Привет, Хабр! Меня зовут Даниил Пасечник, в RWB я отвечаю за архитектуру управления пользовательского доступа в базы данных. В этой статье расскажу, как мы прошли путь от разрозненной, неконтролируемой выдачи доступов к БД до единого корпоративного процесса на базе Trino и Open Policy Agent — и почему это получилось не просто техническим решением, а полноценной кросс‑департаментной архитектурой.
Это будет история не только про код и инфраструктуру, но и про то, как из проблемы одного отдела вырастает задача уровня компании, требующая сборки команды, декомпозиции ответственности и управленческих решений не менее важных, чем архитектурный и технический слои.
Проблема, с которой всё началось
Когда мы начали разбираться, как устроен доступ к данным, картина была примерно такой:
Доступ к БД выдавался не гранулярно — фактически человек получал доступ сразу ко всей базе, а не к нужным ему таблицам или схемам;
Процесс отзыва доступа у сотрудника не был автоматизирован и зависел от ручной синхронизации между HR и отдельными инфраструктурными командами — это создавало операционные риски и требовало постоянного контроля;
Выдача нового доступа занимала от 1 до 17 дней, в среднем около 4 дней — пока заявка проходила все ручные согласования и локальное создание учётной записи;
Аудит того, кто и когда получил доступ и на каком основании, велся фрагментарно и не давал полной картины.
Мы проанализировали эти проблемы не изолированно, а в контексте потребностей бизнес‑подразделений — компания растёт, число проектов и команд, которым нужен доступ к данным, растёт вместе с ней, и с текущим процессом это просто не масштабировалось. Стало понятно: чинить это точечно бессмысленно, нужно закрывать проблему комплексно, на уровне единого централизованного процесса для всей компании.
Масштаб задачи: почему это невозможно сделать в одиночку
Прежде чем проектировать решение, были сформулированы требования, которым оно должно соответствовать:
Анонимный и парольный доступ к базам данных запрещён — только через единого провайдера идентификации.
Минимизация прав по умолчанию — доступ выдаётся ровно на то, что нужно, а не «с запасом».
Обязательный аудит операций — каждое действие с данными должно быть прослеживаемо, с обязательным логированием и хранением событий.
Цифровой след запроса доступа и его согласования — кто запросил, кто согласовал, когда и на каком основании.
Когда я сопоставил это с реальным масштабом RWB — десятками команд, сотнями баз данных и пользователей — стало очевидно: это не задача одного сотрудника и даже не задача одной команды. Нужен был не просто технический шлюз к данным, а организационный процесс с чёткой декомпозицией зон ответственности между несколькими департаментами.
Так мы решили собирать большую архитектуру, в которой каждый отдел закрывает свой участок — так, чтобы вся конструкция была одновременно управляемой, проверяемой и не завязанной на одного человека или одну команду.
Архитектура решения и как был организован процесс
В основе решения — простая идея: Trino как единая точка входа к данным, а OPA (Open Policy Agent) — как декларативный слой контроля доступа поверх неё. Вместо того, чтобы управлять правами внутри каждой отдельной СУБД, мы выносим всю логику доступа наружу, в политики, которые можно версионировать, тестировать и аудировать как обычный код.
Ключевые компоненты:
Trino Coordinator/Worker — принимает и исполняет запросы к данным.
OPA — на каждый запрос проверяет, разрешена ли операция политикой.
Keycloak — аутентификация пользователей через OIDC, без паролей и анонимного доступа.
Vault — хранение всех секретов и конфигураций.
S3 — длительное хранение событий безопасности.
Kafka — брокер сообщений для передачи событий безопасности в SOC.
Kubernetes — среда для всего этого хозяйства.
Главное, что мне хотелось получить от модели доступа, — чтобы она была понятной и однозначной, как код.
Получилось так:
матрица доступов (group / catalog / owner / access / users)
↓ автогенерация
Rego-политики
↓ CI/CD
бандл в S3
↓
OPA подхватывает без рестарта
Технически гранулярность прав в OPA позволяет ограничивать доступ вплоть до отдельной колонки таблицы. На практике для большинства команд основным уровнем стал catalog / schema / table — этого достаточно для подавляющего большинства сценариев, а более тонкая настройка доступна там, где это действительно нужно.
Архитектуру и организацию процесса удалось закрыть своими силами, но реализация не была бы возможна без моего коллеги Максима Умнова, руководителя Rapid Response Team — на нём и его команде деплой, покрытие Trino по компании, а также постоянная поддержка сервиса. На сегодняшний день большая часть этих процессов уже автоматизирована.
Для полноты картины — вот как выглядит декомпозиция зон ответственности, к которой мы пришли:
Кто | За что отвечает |
AI & Data Security | Идея, архитектура, дизайн процесса, организация |
Core DevOps | Техническая реализация, деплой, автоматизация, поддержка |
Отдел управления доступов | Владеет пространством OPA‑политик в GitLab, независимый надзор за политиками, ресертификация и актуализация владельцев групп/каталогов |
SOC | Логирование и мониторинг событий Trino |
Trust Safety (T&S) | Длительное хранение логов и их доставка |
Как выглядит выдача доступа на практике
В рамках миграции на Trino мы выстроили три параллельных сценария выдачи доступа — под разные жизненные ситуации.
Базовые матрицы доступа для проекта. Команда описывает нужный доступ в виде матрицы (кто, к какому каталогу, с какими правами). К самой матрице мы подошли с «юзерфрендли» стороны: сформировали инструкцию и шаблон её заполнения, что позволило снизить вовлечённость бизнес‑подразделений и их трудозатраты.
Дальше всё происходит автоматически: запускаются два автотеста (проверка, что запрашиваются только согласованные операции из белого списка, и что группы не вложены друг в друга), после успешного прохождения MR согласовывается и мержится в основную ветку проекта. Управление ресурсами и гранулярность доступов ведётся строго на уровне проекта — это делает процесс независимым, снижает количество точек отказа и даёт полностью прозрачный аудит доступа в разрезе каждого проекта и команды.
Точечная выдача доступа пользователю в существующую группу. Этот процесс ещё проще для конечного пользователя: от инициатора требуется только заявка через Service Desk и двухуровневое согласование (владелец каталога и руководитель инициатора), дальше бэкенд‑процессор вносит изменение в Rego‑политику — без ручного MR со стороны пользователя.
С нашей стороны — пост‑контроль изменений на уровне Git. Если доступ не согласован или в процессе запроса выявлено нарушение, поступает алерт, и в заявку точечно подключается коллега из команды RRT для ручного сопровождения. Контроль выдачи доступа строится не только на жёстко заданных параметрах матриц, но и на ряде компенсирующих контрольных процедур, включая ступенчатую эскалацию, где уровень L2 закрывается совместно командой DevOps и отделом управления доступа.
На практике около 92% заявок отрабатывается автоматикой в режиме 24/7/365, ручная вовлечённость минимальна — для сравнения, до внедрения этого процесса соотношение было обратным: около 80% нагрузки закрывалось вручную и лишь 20% — редкой точечной автоматикой.
Временный доступ. Для разовых задач — включая внутренние инциденты команд и срочную разработку — предусмотрен параллельный процесс с TTL от 24 до 72 часов и возможностью получения прав RO или RW. Заявка проходит через Service Desk и интегратор, который определяет владельца базы через Global Inventory, получает согласование руководителя инициатора и владельца БД, выдаёт учётные данные через PrivateBin и автоматически отзывает их по истечении срока действия учётной записи.
Бизнес‑логика процесса передана на сопровождение отделу управления доступа, а техническая реализация — команде RRT. Мы также ведём дашборды в реальном времени по всем БД, проектам и инициаторам заявок. Если видим постоянный перезапрос прямого доступа к БД и явное злоупотребление повышенными привилегиями, включаем сотрудника и его команду в точечный аудит — разбираем причину запроса и бизнес‑обоснование к нему в деталях.
На практике такое случается редко: мы проводим регулярные рассылки и держим фокус внимания пользователей на работе с доступом именно через Trino. Временный доступ используется как исключение и компромисс ИБ в сторону бизнеса.
Отзыв доступа и безопасность в моменте
Одна из проблем, которая раньше требовала постоянного ручного контроля, — отзыв доступа при увольнении сотрудника. Сейчас связка Trino и Keycloak синхронизирована с HR‑системой и отзывает доступ сотрудника автоматически и практически мгновенно, без участия человека в цепочке.
При этом сами OPA‑политики — не бесконтрольная зона. За ними следит отдельный независимый контур: отдел управления доступов, у которого есть возможность в экстренной ситуации изъять доступ буквально за считанные секунды, не дожидаясь стандартного цикла согласований.
Параллельно с этим весь трафик Trino проходит через event‑listener в Kafka и дальше в SOC, где настроены алерты на:
массовый перебор системного каталога (enumeration);
неавторизованные попытки изменения данных (DDL/DML);
аномальный всплеск запросов (DoS/abuse);
имперсонацию — работу от имени другого пользователя;
подозрительные или устаревшие клиенты подключения.
Готовых практик мониторинга Trino под наши задачи на рынке просто не существовало — правила алертинга я писал с нуля, опираясь на реальную эксплуатацию и собственные тесты. После того как логика была готова, совместно с SOC реализовали отдельный канал передачи событий: поскольку работа с данными порождает огромный объём логов, лог разделили на уровне Kafka, и SOC получает только ту часть, которая необходима для работы их правил — этого полностью достаточно для мониторинга и алертинга.
Модель эскалации инцидентов — это тоже отдельный управленческий результат, который мы построили сами: готовых наработок под Trino не существовало ни у нас, ни на рынке. Мы с нуля описали три уровня: L1 закрывается силами SOC в рамках их внутренних процессов, L2 — совместно командой DevOps и отделом управления доступа, а L3 подразумевает подключение DataSec к разбору инцидента и, при необходимости работы с полным логом, — обращение SOC к архиву в S3. На практике грамотно выстроенная последовательность действий позволяет пресекать несанкционированную активность ещё на уровне L1 и заметно реже — на L2.
Логи для расследований и форензики инцидентов хранятся в S3 длительный срок — условия и период хранения установлены в соответствии с рекомендацией надзорных органов и реализованы силами команды T&S. Все секреты — только в Vault, вся конфигурация — только через IaC, без возможности ручных правок на проде.
Бизнес‑эффект: было / стало
Главная метрика, которая для меня лично значит больше всего, — время выдачи доступа:
Было: в среднем ~4 дня, в диапазоне от 1 до 17 дней;
Стало: 3–10 минут — это время, за которое MR проходит проверку в Git.
Это не абстрактная цифра, а конкретное снижение издержек бизнеса и заметное ускорение онбординга новых сотрудников: человек выходит на проект и в течение нескольких минут после согласования уже может работать с данными, а не ждёт доступ неделю, простаивая.
Похожий контраст — и в скорости подключения новых команд целиком, а не только отдельных пользователей. Сегодня, если появляется новая команда или новый источник данных, мы разворачиваем для неё полную архитектуру доступа «по кнопке» и в течение одного рабочего дня предоставляем полностью рабочую инфраструктуру. Это позволяет бизнесу без простоя сосредоточиться на своих задачах, а весь технический бэкграунд — предоставление доступа, онбординг пользователей, мониторинг и алертинг на аномальную активность — остаётся на нашей стороне.
Результаты роста:
1250+ кластеров PostgreSQL в проде подключено через Trino;
700+ уникальных пользователей работают через систему ежедневно;
90+ проектов компании подключено к Trino;
45+ проектов используют процесс временного доступа.
Отчет автоматически обновляется, контроль внедрения trino в realtime
Поддержка и онбординг пользователей
Технология без поддержки живёт плохо, поэтому мы с самого начала выстраивали процесс не только для инженеров, но и для конечных пользователей:
Организовали единый канал поддержки Trino support, работающий 24/7/365.
Подготовили обучающие ролики для новых сотрудников.
Подробно описали процесс и собрали FAQ по частым вопросам.
Всё, что выходит за рамки типовых сценариев, эскалируется в Core DevOps через тот же канал поддержки.
Дашборд зрелости
Отдельно хочу рассказать про инструмент, который мы внедрили для прозрачности всего процесса, — дашборд зрелости в BI‑системе, с изолированным окружением и доступом на чтение для всех желающих.
Динамика подключения кластеров и проектов, статус настройки проектов по Trino
Дашборд показывает, какие проекты компании уже подключены к Trino, какие ещё нет, и какой у каждого проекта уровень «здоровья» — по сути, зрелости с точки зрения информационной безопасности. Это не просто красивая визуализация: инструмент даёт публичную мотивацию командам подключаться и позволяет нам контролировать исполнение задач по миграции без ручных напоминаний.
Итоги
Если подводить черту: мы проанализировали проблему и потребности бизнес‑подразделений, собрали команду с чёткой декомпозицией зон ответственности и спроектировали корпоративную архитектуру — а вместе с Максимом Умновым, командой RRT, а также другими командами Core DevOps мы реализовали её в кратчайшие сроки. В результате получился не костыль поверх старых процессов, а рабочий, прозрачный и удобный для пользователей бизнес‑процесс.
Главная задача с самого начала была не в том, чтобы создать очередное ограничение от службы информационной безопасности, а в том, чтобы найти клиентоориентированный подход, который одновременно помогает бизнесу двигаться быстрее и закрывает все требования безопасности.
Спасибо за внимание!
