Auto-hospedagem vs soberano da UE BaaS para uma PME GDPR

Um back-end auto-hospedado em um data center europeu e um BaaS soberano da UE podem marcar as mesmas caixas do GDPR: localização na UE, empresa operacional europeia, DPA disponível (lado do provedor) ou registro interno atualizado (lado auto-hospedado). O GDPR não tem preferência arquitetônica entre os dois. O que realmente muda é quem absorve a carga operacional diária: patch de segurança, backup testado, plantão, supervisão contínua.

A estrutura jurídica completa, GDPR e CLOUD Act, é detalhada em nosso guia de back-end compatível com GDPR e soberano da UE. O que este guia não aprofunda é o real custo operacional de cada opção para uma equipe que não necessariamente possui um SRE dedicado. Este é o ângulo deste artigo.

A auto-hospedagem de um back-end do Postgres transfere toda a responsabilidade operacional para sua equipe, não apenas para o servidor. Concretamente, quatro tarefas surgem repetidamente: aplicar patches de segurança do Postgres assim que forem publicados e testar regularmente uma restauração de backup, e não apenas agendá-la. Também é necessário monitorar continuamente a disponibilidade ou aceitar um tempo de resposta mais longo e alternar segredos e chaves de acesso de acordo com um cronograma documentado.

Essas tarefas nunca desaparecem, mesmo na auto-hospedagem. Você também permanece seu próprio subcontratante técnico em relação ao seu anfitrião (Hetzner, OVH, Scaleway ou outro). Deve existir um DPA e o seu registo de processamento (Art. 30 do RGPD) deve documentar esta cadeia. Uma PME sem uma equipa de infraestrutura dedicada subestima frequentemente este último ponto.

Um BaaS soberano da UE transfere patches, infraestrutura de backup e monitoramento de disponibilidade para o provedor, sob a cobertura de um DPA datado e verificável (Art. 28 do GDPR). É o ónus operacional descrito no ponto anterior que muda de mãos e não a responsabilidade legal.

O responsável pelo tratamento dos dados continua a ser você, independentemente do fornecedor escolhido (Art. 24 do RGPD). Base jurídica para o tratamento, minimização dos dados recolhidos, notificação da violação à autoridade de controlo no prazo de 72 horas (Art. 33 do RGPD): estas decisões são da sua responsabilidade. Um BaaS soberano da UE reduz o tempo necessário para produzir prova de conformidade a um DPO ou cliente. Isso não elimina sua obrigação de ter um.

Muitas equipes comparam apenas duas opções enquanto uma terceira pesa na sua decisão real: um hyperscaler ou um BaaS sob a lei americana, configurado em uma região europeia. O AWS Amplify com uma região eu-west-1, ou serviço equivalente, reduz a latência e atende aos requisitos de residência de dados. Mas isso não altera a nacionalidade da empresa que a opera.

Uma empresa constituída sob a legislação americana permanece sujeita ao CLOUD Act, independentemente da região escolhida por seus clientes. Este ponto é desenvolvido em detalhes em nosso guia compatível com GDPR e back-end soberano da UE e em nosso artigo dedicado por que a Lei CLOUD altera a escolha de seu BaaS. Conta na arbitragem de uma PME, mesmo quando esta opção parece a mais simples no curto prazo.

Aqui estão as três opções realmente disponíveis para uma PME hoje, comparadas nos critérios que mais pesam em uma decisão arquitetônica, e não apenas na caixa de região marcada.

O verdadeiro custo da auto-hospedagem não pode ser lido na conta do servidor. Pode ser lido no tempo do engenheiro desviado do produto, e na exposição jurídica direta em caso de incidente.

Uma PME auto-hospedada torna-se simultaneamente o responsável pelo tratamento dos dados e o seu próprio subcontratante técnico. Um patch Postgres perdido ou um backup nunca testado tornam-se diretamente atribuíveis ao próprio controlador de dados (Art. 83 do GDPR), sem uma cadeia contratual da DPA para se opor à diligência documental. Num fornecedor de BaaS soberano da UE, a mesma falha continua a ser uma exposição real. Mas faz parte de um contrato datado que um DPO ou um auditor pode verificar em poucos minutos, em vez de num histórico interno a ser reconstruído.

A auto-hospedagem continua relevante para um ETI ou uma conta grande que já possui uma equipe de SRE/ops e serviço de plantão funcional. O mesmo se aplica a um sector onde a soberania não tolera qualquer cadeia de subcontratação externa: sector público, defesa, determinados estabelecimentos de saúde. O controle direto do servidor físico tem precedência sobre a velocidade de produção.

Uma empresa que já investiu numa infraestrutura interna de Kubernetes ou Postgres, com competências para a manter, amortiza mais facilmente esta escolha do que uma PME que começa do zero.

Um BaaS soberano da UE é a escolha certa para uma PME sem uma equipa de infraestrutura dedicada, que precisa de demonstrar conformidade rapidamente a um cliente ou DPO. Portanto, ela prefere dedicar seu tempo de engenharia ao produto, em vez de corrigir o Postgres. É também a escolha relevante para uma equipe que prioriza a velocidade de lançamento ao invés do controle total da pilha.

Aurabase não corrige esta escolha em uma direção. A plataforma existe em BaaS gerido soberanamente pela UE, infraestrutura de produção verificada na Alemanha (Nuremberg, Falkenstein) e na Finlândia (Helsínquia) através da Hetzner, operada pela Aurabase SAS, uma empresa constituída sob a lei francesa. Também existe em auto-hospedagem: o repositório fornece um cluster Kubernetes local (k3d) lançado via ./start.she um gráfico Helm completo para Kubernetes, tudo sob a licença MIT.

O mesmo mecanismo PostgreSQL 16, as mesmas políticas RLS e o mesmo SDK se aplicam em ambos os lados: a migração de um modelo para outro não requer a reescrita do seu esquema. Para uma comparação desse modo auto-hospedado com outros back-ends mono-binários nativos do Rust (sh0.dev, TrailBase), nosso artigo Auto-hospedagem soberana: Aurabase contra BaaS nativo do Rust explora esse ângulo arquitetônico em detalhes. Isso permanece focado na decisão do GDPR.

Quatro perguntas operacionais que você deve fazer antes de escolher, além da lista de verificação de verificação de fornecedor em nosso guia GDPR.

Para obter a lista de verificação completa de verificação do fornecedor, incluindo questões legais, consulte nossa Lista de verificação de conformidade com GDPR para um BaaS. Para obter a postura técnica de segurança associada, consulte página de segurança do Aurabase.