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

  • Artigo

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

Geralmente, os aplicativos Web precisam armazenar dados confidenciais. A API de proteção de dados (DPAPI) do Windows não se destina ao uso em aplicativos Web.

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

  • Fornecer uma solução interna para a maioria dos cenários da Web.
  • Resolver muitas das deficiências do sistema de criptografia anterior.
  • Servir como a substituição do elemento <machineKey> no ASP.NET 1.x a 4.x.

Instrução do problema

Preciso manter informações confiáveis para recuperação posterior, mas não confio no mecanismo de persistência. Em termos da Web, isso pode ser escrito como Preciso de um estado confiável de ida e volta por meio de um cliente não confiável".

A autenticidade, a integridade e a prova de adulteração são um requisito. O exemplo canônico disso é um cookie de autenticação ou token de portador. O servidor gera um token Eu sou Groot e tenho as permissões xyz e o envia 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 forjou o token.

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

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

Isolamento é um requisito. Como os aplicativos modernos são componetizados, os componentes individuais aproveitam esse sistema sem considerar outros componentes no sistema. Por exemplo, considere um componente de token de portador usando essa pilha. Ele deve operar sem qualquer interferência, por exemplo, de um mecanismo anti-CSRF também usando a mesma pilha.

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

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

Filosofia de design

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

  • Facilidade de configuração. O sistema se esforça para atingir a configuração zero. Em situações em que os desenvolvedores precisam configurar um aspecto específico (como o repositório de chaves), essas configurações específicas não são difíceis.
  • Ofereça uma API básica voltada para o consumidor. As APIs são simples de usar corretamente e difíceis de usar incorretamente.
  • Os desenvolvedores não precisam aprender os princípios de gerenciamento de chaves. O sistema lida com a seleção de algoritmos e o tempo de vida da chave em nome do desenvolvedor. O desenvolvedor não tem acesso ao material de chave bruta.
  • As chaves são protegidas em repouso o máximo possível. O sistema descobre um mecanismo de proteção padrão apropriado e aplica-o automaticamente.

As APIs de proteção de dados não se destinam principalmente à persistência indefinida de payloads confidenciais. Outras tecnologias, como a DPAPI da CNG do Windows e o Azure Rights Management, são mais adequadas para o cenário de armazenamento indefinido. Elas têm funcionalidades de gerenciamento de chaves proporcionalmente fortes. Dito isso, as APIs de proteção de dados do ASP.NET Core podem ser usadas para proteção de longo prazo de dados confidenciais.

Público-alvo

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

  1. As APIs de consumidor são direcionadas a desenvolvedores de aplicativos e estruturas.

    Não quero saber mais sobre como a pilha opera ou sobre como ela é configurada. Eu só quero executar alguma operação com alta probabilidade de usar as APIs com êxito.

  2. As APIs de configuração são direcionadas a desenvolvedores de aplicativos e administradores de sistemas.

    Preciso informar ao sistema de proteção de dados que meu ambiente requer caminhos ou configurações fora do padrão.

  3. As APIs de extensibilidade são direcionadas aos desenvolvedores responsáveis pela implementação da política personalizada. O uso dessas APIs é limitado a situações raras e a desenvolvedores com experiência em segurança.

    Preciso substituir um componente inteiro dentro do sistema porque tenho requisitos comportamentais realmente exclusivos. Estou disposto a aprender partes usadas de maneira incomum da superfície da API para criar um plug-in que atenda aos meus requisitos.

Layout de pacote

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

Recursos adicionais

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

Geralmente, os aplicativos Web precisam armazenar dados confidenciais. A API de proteção de dados (DPAPI) do Windows não se destina ao uso em aplicativos Web.

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

  • Fornecer uma solução interna para a maioria dos cenários da Web.
  • Resolver muitas das deficiências do sistema de criptografia anterior.
  • Servir como a substituição do elemento <machineKey> no ASP.NET 1.x a 4.x.

Instrução do problema

Preciso manter informações confiáveis para recuperação posterior, mas não confio no mecanismo de persistência. Em termos da Web, isso pode ser escrito como Preciso de um estado confiável de ida e volta por meio de um cliente não confiável".

A autenticidade, a integridade e a prova de adulteração são um requisito. O exemplo canônico disso é um cookie de autenticação ou token de portador. O servidor gera um token Eu sou Groot e tenho as permissões xyz e o envia 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 forjou o token.

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

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

Isolamento é um requisito. Como os aplicativos modernos são componetizados, os componentes individuais aproveitam esse sistema sem considerar outros componentes no sistema. Por exemplo, considere um componente de token de portador usando essa pilha. Ele deve operar sem qualquer interferência, por exemplo, de um mecanismo anti-CSRF também usando a mesma pilha.

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

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

Filosofia de design

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

  • Facilidade de configuração. O sistema se esforça para atingir a configuração zero. Em situações em que os desenvolvedores precisam configurar um aspecto específico (como o repositório de chaves), essas configurações específicas não são difíceis.
  • Ofereça uma API básica voltada para o consumidor. As APIs são simples de usar corretamente e difíceis de usar incorretamente.
  • Os desenvolvedores não precisam aprender os princípios de gerenciamento de chaves. O sistema lida com a seleção de algoritmos e o tempo de vida da chave em nome do desenvolvedor. O desenvolvedor não tem acesso ao material de chave bruta.
  • As chaves são protegidas em repouso o máximo possível. O sistema descobre um mecanismo de proteção padrão apropriado e aplica-o automaticamente.

As APIs de proteção de dados não se destinam principalmente à persistência indefinida de payloads confidenciais. Outras tecnologias, como a DPAPI da CNG do Windows e o Azure Rights Management, são mais adequadas para o cenário de armazenamento indefinido. Elas têm funcionalidades de gerenciamento de chaves proporcionalmente fortes. Dito isso, as APIs de proteção de dados do ASP.NET Core podem ser usadas para proteção de longo prazo de dados confidenciais.

Público-alvo

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

  1. As APIs de consumidor são direcionadas a desenvolvedores de aplicativos e estruturas.

    Não quero saber mais sobre como a pilha opera ou sobre como ela é configurada. Eu só quero executar alguma operação com alta probabilidade de usar as APIs com êxito.

  2. As APIs de configuração são direcionadas a desenvolvedores de aplicativos e administradores de sistemas.

    Preciso informar ao sistema de proteção de dados que meu ambiente requer caminhos ou configurações fora do padrão.

  3. As APIs de extensibilidade são direcionadas aos desenvolvedores responsáveis pela implementação da política personalizada. O uso dessas APIs é limitado a situações raras e a desenvolvedores com experiência em segurança.

    Preciso substituir um componente inteiro dentro do sistema porque tenho requisitos comportamentais realmente exclusivos. Estou disposto a aprender partes usadas de maneira incomum da superfície da API para criar um plug-in que atenda aos meus requisitos.

Layout de pacote

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

Recursos adicionais