Безопасность и соответствие требованиям

Mockarty помогает создавать моки API и проводить функциональные, нагрузочные, проверки безопасности, хаос- и контрактные тесты. Его можно развернуть в своей инфраструктуре. Эта страница помогает администратору оценить данные в Mockarty, доступные настройки защиты и ответственность своей организации.

В Mockarty могут находиться учётные записи, тестовые данные, записанный трафик и учётные данные подключённых систем. Тесты могут обращаться к системам с реальными данными. Определите класс данных в своём пространстве и вместе со службой безопасности и юристами установите, какие требования применимы к вашему развёртыванию.

Таблица соответствия ниже может помочь заполнить анкету поставщика, но сама по себе не подтверждает сертификацию или соответствие требованиям.

Модель развёртывания и границы данных

Встроенные механизмы безопасности

Идентификация и доступ

• Аутентификация: локальные пользователи, OAuth2/OIDC, LDAP/AD, SAML 2.0.
• MFA: TOTP (RFC 6238) с recovery-кодами.
• RBAC: системные роли и роли пространства определяют, кто может просматривать или менять ресурсы. Перед выдачей доступа проверяйте роль пользователя и API-токена.
• API-токены: scope’ятся по namespace + роль + опциональный срок; отзываются; показываются один раз при создании.
• Сессии: Redis-backed (если настроен), идемпотентный logout, различимые ошибки «сессия истекла» vs «сессия недействительна».

Изоляция по namespace (мультитенантность)

• Каждый мок, тестовый прогон, webhook, запись аудита привязаны к namespace.
• Handler-слой применяет шаблон load → check namespace → 404 on mismatch — зондирование ID из чужого namespace неотличимо от «не найдено».
• Роль Support может читать между namespace, но не может жёстко удалять или опустошать корзину.

Защита данных

• В канале: TLS 1.2+ для всех HTTP-endpoint’ов, опционально mTLS для gRPC.
• В покое — БД: шифрование делегировано СУБД (PostgreSQL / SQLite — выбор оператора).
• В покое — персональные данные (email пользователя, user agent и поисковый индекс логина): опционально field-level AES-256-GCM (envelope encryption). Выключено по умолчанию; включается через MOCKARTY_PII_ENCRYPTION_KEY + MOCKARTY_PII_HMAC_PEPPER.
• Хранение ключей: по умолчанию ключи читаются из переменных окружения; опционально доступен PKCS#11 HSM-бэкенд (в отдельном варианте сборки) для ФСТЭК/FIPS-развёртываний. Выбор зависит от профиля рисков.
• Секреты в логах: редактируются logging-слоем; поля password и token никогда не попадают в структурированные логи.

Журнал аудита

• Каждое действие записи (create / update / delete / login / смена роли / смена политики / выпуск токена / каскадное удаление) порождает запись аудита с актёром, namespace, ресурсом, IP, user-agent, путём запроса.
• Неизменяемость обеспечивается триггерами БД: после записи строки аудита нельзя изменить или удалить; флаг legal hold блокирует ретеншн-очистку.
• Плавное завершение сбрасывает незавершённые записи аудита перед закрытием соединения с БД — потери аудита на SIGTERM не бывает.
• Экспорт: CSV, JSON, Syslog (RFC 5424), CEF 0 (ArcSight). Заливайте напрямую в Splunk / QRadar / КУМА / MaxPatrol.

Оповещения по журналу аудита

Экспорт в SIEM отвечает на вопрос «что произошло» постфактум. Правила оповещений
отвечают на него по ходу: правило следит за потоком аудита и уведомляет по
HTTP-вебхуку или письмом в момент, когда записана подходящая запись.

Правило сужает поток любым нужным способом:

Правило обязано сузить поток хотя бы одним действием или одним флагом триггера.
Правило без того и другого срабатывало бы на КАЖДОЕ аудируемое действие в
продукте, поэтому оно отклоняется при сохранении, а не после того, как зальёт
дежурный канал.

Управление — /api/v1/admin/alert-rules (только администратор: правила читают
журнал аудита, охватывающий все неймспейсы):

curl -X POST http://localhost:5770/api/v1/admin/alert-rules \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{
    "name": "удаления неймспейсов",
    "action_filter": ["namespace.delete"],
    "notification_type": "webhook",
    "notification_config": {"url": "https://hooks.example.com/oncall"},
    "enabled": true
  }'

GET /api/v1/admin/alert-logs показывает, что реально сработало, начиная с
свежего. В каждой строке есть notification_sent, а при неудаче доставки —
notification_error: правило, которое совпало, но не достучалось до своего
эндпоинта, видно, а не теряется молча. Строка связана с записью аудита и
называет затронутую сущность, но не содержит учётных данных канала доставки
или произвольных деталей из аудита. Ошибка вебхука показывает безопасный адрес
назначения и тип сбоя, а не URL с учётными данными.
Ответы MCP при просмотре и создании правил не содержат настройки доставки и
метаданные правила; управляйте ими через API администратора.

Маршрутизация алерта через ваши каналы уведомлений

notification_type: "channel" отправляет алерт через каналы уведомлений, которые
вы уже настроили (Slack, Teams, Telegram, Discord, Rocket.Chat, Pachca, VK Teams,
Opsgenie, PagerDuty, Webex, email, webhook), вместо того чтобы вшивать одно
назначение внутрь правила. Алерт доходит и до каналов, ПРИВЯЗАННЫХ в этом
пространстве имён, и до каналов, ПОДПИСАННЫХ на тип события алерта (по умолчанию
alert.triggered) — это подписки на события из
Каналов уведомлений с их тихими часами,
дайджестами, дедупликацией, лимитами, размыкателем и журналом доставок. То есть
оператору, который хочет, чтобы алерты уважали тихие часы, нужно подписать канал
на alert.triggered, а не привязывать его. Доставка записывается дважды, и это
намеренно: результат и причина — в строке алерта (notification_sent, видно в
журнале алертов), а факт доставки — в собственном журнале подписанного канала.
Правило, которое сработало и никого не достигло, видно в обоих:

curl -X POST http://localhost:5770/api/v1/admin/alert-rules \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{
    "name": "удаления пространств имён",
    "action_filter": ["namespace.delete"],
    "notification_type": "channel",
    "notification_config": {"eventType": "alert.triggered", "actionLabel": "Открыть запись аудита"},
    "enabled": true
  }'

Держите eventType неизменным между правками правила: именно эту строку оператор
привязывает к каналу, и её переименование молча прекращает доставку.
actionLabel необязателен и используется только когда у сущности алерта есть
страница, которую можно открыть: алерт о миссии открывает её карточку, а типы
сущностей без страницы получают поля корреляции и никакой кнопки (кнопка, ведущая
в никуда, хуже её отсутствия). Алерт, который не удалось доставить — нет
привязанного канала, нет пространства имён, отказ транспорта, — записывает причину
в notification_error, а не сообщает об успехе.

Защита от угроз

• Валидация входа на каждой handler-границе; параметризованный SQL (никакой конкатенации).
• CEF/Syslog экспорт экранирует инъекционные векторы (|, =, backslash, пробел, перевод строки) — значит атакующий, контролирующий User-Agent или email, не может подмешать фейковые extension-пары в дашборды SIEM.
• Soft-delete с ограниченным ретеншном и корзиной: обратимо, аудируемо, с rate-limit.
• Advisory locks на каскадных операциях предотвращают гонки с частичным удалением.
• Пулы воркеров масштабируются от числа доступных CPU-ядер; back-pressure автоматически останавливает прогон при устойчиво высокой доле ошибок, чтобы не допустить runaway-потребления ресурсов.

Доступность и устойчивость

• Кластерный режим: leader election для планировщика, NOTIFY-инвалидация кешей, кросс-нодовый SSE fan-out.
• K8s-ready: liveness/readiness probes отражают реальное состояние зависимостей (БД, Redis, лицензионный сервер), бинари, учитывающие CPU-квоту, bounded graceful shutdown.
• Air-gapped: все фронтовые ассеты встроены (никаких CDN), офлайн-активация лицензии.

Сопоставление с фреймворками

Матрица ниже — карта заявлений: она показывает, какие встроенные контроли Mockarty релевантны для технических требований каждого фреймворка. Это не сертификация, не аудиторское заключение и не аттестация. Клиенты, проходящие формальные аудиты, наследуют эти контроли, но остаются ответственными за свои организационные процессы.

Разделение ответственности

Локализация данных

При самостоятельном размещении вы выбираете, где работают сервисы Mockarty и хранится информация. Планируя исходящие соединения, проверьте все включённые интеграции и тестовые цели: SMTP, вебхуки, платёжные и LLM-сервисы, а также сами тесты могут передавать данные настроенным внешним системам. Для изолированных установок доступна офлайн-активация лицензии.

Реакция на инциденты

• Каждый исключительный исход (неуспешный логин, провал MFA, RBAC-отказ, неправильное использование токена, каскадное удаление) — отдельный аудит-глагол, и SIEM умеет алертить по конкретной причине.
• Для расследования используйте фильтры журнала аудита по действию и времени и сверяйте записи с журналами тестируемой системы и инфраструктуры.
• Legal hold: любой аудитор может заморозить сегмент журнала и блокировать ретеншн-очистку; попытки модификации ловятся триггерами на уровне БД.

Запрос артефактов

По запросу (обычно в рамках анкеты поставщика) мы можем предоставить:

• SBOM (CycloneDX) для бинарей релиза
• Отчёт о сканировании CVE (Trivy) по последнему релизу
• Эту страницу в виде подписанного PDF
• Шаблон DPA (Data Processing Agreement) — EN / RU
• Шаблон BAA для HIPAA-интеграций
• Архитектурную диаграмму для security-ревью

Запросите у своего account-менеджера или у команды безопасности Mockarty актуальные версии.