Proxmox VE Access Control Realm, Identity Management และการกำกับดูแลด้วย RBAC
คู่มือปฏิบัติการวางโครงสร้างการยืนยันตัวตนและการกำหนดสิทธิ์บน Proxmox VE 9.2 ตั้งแต่การเชื่อมต่อ Realm แบบ Microsoft Active Directory และ LDAP การซิงค์ผู้ใช้และกลุ่ม การกำหนดบทบาทผ่านสิทธิ์ระดับเส้นทาง ไปจนถึงการใช้ API Token แบบแยกสิทธิ์สำหรับงานอัตโนมัติ
ปัญหาและโจทย์
ในทางปฏิบัติ ระบบเสมือนจริงขององค์กรมักถูกใช้งานโดยผู้ใช้บัญชีผู้ดูแลระบบร่วมกันตั้งแต่เริ่มติดตั้ง เพราะสะดวกและรวดเร็วเมื่อทีมยังเล็ก แต่เมื่อระบบขยายตัวและมีผู้เกี่ยวข้องมากขึ้น ทั้งทีมไอทีภายใน ผู้รับเหมา และผู้ตรวจสอบภายใน การใช้บัญชีร่วมกันกลับสร้างความเสี่ยงที่ประเมินไม่ได้
ปัญหาที่ตามมาคือ เมื่อเกิดเหตุการณ์ผิดปกติ จะไม่สามารถระบุได้ว่าใครเป็นผู้ดำเนินการ เพราะทุกคนใช้บัญชีเดียวกัน และเมื่อมีพนักงานลาออกหรือย้ายทีม การถอนสิทธิ์ต้องเปลี่ยนรหัสผ่านของทุกคนใหม่ทั้งระบบ ซึ่งกระทบต่อการทำงานโดยไม่จำเป็น
นอกจากนี้ งานอัตโนมัติที่เชื่อมต่อกับระบบเสมือน เช่น ระบบสำรองข้อมูลหรือระบบเฝ้าระวัง มักถูกตั้งค่าให้ใช้บัญชีผู้ดูแลระบบเต็มรูปแบบ เพราะไม่มีกลไกที่ชัดเจนในการจำกัดสิทธิ์ ทำให้บัญชีที่เก็บบนสคริปต์กลายเป็นจุดเปราะบางที่สำคัญที่สุดของระบบ
แนวทางการแก้ปัญหา: Realm, Role และ ACL
Proxmox VE แยกเรื่องการพิสูจน์ตัวตนออกจากเรื่องการกำหนดสิทธิ์อย่างชัดเจน โดยผู้ใช้แต่ละรายถูกระบุในรูปแบบ ชื่อผู้ใช้@ชื่อ Realm และ Realm ที่มีให้เลือกตามเอกสารทางการมีดังนี้
1. Realm ที่รองรับ
- Linux PAM: ใช้บัญชีของระบบปฏิบัติการบนโหนด เป็น Realm ที่มีมาให้ตั้งแต่เริ่มต้นและลบไม่ได้ ผู้ใช้ root จะเข้าสู่ระบบผ่าน Realm นี้เสมอ
- Proxmox VE Authentication Server: แหล่งรหัสผ่านภายในตัวระบบ เหมาะกับระบบขนาดเล็กถึงกลางที่ไม่ต้องการพึ่งพาระบบภายนอก
- LDAP: เชื่อมต่อกับไดเรกทอรี เช่น OpenLDAP โดยค้นหาผู้ใช้ภายใต้ Base Domain Name
- Microsoft Active Directory: ใช้ไดเรกทอรีของโดเมนวินโดวส์เป็นแหล่งยืนยันตัวตน
- OpenID Connect: ยืนยันตัวตนผ่าน Authorization Server ภายนอกตามมาตรฐาน OAuth 2.0
2. โครงสร้างการกำหนดสิทธิ์
- กลุ่ม (Group): เอกสารทางการแนะนำอย่างชัดเจนว่าควรมอบสิทธิ์ให้กลุ่มแทนการมอบให้ผู้ใช้รายบุคคล เพื่อให้ดูแลรักษาง่าย
- บทบาท (Role): ชุดของ Privilege ที่นำไปผูกกับเส้นทางได้ เช่น PVEAuditor สำหรับอ่านอย่างเดียว หรือ PVEVMAdmin สำหรับดูแลเครื่องเสมือน
- เส้นทาง ACL: กำหนดขอบเขตว่าสิทธิ์นั้นมีผลที่ใด เช่น ทั้งระบบ ในกลุ่มเครื่องเสมือน ในกลุ่มผู้ใช้ หรือภายใน Resource Pool
- Resource Pool: ใช้จัดกลุ่มเครื่องเสมือน คอนเทนเนอร์ และสตอเรจ เพื่อมอบสิทธิ์เป็นชุดตามโครงสร้างหน่วยงาน
ข้อมูลผู้ใช้ถูกเก็บที่ใด: คุณลักษณะของผู้ใช้จัดเก็บในไฟล์ /etc/pve/user.cfg ซึ่งเป็นระบบไฟล์ของคลัสเตอร์ ประกอบด้วยชื่อ นามสกุล อีเมล กลุ่มที่สังกัด วันหมดอายุ หมายเหตุ สถานะการใช้งาน และคีย์สำหรับการยืนยันตัวตนสองชั้น โดยตัวรหัสผ่านจะไม่ถูกเก็บไว้ในไฟล์นี้ แต่ผูกกับ Realm ที่ผู้ใช้สังกัด และคอนฟิกของ Realm จัดเก็บที่ /etc/pve/domains.cfg
ขั้นตอนการวางโครงสร้างการยืนยันตัวตนและสิทธิ์
ขั้นที่ 1: เชื่อมต่อ Realm กับระบบไดเรกทอรีขององค์กร
ทำได้จากเมนู Datacenter → Permissions → Realms ผ่านเว็บอินเทอร์เฟซ หรือใช้คำสั่ง pveum ผ่านบรรทัดคำสั่ง สำหรับ Microsoft Active Directory ค่าที่ต้องเตรียมคือชื่อโดเมน ที่อยู่เซิร์ฟเวอร์ พอร์ต และบัญชีที่ใช้ผูกเพื่อค้นหาข้อมูลผู้ใช้
# ตัวอย่างการเชื่อมต่อ Realm แบบ OpenID Connect
pveum realm add myrealm1 --type openid --issuer-url https://accounts.google.com \
--client-id XXXX --client-key YYYY --username-claim email
# ปรับให้การตรวจสอบชื่อผู้ใช้ไม่คำนึงถึงตัวพิมพ์เล็กใหญ่ (เหมาะกับ Microsoft AD)
pveum realm modify myrealm1 --case-sensitive 0
สำหรับ Realm แบบ LDAP และ Active Directory หากเซิร์ฟเวอร์กำหนดให้ระบบต้องยืนยันตัวตนก่อนค้นหาข้อมูล ต้องระบุบัญชีที่ใช้ผูก โดยรหัสผ่านของบัญชีนั้นจะถูกเก็บแยกไว้ในไฟล์เฉพาะภายในไดเรกทอรีที่ผู้ใช้ทั่วไปเข้าถึงไม่ได้ และหากต้องการตรวจสอบใบรับรองของเซิร์ฟเวอร์ ต้องตั้งค่าเส้นทางของ CA และเปิดตัวเลือกการตรวจสอบใบรับรองไว้
ขั้นที่ 2: ซิงค์ผู้ใช้และกลุ่มจากไดเรกทอรี
การซิงค์ช่วยลดภาระการสร้างผู้ใช้ด้วยมือ และลดความผิดพลาดจากการพิมพ์ชื่อผิด การตั้งค่าที่ควรพิจารณาให้รอบคอบคือพฤติกรรมเมื่อผู้ใช้หายไปจากผลการซิงค์ ซึ่งเอกสารทางการให้ตัวเลือกแยกเป็นรายด้าน
| ตัวเลือกการซิงค์ | ความหมายตามเอกสารทางการ |
|---|---|
| scope | ขอบเขตสิ่งที่ซิงค์ ได้แก่ ผู้ใช้ กลุ่ม หรือทั้งสองอย่าง |
| enable-new | เปิดใช้งานผู้ใช้ที่ซิงค์เข้ามาใหม่ทันที ค่าเริ่มต้นคือเปิด |
| remove-vanished | กำหนดว่าจะลบสิ่งใดเมื่อไม่ปรากฏในผลการซิงค์ ได้แก่ สิทธิ์การเข้าถึง (acl) รายการผู้ใช้หรือกลุ่ม (entry) และคุณลักษณะต่าง ๆ (properties) |
| preview (dry-run) | แสดงผลลัพธ์โดยไม่บันทึกข้อมูลจริง ใช้ตรวจสอบก่อนซิงค์จริงทุกครั้ง |
# ตรวจสอบผลลัพธ์ก่อนบันทึกจริง pveum realm sync myrealm1 --dry-run # ซิงค์ผู้ใช้และกลุ่มจริง pveum realm sync myrealm1
ขั้นที่ 3: สร้างกลุ่มและมอบบทบาทตามหน้าที่
แนวปฏิบัติที่เอกสารทางการยกตัวอย่างไว้คือ การสร้างกลุ่มผู้ดูแลระบบที่ทำงานได้เต็มรูปแบบโดยไม่ต้องใช้บัญชี root และการมอบสิทธิ์อ่านอย่างเดียวให้ผู้ตรวจสอบภายใน
# สร้างกลุ่มผู้ดูแลระบบและมอบบทบาท Administrator pveum group add admin -comment "System Administrators" pveum acl modify / -group admin -role Administrator pveum user modify testuser@pve -group admin # มอบสิทธิ์อ่านอย่างเดียวทั้งระบบให้ผู้ตรวจสอบ pveum acl modify / -user joe@pve -role PVEAuditor # จำกัดขอบเขตสิทธิ์อ่านเฉพาะกลุ่มเครื่องเสมือน pveum acl modify /vms -user joe@pve -role PVEAuditor
ขั้นที่ 4: มอบหมายงานบริหารจัดการแบบจำกัดขอบเขต
บทบาท PVEUserAdmin เป็นบทบาทที่ทรงอำนาจ จึงควรจำกัดให้มีผลเฉพาะ Realm และกลุ่มที่ต้องการจริง ๆ โดยเอกสารทางการยกตัวอย่างการให้สิทธิ์ผู้ใช้หนึ่งรายดูแลผู้ใช้ได้เฉพาะใน Realm pve และเฉพาะสมาชิกของกลุ่ม customers เท่านั้น
# มอบหมายงานดูแลผู้ใช้อย่างจำกัดขอบเขต pveum acl modify /access/realm/pve -user joe@pve -role PVEUserAdmin pveum acl modify /access/groups/customers -user joe@pve -role PVEUserAdmin # สร้าง Resource Pool ตามโครงสร้างหน่วยงาน pveum pool add dev-pool --comment "IT development pool" pveum acl modify /pool/dev-pool/ -group developers -role PVEAdmin
ขั้นที่ 5: สร้าง API Token แบบแยกสิทธิ์สำหรับงานอัตโนมัติ
API Token ช่วยให้ระบบภายนอกเข้าถึง REST API ได้โดยไม่ต้องเก็บรหัสผ่านของผู้ใช้ โดยค่าเริ่มต้นของ Token ใหม่คือแบบแยกสิทธิ์ กล่าวคือสิทธิ์ที่ได้จริงเป็นผลจากการตัดกันระหว่างสิทธิ์ของ Token และสิทธิ์ของเจ้าของ Token จึงไม่สามารถทำอะไรเกินกว่าที่เจ้าของทำได้
# เจ้าของ Token มีสิทธิ์ดูแลเครื่องเสมือน pveum acl modify /vms -user joe@pve -role PVEVMAdmin # สร้าง Token แบบแยกสิทธิ์ ให้อ่านข้อมูลได้อย่างเดียวเพื่อใช้เฝ้าระวัง pveum user token add joe@pve monitoring -privsep 1 pveum acl modify /vms -token 'joe@pve!monitoring' -role PVEAuditor # ตรวจสอบสิทธิ์ผลลัพธ์ที่ได้จริง pveum user permissions joe@pve pveum user token permissions joe@pve monitoring
ข้อควรระวังที่เอกสารทางการย้ำไว้: ค่าของ Token จะแสดงให้เห็นเพียงครั้งเดียวในขณะสร้างเท่านั้น ไม่สามารถเรียกดูซ้ำผ่าน API ในภายหลังได้ จึงต้องจัดเก็บอย่างปลอดภัยทันที และควรกำหนดวันหมดอายุให้ Token เพื่อไม่ให้งานอัตโนมัติที่ถูกลืมยังทำงานอยู่โดยที่ไม่มีใครทราบ นอกจากนี้ ปลายทางที่ให้เข้าถึงคอนโซลของเครื่องเสมือนหรือระบบปฏิบัติการไม่สามารถใช้ API Token ได้ ต้องใช้สิทธิ์ของผู้ใช้จริงเท่านั้น
การยืนยันตัวตนสองชั้นและการเฝ้าระวังสิทธิ์
การยืนยันตัวตนสองชั้นกำหนดได้สองระดับ คือระดับ Realm ซึ่งบังคับใช้กับผู้ใช้ทุกคนใน Realm นั้น และระดับผู้ใช้รายบุคคล โดยเอกสารทางการระบุวิธีที่รองรับไว้ดังนี้
- TOTP (Time-based One-Time Password): รหัสที่เปลี่ยนทุก 30 วินาที ตามอัลกอริทึม HMAC-SHA1 โดยเทียบกับเวลาปัจจุบัน
- YubiKey OTP: การยืนยันด้วยอุปกรณ์ฮาร์ดแวร์
- การบังคับใช้ระดับ Realm: เมื่อ Realm เปิดใช้ ผู้ใช้ที่ยังไม่ได้ตั้งค่าปัจจัยที่สองจะไม่สามารถเข้าสู่ระบบได้ และไม่มีวิธีเข้าสู่ระบบโดยไม่ระบุปัจจัยที่สอง
- การกู้คืน: หากป้อนรหัส TOTP ผิดติดต่อกัน 8 ครั้ง ปัจจัย TOTP ของผู้ใช้จะถูกปิด และจะปลดล็อกได้ด้วยการเข้าสู่ระบบด้วยรหัสกู้คืน หาก TOTP เป็นปัจจัยเดียวที่มี จำเป็นต้องให้ผู้ดูแลระบบเข้าช่วย
ในมุมของการกำกับดูแล การตรวจสอบสิทธิ์ไม่ควรดูเฉพาะว่าผู้ใช้แต่ละรายได้รับบทบาทอะไร แต่ต้องดูผลลัพธ์ที่รวมกันแล้วด้วย โดยเฉพาะผู้ใช้ที่ได้รับสิทธิ์จากหลายเส้นทางพร้อมกัน
# ตรวจสอบสิทธิ์ที่ผู้ใช้ได้รับจริงในทุกเส้นทาง pveum user permissions testuser@pve # รายการบทบาทและสิทธิ์ที่บทบาทนั้นประกอบด้วย pveum role list # สร้างบทบาทเฉพาะกิจสำหรับงานที่จำกัดขอบเขต pveum role add PVE_Power-only -privs "VM.PowerMgmt VM.Console"
ผลลัพธ์และประโยชน์
- ตรวจสอบย้อนกลับได้: ทุกการดำเนินการผูกกับบัญชีผู้ใช้รายบุคคล ทำให้ระบุผู้รับผิดชอบได้ชัดเจน
- ลดภาระงานบริหาร: การถอนสิทธิ์เมื่อพนักงานลาออกทำได้ที่ระบบไดเรกทอรีเพียงจุดเดียว
- จำกัดความเสียหายเมื่อถูกโจมตี: API Token แบบแยกสิทธิ์ทำให้บัญชีสำหรับงานอัตโนมัติไม่สามารถทำอะไรเกินขอบเขตที่กำหนด
- ยกระดับการตรวจสอบภายใน: การมอบสิทธิ์แบบอ่านอย่างเดียวให้ผู้ตรวจสอบภายในทำได้โดยไม่กระทบต่อการทำงานจริง
จุดเด่นของเรา
- ออกแบบโครงสร้างสิทธิ์จากผังองค์กร: เราเริ่มจากการทำความเข้าใจบทบาทหน้าที่ของแต่ละทีม แล้วจึงแปลงเป็นกลุ่ม บทบาท และเส้นทาง ACL ที่ตรวจสอบได้
- เชื่อมต่อไดเรกทอรีขององค์กรโดยไม่กระทบระบบเดิม: ทดสอบการซิงค์ในโหมดตรวจสอบก่อนเสมอ เพื่อไม่ให้เกิดการลบผู้ใช้หรือสิทธิ์โดยไม่ตั้งใจ
- วางแนวปฏิบัติสำหรับงานอัตโนมัติ: กำหนดนโยบายการออก Token การตั้งวันหมดอายุ และการทบทวนสิทธิ์เป็นรอบ
- สอดคล้องกรอบความมั่นคงปลอดภัย: ช่วยรองรับข้อกำหนดด้านการควบคุมการเข้าถึงของกรอบ NIST Cybersecurity Framework ที่องค์กรใช้อ้างอิงอยู่แล้ว
ต้องการวางโครงสร้างสิทธิ์บนระบบเสมือนให้ตรวจสอบได้หรือไม่
หากองค์กรของคุณกำลังเตรียมพร้อมสำหรับการตรวจสอบภายใน หรือต้องการแยกสิทธิ์ผู้ดูแลระบบออกจากกันอย่างชัดเจนบน Proxmox Virtual Environment ทีมวิศวกรของเราพร้อมร่วมออกแบบโครงสร้าง Realm กลุ่ม บทบาท และนโยบาย Token ให้สอดคล้องกับโครงสร้างองค์กรของท่าน