Определите требования
Сначала фиксируют тип системы, класс защищённости, модель угроз и обязательные меры. Только после этого выбирают редакцию и аппаратную модель.
- Границы системы
- Модель угроз
- Требования регулятора
- Интеграции и журналирование
Сначала исполнение, затем модель
Разделите два решения: какую редакцию программного обеспечения требует проект и на какой платформе она будет работать. Одинаковое название семейства не подтверждает одинаковый состав сертифицированной поставки. Для ПАК сопоставляют аппаратное исполнение и программную версию; для размещения на собственной инфраструктуре отдельно уточняют допустимую среду и эксплуатационные ограничения.
Практический пример выбора: в филиале уже есть виртуальная инфраструктура, но нет отдельного администратора защиты. В таком случае сравнивают не только ресурсы виртуальной машины и аппаратного комплекса, но и ответственность за обновления, восстановление и доступ к консоли при сбое. Это пример методики, а не описание выполненного внедрения.
- Кто обслуживает платформу и кто отвечает за средство защиты
- Как восстанавливается доступ при отказе инфраструктуры
- Какая версия и среда включаются в спецификацию
- Какими документами подтверждается выбранное исполнение
Не смешивайте документы
Сертификат ФСТЭК относится к средству защиты и версии, документы ЕАЭС описывают аппаратную платформу, а реестровая запись подтверждает отдельный правовой статус.
- Сертификат безопасности
- Паспорт ПАК
- Документы аппаратной платформы
- Эксплуатационный комплект
Как проверить комплект до заказа
Заведите строку проверки для каждой позиции спецификации: наименование, версия, исполнение, документ, дата сверки и ответственный. Сопоставляйте сведения документа с конкретной позицией, а не только с логотипом производителя. Если приложение к сертификату или паспорт отсутствует, запросите именно этот материал и зафиксируйте открытый вопрос до согласования комплектации.
В запросе поставщику удобно сразу перечислить: точное исполнение, планируемую версию, схему размещения и требуемый перечень документов. Так ответ будет относиться к вашей конфигурации. Номер сертификата или запись в реестре сами по себе не заменяют проверки применимости к проекту.
- Совпадают ли названия и версии в предложении и документах
- Есть ли приложения, описывающие область действия
- Понятен ли порядок обновления выбранной версии
- Получены ли руководство и паспорт именно выбранного исполнения
Подготовьте приёмку
До поставки согласуют схему, матрицу мер, сценарии испытаний и перечень подтверждающих материалов.
- Программа и методика
- Протокол настроек
- Реестр документов
- План сопровождения
Связь требований, поставки и приёмки
Работу начинают с требований конкретной информационной системы. Из модели угроз и нормативной базы выделяют меры, которые должен обеспечивать межсетевой экран, требования к журналированию, администрированию и контролю целостности. Рядом с каждой мерой указывают проектное решение и подтверждающий документ. Это позволяет увидеть пробел до закупки, а не во время аттестационных работ.
В спецификации поставки фиксируют полное наименование редакции, аппаратную модель, ревизию, состав лицензий, комплект эксплуатационных документов и условия поддержки. Обобщённая запись «NGFW с сертификатом» недостаточна: документы могут относиться к другой версии или исполнению. Актуальность сертификата и область действия проверяют по официальному реестру на дату проектирования и повторно перед поставкой.
Проектная схема должна оставаться в пределах проверяемой конфигурации. Обновление версии, замена аппаратной платформы, подключение внешнего компонента или изменение режима работы оценивают с точки зрения применимости требований и документации. Решение о допустимости принимает ответственная сторона проекта на основании официальных материалов, а не маркетингового описания функции.
Приёмка связывает меру с наблюдаемым тестом. В протоколе указывают команду или действие, ожидаемый результат, журнал и реквизит конфигурации. Отдельно проверяют резервное копирование, восстановление, роли администраторов, синхронизацию времени и передачу событий. Итоговый реестр документов передают эксплуатации вместе со сроками проверки обновлений и ответственными за изменения.
После ввода системы изменения контролируют так же строго, как исходную поставку. Обновление версии, замена узла, продление поддержки и корректировка политики попадают в журнал конфигурации. Перед существенным изменением проверяют актуальность документов и повторяют затронутые испытания, сохраняя доказательства для внутреннего контроля и последующих проверок.
Что зафиксировать
- Матрица требований и мер
- Точное исполнение в спецификации
- Проверка официальных реестров
- Программа и методика испытаний
- Реестр документов и изменений
Практический результат
Выбор IDECO UTM ФСТЭК для проекта: различия ПО и ПАК, проверка версии и сертификата, состав спецификации и вопросы для приёмочных испытаний. Итогом работы должен стать не общий вывод, а согласованный документ: схема, таблица параметров, программа испытаний или план изменений — в зависимости от задачи.
Перед закупкой или обновлением проверьте выводы на собственной топологии и реальном профиле трафика. Производительность, совместимость и состав документов подтверждаются для выбранной версии и аппаратной ревизии.