Угрозы безопасности и зоны ответственности
Это руководство помогает администратору проверить собственную установку Mockarty до подключения к реальным системам и выдачи доступа команде. Категории STRIDE показывают возможные угрозы, полезные средства Mockarty и действия, которые остаются за вашей организацией. Документ помогает планировать защиту, но не заменяет проверку вашей установки и не является сертификатом соответствия.
Порядок настройки описан в разделах Администрирование и Безопасность и соответствие.
1. Как устроен доступ
Пользователи и автоматизация обращаются к административному сервису Mockarty через веб-интерфейс, API, CLI или SDK. Установка может также включать компоненты обработки запросов и запуска тестов. Через них проходят моки, тестовые запросы, результаты, учётные данные и записи аудита. До открытия доступа определите, какие люди и сети могут обращаться к каждому компоненту.
2. Что нужно защищать
| Данные | Почему это важно |
|---|---|
| Моки, входные данные тестов и результаты | В них могут оказаться детали API и данные тестируемой системы. |
| Учётные записи, сессии и API-токены | Они дают доступ к пространствам и автоматизации. |
| Секреты интеграций | Их утечка может открыть доступ к внешним системам. |
| Записи аудита и резервные копии | Они нужны для расследования и восстановления. |
| Файлы релиза и образы контейнеров | Подменённый пакет может скомпрометировать установку. |
По возможности используйте искусственные тестовые данные. Если нужны чувствительные данные, ограничьте круг читателей и заранее определите срок хранения результатов.
3. Границы доступа
| Граница | Что проверить |
|---|---|
| Пользователи и автоматизация → административный сервис | TLS, вход в систему, роли и область действия API-токенов. |
| Административный сервис → пространства | Членство в пространстве и доступ к общим тестовым данным. |
| Mockarty → тестируемые системы | Разрешённые адреса, сетевой выход и письменное разрешение на тестирование. |
| Mockarty → хранилище и резервные копии | Доступ к базе данных, защита копий и сроки хранения. |
| Установка → внешний провайдер входа или модели | Права провайдера, учётные данные и данные, покидающие вашу сеть. |
4. Анализ STRIDE
S — Подмена личности
Риск: кто-то входит под чужим именем или использует утёкший API-токен. Средства Mockarty: роли, токены с ограниченными правами и возможностью отзыва, а также MFA при соответствующей настройке. Ваши действия: требуйте MFA для привилегированных пользователей, не храните токены в репозиториях и логах, отзывайте токен при смене владельца или назначения. При внешнем входе проверьте настройки провайдера идентификации.
T — Изменение данных
Риск: пользователь без разрешения меняет моки, настройки тестов или результаты. Средства Mockarty: проверка ролей и аудит защищённых действий. Ваши действия: выдавайте минимально достаточную роль, отслеживайте изменения в общих пространствах и защищайте базу данных и резервные копии от прямого изменения.
R — Отказ от совершённого действия
Риск: после инцидента невозможно узнать, кто изменил настройку или запустил тест. Средства Mockarty: записи аудита для административных и пользовательских действий. Ваши действия: задайте срок хранения, при необходимости отправляйте записи в систему мониторинга и обеспечьте администраторам возможность расследовать необычную активность. Настройки аудита описаны в Администрировании.
I — Раскрытие информации
Риск: пользователь читает данные чужого пространства либо отчёт содержит учётные данные или персональную информацию. Средства Mockarty: проверка доступа к пространству и дополнительные средства защиты хранимой персональной информации. Ваши действия: проверяйте участников пространств и отчёты перед отправкой, включайте шифрование персональных данных, если оно требуется для вашей установки. В установке по умолчанию шифрование персональных данных выключено; настройка описана в Администрировании.
D — Отказ в обслуживании
Риск: нагрузочный тест, фаззинг или хаос-эксперимент перегружает Mockarty или целевую систему. Средства Mockarty: ограничения и отмена прогонов. Ваши действия: начинайте с малой нагрузки, проводите потенциально опасные тесты в согласованное окно, наблюдайте за Mockarty и целью, подбирайте ресурсы компонентов запуска под ожидаемую нагрузку.
E — Повышение прав
Риск: пользователь получает лишние права через API или слишком широкую роль. Mockarty проверяет доступ на уровне API и интерфейса. Четыре системные роли (Admin, Support, User, Auditor) и роли пространства определяют доступные действия. Ваши действия: регулярно пересматривайте роли, выдавайте автоматизации отдельные токены и проверяйте доступ тестовой учётной записью до приглашения команды.
5. Цепочка поставки
Получайте релизы из одобренного вашей организацией канала и проверяйте опубликованные контрольные суммы перед установкой. Обновляйте хост, базу данных, обратный прокси и среду контейнеров. Если пакеты копируются во внутреннее хранилище, защищайте его и записывайте версию каждой установки.
6. Остаточные риски
Mockarty не может защитить скомпрометированный провайдер входа, украденную учётную запись администратора или данные, которые пользователь сам скопировал в тест. Человек с прямым доступом к базе данных или хосту может обойти ограничения приложения. Сетевые политики, настройки входа, защита резервных копий и план реагирования остаются частью ответственности вашей организации.
Возвращайтесь к этой проверке при добавлении интеграций, открытии доступа из новых сетей, изменении ролей и начале тестирования систем с чувствительными данными.