Hierarchy of accounts and sub-users

(Section: Operations and Management)

1) Task and principles

The hierarchy of accounts defines how organizations and people gain access to platform resources and how rights, quotas, budgets and responsibilities are distributed.

• Separation of Concerns: we reflect the structure of the business in the entity tree, and the rights in the policies.
• Least Privilege: default - minimum roles, temporary promotion via JIT.
• Composability: roles/quotas/limits are inherited and overridden.
• Policy-as-Code: access policies, quotas, billing - versioned artifacts.
• Auditability - Each action is correlated to a subject, context, and signature.

2) Hierarchy reference model

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: owner of contracts, high-level billing, global policies and SSOs.
• Account: isolated area of ​ ​ responsibility (brand/country/company code); own budgets/limits.
• Sub-account: work unit (product/stream/command); your keys, quotas, roles, and auditing.

3) Authorization models

RBAC: роли Owner/Admin/Operator/Viewer/Billing/Compliance.
ABAC: атрибуты `region`, `tenant`, `account`, `environment`, `risk_score`, `device_posture`.
ReBAC: "owns/participates/reviews" relationships for projects and secrets.

Practice: Hybrid - RBAC as a readable basis, ABAC for context constraints (region/time/device), ReBAC for resource ownership.

4) Delegation and inheritance

Delegation down: Tenant-admin gives the Account Admin role, the same - Sub-account Maintainer.
Overrides: Quotas/limits/policies can be tightened down the tree.
Trust Boundaries: PII/Finance - only in Account-level "trust zones"; Sub-account sees tokens/aggregates.
Break-glass: emergency access with short TTL, auto-alert and post-mortem.

5) Quotas, budgets, billing

Quotas: requests/sec, events/day, egress, storage, keys/webhooks.
Budgets: monthly caps and alerts (80/90/100%), auto-throttling/suspension.
Billing: invoices at Tenant/Account level; Sub-account and cost centers sections.
Transfer Pricing: internal charges between BUs/regions.

Fair-use: public limits, rate-limits, protection against "bursts."

6) Identities and SSO/SCIM

SSO (SAML/OIDC): centralized entry at Tenant level.
SCIM: automatic creation/deactivation of users/groups and binding to roles.
JML (Joiner/Mover/Leaver): auto-issuance of starting roles, revision during translation, instant recall upon dismissal.
MFA/FIDO2: mandatory for admins, finance and access to PII.
Device Posture: device status tolerance (encryption, EDR).

7) Service accounts and keys

Service Account per Sub-account + Environment, no shared secrets.
Workload Identity: short-lived tokens, binding to the bottom/function.
KMS/Vault: secret rotation, role access, DSSE signatures.
Webhooks: HMAC/EdDSA signatures, 'nonce + timestamp', TTL window.

8) Data model (simplified)

`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 Contracts

• 'POST/tenants/{ id }/accounts' - create Account (policies/quotas/billing).
• 'POST/accounts/{ id }/sub-accounts' - create a Sub-account (keys, webhooks).
• 'PUT/roles/{ id} '- role policy;' POST/members' - assign a role.
• 'POST/access/elevate '- JIT boost with TTL and justification.
• 'GET/quotas/usage '- usage/cap;' POST/quotas/override '.

• `GET /audit/events? scope =... '- signed logs.
• 'GET/status/access' - acting roles/TTL/keys.
• Вебхуки: `QuotaCapReached`, `RoleExpiring`, `KeyRotationDue`, `PolicyChanged`.

10) RACI (key areas)

11) Metrics and SLO

TTG (Time-to-Grant): median standard access issue ≤ 4 hours

JIT Coverage: ≥ 80% of privileged transactions through temporary roles.
SoD Violations: 0 в prod; Elimination TTR ≤ 24 h.
Orphaned Access: share of "forgotten" rights ≤ 0. 1%.
Quota Accuracy: matching accruals/usage ≥ 99. 99%.
Audit Completeness: 100% critical signature/receipt activity.

12) Dashboards

Access Health: active roles by level, expiring TTL, SoD violations.
FinOps: quota usage, budget forecast, egress/compute anomalies.
Security: key rotation, MFA/SSO failures, risk rate of cohorts.
Compliance: recertification status, audit logs, policy violations.
Operations: MTTR access requests, TTFI for new commands.

13) Data delimitation and privacy

Data Domains: PII/Finance - Account level only; Sub-account - aggregates/tokens.
Regionality: localization of data and keys per-region (trust zones).
PII requests: through approved jabs only; tokenization and masking.

14) Risks and anti-patterns

Flat-model: all - "admins →" incidents and leaks.
Shared secrets: untraceability and impossibility of reviews.
No SoD: One person creates and approves payments/limits.
Unposted environments: dev keys in prod; mixing test and real data.
"Infinite" roles: no TTL/recertification → risk accumulation.
Weak quotas: one Sub-account "eats up" the capacity of everyone.

15) Incident playbooks

Compromise of the Sub-account key: immediate revocation, rotation of dependencies, recalculation of quotas, audit of the last 7-30 days.
Exceeding quotas: automatic throttling/pause, notification of the owner, temporary budget cap.
Violation of SoD: blocking the operation, temporarily removing the role, investigating and fixing the policy.
Substitution of webhooks: prohibition of reception without a signature/outside TTL, re-key, status-endpoint reconciliation.

16) Onboarding and life cycle

1. Tenant initialization: SSO/SCIM, billing profile, global policies.

2. Create Account - Regions, Quotas, Budgets, Data Zones, Base Roles

3. Sub-account: keys/webhooks, team roles, integrations.

4. JML/Recertification: quarterly review of rights, auto-removal of "sleepers."

5. EOL: archive, key recall, ownership transfer, billing closure.

17) Implementation checklist

• Reconcile Tenant → Account → Sub-account tree and inheritance rules.
• Describe roles (RBAC) and context policies (ABAC), SoD matrix.
• Start SSO/SCIM, JML processes and JIT boosts.
• Enter quotas/budgets/cap rules and alert.
• Deploy KMS/Vault, rotations, and shared secrets.
• Include policies-as-code, signed releases, and WORM logs.
• Configure management APIs/webhooks, status endpoints, and auditing.
• Build Access/FinOps/Security/Compliance dashboards.
• Conduct GameDay: key leak, quota storm, IdP failure, SoD violation.
• Regularly recertify roles and review limits.

18) FAQ

Where to keep the border between Account and Sub-account?
Where finances/compliance/regulatory (Account) change, and Sub-account - about the team/product/environment.

Is it possible to "glue" quotas of several Sub-accounts?
Yes, through pools and priorities, but with capacity "burn out" fuses.

How to quickly issue temporary access?
JIT application with MFA and TTL, autologation and post-mortem for privileged sessions.

Do I need different keys on Wednesdays?
Required: separate Service Accounts/keys for dev/stage/prod with isolation of networks and rights.

Summary: The hierarchy of accounts and sub-users is a framework of manageability: a readable structure of entities, inherited policies, strict quotas and billing, secure identities, and provable auditing. By implementing the RBAC/ABAC/ReBAC, JIT/SoD, and policy-as-code hybrid, you will gain fast onboarding, predictable costs, and sustainable security when scaled by product, team, and region.