帳戶和子用戶的層次結構
（部分： 業務和管理）
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混合體，您可以在跨產品，團隊和地區擴展時獲得快速提取，可預測的成本和可持續的安全性。