--- title: "O Supabase cumpre o HIPAA? O que o BAA deixa consigo" description: "Supabase HIPAA: assina um BAA no plano Team com o complemento HIPAA. Dez deveres continuam seus, do PITR aos logs. Quais vê um verificador gratuito." url: "https://madsalt.tech/pt/blog/is-supabase-hipaa-compliant/" author: "Denys Zaichenko" author_url: "https://madsalt.tech/pt/about/" language: "pt" published: 2026-11-03 --- # O Supabase cumpre o HIPAA? O que o BAA deixa consigo Em resumo Sim, o Supabase alojado pode guardar dados de saúde: assina um Business Associate Agreement (BAA) no plano Team e superiores, depois de ativado o complemento HIPAA. O Supabase auto-alojado não está coberto. O BAA não configura o seu projeto. O modelo de responsabilidade partilhada do Supabase enumera dez deveres que ficam consigo, entre eles point-in-time recovery, a imposição de SSL, as restrições de rede e o registo de ligações do Postgres. Destes dez, o meu verificador gratuito do Supabase assinala 3 diretamente, 2 só em parte e não consegue ver os outros 5. Sou o Denys, engenheiro full-stack e de IA, e a maioria das apps que construo ou corrijo corre em Supabase. Quando uma app de saúde ou bem-estar pergunta se pode usar o Supabase, a resposta honesta tem duas partes: o que o Supabase assina e o que ainda tem de ligar. Este artigo trata delas por essa ordem, a partir dos documentos do próprio Supabase, lidos a 29 de outubro de 2026. ## O Supabase é compatível com o HIPAA? A plataforma alojada é. O [guia de conformidade HIPAA](https://supabase.com/docs/guides/security/hipaa-compliance) do Supabase diz que atua como business associate para os clientes que tratam Protected Health Information (PHI), que assinou BAA com os seus próprios fornecedores que podem aceder a esses dados, como a AWS, e que os seus controlos HIPAA são auditados todos os anos no mesmo período de auditoria que o SOC 2. Os projetos HIPAA recebem ainda todos os controlos SOC 2 que o resto da plataforma tem. O mesmo guia traz dois limites. O Supabase auto-alojado não traz estes controlos de origem, e a conformidade HIPAA aí é um assunto entre si e o seu auditor. E o BAA cobre apenas a parte do Supabase: o guia enumera as suas responsabilidades como cumprir as regras de Privacidade, Segurança e Notificação de Violações do HIPAA, assinar o BAA e configurar os seus projetos HIPAA como o Security Advisor indica. ## O que precisa antes de guardar PHI? Segundo a [página de projetos HIPAA](https://supabase.com/docs/guides/platform/hipaa-projects) e o [modelo de responsabilidade partilhada](https://supabase.com/docs/guides/deployment/shared-responsibility-model): 1. **Um plano Team ou superior.** O BAA não está disponível abaixo disso. 2. **O complemento HIPAA e um BAA assinado.** Pede ambos ao Supabase; o complemento é ativado na organização. 3. **High Compliance em cada projeto.** Com o complemento ativo, um projeto pode ser marcado como High Compliance em General Project Settings. A partir daí o Supabase executa verificações adicionais nesse projeto de forma contínua, e uma definição não conforme aparece como aviso no Security Advisor. O Security Advisor avisa; não corrige. O guia do Supabase é direto quanto a isto: a responsabilidade de aplicar os controlos recomendados cabe ao cliente. ## Que definições precisa um projeto HIPAA? Eis a lista completa do modelo de responsabilidade partilhada, com o sítio onde cada uma vive e se o [verificador de segurança do Supabase](https://madsalt.tech/pt/tools/supabase-security-check/) gratuito a consegue ver. O verificador lê um projeto através da Management API do Supabase depois de iniciar sessão com o Supabase, por isso vê definições, não contratos. | O seu dever sob o BAA | Onde vive | Verificador gratuito | | ------------------------------------------------ | --------------------------------------------------------------- | --------------------------------------------------------- | | Assinar o BAA, plano Team ou superior | Contrato com o Supabase | Não vê | | Marcar projetos como HIPAA, corrigir avisos | General Project Settings, Security Advisor | Em parte: mostra cada lint do Security Advisor que recebe | | MFA em todas as contas Supabase, obrigatório | Definições da organização | Não vê | | Point-in-time recovery (PITR) | Database → Backups, requer um pequeno complemento de computação | Em parte: passa só com cópias diárias | | Imposição de SSL | Database Settings → SSL Configuration | Assinala: "SSL not enforced on database connections" | | Restrições de rede | Database Settings → Network Restrictions | Assinala: "Database open to every IP address" | | Registo de ligações do Postgres ativo | `log_connections`, desligado por omissão em projetos novos | Não vê | | Cifragem segundo a HIPAA Security Rule | O Supabase cifra em repouso e em trânsito | Não vê; a cifragem ao nível da aplicação é escolha sua | | Sem PHI em buckets de Storage públicos | Storage → definições do bucket | Assinala cada bucket público; se contém PHI é consigo | | Sem transferência para uma organização não HIPAA | Transferência de projeto | Não vê | ![Os 10 deveres HIPAA do Supabase: o que vê um verificador gratuito. Deveres do modelo de responsabilidade partilhada do Supabase. Assinalado por uma regra: 3; Visto só em parte: 2; Invisível para o verificador: 5.](https://madsalt.tech/charts/pt/is-supabase-hipaa-compliant.svg) *Figura 1. Modelo de responsabilidade partilhada do Supabase, lido a 29 de outubro de 2026, face às regras do meu verificador gratuito do Supabase.* ## O que escapa à verificação gratuita? Vale a pena detalhar três lacunas, porque um resultado verde pode parecer mais do que é. **Cópias diárias não são PITR.** A regra de cópias do verificador passa quando o projeto tem point-in-time recovery ou pelo menos uma cópia. Um projeto pago com cópias diárias e sem PITR passa. Os projetos HIPAA precisam especificamente de PITR, por isso veja Database → Backups você mesmo; o PITR exige pelo menos o pequeno complemento de computação. O que cada plano guarda, e um teste de restauro, está em Supabase backups. **Duas definições de MFA diferentes.** O "No multi-factor method enabled" do verificador diz respeito aos utilizadores da sua app: se o Supabase Auth lhes oferece um segundo fator. O dever HIPAA diz respeito às pessoas que podem abrir o seu painel do Supabase: MFA em todas as contas da organização, imposto como requisito. Quer ambos, e ligam-se em sítios diferentes. **Registo de ligações.** O Supabase deixa `log_connections` desligado nos projetos novos, e os projetos HIPAA devem mantê-lo ligado para o rasto de auditoria. O verificador não tem nenhuma regra que o leia. No editor SQL, `show log_connections;` responde numa linha, e o Security Advisor avisa disso num projeto High Compliance. O verificador mostra todos os lints que o Security Advisor devolve, erros e avisos por igual. Não o executei num projeto High Compliance, por isso não posso confirmar que os avisos HIPAA chegam nessa mesma lista. Leia-os no painel de qualquer forma. ## O que as definições HIPAA não cobrem Nenhum dos dez deveres menciona Row Level Security. Um projeto HIPAA com todas as definições acima no sítio pode na mesma servir uma tabela de pacientes a quem tenha a chave pública, se essa tabela tiver RLS desligado ou uma política que permita todas as linhas. Essa é a parte que o verificador lê por inteiro: grants, políticas, funções que contornam o RLS e colunas com ar sensível legíveis por visitantes anónimos. A diferença entre as duas chaves está em [Supabase anon key vs service role key](https://madsalt.tech/pt/blog/supabase-anon-key-vs-service-role-key/), e como provo cada permissão contra a API está em [como testar o Supabase RLS](https://madsalt.tech/pt/blog/how-to-test-supabase-rls/). O mesmo vale para tudo o que fica fora do Supabase. O modelo de responsabilidade partilhada põe do seu lado os serviços de terceiros: fornecedores de SMTP e SMS, início de sessão com OAuth e qualquer API externa que uma Edge Function ou um trigger da base de dados chame. Se algum receber PHI, faz parte do seu quadro HIPAA, não do do Supabase, por isso verifique se cada fornecedor assina um BAA antes de os dados lá chegarem. ## Como verificar o seu projeto? 1. No painel, confirme que a organização tem o complemento HIPAA e que o projeto está marcado como High Compliance; depois abra o Security Advisor e trate cada aviso. 2. Abra Database → Backups e confirme que o PITR está ativo, não apenas as cópias diárias. 3. Execute `show log_connections;` no editor SQL. Deve devolver `on`. 4. Nas definições da organização, confirme que todos os membros têm MFA e que o MFA é obrigatório. 5. Execute o [verificador de segurança do Supabase](https://madsalt.tech/pt/tools/supabase-security-check/) gratuito para SSL, restrições de rede, buckets públicos e as regras de acesso acima. A minha nota sobre buckets públicos explica como passar os ficheiros para URLs assinados. Para a pergunta mais ampla sobre o que a plataforma garante e o que não garante, veja [o Supabase é seguro?](https://madsalt.tech/pt/blog/is-supabase-secure/). Este artigo não é aconselhamento jurídico; o seu responsável de conformidade ou o seu auditor decide o que o seu BAA e o seu programa HIPAA exigem. A construir uma app de saúde em Supabase? Gostava de rever as definições do seu projeto e trocar impressões. Sem pitch. [Fale comigo](https://madsalt.tech/pt/#contact)