Безопасность
Контроль доступа, событий и решений
Безопасность документного процесса складывается из нескольких уровней: кто видит документ, какие действия разрешены, как проверяется входящий файл, где хранятся секреты интеграций и можно ли восстановить историю решения.
Изоляция данных по организации
Роли и ограниченные области наблюдения
Журнал действий и интеграционных событий
01
Доступ внутри организации
Документы и процессы привязаны к организации. Серверная проверка ограничивает запросы контекстом текущего пользователя; интерфейс не считается границей безопасности. Права дополняются ролями и областями наблюдения.
Административные и чувствительные действия фиксируются отдельно. В журнале можно хранить участника, объект действия, результат, идентификатор запроса и технический контекст.
- роль пользователя и разрешённые действия;
- принадлежность процесса и документа организации;
- область наблюдения для отдельных подразделений;
- аудит административных операций.
02
Работа с файлами
На входе проверяются размер и разрешённый тип файла. Документ получает отдельную версию, а распознанный текст и результаты анализа связаны с исходным объектом. Доступ к просмотру выдаётся через серверный маршрут.
Конкретные параметры хранения, шифрования и резервного копирования зависят от выбранной инфраструктуры. Их нельзя считать свойством продукта без проверки конфигурации развёртывания.
03
Интеграции и внешние вызовы
Токены подключений остаются на серверной стороне. Для вебхуков предусмотрены подпись сообщения, повторные попытки и журнал доставки. Исходящие URL проходят проверку, чтобы снизить риск обращения к внутренним адресам через пользовательский ввод.
Безопасный производственный контур также требует ротации секретов, сетевых ограничений и наблюдения за ошибками. Эти меры настраиваются совместно с владельцем инфраструктуры.
- секреты не встраиваются в клиентский код;
- подпись и проверка целостности вебхуков;
- ограничение исходящих адресов;
- история попыток доставки и ошибок.
04
Что мы не заявляем без подтверждения
Эта страница описывает реализованные механизмы и принципы проектирования, но не заменяет аудит конкретного развёртывания. АА.Докс не заявляет сертификацию, соответствие отраслевому стандарту или размещение в определённой юрисдикции, пока это не подтверждено документами и выбранной конфигурацией.
Провайдеры ИИ и распознавания выбираются в конфигурации развёртывания. В зависимости от выбранного сценария внешнему провайдеру может передаваться текст или файл документа, поэтому состав данных, модель и условия обработки нужно согласовать до запуска. Финальные решения по документу остаются за назначенной ролью.
Перед использованием производственных данных нужно согласовать модель угроз, требования к хранению, резервному копированию, журналам, срокам удаления и реагированию на инциденты. Сообщение о возможной уязвимости можно передать через страницу контактов без публикации технических деталей в открытом поле.
Сверим требования к контуру
Пришлите перечень обязательных требований без секретов и персональных данных. Мы отделим готовые механизмы от настроек и работ, которые нужны именно вашему развёртыванию.