Governança e conformidade

Um certificado que não cobria o que pensavam

Uma startup de saúde contrata um grande provedor de nuvem, vê os selos SOC 2 e ISO 27001 na página de conformidade do provedor, e diz ao conselho que a plataforma é compatível com a HIPAA. Meses depois, uma auditoria de HIPAA de verdade pede os próprios registros de acesso da startup, a configuração de criptografia dela e os registros de treinamento de segurança da equipe, nada que as certificações do provedor jamais alegaram cobrir.

Essa é a mesma lacuna que a primeira lição deste tópico já tinha nomeado como um equívoco, agora acontecendo por completo: a certificação de um provedor prova que a própria infraestrutura dele atende a um padrão. Se a aplicação construída em cima dela atende a esse mesmo padrão é uma pergunta separada, e é exatamente isso que governança e conformidade, como disciplina, existem para responder.

Governança pergunta para dentro, conformidade aponta para fora

Governança é o próprio manual de regras de uma organização para como os recursos de nuvem dela são configurados e usados: quem revisa pedidos de acesso, como os recursos são marcados, qual padrão de configuração todo serviço novo precisa atender antes de entrar em produção. É conduzida internamente, e uma empresa pode ter uma governança forte sem nenhum framework externo envolvido.

Conformidade é diferente: é provar, para um auditor, um regulador, ou o próprio time de compras de um cliente, que as práticas de uma organização atendem a uma régua externa específica. Essa régua pode ser um padrão certificável que uma empresa escolhe buscar, ou uma lei que ela não tem escolha a não ser satisfazer. Boa governança facilita demonstrar conformidade, mas as 2 respondem perguntas diferentes: governança pergunta "estamos fazendo isso de forma consistente", conformidade pergunta "conseguimos provar isso para alguém de fora da organização".

O panorama de conformidade: o que cada framework realmente cobre

ISO 27001 e SOC 2 se sobrepõem bastante nos controles que verificam, o suficiente para um programa de conformidade bem executado muitas vezes satisfazer as 2 sem duplicar o trabalho, mas atendem públicos diferentes: SOC 2 é o que um cliente corporativo americano costuma pedir, ISO 27001 é o que um cliente internacional costuma esperar.

Onde encontrar a metade do provedor na evidência

Um provedor de nuvem não manda os relatórios de conformidade por e-mail quando pedido; ele publica eles em um portal self-service. A versão da AWS se chama AWS Artifact, dando a qualquer conta acesso sob demanda aos próprios relatórios SOC 1/2/3, ISO e PCI da AWS, cada um gerado com uma marca d'água única para quem solicitou. Esse portal é o ponto de partida do cliente quando um auditor pergunta "me mostre os controles do provedor", e é gratuito. O que ele nunca consegue entregar é a outra metade da evidência, a própria configuração, os registros de acesso e os processos internos do cliente, porque o AWS Artifact só documenta o lado da AWS na linha de responsabilidade compartilhada.

Residência de dados versus soberania de dados

Esses 2 termos são usados de forma intercambiável, e a fronteira entre eles vale a pena nomear com clareza. Residência de dados é sobre local físico: onde, geograficamente, os dados estão guardados. Soberania de dados é sobre jurisdição legal: as leis de quem regem esses dados, independente de onde eles estejam de fato.

A GDPR é um bom caso de estudo porque deixa claro qual das 2 ela de fato se importa. A GDPR não exige que dados pessoais da UE fiquem fisicamente dentro da UE. O que ela exige, nas próprias regras sobre transferências internacionais, é que qualquer transferência de dados pessoais para fora da UE ou do EEE receba um nível de proteção equivalente ao que a própria GDPR garante, por mecanismos como uma decisão de adequação cobrindo o país de destino, ou cláusulas contratuais padrão entre quem envia e quem recebe. Uma empresa pode escolher uma região da UE por boas razões operacionais, menos latência para usuários da UE, uma explicação mais simples para os clientes, mas fazer isso resolve a residência, uma questão de local. Não satisfaz, sozinho, a questão legal de transferência que a GDPR está de fato perguntando se esses mesmos dados depois forem copiados, terem backup feito, ou processados em algum lugar fora da UE.

Exemplo prático: escolhendo uma região para dados pessoais da UE

Digamos que um time está construindo um serviço que guarda dados pessoais de residentes da UE. Escolher uma região baseada na UE mantém esses dados fisicamente perto dos usuários e dá uma resposta simples para "onde nossos dados vivem". Mas o time ainda precisa checar todo lugar para onde esses dados viajam depois: uma ferramenta de suporte hospedada fora da UE, um pipeline de analytics em uma região dos Estados Unidos, um backup replicado para outro continente. Cada um desses é uma transferência sob as regras do Capítulo 5 da GDPR, e cada um precisa da própria base legal, uma decisão de adequação para esse destino, ou cláusulas contratuais, não importa quão cuidadosamente a região principal tenha sido escolhida.

Equívoco, revisitado: herdar um selo

A primeira lição deste tópico nomeou esse equívoco no contexto de segurança de forma geral; aqui está o erro específico e recorrente de conformidade: presumir que a certificação de um provedor se transfere automaticamente para o que quer que o cliente construa em cima dela. Nunca se transfere. O AWS Artifact, ou seu equivalente em qualquer outro provedor, entrega evidência dos próprios controles do provedor. O cliente ainda precisa reunir a própria evidência: revisões de acesso, a configuração de criptografia da lição anterior, treinamento de funcionários, processos de resposta a incidentes, tudo o que a HIPAA, a PCI DSS ou o próprio questionário de segurança de um cliente de fato pede para ver.

Dicas para a prova: relacionando um cenário a um framework

Onde isso deixa você

Conformidade nunca é algo que um cliente herda por inteiro do selo de um provedor; é algo montado a partir da infraestrutura certificada do provedor mais os próprios controles do cliente por cima, exatamente a mesma fronteira que o modelo de responsabilidade compartilhada traçou no início, agora aplicada especificamente a provar isso para alguém de fora. Isso fecha o tópico de Segurança na Nuvem: você agora sabe nomear quem é dono de qual tarefa de segurança, como identidade e criptografia impõem essa propriedade, e como governança e conformidade provam que tudo isso resiste a uma auditoria. O próximo tópico deste domínio deixa a segurança para trás e faz uma pergunta bem diferente: depois que um sistema está seguro, como ele continua no ar.