Техническое задание на создание СЗИ: как собрать документ, по которому реально можно работать

С техническим заданием на создание СЗИ обычно случается перекос в одну из двух сторон. Либо его превращают в формальный документ ради комплекта, который никто потом не открывает, либо пытаются впихнуть в него вообще всё: от общих фраз о важности безопасности до детальных настроек, которые ещё даже не определены. В обоих случаях ТЗ перестаёт быть рабочим документом. А ведь его смысл как раз в обратном — зафиксировать, что именно и на каком основании должно быть сделано, чтобы дальше проект, внедрение и проверка шли по одной линии.

На практике хорошее ТЗ — это документ, который можно дать проектировщику, администратору, подрядчику, комиссии или руководителю, и все они увидят одну и ту же задачу. Не набор пожеланий, не красивую декларацию и не технический дамп, а понятный каркас будущей СЗИ. Если документ не помогает принять решения и потом проверить, что решение реализовано правильно, значит, он написан зря.

Именно поэтому ТЗ нельзя писать в отрыве от реальной системы. Оно должно вырастать из уже понятных границ ИС, её класса, состава активов, потоков и выбранной логики защиты, а не подменять собой этот анализ.

Что в ТЗ действительно обязательно

Здесь важно не выдумывать лишнего. Если смотреть строго по нормативной логике, у ТЗ есть обязательное ядро. Во-первых, в нём должно быть однозначно указано, для какой именно информационной системы создаётся СЗИ и какой класс или классы типовых ИС ей присвоены. Во-вторых, в нём должны быть зафиксированы требования к СЗИ в зависимости от используемых технологий и класса ИС по приложению 3. Всё остальное уже относится к качеству документа и его пригодности для реальной работы.

Это означает простую вещь: плохое ТЗ может быть толстым, подробным и даже аккуратно оформленным, но если в нём не закреплена привязка к конкретной ИС и её классу, а требования к СЗИ не выведены из приложения 3 и используемых технологий, документ уже собран неправильно. И наоборот, даже сравнительно компактное ТЗ может быть рабочим, если это обязательное ядро в нём есть и дальше оно грамотно развернуто в прикладные разделы.

Именно здесь и проходит граница между формальным документом и рабочим инструментом. Формальный ТЗ существует ради наличия. Рабочий ТЗ связывает класс ИС, технологии, требования, архитектуру и будущие доказательства в один маршрут.

Какой каркас ТЗ реально помогает в проекте

На практике удобнее всего собирать ТЗ как документ из обязательного ядра и прикладной надстройки. Обязательное ядро нужно, чтобы документ вообще соответствовал нормативной логике. Прикладная часть нужна, чтобы по нему можно было реально строить СЗИ, внедрять меры и потом проверять результат. Если оставить только обязательный минимум, получится слишком сухой документ, по которому трудно работать. Если писать только прикладную часть и забыть про обязательное ядро, получится хороший внутренний документ, но слабый с точки зрения нормативной опоры.

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

Общие сведения об ИС (обязательно). Здесь фиксируются наименование ИС, владелец, назначение системы и присвоенный класс или классы типовых ИС. Это нормативное основание всего документа.
Требования к СЗИ (обязательно). В этом разделе должны быть отражены требования к системе защиты информации в зависимости от используемых технологий и класса ИС по приложению 3. Это не приложение ради приложения, а центральная часть ТЗ.
Границы и состав ИС (практически необходимо). Что входит в контур: площадки, сегменты, серверы, виртуальные машины, рабочие места, каналы связи, внешние взаимодействия, обеспечивающие сервисы, средства защиты.
Исходные архитектурные и технологические условия (практически необходимо). Какие технологии уже используются, какие ограничения есть у инфраструктуры, какие СЗИ уже внедрены, что нельзя ломать в ходе работ.
Требования к реализации мер защиты (практически необходимо). Какой результат должен быть получен по доступу, администрированию, журналированию, резервному копированию, удалённому доступу, защите каналов связи, сегментации, использованию СКЗИ и другим направлениям.
Требования к документированию (практически необходимо). Какие схемы, ЛПА, ОРД, перечни и рабочие материалы должны быть разработаны или актуализированы по итогам создания СЗИ.
Требования к подтверждению результата (практически необходимо). Какие проверки, скриншоты, конфигурации, журналы, протоколы и иные доказательства должны появиться на выходе.
Этапы, ответственность и критерии завершения (практически необходимо). Кто делает, в какой последовательности, где контрольные точки и что считается завершением каждого этапа.

Такой каркас не спорит с приказом № 66. Он просто превращает его минимальные требования в документ, по которому можно работать не в теории, а в проекте.

Практический пример

Допустим, владелец ИС пишет ТЗ на создание СЗИ для системы, где есть веб-доступ пользователей, сервер приложений, база данных, VPN для удалённых сотрудников, доменная аутентификация, межсетевой экран, журналирование и резервное копирование. Плохой вариант ТЗ в такой ситуации выглядит так: перечислены общие требования к защите информации, дана отсылка к приказу № 66 и приложению 3, после чего написано, что необходимо обеспечить безопасность системы.

Формально такой документ существует, но реально по нему нельзя ни внедрять, ни проверять. Из него неясно, какие сегменты должны быть выделены, как должен организовываться удалённый доступ, что именно журналируется, где должны храниться журналы, как подтверждается резервное копирование, что считается допустимой моделью администрирования и где вообще заканчивается защищаемый контур.

Рабочий вариант ТЗ в той же ситуации будет намного приземлённее. В нём сначала зафиксированы сама ИС, её класс и обязательные требования к СЗИ по приложению 3. А дальше это обязательное ядро уже развернуто в понятные проектные блоки: контур системы, меры по направлениям, состав документов, ожидаемые доказательства и этапы выполнения. Тогда ТЗ перестаёт быть бумажной формальностью и становится маршрутом для создания СЗИ.

Где чаще всего ломают документ

Первая ошибка — писать ТЗ слишком рано, когда ещё толком не понятны границы ИС и её фактический состав. Тогда документ почти неизбежно приходится переписывать после уточнения схем. Вторая ошибка — сводить всё к переписанному приложению 3 без привязки к реальной архитектуре. Третья — делать из ТЗ уже почти отчёт о реализованных настройках, хотя это всё ещё документ задания, а не подтверждения.

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

Техническое задание на создание СЗИ нужно не для формального комплекта и не для красивой папки. Его задача — зафиксировать задачу на понятном языке, связать нормативные требования с конкретной ИС и дать основу для внедрения, контроля и последующей проверки результата. Обязательное ядро у него узкое, но жёсткое. Всё остальное — это уже вопрос качества документа. Хорошее ТЗ всегда состоит из обоих слоёв: того, что обязательно, и того, что делает документ по-настоящему рабочим.