Como gerenciar uma proteção de chave privada SSL de servidores da Web (senha vs. sem senha)?

Question

Temos uma discussão no grupo de segurança da minha empresa sobre qual é o pior das seguintes opções para gerenciar a chave privada SSL.

O servidor da Web precisa de acesso à chave privada para a operação de criptografia. Este arquivo deve ser protegido contra acesso não autorizado. Ao mesmo tempo, o servidor deve iniciar automaticamente, sem intervenção humana (se for seguro o suficiente).

Estamos discutindo três opções:

1. Proteja a chave com perms do sistema de arquivos.

2. Use uma chave protegida por senha e insira a chave manualmente em cada reinicialização.

3. Use uma chave protegida por senha e armazene a chave no sistema de arquivos para automatizar a reinicialização.

Nossas preocupações são as seguintes:

1. Com a opção 1, as reinicializações são automáticas, mas um compromisso pode copiar a chave privada e, como não está protegido, pode ser usado para decifrar a comunicação ou representar nossos servidores.

2. A opção 2 parece ser a mais segura, mas precisa de intervenção humana e administradores de sistemas se isso acontecer fora do horário comercial. Além disso, a senha deve ser compartilhada com vários sysadmins e você sabe que um segredo compartilhado não é mais um segredo.

3. A opção 3 tem o melhor das duas opções anteriores, mas se alguém tiver acesso à chave também poderá ter acesso à senha :(, para que não pareça tão seguro.

Como você gerencia a segurança das chaves privadas de seus servidores? Existe alguma outra opção (mais segura)?

    

Answer 1

A opção 1 é o padrão aceito.

No entanto, se você realmente quer segurança extra, por que você não tem um servidor seguro (não em seu DMZ) configurado para monitorar seu servidor web, e se o apache ficar inativo, ele pode se conectar remotamente automaticamente? e reinicie o apache , fornecendo a frase secreta.

Portanto, a frase secreta é mantida em um computador, mas não é a mesma em que o apache está sendo executado, e não na sua DMZ. Você ganha a segurança adicional de usar uma frase secreta e manter a capacidade de reinicialização automática.

    

Answer 2

Se alguém tiver acesso suficiente ao servidor para ler a chave, provavelmente terá acesso suficiente para anexar um depurador e obter a chave da memória.

A menos que você realmente goste de acordar no meio da noite para digitar senhas, vá para a opção 1. Quando você tem muitos servidores, você quer reinicializar automaticamente em caso de falha, e a opção 2 não permite isso. / p>     

Answer 3

Uma possibilidade de segurança mais alta que 1. mas menos tempo de inatividade que 2. é criar chaves privadas com validade curta e reciclá-las regularmente. Dessa forma, você pode armazená-los sem passphrase, mas reduzir a janela de vulnerabilidade.

Como você reconheceu, a opção 3. não oferece nenhuma segurança adicional acima de 1.

    

Answer 4

A prática determina que, em quase todas as situações, você acabará usando a opção (1). Perms do sistema de arquivos são a melhor maneira de ir na maioria dos cenários de segurança versus cenários práticos.

Em um sistema * nix, você pode restringir a chave privada apenas à raiz, pois a maioria dos bons servidores web (como o apache) iniciarão como root, mas farão o downgrade de privs para um usuário restrito quando tiverem as portas privilegiadas de que precisam (80, 443 etc).

Como você mencionou, a opção (3) é do ponto de vista da segurança igual à opção (1).