Business Continuity: Sådan finder I ud af, om jeres cloud-setup er så robust, som I går og tror

Af Kasper Hartvig Hansen, Presales engineer hos ScanNet 

En solid business continuity plan er sindssygt vigtig. Altså en plan for, hvordan I sikrer, at jeres forretning kan køre videre, hvis jeres cloud-arkitektur skulle blive ramt af nedbrud, angreb eller nedlukning.

Når du har læst det her, så er du klogere på, hvad der udgør en god business continuity plan og hvilke spørgsmål I med fordel kan stille jer selv for at blive klogere på, hvor robust jeres setup faktisk er.

Vi kommer ind på:

• De tre elementer i en business continuity plan
• Forstå jeres IT-arkitektur: Spørgsmål I kan stille jer selv 
  • Hvis on premise 
  • Hvis private cloud
  • Hvis public Cloud
• Sådan kortlægger I jeres IT-arkitektur med trusler, krav og løsninger
• Hvordan I tester jeres disaster recovery 
• Eksempler på scenarier og konsekvenser ved forskellige setups
• Skabelon: Kommunikér det videre – til ledelsen
  

Guiden her tager udgangspunkt i, at I allerede har styr på basal IT-sikkerhed som firewall, patching, antivirus, MFA, komplekse adgangskoder osv.

De tre elementer i en business continuity plan

En business continuity plan (BCP) handler grundlæggende om tre ting: 

1. Availability 

2. Backup & Recovery 

Tiltag som sikrer jer imod datatab som følge af slettede/overskrevne filer, menneskelige fejl, nedbrud, hackere, utilfredse medarbejdere med videre. Og ikke mindst evnen til at gendanne disse data.

3. Disaster Recovery

Tiltag som sikrer, at I er i stand til at få jeres forretning online igen. Også når alt, der ikke må gå galt, alligevel går galt. Hvad nu hvis backup’en ikke virker, eller jeres hosting-udbyder ikke er til at få fat i, når alt er nede? DR er jeres beredskabsplan, I kan falde tilbage på, når alt andet fejler.
 

Forstå jeres IT-arkitektur: Spørgsmål I kan stille jer selv

En af de ting vi ofte møder er antagelser omkring sikkerheden i et givent setup. Og når det kommer til business continuity, er der desværre ingen vej udenom det gamle ordsprog “man skal ikke tro, man skal vide”.  

Hvis I selv hoster jeres servere (on premise eller som co-location)

Med en On premise-løsning er det formentlig forholdsvist simpelt. Nogen har bygget miljøet, og bør kunne redegøre for hvordan I er stillet, som minimum i forhold til availability.

Hvad sker der hvis strømmen går? Hvad hvis køleanlægget holder op med at virke? Et defekt bundkort, defekt harddisk osv. Er der serviceaftaler på? Har I de mest gængse reservedele på lager? Kører jeres Virtuelle Maskiner i et cluster, eller ligger de på lokal storage på en enkelt fysisk server? 

Hvis I har jeres data hos en private cloud-udbyder

Private cloud er et rigtig godt udgangspunkt, men øger nødvendigheden af at forstå hvordan tingene er bygget. Hvad I er sikret mod – og hvad I ikke er sikret imod?

En helt almindelig virtuel maskine med 2 CPU, 8 GB RAM og 100 GB harddisk kan leveres på mange måder og til vidt forskellige priser, afhængigt af hvilken arkitektur den er bygget på. Der er ikke noget rigtigt eller forkert, men det er vigtigt at I forstår hvad I har købt, så I kan planlægge efter det.

VPS-servere er for eksempel ofte prisbillige virtuelle maskiner, der er er bygget på relativt billig hardware og med et minimum af indbyggede “availability” tiltag.

Et glimrende valg, hvis man har brug for en server til en hjemmeside, der godt kan tåle at være nede nogle timer, I tilfælde af hardwarefejl, men et katastrofalt valg, hvis man skal drive noget forretningskritisk. Her vil det være bedre med en VM, som kører i et cluster, og som derfor automatisk starter op på anden hardware i løbet af få minutter, hvis f.eks. et bundkort brænder af.  

Hvis jeres leverandør siger at I har en “to-center”-løsning, så skal I være sikre på, hvad det helt konkret betyder.

Er det for eksempel en aktiv/aktiv-løsning, hvor et helt datacenter kan gå offline uden at der sker andet end at jeres VM’er genstarter? Er det SAN-replikering til et andet datacenter? Eller mener de blot at backup’en ligger på en anden lokation?

Det vigtige er, at I forstår jeres availability-politik, og hvad den betyder i praksis.  

Her er en række ting, I kan spørge jeres hosting-leverandør om: 

• Må vi få jeres seneste ISAE3402 og ISAE3000 erklæringer, samt ISO27001 certificering? 

• Er vores servere fysiske eller virtuelle? 

• • Hvis virtuelle:  

• • • Hvilken hypervisor bruges der, og er det et clustered setup? 

• • • Hvilket vCPU:pCPU forhold har vi aktuelt? 

• • • Hvilket N+X niveau er der i clusteret? 

• • • Hvilken clock frekvens er CPU’erne? 

• • • Benyttes der SAN storage? 

• • • Hvilken type? (Tiered, SSD eller NVMe) 

• • • Er der SAN replikering? 

• • • Er der SAN snapshots? 

• • • Har vi Image backup? 

• • • Hvad er retention policy? 

• • • Hvor tit kører backup? 

• • • Gemmes backupdata i et andet datacenter end vores produktion? 

• • • Replikeres data til 3. lokation? 

• • • Har vi agentbaseret backup? 

• • • Hvad er retention policy? 

• • • Hvor tit kører backup? 

• • • Gemmes backupdata i et andet datacenter end vores produktion? 

• • • Replikeres data til 3. lokation? 

• • Hvis fysiske: 

• • • Hvilken model generation af servere? 

• • • Hvilken CPU’er benyttes i vores servere? 

• • • Er der aktive serviceaftaler på alt udstyr? 

• • • Lagerfører I de mest gængse reservedele (f.eks. HDD/SSD, bundkort, CPU, RAM, strømforsyninger)? 

• • • Benyttes SAN storage, eller udelukkende lokal storage? 

• • • Er servermiljøet redundant (f.eks. Load balancere, og clustering)? 

• • Uanset servertype: 

• • • Hvor lang tid er vi nede hvis: 

• • • • En fysisk server crasher? 

• • • • Strømmen går i datacenteret, og kommer igen efter 15 min? 

• • • • Strømmen går i datacenteret, og kommer igen efter 4 timer? 

• • • • Hvis internetforbindelsen til datacenteret bliver gravet over? 

• • • • Hvis datacenteret går op i røg? 

Listen bliver hurtigt lang – og ovenstående er ikke nødvendigvis en udtømmende liste over spørgsmål.  

Det er ikke en kamp mellem amerikansk public cloud og europæisk/dansk private cloud. Det er både og. Det er både private clouds sikkerhed og public clouds skalérbarhed, som tilsammen i et hybrid cloud-setup giver mening for mange virksomehder.

Hvis I benytter en “Public Cloud” udbyder (f.eks. Azure, AWS, Google Cloud, Digital Ocean eller lignende)

Her kan din opgave godt blive lidt sværere, for det er ofte svært bare at sende en mail med spørgsmål. 

Her er det en særligt god ide at være opmærksom på, at public cloud-udbyderne oftest bare “stiller værktøj til rådighed”, men at de betragter det som kundens ansvar at benytte det “korrekt”.

Køber du for eksempel en enkelt VM i Azure, har den en SLA på 99,50%, hvilket ligger markant under markedsstandarden for VM’er i Danmark. Ønsker du en højere SLA, skal du købe to eller flere VM’s i et “Availability Set” og selv bygge et redundant setup i software – for eksempel ved hjælp af et SQL-cluster eller en load balancer foran to webservere.

Begge er gode løsninger, men kræver dels, at I har evnerne til at konfigurere dette korrekt — og at I er opmærksomme på, at netop dët er en forudsætning for, at løsningen betragtes som redundant.

På samme måde er det også kundens eget ansvar at overvåge, at servene er oppe, og at regningen for variable ydelser ikke stikker af.

Public cloud kræver altså mere af jer.

Med den rigtige arkitektur og budget er der basis for at bygge nogle rigtig gode løsninger i en public cloud, men tilsvarende kan manglende omtanke eller forståelse for arkitekturen lede til unødvendigt dyre løsninger med dårlig oppetid. 

Uanset om I har den ene eller anden løsning, eller en “hybrid cloud” der kombinerer flere af dem, er det uhyre væsentligt at I selv tager ejerskab over at forstå løsningen og de svagheder den eventuelt har. 

Kan du redegøre for hvilke tiltag I har gjort, for at sikre jer ift. Business Continuity (Availability, Backup & Recovery og Disaster Recovery)? 

Hvis dit svar på ovenstående inkluderer noget i retning af “Det har vi outsourcet til [indsæt selv leverandør], så det regner jeg med at de har styr på” eller “Det regner jeg med at vores IT-afdeling har styr på”, så skal du i gang med at lege detektiv. 

Sådan kortlægger I jeres IT-arkitektur med trusler, krav og løsninger

Når du ved hvad I gør, skal du have fundet ud af om det er “godt nok”. 

Er der eksterne krav? 

• Er vi underlagt nogle regulatoriske krav? F.eks. finanstilsynet, DORA mv. 

• Myndighedskrav til f.eks. backup af økonomisystem 

Er der nogen trusler — og hvor sandsynlige er de? 

• Kan amerikanerne trække stikket på vores cloud-tjenester?
• Kan strømmen ryge på vores datacenter?

Hvad er ledelsens krav og forventninger? 

• Hvor lang tid forventer I at det tager, fra en hændelse lægger os helt ned, til vi er i fuld produktion igen? (RTO) 

• Hvor meget data kan vi tåle at miste, i det tilfælde? (RPO) 

• Et par timers arbejde? 

• En hel dags arbejde? 

• En uges arbejde? 

• Hvis der skal spares et sted, er der så systemer, afdelinger eller andet, hvor kravene kan slækkes? 

Eksempel på kortlægning

Når først du kender alle jeres “forsvarsværker”, og de krav, som jeres ledelse/bestyrelse stiller, kan du begynde at sammenligne. I første omgang er det en ren skrivebordsøvelse, hvor du kan starte med at udfylde en tabel med de informationer, du er sikker på.

Efterfølgende er opgaven selvfølgelig at få udfyldt de eventuelle ukendte punkter og tjekke, at der sammenhæng mellem de krav der er stilles og de løsninger, som er implementeret. I ovenstående eksempel er backup-planen for filserveren for eksempel mangelfuld i forhold til RPO-kravet. 

Senere kan tabellen udbygges med flere kolonner som gendannelsesprioritet, testfrekvens, seneste test, testscenarier, ansvarlig (internt), kontakt ved nedbrud, kendte risici og lignende.

Husk lige testen! 

Selv de bedst producerede oste har huller — og det samme gælder for selv de mest robuste business continuity planer Det ser vi gang på gang. For ofte er virkeligheden betydeligt mere kompleks end man forestiller sig.

• et glemt flueben...
• et korrupt filsystem ...
• drilske drivere ...

... eller andre uforudsete ting kan kaste grus i selv den mest velsmurte gendannelses-maskine.  

Når først du har lavet skemaet, bør I (det er en fælles opgave) teste de enkelte systemer. Det behøver ikke at være alting på én gang, men start med at vælge ét system (det mest kritiske), og lav en fælles brainstorm over “katastrofescenarier” (ChatGPT er god til brainstorms, bare et lille tip), og vælg så det der virker mest sandsynligt.

Har I en ekstern leverandør på systemet, så tag dem med på råd om, hvordan det gøres bedst, og om hvorvidt det er et realistisk scenarie, I har valgt. 

Når I tester, så tænk det som et rollespil, og sørg for at dokumentere processen.

Dokumentationen skal indeholde: 

• En kort beskrivelse af selve testcasen 

• En kronologisk gennemgang af hændelsesforløbet inkl. Præcise tidspunkter 

• Beskrivelse af alle fejl og uventede ting der skete 

• Hvordan I løste eventuelle problemer 

Når I er færdige, kan i nemt konkludere på om testen var en succes, ved at se på om den levede op til alle kendte krav. Efterfølgende kan du for eksempel. bede din direktion/bestyrelse om at vurdere, om de er tilfredse med resultatet. 

Levede testen ikke op til alle krav, eller kunne den ikke gennemføres, er det stadig en god test. Så kan du nemlig tage den dialog med ledelsen. Er kravene for høje, eller mangler I systemer, timer eller midler, for at leve op til kravene? 

En fejlet test skal selvfølgelig laves om, når man har implementeret foranstaltninger til at sikre at man kan leve op til kravene fra ledelsen. Det er iterativ proces, som godt kan tage lidt tid, særligt i starten, men den er sund, fordi den sikrer at der er helt klare linjer omkring forventningerne fra ledelsen til IT-afdelingen.'

Ingen skal gå rundt med en knude i maven, fordi de frygter et mismatch mellem forventninger og virkelighed. 

Scenarier og eksempler: Hvad sker der, når XYZ mangler? 

Scenarie 1: Webshop på VPS server

Problem:

• Et RAID controller-crash har resulteret i korrupt RAID5. Alle VM’s på hosten er offline.

Konsekvens: 

• Webshoppen er offline – der er ingen svar fra serveren 

• Fejlen indtræf kl. 14:37. Seneste snapshot af serveren er fra kl. 00:13. Over 14 timers data er tabt.  

• Kunder der har bestilt mellem 00:13 og 14:37 har modtaget ordrenumre og -bekræftelser, men der er ingen historik på hvad de indeholder. 

• Ingen in-guest backup af serveren, hvilket betyder at man udelukkende har de natlige snapshots at falde tilbage til. 

• Når shoppen er gendannet fra backup, vil ordrenumrene “blive spolet tilbage” - hvis ikke man husker at tage højde for det -> dobbelte ordrenumre og total forvirring. 

• Udbyderen er i gang med at gendanne VM’s fra backup, men rækkefølgen er tilfældig og restore-tiden er estimeret til ca. 12 timer indtil sidste server er gendannet. 

Løsningsmuligheder 

• Availability: 

• • SAN-storage havde haft markant mindre risiko for datakorruption. 

• • Clustering havde betydet at VM’en blot var bootet på anden hardware og reduceret nedetid til under 5 min. 

• Backup & Recovery: 

• • Agentbaseret backup med hyppigere backupinterval havde reduceret datatabet. 

• • Tier 1 image backup havde givet mulighed for at boote VM’en direkte fra backup storage og reduceret RTO til < 1 time. 

• Disaster Recovery: 

• • Fast replikering af serveren til et sekundært datacenter kunne have minimeret datatab og RTO til < 4 timer. 

Scenarie 2: Produktionsvirksomhed med on premise servere 

Virksomheden kører med lokal serverdrift. Alt fungerer. Indtil ...

Problem:

Køleanlægget går pludselig i stå i uge 28. Serverrummet overopheder, og serverne lukker ned. Kølefirmaet er ferieramte og løsningen tager mindst 24 timer. En ukendt mængde hardware er ødelagt af varmen. 

Konsekvens: 

• Ordrebehandling går i stå. 

• Produktionslinjer må vente. 

• Tabt omsætning og leveranceproblemer. 

• Selv efter køl er re-etableret, kan det tage timer eller måske dage at få fejlsøgt på - og identificeret og erstattet defekt hardware. 

• Potentielt datatab pga. defekte diske eller SAN. 

Løsningsmuligheder: 

• Availability: 

• • Redundant køleanlæg havde afværget problemet. 

• • Aktiv/Aktiv clustering mellem to serverrum havde resulteret i at VM’s blot genstartede i fungerende serverrum -> ca. 5 min nedetid. 

• Backup & Recovery: 

• • Tilstrækkelig backup politik sikrer at datatab er indenfor det acceptable. 

• • RTO er sat ud af spil, da der ikke er tilgængelig hardware at gendanne til. 

• Disaster Recovery: 

• • Replikering af workloads til sekundært site med standby hardware kunne have minimeret nedetid til < 4 timer. 

Scenarie 3: Ransomware i offentlig sektor 

Problem:

Et kommune-netværk bliver kompromitteret. Krypteret. Backups findes – men de ligger på samme netværk og er også låst. 

Konsekvens: 

• Ingen adgang til borgerdata. 

• Pressedækning, panik og konsulenter. 

• Millionregning. 
  
  

Løsning: 

• Immutable backups i skyen. 

• Backup opbevaret i isoleret zone. 

• Regelmæssig test af restore-procedurer. 

Skabelon: Kommunikér det videre – til ledelsen

Den øvrige ledelse behøver ikke kende RPO eller forskellen på single- og multi site. Men de skal forstå konsekvensen. Og være med til at definere, hvor længe I kan tåle nedetid på forskellige systemer. Så hvordan sætter du fut under den samtale?  

Start for eksempel dialogen sådan her: 

• ”Lige nu er vores cloud-arkitektur designet til at håndtere et nedbrud i [indsæt tid], før vi kan være oppe at køre igen. Kan vi undvære de data og systemer i så lang tid?  
  
  

• "Vi kan være oppe igen inden for 2 timer, selv hvis vores primære datacenter brænder ned. Er det acceptabelt?" 
  
  

• "Vi mister maks 1 times data, hvis vores systemer bliver kompromitteret af hackere. Det kan ske ved [indsæt scenarier], så jeg vurderer risikoen som [lille/stor]. Kan vi tåle at undvære de data og systemer så længe? " 
  
  

Måske får du en tommel op. Så ved du, at alle har afstemt forventningerne til nedetid, og du ikke ender med at stå alene i spotlightet, hvis alt går galt. 

Du kan også få et ”nej, så længe kan vi ikke undvære system X”. Nu kan du tænke løsninger og lave en case til ledelsen, som formetlig kræver et par samtaler med jeres cloud-leverandør for at regne helt hjem. Der skal itereres.  

Sådan præsenterer du casen: 

Lav én side, der forklarer casen. Gør det visuelt. Brug jeres egne systemer i eksemplerne. Vis et konkret eksempel, som involverer forretningskritiske data, som bliver gjort utilgængelige. For eksempel under et total nedbrud i datacentret eller et hackerangreb på system 1, 2 eller 3 – eller, hvis det utænkelige skulle ske, et total sammenbrud i samarbejdet med amerikanske cloud-udbydere på grund af den geopolitiske situation.  

• Vis, hvor længe I vil være nede med jeres nuværende løsning  

• Foreslå konkrete ændringer  

• Giv et prisestimat. 

Det kan for eksempel være, at I endnu ikke har en dedikeret disaster recovery, som kan få jer op at køre igen under et total nedbrud. Fortæl, hvad det kræver at få det, og vis, hvordan det ville hjælpe jer i et worst case scenarie. 

Så kan ledelsen vurdere, om det er omkostningerne værd.

Det vil typisk koste 10% ekstra på jeres samlede faktura at få en robust disaster recovery-løsning. 

Det vigtigste at tage med videre

Et robust cloud-setup er ikke én ting. Det er samspillet mellem mange. 

Det er: 

• Backup, der virker og testes. 

• Høj tilgængelighed, der holder systemerne i live. 

• En plan for katastrofer, der er realistisk og afprøvet. 

• Det rigtige mix af private og public cloud i en hybrid-løsning. 

Og det er erkendelsen af, at tingene vil fejle.

Så spørg jer selv: 

• Har vi styr på vores RPO og RTO? 

• Ved vi, hvad der sker, hvis vores database dør kl. 02.34 en tirsdag nat? 

• Har vi testet, hvad der sker, hvis det hele ramler? 

Hvis svaret er ja, er I godt på vej. Hvis ikke – så er det nu, I skal i gang. 

Vil I have sparring? I ScanNet hjælper vi med at drive og designe private cloud-arkitektur, der tager højde for netop jeres virkelighed. For eksempel i kombination med public cloud i et hybrid cloud-setup.