ADG Оставить заявку
Блог Информационная безопасность 6 мин чтения

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

Почему аутсорс DevOps не страшнее внешнего бухгалтера, и как именно мы работаем с доступами: NDA до переговоров, наименьшие привилегии, Vault, маскирование и audit-log.

Контекст момента

После ужесточения штрафов за утечки ПДн бизнес пристально смотрит, как подрядчик работает с доступами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Журнал действий: что, кто и когда

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

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

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

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

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

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

Один честный компромисс

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

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

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

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

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

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


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

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.

Сообщение придёт нам в мессенджер. Отправляя форму, вы соглашаетесь с политикой конфиденциальности.