Sicurezza, secrets e operatività sicura

La sicurezza nelle applicazioni generate con Lino inizia nel progetto generato stesso. Lino registra già i secrets locali, configura parametri sensibili in Aspire e crea la base per JWT, API keys, token temporanei e policies di rate limiting per le API.

Questa pagina spiega perché esistono queste protezioni e come mantenerle quando l'applicazione evolve. L'idea centrale è che un secret non nasce dentro il repository e un'API pubblica non nasce senza limiti d'uso; Lino fornisce questo modello per ridurre fughe accidentali di credenziali e abuso di endpoint sensibili come login, refresh token, registrazione e recupero password.

Secrets locali del progetto

Lino registra automaticamente i secrets locali necessari per l'applicazione generata. Password di database, Redis e RabbitMQ, chiave JWT, API keys e altri valori sensibili restano negli User Secrets dell'applicazione, invece di nascere in file versionati.

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

I comandi restano utili per la manutenzione: usa secret list per verificare le chiavi configurate, secret set per modificare o registrare valori locali, secret remove per eliminare una chiave e secret clear per rimuovere tutti i secrets locali del progetto.

Questo flusso è integrato nel progetto generato. Quando aggiungi risorse come Redis, RabbitMQ, autenticazione, autorizzazione, SMTP, API keys o token di download, Lino mantiene i valori sensibili fuori dal codice sorgente e prepara l'applicazione a riceverli come configurazione d'ambiente.

Puoi anche ispezionare i secrets locali con strumenti della piattaforma .NET e Aspire, quando applicabile, come dotnet user-secrets list o risorse equivalenti di Aspire. Il comando di Lino esiste per rendere questo flusso più diretto nel contesto del progetto generato.

Parametri in Aspire

L'AppHost di Aspire coordina risorse come database, Redis, RabbitMQ, API, worker e web app. Nei progetti generati, Lino registra i valori sensibili come parametri di Aspire affinché l'applicazione li tratti come dipendenze esterne, non come dati fissi nel codice sorgente.

Questo include password di database, Redis, RabbitMQ e altri valori necessari per l'infrastruttura locale. L'AppHost passa questi parametri alle risorse corrispondenti usando il modello di secret di Aspire, per esempio con parametri marcati come sensibili.

Il vantaggio pratico è che il secret smette di essere un dettaglio perso nei file di configurazione e diventa parte del modello di esecuzione della soluzione. Quando esegui l'applicazione tramite Aspire, i servizi ricevono le dipendenze di cui hanno bisogno senza richiederti di copiare manualmente le password in ogni progetto.

Questo design aiuta anche il deploy. Quando Aspire pubblica artefatti, la necessità di questi parametri continua a esistere: in Docker Compose, per esempio, possono comparire placeholder e file di ambiente da compilare nell'ambiente corretto; in altri target, lo stesso principio guida il passaggio della configurazione sensibile alla piattaforma.

Rate limiting

Il rate limiting riduce abuso, brute force e consumo improprio di risorse. Lino configura già policies predefinite e applica helper agli endpoint generati affinché API pubbliche, autenticate, interne e sensibili non nascano senza limiti d'uso.

Questo è importante perché un'API può autenticare correttamente e subire comunque abuso di volume. Login, refresh token, registrazione e recupero password sono flussi sensibili; per impostazione predefinita, Lino li separa dagli endpoint comuni affinché abbiano limiti più conservativi.

Usa le policies generate quando crei nuovi endpoint.
Mantieni limiti diversi per endpoint sensibili ed endpoint comuni.
Combina rate limiting con autenticazione, validazione e protezione dai bot quando necessario.
Tratta 429 Too Many Requests come risposta attesa quando il limite viene superato.

Policy	Uso predefinito in Lino	Come applicarla durante l'evoluzione
`anonymous`	Endpoint pubblici senza autenticazione.	Usa per API anonime che non creano token, account o credenziali.
`authenticated-user`	Traffico autenticato partizionato per utente corrente.	Usa come standard per API autenticate comuni.
`identity-sensitive`	Login, registrazione, refresh token, password dimenticata e cambio/reset password.	Usa in endpoint che creano token, codici o modificano credenziali.
`api-key`	Endpoint interni protetti da API key.	Usa in integrazioni service-to-service che seguono il filtro API key.
`download-token`	Generazione di token temporanei di download.	Usa quando utenti autenticati possono emettere link o token brevi.

Sicurezza JWT

Quando viene aggiunta l'autenticazione, Lino genera la base per emissione, lettura e validazione dei JWT, mantenendo la chiave di firma fuori dal codice sorgente. Il token identifica l'utente e porta claims essenziali senza trasformare il JWT in un database portatile.

Mantieni la chiave di firma in User Secrets durante lo sviluppo e in un provider sicuro in produzione.
Preserva la validazione di issuer, audience, scadenza e algoritmo configurata nel progetto.
Includi solo i claims necessari per il flusso autenticato.
In multi-tenancy, usa il contesto utente e tenant che Lino rende già disponibile.

La chiave di firma del JWT è un secret critico, e Lino tratta già questo valore come configurazione sensibile. Quando crei nuovi ambienti, pipeline o deploy, mantieni la stessa regola: la chiave non deve apparire in commit, immagini Docker, log, file pubblici o esempi reali di configurazione.

JWT inoltre non sostituisce l'autorizzazione nel dominio. I claims aiutano a prendere decisioni, ma le operazioni critiche devono ancora considerare stato attuale, stato dell'utente, permessi attivi e contesto della richiesta. La parte generata fornisce la base; la tua responsabilità quando evolvi il sistema è non creare scorciatoie che ignorino questo flusso.

API keys e token di download

Lino tratta API keys e token temporanei come credenziali con ambito limitato. Quando un flusso deve rilasciare accesso temporaneo a un file, pacchetto o integrazione, la base generata favorisce token brevi e specifici invece di riutilizzare credenziali ampie.

Usa scadenza breve per link e token temporanei.
Associa il token a utente, tenant e risorsa quando il flusso ha questo contesto.
Registra l'uso per audit quando l'accesso coinvolge artefatti sensibili.
Revoca i token quando la risorsa o il permesso cambia.

Le API protette da chiave usano il modello di autorizzazione e rate limiting generato da Lino. Una chiave creata per automazione di integrazione non deve diventare un lasciapassare per chiamate amministrative, e un token temporaneo di download non deve sostituire i permessi dell'utente autenticato.

Quando crei nuovi flussi di download o integrazione, mantieni la stessa idea: ambito esplicito, scadenza, metadati utili e policy di rate limiting adeguata. Così l'accesso temporaneo resta auditabile e prevedibile, invece di diventare una credenziale libera che circola nel sistema.

Provider di secrets in produzione

User Secrets risolve lo sviluppo locale. In produzione, mantieni la stessa separazione usando il provider sicuro della piattaforma: Azure Key Vault, AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Kubernetes Secrets o variabili d'ambiente protette dall'orchestratore.

Lino prepara l'applicazione a ricevere configurazione sensibile dall'esterno del codice. Il passaggio alla produzione è una decisione d'ambiente: nomi e parametri continuano a esistere, ma i valori arrivano dal vault, dalla pipeline o dall'orchestratore usato dalla tua infrastruttura.

In produzione entrano anche pratiche operative come rotazione, segregazione per ambiente, permessi per applicazione e audit degli accessi. User Secrets non sostituisce questi controlli; copre l'esperienza locale senza mettere secrets nel repository.

Separa per ambiente: sviluppo, staging e produzione non devono condividere credenziali.
Separa per applicazione: ogni servizio deve ricevere solo i secrets di cui ha bisogno.
Pianifica la rotazione: chiavi JWT, SMTP, API keys e password di database richiedono una procedura di sostituzione.
Audita l'accesso: registra chi può leggere o modificare secrets nella piattaforma.