Сценарии администрирования#

Администраторы Platform V Audit SE (AUD)#

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

Кроме того в ролевой модели UI Platform V Audit SE (AUD) предусмотрена роль «Администратор», основная задача которого — это администрирование и восстановление событий из архивного хранилища. Пользователь с ролью «Администратор» не имеет доступ к событиям аудита. Он может получать статистику по оперативному и архивному хранилищу, управлять задачами импорта данных из архивного в оперативное хранилище, удалять импортированные пользователями коллекции (например, в целях освобождения дискового пространства при срабатывании пороговых значений метрик). Смотрите подробнее о ролях в разделе ниже – Ролевая модель.

Разграничение доступа к Platform V Audit SE (AUD)#

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

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

1. В СУДИР создается учетная запись, которой назначается временный пароль.

2. Этой учетной записи назначаются необходимые роли Platform V Audit SE (AUD) (одна роль или несколько).

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

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

2. Зарегистрировать требование в Platform V Audit SE (AUD) на внесение изменений в ролевую модель. Ответственные лица со стороны Platform V Audit SE (AUD) (разработчики или администраторы сервиса) добавляют право и роль для просмотра событий ПМ в ролевую модель. Ролевая модель может поставляться через изменения в составе дистрибутива (заказная разработка) или путем правки вручную файла с ролевой моделью на стороне эксплуатирующей стороны.

3. Администраторы сервиса Platform V IAM (SPAS) обновляют ролевую модель модуля Platform V Audit SE (AUD) и синхронизируют ее с СУДИР.

Рекомендации по заданию стойких паролей и смене паролей:

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

• пароль должен быть сложен (обязательно использование строчных и прописных букв и цифр);

• длина пароля – минимум 12 символов;

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

• пароль не должен содержать имя УЗ пользователя или какую-либо его часть;

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

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

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

Ролевая модель#

Описание ролей с правами доступа к функциональности Platform V Audit SE (AUD) представлено в таблице:

Роли пользователей Platform V Audit SE (AUD)

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

2. Аудитор прикладного модуля (ПМ) — это роль с ограниченным доступом к данным, для поиска и просмотра пользователю доступны события только конкретного списка модулей / одного модуля (АС). Имеет несколько вариантов, по одному на каждый отдельный модуль. Добавление таких ролей осуществляется дополнением ролевой модели.

3. Администратор — пользователь с ролью Администратор (Администратор системы) не имеет доступ к событиям аудита. Он может управлять задачами импорта данных из архивного в оперативное хранилище, выполнять импорт из архива, удалять импортированные пользователями коллекции (например, в целях освобождения дискового пространства при срабатывании пороговых значений метрик).

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

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

## --------- PLATFORM CONFIG
platform-commons@access.dev-mode=false
## Флаг включения интеграции с СУД-ИР (по умолчанию — true)
platform-commons@sudir-enabled=false

## --------- LOGGER-CONFIG
## В случае установки флага отключает режим использования централизованной конфигурации. В этом режиме модуль переключается на использование стандартного механизма журналирования согласно стандартному поведению библиотеки logback. Параметры журналирования в этом случае задаются в прикладном коде разработчиками конкретной ФП^M
logger@context.dev.mode=false
## Указывает адреса (через запятую) серверов ZooKeeper, с которых модуль должен загрузить конфигурацию журналирования
logger@config.zookeeper.host=<IP address>:2181

## --------- CLIPAS CONFIG
## Ключ шифрования данных (должен совпадать с ключом spas-config.secret_key
clipas@secret_key=<key>
## URL-адрес REST-API подсистемы доступа
#clipas@spas_server_url=http://<IP address>:8080/spas/rest
clipas@spas_server_url=https://<IP address>:8443/spas/rest

## --------- SPAS CONFIG
spas@Database[GROUP]/ConnectionProperties[main]/jdbc.login=audt_spas
spas@Database[GROUP]/ConnectionProperties[main]/jdbc.password=<password>
spas@Database[GROUP]/ConnectionProperties[main]/jdbc.driver_class=org.postgresql.ds.PGSimpleDataSource
spas@Database[GROUP]/ConnectionProperties[main]/jdbc.connection_test_query=SELECT 1
spas@Database[GROUP]/ConnectionProperties[main]/jdbc.url=jdbc:postgresql://<IP address>:5432/audt_spas
spas@Database[GROUP]/currentConnectionName=main
spas@hibernate.jdbc.lob.non_contextual_creation=true
spas@hibernate.named_query_type=postgres
spas@hibernate.dialect=org.hibernate.dialect.PostgreSQL9Dialect
spas@secret_key=<key>
spas@ABAC[GROUP]/abacEnabled=false

spas@liquibase.context=production
spas@rights_update_on_start=false

Рекомендации по использованию подсистем при интеграции с Platform V Audit SE (AUD)#

Все подсистемы должны эксплуатироваться в соответствии с Руководством администратора и Руководством оператора для этих подсистем.

Сценарии администрирования#

Проверка развертывания транспортного модуля и хранилищ (один из подробных сценариев контроля установки Platform V Audit SE (AUD))#

1. Проверить список адресов кластера хранения:

   1. Подключиться к одному из серверов, на которых развернут транспортный модуль (кластер Corax).

   2. Открыть файл server.properties и найти параметр listeners.

   3. Сравнить список адресов из Cloudera и из файла server.properties.

2. Проверить фактор репликации для сохранения в долговременном хранилище.

Критерии удачной проверки развертывания:

1. Списки серверов кластера хранения и server.properties не имеют пересечений.

2. В долговременном хранилище установлен фактор репликации 3.

Регулярные сценарии мониторинга#

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

• контроль состояния работы всех компонентов Platform V Audit SE (AUD);

• мониторинг производительности всех компонентов Platform V Audit SE (AUD);

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

Сделать это можно с помощью системных метрик и метрик доступности.

Также контролировать работу сервиса можно с помощью логов модулей Platform V Audit SE (AUD) (логи Kafka, логи в Cloudera Manager, логи в OpenShift, логи WildFly или на диске), проверять их на наличие ошибок.

Типичные сценарии работы администраторов#

Используется роль "Администратор" по ролевой системе.

Импорт данных из архива#

Основное действующее лицо (ОДЛ): Администратор.

Цель: Импортировать данные из архива в оперативное хранилище для выполнения поисковых запросов по ним.

Частота применения: по запросу.

1. Администратор указывает параметры поискового запроса к архивному хранилищу. Обязательно указывается период: дата начала и дата окончания.

2. Система выполняет подсчет объема данных.

3. Если импорт возможен, то система инициирует задачу импорта данных в отдельную коллекцию.

4. Система уведомляет администратора о результате по окончании импорта данных.

Восстановление данных в оперативном хранилище#

ОДЛ: Администратор.

Предусловие: Работа оперативного хранилища восстановлена и регистрация событий в системе возобновлена.

1. Администратор инициирует восстановление данных из архива за последние несколько дней.

2. Система импортирует данные из архива в оперативное хранилище, устанавливая для каждого события дату истечения на основе даты создания события.

Администратор контролирует состояния хранилищ#

ОДЛ: Администратор или таймер (системный).

Цель: Контролировать размер хранилища, чтобы не допустить переполнения выделенной под них памяти.

Частота применения: Периодически, предположительно раз в неделю (не чаще раза в сутки).

Пользовательский контроль#

ОДЛ: Администратор.

Предусловие: Администратор получил оповещение о срабатывании какого-либо порогового значения.

Администратор запрашивает размеры оперативного и архивного хранилища и объемы выделенной под них памяти. Система предоставляет размеры хранилищ, объемы выделенной под них памяти, вычисляет процент занятой памяти. Если процент превышает какое-либо пороговое значение, то Система выдает оповещение.

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

Системный контроль#

ОДЛ: Таймер (системный) — для администратора.

Периодически Система вычисляет размеры хранилищ, объемы выделенной под них памяти, вычисляет процент занятой памяти. Если процент превышает какое-либо пороговое значение, то Система выдает оповещение администратору Platform V Audit SE (AUD).

Если превышено второе пороговое значение оперативного хранилища, то Система запускает расчистку старых данных.

Освободить место на дисках#

ОДЛ: Администратор.

Цель: Не допустить переполнения хранилищ.

Частота применения: Периодически, предположительно раз в неделю/месяц.

Удалить данные из оперативного хранилища#

ОДЛ: Администратор.

Цель: Не допустить переполнения оперативного хранилища.

Частота применения: Зависит от заполнения хранилища.

Администратор инициирует удаление данных. После удаления проверяет процент занятой памяти, отведенной под оперативное хранилище. При необходимости администратор повторяет процедуру удаления данных.

Инициировать удаление данных из хранилища Hbase#

ОДЛ: Администратор.

Цель: Не допустить переполнения Hbase.

Частота применения: Зависит от заполнения Hbase.

Администратор инициирует процедуру физического удаления данных из Hbase во время наименьшей нагрузки на Hbase.

Сжать данные в архиве#

ОДЛ: Администратор.

Цель: Сократить размер архива.

Частота применения: не чаще раза в неделю.

Администратор инициирует сжатие данных avro старее 1 месяца (относительно текущей даты) в архиве.

Настроить параметры#

ОДЛ: Администратор.

Цель: Выполнить настройки, обеспечивающие отказоустойчивую работу системы.

Частота применения: При первой пусконаладке системы, а также при последующих изменениях соответствующих бизнес-правил (крайне редко).

Администратор указывает одну или несколько настроек:

• Срок хранения в сутках событий в оперативном хранилище, поступающих от внешних систем.

• Первое пороговое значение для оперативного хранилища в процентах от выделенной памяти. Если размер оперативного хранилища достигнет этого значения, администратор получит уведомление.

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

• Первое и второе пороговое значение для архивного хранилища в процентах от выделенной памяти. Если размер архивного хранилища достигнет этих значений, администратор получит уведомления. При получении уведомления ожидается, что администратор увеличит размер выделенной памяти.

• Настройки выгрузки событий в режиме онлайн в систему мониторинга. Администратор должен настроить выборку данных по критериям, а также маппинг (настройку соответствия) полей.

Действия при нештатных ситуациях#

При выявлении нештатных ситуаций администратору необходимо:

• проверить логи Unimon-agent на наличие ошибок;

• проверить логи Unimon-sender на наличие ошибок.

Периодический контроль по безопасности#

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

• осуществляет контроль использования средств защиты информации;

• осуществляет контроль доступа к обрабатываемым данным пользователями, согласно с их правами доступа к АС.

Ротация коллекций Solr с помощью сервиса audit2-divider и контроль работоспособности оперативного хранилища#

Сведения о событиях, которые пишутся в оперативное хранилище Solr, разделяются на коллекции сервисом audit2-divider. Основные настраиваемые параметры хранения и ротации коллекций:

• Время хранения текущих коллекций оперативного хранилища в Solr.

• Время хранения архивных коллекций, восстановленных из долговременного хранилища.

• Ограничение в UI на длину периода, по которому идет поиск событий.

• Периодичность разделения данных на коллекции и удаления коллекций.

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

Изменен механизм удаления данных из оперативного хранилища. Вместо механизма TTL для документов Solr, коллекции удаляются целиком в соответствии с параметрами хранения. Параметры Solr, которые использовались для удаления данных из коллекций (TTL по полю expiredAt) больше не используются, но оставлены для обратной совместимости.

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

Наименования коллекций в Solr

Архивные коллекции, поднятые из долговременного хранилища в оперативное, имеют название вида archive-date1-date2-timestamp, где date1 - дата начала поднятия, date2 - дата окончания поднятия, timestamp - время поднятия из архива в миллисекундах (в формате Unix time, 13 цифр).

Текущие коллекции, в которые сейчас идет запись, имеют название вида splitted-ae-timestamp, где timestamp - время создания новой коллекции Solr сервисом divider в формате Unix time.

Flume proxy-flume-solr-event записывает события в alias под названием write-alias, в котором находятся коллекции формата splitted-ae-timestamp.

Как производится ротация

1. При развертывании Platform V Audit SE (AUD) автоматически создается alias write-alias и в нем первая коллекция splitted-ae-timestamp.

2. Flume начинает писать данные в write-alias.

3. Запускается сервис divider, и в зависимости от стратегии (например, timebased), проверяет timestamp у коллекции splitted-ae-timestamp. Если timestamp актуальный, разделения на коллекции или удаления не происходит.

4. Периодически divider анализирует текущие коллекции в оперативном хранилище и определяет, в каких коллекциях содержатся события за какой период и записывает эти данные в коллекцию collection-metadata.

5. По истечении заданного времени, divider создает следующую коллекцию splitted-ae-timestamp в write-alias. Предыдущую коллекцию, время жизни которой истекло, divider удаляет из write-alias (но оставляет в Solr).

6. Flume продолжает писать в write-alias, но уже в новую коллекцию.

7. Divider проверяет коллекции в splitted-ae-timestamp и splitted-ae-alias-timestamp на предмет превышения разрешенного времени хранения и удаляет устаревшие коллекции из Solr, а также удаляет и сам alias.

Как производится поиск событий

Поиск событий в UI работает следующим образом:

1. Пользователь указывает диапазон дат для поиска.

2. По результатам данных из collection-metadata, выбираются коллекции, которые содержат события за требуемый период. Также для целей поиска выбираются архивные коллекции (если пользователь выставил флажок в UI) и текущая коллекция splitted-ae-timestamp из write-alias.

Настройки хранения и ротации коллекций в сервисе divider.

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

Рекомендации на случаи неисправности

В случае сбоя (полной неработоспособности или отключения) сервиса divider администратор должен вручную с той же периодичностью, что в настройках divider выполнять следующие манипуляции: создать новую коллекцию splitted-ae-timestamp (где timestamp - время создания коллекции в формате Unix time), добавить её в alias write-alias, исключить из alias write-alias все остальные коллекции. Timestamp должен состоять из 13 цифр, чтобы при возобновлении работы divider происходила автоматическая обработка новой коллекции.

Также потребуется удалять старые коллекции вручную: коллекции splitted-ae-… с самым маленьким значением timestamp и коллекции archive-date1-date2-timestamp.

Делать это можно через Solr Server Web UI. Если этого не делать, то коллекция, в которую ведется запись, будет увеличиваться до бесконечности, что приведет сначала к деградации записи в Solr, затем - к переполнению дисков серверов Solr, и в итоге - к отказу всего сервиса Solr. В результате потребуется восстановление работоспособности сервиса Solr.