No primeiro post desta série , descrevemos diversas abordagens para melhorar a segurança de suas chaves privadas SSL. A postagem terminou com uma demonstração de um ponto de distribuição de senhas remoto (PDP) usado para compartilhar com segurança senhas criptografadas com instâncias NGINX.
Sistemas de gerenciamento de segredos como o HashiCorp Vault operam de maneira semelhante ao PDP de exemplo:
Nesta postagem, mostramos como configurar o HashiCorp Vault para distribuir senhas SSL. Para ainda mais segurança, você pode configurar um módulo de segurança de hardware externo (HSM).
Para eliminar completamente o armazenamento em disco de pares de certificado-chave SSL, consulte a terceira postagem desta série, Usando o armazenamento de chave-valor do NGINX Plus para proteger chaves SSL efêmeras do HashiCorp Vault . Ele explica como gerar chaves SSL efêmeras do HashiCorp Vault e armazená-las na memória no armazenamento de chave-valor do NGINX Plus.
Esta postagem se aplica tanto ao NGINX Open Source quanto ao NGINX Plus. Para facilitar a leitura, faremos referência ao NGINX ao longo do texto.
As instruções nesta seção configuram um servidor PDP central usando o Vault para distribuir senhas SSL. Elas são baseadas nas instruções da DigitalOcean ; modifique-as conforme necessário para cumprir com suas próprias políticas do Vault.
Em nosso exemplo, cada servidor web remoto tem um token de autenticação exclusivo. Esses tokens podem ser usados para acessar segredos no caminho secret/webservers/ do Vault, e armazenamos as senhas SSL em secret/webservers/ssl_passwords .
Veremos como proteger os tokens e como revogar tokens de autenticação individuais quando necessário.
Siga as instruções do DigitalOcean para baixar e extrair o Vault no seu servidor PDP. Estamos usando o seguinte arquivo de exemplo /etc/vault.hcl para tornar o Vault acessível remotamente e desabilitar o TLS (para facilitar o uso durante os testes):
backend "arquivo" { caminho = "/var/lib/vault"
}
ouvinte "tcp" {
endereço = "0.0.0.0:8200"
tls_disable = 1
}
Inicie o Vault usando os scripts de inicialização (se você os criou) ou manualmente:
usuário@pdp:~$ sudo /usr/local/bin/vault server -config=/etc/vault.hcl
Inicialize o Vault e obtenha o Token Raiz Inicial:
user@pdp:~$ export VAULT_ADDR=http://localhost:8200 user@pdp:~$ vault init -key-shares=3 -key-threshold=2 user@pdp:~$ vault operator unseal Token raiz inicial: 86c5c2a4-8ab2-24dd-1816-48449c83114e
Precisamos fornecer o Token Raiz Inicial em muitos dos comandos a seguir. Por conveniência, atribuímos isso à variável de shell root_token
:
usuário@pdp:~$ root_token=86c5c2a4-8ab2-24dd-1816-48449c83114e
Ainda trabalhando no servidor PDP, crie um arquivo temporário chamado /tmp/ssl_passwords.txt com as senhas nele.
Armazene este arquivo como um segredo no Vault e verifique se você pode recuperá-lo:
user@pdp:~$ VAULT_TOKEN=$root_token vault kv put segredo/servidores_web/senhas_ssl value=@/tmp/senhas_ssl.txt user@pdp:~$ VAULT_TOKEN=$root_token vault kv get -field=valor segredo/servidores_web/senhas_ssl senha1 senha2 ...
Por segurança, exclua /tmp/ssl_passwords.txt .
Crie uma especificação de política em um arquivo chamado web.hcl com o seguinte conteúdo:
caminho "secreto/webservers/*" {
capacidades = ["ler"]
}
Carregue a política no Vault, nomeando-a web
:
user@pdp:~$ VAULT_TOKEN=$root_token política de vault escrever web web.hcl
Crie um novo token de autenticação, associe-o à política da web
e, opcionalmente, inclua o parâmetro display-name
para dar a ele um nome amigável. Anote os valores de token
e token_accessor
; você os usará em comandos subsequentes:
user@pdp:~$ VAULT_TOKEN=$root_token vault token create -policy=web -display-name=webserver1 Valor da chave --- ----- token dcf75ffd-a245-860f-6960-dc9e834d3385 token_accessor 0c1d6181-7adf-7b42-27be-b70cfa264048
O servidor web NGINX usa esse token para recuperar as senhas SSL. A política da web
impede que o servidor web recupere segredos fora do caminho secret/webservers/* .
Declare a localização do servidor Vault remoto (aqui, http://pdp:8200 ) e, em seguida, verifique se a máquina do servidor web pode recuperar as senhas SSL usando o token:
usuário@web1:~$ export VAULT_ADDR=http://pdp:8200 usuário@web1:~$ VAULT_TOKEN=dcf75ffd-a245-860f-6960-dc9e834d3385 vault kv get -field=value secret/webservers/ssl_passwords password1 password2 ...
Como parte da configuração do PDP de exemplo no primeiro post , criamos um script de shell chamado connector.sh no host NGINX (máquina do servidor web). Aqui nós o modificamos para usar o Vault:
#!/bin/sh
# Uso: connector_v.sh
CONNECTOR=$1
CREDS=$2
[ -e $CONNECTOR ] && /bin/rm -f $CONNECTOR
mkfifo $CONNECTOR; chmod 600 $CONNECTOR
export VAULT_ADDR=http://pdp:8200
export VAULT_TOKEN=$CREDS
while true; do
vault kv get -field=value secret/webservers/ssl_passwords > $CONNECTOR
sleep 0.1 # condição de corrida, garante EOF
done
Execute o script como um processo em segundo plano, invocado da seguinte maneira:
root@web1:~# ./connector_v.sh /var/run/nginx/ssl_passwords \dcf75ffd-a245-860f-6960-dc9e834d3385 &
Teste o conector lendo o caminho do conector:
root@web1:~$ cat /var/run/nginx/ssl_passwords senha1 senha2 ...
Configure o NGINX para ler o arquivo ssl_passwords na inicialização e usar o conteúdo como senhas para descriptografar chaves privadas criptografadas. Você pode incluir a diretiva ssl_password_file
em um bloco de servidor
(como o criado para a configuração padrão no primeiro post) ou no contexto http
para aplicá-la a vários servidores virtuais:
arquivo_senha_ssl /var/run/nginx/senhas_ssl;
Verifique se o NGINX pode ler a senha e descriptografar as chaves SSL:
root@web1:~# nginx -t nginx: a sintaxe do arquivo de configuração /etc/nginx/nginx.conf está ok nginx: o teste do arquivo de configuração /etc/nginx/nginx.conf foi bem-sucedido
Você pode revogar facilmente o acesso se o servidor web for comprometido ou quando for desativado. Para fazer isso, você pode revogar diretamente o token de autenticação usado pelo servidor web:
user@pdp:~$ VAULT_TOKEN=$root_token revogação do token do cofre dcf75ffd-a245-860f-6960-dc9e834d3385
Os tokens do Vault são itens de dados confidenciais e muitos fluxos de trabalho do Vault não armazenam cópias de tokens emitidos para um cliente autenticado. Se uma cópia de um token vazar, um invasor poderá se passar pelo cliente.
Em vez disso, é comum gerenciar um token ativo usando seu acessador , que concede direitos limitados sobre o token e não pode ser usado para recuperar o valor do token. Em vez de armazenar tokens quando eles são emitidos, armazene seu acessador correspondente.
Se você precisar determinar o acessador para o token de autenticação de um servidor web, execute o comando vault
list
para recuperar a lista de acessadores e o comando vault
token
lookup
em cada acessador para encontrar aquele com o nome de exibição e a política relevantes:
user@pdp:~$ VAULT_TOKEN=$root_token lista de vault /auth/token/accessors Chaves ---- 83be5a73-9025-1221-cb70-4b0e8a3ba8df 0c1d6181-7adf-7b42-27be-b70cfa264048 f043b145-7a63-01db-ea85-9f22f413c55e user@pdp:~$ VAULT_TOKEN=$root_token pesquisa de token de vault -accessor 0c1d6181-7adf-7b42-27be-b70cfa264048 Valor da chave --- ----- ... nome-de-exibição webserver1 ... política web ...
Você pode então revogar o token usando seu acessador:
user@pdp:~$ VAULT_TOKEN=$root_token revogação do token do vault -accessor 0c1d6181-7adf-7b42-27be-b70cfa264048
O uso do Vault tem um perfil de segurança semelhante ao PDP de exemplo descrito no primeiro post . As chaves privadas SSL só podem ser obtidas se a senha correspondente for obtida e, para isso, um invasor precisa saber o valor de um token de autenticação atual.
O principal benefício de usar o Vault é automatizar e dimensionar o armazenamento secreto.
Nenhuma das soluções que abordamos até agora na série protege a chave privada quando um invasor obtém acesso root
ao servidor NGINX. Se um invasor puder acessar a memória de tempo de execução do NGINX ou gerar um despejo de núcleo, há técnicas bem conhecidas para escanear a memória do processo e localizar dados de chave privada.
Os módulos de segurança de hardware externo (HSMs) resolvem isso armazenando as chaves privadas SSL em hardware externo à prova de violação. Eles oferecem descriptografia como um serviço, e o NGINX acessa esse serviço sempre que precisa executar uma operação SSL que requer o key.
O servidor NGINX nunca vê os dados da chave privada SSL. Um invasor que obtém acesso root
no servidor não consegue obter a chave privada SSL, mas pode descriptografar dados sob demanda acessando o serviço de descriptografia HSM usando as credenciais NGINX.
O NGINX delega todas as operações de chave privada SSL para uma biblioteca de criptografia chamada OpenSSL. Dispositivos HSM de terceiros podem ser disponibilizados para o NGINX usando o mecanismo OpenSSL do fornecedor do HSM.
A configuração do NGINX é específica para cada HSM do fornecedor, mas geralmente segue um caminho simples:
Configure o NGINX para usar o mecanismo OpenSSL do fornecedor em vez do mecanismo de software padrão:
mecanismo ssl_certificate_key :motor-hsm-do-fornecedor:...;
Em vez de usar a chave privada real, configure o NGINX para usar a chave "falsa" fornecida pelo fornecedor. Esta chave contém um identificador que identifica a chave real no dispositivo HSM:
chave_certificado_ssl ssl/chave.privada.do.vendedor;
A chave também pode conter as credenciais para acessar o dispositivo HSM, ou as credenciais podem ser fornecidas usando configuração adicional específica do fornecedor.
(Opcional) Aplique qualquer ajuste desejado, como aumentar o número de processos de trabalho do NGINX, para maximizar o desempenho do NGINX e do HSM.
Para um exemplo de configuração do HSM, consulte a documentação do CloudHSM da Amazon .
HSMs externos são um método altamente seguro de armazenamento de chaves privadas SSL. Um invasor com acesso root
ao servidor NGINX consegue aproveitar as credenciais do NGINX para descriptografar dados arbitrários usando o HSM, mas não consegue obter a chave privada não criptografada. Um HSM torna significativamente mais difícil para um invasor personificar um site ou descriptografar dados arbitrários offline.
É essencial garantir que dados secretos, como a chave privada SSL, estejam totalmente protegidos porque as consequências da divulgação são muito sérias.
Para muitas organizações com processos de segurança apropriados, é suficiente armazenar a chave privada nos balanceadores de carga de front-end e então limitar e auditar todo o acesso a esses servidores (a configuração padrão descrita no primeiro post).
Para organizações que precisam implantar a configuração do NGINX com frequência, as medidas nesta postagem e na primeira podem ser usadas para limitar os usuários ou entidades que podem ver os dados da chave privada.
Na terceira postagem desta série, Usando o armazenamento de chave-valor do NGINX Plus para proteger chaves SSL efêmeras do HashiCorp Vault , explicamos como automatizar o provisionamento de chaves e certificados do Vault para o armazenamento de chave-valor do NGINX Plus, usando a API do NGINX Plus .
Observe novamente que nenhum desses métodos reduz a necessidade de proteger totalmente as instâncias do NGINX em execução contra acesso remoto ou manipulação de configuração.
Experimente o NGINX Plus você mesmo – comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso .
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."