Como parte da série Security Masterclass da Aikido, Mackenzie Jackson conversou com Bill Harmer (CISO, Supabase) e Etienne Stalmans (Security Engineer, Supabase) para explorar como a Supabase aborda a segurança como parte do design, e não como algo a ser adicionado posteriormente.
Desde a Segurança em Nível de Linha (RLS) até os riscos da codificação assistida por IA, a discussão focou no que é preciso para construir rapidamente e permanecer seguro.
A segurança começa com os dados
A filosofia da Supabase começa com os próprios dados.
“Construímos o Supabase do ponto de vista de um desenvolvedor. Tudo começa com os dados. Por que construir camadas secundárias quando você pode controlar tudo em um só lugar.” - Bill Harmer, CISO Supabase
Em vez de espalhar a lógica de segurança por vários serviços, a Supabase a aproxima de onde os dados residem. Quanto mais próximo o controle, menores as chances de algo dar errado.
Construindo com primeiros princípios
Para Etienne, essa abordagem muda a forma como os desenvolvedores pensam sobre a construção de software.
“Quando você move a segurança para mais perto dos seus dados, você começa a pensar nela a partir dos primeiros princípios. Uma vez que isso se encaixa, você acelera o desenvolvimento e mantém a confiança de que está seguro.” - Etienne Stalmans, Security Engineer Supabase
Ao tornar a propriedade e o acesso aos dados parte do design da aplicação, as equipes eliminam as suposições que vêm com sistemas de permissão em camadas.
Anônimo ou autenticado
A Supabase mantém o controle de acesso simples. Os usuários são anônimos ou autenticados, nada intermediário.
“Todas as atualizações de dados devem ser registradas: quem fez o quê, quando e por quê. Usuários anônimos obtêm acesso limitado. Usuários autenticados obtêm exatamente o que precisam e nada mais.” - Bill Harmer, CISO Supabase
Etienne demonstrou isso durante a sessão usando um aplicativo de compartilhamento de receitas ao vivo.
Receitas públicas eram visíveis para todos. Receitas privadas eram visíveis apenas para seus proprietários ou usuários específicos compartilhados.
Algumas linhas de SQL, apoiadas por Segurança em Nível de Linha, lidaram com todo o modelo.
Segurança em Nível de Linha é inegociável
RLS define quem pode ver ou alterar quais linhas de dados. É uma das funcionalidades mais poderosas do Postgres e uma das mais fáceis de ignorar.
“Basta isso, uma verificação ausente e tudo está exposto.” - Etienne Stalmans, Engenheiro de Segurança da Supabase
Etienne compartilhou um exemplo em que uma política gerada por IA acidentalmente retornou todos os registros de uma tabela porque pulou uma condição.
A correção foi uma única alteração na query, uma linha que fechou uma grande falha de segurança.
Bill resumiu de forma simples:
“Queremos a segurança o mais próximo possível dos dados. Quanto mais próxima, menor a margem para erros.” - Bill Harmer, CISO da Supabase
Testando suas políticas com pgTAP
A segurança não para quando o aplicativo é lançado. Etienne mostrou como a Supabase usa pgTAP para testar continuamente as políticas do banco de dados.
“Você pode provar que o que você acredita ser seguro realmente é. Esses testes mantêm você honesto.” - Etienne Stalmans, Engenheiro de Segurança da Supabase
Cada teste verifica o que mais importa:
- Usuários públicos veem apenas dados públicos
- Usuários autenticados veem apenas o que lhes pertence
- As políticas impõem os limites esperados sempre
Essa garantia contínua assegura que pequenos erros não se transformem em vazamentos de dados.
Segurança escalável
A Supabase executa RLS para milhões de usuários e grandes cargas de trabalho sem problemas.
“Nós o executamos em todos os lugares, mesmo em escala. Sem problemas, sem desculpas.” - Etienne Stalmans, Engenheiro de Segurança da Supabase
Ao aplicar a segurança no nível do banco de dados, a Supabase mantém a lógica consistente, não importa o quão complexo o aplicativo se torne.
“Apenas faça funcionar”, o prompt perigoso
Bill encerrou a sessão com um aviso para qualquer pessoa que use IA para gerar código.
“Só porque funciona não significa que está pronto para produção.” - Bill Harmer, CISO da Supabase
“Se você pedir a uma IA para fazer algo funcionar, ela pode remover as próprias verificações de segurança que o protegem.” - Bill Harmer, CISO da Supabase
Modelos de IA não entendem intenção. Eles farão o que for preciso para atingir o objetivo que você definiu, mesmo que isso signifique desabilitar o RLS ou excluir a lógica de autenticação.
O perigo não é usar IA, é usá-la sem orientação.
“O modelo não é malicioso. Ele está fazendo o seu trabalho. Mas ele não conhece a sua intenção. Esse é o seu trabalho.” - Bill Harmer, CISO da Supabase
Construindo com segurança por padrão
Segurança não é um impedimento. É como você avança mais rápido sem duvidar do que entrega.
Supabase prova que, quando a segurança reside na camada de dados, ela se torna parte da forma como você constrói, e não uma reflexão tardia.
