SREDay Campinas 2025: Secure SRE Pipelines with Terraform and AWS

Confiabilidade sem segurança é mera sorte. Nesta palestra, veja como as práticas do Shift Left capacitam SREs a automatizar a segurança, prevenir incidentes precocemente e entregar sistemas resilientes com confiança.

Sou um profissional de cloud security e curto práticas de ser/devops, com experiência prática em automação de segurança em pipelines CI/CD em ambientes multicloud (AWS, Azure e GCP). Atuo como HashiCorp Ambassador e AWS Community Builder, além de professor de MBA em DevSecOps e Cloud Security na FIAP, onde ensina justamente como integrar segurança e confiabilidade desde o início do ciclo de entrega.

Transcript

1. SREDay Campinas Site Reliability, DevOps and Cloud
2. Secure SRE Pipelines with Terraform & AWS Aplicando Shift Left na Confiabilidade.
3. Sr. Security Engineer, Cloud at CI&T Professor Pós Grad MBA at FIAP 3⃣AWS Community Builder 3⃣Hashicorp Ambassador @amaurybsouza Amaury Borges Souza
4. Gosto de escrever…
5. Também gosto de eventos…
6. Tópicos • Por que SRE também é segurança • O impacto das misconfigurations em Terraform + AWS • Shift Left aplicado ao SRE • Hardening IaC na prática (Terraform) • Security Gates no pipeline de SRE • Ferramentas essenciais para automação de segurança • Como prevenir incidentes antes do deploy • Confiabilidade com segurança: o caminho ideal
7. Os números que explicam por que SRE precisa de segurança • Aumento de 154% em incidentes de segurança na nuvem em 1 ano (Check Point) • 64% relatam aumento em data breaches; 45% em downtime por misconfig (State of Cloud-Native Security) • Misconfigurations são hoje a causa #1 de incidentes em produção; e SRE sente isso primeiro no on-call.
8. Outros dados de pesquisas sobre segurança nos times de SREs • 90% dos pipelines CI/CD têm pelo menos 1 falha crítica de segurança (Fonte: CrowdStrike) • 40% do tempo dos SREs vai para investigar incidentes que poderiam ser prevenidos por controles simples (validações automáticas, IaC scan, config checks) SRE mantém parte dessas automações. Pipeline inseguro = deploy com risco operacional.
9. Por que SREs escolhem AWS + Terraform? • AWS domina o mercado; onde a maior parte das workloads SRE vivem. • Terraform é o padrão IaC; simples, reprodutível e usado por SREs no dia a dia. • Misconfigurations causam incidentes; impacto direto em segurança e confiabilidade. • IaC seguro = menos on-call, menos falhas. • Shift Left une SRE + Segurança desde o início.
10. Segurança como Pilar de SRE • Segurança no processo de SRE • Por que “Shift Left” em SRE Referência OWASP para SRE
11. Como SRE se relaciona com Segurança e DevOps • SRE conecta DevOps com Segurança por meio de automação • Falhas de segurança viram incidentes → quebram SLOs • SRE evita que código ou infra inseguros cheguem na produção • SRE automatiza controles via pipelines (DevSecOps real) • Tudo que compromete segurança… compromete confiabilidade.
12. Por que SRE também é segurança? 1. Confiabilidade depende de segurança a. Falha de segurança = indisponibilidade. 2. Misconfigurations são a maior causa de incidentes 3. Erros em pipelines, Terraform, K8s se tornam riscos de segurança (permissões abertas, storage público, pods inseguros, etc.). 4. Incidentes modernos derrubam sistemas tanto quanto bugs.
13. Quando SBOM importa para SRE? • Visibilidade de componentes e dependências críticas • Acelera resposta a incidentes (ex.: Log4Shell) • Ajuda a garantir confiabilidade e reduzir risco operacional • Evita que libs vulneráveis cheguem à produção • Auxilia SRE a validar imagens e artefatos antes do deploy • Permite rastrear impacto de CVEs rapidamente SBOM é um documento (geralmente em formato JSON ou XML) que descreve todos os componentes, dependências, bibliotecas e versões usados em uma aplicação.
14. Perguntas para fazer qualquer SRE pensar • “Deploy automático sem security gate é inovação… ou roleta russa?” • “Se tudo é automatizado, quem garante que está seguro?” • “K8s com permissões amplas é alta disponibilidade… ou alta exposição?”
15. Referência OWASP (CI/CD Security) Os pipelines de CI/CD também são um alvo atraente para hackers mal-intencionados, e sua segurança não pode ser ignorada. Veja pontos de segurança em pipelines de CI/CD para SRE: • Segurança de Configuração • IAM • Gerenciamento de código de terceiros • Monitoramento e Visibilidade • Gerenciamento de Senhas • Scanners de IaC A OWASP já mapeou os principais riscos de segurança em pipelines. Como SRE, ignorar isso significa correr risco de incidentes.
16. SRE cuida de como código é deployado; e isso acontece via pipeline. Todo deploy moderno acontece por: • GitHub Actions • GitLab CI • ArgoCD / Tekton • Jenkins • Spinnaker • Azure DevOps Pipelines • AWS CodePipeline
17. Como camadas de segurança ajudam SRE a reduzir incidentes e aumentar a confiabilidade • Reduz falhas em produção • Diminui o volume de alertas e on-call • Permite deploy seguro e confiável Fonte: PagerDuty
18. Categorias de Ferramentas • SCA, SAST, DAST, IaC scanning → o que são e diferenças. • Observabilidade e segurança.
19. Como detectar vulnerabilidades antes que virem incidentes SCA SAST DAST IaC Scan
20. Ferramentas para IaC Com IaC, equipes de SRE automatizam infraestrutura de forma consistente, auditável e segura; reduzindo erros humanos e acelerando entregas.
21. Security Gates no Pipeline de SRE Security Gates são pontos de controle inseridos no pipeline para impedir que código, infraestrutura ou configurações inseguras cheguem à produção. • Confiabilidade = Segurança: vulnerabilidades impactam SLOs e disponibilidade. • Reduz incidentes: evita misconfigurations, permissões incorretas e riscos de supply-chain. • Shift Left real: problemas são bloqueados no pipeline, e não descobertos no on-call. • Automação remove subjetividade: critérios claros e reproduzíveis para “go/no-go”.
22. O que um Security Gate valida? • Vulnerabilidades no código (SAST) • Vulnerabilidades em libs (SCA) • Imagens/container inseguros • IaC com configurações críticas • Credenciais vazadas • Políticas de conformidade (OPA/Regula/Checkov)
23. Ferramentas de Segurança que Impactam SRE SCA • Prisma Cloud • Snyk • Dependabot • Black Duck Software Composition Analysis. Porque importa para SRE: Vulnerabilidades críticas podem derrubar workloads ou gerar incidentes de supply chain. SAST • SonarQube • Checkmarx • Veracode • Semgrep Teste de segurança de aplicativos estáticos (Início da pipeline) Porque importa para SRE: Reduz risco de incidentes originados por falhas de implementação (tokens hardcoded) DAST • Zap proxy Teste de segurança de aplicativos dinâmicos (final do pipeline) Porque importa para SRE: Encontrar pontos de falha que podem resultar em indisponibilidade, abuso de recursos ou exposição de dados. IaC Scan • TFlint • TfSec Abordagem de infraestrutura como código. Porque importa para SRE Previna incidentes como: S3 públicos, Security Groups 0.0.0.0/0, IAM permissivo
24. Shift Left no SRE Shift Left" significa aplicar práticas de segurança nas fases iniciais do desenvolvimento de software, como o commit e o build, em vez de deixá-las apenas no final. Fonte: Demonstrativa (educacional)
25. Case com AWS para SRE • KIRO CLI como aliado do SRE • Prompts Engineering com KIRO CLI
26. Por que usar AWS KIRO CLI no contexto de SRE? Kiro CLI pode ajudar um SRE a automatizar tarefas rotineiras, priorizar problemas com inteligência e executar ações de remediação diretamente do terminal, tornando o fluxo de trabalho mais eficiente.
27. Prompt Engineering com KIRO CLI para SRE Prompt Engineering com KIRO CLI permite que SREs obtenham rapidamente análises de risco, detecção de misconfigurações e insights de segurança diretamente na CLI. • Exemplo de Prompt 01 “ > kiro, verifique se há alguma configuração incorreta em IAM, S3 ou Security Groups que possa gerar incidentes.”
28. Prompt Engineering com KIRO CLI para SRE Com prompts bem formulados, o KIRO entrega diagnósticos rápidos, identifica riscos AWS e ajuda o SRE a prevenir incidentes antes que afetem SLOs. • Exemplo de Prompt 02 “ > kiro, encontre problemas reais que podem virar incidentes e ignore os falsos positivos.”
29. Como prevenir incidentes antes do deploy • Scanners IaC (Checkov, TFsec) • Policy as Code no pipeline • Terraform plan + validações • Detectar drift antes do apply
30. IaC com Terraform É uma ferramenta popular de IaC da HashiCorp para definir, provisionar e gerenciar infraestrutura com segurança e eficiência. Ela utiliza uma sintaxe declarativa para definir dependências de recursos. • Linguagem Declarativa • Multi-Cloud (AWS, Azure, GCP) • Reduz incidentes ao remover mudanças manuais • Policy as Code (Sentinel) • Integração com Pipeline
31. Ameaças em IaC (Infrastructure as Code) A adoção de infraestrutura como código (IaC) traz velocidade e padronização, mas também pode introduzir riscos de segurança quando não bem controlada. Principais Ameaças: • Misconfigurações críticas (S3 público), SG 0.0.0.0/0 • Segredos expostos em código • Drift entre código vs. ambiente real • Dependências inseguras • Não conformidade com padrões de compliance CIS/NIST/PCI
32. Ferramentas do ecossistema do Kubernetes para segurança de app baseadas em Cloud Native • Kubescape (é uma plataforma de segurança Kubernetes de código aberto para seus IDEs, CI/CD e clusters. Inclui análise de riscos, segurança). • Falco (é uma ferramenta de segurança nativa em nuvem que fornece segurança em tempo de execução em hosts, Kubernetes. • Cnspec (avalia a segurança e a conformidade de toda a sua infraestrutura. Ele encontra vulnerabilidades e configurações incorretas em clusters Kubernetes. • Kube-bench (é uma ferramenta que verifica se o Kubernetes está implantado com segurança executando as verificações com CIS Kubernetes Benchmark.).
33. Política como Código (Policy as Code) Política como código é uma abordagem de gerenciamento de políticas na qual as políticas são definidas, atualizadas, compartilhadas e aplicadas por meio de código Fonte: RedHat Blog
34. Scanners de Segurança para IaC Detecta violações de conformidade e segurança em toda a infraestrutura como código (IaC), para mitigar riscos antes de provisionar a infraestrutura nativa na nuvem. Principais Ferramentas: • TFLint • Tfsec • Terrascan • Sentinel • Checkov • Kics Por que isso importa para SRE: • Evita incidentes antes mesmo do deploy → menos on-call • Aumenta previsibilidade e estabilidade da infraestrutura
35. Checkov O Checkov verifica as configurações de infraestrutura de nuvem para encontrar erros de configuração antes que elas sejam implantadas. Checkov usa uma interface de linha de comando comum para gerenciar e analisar resultados de varredura de infraestrutura como código (IaC) em plataformas como Terraform, CloudFormation, Kubernetes, Helm. Interface de integração extensível com Jenkins, GitLab, GitHub Actions, VSCode.
36. Como SRE Pratica Segurança na Rotina • Shift Left de Infra: validar Terraform, Helm, pipelines, permissões • Automação de segurança: scanners IaC, container, SAST/SCA no pipeline • Hardening: IAM mínimo, redes restritas, policies automatizadas (OPA/Rego) • SLOs de Segurança: falhas de compliance afetam confiabilidade • Detecção precoce: alertas de tráfego anômalo, pods reiniciando, erros suspeitos • Cultura: SRE, DevOps e Segurança trabalhando juntos; menos incidentes e mais resiliência
37. Desafios e Evolução • Barreiras e Desafios na Adoção • Futuro da Segurança para SRE • Recursos Adicionais • Discussão e Dúvidas
38. Barreiras e Desafios na Adoção Resistência cultural: Mudança de mindset das equipes, medo da automação, falta de alinhamento entre os times. Trade-offs entre velocidade e segurança: Pressão por entregas rápidas x necessidade de práticas seguras. Ferramentas mal configuradas: Risco de false positives, alert fatigue e perda de credibilidade das análises. Treinamento e educação: Programas de educação e treinamento são importantes para manter uma boa adoção da segurança no processo no SRE.
39. Futuro da Segurança em SRE • Segurança orientada por IA: integre algoritmos de IA e ML para aprimorar os recursos de detecção e resposta a ameaças. Modelos de ML para prever vulnerabilidades (por exemplo, GitHub Copilot para sugestões de código seguro). • Política como código (PaC): codifique políticas de segurança para correção automática (por exemplo, HashiCorp Sentinel, OPA, Checkov). • Colaboração: As habilidades de se manter comunicativo, manter uma cultura de segurança no time de SRE, é um dos pilares de sucesso, potencializando entregas, negócios e inovação em time.
40. Referências SRE / Confiabilidade • Google SRE Book: Site Reliability Engineering https://sre.google/sre-book/table-of-contents/ • Google SRE Workbook (Práticas e exemplos) https://sre.google/workbook/table-of-contents/ • SRE Fundamentals – Red Hat https://www.redhat.com/en/topics/devops/what-is-sre Segurança + DevSecOps • OWASP DevSecOps Guideline https://owasp.org/www-project-devsecops-guideline/ • OWASP Secure SDLC Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Secure_SD LC_Cheat_Sheet.html • DevSecOps Maturity Model (DSOMM) https://dsomm.timo-pagel.de/ • NIST Secure Software Development Framework (SSDF) https://csrc.nist.gov/projects/ssdf
41. RECURSOS ADICIONAIS: LIVROS • Infrastructure as Code: Neste livro prático, Kief Morris, mostra como usar com eficácia os princípios, práticas e padrões pioneiros das equipes de DevOps para gerenciar a infraestrutura da era da nuvem. • Building Secure & Reliable Systems: Ofrece ótimas dicas sobre como projetar sistemas escaláveis, integrando segurança e confiabilidade. • Engenharia de Plataforma: Obter insights sobre as melhores práticas para liderar equipes de engenharia de plataforma bem-sucedidas. • Site Reliability Engineering: Entenda a teoria e a prática do trabalho cotidiano de um SRE: desenvolver e operar sistemas computacionais distribuídos de grande porte.
42. PERGUNTAS & DISCUSSÃO • Qual validação de segurança seu time conseguiria automatizar já na próxima sprint? • O que sua equipe pode mover para Shift Left esta semana? • Qual é o maior risco escondido na sua automação atual?
43. linkedin.com/in/amaurybsouza | builder.aws.com/community/@amaury | @amaurybsouza Thank you SREDay Campinas (Site Reliability, DevOps and Cloud)