Сегментация привилегий

1) Зачем нужна сегментация

Сегментация привилегий — ключ к снижению “blast radius” ошибок и инсайдерских злоупотреблений. Она позволяет точно ограничивать, кто и где может выполнять какие действия с какими данными, при этом сохранять скорость операций и соответствие требованиям регуляторов.

• меньше инцидентов из-за “лишних прав”;
• ускорение расследований: доступы прозрачны и объяснимы;
• соответствие SoD/комплаенс, доказуемый аудит;
• безопасные эксперименты и быстрые релизы без риска для прод-ядра.

2) Принципы

Zero Trust: каждое действие проверяется контекстно; нет “доверенных зон”.
Least Privilege: минимальные права, выданные на минимальный срок (в идеале — JIT).
Context over Role: права зависят не только от роли, но и от атрибутов (тенант, регион, окружение, риск).
Segregation of Duties (SoD): разделяем инициирование, одобрение, исполнение и аудит.
Policy-as-Code: политики в коде с версионированием, тестами и ревью.

3) Модель зрелости доступа

1. RBAC (roles): старт — фиксированные роли (Support, Risk, Payments, Trading, Ops, SRE, Compliance).
2. ABAC (attributes): добавляем атрибуты: тенант, регион, юрисдикция, продукт, канал, окружение (prod/stage/dev), время, риск-класс операции, KRI-сигналы.
3. PBAC (policy-based): централизованные политики “кто/что/где/когда/зачем” + условия (например, “в проде — только по JIT и с тикетом”).

4) Домены сегментации (ось за осью)

4.1 Тенант/клиент

Доступ и операции ограничены конкретным брендом/оператором/аффилиатом.
Кросс-тенантные действия запрещены, кроме строго определенных агрегаций без PII.

4.2 Регион/юрисдикция

Политики учитывают местные лицензионные и KYC/AML-правила.
Операции с данными игрока ограничены географией хранения и обработки.

4.3 Окружение (dev/stage/prod)

Prod изолирован: отдельные креды, сети, Bastion/PAM, “read-only по умолчанию”.
Доступ в prod только JIT, с тикетом и окнами изменений.

4.4 Класс данных

PII/финансы/игровая телеметрия/техлоги — разные уровни доступа и маскирования.
Экспорт PII — только через утвержденные воркфлоу с шифрованием и TTL.

4.5 Критичность операций

Классы P1/P2/P3: публикация коэффициентов, ручные зачеты, выводы, смена PSP-роутинга — требуют dual control.
Низкорисковые операции могут быть авто-апрувнуты политикой.

5) Уровни привилегий (tiers)

Viewer: только чтение агрегатов и маскированных данных.
Operator: выполнение процедур по ранбукам без изменения конфигураций.
Contributor: изменение конфигураций в не-критичных доменах.
Approver: одобрение заявок и high-risk операций (не совмещается с исполнением — SoD).
Admin (JIT): краткосрочное повышение для редких задач под dual control и запись сессии.

6) SoD и несовместимые роли

• Инициировать выводы ≠ одобрять ≠ финально проводить.
• Создавать бонусную кампанию ≠ активировать в проде ≠ менять лимиты.
• Разрабатывать фичу ≠ аппрувить релиз ≠ выкат в прод.
• Запрашивать выгрузку PII ≠ одобрять ≠ расшифровывать.

Для каждой пары — формализованная политика запрета и исключения с датой пересмотра.

7) JIT-доступ и PAM

Elevation по запросу: указывается цель/тикет/срок; после истечения — авто-отзыв.
Dual control: P1/P2 действия — два аппрувера из разных функций.
Session control: запись критичных сессий, алерты аномалий, запрет копипасты при работе с PII.
Break-glass: аварийный доступ с жесткими лимитами и обязательным пост-аудитом.

8) Сервисные аккаунты и API-скоупы

Минимальные скоупы; разделение по задачам/микросервисам; краткоживущие токены/сертификаты.
Ротация секретов, запрет shared-секретов; запрет “god-scope”.
Лимиты на rate/quotas, idempotency-ключи, подпись вебхуков (HMAC).

9) Сегментация на уровне инфраструктуры

Сети: изоляция сегментов (per-domain/per-tenant), запрет egress по умолчанию, mTLS.
Kubernetes/Cloud: неймспейсы/проекты per-окружение и домен, Gatekeeper/OPA для запрета опасных шаблонов.
БД/Кэши: брокер доступа (DB proxy/IAM), read-only по умолчанию, запрет DDL в проде вне окна.
Хранилища: разные ключи/бакеты per-класс данных с политиками TTL и WORM для аудита.

10) Политики как код (PaC)

Политики в репозиториях (Rego/YAML), PR-ревью, авто-тесты (unit/e2e), дифф-аудит.
Динамический контекст: время суток, локация, уровень KRI, риск-скоринг операции.
Объяснимость решения allow/deny и ссылка на политику в аудите.

11) Журналы и аудит

Полнота: кто/что/где/когда/зачем, пред/пост-значения, ID тикета.
Неподменяемость: централизованный сбор, WORM/immutable, подпись записей.
Связность: цепочка из админ-консоли → API → БД → внешние провайдеры.
SLA аудита: скорость ответа на запросы контроля/регулятора.

12) Дашборды и метрики (KPI/KRI)

KPI доступа: доля JIT vs постоянных прав, средняя длительность привилегии, % покрытых SoD, время обработки заявок, покрытие ресертификаций.
KRI злоупотреблений: всплески чувствительных операций, массовые выгрузки, нетипичные локации/часы, последовательности “заявка→действие→откат”.
Exec-дашборд: трек статуса высокорисковых ролей, break-glass события, тренды.

13) Примеры политик (эскизы)

Prod-операции: `allow if role in {Operator, Admin} AND env=prod AND jit=true AND ticket!=null AND sod_ok AND time in ChangeWindow`.
Экспорт PII: `allow if data_class=PII AND purpose in ApprovedPurposes AND ttl<=7d AND encryption=ON AND approvers>=2`.
PSP-роутинг: `allow if action=UpdateRouting AND dual_control AND risk_assessment_passed AND rollback_plan_attached`.

14) Дорожная карта внедрения (8–12 недель)

Нед. 1–2: инвентаризация операций/ролей/данных, матрица SoD, классификация данных и домены сегментации.
Нед. 3–4: RBAC-базис, каталог ролей, JIT для прод-консолей, старт PaC (OPA/Gatekeeper).
Нед. 5–6: ABAC: атрибуты тенант/регион/окружение/класс данных; разделение неймспейсов/проектов.
Нед. 7–8: PAM (JIT-elevation, запись сессий, break-glass), запрет DDL и брокер БД, политики экспорта PII.
Нед. 9–10: PBAC для высокорисковых операций (выводы, бонусы, PSP), dual control, KRI-алерты.
Нед. 11–12: квартальная ресертификация, покрытие 100% high-risk операций PaC, отчетность и обучение.

15) Артефакты

Role Catalog: роли, минимальные привилегии, владельцы.
SoD Matrix: несовместимые роли/операции, исключения, процесс override.
Policy Pack: набор PaC-политик с тестами и примерами deny/allow.
Access Request Form: цель, срок, объект (тенант/регион/окружение), риск-оценка, аппруверы.
Sensitive Ops Register: перечень P1/P2 действий, окна, критерии dual control.
Audit Playbook: сбор и предоставление журналов, SLA ответа, роли.

16) Антипаттерны

Постоянные админ-права и общие учетки.
Кросс-тенантные доступы “для удобства”.
Отсутствие изоляции prod/stage/dev.
Политики на бумаге без enforce в коде/консолях.
Экспорт PII по ручной договоренности без шифрования и TTL.
Отсутствие ресертификаций и “зависшие” права.

17) Итог

Сегментация привилегий — это не просто “правильные роли”. Это многомерная изоляция (тенант, регион, окружение, данные, критичность) + динамический контекст (ABAC/PBAC) + процессы (SoD, JIT, ресертификация) + техническое принуждение (PaC, PAM, сети/БД). Такой контур резко снижает риск ошибок и злоупотреблений, ускоряет безопасные изменения и делает платформу устойчивой к требованиям масштаба и регуляторов.