WEBVTT

00:00.150 --> 00:01.770
-: Il nuovo tipo di virtualizzazione

00:01.770 --> 00:03.540
che sta diventando popolare nelle nostre

00:03.540 --> 00:05.790
reti è noto come virtualizzazione basata su container,

00:05.790 --> 00:07.980
nota anche come containerizzazione.

00:07.980 --> 00:10.290
Questo tipo di virtualizzazione, però, è molto

00:10.290 --> 00:12.780
più incentrato sui server che sull'utente finale.

00:12.780 --> 00:14.460
Con questo tipo di virtualizzazione,

00:14.460 --> 00:16.440
il kernel del sistema operativo è condiviso

00:16.440 --> 00:19.440
tra più macchine virtuali, ma lo spazio utente di ogni macchina

00:19.440 --> 00:22.740
virtuale è creato e gestito in modo univoco.

00:22.740 --> 00:25.020
La containerizzazione è un tipo di virtualizzazione

00:25.020 --> 00:27.900
applicata da un sistema operativo host per fornire un ambiente

00:27.900 --> 00:31.230
di esecuzione isolato per un'applicazione.

00:31.230 --> 00:33.390
La containerizzazione è considerata abbastanza

00:33.390 --> 00:35.370
sicura perché impone la segmentazione e la

00:35.370 --> 00:38.280
separazione delle risorse a livello di sistema operativo.

00:38.280 --> 00:40.290
Ora la containerizzazione è comunemente

00:40.290 --> 00:42.210
usata con i server Linux e alcuni esempi

00:42.210 --> 00:43.950
di questa virtualizzazione basata

00:43.950 --> 00:46.980
su container includono cose come Docker, Parallels Virtuozzo

00:46.980 --> 00:48.960
e il progetto OpenVZ.

00:48.960 --> 00:51.870
Ora, come si presenta realmente la containerizzazione?

00:51.870 --> 00:53.610
Si tratta di un pezzo di hardware

00:53.610 --> 00:56.460
e di un sistema operativo host, di solito Linux,

00:56.460 --> 00:59.430
e di un gestore di container.

00:59.430 --> 01:02.820
Qualcosa come Kubernetes, Docker o simili.

01:02.820 --> 01:05.100
Ora questo gestore di contenitori verrà usato per creare

01:05.100 --> 01:08.070
diversi contenitori che contengono diverse applicazioni.

01:08.070 --> 01:10.290
In questo caso, ho tre contenitori.

01:10.290 --> 01:12.000
Ho il primo ambiente, che si basa

01:12.000 --> 01:14.340
sul kernel del sistema operativo host, in questo

01:14.340 --> 01:16.170
esempio un sistema Linux.

01:16.170 --> 01:18.720
Abbiamo quindi un contenitore che esegue Linnux

01:18.720 --> 01:20.700
e contiene alcune applicazioni.

01:20.700 --> 01:23.130
Ora il contenitore due può fare la stessa cosa e il

01:23.130 --> 01:25.290
contenitore tre può fare la stessa cosa.

01:25.290 --> 01:27.210
Poiché tutti e tre i contenitori condividono gli

01:27.210 --> 01:28.980
stessi file del sistema operativo host.

01:28.980 --> 01:30.750
Questo richiede molte meno risorse rispetto

01:30.750 --> 01:33.690
alla virtualizzazione pura con macchine virtuali.

01:33.690 --> 01:35.730
Come abbiamo detto per la virtualizzazione.

01:35.730 --> 01:38.340
Se invece utilizzassimo singole macchine virtuali, ognuna avrebbe

01:38.340 --> 01:40.860
bisogno della propria copia di un sistema operativo.

01:40.860 --> 01:43.740
E potrebbe trattarsi di 8-10 gigabyte per ciascuno di essi.

01:43.740 --> 01:45.000
Ma con i container possiamo

01:45.000 --> 01:47.280
condividere lo stesso sistema operativo.

01:47.280 --> 01:50.250
Quindi la containerizzazione utilizza una base di memoria molto inferiore

01:50.250 --> 01:52.260
e richiede molta meno potenza di elaborazione.

01:52.260 --> 01:55.050
Questo è il vero vantaggio dell'utilizzo di un container

01:55.050 --> 01:56.970
dal punto di vista operativo.

01:56.970 --> 01:59.970
Ora, poiché questi contenitori sono logicamente isolati.

01:59.970 --> 02:02.100
Non possono interfacciarsi tra loro.

02:02.100 --> 02:04.080
Se volessi far parlare due container, dovrei

02:04.080 --> 02:06.480
collegarli attraverso una rete virtuale e fare il giusto

02:06.480 --> 02:07.890
routing e switching per consentire

02:07.890 --> 02:09.330
loro di parlare.

02:09.330 --> 02:11.970
Per impostazione predefinita, non hanno modo di parlare tra di loro

02:11.970 --> 02:14.310
e questo è un ottimo aspetto dal punto di vista della sicurezza,

02:14.310 --> 02:16.410
perché abbiamo questa segmentazione.

02:16.410 --> 02:18.810
Ecco il grande avvertimento quando si tratta di trattare

02:18.810 --> 02:20.010
i contenitori.

02:20.010 --> 02:22.890
Se un aggressore compromette il sistema operativo host,

02:22.890 --> 02:24.990
ad esempio il sistema operativo Linux di

02:24.990 --> 02:27.960
cui ho appena parlato, indovinate cosa succede?

02:27.960 --> 02:30.810
Ebbene, questo attacco ha ora accesso a tutti i container

02:30.810 --> 02:33.270
nei loro dati, perché quell'unico sistema operativo

02:33.270 --> 02:35.790
è utilizzato da tutti i container ospitati.

02:35.790 --> 02:37.440
Questa è una delle maggiori vulnerabilità

02:37.440 --> 02:38.820
quando si utilizzano i container.

02:38.820 --> 02:40.470
Posso avere un sistema di container che esegue

02:40.470 --> 02:42.240
50 server diversi in questo momento.

02:42.240 --> 02:43.980
Ognuno di essi esegue server e servizi

02:43.980 --> 02:46.230
diversi utilizzando la containerizzazione.

02:46.230 --> 02:49.050
Ma se qualcuno è in grado di accedere a quell'unico

02:49.050 --> 02:52.020
server sotto il sistema operativo Linux, ora ha accesso

02:52.020 --> 02:55.290
a tutti i 50 server ospitati e a tutti i loro dati.

02:55.290 --> 02:57.480
Un altro rischio da considerare è il modo in cui i container

02:57.480 --> 03:00.390
e le altre macchine virtuali saranno effettivamente ospitati.

03:00.390 --> 03:03.210
Quando si inizia a fare affidamento sulla virtualizzazione e sul cloud

03:03.210 --> 03:05.040
computing, diventa molto importante riconoscere

03:05.040 --> 03:07.680
che i nostri dati potrebbero essere ospitati sullo stesso server fisico

03:07.680 --> 03:09.660
dei dati di un'altra organizzazione.

03:09.660 --> 03:12.120
Così facendo, introduciamo alcune vulnerabilità

03:12.120 --> 03:13.920
nella sicurezza dei nostri sistemi.

03:13.920 --> 03:16.950
In primo luogo, se il server fisico si blocca a causa di un'azione

03:16.950 --> 03:18.960
di una delle altre organizzazioni, ciò può

03:18.960 --> 03:19.880
influire su tutte le

03:19.880 --> 03:22.500
organizzazioni che si trovano sullo stesso server.

03:22.500 --> 03:24.960
Allo stesso modo, se un'organizzazione non mantiene

03:24.960 --> 03:26.760
la sicurezza dei propri ambienti virtuali,

03:26.760 --> 03:28.740
ospitati su quel server fisico, c'è la possibilità

03:28.740 --> 03:31.470
che un aggressore possa utilizzarli a danno di tutte le

03:31.470 --> 03:33.900
altre organizzazioni ospitate su quello stesso

03:33.900 --> 03:35.880
server.

03:35.880 --> 03:38.220
Così come ci sono preoccupazioni quando si interconnettono

03:38.220 --> 03:40.170
le nostre reti con quelle di altri, ce ne sono anche

03:40.170 --> 03:42.210
quando si ospitano i dati di più organizzazioni

03:42.210 --> 03:44.010
sullo stesso server fisico.

03:44.010 --> 03:46.530
È importante per noi configurare, gestire e verificare

03:46.530 --> 03:48.780
correttamente l'accesso degli utenti alle macchine

03:48.780 --> 03:50.820
virtuali ospitate su questi server.

03:50.820 --> 03:53.850
Inoltre, vogliamo assicurarci che le nostre macchine virtuali

03:53.850 --> 03:56.580
abbiano le patch più recenti, l'antivirus, l'animwire

03:56.580 --> 03:58.410
e il controllo degli accessi.

03:58.410 --> 03:59.760
Per ridurre al minimo il rischio

03:59.760 --> 04:02.490
di sovraccarico delle risorse dei server fisici, è sempre

04:02.490 --> 04:04.920
una buona idea impostare le macchine virtuali

04:04.920 --> 04:08.280
con failover, ridondanza ed elasticità adeguati.

04:08.280 --> 04:09.810
Monitorando le prestazioni della

04:09.810 --> 04:11.610
rete e le risorse dei server fisici,

04:11.610 --> 04:13.500
dovremmo essere in grado di bilanciare

04:13.500 --> 04:15.570
il carico su più macchine fisiche invece

04:15.570 --> 04:17.370
di affidarci a una sola.

04:17.370 --> 04:19.290
Un'altra vulnerabilità che potrebbe essere

04:19.290 --> 04:21.330
sfruttata da un aggressore è quando si utilizza

04:21.330 --> 04:24.420
lo stesso tipo di hypervisor per tutte le macchine virtuali.

04:24.420 --> 04:27.180
Ad esempio, se la nostra organizzazione si affida esclusivamente

04:27.180 --> 04:29.700
all'hypervisor ESXi di VMware e viene creato un nuovo

04:29.700 --> 04:32.280
exploit per quell'hypervisor, un aggressore potrebbe

04:32.280 --> 04:35.790
utilizzarlo contro tutti i nostri sistemi.

04:35.790 --> 04:38.400
Quindi, se ha successo su uno dei nostri server, è probabile

04:38.400 --> 04:40.830
che lo proveranno sugli altri server.

04:40.830 --> 04:43.260
E se tutti i nostri server utilizzano la stessa piattaforma,

04:43.260 --> 04:46.410
in questo caso ESXi di VMware, questa vulnerabilità potrebbe essere

04:46.410 --> 04:49.350
sfruttata in tutta la nostra organizzazione.

04:49.350 --> 04:51.420
Il problema, tuttavia, è che se utilizziamo

04:51.420 --> 04:53.700
più piattaforme hypervisor, i costi di

04:53.700 --> 04:55.620
supporto e i requisiti di formazione

04:55.620 --> 04:57.360
aumenteranno.

04:57.360 --> 05:00.090
Per questo motivo, la maggior parte delle organizzazioni sceglie

05:00.090 --> 05:02.610
di utilizzare un'unica piattaforma, ma per lo meno prende

05:02.610 --> 05:04.800
una decisione di rischio misurata.

05:04.800 --> 05:07.290
Per ridurre questo rischio, l'organizzazione deve utilizzare

05:07.290 --> 05:09.690
configurazioni corrette, assicurarsi che l'hypervisor sia

05:09.690 --> 05:11.520
sempre patchato e aggiornato e che sia accessibile

05:11.520 --> 05:14.280
solo attraverso un'interfaccia di gestione sicura, oltre a controllare

05:14.280 --> 05:16.830
strettamente il controllo degli accessi.

05:16.830 --> 05:19.230
Questi sono alcuni degli aspetti da tenere in considerazione

05:19.230 --> 05:21.570
quando si decide di virtualizzare i sistemi e migrarli

05:21.570 --> 05:25.410
verso una soluzione on-premise o basata sul cloud.

05:25.410 --> 05:27.540
Innanzitutto, avete intenzione di virtualizzare?

05:27.540 --> 05:30.360
In tal caso, utilizzerete macchine virtuali tradizionali

05:30.360 --> 05:32.430
o la containerizzazione?

05:32.430 --> 05:34.410
Qual è il rapporto tra rischio e ricompensa?

05:34.410 --> 05:35.970
È necessario trovare un equilibrio.

05:35.970 --> 05:37.230
È una decisione aziendale

05:37.230 --> 05:39.780
e anche una decisione di sicurezza informatica.

05:39.780 --> 05:41.460
Dovrete quindi misurare questi aspetti

05:41.460 --> 05:44.100
e decidere cosa è meglio scegliere per la vostra organizzazione

05:44.100 --> 05:45.723
e per i suoi casi d'uso specifici.