Identity & Access ManagementIdentity & Access Management
Thuộc bộ kiến thức DevSecOps Roadmap.
Tổng quan
Identity & Access Management (IAM) là lĩnh vực trả lời câu hỏi: hệ thống của bạn biết ai (hoặc cái gì) đang thao tác, và kiểm soát họ được phép làm gì. Đây là bề mặt kiểm soát có tác động lớn nhất trong bảo mật: các báo cáo phân tích sự cố lớn (Verizon DBIR, năm này qua năm khác) đều cho thấy credential bị đánh cắp, quyền hạn dư thừa, và cấu hình access sai là nguyên nhân của phần lớn sự cố — nhiều hơn cả zero-day bị khai thác. Bạn không thể “vá lỗi” cho một identity đã bị chiếm đoạt và có quá nhiều quyền.
Trong bối cảnh DevSecOps, IAM không chỉ là “user đăng nhập vào website.” Nó bao trùm:
- Con người (human) — kỹ sư, vận hành, nhân viên hỗ trợ đăng nhập vào console, VPN, admin panel.
- Service — một payments API gọi tới một inventory API.
- Máy/workload — một CI/CD pipeline kéo secret về, một Kubernetes pod assume một cloud role, một Lambda function ghi dữ liệu vào S3.
Mỗi thứ trên đều là một identity cần được provisioning, authenticate, authorize, giám sát, và cuối cùng là deprovisioning. Khi các tổ chức chuyển sang microservices, multi-cloud, và hạ tầng ephemeral, số lượng non-human identity giờ đây vượt xa số lượng human identity — và chúng thường là mắt xích yếu hơn, ít được audit hơn.
Note này tập trung vào chiến lược và kiến trúc IAM: các loại identity và vòng đời của chúng, các mô hình access control, least privilege, machine/workload identity trong cloud và CI/CD, và governance ở quy mô lớn. Cơ chế chi tiết về cách các giao thức authentication hoạt động (password hashing, JWT, các luồng OAuth2/OIDC/SAML, session) được trình bày đầy đủ tại ../backend/en/07-authentication-and-authorization.md — note này xây dựng dựa trên đó và không lặp lại. Các khối xây dựng mật mã (ký số, quản lý key) nằm ở ./04-cryptography-fundamentals.md; việc identity gắn kết như thế nào trong mô hình zero-trust network nằm ở ./08-network-security-and-zero-trust.md; và vận hành IAM xuyên suốt nhiều team/business unit được mở rộng tại ./17-enterprise-security-at-scale.md.
Kiến thức nền tảng
Identity là gì?
Một identity (hay principal) là bất cứ thứ gì có thể được authenticate và có thể gắn permission vào. Có ba nhóm chính:
| Loại identity | Ví dụ | Đặc điểm phân biệt |
|---|---|---|
| Human | Nhân viên, contractor, khách hàng, admin | Có tên/email, dùng MFA, được kỳ vọng đăng nhập tương tác, chịu các sự kiện joiner/mover/leaver của HR |
| Service (application) | Payments service gọi inventory service, backend gọi API bên thứ ba | Identity dài hạn gắn với từng application/service; thường authenticate bằng API key, mTLS cert, hoặc OAuth2 client credentials |
| Machine/workload | CI/CD job, Kubernetes pod, VM, serverless function, container | Thường ngắn hạn và ephemeral; lý tưởng là dùng credential được cấp phát động, tự động rotate thay vì static secret |
Một số framework (ví dụ NIST SP 800-63) chia nhỏ hơn mức độ tin cậy của human identity thành ba trục độc lập: Identity Assurance Level (IAL) — bạn đã xác minh danh tính thật của người đó kỹ đến mức nào; Authenticator Assurance Level (AAL) — cơ chế đăng nhập mạnh đến đâu (password vs. MFA vs. hardware key); và Federation Assurance Level (FAL) — mức độ tin cậy của một assertion đến từ identity provider bên ngoài. Sự phân tách này quan trọng vì một hệ thống có thể yêu cầu authentication mạnh (AAL cao) mà không cần xác minh danh tính thật ngoài đời (IAL thấp) — ví dụ một account ẩn danh chỉ cần đăng nhập mạnh.
Vòng đời của identity
Mọi identity — con người hay máy — đều nên trải qua một vòng đời được kiểm soát. Việc bỏ qua các bước là nơi hầu hết các lỗi IAM trong thực tế bắt nguồn.
- 01Yêu cầu/Provision
- 02Authenticate
- 03Authorizetheo từng hành động
- 04Review/Recertifyaccess review định kỳ quay lại Yêu cầu/Provision
- 05Deprovision
| Giai đoạn | Diễn ra gì | Ví dụ con người | Ví dụ máy/service |
|---|---|---|---|
| 1. Provisioning | Tạo identity, gán entitlement dựa trên role/nhu cầu | Nhân viên mới nhận account qua HR onboarding + yêu cầu role được duyệt | Một microservice mới nhận service account/IAM role giới hạn theo đúng resource cần dùng |
| 2. Authentication | Identity chứng minh mình là ai tại thời điểm truy cập | Password + MFA, đăng nhập SSO | Token ngắn hạn, mTLS client cert, token workload identity đã được ký |
| 3. Authorization | Từng hành động cụ thể được kiểm tra theo policy | ”User này có được refund đơn hàng không?" | "Pod này có được đọc S3 bucket này không?“ |
| 4. Sử dụng & giám sát | Access được log, bất thường được gắn cờ | Đăng nhập từ quốc gia lạ bị gắn cờ | Khối lượng API call bất thường từ một service account bị gắn cờ |
| 5. Review / recertification | Xác minh định kỳ xem access có còn cần thiết không | Manager recertify access của nhân viên mỗi quý | Team sở hữu recertify xem service nào vẫn còn gọi tới một API cụ thể |
| 6. Deprovisioning | Xóa access khi không còn cần | Nhân viên bị offboard vào ngày làm việc cuối | Credential/role của service đã ngừng hoạt động bị xóa |
Các lỗi IAM phổ biến nhất (privilege creep, orphaned account — trình bày ở phần sau) về bản chất là lỗi vòng đời: bước 1 cấp quá nhiều quyền, hoặc bước 6 không bao giờ xảy ra.
Authentication vs. Authorization — nhắc lại nhanh
IAM dựa trên sự phân biệt giữa authentication (AuthN) — chứng minh bạn là ai — và authorization (AuthZ) — quyết định bạn được phép làm gì sau khi đã biết bạn là ai. Cơ chế chi tiết (password hashing, session, JWT, OAuth2/OIDC, SAML, mTLS) được trình bày đầy đủ tại ../backend/en/07-authentication-and-authorization.md. Thứ IAM bổ sung thêm là lớp governance: những identity nào tồn tại, chúng được cấp quyền gì, mô hình hóa quyền đó ra sao (RBAC/ABAC), quyền được cấp và review theo thời gian như thế nào, và được enforce nhất quán ra sao trên toàn bộ service, cloud account, và pipeline của tổ chức — chứ không chỉ là màn hình login của một application đơn lẻ.
Khái niệm chính
Các mô hình access control: RBAC vs. ABAC vs. ACL vs. PBAC
Khi đã biết ai đó là ai, bạn cần một mô hình để quyết định họ được làm gì. Bốn mô hình phổ biến:
| Mô hình | Cách quyết định access | Ví dụ | Điểm mạnh | Điểm yếu |
|---|---|---|---|---|
| ACL (Access Control List) | Một danh sách gắn vào từng resource, ghi rõ principal nào được permission nào | ”file.txt: alice=read/write, bob=read” | Đơn giản, trực quan, chi tiết theo từng resource | Không scale — N resource × M user = phình to khủng khiếp; khó audit “alice có thể làm gì ở mọi nơi?” |
| RBAC (Role-Based Access Control) | Permission gắn vào role; user/service được gán vào role | ”Role billing-admin được đọc/ghi invoice; alice có role billing-admin” | Dễ suy luận, ánh xạ theo cơ cấu tổ chức, được hỗ trợ rộng rãi (AWS IAM, Kubernetes RBAC, hầu hết SaaS) | Bùng nổ số lượng role khi nhu cầu access trở nên chi tiết (“billing-admin-vùng-EU-chỉ-đọc-thứ-Ba”); mặc định khá thô |
| ABAC (Attribute-Based Access Control) | Policy engine đánh giá thuộc tính của user, resource, action, và môi trường tại thời điểm request | ”Cho phép nếu user.department == resource.owning_department AND đang trong giờ làm việc AND request.ip nằm trong dải IP công ty” | Cực kỳ chi tiết, động, nhận biết ngữ cảnh (thời gian, vị trí, tình trạng thiết bị); một policy có thể bao quát nhiều trường hợp | Khó audit hơn (“alice thực sự có thể làm gì?” đòi hỏi mô phỏng policy); phức tạp hơn để xây dựng/debug |
| PBAC / Policy-as-Code | Policy engine tập trung, có version (ví dụ OPA/Rego, Cedar) được service đánh giá lúc runtime | Kubernetes admission control qua OPA Gatekeeper; AWS Verified Permissions dựa trên Cedar | Policy là code — có thể test, review, version-control; tách policy ra khỏi code của application | Cần đầu tư vào tooling và kiến trúc policy decision point (PDP) |
Gợi ý thực tế: hầu hết tổ chức dùng RBAC làm xương sống (thô, dễ audit, khớp với chức năng công việc) và bổ sung ABAC/policy-as-code cho các trường hợp ngoại lệ và quy tắc chi tiết/theo ngữ cảnh (ví dụ: “kỹ sư chỉ được truy cập prod từ VPN, chỉ trong lúc đang xử lý incident, chỉ khi có ticket break-glass đã được duyệt”). ACL thuần thường chỉ tồn tại được trong file system và các team nhỏ; nó không scale được trong môi trường cloud-native với hàng ngàn resource.
Nguyên tắc Least Privilege (Nguyên tắc đặc quyền tối thiểu)
Least privilege nghĩa là mỗi identity — con người hay máy — chỉ được cấp bộ permission tối thiểu cần thiết để làm việc, trong khoảng thời gian tối thiểu, và không có gì thêm “để phòng hờ.” Trong thực tế:
- Bắt đầu từ zero, thêm quyền một cách rõ ràng. Default-deny. Cấp các permission/role cụ thể thay vì bắt đầu từ role admin rồi cố gắng thu hẹp lại.
- Giới hạn theo resource, không chỉ theo action.
s3:GetObjecttrên một bucket/prefix cụ thể, không phải trên*. Quyềnkubectltrên một namespace cụ thể, không phải cả cluster. - Access có giới hạn thời gian — Just-in-Time (JIT) access. Thay vì có permission admin thường trực, kỹ sư yêu cầu access nâng cao cho một tác vụ cụ thể, được duyệt (thường qua workflow tooling), và access đó tự động hết hạn sau một khoảng thời gian nhất định (ví dụ 1–4 giờ). Điều này thu hẹp “cửa sổ blast radius” — một credential bị lộ chỉ nguy hiểm khi nó vừa còn hiệu lực vừa có quyền cao, và JIT giảm thiểu sự chồng lấn đó.
- Privileged Access Management (PAM). Một nhóm tooling chuyên biệt (ví dụ CyberArk, HashiCorp Vault, Teleport, AWS IAM Identity Center + Access Analyzer, Azure PIM) quản lý vòng đời của các account có đặc quyền: vault hóa credential để con người không bao giờ thấy password gốc, ghi lại/proxy session cho các phiên có đặc quyền, tự động rotate credential sau khi dùng, workflow duyệt cho việc nâng quyền, và quy trình break-glass khẩn cấp với audit chặt chẽ.
- Separation of Duties (SoD — Phân tách nhiệm vụ). Không một identity nào nên nắm giữ hai quyền xung đột cho phép nó tự bypass một control một mình (ví dụ: người có thể duyệt deployment không nên là người duy nhất có thể tắt audit log).
Least privilege là một quá trình, không phải một cấu hình một lần — permission phải liên tục được right-size khi role và hệ thống thay đổi (xem access review bên dưới).
IAM trong cloud & hạ tầng: machine và workload identity
Nhóm identity phát triển nhanh nhất là non-human: CI/CD runner, container, serverless function, VM, và service mesh đều cần authenticate với thứ gì đó. Sự tiến hóa cốt lõi ở đây là chuyển từ static, long-lived secret sang credential được cấp phát động, ngắn hạn, dựa trên identity.
| Cách tiếp cận | Là gì | Ví dụ | Mức độ rủi ro |
|---|---|---|---|
| Static secret | API key, password, hoặc cặp access key được hardcode/lưu trữ, không có hạn dùng tích hợp | Cặp AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY nhúng trong biến môi trường hoặc biến CI | Rủi ro cao: không tự hết hạn, dễ bị lộ (log, git history), khó rotate, không gắn liền vốn dĩ với một workload cụ thể |
| Được cấp bởi secrets manager | Secret lưu tập trung, fetch lúc runtime, có thể rotate tập trung | HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager | Tốt hơn: rotate/audit tập trung, nhưng vẫn là bearer secret — ai giữ được là dùng được |
| Service account / IAM role | Identity có tên, cloud-native mà một resource (VM, function, pod) assume, không cần key tĩnh dài hạn | AWS IAM Role được assume qua EC2 instance profile hoặc Lambda execution role; GCP Service Account | Nền tảng cloud cấp phát credential tạm thời ngắn hạn, tự động rotate cho workload — không có gì để lộ trong repo |
| Workload identity federation | Một workload chứng minh identity bằng token native của platform (không bao giờ lưu trữ cloud credential), sau đó đổi lấy cloud credential ngắn hạn | GCP Workload Identity Federation, AWS IAM Roles for Service Accounts (IRSA) / EKS Pod Identity, GitHub Actions OIDC → assume cloud role | Tốt nhất: không có secret dài hạn nào ở bất cứ đâu; trust được thiết lập bằng mật mã học cho từng request; blast radius của một token bị lộ là tối thiểu vì token ngắn hạn và giới hạn phạm vi |
| SPIFFE/SPIRE | Chuẩn mở cấp phát tài liệu identity có thể xác minh bằng mật mã học (SVID) cho workload, độc lập với cloud provider | Dùng trong service mesh (Istio, Linkerd) cho mTLS giữa các service dựa trên workload identity thay vì IP/vị trí mạng | Cho phép zero-trust auth service-to-service xuyên cluster/cloud |
Secret vs. access dựa trên identity — sự khác biệt then chốt: một secret (API key, password, static token) là một bearer credential — ai sở hữu nó cũng dùng được, và hệ thống cấp access không có cách nào biết người sở hữu có hợp lệ hay không. Access dựa trên identity dựa vào việc workload chứng minh mình là ai (thông qua attestation của platform, token đã ký, hoặc certificate gắn với ngữ cảnh runtime của nó — ví dụ: “tôi là pod X trong namespace Y ở cluster Z”) và nhận credential được giới hạn phạm vi và thời gian theo bằng chứng đó. Xu hướng chiến lược trên toàn ngành (AWS, GCP, Azure, Kubernetes, GitHub Actions) là loại bỏ static secret dài hạn ở bất cứ đâu có workload identity federation — chỉ riêng điều này đã loại bỏ hẳn một nhóm sự cố (key bị lộ trong git repo, credential hardcode trong container image, secret trong CI log).
SSO & federation (tóm tắt)
Single Sign-On (SSO) cho phép user authenticate một lần với một Identity Provider (IdP) trung tâm (ví dụ Okta, Azure AD/Entra ID, Google Workspace) và truy cập nhiều application (Service Provider) phía sau mà không cần authenticate lại. Federation mở rộng sự tin cậy này xuyên biên giới tổ chức — ví dụ đăng nhập vào công cụ SaaS của đối tác bằng chính IdP của công ty bạn.
Với chiến lược IAM, những điểm quan trọng là:
- SSO/federation tập trung hóa quyết định authentication vào một nơi duy nhất, nghĩa là MFA, conditional access policy, và deprovisioning chỉ cần được enforce/cập nhật một lần tại IdP, thay vì ở từng application phía sau — giảm đáng kể gánh nặng vận hành và audit.
- Hai giao thức thống trị là SAML (cũ hơn, dựa trên XML, phổ biến trong SSO doanh nghiệp) và OIDC/OAuth2 (hiện đại, dựa trên JSON/JWT, phổ biến trong SaaS và hệ thống driven-by-API). Cơ chế giao thức — token, assertion, redirect flow, cách validate an toàn — được trình bày tại
../backend/en/07-authentication-and-authorization.md. - Từ góc nhìn governance của IAM, IdP trở thành hệ thống quan trọng nhất trong tổ chức: việc IdP (hoặc admin console của nó) bị xâm phạm tương đương với việc mọi application được kết nối bị xâm phạm cùng lúc. Nó cần được bảo vệ mạnh nhất (MFA chống phishing, admin access được hardening, break-glass account được quản lý bởi PAM) so với bất cứ thứ gì khác trong môi trường.
Chiến lược & governance identity ở quy mô lớn
Khi tổ chức phát triển vượt quá vài service và một cloud account, việc quản lý access theo kiểu ad hoc sẽ sụp đổ. Identity governance là tập hợp các quy trình và tooling giữ cho access luôn hợp lệ ở quy mô lớn:
- Identity Provider tập trung làm nguồn chân lý. Mọi human identity đều bắt nguồn từ một directory liên kết với HR (ví dụ qua SCIM provisioning) vào một IdP duy nhất, sau đó federate ra mọi application/cloud account — thay vì login riêng cho từng hệ thống.
- Tự động hóa Joiner-Mover-Leaver (JML). Access nên phản ứng tự động với các sự kiện HR/tổ chức: nhân viên mới được provision với access mặc định theo role (joiner); nhân viên chuyển team bị gỡ access team cũ và được cấp access team mới (mover); nhân viên rời đi bị deprovision ở mọi nơi trong một SLA xác định, lý tưởng là ngay lập tức (leaver). Xử lý JML thủ công là nguồn gốc lớn nhất của orphaned account và privilege creep.
- Entitlement management. Duy trì một kho dữ liệu chính xác, truy vấn được về ai có access gì tới resource nào, và vì sao (tức là approval/role nào đã cấp quyền đó). Các công cụ cloud-native như AWS IAM Access Analyzer, GCP Policy Analyzer, và Azure AD Entitlement Management giúp hiển thị điều này; các platform identity governance chuyên biệt (SailPoint, Saviynt) làm việc này ở quy mô doanh nghiệp xuyên nhiều hệ thống.
- Access review / recertification định kỳ. Theo chu kỳ đều đặn (thường là hàng quý, thường xuyên hơn với access rủi ro cao), chủ sở hữu resource/role phải chủ động xác nhận lại rằng mỗi quyền được cấp vẫn còn cần thiết, thay vì mặc định là ổn vì không ai phàn nàn. Review nên được cân nhắc theo mức rủi ro — access đặc quyền cao và hướng ra internet được review thường xuyên hơn access đọc rủi ro thấp.
- Nhất quán trên nhiều cloud/nhiều account. Khi một tổ chức trải rộng trên AWS + GCP + Azure + on-prem, ý định của IAM policy (ví dụ “kỹ sư mặc định chỉ được đọc prod”) nên được định nghĩa một lần và ánh xạ nhất quán vào mô hình IAM native của từng platform, thay vì được tái phát minh độc lập cho từng cloud — nếu không policy sẽ trôi dạt và xuất hiện khoảng hở giữa các môi trường.
- Identity là một phần của SDLC. Yêu cầu access, định nghĩa role, và thay đổi policy nên đi qua cùng kỷ luật review/version-control như code của application (policy-as-code, pull request cho thay đổi IAM policy, linting tự động cho permission quá rộng) thay vì được thực hiện ad hoc qua cloud console. Xem
./17-enterprise-security-at-scale.mdđể biết cách điều này scale xuyên nhiều team và business unit.
Các lỗi IAM thường gặp
| Lỗi | Biểu hiện | Vì sao xảy ra | Cách khắc phục |
|---|---|---|---|
| Privilege creep (tích lũy quyền) | Một nhân viên/service lâu năm tích lũy permission từ mọi role trong quá khứ, không bao giờ mất quyền cũ | Chuyển team/thăng chức cấp access mới nhưng hiếm khi thu hồi access cũ | Access review định kỳ; provisioning theo role thay thế thay vì cộng dồn; phát hiện tự động “permission không dùng đến” |
| Orphaned account (account mồ côi) | Account của nhân viên đã nghỉ, service đã ngừng hoạt động, hoặc contractor cũ không bao giờ bị xóa | Bước deprovisioning trong vòng đời là thủ công/bị bỏ qua; không có kho dữ liệu tập trung để nhận ra account vẫn tồn tại | Tự động hóa JML gắn với sự kiện HR/ticketing; audit định kỳ kho dữ liệu account; tự động disable sau ngưỡng không hoạt động |
| Role có quá nhiều quyền | Role/policy được cấp * hoặc quyền admin “cho an toàn” hoặc “để không bị chặn deadline,” không bao giờ xem lại | Cấu hình đúng least privileged ngay từ đầu khó/chậm hơn; không ai sở hữu việc thu hẹp lại sau này | Công cụ Access Analyzer/policy-linting gắn cờ permission không dùng; văn hóa default-deny + cấp quyền rõ ràng; review right-sizing định kỳ |
| Credential dùng chung/tổng quát | Một login “service” hoặc “admin” duy nhất được nhiều người/hệ thống dùng chung, không có attribution theo từng identity | Tiện lợi, hệ thống legacy không hỗ trợ account theo từng user, tránh chi phí setup IAM | Account/role riêng cho từng identity (con người hay máy); PAM vault hóa để credential dùng chung không bao giờ bị biết trực tiếp dù role dùng chung vẫn phải tồn tại; audit log mạnh gắn với session, không chỉ account |
| Access đặc quyền thường trực | Quyền admin/root được giữ vĩnh viễn thay vì chỉ được nâng lên khi cần | Chưa áp dụng tooling JIT/PAM; giả định sự tiện lợi quan trọng hơn rủi ro | Nâng quyền just-in-time với workflow duyệt và tự động hết hạn; quy trình break-glass cho tình huống khẩn cấp kèm review bắt buộc sau đó |
| Static secret dài hạn trong code/CI | API key hoặc cloud credential được hardcode hoặc lưu như biến CI dài hạn | Chưa thiết lập workload identity federation; “dán key vào cho tiện” | Chuyển sang workload identity federation / token ngắn hạn; secret scanning trong CI/CD và pre-commit hook |
| Policy không nhất quán giữa các cloud/team | ”Access prod chỉ đọc” có nghĩa khác nhau trên AWS vs. GCP vs. một công cụ admin nội bộ | Không có cơ quan policy trung tâm; mỗi team/cloud tự cấu hình IAM độc lập | Policy-as-code với một nguồn ý định duy nhất ánh xạ vào từng platform; identity governance tập trung |
Audit & monitoring cho IAM
Provisioning đúng thôi là chưa đủ — access phải quan sát được theo thời gian. Mọi sự kiện authentication, quyết định authorization, việc nâng quyền, và mọi thay đổi IAM mang tính hành chính (role mới, permission mới, user mới) nên được log vào một kho log tập trung, bất biến, và được giám sát để phát hiện bất thường (đi lại “bất khả thi,” khối lượng API call bất thường từ một service account, một role admin mới được cấp ngoài giờ change-management, đăng nhập từ một account đã bị disable). Việc này chồng lấn nhiều với chiến lược observability/SIEM rộng hơn của tổ chức — xem ./13-monitoring-and-logging.md để biết thiết kế pipeline log, và các use case phát hiện threat riêng cho sự kiện identity thuộc về các correlation rule của SIEM được trình bày ở đó. Tối thiểu, audit log dành riêng cho IAM nên trả lời được: ai đã authenticate, từ đâu, tới cái gì, họ được authorize làm gì, họ thực sự đã làm gì, và ai đã duyệt bất kỳ thay đổi quyền nào.
Best Practices
| Thực hành | Vì sao quan trọng |
|---|---|
| Enforce least privilege mặc định (default-deny, cấp quyền rõ ràng) | Thu hẹp blast radius của bất kỳ identity nào bị xâm phạm |
| Dùng RBAC làm nền tảng, ABAC/policy-as-code cho ngoại lệ | Giữ access dễ audit trong khi vẫn hỗ trợ quy tắc chi tiết/theo ngữ cảnh |
| Loại bỏ static secret dài hạn — dùng workload identity federation / token ngắn hạn bất cứ khi nào có thể | Loại bỏ hẳn một nhóm sự cố credential bị lộ |
| Bắt buộc MFA cho mọi human access, MFA chống phishing (FIDO2/WebAuthn) cho account đặc quyền/admin | Password đơn thuần luôn là vector initial-access hàng đầu trong các vụ vi phạm |
| Áp dụng Just-in-Time (JIT) access cho thao tác đặc quyền thay vì quyền admin thường trực | Giới hạn thời gian cửa sổ mà kẻ tấn công có thể khai thác một identity đặc quyền bị xâm phạm |
| Dùng giải pháp PAM để vault, rotate, và ghi lại credential/session đặc quyền | Loại bỏ việc con người phải cầm secret đặc quyền dạng gốc; cho phép điều tra session |
| Tự động hóa Joiner-Mover-Leaver qua tích hợp HR/ticketing | Loại bỏ nguyên nhân số 1 gây orphaned account và privilege creep |
| Chạy access review/recertification định kỳ, theo mức rủi ro | Bắt được sự trôi dạt mà kiểm soát lúc provisioning bỏ lỡ |
| Tập trung hóa authentication sau một IdP duy nhất được hardening (SSO/federation) | Điểm kiểm soát duy nhất cho MFA, conditional access, deprovisioning |
| Coi IAM policy là code — có version-control, review, lint cho permission quá rộng | Ngăn thay đổi ad hoc qua console âm thầm mở rộng access |
| Log và giám sát tập trung mọi sự kiện authN/authZ và thay đổi quyền | Cho phép phát hiện lạm dụng và hỗ trợ incident response/audit |
| Áp dụng Separation of Duties cho các hành động tác động lớn (deploy vs. duyệt, ghi vs. audit) | Ngăn một identity bị xâm phạm/độc hại tự bypass control một mình |
| Duy trì kho entitlement chính xác, truy vấn được xuyên mọi cloud/hệ thống | Giúp trả lời “ai truy cập được gì, và vì sao” trong vài phút, không phải vài tuần |
Tài liệu tham khảo
- NIST SP 800-63 — Digital Identity Guidelines — chuẩn liên bang Mỹ có tính thẩm quyền, bao quát identity proofing, authentication, và các mức độ tin cậy của federation.
- NIST SP 800-53 — Security and Privacy Controls (nhóm AC) — bộ control access control được hầu hết các framework compliance tham chiếu.
- NIST SP 800-207 — Zero Trust Architecture — identity là nền tảng của các quyết định access trong zero-trust; xem thêm
./08-network-security-and-zero-trust.md. - OWASP Top 10 — A01:2021 Broken Access Control — nhóm rủi ro web application phổ biến nhất, gắn trực tiếp với lỗi authorization.
- OWASP Application Security Verification Standard (ASVS) — chương V4/V8/V10 Access Control & Authentication — yêu cầu access control cụ thể, có thể kiểm thử được.
- SPIFFE — Secure Production Identity Framework for Everyone — chuẩn mở cho workload identity.
- AWS IAM Best Practices — hướng dẫn triển khai cụ thể theo cloud provider cho least privilege, role, và workload identity federation.
- Google Cloud — Workload Identity Federation — triển khai tham chiếu cho workload authentication không cần secret.
Part of the DevSecOps Roadmap knowledge base.
Overview
Identity & Access Management (IAM) is the discipline of knowing who (or what) is acting in your systems, and controlling what they are allowed to do. It is the single most impactful control surface in security: analyses of large breaches (Verizon DBIR year after year) consistently find that stolen credentials, excessive permissions, and misconfigured access are involved in the majority of incidents — more than any exploited zero-day. You cannot patch your way out of a compromised, over-privileged identity.
In a DevSecOps context, IAM is not just “user logs into a website.” It spans:
- Humans — engineers, operators, support staff logging into consoles, VPNs, admin panels.
- Services — a payments API calling an inventory API.
- Machines/workloads — a CI/CD pipeline pulling a secret, a Kubernetes pod assuming a cloud role, a Lambda function writing to S3.
Every one of these is an identity that needs to be provisioned, authenticated, authorized, monitored, and eventually deprovisioned. As organizations move to microservices, multi-cloud, and ephemeral infrastructure, the number of non-human identities now vastly outnumbers human ones — and they are frequently the weaker, less-audited link.
This note focuses on IAM strategy and architecture: identity types and lifecycle, access control models, least privilege, machine/workload identity in cloud and CI/CD, and governance at scale. The mechanics of how authentication protocols work (password hashing, JWTs, OAuth2/OIDC/SAML flows, sessions) are covered in depth in ../backend/en/07-authentication-and-authorization.md — this note builds on top of that and does not repeat it. Cryptographic building blocks (signing, key management) are in ./04-cryptography-fundamentals.md; how identity fits into a zero-trust network model is in ./08-network-security-and-zero-trust.md; and running IAM across many teams/business units is expanded in ./17-enterprise-security-at-scale.md.
Fundamentals
What is an identity?
An identity (or principal) is anything that can be authenticated and to which permissions can be attached. There are three broad categories:
| Identity type | Examples | Distinguishing traits |
|---|---|---|
| Human | Employee, contractor, customer, admin | Has a name/email, uses MFA, expected to log in interactively, subject to HR joiner/mover/leaver events |
| Service (application) | Payments service calling the inventory service, a backend calling a third-party API | Long-lived identity per application/service; typically authenticates with API keys, mTLS certs, or OAuth2 client credentials |
| Machine/workload | CI/CD job, Kubernetes pod, VM, serverless function, container | Often short-lived and ephemeral; ideally uses dynamically-issued, auto-rotating credentials rather than static secrets |
Some frameworks (e.g., NIST SP 800-63) further split human identity assurance into three independent axes: Identity Assurance Level (IAL) — how well you’ve verified who someone really is; Authenticator Assurance Level (AAL) — how strong the login mechanism is (password vs. MFA vs. hardware key); and Federation Assurance Level (FAL) — how trustworthy an assertion from an external identity provider is. This separation matters because a system can require strong authentication (high AAL) without ever verifying real-world identity (low IAL) — e.g., an anonymous account that just needs a strong login.
The identity lifecycle
Every identity — human or machine — should pass through a controlled lifecycle. Skipping stages is where most real-world IAM failures originate.
- 01Request/Provision
- 02Authenticate
- 03Authorizeper action
- 04Review/Recertifyperiodic access review loops back to Request/Provision
- 05Deprovision
| Stage | What happens | Human example | Machine/service example |
|---|---|---|---|
| 1. Provisioning | Identity is created, entitlements assigned based on role/need | New hire gets an account via HR onboarding + approved role request | A new microservice gets a service account/IAM role scoped to the resources it needs |
| 2. Authentication | Identity proves who it is at time of access | Password + MFA, SSO login | Short-lived token, mTLS client cert, signed workload identity token |
| 3. Authorization | Each specific action is checked against policy | ”Can this user refund an order?" | "Can this pod read this S3 bucket?“ |
| 4. Use & monitoring | Access is logged, anomalies flagged | Login from new country flagged | Unusual API call volume from a service account flagged |
| 5. Review / recertification | Periodic verification that access is still needed | Manager recertifies employee’s access quarterly | Owning team recertifies which services still call a given API |
| 6. Deprovisioning | Access removed when no longer needed | Employee offboarded on last day | Decommissioned service’s credentials/roles deleted |
The most common IAM failures (privilege creep, orphaned accounts — covered later) are essentially lifecycle failures: step 1 over-grants, or step 6 never happens.
Authentication vs. Authorization — quick recap
IAM rests on the distinction between authentication (AuthN) — proving who you are — and authorization (AuthZ) — deciding what you’re allowed to do once known. The mechanics (password hashing, sessions, JWTs, OAuth2/OIDC, SAML, mTLS) are covered in full in ../backend/en/07-authentication-and-authorization.md. What IAM adds on top is the governance layer: which identities exist, what they’re entitled to, how that’s modeled (RBAC/ABAC), how it’s granted and reviewed over time, and how it’s enforced consistently across every service, cloud account, and pipeline in the organization — not just a single application’s login box.
Key Concepts
Access control models: RBAC vs. ABAC vs. ACL vs. PBAC
Once you know who someone is, you need a model for deciding what they can do. The four common models:
| Model | How it decides access | Example | Strengths | Weaknesses |
|---|---|---|---|---|
| ACL (Access Control List) | A list attached to each resource naming which principals get which permissions | ”file.txt: alice=read/write, bob=read” | Simple, intuitive, fine-grained per resource | Doesn’t scale — N resources × M users = huge sprawl; hard to audit “what can alice do everywhere?” |
| RBAC (Role-Based Access Control) | Permissions attached to roles; users/services assigned to roles | ”Role billing-admin can read/write invoices; alice has role billing-admin” | Easy to reason about, maps to org structure, widely supported (AWS IAM, Kubernetes RBAC, most SaaS) | Role explosion when access needs get granular (“billing-admin-for-region-EU-read-only-Tuesdays”); coarse by default |
| ABAC (Attribute-Based Access Control) | Policy engine evaluates attributes of user, resource, action, and environment at request time | ”Allow if user.department == resource.owning_department AND time is business_hours AND request.ip in corp_range” | Extremely fine-grained, dynamic, context-aware (time, location, device posture); one policy can cover many cases | Harder to audit (“what can alice actually do?” requires policy simulation); more complex to build/debug |
| PBAC / Policy-as-Code | Centralized, versioned policy engine (e.g., OPA/Rego, Cedar) evaluated by services at runtime | Kubernetes admission control via OPA Gatekeeper; AWS Cedar-based Verified Permissions | Policies are code — testable, reviewable, version-controlled; decouples policy from application code | Requires investment in tooling and a policy decision point (PDP) architecture |
Practical guidance: most organizations use RBAC as the backbone (coarse, auditable, matches job functions) and layer ABAC/policy-as-code for exceptions and fine-grained/contextual rules (e.g., “engineers can access prod only from the VPN, only during an active incident, only with an approved break-glass ticket”). Pure ACLs tend to survive only in file systems and small teams; they don’t scale to cloud-native environments with thousands of resources.
The Principle of Least Privilege (PoLP)
Least privilege means every identity — human or machine — gets the minimum set of permissions required to do its job, for the minimum amount of time, and nothing more “just in case.” In practice:
- Start from zero, add explicitly. Default-deny. Grant specific permissions/roles rather than starting from an admin role and trying to restrict it.
- Scope by resource, not just action.
s3:GetObjecton a specific bucket/prefix, not on*.kubectlaccess to a specific namespace, not the whole cluster. - Time-bound access — Just-in-Time (JIT) access. Instead of standing admin permissions, engineers request elevated access for a specific task, get it approved (often via workflow tooling), and it automatically expires after a set window (e.g., 1–4 hours). This shrinks the “blast radius window” — a compromised credential is only dangerous while it’s both valid and privileged, and JIT minimizes the overlap.
- Privileged Access Management (PAM). A dedicated class of tooling (e.g., CyberArk, HashiCorp Vault, Teleport, AWS IAM Identity Center + Access Analyzer, Azure PIM) that manages the lifecycle of privileged accounts specifically: vaulting credentials so no human ever sees the raw password, session recording/proxying for privileged sessions, automatic credential rotation after use, approval workflows for elevation, and break-glass emergency access with heavy auditing.
- Separation of Duties (SoD). No single identity should hold two conflicting privileges that let it bypass a control alone (e.g., the person who can approve a deployment shouldn’t be the only one who can also disable the audit log).
Least privilege is a process, not a one-time configuration — permissions must be continuously right-sized as roles and systems change (see access reviews below).
IAM in cloud & infrastructure: machine and workload identity
The fastest-growing category of identity is non-human: CI/CD runners, containers, serverless functions, VMs, and service meshes all need to authenticate to something. The core evolution here is moving away from static, long-lived secrets and toward dynamically-issued, short-lived, identity-based credentials.
| Approach | What it is | Example | Risk profile |
|---|---|---|---|
| Static secrets | Hardcoded/stored API key, password, or access key pair with no built-in expiry | An AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY pair embedded in an env var or CI variable | High risk: doesn’t expire on its own, easy to leak (logs, git history), hard to rotate, no inherent link to a specific workload |
| Secrets manager-issued | Secret stored centrally, fetched at runtime, can be rotated centrally | HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager | Better: central rotation/audit, but still a bearer secret — whoever holds it can use it |
| Service accounts / IAM roles | Cloud-native named identity that a resource (VM, function, pod) assumes, without a static long-lived key | AWS IAM Role assumed via EC2 instance profile or Lambda execution role; GCP Service Account | The cloud platform vends short-lived, auto-rotated temporary credentials to the workload — nothing to leak in a repo |
| Workload identity federation | A workload proves its identity using a platform-native token (no cloud credential ever stored), which is exchanged for a short-lived cloud credential | GCP Workload Identity Federation, AWS IAM Roles for Service Accounts (IRSA) / EKS Pod Identity, GitHub Actions OIDC → cloud role assumption | Best: zero long-lived secrets anywhere; trust is established cryptographically per-request; blast radius of a leaked token is minimal since tokens are short-lived and scoped |
| SPIFFE/SPIRE | Open standard for workload identity issuing cryptographically verifiable identity documents (SVIDs) to workloads, independent of cloud provider | Used in service meshes (Istio, Linkerd) for mTLS between services based on workload identity rather than IP/network location | Enables zero-trust service-to-service auth across clusters/clouds |
Secrets vs. identity-based access — the key distinction: a secret (API key, password, static token) is a bearer credential — whoever possesses it can use it, and the system granting access has no way to know if the possessor is legitimate. Identity-based access relies on the workload proving who it is (via a platform attestation, signed token, or certificate tied to its runtime context — e.g., “I am pod X in namespace Y in cluster Z”) and receiving credentials scoped and time-limited to that proof. The strategic direction across the industry (AWS, GCP, Azure, Kubernetes, GitHub Actions) is to eliminate long-lived static secrets wherever workload identity federation is available — this alone removes an entire class of incidents (leaked keys in git repos, hardcoded credentials in container images, secrets in CI logs).
SSO & federation (brief)
Single Sign-On (SSO) lets a user authenticate once with a central Identity Provider (IdP) (e.g., Okta, Azure AD/Entra ID, Google Workspace) and access many downstream applications (Service Providers) without re-authenticating. Federation extends this trust across organizational boundaries — e.g., logging into a partner’s SaaS tool using your own company’s IdP.
For IAM strategy, the important points are:
- SSO/federation centralizes authentication decisions into one place, which means MFA, conditional access policies, and deprovisioning only need to be enforced/updated once at the IdP, rather than in every downstream application — a major reduction in operational and audit burden.
- The two dominant protocols are SAML (older, XML-based, common in enterprise SSO) and OIDC/OAuth2 (modern, JSON/JWT-based, common in SaaS and API-driven systems). Protocol mechanics — tokens, assertions, redirect flows, how to validate them securely — are covered in
../backend/en/07-authentication-and-authorization.md. - From an IAM governance view, the IdP becomes the single most critical system in the organization: compromise of the IdP (or its admin console) is equivalent to compromising every connected application at once. It must get the strongest protection (phishing-resistant MFA, hardened admin access, PAM-managed break-glass accounts) of anything in the environment.
Large-scale identity strategy & governance
As organizations grow past a handful of services and one cloud account, ad hoc access management collapses. Identity governance is the set of processes and tooling that keeps access legitimate at scale:
- Centralized Identity Provider as source of truth. All human identities flow from one HR-linked directory (e.g., via SCIM provisioning) into one IdP, which federates out to every application/cloud account — instead of separate logins per system.
- Joiner-Mover-Leaver (JML) automation. Access should react automatically to HR/organizational events: a new hire is provisioned with role-based default access (joiner); a transferred employee has old-team access removed and new-team access granted (mover); a departing employee is deprovisioned everywhere within a defined SLA, ideally immediately (leaver). Manual JML handling is the single largest source of orphaned accounts and privilege creep.
- Entitlement management. Maintaining an accurate, queryable inventory of who has what access to what resource, and why (i.e., which approval/role granted it). Cloud-native tools like AWS IAM Access Analyzer, GCP Policy Analyzer, and Azure AD Entitlement Management surface this; dedicated identity governance platforms (SailPoint, Saviynt) do this at enterprise scale across many systems.
- Periodic access reviews / recertification. On a regular cadence (commonly quarterly, more often for high-risk access), resource/role owners must actively re-affirm that each grant is still needed, rather than assuming it’s fine because nobody complained. Reviews should be risk-weighted — high-privilege and internet-facing access reviewed more frequently than low-risk read access.
- Multi-cloud/multi-account consistency. Where an organization spans AWS + GCP + Azure + on-prem, IAM policy intent (e.g., “engineers get read-only prod access by default”) should be defined once and mapped consistently across each platform’s native IAM model, rather than independently re-invented per cloud — otherwise policy drifts and gaps appear between environments.
- Identity as part of the SDLC. Access requests, role definitions, and policy changes should go through the same review/version-control discipline as application code (policy-as-code, pull requests for IAM policy changes, automated linting for overly broad permissions) rather than being made ad hoc through a cloud console. See
./17-enterprise-security-at-scale.mdfor how this scales across many teams and business units.
Common IAM failure modes
| Failure mode | What it looks like | Why it happens | Mitigation |
|---|---|---|---|
| Privilege creep | A long-tenured employee/service accumulates permissions from every past role, never losing old ones | Moves/promotions grant new access but rarely revoke old access | Periodic access reviews; role-based provisioning that replaces rather than adds; automated “unused permission” detection |
| Orphaned accounts | Accounts for departed employees, decommissioned services, or old contractors that are never deleted | Deprovisioning step of the lifecycle is manual/skipped; no central inventory to notice the account exists | JML automation tied to HR/ticketing events; periodic account inventory audits; automatic disable after inactivity threshold |
| Over-permissioned roles | Roles/policies granted * or admin-level access “to be safe” or “to unblock a deadline,” never revisited | Least privilege is harder/slower to configure correctly upfront; nobody owns tightening it later | Access Analyzer/policy-linting tools that flag unused permissions; default-deny + explicit grant culture; regular right-sizing reviews |
| Shared/generic credentials | A single “service” or “admin” login used by multiple people or systems, no per-identity attribution | Convenience, legacy systems that don’t support per-user accounts, avoiding IAM setup overhead | Individual accounts/roles for every identity (human or machine); PAM vaulting so shared credentials are never directly known even if a shared role must exist; strong audit logging tied to session, not just account |
| Standing privileged access | Admin/root-level access held permanently rather than elevated only when needed | JIT/PAM tooling not adopted; assumption that convenience outweighs risk | Just-in-time elevation with approval workflow and automatic expiry; break-glass process for emergencies with mandatory post-hoc review |
| Long-lived static secrets in code/CI | API keys or cloud credentials hardcoded or stored as long-lived CI variables | Workload identity federation not set up; “it’s easier to just paste the key” | Migrate to workload identity federation / short-lived tokens; secret scanning in CI/CD and pre-commit hooks |
| Inconsistent policy across clouds/teams | ”Read-only prod access” means something different on AWS vs. GCP vs. an internal admin tool | No central policy authority; each team/cloud IAM configured independently | Policy-as-code with a single source of intent mapped to each platform; centralized identity governance |
IAM auditing & monitoring
Provisioning correctly is not enough — access must be observable over time. Every authentication event, authorization decision, privilege elevation, and administrative IAM change (new role, new permission, new user) should be logged to an immutable, centralized log store and monitored for anomalies (impossible travel, unusual API call volume from a service account, a new admin role granted outside change-management hours, a login from a disabled account). This overlaps heavily with the org’s broader observability/SIEM strategy — see ./13-monitoring-and-logging.md for log pipeline design, and threat-detection use cases specific to identity events belong in the SIEM correlation rules covered there. At minimum, IAM-specific audit logs should answer: who authenticated, from where, to what, what they were authorized to do, what they actually did, and who approved any privilege change.
Best Practices
| Practice | Why it matters |
|---|---|
| Enforce least privilege by default (default-deny, explicit grants) | Shrinks blast radius of any single compromised identity |
| Use RBAC as the baseline, ABAC/policy-as-code for exceptions | Keeps access auditable while still supporting fine-grained/contextual rules |
| Eliminate long-lived static secrets — use workload identity federation / short-lived tokens wherever possible | Removes an entire class of leaked-credential incidents |
| Require MFA for all human access, phishing-resistant MFA (FIDO2/WebAuthn) for privileged/admin accounts | Passwords alone are consistently the top initial-access vector in breaches |
| Adopt Just-in-Time (JIT) access for privileged operations instead of standing admin rights | Time-bounds the window an attacker could exploit a compromised privileged identity |
| Use a PAM solution to vault, rotate, and record privileged credentials/sessions | Removes humans from ever handling raw privileged secrets; enables session forensics |
| Automate Joiner-Mover-Leaver via HR/ticketing integration | Eliminates the #1 cause of orphaned accounts and privilege creep |
| Run periodic, risk-weighted access reviews/recertification | Catches drift that provisioning-time controls miss |
| Centralize authentication behind one hardened IdP (SSO/federation) | Single point of control for MFA, conditional access, deprovisioning |
| Treat IAM policy as code — version-controlled, reviewed, linted for over-broad grants | Prevents ad hoc console changes from silently widening access |
| Log and monitor all authN/authZ events and privilege changes centrally | Enables detection of misuse and supports incident response/audits |
| Apply Separation of Duties for high-impact actions (deploy vs. approve, write vs. audit) | Prevents a single compromised/malicious identity from bypassing controls alone |
| Maintain an accurate, queryable entitlement inventory across all clouds/systems | Makes “who can access what, and why” answerable in minutes, not weeks |
References
- NIST SP 800-63 — Digital Identity Guidelines — the authoritative U.S. federal standard covering identity proofing, authentication, and federation assurance levels.
- NIST SP 800-53 — Security and Privacy Controls (AC family) — access control control catalog referenced by most compliance frameworks.
- NIST SP 800-207 — Zero Trust Architecture — identity as the foundation of zero-trust access decisions; see also
./08-network-security-and-zero-trust.md. - OWASP Top 10 — A01:2021 Broken Access Control — the most prevalent web application risk category, directly tied to authorization failures.
- OWASP Application Security Verification Standard (ASVS) — V4/V8/V10 Access Control & Authentication chapters — concrete, testable access control requirements.
- SPIFFE — Secure Production Identity Framework for Everyone — open standard for workload identity.
- AWS IAM Best Practices — cloud-provider-specific implementation guidance for least privilege, roles, and workload identity federation.
- Google Cloud — Workload Identity Federation — reference implementation of secretless workload authentication.