Lançar uma instância a partir de uma AMI é, na prática, executar na sua conta software empacotado por outra pessoa. Se a imagem contiver malware, mineradores de criptomoedas, chaves embutidas ou simplesmente pacotes sem patches, esse risco entra diretamente na sua infraestrutura. Há casos documentados de imagens públicas maliciosas concebidas precisamente para isso.
A solução não é a paranoia, mas um processo de verificação repetível. Escolher bem uma AMI parece-se com contratar alguém: verifica identidade, referências e estado antes de lhe dar as chaves.
Os cinco pilares de uma AMI de confiança
Avalie cada imagem candidata segundo estes cinco eixos. Se falhar em vários, procure outra.
1. Proveniência: quem a publica?
- Verifique o owner ID da conta que publica a imagem; desconfie de proprietários anónimos ou desconhecidos.
- Prefira imagens de fornecedores oficiais, parceiros verificados ou editores com reputação demonstrável.
- Confirme que o nome e a descrição coincidem com uma origem legítima: cuidado com as imitações por typosquatting.
2. Segurança: o que leva dentro?
- Está endurecida (CIS ou hardening equivalente) ou é uma base desprotegida?
- Os snapshots estão cifrados?
- Analise-a você mesmo antes da produção com Inspector, Trivy ou similar para detetar CVE e segredos.
- Verifique que não tem chaves SSH autorizadas desconhecidas nem utilizadores a mais.
3. Manutenção: está viva?
- Com que frequência é atualizada? Uma imagem sem novas versões há um ano é um sinal de alarme.
- O editor informa dos CVE corrigidos em cada versão?
- Existe documentação clara do que contém e de como se configura?
4. Compatibilidade: serve para o seu caso?
- Arquitetura correta (x86_64 face a ARM/Graviton) e tipo de virtualização.
- Região disponível e possibilidade de a copiar para a sua.
- Suporte do tipo de instância de que precisa e compatibilidade com a sua automação.
5. Custo e licença: o que paga e sob que termos?
- Modelo de custo: gratuita, à hora ou BYOL.
- Licença do software incluído e as suas obrigações.
- Custo dos snapshots e do armazenamento associado.
Checklist rápida de verificação
| Verificação | Bom sinal | Sinal de alarme |
|---|---|---|
| Proprietário | Owner verificado e conhecido | Conta anónima ou acabada de criar |
| Cifragem | Snapshots cifrados | Sem cifragem |
| Atualização | Versões recentes e frequentes | Sem alterações há mais de 12 meses |
| Documentação | Notas de versão e CVE | Nula ou inexistente |
| Análise própria | Sem CVE críticos nem segredos | Vulnerabilidades ou chaves embutidas |
| Custo | Modelo claro e previsível | Custos ocultos de armazenamento |
Verifique cada ponto antes de levar uma AMI a produção.
Boa prática: recozer sobre aquilo que recebe
Mesmo uma imagem de confiança envelhece. A prática mais segura é pegar numa AMI base fiável e recozê-la na sua própria pipeline: aplica os seus patches, o seu hardening e a sua configuração, cifra-a com a sua chave e versiona-a. Assim herda o que a imagem de origem tem de bom e acrescenta o seu próprio controlo de qualidade e rastreabilidade.
Perguntas frequentes
É seguro usar uma AMI pública da comunidade?
Pode ser, mas tem de verificar proprietário, conteúdo e estado, e analisá-la antes de a usar. Para produção é preferível uma imagem de um editor de confiança, ou recozê-la você mesmo.
Como sei se uma AMI tem uma porta traseira?
Nenhum método é infalível, mas analisar a imagem, rever utilizadores e chaves autorizadas, inspecionar tarefas agendadas e observar o tráfego de rede numa instância de teste isolada reduz muito o risco.
Devo confiar mais em imagens pagas do que em gratuitas?
O preço não garante segurança, mas um editor que mantém e documenta as suas imagens —pagas ou não— costuma oferecer mais garantias do que uma imagem anónima abandonada.
Na imaxe.cloud construímos imagens com proveniência clara, cifragem e atualização contínua para que possa implantar com confiança.
