<?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/en/tags/audit/</link><description>Recent content in Audit on Ivan Luminaria</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 27 Jan 2026 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/en/tags/audit/index.xml" rel="self" type="application/rss+xml"/><item><title>Users, Roles and Privileges in Oracle: Why GRANT ALL Is Never the Answer</title><link>https://ivanluminaria.com/en/posts/oracle/oracle-roles-privileges/</link><pubDate>Tue, 27 Jan 2026 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/en/posts/oracle/oracle-roles-privileges/</guid><description>&lt;p&gt;It has happened to me more than once: I walk into an Oracle environment and find the same situation. Every application user connected as the schema owner, with the DBA role granted. Developers, batch jobs, reporting tools — all running with the same privileges as the user that owns the tables.&lt;/p&gt;
&lt;p&gt;When you ask why, the answer is always some variation of: &amp;ldquo;This way everything works without permission issues.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Sure. Everything works. Until the day a developer runs a &lt;code&gt;DROP TABLE&lt;/code&gt; on the wrong table. Or a batch import does a &lt;code&gt;TRUNCATE&lt;/code&gt; on a production table thinking it is in the test environment. Or someone runs a &lt;code&gt;DELETE FROM customers&lt;/code&gt; without a &lt;code&gt;WHERE&lt;/code&gt; clause.&lt;/p&gt;</description></item></channel></rss>