Почему «и так понятно» стоит дороже проекта
Проектная стадия — первое, что вычёркивают из ИБ-проекта под давлением сроков. Логика понятная: средства защиты выбраны, вендор известен, инженеры опытные — зачем месяц на документы. Счёт приходит позже и в других статьях: закуплена не та лицензия, межсетевой экран не встал в разрыв, потому что схема трафика оказалась другой, миграция потребовала простоя, которого никто не согласовывал, а на приёмке выяснилось, что проверять соответствие нечему — требований в измеримом виде не существует.
HLD и LLD решают одну задачу: перевести намерение в проверяемые решения до того, как за них заплатили. Это не бюрократия, а способ обнаружить ошибку на стадии, где её исправление стоит правки в документе, а не переноса релиза.
Граница между HLD и LLD
Путаница между документами приводит к тому, что HLD раздувается до настроек, а LLD остаётся набором картинок. Разделение проходит по одному признаку: HLD отвечает «что и почему», LLD — «как именно».
| Аспект | HLD (высокоуровневый проект) | LLD (низкоуровневый проект) |
|---|---|---|
| Вопрос | Какая архитектура закрывает угрозы и требования | Как это собирается и настраивается |
| Читатель | CISO, архитектор, закупка, регулятор | Инженер внедрения и эксплуатации |
| Сетевой уровень | Сегменты, зоны доверия, потоки между ними | VLAN, адресация, маршруты, правила фильтрации |
| Средства защиты | Классы средств и обоснование выбора | Модели, версии, лицензии, схемы включения |
| Отказоустойчивость | Требуемый режим и допустимый простой | Кластеры, синхронизация, порядок переключения |
| Доступ | Ролевая модель и принципы разграничения | Группы, политики, конкретные права |
| Результат | Согласованная архитектура и спецификация для закупки | Документ, по которому систему можно собрать и воспроизвести |
Практическое следствие: по HLD нельзя внедрять, а по LLD нельзя спорить об архитектуре. Попытка обойтись одним документом даёт либо неисполнимый замысел, либо настройки без обоснования.
Что должно быть в HLD
- Границы системы и объекты защиты. Что именно защищаем: информационные системы, сегменты, данные, их категории. Без этого невозможно оценить достаточность мер. Отправная точка — инвентаризация; для КИИ она обязательна и разобрана отдельно в материале про инвентаризацию.
- Модель угроз и нарушителя. Не формальная выписка из методики, а применённая к вашему контуру: какие сценарии реальны, какие меры их закрывают, какие риски принимаются осознанно.
- Требования. Нормативные (ФСТЭК, ФСБ, отраслевые), договорные и внутренние — сведённые в перечень, где у каждого требования есть решение, которое его закрывает. Это же станет основой программы приёмочных испытаний.
- Архитектура. Зоны, потоки, точки контроля, места включения средств защиты, схема управления и мониторинга.
- Обоснование выбора класса средств. Почему межсетевой экран уровня приложений, а не система обнаружения вторжений; почему средство криптографической защиты именно этого класса. Для сертифицированных решений — требуемый класс защиты и наличие действующего сертификата.
- Нефункциональные требования. Пропускная способность, задержка, число сессий, глубина хранения событий, режим доступности. Самый частый источник провала внедрения — их отсутствие.
- Спецификация. Перечень для закупки с лицензиями, поддержкой и сроками. Ошибка здесь всплывает через месяцы, когда докупать поздно.
Что должно быть в LLD
- Схемы включения каждого средства: в разрыв, зеркалированием, агентом — с указанием интерфейсов, адресов и портов.
- Адресный план и правила фильтрации в виде, пригодном для переноса в конфигурацию, а не в виде описания намерений.
- Конфигурации и политики: профили проверки, правила корреляции, политики доступа, интеграции с каталогом и системой мониторинга.
- Порядок развёртывания и миграции: последовательность шагов, окна работ, состояние сервисов на каждом шаге, критерии перехода к следующему.
- План отката. Что делать, если после переключения сервис недоступен. Отсутствие этого раздела — причина большинства ночных инцидентов на внедрении.
- Программа и методика испытаний: проверяемое требование, шаги, ожидаемый результат. По ней принимают работу — и по ней же потом проверяет регулятор.
- Эксплуатационные процедуры: обновление, резервное копирование конфигураций, действия при отказе, контакты поддержки вендора.
Типовые провалы и их корни
| Что случилось на внедрении | Чего не хватило в проекте |
|---|---|
| Средство защиты не держит нагрузку в час пик | Нефункциональных требований и расчёта производительности в HLD |
| Купленной лицензии не хватает на реальное число узлов | Спецификации, сверенной с инвентаризацией |
| Внедрение потребовало незапланированного простоя | Порядка миграции и согласованных окон работ в LLD |
| Система собрана, но принять её невозможно | Требований в измеримом виде и программы испытаний |
| Средство работает, но события никуда не идут | Схемы интеграции с мониторингом и форматов событий |
| После ухода подрядчика систему нельзя сопровождать | Эксплуатационных процедур и воспроизводимых конфигураций |
| Регулятор требует обоснование мер, а его нет | Связки «угроза → требование → мера → доказательство» |
Проект как основа закупки и приёмки
HLD и LLD — не только инженерные документы. Они закрывают две коммерческие задачи.
Закупка. Спецификация из HLD позволяет сравнивать предложения по существу, а не по итоговой сумме: видно, что входит в поставку, какие лицензии нужны, что потребуется докупить через год. Поставку сертифицированных средств защиты и СКЗИ мы выполняем в рамках решения «Поставка средств защиты информации»; передача СКЗИ требует лицензии ФСБ — она у РЕСТАРТ есть (подробнее).
Приёмка. Программа испытаний, выросшая из перечня требований, превращает приёмку из спора в процедуру: каждое требование либо проверено, либо явно перенесено. Это же основа для последующих проверок регулятора — доказательства собраны заранее, а не восстанавливаются задним числом.
Дальше проект переходит во внедрение — «Внедрение СЗИ», а сетевая часть детализируется в сетевой безопасности и защите периметра.
Когда проект обязателен по нормативу
- Значимые объекты КИИ. Создание системы безопасности значимого объекта по 187-ФЗ предполагает проектирование с обоснованием мер и последующую приёмку — см. «Защита КИИ / 187-ФЗ».
- Информационные системы персональных данных. Выбор мер защиты опирается на определённый уровень защищённости и модель угроз; без документов обоснование мер не построить — «152-ФЗ и персональные данные».
- Государственные информационные системы. Класс защищённости и состав мер фиксируются на стадии проектирования — «Защита ГИС».
- Работы по лицензии ФСТЭК. Проектирование средств защиты — лицензируемая деятельность; лицензированная практика РЕСТАРТ описана в решении «Регуляторное соответствие и защита информационных систем».
Чек-лист качества HLD и LLD
HLD
- Перечислены объекты защиты и границы системы, они сверены с инвентаризацией.
- Каждому требованию сопоставлена мера, каждой мере — обоснование.
- Есть нефункциональные требования с цифрами, а не с прилагательными.
- Для сертифицированных средств указан требуемый класс и проверено наличие действующего сертификата.
- Спецификация покрывает лицензии, поддержку и срок; сверена с реальным числом узлов и пользователей.
- Принятые риски перечислены явно и кем-то подписаны.
LLD
- По документу посторонний инженер может собрать систему без уточняющих вопросов.
- Указаны интерфейсы, адреса, порты и схемы включения каждого средства.
- Порядок миграции разбит на шаги с критериями перехода и планом отката.
- Есть программа испытаний, покрывающая перечень требований из HLD.
- Описано, куда идут события и как система сопровождается после сдачи.
- Конфигурации хранятся в воспроизводимом виде, а не только в памяти внедренца.
Как это делает РЕСТАРТ
Проектная стадия у нас — отдельное решение «Проектирование СЗИ / HLD и LLD». Логика работы: обследование и комплексный аудит ИБ → модель угроз и перечень требований → HLD с обоснованием и спецификацией → LLD с конфигурациями, миграцией и программой испытаний → внедрение и приёмка по той же программе.
Подбор конкретных продуктов опирается на партнёрскую и вендорскую экосистему, а сложные решения проверяются на стенде Лаборатории ИБ до закупки, а не после.
Нужен разбор конкретного контура — напишите нам.
Обсудим ваш контур
Опишите задачу, текущие системы, ограничения и ожидаемый результат. Мы предложим первый практичный шаг: диагностику, пилот, аудит, дорожную карту или проектную команду.
