Безопасность, secrets и безопасная эксплуатация

Локальные secrets проекта

Lino автоматически регистрирует локальные secrets, необходимые сгенерированному приложению. Пароли базы данных, Redis и RabbitMQ, JWT-ключ, API keys и другие чувствительные значения остаются в User Secrets приложения, а не создаются в версионируемых файлах.

lino secret list
lino secret set
lino secret remove
lino secret clear

Команды остаются полезными для сопровождения: используйте secret list, чтобы проверить настроенные ключи, secret set, чтобы изменить или зарегистрировать локальные значения, secret remove, чтобы удалить ключ, и secret clear, чтобы очистить все локальные secrets проекта.

Этот поток интегрирован со сгенерированным проектом. Когда вы добавляете ресурсы, такие как Redis, RabbitMQ, аутентификация, авторизация, SMTP, API keys или download tokens, Lino удерживает чувствительные значения вне исходного кода и подготавливает приложение к получению их как конфигурации окружения.

Вы также можете проверять локальные secrets инструментами платформы .NET и Aspire, когда это применимо, например dotnet user-secrets list или эквивалентными ресурсами Aspire. Команда Lino существует, чтобы сделать этот поток более прямым в контексте сгенерированного проекта.

Параметры в Aspire

Aspire AppHost координирует ресурсы, такие как базы данных, Redis, RabbitMQ, API, workers и web apps. В сгенерированных проектах Lino регистрирует чувствительные значения как параметры Aspire, чтобы приложение рассматривало эти значения как внешние зависимости, а не как фиксированные данные в исходном коде.

Сюда входят пароли базы данных, Redis, RabbitMQ и другие значения, необходимые для локальной инфраструктуры. AppHost передает эти параметры соответствующим ресурсам с использованием модели secret в Aspire, например через параметры, помеченные как sensitive.

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

Этот дизайн также помогает deploy. Когда Aspire публикует артефакты, потребность в этих параметрах сохраняется: например, в Docker Compose могут появиться placeholders и файлы окружения, которые нужно заполнить в правильной среде; в других targets тот же принцип направляет передачу чувствительной конфигурации на платформу.

Rate limiting

Rate limiting снижает злоупотребления, brute force и неправильное потребление ресурсов. Lino уже настраивает policies по умолчанию и применяет helpers к сгенерированным endpoints, чтобы публичные, аутентифицированные, внутренние и чувствительные API не создавались без ограничений использования.

Это важно, потому что API может корректно выполнять аутентификацию и все равно страдать от злоупотребления объемом запросов. Login, refresh token, регистрация и восстановление пароля являются чувствительными потоками; по умолчанию Lino отделяет их от обычных endpoints, чтобы у них были более консервативные лимиты.

• Используйте сгенерированные policies при создании новых endpoints.
• Сохраняйте разные лимиты для чувствительных и обычных endpoints.
• При необходимости сочетайте rate limiting с аутентификацией, валидацией и защитой от bots.
• Рассматривайте 429 Too Many Requests как ожидаемый ответ при превышении лимита.

Безопасность JWT

Когда добавляется аутентификация, Lino генерирует основу для выпуска, чтения и проверки JWT, удерживая ключ подписи вне исходного кода. Token идентифицирует пользователя и несет необходимые claims, не превращая JWT в переносимую базу данных.

• Храните ключ подписи в User Secrets при разработке и у безопасного provider в production.
• Сохраняйте проверку issuer, audience, срока действия и алгоритма, настроенную в проекте.
• Включайте только claims, необходимые для аутентифицированного потока.
• В multi-tenancy используйте контекст пользователя и tenant, который Lino уже предоставляет.

Ключ подписи JWT является критическим secret, и Lino уже обрабатывает это значение как чувствительную конфигурацию. При создании новых окружений, pipelines или deploys сохраняйте то же правило: ключ не должен появляться в commit, Docker image, log, публичном файле или реальном примере конфигурации.

JWT также не заменяет авторизацию в домене. Claims помогают принимать решения, но критические операции все равно должны учитывать текущее состояние, статус пользователя, активные permissions и контекст запроса. Сгенерированная часть предоставляет основу; ваша ответственность при развитии системы - не создавать обходные пути, игнорирующие этот поток.

API keys и download tokens

Lino рассматривает API keys и временные tokens как credentials с ограниченным scope. Когда поток должен предоставить временный доступ к файлу, пакету или интеграции, сгенерированная основа предпочитает короткие и конкретные tokens вместо повторного использования широких credentials.

• Используйте короткий срок действия для links и временных tokens.
• Связывайте token с пользователем, tenant и ресурсом, когда у потока есть этот контекст.
• Записывайте использование для аудита, когда доступ затрагивает чувствительные артефакты.
• Отзывайте tokens, когда ресурс или permission меняется.

API, защищенные ключом, используют модель авторизации и rate limiting, сгенерированную Lino. Ключ, созданный для автоматизации интеграции, не должен становиться свободным пропуском для административных вызовов, а временный download token не должен заменять permissions аутентифицированного пользователя.

При создании новых потоков download или интеграции сохраняйте ту же идею: явный scope, срок действия, полезные metadata и подходящая policy rate limiting. Так временный доступ остается проверяемым и предсказуемым, а не превращается в свободную credential, циркулирующую по системе.

Secret providers в production

User Secrets решают задачу локальной разработки. В production сохраняйте то же разделение, используя безопасный provider платформы: Azure Key Vault, AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Kubernetes Secrets или переменные окружения, защищенные orchestrator.

Lino подготавливает приложение к получению чувствительной конфигурации извне кода. Переход в production является решением окружения: имена и параметры продолжают существовать, но значения начинают поступать из vault, pipeline или orchestrator, используемого вашей инфраструктурой.

В production также появляются операционные практики: rotation, разделение по окружениям, permissions по приложениям и аудит доступа. User Secrets не заменяют эти контроли; они покрывают локальный опыт, не помещая secrets в репозиторий.

• Разделяйте по окружению: development, staging и production не должны делить credentials.
• Разделяйте по приложению: каждый сервис должен получать только те secrets, которые ему нужны.
• Планируйте rotation: JWT keys, SMTP, API keys и пароли базы данных требуют процедуры замены.
• Аудируйте доступ: фиксируйте, кто может читать или изменять secrets на платформе.