Dagens utvecklingen går mot allt fler tjänster i molnet och marknaden förut-spås öka sin omsättning med mer än 50% inom tre år. I takt med att molntjäns-ter växer blir det allt vanligare att höra om dataintrång. Genom att strukturera arbetet med säkerhet i form av en holistisk metod kan det enkelt genomföras i samband med den övriga utvecklingen. Studiens resultat kan därmed bidra till säkrare molntjänster och på sikt minska mängden dataintrång genom ökad kunskap och medvetenhet.
[1] Internet History – One Page Summary. url: https://www.livinginternet.
com/i/ii_summary.htm (hämtad 2019-09-09).
[2] Andrew Meola. How IoT & smart home automation will change the
way we live. url: https : / / www . businessinsider . com /
internet-of-things-smart-home-automation-2016-8?r=US&IR=T (hämtad 2019-09-09).
[3] Mohammad Hamdaqa och Ladan Tahvildari. “Cloud computing unco-vered: a research landscape”. I: Advances in Computers. Vol. 86. Else-vier, 2012, s. 41–85.
[4] 2018 Cloud Security Report - Cybersecurity Insiders. 2018. url: https:
//www.cybersecurity-insiders.com/portfolio/2018-cloud-security-report-download/ (hämtad 2019-03-28). [5] Statliga hemligheter kunde nås av främmande makt. url: https://
www.dn.se/nyheter/sverige/statliga-hemligheter-kunde-nas-av-frammande-makt/ (hämtad 2019-09-09). [6] Cyberattacks against industrial targets have doubled over the last 6
months | ZDNet. url: https://www.zdnet.com/article/
cyberattacks-against-industrial-targets-double-over-the-last-6-months/ (hämtad 2019-08-10).
[7] Nayan B Ruparelia. “Software development lifecycle models”. I: ACM
SIGSOFT Software Engineering Notes 35.3 (2010), s. 8–13.
[8] S. Subashini och V. Kavitha. “A survey on security issues in service delivery models of cloud computing”. I: Journal of Network and
Com-puter Applications 34.1 (jan. 2011), s. 1–11. issn: 1084-8045. doi: 10.
1016/J.JNCA.2010.07.006. url: https://www.sciencedirect. com/science/article/pii/S1084804510001281.
[9] Per Oscarsson. Modell för klassificering av information :
rekommenda-tioner. Tekn. rapport. url: https://www.msb.se/RibData/
Filer/pdf/25602.pdf.
[10] Simon C Kitto, Janice Chesters och Carol Grbich. “Quality in qualitati-ve research”. I: Medical journal of Australia 188.4 (2008), s. 243–246. [11] Forskningsetiska principer inom humanistisk-samhällsvetenskaplig
forsk-ning. Tekn. rapport. url: https://www.gu.se/digitalAssets/
1268 / 1268494 _ forskningsetiska _ principer _ 2002 . pdf.
[12] Triona Sverige AB. 2019. url: https://www.triona.se/.
[13] Cyberattacks against industrial targets have doubled over the last 6 months | ZDNet. url: https://www.zdnet.com/article/
cyberattacks-against-industrial-targets-double-over-the-last-6-months/ (hämtad 2019-08-10).
[14] Gartner Identifies Key Trends in PaaS and Platform Architecture for 2019. url: https : / / www . gartner . com / en / newsroom /
press- releases/2019- 04- 29- gartner- identifies-key-trends-in-paas-and-platform-ar (hämtad 2019-08-05). [15] Gartner. Cloud market share 2018. 2019. url: https://www.gartner.
com / en / newsroom / press releases / 2019 07 29 - gartner-says-worldwide-iaas-public-cloud-services-market-grew-31point3-percent-in-2018.
[16] Khayyam H. Masiyev m. fl. “Cloud computing for business”. I: 2012
6th International Conference on Application of Information and Com-munication Technologies (AICT). IEEE, okt. 2012. isbn:
978-1-4673-1740-5. doi: 10 . 1109 / ICAICT . 2012 . 6398514. url: http : //ieeexplore.ieee.org/document/6398514/.
[17] Peter Mell och Timothy Grance. The NIST Definition of Cloud
Compu-ting Recommendations of the National Institute of Standards and Tech-nology. Tekn. rapport. url: http://faculty.winthrop.edu/
domanm/csci411/Handouts/NIST.pdf.
[18] Gartner Forecasts Worldwide Public Cloud Revenue to Grow 17.3 Per-cent in 2019. 2018. url: https : / / www . gartner . com / en /
newsroom / press releases / 2018 09 12 gartner forecasts worldwide public cloud revenue to -grow-17-percent-in-2019.
[19] Gmail by Google. url: https://www.google.com/gmail/
about/ (hämtad 2019-09-09).
[20] Keep by Google. url: https://www.google.com/keep/
(häm-tad 2019-09-09).
[21] Drive by Google. url: https : / / www . google . com / drive/
(hämtad 2019-09-09).
[22] 44 U.S. Code § 3542 - Definitions. url: https : / / www . law .
cornell.edu/uscode/text/44/3542 (hämtad 2019-09-09). [23] Tim Stevens. “Global Cybersecurity: New Directions in Theory and
Methods”. I: (2018).
[24] IEEE Computer Society. Technical Community for Services Compu-ting. 2009 IEEE International Conference on Services Computing :
pro-ceedings, Bangalore, India, 21-25 September 2009. IEEE Computer
So-ciety, 2009. isbn: 9781424451838. url: https://ieeexplore-ieee-org.focus.lib.kth.se/document/5283911. [25] P. Wieder m. fl. Service Level Agreements for Cloud Computing.
Spring-erLink : Bücher. Springer New York, 2011. isbn: 9781461416142. url: https://books.google.se/books?id=z306GUfFL5gC. [26] Cyril Onwubiko. “A Security Audit Framework for Security
Manage-ment in the Enterprise”. I: (2009). url: https://link-springer-com . focus . lib . kth . se / content / pdf / 10 . 1007 % 7B % 5C%%7D2F978-3-642-04062-7.pdf.
[27] Ken Peffers m. fl. “A design science research methodology for informa-tion systems research”. I: Journal of management informainforma-tion systems 24.3 (2007), s. 45–77.
[28] Janet BW Williams. “A structured interview guide for the Hamilton De-pression Rating Scale”. I: Archives of general psychiatry 45.8 (1988), s. 742–747.
[29] J. Hartman. Vetenskapligt tänkande: från kunskapsteori till
metodte-ori. Studentlitteratur, 2007. isbn: 9789144033068. url: https : / /
books.google.se/books?id=onEZMgAACAAJ.
[30] Anne Håkansson. Citation for the original published paper:
Håkans-son, A. (2013) Portal of Research Methods and Methodologies for Re-search Projects and Degree Projects. Tekn. rapport. 2013. url: http:
/ / urn . kb . se / resolve ? urn = urn : nbn : se : kth : diva -136960.
[31] Sharan B Merriam. Qualitative Research and Case Study Applications
in Education. Revised and Expanded from"Case Study Research in Educa-tion.". ERIC, 1998.
[32] Manfred Max Bergman. Advances in mixed methods research: Theories
and applications. Sage, 2008.
[33] Wasana Sedera, Michael Rosemann och Guy Gable. “Measuring pro-cess modelling sucpro-cess”. I: (2002).
[34] Ilker Etikan, Sulaiman Abubakar Musa och Rukayya Sunusi Alkas-sim. “Comparison of convenience sampling and purposive sampling”. I: American journal of theoretical and applied statistics 5.1 (2016), s. 1– 4.
[35] Alan Bryman, Saul Becker och Joe Sempik. “Quality criteria for quan-titative, qualitative and mixed methods research: A view from social policy”. I: International Journal of Social Research Methodology 11.4 (2008), s. 261–276.
[36] Paul Johannesson och Erik Perjons. A design science primer. Create-Space, 2012.
[37] Keith A Meadows. “So you want to do research? 3. An introduction to qualitative methods”. I: British Journal of Community Nursing 8.10 (2003), s. 464–469.
[38] Howard Baldwin. Drilling Into The Value Of Data. url: https:// www.forbes.com/sites/howardbaldwin/2015/03/23/ drilling-into-the-value-of-data/ (hämtad 2019-10-23). [39] Melissa Larsen och Michael Myers. “BPR success or failure? A busi-ness process reengineering project in the financial services industry”. I:
ICIS 1997 Proceedings (1997), s. 24.
[40] William J Doll och Gholamreza Torkzadeh. “Developing a multidimen-sional measure of system-use in an organizational context”. I:
Informa-tion & Management 33.4 (1998), s. 171–185.
[41] ISO 9241-11:2018 Ergonomics of human-system interaction — Part 11: Usability: Definitions and concepts. url: https : / / www . iso .
Enkätfrågor
Säkerhetsområden för PaaS-tjänster
Joakim Bergstedt, joakbe@kth.seAndré Hansson, andrhans@kth.se
Examensarbete (15 hp) på Kungliga Tekniska Högskolan (KTH)
Enkäten utförs inom en undersökning angående säkerhet och rutiner vid PaaS. Syftet med enkäten är att samla insikter om vilka rutiner och tillvägagångssätt erfarna personer på företag inom området har för att säkerställa säkerheten vid användning av PaaS-tjänster. De svar och resultat som ges kommer användas som stöd för att försöka ta fram en process för säkerställning av säkerhet. Medverkande i enkäten är frivilligt och vi uppskattar alla svar. Alla svar kom-mer endast att användas i undersökningen och ej för icke-vetenskapliga syften. Personlig information hanteras konfidentiellt, endast information om yrkesroll och eventuellt företag om det accepteras kommer redogöras och presenteras i rapporten.
1. Vad är din yrkesroll på företaget?
2. Vilken typ av kontakt med molntjänster har du i arbetet?
3. Vilka rutiner har ni vid leverans av PaaS med fokus på säkerhet? 3.1. Vad skiljer sig från on-premise?
3.2. Hur utvärderas säkerheten?
3.3. Vilka säkerhetsaspekter prioriteras och inte?
4. Vilka är enligt din erfarenhet de främsta säkerhetsriskerna att ta hänsyn till vid användning av PaaS? (hantering av krypteringsnycklar, access etc.)
4.1. Hur motverkar ni dessa?
4.2. Hur skiljer sig det från on-premise? 5. Vilka garantier ges för data?
5.1. Lagrinsplats? (geografiskt?) 5.2. Integritet?
5.3. Tillgänglighet? 5.4. Access?
5.5. Lagar och regler? (GDPR)
6. Vid behov av intern kommunikation mellan tjänster, hur löses detta? 6.1. Begränsas tillgängligheten då till dessa?
Förbättrad PaaSM
Denna billaga presenterar den fullständiga förbättrade versionen av PaaSM. Kapitel B innehåller en översikt av PaaSM. Kapitel B till B presenterar PaaSMs olika steg och aktiviteter.
Översikt förbättrad PaaSM
Platform as a Service Security Method (PaaSM) är ett metodförslag för att
utvärdera och upprätthålla säkerhet i PaaS-miljö. Metodförslaget, vars översikt visas i figur B.1, består av fem metodsteg med tillhörande aktiviteter. Varje steg appliceras inom ett eller flera stadier av en PaaS-applikations livscykel. Tidigt i en applikations livscykel genomförs kravställning. Detta för att defi-niera vad som krävs av den slutgiltiga implementationen för att uppfylla öns-kat resultat. Genom att genomföra en kravställning helt fokuserad på säkerhet (Steg 1 - Kravställning) tillsammans med ordinarie kravställning kan kraven för olika säkerhetsaspekter inkluderas i applikationens övriga krav och imple-mentering. Detta gör att beslut kring implementering kan fattas med säker-hetskraven i åtanke istället för att någon av delarna behöver anpassas vid ett senare tillfälle.
För att få en grundlig förståelse av vilken typ av säkerhet som en applikation kräver behövs ordentlig kunskap om vilken typ av data applikationen skall hantera (Steg 2 - Informationsklassning). Olika typer av data är olika känsliga och kräver därmed olika nivåer av säkerhet i sin hantering. Genom att struktu-rera den data applikationen ska hantera efter typ kan den enkelt klassificeras och hanteras efter dess säkerhetsbehov.
Nästa stadie i livscykeln hos en applikation är Implementation. Stadiet kräver att man har förståelse för vilka säkerhetsaspekter som bör tas hänsyn till samt vilka verktyg som finns tillgängliga (Steg 3 - Implementering av Datasäkerhet och Steg 4 - Implementering av Säkerhetsaspekter). Genom användandet av beprövade verktyg så minskar risken för små men kritiska brister i säkerheten hos den applikation som utvecklas.
När utvecklingen av applikationen är färdig är det viktigt att kontrollera att samtliga krav har tillgodosetts. Normalt sker detta genom testning innan ap-plikationen driftsätts. Utöver test av funktionalitet så är det också viktigt att kontrollera att säkerheten uppfyller de krav som satts upp (Steg 5 -
Gransk-ning). Kontroller av säkerheten hos applikationen bör sker med jämna
mellan-rum för att garantera att den fortsatt uppfyller satta krav.
Steg 1 - Kravställning
Vid utvecklingen av en applikation utgår arbetet från de krav som sätts upp av kund och/eller projektmedlemmar. Kraven ser till att resultatet av arbetet är det som förväntas. För att kunna garantera lämplig säkerhet hos en applikation i PaaS-miljö behöver säkerhetsrelaterade krav specificeras. Steg ett i PaaSM presenterar stöd för att genomföra en säkerhetsrelaterad kravställning i fyra olika aktiviteter där varje aktivitet tar upp en säkerhetsaspekt. Kravställning-en är tänkt att gKravställning-enomföras under stadiet Planering i applikationKravställning-ens livscykel, detta illustreras i figur B.2.
Figur B.2: Steg 1 - Kravställning
Aktivitet 1.1. - Identifiera säkerhetskrav: Data
Det är viktigt att specificera hur en applikation hanterar data. Applikationens ordinarie kravställning specificerar normalt vilken typ av data som ska han-teras och eventuellt på vilket sätt. Säkerhetsaspekter kan därmed lätt missas och det är därför viktigt att tidigt identifiera vilka säkerhetskrav som finns för applikationens data.
Identifiering av säkerhetskrav kopplade till data sker genom att först definiera vad som ska lagras. Specificera om den data som applikationen ska hantera som är extra känslig eller kräver specialhantering. Genomför en undersökning gällande vilka delar av applikationens data som kan placeras i molnet. Eventu-ellt finns det data som ej får hanteras av en extern molnleverantör och behöver lagras internt. Undersök huruvida det finns data som har geografiska restrik-tioner som kräver att data placeras inom specifika regioner. Ytterligare skall
kraven specificera hur data får transporteras mellan enheter i applikationens infrastruktur samt hur förändring och läsning av data får ske och av vem.
Aktivitet 1.2. - Identifiera säkerhetskrav: Access
Att identifiera säkerhetskrav gällande access är viktigt ur två olika aspekter, access för användare delaktiga i utvecklingen av applikationen och de olika aktörerna som ska använda applikationen. Generellt när det gäller access vill man i högsta grad sträva efter principen minsta möjliga behörighet. Minsta möjliga behörighet innebär att ingen utvecklare eller användare ska tilldelas högre behörighet än vad som krävs för att de ska kunna utföra sin uppgift. Ett tillvägagångssätt för att minska överflödig access under utvecklingen är att endast utse en administratör med ansvaret för att tilldelning av access. Vidare bör det definieras en process för hur tilldelning ska ske. Detta ökar sannolik-heten att access tilldelas enhetligt till alla. Det är viktigt att kontrollera vad för access användaren behöver och till vilka delar av applikationen. Detta bör resultera i olika access-nivåer. Under processen är det viktigt att klargöra an-vändarens roll och uppgift i applikationen för att se till att de inte får access utöver vad deras roll kräver.
Aktivitet 1.3. - Identifiera säkerhetskrav: Tillgänglighet
Säkerhetskrav för en applikations tillgänglighet identifieras för att begränsa applikationens risk att bli utsatt för attacker eller intrång. Finns det inget be-hov av åtkomst oavsett position eller typ av anslutning minskas potentiella säkerhetsrisker markant om applikationen ej görs tillgänglig utanför de krav som finns. Identifiering av säkerhetskrav för tillgänglighet handlar först om att definiera vilken typ av applikation det är genom att klargöra om den är tänkt att endast användas internt hos ett företag eller publik på internet. Om applikatio-nen endast skall användas internt behöver den inte vara synlig eller tillgänglig online. Kraven på tillgänglighet kan behöva anpassas efter de säkerhetskrav som identifieras för applikationens data. Finns det data som ej får förflyttas ut-anför det interna nätverket kan restriktioner för tillgänglighet via VPN behöva specificeras.Aktivitet 1.4. - Identifiera säkerhetskrav: Övrig säkerhet
Säkerhetskrav för applikationer varierar beroende på typ applikation. Det är därmed viktigt att identifiera eventuella applikationsspecifika krav kring sä-kerhet utöver de tidigare aktiviteterna. Detta görs enklast genom att specificera typ av applikation, dess syfte och mål samt ta hänsyn till eventuella krav från kund som påverkar eventuella beslut kring säkerheten.Steg 2 - Informationsklassning
Informationsklassning är en process för att dela in applikationens data och
re-surser i olika nivåer utifrån de konsekvenser som kan uppstå från otillräckligt skydd. Klassificeringen utförs på olika säkerhetsaspekter, konfidentialitet, rik-tighet och tillgänglighet. Detta bidrar till att förbättra både datasäkerhet och överensstämmelse med rådande lagar och regler. Genom att klassificera data skapas en tydligare förståelse vad för data som faktiskt hanteras och av vem. Informationsklassningen är tänkt att genomföras under stadiet Planering i ap-plikationens livscykel, detta illustreras i figur B.3.
Figur B.3: Steg 2 - Informationsklassning
Aktivitet 2.1. - Definiera informationsmängder
Första momentet i informationsklassningen handlar om att kartlägga data och resurser som applikationen är tänkt att hantera och bearbeta. Syftet är att skapa en överblick på vilka olika typer av information som behöver skyddas utifrån särskilda säkerhetsaspekter. Att definiera informationsmängder innebär att un-dersöka och dela upp informationen som applikationen avser att behandla i meningsfulla mängder. Vad som anses vara en meningsfull mängd kan vara svårt att definiera. En grundregel är att en informationsmängd är den mins-ta sammansatmins-ta grupperingen av information som hanteras av applikationen. Två exempel på vad lämpliga informationsmängder kan vara är personuppgif-ter och bankuppgifpersonuppgif-ter. Båda kan innehålla en varierande mängd data beroende på applikationens behov men minsta sammansättningen av namn, adress och födelsedatum är vanligtvis personuppgifter.
Nivå \Aspekt Konfidentialitet Riktighet Tillgänglighet
Allvarlig K3 R3 T3
Betydande K2 R2 T2
Måttlig K1 R1 T1
Ingen K0 R0 T0
Tabell B.1: Exempel på klassificeringens olika bedömningsnivåer
Genomförandet av detta moment kräver att medverkande besitter grundlig kunskap om den information applikationen hanterar under sin livscykel. Re-sultat skall vara en lista av lämpliga informationsmängder.
Aktivitet 2.2. - Klassificera informationsmängder
I moment två av informationsklassningen ska listan på informationsmängder klassificeras. Det innebär att det ska genomföras en konsekvensbedömning på vilka konsekvenser som kan inträffa om informationens konfidentialitet, rik-tighet och tillgänglighet inte upprätthålls. Syftet med detta steg är att bedöma vilken aspekt som är mest kritisk för respektive informationsmängd från före-gående aktivitet.
Konfidentialitet syftar till vilka konsekvenser som kan uppstå i de fall informa-tionen läcker eller blir åtkomlig för obehöriga. Riktighet syftar till vilka kon-sekvenser som kan uppstå om informationen är felaktig eller inaktuell. Till-gänglighet handlar om ifall en användare inte får tillgång till informationen förutsatt att användaren är behörig.
Varje informationsmängd ska tilldelas en konsekvensnivå för alla tre aspekter. Skalan på konsekvensnivåer kan bestämmas efter preferens. Ett förslag är att använda en skala från noll till tre, se tabell B.1. I skalan innebär noll att in-formationen inte kan orsaka någon form av skada oberoende av konsekvens. Konsekvensnivå tre innebär därmed allvarliga konsekvenser vid otillräckligt skydd. Det kan underlätta att tänka på vad för data applikationen hanterar i oli-ka sammanhang. Dessa oli-kan vara till exempel inmatning, bearbetning, lagring och utmatning. Efter den initiala konsekvensbedömningen ska konsekvensni-vån hos varje informationsmängd utvärderas mot eventuella interna och ex-terna krav. Dessa kan till exempel inkludera lagar (GDPR), avtal, kundkrav,
organisationella krav eller specifika krav på säkerhet som definierats i steg ett av PaaSM.
Aktivitet 2.3. - Sammanställ lista med
säkerhetsåtgär-der
Resultatet från föregående aktivitet, Klassificera, ska i det tredje momentet an-vändas för att sammanställa en lista på säkerhetsåtgärder som ska införas för att uppnå den nivå av skydd varje informationsmängd kräver. Informations-mängdernas konsekvensnivåer ska användas som riktlinjer till att formulera lämpliga säkerhetsåtgärder.
Om en informationsmängd har högt värde på konfidentialitet bör fokus ligga på att ta fram säkerhetsåtgärder som ska upprätthålla rigorösa access kontroller för att minska risken för obehörig access. Utöver access bör även informatio-nen krypteras för att skapa ett ytterligare lager av säkerhet. Ett hög konsekvens-nivå på tillgänglighet innebär ett behov att informationen alltid ska finnas till-gänglig, därmed bör säkerhetsåtgärder inkludera olika former av säkerhetsko-piering och redundans. Med höga värden på riktighet bör säkerhetsåtgärder inkludera rigorösa valideringskontroller.
Figur B.4: Steg 3 - Implementering av Datasäkerhet
Steg 3 - Implementering av Datasäkerhet
Vid implementation av de krav som specificerats för säkerheten kring appli-kationens data är det viktigt att kontrollera och hantera de säkerhetsaspekter som anses kritiska för PaaS-applikationer. Det tredje steget i PaaSM presente-rar dessa säkerhetsaspekter och potentiella lösningar från Microsoft Azure och
Google Cloud. Implementationerna av säkerhetsåtgärder är tänkt att
genom-föras under stadiet Implementering i applikationens livscykel, detta illustreras i figur B.4.
Aktivitet 3.1. - Implementera säkerhetsåtgärder för
data-access
Tilldelning av data-access medför alltid risken att användare får tillgång till data utanför deras behov. Detta medför i sin tur ökad risk att denna data för-störs eller hamnar i fel händer. För att minimera riskerna att obehöriga och ej berättigade användare får tillgång till känslig data vill man sträva efter princi-pen “Minsta möjliga behörighet”. Användarens datatillgång ska även följa de säkerhetskrav som specificerats för applikationen.
Vid implementation av säkerhetsåtgärder för data-access är det viktigt att ta hänsyn till tidigare steg av PaaSM. De krav som specificerats gällande data-access (Steg 1, aktivitet 1.1-1.2) och de säkerhetsåtgärder som tagits fram i samband med genomförd Informationsklassning (Steg 2) ska ligga till grund för implementationen.
Både Microsoft och Google tillhandahåller lösningar för hantering av access. Microsoft har Azure Active Directory och Google har Cloud Identity Access
Management. Båda tjänsterna tillhandahåller verktyg för hantering av
identi-teter och behörigheter.
Aktivitet 3.2. - Implementera säkerhetsåtgärder för
da-taokalitet
Kontrollen över vilken data som lagras var försämras i samband med att den flyttas till molnet. Då leverantörens infrastruktur ofta är spridd över flera geo-grafiska platser kan även den data som lagras spridas. Spridning kan vara både positivt och negativt då det dels skapar geografisk redundans men även kan placera lagrad data på platser som inte tillåts i kravställningen. Det är därför viktigt att ha kunskap om var och på vilket sätt data lagras av leverantören.