Контроль доступа к операциям
1) Зачем это нужно
Контроль доступа к операциям предотвращает финансовые потери, злоупотребления и регуляторные нарушения. Он ограничивает “blast radius” ошибок и инсайдерских угроз, ускоряет расследования и делает изменения трассируемыми. Для iGaming это критично в доменах платежей, противодействия фроду, бонусных программ и управления контентом игр/коэффициентами.
2) Базовые принципы
Zero Trust: не доверяй по умолчанию; проверяй каждое действие.
Least Privilege: минимально необходимые права на ограниченное время.
Need-to-know: доступ к данным/функциям только по обоснованной цели.
Segregation of Duties (SoD): разделение ролей “запрос → одобрение → выполнение → аудит”.
Accountability: каждое действие — на именованного субъекта с персональной/делегированной ответственностью.
Composability: доступ формируется политиками, которые можно проверять и версионировать как код.
3) Модель управления доступом
3.1 Ролевые и атрибутивные модели
RBAC: базовые роли по функциям (Support, Risk, Payments, Trading, Ops, Dev, SRE, Compliance).
ABAC: атрибуты тенант/регион/юрисдикция/канал/продукт/окружение (prod/stage/dev).
PBAC/Policy-as-Code: правила в OPA/Rego или аналогах: кто/что/где/когда/зачем + контекст (KRI, время, уровень риска операции).
3.2 Матрица SoD (пример)
Платежи/выводы: инициировать ≠ одобрять ≠ проводить.
Бонусы: создавать кампанию ≠ активировать на проде ≠ изменять лимиты.
Коэффициенты/линия: моделирование ≠ публикация ≠ откат.
Данные/PII: запрос выгрузки ≠ одобрение ≠ доступ к расшифровке.
Релизы: разработчик ≠ аппрувер релиза ≠ оператор выката.
4) Контур идентификации и федерации
SSO/MFA: единая точка входа с обязательной MFA, поддержка FIDO2.
Just-In-Time (JIT) Provisioning: выдача ролей при входе по атрибутам и группе риска.
SCIM/HR-driven: автоматическое назначение/отзыв прав по событиям HR (hire/move/exit).
Сервисные аккаунты: краткоживущие токены/сертификаты, ротация секретов, ограниченные scope.
5) Привилегированный доступ (PAM)
JIT-elevation: временное повышение привилегий с указанием причины и тикета.
Dual control (4-eyes): для высокорисковых операций (P1/P2) требуется два аппрувера из разных функций.
Session control: запись/кейлог критичных сессий, алерты аномалий, запрет копипасты/файлообмена при необходимости.
Break-glass: аварийный доступ с жесткими лимитами, обязательным пост-аудитом и автоматическим отзывом.
6) Контроль доступа к данным
Классификация: PII/финансовые/технические/общедоступные.
Data masking: маскирование по ролям, токенизация идентификаторов.
Пути доступа: аналитика читает агрегаты; доступ к сырым PII — только через утвержденные воркфлоу с целевым окном времени.
Экспорт/линьяж: все выгрузки подписаны запросом/тикетом, хранятся в зашифрованном виде с TTL.
7) Контроль операций домена iGaming
Выводы средств: лимиты по сумме/часу/дню, 2-факторный аппрув, автоматические стоп-факторы (скоринг риска, velocity).
Бонусы/фриспины: cap на бюджет/тенанта, sandbox-прогоны, два уровня утверждения.
Коэффициенты/market-lines: промо-периоды требуют двойной проверки, журнал публикаций, быстрый откат.
KYC/AML: доступ к документам — по цели и тикету, запрет массовых скачиваний.
Платежные маршруты: изменение PSP-правил — только через change-management с review комиссий/конверсии.
Саппорт-действия: заморозка аккаунта, списание/начисление — только через шаблон-плейбук, с авто-созданием кейса.
8) Инфраструктурный доступ
Сегментация окружений: prod изолирован; доступ в prod — через bastion с короткими сертификатами SSH/MTLS.
Kubernetes/Cloud: политики на неймспейсы/нейтворк, запрещенный egress по умолчанию, PodSecurityPolicies/OPA Gatekeeper.
БД/кэши: брокеры доступа (DB proxy, IAM-на-уровне-запроса), “read-only по умолчанию”, запрет DDL в проде без окна изменений.
Секреты: менеджер секретов, автоматическая ротация, запрет секретов в переменных окружения без шифрования.
9) Процессы заявок и апрувов
Каталог доступов: описания ролей, атрибутов, риск-класс операций, SLO рассмотрения.
Заявка: обоснование, срок, объект (тенант/регион/окружение), ожидаемый объем операций.
Апрув: line manager + data/ops owner; для высокорисковых — Compliance/Payments/Risk.
Ресертификация (Access Review): ежеквартально — владельцы подтверждают нужность прав; автоматическое отключение “зависших” доступов.
10) Политики как код (Policy-as-Code)
Централизация: OPA/Rego/вебхуки в CI/CD и админ-консолях.
Версионирование: PR-процессы, ревью и тесты политик, дифф-аудит.
Динамический контекст: время суток, KRI, гео, риск-скоринг игрока/операции.
Доказуемость: каждому решению allow/deny соответствует объяснимая политика и запись в аудите.
11) Журналы и аудит (tamper-evident)
Неподменяемость: централизованный сбор (WORM/immutable storage), подпись записей.
Полнота: кто, что, где, когда, зачем (ID тикета), пред-/пост-значения.
Связность: трейс операции через консоль → API → БД → внешние провайдеры.
SLA аудита: доступность журналов, время ответа на запрос контроля/регулятора.
12) Мониторинг и алертинг
KPI доступа: % JIT-доступов, среднее время жизни привилегии, доля break-glass, неиспользуемые права > N дней.
KRI злоупотреблений: спайки чувствительных действий, массовые выгрузки, нетипичные часы/локации, последовательности “заявка → действие → откат”.
Real-time алерты: для P1/P2 операций — в on-call и SecOps канал.
13) Тесты и контроль качества
Tabletop/пентест-стори: сценарии инсайдера, украденного токена, злоупотребления саппорт-ролями, намеренных ошибок конфигурации.
Chaos-access: принудительный отзыв прав во время активной смены, проверка устойчивости процессов.
DR тесты: отказ SSO/PAM, доступ по break-glass, восстановление нормального контура.
14) Дорожная карта внедрения (8–12 недель)
Нед. 1–2: инвентаризация операций/ролей/данных, риск-оценка и первичная матрица SoD.
Нед. 3–4: SSO/MFA повсеместно, каталог доступов, JIT для админ-консолей, базовые политики OPA.
Нед. 5–6: PAM: JIT-elevation, запись сессий, break-glass с пост-аудитом. Маскирование PII и workflow на выгрузки.
Нед. 7–8: сегментация prod/stage/dev, bastion-модель, брокер доступа к БД, запрет DDL.
Нед. 9–10: high-risk операции с dual control; алерты по KRI злоупотреблений; первые tabletop-учения.
Нед. 11–12: автопровижининг/SCIM, квартальные access-review, полная трассировка аудита и метрики эффективности.
15) Артефакты и шаблоны
Role Catalog: роль, описание, минимальные привилегии, атрибуты ABAC, владелец.
SoD Matrix: несовместимые роли/операции, исключения, процесс временного override.
Sensitive Ops Register: список действий P1/P2, критерии dual control, окна выполнения.
Access Request Form: цель, срок, объект, тикет, риск-оценка, аппруверы.
Policy Pack (PaC): набор Rego-политик с тестами и примерами deny/allow.
Audit Playbook: как собирать цепочку событий, SLA ответа, кто коммуницирует с регулятором.
16) KPI функции
% операций, покрытых SoD и dual control
Среднее время жизни повышенных привилегий (цель: часы, не дни)
Доля JIT- vs постоянных доступов
Время закрытия заявок и % авто-апрувов по low-risk шаблонам
Количество/частка инцидентов, где доступ был ключевым фактором
Полнота аудита (% событий с привязкой к тикету/причине)
17) Антипаттерны
“Админ навсегда” и общие учетки.
Доступ к прод-данным через BI/ад-hoc без маскировки и журнала.
Политики на бумаге без enforce в коде/консолях.
Break-glass без пост-мортема и автоматического отзыва.
Ручные выгрузки PII “по доброй воле”.
Смешение ролей саппорта и финансовых аппруверов.
Итог
Эффективный контроль доступа к операциям — это сочетание строгих принципов (Zero Trust, Least Privilege, SoD), технических средств (SSO/MFA, PAM, PaC, сегментация, брокеры БД), управленческих процессов (каталог ролей, заявки/апрувы, ресертификация) и проверяемого аудита. Такой контур делает инфраструктуру и бизнес-операции устойчивыми, снижает вероятность злоупотреблений и ускоряет реагирование на инциденты — с доказуемой соответствием требованиям регуляторов и партнеров.