Table of Contents

Os recipientes Docker revolucionaram a implantação moderna de aplicativos, fornecendo ambientes leves, portáteis e eficientes para executar software. À medida que as organizações adotam cada vez mais a contêinerização para simplificar seus fluxos de trabalho de desenvolvimento e implantação, a segurança desses recipientes tornou-se uma preocupação crítica.Contêineres mal configurados e imagens expostas estão entre as principais causas de violações de dados na nuvem, e enquanto a Docker simplifica o desenvolvimento e a implantação, ela também expande a superfície de ataque.Este guia abrangente explora as melhores práticas essenciais, estratégias de design e medidas de segurança necessárias para implementar contêineres Docker seguros em ambientes de produção.

Compreender os fundamentos de segurança do recipiente Docker

A Docker tem seus próprios desafios de segurança, e garantir a segurança dos recipientes da Docker não é apenas uma questão de fortificar a aplicação, mas envolve uma abordagem abrangente que abrange todo o ecossistema. Antes de implementar medidas de segurança específicas, é essencial entender o modelo de segurança da Docker e como ele difere das abordagens tradicionais de virtualização.

Arquitetura de Segurança do Docker

A abordagem do Docker à segurança é distinta dos métodos tradicionais de virtualização, principalmente devido à sua dependência no kernel do sistema operacional host. O Docker aproveita os espaços de nomes do kernel para o isolamento do processo. Os espaços de nomes fornecem a primeira e mais simples forma de isolamento. Os processos em execução dentro de um recipiente não podem ver, e ainda menos afetar, processos em execução em outro recipiente, ou no sistema host.

Os recipientes docker são leves e portáteis. No entanto, eles compartilham o kernel do sistema operacional host. Esta arquitetura cria desafios de segurança únicos. Entender este modelo de kernel compartilhado é crucial porque vulnerabilidades no kernel host podem afetar todos os recipientes rodando nesse sistema.

Cada recipiente também tem sua própria pilha de rede, o que significa que um recipiente não obtém acesso privilegiado aos soquetes ou interfaces de outro recipiente. Claro, se o sistema host estiver configurado de acordo, os recipientes podem interagir entre si através de suas respectivas interfaces de rede – assim como eles podem interagir com hosts externos.

O Modelo de Responsabilidade Compartilhada

A segurança do Docker envolve oferecer recursos como Docker Compose, namespaces e Docker Content Trust (DCT) para melhorar a segurança, usando configurações seguras para o tempo de execução, redes e armazenamento de contêineres, digitalizar regularmente imagens de contêineres e abordar vulnerabilidades conhecidas, e monitorar atividades de execução e implementar controles de acesso baseados em funções (RBAC) para restringir o acesso não autorizado.

O fracasso de ambos os lados deste modelo de responsabilidade compartilhada pode deixar cargas de trabalho em contêiner expostas. Usuários que não endurecem seus ambientes ou mantêm seus componentes atualizados estão especialmente em risco de exploração.As organizações devem entender que o Docker fornece as ferramentas e plataforma, mas implementar medidas de segurança é da responsabilidade das equipes de desenvolvimento e operações.

Melhores práticas essenciais para proteger os recipientes Docker

A segurança do container não é uma única ferramenta ou uma auditoria única. É um conjunto de práticas em camadas em todo o seu pipeline — do arquivo Docker que você escreve, para o CI que o constrói, para o tempo de execução que o executa. A implementação de segurança abrangente requer atenção para várias camadas da pilha de contêiners.

Usar imagens mínimas e confiáveis de base

Construa sempre containers de imagens de base mínimas verificadas. As imagens oficiais e endurecidas são pontos de partida mais seguros. A escolha da imagem de base impacta significativamente a postura de segurança do seu container. Imagens maiores contêm mais pacotes, bibliotecas e vulnerabilidades potenciais que os atacantes poderiam explorar.

Alpine contém menos pacotes, o que reduz os CVEs e melhora os resultados de digitalização. Considere usar imagens distross ou o Linux Alpine como imagens base para minimizar a superfície de ataque. As imagens distross contêm apenas a sua aplicação e as suas dependências de tempo de execução, excluindo os gestores de pacotes, shells e outros utilitários que não são necessários para a produção.

A utilização de imagens oficiais do Docker é fundamental para manter a segurança, uma vez que estas imagens são regularmente atualizadas e remendadas por entidades confiáveis. Esta abordagem reduz significativamente o risco de implantar recipientes com vulnerabilidades existentes ou código malicioso. Verifique sempre a origem das suas imagens de base e prefira imagens oficiais do Docker Hub ou outros registros confiáveis.

Pin versões de imagem e evitar etiquetas mais recentes

Usando as últimas versões torna as builds imprevisíveis. Ele pode puxar uma versão atualizada que introduz mudanças ou vulnerabilidades de quebra sem aviso. Em vez de usar a tag latest, sempre afixa versões específicas de imagens de base usando as tags digest ou version.

Pinting versões de imagem garante reprodutibilidade e evita regressões de segurança inesperadas. Quando você especificar uma versão exata ou digerir, você garante que suas construções usarão a mesma imagem base todas as vezes, tornando mais fácil rastrear vulnerabilidades e gerenciar atualizações sistematicamente.

# Bad practice
FROM node:latest

# Good practice - pin specific version
FROM node:18.16.0-alpine

# Best practice - use digest for immutability
FROM node:18.16.0-alpine@sha256:a1e4e58...

Executar os Containers como Usuários Não- Root

É uma prática de melhor Dockerfile para evitar correr os recipientes como root (UID 0). Existem muito poucos casos de uso onde o recipiente precisa ser executado como root, por isso não se esqueça de incluir a instrução USER para alterar o UID eficaz padrão. Executar os recipientes como root representa riscos de segurança significativos, porque se um atacante compromete o recipiente, eles ganham acesso root-level.

Executar como não root pode exigir algumas etapas adicionais no seu arquivo Docker, pois agora você precisará se certificar de que o usuário especificado na instrução USER existe dentro do recipiente e fornecer permissões adequadas do sistema de arquivos nos locais onde o processo será leitura ou escrita.

FROM alpine:3.18

# Create a non-root user
RUN addgroup -g 1000 appgroup &&
 adduser -D -u 1000 -G appgroup appuser

# Set ownership of application directories
RUN chown -R appuser:appgroup /app

# Switch to non-root user
USER appuser

WORKDIR /app
COPY --chown=appuser:appgroup . .

CMD ["./myapp"]

Além disso, o seu ambiente de execução pode bloquear os contentores que funcionam como root por omissão (ou seja, o Openshift requer restrições adicionais de contexto de segurança). Muitas distribuições do Kubernetes e plataformas de contentores aplicam políticas não root, tornando esta prática essencial para a compatibilidade.

Implementar sistemas de ficheiros apenas para leitura

Executar com o sistema de arquivos root somente leitura onde --read- only faz com que todo o sistema de arquivos container somente leitura e --tmpfs fornece diretórios em memória para as necessidades de execução. Esta medida de segurança impede que os atacantes modifiquem arquivos dentro do container, mesmo que eles ganhem acesso.

Este manifesto obriga a regra do sistema de ficheiros apenas para leitura. Lembre- se quando você faz um recipiente só para leitura, o aplicativo não pode mais gravar no disco. Se o seu aplicativo precisa de gravar ficheiros temporários (como logs ou cache), você deve montar um volume temporário.

docker run -d
 --read-only
 --tmpfs /tmp:rw,noexec,nosuid,size=64m
 --tmpfs /var/run:rw,noexec,nosuid,size=32m
 nginx:alpine

Para aplicações que requerem armazenamento persistente, use volumes nomeados para pastas específicas, mantendo o sistema de leitura de arquivos raiz somente. Esta abordagem fornece o acesso de gravação necessário, mantendo os limites de segurança.

Soltar as Capacidades Linux Desnecessárias

Capacidades transformam a dicotomia binária "root/non-root" em um sistema de controle de acesso de grãos finos. Processos (como servidores web) que só precisam se vincular em uma porta abaixo de 1024 não precisam ser executados como root: eles podem ser concedidos a capacidade net bind service em vez disso. E existem muitas outras capacidades, para quase todas as áreas específicas onde os privilégios root são geralmente necessários.

A melhor prática para os usuários seria remover todos os recursos, exceto aqueles explicitamente necessários para seus processos. Os recursos Linux são permissões de granulação fina que substituem o antigo binário root/non-root. O Docker dá aos contêineres um conjunto padrão que a maioria das aplicações não precisam.

docker run -d
 --cap-drop=ALL
 --cap-add=NET_BIND_SERVICE
 --security-opt=no-new-privileges:true
 myapp:latest

A bandeira no-new-privileges impede que processos ganhem privilégios adicionais através de binários setuid ou setgid, adicionando outra camada de proteção contra ataques de escalada de privilégios.

Estratégias avançadas de design de segurança

Grande parte desta sobrecarga pode ser evitada deslocando a segurança esquerda, enfrentando problemas potenciais o mais rapidamente possível em seu fluxo de trabalho de desenvolvimento. A implementação de segurança no início do ciclo de vida do desenvolvimento reduz os riscos e simplifica a remediação.

Implementar a digitalização de imagens do recipiente

A digitalização de vulnerabilidade de containers é essencial. Em um pipeline seguro, a digitalização de vulnerabilidade de Docker deve ser uma etapa obrigatória do seu processo CI/CD e qualquer imagem deve ser digitalizada e aprovada antes de entrar em estado "Running" nos clusters de produção.

Várias ferramentas poderosas estão disponíveis para digitalização de imagens Docker:

  • Trivy: Um scanner de vulnerabilidade tudo-em-um para imagens de containers, sistemas de arquivos e repositórios Git. É popular por sua simplicidade, velocidade e amplitude de cobertura, incluindo suporte para escaneamento de modelos de infraestrutura como Código (IaC) e dependências de aplicativos.
  • Docker Scout: Integrado ao Docker Desktop e ao Docker CLI. Ele fornece insights de vulnerabilidade, resumos CVE e links diretos para orientação de remediação.
  • Anchore Engine: Uma ferramenta de digitalização de imagens Docker de código aberto que inspeciona imagens de container para vulnerabilidades, problemas de configuração e violações de políticas. Permite a criação de políticas de segurança personalizadas.
  • Snyk Container: Um scanner de vulnerabilidade que se integra com pipelines CI/CD para detectar e corrigir automaticamente vulnerabilidades.
  • Clair: Verifica imagens de container para vulnerabilidades conhecidas listadas em bases de dados como o banco de dados Common Vulnerabilities and Exposures (CVE).

Antes de empurrar as imagens, você deve sempre digitalizá-las para encontrar vulnerabilidades. Ferramentas como o Trivy tornam isso simples. Trivy relata vulnerabilidades, sua gravidade e correções recomendadas.

# Scan an image with Trivy
trivy image myapp:latest

# Scan and fail on high/critical vulnerabilities
trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:latest

Gerar e manter contas de software de materiais (SBOM)

A SBOM fornece um inventário completo de tudo dentro do seu recipiente. Quando o próximo dia zero cair, você pode verificar instantaneamente se você é afetado. A EU Cyber Resilience Act (Setembro 2026) vai exigir a geração da SBOM para todos os softwares vendidos no mercado da UE – isso não é mais um bom negócio.

A Image Provenance documenta a origem e o histórico das imagens de contêiner para garantir a rastreabilidade e integridade. A SBOM Generation cria uma Lei de Materiais de Software (SBOM) para cada imagem, detalhando todos os componentes, bibliotecas e dependências para o gerenciamento de transparência e vulnerabilidade.

O Grype suporta a digitalização de contas de software de materiais (SBOMs). Um SBOM fornece um banco de dados de todos os metadados, componentes, bibliotecas e pacotes que compõem um recipiente. Ferramentas como o Syft podem gerar SBOMs automaticamente, que podem então ser digitalizadas para vulnerabilidades.

Habilitar a confiança no conteúdo do Docker e assinatura de imagem

O motor de acoplagem pode ser configurado para executar apenas imagens assinadas. O recurso de verificação de assinatura do conteúdo do acoplamento Trust é incorporado diretamente no binário dockerd. Isto garante que as imagens não foram adulteradas e vêm de fontes confiáveis.

Cosign v3 (atual: v3.0.5) padrão para verificação sem chave através da autoridade do certificado do Sigstore e registro de transparência. Isto é mais simples e seguro do que gerenciar chaves de assinatura você mesmo.

# Enable Docker Content Trust
export DOCKER_CONTENT_TRUST=1

# Sign an image with Cosign
cosign sign myregistry.io/myapp:v1.0.0

# Verify a signed image
cosign verify myregistry.io/myapp:v1.0.0

A assinatura de imagens fornece provas criptográficas de autenticidade e integridade, protegendo contra ataques de cadeia de suprimentos, onde atores maliciosos podem injetar imagens comprometidas em seu registro.

Implementar Segmentação e Isolamento da Rede

A segmentação de rede é uma estratégia crítica de defesa em profundidade que limita o raio de explosão de possíveis falhas de segurança. Ao isolar contêineres em redes separadas com base em sua função e nível de confiança, você pode evitar o movimento lateral pelos atacantes.

Criar redes personalizadas de Docker para diferentes níveis de aplicativos:

# Create isolated networks
docker network create --driver bridge frontend-net
docker network create --driver bridge backend-net
docker network create --driver bridge database-net

# Run containers on specific networks
docker run -d --name web --network frontend-net nginx:alpine
docker run -d --name api --network backend-net myapi:latest
docker run -d --name db --network database-net postgres:14

# Connect API to both frontend and backend networks
docker network connect frontend-net api

O Docker Engine 28 abordou um problema relacionado: portas de contêineres inéditas estão bloqueadas do acesso à LAN por padrão. Isto evita a exposição acidental de serviços que não deveriam ser acessíveis na rede.

Use as políticas de rede em ambientes Kubernetes para restringir ainda mais o tráfego entre os pods. Defina as regras de entrada e saída que explicitamente permitem apenas os caminhos de comunicação necessários.

Aplicar os Perfis de Segurança em Tempo de Execução

Os perfis de segurança em tempo de execução fornecem camadas adicionais de proteção restringindo o que os contêineres podem fazer durante a execução. Três mecanismos primários estão disponíveis:

Perfis Secomp

Seccomp (Secure Computing Mode) filtra as chamadas de sistema que os recipientes podem fazer ao kernel. Ao limitar as chamadas de sistema disponíveis, você reduz significativamente a superfície de ataque.

# Run container with custom seccomp profile
docker run --security-opt seccomp=/path/to/seccomp-profile.json myapp:latest

Perfil do AppArmor

Carregar o perfil AppArmor e executar o recipiente com o perfil AppArmor. AppArmor fornece controle de acesso obrigatório, restringindo as capacidades dos programas com perfis por programa.

# Load AppArmor profile
sudo apparmor_parser -r /etc/apparmor.d/docker-webapp

# Run container with AppArmor
docker run --security-opt apparmor=docker-webapp myapp:latest

Integração SELinux

A integração SELinux fornece uma camada adicional de segurança, impondo controles de acesso obrigatórios em contêineres e suas interações com o sistema host. As etiquetas SELinux fornecem controle de acesso de grãos finos para processos e recursos de contêineres.

Gestão de Segredos e Proteção de Dados Sensíveis

Segredos de codificação em imagens ou variáveis de ambiente é um dos erros mais comuns que os desenvolvedores fazem. Devemos armazenar e injetar segredos com segurança. Gerenciamento de segredos adequado é crucial para manter a segurança de aplicativos em container.

Nunca Incorpore Segredos em Imagens

Senhas, chaves de API e tokens nunca devem ser armazenados dentro da imagem, dentro das variáveis de ambiente expostas em logs ou nos repositórios do Git. Em vez disso, deve-se protegê-los como segredos do Docker, segredos do Kubernetes ou cofres externos (AWS Secrets Manager, HashiCorp Vault) devem ser usados.

Erros comuns para evitar:

  • Credenciais de codificação em Dockerfiles
  • Commit .env arquivos com segredos para controle de versão
  • Passando segredos como argumentos de compilação (eles permanecem na história da imagem)
  • Expor segredos em variáveis de ambiente visíveis em logs

Usar os Segredos do Acoplador para o Modo Enxame

O Docker oferece uma funcionalidade de segredos integrada para armazenamento encriptado. O Docker Swarm inclui o gerenciamento de segredos nativos que criptografa segredos em repouso e em trânsito.

# Create a secret
echo "my-db-password" | docker secret create db_password -

# Use secret in service
docker service create
 --name myapp
 --secret db_password
 myapp:latest

Dentro do recipiente, os segredos são montados como arquivos em /run/secrets/, tornando-os acessíveis apenas ao processo do recipiente sem expô-los em variáveis de ambiente ou logs.

Integrar soluções de gerenciamento de segredos externos

Hashicorp Vault: Uma ferramenta de gerenciamento centralizado de segredos que pode ser usada para armazenar e gerenciar segredos em ambientes de contêineres com segurança. Para ambientes de produção, especialmente em Kubernetes, considere usar soluções de gerenciamento de segredos dedicadas.

As opções populares incluem:

  • HashiCorp Vault: Fornece segredos dinâmicos, criptografia como serviço e registros de auditoria detalhados
  • AWS Secrets Manager: Integração nativa com serviços AWS e rotação automática
  • Azure Key Vault: Gestão centralizada de segredos para cargas de trabalho Azure
  • Google Secret Manager: Armazenamento seguro para chaves, senhas e certificados de API no GCP

Embora os Docker Secrets geralmente forneçam uma forma segura de gerenciar dados sensíveis em ambientes do Docker, esta abordagem não é recomendada para Kubernetes, onde os segredos são armazenados em texto simples por padrão. Em Kubernetes, considere usar medidas de segurança adicionais, como criptografia etc., ou ferramentas de terceiros.

Segurança e Manutenção do Sistema Host

Para proteger contra vulnerabilidades de fuga de container conhecidas como Vazões Vazões, que normalmente resultam em o atacante ganhar acesso root para o host, é vital manter o host e o Docker atualizados. Isto inclui atualizar regularmente o kernel do host, bem como o Docker Engine.

Manter os Sistemas Actualizados e Correccionados

Isto deve- se ao facto de os contentores partilharem o kernel da máquina. Se o kernel da máquina estiver vulnerável, os contentores também são vulneráveis. Por exemplo, a exploração da escalada do privilégio do kernel, a COUV Suja, executada dentro de um contentor bem isolado, resultaria ainda em acesso ao root num hospedeiro vulnerável.

Motores de execução de containers, como o Docker, frequentemente atualizam seu software com correções e recursos. Você pode mitigar vulnerabilidades aplicando as últimas atualizações.

Executar o docker puxar uma vez e esquecer isso significa enviar imagens com vulnerabilidades de meses. Automatize atualizações com o código de dados da imagem do recipiente do Bot Renovate — ele cria RPs quando as imagens de base têm atualizações, pares com o seu pipeline de digitalização de CI para remediação automática.

Acesso seguro ao host e autenticação

Toda a autenticação diretamente para o sistema operacional deve ser auditada e registrada. Você só deve conceder acesso aos usuários apropriados e usar chaves para logins remotos. E você deve implementar firewalls e permitir o acesso apenas em redes confiáveis.

As melhores práticas para a segurança do anfitrião incluem:

  • Desactivar a autenticação de senha para o SSH, usar apenas a autenticação baseada em chaves
  • Implementar autenticação multifatorial para acesso privilegiado
  • Usar máquinas de bastião ou servidores de salto para acessar sistemas de produção
  • Activar o registo de auditoria para todas as acções administrativas
  • Restrinja o acesso de 'socket' do Docker apenas aos usuários autorizados

Nunca Expor o 'Socket' de Daemon do Acoplamento

Esta é uma prática ruim que você deve evitar porque um atacante seria capaz de executar qualquer comando que o serviço Docker possa executar e potencialmente obter acesso a todo o sistema host porque o serviço Docker é executado como root.

Montar o soquete Docker (/var/run/docker.sock) dentro de um recipiente dá àquele recipiente controle total sobre o daemon Docker, efetivamente concedendo acesso root ao host. Se você deve fornecer acesso do Docker a recipientes, considere alternativas como:

  • Usando Docker-in-Docker (DinD) com isolamento adequado
  • A implementar o modo 'Docker' sem raiz
  • Usando APIs de tempo de execução de container com permissões restritas
  • Aproveitando o Kubernetes CRI em vez de acesso direto ao Docker

Executar a Acoplagem no Modo Sem Raiz

O Docker sem raiz permite executar o servidor de Docker e os recipientes como um usuário não- root, reduzindo significativamente o impacto das potenciais vulnerabilidades de quebra de container. Este modo elimina a necessidade de privilégios de root no sistema host.

# Install rootless Docker
dockerd-rootless-setuptool.sh install

# Run Docker commands as non-root user
docker run -d nginx:alpine

Embora o modo sem raiz forneça segurança aprimorada, ele tem algumas limitações, como recursos de rede restritos e considerações de desempenho. Avaliar se esses trade-offs são aceitáveis para o seu caso de uso.

Monitoramento e detecção de segurança em tempo de execução

Segurança estática pega problemas antes da implantação. Segurança em tempo de execução pega o que acontece depois. Mesmo que as imagens sejam seguras, os contêineres ainda podem ser atacados em tempo de execução. A implementação de monitoramento de segurança em tempo de execução é essencial para detectar e responder a ameaças em ambientes de produção.

Instalar as ferramentas de segurança em tempo de execução

Falco 0.43.0 (janeiro de 2026) — Detecta chamadas de sys anômalas, acesso a arquivos e conexões de rede. A nova iniciativa drop-enter removeu a chamada de sys, introduzindo eventos do gasoduto, melhorando significativamente o desempenho. A sonda legado eBPF está desprecada em favor do moderno driver eBPF.

Falco é uma ferramenta de segurança em tempo de execução de código aberto que usa o eBPF para monitorar o comportamento do contêiner e detectar atividades suspeitas.

  • Execução do processo inesperada
  • Modificações de ficheiro não autorizadas
  • Conexões de rede suspeitas
  • Tentativas de escalada do privilégio
  • Desossagem de conchas em recipientes
# Example Falco rule for detecting shell in container
- rule: Shell Spawned in Container
 desc: Detect shell process started in container
 condition: >
 spawned_process and
 container and
 proc.name in (bash, sh, zsh)
 output: >
 Shell spawned in container (user=%user.name container=%container.name
 shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
 priority: WARNING

Implementar o registro e monitoramento abrangentes

Eventos de Docker fornecem fluxo de auditoria nativo para o ciclo de vida do contêiner, Prometheus + cAdvisor track use station tracking per container. Execução de processo inesperada, conexões de rede ou modificações de arquivos disparam alertas imediatos.

Estabelecer uma estratégia de registro abrangente que capture:

  • [[FLT: 0]] Registos de conteúdo : Saída de aplicação e mensagens de erro
  • Registros de daemon de Docker : Eventos de ciclo de vida do Container e operações de daemon
  • Registos de sistemas de host : Mensagens de Kernel e eventos de sistema
  • Registros de auditoria: Eventos relevantes para a segurança e tentativas de acesso

Centralize os logs usando ferramentas como a pilha ELK (Elastsearch, Logstash, Kibana), Loki com Grafana ou soluções nativas de nuvem como AWS CloudWatch ou Azure Monitor. O registro centralizado permite a correlação de eventos entre vários recipientes e hosts, facilitando a detecção de ataques distribuídos.

# Configure Docker to use JSON file logging driver with rotation
{
 "log-driver": "json-file",
 "log-opts": {
 "max-size": "10m",
 "max-file": "3",
 "labels": "production_status",
 "env": "os,customer"
 }
}

Definir os limites dos recursos para evitar ataques do S.S.

Os limites de recursos impedem a negação de ataques de serviço e a exaustão de recursos. Sem restrições de recursos adequadas, um recipiente comprometido ou mal comportado poderia consumir todos os recursos do sistema disponíveis, afetando outros recipientes e o hospedeiro.

# Docker Compose with resource limits
version: "3.9"
services:
 app:
 image: myapp:latest
 deploy:
 resources:
 limits:
 cpus: "2.0"
 memory: 512M
 pids: 100
 reservations:
 cpus: "0.5"
 memory: 256M
 ulimits:
 nofile:
 soft: 65536
 hard: 65536
 nproc:
 soft: 100
 hard: 200

Os limites de recursos devem ser estabelecidos com base nos requisitos de aplicação e no planejamento de capacidade. Monitore o uso real de recursos para ajustar esses limites adequadamente, garantindo que os recipientes tenham recursos suficientes, evitando ataques de exaustão de recursos.

Integração CI/CD de segurança de tubulação

Os pipelines CI/CD são uma parte crucial do ciclo de vida do desenvolvimento de software e devem incluir várias verificações de segurança, tais como verificações de fiapos, análise estática de código e digitalização de containers. Muitos problemas podem ser evitados seguindo algumas boas práticas ao escrever o Dockerfile. No entanto, adicionar uma linter de segurança como um passo no pipeline de construção pode ir um longo caminho para evitar novas dores de cabeça.

Implementar o Engate do Dockerfile

Os linters dockerfile analisam seus arquivos Docker para erros comuns, problemas de segurança e violações de melhores práticas antes de imagens serem construídas. Ferramentas como o Hadolint podem detectar problemas no início do processo de desenvolvimento.

# Run Hadolint on Dockerfile
docker run --rm -i hadolint/hadolint < Dockerfile

# Example output showing issues
DL3008: Pin versions in apt get install
DL3009: Delete the apt-get lists after installing
DL3015: Avoid additional packages by specifying --no-install-recommends

Automatizar a verificação de segurança em CI/CD

As ferramentas de digitalização de containers são especialmente importantes como parte de uma estratégia de segurança bem sucedida. Eles podem detectar vulnerabilidades, segredos e configurações erradas conhecidas em imagens de containers e fornecer um relatório das descobertas com recomendações sobre como corrigi-las.

Integrar o Docker Scout no seu pipeline CI/CD permite verificar automaticamente que as imagens construídas a partir do Docker Hardened Images permanecem livres de vulnerabilidades conhecidas durante o processo de compilação. Esta abordagem proativa garante a integridade de segurança contínua das suas imagens durante todo o ciclo de vida do desenvolvimento.

# GitHub Actions workflow example
name: Container Security Scan

on:
 push:
 branches: [ main ]
 pull_request:
 branches: [ main ]

jobs:
 security-scan:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3

 - name: Build image
 run: docker build -t myapp:${{ github.sha }} .

 - name: Run Trivy vulnerability scanner
 uses: aquasecurity/trivy-action@master
 with:
 image-ref: myapp:${{ github.sha }}
 format: 'sarif'
 output: 'trivy-results.sarif'
 severity: 'CRITICAL,HIGH'
 exit-code: '1'

 - name: Upload Trivy results to GitHub Security
 uses: github/codeql-action/upload-sarif@v2
 if: always()
 with:
 sarif_file: 'trivy-results.sarif'

 - name: Push image if scan passes
 if: success()
 run: |
 docker tag myapp:${{ github.sha }} myregistry.io/myapp:latest
 docker push myregistry.io/myapp:latest

Aplicação da aplicação da política

A aplicação de políticas garante que apenas imagens compatíveis sejam implantadas na produção. Ferramentas como Open Policy Agent (OPA) e Kyverno podem impor políticas organizacionais automaticamente.

As políticas comuns a aplicar incluem:

  • As imagens devem ser digitalizadas e não ter vulnerabilidades críticas
  • As imagens devem ser assinadas por autoridades de confiança
  • Os contentores devem ser executados como utilizadores não- root
  • Os contentores não devem utilizar o modo privilegiado
  • Os limites dos recursos devem ser definidos
  • As imagens devem provir de registos aprovados

Considerações sobre segurança específicas do Kubernetes

A segurança do Kubernetes torna-se vital ao gerenciar clusters. Controles de acesso baseados em funções (RBAC) ou painéis expostos aumentam o risco. Ao executar os containers do Docker em Kubernetes, são necessárias medidas de segurança adicionais.

Implementar Padrões de Segurança Pod

As Normas de Segurança do Pod Kubernetes definem três níveis de políticas de segurança: Privilegiadas, Baseline e Restritas. A política restrita impõe os requisitos de segurança mais rigorosos e deve ser usada para cargas de trabalho de produção sempre que possível.

apiVersion: v1
kind: Pod
metadata:
 name: secure-app
 labels:
 app: myapp
spec:
 securityContext:
 runAsNonRoot: true
 runAsUser: 1000
 fsGroup: 1000
 seccompProfile:
 type: RuntimeDefault
 containers:
 - name: app
 image: myapp:latest
 securityContext:
 allowPrivilegeEscalation: false
 readOnlyRootFilesystem: true
 capabilities:
 drop:
 - ALL
 runAsNonRoot: true
 runAsUser: 1000
 resources:
 limits:
 cpu: "1"
 memory: "512Mi"
 requests:
 cpu: "100m"
 memory: "128Mi"
 volumeMounts:
 - name: tmp
 mountPath: /tmp
 volumes:
 - name: tmp
 emptyDir: {}

Configurar as Políticas de Rede

As Políticas de Rede do Kubernetes fornecem um controle fino sobre a comunicação pod-to-pod. Por padrão, todos os pods podem se comunicar uns com os outros, o que viola o princípio do menor privilégio.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: api-network-policy
 namespace: production
spec:
 podSelector:
 matchLabels:
 app: api
 policyTypes:
 - Ingress
 - Egress
 ingress:
 - from:
 - podSelector:
 matchLabels:
 app: frontend
 ports:
 - protocol: TCP
 port: 8080
 egress:
 - to:
 - podSelector:
 matchLabels:
 app: database
 ports:
 - protocol: TCP
 port: 5432

Usar os Controladores de Admissão

Os controladores de admissão interceptam as solicitações ao servidor de APIs do Kubernetes antes de os objetos persistirem, permitindo- lhe aplicar políticas e validar configurações. Ferramentas como o OPA Gatekeeper e o Kyverno fornecem recursos de política como código.

Políticas de exemplo a implementar:

  • Requerer que todas as imagens sejam provenientes de registos aprovados
  • Aplicar limites de recursos em todos os contentores
  • Impedir a criação de recipientes privilegiados
  • Requer rótulos específicos em todos os recursos
  • Validar contextos de segurança que atendam aos requisitos mínimos

Conformidade e Considerações Regulatórias

As organizações que operam em indústrias regulamentadas devem assegurar que as suas implantações de contentores cumpram requisitos específicos de conformidade.

  • CIS Docker Benchmark: Fornece orientação prescritiva para estabelecer uma postura de configuração segura para o Docker
  • CIS Kubernetes Benchmark: Recomendações de segurança para implantações Kubernetes
  • PCI DSS: Requisitos para as organizações que lidam com dados de cartões de pagamento
  • HIPAA: Normas para proteger informações sensíveis sobre a saúde dos doentes
  • SOC 2: Framework para gerenciar dados de clientes com base em cinco princípios de serviço confiável
  • RGPD: Requisitos de proteção de dados e privacidade para residentes na UE

Ferramentas como Docker Bench for Security e kube-bench podem avaliar automaticamente seu ambiente com esses benchmarks e fornecer orientação de remediação.

# Run Docker Bench for Security
docker run --rm --net host --pid host --userns host --cap-add audit_control
 -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST
 -v /var/lib:/var/lib
 -v /var/run/docker.sock:/var/run/docker.sock
 -v /usr/lib/systemd:/usr/lib/systemd
 -v /etc:/etc --label docker_bench_security
 docker/docker-bench-security

# Run kube-bench for Kubernetes
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Segurança do Registo de Contentores

Os registros de containers são componentes críticos da cadeia de suprimentos de contêineres. A segurança de seus registros impede o acesso não autorizado às imagens e protege contra ataques de cadeias de suprimentos.

Usar Registros Privados

Embora registros públicos como o Docker Hub sejam convenientes, cargas de trabalho de produção devem usar registros privados com controles de acesso adequados. As opções incluem:

  • Harbor: Registro de código aberto com digitalização de vulnerabilidade, assinatura de imagem e RBAC
  • AWS ECR: Registo gerido integrado com serviços AWS
  • Azure Container Registry: Registro gerenciado para cargas de trabalho Azure
  • Google Container Registry: Registo gerido para GCP
  • JFrog Artifactory: Repositório de artefatos universal com recursos de segurança avançados

Implementar os Controles de Acesso ao Registro

Configurar autenticação e autorização para o acesso ao registro:

  • Usar contas de serviço com permissões mínimas para pipelines CI/CD
  • Implementar o controle de acesso baseado em funções (RBAC) para diferentes equipes
  • Activar o registo de auditoria para todas as operações de registo
  • Usar fichas de curta duração em vez de credenciais de longo prazo
  • Implementar a listagem de IP para acesso ao registro

Activar a Varredura Automática da Vulnerabilidade

O Docker Hub permite- lhe realizar uma digitalização de vulnerabilidade estática ponto-em-tempo ou sempre uma análise de imagem actualizada usando o Docker Scout. Depois de activar a análise de imagem do Docker Scout, o Docker Scout analisa automaticamente as imagens no seu repositório Docker Hub. A análise de imagens extrai a Lei de Materiais do Software (SBOM) e outros metadados de imagem, e avalia- a contra os dados de vulnerabilidade dos conselhos de segurança.

A maioria dos registros modernos oferecem uma digitalização integrada de vulnerabilidade que automaticamente verifica imagens quando são empurradas. Configure seu registro para:

  • Digitalizar todas as imagens automaticamente ao empurrar
  • Varrer continuamente as imagens para vulnerabilidades recém- descobertas
  • Implantação em bloco de imagens com vulnerabilidades críticas
  • Enviar notificações quando as vulnerabilidades são detectadas
  • Fornecer orientações de remediação para questões identificadas

Resposta e Recuperação de Incidentes

Apesar de implementar medidas de segurança abrangentes, os incidentes ainda podem ocorrer. Ter um plano de resposta de incidentes bem definido é crucial para minimizar os danos e recuperar rapidamente.

Desenvolva um plano de resposta a incidentes

O seu plano de resposta ao incidente deve incluir:

  • Detecção: Mecanismos para identificar incidentes de segurança através do acompanhamento e alerta
  • Contenção : Procedimentos para isolar os recipientes afectados e impedir a propagação
  • Investigação: Passos para analisar o incidente e determinar a causa raiz
  • Erradicação: Processos para remover ameaças e fechar vulnerabilidades
  • Recovery: Procedimentos para restaurar serviços e validar segurança
  • Revisão pós-incidente: Análise do que aconteceu e como prevenir recorrência

Implementar as capacidades forenses do container

A perícia de containers pode ser desafiadora devido à natureza efêmera dos contêineres. Implemente essas práticas para apoiar investigações:

  • Preservar o estado do recipiente criando instantâneos antes de terminar
  • Manter registos completos com períodos de retenção suficientes
  • Utilizar infra-estruturas imutáveis para evitar adulterações de provas
  • Implementar o registo de auditoria para todas as operações de contentores
  • Manter a origem da imagem e construir o histórico

Praticar Recuperação de Desastres

Teste regularmente os procedimentos de recuperação de desastres:

  • Realizar exercícios de mesa simulando incidentes de segurança
  • Teste procedimentos de backup e restauração para dados de container
  • Validar que você pode reconstruir ambientes do zero
  • Garantir que a documentação é atual e acessível
  • Membros da equipa de comboios em procedimentos de resposta a incidentes

Lista de verificação de segurança para as operações de produção

Comece com os itens de alto impacto: imagens mínimas, usuários não-root, digitalização de CI e pinning digest. Camada em monitoramento em tempo de execução, segmentação de rede e gerenciamento de segredos. Use esta lista de verificação abrangente para garantir que seus recipientes Docker atendam aos requisitos de segurança antes da implantação da produção:

Segurança da Imagem

  • Usar imagens de base mínimas (alpinas, distross)
  • Pino versões específicas de imagens usando digestos
  • Procurar por vulnerabilidades no pipeline CI/CD
  • Assinar imagens com o Docker Content Trust ou Cosign
  • Gerar e manter SBOMs para todas as imagens
  • Remover pacotes e arquivos desnecessários
  • Usar builds de vários estágios para minimizar o tamanho final da imagem
  • Nunca inclua segredos em imagens

Segurança de Tempo de Execução do Container

  • Executar recipientes como usuários não-root
  • Usar sistemas de ficheiros raiz apenas para leitura
  • Largue todas as capacidades e adicione apenas as necessárias
  • Activar a bandeira sem novos privilégios
  • Aplicar perfis seccomp, AppArmor ou SELinux
  • Definir limites de recursos (CPU, memória, PIDs)
  • Implementar a segmentação de rede
  • Usar redes privadas para comunicação intercontentor

Segurança de Host e Infraestrutura

  • Manter o sistema operacional da máquina e o kernel actualizados
  • Atualizar o motor de docker regularmente
  • Nunca expor o 'socket' do servidor do Docker
  • Usar o Docker sem raiz quando possível
  • Implementar firewalls baseados em host
  • Activar o registo de auditoria
  • Restrinja o acesso SSH com autenticação baseada em chaves
  • Usar máquinas de bastião para acesso à produção

Segredos e Gestão de Configuração

  • Usar os Segredos do Docker ou os cofres externos
  • Nunca credenciais de código rígido
  • Rodar os segredos regularmente
  • Usar fichas e credenciais de curta duração
  • Criptografar segredos em repouso e em trânsito
  • Acesso secreto de auditoria

Monitoramento e registro

  • Implementar o monitoramento de segurança em tempo de execução (Falco)
  • Centralizar os logs de todos os recipientes
  • Activar o registo do servidor de Docker
  • Monitorar a utilização dos recursos
  • Estabelecer alertas para atividades suspeitas
  • Manter retenção de log suficiente
  • Aplicar as pistas de auditoria para o cumprimento

Segurança de tubos CI/CD

  • Ficheiros do Lint Docker com Hadolint
  • Digitalizar imagens em pipeline CI
  • Falhar nas vulnerabilidades críticas
  • Aplicar a aplicação da política
  • Utilizar registos separados para desactivação/estacionamento/prod
  • Automatizar testes de segurança
  • Requer revisão de código para alterações do Dockerfile

Kubernetes-Específico (se aplicável)

  • Implementar Padrões de Segurança Pod
  • Configurar as Políticas de Rede
  • Utilizar controladores de admissão para aplicação de políticas
  • Activar o RBAC com menos privilégio
  • Proteja o servidor de APIs do Kubernetes
  • Encriptar os dados em repouso
  • Executar verificações de Benchmark CIS Kubernetes

Tendências emergentes e considerações futuras

A segurança do container continua a evoluir com novas tecnologias e abordagens. Mantenha-se informado sobre as tendências emergentes:

Segurança da Cadeia de Suprimentos

Os incidentes de 2025 — o transporte de imagens de base por meses, milhares de credenciais de produção vazadas através de arquivos Docker — provam que o básico ainda importa. Ataques de cadeia de suprimentos visando ecossistemas de contêineres estão aumentando. Implemente os princípios de framework SLSA (Níveis de cadeia de suprimentos para artefatos de software) para verificar a integridade da sua cadeia de suprimentos de software.

Arquitetura de confiança zero

Aplicar princípios de confiança zero em ambientes de contêineres assumindo violação e verificando cada pedido. Implementar tecnologias de malha de serviço como Istio ou Linkerd para fornecer autenticação TLS mútua, autorização de granulação fina e observação para comunicação de contêineres para o contêiner.

Segurança baseada no eBPF

Tecnologia de filtro de pacotes de Berkeley estendido (eBPF) permite monitoramento de segurança em tempo de execução poderoso com sobrecarga de desempenho mínimo. Ferramentas que alavancam o eBPF podem fornecer visibilidade profunda no comportamento do recipiente sem exigir módulos de kernel ou modificações de container.

Computação Confidencial

Tecnologias de computação confidenciais protegem dados em uso realizando computação em ambientes de execução confiáveis baseados em hardware (TEEs). Esta abordagem emergente pode proteger cargas de trabalho sensíveis, mesmo de usuários privilegiados e sistemas host comprometidos.

Ferramentas e Recursos Recomendados

Construir um programa abrangente de segurança de contêineres requer alavancar as ferramentas certas. Aqui estão os recursos recomendados organizados por categoria:

Varredura de Vulnerabilidade

  • Trivy (Fonte aberta): Escaneador de vulnerabilidade rápido e abrangente
  • Escutador de Docker: Digitalização integrada com o Docker Desktop e o CLI
  • Motor de ancoragem (Fonte aberta): Verificação e conformidade baseadas em políticas
  • Snyk Container: Digitalização focada no desenvolvedor com recomendações de correção
  • Clair (Fonte aberta): Análise estática das vulnerabilidades

Segurança em Tempo de Execução

  • Falco (Fonte aberta): Detecção de ameaça de execução usando o eBPF
  • Segurança Aqua: Plataforma de segurança abrangente de contentores
  • Sysdig Secure: Segurança em tempo de execução e perícia

Política e Cumprimento

  • Agente de Política Aberto (Fonte aberta): Motor de Política como código
  • Kyverno (Fonte aberta): Gestão de políticas nativas do Kubernetes
  • Cálculo de segurança (Fonte aberta): Controlos do CIS Docker Benchmark
  • kube-bench (Fonte aberta): Controlos de referência CIS Kubernetes

Gestão de Segredos

  • HashiCorp Vault: Gestão de segredos empresariais
  • AWS Secrets Manager: Segredos nativos em nuvem para AWS
  • Azure Key Vault: Gestão de segredos para o Azure
  • Google Secret Manager: Gestão de Segredos para o GCP

Recursos adicionais

Conclusão

A segurança do container é um processo contínuo que abrange vários aspectos, incluindo criação de imagens, manipulação secreta, comportamento de execução e monitoramento contínuo. A segurança é um processo contínuo. Audite regularmente suas configurações, atualize imagens de base e fique informado sobre novas vulnerabilidades. O esforço que você investe na segurança do container hoje protege sua infraestrutura amanhã.

A implementação de recipientes Docker seguros requer uma abordagem abrangente e em camadas que aborda a segurança em cada fase do ciclo de vida do recipiente. Da escolha de imagens de base mínimas e execução como usuários não-root para implementar o monitoramento em tempo de execução e manter a conformidade, cada medida de segurança contribui para uma estratégia robusta de defesa em profundidade.

Os recipientes Docker fornecem ferramentas poderosas para o desenvolvimento moderno, mas requerem supervisão cuidadosa para garantir que permaneçam seguros. Ao abordar os riscos associados às imagens Docker, privilégios de container e sistemas host, as organizações podem minimizar a probabilidade de violações e maximizar a confiabilidade de seus ambientes containerizados.

A chave para o sucesso da segurança do contêiner é tratá-lo não como uma implementação única, mas como uma prática contínua integrada à sua cultura de desenvolvimento. Automatize as verificações de segurança em seus pipelines CI/CD, monitore continuamente o comportamento de execução, atualize regularmente componentes e fique informado sobre ameaças emergentes e melhores práticas. Ao seguir as estratégias e recomendações descritas neste guia, você pode construir e manter aplicativos em containers seguros que protegem os ativos da sua organização, permitindo a agilidade e eficiência que os contêineres fornecem.

Lembre-se que a segurança é uma responsabilidade compartilhada. Enquanto as plataformas de orquestração de contêineres e Docker fornecem as ferramentas e capacidades, cabe às equipes de desenvolvimento e operações implementar e manter medidas de segurança de forma consistente.Invista em treinar sua equipe, estabelecer políticas de segurança claras e promover uma cultura onde a segurança seja da responsabilidade de todos.Com a combinação correta de ferramentas, práticas e vigilância, você pode aproveitar todo o poder da contêinerização, mantendo uma postura de segurança forte.