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

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

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

Кроме того в ролевой модели UI Platform V Audit SE (AUD) предусмотрены роли ASSupport (Сотрудник сопровождения АС) и PlatformAdmin (Администратор платформы). Смотрите подробнее об этих ролях в разделе ниже – Ролевая модель.

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

Идентификация и аутентификация пользователей осуществляются через IAM Proxy (AUTH), авторизация через Объединенный сервис авторизации (AUTZ), которые являются компонентами сервиса Platform V IAM SE (IAM). Для разграничения доступа к Platform V Audit SE (AUD) используется ролевая модель. На этапе развертывания Platform V Audit SE (AUD) настраивается подключение к Platform V IAM SE (IAM) путем установки настроек в конфигурационном файле os_props.conf. Ролевая модель для сервиса Platform V Audit SE (AUD) загружается в Объединенный сервис авторизации (AUTZ) Platform V IAM SE (IAM) администратором. После этого администратор системы может создавать через IAM Proxy (AUTH) Platform V IAM SE (IAM) учетные записи для пользователей Platform V Audit SE (AUD) и назначать нужные права пользователям в соответствии с ролевой моделью. После этого пользователи смогут авторизоваться в Platform V Audit SE (AUD). Пользователю назначается одна из ролей, описанных в разделе Ролевая модель.

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

1. В IAM Proxy (AUTH) Platform V IAM SE (IAM) создается учетная запись, которой назначается временный пароль.

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

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

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

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

3. Администраторы сервиса Объединенный сервис авторизации (AUTZ) Platform V IAM SE (IAM) обновляют ролевую модель модуля Platform V Audit SE (AUD).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используется роль "ASSupport (Сотрудник сопровождения АС)" по ролевой системе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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