Na aula anterior, introduzimos o conceito de segurança em automação, destacando a importância de proteger pipelines, scripts e configurações. Agora, vamos mergulhar em aspectos práticos e avançados: como lidar com segredos, implementar verificações automatizadas de segurança, configurar logging eficaz e estabelecer processos de revisão que fortaleçam a postura de segurança.

Esta aula é essencial para quem deseja construir pipelines de CI/CD robustos e seguros, evitando vazamentos de credenciais e vulnerabilidades que podem ser exploradas. Cada tópico será abordado com profundidade, incluindo exemplos de código e melhores práticas.

Secrets

Segredos são informações sensíveis como senhas, chaves de API, tokens e certificados. Em automação, eles são necessários para autenticar serviços, mas seu gerenciamento inadequado é uma das principais causas de violações de segurança. Nunca armazene segredos em texto plano em repositórios, scripts ou variáveis de ambiente expostas.

Ferramentas modernas de CI/CD, como GitHub Actions, GitLab CI e Jenkins, oferecem mecanismos para armazenar segredos de forma criptografada e injetá-los no ambiente de execução apenas quando necessário. Além disso, é fundamental adotar o princípio do menor privilégio: conceda apenas as permissões estritamente necessárias para cada automação.

Um exemplo comum de uso de segredos em um pipeline GitHub Actions:

name: Deploy
on: [push]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
      - name: Deploy to production
        run: ./deploy.sh

Nesse exemplo, os segredos são referenciados como ${{ secrets.NOME }} e são injetados pelo GitHub Actions no momento da execução, sem aparecer nos logs. Nunca imprima segredos em logs ou saídas de comando.

Automation checks

Verificações automatizadas são gateways de qualidade e segurança que executam durante o pipeline, antes de aprovar uma alteração. Elas incluem análise estática de código (SAST), verificação de dependências vulneráveis, testes de segurança dinâmicos (DAST) e até mesmo verificação de conformidade com políticas de infraestrutura como código (IaC).

Essas verificações ajudam a detectar problemas precocemente, reduzindo o risco de vulnerabilidades chegarem à produção. Por exemplo, ferramentas como SonarQube ou Semgrep podem ser integradas ao pipeline para analisar o código em busca de padrões inseguros.

Um exemplo de etapa de verificação em um pipeline GitLab CI:

stages:
  - test
  - security
security_scan:
  stage: security
  script:
    - semgrep --config=auto .
  only:
    - merge_requests

Essa etapa executa o Semgrep em cada merge request, falhando se encontrar problemas. É importante definir políticas de qualidade: por exemplo, nenhuma vulnerabilidade crítica pode ser aceita, e o pipeline deve falhar se a verificação não passar.

Logging

Logging é a prática de registrar eventos e atividades do sistema. Em automação, logs são cruciais para auditoria, depuração e detecção de incidentes. No entanto, logs mal configurados podem expor informações sensíveis ou não fornecer detalhes suficientes para investigação.

Boas práticas de logging incluem: registrar eventos de autenticação, alterações de configuração e execuções de pipeline; usar níveis de log adequados (debug, info, warn, error); e nunca registrar segredos ou dados pessoais. Logs devem ser centralizados e protegidos contra acesso não autorizado.

Um exemplo de logging em um script Python de automação:

import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

def deploy():
    logger.info('Iniciando deploy')
    try:
        # código de deploy
        pass
    except Exception as e:
        logger.error('Falha no deploy: %s', e)
        raise

Além disso, em pipelines, é possível usar ferramentas como ELK, Splunk ou CloudWatch para agregar logs e criar alertas. Lembre-se de mascarar qualquer segredo que possa aparecer nos logs, usando filtros automáticos.

Reviews

Revisões de código são revisões humanas de alterações propostas, mas também podem ser automatizadas. Em segurança, revisões são essenciais para identificar vulnerabilidades que ferramentas automáticas podem não detectar, como lógica de negócio insegura ou abuso de privilégios.

Processos de revisão eficazes incluem: exigir pelo menos um revisor aprovado antes do merge, usar checklists de segurança, e integrar bots que comentam automaticamente em pull requests com base em análises estáticas.

Um exemplo de configuração de revisão obrigatória no GitHub:

branch-protection:
  "main":
    required_pull_request_reviews:
      required_approving_review_count: 1
      dismiss_stale_reviews: true
    required_status_checks:
      strict: true

Além disso, é importante que os revisores tenham conhecimento em segurança e que haja uma cultura de segurança na equipe. Revisões não devem ser apenas uma formalidade, mas uma oportunidade real de melhorar a qualidade e segurança do código.

Boas práticas e observações finais

Além dos tópicos abordados, considere as seguintes boas práticas: rotacione segredos regularmente, use ferramentas de gerenciamento de segredos como HashiCorp Vault, implemente políticas de imutabilidade para artefatos de build, e mantenha as dependências atualizadas. Lembre-se de que segurança é um processo contínuo e que a automação deve ser constantemente revisada e melhorada.

Referências

Exercícios

  1. Explique por que é arriscado armazenar segredos em variáveis de ambiente em um script de automação e cite uma alternativa segura.

    ✓ Resposta: Variáveis de ambiente podem ser expostas em logs, processos ou arquivos de configuração, e muitas vezes são visíveis para outros usuários do sistema. Uma alternativa segura é usar um gerenciador de segredos como HashiCorp Vault ou o serviço de segredos do seu provedor de CI/CD, que injeta segredos diretamente no ambiente de execução sem expô-los em texto plano.
  2. Descreva duas verificações automatizadas de segurança que você pode adicionar a um pipeline CI/CD e explique o que cada uma detecta.

    ✓ Resposta: Duas verificações comuns são: 1) Análise estática de código (SAST) usando ferramentas como Semgrep ou SonarQube, que detecta padrões inseguros, injeção de SQL, uso de funções perigosas, etc. 2) Verificação de dependências vulneráveis usando ferramentas como OWASP Dependency-Check ou Snyk, que compara as versões das bibliotecas com bancos de dados de vulnerabilidades conhecidas.
  3. Cite três boas práticas de logging em automação e explique por que cada uma é importante.

    ✓ Resposta: 1) Registrar eventos de autenticação e autorização: ajuda a detectar tentativas de acesso não autorizado. 2) Usar níveis de log apropriados: permite filtrar informações e reduzir ruído, facilitando a depuração e análise. 3) Centralizar logs: facilita a correlação de eventos e a detecção de incidentes em toda a infraestrutura, além de permitir a retenção adequada para auditoria.
  4. Como você implementaria uma revisão obrigatória de código em um repositório Git, e qual é o papel do revisor em relação à segurança?

    ✓ Resposta: Para implementar revisão obrigatória, configure regras de proteção de branch no GitHub/GitLab, exigindo pelo menos um revisor aprovado e status checks que devem passar. O revisor deve analisar o código não apenas quanto à funcionalidade, mas também procurar por vulnerabilidades, uso inadequado de segredos, validação de entrada, e conformidade com políticas de segurança.
  5. Dada a seguinte etapa de pipeline, identifique um problema de segurança e sugira uma correção: 
    - name: Deploy
  run: echo "Chave: $API_KEY" && ./deploy.sh

    ✓ Resposta: O problema é que o comando echo imprime o valor da chave nos logs, expondo o segredo. Correção: remover o echo e apenas usar a variável em comandos que não a exibam. Ou, se precisar de depuração, use mascaramento, como echo "Chave: ${{ secrets.API_KEY }}" em alguns sistemas, mas o ideal é nunca logar o valor.