Conformidade SOC 2 para o Google Workspace: O Que Precisa de Saber

Se a sua organização está a candidatar-se à SOC 2 — e a maioria das empresas de software B2B acaba por fazê-lo, porque os clientes o exigem — o Google Workspace estará no âmbito. Este contém identidades, documentos e controlos de acesso que correspondem diretamente aos critérios que um auditor examina. Este artigo explica como o Workspace se integra num programa SOC 2 e como preparar o lado do Workspace sem a corrida de última hora.

Uma nota sobre terminologia, antes de mais: a SOC 2 é uma *atestação* realizada por uma firma de auditoria independente (CPA), não um selo que a própria empresa se atribui. O resultado é um relatório emitido por um auditor, não uma autodeclaração. O que pode fazer internamente é construir e demonstrar os controlos, e reunir as evidências, para que a atestação decorra sem problemas. É sobre isso que trata este artigo.

Uma orientação rápida sobre a SOC 2

A SOC 2 avalia os controlos de uma organização de serviços em relação aos Trust Services Criteria (TSC): Security (sempre incluído, frequentemente designado por Common Criteria) e, opcionalmente, Availability, Processing Integrity, Confidentiality e Privacy. Os critérios de Security — a série CC — são onde o Google Workspace mais se destaca.

Um relatório Type I avalia se os controlos estão *concebidos* de forma adequada num determinado momento. Um relatório Type II avalia se estes *funcionaram eficazmente* durante um período (normalmente 3 a 12 meses). O Type II é o que os clientes geralmente pretendem, e isso tem uma implicação importante: precisa de controlos que funcionem, e de evidências de que funcionaram, ao longo de todo o período — não apenas no dia da auditoria.

Onde o Google Workspace se enquadra nos critérios

Vários Common Criteria correspondem diretamente a controlos do Workspace com os quais já lida:

• CC6.1 — Controlos de acesso lógico. Quem pode aceder a informação protegida e como o acesso é restringido a utilizadores autorizados. Em termos de Workspace: aprovisionamento de contas, aplicação de MFA, controlos de partilha e o acesso detido por cada identidade, incluindo contas externas e de serviço.
• CC6.2 — Registo e autorização. Os novos utilizadores são registados e autorizados antes de lhes ser concedido acesso; o acesso é removido quando já não é necessário. É aqui que se enquadra a boa gestão de entradas, mudanças e saídas de colaboradores.
• CC6.3 — Privilégio mínimo e segregação de funções. O acesso baseia-se em funções e é mantido no mínimo necessário. Acessos com permissões excessivas e a proliferação de privilégios administrativos são falhas identificadas neste critério.
• CC6.6 — Proteção contra ameaças externas. A superfície acessível externamente: links públicos, partilhas externas e acesso concedido a identidades fora da organização.
• CC7.x — Monitorização e resposta a incidentes. Deteção de anomalias e resposta a eventos de segurança. Saber quando ocorrem alterações de partilha ou de acesso, e ser capaz de investigar, dá suporte a estes critérios.

Não precisa de memorizar a numeração. O ponto essencial é que o trabalho quotidiano no Workspace — aplicar MFA, controlar a partilha, remover acessos obsoletos, governar aplicações de terceiros — *é* a evidência de controlo que um auditor quer ver.

O que os auditores realmente pedem

Os auditores não querem garantias verbais; querem evidências. Para os controlos relacionados com o Workspace, espere pedidos como:

• Prova de que a MFA é aplicada (a política e a sua aplicação efetiva, não apenas "ativámos a funcionalidade").
• A lista de administradores e uma justificação para cada função privilegiada.
• Evidência de revisões de acesso — que verifica periodicamente quem pode aceder a dados sensíveis e age em função do que encontra.
• Registos de remoção de acesso quando os colaboradores saem da organização.
• A configuração de partilha e como a partilha externa é controlada.
• Um registo de como as conclusões de segurança são acompanhadas até à resolução.

O tema recorrente é o processo documentado e repetível, com um registo de auditoria (audit trail). Um controlo que existe mas não deixa rasto é difícil de atestar. Um controlo que funciona de forma contínua e regista o que encontrou é fácil de comprovar.

Como preparar o lado do Workspace

1. Estabeleça uma linha de base de configuração. Documente o estado pretendido das suas definições de administração — partilha, verificação em duas etapas, restrições ao Marketplace, autenticação de e-mail — e verifique a realidade em relação a essa linha de base numa cadência regular. O desvio (drift) é o inimigo de uma auditoria limpa.
2. Realize revisões de acesso que consiga comprovar. Reveja periodicamente quem pode aceder a dados sensíveis, incluindo identidades externas e não humanas, e guarde os resultados. "Revimos os acessos trimestralmente, aqui estão os registos" é exatamente o que o CC6.3 exige.
3. Reforce e documente a partilha. Corresponda ao CC6.1 e ao CC6.6 controlando a partilha pública e externa e sendo capaz de demonstrar o estado atual.
4. Acompanhe as conclusões até à resolução. Quando encontrar uma exposição, registe-a, corrija-a e mantenha o rasto. Isto sustenta os critérios de monitorização e remediação.
5. Mantenha um registo de auditoria. Um registo com data e hora das ações relevantes para a segurança torna trivial responder às perguntas de "quem fez o quê, e quando".

Grande parte disto sobrepõe-se a uma boa segurança do Google Workspace em geral — e é precisamente esse o ponto. A SOC 2 não é um projeto separado, encaixado à parte; é a sua prática de segurança, tornada legível e comprovada.

Evidência contínua supera a corrida da auditoria

O erro clássico é tratar a conformidade como um evento: um mês frenético de capturas de ecrã e folhas de cálculo antes da auditoria, repetido anualmente. É estressante, propenso a erros e produz evidências pontuais que um auditor Type II questionará, e com razão.

A alternativa é a via contínua: controlar a postura durante todo o ano, gerar a evidência como subproduto, e chegar à auditoria com o rasto já reunido. Uma ferramenta de postura que mapeia as conclusões para os critérios da SOC 2 e produz evidência pronta para auditoria transforma a corrida numa simples exportação.

Erros comuns na parte do Workspace numa auditoria

Alguns erros surgem repetidamente e vale a pena evitá-los antecipadamente:

• Confundir "configurado" com "aplicado". Ativar uma política de verificação em duas etapas não é o mesmo que ela se aplicar a todas as contas. Os auditores testam esse segundo aspeto. Verifique se a aplicação se mantém em toda a organização — veja o nosso guia sobre aplicar MFA em todo o Google Workspace.
• Tratar as revisões de acesso como uma mera formalidade. "Revemos os acessos" sem registos, âmbito ou seguimento não constitui evidência. Guarde os resultados e demonstre que as conclusões foram tratadas.
• Esquecer as identidades não humanas. As contas de serviço e os agentes de IA também detêm acesso, e um auditor que analise o privilégio mínimo (CC6.3) não aceitará "só revimos as pessoas". Governe-as — veja deteção de agentes de IA de risco.
• Deixar a configuração desviar-se entre auditorias. Uma linha de base que estava limpa em janeiro e se desviou até junho gera uma conclusão negativa numa auditoria Type II. É a verificação contínua, e não uma fotografia anual, que mantém a conformidade.

A conformidade é um subproduto de uma boa segurança

A reformulação mais útil para a parte do Workspace na SOC 2 é reconhecer que não está a construir controlos *para a auditoria* — está a gerir um programa de segurança sólido e a deixar que a auditoria o observe. Tudo o que um auditor quer ver nos critérios de controlo de acesso é algo que desejaria de qualquer forma: identidade aplicada, partilha controlada, acesso de terceiros governado e uma linha de base de configuração mantida. A auditoria simplesmente pede que torne isso legível e comprovado.

As equipas que interiorizam isto deixam de temer o ciclo anual. Os controlos funcionam durante todo o ano, a evidência acumula-se como subproduto, e a auditoria transforma-se numa revisão de um trabalho já feito, em vez de um projeto autónomo. É também essa a diferença, na prática, entre correr contra o tempo e estar preparado.

A 8200.dev mapeia a sua postura no Google Workspace para as famílias de controlos da SOC 2, ISO 27001 e RGPD, e gera pacotes de evidência que pode entregar a um auditor — honestos, limitados ao que efetivamente observamos, nunca uma alegação de conformidade não justificada. Saiba mais sobre como funciona ou sobre as nossas próprias práticas de segurança.

A preparar-se para uma auditoria? Inicie a sua auditoria de segurança gratuita e veja como a postura do seu Google Workspace se enquadra nos critérios de controlo de acesso que os auditores examinam.