พิสูจน์ระบบ Zero Trust ด้วย Microsoft Entra ID และ Cloudflare Access
เจาะลึกการจำลองสถาปัตยกรรม Zero Trust แบบครบวงจรผ่าน Terraform ครอบคลุมทั้งโปรโตคอล OIDC และ SAML เพื่อทดสอบจุดพังของระบบที่มักมองข้าม
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- จำลองระบบ Zero Trust ด้วย Terraform ครอบคลุม Entra ID และ Cloudflare Access ทั้ง OIDC และ SAML
- ทดสอบเคสจริงของ Carol เพื่อพิสูจน์การทำงานของเงื่อนไขนโยบายแบบซับซ้อน
- แก้ไขปัญหาการยินยอมของแอดมิน (Admin Consent) และการจัดการกลุ่มผ่าน GUID โดยอัตโนมัติ
บทความส่วนใหญ่เกี่ยวกับ Zero Trust มักจะหยุดอยู่แค่ขั้นตอนที่ว่าผู้ใช้ล็อกอินสำเร็จและเข้าถึงระบบได้ แต่ในความเป็นจริง ระบบมักจะล่มในจุดที่คาดไม่ถึง เช่น สมาชิกกลุ่มที่ไม่ตรงกับนโยบายพอดี การยินยอมของแอดมินที่ไม่เคยถูกตั้งค่าจนกระทั่งมีคนล็อกอินจริง หรือกฎเรื่องประเทศที่ดันทำงานผิดพลาดจากเงื่อนไขที่ควรจะเป็น OR แต่กลายเป็น AND โครงการนี้จึงถูกสร้างขึ้นมาเพื่อแก้ปัญหาดังกล่าว
ผู้พัฒนาได้สร้างเดโมที่จัดการผ่าน Terraform ทั้งหมด เพื่อให้โหมดความล้มเหลวเหล่านี้มองเห็นได้จริงไม่ใช่แค่ทฤษฎี โดยใช้ Microsoft Entra ID ขับเคลื่อนการให้สิทธิ์ของ Cloudflare Access ผ่านทั้ง OIDC และ SAML สำหรับผู้ใช้สามคน และตรวจสอบยืนยันตัวตนที่ต้นทางอย่างแท้จริง ทุกอย่างถูกจัดเตรียมไว้ด้วยคำสั่งเดียวผ่าน Terraform ตั้งแต่การลงทะเบียนแอปพลิเคชัน เดโมยูสเซอร์ กลุ่ม สิทธิ์แอดมิน ไปจนถึงทันเนลเฉพาะและนโยบายความปลอดภัย
การเชื่อมต่อระหว่าง Entra ID และ Cloudflare Access มักมีความซับซ้อนในทางปฏิบัติ เนื่องจากความแตกต่างของโปรโตคอลและการจัดการสิทธิ์ระดับกลุ่ม การใช้ Terraform ช่วยตัดปัญหาความผิดพลาดจากการตั้งค่าด้วยมือผ่านหน้าพอร์ทัล (Portal Click) ซึ่งมักนำไปสู่ปัญหาการล็อกอินล้มเหลวในภายหลัง
ระบบมีการลงทะเบียน Entra กับ Cloudflare สองครั้ง ครั้งแรกผ่านเนทีฟ OIDC คอนเนกเตอร์ที่ดึงข้อมูลสมาชิกกลุ่มแบบเรียลไทม์ผ่าน Microsoft Graph และครั้งที่สองในฐานะแอปพลิเคชัน SAML 2.0 ทั่วไปที่ส่งข้อมูลสมาชิกกลุ่มมาพร้อมกับการยืนยันตัวตน เพื่อให้เห็นการทำงานเทียบเคียงกันระหว่างสองโปรโตคอลภายใต้ตัวตนเดียวกัน ตัวอย่างเช่น การทดสอบผู้ใช้ชื่อ Carol ซึ่งผ่านเงื่อนไขการรวมกลุ่ม (Include) ของแผนกวิศวกรรม แต่ถูกปฏิเสธการเข้าถึงเพราะเงื่อนไขบังคับ (Require) ต้องเป็นสมาชิกทีม On-call ด้วย ซึ่งสะท้อนการทำงานของนโยบายแบบซับซ้อนได้อย่างชัดเจน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
นอกจากนี้ ระบบยังมีการตั้งค่านโยบายปฏิเสธ (Deny Policy) ที่ลำดับความสำคัญ 1 เพื่อตัดตอนก่อนการประเมินกฎอนุญาต รวมถึงการแจ้งเตือนเหตุผลในการเข้าถึง เซสชันความยาว 30 นาที และนโยบายยกเว้นเส้นทางสำหรับ /health ที่อนุญาตให้เข้าถึงได้โดยไม่ต้องยืนยันตัวตน ในส่วนของการตรวจสอบที่ต้นทาง (Origin) จะทำหน้าที่ถอดรหัสและตรวจสอบ JWT Assertion พร้อมทั้งตรวจสอบกลุ่มและโทเค็น เพื่อให้มั่นใจว่าคำขอที่เข้ามาผ่านนโยบายความปลอดภัยจริงๆ ไม่ใช่แค่การเข้าถึงผ่านช่องทางอื่น
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น