Чек-лист проверки архитектуры перед запуском сервиса

Статья «Модель угроз за один день» разбирает, как оценить риски системы целиком. Этот чек-лист уже, но предназначен для повторного использования: его проходят перед запуском каждого нового сервиса в продуктив, за 20–30 минут, без привлечения внешних консультантов.

Статья опирается на логику направления «Архитектура кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами.

Что должно получиться

Уровень	Что это значит на практике
2. Гигиенический	Новый сервис перед запуском в продуктив проходит базовую архитектурную проверку, находки фиксируются и закрываются до запуска или осознанно принимаются как риск

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

☐ Потоки данных и границы доверия

☐ Известно, откуда в сервис попадают данные (пользователи из интернета, внутренние системы, партнёрские интеграции) и куда он сам обращается наружу.
☐ Для каждой точки, где данные пересекают границу доверия (из интернета во внутреннюю сеть, из одного сервиса в другой с другим уровнем доступа), есть явная проверка на этой границе, а не только на входе в систему целиком.
☐ Сервис не обращается к внутренним системам напрямую там, где можно пройти через существующий внутренний API с собственной проверкой прав.

☐ Аутентификация и авторизация

☐ У сервиса нет собственного механизма входа «на скорую руку» — используется существующий централизованный механизм аутентификации компании, если он есть.
☐ Проверка прав выполняется на стороне сервера при каждом запросе, а не только скрытием кнопки в интерфейсе.
☐ Сервисные и технические учётные записи для межсервисного взаимодействия не используют один и тот же общий пароль для разных окружений (тест и продуктив).

☐ Хранение данных

☐ Известно, какие данные сервис хранит и есть ли среди них персональные или платёжные данные — если да, применяются требования самопроверки по ПДн.
☐ Чувствительные данные не хранятся в тестовой среде в виде прямой копии продуктива без обезличивания.
☐ Резервное копирование данных сервиса включено в общую стратегию копирования, а не осталось «добавим потом».

☐ Журналирование

☐ Сервис пишет журнал действий, значимых для безопасности: вход, изменение прав, отказ в доступе.
☐ В журнал не попадают пароли, токены и содержимое персональных данных в открытом виде.
☐ Журнал доступен для разбора инцидента (централизованный сбор или хотя бы хранение на самом сервере достаточный срок), а не исчезает при перезапуске контейнера.

☐ Сетевой доступ

☐ Сервис слушает только нужные порты и только на нужных адресах, а не на всех интерфейсах по умолчанию.
☐ Административный интерфейс (панель управления, метрики, отладочный эндпоинт) не доступен из интернета напрямую.
☐ Правила сетевого доступа соответствуют принятой сегментации сети, а не добавлены точечным исключением «чтобы заработало».

☐ План на случай отказа и инцидента

☐ Известно, кто получает оповещение, если сервис станет недоступен или начнёт работать нештатно.
☐ Есть способ быстро отключить сервис или ограничить его доступ, не затрагивая остальную инфраструктуру.
☐ Процесс реагирования на инцидент учитывает этот сервис (данные, которые он хранит, и то, куда он обращается): первые 24 часа реагирования.

Как проводить проверку на практике

Проверку проходят до того, как сервис получит реальных пользователей или реальные данные — на этапе, когда находки ещё дёшево исправить. Отвечает на вопросы команда, которая делает сервис, при участии того, кто отвечает за ИБ: формат — встреча на 20–30 минут с чек-листом перед глазами, не бумажный опросник, заполняемый в одиночку. Находки без галочки фиксируются отдельным списком с владельцем и сроком; то, что сознательно решили не исправлять до запуска, — как принятый риск с обоснованием, а не молча пропущенный пункт.

Диагностика

Симптом	Причина и что делать
Проверка превращается в разбор архитектуры на два часа	Чек-лист используется не по назначению — для этого есть модель угроз. Держите формат коротким, глубокий разбор переносите в отдельную встречу
Пункты отмечаются «на глаз» без проверки	Нет ответственного, который реально смотрит конфигурацию. Назначьте, кто подтверждает каждый пункт делом, а не словом
Находки фиксируются, но не закрываются до запуска	Нет срока и владельца. Переносите находку в тот же трекер задач, где ведётся остальная разработка, с конкретным сроком
Команда воспринимает проверку как бюрократию, тормозящую запуск	Проверка проводится слишком поздно, когда всё уже готово. Встройте её в план работ заранее, а не добавляйте последним шагом

Где это в модели зрелости

Материал относится к направлению «Архитектура кибербезопасности» (материалы направления, карта зрелости). Уровень 2 требует, чтобы архитектурные решения проверялись системно, а не полагались на память команды: короткий повторяемый чек-лист даёт такую проверку без отдельного согласования для каждого запуска.

Как проверить

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