Spring til login

Digitaliser.dk

Sektioner

Aktuel side

Gruppens profilbillede

Cloud computing i Danmark

276 medlemmer | Medlemsskab via fri tilmelding (Bliv medlem - kræver login )
Profilens billede

RISIKOVURDERING – Risiko og Cloud Computing

Klaus Agnoletti - 18.08.2009

Den afgørende forskel er, som jeg ser det, at det er mere komplekst at outsource til en cloud computing leverandør.

 

Der er flere faktorer der skal tages stilling til, og flere risici der skal afdækkes. Derfor vil det være en større risiko at outsource til en cloud computing leverandør end til en mere traditionel outsourcing leverandør der hoster virksomhedens servere i sit eget, dedikerede serverrum.

 

Inden valget om en cloud computing baseret outsourcing leverandør tages, er det vigtigt at alle væsentlige risici afdækkes og undersøges, og at disse vurderes i forhold til den beregnede besparelse.

 

De vigtigste forhold der efter min vurdering skal undersøges er:

  • Dataadskillelse fra andre kunder. Her kan kryptering være en del af løsningen. Der bør dog også være en form for logisk netværksadskillelse til andre kunder. Få leverandøren til at levere en revisionserklæring på datadskillelsen hvis du kan, og du virkeligt vil være sikker på at kun du har adgang til dine data.
  • Kryptering. Alle data i clouden skal være krypteret, og ligeledes trafikken til og fra clouden. Få leverandøren til at levere dokumentation for at krypteringsmetoden er anerkendt og testet af specialister på området, og at leverandøren følger anerkendte principper og procedurer for nøglehåndtering.
  • Disaster recovery. Leverandøren skal dokumentere at de har en plan og procedurer for disaster recovery, og at disse er implementeret, således at du som kunde påvirkes mindst muligt af uheld hos leverandøren.
  • Compliance i relation til DS484 - og virksomhedens egen IT-sikkerhedspolitik. Sikkerheden og integriteten i de data der ligger i skyen er ultimativt dit eget ansvar. Derfor bør man sikre sig at der foreligger en revisionserklæring på at leverandørens procedurer og forretningsgange overholder de sikkerhedsstandarder og politikker som virksomheden selv skal overholde, eller vurder om disse eventuelt skal justeres i forhold til hvad der er realistisk at forlange af sin leverandør.
  • Datas placering. Ved en global leverandør af cloud computing med en kompleks infrastruktur, som Google eller Amazon, kan der herske usikkerhed om hvor præcist dine data befinder sig rent fysisk. Det har betydning fordi der er forskel på de enkelte landes og regioners krav til datahåndtering. Få derfor en erklæring fra leverandøren om at dansk lov opretholdes, og at data opbevares fysisk på servere indenfor EU hvis dette påkræves.

 

Ovenstående liste er ikke komplet, og risici er nævnt i tilfældig rækkefølge.

 

Valget om det overhovedet er en god idé at outsource til en cloud computing baseret leverandør - og ikke mindst hvilken - er et meget komplekst valg der kræver en grunding analyse af en lang række information. Denne bør efter vores vurdering ikke tages uden alle risici er belyst.

 

Netop cloud computing og sikkerhed vil blive diskuteret ved næste møde i OWASP-DK (http://www.owasp.dk) i morgen d. 19/8 kl 17.30 ved Deloitte. Mødet er gratis, tilmelding skal dog ske snarest muligt til Vikie på vjohnsen@deloitte.dk af hensyn til forplejning.

 

Har du erfaring med cloud computing og har været igennem risikovurderingen - eller har du en mening, så hold dig ikke tilbage.

Sæt/fjern bogmærke
+2

Kommentarer (19)

Profilens billede 1
Stephan Engberg - 19.08.2009

"Mine data"? - Du har vidst fået ejerskabet galt her. Personhenførbare data tilhører borgeren - med god grund.

 

Som jeg læser listen (der i sig selv er glimrende), så er det mest karakteristiske at den overser det risikokoblende element. De fleste data tilhører ikke beslutningstagerne hvis der er tale om data om andre fordi de udgør en risiko for andre.

Vi er vidne til den samme type kobling af risici som gjorde finanskrisen så voldsom. Når det går galt går det rigtigt galt i stor skala. Det er uansvarligt hvis man ikke sørger for at isolere risikoen og det dækker denne liste IKKE - den afspejler en blind tro på at risikoen kan håndteres med aftaler uden indhold. Den overser samtidig at interessen i misbrug er voksende.

Bankerne troede også at de kunne outsource kundeservice indtil kriminaliteten via f.eks. salg af kundedata eskalerede. og det er den mildeste type af problemer her.

Hele denne lemminge-jagt på Cloud er stærkt præget af grådighed uden ansvarlighed eller omtanke.

Sæt/fjern bogmærke
-3
Profilens billede 2
Stephan Engberg - 19.08.2009

Indlægget erkender at risikovurderingen ikke er afdækket med dette - alt ros for det.

Med overgangen til Cloud - og iøvrigt også med ambient computing som vi f.eks. så med RFID og EPCGlobal påvisning af at dårligt designet ambient er en slags meta-cloud - bryder det såkaldte Walled Fortress paradigme sammen.

Vi kan ikke længere basere sikkerhed på at beskytte hemmeligheder i åbne systemer. Man er ganske enkelt nødtvunget til at skifte til modeller hvor man designer sikkerhed ind i bunden, dvs. hvor man fjerner sårbarheden.

I de fleste tilfælde kan det klares ved at sikre at henførbarheden ikke kommer ind i systemet - hvilket ikke er simpelt, men kan håndteres med overblik og rettidig omhu.

Truslen er at pseudo-risikovurderinger og mere udokumenteret misbrug af "proportionalitets"-argumentet blot presser de kortsigtede interesser igennem på bekostning af en hastigt voksende sårbarhed og typisk også - som vi f.eks. ser med Google og PBS - skævvridning af markedsdannelsen.

Som vi allerede har været vidne til over de sidste 10-15 år er den kortsigtede teknologideterminisme en enorm trussel mod samfundet.

Sæt/fjern bogmærke
-1
Profilens billede 3
Søren Peter Nielsen - 19.08.2009 modereret af Søren Peter Nielsen (19.08.2009)

Hej Klaus – Når jeg spekulerer over risici som får en ændret vægt i forbindelse med Cloud computing dukker nogle af dem du nævner op, men fx. også

  • Migreringsomkostninger – Det er fint at mine data er adskilte og krypterede hos udbyderen, men an jeg i det hele taget få mine data igen på en praktisk anvendelig måde? – og hvis jeg kan hvor vil jeg kunne migrere hen? Hvad er muligheden for at skifte i mellem forskellige Cloud-udbydere?
  • Kontrakt/tilslutningsaftale – Et argument er at lave priser ved Cloud computing forudsætter standardiserede tilslutningvilkår og SLA'er. Hvis der mangler ting i SLA'en hvad kan man kompensere for på anden vis – og hvor er der de største konsekvenser ved mangler i SLA'en
  • Netværksinfrastruktur – Cloud computing forudsætter en robust og hurtig netforbindelse. Hvor god er din netværkforbindelse til de steder hvor din Cloud computing leveres fra?

Jeg kunne godt tænke mig dit bud på hvordan du overordnet vægter disse i forhold til de risici du allerede har nævnt?

/Søren P

 

Sæt/fjern bogmærke
+3
Profilens billede 4
Klaus Agnoletti - 19.08.2009

@Stefan

Jeg ville rigtigt gerne svare noget konstruktivt til din kommentar, men jeg forstår ikke rigtigt hvad du mener og hvor du vil hen med det. Vil du ikke uddybe det lidt for mig?

 

@Søren Peter

Du har lige ramt de ting jeg tænkte på, men ikke lige fik med i mit oplæg.

Migreringsomkostninger:

Som det er nu, er det en væsentlig risiko at de forskellige leverandører ikke kan tale sammen og ikke bruger et standardiseret API - Cloud computing er en relativt ny ting og der er ingen fastlagte standarder på området. Man risikerer i værste fald at være bundet til én leverandør man ikke kan skifte fra uden det bliver rigtigt dyrt.

 

SLA:

Det er klart at SLA er meget vigtig. Jeg har lidt svært ved umiddelbart at se hvad man kan gøre ved en SLA der ikke er god nok - andet end at forsøge at forhandle en der er bedre..

Netværksinfrastruktur:

Uanset hvilken outsourcing levarandør man vælger, er det nødvendigt med en god netværksforbindelse til leverandøren. Det er klart at det er en risiko hvis forbindelsen går ned og ens virksomhed står stille. Typisk imødekommer man denne risiko med redundant internet forbindelse ved to forskellige udbydere. Eller flere hvis det er en meget væsentlig risiko.

 

Den største af de risici du nævner, er efter min mening SLA. De andre er naturligvis også vigtige - den indbyrdes vigtighed afhænger af lokale forhold, så netværksinfrastruktur kan godt gå hen og blive vigtig, afhængigt af hvor vigtig en del af infrastrukturen der lægges ud.

Jeg er ikke sikker på at risikoen for at være låst til en enkelt leverandør er så stor. Godt nok er risikoen reel, men jeg tror også på at de forskellige leverandører vil udvikle værktøjer der kan hjælpe med at skifte leverandør. Det er der jo en vis økonomisk interesse i.

 

/klaus

 

Sæt/fjern bogmærke
+2
Profilens billede 5
Stephan Engberg - 20.08.2009

Klaus

Hvad skal jeg uddybe?

Cloud er klart brugbart og en del af fremtiden, men er reelt så tæt på online man kan komme, dvs. du kan IKKE antage isolering. Den eneste måde at sikre et cloud system er IKKE at lægge risikoen ind i Cloud. Så langt er vi vel stort set enige.

Men jeg synes du dokumenterer problemet glimrende andetssteds ved at kalde email et lav-risiko område. email (og tilsvarende) er formentligt vores mest sårbare aspekt og absolut ikke noget som på noget tidspunkt kan flyttes til cloud.

At folk gør det med gmail etc. er reelt blot udtryk for en dårlig risikoevaluering hvor man ikke ser skaderne. F.eks. blotlægges en virksomhed nærmest fuldstændigt hvis medarbejderne bruger gmail som de fleste virksomheder gør det.

Risikoen er at din tilgang her vil ende i pseudo-risiko evalueringer som kun ender i en art complience forklædt som sikkerhedsvurderiger. Det største problem er at man groft undervurderer risikoen ved kundedata og andre partnerdata men det gælder også forretningshemmeligheder generelt.

Selvfølgelig kan man lave interne pseudo-clouds, men det er dels noget andet og dels er det i det bredere perspektiv ikke mere sikkert at lægge noget på "intranettet".

Ovenstående passer selvfølgelig ikke de kommercielle udbydere af clouds eller de service providers som gerne vil springer over hvor gærdet er for lavt. Men principielt som samfund og med blot et minimum af rettidig omhu i vurderingerne må vi insistere her.

Løsningen på alt dette er efter min mening efter Open Metropolic princippet at virtualisere alle entiteter UDENFOR cloud, dvs. rent principielt sikre revokation af data ved at låse data til den kontekst som blotlægges i cloud-systemet.

 

 

 

 

Profilens billede 6
Stephan Engberg - 20.08.2009

Søren, Klaus

Data er ikke "krypterede og adskilte" hos cloud-provider hvis cloud-provideren kontrollerer nøglerne.

Der er alt for meget forsøg på at legitimisere midlerne ved at påstår at målet berettiger alt. I stedet må man gå tilbage og justere ens opfattelse af målet.

 

 

Profilens billede 7
Stephan Engberg - 20.08.2009

Rent principielt bør man vende spørgsmålet rundt.

I takt med at virksomheder og offentlige institutioner outsource drift af systemer kan man ikke længere sikkerhedsmæssigt bruge "tillid" til noget, fordi du ikke aner hvem du interagerer med. Og man interagerer med mange flere end man tror. Hele "samtykke" perspektivet bryder sammen.

Som direkte konsekvens af den stærkt forøgede risiko er man derfor nødt til at flytte kontrollen tættere til slutkunden / slutbrugeren så man ikke behøver have tillid til den som udbyder servicen. Dvs. i den sammenhæng sikre at der slet ikke kan skabes personhenførbare data hos serviceudbyder som dermed ikke skalerer risici ukontrolabelt hvis de oursources eller lægges i cloud.

Det har altid været god latin og lovpligtigt at minimere risikoen for borgeren, men nu er det i stigende grad samfundskritisk.

Profilens billede 8
Camilla Grynnerup Fisker - 20.08.2009

Som jeg ser det er mange af de nævnte risici er ikke nogen som gælder specielt for cloud, men er noget som også skal undersøges ved traditionel outsourcing - spørgsmålet er blot om risikoen er større eller mindre i forhold til løsningerne vi benytter i dag.

Desuden vil jeg også nævne en anden relevant debat omkring risiko, som også er interessant læsning http://www.version2.dk/artikel/11825-er-der-nogen-risiko-ved-cloud-computing 

Jeg synes at det kunne være interessant at høre nogle meninger om hvordan DS 484 passer på cloud? 

Profilens billede 9
Stephan Engberg - 20.08.2009

Helt enig - risici vokser eksponentielt via alle former for digital integration. Alene for opretholde status quo skal man systematisk reducere og isolere risici. Man gør det stik modsatte. Men det betyder at systemer som før var isolerede og relativt sikre i morgen er langt mere sårbare og risikoskabende.

DS484 skaber nok complience formelt men giver ikke sikkerhed reelt. Et af de tunge problemer at evalueringen af risiko skrider med interessen og herunder specielt at man undervurderer andres risici og overvurdere tilliden til en selv. Man kan sige at prisen på risiko falder mens konsekvensen når det går galt stiger.

Det er på mange måder fuldstændigt parallelt med det som gik galt i Finanskrisen. Man blev grådige på risici fordi man kunstigt troede at man kunne ændre risiko/afkast ratioen ved at restrukture den (f.eks. lave noget pseudo-sikkerhed a la SLA). Reelt skete der det at man fik risikoforstoppelse og det som startede som en lille usandsynlig risiko med lille konsekvens pludselig blev til vished grænsende sansynligt og konsekvensen blev enorm.

Hvis man vil Cloud skal man have MEGET bedre sikkerhed end i dag ville være kravet ved en almindelige outsourcing. Foreløbig er grådigheden på risiko blot eksponentielt voksende -  nu endda til det niveau hvor nogen kalder email for en lav-risiko applikation, at man bilder sig selv ind at "borgerne er ligeglade" og man i typisk nysprog-stil omdefinere overvågning til sikkerhed og kalder Danid of Nemid istedet for at rette op på lovløsheden.

 

 

Profilens billede 10
Klaus Agnoletti - 20.08.2009

Hej Stefan,

Som jeg har uddybet andetsteds så KAN mail være et lav-risiko område og noget der kan cloudsources nemt hvis det er tilfældet. At du kan komme på tilfælde hvor mail måske ikke er et lavrisiko område er blot et bevis på hvorfor vi overhovedet laver en risikovurdering : at virksomheder/myndigheder, deres behov og risici er forskellige. Og cloud computing kan være en fornuftig ting for de dele af ens drift der ikke er for stor en risiko.

 

/k

Profilens billede 11
Stephan Engberg - 20.08.2009

Du mener på samme måde som nogen mener at kunne forsvare at skolebørn bruger Gmail?

Min opfattelse er at denne tilgang til sikkerhed reducerer det til pr markedsføring og tilpasning af virkeligheden til særinteressen. Det er selve årsagen til at sikkerhed er i en så elendig forfatning som det er tilfældet og hvorfor den kontinuert forværres.

 

Profilens billede 12
Stephan Engberg - 20.08.2009

For lige at sætte det i presketiv - medmidnre man aktivt designer infrastrukturen med udgangspunkt i helt basale borgerrettigheder og samfundspricnipper så er Cloud misbrug a la dette

http://www.comon.dk/nyheder/Google-gar-i-koedet-pa-teleselskaberne-1.239618.html

Du skal IKKE have "et telefonnummer resten af livet" som bruges til at sætte sig på og etablere kontrol over dig - tværtimod skal du den stik modsatte vej og eliminere det misbrug og interesser som ligger bag sådanne tiltag.

Sæt/fjern bogmærke
-1
Profilens billede 13
Lars Thomsen - 21.08.2009

Hej Camilla

 

Du spørger til meninger om DS 484 og Cloud Computing. Man kan godt overholde kravene fra DS 484 samtidig med at man anvender cloud, men det kræver selvfølgelig, at man er bevidst om de udfordringer man stor over for.

 

Første og fremmest skal man altid foretage en risikovurdering og i den vurdering skal man være opmærksom på at data kan ændre vigtighed og følsomhed over tid. Det kan f.eks. være svært per automatik at klassificere mail som ukritisk, da man jo aldrig ved hvad andre sender til en. Eller finansdata, der før offentliggørelse af regnskabet skal holdes fortrolige, men efter skal være fuldt tilgængelige. Man skal også gøre sig klart om man skal bruge clouden til lagring eller behandling af data eller måske begge dele. I risikovurderingen skal man også tage høje for at man ved at anvende cloud computing sætter sin lid til internettet som transportmedie – og hvor robust er din internetforbindelse?

 

En anden central del af DS 484 krav, i cloud perspektiv, er kravene der handler om brugen af eksterne serviceleverandører og samarbejdsparter. Her kan det gå hen og blive ganske omfattende, hvis man skal risikovurdere, indgå aftaler med, reviderer osv. alle de eksterne parter man anvender i clouden.

 

Der er andre dele af standarden der også kommer til at spille ind hvis man går i skyen, men jeg skal ikke trætte med en lang liste. Men standard alene gør det ikke, DS 484 er et værktøj, en liste af kontroller, der skal sikre at en organisation arbejder systematisk og effektivt med informationssikkerhed og der igennem markant øge sandsynligheden for at man sikre sig tilstrækkeligt.

 

Til slut kan jeg lige tilføje at den standard, der ligger til grund for DS 484, er under revision i ISO regi. Jeg ved at man i den nye version vil forsøge at indføje elementer der bl.a. adressere cloud computing.

Profilens billede 14
Stephan Engberg - 22.08.2009

Lars

Din indlæg påviser svagheden ved DS484. Den siger blot at man skal vurdere risici (i sig selv glimrende), men f.eks. i forbindelse med Cloud skal man blot evaluere "eksterne serviceleverandører og samarbejdsparter", hvilket er en helt umulig opgave.

DS484 er i praksis IKKE et værktøj til at designe sikkerhed IND I eller MED applikationen, dvs. det bliver til en security plug-on øvelse som tager teknologien og applikationen for givet.

Dermed ender DS484 øvelser i at man nedrangerer risici efter interessen i stedet for at redesigne efter behovet. Det tjener kun til at placere ansvar, men giver ikke tilstrækkeligt sikre systemer.

Ellers ville man jo aldrig kunne se de mange og alvorlige fejl som begås i Digital Forvaltning fordi interessen overvender behovet og retten. Eksemplificeret med NemIds mange sikkerhedsproblemer som VTU end ikke havde legal hjemmel til at sanktionere som Digital Signatur, dvs. sikkerhedsanalysen i henhold til DS484 er åbenlyst utilstrækkelig selvom man formelt i bureaukratiet misbruger det som undskyldning for at man har taget hensyn til sikkerhed.

 

Et hovedproblem med DS484 er at den ikke tager udgangspunkt i borgeren som samfundets vigtigste aktiv - og data om borgeren som samfundets mest sårbarhedsskabende problem. Den fungerer i praksis ikke og fører ikke til redesign når risici er for store.

Dvs. DS484 kan misbruges til at påstå legal complience om dårligt designede systemer, men giver kun marginal  validering af og nærmest slet ikke hjælp til at redesigne  sikkerhedsmodellen. DS484 fejler allerede med de nuværende systemer og vil slet ikke kunne sikre Cloud.

Clous baserer sig kun på ren perimetersikkerhed og den forsvinder, dvs. du er nødt til selv at tage ansvaret for at designe sikkerheden ind i applikationen som IKKE antager at Cloud-sikkerheden er noget værd.

Profilens billede 15
Camilla Grynnerup Fisker - 27.08.2009 modereret af Camilla Grynnerup Fisker (27.08.2009)

CSA (Cloud Security Alliance) er en non-profit organisation som arbejder for at fremme sikkerhed i clouden. De har udgivet en rapport som lister de overordnede områder angående risiko og sikkerhed som skal håndteres i forbindelse med riskovurdering og sikkerhedsoptimering. Samtidig kommer de med deres bud på en "checkliste" for at sikre sikkerhed i clouden.

http://www.cloudsecurityalliance.org/csaguide.pdf

Diverse relevante links angående cloud og risikovurdering er samlet ressourcen: "Risikovurdering - relevante links" 

http://digitaliser.dk/resource/388867

Profilens billede 16
Stephan Engberg - 27.08.2009

Camilla

Cloud Alliancen er aldeles ikke non-profit. Det er blot en kartel-pulje for kommercielle partnere som ikke i sig selv skal tjene penge. De kan som i de fleste tilsvarende tekniske kartelkonstruktioner blive enige om en ting - kontrollen skal ligge i Cloud/hos gatekeeperen.

Se på deres identity Management afsnit, hvor det træder fuldt frem. I stedet for bevidst at opretholde separation og isolering (som den eneste mekanisme jeg kender til at sikre online cloud), så agiterer de får at man skal overlade kontrollen til cloud-strukturen og sikre federation på tværs - nej, det er præcis det som man ikke skal eller må hvis cloud sikkerhed skal give mening.

Problemet i denne diskussion er som så ofte set før at man forsøger at presse en fejldesignet teknologi igennem med en kortsigtet agenda uden at gøre hvad det kræver. Det er ikke anderledes end den process som skabte klimaproblemerne og som vi nu står i problemer til halsen for at rydde op i.

 

Sæt/fjern bogmærke
-1
Profilens billede 17
Carsten Jørgensen - 14.09.2009

Her melder ENISA - EU's Network and Information Security Agency - sig ind i Cloud Security Alliance :
http://enisa.europa.eu/pages/02_03_news_2009_09_07_csa_affiliation.html

Profilens billede 18
Carsten Jørgensen - 14.09.2009

Nedenstående er primært en re-post fra http://www.computerworld.dk/blog/itsikkerhed/1955 og http://www.cloudsecurity.dk/risikovurderingen/ :

Jeg mener teknikkerne til at vurderer sikkerheden i en Cloud løsning i praksis er stort set identiske med ”almindelige” løsninger.

Data klassifikation
Selvom data klassifikationen er et af de områder man oftest springer over i sikkerhedsarbejdet er det en kritisk opgave i forbindelse med Cloud Computing.

Første skridt i risikovurderingen bør altid være at klassificere den data og de forretningsprocesser, der indgår i den løsning man overvejer at Cloudsource (outsource til en Cloud-leverandør). Der findes en række forskellige teknikker til at indsamle og klassificere informationen, som jeg ikke vil komme nærmere ind på her.

Afklaringerne fra dataklassifikationen bruges efterfølgende i risikovurderingen. Og jo mere kritisk den applikation eller de data man overvejer at lægge ud i Skyen er, jo flere krav skal man selvfølgelig efterfølgende stille, før en potentiel Cloud-løsning er sikkerhedsmæssigt acceptabel.

Risikovurdering
Spørgsmål man bør starte med at stille kan f.eks. være

1. Er vi underlagt lovkrav?
Hvis man er underlagt f.eks. Persondatalovgivningen eller Bogføringslovgivningen giver det selvfølgelig en række krav, der skal kunne håndteres af en mulig løsning.

2. Er der compliance hensyn at tage hensyn til?
Hvis relevant giver SOX, Euro-SOX, PCI osv en række andre krav, der skal kunne adresseres af den valgte løsning.

3. Hvilken sikkerhedsmodel benytter vi normalt?
DS484/ISO 27002 osv giver input til krav om bl.a. beredskabsplaner og håndtering af sikkerhedshændelser, både internt og hos den potentielle leverandør.

 4. Vurdering af Cloud-løsningen på baggrund af SPI-aaS:

 http://www.cloudsecurity.dk/pics/UdfoldetStabel.png

SPI-modellen ovenfor er meget effektiv til at afklare hvilke sikkerhedsområder der skal fokuseres på for en specifik Cloud-løsning. Herunder hvilke områder leverandøren har ansvar for, hvordan de håndteres - og hvad det forventes, at man selv håndterer.

I en PaaS-løsning skal man f.eks. måske selv sørge for alle sikkerhedsopdateringer, mens man normalt aldrig har mulighed for at opdatere noget - overhovedet - i en SaaS-løsning.

Lad os se på eksempler på de forskellige niveauer:

a) Infrastruktur

Afhængig af hvor kritisk den proces, applikationen eller data man overvejer at ligge ud i Skyen er, kan man f.eks. se nærmere på følgende hovedområder for en IaaS-løsning.

Den fysiske placering af datacenter
Persondataloven eller bekymringer om lokale lovkrav, f.eks. risiko for electronic discovery, eller at udenlandske regeringer udleverer materiale til lokale konkurrenter kan påvirke krav til hvor et datacenter kan være fysisk placeret.

Nogle Cloud-leverandører giver mulighed for at vælge regioner eller ligefrem specifikke datacentre som kunden kan ønske at bruge. Hvis placeringen er meget kritisk bør man nærlæse kontrakten for at bestemme leverandørens mulighed for at flytte data til andre datacentre.
Vær opmærksom på teknikker som VMotion/XenMotion, der gør det muligt at flytte virtuelle maskiner mellem forskellige datacentre.

Fysisk sikring af datacenter
Det er muligt at undersøge og vurderer alle standard kravene til et datacenter: skalsikring, overvågning - fra vagter og kamera til alarmsystemer, adgangskontrol, hvordan adgang er begrænset osv.

Hardware
Hvilken form for hardware bruger leverandøren, er der etableret (tilstrækkelig) logning, hvor meget adgang til logs er muligt. Er der etableret kryptering på netværksniveau, hvordan er krypteringen implementeret osv.

Netværk
Eksempler på områder der kan overvejes er bl.a. hvordan netværket er segmenteret, hvordan bruges firewalls og VLAN? Er beskyttelse imod DDoS (ude-af-drift angreb) standard.

b) Platform as a Service

Hvis den Cloud-løsning man overvejer også inkluderer platformen, f.eks. "Database as a Service", bør håndteringen af hele system management området også vurderes. Hvordan håndteres f.eks. patch management og configuration management? Hvad med overvågning, identity management osv.
 

c) Software as a Service

I SaaS-løsninger styres alle de underliggende IaaS- og PaaS systemer og processer af leverandøren. Og hvis man mener, at sikkerheden er utilstrækkelig har man, som nævnt, ofte kun meget begrænset mulighed for at bygge ekstra sikkerhed ind i løsningen.

Alle de underlæggende områder kan være relevante at spørge ind til. Derudover er der to ekstra hovedområder man bør fokuserer på i en SaaS-løsning: data og applikationerne.

Data
Hvordan beskyttes data - og er beskyttelsen tilstrækkelig i forhold til risikovurderingen og dataklassifikationen.

Er kryptering etableret eller måske endda standard, hvordan er krypteringen implementeret og ikke mindst hvordan er nøglehåndteringen. Hvilke muligheder for overvågning er tilgængelige, og hvordan integrerer kontrollerne med vores etablerede systemer.

Kan leverandøren oplyse hvordan de klassificerer data, gemmes al data som flade filer eller har kunden mulighed for at styre adgangen til specifik data, kan data f.eks. beskyttes imod adgang fra administratorer?

Applikationer
Hvordan har Cloud-leverandøren sikret applikationen, hvilken udviklingsmodel benyttes, har man mulighed for selv at teste sikkerheden eller er det direkte forbudt. Giver applikationen mulighed for at ændre på sikkerhedsparametre, f.eks. styrke krav til passwords.

Har applikationen indbygget beskyttelse imod almindelige webapplikation angreb som XSS?
 

5. Cloud-specifikke trusler

Teknikkerne i risikovurderingen er - næsten - fuldstændig de samme som udenfor Skyen. Men der er selvfølgelig nogle nye områder og nogle områder man bør fokuserer særligt på indenfor Cloud Computing.

Så for at lave en komplet vurdering af sikkerheden er man naturligvis nødt til at vurderer de Cloud-specifikke trusler og de trusler der er særlige kritiske for en Cloud-løsning.

Men lad os tage den del i en særskilt diskussion.

Opsummering
Ved at starte med en dataklassifikation og derefter gå videre med input fra lovkrav, compliance krav og en sikkerhedsmodel kan sikkerhedskrav mappes direkte til den cloud-løsningen der skal vurderes.

Cloud-specifikke trusler og de trusler der er særlige kritiske for en Cloud-løsning skal selvfølgelig indgå specifikt i vurderingen.

Som nævnt i begyndelsen af indlægget er antallet af spørgsmål man stiller i risikovurderingen naturligvis helt afhængigt af hvilke data og processer der skal behandles i den Cloud løsning man overvejer. Jo mere kritisk den applikation eller de data man overvejer at lægge ud i Skyen er, jo flere krav skal man selvfølgelig efterfølgende stille, før en potentiel Cloud-løsning er sikkerhedsmæssigt acceptabel.

Risikoanalysen viser primært om Cloud-løsningen har "huller" i forhold til sikkerhedskravene. Næste skridt er selvfølgelig at vurderer om leverandøren kan lukke hullerne, om der er sikkerhedstiltag der kan kompenserer for problemområderne - eller om man kan leve med risikoen.

Spørgsmålet er selvfølgelig, om *en specifik* Cloud løsning er "sikker nok" til det man vil bruge den til. Hvis ikke må man finde måder sikkerheden kan forbedres på, eller finde alternative løsninger.

Profilens billede 19
Camilla Grynnerup Fisker - 24.11.2009 modereret af Camilla Grynnerup Fisker (24.11.2009)
ENISA, European Network and Information Security Agency, har udgivet en rapport om risikovurdering af cloud computing:http://digitaliser.dk/resource/436372

Tilføj fil(er)

En ny fil vil overskrive en eksisterende fil, hvis begge filer har samme navn og samme ekstension.

Bliv opdateret med nye aktiviter i gruppen via Twitter. Alt hvad du skal gøre er at følge digicloud på Twitter.

Below you will find links to English cloud computing related publications:

Read the full version of the publication with descriptions of each article and Statements from the Danish Data Protection Agency here.

Luk

Fjern fremhævning

Digitaliseringsstyrelsen