Esta lista de verificação detalha dez critérios a serem verificados antes de assinar um backend como serviço (BaaS), com a pergunta precisa a ser feita a cada fornecedor para cada um.
O critério mais frequentemente esquecido é a nacionalidade do fornecedor, distinta da localização dos seus servidores. Uma empresa-mãe americana continua sujeita à Lei CLOUD mesmo que os seus dados sejam executados em servidores em França ou na Alemanha. Nosso guia completo para GDPR e soberania da UE detalha essa distinção legal em profundidade; Esta lista de verificação concentra-se nos pontos operacionais a serem verificados durante uma avaliação de fornecedor.
O essencial
- Uma caixa marcada “região da UE” cobre apenas parte do risco: a nacionalidade da empresa que hospeda os seus dados é igualmente importante face à Lei CLOUD.
- O DPA (artigo 28 do RGPD) é obrigatório assim que um fornecedor processa dados em seu nome, independentemente do tamanho da sua empresa.
- O isolamento entre clientes não é um detalhe de implementação: uma tabela compartilhada com tenant_id não oferece as mesmas garantias que um banco de dados dedicado por projeto.
- Uma certificação “roadmap” não é uma certificação obtida: exija o relatório de auditoria assinado, não uma promessa de marketing.
- Os direitos de acesso, eliminação e portabilidade devem ser exercíveis no autoatendimento: um fornecedor que responde com script SQL personalizado retarda sua própria conformidade.
- A auto-hospedagem elimina o contratante, mas transfere toda a carga operacional de segurança e notificação de violação para sua equipe.
Localização dos dados e nacionalidade do fornecedor
Dois factos distintos determinam a sua exposição legal: onde os dados são armazenados e qual é a nacionalidade legal da empresa que os hospeda. O GDPR rege o primeiro ponto. O American CLOUD Act rege o segundo.
Este texto autoriza as autoridades federais americanas a solicitar dados de qualquer empresa constituída de acordo com as leis americanas, incluindo suas subsidiárias. Isto aplica-se mesmo quando estes dados estão alojados em servidores localizados fisicamente na Europa. Um selo “hospedado na UE” num site de marketing não diz nada sobre a nacionalidade da empresa-mãe.
Aurabase é uma empresa francesa, Aurabase SAS, com sede em Paris. A sua infraestrutura de produção funciona em centros de dados da Hetzner em Nuremberga, Falkenstein (Alemanha) e Helsínquia (Finlândia): soberania da UE. Dois fatos distintos, sede legal e localização de servidores, não se confundindo na mesma diligência.
A pergunta a fazer a qualquer fornecedor: a sua empresa-mãe está registada fora da UE, mesmo que os seus servidores estejam na Europa?
A DPA: o que exige o artigo 28.º do RGPD
O GDPR exige um contrato escrito entre você, o controlador de dados, e seu fornecedor, subcontratado: este é o artigo 28. Sem este documento, você não está em conformidade, independentemente da seriedade técnica do fornecedor em outro lugar.
Um DPA válido especifica a finalidade e a duração do processamento, as categorias de dados e titulares de dados e a lista de subcontratantes. Também detalha as medidas de segurança aplicadas e as obrigações de assistência em caso de solicitação do usuário. Por fim, determina o destino dos dados no final do contrato: eliminação ou restituição.
A Aurabase publica um DPA assinável diretamente do Studio, baseado nas cláusulas contratuais padrão adotadas pela Comissão Europeia (decisão 2021/914). Nosso artigo dedicado ao DPA de um backend como serviço detalha cláusula por cláusula o que verificar antes de assinar.
A lista de subcontratados deve ser pública e notificada
O Artigo 28 do GDPR também exige que seu subcontratado liste seus próprios subcontratados: host, gateway de pagamento, serviço de e-mail transacional. Qualquer alteração deverá ser notificada a você, com direito de oposição.
Exija esta lista por escrito e verifique se cada subcontratante crítico, em particular o anfitrião, também está baseado na UE. Caso contrário, a cadeia de subcontratação recria a exposição da Lei CLOUD que você procurou evitar ao mudar de fornecedor principal.
Isolamento entre clientes: compartilhado ou dedicado?
O isolamento entre os seus dados e os de outros clientes do mesmo fornecedor determina a extensão do vazamento em caso de bug. Existem três arquiteturas, com garantias muito diferentes.
O modelo mais comum, uma grande tabela compartilhada com uma coluna tenant_id, também é o mais frágil. Uma política de RLS mal escrita ou uma consulta sem cláusula de filtro pode expor vários clientes ao mesmo tempo. Uma base por projeto, com sua própria função de conexão, elimina essa classe de bug: o limite é definido no nível da conexão, não em uma cláusula WHERE que um desenvolvedor poderia esquecer.
Neste ponto, cada projeto Aurabase recebe seu próprio banco de dados Postgres, com sua própria função de conexão com escopo definido por search_path injetado do JWT no nível do gateway. Entre duas organizações, o isolamento torna-se físico: cluster Postgres dedicado, namespace Kubernetes separado. Detalhes completos na página Segurança.
Segurança técnica: criptografia, auditorias, recompensa por bugs
O GDPR impõe “medidas técnicas e organizacionais adequadas” (artigo 32), sem listar um padrão preciso. Na prática, três elementos concretos a verificar: criptografia em trânsito e em repouso, a existência de um programa de auditoria independente e um canal documentado de relatórios de vulnerabilidades.
Aurabase criptografa trocas em TLS 1.3 e dados em repouso em AES-256, com opção BYOK (chaves gerenciadas por você via AWS KMS ou HashiCorp Vault) no plano Enterprise. O programa público de recompensas por bugs, hospedado em hunter.dev/aurabase, paga de 200 a 10.000 euros, dependendo da gravidade da falha encontrada. A política de divulgação coordenada dura 90 dias. Um fornecedor sem um canal de denúncia documentado, por definição, não possui auditorias independentes em andamento.
Direitos dos titulares dos dados: autoatendimento ou roteiro manual?
Os artigos 15, 17 e 20 do RGPD garantem aos seus utilizadores finais o direito de acesso, apagamento e portabilidade dos seus dados. A pergunta a ser feita ao seu BaaS: esses direitos podem ser exercidos em autoatendimento ou exigem um script SQL personalizado para cada solicitação?
É você, o responsável pelo tratamento dos dados, quem permanece legalmente obrigado a responder no prazo de 30 dias, mesmo que a infraestrutura subjacente seja opaca. Um provedor que exige um script manual para cada solicitação retarda seu próprio tempo de resposta. Na Aurabase, a exportação e exclusão são acessíveis em Studio → Configurações → Privacidade, ou via privacy@aurabase.cloud para casos mais complexos.
Notificação de violação: prazo legal versus compromisso contratual
O GDPR exige que o controlador de dados, você, notifique uma violação à sua autoridade supervisora dentro de 72 horas após tomar conhecimento dela (artigo 33). Este período só começa quando você for informado pelo seu fornecedor.
O compromisso contratual do fornecedor de notificar é, portanto, tão importante quanto o próprio prazo legal. Solicite o prazo contratual máximo que se compromete a respeitar para notificá-lo de um incidente, e o que esta notificação deve incluir: natureza da violação, categorias e volume aproximado de dados em causa. Este valor deve ser escrito em preto e branco no DPA, e não apenas mencionado oralmente antes das vendas.
Certificações: obtidas ou roteiro?
Uma certificação anunciada em um site de marketing não é o mesmo que uma certificação obtida. Muitos provedores de BaaS comunicam um “roteiro de conformidade” (SOC 2, ISO 27001) sem ter iniciado a auditoria de terceiros correspondente.
Neste ponto específico, a transparência é mais importante do que o anúncio em si. A página Segurança da Aurabase afirma explicitamente que nenhuma certificação de terceiros está comprometida até o momento e publica seu roteiro em um Trust Center dedicado, em vez de exibir um selo não conquistado. Exigir sistematicamente o relatório de auditoria assinado, e não apenas o nome da norma em questão, antes de considerar concedida uma certificação de qualquer fornecedor.
Auto-hospedagem: a conformidade total tem um custo operacional
A auto-hospedagem do seu próprio Postgres elimina a questão do subcontratado, mas não resolve automaticamente a conformidade com o GDPR. A responsabilidade pela segurança, backups criptografados, patches e resposta a violações permanece inteiramente com você.
Para uma equipe sem um SRE dedicado à segurança do Postgres, um BaaS soberano da UE com DPA assinado transfere parte dessa carga operacional para um terceiro auditado, sem sacrificar a jurisdição. Nossa comparação auto-hospedagem versus BaaS soberano da UE quantifica esse compromisso para uma equipe pequena.
Os dez critérios e a pergunta a fazer
Uma versão condensada, útil em reuniões de avaliação de fornecedores ou para construir sua própria grade de auditoria.
| Critério | Pergunta a fazer ao fornecedor |
|---|---|
| Localização E nacionalidade | Onde estão os servidores e onde está registrada a controladora do provedor? |
| DPA (artigo 28 do RGPD) | O contrato de subcontratação é assinado ou apenas mencionado na pré-venda? |
| Lista de subcontratados | É público, atualizado, com aviso em caso de alteração? |
| Isolamento de dados | Tabela compartilhada com coluna tenant_id ou base dedicada por cliente? |
| Criptografia | TLS em trânsito, AES em repouso, opção BYOK disponível? |
| Auditoria independente | Recompensa de bug ativa ou pentest externo datado, com canal de relatórios documentado? |
| Direitos GDPR (acesso, eliminação, portabilidade) | Pode ser exercido em autoatendimento, ou somente via roteiro manual mediante solicitação? |
| Notificação de violação | Qual o prazo contratual máximo escrito a preto e branco no DPA? |
| Certificações | Obtido com relatório de auditoria assinado ou apenas como roteiro? |
| Responsável pela conformidade | BaaS soberano da UE auditado ou auto-hospedagem com a carga operacional assumida internamente? |
Perguntas frequentes: conformidade com GDPR e escolha de um BaaS
Próxima etapa
Nenhum desses dez critérios é suficiente isoladamente para garantir a conformidade com o GDPR para um back-end como serviço. É a sua combinação, verificada ponto a ponto, em vez de deduzida de um selo de marketing, que constrói uma avaliação séria do fornecedor.
Para obter informações jurídicas completas entre a região de hospedagem e a nacionalidade do fornecedor, acesse nosso GDPR e guia de soberania da UE. Para obter detalhes sobre as medidas técnicas de segurança mencionadas nos critérios 4 e 5, a página Aurabase Security continua sendo a referência atualizada.