Segurança, secrets e operação segura

Segurança em aplicações geradas com Lino começa no próprio projeto gerado. O Lino já registra secrets locais, configura parâmetros sensíveis no Aspire, cria a base de JWT, API keys, tokens temporários e policies de rate limiting para as APIs.

Esta página explica por que essas proteções existem e como mantê-las ao evoluir a aplicação. A ideia central é que segredo não nasce dentro do repositório e API pública não nasce sem limite de uso; o Lino entrega esse padrão para reduzir vazamento acidental de credenciais e abuso de endpoints sensíveis como login, refresh token, cadastro e recuperação de senha.

Secrets locais do projeto

O Lino registra automaticamente os secrets locais necessários para a aplicação gerada. Senhas de banco de dados, Redis, RabbitMQ, chave JWT, API keys e outros valores sensíveis ficam no User Secrets da aplicação, em vez de nascerem em arquivos versionados.

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

Os comandos continuam úteis para manutenção: use secret list para auditar chaves configuradas, secret set para alterar ou registrar valores locais, secret remove para excluir uma chave e secret clear para limpar todos os secrets locais do projeto.

Esse fluxo é integrado ao projeto gerado. Quando você adiciona recursos como Redis, RabbitMQ, autenticação, autorização, SMTP, API keys ou tokens de download, o Lino mantém os valores sensíveis fora do código-fonte e prepara a aplicação para recebê-los como configuração de ambiente.

Você também pode inspecionar secrets locais com ferramentas da plataforma .NET e Aspire, quando aplicável, como dotnet user-secrets list ou recursos equivalentes do Aspire. O comando do Lino existe para tornar esse fluxo mais direto dentro do contexto do projeto gerado.

Parâmetros no Aspire

O AppHost do Aspire coordena recursos como bancos, Redis, RabbitMQ, APIs, workers e web apps. Nos projetos gerados, o Lino registra valores sensíveis como parâmetros do Aspire para que a aplicação trate esses valores como dependências externas, não como dados fixos no código-fonte.

Isso inclui senhas de banco de dados, Redis, RabbitMQ e outros valores necessários para a infraestrutura local. O AppHost passa esses parâmetros para os recursos correspondentes, usando o modelo de segredo do Aspire, por exemplo com parâmetros marcados como sensíveis.

O ganho prático é que o segredo deixa de ser um detalhe perdido em arquivos de configuração e passa a fazer parte do modelo de execução da solução. Ao rodar a aplicação pelo Aspire, os serviços recebem as dependências de que precisam sem exigir que você copie senhas para cada projeto manualmente.

Esse desenho também ajuda o deploy. Quando o Aspire publica artefatos, a necessidade desses parâmetros continua existindo: em Docker Compose, por exemplo, podem aparecer placeholders e arquivos de ambiente a serem preenchidos no ambiente correto; em outros targets, o mesmo princípio orienta a passagem de configuração sensível para a plataforma.

Rate limiting

Rate limiting reduz abuso, brute force e consumo indevido de recursos. O Lino já configura policies padrão e aplica helpers nos endpoints gerados para que APIs públicas, autenticadas, internas e sensíveis não nasçam sem limite de uso.

Isso importa porque uma API pode autenticar corretamente e ainda assim sofrer abuso de volume. Login, refresh token, cadastro e recuperação de senha são fluxos sensíveis; por padrão, o Lino os separa de endpoints comuns para que tenham limites mais conservadores.

Use as policies geradas ao criar endpoints novos.
Mantenha limites diferentes para endpoints sensíveis e endpoints comuns.
Combine rate limiting com autenticação, validação e proteção de bots quando necessário.
Trate 429 Too Many Requests como resposta esperada quando o limite for excedido.

Policy	Uso padrão no Lino	Como aplicar ao evoluir
`anonymous`	Endpoints públicos sem autenticação.	Use em APIs anônimas que não criam token, conta ou credencial.
`authenticated-user`	Tráfego autenticado particionado pelo usuário atual.	Use como padrão para APIs autenticadas comuns.
`identity-sensitive`	Login, cadastro, refresh token, esqueci senha e troca/reset de senha.	Use em endpoints que criam tokens, códigos ou alteram credenciais.
`api-key`	Endpoints internos protegidos por chave de API.	Use em integrações service-to-service que seguem o filtro de API key.
`download-token`	Geração de tokens temporários de download.	Use quando usuários autenticados puderem emitir links ou tokens curtos.

Segurança em JWT

Quando autenticação é adicionada, o Lino gera a base de emissão, leitura e validação de JWT, mantendo a chave de assinatura fora do código-fonte. O token identifica o usuário e carrega claims essenciais sem transformar o JWT em um banco de dados portátil.

Mantenha a chave de assinatura em User Secrets no desenvolvimento e em provedor seguro na produção.
Preserve validação de issuer, audience, expiração e algoritmo configurada no projeto.
Inclua apenas claims necessárias para o fluxo autenticado.
Em multi-tenancy, use o contexto de usuário e tenant que o Lino já disponibiliza.

A chave de assinatura do JWT é segredo crítico, e o Lino já trata esse valor como configuração sensível. Ao criar novos ambientes, pipelines ou deploys, mantenha a mesma regra: a chave não deve aparecer em commit, imagem Docker, log, arquivo público ou exemplo real de configuração.

JWT também não substitui autorização no domínio. Claims ajudam a tomar decisões, mas operações críticas ainda precisam considerar estado atual, status do usuário, permissões ativas e contexto da requisição. A parte gerada fornece a base; sua responsabilidade ao evoluir o sistema é não criar atalhos que ignorem esse fluxo.

API keys e tokens de download

O Lino trata API keys e tokens temporários como credenciais de escopo limitado. Quando um fluxo precisa liberar acesso temporário a um arquivo, pacote ou integração, a base gerada favorece tokens curtos e específicos em vez de reaproveitar credenciais amplas.

Use expiração curta para links e tokens temporários.
Associe token ao usuário, tenant e recurso quando o fluxo tiver esse contexto.
Registre uso para auditoria quando o acesso envolver artefatos sensíveis.
Revogue tokens quando o recurso ou permissão mudar.

As APIs protegidas por chave usam o modelo de autorização e rate limiting gerado pelo Lino. Uma chave criada para automação de integração não deve virar passe livre para chamadas administrativas, e um token temporário de download não deve substituir permissões do usuário autenticado.

Ao criar novos fluxos de download ou integração, mantenha a mesma ideia: escopo explícito, expiração, metadados úteis e policy de rate limiting adequada. Assim o acesso temporário continua auditável e previsível, em vez de virar uma credencial solta circulando pelo sistema.

Provedores de segredo em produção

User Secrets resolvem o desenvolvimento local. Em produção, mantenha a mesma separação usando o provedor seguro da plataforma: Azure Key Vault, AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Kubernetes Secrets ou variáveis de ambiente protegidas pelo orquestrador.

O Lino prepara a aplicação para receber configuração sensível de fora do código. A troca para produção é uma decisão de ambiente: os nomes e parâmetros continuam existindo, mas os valores passam a vir do cofre, pipeline ou orquestrador usado pela sua infraestrutura.

Em produção, também entram práticas operacionais como rotação, segregação por ambiente, permissões por aplicação e auditoria de acesso. User Secrets não substituem esses controles; eles cobrem a experiência local sem colocar segredo no repositório.

Separe por ambiente: desenvolvimento, homologação e produção não devem compartilhar credenciais.
Separe por aplicação: cada serviço deve receber apenas os segredos de que precisa.
Planeje rotação: chaves JWT, SMTP, API keys e senhas de banco precisam de procedimento de troca.
Audite acesso: registre quem pode ler ou alterar segredos na plataforma.