DevEnv nis2-agileandClaude Opus 4.8
1c2eced7a4
Provisioning idempotente di un'azienda cliente cloud-only (Aruba/Hetzner/AI, no server in sede, PC portatili): - Fase 1: org + classificazione NIS2 (important, sub_threshold_candidate/preliminary) + 3 membri esistenti collegati + organigramma 8 ruoli - Fase 2: 12 asset (NIS2-rilevanti) + 4 fornitori + 10 rischi + gap analysis (80 risposte, 45%) - Fase 3: ISMS model + SoA 111 controlli (27001/27017/27018) + 31 documenti (Manuale/10 politiche/13 procedure/7 istruzioni) - Fase 4: 15 piani di controllo periodici + 5 corsi formazione Documenti AI-redatti con regole fonti-certe (D.Lgs.138/2024 art.23/24/25; 24h/72h/1 mese). Sorgenti in _docs_na/. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
43 lines
3.8 KiB
HTML
43 lines
3.8 KiB
HTML
<!--META|doc_type=istruzione_log_review|title=Istruzione Operativa: Revisione di Log e Accessi|status=approved|version=1.0-->
|
|
|
|
<h2>1. Scopo</h2>
|
|
<p>Definire come e con quale frequenza il Resp. IT/Sicurezza esamina i registri (log) e gli accessi dei servizi cloud di Nuova Agile Technology srl, per rilevare tempestivamente attività anomale o accessi non autorizzati. In assenza di server in sede, i log dei servizi cloud sono la principale fonte di visibilità.</p>
|
|
|
|
<h2>2. A chi si applica</h2>
|
|
<p>Principalmente al Resp. IT/Sicurezza <strong>Simon Fattori</strong> (esecutore). I dipendenti e collaboratori collaborano segnalando attività anomale sui propri account.</p>
|
|
|
|
<h2>3. Prerequisiti</h2>
|
|
<ul>
|
|
<li>Logging attivo su tutti i servizi critici (posta, console Aruba/Hetzner, repository, piattaforme AI, password manager, prodotti SaaS).</li>
|
|
<li>Accesso autorizzato ai registri e, dove disponibile, agli avvisi di sicurezza dei fornitori.</li>
|
|
<li>Orari di riferimento coerenti (fuso Europe/Rome o UTC documentato) per correlare gli eventi.</li>
|
|
</ul>
|
|
|
|
<h2>4. Passi operativi</h2>
|
|
<ol>
|
|
<li><strong>Verifica giornaliera rapida.</strong> Controlla gli avvisi di sicurezza automatici ricevuti via email dai fornitori (nuovi accessi, login da nuovi dispositivi/paesi, blocchi MFA). Tratta ogni avviso come da valutare, non da ignorare.</li>
|
|
<li><strong>Revisione settimanale degli accessi.</strong> Esamina i log di autenticazione dei servizi critici cercando: login falliti ripetuti, accessi da località/orari inusuali, accessi a orari notturni non giustificati, nuove sessioni o dispositivi non riconosciuti.</li>
|
|
<li><strong>Controllo dei cambiamenti privilegiati.</strong> Verifica modifiche a ruoli/permessi, creazione di nuovi account, generazione o rotazione di chiavi API e token. Ogni cambiamento deve essere riconducibile a una richiesta legittima.</li>
|
|
<li><strong>Log dei prodotti SaaS.</strong> Controlla i registri applicativi (audit log) dei prodotti per accessi anomali ai dati dei clienti ed errori ricorrenti.</li>
|
|
<li><strong>Correla gli eventi.</strong> Se noti un'anomalia, ricostruisci la sequenza tra servizi diversi usando orari allineati, per capire se si tratta di un singolo evento o di una catena.</li>
|
|
<li><strong>Conserva e proteggi i log.</strong> Assicurati che i registri non siano modificabili dagli utenti finali e siano conservati per un periodo adeguato secondo le impostazioni dei fornitori [DA VERIFICARE rispetto alla policy di retention interna].</li>
|
|
<li><strong>Documenta la revisione.</strong> Annota data, servizi controllati, anomalie rilevate e azioni intraprese nel registro delle revisioni.</li>
|
|
</ol>
|
|
|
|
<h2>5. Verifiche e controlli di esito</h2>
|
|
<ul>
|
|
<li>Logging attivo confermato su tutti i servizi critici.</li>
|
|
<li>Revisione settimanale eseguita e registrata.</li>
|
|
<li>Ogni anomalia rilevata risulta tracciata con esito (chiusa come falso positivo o escalata a incidente).</li>
|
|
<li>Nessun account o chiave attivi non riconducibili a personale in forza.</li>
|
|
</ul>
|
|
|
|
<h2>6. In caso di problema</h2>
|
|
<p>Se rilevi un accesso non autorizzato confermato o sospetto, una chiave compromessa o attività anomale sui dati dei clienti, avvia la procedura di gestione incidenti. Il referente è il Resp. IT/Sicurezza <strong>Simon Fattori</strong>; per incidenti che possono ricadere sotto NIS2 ricorda le tempistiche di notifica al CSIRT Italia: pre-allarme 24h, notifica 72h, relazione finale 1 mese.</p>
|
|
|
|
<h2>7. Controlli ISO collegati</h2>
|
|
<p>ISO/IEC 27001:2022 — A.8.15 (logging), A.8.16 (attività di monitoraggio), A.5.17 (autenticazione). Coerente con ISO/IEC 27017/27018 per i servizi cloud e i dati personali, e con NIS2 (D.Lgs. 138/2024, art. 24) per il rilevamento degli incidenti.</p>
|
|
|
|
<h2>8. Versionamento</h2>
|
|
<p>Versione 1.0 — Stato: approvato. RSGSI: Massimo Tagliavini. Resp. IT: Simon Fattori. Approvazione Direzione: Silvia Garretto. Revisione almeno annuale.</p>
|