Segurança e LGPD da ContaClara

BLOCO 1

DPA — Data Processing Agreement em PDF + assinatura digital

O DPA é o contrato técnico-jurídico que define a relação entre a sua empresa (controladora dos dados pessoais na fatura) e a ContaClara (operadora de tratamento, art. 39 LGPD). Sem DPA, sua empresa fica exposta — e o seu DPO sabe disso.

O que está dentro do DPA

• • Identificação completa das partes — sua razão social + nossa razão social AtraND ND Ltda. CNPJ 28.726.886/0001-83
• • Categorias de dados pessoais tratados — CPF de colaborador, número de linha, plano, consumo, endereço. Lista exaustiva, sem "etc."
• • Finalidade específica — consolidar, organizar e governar fatura telecom corporativa. Nada além disso.
• • Base legal aplicada — art. 7º V (execução de contrato) e II (cumprimento de obrigação legal e regulatória)
• • Sub-operadores autorizados — Supabase (DB+auth), Hetzner (infra), Modal Labs (parser), MailerSend (e-mail), Asaas (gateway). Lista pública, 30 dias de aviso prévio.
• • Cláusula de transferência internacional — declaração explícita amparada no art. 33, II LGPD
• • Direitos do titular operacionalizados — fluxo concreto art. 18, SLA até 15 dias úteis
• • Notificação de incidente — 24h cliente, 72h ANPD (Res. CD/ANPD 15/2024)
• • Portabilidade e devolução — export integral self-service · 90 dias pós-cancelamento
• • Auditoria pelo controlador — direito anual sem custo

Como assinar em 5 minutos

Usamos ZapSign (autoridade certificadora ICP-Brasil credenciada) para assinatura digital. Você baixa o DPA, envia o nome do signatário pra dpo@usecontaclara.com.br, abrimos envelope ZapSign preenchido, você assina via e-CPF/e-CNPJ/gov.br Prata-Ouro. Validade jurídica plena (MP 2.200-2/2001 + Lei 14.063/2020).

Sem reunião comercial. Sem "fale com o nosso jurídico". DPA padrão e idêntico para todos os clientes — só mudam os dados de identificação.

Datapoint: o DPA da ContaClara foi minutado em maio/2026 sob revisão jurídica externa especializada em LGPD e telecomunicações. Próxima revisão programada para novembro/2026 — versionamento público em /seguranca/dpa-historico.

BLOCO 3

Isolamento multi-tenant — Row Level Security no Postgres

A maior preocupação técnica do seu coordenador de TI é simples: "se a ContaClara é multi-tenant, como vocês garantem que o cliente A nunca enxergue dado do cliente B?". A resposta é Row Level Security (RLS) do Postgres, ativado em todas as tabelas que carregam cliente_id.

┌──────────────────────────────────────────────────────────┐
│ APLICAÇÃO Next.js (app.usecontaclara.com.br)             │
│                                                          │
│ Usuário autenticado → JWT contém claim cliente_id        │
│ Toda query passa por Supabase Auth → set_config()        │
│ Postgres aplica política RLS automaticamente             │
└────────────────────────────┬─────────────────────────────┘
                             ▼
┌──────────────────────────────────────────────────────────┐
│ POSTGRES 16 (Supabase)                                   │
│                                                          │
│ Tabela cc_faturas:                                       │
│ ┌─────────────┬─────────────┬───────────┐                │
│ │ fatura_id   │ cliente_id  │ valor_brl │                │
│ ├─────────────┼─────────────┼───────────┤                │
│ │ ftr-001     │ cli-A       │  47.328   │ ← cli-A vê     │
│ │ ftr-002     │ cli-A       │  46.910   │ ← cli-A vê     │
│ │ ftr-003     │ cli-B       │  12.450   │ ← cli-A NÃO vê │
│ └─────────────┴─────────────┴───────────┘                │
│                                                          │
│ Política RLS ativa:                                      │
│   CREATE POLICY tenant_isolation ON cc_faturas           │
│     USING (cliente_id = current_setting(                 │
│       'request.jwt.claims', true                         │
│     )::json->>'cliente_id');                             │
│                                                          │
│ → Isolamento APLICADO PELO BANCO, não pela aplicação.    │
└──────────────────────────────────────────────────────────┘

Por que isso é diferente de "isolamento por WHERE no código"

1. Qualquer endpoint que esqueça o WHERE vaza tudo — classe de bug que produz manchete.
2. Migrations, ferramentas administrativas e scripts ad-hoc não respeitam o filtro.
3. Auditor externo não consegue verificar isolamento sem ler todo o código-fonte.

Com RLS, a política é definida uma vez por tabela, no banco. Auditor externo verifica isolamento lendo a definição da política, em SQL, sem mergulhar no código.

Tabelas com RLS ativado hoje

cc_clientes · cc_contas_telecom · cc_faturas · cc_linhas · cc_anomalias · cc_audit_log · cc_assinaturas · cc_pagamentos · cc_planos_assinatura · cc_users_cliente · cc_demo_cliente_public (esta deliberadamente pública sem RLS — apenas dataset fictício Mercearia Tem de Tudo LTDA)

Datapoint: em 16/05/2026, há 47 testes de isolamento RLS rodando a cada commit no monorepo, com cobertura 11 de 11 tabelas tenant-scoped (100%). Logs públicos disponíveis sob solicitação.

BLOCO 5

Audit trail exportável — quem, o quê, quando, onde

Toda alteração relevante é registrada em cc_audit_log, tabela imutável (insert-only) com retenção mínima de 12 meses e exportação self-service em CSV/JSON.

3 casos de uso destravados

1. Auditoria interna — quem aprovou a inclusão de uma linha nova? Quem cancelou a linha do colaborador X?
2. Auditoria contábil/fiscal externa — relatório de 12-36 meses por centro de custo, exportado em segundos.
3. Exercício de direito do titular (art. 18 LGPD) — quem acessou o dado pessoal do colaborador X nos últimos 90 dias.

Estrutura do registro (11 campos)

audit_id (UUID v7) · cliente_id · actor_id · actor_role · event_type · entity_type · entity_id · payload_before (JSONB) · payload_after (JSONB) · ip_origem (mascarado) · occurred_at (timestamptz)

Política de retenção

• Mínima: 12 meses (orientação ANPD)
• Padrão contratual: 24 meses
• Máxima: 36 meses (art. 133 Res. Anatel 632/2014)
• Pós-cancelamento: 90 dias para export self-service

Datapoint: audit trail não é apagável por usuário cliente nem por operador interno. Tabela é insert-only · eliminação só executada por job batch autenticado por chave de sistema separada, com log próprio em cc_system_log — também imutável.

BLOCO 7

Roadmap público de certificações

Transparência vale mais do que credencial inflada. Aqui está o que está cravado, com data:

2026  ─┬─ Q2  Página /seguranca publicada (este documento)
       │     DPA versão 2026-05 disponível para download
       │
       ├─ Q3  Microsoft Entra ID (SSO via OIDC) em produção
       │     Status page (status.usecontaclara.com.br) live
       │
       └─ Q4  Pen test externo por consultoria especializada
              Relatório resumido público em /seguranca/pentest-2026

2027  ─┬─ Q2  ANPD — registro voluntário de operador
       │     Política de mascaramento dinâmico em produção
       │
       └─ Q4  SOC 2 Type II — auditoria iniciada
              Foco: Security + Availability + Confidentiality

2028  ─── Q2  ISO/IEC 27001:2022 — auditoria iniciada
              Escopo: app.usecontaclara.com.br + Hetzner
              Declaração de aplicabilidade (SoA) pública

Por que adiar SOC 2 para Q4/2027

Honestidade técnica: SOC 2 Type II exige observação contínua de controles por no mínimo 6 meses antes da auditoria final. O custo (auditor + tempo interno) faz sentido a partir de aproximadamente 50 clientes ativos. ContaClara está em ramp-up e prefere atender 50 clientes bem antes de pagar SOC 2 sem que isso resolva problema do cliente médio.

Para o cliente que precisa de SOC 2 já, recomendamos esperar Q4/2027 ou considerar consultoria PREMIUM da Adrion Telecom. Não fingimos.