Sharing IT Best Practices with youSharing IT Best Practices with you
SaaS Business Continuity Plan
Het Business Continuity Plan is vaak iets dat in de kast staat te verstoffen. Het is geen sexy onderwerp terwijl we met nieuwe applicaties meer lof kunnen oogsten. De invoering van SaaS en Cloud services maakt een grondige herziening van het Business Continuity Plan (BCP) echter noodzakelijk.
Het outsourcen van IT is tegenwoordig de zakelijke realiteit. Helaas komen SaaS providers niet altijd met de garanties die ze zouden moeten geven.
Ongeacht het soort software dat we gebruiken, lopen we het risico op enorme mislukkingen. Daarom moeten we de afhankelijkheid van SaaS leveranciers compenseren met een haalbaar SaaS Business Continuity Plan. Van rampen in het datacenter tot softwareleveranciers die ten onder gaan, de afhankelijkheid van van tools van derden brengt onze dagelijkse activiteiten en winstgevendheid in gevaar.
SaaS aanbieders kunnen een hele goeie indruk achterlaten. Vaak zijn ze innovatief, gebruiken ultramoderne software en de support is geweldig. Iedereen in ons team is verkocht aan de nieuwe SaaS-provider. Besef echter wel dat onze organisatie uiteindelijk enorm afhankelijk van deze SaaS provider is. Een groot aantal van onze gebruikers op het systeem, de investeringen in trainingen, dataconversie enzovoort maken de SaaS provider in een korte tijd een kritische factor.
Het SaaS Business Continuity Plan (SBCP) kunnen we definiëren als een plan om te reageren op noodsituaties, back-up na rampen en herstelactiviteiten. Het BCP maakt deel uit van informatiebeveiliging die de beschikbaarheid van het operationele systeem van het bedrijf in een noodsituatie vergemakkelijkt en verzekert. BCP maakt het mogelijk om het systeem snel terug te brengen naar normale omstandigheden na een ramp of gebeurtenis die de operationele duurzaamheid van het bedrijf verstoort.
Een SaaS Business Continuity Plan is een uitgebreide en gedetailleerde planning vanaf de aanstaande ramp tot het herstel van bedrijfsactiviteiten na de ramp. Het is een compilatie of verzameling van andere plannen zoals:
Het doel van SBCP is om de effecten van rampen of gebeurtenissen die de bedrijfsactiviteiten verstoren te minimaliseren en ook het risico op verliezen te verminderen. Een SBCP heeft ook als doel om de capaciteit van het bedrijf in het herstelproces tegen rampen zo snel mogelijk te verbeteren.
Rampen waarnaar in BCP wordt verwezen, zijn alle gebeurtenissen die zich voordoen en die de normale bedrijfsvoering kunnen verstoren. BCP-rampen bestaan uit twee categorieën, namelijk:
Het is een ramp veroorzaakt door mensen opzettelijk of onopzettelijk. Voorbeelden zoals bommen, sabotage, communicatiestoring , demonstraties, verkeerde configuraties en andere.
Is een ramp veroorzaakt door de natuur. Bijvoorbeeld uitbarstende bergen, aardbevingen, overstromingen, tsunami’s, bliksem, aardverschuivingen en andere.
Kunnen we de volgende vragen over onze SaaS provider en de SaaS oplossing beantwoorden?
Het antwoord op deze vragen stelt ons in staat om samen met ozne SaaS provider een realistisch SaaS Business Continuity Plan op te stellen.
Is er een Businesscase voor een SaaS Business Continuity Plan? Daarvoor hangt alles af van de antwoorden op de volgende vragen:
Een rekensommetje is snel gemaakt.
Het is aan te raden om over ons SaaS Business Continuity Plan te onderhandelen met onze SaaS provider tijdens de eerste gesprekken. De verkoper wil de deal graag sluiten. Misschien lukt dat wel met iets extra’s als een BCP. Profiteer tijdens deze fase van de onderhandelingen van het hefboomeffect door vooraf alles te vragen wat we willen. Zodra de overeenkomst is ondertekend kost al het extra’s meer geld.
Uitbesteden kan altijd leiden tot verwarring tussen de leverancier en de klant met betrekking tot verantwoordelijkheden en aansprakelijkheid. Specificeer dus contractueel welke partij verantwoordelijk is voor het naleven van bepaalde contractregels.
Een goede continuïteitsstrategie is levend en up-to-date. Bedreigingen en risico’s veranderen, dus organisaties moeten hun visie op rampen regelmatig controleren en bijwerken. Er zijn verschillende strategieën om de kansen op overleving te vergroten als bedrijfskritische systemen plotseling in rook opgaan. Hier zijn slechts een paar strategieën:
Gezonde netwerken zijn van vitaal belang voor iedere IT implementatie. Slimmere strategieën kunnen ons SaaS Business Continuity Plan echter ook verbeteren. Als onze leverancier ons de mogelijkheid biedt om onze eigen versie van hun applicatie te hosten, moeten we er op toezien dat het datacenter robuuste strategieën heeft voor back-ups, herstel en risicopreventie.
Bedrijfscontinuïteit draait om het verminderen van de gevolgen van rampen. Als we snel weer aan de slag kunnen omdat onze bronnen gedistribueerd zijn naar verschillende server locaties, heeft een DDoS-aanval misschien minder impact op onze dagelijkse activiteiten.
SaaS draait meestal in de Cloud bij een Cloud provider. Meestal merken we daar niet veel van omdat de SaaS provider zelf een Cloud provider gecontracteerd heeft. In sommige gevallen moeten we het echter zelf regelen. Daarom moet de continuïteitsstrategie ook SaaS migratieplannen bevatten voor het geval we plotseling van cloud provider moeten veranderen. Net als ieder ander servicebedrijf kunnen cloud providers failliet gaan of de prijzen drastisch verhogen.
Zorg er voor dat applicaties en datastructuren provider-neutraal zijn. Dat maakt het een stuk eenvoudiger om van cloud provider te wisselen. Maak een lijst met potentiële providers die voldoen aan de vereisten van de organisatie. Breng ook de kosten voor het verplaatsen van data en het herscholen van personeel op een nieuw systeem in beeld. Zorg ervoor dat de back-up service ook een cloud-onafhankelijke indeling hanteert. Hierdoor hebben we controle over een back-up die hersteld kan worden op een locatie naar keuze.
Dankzij het dupliceren van data en het gebruik van meerdere datacenters is de kans dat een SaaS provider uit de lucht gaat erg klein. Andersom is de kans dat er iets met ons eigen kantoor gebeurt groter. In dat geval zijn de risico’s bij een SaaS oplossing een stuk kleiner omdat we geen serverruimte meer hebben waar alle apparatuur in staat. Tevens zijn de medewerkers niet afhankelijk van de locatie om toch (papierloos) te kunnen werken. Ze kunnen thuis hun werk doen, of in een hotel of vanuit een ander kantoor, zolang er maar internet is. Wat we daarvoor moeten regelen is:
Bij ieder project kan de SaaS Business Continuity Planning het beste in een vroeg stadium worden gedaan. Het overstappen op een SaaS of cloud gebaseerd servicemodel is hier geen uitzondering op. Als er zich een beveiligingscalamiteit voordoet, zullen slechte procedures of slechte training van personeel ongetwijfeld de ernst van de calamiteit verhogen. Tegen de tijd dat we klaar zijn met het verplaatsen van data en SaaS applicaties naar de cloud, moet ons IT-team ook klaar zijn om hun rollen in de algemene beveiligings- en continuïteitsplannen op te pakken.
We moeten elke grote externe provider in onze plannen opnemen als we overstappen op SaaS. Enkele voorbeelden zijn:
Business Continuity Plan (BCP) voor Software as a Service (SaaS) is een must als we kantoren hebben in opkomende markten of op een plek met een zwakke of onvolwaardige internetinfrastructuur. Daar is een grotere kans op uitval die de bedrijfsactiviteiten kan stilleggen.
We moeten constant online te zijn om een SaaS applicatie te kunnen gebruiken. Als bedrijven SaaS willen uitproberen, doen ze dat eerst met niet-kritieke applicaties. Er is geen wondermiddel om SaaS te garanderen te midden van een zwakke internetinfrastructuur. Op locaties met een zwak internet is SaaS Business Continuity Planning een integraal onderdeel van de dagelijkse praktijk.
Organisaties moeten de SLA (Service Level Agreement) niveaus van de provider kennen en vaststellen hoe tolerant hij is in het geval van downtime. Het tolerantieniveau maakt deel uit van het algemene Disaster Recovery (DR) of BCP. De tijdsduur en het serviceniveau waarbinnen een applicatie na onderbreking moet worden hersteld is bepalend voor de duur waarmee we de data moeten bewaren.
De voorgaande strategieën lossen enkele problemen op, maar er kunnen altijd continuïteitproblemen optreden. Om alles uit te sluiten kunnen we escrow-bepalingen met een extern software-escrow-bedrijf in de SLA laten opnemen.
Software escrow is een mechanisme waarbij een onpartijdige derde partij met technische professionals toegang houdt tot de actieve versies van de broncode van de software. Als de leverancier permanent uitvalt, heeft de klant nog steeds toegang tot zijn voorkeursapplicaties.
Hoewel klanten historisch gezien software escrow gebruikten voor applicaties die niet in de cloud zaten, kunnen ze vergelijkbare principes toepassen op SaaS-oplossingen. Sommige SaaS-escrow-aanbieders hebben zelfs rechtstreeks toegang tot SaaS providers, wat hen in staat stelt om escrow aan te bieden als standaard service.
In de escrow overeenkomst moeten providers gehouden worden aan bepaalde verantwoordelijkheden. Ze moeten bijvoorbeeld regelmatig de broncode in de escrow bijwerken en de juistheid en bruikbaarheid van de code moeten periodiek worden getest. Dit geldt ook voor de compileerbaarheid van de code. Dergelijke overeenkomsten zijn vooral belangrijk bij het werken met SaaS-applicaties, die andere risicofactoren hebben dan traditionele software.
SaaS-data escrow is vergelijkbaar met software escrow, maar in plaats van de applicatiecode te behouden, houden derden de data vast die applicaties genereren of gebruiken. Deze vorm van escrow maakt het mogelijk om systemen tot een bepaalde datum compleet te herstellen.
De standaard aanpak voor het evalueren van een continuïteitsplan met een potentiële cloud-SaaS provider moet drie eenvoudige stappen omvatten:
Herstellen bij een andere provider kan, als we over de juiste bronnen beschikken. Alle bestanden, een lijst met tools en ondersteunende documenten, is wat de meeste providers voor een recovery nodig hebben. Met de juiste bronnen kunnen we zonder problemen een andere provider vinden – dat wil zeggen een Managed Service Provider (MSP). Hij kan helpen in tijden van nood.
Om een SaaS Business Continuity Plan effectief te laten werken, moet onze organisatie ten volle rekening houden met de beveiligingsvereisten voor de data die in de cloud worden geplaatst. Denk niet alleen aan minimale hersteltijden en toegang tot de back-up, maar ook aan de eisen vanuit de GDPR. Vervolgens moeten we het de eigen disaster recovery plan van de SaaS provider bekijken om ervoor te zorgen dat deze aansluit op die vereisten. Hou ook rekening met de toekomstplannen van de provider. Deze kunnen van invloed zijn op onze eigen continuïteit en toegang tot data.
Als we data in een ander land worden bewaren, moet er ook rekening worden gehouden met de betrokken internationale en nationale wetgeving. Business Continuity Plannen moeten eventuele nalevingsbeperkingen in de plannen van een cloudprovider dekken. Het verwijderen van data op roulerende back-upmedia kan een van die beperkingen zijn. De GDPR bepaalt bijvoorbeeld dat persoonlijke informatie niet langer dan nodig mag worden bewaard. Deze kunnen op de back-uptapes van een cloudprovider kan blijven staan, mits er een veilig verwijderingsproces is tijdens het restoren van de back-up. Het vereist enige discussie met de provider die ervoor moet zorgen dat alle belangrijke bepalingen worden nagekomen.
Bekijk ook de internetverbinding. Als de onderneming 24 uur per dag en 7 dagen per week toegang moet hebben tot bepaalde data in de cloud, kan een internetstoring desastreus zijn.
De organisatie heeft nauwelijks hardware nodig voor SaaS, maar SaaS moet wel worden behandeld als een uitbreiding van de eigen IT-omgeving. Daarom moet SaaS worden opgenomen in de algemene Business Continuity Strategie. Organisaties moeten de realiteit onder ogen zien en accepteren dat er sprake van downtime op internet kan zijn voor SaaS. Ze moeten de nodige rampenplannen maken.
Hoewel het plan zelf een stuk eenvoudiger wordt, maakt SaaS het maken van een BCP wel moeilijker. Dat komt omdat een derde partij bijna het hele systeem beheert, van de infrastructuur tot de applicatielaag. Bedrijven hebben daardoor minder invloed op de omgeving. Het aanpassen van de applicatie en de onderliggende infrastructuur en optimaal beschikbaar maken voor gebruikers zijn begrensd.
Natuurlijk is geen enkele continuïteitsmethode volkomen vlekkeloos, maar veel gebruikers hebben goede ervaringen met gecombineerde benaderingen. Sommigen vertrouwen op een combinatie van open source en escrow om ervoor te zorgen dat ze de downtime na een ramp kunnen voorkomen. Anderen richten zich op het handhaven van hun eigen interne veiligheidsmaatregelen om de risico’s die hun SaaS-implementaties met zich meebrengen te minimaliseren. Welke benaderingen we ook kiezen, de gebruikers kunnen het beste worden bediend door een SLA die de door hen gekozen strategie ondersteunt.
Het is opvallend dat organisaties soms willen besparen door niet te kiezen voor DR- of BCP-opties die hun SaaS-provider aanbiedt. Dat komt omdat deze optie meestal worden geleverd als add-ons die apart betaald moeten worden. Deze organisaties nemen een enorm risico dat niet te verzekeren is.
Al met al is een SaaS – Cloud oplossing voor business software een stuk veiliger dan een on premise oplossing als we door een SaaS BCP bril kijken. De redenen daarvoor zijn:
Discussieer mee op LinkedIn. 
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.