2. Системные требования и совместимость

Навигатор разделу:

1. Что необходимо определить до установки

Перед развертыванием Avanpost CA необходимо определить:

1. роль экземпляра CA: корневой, подчиненный или выпускающий;

2. ожидаемое количество действующих и архивных сертификатов;

3. среднюю и пиковую интенсивность выпуска и перевыпуска;

4. ожидаемое количество запросов OCSP;

5. периодичность выпуска CRL и Delta CRL;

6. сроки хранения журналов и данных аудита;

7. используемые криптографические алгоритмы и криптопровайдер;

8. способ защиты закрытого ключа CA;

9. необходимость использования HSM;

10. необходимость хранения секретов в Vault;

11. требования к отказоустойчивости и восстановлению;

12. состав интеграций: Avanpost DS, Microsoft AD, Avanpost FAM, Avanpost PKI, MDM, SIEM и внешние системы;

13. способ установки: нативная установка или контейнерное развертывание;

14. точки публикации AIA, CDP, CRL и OCSP.

2. Расчетные показатели нагрузки

Пояснения к показателям

Средняя интенсивность выпуска рассчитана по формуле:

активные сертификаты × 1,2 / 365 / 24

Коэффициент 1,2 учитывает ежегодное продление, внеплановый перевыпуск, отзыв, замену устройств и умеренный рост инфраструктуры.

Расчетный пик выпуска соответствует обработке 1% всей инфраструктуры за час. Такой пик возможен после длительного простоя, применения новой доменной политики или массового обновления сертификатов.

Аварийный пик соответствует перевыпуску 5% сертификатов за час. Это не постоянная нагрузка, а целевой кратковременный запас для массовой замены сертификатов или ключей.

Средняя нагрузка OCSP рассчитана исходя из 10 проверок статуса одного активного сертификата в сутки. При отсутствии клиентского и серверного кеширования, использовании коротких TLS-сессий или большом количестве сетевых устройств реальная нагрузка может быть в 5–20 раз выше.

Размер CRL рассчитан при доле отозванных, но еще не истекших сертификатов до 10%. Предельное значение содержит запас на расширения CRL, неравномерный отзыв и временный рост количества записей.

Срок хранения журналов является не техническим ограничением CA, а рекомендуемой эксплуатационной политикой. Если действуют отраслевые или регуляторные требования, применяется больший срок.

Резервные копии закрытого ключа CA не должны удаляться по обычной политике резервного копирования. Они хранятся в соответствии с криптографическим регламентом как минимум в течение срока доверия к соответствующему сертификату CA.

Принятые допущения

• средний срок действия сертификата — 12 месяцев;
• за год выпускается примерно 120% от активного объема: продление плюс замена, отзыв и рост;
• расчетный пик выпуска — 1% активных сертификатов в час;
• аварийный кратковременный пик — 5% в час;
• OCSP — в среднем 10 проверок на сертификат в сутки;
• расчетный пик OCSP — примерно 15–20 средних нагрузок;
• доля отозванных, но еще не истекших сертификатов — до 10%;
• одна запись CRL с расширениями занимает ориентировочно 100–150 байт;
• журналы OCSP передаются во внешнюю систему хранения; локально сохраняются только оперативные журналы;
• сертификаты, запросы и служебные данные хранятся в БД не менее пяти лет.

3. Требования к аппаратному обеспечению

Рекомендуемые ресурсы сервера приложения

Требования к диску сервера приложения

• SSD;

• не менее 3 000 IOPS для профилей до 10 000 сертификатов;

• не менее 5 000–10 000 IOPS для профиля до 100 000 сертификатов;

• локальное хранение журналов — не более 14–30 дней;

• долгосрочное хранение журналов должно выполняться в SIEM или централизованной системе журналирования;

• указанный объем не включает архив журналов за весь срок хранения.

Если все OCSP-запросы журналируются локально, к диску рекомендуется дополнительно добавить:

Рекомендуемые ресурсы сервера СУБД

Требования к диску СУБД

• SSD или NVMe;

• для 1 000 сертификатов — не менее 3 000 IOPS;

• для 10 000 сертификатов — не менее 5 000 IOPS;

• для 100 000 сертификатов — не менее 10 000 IOPS;

• задержка записи — желательно не более 5 мс;

• резервные копии должны размещаться вне диска рабочей СУБД;

• необходимо контролировать рост WAL и выполнять регулярное обслуживание PostgreSQL;

• для профиля 100 000 сертификатов рекомендуется выделенный дисковый том под PostgreSQL.

Объем внешнего хранилища резервных копий

Объем рассчитан для полных и инкрементальных копий БД, конфигурации, журналов миграций и PostgreSQL WAL. Криптографические резервные копии и резервные копии HSM рассчитываются отдельно.

Итоговые рекомендуемые профили

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

4. Требования к программному обеспечению

4.1. Серверные операционные системы

Для других Linux-дистрибутивов требуется предварительная проверка совместимости. Минимальные условия: systemd, glibc и системные библиотеки требуемых версий, поддерживаемый PostgreSQL-клиент, возможность установки reverse proxy и криптопровайдера. ARM64, «Эльбрус» и другие архитектуры должны подтверждаться отдельно.

Рекомендуется использовать поддерживаемые производителем ОС версии с установленными обновлениями безопасности.

4.2. Системы управления базами данных

Совместимость конкретной редакции и версии должна быть подтверждена до начала промышленного внедрения.

4.3. Дополнительное программное обеспечение

Для любого каталога, реализующего LDAPv3, возможна протокольная совместимость, но не считается официальной поддержкой. Обязательны испытания схемы, атрибутов, пагинации, referrals, nested groups, TLS, bind, GSSAPI и обработки ошибок.

5. Варианты развертывания

В производственной среде рекомендуется разделять сервер приложения и сервер СУБД. Совмещение компонентов допустимо для демонстрационного или ограниченного тестового контура, если это не противоречит требованиям безопасности и доступности.

6. Криптография и защита ключей

Наличие поддержки криптографического алгоритма не означает автоматического выполнения требований регуляторов. Необходимо отдельно учитывать сертификационный статус ОС, СКЗИ, HSM и других компонентов конкретного решения.

6.7. Экосистема и внешние системы

7. Сетевые требования

Точный перечень направлений и портов определяется выбранными компонентами и настройками. Ниже приведены типовые взаимодействия.

Адреса AIA, CDP и OCSP должны быть доступны проверяющим сторонам в течение всего срока действия выпущенных сертификатов, включая период после остановки или замены выпускающего CA.

8. Эксплуатационные требования

Обязательные требования

• стабильное разрешение DNS-имен;

• синхронизация времени на всех узлах PKI;

• защита административного интерфейса TLS;

• ограничение сетевого доступа к СУБД;

• разграничение административных ролей;

• контроль доступа к шаблонам сертификатов;

• резервное копирование базы данных и конфигурации;

• резервное копирование материалов, необходимых для восстановления CA;

• мониторинг свободного места, состояния сервисов и СУБД;

• контроль сроков действия сертификата CA, OCSP и TLS-сертификатов;

• контроль публикации CRL и Delta CRL;

• централизованный сбор журналов аудита;

• документированная процедура плановой и внеплановой смены ключа CA;

• документированная процедура отзыва сертификата CA при компрометации.

Резервное копирование

В резервное копирование необходимо включить:

• базу данных Avanpost CA, включая следующие объекты данных:

  • настройки AIA, CDP, CRL, OCSP и SCEP;

  • шаблоны сертификатов и политики доступа;

  • конфигурацию интеграций;

  • журналы аудита — в соответствии с политикой хранения;

• конфигурацию приложения;

• конфигурацию Nginx;

• секреты и параметры подключения;

• материалы закрытого ключа CA, если это допускается принятой моделью хранения ключей.

Закрытый ключ CA должен резервироваться только в соответствии с утвержденной криптографической процедурой. Обычное файловое резервное копирование закрытого ключа может быть недопустимо.

9. Рекомендации для производственной среды

Для производственного развертывания рекомендуется:

• размещать приложение и СУБД на отдельных узлах;

• использовать отдельную учетную запись службы с минимальными полномочиями;

• запретить прямой доступ пользователей к серверу приложения;

• публиковать сервисы через reverse proxy;

• использовать TLS для административных и интеграционных соединений;

• ограничить доступ к СУБД только узлами Avanpost CA;

• хранить секреты вне конфигурационных файлов;

• рассмотреть Vault для хранения секретов;

• использовать HSM или Vault для защиты закрытого ключа CA;

• размещать корневой CA в изолированном или offline-контуре, если это предусмотрено архитектурой PKI;

• проверить восстановление из резервной копии;

• контролировать доступность AIA, CDP и OCSP из всех обслуживаемых сегментов.

10. Чек-лист готовности к установке