Bài 74. Quản lý danh tính (1): provisioning/deprovisioning, SSO, federation: SAML, OAuth, OIDC

Khóa học CompTIA Security+ SY0-801 · Phần 4: Vận hành bảo mật · Bài 74 · 🎯 Objective 4.5 · ⏱️ Đọc khoảng 18 phút · 🧪 Không cần lab · 📝 5 câu bài tập cuối bài

🎯 Mục tiêu bài học

• Hiểu vòng đời danh tính: xác minh danh tính (identity proofing), cấp (provisioning), thay đổi, rà soát (attestation) và thu hồi (deprovisioning).
• Hiểu vì sao tài khoản mồ côi và phình quyền (privilege creep) nguy hiểm.
• Nắm đăng nhập một lần (SSO) và liên kết danh tính (federation).
• Phân biệt LDAP, SAML, OAuth, OpenID Connect (OIDC): mỗi chuẩn làm việc gì.

📎 Vị trí trong đề thi: Objective 4.5 nói về quản lý danh tính và truy cập (IAM). Bài này lo vòng đời và đăng nhập tập trung; Bài 75 lo MFA, passkeys, mật khẩu; Bài 76 lo mô hình điều khiển truy cập. Bài dùng lại AAA ở Bài 2, PKI và chứng chỉ ở Bài 11, và 802.1X ở Bài 48.

💡 Liên hệ thực tế: nhân viên nghỉ việc mà tài khoản vẫn sống

Cửa hàng chị Lan dùng khoảng chục dịch vụ: email, phần mềm bán hàng, kế toán, lưu trữ đám mây, hệ thống chấm công... Mỗi nơi một tài khoản và một mật khẩu riêng. Khi nhân viên An nghỉ việc, người ta khóa email nhưng quên tài khoản phần mềm kế toán. Ba tháng sau, tài khoản đó vẫn đăng nhập được từ một địa chỉ lạ. Đây là tình huống minh họa, không phải vụ việc có thật.

Nam chỉ ra ba vấn đề: không có quy trình thu hồi đầy đủ, không có nơi quản lý tập trung, và nhân viên phải nhớ quá nhiều mật khẩu nên hay dùng lại. Giải pháp là một nhà cung cấp danh tính (identity provider) làm trung tâm: tạo tài khoản một nơi, đăng nhập một lần cho nhiều ứng dụng (SSO), và khi nhân viên nghỉ, khóa một nơi là mất quyền ở mọi nơi.

🔄 Hình 74a. Vào làm, chuyển bộ phận, nghỉ việc: quyền phải đi theo vai trò thực tế.

📘 Kiến thức cốt lõi

🔄 Vòng đời danh tính

Quy trình này thường gọi theo ba tình huống: joiner (vào), mover (chuyển), leaver (rời). Tự động hóa bằng liên kết với hệ thống nhân sự giúp khi nhân sự cập nhật trạng thái thì tài khoản tự đổi theo, giảm việc quên. Một chuẩn thường dùng để đồng bộ tài khoản giữa các hệ thống là SCIM.

Với tài khoản không phải người (tài khoản dịch vụ, khóa API, tài khoản của đối tác) cũng phải có chủ sở hữu, mục đích, thời hạn và vòng đời thu hồi; đây là nhóm hay bị bỏ quên nhất. Tương tự, tài khoản khách và đối tác tạm thời nên có ngày hết hạn tự động.

🔑 Đăng nhập một lần (SSO)

SSO (Single Sign-On) cho phép người dùng đăng nhập một lần rồi truy cập nhiều ứng dụng mà không phải nhập lại thông tin.

🤝 Liên kết danh tính (federation)

Federation là sự tin cậy giữa các tổ chức hoặc hệ thống để người dùng của một bên dùng được dịch vụ của bên kia mà không cần tài khoản riêng. Hai vai trò:

• IdP (Identity Provider): nơi xác thực người dùng và phát hành thông tin danh tính.
• SP (Service Provider / Relying Party): ứng dụng hoặc dịch vụ tin IdP và cho người dùng vào dựa trên thông tin IdP gửi.

Ví dụ: nhân viên dùng tài khoản công ty để vào một dịch vụ đám mây bên thứ ba; hoặc đăng nhập một trang web bằng tài khoản của một nền tảng lớn ("Đăng nhập bằng..."). Ứng dụng không bao giờ nhận mật khẩu, chỉ nhận token hoặc assertion do IdP ký.

🔐 Hình 74b. Mật khẩu chỉ nhập ở IdP; ứng dụng nhận token do IdP cấp và ký.

📚 Các chuẩn thường gặp

Phân biệt dễ nhầm:

• OAuth là ủy quyền ("ứng dụng này được phép đọc lịch của tôi"), còn OIDC là xác thực ("người này là ai") chạy trên nền OAuth.
• SAML (XML, doanh nghiệp, web) và OIDC (JSON, hiện đại, di động) cùng giải quyết SSO nhưng theo cách khác nhau.
• Kerberos (vé xác thực trong mạng nội bộ miền) và RADIUS/802.1X (Bài 48) là các cơ chế xác thực khác trong môi trường nội bộ, thường đứng sau LDAP và thư mục.

Khả năng tương tác (interoperability): chuẩn chung (SAML, OIDC) cho phép các hệ thống của nhiều nhà cung cấp phối hợp. Cần cấu hình đúng: kiểm tra chữ ký của assertion và token, thời hạn, người nhận (audience), và dùng TLS; cấu hình sai là nguồn lỗ hổng thường gặp (ví dụ chấp nhận token không ký hoặc quá hạn).

✅ Rà soát quyền (attestation)

Attestation (còn gọi chứng nhận quyền, access review, recertification) là việc chủ sở hữu hoặc quản lý xác nhận định kỳ rằng mỗi người vẫn cần các quyền họ đang có. Cách làm:

• Định kỳ (ví dụ hằng quý hoặc nửa năm), thường xuyên hơn với quyền đặc biệt như quản trị.
• Người duyệt là chủ sở hữu tài sản hoặc quản lý trực tiếp, không phải đội kỹ thuật tự duyệt (Bài 66).
• Gỡ ngay quyền không còn cần; ghi nhận kết quả để làm bằng chứng kiểm toán.
• Tìm tài khoản mồ côi, tài khoản không dùng lâu, tài khoản có quá nhiều quyền.

🎯 Mẹo làm bài: "Chứng minh một người đúng là người họ nói trước khi cấp tài khoản" → identity proofing. "Tạo tài khoản và gán quyền" → provisioning. "Khóa tài khoản và thu hồi quyền khi nghỉ việc" → deprovisioning. "Quyền cứ tích lũy khi chuyển vị trí" → privilege creep. "Tài khoản của người đã nghỉ vẫn còn" → orphaned account. "Xác nhận định kỳ ai có quyền gì" → attestation / access review. "Đăng nhập một lần cho nhiều ứng dụng" → SSO. "Tin cậy giữa các tổ chức, không cần tài khoản riêng" → federation. "Nơi xác thực" → IdP; "ứng dụng tin IdP" → SP. "XML, assertion, SSO doanh nghiệp" → SAML. "Ủy quyền truy cập bằng token, không đưa mật khẩu" → OAuth. "Xác thực xây trên OAuth, có ID token" → OIDC. "Giao thức truy vấn thư mục" → LDAP.

🧠 Áp vào câu chuyện của Nam

📖 Thuật ngữ cần nhớ

📌 Tóm tắt nhanh

• Vòng đời danh tính: xác minh, cấp, thay đổi, rà soát, thu hồi; lỗi hay gặp là tài khoản mồ côi và phình quyền.
• SSO giảm mật khẩu, tập trung quản lý nhưng là điểm lỗi duy nhất, cần MFA và dự phòng.
• Federation: IdP xác thực, SP tin IdP; ứng dụng nhận token, không nhận mật khẩu.
• SAML (XML, doanh nghiệp), OAuth (ủy quyền, không phải xác thực), OIDC (xác thực trên OAuth), LDAP (thư mục).
• Attestation định kỳ giúp gỡ quyền thừa; áp dụng cả cho tài khoản dịch vụ và đối tác.

💬 Hỏi & Đáp nhanh

❓ SSO có làm giảm an toàn vì "một chìa mở nhiều khóa" không? Có rủi ro tập trung, nhưng thường vẫn an toàn hơn so với nhiều mật khẩu yếu và dùng lại, miễn là IdP được bảo vệ rất chặt: MFA, cảnh báo đăng nhập bất thường, quyền quản trị IdP hạn chế, kế hoạch dự phòng khi IdP gặp sự cố.

❓ OAuth và OIDC khác nhau chỗ nào, vì sao hay nhầm? OAuth trả lời "ứng dụng này được làm gì thay mặt bạn" (ủy quyền); nó không cho biết người dùng là ai. OIDC thêm một lớp ID token để trả lời "người này là ai" (xác thực). Hai thứ hay dùng chung nên dễ nhầm.

❓ Bao lâu nên rà soát quyền (attestation) một lần? Không có con số cố định đúng cho mọi nơi. Thường rà soát định kỳ (hằng quý hoặc nửa năm), quyền quản trị và nhạy cảm nên thường xuyên hơn, và nên rà soát thêm khi có thay đổi lớn về tổ chức.

📝 Bài tập đánh giá

Tự chọn đáp án cho từng câu, rồi đối chiếu với phần đáp án ở cuối bài.

Câu 1. Một nhân viên chuyển từ phòng kế toán sang phòng kinh doanh nhưng vẫn giữ nguyên quyền cũ, cộng thêm quyền mới. Rủi ro này gọi là gì?

• A. Federation
• B. Phình quyền (privilege creep)
• C. Dương tính giả
• D. Tokenization

Câu 2. Bước nào giúp phát hiện và gỡ các quyền không còn cần thiết thông qua việc quản lý hoặc chủ sở hữu xác nhận định kỳ?

• A. Attestation (rà soát quyền định kỳ)
• B. Provisioning
• C. Hashing
• D. Port forwarding

Câu 3. Chuẩn nào dựa trên XML, dùng assertion do IdP ký để thực hiện SSO và federation cho ứng dụng web doanh nghiệp?

• A. LDAP
• B. Kerberos
• C. OAuth 2.0
• D. SAML

Câu 4. Ứng dụng chỉ cần được phép đọc lịch của người dùng mà không nhận mật khẩu của họ. Chuẩn nào phù hợp nhất với nhu cầu ủy quyền này?

• A. LDAP
• B. SNMP
• C. OAuth 2.0
• D. NTP

Câu 5. Khi đăng nhập qua federation, ứng dụng (SP) nhận được gì từ IdP?

• A. Mật khẩu của người dùng
• B. Token hoặc assertion do IdP ký, xác nhận danh tính người dùng
• C. Khóa riêng của IdP
• D. Toàn bộ cơ sở dữ liệu người dùng

👉 Đáp án

Câu 1: B — Quyền tích lũy khi chuyển vị trí mà không gỡ quyền cũ là phình quyền (privilege creep).

Câu 2: A — Attestation là rà soát định kỳ để xác nhận và gỡ quyền không còn cần.

Câu 3: D — SAML dùng XML và assertion do IdP ký cho SSO và federation.

Câu 4: C — OAuth 2.0 là chuẩn ủy quyền, cấp token có phạm vi mà không chia sẻ mật khẩu.

Câu 5: B — SP nhận token hoặc assertion đã ký từ IdP, không bao giờ nhận mật khẩu người dùng.

📚 Bài viết thuộc khóa học CompTIA Security+ của VNExperts

🧭 Điều hướng