REVOKE en SQL: revocar privilegios concedidos de forma segura

REVOKE es la imagen reflejada de GRANT: retira privilegios que antes concediste a un usuario o a un rol. En la practica revocar es mas delicado que conceder, porque el mismo acceso puede llegar por varias vias a la vez.

Sintaxis basica

Para retirar un privilegio concreto sobre una tabla, indica el privilegio, el objeto y el beneficiario:

REVOKE INSERT ON orders FROM analyst;

Puedes revocar varios privilegios a la vez y apuntar a columnas concretas:

REVOKE SELECT, UPDATE ON users FROM analyst;
REVOKE UPDATE (salary) ON employees FROM analyst;
REVOKE ALL PRIVILEGES ON orders FROM analyst;

El principio clave: REVOKE solo elimina lo que se concedio directamente a ese beneficiario. Si el acceso llego por otra via, la sentencia se ejecuta sin error, pero el acceso efectivo permanece.

CASCADE frente a RESTRICT

Si un privilegio se concedio WITH GRANT OPTION, quien lo recibio pudo pasarlo a otros. Al revocar, PostgreSQL debe decidir que pasa con esas concesiones derivadas.

• RESTRICT (el comportamiento por defecto) rechaza la revocacion si otras concesiones dependen de esta.
• CASCADE elimina el privilegio y todas las concesiones que descienden de el.

GRANT SELECT ON orders TO manager WITH GRANT OPTION;
-- manager passed it on:
GRANT SELECT ON orders TO analyst;

-- This fails because manager re-granted the right:
REVOKE SELECT ON orders FROM manager RESTRICT;

-- This removes manager's grant AND analyst's:
REVOKE SELECT ON orders FROM manager CASCADE;

Tambien puedes revocar solo la capacidad de volver a conceder, dejando intacto el acceso:

REVOKE GRANT OPTION FOR SELECT ON orders FROM manager CASCADE;

Gotcha: CASCADE puede borrar el acceso de cuentas en las que ni pensaste. Antes de revocar con CASCADE, revisa la cadena de concesiones en information_schema.role_table_grants, o podrias romper el panel o el trabajo de ETL de alguien.

Por que PUBLIC sigue teniendo acceso

La sorpresa mas comun: revocas un privilegio a un usuario y este sigue leyendo la tabla igualmente. La causa es el pseudo-rol PUBLIC, al que pertenece de forma implicita todo rol del cluster. Si el privilegio se concedio a PUBLIC, revocarlo a un solo usuario no cambia nada.

-- Someone granted broad access earlier:
GRANT SELECT ON users TO PUBLIC;

-- This looks right but analyst still reads users:
REVOKE SELECT ON users FROM analyst;

-- You must revoke from PUBLIC itself:
REVOKE SELECT ON users FROM PUBLIC;

Ten en cuenta tambien los privilegios del propietario: el dueno de la tabla y los superusuarios conservan el acceso completo pese a REVOKE. No puedes quitarles el acceso con una revocacion normal.

Rol frente a usuario

Repartir el acceso mediante roles de grupo es comodo, pero complica la revocacion. Si el usuario analyst es miembro del rol analytics_team, revocar un privilegio a analyst en persona no afecta a lo que hereda a traves del rol.

GRANT SELECT ON orders TO analytics_team;
GRANT analytics_team TO analyst;

-- No effect: analyst gets SELECT via the role, not directly:
REVOKE SELECT ON orders FROM analyst;

-- Option A: revoke from the role (affects everyone in it):
REVOKE SELECT ON orders FROM analytics_team;

-- Option B: remove this user from the role:
REVOKE analytics_team FROM analyst;

MySQL sigue un modelo parecido, pero no admite REVOKE ... CASCADE/RESTRICT, y los roles solo llegaron en la version 8.0; antes los privilegios se asignaban directamente a las cuentas. ClickHouse admite REVOKE y roles, pero sus privilegios y su sintaxis difieren bastante del SQL estandar.

Como endurecer permisos con seguridad

• Comprueba primero el acceso efectivo: lee information_schema.role_table_grants y recorre las pertenencias a roles antes de revocar nada.
• No olvides PUBLIC: para tablas sensibles, ejecuta de forma explicita REVOKE ... FROM PUBLIC.
• Prefiere RESTRICT (o simplemente omite CASCADE) para que la sentencia falle de forma evidente cuando existan concesiones dependientes y veas el problema con antelacion.
• Revoca al mismo nivel en que concediste: revoca un rol de un rol y una concesion directa de un usuario.
• Envuelve la serie de REVOKE en una transaccion y verifica con un SELECT como el usuario afectado antes de confirmar.