Por que Hosts Bastion Aumentam o Risco

Para administrar servidores dentro de uma rede privada, as equipes tradicionalmente usavam um host bastion (também chamado de servidor de salto): uma instância reforçada e voltada para a Internet à qual você se conecta primeiro e, depois, usa para acessar as máquinas internas. Embora seja um padrão comum, ele amplia sua superfície de ataque de várias formas que a prova SCS-C02 espera que você reconheça e elimine.

Um host bastion fica em uma sub-rede pública com uma porta (geralmente 22 para SSH ou 3389 para RDP) aberta à Internet ou a um intervalo de IP corporativo. Os administradores se conectam a ele e, em seguida, acessam as instâncias privadas. Ele é a única porta de entrada protegida do ambiente, o que o torna essencial e um alvo prioritário.

O maior risco é a porta de entrada aberta. Qualquer porta SSH ou RDP acessível pela Internet é constantemente examinada e alvo de ataques de força bruta. Mesmo com autenticação baseada em chaves, uma porta exposta convida a ataques, e uma única configuração incorreta ou vulnerabilidade não corrigida no bastion pode dar aos invasores uma base de acesso à rede inteira.

O acesso ao bastion geralmente depende de pares de chaves SSH de longa duração distribuídos aos administradores. Essas chaves podem ser copiadas, perdidas ou permanecer nos computadores de ex-funcionários. Alterná-las em toda uma frota é trabalhoso, e raramente existe um registro claro de qual chave abriu qual sessão, prejudicando a responsabilização.

Rastrear quem fez o quê por meio de um bastion é difícil. O SSH nativo oferece pouco registro centralizado dos comandos executados nos hosts subsequentes. Investigar um incidente significa juntar registros dos hosts, e um bastion comprometido pode permitir que um invasor apague os próprios rastros — exatamente a lacuna de visibilidade apontada pelos auditores.

O próprio bastion é uma instância que você precisa corrigir e reforçar continuamente. Se ficar atrasado em relação às atualizações, ele se tornará o elo mais fraco. Manter um servidor de salto altamente disponível e sempre seguro gera uma sobrecarga operacional contínua, acrescentando custo e risco sem oferecer valor comercial.

Como todo o tráfego administrativo passa pelo bastion, ele é tanto um ponto único de falha quanto um alvo de alto valor. Se ele parar, os administradores perderão o acesso; se for comprometido, o invasor ganhará uma plataforma de lançamento. Concentrar o risco em um único host exposto é uma arquitetura que a prova quer que você evite.

O Systems Manager (SSM) da AWS elimina completamente a necessidade de bastions. Ele fornece acesso ao shell das instâncias por meio do serviço SSM, com nenhuma porta de entrada aberta, nenhum IP público e nenhuma chave SSH. O acesso é controlado pelo IAM e cada sessão é registrada, resolvendo de uma só vez todas as deficiências do modelo de bastion.

O SSM funciona porque a instância executa um SSM Agent que estabelece uma conexão de saída com o serviço SSM; nada é aberto para entrada. Os grupos de segurança podem negar todo o tráfego de entrada, e a administração continuará funcionando. Essa inversão — saída em vez de entrada — é o principal conceito que torna os bastions obsoletos.

Na prova, qualquer cenário que descreva portas SSH/RDP abertas, pares de chaves distribuídos ou um servidor de salto quase sempre tem uma resposta melhor: substitua o bastion pelo Session Manager. Isso reduz a superfície de ataque, centraliza o controle de acesso no IAM e produz uma trilha de auditoria completa — o design seguro e de privilégio mínimo recomendado pela AWS.

Um host bastion expõe uma porta de entrada, depende de chaves SSH permanentes, oferece auditoria insuficiente e precisa ser corrigido constantemente, tornando-se um alvo concentrado e atraente. A substituição recomendada é o SSM Session Manager, que concede acesso ao shell controlado pelo IAM e totalmente registrado, sem portas abertas, IP público ou chaves.

Teste por que os bastions são arriscados.

Um host bastion abre uma porta SSH/RDP de entrada, depende de chaves SSH de longa duração, oferece auditoria insuficiente e exige aplicação constante de correções, concentrando o risco em um único alvo exposto. O SSM Session Manager o substitui por acesso controlado pelo IAM e totalmente registrado, por meio de uma conexão de agente de saída, sem portas abertas, IP público ou chaves.