Araúz Advogados Security & Cloud
Security & Cloud Araúz{{ tituloVista }}{{ chipVista }}
Security & Cloud Araúz · Dossiê para auditoria · 08 de setembro de 2026

A segurança só é uma decisão quando deixa evidência.

Este office consolida a visão do CTO para identidade, AppSec, dados, borda e nuvem. Ele separa arquitetura homologada, estado declarado e prova operacional — o recorte que Paulo, da Relieve, precisa revisar antes da auditoria.

Custódia executivaGabriel · CTO Office, com Murilo · DPO
Consultoria e infraestruturaPaulo · TI Infra & AppSec · Relieve
Fonte de decisãoGovernance & Security Platform · CTO Master Plan
Regra de leituraHomologado não substitui evidência anexada.
Fronteira do documentoEsta página organiza a revisão. Evidências técnicas, exportações de tenant e logs devem permanecer em pacote de acesso controlado.
5Pilares defensivosIAM, AppSec, segredos, LGPD e borda/cloud
6Security gatesGitleaks, SAST, dependências, RLS, LGPD e threat model
S0–S3Semáforo LGPDClassificação que define armazenamento, logs e acesso
4Ondas de evoluçãoFundação, AppSec, Zero Trust e resiliência
1Gate de saídaG0 antes de abrir a próxima onda
Visão executiva

Seis lentes organizam o que a banca precisa governar antes de escalar.

A banda intermediária separa padrão, princípio, ferramenta, obrigação, capacidade cloud e execução. O conteúdo abaixo é uma projeção executiva; evidências técnicas, contratos, exportações e logs permanecem no pacote controlado.

01 · PADRÕES

Baseline de segurança

OWASP, headers HTTP, CORS/CSRF, RLS, secrets, ZDR e os ADRs de IAM, dados, IA e borda.

Estado: declarado · evidência por aplicação pendente.
02 · FUNDAMENTOS

Princípios que não variam

Zero Trust, menor privilégio, defesa em profundidade, Privacy by Design, separação e AI Safety.

Estado: fundamento canônico · revisão operacional contínua.
03 · FERRAMENTAS

Catálogo de defesa

Entra ID, Cloudflare, Gitleaks, CodeQL/SonarCloud, auditoria de dependências, Docker, PWS, PostgreSQL/RLS e telemetria.

Estado: catálogo homologado · uso real a comprovar por app.
04 · COMPLIANCE & LEGAL

Obrigação contextualizada

LGPD/ANPD, sigilo profissional, OAB, Provimento 205, DPA, Zero-Training e Semáforo S0–S3.

A reconciliar: a definição canônica do S0–S3 ainda diverge entre fontes.Fiscal/tributário: mapeamento específico ainda não consta nas fontes canônicas consultadas.
05 · CLOUD & EXPANSÃO

Capacidade para crescer

PWS, Docker, Local/DEV/HML/PRD, Cloudflare, TLS/mTLS, PostgreSQL 16, backup, DR e observabilidade.

Estado: padrão necessário · inventário e capacidade futura pendentes.
06 · ROADMAP & GATES

Da fundação à escala

O0 Fundação, O1 AppSec/CI, O2 Zero Trust e O3 Resiliência, conectados aos Gates G0–G3.

Estado: cronograma macro definido · tarefas e evidências em consolidação.
01 · O mapa

A blindagem funciona como uma cadeia, não como um produto isolado.

A arquitetura canônica encadeia identidade, perímetro, aplicação, dado, segredo e auditoria. A falha de uma camada deve ser contida pela seguinte; a auditoria deve conseguir provar o caminho completo.

01

Identidade

Entra ID, SSO, MFA, Conditional Access e grupos `SG-ARAUZ-*`.

02

Borda e cloud

Cloudflare WAF/Zero Trust na borda e workloads conteinerizados na PWS.

03

Aplicação e dado

Headers, CORS, CSRF, RLS, mascaramento, ZDR e telemetria auditável.

02 · Domínios de controle

Cinco domínios organizam a revisão de Paulo.

Cada domínio tem um dono, uma pergunta de validação e um artefato mínimo. O status abaixo é status de planejamento/documentação; nenhum item vira “validado” sem evidência anexada.

Em revisãoA confirmarNão emitido
SC-01 · EM REVISÃO

Identidade e acesso

Entra ID, MFA, Conditional Access, grupos e contas de emergência.

Evidência: export de políticas, grupos e logs de SSO.
SC-02 · A CONFIRMAR

Borda e continuidade

Cloudflare, PWS, TLS/mTLS, inventário, backup e DR.

Evidência: inventário, regras, backup e teste de restauração.
SC-03 · A CONFIRMAR

DevSecOps

Branch Protection, Gitleaks, SAST, dependências e waivers.

Evidência: runs de CI, configurações e exceções vigentes.
SC-04 · A CONFIRMAR

Dados e LGPD

Semáforo S0–S3, mascaramento, retenção, ACL e ZDR.

Evidência: matriz, amostras mascaradas e trilha de acesso.
SC-05 · A CONFIRMAR

Monitoramento e resposta

Logs, correlação, incidentes, alertas e revisão periódica.

Evidência: runbook, alertas, incidentes e ata de revisão.
03 · Onda e gate

O roadmap declara maturidade progressiva, com um gate antes de cada salto.

A visão registrada pelo CTO coloca a Onda 0 como concluída/homologada, a Onda 1 em andamento, a Onda 2 como próximo ciclo e a Onda 3 como evolução futura. Essa distinção deve permanecer visível na auditoria.

O0

Fundação

Entra ID/MFA, hooks e Semáforo. Declarada concluída.

O1

AppSec

SG-01 a SG-06, headers, RLS e mascaramento. Em andamento.

O2

Zero Trust

Cloudflare Access, WAF em bloqueio e anti-prompt injection.

O3

Resiliência

SOC 2/ISO 27001, detecção autônoma e resposta a incidentes.

04 · Exit Gate G0

A Onda 1 só abre quando o Board assina o que foi comprovado.

A story `cto-E05-S04` define o Gate G0 como cerimônia de homologação. Esta seção converte o requisito em checklist de revisão para Paulo, Murilo e Gabriel.

IDCritério de aceiteEstado
G0-01Dossiê de nuvem PWS e evidências de infraestrutura compilados.A confirmar
G0-02SSO/SCIM Entra ID, grupos e políticas M365 validados por Paulo.A confirmar
G0-03Branch Protection, Gitleaks e Semáforo LGPD com evidência de execução.A confirmar
G0-04Termo de homologação assinado por Gabriel, Murilo e Paulo.Não emitido
05 · Ledger de evidências

A revisão só fecha quando cada controle tem ID, dono, resultado e próxima ação.

O ledger abaixo é a fila de validação. Ele não contém logs nem exportações; apenas define o contrato que o pacote privado deve cumprir.

ID / controleProva mínimaAceite
EV-01 · Entra ID/MFAExport datado de políticas, grupos, contas privilegiadas e log de SSO.Paulo · pendente
EV-02 · PWS/DRInventário, matriz de acesso, backup, restauração e teste de desastre.Paulo/Gage · pendente
EV-03 · CI/CDRuns SG-01 a SG-06, Branch Protection, Gitleaks e registro de exceções.Security/DevOps · pendente
EV-04 · LGPDMatriz S0–S3, retenção, ACL e amostras de logs mascarados.Murilo/Paulo · pendente
EV-05 · IncidentesRunbook, alertas, canais, último teste e ata de revisão.CTO/Sec · pendente
06 · Revisão de Paulo

A auditoria começa pelas lacunas entre “homologado” e “comprovado”.

As perguntas abaixo são o handoff do CTO Office. Elas não reescrevem a política de segurança; pedem a evidência de que a política está aplicada no ambiente real.

01

Tenant e identidade

Entra ID é o provedor efetivo de todos os apps? MFA, grupos e break-glass estão revisados?

02

Cloud e continuidade

A PWS tem inventário, backup, DR testado, hardening e trilha de acesso que possam ser apresentados?

03

Gates e exceções

Os SG-01 a SG-06 executam no CI? Há waivers, vencimentos, responsáveis e aprovação conjunta registrada?

Critério de fechamento

Nenhum controle deve ser marcado como concluído apenas porque aparece na arquitetura. Fechamento exige evidência datada, escopo, responsável, resultado e próxima revisão.

Security & Cloud Araúz · documento de trabalho para auditoriaFonte: `governance-security-platform` · Planos 00, 02, 03, 11, 13 e 14