# Руководство по безопасности NocoBase

NocoBase уделяет особое внимание безопасности данных и приложений, начиная с функционального проектирования и заканчивая системной реализацией. Платформа включает в себя множество встроенных функций безопасности, таких как аутентификация пользователей, контроль доступа и шифрование данных, а также позволяет гибко настраивать политики безопасности в соответствии с вашими потребностями. Будь то защита пользовательских данных, управление правами доступа или изоляция сред разработки и продакшена, NocoBase предлагает практичные инструменты и решения. Это руководство призвано помочь вам безопасно использовать NocoBase, защитить ваши данные, приложения и среду, а также обеспечить эффективное использование функций системы при соблюдении всех мер безопасности.

## Аутентификация пользователей

Аутентификация пользователей используется для подтверждения личности пользователя, предотвращения несанкционированного доступа к системе и защиты от неправомерного использования учетных данных.

### Ключ токена

По умолчанию NocoBase использует JWT (JSON Web Token) для аутентификации API на стороне сервера. Вы можете установить ключ токена через системную переменную окружения `APP_KEY`. Пожалуйста, надлежащим образом управляйте ключом токена вашего приложения, чтобы предотвратить его утечку. Обратите внимание: если `APP_KEY` будет изменен, старые токены станут недействительными.

### Политика токенов

NocoBase поддерживает следующие политики безопасности для пользовательских токенов:

| Параметр конфигурации             | Описание

## Безопасность данных

### Хранение файлов

Если необходимо хранить конфиденциальные файлы, рекомендуется использовать облачное хранилище, совместимое с протоколом S3, и коммерческий плагин File storage: S3 (Pro), чтобы обеспечить приватное чтение и запись файлов.

Для локального хранилища или другого public-хранилища, доступного напрямую по URL того же источника, что и приложение, также необходимо учитывать риски, связанные с файлами с активным содержимым. Такие файлы, как `html`, `xhtml` и `svg`, могут быть напрямую интерпретированы и выполнены браузером. Если злоумышленник сможет загрузить такой файл и убедить пользователя открыть его, он сможет использовать доверенный домен приложения для размещения вредоносной страницы или скрипта.

Обычно мы рекомендуем администраторам:

- По возможности использовать приватное хранилище, подписанные URL или отдельный домен для файлов, чтобы пользовательские загрузки не отдавались напрямую с того же origin, что и основное приложение.
- Применять строгий allowlist MIME-типов для загрузки и разрешать только те типы файлов, которые действительно нужны для бизнеса.
- С осторожностью разрешать типы активного содержимого, такие как `text/html`, `application/xhtml+xml` и `image/svg+xml`. Даже если система старается отдавать такие файлы только как скачивание, это не является полноценной заменой ограничениям на загрузку и изоляции origin.
- Настраивать reverse proxy, CDN, объектное хранилище и другие слои раздачи статических файлов единообразно, чтобы опасные файлы не возвращались inline в обход защит на уровне приложения.
- Не использовать локальное/public-хранилище для размещения недоверенного веб-контента. Если такая необходимость все же есть, следует использовать изолированный домен и отдельно оценивать CSP, стратегию скачивания и контроль доступа.

Если администратор явно разрешает загрузку опасных типов файлов, он должен самостоятельно оценить риски фишинга, выполнения скриптов в том же origin и утечки чувствительной информации, а также убедиться, что Web Server, gateway, CDN и сервисы хранения применяют согласованные ограничения по всей цепочке развертывания.
