Руководство администратора MIND Guard #guest 2.16-1

Термины и сокращения

MIND Suite

Программный комплекс, разработанный компанией MIND Software, предназначенный для репликации IT-сервисов.

MIND Guard #guest

Модуль комплекса MIND Suite, предназначенный для защиты и аварийного восстановления IT-сервисов.

KTMU

Kernel Tools with MIND Utilities - загрузочный ISO-образ, содержащий базовую ОС, драйверы для различных устройств и набор утилит MIND, используемый приёмником для загрузки во временную ОС для репликации.

CBT-журнал

Файл, в котором хранится карта блоков данных, измененных с момента последней синхронизации. CBT-журналы создаются для каждого исходного диска на источнике, после чего с их помощью источник определяет данные, которые требуется передать на приёмник.

Агент

Сервис, который запускается на источнике или приёмнике и взаимодействует с контроллером в процессе настройки и запуска заданий на репликацию. Каждый агент имеет уникальный идентификатор и регистрируется на конкретном экземпляре контроллера. Агент получает и выполняет команды с контроллера, ведет журнал событий, запускает хост-утилиты и отправляет контроллеру информацию о статусе заданий. Может устанавливаться в ручном режиме или автоматически.

Журнальный диск

Выделенное блочное устройство, путь к каталогу в файловой системе или RAM-диск, используемый для хранения CBT-журналов на источнике и приёмнике. Журнальный диск снижает нагрузку на исходные и целевые диски и уменьшает требования к свободному месту при синхронизации. При репликации данных использование журнального диска на приёмнике обязательно.

Источник

Машина, с которой выполняется копирование (синхронизация) данных на приёмник в процессе выполнения репликации. Источник содержит исходную операционную систему, приложения, данные и настройки, которые переносятся на приёмник.

Контроллер

Центральный компонент MIND Suite. Выступает в роли оркестратора для реализации функций управления и контроля за выполнением заданий репликации, координирует работу компонентов, хранит конфигурацию и предоставляет интерфейс взаимодействия (GUI и API) для пользователей и администраторов. Контроллер устанавливается на выделенный сервер под управлением совместимой ОС Linux и состоит из набора взаимодействующих между собой сервисов, работающих в виде нативных сервисов systemd и внутри контейнеров: API, Scheduler, Vault, Postgres, RabbitMQ и других.

Машина

Виртуальная машина, физическая рабочая станция или сервер зарегистрированная на контроллере для использования в качестве источника или приёмника в заданиях репликации.

Приёмник

Машина, на которую выполняется копирование (синхронизация) данных с источника в процессе выполнения репликации. После завершения процесса приёмник содержит копию ОС, данных и приложений, идентичную источнику.

Прокси-группа

Логическое объединение из одного или нескольких прокси-серверов. При назначении машине прокси-группы агент выбирает один из серверов и использует его как промежуточный узел для сетевого взаимодействия с контроллером или другой машиной в задании репликации. При отказе сервера агент автоматически переключается на другой доступный сервер группы.

Прокси-сервер

Выделенная виртуальная машина или физический сервер с ОС Linux и установленным прокси-агентом; выполняет опциональную роль промежуточного узла для передачи трафика между источником и приёмником либо между машинами и контроллером при отсутствии прямой сетевой связности.

Синхронизация

Процесс передачи данных от источника к приёмнику для поддержания их в консистентном состоянии. MIND Suite поддерживает два варианта синхронизации - первичную (полную) и периодическую (дельта-синхронизацию). Первичная синхронизация выполняется при первом запуске задания репликации для полного копирования данных с исходных дисков источника на целевые диски приёмника. Периодическая синхронизация использует снапшоты для передачи изменений, которые появились на источнике с момента последней синхронизации. Периодическая синхронизация может выполняться по расписанию через заданные интервалы времени или вручную перед переключением.

Снапшот

Моментальный снимок диска, создаваемый при каждой итерации синхронизации данных. Используется для формирования CBT-журналов для отслеживания измененных блоков. При синхронизации данных в ОС семейства Windows используется механизм Volume Shadow Copy Service (VSS), в ОС Linux используется mindbd.

Назначение

Традиционные подходы к обеспечению непрерывной репликации и аварийному восстановлению данных сопряжены с рядом сложностей:

• Отсутствие универсального подхода по защите различных сервисов и приложений, работающих как на ОС Linux, так и на ОС Windows.

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

Модуль MIND Guard #guest в составе MIND Suite позволяет решить эти проблемы и обеспечить единый подход к защите сервисов и данных с требуемыми показателями RPO и RTO, работающих на физических серверах или виртуальных машинах.

Центральным компонентом MIND Suite является контроллер, который обеспечивает единую точку управления и контроля заданий репликации и восстановления, хранит конфигурации и журналы работы системы, выполняет мониторинг состояния компонентов системы, а также предоставляет графический интерфейс и интерфейс для запуска API вызовов.

Сценарии защиты и восстановления

MIND Guard #guest позволяет реализовать следующие сценарии защиты и восстановления сервисов:

1. Защита от отказа оборудования или площадки

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

2. Кроссплатформенная защита

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

3. Быстрое восстановление после потери данных

   Защита сервисов от сбоев, приводящих к потерям данных из-за логической ошибки, человеческого фактора или вредоносного ПО (вирусы-шифровальщики).

4. Развертывание тестовых стендов

   Простое и быстрое создание идентичных копий производственных сервисов и приложения для задач разработки и тестирования с возможностью интеграции с инструментами CI/CD для автоматизации.

Дополнительная информация о поддерживаемых сценариях, конфигурациях и имеющихся ограничениях продукта приведена в документе «Матрица совместимости MIND Suite».

Поддерживаемая инфраструктура

Подробная информация о поддерживаемых операционных системах, гипервизорах, платформах виртуализации и облачных платформах для MIND Guard #guest приведена в документе «Матрица совместимости MIND Suite».

Общесистемные сервисы и порты

Перечень протоколов и портов, которые используются для взаимодействия между компонентами MIND Suite и внешними сервисами, приведён в разделе Приложение > Протоколы и порты.

Для работы контроллера и ОС могут использоваться общесистемные сервисы:

Направление	Сервис	Порт/протокол	Назначение
Исходящие	DNS	TCP/UDP 53	Разрешение доменных имён
Исходящие	NTP	UDP 123	Синхронизация времени с сетевыми серверами времени
Входящие	SSH	TCP 22	Удалённый доступ с шифрованием соединения

Для повышения безопасности контроллера настройте встроенный межсетевой экран ОС так, чтобы разрешить только трафик по портам и протоколам, необходимым для работы ПО MIND Suite и ОС Linux, а весь остальной трафик заблокировать.

Технология создания моментального снимка

Windows

Для обеспечения целостности данных при выполнении репликации используется стандартная служба снимков томов Microsoft Volume Snapshot Service (VSS), встроенная в гостевую операционную систему Windows. VSS позволяет создавать согласованные снимки томов без остановки работы приложений и служб в виртуальной машине.

Важно

Корректная работа VSS зависит от актуальности установленных компонентов операционной системы. Перед выполнением репликации рекомендуется проверить, что на исходной виртуальной машине установлены все последние обновления Windows. Это позволит избежать ошибок при создании снимков.

Linux

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

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

Особенности драйвера:

• Не зависит от установленного в системе программного обеспечения.

• Содержит полный комплект необходимых библиотек и компонентов.

• Работает полностью автономно в пределах своей версии.

Драйвер копируется на источник и приёмник автоматически в ходе выполнения задания репликации и удаляется автоматически сразу после завершения процесса репликации.

Группы консистентности

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

Производительность

Фактическая производительность и скорость выполнения репликаций с использованием MIND Guard #guest зависят от множества факторов, включая:

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

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

• конфигурацию сети и текущую доступную пропускную способность;

• количество дисковых устройств на источнике и их общий объём;

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

• количество одновременно выполняемых репликаций;

• включение опции шифрования данных;

• включение опции сжатия данных.

При подготовке к масштабным проектам рекомендуется:

• провести одиночную тестовую репликацию с типичной нагрузкой;

• зафиксировать полученные метрики скорости и загрузки ресурсов;

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

Многопоточность

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

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

Сжатие данных

Для операционных систем Linux в MIND Guard #guest поддерживается динамическое потоковое сжатие данных с использованием алгоритма Zstandard (zstd). Сжатие выполняется как при первичной репликации, так и при последующей досинхронизации данных.

Механизм работы

При передаче данных от источника к приёмнику агент MIND применяет встроенный механизм компрессии на основе Zstandard, что позволяет:

• снизить утилизацию сетевых каналов, особенно на линиях с пропускной способностью менее 5Гбит/с;

• достичь среднего коэффициента сжатия порядка 2.4:1.

Нагрузочные характеристики

Использование компрессии сопровождается дополнительной загрузкой процессора источника — до 50% одного ядра. Фактические показатели степени сжатия и загрузки процессора зависят от типа передаваемых данных и текущей нагрузки на систему.

Рекомендации по использованию

• Включение компрессии целесообразно на каналах с ограниченной пропускной способностью.

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

Время синхронизации

Время ресинхронизации позволяет устанавливать время задержки между двумя интервалами передачи изменений при репликации. По умолчанию интервал ресинхронизации равен 0, что означает, что следующая ресинхронизация начнётся сразу же после завершения предыдущей для обеспечения минимального RPO.

Ресинхронизация требует создания снапшотов (COW-журналов), что приводит к кратковременному росту утилизации процессора, поэтому для снижения нагрузки на дисковую подсистему и процессор можно увеличить значение данного параметра.

Шифрование данных

Для операционных систем Windows и Linux поддерживается возможность шифрования соединения между источником и приёмником. При включении данной опции данные передаются по защищённому каналу.

Механизм работы

При установке защищённого соединения:

• автоматически создаётся уникальный pre-shared TLS-ключ для данного подключения;

• формируется временная учётная запись TLS для аутентификации.

Эти параметры используются:

• для взаимной аутентификации источника и приёмника (проверка прав доступа);

• для шифрования содержимого передаваемых данных на всём пути между системами.

Технологии

Pre-shared TLS-ключ генерируется с использованием библиотеки GnuTLS Transport Layer Security Library, обеспечивающей реализацию протоколов TLS и соответствующую криптографическую стойкость.

Использование выделенных журнальных дисков

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

Назначение

Использование выделенных журнальных дисков позволяет:

• снизить нагрузку на дисковую подсистему источника;

• уменьшить утилизацию СХД, на которой расположены диски реплицируемой виртуальной машины;

• обеспечить консистентность данных на приёмнике на всём протяжении репликации;

• обеспечить возможность возврата производственной нагрузки на источник (failback) после завершения репликации.

Настройка

При создании задания репликации можно указать расположение журналов следующим образом: выбрать выделенное блочное устройство (диск) — например, диск, размещённый на отдельной СХД.

Выбор подходящего устройства зависит от архитектуры инфраструктуры и доступных ресурсов.

Ограничение пропускной способности канала

На этапе конфигурации задания репликации предусмотрена возможность задать ограничение скорости передачи данных с источника на приёмник.

При этом MIND Guard #guest не накладывает ограничений на использование любых внешних технических средств, реализующих аналогичную функцию — например, через механизмы сетевого или дискового контроля, доступные в инфраструктуре пользователя.

Настройка ограничения скорости

• Для заданий репликации можно установить лимит на максимальную скорость чтения данных с дисков источника в диапазоне от 10 Мбит/с до 100 Гбит/с.

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

• По умолчанию при создании нового задания ограничение не задаётся — используется максимальный лимит скорости 100 Гбит/с.

Важно

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

Безопасность и конфиденциальность

Взаимодействие с антивирусным ПО

В процессе своей работы MIND Suite использует набор низкоуровневых утилит и драйверов и выполняет различные системные вызовы, что может быть расценено антивирусным ПО как потенциально вредоносная активность.

Компания MIND Software выполняет регулярную проверку и отправку обновлённых версий компонентов MIND Suite для добавления в списки исключений (белые списки) средств антивирусной защиты, разрабатываемых АО «Лаборатория Касперского».

В случае использования иных решений обеспечения антивирусной защиты, для исключения их влияния на работу MIND Suite рекомендуется выполнить следующие настройки.

Настройка исключения антивирусного ПО для источников и приёмников на ОС Windows

Добавить в исключение из проверки следующие каталоги и файлы:

{OS_drive}:\MIND\
{OS_drive}:\Program Files\mind\
{OS_drive}:\Windows\winexesvc.exe

Пример настройки исключений для антивирусного ПО Windows Defender приведён в документе «Руководство пользователя MIND Migrate #guest» в разделе Подготовка машин на ОС Windows.

Настройка исключения антивирусного ПО для источников и приёмников на ОС Linux

Добавить в исключение из проверки следующие каталоги и файлы:

/mind
/opt/mind

Безопасное подключение

Поддерживается возможность конфигурации контроллера MIND Suite для подключения к его веб-интерфейсу посредством защищённого протокола HTTPS (с использованием TLS). Шаги настройки описаны в разделе Настройка доступа к контроллеру по протоколам HTTP и HTTPS.

Между источником и приёмником должно быть обеспечено сетевое соединение L3, так как перенос данных прикладной среды между ними осуществляется напрямую, при этом на машину-контроллер никакие данные с источника или приёмника не передаются и не сохраняются.

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

Kerberos

Поддерживается возможность конфигурации контроллера MIND Suite для репликации машин под управлением ОС Windows, находящихся в Active Directory, где используется аутентификация посредством протокола Kerberos.

Сохранность учётных данных

Во время настройки заданий на репликацию в графическом интерфейсе MIND Guard #guest пользователю будет предложено создать связки ключей доступа к исходной и целевой машинам. Эти данные добавляются в хранилища MIND Vault — базу данных на стороне контроллера.

Чувствительные данные (пароли, ssh-ключ, ssh-key passphrase) хранятся в зашифрованном виде.

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

В текущей версии поддерживается добавление ключей, сгенерированных в формате OpenSSH.

Важно

Ключи доступа заводятся в рамках тенанта. После этого все ключи, заведённые в рамках конкретного тенанта, доступны для любых задач репликации в рамках этого тенанта.

Авторизация и аутентификация

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

Смена стандартных учётных записей микросервисов

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

Инструкции по изменению логинов и паролей для баз данных и хранения метрик, менеджера очередей, хранилища журналов и служб приведены в документе «Руководство по обеспечению безопасности MIND Suite».

Настройка хранения событий в системных журналах

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

1. Установите значение SystemMaxUse=10G (максимальный размер, отводимый под системные журналы — 10 ГБ) в секции [Journal] в файле etc/systemd/journald.conf.

2. Перезапустите сервис с помощью команды:

sudo systemctl restart systemd-journald.service

Настройка длительности хранения журналов события на контроллере

События, не относящиеся к событиям информационной безопасности, по умолчанию хранятся в базе VictoriaLogs на протяжении 7 дней.

Для изменения срока хранения добавьте в /opt/mind/etc/config.yml в секцию logs: retentionperiod: в интервале от 1d (1 день) до 100y (100 лет). Например:

-retentionPeriod=2d

После этого перезапустите сервис:

sudo systemctl restart mind_logs.service

Устройство MIND Suite

На уровне сервисов в MIND Suite задействованы следующие компоненты.

NGINX

Web-сервер, который обслуживает внешние подключения по протоколу HTTP(s) со стороны администраторов и агентов, а также запросы к API от других сервисов контроллера. За работу компонента отвечает сервис nginx.service, параметры запуска сервиса описаны в файле lib/systemd/system/nginx.service.

Настройка Nginx выполняется через конфигурационные файлы /etc/nginx/sites-enabled/controller.conf и /etc/nginx/nginx.conf.

TaskWorker

Отвечает за установку и настройку агентов на машинах, а также за отслеживание их состояния. За работу компонента отвечает сервис mind_taskworker.service, параметры запуска сервиса описаны в etc/systemd/system/mind_taskworker.service.

Настройка TaskWorker выполняется через конфигурационный файл /opt/mind/etc/config.yml.

JobWorker

Управляет первичной синхронизацией и репликацией данных и отслеживает статус заданий. За работу компонента отвечает сервис JobWorker.service, параметры запуска описаны в /etc/systemd/system/mind_jobworker.service.

Настройка JobWorker выполняется через конфигурационный файл /opt/mind/etc/config.yml.

SiteWorker

Управляет задачами автоматизации создания приёмников и импорта источников с платформы виртуализации. За работу компонента отвечает сервис mind_siteworker.service, параметры запуска сервиса описаны в etc/systemd/system/mind_siteworker.service.

Настройка SiteWorker выполняется через конфигурационный файл /opt/mind/etc/config.yml.

HealthManager

Выполняет мониторинг работы контроллера, включая сбор и передачу метрик в InfluxDB. За работу компонента отвечает сервис mind_healthmanager.service, параметры сервиса описаны в etc/systemd/system/mind_healthmanager.service.

Настройка HealthManager выполняется через конфигурационный файл /opt/mind/etc/config.yml.

API

Обеспечивает взаимодействие с контроллером с помощью RESTful API. За работу компонента отвечает сервис mind_api.service, параметры запуска описаны в /etc/systemd/system/mind_api.service.

Настройка API выполняется через конфигурационный файл /opt/mind/etc/config.yml.

Scheduler

Планировщик заданий, который отвечает за управление планами репликаций. Подключается к брокеру сообщений RabbitMQ для получения и разбора задания с последующей публикацией заданий для сервиса Jobworker. За работу компонента отвечает сервис mind_scheduler.service, параметры запуска описаны в /etc/systemd/system/mind_scheduler.service.

RabbitMQ

Брокер сообщений, используемый для передачи данных между компонентами контроллера. RabbitMQ запускается внутри контейнера mind-rabbitmq. За запуск контейнера отвечает сервис mind_rabbitmq.service, параметры запуска описаны в /etc/systemd/system/mind_rabbitmq.service.

Настройка RabbitMQ выполняется через конфигурационный файл /opt/mind/etc/config.yml.

PostgresPRO

База данных контроллера, хранящая конфигурацию, заданий, тенантов, машин, пользователей и других объектов. Экземпляр PostgresPRO в контейнере mind-postgres. За запуск контейнера отвечает сервис mind_postgres.service, параметры запуска описаны в /etc/systemd/system/mind_postgres.service.

Настройка PostgresPRO выполняется через конфигурационный файл /opt/mind/etc/config.yml.

InfluxDB

База данных, хранящая метрики компонента мониторинга HealthManager. Экземпляр InfluxDB работает в контейнере mind-influxdb. За запуск контейнера отвечает сервис mind_influxdb.service, параметры запуска описаны в /etc/systemd/system/mind_influxdb.service.

Настройка InfluxDB выполняется через конфигурационный файл /opt/mind/etc/config.yml.

VictoriaLogs

Компонент для сбора и хранения журналов событий. Экземпляр VictoriaLogs работает в контейнере mind-logs. За запуск контейнера отвечает сервис mind_logs.service, параметры запуска описаны в /etc/systemd/system/mind_logs.service.

Настройка VictoriaLogs выполняется через конфигурационный файл /opt/mind/etc/config.yml.

Vault

Компонент для интеграции с внешними системами хранения секретов на базе SecMan. За работу компонента отвечает сервис mind_vaults.service, параметры запуска описаны в /etc/systemd/system/mind_vaults.service.

MIND System

Сервис отвечает за первоначальную настройку контроллера, считывание и сохранение настроек контроллера через веб-интерфейс. За работу компонента отвечает сервис mind_system.service, параметры запуска описаны в /etc/systemd/system/mind_system.service.

MIND drworker

Компонент управления планами аварийного восстановления. За работу компонента отвечает сервис mind_drworker.service, параметры запуска описаны в /etc/systemd/system/mind_drworker.service.

mind-ctrl.target

Отвечает за запуск и перезапуск сервисов MIND mind_taskworker.service, mind_jobworker.service, mind_siteworker.service, mind_healthmanager.service, mind_api.service, mind_scheduler.service, mind_vaults.service, mind_system.service на контроллере в правильном порядке.

Параметры запуска описаны в /etc/systemd/system/mind-ctrl.target.

В портфель решений программного комплекса MIND Suite на данный момент входят модули по переносу рабочей нагрузки между платформами: MIND Migrate #guest для миграции и MIND Guard #guest для репликации данных, а также драйверы и агент MIND, необходимые для выполнения заданий на репликацию.

Обзор контроллера

Контроллер — виртуальная машина с основной панелью доступа к инструментам комплекса MIND Suite. Данная машина рекомендуется к размещению в том же сетевом контуре, где будет находиться приёмник.

Единый интерфейс с многопользовательским разграничением прав доступа позволяет контролировать выполнение параллельных задач по репликации в условиях корпоративной среды, а его доступность посредством RESTful API обеспечивает эффективную интеграцию с уже имеющимися порталами самообслуживания, системами автоматизации, DevOps-инструментами или средствами мониторинга.

Контроллер разворачивается на физическом сервере или ВМ с помощью предоставляемых скриптов из заранее подготовленного пакета и не требует доступа к Интернету. Контроллер управляет ходом выполнения заданий по репликации, но не участвует в процессе копирования данных, который происходит напрямую от источника к приёмнику.

Для проведения репликации на контроллере требуется наличие драйвера, представляющего собой набор заранее подготовленных под конкретную версию ОС модуля ядра и исполняемых утилит.

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

Драйверы для MIND Suite можно скачать в Личном Кабинете Пользователя в разделе Загрузки.

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

Настройка доступа к контроллеру по протоколам HTTP и HTTPS

Интерфейс управления платформой MIND Suite работает за обратным прокси NGINX, который транслирует внешние запросы на внутренние сервисы контроллера. Для настройки шифрованного канала передачи данных необходимо иметь сертификат и приватный ключ для вашего домена. Также требуется сертификат Удостоверяющего Центра, который выдал сертификат. Все эти файлы следует разместить на файловой системе контроллера MIND Suite.

Важно

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

Доступ к контроллеру по HTTP и HTTPS

По умолчанию контроллер принимает входящие подключения по протоколам HTTP (порт TCP 80) и HTTPS (порт TCP 443). Для изменения порта, на котором будет доступен веб-интерфейс контроллера, отредактируйте один из блоков в файле /etc/nginx/sites-enabled/controller.conf.

Для изменения порта подключения по протоколу HTTP измените порт 80 на требуемый в блоке:

server {
listen 80 default_server;
}

Для изменения порта подключения по протоколу HTTPS измените порт 443 на требуемый в блоке:

server {
listen 443 ssl;
}

Перезапустите сервис nginx:

sudo systemctl restart nginx

Работа контроллера с сертификатами

При установке ПО MIND Suite на контроллере автоматически создаются самоподписанные сертификаты корневого Удостоверяющего Центра (УЦ) и сервера для организации зашифрованного канала передачи данных при подключении к контроллеру по HTTPS. Информация о замене сертификата приведена в разделе Работа контроллера с сертификатами. Контроллер поддерживает TLS версии v1.2 и v1.3.

На контроллере файлы сертификатов размещаются в каталоге /opt/mind/etc/tls:

• ca.mindsw.io.pem — X.509 сертификат корневого УЦ в формате Base64;

• ca.mindsw.io.key — закрытый ключ сертификата корневого УЦ;

• tls.mindsw.io.pem — X.509 цифровой сертификат сервера в формате Base64;

• tls.mindsw.io.key — закрытый ключ сертификата сервера.

Для обеспечения безопасного подключения к контроллеру замените самоподписанные сертификаты сервера и корневого УЦ на сертификаты, выданные доверенным корпоративным или публичным УЦ.

Важно

При установке агента MIND сертификат корневого УЦ ca.mindsw.io.pem, используемый контроллером, сохраняется на машине в каталог установки /opt/mind/etc/tls — для Linux и %ProgramFiles%\mind\ — для Windows.

При замене сертификата сервера или УЦ на контроллере переустановите агент для обновления файла ca.mindsw.io.pem или скопируйте обновлённый сертификат корневого УЦ в соответствующий каталог на машине и перезапустите агент MIND.

При необходимости использования собственных TLS-сертификатов подготовьте каталог с файлами:

• ca.mindsw.key;

• ca.mindsw.pem;

• tls.mindsw.key;

• tls.mindsw.pem;

• custom.mindsw.pem.

Эти файлы будут скопированы в каталог /opt/mind/etc/tls.

Подробная информация по замене сертификатов приведена в разделе Сертификат.

Драйверы MIND

Драйверы используются для снятия и передачи моментальных снимков в ходе выполнения задания на репликацию. Они не требуют пакетной установки в системе и представляют собой набор заранее подготовленных под определённую версию ОС модуля ядра и исполняемых утилит, которые не имеют каких-либо дополнительных зависимостей от системного ПО и содержат весь перечень библиотек и компонентов, необходимых для своей работы. В MIND Suite существует механизм валидации драйверов для более строгой проверки целостности и соответствия метаданных.

Драйвер состоит из следующих компонентов:

• модуль ядра для работы с блочными устройствами;

• модуль, обеспечивающий снятие снимков;

• модуль, отслеживающий изменение блоков (механизм CBT);

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

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

Важно

Для задач репликации доступны все драйверы, зарегистрированные на данном контроллере MIND Suite.

Механизм валидации утилит хоста

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

Для обеспечения доверенной модели исполнения утилит хоста реализован механизм криптографической валидации на стороне агента. Основные принципы:

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

2. Агент перед запуском каждой утилиты проверяет её подпись, используя встроенный открытый ключ.

3. Если утилита будет не подписана, то при использовании контроллером этой утилиты в интерфейсе отобразится ошибка, а также сформируется запись в логах аудита.

Агент MIND

Компонент взаимодействия контроллера с машинами, использующий для связи протокол WebSocket; устанавливается на источник и приёмник автоматически (с предоставлением доступов) или вручную (предоставление доступов не требуется).

В процессе работы установленный агент MIND и утилиты хоста взаимодействуют с различными компонентами ОС, включая файловую систему, файлы конфигурации и сервисы. Перечень взаимодействий приведён в документе «Руководство по обеспечению безопасности MIND Suite».

MIND Guard #guest

Модуль для автоматической репликации облачной инфраструктуры обеспечивает постоянную асинхронную репликацию данных. Модуль используется для сценариев Disaster Recovery с соблюдением RPO.

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

RPO (Recovery Point Objective) — цель точки восстановления.

Если после первичной синхронизации последующая передача изменённых данных с источника на приёмник успевает произойти за установленное время (по умолчанию 300 секунд), то в интерфейсе MIND Guard #guest в сводке данных по репликации отобразится зелёный индикатор состояния RPO.

Во время передачи входят все этапы репликации. Если передать изменённые данные за заданное количество секунд не получается (например, их очень много), тогда RPO будет расти, а в интерфейсе отобразится жёлтый индикатор состояния RPO.

Важно

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

RTO (Recovery Time Objective) — время восстановления.

Показатель RTO определяется тем, что пользователю не нужно восстанавливать данные из копии, они уже на приёмнике. Здесь только требуется выключить репликацию и перезагрузить ВМ.

Терминология MIND Guard #guest

Машина (Unit)

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

На обеих машинах запускаются сервисы агента, которые взаимодействуют с контроллером MIND и между собой для обеспечения репликации данных.

Проект (Project)

Контейнер, используемый для логической группировки объектов, используемых в репликации, таких как машины, задания, сайты для более удобной организации работы. Проекты могут использоваться для разделения объектов по организационному признаку — объекты разных подразделений относятся к разным проектам, по сегментам — объекты внешнего и внутреннего контура, по типу приложений — объекты инфраструктурных приложений, объекты для конкретного бизнес-приложения и т. д.

Задание на репликацию (ProtectionSet)

Объект, включающий в себя заранее описанные настройки и инструкции, которые используются для репликации данных между выбранным источником и приёмником. Включает в себя конфигурацию дисков, настройки сетевых интерфейсов, режим передачи данных, сценарии запуска скриптов на различных этапах выполнения задания, настройки времени ресинхронизации, а также расширенные настройки.

Сайт (Site)

Логический объект-контейнер, представляющий собой физическую площадку: серверную комнату, ЦОД, город, которые с точки зрения пользователя MIND Guard являются единой точкой отказа. При регистрации машин на контроллере они привязываются к определённому сайту и могут выступать в качестве источников или приёмников при настройке заданий на репликацию.

Защищённая группа (Protect group)

Объект, позволяющий объединить несколько заданий на репликацию для защиты машин, имеющих единые требования к RPO, например, машины, обеспечивающие работу одного конкретного приложения. При создании защищённой группы требуется выбрать сайт, на котором находятся машины, которые требуется защитить (источники), и сайт, на котором находятся машины, куда будут реплицироваться данные (приёмники). Запуск, остановка и переключение заданий, входящих в защищённую группу, может выполняться как на уровне отдельных заданий, так и на уровне всей группы.

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

Объектная схема взаимодействия в MIND Guard #guest

Архитектура MIND Guard #guest

Архитектура MIND Guard #guest, основные компоненты и взаимодействие между ними приведены на схеме.

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

HostUtil — программный процесс на источнике и приёмнике, выполняющий задачи по репликации данных на стороне источника/приёмника. Отвечает за запуск процессов на источнике/приёмнике и отслеживает их статус, взаимодействует с HostUtil на приёмнике/источнике, оповещает MIND Agent о статусе процессов на источнике/приёмнике.

Data-диск (Источник) — диски на источнике, хранящие информацию, которая необходима для работы защищаемого приложения. Содержимое этого диска реплицируется с поставленным ему в соответствие диском на приёмнике.

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

Журнальный диск (Источник) — диск, который используется при защите высоконагруженных приложений/при недостатке места на data-дисках источника для хранения снапшота и stash-файлов. Является необязательным.

Журнальный диск (Приёмник) — журнальный диск на приёмнике. Данный диск используется для накопления полученных от источника stash-файлов перед их применением к диску-приёмнику. Один журнальный диск может быть использован для множества data- дисков; важно, чтобы были правильно выбраны объём и производительность.

Stash-файлы (Источник и Приёмник) — файлы, содержащие историю изменений, зарегистрированных на data-дисках, в формате, пригодном для применения этих изменений к дискам приёмника.

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

Data Transfer (Источник) — модуль ядра ОС, который отслеживает IO-операции на data-дисках источника и фиксирует происходящие изменения в виде COW- и CBT-журналов.

Трансмиттер (Источник) — программный процесс на источнике, осуществляющий передачу stash-файлов на приёмник. После успешной передачи stash-файлов на приёмник эти файлы удаляются с источника.

Ресивер (Приёмник) — программный процесс на приёмнике, который реализует получение stash-файлов от источника и их накопление на журнальном диске для последующего применения к дискам на стороне приёмника.

Copy Data Management (MIND CDM) — набор компонентов, обеспечивающий создание моментальных снимков и отслеживание изменённых блоков данных для блочных устройств. Включает модуль ядра mindbd.ko и утилиты mindbdctl, cdm-imager.

Data Transfer Management (MIND DTM) — набор компонентов, обеспечивающий наполнение stash-файлов, их передачу и приём для последующего применения к блочным устройствам на приёмнике. Состоит из утилит dtm-client и dtm-server.

Передатчик (Transmitter) — программный процесс dtm-client на источнике, осуществляющий передачу снапшота и stash-файлов на приёмник.

Приёмник (Receiver) — программный процесс dtm-server на приёмнике, который реализует получение снапшота и stash-файлов от источника и их накопление на журнальном диске для последующего применения к дискам на стороне приёмника.

Сетевая схема MIND Guard #guest

Периодическая инвентаризация источника и приёмника

Во время активной передачи данных при репликации MIND Guard #guest дополнительно выполняет периодическую инвентаризацию источника и приёмника — сбор актуальной информации об их конфигурации (диски, ресурсы и т. д.).

Результат периодической инвентаризации сохраняется на контроллере отдельно от исходной конфигурации, с которой было запущено задание на репликацию, и не затирает её. Для каждой машины фиксируется время последнего обновления. В дальнейшем это позволит сравнивать исходную и текущую конфигурацию машин.

Посмотреть актуальный результат периодической инвентаризации для конкретной машины можно с помощью API. Подробная информация об API-вызовах приведена в документе «Руководство по работе с API».

Управление периодичностью

Периодичность запуска задаётся параметром Период выполнения (discoveryPeriod), общим для всех машин на контроллере.

• Минимальное значение периода — 5 минут. При значении менее 5 минут периодическая инвентаризация не активируется.

• Изменение периода подхватывается агентами динамически, без перезапуска: время следующего запуска пересчитывается от времени предыдущего запуска с учётом нового периода.

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

Работа с прокси-серверами

Прокси-сервер — это опциональный компонент MIND Suite, разворачиваемый на выделенной машине с ОС Linux. Он используется для маршрутизации как пользовательского трафика между источниками и приёмниками в процессе репликации, так и управляющего трафика между машинами и контроллером. Прокси функционирует как транспарентный узел: он не модифицирует и не кеширует данные, скрывает реальные IP-адреса, не проверяет активность соединений и просто перенаправляет потоки с помощью NAT-правил iptables.

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

MIND Suite поддерживает следующие сценарии работы с прокси-серверами:

• Использование двух прокси-серверов: на источнике и приёмнике. В данном режиме исключено какое-либо прямое сетевое взаимодействие между источниками, приёмниками и контроллером. При выполнении репликации источник отправляет данные на прокси-источник, который затем транслирует их на прокси-приёмник, а прокси-приёмник передаёт данные на приёмник.

• Использование одного прокси-сервера: на источнике. При выполнении репликации источник отправляет данные на прокси-источник, который затем передаёт данные на приёмник. Прокси используется не только для передачи данных от источника к приёмнику, но и для связи источника с оркестратором. Приёмник также использует этот прокси для отправки служебного трафика (watermill) на источник, но сам связывается с оркестратором напрямую.

• Использование одного прокси-сервера: на приёмнике. При выполнении репликации источник отправляет данные на прокси-приёмник, который затем передаёт данные на приёмник. Источник напрямую взаимодействует с оркестратором, но для передачи данных и watermill-трафика использует прокси приёмника. Приёмник слушает входящий трафик на открытых портах, принимая его через прокси. Все соединения с оркестратором производятся также через прокси приёмника.

• Работа без прокси-серверов. В данном режиме данные передаются напрямую между источником, приёмником и контроллером.

При использовании прокси с обеих сторон (у источника и у приёмника) автоматически формируются так называемые прокси-пары — соответствия между прокси из группы источника и прокси из группы приёмника. Это обеспечивает однозначность маршрутизации трафика.

Важно

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

Работа с прокси-серверами выполняется в разделе Прокси в веб-интерфейсе контроллера. На вкладке Список отображаются все прокси-серверы, зарегистрированные на данном контроллере.

Важно

В данном разделе отображаются только те прокси-серверы, которые зарегистрированы на текущем контроллере MIND Suite. Один прокси-сервер может быть привязан только к одному контроллеру; использование одного и того же прокси несколькими контроллерами не поддерживается.

На вкладке Прокси группы отображаются группы, включающие один или несколько прокси-серверов.

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

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

• Имя — название записи для отображения в интерфейсе MIND;

• IP/FQDN — статический адрес машины или её полное доменное имя.

• Расширенные настройки:

  • Порт SSH — открытый порт для удалённого подключения к машине. По умолчанию — 22 для SSH.

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

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

Подробная информация по работе с агентами приведена в документе «Руководство пользователя MIND Guard #guest».

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

Примечание

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

Для создания новой группы требуется перейти на вкладку Прокси группы и нажать на кнопку + Добавить. В открывшейся форме необходимо выбрать прокси-серверы, которые необходимо включить в группу, отметив их флажком. Затем необходимо ввести название группы в поле Имя и нажать Сохранить.

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

Важно

Все прокси-серверы в группе используют одинаковый набор NAT-правил iptables, синхронизируемых с контроллером. Прокси-агент периодически пингует оркестратор, проверяя актуальность правил. При несоответствии правила загружаются заново через API, после чего старые удаляются, а новые применяются автоматически.

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

Влияние прокси-серверов на RPO

Базовая конфигурация MIND Guard предполагает репликацию в режиме «точка-точка», при которой данные напрямую передаются от источника к приёмнику без участия промежуточных вычислительных узлов. Такая схема обеспечивает минимально возможную задержку доставки данных и, соответственно, наилучшее значение RPO, ограниченное в основном скоростью генерации и передачи данных, а также производительностью приёмника.

При использовании прокси-серверов в архитектуре (например, при необходимости маршрутизации трафика через DMZ или для централизации точек входа/выхода) данные проходят через дополнительный промежуточный узел. Он функционирует как транспарентный сетевой прокси: перенаправляет потоки данных с помощью механизмов на базе iptables, без модификации содержимого и без существенной задержки.

Влияние на RPO:

• Минимальное при малой нагрузке: в условиях, когда прокси обслуживает ограниченное количество репликационных потоков, его влияние на задержки передачи данных пренебрежимо мало, а RPO остаётся близким к показателям при прямом соединении.

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

  • может возникнуть конкуренция за пропускную способность сетевых интерфейсов;

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

Таким образом, сам по себе прокси-сервер не ухудшает RPO, если:

• его сетевой ресурс не исчерпан;

• пропускная способность канала соответствует или превышает объёмы реплицируемых данных.

В режиме работы без прокси-серверов данные передаются напрямую между источником, приёмником и контроллером.

Ресурсы для прокси-серверов

Принцип работы прокси-серверов

Прокси-серверы обеспечивают сетевую связность между компонентами MIND Suite, такими как машины-источники, машины-приёмники и контроллер посредством трансляции сетевых адресов.

Для этого прокси-сервер использует стандартные средства ядра Linux: подсистему iptables и цепочки PREROUTING, DNAT и FORWARD. Такой подход обеспечивает высокую пропускную способность при минимальной нагрузке на процессор и оперативную память, так как не требуется глубокая инспекция или модификация трафика на уровне приложений.

Базовые рекомендации по ресурсам (CPU и RAM)

Поскольку iptables сам по себе не требует значительных вычислительных ресурсов, базовая нагрузка на CPU и RAM остаётся низкой. Однако по мере увеличения числа активных соединений и объёма проходящего трафика возрастает нагрузка на сетевой стек ядра.

Рекомендации по ресурсам приведены на основе обобщённой практики и документации (включая источники от Linux Foundation, Red Hat и Netgate).

Пропускная способность	Рекомендованные ресурсы	Примечания
До 100 Мбит/с	1 vCPU, 512 МБ RAM	Подходит для начального уровня; минимальные задержки
До 500 Мбит/с	1 vCPU, 1 ГБ RAM	Умеренная нагрузка, стабильная работа NAT/iptables
До 1 Гбит/с	2 vCPU, 2 ГБ RAM
До 10 Гбит/с	4 vCPU, 4 ГБ RAM
>10 Гбит/с (high perf)	8 vCPU, 8 ГБ RAM	Возможно iptables начнёт вносить увеличенные задержки

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

1. Оценить трафик репликации:

   • Получить список ВМ, участвующих в репликации через данный прокси.

   • Проанализировать средний и пиковый трафик от каждой ВМ.

   • Просуммировать предполагаемую общую пропускную способность, например:

   ВМ1: 50 Мбит/с
   ВМ2: 120 Мбит/с
   ВМ3: 300 Мбит/с
   Общая пиковая: 470 Мбит/с
   

2. Закладывать резерв. Рекомендуется добавлять минимум 25–50% на рост нагрузки и bursts. Резерв с запасом: 470 Мбит/с * 1.25 = 590 Мбит/с.

3. Назначить ресурсы. В соответствии с таблицей выше, выбирается конфигурация: для ~600 Мбит/с: 2 vCPU и 2 ГБ RAM.

Дополнительные возможности

Снятие первичной диагностической информации

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

На странице задания предусмотрена кнопка Скачать журнал выполнения репликации, которая позволяет получить доступ к этим записям в любой момент, независимо от того, завершилась ли репликация с ошибкой или без.

Нажав эту кнопку, Пользователь может скачать логи задания в формате JSON на своё устройство для более детального анализа или последующего обращения в Службу Технической поддержки MIND.

Объединение в группы

Пользователь может осуществлять групповые действия с обнаруженными на контроллере машинами. После формирования заданий на репликацию из пар машин появляется возможность объединять несколько заданий в Группы с поэтапным выполнением.

Для одной группы применяются единые настройки режима синхронизации, а также доступны групповые действия для добавленных машин — валидация, удаление.

Выполнение скриптов

На этапе конфигурации задания на репликацию пользователь может добавить дополнительные индивидуальные наборы команд или инструкции для выполнения на источнике или приёмнике.

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

Скрипты загружаются Пользователем в тенант и доступны всем пользователям с возможностью работы в рамках тенанта. Сами скрипты хранятся на контроллере в зашифрованном виде и могут быть организованы в Сценарий, определяющий порядок их исполнения. Для Linux-систем поддерживаются языки для написания скриптов Shell и Bash.

Важно

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

Сценарий — это упорядоченная последовательность исполнения скриптов.

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

Так, для удобства использования скриптов предусмотрена возможность запуска скриптов на источнике или приёмнике на разных этапах репликации. Сами этапы репликации разбиты на несколько подэтапов — Начало, Снимки, Завершение.

Начало — подразумевает возможность запускать скрипты в самом начале процесса репликации. Данный подэтап включает возможность запустить скрипты в следующей очерёдности:

• Перед первым снимком;

• После первого снимка;

• После первичной синхронизации.

Снимки — подразумевает возможность запускать скрипты в процессе работы механизма снапшотирования. Данный подэтап включает возможность запустить скрипты в следующей очерёдности:

• Перед каждым снимком;

• После каждого снимка;

• Перед последним снимком;

• После последнего снимка.

Завершение — после финальной синхронизации. Приведённые выше этапы применимы для источника.

Для приёмника предусмотрена возможность запуска скриптов только на этапе завершения процесса репликации. Для ОС Linux скрипт выполняется перед перезагрузкой из режима работы chroot. При этом сами скрипты как на источнике, так и на приёмнике на всех этапах выполняются агентом mind_agent, который работает от пользователя с ролью Администратора.

При исполнении скриптов их содержимое не играет роли. Пользователь может установить политику для каждого скрипта, определяющую реакцию на исключительные ситуации. У каждого скрипта может быть сценарий «фолбэк», т. е. альтернативное действие, которое будет выполнено при возникновении ошибки.

Пользователь может выбрать одну из трёх реакций:

1. Продолжить репликацию.

2. Остановить репликацию с ошибкой.

3. Запустить запасной скрипт.

Контроллер предоставляет возможность отключения механизма скриптов и сценариев. Данная возможность может использоваться для снижения риска запуска неавторизованных команд на источниках или приёмниках в процессе выполнения заданий репликации или защиты машин.

Чтобы отключить скрипты и сценарии, выполните следующие действия:

1. Подключитесь к контроллеру и добавьте в файл opt/mind/etc/config.yml строку disablescripts: true в раздел runmode.

   runmode:
      debug: false ## Set debug mode
      webdebug: false ## Set debug mode for web
      research: false ## If false then check operating system support
      disablescripts: true
   

   Важно

   Параметр debug: true в разделе runmode включает расширенный отладочный режим контроллера. В этом режиме система генерирует большое количество диагностических сообщений и записей в журналах.

   Используйте этот режим только для кратковременной диагностики и поиска неисправностей. Длительное включение режима отладки может привести к быстрому росту объёма журналов, исчерпанию свободного места на диске и повышенному потреблению оперативной памяти.

2. Перезапустите сервис mind_api:

   sudo systemctl restart mind_api.service
   

После отключения скриптов и сценариев вкладка Скрипты исчезнет из графического интерфейса контроллера. Если попытаетесь выполнить REST API-запросы, связанные с просмотром, созданием или редактированием скриптов и сценариев, контроллер вернёт ошибку вида:

{
"error": "Scripts api is disabled",
...
}

Проверка целостности скриптов

При добавлении пользовательских скриптов на контроллер MIND Suite они сохраняются в зашифрованном виде в каталоге /opt/mind/share/userscripts.

Перед запуском задания зашифрованные скрипты передаются на источник и приёмник, где расшифровываются и сохраняются в каталоге /mind/scripts.

В случае подмены скриптов на стороне контроллера или в процессе передачи они не смогут быть расшифрованы агентом и журнале Аудита появится соответствующая запись об ошибке обработки скрипта.

Управление платформой MIND Guard #guest

Управление платформой MIND Guard #guest возможно двумя основными способами: через графический веб-интерфейс или программный интерфейс (REST API). Оба способа обеспечивают удобное и эффективное управление системой согласно потребностям пользователя.

Графический интерфейс (GUI) предоставляет интуитивное и простое в использовании окружение для управления MIND Guard #guest. Пользователь получает доступ ко всем функциям и инструментам, позволяющим настраивать и отслеживать различные этапы репликации. Более детальное описание возможностей GUI можно найти в документе «Руководство пользователя MIND Guard #guest».

Программный интерфейс приложения (API) предоставляет программистам и разработчикам возможность взаимодействовать с MIND Guard #guest напрямую, используя набор API-методов. Это позволяет автоматизировать процессы, интегрировать систему с другими приложениями и настраивать её возможности в соответствии с индивидуальными потребностями и сценариями использования. С описанием API-запросов и примерами ответов можно ознакомиться в интерфейсе Swagger — соответствующий раздел доступен в меню контроллера.

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

Управление ролевой моделью в MIND Guard #guest осуществляется на уровне тенанта — объекта, включающего в себя набор ключей доступа, проектов и машин, доступ к которым предоставляется для пользователей и групп на основании ролевой модели.

MIND Suite использует ролевую модель для управления учётными записями и правами пользователей, а также для определения доступных возможностей репликации: три роли определяют возможности Администратора, ещё три — права и возможности Пользователя.

System Admin — роль даёт права на доступ ко всем API и возможностям платформы.

Security Admin — роль позволяет просматривать объекты платформы.

Platform Operator — роль даёт права на мониторинг и управление конфигурацией платформы без возможности запуска заданий на репликацию, а также позволяет создавать пользователей и их окружения.

Super User — роль позволяет предоставлять доступ к тенантам, полноценно работать с платформой и репликациями, но без возможности создания новых пользователей.

Power User — роль даёт возможность работать с основными объектами платформы кроме действий с тенантами.

User Operator — роль даёт доступ к осуществлению репликаций, но с ограниченным набором действий.

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

Раздел Администрирование

Данный раздел содержит перечень вкладок с инструментами для управления объектами MIND Guard #guest:

• Общие настройки;

• Мониторинг;

• Управление доступами;

• Интеграции.

Общие настройки

В разделе Общие настройки используйте подразделы Публичный адрес, Часовой пояс и Сертификат.

Важно

При авторизации по HTTPS сессионные cookie получают флаги secure и samesite=strict.

При доступе по HTTP cookie получают флаг samesite=strict.

Публичный адрес

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

Важно

После изменения публичного адреса переустановите агентов.

Часовой пояс

В подразделе Часовой пояс выберите часовой пояс в раскрывающемся списке. Используйте эту настройку для отображения времени в интерфейсе.

Сертификат

В подразделе Сертификат проверьте следующие сведения о текущем сертификате контроллера:

• Действителен по;

• Самоподписанный;

• Субъект;

• Издатель;

• Отпечаток.

Используйте поле Отпечаток для проверки контрольного значения сертификата. Значение указано в виде шестнадцатеричных пар, разделённых двоеточиями. При необходимости скопируйте отпечаток кнопкой копирования рядом с полем.

1. Нажмите кнопку Заменить.

2. Оставьте установленным флажок Самоподписанный и нажмите кнопку Генерировать.

3. В окне с предупреждением о недоступности установленных агентов после генерации сертификата нажмите кнопку ОК.

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

Для замены сертификатов на сертификаты доверенного УЦ:

1. Нажмите кнопку Заменить.

2. Снимите флажок с поля Самоподписанный.

3. Заполните поля:

   • Сертификат контроллера — сертификат сервера в формате Base64 (.pem). Пример:

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

   • Приватный ключ сертификата контроллера — закрытый RSA-ключ (.key). Пример:

     -----BEGIN RSA PRIVATE KEY-----
     ...
     -----END RSA PRIVATE KEY-----
     

   • Промежуточный сертификат УЦ — сертификат корневого или промежуточного УЦ, выпустившего сертификат контроллера, в формате Base64 (.pem). Пример:

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

   Важно

   Если вы заменили сертификат сервера или УЦ на контроллере, обновите сертификат корневого УЦ на машинах с агентом одним из способов:

   • переустановите агент, чтобы обновить файл ca.mindsw.io.pem;

   • скопируйте обновлённый сертификат корневого УЦ в каталог установки агента и перезапустите агент.

4. Нажмите кнопку Сохранить.

5. В окне с предупреждением о недоступности установленных агентов нажмите кнопку ОК.

Настройка анимации в интерфейсе

В настройках профиля для работы на медленных каналах можно настроить режим медленных подключений. Данная опция отключит анимацию в интерфейсе и позволит ускорить работу контроллера. Для этого необходимо установить флажок в соответствующем поле.

Мониторинг

Состояние сервисов и системы

На вкладке Состояние сервисов и систем отображена информация о состоянии служб и ресурсов контроллера MIND. В этом разделе осуществляется мониторинг, проверка и оценка состояния запущенных сервисов.

При необходимости возобновления работы сервисов необходимо нажать на Перезапустить напротив соответствующей строки, а в открывшемся окне предупреждения нажать ОК.

Логи

На вкладке Логи просматривайте важную информацию о событиях контроллера и агента MIND.

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

Важно

В системе можно отобразить не более 1 000 событий за один запрос.

Чтобы сохранить отображённые журналы в файл, нажмите Скачать внизу страницы.

Чтобы загрузить полный архив журналов с контроллера, нажмите Скачать полный архив журналов. Используйте этот архив для массового устранения неполадок, связанных с заданиями на репликацию и состоянием контроллера. Архив включает все журналы с Syslog-сервера и JSON-файлы заданий на репликацию.

Примечание

Для активных заданий на репликацию в разделе Проекты нажмите Скачать журнал выполнения репликации.

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

• Загрузить dmesg -T — для Linux;

• Загрузить builder.log — для Windows;

• Загрузить журналы агентов.

Для сбора диагностической информации на контроллере используйте скрипт collect_diagnostic_information.sh, который расположен по пути /opt/mind/bin/. Чтобы запустить скрипт, выполните команду:

bash collect_diagnostic_information.sh

После запуска скрипт формирует архив /tmp/collect_<date>.tar.gz, который включает:

• вывод системных команд df -h, lsblk -f и dmesg -T; для dmesg -T сохраняются последние 2000 строк;

• журналы NGINX из каталога `/var/log/nginx`; для каждого файла сохраняется до 1000 строк;

• данные Podman по контейнерам:

  • конфигурацию контейнеров;

  • журналы контейнеров;

• журналы systemd по сервисам контроллера;

• журналы systemd для контейнерных сервисов, включая сервисы Postgres, RabbitMQ, InfluxDB и сервиса журналов;

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

Примечание

Архив включает журналы systemd для контейнерных сервисов. Это позволяет получить информацию о запусках, падениях и перезапусках контейнеров, даже если журналы самого контейнера недоступны.

Примечание

Если требуется освободить место на диске контроллера, очистите временные директории с инсталляторами агентов через API-метод POST /agent/clear-temporary.

Метод удаляет все директории внутри /opt/mind/tmp/agent и доступен только ролям sysAdmin и platformOperator.

Подробная информация о вызове приведена в документе «Руководство по работе с API».

Аудит

На вкладке Аудит доступен журнал аудита системных событий. События представлены отдельными строками, которые можно отфильтровать по датам, а также произвести поиск по тегам, основывающимся на информации в полях записей.

Для просмотра нужных полей можно воспользоваться элементами прокрутки и управления отображением столбцов в таблице.

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

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

• Поле ID события содержит идентификатор события на контроллере.

• Поле Дата содержит информацию о дате и времени регистрации события на контроллере.

• В поле Субъект операции содержится имя учётной записи, которая сгенерировала событие.

• В поле Критичность содержится описание уровня критичности события. Подробная шкала оценки критичности событий приведена в таблице.

Код	Расшифровка	Комментарий	Примеры событий
0	Informational / Информационный	Информационное сообщение о событии или действии, на которое, как правило, не требуется реагировать каким-либо образом	login success, object create/update/delete success, successful system start (for successful security logging subsystem initialization see «minor security event»)
1	Warning / Предупреждение	Событие, в процессе которого возникла некритичная нештатная ситуация, которая, тем не менее, не помешала завершению действия.	partial object information retrieval/update
2	Error / Ошибка	Событие, в процессе которого возникла ситуация, которая не позволила завершить начатое действие	error when parsing API parameters, internal error when creating/updating/deleting object (for access denial see «minor security event»)
3	Minor security event / Незначительное событие безопасности	Событие, имеющее отношение к сфере информационной безопасности, но не оказывающее критического влияния на MIND Suite или не требующее немедленного реагирования	object access denial, login failure, password change, password reset request, password reset, user create/delete, successful security logging facility start
4	System state change / Изменение состояния системы	Запуск/инициализация системных компонентов MIND Suite, а также сбой внутренних подсистем MIND Suite или внешних информационных сервисов, от которых зависит его функционирование	system facility initialization, process/microservice failure detected, process restart
5	Major security event / Крупное событие безопасности	Событие, имеющее отношение к сфере информационной безопасности, потенциально способное оказать критическое влияние на MIND Suite или требующее немедленного реагирования	user blocked for excessive failed login attempts, login failure while block is active, login attempt by banned user, security policy create/update/enable/disable/delete, user role update, user ban/permit, inability to initialize security logging facility

• Поле Название содержит имя события.

• Поле Адрес объекта операции содержит имя или IP-адрес контроллера, указанный в PublicURL.

• Поле Название хоста содержит имя компьютера или хоста, на котором установлен контроллер.

• Поле Объект операции содержит имя объекта, для которого было сгенерировано событие.

• Поле Роль пользователя содержит роль, назначенную учётной записи пользователя, выполнившего операцию. Подробная информация о ролевой модели приведена в документе «Руководство пользователя MIND Guard #guest».

• Поле ID пользователя содержит уникальный номер пользователя.

• Поле IP-адрес содержит адрес виртуальной машины или рабочей станции, с которой пользователь отправил запрос.

• Поле Класс содержит класс события. Для удобства учёта и анализа все регистрируемые события сгруппированы по классам, каждый из которых объединяет события, сходные по объекту или содержанию действия. Описания классов приведены в таблице.

Класс	Комментарий	Примеры событий
Доступ пользователя	События, возникающие в процессе получения пользователем доступа к MIND Suite или изменения параметров доступа	user login; user logout; user password set
Управление пользователями	События, возникающие в процессе настройки доступа к MIND Suite или прав пользователей	user create; user ban; user role update
Управление объектами	События, связанные с управлением жизненным циклом объектов в MIND Suite (за исключением пользователей и политик) и доступом к ним	project get; unit create; set delete
Управление действиями	События, связанные с запуском, остановкой или мониторингом статуса выполнения процессов, влияющих на объекты	job start; job stop; job get
Управление политиками	События, связанные с управлением жизненным циклом политик, регулирующих различные аспекты работы пользователей и ресурсов MIND Suite	policy create; policy enable; policy update
Системные события	Системные события, связанные с изменением состояния внутренних процессов и сервисов MIND Suite	process failed; process start
Специальный	Сервисные события, служащие для отладки MIND Suite и передачи служебной информации, непосредственно не связанной с задачами аудита важных событий	test

• Значения поля Действие приведены в таблице.

Действие	Описание
logout	Выход из учётной записи
logout	Отключение пользователясессии по таймауту
login	Авторизация в системе
logblock	Запрет на авторизацию пользователя
pwdchng	Изменение пароля пользователя
pwdresetreq	Отмена запроса на изменение пароля пользователя
pwdreset	Сброс пароля
tokeninvalid	Неверный токен
create	Создание объекта
delete	Удаление объекта
get	Получение информации об объекте
update	Обновление информации об объекте
ban	Блокировка пользователя
permit	Разблокировка пользователя
pwdmust	Установка флага обязательной смены пароля
roleupd	Изменение роли пользователя
emailupd	Обновление электронного адреса пользователя
attrupd	Обновление атрибутов объекта
aclupdate	Изменение списков доступа к объекту
start	Запуск действия
stop	Остановка действия
enable	Разрешение действия
disable	Запрет действия
procstart	Попытка запуска системного процесса/инициализация подсистемы
procfail	Неуспешное завершение процесса
syslogstart	Запуск логирования системных событий
testinfo	Логирование тестового события
restart	Перезапуск сервиса

• Поле Тип объекта может быть заполнено одним из следующих значений: Group (группа), Job (задание), Project (проект), Unit (машина), User (пользователь) и т. д.

• В поле ID объекта в случае определения ID задания (Job) используется GUID. Для остальных объектов используется числовое значение. ID — уникальный идентификатор объекта, для которого было выполнено действие.

• В поле Подсистема указывается принадлежность объекта или действия к одному из модулей: Migrate, Guard или Controller.

• Описание события — это расширенная информация о действии, которое было выполнено. Для событий с типом объекта Job в данном поле приводится его внутренний идентификатор (GUID). При перезапуске сервиса через веб-интерфейс в лог записываются логин и идентификатор пользователя, выполнившего действие. Для всех остальных типов объектов приводится текстовое описание события либо пустое поле, если описание не применимо.

• Поле Результат может быть заполнено одним из следующих значений, приведённых в таблице.

Значение	Пример
Успешно	Успешная авторизация пользователя
Сбой	Неуспешная авторизация пользователя из-за неверного пароля
Исключение	Ошибка при обращении к БД в процессе авторизации пользователя

Статистика репликаций

На вкладке Статистика репликаций отображена информация о состоянии прохождения репликаций на контроллере MIND.

Ротация логов

На вкладке Ротация логов выполняется настройка срока хранения и ротации журналов контроллера, а также ротации журнала dtm-server.log в KTMU.

Настройки на вкладке позволяют управлять:

• журналами событий, хранящимися в /var/log/mind;

• журналами аудита;

• событиями, хранящимися в базе VictoriaLogs;

• журналом dtm-server.log в KTMU.

Для управления другими файлами журналов настройте конфигурацию сервиса journald. Информация по настройке приведена в разделе Настройка хранения событий в системных журналах.

Чтобы задать параметры глубины хранения событий, ротации по сроку хранения или объёму данных на диске, переведите переключатель Включено в активное положение. После этого поля формы станут доступны для редактирования:

• Сколько часов хранить логи в БД (час);

• Интервал проверки файлов журналов аудита (сек);

• Интервал ротации файлов журналов аудита (час);

• Максимальное число архивных журналов аудита;

• Максимальный размер суммы файлов api_audit.log и sec_events_audit.log, после которой начинается ротация логов (МБ);

• Максимальный размер файла журнала на машинах (МБ).

В форме Настройка ротации журналов в KTMU настройте ротацию журнала dtm-server.log в KTMU:

• Максимальный размер журнала (МБ);

• Максимальное число архивных журналов.

При достижении заданного размера dtm-server.log сохраняется в архив, а запись продолжается в новый файл журнала. Если количество архивных журналов превышает установленный лимит, система удаляет самые старые файлы.

При настройке через интерфейс архивные файлы журнала сохраняются в формате zip. Максимальное значение для размера журнала и числа архивных журналов — 1024.

Настройки ротации журналов контроллера и KTMU доступны через API.

Примечание

Максимальный размер журналов указывается в МБ.

Управление доступами

Тенанты

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

Чтобы создать новый тенант, нажмите кнопку + Добавить. В открывшейся форме введите название тенанта и нажмите кнопку Сохранить.

Для добавления, просмотра и изменения перечня групп или пользователей необходимо нажать Смотреть напротив строки с названием тенанта. Во всплывающей форме выберите новые для тенанта объекты и нажмите + Добавить.

Для редактирования тенанта нажмите иконку напротив соответствующей строки. Для удаления тенанта нажмите .

Группы

На вкладке Группы Администратор может создать локальную группу, включить в нее пользователей и назначить доступ к определённым тенантам. Для создания группы необходимо нажать кнопку + Добавить.

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

После этого созданная группа отобразится в перечне на вкладке Группы. При нажатии Смотреть в столбце Тенанты или Пользователи можно просмотреть список тенантов, к которым у группы есть доступ, а также пользователей, которые включены в данную группу.

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

Пользователи

На вкладке Пользователи Администратор может просматривать, создавать, редактировать и удалять учётные записи пользователей, а также назначать роли.

Для создания локальной учётной записи пользователя необходимо нажать кнопку + Добавить одного пользователя.

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

После заполнения формы необходимо нажать Сохранить.

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

При нажатии Смотреть в столбце Тенанты или Группы можно просмотреть список тенантов, к которым у пользователя есть доступ, а также группы, в которые включён соответствующий пользователь. Во всплывающей форме можно выбрать новые для пользователя объекты и нажать + Добавить.

Важно

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

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

В столбце Роль каждому пользователю можно назначить нужную роль с определёнными правами, выбрав нужное из выпадающего списка. У одного пользователя может быть несколько ролей, в таком случае права ему назначаются суммарно от каждой роли.

В столбце Статус можно увидеть, активна ли данная учётная запись или заблокирована. Администратор может заблокировать учётную запись, нажав на .

В столбце Действие Администратор может заблокировать учётную запись, нажав на . Для редактирования информации необходимо нажать на напротив соответствующей строки. Для изменения пароля пользователя необходимо нажать на иконку .

В столбце Действие также можно принудительно завершить активные сессии пользователей. Для этого необходимо нажать на напротив соответствующей строки. Отобразится окно предупреждения, в котором необходимо нажать ОК.

Группы LDAP

На вкладке LDAP Администратором осуществляется привязка ролей к группам из LDAP каталога, а также просмотр, редактирование и назначение ролей на группы. Для назначения новой роли нажмите кнопку + Сопоставить роль и группу LDAP:

1. В поле Выберите сервер укажите имя конфигурации для подключения к LDAP серверу.

2. В поле Роль выберите одну или несколько ролей.

3. В поле Тенанты выберите тенант на группу.

4. Нажмите Сохранить.

В случае создания LDAP-групп с ролями superUser, powerUser, userOperator и не указания тенанта, у пользователей группы не будет доступа ни к одному тенанту. В случае создания LDAP-групп с ролями superUser, powerUser, userOperator и предоставления определенного тенанта, у пользователей группы будет доступ к этим определённым или нескольким тенантам.

В поле Запись о группе укажите DistinguishedName группы, которой требуется назначить данную роль. Для этого используйте формат:

distinguishedName:
"cn=Администратор,cn=Users,dc=ldaptest,dc=mind,dc=io".

Если роль необходимо назначить нескольким группам, нажмите кнопку + Добавить группу в карточку роли.

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

Для просмотра и добавления тенанта нажмите на Смотреть в соответствующей записи.

Политики

На вкладке Политики отображается особый набор правил безопасности. Для редактирования необходимо привести переключатель Включено в активное положение.

Для управления политиками паролей доступны следующие настройки:

• Максимальное время жизни пароля (задаётся в секундах) – по умолчанию составляет 5184000 секунд (60 дней).

• Минимальное время жизни пароля (задаётся в секундах) – по умолчанию составляет 0 секунд.

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

• Время блокировки пользователя при превышении числа попыток неправильного ввода (задаётся в секундах) – по умолчанию 16 минут.

• Время блокировки неактивного пользователя (задаётся в секундах) – по умолчанию составляет 45 дней.

• История хранения паролей – по умолчанию не хранит.

• Максимальное время жизни сессии пользователя, с – по умолчанию 86400 секунд (24 часа).

• Минимальная длина пароля – по умолчанию 8 символов.

• Минимальное количество букв в верхнем регистре – по умолчанию не менее 1 символа.

• Минимальное количество букв в нижнем регистре – по умолчанию не менее 1 символа.

• Минимальное количество цифр – по умолчанию не менее 1 символа.

• Минимальное количество спец. символов – по умолчанию не менее 1 символа.

• Пороговое значение для отправки уведомления об истечении срока пароля (задаётся в % от максимального времени жизни пароля) – по умолчанию 90. При превышении порогового значения времени жизни пароля пользователь получит письмо с уведомлением о том, что пароль скоро истечёт.

• Время бездействия – период, в течение которого пользователь не выполняет действий в интерфейсе. По истечении этого времени сессия завершается автоматически. По умолчанию составляет 0 минут.

После внесения изменений необходимо нажать кнопку Сохранить.

Примечание

Если максимальный срок жизни пароля локального пользователя истёк, при следующем входе в веб-интерфейс контроллера откроется форма смены пароля.

Внешние секреты

На вкладке Внешние секреты настройте интеграцию с внешней системой хранения и управления секретами SecMan.

Для добавления нового сервера нажмите + Добавить. В открывшейся форме Добавить сервер заполните следующие поля:

• В поле Название введите произвольное имя хранилища секретов.

• В поле Тип выберите SecMan.

• В поле Параметры подключения введите данные для подключения к серверу, заполнив необходимые поля в шаблоне:

  • serverUrl — адрес внешнего сервера SecMan, к которому будет направляться запрос. Параметр обязательный. Адрес сервера указывайте в формате "serverUrl":"txxxxxx.test.domain.com".

  • MFAMethodID — идентификатор метода аутентификации пользователя. Указывайте его, если пользователь в системе SecMan защищён OTP.

  • namespace — название пространства имён в SecMan. Параметр необязательный. Данные указывайте в формате "namespace":"CIXXYYZZYY_CIIXXYYZZYY".

  • AD — имя LDAP-домена для авторизации в SecMan. Параметр обязательный. Указывайте его в формате "AD":"ad\\external.domain.com".

  • insecure — параметр, который отключает проверку сертификатов. Если указать true, проверка сертификатов выполняться не будет.

Нажмите Сохранить. На вкладке Внешние секреты отобразится созданный сервер с типом SecMan. В разделе Ключи доступа станет доступен выбор типа ключа SecMan.

Для аутентификации на сервере SecMan доступны два способа: Учётные данные AD и OTP и Токен AD.

Выберите Учётные данные AD и OTP, чтобы ввести логин, пароль и OTP. Выберите Токен AD, чтобы ввести токен AD (client_token), полученный в интерфейсе SecMan. При использовании этого способа логин, пароль и OTP вводить не нужно.

Примечание

Токен AD привязан к выбранному внешнему серверу. Если срок действия токена истёк, выполните аутентификацию повторно и введите новый токен.

Примечание

При использовании интеграции с SecMan и ключа типа signed key SSH-ключи контроллера не хранятся на файловой системе на постоянной основе. Файлы /opt/mind/etc/keys/id_rsa и /opt/mind/etc/keys/id_rsa.pub отсутствуют. Ключи хранятся в БД контроллера в зашифрованном виде. Если операции с агентами недоступны из-за повреждённого ключа, перезапустите контроллер. После перезапуска ключи будут сгенерированы повторно, и действия с агентами снова станут доступны.

LDAP серверы

На вкладке LDAP серверы осуществляется привязка ролей Пользователей MIND Suite к группам из каталога LDAP. Для этого нажмите + Добавить и в открывшейся форме заполните поля:

1. В поле Имя сервера введите уникальное имя LDAP сервера;

2. В поле Адрес сервера введите IP-адрес LDAP сервера в формате ldap://<domain_controller_fqdn>:<ldap_port>, например, ldap://controller.example.local:389;

3. Установите флажок Игнорировать проверку SSL сертификата для возможности отключения проверки сертификатов при настройке интеграции с контроллерами домена через ldaps://.

4. В поле Базовый DN введите путь до OU или каталога, где будут размещаться учётные записи пользователей и групп пользователей, для которых требуется предоставлять доступ к контроллеру в формате DistinguishedName. Например, dc=ldaptest,dc=mind,dc=io.

5. В поле Bind DN введите путь до учётной записи пользователя, под которой будет выполняться подключение к контроллеру домена в формате DistinguishedName. Например: cn=Администратор,cn=Users,dc=ldaptest,dc=mind,dc=io.

   Примечание

   Для подключения к контроллеру домена достаточно использовать учётную запись с правами на просмотр содержимого OU и каталогов, а также чтение атрибутов учётных записей пользователей и групп, например, учётной записи, состоящей в группе Domain Users.

6. В поле Пароль введите пароль.

   

7. Выполните тестовое подключение к LDAP с заданными настройками, нажав кнопку Протестировать. В случае неудачного подключения отобразится уведомление с текстом ошибки.

8. Нажмите Сохранить.

Примечание

После добавления LDAP-сервера в интерфейсе в целях безопасности будет скрыто отображение значения полей Базовый DN и Bind DN.

Для настройки подключения к LDAP с TLS выполните следующие действия:

1. Добавьте сертификат LDAP в доверенные на ОС:

   • Поместите сертификат в usr/share/local/ca-certificates (если директория отсутствует, создайте её).

   • В etc/hosts добавьте новую строку с IP-адресом LDAP-сервера и его доменным именем.

   • Выполните команды:

   Для ОС Astra Linux 1.7.7 и Ubuntu Server 24.04:

   cd /usr/share/local/ca-certificates
   sudo update-ca-certificates
   

   Для ОС РЕД ОС 8 и SberLinux 8.10.x:

   cd /usr/share/local/ca-certificates
   sudo update-ca-trust
   sudo update-ca-trust extract
   

2. В интерфейсе MIND Suite перейдите в раздел Администрирование, в списке Управление доступами выберите пункт Группы LDAP и выполните настройку. Подробная информация по настройке приведена в разделе Группы LDAP.

После исправления конфигурации вход с LDAP-пользователем будет успешным.

Kerberos

Для репликации машин под управлением ОС Windows, находящихся в Active Directory с аутентификацией по протоколу Kerberos, выполните следующие действия:

1. Приведите переключатель Включено в активное положение, после чего поля в форме станут доступными для редактирования.

2. В поле Realm по умолчанию введите имя домена.

3. В поле Сервер DC введите серверы контроллера домена через запятую.

4. В поле Сервер аутентификации укажите необходимый сервер.

   

5. Нажмите кнопку Сохранить.

Почта

На странице Администрирование выберите Интеграции | Почта.

Настройте SMTP-оповещения о ходе репликации по электронной почте.

Перечень событий, по которым отправляются оповещения, приведён в таблице.

Тип	Событие
Информация	Запуск задания на репликацию Пауза репликации Возобновление репликации после паузы Остановка Возобновление после остановки Прерывание задания Успешное завершение репликации
Предупреждение	Нарушение RPO Ошибка

Создание правила оповещения

Чтобы создать правило оповещения:

1. Нажмите + Добавить правило.

2. В открывшейся форме заполните поля:

   • Тип оповещения — выберите значение Информация или Предупреждение;

   • Тип объекта — выберите объект, по которому нужно отправлять оповещения;

   • Объект — укажите имя объекта и его [id];

   • Повторная отправка оповещения через, минут — укажите интервал повторной отправки сообщений;

   • Получатели — укажите один или несколько email-адресов получателей.

3. В зависимости от значения в поле Тип объекта заполните поле Объект:

   • Проект — выберите проект;

   • Тенант — выберите тенант;

   • Защищенная группа — выберите защищённую группу;

   • Задание — выберите задание на репликацию.

4. Если в поле Тип объекта выбрано значение Все, укажите интервал повторной отправки оповещений по всем заданиям на репликацию и выберите получателей.

5. Нажмите Сохранить.

Изменение и удаление правил оповещения

Чтобы изменить правило оповещения:

1. Найдите нужное правило в таблице.

2. В столбце Действие нажмите иконку .

   

3. В форме Обновить правило измените необходимые параметры.

4. Нажмите Сохранить.

Чтобы удалить правило, найдите нужную строку и нажмите иконку .

Настройка SMTP

Чтобы настроить SMTP:

1. Нажмите Настроить SMTP.

2. В форме Настройки SMTP заполните поля:

   • Адрес почтового сервера;

   • Порт для подключения;

   • Тип аутентификации;

   • Email отправителя.

3. При необходимости установите флажок Использовать SSL/TLS.

4. В поле Тип аутентификации выберите один из вариантов:

   • Без аутентификации — для подключения к SMTP-серверу без логина и пароля;

   • Аутентификация по логину и паролю — для подключения к SMTP-серверу с использованием учётных данных.

5. Нажмите Сохранить.

   

Чтобы проверить параметры подключения, нажмите Протестировать.

Если при проверке или сохранении настроек возникнет ошибка, в интерфейсе отобразится уведомление.

Чтобы удалить все параметры подключения к SMTP-серверу с контроллера, нажмите Очистить. Чтобы закрыть форму Настройки SMTP без сохранения изменений, нажмите Отменить.

После настройки SMTP и сохранения правила оповещения на указанные email-адреса будут приходить уведомления о ходе выполнения репликации.

В письмах содержится следующая информация:

• имя контроллера;

• имя и ID тенанта;

• имя и ID проекта;

• имя и ID задания;

• имена и ID источника и приёмника.

Syslog

На вкладке Syslog Администратором осуществляется отправка событий безопасности (audit logs) и информации о включённом/выключенном шифровании в заданиив систему SIEM. Для этого используется протокол syslog. Логи отправляются в формате CEF (Common Event Format). Для включения требуется выполнить следующие действия:

1. Нажать кнопку + Добавить и в открывшейся форме заполнить следующие поля:

   • В поле Адрес подключения ввести адрес сервера.

   • В поле Тэг ввести тег сообщений, которые отправляются в syslog.

   • В поле Протокол выбрать:

     • TCP;

     • UDP.

   • В поле Тип выбрать соответствующий пункт. MIND Suite поддерживает отправку логов через протокол syslog в двух режимах:

     • audit – для передачи событий безопасности (audit logs) и информации о шифровании заданий в SIEM-системы (в формате CEF);

     • general – для экспорта общих журналов событий во внешние системы сбора логов.

   Оба типа (audit и general) могут работать параллельно. Для этого необходимо создать две отдельные конфигурации syslog. В первой указать тип audit, во второй – general. Настроить разные Тэги или Адреса подключения при необходимости. Совместная настройка позволяет отправлять аудит-логи в SIEM, а общие логи – в системы мониторинга, а также распределять нагрузку между серверами.

   

Бекапы

На странице Администрирование выберите Интеграции | Бекапы.

Сервис mind-backup используется для восстановления следующих компонентов MIND Suite:

• сертификаты;

• основной конфигурационный файл config.yml;

• драйверы;

• InfluxDB;

• NGINX;

• Postgres.

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

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

Таблица резервных копий содержит следующие столбцы:

• Дата создания;

• Тип;

• Версия контроллера;

• Действия — иконки для восстановления и удаления резервной копии.

Чтобы восстановить контроллер из резервной копии:

1. На вкладке Восстановление найдите в таблице нужную резервную копию.

2. В столбце Действия нажмите иконку .

3. Подтвердите действие в диалоговом окне.

Чтобы удалить резервную копию:

1. На вкладке Восстановление найдите в таблице резервную копию, которую нужно удалить.

2. В столбце Действия нажмите иконку .

3. Подтвердите действие в диалоговом окне.

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

Важно

При настройке автоматического резервного копирования время запуска указывается в формате UTC.

Например, если для ежедневного резервного копирования указано время 00:00, а на сервере установлен часовой пояс GMT+3, резервная копия будет создана в 03:00.

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

1. На вкладке Резервное копирование включите переключатель Автоматическое резервное копирование.

2. В поле Где хранить резервные копии укажите каталог для хранения.

3. В поле Автоматически копировать каждый выберите значение Час, День или Неделя.

4. Если выбрано значение День, заполните поле Время.

5. Если выбрано значение Неделя, заполните поля Время и День.

6. В поле Количество хранимых копий укажите количество резервных копий для хранения.

7. Чтобы создать резервную копию вручную, нажмите Создать копию вручную.

8. Нажмите Сохранить.

Примечание

Во время выполнения резервного копирования или восстановления контроллер становится временно недоступным. На время этих операций веб-интерфейс может возвращать ошибки. По завершении процессов копирования или восстановления контроллер снова будет доступен.

Сервис хранит конфигурацию в базе данных. Если API недоступен, обновите конфигурацию из командной строки.

Документ «Руководство по работе с API» содержит подробную информацию об API-вызовах для работы с конфигурацией.

Работа с mind-backup в командной строке

Утилита mind_backup предоставляет интерфейс для управления резервным копированием и восстановлением оркестратора, находится по пути /opt/mind/bin/mind_backup.

Важно

Запускайте команды утилиты от имени пользователя mindctrl.

Примечание

Остановите сервис mind_backup с помощью команды systemctl stop mind_backup. Если сервис активен, команды mind_backup serve, mind_backup create и mind_backup restore завершаются ошибкой с идентификатором активного процесса (PID).

Пример команды:

mind_backup [flags]

Параметры: -v, --version – показать информацию о версии программы.

version

Выводит текущую версию программы.

mind_backup version

Пример вывода:

VERSION: development, BUILDTIME: 1757435065, BRANCH: base-impl, COMMIT: a18af30, HOTFIX:

serve

Запускает сервер резервного копирования как фоновый процесс.

mind_backup serve [flags]

Параметры: -s, --servercfg string – путь к файлу конфигурации сервера.

Пример:

mind_backup serve --servercfg /tmp/backup_server.yaml

Пример файла конфигурации:

{
   "addr": "0.0.0.0:8085",
   "pgConf": {
      "rtDBUser": "cG9zdGdyZXM=",
      "rtDBPassword":
      "M3xqNURPQjEwdkdvMSRhbzZEfUE=",
      "rtDBAddress": "127.0.0.1",
      "rtDBPort": 5432,
      "rtDBName": "mind",
      "rtDBSSLMode": "disable"
   }
}

Особенности:

• проверяет, работает ли сервер резервного копирования;

• если сервер резервного копирования уже работает, команда завершается с ошибкой;

• загружает конфигурацию и запускает сервер.

list

Выводит список всех доступных резервных копий.

mind_backup list [flags]

Параметры: -b, --cfg string – путь к файлу конфигурации резервных копий.

Пример:

mind_backup list --cfg /etc/mind/backup_config.yaml

Пример файла конфигурации:

{
    "backupSettings": {
      "path": "/tmp",
      "interval": {
         "step": "HOUR"
      },
      "numberOfCopies": 3
   },
   "pgConf": {
      "rtDBUser": "cG9zdGdyZXM=",
      "rtDBPassword":
      "M3xqNURPQjEwdkdvMSRhbzZEfUE=",
      "rtDBAddress": "127.0.0.1",
      "rtDBPort": 5432,
      "rtDBName": "mind",
      "rtDBSSLMode": "disable"
   }
}

Пример вывода:

auto_backup_development_1757434140.tgz
auto_backup_development_1757435160.tgz
auto_backup_development_1757435400.tgz

create

Создаёт резервную копию.

mind_backup create [flags]

Параметры: -b, --cfg string – путь к файлу конфигурации резервных копий.

Пример:

/opt/mind/bin/mind_backup create

restore

Восстанавливает систему из указанной резервной копии.

mind_backup restore [filename] [flags]

Аргументы: filename – имя файла резервной копии (обязательный). Не указывайте путь к файлу: утилита определяет каталог резервных копий по конфигурации. Чтобы получить имя файла резервной копии, выполните команду mind_backup list.

Параметры: -b, --cfg string – путь к файлу конфигурации резервных копий.

Пример:

/opt/mind/bin/mind_backup restore auto_backup_development_1757435400.tgz

Выполняйте восстановление на совместимой версии системы. Во время резервного копирования и восстановления контроллер временно недоступен. Продолжительность периода недоступности зависит от скорости остановки и запуска сервисов: mind_system, mind_api, mind_healthmanager, mind_jobworker, mind_scheduler, mind_siteworker, mind_taskworker, mind_vaults.

Процесс валидации происходит следующим образом:

• Все команды, кроме serve и version, проверяют, работает ли сервер резервного копирования.

• Если сервер резервного копирования работает, команды завершаются с ошибкой.

• Команды проверяют настройки из конфигурационного файла.

Система уведомлений

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

1. Репликация была запущена.

2. Репликация завершена успешно.

3. Репликация завершена неуспешно.

Информация об используемом ПО

В соответствии с лицензионным соглашением № П041/06/2024 между ООО «Майнд Софт» и ООО «Постгрес Профессиональный» продукт «СУБД Postgres Pro Standard» может быть использован в качестве встраиваемого компонента в составе MIND Suite и только для целей функционирования ПО MIND Suite. Лицензия предоставляется на весь срок поддержки MIND Suite.

Информация о программном обеспечении с открытым исходным кодом, используемом в MIND Suite.

• Nginx;

• RabbitMQ;

• Victoria Logs;

• InfluxDB.

Приложение

Протоколы и порты

Примечание

Доступность портов TCP 9000 и TCP 9001 между источником и приёмником проверяется автоматически при выполнении действия Протестировать задание (см. раздел Тестовый запуск задания на репликацию в документе «Руководство пользователя MIND Guard #guest»).

Источник трафика	Назначение трафика	Порт назначения	Протокол	Комментарий
MIND Guard #guest
Машина	Контроллер	TCP 80	HTTP	Подключение агента к контроллеру
		TCP 443	HTTPS
Рабочая станция администрации	Контроллер	TCP 80	HTTP	Подключение к веб-консоли администрирования и RESTful API
		TCP 443	HTTPS
Контроллер	Машина	TCP 22	SSH	Автоматическая установка агента на машинах с ОС Linux
Контроллер	Машина	TCP 445	SMB	Автоматическая установка агента на машинах с ОС Windows
Машина (источник)	Машина (приёмник)	TCP 9000	MIND Data Plane	Передача трафика репликации от источника к приёмнику
Машина (источник)	Машина (приёмник)	TCP 9001	MIND Control Plane	Подтверждение передачи трафика репликации между источником и приёмником
Машина (приёмник)	Машина (источник)	TCP 9001	MIND Control Plane	Подтверждение передачи трафика репликации между приёмником и источником
Прокси-серверы
Машина (источник)	Прокси-сервер	TCP 9000–9999	MIND Data Plane	Передача трафика репликации через прокси между машинами, включая разворот направления
Прокси-сервер	Машина (приёмник)	TCP 9000	MIND Data Plane	Передача трафика репликации от прокси к приёмнику
Прокси-сервер	Прокси-сервер	TCP 9000–9999	MIND Data Plane	Передача трафика репликации между прокси при использовании прокси с обеих сторон, включая разворот направления
Машина (источник)	Прокси-сервер	TCP 17000–17999	MIND Control Plane	Контрольный трафик репликации через прокси в направлении источник → приёмник
Прокси-сервер	Машина (приёмник)	TCP 9001	MIND Control Plane	Контрольный трафик репликации от прокси к приёмнику (перенаправление с TCP 17000–17999)
Машина (приёмник)	Прокси-сервер	TCP 18000–18999	MIND Control Plane	Контрольный трафик репликации через прокси в направлении приёмник → источник (перенаправление на TCP 9001)
Прокси-сервер	Машина (источник)	TCP 9001	MIND Control Plane	Контрольный трафик репликации от прокси к источнику (перенаправление с TCP 18000–18999)
Контроллер	Прокси-сервер	TCP 19000–19999	SSH	Управляющий доступ контроллера к машинам через прокси (перенаправление на TCP 22)
Прокси-сервер	Машина (источник)	TCP 22	SSH	Управляющий доступ прокси к источнику
Прокси-сервер	Машина (приёмник)	TCP 22	SSH	Управляющий доступ прокси к приёмнику
Машина	Прокси-сервер	TCP 20000–20999	HTTP	Подключение агента к контроллеру через прокси (перенаправление на TCP 443)
			HTTPS
Прокси-сервер	Контроллер	TCP 80	HTTP	Получение конфигурации прокси с контроллера
		TCP 443	HTTPS
Вспомогательные сервисы
Контроллер	Контроллер домена	TCP 389	LDAP	Аутентификация через домен на контроллере
		TCP 636	LDAPS
Контроллер	Контроллер домена	TCP 88	Kerberos	Аутентификация на машинах с ОС Windows с использованием Kerberos
		UDP 88
Контроллер	Сервер Secman	TCP 443	HTTPS	Взаимодействие с внешним хранилищем секретов
Контроллер	Почтовый сервер	TCP 25	SMTP	Отправка почтовых уведомлений
Контроллер	Сервер логирования	TCP 514	SYSLOG	Отправка журналов на внешний сервер по Syslog
		UDP 514