Visão geral da proteção de dados ASP.NET Core

ASP.NET Core fornece uma API criptográfica para proteger os dados, incluindo gestão e rotação de chaves.

As aplicações web muitas vezes precisam de armazenar dados sensíveis. A API de proteção de dados do Windows (DPAPI) não se destina a aplicações web.

A pilha de proteção de dados ASP.NET Core foi concebida para:

  • Fornecer uma solução integrada para a maioria dos cenários web.
  • Corrigir muitas deficiências do sistema de encriptação anterior.
  • Serve como substituto do <machineKey> elemento em ASP.NET 1.x - 4.x.

Declaração do problema

Preciso de persistir informação fidedigna para recuperação posterior, mas não confio no mecanismo de armazenamento. Em termos da Web, esta afirmação pode ser escrita como preciso de fazer o estado fiável percorrer um ciclo de ida e volta através de um cliente não fiável.

Autenticidade, integridade e proteção contra adulterações são requisitos. O exemplo canónico deste cenário é um token de autenticação cookie ou um token ao portador. O servidor gera um token de I am Groot e tem permissões xyz e envia-o ao cliente. O cliente apresenta esse token de volta ao servidor, mas o servidor precisa de algum tipo de garantia de que o cliente não falsificou o token.

A confidencialidade é um requisito. Como o estado persistente é confiável pelo servidor, este estado pode conter informação que não deve ser divulgada a um cliente não confiável. Por exemplo:

  • Um caminho de ficheiro
  • Uma permissão
  • Uma alça ou outra referência indireta
  • Alguns dados específicos do servidor

O isolamento é um requisito. Como as aplicações modernas são componentizadas, os componentes individuais querem tirar partido deste sistema sem se preocuparem com outros componentes do sistema. Por exemplo, considere um componente de token portador usando esta pilha. Deve operar sem qualquer interferência, por exemplo, de um mecanismo anti-CSRF que também utilize a mesma pilha.

Algumas suposições comuns podem restringir o âmbito dos requisitos:

  • Todos os serviços que operam dentro do criptosistema são igualmente confiáveis.
  • Os dados não precisam de ser gerados ou consumidos fora dos serviços sob o nosso controlo direto.
  • As operações devem ser rápidas porque cada pedido ao serviço web pode passar pelo criptosistema uma ou mais vezes. O requisito de velocidade torna a criptografia simétrica ideal. A criptografia assimétrica não é usada até ser necessária.

Filosofia de design

A proteção de dados do ASP.NET Core é uma plataforma de proteção de dados fácil de utilizar baseada nos seguintes princípios:

  • A configuração deve ser fácil. O sistema procura não necessitar de configuração. Em situações em que os programadores precisam de configurar um aspeto específico, como o repositório de chaves, essas configurações específicas não são difíceis.
  • Ofereça APIs básicas direcionadas para o consumidor. As APIs são simples de usar corretamente e difíceis de usar incorretamente.
  • Não exija que o programador aprenda os princípios de gestão de chaves. O sistema trata da seleção do algoritmo e da duração da chave em nome do programador. Os programadores não têm acesso ao material-chave bruto, por isso não precisam de conhecimento especializado dos princípios.
  • Proteja as chaves em repouso o máximo possível. O sistema descobre um mecanismo de proteção padrão adequado e aplica-o automaticamente.

As APIs de proteção de dados não se destinam principalmente à persistência indefinida de cargas confidenciais. Outras tecnologias, como o Windows CNG, DPAPI e Azure Rights Management , são mais adequadas ao cenário de armazenamento indefinido. Têm capacidades de gestão de chaves igualmente fortes. Dito isto, as APIs ASP.NET Core de proteção de dados podem ser usadas para a proteção a longo prazo de dados confidenciais.

Audiência alvo

O sistema de proteção de dados fornece APIs que visam três públicos principais:

  • As APIs de consumo destinam-se a programadores de aplicações e frameworks.

    Não quero aprender sobre a operação da pilha ou como está configurada. Só quero realizar alguma operação com alta probabilidade de usar as APIs com sucesso.

  • As APIs de configuração visam programadores de aplicações e administradores de sistemas.

    Preciso de dizer ao sistema de proteção de dados que o meu ambiente requer caminhos ou definições não padrão.

  • As APIs de extensibilidade destinam-se aos programadores responsáveis pela implementação de políticas personalizadas. A utilização destas APIs está limitada a situações raras e a programadores com experiência em segurança.

    Preciso de substituir um componente inteiro dentro do sistema porque tenho requisitos comportamentais verdadeiramente únicos. Estou disposto a aprender partes pouco usadas da API Surface para poder construir um plugin que cumpra os meus requisitos.

Layout do pacote

A pilha de proteção de dados consiste em cinco pacotes:

Conteúdo relacionado

ASP.NET Core fornece uma API criptográfica para proteger os dados, incluindo gestão e rotação de chaves.

As aplicações web muitas vezes precisam de armazenar dados sensíveis. A API de proteção de dados do Windows (DPAPI) não se destina a aplicações web.

A pilha de proteção de dados ASP.NET Core foi concebida para:

  • Forneça uma solução integrada para a maioria dos cenários Web.
  • Corrigir muitas das deficiências do sistema de encriptação anterior.
  • Serve como substituto do <machineKey> elemento em ASP.NET 1.x - 4.x.

Declaração do problema

Preciso de persistir informação fidedigna para recuperação posterior, mas não confio no mecanismo de armazenamento. Em termos web, isto pode ser escrito como Preciso de realizar uma comunicação de ida e volta de um estado confiável através de um cliente não confiável.

Autenticidade, integridade e proteção contra adulterações são um requisito. O exemplo canónico disto é um token de autenticação cookie ou token de portador. O servidor gera um token de I am Groot e tem permissões xyz e envia-o ao cliente. O cliente apresenta esse token de volta ao servidor, mas este precisa de algum tipo de garantia de que o cliente não falsificou o token.

A confidencialidade é um requisito. Como o estado persistente é confiável pelo servidor, este estado pode conter informações que não devem ser divulgadas a um cliente não confiável. Por exemplo:

  • Um caminho de ficheiro.
  • Uma permissão.
  • Um handle ou outra referência indireta.
  • Alguns dados específicos do servidor.

O isolamento é um requisito. Como as aplicações modernas são componentizadas, os componentes individuais querem tirar partido deste sistema sem se preocuparem com outros componentes do sistema. Por exemplo, considere um componente de token portador usando esta pilha. Deve operar sem qualquer interferência, por exemplo, de um mecanismo anti-CSRF que também utilize a mesma pilha.

Algumas suposições comuns podem restringir o âmbito dos requisitos:

  • Todos os serviços que operam dentro do criptosistema são igualmente confiáveis.
  • Os dados não precisam de ser gerados ou consumidos fora dos serviços sob o nosso controlo direto.
  • As operações devem ser rápidas, pois cada pedido ao serviço web pode passar pelo criptosistema uma ou mais vezes. O requisito de velocidade torna a criptografia simétrica ideal. A criptografia assimétrica não é usada até ser necessária.

Filosofia de design

A proteção de dados do ASP.NET Core é uma pilha de proteção de dados fácil de usar. Baseia-se nos seguintes princípios:

  • Facilidade de configuração. O sistema procura não necessitar de configuração. Em situações em que os programadores precisam de configurar um aspeto específico, como o repositório de chaves, essas configurações específicas não são difíceis.
  • Oferecer uma API básica voltada para o consumidor. As APIs são simples de usar corretamente e difíceis de usar incorretamente.
  • Os programadores não precisam de aprender princípios de gestão-chave. O sistema trata da seleção do algoritmo e da duração da chave em nome do programador. O programador não tem acesso ao material bruto-chave.
  • As chaves são protegidas da melhor forma possível quando não estão em uso. O sistema descobre um mecanismo de proteção padrão adequado e aplica-o automaticamente.

As APIs de proteção de dados não se destinam principalmente à persistência indefinida de cargas confidenciais. Outras tecnologias, como o Windows CNG, DPAPI e Azure Rights Management , são mais adequadas ao cenário de armazenamento indefinido. Têm capacidades de gestão de chaves igualmente fortes. Dito isto, as APIs ASP.NET Core de proteção de dados podem ser usadas para a proteção a longo prazo de dados confidenciais.

Público-alvo

O sistema de proteção de dados fornece APIs que visam três públicos principais:

  1. As APIs de consumo destinam-se a programadores de aplicações e frameworks.

    Não quero aprender sobre a operação da pilha ou como está configurada. Só quero realizar alguma operação com alta probabilidade de usar as APIs com sucesso.

  2. As APIs de configuração visam programadores de aplicações e administradores de sistemas.

    Preciso de dizer ao sistema de proteção de dados que o meu ambiente requer caminhos ou definições não padrão.

  3. As APIs de extensibilidade destinam-se aos programadores responsáveis pela implementação de políticas personalizadas. A utilização destas APIs está limitada a situações raras e a programadores com experiência em segurança.

    Preciso de substituir um componente inteiro dentro do sistema porque tenho requisitos comportamentais verdadeiramente únicos. Estou disposto a aprender partes invulgarmente usadas da superfície API para construir um plugin que cumpra os meus requisitos.

Layout do pacote

A pilha de proteção de dados consiste em cinco pacotes:

Recursos adicionais

  • Last updated on