GH GambleHub

Аудит ідентифікацій

1) Мета і результат

Мета: забезпечити доказову відповідність принципам Zero Trust і найменших привілеїв через регулярну перевірку того, хто має які доступи де і чому.
Результат: повний та актуальний реєстр ідентичностей та прав з підтвердженими власниками, усуненими «завислими» доступами, оформленою доказовою базою для внутрішнього контролю та регуляторів.

2) Область охоплення

Внутрішні користувачі: штат, стажисти, керівники, тимчасові ролі.
Підрядники/партнери: студії ігор, PSP/KYC/AML-провайдери, афіліати.
Сервісні ідентичності: боти, CI/CD, інтеграції, ключі та токени API.
Привілейовані ролі: адміни інфраструктури/БД, Payments, Risk, Trading.
Гравці (у контексті KYC): коректність зв'язки облікового запису ↔ KYC-профіль ↔ статуси RG/AML (перевірка процесів, не вмісту документів).

3) Терміни та принципи

Identity (ідентичність): унікальний суб'єкт (людина/сервіс) з атрибутами.
Entitlement (привілей): конкретне право/роль на ресурс.
JML: Joiner → Mover → Leaver - життєвий цикл ідентичності.
SoD: поділ обов'язків для високоризикових операцій.
Least Privilege & Just-in-Time (JIT): мінімальний набір прав, виданий на обмежений час.
Accountability: у кожної ідентичності є власник, у кожного права - бізнес-обгрунтування і термін.

4) Джерела істини та модель даних

HRIS/кадрова система: первинне джерело статусу співробітника (hire/move/exit).
IdP/SSO: єдина точка аутентифікації (MFA/FIDO2), федерація.
IAM/IGA: каталог ролей, політик і процесів ресертифікації.
CMDB/каталог сервісів: володіння системами та контурами доступу.
Платформи провайдерів: PSP/KYC/CDN/WAF/провайдери ігор - зовнішні портали доступу.
Модель: Identity → (belongs to) → Org Unit/Team → (has) → Roles → (expand via ABAC) → Entitlements → (apply) → Resources.

5) Контролі, які перевіряє аудит

1. SSO і MFA повсюдно (без локальних обліків і shared-акаунтів).
2. RBAC/ABAC/PBAC: права описані політиками (policy-as-code), ролі - типові та узгоджені.
3. SoD: формалізовано несумісні ролі та винятки.
4. JIT/PAM: тимчасові підвищення з тікетом, записом сесії і авто-відкликанням.
5. Секрети/ключі: зберігаються в менеджері секретів, з ротацією і термінами життя.
6. Журнали та доказовість: tamper-evident, зв'язне трасування хто/що/де/коли/навіщо.
7. Data Access: маскування PII, експорт - тільки по workflow з шифруванням і TTL.

6) Процес аудиту (end-to-end)

1. Підготовка: заморожування знімка прав (entitlements snapshot) за системами; вивантаження з IdP/IAM/провайдерів.
2. Нормалізація: мепінг ролей до каталогу, дедуплікація, угруповання за власниками ресурсів.
3. Категоризація ризику: P1/P2 (привілейовані та чутливі) → пріоритетна перевірка.
4. Ресертифікація прав: власники систем підтверджують/відхиляють права (кампанії access review).
5. Перевірка SoD: виявлення несумісностей і тимчасових винятків (з датою закінчення).
6. JML-звірка: зіставлення hire/move/exit з фактичними правами (в т.ч. зовнішні портали).
7. Сервісні обліки: наявність власника, токени короткоживучі, немає «god-scope».
8. Доказова база: формування пакету артефактів (звіти, вивантаження, акти).
9. Remediation-план: тікети на відгук/виправлення, терміни та відповідальні.
10. Фінальний звіт: статус ризиків, KPI циклу, уроки і поліпшення політик.

7) JML-контури (що перевіряємо глибше)

Joiner: автоматичне призначення базових ролей, заборона ручних «добавок» поза каталогом.
Mover: зміна команди/локації → автоматична заміна ролей, відкликання старих привілеїв.
Leaver: відкликання всіх прав протягом X хвилин/годин, закриття пошти/VPN/порталів провайдерів, відключення ключів і токенів.

8) Зовнішні залежності та портали

PSP/KYC/AML/CDN/WAF/ігрові провайдери: у кожної обліки - власник, мета, термін, MFA, заборона загальних акаунтів.
Контрактні SoD/SLA: наявність dual-control для операцій P1 (зміна роутингу платежів, лімітів бонусів тощо).
Регулярна звірка: реєстр зовнішніх порталів ↔ список актуальних користувачів ↔ результати ресертифікацій.

9) Особливості iGaming-домену

Payments & Risk: окремі гілки SoD; апруви на зміни лімітів/роутингу; аудит ручних коригувань.
Trading/коефіцієнти: пісочниці для моделювання, окремі ролі публікації, швидкий відкат; журнал змін.
Responsible Gaming/KYC/PII: жорсткий контроль експорту, маскування в BI, SLA обробки запитів регулятора.
Афіліати і стримери: обмежені портали з можливостями звітності без доступу до PII.

10) Політики як код (PaC)

Політики в репозиторії (Rego/YAML), PR-рев'ю, тести.
Динамічний контекст у рішеннях allow/deny: оточення (prod), час, локація, критичність операції, сигнали KRI (наприклад, сплеск чутливих дій).
Обов'язкова прив'язка до тікету і мети при JIT-підвищеннях.

11) Журнали і доказовість

Ланцюжок подій: адмін-консоль/IdP → API → БД → зовнішні провайдери.
Tamper-evident: WORM/immutable-сховища, підпис записів, строгі TTL.
Пошук і відповідь: SLA відповіді на внутрішні/зовнішні запити (аудит, регулятор, банк/партнер).

12) Метрики та KPI/KRI

KPI:
  • Частка підтверджених прав у строк (ресертифікація),% прострочених кампаній.
  • Час від звільнення до повного відкликання прав (MTTR-leaver).
  • Частка JIT-підвищень vs постійних привілеїв.
  • Кількість усунутих SoD-конфліктів за цикл.
  • Повнота покритих систем і зовнішніх порталів.
KRI:
  • Спайки чутливих дій (експорт PII, зміни PSP).
  • Невикористовувані права> N днів.
  • Break-glass без пост-аудиту.
  • Акаунти без власника/мети/терміну.

13) Дорожня карта впровадження (8-12 тижнів)

Нед. 1–2: інвентаризація ідентичностей і систем (включаючи зовнішні портали), каталог ролей і SoD-матриця.
Нед. 3–4: підключення SSO/MFA повсюдно, єдиний збір entitlements, перші snapshot-звіти.
Нед. 5–6: запуск IGA-кампаній ресертифікації (P1/P2 пріоритет), автоматичний відгук по Leaver.
Нед. 7–8: JIT/PAM для прод-контурів, запис сесій, заборона shared-акаунтів у провайдерів.
Нед. 9–10: PaC: формалізація ключових політик (експорт PII, PSP-роутинг, релізи), unit-тести політик.
Нед. 11–12: дашборди KPI/KRI, регламент квартальних циклів, звітність для комплаєнсу/регуляторів.

14) Шаблони артефактів

Role Catalog: роль, опис, мінімальні привілеї, власник, застосовність (тенант/регіон/оточення).
SoD Matrix: несумісні ролі/операції, винятки, термін і власник винятку.
Access Review Pack: лист підтвердження прав, коментарі, результат (approve/revoke/mitigate).
Service Account Register: мета, власник, термін життя, скоупи, місце зберігання секретів, розклад ротації.
External Portals Inventory: система, контакти, список користувачів, MFA, дата останньої ресертифікації.
Evidence Checklist: які вивантаження/логи і в якому форматі зберігати для аудиту.

15) Антипатерни

Загальні обліки і «адмін назавжди».
Ручні видачі прав в обхід IdP/IGA.
Відсутність SoD або допуск «тимчасових винятків» без дати закінчення.
Сервісні токени без ротації/власника.
Експорт PII «по листу» без workflow і шифрування.
Немає аудиту зовнішніх порталів (PSP/KYC/провайдери ігор).

16) Часті знахідки аудиту і швидка поправка

Завислі доступи у звільнених/підрядників: включити авто-відгук по подіям HR (Leaver).
Ролі з надмірними правами: декомпозувати в більш дрібні і прив'язати ABAC-атрибути.
Shared-акаунти у провайдерів: міграція на персональні + MFA, видача тимчасових ролей для рідкісних завдань.
Довгоживучі секрети: перехід на короткоживучі токени/сертифікати і планову ротацію.

17) Інцидент-менеджмент зв'язка

Будь-який інцидент з компонентом доступу → обов'язкове оновлення реєстру ризиків і політик, точкова ресертифікація порушених ролей, пост-мортем з action items (і термінами).

Підсумок

Аудит ідентифікацій - це повторюваний, автоматизований цикл: повний реєстр ідентичностей і прав → ризик-орієнтована ресертифікація → жорсткий JML і JIT/PAM → політики як код і доказовий аудит → поліпшення за результатами циклу. Такий контур знижує ймовірність зловживань і помилок, прискорює розслідування, зміцнює відповідність вимогам і захищає ключові бізнес-операції iGaming-платформи.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.