Access Principles
หลักการเข้าถึง
ตัวตน สิทธิ์ และประวัติการใช้เป็นคนละส่วน เรียนให้แยกก่อนจัดระบบบัญชี
หัวข้อในบทนี้
ศัพท์ในบทนี้ · กดคำที่ขีดเส้นใต้ในเนื้อหาเพื่อดูความหมายได้ด้วย
- API
- ข้อตกลงวิธีที่โปรแกรมเรียกความสามารถหรือข้อมูลของอีกโปรแกรม
- MFA
- การยืนยันจากปัจจัยคนละชนิดตามระบบ
- SSO
- การใช้บริบทการยืนยันร่วมเพื่อเข้าหลายบริการ
ยืนยันตัวตนแล้ว แต่บทบาท Reader มีสิทธิ์อ่านเท่านั้น จึงแก้ไขเอกสารไม่ได้
ตัวอย่างนโยบาย RBAC แบบย่อ: Reader อ่านได้, Editor อ่านและแก้ไขได้ ทุกคำขอต้องยืนยันตัวตนก่อน ในระบบจริงยังมีขอบเขตทรัพยากร เงื่อนไข และนโยบายอื่นร่วมด้วย
ยืนยันว่าใคร แล้วตรวจว่าเข้าถึงอะไรได้
Authentication ตรวจหลักฐานตัวตน Authorization ตัดสินสิทธิ์ต่อการกระทำและทรัพยากร Accounting เก็บการใช้ตามที่ระบบบันทึก ใช้ปัจจัยต่างประเภท ส่วน ให้ใช้บริบท login กับหลายบริการ Federation ให้ระบบหนึ่งยอมรับข้อมูลตัวตนจากอีกระบบตามความเชื่อถือที่กำหนด
- Provision
สร้างบัญชีและบทบาทจากงานที่มีเจ้าของ กำหนดผู้อนุมัติและวันทบทวน
- Authenticate
ตรวจ authenticator เช่นรหัสผ่านหรือกุญแจ MFA ต้องต่างปัจจัย ไม่ใช่สองรหัสผ่าน
- Authorize
ตรวจคน งานและทรัพยากรทุกจุดที่ต้องป้องกัน Login ผ่านไม่ให้สิทธิ์ทุกอย่าง
- Account / monitor
บันทึกว่าใครทำอะไรเมื่อใดตามขอบเขต log และสิทธิ์อ่าน
- Revoke
ยุติสิทธิ์และบริบทที่เกี่ยวข้องเมื่อเปลี่ยนงาน ออกจากงาน หรือหลักฐานรั่ว
Policy สังเคราะห์ให้ owner อ่านข้อมูลตน ตัวอย่างไม่ได้บอกว่าทุกระบบต้องใช้ owner model เดียวกัน แต่ต้องมีการตรวจทรัพยากรหลังตัวตน
Passkey ช่วยป้องกันการหลอกใช้ credential กับเว็บคนละ origin/RP แต่ยังต้องออกแบบ enrollment, recovery และ session ให้เหมาะ PIN หรือ biometric ใช้ปลด key ในอุปกรณ์ตามแบบที่รองรับ ไม่ใช่ส่ง biometric ให้เว็บไซต์ทุกครั้ง; OTP MFA กับ phishing-resistant authentication ไม่ใช่คำเดียวกัน
ไม่จำเป็นต้องเป็น federation ทุกแบบ และ ไม่ใช่ทุกวิธีจะต้าน phishing เท่ากัน Least privilege ต้องจำกัดทั้งบัญชีคน service account และ workload การเปลี่ยนกลุ่มหรือปิดบัญชีอาจมีผลกับ session และ token ตามวงจรของระบบ จึงต้องตรวจผลจริงหลังถอน
ยืนยันตัวตน อนุญาต และบันทึกการใช้Authentication, Authorization and Accounting · 20.1.1
Authentication ตรวจว่าเป็นใคร Authorization ตรวจว่าทำอะไรได้ Accounting บันทึกการใช้
Authentication ตรวจตัวตน Authorization ตรวจการกระทำ Accounting บันทึกการใช้งาน การ login ผ่านเป็นเพียงขั้นแรก สิทธิ์ควรถูกตรวจตาม resource และ action ไม่ตามหน้าจอที่ client แสดง
คุณคือใคร
คุณทำอะไรได้
ทำอะไรเมื่อใดกับอะไร
ผู้ใช้เข้าระบบได้แต่ไม่ได้สิทธิ์แก้ firewall ต้องถูกปฏิเสธและบันทึก การบันทึก login เพียงอย่างเดียวไม่พออธิบายว่าใครเปลี่ยน rule ต้องเก็บ action กับผู้กระทำด้วย
ที่มาของหัวข้อนี้ · 3 รายการ
คำอธิบายและภาพในหน้านี้เรียบเรียงใหม่ ชื่อบทต้นทางด้านล่างใช้ตรวจที่มา ไม่ได้แทนเนื้อหาที่คุณต้องไปอ่านเพิ่มเพื่อเข้าใจหน้านี้ และไม่ยืนยันว่าทุกประโยคมีอยู่ในคอร์ส
- IT Security: Defense against the digital dark arts · Module 3: The 3 A's of Cybersecurity: Authentication, Authorization, AccountingVideo: Best practices for authenticationIT5.M3.V1
- IT Security: Defense against the digital dark arts · Module 3: The 3 A's of Cybersecurity: Authentication, Authorization, AccountingVideo: Authorization and Access Control MethodsIT5.M3.V10
- IT Security: Defense against the digital dark arts · Module 3: The 3 A's of Cybersecurity: Authentication, Authorization, AccountingVideo: Tracking Usage and AccessIT5.M3.V13
เอกสารหลักที่ใช้ตรวจแนวคิดเพิ่มเติม
สิทธิ์เท่าที่จำเป็นLeast Privilege · 20.1.2
ให้สิทธิ์เฉพาะงานและระยะเวลาที่จำเป็น ลดขอบเขตผลกระทบเมื่อบัญชีมีปัญหา
สิทธิ์ควรมีตามงาน มีเจ้าของ และทบทวนเมื่อหน้าที่เปลี่ยน แยกบัญชีใช้งานทั่วไปกับงาน admin ลดการใช้สิทธิ์สูงตลอดเวลา รวมสิทธิ์ผ่าน role หรือ group ที่ออกแบบตามหน้าที่
งานที่ต้องทำ
สิทธิ์ที่ให้ตรงงาน
ทบทวนและยุติเมื่อไม่ใช้
Helpdesk reset บัญชีบางขอบเขตได้โดยไม่ต้องเป็น domain admin สิทธิ์ชั่วคราวต้องมีวันหมดและการตรวจใช้ มิฉะนั้นคำว่าชั่วคราวกลายเป็นถาวรโดยไม่มีใครทบทวน
ที่มาของหัวข้อนี้ · 1 รายการ
คำอธิบายและภาพในหน้านี้เรียบเรียงใหม่ ชื่อบทต้นทางด้านล่างใช้ตรวจที่มา ไม่ได้แทนเนื้อหาที่คุณต้องไปอ่านเพิ่มเพื่อเข้าใจหน้านี้ และไม่ยืนยันว่าทุกประโยคมีอยู่ในคอร์ส
- Assets, Threats, and Vulnerabilities · Module 2: Protect organizational assetsReading: Principle of least privilegeCY5.M2.R1
ยืนยันหลายปัจจัยและเข้าระบบครั้งเดียวMFA and SSO · 20.1.3
MFA ใช้หลายปัจจัย SSO ลดการล็อกอินซ้ำ แต่ต้องดูระบบตัวตนและ session
ใช้หลักฐานคนละปัจจัย เช่นความรู้ สิ่งที่ถือ หรือชีวมิติ Password สองชุดยังเป็นปัจจัยชนิดเดียว ให้ใช้การยืนยันหนึ่งบริบทเข้าหลายบริการผ่านกลไกที่ไว้ใจร่วมกัน
ชนิดหลักฐานที่เป็นอิสระ
บริบทเดียวใช้หลายบริการ
ปกป้องหลังยืนยันแล้ว
ไม่ได้ต้าน phishing เท่ากันทุกรูปแบบ และ session ที่ถูกขโมยอาจเลี่ยงการยืนยันใหม่ได้ตามระบบ ลดรหัสกระจายแต่ทำให้ identity provider สำคัญ ต้องดู availability และการตอบสนองด้วย
ที่มาของหัวข้อนี้ · 1 รายการ
คำอธิบายและภาพในหน้านี้เรียบเรียงใหม่ ชื่อบทต้นทางด้านล่างใช้ตรวจที่มา ไม่ได้แทนเนื้อหาที่คุณต้องไปอ่านเพิ่มเพื่อเข้าใจหน้านี้ และไม่ยืนยันว่าทุกประโยคมีอยู่ในคอร์ส
- Assets, Threats, and Vulnerabilities · Module 2: Protect organizational assetsReading: The rise of SSO and MFACY5.M2.R11
เอกสารหลักที่ใช้ตรวจแนวคิดเพิ่มเติม
วงจรบัญชีและบทบาทAccount Lifecycle and Roles · 20.1.4
วงจรบัญชีมีสร้าง เปลี่ยนบทบาท ทบทวน และปิด Role ช่วยรวมสิทธิ์ตามหน้าที่
Account lifecycle มีสร้าง เปลี่ยนหน้าที่ ระงับ และยุติ Role กำหนดสิทธิ์ตามงาน การเปลี่ยนทีมต้องลดสิทธิ์เดิมด้วยไม่ใช่เพิ่มใหม่อย่างเดียว รวม service account และ key ที่ไม่ใช่คน
สร้างตามหน้าที่
ปรับสิทธิ์เมื่อหน้าที่เปลี่ยน
ยุติและส่งต่องานที่จำเป็น
พนักงานย้ายฝ่ายแต่ยังเข้าข้อมูลเดิมได้คือสิทธิ์สะสม การยุติคนหนึ่งต้องโอนเจ้าของ automation และข้อมูลที่งานพึ่งก่อน ไม่ปล่อย service หยุดเพราะผูกบัญชีบุคคล
ที่มาของหัวข้อนี้ · 1 รายการ
คำอธิบายและภาพในหน้านี้เรียบเรียงใหม่ ชื่อบทต้นทางด้านล่างใช้ตรวจที่มา ไม่ได้แทนเนื้อหาที่คุณต้องไปอ่านเพิ่มเพื่อเข้าใจหน้านี้ และไม่ยืนยันว่าทุกประโยคมีอยู่ในคอร์ส
- Assets, Threats, and Vulnerabilities · Module 2: Protect organizational assetsReading: Identity and access managementCY5.M2.R12
การเชื่อมระบบตัวตนข้ามบริการFederation · 20.1.5
Federation ใช้ความเชื่อถือระหว่างระบบตัวตนเพื่อเข้าถึงอีกบริการ
Federation ให้บริการหนึ่งเชื่อคำยืนยันจาก identity provider ผ่านข้อตกลง protocol และ configuration เช่น issuer audience signature และอายุ assertion/token บริการปลายทางยังต้องกำหนดสิทธิ์ของตน
ออกคำยืนยัน
เงื่อนไขที่ปลายทางตรวจ
ใช้ตัวตนแล้วบังคับสิทธิ์
Token ลงนามถูกแต่ audience เป็นอีกแอปต้องไม่รับ ต้องตรวจค่าตาม protocol ไม่เพียง decode payload OAuth เน้นการมอบสิทธิ์ ส่วน OIDC เพิ่มการยืนยันตัวตน อย่าสลับความหมายทั้งสอง
Token Purpose and Validation (ใช้ token ให้ตรงวัตถุประสงค์)
OAuth access token ใช้เข้าถึง ตามการมอบสิทธิ์ ส่วน OIDC ID token ให้ client ใช้ข้อมูลการยืนยันตัวตนตาม protocol ไม่ควรสลับเพียงเพราะทั้งสองอาจเป็นข้อความที่ decode ได้ JWT payload อ่านได้ในแบบ signed ทั่วไป การ decode จึงไม่ใช่การตรวจ signature และไม่ได้แปลว่าข้อมูลเข้ารหัส
ผู้รับตรวจ issuer audience อายุ signature และข้อกำหนดของ protocol ด้วยกุญแจและแหล่งที่เชื่อถือ การลงนามถูกแต่ audience เป็นอีกบริการยังไม่ควรรับ และ authorization ต่อ resource ยังต้องทำหลังตรวจ token ไม่แจกทุกสิทธิ์จากการเห็นชื่อผู้ใช้ใน payload
ที่มาของหัวข้อนี้ · คำอธิบายต่อยอด
คำอธิบายและภาพในหน้านี้เรียบเรียงใหม่ ชื่อบทต้นทางด้านล่างใช้ตรวจที่มา ไม่ได้แทนเนื้อหาที่คุณต้องไปอ่านเพิ่มเพื่อเข้าใจหน้านี้ และไม่ยืนยันว่าทุกประโยคมีอยู่ในคอร์ส
เป็นส่วนต่อยอดที่เขียนเพื่อเชื่อมความเข้าใจ ไม่มีชื่อ Video/Reading เฉพาะที่ยืนยันจาก inventory เดิม
เอกสารหลักที่ใช้ตรวจแนวคิดเพิ่มเติม
นำศัพท์มาเชื่อมกับงาน
รหัสผ่านถูกไม่ได้แปลว่ามีสิทธิ์ดูรายงานการเงิน ต้องตรวจ authorization เพิ่ม
สิ่งที่บทนี้เชื่อมไว้
ตัวตน สิทธิ์ และประวัติการใช้เป็นคนละส่วน เรียนให้แยกก่อนจัดระบบบัญชี
ใช้ภาพกับตัวอย่างด้านบนเชื่อมหน้าที่ของแต่ละส่วน แล้วตรวจความเข้าใจด้วยการอธิบายเหตุผลของผลที่เห็น ก่อนเปิดบทถัดไป
บทเรียนที่เกี่ยวข้องและที่มาของบทอ่าน
transcript ที่เคยใช้ตรวจแนวคิดพื้นฐานและตัวอย่างบางส่วน: T0685 · 5.IT Security Defense against the digital dark arts คำอธิบายเป็นการเขียนใหม่ ไม่ใช่การแปลครบทุกประโยค ภาพและตัวอย่างเป็นการเรียบเรียงเพื่อเชื่อมความเข้าใจ
คำอธิบายหน้านี้เขียนใหม่ตามหัวข้อใน Atlas รายการด้านล่างเป็นชื่อ Video/Reading ที่เคยจับคู่ไว้ แสดงไว้ให้ตรวจที่มาของชื่อหัวข้อ และไม่รับรองว่าคอร์สสอนทุกส่วนของคำอธิบายนี้