Partilhar via

ASP.NET Visão Geral Principal de Proteção de Dados

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

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 "bearer token" utilizando 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

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 visa uma configuração mínima. 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 em repouso tanto quanto 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.

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