Перейти к содержанию

Политика безопасного применения ГОСТ: уровни, доверие и эксплуатация

Наличие ГОСТ-алгоритма в ОС не означает, что произвольная комбинация алгоритмов безопасна. Реальную защиту обеспечивает полный профиль: ключевой материал, генерация случайных значений, правильный режим, формат сообщений, аутентификация участников и реакция на ошибки.

Шесть обязательных границ безопасности

  1. Выбор алгоритма и режима. Сверьте назначения: подпись для подлинности, хэш для дайджеста, MGM для AEAD, XTS для конфиденциальности секторов. Не подменяйте одно другим.
  2. Материал ключа. Генерация из надёжного источника, уникальные ключи/параметры, защищённое хранение, журналирование без секретов, своевременная ротация.
  3. Nonce и IV. Уникальность/непредсказуемость по требованиям каждого режима, учёт потери состояния после перезагрузки и риска повторного значения. Не выводите общую «достаточную длину nonce» без выбранного протокола.
  4. Доверие PKI. Сертификаты проверяются по цепочке, идентичности, назначению, срокам и статусу CRL/OCSP. Источник CRL должен иметь контролируемую доступность и правильную проверку подписи.
  5. Защита на границах. Для IPsec необходимы корректные маршруты и fail-closed политики, исключающие обход туннеля. Для HTTPS — проверка имени и CA; для CMS — проверка точного подписанного содержания.
  6. Изменения и откат. Патч RPM, смена криптобиблиотеки и обновление ОС требуют regression tests на совместимость и отказ; наличие рабочей старой SA не доказывает успешный новый IKE_AUTH.

Особое значение отказа при недоступной инфраструктуре

Политика strict revocation предполагает, что при невозможности определить действительный статус сертификата новая аутентификация не завершается успехом, если нет других допустимых источников/кэшей согласно политике. Однако она не эквивалентна мгновенной блокировке ранее установленного сеанса. В НАЙС.ОС 5.2 подтверждены отрицательные тесты локальной CRL и HTTPS-сбоя в charon; автоматическое отключение всех действующих SA по событию отзыва требует отдельного проекта.

План валидации политики

[Формальный профиль стандартов]
               |
  [Установленная реализация RPM]
               |
    [Проверка нормального обмена]
               |
    [Нарушение доверия/подписи/nonce/сети]
               |
    [Подтверждённый отказ + отсутствие обхода]
               |
      [Восстановление + аудит]

Проводите отрицательные испытания только на лабораторном стенде: отключение CA, CRL или туннеля на действующем производственном сервере может привести к отказу доступности. При проверке не публикуйте закрытые ключи, PSK и содержимое защищённых сообщений. Предусмотрите ротацию доверенных CA и долгосрочное хранение открытых подтверждающих данных.

Разграничение продуктовых и нормативных утверждений

  • Нормативная совместимость: выбранный документ определяет требования; это не запись о выполненном тесте.
  • Функциональная поддержка: конкретная версия RPM выполнила положительный и отрицательный сценарий.
  • Межвендорная совместимость: обмен подтверждён между двумя разными реализациями.
  • Регуляторный статус: определяется отдельной процедурой сертификации; данная документация его не устанавливает.

Страницы по темам: режимы/AEAD, X.509/OCSP/CRL, IKEv2, PFX, проверка статуса источников, правила безопасности алгоритмов, матрица испытаний.

Источники

ГОСТ и рекомендации ТК26 · RFC 9058 — MGM · RFC 5280 — PKIX · RFC 9385 — IKEv2 ГОСТ · RFC 9367 — TLS ГОСТ · RFC 9906 — вывод ECC-GOST DNSSEC.