Non-human identity (NHI คือตัวตนที่ซอฟต์แวร์ใช้แทนคน) ได้แก่ service account (บัญชีที่แอปหรือระบบใช้ login แทนคน) API key (รหัสที่โปรแกรมใช้เรียกบริการอื่น) access token (รหัสชั่วคราวที่ใช้เข้าถึงบริการ) ใบรับรอง (certificate) และกุญแจเข้ารหัส ที่ใช้ในแอปพลิเคชัน สคริปต์ บริการคลาวด์ และ pipeline (ขั้นตอนอัตโนมัติสำหรับสร้างและติดตั้งซอฟต์แวร์ หรือ CI/CD) OWASP เผยแพร่ Non-Human Identities Top 10 ฉบับปี 2025 และอธิบายคำนี้ด้วยตัวอย่างชุดเดียวกัน ความเสี่ยงของ service account อยู่ที่สร้างง่ายและลืมง่าย มักมีสิทธิ์สูง และตอบ MFA (การยืนยันตัวตนหลายขั้นตอน) ไม่ได้ ดังนั้นความลับ (secret) ที่รั่วไปเพียงชุดเดียว ใครถือไว้ก็ใช้ได้ จนกว่าจะมีคนสังเกตเห็น

ทำไมจึงถูกมองข้าม

  • ไม่มีคนอยู่เบื้องหลัง: ไม่มีกระบวนการคนเข้า-ย้าย-ออก (joiner-mover-leaver) แบบที่ใช้กับพนักงาน และไม่มีหัวหน้าคอยถามว่ายังต้องใช้อยู่หรือไม่
  • สร้างเพื่อโครงการแล้วเก็บไว้ตลอด: OWASP จัด improper offboarding (การไม่ปิดตัวตนที่เลิกใช้แล้ว) เป็นความเสี่ยงอันดับหนึ่ง คือ service account และ access key ที่ไม่ใช้แล้วแต่ไม่มีใครปิดหรือลบ
  • ความลับถูกวางไว้หลายที่: คีย์ไปอยู่ใน source code ไฟล์ config ที่เก็บเป็นข้อความธรรมดา (plain text) และเครื่องมือแชต
  • สิทธิ์ค่อย ๆ เพิ่มขึ้น: ตอนแรกให้สิทธิ์กว้างไว้ก่อนเพื่อให้ระบบทำงานได้ แล้วไม่เคยลดลง
  • อยู่นอกกระบวนการที่ออกแบบมาสำหรับคน: การทบทวนสิทธิ์ (access review) และโครงการ MFA มักนับเฉพาะผู้ใช้ที่เป็นคน

มาตรฐานก็แยกเรื่องคนกับเครื่องออกจากกัน NIST SP 800-63-4 (Digital Identity Guidelines ฉบับสุดท้ายปี 2025) ครอบคลุมการพิสูจน์ตัวตน การยืนยันตัวตน และ federation (การใช้ตัวตนข้ามระบบหรือข้ามองค์กร) สำหรับบุคคลธรรมดา และระบุว่าการยืนยันตัวตนแบบ machine-to-machine (เครื่องคุยกับเครื่อง) อยู่นอกขอบเขต ดังนั้นแนวทางเรื่อง passkey และ MFA ที่มาจาก 800-63 จึงไม่ใช่คำตอบสำหรับเครื่อง สำหรับเครื่องและบริการ ให้ดูมาตรการใน NIST SP 800-53 เช่น IA-9 (ระบุและยืนยันตัวตนของบริการก่อนเริ่มสื่อสารกัน) IA-5(7) (ห้ามฝังข้อมูลพิสูจน์ตัวตนแบบ static ที่ไม่เข้ารหัสไว้ในแอปพลิเคชันหรือที่เก็บข้อมูลแบบ static) AC-6 (สิทธิ์เท่าที่จำเป็น (least privilege) ซึ่งใช้กับ process ที่ทำงานแทนผู้ใช้ด้วย) และ AC-2 (การจัดการบัญชี รวมถึงการเฝ้าดูการใช้บัญชีและการปิดบัญชีที่ไม่ได้ใช้แล้ว)

OWASP NHI Top 10 (2025)

OWASP ระบุความเสี่ยงไว้สิบข้อในรายการปี 2025 เราจัดเป็นห้ากลุ่มในภาพด้านล่าง เพื่อให้ลงมือแก้ได้ง่ายขึ้น

  • NHI1 Improper Offboarding: ไม่ปิดหรือลบ service account และ access key ที่เลิกใช้แล้ว
  • NHI2 Secret Leakage: API key, token และใบรับรองหลุดไปอยู่ใน source code, ไฟล์ config แบบ plain text หรือเครื่องมือแชต
  • NHI3 Vulnerable Third-Party NHI: IDE extension (ส่วนเสริมของโปรแกรมเขียนโค้ด) หรือ SaaS integration (ตัวเชื่อมกับบริการ SaaS) ที่ถูกเจาะ ทำให้ข้อมูลรับรองที่ถือไว้รั่วตามไปด้วย
  • NHI4 Insecure Authentication: ใช้วิธียืนยันตัวตนที่เลิกใช้แล้วหรืออ่อนแอ
  • NHI5 Overprivileged NHI: ได้สิทธิ์เกินกว่าที่งานต้องใช้มาก
  • NHI6 Insecure Cloud Deployment Configurations: pipeline CI/CD ใช้ข้อมูลรับรองคลาวด์แบบ static (ไม่เปลี่ยนแปลง) หรือตั้งค่า OIDC (มาตรฐานที่ให้ pipeline ขอ token ชั่วคราวแทนการเก็บคีย์) โดยไม่ตรวจ token และไม่กำหนดเงื่อนไขของ claim (ข้อมูลที่ระบุอยู่ใน token)
  • NHI7 Long-Lived Secrets: ข้อมูลรับรองที่หมดอายุในอีกนานมากหรือไม่มีวันหมดอายุ
  • NHI8 Environment Isolation: NHI ตัวเดียวถูกใช้ร่วมกันทั้งใน environment (ชุดระบบแยกตามขั้นตอนงาน) dev, test, staging และ production
  • NHI9 NHI Reuse: NHI ตัวเดียวถูกใช้กับหลายแอปพลิเคชัน
  • NHI10 Human Use of NHI: คนใช้ตัวตนของบริการทำงานด้วยมือ ทำให้ดูจาก log ไม่ได้ว่าใครทำอะไร
INFOGRAPHIC
OWASP NHI Top 10 จัดเป็นห้ากลุ่ม
ความเสี่ยง NHI
สิบข้อของ OWASP ที่เราจัดกลุ่มเอง
วงจรชีวิต
NHI1, NHI7: ไม่ถูกปิด ไม่หมดอายุ
การจัดการความลับ
NHI2, NHI4: เก็บไว้ที่ไหน ใช้วิธีใด
ขอบเขตความเสียหาย
NHI5, NHI8, NHI9: สิทธิ์เกิน ใช้ร่วมกัน
ห่วงโซ่อุปทานและ pipeline
NHI3, NHI6: ตัวเชื่อมภายนอกและ CI/CD
ความรับผิดชอบ
NHI10: คนใช้ตัวตนของเครื่อง

ตัวอย่างจริง: แอปทดสอบที่ถูกลืม

เดือนมกราคม 2024 Microsoft เปิดเผยว่ากลุ่มที่ Microsoft เรียกว่า Midnight Blizzard ใช้ password spraying (การลองรหัสผ่านที่พบบ่อยกับหลายบัญชี) เจาะบัญชีใน tenant (พื้นที่ของแต่ละองค์กรบนบริการคลาวด์) รุ่นเก่าที่ใช้ทดสอบและไม่ใช่ระบบจริง บัญชีนั้นไม่ได้เปิด MFA จากนั้น ตามที่ Microsoft ระบุ ผู้โจมตีเข้าควบคุมแอปทดสอบแบบ OAuth (แอปที่ได้รับสิทธิ์เข้าถึงข้อมูลแทนผู้ใช้) รุ่นเก่า ซึ่งมีสิทธิ์สูงในระบบขององค์กร แล้วใช้แอปนั้นกำหนดบทบาท full_access_as_app ของ Exchange Online ซึ่งเปิดทางให้เข้าถึงกล่องจดหมายได้ บทเรียนคือจุดอ่อนอยู่ที่ตัวตนของแอปทดสอบที่ถูกลืมแต่ยังมีสิทธิ์สูง ตรงกับรูปแบบที่ NHI1 และ NHI5 อธิบายไว้

INFOGRAPHIC
แอปทดสอบที่ถูกลืมเปิดทางอย่างไร (Microsoft 2024)
01
สุ่มรหัสผ่าน
บัญชีทดสอบเก่า ไม่มี MFA
02
แอป OAuth ทดสอบเก่า
มีสิทธิ์สูงในระบบองค์กร
03
ได้บทบาทใหม่
full_access_as_app
04
เข้าถึงอีเมล
กล่องจดหมายองค์กรบางส่วน

แนวทางที่ปลอดภัยกว่า: ความลับน้อยลง อายุสั้นลง

วิธีที่ได้ผลที่สุดคือทำให้ต้องพึ่งความลับอายุยาวให้น้อยลง ตามเอกสารของผู้ให้บริการเอง ปัจจุบันแพลตฟอร์มคลาวด์มีวิธีพิสูจน์ตัวตนของ workload (โปรแกรมที่รันบนคลาวด์) โดยไม่ต้องเก็บรหัสผ่านหรือคีย์

  • ตัวตนที่แพลตฟอร์มจัดการให้: Microsoft ระบุว่า managed identity (ตัวตนที่ Azure สร้างและดูแลให้แอป) ช่วยให้แอปขอ token จาก Microsoft Entra ได้โดยไม่ต้องจัดการข้อมูลรับรองเอง และผู้ใช้เข้าไปดูข้อมูลรับรองนั้นไม่ได้ด้วยซ้ำ
  • เลี่ยงคีย์ที่ดาวน์โหลดไว้: Google Cloud เปรียบ service account key กับรหัสผ่าน และระบุว่าผู้โจมตีมองหาคีย์ที่รั่วใน public repository, bucket สาธารณะ และข้อมูลจากเหตุข้อมูลรั่วไหล จึงแนะนำให้ใช้ทางเลือกที่ปลอดภัยกว่าทุกครั้งที่ทำได้ เช่น attached service account (service account ที่ผูกกับเครื่องหรือบริการที่รันงานโดยตรง) หรือ Workload Identity Federation (การแลกตัวตนจากระบบอื่นเป็นสิทธิ์ชั่วคราวโดยไม่ต้องมีคีย์) ถ้าจำเป็นต้องใช้คีย์ Google แนะนำให้ปิดการสร้างคีย์ด้วย organization policy (นโยบายระดับองค์กร) แล้วอนุญาตเฉพาะกรณียกเว้น
  • token อายุสั้นใน pipeline: ถ้าใช้ OIDC ใน GitHub Actions แต่ละ job (งานหนึ่งรอบใน pipeline) จะได้ token ของตัวเอง แล้วนำไปแลกเป็น token คลาวด์อายุสั้นที่ใช้ได้เฉพาะ job นั้น จึงไม่ต้องเก็บข้อมูลรับรองคลาวด์อายุยาวไว้ใน GitHub
  • token อายุสั้นใน Kubernetes: ตั้งแต่ v1.22 Pod (หน่วยที่รันแอปใน Kubernetes) ได้รับ token อายุสั้นที่เปลี่ยนค่าเองโดยอัตโนมัติผ่าน TokenRequest API ส่วนเวอร์ชันก่อนหน้าใช้ token แบบ static อายุยาวที่เก็บใน Secret เอกสารของ Kubernetes ยังอธิบายการใช้ RBAC (การกำหนดสิทธิ์ตามบทบาท) เพื่อให้สิทธิ์เท่าที่จำเป็น และการตั้งค่า automountServiceAccountToken เพื่อไม่ให้ระบบใส่ข้อมูลรับรองให้ Pod โดยไม่จำเป็น
  • ความลับที่ยังเหลือ ให้เก็บใน vault และหมุนเปลี่ยน: ถ้าเลี่ยงความลับไม่ได้ ให้ใช้หนึ่งชุดต่อหนึ่งแอปและหนึ่ง environment กำหนดวันหมดอายุ และเปลี่ยนค่าเป็นรอบ (rotate) โดยเก็บไว้ใน vault (ที่เก็บความลับที่ควบคุมการเข้าถึง) คำแนะนำของ Google คือให้ใช้ service account แยกต่อแอป และคีย์แยกต่อเครื่อง เพื่อให้ตรวจย้อนได้
INFOGRAPHIC
รูปแบบข้อมูลรับรองจากเสี่ยงสุดถึงปลอดภัยสุด
คีย์ static ฝังในโค้ดหรือใช้ร่วมกัน
รั่วง่าย ตามรอยยาก
คีย์ static ที่ไม่เคยเปลี่ยนค่า
เก็บใน config หรือที่เก็บทั่วไป
เก็บใน vault และเปลี่ยนค่าเป็นรอบ
ต้องมีวันหมดอายุ
token อายุสั้น ออกให้เมื่อขอ
เช่น OIDC และ bound token
ตัวตนที่แพลตฟอร์มจัดการให้
ไม่มีความลับให้ดูแล
ความเสี่ยงสูงความเสี่ยงต่ำ

AI agent คือ NHI กลุ่มถัดไป

AI agent (ซอฟต์แวร์ AI ที่ลงมือทำงานแทนผู้ใช้) และ MCP server (ตัวเชื่อมที่ให้ AI agent เรียกใช้เครื่องมือและข้อมูล) ถือ token และเรียก API แทนใครบางคน จึงเป็น NHI เช่นกัน เดือนกุมภาพันธ์ 2026 NCCoE ของ NIST (ศูนย์ความปลอดภัยไซเบอร์ของ NIST) เผยแพร่ concept paper (เอกสารข้อเสนอแนวคิด) เรื่องตัวตนและการกำหนดสิทธิ์ของซอฟต์แวร์และ AI agent และขอความเห็นสาธารณะ (ปิดรับความเห็นวันที่ 2 เมษายน 2026) ในหัวข้อการระบุตัวตน การกำหนดสิทธิ์ การตรวจสอบย้อนหลัง และ non-repudiation (การพิสูจน์ได้ว่าใครเป็นผู้ทำ ปฏิเสธภายหลังไม่ได้) ของ AI agent เอกสารนี้เป็นข้อเสนอระยะเริ่มต้น และเรายังไม่ได้ตรวจสอบความคืบหน้าหลังจากนั้น จึงควรเปิดหน้าโครงการของ NCCoE เพื่อดูข้อมูลล่าสุด ส่วนแนวป้องกันที่นำไปใช้ได้ทันที ดูใน คู่มือความปลอดภัยของ MCP และ ความปลอดภัยของ agentic AI

ข้อควรระวัง

  • นับเฉพาะผู้ใช้ที่เป็นคน: การทบทวนสิทธิ์ที่ข้าม service account ไปจะเหลือจุดบอด
  • ใช้คีย์เดียวข้าม environment หรือข้ามแอป: ตรงกับ NHI8 และ NHI9 รั่วครั้งเดียวก็กระทบทุกที่ที่ใช้คีย์นั้น
  • ไม่หมุนอะไรเลยเพราะกลัวระบบพัง: ให้ลองหมุนในระบบทดสอบก่อน และให้เจ้าของรู้ว่ามีอะไรพึ่งพาคีย์แต่ละตัว
  • เก็บใน vault แต่ไม่ตั้งวันหมดอายุ: ที่เก็บปลอดภัยขึ้น แต่ความลับยังอายุยาวอยู่ (NHI7)
  • ปล่อยให้คน login ด้วย service account: log จะเห็นแค่ชื่อ service account ไม่เห็นว่าใครลงมือ (NHI10)
  • มองข้าม integration ของบุคคลภายนอก: OAuth app และ SaaS connector ถือสิทธิ์เข้าถึงค้างไว้ตลอด (NHI3)
  • ลบบัญชีโดยไม่ตรวจว่ามีอะไรพึ่งพา: ให้ปิดการใช้งานก่อน สังเกตว่ามีอะไรพังหรือไม่ แล้วค่อยลบ
INFOGRAPHIC
สถานะทั่วไป กับสถานะเป้าหมายของ NHI

ที่พบบ่อย

  • ไม่มีเจ้าของไม่มีใครตอบได้ว่าใครใช้อยู่
  • ใช้ร่วมข้ามระบบหนึ่งคีย์ ใช้กับหลายแอปและ environment
  • ไม่หมดอายุถ้ารั่ว ก็ใช้ได้ตลอดไป

เป้าหมาย

  • มีเจ้าของที่ระบุชื่อรู้ว่าใครรับผิดชอบ
  • หนึ่งตัวต่อแอปและ environmentถ้ารั่ว ความเสียหายจำกัดอยู่ที่เดียว
  • อายุสั้นและทบทวนเป็นรอบหมดอายุเอง และตรวจสอบเป็นรอบ

ขั้นแรกที่ทำได้ทันที

  • ทำรายการ NHI: service account, API key, ใบรับรอง, OAuth app, ความลับใน CI/CD และ workload identity บนคลาวด์ แล้วบันทึกเจ้าของ วัตถุประสงค์ environment และครั้งล่าสุดที่ใช้
  • กำหนดเจ้าของให้ทุกตัว: ตัวที่ไม่มีเจ้าของควรถูกปิดเป็นกลุ่มแรก
  • ค้นหาความลับที่รั่ว: สแกน repository ไฟล์ config และช่องแชตเพื่อหาข้อมูลรับรอง แล้วเปลี่ยนค่าทุกชุดที่พบ
  • ปิดบัญชีที่ไม่ได้ใช้ก่อน: ดูจากวันที่ login ล่าสุด และสังเกตผลกระทบก่อนลบ
  • ลดสิทธิ์: เริ่มจากตัวที่มีสิทธิ์ admin หรือ owner
  • ทดลองแทนคีย์ static หนึ่งตัว ด้วย managed identity หรือ token อายุสั้น เพื่อสร้างแบบอย่างให้ทีมทำตาม

ลองตรวจดูว่ามาตรการด้านตัวตนขององค์กรอยู่ระดับไหนด้วย แบบประเมินตนเอง แล้วเลือกสองถึงสามข้อจากรายการด้านบนมาทำก่อน ส่วนบัญชีสิทธิ์สูงของคนมีแนวทางแยกไว้ใน PAM คืออะไร และภาพรวมด้านสถาปัตยกรรมอยู่ใน Zero Trust Architecture: องค์ประกอบและแผนเริ่มต้น

ใบรับรองก็เป็นตัวตนของเครื่องอย่างหนึ่ง ดูเรื่องการจัดการใน Certificate Lifecycle Management เมื่อใบรับรองเหลือ 47 วัน

บัญชีของโปรแกรมบนคลาวด์ที่มีสิทธิ์เกินจำเป็นเป็นสิ่งที่ CNAPP ช่วยตรวจ อ่านภาพรวมในบทความ CNAPP

token และ API key ที่เชื่อมแอป SaaS เข้าด้วยกันเป็นตัวตนของเครื่อง ดูการตรวจแอปที่เชื่อมต่อใน SaaS Security และ SSPM: ดูแลแอป SaaS อย่างไร

แหล่งอ้างอิงและข้อมูลเพิ่มเติม