Datum | |
---|---|
Tijd | |
Thema | |
Location |
|
Role | |
Description | |
More info |
- Nieuws
Nederlandse partijen bouwen testomgeving voor Gaia-X clouddiensten
- Cloud
Overstappen naar de cloud: het klinkt tegenwoordig als de gewoonste zaak van de wereld, maar afscheid nemen van je eigen datacenter en vertrouwen op systemen van derden brengt heel wat hoofdbrekens met zich mee. Voor organisaties die in de financiële sector werkzaam zijn, zijn er nog net wat meer uitdagingen. Hoe ga je voldoen aan alle regels die toezichthouders en overheden stellen? Hoe ga je bewijzen dat je compliant bent? Met welk deel van je IT ga je naar de cloud? En ben je als bedrijf wel goed voorbereid? Een eerste tip: het is een flinke lijst met complexe vraagstukken. Probeer vooral zelf het wiel niet uit te vinden.
Bij een cloudtransitie, ontkom je niet aan de meest essentiële vraag: is mijn data wel veilig? Dat je als organisatie secuur met gegevens omgaat, moet je kunnen bewijzen. Of je je gegevens nou opslaat op eigen servers of in de cloud. Onder de streep betekent compliant zijn dat je wet- en regelgeving naleeft, zowel regels van externe partijen als interne bedrijfsafspraken. Vooral in de financiële sector gaat het om gevoelige gegevens. Denk dan aan bank- en in sommige gevallen zelfs gezondheidsgegevens, zoals bij verzekeringen of hypotheken. Daar moet je extreem voorzichtig mee zijn.
Als bedrijf in de financiële sector moet je aan allerlei verplichtingen voldoen. Denk aan wetten van de overheid en regels van de AFM, De Nederlandsche Bank en andere toezichthouders. Je moet verklaringen kunnen afleggen van compliancy, denk bijvoorbeeld aan ISAE 3402 type 2 en SOC 2. Of voldoen aan wetgeving zoals de AVG of Schrems 2, dat uitspraken doet over waar je, geografisch gezien, data van EU-ingezetenen al dan niet mag onderbrengen. Om echt compliant te zijn moet je aantonen dat je voor alle problemen een oplossing hebt en dat je als bedrijf in control bent.
Een transitie naar de cloud is een lange reeks hordes die je moet nemen. Vooral op het gebied van veiligheid liggen er uitdagingen. Om te beginnen moet je de toegang beperken voor iedereen die er niets te zoeken heeft. Waar minder vaak aan gedacht wordt, is dat bestanden niet alleen onleesbaar moeten zijn voor derden zijn als ze onderweg zijn naar de cloud (encryptie “in transit”), maar ook als ze op de bestemming zijn (encryptie “at rest”). Is de standaard hardeschijfversleuteling van de clouddienst voldoende? Of heeft de systeembeheerder daar dan ook de sleutel van en kan er alsnog worden meegelezen?
Als je naar de cloud verhuist, zet je simpel gezegd spullen van jezelf op een computer van een ander. De risico’s daarvan moet je goed in kaart brengen. Hoe borg je bijvoorbeeld dat je toegang blijft houden? Hoe kan je je business draaien als het datacenter het even niet doet? Daar moet je van tevoren goed over nadenken en protocollen voor maken.
Zo kan je overwegen om gebruik te maken van meerdere datacenters. Is er in één van de twee datacenters iets aan de hand, merk je daar als bedrijf niet veel van in je processen. Mits je alles goed hebt ingericht. Maar, staan deze datacenters in verschillende landen, mag dat dan wel van nationale of Europese wetgeving? En kan een buitenlandse overheid op basis van haar wetten dan daar zomaar toegang claimen tot jouw bedrijfsgegevens?
Zeker voor bedrijven in de financiële sector is het in de periode voor een livegang essentieel om alle risico’s die er zijn in kaart te brengen. Hoe snel moet je je business weer draaiende hebben als er zich een ramp voordoet? Stel dat je dat binnen acht uur moet kunnen, dan heb je even de tijd en hoef je niet per se twee systemen naast elkaar live te hebben. Maar heb je de verplichting opgelegd gekregen van een van de toezichthouders of een belanghebbende, om binnen een minuut weer live te zijn, dan moet je wél zorgen dat alles wat belangrijk is stand-by staat. Stel dat je als bank geen geld meer kunt overschrijven, omdat het datacenter het tijdelijk niet doet, dan raakt dat de hele sector, en misschien zelfs de hele maatschappij. Dat mag dus nooit gebeuren.
Voor de klantengroep van Info Support zijn er twee grote cloudaanbieders: Amazon en Microsoft met hun Azure-platform. Daarnaast maakt een steeds grotere groep klanten gebruik van de Info Support -cloudomgeving, die in onze eigen datacenters draait. Info Support snapt die systemen als geen ander en weet weet hoe security-officers of de risk- & compliance-officers van een bedrijf kunnen aantonen dat ze compliant zijn. Bij dat laatste ligt een grote uitdaging. Je moet als bedrijf namelijk zelf laten zien dat je compliant bent. Dat doe je door – naast verklaringen aan te leveren – bewijzen te verzamelen.
Bij het inregelen van een nieuw systeem raadt Info Support klanten aan om er een pentest op los te laten door een extern beveiligingsbureau. Schiet maar een gat in de verdediging als je denkt dat dat lukt. Vervolgens kan het Security Operations Center (SoC) van de klant zelf, als het live staat, monitoren op security-incidenten, of dat overlaten aan Info Support dat ook SoC-diensten levert.
Uit bovenstaande blijkt dat migreren naar de cloud en de bijbehorende transitie veel aandacht verdient. Een goede tip: neem de tijd om een gedegen transitieplan te maken. Zoek een partij die op de hoogte is van alle eisen en regels waar je aan moet voldoen. Laat iemand adviseren over wat er wel en niet naar de cloud kan. Ga pas live als er een kant-en-klaar draaiboek ligt waarbij ook het omschakelmoment tot in detail in kaart is gebracht.
Bij een dergelijke transitie hoort mogelijk ook een migratie van applicaties. Afhankelijk van het gekozen scenario ‘cloud native’, ‘lift & shift’ of ‘hybride” zijn vaak nog aanpassingen aan applicaties nodig. Daarvoor heeft Info Support ook een aantal publicaties beschikbaar via haar website.
Het omschakelmoment verdient sowieso extra aandacht. Dan zijn er namelijk applicaties al naar de cloud verhuisd, maar die moeten soms nog wel verbinden met applicaties die nog op een server in het eigen datacenter staan. Dat wil wel eens misgaan als de netwerken en firewalls niet goed ingeregeld zijn. Dan zal toegang worden geweigerd. Om dat werkend te krijgen moet je niet tijdelijk alle poorten openzetten, maar teruggaan naar de tekentafel. Je maakt jezelf anders dus enorm kwetsbaar. Een dergelijke vertraging is doorgaans kostbaar, wat dus te voorkomen is met een gedegen infrastructuurontwerp en transitieplan.
Valkuilen, gevaren en potentiële problemen zijn er dus genoeg. Waarom zou je jezelf als bedrijf wel aan een overstap wagen? De voordelen zijn groot. Een eigen serverpark beveiligen en compliant krijgen – en houden – kost óók de nodige effort. Werken in de cloud is snel en praktisch. Je kunt makkelijk je capaciteit opschalen of verkleinen. Je kunt gebruik maken van geografische risicospreiding door data op verschillende locaties op te slaan. Dat gaat allemaal veel eenvoudiger dan wanneer je zelf servers in beheer hebt.
Qua kosten valt er zeker wat te winnen. Je betaalt namelijk voor de capaciteit die je nodig hebt. Dat is logisch, maar je hoeft niet 24 uur per dag te betalen voor alle diensten die je afneemt. Dat kan ook een valkuil zijn. Neem een acceptatie-testomgeving, die draait meestal alleen tijdens kantooruren. Het is zonde om daar een hele dag voor te betalen. Daar moet je als afnemer wel aan denken. Degene die ’s avonds het licht uit doet, moet ook de servercapaciteit uitzetten. Tenminste, als het resources zijn die afgerekend worden per tijdseenheid. Er zijn bijvoorbeeld ook clouddiensten die afgerekend worden op basis van het aantal keer dat ze worden aangesproken. Dus, of dit relevant is en of dit wel zomaar kan, is afhankelijk van het doel dat je hebt met je transitie naar de cloud.
Het zijn vraagstukken waar Info Support graag hun tanden inzet. Als een bedrijf het zelf wil doen, dan kan dat ook, maar moet je keer op keer op zoek naar een oplossing voor een probleem dat waarschijnlijk al een aantal keer getackeld is door anderen. Probeer dus niet het wiel opnieuw uit te vinden.
Peter Jansen is consultant bij Info Support en begeleidt regelmatig cloudtransities voor bedrijven in de financiële sector. Hij weet als geen ander waar de moeilijkheden liggen bij compliance in de cloud.
1. Zelf wetten van de overheid vertalen naar beleid
“Dat je moet voldoen aan wetten en regels, is volkomen logisch. Waar de moeilijkheid in zit? Het is complexe materie, want je moet de eisen van een toezichthouder zelf vertalen naar beleid. Dat zijn de vraagstukken die wij als Info Support vaak van onze klanten krijgen. Denk aan vragen als: ‘Is uitwijk geregeld?’, ‘Hoe gaan we om met de bedrijfsvoering bij een outage?’, ‘Wat doe ik als ik niet meer bij mijn data kan?’”
2. Het schort aan een goede voorbereiding
“Er wordt nog wel eens te licht gedacht over een overstap naar de cloud en aan compliant zijn. Het is niet zo eenvoudig als dat sommige bedrijven denken. Je kunt de server aanzetten, een applicatie uitrollen en dan kijken of het werkt. Dankzij interne audits en eisen van toezichthouders gebeurt dat niet zo vaak meer, maar nog altijd komen we bedrijven tegen die ons later in de transitie pas om hulp vragen. Dan blijkt dat er nog zaken zijn waar niet aan gedacht is. Dat kan van alles zijn: van beveiligingsissues, geen goede inrichting van virtuele cloudnetwerken, tot geen goede back-up. Daarnaast staat een server aanzetten en een applicatie uitrollen, zoals je dit ook on-premises deed (lift & shift), niet gelijk aan overstappen op een cloud native-architectuur, waarbij je echt voordeel gaat halen uit alle mogelijkheden die de cloud biedt. Afhankelijk van de situatie kan dit overigens wel een heel valide eerste stap zijn.”
3. Je authenticatie en autorisatie op orde hebben
“Identity & Access Management (IAM), zeg maar authenticatie en autorisatie kan een technisch complex, veelkoppig monster zijn voor bedrijven die naar de cloud verhuizen. Een simpel voorbeeld: hoe log je met een werkaccount in op de nieuwe locatie? Dat ging altijd goed bij een applicatie die op een server in je eigen datacenter stond, maar kan dat nog steeds als het gemigreerd is? Aan dergelijke mechanismes moet je vaak nog het een en ander sleutelen. Kan je oude applicatie wel omgaan met andere inlog methodes die je in de cloud moet gebruiken, moet je accounts migreren of synchroniseren?”