Bastion host: 3 estratégias para ligar e acessar o porteiro

O porteiro (o bastion host) já funciona e o túnel SSH abre, mas deixá-lo ligado o dia inteiro custa dinheiro. Aqui estão três estratégias para ligar, desligar e conectar nele no dia a dia da empresa, e como escolher a sua, ou combinar duas.

Parto do porteiro já montado. A montagem (security groups, chave .pem e túnel) está em Acesso seguro ao RDS: bastion host e túnel SSH.

O cenário: o time acessa o banco pelo porteiro

O desenho é o do porteiro: o usuário chega pela internet ao bastion host (BH), dentro da VPC, e dele alcança o RDS.

Agora pense no cenário real: na sua empresa, um time acessa o servidor por esse porteiro. Em que horário essa gente acessa? De madrugada, à noite, o tempo todo ou só em horário comercial? No meu exemplo, das 9h às 18h.

A resposta decide a estratégia. Deixar o porteiro ligado o tempo todo pode não fazer sentido, porque envolve custo, e onde há custo vale ter uma estratégia inteligente para reduzi-lo ao máximo.

Estratégia 1: ligar e desligar o porteiro com Lambda

Se o time trabalha em horário comercial, automatize o ligar e o desligar do porteiro com o AWS Lambda, com uma função agendada (schedule). Dá para criar direto no Lambda ou usar o SAM, e a escolha é gosto do freguês. A EC2 liga e desliga sozinha nos horários que você definiu.

A função precisa das permissões de IAM para ligar e desligar a EC2.

Essa estratégia traz um problema. Quando você para a instância e liga de novo, o IP público dela muda, e o usuário, que precisa desse IP para conectar, passa a ter um endereço diferente a cada dia.

Há dois caminhos para isso:

• Elastic IP. Você configura para reassociá-lo ao porteiro sempre que a instância for ligada de novo, e o IP não muda. Em compensação, quando o Elastic IP não está associado a nenhuma EC2 ligada, a AWS cobra uma fração por hora, um valor pequeno. Se custo é problema para você, fique atento a isso.

Estratégia 2: ler o IP público na hora de conectar

Sem Elastic IP, o script que você entrega ao time descobre o IP do porteiro na hora de abrir o túnel. O caminho:

1. Crie um usuário no IAM e dê a ele uma policy com a permissão de describe instances, para recuperar informações da EC2.
2. Com o ID da instância do porteiro, o script recupera o IP público dela.
3. O shell script usa esse IP para abrir o túnel SSH.

Mesmo dinâmico, o IP é lido no instante em que o script roda, então o túnel aponta para o endereço certo.

Tem um benefício de segurança: o porteiro passa a ter um IP diferente a cada vez que liga. Se alguém na mesma rede que você conseguir a sua chave .pem e o endereço do porteiro, esse endereço muda, e isso é mais um requisito de segurança na sua realidade.

E tem o contra, porque sempre tem: passa a existir um usuário com credenciais de CLI e permissão para listar as informações das instâncias daquela região. Se isso não for problema para você, lembre que a permissão dele é só essa e que é um usuário do seu negócio.

Estratégia 3: start e stop pela CLI, sem Lambda

A terceira é mais permissiva e não usa Lambda. Não há ligar e desligar por horário: funciona em qualquer horário.

O usuário do IAM, que na estratégia 2 só tinha describe instances, ganha também a permissão de dar start e stop na EC2. A rotina do script, via CLI, passa a ser:

1. Ligar a EC2 pela CLI.
2. Esperar a instância ficar disponível.
3. Recuperar o IP público dela.
4. Abrir o túnel SSH com esse IP.

Quando terminar, uma rotina separada para a instância.

Essa estratégia dá mais trabalho e, dependendo do que você faz, pode nem fazer sentido montar. Para um acesso pontual, pode valer. Para um acesso controlado, com horário e tudo mais, a estratégia 1 combinada com a 2 pode ser a ideal para o seu negócio.

Qual escolher

• Time com horário fixo (estratégias 1 e 2 juntas). O Lambda liga e desliga o porteiro no horário combinado, e o script lê o IP público a cada conexão. O porteiro não fica ligado fora do expediente, você dispensa o Elastic IP e o endereço muda a cada vez que ele liga.
• Acesso pontual (estratégia 3). Sem horário, o script liga o porteiro quando o usuário precisa e uma rotina separada o para quando termina. Dá mais trabalho de montar, em troca de funcionar a qualquer hora.
• Só a estratégia 1. Funciona, com a ressalva do IP que muda: ou você usa Elastic IP e aceita o custo, ou passa para a estratégia 2.

Combinar uma ou duas estratégias é escolha sua: você tem o escopo para aplicar ao seu negócio.

Checklist

• Descubra em que horários o seu time acessa o banco pelo porteiro.
• Se for horário fixo, crie uma função Lambda agendada para ligar e desligar a EC2, com permissão no IAM para isso.
• Decida entre Elastic IP, que tem custo por hora quando não está associado a uma EC2 ligada (e, desde fevereiro de 2024, todo IPv4 público é cobrado), e IP dinâmico.
• Para o IP dinâmico, crie um usuário no IAM com a permissão de describe instances e faça o script recuperar o IP público pelo ID da instância.
• Para acesso pontual, acrescente a esse usuário a permissão de start e stop e escreva uma rotina que liga, espera, lê o IP e abre o túnel.
• Tenha uma rotina separada para parar a instância quando o acesso terminar.
• Não deixe o porteiro ligado o tempo todo sem necessidade: isso é custo.

Escolha a estratégia pelo horário do seu time: o porteiro só precisa estar ligado quando alguém vai usá-lo.