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

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-данные нe копируются в stage/dev; используются синтетические или псевдонимизированные наборы.

• Edge/WAF/CDN → App-зона → Data-зона (DWH/DB) → Secrets/KMS.
• Платежный периметр (PSP/карты) изолирован от общего prod; KYC/санкции — отдельный сегмент.
• 6.3 Логическая сегментация: пространства имен (K8s), tenant-IDs, схемы БД/каталога данных, отдельные ключи шифрования per tenant/регион.
• 6.4 Гео-сегментация: хранение/обработка согласно локации (ЕС/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: доступ к KYC/санкциям — только для обученных ролей, журнал решений.
PCI DSS (если применимо): сегрегация платежной зоны, запрет хранения PAN/CSC, отдельные ключи/хостинг.
ISO/ISMS: формализованные политики доступа, ежегодные аудиты и тесты.

13) РACI

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 и внутренних стандартов.