Иерархия аккаунтов и субпользователей

(Раздел: Операции и Управление)

1) Задача и принципы

Иерархия аккаунтов определяет как организации и люди получают доступ к ресурсам платформы и как распределяются права, квоты, бюджеты и ответственность.

• Separation of 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.
• Account: изолированная зона ответственности (бренд/страна/БЕ); собственные бюджеты/лимиты.
• Sub-account: рабочая единица (продукт/поток/команда); свои ключи, квоты, роли и аудит.

3) Модели авторизации

RBAC: роли Owner/Admin/Operator/Viewer/Billing/Compliance.
ABAC: атрибуты `region`, `tenant`, `account`, `environment`, `risk_score`, `device_posture`.
ReBAC: отношения «владеет/участвует/ревьюит» для проектов и секретов.

Практика: гибрид — RBAC как читаемый базис, ABAC для контекстных ограничений (регион/время/устройство), ReBAC для владения ресурсами.

4) Делегирование и наследование

Делегирование вниз: Tenant-админ выдает роль Account Admin, тот — Sub-account Maintainer.
Переопределения: квоты/лимиты/политики могут ужесточаться вниз по дереву.
Trust Boundaries: PII/финансы — только в «зонах доверия» уровня Account; Sub-account видит токены/агрегаты.
Break-glass: аварийный доступ c коротким TTL, авто-алертом и пост-мортемом.

5) Квоты, бюджеты, биллинг

Квоты: запросы/сек, событий/день, egress, хранилище, ключи/вебхуки.
Бюджеты: месячные капы и алерты (80/90/100%), авто-тротлинг/приостановка.
Биллинг: инвойсы на уровне Tenant/Account; разрезы по Sub-account и тегам (cost centers).
Transfer Pricing: внутренние разнарядки между BU/регионами.
Fair-use: публичные лимиты, rate-limits, защита от «бурстов».

6) Идентичности и SSO/SCIM

SSO (SAML/OIDC): централизованный вход на уровне Tenant.
SCIM: автоматическое создание/деактивация пользователей/групп и привязка к ролям.
JML (Joiner/Mover/Leaver): авто-выдача стартовых ролей, пересмотр при переводе, мгновенный отзыв при увольнении.
MFA/FIDO2: обязательна для админов, финансов и доступа к PII.
Device Posture: допуск по состоянию устройства (шифрование, EDR).

7) Сервисные учетки и ключи

Service Account per Sub-account + Environment, без shared-секретов.
Workload Identity: краткоживущие токены, привязка к поду/функции.
KMS/Vault: ротация секретов, доступ по ролям, DSSE-подписи.
Вебхуки: подписи 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` — создать Account (политики/квоты/биллинг).
• `POST /accounts/{id}/sub-accounts` — создать Sub-account (ключи, вебхуки).
• `PUT /roles/{id}` — политика роли; `POST /memberships` — назначить роль.
• `POST /access/elevate` — JIT-повышение с TTL и обоснованием.
• `GET /quotas/usage` — использование/кап; `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%.
Audit Completeness: 100% критичных действий с подписью/квитанцией.

12) Дашборды

Access Health: активные роли по уровням, истекающие TTL, нарушения SoD.
FinOps: использование квот, прогноз бюджета, аномалии egress/compute.
Security: ротация ключей, провалы MFA/SSO, риск-скор когорт.
Compliance: статус рецертификации, аудит-логи, нарушения политик.
Operations: MTTR запросов на доступ, TTFI для новых команд.

13) Разграничение данных и приватность

Data Domains: PII/финансы — только на уровне Account; Sub-account — агрегаты/токены.
Региональность: локализация данных и ключей per-region (зоны доверия).
Запросы к PII: только через утвержденные джобы; токенизация и маскирование.

14) Риски и анти-паттерны

Flat-модель: все — «админы» → инциденты и утечки.
Shared-секреты: неотслеживаемость и невозможность отзывов.
Нет SoD: один человек создает и утверждает выплаты/лимиты.
Неразнесенные среды: dev-ключи в prod; смешение тестовых и реальных данных.
«Бесконечные» роли: без TTL/рецертификации → накопление рисков.
Слабые квоты: один Sub-account «съедает» емкость всех.

15) Плейбуки инцидентов

Компрометация ключа Sub-account: немедленный отзыв, ротация зависимостей, пересчет квот, аудит последних 7–30 дней.
Превышение квот: автоматический троттлинг/паузер, уведомление владельца, временный бюджетный кап.
Нарушение SoD: блокировка операции, временное снятие роли, расследование и фиксация политики.
Подмена вебхуков: запрет приема без подписи/вне TTL, re-key, статус-эндпоинт сверок.

16) Онбординг и жизненный цикл

1. Инициализация Tenant: SSO/SCIM, биллинг-профиль, глобальные политики.
2. Создание Account: регионы, квоты, бюджеты, зоны данных, базовые роли.
3. Sub-account: ключи/вебхуки, роли команд, интеграции.
4. JML/Рецертификация: ежеквартальный пересмотр прав, авто-снятие «спящих».
5. EOL: архив, отзыв ключей, перенос владения, закрытие биллинга.

17) Чек-лист внедрения

• Согласовать дерево Tenant → Account → Sub-account и правила наследования.
• Описать роли (RBAC) и контекстные политики (ABAC), матрицу SoD.
• Запустить SSO/SCIM, JML-процессы и JIT-повышения.
• Ввести квоты/бюджеты/кап-правила и алертинг.
• Развернуть KMS/Vault, ротации и запрет shared-секретов.
• Включить политики-как-код, подписанные релизы и WORM-журналы.
• Настроить API/вебхуки управления, статус-эндпоинты и аудит.
• Построить дашборды Access/FinOps/Security/Compliance.
• Провести GameDay: утечка ключа, квота-шторм, отказ IdP, нарушение SoD.
• Регулярно рецертифицировать роли и пересматривать лимиты.

18) FAQ

Где держать границу между Account и Sub-account?
Там, где меняются финансы/комплаенс/регуляторика (Account), а Sub-account — про команду/продукт/среду.

Можно ли «склеивать» квоты нескольких Sub-account?
Да, через пулы и приоритеты, но с предохранителями от «выжигания» емкости.

Как быстро выдать временный доступ?
JIT-заявка с MFA и TTL, автологирование и пост-мортем для привилегированных сессий.

Нужны ли разные ключи по средам?
Обязательно: отдельные Service Accounts/ключи для dev/stage/prod с изоляцией сетей и прав.

Резюме: Иерархия аккаунтов и субпользователей — это каркас управляемости: читаемая структура сущностей, наследуемые политики, строгие квоты и биллинг, безопасные идентичности и доказуемый аудит. Внедрив гибрид RBAC/ABAC/ReBAC, JIT/SoD и policy-as-code, вы получите быстрый онбординг, предсказуемые расходы и устойчивую безопасность при масштабировании по продуктам, командам и регионам.