Panoramica della protezione dei dati di base di ASP.NET

  • Articolo

La protezione dei dati di base di ASP.NET fornisce un'API crittografica per proteggere i dati, inclusa la gestione e la rotazione delle chiavi.

Le applicazioni Web spesso devono archiviare dati sensibili alla sicurezza. Windows fornisce un'API di protezione dei dati, DPAPI, ma Windows DPAPI non è destinata all'uso nelle applicazioni Web.

Lo stack di protezione dei dati core ASP.NET è progettato per fungere da sostituzione a lungo termine per l'elemento <machineKey> in ASP.NET 1.x - 4.x. È stato progettato per risolvere molte delle carenze dello stack crittografico precedente, fornendo al tempo stesso una soluzione predefinita per la maggior parte dei casi d'uso, è probabile che si verifichino applicazioni moderne.

Presentazione del problema

L'istruzione complessiva del problema può essere concisamente dichiarata in una singola frase: è necessario rendere persistenti le informazioni attendibili per il recupero successivo, ma non si considera attendibile il meccanismo di persistenza. In termini Web, questo potrebbe essere scritto come "È necessario eseguire il round trip dello stato attendibile tramite un client non attendibile".

L'esempio canonico di questo è un token di autenticazione cookie o di connessione. Il server genera un token "I am Groot and have xyz permissions" (I am Groot and have xyz permissions) e lo passa al client. In una data futura il client presenterà il token al server, ma il server necessita di un certo tipo di garanzia che il client non abbia contraffatto il token. Il primo requisito: autenticità (integrità, manomissione).

Poiché lo stato persistente è considerato attendibile dal server, si prevede che questo stato possa contenere informazioni specifiche dell'ambiente operativo. Può trattarsi di un percorso di file, di un'autorizzazione, di un handle o di un altro riferimento indiretto o di altri dati specifici del server. Tali informazioni non devono in genere essere divulgate a un client non attendibile. Il secondo requisito: riservatezza.

Infine, poiché le applicazioni moderne sono componentizzate, ciò che abbiamo visto è che i singoli componenti vogliono sfruttare questo sistema senza considerare altri componenti del sistema. Ad esempio, se un componente del token di connessione usa questo stack, deve funzionare senza interferenze da un meccanismo anti-CSRF che potrebbe anche usare lo stesso stack. Pertanto, il requisito finale: isolamento.

È possibile fornire ulteriori vincoli per limitare l'ambito dei requisiti. Si presuppone che tutti i servizi che operano all'interno del cryptosystem siano ugualmente attendibili e che i dati non debbano essere generati o utilizzati all'esterno dei servizi sotto il nostro controllo diretto. Inoltre, è necessario che le operazioni siano il più velocemente possibile perché ogni richiesta al servizio Web potrebbe passare attraverso il sistema di crittografia una o più volte. Ciò rende la crittografia simmetrica ideale per lo scenario e possiamo scontate la crittografia asimmetrica fino a quando non è necessario.

Filosofia di progettazione

È stato iniziato identificando i problemi con lo stack esistente. Una volta che lo avevamo fatto, abbiamo esplorato il panorama delle soluzioni esistenti e abbiamo concluso che nessuna soluzione esistente aveva le capacità che abbiamo cercato. Abbiamo quindi progettato una soluzione basata su diversi principi guida.

  • Il sistema deve offrire semplicità di configurazione. Idealmente, il sistema sarebbe zero-configuration e gli sviluppatori potrebbero raggiungere il terreno in esecuzione. Nelle situazioni in cui gli sviluppatori devono configurare un aspetto specifico (ad esempio il repository delle chiavi), è necessario considerare l'esigenza di semplificare tali configurazioni specifiche.

  • Offrire una semplice API rivolta ai consumer. Le API devono essere facili da usare correttamente e difficili da usare in modo non corretto.

  • Gli sviluppatori non devono apprendere i principi chiave di gestione. Il sistema deve gestire la selezione dell'algoritmo e la durata della chiave per conto dello sviluppatore. Idealmente lo sviluppatore non dovrebbe mai avere accesso al materiale chiave non elaborato.

  • Quando possibile, le chiavi devono essere protette inattive. Il sistema deve individuare un meccanismo di protezione predefinito appropriato e applicarlo automaticamente.

Tenendo presente questi principi, abbiamo sviluppato uno stack di protezione dei dati semplice e facile da usare .

Le API di protezione dei dati di base di ASP.NET non sono destinate principalmente alla persistenza illimitata dei payload riservati. Altre tecnologie, ad esempio DPAPI CNG di Windows e Azure Rights Management , sono più adatte allo scenario di archiviazione a tempo indeterminato e hanno funzionalità di gestione delle chiavi avanzate corrispondenti. Detto questo, non c'è nulla che impedisca a uno sviluppatore di usare le API di protezione dei dati core ASP.NET per la protezione a lungo termine dei dati riservati.

Destinatario

Il sistema di protezione dei dati è suddiviso in cinque pacchetti principali. Vari aspetti di queste API sono destinati a tre destinatari principali;

  1. Panoramica delle API consumer per sviluppatori di applicazioni e framework di destinazione.

    "Non voglio sapere come funziona lo stack o su come viene configurato. Voglio semplicemente eseguire un'operazione nel modo più semplice possibile con alta probabilità di usare correttamente le API."

  2. Le API di configurazione sono destinate agli sviluppatori di applicazioni e agli amministratori di sistema.

    "È necessario indicare al sistema di protezione dei dati che l'ambiente richiede percorsi o impostazioni non predefiniti".

  3. Le API di estendibilità sono destinate agli sviluppatori responsabili dell'implementazione di criteri personalizzati. L'uso di queste API sarebbe limitato a rare situazioni e a sviluppatori esperti e consapevoli della sicurezza.

    "Devo sostituire un intero componente all'interno del sistema perché ho requisiti comportamentali davvero univoci. Sono disposto a imparare parti usate raramente della superficie API per creare un plug-in che soddisfi i miei requisiti."

Layout del pacchetto

Lo stack di protezione dei dati è costituito da cinque pacchetti.

Risorse aggiuntive