Gerenciamento e tempo de vida de chaves da proteção de dados no ASP.NET Core

  • Artigo

De Rick Anderson

Gerenciamento de chaves

O aplicativo tenta detectar seu ambiente operacional e lidar com a configuração de chave por conta própria.

  1. Se o aplicativo estiver hospedado nos Aplicativos do Azure, as chaves serão mantidas na pasta %HOME%\ASP.NET\DataProtection-Keys . Essa pasta é apoiada pelo repositório de rede e é sincronizada em todos os computadores que hospedam o aplicativo.

    • As chaves não são protegidas em repouso.
    • A pasta DataProtection-Keys fornece o chaveiro para todas as instâncias de um aplicativo em um único slot de implantação.
    • Slots de implantação separados, como de preparo e produção, não compartilham um anel de chave. Quando você alterna entre slots de implantação, por exemplo, trocando Preparo para Produção ou usando testes A/B, qualquer aplicativo que use a Proteção de Dados não poderá descriptografar dados armazenados usando o anel de chave dentro do slot anterior. Isso faz com que os usuários sejam desconectados de um aplicativo que usa a autenticação do ASP.NET Core cookie padrão, pois ele usa a Proteção de Dados para proteger seus cookies. Se desejar chaveiros independentes de slot, use um provedor de chaveiro externo, como o Armazenamento de Blobs do Azure, o Azure Key Vault, um repositório do SQL ou o cache do Redis.

  2. Se o perfil de usuário estiver disponível, as chaves serão persistidas para a pasta %LOCALAPPDATA%\ASP.NET\DataProtection-Keys . Se o sistema operacional for Windows, as chaves serão criptografadas em repouso por meio de DPAPI.

    O atributo setProfileEnvironment do pool de aplicativos também deve ser habilitado. O valor padrão de setProfileEnvironment é true. Em alguns cenários (por exemplo, um SO Windows), setProfileEnvironment é definido como false. Se as chaves não estiverem armazenadas no diretório do perfil do usuário como esperado:

    1. navegue até a pasta %windir%/system32/inetsrv/config.
    2. Abra o arquivo applicationHost.config.
    3. Localize o elemento <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
    4. Confirme se o atributo setProfileEnvironment não está presente, que tem como padrão o valor true, ou defina explicitamente o valor do atributo como true.

  3. Se o aplicativo estiver hospedado no IIS, as chaves serão mantidas no registro HKLM em uma chave especial do Registro que é ACLed somente para a conta de processo de trabalho. As chaves são criptografadas em repouso usando a DPAPI.

  4. Se nenhuma dessas condições corresponder, as chaves não serão mantidas fora do processo atual. Quando o processo é desligado, todas as chaves geradas são perdidas.

O desenvolvedor sempre tem controle total e pode substituir como e onde as chaves são armazenadas. As três primeiras opções acima devem fornecer bons padrões para a maioria dos aplicativos semelhantes a como as rotinas de geração automática de <machineKey> do ASP.NET funcionavam no passado. A opção final de fallback é o único cenário que exige que o desenvolvedor especifique a configuração antecipadamente se desejar persistência de chave, mas esse fallback só ocorrerá em situações raras.

Ao hospedar em um contêiner do Docker, as chaves devem ser mantidas em uma pasta que seja um volume do Docker (um volume compartilhado ou um volume montado em host que persista além do tempo de vida do contêiner) ou em um provedor externo, como o Azure Key Vault ou o Redis. Um provedor externo também será útil em cenários de web farm se os aplicativos não puderem acessar um volume de rede compartilhado (consulte PersistKeysToFileSystem para obter mais informações).

Aviso

Se o desenvolvedor substituir as regras descritas acima e apontar o sistema de Proteção de Dados em um repositório de chaves específico, a criptografia automática de chaves em repouso será desabilitada. A proteção em repouso pode ser reabilitada por meio da configuração.

Tempo de vida da chave.

As chaves têm um tempo de vida de 90 dias por padrão. Quando uma chave expira, o aplicativo gera automaticamente uma nova chave e define a nova chave como a chave ativa. Enquanto as chaves desativadas permanecerem no sistema, seu aplicativo poderá descriptografar todos os dados protegidos com elas. Consulte gerenciamento de chaves para obter mais informações.

Algoritmos padrão

O algoritmo de proteção de conteúdo padrão usado é AES-256-CBC para confidencialidade e HMACSHA256 para autenticidade. Uma chave mestra de 512 bits, alterada a cada 90 dias, é usada para derivar as duas subchaves usadas para esses algoritmos por carga. Consulte derivação de subchave para obter mais informações.

Recursos adicionais