Sikkerhet og compliance

I skyen er sikkerhet et delt ansvar mellom skyleverandøren og virksomheten din. Leverandørene sikrer den underliggende infrastrukturen, mens du har ansvar for data, applikasjoner og tilganger. Her får du praktisk veiledning i hvordan du kan implementere sikkerhet som kan oppfylle regulatoriske krav.

Denne delen av rammeverket gir deg en praktisk veiledning for sikkerhet og compliance i skymiljøer. Den dekker både planlegging før og etter anskaffelse. I avsnittene under beskrives sentrale sikkerhetsprinsipper og anbefalte praksiser som er relevante for bruk av sky. Sikkerhetsprinsippene er basert på NSMs grunnprinsipper for IKT-sikkerhet.

Hver del vil peke på relevante sikkerhetsprinsipper, før de prinsippene presenteres i sin helhet mot slutten av denne veiledningen.

Operasjonalisering av sikkerhet

Du må operasjonalisere sikkerheten ved å automatisere den der det er mulig, integrere det i utviklingsprosesser og overvåke den kontinuerlig.

Sikkerhetskrav er som regel formulert på et høyere abstrakt nivå. Det vil si at kravene er overordnet, og det er virksomhetens eget ansvar å oversette dem til konkrete tekniske tiltak i deres plattform.

Delt ansvarsmodell

Ansvaret er basert på hvilken tjenestemodell (SaaS, PaaS eller IaaS) som benyttes.

Modellen her viser hvordan ansvaret er fordelt mellom skyleverandør og deg som kunde
KategoriInnholdBeskrivelse
Fysisk sikkerhetDatasentre med adgangskontrollSikrer at kun autoriserte personer får fysisk tilgang til datasentrene
Fysisk sikring av maskinvareBeskytter servere og utstyr mot tyveri og hærværk
Strømforsyning og kjølingOpprettholder strømtilførsel og riktig temperatur
BrannvernInstallerer systemer og redskaper for brann
InfrastrukturVedlikehold av maskinvareSørger for at maskinvare oppdateres etter behov
NettverkLeverer nettverksforbindelse mellom systemer og tjenester
VirtualiseringHåndterer virtuelle maskiner som kjører tjenester
Leverandørens ansvar
KategoriInnholdBeskrivelse
DataKlassifiseringIdentifiserer hvilke data som er sensitive
KrypteringSørger for at data krypteres under lagring og overføring
SikkerhetskopieringPlanlegger og gjennomfører sikkerhetskopiering
SlettingFjerner data når de ikke lenger er nødvendig eller når det kreves (regulatoriske krav)
ApplikasjonerApplikasjonskodeUtvikler applikasjoner som kjøres på plattformen
UtviklingImplementerer nye funksjoner i applikasjonene
Oppdatering av applikasjonerSørger for at applikasjoner er oppdatert
TilgangIdentitets- og tilgangsstyringAdministrerer hvem som har tilgang til hva
BrukerhåndteringOppretter, endrer og fjerner brukerkontoer
AutentiseringSikrer at brukere bekrefter sin identitet på en sikker måte
AutoriseringDefinerer og håndhever hva brukere har lov til å gjøre i systemene
NettverkBrannmurKonfigurerer og overvåker nettverkstrafikk
NettverkssegmenteringDeler opp nettverk for å øke sikkerhet
Konfigurasjon av sikker tilkoblingSørger for å sikre forbindelser mellom brukere og tjenester
Virksomhetens ansvar

Dette støtter følgende prinsipper:

  • Prinsipp 1: Kartlegg IKT-systemer og tilhørende ressurser
  • Prinsipp 2: Kartlegg brukere og tilgangsbehov
  • Prinsipp 12: Sikre tjenester og leverandører

Skal du kjøpe eller bruke skytjenester?

Markedsplassen for skytjenester (MPS) har publisert en referansearkitektur med grunnleggende krav til informasjonssikkerhet og personvern i skyavtaler som kan brukes ved anskaffelse av skytjenester. Referansearkitekturen er mappet til internasjonale standarder.

Sikkerhet i skyprosjekter

Sikkerhet må være med i designfasen av prosjektet – den skal ikke være en ettertanke. Benytt prinsipper som trusselmodellering, minste privilegium, forsvar i dybden, sikker feiltilstand og minimal angrepsflate.

Disse bygger på følgende prinsipper:

  • Prinsipp 5: Vurder risiko.
  • Prinsipp 2: Etabler sikkerhetsarkitektur og design.
  • Prinsipp 8: Kontroller identiteter og tilgangsstyring.
  • Prinsipp 13: Beskytt klienter, servere og tjenester.
  • Prinsipp 14: Beskytt nettverk og grensesnitt.

Trusselmodellering

Trusselmodellering handler om å identifisere trusler tidlig, forstå angrepsflater og prioritere sikkerhetstiltak. Prosessen er slik:

  1. Tegn arkitekturdiagram
  2. Identifiser ressurser (data og tjenester)
  3. Identifiser trusler – STRIDE-modell
  4. Vurder sannsynlighet og konsekvens
  5. Definer mitigering
  6. Prioriter basert på risiko
KategoriForklaringEksempler
S – Spoofing (Identitetsforfalskning)Angriperen utgir seg for å være noen andre.- Stjålet brukerkonto (brukernavn og passord)
- Falske innloggingsforespørsler
T – Tampering (Manipulasjon av data)Uautorisert endring av data. Kan være data som ligger lagret, er i bruk eller under overføring.- Endre data i en database
- Manipulere filer eller konfigurasjon
R – Repudiation (Benektelse)Manglende sporbarhet som gjør at en bruker eller angriper kan skjule og nekte sine handlinger.- Ingen logger
- Endrede logger
- Handlinger som ikke kan knyttes sikkert til en identitet
I – Information disclosure (Informasjonslekkasje)Uautorisert tilgang til sensitiv informasjon.- Datainnbrudd
- Feilkonfigurerte lagringstjenester
- Sniffing av nettverkstrafikk
D – Denial of service (Tjenestenekt)Angrep som gjør systemet utilgjengelig.- DDoS (Distributed Denial of Service) angrep
- Tømming av ressurser
- Låsing av kritiske funksjoner
E – Elevation of Privilege (Rettighetseskalering)Angriperen får høyere privilegier.- Bruker blir administrator
- Tjeneste får tilgang til systemressurser den ikke skulle hatt
- Sårbarheter som lar angripere omgå tilgangskontroll
STRIDE-modellen

Minste privilegium

Minste privilegium vil si at du gir minimum nødvendig tilgang. Du gir kun den tilgangen som brukeren trenger for å utføre sin oppgave, og den skal ikke gi rettigheter utover det som er nødvendig. Ta i bruk implementasjoner som rolle-basert tilgangskontroll (RBAC) og tidsbestemt tilgang.

Et eksempel på dette kan være en utvikler som skal utrulle og teste applikasjoner i et testmiljø. Dersom vedkommende får en tilgang eller en rolle som gir administrative rettigheter for flere miljøer, vil dette være et brudd på prinsippet. Riktig bruk er å tildele en rolle som kun gir tilgang til det aktuelle miljøet og kun de rettighetene som er nødvendig for oppgaven. Hvis utvikleren skal ha midlertidig tilgang, kan tidsbestemt tilgang benyttes for den perioden slik at tilgangen utløper automatisk.

Forsvar i dybden

Ha flere lag med sikkerhet. Det er ikke nok å stole på kun en tjeneste eller kontroll. Dersom ett lag feiler, er det høyere sannsynlighet for at det neste fanger opp angrepsforsøket. Lag kan være følgende:

  • Yttergrense: brannmur, DDoS beskyttelse
  • Nettverk: segmentering, sikkerhetsgrupper for nettverk
  • Prosessering: herdet operativsystem, antivirus
  • Applikasjon: WAF (Web application firewall), inndatavalidering (Input validation)
  • Data: kryptering, beskyttelse mot datatap
  • Identitet: multifaktorautentisering, betingelsesbasert tilgang

Sikker feiltilstand

Målet med sikker feiltilstand er å håndtere feil på en kontrollert og trygg måte, i stedet for å fortsette i en usikker og ukontrollert tilstand.

SituasjonSikker feiltilstandForklaring
Feil på serverTjenesten stopper kontrollertForhindrer datatap og begrenser påvirkning på brukere
DatabasefeilSystemet går i en skrivebeskyttet tilstandSikrer at data ikke blir ødelagt eller korrupt mens feilen håndteres
Sikkerhetsbrudd oppdagesKontoer låses midlertidig eller tilgang begrensesReduserer risiko for videre skade og datalekkasjer
Eksempler på sikker feilstand

Minimal angrepsflate

Det er viktig å redusere antall inngangspunkter og tjenester som kan utnyttes av angripere. Jo færre komponenter, brukere og nettverksporter som er tilgengelige, desto mindre sjanse har en angriper på å komme seg inn i systemene.

TiltakForklaring
Deaktivere ubrukte tjenesterFjern eller slå av tjenester som er unødvendige eller ikke i bruk.
Begrense administrative rettigheterGi brukere og tjenester kun de rettighetene som er nødvendige for å utføre arbeidet (minste privilegium).
Stenge unødvendige nettverksporterÅpne kun de portene som faktisk trengs for kommunikasjon og applikasjoner.
Segmentering av nettverk og ressurserHa et klar skille mellom kritiske systemer og mindre sensitive miljøer for å begrense spredning ved et angrep.
Eksempler på tiltak som minimerer angrepsflaten

Sikkerhetsvurdering

En strukturert sikkerhetsvurdering hjelper deg med å identifisere risikoer, sikre at sensitive data håndteres riktig og at løsningene oppfyller regulatoriske krav. Det er en prosess som omfatter data, arkitektur, compliance, trusler og testing. Prosessen kan kjøres ved oppstart av nytt prosjekt, større endringer i eksisterende miljø, periodisk eller før produksjonssetting.

KategoriInnholdBeskrivelse
DataklassifiseringType dataKartlegge hvilke data som behandles i systemet
KlassifiseringOffentlig, intern, konfidensiell eller hemmelig
DatalagringVurdere fysisk og digital plassering av data
DatabeskyttelseMetoder for kryptering, tilgangskontroll og sikkerhet
ArkitekturNettverksdiagramVisualisering av nettverkets struktur og forbindelser
DataflytdiagramOversikt over hvordan data beveger seg mellom systemer
Autentisering og autoriseringMetoder for å kontrollere hvem som får tilgang til systemet
KrypteringBeskyttelse av data både i lagring og under overføring
ComplianceGDPRSikre at løsningen oppfyller kravene i personvernforordninger
PersonopplysningerIdentifisere og håndtere sensitive personopplysninger
Avtaler for databehandlingSikre at eksterne avtaler følger regulatoriske krav
TrusselmodelleringIdentifisere truslerKartlegge potensielle trusler mot systemet
RisikovurderingVurdere sannsynlighet og konsekvens av identifiserte trusler
MitigeringTiltak for å redusere risiko og minimere konsekvenser
TestingTesting av sikkerhetGenerell vurdering av systemets sikkerhet
PenetrasjonstestingSimulere angrep for å identifisere sårbarheter
Skanning etter sårbarheterAutomatisert eller manuell gjennomgang for å oppdage svakheter
Vurderingsområder

Bruk en praktisk sjekkliste som kartlegger sikkerheten i deres miljø. Eksempel på en sjekkliste for dette:

Sjekkliste for sikkerhet i nye prosjekter:

Før utvikling:

  • Dataklassifisering utført
  • Trusselmodellering gjennomført
  • Sikkerhetskrav definert
  • Sikkerhetsansvarlig utpekt

Under utvikling:

  • Retningslinjer for programmering følges
  • Passord og andre sensitive verdier ikke synliggjort
  • Avhengigheter skannes for sårbarheter

Før produksjonssetting:

  • Penetrasjonstesting gjennomført
  • Sikkerhetsdokumentasjon komplett
  • Logging og monitorering konfigurert
  • Sikkerhetsvurdering godkjent

Tilgangsstyring og identitetsforvaltning

Identitets- og tilgangsstyring (IAM) er et viktig fundament i skysikkerhet. IAM som er riktig implementert, sikrer at riktige personer har riktig tilgang, til riktige ressurser på riktig tidspunkt. IAM-prinsipper som minste privilegium, separasjon av ansvar og tilgang ved behov (Just-in-time access) bidrar til å sikre identiteter og tilganger.

Som nevnt tidligere, er minste privilegium basert på at brukere og tjenester får kun nødvendige tilganger. Administrator og forhøyede rettigheter skal ikke deles ut til mange brukere. En praktisk måte å implementere dette på, er å begynne med ingen tilgang. Deretter gir du tilgang basert på behov, og utfører en periodisk evaluering av tilganger. Dersom det avdekkes tilganger som ikke lenger er nødvendige i disse evalueringene, skal de fjernes.

Separasjon av ansvar vil si at en person ikke skal gjennomføre kritiske operasjoner alene. Det skal kreve samarbeid og godkjenning slik at utførelsen er kontrollert. Eksempler på dette:

  • Utviklere kan ikke utrulle til produksjonsmiljøer uten godkjenning.
  • Sletting av produksjonsdata krever to personer.
  • Finansielle transaksjoner krever en grundig gjennomgang.

Tilgang ved behov baserer seg på tidsbegrenset tilgang som kun skal forhøyes ved behov, med begrunnelse. Dette reduserer angrepsflate og risiko ved uautorisert tilgang på konto. En bruker kan ha lesetilgang til systemet, men når det er behov for mer tilgang kan vedkommende be om tilgang ved å legge inn en forespørsel med begrunnelse og varighet. Denne tilgangen kan enten godkjennes automatisk eller manuelt, basert på konfigurasjon. Denne forespørselen blir logget.

Dette støtter følgende prinsipper:

  • Prinsipp 2: Kartlegg brukere og tilgangsbehov.
  • Prinsipp 8: Kontroller identiteter og tilgangsstyring.
  • Prinsipp 20: Håndter sikkerhetshendelser effektivt.

Logging og revisjon

Logging og revisjon er en viktig del av sikkerheten. De gir innsikt i hvordan tilgangene brukes, endringer som blir utført og hvilken bruker som gjør hva. Dette gjør det mulig å etterforske hendelser og oppdage uvanlige aktiviteter. For å oppnå det må loggingen være konfigurert til å være helhetlig, nøyaktig og beskyttet mot manipulering. Loggingen må også være tilgjengelig for analyse gjennom sentraliserte løsninger som støtter overvåkning, varsling og revisjon.

KategoriLogg
AutentiseringVellykkede innlogginger
Mislykkede innlogginger
Multifaktorautentisering
Innlogging fra nye lokasjoner og enheter
AutorisasjonTilgang til ressurser
Endringer i rettigheter
Administrative handlingerOpprettelse og sletting av ressurser
Endringer i konfigurasjon
Brukeradministrasjon
DataHandlinger (Lese og skrive) mot sensitiv data
Eksportering av data
Hva skal logges?

Det anbefales å ha sentralisert logging. Det vil si at alle logger ligger på et sted. Dette gjør det enklere å søke og analysere hendelser på tvers. Du kan ta i bruk SIEM (Security Information and Event Management) – et verktøy som gir deg en sentral plattform for sikkerhetshendelser hvor du kan få data fra mange kilder, analysere dem og konfigurere varsling.

Dette støtter følgende prinsipper:

  • Prinsipp 16: Etabler logging og sporbarhet.
  • Prinsipp 17: Overvåk systemer og sikkerhetstilstand.
  • Prinsipp 18: Detekter sikkerhetshendelser.

Kryptering og databeskyttelse

Kryptering er en av de viktigste sikkerhetskontrollene i skyen. Data som lagres og overføres, må beskyttes. Alle leverandørene i vår rammeavtale tilbyr omfattende muligheter for kryptering, men det er også viktig at du forstår alternativene, og at du tar bevisste valg.

Datakryptering

Dette betyr at informasjonen gjøres uleselig for alle som ikke har en nøkkel. Det beskytter mot innsyn og misbruk. Nøklene fungerer som digitale passord som låser opp den krypterte informasjonen.

Kryptering og databeskyttelse støtter følgende prinsipper:

  • Prinsipp 4: Kategoriser informasjon og systemer.
  • Prinsipp 9: Sikre data i ro og under overføring.
  • Prinsipp 21: Gjenopprett normal drift og lær av hendelser.

Kryptering i overførelse

Også kjent som "In transit". Det vil si når data sendes mellom systemer, brukere og tjenester. TLS (Transport Layer Security) er dagens standardprotokoll for å beskytte kommunikasjon på tvers av nettverk. Riktig bruk av moderne TLS-versjoner og sikre ((sertifikater+Et sertifikat kan ansees som en digitalt identifikasjon. Den brukes for å bekrefte identiteten til en server, tjeneste eller bruker.)) er nødvendig for å sikre data og oppfylle regulatoriske krav.

TLS krypterer data mellom to endepunkter. Det kan være kommunikasjon mellom brukere og applikasjoner, tilkoblinger mot databaser og fjernstyring av tjenester. TLS-versjoner har ulike sikkerhetsnivåer:

  • TLS 1.3: anbefalt og mest sikker
  • TLS 1.2: akseptabelt og minimum standard
  • TLS 1.1 og eldre: utdatert og må ikke brukes

Sertifikathåndtering er en sentral del for sikker kommunikasjon i interne og eksterne systemer. Digitale sertifikater bekrefter identiteten til tjenester, og gjør at kommunikasjon gjennom TLS er kryptert. For å opprettholde en sikker infrastruktur må sertifikater velges, administreres og fornyes riktig. Det finnes ulike typer sertifikater:

  • Public ((CA+Certificate Authority – en tjeneste som lager og signerer digitale sertifikater som brukes til å bevise identitet i datasystemer. Den bekrefter hvem noen er og utsteder et sertifikat som andre kan stole på. Dette gjelder både for offentlige og interne miljøer.)): for offentlig tilgjengelige tjenester
  • Private CA: for interne tjenester
  • Selvsignert: kun for testing og ikke for produksjon

Livssyklusen til et sertifikat begynner med at det utstedes, installeres, overvåkes for utløpsdato og fornyelse. Ved tilfeller hvor sertifikatet er kompromittert, må det tilbakekalles. Det anbefales at sertifikatet har kort levetid (90 dager), fornyes automatisk, og at det tas i bruk tjenester for sertifikathåndtering der det er en mulighet for det.

Kryptering ved lagring

Også kjent som "At rest". Data som lagres, må du kryptere slik at selv om den fysiske lagringsenheten eller sikkerhetskopien blir stjålet, er dataen uleselig uten krypteringsnøkkelen. Leverandørene tilbyr blant annet følgende tjenester for dette:

  • AWS: EBS encryption
  • Google Cloud: Persistent encryption
  • Oracle Cloud: Block Volume encryption
  • IBM Cloud: Block Storage encryption

Standard er at leverandøren administrerer krypteringsnøklene, men du kan administrere dem selv også (Customer-managed keys). Det gjør at virksomheten din får mer kontroll over nøklene, men det krever mer administrativt arbeid. For de fleste bruksområdene holder det med at leverandøren har ansvar for dem, men dersom det er et compliance krav om kontroll av nøkler, og du har høyt klassifiserte data, er det anbefalt å administrere dem selv.

Nøkkelhåndtering

Håndtering av krypteringsnøkler er avgjørende for å sikre data i både skyen og i interne systemer. En tjeneste for nøkkelhåndtering, også kjent som KMS (Key Management Service), gir en sentralisert og kontrollert måte å generere, lagre og rotere kryptografiske nøkler på. Det gjør at applikasjoner ikke trenger å håndtere nøklene direkte. Du får sikker lagring, tilgangskontroll, logging og automatisk rotasjon for nøklene.

Nøkkelrotasjon innebærer å bytte krypteringsnøklene regelmessig. Dette reduserer risikoen for at nøkkelen blir kompromittert. Manuell rotasjon krever at du initierer rotasjonen selv, hvorav automatisk rotasjon som gjøres av KMS-tjenesten selv. Beste praksis er å benytte seg av den automatiske rotasjonen, rotere nøklene minimum årlig og overvåke bruken.

Compliance

Compliance handler om å sikre at virksomheter oppfyller regulatoriske krav og interne retningslinjer. Det må dokumenteres at skybruk skjer i tråd med disse. Ansvaret deles mellom din virksomhet og skyleverandøren, men det er du som har det endelige ansvaret for å dokumentere etterlevelse.

Regulatoriske krav og standarder

Virksomheten din må forstå hvilke lover, forskrifter og standarder som gjelder for deres data og tjenester.

  • GDPR - Personvernforordningen stiller krav til behandling av personopplysninger
  • NIS2 - Krav til sikkerhet i kritisk infrastruktur
  • ISO - Standarder for informasjonssikkerhet
  • Bransjespesifikke krav - Kan være for finansielle reguleringer (SOX) eller helselovgivning (HIPAA)

Det er anbefalt å lage en oversikt over hvilke standarder og krav som er relevante. Da kan du danne deg en oversikt over hvilke som må etterleves direkte, og hvilke som kan støttes av leverandørens sertifiseringer.

Les mer om digitale reguleringer i EU.

Dataklassifisering og behandling

For å sikre compliance må virksomheten din ha kontroll på hvilke data som håndteres, hvor de lagres og hvordan de beskyttes.

  • Identifisering av sensitiv data: Personopplysninger, økonomiske data, helseopplysninger og annet som kan ansees som sensitivt for virksomheten, må kategoriseres.
  • Lokasjon og datasuverenitet: Data skal lagres i samsvar med krav om nasjonalitet og regulatoriske restriksjoner
  • Behandling og sikkerhet: Implementer kryptering, tilgangskontroll, sikker sletting og overvåking.

Identifiser hvilke data som er sensitive, konfidensielle eller offentlig tilgjengelige. Bestem hvor data lages og behandles.

Overvåking, logging og raportering

Compliance krever sporbarhet og dokumentasjon av alle kritiske handlinger.

  • Logging: Registrer autentisering, autorisering, endringer i konfigurasjon og kritiske datahandlinger.
  • Sentralisert logging: Samle logger på ett sted for enklere analyse, revisjon og rapportering.
  • Rapportering: Dokumenter at tiltakene fungerer og oppfyller regulatoriske krav.

Kontinuerlig evaluering og revisjon

Compliance er en kontinuerlig prosess som krever regelmessig gjennomgang og forbedring.

  • Periodisk evaluering: Gå gjennom krav og retningslinjer jevnlig for å sikre at de er oppdaterte.
  • Teknisk evaluering: Bruk verktøy som ((CSPM+Cloud Security Posture Management – En løsning som hjelper virksomheter med å overvåke og sikre skyinfrastrukturen kontinuerlig. Den identifiserer feilkonfigurasjoner, manglende sikkerhetstiltak og brudd på interne eller eksterne retningslinjer innen sikkerhet. Den gir også anbefalinger for å redusere risiko. Leverandørene i rammeavtalen tilbyr CSPM løsninger.)) for å identifisere avvik og svakheter i skyinfrastrukturen.
  • Oppdatering av dokumentasjon: Revider sikkerhetsdokumentasjon og prosesser når nye krav eller endringer i skyplattformen skjer.

Arbeidet med compliance støtter disse prinsippene:

  • Prinsipp 1: Kartlegg IKT-systemer og tilhørende ressurser.
  • Prinsipp 4: Kategoriser informasjon og systemer.
  • Prinsipp 5: Vurder risiko.
  • Prinsipp 16: Etabler logging og sporbarhet.
  • Prinsipp 17: Overvåk systemer og sikkerhetstilstand.

Implementering av NSMs grunnprinsipper

NSM (Nasjonal sikkerhetsmyndighet) har utgitt rammeverket Grunnprinsipper for IKT-sikkerhet. Her tar vi for oss hvordan disse prinsippene kan oppfylles i skyen med eksempler på relevante tjenester fra leverandørene i rammeavtalen.

NSM sitt rammeverk er delt i fire deler.

Del 1: Identifisere og kartlegge

Prinsipp 1: Kartlegg IKT-systemer og tilhørende ressurser

Ha oversikt over maskinvare, programvare, data og brukere. I skyen kan du ta i bruk tjenester for inventar og merkelapper (Tags). Merk alle ressurser med eier, kostnadssted, dataklassifisering og miljø.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: AWS Config og Resource Groups
  • Google Cloud: Cloud Asset Inventory
  • Oracle Cloud: Cloud Guard
  • IBM: Resource tagging og Inventory

Prinsipp 2: Kartlegg brukere og tilgangsbehov

Du må ha oversikt over roller, grupper, privilegier og automatiserte prosesser for tilgangshåndtering. Dette innebærer å skape oversikt over IAM-brukere og roller, i tillegg til regelmessig revisjon av tilganger.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: IAM Access Analyzer
  • Google Cloud: IAM Recommender
  • Oracle Cloud: Identity Domains
  • IBM Cloud: IAM Access Groups

Prinsipp 3: Etablere og vedlikeholde oversikt over avhengigheter

Du skal ha en forståelse for hvilke systemer som avhenger av hverandre og dataflyten mellom disse. Leverandørene tilbyr verktøy for å se på nettverkskart og kartlegge avhengigheter.

Opprett arkitekturdiagrammer, kart over avhengigheter for applikasjoner og dokumenter integrasjoner. Jevnlige gjennomganger av arkitekturen sikrer at endringer ikke skaper uforutsette risikoer.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: VPC Flow Logs og X-Ray
  • Google Cloud: Network Topology og Cloud Trace
  • Oracle Cloud: Flow Logs og Service Connector Hub
  • IBM Cloud: Activity Tracker og Log Analysis

Prinsipp 4: Kategoriser informasjon og systemer

Definer hva som skal beskyttes og hvor godt, basert på konfidensialitet, integritet og tilgjengelighet. Definer ((RTO+RTO står for Recovery Time Objective, som er målet for gjenopprettingstid. Tiden angir hvor lenge et system kan være nede etter en hendelse før det skaper uakseptable konsekvenser.)) og ((RPO+RPO står for Recovery Point Objective. Det er målet for gjennopprettingspunktet. Det definerer hvor mye data man kan akseptere å miste etter en hendelse, basert på siste gjenopprettingspunkt.)) per system, klassifiser data (Offentlig, intern, konfidensiell eller hemmelig) og gjennomfør en risikovurdering for hver applikasjon.

Prinsipp 5: Vurder risiko

Identifiser trusler og sårbarheter. Gjør en vurdering på sannsynligheten og konsekvens. I skyen kan du ta i bruk CSPM for å få en oversikt over hvor godt sikret skymiljøet ditt er, og hvilke tiltak du kan prioritere for å øke sikkerheten. Bruk også trusselmodellering og gjennomfør en skanning for sårbarheter.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: Security Hub og Inspector
  • Google Cloud: Security Command Center
  • Oracle Cloud: Cloud Guard
  • IBM Cloud: Security and Compliance Center

Del 2: Beskytte og opprettholde

Prinsipp 6: Etabler sikkerhetsarkitektur og -design

Skyarkitekturen må bygges med sikkerhet som en prioritet. Du må velge de riktige tjenestene for sensitiv data og ha minste privilegium på alle ressurser.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: VPC, KMS og PrivateLink
  • Google Cloud: VPC Service Controls
  • Oracle Cloud: Vault og Network Segmentation
  • IBM Cloud: Hyper Protect

Prinsipp 7: Sikre konfigurasjon

Konfigurasjoner skal være konsistente, sikre og oppdaterte. Infrastruktur som kode reduserer menneskelige feil og gir sporbarhet. Dette gjør at du unngår manuelle endringer, og kan oppdage konfigurasjonsavvik.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: Config og Systems Manager
  • Google Cloud: Config Validator
  • Oracle Cloud: OS Management
  • IBM Cloud: Image Templater

Prinsipp 8: Kontroller identiteter og tilgangsstyring

Som nevnt tidligere, er IAM en av de viktigste sikkerhetsmekanismene i sky. Tilgang skal være minste privilegium og multifaktorautentisering bør være aktivert. Alle leverandørene i rammeavtalen har IAM tjenester.

Prinsipp 9: Sikre data i ro og under overføring

Aktiver kryptering på alle lagringsressurser, bruk TLS versjon 1.2 eller nyere for all kommunikasjon og administrer nøkler gjennom KMS-tjenester.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: KMS, EBS Encryption og S3 Encryption
  • Google Cloud: Cloud KMS og CMEK
  • Oracle Cloud: Key Management og Object Storage Versioning
  • IBM Cloud: Key Protect

Prinsipp 10: Håndter sårbarheter

Sårbarheter bør oppdages og håndteres raskt. Det bør gjennomføres regelmessige skanninger for sårbarheter, i tillegg til automatiserte oppdateringer.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: Inspector
  • Google Cloud: SCC Vulnerability Findings
  • Oracle Cloud: Vulnerability Scanning Service
  • IBM Cloud: Vulnerability Advisor

Prinsipp 11: Etabler sikre utviklings- og endringsprosesser

Konfigurer og integrer sikkerhet i prosessene for utrulling. Ha et krav for godkjenning før det blir utført endringer i produksjonsmiljøer.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: CodePipeline og CodeGuru
  • Google Cloud: Cloud Build og Binary Authorization
  • Oracle Cloud: DevOps Deployment Pipeline
  • IBM Cloud: Continuous Delivery og Vulnerability Advisor

Prinsipp 12: Sikre tjenester og leverandører

Skyleverandører er eksterne leverandører, og virksomheten din må dermed forstå delingen av ansvar. I anskaffelsesprosesser blir det deres oppgave å undersøke og vurdere leverandørens sertifiseringer, sikkerhet og tjenester.

Prinsipp 13: Beskytt klienter, servere og tjenester

Alt av maskinvare må du beskytte med antivirus, oppdateringer og grunnleggende sikkerhetsmekanismer.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: GuardDuty Malware Protection
  • Google Cloud: VM Manager
  • Oracle Cloud: OS Management
  • IBM Cloud: Endpoint and server protection

Prinsipp 14: Beskytt nettverk og grensesnitt

Nettverk må segmenteres og sikres med brannmurer. Kun nødvendig trafikk skal være tillatt.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: WAF, Shield og Security Groups
  • Google Cloud: Cloud Armor
  • Oracle Cloud: WAF
  • IBM Cloud: Cloud Internet Services

Prinsipp 15: Beskytt e-post og samhandlingstjenester

Phising og kontoovertakelse er vanlige angrep som skjer ofte. Beskyttelse må kombineres med opplæring. Ha opplæringskurs, workshops og periodiske påminnelser for brukerne om sikkerhet i tjenestene som brukes.

Del 3: Oppdage

Prinsipp 16: Etabler logging og sporbarhet

Skyplattformene gir muligheten til å ha detaljert logging av ressurser og nettverkstrafikk. Alle endringer skal være sporbare.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: CloudTrail og CloudWatch Logs
  • Google Cloud: Cloud Logging
  • Oracle Cloud: Logging
  • IBM Cloud: Log Analysis

Prinsipp 17: Overvåk systemer og sikkerhetstilstand

Kontinuerlig overvåking må være etablert for avvik, sårbarheter, feilkonfigurasjoner og trusler. Konfigurer automatiske varsler for sikkerhetshendelser, og opprett et oversiktspanel.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: Security Hub og GuardDuty
  • Google Cloud: Security Command Center
  • Oracle Cloud: Cloud Guard
  • IBM Cloud: Security and Compliance Center

Prinsipp 18: Detekter sikkerhetshendelser

Skyplattformene tilbyr tjenester som analyserer logger, trafikk og atferd. Dette bidrar til tidlig oppdagelse av angrep. Det er anbefalt å ha et regelverk for automatiserte tiltak og sette opp varslinger for uvanlig aktivitet.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: GuardDuty
  • Google Cloud: Event Threat Detection
  • Oracle Cloud: Cloud Guard Threat Detection
  • IBM Cloud: QRadar Cloud

Del 4: Håndtere og gjenopprette

Prinsipp 19: Etabler beredskap og forbered hendelseshåndtering

Det er viktig at dere har klare roller, ansvar og prosesser for håndtering av hendelser som oppstår i skymiljøet. Sett opp plan for håndtering av hendelser, ha øvelser og kontaktpunkter hos skyleverandøren.

I skymiljøer må beredskap også inkludere koordinering med leverandør og forståelse av ansvarsmodellen.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: CloudWatch og CloudTrail
  • Google Cloud: Cloud Monitoring, Event Threat Detection og Cloud logging
  • Oracle Cloud: Cloud Guard og Logging Service
  • IBM Cloud: Security and Compliance Center og LogDNA

Prinsipp 20: Håndter sikkerhetshendelser effektivt

Når en hendelse oppstår, må tiltak iverksettes raskt for å begrense skaden. Sporbarhet som tilbys av skyplattformenes logg- og sikkerhetstjenester, hjelper til med dette.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: GuardDuty og Security Hub
  • Google Cloud: Event Threat Detection
  • Oracle Cloud: Cloud Guard
  • IBM Cloud: QRadar

Prinsipp 21: Gjenopprett normal drift og lær av hendelser

Gjenoppretting må være planlagt og testet. Erfaringer fra testene bidrar til forbedringer. Utfør analyse av rotårsak, gjenoppretting fra backup og forbedring av eksisterende oppsett.

Eksempel på leverandørtjenester som kan støtte dette prinsippet:

  • AWS: Backup og Restore Manager
  • Google Cloud: Backup og Disaster Recovery
  • Oracle Cloud: Data Safe og Backup Service
  • IBM Cloud: Backup
Oppdatert: 9. oktober 2025

Kontakt

Gi oss tilbakemelding!

Har du spørsmål eller tilbakemeldinger? Ta kontakt med oss!

E-post: markedsplassen [at] dfo.no (markedsplassen[at]dfo[dot]no)

Fant du det du lette etter?

Nei

Det beklager vi!

Tilbakemeldingen din er anonym og vil ikke bli besvart. Vi bruker den til å forbedre nettsidene. Hvis du vil ha svar fra oss, ta kontakt på telefon, e-post eller kundesenter på nett.