アカウントとサブユーザーの階層
（事業・管理）
1）タスクと原則
アカウントの階層は、組織や人々がどのようにプラットフォームリソースにアクセスし、権利、クォータ、予算、責任がどのように分散されるかを定義します。
原則：- 懸念の分離：事業の構造をエンティティツリーに反映し、ポリシーに権利を反映します。
- 最小権限：デフォルト-最小ロール、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)- テナント：契約の所有者、高レベル請求、グローバルポリシーとSSO。
- アカウント：責任の分離された領域（ブランド/国/会社コード）；独自の予算/限度。
- サブアカウント：作業単位（product/stream/command）；あなたのキー、クォータ、役割、および監査。
3）承認モデル
RBAC：オーナー/管理者/オペレーター/ビューア/請求/コンプライアンス。
ABAC： 'region'、 'tenant'、 'account'、 'environment'、 'risk_score'、 'device_posture'。
ReBAC：プロジェクトと秘密のための「所有/参加/レビュー」関係。
実践：ハイブリッド-可読基盤としてのRBAC、コンテキスト制約のためのABAC（地域/時間/デバイス）、リソース所有権のためのReBAC。
4）委任と相続
委任：テナント管理者は、サブアカウント管理者と同じアカウント管理者の役割を与えます。
オーバーライド：クォータ/リミット/ポリシーをツリーの下に締め付けることができます。
信託境界：PII/ファイナンス-アカウントレベルの「信託ゾーン」でのみ。サブアカウントにはトークン/集計が表示されます。
壊れ目ガラス：短いTTL、自動警報および後死亡との緊急アクセス。
5）クォータ、予算、請求
クォータ：requests/sec、 events/day、 exress、 storage、 key/webhook。
予算：毎月の帽子および警報（80/90/100％）、自動スロットル/懸濁液。
請求：テナント/アカウントレベルの請求書;サブアカウントとコストセンターセクション。
転送価格：BU/リージョン間の内部料金。
公正使用：公的制限、レート制限、「バースト」に対する保護。
6）アイデンティティとSSO/SCIM
SSO （SAML/OIDC）：テナントレベルでの集中エントリー。
SCIM：ユーザー/グループの自動作成/無効化、ロールへのバインディング。
JML （Joiner/Mover/Leaver）：開始ロールの自動発行、翻訳中の改訂、解雇時のインスタントリコール。
MFA/FIDO2：管理者、財務、PIIへのアクセスには必須です。
デバイスの姿勢：デバイスの状態許容差（暗号化、EDR）。
7）サービスアカウントとキー
サブアカウントごとのサービスアカウント+環境、共有秘密はありません。
Workload Identity：短命のトークン、下部/関数へのバインディング。
KMS/Vault：シークレットローテーション、ロールアクセス、DSSE署名。
Webhooks： HMAC/EdDSA署名、'nonce+timestamp'、 TTLウィンドウ。
8）データモデル（簡略化）
'tend'' {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 'sud' 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'-サブアカウント（キー、webhook）を作成します。
- 'PUT/roles/{ id}'-ロールポリシー；'POST/members-役割を割り当てます。
- 'POST/access/elevate'-TTLと正当化によるJITブースト。
- 'GET/quotas/usage'-usage/cap；'POST/quotas/override'。
- 'GET/監査/イベント？スコープ=……'-署名されたログ。
- 'GET/status/access'-演技ロール/TTL/キー。
- Вебхуки： 'QuotaCapReaced'、 'RoleExpiring'、 'KeyRotationDue'、 'PolicyChanged'。
10） RACI（主要分野）
11）メトリックとSLO
TTG （Time-to-Grant）： 標準アクセス問題の中央値≤ 4時間
JITカバレッジ：一時的な役割を通じて特権トランザクションの80％を≥します。
SoD違反：0 prod；排除TTR ≤ 24時間。
孤立したアクセス： 「忘れられた」権利の共有≤ 0。1%.
クォータ精度： accrulals/usage ≥ 99と一致しています。99%.
監査の完全性：100％重要な署名/領収書アクティビティ。
12）ダッシュボード
アクセスの健康：レベル別のアクティブな役割、TTLの期限切れ、SoD違反。
FinOps：クォータ使用量、予算予測、排出/計算異常。
セキュリティ：キー回転、MFA/SSO障害、コホートのリスク率。
コンプライアンス：再認証状況、監査ログ、ポリシー違反。
操作：MTTRアクセスリクエスト、新しいコマンドのTTFI。
13）データの区分とプライバシー
データドメイン：PII/ファイナンス-アカウントレベルのみ；サブアカウント-集計/トークン。
地域性：地域ごとのデータとキー（信頼ゾーン）のローカライズ。
PII要求：承認されたジャブのみを通じて；トークン化とマスキング。
14）リスクとアンチパターン
フラットモデル：all-「admins→」インシデントとリーク。
共有秘密：トレーサビリティとレビューの不可能。
No SoD： 1人が支払い/制限を作成し承認します。
未配置の環境：prodのdevキー；混合テストおよび実質データ。
「無限」の役割：TTL/再認証→リスク蓄積なし。
弱いクォータ：1つのサブアカウントが全員の容量を「食べ」ます。
15）インシデントプレイブック
サブアカウントキーの妥協：即時失効、依存関係の回転、クォータの再計算、過去7〜30日間の監査。
クォータを超える：自動スロットリング/一時停止、所有者の通知、一時的な予算上限。
SoD違反：操作をブロックし、役割を一時的に削除し、ポリシーを調査して修正します。
Webhookの置換：署名なし/外部TTL、再キー、ステータスエンドポイントの和解なしの受信の禁止。
16）オンボーディングとライフサイクル
1.テナントの初期化：SSO/SCIM、請求プロファイル、グローバルポリシー。
2.アカウントの作成： リージョン、クォータ、予算、データゾーン、ベースロール
3.サブアカウント：キー/Webhook、チームロール、統合。
4.JML/Recertification：四半期ごとに権利の見直し、「スリーパー」の自動削除。
5.EOL：アーカイブ、キーリコール、所有権移転、請求閉鎖。
17）実装チェックリスト
- テナント→アカウント→サブアカウントツリーと継承ルールを調整します。
- 役割（RBAC）とコンテキストポリシー（ABAC）、 SoD行列を記述する。
- SSO/SCIM、 JMLプロセス、JITブーストを開始します。
- クォータ/予算/キャップルールとアラートを入力します。
- KMS/Vault、回転、共有秘密を展開します。
- ポリシー・アズ・コード、署名済みリリース、およびWORMログを含める。
- 管理API/Webhook、ステータスエンドポイント、監査を構成します。
- アクセス/FinOps/セキュリティ/コンプライアンスのダッシュボードを構築します。
- GameDayを実施する：キーリーク、クォータストーム、IdP障害、SoD違反。
- 定期的に役割を再認識し、制限を見直す。
18） FAQ
アカウントとサブアカウントの境界を保つ場所は？
財務/コンプライアンス/規制（アカウント）の変更、サブアカウント-チーム/製品/環境について。
複数のサブアカウントのクォータを「接着」することは可能ですか？
はい、プールと優先順位を通して、しかし容量で「燃え尽きます」ヒューズ。
どのように迅速に一時的なアクセスを発行するには？
MFAとTTLによるJIT申請、特権セッションのための自動診断と死後。
水曜日に異なるキーが必要ですか？
必須：ネットワークと権利を分離したdev/stage/prodのサービスアカウント/キーを分離します。
概要：アカウントとサブユーザーの階層は、管理可能性のフレームワークです。エンティティの可読性の構造、継承されたポリシー、厳格なクォータと請求、セキュアなアイデンティティ、および証明可能な監査です。RBAC/ABAC/ReBAC、 JIT/SoD、ポリシー・アズ・コードハイブリッドを実装することで、製品、チーム、および地域によってスケールアップされると、迅速なオンボーディング、予測可能なコスト、および持続可能なセキュリティを得ることができます。