Conformidade RGPD em Armazenamento Cloud: Guia Essencial
Melhores práticas para armazenamento cloud em conformidade com o RGPD, incluindo encriptação, controlo de acessos, localização dos dados e avaliação de fornecedores.
O armazenamento cloud em conformidade com o RGPD exige cinco controlos em camadas: (1) encriptação em repouso com AES-256 e em trânsito com TLS 1.3, idealmente complementada por encriptação do lado do cliente para dados sensíveis; (2) um Contrato de Subcontratação com o fornecedor que respeite o Artigo 28.º(3); (3) residência de dados documentada — habitualmente UE/EEE para dados pessoais europeus — com transparência de sub-subcontratantes; (4) controlos de acesso granulares com MFA, permissões baseadas em funções e registos de auditoria conservados durante pelo menos seis meses; (5) deteção de violações capaz de cumprir a janela de notificação de 72 horas do Artigo 33.º. A falha em qualquer camada transforma o nível de armazenamento no ponto mais fraco da sua pilha de conformidade.
Escolher um fornecedor conforme com o Artigo 28.º
O mercado europeu de proteção de dados divide os fornecedores em categorias bem definidas. Os hiper-escaladores (AWS, Azure, Google Cloud) oferecem CS abrangentes e regiões europeias, mas estão sujeitos à exposição do CLOUD Act. Os fornecedores europeus soberanos (OVHcloud, Scaleway, Infomaniak, Hetzner, IONOS) evitam a jurisdição norte-americana e têm frequentemente certificações C5, SecNumCloud ou ISO 27001. Os fornecedores especializados focados na privacidade (Tresorit, Proton Drive, Internxt, Nextcloud alojado) acrescentam arquitetura de conhecimento zero. Escolha com base na sensibilidade dos dados: registos médicos e dados de defesa requerem fornecedores soberanos ou de conhecimento zero; ficheiros empresariais gerais funcionam em hiper-escaladores com configuração adequada.
Encriptação do lado do servidor versus do lado do cliente
A encriptação do lado do servidor — AWS S3 SSE-KMS, Azure Storage Service Encryption, chaves geridas pelo cliente no Google Cloud — protege contra o roubo físico de discos, mas não contra colaboradores do fornecedor com acesso às chaves nem contra compelência legal ao fornecedor. A encriptação do lado do cliente com chaves que o fornecedor nunca vê (XChaCha20-Poly1305 no Tresorit, AES-256-GCM com derivação de chave PBKDF2-SHA-256 na HexaTransfer) garante proteção de conhecimento zero. Para dados de alta sensibilidade ao abrigo do Artigo 9.º (saúde, biometria, opiniões políticas), o lado do cliente é a opção predefinida conforme; o lado do servidor isolado é marginal.
Configurar o AWS S3 para o RGPD
O S3 não é conforme de raiz. Para dados pessoais da UE, defina a região do bucket como eu-central-1 (Frankfurt), eu-west-1 (Irlanda), eu-west-3 (Paris) ou eu-south-1 (Milão). Ative a encriptação predefinida com SSE-KMS utilizando uma CMK gerida pelo cliente com rotação de chaves. Bloqueie o acesso público ao nível da conta. Configure o Object Lock para armazenamento de conformidade imutável onde a retenção é legalmente obrigatória. Ative os registos de acesso ao S3 e o AWS CloudTrail para auditoria. Utilize pontos finais de VPC para que o tráfego nunca transite pela internet pública. Desative o S3 Transfer Acceleration a menos que consiga provar que as caches de borda do CloudFront permanecem na UE.
Equivalentes no Azure e no Google Cloud
Azure: escolha a Europa Ocidental (Amesterdão) ou a Europa do Norte (Dublin), ative a encriptação com chaves geridas pelo cliente via Key Vault, configure pontos finais privados, defina a Política do Azure para negar implementações fora da UE, e ative o Microsoft Defender para Armazenamento. Google Cloud: escolha europe-west1 (Bélgica), europe-west3 (Frankfurt) ou europe-west9 (Paris), ative chaves de encriptação geridas pelo cliente via Cloud KMS, use VPC Service Controls para impedir exfiltração, e ative os Cloud Audit Logs. Ambos os hiper-escaladores publicam guias de configuração específicos para o RGPD; siga-os na íntegra, sem improvisar.
Controlos de acesso ao abrigo do Artigo 32.º(1)(b)
O acesso baseado em funções é a linha de base. Cada identidade — humana ou de serviço — deve ter o mínimo de privilégios com âmbito definido para um bucket, prefixo ou pasta específicos. O MFA é obrigatório para acesso à consola e recomendado para chaves de API via tokens de sessão. Os fluxos de trabalho de entrada-movimentação-saída integrados com o seu fornecedor de identidade (Okta, Azure AD, Google Workspace) impedem acessos desatualizados. As revisões trimestrais de acessos detetam expansões de âmbito. Para ficheiros altamente sensíveis, o acesso de emergência com aprovação dupla e expiração automática de privilégios elevados após 4 a 8 horas limita os danos de contas de administrador comprometidas.
Políticas de retenção adequadas à finalidade
O Artigo 5.º(1)(e) (limitação da conservação) obriga a eliminar dados quando a finalidade do tratamento expira. O armazenamento cloud torna a retenção indefinida tentadora — o armazenamento é barato. Crie políticas de ciclo de vida que imponham retenção vinculada à finalidade: 30 dias para zonas de entrega transitória, 13 meses para anexos de apoio ao cliente, 7 anos para faturas (lei fiscal), 10 anos para registos médicos em algumas jurisdições. As regras de ciclo de vida do S3, a Gestão do Ciclo de Vida do Azure Blob e o Ciclo de Vida de Objetos do GCS automatizam tudo isso. Combine com Object Lock para conformidade WORM quando a retenção é legalmente exigida.
Gestão de chaves de encriptação
As chaves são o centro de gravidade. Quem detém a chave detém os dados. Ao abrigo do RGPD, a custódia das chaves determina se o fornecedor de armazenamento é um subcontratante (pode desencriptar) ou apenas um condutor de dados (detém texto cifrado). Utilize armazenamentos de chaves com HSM (AWS KMS, Azure Key Vault HSM Gerido, Google Cloud HSM) para cenários geridos pelo servidor. Para conhecimento zero, derive chaves no browser através da PBKDF2 da API Web Crypto ou Argon2id (crypto_pwhash da libsodium) e nunca as transmita. Rode as chaves anualmente ou quando pessoal com acesso sair. Documente a custódia das chaves no seu RoPA ao abrigo do Artigo 30.º.
Encriptação e residência das cópias de segurança
As cópias de segurança quebram frequentemente as histórias de residência e encriptação. Um bucket em eu-central-1 com uma regra de replicação entre regiões para us-east-1 para "resiliência" transferiu todos os ficheiros para os EUA sem atualizar o CS. Verifique as configurações de CRR e defina os destinos dentro do EEE — eu-west-1 (Irlanda) e eu-central-1 (Frankfurt) complementam-se naturalmente. Encripte as cópias de segurança com uma chave separada do armazenamento primário, de modo que o comprometimento de uma chave não revele ambas as cópias. Teste a restauração trimestralmente; uma cópia de segurança irrestaurável é pior do que nenhuma para fins de recuperação de desastres.
Deteção de violações que cumpra as 72 horas
O prazo de 72 horas do Artigo 33.º começa quando "toma conhecimento". As ferramentas de deteção reduzem o intervalo entre a violação e o conhecimento. O CloudTrail + GuardDuty na AWS, o Microsoft Defender for Cloud no Azure e o Security Command Center Premium no GCP assinalam padrões de acesso invulgares — transferências em massa, acesso de novas localizações geográficas, chaves utilizadas fora do horário de trabalho. Encaminhe alertas para um SOC disponível 24/7 ou pelo menos para uma rotação de plantão. Para organizações de menor dimensão, os serviços de deteção e resposta geridos (Arctic Wolf, Red Canary) colmatam a lacuna. Documente o guia de procedimentos: quem notifica a autoridade de proteção de dados, quem redige o formulário do Artigo 33.º, quem comunica aos titulares ao abrigo do Artigo 34.º.
Lista de verificação de avaliação de fornecedores
Antes de assinar um contrato de armazenamento cloud, exija: (1) CS conforme com o Artigo 28.º cobrindo as oito matérias; (2) certificado ISO 27001 com declaração de âmbito; (3) relatório SOC 2 Type 2 (o Type 1 é insuficiente — testa a conceção, não a operação); (4) compromisso de residência de dados na UE com centros de dados identificados; (5) registo de sub-subcontratantes com jurisdições; (6) prazo de notificação de violações publicado (preferência por ≤24 horas); (7) documentação de encriptação incluindo gestão de chaves; (8) direitos de auditoria ao abrigo do Artigo 28.º(3)(h). A HexaTransfer publica todos os oito na sua página de confiança; alternativas respeitáveis (Tresorit, Proton, Infomaniak) fazem o mesmo.
Trate a página de confiança do fornecedor como um contrato — se estiver ausente, o fornecedor não está a levar isso a sério. Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.
Envie arquivos grandes com segurança e criptografia de ponta a ponta
Transfira arquivos de até 10 GB gratuitamente com criptografia de ponta a ponta. Sem necessidade de conta. Seus arquivos são criptografados no navegador antes do envio — ninguém mais pode lê-los.
Enviar um arquivo