Melhores práticas para dados de config privados e strings de conexão na configuração em ASP.NET e Azure
Um leitor enviou um e-mail perguntando como evitar o check-in acidentalmente de senhas e outros dados confidenciais no GitHub ou controle de origem em geral. Eu acho que é justo dizer que todos nós fizemos isso uma ou duas vezes - é um rito de passagem para desenvolvedores velhos e novos.
A maneira mais simples de evitar verificar senhas e/ou strings de conexão no controle de origem é (sem brincadeira) manter senhas e sequências de conexão fora de sua fonte.
Parece condescendente ou engraçado, mas não é, é verdade. Você não pode verificar o que não existe no disco.
Dito isso, às vezes você só precisa marcar um arquivo como “ignorado”, o que significa que não está sob controle de origem. Para alguns sistemas que envolvem externalizar valores de configuração que podem estar em arquivos de configuração compartilhados com um monte de dados de config não sensíveis.
ASP.NET SEGREDOS 4.6 E STRINGS DE CONEXÃO
Só para esclarecer, o quão “secreto” algo é com você. Se é realmente criptograficamente secreto ou algo como uma chave privada, você deve estar olhando para sistemas de proteção de dados ou um Cofre de Chaves como o Azure Key Vault. Aqui estamos falando de aplicativos web de impacto de negócios médios com chaves de API para APIs web de terceiros e strings de conexão que podem viver na memória por curtos períodos. Seja esperto.
ASP.NET 4.6 tem arquivos XML web.config como este com pares de nome/valor.
<appSettings>
<add key="name" value="someValue" />
<add key="name" value="someSECRETValue" />
</appSettings>
Não queremos segredos lá! Em vez disso, mova-os para fora assim:
<appSettings file="Web.SECRETS.config">
<add key="name" value="someValue" />
</appSettings>
Em seguida, basta colocar outra seção appSettings nesse arquivo web.secrets.config e ele é mesclado no tempo de execução.
NOTA: Vale ressaltar que a técnica AppSettings também funciona para aplicativos console com um app.config.
Finalmente, não deixe de adicionar Web.secrets.config (ou, melhor ainda, torná-lo *.segredos e usar uma extensão única para identificar seu config sensível.
Esta externalização do config também funciona com a
<connectionStrings configSource="secretConnectionStrings.config">
</connectionStrings>
STRINGS DE CONEXÃO/SEGREDOS DE APLICATIVOS NO AZURE
Quando você está implantando um aplicativo web para o Azure (como muitas vezes esses aplicativos são implantados a partir de source/GitHub, etc) você NUNCA deve colocar suas strings de conexão ou aplicativosSettings em web.config ou código rígido deles.
Em vez disso, use sempre a seção de configuração de configurações de aplicativos do Aplicativo no Azure.
Essas sequências de coleta e pares de valor de nome serão automaticamente disponibilizados de forma transparente para o seu site para que você não precise alterar nenhum código ASP.NET. Considerou-os com um escopo mais estreito do que o que está no web.config, e o sistema irá mesclar o conjunto automaticamente.
Além disso, elas são disponibilizadas como Variáveis ambientais, para que você possa Ambiente.GetEnvironmentVariable (“APPSETTING_yourkey”) também. Isso funciona em qualquer estrutura web, não apenas ASP.NET, então no PHP você só fica APPSETTING_yourkey(‘APPSETTING_yourkey”) como quiser.
A lista completa dos tipos de sequência de conexão do banco de dados e da sequência pré-estabelecida usada para variáveis ambientais está abaixo:
- Se você selecionar “Sql Databases”, a sequência pré-final é “SQLAZURECONNSTR_”
- Se você selecionar “SQL Server” a sequência pré-final é “SQLCONNSTR_”
- Se você selecionar “MySQL” a sequência prepended é “MYSQLCONNSTR_”
- Se você selecionar “Personalizado” a sequência prepended é “CUSTOMCONNSTR_”
ASP.NET 5
ASP.NET 5 tem o conceito de Segredos do Usuário ou Segredos de Nível de Usuário onde o par de chave/valor existe em um arquivo MAS esse arquivo não está na pasta do projeto, ele é armazenado na pasta de perfil do usuário do SISTEMA OPERACIONAL. Assim não há chance de ser verificado no controle de origem. Há um gerenciador secreto (é tudo beta, então espere que ele mude) onde você pode definir pares de nomes/valores.
ASP.NET também tem regras de escopo muito flexíveis em código. Você pode ter um aplicativoSettings, em seguida, um aplicativo específico do ambiente (dev, teste, encenação, prod) e, em seguida, segredos do usuário e, em seguida, variáveis de ambiente. Tudo isso é feito através da configuração de código e é, como mencionei, profundamente flexível. Se você não gosta, você pode mudá-lo.
var builder = new ConfigurationBuilder()
.AddJsonFile("appsettings.json")
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);
if (env.IsDevelopment())
{
// For more details on using the user secret store see http://go.microsoft.com/fwlink/?LinkID=532709
builder.AddUserSecrets();
}
builder.AddEnvironmentVariables();
Configuration = builder.Build();
Então, em conclusão:
- Não coloque coisas privadas em código.
- Parece óbvio, mas…
- Evite colocar coisas privadas em arquivos de config comuns
- Externalizá-los e ignorar o arquivo externalizado para que eles não sejam verificados
- Considere usar variáveis de ambiente ou opções de conexão em nível de usuário.
- Mantenha o config sensível fora de sua pasta de projeto no momento do desenvolvimento
Tenho certeza que perdi alguma coisa. Quais são suas dicas, Caro Leitor?
RECURSOS
Autor: Scott Hanselman