IT infrastrucuur HOOFDSTUK 3 VIRTUALISATIE EN CLOUDCOMPUTING .pdf

3 Virtualisatie en cloud computing ....................................................................................... 1 3.1 Inleiding ..................................................................................................................... 1 3.2 Computevirtualisatie ...............

3 Virtualisatie en cloud computing ....................................................................................... 1 3.1 Inleiding ..................................................................................................................... 1 3.2 Computevirtualisatie .................................................................................................. 1 3.2.1 Software Defined Compute (SDC)..................................................................... 2 3.2.2 Nadelen van het virtualiseren van compute ....................................................... 3 3.2.3 Gebruikte technologie voor virtualisatie van compute....................................... 4 3.3 Beschikbaarheid van gevirtualiseerde compute ......................................................... 6 3.4 Desktopvirtualisatie .................................................................................................... 7 3.4.1 Applicatievirtualisatie ........................................................................................ 7 3.4.2 Server Based Computing (SBC) ........................................................................ 8 3.4.3 Virtual Desktop Infrastructure (VDI) ................................................................. 9 3.4.4 Thin-clients....................................................................................................... 10 3.4.5 PXE boot .......................................................................................................... 10 3.5 Netwerkvirtualisatie ................................................................................................. 10 3.5.1 VPN (Virtual Private Network)........................................................................ 10 3.5.2 Virtual NICs ..................................................................................................... 11 3.5.3 Virtual Switch .................................................................................................. 11 3.5.4 Virtual LAN (VLAN)....................................................................................... 11 3.5.5 Software defined networking ........................................................................... 12 3.5.6 Virtualisatie van netwerkfunctionaliteiten. ...................................................... 12 3.6 Data(bank)virtualisatie ............................................................................................. 12 3.6.1 Datavirtualisatie................................................................................................ 12 3.6.2 Databankvirtualisatie ........................................................................................ 13 3.7 Cloud computing ...................................................................................................... 13 3.7.1 Belangrijkste eigenschappen van cloud computing: ........................................ 13 3.7.2 Cloud deplyment modellen : ............................................................................ 14 3.8 Clouddiensten volgens de beheerder ........................................................................ 16 3.9 Belangrijkste voor- en nadelen van cloud computing .............................................. 17 3.9.1 Voordelen van cloud computing ...................................................................... 17 3.9.2 Belangrijkste nadelen van cloud-computing .................................................... 19 3 Virtualisatie en cloud computing 3.1 Inleiding Door gebruikt te maken van virtualisatie kan men bouwstenen van IT-infrastructuur er anders laten uitzien dan ze eigenlijk fysiek zijn. Op die manier kan men heel veel (tijdelijke) problemen rond IT-infrastructuur oplossen en/of beheersbaar maken. Stel dat een laptop niet voldoende geheugen heeft, en dat de eindgebruiker toch een extra applicatie wil opstarten, dan kan geheugenvirtualisatie een oplossing bieden. Stel dat een server in een datacentrum plots nood heeft aan meer rekenkracht, dan kunnen andere servers binnen dat datacentrum eventueel die rekenkracht leveren dankzij virtualisatie. Virtualisatie wordt al gebruikt sinds de jaren 60 in mainframe-omgevingen. Zo kon men mainframe-computers zo configureren dat verschillende programma’s gebruik konden maken van gezamenlijke hulpbronnen, zoals geheugen. Het virtualiseren van opslag werd al besproken in Hoofdstuk 2. Daar wordt duidelijk gemaakt dat verschillende toestellen samen worden gebracht om zo alle opslag van een datacentrum proberen te ondersteunen. In dit hoofdstuk gaan we dieper in op virtualisatie van compute en virtualisatie van desktops. Deze twee technieken samen vormen de basis van cloud computing. Cloud computing kan aanzien worden als een heel disruptieve evolutie binnen ITinfrastructuur. Het 2de deel van dit hoofdstuk gaat dieper in op cloud computing. Volledigheidshalve worden datavirtualisatie besproken. ook enkele toepassingen van netwerkvirtualisatie en 3.2 Computevirtualisatie In een traditionele computerarchitectuur zal het OS de interactie aangaan met de onderliggende hardware. Virtualisatie van compute (ook gekend onder de naam servervirtualisatie of software defined compute) introduceert een abstracte laag tussen de fysieke hardware van de computer en het OS dat de hardware gebruikt. Dankzij virtualisatie is het mogelijk om verschillende OS’en tegelijk te gebruiken op 1 fysiek toestel. 1 Figuur 3-1: Architectuur van virtualisatie De virtualisatielaag heeft dus als doel om de verschillende virtuele machines (VM’s) los te koppelen van elkaar en van de onderliggende fysieke hardware. Een VM is dus een logische representatie van een fysieke computer, maar is dus eigenlijk software die ervoor zorgt dat alle noodzakelijke componenten worden samengebracht en zo de illusie geven van een zelfstandig functionerende machine. VM’s kunnen los van elkaar gestart worden (of gestopt worden). Als 1 VM crasht dan is deze volledig geïsoleerd van de andere VM’s. De andere VM’s zullen dus geen hinder ondervinden van een dergelijk falen. Dankzij virtualisatie is het mogelijk om nieuwe VM’s te voorzien indien nodig, zonder nieuwe hardware te voorzien wat veel tijd en geld kan uitsparen. Aan de hand van een paar simpele muisklikken kan een nieuwe server gemaakt worden voor een toepassing of als testomgeving. Omdat minder hardware nodig is voor de verschillende servers kan men geld sparen op koeling, stroom en hardware zelf. Maar ook de kost voor onderhoud en het risico van hardware falen neemt af. 3.2.1 Software Defined Compute (SDC) VM’s worden meestal gemanaged door gebruik te maken van een redundant gecentraliseerd VMM-systeem (Virtual Machine Management system). Dit laat systeemmanagers toe om meer systemen te beheren. Het beheren van de VM’s gebeurt via API’s. Het centraal managen van de beschikbare resources en (automatisch) optimaliseren van het gebruik van deze resources maakt het managen nog eenvoudiger. Het virtualiseren van een server wordt ook omschreven als SDC. Een SDC-architectuur ziet eruit zoals weergegeven op Figuur 3-2. De hypervisor, die op een dynamische manier rescources (CPU, geheugen, opslag en netwerkresources) toekent aan elke VM, is actief op elk fysiek toestel. Alle hypervisors worden gezamenlijk beheerd als een laag door gebruik te malen van VM-management software. Sommige virtualisatieplatformen laten het zelfs toe dat VM’s zich verplaatsen over de onderliggende fysieke toestellen, volgens de behoefte en beschikbaarheid van de benodigde 2 resources. Dit laat het toe dat onderliggende hardware kan onderhouden worden zonder de beschikbaarheid van de toepassingen in het gedrang te brengen. Figuur 3-2: Software Defined Compute (SDC) Een SDC architectuur zorgt er dus voor dat de beschikbaarheid van de verschillende servers verhoogt. Er bestaan zelfs VMM’s die het toelaten om volledige servers te locksteppen (zie 2.4.3.3 in H2) tot op het niveau van het geheugen toe. Wanneer een dergelijke server faalt, kan de andere direct over nemen, zonder enige onderbreking. Wanneer een VM wordt uigezet is dit dus eigenlijk niet meer dan een file op een hard disk (de zogenaamde virtual machine image). Dit betekent dus ook dat het vrij simpel is om een copy te maken van een VM (bv net voor een wijziging zoals het installeren van een patch). Een VM kan ook bewaard worden (het is uiteindelijk een file). Om bijvoorbeeld data van een verouderd systeem (meestal gearchiveerde data) toch nog toegankelijk te maken. 3.2.2 Nadelen van het virtualiseren van compute Er zijn natuurlijk ook enkele nadelen verbonden aan het gebruik van VM’s. Een eerste nadeel is dat het soms te eenvoudig is om een nieuwe VM te creëren. Men is geneigd om voor het minst een nieuwe VM te creëren. Dit wordt ook soms VM sprawl genoemd. Al die VM’s moeten gemanaged, gepatched, geback-upt worden .. etc. Ook de nieuwe laag die toegevoegd wordt (VMM) aan de infrastructuur dient gemanaged te worden. Er zijn licenties nodig, skills, installatie, onderhoud … etc. 3 Ook niet alle servers laten het toe om gebruik te maken van VMM. En ook voor databank servers is VM niet altijd de beste oplossing, omdat grote DB-servers soms alle resources van een dedicated server nodig hebben om te kunnen werken. Daarnaast zijn er producenten van bepaalde applicaties die geen support bieden wanneer de software draait op een VM. 3.2.3 Gebruikte technologie voor virtualisatie van compute Er wordt gebruik gemaakt van meerdere technologieën om virtualisatie van compute mogelijk te maken. 3 daarvan zijn belangrijk en worden hier verder uitgelegd. 3.2.3.1 Emulatie (Emulation) Een emulator is een vorm van software die het toelaat om een programma te draaien op een computersysteem (of OS) die eigenlijk niet ontwikkeld is voor dit systeem (of OS). Een emulator doet dit door het gedrag van de originele computer na te bootsen. De nodige processen die de software verwacht worden vertaald naar de omgeving waar de software actief is. Dergelijke vertaling wordt emulatie genoemd. Figuur 3-3: Emulator Emulatie hoeft dus niet alleen iets te zijn van servers en datacentra. Zo kan je bijvoorbeeld op je eigen laptop een emulator installeren die het toelaat om bijvoorbeeld oude 8bit games van een Commodore 64 te spelen. Omdat een emulator de CPU-instructies van een architectuur moet vertalen naar CPUinstructies van een andere architectuur is emulatie een proces dat niet gekenmerkt wordt door snelheid (bij het voorbeeld van de 8bit games is snelheid geen issue, aangezien de oude Commodore 64 aanzienlijk trager was dan eender welke laptop). Maar niet alleen de CPUinstructies moeten geëmuleerd worden. Alle andere onderliggende stukken ook (zoals toetsenbord, grafische kaart, toegang tot opslag … etc. 3.2.3.2 Hypervisors Wanneer gebruik gemaakt wordt van VM’s in datacentra, wordt meestal gebruik gemaakt van hypervisors. Zoals hierboven aangeduid is een hypervisor eigenlijk een VM-monitor en zijn 4 taak bestaat eruit om VM’s te laten werken en hun werkzaamheden te monitoren. De hypervisors controleren de hardware van de fysieke onderliggende computers en voorzien de VM’s van de nodige services om te kunnen werken. Deze bevatten virtuele BIOS, virtueel opslag, virtueel geheugen … etc. Om hypervisors te implementeren wordt gebruik gemaakt van verschillende technologieën. Volgende 2 zijn daarvan de belangrijkste: Paravirtualisatie: In tegenstelling tot volledige virtualisatie, zullen bij paravirtualisatie sommige (hardware) onderdelen niet gevirtualiseerd zijn en deze staan dus rechtstreeks ter beschikking van de software die werkt binnen de virtual machine. Dergelijke onderdelen zijn bijvoorbeeld geheugen, opslag of CPU-tijd. Dit kan alleen tot stand komen als de OS die werkt binnen de VM wel degelijk weet dat hij werkt binnen een VM. Paravirtualisatie laat toe dat de software performanter is binnen de virtual machine. In vele instanties zal de software (onder ander ook de OS) die draait binnen de VM aangepast moeten worden, wat bij volledige virtualisatie niet het geval is. Hardware assisted virtualisatie: bij hardware assisted virtualisatie zijn er instructies voorzien in de CPU die tot doel hebben om de hypervisor te helpen. Doordat de instructies voorzien zijn in de CPU zal de virtualisatie dus efficiënter gebeuren. 3.2.3.3 Virtueel-geheugen-management Hypervisors managen het geheugen van de fysische computers door het beschikbare geheugen te verdelen over de verschillende virtuele machines. Dit kan geoptimaliseerd worden door gebruik te maken van memory overcommitment en memory sharing. Memory overcomitment: De meeste OS’en eisen meer geheugen op dan dat ze echt nodig hebben. Door gebruik te maken van overcommitment kan de hypervisor meer geheugen toekennen dan dat er fysiek geheugen aanwezig is. Het toekennen van meer geheugen dan beschikbaar is eigenlijk ook een vorm van geheugenvirtualisatie die gebruikt wordt door laptops. Door gebruik te maken van opslag kan geswapt worden (zie hoofdstuk 2) tussen actief geheugen en geheugen dat tijdelijk niet gebruikt wordt. Indien een hypervisor door overcommitment geheugen te kort heeft, kan deze ook gebruik maken van het swappen van geheugen met de disk. Dit zal het systeem tijdelijk vertragen, maar uitvallen van systemen kan vermeden worden. Memory sharing: Geheugen kan ook gedeeld worden door de verschillende OS’en. Wanneer een bepaald stuk geheugen identiek is voor de verschillende OS’en kan deze door de 2 aangesproken worden (read only). Alleen wanneer men dingen wil schrijven in dit blok wordt het gekopieerd en toegekend aan die specifieke OS. Op die manier kan heel veel geheugen gespaard worden. Stel dat bijvoorbeeld verschillende VM’s gebruik maken van dezelfde versie van windows, dan zullen veel stukjes van het geheugen identiek zijn voor elke OS. Ipv die meerdere keren in een aparte cel bij te houden kan voor elke OS naar dezelfde cel gewezen worden. 5 3.3 Beschikbaarheid van gevirtualiseerde compute Alle vormen van virtualisatie voorzien een of andere vorm van failover. Als een fysieke machine faalt, dan kunnen alle VM’s die actief zijn op dit toestel zo geconfigureerd worden dat ze automatisch herstarten op een ander fysiek toestel. En als een VM crasht, kan het automatisch herstart worden op de zelfde fysieke computer waar hij actief was. Om beter om te gaan met het falen van een fysiek toestel wordt een extra fysiek toestel voorzien. Om dit goed te laten verlopen worden alle hypervisors samengebracht in een virtuele cluster, zodat ze weten van elkaars bestaan. De hypervisors van de fysieke machines kijken naar de beschikbaarheid van de andere hypervisors in de cluster. Figuur 3-4: Gebruik van een extra fysiek toestel In Figuur 3-4 zie je één extra fysiek toestel dat gebruikt wordt als reserve. Wanneer een ander fysiek toestel faalt, kan deze overnemen (Figuur 3-5). Figuur 3-5: Reactie wanneer een fysiek toestel faalt. Er is echter ook een tweede manier om dit probleem aan te pakken. Je kan op de verschillende fysieke machines een lagere capaciteit gebruiken. Stel dat je 5 servers hebt en elke machine kan 10 VM’s tegelijk draaien. Dan zou je in het voorbeeld van hierboven 40 VM’s kunnen gebruiken (4 * 10 + 1 extra server die niet gebruikt wordt). Je kan deze ook verdelen over de 5 servers en elke server maar gebruiken voor 8 VM’s (Figuur 3-6). 6 Figuur 3-6: Gedeeltelijk gebruik van alle servers Wanneer een fysiek toestel dan faalt, zou je de 8 VM’s van dat toestel kunnen herverdelen over de 4 overige beschikbare fysieke toestellen (en op die manier hun volle capaciteit gebruiken) (Figuur 3-7). Figuur 3-7: Reactie wanneer een fysiek toestel faalt in geval van gedeeltelijk gebruik van de servers. 3.4 Desktopvirtualisatie Er zijn verschillende technieken die kunnen gebruikt worden om virtualisatie in te zetten voor end user devices. 3.4.1 Applicatievirtualisatie De term applicatievirtualisatie is een beetje misleidend aangezien de applicatie zelf niet gevirtualiseerd wordt maar de OS (op het end user device) waar de applicatie op actief is. De applicatie denkt dat het zelf rechtstreeks werkt in een OS maar eigenlijk werkt het in een virtuele laag die in interactie gaat met de OS. Op deze manier kan compatibiliteit gegarandeerd worden. Applicatievirtualisatie wordt veelal gebruikt in een Windowsomgeving. 7 Figuur 3-8: Applicatievirtualisatie The virtualisatielaag (Figuur 3-8) werkt als tussenstation en zorgt voor alle systeem requests aan de OS. Er wordt echter gebruik gemaakt van één enkele file. Alle interacties met de registry en files die door de bestanden bewerkt worden wordt gedaan door de virtualisatielaag en hebben alleen invloed op deze ene file. Aangezien de OS op die manier werkt met maar 1 (‘real’) file, is het makkelijker om de applicatie te laten werken op verschillende toestellen, zelfs al zijn deze toestellen op zich niet compatibel met de applicatie. Het is tevens ook mogelijk om verschillende versies van eenzelfde applicatie tegelijk actief te hebben op een toestel. (In dat geval zijn er meerdere ‘real’ files voor dezelfde applicatie). 3.4.2 Server Based Computing (SBC) Server Based Computing, ook wel thin-client computing genoemd, is een overkoepelende term die verwijst naar de technologie waarbij applicaties geïmplementeerd zijn op een afgelegen server, in plaats van op een eindgebruikertoestel. Het toestel van de eindgebruiker, veelal een relatief zwak toestel (thin-client), krijgt een virtueel scherm te zien waarin de applicatie die op de server draait, kan gebruikt worden. De thin-client maakt gebruik van een relatief lichte applicatie (een thin-client agent) die eigenlijk alleen moet instaan voor output en input. Voor output wordt het virtuele scherm gebruikt en voor input moet hij toetsenbord aanslagen en muiskliks terugsturen naar de server. De server interpreteert de input commando’s en genereert eventueel een nieuw (virtueel) scherm dat dan door de thin-client agent wordt weergegeven aan de eindgebruiker. 8 Figuur 3-9: Server Based Computing (SBC) SBC neemt ook maar een beperkte bandbreedte van het netwerk in beslag, omdat alleen de in/out commando’s dienen verstuurd te worden. Het grootste voordeel van het gebruik van SBC is onderhoud. Door applicaties via SBC toegankelijk te maken kan men alle updates en patches op serverniveau doen en zijn deze direct actief voor alle gebruikers. In grote organisaties waar applicaties op individuele toestellen staan, is bijvoorbeeld een simpele update een hele karwei aangezien deze op elk toestel moet uitgevoerd worden. 3.4.3 Virtual Desktop Infrastructure (VDI) Virtual Desktop Infrastruture (VDI) is sterk vergelijkbaar met SBC, maar bij VDI is de applicatie actief in een eigen virtuele machine. Figuur 3-10: Virtual Destop Infrastructure (VDI) Net als bij een fysieke PC heeft elke gebruiker exclusief gebruik van een eigen OS, CPU en geheugen wanneer gebruik gemaakt wordt van VDI. Bij SBC wordt gebruik gemaakt van gemeenschappelijke resources. 9 3.4.4 Thin-clients Door gebruik te maken van VDI en SBC is het dus mogelijk om een desktop volledig te draaien op afgelegen server(s). Toestellen voor eindgebruikers gaan dus alleen in interactie met een SBC of een VDI server. In dit geval spreken we over een thin-client. Er zijn 2 soorten thin-clients: Hardware based thin-clients, zijn relatief goedkope toestellen met weinig hardware vereisten. Ze hebben geen nood aan een eigen opslag. Ze hoeven niet geconfigureerd te zijn en zijn onmiddellijk bruikbaar wanneer ze zijn ingelogd in een netwerk. Wanneer zo’n toestel stuk gaat, kan je dit zonder probleem vervangen. Medewerkers zullen gewoon kunnen doorwerken, zonder enig ongemak. Er is ook minder nodig om toestellen voor eindgebruikers op regelmatige basis te upgraden. De eventueel toegenomen vereisten aan resources door de applicatie updates worden volledig opgevangen door de server. Software based thin-clients, zijn applicaties die werken op een normale OS (zoals een windows, Max OS X, linux). Ze maken het bijvoorbeeld mogelijk om een applicatie te laten werken op een mobiel toestel dat eigenlijk bedoeld is voor een vast toestel. 3.4.5 PXE boot Het zogenaamde Preboot eXecution Environment (PXE) laat het toe dat de desktop of thinclient boot (opstart) van een OS-diskimage die wordt bijgehouden via een netwerk ipv een lokale harde schijf. Dit laat het toe om thin-clients te maken die zelf geen eigen disk hebben wat zowel de kost als onderhoud van de thin-clients nog eenvoudiger maakt. 3.5 Netwerkvirtualisatie Er zijn verschillende vormen van netwerkvirtualisatie die kunnen gebruikt worden om bepaalde IT-infrastructuur aspecten beter te beheren zoals veiliger maken of onderdelen beter beschikbaar maken. 3.5.1 VPN (Virtual Private Network) Een virtueel privaat netwerk maakt gebruik van een publiek netwerk om interactie te gaan met private sites (of netwerken) op een beveiligde manier. (Dit wordt ook aangeduid als een VPNtunnel). Figuur 3-11: VPN-tunnel 10 Een VPN-tunnel kan vrij makkelijk worden opgezet als er een internetconnectie mogelijk is. Een gebruiker buiten het netwerk van een organisatie kan een VPN-tunnel creëren tussen zijn toestel en de organisatie. Om zodoende de LAN van de organisatie (tijdelijk) uit te breiden met de nieuwe locatie. Aangezien VPN gebruik maakt van sterke encryptie en een sterke vorm van authenticatie, wordt deze techniek als veilig aanzien. 3.5.2 Virtual NICs Fysieke machines bevatten fysieke NICs (Network Interface Card). Wanneer een of meerdere VMs worden geïnstalleerd op een fysiek toestel, dan maken deze gebruik van de NIC van dit toestel. De hypervisor zou virtuele NIC’s kunnen aanmaken, zodat de communicatie tussen de verschillende VMs kan gerout worden via het geheugen (zonder gebruik te maken van de fysieke NIC). 3.5.3 Virtual Switch Net als bij virtual NICs zou de hypervisor ook een virtuele switch kunnen maken, die de netwerktrafiek tussen de verschillende VM’s kan regelen binnen het geheugen van de server. 3.5.4 Virtual LAN (VLAN) Virtual LANs (VLANs) laten het toe om logische groepen te creëren van netwerknodes binnen dezelfde LAN. VLANs worden geconfigureerd op netwerkswitches en werken op het niveau van het ethernet. De belangrijkste toepassing is het segmenteren van een netwerk zonder afhankelijk te zijn van devices op de netwerk laag (zoals routers) Figuur 3-12: 2 VLANs binnen 1 LAN VLANs hebben dezelfde fysieke LAN, maar laten het toe dat end user devices gegroepeerd worden in aparte (virtuele) subnetten. VLAN's laten bijvoorbeeld toe dat in een bedrijf logisch gescheiden netwerken bestaan voor de administratie-afdeling, de verkoopafdeling, etc., los van de fysieke inrichting van het netwerk. Dit betekent dat alle computers en andere netwerkelementen van één afdeling rechtstreeks met elkaar kunnen communiceren, maar communicatie met toestellen van een andere afdeling rechtstreeks (via Ethernet) niet mogelijk is. 11 VLANs kunnen gebruikt worden om het onderhouden en de beveiliging van netwerken te vereenvoudigen. 3.5.5 Software defined networking Software defined Networking (SDN) is een relatief nieuw concept. Door gebruik te maken van SDN is het mogelijk om een relatief simpel netwerk zo te configureren dat het zich voordoet als een complex virtueel netwerk. Het kan enorm bijdragen tot de veiligheid van een netwerk, zonder complexe netwerkdevices toe te voegen. Het is tevens ook mogelijk om een volledig andere netwerktopologie in te laden. Dit kan onder andere heel nuttig zijn voor cloudomgevingen. Omdat zowel het virtuele netwerk als de virtuele machines die verbonden zijn met dat netwerk constant kunnen veranderen. 3.5.6 Virtualisatie van netwerkfunctionaliteiten. Het virtualiseren van netwerk functionaliteiten is een manier om bepaalde netwerk devices te vritualiseren. Dit kan gaan over firewalls, VPN gateways, load balancers … etc. Je kan het bijvoorbeeld gebruiken om een virtuele firewall te plaatsen tussen verschillende VM’s in een cloudomgeving. 3.6 Data(bank)virtualisatie In hoofdstuk 2 werd al gekeken hoe opslag gevirtualiseerd kan worden en hoe men de verschillende beschikbare opslagmedia zo kan gebruiken dat prestatie en beschikbaarheid zo goed mogelijk gegarandeerd wordt. Er zijn echter nog 2 vormen van datavirtualisatie die niet aan bod kwamen 3.6.1 Datavirtualisatie Datavirtualisatie is een manier om data voor te stellen aan programma’s zodat deze niet hoeven te weten in welk formaat de data origineel is bijgehouden. Dit systeem is eigenlijk een alternatieve manier om een datawarehouse te benaderen. Een datawarehouse, datamart of data lake is een plaats waar bedrijfsdata wordt samengebracht in nieuwe standaarden die door programma’s kunnen geïnterpreteerd worden. Om een datawarehouse te laten ontstaan maakt men gebruik van de ETL-methode: “Extract” data van de verschillende databases, “Transformeer” de data naar het formaat van de datawarehouse en “Load” deze data in de warehouse. Daarna is de data inzetbaar in andere systemen. Datavirtualisatie is gebaseerd op hetzelfde principe maar zonder een datawarehouse als tussenmedium te creëren. Alle nodige data wordt virtueel voorgesteld in een formaat dat bruikbaar is voor de applicatie. Zonder dat de applicatie hoeft te weten wat de originele formaten van de data zijn of waar die worden bijgehouden. 12 3.6.2 Databankvirtualisatie Datavirtualisatie kan aanzien worden als een onderdeel van databankvirtualisatie. Bij databankvirtualisatie gaat het niet alleen over de data, maar ook over bijvoorbeeld een pool aan rekenkracht die bijvoorbeeld kan aangewend worden bij het berekenen van een complexe query. Het gaat dus niet alleen over de data, maar over alle hulpmiddelen die nodig zijn voor een correcte werking van de database. 3.7 Cloud computing ‘Cloud-computing’ is eigenlijk de verzamelnaam voor alle diensten die het mogelijk maken om IT-infrastructuur (eventueel van derden) via netwerken toegankelijk te maken voor organisaties. Figuur 3-13: Cloud computing 3.7.1 Belangrijkste eigenschappen van cloud computing: Omdat cloudcomputing gebaseerd is op virtualisatie en deze via het internet toegankelijk maakt kan men stellen dat men beschikt over enkele specifieke eigenschappen die cloud-computing een heel interessante IT-infrastructuur oplossing maken. § On-demand self-service Gebruikers van clouddiensten kunnen zelf diensten (self-service) aanvragen (ondemand), verkrijgen, configureren en ontplooien zonder assistentie of tussenkomst van IT-specialisten of ander menselijk contact. Het betreft hier niet louter de voorzieningen van clouddiensten in het algemeen maar zaken zoals : On-demand processing resources (hardware): men kan dus zelf de performantie van de clouddiensten bepalen On-demand storage resources: men kan dus zelf de hoeveelheid schijfruimte bepalen On-demand services (software): Men kan dus zelf bepalen welke softwarediensten hij ter beschikking wil hebben. 13 § Broad network access: Cloud computing zorgt ervoor dat de verschillende services bereikbaar zijn van overal (niet locatie gebonden). Het komt erop neer dat diensten bereikbaar zijn vanop alle toestellen die beschikken over een internetverbinding. Dit betekent dat deze diensten bereikbaar zijn vanop smartphones, tablets, laptops, desktops … etc. § Resource pooling: Is eigenlijk een logisch gevolg van virtualisatie. Bij resource pooling komt het erop neer dat computer resources via de cloud service provider worden gegroepeerd om meerdere afnemers te bedienen. Hierbij wordt gebruik gemaakt van het multi-tenancy model. Het multi-tenancy model is een software architectuur waarbij elke individuele instantie van een softwareapplicatie meerdere afnemers (tenants) bedient. Het voordeel tegenover single-tenancy (een architectuur waarbij elke afnemer zijn eigen software-instantie ter beschikking heeft) is vooral economisch. Onder meer de kosten voor softwareontwikkeling en –onderhoud kunnen gedeeld worden. § Rapid elasticity: Rapid elasticity betekent dat afnemers van clouddiensten hun volume aan diensten kunnen laten toenemen naarmate de behoefte daarvoor ontstaat. Het kan hier gaan over rekenkracht of software diensten, hoeveelheid opslag en andere vormen van clouddiensten. § Measured service: Cloud computing optimaliseert het gebruik van de diensten van de cloud service provider. Hierbij kan het systeem op een bepaald niveau (bvb opslag, rekenkracht, bandbreedte … etc) het verbruik meten. De afnemer zal enkel betalen voor wat er verbruikt wordt. (pay for what you use) 3.7.2 Cloud deplyment modellen : Cloudcomputing kan worden ingezet op drie verschillende manieren. Men spreekt over de drie ‘deployment-modellen’. 1. SaaS (Software as a Service) Bedrijven krijgen software ter beschikking via het internet. Een voorbeeld hiervan is Athena, een applicatieserver van UGent die studenten allerhande software ter beschikking stelt die ze nodig hebben voor hun studies. 2. PaaS (Platform as a Service) Bij PaaS krijgen bedrijven volledige platformen ter beschikking via het internet waarop ze dan zelf software kunnen ontwikkelen. Denk bijvoorbeeld aan een SQL-server die nodig is om een databanktoepassing op te zetten. 14 3. IaaS (Infrastructure as a Service) Hier wordt de volledige infrastructuur ter beschikking gesteld aan bedrijven. Een voorbeeld is een digitale telefooncentrale zonder er een eigen infrastructuur voor uit te bouwen. Alleen de telefoons dienen aangekocht te worden, de ‘centrale’ kan volledig via internet ter beschikking gesteld worden. Samenvattend (verantwoordelijkheid vs controle) Zoals je kan zien in Figuur 3-14 is de verantwoordelijkheid van de cloud provider anders is per gekozen deployment model. Figuur 3-14: Cloud provider verantwoordelijkheid. Je zou ook kunnen stellen dat de controle die de klant heeft over de geleverde service afhankelijk is van het gebruikte deployment model (Figuur 3-15) . 15 Figuur 3-15: Controle vs flexibiliteit van cloud deplyment modellen Zo kan men stellen dat SaaS minder controle biedt aan klanten (bijvoorbeeld om eigen toepassingen te ontwikkelen) dan IaaS (waar het voor klanten veel moeilijker is om nieuwe toepassingen te ontwikkelen). Klanten hebben echter wel meer flexibiliteit bij het opzetten van een IaaS systeem dan bij het opzetten van een SaaS-systeem. Zo kan een klant bijvoorbeeld veel duidelijker kiezen welke netwerkcomponenten aanwezig zijn bij een virtueel netwerk, maar hebben ze minder keuze voor de minimum vereisten van een ERP pakket dat via een CSP wordt gehost. 3.8 Clouddiensten volgens de beheerder Naast het type service dat via cloud-computing ter beschikking wordt gesteld, kan men clouddiensten ook onderscheiden volgens wie de clouddienst beheert of ter beschikking stelt. We spreken van publieke clouddiensten, private clouddiensten, community-clouddiensten of hybride clouddiensten. Figuur 3-16: Opsplitsing clouddiensten volgens de beheerder van de cloud Publieke clouddiensten Bij een publieke cloud wordt de infrastructuur ter beschikking gesteld voor iedereen. Zowel gewone consumenten als organisaties hebben de mogelijkheid gebruik te maken van de cloudinfrastructuur in kwestie. Publieke clouddiensten kunnen gratis aangeboden worden maar zijn meestal in handen van organisaties die clouddiensten verhuren aan derden. Gekende publieke CSP’s zijn: Google, Amazon, Microsoft... 16 Private clouddiensten De infrastructuur van private clouds wordt vooral gekenmerkt door het feit dat ze exclusief ter beschikking staan van één organisatie en meerdere consumenten (onderdelen van de organisatie). Er is over het algemeen veel meer controle over de infrastructuur en de daarop aanwezige applicaties en functionaliteiten door de afnemer zelf. De private cloud is meestal eigendom van de afnemer zelf, maar men kan ook een private cloud huren bij een cloud-serviceprovider (klinkt een beetje contradictief, maar het is wel zo). Community-clouddiensten In het geval van een ‘community cloud’ wordt de cloudinfrastructuur voorzien voor het exclusieve gebruik van een gemeenschap (denk bijvoorbeeld aan een industriepark of een scholengemeenschap). Het principe is dus hetzelfde als dat van de private clouds, maar het doelpubliek is een groep van organisaties die iets met elkaar delen zoals een gemeenschappelijke locatie, gemeenschappelijke missies, gemeenschappelijke beveiligingsvereisten, een gemeenschappelijk beleid... Hybride clouddiensten In het geval van een hybride cloud bestaat de cloudinfrastructuur waar een organisatie gebruik van maakt uit een samenstelling van voorgenoemde cloudinfrastructuurmodellen. Meestal gaat het om een combinatie van een publieke cloud en een private cloud. De verschillende infrastructuren behouden hun unieke entiteit maar worden verbonden met elkaar door gebruik te maken van bepaalde technologieën die de verplaatsing van data en applicaties mogelijk maakt. Zo kan bijvoorbeeld bedrijfsgevoelige data beheerd worden in de private cloud en minder vertrouwelijke applicaties in de publieke. 3.9 Belangrijkste voor- en nadelen van cloud computing De mogelijkheden van cloud computing blijven toenemen. Dit biedt een enorm gamma aan opportuniteiten voor bedrijven. Vandaag de dag lijkt cloud computing de meest inzetbare oplossing voor tal van kleine en grote bedrijven. Daarom is het ook belangrijk om de voor- en nadelen voor deze bedrijven nader toe te lichten. De hieronder genoemde voor- en nadelen zijn vooral belangrijk voor bedrijven die gebruik maken publieke clouddiensten. 3.9.1 3.9.1.1 Voordelen van cloud computing Schaalbaarheid (Scalability) Het is mogelijk voor een organisatie om de geleverde diensten van de cloud provider snel aan te passen. Wanneer een organisatie bijvoorbeeld plots te maken krijgt met een voorheen onbekende piek in haar economische activiteit, kunnen extra resources heel snel en eenvoudig voorzien worden dankzij de flexibiliteit van cloud-infrastructuren. 17 Indien er een periode aanbreekt waarin de economische activiteit van de organisatie sterk afneemt, kan de overbodige cloud-capaciteit worden opgezegd. 3.9.1.2 Pay for what you use Men hoeft enkel te betalen wat de organisatie verbruikt. Dit betekent dat een onderneming heel wat geld kan besparen. Indien een organisatie enkel gebruik zou maken van een eigen infrastructuur, zou men in periodes van lage economische activiteit met overcapaciteit kampen. Gedurende deze periode zou men de overbodige infrastructuur toch moeten onderhouden, ook al wordt deze niet gebruikt. 3.9.1.3 Lagere infrastructuurkosten en andere besparingen Door gebruik te maken van cloud computing is al gebleken uit de vorige 2 punten dat er bespaard kan worden. Naast schaalbaarheid en pay for what you use, moeten organisaties ook minder investeren in andere kosten zoals bijvoorbeeld loonkosten binnen het IT-departement daar een groot stuk van het onderhoud van de infrastructuur niet door de bedrijven zelf dient gedragen te worden (deze zit wel voor een stuk verrekend in de prijs die betaald wordt aan de cloud service provider). Dergelijke kostenbesparingen kunnen soms hoog oplopen voor bedrijven (zie hoofdstuk 4 TCO) 3.9.1.4 Beschikbaarheid Je kan er vanuit gaan dat de beschikbaarheid van de infrastructuur door cloud service providers gegarandeerd wordt en vaak hoger is dan de beschikbaarheid die een bedrijf kan garanderen wanneer hij deze infrastructuur zelf zou beheren. De meeste CSP’s beschikken over een vrij groot aantal servers. De grote spelers hebben zelf meerdere datacentra. Door op regelmatige tijden snapshots te nemen en scenario’s te voorzien voor failovers, kan een vrij grote beschikbaarheid gegarandeerd worden. Als er zich bijvoorbeeld een ernstig voorval voordoet in een rekencentrum (brand) dan kan een ander rekencentrum overnemen. Dit betekent dus inderdaad dat snapshots worden bijgehouden op verschillende locaties. 3.9.1.5 Toestel onafhankelijkheid Gezien de applicaties en/of data extern gehost worden op cloudservers en deze servers logischerwijs verbonden zijn met het internet, kunnen deze applicaties en/of data vanaf elk toestel met internet verbonden, benaderd worden indien de benodigde toegangssoftware is voorzien op deze toestellen. Door gebruik te maken van desktopvirtualisatie kan op eender welk toestel een desktop aangeboden worden die nodig is om in interactie te gaan met de gebruikte infrastructuur die via de cloud wordt gebruikt. Sommige virtuele desktops zijn zelfs voorzien van interfaces die gebruikt kunnen worden op toestellen die eigenlijk niet over de nodige infrastructuur beschikken. Zo kan een virtuele desktop gemaakt zijn om op een tablet te gebruiken waar geen muis aan hangt (en dus geen dubbel-click commando kan gegeven worden). Een ander 18 voorbeeld is een virtual desktop voor een smartphone die de camera van de telefoon gebruikt als (virtuele) barcodelezer. 3.9.1.6 Robuustheid van oplossing (data) Dankzij de technologie als snapshot, migratie en failover is het mogelijk om heel robuuste oplossingen te bedenken voor toepassingen en data. We hebben dit al besproken bij beschikbaarheid. Voor data dient men echter nog bijkomend op te merken dat de meest betrouwbare manier om met data om te gaan gebeurt via cloudoplossingen. Data in de cloud wordt vaak niet enkel bewaard op één fysieke locatie (wat dus al een heel goede back-up garandeert). De data kan eenvoudig gemigreerd en gekopieerd worden tussen verschillende cloudbronnen. Snapshots uit het verleden kunnen ook verzameld worden. Zo kan men vrij snel terug keren naar vorige tijdstippen van data. Een medewerker die per ongeluk een file overschrijft hoeft geen probleem op te leveren. 3.9.1.7 Economische efficiëntie en efficiënter gebruik van resources. Door het feit dat clouddiensten worden afgestemd op de vraag kan besloten worden dat clouddiensten economisch efficiënter zijn. Bijvoorbeeld via community clouds kunnen bedrijven of andere instanties hun hulpbronnen koppelen of investeringen in infrastructuur gezamenlijk dragen. Uit de definitie van cloud computing kan afgeleid worden dat resources efficiënter gebruikt worden bij servers die behoren tot een cloudserverpark aangezien deze door meerdere afnemers gebruikt worden. Applicaties die best een eigen “dedicated” server krijgen, kunnen via een VM zo geconfigureerd worden dat ze inderdaad een eigen afgesloten omgeving hebben en toch gebruik maken van gemeenschappelijke servers. Opslag, geheugen, rekenkracht, fysische voorzieningen van een datacentrum … etc, worden allemaal veel efficiënter gebruikt. Bepaald beleid kan ook makkelijker gerealiseerd worden door het gebruik van cloud computing. Denk maar aan Green-IT, waar initiatieven voor bijvoorbeeld paperless office kunnen gebruik maken van bestaande cloudoplossingen. 3.9.1.8 Beveiliging Cloud service providers staan zelf in voor de beveiliging van hun diensten. Dit zou beschouwd kunnen worden als een nadeel, maar is tegelijk ook een voordeel. Kleine bedrijven die gebruik maken van clouddiensten maken op die manier gebruik van de aangeboden beveiligingsdiensten van de cloud service providers. Wanneer ze eigen IT infrastructuur uitbouwen wordt de factor rond beveiliging veelal over het hoofd gezien of stiefmoederlijk behandeld. Denk maar aan patchen. Patchen kan aanzien worden als een belangrijke beveiligingsmaatregel bij IT-infrastructuur. Het patchen van systemen zal in veel instanties gebeuren door de CSP en is een zorg waar de afnemer minder rekening dient te houden. (‘…. geen rekening dient te houden’ is niet correct, zie 3.9.2.3) 19 3.9.2 Belangrijkste nadelen van cloud-computing Het gebruik van cloudoplossingen houdt ook enkele risico’s in voor bedrijven. 3.9.2.1 System Lock-in System lock-in is één van de strategieën die naar voren wordt geschoven door het delta-model. Er zijn verschillende raamwerken die gebruikt worden om op een strategische manier om te gaan met IT. Het deltamodel is daar een belangrijke van. System lock-in nastreven voor zijn klanten wordt binnen dat model aanzien als de beste concurrentiepositie die een bedrijf (in dit geval een CSP) kan nastreven, maar dit is niet het beste voor de klant. Het hele deltamodel uitleggen zou ons te ver weg brengen van een cursus IT-infrastructuur. Maar system lock-in dient kort besproken te worden omdat het een belangrijk risico is wanneer gebruik gemaakt wordt van cloud computing. Figuur 3-17: Het Delta-model De makkelijkste manier om system lock-in uit te leggen is door gebruik te maken van een voorbeeld. De meeste software wordt ontwikkeld voor windows OS’en want dit is de meest gebruikte OS. De meeste mensen die een nieuwe computer kopen kiezen voor een windows OS want deze heeft de meeste software. Dit is een typisch voorbeeld van een system lock-in. De meeste IT-bedrijven die producten of diensten verkopen proberen zichzelf in zo’n positie te krijgen. Door te kiezen voor een commerciële CSP is de kans groot dat het bedrijf in een system lock-in komt van de CSP. Dat betekent dus wel dat de keuze van de CSP niet vrijblijvend is. Eenmaal gekozen voor een CSP zal verdere integratie van IT vermoedelijk het makkelijkst gebeuren door andere systemen ook bij hen onder te brengen, en op die manier is men op termijn heel afhankelijk van de CSP en zijn visie. 20 3.9.2.2 Problemen rond gebruikersovereenkomsten en SLA’s Binnen het domein van IT-infrastructuur wordt veel gebruik gemaakt van een gebruikersovereenkomst en / of SLA (service level agreement). Dit kan aanzien worden als het contract tussen de klant en het bedrijf die de IT of IT-service voorziet. Het beschrijft de spelregels maar ook de juridische aansprakelijkheid en de garanties die worden gekoppeld aan het gebruik van de dienst. Veel CSP’s maken gebruik van standaard gebruikersovereenkomsten en / of SLA’s. Deze zijn meestal zo opgesteld dat vooral de klant gebonden is aan vaste regels (met veelal vastliggende sancties). Grote CSP’s beschikken over een batterij aan juristen die dergelijke overeenkomsten zo hebben opgesteld dat het grootste stuk van de verantwoordelijkheid bij de klanten ligt en de aansprakelijkheid tot een minimum is beperkt. Voor een klant is het heel moeilijk om invloed te hebben op de termen die in dergelijke overeenkomsten verwerkt zitten. (zeker voor kleine bedrijven). In vele gevallen is ook de kennis niet aanwezig om te kunnen inschatten wat nu exact in die overeenkomsten verwerkt zit. Dit alles samen zorgt ervoor dat het dit een risico inhoudt voor bedrijven die opteren voor cloud oplossingen bij commerciële CSP’s. 3.9.2.3 Beveiliging Hoewel de beveiliging van data in de cloud reeds als voordeel werd aangehaald, kan security ook als nadeel gezien worden. De 2 hoofdbezorgdheden zijn : § Externe hackers kunnen toegang krijgen tot cruciale data. Bescherming van data is niet meer in handen van de eigenaar van de data, maar in handen van de service provider (of toch minstens gedeeltelijk). § Een cloud service provider zelf kan de eigenaar van de data schade berokkenen aangezien de data zich in zijn servercentrum bevindt. Er wordt vanuit gegaan dat data onderhevig is aan 4 belangrijke bedreigingen. 1. Ongeautoriseerde server: data wordt getransporteerd over een netwerk naar de cloud dus zijn er meerdere mogelijkheden als aanvaller om zich voor te doen als cloudserver om zo aan data te raken (man in the middle attack). 2. Data wordt wel geëncrypteerd om verstuurd te worden, maar deze encryptie is te kraken via een “brute force attack”. 3. Indien een CSP zich keert tegen de eigenaar van de data, kan er heel wat gebeuren met deze data. 4. Authenticatie is nodig om ongeautoriseerde toegang tot data te voorkomen. Gebruikers kunnen echter toegangsgegevens verliezen of deze gegevens (al dan niet per ongeluk denk maar aan slecht wachtwoordbeheer) geven aan ongeautoriseerde personen, die via deze weg toegang kan verkrijgen tot die data (social engeneering). 3.9.2.4 Privacy, GDPR en andere legale risico’s Bestaande privacy regels (zoals bijvoorbeeld de Europese e-privacyverordening) gaan ervan uit dat er een duidelijk geïdentificeerd persoon of bedrijf verantwoordelijk is voor de verwerking van persoonsgegevens. Cloud computing bemoeilijkt dit aangezien data overal ter wereld 21 bewaard wordt zonder dat de afnemer precies weet waar. Hoe gaat men bepalen wie verantwoordelijk is voor mogelijke lekken van persoonsgegevens en onder welke nationale wetgeving zou dit moeten vervolgd worden? Een belangrijke wetgeving rond informatiebeveiliging en privacy is ‘GDPR’ (of met de Nederlandse benaming ‘AVG’, Algemene Verordening voor Gegevensbescherming). Deze Europese wetgeving is van kracht sinds 25 mei 2018 en gaat over “de bescherming van natuurlijke personen in verband met de verwerking van persoonsgegevens en betreffende het vrije verkeer van die gegevens”. Alle bedrijven die persoonlijke gegevens bijhouden of verwerken zijn onderhevig aan deze wetgeving. Wanneer bedrijven niet voldoen aan deze wetgeving kunnen boetes worden opgelegd tot 4 procent van de omzet met een maximum van 20.000.000 euro. Het is de bedoeling dat deze wetgeving wordt toegepast naast de Europese eprivacyverordening. De GDPR-wetgeving garandeert dus privacy bij het gebruik van persoonsgegevens. Het voorziet enkele mechanismen die het mogelijk maken voor mensen om inzicht te krijgen in de verwerking van hun persoonsdata en beschermt tegelijk personen voor niet-correct gebruik van de data. De belangrijkste zaken waar bedrijven rekening mee moeten houden zijn: transparantie, doelbeperking, gegevensbeperking, bewaarbeperking, recht vergeten te worden, integriteit en vertrouwelijkheid, verantwoording, meldplicht datalekken, aanstellen DPO (Data Protection Officer). Sommige van deze zaken zijn onderhevig aan risico’s wanneer met gebruik maakt van cloud computing: Transparantie Elke persoon van wie gegevens verwerkt worden, dient hiervan op de hoogte te zijn gesteld en dient expliciet toelating te hebben gegeven. Men moet ook te kennen geven waarvoor deze data gebruikt wordt en welke informatiesystemen, binnen (of buiten) de organisatie, gebruik maken van welke data. Men dient ook te kunnen aantonen wie op welk moment toegang heeft tot deze informatie. Vooral dat laatste is niet altijd even duidelijk wanneer men gebruik maakt van een CSP. Er mag nog zo hard worden nagedacht over wie toegang heeft tot welke gegevens. Ook de CSP heeft mensen die toegang hebben. Deze kunnen onmogelijk in kaart worden gebracht door de betrokken afnemers en kunnen meestal niet worden opgevraagd bij een CSP (dit zit meestal vervat in SLA’s). Bewaarbeperking Persoonsgegevens mogen niet langer bewaard worden dan nodig is voor het beoogde doel. 22 Voor veel CSP is het net een onderdeel van hun bedrijfsvoering dat heel robuuste oplossingen worden aangeboden rond data. Snapshots worden soms heel lang bewaard. Dit is in tegenspraak met deze richtlijn binnen GDPR. Recht vergeten te worden Personen mogen te allen tijde vragen om hun persoonsgegevens te wissen. Bedrijven dienen dan effectief alle persoonsgegevens van die persoon te verwijderen. Hier geldt dus hetzelfde risico als bij bewaarbeperking. Een bedrijf kan een persoon verwijderen uit een databank, maar de CSP heeft misschien nog heel lang kopieën van die databank waar de persoon wel nog in staat. Verantwoording Bedrijven dienen de verantwoordelijkheid te dragen voor hun informatiesystemen. Men moet kunnen aantonen dat bepaalde beveiligingsmaatregelen genomen werden en dat ze aan de regels van GDPR voldoen. Bij het gebruik van cloud computing gaat het veelal om gedeelde verantwoordelijkheid. Zowel het bedrijf als de CSP dienen adequate maatregelen te nemen voor de stukken waar ze voor verantwoordelijk zijn. Wanneer een bedrijf zou te kampen krijgen met een GDPR-geschil kan het moeilijk zijn om aan te tonen welke verantwoordelijkheid bij de CSP ligt en welke maatregelen deze genomen heeft om te voldoen aan de GDPR vordering. Meldplicht datalekken Bedrijven zijn ook verplicht om datalekken te melden aan een Europese instantie. Zo kunnen bedrijven niet langer proberen verbergen dat bepaalde data door onbevoegden is onttrokken aan de informatiesystemen. Zal een CSP inderdaad melden wanneer er datalekken gebeurd zijn? Kan een CSP exact achterhalen welke bedrijven betrokken zijn bij een cyberaanval. De manier waarop via virtualisatie op een zo efficiënt mogelijke manier wordt omgegaan met server en datacentra maakt het niet altijd even makkelijk om in te schatten welke data inderdaad onderhevig is geweest aan een datalek. Naast GDPR zijn bedrijven onderhevig aan andere wetten die soms sector gebonden zijn. Organisaties uit de financiële sector bijvoorbeeld worden vele regels opgelegd die verplaatsing/ beweging van data beperkt. Men moet dus enorm voorzichtig zijn met het verhuizen van data in de cloud en dit schrikt af. Ook de locatie van de data of toepassingen kan wettelijke gevolgen hebben. De locatie bepaalt de wetgeving die van toepassing is. Een internationale wetgeving zou dit kunnen verhelpen, maar is tot nog toe onbestaand. 23 3.9.2.5 Technologische adoptie en implementatie Veel bedrijven hebben nood aan begeleiding in het ontwikkelen van een ‘technology roadmap’. Het is niet vanzelfsprekend voor een bedrijf om te bepalen welke applicaties zouden moeten verhuizen naar de cloud en hoe men de technologische veranderingen moet implementeren op een manier die de huidige activiteit het minst verstoort. Het ontwikkelen van methodologieën die alle mogelijke risico’s identificeert en evalueert bij het adopteren van clouddiensten is hier van essentieel belang. Het is belangrijk dat bedrijven zich bewust zijn van de impact van een cloud-migratie en vooral stilstaan bij het integreren van de cloud-oplossing met de andere IT-infrastructuur van het bedrijf. 3.9.2.6 Strategie Wanneer bedrijven resoluut kiezen voor cloud computing zal het nieuw ontwikkelen of aanpassen van bedrijfsstrategieën grote veranderingen met zich meebrengen. Grote organisaties hebben heel wat samenwerkingsverbanden met andere organisaties. Hoe moet men deze potentiële intra-organisationele problemen aanpakken? Welke culturele veranderingen zouden moeten doorgevoerd worden om de acceptatie van de werknemers en partners te bekomen? Welke andere problemen kunnen optreden bij het doorvoeren van een verandering in de ITstrategie? Al deze bedenkingen kunnen bedrijven ervan weerhouden om over te schakelen naar cloud computing oplossingen. 3.9.2.7 Controle IT-departementen van bedrijven verliezen niet graag de controle over hun bronnen aan de CSP die de onderliggende technologie van hun toepassingen en/of data kunnen veranderen zonder toestemming van de afnemer. CSP’s geven veel controle over de dienst die wordt gebruikt door een afnemer. Wanneer men bijvoorbeeld via de cloud een SQL-server huurt, dan heeft men meestal als afnemer vrij veel controle over de configuratie. Over de onderliggende hardware echter is deze controle zo goed als niet bestaand. De CSP voorziet een dienst, geen inspraak in de manier waarop deze dienst technologisch wordt ondersteund. Het afstaan van deze controle is veelal een te overwegen risico alvorens over te schakelen naar cloud computing. 3.9.2.8 Beschikbaarheid Beschikbaarheid werd al aangehaald als voordeel, maar deze technologie heeft natuurlijk ook te kampen met een probleem rond beschikbaarheid. Wanneer providers enkele uren offline gaan of wanneer afnemers voor eender welke reden geen toegang hebben tot het internet is deze service niet meer bruikbaar. Dat betekent dus dat organisaties heel afhankelijk worden van netwerktoegang (internettoegang) en van de beschikbaarheid van de CSP. 24 Internettoegang wordt veel aangehaald als een belangrijke reden waarom bedrijven niet overgaan naar cloud-computing. Hier dient men echter ook enige terughoudendheid te voorzien in dergelijke argumentatie. Een backup plan voor internettoegang hoeft niet duur te zijn. Er kan een abonnement genomen worden bij meer dan 1 internet provider of men kan bijvoorbeeld 4G-sticks voorzien voor de gevallen waarop internet niet beschikbaar is. Bij on-premises IT kan inderdaad gesteld worden dat deze niet onderhevig is aan dit risico (alles draait op eigen LAN). Maar wanneer de servers gebruikt worden om diensten aan externen te leveren (zoals klanten of partners), dan was dit risico al aanwezig. Hoewel de meeste CSP providers gebruik maken van heel robuuste IT-oplossingen is het risico dat een CSP onbeschikbaar is niet onbestaande. Op 21 oktober 2016 werd een wereldwijde cyberaanval gedaan op enkele DNS-servers. Dit resulteerde in een groot aantal sites die niet meer toegankelijk waren voor enkele uren. Naast twitter, AirBNB, spotify, netflix …etc waren ook enkele grote CSP het slachtoffer (oa Amazone Web Service). Dit voorbeeld dient vooral om aan te geven dat zelfs de meest beveiligde CSP geen controle heeft over belangrijke DNS-servers die een cruciaal onderdeel vormen voor de werking van het (hele) internet. 3.9.2.9 Onvoldoende kennis van risico’s. Vele bedrijven vrezen dat ze niet over de juiste kennis beschikken om de risico’s van een migratie naar de cloud juist te kunnen inschatten. Om niet voor verrassingen komen te staan is men soms geneigd om deze migratie niet te doen. Voor anderen kan het ontbreken van de nodige kennis rond de risico’s inhouden dat men in een later stadium voor onaangename verrassingen komt te staan. Veelal hebben ze de gebruikersovereenkomst niet goed ingeschat omdat ze geen beeld hadden van de risico’s die ze liepen door te migreren naar de cloud. 3.9.2.10 Gebrek aan regularisatie Er is een noodzaak aan internationale agentschappen of overheden om proactief om te gaan met de uitdagingen in de opkomende cloud industrie. Een voorbeeld hiervan zouden voorschriften kunnen zijn waarmee rekening moet gehouden worden bij het opstellen van een SLA (service level agreement) tussen dienstverlener en klant. Voorlopig kan men hier nog spreken over een ernstig gebrek aan dergelijke initiatieven. 25 26