Внешние модули и сервисы платформы Platform V, с которыми интегрируется Platform V Audit SE (AUD)#

• Модуль Platform V Backend (PACMAN). Представлен модулем platform-commons-war, версии 9.2 и выше. (Третье поколение.)

• Модуль Platform V Monitor (Объединенный мониторинг Unimon). Представлен модулем custodian-distr-impl-ear, версии 4.0 и выше. (Третье поколение.)

• Модуль Platform V Monitor Журналирование. Представлен модулем logger-platform, версии 3.7 и выше. (Третье поколение.)

• Platform V IAM SE (IAM). Представлен модулем access_platform_client_ear, версии 4.3 и выше. (Третье поколение.)

• API транспорта. Представлен модулем transport-platform-api-web, версии 6.2 и выше. (Третье поколение.)

• Secret Management System.

Для работы UI Platform V Audit SE (AUD) также используется библиотека seap-lib версии 9.2 и выше, которую нужно развернуть на сервере с WildFly. (Третье поколение.)

1. Для успешного старта UI Platform V Audit SE (AUD) в WildFly должны быть запущены:

   • custodian-distr-impl-ear

   • transport-platform-api-web

   • platform-commons-war

   • logger-platform

   • access_platform_client_ear

2. Для успешного старта сервиса Перекладчик в WildFly должны быть запущены:

   • custodian-distr-impl-ear

   • transport-platform-api-web

   • platform-commons-war

   • logger-platform

Интеграция с компонентом PACMAN (CFGA) продукта Platform V Backend (#BD)#

Для централизованного управления настройками Platform V Audit SE (AUD), используется интеграция с компонентом PACMAN (CFGA) продукта Platform V Backend (#BD). Во время развертывания Platform V Audit SE (AUD), администратор сервиса PACMAN загружает в него структуры конфигурационных файлов:

• audit2-config-struct.xml (серверная часть и UI),

• audit2-client-config-struct.xml (клиентский модуль). После этого, администраторы стенда вносят настройки через веб-интерфейс PACMAN. Все настройки и их возможные значения указаны в разделе Конфигурационные настройки серверной части Platform V Audit SE (AUD).

Аутентификация и авторизация пользователей (Интеграция с сервисом Platform V IAM)#

Чтобы предоставить пользователям доступ в UI Platform V Audit SE (AUD), используется СУДИР для аутентификации и SPAS (часть Platform V IAM (IAM)) для авторизации. Между СУДИР и серверами UI должен быть настроен mTLS с проверкой CN сертификата СУДИР. Для этого, на этапе развертывания модуля UI Platform V Audit SE (AUD) в WildFly нужно загрузить в PACMAN конфигурационный файл audit2-config-struct.xml из состава дистрибутива Platform V Audit SE (AUD), и после этого указать параметры в PACMAN:

• security.x509.principal – CN сертификата СУДИР, который проверяется при редиректе запроса с СУДИР на UI Platform V Audit SE (AUD).

• sudirLoginUrl - URL для входа в интерфейc.

• sudirLogoutUrl - URL загружаемой страницы после выхода пользователя из интерфейса.

Авторизация через SPAS происходит при помощи ролевой модели. Пользователю назначается одна из следующих ролей: администратор, аудитор с доступом ко всем модулям, и аудитор с доступом только к одному модулю. Подробнее о ролях пользователей и ролевой модели вы можете прочитать в Руководстве по безопасности. После того, как аутентификация через СУДИР настроена и ролевая модель Audit загружена в сервис авторизации SPAS, зайдите в приложение по администрированию сервиса аутентификации СУДИР и назначьте пользователям полномочия в соответствии с ролевой моделью аудита. После этого пользователи смогут авторизоваться в Platform V Audit SE (AUD).

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

Ролевая модель доступа также применяется при взаимодействии отдельных компонентов сервиса. На каждом взаимодействии между компонентами выполняется аутентификация и авторизация соединений: клиент → транспорт (Kafka) → хранилище (Storage) → экспорт (Stream). Ниже приводится описание ролей и предоставляемого ими доступа.

Интеграция с сервисом Platform V Monitor Журналирование#

Журналирование компонентов Platform V Audit SE (AUD)#

Приложения Platform V Audit SE (AUD), развернутые в среде OpenShift, пишут логи в папку /app/logs/ внутри контейнера:

• В стандартном формате (по паттерну %d{ISO8601} [%t] [%level] (%c) [%C::%M:%L] mdc:(%mdc)| %m%n) - application.log;

• В формате JSON - application.log.json.

Для хранения логов настроена авто-ротация со сжатием. Когда файл с логом достигает размера 10 мегабайт, происходит сжатие файла в ZIP-архив и начинается запись в новый файл. Максимальный размер архивов с логами может составлять до 50 мегабайт.

Конфигурацию логирования можно посмотреть и изменить в configMap каждого из приложений. Имя configMap формируется по принципу «<имя-компонента>-cfg».

Для каждого контейнера с компонентом Platform V Audit SE (AUD) подключен sidecar Logger (Fluent-bit), который вычитывает логи из application.log.json и отправляет сервису Logger через REST API.

Настройки подключения sidecar к описаны в Deployment каждого компонента Platform V Audit SE (AUD). Имя Deployment формируется по принципу «<имя-компонента>».

Настройки самого приложения Logger (Fluent-bit) описаны в configMap для каждого компонента отдельно. Имя configMap формируется по принципу «<имя-компонента>-logger-sidecar-cfg».

Компоненты Platform V Audit SE (AUD) пишут в логи под следующими moduleID:

audit2-proxy, audit2-divider, audit2-indicator, audit, audit2-pci-dss-transmitter

Клиентские модули не имеют собственных moduleID. Они пишут логи под идентификаторами пользовательских модулей, использующих Platform V Audit SE (AUD).

Интеграция с сервисом Platform V Monitor Unimon#

Мониторинг компонентов Platform V Audit SE (AUD)#

Platform V Audit SE (AUD) может передавать следующие метрики в Platform V Monitor (OPM) для отображения в Platform V Monitor - Indicator (INDA):

• Метрики серверной части

• Метрики клиентской части

• Метрики перекладчика PCI DSS

• Метрики с ETL-сервисов Flume

• Метрики с транспортного сервиса Kafka

• Метрики для отслеживания нагрузки на API Platform V Audit

За централизованный сбор метрик и их передачу в Platform V Monitor отвечает сервис audit2-indicator, который работает в связке с сервисами unimon-agent и unimon-sender из состава поставки Platform V Monitor. Pods c сервисом audit2-indicator, unimon-agent и unimon-sender разворачиваются в namespace Platform V Audit SE (AUD) в OpenShift. Audit2-indicator развертывается автоматически при установке компонентов Platform V Audit SE (AUD) в OpenShift. Для развертывания и настройки unimon-agent и unimon-sender необходимо выполнить дополнительные шаги, согласно документации Platform V Monitor. Для просмотра метрик в Platform V Monitor также необходимо настроить дашборд в Platform V Monitor Indicator (INDA), согласно документации этого компонента. При возникновении сложностей с настройкой рекомендуем обратиться за помощью в службу технической поддержки по этому компоненту.

Включить, настроить и выключить сбор метрик с Kafka в audit2-indicator можно через ConfigMap application.yml:

indicator:
  plannerPoolSize: 100
  metrics:
    audit_flume_written_events_to_solr:
      enabled: true
      period: 10m
      parameters:
        attribute: Written
    audit_flume_read_events_solr_pipeline:
      enabled: true
      period: 10m
      parameters:
        attribute: Read
    audit_flume_written_events_to_hdfs:
      enabled: true
      period: 10m
      parameters:
        attribute: Written
    audit_flume_read_events_hdfs_pipeline:
      enabled: true
      period: 10m
      parameters:
        attribute: Read
    audit_flume_written_metamodels_to_hbase:
      enabled: true
      period: 10m
      parameters:
        attribute: Written
    audit_flume_read_metamodels_hbase_pipeline:
      enabled: true
      period: 10m
      parameters:
        attribute: Read
    audit_kafka_messages_per_topic:
      enabled: true
      period: 10m
    audit_kafka_lag_percent_consumer_topic:
      enabled: true
      period: 10m
    audit_kafka_lag_consumer_topic:
      enabled: true
      period: 10m
      parameters:
        include-groups: "audit-events.*,audit-metamodels.*,audit-operations.*"
  publication:
    logger:
      enabled: true

enabled: - опция включает и выключает сборщик метрик (true/false). period: - период, который используется для сбора метрики (s/m/h).

Нагрузка, возникающая при интеграции с Platform V Monitor Unimon (MONA)#

Нагрузка, которая возникает при передаче метрик в компонент MONA, зависит от количества передаваемых метрик, количества кластеров Kafka и периодичности их сбора. Необходимо сложить метрики, собранные с Kafka и метрики, собранные с ETL-сервисов. Умножить их на количество кластеров Kafka. Данное произведение умножить на период времени сбора (период времени сбора с Kafka и ETL-сервисов всегда должен быть одинаковым). Одна метрика равна 300 символам в кодировке Unicode UTF-8.

Интеграция с сервисом Secret Management System#

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

В процессе развертывания Platform V Audit SE (AUD), на Pods c этими компонентами устанавливаются sidecar Vault Agent Injector. На Pods c Ingress и Egress устанавливаются sidecar Vault Agent Injector и init-container vault-agent-init.

При обновлении секретов в хранилище Vault, Vault Agent Injector считывает их и размещает в виде файла на соответствующий volume. После этого приложение перезапускается автоматически.

Интеграция с сервисом Secret Management System опциональна. Включается путем указания настроек в процессе установки Platform V Audit SE (AUD). Подробнее об этом можно прочитать в разделе Инструкции по настройке развертывания при помощи Install_EIP.

Предварительные шаги для подготовки интеграции с Secret Management System#

1. Получите доступ к сервису Secret Management System у его администраторов.

2. Закодируйте в base64 секреты из таблицы ниже (отмечены фразой "Закодированная в base 64…"). Это нужно для хранения сложных по структуре файлов или бинарных файлов. Закодировать можно при помощи команды base64 <имя_исходного_файла> > <имя_base64_файла>.

Секреты для хранения в Secret Management System

3. Подключите в сервисе Secret Management System движок выпуска сертификатов и настройте в нем возможность выпускать сертификаты с требуемыми для стенда CN и SAN.

Дальнейшие шаги по интеграции происходят на этапе развертывания Platform V Audit SE (AUD). О них рассказываем подробно в разделе Инструкции по настройке развертывания при помощи Install_EIP.

Ограничения интеграции с Secret Management System#

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

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

• Приложение, напрямую использующее REST API Platform V Audit SE (AUD), должно самостоятельно проработать интеграцию с Secret Management System.

• Отзыв/ротация корневого сертификата потребует ручных манипуляций на компонентах Platform V Audit SE (AUD), у которых нет интеграции с Secret Management System.

• Сертификаты для Cloudera не управляются Secret Management System, их необходимо ротировать вручную в соответствии с их сроком действия, не реже раза в год.

• Хранение и ротация секретов Kerberos пока не поддерживается в Secret Management System. Поэтому в Platform V Audit SE (AUD) либо должна быть отключена интеграция с Kerberos (FreeIPA), либо поставка keytab должна осуществляться в ручном режиме для компонентов Platform V Audit SE (AUD).

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

• Выпуск нового сертификата должен происходить до истечения срока действия предыдущего, чтобы обеспечить rolling update.

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

Интеграция с Platform V Synapse Service Mesh#

Для обеспечения безопасных подключений компонентов Аудита в кластере OSE, используется интеграция с Platform V Synapse Service Mesh, а именно поды Ingress/Egress + sidecar'ы 'istio-proxy' в подах самого Аудита.

Ограничения интеграции с Platform V Synapse Service Mesh#

При установке Аудита в кластер OSE, по требованию информационной безопасности Банка, должен быть включен валидатор конфигураций Istio - VALD. В данном валидаторе нет возможности пройти правила валидации под номерами:

• 23 (217) - Ошибка при проверке портов в других VirtualService. Внутренний порт не указан в Service Entry. Добавьте внутренний порт в ServiceEntry.

• 205 - Ошибка в том, что host уже присутствует в другом ServiceEntry, а правило гласит, что два ServiceEntry с одним хостом не могут находится в одном проекте для TCP порта.

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