Эксплуатационная модель¶
Раздел содержит общие сведения об эксплуатационных условиях NC AI Platform.
Материалы раздела описывают публичные свойства продукта, связанные с размещением данных, возможным появлением чувствительной информации, доступностью и восстановлением при эксплуатации.
Потенциальное хранение персональных данных¶
Документ описывает места NC AI Platform, где при эксплуатации могут появиться персональные данные или иная чувствительная информация.
Концептуально NC AI Platform не требует персональные данные для работы. Система может получить персональные данные только косвенно, через тестовые сценарии, тестируемые приложения и артефакты выполнения тестов. В тестовом контуре PII данные могут отсутствовать полностью, если пользователь использует синтетические или обезличенные данные.
Общий принцип¶
NC AI Platform поставляется on-premise и разворачивается в контуре заказчика. При штатной эксплуатации данные тестирования, сценарии, журналы, скриншоты и отчеты остаются внутри этого контура и не передаются поставщику или во внешние сервисы. Решение о том, используются ли реальные персональные данные в тестовых данных и сценариях, принимает заказчик.
Со стороны поставщика указываются потенциальные места хранения и обработки таких данных, чтобы администраторы и ИБ заказчика могли применить нужные организационные и технические меры защиты.
Потенциальные места хранения¶
| Категория хранилища | Технический компонент | Что хранит | Как может появиться PII |
|---|---|---|---|
| Основная база данных платформы | MongoDB | Пользователи платформы, проекты, сценарии, параметры запусков, задачи, журналы выполнения | ФИО, email, логины пользователей; значения в сценариях, параметрах и логах |
| Объектное хранилище артефактов | MinIO / S3 NeuroControl | Изображения, скриншоты, артефакты распознавания UI | Данные, отображенные на экране тестируемого приложения |
| Хранилище результатов выполнения | Allure / Allure reports | Результаты запусков, вложения, отчеты | Логи, шаги, параметры, скриншоты и сообщения об ошибках |
| Временное хранилище и cache | Redis | Временные данные и cache | Технические данные приложения; компонент должен защищаться как часть контура платформы |
| Постоянные файловые каталоги сервисов | Docker volumes | Данные MongoDB, RabbitMQ, Allure, MinIO и другие persisted volumes | Те же данные, что хранятся соответствующими сервисами |
| Журналы технической эксплуатации | Container logs | Технические сообщения сервисов | Фрагменты ошибок, параметров или сообщений выполнения при некорректной эксплуатации сценариев |
Состав хранилищ данных и фактические пути размещения описываются в руководствах администратора, входящих в
Ответственность сторон¶
Поставщик NC AI Platform:
- документирует потенциальные места хранения и обработки данных;
- предоставляет механизмы авторизации и разграничения доступа внутри платформы;
- не требует использования реальных персональных данных для работы платформы;
- рекомендует не помещать реальные персональные данные в тестовые сценарии, параметры и артефакты, если это не требуется регламентами заказчика.
Заказчик / пользователь NC AI Platform:
- определяет, допускается ли использование реальных персональных данных в тестовой и продукционной эксплуатации;
- отвечает за наполнение тестируемых приложений и тестовых сценариев реальными, обезличенными или синтетическими данными;
- управляет остаточным риском внутри своего закрытого контура: настраивает защиту хранилищ, резервных копий, сетевых доступов, журналов, регламенты допуска сотрудников и права пользователей NC AI Platform.
- определяет сроки хранения и порядок удаления артефактов тестирования.
Настройка входа осуществляется как через локальные учетные записи, так и через корпоративный LDAP/AD. Связь LDAP-аутентификации с внутренними ролями платформы описана в разделе авторизации.
Доступность и восстановление после сбоя¶
NC AI Platform поставляется для развертывания в контуре заказчика. Данные платформы, результаты запусков, сценарии, изображения и отчеты при штатной эксплуатации хранятся в этом контуре.
Базовая поставка не реализует конфигурацию высокой доступности и автоматическое восстановление после сбоя без ручных процедур администратора.
Резервное копирование¶
В приложении выполняется автоматическое создание дампов коллекций базы данных платформы. Дампы создаются по расписанию, которое задается параметрами установки; в типовой конфигурации используется ежедневное создание дампа. Для дампов применяются ограничения хранения по возрасту, общему объему и минимальному количеству сохраняемых копий.
Этот механизм относится к данным основной базы приложения и не заменяет резервное копирование всего эксплуатационного контура. Резервное копирование файловых хранилищ, отчетов, артефактов выполнения, конфигурационных файлов, резервных копий самих дампов, а также проверку процедуры восстановления обеспечивает эксплуатирующая сторона.
RPO и RTO¶
Формальные бизнес-SLA по доступности, RPO и RTO в базовой поставке не заявляются.
Для плановых административных операций потеря данных может быть исключена, если перед созданием резервной копии пользователи предупреждены, выполнение операций записи остановлено, а сервисы переведены в состояние, исключающее изменение данных. В таком режиме для конкретной операции резервного копирования может быть достигнуто значение RPO, равное нулю.
Для внепланового сбоя фактическое RPO определяется моментом последней корректной резервной копии и составом данных, которые были включены в процедуру резервного копирования.
Фактическое RTO определяется временем выполнения административной процедуры восстановления: остановкой сервисов, подготовкой резервной копии, переносом архива при необходимости, восстановлением данных, запуском сервисов и проверкой работоспособности продукта.