Illustrasjon.
Illustrasjon. (Bilde: Colourbox)

Dette må du vite om sikkerhet i skyen

  • Debatt
Marius Sandbu er seniorkonsulent i Evry Cloud Services.
Marius Sandbu er seniorkonsulent i Evry Cloud Services. Foto: Evry

Bruken av skytjenester vokser i et voldsomt tempo – og gir en rekke fordeler som blant annet bedre kontroll på kostnader, økt fleksibilitet og fantastiske muligheter for eskalering. Men mindre kjent er sikkerhetsutfordringene som man også må ha kontroll på når skybruken eksploderer.

Risikoelementene spenner fra ansatte hos skyleverandørene med uærlige hensikter, til usikre datasystemer, filer andre får tilgang til, og risiko for tap eller lekkasje av data. Basert på daglige samtaler med våre kunder har vi konkretisert ti sikkerhetsrisikoer i skyen – og hvordan du håndterer dem:

1. Ta i bruk multifaktor-autentisering og føderert tilgang

De som setter opp skytjenesten vil som oftest ha full administrativ tilgang på abonnementet. Dette gir mulighet til å provisjonere og sette opp nye ressurser, eller endre og modifisere det som er satt opp. Om denne tilgangen kommer på avveie kan uvedkommende få tilgang til ditt abonnement hos leverandøren, og potensielt gjøre stor skade. De kan misbruke lagrede opplysninger, gjøre endringer i filer og innstillinger, og få tilgang til tjenestene og dataene som ligger lagret. De fleste leverandører støtter multifaktor-autentisering, slik at man for å logge på må ha brukernavn, passord og en kode via SMS, eller programvare på mobilen. I tillegg støtter de fleste leverandører føderert tilgang. Dette gir enda tryggere innlogging ved at autentisering flyttes fra leverandør tilbake til kundens eventuelt eksisterende identitetsløsning, som ofte tillater bedre innsikt og regelstyring.

2. Sett opp automatisert brukeradministrasjon

Det er viktig å benytte et verktøy som håndterer oppretting av passord og tilgangsstyring på tvers av ulike skyløsninger, slik at brukerne får én identitet å forholde seg til. Dette øker også sikkerheten ved at tilganger kan fjernes med en gang en bruker slutter. De fleste leverandører tilbyr allerede slike verktøy, men krever at man selv konfigurer dem.

3. Endre og eller fjern standardtilgang

De fleste leverandører har lagt til rette for at brukeren enkelt skal få tilgang til virtuelle maskiner, remote desktops og SSH (kryptert tunnel for datatrafikk som fungerer på applikasjonslaget). Dette betyr at alle nye virtuelle maskiner man setter opp i utgangspunktet vil ha portene som kreves åpne. Dette utgjør en fare for sikkerheten, da det er vanlig for hackere å sjekke disse. Her bør man enten låse de aktuelle portene eller endre numrene for å maskere åpningen. Det er viktig å låse ned tilgangen med brannmurregler mot gitte adresser og porter. Det er også en opsjon å drive administrasjon av virtuelle ressurser hos en leverandør via for eksempel en VPN-tunnel.

4. Spesifisert regelsett på automatiseringsløsningen

De fleste leverandører har en egen automatiseringsløsning som gjør at man kan dele opp provisjonene på hele miljøet ved hjelp av en ferdig mal. Malene gir fordeler ved at man får satt opp infrastrukturen på kort tid. Det er viktig å være oppmerksom på at disse også kan brukes til å overskrive eksisterende konfigurasjon. Hvis noen hos leverandøren ved uhell bruker en eksisterende mal mot en eksisterende kunde, kan de overskrive kundens ressurser. Det er derfor viktig at man selv tar seg tid til å sette opp regler for automatiseringsløsningen. 

5. Lås viktige ressurser og definer rollebasert tilgang

Man har mulighet til å sette lås på essensielle data for å unngå at de blir slettet ved et uhell. Samtidig er det viktig å definere tilgangsrollene skikkelig, slik at ingen får tilgang til funksjoner eller objekter som ligger utenfor ens rolle.

6. Sett opp databeskyttelse og kryptering av data

De fleste leverandører tilbyr en overflod av løsninger, men tar som regel ikke backup av kunders data. De kan ikke vite hva som er viktig å ta backup av, eller hvor ofte det trengs. Noen leverandører tilbyr integrerte backup-løsninger, men man må selv passe på å sette opp disse. Et fåtall leverandører krypterer brukerdata, men de fleste lar brukeren selv sette opp kryptering med egne nøkler. Ulempen med dette er hvis man mister nøkkelen. Leverandøren vil da ikke kunne hjelpe til med å skaffe tilgang til dataene.

7. Samle logger og hendelsesdata lokalt for gransking

Alle hendelser som skjer blir som regel loggført av leverandøren via et eget verktøy. Man bør se på mulighetene for å samle loggene lokalt, eller sjekke om leverandøren tilbyr en sentralisert mulighet for analyse og gransking av loggførte hendelser.

8. Forsterk sikkerheten på applikasjoner

Det er viktig å ta i bruk nyere SSL-/TSL-funksjoner som fjerner støtten for utdaterte SSL-protokoller (kryptografiske protokoller for sikker kommunikasjon). Dette gjelder spesielt om man benytter seg av egne applikasjoner eller koder. Her kan man gjerne følge anbefalinger fra ssllabs.com, eller overlate dette til leverandøren, som ofte har egne balanseringsløsninger som kan håndtere dette.

9. Vurder å ta i bruk applikasjonsbrannmur og beskyttelsesfunksjoner

Se på behovet for å ta i bruk brannmur og DDoS-beskyttelse. Om du har usikre applikasjoner, eller bare er usikker på hvor trygge de er, har de fleste leverandører egne brannmurløsninger som dekker for både CSRP, XSS og SQL injeksjoner. I tillegg tilbyr de fleste leverandører en enkel DDoS-beskyttelse som dekker mot de vanligste former angrep. Enkelte leverandører tilbyr dedikerte DDoS-tjenester som beskytter mot et bredt spekter av angrep. 

10. Studer leverandørens sikkerhetstjenester, og innled dialog

De fleste leverandører prøver å operere proaktivt og tilbyr gjerne en sikkerhetsrådgivningstjeneste som ser på hver enkelt kundes behov. Utviklingen er kontinuerlig og nye sikkerhetstiltak blir lagt til med jevne mellomrom. Innled dialog med leverandøren for å få svar på eventuelle spørsmål.

Leverandørene vil informere kunder som de oppdager at har blitt kompromittert, eller om de har oppdaget mistenkelig trafikk som ved for eksempel et DDoS-angrep. 

 

Kommentarer (2)

Kommentarer (2)
Til toppen