Политики доступа

Политики доступа к данным: кто и при каких условиях может читать или изменять данные в платформе.

Принципы

Минимальные привилегии: доступ только к тем данным и операциям, которые нужны для роли или задачи.
По идентитету: доступ привязан к аутентифицированному субъекту (user_id, service account); проверка на каждом чувствительном запросе.
Разделение по контурам: операционные БД сервисов недоступны напрямую извне; доступ только через API сервиса с проверкой прав; аналитические данные (DWH, витрины) — отдельные роли и политики.

API Gateway проверяет JWT и передаёт контекст (user_id, roles) во backend; сервисы проверяют право на операцию (например, пользователь может менять только свой профиль или ресурсы своей организации).
Внутренние вызовы (gRPC): в доверенной сети; контекст пользователя передаётся в метаданных; сервис не должен доверять произвольному caller без контекста от Gateway.
Прямой доступ к БД: только из соответствующего сервиса; нет кросс-сервисного доступа к чужим БД; учётные данные БД — в Vault, не в общем доступе.
Детали модели прав: Authorization, Security requirements.

Доступ по ролям: аналитики, продукт, SRE — только к тем витринам и полям, которые нужны для работы; PII при необходимости маскируются или ограничиваются.
Аудит-логи и сырые логи с персональными данными — ограниченный круг лиц (security, compliance); доступ логируется.
Retention и право на удаление/экспорт согласованы с Retention policies и Privacy.

Vault: доступ по политикам Vault (роли, привязка к K8s service account); приложение получает только те секреты, которые ему разрешены.
Kubernetes Secrets: синхронизация из Vault через External Secrets; права на чтение — только у подов нужных сервисов.
Не хранить секреты в коде, в открытых конфигах и в логах; см. Secrets Management.

На странице