Segurança no Amazon ECR: boas práticas para imagens de containers
O registry é o ponto onde a supply chain de containers vive ou morre. Veja como proteger imagens no ECR.
O Amazon ECR guarda as imagens de container que rodam nos seus ambientes, o que o torna um ponto central da supply chain. Uma imagem com vulnerabilidades conhecidas, uma tag mutável que muda sob seus pés ou um repositório com permissões amplas demais comprometem tudo o que roda a partir dali. Segurança no ECR é garantir procedência, integridade e atualização das imagens.
Este guia trata das boas práticas de segurança no ECR de forma defensiva: scan de vulnerabilidades, imutabilidade de tags, ciclo de vida, permissões e cuidados com a cadeia de suprimento. O objetivo é que cada imagem promovida para produção seja confiável e rastreável.
Scan de vulnerabilidades e CVEs
Ative o scan de imagens do ECR para identificar CVEs nos pacotes da imagem. O scan no push pega problemas cedo, e o scan contínuo reavalia imagens já armazenadas conforme novas vulnerabilidades surgem. Uma imagem que era segura há meses pode acumular CVEs sem nenhuma mudança no seu código; sem scan contínuo, você empacota vulnerabilidades em produção.
Scan básico e scan aprimorado
O ECR tem dois modos. O scan básico usa uma base de CVEs do sistema operacional e roda no push. O scan aprimorado é feito pelo Amazon Inspector, cobre também dependências de linguagem de programação, faz reavaliação contínua conforme novas CVEs aparecem e alimenta o Security Hub. Para produção, o scan aprimorado com reavaliação contínua costuma valer o custo, porque é o que enxerga a imagem envelhecer.
aws ecr put-image-scanning-configuration \
--repository-name minha-app \
--image-scanning-configuration scanOnPush=true
aws ecr put-image-tag-mutability \
--repository-name minha-app \
--image-tag-mutability IMMUTABLEDefina o que fazer com os achados: bloquear a promoção de imagens com vulnerabilidades críticas, priorizar correções e atualizar a base. O scan só agrega valor se houver um processo de tratamento, e não apenas um relatório ignorado.
Tags imutáveis e ciclo de vida
Tags mutáveis são uma armadilha de segurança: a mesma tag pode apontar para imagens diferentes ao longo do tempo, então o que você testou não é necessariamente o que roda. Habilite a imutabilidade de tags para que uma tag, uma vez publicada, sempre se refira à mesma imagem. Para builds reproduzíveis, referencie imagens por digest.
Use lifecycle policies para limpar imagens antigas e não utilizadas, reduzindo custo e a chance de alguém implantar uma versão obsoleta e vulnerável. Mantenha o que é necessário para rollback e expire o resto. A regra abaixo expira imagens sem tag depois de alguns dias, um alvo comum de acúmulo.
{
"rules": [
{
"rulePriority": 1,
"description": "Expira imagens sem tag apos 14 dias",
"selection": {
"tagStatus": "untagged",
"countType": "sinceImagePushed",
"countUnit": "days",
"countNumber": 14
},
"action": { "type": "expire" }
}
]
}- Habilitar scan no push e scan aprimorado contínuo
- Tratar achados, não apenas gerar relatório
- Habilitar imutabilidade de tags
- Referenciar imagens por digest em produção
- Definir lifecycle policy para expirar imagens antigas
Permissões e supply chain
Restrinja quem pode enviar e baixar imagens com políticas de repositório e IAM, aplicando menor privilégio. Cuidado redobrado com repositórios públicos, que expõem imagens a qualquer um e podem vazar conteúdo sensível embutido. Controle a procedência das base images, prefira fontes confiáveis e reconstrua imagens periodicamente para herdar correções da base.
A política de repositório restringe quem baixa a imagem. Concentrar o pull na role de deploy da carga certa, em vez de deixá-lo aberto na conta, reduz o alcance de uma credencial comprometida e evita que qualquer identidade da organização puxe imagens que não deveria.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PermitirPullSomenteDaRoleDeDeploy",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::CONTA:role/deploy-minha-app"
},
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage"
]
}
]
}Procedência: assinatura e verificação de imagens
Scan e imutabilidade dizem que a imagem tem poucas CVEs e que a tag não muda, mas não provam quem a construiu. A assinatura fecha essa lacuna: o pipeline assina cada imagem promovida, e o ambiente de execução só aceita imagens com assinatura válida de uma chave confiável. Assim, uma imagem injetada por fora do pipeline, mesmo com a tag esperada, é recusada na implantação.
Na prática, isso combina uma ferramenta de assinatura, como o AWS Signer com o Notation ou um assinador do ecossistema sigstore, com uma verificação no momento do deploy. Em Kubernetes, um controlador de admissão valida a assinatura antes de permitir que o pod suba; fora do Kubernetes, a verificação entra como etapa do próprio deploy. O ponto é que a confiança deixe de ser só a tag e passe a ser a assinatura.
Gate no pipeline: do build ao deploy
A governança de imagens só reduz risco de verdade quando vira uma barreira no caminho até produção. Encaixe as verificações como etapas obrigatórias do pipeline, e não como relatórios opcionais que ninguém lê.
- Rodar scan e falhar o build quando houver CVE crítica sem exceção aprovada
- Assinar a imagem aprovada e promovê-la por digest, não por tag móvel
- Bloquear no deploy imagens sem assinatura válida
- Registrar quem aprovou cada exceção de vulnerabilidade e por quanto tempo
- Reconstruir periodicamente para herdar correções da base image
Exceções vão existir, porque nem toda CVE crítica tem correção imediata. O que diferencia um processo saudável é a exceção ser consciente, com dono e prazo, em vez de um bloqueio que alguém desliga em silêncio na primeira vez que atrapalha.
Checklist prático
- Habilitar scan no push e scan aprimorado contínuo via Inspector
- Definir processo de tratamento dos achados de CVE
- Bloquear promoção de imagens com vulnerabilidades críticas
- Habilitar imutabilidade de tags
- Referenciar imagens por digest em produção
- Definir lifecycle policy para expirar imagens antigas
- Restringir push e pull com políticas de repositório e IAM
- Evitar repositórios públicos para imagens internas
- Assinar imagens promovidas e verificar a assinatura no deploy
- Registrar exceções de vulnerabilidade com dono e prazo
- Controlar a procedência das base images
- Reconstruir imagens periodicamente para herdar correções
Boas práticas
- Trate o registry como ponto crítico da supply chain
- Use scan aprimorado contínuo, porque CVEs surgem após o build
- Garanta imutabilidade para que o testado seja o que roda
- Aplique menor privilégio em push e pull
- Assine imagens e recuse no deploy o que não tem assinatura válida
- Controle base images e reconstrua para herdar correções
- Expire imagens antigas para reduzir risco e custo
Erros comuns
Tags mutáveis em produção
A mesma tag passa a apontar para imagens diferentes; o testado não é o que roda.
Confiar só na tag, sem verificar assinatura
Uma imagem injetada fora do pipeline com a tag esperada sobe sem barreira.
Pull aberto para toda a conta
Qualquer identidade comprometida baixa imagens internas que não deveria alcançar.
Scan só no push, sem reavaliação contínua
Imagens acumulam CVEs descobertas depois do build sem ninguém notar.
Repositório público com imagem interna
Conteúdo sensível embutido na imagem fica exposto a qualquer um.
Achados de scan ignorados
Vulnerabilidades conhecidas seguem para produção sem tratamento.
Sem lifecycle policy
Imagens obsoletas e vulneráveis permanecem disponíveis para deploy.
Quando procurar apoio especializado
Integrar scan, imutabilidade e governança de imagens ao pipeline é parte do serviço de Hardening da GUARDIASEC, que avalia a supply chain de containers e recomenda controles priorizados por risco.
Perguntas frequentes
O que é o Amazon ECR e qual o seu papel na segurança de containers?
O Amazon ECR (Elastic Container Registry) é o registro de imagens de container da AWS, onde as imagens são armazenadas e distribuídas para serviços como ECS e EKS. Ele é um ponto crítico da supply chain de containers: se uma imagem comprometida ou vulnerável é publicada ali, ela se espalha para todos os ambientes que a consomem. Por isso, scan de vulnerabilidades, tags imutáveis e permissões restritas no ECR são essenciais para garantir que só imagens confiáveis cheguem à produção.
Por que habilitar scan contínuo se já faço scan no push?
Porque novas vulnerabilidades são descobertas o tempo todo. Uma imagem aprovada no push pode acumular CVEs semanas depois, sem nenhuma mudança no seu código. O scan contínuo reavalia imagens já armazenadas contra as CVEs mais recentes, evitando que você rode em produção uma imagem que se tornou vulnerável após o build.
O que são tags imutáveis e por que importam?
Tags imutáveis garantem que uma tag, depois de publicada, sempre se refira à mesma imagem. Sem isso, a mesma tag pode apontar para imagens diferentes ao longo do tempo, então o que você testou pode não ser o que roda em produção. A imutabilidade traz previsibilidade e é base para builds reproduzíveis e rastreáveis.
Devo bloquear deploy de imagens com CVE crítica?
É uma boa prática integrar o resultado do scan ao pipeline e bloquear a promoção de imagens com vulnerabilidades críticas conhecidas, ou ao menos exigir aprovação consciente. O scan só agrega valor com um processo de tratamento; um relatório que ninguém aciona não reduz risco. O bloqueio força a correção antes da produção.
Repositório público no ECR é seguro?
Repositórios públicos têm uso legítimo para distribuir imagens abertas, mas são arriscados para imagens internas, que podem conter configuração ou segredos embutidos. Para conteúdo interno, use repositórios privados com permissões restritas. Antes de tornar algo público, verifique que a imagem não carrega dados sensíveis nas camadas.
Qual a diferença entre scan básico e scan aprimorado no ECR?
O scan básico verifica CVEs do sistema operacional da imagem e roda no push. O scan aprimorado é conduzido pelo Amazon Inspector, cobre também dependências de linguagem de programação, reavalia as imagens de forma contínua conforme novas CVEs surgem e envia os achados ao Security Hub. Para imagens de produção, o aprimorado com reavaliação contínua tende a compensar, porque é o que detecta a imagem se tornando vulnerável depois do build.
Por que assinar imagens se já faço scan e uso tags imutáveis?
Scan mede vulnerabilidades e a tag imutável garante que aquela tag não muda, mas nenhum dos dois prova quem construiu a imagem. A assinatura estabelece procedência: o ambiente de execução passa a aceitar apenas imagens assinadas por uma chave confiável, então uma imagem injetada por fora do pipeline é recusada no deploy mesmo carregando a tag esperada. É a camada que liga a confiança à origem, e não só ao nome.
Como referencio uma imagem por digest em vez de por tag?
O digest é o hash do conteúdo da imagem, no formato sha256, e identifica exatamente aquele artefato. Em vez de apontar o deploy para repositorio:app:producao, aponte para repositorio:app@sha256:HASH. Assim, o que foi testado e aprovado é literalmente o que roda, sem depender de uma tag que poderia, em um repositório sem imutabilidade, passar a apontar para outra imagem.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.