Ngân hàng đề — Microsoft Azure Security Technology
Tìm thấy 100 câu.
You're assessing the overall security posture of your Azure environment. Which tool in Azure provides you with a numeric value indicating the percentage of security best practices you've adhered to?
-
A
Azure Security Center Alerts
-
B
Microsoft Defender for Cloud Secure Score
-
C
Microsoft Purview Compliance Manager
-
D
Azure Advisor Score
Xem giải thích
Đáp án
B — Secure Score của Microsoft Defender for Cloud
Vì sao đúng
Secure Score là một con số phần trăm thể hiện mức độ môi trường của bạn tuân theo các khuyến nghị bảo mật của Microsoft. Điểm mạnh của nó không nằm ở con số mà ở chỗ đi kèm: mỗi khuyến nghị chưa đạt đều có hướng dẫn khắc phục cụ thể và cho biết sửa nó thì điểm tăng bao nhiêu.
Nhờ vậy đội bảo mật có thứ tự ưu tiên dựa trên tác động thật, thay vì làm theo cảm tính.
Vì sao các phương án khác sai
- C. Purview Compliance Manager — cũng có điểm số, nhưng đo mức tuân thủ theo chuẩn và quy định (GDPR, ISO 27001), không phải tư thế bảo mật kỹ thuật của tài nguyên. Đây là phương án nhiễu gần nhất.
- D. Azure Advisor Score — chấm điểm theo năm trụ của khung Well-Architected, trong đó bảo mật chỉ là một phần.
- A. Cảnh báo của Security Center — là sự kiện riêng lẻ khi phát hiện mối đe doạ, không phải một chỉ số tổng hợp.
Your company is deploying an application that requires a secure way to manage application secrets. You are asked to set up a solution that allows for secure secret management, certificate management, and the ability to automate the backup and recovery of these items.
Which of the following should you configure? (Select three)
-
A
Azure Blueprint
-
B
Azure Key Vault
-
C
Configure key rotation in Azure Key Vault
-
D
Recovery Services Vault
-
E
Azure Backup
-
F
Configure backup and recovery in Azure Key Vault
Xem giải thích
Đáp án
B, C và F.
- B — Azure Key Vault.
- C — Cấu hình xoay vòng khoá trong Key Vault.
- F — Cấu hình sao lưu và khôi phục trong Key Vault.
Vì sao đúng
⚠ Ba yêu cầu của đề, ba cấu hình trong cùng một dịch vụ: | Yêu cầu | Cấu hình | |---|---| | ⚠ Quản lý bí mật và chứng chỉ an toàn | ⚠ Key Vault | | ⚠ Tự động hoá vòng đời | ⚠ key rotation policy | | ⚠ Sao lưu và khôi phục | ⚠ backup và restore của Key Vault |
Vì sao các phương án khác sai
-
D (Recovery Services Vault) và E (Azure Backup) — ⚠ sao lưu MÁY ẢO, tệp, CSDL; ⚠ KHÔNG sao lưu được nội dung Key Vault.
-
A (Azure Blueprint) — ⚠ đóng gói mẫu môi trường, không quản lý bí mật.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #23818 và #23819 ở lô trước cùng về Key Vault. ⚠ Câu này đi sâu vào hai cấu hình vận hành: xoay vòng và sao lưu. Ba câu nhất quán.
⚠ Key rotation policy — tự động hoá vòng đời khoá: | Cấu hình | Nội dung | |---|---| | ⚠ Chu kỳ xoay vòng | ⚠ ví dụ mỗi 90 ngày | | ⚠ Thông báo trước khi hết hạn | | | ⚠ Tự tạo phiên bản khoá mới | | | ⚠ Lưu ý | ⚠ áp cho KEY; với SECRET thì cần Event Grid và Function tự viết |
⚠ Sao lưu Key Vault — điều cần biết: | Điều | Nội dung | |---|---| | ⚠ Sao lưu từng đối tượng | ⚠ key, secret, certificate riêng lẻ | | ⚠ Bản sao lưu MÃ HOÁ | ⚠ chỉ khôi phục được vào vault CÙNG subscription và CÙNG khu vực địa lý | | ⚠ Không có nút "sao lưu cả vault" | | | ⚠ Soft delete và purge protection là lớp bảo vệ chính | |
Từ khoá nhận diện:
"lưu bí mật, khoá, chứng chỉ" → ⚠ Key Vault "tự động đổi khoá định kỳ" → ⚠ key rotation policy "sao lưu máy ảo và tệp" → ⚠ Azure Backup và Recovery Services Vault "khôi phục vault đã xoá" → ⚠ soft delete
| ⚠ Hai lớp bảo vệ bắt buộc | Lớp |
|---|---|
| ⚠ Soft delete | ⚠ giữ vault và đối tượng đã xoá, nay BẬT MẶC ĐỊNH |
| ⚠ Purge protection | ⚠ không xoá vĩnh viễn được trước hạn |
| ⚠ Với customer-managed key | ⚠ purge protection là BẮT BUỘC |
| ⚠ Vì sao xoay vòng khoá quan trọng | Lý do |
|---|---|
| ⚠ Giới hạn thiệt hại nếu khoá bị lộ | |
| ⚠ Nhiều chuẩn tuân thủ yêu cầu | |
| ⚠ Buộc phát hiện chỗ nào còn hard-code khoá cũ | |
| ⚠ Tự động hoá | ⚠ để nó thật sự diễn ra, thay vì nằm trong tài liệu |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có khoá nào chưa bao giờ được xoay vòng không | | | Purge protection đã bật chưa | | | Có quy trình khôi phục Key Vault đã thử chưa | |
Và lợi ích phụ đáng giá của việc xoay vòng khoá tự động: nó buộc lộ ra mọi chỗ còn hard-code khoá cũ. Ứng dụng nào hỏng sau lần xoay đầu tiên chính là ứng dụng đang giữ bí mật ở nơi không nên giữ.
In what specific scenarios is it advisable to use a dedicated Hardware Security Module (HSM)?
-
A
When implementing basic data encryption for non-sensitive information in a small-scale application
-
B
When managing authentication tokens for user access control in a cloud-based software solution
-
C
When strict cryptographic protection is needed for highly sensitive data and cryptographic keys,
-
D
When deploying a low-security web application that has minimal data encryption requirements
Xem giải thích
Đáp án
C — Khi cần bảo vệ mật mã ở mức nghiêm ngặt cho dữ liệu rất nhạy cảm
Vì sao đúng
Hardware Security Module là thiết bị phần cứng chuyên dụng, và nó có một đặc tính quyết định: khoá được sinh ra và tồn tại bên trong module, không bao giờ rời ra dưới dạng đọc được. Mọi thao tác mã hoá diễn ra bên trong thiết bị.
Vì vậy nó chỉ đáng dùng khi có yêu cầu tương xứng: dữ liệu rất nhạy cảm, hoặc quy định bắt buộc mức chứng nhận cụ thể — ví dụ FIPS 140-2 Level 3, mức mà Azure Key Vault bậc thường không đạt.
Vì sao các phương án khác sai
- A. Mã hoá cơ bản cho dữ liệu không nhạy cảm và D. Ứng dụng web mức bảo mật thấp — HSM đắt và phức tạp hơn nhiều so với nhu cầu; mã hoá mặc định của nền tảng đã đủ.
- B. Quản lý token xác thực — token có vòng đời ngắn và được xử lý bởi dịch vụ danh tính, không phải trường hợp cần HSM.
You are tasked with limiting the inbound traffic to a specific application within your Azure virtual network.
Which Azure resource should you configure?
-
A
Application Security Groups
-
B
Virtual Network Peering
-
C
User-defined route
-
D
Virtual WAN
Xem giải thích
Đáp án
A — Application Security Group (ASG)
Vì sao đúng
ASG cho phép nhóm các máy ảo theo vai trò ứng dụng rồi dùng nhóm đó làm nguồn hoặc đích trong luật NSG. Nhờ vậy bạn viết luật kiểu "chỉ nguồn thuộc ASG web mới tới được đích thuộc ASG db", thay vì phải liệt kê địa chỉ IP.
Lợi ích thực tế lớn nhất: máy mới thêm vào nhóm là tự động chịu đúng luật, không phải sửa gì — điều rất quan trọng khi hệ thống co giãn.
Vì sao các phương án khác sai
- B. VNet Peering — nối hai mạng ảo với nhau, không lọc lưu lượng.
- C. User-defined route — quyết định gói tin đi đường nào, không quyết định nó có được phép hay không. Đây là cặp hay bị lẫn: route lo đường đi, NSG lo cho phép.
- D. Virtual WAN — dịch vụ nối nhiều chi nhánh và mạng lại với nhau ở quy mô lớn.
A company is implementing enhanced security controls. Which of the following actions can help in managing temporary, 'just-in-time' elevated access to Azure resources and Microsoft Entra ID, and also periodically reviewing access rights? (Select two)
-
A
Configure Azure role permissions for subscriptions
-
B
Implement Microsoft Entra Permissions Management
-
C
Configure Microsoft Entra Privileged Identity Management (PIM)
-
D
Configure role management and access reviews in Microsoft Entra
Xem giải thích
Đáp án
C và D.
- C — Cấu hình Microsoft Entra Privileged Identity Management (PIM).
- D — Cấu hình quản lý vai trò và access reviews trong Microsoft Entra.
Vì sao đúng
⚠ Hai yêu cầu của đề, hai cấu hình: | Yêu cầu | Cấu hình | |---|---| | ⚠ Quyền nâng cao TẠM THỜI, just-in-time | ⚠ PIM — eligible, kích hoạt có hạn | | ⚠ RÀ SOÁT ĐỊNH KỲ quyền truy cập | ⚠ Access Reviews trong quản lý vai trò |
Vì sao các phương án khác sai
-
A (cấu hình quyền vai trò Azure cho subscription) — ⚠ là gán quyền THƯỜNG TRỰC, không có yếu tố tạm thời hay rà soát.
-
B (Microsoft Entra Permissions Management) — ⚠ là CIEM — quản lý quyền ĐA ĐÁM MÂY: phát hiện quyền thừa trên Azure, AWS, GCP; ⚠ hữu ích nhưng không phải cơ chế just-in-time như PIM.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #23832 ở lô trước liệt kê ba việc của PIM, trong đó có Access Reviews. ⚠ Câu này hỏi cùng nội dung từ góc tình huống. Hai câu nhất quán.
⚠ Ba công cụ quản trị quyền — phân biệt: | Công cụ | Việc | |---|---| | ⚠ PIM | ⚠ quyền ĐẶC QUYỀN có thời hạn, kích hoạt khi cần | | ⚠ Access Reviews | ⚠ rà soát định kỳ ai còn cần quyền gì | | ⚠ Permissions Management | ⚠ phát hiện quyền THỪA trên nhiều đám mây — CIEM | | ⚠ Entitlement Management | ⚠ gói quyền có người duyệt, có hạn, cho cả người ngoài |
Từ khoá nhận diện:
"just-in-time, quyền tạm thời" → ⚠ PIM "rà soát định kỳ" → ⚠ Access Reviews "quyền thừa trên AWS và GCP" → ⚠ Permissions Management "gói quyền cho đối tác" → ⚠ Entitlement Management
| ⚠ Access Reviews rà soát được gì | Đối tượng |
|---|---|
| ⚠ Thành viên nhóm | |
| ⚠ Quyền vào ứng dụng | |
| ⚠ Vai trò đặc quyền Entra ID và Azure | |
| ⚠ Người dùng khách | ⚠ hay tích tụ nhất |
| ⚠ Người rà soát | ⚠ quản trị viên, chủ nhóm, hoặc chính người dùng tự xác nhận |
| ⚠ Nếu không phản hồi | ⚠ cấu hình được là TỰ GỠ quyền |
| ⚠ Yêu cầu giấy phép | Yêu cầu |
|---|---|
| ⚠ PIM và Access Reviews | ⚠ Entra ID P2 hoặc Entra ID Governance |
| ⚠ Permissions Management | ⚠ giấy phép riêng |
| ⚠ Không có P2 | ⚠ chỉ còn cách gán quyền thường trực và rà soát thủ công |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có Access Review nào đang chạy không | | | Bao nhiêu vai trò quản trị đang là thường trực | | | Lần cuối rà soát tài khoản khách là khi nào | |
Và quy luật gần như bất biến trong 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 vị trí giữ lại một chút — và sau vài năm không ai còn giải thích được vì sao một người lại có quyền đó.
You are tasked with assigning permissions to an Azure resource group. Which of the following is the most appropriate method to assign these permissions?
-
A
Assign a built-in role in Microsoft Entra ID
-
B
Configure Conditional Access policies
-
C
Azure role-based access control (Azure RBAC)
-
D
Implement Microsoft Entra Permissions Management
Xem giải thích
Đáp án
C — Azure role-based access control (Azure RBAC).
Vì sao đúng
⚠ Azure RBAC là cơ chế gán quyền cho TÀI NGUYÊN Azure: | Phạm vi gán được | Cấp | |---|---| | ⚠ Management group | ⚠ rộng nhất | | ⚠ Subscription | | | ⚠ Resource group | ⚠ cấp mà đề hỏi | | ⚠ Resource | ⚠ hẹp nhất | | ⚠ Quyền | ⚠ KẾ THỪA từ trên xuống dưới |
Vì sao các phương án khác sai
-
A (gán vai trò tích hợp trong Entra ID) — ⚠ Entra roles quản DANH BẠ — người dùng, nhóm, ứng dụng; ⚠ không gán được cho resource group.
-
B (Conditional Access) — ⚠ khai điều kiện ĐĂNG NHẬP, không cấp quyền trên tài nguyên.
-
D (Permissions Management) — ⚠ PHÁT HIỆN quyền thừa, không phải công cụ để gán quyền.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #23792 ở lô trước liệt kê ba cơ chế gán vai trò (RBAC, Entra roles, PIM), còn #22194 hỏi chữ R trong RBAC là gì. ⚠ Ba câu nhất quán.
⚠ Azure RBAC và Entra roles — hai hệ thống TÁCH BIỆT: | Tiêu chí | Azure RBAC | Entra roles | |---|---|---| | ⚠ Quản gì | ⚠ tài nguyên Azure | ⚠ danh bạ Entra ID | | ⚠ Phạm vi | ⚠ MG → subscription → RG → resource | ⚠ toàn tenant hoặc administrative unit | | ⚠ Vai trò tiêu biểu | ⚠ Owner, Contributor, Reader | ⚠ Global Administrator, User Administrator | | ⚠ Quản ở đâu | ⚠ tab Access control (IAM) | ⚠ Roles and administrators |
Từ khoá nhận diện:
"quyền trên resource group, máy ảo, storage" → ⚠ Azure RBAC "quyền tạo và xoá người dùng" → ⚠ Entra roles "quyền tạm thời" → ⚠ PIM "cái gì được phép tạo" → ⚠ Azure Policy
| ⚠ Bốn vai trò RBAC cơ bản | Vai trò |
|---|---|
| ⚠ Reader | ⚠ chỉ xem |
| ⚠ Contributor | ⚠ tạo và sửa, NHƯNG không cấp quyền |
| ⚠ Owner | ⚠ toàn quyền, kể cả cấp quyền |
| ⚠ User Access Administrator | ⚠ chỉ quản việc cấp quyền |
| ⚠ Thực hành tốt | Thực hành |
|---|---|
| ⚠ Gán cho NHÓM, không gán cho cá nhân | |
| ⚠ Phạm vi hẹp nhất đủ dùng | ⚠ resource group thường là mức hợp lý |
| ⚠ Dùng vai trò tích hợp trước | |
| ⚠ Rất ít Owner ở cấp subscription | |
| ⚠ Rà soát định kỳ bằng Access Reviews |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quyền gán ở mức nào — subscription hay resource group | | | Có quyền nào gán trực tiếp cho cá nhân không | | | Ai giữ vai Owner và có cần thiết không | |
Và mức phạm vi hợp lý nhất cho phần lớn trường hợp: resource group. Gán ở subscription thường rộng quá mức cần thiết, còn gán ở từng tài nguyên thì nhanh chóng trở nên không quản nổi.
Your organization is planning to centralize authentication for several applications. Which solution enables users to authenticate once and gain access to multiple applications?
-
A
Password Protection
-
B
Multi-Factor Authentication
-
C
Passwordless Authentication
-
D
Single Sign-On (SSO)
Xem giải thích
Đáp án
D — Single Sign-On (SSO).
Vì sao đúng
⚠ SSO cho phép xác thực MỘT LẦN rồi vào nhiều ứng dụng: | Lợi ích | Nội dung | |---|---| | ⚠ Một bộ thông tin đăng nhập | | | ⚠ Ít mật khẩu hơn = ít rủi ro hơn | | | ⚠ Tắt một tài khoản là đóng mọi cửa | | | ⚠ Nhật ký đăng nhập tập trung | | | ⚠ Áp chính sách chung cho mọi ứng dụng | |
Vì sao các phương án khác sai
-
B (MFA) và C (Passwordless) — ⚠ về CHẤT LƯỢNG xác thực, không phải về việc dùng chung một lần đăng nhập.
-
A (Password Protection) — ⚠ chặn mật khẩu yếu.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu THỨ BA về SSO trong hai lô gần nhau.
| Câu | Đề bài | Khoá |
|---|---|---|
| ⚠ #23788 | ⚠ "dịch vụ nào cho dùng một bộ thông tin đăng nhập cho nhiều ứng dụng" | ⚠ C |
| ⚠ #23830 | ⚠ "tính năng nào giúp không phải nhớ thêm mật khẩu, giảm số lần hỏi" | ⚠ D |
| ⚠ #23861 (câu này) | ⚠ "giải pháp nào cho xác thực một lần, vào nhiều ứng dụng" | ⚠ D |
| ⚠ Nội dung | ⚠ cùng một khái niệm, ba cách diễn đạt | |
| ⚠ Chữ cái | ⚠ C, D, D — phải đọc kỹ phương án mỗi lần | |
| ⚠ Không mâu thuẫn | ⚠ giữ nguyên cả ba khoá |
⚠ Các giao thức SSO Entra ID hỗ trợ: | Giao thức | Dùng cho | |---|---| | ⚠ SAML 2.0 | ⚠ ứng dụng doanh nghiệp truyền thống | | ⚠ OpenID Connect | ⚠ ứng dụng hiện đại | | ⚠ OAuth 2.0 | ⚠ uỷ quyền truy cập API | | ⚠ Password-based SSO | ⚠ ứng dụng cũ không hỗ trợ liên kết | | ⚠ Header-based | ⚠ qua Application Proxy |
Từ khoá nhận diện:
"một lần đăng nhập, nhiều ứng dụng" → ⚠ SSO "thêm yếu tố xác minh" → ⚠ MFA "bỏ mật khẩu" → ⚠ passwordless "chặn mật khẩu yếu" → ⚠ Password Protection
| ⚠ SSO không có MFA — vì sao nguy hiểm | Lý do |
|---|---|
| ⚠ Một mật khẩu mở được MỌI ứng dụng | |
| ⚠ Rủi ro dồn hết vào một điểm | |
| ⚠ Kẻ tấn công chỉ cần thành công một lần | |
| ⚠ Vì thế | ⚠ SSO và MFA phải đi cùng nhau, không phải chọn một |
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 | | | Legacy authentication đã bị chặn chưa | |
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 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 là một danh sách dài và luôn sót vài mục.
Which of the following authentication methods are considered passwordless? (Select three)
-
A
Microsoft Authenticator app
-
B
Security Questions
-
C
FIDO2 security keys
-
D
SMS-based One-Time Password (OTP)
-
E
Windows Hello for Business
Xem giải thích
Đáp án
A, C và E — Microsoft Authenticator app, FIDO2 security keys, và Windows Hello for Business.
Vì sao đúng
⚠ Ba phương thức passwordless chính thức của Entra ID: | Phương thức | Yếu tố | |---|---| | ⚠ 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 kèm number matching và sinh trắc học |
⚠ Điểm chung: ⚠ KHÔNG có mật khẩu nào được nhập hay truyền đi.
Vì sao các phương án khác sai
-
D (OTP qua SMS) — ⚠ là yếu tố THỨ HAI trong MFA, vẫn cần mật khẩu ở bước đầu; ⚠ và SMS là phương thức yếu nhất vì bị đánh cắp SIM.
-
B (câu hỏi bí mật) — ⚠ vẫn là "thứ bạn BIẾT", cùng loại với mật khẩu và thường còn dễ đoán hơn.
Ghi nhớ
⚠ Ba loại yếu tố xác thực: | Loại | Ví dụ | |---|---| | ⚠ Thứ bạn BIẾT | ⚠ mật khẩu, PIN, câu hỏi bí mật | | ⚠ Thứ bạn CÓ | ⚠ điện thoại, khoá FIDO2, thẻ thông minh | | ⚠ Thứ bạn LÀ | ⚠ vân tay, khuôn mặt | | ⚠ Passwordless | ⚠ bỏ hẳn loại thứ nhất, dùng hai loại còn lại |
⚠ Xếp hạng độ mạnh: | Phương thức | Mức | |---|---| | ⚠ FIDO2 và Windows Hello | ⚠ mạnh nhất — chống phishing | | ⚠ Authenticator có number matching | ⚠ rất tốt | | ⚠ OTP trong app | ⚠ tốt | | ⚠ Gọi điện | ⚠ yếu hơn | | ⚠ SMS | ⚠ YẾU NHẤT |
Từ khoá nhận diện:
"không nhập mật khẩu nào" → ⚠ passwordless "mật khẩu cộng OTP" → ⚠ MFA, không phải passwordless "chống phishing về mặt kỹ thuật" → ⚠ FIDO2 "câu hỏi bí mật" → ⚠ vẫn là thứ bạn biết, không phải yếu tố mạnh
| ⚠ Vì sao SMS yếu | Lý do |
|---|---|
| ⚠ Đánh cắp SIM | ⚠ SIM swap |
| ⚠ Chặn được trên mạng viễn thông | |
| ⚠ Không chống được phishing thời gian thực | |
| ⚠ NIST | ⚠ đã khuyến nghị hạn chế dùng SMS từ lâu |
| ⚠ Vì sao FIDO2 chống phishing được | Cơ chế |
|---|---|
| ⚠ Khoá gắn với TÊN MIỀN cụ thể | |
| ⚠ Trang giả có tên miền khác → khoá KHÔNG ký | |
| ⚠ Không có mã nào để người dùng gõ nhầm chỗ | |
| ⚠ Khác với OTP | ⚠ người dùng vẫn có thể bị lừa gõ mã vào trang giả |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đang dựa vào SMS làm phương thức chính không | | | Bao nhiêu người đã đăng ký phương thức passwordless | | | Tài khoản quản trị có dùng FIDO2 không | ⚠ nên bắt đầu từ nhóm này |
Và khác biệt cốt lõi giữa MFA truyền thống và passwordless: MFA thêm một lớp lên trên mật khẩu; passwordless bỏ hẳn mật khẩu đi. Cái sau vừa an toàn hơn vừa tiện hơn — hiếm khi hai điều đó đi cùng nhau trong bảo mật.
For an App Service web application that utilizes an SQL database, what is the necessary configuration step to allow users to authenticate to the database using their Microsoft Entra credentials?
-
A
Enable Microsoft Entra Authentication
-
B
Create an SQL Database Administrator
-
C
Create users in each database
Xem giải thích
Đáp án
A — Bật Microsoft Entra Authentication cho máy chủ SQL
Vì sao đúng
Đây là bước bắt buộc đầu tiên: nếu chưa bật xác thực bằng Entra ID trên máy chủ SQL logic thì mọi bước sau đều không làm được — không tạo được người dùng dựa trên danh tính Entra, và ứng dụng không thể lấy token để kết nối.
Lợi ích của việc chuyển sang mô hình này rất rõ: không còn mật khẩu SQL nào trong chuỗi kết nối, và quyền được quản lý tập trung ở Entra ID nên thu hồi ở một chỗ là mất quyền ở mọi nơi.
Vì sao các phương án khác sai
- B. Tạo quản trị viên cho SQL Database — là bước tiếp theo sau khi đã bật, và nó cũng cần xác thực Entra được bật trước.
- C. Tạo người dùng trong từng cơ sở dữ liệu — cũng là bước sau; đây là nơi bạn gán quyền cụ thể, nhưng phải có nền tảng xác thực trước đã.
Which of the following are features of Microsoft Entra Identity Protection? (Select three)
-
A
Risk-based conditional access policies
-
B
Vulnerability scans of Azure resources
-
C
Investigate risk events using relevant and contextual information
-
D
Leverage automated risk detection
-
E
Network security
Xem giải thích
Đáp án
A, C và D.
- A — Chính sách truy cập có điều kiện dựa trên rủi ro.
- C — Điều tra sự kiện rủi ro bằng thông tin ngữ cảnh liên quan.
- D — Tận dụng phát hiện rủi ro tự động.
Vì sao đúng
⚠ Ba năng lực cốt lõi của Entra ID Protection: | Năng lực | Nội dung | |---|---| | ⚠ Phát hiện tự động | ⚠ thông tin đăng nhập rò rỉ, đăng nhập bất thường, IP ẩn danh | | ⚠ Điều tra | ⚠ ba báo cáo: risky users, risky sign-ins, risk detections | | ⚠ Phản ứng tự động | ⚠ risk-based Conditional Access — buộc MFA hoặc đổi mật khẩu |
Vì sao các phương án khác sai
-
B (quét lỗ hổng tài nguyên Azure) — ⚠ đó là Defender for Cloud, không phải Identity Protection.
-
E (bảo mật mạng) — ⚠ NSG, Azure Firewall; ⚠ Identity Protection chỉ lo ĐỊNH DANH.
Ghi nhớ
⚠ Đối chiếu: ⚠ lô này và lô trước có #23787, #23825 và câu này, cả ba đều về Identity Protection. ⚠ Ba câu nhất quán.
⚠ 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ỉ | | ⚠ 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ạ | | ⚠ Malware linked IP | |
⚠ Hai loại chính sách rủi ro: | Chính sách | Đánh giá | Phản ứng | |---|---|---| | ⚠ User risk | ⚠ rủi ro của TÀI KHOẢN | ⚠ buộc đổi mật khẩu | | ⚠ Sign-in risk | ⚠ rủi ro của LẦN đăng nhập | ⚠ buộc MFA |
Từ khoá nhận diện:
"phát hiện rủi ro định danh" → ⚠ Identity Protection "quét lỗ hổng tài nguyên" → ⚠ Defender for Cloud "quyền quản trị tạm thời" → ⚠ PIM "lọc lưu lượng mạng" → ⚠ NSG, Azure Firewall
| ⚠ Yêu cầu giấy phép | Yêu cầu |
|---|---|
| ⚠ Identity Protection đầy đủ | ⚠ Entra ID P2 |
| ⚠ Bậc thấp hơn | ⚠ chỉ thấy mức rủi ro chung |
| ⚠ Risk-based Conditional Access | ⚠ cần P2 |
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 ở mức rủi ro cao chưa xử lý không | | | Ai rà soát các phát hiện hằng tuần | |
Và điều làm phát hiện dựa trên rủi ro có giá trị riêng: nó dùng tín hiệu từ hàng nghìn tỷ lượt đăng nhập trên toàn cầu. Một mật khẩu lộ ở dịch vụ hoàn toàn khác vẫn khiến tài khoản của bạn bị đánh dấu — điều mà không luật nội bộ nào bắt được.