ทำไมคุณควรปกป้องอินสแตนซ์ Odoo ของคุณด้วย Microsoft SSO

Odoo มักเก็บข้อมูลที่สำคัญต่อทั้งองค์กรไว้ ไม่ว่าจะเป็นบันทึกลูกค้า กิจกรรมการขาย ใบแจ้งหนี้ รายละเอียดพนักงาน โปรเจ็กต์ สินค้าคงคลัง และเอกสารปฏิบัติงาน การเข้าถึงข้อมูลเหล่านี้สมควรได้รับความใส่ใจเช่นเดียวกับการเข้าถึงอีเมล ไฟล์ และระบบธุรกิจหลักอื่นๆ

แต่ Odoo ก็อาจกลายเป็นเกาะเดี่ยวด้านข้อมูลประจำตัวได้ พนักงานอาจมีรหัสผ่านหนึ่งชุดสำหรับ Microsoft 365 และอีกชุดสำหรับ Odoo ผู้ดูแลระบบอาจต้องจัดการสิทธิ์การเข้าถึงในหลายที่ เมื่อมีใครเปลี่ยนบทบาทหรือออกจากบริษัท กระบวนการอาจขึ้นอยู่กับการตรวจสอบให้แน่ใจว่าทุกแอปพลิเคชันทำตามรายการตรวจสอบได้อย่างถูกต้อง

การลงชื่อเข้าใช้ครั้งเดียวของ Microsoft เป็นอีกทางเลือกหนึ่งสำหรับองค์กร โดยการเชื่อมต่อ Odoo กับ Microsoft Entra ID ผู้ใช้สามารถยืนยันตัวตนผ่านบัญชี Microsoft ของตน และธุรกิจสามารถนำการควบคุมข้อมูลประจำตัวของ Microsoft ที่มีอยู่แล้วมาใช้กับขั้นตอนการลงชื่อเข้าใช้ Odoo ได้

โครงสร้างข้อมูลประจำตัวของ Microsoft ของคุณอาจมีอยู่แล้ว

หากองค์กรของคุณใช้ Microsoft 365 โดยปกติแล้วจะมี Microsoft Entra workforce tenant อยู่แล้ว Microsoft อธิบายว่า workforce tenant จะถูกสร้างขึ้นสำหรับพนักงาน แอปพลิเคชันภายใน และทรัพยากรขององค์กร เมื่อธุรกิจสมัครใช้บริการคลาวด์ของ Microsoft เช่น Microsoft 365 ซึ่งทำให้ Entra เป็นผู้ให้บริการข้อมูลประจำตัวที่เหมาะสมสำหรับ Odoo ที่ควรพิจารณา แทนที่จะนำระบบบัญชีแบบแยกต่างหากอีกระบบเข้ามา ดูคำอธิบายของ Microsoft เกี่ยวกับ การกำหนดค่า workforce และ external tenant.

Odoo ก็รองรับกรณีการใช้งานนี้เช่นกัน เอกสารทางการ Odoo 19 Microsoft Azure sign-in documentation อธิบายว่าผู้ใช้ Odoo สามารถลงชื่อเข้าใช้ด้วยบัญชี Microsoft ได้อย่างไร และยังระบุชัดเจนว่าจำเป็นต้องกำหนดค่าทั้งสองฝั่งของการผสานการทำงาน

ประโยชน์ที่ใหญ่กว่าคือ Microsoft กลายเป็นจุดที่องค์กรสามารถบังคับใช้นโยบายการยืนยันตัวตนก่อนที่เซสชันของ Odoo จะเริ่มต้นขึ้น

เพิ่มการยืนยันตัวตนที่แข็งแกร่งขึ้นให้กับเส้นทางการลงชื่อเข้าใช้ Odoo

Microsoft Entra multifactor authentication สามารถกำหนดให้มีการยืนยันตัวตนตั้งแต่สองรูปแบบขึ้นไปได้ ปัจจัยเหล่านี้อาจรวมถึงสิ่งที่ผู้ใช้รู้ สิ่งที่ผู้ใช้มี หรือสิ่งที่ผู้ใช้เป็น Microsoft อธิบายว่ากระบวนการท้าทายดังกล่าวจัดการเป็นส่วนหนึ่งของกระบวนการลงชื่อเข้าใช้ Entra ไว้อย่างไรใน ภาพรวม MFA.

เมื่อ Odoo ส่งต่อการลงชื่อเข้าใช้ไปยัง Entra องค์กรสามารถกำหนดให้ใช้วิธี MFA ที่ได้รับอนุมัติได้ นอกจากนี้ยังสามารถผลักดันผู้ใช้บางกลุ่มไปสู่วิธีที่ต้านทานฟิชชิงได้ เช่น passkeys, FIDO2 security keys, Windows Hello for Business หรือการยืนยันตัวตนด้วยใบรับรอง Microsoft แนะนำวิธีเหล่านี้ไว้ใน คำแนะนำด้านการยืนยันตัวตน.

ความแตกต่างนี้สำคัญ MFA แบบดั้งเดิมโดยทั่วไปปลอดภัยกว่าการเข้าถึงด้วยรหัสผ่านเพียงอย่างเดียว แต่ไม่ใช่วิธี MFA ทุกแบบที่จะต้านทานฟิชชิงได้ NIST ระบุว่ารหัสผ่านไม่ต้านทานฟิชชิง และรหัสแบบใช้ครั้งเดียวที่ป้อนด้วยตนเองก็ไม่ต้านทานฟิชชิง เพราะผู้โจมตีสามารถส่งต่อรหัสเหล่านั้นได้ NIST ระบุให้ WebAuthn ซึ่งใช้โดยตัวตรวจสอบ FIDO2 เป็นตัวอย่างของการต้านทานฟิชชิงผ่านการผูกกับโดเมน รายละเอียดมีอยู่ใน NIST SP 800-63B-4.

การผสาน SSO ทำให้องค์กรมีเส้นทางในการใช้ความสามารถของ Entra เหล่านี้กับ Odoo ได้ แต่ธุรกิจยังต้องเปิดใช้งานและบังคับใช้นโยบายที่เหมาะสมอยู่ดี

ตัดสินใจการเข้าถึงด้วยบริบทที่มากขึ้น

Microsoft Entra Conditional Access สามารถประเมินสัญญาณต่างๆ เช่น ผู้ใช้ กลุ่ม แอปพลิเคชัน ตำแหน่ง สถานะอุปกรณ์ และความเสี่ยงในการลงชื่อเข้าใช้ จากนั้นจึงสามารถบล็อกการเข้าถึงหรือกำหนดให้ใช้การควบคุม เช่น MFA ความแข็งแกร่งในการยืนยันตัวตนแบบเฉพาะ หรืออุปกรณ์ที่เป็นไปตามข้อกำหนด Microsoft เรียก Conditional Access ว่าเป็นกลไกนโยบาย Zero Trust และอธิบายสัญญาณและการตัดสินใจที่มีอยู่ไว้ใน ภาพรวม Conditional Access.

สำหรับการติดตั้งใช้งาน Odoo สิ่งนี้สามารถรองรับนโยบายต่างๆ เช่น:

• กำหนดให้ผู้ดูแลระบบ Odoo และผู้ใช้ฝ่ายการเงินต้องใช้ MFA
• กำหนดให้บทบาทระดับสิทธิ์ใช้ความแข็งแกร่งในการยืนยันตัวตนที่ต้านทานฟิชชิงได้
• บล็อกการลงชื่อเข้าใช้ Odoo จากตำแหน่งที่ธุรกิจไม่ได้ให้บริการ
• กำหนดให้อุปกรณ์ต้องเป็นไปตามข้อกำหนดหรือเป็นอุปกรณ์ที่มีการจัดการสำหรับการเข้าถึงภายในที่มีความละเอียดอ่อน
• ใช้นโยบายที่เข้มงวดกว่าในการลงชื่อเข้าใช้จากภายนอกหรือมีความเสี่ยงสูงกว่า

นี่เป็นเพียงตัวอย่าง ไม่ใช่การตั้งค่าที่ใช้ได้กับทุกกรณี นโยบายที่เหมาะกับทีมการเงินภายในอาจไม่เหมาะกับพอร์ทัลลูกค้า อ่าน วิธีที่ Conditional Access เสริมความปลอดภัยการลงชื่อเข้าใช้ Odoo ก่อนเลือกการควบคุม

Conditional Access ยังมีข้อกำหนดด้านลิขสิทธิ์ Microsoft Entra ID P1 จำเป็นสำหรับ Conditional Access ขณะที่นโยบายที่อิงความเสี่ยงต้องใช้ P2 Microsoft 365 Business Premium รวมความสามารถของ Conditional Access ไว้ด้วย ควรตรวจสอบลิขสิทธิ์และความพร้อมใช้งานของฟีเจอร์ปัจจุบันเทียบกับ เอกสารทางการของ Microsoft.

ทำให้ข้อมูลประจำตัวและการเข้าถึง Odoo ใกล้ชิดกันมากขึ้น

การยืนยันตัวตนตอบคำถามว่าผู้ใช้คือใคร ส่วนการกำหนดสิทธิ์ใน Odoo ยังคงตัดสินว่าผู้ใช้รายนั้นทำอะไรได้บ้าง

การผสานการทำงานที่ออกแบบมาอย่างดีสามารถจับคู่ข้อมูลประจำตัว Microsoft ที่ได้รับอนุมัติกับบัญชี Odoo ที่มีอยู่ สร้างบัญชีที่ได้รับอนุมัติเมื่อมีการลงชื่อเข้าใช้ครั้งแรก และแมป Entra groups หรือบทบาทแอปพลิเคชันที่เลือกไปยังกลุ่มการเข้าถึงของ Odoo สิ่งนี้สามารถลดงานดูแลที่ซ้ำซ้อนและทำให้การตรวจสอบการตัดสินใจเรื่องการเข้าถึงง่ายขึ้น

สิ่งสำคัญคือต้องรักษาขอบเขตระหว่างข้อมูลประจำตัวและการกำหนดสิทธิ์ การลบใครบางคนออกจาก Entra group ควรส่งผลต่อการแมปของ Odoo ตามพฤติกรรมการซิงโครไนซ์ที่ระบุไว้ของการผสานการทำงาน แต่ไม่ได้หมายความว่าจะสิ้นสุดเซสชัน Odoo ที่มีอยู่ทันที หากมีการซิงโครไนซ์การเข้าถึงตอนลงชื่อเข้าใช้ การเปลี่ยนแปลงจะมีผลเมื่อผู้ใช้ลงชื่อเข้าใช้อีกครั้ง เว้นแต่การควบคุมเซสชันอื่นจะเข้ามาแทรกแซง

การจับคู่อีเมลก็ต้องระมัดระวังเช่นกัน Microsoft เตือนว่าอีเมลแอดเดรสและ user principal names สามารถเปลี่ยนแปลงหรือถูกนำกลับมาใช้ใหม่ได้ คำแนะนำ ID token claims guidance ของ Microsoft แนะนำให้ใช้ตัวระบุที่ไม่เปลี่ยนแปลง เช่น sub หรือ oid พร้อมบริบทของ tenant เมื่อจำเป็น เพื่อให้มีข้อมูลประจำตัวที่คงทน อีเมลอาจมีประโยชน์ในขั้นตอนเชื่อมโยงครั้งแรกที่ควบคุมได้ แต่ไม่ควรเป็นกุญแจข้อมูลประจำตัวถาวร

หากต้องการออกแบบการเข้าถึงให้ลึกขึ้น อ่าน การรวมศูนย์การเข้าถึง Odoo ด้วย Entra groups และ app roles.

สิ่งที่ Microsoft SSO ไม่ได้มาแทนที่

Microsoft SSO ไม่ได้มาแทนที่การอัปเดต Odoo บทบาทแบบสิทธิ์น้อยที่สุด กฎระเบียน การโฮสต์ที่ปลอดภัย การสำรองข้อมูล การมอนิเตอร์ การควบคุมเซสชัน หรือการตอบสนองต่อเหตุการณ์ เอกสารทางการของ Odoo ยังเตือนฐานข้อมูลที่โฮสต์บน Odoo.com ไม่ให้ใช้ OAuth flow ที่มีเอกสารกำกับกับเจ้าของฐานข้อมูลหรือผู้ดูแลระบบ เพราะการจัดการพอร์ทัลอาจได้รับผลกระทบ โปรดยืนยันเจ้าของและการดูแลระบบฉุกเฉินก่อนเริ่มใช้งาน

วิธีที่ปลอดภัยกว่าในการนำการลงชื่อเข้าใช้ Microsoft มาใช้

เริ่มด้วยกลุ่มทดสอบขนาดเล็ก ตรวจสอบข้อมูลเมตาของการค้นพบจาก Microsoft และคีย์การลงนาม ยืนยัน URL callback ทดสอบการจับคู่บัญชี และตรวจสอบผลลัพธ์สำหรับผู้ใช้ใหม่และผู้ใช้ที่ไม่ได้รับอนุญาต เก็บเส้นทางการดูแลระบบฉุกเฉินไว้จนกว่ากระบวนการจะได้รับการทดสอบครบทุกขั้นตอน

จากนั้นจัดทำเอกสารนโยบายที่ใช้กับ Odoo ใบอนุญาต Entra ที่จำเป็น วิธีที่การเปลี่ยนแปลงกลุ่มหรือบทบาทส่งผลไปยัง Odoo และวิธีที่ฝ่ายสนับสนุนจะตอบสนองหากการลงชื่อเข้าใช้ของ Microsoft ไม่พร้อมใช้งาน หากลูกค้าและพาร์ตเนอร์จำเป็นต้องเข้าถึง ให้พิจารณาออกแบบข้อมูลระบุตัวตนสำหรับลูกค้าแยกต่างหาก แทนที่จะถือว่าเป็นพนักงาน คู่มือของเราว่าด้วย Microsoft Entra External ID for Odoo customers and partners อธิบายความแตกต่างนั้น

นำ Microsoft SSO แบบมีคำแนะนำมาสู่ Odoo 19

โมดูล Microsoft Entra SSO for Odoo module ของเรามอบการเชื่อมต่อแบบมีคำแนะนำสำหรับ Odoo 19 ครอบคลุมทั้งผู้ใช้งานภายในองค์กรและกลุ่มภายนอก การลงชื่อเข้าใช้ครั้งแรกที่ควบคุมได้ การแมปกลุ่มและบทบาทของแอป การทดสอบการลงชื่อเข้าใช้ และการเข้าสู่ระบบแบบอินเทอร์แอกทีฟด้วย Microsoft เท่านั้นหลังการตรวจสอบความถูกต้อง ใช้โฟลว์การให้สิทธิ์ OpenID Connect แบบ authorization code พร้อม PKCE

โมดูลนี้ไม่ได้เป็นตัวกำหนดนโยบายความปลอดภัยของคุณ องค์กรของคุณยังคงรับผิดชอบต่อการกำหนดค่า Entra การออกแบบการเข้าถึง Odoo และการนำไปใช้งาน