Ролевое делегирование и доступы

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

1) Зачем ролевое делегирование

Цель — дать каждому участнику (сотруднику, партнеру, сервису) ровно столько прав, сколько нужно и ровно на столько времени, сколько необходимо, при полной трассируемости действий. Это снижает риски утечек и злоупотреблений, ускоряет онбординг и проход аудитов.

2) Модель доступа: уровни и домены

Домены доступа: люди (консоль/панели), сервисы (машинные токены), данные (таблицы/объекты), инфраструктура (облако/K8s), контрагенты (внешние интеграции), регионы/тенанты.
Уровни доверия: публичный → внутренний → защищенный (PII/финансы) → особо критичный (ключи/выплаты).
Зоны операций: prod / staging / sandbox; правило «из “ниже” в “выше” — только через утвержденные pipeline’ы».

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

RBAC: роли привязаны к задачам («Контент-редактор», «Оператор выплат»). Простой старт, легко проверять.
ABAC: политики по атрибутам субъекта/ресурса/контекста (регион, тенант, смена, устройство, риск-скоринг).
ReBAC (relationship-based): права следуют из связей (владелец проекта, член команды).
Гибрид: RBAC для базовой матрицы, ABAC для контекстных ограничений, ReBAC для владения.

4) Минимально необходимый доступ (Least Privilege)

Старт — минимальные роли-по-умолчанию (read-only, без PII).
Повышение — только через заявку с обоснованием, сроком и владельцем.
Лимит времени (TTL): права «тают» автоматически; продление — осознанно.
Контекстные гвард-рейлы: регион/тенант, часы работы, устройство, гео.

5) Разделение обязанностей (SoD)

• «Заводит лимиты» ≠ «утверждает лимиты».
• «Готовит выплату» ≠ «подписывает выплату».
• «Пишет код» ≠ «релизит в prod».
• «Админ БД» ≠ «читает PII в аналитике».
• Реализуйте SoD в политиках и в самих процессах (двухподпись, M-of-N).

6) JML-процессы (Joiner/Mover/Leaver)

Joiner: авто-назначение базовых ролей по должности/команде/региону, чек-лист доступов за 24ч.
Mover: пересмотр ролей при смене команды/проекта; автоматическое снятие «старых» прав.
Leaver: отзыв сессий, ключей, токенов; перевыпуск секретов, transfer владений артефактами.

7) Временные привилегии: JIT / PAM

Just-In-Time (JIT): поднятие прав по заявке на 15–240 минут с MFA и обоснованием тикетом.
PAM (Privileged Access Management): прокси/вход «под учеткой-оболочкой», запись сессий, командный журнал.
Break-glass: аварийный доступ с мгновенным алертом, коротким TTL и обязательным пост-мортемом.

8) Идентичности сервисов и ключи

Service Accounts: отдельные для каждого сервиса и среды, никаких shared-секретов.
Workload Identity: привязка токенов к поду/виру/функции; краткоживущие креды.
Секреты: KMS/Vault, ротация, двуконтурное шифрование, запрет попадания в логи.
Ключи подписей/выплат: threshold/MPC, аппаратные HSM, разнесение по доменам доверия.

9) SSO/MFA/SCIM и жизненный цикл аккаунтов

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

10) Политики-как-код и верификация

OPA/Authorization service: политики в виде кода (Rego/JSON), ревью через PR, тесты.
Дрифт-контроль: регулярные сравнения «задекларировано vs фактически».
Pre-flight проверки: «разрешит ли политика такую операцию?» — тестируйте кейсы до релиза.

11) Доступ к данным

Классификация: паблик / внутр / ограниченный / PII/финансы.
Давление «минимума»: агрегаты/маски вместо «сырых» данных; запросы PII — только через утвержденные джобы.
Tokenization/DE-ID: замена идентификаторов, аудит запросов.
Слои: прод → реплики → витрины → агрегаты; прямой доступ в прод-БД — только JIT/PAM.

12) Облако, K8s, сети

Cloud IAM: роли per-аккаунт/проект; запрет «Admin» по умолчанию; ограничение действий по тэгам/папкам.
Kubernetes: RBAC по неймспейсам, PSP/подобные политики без «privileged», образ-allowlist, секреты через CSI, сервисные аккаунты per-под.
Сеть: Zero-Trust (mTLS, identity-aware), доступ к jump-host — только JIT, запись SSH-сессий.

13) Внешние партнеры и интеграции

Изолированные тенанты/ключи, минимум скоупов OAuth2, короткие TTL токенов.
Вебхуки: подпись (HMAC/EdDSA), `nonce + timestamp`, узкое окно приема.
Ротация ключей по расписанию, отзыв при компрометации, статус-эндпоинты для «health».

14) Аудит, рецертификация, отчетность

Immutability: WORM-журналы, подписи релизов политик, Merkle-срезы.
Рецертификация: ежеквартальная проверка критичных ролей, ежемесячно — админ-прав.
Карантин прав: «неиспользуемые 60 дней» → авто-снятие.
Evidence pack: выгрузки матрицы ролей, SoD-срабатываний, JIT-заявок, запись PAM-сессий.

15) Метрики и SLO

TTG (Time-to-Grant): медиана выдачи доступа по стандартной заявке (цель ≤ 4ч).
Доля JIT-доступов среди «привилегированных» (цель ≥ 80%).
SoD-violations: 0 в prod, время устранения ≤ 24ч.
Орфанные права: % пользователей с избыточными правами (цель → 0.0x%).
Ротация секретов: средний возраст секрета (цель ≤ 30 дней для чувствительных).
Аудит-покрытие: 100% привилегированных действий с артефактами (записи, квитанции).

16) Дашборды

Access Health: активные роли, орфанные права, JIT vs постоянные.
PAM & Sessions: число привилегированных сессий, длительность, успешность MFA.
SoD & Incidents: статистика блокировок, причины, MTTR.
Secrets & Keys: возраст, предстоящая ротация, «красные» ключи.
JML: SLA онбординга/оффбординга, просроченные заявки.
Audit Evidence: статус ежеквартальной рецертификации, completeness 100%.

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

Компрометация токена/ключа: немедленный отзыв, глобальный поиск использования, ротация зависимостей, ретро-аудит за N дней.
Нарушение SoD: блок операции, временное отключение роли, пост-мортем и изменение политики.
Неавторизованный доступ к PII: изоляция, уведомление DPO, инвентаризация утечки, юридические процедуры.
Escalation abuse: заморозка JIT для субъекта/команды, анализ заявок/обоснований, корректировка лимитов TTL.

18) Операционные практики

Четыре глаза на выдачу/изменение критичных прав.
Каталог ролей с описанием задач, рисков и допустимых операций.
Тестовые окружения с анонимизированными данными и иными ролями.
Policy dry-run: симуляция последствий изменений перед применением.
GameDays по доступам: «потеря IdP», «отказ PAM», «утечка секрета».

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

• Сформировать таксономию ролей и матрицу SoD по ключевым процессам.
• Включить SSO+MFA для всех, SCIM-потоки для JML.
• Развернуть PAM/JIT, настроить break-glass с алертами и коротким TTL.
• Ввести политики-как-код (OPA), ревизии через PR и автотесты.
• Отдельные сервис-аккаунты и workload-identity; запрет shared-секретов.
• Vault/KMS, регулярная ротация секретов и ключей, запрет секретов в коде/логах.
• Разделить среды и регионы, закрепить правила кросс-региональных доступов.
• Запустить дашборды и SLO, ежемесячные отчеты по рецертификации.
• Провести SoD-скан графа прав и устранить пути эскалации.
• Регулярные учения и пост-мортемы с action items.

20) FAQ

RBAC или ABAC?
RBAC — базовый слой читаемости, ABAC — контекст и динамика. Используйте гибрид.

Нужен ли PAM, если есть JIT?
Да: PAM дает запись сессий и управляемые каналы привилегированного доступа.

Как уменьшить «залипание» прав?
TTL на роли, авто-снятие неиспользуемых, ежемесячная рецертификация и SoD-алерты.

Что делать с внешними подрядчиками?
Выделенные тенанты/группы, ограниченные скоупы, короткие TTL, обязательные отчеты и рецертификация.

Резюме: Ролевое делегирование и доступы — это не «набор галочек», а жизненный цикл прав: минимально необходимые роли, SoD, JIT/PAM, политики-как-код, наблюдаемость и регулярная рецертификация. Такой контур дает быструю работу командам и предсказуемую безопасность для бизнеса и аудита.