Capítulo 42 — Arquitetura de Segurança

42.1 Objetivo do Capítulo

Este capítulo estabelece os princípios, padrões e controles de segurança da Plataforma de Relacionamento Digital com o Cidadão. A segurança não é um componente adicionado ao final — é um requisito transversal que permeia arquitetura, design, desenvolvimento, deploy e operação.

O capítulo cobre: princípios de segurança, Zero Trust, defesa em profundidade, threat modeling, criptografia, controles de acesso, auditoria, conformidade OWASP e NIST, e resposta a incidentes.

42.2 Princípios de Segurança

1. Zero Trust — nenhuma entidade é confiável por padrão. Toda requisição é autenticada e autorizada, independentemente da origem;
2. Defesa em profundidade — múltiplas camadas de controle. Falha em uma camada não compromete a segurança geral;
3. Menor privilégio — cada identidade recebe apenas permissões necessárias para sua função;
4. Assumir comprometimento — arquitetar como se um componente já estivesse comprometido; limitar danos;
5. Criptografia por padrão — dados em trânsito sempre criptografados. Dados em repouso criptografados conforme classificação;
6. Auditoria completa — toda ação sensível é registrada com tenant, usuário, timestamp, resultado;
7. Segurança no design — não é ajuste posterior. Ameaças são identificadas cedo;
8. Conformidade explícita — regulamentações (LGPD, OWASP, NIST) são codificadas nos contratos;
9. Transparência — limites de segurança são conhecidos, documentados e testados;
10. Resiliência — sistema permanece operacional mesmo sob ataque ou compromisso parcial.

42.3 Zero Trust Architecture

42.3.1 Modelo

Usuário      Dispositivo      Rede      Aplicação      Dados
  │             │              │           │             │
  ├─ Identidade Verificada    │           │             │
  ├─ MFA obrigatório          │           │             │
  │                  ├─ TLS 1.3            │             │
  │                  ├─ Device Posture     │             │
  │                  │              ├─ OAuth + PKCE     │
  │                  │              ├─ mTLS             │
  │                  │              ├─ Tenant Context   │
  │                  │              ├─ Autorização      │
  │                  │              │           ├─ Criptografia
  │                  │              │           ├─ Classificação
  │                  │              │           ├─ Auditoria

Cada camada assume que as demais foram comprometidas e funciona de forma independente.

42.3.2 Aplicação no Backend

// Toda requisição segue este fluxo imutável:

1. Autenticação
   └─ Token validado
   
2. Tenant Context
   └─ Tenant validado e propagado em ThreadLocal
   
3. Autorização
   └─ Permissão verificada no contexto do tenant
   
4. Validação de Entrada
   └─ Dados sanitizados
   
5. Execução
   └─ Operação no banco/cache/cache com tenant discriminator
   
6. Auditoria
   └─ Ação registrada com tenant, usuário, resultado

42.4 Criptografia

42.4.1 Em Trânsito

TLS 1.3 obrigatório para toda comunicação:

• entre canais e API Gateway;
• entre serviços internos (mTLS);
• entre aplicação e bancos de dados;
• entre aplicação e caches;
• entre aplicação e provedores externos.

Certificados:

• assinados por CA interna ou CA comercial;
• rotação automática via Cert-Manager;
• versionamento por SAN e wildcard gerenciado;
• validação de certificado cliente em mTLS (revogação via CRL ou OCSP).

42.4.2 Em Repouso

Por classificação de dado:

Gerenciamento de chaves:

• chaves de criptografia em repouso armazenadas em Secrets Management (Vault, AWS Secrets Manager);
• rotação automática periódica;
• chaves antigas preservadas para descriptografia de dados históricos;
• auditoria de acesso a chaves.

42.4.3 Algoritmos e Tamanhos

TLS:       TLS 1.3 (não TLS 1.2)
Assinatura: RSA 2048 ou ECDSA P-256+
Hash:      SHA-256+
AES:       AES-256-GCM
Senha:     Argon2 ou bcrypt
HMAC:      SHA-256

42.5 Autenticação e Autorização

42.5.1 Autenticação Multifator (MFA)

Obrigatório para:

• administradores de tenant (TENANT_ADMIN);
• administradores de plataforma (PLATFORM_ADMIN);
• opcional para cidadãos (voluntário ou exigido por política do tenant).

Fatores suportados:

• TOTP (Time-based One-Time Password);
• envio de código por e-mail;
• envio de código por SMS;
• biometria (mobile);
• chave de segurança FIDO2.

42.5.2 Autorização Granular

Identidade + Tenant + Perfil + Permissão + Recurso + Escopo

Cada dimensão é verificada independentemente. Ausência de qualquer dimensão resulta em negação.

42.5.3 Step-Up Authentication

Operações de alto risco (alteração de e-mail, exclusão de conta, acesso a dados sensíveis) exigem re-autenticação no mesmo fluxo sem logout:

Usuário autenticado
    │
Tenta operação sensível
    │
Step-up: nova autenticação
    │
Operação executada
    │
Sessão mantida (sem logout)

42.6 Proteção contra Ataques Comuns

42.6.1 Injection (SQL, Command, Template)

Mitigações:

• Prepared statements / ORM (nunca concatenação de strings);
• validação de entrada com lista branca de padrões;
• escape de saída conforme contexto (HTML, SQL, URL, JSON);
• Web Application Firewall (WAF) detecta payloads incomuns.

42.6.2 Cross-Site Scripting (XSS)

Mitigações:

• saída renderizada pelo React é sanitizada;
• dangerouslySetInnerHTML proibido sem revisão de segurança explícita;
• Content Security Policy (CSP) ativa: proíbe inline scripts, eval, origens não autorizadas;
• entrada de usuário e conteúdo gerado por IA tratados sempre como dados, nunca como markup.

42.6.3 Cross-Site Request Forgery (CSRF)

Mitigações:

• OAuth 2.0 com Bearer tokens (invulnérável ao CSRF clássico);
• quando cookies utilizados: SameSite=Strict e CSRF tokens;
• estado de mudança sempre via POST/PUT/DELETE, nunca GET.

42.6.4 Insecure Deserialization

Mitigações:

• desserialização JSON apenas de tipos esperados;
• TypeScript strict mode no frontend;
• validação de schema de entrada.

42.6.5 Broken Access Control

Mitigações:

• BOLA (Broken Object Level Authorization) verificado em toda operação de recurso específico;
• autorização no backend, nunca apenas no cliente;
• tenant discriminator obrigatório em queries;
• auditoria de acesso negado.

42.6.6 Security Misconfiguration

Mitigações:

• variáveis de ambiente para toda configuração sensível;
• secrets nunca em código-fonte;
• headers de segurança padronizados (HSTS, X-Content-Type-Options, X-Frame-Options);
• default deny em network policies;
• permissões de arquivo restritivas no servidor.

42.7 Comunicação Segura entre Serviços

42.7.1 mTLS (Mutual TLS)

Serviços se autenticam mutuamente:

Serviço A
  │
  ├─ Valida certificado de Serviço B
  │
  ├─ Serviço B valida certificado de Serviço A
  │
  └─ Comunicação encriptada

Certificados:

• assinados por CA interna;
• rotação automática sem downtime;
• revogação por CRL ou OCSP.

42.7.2 Service-to-Service Authentication

Além de mTLS, identidade de serviço é propagada:

Serviço A (client)
  │
  ├─ X-Service-Identity: api-solicitacoes
  │
  ├─ X-Request-ID: corr-a7f2...
  │
  └─ Serviço B valida identidade

Serviços nunca esperam que outro serviço faça autorização em seu lugar. Cada serviço valida autorização no seu domínio.

42.8 Secrets Management

42.8.1 Armazenamento de Secrets

Secrets nunca em código-fonte. Armazenamento centralizado:

Desenvolvimento:

• .env local (nunca commitado);
• arquivo .gitignore contém *.env;
• documentação descreve variáveis esperadas.

Staging/Produção:

• AWS Secrets Manager, Azure Key Vault ou Vault open-source;
• separação por ambiente;
• credenciais mínimas para acesso.

42.8.2 Injeção de Secrets

Via External Secrets Operator (Kubernetes):

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "https://vault.example.com:8200"
      path: "secret"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "api-solicitacoes"
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: api-solicitacoes-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: api-solicitacoes-env
    creationPolicy: Owner
  data:
  - secretKey: DB_PASSWORD
    remoteRef:
      key: api-solicitacoes/db-password

Secrets são sincronizados, rotacionados e injetados automaticamente.

42.8.3 Rotação de Secrets

Política:

• credenciais de banco: rotação a cada 90 dias;
• tokens de integração: rotação a cada 30 dias;
• certificados TLS: renovação antes da expiração (30 dias antes);
• chaves de API: rotação a cada 12 meses ou em caso de suspeita de compromisso.

42.9 Auditoria de Segurança

42.9.1 Trilha de Auditoria Imutável

Toda ação sensível é registrada:

{
  "timestamp": "2026-07-16T10:30:00Z",
  "tenantId": "tenant-org-a",
  "userId": "user-12345",
  "action": "REQUEST_APPROVED",
  "resourceId": "req-67890",
  "resourceType": "REQUEST",
  "resultStatus": "SUCCESS",
  "ipAddress": "192.168.1.1",
  "userAgent": "Mozilla/5.0...",
  "changes": {
    "status": "PENDING → APPROVED"
  }
}

Registros são imutáveis e armazenados em Audit Store segregado.

42.9.2 Eventos de Segurança

Eventos de segurança geram alertas imediatos:

42.10 Conformidade com Padrões

42.10.1 OWASP Top 10

42.10.2 NIST Cybersecurity Framework

Plataforma alinha-se com NIST CSF:

• Identify — inventário de ativos, gestão de risco;
• Protect — controles de acesso, criptografia, treinamento;
• Detect — logging, monitoramento, detecção de anomalias;
• Respond — plano de incidente, playbooks, comunicação;
• Recover — backup, restore, continuidade de negócio.

42.11 Gestão de Incidentes de Segurança

42.11.1 Plano de Resposta

1. Identificação
   └─ Alerta automatizado ou relatório manual
   
2. Contenção
   └─ Isolar sistema comprometido; evitar propagação
   
3. Investigação
   └─ Forense; entender escopo, causa, impacto
   
4. Remediação
   └─ Corrigir vulnerabilidade; restaurar integridade
   
5. Comunicação
   └─ Notificar stakeholders conforme política
   
6. Post-Incident
   └─ Root cause analysis; melhorias implementadas

42.11.2 Playbooks por Cenário

Cenário: SQL Injection detectada em produção

1. Trigger: WAF detecta payload SQL; alerta crítico
2. Conteção: Aplicação roteada para modo read-only; investigação iniciada
3. Investigação: 
   - Logs de auditoria verificam queries executadas
   - Dados potencialmente expostos identificados
4. Remediação:
   - Rollback para build anterior
   - Patch preparado
   - Testes incluindo exploit replicado
5. Deploy:
   - Canary 10% → 50% → 100%
6. Post-Incident:
   - Code review de queries
   - Aumento de SAST coverage

42.12 Threat Modeling

42.12.1 Metodologia STRIDE

Aplicar STRIDE em cada serviço:

• Spoofing — alguém forja identidade;
• Tampering — alguém altera dados;
• Repudiation — alguém nega ter realizado ação;
• Information Disclosure — dados vazam;
• Denial of Service — serviço fica indisponível;
• Elevation of Privilege — usuário obtém acesso elevado.

42.12.2 Exemplo: Request Service

Ator: Cidadão autenticado
Recurso: Solicitação de outro cidadão

Ameaça: Tentar ler solicitação de outro cidadão (BOLA)
Controle: Verificação de tenant + ACL no recurso
Teste: Enviar request.id de outro tenant → esperado 404

42.13 Rastreabilidade com Anexo III

42.14 Benefícios da Arquitetura de Segurança

• Zero Trust reduz superfície de ataque;
• defesa em profundidade garante que falha em uma camada não compromete segurança geral;
• criptografia por padrão protege dados em repouso e trânsito;
• auditoria imutável fornece rastreabilidade completa;
• conformidade com OWASP e NIST demonstra rigor;
• resposta a incidentes planejada reduz MTTR;
• threat modeling previne falhas de design.

42.15 Riscos e Mitigações

42.16 Decisões Arquiteturais

42.17 Considerações Finais

A arquitetura de segurança não é um fim em si. É o meio pelo qual a plataforma cumpre seu compromisso com usuários e reguladores: proteger dados pessoais, garantir integridade de operações, e detectar e responder a ameaças.

Segurança efetiva resulta de: design defensivo, implementação rigorosa, operação vigilante, e aprendizado contínuo de incidentes.

O Capítulo 43 detalha o IAM — Gestão de Identidade e Acesso como componente especializado.

42.18 Controle de Versão

42.19 Rastreabilidade PRODEMGE

• [ANX-III] Bloco 6 — Segurança, Governança, Acesso: itens 6.1, 6.2, 6.3, 6.4 cobertos conforme seção 42.13.
• [ANX-IV] — Capacidades técnicas de segurança: Zero Trust, autenticação MFA, autorização granular, criptografia, auditoria.
• [ANX-V] Item 2.3 — Proteção do usuário: conformidade com OWASP Top 10, NIST CSF, LGPD.
• [PNR] — Plano de Negócio Referencial: plataforma com segurança por design, defesa em profundidade, conformidade com padrões internacionais.
• [EDITAL] — Edital CP001/2026: plataforma com arquitetura de segurança defensiva, auditoria completa, conformidade regulatória.

42.20 Resumo

O capítulo estabeleceu os princípios, padrões e controles de segurança transversais. Zero Trust, defesa em profundidade, criptografia, auditoria e conformidade com OWASP e NIST são os pilares. O Capítulo 43 aprofunda em IAM como componente especializado.

42.21 Próximo Capítulo

O Capítulo 43 detalha IAM — Gestão de Identidade e Acesso como especialização da segurança.

42.22 Referências

• OWASP Top 10
• NIST Cybersecurity Framework
• CWE/SANS Top 25
• OWASP Mobile Application Security Verification Standard