Come creare solide misure di sicurezza per proteggere i tuoi server

Introduzione

Quando si lavora su un'infrastruttura cloud, la preoccupazione principale è garantire che le applicazioni siano pienamente operative. Un elemento importante del processo di configurazione e distribuzione consiste nell'integrare misure di sicurezza efficaci, approfondite e robuste nelle app o nei sistemi prima che vengano offerti al pubblico. Invece di implementare retroattivamente le misure di sicurezza dopo la distribuzione, è importante garantire che nell'infrastruttura sia integrata una configurazione di base sicura.

Questo tutorial ti aiuterà in questo senso. Evidenzierà alcune misure di sicurezza pratiche che possono essere implementate durante la configurazione dell'infrastruttura del server. Sebbene questo non sia un elenco esaustivo di protocolli di sicurezza del server, è un utile punto di partenza. Man mano che lavori e comprendi meglio le esigenze specifiche del tuo ambiente e delle tue applicazioni, potrai sviluppare ulteriori misure di sicurezza per migliorare la tua base.

Chiavi SSH (Secure Shell)

Mentre lavori con il tuo server, la maggior parte del tempo la trascorrerai lavorando in una connessione SSH con il tuo server in una sessione di terminale. Le chiavi SSH (Security Shell) forniscono un metodo di accesso al server più sicuro rispetto agli accessi basati su password. Ai fini dell'autenticazione, con l'uso delle chiavi SSH, vengono preparate due chiavi di accesso. La prima è una chiave segreta (privata), mentre l'altra è una chiave pubblica condivisibile.

L'autenticazione tramite chiave SSH deve prima essere configurata. Questo si ottiene inserendo la chiave pubblica SSH nella directory corretta sul server. Quando il client si connette inizialmente al server, ti verrà richiesta la prova del possesso della chiave privata. Ciò avviene tramite la generazione di un valore casuale che verrà poi inviato al tuo client SSH. Il client SSH, a sua volta, utilizzerà la chiave privata per crittografare una risposta. Questa risposta verrà inviata al server. Successivamente, il server decifrerà il messaggio del client utilizzando la tua chiave pubblica. Se il valore casuale viene decifrato dal server, significa che il client possiede la chiave privata. In tal caso, l'autenticazione è confermata e può essere stabilita una connessione al server senza password.

Migliorare la sicurezza con le chiavi SSH

Sebbene l'autorizzazione tramite password o qualsiasi autenticazione con SSH sia completamente crittografata, l'accesso al server può essere tentato da utenti malintenzionati. Soprattutto se sono entrati in possesso dell'indirizzo IP pubblico del server. Provando ogni possibile combinazione di tasti, l'informatica moderna consente gli accessi basati su password, che vengono spesso tentati da utenti malintenzionati. Se si dovessero automatizzare questi tentativi di accesso, è possibile, provando sistematicamente diverse combinazioni, arrivare infine alla password corretta.

Sfruttando l'autenticazione crittografata SSH, non è necessario abilitare le password per l'accesso. Le chiavi SSH contengono in genere un numero enorme di combinazioni possibili che un utente malintenzionato dovrebbe provare. L'aumento del numero di bit moltiplica il potenziale delle diverse combinazioni necessarie per violare la crittografia. Passare in rassegna tutte le possibili combinazioni dell'algoritmo della chiave SSH richiederebbe quindi un'immensa quantità di tempo. Di conseguenza, diventa un'impresa che non vale il tempo di un utente malintenzionato. Questo è il motivo per cui la crittografia SSH è tipicamente considerata 'inviolabile'.

Implementazione delle chiavi SSH

L'accesso a qualsiasi server Linux remoto dovrebbe utilizzare le chiavi SSH. È possibile generare una chiave sulla macchina locale, con la chiave pubblica trasferita al server in pochi minuti. Con questo tutorial avrai un'idea di base su come utilizzare SSH per connettersi a un server remoto in Ubuntu.  Puoi anche seguire il nostro approfondito tutorial su come configurare il tuo server Linux per utilizzare l'autenticazione basata su chiavi SSH.

Nel complesso, non consentire all'utente root di accedere direttamente tramite SSH è una best practice comunemente utilizzata, mentre si accede come utente non privilegiato e si utilizza uno strumento come sudo per elevare i privilegi secondo necessità. Questo è noto come principio del privilegio minimo: un metodo per limitare i permessi di accesso. Una volta verificato l'accesso come account non privilegiato con SSH, gli accessi root possono essere disabilitati impostando la direttiva PermitRootLogin no in /etc/ssh/sshd_config sul server. Successivamente, il server può essere riavviato con un comando del processo SSH sudo systemctl restart sshd.

Firewall

Un software (o dispositivo hardware) che regola l'esposizione dei servizi alla rete è noto come firewall. Un firewall, configurato in modo ottimale, garantisce che solo i servizi consentiti siano disponibili pubblicamente e ammessi in entrata e in uscita dal server specifico.

Diversi servizi possono essere in esecuzione per impostazione predefinita su un server e questi possono essere classificati nei seguenti gruppi:

• Servizi interni: Vi si dovrebbe accedere solo internamente dal server stesso. Ciò impedisce l'esposizione dei servizi dall'accessibilità Internet disponibile pubblicamente (es: un database raggiungibile solo tramite connessioni locali).
• Servizi pubblici: Servizi a cui chiunque può accedere, spesso in modo anonimo, su Internet. Questi includono i server web che consentono ai visitatori di accedere al tuo sito.
• Servizi privati: Solo gli account autorizzati provenienti da un set esclusivo di posizioni possono accedere a questi servizi (es: pannello di controllo del database phpMyAdmin).

Mentre i servizi pubblici possono essere lasciati disponibili per l'accesso da Internet, i servizi privati possono essere limitati in base ai parametri di accesso (come i tipi di connessione) e i servizi interni sono completamente esclusi da qualsiasi accesso basato su Internet. L'accesso a questi servizi, insieme alla granularità con cui è consentito, è interamente controllato dal firewall. Le porte inutilizzate sono comunemente configurate per bloccare completamente l'accesso ad esse.

Miglioramento della sicurezza con l'uso del firewall

Un firewall è una base per la protezione del server. Serve a limitare la connessione da e verso i servizi prima che l'applicazione gestisca il traffico. Naturalmente, puoi implementare funzionalità di sicurezza aggiuntive per i tuoi servizi e limitarli alle interfacce desiderate.

Solo i servizi che scegli di lasciare aperti non saranno limitati da un firewall configurato correttamente. Ciò limita gli elementi vulnerabili allo sfruttamento poiché i software disponibili sono molto più limitati e quindi hanno meno probabilità di subire un attacco.

Implementazione dei firewall

Molti firewall sono disponibili per i sistemi Linux. Alcuni di questi sono piuttosto complessi. Tuttavia, la configurazione tipica di un firewall dovrebbe essere eseguita solo al momento della configurazione iniziale del server, quando vengono implementate modifiche ai servizi del server. Questo dovrebbe richiedere solo pochi minuti del tuo tempo. Di seguito sono riportate alcune opzioni da considerare per configurare e attivare il firewall:

• Per CentOS, puoi seguire la nostra guida alla configurazione di un firewall con FirewallD su CentOS 7.
• La nostra guida a Iptables può guidarti nella visualizzazione e nell'eliminazione delle regole del firewall Iptables.

Ancora più importante, indipendentemente dal tutorial, devi assicurarti che il firewall scelto blocchi il traffico sconosciuto verso i tuoi server al fine di evitare che nuovi servizi disponibili vengano inavvertitamente esposti su Internet. Dovendo autorizzare esplicitamente l'accesso, sarai spinto a valutare appieno come si accede a un servizio, come viene eseguito e da chi è consentito l'accesso.

Reti Virtual Private Cloud (VPC)

Le risorse della tua infrastruttura devono operare all’interno di una rete privata nota come VPC. Queste reti sono più sicure in quanto impediscono l'accesso da altre reti VPC basate su cloud. Pertanto, rendono le interfacce della rete inaccessibili dall'Internet pubblico.

Miglioramento della sicurezza con le reti VPC

Le reti private sono preferibili alla controparte pubblica per la comunicazione interna. Il VPC consente l’isolamento di gruppi di risorse in specifiche reti private. Poiché le reti VPC si interfacciano solo tramite connessioni private, il traffico della rete è protetto dall’esposizione a Internet pubblico, dove tali informazioni potrebbero essere vulnerabili a intercettazioni o esposizioni. Le reti VPC possono anche essere utilizzate per isolare gli ambienti di esecuzione, nonché i tenant. I gateway Internet possono anche essere configurati come un unico punto di accesso tra l’Internet pubblico e le risorse sulla rete VPC.

Inoltre, gran parte della sicurezza comporta l’analisi dei nostri sistemi e la protezione di tutti i componenti al meglio delle nostre capacità. L’audit dei servizi ci consente di conoscere i protocolli accettabili dei sistemi, i servizi in esecuzione e quali porte vengono utilizzate per la comunicazione. Conoscere queste informazioni può aiutare a prendere le decisioni migliori in merito alla configurazione. Tali decisioni potrebbero riguardare le impostazioni del firewall, il monitoraggio e gli avvisi di sistema e quali servizi dovrebbero essere accessibili pubblicamente.

Sfruttare l’audit per migliorare la sicurezza

Ogni servizio può essere utilizzato per la gestione di client esterni o per scopi interni. Indipendentemente dall’intento, questi servizi sono tutti punti di vulnerabilità per gli utenti malintenzionati. Con l’aumentare del numero di servizi in esecuzione, aumenta anche il potenziale di sfruttamento delle vulnerabilità.

È possibile iniziare ad analizzare i servizi una volta acquisita una solida comprensione di quali servizi sono in esecuzione su una macchina. Quando si esegue un audit dei servizi, è utile porsi le seguenti domande:

• Il servizio specifico dovrebbe essere attivamente in esecuzione?
• È in esecuzione sulle interfacce di rete ottimali?
• Il servizio è più adatto per un’interfaccia di rete pubblica o privata?
• Le regole del firewall sono configurate correttamente per consentire il traffico legittimo verso questo servizio?
• Il traffico illegittimo viene bloccato con le mie regole del firewall?
• È abilitato un sistema di avviso sulle vulnerabilità di sicurezza?

Quando si aggiunge un nuovo server all’infrastruttura, quanto sopra dovrebbe costituire una pratica standard nel suo processo di configurazione. Un ulteriore vantaggio degli audit dei servizi è che consentiranno di identificare eventuali configurazioni modificate involontariamente.

Esecuzione degli audit dei servizi

Per verificare i servizi in esecuzione, utilizzare il comando ss per elencare tutte le porte UDP e TCP attivamente utilizzate su un server. Ecco un esempio di utilizzo del comando ss con il PID del nome del programma, per verificare le porte TCP e UDP in ascolto:

Verrà restituito qualcosa di simile al seguente:

L’attenzione principale dovrebbe essere rivolta alle colonne Netid, Local Address:Port e Process:

• Se il valore Local Address:Port è 0.0.0.0, significa che il servizio accetta attivamente tutte le connessioni su tutte le interfacce di rete IPv4. Se l’indirizzo è [::], tutte le connessioni IPv6 accettano il traffico.
• Nell’esempio sopra, sia Nginx che SSH sono in ascolto su tutte le interfacce pubbliche su entrambi gli stack di rete (IPv4 e IPv6).

Con l’documento precedente, potresti scegliere se consentire a SSH e Nginx di ascoltare su entrambe le interfacce o solo su una di esse. In genere, si consiglia di disabilitare tutti i servizi inutilizzati per evitare che rimangano in esecuzione. Ad esempio, se il tuo sito dovesse essere raggiungibile solo tramite IPv4, sarebbe utile disattivare le interfacce IPv6 per limitare l’esposizione.

Rimanere aggiornati con gli aggiornamenti non presidiati

Gli aggiornamenti non presidiati riducono il livello di impegno richiesto per mantenere sicuri i server e aiutano a ridurre il tempo in cui rimangono esposti a bug noti. Più tempo si impiega per eseguire gli aggiornamenti sul server, più a lungo questo rimarrà esposto a vulnerabilità note. Gli aggiornamenti non presidiati assicureranno che, non appena saranno disponibili i pacchetti di correzione, questi possano essere installati automaticamente sul server per limitare il tempo di vulnerabilità.

Oltre all’audit del server, gli aggiornamenti non presidiati possono ridurre notevolmente l’esposizione agli attacchi. Ridurranno inoltre notevolmente il tempo dedicato alla manutenzione del server.

Come vengono attivati gli aggiornamenti non presidiati

Gli aggiornamenti non presidiati sono ormai una funzionalità opzionale sulla maggior parte delle distribuzioni server. Su Ubuntu, ad esempio, l'amministratore può eseguire il seguente comando:

Per ulteriori informazioni sull'implementazione degli aggiornamenti non presidiati, consulta la sezione Aggiornamenti Automatici qui. Per Fedora, le istruzioni si trovano qui. Tieni presente che gli aggiornamenti automatici installeranno solo il software inizialmente installato tramite il sistema di gestione dei pacchetti del tuo sistema. Eventuali applicazioni supplementari, come quelle basate sul web, dovranno essere controllate separatamente per gli aggiornamenti in modo manuale o configurate singolarmente per gli aggiornamenti automatici.

Indici delle directory

Quando una directory non ha un file indice, la maggior parte dei server è configurata per mostrare gli indici delle directory per impostazione predefinita. In altre parole, se sul tuo server web viene creata una directory chiamata 'downloads', chiunque navighi in quella directory sarà in grado di vedere tutti i file in essa contenuti. Sebbene questo non sia sempre un rischio per la sicurezza, rende visibili informazioni riservate a occhi non autorizzati. Ad esempio, considera che il tuo server web potrebbe avere un file contenente le credenziali di accesso alla homepage del tuo sito web e un file con tutte le configurazioni del database di back-end del sito. Se gli indici delle directory non sono disabilitati, questi file saranno visibili a chiunque navighi in quella directory.

Aumentare la sicurezza disabilitando gli indici delle directory

Anche se gli indici delle directory sono utili, possono esporre involontariamente i file. Per mitigare tale esposizione involontaria e i rischi associati, gli indici delle directory sul server dovrebbero essere disabilitati per impostazione predefinita. Sebbene i file possano comunque essere raggiunti dai visitatori, l'esposizione alla visualizzazione involontaria dei dati è notevolmente limitata.

Disabilitare gli indici delle directory

Nella maggior parte dei casi, l'aggiunta di una sola riga in più alla configurazione del tuo server web è sufficiente per disabilitare gli indici delle directory.

• Segui questi passaggi per disabilitare questi elenchi di directory sul Wiki di Apache. Assicurati che Options -Indexes siano elencate nei blocchi di configurazione Apache Directory.
• Gli indici sono disabilitati per impostazione predefinita su Nginx, quindi non è richiesta alcuna ulteriore azione a riguardo.

Backup frequenti

Anche se i backup non sono una misura di sicurezza, sono fondamentali per salvaguardare i dati e interi sistemi nel caso in cui il sistema venga compromesso. Aiutano anche ad analizzare come il sistema possa essere stato attaccato. Considera uno scenario sfortunato in cui il tuo sistema viene attaccato da un ransomware (un virus o un malware che crittografa i file sul tuo sistema, decrittografandoli solo se paghi del denaro all'hacker). Se non ci sono backup dei dati, l'unica scelta è pagare il denaro per riottenere l'accesso ai tuoi dati. Se i dati sono sottoposti a backup sicuro, avrai comunque accesso ad essi e potrai recuperarli senza dover accedere al sistema compromesso.

Miglioramento della sicurezza tramite backup frequenti

I backup frequenti aiutano a recuperare le informazioni a causa di attacchi, corruzione o persino perdita involontaria (cancellazione). Indipendentemente dal tipo di evento negativo che porta alla perdita di dati, il rischio è ridotto dalla conservazione di copie dei dati del server.

Oltre agli attacchi ransomware, i backup frequenti possono aiutare nell'indagine misurabile di attacchi di sistema a lungo termine. Se non memorizzi in modo sicuro i tuoi dati in un formato di backup, determinare la fonte dell'attacco e quali dati sono stati compromessi può essere difficile o addirittura impossibile.

Implementazione di backup frequenti

Considerare il recupero verificabile di dati corrotti, compromessi o cancellati come l'obiettivo dei tuoi sforzi di ripristino durante il backup dei sistemi è fondamentale. Per inquadrarlo al meglio, considera quali azioni richiederebbero la minor quantità di lavoro per rimetterti in sesto se il tuo server dovesse sparire domani.

Ecco alcuni altri punti da considerare quando si pensa a un piano di disaster recovery:

• Se operate con dati che cambiano dinamicamente, i vostri backup dovranno probabilmente essere più frequenti. In caso di perdita di dati, se l'ultimo backup risale a troppo tempo fa, potreste essere costretti a tornare a dati obsoleti.
• Pensate al processo effettivo di ripristino del backup. Sarà necessario aggiungere un nuovo server o sarà possibile ripristinare quello esistente?
• Qual è il periodo di tempo massimo in cui il server può non essere operativo?
• Il backup offsite è una soluzione necessaria?

Per saperne di più sulle soluzioni di Disaster Recovery di CloudSigma, consultate il nostro post sul blog che descrive in dettaglio perché il nostro Disaster-Recovery-as-a-Service è il compagno perfetto per il cloud. E qui potete trovare maggiori informazioni su funzionalità di sicurezza & continuità aziendale di CloudSigma. Abbiamo anche una guida dettagliata su come configurare facilmente la funzionalità di backup di CloudSigma.

Reti private e VPN

Una rete privata è una rete disponibile per l'accesso e l'utilizzo solo da parte di utenti o server specifici. Una connessione sicura tra dispositivi remoti che consente alla connessione di operare come se fosse in una rete privata è una VPN (una rete privata virtuale). Vi offre la possibilità di proteggere le connessioni in una rete privata e di collegare server remoti.

In che modo le reti private migliorano la sicurezza?

Quando si può scegliere se utilizzare reti pubbliche o private per la comunicazione interna, la seconda opzione è sempre quella preferibile. Tenete presente, tuttavia, che altri utenti all'interno del data center possono comunque accedere alla stessa rete. Ciò significa che è necessario applicare misure di sicurezza supplementari per garantire che la comunicazione tra i server sia sicura.

In sostanza, l'utilizzo di una VPN è un approccio per delineare ciò che i dipendenti della vostra organizzazione possono vedere. La corrispondenza sarà completamente sicura e privata. Le configurazioni delle applicazioni consentirebbero il passaggio del traffico dell'interfaccia virtuale attraverso la VPN. In questo modo, solo i servizi destinati all'interazione con i clienti via Internet potranno essere esposti a una rete pubblica.

Quanto è difficile implementare una VPN?

Sfruttare le reti private è semplice per il vostro data center così come configurare le applicazioni e il firewall per l'utilizzo di una rete privata e abilitare la VPN durante la creazione del server. È importante ricordare che altri server condividono lo stesso spazio di rete delle reti private dell'intero data center.

La configurazione iniziale di una VPN è leggermente più complessa. Tuttavia, la sicurezza aggiuntiva che offre vale la pena per la maggior parte dei casi d'uso. I dati di configurazione e la sicurezza condivisa devono essere installati e configurati su ciascun server della rete. Per informazioni più approfondite su come funziona una VPN e una panoramica sulla configurazione di OpenVPN su Ubuntu, seguite questa guida. Potete anche seguire questo tutorial che vi guida attraverso i passaggi per connettere una rete VPN all'infrastruttura di CloudSigma.

Crittografia SSL/TLS e infrastruttura a chiave pubblica

La generazione, la gestione e la convalida dei certificati per identificare le persone e la crittografia delle comunicazioni sono denominate Infrastruttura a chiave pubblica (PKI). Diverse entità possono essere autenticate tra loro con l'uso di certificati SSL o TLS certificati. Successivamente, possono essere utilizzati anche per stabilire una comunicazione crittografata.

In che modo i certificati migliorano la sicurezza

Al fine di crittografare il traffico e convalidare le identità dei membri su un server, è fondamentale stabilire un'autorità di certificazione (CA) e poter vedere tutti i certificati della rete. Questo può aiutare a prevenire gli attacchi 'man-in-the-middle', in cui il server viene imitato da un hacker e il traffico viene reindirizzato altrove.

La configurazione di ciascun server può essere impostata per considerare attendibile una CA centralizzata. Qualsiasi firma di certificato successiva può quindi essere considerata implicitamente attendibile. Se la crittografia SSL/TLS è supportata dai protocolli e dalle app utilizzate dal server, è possibile proteggere il sistema senza il sovraccarico del tunnel VPN. Per ulteriori informazioni, seguite il nostro tutorial su come automatizzare i rinnovi dei certificati SSL di LetsEncrypt per Nginx.

Difficoltà di implementazione

La configurazione di un’autorità di certificazione e la successiva impostazione della restante PKI possono richiedere un notevole sforzo iniziale. Inoltre, quando è necessario creare, revocare o firmare nuovi certificati, sarà richiesto un ulteriore sforzo amministrativo.

Poiché la maggior parte delle infrastrutture deve crescere, l’implementazione di una PKO completa è l’approccio più sensato. Fino a quando non si raggiunge un punto in cui la PKI vale i costi amministrativi aggiuntivi, l’utilizzo di una VPN per proteggere i componenti del sistema può fungere da adeguata misura temporanea.

Rilevamento delle intrusioni nel sistema e utilizzo dell’audit dei file

L’audit dei file è un processo utilizzato per confrontare i file e i relativi attributi del sistema in uno stato completamente sicuro e integro con quelli attuali del sistema. Questo è un buon metodo per trovare e isolare modifiche non autorizzate al sistema.

Un IDS, intrusion detection system, si riferisce a un software di monitoraggio che tiene traccia di qualsiasi attività non autorizzata sul sistema. In genere, utilizza metodi di audit dei file per cercare eventuali modifiche impreviste del sistema.

Miglioramento della sicurezza tramite IDS/Audit dei file

Oltre al semplice audit a livello di servizio, l’esecuzione di audit a livello di file è essenziale per garantire la sicurezza del sistema. Questo può essere fatto tramite un processo IDS automatizzato o eseguito periodicamente dall’amministratore di sistema.

Gli audit dei file e gli IDS sono gli unici veri processi per assicurarsi che il sistema non abbia subito modifiche impreviste. La maggior parte degli intrusi vuole sfruttare i server che invade per lunghi periodi di tempo e, per farlo, deve mantenere la capacità di agire in modo furtivo. Potrebbero sostituire i file binari con versioni vulnerabili o compromesse. Qualsiasi file che sia stato modificato nel sistema verrà rilevato da un audit del filesystem. Questo offre la tranquillità di sapere molto rapidamente se l’integrità del sistema è stata compromessa.

Livello di difficoltà di implementazione

L’implementazione dell’IDS e dell’audit dei file può essere un processo molto intenso. All’inizio, il sistema deve essere configurato per definire i percorsi da escludere e stabilire le modifiche non standard che sono state apportate al sistema, al fine di creare una lettura di riferimento (baseline) del sistema.

Anche le operazioni quotidiane diventano più onerose, poiché le procedure dovranno ricontrollare il sistema prima dell’esecuzione di qualsiasi aggiornamento. Anche la baseline delle misurazioni del sistema dovrà essere ricreata o ristabilita per recepire le modifiche della versione del software come parte della nuova baseline del sistema. Anche i report di audit dovranno essere trasferiti in una posizione alternativa. Questo perché è necessario impedire a un intruso del sistema di alterare l’audit per rimanere nascosto coprendo le proprie tracce.

Sebbene questo aumenti certamente il carico amministrativo del sistema, è uno dei pochi modi sicuri per garantire che nessuno dei file sia stato modificato a vostra insaputa. Alcuni dei sistemi di rilevamento delle intrusioni e di audit dei file più diffusi sono Aide e Tripwire.

Ambienti isolati

Qualsiasi metodo in cui i singoli componenti vengono eseguiti nel proprio spazio dedicato viene definito ambiente di esecuzione isolato.

Questo potrebbe significare che particolari componenti dell’applicazione saranno ospitati su server dedicati, o che i servizi potrebbero essere configurati per funzionare in ambienti chroot (o container). Il grado di isolamento dell’ambiente dipende principalmente dalla realtà della vostra infrastruttura e dai requisiti dell’applicazione.

Migliorare la sicurezza con gli ambienti isolati

Isolando i processi in singoli ambienti, si isolano anche i processi che potrebbero essere interessati da falle di sicurezza. Proprio come i compartimenti e le paratie stagne aiutano a contenere le falle nello scafo delle navi, quando si separano le singole parti e i componenti del sistema, se un intruso accede a uno di essi, non sarà in grado di raggiungere l’intero sistema di rete interconnesso.

Difficoltà di implementazione

La complessità dell'isolamento delle tue applicazioni varia a seconda dei tipi di contenimento che hai deciso di utilizzare. Docker non considera l'isolamento una funzionalità di sicurezza. Tuttavia, quando i tuoi componenti sono suddivisi tra diversi container, l'isolamento si ottiene molto più facilmente. Puoi seguire questo tutorial per installare Docker sulla nostra infrastruttura.

Anche quando vengono configurati ambienti chroot, viene offerto un certo grado di isolamento. Tuttavia, questo non è un metodo completamente impenetrabile, poiché esistono modi per evadere da un simile ambiente. Le macchine dedicate per i vari componenti sono in genere il modo migliore e più semplice per ottenere l'isolamento. Tuttavia, è più costoso a causa della necessità di macchine aggiuntive.

Considerazioni finali

Le strategie fornite sono solo alcune delle misure che puoi adottare per aumentare la sicurezza del tuo sistema. Vale la pena notare che più a lungo si aspetta a implementare le funzionalità di sicurezza, minore diventa la loro efficacia. Con questo in mente, è importante assicurarsi che la sicurezza non sia qualcosa da rimandare. Al contrario, dovrebbe essere implementata come uno dei primi provvedimenti nella creazione dell’infrastruttura. Una volta che il tuo sistema è sufficientemente sicuro con le protezioni di base, puoi iniziare ad attivare i servizi e ad aggiungere applicazioni, sapendo che verranno eseguite per impostazione predefinita in un ambiente sicuro.

La sicurezza non è tuttavia un processo statico, bensì fluido. Deve essere mantenuta e aggiornata costantemente. Dovrebbe essere affrontata con una mentalità di costante consapevolezza e continua vigilanza. Chiediti sempre quali siano le implicazioni di sicurezza coinvolte in qualsiasi modifica del sistema.  Assicurati che gli ambienti operativi e le configurazioni predefinite ottimizzino sempre la sicurezza e funzionino con software sufficientemente difensivi.

Buon computing!