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

  • Artigo

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

Os aplicativos Web geralmente precisam armazenar dados confidenciais de segurança. O Windows fornece uma API de proteção de dados, DPAPI, mas o 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 servir como a substituição de longo prazo para o elemento <machineKey> no ASP.NET 1.x - 4.x. Ele foi projetado para resolver muitas das deficiências da pilha criptográfica antiga, fornecendo uma solução pronta para uso para a maioria dos casos de uso que os aplicativos modernos provavelmente encontrarão.

Problema declarado

A instrução geral do problema pode ser sucintamente declarada em uma única frase: preciso persistir 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".

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 as entrega ao cliente. Em alguma data futura, o cliente apresentará esse token de volta ao servidor, mas o servidor precisa de algum tipo de garantia de que o cliente não forjou o token. Assim, o primeiro requisito: autenticidade (também conhecido como integridade, proteção contra violações).

Como o estado persistente é confiável para o servidor, antecipamos que esse estado pode conter informações específicas para o ambiente operacional. Isso pode estar na forma de um caminho de arquivo, uma permissão, um identificador ou outra referência indireta ou alguma outra parte de dados específicos do servidor. Essas informações geralmente não devem ser divulgadas para um cliente não confiável. Dessa forma, o segundo requisito é confidencialidade.

Por fim, como os aplicativos modernos são componentes, o que vimos é que os componentes individuais desejarão aproveitar esse sistema sem considerar outros componentes no sistema. Por exemplo, se um componente de token de portador estiver usando essa pilha, ele deverá operar sem interferência de um mecanismo anti-CSRF que pode estar usando a mesma pilha. Dessa forma, o requisito final é isolamento.

Podemos fornecer restrições adicionais para restringir o escopo de nossos requisitos. Assumimos que todos os serviços que operam dentro do sistema de criptografia são igualmente confiáveis e que os dados não precisam ser gerados ou consumidos fora dos serviços sob nosso controle direto. Além disso, exigimos que as operações sejam o mais rápidas possível, pois cada solicitação para o serviço Web pode passar pelo sistema de criptografia uma ou mais vezes. Isso torna a criptografia simétrica ideal para nosso cenário e podemos descartar o uso de criptografia assimétrica até que ela seja necessária.

Filosofia de design

Começamos identificando problemas com a pilha existente. Depois disso, pesquisamos o panorama das soluções existentes e concluímos que nenhuma solução existente tinha os recursos que buscamos. Em seguida, desenvolvemos uma solução com base em vários princípios orientadores.

  • O sistema deve oferecer simplicidade de configuração. Idealmente, o sistema seria de configuração zero e os desenvolvedores poderiam começar a execução imediatamente. Em situações em que os desenvolvedores precisam configurar um aspecto específico (como o repositório de chaves), deve-se considerar a simplificação dessas configurações específicas.

  • Ofereça uma API simples voltada para o consumidor. As APIs devem ser fáceis de usar corretamente e difíceis de usar incorretamente.

  • Os desenvolvedores não devem ter que aprender os princípios de gerenciamento de chaves. O sistema deve lidar com a seleção de algoritmos e o tempo de vida da chave em nome do desenvolvedor. O ideal é que o desenvolvedor nunca tenha acesso à matéria-prima da chave.

  • As chaves devem ser protegidas em repouso quando possível. O sistema deve descobrir um mecanismo de proteção padrão apropriado e aplicá-lo automaticamente.

Com esses princípios em mente, desenvolvemos uma pilha de proteção de dados simples e fácil de usar.

As APIs de proteção de dados ASP.NET Core não se destinam principalmente à persistência indefinida de cargas 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 e têm recursos de gerenciamento de chaves correspondentemente fortes. Dito isso, não há nada que proíba um desenvolvedor de usar as APIs de proteção de dados ASP.NET Core para proteção de longo prazo de dados confidenciais.

Público

O sistema de proteção de dados é dividido em cinco pacotes principais. Vários aspectos dessas APIs têm como alvo três públicos principais;

  1. A Visão geral das APIs de consumidor tem como destino desenvolvedores de aplicativos e estruturas.

    "Não quero saber mais sobre como a pilha opera ou sobre como ela é configurada. Eu simplesmente quero executar alguma operação da maneira mais simples possível com alta probabilidade de usar as APIs com êxito."

  2. As APIs de configuração destinam-se a desenvolvedores de aplicativos e administradores de sistema.

    "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 seria limitado a situações raras e a desenvolvedores experientes e com reconhecimento de 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