I'm available for business trips to other cities for projects lasting a month or longer.
Реагирование на инциденты
Обнаружение, локализация, ликвидация последствий, типовые инциденты и процедуры
ООО «Рапид.Исследовательские системы»
Версия: 1.1.2
Дата: март 2026
1. Назначение
Документ описывает процедуры реагирования на инциденты информационной безопасности при эксплуатации платформы Rapeed BI. Структура документа основана на трёхстадийной модели управления инцидентами.
Для администраторов и специалистов по безопасности.
2. Процесс реагирования
3. Стадия 1: Обнаружение и регистрация
3.1. Автоматизированное обнаружение
Автоматически обнаруживаются:
| Признак | Источник | Механизм |
|---|---|---|
| Множественные неудачные попытки входа | Keycloak | Brute force protection: блокировка после 5 попыток, событие SEC-001 с result=FAILURE |
| Недоступность компонента | Docker healthcheck | Автоматический перезапуск контейнера, запись в журнал |
| Аномальная активность API | Reverse Proxy access log | HTTP-статусы 401/403 в журнале, доступны через Grafana |
| Попытка доступа без аутентификации | OAuth2 Proxy, API | Отклонение запроса, запись в журнал |
| Экспорт данных | REST API | Событие SEC-025 при каждом экспорте |
3.2. Ручное обнаружение
Администратор или аудитор может обнаружить признаки инцидента при:
- Просмотре журналов событий безопасности через Grafana
- Анализе данных из SIEM
- Обращении пользователя о подозрительной активности
- Плановой проверке конфигурации
3.3. Регистрация
При обнаружении признаков инцидента необходимо зафиксировать:
| Поле | Описание |
|---|---|
| Дата и время обнаружения | Момент обнаружения признака |
| Источник информации | Журнал, SIEM, обращение пользователя |
| Описание признака | Что наблюдается |
| Затронутые компоненты | Какие сервисы или пользователи затронуты |
| Предварительная оценка | Критичность (высокая / средняя / низкая) |
4. Стадия 2: Реагирование
4.1. Определение затронутых компонентов
Определить, какие компоненты платформы вовлечены в инцидент:
- Проверить журналы затронутых контейнеров через Grafana
- Проверить статус healthcheck всех сервисов:
docker ps - Проверить сетевую активность: журналы reverse proxy
- Проверить активные сессии в Keycloak Admin Console
4.2. Локализация
Ограничить распространение инцидента. В зависимости от типа:
| Действие | Команда / процедура |
|---|---|
| Блокировка учётной записи | Keycloak Admin Console → Users → Disable |
| Завершение всех сессий пользователя | Keycloak Admin Console → Users → Sessions → Logout all |
| Остановка отдельного сервиса | docker compose stop <service> |
| Ограничение сетевого доступа | Правила межсетевого экрана на хосте |
| Остановка платформы | docker compose down (крайняя мера) |
4.3. Выявление последствий
- Определить, были ли данные просмотрены или экспортированы (SEC-025)
- Определить, были ли изменены настройки или права доступа (SEC-006, SEC-008)
- Определить, были ли созданы или удалены учётные записи (SEC-005, SEC-007)
- Сохранить журналы за период инцидента
4.4. Ликвидация последствий
| Последствие | Действие |
|---|---|
| Компрометация учётной записи | Сброс пароля, отзыв сессий, проверка действий пользователя в журналах |
| Несанкционированное изменение конфигурации | Восстановление из резервной копии, проверка diff |
| Несанкционированный экспорт данных | Фиксация факта, уведомление ответственного за данные |
| Недоступность сервиса | Перезапуск контейнера, проверка журналов, при необходимости, восстановить из резервной копии |
4.5. Закрытие инцидента
- Подтвердить восстановление штатной работы
- Проверить healthcheck всех компонентов
- Убедиться, что причина инцидента устранена
- Зафиксировать дату и время закрытия
5. Стадия 3: Анализ результатов
- Определить корневую причину инцидента
- Оценить эффективность реагирования (время обнаружения, локализации, ликвидации)
- Разработать рекомендации по предотвращению повторения
- При необходимости обновить конфигурацию, парольные политики или правила доступа
- При обнаружении уязвимости в ПО передать информацию вендору
6. Типовые инциденты и процедуры
6.1. Подбор пароля (brute force)
Признаки
- Множественные события SEC-001 с result=FAILURE для одной учётной записи
- Автоматическая блокировка учётной записи в Keycloak (после 5 попыток)
- События с разных IP-адресов для одного пользователя
Действия
- Проверить журнал: IP-адреса источников, частоту попыток
- Убедиться, что учётная запись заблокирована (Keycloak Admin Console)
- При атаке с одного IP: заблокировать на уровне межсетевого экрана
- Уведомить владельца учётной записи
- После разблокировки: обязать смену пароля
6.2. Несанкционированный доступ
Признаки
- Вход в систему в нехарактерное время (SEC-001, SUCCESS)
- Доступ к данным, не относящимся к обязанностям пользователя
- Действия администратора (SEC-024) от пользователя без соответствующей роли
Действия
- Немедленно заблокировать учётную запись в Keycloak
- Завершить все активные сессии пользователя
- Собрать журналы действий: все SEC-* события для данного пользователя за период
- Определить, какие данные были просмотрены или экспортированы
- Проверить, не были ли изменены права доступа (SEC-008)
- Сбросить пароль, проверить наличие несанкционированных OTP-устройств
6.3. Компрометация сервиса
Признаки
- Аномальное потребление ресурсов контейнером (CPU, память, сеть)
- Неожиданные исходящие сетевые подключения
- Изменение файлов внутри контейнера (при наличии мониторинга)
- Ошибки healthcheck, не связанные с известными причинами
Действия
- Остановить затронутый контейнер:
docker compose stop <service> - Сохранить состояние для анализа:
docker commit <container> evidence:incident-YYYYMMDD - Проверить digest образа: соответствие эталону из реестра
- Проверить, не были ли изменены volumes
- Пересоздать контейнер из оригинального образа
- Проверить смежные сервисы на аналогичные признаки
- Проверить и при необходимости ротировать секреты (.env.enc)
6.4. Несанкционированный экспорт данных
Признаки
- Множественные события SEC-025 (DATA_EXPORT) от одного пользователя
- Экспорт данных, не относящихся к обязанностям пользователя
- Экспорт в нехарактерное время
Действия
- Зафиксировать список экспортированных данных из журнала (object, timestamp)
- Связаться с пользователем для выяснения обстоятельств
- При подтверждении: заблокировать учётную запись
- Уведомить ответственного за данные
- При необходимости ограничить права экспорта для роли
6.5. Отказ компонента платформы
Признаки
- Healthcheck контейнера в статусе unhealthy
- Ошибки при обращении к интерфейсу или API
- Ошибки в журналах (ib_severity=HIGH)
Действия
- Docker автоматически перезапускает контейнер (restart: always)
- Проверить журналы:
docker logs <container> --tail 100 - Проверить ресурсы хоста: дисковое пространство, память, CPU
- Если проблема не устранена автоматически, перезапустить сервис вручную
- При повторении восстановить из резервной копии
7. Роли и ответственность
| Роль | Ответственность |
|---|---|
| Администратор платформы | Обнаружение инцидентов, первичная локализация, восстановление штатной работы, сохранение журналов |
| Специалист по ИБ | Анализ инцидента, определение последствий, разработка рекомендаций, взаимодействие с SIEM |
| Ответственный за данные | Оценка влияния на данные, принятие решений об уведомлении затронутых лиц |
| Вендор (ООО «Рапид.Исследовательские системы») | Техническая поддержка, анализ уязвимостей в ПО, выпуск обновлений |
8. Контактная информация
| Вопрос | Контакт |
|---|---|
| Техническая поддержка | support@rapeed.ai |
| Инциденты безопасности | security@rapeed.ai |