Como parte da série Masterclass de Segurança Aikido, Mackenzie Jackson conversou com Bill Harmer (CISO, Supabase) e Etienne Stalmans (Engenheiro de Segurança, Supabase) para explorar como a Supabase aborda a segurança como parte do design, e não como algo a ser adicionado posteriormente.
Da segurança ao nível da linha (RLS) aos riscos da codificação assistida por IA, a discussão centrou-se no que é necessário para construir rapidamente e manter a segurança.
A segurança começa com os dados
A filosofia da Supabase começa com os próprios dados.
«Criámos o Supabase a partir da perspetiva de um programador. Tudo começa com os dados. Porquê criar camadas secundárias quando se pode controlar tudo num único local?» - Bill Harmer, CISO Supabase
Em vez de espalhar a lógica de segurança pelos serviços, o Supabase aproxima-a do local onde os dados residem. Quanto mais próximo for o controlo, menores serão as hipóteses de algo correr mal.
Construindo com princípios básicos
Para Etienne, essa abordagem muda a forma como os programadores pensam sobre a criação de software.
“Quando aproxima a segurança dos seus dados, começa a pensar nela a partir dos princípios básicos. Assim que percebe isso, acelera o desenvolvimento e mantém a confiança de que está seguro.” - Etienne Stalmans, Engenheiro de Segurança da Supabase
Ao tornar a propriedade e o acesso aos dados parte do design da aplicação, as equipas eliminam as suposições que acompanham os sistemas de permissões em camadas.
Anónimo ou autenticado
O Supabase mantém o controlo de acesso simples. Os utilizadores são anónimos ou autenticados, sem meio-termo.
«Todas as atualizações dos dados devem ser registadas, quem fez o quê, quando e porquê. Os utilizadores anónimos têm acesso limitado. Os utilizadores 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 partilha de receitas ao vivo.
As receitas públicas eram visíveis para todos. As receitas privadas eram visíveis apenas para os seus proprietários ou utilizadores específicos com quem eram partilhadas.
Algumas linhas de SQL, apoiadas pela segurança ao nível da linha, trataram de todo o modelo.
A segurança ao nível da linha não é negociável
O RLS define quem pode ver ou alterar quais linhas de dados. É um dos recursos mais poderosos do Postgres e um dos mais fáceis de ignorar.
«É só isso que basta, um cheque em falta e tudo fica exposto.» - Etienne Stalmans, Engenheiro de Segurança da Supabase
Etienne partilhou um exemplo em que uma política gerada por IA acidentalmente retornou todos os registos de uma tabela porque ignorou uma condição.
A correção consistiu numa única alteração à consulta, uma linha que eliminou uma importante falha de segurança.
Bill resumiu de forma simples:
«Queremos segurança o mais próximo possível dos dados. Quanto mais próximo estiver, menos margem para erros haverá.» - Bill Harmer, CISO Supabase
Testando suas políticas com o pgTAP
A segurança não termina quando a aplicação é lançada. Etienne mostrou como a Supabase usa o pgTAP para testar continuamente as políticas do banco de dados.
«Pode provar que aquilo em que acredita ser seguro realmente o é. Estes testes mantêm-no honesto.» - Etienne Stalmans, Engenheiro de Segurança Supabase
Cada teste verifica o que é mais importante:
- Os utilizadores públicos só veem dados públicos
- Os utilizadores autenticados só veem o que é deles
- As políticas aplicam os limites esperados sempre
Essa garantia contínua assegura que pequenos erros não se transformem em fugas de dados.
Segurança que se adapta
A Supabase executa RLS em milhões de utilizadores e grandes cargas de trabalho sem problemas.
«Nós o utilizamos em todos os lugares, mesmo em grande escala. Sem problemas, sem desculpas.» - Etienne Stalmans, Engenheiro de Segurança Supabase
Ao reforçar a segurança ao nível da base de dados, o Supabase mantém a lógica consistente, independentemente da complexidade da aplicação.
“Faça funcionar” – a perigosa sugestão
Bill encerrou a sessão com uma advertência para qualquer pessoa que utilize IA para gerar código.
«Só porque funciona, não significa que esteja pronto para produção.» - Bill Harmer, CISO Supabase
«Se pedir a uma IA para fazer algo funcionar, ela pode remover as verificações de segurança que o protegem.» - Bill Harmer, CISO Supabase
Os modelos de IA não compreendem a intenção. Eles farão o que for necessário para atingir o objetivo que você definiu, mesmo que isso signifique desativar 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á a fazer o seu trabalho. Mas não conhece a sua intenção. Essa é a sua função.» - Bill Harmer, CISO Supabase
Construir com segurança por padrão
A segurança não é um obstáculo. É a forma de avançar mais rapidamente sem questionar o que se entrega.
A Supabase prova que, quando a segurança está presente na camada de dados, ela passa a fazer parte da forma como você constrói, e não é algo secundário.
Proteja seu software agora
.avif)
