Требования ИБ к новой системе: короткий чек-лист в ТЗ
Архитектурная проверка перед запуском ловит дыры, когда система уже куплена или написана. Этот чек-лист ставится раньше: в техническое задание (ТЗ) или в договор, пока ещё можно сказать «без журналов не принимаем». Пройдите пункты с заказчиком и исполнителем до подписания, отметьте, что обязательно, что исключение, кто проверяет на приёмке.
Это не юридическая консультация и не замена экспертизы договора. Дополнение, не замена: перед продуктивным запуском отдельно пройдите архитектурную проверку; каждый релиз кода — чек-лист релиза. Модель угроз системы: за один день.
Статья опирается на логику направления «Архитектура кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами.
Что должно получиться
В ТЗ есть раздел «Требования информационной безопасности» с проверяемыми формулировками, а не фраза «система должна быть безопасной». Для каждого пункта ниже — отметка в ТЗ: обязательно / не применимо (почему) / исключение до даты. Исполнитель не может снять пункт молча.
☐ Доступ
- ☐ Вход пользователей — личные учётные записи, без общей «admin» в продуктив.
- ☐ Для администраторов и удалённого доступа — второй фактор.
- ☐ Права по ролям; роль с полными правами не используется для повседневной работы.
- ☐ Описан отзыв доступа при увольнении и смене должности в срок, согласованный с кадрами.
- ☐ Подрядчик входит только в оговорённый контур, сессии учитываются.
☐ Данные
- ☐ Перечислены категории данных (в том числе персональные) и места хранения.
- ☐ Тестовый контур без копии боевых персональных данных либо с обезличиванием: тестовые данные и логи.
- ☐ Каналы наружу — с шифрованием на транспорте; секреты не в репозитории.
- ☐ Если данные обрабатывает подрядчик — в ТЗ отсылка к поручению и к составу действий, не «доступ как удобно».
☐ Сеть и размещение
- ☐ Указана зона размещения по сегментации и какие потоки разрешены.
- ☐ Наружу открыты только названные порты; админка не торчит в интернет без VPN.
- ☐ Новые потоки попадают на схему сети до запуска, не после.
- ☐ Зависимости (платежный шлюз, почта, объектное хранилище) названы, для каждой — кто отвечает за договор и доступ.
☐ Журналы и копии
- ☐ События входа, смены прав и отказа в доступе пишутся и хранятся оговорённый срок.
- ☐ В журналы не попадают пароли, токены и тела персональных данных.
- ☐ Резервное копирование новых данных входит в существующую схему 3-2-1 либо описано отдельно, с пробным восстановлением.
- ☐ Часы и идентификаторы узлов согласованы, чтобы журналы можно было сложить при инциденте.
☐ Приёмка ИБ
- ☐ В ТЗ есть критерий приёмки: кто со стороны заказчика смотрит доступы, журналы, схему и копии.
- ☐ Незакрытые пункты либо устранены, либо приняты руководителем как риск с датой пересмотра — не «запустим, потом закроем».
- ☐ Источники установки и состав ПО согласованы: откуда ставить, что можно ставить.
- ☐ Изменение после приёмки идёт через карточку, а не «маленькая доработка в чате»: управление изменениями.
Как вставить в ТЗ, а не в переписку
Скопируйте пять блоков в приложение к ТЗ. Против каждого пункта — колонка «как проверят на приёмке» (команда, журнал, схема, акт). Пункт без способа проверки вычеркните или перепишите: иначе исполнитель сдаст систему «по смыслу», а спор будет на словах.
Если закупаете SaaS, те же блоки превратите в вопросы поставщику до оплаты. Облако и персональные данные: как выбрать и проверить.
Диагностика
| Симптом | Причина и что делать |
|---|---|
| В ТЗ одна строка «соответствие 152-ФЗ» | Нет проверяемых мер. Замените на пункты доступа, журналов и тестовых данных |
| ИБ видит систему за неделю до запуска | Чек-лист не попал в ТЗ. Верните приложение на этап договора, даже ценой сдвига срока |
| Исполнитель вычеркнул журналы «не в бюджете» | Нет колонки приёмки. Зафиксируйте исключение как риск руководителя, не как устную скидку |
| Путают этот список с проверкой перед продом | Разные моменты жизни системы. ТЗ — до работ; архитектурный чек-лист — до включения пользователей |
Где это в модели зрелости
Материал относится к направлению «Архитектура кибербезопасности» (хаб: архитектура кибербезопасности, карта: карта зрелости). Гигиена — требования ИБ попадают в проектирование новой системы, а не наклеиваются перед релизом. Схема сети и сегментация задают, куда систему вообще можно поставить; этот чек-лист говорит, что должно быть внутри ТЗ.
Как проверить
- Последнее ТЗ или договор на информационную систему содержит приложение с этими блоками или явную отсылку к ним.
- У каждого обязательного пункта написано, чем его примут (журнал, схема, акт, команда).
- Снятые пункты имеют причину «не применимо» или исключение с датой, подписанное руководителем.
- Дата согласования ИБ раньше даты начала разработки или поставки, а не недели запуска.
- Перед продом всё равно есть отметка об архитектурной проверке — этот чек-лист её не заменяет.
Источники
- CIS Controls v8.1, контроль 16 (безопасность прикладного ПО на протяжении жизненного цикла). Это не закон РФ: cisecurity.org.
- NIST Cybersecurity Framework 2.0. Это не закон РФ: nist.gov/cyberframework.
- Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
