[P2][feature] feat(connector): Google Workspace auditor — content-scan (Drive) + access-audit (Admin SDK Reports)

[FabioLeitao]

[P2][feature] feat(connector): Google Workspace auditor — content-scan (Drive) + access-audit (Admin SDK Reports)

Contexto

Google Workspace é um reservatório massivo de PII não-governado: docs, sheets, slides com CPF/email/dados sensíveis, compartilhados amplamente. Diferente de um scanner de conteúdo puro, o valor aqui é combinar o que tem PII com quem acessou/compartilhou — "tudo que o empregado toca é aferido".

Análogo ao SharePoint connector (já no roster), mas com a camada de auditoria de acesso do jeito Google. Opt-in, Zero Trust, least privilege. Pro/Ent tier.

Encaixe na arquitetura (ref: docs/ADDING_CONNECTORS.md)

Extensão do contrato de conector, dois eixos combinados:

• Eixo conteúdo (o "lado SharePoint"):

  • Drive API (/drive/v3/files) → lista e amostra conteúdo de Docs/Sheets/Slides
  • Cada arquivo/aba tratado como fonte; scanner.scan_column(field, sample) → save_finding(source_type="filesystem", path=<file_path>, file_name=<file_name>, ...)

• Eixo auditoria (o diferencial "a mais"):

  • Admin SDK Reports API (/admin/reports/v1/activity) → quem acessou/editou/compartilhou o quê (audit events)
  • Correlaciona: arquivo com PII + eventos de acesso/compartilhamento externo = achado enriquecido ("CPF neste doc, compartilhado com N externos")

• Módulo connectors/gworkspace_connector.py, classe GoogleWorkspaceConnector

• __init__(self, target_config, scanner, db_manager, sample_limit=5)

• connect() — service account (domain-wide delegation) a partir de target_config; credencial injetada, NUNCA no config

• run() — enumera Drive (conteúdo) + Reports (acesso); combina; salva findings

• registro: register("gworkspace", GoogleWorkspaceConnector, ["name","type"]) + ramo type: gworkspace

Least privilege

• Service account read-only: drive.readonly (ou drive.metadata.readonly para modo metadata-first) + admin.reports.audit.readonly
• Zero write. Domain-wide delegation aprovada pelo admin do Workspace do cliente.

Config (exemplo)

targets:
  - name: gworkspace-corp
    type: gworkspace
    scan_content: true       # Drive API
    scan_access_audit: true  # Admin SDK Reports API
    # service account via env: GWORKSPACE_SA_JSON (nunca no arquivo)

Patterns

Todos os patterns existentes via YAML — zero mudança de código de detecção.

O diferencial (por que combinar os dois eixos importa)

A maioria dos scanners faz content-scan OU access-audit, não os dois juntos. "Achei CPF neste doc E 12 externos acessaram" é um achado que assusta o DPO — combina descoberta com exposição/acesso, que é o que fecha a conversa de risco.

Definição de pronto

• GoogleWorkspaceConnector implementado, registrado, resolvível via type: gworkspace
• Drive content-scan alimenta o output Excel/heatmap existente
• Admin SDK Reports access-audit correlacionado aos findings (arquivo → quem acessou)
• Fixtures sintéticos (Drive mock + audit events mock)
• Service account via env, escopos read-only documentados
• docs/ADDING_CONNECTORS referenciado; config de exemplo

— claude.ai · Auditor R.O. externo (steering/altitude) · Sonnet 5 · A.I.I.D.C.O.B.P.P. v1.4