Planejamento do TCC

Tema

Compliance-as-Code em Ambientes Cloud: Uma Arquitetura de Referência Autonômica Baseada em MAPE-K para Detecção, Remediação Automatizada e Governança Formal de Exceções

Delimitação do Tema

O trabalho delimita-se à proposta, formalização e avaliação experimental de uma arquitetura de referência autonômica para compliance de segurança em ambientes cloud, com as seguintes fronteiras:

• Domínio técnico: misconfigurations de recursos cloud — desvios de propriedades de configuração verificáveis programaticamente — excluindo vulnerabilidades de código-fonte, CVEs e falhas de autenticação de usuários humanos
• Norma primária: ISO/IEC 27002, com correspondência validada ao NIST SP 800-137 para os controles selecionados
• Implementação de referência: Amazon Web Services, utilizando serviços serverless nativos, como prova de conceito da arquitetura agnóstica proposta
• Ferramenta de IaC: OpenTofu como mecanismo de provisionamento e remediação, por ser open source e agnóstico a provedor cloud
• Motor de políticas: Open Policy Agent (OPA) com linguagem Rego como fonte única de verdade para avaliação de conformidade
• Escopo experimental: ambiente controlado com violações sintéticas introduzidas, validação interna das hipóteses

Estão fora do escopo:

• Otimização de custos de infraestrutura (FinOps)
• Gestão de identidade e autenticação de usuários humanos
• Vulnerabilidades de código-fonte e CVEs
• Remediação de recursos sem representação em IaC
• Ambientes multi-cloud simultâneos
• Propriedade self-optimizing da Computação Autonômica
• Validação externa em múltiplos ambientes de produção

Problema de Pesquisa

Ambientes cloud apresentam alta frequência de violações de controles de segurança decorrentes de:

• configurações incorretas de recursos
• permissões excessivas concedidas a identidades
• exposição acidental de serviços à internet
• alterações manuais realizadas fora de pipelines de infraestrutura como código

Embora normas como a ISO/IEC 27002 estabeleçam controles de segurança reconhecidos internacionalmente, sua aplicação em ambientes cloud dinâmicos enfrenta três desafios operacionais centrais:

1. Detecção tardia: violações permanecem ativas por horas ou dias até serem identificadas por processos manuais periódicos, elevando o tempo de exposição ao risco
2. Remediação manual: a correção depende de intervenção humana, introduzindo latência, inconsistência e ausência de rastreabilidade formal
3. Governança informal de exceções: organizações permitem desvios operacionais temporários sem controle formal, sem limite temporal e sem rastreabilidade adequada, criando risco de exceções que se tornam permanentes

Esses desafios produzem dois efeitos mensuráveis:

• Aumento do tempo de exposição a configurações inseguras, elevando o risco de incidentes de segurança
• Perda de governança e auditabilidade de compliance, comprometendo a capacidade de demonstrar conformidade a auditores e reguladores

A literatura de Computação Autonômica demonstra que o padrão MAPE-K é adequado para sistemas que precisam monitorar, analisar e corrigir desvios de estado de forma autônoma. No entanto, sua aplicação ao domínio de compliance de segurança cloud — especialmente com governança formal de exceções — permanece pouco explorada, configurando o gap que este trabalho propõe preencher.

Questão de Pesquisa

Como uma arquitetura de referência baseada no padrão autonômico MAPE-K pode apoiar a detecção contínua, remediação automatizada e governança formal de exceções de controles de segurança derivados da ISO/IEC 27002 em ambientes cloud dinâmicos, independentemente do provedor ou ferramenta de infraestrutura como código?

Objetivos

Objetivo Geral

Propor, formalizar e avaliar experimentalmente uma arquitetura de referência autonômica baseada no padrão MAPE-K para compliance de segurança em ambientes cloud, capaz de detectar violações de controles, remediá-las automaticamente e governar exceções temporárias de forma rastreável e auditável.

Objetivos Específicos

1. Formalizar o espaço de estados de compliance como uma partição tripartite — S_nominal, S_violation e S_exception — com transições, invariantes e propriedades de resiliência formalmente definidas
2. Definir uma arquitetura de referência agnóstica a provedor cloud e ferramenta de IaC, especificando o papel, objetivo e justificativa de cada componente do loop MAPE-K
3. Propor um modelo formal de governança de exceções com metacondições, rastreabilidade e reversão automática por expiração temporal
4. Implementar um protótipo da arquitetura de referência em AWS utilizando serviços serverless nativos e OpenTofu como mecanismo de provisionamento e remediação
5. Estabelecer OPA/Rego como fonte única de verdade para avaliação de conformidade, garantindo que a mesma política seja aplicada em tempo de deploy e em runtime
6. Avaliar experimentalmente o impacto da automação no tempo de detecção, remediação e exposição ao risco, comparando com baseline da literatura de vulnerability management
7. Demonstrar a rastreabilidade do ciclo de vida completo de uma violação — da detecção à remediação ou governança de exceção — por meio de Event Sourcing enxuto

Justificativa

Relatórios de segurança como o Verizon DBIR e estudos da Gartner apontam misconfiguration como a principal causa de incidentes de segurança em ambientes cloud, com janelas de exposição tipicamente medidas em horas ou dias quando tratadas por processos manuais. A automação da detecção e remediação — o que a literatura denomina Mean Time to Remediate (MTTR) — é reconhecida como fator crítico de redução de risco em frameworks como o NIST SP 800-137.

Este trabalho justifica-se por três razões:

Lacuna científica: a aplicação do MAPE-K a compliance cloud com modelo formal de exceções como estado de primeira classe não foi identificada na literatura revisada. Trabalhos existentes abordam compliance automation ou policy-as-code, mas sem a formalização do espaço de estados nem o mecanismo de governança de exceções integrado ao loop autonômico.

Relevância prática: o autor atua profissionalmente como CloudOps, conferindo ao trabalho aderência direta aos desafios operacionais reais que a solução proposta endereça.

Contribuição arquitetural: a arquitetura de referência proposta é agnóstica a provedor e ferramenta de IaC, permitindo sua instanciação em múltiplos contextos tecnológicos, o que amplia o alcance da contribuição para além do ambiente experimental específico.

Hipóteses de Pesquisa

H1 — Redução do tempo médio de remediação

Um sistema baseado em MAPE-K reduz o tempo médio de remediação (MTTR) de violações de controles de segurança em ambientes cloud quando comparado ao baseline de processos manuais documentado na literatura.

Métrica: t_remediation = t_Execute_concluído − t_detecção_CloudTrail

Baseline: MTTR de misconfigurations cloud reportado em estudos como Verizon DBIR e literatura de DevOps (Forsgren et al., 2018)

H2 — Governança estruturada aumenta rastreabilidade

A introdução de um modelo formal de exceções temporárias com Event Sourcing aumenta a rastreabilidade e auditabilidade de desvios de compliance em relação a processos sem governança estruturada.

Métrica: completude do violations_log — percentual de eventos com todos os campos preenchidos: actor_arn, origin, t_detection, t_remediation, state_classified, from_state, to_state, event_type

Baseline: processos manuais tipicamente não registram nenhum desses campos de forma estruturada

H3 — Automação reduz o tempo de exposição ao risco

A combinação de detecção contínua via CloudTrail, remediação automática via Execute e governança formal de exceções reduz o tempo total em que recursos permanecem em estado inseguro em relação ao processo manual.

Métrica: t_exposure = t_remediation − t_violation_introduced

H4 — Observabilidade derivada do Knowledge garante consistência

Métrica: percentual de violações introduzidas nos cenários experimentais que foram detectadas pelo Monitor dentro do tempo esperado, comparado com controles que não possuem EventBridge Rule correspondente

Fundamentação Teórica — Principais Teorias

Teorias Primárias

Computação Autonômica e MAPE-K Kephart e Chess (2003) definiram os quatro requisitos de sistemas autônomos — self-healing, self-protecting, self-configuring e self-optimizing — e o loop MAPE-K como modelo arquitetural para realizá-los. O sistema proposto realiza os três primeiros. Self-optimizing é explicitamente excluído do escopo com justificativa: as políticas são estáticas e definidas pelo operador, sem aprendizado automático de thresholds ou prioridades.

Sistemas Autoadaptativos Salehie e Tahvildari (2009) classificam sistemas autoadaptativos por objetivo de adaptação, nível de autonomia e tipo de resposta. O sistema proposto é classificado como goal-based — objetivo declarado de manter S_nominal — com adaptação do tipo corrective para S_violation e preventive para o mecanismo de exceções.

Control Theory O MAPE-K é formalmente um closed-loop feedback controller no sentido da Control Theory. O espaço de estados S é o plant, o controlador é o loop MAPE-K, o setpoint é S_nominal, e o settling time é t_exposure_seconds. Disturbance rejection é a capacidade de neutralizar mudanças manuais fora do pipeline. A propriedade de resiliência formal é equivalente à condição de estabilidade de Lyapunov aplicada ao sistema discreto de estados.

Formal Methods e Runtime Verification O OPA avaliando políticas Rego contra eventos do CloudTrail é funcionalmente equivalente a um runtime model checker — verifica em tempo de execução se o estado atual satisfaz a propriedade formal declarada na política. O violations_log com Event Sourcing produz contraexemplos rastreáveis de cada violação de propriedade.

Governance, Risk and Compliance (GRC) O sistema implementa a camada de compliance do framework GRC: detecta desvios de controles (compliance), produz evidências auditáveis de risco (risk) e garante que a infraestrutura converge para o estado declarado pela política (governance). O modelo de exceções implementa formalmente o mecanismo de risk acceptance do GRC com rastreabilidade obrigatória.

Design Science Research Hevner et al. (2004) definem DSR como metodologia para criação e avaliação de artefatos de TI. O trabalho produz quatro artefatos: o construto formal do espaço de estados, o modelo da arquitetura de referência, o método Compliance-as-Code com fonte única de verdade, e a instância AWS como prova de conceito. A avaliação experimental valida a utilidade dos artefatos.

Teorias de Suporte

Socio-technical Theory: fundamenta o modelo de exceções como mecanismo que reconhece a interdependência entre sistema técnico e necessidades operacionais humanas. Um sistema puramente técnico sem mecanismo de exceção seria socialmente inviável em ambientes de produção reais.

General Deterrence Theory: o mecanismo preventivo via Conftest + OPA no CI/CD e o registro de violações com GitHub Issues criam certeza de detecção e visibilidade de accountability — os dois fatores que a GDT aponta como mais eficazes para dissuasão de comportamentos não-conformes.

Knowledge Security Theory: o Knowledge Base — tabelas controls, exceptions e violations_log — é o ativo mais crítico do sistema. Sua proteção via IAM com menor privilégio, auditoria via CloudTrail e imutabilidade via Event Sourcing é fundamentada por esta teoria.

Chaos Theory: ambientes cloud exibem comportamento sensível a condições iniciais — pequenas mudanças de configuração podem ter consequências de segurança desproporcionais. Sistemas puramente preventivos não conseguem antecipar todas as perturbações possíveis, justificando a abordagem detective-corrective com feedback contínuo.

Agency Theory: o sistema resolve o problema de agência entre o principal (organização que quer compliance) e o agente (operador cloud que quer flexibilidade), reduzindo o custo de monitoramento via automação e alinhando incentivos via modelo formal de exceções com aprovação.

Contingency Theory: a arquitetura de referência não prescreve uma solução universal — ela se adapta ao ambiente de cada organização via controles configuráveis no Knowledge Base e implementações intercambiáveis por provedor cloud.

Modelo Conceitual — Arquitetura de Referência

Definições Fundamentais

R  = conjunto de recursos cloud monitorados
C  = conjunto de controles ativos (Knowledge Base)
E  = conjunto de eventos observáveis (audit log do provedor)
K  = base de conhecimento (controles, exceções, histórico)

Espaço de Estados de Compliance

A infraestrutura cloud é modelada como um espaço de estados discreto onde cada recurso r ∈ R tem um estado σ(r, c) em relação a cada controle c ∈ C:

σ(r, c) ∈ {nominal, violation, exception}

O estado global do sistema é o produto cartesiano de todos os estados individuais:

S = { σ(r, c) | r ∈ R, c ∈ C }

Partição Formal

O espaço de estados é particionado em três conjuntos disjuntos e exaustivos:

S_nominal   = { s ∈ S | ∀(r,c) : σ(r,c) = nominal }
S_violation = { s ∈ S | ∃(r,c) : σ(r,c) = violation }
S_exception = { s ∈ S | ∃(r,c) : σ(r,c) = exception ∧ ∀(r,c) : σ(r,c) ≠ violation }

S_nominal ∩ S_violation = ∅
S_nominal ∩ S_exception = ∅
S_violation ∩ S_exception = ∅
S = S_nominal ∪ S_violation ∪ S_exception

Função de Transição

O sistema evolui por transições disparadas por eventos:

δ : S × E → S

δ(S_nominal,   e_violation)   → S_violation   (mudança não-conforme detectada)
δ(S_violation, e_remediation) → S_nominal     (remediação bem-sucedida confirmada)
δ(S_violation, e_exception)   → S_exception   (exceção aprovada e registrada)
δ(S_exception, e_ttl_expiry)  → S_nominal     (exceção expirada, reversão automática)
δ(S_exception, e_revocation)  → S_violation   (exceção revogada antes do prazo)
δ(S_exception, e_violation)   → S_exception   (nova violação no mesmo recurso com exceção ativa — monitorado, não remediado)

Controlador Autonômico

controller : Ŝ → A

onde:
  Ŝ = estado estimado via eventos + consultas ao provedor cloud
  A = { remediate, escalate, accept_exception, no_action }

O controlador é implementado pelo loop MAPE-K. O estado estimado Ŝ(t) difere do estado real S(t) por uma margem de latência ε decorrente da latência do audit log do provedor — limitação conhecida, declarada e aceitável para o escopo experimental.

Função Objetivo

maximize   T_nominal
minimize   T_violation
constrain  T_exception ≤ TTL_definido

Correspondência com as hipóteses:

H1 → minimize T_violation (MTTR)
H3 → minimize T_violation (tempo de exposição)
H2 → rastreabilidade de todas as transições de T_exception
H4 → completude da cobertura de eventos pelo Monitor

Invariantes do Sistema

I1: ∀ r ∈ R, ∀ c ∈ C :
    σ(r,c) = violation → controller detecta em Δt_detection
                       → controller age em Δt_remediation

I2: ∀ e ∈ EventBridge :
    e ∈ tfstate
    (toda regra de monitoramento existe no estado do IaC)

I3: ∀ c ∈ controls : enabled(c) ↔ ∃ rule ∈ EventBridge : monitors(rule, c)
    (observabilidade é derivada do Knowledge — sem regras órfãs)

Propriedade de Resiliência

Resiliência = capacidade de retornar a S_nominal em tempo finito

Se s ∈ S_violation ∧ ¬escalate(s):
  ∃ T_remediate : T_remediate(s) ∈ S_nominal dentro de Δt ≤ SLA_remediation

Se s ∈ S_exception:
  ∃ T_recover : T_recover(s) ∈ S_nominal dentro de Δt ≤ TTL_exception

Metacondição de Exceção

Estado permitido em S_exception apenas se E(s) = verdadeiro:

E(s) ≡ justificativa_registrada(s)
      ∧ aprovação_formal(s)
      ∧ prazo_definido(s)
      ∧ registro_auditoria(s)
      ∧ timestamp_atual ≤ expires_at(s)

Taxonomia de Controles de Segurança

O sistema realiza as três categorias clássicas de controles:

Preventivo  → OPA + Conftest no CI/CD: bloqueia deploy não-conforme
Detective   → Monitor (CloudTrail + EventBridge): detecta desvio pós-deploy
Corretivo   → Execute (OpenTofu): restaura S_nominal automaticamente

A janela de exposição é uma característica estrutural inerente a controles detective-corrective — não um defeito do sistema. É formalmente o settling time do controlador após uma perturbação (disturbance) no plant.

Componentes do Loop MAPE-K — Objetivo e Justificativa

Monitor

O que é: infraestrutura de observabilidade — não executa código de negócio

Implementação de referência: CloudTrail + EventBridge Rules provisionadas via OpenTofu

Objetivo: capturar eventos de mutação de recursos cloud e dispará-los para o Analyze

Justificativa: o CloudTrail registra toda chamada de API do provedor, independente da origem — console, CLI, SDK ou pipeline. O EventBridge filtra apenas os eventos relevantes para os controles ativos. Essa separação garante que o Monitor é agnóstico à lógica de negócio.

Propriedade crítica — observabilidade derivada do Knowledge: as EventBridge Rules não são configuradas manualmente. Cada controle registrado na tabela controls do DynamoDB carrega seu próprio event_pattern. O OpenTofu lê os controles habilitados via external data source (script Python + boto3) durante o plan e gera exatamente uma Rule por controle habilitado. Quando um controle é desabilitado, o OpenTofu destrói a Rule correspondente. O tfstate é sempre uma projeção fiel do Knowledge — garantindo a invariante I2 e I3.

Argumento de agnósticidade: em GCP, o equivalente é Cloud Audit Logs + Eventarc. Em Azure, é Azure Monitor + Event Grid. O componente Monitor é definido no modelo como “mecanismo de captura de eventos de mutação do provedor” — a implementação específica varia por cloud.

Analyze

O que é: Lambda de classificação de estado — componente cognitivo de percepção

Objetivo: receber o evento bruto do Monitor e classificar o estado do recurso em S_nominal, S_violation ou S_exception

Responsabilidades:

1. Identificar o recurso e o tipo de evento
2. Consultar a tabela controls — quais controles cobrem esse tipo de evento?
3. Buscar o estado atual do recurso via AWS Config (API normalizada, agnóstica ao tipo de recurso)
4. Invocar o OPA com a política Rego correspondente ao controle
5. Consultar exceções ativas na tabela exceptions do DynamoDB (tempo real, sem Bundle)
6. Classificar o estado: S_nominal, S_violation ou S_exception
7. Registrar o evento no violations_log com event_type, from_state, to_state e timestamp
8. Passar o estado classificado para o Plan via Step Functions

O que o Analyze NÃO faz: não conhece ações de remediação, não toca na infraestrutura, não consulta a tabela controls para decidir o que fazer — apenas para contextualizar a avaliação

Separação formal com o Plan: o Analyze é o componente de percepção — responde “o que está acontecendo”. O Plan é o componente de deliberação — responde “o que fazer sobre isso”. Misturá-los viola o princípio de separation of concerns between reasoning and acting da Computação Autonômica.

OPA como motor de avaliação: o OPA recebe o evento e o estado atual do recurso como input e avalia a política Rego correspondente ao control_id. As políticas Rego são carregadas via OPA Bundle do S3 (atualizado a cada mudança na pipeline CI/CD). As exceções são consultadas diretamente no DynamoDB em tempo real — não via Bundle — garantindo consistência imediata.

Argumento de agnósticidade: o OPA é agnóstico ao provedor cloud — avalia qualquer JSON. A política Rego define “o que é conforme” independente de onde o recurso foi criado. Em GCP ou Azure, o Analyze recebe eventos do respectivo audit log, normaliza para o formato input do OPA e avalia a mesma política.

Plan

O que é: Lambda de decisão — componente cognitivo de deliberação

Objetivo: receber o estado classificado pelo Analyze e produzir uma intenção de ação estruturada, sem executar nada

Responsabilidades:

1. Receber o estado classificado e o contexto do Analyze
2. Consultar a tabela controls — qual ação de remediação? qual Stack de remediação?
3. Avaliar condições de decisão: origem da violação (AWSCloudFormation indica template inválido → escalar), severidade do controle, estado de exceção
4. Produzir um plano de ação imutável: { action, resource_id, control_id, remediation_action, stack_template, properties_to_patch }

Ponto de entrada alternativo — TTL expiry: quando uma exceção expira via DynamoDB TTL + Stream, o loop entra diretamente no Plan, pulando o Analyze. O contexto completo está disponível no item expirado do DynamoDB. Não há estado real para avaliar — a decisão é determinística: reverter para S_nominal.

O que o Plan NÃO faz: não toca na infraestrutura, não consulta o estado atual do recurso, não conhece como executar tecnicamente uma remediação

Separação formal com o Execute: o Plan decide O QUE e SE. O Execute decide COMO e FAZ. Essa separação garante testabilidade independente e permite inserir human-in-the-loop entre os dois estados no Step Functions sem modificar nenhum dos componentes.

Execute

O que é: Lambda de atuação — componente motor

Objetivo: executar o plano produzido pelo Plan aplicando remediação via OpenTofu e registrar o resultado no violations_log

Responsabilidades:

1. Receber o plano imutável do Plan
2. Verificar exceções ativas granulares no nível de propriedade — não tocar em propriedades cobertas por exceção de outro controle no mesmo recurso
3. Invocar o OpenTofu com a Stack de remediação correspondente ao controle, passando o resource_id como parâmetro
4. Registrar t_remediation no violations_log com event_type: RemediationStarted
5. Aguardar confirmação via segundo ciclo do CloudTrail (o CloudTrail captura a mudança do OpenTofu, o EventBridge dispara o loop novamente, o Analyze classifica S_nominal e fecha o violations_log com event_type: RemediationConfirmed)
6. Em caso de falha do OpenTofu: registrar remediation_status: failed e encaminhar para escalação via SQS → GitHub Issues

Stack de remediação por controle: cada controle na tabela controls referencia uma Stack OpenTofu dedicada que toca apenas as propriedades que aquele controle governa (properties_affected). Isso garante que a remediação de um controle não interfere nas propriedades de outro controle — incluindo propriedades em S_exception.

Verificação implícita de remediação: o Execute não verifica diretamente se a remediação foi bem-sucedida. O segundo ciclo do CloudTrail — evento gerado pelo próprio OpenTofu ao modificar o recurso — dispara o Monitor, que dispara o Analyze, que classifica S_nominal e fecha o violations_log. A remediação é confirmada pelo próprio loop, não por chamada direta de verificação.

Argumento de agnósticidade: o OpenTofu é agnóstico ao provedor cloud — suporta AWS, GCP, Azure e dezenas de outros via providers. Em outro provedor, apenas o provider do OpenTofu muda; a lógica do Execute permanece idêntica.

Knowledge Base

O que é: base de dados operacional do sistema — componente de memória

Objetivo: armazenar e servir o estado operacional completo do sistema — controles ativos, exceções vigentes e histórico de violações

Implementação de referência: DynamoDB com três tabelas + S3 para OPA Bundle

Tabela controls:

control_id              (PK)
resource_type
domain
iso_27002
nist_800_137
enabled
severity
observability.event_pattern   (consumido pelo OpenTofu para gerar EventBridge Rules)
properties_affected           (limita escopo de remediação por controle)
remediation_action
remediation_stack_template

Papel no sistema: fonte de verdade operacional. O OpenTofu lê esta tabela para provisionar as EventBridge Rules. O Analyze consulta para identificar quais controles avaliar. O Plan consulta para decidir qual ação tomar. O Execute consulta para identificar qual Stack e quais propriedades tocar.

Tabela exceptions:

resource_id    (PK)
control_id     (SK)
justification
approved_by
created_at
expires_at
ttl            (Unix timestamp — DynamoDB TTL nativo)
state

Papel no sistema: árbitro de S_exception. O Analyze consulta em tempo real antes de classificar qualquer violação. O TTL nativo do DynamoDB expira o item automaticamente. O DynamoDB Stream detecta a remoção e dispara o Plan para reverter o recurso a S_nominal.

Tabela violations_log (Event Sourcing enxuto):

pk             (resource_id#control_id)
sk             (sequence#timestamp)
event_type     (ViolationDetected | RemediationStarted | RemediationConfirmed |
                ExceptionGranted | ExceptionExpired | EscalationCreated)
from_state
to_state
actor_arn
origin
payload        (propriedades afetadas, valores antes e depois)
timestamp

Papel no sistema: registro auditável e reconstituível de todas as transições de estado. Cada entrada é imutável e representa uma transição, não um estado final. O estado atual de qualquer recurso pode ser reconstituído reproduzindo os eventos em ordem — Event Sourcing. Esta tabela é a evidência primária para H2.

OPA Bundle no S3: políticas Rego empacotadas e versionadas. Atualizado pela pipeline CI/CD a cada mudança de política aprovada via PR. Carregado pelo Analyze a cada invocação. Separação de responsabilidades: o Bundle carrega o conhecimento estrutural (políticas — mudam raramente). O DynamoDB carrega o estado operacional (exceções — mudam frequentemente e precisam de consistência imediata).

Proteção do Knowledge Base: o Knowledge é o ativo mais crítico do sistema. Sua integridade é garantida por IAM com menor privilégio, auditoria via CloudTrail de todas as operações, validação de schema em todo insert via pipeline CI/CD e imutabilidade do violations_log via Event Sourcing.

Argumento de Agnósticidade

A arquitetura de referência é agnóstica em dois níveis:

Nível 1 — Agnósticidade ao provedor cloud

Componente do modelo    →  Implementação AWS       →  Equivalente GCP        →  Equivalente Azure
Monitor                    CloudTrail + EventBridge    Cloud Audit + Eventarc    Azure Monitor + Event Grid
Analyze (runtime)          Lambda                      Cloud Functions            Azure Functions
Plan                       Step Functions Express      Cloud Workflows            Logic Apps
Execute                    Lambda + OpenTofu           Cloud Functions + OpenTofu Azure Functions + OpenTofu
Knowledge                  DynamoDB                    Firestore                  Cosmos DB

Nível 2 — Agnósticidade à ferramenta de IaC

O OPA avalia qualquer JSON — o input pode ser um plan do OpenTofu, do CloudFormation, do Pulumi ou do CDK. A política Rego define “o que é conforme” independente da ferramenta de IaC. O OpenTofu é escolhido para a implementação de referência por ser open source (licença MPL 2.0), compatível com o ecossistema Terraform e suportado pela CNCF.

Nível 3 — Agnósticidade à norma

A tabela controls mapeia cada controle a múltiplas normas simultaneamente via campos iso_27002, nist_800_137 e domain. O mesmo controle técnico s3-no-public-acl satisfaz simultaneamente ISO 27002 8.9 e NIST SP 800-137 CM-6. A adição de novos campos de mapeamento não requer mudança na lógica do sistema.

Arquitetura de Implementação AWS

Diagrama de componentes

Repositório Git (OpenTofu + Políticas Rego + Controles YAML)
        ↓ pipeline CI/CD
        ├── Conftest + OPA valida plan OpenTofu (preventivo)
        ├── jsonschema valida controles YAML
        ├── OpenTofu apply
        │   ├── EventBridge Rules (derivadas de controls DynamoDB)
        │   ├── Step Functions Express State Machine
        │   ├── Lambdas (Analyze, Plan, Execute, Escalate)
        │   └── DynamoDB (controls, exceptions, violations_log)
        └── Insert de controles no DynamoDB

Monitor: CloudTrail → EventBridge Rules (provisionadas pelo OpenTofu lendo DynamoDB)
        ↓ inicia execução Step Functions
        
Step Functions Express:
  Analyze Lambda
    ├── AWS Config (estado atual do recurso)
    ├── OPA + Rego via Bundle S3 (avalia política)
    └── DynamoDB exceptions (tempo real)
        ↓ ClassifyState (Choice)
        
  S_nominal → LogNominal → fim
  S_exception → LogException → fim
  S_violation → Plan Lambda
    └── DynamoDB controls (remediação_stack, properties_affected)
        ↓ PlanDecision (Choice)
        
  escalate → Escalate Lambda
    └── SQS → Lambda consumer → GitHub Issues API
              → violations_log fecha com issue_url

  remediate → Execute Lambda
    └── OpenTofu apply -target (Stack de remediação por controle)
        ↓ OpenTofu modifica recurso na AWS
        ↓ CloudTrail captura evento (origem: AWSCloudFormation)
        ↓ EventBridge dispara segundo ciclo
        ↓ Analyze classifica S_nominal
        ↓ violations_log fecha com RemediationConfirmed

TTL expiry path:
  DynamoDB TTL expira exception
  → DynamoDB Stream
  → SQS FIFO (deduplicação)
  → Lambda
  → Step Functions inicia no Plan (pula Analyze)
  → Execute reverte recurso
  → segundo ciclo CloudTrail confirma S_nominal

Decisões de design e justificativas

Escopo dos Controles Experimentais

Controles selecionados com correspondência direta à ISO/IEC 27002 e ao NIST SP 800-137, com propriedades tecnicamente verificáveis via AWS Config:

Critérios de seleção: correspondência direta a controles normativos, verificabilidade via API do provedor, remediação tecnicamente possível via OpenTofu, e cobertura de múltiplos domínios da norma.

Cenários Experimentais

Suite de testes por controle

Para cada controle da tabela acima, os seguintes cenários são executados:

Sanity check periódico (H4)

Uma Lambda agendada introduz uma violação controlada em um recurso dedicado ao experimento e verifica se o loop completo é disparado dentro do tempo esperado. Garante que o Monitor está funcionando corretamente durante todo o período experimental.

Métricas de Avaliação

H1 — MTTR

t_remediation = t_RemediationConfirmed − t_ViolationDetected

Estatísticas: média, mediana, desvio padrão por controle
Comparação: baseline da literatura (Verizon DBIR, Forsgren et al. 2018)

H2 — Rastreabilidade

completude = eventos com todos os campos preenchidos / total de eventos

Campos obrigatórios: actor_arn, origin, t_detection, from_state, to_state,
                     event_type, payload, timestamp

Rastreabilidade de exceções: percentual de exceções com fluxo completo documentado
(ExceptionGranted → monitoramento → ExceptionExpired → RemediationConfirmed)

H3 — Tempo de exposição

t_exposure = t_RemediationConfirmed − t_violation_introduced

Estatísticas: média, mediana, desvio padrão
Decomposição: t_detection + t_remediation

H4 — Cobertura do Monitor

cobertura = violações detectadas / violações introduzidas nos cenários

Baseline: 100% esperado para controles habilitados
          0% esperado para controles desabilitados (C9)

Método Experimental

Metodologia: Design Science Research (Hevner et al., 2004) — produção e avaliação de artefatos de TI

Tipo de validação: validação interna em ambiente controlado

Ambiente: conta AWS isolada com recursos provisionados exclusivamente para o experimento via OpenTofu

Baseline: MTTR de misconfigurations cloud documentado na literatura — não simulação de processo manual com operador, evitando viés de medição

Reprodutibilidade: todos os cenários são codificados como scripts de injeção de violação idempotentes, executáveis em qualquer ordem

Tamanho amostral: N repetições por cenário justificadas estatisticamente para intervalo de confiança de 95%

Ameaças à validade:

• Validade interna: variáveis controladas, ambiente isolado, violações determinísticas
• Validade externa: ambiente sintético pode não refletir complexidade de produção — endereçado pelo Apêndice D (estudo de caso exploratório)
• Validade de constructo: t_exposure_seconds mede tempo técnico de exposição, não impacto de negócio
• Validade de conclusão: comparação com baseline da literatura, não com processo manual simulado

Contribuições Científicas

C1 — Modelo formal de estados de compliance cloud

Partição tripartite S_nominal, S_violation, S_exception com função de transição, invariantes e propriedade de resiliência formalmente definidas. Extensão do modelo MAPE-K clássico com estado de primeira classe para exceções temporárias — não identificado na literatura revisada.

C2 — Arquitetura de referência autonômica agnóstica

Especificação formal de uma arquitetura de referência para compliance cloud implementável em qualquer provedor cloud e ferramenta de IaC, com mapeamento explícito entre componentes abstratos e serviços concretos.

C3 — Mecanismo de observabilidade derivada do Knowledge

Padrão de design onde as regras de monitoramento são projeções automáticas dos controles ativos no Knowledge Base, garantindo consistência entre o que o sistema sabe e o que ele observa — sem configuração manual e sem regras órfãs.

C4 — Avaliação experimental do impacto da automação

Validação empírica das hipóteses H1, H2, H3 e H4 com métricas objetivas e comparação com baseline da literatura, produzindo evidências quantitativas sobre o impacto da automação em MTTR, rastreabilidade e cobertura de monitoramento.

Diferencial em Relação a Trabalhos Relacionados

Trabalhos de compliance automation existentes
  → detectam violações, mas não formalizam o espaço de estados
  → não têm modelo de exceções como estado de primeira classe
  → não garantem que observabilidade é derivada do Knowledge

Trabalhos de policy-as-code existentes
  → focam no momento de deploy (preventivo)
  → não têm loop de remediação contínua em runtime

Trabalhos de MAPE-K existentes
  → focam em performance e QoS, não em segurança/compliance
  → não têm Knowledge Base como fonte de verdade para observabilidade

Este trabalho
  → combina as três frentes em um modelo formal único
  → formaliza S_exception como estado de primeira classe
  → garante consistência via observabilidade derivada do Knowledge
  → propõe arquitetura de referência agnóstica e replicável

Estrutura do TCC

Capítulo 1 — Introdução (~15 páginas)

• Contextualização: dinâmica de ambientes cloud e o problema de misconfiguration
• Problema de pesquisa e motivação
• Questão de pesquisa
• Objetivos geral e específicos
• Hipóteses
• Justificativa
• Delimitação do escopo
• Organização do trabalho

Capítulo 2 — Fundamentação Teórica (~30 páginas)

• 2.1 Segurança em ambientes cloud e misconfiguration como classe de vulnerabilidade
• 2.2 Controles de segurança: taxonomia preventive / detective / corrective
• 2.3 Compliance-as-Code, Policy-as-Code e Infrastructure-as-Code
• 2.4 Governance, Risk and Compliance (GRC) como framework organizacional
• 2.5 Computação Autonômica: propriedades self-* e arquitetura MAPE-K
• 2.6 Sistemas Autoadaptativos: taxonomia goal-based e feedback control loops
• 2.7 Control Theory aplicada a sistemas adaptativos discretos
• 2.8 Formal Methods e runtime verification
• 2.9 Socio-technical Theory e o modelo de exceções
• 2.10 Knowledge Security Theory e proteção da base de conhecimento
• 2.11 Design Science Research como metodologia
• 2.12 General Deterrence Theory e mecanismos preventivos
• 2.13 Event Sourcing como padrão de rastreabilidade

Capítulo 3 — Trabalhos Relacionados (~20 páginas)

• 3.1 Compliance automation em ambientes cloud
• 3.2 Policy-as-Code e ferramentas de avaliação
• 3.3 Aplicações do MAPE-K em segurança e infraestrutura
• 3.4 Abordagens de governança de exceções
• 3.5 Posicionamento do trabalho e gap identificado

Capítulo 4 — Modelo Proposto (~30 páginas)

• 4.1 Espaço de estados formal e partição tripartite
• 4.2 Função de transição e modelo de eventos
• 4.3 Controlador autonômico: mapeamento MAPE-K formal
• 4.4 Invariantes e propriedade de resiliência
• 4.5 Modelo formal de governança de exceções
• 4.6 Knowledge Base como fonte única de verdade
• 4.7 Observabilidade derivada do Knowledge
• 4.8 Taxonomia de controles de segurança no modelo
• 4.9 Arquitetura de referência agnóstica

Capítulo 5 — Implementação (~25 páginas)

• 5.1 Mapeamento da arquitetura de referência para AWS serverless
• 5.2 Monitor: CloudTrail, EventBridge e derivação de Rules via OpenTofu
• 5.3 Analyze: Lambda, OPA/Rego e consulta ao DynamoDB
• 5.4 Plan: Step Functions Express e lógica de decisão
• 5.5 Execute: OpenTofu como remediador agnóstico
• 5.6 Knowledge Base: DynamoDB, Event Sourcing e OPA Bundle
• 5.7 Escalação: SQS e GitHub Issues
• 5.8 Pipeline CI/CD: validação de schema, Conftest e provisionamento
• 5.9 Decisões de design e justificativas
• 5.10 Limitações de implementação aceitas

Capítulo 6 — Avaliação Experimental (~25 páginas)

• 6.1 Método experimental e Design Science Research
• 6.2 Ambiente experimental e configuração
• 6.3 Suite de cenários por controle
• 6.4 Resultados — H1: MTTR
• 6.5 Resultados — H2: rastreabilidade
• 6.6 Resultados — H3: tempo de exposição
• 6.7 Resultados — H4: cobertura do Monitor
• 6.8 Discussão dos resultados

Capítulo 7 — Ameaças à Validade (~8 páginas)

• 7.1 Validade interna
• 7.2 Validade externa
• 7.3 Validade de constructo
• 7.4 Validade de conclusão

Capítulo 8 — Conclusão (~10 páginas)

• 8.1 Síntese das contribuições
• 8.2 Limitações do trabalho
• 8.3 Trabalhos futuros

Apêndices

• Apêndice A — Tabela de rastreabilidade ISO 27002 ↔ controles ↔ cenários experimentais
• Apêndice B — Implementação completa: código das Lambdas, políticas Rego, templates OpenTofu
• Apêndice C — Camada preventiva: OpenTofu + Conftest como extensão agnóstica
• Apêndice D — Estudo de caso exploratório: replicação em ambiente de produção (qualitativo)

Trabalhos Futuros

• Extensão para multi-cloud simultâneo com normalização de eventos
• Self-optimizing: aprendizado automático de thresholds e priorização de remediações com base no histórico de violations_log
• Portal de self-service para registro de controles e solicitação de exceções — Platform Engineering / Golden Path
• Modelagem formal do mecanismo de exceções como jogo de barganha (Game Theory)
• Integração com frameworks de risk quantification para calcular risk score por recurso a partir de t_exposure_seconds e severidade

Tags de Referências Bibliográficas Essenciais

• Kephart, J.O.; Chess, D.M. (2003) — The Vision of Autonomic Computing
• Salehie, M.; Tahvildari, L. (2009) — Self-Adaptive Software: Landscape and Research Challenges
• Hevner, A. et al. (2004) — Design Science in Information Systems Research
• Forsgren, N. et al. (2018) — Accelerate: The Science of Lean Software and DevOps
• Verizon DBIR (edição mais recente) — Data Breach Investigations Report
• NIST SP 800-137 — Information Security Continuous Monitoring
• NIST SP 800-53 — Security and Privacy Controls
• ISO/IEC 27002:2022 — Information Security Controls
• Open Policy Agent Documentation — openpolicyagent.org
• OpenTofu Documentation — opentofu.org
• Styra OPA AWS CloudFormation Hook — github.com/StyraOSS/opa-aws-cloudformation-hook