การตั้งค่า MFA และการเข้าถึงแบบมีเงื่อนไขใน Windows 11

ปกป้องการเข้าสู่ระบบ Windows 11 สำหรับธุรกิจ ด้วย MFA และการเข้าถึงแบบมีเงื่อนไข การใช้รหัสผ่านที่ซับซ้อนกลายเป็นสิ่งจำเป็นพื้นฐานสำหรับองค์กรใดๆ ที่ใช้ Microsoft 365, Power Platform หรือบริการคลาวด์ รหัสผ่านที่ซับซ้อนเพียงอย่างเดียวไม่เพียงพออีกต่อไปแล้ว เพราะผู้โจมตีได้เรียนรู้วิธีหลีกเลี่ยง และความปลอดภัยที่แท้จริงอยู่ที่การตรวจสอบสิทธิ์แบบหลายปัจจัยและนโยบายการเข้าถึงอัจฉริยะ

ถ้าคุณทำงานกับ Microsoft Entra ID (เดิมคือ Azure AD), Intune และอุปกรณ์ Windows 11คุณอาจเคยได้ยินเกี่ยวกับ Conditional Access มาบ้างแล้ว แต่คุณอาจไม่แน่ใจนักว่าส่วนประกอบต่างๆ ทำงานร่วมกันอย่างไร เช่น MFA, ความแข็งแกร่งของการตรวจสอบสิทธิ์, อุปกรณ์ที่ใช้งานร่วมกันได้, ผู้ใช้ภายนอก, Power Platform และอื่นๆ คู่มือนี้จะรวบรวมส่วนประกอบทั้งหมดเข้าด้วยกัน โดยอธิบายรายละเอียดว่าแต่ละส่วนควบคุมทำอะไร วิธีการทำงานร่วมกัน และข้อจำกัดที่แท้จริงที่คุณจะพบเมื่อนำไปใช้กับ Windows 11 รวมถึงกรณีพิเศษของการเข้าสู่ระบบผ่านเว็บด้วย

การเข้าถึงแบบมีเงื่อนไข (Conditional Access) คืออะไร และมีความเกี่ยวข้องกับการตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA) ใน Windows 11 อย่างไร?

El รหัสเข้าสู่ระบบการเข้าถึงแบบมีเงื่อนไขของ Microsoft โดยพื้นฐานแล้วมันคือระบบของกฎ "ถ้าเกิดเหตุการณ์นี้ ให้ทำอย่างนั้น" ที่กำหนดว่าผู้ใช้สามารถเข้าถึงทรัพยากรได้หรือไม่ เช่น แอปพลิเคชันบนคลาวด์ การกระทำเฉพาะ (เช่น การบันทึกข้อมูลความปลอดภัย) หรือบริบทการตรวจสอบสิทธิ์พิเศษ นโยบายเหล่านี้จะรวมสัญญาณต่างๆ เช่น ข้อมูลประจำตัวผู้ใช้ อุปกรณ์ เครือข่าย ความเสี่ยงในการเข้าสู่ระบบ และประเภทของไคลเอ็นต์ เพื่อใช้การควบคุมต่างๆ เช่น การตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA) ข้อกำหนดของอุปกรณ์ที่สอดคล้อง หรือการบล็อกโดยสมบูรณ์

แต่ละคำสั่งประกอบด้วยส่วนประกอบหลักสองส่วน: การมอบหมายงาน (ใคร ทำอะไร และภายใต้เงื่อนไขใด) y การควบคุมการเข้าถึง (สิ่งใดจำเป็นหรือถูกบล็อก)สามารถใช้มาตรการควบคุมหลายอย่างพร้อมกันได้ และหากตรงตามเงื่อนไขของนโยบายมากกว่าหนึ่งข้อ ผู้ใช้จะต้องปฏิบัติตามข้อกำหนดที่เกี่ยวข้องทั้งหมด (เช่น การยืนยันตัวตนแบบหลายปัจจัย + อุปกรณ์ที่รองรับ + ​​การยอมรับข้อกำหนดการใช้งาน)

ในสภาพแวดล้อมที่ใช้ Windows 11 ร่วมกับ Entra ID และ Intune การเข้าถึงแบบมีเงื่อนไขจะทำงานเมื่อมีการร้องขอโทเค็นสำหรับทรัพยากรที่ได้รับการป้องกัน จุดนี้สำคัญมากกลไกการเข้าถึงแบบมีเงื่อนไขจะไม่ทำงานทุกครั้งที่ผู้ใช้ป้อนข้อมูลประจำตัว แต่จะทำงานเมื่อแอป (หรือระบบ) ร้องขอโทเค็นสำหรับทรัพยากรเฉพาะ (Exchange, SharePoint, Power BI เป็นต้น)

ดังนั้น แม้ว่าเป้าหมายของคุณคือ "กำหนดให้ต้องใช้ MFA ทุกครั้งที่เข้าสู่ระบบ Windows 11" ในทางปฏิบัติแล้ว ความท้าทายทางเทคนิคคือจะประเมินนโยบายเหล่านั้นที่ใด และแอปพลิเคชันหรือทรัพยากรใดที่กระตุ้นการประเมินการเข้าถึงแบบมีเงื่อนไข

MFA และความเข้มข้นของการตรวจสอบสิทธิ์: ระดับและกลยุทธ์

ใน Microsoft Entra ID การตรวจสอบสิทธิ์แบบหลายปัจจัยไม่ได้เป็นเพียงแค่การเลือก "ใช่/ไม่ใช่" เท่านั้น แต่มีแนวคิดที่สำคัญมากอย่างหนึ่งเรียกว่า... ความแข็งแกร่งในการตรวจสอบสิทธิ์ซึ่งเป็นการกำหนดว่าวิธีการนั้นต้องมีความแข็งแกร่งมากแค่ไหนเพื่อให้เป็นไปตามนโยบาย ไมโครซอฟต์มีระดับความแข็งแกร่งที่กำหนดไว้ล่วงหน้าสามระดับ:

การรักษาความปลอดภัยด้วยการตรวจสอบสิทธิ์แบบหลายปัจจัย (รูปแบบที่เข้มงวดน้อยที่สุด แต่เป็นรูปแบบพื้นฐานที่แนะนำในสถานการณ์ส่วนใหญ่) รูปแบบนี้รองรับวิธีการยืนยันตัวตนแบบหลายปัจจัย (MFA) มาตรฐาน เช่น SMS, การโทรด้วยเสียง, การแจ้งเตือนแบบพุชใน Microsoft Authenticator, โทเค็น OATH เป็นต้น และเป็นจุดเริ่มต้นที่พบบ่อยที่สุดสำหรับการกำหนดให้ใช้การยืนยันตัวตนแบบสองปัจจัยเมื่อเข้าถึงทรัพยากรขององค์กรจาก Windows 11

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

ความแรงของ MFA ที่ทนต่อ Phishระดับที่เข้มงวดที่สุด ออกแบบมาสำหรับบัญชีที่สำคัญ (ผู้ดูแลระบบ บัญชีที่มีสิทธิ์สูง การเข้าถึงข้อมูลที่ละเอียดอ่อนมาก) โดยทั่วไปแล้ว ระดับนี้ต้องการการผสมผสานของวิธีการที่ไม่สามารถดักฟังได้ง่าย (ตัวอย่างเช่น FIDO2 หรือ Windows Hello for Business)

นอกเหนือจากตัวเลือกที่กำหนดไว้ล่วงหน้าเหล่านี้แล้ว คุณยังสามารถ สร้างความเข้มข้นแบบกำหนดเองการสร้างส่วนผสมของวิธีการที่ได้รับการยอมรับด้วยตนเองนั้นมีประโยชน์มาก ตัวอย่างเช่น หากคุณต้องการบังคับให้ผู้ดูแลระบบของคุณใช้ Windows Hello หรือ FIDO2 สำหรับงานบางอย่างใน Windows 11 และห้ามไม่ให้พวกเขาตรวจสอบความถูกต้องด้วย SMS

สร้างนโยบาย MFA พื้นฐานพร้อมการเข้าถึงแบบมีเงื่อนไข

วิธีที่สะอาดที่สุดในการ บังคับใช้ MFA ทั่วโลก (รวมถึงการเข้าถึงบริการ Microsoft 365, แอปพลิเคชันระดับองค์กร และ Power Platform จาก Windows 11) ทำได้โดยใช้นโยบายการเข้าถึงแบบมีเงื่อนไข (Conditional Access Policy) ที่กำหนดเป้าหมายไปยังผู้ใช้และทรัพยากรทั้งหมด ขั้นตอนการทำงานทั่วไปสำหรับการสร้างนโยบายนี้จะเป็นดังนี้:

ขั้นแรก เข้าไปที่ ศูนย์การดูแลระบบ Microsoft ลงชื่อเข้าใช้ ใช้บัญชีผู้ใช้ที่มีบทบาทอย่างน้อยเป็นผู้ดูแลระบบการเข้าถึงแบบมีเงื่อนไข ไปที่ รหัสเข้าสู่ระบบ > การเข้าถึงแบบมีเงื่อนไข > นโยบาย และสร้างนโยบายใหม่โดยตั้งชื่อที่ชัดเจนและเป็นมาตรฐาน

ใน บัญชีผู้ใช้หรือข้อมูลประจำตัวในการทำงานเลือก “ผู้ใช้ทั้งหมด” ในส่วน “รวม” แต่ให้ยกเว้นบัญชีฉุกเฉินและบัญชีการซิงโครไนซ์ (เช่น บัญชีจาก Entra Connect) เพื่อหลีกเลี่ยงการบล็อกการเข้าถึงของผู้ดูแลระบบหรือการซิงโครไนซ์ข้อมูลประจำตัว หากคุณจัดการแขกด้วยนโยบายเฉพาะ คุณสามารถยกเว้นผู้ใช้ภายนอกจากนโยบายโดยรวมนี้ได้

En ทรัพยากรเป้าหมาย (เดิมชื่อ “แอปพลิเคชันบนคลาวด์”)เลือก “ทรัพยากรทั้งหมด” วิธีนี้จะทำให้คำขอโทเค็นใดๆ ไปยังบริการต่างๆ เช่น Exchange Online, SharePoint, Teams, Power BI, แอปพลิเคชันทางธุรกิจ และแม้แต่ Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) ได้รับผลกระทบจากนโยบายนี้

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

เมื่อคุณตรวจสอบบันทึกและยืนยันแล้วว่าคุณจะไม่เผลอทำให้ระบบล่มไปครึ่งหนึ่ง คุณสามารถเปลี่ยนสถานะเป็น "เปิดใช้งาน" ได้ จากนั้นเป็นต้นไป คำขอทั้งหมดสำหรับการเข้าถึงทรัพยากรที่ได้รับการคุ้มครอง คอมพิวเตอร์ที่ใช้ Windows 11 ที่เข้าร่วมในไดเร็กทอรีจะต้องผ่านการตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA) นี้ ยกเว้นคอมพิวเตอร์ที่คุณกำหนดไว้เป็นข้อยกเว้น

การควบคุมการให้ทุนขั้นสูง: นอกเหนือจาก “การกำหนดให้ใช้ MFA”

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

การควบคุมของ “บล็อกการเข้าถึง” มันทรงพลังและอันตรายมาก หากการจับคู่ตรงกัน (ผู้ใช้ ทรัพยากร เงื่อนไข) การเข้าถึงจะถูกปฏิเสธโดยไม่มีตัวเลือกการยืนยันตัวตนแบบหลายปัจจัย (MFA) หรือมาตรการบรรเทาอื่นๆ เหมาะอย่างยิ่งสำหรับการลบโปรโตคอลเก่า การบล็อกประเทศเฉพาะ หรือการตัดการเข้าถึงแอปพลิเคชันที่ล้าสมัย แต่ควรทดสอบก่อนในโหมด "รายงานอย่างเดียว" และใช้เครื่องมือต่างๆ เช่น What If เสมอ

เมื่อคุณเลือก “อนุญาตสิทธิ์การเข้าถึง” คุณสามารถ รวมข้อกำหนดหลายประการเข้าด้วยกันคุณสามารถกำหนดให้ต้องใช้ MFA, อุปกรณ์ที่รองรับ, การเชื่อมต่อ Entra แบบไฮบริด, แอปพลิเคชันไคลเอ็นต์ที่ได้รับอนุมัติ, นโยบายการปกป้องแอป, การเปลี่ยนรหัสผ่าน หรือการลดความเสี่ยง คุณสามารถตัดสินใจได้ว่าผู้ใช้ต้องปฏิบัติตามการควบคุมที่เลือกทั้งหมด (AND) หรือเพียงข้อเดียว (OR)

การควบคุมของ “กำหนดให้ต้องระบุว่าอุปกรณ์นั้นใช้งานร่วมกันได้” ระบบนี้ใช้ Intune อุปกรณ์ต้องลงทะเบียนกับ Entra ID และปฏิบัติตามนโยบายการปฏิบัติตามข้อกำหนด (โปรแกรมป้องกันไวรัส การเข้ารหัส เวอร์ชันระบบปฏิบัติการ ฯลฯ) ระบบนี้รองรับ... หน้าต่าง 10 / 11iOS, Android, macOS และ Ubuntu Linux ที่ใช้ Intune วิธีนี้เหมาะอย่างยิ่งสำหรับการรับประกันว่าการเข้าถึงข้อมูลที่ละเอียดอ่อนจะมาจากอุปกรณ์ที่ได้รับการจัดการเสมอ

หากคุณอยู่ในองค์กรแบบไฮบริด การควบคุม “ต้องใช้อุปกรณ์ไฮบริดที่เชื่อมต่อกับ Microsoft ลงชื่อเข้าใช้"วิธีนี้ช่วยให้คุณมั่นใจได้ว่าเฉพาะคอมพิวเตอร์ที่เข้าร่วมโดเมนและลงทะเบียนด้วย Entra ID (ทั้ง Windows 10 รุ่นก่อนและรุ่นปัจจุบัน) เท่านั้นที่จะสามารถเข้าถึงทรัพยากรบางอย่างได้ วิธีนี้ใช้กันอย่างแพร่หลายเพื่อจำกัดการบริหารจัดการเฉพาะอุปกรณ์ขององค์กร"

คุณสามารถเรียกร้องได้เช่นกัน ใบสมัครของลูกค้าที่ได้รับการอนุมัติ (เช่น รายชื่อแอป Office คลาสสิก, Outlook, OneDrive, Teams, Power BI เป็นต้น) หรือ นโยบายการคุ้มครองแอปพลิเคชัน โดย Intune ซึ่งช่วยให้มั่นใจได้ว่าข้อมูลจะถูกเปิดเฉพาะในแอปที่ได้รับการปกป้องโดย MAM ซึ่งส่วนใหญ่อยู่ในระบบ iOS และ Android (และอยู่ในช่วงทดลองใช้งานสำหรับ Edge บน Windows)

สุดท้ายนี้ การควบคุมของ “ต้องเปลี่ยนรหัสผ่าน” การตั้งค่า "กำหนดให้มีการลดความเสี่ยง" นั้นถูกรวมเข้ากับ Microsoft Entra ID Protection โดยจะถูกใช้เมื่อผู้ใช้ถูกระบุว่ามีความเสี่ยงสูง ในสถานการณ์เหล่านี้ ระบบจะบังคับให้ทำการรีเซ็ตอย่างปลอดภัยหรือดำเนินการแก้ไขความเสี่ยง โดยจะต้องมีการยืนยันตัวตนแบบหลายปัจจัย (MFA) นำหน้าเสมอ เพื่อป้องกันการถูกบุกรุกบัญชีโดยไม่ต้องมีการแทรกแซงจากผู้ดูแลระบบอย่างต่อเนื่อง

การเข้าถึงแบบมีเงื่อนไข: การมอบหมาย เงื่อนไข และลำดับการประเมิน

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

ในส่วนของ ผู้ใช้และกลุ่ม คุณสามารถกำหนดได้ว่านโยบายนี้จะมีผลกับใครบ้าง: ผู้ใช้ทั้งหมด กลุ่มเฉพาะ บทบาทในไดเร็กทอรี (เช่น ผู้ดูแลระบบส่วนกลาง) หรือข้อมูลประจำตัวของเวิร์กโหลด (หลักการบริการ) การประเมินจะดำเนินการเมื่อมีการออกโทเค็นใหม่ ดังนั้นหากผู้ใช้เข้าร่วมกลุ่มหลังจากมีโทเค็นที่ถูกต้องแล้ว นโยบายนี้จะไม่มีผลกับพวกเขาจนกว่าพวกเขาจะต่ออายุข้อมูลประจำตัว

En แหล่งข้อมูลปลายทาง คุณสามารถกำหนดเครื่องหมายให้กับแอปพลิเคชันบนคลาวด์ของ Microsoft (Office 365, Azure Service Management API, พอร์ทัลการดูแลระบบ ฯลฯ) แอปที่เผยแพร่ผ่าน Application Proxy การกระทำของผู้ใช้ เช่น การลงทะเบียนข้อมูลความปลอดภัย หรือการลงทะเบียน/เข้าร่วมอุปกรณ์ และแม้แต่บริบทการตรวจสอบสิทธิ์เฉพาะที่ใช้จาก SharePoint, PIM หรือแอปพลิเคชันอื่นๆ

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

นอกจากนี้ คุณยังมีเงื่อนไขเพิ่มเติมอีก เช่น แพลตฟอร์มอุปกรณ์ (Windows, iOS, Android, macOS, Linux), ประเภทแอปพลิเคชันไคลเอ็นต์ (เบราว์เซอร์, แอปมือถือ/เดสก์ท็อป, โปรโตคอลแบบเดิม), ตัวกรองอุปกรณ์ (อิงตามคุณลักษณะของวัตถุอุปกรณ์) และความเสี่ยงในการเข้าสู่ระบบ (หากคุณมี Entra ID Protection)

เมื่อมีการบังคับใช้นโยบายหลายฉบับกับผู้ใช้และทรัพยากรเดียวกัน พวกมันรวมกันแบบสะสมดังนั้น หากนโยบายหนึ่งกำหนดให้ใช้ MFA และอีกนโยบายหนึ่งกำหนดให้ใช้อุปกรณ์ที่ใช้งานร่วมกันได้ ผู้ใช้จะต้องปฏิบัติตามทั้งสองนโยบาย ลำดับการตรวจสอบมักจะเป็นไปตามตรรกะ MFA – สถานะอุปกรณ์ – ข้อกำหนดการใช้งาน และคุณจะเห็นลำดับนี้สะท้อนอยู่ในนั้น บันทึกการเข้าสู่ระบบ.

ข้อจำกัดของ MFA กับการเข้าสู่ระบบผ่านเว็บใน Windows 11

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

โดยปกติแล้ว ปัญหานี้จะไม่เกิดขึ้นกับการเข้าสู่ระบบผ่านเบราว์เซอร์ แอปพลิเคชันบนมือถือ หรือ Office ใน Windows 11 ซึ่งนโยบายการเข้าถึงแบบมีเงื่อนไขเดียวกันนี้ใช้งานได้โดยไม่มีปัญหา หากคุณเปิดใช้งาน MFA ต่อผู้ใช้ (โมเดลแบบคลาสสิก) แทนการเข้าถึงแบบมีเงื่อนไข MFA จะถูกบังคับใช้กับการเข้าสู่ระบบผ่านเว็บ ซึ่งบ่งชี้ว่าปัญหาอยู่ที่วิธีการทำงานร่วมกันระหว่างกระบวนการดังกล่าวกับกลไกนโยบายการเข้าถึงแบบมีเงื่อนไข

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

ดังนั้น หากความต้องการของคุณคือ หน้าจอล็อกการเข้าสู่ระบบของ Windows 11 จะขอการยืนยันตัวตนแบบหลายปัจจัย (MFA) เสมอวิธีเดียวที่น่าเชื่อถือในการทำเช่นนี้ในปัจจุบันคือการใช้ MFA ต่อผู้ใช้ ซึ่งจะบังคับให้ผู้ใช้ทุกคนต้องมีปัจจัยการตรวจสอบสิทธิ์ที่สอง ไม่ว่าพวกเขาจะเข้าถึงทรัพยากรใดในภายหลังก็ตาม วิธีนี้อาจไม่ยืดหยุ่นหรือละเอียดเท่ากับการเข้าถึงแบบมีเงื่อนไข แต่ก็ช่วยแก้ปัญหาข้อจำกัดเฉพาะนี้ได้

การเข้าถึงแบบมีเงื่อนไขสำหรับแอปพลิเคชัน, Power Platform และ API

ขอบเขตการใช้งานของ Conditional Access นั้นกว้างไกลกว่าแค่ Windows 11 และ Microsoft 365 แพลตฟอร์มพลังงาน (Power Apps, Power Automate, Power BI, Copilot Studio ฯลฯ) ระบบนี้อาศัย Entra ID ในการตรวจสอบสิทธิ์และการอนุญาตอย่างสมบูรณ์ ดังนั้นนโยบายการเข้าถึงเดียวกันจึงใช้กับการใช้งานแอปพลิเคชัน โฟลว์ และตัวเชื่อมต่อ

ในระดับผู้เช่า Entra ID จะตรวจสอบให้แน่ใจว่าผู้ใช้มีบัญชีที่ใช้งานอยู่ ผ่านนโยบายการเข้าถึง (MFA, ตำแหน่งที่ตั้ง, อุปกรณ์, ความเสี่ยง) และมีใบอนุญาต แต่ สำหรับ Power Platform นี่เป็นเพียงชั้นแรกเท่านั้นจากนั้น บทบาทการให้บริการ (เช่น ผู้ดูแลระบบ Power Platform, ผู้ดูแลระบบ Dynamics 365), กลุ่มความปลอดภัยที่ควบคุมการเข้าถึงสภาพแวดล้อม และเหนือสิ่งอื่นใดคือแบบจำลองความปลอดภัยของ Dataverse (RBAC, สิทธิ์ตามตาราง แถว และคอลัมน์) จะเข้ามามีบทบาท

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

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

การเข้าถึงแบบมีเงื่อนไขสำหรับผู้ใช้ภายนอกและการทำงานร่วมกันระหว่างธุรกิจ (B2B)

องค์กรหลายแห่งแบ่งปันทรัพยากรกับ ผู้ใช้ภายนอกคู่ค้า ซัพพลายเออร์ ลูกค้า ที่ปรึกษา… ในกรณีเหล่านี้ Microsoft Entra External ID จะเข้ามามีบทบาท ช่วยให้เกิดความร่วมมือแบบ B2B และการเชื่อมต่อ B2B โดยตรง ผู้ใช้ภายนอกสามารถยืนยันตัวตนด้วยเทนเนนต์ของตนเองหรือด้วยผู้ให้บริการยืนยันตัวตนทางโซเชียล (Google, Facebook, SAML ฯลฯ) แต่เทนเนนต์ของทรัพยากรจะเป็นผู้กำหนดนโยบายการเข้าถึงแบบมีเงื่อนไขที่ใช้บังคับ

สำหรับสถานการณ์ระหว่างผู้เช่า Entra ต่างๆ คุณสามารถกำหนดค่าได้ดังนี้ MFA และความน่าเชื่อถือในการป้อนข้อมูลอุปกรณ์การตั้งค่านี้ช่วยให้ผู้เช่าของคุณยอมรับสัญญาณได้ หากผู้ใช้ได้ทำการยืนยันตัวตนแบบหลายปัจจัย (MFA) เสร็จสิ้นแล้ว หรืออุปกรณ์ของผู้ใช้ได้รับการตรวจสอบแล้วว่าใช้งานร่วมกันได้ หรือได้เข้าร่วมกับ Hybrid Entry ในองค์กรต้นทางแล้ว และจะไม่ขอการยืนยันตัวตนเพิ่มเติม หากคุณไม่ได้กำหนดค่าความเชื่อถือนี้ พฤติกรรมจะแตกต่างกันไป: ผู้ใช้งาน B2B ที่เป็นแขกจะต้องทำการยืนยันตัวตนแบบหลายปัจจัย (MFA) ในผู้เช่าของคุณ ผู้ใช้งาน B2B ที่เชื่อมต่อโดยตรงอาจถูกบล็อกหากจำเป็นต้องใช้ MFA หรือการตรวจสอบความสอดคล้องของอุปกรณ์ และไม่สามารถประเมินได้

ในกรณีของผู้ใช้ที่ไม่ได้มาจาก Entra (เช่น ผู้ใช้ที่ใช้บัญชีโซเชียลมีเดีย บัญชี Microsoft ส่วนตัว หรือการยืนยันตัวตนด้วย OTP ผ่านอีเมล) ผู้เช่าทรัพยากรมีหน้าที่รับผิดชอบต่อ MFA เสมอกล่าวอีกนัยหนึ่ง หากนโยบายของคุณกำหนดให้ใช้ MFA การดำเนินการดังกล่าวจะต้องทำในไดเร็กทอรีของคุณเอง คุณไม่สามารถมอบหมายให้ผู้ให้บริการภายนอกรายอื่นดำเนินการแทนได้

นอกจากนี้ คุณยังสามารถกำหนดนโยบายเฉพาะตามประเภทของผู้ใช้ภายนอกได้ เช่น ผู้ใช้ B2B (UserType=Guest), สมาชิก B2B (ได้รับการปฏิบัติเกือบเหมือนผู้ใช้ภายใน), ผู้ใช้ B2B ที่เชื่อมต่อโดยตรง (ไม่มีวัตถุผู้ใช้ในไดเร็กทอรีของคุณ), ผู้ใช้แบบเดิมในระบบภายใน, ผู้ให้บริการ และอื่นๆ ระดับความละเอียดนี้ช่วยให้คุณสามารถกำหนดให้ใช้ MFA ที่ป้องกันฟิชชิ่งได้เฉพาะกับการเชื่อมต่อภายนอกที่มีความเสี่ยงสูงเท่านั้น

การปกป้องไดเร็กทอรี ความเสี่ยง และโดเมนที่มีสิทธิ์จำกัด

รายละเอียดเล็กๆ น้อยๆ ที่มักถูกมองข้ามคือ แอปพลิเคชันจำนวนมากมักถามคำถามเหล่านี้ ขอบเขตที่มีสิทธิ์น้อย ขอบเขตเหล่านี้เกี่ยวข้องกับไดเร็กทอรี เช่น User.Read, People.Read, GroupMember.Read.All เป็นต้น โดยปกติแล้ว เมื่อคุณสร้างนโยบาย "ทรัพยากรทั้งหมด" โดยมีการยกเว้นบางส่วน ขอบเขตเหล่านี้มักถูกละเว้น เพื่อไม่ให้แอปพลิเคชันที่อ่านเฉพาะโปรไฟล์ผู้ใช้พื้นฐานหรือสมาชิกกลุ่มของพวกเขาทำงานผิดพลาด

ไมโครซอฟต์ได้เปลี่ยนพฤติกรรมนี้แล้ว และตอนนี้ พื้นที่เหล่านี้ได้รับการประเมินว่าสามารถเข้าถึงทรัพยากร Windows Azure Active Directory ได้หรือไม่ (00000002-0000-0000-c000-000000000000) หมายความว่า หากคุณมีนโยบายที่กำหนดเป้าหมายไปที่ "ทรัพยากรทั้งหมด" โดยมีข้อยกเว้น หรือนโยบายเฉพาะบน Windows Azure AD คำขอโทเค็นที่ขอเฉพาะขอบเขตเหล่านี้เท่านั้น สามารถกระตุ้นการเข้าถึงแบบมีเงื่อนไข และบังคับใช้ MFA หรือการปฏิบัติตามข้อกำหนดของอุปกรณ์ได้

ในทางปฏิบัติ ผู้ใช้อาจเริ่มพบกับปัญหาเกี่ยวกับ MFA เมื่อเข้าสู่ระบบเครื่องมือต่างๆ เช่น Visual Studio Code, Azure CLI หรือแอปพลิเคชันอื่นๆ ที่ขอเพียงสิทธิ์การเข้าถึงแบบ openid, profile, User.Read หรือสิทธิ์ที่คล้ายกัน หากองค์กรของคุณตั้งใจที่จะรักษาความปลอดภัยในการเข้าถึงข้อมูลไดเร็กทอรีประเภทนี้ด้วย นี่คือขั้นตอนที่สมเหตุสมผล มิเช่นนั้น คุณจะต้องปรับนโยบายหรือสร้างนโยบายเฉพาะสำหรับ Windows Azure Active Directory

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

แนวปฏิบัติที่ดีสำหรับการรักษาความปลอดภัยและการกำกับดูแลตัวตน

การตั้งค่า MFA และ Conditional Access ใน Windows 11 และสภาพแวดล้อมอื่นๆ ของคุณเป็นเพียงครึ่งหนึ่งของเรื่องราว อีก 50% อยู่ที่... แบบจำลองการกำกับดูแลตัวตนใครมีสิทธิ์เข้าถึงบ้าง นานเท่าไหร่ และมีสิทธิ์พิเศษอะไรบ้าง

ข้อแนะนำที่สำคัญที่สุดประการหนึ่งคือ ลดจำนวนบัญชีที่มีผลกระทบสูงให้น้อยที่สุดควรแยกบทบาทแทนการยกระดับสิทธิ์ในบัญชีผู้ใช้ทั่วไป และใช้โมเดล Just-In-Time (JIT) ร่วมกับเครื่องมืออย่าง Microsoft Entra Privileged Identity Management (PIM) เพื่อให้สิทธิ์ระดับสูงเฉพาะเมื่อจำเป็นเท่านั้น

นอกจากนี้ ยังควรหลีกเลี่ยงการเข้าถึงระดับผู้ดูแลระบบแบบถาวร เพื่อรักษาเสถียรภาพ บัญชีฉุกเฉินที่บันทึกและตรวจสอบแล้วเสริมความแข็งแกร่งให้กับการตรวจสอบสิทธิ์ของผู้ดูแลระบบด้วยวิธีการที่ไม่ต้องใช้รหัสผ่านหรือ MFA ที่มีประสิทธิภาพ และใช้เงื่อนไขการเข้าถึงแบบมีเงื่อนไขที่เข้มงวดมากขึ้นกับบทบาทเหล่านี้ (เช่น กำหนดให้ต้องใช้อุปกรณ์ที่เข้ากันได้และ MFA ที่ป้องกันการฟิชชิ่งสำหรับการดำเนินการใดๆ ของผู้ดูแลระบบจาก Windows 11)

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

สำหรับ Power Platform โดยเฉพาะ ขอแนะนำอย่างยิ่งให้แนะนำนักพัฒนาไปที่... สภาพแวดล้อมการพัฒนาของตนเองจำกัดการแชร์ข้อมูลจำนวนมาก (เช่น หลีกเลี่ยงตัวเลือก "ทุกคน" อย่างระมัดระวัง) ควบคุมการเข้าถึงสภาพแวดล้อมโดยใช้กลุ่ม Entra ID ใช้ Dataverse เป็นที่เก็บข้อมูลหลักพร้อมการควบคุมการเข้าถึงตามบทบาท (RBAC) ที่ละเอียด และใช้ นโยบายข้อมูลที่จำกัดตัวเชื่อมต่อที่สามารถใช้ได้ในสภาพแวดล้อมเริ่มต้นหรือสภาพแวดล้อมการพัฒนา

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