Что такое HLD
HLD расшифровывается как High-Level Design, то есть проект высокого уровня. В ИБ это архитектурный документ, который объясняет, как должна быть устроена целевая система защиты информации: какие контуры защищаем, где проходят границы доверия, какие классы СЗИ нужны, как разделяются зоны, какие потоки данных критичны и как решение встраивается в существующий ИТ-ландшафт.
HLD не должен превращаться в абстрактную картинку. Его задача — дать CIO, CISO, архитекторам, владельцам систем, закупкам и эксплуатации единое понимание будущего контура до начала закупки и внедрения. На этом уровне фиксируются принципы, зависимости, ограничения, целевая схема и решения, которые потом нельзя незаметно поменять на этапе настройки.
Место HLD в Enterprise-архитектуре
В enterprise-среде HLD находится между стратегией ИБ и детальным техническим проектированием. Он связывает бизнес-процессы, регуляторные требования, модель угроз, ИТ-архитектуру, сетевую сегментацию, IAM/PAM, SOC/SIEM, DevSecOps, ERP, DWH, облака, филиалы, удаленный доступ и эксплуатационные процессы.
Для крупной компании HLD полезен как архитектурный контракт: он показывает, какие системы входят в scope, какие риски закрываются, какие решения должны быть совместимы, какие интеграции обязательны, где нужны пилоты и какие изменения затронут пользователей. Такой документ помогает избежать ситуации, когда СЗИ куплены, но не работают вместе, не дают нужных событий в SIEM, ломают бизнес-процессы или не проходят приемку у эксплуатации.
| Enterprise-слой | Что фиксирует HLD |
|---|---|
| Бизнес и регуляторика | Критичные процессы, применимые требования, ИСПДн, КИИ, ГИС, персональные данные, коммерческая тайна, требования аудита и проверок. |
| ИТ-ландшафт | Системы, контуры, сети, филиалы, облака, интеграции, каналы доступа, точки обмена данными и зависимости от инфраструктуры. |
| ИБ-архитектура | Зоны безопасности, классы СЗИ, модель доступа, журналирование, мониторинг, реагирование, криптография, защита endpoints, web/API и данных. |
| Эксплуатация | Роли, процессы изменений, требования к мониторингу, SLA/OLA, сопровождение, резервирование, обновления и контроль эффективности. |
Что такое LLD
LLD расшифровывается как Low-Level Design, то есть проект низкого уровня или детальный технический проект. Если HLD отвечает на вопрос «как должен быть устроен контур», то LLD отвечает на вопрос «как именно это будет собрано, настроено, подключено и принято».
В LLD появляются конкретные компоненты, версии, сетевые интерфейсы, адресация, правила межсетевого взаимодействия, интеграции с каталогами, SIEM, ITSM, PAM, сканерами, EDR/XDR, WAF, DLP, СКЗИ, политиками доступа, журналами и резервным копированием. Для команды внедрения LLD становится рабочей инструкцией, для эксплуатации — будущей документацией, а для приемки — основанием проверить, что решение действительно соответствует архитектуре.
Место LLD в Enterprise-архитектуре
LLD живет ближе к внедрению и промышленной эксплуатации. Он переводит архитектурные решения в конфигурации, правила, параметры, чек-листы, миграционные шаги и acceptance criteria. В enterprise-ландшафте это особенно важно, потому что одна настройка может затронуть сеть, доменную структуру, бизнес-приложение, мониторинг, службу поддержки и регуляторную отчетность.
Хороший LLD не ограничивается перечнем настроек продукта. Он описывает, как решение будет существовать в реальной операционной модели: кто администрирует политики, кто получает события, как обрабатываются исключения, как обновляются правила, где хранятся журналы, как выполняется rollback, что считается успешной приемкой и какие метрики показывают, что защита работает.
| Практический слой | Что фиксирует LLD |
|---|---|
| Компоненты | Серверы, агенты, сенсоры, шлюзы, политики, версии, роли, учетные записи, сертификаты и зависимости. |
| Сеть и интеграции | IP/FQDN, порты, маршруты, firewall rules, API, syslog, webhooks, очереди, подключение к AD/LDAP, SIEM, ITSM и хранилищам. |
| Настройки ИБ | Политики доступа, исключения, профили сканирования, use cases, correlation rules, уровни журналирования, retention и правила реагирования. |
| Приемка и эксплуатация | Пошаговый план внедрения, тесты, негативные сценарии, rollback, runbook, инструкции администраторов и критерии передачи в поддержку. |
HLD и LLD: сравнение
HLD и LLD не конкурируют друг с другом. Это два уровня одного проектирования: HLD нужен, чтобы согласовать целевую архитектуру и управленческие решения, LLD — чтобы безопасно и проверяемо реализовать их в инфраструктуре.
| Критерий | HLD / High-Level Design | LLD / Low-Level Design |
|---|---|---|
| Главный вопрос | Как должна быть устроена целевая архитектура защиты? | Как именно ее внедрить, настроить и принять? |
| Аудитория | CIO, CISO, enterprise-архитекторы, владельцы систем, закупки, проектный офис. | Инженеры внедрения, администраторы, эксплуатация, SOC, DevOps/DevSecOps, тестирование. |
| Уровень детализации | Контуры, зоны, классы решений, принципы, потоки, зависимости и ограничения. | Компоненты, параметры, адреса, правила, политики, интеграции, тесты и runbook. |
| Риск без документа | Купили не то, не учли зависимости, получили конфликт архитектуры и дорогую переделку. | Внедрили по-разному в разных командах, потеряли настройки, не смогли принять и поддерживать решение. |
| Результат | Согласованная целевая архитектура и рамка проекта. | Рабочий технический проект для внедрения и эксплуатации. |
Когда HLD/LLD действительно нужны
HLD и LLD особенно важны, когда проект затрагивает несколько систем, команд и требований: внедрение СЗИ, модернизацию периметра, защиту ИСПДн, КИИ или ГИС, запуск SOC/SIEM/SOAR, PAM/IDM, DLP, WAF, EDR/XDR, СКЗИ, DevSecOps, защиту API, AI-контур, филиальную сеть или критичные интеграции.
Если проект небольшой, можно начинать с облегченного HLD и короткого LLD. Если контур регулируемый, критичный или распределенный, экономия на проектировании почти всегда возвращается переделками: конфликтами политик, неполными событиями в SIEM, ошибками доступа, непринятыми исключениями, ручными обходами и спором между ИТ, ИБ и подрядчиками.
Как РЕСТАРТ ведет проектирование
Scope и обследование
Фиксируем бизнес-задачу, регуляторику, границы контура, системы, сети, роли, данные, текущие СЗИ, ограничения и точки боли эксплуатации.
Архитектура HLD
Описываем целевую модель защиты, зоны, классы решений, потоки, интеграции, требования к инфраструктуре, риски и варианты архитектурных решений.
Детализация LLD
Готовим настройки, схемы взаимодействия, матрицы доступа, правила, требования к журналам, тестовые сценарии, план внедрения и rollback.
Приемка и передача
Согласуем критерии готовности, проводим ревью с ИТ/ИБ/эксплуатацией, готовим runbook, backlog внедрения и рекомендации по развитию.
Артефакты результата
- HLD-документ с целевой архитектурой, зонами, потоками, классами СЗИ, зависимостями и архитектурными решениями;
- LLD-документ с компонентами, настройками, интеграциями, сетевыми правилами, матрицами доступа, журналированием и тестами;
- архитектурные схемы: контуры, сегментация, потоки данных, каналы администрирования, события в SIEM/SOC, интеграции с IAM/PAM/ITSM;
- матрица требований: регуляторика, модель угроз, бизнес-риски, требования эксплуатации и критерии приемки;
- roadmap внедрения: этапы, зависимости, пилоты, rollback, миграция, обучение, передача в сопровождение и backlog развития.
Связь с внедрением и эксплуатацией
Проектирование имеет смысл только тогда, когда по нему можно внедрять и поддерживать систему. Поэтому РЕСТАРТ связывает HLD/LLD с подбором вендоров, пилотом, закупкой, внедрением, настройкой политик, интеграцией с SIEM/SOC, обучением администраторов и передачей в эксплуатацию.
После проектирования команда может перейти к внедрению СЗИ, поставке лицензий, настройке, тестированию, разработке регламентов, опытной эксплуатации и сопровождению. Если у заказчика уже есть часть решений, HLD/LLD помогает не перепокупать весь стек, а встроить новые меры защиты в существующую архитектуру.
Частые вопросы
Можно ли делать LLD без HLD?
Технически можно, но в enterprise-проектах это рискованно: команда быстро уйдет в настройки продукта, не согласовав зоны, границы ответственности, потоки данных и требования эксплуатации.
HLD — это только схема?
Нет. Схема важна, но HLD также фиксирует архитектурные решения, требования, зависимости, ограничения, классы СЗИ, риски, принципы интеграции и критерии готовности.
Кто должен согласовывать HLD и LLD?
HLD обычно согласуют CISO, ИТ-архитектура, владельцы систем и эксплуатация. LLD дополнительно проходит инженерное ревью у администраторов, SOC, DevOps/DevSecOps и команды внедрения.
Что важнее для проверки: HLD или LLD?
Для проверки важны оба уровня. HLD показывает обоснованность архитектуры и мер защиты, LLD доказывает, что меры реализованы конкретно, проверяемо и управляемо.
Можно ли использовать документы для закупки?
Да. HLD помогает сформировать требования к классам решений и интеграциям, а LLD уточняет объем внедрения, работы подрядчика, критерии приемки и ограничения по эксплуатации.
Что делать, если СЗИ уже куплены?
Можно начать с архитектурного ревью: проверить, какие решения уже закрывают риски, где есть дублирование, какие интеграции не реализованы и что нужно донастроить до промышленной модели.
Обсудим ваш контур
Опишите задачу, текущие системы, ограничения и ожидаемый результат. Мы предложим первый практичный шаг: диагностику, пилот, аудит, дорожную карту или проектную команду.
