IAM, IGA, PAM และ CIEM ต่างกันอย่างไร เลือกตัวไหนก่อน

IAM, IGA, PAM และ CIEM เป็นความสามารถด้านการจัดการตัวตนและสิทธิ์ที่ชื่อคล้ายกันจนสับสนง่าย แต่แต่ละตัวตอบคำถามคนละข้อ IAM (identity and access management) ดูแลว่าใครเป็นใครและเข้าถึงอะไรได้ IGA ตรวจว่าสิทธิ์ที่มีผ่านการอนุมัติและยังจำเป็นอยู่ PAM ปกป้องบัญชีที่มีอำนาจสูง ส่วน CIEM ค้นหาและลดสิทธิ์เกินจำเป็นของตัวตนบนคลาวด์ บทความนี้เปรียบเทียบทั้งสี่ตัวแบบไม่ผูกกับผู้ผลิตรายใด เพื่อช่วยตัดสินใจว่าองค์กรควรเริ่มจากตัวไหน

IAM คือร่มใหญ่ ส่วนอีกสามตัวเป็นงานเฉพาะทาง

คลังคำศัพท์ (glossary) ของ NIST (หน่วยงานมาตรฐานของสหรัฐ) นิยาม identity management ในระบบไอทีองค์กรว่า คือการกำหนดและบริหารบทบาทกับสิทธิ์เข้าถึงของผู้ใช้เครือข่ายแต่ละคน (อ้างจาก NIST SP 800-175A) เอกสารของ AWS แบ่งงานของ IAM เป็นสองส่วน คือ authentication (การยืนยันว่าใครเป็นผู้ login) และ authorization (การกำหนดว่าทำอะไรได้บ้าง) ในทางปฏิบัติ IAM จึงครอบคลุมสามอย่าง คือไดเรกทอรี (directory: ฐานข้อมูลรายชื่อผู้ใช้และบัญชี) ระบบ login ซึ่งรวม MFA (การยืนยันตัวตนหลายขั้น) และ SSO (login ครั้งเดียวใช้ได้หลายระบบ) และกฎที่กำหนดสิทธิ์ ส่วน IGA, PAM และ CIEM เป็นชื่อหมวดที่ตลาดตั้งขึ้น ขอบเขตของแต่ละหมวดจึงต่างกันไปตามผู้ผลิตและนักวิเคราะห์ ให้ดูว่าผลิตภัณฑ์ทำอะไรได้จริง อย่าตัดสินจากชื่อหมวดอย่างเดียว

ทั้งสี่ตัวตอบคำถามอะไร

• IAM: "ตอนนี้ใครเข้าถึงอะไรได้" งานหลักมีสามส่วน คือไดเรกทอรี การยืนยันตัวตน (รวม MFA และ SSO) และนโยบายการอนุญาต เช่น role (ชุดสิทธิ์ตามหน้าที่) และ policy (กฎที่ระบุว่าใครทำอะไรได้)
• IGA (identity governance and administration): "สิทธิ์ที่มีอยู่ตอนนี้ถูกต้องและยังจำเป็นหรือไม่" Microsoft อธิบายงานนี้ผ่านสี่คำถาม คือ ตัวตนใดควรเข้าถึงทรัพยากรใด ตัวตนเหล่านั้นใช้สิทธิ์ทำอะไร องค์กรมีมาตรการควบคุมหรือไม่ และผู้ตรวจสอบยืนยันได้หรือไม่ว่ามาตรการเหล่านั้นใช้ได้ผล งานหลักมีสี่ส่วน คือ วงจรชีวิตตัวตนที่เชื่อมกับระบบ HR การขอและอนุมัติสิทธิ์ การทบทวนสิทธิ์เป็นรอบ (access review) และการตรวจ separation of duties (การแบ่งหน้าที่ไม่ให้คนเดียวถือสิทธิ์ที่ขัดกัน)
• PAM (privileged access management): "บัญชีอำนาจสูงถูกควบคุมอย่างไร" NIST นิยาม privileged user ว่าคือผู้ใช้ที่ได้รับอนุญาตให้ทำงานด้านความปลอดภัยที่ผู้ใช้ทั่วไปทำไม่ได้ เครื่องมือ PAM ลดความเสี่ยงของบัญชีกลุ่มนี้ด้วยสามวิธี คือให้สิทธิ์ชั่วคราวเฉพาะตอนใช้ (just-in-time) ต้องขออนุมัติก่อนใช้ และเก็บประวัติการใช้งานไว้ตรวจสอบ
• CIEM (cloud infrastructure entitlement management): "ตัวตนบนคลาวด์ถือสิทธิ์อะไรอยู่ และใช้จริงแค่ไหน" Google Security Command Center อธิบายว่า CIEM คือการจัดการว่าตัวตนใดเข้าถึงทรัพยากรใดบนหลายแพลตฟอร์มคลาวด์ และแจ้งเตือนสิทธิ์ส่วนเกิน

ความต่างอีกข้อคือจังหวะที่แต่ละตัวทำงาน IAM ทำงานทุกครั้งที่มีการเข้าใช้ IGA ทำงานเมื่อมีเหตุการณ์ เช่น พนักงานเข้าใหม่ ย้ายตำแหน่ง หรือลาออก และทำงานตามรอบทบทวน PAM ทำงานตอนที่มีคนใช้สิทธิ์อำนาจสูง ส่วน CIEM ทำงานต่อเนื่อง โดยเทียบสิทธิ์ที่ให้ไว้กับสิทธิ์ที่ถูกใช้จริง

ทั้งสี่ตัวทำงานร่วมกันอย่างไร

ลองดูเส้นทางของสิทธิ์หนึ่งรายการ วิศวกรคนใหม่ขอ role บนคลาวด์ IGA ส่งคำขอไปให้เจ้าของระบบอนุมัติ IAM ยืนยันตัวตนวิศวกรด้วย MFA และบังคับให้ใช้ได้เฉพาะสิทธิ์ที่อนุมัติ เมื่อต้องทำงานระดับผู้ดูแลระบบ PAM ให้สิทธิ์ยกระดับชั่วคราวแทนการถือสิทธิ์ถาวร เมื่อเวลาผ่านไป CIEM พบว่าบางสิทธิ์ไม่เคยถูกใช้ จึงส่งผลกลับไปให้ IGA ทบทวนหรือถอนสิทธิ์ เครื่องมือของผู้ให้บริการคลาวด์เองก็ทำงานในแนวนี้ เช่น IAM Access Analyzer ของ AWS รายงาน role, access key (คีย์ที่โปรแกรมใช้เรียกบริการคลาวด์) และรหัสผ่านของ IAM user ที่ไม่ได้ใช้ ส่วน IAM recommender ของ Google Cloud เทียบสิทธิ์ที่ให้ไว้กับสิทธิ์ที่ใช้จริงในช่วงสังเกตการณ์ไม่เกิน 90 วัน

จุดที่ทับซ้อนและเส้นแบ่งที่ควรรู้

• PAM กับ IGA: Microsoft ถือว่าการจัดการสิทธิ์อำนาจสูงเป็นส่วนหนึ่งของ identity governance และ Privileged Identity Management (PIM) ของ Microsoft ต้องใช้ไลเซนส์ Microsoft Entra ID P2 หรือ ID Governance นี่แสดงว่าเส้นแบ่งระหว่างหมวดไม่ตายตัว ควรตรวจก่อนว่าไลเซนส์ที่องค์กรมีอยู่แล้วรวมความสามารถอะไรไว้บ้าง
• CIEM กับเครื่องมือของผู้ให้บริการคลาวด์: AWS และ Google Cloud มีเครื่องมือวิเคราะห์สิทธิ์สำหรับคลาวด์ของตัวเอง ส่วน CIEM ให้มุมมองเดียวครอบคลุมหลายคลาวด์ ควรรู้ข้อจำกัดด้วย IAM recommender ของ Google ไม่แก้สิทธิ์ให้อัตโนมัติ และพิจารณาเฉพาะ IAM allow policy (policy ที่อนุญาตสิทธิ์) ไม่รวม ACL (รายการควบคุมการเข้าถึง) หรือ Kubernetes RBAC (การกำหนดสิทธิ์ตาม role ใน Kubernetes)
• ตลาด CIEM เปลี่ยนเร็ว: Microsoft ประกาศหยุดขายและเลิกให้บริการ Microsoft Entra Permissions Management ในปี 2025 และเอกสารของผลิตภัณฑ์นี้ถูกย้ายไปอยู่ในคลังเอกสารเก่าแล้ว ก่อนเลือกผลิตภัณฑ์ ควรถามผู้ผลิตถึงแผนระยะยาวและวิธีส่งออกข้อมูลออกมา
• ตัวตนที่ไม่ใช่คน: สิทธิ์ของ service account (บัญชีที่โปรแกรมใช้) แอปพลิเคชัน และ workload (งานที่รันอัตโนมัติบนระบบ) ต้องรวมอยู่ในขอบเขตการทบทวนด้วย เอกสารของ Microsoft ระบุว่า Entra Permissions Management ครอบคลุมสิทธิ์ของทั้งผู้ใช้และ workload ดูแนวทางใน บัญชีบริการและตัวตนที่ไม่ใช่คน

PAM: สิทธิ์อำนาจสูงขององค์กรเสี่ยงแค่ไหน

Microsoft PIM แบ่งการมอบสิทธิ์เป็นสองแบบ คือ active (ใช้ได้ทันที) และ eligible (ผู้ใช้ต้องกดเปิดสิทธิ์ก่อนใช้ ซึ่งอาจต้องผ่าน MFA ใส่เหตุผล หรือรออนุมัติ) ทั้งสองแบบกำหนดช่วงเวลาได้ เอกสารแนวปฏิบัติของ Microsoft แนะนำให้มี Global Administrator (ผู้ดูแลสูงสุดของ tenant ซึ่งคือพื้นที่บัญชีองค์กรหนึ่งชุดบนบริการของ Microsoft) น้อยกว่าห้าคน จำกัดการมอบ role สิทธิ์สูง (privileged role assignment) ให้น้อยกว่า 10 รายการ ใช้ PIM ให้สิทธิ์แบบ just-in-time เปิด MFA กับบัญชีผู้ดูแลทุกบัญชี และทบทวนสิทธิ์เป็นรอบ ตัวเลขเหล่านี้เป็นคำแนะนำของผู้ผลิตรายเดียวสำหรับ tenant ของตนเอง ไม่ใช่มาตรฐานกลาง แต่แนวคิดนำไปใช้กับแพลตฟอร์มอื่นได้ รายละเอียดเพิ่มเติมอยู่ใน บทความเรื่อง PAM

เริ่มจากอะไรก่อน

ไม่มีลำดับตายตัว ให้เริ่มจากปัญหาที่ใหญ่ที่สุดในองค์กร

• ยังไม่มี SSO และ MFA ครอบคลุม: เริ่มที่พื้นฐาน IAM ก่อน ดู MFA แบบไหนปลอดภัยกว่า
• ผู้ดูแลระบบถือสิทธิ์ถาวรหรือใช้บัญชีร่วมกัน: เริ่มที่ PAM
• บัญชีของคนที่ลาออกยังใช้ได้ หรือตอบผู้ตรวจสอบไม่ได้ว่าใครอนุมัติสิทธิ์: เริ่มที่ IGA
• ใช้หลายคลาวด์ มี role และ key จำนวนมาก: เริ่มจากเครื่องมือวิเคราะห์สิทธิ์ของผู้ให้บริการคลาวด์แต่ละราย แล้วค่อยพิจารณา CIEM เมื่อต้องการมุมมองรวมศูนย์
• ไม่รู้ตัวเมื่อบัญชีถูกยึด: ดู ITDR (การตรวจจับและตอบสนองภัยคุกคามที่มุ่งที่ตัวตน) ซึ่งเป็นอีกชั้นที่เสริมทั้งสี่ตัวนี้

ข้อผิดพลาดที่พบบ่อย

• ซื้อเครื่องมือก่อนทำความสะอาดข้อมูลตัวตน: IGA และ CIEM ต้องอาศัยข้อมูลเจ้าของ บัญชี และสถานะการจ้างงานที่ถูกต้อง ถ้าข้อมูลจากระบบ HR กับไดเรกทอรีไม่ตรงกัน ผลที่ได้จะชี้นำไปผิดทาง
• ปล่อยสิทธิ์ผู้ดูแลถาวร: บัญชีที่มีอำนาจสูงตลอดเวลาเป็นเป้าหมายที่คุ้มที่สุดสำหรับผู้โจมตี ให้ใช้การยกสิทธิ์ชั่วคราว และมีบัญชีฉุกเฉินแยกต่างหากที่มีการเฝ้าระวัง (Microsoft แนะนำบัญชีฉุกเฉินแบบ cloud-only สองบัญชี คือบัญชีที่สร้างบนคลาวด์ล้วน)
• ทบทวนสิทธิ์แบบกดอนุมัติทุกรายการ: ถ้าผู้ทบทวนไม่มีข้อมูลประกอบ การทบทวนก็เป็นเพียงพิธีกรรม ให้เจ้าของระบบเป็นผู้ตัดสิน โดยดูข้อมูลการใช้งานล่าสุดประกอบ
• ลดสิทธิ์ตามผลวิเคราะห์โดยไม่ทดสอบ: ผลวิเคราะห์อิงข้อมูลในช่วงสังเกตการณ์ที่จำกัด งานที่ทำปีละครั้งจึงอาจดูเหมือนไม่เคยถูกใช้ ควรยืนยันกับเจ้าของงานและทดสอบก่อนถอนสิทธิ์
• ลืมตัวตนที่ไม่ใช่คน: service account และ access key ที่ไม่มีเจ้าของมักหลุดจากการทบทวน
• เชื่อชื่อหมวดมากกว่าความสามารถจริง: ให้ผู้ผลิตสาธิตด้วยกรณีใช้งานจริงขององค์กร

เริ่มได้ทันที

• นับผู้ดูแลระบบ: ทำรายการบัญชีสิทธิ์สูงในไดเรกทอรี คลาวด์ และระบบสำคัญ แล้วระบุว่าใครถือสิทธิ์ถาวรอยู่
• เทียบรายชื่อพนักงานกับบัญชีที่ยังใช้งานได้: หาบัญชีของคนที่ลาออกหรือย้ายงานไปแล้ว
• ดูรายงานสิทธิ์ที่ไม่ได้ใช้ในคลาวด์ที่ใช้อยู่: เช่น unused access ของ IAM Access Analyzer หรือ IAM recommender เปิดแบบอ่านอย่างเดียว และตรวจค่าบริการก่อนเปิดใช้ เพราะ AWS คิดค่าบริการสำหรับการวิเคราะห์ unused access
• เลือกกลุ่มสิทธิ์สำคัญหนึ่งกลุ่ม เช่น domain admins (ผู้ดูแลโดเมน) หรือ role เจ้าของคลาวด์ แล้วทำ access review รอบแรก
• ระบุเจ้าของแต่ละความสามารถ: ใครรับผิดชอบ IAM, IGA, PAM และ CIEM ถ้าอยู่คนละทีม ให้ตกลงจุดส่งต่องานให้ชัด

หากต้องการดูว่าช่องว่างด้านใดควรแก้ก่อน ลองใช้ แบบประเมินตนเอง

CIEM เป็นหนึ่งในเครื่องมือที่ผลิตภัณฑ์แบบรวมมักนำมาไว้ด้วยกัน ดูว่าCNAPP ต่างจาก CSPM และ CWPP อย่างไร

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

• NIST glossary: identity and access management: นิยามพื้นฐานของ identity management
• NIST glossary: privileged user: นิยามของผู้ใช้สิทธิ์สูงจาก NIST และ CNSS
• Microsoft Learn: Microsoft Entra ID Governance: ตัวอย่างของ IGA ที่ครอบคลุมวงจรชีวิตตัวตน การขอสิทธิ์ และ access review
• Microsoft Learn: What is Privileged Identity Management?: ตัวอย่างการให้สิทธิ์แบบ just-in-time และจำกัดเวลา
• Microsoft Learn: Best practices for Microsoft Entra roles: คำแนะนำเรื่องสิทธิ์ผู้ดูแล รวมถึงตัวเลขที่แนะนำ
• AWS: What is IAM?: ความต่างระหว่าง authentication กับ authorization
• AWS: IAM Access Analyzer: การวิเคราะห์ unused access และการสร้าง policy จากกิจกรรมที่เกิดขึ้นจริง
• Google Cloud: IAM recommender overview: การเทียบสิทธิ์ที่ให้ไว้กับสิทธิ์ที่ใช้จริง และข้อจำกัดของเครื่องมือ
• Google Cloud: CIEM in Security Command Center: ตัวอย่างการนิยาม CIEM ที่ครอบคลุมหลายคลาวด์