Como Compartilhar Chaves SSH e Certificados com Sua Equipe de Forma Segura

"Manda a chave SSH pelo Slack." Toda equipe de desenvolvimento ja ouviu isso. O acesso ao servidor e urgente, um novo membro precisa configurar seu ambiente, o deploy esta a minutos e alguem nao tem a chave.

Mas esse simples pedido pode ser o inicio de um incidente grave de seguranca.

Por Que Compartilhar Chaves SSH É Especialmente Perigoso

Chaves SSH nao sao como senhas comuns. Elas concedem acesso completo a um servidor.

Fator	Senha	Chave SSH
Escopo	Conta especifica	Servidor inteiro
Impacto se vazada	Aquela conta	Todos os dados no servidor
Facilidade de rotacao	Muda instantaneamente	Regenerar chave + atualizar todos os servidores
Suporte a 2FA	Disponivel	A chave em si e a autenticacao

Uma chave SSH vazada expoe cada arquivo, cada banco de dados, cada linha de codigo no servidor. Isso e fundamentalmente diferente de um vazamento de senha unica.

Quando Equipes Precisam Compartilhar Chaves SSH

De forma realista, existem razoes legitimas para compartilhamento:

• Acesso compartilhado a servidores: Servidores de staging ou producao que toda equipe precisa
• Deploy keys: Chaves usadas em pipelines de CI/CD
• Certificados SSL: Renovacao de certificados quando responsabilidades mudam
• Segredos de API: Credenciais de autenticacao para integracoes terceirizadas
• Credenciais de banco de dados: Resposta a incidentes emergenciais

Metodos Perigosos de Compartilhamento

1. DMs do Slack ou Discord

O historico do chat e permanentemente armazenado nos servidores. Qualquer pessoa pode buscar "ssh" ou "key" para encontrar chaves compartilhadas anteriormente. Ate contas de ex-funcionarios mantem o historico.

2. E-mail

Permanentemente arquivado em servidores de e-mail e incontrolavel uma vez encaminhado. Uma unica violacao do servidor de e-mail expoe todas as chaves ja enviadas.

3. Google Drive ou Notion Compartilhados

Controle de acesso granular e dificil. Quando arquivos sincronizam, copias locais permanecem nos dispositivos. Recuperar todas as copias quando alguem sai da equipe e praticamente impossivel.

4. Commit no Repositorio Git

O metodo mais perigoso. Chaves persistem para sempre no historico do Git. Mesmo arquivos deletados podem ser recuperados do historico. Se o repo for publico, a chave esta exposta globalmente.

Metodos Seguros de Compartilhamento

Metodo 1: Memo Secreto LOCK.PUB (Melhor para Transferencias Unicas)

A solucao mais pratica quando voce precisa transferir uma chave uma vez.

1. Crie um memo secreto no LOCK.PUB
2. Cole o conteudo da chave SSH ou certificado
3. Defina uma senha forte
4. Defina a expiracao mais curta possivel (1-4 horas)
5. Envie o link pelo Slack, compartilhe a senha por telefone
6. Apos o destinatario salvar a chave localmente, o link expira

Beneficios:

• A chave nao fica armazenada em texto simples em nenhum servidor persistente
• Inacessivel apos a expiracao
• Sem texto simples da chave no historico de chat

Metodo 2: Gerenciadores de Segredos (Para Equipes Maiores)

Use ferramentas dedicadas como HashiCorp Vault, AWS Secrets Manager ou Google Secret Manager.

• Controle de acesso e logs de auditoria incluidos
• Rotacao automatica de chaves possivel
• Custo e complexidade de configuracao sao desvantagens

Metodo 3: Autoridade Certificadora SSH (Solucao de Longo Prazo)

Em vez de chaves compartilhadas, execute uma CA SSH que emite certificados individuais para cada usuario.

• Elimina a necessidade de compartilhamento de chaves
• Gerenciamento de acesso por usuario
• Custo inicial de configuracao mais alto

Metodo 4: Chaves Por Usuario (Mais Recomendado)

Quando possivel, emita chaves individuais em vez de compartilhar uma chave por toda a equipe.

Principio: Chave compartilhada < Chaves individuais
Chave compartilhada vazada → Toda equipe afetada
Chave individual vazada → Apenas aquele usuario afetado

Checklist Para Quando o Compartilhamento É Necessario

Se chaves por usuario nao sao uma opcao e o compartilhamento e inevitavel, siga este checklist.

Antes da Transferencia

• Voce definiu o escopo minimo de permissao para a chave?
• Uma chave somente leitura seria suficiente?
• Voce pode aplicar restricoes de IP?

Durante a Transferencia

• Voce esta enviando a chave e a senha por canais diferentes?
• Voce definiu a expiracao mais curta pratica?
• O remetente pode deletar o original apos o destinatario confirmar?

Apos a Transferencia

• Confirme que o destinatario armazenou a chave de forma segura
• Verifique que o link/memo compartilhado expirou
• Monitore logs de uso da chave

Agenda de Rotacao de Chaves

A rotacao regular limita a janela de validade de qualquer chave comprometida.

Tipo de Chave	Rotacao Recomendada
Chaves de servidor de producao	90 dias
Deploy keys	90 dias
Certificados SSL	A cada renovacao
Segredos de API	90 dias
Chaves de desenvolvimento/staging	180 dias

Checklist de Seguranca para Equipes DevOps

• Chaves SSH individuais sao usadas para todos os servidores?
• Se chaves compartilhadas existem, restricoes de IP estao configuradas?
• Chaves de funcionarios que sairam sao imediatamente desativadas?
• Uma agenda de rotacao de chaves esta em vigor?
• Chaves SSH ja foram commitadas em um repositorio Git?
• Alguma chave esta armazenada em texto simples no historico de chat?
• Um canal com expiracao e usado para transferencias de segredos?

Resumo

Chaves SSH e certificados sao a espinha dorsal da seguranca de servidores. Envia-los por DM do Slack ou e-mail e como fixar a chave da sua casa em um mural publico. Emita chaves por usuario quando possivel. Quando o compartilhamento for inevitavel, use um memo secreto com a menor expiracao possivel.

Crie um memo secreto agora para transferir chaves SSH de forma segura.

Criar um Memo Secreto