Lộ trình
Microsoft AzureCơ bảnTuần 3: Kiến trúc & bảo mậtBài 16 / 30

Ngày 16: Authentication & Access

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
az-900ngày 16
hoàn thành16 / 30 bài
Bối cảnh bài học

Thiết kế authentication và access với MFA, Conditional Access, SSO và Azure RBAC; nối policy với principal, condition, scope và evidence.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Thiết kế authentication và access với MFA, Conditional Access, SSO và Azure RBAC; nối policy với principal, condition, scope và evidence.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Tìm hiểu MFA, Conditional Access, SSO
  • Học RBAC và cách gán role cho resource
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

Một tài khoản admin bị lộ password, contractor vẫn truy cập sau khi hợp đồng kết thúc và developer có quyền owner toàn subscription chỉ để đọc logs. Bài học xây access model giảm blast radius mà vẫn hỗ trợ SSO và vận hành.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • MFA thêm yếu tố xác minh; không thay thế least privilege hoặc secure recovery.
  • Conditional Access đánh giá signal/condition như user, device, location, risk và application để require/block/control access; policy design cần tránh lockout.
  • SSO giảm password sprawl và friction nhưng cần tenant/app integration, session/lifecycle và offboarding.
  • Azure RBAC role definition gồm actions/dataActions/notActions/notDataActions; assignment gắn principal với role ở scope và có inheritance.

Access decision có nhiều lớp

Authentication trả lời “ai?”, MFA tăng assurance, Conditional Access trả lời “trong điều kiện nào có thể đăng nhập?”, SSO nối một identity với nhiều app và RBAC trả lời “được làm gì ở scope nào?”.

Conditional Access

Một policy có thể dựa trên user/group, app, device compliance, location, sign-in risk và require MFA/block/limited session. Thiết kế phải có test group, report-only/validation, exception có owner/expiry và break-glass account được giám sát; policy quá rộng có thể tự khóa admin.

RBAC

Assignment = principal + role + scope. Scope có thể kế thừa từ management group/subscription/resource group/resource. Reader không cần write; Contributor không quản lý access; Owner có quyền rộng gồm access delegation. Chọn built-in role trước, custom role chỉ khi gap có evidence.

Bài tập

Tạo matrix access cho team và contractor. Viết sign-in/access flow và một role review record. Thêm scenario offboarding, compromised password, contractor location mới và developer cần đọc logs; ghi control, evidence và rollback.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
az account show --output table
az account list --output table
az group list --output table
Hands-on lab

Thực hành theo scenario

  1. Tạo access matrix cho employee, contractor, developer, operator và auditor; chọn built-in role/scope tối thiểu.
  2. Vẽ sign-in decision: principal → application → Conditional Access signals → MFA/block/grant → RBAC scope.
  3. Dùng What-if/pseudo policy để kiểm tra MFA/CA exception, break-glass account và offboarding; không thay đổi tenant production.
  4. Mô phỏng role assignment audit: current access, owner, expiry, last review, evidence và rollback.
Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Phân biệt MFA/CA/SSO/RBAC.
  • Role assignment có principal, role và scope cụ thể.
  • Nêu được risk của broad Owner/Contributor.
  • Policy có exception/break-glass/test plan.
  • Có offboarding và periodic access review.
Transfer to exam / production

Bẫy thường gặp và trade-off

MFA xác thực mạnh hơn; Conditional Access quyết định điều kiện truy cập; RBAC quyết định quyền trên Azure resource. Đừng dùng một thuật ngữ để trả lời cả ba câu hỏi.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Muốn yêu cầu MFA khi nhóm contractor truy cập Azure Portal ngoài mạng công ty, control nào diễn tả đúng nhất?

Kết thúc bài

Checklist trước khi sang Ngày 2