Сервис не готов к публичному размещению. Сервисные ключи, пользовательские учётные записи и repository ACL реализованы; внешняя проверка угроз, эксплуатационные процедуры и полный аудит доступа ещё требуются перед production.

Учётные записи создаёт администратор; самостоятельная регистрация включается только ARKVORY_ALLOW_REGISTRATION=true и не занимает последние 100 мест. Сессии и персональные токены (PAT) хранятся в PostgreSQL в виде хеша. Сессии отзываются при выходе, отключении аккаунта или смене пароля; смена и сброс пароля отзывают также все PAT. Проверка membership и repository grants выполняется на каждом запросе. Пароли хешируются scrypt. Вид учётных данных (session, personal-token, service-key, file-key) входит в principal: PAT создаются, отзываются и меняют пароль только из сессии, никогда не получают права администратора, имеют scope read/read-write и обязательный срок до 365 дней. Вход и регистрация ограничены по адресу клиента до хеширования, жёсткую блокировку заменил ограниченный backoff учётной записи (не дольше 2 минут), анонимная и административная проверка паролей идут через разные очереди. События identity пишутся в append-only журнал GET /api/v1/security/audit. За reverse proxy задайте ARKVORY_TRUSTED_PROXIES. См. IDENTITY, ADR 0011, ADR 0049.

Управляемые machine credentials проверяются через PostgreSQL на каждом запросе, без положительного auth cache. Эффективные права — пересечение account policy и key bindings. Перед фиксацией изменения проверка повторяется под короткими row locks; revoke/disable/policy update упорядочены с публикацией. Уже начатое скачивание не прерывается только из-за revoke. Создание аккаунтов и назначение grants требует отдельного локального serviceAdministrator, не обычного administrator. Управление существующим аккаунтом допускается делегированному managed key с точной целью/actions/ceiling; самоуправление и цепочки запрещены. Отзыв grant блокирует pending activation, но не отзывает уже активированные ключи потребителя: для них требуется явный revoke/disable. Control mutation повторно проверяет authority после общей транзакционной блокировки; начатое snapshot-чтение может завершиться по прежнему grant. Контракт делегирования. Подробнее: эксплуатация и границы, ADR 0017.

• TLS с проверкой сертификатов; сервисные аккаунты с минимальными правами и возможностью ротации/отзыва.
• Авторизация на уровне репозитория и операции; фильтрация поиска и счётчиков по тем же правам.
• Ограниченные по объекту, действию, допуску и сроку токены передачи. Их нельзя логировать.
• Недоступность внешнего сервиса не включает анонимный режим доступа.
• Валидация путей, имен, архивов, metadata и размеров. Не использовать пользовательский путь напрямую как путь blob на сервере.
• Ограничения распаковки, количества частей/записей, очередей, staging и параллелизма.
• Исходящие запросы сервера идут только по адресам, которые задаёт доверенный администратор в конфигурации (источники зеркал в ARKVORY_MIRRORS_FILE), получатели webhook (ARKVORY_WEBHOOKS_FILE, ADR 0069) и по фиксированным адресам самого продукта (обратная связь, проверка обновлений); ограничивайте их сетевой политикой. Адреса webhook проходят защиту от SSRF: HTTPS с проверкой сертификата, запрет loopback, private, link-local и metadata-адресов (private-сети только явным списком ARKVORY_WEBHOOKS_ALLOW_PRIVATE), соединение с проверенным IP, без редиректов. Секрет подписи лежит в файле с правами учётной записи службы и не попадает в журнал. Импорта по URL нет.
• Резервные копии: vault шифруется по умолчанию (AES-256-GCM с проверкой подлинности, ADR 0070); ключ агента лежит в файле службы, recovery kit хранится вне сервера, ключи не попадают в аргументы, журналы, API, метрики и manifest, а подмена, усечение и перестановка файлов vault обнаруживаются. Vault без шифрования требует зашифрованного тома.
• Безопасный вывод метаданных в UI; отделение права загрузки от права approve/promote.
• Сервер не устанавливает cookie: консоль передаёт Bearer-токен заголовком Authorization и хранит его только в памяти вкладки, поэтому CSRF-защита для cookie-сессий не нужна; серверные ключи не сохраняются в браузерном коде. Если появятся cookie-сессии, CSRF-защита становится обязательной.

Используйте переменные окружения или выбранный secret store. Примеры не содержат рабочих ключей. В журналах остаются request ID, код ошибки и разрешённый контекст, но не Authorization, query key, signed URL или тело с секретами.

При обнаружении уязвимости не публикуйте credentials и эксплуатационные детали в общедоступном issue. Ответственный правообладатель — Ian Panaev, GitHub-аккаунт ProAnima. О найденных уязвимостях сообщайте на info@proanima.net — этот адрес консоль показывает как контакт ProAnimaStudio; пишите в письме описание и шаги воспроизведения, без реальных credentials.

Перед production: threat model, проверка прав и отзыва токенов, скан зависимостей, тесты путей/архивов, проверенный backup/restore, экспорт журнала безопасности во внешнее хранилище событий и назначенный владелец обновлений.