Рекомендуемые настройки безопасности окружения#

Общие указания#

Для реализации функций безопасности среды функционирования Platform V Audit SE (AUD) должны выполняться следующие действия:

  • Необходимо регулярное обновление всех сред функционирования Platform V Audit SE (AUD) до актуальных версий с применением всех необходимых патчей безопасности с официальных сайтов разработчиков сред функционирования.

  • Компоненты операционной системы и сред функционирования Platform V Audit SE (AUD) должны быть максимально ограничены. Компоненты, которые не участвуют в функционировании Platform V Audit SE (AUD), должны быть отключены.

  • Должно обеспечиваться предотвращение несанкционированного доступа к идентификаторам и паролям администраторов среды виртуализации, которые необходимы для управления и технической поддержки среды функционирования Platform V Audit SE (AUD).

  • Должна быть обеспечена физическая сохранность серверной платформы с установленным Platform V Audit SE (AUD) и исключение возможности физического доступа к ней посторонних лиц.

  • Каналы передачи данных Platform V Audit SE (AUD) должны быть либо расположены в пределах контролируемой зоны и защищены с использованием организационно-технических мер, либо, в случае их выхода за пределы контролируемой зоны, должны быть защищены путем применения средств криптографической защиты информации, сертифицированных в системе сертификации ФСБ России.

  • Должна быть исключена возможности использования Platform V Audit SE (AUD) для обработки информации, содержащей сведения, составляющие государственную тайну.

  • Должно быть обеспечено наличие администратора, отвечающего за управление (администрирование) механизмов защиты Platform V Audit SE (AUD).

  • Установка, конфигурирование и управление Platform V Audit SE (AUD) должны выполняться в соответствии с эксплуатационной документацией.

  • Должно обеспечиваться предотвращение несанкционированного доступа к идентификаторам и паролям пользователей Platform V Audit SE (AUD).

  • Должно обеспечиваться хранение информации о событиях безопасности в течение не менее трёх лет.

  • Platform V Audit SE (AUD) должно функционировать на JRE, которая прошла анализ безопасности в рамках сертификационных испытаний Platform V Audit SE (AUD), или на JRE, прошедшей испытания по соответствующему уровню контроля или более высокому в рамках сертификации по соответствующему уровню доверия, в том числе заимствованной из состава другого программного обеспечения, сертифицированного по соответствующему уровню доверия или выше.

  • В виртуальной машине JRE из состава среды функционирования Platform V Audit SE (AUD) должно функционировать только программное обеспечение, необходимое для штатного функционирования компонентов Platform V IAM или другое ПО, сертифицированное по соответствующему уровню доверия или выше.

  • Для всех компонентов среды функционирования Platform V Audit SE (AUD) должны быть установлены все актуальные обновления программного обеспечения, либо приняты организационно-технические меры, направленные на исключение возможности эксплуатации уязвимостей.

  • На Hadoop (для Solr, Hbase) и Kafka должен быть настроен SSL. Подключение клиентов также должно выполняться через SSL.

Настройка брандмауэра#

Перед развертыванием Platform V Audit SE (AUD) убедитесь, что настройки брандмауэра разрешают входящие и исходящие соединения по протоколу TCP на следующих портах:

Сервис

Порт

Cloudera Manager

5678, 7180, 7182, 7183, 7184, 7185, 7186, 7187, 7190, 7191, 7432, 8083, 8084, 8086, 8087, 8089, 8091, 9000, 9091, 9994, 9995, 9996, 9997, 9998, 9999, 10101, 10110, 10111

Kafka

9092, 9093, 9393, 9394, 24042

Logger

443

Spark

7077, 7078, 7337, 18080, 18081, 18088

Zookeeper

2181, 2182, 2888, 3181, 3888, 4181, 9010

Solr

8983, 8985

Hbase

2181, 2888, 3888, 16000, 16010, 16020, 16030, 20550, 8085, 9090, 9095, 11060

HDFS

111, 1004, 1006, 2049, 4242, 8019, 8020, 8022, 8480, 8481, 8485, 9864, 9865, 9866, 9867, 9868, 9869, 9870, 9871, 14000, 50010, 50070, 50079, 50470, 50579, 14000, 14001

Hive

9083, 10000, 10002, 50111

Hue

8888, 8889

Oozie

11000, 11443

YARN

8030, 8031, 8032, 8033, 8040, 8041, 8042, 8044, 8088, 8090, 10020, 10033, 13562, 19888, 19890

Flume

41414

Rest API

80, 443

Audit UI

80, 443

Kerberos

88, 464, 749

SSH

22

Возможные настройки OC Linux#

Выполните настройки операционной системы для организации безопасности. Ниже приведен рекомендуемый (необязательный) список возможных настроек. Исполнение остается на усмотрение администраторов среды функционирования:

  • Удалите беспарольную политику группе wheel (sudo).

  • Удалите разрешения setuid и setgid для всех исполняемых файлов, где они не требуются.

  • Настройте максимальный срок действия пароля 40 дней.

  • Настройте минимальный срок пароля 1 день.

  • Настройте предупреждение об окончании срока пароля 14 дней.

  • Настройте минимальную длину пароля не менее 8 символов.

  • Отключите поддержку USB накопителя.

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

  • Включите службу аудита и добавьте файл с правилами. Ссылка.

  • Измените следующие параметры SSH:

    • X11Forwarding no

    • MaxAuthTries 3

    • MaxSessions 2

    • PubkeyAuthentication yes

    • PasswordAuthentication no

    • ListenAddress - установите локальный IP. Сервис SSH не должен слушать сетевой интерфейс.

    • AllowUsers - включите этот параметр и добавьте пользователей.

    • Allowgroups - включите этот параметр и добавьте группу.

  • Отключите поддержку IPv6.

  • Обновите программное обеспечение.

  • Удалите VMware Tools.

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

Настройки OpenShift#

Ниже приведен рекомендуемый (необязательный) список требований безопасности к среде исполнения приложений OpenShift. Исполнение остается на усмотрение администраторов среды функционирования:

  • Обеспечьте установку новых обновлений безопасности для элементов среды исполнения.

  • Обеспечьте регулярную синхронизацию времени от доверенных источников.

  • Отключите или удалите все неиспользуемые и ненужные пакеты, модули, сервисы и протоколы.

  • Измените, переименуйте или заблокируйте все встроенные учетные записи, включая учетную запись локального администратора (суперпользователя).

  • Обеспечьте разграничение доступа учетных записей пользователей (далее, УЗ) и технологических учетных записей (далее, ТУЗ) в соответствии с ролевой моделью доступа.

  • Используйте межсетевое экранирование для защиты хранимых данных.

  • Включите и настройте механизм шифрования административного доступа.

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

  • Обеспечьте статический (анализ защищенности образов) и динамический (анализ защищенности компонентов и приложений) контроль защищенности, подпись (контроль неизменности) образов по результатам проведения анализа — Vulnerability Management.

  • Обеспечьте сбор журналов доступа и событий безопасности для выявления инцидентов кибербезопасности — SOC Monitoring.

  • Контролируйте и ограничивайте вызов компонентов в целях предотвращения атак типа «отказ в обслуживании» — DoS/DDoS prevention.

  • Контролируйте использование компонентами технических ресурсов, чтобы обеспечить непрерывное функционирование среды исполнения - Resources monitoring.

  • Защищайте используемые в средах исполнения секреты от компрометации, модификации, удаления — Secret Management.

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

  • Для обеспечения аутентифицированного доступа к REST API Audit-proxy и шифрования передаваемых данных, рекомендуется настроить TLS на ingress средствами OpenShift.

Поддерживаемой системой приложений-контейнеров является OpenShift (использование Kubernetes опционально). В инструкциях по настройке, в именах переменных и параметрах системы могут встречаться названия систем контейнеризации, которые одинаковы и применимы для обеих сред контейнеризации.

Настройки Kafka#

Для настройки безопасного использования обратитесь к следующим разделам этого руководства:

Создание сертификатов TLS/SSL для компонентов Platform V Audit SE (AUD)#

Для межсервисного взаимодействия компонентов Platform V Audit SE (AUD) необходимы следующие сертификаты:

  • Сертификат для audit2-proxy (клиентский)

  • Сертификат для Istio OTT sidecar (клиентский)

  • Сертификат для Istio Ingress (серверный)

  • Сертификат для Istio Egress (клиентский)

  • Сертификат для Solr (клиентский, серверный)

  • Сертификат для audit2-divider (клиентский)

  • Сертификат HBase (серверный, клиентский)

  • Сертификат для Audit WebUI в WildFly (клиентский, серверный)

  • Сертификат Kafka (клиентский, серверный)

  • Сертификат Flume (клиентский, серверный)

Для генерации сертификатов потребуется сервер с операционной системой Linux и установленными утилитами keytool (jdk 7+) и openssl.

Если Platform V Audit SE (AUD) используется вместе с сервисом Secret Management System, вы можете в автоматическом режиме получать сертификаты для следующих сервисов:

  • audit2-proxy,

  • divider.

Для остальных компонентов Platform V Audit SE (AUD), таких, как клиентские модули, а так же для сервисов Cloudera - интеграция с Secret Management System не предусмотрена. Для них будет необходимо создать сертификаты по инструкциям, приведенным далее в этом разделе, и обновлять сертификаты вручную в соответствии с их сроком действия, не реже раза в год.

Сервис Secret Management System обеспечивает хранение секретов (сертификатов, ключей и паролей), безопасную передачу секретов приложениям и обновление секретов, без необходимости прерывать работу Platform V Audit SE (AUD).

При подключении Platform V Audit SE (AUD) к сервису Secret Management System, обратитесь к администраторам этого сервиса при необходимости выпустить и установить сертификаты для компонентов audit2-proxy и divider.

Внимание:
Все названия сертификатов и их частей, указанные в инструкциях ниже - только для примера. Названия актуальных сертификатов, выданных сервисом RLM, могут отличаться.

Сертификат для audit2-proxy (клиентский)#

Если Platform V Audit SE (AUD) не подключен к системе Secret Management System, воспользуйтесь этой инструкцией для создания сертификата.

Если Platform V Audit SE (AUD) подключен к Secret Management System, обратитесь к администраторам сервиса Secret Management System.

  1. Создайте хранилище public и private ключей.

keytool -genkeypair -keystore keystore_audit2_proxy.jks -storetype JKS -alias audit2_proxy -ext
EKU=clientAuth -dname "CN=audit2_proxy,OU=00CA,O=Company Name,C=RU" -keyalg
RSA -keysize 2048 -keypass <уникальный_ключ> -storepass <пароль_хранилища>

Где пароль_хранилища - пароль для создаваемого JKS, уникальный_ключ - для простоты то же самое, что и пароль_хранилища.

  1. Создайте запрос на подписание сертификата (файл csr).

keytool -certreq -alias audit2_proxy -keystore keystore_audit2_proxy.jks -file request_audit2_proxy.csr
-ext EKU=clientAuth -keypass <уникальный_ключ> -storepass <пароль_хранилища>

Где пароль_хранилища - пароль из предыдущего пункта и уникальный_ключ - пароль из предыдущего пункта.

  1. Подпишите сертификат через сервис RLM (доступен для администраторов стендов).

  2. После подписания положите полученные сертификаты на целевой хост и импортируйте в хранилище keystore_audit2_proxy.jks всю цепочку (корневой, промежуточный и клиентский).

keytool -import -alias rootCA2 -storetype JKS -keystore keystore_audit2_proxy.jks -file "Test Root CA 2.cer"
keytool -import -alias issuingCA2 -storetype JKS -keystore keystore_audit2_proxy.jks -file "Test Issuing CA 2.cer"
keytool -import -alias audit2_proxy -storetype JKS -keystore keystore_audit2_proxy.jks -file request_audit2_proxy.cer

  1. Создайте truststore-audit2-proxy.jks.

keytool -import -alias CAroot -storetype JKS -keystore truststore_audit2_proxy.jks -file "Test Root CA 2.cer"
keytool -import -alias Issuer -storetype JKS -keystore truststore_audit2_proxy.jks -file "Test Issuing CA 2.cer"

Сертификат для Istio OTT sidecar (клиентский)#

  1. Создайте ключевую пару в p12-контейнере.

keytool -genkey -keyalg EC -sigalg SHA256withECDSA -keystore ${module_id}.p12 -storetype PKCS12 -keysize 256 -dname "CN=${module_id}" -alias ${module_id}

Где module_id - это уникальный идентификатор субъекта доступа (приложение или автоматизированная система), для которого будет выполняться получение токенов. Допустимые символы:

  • буквы латинского алфавита в нижнем регистре

  • цифры

  • символы "-" и "_"

Не более 64 символов.

Внимание: Не допускается переиспользование чужих module.id и соответствующих сертификатов OTT, выпущенных для других приложений или автоматизированных систем.

  1. Создайте запрос на подписание сертификата (файл csr).

keytool -certreq -keyalg EC -sigalg SHA256withECDSA -keystore ${module_id}.p12 -storetype PKCS12 -alias ${module_id} > ${module_id}_cert_req.pem

В результате выполнения этой команды создастся файл CSR - ${module_id}_cert_req.pem. Для создания сертификатов обратитесь к администраторам сервиса Istio OTT.

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

keytool -import -keystore ${module_id}.p12 -storetype PKCS12 -file PlatformCA_EC.pem -alias PlatformCA_EC
keytool -import -keystore ${module_id}.p12 -storetype PKCS12 -file ${module_id}.pem -alias ${module_id}

Если сертификаты были выданы в формате, отличном от PEM, их можно сконвертировать в PEM с помощью следующих команд.

Из JKS в p12

Конвертация keystore:

keytool -importkeystore \
-srckeystore keystore.jks \
-destkeystore keystore.p12 \
-srcalias audit2_proxy \
-srcstoretype jks \
-deststoretype pkcs12

Конвертация truststore:

keytool -importkeystore \
-srckeystore truststore.jks \
-destkeystore truststore.p12 \
-srcstoretype jks \
-deststoretype pkcs12

Из p12 в PEM

Конвертация keystore:

openssl pkcs12 -in keystore.p12 -out client_crt.pem -nokeys
openssl pkcs12 -in keystore.p12 -out client_private_key.pem -nodes -nocerts

Конвертация truststore:

openssl pkcs12 -in truststore.p12 -out service_tls_crt.pem -nokeys

Создание service_crt.pem:

Для создания service_crt.pem необходимо найти в service_tls_crt.pem сертификат с CN=ott-service и вручную скопировать его.

При конвертации из p12 в PEM в результирующий файл добавляется дополнительная информация, которую необходимо удалить (вручную или с помощью команд ниже), сохранив формат PEM сертификата.

Формат PEM:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Команда для запуска на Linux:

sed -i '/-*BEGIN [A-Z]*-*/,/-*END [A-Z]-*/!d' file.pem

Команда для запуска на MacOS:

sed -i '' '/-*BEGIN [A-Z]*-*/,/-*END [A-Z]-*/!d' file.pem

Сертификат для Istio Ingress (серверный)#

  1. Создайте запрос на создание сертификата. Для этого подготовьте конфигурационный файл ingress_audit.cnf с параметрами.

[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
[ req_distinguished_name ]
CN = audit2proxy_ingress
OU = 00CA
O = Company Name
C = RU
[ req_ext ]
subjectAltName = @alt_names
subjectKeyIdentifier = hash
extendedKeyUsage = serverAuth
[alt_names]
DNS.1 = <FQDN 1>
DNS.2 = <FQDN 2>

В [alt_names] укажите FQDN хостов для приема REST запросов клиентов Platform V Audit SE (AUD).

  1. Сгенерируйте запрос и ключ.

openssl req -new -out request_audit_ingress.csr -newkey rsa:2048 -nodes -sha256 -keyout key_audit_ingress.key -config ingress_audit.cnf

При генерации запроса подтвердите заполнение полей. Для этого достаточно продублировать предложенные значения:

Generating a 2048 bit RSA private key
...............+++
...............................................................................+++
writing new private key to 'key_audit_ingress.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
audit2proxy_ingress []:audit2proxy_ingress
00CA []:00CA
Company Name []:Company Name
RU []:RU

  1. Подпишите сертификат через сервис RLM (доступен для администраторов стендов).

  2. Преобразуйте полученные сертификаты из DER формата в PEM (если они не в PEM).

Так как они обычно предоставляются в формате DER, а в OpenShift необходимо использовать в формате PEM, то необходимо произвести конвертацию при помощи следующих команд: a. Конвертируем подписанный сертификат.

   openssl x509 -inform der -in request_audit_ingress.cer -out ingress_audit.crt

b. Конвертируем корневой сертификат.

   openssl x509 -inform der -in Test\ Root\ CA\ 2.cer -out ca.pem

"Test\ Root\ CA\ 2.cer" - имя корневого сертификата. Может отличаться. c. Конвертируем промежуточный сертификат.

   openssl x509 -inform der -in Test\ Issuing\ CA\ 2.cer -out issuing_ca.pem

"Test\ Issuing\ CA\ 2.cer" - имя промежуточного сертификата. Может отличаться.

d. Склеиваем промежуточный и корневой сертификаты в один.

   cat issuing_ca.pem ca.pem >> ca.crt

На этапе развертывания Platform V Audit SE (AUD) нужно будет подложить эти сертификаты в секреты в OpenShift. e. Удалите лишние файлы, получившиеся при генерации и конвертации сертификатов.

   rm ca.pem ingress_audit.cnf issuing_ca.pem request_audit_ingress.csr request_audit_ingress.cer Test\ Issuing\ CA\ 2.cer Test\ Root\ CA\ 2.cer

Сертификат для Istio Egress (клиентский)#

  1. Создайте запрос на создание сертификата. Для этого подготовьте конфигурационный файл egress_audit.cnf с параметрами.

[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
[ req_distinguished_name ]
CN = audit2proxy_egress
OU = 00CA
O = Company Name
C = RU
[ req_ext ]
subjectKeyIdentifier = hash
extendedKeyUsage = clientAuth

  1. Сгенерируйте запрос и ключ.

openssl req -new -out request_audit_egress.csr -newkey rsa:2048 -nodes -sha256 -keyout key_audit_egress.key -config egress_audit.cnf

При генерации запроса подтвердите заполнение полей. Для этого достаточно продублировать предложенные значения:

Generating a 2048 bit RSA private key
...............+++
...............................................................................+++
writing new private key to 'key_audit_egress.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
audit2proxy_egress []:audit2proxy_egress
00CA []:00CA
Company Name []:Company Name
RU []:RU

  1. Подпишите сертификат через сервис RLM (доступен для администраторов стендов).

  2. Преобразуйте полученные сертификаты из DER формата в PEM (если они не в PEM).

Так как они обычно предоставляются в формате DER, а в OpenShift необходимо использовать в формате PEM, то необходимо произвести конвертацию при помощи следующих команд: a. Конвертируем подписанный сертификат.

   openssl x509 -inform der -in request_audit_egress.cer -out egress_audit.crt

b. Конвертируем корневой сертификат.

   openssl x509 -inform der -in Test\ Root\ CA\ 2.cer -out ca.pem

"Test\ Root\ CA\ 2.cer" - имя корневого сертификата. Может отличаться. c. Конвертируем промежуточный сертификат.

   openssl x509 -inform der -in Test\ Issuing\ CA\ 2.cer -out issuing_ca.pem

"Test\ Issuing\ CA\ 2.cer" - имя промежуточного сертификата. Может отличаться.

d. Склеиваем промежуточный и корневой сертификаты в один.

   cat issuing_ca.pem ca.pem >> ca.crt

На этапе развертывания Platform V Audit SE (AUD) нужно будет подложить эти сертификаты в секреты в OpenShift.

e. Удалите лишние файлы, получившиеся при генерации и конвертации сертификатов.

   rm ca.pem egress_audit.cnf issuing_ca.pem request_audit_egress.csr request_audit_egress.cer Test\ Issuing\ CA\ 2.cer Test\ Root\ CA\ 2.cer

Сертификат для Solr (клиентский, серверный)#

  1. Создайте хранилище public и private ключей.

keytool -genkeypair -keystore keystore_audit_solr.jks -storetype JKS -alias audit2_solr -ext
EKU=serverAuth,clientAuth -dname "CN=audit2-solr,OU=00CA,O=Company Name,C=RU" -keyalg
RSA -keysize 2048 -ext "SAN=dns:<SOLR SERVER FQDN>" -keypass <уникальный_ключ> -storepass <пароль_хранилища>

Где пароль_хранилища - пароль для создаваемого JKS, уникальный_ключ - для простоты тоже самое что и пароль_хранилища.

  1. Создайте запрос на подписание сертификата (файл csr).

keytool -certreq -alias audit2_solr -keystore keystore_audit_solr.jks -file request_audit_solr.csr
-ext EKU=serverAuth,clientAuth -ext "SAN=dns:<SOLR SERVER FQDN>" -keypass <уникальный_ключ> -storepass <пароль_хранилища>

Где пароль_хранилища - пароль из предыдущего пункта, уникальный_ключ - пароль из предыдущего пункта, SOLR SERVER FQDN - значение из предыдущего пункта.

  1. Подпишите сертификат через сервис RLM (доступен для администраторов стендов).

  2. После подписания положите полученные сертификаты на целевой хост и импортируйте в хранилище keystore_audit_solr.jks всю цепочку (корневой, промежуточный и клиентский).

keytool -import -alias rootCA2 -storetype JKS -keystore keystore_audit_solr.jks -file "Test Root CA 2.cer"
keytool -import -alias issuingCA2 -storetype JKS -keystore keystore_audit_solr.jks -file "Test Issuing CA 2.cer"
keytool -import -alias audit2-solr -storetype JKS -keystore keystore_audit_solr.jks -file request_audit_solr.cer

  1. Создайте truststore-audit-solr.jks.

keytool -import -alias CAroot -storetype JKS -keystore truststore_audit_solr.jks -file "Test Root CA 2.cer"
keytool -import -alias Issuer -storetype JKS -keystore truststore_audit_solr.jks -file "Test Issuing CA 2.cer"

Сертификат для audit2-divider (клиентский)#

Если Platform V Audit SE (AUD) не подключен к системе Secret Management System, воспользуйтесь этой инструкцией для создания сертификата.

Если Platform V Audit SE (AUD) подключен к Secret Management System, обратитесь к администраторам сервиса Secret Management System.

  1. Создайте запрос на создание сертификата. Для этого подготовьте конфигурационный файл audit2-divider.cnf с параметрами.

[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
[ req_distinguished_name ]
CN = audit2_divider
OU = 00CA
O = Company Name
C = RU
[ req_ext ]
subjectKeyIdentifier = hash
extendedKeyUsage = clientAuth

  1. Сгенерируйте запрос и ключ.

openssl req -new -out request_audit2_divider.csr -newkey rsa:2048 -nodes -sha256 -keyout key_audit2_divider.key -config audit2_divider.cnf

При генерации запроса подтвердите заполнение полей. Для этого достаточно продублировать предложенные значения:

Generating a 2048 bit RSA private key
...............+++
...............................................................................+++
writing new private key to 'key_audit2_divider.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
audit2_divider []:audit2_divider
00CA []:00CA
Company Name []:Company Name
RU []:RU

  1. Подпишите сертификат через сервис RLM (доступен для администраторов стендов).

  2. Преобразуйте полученные сертификаты из DER формата в PEM (если они не в PEM).

Так как они обычно предоставляются в формате DER, а в OpenShift необходимо использовать в формате PEM, то необходимо произвести конвертацию при помощи следующих команд: a. Конвертируем подписанный сертификат.

   openssl x509 -inform der -in request_audit2_divider.cer -out audit2_divider.crt

b. Конвертируем корневой сертификат.

   openssl x509 -inform der -in Test\ Root\ CA\ 2.cer -out ca.pem

"Test\ Root\ CA\ 2.cer" - имя корневого сертификата. Может отличаться. c. Конвертируем промежуточный сертификат.

   openssl x509 -inform der -in Test\ Issuing\ CA\ 2.cer -out issuing_ca.pem

"Test\ Issuing\ CA\ 2.cer" - имя промежуточного сертификата. Может отличаться.

d. Склеиваем промежуточный и корневой сертификаты в один.

   cat issuing_ca.pem ca.pem >> ca.crt

На этапе развертывания Platform V Audit SE (AUD) нужно будет подложить эти сертификаты в секреты в OpenShift.

Сертификат HBase (серверный, клиентский)#

  1. Создайте хранилище public и private ключей.

keytool -genkeypair -keystore keystore_audit_hbase.jks -storetype JKS -alias audit2_hbase -ext
EKU=serverAuth,clientAuth -dname "CN=audit2-hbase,OU=00CA,O=Company Name,C=RU" -keyalg
RSA -keysize 2048 -ext "SAN=dns:<HBASE FQDN>" -keypass <уникальный_ключ> -storepass <пароль_хранилища>

Где пароль_хранилища - пароль для создаваемого JKS, уникальный_ключ - для простоты тоже самое что и пароль_хранилища, HBASE FQDN - полное имя серверов, на которых установлены компоненты HBASE. Узнать можно с помощью команды hostname -f. При необходимости, можно перечислить несколько, для тиражирования одного сертификата на несколько хостов. -ext "san=dns:test1.example.com,dns:test2.example.com,ip:10.10.10.10,ip:20.20.20.20"

  1. Создайте запрос на подписание сертификата (файл csr).

keytool -certreq -alias audit2_hbase -keystore keystore_audit_hbase.jks -file request_audit_hbase.csr
-ext EKU=serverAuth,clientAuth -ext "SAN=dns:<HBASE FQDN>" -keypass <уникальный_ключ> -storepass <пароль_хранилища>

Где пароль_хранилища - пароль из предыдущего пункта, уникальный_ключ - пароль из предыдущего пункта, HBASE FQDN - значение из предыдущего пункта.

  1. Подпишите сертификат через сервис RLM (доступен для администраторов стендов).

  2. После подписания положите полученные сертификаты на целевой хост и импортируйте в хранилище keystore-audit-hbase.jks всю цепочку (корневой, промежуточный и клиентский).

keytool -import -alias rootCA2 -storetype JKS -keystore keystore_audit_hbase.jks -file "Test Root CA 2.cer"
keytool -import -alias issuingCA2 -storetype JKS -keystore keystore_audit_hbase.jks -file "Test Issuing CA 2.cer"
keytool -import -alias audit2_hbase -storetype JKS -keystore keystore_audit_hbase.jks -file request_audit_hbase.cer

  1. Создайте truststore-audit-hbase.jks.

keytool -import -alias CAroot -storetype JKS -keystore truststore_audit_hbase.jks -file "Test Root CA 2.cer"
keytool -import -alias Issuer -storetype JKS -keystore truststore_audit_hbase.jks -file "Test Issuing CA 2.cer"

Сертификат для Audit WebUI в WildFly (клиентский, серверный)#

  1. Создайте хранилище public и private ключей.

keytool -genkeypair -keystore keystore_audit_web.jks -storetype JKS -alias audit2-web -ext
EKU=serverAuth,clientAuth -dname "CN=audit2-web,OU=00CA,O=Company Name,C=RU" -keyalg
RSA -keysize 2048 -ext "SAN=dns:<WildFly FQDN>" -keypass <уникальный_ключ> -storepass <пароль_хранилища>

Где пароль_хранилища - пароль для создаваемого JKS, уникальный_ключ - для простоты тоже самое что и пароль_хранилища, WildFly FQDN - полное имя сервера, на котором установлен Audit WebUI. Узнать можно с помощью команды hostname -f. При необходимости, можно перечислить несколько, для тиражирования одного сертификата на несколько хостов. -ext "san=dns:test1.example.com,dns:test2.example.com,ip:10.10.10.10,ip:20.20.20.20"

  1. Создайте запрос на подписание сертификата (файл csr).

keytool -certreq -alias audit2_web -keystore keystore_audit_web.jks -file request_audit_web.csr
-ext EKU=serverAuth,clientAuth -ext "SAN=dns:<WildFly FQDN>" -keypass <уникальный_ключ> -storepass <пароль_хранилища>

Где пароль_хранилища - пароль из предыдущего пункта, уникальный_ключ - пароль из предыдущего пункта, WildFly FQDN - значение из предыдущего пункта.

  1. Подпишите сертификат через сервис RLM (доступен для администраторов стендов).

  2. После подписания положите полученные сертификаты на целевой хост и импортируйте в хранилище keystore-audit-web.jks всю цепочку (корневой, промежуточный и клиентский).

keytool -import -alias rootCA2 -storetype JKS -keystore keystore_audit_web.jks -file "Test Root CA 2.cer"
keytool -import -alias issuingCA2 -storetype JKS -keystore keystore_audit_web.jks -file "Test Issuing CA 2.cer"
keytool -import -alias audit2_web -storetype JKS -keystore keystore_audit_web.jks -file request_audit_web.cer

  1. Создайте truststore-audit-web.jks.

keytool -import -alias CAroot -storetype JKS -keystore truststore_audit_web.jks -file "Test Root CA 2.cer"
keytool -import -alias Issuer -storetype JKS -keystore truststore_audit_web.jks -file "Test Issuing CA 2.cer"

Сертификат Kafka (клиентский, серверный)#

  1. Создайте хранилище public и private ключей.

keytool -genkeypair -keystore keystore_audit_kafka.jks -storetype JKS -alias audit2_kafka -ext
EKU=serverAuth,clientAuth -dname "CN=audit2_kafka,OU=00CA,O=Company Name,C=RU" -keyalg
RSA -keysize 2048 -ext "SAN=dns:<Kafka server FQDN>" -keypass <уникальный_ключ> -storepass <пароль_хранилища>

Где пароль_хранилища - пароль для создаваемого JKS, уникальный_ключ - для простоты тоже самое что и пароль_хранилища, Kafka server FQDN - полное имя сервера, на котором установлен Kafka server. Узнать можно с помощью команды hostname -f. При необходимости, можно перечислить несколько, для тиражирования одного сертификата на несколько хостов. -ext "san=dns:test1.example.com,dns:test2.example.com,ip:10.10.10.10,ip:20.20.20.20"

  1. Создайте запрос на подписание сертификата (файл csr).

keytool -certreq -alias audit2_kafka -keystore keystore_audit_kafka.jks -file request_audit_kafka.csr
-ext EKU=serverAuth,clientAuth -ext "SAN=dns:<Kafka server FQDN>" -keypass <уникальный_ключ> -storepass <пароль_хранилища>

Где пароль_хранилища - пароль из предыдущего пункта, уникальный_ключ - пароль из предыдущего пункта, Kafka server FQDN - значение из предыдущего пункта.

  1. Подпишите сертификат через сервис RLM (доступен для администраторов стендов).

  2. После подписания положите полученные сертификаты на целевой хост и импортируйте в хранилище keystore-audit-kafka.jks всю цепочку (корневой, промежуточный и клиентский).

keytool -import -alias rootCA2 -storetype JKS -keystore keystore_audit_kafka.jks -file "Test Root CA 2.cer"
keytool -import -alias issuingCA2 -storetype JKS -keystore keystore_audit_kafka.jks -file "Test Issuing CA 2.cer"
keytool -import -alias audit2_web -storetype JKS -keystore keystore_audit_kafka.jks -file request_audit_kafka.cer

  1. Создайте truststore_audit_kafka.jks.

keytool -import -alias CAroot -storetype JKS -keystore truststore_audit_kafka.jks -file "Test Root CA 2.cer"
keytool -import -alias Issuer -storetype JKS -keystore truststore_audit_kafka.jks -file "Test Issuing CA 2.cer"

Сертификат Flume (клиентский, серверный)#

  1. Создайте хранилище public и private ключей.

keytool -genkeypair -keystore keystore_audit_flume.jks -storetype JKS -alias audit2_flume -ext
EKU=serverAuth,clientAuth -dname "CN=audit2_flume,OU=00CA,O=Company Name,C=RU" -keyalg
RSA -keysize 2048 -ext "SAN=dns:<Flume host FQDN>" -keypass <уникальный_ключ> -storepass <пароль_хранилища>

Где пароль_хранилища - пароль для создаваемого JKS, уникальный_ключ - для простоты тоже самое что и пароль_хранилища, Flume host FQDN - полное имя сервера, на котором установлен Flume. Узнать можно с помощью команды hostname -f. При необходимости, можно перечислить несколько, для тиражирования одного сертификата на несколько хостов. -ext "san=dns:test1.example.com,dns:test2.example.com,ip:10.10.10.10,ip:20.20.20.20"

  1. Создайте запрос на подписание сертификата (файл csr).

keytool -certreq -alias audit2_flume -keystore keystore_audit_flume.jks -file request_audit_flume.csr
-ext EKU=serverAuth,clientAuth -ext "SAN=dns:<Flume host FQDN>" -keypass <уникальный_ключ> -storepass <пароль_хранилища>

Где пароль_хранилища - пароль из предыдущего пункта, уникальный_ключ - пароль из предыдущего пункта, Flume host FQDN - значение из предыдущего пункта.

  1. Подпишите сертификат через сервис RLM (доступен для администраторов стендов).

  2. После подписания положите полученные сертификаты на целевой хост и импортируйте в хранилище keystore_audit_flume.jks всю цепочку (корневой, промежуточный и клиентский).

keytool -import -alias rootCA2 -storetype JKS -keystore keystore_audit_flume.jks -file "Test Root CA 2.cer"
keytool -import -alias issuingCA2 -storetype JKS -keystore keystore_audit_flume.jks -file "Test Issuing CA 2.cer"
keytool -import -alias audit2_web -storetype JKS -keystore keystore_audit_flume.jks -file request_audit_flume.cer

  1. Создайте truststore_audit_flume.jks.

keytool -import -alias CAroot -storetype JKS -keystore truststore_audit_flume.jks -file "Test Root CA 2.cer"
keytool -import -alias Issuer -storetype JKS -keystore truststore_audit_flume.jks -file "Test Issuing CA 2.cer"