← Blog
Segurança no Ansible: melhores práticas para automação segura
Melhores práticas de segurança no Ansible: proteja segredos com o Ansible Vault, reforce privilégios e módulos e escaneie playbooks no CI.
Bruno Baldo·21 de set. de 2026·Atualizado em 14 de set. de 2026·10 min de leitura·Revisado por Rainforest Technologies
O Ansible é o cavalo de batalha silencioso da infraestrutura moderna. Ele configura servidores, faz deploy de aplicações, aplica patches em frotas e orquestra releases, muitas vezes com um punhado de arquivos YAML legíveis. É justamente essa acessibilidade que faz a segurança no Ansible merecer atenção deliberada: um playbook que alcança centenas de hosts com privilégios elevados é um dos artefatos mais poderosos, e mais perigosos, do seu ambiente. Uma única credencial vazada ou uma variável não validada passada a um comando de shell pode transformar a automação conveniente em um caminho rápido para um atacante.
A boa notícia é que proteger o Ansible é, em grande parte, uma questão de disciplina e de um conjunto de melhores práticas de segurança no Ansible bem compreendidas. Este mergulho detalhado percorre as áreas que mais importam: proteger segredos com o Ansible Vault, manter credenciais fora dos playbooks e logs, aplicar o menor privilégio com become, escolher módulos seguros, defender-se contra injeção em templates, reforçar as conexões, gerenciar a cadeia de suprimentos da sua automação e escanear tudo no CI para que playbooks Ansible seguros se tornem o padrão, e não a exceção. Ele faz parte do nosso guia mais amplo de segurança de Infrastructure as Code, que conecta essas práticas específicas de cada ferramenta.
Gestão de segredos com o Ansible Vault
A automação precisa de credenciais: senhas de banco de dados, tokens de API, chaves TLS, chaves de acesso à nuvem. A regra fundamental é simples. Valores sensíveis nunca devem ficar em texto puro em um repositório. O Ansible Vault é a resposta nativa. Ele criptografa variáveis e arquivos com uma chave simétrica, para que possam conviver com segurança ao lado dos seus playbooks.
Você pode criptografar um arquivo inteiro:
ansible-vault encrypt group_vars/production/secrets.yml
Ou criptografar strings individuais inline, para que a maior parte de um arquivo de vars permaneça legível nos diffs:
db_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
66386439653......
Alguns hábitos tornam o Vault genuinamente eficaz, em vez de mero teatro:
Nunca faça commit da própria senha do Vault. Forneça-a em tempo de execução com --vault-password-file apontando para um arquivo fora do repositório, ou um script que busca a chave na sua plataforma de segredos. Mantenha a senha fora do histórico do shell e dos logs de CI.
Separe os dados criptografados dos dados em texto claro. Um padrão comum é um vars.yml legível que referencia valores criptografados guardados em um vault.yml, de modo que os revisores possam ver a estrutura sem expor os segredos.
Rotacione as chaves e refaça a chave quando pessoas saem. O ansible-vault rekey recriptografa o conteúdo com uma nova senha sem alterar o texto puro.
O Vault é excelente para segredos estáticos, mas, para credenciais que rotacionam com frequência ou são compartilhadas entre muitos sistemas, integre um cofre de segredos externo. O Ansible pode obter segredos em tempo de execução de vaults gerenciados e gerenciadores de segredos na nuvem via lookup plugins, de modo que nada sensível seja gravado em disco:
- name: Fetch API token from an external secret store at runtime
ansible.builtin.debug:
msg: "{{ lookup('community.hashi_vault.vault_kv2_get', 'apps/payments').secret.api_token }}"
no_log: true
Isso mantém a fonte da verdade em um sistema construído para rotação, auditoria e controle de acesso, enquanto o Ansible simplesmente solicita o que precisa quando é executado. Também reduz o número de segredos de longa duração que você precisa gerenciar manualmente, que é onde o drift e as credenciais desatualizadas costumam surgir.
Uma regra prática: use o Vault para valores que mudam raramente e pertencem ao código (feature flags, configuração de serviço, credenciais iniciais para um ambiente novo), e use um cofre externo para tudo o que é compartilhado entre equipes, rotacionado em uma programação ou sujeito a auditoria de conformidade. Misturar os dois é normal e esperado; o importante é que nenhum segredo sem criptografia jamais chegue a um commit, a uma linha de log ou a um artefato de CI.
Mantendo segredos fora de playbooks, inventory e logs
A criptografia só ajuda se os segredos não vazarem em outros lugares. Dois modos de falha silenciosos causam a maioria dos incidentes.
Primeiro, a proliferação de inventory e playbooks. Senhas de conexão em um arquivo de inventory em texto puro, tokens fixados diretamente em uma tarefa ou chaves privadas versionadas no controle de versão são todos comuns. Mantenha as credenciais em vars criptografadas com o Vault ou em um cofre externo, e adicione os segredos do inventory a padrões do .gitignore para que não possam ser commitados por acidente.
Segundo, os logs. O Ansible ecoa os resultados das tarefas por padrão, e uma tarefa que manipula uma senha pode imprimi-la diretamente no console ou na saída do CI. Use no_log: true em qualquer tarefa que lide com dados sensíveis:
- name: Create database user
community.postgresql.postgresql_user:
name: app
password: "{{ db_password }}"
no_log: true
Lembre-se de que modos verbosos e callbacks ainda podem expor dados, então evite passar segredos por command/shell, onde eles podem aparecer em listagens de processos ou logs, e prefira módulos que aceitem credenciais como parâmetros.
Privilégio e become: menor privilégio por padrão
A escalada de privilégios do Ansible é poderosa e fácil de aplicar em excesso. Definir become: true no nível do play, de modo que toda tarefa seja executada como root, é conveniente e arriscado. Se qualquer tarefa for comprometida ou se comportar mal, ela o fará com autoridade total de root.
Aplique o menor privilégio em vez disso:
Escale privilégios apenas onde for necessário. Coloque become: true nas tarefas individuais que exigem, não no play inteiro.
Escale para o usuário certo, nem sempre para o root. Use become_user para executar tarefas como a conta de serviço específica que é dona do recurso.
Restrinja o sudo com precisão. Nos hosts gerenciados, conceda à conta de automação direitos de sudo apenas para os comandos específicos de que ela precisa, em vez de acesso irrestrito ALL.
- name: Restart the app service (scoped escalation)
ansible.builtin.systemd:
name: myapp
state: restarted
become: true
become_user: root
O objetivo é que uma tarefa descontrolada ou sequestrada tenha o menor raio de impacto possível.
Também ajuda separar a conta com a qual o Ansible se conecta dos privilégios para os quais ele escala. Conecte-se como um usuário de automação sem privilégios via SSH e escale apenas para as tarefas específicas que precisam. Assim, uma chave SSH roubada não equivale automaticamente a root em todos os hosts gerenciados, e a sua política de sudo nesses hosts se torna uma segunda linha de defesa auditável, que você controla de forma independente dos próprios playbooks.
Segurança dos módulos: prefira módulos ao shell
O Ansible traz centenas de módulos idempotentes que entendem o estado que gerenciam. Recorra a eles antes de descer para shell, command ou raw. Esses três executam comandos arbitrários, não são idempotentes e, o mais importante, são o principal vetor de injeção de comandos quando interpolam variáveis não validadas:
# Risky: an attacker-controlled username can inject commands
- name: Add user (unsafe)
ansible.builtin.shell: "useradd {{ username }}"
# Safer: the module validates and handles the value
- name: Add user (safe)
ansible.builtin.user:
name: "{{ username }}"
state: present
Se uma variável vem de uma origem externa (uma API, entrada do usuário, um survey), trate-a como não confiável. Quando você realmente precisar usar shell ou command, valide as entradas, use os filtros quote e evite construir strings de comando por concatenação. Prefira command a shell sempre que possível, já que command não passa por um shell e, portanto, não interpreta pipes, redirecionamentos e outros metacaracteres que ampliam a superfície de injeção. Os módulos lhe dão idempotência, melhor tratamento de erros e uma superfície de injeção muito menor de graça.
Injeção em templates (Jinja2)
O Ansible renderiza variáveis e templates através do Jinja2, e templatizar entradas não confiáveis pode levar à injeção de template do lado do servidor, em que valores maliciosos executam expressões em vez de serem tratados como dados. Nunca renderize valores que você não controla diretamente em templates ou strings de comando. Mantenha os dados fornecidos externamente como dados: passe-os como parâmetros de módulo, aplique o filtro quote quando for relevante e tenha cautela com construções que avaliam strings. Revise as tarefas template: que puxam variáveis originadas fora do seu inventory controlado.
Segurança de SSH e das conexões
O Ansible alcança os hosts principalmente por SSH, então a higiene das conexões é essencial para a segurança no Ansible.
Gerencie as chaves adequadamente. Use chaves SSH dedicadas para a automação, proteja as chaves privadas e prefira um agente SSH ou uma autoridade certificadora de curta duração a chaves de longa duração espalhadas pelas máquinas.
Não desative a verificação de chaves de host. É tentador definir host_key_checking = False para silenciar os prompts, mas isso remove a proteção contra ataques man-in-the-middle. Em vez disso, gerencie o known_hosts para que novos hosts sejam confiados de forma deliberada.
Prefira autenticação baseada em chaves a senhas e evite embutir senhas de conexão no inventory.
Cadeia de suprimentos: fixe e avalie collections e roles
O Ansible moderno puxa collections e roles do Galaxy e de outras origens. Cada uma é código que roda no seu ambiente, então trate-a como parte da sua cadeia de suprimentos de software. Dependências não fixadas significam que um upstream comprometido ou alterado pode mudar silenciosamente o que a sua automação faz.
Fixe versões exatas no requirements.yml e avalie de onde o conteúdo vem:
collections:
- name: community.postgresql
version: "3.4.0"
roles:
- src: https://github.com/example/hardening-role
version: "v2.1.0"
Instale a partir desse manifesto (ansible-galaxy install -r requirements.yml), revise as atualizações antes de subir as versões e favoreça origens reputáveis e bem mantidas. Reconstruir a partir de um manifesto fixado também torna suas execuções reproduzíveis e lhe dá um único lugar para auditar exatamente qual código de terceiros está sendo executado no seu ambiente. Quando você atualizar uma dependência, leia o changelog e faça o diff da mudança da mesma forma que revisaria o código de uma aplicação, porque uma role que gerencia o estado do sistema pode fazer qualquer coisa que a conta que a executa consiga fazer.
Idempotência e drift
A idempotência é uma propriedade de segurança, não apenas de correção. Um playbook que produz o mesmo resultado não importa quantas vezes seja executado permite que você reaplique o estado desejado para corrigir o drift de configuração. Quando a automação é a definição autoritativa de um sistema, mudanças inesperadas se destacam e alterações manuais são sobrescritas na próxima execução. Favoreça módulos e estado declarativo (state: present, state: absent) em vez de passos imperativos de shell, para que seus playbooks convirjam de forma confiável.
Linting e escaneamento de playbooks no CI
A forma mais confiável de manter playbooks Ansible seguros de fato seguros é verificá-los automaticamente a cada mudança. Duas camadas funcionam em conjunto.
O ansible-lint detecta padrões arriscados e antipadrões: uso de command onde existe um módulo, ausência de no_log, sintaxe obsoleta e mais. Execute-o no CI para que os problemas falhem o pipeline cedo:
# In your CI pipeline
- ansible-lint playbooks/
Ao lado do linting, execute um scan de segurança de IaC que entenda configurações incorretas e segredos expostos em toda a sua automação e na infraestrutura que ela define. O linting impõe bom estilo e antipadrões conhecidos; o scan de segurança procura os resultados arriscados, como credenciais vazadas, escalada permissiva demais e defaults inseguros, e os classifica por severidade. Juntos, eles transformam a segurança de um passo de revisão manual em um gate automatizado.
Se você está protegendo IaC além do Ansible, a mesma abordagem CI-first se aplica às suas outras ferramentas, cobertas em nossos mergulhos detalhados de segurança no Terraform e segurança no Kubernetes.
Como a Rainforest ajuda
A Rainforest traz o Ansible para o mesmo fluxo de segurança do resto da sua base de código. Nosso escaneamento de segurança de IaC analisa suas definições de automação e infraestrutura em busca de configurações incorretas, segredos expostos e defaults inseguros, e então apresenta os achados com o contexto e a severidade de que sua equipe precisa para agir. Como ele se conecta ao pipeline como parte da plataforma mais ampla de testes de segurança de aplicações, o mesmo scan roda em cada merge request, de modo que playbooks arriscados são sinalizados antes de irem para produção, não depois de um incidente.
O resultado é uma automação em que você pode confiar: segredos criptografados, escalada de menor privilégio, módulos seguros e um gate de CI que mantém cada mudança honesta. Pronto para ver isso nos seus próprios playbooks? Agende uma demonstração e percorreremos tudo com a sua stack.
Perguntas frequentes
O Ansible é seguro?
O Ansible pode ser muito seguro, mas a segurança depende de como você o usa. Seu design agentless, baseado em SSH, e sua grande biblioteca de módulos idempotentes lhe dão uma base sólida. O risco vem de como você lida com segredos, escalada de privilégios, entradas não confiáveis e dependências. Seguir práticas como usar o Ansible Vault, restringir o escopo do become, preferir módulos ao shell e escanear playbooks no CI torna o Ansible uma ferramenta de automação segura.
O que é o Ansible Vault?
O Ansible Vault é o recurso nativo do Ansible para criptografar dados sensíveis, como senhas, tokens de API e chaves. Ele usa criptografia simétrica AES-256, para que você possa armazenar segredos com segurança no mesmo repositório dos seus playbooks. Você pode criptografar arquivos inteiros ou variáveis individuais, e fornece a senha do Vault em tempo de execução em vez de fazer commit dela.
Como mantenho segredos fora dos playbooks do Ansible?
Criptografe variáveis e arquivos sensíveis com o Ansible Vault, ou obtenha-os em tempo de execução de um cofre de segredos externo usando lookup plugins, de modo que nada seja gravado em disco. Nunca faça commit de credenciais em texto puro ou chaves privadas, mantenha os arquivos de inventory que contêm segredos fora do controle de versão e adicione no_log: true às tarefas que lidam com dados sensíveis, para que não vazem nos logs.
É seguro usar os módulos shell/command?
Eles são seguros apenas com cuidado. shell, command e raw executam comandos arbitrários, não são idempotentes e podem permitir injeção de comandos se interpolarem variáveis não validadas. Prefira um módulo específico sempre que houver um. Quando precisar usá-los, trate as entradas externas como não confiáveis, valide e faça o quote dos valores e evite construir strings de comando por concatenação.
Como escaneio playbooks do Ansible em busca de problemas de segurança?
Use duas camadas no CI. Execute o ansible-lint para detectar padrões arriscados e antipadrões, e execute um scan de segurança de IaC para detectar configurações incorretas, segredos expostos e definições permissivas demais, classificados por severidade. O escaneamento de segurança de IaC da Rainforest se integra ao seu pipeline, de modo que cada mudança nos seus playbooks é verificada automaticamente antes de ir para produção.
Escrito por
Bruno Baldo
CMO
Um pouco de marketing e um pouco de curiosidade e temos a receita pra criar um apaixonado por cyber!
Segurança de Infrastructure as Code (IaC): o guia completo
Segurança de IaC explicada: o modelo de ameaças, o scanning ao longo do SDLC, policy as code, secrets e state e um fluxo prático de remediação.
Segurança no Terraform: Boas Práticas para uma Infraestrutura Segura
Boas práticas de segurança no Terraform para state, segredos, IAM, módulos e CI para que sua infraestrutura como código chegue à produção com segurança.
Segurança no Kubernetes: o guia completo
Guia completo de segurança no Kubernetes: o modelo dos 4C's, superfície de ataque, RBAC, pods, network policies, secrets, cadeia de suprimentos e shift-left.