План комплексного реагирования на сбои платформы

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

1. Общая информация

Платформа двухфакторной аутентификации Protectimus используется в локальной (on-premise) конфигурации. Она включает в себя следующие основные компоненты:

• База данных (БД);
• Сервер приложений и API.

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

2. Возможные сценарии отказов

Основные потенциальные причины сбоев в работе локальной платформы Protectimus включают:

• Сбой базы данных;
• Сбой или неисправность сервера приложений;
• Сбой сети – отсутствие доступа к API;
• Аппаратный сбой.

Примечание: Внешние атаки, такие как DDoS, не рассматриваются, так как платформа не имеет внешнего доступа.

3. Рекомендации по мониторингу для немедленного обнаружения проблем

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

1. Отзывчивость API:
   • Запрос:

     [platform path]/api/v1/auth-service/balance

   • Если подключение выполнено успешно без авторизации, должен быть возвращен ответ 401.
2. Доступность корневого URL (этот метод не гарантирует, что база данных работает):
   • https://localhost:8443/ должен отвечать кодом статуса 200 и отображать HTML-страницу платформы.

4. План действий при сбое

4.1. Действия администратора при обнаружении некорректного ответа:

1. Решить проблемы с сетью (если применимо).
2. Решить проблемы с оборудованием (если применимо).
3. Если предыдущие шаги не помогли – восстановить систему с резервной копии виртуальной машины, резервной копии базы данных или полной резервной копии системы.

4.2. Рекомендации по созданию резервных копий

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

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

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

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

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

5. Восстановление после сбоя

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

1. Выполните восстановление в соответствии с выбранной процедурой.
2. Убедитесь, что все сервисы запущены и работают корректно.
3. Проверьте работу аутентификации на клиентских устройствах.
4. Сообщите ответственному персоналу о завершении восстановления.

6. Предотвращение будущих сбоев

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

Эта информация предназначена для минимизации рисков и быстрого реагирования при возникновении проблем с локальной MFA платформой Protectimus. Если у вас есть вопросы, обратитесь в службу поддержки клиентов Protectimus.