Skyløsninger gir mer kostnadseffektiv bruk av IKT og store muligheter for økt produktivitet – men det skaper også risikoelementer og sikkerhetsutfordringer som man må ha oversikt over.
Ansvaret for informasjonssikkerhet i skyen er delt mellom din skytjenesteleverandør og deg som kunde. For at du skal kunne sikre dine data i skyen, må du ha kunnskap om hvilket sikkerhetsansvar din leverandør har.
Mange tenker at man "løser sikkerhet" ved å flytte seg til skyen, men man beveger seg egentlig bare videre til et nytt sett med utfordringer. I denne ukens bloggartikkel ser vi nærmere på noen av disse, og dessuten gir vi deg 7 tips til hvordan du kan oppnå bedre sikkerhet i skyen.
Sky har sine helt egne utfordringer, og det krever egen kompetanse å konfigurere og drifte det. Mange av utfordringene med on-premise kan løses av skyteknologi, men sky har sine egne unike aspekter også.
Tilgangskontroll (som vi skrev om i vår forrige fagbloggartikkel) er avgjørende i sky, ettersom tilgang – i stedet for å begrenses av fysiske nettverk og tilgang på enkelte maskiner – nå er rollebasert og ofte gjemt "kun" bak en innlogging. Dermed må tilgangskontrollen være godt på plass for å sikre at ikke ansatte og samarbeidspartnere får tilgang til ting de ikke burde.
Dersom uvedkommende får administratortilgang til din konto hos skyleverandøren, kan de misbruke lagrede opplysninger, gjøre endringer i filer og innstillinger, og få tilgang til tjenestene og dataene som ligger lagret.
Sikre at så få som mulig har tilgang til tilgangskontroll og styring av denne. Vedkommende som har slik tilgang, bør som minimum ha tofaktorautentisering påslått.
Feilkonfigurasjon er en av de større utfordringene ved en migrasjon til skyen. I sitt hastverk med å komme seg til skyen er det mange virksomheter som ikke bruker nok tid eller skaffer seg god nok kompetanse, på oppsett og konfigurering. Dermed ender de opp med å eksponere data og ressurser som aldri burde ha vært eksponert. Dette kan for eksempel sees i at ressurser som burde ha vært private, blir opprettet som offentlige, slik at ikke-autentiserte brukere også kan få tilgang til disse.
Pass på at du godt nok forstår forskjellen i konfigurasjon i sky og i on-premise teknologi. For eksempel kan en penetrasjonstest være med og hjelpe deg å forstå om det er blitt innført nye sårbarheter basert på migrering til skyen.
Ettersom ressurser i sky opprettes rimelig on-demand, handler mye av sikkerheten om tilgangskontroll og riktig konfigurasjon. Man ser ofte datalekkasjer som skjer via såkalte "Leaky AWS S3 Buckets", som handler om datalagring som ikke blir konfigurert riktig, og dermed eksponerer data offentlig.
Når man setter opp tilganger til lagringssystemer, må man være sikker på at nødvendig rettigheter er begrenset, og at man ikke ved feiltagelse åpner opp for mye tilgang.
Det gjøres mye integrasjoner mellom forskjellig programvare og plattformtjenester i skyen. Disse er ikke alltid gjort på en god og sikker måte, og eksponerer dermed svakheter som ikke var tiltenkt.
API, eller tjenester som ServiceBus og tilsvarende, ligger eksponert på internett og kan enkelt utnyttes til å kjøre kode eller å komme videre inn i systemene. Manglende eller dårlig autentisering i integrasjoner er noe som forekommer ofte i sky.
Enhver bedrift som flytter seg til sky, må forstå seg på sin egne angrepsflate for å hjelpes i sikkerhetsproblematikken.
Audit og loggdata er ofte deaktivert som standard i skymiljøer, men de er særdeles verdifulle. Blant annet brukes de til hendelseshåndtering eller gjennomgang av mistenkelig aktivitet. I sky er disse ofte sentraliserte og samlet på ett sted, noe som gjør dem enklere å lese gjennom, siden man slipper å samle og korrelere logger fra mange forskjellige systemer.
Det anbefales å skru på audit og loggdata, samt videre overføre disse loggdata til en sentralisert loggtjeneste som gjerne overvåkes av et Security Operations Center.
Sky har ofte gode muligheter for å forebygge DDoS-angrep, som også kan skaleres etter hvor nødvendig det er. De fleste skyleverandører tilbyr en enkel DDoS-beskyttelse som dekker mot de vanligste former angrep.
Om du er en liten bedrift, kan du få en begrenset DDoS-beskyttelse som tar seg av det som er av vanlig rusk på nettet. Hvis du derimot er en større og mer profilert bedrift, kan man skaffe seg mer beskyttelse etter som trusselbildet krever det.
Å patche er like viktig i sky som on-premise. Stadig flere enheter brukes utenfor kontoret, i usikrede trådløse nettverk, og dette utgjør en sikkerhetsrisiko. Eksponert angrepsflate med sårbare teknologier vil alltid kunne resultere i tap av konfidensialitet, integritet og tilgjengelighet.
Skyen er hyggelig slik at mye av infrastrukturen som benyttes blir patchet for deg. For eksempel. dersom man leier en server, blir nettverkskomponenter tilkoblet serveren autoamtisk patchet for deg, i det minste i moderne skymiljøer.
API-nøkler brukes for å bekrefte at det kun er de tjenestene som skal ha tilgang til ressurser, som får tilgang. Imidlertid har vi gjentatte ganger sett at utviklere ikke håndterer API-nøkler trygt, eller for eksempel glemmer å fjerne dem fra kildekode som publiseres, noe som gjør at ondsinnede aktører kan få tilgang til selskapets ressurser.
Det anbefales å forvente at API-tilgang aksesseres uautorisert, uten gjennom de tiltenkte kanalene. Penetrasjonstesting og god programmeringsskikk vil hjelpe med å redusere risikoen.
Ofte kommer skyløsninger som en "ready-to-fire"-løsning, som kan ha tjenester som et selskap ikke bruker. Dette kan føre til at det eksponeres tjenester som selskapet ikke kjenner til eller vedlikeholder. Følgelig er det avgjørende å holde styr på hva som kjører i miljøet.
Hvis det f.eks. kjøres en tjeneste som selskapet ikke kjenner til, og som dermed ikke oppdateres, kan det føre til at kjente sårbarheter dukker opp i skymiljøet. Dermed kan angripere få en vei inn utenom det som er den tiltenkte ressursen. Et eksempel på dette er at RDP som standard er åpen i Azure, uansett om du skal bruke det eller ikke, så du må selv gå inn selv og skru det av.
Å sikre kontroll på tjenestene som man eksponerer, er ikke alltid like lett, men det anbfales å gjøre tilstrekkelig research og rådføre seg med eksperter rundt sikkerhet på sky, før man tar i bruk hva som helst.
Noen skyleverandører skiller ikke godt nok mellom de forskjellige kundene som deler samme sky, gjerne de mindre modne aktørene. Dette kan føre til at hvis en kunde blir kompromittert, kan angriperne flytte seg fra den første kunden til så videre å angripe og kompromittere andre kunder som har miljøet sitt i samme sky. Dersom angripere kan bevege seg sidelengs i skymiljøet, pga. manglende kontroller fra leverandør, kan det ha store konsekvenser for den enkelte kunde.
Pivoting kan forhindres ved å bygge sterk segmentering mellom tjenestene, f.eks. ved å ta i bruk brannmurer og streng aksesskontroll. Moderne skyleverandører som Azure, Amazon og Google har implementert gode løsninger for dette, mens andre mindre seriøse aktører bør nøye vurderes i forkant.
Når alt er tilgjengelig online i en sky, blir viktigheten av gode passordrutiner og tofaktorautentisering enda viktigere enn før. Et passord på avveie vil kunne føre til at en angriper får tilgang til mange flere ressurser enn denne nødvendigvis hadde fått i et on-premise-miljø. Dette avhenger naturligvis veldig av konfigurasjonen og oppsettet til hvert enkelte skymiljø.
Følgelig er det viktig med sikker lagring, trygg henting og rotering av credentials, slik at tilganger kan holdes så oppdatert som mulig, og at man unngår at passord kommer på avveie.
Ingen løsninger er 100 prosent sikre, uavhengig av om de er i skyen eller on-premise, og selv om man føler en løsning er tilstrekkelig sikret, blir den aldri 100 prosent sikker. Mange av sikkerhetsutfordringene man finner i skyen, er de samme man finner i tradisjonelle datasentre, men konsekvensene kan fort bli større i skyen. Feil i skymiljøer kan ha katastrofale følger, og man kan gjerne ikke bare “trekke ut internett-kabelen” for å begrense et angrep.
Sky har mange gode løsninger, men man må være obs på særegenhetene ved det. Kompetanse på sky er ofte manglende, og da gjør man fort feil om man bare hiver seg ut i det. For eksempel er mangel på skykompetanse årsaken til problemer som feilkonfigurerte S3 Buckets og lignende oppstår.
Man må gjøre en risikovurdering før skytjenester tas i bruk, og basert på resultatet av denne innføre nødvendige sikkerhetstiltak for å minimere denne risikoen. Tiltakene kan være av teknisk art, prosesser, opplæring, m.m.
Hvis din bedrift skal flytte fra on-premise til skyen, trenger dere spesialisert kompetanse på dette feltet for å unngå å gjøre feil i migreringen.