ชื่อผู้ใช้และรหัสผ่านตอบได้เพียงบางส่วนของคำถามเรื่องการเข้าถึง ธุรกิจอาจต้องรู้ด้วยว่าผู้ใช้ทำ MFA แล้วหรือไม่ อุปกรณ์ได้รับการจัดการหรือไม่ และคำขอมาจากตำแหน่งที่คาดไว้หรือไม่
Microsoft Entra Conditional Access นำสัญญาณเหล่านั้นมาใช้ในการตัดสินใจตามนโยบาย เมื่อ Odoo ใช้ Microsoft Entra เป็นผู้ให้บริการข้อมูลประจำตัว Conditional Access จะประเมินการลงชื่อเข้าใช้ของ Microsoft ก่อนที่ผู้ใช้จะกลับไปยัง Odoo
สิ่งนี้ทำให้การยืนยันตัวตนของ Odoo สอดคล้องกับสภาพแวดล้อมที่บริหารจัดการด้วย Microsoft มากขึ้น แต่ก็อาจล็อกผู้ใช้ที่ถูกต้องออกได้หากตั้งค่าอย่างไม่รอบคอบ เป้าหมายคือใช้นโยบายอย่างพอเหมาะและเหมาะกับกลุ่มผู้ใช้ Odoo และข้อมูล
Conditional Access ทำอะไรได้จริง
Microsoft อธิบายว่า Conditional Access คือกลไกนโยบาย Zero Trust ของตน นโยบายทำงานเหมือนคำสั่ง if-then คือเมื่อเงื่อนไขที่กำหนดตรงกัน Entra จะใช้อินเทอร์แอคชันการเข้าถึงที่กำหนดไว้ ภาพรวมอย่างเป็นทางการของ ภาพรวม Conditional Access ระบุสัญญาณที่ใช้บ่อย ได้แก่ ผู้ใช้และกลุ่ม ตำแหน่ง IP อุปกรณ์ แอปพลิเคชัน และความเสี่ยงแบบเรียลไทม์หรือความเสี่ยงที่คำนวณได้
การควบคุมการอนุญาตสามารถกำหนดให้ต้องมี:
- การยืนยันตัวตนหลายปัจจัย
- ความแข็งแกร่งของการยืนยันตัวตนที่กำหนดไว้
- อุปกรณ์ที่ถูกทำเครื่องหมายว่าเป็นไปตามข้อกำหนด
- อุปกรณ์ที่เข้าร่วมแบบ hybrid กับ Microsoft Entra
- แอปพลิเคชันไคลเอนต์ที่ได้รับอนุญาตหรือนโยบายการปกป้องแอป
- การเปลี่ยนรหัสผ่านหรือการยอมรับเงื่อนไขการใช้งาน
นโยบายยังสามารถบล็อกการเข้าถึงได้ หลายนโยบายอาจมีผลกับการลงชื่อเข้าใช้เดียวกัน และ Microsoft อธิบายว่าต้องปฏิบัติตามข้อกำหนดของนโยบายทั้งหมดที่เกี่ยวข้อง ดู วิธีประเมินนโยบาย Conditional Access.
รูปแบบนโยบายที่ใช้ได้จริงสำหรับ Odoo
กำหนดให้ MFA สำหรับผู้ใช้ Odoo ที่มีสิทธิ์สูง
ผู้ดูแลระบบ Odoo เจ้าหน้าที่การเงิน และผู้ใช้ที่สามารถส่งออกบันทึกข้อมูลสำคัญเป็นกลุ่มเป้าหมายที่เหมาะสมสำหรับการยืนยันตัวตนที่เข้มแข็งกว่า Microsoft Entra MFA กำหนดให้ใช้วิธีการยืนยันอย่างน้อยสองวิธีจากคนละหมวดปัจจัย ตามที่อธิบายไว้ใน เอกสาร MFA ของ Microsoft
อย่าคิดว่าวิธี MFA ทุกแบบให้การป้องกันเท่ากัน Microsoft แนะนำตัวเลือกที่ต้านฟิชชิงได้ เช่น passkeys, คีย์ความปลอดภัย FIDO2, Windows Hello for Business และการยืนยันตัวตนแบบใช้ใบรับรอง ใน ภาพรวมการยืนยันตัวตน ของตน
ลำดับที่เหมาะสมในทางปฏิบัติอาจเป็นการกำหนดให้ MFA สำหรับผู้ใช้ทุกคนในองค์กร จากนั้นกำหนดความแข็งแกร่งของการยืนยันตัวตนที่ต้านฟิชชิงได้สำหรับกลุ่มที่มีสิทธิ์สูง ลำดับที่เหมาะสมขึ้นอยู่กับอุปกรณ์ที่มีอยู่ ความพร้อมในการลงทะเบียน และกำลังของทีมสนับสนุน
กำหนดให้อุปกรณ์เหมาะสม
Conditional Access สามารถกำหนดให้ใช้อุปกรณ์ที่เป็นไปตามข้อกำหนดหรือที่เข้าร่วมแบบ hybrid ได้ ซึ่งมีประโยชน์เมื่อ Odoo เปิดเผยข้อมูลการเงิน ข้อมูลพนักงาน หรือข้อมูลการปฏิบัติงานที่ไม่ควรถูกดาวน์โหลดจากอุปกรณ์ที่ไม่ได้รับการจัดการ
ทดสอบการตัดสินใจนี้กับผู้ใช้จริง ผู้รับเหมา เวิร์กสเตชันที่ใช้ร่วมกัน และผู้ใช้บนมือถืออาจไม่เหมาะกับนโยบายที่ออกแบบมาสำหรับแล็ปท็อปของพนักงาน การปฏิบัติตามข้อกำหนดของอุปกรณ์ยังขึ้นอยู่กับการตั้งค่าและสิทธิ์การใช้งานของ Microsoft ที่เกี่ยวข้อง
ใช้ตำแหน่งเป็นเพียงสัญญาณ ไม่ใช่หลักฐานยืนยันตัวตน
Conditional Access สามารถบล็อกหรืออนุญาตการเข้าถึงตามตำแหน่งและช่วง IP ที่กำหนดไว้ ซึ่งช่วยลดความเสี่ยงได้เมื่อองค์กรดำเนินงานในพื้นที่ภูมิศาสตร์จำกัดหรือมีที่อยู่ egress ขององค์กรที่ทราบแน่นอน
ตำแหน่งไม่ใช่หลักฐานยืนยันตัวตน พนักงานเดินทาง การเชื่อมต่อมือถือเปลี่ยนแปลงได้ และผู้โจมตีสามารถใช้อินฟราสตรักเจอร์ในภูมิภาคที่อนุญาตได้ ผสานสิ่งนี้เข้ากับการยืนยันตัวตนที่เข้มแข็งและการควบคุมอุปกรณ์
ใช้นโยบายตามความเสี่ยงเมื่อมีสิทธิ์ใช้งาน
Microsoft Entra ID Protection สามารถส่งข้อมูลความเสี่ยงของผู้ใช้และการลงชื่อเข้าใช้ไปยัง Conditional Access ได้ Microsoft ระบุว่า Conditional Access แบบอิงความเสี่ยงต้องใช้ Entra ID P2 ซึ่งช่วยรองรับการตอบสนองที่เข้มงวดขึ้นต่อการลงชื่อเข้าใช้ที่มีความเสี่ยง แต่ฟีเจอร์นี้ไม่ได้รวมอยู่ในไลเซนส์ Entra ทุกแบบ
Conditional Access ประเมินสัญญาณที่มีอยู่ในช่วงการออกโทเค็น มันไม่ได้ตรวจสอบทุกการกระทำที่ผู้ใช้ทำภายหลังภายใน Odoo
Conditional Access และขอบเขตเซสชันของ Odoo
Conditional Access ทำงานระหว่างการยืนยันตัวตนของ Microsoft และการออกโทเค็น หลังจาก Odoo ตรวจสอบผลลัพธ์และสร้างเซสชันของตนเองแล้ว พฤติกรรมเซสชันของ Odoo ก็ยังมีความสำคัญ
ตัวอย่างเช่น การนำผู้ใช้ออกจากกลุ่มที่กำหนดเป้าหมายไว้จะไม่เปลี่ยนโทเค็นที่ออกไปแล้วโดยอัตโนมัติ เอกสารนโยบายของ Microsoft เอกสารนโยบาย ระบุว่า บทบาทหรือสมาชิกกลุ่มที่เพิ่งถูกเพิ่มเข้ามาจะอยู่ภายใต้นโยบายเมื่อมีการออกโทเค็นใหม่ ในทำนองเดียวกัน การเชื่อมต่อที่ซิงค์กลุ่ม Odoo เมื่อมีการลงชื่อเข้าใช้ไม่ได้หมายความว่าจะเพิกถอนเซสชัน Odoo ที่กำลังใช้งานอยู่ทันทีเสมอไป
ดังนั้น การออกแบบของคุณควรครอบคลุม:
- อายุการใช้งานเซสชัน Odoo และพฤติกรรมการออกจากระบบ
- ความเร็วในการอัปเดตการแมปการเข้าถึงของ Odoo
- ขั้นตอนการเพิกถอนฉุกเฉิน
- ผลของการปิดใช้งานบัญชี Microsoft
- การใช้การลงชื่อเข้าใช้แบบโต้ตอบเฉพาะ Microsoft เหมาะสมหรือไม่
- ผู้ดูแลระบบจะกลับมาเข้าถึงได้อย่างไรระหว่างที่ผู้ให้บริการข้อมูลประจำตัวล่ม
วางแผนการเปิดใช้งานก่อนบังคับใช้นโยบาย
คู่มือการปรับใช้ Conditional Access Deployment Guide ของ Microsoft แนะนำให้วางแผน ใช้ผู้ใช้ทดสอบ สื่อสารการเปลี่ยนแปลง และตรวจสอบให้แน่ใจว่าผู้ใช้สามารถลงทะเบียน MFA ได้ก่อนเริ่มบังคับใช้
สำหรับการนำ Odoo ไปใช้งานจริง ลำดับที่เหมาะสมคือ:
- ลงทะเบียนการเชื่อมต่อ Odoo และตรวจสอบ callback, ข้อมูล discovery และ signing keys
- ทดสอบการลงชื่อเข้าใช้ Microsoft ด้วยบัญชีที่ไม่ใช่ผู้ดูแลระบบ
- ยืนยันการจับคู่บัญชี Odoo และผลลัพธ์ของ access-group
- กำหนดกลุ่มนำร่องขนาดเล็กด้วยนโยบาย Conditional Access ที่ต้องการ
- ตรวจสอบบันทึกการลงชื่อเข้าใช้และข้อเสนอแนะจากฝ่ายสนับสนุน
- ขยายกลุ่มผู้ใช้ทีละน้อย
- เปิดใช้งานการเข้าสู่ระบบเชิงโต้ตอบด้วย Microsoft เท่านั้น เฉพาะหลังจากที่ได้จัดทำเอกสารและทดสอบการเข้าถึงฉุกเฉินแล้ว
หลีกเลี่ยงการยกเว้นแบบกว้าง ใช้ข้อยกเว้นที่จำเป็นน้อยที่สุด บันทึกผู้รับผิดชอบ และกำหนดวันที่ทบทวน
ทำความเข้าใจขอบเขตของไลเซนส์
Conditional Access ต้องใช้ Microsoft Entra ID P1 Microsoft 365 Business Premium ก็มีความสามารถของ Conditional Access รวมอยู่ด้วยเช่นกัน Conditional Access ที่อิงความเสี่ยงต้องใช้ Entra ID P2 การควบคุมอื่น ๆ อาจขึ้นอยู่กับผลิตภัณฑ์แยกต่างหาก รวมถึง Microsoft Intune หรือ Defender for Cloud Apps รายละเอียดล่าสุดดูได้ใน ข้อกำหนดไลเซนส์ของ Conditional Access.
องค์กรที่ไม่มี P1 หรือ P2 สามารถใช้ security defaults ของ Microsoft เป็นพื้นฐานความปลอดภัยเบื้องต้นได้ แต่นโยบายของ Microsoft ระบุว่า security defaults และ Conditional Access ไม่ได้ออกแบบมาให้ใช้ร่วมกัน อย่าสร้างแผนการเข้าถึง Odoo โดยอาศัยฟีเจอร์ใดฟีเจอร์หนึ่งจนกว่าจะยืนยันไลเซนส์และการตั้งค่าของ tenant แล้ว
เชื่อมโยงนโยบายกับการกำหนดสิทธิ์ใน Odoo
Conditional Access จะกำหนดว่า Microsoft จะดำเนินการลงชื่อเข้าใช้ต่อหรือไม่ ส่วนกลุ่มของ Odoo จะกำหนดสิ่งที่เกิดขึ้นหลังผู้ใช้เข้าสู่ Odoo การเชื่อมโยงแต่ละชั้นอย่างรอบคอบจะช่วยสร้างโมเดลที่ชัดเจนขึ้น, Entra ควบคุมเงื่อนไขการตรวจสอบสิทธิ์ ขณะที่กลุ่มที่อนุมัติแล้วหรือ app roles จะเชื่อมไปยังสิทธิ์การเข้าถึง Odoo ที่เฉพาะเจาะจง
อ่าน การรวมศูนย์การเข้าถึง Odoo ด้วย Microsoft Entra groups และ app roles สำหรับด้านการกำหนดสิทธิ์ หากคุณยังตัดสินใจไม่ได้ว่า SSO คุ้มค่าหรือไม่ ให้เริ่มจาก ทำไมคุณควรปกป้อง Odoo instance ของคุณด้วย Microsoft SSO.
ใช้การควบคุมการลงชื่อเข้าใช้ของ Microsoft กับ Odoo 19
ของเรา โมดูล Microsoft Entra SSO สำหรับ Odoo มอบการเชื่อมต่อ Odoo 19 กับ Microsoft Entra ID หรือ External ID แบบมีขั้นตอนแนะนำ โดยจะตรวจสอบข้อมูล discovery และ signing keys ของ Microsoft รองรับการทดสอบการลงชื่อเข้าใช้แบบโต้ตอบ และสามารถกำหนดให้ผู้ใช้แบบโต้ตอบต้องลงชื่อเข้าใช้ด้วย Microsoft ได้หลังจากยืนยันการเชื่อมต่อแล้ว
โมดูลนี้ช่วยเปิดใช้งานการเชื่อมต่อ แต่ไม่ได้สร้างนโยบาย Conditional Access ที่ถูกต้องให้โดยอัตโนมัติ หรือทำให้ไม่ต้องทดสอบเซสชันและสิทธิ์ของ Odoo โปรดพิจารณาโมดูลนี้หากคุณต้องการจุดเชื่อมต่อที่ควบคุมได้ ซึ่งนโยบาย Entra ที่มีอยู่ของคุณสามารถกำกับการลงชื่อเข้าใช้ Odoo ได้