IAM và PAM là gì? Hướng dẫn Identity, SSO, MFA, RBAC, ABAC và Privileged Access

IAM và PAM là gì? Hướng dẫn Identity, SSO, MFA, RBAC, ABAC, Service Account và Privileged Access

Ảnh PNG đã được mở kiểm tra hiển thị trước khi đưa vào file Markdown. Ảnh trích xuất từ website chính thức Keycloak, dùng minh họa cho SSO/login. Không dùng SVG.¹

Ảnh PNG đã được mở kiểm tra hiển thị trước khi đưa vào file Markdown. Ảnh trích xuất từ website chính thức Keycloak, dùng minh họa cho quản trị IAM. Không dùng SVG.²

Ảnh PNG đã được mở kiểm tra hiển thị trước khi đưa vào file Markdown. Ảnh trích xuất từ website chính thức Keycloak, dùng minh họa cho quản lý phiên đăng nhập và thiết bị người dùng. Không dùng SVG.³

Tóm tắt nhanh

IAM là viết tắt của Identity and Access Management: hệ thống chính sách, quy trình và công nghệ để quản lý danh tính, xác thực người dùng/dịch vụ, cấp quyền truy cập, kiểm soát vòng đời tài khoản và ghi nhận audit. IAM trả lời các câu hỏi: ai là người dùng, họ đăng nhập thế nào, họ thuộc nhóm nào, được truy cập ứng dụng nào, quyền đó hết hạn khi nào và ai phê duyệt.

PAM là viết tắt của Privileged Access Management: quản lý quyền đặc quyền như admin hệ thống, root, database admin, cloud admin, Kubernetes cluster-admin, break-glass account, service account quyền cao và tài khoản CI/CD có thể deploy production. PAM tập trung vào quyền nguy hiểm nhất.

NIST SP 800-63 Revision 4 là bộ Digital Identity Guidelines gồm yêu cầu cho identity proofing, authentication và federation, đồng thời cập nhật nhiều nội dung cho rủi ro mới như synced passkeys, continuous evaluation metrics và forged media/deepfakes.⁴ OWASP Authorization Cheat Sheet nhấn mạnh authorization khác authentication; một user đã xác thực không có nghĩa là được phép truy cập mọi resource hoặc action.⁵ Keycloak tự mô tả là hệ thống Open Source Identity and Access Management, hỗ trợ SSO, identity brokering, user federation, admin console, account management, OpenID Connect, OAuth 2.0 và SAML.⁶

Nói ngắn gọn: IAM kiểm soát danh tính và quyền truy cập nói chung; PAM kiểm soát quyền đặc quyền có thể gây thiệt hại lớn nếu bị lạm dụng.

Vì sao IAM/PAM là nền tảng bảo mật IT?

Nhiều sự cố bảo mật không bắt đầu bằng malware phức tạp. Chúng bắt đầu bằng tài khoản bị chiếm, token bị lộ, quyền quá rộng hoặc tài khoản cũ chưa bị xóa.

Ví dụ:

Nhân viên nghỉ việc
  ↓
Tài khoản SaaS chưa bị disable
  ↓
Token API vẫn còn hoạt động
  ↓
Dữ liệu khách hàng bị export

Hoặc:

CI/CD secret bị lộ
  ↓
Attacker lấy cloud admin key
  ↓
Tạo resource mới / đọc database backup / sửa DNS
  ↓
Chiếm quyền hệ thống

IAM/PAM tốt giúp giảm các rủi ro này bằng cách:

• xác thực mạnh hơn;
• cấp quyền tối thiểu;
• tự động thu hồi quyền;
• buộc phê duyệt cho quyền cao;
• ghi log đầy đủ;
• phát hiện hành vi bất thường;
• giảm tài khoản admin vĩnh viễn;
• quản lý cả human identity và machine identity.

IAM không phải là gì?

PAM không phải là gì?

Authentication, Authorization và Accounting

Sai lầm phổ biến là nghĩ “đăng nhập thành công” đồng nghĩa “được phép truy cập”. OWASP nhấn mạnh authentication và authorization là hai việc khác nhau; user đã authenticated không có nghĩa là authorized cho mọi resource/action.⁵

Identity lifecycle: Joiner, Mover, Leaver

IAM tốt bắt đầu từ vòng đời tài khoản.

Joiner

Khi người mới vào:

• tạo tài khoản theo HR source;
• gán group/role theo vị trí;
• bật MFA/passkey;
• cấp thiết bị;
• cấp SaaS cần thiết;
• ghi nhận approval;
• training security cơ bản.

Mover

Khi người đổi vị trí:

• xóa quyền role cũ;
• cấp quyền role mới;
• review quyền đặc biệt;
• kiểm tra group nested;
• cập nhật owner/team;
• revoke token không còn cần.

Leaver

Khi người nghỉ:

• disable tài khoản ngay;
• revoke session;
• revoke refresh token/API token;
• remove khỏi group;
• thu hồi thiết bị;
• rotate shared secret nếu có;
• chuyển ownership tài nguyên;
• giữ audit log theo retention.

Vấn đề thường nằm ở “mover”: người đổi team nhưng vẫn giữ quyền cũ, tạo privilege creep.

SSO là gì?

SSO là Single Sign-On: người dùng đăng nhập một lần qua identity provider, sau đó truy cập nhiều ứng dụng mà không phải đăng nhập riêng lẻ từng app.

Keycloak mô tả SSO là việc user authenticate với Keycloak thay vì từng ứng dụng; sau khi login vào Keycloak, user không phải login lại để truy cập app khác dùng Keycloak.⁷

Lợi ích:

• giảm số mật khẩu;
• dễ bật MFA tập trung;
• disable user ở một nơi;
• audit login tập trung;
• tích hợp SaaS/app nội bộ;
• giảm tự xây login form kém an toàn.

Rủi ro:

• IdP trở thành điểm trọng yếu;
• cấu hình SAML/OIDC sai có thể gây bypass;
• session/token lifetime quá dài;
• app không kiểm tra token đúng;
• không có break-glass khi IdP lỗi.

MFA và Passkeys

MFA là xác thực đa yếu tố: kết hợp ít nhất hai loại yếu tố như thứ bạn biết, thứ bạn có, thứ bạn là.

Passkeys/WebAuthn/FIDO2 giúp giảm rủi ro phishing tốt hơn OTP SMS hoặc OTP email. NIST SP 800-63B Revision 4 cũng tích hợp syncable authenticators như synced passkeys vào guideline mới.⁴

Khuyến nghị:

• bắt buộc MFA cho mọi user;
• phishing-resistant MFA cho admin;
• không dùng SMS OTP cho quyền cao nếu có lựa chọn tốt hơn;
• hỗ trợ passkeys/security keys;
• yêu cầu step-up MFA cho action rủi ro;
• có quy trình recovery an toàn.

OAuth, OIDC và SAML trong IAM

OAuth 2.0

OAuth là framework ủy quyền, thường dùng để cấp access token cho client gọi API.

OpenID Connect

OIDC là lớp identity trên OAuth 2.0, dùng cho login/SSO. OIDC phù hợp app web/mobile/API hiện đại.

SAML

SAML là chuẩn federation lâu đời, phổ biến trong enterprise SaaS.

SCIM

SCIM dùng để provisioning/deprovisioning user và group giữa identity provider và ứng dụng. RFC 7644 định nghĩa SCIM Protocol.⁸

Bảng chọn nhanh:

RBAC, ABAC và ReBAC

RBAC

Role-Based Access Control cấp quyền theo vai trò.

Ví dụ:

role: finance_reader
permissions:
  - invoice:read
  - payment:read

Ưu điểm: dễ hiểu, dễ bắt đầu. Nhược điểm: role explosion khi hệ thống phức tạp.

ABAC

Attribute-Based Access Control quyết định theo thuộc tính.

Ví dụ:

allow if user.department == "finance"
and resource.department == "finance"
and request.time in business_hours
and device.compliant == true

Ưu điểm: linh hoạt. Nhược điểm: cần dữ liệu thuộc tính đáng tin cậy và policy rõ.

ReBAC

Relationship-Based Access Control quyết định theo quan hệ.

Ví dụ:

user Alice can view document X
if Alice is member of team Y
and team Y owns document X

Phù hợp hệ thống nhiều quan hệ như Google Drive, GitHub org/repo/team, CRM account ownership hoặc multi-tenant SaaS.

OWASP Authorization Cheat Sheet khuyến nghị cân nhắc Attribute-Based và Relationship-Based Access Control thay vì chỉ dựa vào RBAC khi yêu cầu phức tạp.⁵

Least privilege và deny by default

Hai nguyên tắc quan trọng:

Least privilege: chỉ cấp quyền tối thiểu cần thiết
Deny by default: không match rule thì từ chối

OWASP khuyến nghị enforce least privilege, deny by default và validate permissions trên mọi request.⁵

Ví dụ policy tốt:

User chỉ được đọc invoice của tenant mình
Admin support chỉ được impersonate user khi có ticket hợp lệ
Developer chỉ được deploy staging mặc định
Production deploy cần approval và MFA step-up

Ví dụ policy xấu:

Mọi nhân viên có thể đọc toàn bộ dashboard
Mọi developer có cloud admin
CI/CD token có quyền tạo/xóa mọi resource

Service account và machine identity

IAM không chỉ dành cho người. Hệ thống hiện đại có rất nhiều non-human identity:

• service account;
• API key;
• OAuth client;
• Kubernetes service account;
• cloud workload identity;
• CI/CD runner;
• database user;
• robot account;
• webhook secret;
• AI agent identity.

Rủi ro:

• secret không rotate;
• token không hết hạn;
• service account không có owner;
• quyền quá rộng;
• không biết app nào đang dùng;
• credentials nằm trong Git/log;
• không audit được hành động.

Khuyến nghị:

• mỗi service có identity riêng;
• owner rõ;
• scope tối thiểu;
• rotation;
• short-lived credentials;
• OIDC federation cho CI/CD;
• workload identity thay static keys;
• không dùng shared account;
• log theo service identity;
• xóa identity không dùng.

SPIFFE là một framework tiêu chuẩn hóa identity cho workload trong môi trường phân tán, thường được dùng trong mô hình Zero Trust workload identity.⁹

PAM: quản lý quyền đặc quyền

Privileged access gồm:

• domain admin;
• root/sudo;
• database admin;
• cloud admin;
• Kubernetes cluster-admin;
• firewall/DNS/CDN admin;
• break-glass account;
• CI/CD production deploy;
• secret manager admin;
• backup admin;
• IAM admin.

PAM nên có:

• vault credential;
• no shared password nếu có thể;
• MFA mạnh;
• just-in-time access;
• approval workflow;
• session recording/logging;
• command logging;
• break-glass policy;
• automatic rotation;
• periodic access review;
• alert hành vi bất thường.

Just-in-Time và Zero Standing Privilege

Standing privilege là quyền tồn tại sẵn, luôn bật. Ví dụ developer có quyền production admin 24/7 dù chỉ cần deploy mỗi tuần.

Just-in-Time access cấp quyền trong thời gian ngắn khi có lý do và approval.

Ví dụ:

User yêu cầu production database read-only
  ↓
Manager/owner approve
  ↓
MFA step-up
  ↓
Quyền được cấp 30 phút
  ↓
Session được log
  ↓
Quyền tự thu hồi

Mục tiêu là zero-standing privilege: không ai giữ quyền đặc quyền thường trực nếu không cần.

Access review

Access review là kiểm tra định kỳ ai có quyền gì và quyền đó còn cần không.

Nên review:

• admin roles;
• production access;
• database access;
• SaaS admin;
• GitHub org/repo admin;
• cloud IAM;
• Kubernetes RBAC;
• service accounts;
• API keys;
• break-glass accounts.

Câu hỏi cần trả lời:

Ai là owner của quyền này?
Người này còn thuộc team đó không?
Quyền này được dùng lần cuối khi nào?
Có ticket/approval không?
Có thể giảm scope không?
Có thể chuyển sang JIT không?

Audit logging cho IAM/PAM

Nên log:

• login success/failure;
• MFA enrollment/change;
• password/passkey reset;
• group/role change;
• privilege elevation;
• access request/approval;
• admin console action;
• token creation/revocation;
• service account key creation;
• SSO app config change;
• failed authorization;
• break-glass usage;
• session recording metadata.

Không nên log:

• password;
• OTP;
• access token;
• refresh token;
• private key;
• recovery code.

Alert nên có:

Admin login từ location lạ
MFA bị disable
Nhiều login failure
Role admin được gán ngoài change window
Service account key mới được tạo
Break-glass account được dùng
OAuth app mới được consent quyền rộng
Token validation failure spike

Keycloak dùng trong IAM như thế nào?

Keycloak là lựa chọn open-source phổ biến cho SSO/IAM. Website Keycloak mô tả nó là Open Source Identity and Access Management, hỗ trợ SSO, identity brokering, user federation, admin console, account management, OpenID Connect, OAuth 2.0, SAML và authorization services.⁶

Dùng Keycloak khi:

• cần SSO cho app nội bộ;
• cần OIDC/SAML;
• cần kết nối LDAP/Active Directory;
• cần user federation;
• cần quản lý realm/client/role;
• muốn self-host IAM;
• cần tùy biến login theme hoặc flow.

Cần lưu ý:

• Keycloak là hệ thống trọng yếu, phải backup và monitor;
• cấu hình token/session phải cẩn thận;
• realm/client redirect URI phải chặt;
• admin console cần MFA và RBAC;
• upgrade cần test;
• không để client secret lộ trong frontend;
• audit logs cần bật và gửi về SIEM/log platform.

OpenFGA, OPA và OPAL dùng ở đâu?

OpenFGA

OpenFGA là hệ thống authorization lấy cảm hứng từ Zanzibar, dùng cho fine-grained authorization và relationship-based access control. Phù hợp SaaS nhiều tenant, resource sharing, team/org/project permission.

OPA

Open Policy Agent là policy engine tổng quát, dùng Rego để quyết định policy cho Kubernetes, API gateway, CI/CD hoặc app authorization.

OPAL

OPAL là Open Policy Administration Layer cho policy engines như OPA và Cedar Agent; docs nói OPAL phát hiện thay đổi policy và policy data theo thời gian thực rồi đẩy update tới agents.¹⁰

Mô hình:

Application
  ↓ hỏi "user có được làm action này không?"
Authorization service / policy engine
  ↓
Policy + relationship/attribute data
  ↓
Decision: allow/deny

Không nên nhét toàn bộ logic authorization phức tạp vào frontend.

IAM/PAM cho cloud

Cloud IAM thường là nguồn rủi ro lớn.

Checklist:

• không dùng root account hằng ngày;
• MFA cho root/admin;
• tách account/project/subscription theo môi trường;
• least privilege IAM policy;
• không dùng wildcard * quá rộng;
• dùng role assumption/JIT;
• short-lived credentials;
• OIDC federation cho CI/CD;
• không lưu cloud access key lâu dài;
• detect public access;
• log IAM changes;
• review service principals;
• rotate keys;
• alert khi tạo admin policy.

IAM/PAM cho Kubernetes

Checklist:

• không dùng kubeconfig admin chia sẻ;
• OIDC integration cho user login;
• Kubernetes RBAC theo namespace;
• không cấp cluster-admin rộng;
• service account riêng cho workload;
• automount token false nếu không cần;
• audit kubectl exec, port-forward, secret reads;
• short-lived kube credentials;
• break-glass account có policy;
• GitOps controller quyền tối thiểu;
• CI/CD deploy chỉ trong namespace cần thiết.

IAM/PAM cho AI agents

AI agents có thể đọc file, gọi API, sửa code, chạy lệnh, tạo PR và deploy. Vì vậy cần identity riêng.

Checklist:

• mỗi agent có identity riêng;
• tool permission theo scope;
• không dùng user token cá nhân nếu có thể;
• approval cho action nguy hiểm;
• log mọi tool call;
• giới hạn file/network access;
• không đưa secret vào prompt;
• short-lived tokens;
• policy theo task;
• revoke agent khi không dùng;
• tách dev/staging/prod agent permission.

Roadmap 30/60/90 ngày

Ngày 1–30: nền tảng identity

• Kiểm kê user, group, app, admin account.
• Bật MFA cho admin.
• Bật MFA cho toàn bộ user nếu có thể.
• Tắt tài khoản không dùng.
• Chuẩn hóa SSO cho app quan trọng.
• Review cloud admin và SaaS admin.
• Tách tài khoản admin và tài khoản thường.
• Tạo quy trình joiner/mover/leaver.
• Bật audit logs cho IdP, cloud, Git, CI/CD.
• Kiểm kê service accounts/API keys.

Ngày 31–60: least privilege và lifecycle

• Áp RBAC/ABAC rõ ràng cho app quan trọng.
• SCIM provisioning/deprovisioning cho SaaS chính.
• Review group nested.
• Xóa quyền không dùng.
• Tạo access review định kỳ.
• Giảm permanent admin.
• Tạo break-glass policy.
• Rotate shared secrets.
• Chuyển CI/CD sang OIDC federation nếu có thể.
• Gắn owner cho service accounts.

Ngày 61–90: PAM và automation

• Triển khai JIT cho quyền production/cloud/database.
• Session logging cho admin access.
• Vault/secret manager cho privileged credentials.
• Alert khi role admin thay đổi.
• Phishing-resistant MFA cho admin.
• Policy-as-code cho authorization nếu phù hợp.
• Tạo dashboard IAM risk.
• Diễn tập leaver khẩn cấp.
• Diễn tập leaked service account key.
• Bắt đầu zero-standing privilege cho nhóm rủi ro cao.

Checklist triển khai nhanh

Identity

• SSO.
• MFA/passkeys.
• Strong recovery process.
• HR-driven lifecycle.
• SCIM provisioning.
• Device/session visibility.
• Audit logs.
• Dormant account cleanup.

Access

• Least privilege.
• Deny by default.
• RBAC/ABAC/ReBAC phù hợp.
• Access review.
• Policy tests.
• Ownership checks.
• Sensitive action step-up MFA.

Privileged Access

• No shared admin.
• JIT access.
• Approval workflow.
• Session logging.
• Break-glass account.
• Credential rotation.
• Admin MFA mạnh.
• Alerting.

Machine Identity

• Service account inventory.
• Owner cho từng identity.
• Short-lived credentials.
• OIDC federation.
• Secret rotation.
• Scope tối thiểu.
• Không để keys trong Git.
• Log theo service identity.

Sai lầm phổ biến

• Chỉ tập trung login, bỏ qua authorization.
• Không có quy trình leaver.
• Người đổi team vẫn giữ quyền cũ.
• Dùng shared admin account.
• Cloud admin cấp quá rộng.
• Service account không có owner.
• API key không hết hạn.
• Không biết OAuth app nào được consent.
• Không validate token audience/issuer.
• SAML/OIDC redirect URI quá rộng.
• Không bật MFA cho admin.
• Không có access review.
• Không log thay đổi quyền.
• Break-glass account không được test.
• CI/CD dùng static cloud key lâu dài.

Tooling tham khảo

FAQ

IAM là gì?

IAM là Identity and Access Management: quản lý danh tính, xác thực, phân quyền, vòng đời tài khoản, provisioning/deprovisioning và audit.

PAM là gì?

PAM là Privileged Access Management: quản lý quyền đặc quyền như admin, root, cloud admin, database admin, Kubernetes cluster-admin, break-glass account và service account quyền cao.

Authentication khác authorization thế nào?

Authentication xác minh bạn là ai. Authorization quyết định bạn được làm gì. Một user đã đăng nhập không mặc định có quyền đọc/sửa mọi resource.⁵

SSO có đủ bảo mật không?

Không. SSO giúp quản lý login tập trung, nhưng vẫn cần MFA, token/session policy, authorization đúng, audit logs, app configuration an toàn và break-glass plan.

RBAC hay ABAC tốt hơn?

RBAC dễ bắt đầu và dễ hiểu. ABAC linh hoạt hơn khi cần policy dựa trên thuộc tính như department, device, location, risk. Hệ thống lớn có thể kết hợp RBAC + ABAC + ReBAC.

Service account có cần IAM governance không?

Có. Service account thường có quyền cao và ít được chú ý. Cần owner, scope, rotation, short-lived credential và audit.

Kết luận

IAM và PAM là nền tảng của bảo mật IT hiện đại. Nếu danh tính, quyền truy cập và tài khoản đặc quyền không được quản lý tốt, các lớp bảo mật khác sẽ yếu đi rất nhiều. Mục tiêu không phải chỉ là có màn hình đăng nhập, mà là kiểm soát toàn bộ vòng đời identity: ai được tạo tài khoản, được cấp quyền gì, vì sao được cấp, quyền tồn tại bao lâu, ai phê duyệt và hành động được ghi log thế nào.

Cách triển khai thực tế là bắt đầu bằng SSO, MFA, joiner/mover/leaver, audit logs và review tài khoản admin. Sau đó giảm privilege creep, áp least privilege, quản lý service account, dùng SCIM, chuyển quyền cao sang JIT/PAM và tiến tới zero-standing privilege cho hệ thống rủi ro cao. IAM/PAM tốt sẽ giảm đáng kể rủi ro account takeover, insider threat, credential leak và cloud privilege escalation.

Nguồn tham khảo

Footnotes

1. Keycloak official website image, login screen. https://www.keycloak.org/resources/images/screen-login.png ↩

2. Keycloak official website image, admin console. https://www.keycloak.org/resources/images/screen-admin.png ↩

3. Keycloak official website image, account management. https://www.keycloak.org/resources/images/screen-account.png ↩

4. NIST SP 800-63 Revision 4. “Digital Identity Guidelines.” https://pages.nist.gov/800-63-4/ ↩ ↩²

5. OWASP Cheat Sheet Series. “Authorization Cheat Sheet.” https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html ↩ ↩² ↩³ ↩⁴ ↩⁵

6. Keycloak official website. https://www.keycloak.org/ ↩ ↩²

7. Keycloak official website, Single-Sign On section. https://www.keycloak.org/ ↩

8. RFC 7644. “System for Cross-domain Identity Management: Protocol.” https://www.rfc-editor.org/rfc/rfc7644 ↩

9. SPIFFE. https://spiffe.io/ ↩

10. OPAL Docs. https://docs.opal.ac/ ↩