Inledning
Jag har tidigare skrivit om att det inte går att förlita sig på att molnleverantören löser era problem eller fråntar er allt ansvar, men inte gått in på detaljer.
I den här artikeln beskriver jag de olika tjänstemodeller ni hittar i ett moln samt var molnleverantörens ansvar slutar och ert börjar. Utöver det kommer jag även beröra säkerhet, helt enkelt på grund av att det är ett så viktigt ämne.
När ni läst klart hoppas jag att ni har en bättre förståelse för vad ni måste hantera och vad ni kan förvänta er att molnleverantörerna hanterar.
De olika tjänstemodellerna
Det NIST kallar "service models" [1] och ISO kallar "cloud service categories" [2] översätter jag till tjänstemodeller. NIST använder sig av tre medan ISO anger många fler exempel. För enkelhetens skull kommer jag hålla mig till de tre traditionella modellerna som NIST och många andra använder sig av.
Följande bild illustrerar Microsofts syn på ansvarsfördelningen i molnet [3]. Jag går igenom de olika modellerna i detalj nedan.
IaaS
Infrastructure as a Service är den mest grundläggande modellen där ni exempelvis köper en virtuell maskin, lagring eller nätverk hos molnleverantören. Beroende på molnleverantör finns det skillnader i exakt vad som klassas som IaaS men grundprincipen är att tjänsten ni konsumerar är så nära den underliggande hårdvaran ni kan komma.
Detta innebär att det främsta molnleverantören ansvarar för är hårdvaran och att de tjänster ni köper är tillgängliga. Ni kan lägga till funktionalitet, ibland mot en kostnad, som utökar molnleverantörens åtaganden. Exempelvis kan ni i Azure aktivera automatiska uppdateringar av era servrar, men det är fortfarande ert ansvar att se till att uppdateringarna sker.
Backup är ett annat bra exempel på vad som är ert ansvar. Microsoft tillhandahåller tjänster för att ta backup på er virtuella maskin eller lagring men ni måste säkerställa att backup är konfigurerat samt övervaka att tjänsten fungerar som förväntat.
Samma sak med katastrofsäkring där det enda Microsoft garanterar är att er data finns på tre fysiskt åtskilda platser i deras datacenter. Ert ansvar är att ha en plan för hur ni säkerställer att er data är säkrad och hur ni får tillbaka den i händelse av katastrof.
Brandväggsregler, övervakning, antivirus, kryptering, och prestandaoptimering är några exempel på andra åtaganden ni har om ni kör IaaS. Molnleverantörerna tillhandahåller verktyg och tjänster för att göra detta, men inte mer än så.
Fördelen med den här modellen är att den ger er möjlighet att köra samma applikationer som på en VM i ert eget datacenter, och så länge ni inte bryter mot Microsofts avtal eller lagen bryr de sig inte om vad ni kör i era virtuella servrar.
PaaS
Platform as a Service innebär förenklat att molnleverantören tillhandahåller en server för er att köra er applikation på. Det kan vara ren kod, en container med en applikation i, en databas, eller något mer specialiserat som AI eller High Performance Computing.
PaaS ger er en möjlighet att slippa ansvaret för operativsystem, samt vissa delar av nätverk och lagring. Som bilden ovan illustrerar varierar ansvarsfördelningen från tjänst till tjänst men var gränsen går skall alltid vara tydligt beskrivet för respektive tjänst.
Om ni exempelvis väljer att köra Microsoft Azure SQL Database behöver ni inte fundera på att hålla varken Windowsservern eller SQL-servern uppdaterad, men ni är däremot ansvariga för att konfigurera brandväggsreglerna för databasen.
Ett ansvar som ni inte slipper är att se till att molnleverantören faktiskt levererar det som förväntas. Om era kunder drabbas på grund av att molnleverantören inte levererar vad som är avtalat är det ni som kommer få skulden.
PaaS bör vara lägsta nivån när ni kör applikationer i molnet helt enkelt på grund av att ni slipper mycket av den kritiska, tidsödande och ofta tråkiga hantering som krävs av IaaS. I ett initialt skede kan ni flytta er arbetslast från en VM i ert eget datacenter till en VM i molnet, så länge ni har en plan för hur ni skall flytta applikationen vidare till PaaS.
Nackdelen med PaaS är att molnleverantörerna har väldigt tydliga definitioner av vad deras tjänst består av och vad ni kan förvänta er. Det finns fortfarande mycket flexibilitet men ni är mer nerlåsta i en PaaS-tjänst jämfört med en IaaS-tjänst. Om ni använder PaaS på ett korrekt sätt är denna begränsning dock inte ett problem i praktiken.
SaaS
Software as a Service är den modell som kräver minst av er, och mest av molnleverantören. Baksidan av det här myntet är att leveransen är väldigt strikt definierad och ni som kund har väldigt få möjligheter att modifiera och anpassa tjänsten.
Ett exempel på en populär SaaS-tjänst är Office 365, och även om Azure traditionellt endast levererar Iaas- och PaaS-tjänster är det diskutabelt om inte ett antal tjänster i Azure rent krasst kan klassificeras som SaaS-tjänster. Exempelvis är Azure Monitor [4] en lösning som låter er övervaka era tjänster och applikationer. Ni kan dock inte modifiera den här lösningen något nämnvärt.
När ni konsumerar en SaaS-tjänst har ni ett tydligt ansvar, illustrerat i bilden ovan, och i vissa fall även ett visst ansvar för identitetshantering, men en majoritet av ansvaret ligger hos molnleverantören. Som med övriga modeller måste ni även här säkerställa att ni får det ni avtalat.
Säkerhet är alltid ert ansvar
Säkerhet är alltid kundens ansvar, till viss del illustrerat av översta segmentet i bilden ovan. Era konton, era enheter och er information är något som en molnleverantör aldrig kan hållas ytterst ansvarig för.
Som kund faller det på er att säkerställa att molnleverantören lever upp till sina åtaganden och att deras verktyg, system och processer fungerar som utlovat. Om dessa brister är det ni som måste se till att ordningen återställs. Att avvakta och hoppas på att molnleverantören löser problemet är inte en hållbar strategi.
Jag har skrivit om säkerhet i andra artiklar men trots detta vill jag lyfta fram det även här då det är den enskilt viktigaste aspekten av konsumtion av molntjänster som ni kan och skall påverka.
Avslutningsvis
Ju mer en molntjänst liknar vad ni kör i ert eget datacenter, desto större ansvar har ni för att säkerställa att er applikation fungerar som tänkt. Ju närmare en SaaS-tjänstemodell ni kommer desto mindre blir ert åtagande, och det faller istället på molnleverantören att ta ett större ansvar.
I slutändan är det dock ni som kund som måste säkerställa att ni får vad som avtalats och att leveransen lever upp till era förväntningar. Alla molnleverantörer har problem av och till, trots allt de gör för att undvika det, och ni som kund måste hantera dessa situationer. Det finns såklart en gräns för hur långt ni kan ta detta och det är här en risk- och sårbarhetsanalys kommer in i bilden.
Hur mycket är det värt för er organisation att ta höjd för att, exempelvis, ett av Microsofts datacenter drabbas av totalt driftstopp? Kanske befinner ni er i en situation där ni endast använder molnet för att avlasta er lokala produktionsmiljö. I så fall är det av förklarliga skäl inte alls lika kritiskt att ta höjd för eventuella problem i molnet.
Molnet erbjuder ett otal möjligheter för er att utveckla er leverans av IT men det är inte "set and forget." Oavsett vilken tjänstemodell ni väljer - IaaS, PaaS, eller SaaS - har ni ett ansvar ni inte kan avskriva er. Hur allvarligt ni tar detta ansvar avgör hur väl rustade ni är när, inte om, molnet upplever problem.
Tveka inte att kontakta mig, antingen via e-mail, telefon eller formuläret här på hemsidan, om ni är intresserade av att diskutera ämnet vidare med mig.
Tack för er tid!