Identity & Access Management

简短摘要

IAM是流程，策略和工具的集合，可确保谁可以访问内容，在什么条件下以及如何控制它。目标：最大限度地减少多余的权限、减少攻击表面、加速盘绕和审计、合规性（PCI DSS、GDPR等）以及可测量的访问可靠性。

基本概念

身份（身份）：人员（雇员、承包商）、服务/应用程序、设备。
身份验证（AuthN）：验证"谁"（密码→ MFA → FIDO2/passkeys无杆电路）。
授权（AuthZ）："允许什么"解决方案（RBAC/ABAC/ReBAC，策略）。
凭证（Credentials）：密码、密钥、令牌、证书（mTLS）。
秘密管理：KMS/HSM/Vault，轮换，短TTL，动态秘密。
生命周期：Joiner-Mover-Leaver （JML）-创建、更改角色、召回。

IAM目标体系结构

• IdP（身份提供者）：SSO，MFA，目录，联邦（OIDC/SAML），风险策略。
• PDP/PEP：决定/实施-策略引擎（OPA/Cedar）+应用点（API网关，代理，服务-mesh）。
• 目录/人力资源系统：员工和角色的真相来源。
• Provigining： SCIM/Automation用于创建/修改/撤消访问权限。
• 审计：集中式登录、UEBA、角色和访问报告。

• SSO（+MFA）→令牌发布（OIDC/JWT/SAML）→ PEP检查令牌/上下文→ PDP根据策略（角色/属性/风险）进行决策→应用程序签发/拒绝访问。

身份验证： 从密码到密码

密码：只有密码管理器,最少12-14个字符,没有"按日历"轮换,但在事件中是强制性的。
默认的MFA：TOTP/WebAuthn/Push；避免SMS作为主要因素。
无杆输入：关键域的FIDO2/passkeys。
自适应AuthN：考虑风险信号（地理、ASN、设备、异常）→要求额外的因素/阻塞。

授权： RBAC，ABAC，ReBAC

RBAC：与功能相对应的角色（支持，财务，DevOps）。简单易懂，但"蔓延"。
ABAC：属性规则（部门、风险级别、时间、区域、资源标签）。可扩展。
ReBAC："属于谁"关系（项目所有者，团队成员）。适用于多重场景。

• 结合RBAC（基本网格）+ABAC/ReBAC（上下文/边界）。
• JIT （Just-In-Time）：通过查询/应用程序授予临时权限,自动召回。
• JEA （Just-Enough Access）：最低限度的操作权。
• PAM：孤立的"强"访问（DB/云管理器），具有会话代理，屏幕/命令记录和短暂生命信用。

联合会和SSO

协议：OIDC（JWT令牌），SAML 2。0 （XML assertions）-用于外部提供商/合作伙伴。
SSO：使用MFA的单一入口点,减少网络钓鱼,集中反馈。
B2B/B2C：与合作伙伴建立联盟，限制领域和政策。
mTLS/m2m：对于服务,请使用简短的x.509 （SPIFFE/SVID）或Client Credentials OAuth2。

生命周期（JML）和provigining

Joiner：从HR/目录中自动分配帐户和基本角色。
Mover：按属性（部门、项目、位置）自动更改角色。
Leaver：立即召回SSO 、密钥、令牌、存储库/云访问/CI/CD。
流程：访问申请（ITSM），SoD矩阵（职责分工），定期访问评论。

秘密、密钥和轮换

KMS/HSM：存储根/关键键,包括操作审核。
Vault/Secrets经理：TTL完成时的动态信条（DB、云）、自动咆哮。
轮换：OAuth令牌，JWT签名密钥，服务密码-如期和发生事件。
mTLS：短期证书（小时/日）,自动超额发放。

策略和解决方桉引擎

声明性：将政治家保存在Git中；检查CI（策略测试）。
上下文：时间/位置/ASN/风险级别/设备状态 （MDM/EDR）。

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

监控、SLO和审计

• AuthN/AuthZ（%）成功率,p95登录时间/决策时间,MFA/无杆输入的比例。
• 在JIT/PAM升级中，特权平均持续时间。
• 覆盖复杂设备，短暂的秘密比例。

• SSO/IdP ≥ 99的可用性。每月95%。
• p95 AuthZ decision ≤ 50 мс.
• 100%关闭帐户≤离岸后15分钟。
• 审核和UEBA：集中式不可更改的逻辑（访问，角色更改，失败的输入，PDP解决方案），行为分析和异常焦虑。

IAM中的重构事件

令牌/密钥的损害：立即召回,强制登录,签名密钥的轮换,简短的秘密。
滥用权限：暂停帐户,阻止JIT/JEA,对相邻实体进行访问审查。
IdP不可用：离线模式（具有短TTL的令牌临时缓存验证），优先恢复过程。
网络钓鱼：强制性MFA，会话风险检查，通知用户，培训。

云和Kubernetes（模式）

公共云IAM：使用具有优先特权的本机角色；代替"永恒"密钥是带有OIDC联盟到云的工作负载（IRSA/Workload Identity）。
Kubernetes：RBAC在neimspace/角色上，限制"集群管理"；秘密-通过外部经理；L7策略的mesh+OPA服务；管理控制器（签名映像，禁令"：最新"）。
API网关：JWT/mTLS检查、速度限制、敏感端点查询签名（HMAC）。

iGaming/fintech的实践

访问域：支付、反欺诈、PII、内容提供商-隔离角色和网络段。
SoD：禁止组合冲突角色（例如，创建促销活动+批准付款）。
PAM和JIT：仅通过会话经纪人访问PSP/银行和 prod-DB，并进行记录和自动召回。
合规性：PCI DSS-MFA，最低特权，CHD区域细分；GDPR是最小化数据和PII访问点日志的原理。
合作伙伴和内容提供商：联合会和按年龄段的政策；短寿命令牌和IP/ASN allow-list。

典型错误

"永恒"钥匙和令牌：没有轮换，TTL →高泄漏风险。
手动离岸："幽灵般"的出入→权利撤销延误。
整体角色：一个"超级角色"而不是组成和属性。
MFA仅在管理中：MFA必须适用于所有输入和关键操作。
无处可去：缺乏集中化，UEBA →后来的事件检测。

IAM实施路线图

1.用户/服务/资源清单；数据和灵敏度图。
2.SSO+MFA for All，包括抗菌因子。
3.角色模型：上下文的基本RBAC+属性（ABAC）；SoD矩阵。
4.Provigining SCIM：从HR/目录中自动发布/更改/撤销权利；ITSM的申请和申请。
5.PAM和JIT/JEA：用于特权访问；TTL简短会议记录。
6.秘密管理：放弃静态密钥；动态秘密，轮换，具有简短证书的mTLS。
7.Git+CI中的策略：规则测试、更改控制、策略金丝雀部署。
8.可观察性和SLO：AuthN/AuthZ dashbords，Alerta，定期访问评论。

工件示例

AWS IAM Policy（至少读取S3报告）

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC（命名空间扫描开发人员）

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC： ABAC的声明（示例）

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

策略可能需要与资源匹配的"device_compliant=true"和"tenant"。

核对清单（检查清单）

• 所有应用程序均启用SSO；默认的MFA，优先级为paskeys。
• RBAC已确定；ABAC/ReBAC添加上下文；JIT/JEA实现。
• PAM保护特权访问；会议记录在桉。
• HR的SCIM-proviging；离岸板是完全自动化的。
• 秘密是动态的，TTL短；轮换是自动化的。
• 政客在Git中进行考试，在CI中进行测试；有金丝雀布置。
• AuthN/AuthZ的Dashbords和SLO；集中式日志和UEBA。
• 定期访问审查和SoD检查；合并的报告。

FAQ

每个人都需要一个ReBAC吗？
没有。对于简单的环境，RBAC+ABAC足够。ReBAC在复杂的资源所有权和多项性层次结构中很有用。

可以保留本地帐户吗?

仅适用于断面和离线场景,具有严格的限制和定期检查。

如何减少"角色爆炸"？
提高资源的粒度,使用AWAS/模板,自动化咆哮,并放弃未使用的角色。

底线

成熟的IAM体系结构是SSO+MFA，最低要求权限，自动化JML，集中式策略和可观察性。通过将RBAC与属性模型和关系模型结合使用，应用JIT/JEA和PAM，以及自动分配和旋转秘密，您可以获得可管理，可验证和可扩展的访问，以满足安全和业务要求。