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

Tìm thấy 100 câu.

Câu 11 Manage identity and access (25-30%)
Which feature of Microsoft Entra ID is primarily used to set up multi-factor authentication for enhanced security of user accounts?
  1. A Conditional Access
  2. B Access Reviews
  3. C Security Groups
  4. D Directory Services
Xem giải thích

Đáp án

A — Conditional Access (truy cập có điều kiện).

Vì sao đúng

⚠ Conditional Access là nơi khai chính sách "khi nào thì đòi MFA": | Thành phần chính sách | Nội dung | |---|---| | ⚠ Assignments | ⚠ áp cho AI — người dùng, nhóm, vai trò | | ⚠ Conditions | ⚠ KHI NÀO — vị trí, thiết bị, ứng dụng, mức rủi ro | | ⚠ Grant controls | ⚠ THÌ SAO — đòi MFA, đòi thiết bị tuân thủ, chặn |

⚠ Ví dụ chính sách:
   ⚠ Ai: quản trị viên
   ⚠ Khi: đăng nhập từ ngoài mạng công ty
   ⚠ Thì: BẮT BUỘC MFA

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

  • B (Access Reviews) — ⚠ rà soát định kỳ xem ai còn cần quyền gì, không cấu hình MFA.

  • C (Security Groups) — ⚠ nhóm người dùng; là đối tượng ÁP chính sách, không phải nơi cấu hình.

  • D (Directory Services) — ⚠ tên gọi chung, không phải tính năng cụ thể.

Ghi nhớ

⚠ Đối chiếu: ⚠ lô 170 có #22092 (tính năng nào cung cấp yếu tố đăng nhập thêm — MFA) và #22152 (bật MFA cho quản trị viên mà không bắt người dùng thường — PIM). ⚠ Câu này hỏi nơi CẤU HÌNH chính sách MFA. Ba câu nhìn cùng một chủ đề từ ba góc.

Câu Hỏi gì Khoá
⚠ #22092 ⚠ tính năng nào là yếu tố đăng nhập thêm ⚠ Multi-Factor Authentication
⚠ #22152 ⚠ bật MFA riêng cho quản trị viên ⚠ PIM
⚠ #23785 (câu này) ⚠ tính năng nào dùng để THIẾT LẬP MFA ⚠ Conditional Access
⚠ Không mâu thuẫn ⚠ MFA là cơ chế, Conditional Access là nơi khai luật, PIM là quản lý quyền quản trị

⚠ Ba cách bật MFA — theo mức độ tinh vi: | Cách | Nội dung | |---|---| | ⚠ Security defaults | ⚠ bậc Free, bật MFA cơ bản cho mọi người, không tuỳ chỉnh | | ⚠ Conditional Access | ⚠ cần P1, khai luật chi tiết theo điều kiện | | ⚠ PIM | ⚠ cần P2, MFA khi kích hoạt vai trò quản trị |

Từ khoá nhận diện:

"khai luật MFA theo điều kiện" → ⚠ Conditional Access "bật MFA nhanh cho mọi người, bậc Free" → ⚠ security defaults "rà soát ai còn cần quyền" → ⚠ Access Reviews "quyền quản trị tạm thời" → ⚠ PIM

⚠ Điều kiện Conditional Access xét được Điều kiện
⚠ Vị trí mạng ⚠ IP tin cậy, quốc gia
⚠ Trạng thái thiết bị ⚠ đã join, đã tuân thủ Intune
⚠ Ứng dụng đích
⚠ Mức rủi ro đăng nhập ⚠ cần Identity Protection, P2
⚠ Nền tảng thiết bị ⚠ Windows, iOS, Android
⚠ Bẫy triển khai Conditional Access Bẫy
⚠ Tự khoá mình ra ngoài ⚠ phải chừa tài khoản khẩn cấp
⚠ Tài khoản dịch vụ không bấm duyệt được ⚠ dùng managed identity, hoặc loại trừ
⚠ Bật thẳng chế độ On ⚠ nên chạy report-only trước
⚠ Công cụ hỗ trợ ⚠ What If để mô phỏng trước khi bật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tài khoản khẩn cấp được loại trừ chưa | ⚠ và cất an toàn | | Chính sách mới đã chạy report-only chưa | | | Có chính sách nào chặn nhầm ứng dụng nào không | |

Và việc bắt buộc phải làm trước khi bật bất kỳ chính sách Conditional Access nào: tạo hai tài khoản khẩn cấp được loại trừ khỏi mọi chính sách. Không có chúng, một chính sách cấu hình sai có thể khoá toàn bộ tổ chức ra khỏi tenant của chính mình.

Câu 12 Chọn nhiều đáp án Manage identity and access (25-30%)

Your organization works with various partners and vendors. You want to allow these external users to access specific company resources without creating a user account for them in your domain.

Which features of Microsoft Entra External ID should you leverage? (Select two)

  1. A

    B2B collaboration
  2. B

    Azure AD B2C
  3. C

    Self-Service Sign-Up
  4. D

    Azure AD Join
Xem giải thích

Đáp án

A và B — B2B collaboration và Azure AD B2C.

Vì sao đúng

⚠ Microsoft Entra External ID có hai hướng phục vụ người dùng ngoài: | Tính năng | Dành cho | |---|---| | ⚠ B2B collaboration | ⚠ ĐỐI TÁC và NHÀ CUNG CẤP — dùng chính tài khoản của họ | | ⚠ B2C | ⚠ KHÁCH HÀNG — đăng ký bằng email, mạng xã hội, hoặc tài khoản riêng |

⚠ B2B collaboration: | Đặc điểm | Nội dung | |---|---| | ⚠ Mời bằng email | ⚠ họ dùng tài khoản của tổ chức họ | | ⚠ KHÔNG tạo tài khoản trong domain của bạn | ⚠ chỉ là đối tượng khách mời | | ⚠ Áp được Conditional Access và MFA | | | ⚠ Thu hồi quyền là xoá đối tượng khách | |

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

  • C (Self-Service Sign-Up) — ⚠ là một CƠ CHẾ hỗ trợ, cho phép khách tự đăng ký; nhưng bản thân nó không phải một tính năng độc lập của External ID theo cách đề liệt kê.

  • D (Azure AD Join) — ⚠ đăng ký THIẾT BỊ vào Entra ID, không liên quan tới người dùng ngoài.

Ghi nhớ

⚠ B2B và B2C — khác nhau căn bản: | 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 trăm tới 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 của tổ chức họ | ⚠ email, Google, Facebook, tài khoản cục bộ | | ⚠ Giao diện đăng nhập | ⚠ của Microsoft | ⚠ tuỳ biến thương hiệu hoàn toàn |

Từ khoá nhận diện:

"đối tác dùng tài khoản của họ" → ⚠ B2B collaboration "khách hàng đăng ký bằng Facebook" → ⚠ B2C "đăng ký thiết bị vào Entra ID" → ⚠ Entra Join "nhân viên dùng tài khoản công ty" → ⚠ người dùng nội bộ thường

⚠ Vì sao B2B tốt hơn tạo tài khoản mới cho đối tác Lý do
⚠ Không phải quản mật khẩu của người ngoài
⚠ Họ nghỉ việc ở công ty họ là tự mất quyền
⚠ MFA do tổ chức của họ lo
⚠ Bạn vẫn áp được Conditional Access
⚠ Tạo tài khoản mới trong domain của mình ⚠ là nhận thêm gánh nặng quản lý và rủi ro
⚠ Quản trị người dùng khách Việc
⚠ Access Reviews định kỳ ⚠ rà xem ai còn cần quyền
⚠ Entitlement Management ⚠ gói quyền, có hạn, có người duyệt
⚠ Cross-tenant access settings ⚠ kiểm soát tenant nào được cộng tác
⚠ Giới hạn quyền mặc định của guest ⚠ mặc định guest thấy được khá nhiều thông tin danh bạ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tenant có bao nhiêu tài khoản khách | ⚠ thường nhiều hơn người ta tưởng | | Có tài khoản khách nào đã lâu không dùng không | | | Quyền mặc định của guest đã siết chưa | |

Và rủi ro âm thầm tích tụ trong mọi tenant có dùng B2B: tài khoản khách không bao giờ được dọn. Dự án kết thúc, đối tác đổi nhân sự, nhưng đối tượng khách vẫn còn đó với nguyên quyền — Access Reviews định kỳ là cách duy nhất giữ danh sách đó sạch.

Câu 13 Manage identity and access (25-30%)
An organization wants to set up alerts for suspicious activities, like multiple failed sign-in attempts. Which feature of Microsoft Entra ID can be used to achieve this?
  1. A Identity Governance
  2. B Entra ID Access Reviews
  3. C Identity Protection
  4. D Entra ID Directory Roles
Xem giải thích

Đáp án

C — Identity Protection.

Vì sao đúng

⚠ Microsoft Entra ID Protection phát hiện và cảnh báo rủi ro định danh: | Loại rủi ro phát hiện | Ví dụ | |---|---| | ⚠ Rủi ro ĐĂNG NHẬP | ⚠ đăng nhập từ IP lạ, từ hai nơi cách xa trong thời gian ngắn | | ⚠ Rủi ro NGƯỜI DÙNG | ⚠ thông tin đăng nhập bị rò rỉ, hành vi bất thường | | ⚠ Đăng nhập ẩn danh | ⚠ qua Tor hoặc VPN ẩn danh | | ⚠ Phun mật khẩu | ⚠ password spray | | ⚠ Nhiều lần đăng nhập thất bại | |

⚠ Ba báo cáo chính: | Báo cáo | Nội dung | |---|---| | ⚠ Risky users | ⚠ người dùng bị đánh dấu rủi ro | | ⚠ Risky sign-ins | ⚠ lần đăng nhập bị đánh dấu | | ⚠ Risk detections | ⚠ chi tiết từng phát hiện |

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

  • B (Access Reviews) — ⚠ rà soát định kỳ ai còn cần quyền, không phát hiện tấn công.

  • A (Identity Governance) — ⚠ nhóm tính năng quản trị vòng đời định danh, gồm Access Reviews và Entitlement Management.

  • D (Entra ID Directory Roles) — ⚠ vai trò quản trị trong danh bạ.

Ghi nhớ

⚠ Identity Protection kết hợp với Conditional Access: | Kết hợp | Nội dung | |---|---| | ⚠ Rủi ro THẤP | ⚠ cho qua, chỉ ghi nhận | | ⚠ Rủi ro TRUNG BÌNH | ⚠ bắt buộc MFA | | ⚠ Rủi ro CAO | ⚠ chặn, hoặc bắt buộc đổi mật khẩu | | ⚠ Đây là | ⚠ chính sách "risk-based Conditional Access" |

Từ khoá nhận diện:

"phát hiện đăng nhập bất thường, tài khoản bị lộ" → ⚠ Identity Protection "khai luật khi nào đòi MFA" → ⚠ Conditional Access "rà soát ai còn cần quyền" → ⚠ Access Reviews "quyền quản trị tạm thời" → ⚠ PIM

⚠ Yêu cầu giấy phép Yêu cầu
⚠ Identity Protection ⚠ Entra ID P2
⚠ Conditional Access ⚠ P1 trở lên
⚠ PIM ⚠ P2
⚠ Security defaults ⚠ bậc Free
⚠ Đề AZ-500 ⚠ hay hỏi tính năng nào thuộc bậc nào
⚠ Vì sao phát hiện dựa trên rủi ro hiệu quả Lý do
⚠ Dựa trên tín hiệu từ hàng nghìn tỷ lượt đăng nhập
⚠ Bắt được tấn công mà luật cứng bỏ lọt
⚠ Phản ứng TỰ ĐỘNG, không chờ người xử lý
⚠ Nhưng ⚠ vẫn cần người rà soát các phát hiện định kỳ

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 bị đánh dấu rủi ro cao chưa xử lý không | | | Tổ chức có giấy phép P2 không | ⚠ thiếu thì không dùng được |

Và điều làm phát hiện dựa trên rủi ro khác với luật cứng: nó học từ 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 một vụ rò rỉ ở nơi khác sẽ bị đánh dấu, dù chưa có bất kỳ hành vi lạ nào trong tổ chức của bạn.

Câu 14 Manage identity and access (25-30%)
Which Microsoft service allows users to access several applications using a single set of credentials?
  1. A Entra ID Join
  2. B Entra ID Passwordless
  3. C

    Microsoft Entra seamless single sign-on
  4. D Entra ID Password Protection
Xem giải thích

Đáp án

C — Microsoft Entra seamless single sign-on.

Vì sao đúng

⚠ SSO cho phép đăng nhập MỘT LẦN rồi vào được nhiều ứng dụng: | Lợi ích | Nội dung | |---|---| | ⚠ Một bộ thông tin đăng nhập | ⚠ không phải nhớ nhiều mật khẩu | | ⚠ Í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 | | | ⚠ Hỗ trợ hàng nghìn ứng dụng SaaS | ⚠ qua Entra ID Application Gallery |

⚠ "Seamless SSO" cụ thể còn nghĩa là: ⚠ máy đã join domain trong mạng công ty tự động đăng nhập mà không cần gõ lại gì.

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

  • B (Passwordless) — ⚠ bỏ mật khẩu, thay bằng khoá bảo mật, sinh trắc học, hoặc app; giải bài toán khác.

  • A (Entra ID Join) — ⚠ đăng ký THIẾT BỊ vào Entra ID.

  • D (Password Protection) — ⚠ chặn mật khẩu yếu và dễ đoán.

Ghi nhớ

⚠ SSO và MFA bổ sung cho nhau: | Cơ chế | Mang lại | |---|---| | ⚠ SSO | ⚠ TIỆN — ít lần đăng nhập hơn | | ⚠ MFA | ⚠ AN TOÀN — lần đăng nhập đó chắc chắn hơn | | ⚠ Kết hợp | ⚠ vừa tiện vừa an toàn | | ⚠ Chỉ SSO không MFA | ⚠ một mật khẩu lộ là mở HẾT mọi ứng dụng |

Từ khoá nhận diện:

"một bộ thông tin đăng nhập cho nhiều ứng dụng" → ⚠ SSO "không dùng mật khẩu nữa" → ⚠ passwordless "chặn mật khẩu yếu" → ⚠ Password Protection "đăng ký thiết bị" → ⚠ Entra Join

⚠ Các giao thức SSO Entra ID hỗ trợ Giao thức
⚠ SAML 2.0 ⚠ phổ biến với ứng dụng doanh nghiệp cũ
⚠ OpenID Connect ⚠ hiện đại, dựa trên OAuth 2.0
⚠ OAuth 2.0 ⚠ uỷ quyền truy cập API
⚠ 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
⚠ Header-based ⚠ qua Application Proxy
⚠ Ba lựa chọn passwordless Lựa chọn
⚠ Windows Hello for Business ⚠ sinh trắc học hoặc PIN trên thiết bị
⚠ FIDO2 security key ⚠ khoá phần cứng, chống phishing tốt nhất
⚠ Microsoft Authenticator ⚠ đăng nhập bằng điện thoại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn ứng dụng nội bộ nào dùng mật khẩu riêng không | ⚠ mỗi cái là một rủi ro riêng | | SSO đã đi kèm MFA chưa | ⚠ chỉ SSO là rất nguy hiểm | | Có bao nhiêu ứng dụng đã tích hợp Entra ID | |

Và điều phải luôn đi kèm khi triển khai SSO: MFA. Đăng nhập một lần cho mọi ứng dụng nghĩa là một mật khẩu bị đánh cắp cũng mở được mọi ứng dụng — SSO không có MFA là dồn toàn bộ rủi ro vào một điểm.

Câu 15 Chọn nhiều đáp án Manage identity and access (25-30%)

Your organization is looking to increase its security posture.

Which of the following would you implement to reduce the reliance on passwords and increase account security? (Select two)

  1. A

    Password Writeback
  2. B Multi-factor Authentication (MFA)
  3. C Passwordless Authentication
  4. D

    Password Expiration Policies
Xem giải thích

Đáp án

B và C — Multi-factor Authentication và Passwordless Authentication.

Vì sao đúng

⚠ Hai biện pháp tấn công đúng 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 bị lộ vẫn KHÔNG đủ để vào | | ⚠ Passwordless | ⚠ BỎ HẲN mật khẩu — không còn gì để đánh cắp |

⚠ Ba phương thức passwordless của Entra ID: | Phương thức | Nội dung | |---|---| | ⚠ 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 |

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

  • A (Password Writeback) — ⚠ ghi mật khẩu đổi trên đám mây ngược về AD tại chỗ; là tiện ích đồng bộ, không giảm phụ thuộc mật khẩu.

  • D (chính sách hết hạn mật khẩu) — ⚠ NIST và Microsoft đều KHUYẾN NGHỊ BỎ; ép đổi định kỳ khiến người dùng chọn mật khẩu yếu hơn theo mẫu dễ đoán.

Ghi nhớ

⚠ Vì sao chính sách hết hạn mật khẩu bị coi là phản tác dụng: | Vấn đề | Nội dung | |---|---| | ⚠ Người dùng đổi theo mẫu | ⚠ MatKhau01 thành MatKhau02 | | ⚠ Ghi ra giấy nhiều hơn | | | ⚠ Không ngăn được mật khẩu đã bị đánh cắp | ⚠ kẻ tấn công dùng ngay, không chờ hết hạn | | ⚠ Khuyến nghị hiện nay | ⚠ mật khẩu KHÔNG hết hạn, nhưng BẮT BUỘC MFA và chặn mật khẩu yếu |

Từ khoá nhận diện:

"giảm phụ thuộc mật khẩu" → ⚠ MFA và passwordless "chặn mật khẩu dễ đoán" → ⚠ Password Protection "đổi mật khẩu trên đám mây ghi về AD" → ⚠ password writeback "ép đổi mật khẩu định kỳ" → ⚠ thực hành CŨ, không còn khuyến nghị

⚠ Thứ tự nên triển khai Bước
⚠ 1. MFA cho mọi tài khoản quản trị ⚠ việc đáng làm nhất
⚠ 2. MFA cho toàn bộ người dùng
⚠ 3. Chặn mật khẩu yếu ⚠ Password Protection
⚠ 4. Bỏ chính sách hết hạn
⚠ 5. Chuyển dần sang passwordless
⚠ Vì sao FIDO2 mạnh nhất Lý do
⚠ Chống phishing về mặt kỹ thuật ⚠ khoá gắn với TÊN MIỀN, không ký cho trang giả
⚠ Không có bí mật nào truyền qua mạng
⚠ Không bị đánh cắp SIM như SMS
⚠ Đổi lại ⚠ cần mua phần cứng và quy trình phát khoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Toàn bộ tài khoản quản trị đã bật MFA chưa | | | Chính sách hết hạn mật khẩu còn bật không | | | Có lộ trình chuyển sang passwordless chưa | |

Và thay đổi tư duy quan trọng nhất trong bảo mật định danh mười năm qua: mật khẩu mạnh và đổi thường xuyên không còn là biện pháp chính. Thứ thật sự chặn được tấn công là yếu tố thứ hai — hoặc bỏ hẳn mật khẩu.

Câu 16 Manage identity and access (25-30%)
Which of the following is designed to ban certain passwords from being used, ensuring users avoid easily guessable and vulnerable passwords?
  1. A Entra ID Identity Protection
  2. B

    Entra ID Conditional Access
  3. C

    Global/Custom banned password list
  4. D Entra ID B2B
Xem giải thích

Đáp án

C — Danh sách mật khẩu bị cấm toàn cầu và tuỳ chỉnh (Global/Custom banned password list).

Vì sao đúng

⚠ Microsoft Entra Password Protection có hai danh sách: | Danh sách | Nội dung | |---|---| | ⚠ Global banned password list | ⚠ Microsoft duy trì, dựa trên dữ liệu tấn công thật, LUÔN bật, không tắt được | | ⚠ Custom banned password list | ⚠ của bạn — tên công ty, tên sản phẩm, tên địa phương, khẩu hiệu |

⚠ Cách nó chấm điểm — thông minh hơn so khớp thuần: | Cơ chế | Nội dung | |---|---| | ⚠ Chuẩn hoá | ⚠ P@ssw0rd được quy về password | | ⚠ Bắt biến thể thay ký tự | ⚠ 0 thay o, @ thay a | | ⚠ Chấm điểm theo thành phần | ⚠ mật khẩu chứa từ bị cấm bị trừ điểm | | ⚠ Áp được cho cả AD TẠI CHỖ | ⚠ qua agent cài trên domain controller |

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

  • A (Identity Protection) — ⚠ phát hiện rủi ro đăng nhập và tài khoản bị lộ, không kiểm tra mật khẩu lúc đặt.

  • B (Conditional Access) — ⚠ khai điều kiện đăng nhập, không đụng tới nội dung mật khẩu.

  • D (Entra ID B2B) — ⚠ cộng tác với người ngoài.

Ghi nhớ

⚠ Danh sách cấm tuỳ chỉnh nên chứa gì: | Loại | Ví dụ | |---|---| | ⚠ Tên công ty và viết tắt | | | ⚠ Tên sản phẩm và thương hiệu | | | ⚠ Tên thành phố nơi đặt trụ sở | | | ⚠ Khẩu hiệu và từ khoá nội bộ | | | ⚠ Giới hạn | ⚠ tối đa 1.000 từ |

Từ khoá nhận diện:

"cấm mật khẩu dễ đoán" → ⚠ Password Protection, banned password list "phát hiện tài khoản bị lộ" → ⚠ Identity Protection "khai luật đăng nhập" → ⚠ Conditional Access "bỏ hẳn mật khẩu" → ⚠ passwordless

⚠ Hai chế độ triển khai Chế độ
⚠ Audit ⚠ chỉ GHI NHẬT KÝ, vẫn cho đặt mật khẩu yếu
⚠ Enforced ⚠ CHẶN thật
⚠ Triển khai an toàn ⚠ chạy Audit vài tuần để ước lượng ảnh hưởng, rồi mới Enforce
⚠ Yêu cầu giấy phép Yêu cầu
⚠ Danh sách toàn cầu cho tài khoản đám mây ⚠ bậc Free, LUÔN bật
⚠ Danh sách tuỳ chỉnh ⚠ cần P1
⚠ Áp cho AD tại chỗ ⚠ cần P1 và cài agent trên domain controller

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Danh sách tuỳ chỉnh đã có tên công ty chưa | ⚠ đây là từ hay bị dùng nhất | | Đang ở chế độ Audit hay Enforced | | | AD tại chỗ đã cài agent chưa | ⚠ nếu không thì chỉ tài khoản đám mây được bảo vệ |

Và giá trị lớn nhất của danh sách cấm tuỳ chỉnh: nó chặn đúng những mật khẩu mà nhân viên của bạn hay nghĩ ra nhất — tên công ty ghép với năm hiện tại. Danh sách toàn cầu của Microsoft không biết công ty bạn tên gì.

Câu 17 Manage identity and access (25-30%)
Which Azure service allows you to manage and provide time-limited access to Entra ID roles and Azure resources?
  1. A

    Entra Join
  2. B

    Entra Password Protection
  3. C

    Conditional Access
  4. D

    Privileged Identity Management (PIM)
Xem giải thích

Đáp án

D — Privileged Identity Management (PIM).

Vì sao đúng

⚠ PIM quản lý quyền CÓ THỜI HẠN cho cả hai loại vai trò: | Quản được | Nội dung | |---|---| | ⚠ Vai trò Microsoft Entra ID | ⚠ Global Administrator, User Administrator... | | ⚠ Vai trò tài nguyên Azure | ⚠ Owner, Contributor trên subscription, resource group | | ⚠ Nhóm có thể gán vai trò | ⚠ PIM for Groups |

⚠ Cách hoạt động: | Khái niệm | Nội dung | |---|---| | ⚠ Eligible | ⚠ ĐỦ ĐIỀU KIỆN nhận vai trò, nhưng CHƯA có quyền | | ⚠ Active | ⚠ đã kích hoạt, đang có quyền | | ⚠ Kích hoạt | ⚠ cần MFA, cần lý do, có thể cần người duyệt | | ⚠ Hết thời hạn | ⚠ quyền TỰ thu hồi |

⚠ Bình thường: ⚠ Eligible — không có quyền gì
⚠ Khi cần:     ⚠ kích hoạt → ⚠ MFA + lý do → ⚠ Active trong N giờ
⚠ Hết giờ:     ⚠ tự về Eligible

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

  • C (Conditional Access) — ⚠ khai điều kiện ĐĂNG NHẬP, không quản lý vòng đời của quyền.

  • B (Password Protection) — ⚠ chặn mật khẩu yếu.

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

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #22152 ở lô 170 hỏi dịch vụ nào bật MFA cho quản trị viên mà không bắt người dùng thường (đáp án PIM). ⚠ Câu này hỏi dịch vụ nào cấp quyền CÓ THỜI HẠN. Hai câu nhất quán, cùng chỉ về PIM.

⚠ Vì sao quyền thường trực là rủi ro: | Rủi ro | Nội dung | |---|---| | ⚠ Tài khoản bị chiếm là có ngay quyền cao nhất | | | ⚠ Không ai theo dõi vì quyền lúc nào cũng có | | | ⚠ Quyền tích tụ dần khi người ta đổi việc | | | ⚠ PIM đổi thành | ⚠ có quyền là một HÀNH ĐỘNG có ghi nhận, không phải một trạng thái |

Từ khoá nhận diện:

"quyền tạm thời, kích hoạt khi cần" → ⚠ PIM "điều kiện đăng nhập" → ⚠ Conditional Access "rà soát ai còn cần quyền" → ⚠ Access Reviews "gói quyền có hạn cho người ngoài" → ⚠ Entitlement Management

⚠ Cấu hình PIM nên đặt Cấu hình
⚠ Thời hạn kích hoạt tối đa ⚠ thường 1 đến 8 giờ
⚠ Bắt buộc MFA khi kích hoạt
⚠ Bắt buộc ghi lý do
⚠ Cần người duyệt cho vai trò nhạy cảm ⚠ Global Administrator
⚠ Gửi thông báo khi có kích hoạt
⚠ Đánh giá quyền định kỳ
⚠ Yêu cầu giấy phép Yêu cầu
⚠ PIM cần Entra ID P2 ⚠ hoặc Microsoft Entra ID Governance
⚠ 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ó bao nhiêu tài khoản giữ Global Administrator thường trực | ⚠ Microsoft khuyến nghị dưới 5 | | Vai trò quản trị có bị buộc MFA khi kích hoạt không | | | Có tài khoản khẩn cấp được loại trừ và cất an toàn chưa | |

Và điều PIM thay đổi về mặt vận hành: mỗi lần dùng quyền quản trị đều để lại dấu vết và có lý do đi kèm. Từ chỗ không ai biết ai đã làm gì, thành ra một sổ ghi chép đầy đủ mà kiểm toán viên đọc được.

Câu 18 Chọn nhiều đáp án Manage identity and access (25-30%)

You are tasked with assigning roles for Azure resources and Entra ID.

Which of the following can be used to assign built-in roles for both? (Select three)

  1. A Entra ID User settings
  2. B Azure Policy
  3. C Azure RBAC
  4. D

    Microsoft Entra roles
  5. E

    Entra Privileged Identity Management (PIM)
Xem giải thích

Đáp án

C, D và E — Azure RBAC, Microsoft Entra roles, và Entra Privileged Identity Management.

Vì sao đúng

⚠ Ba cơ chế gán vai trò tích hợp: | Cơ chế | Gán vai trò cho | |---|---| | ⚠ Azure RBAC | ⚠ TÀI NGUYÊN Azure — subscription, resource group, resource | | ⚠ Microsoft Entra roles | ⚠ DANH BẠ — quản lý người dùng, ứng dụng, thiết bị | | ⚠ PIM | ⚠ CẢ HAI, nhưng theo kiểu có thời hạn |

⚠ Azure RBAC       →  ⚠ "ai quản máy ảo, tài khoản lưu trữ"
⚠ Entra roles      →  ⚠ "ai quản người dùng, nhóm, ứng dụng"
⚠ PIM              →  ⚠ "ai được kích hoạt hai loại trên, trong bao lâu"

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

  • A (Entra ID User settings) — ⚠ cấu hình chung cho người dùng, ví dụ có được tự đăng ký ứng dụng không; không gán vai trò.

  • B (Azure Policy) — ⚠ áp luật lên CẤU HÌNH tài nguyên, không phải gán quyền cho ai.

Ghi nhớ

⚠ Azure RBAC và Entra roles — hai hệ thống TÁCH BIỆT: | Tiêu chí | Azure RBAC | Entra roles | |---|---|---| | ⚠ Phạm vi | ⚠ management group → resource | ⚠ toàn bộ tenant, hoặc đơn vị quản trị | | ⚠ Vai trò tiêu biểu | ⚠ Owner, Contributor, Reader | ⚠ Global Administrator, User Administrator | | ⚠ Quản lý ở đâu | ⚠ tab Access control (IAM) của tài nguyên | ⚠ mục Roles and administrators của Entra ID | | ⚠ Ảnh hưởng lẫn nhau | ⚠ KHÔNG, trừ một ngoại lệ | |

⚠ Ngoại lệ đáng nhớ: ⚠ Global Administrator có thể tự nâng quyền để quản lý mọi subscription trong tenant — ⚠ qua công tắc "Access management for Azure resources".

Từ khoá nhận diện:

"quyền trên máy ảo, tài khoản lưu trữ" → ⚠ Azure RBAC "quyền tạo và xoá người dùng" → ⚠ Entra roles "quyền có thời hạn" → ⚠ PIM "buộc tài nguyên phải gắn thẻ" → ⚠ Azure Policy

⚠ Bốn vai trò Azure 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
⚠ Nguyên tắc gán quyền Nguyên tắc
⚠ Gán cho NHÓM, không gán cho cá nhân
⚠ Phạm vi hẹp nhất đủ dùng
⚠ Dùng vai trò tích hợp trước, tự tạo sau
⚠ Rất ít Owner ở cấp subscription
⚠ Đánh giá quyền định kỳ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang giữ Global Administrator | ⚠ và công tắc nâng quyền có bật không | | Có quyền nào gán trực tiếp cho cá nhân không | | | Vai trò tự tạo có rộng hơn cần thiết không | |

Và điểm giao nhau nguy hiểm giữa hai hệ thống quyền: Global Administrator có thể tự cấp cho mình quyền trên mọi subscription. Đó là lý do số lượng tài khoản giữ vai trò này phải được giữ ở mức tối thiểu và luôn đi qua PIM.

Câu 19 Manage identity and access (25-30%)

What is the primary use case for Azure Managed Identity and how does it enhance the security of Azure resources?

  1. A

    Azure Managed Identity is primarily used to provide an Azure service with an automatically managed identity in Azure AD. It allows the service to authenticate to any service that supports Azure AD authentication, without needing credentials in the code, thereby enhancing security by eliminating the need for developers to manage credentials.
  2. B

    Azure Managed Identity is primarily used to increase the processing speed of Azure services and it enhances security by encrypting all data.
  3. C

    Azure Managed Identity is primarily used to provide a graphical user interface for managing Azure resources and it enhances security through multi-factor authentication.
  4. D

    Azure Managed Identity is primarily used to monitor the performance of Azure resources and it enhances security by regularly scanning for vulnerabilities.
Xem giải thích

Đáp án

A — Managed Identity cấp cho một dịch vụ Azure một định danh được quản lý tự động trong Entra ID, cho phép dịch vụ đó xác thực tới bất kỳ dịch vụ nào hỗ trợ xác thực Entra ID mà KHÔNG cần thông tin đăng nhập trong mã, nhờ đó lập trình viên không phải quản lý bí mật.

Vì sao đúng

⚠ Managed Identity giải quyết bài toán "con gà và quả trứng" của bí mật: | Vấn đề | Nội dung | |---|---| | ⚠ Ứng dụng cần bí mật để lấy bí mật từ Key Vault | ⚠ vậy bí mật đầu tiên cất ở đâu | | ⚠ Managed Identity trả lời | ⚠ KHÔNG có bí mật nào cả — Azure tự chứng thực danh tính của tài nguyên |

⚠ Máy ảo hoặc App Service
   ↓ ⚠ hỏi Instance Metadata Service (169.254.169.254)
⚠ Nhận token từ Entra ID
   ↓
⚠ Gọi Key Vault, Storage, SQL...
   ⚠ KHÔNG có mật khẩu nào trong mã hay cấu hình

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

  • B (tăng tốc độ xử lý và mã hoá mọi dữ liệu) — ⚠ sai hoàn toàn; managed identity không liên quan tới hiệu năng.

  • C (giao diện đồ hoạ quản lý tài nguyên) — ⚠ đó là Azure Portal.

  • D (giám sát hiệu năng và quét lỗ hổng) — ⚠ đó là Azure Monitor và Defender for Cloud.

Ghi nhớ

⚠ Hai loại managed identity: | Loại | Đặc điểm | |---|---| | ⚠ System-assigned | ⚠ gắn với MỘT tài nguyên; xoá tài nguyên là xoá luôn định danh | | ⚠ User-assigned | ⚠ tài nguyên ĐỘC LẬP; NHIỀU dịch vụ dùng chung một định danh |

⚠ Chọn loại nào: | Tình huống | Chọn | |---|---| | ⚠ Một ứng dụng đơn lẻ | ⚠ system-assigned, đơn giản nhất | | ⚠ Nhiều dịch vụ cần cùng bộ quyền | ⚠ user-assigned, gán quyền một lần | | ⚠ Cần định danh tồn tại trước khi tạo tài nguyên | ⚠ user-assigned | | ⚠ Tài nguyên hay bị tạo lại | ⚠ user-assigned, khỏi gán quyền lại mỗi lần |

Từ khoá nhận diện:

"không lưu bí mật nào trong mã" → ⚠ managed identity "nơi cất bí mật" → ⚠ Key Vault "ứng dụng ngoài Azure cần gọi API Azure" → ⚠ service principal kèm secret hoặc chứng chỉ "định danh dùng chung cho nhiều dịch vụ" → ⚠ user-assigned managed identity

⚠ Kiến trúc quản lý bí mật lý tưởng Kiến trúc
⚠ Ứng dụng dùng managed identity ⚠ không có bí mật nào
⚠ Managed identity có quyền đọc Key Vault ⚠ RBAC phạm vi hẹp
⚠ Bí mật của bên thứ ba nằm trong Key Vault ⚠ API key, chuỗi kết nối ngoài
⚠ Bật nhật ký truy cập Key Vault
⚠ Kết quả ⚠ không có bí mật nào trong mã, trong Git, hay trong biến môi trường
⚠ Giới hạn của managed identity Giới hạn
⚠ Chỉ dùng được TỪ TRONG Azure ⚠ ứng dụng chạy ở nơi khác thì không
⚠ Dịch vụ đích phải hỗ trợ xác thực Entra ID
⚠ IMDS là mục tiêu tấn công SSRF ⚠ cần phòng vệ ở tầng ứng dụng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn bí mật nào trong mã nguồn không | ⚠ quét cả lịch sử Git | | Ứng dụng nào có thể chuyển sang managed identity | | | Managed identity có được cấp quyền hẹp nhất không | |

Và giá trị lớn nhất của managed identity không phải là tiện, mà là: không có gì để đánh cắp. Bí mật không tồn tại thì không lộ được, không hết hạn, và không cần xoay vòng.

Câu 20 Chọn nhiều đáp án Manage identity and access (25-30%)

You're setting up an application to use Microsoft Entra ID for authentication. Which of the following are essential components you would need to create or configure in Microsoft Entra ID? (Select three)

  1. A Application Registration
  2. B

    OAuth 2.0
  3. C Azure Policy
  4. D

    OpenID Connect
Xem giải thích

Đáp án

A, B và D — Application Registration, OAuth 2.0, và OpenID Connect.

Vì sao đúng

⚠ Ba mảnh của một ứng dụng tích hợp Entra ID: | Thành phần | Vai trò | |---|---| | ⚠ Application Registration | ⚠ khai báo ứng dụng với Entra ID — nhận Application ID, redirect URI, quyền | | ⚠ OpenID Connect | ⚠ giao thức XÁC THỰC — "người này là ai" | | ⚠ OAuth 2.0 | ⚠ giao thức UỶ QUYỀN — "ứng dụng được phép làm gì thay người này" |

⚠ Người dùng đăng nhập
   ↓ ⚠ OpenID Connect  →  ⚠ ID token: người này là ai
   ↓ ⚠ OAuth 2.0       →  ⚠ Access token: được gọi API nào
⚠ Ứng dụng gọi API thay mặt người dùng

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

  • C (Azure Policy) — ⚠ áp luật lên cấu hình TÀI NGUYÊN Azure, không liên quan tới xác thực ứng dụng.

Ghi nhớ

⚠ OpenID Connect và OAuth 2.0 — phân biệt cho rõ: | Giao thức | Trả lời | |---|---| | ⚠ OpenID Connect | ⚠ AUTHENTICATION — bạn là ai | | ⚠ OAuth 2.0 | ⚠ AUTHORIZATION — bạn cho phép ứng dụng làm gì | | ⚠ Quan hệ | ⚠ OIDC là một LỚP xây trên OAuth 2.0 | | ⚠ Token tương ứng | ⚠ ID token cho OIDC, Access token cho OAuth |

⚠ App Registration khai những gì: | Mục | Nội dung | |---|---| | ⚠ Application (client) ID | ⚠ định danh của ứng dụng | | ⚠ Redirect URI | ⚠ nơi Entra ID trả token về — phải khớp CHÍNH XÁC | | ⚠ API permissions | ⚠ quyền cần xin, delegated hoặc application | | ⚠ Certificates and secrets | ⚠ nếu là ứng dụng bí mật | | ⚠ Token configuration | ⚠ claim nào có trong token | | ⚠ App roles | ⚠ vai trò trong chính ứng dụng |

Từ khoá nhận diện:

"người này là ai" → ⚠ OpenID Connect, ID token "ứng dụng được gọi API nào" → ⚠ OAuth 2.0, access token "khai báo ứng dụng với Entra ID" → ⚠ App Registration "ứng dụng cũ chỉ hỗ trợ SAML" → ⚠ SAML 2.0, vẫn được hỗ trợ

⚠ Hai loại quyền API Loại
⚠ Delegated ⚠ ứng dụng hành động THAY MẶT người dùng — quyền không vượt quá quyền của họ
⚠ Application ⚠ ứng dụng hành động TỰ THÂN, không có người dùng — cần admin consent
⚠ Quyền application ⚠ nguy hiểm hơn nhiều, phải xét kỹ
⚠ Bẫy bảo mật thường gặp Bẫy
⚠ Client secret nhúng trong mã ⚠ dùng chứng chỉ hoặc managed identity thay thế
⚠ Redirect URI dùng ký tự đại diện ⚠ mở đường cho tấn công chuyển hướng
⚠ Xin quyền rộng hơn cần thiết
⚠ Secret hết hạn không ai biết ⚠ đặt cảnh báo trước ngày hết hạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | App registration nào sắp hết hạn secret | ⚠ sự cố im lặng rất hay gặp | | Có ứng dụng nào giữ quyền application quá rộng không | | | Redirect URI có khai chặt chẽ không | |

Và sự cố ngừng dịch vụ khó đoán nhất liên quan tới Entra ID: client secret của app registration hết hạn. Mọi thứ chạy bình thường cho tới đúng ngày đó, rồi ứng dụng ngừng đăng nhập được mà không ai thay đổi gì cả.