Business Continuity og Cloud

Transkript

1 Business Continuity og Cloud af: Michael Christensen, Certified Business Continuity and IT-security Consultant, CISSP, CSSLP, CISM, CRISC, CCM, CPSA, ISTQB, PRINCE2, COBIT5 For rigtig mange danske virksomheder vil det kunne betales sig at lægge end del af deres IT over i en cloud løsning når talen falder på Business Continuity. Business Continuity er udarbejdelsen af planer og foranstaltninger, der sikrer forretningens overlevelse i krise og katastrofe situationer. Hvad sker der, hvis din internetserver med din webshop fejler, du får besøg af en hacker, dit datacenter eller serverrum bliver ramt af en brand eller en vandskade? Hvor længe kan du fortsætte uden at lide så store tab, der kan true din virksomheds overlevelse. Rigtig mange virksomheder kan i dag ikke fungere uden støtte fra deres IT systemer. Denne afhængighed kan blive fatal for virksomheden, hvis ledelsen ikke planlægger for situationer, hvor IT i en kortere eller længere periode ikke er tilgængeligt. Cloud løsninger kan være med til at give en fornuftig sikring af serverdelen af IT systemerne og infrastrukturen, så driften kan flyttes til cloud, selvom det lokale datacenter er beskadiget eller sat helt ud af drift. Hybrid cloud Ikke alle applikationer egner sig dog til at køre i skyen, da der er en vis svartid, elasticitet, indbygget. Derfor anvender en række virksomheder en blanding af on-premises (lokale) applikationer og cloud services. Herudover vil en række virksomheder kunne høste fordelene af at off-loade (flytte) deres inaktive data til skyen. Inaktive data er de data, der ikke har været rørt ved indenfor en given periode. De aktive data bliver liggende på det lokale datacenter. De inaktive data flyttes til skyen af en særlig enhed, der sørger for udpegning og kryptering af data under både transport og lagring. For brugeren er det transparent. De ser deres filer i deres drev som normalt, men hvis de tilgår en inaktiv fil, så tager det blot lidt længere at 1

2 hente den, da den først skal hentes på nettet, inden den kan åbnes. Filen skifter herefter normalt status til aktiv og placeres igen på det lokale datacenter, indtil den falder for aldersgrænsen. Overførsel af inaktive data til skyen vil i mange tilfælde have en god business case, hvis du ser det i forhold til at udvide lager kapacitet og backup kapacitet i det lokale datacenter. Dette miks af lokale og cloud ressourcer kaldes i daglig tale for hybrid cloud. Grov definition af cloud typer Umiddelbart arbejder vi med tre forskellige typer af cloud modeller kaldet SPI eller Software, Platform og Infrastruktur modellerne (1), (2). Disse modeller har stor betydning for, hvordan Business Continuity skal planlægges, og derfor fortjener de lidt omtale. kontrol over applikationen og eventuelt over forskellige dele af hosting miljøet og forskellige konfigurationer. Cloud Infrastructure as a Service (IaaS) Med IaaS opnår du næsten fuld kontrol over det miljø, som dine applikationer afvikles på. Du får mulighed for at oprette servere, tilknytte lagermedier og styre dele af netværket. Du har mulighed for at loade operativsystemer, oprette firewalls osv. Du har ikke mulighed for at tage kontrol med den underliggende cloud infrastruktur, men du kan for eksempel oprette visser typer af sikkerhed, firewalls, segmentering af netværk, implementering af host baseret intrusion detection og intrusion prevention. Det afhænger af udbyderens platform. Cloud Software as a Service (SaaS) Giver dig mulighed for at afvikle applikationer i clouden. Eksempler på en SaaS applikation kan være en web-mail, et online faktureringssystem eller andre online applikationer. Fælles for dem alle er, at du ser applikationen gennem et tyndt interface, f.eks. en webbrowser. Du har som bruger ikke kontrol over noget af den underliggende infrastruktur eller elementer som servere, netværk eller diske. Du har heller ikke mulighed for at ændre applikationen udenfor det scope, som indstillinger tillader dig. Cloud Platform as a Service (PaaS) PaaS giver dig mulighed for at lægge applikationer ud på en eksisterende cloud infrastruktur. Du har ikke kontrol over de underliggende servere og deres operativsystem, lagermedier eller infrastruktur. Derimod har du Engagement i business continuity Jo længere du går ned mod infrastrukturen, jo flere af business continuity opgaverne overtager du groft sagt selv. Arbejder du med SaaS løsninger, så er løsningen, at du gennem din kontrakt og dine SLA er (service level agreements) skal have styr på business continuity. Arbejder du derimod med IaaS, så er der rigtig mange elementer, du selv skal have styr på, men du skal selvfølgelig også stadig have styr på kontrakterne. 2

3 Det er vigtigt, at du i din kontrakt og dine SLA (service level agreements) har styr på dine RTO og RPO altså recovery time objective og recovery point objective. Det vil sige, at du skal vide hvor lang tid det vil tage at genskabe en given service/datamængde hvor meget data du kan tabe, uden at det gør ondt på din virksomhed. For din virksomhed er det vigtigt at dine cloud services kan opfylde det SDO service delivery objective (3) som virksomheden har. Altså at en række vitale nøgle services er i luften inden for en tidsramme, hvor din virksomhed ikke lider vital skade. Vær opmærksom på, at arbejdet med business continuity ikke er en opgave, der kan løses en gang for alle. Som andre elementer indenfor informations sikkerhed, så er det ikke et projekt, der kan sættes to streger under, men derimod en løbende proces. Dette er også understreget i ISO22301 standarden, der omhandler Business Continuity Management systemer. Umiddelbare anbefalinger Baseret på hvad Cloud Security Alliance skriver (1), så vil jeg gerne give en række anbefalinger omkring Business Continuity og Cloud. 1. Du bør udarbejde et review af kontrakten med din cloud leverandør Cloud Services Provide (CSP). Det er vigtigt at du kender leverandørens forpligtigelser I forhold til business continuity i den service, du køber. Du bør også grave et spadestik dybere, specielt i forhold til lovgivning omkring persondata (2) og sektor krav som PCI-DSS (2), (3). 2. Du bør også udarbejde et review på leverandørens business continuity processer og kigge efter certificeringer. Dette kunne være BS25999, ISO22301, ISO2700x eller PCI. Dette kan være nødvendigt for leverandøren at have, for at du som kunde skal kunne overholde dansk lovgivning eller sektor krav. 3. Du bør overveje, om du kan foretage en vurdering af din CSP ved at foretage en inspektion, hvor dine egne eksperter gennemgår og vurderer de foranstaltninger, som CSP har foretaget for at sikre business continuity. Det vil ofte ikke være muligt at få adgang til alle CSP rent fysisk, men nogle CSP vil dog tillade varslede inspektioner. Mange CSP vil have fået udarbejdet revisorerklæringer, som de anvender til dokumentation af deres arbejde. Disse erklæringer sammen med en eventuel certificering vil i mange tilfælde være tilfredsstillende dokumentation. 4. Du skal sikre dig, at du får meddelelse om resultatet af de forskellige tests, som CSP gennemfører på business continuity og data recovery området. Disse tests skal leve op til de service level agreements (SLA), som er bestemt i kontrakten. 5. Du skal også periodisk sikre dig at: a. CSP opretholder sine certificeringer og har en revisorerklæring, der ikke viser tegn på, at business continuity arbejdet ikke er på plads, 3

4 b. Din SLA med CSP er i overensstemmelse med de behov, som du har lige nu. 6. Du skal sikre dig, at du har udarbejdet de tekniske business continuity planer for at få systemerne i luften igen men at du også har udarbejdet planer for forretningen, som de kan køre efter, hvis IT understøttelsen er væk i en kortere eller længere periode. 7. Du bør også sikre dig mod, at du låses fuldstændigt fast i et proprietært cloud miljø, så du ikke kan komme ud af en kontrakt igen, uden at du skal genopfinde den dybe tallerken. Altså du skal have en exit strategi - inden at du går ind i et engagement med en CSP. Tag beslutninger med åbne øjne Skal du have data og forretningsprocesser ud i skyen, så skal ud tage beslutninger med åbne øjne. Du bør derfor gennemføre en risikovurdering af hele scenariet, inden du igangsætter udflagningen, så du er sikker på, at du ikke udsætter din virksomhed for fare. Dine SLA skal selvfølgelig reflektere dette. Kører du på en løsning, hvor du ikke har de store muligheder på at påvirke business continuity, så må du afgøre om de, CSP tilbyder dig er indenfor din risiko appetit. Jeg har set firmaer, hvor cloud løsninger, taget i anvendelse i dølgsmål, dukkede frem af disen, når vi arbejdede med den tekniske sårbarhedsanalyse. Det har givet røde øre både i forretningen, hos IT og på ledelsesgangen. De fleste gange er det SaaS løsninger som WebMail, kontor applikationer, Dropbox eller andre lagermedier, men jeg har også set forretningskritiske applikationer dukke frem, vel at mærke uden at IT havde kendskab til dem, eller at der var gennemført en risikovurdering. Begrundelsen: IT var for længe om at levere varen, og politikken var ikke klar. Set fra et IT-sikkerheds- og business continuity synspunkt er sådan noget gift, for der ganske sikkert ikke styr på en række væsentlige elementer eller det var der ikke i de fleste af de tilfælde, hvor jeg har opdaget dem. Virksomheden pådrog sig en risiko, som ikke var acceptabel. Individuel vurdering I den sidste ende, så kommer business continuity indsatsen til at afhænge af behovene i din virksomhed, altså en fuldstændig individuel vurdering. Jeg vil dog anbefale, at du ser på sagen gennem en af de etablerede standarder på markedet. Det kunne for eksempel være COBIT5 (6), som har et afsnit omkring informations sikkerhed. Du må ikke sætte dig i en situation, hvor beslutningen om at bruge cloud bliver truffet nede i forretningen. Derfor skal alle beslutninger være aktive, støttet af ledelsen. Det skal stå lysende klart i organisationen, hvordan beslutninger omkring anskaffelser skal tages; for Cloud er en anskaffelse. De nødvendige politikker og regler skal understøtte det. 4

5 Referencer 1. CSA. Security Guidance for Critical Areas of Focus in Cloud Computing V3.0. [Online] [Citeret: ] ity-guidance-for-critical-areas-of-focus-in-cloudcomputing-v3/. 2. ENISA. Cloud Computing - Benefits, risks and recommendations for information security. s.l. : ENISA, ISACA. CISM Review Manual s.l. : ISACA, Datatilsynet. Sammenskrevet udgave af persondataloven. [Online] [Cited: 02 17, 2014.] aloven/. 5. PCI Security Standards Council. PCI SSC Data Security Standards Overview (PCI-DSS). [Online] [Cited: 04 27, 2014.] tandards/. 6. PCI. Information Supplement: PCI DSS Cloud Computing Guidelines. [Online] [Citeret: ] DSS_v2_Cloud_Guidelines.pdf. 7. ISACA. COBIT5 for Information Security. s.l. : ISACA, Forkortelser 1. CSP Cloud Service Provider. Din leverandør af cloud services. 2. RPO Recovery Point Objective. Hvor meget data må du tabe, hvis du får et nedbrud. Hvor ofte er du så nødt til at tage backup. 3. RTO Recovery Time Objective. Hvor lang tid må det tage før data skal være i luften igen efter et nedbrud, når de skal hentes fra backup systemet. 4. SDO Service Delivery Objective. Hvilke systemer skal være i luften, før virksomheden ikke lider skade og hvornår. 5. SLA Service Level Agreement. En aftale om, hvilke services der leveres, hvordan de måles og hvornår godt nok er godt nok. Forfatteren: Michael Christensen har arbejde som IT-professionel siden 1985, heraf 11 år som ansat i den finansielle sektor. I 2011 startede Michael sit eget konsulentfirma, inhouse Security, som har speciale i Informationssikkerhed og Business Continuity Management. Michael har en række internationalt anderkendte certificeringer omkring informationssikkerhed, projektledelse og governance i sin portefølje: CISSP, CSSLP, CISM, CRISC, CCM, CCSK, CPSA, ISTQB, PRINCE2 og COBIT5 5