WEBVTT 00:00.150 --> 00:01.770 -: De nieuwste vorm van virtualisatie 00:01.770 --> 00:03.540 die steeds populairder wordt in onze netwerken 00:03.540 --> 00:05.790 staat bekend als containergebaseerde virtualisatie, 00:05.790 --> 00:07.980 ook wel bekend als containerisatie. 00:07.980 --> 00:10.290 Dit type virtualisatie is echter veel meer 00:10.290 --> 00:12.780 gericht op servers dan op de eindgebruiker. 00:12.780 --> 00:14.460 Bij dit type virtualisatie wordt de 00:14.460 --> 00:16.440 kernel van het besturingssysteem gedeeld 00:16.440 --> 00:19.440 door meerdere virtuele machines, maar wordt de gebruikersruimte 00:19.440 --> 00:22.740 voor elke virtuele machine uniek gemaakt en beheerd. 00:22.740 --> 00:25.020 Containerisatie is een vorm van virtualisatie 00:25.020 --> 00:27.900 die wordt toegepast door een hostbesturingssysteem om een 00:27.900 --> 00:31.230 geïsoleerde uitvoeringsomgeving te bieden voor een applicatie. 00:31.230 --> 00:33.390 Containerisatie wordt als redelijk veilig beschouwd 00:33.390 --> 00:35.370 omdat het resource segmentatie en scheiding 00:35.370 --> 00:38.280 afdwingt op het niveau van het besturingssysteem. 00:38.280 --> 00:40.290 Nu wordt containerisatie vaak gebruikt 00:40.290 --> 00:42.210 met Linux-servers en enkele voorbeelden 00:42.210 --> 00:43.950 van deze op containers gebaseerde 00:43.950 --> 00:46.980 virtualisatie zijn Docker, Parallels Virtuozzo en het 00:46.980 --> 00:48.960 OpenVZ-project. 00:48.960 --> 00:51.870 Hoe ziet containerisatie er nu echt uit? 00:51.870 --> 00:53.610 Nou, je hebt een stuk hardware 00:53.610 --> 00:56.460 en bovenop die hardware heb je een Host OS, meestal 00:56.460 --> 00:59.430 Linux, en dan heb je een container manager. 00:59.430 --> 01:02.820 Iets als Kubernetes of Docker of iets dergelijks. 01:02.820 --> 01:05.100 Deze container manager gaat nu gebruikt worden om verschillende 01:05.100 --> 01:08.070 containers aan te maken die verschillende applicaties bevatten. 01:08.070 --> 01:10.290 In dit geval heb ik drie containers. 01:10.290 --> 01:12.000 Ik heb de eerste omgeving, die gebaseerd 01:12.000 --> 01:14.340 is op de kernel van het host OS, in dit voorbeeld een 01:14.340 --> 01:16.170 Linux systeem dat gebruikt wordt. 01:16.170 --> 01:18.720 En dus hebben we container één waarop Linnux draait 01:18.720 --> 01:20.700 en die bevat enkele applicaties. 01:20.700 --> 01:23.130 Nu kan container twee hetzelfde doen 01:23.130 --> 01:25.290 en container drie hetzelfde. 01:25.290 --> 01:27.210 Aangezien alle drie de containers dezelfde bestanden 01:27.210 --> 01:28.980 van het host-besturingssysteem delen. 01:28.980 --> 01:30.750 Dit neemt veel minder middelen in beslag 01:30.750 --> 01:33.690 dan pure virtualisatie met behulp van virtuele machines. 01:33.690 --> 01:35.730 Zoals we hebben besproken met virtualisatie. 01:35.730 --> 01:38.340 Als we in plaats daarvan individuele virtuele machines zouden gebruiken, zou 01:38.340 --> 01:40.860 elke machine zijn eigen kopie van een besturingssysteem nodig hebben. 01:40.860 --> 01:43.740 En dat kan 8 tot 10 gigabyte per stuk zijn. 01:43.740 --> 01:45.000 Maar met containers kunnen we 01:45.000 --> 01:47.280 allemaal hetzelfde besturingssysteem delen. 01:47.280 --> 01:50.250 Containerisatie gebruikt dus veel minder opslagruimte 01:50.250 --> 01:52.260 en vergt veel minder rekenkracht. 01:52.260 --> 01:55.050 Dit is het echte voordeel van het gebruik van zoiets als een container 01:55.050 --> 01:56.970 vanuit een operationeel perspectief. 01:56.970 --> 01:59.970 Omdat deze containers logisch geïsoleerd zijn. 01:59.970 --> 02:02.100 Ze kunnen niet echt met elkaar communiceren. 02:02.100 --> 02:04.080 Als ik twee containers met elkaar wil laten praten, 02:04.080 --> 02:06.480 moet ik ze verbinden via een virtueel netwerk en de juiste routing 02:06.480 --> 02:07.890 en switching uitvoeren om ze met elkaar 02:07.890 --> 02:09.330 te laten praten. 02:09.330 --> 02:11.970 Ze kunnen standaard niet met elkaar praten en dat 02:11.970 --> 02:14.310 is vanuit beveiligingsoogpunt geweldig, 02:14.310 --> 02:16.410 omdat we deze segmentatie hebben. 02:16.410 --> 02:18.810 Hier is je grote waarschuwing als het gaat om het 02:18.810 --> 02:20.010 omgaan met containers. 02:20.010 --> 02:22.890 Als een aanvaller het host-besturingssysteem compromitteert 02:22.890 --> 02:24.990 onder bijvoorbeeld dat Linux-besturingssysteem 02:24.990 --> 02:27.960 waar ik het net over had, raad eens wat er dan gebeurt? 02:27.960 --> 02:30.810 Nou, deze aanval heeft nu toegang tot alle containers in hun 02:30.810 --> 02:33.270 gegevens, omdat dat ene besturingssysteem wordt gebruikt 02:33.270 --> 02:35.790 door alle containers die worden gehost. 02:35.790 --> 02:37.440 Dit is een van de grootste kwetsbaarheden 02:37.440 --> 02:38.820 wanneer je containers gebruikt. 02:38.820 --> 02:40.470 Ik kan een containersysteem hebben waarop 02:40.470 --> 02:42.240 nu 50 verschillende servers draaien. 02:42.240 --> 02:43.980 En elk van deze draait verschillende servers 02:43.980 --> 02:46.230 en services met behulp van containerisatie. 02:46.230 --> 02:49.050 Maar als iemand toegang kan krijgen tot die ene server 02:49.050 --> 02:52.020 onder dat Linux besturingssysteem, heeft hij nu toegang 02:52.020 --> 02:55.290 tot alle 50 van die gehoste servers en al hun gegevens. 02:55.290 --> 02:57.480 Een ander risico waar je rekening mee moet houden is 02:57.480 --> 03:00.390 hoe je containers en andere virtuele machines gehost gaan worden. 03:00.390 --> 03:03.210 Zodra we gaan vertrouwen op virtualisatie en cloud computing, 03:03.210 --> 03:05.040 wordt het heel belangrijk om te beseffen dat 03:05.040 --> 03:07.680 onze gegevens op dezelfde fysieke server kunnen staan als de 03:07.680 --> 03:09.660 gegevens van een andere organisatie. 03:09.660 --> 03:12.120 Hierdoor introduceren we enkele kwetsbaarheden in 03:12.120 --> 03:13.920 de beveiliging van onze systemen. 03:13.920 --> 03:16.950 Ten eerste, als de fysieke server crasht door iets wat een van 03:16.950 --> 03:18.960 de andere organisaties aan het doen is, kan 03:18.960 --> 03:19.880 dit gevolgen hebben 03:19.880 --> 03:22.500 voor alle organisaties op diezelfde server. 03:22.500 --> 03:24.960 Op dezelfde manier, als één organisatie de beveiliging 03:24.960 --> 03:26.760 van hun virtuele omgevingen niet op orde 03:26.760 --> 03:28.740 heeft, omdat ze worden gehost op die fysieke 03:28.740 --> 03:31.470 server, bestaat de mogelijkheid dat een aanvaller daar gebruik 03:31.470 --> 03:33.900 van maakt ten nadele van alle andere organisaties die 03:33.900 --> 03:35.880 op diezelfde server worden gehost. 03:35.880 --> 03:38.220 Net zoals er zorgen zijn bij het verbinden van onze netwerken 03:38.220 --> 03:40.170 met die van iemand anders, zijn er ook zorgen bij 03:40.170 --> 03:42.210 het hosten van gegevens van meerdere organisaties 03:42.210 --> 03:44.010 op dezelfde fysieke server. 03:44.010 --> 03:46.530 Het is belangrijk dat we de gebruikerstoegang tot de virtuele 03:46.530 --> 03:48.780 machines die op die servers worden gehost goed configureren, 03:48.780 --> 03:50.820 beheren en controleren. 03:50.820 --> 03:53.850 Ook willen we ervoor zorgen dat onze virtuele machines zijn 03:53.850 --> 03:56.580 voorzien van de nieuwste patches, antivirus, animwire 03:56.580 --> 03:58.410 en toegangscontrole. 03:58.410 --> 03:59.760 Om het risico te minimaliseren 03:59.760 --> 04:02.490 dat de fysieke servers overbelast raken, is het altijd 04:02.490 --> 04:04.920 een goed idee om onze virtuele machines in te stellen 04:04.920 --> 04:08.280 met de juiste failover, redundantie en elasticiteit. 04:08.280 --> 04:09.810 Door de netwerkprestaties en de bronnen 04:09.810 --> 04:11.610 van de fysieke servers in de gaten te houden, 04:11.610 --> 04:13.500 zouden we de belasting moeten kunnen verdelen 04:13.500 --> 04:15.570 over meerdere fysieke machines in plaats van te vertrouwen 04:15.570 --> 04:17.370 op slechts één enkele. 04:17.370 --> 04:19.290 Een andere kwetsbaarheid die kan worden uitgebuit 04:19.290 --> 04:21.330 door een aanvaller is wanneer we hetzelfde type 04:21.330 --> 04:24.420 hypervisor gebruiken voor al onze virtuele machines. 04:24.420 --> 04:27.180 Dus als onze organisatie bijvoorbeeld alleen vertrouwt 04:27.180 --> 04:29.700 op de ESXi hypervisor van VMware en er wordt een 04:29.700 --> 04:32.280 nieuwe exploit gemaakt voor die hypervisor, dan 04:32.280 --> 04:35.790 kan een aanvaller dat tegen al onze systemen gebruiken. 04:35.790 --> 04:38.400 Dus als het succesvol is op één van onze servers, zullen ze het waarschijnlijk 04:38.400 --> 04:40.830 ook op de rest van onze servers proberen. 04:40.830 --> 04:43.260 En als al onze servers gebruik maken van hetzelfde 04:43.260 --> 04:46.410 platform, in dit geval VMware ESXi, kan deze kwetsbaarheid 04:46.410 --> 04:49.350 in onze hele organisatie worden uitgebuit. 04:49.350 --> 04:51.420 De uitdaging hierbij is echter dat als we 04:51.420 --> 04:53.700 meerdere hypervisor-platforms gebruiken, 04:53.700 --> 04:55.620 onze ondersteuningskosten en trainingseisen 04:55.620 --> 04:57.360 ook zullen toenemen. 04:57.360 --> 05:00.090 De meeste organisaties kiezen om deze reden wel voor één 05:00.090 --> 05:02.610 platform, maar ze nemen in ieder geval een weloverwogen 05:02.610 --> 05:04.800 risicobeslissing als ze dat doen. 05:04.800 --> 05:07.290 Om dat risico te beperken, moet de organisatie 05:07.290 --> 05:09.690 de juiste configuraties gebruiken, ervoor 05:09.690 --> 05:11.520 zorgen dat de hypervisor altijd gepatcht 05:11.520 --> 05:14.280 en up-to-date blijft en alleen toegankelijk is via 05:14.280 --> 05:16.830 een beveiligde beheerinterface. 05:16.830 --> 05:19.230 Dit zijn enkele van de dingen waar je rekening mee moet 05:19.230 --> 05:21.570 houden als je gaat uitzoeken of je je systemen gaat virtualiseren 05:21.570 --> 05:23.880 en migreren naar een on-premise of cloud-gebaseerde 05:23.880 --> 05:25.410 oplossing. 05:25.410 --> 05:27.540 Ten eerste, ga je virtualiseren? 05:27.540 --> 05:30.360 Zo ja, ga je traditionele virtuele machines gebruiken 05:30.360 --> 05:32.430 of ga je containerisatie gebruiken? 05:32.430 --> 05:34.410 Wat is hier het risico versus de beloning? 05:34.410 --> 05:35.970 Er is een evenwichtsoefening die je moet doen. 05:35.970 --> 05:37.230 Het is een zakelijke beslissing 05:37.230 --> 05:39.780 en ook een beslissing over cyberveiligheid. 05:39.780 --> 05:41.460 En dus moet je deze dingen meten en beslissen 05:41.460 --> 05:44.100 wat het beste is om te selecteren voor jouw organisatie en 05:44.100 --> 05:45.723 haar specifieke use cases.