Como parte de la serie «Security Masterclass» de Aikido, Mackenzie Jackson se reunió con Bill Harmer (CISO, Supabase) y Etienne Stalmans (ingeniero de seguridad, Supabase) para explorar cómo Supabase aborda la seguridad como parte del diseño, y no como algo que se añade posteriormente.
Desde la seguridad a nivel de fila (RLS) hasta los riesgos de la codificación asistida por IA, el debate se centró en lo que se necesita para construir rápidamente y mantener la seguridad.
La seguridad comienza con los datos.
La filosofía de Supabase comienza con los datos mismos.
«Hemos creado Supabase desde el punto de vista de los desarrolladores. Todo comienza con los datos. ¿Por qué crear capas secundarias cuando se puede controlar todo desde un solo lugar?». - Bill Harmer, director de seguridad de la información de Supabase.
En lugar de distribuir la lógica de seguridad entre los distintos servicios, Supabase la acerca al lugar donde se encuentran los datos. Cuanto más cercano es el control, menos posibilidades hay de que algo salga mal.
Construir con principios básicos
Para Etienne, este enfoque cambia la forma en que los desarrolladores piensan sobre la creación de software.
«Cuando acercas la seguridad a tus datos, empiezas a pensar en ella desde los principios básicos. Una vez que lo entiendes, aceleras el desarrollo y mantienes la confianza en que es seguro». - Etienne Stalmans, ingeniero de seguridad de Supabase.
Al integrar la propiedad y el acceso a los datos en el diseño de las aplicaciones, los equipos eliminan las conjeturas que conllevan los sistemas de permisos por capas.
Anónimo o autenticado
Supabase simplifica el control de acceso. Los usuarios son anónimos o autenticados, sin términos medios.
«Todas las actualizaciones de los datos deben registrarse, quién hizo qué, cuándo y por qué. Los usuarios anónimos tienen acceso limitado. Los usuarios autenticados obtienen exactamente lo que necesitan y nada más». - Bill Harmer, CISO de Supabase
Etienne lo demostró durante la sesión utilizando una aplicación para compartir recetas en directo.
Las recetas públicas eran visibles para todos. Las recetas privadas solo eran visibles para sus propietarios o para usuarios específicos con los que se compartían.
Unas pocas líneas de SQL, respaldadas por Row Level Security, gestionaron todo el modelo.
La seguridad a nivel de fila no es negociable.
RLS define quién puede ver o modificar qué filas de datos. Es una de las funciones más potentes de Postgres y una de las más fáciles de pasar por alto.
«Es todo lo que hace falta, un cheque perdido y todo queda al descubierto». - Etienne Stalmans, ingeniero de seguridad de Supabase.
Etienne compartió un ejemplo en el que una política generada por IA devolvió accidentalmente todos los registros de una tabla porque omitió una condición.
La solución consistió en una única corrección de la consulta, una línea que cerró una importante brecha de seguridad.
Bill lo resumió de forma sencilla:
«Queremos que la seguridad esté lo más cerca posible de los datos. Cuanto más cerca esté, menos margen habrá para el error». - Bill Harmer, director de seguridad de la información de Supabase.
Prueba tus políticas con pgTAP
La seguridad no termina una vez que se lanza la aplicación. Etienne mostró cómo Supabase utiliza pgTAP para probar continuamente las políticas de la base de datos.
«Puedes demostrar que lo que crees que es seguro realmente lo es. Estas pruebas te permiten mantener la honestidad». - Etienne Stalmans, ingeniero de seguridad de Supabase.
Cada prueba comprueba lo que más importa:
- Los usuarios públicos solo ven datos públicos.
- Los usuarios autenticados solo ven lo que les pertenece.
- Las políticas aplican los límites esperados en todo momento.
Esta garantía continua asegura que los pequeños errores no se conviertan en fugas de datos.
Seguridad que se adapta
Supabase ejecuta RLS en millones de usuarios y grandes cargas de trabajo sin problemas.
«Lo utilizamos en todas partes, incluso a gran escala. Sin problemas, sin excusas». - Etienne Stalmans, ingeniero de seguridad de Supabase.
Al reforzar la seguridad a nivel de la base de datos, Supabase mantiene la coherencia lógica independientemente de la complejidad de la aplicación.
«Solo haz que funcione», la peligrosa indicación.
Bill cerró la sesión con una advertencia para cualquiera que utilice la IA para generar código.
«El hecho de que funcione no significa que esté listo para la producción». - Bill Harmer, director de seguridad de la información de Supabase.
«Si le pides a una IA que haga que algo funcione, podría eliminar los controles de seguridad que te protegen». - Bill Harmer, CISO de Supabase
Los modelos de IA no comprenden la intención. Harán lo que sea necesario para alcanzar el objetivo que usted establezca, incluso si eso significa desactivar RLS o eliminar la lógica de autenticación.
El peligro no está en utilizar la IA, sino en utilizarla sin orientación.
«El modelo no es malicioso. Está haciendo su trabajo. Pero no conoce tu intención. Eso es tarea tuya». - Bill Harmer, CISO Supabase
Construir de forma segura por defecto
La seguridad no es un obstáculo. Es la forma de avanzar más rápido sin dudar de lo que se envía.
Supabase demuestra que cuando la seguridad reside en la capa de datos, se convierte en parte del proceso de creación, y no en algo secundario.
Protege tu software ahora.
.avif)
