Hierarchie von Accounts und Subusern

(Abschnitt: Operationen und Management)

1) Aufgabe und Grundsätze

Die Accounthierarchie definiert, wie Organisationen und Personen auf die Ressourcen der Plattform zugreifen und wie Rechte, Quoten, Budgets und Verantwortlichkeiten verteilt werden.

• Trennung von Concerns: Die Geschäftsstruktur spiegelt sich im Entity Tree und die Rechte in den Policies wider.
• Least Privilege: Standardmäßig minimale Rollen, vorübergehende Erhöhung durch JIT.
• Composability: Rollen/Kontingente/Limits werden geerbt und überschrieben.
• Policy-as-Code: Zugriffsrichtlinien, Quoten, Abrechnung - versionierbare Artefakte.
• Auditability: Jede Aktivität korreliert mit Subjekt, Kontext und Signatur.

2) Referenzmodell der Hierarchie

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: Eigentümer von Verträgen, High-Level-Billing, globalen Richtlinien und SSOs.
• Account: isolierter Verantwortungsbereich (Marke/Land/BU); eigene Budgets/Limits.
• Sub-Account: Arbeitseinheit (Produkt/Stream/Team); Ihre Schlüssel, Kontingente, Rollen und Audits.

3) Berechtigungsmodelle

RBAC: роли Owner/Admin/Operator/Viewer/Billing/Compliance.
ABAC: атрибуты `region`, `tenant`, `account`, `environment`, `risk_score`, `device_posture`.
ReBAC: Besitz-/Beteiligungs-/Revuit-Beziehungen für Projekte und Geheimnisse.

Praxis: Hybrid - RBAC als lesbare Basis, ABAC für Kontextbeschränkungen (Region/Zeit/Gerät), ReBAC für Ressourcenbesitz.

4) Delegation und Vererbung

Delegieren nach unten: Der Tenant-Admin gibt die Rolle Account Admin aus, das ist der Sub-Account Maintainer.
Überschreibungen: Quoten/Limits/Policies können baumabwärts verschärft werden.
Trust Boundaries: PII/Finanzen - nur in „Vertrauenszonen“ der Account-Ebene; Ein Sub-Account sieht Token/Aggregate.
Break-glass: Notzugang mit kurzer TTL, Auto-Alert und Post-Mortem.

5) Quoten, Budgets, Abrechnung

Kontingente: Abfragen/sec, Ereignisse/Tag, egress, Speicher, Schlüssel/Webhooks.
Budgets: monatliche Mundschutz und Alerts (80/90/100%), Auto-Trotting/Suspendierung.
Abrechnung: Rechnungen auf Tenant/Account-Ebene; Schnitte nach Sub-Account und Tags (Kostenstellen).
Transfer Pricing: Interne Aufladungen zwischen BUs/Regionen.
Fair-use: Öffentliche Limits, Rate-Limits, Schutz vor „Bursten“.

6) Identitäten und SSO/SCIM

SSO (SAML/OIDC): zentraler Eingang auf Tenant-Ebene.
SCIM: Automatische Erstellung/Deaktivierung von Benutzern/Gruppen und Bindung an Rollen.
JML (Joiner/Mover/Leaver): automatische Ausgabe von Startrollen, Überarbeitung beim Übersetzen, sofortiger Rückruf bei Entlassung.
MFA/FIDO2: obligatorisch für Admins, Finanzen und Zugang zu PII.
Device Posture: Gerätestatus-Toleranz (Verschlüsselung, EDR).

7) Service-Rechnungen und Schlüssel

Service Account per Sub-Account + Umgebung, ohne geteilte Geheimnisse.
Workload Identity: kurzlebige Token, Bindung an Pod/Funktion.
KMS/Vault: Rotation der Geheimnisse, rollenbasierter Zugriff, DSSE-Signaturen.
Webhooks: HMAC/EdDSA Signaturen, 'nonce + timestamp', TTL-Fenster.

8) Datenmodell (vereinfacht)

`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-Verträge

• 'POST/tenants/{ id }/accounts' - Konto erstellen (Richtlinien/Kontingente/Abrechnung).
• 'POST/accounts/{ id }/sub-accounts' - Erstellen Sie ein Sub-Konto (Schlüssel, Webhooks).
• 'PUT/roles/{ id}' - Rollenrichtlinie; 'POST/memberships' - Rolle zuweisen.
• „POST/access/elevate“ - JIT-Erhöhung mit TTL und Begründung.
• „GET/quotas/usage“ - Verwendung/cap; „POST/quotas/override“.

• `GET /audit/events? scope =...'- signierte Protokolle.
• 'GET/status/access' - aktive Rollen/TTL/Schlüssel.
• Вебхуки: `QuotaCapReached`, `RoleExpiring`, `KeyRotationDue`, `PolicyChanged`.

10) RACI (Schlüsselbereiche)

11) Metriken und SLOs

TTG (Time-to-Grant): Median der Ausgabe eines Standardzugangs ≤ 4 Stunden

JIT Coverage: ≥ 80% der privilegierten Operationen durch temporäre Rollen.

SoD Violations: 0 в prod; TTR Elimination ≤ 24 Stunden

Orphaned Access: Anteil der „vergessenen“ Rechte ≤ 0 1%.
Quota Accuracy: Übereinstimmung der Gebühren/Nutzung ≥ 99. 99%.
Audit Completeness: 100% kritische Aktivitäten mit Unterschrift/Quittung.

12) Dashboards

Access Health: Aktive Rollen nach Level, auslaufende TTL, SoD-Verstöße.
FinOps: Quotennutzung, Budgetprognose, egress/compute Anomalien.
Sicherheit: Schlüsselrotation, MFA/SSO-Ausfälle, Risikokohorten.
Compliance: Rezertifizierungsstatus, Audit-Protokolle, Richtlinienverstöße.
Operationen: MTTR Zugriffsanfragen, TTFI für neue Teams.

13) Abgrenzung von Daten und Privatsphäre

Daten-Domains: PII/Finanzen - nur auf Account-Ebene; Unterkonto - Aggregate/Token.
Regionalität: Lokalisierung von Daten und Schlüsseln pro Region (Vertrauenszonen).
Anfragen an PII: nur über genehmigte Jobs; Tokenisierung und Maskierung.

14) Risiken und Anti-Muster

Flat-Modell: Alles - "Admins' → Vorfälle und Lecks.
Geteilte Geheimnisse: Unauffindbarkeit und Unmöglichkeit von Bewertungen.
Kein SoD: Eine Person erstellt und genehmigt Auszahlungen/Limits.
Nicht aufgelöste Umgebungen: dev-Schlüssel in prod; Vermischung von Test- und Realdaten.
„Unendliche“ Rollen: Ohne TTL/Rezertifizierung → eine Anhäufung von Risiken.
Schwache Quoten: Ein Sub-Account „frisst“ die Kapazität aller.

15) Playbooks der Vorfälle

Kompromittierung des Sub-Account-Schlüssels: sofortiger Widerruf, Rotation der Abhängigkeiten, Neuberechnung der Quoten, Audit der letzten 7-30 Tage.
Quotenüberschreitung: automatisches Trotten/Pausieren, Benachrichtigung des Eigentümers, vorübergehender Budgetdeckel.
Verstoß gegen SoD: Sperrung des Betriebs, vorübergehende Rollentrennung, Untersuchung und Fixierung der Politik.
Ersatz von Webhooks: Verbot des Empfangs ohne Unterschrift/außerhalb von TTL, Re-Key, Status-Endpoint von Sweeks.

16) Onboarding und Lebenszyklus

1. Initialisierung von Tenant: SSO/SCIM, Abrechnungsprofil, globale Richtlinien.
2. Konto erstellen: Regionen, Kontingente, Budgets, Datenzonen, Basisrollen.
3. Unterkonto: Schlüssel/Webhooks, Teamrollen, Integrationen.
4. JML/Rezertifizierung: vierteljährliche Überprüfung der Rechte, automatische Entfernung von „Schläfern“.
5. EOL: Archiv, Schlüsselrücknahme, Eigentumsübertragung, Rechnungsabschluss.

17) Checkliste Umsetzung

• Vereinbaren Sie den Tenant → Account → Sub-Account-Baum und die Vererbungsregeln.
• Rollen beschreiben (RBAC) und Kontextrichtlinien (ABAC), SoD-Matrix.
• Starten Sie SSO/SCIM, JML-Prozesse und JIT-Upgrades.
• Kontingente/Budgets/Cap-Regeln und Alerting einführen.
• Bereitstellung von KMS/Vault, Rotation und Verbot von geteilten Geheimnissen.
• Aktivieren Sie Policies-as-Code, signierte Releases und WORM-Logs.
• Konfiguration von Management-APIs/Webhooks, Status-Endpoints und Audits.
• Erstellen Sie Access/FinOps/Security/Compliance Dashboards.
• GameDay durchführen: Schlüsselleck, Quotensturm, IdP-Ausfall, SoD-Verstoß.
• Rollen regelmäßig rezertifizieren und Limits überprüfen.

18) FAQ

Wo halte ich die Grenze zwischen Account und Sub-Account?
Wo sich die Finanzen/Compliance/Regulatorik (Account) ändert und der Sub-Account sich um das Team/Produkt/Umfeld dreht.

Können Kontingente mehrerer Sub-Accounts „geklebt“ werden?
Ja, durch Pools und Prioritäten, aber mit Sicherungen gegen das „Ausbrennen“ von Kapazitäten.

Wie schnell kann ich einen temporären Zugang gewähren?
JIT-Anwendung mit MFA und TTL, Autologation und Post-Mortem für bevorzugte Sitzungen.

Brauche ich mittwochs unterschiedliche Schlüssel?
Obligatorisch: separate Service Accounts/Schlüssel für dev/stage/prod mit Isolierung von Netzwerken und Rechten.

Zusammenfassung: Die Hierarchie von Accounts und Subusern ist der Rahmen der Verwaltbarkeit: lesbare Entitätsstruktur, vererbbare Richtlinien, strenge Quoten und Abrechnungen, sichere Identitäten und nachweisbare Audits. Durch die Implementierung eines Hybrids aus RBAC/ABAC/ReBAC, JIT/SoD und Policy-as-Code erhalten Sie schnelles Onboarding, vorhersehbare Kosten und nachhaltige Sicherheit, wenn Sie nach Produkten, Teams und Regionen skalieren.