PAM คืออะไร และทำไมต้องควบคุมสิทธิ์ผู้ดูแลระบบ

PAM (Privileged Access Management) คือการควบคุมการใช้บัญชีที่มีสิทธิ์สูง ประกอบด้วยนโยบาย กระบวนการ และเครื่องมือที่กำหนดว่าใครใช้บัญชีเหล่านี้ได้ ใช้เมื่อไร ใช้เพื่อทำอะไร และต้องมีบันทึกว่าทำอะไรไปบ้าง คลังศัพท์ของ NIST นิยามบัญชีสิทธิ์สูง (privileged account) ว่าเป็นบัญชีระบบที่ถือสิทธิ์เทียบเท่าผู้ใช้สิทธิ์สูง ในทางปฏิบัติคือบัญชีของ domain admin (แอดมินที่ควบคุมบัญชีผู้ใช้และเครื่องทั้งโดเมน) ผู้ดูแลเซิร์ฟเวอร์ ผู้ดูแลฐานข้อมูลและคลาวด์ รวมถึง service account (บัญชีที่แอปหรือระบบใช้ login แทนคน) ที่รันด้วยสิทธิ์ใกล้เคียงกัน สิ่งที่ PAM ตั้งใจจะเข้ามาแทนที่ คือรหัสผ่านแอดมินที่หลายคนใช้ร่วมกัน ไม่เคยเปลี่ยน และใช้ได้ทุกเวลา บทความนี้อธิบายว่า PAM ทำงานอย่างไร มาตรฐานกำหนดอะไรไว้ และเริ่มต้นอย่างไรได้โดยยังไม่ต้องซื้อผลิตภัณฑ์

อะไรนับเป็นสิทธิ์สูง

NIST SP 800-53 อธิบายไว้ในส่วนของมาตรการ AC-2(7) ว่า บทบาทสิทธิ์สูง (privileged role) คือบทบาทที่ทำให้ทำงานด้านความปลอดภัยที่ผู้ใช้ทั่วไปทำไม่ได้ เช่น การจัดการกุญแจเข้ารหัส การจัดการบัญชี การดูแลฐานข้อมูล การดูแลระบบและเครือข่าย และการดูแลเว็บ ดังนั้นสิทธิ์สูงวัดจากสิ่งที่บัญชีทำได้ ไม่ใช่จากตำแหน่งงาน ตัวอย่างที่พบบ่อยมีดังนี้

• ผู้ดูแลระบบที่เป็นคน: ผู้ดูแลโดเมน เซิร์ฟเวอร์ เครือข่าย ฐานข้อมูล และ tenant (พื้นที่บริการของแต่ละองค์กร) บนคลาวด์
• บัญชีแอปพลิเคชันและ service account: รันด้วยสิทธิ์สูง และมักไม่มีใครเฝ้าดู (ดู Service Account และ Non-human Identity)
• บัญชีฉุกเฉิน (break-glass): เป็นบัญชีสำรองที่เปิดใช้ตอนฉุกเฉิน มีอำนาจสูงโดยตั้งใจและแทบไม่ได้ใช้ จึงต้องเฝ้าระวังเป็นพิเศษ
• การเข้าถึงของบุคคลภายนอกและผู้ให้บริการ: วิศวกรจากภายนอกที่ต้องใช้สิทธิ์แอดมินเป็นการชั่วคราว
• บทบาทแอดมินบนคลาวด์และ SaaS: เช่น เจ้าของ tenant หรือ subscription ซึ่งแก้ได้ทุกอย่างที่อยู่ภายใต้

ทำไมต้องมี

MITRE ATT&CK (ฐานความรู้รวบรวมเทคนิคของผู้โจมตี) จัด "Valid Accounts" (T1078) เป็นเทคนิคที่ผู้โจมตีนำข้อมูลรับรองของบัญชีที่มีอยู่จริงไปใช้ เพื่อเข้าระบบครั้งแรก อยู่ในระบบต่อไปได้ ยกระดับสิทธิ์ หรือหลบการตรวจจับ เพราะการใช้งานดูเหมือนการ login ตามปกติ จึงกลืนไปกับกิจกรรมจริง นอกจากนี้ สิทธิ์ที่ซ้อนทับกันระหว่างบัญชี local, domain และคลาวด์ ยังอาจทำให้ผู้โจมตีขยับไปถึงระดับ domain admin หรือ enterprise admin ได้ MITRE ยกตัวอย่างกลุ่มผู้โจมตีอย่าง Wizard Spider และ Lazarus Group ประเด็นสำคัญคือ ข้อมูลรับรองแอดมินที่ถูกขโมยหนึ่งชุดไม่ได้แปลว่าเสียแค่หนึ่งบัญชี แต่อาจแปลว่าเสียทั้งระบบ

แนวทางด้าน IAM (การบริหารตัวตนและสิทธิ์การเข้าถึง) สำหรับผู้ดูแลระบบ ที่ CISA และ NSA เผยแพร่ในเดือนมีนาคม 2023 (ภายใต้ Enduring Security Framework) แบ่งข้อแนะนำเป็นห้าด้าน ได้แก่ identity governance (การกำกับดูแลตัวตน) environmental hardening (การเสริมความแข็งแรงของสภาพแวดล้อม) identity federation และ SSO (การใช้ตัวตนข้ามระบบและ login ครั้งเดียว) multifactor authentication (MFA คือการยืนยันตัวตนมากกว่าหนึ่งขั้นตอน) และ IAM auditing and monitoring (การตรวจสอบและเฝ้าระวังด้าน IAM) PAM เกี่ยวข้องกับหลายด้านในนี้ โดยเฉพาะการกำกับดูแล MFA และการเฝ้าดูกิจกรรมของบัญชีสิทธิ์สูง

PAM ทำงานอย่างไร

NCSC (ศูนย์ความปลอดภัยไซเบอร์แห่งชาติของสหราชอาณาจักร) วางหลักการห้าข้อไว้ในแนวทาง secure system administration (การดูแลระบบอย่างปลอดภัย) ได้แก่ เชื่อถืออุปกรณ์ที่ใช้จัดการระบบ ปกป้องหน้าจัดการ (administration interface) แบ่งชั้น (tier) ตามความเสี่ยง ใช้ privileged access management และบันทึกกับตรวจสอบกิจกรรมของแอดมิน ข้อที่เป็น PAM โดยตรงให้ควบคุมว่าใคร ที่ไหน เมื่อไร ทำไม และอย่างไร ผู้ดูแลระบบต้องมีสิทธิ์เท่าที่จำเป็น (least privilege คือเข้าถึงได้เฉพาะสิ่งที่งานต้องใช้) และต้องถอนสิทธิ์เมื่อไม่ต้องใช้แล้ว ห้าคำถามนี้ใช้เป็นเกณฑ์อ่านหรือประเมินการออกแบบ PAM ได้ทุกแบบ

• ใคร: แอดมินแต่ละคนใช้บัญชีที่ระบุตัวตนได้และมี MFA ไม่ใช้บัญชีร่วม SP 800-53 มีมาตรการให้ใช้ MFA กับบัญชีสิทธิ์สูง (IA-2(1)) และให้ใช้บัญชีที่ไม่มีสิทธิ์สูงเมื่อทำงานที่ไม่เกี่ยวกับความปลอดภัย (AC-6(2))
• ที่ไหน: งานแอดมินต้องมาจากอุปกรณ์และเส้นทางที่เชื่อถือได้ การเข้าถึงคำสั่งสิทธิ์สูงจากระยะไกลต้องได้รับอนุญาตและบันทึกเหตุผลไว้ (AC-17(4)) และต้องจำกัดการเข้าถึงคำสั่งสิทธิ์สูงผ่านเครือข่าย (AC-6(3))
• เมื่อไร: สิทธิ์ต้องมีกำหนดเวลา SP 800-53 มีมาตรการให้ระบบปิดบัญชีชั่วคราวและบัญชีฉุกเฉินเองเมื่อครบเวลา (AC-2(2)) และมีมาตรการ dynamic privilege management คือการให้และถอนสิทธิ์ตามสถานการณ์ขณะใช้งาน (AC-2(6))
• ทำไม: การยกระดับสิทธิ์ต้องผูกกับงานที่อนุมัติแล้ว เช่น ticket และต้องทบทวนสิทธิ์เป็นระยะเพื่อยืนยันว่ายังจำเป็นอยู่ (AC-6(7))
• อย่างไร: บันทึกการใช้ฟังก์ชันสิทธิ์สูง (AC-6(9)) เฝ้าดูการกำหนดบทบาทสิทธิ์สูง และเพิกถอนสิทธิ์เมื่อไม่เหมาะสมแล้ว (AC-2(7))

ผลิตภัณฑ์ PAM มักทำสิ่งเหล่านี้ด้วยองค์ประกอบไม่กี่อย่าง ได้แก่ vault (ที่เก็บและเปลี่ยนรหัสผ่านของบัญชีสิทธิ์สูงเป็นรอบ) ตัวกลาง (broker หรือ gateway) ที่เปิด session (ช่วงการเข้าใช้งานหนึ่งรอบ) ให้โดยไม่เปิดเผยรหัสผ่านแก่ผู้ใช้ การบันทึก session และคำสั่งที่พิมพ์ และการยกระดับสิทธิ์แบบ just-in-time (JIT คือให้สิทธิ์เฉพาะตอนที่ต้องใช้) พร้อมขั้นตอนอนุมัติ องค์กรต้องใช้ครบทุกอย่างหรือไม่ ขึ้นอยู่กับขนาดขององค์กร สิ่งที่สำคัญกว่ายี่ห้อคือ การควบคุมห้าข้อข้างต้นเกิดขึ้นจริง

จุดแข็ง ข้อจำกัด และตำแหน่งของ PAM

• จุดแข็ง: จำกัดความเสียหายเมื่อข้อมูลรับรองรั่ว เปลี่ยนรหัสผ่านร่วมเป็นความรับผิดชอบรายบุคคล ให้ audit trail (ร่องรอยการใช้งานที่ตรวจย้อนได้) สำหรับการสอบสวนและการปฏิบัติตามกฎระเบียบ และลดสิทธิ์ที่เปิดค้างไว้ตลอด
• ข้อจำกัด: หยุดผู้โจมตีที่ควบคุม session ของแอดมินที่ได้รับอนุมัติอยู่แล้วไม่ได้ จึงต้องใช้ร่วมกับ MFA และการเฝ้าระวัง
• ช่องว่างของขอบเขต: ปกป้องได้เฉพาะบัญชีที่ค้นพบแล้ว service account บทบาทบนคลาวด์ และแอดมินของ SaaS มักไม่ถูกรวมในการติดตั้งรอบแรก
• ความล่าช้า: ขั้นตอนอนุมัติทำให้งานเร่งด่วนช้าลง หากไม่ได้ออกแบบเส้นทางฉุกเฉินไว้ล่วงหน้า
• จุดล้มเหลวจุดเดียว: vault และตัวกลางกลายเป็นโครงสร้างพื้นฐานสำคัญและเป็นเป้าหมายที่มีมูลค่าสูง จึงต้องป้องกันและสำรองข้อมูลให้ดี

PAM เป็นส่วนหนึ่งของงานด้านความปลอดภัยของตัวตน IAM ดูแลตัวตนและสิทธิ์ของทุกคน IGA (Identity Governance and Administration) ดูแลการทบทวนสิทธิ์และวงจรคนเข้า-ย้าย-ออก ส่วน PAM เน้นกลุ่มย่อยที่เสี่ยงสูงสุด ในสถาปัตยกรรม zero trust (แนวคิดที่ไม่เชื่อใจใครโดยอัตโนมัติ ต้องตรวจสอบทุกครั้ง) PAM คือวิธีนำสิทธิ์เท่าที่จำเป็นและการตรวจสอบทุก session ไปใช้กับผู้ดูแลระบบ ดู Zero Trust Architecture: องค์ประกอบและแผนเริ่มต้น ส่วนการเปรียบเทียบตัวย่อเหล่านี้เคียงข้างกันอยู่ใน IAM, IGA, PAM และ CIEM ต่างกันอย่างไร สำหรับ MFA ของแอดมิน ควรเลือกแบบที่ทนต่อฟิชชิง (phishing) เมื่อทำได้ ดู MFA แบบไหนปลอดภัยกว่า

บันไดวุฒิภาวะแบบง่าย

บันไดด้านล่างช่วยบอกตำแหน่งคร่าว ๆ ขององค์กร เป็นภาพประกอบที่เราทำขึ้นเอง ไม่ใช่มาตรฐานทางการ และไม่จำเป็นต้องขึ้นถึงขั้นบนสุดในทุกระบบ ให้เริ่มจากระบบที่ถ้าถูกเจาะแล้วจะเสียหายมากที่สุดก่อน

ข้อควรระวัง

• ปกป้องเฉพาะรหัสผ่านของแอดมินที่เป็นคน: service account และ API key มีอำนาจเท่ากัน แต่มักถูกลืม
• ซื้อเครื่องมือก่อนค้นหาบัญชี: ปกป้องบัญชีที่ยังหาไม่เจอไม่ได้ จึงควรสำรวจ local admin (แอดมินประจำเครื่อง) service account และบทบาทบนคลาวด์ก่อน
• เปิดสิทธิ์ค้างไว้เผื่อใช้: สิทธิ์ชั่วคราวที่ไม่เคยหมดอายุ จะกลายเป็นสิทธิ์ถาวร
• ลืมบัญชี break-glass: ใช้รหัสผ่านร่วมกัน ไม่มีการแจ้งเตือนเมื่อมีคนใช้ และไม่เคยทดสอบ
• มองว่าติดตั้ง vault แล้วจบโครงการ: ต้องเปลี่ยนรหัสผ่านเป็นรอบ ทบทวนสิทธิ์ และถอนสิทธิ์อย่างต่อเนื่อง
• ไม่มีแผนสำหรับผู้ให้บริการภายนอก: บัญชี VPN ร่วมที่เปิดไว้ตลอดเวลา ทำให้ไม่มีใครรู้ว่าใครทำอะไร

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

• ทำรายการบัญชีสิทธิ์สูง: domain admin, local admin บนเซิร์ฟเวอร์, ฐานข้อมูล, เจ้าของ tenant บนคลาวด์, service account และบัญชีของผู้ให้บริการ แล้วนับจำนวนและกำหนดเจ้าของให้ทุกบัญชี
• แยกบัญชีแอดมินออกจากบัญชีใช้งานประจำ: อ่านอีเมลและท่องเว็บด้วยบัญชีที่ไม่มีสิทธิ์สูง
• เปิด MFA ให้ทุกบัญชีสิทธิ์สูง: เริ่มจากคอนโซลคลาวด์และการเข้าถึงระยะไกล
• เลิกใช้รหัสแอดมินร่วม: เปลี่ยนรหัสทุกครั้งที่มีคนออกจากงาน แล้วย้ายไปเก็บใน vault
• เปิด log กิจกรรมสิทธิ์สูง และให้มีคนอ่านทุกสัปดาห์
• ทดสอบบัญชี break-glass: ให้แน่ใจว่าใช้ได้จริง มีการแจ้งเตือนเมื่อถูกใช้ และเก็บรหัสไว้อย่างปลอดภัย

ไม่แน่ใจว่าองค์กรอยู่ตรงไหน ลองใช้ แบบประเมินตนเอง แล้วเลือกช่องว่างจากรายการด้านบนมาปิดก่อนสองถึงสามข้อ

สิทธิ์ที่ลบหรือปิดงาน backup ได้ควรถูกควบคุมเป็นสิทธิ์พิเศษเช่นกัน ดูตัวอย่างใน กลยุทธ์ Backup 3-2-1-1-0 และ Immutable Backup

การถอนสิทธิ์ผู้ดูแลเครื่องของผู้ใช้เป็นเงื่อนไขที่ baseline ส่วนใหญ่ถือว่าเป็นจริงอยู่แล้ว ดูขั้นตอนปรับตั้งค่าเครื่องได้ใน Endpoint Hardening ด้วย CIS Benchmarks เริ่มอย่างไร

กุญแจเข้ารหัสและบัญชีผู้ดูแลระบบต้องควบคุมการเข้าถึงในแนวเดียวกัน อ่านเพิ่มที่ การเข้ารหัสและ Key Management: KMS, HSM และ BYOK

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

• NIST SP 800-53 Rev. 5: Security and Privacy Controls: ที่มาของมาตรการ AC-2(7), AC-6 และ IA-2(1) ที่อ้างถึงในบทความ
• NIST Glossary: privileged account: นิยามของบัญชีสิทธิ์สูง
• NCSC: Secure system administration: หลักการห้าข้อสำหรับการดูแลระบบอย่างปลอดภัย
• CISA: Enduring Security Framework IAM guidance (มีนาคม 2023): ประกาศฉบับนี้ มีลิงก์ไปยังคู่มือสำหรับผู้ดูแลระบบ
• MITRE ATT&CK T1078: Valid Accounts: เทคนิคการใช้บัญชีที่มีอยู่จริง พร้อมรายการมาตรการลดความเสี่ยง
• CISA Zero Trust Maturity Model: ห้าเสาหลัก รวมถึงตัวตน และสี่ระดับวุฒิภาวะ