План комплексного реагирования на сбои платформы
В случае сбоя
локальной платформы MFA Protectimus необходимо быстро и чётко отреагировать, чтобы свести к минимуму время простоя и сохранить безопасность системы. Этот план действий при сбое платформы описывает основные сценарии отказов, рекомендации по мониторингу, процедуры восстановления и меры по предотвращению сбоев. Соблюдая эти рекомендации, администраторы смогут оперативно выявлять, устранять и предотвращать нарушения в работе платформы.
1. Общая информация
Платформа двухфакторной аутентификации Protectimus используется в локальной (on-premise) конфигурации. Она включает в себя следующие основные компоненты:
- База данных (БД);
- Сервер приложений и API.
Эти компоненты могут работать как на одном сервере, так и быть распределены по нескольким машинам. Также возможна установка резервного сервера или кластера для обеспечения отказоустойчивости.
2. Возможные сценарии отказов
Основные потенциальные причины сбоев в работе локальной платформы Protectimus включают:
- Сбой базы данных;
- Сбой или неисправность сервера приложений;
- Сбой сети – отсутствие доступа к API;
- Аппаратный сбой.
Примечание: Внешние атаки, такие как DDoS, не рассматриваются, так как платформа не имеет внешнего доступа.
3. Рекомендации по мониторингу для немедленного обнаружения проблем
Рекомендуется настроить автоматический мониторинг (для кластера — мониторинг каждого узла) с интервалом хотя бы в одну минуту для проверки состояния системы, включая следующие параметры:
- Отзывчивость API:
- Доступность корневого URL (этот метод не гарантирует, что база данных работает):
- https://localhost:8443/ должен отвечать кодом статуса 200 и отображать HTML-страницу платформы.
4. План действий при сбое
4.1. Действия администратора при обнаружении некорректного ответа:
- Решить проблемы с сетью (если применимо).
- Решить проблемы с оборудованием (если применимо).
- Если предыдущие шаги не помогли – восстановить систему с резервной копии виртуальной машины, резервной копии базы данных или полной резервной копии системы.
4.2. Рекомендации по созданию резервных копий
Для минимизации потерь данных рекомендуется следующая схема резервного копирования:
- Ежедневные инкрементальные резервные копии базы данных;
- Еженедельные полные резервные копии базы данных;
- Ежемесячные полные резервные копии системы.
Примечание: При восстановлении из резервной копии все данные, созданные после последнего резервного копирования, будут утеряны. Это в первую очередь повлияет на новых пользователей или ресурсы, а также будет потеряна история событий за этот период.
4.3. Кластеризованная платформа
Если используется кластер, переключение на резервный сервер происходит автоматически, поэтому большинство проблем устраняется без какого-либо влияния на конечных пользователей. Мы рекомендуем выбрать этот вариант.
5. Восстановление после сбоя
Чтобы восстановить работоспособность платформы, выполните следующие действия:
- Выполните восстановление в соответствии с выбранной процедурой.
- Убедитесь, что все сервисы запущены и работают корректно.
- Проверьте работу аутентификации на клиентских устройствах.
- Сообщите ответственному персоналу о завершении восстановления.
6. Предотвращение будущих сбоев
- Регулярно проверяйте целостность резервных копий.
- Проводите тестовые обновления, чтобы проверить функциональность резервных копий.
- Проводите стресс-тесты для оценки возможности платформы выдерживать нагрузку.
- Настройте уведомления для администраторов о критических событиях.
Эта информация предназначена для минимизации рисков и быстрого реагирования при возникновении проблем с
локальной MFA платформой Protectimus.
Если у вас есть вопросы, обратитесь в
службу поддержки клиентов Protectimus.
