WEBVTT

00:00.330 --> 00:01.710
Instructeur: Om de beoogde kostenbesparingen

00:01.710 --> 00:03.900
en efficiëntie te bereiken, is cloud computing

00:03.900 --> 00:06.540
sterk afhankelijk van virtualisatie.

00:06.540 --> 00:08.280
Door virtualisatie te gebruiken,

00:08.280 --> 00:10.380
kunnen nu meerdere logische servers op één

00:10.380 --> 00:12.210
fysieke server worden geplaatst.

00:12.210 --> 00:15.150
Dit vermindert op zijn beurt de fysieke hoeveelheid ruimte,

00:15.150 --> 00:18.060
stroom en koeling die nodig is in onze datacenters.

00:18.060 --> 00:20.220
Bovendien kunnen we met virtualisatie een hogere

00:20.220 --> 00:22.950
mate van beschikbaarheid bereiken door extra virtuele

00:22.950 --> 00:25.770
servers op te starten wanneer we die nodig hebben.

00:25.770 --> 00:27.870
Deze mogelijkheid om geheugen en CPU-bronnen dynamisch

00:27.870 --> 00:29.580
beschikbaar te stellen is een van de belangrijkste

00:29.580 --> 00:31.920
voordelen van cloud computing.

00:31.920 --> 00:33.690
Hoewel cloud computing veel verschillende voordelen

00:33.690 --> 00:35.670
heeft, zijn er nog steeds veel beveiligingskwesties

00:35.670 --> 00:37.680
waar we rekening mee moeten houden.

00:37.680 --> 00:39.090
De meeste van de beveiligingsproblemen

00:39.090 --> 00:40.620
die we met fysieke servers hebben,

00:40.620 --> 00:43.140
komen ook voor in de cloudomgeving.

00:43.140 --> 00:45.780
Vaak denken managers dat de overstap naar de cloud

00:45.780 --> 00:47.130
al hun problemen zal oplossen,

00:47.130 --> 00:49.260
maar dit is nooit echt het geval.

00:49.260 --> 00:52.050
Bij virtualisatie bevinden een of meer logische servers

00:52.050 --> 00:54.270
zich op een enkele fysieke server.

00:54.270 --> 00:57.240
Om dit te bereiken gebruiken we gespecialiseerde software

00:57.240 --> 00:58.890
die we een hypervisor noemen.

00:58.890 --> 01:00.870
De hypervisor regelt de verdeling

01:00.870 --> 01:03.390
van alle bronnen, zoals de processor, het geheugen

01:03.390 --> 01:05.700
en de beschikbare harde schijf.

01:05.700 --> 01:08.880
In wezen emuleert de hypervisor een fysieke machine zodat

01:08.880 --> 01:10.320
het besturingssysteem en

01:10.320 --> 01:12.360
alle toepassingen niet eens doorhebben

01:12.360 --> 01:15.060
dat ze in een virtuele omgeving werken.

01:15.060 --> 01:17.700
Nu zijn hypervisors onderverdeeld in twee categorieën,

01:17.700 --> 01:19.890
type één of bare metal hypervisors, en type

01:19.890 --> 01:22.230
twee of hosted hypervisor.

01:22.230 --> 01:23.730
Wanneer we nu bare metal versus gehoste

01:23.730 --> 01:25.710
hypervisortypes vergelijken, is het enige

01:25.710 --> 01:28.290
belangrijke verschil vanuit beveiligingsperspectief dat

01:28.290 --> 01:30.330
we er bij gehoste types voor moeten zorgen dat het

01:30.330 --> 01:31.770
onderliggende besturingssysteem

01:31.770 --> 01:34.080
ook goed beveiligd en gepatcht is.

01:34.080 --> 01:35.730
Vanuit het oogpunt van prestaties

01:35.730 --> 01:38.100
zal bare metal sneller en efficiënter zijn

01:38.100 --> 01:39.990
dan de gehoste tegenhanger.

01:39.990 --> 01:42.270
Een andere virtualisatieoptie die we hebben staat

01:42.270 --> 01:45.780
bekend als containergebaseerde virtualisatie, oftewel containerisatie.

01:45.780 --> 01:48.780
Bij dit type wordt helemaal geen hypervisor gebruikt, in plaats daarvan

01:48.780 --> 01:51.930
vertrouwt elke container op een gemeenschappelijk besturingssysteem

01:51.930 --> 01:54.270
als basis voor elk van die containers. Terwijl elke container

01:54.270 --> 01:55.620
hetzelfde onderliggende besturingssysteem

01:55.620 --> 01:57.180
deelt, kan elke container zijn eigen

01:57.180 --> 02:00.660
binaries, bibliotheken en applicaties hebben die kunnen worden aangepast aan

02:00.660 --> 02:02.820
hun behoeften.

02:02.820 --> 02:04.860
Momenteel wordt virtualisatie op basis van

02:04.860 --> 02:06.930
containers bijna uitsluitend gebruikt met

02:06.930 --> 02:09.120
Linux als onderliggend besturingssysteem.

02:09.120 --> 02:12.210
Containergebaseerde virtualisatie gebruikt ook minder bronnen

02:12.210 --> 02:14.460
dan een type één of type twee virtualisatie, omdat

02:14.460 --> 02:16.110
het geen eigen kopie van het besturingssysteem

02:16.110 --> 02:19.290
nodig heeft voor elke individuele container.

02:19.290 --> 02:21.960
Veel cloudserviceproviders zijn nog een stap verder gegaan

02:21.960 --> 02:25.110
met virtualisatie door middel van hyperconverged infrastructuur.

02:25.110 --> 02:27.000
Hierdoor kan de provider de opslag, netwerken

02:27.000 --> 02:29.160
en servers volledig integreren, zonder dat

02:29.160 --> 02:31.410
er hardwarewijzigingen nodig zijn.

02:31.410 --> 02:33.300
In plaats daarvan vertrouwen ze op software

02:33.300 --> 02:34.860
en virtualisatietechnologie om

02:34.860 --> 02:36.750
alle integraties uit te voeren.

02:36.750 --> 02:38.940
We kunnen dit alles beheren vanuit een enkele interface

02:38.940 --> 02:40.710
of een apparaat zonder ons zorgen te hoeven maken

02:40.710 --> 02:43.110
over alle onderliggende oplossingen van leveranciers.

02:43.110 --> 02:45.330
Applicatievirtualisatie is een ander type virtualisatie

02:45.330 --> 02:47.040
dat vaak wordt gebruikt om extra beveiliging

02:47.040 --> 02:50.040
te creëren voor onze onderliggende host.

02:50.040 --> 02:52.920
Applicatievirtualisatie is een softwaretechnologie die computerprogramma's

02:52.920 --> 02:56.130
loskoppelt van het onderliggende besturingssysteem waarop ze worden

02:56.130 --> 02:58.050
uitgevoerd.

02:58.050 --> 02:59.790
Een volledig gevirtualiseerde applicatie

02:59.790 --> 03:02.130
wordt niet eens geïnstalleerd in de traditionele zin van het

03:02.130 --> 03:04.890
woord, hoewel het nog steeds wordt uitgevoerd alsof dat wel zo is.

03:04.890 --> 03:06.690
Met applicatievirtualisatie kun je legacy

03:06.690 --> 03:08.940
applicaties draaien die zijn ontworpen voor een besturingssysteem

03:08.940 --> 03:11.490
dat het einde van zijn levensduur heeft bereikt, zoals Windows

03:11.490 --> 03:14.670
XP of Windows 7, bovenop een moderner besturingssysteem, of je kunt zelfs

03:14.670 --> 03:17.430
cross-platform software draaien, zoals Android applicaties

03:17.430 --> 03:20.280
op een Windows machine.

03:20.280 --> 03:22.680
Veel cloudproviders bieden ook VDI, of virtuele

03:22.680 --> 03:24.840
desktopinfrastructuur.

03:24.840 --> 03:27.480
Met VDI kan een cloudprovider nu een volledig desktopbesturingssysteem

03:27.480 --> 03:29.880
aanbieden aan je eindgebruikers vanaf een gecentraliseerde

03:29.880 --> 03:31.530
server.

03:31.530 --> 03:34.200
Het gebruik van deze aanpak heeft veel veiligheidsvoordelen.

03:34.200 --> 03:36.390
Ik werkte bijvoorbeeld met een organisatie

03:36.390 --> 03:39.240
die voor elke gebruiker een nieuwe virtuele desktopimage

03:39.240 --> 03:41.610
aanmaakte als ze 's ochtends inlogden.

03:41.610 --> 03:43.590
Deze desktop was niet persistent, dus zelfs

03:43.590 --> 03:46.170
als hij werd misbruikt door een aanvaller, werd hij vernietigd

03:46.170 --> 03:48.300
zodra de gebruiker uitlogde, of elke dag om middernacht.

03:48.300 --> 03:50.160
Dit vernietigde effectief de mogelijkheid

03:50.160 --> 03:52.470
van de aanvaller om persistent te blijven op de desktop

03:52.470 --> 03:56.880
van die eindgebruiker, zelfs als er malware was geïnstalleerd.

03:56.880 --> 04:00.240
Een ander goed gebruik van virtualisatie is het creëren van een sandbox.

04:00.240 --> 04:01.680
Met een sandbox kun je een geïsoleerde

04:01.680 --> 04:04.410
omgeving creëren waarin je virussen, wormen, Trojaanse

04:04.410 --> 04:07.170
paarden en andere malware kunt analyseren binnen een

04:07.170 --> 04:09.630
gastbesturingssysteem.

04:09.630 --> 04:11.580
Nu, omdat het in deze virtuele zandbak zit

04:11.580 --> 04:14.400
die zich in een geïsoleerde virtuele machine bevindt, kun

04:14.400 --> 04:16.830
je ervoor zorgen dat je je eigen computer die het host

04:16.830 --> 04:20.130
als het onderliggende host besturingssysteem of de onderliggende

04:20.130 --> 04:22.260
hypervisor niet kunt infecteren.

04:22.260 --> 04:24.120
Als je werkt als cyberbeveiligingsanalist

04:24.120 --> 04:27.240
zul je vaak sandboxes gebruiken om malwareanalyses uit te voeren,

04:27.240 --> 04:29.670
vooral als je dynamische malwareanalyses uitvoert

04:29.670 --> 04:31.680
waarbij je een stuk malware neemt, het uitvoert

04:31.680 --> 04:34.980
en vervolgens identificeert wat er gebeurt als die malware draait op

04:34.980 --> 04:37.710
dat specifieke gastbesturingssysteem.

04:37.710 --> 04:39.540
Een ander goed gebruik van virtuele

04:39.540 --> 04:42.030
machines is cross-platform virtualisatie.

04:42.030 --> 04:45.870
Ik gebruik bijvoorbeeld een MacBook Pro als mijn primaire machine.

04:45.870 --> 04:48.450
Dus als ik software applicaties wil testen voor

04:48.450 --> 04:50.040
verschillende besturingssystemen,

04:50.040 --> 04:52.080
dan kan ik voor elk besturingssysteem

04:52.080 --> 04:53.730
een nieuwe machine pakken, zoals

04:53.730 --> 04:55.590
een laptop voor Windows, een laptop

04:55.590 --> 04:58.560
voor Linux en een laptop voor Mac.

04:58.560 --> 05:00.450
Maar als ik virtualisatie gebruik,

05:00.450 --> 05:03.090
kan ik in plaats daarvan platformonafhankelijke

05:03.090 --> 05:06.120
virtualisatie toepassen door een gehost systeem op mijn

05:06.120 --> 05:08.100
MacBook Pro te gebruiken met software

05:08.100 --> 05:12.300
zoals VMware, Parallels of VirtualBox om die gastbesturingssystemen bovenop

05:12.300 --> 05:15.510
mijn bestaande Mac OS-omgeving te installeren.

05:15.510 --> 05:17.040
Hierdoor kan ik alle stukjes software

05:17.040 --> 05:18.990
testen, ongeacht het besturingssysteem

05:18.990 --> 05:20.520
dat ze nodig hebben, en zien hoe

05:20.520 --> 05:22.320
ze op elkaar inwerken.

05:22.320 --> 05:24.360
Dit is vooral geweldig voor webontwikkelaars,

05:24.360 --> 05:26.220
want als webontwikkelaar wil ik er

05:26.220 --> 05:28.980
zeker van zijn dat mijn website werkt op Windows 10,

05:28.980 --> 05:32.940
Windows 11, Mac, een Chromebook, een iPhone, een Android-apparaat of wat

05:32.940 --> 05:34.980
dan ook, en als je dat allemaal kunt testen

05:34.980 --> 05:36.420
op één machine door virtualisatie

05:36.420 --> 05:38.790
te gebruiken, is dat een geweldige bron voor

05:38.790 --> 05:41.670
ons als ontwikkelaars.

05:41.670 --> 05:44.430
Een andere geweldige toepassing van virtualisatie is training.

05:44.430 --> 05:46.440
Je kunt labomgevingen maken die zo zijn

05:46.440 --> 05:47.940
opgezet dat mensen met deze virtuele

05:47.940 --> 05:51.600
machines kunnen oefenen op een live besturingssysteem.

05:51.600 --> 05:53.220
Als je bijvoorbeeld studeert voor je

05:53.220 --> 05:55.470
verschillende CompTIA-certificeringen en je koopt

05:55.470 --> 05:57.900
je cursus diontraining. com komen met

05:57.900 --> 06:00.480
ingebouwde hands-on labs.

06:00.480 --> 06:03.390
Met deze labs kun je inloggen op onze cloud-gebaseerde

06:03.390 --> 06:06.060
omgeving en dan op een veilige manier acties uitvoeren

06:06.060 --> 06:08.700
op Linux-systemen, Windows 10-systemen, Windows

06:08.700 --> 06:11.520
Server-systemen en andere dingen, en dit heeft geen

06:11.520 --> 06:13.620
invloed op onze productieomgeving omdat

06:13.620 --> 06:16.440
het allemaal geïsoleerd is in dit trainingsgebied,

06:16.440 --> 06:18.900
of deze trainingszandbak.

06:18.900 --> 06:20.850
Een ander voordeel van het gebruik van virtuele

06:20.850 --> 06:22.590
machines voor een training of labomgeving

06:22.590 --> 06:24.930
is dat je op verschillende punten snapshots kunt maken

06:24.930 --> 06:28.110
en dan weer verder kunt gaan waar je die snapshot had.

06:28.110 --> 06:31.200
Toen ik mijn cursussen persoonlijk gaf, maakte ik bijvoorbeeld

06:31.200 --> 06:34.320
kapotte machines met Windows 7 en had ik verschillende problemen

06:34.320 --> 06:35.640
voor mijn A+ studenten om

06:35.640 --> 06:38.040
problemen op te lossen.

06:38.040 --> 06:40.260
Ik zou ze de virtuele machine geven, ik zou hem aanzetten,

06:40.260 --> 06:42.210
ik zou herstellen vanaf het laatste veilige punt,

06:42.210 --> 06:43.470
dat was waar ik hem kapot had gemaakt,

06:43.470 --> 06:44.880
en dan zou ik ze laten proberen uit te zoeken

06:44.880 --> 06:47.220
wat er mis mee was en hoe ze het konden repareren.

06:47.220 --> 06:49.290
Dit is een goed gebruik van virtuele machines

06:49.290 --> 06:50.430
in je training.

06:50.430 --> 06:52.770
En als je verder studeert en begint te leren over

06:52.770 --> 06:55.290
Linux, Windows, serveromgevingen, Mac OS en andere

06:55.290 --> 06:57.720
dingen zoals dat, kun je verschillende virtuele

06:57.720 --> 07:01.350
machines opstarten die deze gastbesturingssystemen bevatten en je

07:01.350 --> 07:04.680
vaardigheden oefenen in een veilige omgeving.

07:04.680 --> 07:05.970
Het laatste dat we moeten

07:05.970 --> 07:07.710
bespreken is het concept van emulatie,

07:07.710 --> 07:11.220
omdat veel mensen emulatie verwarren met virtualisatie.

07:11.220 --> 07:13.350
Emulatie houdt in dat je een systeem gebruikt

07:13.350 --> 07:15.330
dat een ander systeem imiteert.

07:15.330 --> 07:17.580
Met virtualisatie wordt een virtuele instantie

07:17.580 --> 07:20.580
van een bepaald stuk hardware gemaakt en gebruikt.

07:20.580 --> 07:23.460
Dus in werkelijkheid gebruik je een nieuwe fysieke machine die

07:23.460 --> 07:25.440
wordt gerepresenteerd door software.

07:25.440 --> 07:27.570
Maar met een emulator vertaalt een stuk

07:27.570 --> 07:29.910
software de omgeving in realtime om te doen

07:29.910 --> 07:31.920
alsof het iets anders is.

07:31.920 --> 07:33.780
Als ik bijvoorbeeld een oud Super

07:33.780 --> 07:36.000
Nintendo-spel op mijn MacBook Pro wil spelen,

07:36.000 --> 07:39.510
kan ik een Super Nintendo-emulator zoals OpenEmu downloaden,

07:39.510 --> 07:41.580
die de spelcode in realtime vertaalt

07:41.580 --> 07:44.970
naar instructies die mijn Mac kan begrijpen.

07:44.970 --> 07:47.070
Met virtualisatie heeft de software die wordt uitgevoerd

07:47.070 --> 07:49.560
fysiek toegang tot de hardware van je machine, waardoor het

07:49.560 --> 07:52.860
veel, veel sneller is dan wanneer je een emulator gebruikt.

07:52.860 --> 07:55.230
Dus wanneer wil je een emulator gebruiken

07:55.230 --> 07:56.970
in plaats van virtualisatie?

07:56.970 --> 07:58.830
Als je een besturingssysteem wilt gebruiken

07:58.830 --> 08:00.750
dat bedoeld is voor een ander type hardware,

08:00.750 --> 08:03.570
zoals een Super Nintendo op een Mac of Windows-machine, dan zul

08:03.570 --> 08:05.400
je een emulator moeten gebruiken.

08:05.400 --> 08:06.780
Als je software wilt draaien die

08:06.780 --> 08:09.090
bedoeld is voor een ander besturingssysteem, zoals

08:09.090 --> 08:11.130
een Android die is ontworpen om te draaien op een

08:11.130 --> 08:13.020
ARM-processor, maar je hebt een Intel-processor

08:13.020 --> 08:14.550
en een Windows-besturingssysteem,

08:14.550 --> 08:17.550
dan zijn emulators weer de juiste keuze voor jou omdat je te maken hebt

08:17.550 --> 08:20.190
met andere onderliggende hardware.

08:20.190 --> 08:22.080
Aan de andere kant, als je hoge snelheid en betere

08:22.080 --> 08:23.250
prestaties nodig hebt, wil

08:23.250 --> 08:25.590
je een virtualisatieoplossing gebruiken.

08:25.590 --> 08:27.660
Vergeet echter niet dat je met virtualisatie beperkt

08:27.660 --> 08:29.850
bent tot het draaien van software die gecodeerd is

08:29.850 --> 08:33.060
voor de specifieke onderliggende hardware van je processor.

08:33.060 --> 08:37.920
Normaal gesproken gebruiken de meesten van ons x86- of x64-gebaseerde processors,

08:37.920 --> 08:40.650
dus je draait Windows, Linux of Mac, of een van deze

08:40.650 --> 08:42.870
drie besturingssystemen op dit soort

08:42.870 --> 08:45.660
systemen met virtualisatie werkt prima.

08:45.660 --> 08:47.490
Maar als je een besturingssysteem probeert te

08:47.490 --> 08:49.050
draaien dat is ontworpen voor een ARM-processor,

08:49.050 --> 08:51.000
dan werkt dat niet met virtualisatie, dan moet je

08:51.000 --> 08:52.620
een emulator gebruiken.

08:52.620 --> 08:55.110
Over het algemeen zul je virtualisatie gebruiken

08:55.110 --> 08:57.120
in plaats van een emulator, omdat het

08:57.120 --> 08:58.800
sneller en efficiënter is en de

08:58.800 --> 09:00.450
meeste dingen geschreven zijn

09:00.450 --> 09:03.240
om te werken op een x86 of x64 processor.

09:03.240 --> 09:05.070
Maar nogmaals, als je iets voor een

09:05.070 --> 09:06.540
andere processor wilt draaien,

09:06.540 --> 09:08.990
dan zul je een emulator moeten gebruiken.