DevSecOps e NetSecOps na Cloud: Construir infraestruturas resilientes a ataques na era pós-quântica

30 de Julho de 2026

A operação IT em Portugal atravessa um momento de elevada pressão em várias frentes. A pressão regulatória nunca foi tão concreta: a NIS2, transposta para o ordenamento jurídico português em 2024, o DORA, em vigor desde janeiro de 2025 para o setor financeiro, e o reforço das competências do CNCS, criaram obrigações específicas em torno de gestão de risco, comunicação de incidentes e resiliência operacional.

Ao mesmo tempo, o panorama de ameaças agravou-se significativamente. Ataques de ransomware a hospitais e municípios, bem como o aumento sustentado de campanhas com motivação geopolítica transformaram a cibersegurança num verdadeiro problema de continuidade de negócio.

Paralelamente, a transição criptográfica pós-quântica deixou de ser ficção académica. Os dados cifrados hoje com RSA ou ECDH podem já estar a ser recolhidos para futura descodificação, num cenário conhecido como harvest-now-decrypt-later.

Para equipas DevOps em Portugal, o foco em escalabilidade e fiabilidade tem agora de coexistir com uma postura de segurança que se assume compromisso como inevitável e que se prepara para a próxima geração de algoritmos criptográficos.

Neste artigo, veremos como DevSecOps e NetSecOps convergem na cloud, como a resiliência a ataques exige novas práticas de engenharia e o que poderá acontecer horizonte de 4 a 5 anos com a chegada das redes quânticas e da criptografia pós-quântica ao quotidiano operacional.

De DevOps a DevSecOps e NetSecOps

O DevSecOps surge da constatação de que tratar a segurança como uma fase final do ciclo de desenvolvimento é insuficiente. O conceito de shift-left security, ou seja, antecipar as verificações de segurança para o momento em que o código é escrito, e não para a véspera do deploy, tornou-se um princípio elementar.

Na prática, isto significa que análise estática (SAST), análise de dependências (SCA), validação de políticas em IaC e secrets scanning passam a integrar o pipeline da mesma forma que os testes unitários.

Por outro lado, NetSecOps represneta o movimento paralelo no domínio da rede. Tradicionalmente, as equipas de segurança de rede operavam em silos, com firewalls geridas manualmente, ACLs propagadas através de change requests e configurações em VPNs corporativas administradas via interfaces gráficas.

Em ambientes cloud-native, este modelo colapsa. O NetSecOps aplica princípios DevOps à segurança de rede através de firewalls definidas como código, microsegmentação programática, políticas declarativas de zero trust aplicadas via API, peering e VPNs provisionados em Terraform.

A convergência destes dois movimentos com o DevOps clássico é particularmente evidente na cloud. Plataformas como o Microsoft Defender for Cloud, o Google Security Command Center ou o AWS Security Hub agregam sinais de postura de segurança transversais a workloads, redes e identidades. As CNAPPs (Cloud-Native Application Protection Platforms), como Wiz, Prisma Cloud ou Lacework consolidam ainda mais este modelo unificado.

Em empresas portuguesas sujeitas a forte regulação, como bancos, seguradoras ou entidades do setor público, esta convergência tornou-se praticamente obrigatória. Auditorias do Banco de Portugal e do regulador de seguros já incluem questionários específicos sobre práticas DevSecOps e gestão de identidade na cloud.

Escalabilidade segura: Zero Trust e microsegmentação

A escalabilidade horizontal trouxe um problema que muitas equipas apenas descobrem em produção. À medida que se multiplicam serviços e instâncias, a superfície de ataque interna cresce de forma desproporcional.

Em arquiteturas tradicionais com perímetro forte, tudo é confiável dentro da rede. Contudo, este modelo é extremamente frágil na medida em que basta um ponto de entrada comprometido para permitir movimentação lateral sem fricção.

O modelo zero trust inverte este pressuposto na medida em que nenhum workload, utilizador ou dispositivo é fiável por defeito, independentemente da localização na rede. Cada chamada é autenticada, autorizada e cifrada.

Na prática, isto traduz-se em:

mTLS entre serviços

Idealmente implementado através service mesh (Istio, Linkerd, Cilium Service Mesh) que automatiza a rotação de certificados.

Workload identity

Baseada em frameworks como SPIFFE/SPIRE, em que cada pod recebe uma identidade criptográfica verificável sem depender de credenciais estáticas.

NetworkPolicies em Kubernetes

Complementadas por soluções como Cilium (com eBPF) que permitem políticas L7. Ou seja, não basta definir que o serviço A pode comunicar com o B; é possível restringir aos endpoints HTTP específicos.

Microsegmentação

Em vez de uma VPC plana, a arquitetura passa a estar organizada em segmentos isolados por domínio funcional, com fluxos explicitamente definidos.

A escalabilidade segura assenta na ideia de que a postura de segurança deve evoluir à mesma velocidade que o sistema, e não degradar à medida que ele cresce. Isto exige automação total, porque gerir centenas de microserviços com regras manuais deixa rapidamente de ser viável.

Resiliência a ataques: Para além da alta disponibilidade

A resiliência clássica em DevOps protege contra falhas técnicas como hardware avariado, bugs em deploys ou partições de rede. No entanto, não protege contra uma ameaça que ataca ativamente o sistema.

A resiliência a ataques é uma disciplina diferente, com pressupostos próprios:

Assume breach

As perguntas relevantes deixam de ser "como impedimos a entrada?" e passam a ser:

• - "Quanto tempo até detetarmos?"
• - "Que privilégios consegue escalar?"
• - "A que dados consegue aceder?"

Recuperação a partir de comprometimento

O RTO clássico (Recovery Time Objective) assume que o sistema pode ser restaurado a partir de backups íntegros. Em cenários de ransomware, esses backups podem estar comprometidos.

Backups imutáveis (object lock no S3, immutable storage na Azure), isolados em contas separadas, com testes regulares de restauro, tornam-se fundamentais.

Threat modeling como prática de engenharia

No contexto da engenharia moderna, a modelação de ameaças através de metodologias como STRIDE, PASTA e attack trees, deve integrada a fase de conceção dos sistemas, deixando de ser um exercício pontual de auditoria para se tornar uma prática contínua de design seguro.

Security chaos engineering

A Netflix popularizou o Chaos Monkey como abordagem para introduzir falhas técnicas controladas.

A nova geração de ferramentas, como o Chaos Mesh, combinadas como práticas de purple teaming automatizado, vão além da resiliência operacional ao injetar falhas deliberadas de segurança, como:

• - Credenciais expostas;
• - Containers com privilégios excessivos;
• - Padrões de egress anómalos;

O objetivo é validar mecanismos de deteção e resposta em cenários reais.

Imutabilidade e GitOps

A adoção de infraestruturas imutáveis, reconstruídas exclusivamente a partir de uma fonte de verdade versionada, aumenta significativamente a resiliência do sistema.

Alterações realizadas em tempo de execução são revertidas automaticamente no ciclo seguinte de reconciliação, reduzindo a persistência de configurações maliciosas. Plataformas como Argo CD e Flux operacionalizam este modelo de forma nativa.

A gestão de incidentes continua a ser um pilar essencial da segurança operacional, mas passa a assumir também uma dimensão regulatória.

Ao abrigo da NIS2, as entidades essenciais e importantes devem:

• - Notificar incidentes significativos no prazo de 24 horas (alerta inicial);
• - Apresentar uma notificação detalhada em 72 horas;
• - Submeter um relatório final no prazo de um mês.

Desta forma, os runbooks de resposta de resposta a incidentes devem integrar não apenas procedimentos técnicos, mas também fluxos legais, comunicação institucional e reporte às autoridades competentes.

Automação de segurança e Policy as Code

Se a Infrastructure as Code (IaC) democratizou a provisão de infraestrutura, o modelo de Policy as Code democratiza a governação e o compliance. O princípio passa por transformar controlos de segurança, como benchmarks CIS, requisitos da ISO 27001 e políticas internas em código validado automaticamente nos pipelines de desenvolvimento e na fase de deploy.

A segurança torna-se, assim, verificável, auditável e contínua.

Open Policy Agent (OPA)

O Open Policy Agent, com a linguagem Rego, constitui um padrão de facto para validação de políticas em ambientes cloud-native. É amplamente utilizado em Kubernetes através de integrações como Gatekeeper e pode também ser aplicado a pipelines de Terraform, permitindo impor controlos de segurança antes da criação de recursos.

Checkov, tfsec e KICS

Ferramentas como Checkov, tfsec e KICS realizam análise estática de IaC, detetando configurações inseguras antes do deploy.

Entre os problemas mais comuns encontram-se:

• - Buckets S3 públicos;
• - Security groups excessivamente permissivos (0.0.0.0/0);
• - Encriptação em repouso desativada.

Sentinel

O Sentinel é a alternativa proprietária integrada no Terraform Cloud e Terraform Enterprise, permitindo aplicar políticas diretamente no fluxo de execução da infraestrutura.

A gestão de segredos continua a ser um dos pilares mais críticos da segurança operacional.

Segredos incorporados diretamente no código permanecem entre as principais causas de comprometimento de ambientes cloud.

Ferramentas de deteção como Gitleaks, TruffleHog e GitGuardian devem ser executadas tanto no pre-commit como nos pipelines de CI.

Em tempo de execução, soluções como HashiCorp Vault, Azure Key Vault, AWS Secrets Manager e GCP Secret Manager centralizam o ciclo de vida dos segredos, suportando:

• - Rotação automática;
• - Audit trail;
• - Integração com identidades de workload.

A gestão de IAM como código, incluindo papéis, políticas e trust relationships, deve seguir o mesmo rigor de revisão e integração contínua aplicado ao código aplicacional.

O princípio do menor privilégio deixa de ser apenas uma recomendação teórica e passa a ser aplicado de forma sistemática, com ferramentas como AWS Access Analyzer e soluções CIEM (Cloud Infrastructure Entitlement Management) a identificarem permissões não utilizadas e a recomendarem a sua redução.

CI/CD seguro: A cadeia de fornecimento como vetor de ataque

Os principais incidentes da última década, como é o caso de SolarWinds, dependency confusion, Log4Shell e o backdoor no XZ Utils, partilham um padrão: o atacante não comprometeu o alvo final, mas sim algo que o alvo confiava e usava. Isto transformou a segurança da cadeia de fornecimento de software numa prioridade transversal.

Entretanto, várias boas práticas consolidaram-se no mercado.

SBOM obrigatório

O Software Bill of Materials, em formatos como SPDX ou CycloneDX, deve ser gerado a cada build, descrevendo todas as dependências diretas e transitivas.

Para entidades abrangidas pela NIS2 e fornecedores do setor público, esta prática começa já a surgir como requisito contratual.

Assinatura de artefactos

Ferramentas como Sigstore (cosign, fulcio, rekor) tornaram a assinatura de imagens de containers e artefactos praticamente trivial.

A validação na admissão, recorrendo a soluções como Kyverno ou Connaisseur, garante que apenas artefactos assinados por chaves conhecidas chegam a produção.

Atestações in-toto/ SLSA

A framework SLSA (Supply-chain Levels for Software Artifacts) define níveis de garantia progressivos sobre como um artefacto foi construído.

A SLSA 3, baseada em builds executadas em plataformas protegidas e com proveniência verificável, é atualmente uma meta realista para muitas organizações nos próximos 2 a 3 anos.

Builds reprodutíveis

O mesmo input deve produzir exatamente o mesmo output, byte-for-byte. Isto permite validação independente e deteção de adulterações na toolchain.

Scanning contínuo de vulnerabilidades

Em imagens de containers e dependências aplicacionais, recorrendo a ferramentas como Trivy, Grype e Snyk, com priorização baseada no potencial real de exploração das vulnerabilidades através de métricas como EPSS e catálogos KEV, e não exclusivamente em CVSS.

Isolamento de builds

Runners efémeros, sem segredos persistentes e sem acesso lateral à rede de produção.

Para a banca portuguesa sob DORA, o controlo da cadeia de fornecimento de TIC tornou-se uma obrigação direta. As práticas de SBOM e atestação alimentam diretamente este compliance.

Observabilidade unida: SOC, DevSecOps e AIOps

A separação tradicional entre operations (Grafana, Prometheus, painéis de latência) e security operations (SIEM, regras de detecção, alertas no SOC) não sobrevive ao escrutínio moderno.

Um pico de latência pode ser resultado de um deploy mal executado ou de um ataque DDoS em curso. Um aumento de erros 401 pode ser um bug na renovação de tokens ou um credential stuffing. A telemetria unificada é a resposta mais racional.

A resposta passa pela telemetria unificada.

SIEM cloud-native

Plataformas como Microsoft Sentinel, Google Chronicle, Wazuh (open-source), Elastic Security permitiem ingestão de logs, correlação, regras de deteção em código através de Sigma rules).

SOAR

Para automatização da resposta, os playbooks isolam um host, revogam um token, abrem um ticket, notificam o responsável e tudo isto pode acontecer em segundos.

Deteção em runtime

Observabilidade ao nível do kernel via eBPF, permitindo detetar comportamentos anómalos em containers, como: execução inesperada de shells; bind a portas não declaradas e leituras de ficheiros sensíveis.

AIOps aplicado a segurança

Modelos de deteção comportamental (UEBA), correlação automática de alertas dispersos e redução de falsos positivos através de classificação supervisionada começam a ganhar maturidade operacional.

Os modelos de linguagem também começam a ser utilizados para resumir alertas e sugerir hipóteses iniciais aos analistas.

Em organizações com maior maturidade, os dashboards unificados já combinam métricas de SLO com indicadores de segurança, como:

• - Taxa de tentativas de autenticação falhadas;
• - Desvios de baseline;
• - Idade de credenciais não rotacionadas.

A equipa de SRE e a equipa de segurança passam a trabalhar sobre a mesma camada de observabilidade, ainda que recorrendo a fontes de dados diferentes.

O horizonte de 4–5 anos: Criptografia pós-quântica e quantum networks

É precisamente aqui que o planeamento de IT em Portugal precisa de começar a olhar além do horizonte trimestral. Existem duas linhas evolutivas paralelas que irão impactar profundamente a forma como as infraestruturas são desenhadas e operadas nos próximos 4 a 5 anos.

A migração pós-quântica (PQC)

Em agosto de 2024, o NIST publicou os primeiros standards finais de criptografia pós-quântica:

Anteriormente conhecido como CRYSTALS-Kyber, destinado ap encapsulamento de chaves e pensado como substituto de RSA-KEM e ECDH.

FIPS 204 (ML-DSA)

Antiga CRYSTALS-Dilithium, focado em assinaturas digitais.

FIPS 205 (SLH-DSA)

Antigo SPHINCS+, um modelo de assinaturas hash-based concebido como alternativa conservadora.

Estes algoritmos foram desenvolvidos para resistir tanto a computadores clássicos como a computadores quânticos suficientemente avançados para correr o algoritmo de Shor. Embora a chegada desse cenário cuja continue incerta, as estimativas variam entre 5 a 25 anos, a preparação não pode esperar pela confirmação definitiva.

O risco harvest-now-decrypt-later é considerado real. O tráfego TLS intercetado atualmente, com chaves trocadas via ECDHE, pode ser armazenado e descodificado futuramente quando a capacidade computacional quântica atingir maturidade suficiente.

Para dados com elevada sensibilidade como registos clínicos, informação de Estado, propriedade intelectual lcrítica e dados financeiros de longo prazo, a janela de exposição já começou.

Cenário prováveis para o ecossistema cloud em Portugal nos próximos 4-5 anos:

TLS 1.3 híbrido (X25519 + ML-KEM-768) começa a tornar-se default em stacks modernas.

OpenSSL 3.5, BoringSSL, rustls e a maioria dos load balancers da AWS, Azure e GCP já oferecem suporte.

As cipher suites PQC começam também a surgir em pipelines automatizados de auditoria através de ferramentas como: testssl.sh e sslyze.

O CNCS, alinhado com orientações da ENISA, e o Banco de Portugal, em articulação com o BCE e EBA, começam a publicar orientações concretas sobre crypto-agility e calendários de migração para infraestruturas críticas.

Auditorias DORA passam gradualmente a incluir inventário criptográfico.

VPNs corporativas (IKEv2 com KEMs PQC), SSH (a OpenSSH já tem suporte experimental em 9.x), código assinado (assinaturas Dilithium em PKIs internas) começam a ser migrados em massa.

Infraestruturas internas de mTLS, certificados de workload e PKIs corporativas passam a integrar planos plurianuais de migração.

2029-2030

A adoção de PQC torna-se praticamente obrigatória em setores regulados.

As organizações que não tenham iniciado inventário criptográfico até 2026 poderão enfrentar processos de migração reativos e pressionados por exigências regulatórias.

Implicações práticas para operações de IT:

É fundamental identificar onde RSA, ECDSA, DSA e ECDH estão a ser utilizados:

• - Código aplicacional;
• - IaC;
• - Certificados;
• - Chaves ssh;
• - Segredos geridos por kms;
• - Integrações com terceiros.

Ferramentas como CryptoNext, ISARA ou abordagens próprias com nmap e parsing TLS tornam-se particularmente relevantes.

As dependências criptográficas devem ser configuráveis, não hardcoded.

Muitas organizações demoraram anos a abandonar SHA-1 precisamente porque os algoritmos estavam rigidamente integrados nas aplicações.

As novas primitivas criptográficas têm impacto operacional direto.

Por exemplo:

• - Uma chave pública Kyber-768 ronda os 1184 bytes;
• - Uma chave RSA-2048 ocupa cerca de 256 bytes;
• - Assinaturas Dilithium-3 aproximam-se dos 3300 bytes.

Isto influencia:

• - Tamanho de handshakes;
• - Mtu;
• - Latência;
• - Overhead em ambientes mtls de elevada frequência.

É fundamental acompanhar os roadmaps dos fabricantes: Thales, Utimaco, AWS CloudHSM, Azure Managed HSM e Google Cloud HSM.

O suporte PQC em HSMs continua ainda numa fase inicial de adoção.

As equipas que desenvolvem software próprio precisam de definir um plano de adoção. Projetos como liboqs e o OQS Provider para OpenSSL 3.x começam a assumir um papel relevante na interoperabilidade.

Quantum networks: EuroQCI e o caso QKD

Paralelamente, o conceito de quantum networks introduz uma abordagem qualitativamente diferente à distribuição de chaves criptográficas.

O Quantum Key Distribution (QKD) utiliza propriedades físicas da mecânica quântica para distribuir chaves. Qualquer tentativa de intercetação introduz alterações detetáveis devido ao princípio da indeterminação.

A garantia deixa de depender exclusivamente da dificuldade computacional e passa a ser information-theoretic.

Portugal participa atualmente na iniciativa EuroQCI (European Quantum Communication Infrastructure), com o segmento ibérico IberQCI ligando Portugal e Espanha.

Projetos piloto em Lisboa, com colaboração entre o IT, INESC TEC, operadores de telecomunicações e instituições financeiras, deverão começar a materializar-se nos próximos anos.

Assim, um calendário realista poderá ser:

2026-2027

Pilotos QKD em pares específicos de centros de dados na zona metropolitana de Lisboa, ligações dedicadas via fibra escura.

Casos de uso:

• - Ligação entre core banking e disaster recovery;
• - Ligação entre datacenter principal e sistemas de escrow.

2027-2028

Integração híbrido entre QKD + PQC em cenários críticos. O QKD distribui chaves simétricas que são depois usadas em cifras simétricas (AES-256), com PQC como fallback e para autenticação.

2028-2030

Extensão para ligações intercidades através de trusted nodes, eventualmente complementadas por QKD via satélite (programas EuroQCI Space).

A adoção mantém-se concentrada em casos de uso de elevada sensibilidade como é caso do setor da defesa, banca de grande dimensão e infraestruturas críticas.

Para a maioria das equipas de IT em Portugal, QKD permanecerá durante este horizonte temporal, uma tecnologia de nicho.

A prioridade prática nos próximos anos é claramente PQC em software, não QKD em fibra.

Ainda assim, organizações em setores críticos deverão acompanhar estes pilotos, desenvolver competências internas e compreender onde o QKD pode complementar estratégias de migração pós-quântica.

O que fazer nos próximos 12-24 meses

Para equipas de operações de IT em Portugal, o mais importante é iniciar uma transição gradual e realista.

Inventário criptográfico

Automatizado em IaC, código e runtime. Sem inventário, nenhum plano de migração é credível.

Atualizar threat models

Incluir cenários harvest-now-decrypt-later e identificar dados com sensibilidade superior a 10 anos.

Pilotar PQC em ambientes não-produtivos

Testar endpoints TLS híbridos, assinatura de imagens com Dilithium via cosign experimental e SSH com algoritmos pós-quânticos.

Formação técnica

Esta será provavelmente a maior transição criptográfica desde a descontinuação de SHA-1 e exige competências ainda pouco disseminadas no mercado.

Acompanhar fornecedores cloud

Os roadmaps PQC publicados pela AWS (KMS), Azure (Key Vault) e GCP (Cloud KMS) serão determinantes quando para acelerar a adoção.

Acompanhar a evolução regulatória

As orientações do CNCS, ENISA, BCE, Banco de Portugal e ANACOM serão progressivamente mais relevantes.

Embora NIS2 e DORA ainda não imponham explicitamente PQC, os requisitos de crypto-agility deverão surgir cada vez mais em auditorias.

Para setores críticos

Acompanhar iniciativas conduzidas por FCT, INESC, IT, e operadores envolvidos no IberQCI para compreender timings, pilotos e potenciais oportunidades de integração futura.

Boas práticas: Síntese para operações IT

Shift-left e shift-right

Segurança desde o início (no PR, no IaC, no SBOM) e em runtime (eBPF, comportamento anómalo, telemetria SOC).

Crypto-agility como princípio

Os algoritmos criptográficos devem ser tratados como componentes substituíveis: configuráveis, monitorizáveis e reversíveis.

A migração de SHA-1 para SHA-256 foi um aviso. PQC será o verdadeiro teste.

Zero Trust operacional

Identidade como perímetro, mTLS por defeito entre serviços, microsegmentação automatizada e princípio do menor privilégio aplicado mecanicamente.

Cadeia de fornecimento como controlo crítico

SBOM, assinatura, atestação e isolamento de builds deixam de ser boas práticas opcionais.

São já requisitos críticos para organizações abrangidas pela NIS2 e DORA.

Observabilidade unificada

Ops e SecOps passam a partilhar telemetria, ferramentas e contexto operacional.

Ao mesmo tempo, AIOps começa a assumir um papel importante na redução de ruído e correlação automática de sinais dispersos.

A próxima geração de infraestruturas IT em Portugal não se distinguirá apenas pela capacidade de escalar workloads ou pela sofisticação dos dashboards, mas sobretudo pela capacidade de assumir compromisso, recuperar com integridade e migrar criptografia sem comprometer a continuidade operacional.

DevSecOps e NetSecOps representam a disciplina. A transição pós-quântica será o verdadeiro teste dos próximos anos.