Hardening: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica |
m Bot: sintassi dei link e modifiche minori |
||
Riga 4:
==Descrizione==
In [[italia]] rientra nelle pratiche tecniche introdotte dal [[documento programmatico sulla sicurezza]] 196/03 sulla sicurezza dei dati ed in generale enuncia i criteri da adottare per garantire l'adozione delle misure minime di sicurezza sui sistemi e sulle infrastrutture tecnologiche. Dal 25 Maggio 2018 avrà efficacia il [[Regolamento generale sulla protezione dei dati]]
Uno degli errori più comuni nella realizzazione di un sistema informatico riguarda la fase di installazione di un sistema operativo, di un network device o di un'applicazione. Quando si procede ad un lavoro di questo genere, spesso questi componenti non sono ben configurati per impedire i relativi rischi di [[sicurezza informatica]] che possono derivarne, ma sono soggetti ad una configurazione quanto più aderente ai principi basilari dell'amministrazione e più in generale al fine economico che l’azienda persegue. Inoltre, soprattutto la componente software può contenere vulnerabilità che mettono a rischio il sistema.<ref>{{it}}https://www.01net.it/i-principi-di-base-dellhardening-dei-sistemi-parte-1/</ref>
Riga 21:
L'hardening si divide in tre parti fondamentali:
1) '''pre-analisi sullo stato attuale'''
Di solito si identificano per primi i dispositivi di rete. Si tratta di componenti [[hardware]] (e di software che li gestiscono) esposti e visibili da tutti gli altri nodi della rete.
Si procede poi con il [[software di base]]. Ad esempio, un [[sistema operativo]], uno dei componenti principali del software di base, funziona ed interagisce con il resto del sistema informatico mediante vari servizi e utility. Ognuna di queste componenti è pertanto in grado di fornire uno spunto di attacco ad un soggetto malintenzionato che ne abbia scoperto delle vulnerabilità.
Riga 33:
Ultimo fattore da analizzare è dato dalla robustezza fisica dei componenti. L'hardening qui riguarda la capacità del sistema di far fronte principalmente a disastri naturali e a problemi derivanti dalle alterazioni cui possono essere soggetti i componenti fisici del sistema informatico.
2) '''remedy'''
Per la parte di remedy (letteralmente rimedio) vengono elencate delle attività tecniche mirate che poi devono essere opportunamente documentate([[Report informativo|report]]) al fine di garantire la history sul singolo componente dell'infrastruttura e poter permettere un eventuale ripristino([[rollback]]) in caso di blocco della funzionalità. La parte di report è poi soggetta ad un test([[Audit (informatica)|audit]]) successivo di verifica atto a convalidare lo stato di sicurezza raggiunto (compliance). La documentazione dovrà essere attinente alla nuova legge europea
Questa attività di remedy viene normalmente effettuata attraverso operazioni distinte:
Riga 50:
:* installazione delle [[patch (informatica)|patch]] di sicurezza;
:* rimozione degli utenti non necessari;
:* etc.
3) '''monitoring per un dato tempo'''
| |||