Credenciais SSH separadas para um acesso mais seguro à produção

Uma única credencial SSH que alcança desenvolvimento, staging e produção transforma uma pequena conveniência em uma ampla autoridade remota. Ela também torna as aprovações pouco honestas: alguém pode aprovar uma tarefa aparentemente inofensiva em staging, enquanto a mesma credencial pode abrir uma sessão de produção minutos depois.

Separe as credenciais SSH por classe de sistema e por risco. Depois, deixe essa divisão visível na configuração do cliente, aplique-a nos servidores e teste os caminhos negados com a mesma seriedade dos caminhos permitidos. Já vi equipes chamarem isso de controle de acesso quando apenas deram três nomes à mesma chave em ~/.ssh/config; isso não é um limite.

Uma credencial cria um único domínio de falha

Uma credencial compartilhada entre classes de ambiente dá a cada portador o privilégio combinado dessas classes. Se a estação de trabalho de um engenheiro, uma tarefa automatizada ou um fluxo de aprovação puder usá-la, o comprometimento desse único caminho alcançará o ambiente mais privilegiado que aceitar a chave pública.

A defesa comum é dizer que as mesmas pessoas administram todos os ambientes. Isso não atinge o ponto principal. As pessoas podem ser as mesmas, mas as situações não são. O trabalho de desenvolvimento costuma envolver scripts não revisados, dados de teste, máquinas temporárias e experimentação ampla. O trabalho de produção deve aceitar menos processos, exigir uma revisão mais cuidadosa e manter um registro claro de quem se conectou e por quê.

É também por isso que uma única credencial com aliases de host separados não ajuda. Estas entradas parecem organizadas:

Host dev-db
  HostName dev-db.internal

Host prod-db
  HostName prod-db.internal

Mas, se os dois hosts aceitarem a mesma chave pública SSH, qualquer um dos aliases poderá autenticar usando a mesma chave privada. Um erro em uma variável de automação ou um comando copiado poderá atravessar o limite sem uma nova decisão de autorização.

Credenciais separadas mudam o resultado. Uma credencial de desenvolvimento roubada deve falhar em staging e produção. Um processo aprovado para usar uma credencial de staging não deve ter material privado nem capacidade de assinatura que lhe permita autenticar na produção. São controles diferentes. O primeiro limita uma violação. O segundo impede que um processo legítimo, porém amplo demais, faça algo indevido.

Não confunda isso com rotação de senhas. A rotação substitui uma credencial ao longo do tempo. A segregação decide onde uma credencial pode funcionar. Você precisa das duas, mas a rotação não corrige uma credencial que foi deliberadamente aceita em todos os lugares.

Nomes de ambientes não são limites suficientes

Desenvolvimento, staging e produção são rótulos úteis apenas quando correspondem a decisões de confiança diferentes. Um host chamado staging pode conter dados semelhantes aos de produção, enviar e-mails reais, guardar um segredo de assinatura ou se conectar a um endpoint de pagamentos ativo. Da mesma forma, um host de monitoramento em produção pode precisar de menos autoridade que um administrador de banco de dados em staging.

Classifique o acesso SSH pelo efeito de uma sessão, não pelo prefixo do hostname. Normalmente começo com quatro perguntas:

• Essa conta pode ler dados de clientes ou dados regulados?
• Ela pode alterar um serviço ativo, uma implantação, um firewall ou um registro DNS?
• Ela pode obter outra credencial ou se passar por outro serviço?
• Ela pode avançar para sistemas com mais autoridade?

Se a resposta mudar entre os hosts, o escopo da credencial também deve mudar. Isso costuma produzir grupos mais úteis que o conhecido modelo de três ambientes: desenvolvimento de aplicações, sistemas de teste com dados sensíveis, hosts de release, diagnóstico somente leitura em produção e administração de produção.

Uma conta Unix separada também costuma fazer parte do desenho. Uma conta chamada deploy pode ser proprietária do diretório de release e aceitar um comando restrito. Uma conta chamada ops-read pode consultar logs sem editar unidades de serviço. Uma conta chamada admin pode realizar manutenção sob um padrão de aprovação mais alto. Contas separadas dão ao servidor um lugar para vincular permissões e dão aos logs um sujeito identificável.

Não deixe que nomes de contas diferentes façam você aceitar uma credencial compartilhada. Se a mesma chave pública aparecer em dev, deploy e admin em máquinas diferentes, a chave privada continuará sendo uma credencial entre ambientes. Contas separadas e credenciais separadas resolvem partes diferentes do problema.

Dê a cada pessoa e processo sua própria identidade

Cada operador humano e cada processo de automação precisa de uma identidade SSH distinta dentro da classe de ambiente permitida. Uma chave privada compartilhada pela equipe dificulta a resposta a incidentes, porque revogar o acesso de uma pessoa exige substituí-la para todos. Ela também torna os logs quase inúteis quando várias pessoas autenticam na mesma conta com a mesma chave pública.

Para um operador humano, crie chaves privadas separadas para os escopos permitidos. Use nomes que indiquem o escopo, não nomes vagos como id_ed25519_new ou server-key-final.

mkdir -p ~/.ssh/identities
chmod 700 ~/.ssh/identities

ssh-keygen -t ed25519 \
  -f ~/.ssh/identities/id_ed25519_dev_alex \
  -C dev-alex

ssh-keygen -t ed25519 \
  -f ~/.ssh/identities/id_ed25519_stage_alex \
  -C stage-alex

ssh-keygen -t ed25519 \
  -f ~/.ssh/identities/id_ed25519_prod_alex \
  -C prod-alex

O comentário ajuda as pessoas a inspecionar uma lista de chaves públicas, mas não impõe nada. O servidor decide o acesso com base na chave pública, na conta e nas regras de autorização. Trate os comentários como rótulos para operadores, não como metadados de segurança.

A automação merece a mesma disciplina. Um trabalho de release deve usar uma credencial emitida para esse trabalho e ambiente, não a identidade de produção de um engenheiro copiada para um gerenciador de segredos. Se vários trabalhos precisarem de acesso, dê identidades separadas a eles, a menos que tenham o mesmo responsável, o mesmo conjunto de destinos e a mesma autoridade de comando. Uma credencial deve responder a uma pergunta simples em uma revisão pós-incidente: qual processo usou isto?

Credenciais protegidas por hardware podem dificultar o roubo de um arquivo de chave privada, mas não corrigem um desenho de autorização amplo. Uma credencial protegida por hardware aceita em todos os ambientes ainda concede acesso a todos eles. Defina o escopo primeiro e depois escolha como proteger cada chave privada.

A configuração do cliente deve impedir o vazamento de identidades

O OpenSSH tentará usar as identidades da configuração e, quando não houver restrições, as identidades oferecidas por um agente SSH. Esse comportamento é conveniente até que um agente contenha uma identidade de produção e uma conexão destinada a staging seja bem-sucedida com ela.

O manual de ssh_config do OpenSSH descreve IdentitiesOnly como um controle que limita as identidades usadas na autenticação por chave pública aos arquivos de identidade e certificados configurados, mesmo quando o agente contém outras identidades. Defina essa opção para cada alias de host com escopo. Dê a cada alias um único arquivo de identidade explícito e não dependa da ordem em que o agente oferece as chaves.

Host dev-*
  User devops
  IdentityFile ~/.ssh/identities/id_ed25519_dev_alex
  IdentitiesOnly yes
  ForwardAgent no

Host stage-*
  User release
  IdentityFile ~/.ssh/identities/id_ed25519_stage_alex
  IdentitiesOnly yes
  ForwardAgent no

Host prod-*
  User admin
  IdentityFile ~/.ssh/identities/id_ed25519_prod_alex
  IdentitiesOnly yes
  ForwardAgent no

Use aliases que tornem o ambiente difícil de ignorar no histórico do terminal. Por exemplo, prod-api-01 é melhor que api-01 quando desenvolvimento e produção contêm hosts de API com nomes semelhantes. Não esconda o destino atrás de um alias genérico como server.

Confira a configuração final que o OpenSSH usará. Isso detecta conflitos entre curingas, arquivos incluídos e uma configuração global esquecida.

ssh -G prod-api-01 | grep -E '^(hostname|user|identityfile|identitiesonly|forwardagent) '

A saída deve ter este formato:

hostname prod-api-01.internal
user admin
identitiesonly yes
forwardagent no
identityfile ~/.ssh/identities/id_ed25519_prod_alex

O caminho pode ser expandido de forma diferente na sua máquina. O importante é que o alias de produção resolva apenas para a identidade de produção e que identitiesonly mostre yes.

Uma falha frequente aparece depois que alguém executa ssh-add por conveniência. O agente passa a conter várias identidades. Sem IdentitiesOnly yes, o cliente tenta usá-las contra um host até que uma funcione. Os servidores costumam limitar o número de tentativas de autenticação, o que causa falhas confusas. Pior: uma credencial ampla pode fazer a conexão funcionar silenciosamente, e o operador talvez nunca perceba que usou o escopo errado.

A autorização do servidor deve refletir a divisão

Chaves privadas separadas só funcionam quando cada servidor aceita a chave pública correspondente e rejeita as demais. Coloque a chave pública de desenvolvimento nos hosts de desenvolvimento, a chave pública de staging nos hosts de staging e a chave pública de produção apenas onde o acesso à produção for previsto.

A regra parece óbvia, mas o padrão ruim é comum em uma configuração urgente: alguém copia um arquivo inteiro de authorized_keys para um novo host. Esse arquivo costuma conter anos de identidades antigas, ex-prestadores, chaves de implantação e uma chave geral de administrador. O novo host de produção herda decisões de acesso que ninguém revisou.

Monte a lista de autorização de cada conta a partir do trabalho que ela executa. Para uma conta de implantação, use restrições do OpenSSH adequadas a uma transferência ou operação de implantação não interativa. O manual de authorized_keys do OpenSSH documenta a opção restrict, que desativa o encaminhamento de portas, o encaminhamento do agente, o encaminhamento X11 e a alocação de PTY, a menos que outra opção os permita. Uma entrada restrita de implantação pode ter esta aparência:

restrict,from="198.51.100.0/24" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... prod-release-job

Substitua a rede de exemplo por um intervalo de endereços que você realmente controle. Não adicione from= apenas porque parece rigoroso. Se o trabalho for executado de endereços variáveis ou de um pool de runners hospedados, uma restrição de origem incorreta causará uma interrupção e incentivará alguém a remover todas as restrições sob pressão.

Use comandos forçados apenas para automações bem definidas. Um comando forçado pode impedir que uma credencial de implantação obtenha um shell, mas também se torna um contrato de manutenção. O comando precisa validar a entrada, escolher os caminhos com segurança e registrar a solicitação. Não aplique um comando forçado a uma conta de administrador e suponha que ela esteja segura; em algum momento as pessoas precisarão de um shell e encontrarão uma forma de contornar a restrição.

Para a administração humana da produção, uma conta separada e uma chave pública separada costumam ser mais claras que opções elaboradas em authorized_keys. Restrinja a conta pelas permissões normais do host, registre sua atividade de sudo quando aplicável e remova a chave pública quando a pessoa não precisar mais do acesso.

Certificados SSH só ajudam quando suas declarações permanecem restritas

Os certificados OpenSSH podem facilitar a emissão operacional e a revogação de acessos de curta duração. Uma autoridade certificadora assina a chave pública de um usuário, e os servidores confiam na autoridade em vez de armazenar cada chave pública individual. Isso pode reduzir o trabalho de atualizar grandes frotas.

Eles não eliminam a necessidade de separar autoridades. Um certificado com um principal de produção não deve conceder também acesso a desenvolvimento e staging apenas porque um operador trabalha nos três ambientes. Emita certificados distintos, use principals diferentes ou empregue autoridades certificadoras separadas quando os limites administrativos e de risco justificarem isso.

O protocolo de certificados do OpenSSH diferencia certificados de usuário, principals, intervalos de validade e opções críticas. Essa estrutura só é útil se o servidor verificar os principals e se você mantiver as regras de emissão restritas. Um certificado válido para todas as contas em todos os hosts apenas transforma uma chave privada em uma identidade de portador amplamente confiável, com data de expiração.

Validades curtas ajudam com dispositivos perdidos e funcionários que deixam a empresa, mas não substituem a revogação durante um incidente ativo. Você ainda precisa de uma forma de interromper rapidamente a aceitação de uma identidade comprometida ou remover sua autorização. Planeje esse mecanismo antes de emitir certificados e teste-o em um host real.

Certificados também não resolvem o uso indevido do agente. Se um processo automatizado puder obter um certificado de produção sempre que solicitar, o serviço de emissão será o limite da produção. Proteja-o com o mesmo cuidado dedicado a uma chave privada de produção.

O encaminhamento do agente atravessa um limite que você não consegue ver

O encaminhamento do agente SSH permite que um host remoto peça ao seu agente local para assinar desafios de autenticação destinados a outros hosts. A máquina remota não recebe a chave privada, mas um processo executado como a conta remota pode usar o agente encaminhado enquanto sua sessão permanecer aberta.

Isso torna o encaminhamento especialmente perigoso para uma sessão de produção que primeiro chega a um jump host. Se o jump host for comprometido, ou se um processo não confiável for executado nessa conta, ele poderá solicitar assinaturas de todas as identidades oferecidas pelo agente encaminhado. O resultado pode ser um acesso lateral que nunca apareceu no plano original da conexão.

Mantenha este padrão na configuração do cliente:

Host *
  ForwardAgent no

Depois, crie uma única exceção explícita apenas onde um fluxo mantido realmente exigir isso. Antes de adicioná-la, pergunte se ProxyJump, uma credencial dedicada para bastion ou uma operação executada localmente eliminaria a necessidade. O ProxyJump transporta a conexão SSH por um host intermediário; ele não expõe seu agente local a esse host da mesma forma.

Não aceite a afirmação de que o encaminhamento é seguro porque a chave privada permanece no laptop. Um oráculo de assinatura pode ser suficiente para autenticar em outro lugar. A distinção importa durante um comprometimento: proteger um arquivo não é o mesmo que limitar o que pode usar a credencial.

O escopo da aprovação deve corresponder ao escopo da credencial

Uma aprovação que autoriza um novo processo a usar uma credencial SSH deve identificar o ambiente da credencial e o processo que solicitou o acesso. Um prompt que diga apenas ssh command requested pede que uma pessoa deduza informação demais a partir de informação de menos.

É aqui que as equipes costumam misturar dois controles. O escopo da credencial responde onde uma identidade pode autenticar. O escopo da aprovação responde qual processo em execução pode usar essa identidade. Você precisa dos dois. Credenciais de produção separadas impedem que um processo de desenvolvimento chegue acidentalmente à produção; a aprovação do processo impede que um processo local desconhecido use uma credencial de produção disponível.

A aprovação por comando parece mais segura, e muitas pessoas a pedem depois de um incidente desconfortável. Ela costuma falhar na manutenção rotineira, porque prompts repetidos treinam os operadores a aprovar sem ler. Reserve a confirmação por uso para credenciais cujo próprio uso exige uma decisão humana, como uma identidade administrativa de produção de alto impacto. Para o trabalho comum, dê uma autorização de sessão que termine quando o processo sair e mantenha estreito o escopo da credencial no servidor.

O Sallyport mantém credenciais SSH em seu cofre criptografado e pode exigir autorização para um novo processo do agente ou aprovação a cada uso de uma credencial selecionada. Isso não substitui a autorização separada no servidor, mas torna explícito o limite do processo sem entregar a credencial ao agente.

Um agente de programação de IA merece uma separação mais rigorosa que um terminal interativo, porque pode emitir muitos comandos rapidamente e seguir uma instrução incorreta. Dê acesso de desenvolvimento por padrão. Se precisar de staging, use uma identidade exclusiva de staging e uma execução aprovada separadamente. Trate o acesso à produção como uma operação distinta, com um destino identificado e uma finalidade restrita.

A falha geralmente começa com uma exceção aparentemente inofensiva

Considere uma equipe com uma única chave SSH ops aceita por hosts de desenvolvimento, staging e produção. Um engenheiro carrega essa chave em um agente SSH para uma janela de manutenção da produção. Mais tarde, um auxiliar local de compilação abre uma conexão SSH com um host de staging para coletar logs.

O auxiliar não tem uma configuração explícita de IdentityFile e IdentitiesOnly não está definido. O OpenSSH tenta as identidades do agente. A chave compartilhada ops funciona porque staging a aceita. O auxiliar agora tem uma sessão de staging autenticada com uma identidade que também funciona na produção.

Um segundo erro vem em seguida. O host de staging tem o encaminhamento do agente ativado porque alguém precisou de uma conexão pontual no mês anterior. Um processo nesse host pode solicitar assinaturas pelo agente encaminhado. Ele chega a um host de produção usando a mesma identidade ops. O engenheiro original aprovou uma sessão de manutenção de produção, mas um auxiliar sem relação e um host de staging herdaram sua autoridade.

Nenhum exploit exige uma chave privada vazada nessa sequência. O desenho permitiu uma identidade ampla, o cliente a selecionou de forma oportunista e o encaminhamento ampliou seu alcance. Os logs podem mostrar autenticação válida do início ao fim, e é por isso que as equipes classificam o problema como erro do usuário em vez de corrigir o modelo de acesso.

Um desenho separado interrompe a cadeia em vários pontos. O auxiliar usa apenas uma credencial de staging. A produção rejeita essa credencial. O encaminhamento do agente permanece desativado. A identidade de produção só fica disponível para um processo de produção explicitamente aprovado. Qualquer um desses controles ajuda; juntos, fazem a conexão errada falhar cedo.

A rotação e a revogação emergencial precisam de uma ordem praticada

A rotação funciona quando você adiciona uma substituta antes de remover a identidade antiga, verifica o caminho exato e então revoga a antiga. As rotações de produção falham quando alguém testa apenas do próprio laptop, enquanto o implantador real se conecta a partir de outra conta, rede ou runner de automação.

Para uma rotação normal, siga esta ordem:

1. Crie uma credencial substituta no mesmo escopo restrito da antiga.
2. Adicione a autorização da chave pública ou do certificado à conta e aos hosts previstos.
3. Teste o comando real pelo caminho real do processo, incluindo qualquer jump host.
4. Remova a autorização antiga e confirme que a credencial antiga agora falha.
5. Registre a impressão digital, o responsável, o escopo e a data de remoção da substituta no registro de acesso.

Mantenha um caminho de emergência, mas não o transforme em uma segunda credencial permanente de administrador copiada para todas as estações de trabalho. Armazene-a separadamente, limite quem pode ativá-la e teste-a em condições controladas. Um processo de emergência que ninguém praticou vira um exercício de adivinhação durante uma interrupção.

A revogação emergencial é diferente. Se houver possibilidade de exposição de uma credencial de produção, remova imediatamente sua chave pública ou pare de aceitar seu certificado e depois substitua-o. Não espere a janela de rotação programada, porque um invasor não respeitará seu calendário. O custo é a possível interrupção operacional, e é por isso que credenciais restritas são valiosas: revogar uma identidade de implantação da produção não deve interromper o trabalho de desenvolvimento.

Teste o acesso negado e leia as evidências

A separação de acesso só está completa quando a credencial errada falha de uma forma que você consegue explicar. Faça um teste negativo intencional após cada mudança significativa: use a identidade de desenvolvimento contra um host de produção e confirme que a autenticação por chave pública falha. Depois, teste a credencial esperada e confira o nome da conta e o destino no registro da conexão.

Use a saída detalhada do cliente durante os testes, não como hábito permanente:

ssh -vvv -o IdentitiesOnly=yes \
  -i ~/.ssh/identities/id_ed25519_dev_alex \
  [email protected]

Você deve ver o cliente oferecer a chave pública de desenvolvimento e o servidor recusá-la. Não cole essa saída em tickets sem conferi-la antes; logs detalhados do SSH podem revelar hostnames, nomes de usuário e detalhes de autenticação.

Os logs do servidor devem permitir responder quem autenticou, qual conta foi usada, qual impressão digital de chave pública o servidor aceitou e de onde a conexão se originou. Se várias pessoas ou processos compartilharem uma identidade, o log não poderá recuperar essa atribuição perdida depois.

Procure desvios dos limites: uma chave de desenvolvimento adicionada a uma conta de produção, uma credencial antiga de implantação ainda aceita, uma chave de produção carregada em um agente de uso geral ou uma regra curinga do cliente que sobrescreva IdentitiesOnly. Essas mudanças costumam chegar como correções temporárias. O acesso SSH temporário tende a sobreviver muito tempo depois da emergência que o criou.

Comece inventariando todas as chaves públicas aceitas nos hosts de produção e identificando cada uma por responsável, processo, finalidade e escopo. Qualquer entrada que não consiga passar por essa descrição em quatro partes não deve continuar autorizada.