← Volver a la Base de conocimientos← Pregunta anteriorSiguiente pregunta →
ProgramaciónArquitecto de SQL

¿Cuáles son las formas de proteger los datos contra modificaciones no intencionadas o maliciosas a través de permisos y roles en SQL? ¿En qué se diferencian los niveles de acceso y cómo implementar correctamente una política de seguridad en múltiples niveles?

Supere entrevistas con el asistente de IA Hintsage

Respuesta.

El servidor SQL soporta un sistema de permisos en múltiples niveles a través de roles, permisos de usuario (GRANT/REVOKE) y esquemas (schemas). Principios clave:

  • Asigne un rol= conjunto de permisos que luego obtendrá el usuario.
  • Otorgue permisos mínimos, solo los necesarios (principio de mínimo privilegio).
  • Separe los permisos a nivel de base de datos, tabla, vista y procedimientos por separado.
  • Para operaciones especialmente importantes, utilice solo procedimientos almacenados o vistas, y no acceso directo a las tablas.

Ejemplo de creación de roles y asignación de permisos:

-- Creamos un rol para analistas
CREATE ROLE Analyst;
-- Solo otorgamos SELECT a las tablas necesarias
GRANT SELECT ON Sales TO Analyst;
-- Prohibimos la modificación de datos
REVOKE INSERT, UPDATE, DELETE ON Sales FROM Analyst;
-- Asignamos el rol al usuario
GRANT Analyst TO user_ivan;

A menudo se destacan roles para lectura (read-only), modificación, administración y operaciones específicas.

Pregunta con trampa.

Trampa: "¿Puede un usuario que tiene acceso solo a una vista (VIEW) modificar la tabla base a través de ella? Dé un ejemplo."

Respuesta: Sí, si la VIEW no contiene agregación/grupamiento y no es solo de lectura (WITH CHECK OPTION), se pueden realizar INSERT/UPDATE/DELETE en la VIEW, y los cambios se reflejarán en la tabla base, si los permisos lo permiten.

-- Vista que filtra columnas innecesarias
CREATE VIEW SalesAsView AS SELECT id, total, manager_id FROM Sales;
-- Si está permitido, el usuario realizará cambios así:
UPDATE SalesAsView SET total=1000 WHERE id=42;
-- Esto afectará a Sales.total para id=42

Solución: utilizar solo vistas de solo lectura o prohibir permisos para modificar datos a través de vistas.

Ejemplos de errores reales debido al desconocimiento de los matices del tema.

Historia

Proyecto: Portal de Recursos Humanos, datos personales de empleados.

Error: Los operadores tenían acceso a la tabla base a través de VIEW sin restricciones sobre UPDATE, modificaron accidentalmente los salarios entre sí, aunque la VIEW estaba inicialmente pensada "solo para informes".

Historia

Proyecto: Contabilidad, integraciones externas.

Error: Se otorgaron permisos de INSERT y SELECT a un sistema externo en toda la DB en lugar de solo INSERT en las tablas necesarias. Resultado: vulnerabilidad a la lectura de toda la base de datos y posible incumplimiento de la legislación GDPR.

Historia

Proyecto: Plataforma SaaS, informes multiusuario.

Error: Todos los clientes trabajaban en un mismo esquema con permisos compartidos: accidentalmente veían y podían editar datos ajenos. Solución: descomposición en esquemas, roles separados y restricciones propias a nivel de Row Level Security (RLS).