บทความนี้ได้รับแรงบันดาลใจจากการดำเนินงานแพลตฟอร์ม Identity และ Access Management ในบริการทางการเงินที่มีการกำกับดูแลอย่างเข้มงวด ซึ่งการกำหนดสิทธิ์ที่ไม่ถูกต้องอาจกลายเป็นข้อบกพร่องในการตรวจสอบได้
เมื่อต้องอธิบายและตรวจสอบการเข้าถึง การระบุว่า “ใครสามารถแตะต้องทรัพยากรนี้ได้บ้าง” จะต้องเป็นความสัมพันธ์ที่สามารถสอบถามพร้อมประวัติย้อนหลังได้ เนื่องจากผู้ตรวจสอบอาจต้องการทราบสถานะเมื่อหกเดือนที่แล้วเช่นเดียวกับปัจจุบัน
การออกแบบที่เหมาะสมต้องสามารถตอบคำถาม เช่น “ใครเข้าถึงระบบนี้เมื่อวันที่ 14 มีนาคม?” ได้จากโมเดลข้อมูลเพียงอย่างเดียว โดยไม่ต้องค้นหาบันทึกจากหลายเครื่องมือ
ในกรณีของ Service Accounts ที่มีเจ้าของจำนวนมาก การรวมศูนย์ขั้นตอนการเพิกถอนสิทธิ์จากสามเครื่องมือที่ใช้เวลาสามวัน ให้เหลือเพียงเวิร์กโฟลว์เดียวที่ใช้เวลาไม่ถึงหนึ่งวันนั้นเป็นตัวอย่างของการปรับปรุงที่สำคัญ
การส่งผ่านตัวตนข้ามขอบเขตบริการทำได้โดยใช้การแลกเปลี่ยนโทเค็น OAuth 2.0 ซึ่งจะทำให้โทเค็นที่บริการหนึ่งใช้แทนผู้เรียกนั้นมีความจำกัดมากขึ้น แทนที่จะใช้โทเค็นที่กว้างเกินไป
การเพิกถอนสิทธิ์ผ่าน Kafka ทำให้การเข้าถึงที่หมดอายุนั้นยุติลงอย่างรวดเร็วตามอายุสูงสุดที่กำหนด แต่ทุกครั้งที่หมดอายุจะต้องมีการตรวจสอบกลับไปยังแหล่งข้อมูลที่เชื่อถือได้
การตัดสินใจว่าเมื่อใดที่สิ่งเหล่านี้เป็นเรื่องเกินความจำเป็นนั้นขึ้นอยู่กับองค์กร เช่น บริการจำนวนมาก การที่ Service Accounts มีจำนวนมากกว่าและมีอายุยาวนานกว่าผู้ดูแล หรือภาระผูกพันในการตรวจสอบที่มีผลบังคับใช้จริง
ศัพท์ที่ควรรู้
- Identity and Access Management (IAM) – ระบบที่จัดการตัวตนและการเข้าถึงของผู้ใช้ในองค์กร
- Audit finding – ข้อบกพร่องที่ถูกพบระหว่างการตรวจสอบทางการเงิน
- Flat RBAC – รูปแบบการควบคุมการเข้าถึงตามบทบาทแบบพื้นฐานที่อาจมีข้อจำกัด
- Service Accounts – บัญชีที่ถูกสร้างขึ้นสำหรับบริการต่าง ๆ เพื่อให้ทำงานแทนผู้ใช้
- OAuth 2.0 token exchange – กลไกการแลกเปลี่ยนโทเค็นที่ใช้ในการยืนยันตัวตนระหว่างบริการ
ที่มา: infoq.com