<?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/ro/tags/audit/</link><description>Recent content in Audit on Ivan Luminaria</description><generator>Hugo</generator><language>ro</language><lastBuildDate>Tue, 27 Jan 2026 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/ro/tags/audit/index.xml" rel="self" type="application/rss+xml"/><item><title>Utilizatori, roluri și privilegii în Oracle: de ce GRANT ALL nu este niciodată răspunsul</title><link>https://ivanluminaria.com/ro/posts/oracle/oracle-roles-privileges/</link><pubDate>Tue, 27 Jan 2026 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/ro/posts/oracle/oracle-roles-privileges/</guid><description>&lt;p&gt;Mi s-a întâmplat de mai multe ori: intru într-un mediu Oracle și găsesc aceeași situație. Toți utilizatorii aplicativi conectați ca schema owner, cu rolul DBA atribuit. Dezvoltatori, procese batch, instrumente de raportare — toți cu aceleași privilegii ca utilizatorul proprietar al tabelelor.&lt;/p&gt;
&lt;p&gt;Când întrebi de ce, răspunsul este mereu o variantă a: „Așa funcționează totul fără probleme de permisiuni.&amp;quot;&lt;/p&gt;
&lt;p&gt;Sigur. Totul funcționează. Până în ziua în care un dezvoltator execută un &lt;code&gt;DROP TABLE&lt;/code&gt; pe tabela greșită. Sau un batch de import face un &lt;code&gt;TRUNCATE&lt;/code&gt; pe o tabelă de producție crezând că este în mediul de test. Sau cineva execută un &lt;code&gt;DELETE FROM clienti&lt;/code&gt; fără clauza &lt;code&gt;WHERE&lt;/code&gt;.&lt;/p&gt;</description></item></channel></rss>