Ваши доступы и данные: NDA, маскирование, Vault и audit-log

Когда мы предлагаем DevOps-аутсорсинг, почти всегда на каком-то этапе звучит один вопрос: «А вы же получите доступы к нашей инфраструктуре — как мы можем быть уверены, что данные не уйдут?» Вопрос разумный. Но есть кое-что интересное в том, как именно он возникает.

Несимметрия восприятия

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

При этом внешний DevOps-инженер вызывает куда больше вопросов — несмотря на то, что риски по природе те же. Не потому, что вопросы неправомерные: просто восприятие риска устроено несимметрично. К привычному — доверие по умолчанию. К новому — скептицизм.

Давайте разберём, что реально происходит с доступами, когда мы берём инфраструктуру на обслуживание.

NDA до того, как мы видим хоть что-нибудь

Соглашение о неразглашении мы подписываем до начала технических переговоров — не после того, как договорились о цене, не параллельно с договором на обслуживание, а раньше. До того, как вы показали нам схему инфраструктуры, список систем или что-либо ещё.

Это не формальность. Это означает, что с момента первого технического звонка мы несём юридическую ответственность за конфиденциальность того, что услышим. Работаем как юрлицо РФ, договор — с реквизитами и подписями, не на честном слове.

Наименьшие привилегии: только то, что нужно для задачи

Принцип наименьших привилегий — не декларация о намерениях, а рабочая механика. На практике это означает, что набор прав, который получает инженер, определяется конкретной задачей, а не соображением «лишний раз не переспрашивать».

Для сопровождения CI/CD не нужен доступ к продуктовой базе данных. Для настройки мониторинга не нужен доступ к конфигам платёжного модуля. Права выдаются адресно и ревьюятся — не один раз при подключении, а регулярно.

Это принципиально отличается от типичной ситуации с внутренним администратором, который накапливал права годами — потому что когда-то помог с одной задачей, потом с другой, и никто не убирал то, что уже не нужно. «Исторические» права — реальный вектор риска, о котором реже думают, чем о внешних угрозах.

Боевые базы: без прямого доступа, через маскирование

К производственным базам данных с персональными данными мы не работаем напрямую. Там, где нужно диагностировать поведение системы — используем маскирование: имена, телефоны, идентификаторы заменяются синтетическими значениями, сохраняющими структуру, но не несущими реальных данных.

Это требование 152-ФЗ в практическом выражении: оператором персональных данных остаётесь вы, технический подрядчик работает с данными в той мере, в которой это необходимо для выполнения задачи — и не более.

Секреты в Vault, а не в конфигах и головах

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

Мы писали об этом подробно ещё в 2018-м: тогда мы перевели три production-сервиса на динамические секреты для PostgreSQL. Суть механики — Vault создаёт временного пользователя в базе, выдаёт его приложению на конкретный TTL, потом автоматически отзывает. Пароль к базе не существует как постоянная сущность. Даже если credentials где-то утекли — они валидны не годами, а часами.

Параллельная история — сканирование репозиториев на предмет секретов. В 2018-м первый прогон gitleaks по одному из клиентских репозиториев нашёл три живых AWS-ключа в истории коммитов — их немедленно ротировали. Сейчас проверка репозиториев на утёкшие секреты входит в стандартный чеклист при аудите безопасности.

Vault даёт ещё один важный эффект: видимость. В pg_roles в любой момент видно, кто сейчас имеет доступ к базе. Никаких «а вдруг где-то ещё остался пароль» — картина текущего состояния доступов прозрачна.

Audit-log: что, кто и когда

Все действия в инфраструктуре логируются. Audit-log — не опциональная функция и не инструмент постфактум-разборок. Это рабочий инструмент: при инциденте вопрос «что именно произошло и кто это сделал» решается за минуты, а не за дни расследования.

Для вас это означает следующее: вы можете запросить лог действий за любой период. Прозрачность — в обе стороны.

Доступы и ключи остаются у вас

Это, пожалуй, самое важное: выдаёте доступы вы, отзываете — тоже вы. Ключи шифрования остаются на вашей стороне. Инфраструктурный код в Terraform, Ansible, GitLab принадлежит вам.

Если мы расстаёмся — вы не остаётесь с настройками в голове у одного инженера. У вас остаётся воспроизводимое описание контура и полный контроль над доступами. Отзыв — дело нескольких минут: один звонок, одна операция в IAM или Vault, и доступ закрыт полностью.

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

Один честный trade-off

Строгая модель доступов иногда замедляет работу. Если инженеру нужен временный доступ к системе, которой нет в текущем наборе прав — нужно запросить, согласовать, выдать. Это занимает время. В экстренных ситуациях — особенно.

Мы считаем, что это приемлемая цена. Альтернатива — широкие права «на всякий случай» — устраняет трение, но создаёт реальный риск. Там, где нужна скорость реакции, мы решаем это не расширением прав, а заранее составленными runbook-ами для типовых инцидентов и чётко ограниченным набором прав для дежурной смены.

Что это значит на практике

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

С DevOps-аутсорсингом — то же самое. NDA до переговоров, наименьшие привилегии, доступы к боевым данным через маскирование, секреты через Vault, audit-log всех действий, ключи и доступы остаются на вашей стороне. Контроль — строже, чем у среднестатистического внутреннего администратора с историческими правами.

Разница не в том, кто несёт меньше рисков — внутренний или внешний. Разница в том, явная ли модель доступов или нет. Мы работаем с явной.

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