<?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 My personal blog</title>
        <link>https://www.matteobianchi.eu/tags/audit/</link>
        <description>Recent content in Audit on My personal blog</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>en</language>
        <lastBuildDate>Tue, 01 Sep 2026 09:00:00 +0200</lastBuildDate><atom:link href="https://www.matteobianchi.eu/tags/audit/index.xml" rel="self" type="application/rss+xml" /><item>
        <title>Logging e audit trail</title>
        <link>https://www.matteobianchi.eu/p/logging-e-audit-trail/</link>
        <pubDate>Tue, 01 Sep 2026 09:00:00 +0200</pubDate>
        
        <guid>https://www.matteobianchi.eu/p/logging-e-audit-trail/</guid>
        <description>&lt;img src="https://www.matteobianchi.eu/p/logging-e-audit-trail/cover.png" alt="Featured image of post Logging e audit trail" /&gt;&lt;h2 id=&#34;perché-conta&#34;&gt;Perché conta
&lt;/h2&gt;&lt;p&gt;La visibilità è la precondizione di tutto il resto: non puoi rilevare un attacco che non vedi, non puoi
indagare un incidente senza tracce, non puoi dimostrare la compliance senza registri. Il cloud ha un
vantaggio enorme qui: &lt;strong&gt;ogni azione passa per un&amp;rsquo;API&lt;/strong&gt;, e ogni chiamata API può essere registrata. L&#39;
&lt;strong&gt;audit trail&lt;/strong&gt; (CloudTrail su AWS, Activity Log su Azure, Audit Logs su GCP) risponde alla domanda
fondamentale di ogni indagine: &lt;em&gt;chi ha fatto cosa, quando, da dove, con successo o no&lt;/em&gt;.&lt;/p&gt;
&lt;h2 id=&#34;cosa-registra-laudit-trail&#34;&gt;Cosa registra l&amp;rsquo;audit trail
&lt;/h2&gt;&lt;pre class=&#34;mermaid&#34;&gt;
  flowchart LR
    U[&amp;#34;Qualcuno&amp;lt;br/&amp;gt;(utente, ruolo, servizio)&amp;#34;] --&amp;gt;|&amp;#34;chiamata API&amp;#34;| API[Piano di controllo del cloud]
    API --&amp;gt;|azione eseguita| R[Risorsa]
    API --&amp;gt;|&amp;#34;registra: chi, cosa,&amp;lt;br/&amp;gt;quando, da dove, esito&amp;#34;| LOG[(Audit trail)]
    style LOG fill:#fde2e4,stroke:#e63946
&lt;/pre&gt;

&lt;p&gt;Ogni voce dell&amp;rsquo;audit trail dice: l&amp;rsquo;&lt;strong&gt;identità&lt;/strong&gt; che ha agito, l&amp;rsquo;&lt;strong&gt;azione&lt;/strong&gt; (quale API), la &lt;strong&gt;risorsa&lt;/strong&gt;
toccata, l&amp;rsquo;&lt;strong&gt;istante&lt;/strong&gt;, l&amp;rsquo;&lt;strong&gt;IP di origine&lt;/strong&gt; e l&amp;rsquo;&lt;strong&gt;esito&lt;/strong&gt;. Da qui si ricostruisce una timeline: chi ha
creato quel ruolo admin, chi ha reso pubblico quel bucket, da quale IP è partita quella sequenza
sospetta. Senza questo, un incidente è un buco nero.&lt;/p&gt;
&lt;h2 id=&#34;le-tre-regole-dellaudit-trail&#34;&gt;Le tre regole dell&amp;rsquo;audit trail
&lt;/h2&gt;&lt;div class=&#34;highlight&#34;&gt;&lt;div class=&#34;chroma&#34;&gt;
&lt;table class=&#34;lntable&#34;&gt;&lt;tr&gt;&lt;td class=&#34;lntd&#34;&gt;
&lt;pre tabindex=&#34;0&#34; class=&#34;chroma&#34;&gt;&lt;code&gt;&lt;span class=&#34;hl&#34;&gt;&lt;span class=&#34;lnt&#34;&gt;1
&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;hl&#34;&gt;&lt;span class=&#34;lnt&#34;&gt;2
&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;hl&#34;&gt;&lt;span class=&#34;lnt&#34;&gt;3
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/td&gt;
&lt;td class=&#34;lntd&#34;&gt;
&lt;pre tabindex=&#34;0&#34; class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-text&#34; data-lang=&#34;text&#34;&gt;&lt;span class=&#34;line hl&#34;&gt;&lt;span class=&#34;cl&#34;&gt;1. ATTIVO OVUNQUE  → tutti gli account, tutte le region (gli attacchi scelgono gli angoli bui)
&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line hl&#34;&gt;&lt;span class=&#34;cl&#34;&gt;2. INALTERABILE    → i log in un account separato, write-once, fuori dalla portata degli admin
&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line hl&#34;&gt;&lt;span class=&#34;cl&#34;&gt;3. CENTRALIZZATO   → aggregati in un punto solo, per correlare e cercare
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;
&lt;/div&gt;
&lt;/div&gt;&lt;p&gt;Il punto 2 è cruciale e spesso trascurato: un attaccante che ottiene privilegi cerca subito di
&lt;strong&gt;cancellare le proprie tracce&lt;/strong&gt;. Se i log stanno nello stesso account che ha compromesso, può
eliminarli. Vanno quindi inviati a un &lt;strong&gt;account separato di sola scrittura&lt;/strong&gt; (log archive account), con
l&amp;rsquo;immutabilità attiva (object lock), così nessuno — nemmeno un admin dell&amp;rsquo;account di produzione — possa
alterarli.&lt;/p&gt;
&lt;h2 id=&#34;control-plane-e-data-plane&#34;&gt;Control plane e data plane
&lt;/h2&gt;&lt;p&gt;Due livelli di log, con costi e volumi diversi:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Control plane&lt;/strong&gt;: le azioni di &lt;em&gt;gestione&lt;/em&gt; (crea una VM, modifica una policy, cancella un bucket).
Volume gestibile, valore altissimo per la sicurezza. &lt;strong&gt;Sempre attivo.&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Data plane&lt;/strong&gt;: le azioni &lt;em&gt;sui dati&lt;/em&gt; (leggi questo oggetto, invoca questa funzione). Volume enorme e
costoso, ma indispensabile per i dati sensibili. Attivalo &lt;strong&gt;selettivamente&lt;/strong&gt; dove serve sapere chi
accede a cosa.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;conclusione&#34;&gt;Conclusione
&lt;/h2&gt;&lt;p&gt;L&amp;rsquo;audit trail registra chi-ha-fatto-cosa su ogni API: va attivato ovunque, reso inalterabile in un
account separato, e centralizzato. È la materia prima della sicurezza cloud. Ma i log grezzi, da soli,
non avvisano di nulla: qualcuno o qualcosa deve leggerli e riconoscere le minacce. È il passaggio dalla
registrazione alla &lt;a class=&#34;link&#34; href=&#34;https://www.matteobianchi.eu/p/threat-detection-cloud/&#34; &gt;threat detection nel cloud&lt;/a&gt;, prossimo
capitolo.&lt;/p&gt;


&lt;details&gt;
&lt;summary&gt;&lt;strong&gt;Domanda:&lt;/strong&gt; registrare ogni chiamata API genera volumi enormi di log che nessuno leggerà mai e che costano in storage. Non è accumulare dati inutili &#34;per scrupolo&#34;?&lt;/summary&gt;
&lt;p&gt;Sarebbe accumulo inutile se i log servissero a essere &lt;em&gt;letti a mano&lt;/em&gt;, ma non è quello il loro
scopo: servono a essere &lt;em&gt;interrogati quando serve&lt;/em&gt; e &lt;em&gt;analizzati automaticamente sempre&lt;/em&gt;, e
in entrambi i casi il valore è reale e sproporzionato al costo. Pensa al momento dell&#39;incidente: scopri
oggi che tre settimane fa un ruolo è stato compromesso. Senza audit trail, non hai modo di sapere cosa ha
fatto l&#39;attaccante in quelle tre settimane — quali dati ha letto, quali risorse ha creato, se ha lasciato
backdoor. Con l&#39;audit trail, ricostruisci l&#39;intera timeline e sai esattamente l&#39;entità del danno e cosa
bonificare. Quel singolo uso ripaga anni di storage. Ma i log non aspettano passivamente l&#39;incidente: il
loro valore quotidiano è alimentare la &lt;em&gt;detection automatica&lt;/em&gt; (il prossimo capitolo) — sistemi che
leggono il flusso in tempo reale e segnalano l&#39;anomalia, il login da un paese nuovo, la cancellazione di
massa, l&#39;escalation di privilegi. Nessun umano legge i log grezzi; le macchine sì, in continuazione. Sul
costo: i log del control plane, i più preziosi, hanno volume modesto e costano poco; quelli del data
plane, voluminosi, si attivano selettivamente solo dove i dati lo giustificano, e si archiviano su
storage freddo a basso costo con politiche di retention. Il vero &#34;accumulo inutile&#34; sarebbe tenere i log
senza mai interrogarli né analizzarli — ma la soluzione è analizzarli, non smettere di raccoglierli.
Spegnere i log per risparmiare è come togliere le telecamere di sicurezza perché &#34;nessuno guarda i nastri&#34;:
il punto è averli quando serve guardare indietro.&lt;/p&gt;
&lt;/details&gt;


</description>
        </item>
        
    </channel>
</rss>
