Säkerhet och molntjänster
Molntjänster är ett ständigt aktuellt ämne, inte minst sedan den beslutade utbyggnaden av ett par stora serverhallar i Mellansverige som varit omdiskuterade på grund av sin förhållandevis höga elförbrukning. Ur ett säkerhetsperspektiv finns också ett antal nya aspekter att ta hänsyn till även om tekniken i sig har funnits en längre tid.
Det som i första hand möjliggjort utvecklingen av molntjänster är virtualiseringstekniken som tillåter virtuella servrar att enkelt skapas, förändras och flyttas. Denna teknik har funnits en längre tid och används exempelvis i VMware och Hyper-V. För dessa tekniker finns också övergångslösningar och lösningar för samexistens med molnlösningar.
Tekniken att servrar och tjänster finns på en annan plats är gammal, likaså tekniken att uppnå redundans genom att ha exempelvis dubbla serverhallar och konceptet att anlita en utomstående tjänsteleverantör som ansvarar för drift och hårdvara.
Det som verkligen är nytt med publika molntjänster är enkelheten för vem som helst att ansluta sig och att molnleverantören erbjuder både en infrastruktur för virtuella servrar, ett antal standardiserade plattformar och ett antal färdiga tjänster. De företag som önskar kan också behålla dagens lösning med en tjänsteleverantör och låta denna hantera även de delar som läggs i en publik molntjänst, man får då också ofta en lösning i form av ett hybridmoln.
Att information ligger i ett publikt moln betyder inte att informationen är publikt tillgänglig. Ett företag kan lägga intern information i ett moln för att minska fasta kostnader och kostnader relaterade till drift och underhåll av IT-system. Men att information läggs i ett moln kan också bero på att informationen ska delas med andra företag eller slutanvändare eller konsumenter av en produkt eller en tjänst.
Ofta är ett företag inte helt medvetet om vilken information som faktiskt ligger i publika moln. Dolda källor kan vara samarbetsytor med fillagring, mötestjänster med deltagarlistor, inspelningar och presentationsmaterial, outsourcade administrativa tjänster för exempelvis bokföring, ekonomi och rekrytering samt order, lager och faktureringssystem. Orsaker att dessa system ligger i moln kan vara höga krav på tillgänglighet från olika nätverk och vid olika tidpunkter samt ett önskemål att systemen faktiskt ska ligga utanför det egna skalskyddet för att undvika extern access in i egna företagssystem.
Molntjänster ur ett konsumentperspektiv
För en konsument är molntjänster ofta förknippade med begreppet smarta hem. En person kan redan använda molnet genom sociala medier, appar i sin mobiltelefon, barnens spelkonsoler och familjens smart-TV och kanske även genom sin träningsklocka. Men i takt med att fler komponenter blir kopplade till Internet (IoT-enheter) så fås en ökad användning av molntjänster. Typiska komponenter i ett smart hem är kopplade till belysning, värme och ventilation. Enskilda enheter är kopplade via Bluetooth till en större enhet som är kopplad via hemmets WiFi till Internet. Enheterna tar typiskt kontakt med regelbundna intervall och rapporterar status och hämtar eventuella instruktioner. En person som har en bostad och ett fritidshus kan exempelvis se sin egen bostad direkt via appen i sin mobil och även fritidshuset är synligt på samma sätt tack vare molntjänsten.
Ofta är priset för en basversion av molntjänsten inbakat i priset för komponenterna, men det kan även finnas tilläggstjänster som betalas separat. Leverantören har information om sina enheter och konsumentens inloggningsuppgifter (normalt ett eget lösenord kopplat till en uppgiven epost adress). Leverantören förutsätts inte lagra kundens WiFi lösenord, men har i övrigt tillgång till den information kunden valt, tex egna namn på enheterna och namn på bostaden respektive fritidshuset osv.
Ur ett säkerhetsperspektiv kan flera av de enklare tjänsterna för smarta hem ha ett begränsat skyddsvärde. Det kan bli mer känsligt om kameraövervakning, larm eller låsfunktioner kopplas till. Vissa funktioner kan kunden välja att de ska vara publikt synliga, tex utomhustemperaturen för en väderstation. Men man gör i så fall sitt fritidshus lite mer synligt på en karta. Man ska också tänka på att flera funktioner kan användas för en enklare form av övervakning. En sensor för inomhusklimat som mäter temperatur, luftkvalitet och ljudnivå kan exempelvis tala om ifall någon befinner sig i bostaden, om ett fönster gått sönder i fritidshuset eller om någon faktiskt ropar på hjälp. Men vid ett dataintrång kan det exempelvis också vägleda tjuvar eller personer som vill utnyttja tjänsterna för felaktiga ändamål.
För leverantören är denna typ av tjänster typiska molntjänster. Även om man vill ha kontroll över driften så kan den med fördel hanteras separat från företagets interna IT-system. Man vill kunna hantera geografiskt spridda kunder och man vill inte hantera störningar relaterade till exempelvis DDOS-attacker och utpressning på egen hand. Budgetmässigt hamnar kostnader och framtida åtaganden rätt och riskerar inte att döljas i leverantörens övriga budget. Tillgängligheten blir med all säkerhet högre och säkerheten hamnar med hänsyn till konsumentkrav och lagstiftning på en jämn och godtagbar nivå. Leverantören slipper egna åtaganden för datahallar och bemanning av dessa.
Molntjänster ur ett kunskapsperspektiv
Ibland dyker det upp frågeställningar vad kring vad en It-tekniker eller konsult behöver kunna, inte minst när exempelvis Microsoft nu ställer uttalade krav på att kunskap om molntjänster ingår i alla deras aktuella certifieringar. De flesta personer har dock haft mobiler med appar i flera år och en grundläggande förståelse till att det finns ett backend system för att tillhandahålla dessa tjänster. Som konsument har de också fått en förståelse för hur konsumenter autenticierar sig gentemot molnlösningar.
För en tekniker som arbetat med Windows system så har utvecklingen från exempelvis Windows server 2008 till Windows server 2019 i det stora varit relativ jämn. Det som tillkommer med molntjänster är integrationstjänster för att kommunicera med molnbaserade delar av organisationens dataresurser och för att kunna hantera utomstående användare eller utvecklare. Teknikern eller konsulten behöver också känna till den nya tekniken för att kunna avgöra i vilka situationer det är lönsamt eller motiverat att använda molntjänster.
Som utvecklare är det också bra att känna till utbudet, om man exempelvis själv använder tjänster för ett smart hem så inser man också att flera produkter för övervakning har röst och ansiktsigenkänning och att dessa funktioner också ingår som en del av molnlösningarnas tjänsteutbud för utvecklare och på samma sätt är en del av utvecklingen kring lagstiftningen om personlig integritet.
Hantering av molntjänster ur ett säkerhetsperspektiv
För en säkerhetsgranskning av en IT-lösning, en sårbarhetsscanning eller ett penetrationstest spelar det egentligen ingen större roll om en publik molntjänst används.
Det som däremot är unikt vid säkerhetsgranskningar av molntjänster är i första hand hanteringen av behörigheter inom det företag som granskas att hantera resurser i molnet, exempelvis vilka som får skapa, förändra eller ta bort servrar eller andra resurser. Både Azure och AWS, för att ta två exempel, har en form av administrativ struktur som bör användas för att säkerställa att resurser inte förändras av misstag och att det finns en separation mellan utveckling, testmiljöer och produktionsmiljöer. Till detta kommer behovet av att ha en enhetlighet i administrationen så att en person som slutar sin anställning inte har separata konton för administrativ åtkomst till molntjänster som glöms bort.
I andra hand är det säkerhetstekniker som anpassats till moln, exempelvis hantering av brandväggar, VLAN, certifikat och interna lösenord anpassas till det som molntjänsten kan erbjuda på ett standardiserat sätt. Ett exempel är att man inte kan ställa in en egen HSM i molnet utan måste i stället välja en standardiserad säkerhetslösning. Vissa molntjänster erbjuder faktiskt tillgång till HSM för att skydda hemligheter vid en högre prisklass för denna tjänst. Denna tjänst är dock sällan anpassad för individuella anrop för varje autenticiering utan mer för att hämta systemlösenord och centrala lösenord till databaser. Frågan i så fall kan närmast vara om man uppfyller krav enligt FIPS då enbart vissa hemligheter lagras i en HSM.
Likaså måste krav på redundans och tillgänglighet hanteras på ett standardiserat sätt, normalt genom att man väljer lämpliga alternativ för sina resurser och genom att man grupperar dem i olika tillgänglighetszoner för att få en fysisk separation. Det går även att välja olika serverhallar utifrån geografi. En aspekt av betydelse här kan vara var användarna faktiskt befinner sig om man ska uppfylla regionala krav för exempelvis EU för tjänster som ställer särskilda krav i dessa avseenden, tex hälsorelaterade tjänster, försäljning av varor eller streamingtjänster för film.
En annan sak som är delvis unik för molntjänster är tjänsteutbudet. För mobiltelefoner är utbudet av appar centralt, däremot bryr sig en Windows användare kanske inte lika mycket om vilka appar som finns. För de publika molntjänsterna finns det ett liknande utbud av tjänster viket kan ses i floran av databastjänster och tjänster för applikationsutveckling. Det som finns i de publika molnen är ofta tjänster som åtminstone indirekt är relaterade till försäljning och distribution, marknadsföring, riktade annonser och hantering av det som ofta kallas IoT, allt från badrumsvågar till bilar som kan kommunicera och lagra information.
Man bör också tänka på att molntjänster kan vara mer eller mindre integrerade med andra molntjänster eller de egna IT-systemen. Det går delvis också igen i administrationsgränssnitt som kan ”sammanfoga” resurser som ligger hos olika molnleverantörer.
Speciellt för det som kallas Industriell IoT (IIoT) finns det ett flertal integrationslösningar att ta hänsyn till. I en produktionsanläggning kan det finnas ett flertal motorer, givare, plockdon och liknande enheter. Dessa är sammankopplade för att kunna styra den löpande produktionen. I andra hand kan dessa enheter vara individuellt uppkopplade till någon form av ”molntjänst” för att hantera underhåll och felkoder. Större enheter kan exempelvis ha vibrationsgivare som känner av om det kommer behövas ett byte av lager i den närmsta framtiden. I tredje hand kan information om själva tillverkningen lagras i en molntjänst. I de fall produktionen avser elektronisk utrustning som IoT enheter så kan grundläggande information om enheten läggas in i enheten redan vid produktionen.
För publika molntjänster faller slutligen kravet att granska serverhall och driftrutiner på denna plats bort. Detta ersätts då med en kontroll att molnleverantören uppger sig att uppfylla vissa krav och vilka förbehåll som i så fall lämnats av molnleverantören eller en trovärdig part som denne anlitat för att utställa en viss försäkran. För privata moln kvarstår normalt kravet att kunna granska driften på plats.
Hantering av molntjänster och virtualiseringslösningar vid härdning
Grundkonceptet är att varje nivå härdas för sig, exempelvis hanteras nätverk, virtualiseringslösning, operativsystem och applikation för sig. Det finns sökbara guidelines från STIG och CIS som täcker de flesta aktuella typer. Om man i egen regi kör en VMware server som innehåller en Windows server som tillhandahåller ett Office paket så får man alltså tre härdningsnivåer.
Om man nu istället använder en molntjänst så finns det givetvis guidelines för hur dessa bör hanteras. Men beroende på om man köper en infrastruktur (IaaS) eller en plattform (PaaS) så måste tillvägagångssättet anpassas. Tanken med att köpa en plattform är bland annat att underlätta administration och att tillföra skalbarhet. Härdning får då i viss mån ersättas av kommunikationsregler och att den egna applikationen görs tillräckligt stark och anpassas efter molnets betingelser. Det går också i vissa fall att köpa en ”härdad” basplattform. Det kan noteras att plattformarna normalt finns i ett antal varianter med olika versioner för de mest vanligaste programvarorna. Man behöver alltså inte vara rädd att ett system slutar fungera för att molnleverantören gör ett oväntat byte av en basprogramvara.
Hantering av smarta tjänster ur ett lokalt säkerhetsperspektiv
För IoT och IIoT komponenter finns det även lokala säkerhetsaspekter att ta hänsyn till även om dessa delvis ligger utanför detta tema avseende hantering av IT-tjänster i publika moln. Ett smart hem är detta ofta att betrakta som ett lokalt nätverk byggt på WiFi, Bluetooth och annan radiotrafik samt något eller några lokala nav. Kontakter med det publika molnet sker företrädesvis vid omkonfigurationer eller fjärradministration. Men under normala förhållanden så är beroendet av molntjänster lägre. Ofta har man en koppling mellan enskild komponent och en mobilapp som känner till WiFi lösenordet och kan lagra vissa användningsdata i molnet. Till detta kommer ofta en överliggande nivå, tex Apple Homekit, som kan knyta an till komponenter från flera olika tillverkare.
Den person som är mån om sin IT-säkerhet kan utnyttja ett gästnät för sin WiFi trafik för att hålla isär IoT komponenter från sina datorer.
Den person som gör mer avancerade styrningar av belysning eller värme och exempelvis bygger in sändare eller mottagare i befintliga strömbrytare eller uttag måste ha nödvändig behörighet. Det kan annars uppstå risker med felkopplingar som inte upptäcks omedelbart, användning av olämpliga komponenter eller olämpliga användningsfall och logiska automatiseringsfel, tex att överhettning uppstår om ett relä slår av och på ett upprepat antal gånger.
För smarta hem är det normalt inte driftkostnader utan upplevd bekvämlighet som är drivkraften. För smart belysning är det exempelvis möjligheten att ställa in ljusstyrkan för varje enskild lampa som är avgörande, man behöver inte välja lampa i förväg. Nackdelen med IoT glödlampor är att det kan behövas ett par extra tryckningar på en fysisk strömbrytare för att de ska förstå när de förväntas uppträda som en dum glödlampa, tex när man har gäster i hemmet. Den normala inställningen är att de inte ska tändas efter ett strömavbrott om de varit släckta innan.
För en smart brandvarnare är den avgörande skillnaden att man inte behöver bli väckt mitt i natten för att enheten vill ha nya batterier, man kan också se direkt i mobilen att alla enheter fungerar, när de sist testades och hur länge batteriet räcker. Om molnkopplingen inte fungerar kan man inte få ett larm till en annan plats. Om radiodelen i brandvarnaren slutar att fungera så kasseras den eftersom man i annat fall inte kan avgöra dess skick. Slutligen, om man säljer huset och låter brandvarnaren sitta kvar så måste den fabriksåterställas liksom övriga IoT enheter för att passa den nya ägaren.
Om ”Internet” slutar att fungera så kommer de lokala enheterna i ett smart hem ändå att fungera lokalt. Det finns mycket att tänka på, men man lär sig relativt snabbt vad som fungerar. Det tillkommer också normalt ett antal interna radionätverk inom hushållet, belysningen har sitt nätverk, medan termostaterna och säkerhetsprodukterna har sina vilket kan kräva vissa överväganden.
För industriell IoT gäller delvis andra förutsättningar och man måste skilja mellan normal processtyrning och den extra funktionalitet som exempelvis IIoT komponenter kan ge avseende övervakning och underhåll av vissa komponenter. Generellt är industriproduktion gjord för att fungera med så få externa beroenden som möjligt och det mesta styrs och övervakas på lokal nivå precis som i ett smart hem. Det som skiljer är att komplexiteten är större i industriella system och att man ofta har en eller flera egna underleverantörer som kan göra service, antingen på plats eller via kopplingar till egna system. För IIoT är beroendet till leverantören också större eftersom industriella system generellt har en längre livslängd, för att systemen ofta är nischade och kundanpassade samt för att reservdelar mm kan behövas. De mer komplexa kopplingarna till produktionen gör också att granskningar av säkerheten mer nödvändiga, både på en teknisk nivå och för att avgöra riskerna för störningar i verksamheten.
Hantering enligt best practice
Det finns ett antal källor för best practice, exempelvis från tjänsteleverantörerna, organisationer och myndigheter.
Molnleverantören har egna guidelines och utbildningsvägar för hur tjänsterna ska användas på ett säkert sätt.
Olika organisationer som CSA (Cloud Security Alliance), CIS mm har guidelines för hantering av säkerheten, utbildningsvägar och certifieringar.
Olika branschkrav, tex HIPAA, SOX, PCI DSS och GDPR, ställer ett antal krav oavsett om systemet är molnbaserat eller inte. I många fall kan kraven leda till att delar av systemet måste ligga utanför en molntjänst.
CSA har ett antal benchmarks och guidelines för alla typer av IT-system, inklusive molntjänster
Cloud Security Alliance har ett antal guidelines, checklistor och utbildningsmaterial
https://cloudsecurityalliance.org/
https://ccsk.cloudsecurityalliance.org/en
Microsoft har en grundläggande utbildning i Azure
https://docs.microsoft.com/en-us/learn/certifications/exams/az-900