Контроль доступу до операцій
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, сегментація, брокери БД), управлінських процесів (каталог ролей, заявки/апруви, ресертифікація) і аудиту, що перевіряється. Такий контур робить інфраструктуру і бізнес-операції стійкими, знижує ймовірність зловживань і прискорює реагування на інциденти - з доказовою відповідністю вимогам регуляторів і партнерів.