Inleiding
De overstap naar cloudgebaseerde IT-oplossingen biedt organisaties ongekende mogelijkheden, maar roept ook fundamentele vragen op. Wat gebeurt er als een cyberaanval toeslaat? Kun je volledig vertrouwen op je cloudleverancier, of moet je zelf herstelmaatregelen nemen? En hoe verschillen de opties tussen SaaS, PaaS en IaaS? Deze blog behandelt de uitdagingen en keuzes die komen kijken bij Cyber Recovery in de cloud. Het is een aanvulling op mijn eerdere blog over Cyber Recovery en uitbesteding en gaat in op de verantwoordelijkheden die je mogelijk er nog bij neemt, anders dan het bijvoorbeeld het stellen van de juiste contracten- en service levelafspraken. Recente voorbeelden van cyberproblemen (van)uit toeleveringsketens, waar cloudaanbieders ook onderdeel van zijn, tonen de relevantie van dit vraagstuk aan. Te vaag? Denk maar eens aan Blue Yonder dat voor bedrijven als Starbucks en Jumbo even geen softwarediensten kon leveren.
Ben jij voorbereid op een cyberaanval? En hoe zeker ben je dat je kunt herstellen na zo’n aanval? Lees verder >
In deze blog staan we stil bij waarom het niet verstandig is om Cyber Recovery volledig uit te besteden, zelfs als je IT dat wel is. Ook geven we 5 tips over zaken die je écht zelf moet regelen. Lees verder >
In deze blog geven we tips over herstellen na een cyberaanval. Tijd om jouw herstelstrategie onder de loep te nemen. Lees verder >
Wat moet je precies veiligstellen om zo snel en efficiënt mogelijk te herstellen na een cyberaanval? In de vorige blog stonden we stil bij het type informatie. Nu gaan we dieper in op de vorm waarin die informatie is opgeslagen. Lees verder >
Een goede cyber recovery-strategie valt of staat bij de kwaliteit van je tests. Maar wat moet je precies testen en hoe diep moet je gaan? Lees verder
Kun je volledig vertrouwen op je cloudleverancier, of moet je zelf herstelmaatregelen nemen als er een cyberaanval toeslaat? En hoe verschillen de opties tussen SaaS, PaaS en IaaS? Lees verder
On-premise vs. cloud: wat verandert er voor herstel?
In het kader van cyber recovery maakt het absoluut uit welk sourcing model van toepassing is: gaat het om on-premise IT, of public cloud? En als het om (public) cloud gaat, is het dan op basis van IaaS, PaaS of SaaS? De verantwoordelijkheden die bij jou liggen verschillen dan namelijk nogal, zoals ook in onderstaande afbeelding is weergegeven.
Bron: https://www.ncsc.gov.uk/collection/cloud/understanding-cloud-services/cloud-security-shared-responsibility-model
Als je on-premise werkt, heb je volledige controle over je infrastructuur en data. Dit betekent echter ook dat je zelf verantwoordelijk bent voor alle herstelmaatregelen, inclusief back-ups en recovery. De cloud biedt flexibiliteit en schaalbaarheid, maar ook een verschuiving in verantwoordelijkheden. De mate van verantwoordelijkheid hangt af van het gebruikte cloudmodel: SaaS, PaaS of IaaS.
Wie is waarvoor verantwoordelijk? SaaS, PaaS en IaaS
SaaS (Software-as-a-Service)
Bij SaaS-diensten, zoals Microsoft 365 en Salesforce, biedt de leverancier een kant-en-klare oplossing. Je hoeft je geen zorgen te maken over infrastructuur of software-updates, maar je bent wel zelf verantwoordelijk voor het beschermen van je data.
- Voorbeeld: Wat gebeurt er als een storing of ransomware-aanval de SaaS-dienst treft? Kun je je bedrijf draaiende houden zonder toegang tot de applicatie(s)? Hoewel je je data kunt veiligstellen, kunnen workflows, rechtenstructuren en andere applicatie-afhankelijke data verloren gaan. Mogelijk valt je proces daardoor stil en moet je op pen en papier verder.
PaaS (Platform-as-a-Service)
PaaS-oplossingen, zoals Heroku en Google App Engine, bieden meer flexibiliteit, maar leggen ook meer verantwoordelijkheid bij de klant. De leverancier beheert de infrastructuur, maar applicaties, databases en configuraties zijn jouw verantwoordelijkheid.
- Voorbeeld: Als de platforminfrastructuur crasht, kun je je data en applicaties hebben, maar de onderliggende runtime-omgeving ontbreekt. Zijn je applicaties dusdanig ontwikkeld dat ze gemakkelijk in een andere cloudomgeving of zelfs lokaal kunnen worden uitgevoerd?
IaaS (Infrastructure-as-a-Service)
Bij IaaS-oplossingen zoals AWS of Google Cloud krijg je maximale flexibiliteit om je IT-infrastructuur in te richten, van virtuele servers tot alles wat daar op draait.
- Voorbeeld: Wat als een hele regio van je cloudleverancier wordt getroffen door uitval? Het repliceren van je virtuele machines naar een andere regio of zelfs een andere provider kan de sleutel zijn tot een succesvol herstel. Dit vereist echter niet alleen technische voorbereiding, maar ook aandacht voor de bijkomende kosten en licentievoorwaarden.
Het dilemma: vertrouw je je leverancier (genoeg)?
Zoals hierboven al een paar keer beschreven; hetgeen waarvoor je verantwoordelijk bent verschuift op het moment dat je gebruik maakt van cloud – en eigenlijk ook bij IT-dienstverleners in het algemeen. Als het gaat om cyber recovery van hetgeen buiten jouw verantwoordelijkheid valt, wordt het vertrouwen in je IT-dienstverlener mogelijk toch op een weegschaal gelegd: Vertrouw ik volledig op mijn leverancier, wil ik zelf kunnen herstellen, of is er een tussenweg?
- Volledig vertrouwen op de leverancier: Dit is de eenvoudigste optie, waarbij je vertrouwt op de SLA’s en herstelmaatregelen van de provider. Maar hoe zeker ben je dat de leverancier je data en applicaties op tijd herstelt en je niet dagen- of wekenlang met pen en papier verder moet? Zorg ervoor dat je precies weet wat ze wel en niet bieden.
- Zelf back-ups en herstelplannen beheren: Het zelf opslaan van data en configuraties biedt meer controle, maar roept vragen op: Kun je zonder toegang tot de cloudomgeving iets met die data en configuraties? Hoe kom je aan een alternatief voor de cloudomgeving waarin je de data en configuraties kunt toepassen? Heb je voldoende capaciteit en kennis om zo’n herstelplan uit te voeren? Zie dit als een variant op het exit-plan dat je mogelijk al hebt met je IT-dienstverlener maar met de waarschijnlijke afwijking dat je alle maatregelen al klaar hebt staan (“in place” hebt) om zonder inbreng van de IT-dienstverlener het exit-plan uit te voeren. Let wel op: dit kan tot complicaties leiden op het gebied van licenties, intellectueel eigendom, restricties ten aan zien van dataverplaatsing, middleware en/of API’s die wel/niet mogen worden gebruikt, etc. Hoewel een IT-dienstverlener dus mogelijk niet zit te wachten op het laten back-uppen van zijn IT buiten zijn omgeving, is er voor die partij ook een positief punt. Op het moment dat jij een cyber recovery oplossing inricht voor hetgeen de IT-dienstverlener aanbiedt, kun jij ook fungeren als (vertrekpunt voor) cyber recovery van de gehele dienstverlening van de IT-dienstverlener. Jij bent dan als het ware dus zijn cyber recovery-oplossing. De vraag is dan echter: “Wil je dat wel?
- De tussenweg: Waar volledig vertrouwen wellicht te ver gaat, is een tussenweg tussen dit vertrouwen en zelf alles in beheer willen nemen rondom cyber recovery de meest voor de hand liggende keuze. Immers, in het verleden is niet voor niets de keuze gemaakt om naar de cloud te gaan (of uit te besteden). Door juist alles zelf (weer) op je te nemen, doe je de redenen voor uitbesteding grotendeels of zelfs volledig, teniet. Hoewel het ook in dit scenario tot juridische complicaties kan leiden, valt er wel wat te zeggen voor het zo nu en dan (laten) back-uppen van je data naar een omgeving waar jij zelf (ook) toegang tot hebt en zelf volledig in de hand hebt wat er met de back-ups gebeurt. Er valt zelfs iets te zeggen voor het opzetten van een tweede (stand-by, standaard offline) omgeving die met beperkte functionaliteit en grootte. Zo’n omgeving kan de minimaal noodzakelijke procesgang ondersteunen die normaliter door je primaire cloud-dienstverlener wordt ondersteund. De noodzaak voor zo’n omgeving is vrijwel volledig afhankelijk van de noodzaak voor (zeer) snel herstel van procesgang. Er is een risico dat in zo’n omgeving de back-ups van je primaire dienstverlener niet (een op een) ingelezen kunnen worden – logisch, want meestal is het totaal verschillende techniek die wordt toegepast – dus voor (historische) gegevenskritieke processen is dit wellicht niet de optie. En fin, veel keuzes; allemaal met hun voor- en nadelen.
Wat past bij jouw organisatie?
Cyber Recovery in de cloud is geen eenvoudige keuze tussen vertrouwen en controle. Het vereist een balans tussen afhankelijkheid van de leverancier en maatregelen in huis hebben om zelf te kunnen herstellen. Overweeg daarbij de mogelijke technische oplossingen, juridische beperkingen en operationele haalbaarheid om een strategie te ontwikkelen die aansluit bij jouw organisatiebehoeften en risicobereidheid.
Wil je controle of gemak? Kun je vertrouwen op de beloften van je leverancier, of ga je voor zekerheid door middel van een eigen herstelplan? De belangrijkste vraag blijft: Ben je voorbereid op een cyberaanval, ongeacht waar je IT zich bevindt?