帐户和子用户的层次结构
（部分： 业务和管理）
1）挑战与原则
帐户层次结构定义了组织和人员如何访问平台资源以及如何分配权利，配额，预算和责任。
原则：- Concerns分离：业务结构反映在实体树中，权利反映在政策中。
- Least Privilege：默认情况下-最小角色,通过JIT临时晋升。
- Composability：角色/配额/限制是继承和重新定义的。
- Policy-as-Code：访问策略，配额，计费-可验证文物。
- Auditability：每个动作都与主题，上下文和签名相关。
2）层次结构的参考模型
Tenant
├─ Account - legally/operationally significant unit
│ ├─ Sub-account - Product/Region/Team/Project
│ │ ├─ Spaces/Projects/Environments: prod/stage/dev
│ │ └─ Roles and Groups (RBAC/ABAC) for People and Services
│ └─ Shares (limits, budgets, keys, integrations)
└─ Marketplace/Integrations/Affiliates (Outer Loops)- Tenant：合同，高级账单，全球政策和SSO的所有者。
- 帐户：孤立的责任区（品牌/国家/BE）；自己的预算/限额。
- 子帐户：工作单位（产品/流/命令）；他们的钥匙，配额，角色和审计。
3）授权模式
RBAC: роли Owner/Admin/Operator/Viewer/Billing/Compliance.
ABAC: атрибуты `region`, `tenant`, `account`, `environment`, `risk_score`, `device_posture`.
ReBAC：关系为项目和秘密"拥有/参与/复仇"。
实践：混合体-RBAC作为可读基础，ABAC用于上下文限制（区域/时间/设备），ReBAC用于资源所有权。
4）委派和继承
向下委托：Tenant-admin提供帐户管理员的角色，该角色是子帐户维护者。
重新定义：配额/限制/政策可能会在树上收紧。
Trust Boundaries：PII/财务-仅在Account级别的"信任区"中；Sub-account可以看到令牌/单元。
破玻璃： 紧急通道与短的TTL,自动变速器和后太平间.
5）配额，预算，账单
配额：查询/秒，事件/日，egress，存储，密钥/webhooks。
预算：每月上限和上限（80/90/100%），自动推销/暂停。
计费：Tenant/Account级别的发票；子帐户和标签（成本中心）的切口。
Transfer Pricing： BU/区域之间的内部间隔。
公平使用：公共限制，利率限制，对"burst"的保护。
6）身份和SSO/SCIM
SSO （SAML/OIDC）：在Tenant级别集中输入。
SCIM：自动创建/停用用户/组并绑定角色。
JML （Joiner/Mover/Leaver）：自动发布起始角色、翻译修订、解雇时即时召回。
MFA/FIDO2：对行政管理人员、财政管理人员和获得PII具有约束力。
设备发布：设备状态公差（加密、EDR）。
7）服务帐户和密钥
服务帐户按子帐户+环境，没有共享的秘密。
Workload Identity：短寿命令牌,绑定到Pod/Features。
KMS/Vault：保密轮换，角色访问，DSSE签名。
Webhooks：HMAC/EdDSA签名，"nonce+timestamp"，TTL窗口。
8）数据模型（简化）
`tenant` `{id, name, sso, billing_profile, policies[]}`
`account` `{id, tenant_id, region, legal_entity, quotas{}, budgets{}, risk_tier}`
`sub_account` `{id, account_id, product, environment, keys[], webhooks[], limits{}}`
`role` `{id, scope: tenant|account|sub_account, permissions[]}`
`membership` `{subject_id, role_id, scope_ref, ttl, justification}`
`policy` `{type: rbac|abac|sod|quota, version, rules, signature}`
`audit_event` `{who, what, where, when, trace_id, signature}`
`quota_usage` `{scope_ref, metric, window, used, cap}`
9） API合同
管理：- "POST/tenants/{id}/accounts"-创建帐户（政策/配额/计费）。
- "POST/accounts/{id}/sub-accounts"-创建Sub-account （keys, webhuks）。
- "PUT/roles/{id}-角色策略；'POST/memberships'-指定角色。
- "POST/access/elevate"-通过TTL和理由提高JIT。
- "GET/quotas/usage"-使用/cap； "POST/quotas/override"。
- `GET /audit/events?scope=……'是签名的日志。
- "GET/status/access"-当前角色/TTL/密钥。
- Вебхуки: `QuotaCapReached`, `RoleExpiring`, `KeyRotationDue`, `PolicyChanged`.
10） RACI（关键领域）
11）度量标准和SLO
TTG （Time-to-Grant）：标准访问中位数≤ 4小时。
JIT Coverage：通过临时角色≥ 80%的特权操作。
SoD Violations: 0 в prod;TTR消除≤ 24小时。
Orphaned Access： "被遗忘"权利的份额≤ 0。1%.
Quota Accuracy： 权责发生制/使用匹配≥ 99。99%.
审计完成：100%具有签名/收据的关键操作。
12）Dashbords
Access Health： TTL到期、SoD违规的各个级别的主动角色。
FinOps：配额使用，预算预测，egress/compute异常。
安全：关键轮换，MFA/SSO失败，风险争夺队列。
合规性：退出状态、审计日志、违反政策。
运营：访问请求的MTTR，用于新命令的TTFI。
13）数据划分和隐私
数据领域：PII/财务-仅在帐户级别；子帐户-单元/令牌。
区域性：数据和按区域（信任区）键的本地化。
对PII的查询：仅通过批准的乔巴人；令牌化和伪装。
14）风险和反模式
平坦模型：全部是"admins" →事件和泄漏。
共享秘密：不可追踪性和无法反馈。
没有SoD：一个人创建并批准付款/限额。
未映射的环境：prod中的dev键；测试和真实数据的溷合。
"无限"角色：没有TTL/衰退 →风险积累。
弱配额：一个Sub-account"吃掉"所有人的能力。
15）事件花花公子
子帐户密钥的损害：立即召回,依存关系轮换,配额重新计算,对过去7至30天的审核。
超过配额：自动转弯/暂停，业主通知，临时预算上限。
违反SoD：阻止操作，暂时解除角色，调查和固定策略。
取代webhooks：禁止无签名/退出TTL，re-key，交换状态。
16）Onbording和生命周期
1.Tenant初始化：SSO/SCIM、计费配置文件、全局策略。
2.创建帐户：区域，配额，预算，数据区域，基本角色。
3.子帐户：密钥/webhooks，团队角色，集成。
4.JML/衰退：每季度审查一次权利，自动取消"睡觉"。
5.EOL：存档，召回钥匙，转移所有权，关闭计费。
17）实施支票
- 协调Tenant → Account树→子帐户和继承规则。
- 描述角色（RBAC）和上下文策略（ABAC），SoD矩阵。
- 运行SSO/SCIM、JML进程和JIT增强。
- 引入配额/预算/配额规则和配额。
- 部署KMS/Vault、轮换和禁止共享秘密。
- 启用策略、签名版本和WORM日志。
- 配置管理API/webhooks、端到端状态和审核。
- 构建Access/FinOps/Security/Compliance行车记录板。
- 举办GameDay：钥匙泄漏、配额风暴、IdP故障、SoD违规。
- 定期重新认证角色和审查限制。
18) FAQ
帐户与子帐户之间的界限在哪里?
在财务/合规/监管（帐户）发生变化的地方，而子帐户则是关于团队/产品/环境的。
多个Sub-Account配额可以"粘合"吗?
是的，通过池和优先级，但具有电容的"烧焦"保险丝。
如何快速发出临时访问权限?
与MFA和TTL一起进行JIT申请，为特权会议进行自我介绍和后面介绍。
星期三需要不同的钥匙吗？
强制性：单独的服务帐户/密钥,用于隔离网络和权限的dev/stage/prod。
摘要：帐户和子用户的层次结构是可管理的框架：可读实体结构，可继承的策略，严格的配额和计费，安全身份和可证明的审计。通过实施RBAC/ABAC/ReBAC，JIT/SoD和policy-as-code混合体，您可以在跨产品，团队和地区扩展时获得快速提取，可预测的成本和可持续的安全性。