Supabase cobre a infraestrutura HIPAA, mas RLS e auditoria continuam sob responsabilidade do seu time

Quem armazena PHI (informação de saúde protegida) em um projeto Supabase já sabe que precisa assinar o BAA (Business Associate Agreement) e ativar o modo High Compliance. O que menos gente repete é que isso cobre só a metade do problema. É esse o argumento de um post publicado em 29 de outubro de 2026 por Munaf Khatri no blog do UnitAutogen, ferramenta de testes de segurança para PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →: o BAA e o modo de alta conformidade protegem a plataforma, não as políticas de RLS, as funções ou as tabelas de auditoria que vivem dentro do schema do projeto.

Para quem administra banco de dados, essa distinção não é novidade de princípio, mas costuma sumir na prática quando a infraestrutura é terceirizada. A Supabase tem um modelo de responsabilidade compartilhada que diz isso com todas as letras, pedindo que o cliente "sempre aplique Row Level Security (RLS)" nas tabelas sensíveis. A frase é curta, mas carrega a parte mais trabalhosa da conformidade: ninguém fora da sua equipe vai escrever essas políticas por você.

O que o BAA da Supabase realmente cobre

No plano hospedado, a Supabase assina o BAA, cuida de criptografia em repouso e em trânsito e verifica um conjunto de configurações do projeto. O guia HIPAA da plataforma pede que o time ative Point in Time Recovery, force SSL, restrinja a rede e ligue o log de conexões do Postgres, além de exigir MFA em toda conta com acesso ao projeto. O Security Advisor da própria Supabase avisa quando algum desses itens está desligado.

O advisor e o linter de banco também sinalizam padrões arriscados, como uma tabela em public com RLS desativado. Isso é útil, mas é checagem de configuração, não de comportamento. Nenhum dos dois executa as políticas de fato, então nenhum consegue dizer se uma enfermeira de uma clínica consegue ler visitas de outra, ou se um registro apagado deixou rastro na tabela de auditoria.

As três perguntas que uma auditoria HIPAA faz ao banco

O post mapeia a parte que sobra para o time em três perguntas, cada uma amarrada a uma cláusula da Security Rule americana:

• Quem alcança quais linhas de paciente? Controle de acesso, sob 164.312(a)(1), que exige que o acesso vá "apenas a pessoas ou programas de software aos quais foram concedidos direitos de acesso".
• Toda mudança naquele dado fica registrada? Controles de auditoria, sob 164.312(b).
• Alguém consegue alterar o registro depois? Integridade, sob 164.312(c)(1), que trata de proteger o PHI contra alteração ou destruição indevida.

A Security Rule mapeia ainda outras duas exigências que completam esse quadro, sem fazer parte das três perguntas formuladas pela auditoria: autenticação, sob 164.312(d), e reavaliação periódica (inclusive sempre que o ambiente muda), sob 164.308(a)(8).

No Supabase, quase tudo isso vive em SQL escrito pelo próprio time: políticas de RLS, funções SECURITY DEFINER, triggers de auditoria. Um print das políticas configuradas não mostra o que o banco faz de fato quando uma chamada autenticada aciona uma dessas funções. É exatamente essa lacuna, entre política declarada e comportamento executado, que motiva a segunda metade do post.

Como o UnitAutogen tenta automatizar a coleta de evidências

A ferramenta do próprio Khatri, UnitAutogen for PostgreSQL, ganhou um comando dedicado a isso. Rodado dentro da pasta do projeto com o stack local no ar:

supabase start
unitautogen --supabase hipaa --schema public

O comando se conecta ao banco local reportado por supabase status, construído a partir das migrations, sem dado real de paciente envolvido em nenhum momento. Ele gera os testes, cria as linhas necessárias, roda e desfaz tudo com rollback. O relatório vai para supabase/tests/seccover/hipaa/public/, e os testes de segurança gerados ficam em supabase/tests/seccover/security/, onde supabase test db já consegue pegá-los.

As tabelas de PHI são inferidas a partir do schema, e quando a inferência erra, a correção entra num unitautogen.toml na raiz do projeto:

[phi]
tables = ["public.patients", "public.visits"]
not = ["public.countries"]

[audit]
tables = ["audit.change_log"]

Segundo o post, toda entrada vinda desse arquivo é marcada no relatório como declaração do time, não como achado automático, o que evita que uma correção manual seja lida como evidência técnica.

O que o relatório efetivamente testa

• Acesso: funções, views e triggers que rodam com o privilégio do dono (SECURITY DEFINER) ignoram políticas de linha. Cada uma é chamada como dois locatários diferentes, com dado presente dos dois lados, e o resultado sai marcado como vazando ou contendo o vazamento, junto da tabela, do comando e do papel envolvidos.
• Log de auditoria: para cada tabela de PHI e cada operação (insert, update, delete), o relatório diz se a mudança deixou um registro de auditoria, classificando o resultado como gravado, condicional, cancelado pelo trigger ou não testado. Isso importa porque o log de conexão que a Supabase pede para manter ativo registra só quem se conectou, não quais linhas mudaram.
• Adulteração: para cada tabela de auditoria e cada papel de cliente, checa se dá para editar, apagar ou forjar registros nela. Um jeito comum disso falhar, segundo o post, é uma função SECURITY DEFINER exposta via .rpc() que grava na tabela de auditoria e acaba podendo ser chamada por qualquer usuário autenticado, escrevendo o que quiser.
• Identidade: como as políticas dependem de auth.uid() e auth.jwt(), o relatório verifica se uma sessão de cliente consegue manipular o que essas funções retornam.

O resultado sai em um relatório HTML↳HTML45 conteúdosA importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Como hostear seu site HTML gratuitamente com GitHub PagesDev (Back & Front) · jun 2025SQL Server – Como criar um versionamento de código das suas Stored Procedures em HTML e com comentários da alteraçãoData · nov 2020Ver tudo em Dev (Back & Front) → com cópia em JSON, cada salvaguarda marcada como evidência ou parcial, as lacunas ranqueadas junto da mudança que resolveria cada uma. O arquivo carrega carimbo com banco, horário, papel, versão da ferramenta e um hash SHA-256 de cada arquivo usado na análise; editar o relatório depois quebra a correspondência dos hashes.

Integrar ao pipeline, não rodar na véspera da auditoria

A maioria das mudanças de schema no Supabase chega como migration em pull request, e a própria Supabase já documenta uma GitHub Action que roda supabase test db. O post sugere adicionar o comando hipaa ao mesmo job e guardar o relatório datado como artefato de build. Na prática, isso transforma a avaliação periódica exigida por 164.308(a)(8) em algo automático a cada mudança de schema, em vez de um exercício manual feito às pressas antes de uma auditoria.

O que o relatório não resolve

Aqui vale o ceticismo de praxe com qualquer ferramenta que promete cobrir compliance: o próprio post é claro que o relatório é evidência para um auditor, não certificação. Ele não analisa criptografia nem transmissão, que já ficam com a Supabase, e não revisa logs. Mais importante: ele não julga se uma política é a política certa. Se uma regra de RLS está mal desenhada por decisão de negócio, o relatório vai dizer que o banco a aplica corretamente, porque de fato aplica, a ferramenta testa execução, não intenção.

A análise de risco, as políticas escritas e o próprio BAA continuam sendo responsabilidade da organização, não de nenhuma ferramenta de teste. unitautogen hipaa faz parte da edição Enterprise do UnitAutogen for PostgreSQL, com faixa de preço diferenciada para times em estágio inicial e um teste gratuito disponível para rodar num schema real antes de decidir.

Para quem administra Postgres por trás de um projeto Supabase com dado de saúde, o recado prático do post é menos sobre a ferramenta específica e mais sobre onde fica a linha: nenhum provedor gerenciado assina RLS, trigger de auditoria ou função SECURITY DEFINER por você. Automatizar a checagem desses pontos a cada migration reduz o risco de descobrir um buraco na política de acesso só quando o auditor pergunta.

Fonte: Planet PostgreSQL