<?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/it/tags/audit/</link><description>Recent content in Audit on Ivan Luminaria</description><generator>Hugo</generator><language>it</language><lastBuildDate>Tue, 27 Jan 2026 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/it/tags/audit/index.xml" rel="self" type="application/rss+xml"/><item><title>Utenti, ruoli e privilegi in Oracle: perché GRANT ALL non è mai la risposta</title><link>https://ivanluminaria.com/it/posts/oracle/oracle-roles-privileges/</link><pubDate>Tue, 27 Jan 2026 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/it/posts/oracle/oracle-roles-privileges/</guid><description>&lt;p&gt;Mi è capitato più volte di entrare in un ambiente Oracle e trovare la stessa situazione: tutti gli utenti applicativi connessi come schema owner, con il ruolo DBA assegnato. Sviluppatori, applicazioni batch, tool di reportistica — tutti con gli stessi privilegi dell&amp;rsquo;utente che possiede le tabelle.&lt;/p&gt;
&lt;p&gt;Quando chiedi perché, la risposta è sempre una variante di: &amp;ldquo;Così funziona tutto senza problemi di permessi.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Certo. Funziona tutto. Fino al giorno in cui uno sviluppatore lancia un &lt;code&gt;DROP TABLE&lt;/code&gt; sulla tabella sbagliata. O un batch di import fa un &lt;code&gt;TRUNCATE&lt;/code&gt; su una tabella di produzione pensando di essere in ambiente di test. O qualcuno esegue un &lt;code&gt;DELETE FROM clienti&lt;/code&gt; senza la clausola &lt;code&gt;WHERE&lt;/code&gt;.&lt;/p&gt;</description></item></channel></rss>