Межсервисное взаимодействие в КриптоПро Ключ

См. также:

В данном разделе рассмотрены межсервисные взаимодействия, возникающие между следующими компонентами КриптоПро Ключ:

  • Сервис Подписи (СП),
  • Центр Идентификации (ЦИ),
  • Сервис Аудита (СА),
  • Сервис Обработки Документов (СОД),
  • Сервис Взаимодействия с SDK (MDAG),
  • Сервис PUSH-уведомлений (PushSrv),
  • Веб-интерфейс пользователя (Frontend).

Все компоненты публикуются в виде веб-приложений на веб-сервере cpnginx.

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

Взаимодействие Протокол 2-TLS/LocalPort Назначение
СП -> СОД HTTP/HTTPS Разрешено Скачивание и загрузка документов
ЦИ -> СОД HTTP/HTTPS Разрешено Скачивание и загрузка документов
ЦИ -> Аудит HTTP/HTTPS Разрешено Контроль работы аудита
СП -> ЦИ HTTP/HTTPS Разрешено Оповещение пользователей
ЦИ -> ЦИ HTTP/HTTPS Разрешено Оповещение пользователей
СОД -> ЦИ HTTP/HTTPS Разрешено Оповещение пользователей
СП -> Аудит HTTP/HTTPS Нет Запись событий аудита
ЦИ -> Аудит HTTP/HTTPS Нет Запись событий аудита
СОД -> Аудит HTTP/HTTPS Нет Запись событий аудита
MDAG ->| ЦИ HTTPS Нет Взаимодействие с МП
MDAG ->| СП HTTPS Нет Взаимодействие с МП
MDAG ->| СОД HTTPS Нет Взаимодействие с МП
MDAG ->| Аудит HTTPS Нет Взаимодействие с МП
Frontend ->| ЦИ HTTPS Нет Протокол OAuth
Frontend ->| ЦИ HTTPS Нет Управление УЗ
Frontend ->| СП HTTPS Нет Доступ к API СП
Frontend ->| СОД HTTPS Нет Скачивание и загрузка документа
Frontend ->| Аудит HTTPS Нет Получение событий аудита

Обозначения:

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

Разделение взаимодействий на локальные и внешние является рекомендуемым, но не обязательным, оно отражает общепринятую практику развертывания компонентов продукта КриптоПро Ключ, при которой приложения, доступные из внешних сетей (MDAG и Frontend), располагаются на отдельных физических серверах в выделенной DMZ.

Локальные взаимодействия могут использовать как защищенное соединение (HTTPS), так и незащищенное (HTTP). Защищенные соединения могут дополнительно требовать аутентификацию отправителя с помощью TLS-соединения с двусторонней аутентификацией (2-TLS). Следует иметь в виду, что использование HTTPS (отдельно или вместе с 2-TLS) создает существенно большую нагрузку на вычислительные ресурсы сервера, что в условиях локальных взаимодействий, при которых передаваемые данные не покидают пределов физических серверов, является нецелесообразным.

Существует два параметра, регулирующих безопасность внутреннего межсервисного взаимодействия (кроме записи событий аудита): требование локального порта (RequiredLocalPort) и требование TLS-аутентификации (RequireServiceAuthentication). Комбинация этих параметров позволяет организовать следующие варианты взаимодействия:

1. Без аутентификации по HTTP/HTTPS.

2. Без аутентификации по HTTP/HTTPS с ограничением порта.

3. C 2-TLS аутентификацией по HTTPS.

4. C 2-TLS аутентификацией по HTTPS с ограничением порта.

Сценарий (1) не требует дополнительных настроек со стороны администратора, сценарий (4) является комбинацией сценариев (2) и (3) и с практической точки зрения нецелесообразен. В сценариях (1) и (2) использование HTTPS не является обязательным.

Пример настройки без аутентификации по HTTP/HTTPS с ограничением порта

Рассмотрим настройку сервисов в режиме (2). Этот случай описывает сценарий межсервисного взаимодействия в пределах одного физического сервера по незащищенному каналу (HTTP) без аутентификации. В рамках данного сценария необходимо настроить фиксированный локальный порт для приема входящих запросов и исключить внешние обращения. Для этого на веб-сервере требуется выделить отдельный порт прослушивания. Пусть для примера это будет порт 4435. В конфигурации cpnginx следует добавить секцию server со следующим содержимым:

...
server {
 listen 127.0.0.1:4435;
 include /etc/opt/cprokey/docsrv/DocumentStore/nginx.conf;
 include /etc/opt/cprokey/idsrv/STS/nginx.conf;
 include /etc/opt/cprokey/auditsrv/Audit/nginx.conf;
 }
 ...

Данная настройка ограничивает доступ на порт 4435 только для обращений с самого сервера (127.0.0.1).

Далее требуется настроить требование фиксированного локального порта в настройках сервисов при помощи командлета Set-{компонент}Properties.

Сервис Имя сервиса в командлете
Сервис Подписи Sign
Центр Идентификации Ids
Сервис Обработки Документов Ds
Сервис Аудита Audit
Сервис PUSH-уведомлений Push

Пример

Set-IdsProperties -RequiredLocalPort 4435
Set-DsProperties -RequiredLocalPort 4435
Set-AuditProperties -RequiredLocalPort 4435

Пример настройки с 2-TLS аутентификацией по HTTPS

Рассмотрим настройку сервисов в режиме (3). Для этого в cpnginx необходимо выделить порт, требующий 2-TLS:

server {
 listen 4435;
 include /etc/opt/cprokey/docsrv/DocumentStore/nginx.conf;
 include /etc/opt/cprokey/idsrv/STS/nginx.conf;
 include /etc/opt/cprokey/auditsrv/Audit/nginx.conf;
...
 sspi on;
 ...
 sspi_verify_client on;
 sspi_client_certificate root;
 ...
 }
 ...

Указание директивы sspi_verify_client включает требование двусторонней аутентификации для TLS-соединения.

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

Далее необходимо добавить сервисные сертификаты в дsоверенные в целевом сервисе. Для компонентов Сервиса Обработки Документов и Сервиса Аудита это делается с помощью команд Add-DsClaimsProviderTrust и Add-AuditClaimsProviderTrust соответственно. Для Центра Идентификации доверенные сертификаты добавляются через команду Set-IdsRelyingPartyTrust -AuthenticationCertificate.

Пример

Add-DsClaimsProviderTrust -IssuerName signserver -Certificate (Get-SignServiceCertificate -Primary).Certificate
Add-DsClaimsProviderTrust -IssuerName idsrv -Certificate (Get-IdsServiceCertificate -Primary -Usage Service-Communications).Certificate
Add-AuditClaimsProviderTrust -IssuerName idsrv -Certificate (Get-IdsServiceCertificate -Primary -Usage Service-Communications).Certificate
Set-IdsRelyingPartyTrust -Id 1 -AuthenticationCertificate (Get-SignServiceCertificate -Primary).Certificate

Сервисные сертификаты

Сервисные X509-сертификаты необходимы компонентам СЭП для организации между ними защищенного TLS-соединения с двусторонней аутентификацией, для защиты ключей шифрования cookie и других задач, характерных для конкретного компонента.

Типы сервисных сертификатов

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

Управление сервисными сертификатами

Для управления сервисными сертификатами существует отдельный набор командлетов Get/Set/Add/Remove/New-*ServiceCertificate, где * - имя соответствующего сервиса.

Сервис Имя сервиса в командлете
Сервис Подписи Sign
Центр Идентификации Ids
Сервис Обработки Документов Ds
Сервис Аудита Audit
Сервис PUSH-уведомлений Push

Далее в примерах используются командлеты для настройки Сервис Подписи (Sign).

Примечание

Хранение сервисных сертификатов возможно следующими способами:

  • в PFX в конфигурации сервиса,
  • в хранилище Личное локального компьютера (mMy).

Для работы с хранилищем требуются права локального администратора.

Получение списка сервисных сертификатов

Для получения списка сервисных сертификатов используется командлет Get-SignServiceCertificate.

Get-SignServiceCertificate [-Thumbprint <string>] [-DisplayName {SignServer}] [<CommonParameters>]

Параметры:

  • Thumbprint - отпечаток SHA-1 сервисного сертификата. Если параметр не задан, то выводится список всех сервисных сертификатов.
Get-SignServiceCertificate -Primary [-DisplayName {SignServer}] [<CommonParameters>]

Параметры:

  • Primary - switch-параметр, указывающий, что следует возвратить в ответе только первичный сертификат.

Добавление сертификатов

Для добавления сервисных сертификатов используется командлет Add-SignServiceCertificate.

Add-SignServiceCertificate -Thumbprint <string> [-Primary] [-PassThru] [-DisplayName {SignServer}] [<CommonParameters>]

Данный набор параметров используется для добавления сертификатов из хранилища LocalMachine/My.

Параметры:

  • Thumbprint - SHA-1-отпечаток сертификата.
  • Primary - опциональный switch-параметр, показывающий, что сертификат должен быть добавлен в качестве первичного сервисного сертификата. Если данный параметр не указан, то сертификат будет добавлен в качтестве вторичного. Если сертификат является первым добавляемым сервисным сертификатом, то он будет добавлен в качестве первичного независимо от наличия параметра -Primary.
  • PassThru Передать объект в pipeline.
Add-SignServiceCertificate -FilePath <string> [-Password <string>] [-Primary] [-PassThru] [-DisplayName {SignServer}] [<CommonParameters>]

Данный набор параметров позволяет добавить сервисный сертификат из PFX файла.

Параметр:

  • FilePath - полный путь к файлу, содержащему данные сертификата в формате PFX.
  • Password - пароль для защиты PFX.
  • Primary - опциональный switch-параметр, показывающий, что сертификат должен быть добавлен в качестве первичного сервисного сертификата. Если данный параметр не указан, то сертификат будет добавлен в качтестве вторичного. Если сертификат является первым добавляемым сервисным сертификатом, то он будет добавлен в качестве первичного, независимо от наличия параметра -Primary.
  • PassThru Передать объект в pipeline.

Изменение типа сертификата

Для перевода сервисного сертификата из вторичного в первичный используется командлет Set-SignServiceCerticate.

Set-SignServiceCertificate -InputObject <ServiceCertificate> [-PassThru] [-DisplayName {SignServer}] [<CommonParameters>]

Данный набор параметров позволяет изменить тип сертификата, переданного через pipeline.

Параметры:

  • InputObject - объект сервисного сертификата, полученный через pipeline (например, вызовом командлета Get-SignServiceCertificate).
Set-SignServiceCertificate -Thumbprint <string> [-PassThru] [-DisplayName {SignServer}] [<CommonParameters>]

Данный набор параметров используется для изменения типа сервисного сертификата, поиск которого среди зарегистрированных осуществляется по SHA-1-отпечатку.

Параметр:

  • Thumbprint - SHA-1-отпечаток сертификата.

Удаление сервисного сертификата

Для удаления сервисного сертификата используется командлет Remove-SignServiceCertificate.

Remove-SignServiceCertificate -InputObject <ServiceCertificate> [-PassThru] [-DisplayName {SignServer | SignServer2}] [<CommonParameters>]

Данный набор параметров позволяет удалить сертификат, переданный через pipeline.

Параметры:

  • InputObject - объект сервисного сертификата, полученный через pipeline (например, вызовом командлета Get-SignServiceCertificate).
Remove-SignServiceCertificate -Thumbprint <string> [-PassThru] [-DisplayName {SignServer | SignServer2}] [<CommonParameters>]

Данный набор параметров используется для удаления сервисного сертификата, поиск которого среди зарегистрированных осуществляется по SHA-1-отпечатку.

Параметр:

  • Thumbprint - SHA-1-отпечаток сертификата.

При удалении сервисных сертификатов для компонентов "Веб-интерфейс Пользователя" и "Центр Идентификации" происходит проверка использования удаляемого сертификата в качестве сертификата DPAPI. Tсли удаляемый сертификат участвует в шифровании ключей DPAPI, то выполнение командлета прервется и будет создано соответствующее сообщение об ошибке c указанием идентификатора ключа DPAPI. Для успешного удаления сервисного сертификата в этом случае требуется удалить зашифрованные на нем ключи DPAPI.

Создание сервисного сертификата

Для создания сервисного сертификата используется командлет New-SignServiceCertificate.

Примечание

Для корректной работы данного командлета требуется версия КриптоПро CSP 13000 и выше.

New-SignServiceCertificate -SelfSigned -Install -Output <string> [-Password <string>] [-AddToLocalMachineRoot] [-PublicKeyOutput <string>] [-ContainerName <string>] [-Subject <string>] [-ProviderType {GR3410_2012_256 | GR3410_2012_512 | RSA}] [-ProviderName <string>] [-ExpiresInDays <int>] [-ExtendedKeyUsage <string[]>] [<CommonParameters>]

Данный набор параметров позволяет создать самоподписанный сервисный сертификат, установить его в хранилище LocalMachine/My и экспортировать в PFX.

Параметры:

  • Output - путь к файлу PFX с экспортированным сертификатом.
  • Password - пароль для защиты PFX.
  • AddToLocalMachineRoot - флаг, показывающий, требуется ли установка создаваемого самоподписанного сертификата в хранилище доверенных корневых сертификатов локальной машины (mRoot).
  • PublicKeyOutput - путь к файлу для сохранения содержимого сертификата открытого ключа в формате DER.
  • ContainerName - имя контейнера с ключевой парой сертификата (если не задано, то будет создано случайное имя с префиксом CPROKEY-SIGN-).
  • Subject - имя субъекта сертификата, если не задано, то будет использоваться CN = CproKey Sign Service.
  • ProviderType - тип алгоритма криптопровайдера, если не задан, то будет использован GR3410_2012_256.
  • ProviderName - имя криптопровайдера, если параметр не задан, то будет использоваться провайдер по умолчанию для заданного типа.
  • ExpiresInDays - срок действия сертификата в днях.
  • ExtendedKeyUsage - перечень OID расширений "Улучшенный ключ".
New-SignServiceCertificate -SelfSigned -Install [-AddToLocalMachineRoot] [-PublicKeyOutput <string>] [-ContainerName <string>] [-Exportable] [-Subject <string>] [-ProviderType {GR3410_2012_256 | GR3410_2012_512 | RSA}] [-ProviderName <string>] [-ExpiresInDays <int>] [-ExtendedKeyUsage <string[]>] [<CommonParameters>]

Данный набор параметров создает самоподписанный сертификат и устанавливает его в хранилище LocalMachine\My.

Параметры:

  • ContainerName - имя контейнера с ключевой парой сертификата (если не задано, то будет создано случайное имя с префиксом CPROKEY-SIGN-).
  • AddToLocalMachineRoot - флаг, показывающий, требуется ли установка создаваемого самоподписанного сертификата в хранилище доверенных корневых сертификатов локальной машины (mRoot).
  • PublicKeyOutput - путь к файлу для сохранения содержимого сертификата открытого ключа в формате DER.
  • Exportable - switch-параметр, при наличии указывает на то, что ключ должен быть создан экспортируемым.
  • Subject - имя субъекта сертификата, если не задано, то будет использоваться CN = CproKey Sign Service.
  • ProviderType - тип алгоритма криптопровайдера, если не задан, то будет использован GR3410_2012_256.
  • ProviderName - имя криптопровайдера, если параметр не задан, то будет использоваться провайдер по умолчанию для заданного типа.
  • ExpiresInDays - срок действия сертификата в днях.
  • ExtendedKeyUsage - перечень OID расширений "Улучшенный ключ".
New-SignServiceCertificate -SelfSigned -Output <string> [-Password <string>] [-AddToLocalMachineRoot] [-PublicKeyOutput <string>] [-Subject <string>] [-ProviderType {GR3410_2012_256 | GR3410_2012_512 | RSA}] [-ProviderName <string>] [-ExpiresInDays <int>] [-ExtendedKeyUsage <string[]>] [<CommonParameters>]

Данный набор параметров создает самоподписанный сервисный сертификат и экспортирует его в файл в формате PFX.

Параметры:

  • Output - путь к файлу PFX с экспортированным сертификатом.
  • Password - пароль для защиты PFX.
  • AddToLocalMachineRoot - флаг, показывающий, требуется ли установка создаваемого самоподписанного сертификата в хранилище доверенных корневых сертификатов локальной машины (mRoot).
  • PublicKeyOutput - путь к файлу для сохранения содержимого сертификата открытого ключа в формате DER.
  • Subject - имя субъекта сертификата, если не задано, то будет использоваться CN = CproKey Sign Service.
  • ProviderType - тип алгоритма криптопровайдера, если не задан, то будет использован GR3410_2012_256.
  • ProviderName - имя криптопровайдера, если параметр не задан, то будет использоваться провайдер по умолчанию для заданного типа.
  • ExpiresInDays - срок действия сертификата в днях.
  • ExtendedKeyUsage - перечень OID расширений "Улучшенный ключ".
New-SignServiceCertificate -Output <string> [-ContainerName <string>] [-Subject <string>] [-ProviderType {GR3410_2012_256 | GR3410_2012_512 | RSA}] [-ProviderName <string>] [-ExtendedKeyUsage <string[]>] [<CommonParameters>]

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

Параметры:

  • Output - путь к файлу c PKCS10 запросом.
  • ContainerName - имя контейнера с ключевой парой сертификата (если не задано, то будет создано случайное имя с префиксом CPROKEY-SIGN-).
  • Subject - имя субъекта сертификата, если не задано, то будет использоваться CN = CproKey Sign Service.
  • ProviderType - тип алгоритма криптопровайдера, если не задан, то будет использован GR3410_2012_256.
  • ProviderName - имя криптопровайдера, если параметр не задан, то будет использоваться провайдер по умолчанию для заданного типа.
  • ExtendedKeyUsage - перечень OID расширений "Улучшенный ключ".

Для каждого сервиса префикс контейнера и имя субъекта по умолчанию будет отличаться.

Примечание

Для контейнеров, созданных с помощью считывателя HDIMAGE, автоматически выдаются права доступа для сервисной учетной записи.

Особенности работы с сервисными сертификатами Центра Идентификации

В отличие от других сервисов ЦИ обладает двумя независимыми наборами сервисных сертификатов: для межсервисного взаимодействия (в т.ч. для защиты cookie) и для подписи маркеров. Для работы с двумя наборами сертификатом ко всем командлетам по управлению сертификатами данного компонента добавляется параметр Usage с двумя возможными значениями:

  • Service-Communications - межсервисное взаимодействие.
  • Token-Signing - подпись маркеров.