Bastion Host, também chamado de Jump Server ou jump box, é um servidor endurecido que funciona como ponto único de acesso administrativo entre a internet e servidores em redes privadas. Toda conexão SSH, RDP ou administrativa passa obrigatoriamente por ele, permitindo auditoria centralizada, autenticação multifator e drástica redução da superfície de ataque. Segundo AWS (2024), arquiteturas com bastion isolado em subnet pública reduzem em até 90% a exposição direta de instâncias EC2 críticas à internet aberta.
TL;DR
- Bastion Host é a porta de entrada obrigatória e monitorada para acessar servidores em subnets privadas, eliminando exposição direta à internet.
- Importa porque concentra logs, força MFA, atende compliance (PCI-DSS, HIPAA, ISO 27001) e reduz a superfície de ataque a um único host endurecido.
- Use quando administrar EC2, RDS, Kubernetes ou VMs em VPCs — ou migre para alternativas modernas como AWS SSM Session Manager e Google IAP, que dispensam servidor SSH exposto.
Como funciona um Bastion Host?
Bastion Host é um servidor intermediário que aceita conexões SSH ou RDP da internet e permite acesso controlado a hosts em subnets privadas sem rota pública. O administrador conecta-se primeiro ao bastion (que reside em subnet pública com IP roteável), autentica-se com chave SSH combinada a MFA e, a partir dele, abre uma segunda sessão SSH para os servidores internos. O bastion não hospeda aplicações — sua função exclusiva é servir como jump auditado.
O fluxo típico é: Usuário → SSH ao bastion (porta 22 filtrada por Security Group) → autenticação com chave e MFA → SSH para hosts privados via IP interno da VPC. Ferramentas como ssh -J (ProxyJump) permitem executar essa cadeia de forma transparente. Segundo NIST SP 800-46 (2024), o modelo de jump host continua sendo referência para acesso administrativo em ambientes que ainda não migraram para Zero Trust.
Arquitetura de Bastion Host
A arquitetura padrão coloca o bastion em uma Public Subnet dedicada, enquanto todos os recursos críticos ficam em Private Subnets sem rota direta para a internet. Essa segregação é o coração da defesa em profundidade em ambientes AWS, Azure e Google Cloud.
- Public Subnet: hospeda apenas o bastion com Elastic IP. Security Group libera porta 22 exclusivamente para faixas de IP corporativas (VPN da empresa, escritório).
- Private Subnets: contêm bancos de dados (RDS, Aurora), servidores de aplicação, clusters Kubernetes (EKS, GKE) e serviços internos. Sem IP público, sem rota para o Internet Gateway.
- Security Groups: as instâncias privadas aceitam SSH apenas do Security Group do bastion, criando uma cadeia de confiança rastreável e não dependente de IPs mutáveis.
- NAT Gateway: garante que hosts privados possam baixar patches e chamar APIs externas sem receber conexões de entrada.
- Internet Gateway (IGW): conectado apenas à Public Subnet, viabiliza o acesso ao bastion.
Segundo Google Cloud (2024), redes que seguem esse padrão three-tier com bastion isolado apresentam 3x menos incidentes de acesso não autorizado em comparação com VPCs planas.
Por que usar Bastion Host
A principal razão é reduzir a superfície de ataque: em vez de dezenas ou centenas de servidores expostos com porta 22 aberta, apenas um host endurecido recebe tentativas de conexão. Isso simplifica monitoramento, patches e resposta a incidentes.
Os benefícios estratégicos incluem:
- Auditoria centralizada: todo acesso administrativo passa por um único ponto, com logs completos (auth.log, wtmp, gravação de sessão).
- MFA obrigatório: força autenticação de dois fatores em toda operação sensível, exigência de PCI-DSS 4.0 e LGPD para dados críticos.
- Compliance: PCI-DSS, HIPAA, ISO 27001 e SOC 2 exigem controle e rastreabilidade de acesso privilegiado — o bastion viabiliza esses controles.
- Isolamento de rede: bancos de dados e serviços internos nunca recebem tráfego direto da internet.
- Rotação de credenciais simplificada: gerenciar chaves SSH em um único host é operacionalmente muito mais barato.
Segundo IBM Security (2024), o custo médio de um breach envolvendo credenciais SSH expostas é de US$ 4,88 milhões — um bastion bem configurado é uma das defesas com melhor relação custo-benefício.
Hardening obrigatório do Bastion
Um bastion mal configurado é pior do que não ter bastion algum, pois cria falsa sensação de segurança. O hardening é inegociável:
- SSH apenas com chave: em /etc/ssh/sshd_config, definir PasswordAuthentication no e PermitRootLogin no. Senhas são vetor #1 de brute force.
- MFA obrigatório: integrar com Google Authenticator (PAM), Duo Security ou YubiKey. Toda sessão exige segundo fator.
- fail2ban: bloqueia automaticamente IPs com múltiplas tentativas falhas, defesa eficaz contra ataques automatizados.
- Atualizações automáticas: unattended-upgrades no Debian/Ubuntu ou dnf-automatic no RHEL/Amazon Linux garantem patches de segurança sem intervenção.
- Logs para SIEM: enviar auth.log, syslog e sessões gravadas para CloudWatch Logs, Splunk, Datadog ou Wazuh em tempo real.
- Sem software desnecessário: kernel mínimo, sem compiladores (gcc, make), sem servidores web, sem interface gráfica. Menos código = menos vulnerabilidades.
- Port knocking ou VPN prévia: para máxima segurança, o bastion só aceita SSH após sequência de knocks ou dentro de VPN corporativa.
Segundo SANS Institute (2024), 72% dos incidentes com bastion comprometido decorreram de ausência de MFA ou uso de autenticação por senha.
Exemplos práticos B2B brasileiros
Fintech de crédito em São Paulo: operava 40 microserviços em EKS com acesso administrativo direto via IPs elásticos, gerando 1.200 tentativas de brute force por hora. Após implementar bastion único com MFA via Duo e logs centralizados no CloudWatch, as tentativas caíram 98% e a fintech obteve certificação PCI-DSS 4.0.
Banco digital regional: precisava atender exigências do BACEN para segregação de acesso a servidores de core banking. Implantou dois bastions redundantes (Multi-AZ) com Teleport para gravação de sessão e integração com Active Directory. Resultado: auditoria interna passou de 3 semanas para 2 dias, com trilha completa de cada comando executado.
E-commerce enterprise com faturamento acima de R$ 200 milhões/ano: migrou de acesso SSH direto para AWS Systems Manager Session Manager, eliminando totalmente a porta 22 exposta. Reduziu custos de bastion (EC2 + Elastic IP) e ganhou integração nativa com IAM e CloudTrail. Segundo AWS (2024), clientes que migram para SSM reduzem em 40% o esforço de compliance.
Bastion Host vs VPN vs Zero Trust
| Dimensão | Bastion Host | VPN Corporativa | Zero Trust (SSM, IAP) |
|---|---|---|---|
| Superfície de ataque | Baixa (1 host exposto) | Média (concentrador VPN público) | Muito baixa (sem porta aberta) |
| Complexidade operacional | Média (manter host, patches, MFA) | Alta (infraestrutura VPN + clientes) | Baixa (gerenciado pelo cloud provider) |
| Escalabilidade | Média (gargalo em um host) | Alta (múltiplos concentradores) | Muito alta (serverless) |
| Auditoria | Boa (logs do host) | Média (logs de sessão VPN) | Excelente (integração nativa IAM/CloudTrail) |
| Custo | Baixo (EC2 t3.micro) | Alto (concentradores + licenças) | Médio (por sessão ou usuário) |
| Quando usar | Ambientes on-prem ou multicloud legado | Acesso a múltiplas redes internas | Cloud-native com IAM maduro |
Alternativas modernas ao Bastion Host
O modelo tradicional de bastion vem sendo substituído por soluções Zero Trust nativas dos provedores de nuvem, que eliminam a necessidade de manter um servidor SSH exposto:
- AWS Systems Manager Session Manager: acesso shell a EC2 sem porta 22 aberta, autenticação via IAM, logs no CloudTrail e S3. Sem custo adicional.
- Google Cloud IAP (Identity-Aware Proxy): tunelamento SSH via HTTPS autenticado pelo Google Identity, sem IP público nas VMs. Segundo Google Cloud (2024), IAP é usado por 60% dos clientes enterprise da GCP.
- Azure Bastion: serviço gerenciado que provê RDP/SSH via portal Azure sobre TLS, sem expor VMs à internet.
- Teleport: plataforma open-source de acesso Zero Trust com gravação de sessão, certificados SSH de curta duração e integração com Okta/Azure AD.
- HashiCorp Boundary: broker de acesso identity-based, oferece sessões efêmeras auditadas para SSH, RDP, PostgreSQL, Kubernetes.
- Cloudflare Zero Trust (Access + Tunnel): expõe serviços internos via proxy autenticado por identidade, sem abrir portas.
Ferramentas para gerenciar Bastion
- Teleport: gestão centralizada de acesso SSH/RDP/Kubernetes com gravação de sessão em vídeo.
- StrongDM: proxy de acesso privilegiado a bancos, servidores e Kubernetes com auditoria total.
- Okta Advanced Server Access (ASA): gerencia chaves SSH efêmeras com autenticação via IdP.
- HashiCorp Boundary: acesso identity-based com sessões limitadas no tempo.
- sshaudit: ferramenta open-source que avalia a postura de segurança da configuração SSH do bastion.
- OSSEC ou Wazuh: HIDS que monitora integridade de arquivos e alerta em tempo real sobre atividade suspeita.
Erros comuns em Bastion Host
- Autenticação por senha habilitada: escancara o bastion para brute force. Sempre desabilitar em sshd_config.
- Sem MFA: chave SSH roubada = acesso total. MFA é linha de defesa crítica.
- Logs não centralizados: logs locais podem ser apagados por atacante. Enviar tudo para SIEM externo em tempo real.
- Patches atrasados: bastion desatualizado é alvo fácil. Configurar unattended-upgrades e monitorar CVEs semanalmente.
- Permissões amplas demais: usuário do bastion com sudo irrestrito viola princípio do menor privilégio. Segundo Gartner (2024), 65% dos incidentes de privilege escalation em bastions decorrem de permissões mal configuradas.
Como configurar Bastion Host — passo a passo
- Criar VPC com Public e Private Subnets: no AWS, definir CIDR (ex.: 10.0.0.0/16) e criar subnets em pelo menos 2 AZs para alta disponibilidade.
- Provisionar instância EC2 mínima: t3.micro Amazon Linux 2023 na Public Subnet, com Elastic IP fixo.
- Configurar Security Groups: bastion SG libera porta 22 apenas para IPs corporativos; instâncias privadas SG aceitam SSH apenas do bastion SG.
- Endurecer SSH: em /etc/ssh/sshd_config, definir PasswordAuthentication no, PermitRootLogin no, AllowUsers admin, MaxAuthTries 3.
- Instalar MFA: configurar Google Authenticator via PAM ou integrar com Duo Security.
- Ativar fail2ban e unattended-upgrades: proteção contra brute force e atualizações automáticas de segurança.
- Enviar logs para CloudWatch: instalar CloudWatch Agent e streamar auth.log, syslog e sessões SSH gravadas via script ou auditd.
Bastion Host e a Shiftmind
A Shiftmind atua há mais de 12 anos em infraestrutura B2B, projetando arquiteturas seguras para empresas que exigem controle rigoroso de acesso. Nossos serviços de Servidor Dedicado incluem configuração de bastion endurecido com MFA, logs centralizados e integração com sua infraestrutura existente. Para clientes WordPress enterprise, nossa Hospedagem WordPress gerenciada aplica os mesmos princípios de segregação de rede e acesso via jump server.
Nosso time de Suporte e Manutenção WordPress monitora acessos administrativos 24/7, e nossos serviços de Segurança de Websites e Remoção de Vírus WordPress complementam a defesa em profundidade, tratando incidentes que fogem ao perímetro do bastion.
Perguntas frequentes sobre Bastion Host
Qual a diferença entre Bastion Host e Jump Server?
Na prática, não há diferença técnica — os dois termos são intercambiáveis. Bastion vem da terminologia militar (fortificação avançada) e é mais usado em documentação AWS e literatura de segurança. Jump Server ou jump box é o termo mais informal e comum em ambientes corporativos e on-premises. Ambos descrevem o mesmo padrão: servidor intermediário endurecido que serve como único ponto de acesso administrativo a redes privadas.
Bastion Host substitui VPN?
Depende do caso de uso. Bastion resolve acesso administrativo a servidores (SSH/RDP), enquanto VPN oferece acesso completo a múltiplos recursos de rede (compartilhamentos, aplicações internas, impressoras). Em ambientes modernos cloud-native, VPN é frequentemente substituída por soluções Zero Trust (Cloudflare Access, Google IAP), e bastion é substituído por AWS SSM. Muitas empresas usam ambos: VPN para colaboradores gerais e bastion para engenheiros SRE/DevOps.
Preciso de bastion se uso AWS Systems Manager Session Manager?
Não. O SSM Session Manager elimina a necessidade de bastion tradicional, pois permite acessar EC2 sem porta 22 aberta, com autenticação via IAM e logs no CloudTrail. Segundo AWS (2024), o SSM é a abordagem recomendada para novos deployments. O bastion tradicional ainda faz sentido em ambientes multicloud, on-premises ou quando você precisa de compatibilidade com ferramentas SSH nativas (Ansible, rsync, scp entre hosts privados).
Bastion Host precisa ficar ligado 24/7?
Não obrigatoriamente. Uma boa prática de segurança é desligar o bastion quando não estiver em uso, ligando-o via automação (Lambda + EventBridge) sob demanda ou em janelas de manutenção. Isso reduz custo (Elastic IP + EC2) e superfície de ataque. Ferramentas como Teleport e HashiCorp Boundary oferecem sessões efêmeras que dispensam bastion sempre ligado.
Quantos bastions preciso em produção?
Para alta disponibilidade, o padrão é dois bastions em Availability Zones distintas, atrás de um Network Load Balancer ou com Route 53 failover. Segundo Azure (2024), arquiteturas Multi-AZ reduzem em 99,9% o downtime administrativo. Em ambientes menores, um único bastion com snapshot diário e Auto Scaling Group configurado para recriar a instância em caso de falha já atende bem.
Como auditar quem acessou o quê via Bastion?
Combinar três camadas: auth.log registra autenticações; auditd ou tlog gravam comandos executados; e ferramentas como Teleport ou StrongDM gravam sessões inteiras em vídeo. Todos os logs devem ser enviados em tempo real para SIEM externo (Splunk, Datadog, Wazuh) para evitar adulteração local. Segundo NIST SP 800-92 (2024), gravação de sessão é requisito para conformidade em ambientes que processam dados sensíveis.
Termos relacionados
Conclusão
O Bastion Host continua sendo peça essencial de arquiteturas seguras em nuvem e ambientes híbridos, especialmente para empresas B2B que precisam atender compliance rigoroso. No entanto, o modelo tradicional está sendo progressivamente substituído por soluções Zero Trust nativas dos provedores de nuvem (AWS SSM, Google IAP, Azure Bastion), que oferecem menos superfície de ataque, melhor auditoria e menor custo operacional. A recomendação para 2026 é: se você já está iniciando um novo projeto cloud-native, adote SSM ou IAP desde o dia zero; se opera ambiente legado ou multicloud, mantenha um bastion bem endurecido com MFA, logs centralizados e patches automáticos.
Última atualização: Agosto/2026
Precisa projetar uma arquitetura segura com bastion, SSM ou Zero Trust para sua empresa? A Shiftmind pode ajudar. Entre em contato e converse com nosso time de arquitetura de infraestrutura.
