DEV Community: Luis Cruz

The Five Ideals of DevOps: os Cinco Ideais que Sustentam a Transformação DevOps

Luis Cruz — Thu, 30 Jul 2026 23:50:01 +0000

Toda organização que tenta "fazer DevOps" acaba, cedo ou tarde, comprando um Jenkins, adotando Kubernetes e escrevendo Terraform e mesmo assim continua com deploys arriscados, times sobrecarregados e um MTTR (Mean Time to Recovery) que não sai do lugar. A ferramenta certa não resolve um problema de arquitetura e cultura errada por baixo. É esse o ponto de partida de The Five Ideals (Os Cinco Ideais), um framework conceitual que separa DevOps de "conjunto de ferramentas" e o trata como ele realmente é: uma forma diferente de organizar trabalho, times e sistemas.

Origem do conceito

Os Cinco Ideais foram apresentados por Gene Kim em The Unicorn Project (2019), romance técnico que funciona como continuação conceitual de The Phoenix Project (2013), a obra que popularizou os "Três Caminhos" do DevOps (fluxo, feedback e aprendizagem contínua). Enquanto The Phoenix Project olha a transformação DevOps pela perspectiva de operações, The Unicorn Project conta a mesma história pelo lado do desenvolvimento, e os Cinco Ideais nascem justamente da frustração de uma desenvolvedora tentando fazer uma mudança simples em um sistema legado excessivamente acoplado.

O framework não substitui os Três Caminhos — ele os detalha em princípios mais concretos, fáceis de usar como checklist ao avaliar processos, arquitetura e cultura de um time.

Os cinco ideais, resumidos

#	Ideal	Em uma frase
1	Localidade e Simplicidade	Times mudam sistemas sem depender de dezenas de outros times
2	Foco, Fluxo e Alegria	Trabalho acontece sem interrupção constante de contexto
3	Melhoria do Trabalho Diário	Tempo é reservado para consertar o processo, não só a entrega
4	Segurança Psicológica	Errar e reportar erro não gera punição
5	Foco no Cliente	Toda decisão técnica é avaliada pelo valor que gera para quem usa o produto

1. Localidade e Simplicidade

Locality and Simplicity

O ideal descreve o quanto um time consegue fazer uma mudança sem precisar coordenar, negociar ou esperar por outros times. Quanto mais serviços, times e dependências uma mudança simples atravessa, menor a localidade, e maior o risco, o tempo de entrega e a chance de quebrar algo que ninguém previu.

Uma arquitetura de microsserviços mal desenhada é o exemplo clássico do problema: em vez de reduzir acoplamento, ela às vezes só move o acoplamento do código para a rede, exigindo que uma mudança de negócio toque em cinco ou dez serviços diferentes, cada um com seu próprio time, pipeline e prazo de deploy.

Baixa localidade                    Alta localidade
─────────────────                   ────────────────
1 mudança de negócio      →         1 mudança de negócio
   ↓ toca 8 serviços                   ↓ toca 1 serviço
   ↓ 5 times envolvidos                ↓ 1 time envolvido
   ↓ 3 pipelines de deploy             ↓ 1 pipeline de deploy
   ↓ prazo: 3 semanas                  ↓ prazo: 2 dias

Na prática, isso se traduz em decisões arquiteturais concretas: bounded contexts bem definidos (Domain-Driven Design), times de plataforma que expõem self-service em vez de exigir ticket, e a disciplina de perguntar "quantos times essa mudança precisa acionar?" antes de aprovar um desenho técnico.

2. Foco, Fluxo e Alegria

Focus, Flow, and Joy

Trabalho de engenharia exige estado de fluxo, a concentração profunda que permite resolver um problema complexo de ponta a ponta. Esse estado leva, em média, entre 15 e 20 minutos para ser atingido depois de uma interrupção, segundo os estudos citados no próprio The Unicorn Project. Um desenvolvedor interrompido a cada 10 minutos por reunião, mensagem urgente ou troca de contexto entre projetos nunca chega a entrar em fluxo — e a sensação de "trabalhei o dia inteiro e não produzi nada" é sintoma direto disso.

Esse ideal é sobre desenhar o ambiente de trabalho — não só a agenda, mas os próprios sistemas — para proteger esse estado:

Reduzir o número de sistemas que um desenvolvedor precisa tocar para uma tarefa (relação direta com o Ideal 1)
Ambientes de desenvolvimento e teste que sobem em minutos, não em dias, evitando bloqueio por espera
Deploys automatizados no lugar de checklists manuais que exigem atenção constante durante o processo
Proteger blocos de tempo sem reunião para trabalho profundo

O resultado esperado não é só produtividade é "alegria" no sentido literal do termo: satisfação genuína de resolver problemas e ver o trabalho chegar ao cliente, em vez de desgaste com burocracia.

3. Melhoria do Trabalho Diário

Improvement of Daily Work

Mike Rother, em Toyota Kata, resume esse ideal em uma frase que Gene Kim cita diretamente: "melhorar o trabalho diário é ainda mais importante do que fazer o trabalho diário em si". Times sob pressão constante de entrega tendem a aceitar processos manuais e ferramentas ruins como "o jeito que as coisas são" e nunca sobra tempo para consertar a causa raiz, só para apagar o incêndio de novo a cada semana.

Esse ideal exige reservar tempo, de forma explícita e recorrente, para:

Automatizar uma tarefa manual repetitiva (ex.: um passo de deploy ainda feito por script rodado à mão)
Refatorar um trecho de código ou pipeline que gera atrito toda semana
Investigar a causa raiz de um problema recorrente, em vez de só contorná-lo de novo

# Exemplo: bloco de tempo reservado no sprint para dívida técnica de processo,
# não só de código
sprint_capacity:
  feature_work: 70%
  bugs: 15%
  improvement_of_daily_work: 15%

Sem esse tempo protegido, o time acumula o que Gene Kim chama de "débito de processo" — o equivalente, em fricção operacional, à dívida técnica no código.

4. Segurança Psicológica

Psychological Safety

Termo cunhado pela pesquisadora Amy Edmondson, de Harvard, e confirmado como o fator mais determinante de times de alta performance pelo Project Aristotle do Google. Significa que um profissional pode admitir um erro, questionar uma decisão de alguém mais sênior ou levantar um problema em produção sem medo de retaliação — e isso é o que determina se um problema é reportado cedo, quando é barato de corrigir, ou escondido até virar incidente grave.

A prática mais associada a esse ideal em times DevOps é o blameless postmortem: análise pós-incidente cujo objetivo é entender a cadeia de causas sistêmicas por que o sistema permitiu que aquele erro humano causasse dano em vez de identificar quem errou.

Postmortem com culpa	Blameless postmortem
"Quem fez o deploy sem revisar?"	"Por que o pipeline permitiu deploy sem revisão obrigatória?"
Foco em punir o indivíduo	Foco em corrigir o sistema
Próximo incidente similar é escondido	Próximo incidente similar é reportado imediatamente

Segurança psicológica não é ausência de padrão de qualidade — é a garantia de que o erro, quando acontece, vira aprendizado para todo o time em vez de motivo de punição individual.

5. Foco no Cliente

Customer Focus

O ideal final é o critério de desempate para todos os outros: toda decisão técnica precisa ser avaliada pelo valor que gera para quem usa o produto — não pela elegância da solução ou pela preferência tecnológica do time. Gene Kim chama de "trabalho de vaidade técnica" (vanity engineering work) qualquer esforço que consome tempo de engenharia sem gerar valor perceptível para o cliente final: reescrever um serviço estável só para adotar uma stack mais nova, otimizar uma rota que ninguém usa, ou construir uma camada de abstração para um requisito hipotético.

Times orientados por esse ideal costumam medir o próprio trabalho por métricas que conectam entrega técnica a resultado de negócio — não só uptime e velocidade de deploy, mas retenção, satisfação e tempo até o cliente perceber valor.

Como os cinco ideais se conectam às práticas DevOps

Ideal	Onde aparece na prática
Localidade e Simplicidade	Arquitetura de microsserviços, bounded contexts, self-service de infraestrutura
Foco, Fluxo e Alegria	Pipeline CI/CD automatizado, ambientes de desenvolvimento efêmeros, redução de reuniões
Melhoria do Trabalho Diário	Tempo de sprint reservado para automação e dívida de processo
Segurança Psicológica	Blameless postmortems, cultura de code review sem julgamento
Foco no Cliente	Priorização por métrica de negócio, redução de MTTR como indicador de confiabilidade percebida pelo usuário

Não é coincidência que os cinco apareçam juntos: um pipeline de deploy automatizado (Ideal 2) só existe porque alguém teve tempo reservado para construí-lo (Ideal 3); e esse tempo só é bem investido se a arquitetura por trás permite mudanças localizadas (Ideal 1). Os ideais se reforçam entre si — fraquejar em um tende a corroer os demais.

Boas práticas para aplicar os Cinco Ideais

Use os ideais como checklist de arquitetura, não só de cultura — ao desenhar um novo serviço, pergunte quantos times ele vai exigir para uma mudança simples
Meça interrupção, não só velocity — quantidade de trocas de contexto por dia é um indicador tão relevante quanto story points entregues
Proteja o tempo de melhoria do trabalho diário no planejamento, com percentual fixo de capacidade, não como "se sobrar tempo"
Audite se os postmortems da sua empresa são realmente blameless — se a pergunta "quem fez isso?" aparece antes de "por que o sistema permitiu isso?", a segurança psicológica só existe no papel
Revise backlog técnico com a pergunta do Ideal 5 — se a resposta para "que valor isso gera para o cliente?" for vaga, é sinal de trabalho de vaidade técnica

Conclusão

Os Cinco Ideais não são um framework de implementação com passo a passo, e essa é justamente a força deles: funcionam como lente para diagnosticar por que uma transformação DevOps travou, mesmo depois de a empresa ter comprado todas as ferramentas certas. Um time pode ter Kubernetes, pipeline de CI/CD e observabilidade completa e ainda assim sofrer com deploys lentos e arriscados, se a arquitetura por trás força alta dependência entre times (Ideal 1) ou se o medo de errar mantém problemas escondidos até virarem incidente (Ideal 4).

Antes de comprar a próxima ferramenta, vale revisar os cinco ideais contra o processo atual do seu time: qual deles está mais fraco hoje é, quase sempre, a resposta para por que a transformação DevOps não está entregando o resultado esperado.

Referências

Kim, Gene. The Unicorn Project (2019) — IT Revolution Press
Kim, Gene; Behr, Kevin; Spafford, George. The Phoenix Project (2013) — IT Revolution Press
Rother, Mike. Toyota Kata (2009) — McGraw-Hill
Edmondson, Amy. The Fearless Organization (2018) — Wiley

DevOps na Prática: Como Reduzir Problemas com Servidores e Rede

Luis Cruz — Thu, 23 Jul 2026 19:48:21 +0000

Servidor caindo às três da manhã, rede instável derrubando uma transação em produção, deploy que funcionava em homologação e quebra tudo ao subir — quem já passou uma madrugada resolvendo esse tipo de incidente sabe que boa parte desses problemas não é falta de sorte, é falta de processo. A maioria das instabilidades de infraestrutura tem uma causa raiz recorrente: configuração manual, ausência de monitoramento proativo e deploys sem plano de rollback.

DevOps não é uma ferramenta específica nem um cargo, é um conjunto de práticas que ataca exatamente esses pontos, unindo automação, observabilidade e colaboração entre quem desenvolve e quem opera a infraestrutura. Este artigo detalha as principais estratégias para reduzir problemas com servidores e rede usando DevOps, com exemplos práticos de configuração para cada uma.

Visão geral das estratégias

Frente	Objetivo	Ferramentas comuns
Automação de infraestrutura	Eliminar configuração manual e divergência entre ambientes	Terraform, Ansible, Jenkins, GitLab CI/CD
Monitoramento e logging	Detectar problemas antes que virem incidente	Prometheus, Grafana, ELK Stack, Datadog
Escalabilidade e resiliência	Absorver picos de carga e falhas sem downtime	Docker, Kubernetes, Load Balancers
Gestão de configuração e deployments	Reduzir o raio de impacto de uma mudança ruim	Canary/Blue-Green, imagens imutáveis
Colaboração e cultura	Encurtar o tempo entre "algo quebrou" e "está resolvido"	Runbooks, on-call, postmortems
Segurança e conformidade	Achar vulnerabilidade antes que vire incidente de segurança	Snyk, Aqua, HashiCorp Vault

1. Automação de infraestrutura

Infraestrutura como Código (IaC)

Servidor configurado manualmente é o principal motivo de "funciona no meu ambiente, mas não em produção". Cada alteração feita via SSH, sem registro, cria uma divergência que ninguém consegue reproduzir depois. A Infraestrutura como Código resolve isso descrevendo o estado desejado do ambiente em arquivos versionados, o mesmo código que provisiona um servidor de homologação provisiona o de produção, sem intervenção manual.

Terraform, Ansible, Chef e Puppet cobrem esse espaço com abordagens diferentes: Terraform é declarativo e brilha em provisionamento de recursos de nuvem; Ansible é mais simples de aprender e cobre bem configuração de servidores já provisionados.

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"

  tags = {
    Name        = "web-server"
    Environment = "production"
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_lb_target_group_attachment" "web" {
  target_group_arn = aws_lb_target_group.web.arn
  target_id        = aws_instance.web.id
  port             = 80
}

Pipeline CI/CD

Sem pipeline automatizado, cada deploy depende de alguém lembrar todos os passos manuais, rodar teste, gerar build, copiar arquivo, reiniciar serviço. É nesse processo manual que surgem os erros que derrubam produção. Um pipeline de CI/CD com Jenkins, GitLab CI/CD ou CircleCI garante que toda mudança passe pelas mesmas etapas de teste e validação antes de chegar ao servidor.

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script:
    - npm install
    - npm run test

build:
  stage: build
  script:
    - docker build -t registry.exemplo.com/app:$CI_COMMIT_SHA .
    - docker push registry.exemplo.com/app:$CI_COMMIT_SHA

deploy:
  stage: deploy
  script:
    - kubectl set image deployment/app app=registry.exemplo.com/app:$CI_COMMIT_SHA
  only:
    - main

2. Monitoramento e logging

Monitoramento contínuo

Boa parte dos incidentes de servidor e rede só é percebida quando o cliente reclama, o que significa que o problema já está afetando produção há minutos ou horas. Ferramentas como Prometheus, Grafana, Nagios e Datadog monitoram métricas de CPU, memória, latência de rede e disponibilidade em tempo real, disparando alertas antes que o problema escale.

scrape_configs:
  - job_name: 'node-exporter'
    scrape_interval: 15s
    static_configs:
      - targets: ['servidor-web-01:9100', 'servidor-web-02:9100']

  - job_name: 'blackbox-http'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets: ['https://app.exemplo.com']
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - target_label: __address__
        replacement: blackbox-exporter:9115

Centralização de logs

Investigar um incidente de rede sem logs centralizados significa entrar servidor por servidor procurando o que aconteceu — em uma arquitetura com dezenas de containers, isso é inviável. ELK Stack (Elasticsearch, Logstash, Kibana), Graylog e Splunk coletam logs de todos os componentes em um único lugar, permitindo correlacionar um erro de aplicação com um evento de rede acontecendo no mesmo segundo.

3. Escalabilidade e resiliência

Infraestrutura escalável

Servidor único sobrecarregado é causa clássica de indisponibilidade em picos de tráfego. Containers com Docker e orquestração com Kubernetes permitem escalabilidade horizontal, em vez de aumentar a capacidade de um único servidor (escalabilidade vertical, que tem limite físico), o sistema soma mais instâncias conforme a demanda cresce.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Arquitetura resiliente

Balanceadores de carga distribuem tráfego entre múltiplas instâncias, evitando que a falha de um único servidor derrube o serviço inteiro. Combinado com failover automático e replicação de dados, o sistema continua respondendo mesmo com um nó fora do ar. O padrão Circuit Breaker complementa essa resiliência: quando um serviço dependente começa a falhar repetidamente, o circuito "abre" e para de enviar requisições para ele por um tempo, evitando que uma falha em cascata derrube toda a cadeia de serviços.

4. Gestão de configuração e deployments

Configuração imutável

Servidor que recebe patches e ajustes manuais ao longo de meses acumula um estado que ninguém mais consegue reproduzir do zero, o clássico "servidor de estimação" que todo time tem medo de reiniciar. A prática de configuração imutável resolve isso tratando servidores como descartáveis: em vez de corrigir um servidor com problema, ele é destruído e recriado a partir de uma imagem base atualizada e testada.

Deployments Canary e Blue-Green

Subir uma versão nova diretamente para 100% dos usuários é apostar que não vai dar problema. Estratégias de deployment reduzem esse risco:

Estratégia	Como funciona	Quando usar
Blue-Green	Ambiente novo (green) sobe em paralelo ao atual (blue); tráfego migra de uma vez após validação	Mudanças grandes, rollback precisa ser instantâneo
Canary	Nova versão recebe uma fatia pequena do tráfego (ex.: 5%), que aumenta gradualmente se não houver erro	Mudanças de risco incerto, quer validar com usuários reais antes de expandir

kubectl argo rollouts set image app app=registry.exemplo.com/app:v2
kubectl argo rollouts get rollout app --watch

5. Colaboração e cultura

Automação e monitoramento resolvem o lado técnico, mas incidente que se repete porque ninguém documentou a causa raiz é problema de processo, não de ferramenta. Cultura DevOps significa que desenvolvimento e operações compartilham a responsabilidade pela infraestrutura em produção, em vez de "jogar o código por cima do muro" para um time de infra separado.

Duas práticas concretas sustentam isso:

Postmortem sem culpados: todo incidente relevante gera um documento com linha do tempo, causa raiz e ações de prevenção — sem apontar culpado individual, para que o time reporte problemas sem medo
Loop de feedback contínuo: métricas de produção (erros, latência, uso de recursos) voltam para o time de desenvolvimento como insumo de priorização, não só como alarme de incêndio

6. Segurança e conformidade

Segurança integrada (DevSecOps)

Vulnerabilidade encontrada em produção custa muito mais para corrigir do que uma encontrada no pipeline, antes do deploy. DevSecOps integra a análise de segurança diretamente no CI/CD, ferramentas como Snyk, Clair e Aqua escaneiam código, dependências e imagens de container automaticamente a cada build, bloqueando o deploy se encontrarem uma vulnerabilidade crítica.

security-scan:
  stage: test
  script:
    - snyk test --severity-threshold=high
    - snyk container test registry.exemplo.com/app:$CI_COMMIT_SHA
  allow_failure: false

Conformidade e auditoria

Toda mudança de infraestrutura aplicada via IaC e pipeline já fica registrada em controle de versão, quem mudou, o quê e quando. Isso, por si só, resolve boa parte do trabalho de auditoria que antes dependia de planilha e memória de quem fez a mudança.

Ferramentas e tecnologias por categoria

Categoria	Ferramentas
CI/CD	Jenkins, GitLab CI, CircleCI, Travis CI
Infraestrutura como Código	Terraform, Ansible, Chef, Puppet
Containers e orquestração	Docker, Kubernetes
Monitoramento e logging	Prometheus, Grafana, ELK Stack, Datadog, Graylog
Gerenciamento de configuração distribuída	Consul, Etcd, Zookeeper
Segurança	Snyk, Clair, Aqua, HashiCorp Vault

Boas práticas e troubleshooting

Comece pelo monitoramento, não pela automação mais sofisticada — sem visibilidade do que está acontecendo, é impossível saber se a automação está resolvendo o problema certo
Versione toda configuração de infraestrutura, mesmo mudanças pequenas — o histórico do Git é o primeiro lugar a olhar quando algo quebra depois de um deploy
Teste o rollback antes de precisar dele — pipeline que só testa o caminho feliz do deploy costuma falhar justamente na hora em que o rollback é necessário
Alerta demais é tão ruim quanto alerta de menos — times que recebem centenas de alertas por dia passam a ignorá-los; calibre thresholds para que um alerta signifique ação real
Evite scripts de configuração "só até resolvermos isso direito" — esse tipo de gambiarra manual é justamente o que a configuração imutável e a IaC existem para eliminar

Conclusão

Reduzir problemas com servidores e rede não depende de uma ferramenta mágica, mas da combinação de automação de infraestrutura, monitoramento contínuo, arquitetura resiliente e uma cultura em que desenvolvimento e operações dividem a responsabilidade pelo que está em produção. Cada uma das seis frentes descritas aqui ataca uma causa raiz específica de incidente — configuração manual, falta de visibilidade, ponto único de falha, deploy sem plano de rollback, silos entre equipes e vulnerabilidade não tratada.

O ponto de partida não precisa ser a adoção completa de Kubernetes e um pipeline elaborado no primeiro mês. Comece identificando qual dessas causas gera mais incidentes no seu ambiente hoje, e ataque essa frente primeiro, o restante se constrói de forma incremental a partir daí.

CSPM, CWPP e CNAPP: o que cada sigla protege na sua nuvem e como se relacionam

Luis Cruz — Wed, 15 Jul 2026 00:57:06 +0000

Uma empresa que roda workloads em AWS, Azure ou GCP costuma acumular, sem perceber, três problemas de segurança diferentes ao mesmo tempo: um bucket S3 público que ninguém lembra de ter criado, uma imagem de container com uma CVE crítica rodando em produção há meses, e nenhuma visibilidade real de como esses dois problemas se conectam a um caminho de ataque. O mercado de segurança em nuvem batizou cada uma dessas frentes com uma sigla própria, CSPM, CWPP e CNAPP e é comum confundir uma com a outra, ou tratar como três ferramentas concorrentes quando, na prática, a mais recente das três nasceu para unificar as outras duas.

Este artigo explica o que cada sigla significa, para que serve, como usar na prática e como elas se encaixam quando combinadas.

Visão geral rápida

Sigla	Nome completo	Foco	O que responde
CSPM	Cloud Security Posture Management	Configuração da infraestrutura em nuvem	"Minha nuvem está configurada de forma segura?"
CWPP	Cloud Workload Protection Platform	Proteção do que roda dentro da nuvem (VM, container, serverless)	"O que está rodando dentro da minha carga de trabalho é seguro?"
CNAPP	Cloud-Native Application Protection Platform	Unificação de CSPM + CWPP + outras camadas	"Qual é o meu risco real, do código à execução?"

Repare que CSPM e CWPP olham para dois lados diferentes do mesmo ambiente — um olha a configuração ao redor do workload, o outro olha o que roda dentro dele — e o CNAPP surgiu justamente para juntar essas duas vistas (e outras) em uma plataforma só.

CSPM: postura de configuração da nuvem

Como e por que surgiu

O termo foi cunhado pelo Gartner por volta de 2019, mas o problema é mais antigo: com a migração em massa para IaaS, times passaram a provisionar infraestrutura via console ou API em minutos, sem o mesmo processo de revisão que existia em datacenter próprio. O resultado recorrente eram erros de configuração — bucket de storage público, security group liberado para 0.0.0.0/0, banco de dados sem criptografia, chave de IAM com privilégio excessivo. Pesquisas do setor apontam configuração incorreta, não exploração de vulnerabilidade de software, como a causa mais comum de incidente em nuvem. O CSPM nasceu para automatizar a detecção contínua desse tipo de erro, que antes dependia de checklist manual ou auditoria pontual.

Para que serve

Uma ferramenta de CSPM conecta via API de leitura (read-only) às contas de nuvem do cliente (AWS, Azure, GCP, e às vezes Kubernetes gerenciado) e varre continuamente a configuração de cada recurso contra um conjunto de regras — benchmarks como CIS Benchmarks, controles de PCI-DSS, ISO 27001 ou frameworks próprios do provedor. Entre o que ela cobre:

Categoria	Exemplo de verificação
Exposição de rede	Security group ou NSG liberando porta administrativa (22, 3389, 3306) para a internet
Storage	Bucket S3, Azure Blob ou GCS com acesso público não intencional
Criptografia	Volume EBS, banco RDS ou disco sem criptografia em repouso
IAM	Usuário ou role com política `:`, MFA desabilitado, chave de acesso não rotacionada
Logging/auditoria	CloudTrail, Activity Log ou Cloud Audit Logs desabilitado em alguma região/projeto
Compliance	Mapeamento automático da configuração atual contra CIS, PCI-DSS, HIPAA, LGPD

A saída típica é um painel com findings priorizados por severidade, muitas vezes com remediação automática (auto-fix) ou geração de ticket para o time responsável. Ferramentas conhecidas nessa categoria: Wiz, Prisma Cloud, Microsoft Defender for Cloud, AWS Security Hub, Orca Security.

Exemplo prático

Um time sobe um bucket S3 para armazenar exports temporários de relatório e, por engano, deixa a política de bucket com Principal: "*". Sem CSPM, esse bucket fica exposto até alguém notar manualmente ou até aparecer em um scan externo de terceiros. Com CSPM rodando, a ferramenta detecta a mudança de configuração em minutos (via CloudTrail ou varredura periódica), classifica como severidade crítica por conter dados sensíveis, e dispara alerta ou já reverte a política automaticamente, dependendo da regra configurada.

CWPP: proteção da carga de trabalho

Como e por que surgiu

O termo também é do Gartner, um pouco mais antigo que CSPM (por volta de 2018), evoluindo do conceito tradicional de proteção de servidor (antivírus, EDR) adaptado para o mundo de nuvem híbrida. A motivação: CSPM garante que a configuração ao redor do workload está correta, mas não olha para dentro da VM, do container ou da função serverless, não detecta um processo malicioso rodando, uma imagem de container com vulnerabilidade conhecida, ou um binário malicioso plantado por um atacante que já obteve acesso inicial.

Para que serve

CWPP protege a carga de trabalho em si, ao longo de todo o ciclo de vida, do build ao runtime e normalmente cobre múltiplos tipos de workload sob uma mesma plataforma:

Tipo de workload	O que o CWPP cobre
Máquinas virtuais	Hardening de SO, detecção de malware, EDR, gestão de patch
Containers	Scan de vulnerabilidade de imagem, verificação de configuração do Dockerfile, proteção em runtime
Kubernetes	Políticas de admissão, detecção de comportamento anômalo em pod, segmentação de rede entre namespaces
Serverless (Lambda, Cloud Functions)	Análise de permissões da função, detecção de código malicioso injetado, proteção de dependências

As capacidades típicas se dividem em duas fases:

Antes do deploy (shift-left): scan de imagem de container em pipeline CI/CD, análise de IaC (Terraform, CloudFormation) antes do apply, verificação de dependências vulneráveis (SCA — Software Composition Analysis)
Durante a execução (runtime): monitoramento de comportamento do processo, detecção de escalonamento de privilégio, bloqueio de conexão de rede anômala, integridade de arquivo

Ferramentas conhecidas: Aqua Security, Sysdig, Falco (open source, focado em runtime), Trivy (open source, focado em scan de imagem), CrowdStrike Falcon Cloud Security.

Exemplo prático

Uma imagem de container publicada há seis meses usa uma versão do OpenSSL com uma CVE crítica divulgada na semana passada. O CWPP, ao reavaliar continuamente o inventário de imagens em uso (não só no momento do build), identifica que essa imagem específica está rodando em produção, calcula o risco combinando severidade da CVE com exposição real (a aplicação recebe tráfego externo?) e prioriza a remediação, algo que um scan único feito só no pipeline de CI, sem revarredura contínua, jamais pegaria depois do deploy.

CNAPP: a unificação das duas camadas

Como e por que surgiu

Por volta de 2021, o Gartner formalizou o termo CNAPP reconhecendo um problema prático: empresas estavam comprando uma ferramenta de CSPM, outra de CWPP, mais uma de scan de IaC, outra de gestão de segredo, e mais uma de gestão de identidade em nuvem (CIEM), cada uma com console próprio, sem correlação entre os achados. Um finding de CSPM ("esse security group está aberto") e um finding de CWPP ("essa VM tem uma vulnerabilidade crítica") não conversavam entre si, mesmo quando, juntos, formavam um caminho de ataque real e explorável.

Para que serve

CNAPP é uma plataforma consolidada que integra, no mínimo, CSPM e CWPP sob um único data model, e tipicamente soma outras camadas:

Componente incorporado	O que adiciona
CSPM	Postura de configuração de infraestrutura
CWPP	Proteção de workload (VM, container, serverless)
CIEM (Cloud Infrastructure Entitlement Management)	Análise de permissões excessivas de identidades humanas e de máquina
IaC scanning	Verificação de Terraform/CloudFormation/Bicep antes do deploy
KSPM (Kubernetes Security Posture Management)	Postura de configuração específica de cluster Kubernetes
Secrets scanning	Detecção de credencial exposta em código ou imagem
DSPM (Data Security Posture Management)	Descoberta e classificação de dado sensível espalhado pela nuvem

O diferencial real de um CNAPP não é só "ter tudo isso na mesma assinatura" é a correlação entre camadas para priorizar risco por caminho de ataque real, em vez de uma lista plana de milhares de findings isolados. Um bucket com dado sensível exposto (DSPM), acessível por uma role com permissão excessiva (CIEM), rodando atrás de uma VM com uma CVE crítica e exposta à internet (CWPP + CSPM), é um caminho de ataque completo e é isso que um CNAPP maduro mostra graficamente, priorizando esse combo acima de mil alertas isolados de baixo risco.

Ferramentas conhecidas: Wiz, Prisma Cloud (Palo Alto), Microsoft Defender for Cloud, Orca Security, CrowdStrike Falcon Cloud Security, Aqua Security.

Exemplo prático

Retomando os dois exemplos anteriores: o bucket S3 mal configurado e a imagem de container vulnerável, isoladamente, geram dois alertas médios em ferramentas separadas o tipo de alerta que se acumula em uma fila e nunca é tratado com urgência. Em um CNAPP, o motor de correlação identifica que a role IAM usada pela aplicação vulnerável tem permissão de leitura sobre esse mesmo bucket. O resultado não são dois findings soltos: é um único alerta crítico descrevendo o caminho completo — "atacante explora CVE na imagem X, herda a role Y, acessa dado sensível no bucket Z" — com prioridade muito mais alta do que qualquer um dos dois problemas isolados sugeriria.

Como as três siglas se relacionam

	CSPM	CWPP	CNAPP
O que protege	Configuração da infraestrutura em nuvem	O workload em execução (VM, container, função)	Ambos, mais camadas adicionais (CIEM, DSPM, IaC, secrets)
Momento de atuação	Contínuo, pós-deploy (e cada vez mais pré-deploy via IaC scan)	Build (shift-left) e runtime	Do código ao runtime, ciclo completo
Unidade de análise	Recurso de nuvem (bucket, security group, role)	Processo, imagem, container, função	Caminho de ataque correlacionado entre recursos
Nasce de	Necessidade de detectar erro de configuração em escala	Necessidade de estender EDR/antivírus para nuvem	Necessidade de unificar CSPM + CWPP + ferramentas correlatas
Substitui as outras?	Não	Não	Tipicamente incorpora ambas em uma única plataforma

Uma forma simples de visualizar: CSPM olha a casa (portas e janelas trancadas, alarme ligado), CWPP olha quem está dentro da casa (processos e comportamento), e CNAPP é o painel único que junta as duas vistas e ainda soma outras câmeras (identidade, dado sensível, segredo) para mostrar o caminho de invasão completo, não só os pontos fracos isolados.

Como usar na prática

Comece com CSPM se a maturidade em nuvem é baixa — é o retorno mais rápido: a maioria dos ambientes tem erro de configuração crítico esperando para ser encontrado, e a implantação costuma ser só leitura via API, sem agente
Adicione CWPP onde há workload sensível — containers e VMs expostos à internet, ou que processam dado regulado, justificam agente de runtime além da varredura de configuração
Integre scan de IaC no pipeline antes do deploy — encontrar o security group mal configurado no terraform plan, antes do apply, é ordens de magnitude mais barato do que corrigir depois de exposto em produção
Avalie CNAPP quando a organização já opera CSPM e CWPP separados e sofre com alert fatigue — a consolidação só compensa quando o time já tem findings suficientes para precisar de correlação; para um ambiente pequeno, CSPM isolado pode ser suficiente por um bom tempo
Priorize por caminho de ataque, não por severidade isolada — uma CVE crítica em uma máquina isolada, sem exposição de rede e sem dado sensível, é bem menos urgente que uma CVE média em uma máquina exposta com acesso a dado regulado
Não trate como substituto de WAF, SIEM ou pentest — CSPM/CWPP/CNAPP cobrem postura e workload de nuvem, não substituem proteção de borda de aplicação nem resposta a incidente formal

Boas práticas

Não deixe alertas de CSPM acumular sem triagem — ambientes recém-conectados costumam gerar milhares de findings; comece filtrando por severidade crítica/alta e exposição pública antes de tentar zerar tudo
Use as regras de CIS Benchmark como ponto de partida, não como lista definitiva — adapte exceções documentadas para casos legítimos (ex: bucket público de assets estáticos de um site)
Integre o CWPP à pipeline de CI/CD, não só ao runtime — bloquear build com CVE crítica antes do deploy é mais barato do que caçar a imagem já rodando em produção
Combine CIEM com CSPM/CWPP sempre que possível — permissão excessiva é o fator que transforma uma vulnerabilidade isolada em um caminho de ataque completo
Revise a política de auto-remediação com cuidado — corrigir automaticamente uma configuração de produção sem revisão humana pode causar indisponibilidade; comece com alerta e evolua para remediação automática só em regras bem testadas

Perguntas frequentes

Pergunta	Resposta
CSPM detecta vulnerabilidade dentro de um container?	Não — isso é função de CWPP. CSPM olha a configuração do ambiente ao redor, não o conteúdo do workload
Preciso de CWPP se uso só serviços gerenciados (managed services)?	Em menor grau — o provedor cuida da infraestrutura subjacente, mas funções serverless e containers que você mesmo publica ainda têm código e dependências que precisam de verificação
CNAPP substitui completamente CSPM e CWPP separados?	Na prática, sim — a maioria dos fornecedores de CNAPP oferece os módulos de CSPM e CWPP dentro da mesma plataforma, com a vantagem adicional da correlação
Ferramentas open source como Trivy e Falco competem com CNAPP comercial?	Cobrem pedaços específicos (scan de imagem, detecção de runtime) muito bem e sem custo de licença, mas não entregam a correlação entre camadas nem o painel de gestão unificado de um CNAPP comercial
Qual sigla é mais importante para começar?	Depende do maior risco do ambiente: se a preocupação é configuração exposta, CSPM primeiro; se é código/imagem vulnerável rodando, CWPP primeiro; times maduros tendem a convergir para CNAPP de qualquer forma

Conclusão

CSPM, CWPP e CNAPP não competem entre si — são camadas que evoluíram para cobrir ângulos diferentes do mesmo problema. CSPM garante que a configuração da infraestrutura em nuvem está correta. CWPP garante que o que roda dentro dessa infraestrutura — VM, container, função — está livre de vulnerabilidade e comportamento malicioso. E CNAPP surgiu para unificar as duas vistas (e outras, como CIEM e DSPM) em uma plataforma só, com o benefício real de correlacionar findings isolados em caminhos de ataque priorizáveis.

Antes de sair comprando uma plataforma de CNAPP completa, vale mapear onde está o maior risco real do seu ambiente hoje — configuração exposta, workload vulnerável, ou falta de correlação entre os dois — e usar isso para decidir por onde começar.

Referências

PCI-DSS, ISO 27001, ISO 27701 e ISO 27018: o que cada um cobre e como se relacionam

Luis Cruz — Mon, 13 Jul 2026 13:59:42 +0000

Uma empresa que processa pagamento com cartão, guarda dado de cliente e roda tudo em nuvem pública recebe, com frequência, quatro pedidos de auditoria diferentes: o adquirente de cartão cobrando conformidade com PCI-DSS, o cliente enterprise pedindo certificado ISO 27001, o jurídico perguntando sobre ISO 27701 por causa da LGPD, e o provedor de nuvem citando ISO 27018 no contrato. É comum o time de segurança tratar isso como quatro projetos separados, quando na prática são camadas que se apoiam umas nas outras — e boa parte do trabalho feito para uma serve de base para as outras três.

Este artigo explica o que cada uma dessas normas cobre, para que serve, quem precisa de cada uma e como elas se encaixam quando aplicadas juntas.

Visão geral rápida

Norma	Tipo	Foco	Órgão responsável
PCI-DSS	Padrão de conformidade obrigatório (não é ISO)	Proteção de dados de cartão de pagamento	PCI Security Standards Council
ISO/IEC 27001	Norma internacional certificável	Sistema de Gestão de Segurança da Informação (SGSI/ISMS)	ISO/IEC
ISO/IEC 27701	Norma certificável (independente desde a revisão 2026)	Sistema de Gestão de Privacidade da Informação (PIMS)	ISO/IEC
ISO/IEC 27018	Código de prática (não certificável isoladamente)	Proteção de dados pessoais em nuvem pública	ISO/IEC

Repare que só a PCI-DSS não é uma norma ISO — ela nasceu de um consórcio das bandeiras de cartão, não do comitê de padronização internacional. As outras três pertencem à mesma família (a série ISO/IEC 27000) e foram desenhadas para se complementar.

Atualização (revisão 2026): até então, a ISO 27701 só podia ser certificada como extensão de uma ISO 27001 já certificada. Com a revisão de 2026, ela passa a ser uma norma independente — uma empresa pode certificar seu Sistema de Gestão de Privacidade da Informação (PIMS) sem precisar ter ou implementar a 27001 junto. Isso não muda o fato de que as duas continuam extremamente complementares na prática (ver seção da ISO 27701 abaixo).

PCI-DSS: proteção de dados de cartão

Como e por que surgiu

O PCI-DSS (Payment Card Industry Data Security Standard) nasceu em 2004/2006 quando as principais bandeiras de cartão — Visa, Mastercard, American Express, Discover e JCB — perceberam que cada uma tinha seu próprio programa de segurança, e comerciantes que aceitavam múltiplas bandeiras precisavam seguir requisitos diferentes e conflitantes para a mesma transação. As bandeiras se uniram e criaram o PCI Security Standards Council (PCI SSC), unificando essas exigências em um único padrão. A motivação prática por trás disso foi a onda de vazamentos de dados de cartão do início dos anos 2000, como o caso da TJX Companies, que expôs dezenas de milhões de números de cartão.

Para que serve

O PCI-DSS define 12 requisitos técnicos e operacionais obrigatórios para qualquer organização que armazena, processa ou transmite dados de titular de cartão (PAN — Primary Account Number, dados da trilha magnética, CVV, etc.):

Requisito	Resumo
1–2	Firewall configurado e sem senhas padrão de fabricante
3–4	Proteção de dados de cartão armazenados e em trânsito (criptografia)
5–6	Antivírus/anti-malware e desenvolvimento seguro de aplicações
7–8	Controle de acesso por necessidade de uso e autenticação forte
9	Restrição de acesso físico aos dados
10	Rastreamento e monitoramento de todo acesso
11	Testes de segurança regulares (scans de vulnerabilidade, pentest)
12	Política de segurança da informação formalizada

Diferente das normas ISO, PCI-DSS não é uma certificação opcional — é uma exigência contratual imposta pelas bandeiras e adquirentes. O nível de rigor da validação (SAQ auto-declarado ou auditoria formal por um QSA — Qualified Security Assessor) depende do volume de transações processadas por ano.

ISO/IEC 27001: gestão de segurança da informação

Como e por que surgiu

A ISO/IEC 27001 tem origem no BS 7799, um padrão britânico de segurança da informação publicado pela BSI (British Standards Institution) em 1995. A parte 2 desse padrão, focada em como implementar um sistema de gestão, foi adotada pela ISO em 2005 e se tornou a ISO/IEC 27001. Passou por revisões relevantes em 2013 e na versão mais atual, 2022, que reorganizou os controles do Anexo A.

Para que serve

Diferente da PCI-DSS, que é prescritiva e focada em um tipo específico de dado (cartão), a ISO 27001 é um framework de gestão, agnóstico ao tipo de negócio. Ela não diz exatamente "use criptografia AES-256"; ela exige que a organização estabeleça um SGSI (Sistema de Gestão de Segurança da Informação) — um ciclo contínuo de identificar riscos, aplicar controles proporcionais a esses riscos, e melhorar com o tempo (o clássico PDCA: Plan-Do-Check-Act).

Os controles de referência ficam no Anexo A (hoje alinhado à ISO/IEC 27002), organizados em quatro temas:

Tema do Anexo A	Exemplos de controle
Organizacional	Política de segurança, gestão de fornecedores, resposta a incidentes
Pessoas	Contratação, treinamento, encerramento de acesso
Físico	Controle de acesso a datacenters e escritórios
Tecnológico	Criptografia, backup, segmentação de rede, logging

A certificação ISO 27001 é feita por um organismo certificador acreditado, com auditoria de recertificação a cada três anos e auditorias de manutenção anuais.

ISO/IEC 27701: gestão de privacidade

Como e por que surgiu

Publicada em 2019, a ISO/IEC 27701 surgiu da pressão crescente por conformidade com leis de proteção de dados como o GDPR europeu e, no Brasil, a LGPD. Antes dela, empresas certificadas em ISO 27001 tinham uma base sólida de segurança, mas nada que endereçasse formalmente obrigações específicas de privacidade — como direitos do titular dos dados, base legal para tratamento, ou o papel de controlador versus operador.

Na versão original de 2019, a norma nasceu desenhada como extensão da ISO 27001/27002: só era possível certificar o PIMS (Privacy Information Management System) como um adendo de escopo sobre um SGSI já certificado. A revisão de 2026 muda esse desenho — a ISO 27701 passa a ser publicada como norma independente, com sua própria estrutura de requisitos, deixando de depender de uma certificação 27001 prévia ou simultânea.

Para que serve

Com a revisão 2026, a ISO 27701 não depende mais da ISO 27001 para ser certificada — uma organização pode implementar e certificar seu Sistema de Gestão de Privacidade da Informação (PIMS) de forma autônoma, sem precisar ter ou estar implementando a 27001 junto. Na prática, porém, as duas normas continuam extremamente complementares: como a 27701 herda boa parte da estrutura de gestão de riscos e controles da 27001/27002, empresas que já têm um SGSI implementado aproveitam grande parte do trabalho ao adicionar a camada de privacidade — só que agora essa combinação é uma opção estratégica, não um pré-requisito obrigatório.

Ela adiciona controles como:

Identificação da base legal para cada tratamento de dado pessoal
Processos para atender direitos do titular (acesso, correção, exclusão, portabilidade)
Distinção clara de responsabilidades entre PII Controller (quem decide a finalidade do tratamento) e PII Processor (quem trata em nome de outro)
Avaliação de impacto à privacidade (equivalente ao DPIA do GDPR ou RIPD da LGPD)
Gestão de consentimento e de transferência internacional de dados

Para uma empresa brasileira, a ISO 27701 funciona como evidência estruturada de conformidade com a LGPD, mesmo a norma não citando a lei diretamente — os controles mapeiam de forma bem próxima.

ISO/IEC 27018: privacidade em nuvem pública

Como e por que surgiu

Publicada em 2014 (revisada em 2019), a ISO/IEC 27018 respondeu a uma lacuna específica: a ISO 27002 tinha controles genéricos de segurança, mas nenhum tratava da situação particular de um provedor de nuvem pública que processa dados pessoais em nome de seus clientes — ou seja, quando o provedor é o processor e o cliente é o controller. A adoção em massa de AWS, Azure e Google Cloud ao longo dos anos 2010 tornou essa lacuna crítica: sem um padrão específico, cada contrato de nuvem tratava a proteção de PII de um jeito diferente.

Para que serve

A ISO 27018 é um código de prática, não uma norma certificável por si só — ela estende os controles da ISO 27002 com diretrizes adicionais voltadas especificamente a provedores de nuvem que atuam como processadores de PII. Entre os pontos que ela cobre:

O provedor de nuvem só pode usar os dados pessoais do cliente para os fins contratados, nunca para publicidade própria sem consentimento explícito
Transparência sobre em quais países/subcontratados os dados são processados
Notificação ao cliente em caso de acesso não autorizado ou solicitação legal de terceiros
Direito do cliente de recuperar ou apagar seus dados ao encerrar o contrato

Na prática, quem busca essa certificação (normalmente combinada com a 27001, como um adendo de escopo) são os provedores de nuvem, SaaS e serviços de hospedagem — não a empresa cliente final. Se sua empresa contrata AWS ou Azure, o que você quer ver é o certificado ISO 27018 deles, como evidência de que tratam os dados dos seus usuários com o cuidado esperado.

Como as quatro normas se relacionam

	PCI-DSS	ISO 27001	ISO 27701	ISO 27018
O que protege	Dados de cartão de pagamento	Ativos de informação em geral	Dados pessoais (PII) em geral	Dados pessoais (PII) especificamente em nuvem pública
Depende de outra norma?	Independente	Independente (é a base)	Independente desde a revisão 2026 (mas complementa a 27001/27002 na prática)	Sim, estende a 27002
Quem certifica/valida	QSA ou autoavaliação (SAQ)	Organismo certificador acreditado	Organismo certificador acreditado	Geralmente incluída no escopo de auditoria da 27001 do provedor
Obrigatória ou voluntária	Obrigatória por contrato com bandeiras/adquirente	Voluntária (mas cada vez mais exigida por clientes B2B)	Voluntária	Voluntária, relevante sobretudo para provedores de nuvem
Papel típico de quem certifica	Comerciante ou processador de pagamento	Qualquer organização	Controller e/ou Processor de dados pessoais	Processor de PII atuando como provedor de nuvem

Uma forma simples de visualizar a pilha: a ISO 27001 é a fundação (gestão de segurança da informação como um todo). A ISO 27701 pode rodar de forma independente desde a revisão 2026, mas continua se apoiando conceitualmente na 27001/27002 para adicionar controles de privacidade — a maioria das empresas ainda opta por certificar as duas juntas por causa da sobreposição de controles. A ISO 27018 se apoia na 27002 para o caso específico de provedores de nuvem. E a PCI-DSS roda em paralelo, como uma trilha independente e obrigatória sempre que há dado de cartão envolvido — mesmo que a empresa já tenha as três certificações ISO.

Quem precisa de cada uma

Perfil da empresa	Normas relevantes
E-commerce que processa pagamento com cartão	PCI-DSS obrigatório; ISO 27001 recomendada para maturidade geral
SaaS B2B que lida com dados de clientes corporativos	ISO 27001 quase sempre exigida em processo de venda enterprise
Empresa que trata dados pessoais de usuários finais (qualquer app com cadastro)	ISO 27701 relevante para evidenciar conformidade com LGPD/GDPR
Provedor de nuvem, hosting ou infraestrutura como serviço	ISO 27018 relevante como diferencial de confiança para clientes
Fintech ou gateway de pagamento	Todas as quatro, dependendo do escopo de dados e de nuvem usada

Exemplo prático: um SaaS de e-commerce

Imagine uma plataforma de e-commerce SaaS, hospedada em nuvem pública, que processa pagamento via cartão e armazena dados de clientes dos seus lojistas.

PCI-DSS: obrigatório porque a plataforma processa transações de cartão. Mesmo se o processamento do cartão em si for terceirizado a um gateway (reduzindo o escopo via tokenização), a plataforma ainda precisa validar conformidade com os requisitos que sobram no seu ambiente.
ISO 27001: a plataforma implementa um SGSI cobrindo toda a operação — desenvolvimento, infraestrutura, RH, fornecedores. Vira pré-requisito comum em propostas comerciais de clientes maiores.
ISO 27701: como a plataforma trata dados pessoais de consumidores finais (nome, endereço, e-mail) em nome dos lojistas, ela atua como Processor. A extensão de privacidade formaliza como esses dados são protegidos e como direitos do titular são atendidos.
ISO 27018: se essa plataforma, além de SaaS, também oferece infraestrutura para terceiros hospedarem aplicações (um cenário IaaS/PaaS), essa certificação vira relevante para o próprio provedor de nuvem que ela usa (AWS/Azure/GCP) — e é isso que ela deve exigir contratualmente do fornecedor.

O ponto central: as quatro normas não competem entre si — cada uma cobre uma fatia diferente do mesmo problema (proteger dado sensível), e a sobreposição de controles entre elas (gestão de acesso, criptografia, resposta a incidente) significa que implementar a ISO 27001 primeiro reduz bastante o esforço para as demais.

Boas práticas

Comece pela ISO 27001 se ainda não tem nenhuma base de governança de segurança — mesmo com a 27701 sendo independente desde 2026, a sobreposição de controles faz o SGSI da 27001 acelerar bastante a implementação do PIMS
Não trate PCI-DSS como algo à parte — mapeie os controles que já existem no SGSI (controle de acesso, logging, resposta a incidente) contra os 12 requisitos, a sobreposição costuma passar de 60%
Reduza o escopo de PCI-DSS com tokenização — delegar a captura e armazenamento do cartão a um gateway (Stripe, Adyen, etc.) reduz drasticamente o que precisa ser auditado
Peça o certificado ISO 27018 do seu provedor de nuvem, não tente certificar sua própria empresa nessa norma a menos que você também seja um provedor de infraestrutura
Mantenha uma matriz de controles cruzada — uma planilha simples relacionando cada controle das quatro normas evita retrabalho em auditorias e evidências duplicadas

Perguntas frequentes

Pergunta	Resposta
Preciso ser ISO 27001 antes de fazer ISO 27701?	Não mais — desde a revisão 2026 a ISO 27701 é uma norma independente. Antes disso, a certificação era emitida como extensão de escopo de uma 27001 já certificada ou em processo de certificação conjunta; hoje isso é uma opção estratégica, não um requisito
PCI-DSS substitui a ISO 27001?	Não — PCI-DSS cobre só dado de cartão; ISO 27001 cobre segurança da informação como um todo
Minha empresa pequena precisa de tudo isso?	Depende do que ela processa. Uma loja pequena que usa um gateway de pagamento pronto pode ter escopo de PCI-DSS mínimo (SAQ A); ISO 27701/27018 só fazem sentido se há tratamento relevante de PII ou oferta de infraestrutura
ISO 27018 é uma certificação própria?	Não isoladamente — é um código de prática auditado como extensão de escopo dentro de uma certificação ISO 27001/27002
LGPD exige ISO 27701?	Não exige formalmente, mas a norma é hoje a forma mais reconhecida de evidenciar conformidade estruturada com a lei

Conclusão

PCI-DSS, ISO 27001, ISO 27701 e ISO 27018 não são quatro auditorias concorrentes disputando o tempo do time de segurança — são camadas complementares que protegem tipos diferentes de dado sensível, com graus diferentes de obrigatoriedade. A ISO 27001 estabelece a fundação de gestão de segurança; a ISO 27701 — independente desde a revisão 2026, mas ainda fortemente complementar a ela — cobre a camada de privacidade; a ISO 27018 endereça o caso específico de provedores de nuvem tratando PII de terceiros; e a PCI-DSS roda à parte, como exigência contratual sempre que há dado de cartão envolvido.

Antes de sair atrás de todas ao mesmo tempo, mapeie qual dado sensível sua empresa realmente processa e em que papel (controller, processor, comerciante, provedor de infraestrutura) — isso já reduz bastante a lista do que de fato se aplica.

Referências

Conventional Commits: Guia Completo para Padronizar suas Mensagens de Commit

Luis Cruz — Fri, 10 Jul 2026 14:45:37 +0000

Abra o histórico de commits de qualquer projeto que já passou por várias mãos e você vai encontrar de tudo: "fix", "ajustes", "correção final", "correção final 2", "wip". Nenhuma dessas mensagens diz o que mudou, por que mudou, ou se quebra algo. O resultado prático: gerar um changelog vira trabalho manual, descobrir quando um bug foi introduzido vira arqueologia, e decidir se a próxima versão é 1.2.0 ou 2.0.0 vira palpite.

É esse o problema que o Conventional Commits resolve: uma convenção leve para escrever mensagens de commit de um jeito que tanto humanos quanto máquinas conseguem interpretar, permitindo automatizar changelog, versionamento semântico e até gatilhos de CI a partir do próprio histórico do Git.

Este artigo cobre a origem da especificação, para que ela serve, sua estrutura formal e exemplos práticos do dia a dia.

Como e por que surgiu

O Conventional Commits nasceu da observação de que vários projetos open source já usavam, de forma independente, convenções parecidas para prefixar mensagens de commit. O Angular Commit Message Guidelines é a referência mais citada como origem direta do formato. A ideia central do Angular era simples: prefixar cada commit com um tipo (feat, fix, docs...) para que uma ferramenta pudesse gerar o CHANGELOG.md automaticamente, sem depender de alguém escrever isso manualmente a cada release.

A especificação Conventional Commits 1.0.0 consolidou essa prática em um padrão formal, documentado e versionado, inspirado também no SemVer, com o qual se integra diretamente (mais sobre isso adiante). Hoje é mantida como projeto aberto em conventionalcommits.org, com traduções para várias línguas, incluindo português.

Para que serve

Necessidade	Como o Conventional Commits ajuda
Gerar changelog automaticamente	Ferramentas leem o histórico e montam o `CHANGELOG.md` sem intervenção manual
Determinar a próxima versão semântica	`fix` sugere PATCH, `feat` sugere MINOR, `BREAKING CHANGE` sugere MAJOR
Comunicar a natureza da mudança ao time	Quem revisa o PR já sabe se é bug, feature ou refatoração antes de abrir o diff
Disparar builds e pipelines automaticamente	CI pode decidir se publica um pacote, dispara um deploy ou pula uma etapa com base no tipo de commit
Facilitar contribuição em projetos abertos	Reduz a barreira para quem nunca contribuiu entender como categorizar a própria mudança

Na prática, o ganho não é estético, é que o histórico do Git passa a ser dado estruturado, não só texto livre, e dá para automatizar em cima dele.

Estrutura da mensagem

O formato básico definido pela especificação é:

<tipo>[escopo opcional]: <descrição>

[corpo opcional]

[rodapé(s) opcional(is)]

Os tipos mais usados

Tipo	Quando usar
`feat`	Nova funcionalidade (correlaciona com MINOR no SemVer)
`fix`	Correção de bug (correlaciona com PATCH no SemVer)
`docs`	Mudança apenas em documentação
`style`	Formatação, espaços, ponto e vírgula, sem mudança de lógica
`refactor`	Mudança de código que não corrige bug nem adiciona feature
`perf`	Mudança que melhora performance
`test`	Adição ou correção de testes
`build`	Mudança no sistema de build ou dependências externas
`ci`	Mudança em arquivos e scripts de CI/CD
`chore`	Tarefas de manutenção que não afetam código de produção

A especificação define oficialmente apenas feat e fix como obrigatórios para a relação com SemVer. Os demais tipos (baseados na convenção do Angular) são uma extensão amplamente adotada, mas o time pode ajustar a lista conforme a necessidade do projeto.

Exemplos práticos

Commit simples

feat: adiciona endpoint de exportação de relatórios em PDF

Commit com escopo

O escopo (entre parênteses) indica qual parte do código foi afetada:

fix(auth): corrige expiração prematura do token JWT

feat(checkout): adiciona suporte a pagamento via Pix

Commit com corpo explicando o contexto

fix(api): corrige timeout em requisições de upload grandes

O timeout estava fixo em 30s independente do tamanho do arquivo.
Agora o timeout escala proporcionalmente ao tamanho do payload,
com um teto máximo de 5 minutos.

Commit com breaking change

Uma mudança que quebra compatibilidade é sinalizada com ! após o tipo/escopo, ou com o rodapé BREAKING CHANGE: os dois podem ser usados juntos:

feat(api)!: remove suporte ao endpoint /v1/users

BREAKING CHANGE: o endpoint /v1/users foi descontinuado.
Use /v2/users, que retorna o campo `email` como obrigatório.

Esse commit, por conter BREAKING CHANGE, indica que a próxima versão deve ser um MAJOR no versionamento semântico (ex: 2.4.1 → 3.0.0), independente de conter também um feat.

Commit apenas de manutenção

chore: atualiza dependências de dev para as versões mais recentes

Múltiplos rodapés

Rodapés seguem o mesmo formato de trailers do Git (chave: valor), e podem referenciar issues, coautores ou revisores:

fix(payments): corrige arredondamento incorreto no cálculo de juros

Refs: #482
Reviewed-by: Ana Costa
Co-authored-by: João Silva <joao@example.com>

Relação com Versionamento Semântico (SemVer)

A especificação foi desenhada para mapear diretamente para as três posições do SemVer (MAJOR.MINOR.PATCH):

Tipo de commit	Impacto na versão	Exemplo
`fix`	PATCH	`1.4.2` → `1.4.3`
`feat`	MINOR	`1.4.2` → `1.5.0`
Qualquer tipo com `BREAKING CHANGE` ou `!`	MAJOR	`1.4.2` → `2.0.0`
`docs`, `style`, `chore`, `test`, etc.	Nenhum (não gera release)	—

Essa correlação é o que permite que ferramentas de release automatizem a decisão de qual versão publicar, sem que ninguém precise decidir manualmente "isso é uma minor ou uma patch?".

Ferramentas do ecossistema

Ferramenta	Função
`commitlint`	Valida no commit (via hook) se a mensagem segue o padrão
`commitizen`	CLI interativa que monta a mensagem de commit por perguntas
`semantic-release`	Automatiza versionamento e publicação de pacotes com base nos commits
`standard-version`	Gera changelog e bump de versão localmente, sem publicar
`conventional-changelog`	Biblioteca base para gerar changelogs a partir do histórico

Exemplo de hook local com commitlint

npm install --save-dev @commitlint/cli @commitlint/config-conventional

// commitlint.config.js
module.exports = { extends: ['@commitlint/config-conventional'] };

Integrando com Husky para rodar a validação em todo commit:

npx husky add .husky/commit-msg 'npx --no -- commitlint --edit "$1"'

A partir daí, um commit fora do padrão é rejeitado antes mesmo de entrar no histórico:

$ git commit -m "ajustei umas coisas"
⧗   input: ajustei umas coisas
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖ found 2 problems, 0 warnings

Boas práticas

Descrição no imperativo, minúscula, sem ponto final — ex: fix: corrige, não fix: Corrigido. ou fix: correção de
Um commit, uma mudança lógica — evite misturar feat e refactor no mesmo commit só porque tocaram os mesmos arquivos
Escopo consistente — combine com o time uma lista fixa de escopos (auth, api, ui, db) em vez de deixar livre
Corpo explica o "porquê", não o "o quê" — o diff já mostra o que mudou; o corpo do commit deve justificar a decisão
BREAKING CHANGE sempre no rodapé, em maiúsculas — é o texto que as ferramentas de automação procuram para disparar um MAJOR
Combine com commitlint no pipeline ou pre-commit hook — depender de disciplina manual do time não escala além de poucas pessoas

Troubleshooting

Problema	Causa provável	Solução
`commitlint` rejeita commit com mensagem que parece correta	Espaço faltando após os dois-pontos, ou tipo com maiúscula (`Feat:`)	Sempre `tipo: descrição`, tipo em minúsculas, um espaço após `:`
Changelog gerado não lista uma mudança importante	Commit usou tipo que não gera changelog por padrão (`chore`, `style`)	Reclassifique como `feat`/`fix` se a mudança for relevante ao usuário final
`semantic-release` não bumpou a versão MAJOR esperada	`BREAKING CHANGE` escrito errado no corpo (ex: `Breaking change:` com minúscula)	Use exatamente `BREAKING CHANGE:` maiúsculo, ou `!` após o tipo/escopo
Time reclama que o padrão é burocrático demais	Falta de ferramenta que automatize a checagem, virando esforço manual	Adicione `commitizen` para gerar a mensagem por prompt interativo, reduzindo fricção
Merge commit "genérico" polui o changelog	Merge de branch sem squash mistura vários commits não convencionais	Prefira squash merge com uma mensagem convencional única no PR

Conclusão

Conventional Commits não é sobre burocratizar o Git, é sobre transformar uma mensagem de commit em um dado que máquinas conseguem ler, sem tirar a legibilidade para humanos. O ganho aparece principalmente na escala: um projeto pequeno sobrevive com "fix bug", mas um projeto com múltiplos contribuidores, releases frequentes e changelog público sente a diferença entre montar isso manualmente ou automaticamente a cada versão.

Comece pequeno: adote feat: e fix: no seu próximo commit, adicione o commitlint como hook local, e deixe o time se acostumar antes de cobrar escopos e rodapés. Depois de validado no dia a dia, avalie ferramentas como semantic-release para automatizar versionamento e publicação por completo.

Referências

Checkov: Guia Completo de Segurança para Infraestrutura como Código

Luis Cruz — Thu, 02 Jul 2026 14:03:59 +0000

Escrever infraestrutura como código resolve o problema de reprodutibilidade, mas cria um novo risco: erros de configuração (misconfigurations) agora são versionados, replicados e revisados com a mesma pressa de qualquer outro código. Um bucket S3 público, um security group aberto para 0.0.0.0/0 ou um container rodando como root passam despercebidos em um terraform plan, porque o plan mostra o que vai mudar, não se aquilo é seguro.

É esse o problema que o Checkov resolve: análise estática de segurança (SAST) para arquivos de IaC, rodando antes do apply, direto no seu terminal, editor ou pipeline de CI/CD.

Este artigo cobre tudo para sair do zero: o que é, para quem é, como instalar, como usar no dia a dia e como integrar em um pipeline real.

O que é o Checkov

O Checkov é uma ferramenta open source de policy-as-code criada pela Bridgecrew (adquirida pela Palo Alto Networks) que analisa arquivos de infraestrutura como código em busca de erros de configuração de segurança, conformidade e boas práticas sem precisar aplicar nada na nuvem.

Ele funciona construindo um grafo de recursos a partir do seu código (Terraform, CloudFormation, Kubernetes, etc.), entendendo as relações entre eles, e comparando cada recurso contra centenas de checks pré-definidos como "bucket S3 não deve permitir acesso público" ou "security group não deve expor a porta 22 para a internet".

Principais características:

Mais de 1.000 checks embutidos, cobrindo AWS, Azure, GCP e boas práticas gerais
Suporte a múltiplas linguagens de IaC: Terraform, CloudFormation, Kubernetes, Helm, Dockerfile, Serverless Framework, ARM templates, Bicep e mais
Checks escritos em Python ou YAML - customizáveis e extensíveis
Análise baseada em grafo (entende variáveis, módulos e referências entre recursos, não só regex)
Gratuito e open source (com uma camada paga opcional via Prisma Cloud para políticas centralizadas)

Para quem é o Checkov

Perfil	Como usa o Checkov
Devs que escrevem Terraform/Helm	Roda local antes do commit, corrige o erro antes do PR
Times de DevOps/Platform	Integra no pipeline de CI/CD como gate obrigatório
Security Engineers / AppSec	Define políticas customizadas e audita compliance (CIS, PCI-DSS, SOC2)
SRE	Garante que ambientes de produção seguem baseline de segurança antes do deploy
Estudantes de Cloud/DevSecOps	Aprende boas práticas de segurança na prática, com feedback imediato

Se você já usa terraform validate ou terraform plan no seu fluxo, o Checkov entra como uma etapa adicional, ele não substitui essas ferramentas, complementa: elas garantem que o código é sintaticamente correto, o Checkov garante que ele é seguro.

Pré-requisitos

Python 3.8+ instalado
pip disponível
Um projeto de IaC para testar (vamos usar Terraform no exemplo)

Verifique sua versão do Python:

python3 --version

1. Instalação

O Checkov pode ser instalado de várias formas. As mais comuns:

# Via pip (recomendado)
pip install checkov

# Via pipx (isola em ambiente virtual próprio)
pipx install checkov

# Via Homebrew (macOS/Linux)
brew install checkov

# Via Docker (sem instalar nada localmente)
docker pull bridgecrew/checkov

Confirme a instalação:

checkov --version

No Debian/Ubuntu, se pip install checkov reclamar de ambiente gerenciado externamente (PEP 668), use pipx install checkov ou crie um virtualenv (python3 -m venv .venv && source .venv/bin/activate).

2. Primeiro scan: encontrando problemas reais

Vamos criar um exemplo propositalmente inseguro para ver o Checkov em ação.

mkdir -p ~/checkov-demo && cd ~/checkov-demo

Crie o arquivo main.tf:

resource "aws_s3_bucket" "data" {
  bucket = "minha-empresa-dados-2026"
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Security group da aplicacao web"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_db_instance" "main" {
  identifier        = "app-db"
  engine            = "mysql"
  instance_class    = "db.t3.micro"
  allocated_storage = 20
  username          = "admin"
  password          = "SenhaSuperSecreta123"
  publicly_accessible = true
  skip_final_snapshot = true
}

Rode o scan apontando para o diretório:

checkov -d .

O Checkov vai listar dezenas de checks, com resultado PASSED ou FAILED para cada recurso. Entre os FAILED esperados neste exemplo:

CKV_AWS_24 — Security group permite SSH (porta 22) aberto para 0.0.0.0/0
CKV_AWS_260 — Security group permite HTTP aberto para o mundo sem necessidade
CKV_AWS_16 — Instância RDS sem criptografia habilitada
CKV_AWS_161 — Instância RDS não força autenticação via IAM
CKV_AWS_129 — RDS sem logging de auditoria habilitado
CKV_SECRET_2 — Senha em texto plano detectada no código (password = "SenhaSuperSecreta123")
CKV2_AWS_6 — Bucket S3 sem política de bloqueio de acesso público
CKV_AWS_18 — Bucket S3 sem access logging habilitado

Cada linha do resultado mostra o ID do check, uma descrição, o arquivo e a linha exata do recurso problemático — dá para ir direto ao ponto.

3. Entendendo o output

Formato padrão (texto colorido no terminal):

Check: CKV_AWS_24: "Ensure no security groups allow ingress from 0.0.0.0:0 to port 22"
    FAILED for resource: aws_security_group.web
    File: /main.tf:6-15
    Guide: https://docs.bridgecrew.io/docs/networking_1

Para integrações e leitura por outras ferramentas, use formatos estruturados:

# JSON — útil para parsing programático
checkov -d . -o json

# JUnit XML — direto em relatórios de CI (GitLab, Jenkins, Azure DevOps)
checkov -d . -o junitxml

# SARIF — formato padrão para GitHub Code Scanning
checkov -d . -o sarif

# Múltiplos formatos ao mesmo tempo, salvando em arquivos
checkov -d . -o cli -o json --output-file-path console,results.json

O exit code também importa em automação: por padrão o Checkov retorna 1 se houver qualquer check FAILED, o que quebra o pipeline — é esse comportamento que você quer como gate de segurança.

4. Corrigindo os problemas

Ajustando o main.tf para resolver os principais achados:

resource "aws_s3_bucket" "data" {
  bucket = "minha-empresa-dados-2026"
}

resource "aws_s3_bucket_public_access_block" "data" {
  bucket                  = aws_s3_bucket.data.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Security group da aplicacao web"

  ingress {
    description = "HTTPS publico"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH restrito a VPN corporativa"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
  }
}

resource "aws_db_instance" "main" {
  identifier           = "app-db"
  engine                = "mysql"
  instance_class        = "db.t3.micro"
  allocated_storage     = 20
  username              = "admin"
  manage_master_user_password = true
  storage_encrypted     = true
  publicly_accessible   = false
  skip_final_snapshot   = false
  deletion_protection   = true
}

Principais mudanças: bucket com public access block e criptografia; security group sem SSH aberto ao mundo; RDS privado, criptografado, com senha gerenciada pelo Secrets Manager (manage_master_user_password) em vez de hardcoded.

Rode o scan de novo - o número de FAILED deve cair drasticamente:

checkov -d . --compact

5. Suprimindo checks (quando necessário)

Nem todo FAILED é um bug, às vezes é uma decisão consciente (ex: um bucket público de assets estáticos de um site). Para esses casos, suprima o check pontualmente, sempre com justificativa:

resource "aws_s3_bucket" "site_publico" {
  bucket = "meu-site-assets-publicos"

  # checkov:skip=CKV2_AWS_6:Bucket serve assets estaticos publicos por design (CDN de imagens do site)
}

Para suprimir vários checks em um recurso:

  #checkov:skip=CKV_AWS_18:Logging desnecessario neste bucket de teste
  #checkov:skip=CKV_AWS_21:Versionamento desnecessario neste bucket de teste

Também é possível ignorar checks globalmente via linha de comando — use com cautela, pois afeta o repositório inteiro:

checkov -d . --skip-check CKV_AWS_8,CKV_AWS_79

Prefira sempre o #checkov:skip inline no código: fica documentado, versionado e visível em code review, diferente de uma flag de CLI que vive escondida em um script de pipeline.

6. Criando um baseline (para projetos legados)

Ao rodar o Checkov pela primeira vez em um projeto grande e antigo, é comum encontrar centenas de findings acumulados, inviável corrigir tudo de uma vez sem travar o time. A solução é gerar um baseline: um snapshot dos problemas atuais, para que o pipeline falhe só em novos problemas introduzidos daqui pra frente.

# Gera o baseline com o estado atual (findings existentes)
checkov -d . --create-baseline

# Nas próximas execuções, compara contra o baseline
checkov -d . --baseline .checkov.baseline

Isso permite adotar segurança em pipelines de forma incremental, sem bloquear o time por dívida técnica pré-existente.

7. Integração com CI/CD (GitHub Actions)

Exemplo de workflow que roda o Checkov em todo PR que altera arquivos Terraform:

name: Checkov IaC Security Scan

on:
  pull_request:
    paths:
      - '**.tf'

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: .
          framework: terraform
          output_format: sarif
          output_file_path: results.sarif
          soft_fail: false

      - name: Upload SARIF para GitHub Code Scanning
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: results.sarif

Com soft_fail: false, o job falha e bloqueia o merge se houver check crítico reprovado, esse é o comportamento recomendado para branches protegidas. Use soft_fail: true apenas durante a fase de adoção gradual.

Integração como pre-commit hook

Para pegar problemas antes mesmo do push, adicione ao .pre-commit-config.yaml:

repos:
  - repo: https://github.com/bridgecrewio/checkov.git
    rev: '3.2.0'
    hooks:
      - id: checkov
        args: ["--compact", "--quiet"]

pip install pre-commit
pre-commit install

8. Checks customizados

Quando as regras padrão não cobrem uma política interna da empresa (ex: "toda instância EC2 deve ter a tag cost-center"), é possível escrever checks próprios.

Custom check em Python:

from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck
from checkov.common.models.enums import CheckCategories, CheckResult


class EnsureCostCenterTag(BaseResourceCheck):
    def __init__(self):
        name = "Ensure EC2 instances have a cost-center tag"
        id = "CKV_CUSTOM_1"
        supported_resources = ["aws_instance"]
        categories = [CheckCategories.GENERAL_SECURITY]
        super().__init__(name=name, id=id,
                          categories=categories,
                          supported_resources=supported_resources)

    def scan_resource_conf(self, conf):
        tags = conf.get("tags", [{}])[0]
        if isinstance(tags, dict) and "cost-center" in tags:
            return CheckResult.PASSED
        return CheckResult.FAILED


check = EnsureCostCenterTag()

checkov -d . --external-checks-dir ./custom_checks

Custom check em YAML (mais simples, sem precisar de Python):

metadata:
  id: "CKV_CUSTOM_2"
  name: "Ensure S3 bucket name follows naming convention"
  category: "GENERAL_SECURITY"
scope:
  provider: "aws"
definition:
  and:
    - cond_type: "attribute"
      resource_types:
        - "aws_s3_bucket"
      attribute: "bucket"
      operator: "starts_with"
      value: "empresa-"

9. Referência rápida de flags úteis

Flag	O que faz
`-d <dir>`	Escaneia todo o diretório recursivamente
`-f <file>`	Escaneia um arquivo específico
`--framework terraform`	Limita o scan a um framework (terraform, kubernetes, dockerfile, etc.)
`--check CKV_AWS_24`	Roda apenas checks específicos
`--skip-check CKV_AWS_8`	Ignora checks específicos globalmente
`--compact`	Output resumido, sem detalhes de cada check `PASSED`
`--quiet`	Mostra só os `FAILED`
`--soft-fail`	Não retorna exit code de erro mesmo com findings
`-o json\	junitxml\
{% raw %}`--create-baseline`	Gera baseline com findings atuais
`--external-checks-dir`	Carrega checks customizados

10. Checkov vs. outras ferramentas

Ferramenta	Foco	Linguagens suportadas	Diferencial
Checkov	IaC security + compliance	Terraform, CFN, K8s, Helm, Dockerfile, Bicep, Serverless	Maior cobertura de frameworks, análise por grafo
tfsec	Terraform security	Apenas Terraform	Muito rápido, focado só em Terraform (hoje integrado ao Trivy)
Terrascan	IaC security + compliance	Terraform, K8s, Helm, CFN	Motor baseado em OPA/Rego
Trivy	Vulnerabilidades + IaC + containers	IaC, imagens de container, filesystems	Escopo mais amplo (inclui CVEs de pacotes), não só IaC

Na prática, muitos times usam Checkov + Trivy juntos: Checkov para configuração de IaC, Trivy para vulnerabilidades de imagens de container e dependências. Eles não são mutuamente exclusivos.

Boas práticas

Rode local antes do commit — pre-commit hook pega o problema em segundos, antes de virar um PR
Trave a versão do Checkov no pipeline (checkov==3.2.0) para evitar que uma nova versão introduza checks que quebrem o build sem aviso
Use baseline em projetos legados — não tente corrigir 300 findings de uma vez, adote incrementalmente
Documente todo skip — #checkov:skip sempre com motivo, nunca silencioso
Combine com scanning de secrets — o Checkov já detecta segredos em texto plano (CKV_SECRET_*), mas para repositórios grandes considere complementar com gitleaks no histórico de commits
Trate achados críticos como bloqueadores — soft_fail é aceitável só durante a fase de adoção, não como estado permanente

Troubleshooting

Problema	Causa provável	Solução
`error: externally-managed-environment` no `pip install`	PEP 668 em distros recentes (Debian 12+, Ubuntu 23.04+)	Use `pipx install checkov` ou um virtualenv
Checkov não encontra nenhum recurso	Diretório errado ou `.tf` com erro de sintaxe	Rode `terraform validate` antes; confirme o `-d` aponta pro diretório certo
Check falha mas parece um falso positivo	Contexto que o Checkov não enxerga (ex: recurso protegido por outra camada)	Suprima com `#checkov:skip` e justificativa, não desabilite globalmente
Pipeline trava sempre no primeiro scan	Débito técnico acumulado no repositório	Gere baseline com `--create-baseline` e adote incrementalmente
Scan muito lento em monorepo grande	Escaneando diretórios desnecessários (`.terraform/`, `node_modules/`)	Use `--skip-path` para excluir pastas irrelevantes

Conclusão

O Checkov transforma segurança de infraestrutura de uma revisão manual — que depende de alguém lembrar de checar security groups e permissões — em um portão automatizado que roda em segundos, local ou no pipeline. Ele não substitui uma revisão de arquitetura ou um pentest, mas elimina a categoria inteira de erros básicos e repetitivos que hoje são a causa mais comum de incidentes de cloud: bucket público, credencial hardcoded, porta aberta para o mundo.

Comece pequeno: rode checkov -d . no seu projeto Terraform atual, veja o que aparece, gere um baseline se for muito, e adicione como pre-commit hook. Depois de validado localmente, leve para o CI/CD como gate obrigatório em PRs.

Referências

AWS - Projeto Cloud: Implementação IAM

Luis Cruz — Tue, 02 Jun 2026 19:30:21 +0000

Neste projeto prático você vai implementar um ambiente IAM completo na AWS: criar grupos com permissões específicas, migrar usuários via script automatizado, configurar MFA obrigatório e aplicar uma política de senhas forte — tudo seguindo as boas práticas de segurança da AWS.

O projeto está dividido em duas partes:

Parte 1: Criação de grupos, preparação do CSV e automação da criação de usuários
Parte 2: Boas práticas de segurança — MFA, política de senhas e validação de acesso

Pré-requisitos

Acesso ao AWS Console com permissões de administrador
Arquivo CSV com os dados dos usuários (formato explicado abaixo)

Parte 1 — Criação e Migração de Usuários

Passo 1 — Criar os Grupos IAM

No AWS Console, acesse IAM → User groups → Create group e crie os seguintes grupos:

Grupo	Perfil
`CloudAdmin`	Administradores da conta AWS
`LinuxAdmin`	Administradores de servidores Linux
`RedesAdmin`	Administradores de rede
`DBA`	Administradores de banco de dados
`Estagiarios`	Acesso limitado para estagiários

Nomes de grupos suportam até 128 caracteres, são únicos por conta e não diferenciam maiúsculas de minúsculas.

Passo 2 — Preparar o arquivo CSV

O script espera um arquivo CSV com exatamente três colunas: usuarios, grupo e senha.

Se você tiver uma planilha Excel com os dados dos usuários, faça os seguintes ajustes antes de exportar:

Renomeie a coluna de e-mails para usuarios e remova o domínio (ex: remova @empresa.com usando Localizar e Substituir)
Renomeie a coluna de equipes para grupo e ajuste os valores para bater exatamente com os nomes dos grupos criados na AWS
Adicione a coluna senha com uma senha padrão inicial (ex: AlterarSenha@123!)
Salve como CSV separado por vírgula (UTF-8)

O arquivo final deve ter este formato:

usuarios,grupo,senha
joao.silva,LinuxAdmin,AlterarSenha@123!
maria.souza,DBA,AlterarSenha@123!
pedro.lima,Estagiarios,AlterarSenha@123!
ana.costa,RedesAdmin,AlterarSenha@123!
carlos.melo,CloudAdmin,AlterarSenha@123!

Dica: Para validar o processo, comece com 4 ou 5 usuários antes de rodar o arquivo completo.

Passo 3 — O script de criação de usuários

Salve o conteúdo abaixo como aws-iam-cria-usuario.sh:

#!/bin/bash
# Propósito:   Automatiza a criação de usuários na AWS
# Utilização:  ./aws-iam-cria-usuario.sh <arquivo.csv>
# Formato CSV: usuarios,grupo,senha
# Autor:       Luis Cruz
# ------------------------------------------

INPUT=$1
OLDIFS=$IFS
IFS=',;'

[ ! -f "$INPUT" ] && { echo "$INPUT arquivo não encontrado"; exit 99; }

command -v dos2unix >/dev/null || {
  echo "Utilitário dos2unix não encontrado. Instale com: sudo yum install dos2unix -y"
  exit 1
}

dos2unix "$INPUT"

while read -r usuario grupo senha || [ -n "$usuario" ]; do
  if [ "$usuario" != "usuarios" ]; then
    echo "──────────────────────────────────────"
    echo "Criando: $usuario | Grupo: $grupo"

    aws iam create-user --user-name "$usuario"

    aws iam create-login-profile \
      --password-reset-required \
      --user-name "$usuario" \
      --password "$senha"

    aws iam add-user-to-group \
      --group-name "$grupo" \
      --user-name "$usuario"

    echo "✓ $usuario criado com sucesso"
  fi
done < "$INPUT"

IFS=$OLDIFS
echo ""
echo "Migração concluída."

O script:

Valida se o arquivo CSV foi informado e existe
Converte o arquivo com dos2unix (necessário se criado no Windows)
Lê cada linha ignorando o cabeçalho
Cria o usuário IAM, define a senha inicial com troca obrigatória no primeiro acesso e adiciona ao grupo

Passo 4 — Executar no AWS CloudShell

O AWS CloudShell é um terminal no próprio console da AWS com AWS CLI já configurada. Acesse pelo ícone de terminal no menu superior do console.

Instalar o dos2unix:

sudo yum install dos2unix -y

Fazer upload dos arquivos via Actions → Upload file:

aws-iam-cria-usuario.sh
usuarios.csv

Preparar e executar:

# verificar os arquivos enviados
ls -la

# tornar o script executável
chmod +x aws-iam-cria-usuario.sh

# verificar o conteúdo do CSV
cat usuarios.csv

# executar
./aws-iam-cria-usuario.sh usuarios.csv

Passo 5 — Validar os usuários criados

No console, acesse IAM → Users e confirme que os usuários foram criados e estão nos grupos corretos.

Ou via CLI:

# listar todos os usuários
aws iam list-users --output table

# verificar grupos de um usuário
aws iam list-groups-for-user --user-name joao.silva

# listar usuários de um grupo
aws iam get-group --group-name DBA --output table

Passo 6 — Permitir troca de senha no primeiro acesso

Antes de testar o login com os usuários criados, anexe a política IAMUserChangePassword a todos os grupos.

Acesse IAM → User groups → [grupo] → Permissions → Add permissions → Attach policies, filtre por IAM e adicione IAMUserChangePassword.

Repita para todos os grupos.

Testando o acesso (Passo a passo)

Acesse IAM → Dashboard e copie a URL de login da conta
Abra uma aba anônima no navegador e acesse com a URL copiada
Faça login com um dos usuários criados (ex: adolfo.carlos, grupo DBA, senha AlterarSenha@123!)
Troque a senha quando solicitado
Tente acessar o DynamoDB e criar uma tabela → o acesso deve ser negado, pois o grupo DBA tem apenas AmazonRDSFullAccess

Esse teste confirma que o princípio do mínimo privilégio está funcionando corretamente.

Parte 2 — Boas Práticas de Segurança

Passo 1 — Habilitar MFA no usuário Root

O usuário root é a identidade mais poderosa da conta AWS. Proteja-o primeiro.

Acesse o console com o usuário root
Clique no nome da conta → Security Credentials
Em Multi-factor authentication (MFA) → Assign MFA device
Escolha Authenticator app (ex: Google Authenticator ou Authy)
Escaneie o QR Code com o aplicativo
Informe dois tokens consecutivos para confirmar

A partir de agora, além de usuário e senha, o login do root exigirá o token do autenticador.

Passo 2 — Criar e aplicar a política EnforceMFAPolicy

Esta política bloqueia qualquer acesso a recursos da AWS enquanto o usuário não tiver o MFA ativo.

Acesse IAM → Policies → Create policy → JSON, remova o conteúdo existente e cole:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowViewAccountInfo",
      "Effect": "Allow",
      "Action": [
        "iam:GetAccountPasswordPolicy",
        "iam:ListVirtualMFADevices"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowManageOwnVirtualMFADevice",
      "Effect": "Allow",
      "Action": [
        "iam:CreateVirtualMFADevice"
      ],
      "Resource": "arn:aws:iam::*:mfa/*"
    },
    {
      "Sid": "AllowManageOwnUserMFA",
      "Effect": "Allow",
      "Action": [
        "iam:DeactivateMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ResyncMFADevice"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "DenyAllExceptListedIfNoMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Clique em Next → Next e defina o nome como EnforceMFAPolicy.

Anexar a política em todos os grupos de uma vez:

Acesse IAM → Policies → EnforceMFAPolicy → Entities attached → Attach → Filter: User groups → selecione todos os grupos → Attach policy.

Passo 3 — Configurar política de senhas da conta

Acesse IAM → Account settings → Password policy → Edit → Custom e ative:

Configuração
Letra maiúscula (A-Z)	✅
Letra minúscula (a-z)	✅
Número (0-9)	✅
Caractere especial `! @ # $ % ...`	✅
Permitir que usuários troquem a própria senha	✅
Impedir reutilização de senhas	✅

Clique em Save changes.

Passo 4 — Testar o bloqueio por MFA

Acesse IAM → Dashboard e copie a URL de login
Abra uma aba anônima e faça login com um usuário que não tem MFA configurado (ex: alda.lage, grupo CloudAdmin)
Tente acessar o IAM → o acesso será negado com erro de permissão
Isso confirma que a EnforceMFAPolicy está funcionando

Ativando o MFA como usuário:

Clique no nome do usuário no canto superior direito → Security Credentials
Em MFA device → Assign MFA device → Authenticator app
Escaneie o QR Code e informe dois tokens consecutivos
Faça Logoff → Login
Teste novamente o acesso — agora deve funcionar normalmente

Resumo do que foi implementado

Configuração	Status
Grupos IAM com permissões específicas	✅
Usuários criados via script automatizado	✅
Troca de senha obrigatória no primeiro acesso	✅
MFA habilitado no usuário root	✅
EnforceMFAPolicy aplicada em todos os grupos	✅
Política de senhas forte na conta	✅

Referências

See you later 🤘🏻

Automatizando a Migração de Usuários e o Gerenciamento de IAM na AWS

Luis Cruz — Tue, 02 Jun 2026 18:51:49 +0000

Migrar 100 usuários manualmente no console da AWS é lento, suscetível a erros e impossível de auditar com precisão. Neste artigo você vai ver como automatizar esse processo usando AWS CLI e Shell Script direto no AWS CloudShell — sem instalar nada localmente.

O resultado final: usuários criados, alocados nos grupos corretos e com MFA obrigatório, tudo em minutos.

O que é o IAM?

O AWS Identity and Access Management (IAM) é o serviço que controla quem pode acessar os recursos da sua conta AWS e o que cada pessoa ou serviço pode fazer.

Com o IAM você gerencia:

Conceito	Descrição
Usuário	Identidade individual com credenciais próprias
Grupo	Conjunto de usuários que compartilham as mesmas permissões
Política	Documento JSON que define o que é permitido ou negado
Role	Identidade temporária assumida por serviços ou usuários

A boa prática é nunca conceder permissões diretamente a um usuário — sempre use grupos.

Visão geral da solução

O fluxo é simples:

Criar os grupos IAM no console
Montar um arquivo CSV com os dados dos usuários
Rodar um shell script no CloudShell que lê o CSV e cria tudo automaticamente
Aplicar a política de MFA obrigatório nos grupos

Passo 1 — Criar os Grupos IAM

Antes de importar os usuários, os grupos precisam existir.

No AWS Console, acesse IAM → User groups → Create group e crie um grupo para cada perfil do seu ambiente. Neste exemplo usaremos:

RedesAdmin — administradores de rede
LinuxAdmin — administradores de servidores Linux
DBA — administradores de banco de dados
Estagiarios — acesso limitado para estagiários

Nomes de grupos suportam até 128 caracteres (letras, números e + = , . @ _ -), são únicos por conta e não diferenciam maiúsculas de minúsculas.

Passo 2 — Montar o arquivo CSV

Crie uma planilha com os dados dos usuários e salve como CSV separado por vírgula (UTF-8). O arquivo deve ter exatamente três colunas: Username, Group e Password.

Username,Group,Password
joao.silva,LinuxAdmin,Senha@2024!
maria.souza,DBA,Senha@2024!
pedro.lima,Estagiarios,Senha@2024!
ana.costa,RedesAdmin,Senha@2024!
carlos.melo,LinuxAdmin,Senha@2024!

Algumas observações importantes:

O valor em Group deve corresponder exatamente ao nome do grupo criado no Passo 1
Use senhas que atendam à política da conta AWS (mínimo 8 caracteres, maiúsculas, minúsculas, números e símbolos)
Se o arquivo foi criado no Excel (Windows), salve como CSV UTF-8 — o script vai precisar do dos2unix para converter os caracteres de fim de linha

Passo 3 — O script de criação de usuários

Este é o script que lê o CSV e cria cada usuário no IAM. Salve-o como criar-usuarios-iam.sh:

#!/bin/bash

# Valida se o arquivo CSV foi informado
if [ -z "$1" ]; then
  echo "Uso: $0 <arquivo.csv>"
  exit 1
fi

CSV_FILE="$1"

# Ignora o cabeçalho e lê linha por linha
tail -n +2 "$CSV_FILE" | while IFS=',' read -r USERNAME GROUP PASSWORD; do

  # Remove espaços e caracteres de retorno de carro (Windows)
  USERNAME=$(echo "$USERNAME" | tr -d '[:space:]\r')
  GROUP=$(echo "$GROUP"       | tr -d '[:space:]\r')
  PASSWORD=$(echo "$PASSWORD" | tr -d '\r')

  echo "──────────────────────────────────────"
  echo "Criando usuário: $USERNAME | Grupo: $GROUP"

  # Cria o usuário com acesso ao console
  aws iam create-user --user-name "$USERNAME"

  # Define a senha inicial e exige troca no primeiro login
  aws iam create-login-profile \
    --user-name "$USERNAME" \
    --password "$PASSWORD" \
    --password-reset-required

  # Adiciona ao grupo
  aws iam add-user-to-group \
    --user-name "$USERNAME" \
    --group-name "$GROUP"

  echo "✓ $USERNAME criado e adicionado ao grupo $GROUP"

done

echo ""
echo "Migração concluída."

Passo 4 — Executar no AWS CloudShell

O AWS CloudShell é um terminal no próprio console da AWS com AWS CLI já configurada e autenticada. Não é necessário instalar nada localmente.

4.1 Instalar o dos2unix

sudo yum install dos2unix -y

4.2 Fazer upload dos arquivos

No CloudShell, clique em Actions → Upload file e envie:

criar-usuarios-iam.sh
ListaDeUsuarios.csv

4.3 Preparar e executar

# converter o CSV (necessário se o arquivo foi criado no Windows)
dos2unix ListaDeUsuarios.csv

# tornar o script executável
chmod +x criar-usuarios-iam.sh

# executar
./criar-usuarios-iam.sh ListaDeUsuarios.csv

A saída esperada é uma linha de confirmação para cada usuário criado.

Passo 5 — Validar os usuários criados

Verifique os usuários no console em IAM → Users, ou via CLI:

# listar todos os usuários da conta
aws iam list-users --output table

# verificar os grupos de um usuário específico
aws iam list-groups-for-user --user-name joao.silva

# verificar todos os usuários de um grupo
aws iam get-group --group-name LinuxAdmin --output table

Passo 6 — Aplicar política de MFA obrigatório

Sem essa etapa, os usuários conseguem acessar recursos da AWS sem configurar autenticação multifator. A política abaixo bloqueia qualquer ação enquanto o MFA não estiver ativo.

6.1 Criar a política

Acesse IAM → Policies → Create policy → JSON e cole o conteúdo abaixo:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowViewAccountInfo",
      "Effect": "Allow",
      "Action": [
        "iam:GetAccountPasswordPolicy",
        "iam:ListVirtualMFADevices"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowManageOwnVirtualMFADevice",
      "Effect": "Allow",
      "Action": [
        "iam:CreateVirtualMFADevice"
      ],
      "Resource": "arn:aws:iam::*:mfa/*"
    },
    {
      "Sid": "AllowManageOwnUserMFA",
      "Effect": "Allow",
      "Action": [
        "iam:DeactivateMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ResyncMFADevice"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "DenyAllExceptListedIfNoMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Dê o nome EnforceMFAPolicy e salve.

6.2 Anexar as políticas aos grupos

Para cada grupo, adicione as duas políticas abaixo:

IAMUserChangePassword — permite que o usuário troque sua própria senha no primeiro acesso
EnforceMFAPolicy — bloqueia acesso a qualquer recurso enquanto o MFA não estiver configurado

Acesse IAM → User groups → [nome do grupo] → Permissions → Add permissions → Attach policies.

Para aplicar em todos os grupos de uma vez, use a política diretamente:

IAM → Policies → EnforceMFAPolicy → Entities attached → Attach → selecione todos os grupos → Attach

Boas práticas aplicadas

Mínimo privilégio — cada grupo tem apenas as permissões necessárias para sua função
MFA obrigatório — nenhum usuário acessa recursos sem segundo fator ativo
Troca de senha no primeiro acesso — o parâmetro --password-reset-required garante que o usuário defina sua própria senha
Automação auditável — o script e o CSV podem ser versionados e revisados
Nunca usar o usuário root — toda operação deve ser feita com usuários IAM com permissões adequadas

Considerações finais

O mesmo processo funciona para qualquer escala — 10 ou 10.000 usuários. Para ambientes maiores, o próximo passo natural é evoluir para AWS SSO (IAM Identity Center) com integração a um provedor de identidade como Azure AD ou Okta, eliminando a necessidade de gerenciar senhas individuais no IAM.

Referências

See you later 🤘🏻

Bicep: A Linguagem Moderna de IaC para Azure

Luis Cruz — Tue, 02 Jun 2026 17:46:37 +0000

Se você já trabalhou com ARM Templates na Azure, sabe bem o quanto pode ser frustrante: arquivos JSON verbosos, difíceis de ler e ainda mais difíceis de manter. O Bicep chegou para resolver exatamente isso, uma linguagem de domínio específico (DSL) criada pela Microsoft para declarar infraestrutura no Azure de forma limpa, simples e poderosa.

O que é o Bicep?

Bicep é uma linguagem de IaC (Infrastructure as Code) desenvolvida pela Microsoft que compila diretamente para ARM Templates. Ou seja, por baixo dos panos, a Azure ainda usa ARM, mas você escreve um código muito mais legível e produtivo.

"Bicep é o ARM Template que você sempre quis escrever."

Lançado em 2021 como GA (Generally Available), o Bicep é hoje a forma recomendada pela Microsoft para definir recursos Azure via código.

Por que usar Bicep e não ARM Templates puro?

Veja a diferença para criar um simples Storage Account:

ARM Template (JSON):

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageAccountName": {
      "type": "string"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2022-09-01",
      "name": "[parameters('storageAccountName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "Standard_LRS"
      },
      "kind": "StorageV2"
    }
  ]
}

Bicep (equivalente):

param storageAccountName string

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: storageAccountName
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

Muito mais limpo, não é? Menos linhas, sem JSON aninhado e sem aquelas funções [parameters(...)] espalhadas por todo lado.

Bicep vs ARM vs Terraform: qual escolher?

Característica	Bicep	ARM Template	Terraform
Sintaxe	Limpa, DSL própria	JSON verboso	HCL
Multi-cloud	❌ Apenas Azure	❌ Apenas Azure	✅ Sim
Suporte a recursos Azure	✅ Primeiro dia	✅ Primeiro dia	⚠️ Depende do provider
Curva de aprendizado	Baixa	Alta	Média
State file	❌ Não precisa	❌ Não precisa	✅ Necessário
Módulos	✅ Sim	⚠️ Linked templates	✅ Sim
Integração nativa Azure DevOps/GitHub	✅ Nativa	✅ Nativa	Requer setup

Resumo prático:

Se você trabalha exclusivamente com Azure → Bicep é a melhor escolha
Se precisa de multi-cloud → Terraform
Se está migrando ARM existente → Bicep (tem conversor automático!)

Instalação

Pré-requisitos

Azure CLI instalado

Instalar o Bicep CLI

# Via Azure CLI (recomendado)
az bicep install

# Verificar versão
az bicep version

Extensão para VS Code

Instale a extensão oficial Bicep da Microsoft no VS Code. Ela oferece:

IntelliSense completo
Validação em tempo real
Autocompletar de tipos de recursos e propriedades
Visualização do diagrama de dependências

Conceitos Fundamentais

1. Parâmetros (`param`)

@description('Nome do ambiente')
@allowed(['dev', 'staging', 'prod'])
param environment string = 'dev'

@minLength(3)
@maxLength(24)
param storageAccountName string

Os decorators (@description, @allowed, @minLength) substituem as validações que no ARM eram feitas dentro do JSON.

2. Variáveis (`var`)

var location = resourceGroup().location
var tags = {
  environment: environment
  project: 'meu-projeto'
  managedBy: 'bicep'
}

3. Recursos (`resource`)

resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: 'plan-${environment}'
  location: location
  tags: tags
  sku: {
    name: 'B1'
    tier: 'Basic'
  }
}

4. Outputs (`output`)

output appServicePlanId string = appServicePlan.id
output storageAccountEndpoint string = storageAccount.properties.primaryEndpoints.blob

Exemplo Prático: Web App com Storage

Vamos criar um arquivo Bicep que provisiona um App Service + Storage Account completo:

// main.bicep

@description('Prefixo para os recursos')
param prefix string

@description('Ambiente de deploy')
@allowed(['dev', 'staging', 'prod'])
param environment string = 'dev'

var location = resourceGroup().location
var tags = {
  environment: environment
  managedBy: 'bicep'
}

// Storage Account
resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: '${prefix}${environment}st'
  location: location
  tags: tags
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
  }
}

// App Service Plan
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: '${prefix}-${environment}-plan'
  location: location
  tags: tags
  sku: {
    name: environment == 'prod' ? 'S1' : 'B1'
  }
}

// Web App
resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  name: '${prefix}-${environment}-app'
  location: location
  tags: tags
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
    siteConfig: {
      appSettings: [
        {
          name: 'STORAGE_CONNECTION'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.name};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
      ]
    }
  }
}

output webAppUrl string = 'https://${webApp.properties.defaultHostName}'
output storageAccountName string = storageAccount.name

Deploy

# Criar Resource Group
az group create --name rg-meu-projeto-dev --location brazilsouth

# Preview do que será criado (What-If)
az deployment group what-if \
  --resource-group rg-meu-projeto-dev \
  --template-file main.bicep \
  --parameters prefix=meuprojeto environment=dev

# Deploy
az deployment group create \
  --resource-group rg-meu-projeto-dev \
  --template-file main.bicep \
  --parameters prefix=meuprojeto environment=dev

Módulos: reutilizando código

Uma das funcionalidades mais poderosas do Bicep são os módulos, que permitem quebrar a infraestrutura em partes reutilizáveis:

// modules/storage.bicep
param name string
param location string = resourceGroup().location

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: name
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

output id string = storageAccount.id

// main.bicep — usando o módulo
module storage './modules/storage.bicep' = {
  name: 'storageDeployment'
  params: {
    name: 'mystorageaccount'
  }
}

output storageId string = storage.outputs.id

Você também pode referenciar módulos diretamente de um Bicep Registry (ACR) para compartilhar entre times:

module storage 'br:meuregistry.azurecr.io/bicep/storage:v1.0' = {
  name: 'storageDeployment'
  params: {
    name: 'mystorageaccount'
  }
}

Convertendo ARM Templates existentes para Bicep

Se você já tem ARM Templates, a migração é simples:

# Decompila ARM Template para Bicep
az bicep decompile --file template.json

# Converte Bicep de volta para ARM (útil para debug)
az bicep build --file main.bicep

Dicas e Boas Práticas

Use parâmetros com defaults para ambientes distintos (dev, staging, prod)
Adicione tags em todos os recursos para facilitar o custo e governança
Use what-if antes de todo deploy em produção
Organize em módulos desde o início evita refatorações grandes depois
Versione no Git junto ao código da aplicação (mesmo repositório)
Use o Bicep Registry (Azure Container Registry) para compartilhar módulos entre projetos e times

Próximos passos

Documentação oficial do Bicep
Bicep Playground — teste Bicep no browser
Azure Verified Modules — módulos Bicep oficiais e auditados pela Microsoft

O Bicep é, sem dúvida, a evolução natural para quem trabalha com IaC na Azure. Se você ainda usa ARM Templates puros, vale muito a pena considerar a migração, pois a curva de aprendizado é baixa e os ganhos em produtividade e manutenibilidade são imediatos.

E você, já está usando Bicep nos seus projetos? Deixa nos comentários!

Automação GitOps com Terraform e Proxmox

Luis Cruz — Fri, 30 Jan 2026 14:45:43 +0000

Há alguns meses, adquiri um M910q Desktop (ThinkCentre) para utilizá-lo no meu homelab, permitindo que o WSL do meu Lenovo S145 tivesse um pouco de descanso.

Essa iniciativa faz parte da minha busca contínua por evolução técnica, criando ambientes de teste e homologação que me permitam experimentar novas ferramentas e abordagens com mais liberdade.

Na criação das VMs, sempre utilizei o Terraform para o provisionamento. No entanto, recentemente realizei alguns ajustes importantes, integrando o GitHub e o HCP Terraform ao fluxo de trabalho.

Após dedicar algumas horas a esse processo, concluí um projeto que mudou completamente a forma como gerencio minha infraestrutura de homelab, e decidi compartilhar essa jornada com vocês.

O problema inicial

Sempre que eu precisava criar uma VM no Proxmox, o processo se repetia: abrir a interface web, preencher formulários, configurar rede manualmente, aguardar a criação da VM, acessar via SSH e configurar o ambiente.

Além disso, era necessário torcer para lembrar exatamente quais passos haviam sido executados caso fosse preciso replicar o processo no futuro.

Não havia histórico de mudanças, automação consistente ou rastreabilidade.

Mesmo utilizando scripts ou o próprio Terraform, ainda existiam etapas manuais, tornando o processo mais demorado do que deveria e com pontos claros de melhoria.

A solução: GitOps + Terraform + GitHub Actions

Implementei um fluxo completo de GitOps, no qual toda a infraestrutura passou a ser gerenciada exclusivamente por código versionado em Git.

O resultado foi bastante expressivo.

Hoje, consigo criar, modificar ou remover VMs simplesmente realizando um commit e um push. Em cerca de dois a três minutos, a alteração é automaticamente aplicada no ambiente Proxmox.

O que aprendi no caminho

Nem tudo é simples, especialmente para quem está começando do zero.

Como já possuo uma boa experiência com essas ferramentas, configurar corretamente as permissões no Proxmox, implementar um self-hosted runner na rede local, já que o Proxmox não é acessível diretamente da nuvem, e estruturar o código de forma escalável e reutilizável não foi algo particularmente difícil.

Ainda assim, cada etapa se mostrou uma oportunidade de aprendizado e de refinamento dos processos relacionados a Infrastructure as Code, CI/CD e boas práticas de automação.

Observação: para quem nunca fez algo semelhante, deixei um passo a passo detalhado, além de uma FAQ, para facilitar a reprodução do ambiente.

Tecnologias utilizadas

A stack é 100% open source e gratuita.

Utilizei Terraform para IaC, GitHub Actions para automação, Terraform Cloud para gerenciamento remoto de estado e Proxmox como hypervisor. Tudo isso rodando em um ambiente self-hosted, garantindo controle total sobre os dados e a infraestrutura.

O impacto real

Antes: entre 15 e 20 minutos para criar cada VM, com um processo manual, sujeito a erros e sem histórico de alterações.

Agora: cerca de 30 segundos para definir a VM em código, seguido de commit e push automáticos, com rastreabilidade completa via Git.

Mais importante do que o tempo economizado foi o ganho em confiabilidade.

Cada mudança passa por revisão, fica registrada no histórico do Git e pode ser revertida facilmente com um simples git revert. Isso é especialmente valioso em ambientes de experimentação, onde a possibilidade de voltar atrás com segurança faz toda a diferença.

Lições aprendidas

Automação não é sobre eliminar o trabalho manual, mas sim reduzir tarefas repetitivas e propensas a erros.

Infrastructure as Code não é exclusiva de grandes empresas. Homelabs são ambientes ideais para experimentação.

Documentação é tão importante quanto o código. Dediquei tempo a documentar cada etapa pensando no meu “eu do futuro”.

Self-hosted runners ampliam significativamente as possibilidades de automação em ambientes locais.

Próximos passos / Melhorias

Pretendo evoluir esse projeto integrando o Ansible, já que atualmente utilizo o Semaphore UI para a configuração pós-criação das VMs, além de adicionar testes automatizados antes do deploy.

Para quem se interessou pelos detalhes técnicos da implementação, e quiser fazer a implementação, o passo a passo, incluindo troubleshooting de todos os problemas enfrentados: homelab-infrastructure-template
Public

Trabalhar com infraestrutura é uma jornada contínua de aprendizado.

Compartilhar conhecimento e aprender com a comunidade faz toda a diferença.

Windows - Instalando o WSL 2 e o Docker

Luis Cruz — Wed, 10 Dec 2025 02:12:55 +0000

Se você usa Windows e precisa trabalhar com Docker, Terraform, scripts Bash ou qualquer ferramenta nativa de Linux, o WSL 2 (Windows Subsystem for Linux) é o caminho certo. Ele roda um kernel Linux real dentro do Windows — sem dual boot, sem máquina virtual pesada — e se integra perfeitamente com o Docker.

Neste artigo você vai instalar o WSL 2 com Ubuntu e configurar o Docker, com duas opções: via Docker Desktop (mais simples) ou via Docker Engine direto no Linux (mais leve).

Pré-requisitos

Windows 11 ou Windows 10 (build 19041 ou superior)
Virtualização por hardware habilitada na BIOS/UEFI
Conexão à internet

Para verificar se a virtualização está ativa, abra o Gerenciador de Tarefas → aba Desempenho → CPU → confirme que "Virtualização: Habilitado" aparece.

1. Instalar o WSL 2

Abra o PowerShell como Administrador e execute:

wsl --install

Este comando habilita os componentes necessários, instala o WSL 2 e baixa o Ubuntu como distribuição padrão. Ao final, reinicie o computador quando solicitado.

Para instalar uma distribuição diferente, use:

# listar distribuições disponíveis
wsl --list --online

# instalar uma específica
wsl --install -d Debian

Verificar a instalação

wsl --version
wsl -l -v

A coluna VERSION deve mostrar 2 para confirmar que está usando WSL 2. Novas instalações com wsl --install já são configuradas para WSL 2 por padrão.

Para instruções detalhadas, consulte a documentação oficial da Microsoft.

2. Instalar o Docker

Você tem duas opções. Escolha a que melhor se encaixa no seu uso:

	Docker Desktop	Docker Engine no WSL
Interface gráfica	✅ Sim	❌ Não
Facilidade	Alta	Média
Consumo de recursos	Maior	Menor
Licença	Gratuito para uso pessoal	Open source
Recomendado para	Iniciantes e uso geral	Devs que preferem CLI

Opção A: Docker Desktop com integração WSL 2

Baixe o Docker Desktop para Windows
Durante a instalação, mantenha marcada a opção Use WSL 2 instead of Hyper-V
Após instalar, abra o Docker Desktop e vá em Settings → General → ative Use the WSL 2 based engine
Em Settings → Resources → WSL Integration, habilite a distro que você usa (ex: Ubuntu)
Abra o terminal do WSL — os comandos docker e docker compose já estarão disponíveis

docker --version
docker compose version

Opção B: Docker Engine dentro do Ubuntu (WSL 2)

Abra o terminal do Ubuntu no WSL e execute os passos abaixo.

Adicionar o repositório oficial do Docker:

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg lsb-release

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Instalar o Docker Engine e o Compose:

sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Adicionar seu usuário ao grupo docker (evita usar sudo a cada comando):

sudo usermod -aG docker $USER

Reiniciar o WSL para aplicar as permissões. No PowerShell:

wsl --shutdown

Reabra o terminal do Ubuntu.

Iniciar o daemon do Docker:

sudo service docker start

Se quiser que o Docker inicie automaticamente, ative o systemd no WSL adicionando ao /etc/wsl.conf:
[boot]
systemd=true
Após salvar, execute wsl --shutdown no PowerShell e reabra o WSL.

Verificar a instalação:

docker run --rm hello-world
docker compose version

Consulte o guia oficial de instalação no Ubuntu para mais detalhes.

3. Exemplos práticos

Subir um NGINX

docker run --name exemplo-nginx -p 8080:80 -d nginx:stable

Acesse http://localhost:8080 no navegador do Windows, o Docker no WSL expõe as portas automaticamente para o host.

Usar Docker Compose

Crie um arquivo compose.yml:

services:
  web:
    image: nginx:stable
    ports:
      - "8080:80"

# subir os serviços
docker compose up -d

# verificar status
docker compose ps

# ver logs em tempo real
docker compose logs -f

# encerrar e remover os containers
docker compose down

Referências

O que é Gemba? E como aplicar em times de DevOps remotos

Luis Cruz — Fri, 24 Oct 2025 19:13:53 +0000

Gemba (現場) é um termo japonês que significa, literalmente, "o lugar real" ou "onde as coisas acontecem". Popularizado pelo Lean Manufacturing, o conceito é simples: para entender um problema de verdade, você precisa ir até onde ele acontece, não confiar apenas em relatórios ou reuniões.

Mas o que isso tem a ver com times de DevOps, engenharia de software e ambientes remotos? Muito mais do que parece.

O que é Lean?

Antes de aprofundar no Gemba, vale contextualizar: o Lean (também chamado de Lean Thinking ou Mentalidade Enxuta) é uma filosofia de gestão originada na Toyota que busca maximizar valor e eliminar desperdícios em processos. Nos últimos anos, seus princípios migraram da manufatura para times de tecnologia — e se tornaram base de frameworks como DevOps, Agile e SRE.

O Gemba é um dos pilares práticos do Lean.

O conceito de Gemba

No contexto empresarial, o Gemba é o local onde o valor é criado:

Em uma fábrica → o chão de produção
Em uma empresa de software → onde os desenvolvedores codificam e operam sistemas
Em uma loja de varejo → o piso de atendimento ao cliente

A filosofia incentiva líderes e gestores a irem até esse local para:

Observar os processos diretamente
Identificar problemas reais, não apenas dados em relatórios
Ouvir os colaboradores que estão na linha de frente
Tomar decisões baseadas em fatos, não em suposições

Gemba Walk

O conceito associado mais conhecido é o Gemba Walk — uma visita estruturada ao local de trabalho com o objetivo de:

Entender o fluxo de trabalho real
Detectar desperdícios ou gargalos
Promover a melhoria contínua (Kaizen)
Fortalecer o relacionamento entre gestão e equipe

Importante: o Gemba Walk não é uma auditoria ou fiscalização. É uma oportunidade de aprendizado mútuo — a ideia é entender, não julgar.

Princípios de uma boa prática de Gemba

Princípio	Como aplicar
Ir ao Gemba	Visite o local real com frequência, sem intermediários
Observar com propósito	Veja como o trabalho realmente é feito, não como deveria ser
Fazer perguntas	Entenda os "porquês" por trás dos processos
Ouvir os colaboradores	Eles conhecem os desafios diários melhor que qualquer relatório
Agir com respeito	A ideia é aprender, nunca expor ou pressionar
Promover melhorias	Use os insights para implementar melhorias sustentáveis

Benefícios do Gemba

Aumento da eficiência operacional
Redução de desperdícios no fluxo de trabalho
Maior engajamento e confiança da equipe
Tomada de decisão mais assertiva e baseada em fatos
Cultura de melhoria contínua enraizada no dia a dia

Como aplicar Gemba e Lean com trabalho remoto e times distribuídos

Essa é a pergunta prática: como ir ao "lugar real" quando o time está espalhado em fusos diferentes?

A resposta é que o Gemba não precisa ser físico — ele precisa ser real. Em times remotos, o Gemba é o espaço digital onde o trabalho acontece.

Redefinindo o Gemba no remoto

O "lugar real" de um time de tecnologia remoto está em:

Repositórios de código — GitHub, GitLab (onde o trabalho é registrado)
Sistemas de tickets — Jira, Linear, ServiceNow (onde o fluxo é visível)
Dashboards de observabilidade — Grafana, Prometheus, Datadog (onde os problemas aparecem)
Ferramentas de colaboração — Slack, Teams, Confluence (onde as decisões acontecem)
Pipelines de CI/CD — onde o valor chega ao cliente

Fazendo Gemba Walks digitais

Ação	Como adaptar no remoto
Observar o trabalho em tempo real	Sessões de pair programming, compartilhamento de tela, gravações de Loom
Fazer perguntas abertas	Check-ins por vídeo ou threads assíncronas no Slack/Teams
Identificar desperdícios	Analisar tempo de espera em PRs, filas de aprovação, lead time no Jira
Documentar aprendizados	Logs de Gemba Walks no Confluence ou Notion

Aplicando Lean no remoto

Mapeie o fluxo de valor digital (Value Stream Mapping)

Entenda todas as etapas entre a demanda e a entrega. Exemplo em infraestrutura:

Solicitação → Escrita do Terraform → Code Review → CI/CD → Validação → Deploy → Monitoramento

Cada etapa pode ter desperdícios escondidos — tempo de espera, retrabalho, falta de clareza.

Identifique desperdícios remotos

Espera por aprovações manuais
Retrabalho por requisitos mal definidos
Sobrecarga por excesso de reuniões
Falta de visibilidade do progresso para o time

Estimule o Kaizen remoto

Faça retrospectivas Lean curtas e frequentes (não apenas no fim do sprint)
Capture ideias de melhoria em murais colaborativos (Miro, FigJam)
Implemente pequenas melhorias rápidas e meça os resultados antes de escalar

Ferramentas para suportar Lean + Gemba em times remotos

Categoria	Ferramentas
Gestão visual (Kanban)	Trello, Jira, Linear, Asana
Automação e fluxo	GitHub Actions, GitLab CI/CD, Jenkins
Observabilidade	Grafana, Prometheus, Datadog, New Relic
Colaboração	Slack, Zoom, Teams
Documentação de Gemba Walks	Confluence, Notion

Exemplo prático: Gemba em uma equipe de DevOps remota

Problema identificado	Gemba Walk digital	Ação Lean
Demora no provisionamento de VMs	Acompanhar fluxo no Terraform + GitLab CI com a equipe	Automatizar aprovações com policy as code
Incidentes frequentes em produção	Analisar logs no Grafana + entrevistar o on-call	Criar runbooks e alertas mais precisos
Backlog sem clareza	Revisitar o Jira ao vivo com o time	Definir Definition of Ready para cada ticket

Conclusão

O Gemba não é um conceito preso em fábricas japonesas dos anos 1950. É uma mentalidade que permanece relevante em qualquer contexto onde haja trabalho real acontecendo — incluindo times de DevOps, engenharia de plataforma e operações em nuvem.

A chave está em fazer a pergunta certa: onde, de fato, o trabalho acontece no nosso time? E depois ir lá — seja fisicamente ou digitalmente — para observar, ouvir e melhorar de forma contínua.

Referências

Em inglês:

Em português: