Condividi tramite


Panoramica della protezione dei dati di base di ASP.NET

ASP.NET Core fornisce un'API di crittografia per proteggere i dati, inclusa la gestione e la rotazione delle chiavi.

Le app Web spesso devono archiviare dati sensibili. L'API protezione dati di Windows (DPAPI) non è destinata all'uso nelle app Web.

Lo stack di protezione dei dati core ASP.NET è stato progettato per:

  • Fornire una soluzione predefinita per la maggior parte degli scenari Web.
  • Risolvere molte delle carenze del sistema di crittografia precedente.
  • Sostituire l'elemento <machineKey> in ASP.NET 1.x - 4.x.

Presentazione del problema

È 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 devo eseguire il round trip dello stato attendibile tramite un client non attendibile.

L'autenticità, l'integrità e la correzione delle manomissioni è un requisito. L'esempio canonico di questo è un token di autenticazione cookie o di connessione. Il server genera un oggetto Groot e dispone di un token di autorizzazioni xyz e lo invia al client. Il client presenta il token al server, ma il server necessita di un certo tipo di garanzia che il client non abbia contraffatto il token.

La riservatezza è un requisito. Poiché lo stato persistente è considerato attendibile dal server, questo stato potrebbe contenere informazioni che non devono essere divulgate a un client non attendibile. Ad esempio:

  • Percorso di file.
  • Autorizzazione.
  • Handle o altro riferimento indiretto.
  • Alcuni dati specifici del server.

L'isolamento è un requisito. Poiché le app moderne sono componentizzate, i singoli componenti vogliono sfruttare questo sistema senza considerare altri componenti del sistema. Si consideri, ad esempio, un componente del token di connessione usando questo stack. Deve funzionare senza interferenze, ad esempio da un meccanismo anti-CSRF che usa lo stesso stack.

Alcuni presupposti comuni possono limitare l'ambito dei requisiti:

  • Tutti i servizi che operano all'interno del sistema di crittografia sono ugualmente attendibili.
  • I dati non devono essere generati o utilizzati al di fuori dei servizi sotto il controllo diretto.
  • Le operazioni devono essere veloci perché ogni richiesta al servizio Web potrebbe passare attraverso il sistema di crittografia una o più volte. Il requisito di velocità rende la crittografia simmetrica ideale. La crittografia asimmetrica non viene usata fino a quando non è necessaria.

Filosofia di progettazione

ASP.NET La protezione dei dati di base è un semplice uso dello stack di protezione dei dati. e si basano sui principi seguenti:

  • Facilità di configurazione. Il sistema cerca zero configurazione. Nelle situazioni in cui gli sviluppatori devono configurare un aspetto specifico, ad esempio il repository delle chiavi, tali configurazioni specifiche non sono difficili.
  • Offrire un'API di base rivolta ai consumer. Le API sono semplici da usare correttamente e difficili da usare in modo non corretto.
  • Gli sviluppatori non devono apprendere i principi chiave di gestione. Il sistema gestisce la selezione dell'algoritmo e la durata delle chiavi per conto dello sviluppatore. Lo sviluppatore non ha accesso al materiale chiave non elaborato.
  • Le chiavi sono protette il rest più possibile. Il sistema individua un meccanismo di protezione predefinito appropriato e lo applica automaticamente.

Le API di protezione dei dati 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 illimitata. Hanno corrispondenti funzionalità di gestione delle chiavi avanzate. Detto questo, le API di protezione dei dati di base ASP.NET possono essere usate per la protezione a lungo termine dei dati riservati.

Destinatari

Il sistema di protezione dei dati fornisce API destinate a tre destinatari principali:

  1. Le API consumer sono destinate agli sviluppatori di applicazioni e framework.

    Non voglio sapere come funziona lo stack o su come viene configurato. Voglio solo eseguire un'operazione con alta probabilità di usare correttamente le API.

  2. Le API di configurazione sono destinate agli sviluppatori di app 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 è limitato a rare situazioni e sviluppatori con esperienza di sicurezza.

    Devo sostituire un intero componente all'interno del sistema perché ho requisiti comportamentali veramente 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

ASP.NET Core fornisce un'API di crittografia per proteggere i dati, inclusa la gestione e la rotazione delle chiavi.

Le app Web spesso devono archiviare dati sensibili. L'API protezione dati di Windows (DPAPI) non è destinata all'uso nelle app Web.

Lo stack di protezione dei dati core ASP.NET è stato progettato per:

  • Fornire una soluzione predefinita per la maggior parte degli scenari Web.
  • Risolvere molte delle carenze del sistema di crittografia precedente.
  • Sostituire l'elemento <machineKey> in ASP.NET 1.x - 4.x.

Presentazione del problema

È 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 devo eseguire il round trip dello stato attendibile tramite un client non attendibile.

L'autenticità, l'integrità e la correzione delle manomissioni è un requisito. L'esempio canonico di questo è un token di autenticazione cookie o di connessione. Il server genera un oggetto Groot e dispone di un token di autorizzazioni xyz e lo invia al client. Il client presenta il token al server, ma il server necessita di un certo tipo di garanzia che il client non abbia contraffatto il token.

La riservatezza è un requisito. Poiché lo stato persistente è considerato attendibile dal server, questo stato potrebbe contenere informazioni che non devono essere divulgate a un client non attendibile. Ad esempio:

  • Percorso di file.
  • Autorizzazione.
  • Handle o altro riferimento indiretto.
  • Alcuni dati specifici del server.

L'isolamento è un requisito. Poiché le app moderne sono componentizzate, i singoli componenti vogliono sfruttare questo sistema senza considerare altri componenti del sistema. Si consideri, ad esempio, un componente del token di connessione usando questo stack. Deve funzionare senza interferenze, ad esempio da un meccanismo anti-CSRF che usa lo stesso stack.

Alcuni presupposti comuni possono limitare l'ambito dei requisiti:

  • Tutti i servizi che operano all'interno del sistema di crittografia sono ugualmente attendibili.
  • I dati non devono essere generati o utilizzati al di fuori dei servizi sotto il controllo diretto.
  • Le operazioni devono essere veloci perché ogni richiesta al servizio Web potrebbe passare attraverso il sistema di crittografia una o più volte. Il requisito di velocità rende la crittografia simmetrica ideale. La crittografia asimmetrica non viene usata fino a quando non è necessaria.

Filosofia di progettazione

ASP.NET La protezione dei dati di base è un semplice uso dello stack di protezione dei dati. e si basano sui principi seguenti:

  • Facilità di configurazione. Il sistema cerca zero configurazione. Nelle situazioni in cui gli sviluppatori devono configurare un aspetto specifico, ad esempio il repository delle chiavi, tali configurazioni specifiche non sono difficili.
  • Offrire un'API di base rivolta ai consumer. Le API sono semplici da usare correttamente e difficili da usare in modo non corretto.
  • Gli sviluppatori non devono apprendere i principi chiave di gestione. Il sistema gestisce la selezione dell'algoritmo e la durata delle chiavi per conto dello sviluppatore. Lo sviluppatore non ha accesso al materiale chiave non elaborato.
  • Le chiavi sono protette il rest più possibile. Il sistema individua un meccanismo di protezione predefinito appropriato e lo applica automaticamente.

Le API di protezione dei dati 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 illimitata. Hanno corrispondenti funzionalità di gestione delle chiavi avanzate. Detto questo, le API di protezione dei dati di base ASP.NET possono essere usate per la protezione a lungo termine dei dati riservati.

Destinatari

Il sistema di protezione dei dati fornisce API destinate a tre destinatari principali:

  1. Le API consumer sono destinate agli sviluppatori di applicazioni e framework.

    Non voglio sapere come funziona lo stack o su come viene configurato. Voglio solo eseguire un'operazione con alta probabilità di usare correttamente le API.

  2. Le API di configurazione sono destinate agli sviluppatori di app 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 è limitato a rare situazioni e sviluppatori con esperienza di sicurezza.

    Devo sostituire un intero componente all'interno del sistema perché ho requisiti comportamentali veramente 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