Політики доступу та сегментація

1) Мета і принципи

Мета: мінімізувати ризик витоків/шахрайства та регуляторні наслідки через суворий контроль «хто, до чого і навіщо має доступ», з доказовістю для аудиту.
Принципи: Least Privilege (мінімум прав), Need-to-Know, Zero Trust, Segregation of Duties (SoD), Just-in-Time (JIT), простежуваність і відгуковість доступу в один клік.

2) Класифікація даних та рівні захисту

3) Модель доступу: RBAC + ABAC

RBAC (ролі): базова матриця «роль → дозволу».
ABAC (атрибути): контекстні правила (юрисдикція гравця/оператора, сегмент середовища, чутливість набору, зміна/час, пристрій, рівень перевірки KYC, службове завдання/purpose).

• Marketing-аналітик може читати таблиці'events _'тільки для країн, де є згода на аналітику, тільки в будні 08:00–21:00, тільки з корпоративної мережі/MDM-пристрою, без полів PII (маскування включено).

4) SoD - поділ обов'язків (антифрод і комплаєнс)

5) JIT, break-glass и PAM

JIT (Just-in-Time): підвищені права видаються на обмежений інтервал (15-120 хв) під конкретну задачу і автоматично відкликаються.
Break-glass: аварійний доступ через окрему процедуру (MFA + друге підтвердження + обов'язкове зазначення purpose), повний запис сесії і пост-фактум рев'ю.
PAM: для адмін-акаунтів - парольні сховища, поведінкова аналітика, ротація ключів/секретів, сесійний проксі із записом.

6) Сегментація: Середня, мережева та логічна

6. 1 Середовища: `prod` ≠ `stage` ≠ `dev`. Prod-дані не копіюються в stage/dev; використовуються синтетичні або псевдонімізовані набори.

• Edge/WAF/CDN → App-зона → Data-зона (DWH/DB) → Secrets/KMS.
• Платіжний периметр (PSP/картки) ізольований від загального prod; КУС/санкції - окремий сегмент.
• 6. 3 Логічна сегментація: простору імен (K8s), tenant-IDs, схеми БД/каталогу даних, окремі ключі шифрування per tenant/регіон.
• 6. 4 Гео-сегментація: зберігання/обробка згідно локації (EC/UK/...); маршрутизація гуїдів і ключів по регіону.

7) Доступ вендорів і партнерів

Механіка: окремі B2B-тенанти/облікові записи, мінімальний API-скоуп, mTLS, allow-list IP, час-вікна.
Договори: DPA/SLA (журнали, терміни зберігання, географія, інциденти, субпроцесори).
Оффбординг: відкликання ключів, підтвердження видалення, акт закриття.
Моніторинг: алерти на аномальні обсяги, заборона масових експортів.

8) Процеси (SOP)

8. 1 Запит/зміна доступу

1. Заявка в IDM/ITSM з purpose і терміном.
2. Автоперевірка SoD/юрисдикції/класу даних.
3. Схвалення власником домену + Security/Compliance (якщо Restricted +).
4. Видача JIT/постійного доступу (мінімальний набір).
5. Журналювання: хто/коли/що видано; дата перегляду.

8. 2 Періодичний перегляд (recertification)

Щоквартально: власники підтверджують права груп; автоотзыв невикористовуваних прав (> 30/60 днів).

8. 3 Експорт даних

Тільки через схвалені пайплайни/вітрини, за білими списками форматів (CSV/Parquet/JSON), маскування за замовчуванням, підпис/хеш, журнал вивантажень.

9) Політика пристроїв і контекст

MDM/EMM: доступ до Restricted/Highly Restricted тільки з керованих пристроїв.
Контекстні сигнали: гео, ризик-скор пристрої, час доби, стан MFA, репутація IP - як атрибути ABAC.
Браузерні розширення/захоплення екрану: контроль і журнал, заборона для чутливих консолей.

10) Приклади політик (фрагменти)

10. 1 YAML (псевдо) - ABAC для аналітика маркетингу

yaml policy: read_analytics_no_pii subject: role:marketing_analyst resource: dataset:events_
condition:
consent: analytics == true data_class: not in [Restricted, HighlyRestricted]
network: in [corp_vpn, office_mdm]
time: between 08:00-21:00 workdays effect: allow masking: default logging: audit_access + fields_scope

10. 2 SQL-маскування (ідея)

sql
SELECT user_id_hash,
CASE WHEN has_priv('pii_read') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

11) Моніторинг, журнали та алерти

Audit trails: `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `BREAK_GLASS`, `PAYMENT_APPROVE`.
KRIs: доступи без'purpose'= 0; спроби до Highly Restricted поза вікном; частка провалених SoD-перевірок; аномальні вивантаження.
KPI: % запитів з JIT ≥ 80%; середній час видачі доступу ≤ 4 год; покриття ре-сертифікацією 100%.
SOAR-плейбуки: авто-відкликання при погрозах, тікети на розслідування.

12) Відповідність вимогам (коротка карта)

GDPR/UK GDPR: мінімізація, Need-to-Know, DSAR-сумісність, аудит PII.
AML/KYC: доступ до КУС/санкцій - тільки для навчених ролей, журнал рішень.
PCI DSS (якщо застосовується): сегрегація платіжної зони, заборона зберігання PAN/CSC, окремі ключі/хостинг.
ISO/ISMS: формалізовані політики доступу, щорічні аудити та тести.

13) PACI

14) Метрики зрілості

Покриття ABAC-правилами критичних наборів даних ≥ 95%.
JIT-сесії/всі підвищення прав ≥ 90%.
Час відкликання доступу по offboarding ≤ 15 хв.
0 інцидентів «роль ≠ функція» (SoD).
100% журналів доступів доступні і верифіковані (підпис/хеш).

15) Чек-листи

15. 1 Перед видачею доступу

• Визначено purpose, термін і власник даних
• Перевірка SoD/юрисдикцій пройдена
• Мінімальний скоуп/маскування включені
• MFA/MDM/мережеві умови дотримані
• Журналювання та дата перегляду налаштовані

15. 2 Щоквартальний огляд

• Звірка груп і ролей з оргструктурою
• Автовідгук «висять» прав
• Перевірка аномальних експортів і break-glass
• Навчання та тест-алерти

16) Типові сценарії та заходи

A) Нова роль «VIP-менеджер»

Доступ до профілів VIP (масковано), заборона експортів, JIT на разовий перегляд KYC через тікет.

B) Вендор-аудит BI

read-only до вітрин без PII, тимчасовий VPN + allow-list, заборона збереження локально, журнал вивантажень.

C) Екстрений доступ DevOps до prod-БД

break-glass ≤ 30 хв, запис сесії, пост-рев'ю з DPO/Compliance, CAPA при порушеннях.

17) Дорожня карта впровадження

Тижні 1-2: інвентаризація даних/систем, класи даних, базова RBAC-матриця, SoD.
Тижні 3-4: впровадити ABAC (перші атрибути: середовище, гео, клас даних), IDM-потоки, JIT/break-glass, PAM.
Місяць 2: сегментація платіжного і KYC-периметра, окремі ключі/KMS, журнали експортів, SOAR-альберти.
Місяць 3 +: квартальні ре-сертифікації, розширення атрибутів (пристрій/ризик), автоматизація маскування, регулярні навчання.

TL; DR

Надійна модель доступу = класифікація даних → RBAC + ABAC → SoD + JIT/PAM → жорстка сегментація → журнали та алерти. Це знижує ймовірність витоків і зловживань, прискорює аудит і тримає платформу в межах GDPR/AML/PCI і внутрішніх стандартів.