Ngân hàng đề — Microsoft Azure Security Technology

Đáp án

D — Entra ID Identity Protection.

Vì sao đúng

⚠ Identity Protection làm đủ ba việc đề nêu: | Việc | Nội dung | |---|---| | ⚠ PHÁT HIỆN lỗ hổng ảnh hưởng định danh | ⚠ thông tin đăng nhập rò rỉ, đăng nhập bất thường | | ⚠ Cấu hình PHẢN ỨNG tự động | ⚠ risk-based Conditional Access — buộc MFA hoặc đổi mật khẩu | | ⚠ ĐIỀU TRA hoạt động đáng ngờ | ⚠ ba báo cáo: risky users, risky sign-ins, risk detections |

Vì sao các phương án khác sai

• A (Entra External ID) — ⚠ cộng tác với người dùng ngoài.

• B (Entra Join) — ⚠ đăng ký thiết bị.

• C (Microsoft Identity Platform) — ⚠ nền tảng cho LẬP TRÌNH VIÊN xây ứng dụng xác thực, không phải công cụ phát hiện rủi ro.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với #23787 trong CÙNG lô.

⚠ Các loại phát hiện rủi ro: | Rủi ro | Ví dụ | |---|---| | ⚠ Leaked credentials | ⚠ mật khẩu xuất hiện trong dữ liệu rò rỉ công khai | | ⚠ Impossible travel | ⚠ đăng nhập từ hai nơi cách xa trong thời gian ngắn | | ⚠ Anonymous IP | ⚠ qua Tor hoặc VPN ẩn danh | | ⚠ Password spray | ⚠ thử một mật khẩu phổ biến cho nhiều tài khoản | | ⚠ Unfamiliar sign-in properties | ⚠ thiết bị, vị trí, trình duyệt lạ |

⚠ Hai loại chính sách rủi ro: | Chính sách | Phản ứng | |---|---| | ⚠ Sign-in risk policy | ⚠ rủi ro ở LẦN đăng nhập này — buộc MFA hoặc chặn | | ⚠ User risk policy | ⚠ rủi ro với TÀI KHOẢN — buộc đổi mật khẩu |

Từ khoá nhận diện:

"phát hiện đăng nhập bất thường" → ⚠ Identity Protection "khai điều kiện đăng nhập" → ⚠ Conditional Access "quyền quản trị tạm thời" → ⚠ PIM "nền tảng lập trình xác thực" → ⚠ Microsoft Identity Platform

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có chính sách rủi ro nào đang bật không | | | Có người dùng nào bị đánh dấu rủi ro cao chưa xử lý không | | | Ai rà soát các phát hiện này hằng tuần | |

Và điều làm phát hiện dựa trên rủi ro khác hẳn luật cứng: nó dùng tín hiệu toàn cầu của Microsoft. Một tài khoản có mật khẩu xuất hiện trong vụ rò rỉ ở một dịch vụ hoàn toàn khác sẽ bị đánh dấu ngay — dù trong tổ chức bạn chưa có hành vi bất thường nào.

Đáp án

A, C và E.

• A — Dùng xác thực mạnh (strong authentication).
• C — Áp dụng nguyên tắc quyền tối thiểu.
• E — Dùng xác thực hiện đại (modern authentication).

Vì sao đúng

⚠ Ba thực hành cốt lõi cho bảo mật người dùng trong Entra ID: | Thực hành | Nội dung | |---|---| | ⚠ Xác thực mạnh | ⚠ MFA, passwordless, FIDO2, Windows Hello | | ⚠ Quyền tối thiểu | ⚠ chỉ cấp đúng thứ cần, dùng PIM cho vai trò quản trị | | ⚠ Xác thực hiện đại | ⚠ OAuth 2.0 và OpenID Connect, CHẶN legacy authentication |

⚠ Vì sao chặn legacy authentication lại quan trọng: ⚠ các giao thức cũ như POP, IMAP, SMTP AUTH KHÔNG hỗ trợ MFA — ⚠ kẻ tấn công dùng chúng để đi vòng qua mọi chính sách MFA bạn đã dựng.

Vì sao các phương án khác sai

• B (gán mọi người vai trò Global Administrator) — ⚠ NGƯỢC hoàn toàn với nguyên tắc quyền tối thiểu.

• D (dùng chung một mật khẩu cho nhiều ứng dụng) — ⚠ thực hành TỆ; giải pháp đúng là SSO, không phải dùng lại mật khẩu.

• F (vá máy trạm) và G (dùng kết nối mạng an toàn) — ⚠ đều là thực hành tốt về bảo mật NÓI CHUNG, nhưng không phải biện pháp bảo vệ NGƯỜI DÙNG trong Entra ID theo cách đề hỏi.

Ghi nhớ

⚠ Legacy authentication — mối nguy bị đánh giá thấp nhất: | Giao thức cũ | Vấn đề | |---|---| | ⚠ POP3, IMAP | ⚠ không hỗ trợ MFA | | ⚠ SMTP AUTH | | | ⚠ Exchange ActiveSync cũ | | | ⚠ Office 2010 trở về trước | | | ⚠ Thống kê của Microsoft | ⚠ phần lớn tấn công password spray đi qua legacy auth | | ⚠ Cách chặn | ⚠ Conditional Access policy chặn legacy authentication |

Từ khoá nhận diện:

"xác thực mạnh" → ⚠ MFA, passwordless "xác thực hiện đại" → ⚠ OAuth 2.0, OIDC — và chặn giao thức cũ "quyền tối thiểu" → ⚠ least privilege, PIM "một mật khẩu cho nhiều ứng dụng" → ⚠ SSO, KHÔNG phải dùng lại mật khẩu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Legacy authentication đã bị chặn chưa | ⚠ kiểm tra nhật ký đăng nhập xem còn ai dùng không | | Bao nhiêu người dùng chưa đăng ký MFA | | | Có bao nhiêu Global Administrator | |

Và lỗ hổng phổ biến nhất trong các tổ chức đã "bật MFA đầy đủ": legacy authentication vẫn mở. Chính sách MFA có đó, trông rất chặt, nhưng kẻ tấn công đơn giản là đăng nhập bằng IMAP và đi vòng qua toàn bộ.

Đáp án

B — Ứng dụng hướng người tiêu dùng (consumer-facing apps).

Vì sao đúng

⚠ External identities dành cho người dùng KHÔNG thuộc tổ chức của bạn: | Trường hợp | Giải pháp | |---|---| | ⚠ Ứng dụng cho khách hàng, người tiêu dùng | ⚠ Azure AD B2C hoặc External ID for customers | | ⚠ Đối tác và nhà cung cấp | ⚠ B2B collaboration |

⚠ Với ứng dụng hướng người tiêu dùng: | Nhu cầu | External ID đáp ứng | |---|---| | ⚠ Hàng triệu người dùng | ⚠ thiết kế cho quy mô lớn | | ⚠ Tự đăng ký | ⚠ email, số điện thoại, hoặc tài khoản mạng xã hội | | ⚠ Giao diện đăng nhập mang thương hiệu riêng | ⚠ tuỳ biến hoàn toàn | | ⚠ Tách biệt khỏi danh bạ nhân viên | ⚠ tenant riêng |

Vì sao các phương án khác sai

• A (gộp hai danh bạ) — ⚠ đó là bài toán sáp nhập tenant, dùng cross-tenant synchronization hoặc công cụ di chuyển.

• C (lo ngại bảo mật) — ⚠ quá mơ hồ, không phải một tình huống cụ thể.

• D (tích hợp Google) — ⚠ là một TÍNH NĂNG của external identities, không phải lý do để dùng nó.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23786 trong lô này hỏi tính năng nào của External ID cho phép người ngoài truy cập (đáp án B2B collaboration và B2C). ⚠ Câu này hỏi KHI NÀO nên dùng. Hai câu bổ sung nhau.

⚠ B2B và B2C — chọn theo đối tượng: | Tiêu chí | B2B | B2C | |---|---|---| | ⚠ Đối tượng | ⚠ đối tác, nhà cung cấp | ⚠ khách hàng, người tiêu dùng | | ⚠ Quy mô | ⚠ hàng nghìn | ⚠ hàng triệu | | ⚠ Danh bạ | ⚠ cùng tenant, là khách mời | ⚠ tenant RIÊNG | | ⚠ Đăng nhập bằng | ⚠ tài khoản tổ chức của họ | ⚠ email, mạng xã hội, tài khoản cục bộ | | ⚠ Giao diện | ⚠ của Microsoft | ⚠ tuỳ biến thương hiệu | | ⚠ Chi phí | ⚠ theo MAU | ⚠ theo MAU |

Từ khoá nhận diện:

"ứng dụng cho khách hàng, hàng triệu người dùng" → ⚠ B2C hoặc External ID for customers "đối tác dùng tài khoản của họ" → ⚠ B2B collaboration "nhân viên của mình" → ⚠ người dùng nội bộ thường "gộp hai tenant" → ⚠ cross-tenant sync, không phải external identities

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng ngoài là đối tác hay khách hàng | ⚠ quyết định B2B hay B2C | | Quy mô dự kiến bao nhiêu tài khoản | | | Có yêu cầu tuỳ biến giao diện đăng nhập không | |

Và nguyên tắc phân định gọn nhất giữa hai hướng: B2B là người của tổ chức khác, B2C là người của chính họ. Đối tác đã có danh tính doanh nghiệp để mượn; khách hàng thì bạn phải tự cấp cho họ một danh tính.

Đáp án

D — User risk-based Conditional Access policy (chính sách dựa trên rủi ro NGƯỜI DÙNG).

Vì sao đúng

⚠ Identity Protection có HAI loại chính sách rủi ro, khác nhau ở cấp độ: | Loại | Đánh giá gì | Phản ứng thường dùng | |---|---|---| | ⚠ User risk policy | ⚠ RỦI RO CỦA TÀI KHOẢN — tích luỹ theo thời gian | ⚠ buộc ĐỔI MẬT KHẨU | | ⚠ Sign-in risk policy | ⚠ rủi ro của LẦN đăng nhập cụ thể này | ⚠ buộc MFA |

⚠ Đề hỏi rõ "ở mức NGƯỜI DÙNG" → ⚠ đó là user risk policy.

⚠ Tín hiệu tạo nên user risk: | Tín hiệu | Nội dung | |---|---| | ⚠ Leaked credentials | ⚠ mật khẩu xuất hiện trong dữ liệu rò rỉ công khai | | ⚠ Nhiều phát hiện rủi ro tích luỹ | | | ⚠ Tình báo mối đe doạ của Microsoft | |

Vì sao các phương án khác sai

• B (sign-in risk-based policy) — ⚠ đúng loại cơ chế nhưng SAI CẤP ĐỘ; nó xét từng lần đăng nhập, không xét tài khoản.

• A (Microsoft Identity Manager) — ⚠ sản phẩm quản lý định danh TẠI CHỖ.

• C (Entra Verified ID) — ⚠ thông tin xác thực có thể kiểm chứng — decentralized identity.

Ghi nhớ

⚠ Phân biệt hai chính sách bằng câu hỏi chúng trả lời: | Chính sách | Câu hỏi | |---|---| | ⚠ User risk | ⚠ TÀI KHOẢN này có dấu hiệu bị chiếm không | | ⚠ Sign-in risk | ⚠ LẦN đăng nhập này có bất thường không | | ⚠ Vì sao phản ứng khác nhau | ⚠ tài khoản bị chiếm thì phải đổi mật khẩu; đăng nhập lạ thì chỉ cần xác minh thêm |

Từ khoá nhận diện:

"mức người dùng, tài khoản" → ⚠ user risk policy "lần đăng nhập này" → ⚠ sign-in risk policy "phát hiện rủi ro định danh" → ⚠ Identity Protection "chứng thực có thể kiểm chứng" → ⚠ Verified ID

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có chính sách rủi ro nào đang bật không | | | Có người dùng nào đang ở mức rủi ro cao chưa xử lý không | | | Tài khoản khẩn cấp đã được loại trừ chưa | |

Và lý do hai chính sách này nên bật cùng nhau: chúng bắt hai thứ khác nhau. Sign-in risk bắt kẻ tấn công đang gõ cửa; user risk bắt tài khoản mà mật khẩu đã lọt ra ngoài từ trước — và cái sau thường nguy hiểm hơn vì im lặng hơn.

Đáp án

A và C — Passwordless authentication và Multi-factor authentication.

Vì sao đúng

⚠ Hai biện pháp cùng nhắm vào điểm yếu của mật khẩu: | Biện pháp | Cách hoạt động | |---|---| | ⚠ MFA | ⚠ mật khẩu lộ vẫn KHÔNG đủ để vào | | ⚠ Passwordless | ⚠ BỎ HẲN mật khẩu — không còn gì để đánh cắp |

Vì sao các phương án khác sai

• D (dùng chung một mật khẩu cho nhiều ứng dụng) — ⚠ thực hành TỆ; giải pháp đúng là SSO chứ không phải dùng lại mật khẩu.

• B (chặn người dùng khi họ trở nên rủi ro) — ⚠ là một PHẢN ỨNG hợp lý của user risk policy, nhưng chặn thẳng thường quá gắt: ⚠ khuyến nghị là buộc đổi mật khẩu trước; và đây không phải biện pháp giảm phụ thuộc mật khẩu như đề nhắm tới.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với #23789 ở lô trước.

⚠ Ba phương thức passwordless của Entra ID: | Phương thức | Đặc điểm | |---|---| | ⚠ Windows Hello for Business | ⚠ sinh trắc học hoặc PIN gắn với thiết bị | | ⚠ FIDO2 security key | ⚠ khoá phần cứng, CHỐNG PHISHING tốt nhất | | ⚠ Microsoft Authenticator | ⚠ duyệt trên điện thoại, có number matching |

Từ khoá nhận diện:

"yếu tố thứ hai" → ⚠ MFA "bỏ hẳn mật khẩu" → ⚠ passwordless "một lần đăng nhập cho nhiều ứng dụng" → ⚠ SSO "chặn tài khoản rủi ro" → ⚠ user risk policy của Identity Protection

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bao nhiêu người dùng chưa đăng ký MFA | | | Legacy authentication đã bị chặn chưa | | | Có lộ trình passwordless chưa | |

Và bước hay bị bỏ sót khiến MFA mất tác dụng: không chặn legacy authentication. Chính sách MFA có đó, trông rất chặt, nhưng kẻ tấn công đăng nhập bằng IMAP hoặc SMTP AUTH thì đi vòng qua toàn bộ.

Đáp án

D — Single Sign-On (SSO).

Vì sao đúng

⚠ SSO giải quyết đúng hai điều đề nêu: | Vấn đề | SSO giải quyết | |---|---| | ⚠ Không phải nhớ thêm mật khẩu | ⚠ dùng chính tài khoản Entra ID | | ⚠ Giảm số lần bị hỏi khi xác thực | ⚠ đăng nhập một lần cho nhiều ứng dụng |

⚠ Các cách SSO của Entra ID với ứng dụng bên thứ ba: | Cách | Nội dung | |---|---| | ⚠ SAML 2.0 | ⚠ phổ biến với ứng dụng doanh nghiệp | | ⚠ OpenID Connect | ⚠ hiện đại, dựa trên OAuth 2.0 | | ⚠ Password-based SSO | ⚠ Entra ID điền hộ mật khẩu, cho ứng dụng cũ không hỗ trợ liên kết | | ⚠ Linked SSO | ⚠ chỉ là liên kết tới nơi đăng nhập khác | | ⚠ Header-based | ⚠ qua Application Proxy |

Vì sao các phương án khác sai

• B (Conditional Access) — ⚠ khai điều kiện đăng nhập; thường LÀM TĂNG số lần bị hỏi chứ không giảm.

• C (MFA) — ⚠ thêm một bước xác minh, cũng làm tăng chứ không giảm.

• A (Passwordless) — ⚠ bỏ mật khẩu, nhưng vẫn phải xác thực ở từng ứng dụng nếu không có SSO.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với #23788 ở lô trước.

⚠ SSO và MFA — vai trò trái ngược nhưng bổ sung: | Cơ chế | Ảnh hưởng tới trải nghiệm | |---|---| | ⚠ SSO | ⚠ GIẢM số lần đăng nhập — tiện hơn | | ⚠ MFA | ⚠ TĂNG bước xác minh — an toàn hơn | | ⚠ Kết hợp | ⚠ xác thực mạnh MỘT LẦN, rồi dùng khắp nơi | | ⚠ Đây là | ⚠ lý do hai thứ này luôn đi cùng nhau |

Từ khoá nhận diện:

"một bộ thông tin cho nhiều ứng dụng" → ⚠ SSO "thêm yếu tố xác minh" → ⚠ MFA "điều kiện đăng nhập" → ⚠ Conditional Access "bỏ mật khẩu" → ⚠ passwordless

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn ứng dụng nào có mật khẩu riêng không | | | SSO đã đi kèm MFA chưa | | | Có bao nhiêu ứng dụng đã tích hợp Entra ID | |

Và giá trị bảo mật thật của SSO, ngoài sự tiện lợi: khi một người rời tổ chức, tắt một tài khoản là đóng được mọi cánh cửa. Với mỗi ứng dụng có mật khẩu riêng, việc thu hồi quyền trở thành một danh sách kiểm tra dài và dễ bỏ sót.

Đáp án

A — Service Principals.

Vì sao đúng

⚠ Service principal là định danh của ứng dụng trong tenant, và là đối tượng gán vai trò RBAC được: | Gán vai trò cho service principal để | Nội dung | |---|---| | ⚠ Ứng dụng truy cập tài nguyên Azure | | | ⚠ Pipeline CI/CD triển khai hạ tầng | | | ⚠ Managed identity truy cập Key Vault, Storage | ⚠ managed identity là một dạng service principal |

Vì sao các phương án khác sai

• D (Network Security Groups) — ⚠ là TÀI NGUYÊN, không phải security principal; không gán vai trò cho nó được.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề là chọn MỘT, nhưng ba phương án B, C, E cũng gán được vai trò trong thực tế.

⚠ Bốn loại security principal trong Azure RBAC: | Loại | Nội dung | |---|---| | ⚠ User | ⚠ người dùng, kể cả khách B2B | | ⚠ Group | ⚠ nhóm bảo mật — cách gán quyền TỐT NHẤT | | ⚠ Service principal | ⚠ định danh của ứng dụng | | ⚠ Managed identity | ⚠ service principal do Azure tự quản |

Từ khoá nhận diện:

"định danh của ứng dụng" → ⚠ service principal "ứng dụng chạy trong Azure, không có bí mật" → ⚠ managed identity "nhóm người dùng" → ⚠ security group, nên gán quyền cho nhóm "tài nguyên như NSG, VM" → ⚠ là ĐỐI TƯỢNG được bảo vệ, không phải principal

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có service principal nào giữ quyền Owner không | | | Service principal nào còn dùng client secret | ⚠ cân nhắc chuyển sang managed identity hoặc chứng chỉ | | Có tài khoản khách nào giữ quyền quá rộng không | |

Và loại định danh hay bị quên nhất khi rà soát quyền: service principal của các ứng dụng cũ. Người thì có quy trình nghỉ việc; ứng dụng bị bỏ thì service principal của nó vẫn còn đó với nguyên bộ quyền, im lặng, không ai để ý.

Đáp án

A, C và E.

• A — Gán vai trò CÓ THỜI HẠN.
• C — Tiến hành đánh giá quyền truy cập cho người dùng và nhóm.
• E — Triển khai kiểm soát truy cập dựa trên vai trò.

Vì sao đúng

⚠ Ba việc PIM làm: | Việc | Nội dung | |---|---| | ⚠ Gán vai trò có thời hạn | ⚠ eligible và active, hết hạn tự thu hồi | | ⚠ Access Reviews | ⚠ rà soát định kỳ ai còn cần vai trò gì | | ⚠ Quản lý vai trò RBAC | ⚠ cả vai trò Entra ID lẫn vai trò tài nguyên Azure |

Vì sao các phương án khác sai

• B (tự động cấp quyền cho MỌI người dùng) — ⚠ NGƯỢC hoàn toàn với mục đích của PIM là quyền tối thiểu.

• D (cấu hình chính sách đặt lại mật khẩu) — ⚠ đó là Self-Service Password Reset và Password Protection, không thuộc PIM.

Ghi nhớ

⚠ Đối chiếu: ⚠ lô trước có #23791 và #23824, cả hai đều chỉ về PIM. ⚠ Câu này liệt kê phạm vi chức năng của nó. Ba câu nhất quán.

⚠ Access Reviews — phần hay bị quên của PIM: | Khả năng | Nội dung | |---|---| | ⚠ Rà soát thành viên nhóm | | | ⚠ Rà soát quyền vào ứng dụng | | | ⚠ Rà soát vai trò đặc quyền | | | ⚠ Rà soát người dùng khách | ⚠ rất quan trọng, hay tích tụ | | ⚠ Người rà soát | ⚠ quản trị viên, chủ sở hữu nhóm, hoặc CHÍNH người dùng tự xác nhận | | ⚠ Tự động gỡ quyền | ⚠ nếu không ai phản hồi |

Từ khoá nhận diện:

"quyền có thời hạn, kích hoạt khi cần" → ⚠ PIM "rà soát định kỳ ai còn cần quyền" → ⚠ Access Reviews, thuộc PIM và Identity Governance "tự đặt lại mật khẩu" → ⚠ SSPR "gói quyền có hạn cho người ngoài" → ⚠ Entitlement Management

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có Access Review nào đang chạy không | | | Lần cuối rà soát tài khoản khách là khi nào | | | Bao nhiêu vai trò quản trị đang là thường trực | |

Và quy luật gần như bất biến trong mọi tổ chức không có rà soát định kỳ: quyền chỉ tăng, không bao giờ giảm. Mỗi dự án thêm một chút, mỗi lần đổi việc giữ lại một chút — sau vài năm, không ai còn biết ai đang có quyền gì và vì sao.

Đáp án

A — User assignment (yêu cầu gán người dùng).

Vì sao đúng

⚠ Thiết lập "User assignment required?" trong Enterprise Application: | Giá trị | Hành vi | |---|---| | ⚠ Yes | ⚠ CHỈ người dùng hoặc nhóm ĐÃ ĐƯỢC GÁN mới truy cập được | | ⚠ No | ⚠ mọi người trong tổ chức đều truy cập được |

⚠ Đây là cách kiểm soát chính xác ai được vào ứng dụng nội bộ.

Vì sao các phương án khác sai

• C (Supported account types) — ⚠ khai ai được ĐĂNG NHẬP về mặt loại tài khoản — một tổ chức, nhiều tổ chức, hay cả tài khoản cá nhân; ⚠ nó giới hạn ở mức tenant, không chỉ định được người dùng cụ thể trong tổ chức.

• B (Application properties) — ⚠ là MỤC chứa thiết lập đó, không phải tên thiết lập.

• D (Identity Provider Configuration) — ⚠ cấu hình nhà cung cấp định danh liên kết.

Ghi nhớ

⚠ Hai lớp kiểm soát truy cập ứng dụng — dễ nhầm: | Lớp | Kiểm soát | |---|---| | ⚠ Supported account types | ⚠ loại TÀI KHOẢN nào đăng nhập được — single tenant, multitenant, personal | | ⚠ User assignment required | ⚠ NGƯỜI NÀO trong tenant được vào | | ⚠ Kết hợp | ⚠ single tenant CỘNG user assignment = chỉ đúng những người bạn chọn |

⚠ Ba mức hạn chế từ rộng tới hẹp: | Mức | Cấu hình | |---|---| | ⚠ Rộng nhất | ⚠ multitenant, không yêu cầu gán | | ⚠ Vừa | ⚠ single tenant, không yêu cầu gán — mọi nhân viên vào được | | ⚠ Hẹp nhất | ⚠ single tenant, YÊU CẦU gán — chỉ người được chọn | | ⚠ Thêm lớp nữa | ⚠ Conditional Access theo thiết bị, vị trí, mức rủi ro |

Từ khoá nhận diện:

"chỉ người được gán mới vào được" → ⚠ User assignment required "chỉ tổ chức của tôi đăng nhập được" → ⚠ supported account types = single tenant "chỉ vào được từ thiết bị tuân thủ" → ⚠ Conditional Access "vai trò trong chính ứng dụng" → ⚠ App roles

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có bật user assignment required không | | | Supported account types có rộng hơn cần thiết không | | | Gán quyền cho NHÓM hay cho từng cá nhân | ⚠ nhóm dễ bảo trì hơn nhiều |

Và cấu hình mặc định cần chú ý khi đăng ký một ứng dụng nội bộ: user assignment mặc định là KHÔNG bắt buộc. Nghĩa là mọi nhân viên trong tổ chức đều đăng nhập được vào ứng dụng đó — kể cả khi bạn chỉ định làm cho một phòng ban.

Đáp án

A, B, C — và một phương án thứ tư theo khoá đáp án

Vì sao đúng

Service principal là danh tính của một ứng dụng trong Entra ID, và ba chức năng chắc chắn đúng là:

• A. Làm danh tính để ứng dụng tương tác với Entra ID — đây là lý do tồn tại của nó: ứng dụng cần một thứ để "là ai đó" khi gọi API.
• B. Cấp quyền OAuth cho ứng dụng bên ngoài — service principal là nơi các quyền đã được đồng ý (consent) được lưu lại.
• C. Gán quyền tới tài nguyên Azure cụ thể — service principal nhận được vai RBAC y như người dùng, nên ứng dụng truy cập được đúng tài nguyên nó cần.

Vì sao phương án khác sai

• D. Sinh personal access token cho người dùng — thuộc về tài khoản người dùng, không phải service principal.

Ghi chú về chất lượng câu hỏi

Hai phương án E ("trực tiếp xử lý xác thực người dùng") và F ("xác thực người dùng cho đăng nhập tương tác") nói gần như cùng một điều, nhưng khoá đáp án đánh dấu ngược nhau. Về mặt kỹ thuật thì cả hai đều sai: service principal đại diện cho ứng dụng, còn đăng nhập tương tác của con người là việc của tài khoản người dùng. Phần đáng nhớ vẫn là ba chức năng ở trên.