Gerenciamento e tempo de vida de chaves da proteção de dados no ASP.NET Core
Gerenciamento de chaves
O aplicativo tenta detectar seu ambiente operacional e lidar com a configuração de chave por conta própria.
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 rest.
- 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 de cookie do ASP.NET Core 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.
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 rest usando a 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 comofalse. Se as chaves não estiverem armazenadas no diretório do perfil do usuário como esperado:- navegue até a pasta %windir%/system32/inetsrv/config.
- Abra o arquivo applicationHost.config.
- Localize o elemento
<system.applicationHost><applicationPools><applicationPoolDefaults><processModel>. - Confirme se o atributo
setProfileEnvironmentnão está presente, que tem como padrão o valortrue, ou defina explicitamente o valor do atributo comotrue.
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 rest usando a DPAPI.
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 para o sistema de Proteção de Dados em um repositório de chaves específico, a criptografia automática de chaves em rest será desabilitada. A proteção em rest 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.
Excluir chaves
A exclusão de uma chave torna seus dados protegidos permanentemente inacessíveis. Para mitigar esse risco, recomendamos não excluir chaves. O acúmulo resultante de chaves geralmente tem impacto mínimo porque elas são pequenas. Em casos excepcionais, como serviços de execução extremamente longa, as chaves podem ser excluídas. Exclua apenas as chaves:
- Que são antigas (não estão mais em uso).
- Quando puder aceitar o risco de perda de dados em troca de economia em armazenamento.
Recomendamos que as chaves de proteção de dados não sejam excluídas.
using Microsoft.AspNetCore.DataProtection.KeyManagement;
var services = new ServiceCollection();
services.AddDataProtection();
var serviceProvider = services.BuildServiceProvider();
var keyManager = serviceProvider.GetService<IKeyManager>();
if (keyManager is IDeletableKeyManager deletableKeyManager)
{
var utcNow = DateTimeOffset.UtcNow;
var yearAgo = utcNow.AddYears(-1);
if (!deletableKeyManager.DeleteKeys(key => key.ExpirationDate < yearAgo))
{
Console.WriteLine("Failed to delete keys.");
}
else
{
Console.WriteLine("Old keys deleted successfully.");
}
}
else
{
Console.WriteLine("Key manager does not support deletion.");
}
Recursos adicionais
Gerenciamento de chaves
O aplicativo tenta detectar seu ambiente operacional e lidar com a configuração de chave por conta própria.
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 rest.
- 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 de cookie do ASP.NET Core 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.
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 rest usando a 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 comofalse. Se as chaves não estiverem armazenadas no diretório do perfil do usuário como esperado:- navegue até a pasta %windir%/system32/inetsrv/config.
- Abra o arquivo applicationHost.config.
- Localize o elemento
<system.applicationHost><applicationPools><applicationPoolDefaults><processModel>. - Confirme se o atributo
setProfileEnvironmentnão está presente, que tem como padrão o valortrue, ou defina explicitamente o valor do atributo comotrue.
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 rest usando a DPAPI.
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 para o sistema de Proteção de Dados em um repositório de chaves específico, a criptografia automática de chaves em rest será desabilitada. A proteção em rest 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.
