Quando si parla di sicurezza informatica, è facile concentrarsi sulle vulnerabilità, sugli aggiornamenti e sulle configurazioni dei server.
C'è però un aspetto altrettanto importante: il ciclo di vita delle risorse tecnologiche.
Un server viene creato, configurato, utilizzato, aggiornato e, prima o poi, dismesso. Lo stesso vale per domini, applicazioni, API e servizi cloud.
Se una di queste fasi viene trascurata, la risorsa può rimanere attiva senza un motivo valido oppure continuare a esporre servizi che nessuno controlla più.
Questo processo di gestione è conosciuto come asset lifecycle management.
Che cos'è l'asset lifecycle management?
È l'insieme delle attività utilizzate per gestire una risorsa durante tutta la sua vita operativa.
Un ciclo semplificato è:
Pianificazione
↓
Creazione
↓
Configurazione
↓
Utilizzo e manutenzione
↓
Revisione
↓
Dismissione
La sicurezza dovrebbe essere considerata in ogni fase, non soltanto quando il sistema è già in produzione.
1. Prima della creazione
Prima di attivare una nuova risorsa, è utile definire:
- a cosa serve;
- chi la utilizzerà;
- chi ne sarà responsabile;
- quali dati gestirà;
- se dovrà essere raggiungibile da Internet;
- quali dipendenze avrà;
- come verrà mantenuta.
Queste informazioni aiutano a evitare che un servizio venga pubblicato senza una motivazione chiara.
Per esempio, un ambiente destinato esclusivamente a test interni potrebbe non aver bisogno di un indirizzo pubblico.
2. Durante la configurazione
Quando un server o un'applicazione viene attivato, bisogna verificare che la configurazione sia coerente con il suo scopo.
Per un servizio pubblico possono essere necessari HTTPS, aggiornamenti regolari, logging e controlli di accesso.
Per un componente interno, invece, potrebbe essere prioritario limitare la raggiungibilità attraverso la rete.
Un esempio di distinzione:
Web server
→ accessibile pubblicamente sulle porte necessarie
Database
→ accessibile soltanto dai componenti autorizzati
L'obiettivo è evitare esposizioni non necessarie fin dall'inizio.
3. Durante l'utilizzo
Una risorsa attiva richiede manutenzione.
Con il tempo possono cambiare:
- le versioni del software;
- le persone responsabili;
- i requisiti operativi;
- le autorizzazioni;
- le dipendenze;
- le esigenze di esposizione pubblica.
Per questo l'inventario deve essere aggiornato e le configurazioni riesaminate periodicamente.
Un server correttamente configurato al momento dell'attivazione potrebbe non esserlo più dopo diversi cambiamenti.
4. Quando cambiano le esigenze
Supponiamo che un'applicazione venga sostituita da una nuova piattaforma.
Il vecchio sistema potrebbe non essere più necessario, ma la sua dismissione non avviene sempre insieme alla migrazione.
Il risultato può essere:
Nuova applicazione
→ utilizzata quotidianamente
Vecchia applicazione
→ ancora online
→ aggiornamenti trascurati
→ proprietario non identificato
Questa situazione aumenta la complessità della gestione e può creare una superficie di attacco evitabile.
Ogni cambiamento importante dovrebbe quindi prevedere una revisione delle risorse coinvolte.
5. La dismissione è una fase di sicurezza
Spegnere un server non significa necessariamente aver completato la dismissione.
Possono rimanere:
- record DNS;
- indirizzi IP assegnati;
- certificati da gestire;
- credenziali e chiavi API;
- backup;
- account di servizio;
- regole firewall;
- integrazioni con altri sistemi.
Una procedura di dismissione dovrebbe verificare anche questi elementi.
Naturalmente, i dati devono essere conservati o eliminati secondo gli obblighi applicabili e le esigenze dell'organizzazione.
Una checklist per dismettere un asset
Prima di rimuovere definitivamente una risorsa, è utile controllare:
- [ ] Il servizio non è più necessario?
- [ ] Sono state verificate le dipendenze?
- [ ] Gli utenti e i sistemi interessati sono stati informati?
- [ ] I dati sono stati archiviati o eliminati correttamente?
- [ ] Le credenziali non più necessarie sono state revocate?
- [ ] I record DNS sono stati aggiornati?
- [ ] Le regole di rete obsolete sono state rimosse?
- [ ] Le risorse cloud associate sono state individuate?
- [ ] L'inventario è stato aggiornato?
- [ ] È stata verificata l'assenza di esposizioni residue?
La checklist va adattata al tipo di risorsa: dismettere un semplice sottodominio è diverso dal ritirare un sistema che gestisce dati aziendali.
Il legame tra lifecycle management e attack surface
La superficie di attacco cambia continuamente perché le risorse vengono create, modificate e rimosse.
Se queste attività non sono coordinate, possono comparire differenze tra l'inventario e ciò che è realmente esposto.
Per esempio:
Inventario interno
→ vecchio servizio rimosso
Osservazione esterna
→ hostname ancora raggiungibile
Questa discrepanza è un segnale da approfondire.
Non dimostra necessariamente che il vecchio server sia ancora attivo: il DNS potrebbe puntare altrove, oppure potrebbe esistere una pagina residua. È proprio per questo che servono verifiche successive.
Come misurare la qualità del processo?
Alcuni indicatori possono aiutare a capire se la gestione sta migliorando:
| Indicatore | Cosa misura | | ----------------------------------- | --------------------------------- | | Asset con proprietario assegnato | Responsabilità e tracciabilità | | Asset non riconosciuti | Lacune nell'inventario | | Asset senza revisione recente | Risorse potenzialmente trascurate | | Dismissioni incomplete | Rischio di esposizioni residue | | Tempo di verifica di un nuovo asset | Rapidità del controllo |
Gli indicatori devono essere interpretati nel contesto. Un numero elevato di asset non riconosciuti, per esempio, può dipendere da una nuova attività di ricognizione che ha appena fatto emergere risorse prima sconosciute.
In sintesi
La sicurezza non riguarda soltanto ciò che è attivo oggi, ma anche ciò che è stato creato ieri e avrebbe dovuto essere rimosso.
Un buon asset lifecycle management permette di mantenere sotto controllo le risorse dalla loro attivazione fino alla dismissione, riducendo la possibilità che server, domini e applicazioni rimangano esposti senza una ragione.
MiHakero può contribuire alla verifica periodica della superficie pubblica, aiutando a individuare risorse che meritano un controllo durante le fasi di manutenzione, migrazione e dismissione.