<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Audit on Ivan Luminaria</title><link>https://ivanluminaria.com/es/tags/audit/</link><description>Recent content in Audit on Ivan Luminaria</description><generator>Hugo</generator><language>es</language><lastBuildDate>Tue, 27 Jan 2026 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/es/tags/audit/index.xml" rel="self" type="application/rss+xml"/><item><title>Usuarios, roles y privilegios en Oracle: por qué GRANT ALL nunca es la respuesta</title><link>https://ivanluminaria.com/es/posts/oracle/oracle-roles-privileges/</link><pubDate>Tue, 27 Jan 2026 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/es/posts/oracle/oracle-roles-privileges/</guid><description>&lt;p&gt;Me ha pasado más de una vez: entro en un entorno Oracle y encuentro la misma situación. Todos los usuarios aplicativos conectados como schema owner, con el rol DBA asignado. Desarrolladores, procesos batch, herramientas de reporting — todos con los mismos privilegios que el usuario propietario de las tablas.&lt;/p&gt;
&lt;p&gt;Cuando preguntas por qué, la respuesta siempre es alguna variante de: &amp;ldquo;Así todo funciona sin problemas de permisos.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Claro. Todo funciona. Hasta el día en que un desarrollador ejecuta un &lt;code&gt;DROP TABLE&lt;/code&gt; sobre la tabla equivocada. O un batch de importación hace un &lt;code&gt;TRUNCATE&lt;/code&gt; sobre una tabla de producción pensando que está en el entorno de pruebas. O alguien ejecuta un &lt;code&gt;DELETE FROM clientes&lt;/code&gt; sin la cláusula &lt;code&gt;WHERE&lt;/code&gt;.&lt;/p&gt;</description></item></channel></rss>