ППО в защищенном исполнении: что нужно знать перед сертификацией

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

Что важно понимать на старте?

В практике сертификации важно разграничивать два понятия: сертификация и аттестация. Сертификат соответствия и аттестат соответствия — это два разных документа, отражающих разные процессы. Сертификация подтверждает соответствие конкретного средства защиты информации (СЗИ) установленным требованиям. Аттестация — оценивает систему защиты объекта информатизации в целом в условиях эксплуатации.

Если вы разрабатываете ППО или уже используете его в критических инфраструктурах (АСУ ТП, ИСПДн, КИИ и пр.), вопрос сертификации встроенных механизмов защиты — это не «может быть», а необходимость.

Когда встраивать защиту?

Наиболее частые сценарии:

• ПО уже в эксплуатации, а защита реализована на уровне логики. Нужно определить — насколько она соответствует нормативке;
• Разработка «с нуля», при которой необходимо изначально проектировать встроенные средства защиты;
• Невозможность использования готовых СЗИ — например, в узкоспециализированных решениях или при высоких требованиях к производительности;
• Негативное влияние СЗИ на систему — типичный кейс, когда наложенные средства защиты перегружают ИТ-инфраструктуру, мешают технологическим процессам, увеличивают стоимость сопровождения.

Здесь и появляется интерес к сертификации ППО в защищенном исполнении — с собственной встроенной безопасностью без необходимости внешних СЗИ.

А как быть с Open Source?

Регулятор не запрещает использование свободно распространяемого ПО (СРПО), более того — в ряде случаев оно становится технологическим фундаментом решений. Главное — провести корректную инвентаризацию компонентов, реализовать необходимые механизмы безопасности и оформить все документально. Это важно при подаче заявки.

Среди часто сертифицируемых решений на основе СРПО — операционные системы, СУБД, системы виртуализации и мониторинга, а также решения в сфере финтеха.

Как выбрать подходящую схему сертификации?

Выбор зависит от жизненного цикла и масштаба продукта. Существует три схемы:

• Единичный экземпляр — подходит для уникальных внедрений, бессрочен, но без права тиража.
• Партия — ограниченное количество экземпляров, сертификат до 5 лет.
• Серийное производство — самый сложный и затратный путь, но дает максимальные возможности для масштабирования и коммерческого распространения.

Важные шаги перед сертификацией

1. Проверить соответствие реализованных механизмов защиты нормативным требованиям. Наиболее часто применяемые: приказы ФСТЭК №17, №21, №31, №239.
2. Подготовить техническую документацию. Особое внимание — требованиям технических условий (ТУ), описанию реализуемых механизмов и заданию по безопасности (ЗБ), если есть профиль защиты.
3. Выбрать испытательную лабораторию. Критерии: опыт, количество успешных заключений, логистика и готовность к диалогу.
4. Сформировать комплект заявки. Включая перечень СРПО, если используется, с указанием источников, версий и модификаций.

Какие функции защиты нужно реализовать в ППО?

В топе наиболее востребованных:

• Идентификация и аутентификация (ИАФ).
• Управление доступом (УПД).
• Ограничение программной среды (ОПС).
• Регистрация событий безопасности (РСБ).
• Обеспечение целостности информации (ОЦЛ).

Криптографическая защита в данной статье не рассматривается — это отдельный пласт, требующий взаимодействия с ФСБ России.

Финальное резюме

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