Комплексний план реагування на відмову платформи

У разі відмови локальної платформи Protectimus важливо забезпечити швидке та організоване реагування, щоб мінімізувати час простою та зберегти безпеку. Цей план дій у випадку відмови локальної платформи Protectimus описує основні сценарії відмов, рекомендації з моніторингу, процедури відновлення та профілактичні заходи. Дотримуючись цих рекомендацій, адміністратори зможуть ефективно виявляти, усувати та запобігати порушенням роботи платформи.

1. Загальна інформація

Платформа двофакторної автентифікації Protectimus використовується в локальній конфігурації та складається з таких основних компонентів:

• База даних (БД);
• Сервер додатків та 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.