Postgres Pro 18 Enterprise в очереди на сертификацию ФСТЭК: что это значит для КИИ

На прошлой неделе Postgres Pro опубликовал информацию о том, что Postgres Pro 18 Enterprise подана на сертификацию ФСТЭК. Сертификат пока не выдан - продукт в очереди. Но само начало процедуры уже важное событие для тех, кто эксплуатирует базы данных на объектах КИИ: значит, восемнадцатая версия будет легитимна не только с точки зрения функциональности, но и с точки зрения регуляторных требований.

Поясним, зачем это вообще важно и чем сертифицированная сборка отличается от несертифицированной в контексте реальной эксплуатации.

Реестр отечественного ПО и требование для КИИ

Для объектов критической информационной инфраструктуры обязанность использовать ПО из реестра Минцифры не новость. Приказы и методические рекомендации ФСТЭК дают понять однозначно: программное обеспечение, задействованное в критических сегментах, должно либо присутствовать в реестре отечественного ПО, либо использоваться на основании задокументированного обоснования отсутствия отечественного аналога.

Postgres Pro Enterprise в реестре присутствует давно. Проблема в другом: конкретная версия. Инспекторы на проверках в Q1 этого года уже спрашивали не просто «есть ли отечественная СУБД», а «на какой версии работаете, есть ли сертификат на эту версию». Это сдвиг в детализации, который мы наблюдаем последние несколько месяцев.

До сертификации 18-й версии ситуация была простая: на объектах КИИ де-факто оставались на Postgres Pro 15 или 16 Enterprise - там сертификаты есть, всё чисто с документальной точки зрения. Переходить на 17-ю или 18-ю означало либо принять регуляторный риск, либо ждать.

Чем сертифицированная версия отличается от несертифицированной

Здесь важно не путать два разных понятия: наличие в реестре отечественного ПО и наличие сертификата ФСТЭК. Это разные вещи с разными последствиями.

Реестр Минцифры подтверждает отечественное происхождение продукта. Без записи в реестре продукт не может считаться российским ПО для целей импортозамещения. Postgres Pro 18 Enterprise в реестр попадёт вместе с сертификацией или чуть раньше - это технически одна процедура для вендора.

Сертификат ФСТЭК - это отдельная история. Он подтверждает соответствие требованиям по безопасности: отсутствие недекларированных возможностей, соответствие профилям защиты. Для объектов КИИ первой и второй категории значимости сертификат ФСТЭК на СУБД - это, как правило, обязательное требование в техническом задании на систему защиты.

Практическая разница при эксплуатации: несертифицированная версия технически работает так же. Postgres Pro 18 Enterprise с точки зрения функциональности - это то, о чём мы писали в январе: async I/O, улучшения планировщика, переработанная буферная подсистема. Всё это есть и будет в сертифицированной сборке. Разница не в функциях - она в том, какую документацию вы можете предъявить инспектору и что написано в вашей модели угроз относительно доверенной программной среды.

Сертифицированная сборка имеет ограничение: вендор фиксирует конкретный билд. Патчи выходят, но только в рамках сертифицированной ветки. Это означает, что темп обновлений медленнее, чем в upstream-версии. На практике это компромисс, который в КИИ-среде считается приемлемым: предсказуемость важнее скорости.

Что это значит для тех, кто планирует переход на PG18

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

Несколько практических соображений по подготовке.

• Инвентаризация текущей версии. Какая версия Postgres Pro сейчас на объекте, какой сертификат, до какого срока действует. Сертификаты ФСТЭК не вечны - у некоторых организаций они уже истекают или истекут в ближайшее время, что создаёт дополнительное давление.
• Проверка конфигурационного расхождения. Переход с 15/16 на 18 - это не просто pg_upgrade. В январском посте мы описывали нюансы с autovacuum и io_uring на продакшн-нагрузке. На КИИ-объектах к этому добавляется необходимость перевыпуска документации: модель угроз, технический паспорт, возможно - повторное согласование с регулятором. Это нужно заложить в план.
• Несертифицированный период - это риск, который нужно задокументировать. Если из операционных соображений нужно перейти на PG18 до получения сертификата, это не автоматически запрещено. Но требует: обоснования необходимости, записи в модель угроз, и согласования с куратором от регулятора, если такой есть. Молча обновиться и надеяться, что не заметят, - плохая стратегия в текущей атмосфере проверок.

Где сейчас граница ответственности

На наших аудитах мы периодически видим ситуацию: продукт в реестре есть, сертификат истёк или отсутствует на используемую версию, но в модели угроз и технической документации про это ни слова. Формально это не катастрофа - замечание, которое закрывается документально. Но закрывается только если поднять вопрос самостоятельно, а не когда его поднимет инспектор.

Начало сертификации Postgres Pro 18 Enterprise снимает этот вопрос - но не сразу, а когда сертификат будет выдан. До тех пор ситуация остаётся в зоне «использовать можно, но с документацией». Следим за ходом процедуры.