Централизованный контроль прав в базах через Trino

Wildberries перевела управление доступом к данным на единую точку входа через Trino и Open Policy Agent. Это позволило уйти от ручной раздачи прав в десятках СУБД и получить сквозной аудит. Решение выросло из задачи одного отдела в кросс-департаментный процесс, где техническая часть тесно связана с организацией ответственности. Для инженеров важно понять, какие именно проблемы оно закрывает и какие ограничения остаются при переносе на собственный контур.

Исходные проблемы с доступом

Раньше доступ к базам выдавали сразу на всю СУБД, без ограничения схем и таблиц. Отзыв прав при увольнении зависел от ручной сверки списков между HR и разными командами, что создавало риски. Среднее время согласования заявки составляло четыре дня, а в сложных случаях доходило до семнадцати. Аудит фиксировал только часть событий, поэтому восстановить полную цепочку «кто запросил — кто одобрил — какие данные получил» было невозможно.

Масштаб компании сделал ситуацию критической. Число команд и проектов растёт, а старый порядок не масштабируется. Требования, которые сформулировали до начала проекта, оказались жёсткими: только аутентификация через единый провайдер, минимум прав по умолчанию, обязательный лог каждого действия и цифровой след согласования. Выполнить эти условия точечными правками в отдельных базах не получалось.

При оценке такого подхода стоит учитывать, что отсутствие централизации приводит к фрагментации прав и повышенной вероятности ошибок при отзыве доступа. Ручные процессы плохо поддаются аудиту и не обеспечивают требуемый регуляторами уровень контроля. Если в компании уже есть несколько десятков баз данных и сотни пользователей, ручное управление быстро становится источником задержек и потенциальных утечек. Внедрение единой точки входа позволяет стандартизировать правила и снизить нагрузку на администраторов баз, но требует готовности к изменению процессов согласования.

Как устроен шлюз

Trino стал единственной точкой, через которую пользователи и сервисы обращаются к данным. На каждый запрос OPA проверяет политику, описанную в Rego. Политики хранятся в виде кода, проходят версионирование и автоматическую сборку, а затем попадают в S3, откуда OPA подхватывает их без перезапуска. Аутентификация идёт через Keycloak по OIDC, секреты лежат в Vault, события безопасности отправляются в Kafka и далее в SOC.

Гранулярность политики позволяет ограничивать доступ до колонки, но на практике чаще используют уровень catalog/schema/table. Это снижает сложность поддержки и ускоряет проверку. Матрица прав преобразуется в политики автоматически, поэтому изменения в правах не требуют правок в каждой СУБД. Вся логика вынесена из баз данных наружу и становится частью обычного CI/CD-процесса.

Trino здесь выступает как распределённый SQL-движок, который унифицирует доступ к разнородным источникам без копирования данных. OPA обеспечивает внешнюю проверку правил, что упрощает аудит и обновление политик. При принятии решения важно оценить, насколько существующая инфраструктура поддерживает интеграцию с Keycloak и Vault, а также готовность команды работать с политиками как с кодом. Централизация снижает риски несогласованных прав, но увеличивает зависимость от работоспособности шлюза. Если запросов много, стоит заранее проверить производительность Coordinator, чтобы избежать задержек при проверке политик.

Распределение ответственности

Проект не мог быть реализован силами одной команды. AI & Data Security отвечает за архитектуру и дизайн процесса. Core DevOps берёт на себя деплой, покрытие Trino по компании и поддержку. Rapid Response Team обеспечивает оперативную работу и мониторинг. Такая декомпозиция позволяет не завязывать систему на одного человека и делает её проверяемой.

В российских компаниях похожего размера аналогичная схема помогает выполнить требования регуляторов по аудиту и разграничению прав. При этом важно заранее заложить интеграцию с внутренними системами учёта сотрудников и процессами увольнения, иначе автоматизация отзыва прав не заработает.

Распределение ролей снижает вероятность ошибок и упрощает масштабирование, однако требует чёткого описания зон ответственности между командами. При переносе решения на собственный контур стоит проверить, есть ли в компании аналогичные подразделения или достаточно ли ресурсов у существующих DevOps-команд для поддержки дополнительного слоя. Без этого централизованный контроль может стать узким местом.

Что учитывать при оценке

Решение требует зрелой Kubernetes-инфраструктуры и готовности поддерживать политики как код. Если в компании ещё нет единого IdP или процесс согласования остаётся полностью ручным, сначала придётся выстроить эти слои. Политики нужно регулярно пересматривать, иначе они обрастут устаревшими правилами. При переносе на собственный контур стоит проверить, насколько существующие источники данных совместимы с Trino, и оценить нагрузку на Coordinator при большом числе запросов.

В итоге внедрение имеет смысл, когда число баз и пользователей уже измеряется десятками и сотнями, а ручной процесс стал источником задержек и рисков. В меньших масштабах затраты на поддержку OPA и Trino могут превысить выгоду. Подробности реализации описаны в статье на Хабре.

Источник

Это краткий разбор материала Wildberries (RWB). Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Централизованный контроль прав в базах через Trino.

Курс по теме — Каталог курсов Школы Больших Данных