[feature][connector] Google Workspace connector via Vault API (admin-governed, forensic-complete)

[FabioLeitao]

Contexto / origem

Caso real de um DPO (parceiro): Google Workspace com documentos compartilhados, pastas "pessoais" de usuários, e prompts Gemini possivelmente abusados (PII colada em IA). O admin precisa auditar dado vivo dos usuários sob governança central. O Data Boar tem conector SharePoint/M365 (admin-governed) mas nenhum conector Google Workspace.

Proposta

Conector GoogleWorkspaceVaultConnector (connectors/google_workspace_connector.py) usando a Google Vault API — não a Drive/Gmail API direta.

Por que Vault API e não Drive/Gmail direto:

• Drive/Gmail direto exigiria impersonar cada usuário (DWD por-usuário), é lento, e não garante completude (deletados/versões/fora-de-escopo ficam de fora).
• Vault API foi desenhada pro caso "admin audita dado sob governança central" com completude formal + proof-of-correspondence (prova de que o export corresponde ao dado nos servidores Google) + matter = container de eDiscovery com audit-trail nativo imutável.
• Cobre Gmail/Drive/Calendar/Chat/Meet/Groups/Voice/Sites + dado do app Gemini (governança de uso de IA — ângulo novo e relevante ao "AI-data-readiness").

Divisão de valor (o que o Boar adiciona)

Vault entrega o dado (completo, com prova). O Boar entrega o RISCO: escaneia os artefatos exportados (pipeline padrão) e produz o relatório de PII/PCI/PHI + exposição pro DPO. Vault sozinho não diz "há 4.000 CPFs numa pasta compartilhada com o domínio inteiro".

Arquitetura (fluxo)

GoogleWorkspaceVaultConnector
  auth: OAuth2 service account + domain-wide delegation + Vault API scope
  fluxo:
    1. cria Matter (um por scan/sessao)
    2. cria Export com query de escopo (OU, usuario, data, keyword)
    3. polling ate export completar
    4. baixa artefato (bucket Cloud Storage temporario)
    5. escaneia com o pipeline padrao do Boar
    6. grava matter_id + export_id no finding -> rastreabilidade cruzada

Modelar no connectors/sharepoint_connector.py (precedente admin-governed) + registrar em core/connector_registry.py.

Escopo HONESTO (verificado no repo em 0a841682 — sem overstate)

• ✅ integrity_events já existe (core/integrity_anchor.py, core/audit_export.py, ADR-0037) → o conector grava matter_id/export_id no audit-log real.
• ⚠️ Attestation Ed25519 NÃO está no repo — conceito de ecossistema/roadmap. Não alegar que a DB atesta findings hoje.
• ⚠️ Access-intelligence ("quem tem acesso") = trabalho SEPARADO — Vault dá o dado+prova; o grafo de compartilhamento vem da Drive API + Directory API (ACLs/grupos/OUs). Fase 2.
• ⚠️ Colisão de nome: a DB já usa "vault" pra secrets (docs/plans/PLAN_SECRETS_VAULT.md). Google Vault é outro conceito → nomear com cuidado (google_workspace_connector / classe GoogleWorkspaceVaultConnector).

Pré-requisitos / caveats (documentar no PLAN)

• Cliente precisa de licença Vault (Google Workspace Business Plus / Enterprise).
• DWD lê a org inteira → super-admin do cliente configura; documentar o modelo de consentimento/escopo (paridade com SharePoint/M365).
• Híbrido: fetch dos exports é cloud (API Google), mas o scan/inteligência é LOCAL (mantém o ethos local-first no que importa). Documentar essa fronteira explicitamente.
• Export é async/batch (horas + potencialmente GB) → pipeline batch, com polling + retomada.

Roadmap fásico

• v1 — Vault matter→export→download→scan + matter_id/export_id no integrity-log (Gmail/Drive primeiro; depois Chat/Meet/Gemini).
• v2 — access-exposure: cruzar com Drive/Directory API → "PII X exposta a N pessoas/grupos".
• v3 — attestation dos findings (quando o eixo de attestation do ecossistema aterrissar).

Acceptance Criteria

• connectors/google_workspace_connector.py (v1: matter→export→scan) modelado no sharepoint_connector.py, registrado em core/connector_registry.py.
• Testes: verificar via gh se tests/test_google_workspace_connector.py já existe; se não, criar novo.
• docs/plans/PLAN_GOOGLE_WORKSPACE_VAULT_CONNECTOR.md com <!-- plans-hub-summary: ... --> (roadmap fásico v1/v2/v3 + caveats licença/DWD/híbrido/async).
• python scripts/plans_hub_sync.py --write
• Entry em docs/plans/PLANS_TODO.md.
• Doc do modelo de consentimento/escopo (paridade SharePoint/M365).

---

Origem: caso real de DPO + análise A.I.I.D.C.O.B.P.P. (claude.ai propôs contexto fresco; Claude-Code-local verificou via gh/grep antes de abrir). Enquadramento verificado contra o repo em 0a841682. Claude = RO auditor; execução é do Cursor.