План реагирования на инциденты

Вступает в силу: 2 июня 2026 г.

Настоящий План реагирования на инциденты («План») определяет, как STANDOUT Inc. («мы», «нас») обнаруживает, реагирует, восстанавливается и извлекает уроки из инцидентов безопасности, сбоев сервиса и утечек данных, затрагивающих сервис VATES («Сервис»). План опирается на NIST SP 800-61 Rev.2 и ISO/IEC 27035 и построен на принципе, согласно которому автоматизированные средства мониторинга служат передовой линией обнаружения.

1. Цель и область применения

Задачи настоящего Плана:

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

Настоящий План применяется к production-среде Сервиса (EC2, Cloudflare и связанные SaaS-провайдеры), к каналу связи от Сервиса к вышестоящим AI-провайдерам и ко всем хранилищам, содержащим данные Клиента.

2. Определение инцидента и классификация серьёзности

2.1 Определение инцидента

Для целей настоящего Плана инцидентом является любое событие, соответствующее одному или нескольким из следующего:

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

2.2 Классификация серьёзности

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

• P1 (Critical): полный сбой Сервиса или подтверждённая утечка данных с участием персональных данных. Требует немедленного реагирования.
• P2 (High): значительное нарушение основной функциональности, недоступность для конкретных Клиентов или аномалии аутентификации. Первичное реагирование требуется в течение одного часа.
• P3 (Medium): частичное нарушение функциональности или снижение производительности при наличии обходных путей. Реагирование в рабочее время допустимо.
• P4 (Low): события с ограниченным воздействием на пользователей, незначительное отклонение целостности журналов или снижение резервирования средств мониторинга. Обрабатывается в следующем плановом цикле проверки.

3. Структура реагирования

3.1 Ответственное лицо

Ответственным лицом по настоящему Плану является Takuya Aoki, Managing Director STANDOUT Inc. и руководитель разработки VATES. Все полномочия по принятию решений и полномочия по внешнему уведомлению во время инцидента сосредоточены в ответственном лице.

3.2 Автоматизированные средства обнаружения

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

• Cloudflare Health Check: зондирует production-источник из нескольких географических точек с интервалом 60 секунд.
• HetrixTools: мониторит production-эндпоинты из нескольких глобальных точек по пути, независимому от Cloudflare.
• Sentry: захватывает исключения приложения в реальном времени и уведомляет ответственное лицо.
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): блокирует известные шаблоны атак в режиме Block.
• Cloudflare DDoS Protection: непрерывно и автоматически смягчает DDoS-атаки на сетевом уровне, уровне SSL/TLS и уровне HTTP.
• Батч обнаружения аномалий (systemd timer): сканирует журналы аудита каждые пять минут и обнаруживает три категории: высокую частоту запросов, высокую частоту отказов авторизации и попытки перебора.
• Ограничение частоты: потенантное ограничение частоты запросов на эндпоинтах использования и ограничение частоты на основе IP на эндпоинтах аутентификации, автоматически отклоняющее избыточный трафик.
• Настраиваемые оповещения безопасности: Клиенты могут выбирать, какие операционные события (низкий баланс, вход из нового местоположения, заблокированный доступ, повторные неудачные входы) запускают email-уведомления, с порогами чувствительности для каждого события.
• Инфраструктура журнала аудита: записывает каждый вызов API в устойчивый к подделке журнал аудита с хеш-цепочкой (SHA-256, потенантный порядковый номер) и консолидирует записи для независимой проверки.
• Панель состояния (9 индикаторов работоспособности): визуализирует аудит, аномалии, GeoIP, резервные копии, батч удаления, покрытие каталога, расхождение сверки, killswitch и состояние сервиса на одном экране.
• Автоматическое резервное копирование: шифрует снимки SQLite с помощью GPG AES-256 и хранит 30 ежедневных поколений.

3.3 Делегирование передовой линии реагирования автоматизации

Этапы обнаружения и первичной оценки выполняются вышеуказанными автоматизированными средствами как передовой линией. Ответственное лицо вмешивается только по получении уведомлений о превышении порога. Такая конструкция обеспечивает, что охват обнаружения 24/7 физически установлен без зависимости от местоположения или доступности ответственного лица.

4. Процесс реагирования

4.1 Обнаружение

Когда одно или несколько автоматизированных средств, описанных в Разделе 3.2, обнаруживают аномалию, ответственное лицо немедленно уведомляется через Sentry, email и оповещения дашборда. Сообщения Клиентов принимаются на [email protected] и оформляются в тикеты в том же потоке.

4.2 Первичная оценка

По получении уведомления ответственное лицо подтверждает серьёзность, анализируя:

• Область воздействия (все Клиенты / конкретный Клиент / отдельный экземпляр).
• Затронуты ли персональные данные, учётные данные аутентификации или платёжная информация.
• Участие внешних факторов (сбои вышестоящих AI-провайдеров, сбои Cloudflare, сбои AWS).
• Корреляцию с известными шаблонами атак (журналы WAF, результаты обнаружения аномалий, оповещения GeoIP).

4.3 Сдерживание

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

• Приостановка (suspended) затронутых экземпляров через конечный автомат для немедленной изоляции.
• Добавление IP-адресов источника в deny list (по клиенту или глобально).
• Массовый отзыв сессий по JWT jti.
• Активация killswitch (полная остановка трафика, крайняя мера).
• Активация Cloudflare "Under Attack Mode" против атак L7.

4.4 Восстановление

После сдерживания устраняются коренные причины и выполняется следующее:

• Восстановление из резервной копии по необходимости (процедуры задокументированы в docs/RESTORE.md).
• Ротация затронутых учётных данных (API-ключи, секреты JWT, ключи шифрования резервных копий и т. д.).
• Применение патчей, исправлений конфигурации и правок кода в production.
• Проверка в средах staging и production.
• Продолжение наблюдения не менее 24 часов через средства мониторинга.

4.5 После инцидента

После подтверждения восстановления ответственное лицо:

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

5. Уведомление Клиентов и регулирующих органов

5.1 Уведомление об утечке персональных данных

Если подтверждено несанкционированное получение, потеря или раскрытие персональных данных, мы предоставляем уведомление в соответствии с:

• EU General Data Protection Regulation (GDPR) Article 33: уведомление надзорному органу в течение 72 часов с момента, когда стало известно.
• GDPR Article 34: при выявлении высокого риска — уведомление затронутых субъектов данных без неоправданной задержки.
• Закон о защите персональной информации (Япония): уведомление Комиссии по защите персональной информации и уведомление субъектов данных в соответствии с применимыми правительственными постановлениями и правилами.
• Прочие применимые юрисдикции: уведомления, требуемые применимыми национальными или региональными законами о защите данных.

5.2 Уведомление о сбое сервиса

Для сбоев сервиса, классифицированных как P1 или P2, мы уведомляем затронутых Клиентов без неоправданной задержки, включая ожидаемый срок восстановления и любые временные меры смягчения. Каналами уведомления являются [email protected] и консоль администрирования Сервиса.

5.3 Метод уведомления

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

6. Post-Mortem и цикл извлечения уроков

После инцидента P1 или P2 ответственное лицо проводит Post-Mortem и документирует следующие пункты. Документ хранится внутри и раскрывается Клиентам и аудиторам по запросу.

• Хронология событий от обнаружения до восстановления.
• Анализ коренных причин (технические и операционные факторы).
• Количественно оценённая область воздействия.
• Оценка процесса реагирования.
• Превентивные меры и целевые сроки.

Post-Mortem проводятся как Blameless Post-Mortems, сосредоточенные на структурном улучшении, а не на индивидуальной ответственности.

7. Сопровождение и пересмотр Плана

7.1 Периодический пересмотр

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

7.2 История изменений

История изменений настоящего Плана ведётся внутри и раскрывается Клиентам и аудиторам по запросу.

8. Контакты

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

STANDOUT Inc.
Email: [email protected]

Последнее обновление: 2 июня 2026 г.