Сертификаты TLS

Содержание

Сертификаты TLS#

На этом шаге настройте компоненты платформы на использование сертификатов TLS.

Сертификаты TLS используются для обеспечения защищенного взаимодействия между компонентами платформы Astra Automation и внешними клиентами по протоколу HTTPS.

При установлении соединения сертификат TLS выполняет две ключевые функции:

подтверждает подлинность сервера, к которому подключается клиент;
обеспечивает безопасное согласование параметров шифрования.

Каждый серверный компонент платформы (Platform Gateway, Automation Controller, Private Automation Hub, Event-Driven Automation) должен иметь:

серверный сертификат;
соответствующий закрытый ключ.

Если сертификаты выпущены удостоверяющим центром, компоненты платформы должны иметь доступ к сертификату удостоверяющего центра.

В Astra Automation доступ по TLS настраивают через специальные переменные в описании инвентаря, используемом в процессе развертывания.

Типы поддерживаемых сертификатов#

Платформа Astra Automation поддерживает три модели использования сертификатов TLS, отличающиеся источником доверия и областью применения.

Сертификаты публичного удостоверяющего центра (Public CA)#

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

Примеры таких удостоверяющих центров: Let’s Encrypt, DigiCert, GlobalSign.

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

Этот вариант рекомендуется использовать:

для промышленной эксплуатации;
для систем с публичным доступом;
для систем, к которым подключаются внешние пользователи или внешние сервисы.

Преимущества:

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

Сертификаты корпоративного удостоверяющего центра (Corporate CA)#

Такие сертификаты выпускаются внутренним удостоверяющим центром организации, который используется для построения корпоративной инфраструктуры доверия. В этом случае организация самостоятельно управляет выпуском сертификатов, сроками их действия и политиками безопасности.

Так как корпоративный удостоверяющий центр не является публичным, клиентские системы должны явно доверять ему. Для этого корневой сертификат удостоверяющего центра устанавливается в доверенное хранилище операционной системы или приложения.

Этот вариант рекомендуется использовать:

для внутренних корпоративных систем;
для закрытых инфраструктур;
при наличии собственной инфраструктуры PKI.

Преимущества:

полный контроль над инфраструктурой сертификатов;
отсутствие зависимости от внешних удостоверяющих центров;
соответствие корпоративным политикам безопасности.

Сертификаты собственного удостоверяющего центра (Self-signed CA)#

В этом сценарии удостоверяющий центр создается администратором вручную или автоматически установщиком платформы Astra Automation. Этот удостоверяющий центр используется для выпуска серверных сертификатов компонентов платформы.

Такой удостоверяющий центр не является публичным и требует явной настройки доверия на клиентских системах.

Этот вариант используется для тестирования, разработки, в лабораторных и изолированных средах.

Примечание

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

Применение сертификатов от публичного удостоверяющего центра#

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

Пример описания инвентаря для сертификатов от публичного удостоверяющего центра, например Let’s Encrypt:

[all:vars]
# SSL certificate settings for public CA
# No custom_ca_cert required for public CA certificates

# Platform Gateway SSL certificate
automationgateway_ssl_cert=/etc/letsencrypt/live/gateway.example.com/fullchain.pem
automationgateway_ssl_key=/etc/letsencrypt/live/gateway.example.com/privkey.pem

# Automation Controller SSL certificate
web_server_ssl_cert=/etc/letsencrypt/live/controller.example.com/fullchain.pem
web_server_ssl_key=/etc/letsencrypt/live/controller.example.com/privkey.pem

# Automation Hub SSL certificate
automationhub_ssl_cert=/etc/letsencrypt/live/hub.example.com/fullchain.pem
automationhub_ssl_key=/etc/letsencrypt/live/hub.example.com/privkey.pem

# Event-Driven Automation SSL certificate
automationedacontroller_ssl_cert=/etc/letsencrypt/live/eda.example.com/fullchain.pem
automationedacontroller_ssl_key=/etc/letsencrypt/live/eda.example.com/privkey.pem

Особенности применения публичных сертификатов:

используйте файл, например, fullchain.pem, который содержит серверный сертификат и цепочку промежуточных сертификатов;
переменная custom_ca_cert не требуется, так как корневые CA уже доверяются системой;
сертификаты имеют ограниченный срок действия (например, 90 дней);
требуется автоматизированное обновление сертификатов.

Применение сертификатов корпоративного удостоверяющего центра#

При использовании сертификатов, выпущенных корпоративным удостоверяющим центром, необходимо указать пути к следующим файлам:

серверные сертификаты компонентов платформы;
соответствующие закрытые ключи;
сертификат удостоверяющего центра, которому должна доверять платформа.

Пример описания инвентаря:

[all:vars]
# Certificate Authority certificate (root and/or intermediate)
custom_ca_cert=/path/to/corporate-ca-chain.crt

# Platform Gateway certificate and key
automationgateway_ssl_cert=/path/to/gateway.corp.example.com.crt
automationgateway_ssl_key=/path/to/gateway.corp.example.com.key

# Automation Controller certificate and key
web_server_ssl_cert=/path/to/controller.corp.example.com.crt
web_server_ssl_key=/path/to/controller.corp.example.com.key

# Automation Hub certificate and key
automationhub_ssl_cert=/path/to/hub.corp.example.com.crt
automationhub_ssl_key=/path/to/hub.corp.example.com.key

# Event-Driven Automation certificate and key
automationedacontroller_ssl_cert=/path/to/eda.corp.example.com.crt
automationedacontroller_ssl_key=/path/to/eda.corp.example.com.key

Разделение ролей сертификатов#

В корпоративной инфраструктуре PKI серверный сертификат и сертификат удостоверяющего центра выполняют разные функции и должны указываться отдельно.

Серверный сертификат (переменные automationgateway_ssl_cert, web_server_ssl_cert, automationhub_ssl_cert, automationedacontroller_ssl_cert) обладает следующими особенностями:

используется для идентификации конкретного компонента платформы;
применяется сервером при установлении соединений TLS;
должен содержать серверный сертификат компонента и цепочку промежуточных сертификатов (если используются);
не должен содержать корневой сертификат удостоверяющего центра.

Пример корректного содержимого серверного сертификата:

-----BEGIN CERTIFICATE-----
[Server Certificate]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Intermediate CA Certificate]
-----END CERTIFICATE-----

Переменная custom_ca_cert используется для передачи цепочки сертификатов удостоверяющего центра, которым должна доверять платформа. Этот файл используется для следующих целей:

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

Файл, путь к которому передается через переменную custom_ca_cert, должен содержать следующие сертификаты:

корневой сертификат удостоверяющего центра;
при необходимости – промежуточные сертификаты.

Пример содержимого:

-----BEGIN CERTIFICATE-----
[Intermediate CA Certificate]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Root CA Certificate]
-----END CERTIFICATE-----

Внимание

Корневой сертификат удостоверяющего центра должен указываться только в переменной custom_ca_cert и не должен включаться в серверный сертификат.

Серверный сертификат используется для идентификации компонента, а custom_ca_cert – для установления доверия. Эти файлы имеют различное назначение и не являются взаимозаменяемыми.

Проверка корректности цепочки сертификатов#

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

openssl verify -CAfile /path/to/custom_ca_cert /path/to/server_cert.crt

При корректной конфигурации команда должна вернуть статус OK:

/path/to/server_cert.crt: OK

Если проверка завершается ошибкой, убедитесь в следующем:

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

Использование собственного удостоверяющего центра#

Платформа Astra Automation может использовать сертификаты, выпущенные собственным удостоверяющим центром. Доступны следующие варианты использования:

Удостоверяющий центр, созданный администратором.

Пример описания инвентаря для первого случая:

[all:vars]
# SSL certificate settings for self-signed certificates

# Custom CA certificate (self-signed root)
custom_ca_cert=/path/to/self-signed-ca.crt

# Platform Gateway SSL certificate and key
automationgateway_ssl_cert=/path/to/gateway.local.example.com.crt
automationgateway_ssl_key=/path/to/gateway.local.example.com.key

# Automation Controller SSL certificate and key
web_server_ssl_cert=/path/to/controller.local.example.com.crt
web_server_ssl_key=/path/to/controller.local.example.com.key

# Automation Hub SSL certificate and key
automationhub_ssl_cert=/path/to/hub.local.example.com.crt
automationhub_ssl_key=/path/to/hub.local.example.com.key

# Event-Driven Automation SSL certificate and key
automationedacontroller_ssl_cert=/path/to/eda.local.example.com.crt
automationedacontroller_ssl_key=/path/to/eda.local.example.com.key

# Alternative: Regenerate all self-signed certificates automatically
# aap_service_regen_cert=true

Удостоверяющий центр, автоматически созданный платформой.

Во этом случае ручная подготовка и указание сертификатов не требуется – они создаются и настраиваются автоматически установщиком (см. описание использования переменной aap_service_regen_cert ниже).

Если в дальнейшем потребуется регенерация самозаверенных сертификатов, то используйте переменную aap_service_regen_cert при повторном запуске aa-setup:

[all:vars]
# Automatically regenerate self-signed certificates for all services
aap_service_regen_cert=true

Этот вариант требует всего лишь одну строку настройки. Созданные таким образом сертификаты имеют следующие особенности и ограничения в применении:

простота развертывания: автоматически создаются утилитой установки при указании aap_service_regen_cert=true без требования ручной генерации, предварительной подготовки файлов или знания команд OpenSSL;
комплексное покрытие: генерируются для всех компонентов платформы одновременно (Platform Gateway, Automation Controller, Private Automation Hub, Event-Driven Automation) с единым корневым сертификатом CA и автоматическим размещением в соответствующих каталогах;
гибкость управления: могут быть перегенерированы в любое время повторным запуском утилиты установки с тем же параметром, что обеспечивает простое обновление при необходимости;
оптимизация для тестирования: используют стандартные параметры шифрования с достаточно длительным сроком действия, автоматически включают необходимые Subject Alternative Names (SAN) и подходят для изолированных тестовых сред;
надежность конфигурации: обеспечивают консистентность параметров шифрования между всеми компонентами и позволяют избежать ошибок, связанных с неправильными путями к файлам или форматами сертификатов.

Процесс подготовки#

На этом этапе выполните следующие подготовительные действия, если не используется режим автоматической регенерации:

Подготовьте сертификаты и ключи согласно выбранному типу.
Скопируйте файлы на установочный узел.
Настройте переменные в файле инвентаря.