Регламент ввода нового сервиса в эксплуатацию: согласование архитектуры с ИБ, обязательные проверки и контроль конфигурации перед запуском

Бизнес хочет запускать фичи быстро. ИБ хочет запускать безопасно.

В идеальном мире эти цели синхронизированы. В реальном они конфликтуют. Проект приходит на согласование за день до релиза с «минимальными правками». А после запуска выясняется, что логи не пишутся, доступы не ограничены, а конфигурация — по умолчанию. И в продакшен всё полетело в пятницу 13-е!

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

Этап 1: Согласование архитектуры с ИБ — что реально проверяют

Так и хочется побыстрее воткнуть подпись, но нам необходима содержательная оценка.

На этом этапе ИБ-команда должна получить ответы на следующие вопросы:

• Что за сервис и в какие данные он полезет клювом?
• С какими системами необходима интеграция?
• Кто пользователь — внутренний сотрудник, внешний клиент, партнёр?
• Модель угроз — и не абстрактная «из шкафа», а привязанная к реальным компонентам сервиса.
• Оценка критичности потенциального ущерба — что будет, если сервис взломают или он упадёт?
• Закрыты ли элементарные векторы — дефолтные пароли, публичные эндпоинты без аутентификации, отладка в продакшене?
• Логирование и мониторинг — предусмотрены в принципе, а не «допилим потом».
• И конечно, наличие благословения в ближайшей церкви — отмашка руководства на то, что деньги на безопасность выделят.

В качестве практического совета: проводите архитектуру через ИБ не в конце, а на стадии проработки идеи. Это дешевле, быстрее и эффективнее, чем переделывать готовый продукт, а потом разгребать последствия поспешных решений. Проверено на себе.

Этап 2: Обязательные проверки перед запуском

Минимальный набор, без которого сервис не должен попадать в продакшен.

Сканирование зависимостей

Проверка сторонних библиотек на известные уязвимости (CVE). Автоматизировать через CI/CD, блокировать сборку при критических находках. Потому что разработчик мог стянуть библиотеку с уязвимостью, даже не заметив.

Статический анализ кода (SAST)

Поиск уязвимостей и «запахов» безопасности в исходниках — SQL-инъекции, жестко зашитые пароли, небезопасные функции. Интегрировать в pull request, чтобы разработчики видели проблемы до мёрджа, а не после выкатки.

Проверка конфигураций

Валидация настроек инфраструктуры (контейнеры, облака, сетевые правила) на соответствие hardening-стандартам — CIS, vendor best practices. Потому что «оставить как на дев-стенде» — это путь в ад.

Тестирование бизнес-логики

Ручные или автоматизированные сценарии на обход авторизации, манипуляции с параметрами, аномальные потоки данных. То, что не найдёт ни SAST, ни сканер зависимостей. Только человек (или очень умный инструмент) поймёт, что «а если вместо ID юзера подставить ID админа — сработает?».

Валидация логирования

Убедиться, что ключевые события (входы, изменения прав, ошибки) действительно пишутся, парсятся и попадают в SIEM. Потому что когда инцидент уже случился, а логов нет — это не смешно. Это профессиональная травма.

Важно, что проверки должны быть «инфраструктурой как код» — описаны в репозитории, версионированы, запускаться автоматически. Ручные чек-листы быстро устаревают и пропускаются под давлением дедлайнов. А это, как известно, наше самое любимое в работе.

Этап 3: Контроль конфигурации — как не «сломать» безопасность после релиза

Запуск — это ещё не отпуск. Конфигурация может «уплыть» из-за ручных правок, обновлений, человеческих ошибок. Или просто потому, что кто-то решил «проверить, а что будет, если…».

Что помогает удержать контроль:

Infrastructure as Code (IaC)

Все настройки инфраструктуры — в коде, с ревью, версионированием и откатом. Любое изменение — через merge request, а не «по быстрому в консоли». Иначе рано или поздно кто-нибудь откроет порт 0.0.0.0/0 просто потому, что «так проще тестировать».

Policy as Code

Правила безопасности (например, «никаких публичных S3-бакетов») описываются декларативно и проверяются автоматически при каждом изменении. Никто не «забудет» поправить чек-лист.

Непрерывный мониторинг дрейфа

Инструменты сравнивают фактическое состояние с эталонным и алертят при расхождениях. Увидели, что конфиг уехал — откатили, нашли виноватого (или того, кто просто «не знал»), закрыли вопрос.

Регламент экстренных правок

Если «надо срочно», то есть процедура, которая фиксирует изменение, уведомляет ИБ и гарантирует возврат к базовой конфигурации в оговоренный срок. Не «поправили и забыли», а «поправили, зафиксировали, через два часа вернули как было».

Что в сухом остатке — чек-лист для безопасного релиза

Собственно, эти на первый взгляд «простые» шаги уже позволяют избавиться от многой головной боли. Поэтому предлагаю сформировать из них небольшой чек-лист. На стену в SOC, в Notion команды разработки и в голову каждому, кто имеет доступ к merge request’у.

• Архитектура согласована с ИБ на этапе проектирования, а не «под релиз»
• Модель угроз актуальна и привязана к реальным компонентам сервиса
• Все зависимости просканированы, критические уязвимости устранены (или принят риск)
• Конфигурации описаны как код, проверены на соответствие hardening-стандартам
• Логирование настроено, ключевые события попадают в SIEM, парсинг работает
• Резервное копирование настроено, восстановление протестировано (да, это тоже к безопасности)
• Есть процедура экстренных правок с уведомлением ИБ и откатом
• Ответственный за безопасность сервиса назначен и имеет полномочия останавливать релиз при критических рисках (это важно — если он только «рекомендует», толку ноль)

Заключение

Есть ещё, конечно, политическое влияние внутри каждой компании — когда безопасность упирается в «позвонили с седьмого этажа, сказали пропустить». Как ловко комбинировать вышеизложенное с этим феноменом, мы уже разберём в другой статье. А если у вас еще остались вопросы, «Астрал. Безопасность» всегда готовы вам с этим помочь!

Автор статьи: Мицюк Максим, специалист по информационной безопасности.