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.

| Kategori | Innhold | Beskrivelse |
|---|---|---|
| Fysisk sikkerhet | Datasentre med adgangskontroll | Sikrer at kun autoriserte personer får fysisk tilgang til datasentrene |
| Fysisk sikring av maskinvare | Beskytter servere og utstyr mot tyveri og hærværk | |
| Strømforsyning og kjøling | Opprettholder strømtilførsel og riktig temperatur | |
| Brannvern | Installerer systemer og redskaper for brann | |
| Infrastruktur | Vedlikehold av maskinvare | Sørger for at maskinvare oppdateres etter behov |
| Nettverk | Leverer nettverksforbindelse mellom systemer og tjenester | |
| Virtualisering | Håndterer virtuelle maskiner som kjører tjenester |
| Kategori | Innhold | Beskrivelse |
|---|---|---|
| Data | Klassifisering | Identifiserer hvilke data som er sensitive |
| Kryptering | Sørger for at data krypteres under lagring og overføring | |
| Sikkerhetskopiering | Planlegger og gjennomfører sikkerhetskopiering | |
| Sletting | Fjerner data når de ikke lenger er nødvendig eller når det kreves (regulatoriske krav) | |
| Applikasjoner | Applikasjonskode | Utvikler applikasjoner som kjøres på plattformen |
| Utvikling | Implementerer nye funksjoner i applikasjonene | |
| Oppdatering av applikasjoner | Sørger for at applikasjoner er oppdatert | |
| Tilgang | Identitets- og tilgangsstyring | Administrerer hvem som har tilgang til hva |
| Brukerhåndtering | Oppretter, endrer og fjerner brukerkontoer | |
| Autentisering | Sikrer at brukere bekrefter sin identitet på en sikker måte | |
| Autorisering | Definerer og håndhever hva brukere har lov til å gjøre i systemene | |
| Nettverk | Brannmur | Konfigurerer og overvåker nettverkstrafikk |
| Nettverkssegmentering | Deler opp nettverk for å øke sikkerhet | |
| Konfigurasjon av sikker tilkobling | Sørger for å sikre forbindelser mellom brukere og tjenester |
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:
- Tegn arkitekturdiagram
- Identifiser ressurser (data og tjenester)
- Identifiser trusler – STRIDE-modell
- Vurder sannsynlighet og konsekvens
- Definer mitigering
- Prioriter basert på risiko
| Kategori | Forklaring | Eksempler |
|---|---|---|
| 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 |
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.
| Situasjon | Sikker feiltilstand | Forklaring |
|---|---|---|
| Feil på server | Tjenesten stopper kontrollert | Forhindrer datatap og begrenser påvirkning på brukere |
| Databasefeil | Systemet går i en skrivebeskyttet tilstand | Sikrer at data ikke blir ødelagt eller korrupt mens feilen håndteres |
| Sikkerhetsbrudd oppdages | Kontoer låses midlertidig eller tilgang begrenses | Reduserer risiko for videre skade og datalekkasjer |
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.
| Tiltak | Forklaring |
|---|---|
| Deaktivere ubrukte tjenester | Fjern eller slå av tjenester som er unødvendige eller ikke i bruk. |
| Begrense administrative rettigheter | Gi 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 ressurser | Ha et klar skille mellom kritiske systemer og mindre sensitive miljøer for å begrense spredning ved et angrep. |
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.
| Kategori | Innhold | Beskrivelse |
|---|---|---|
| Dataklassifisering | Type data | Kartlegge hvilke data som behandles i systemet |
| Klassifisering | Offentlig, intern, konfidensiell eller hemmelig | |
| Datalagring | Vurdere fysisk og digital plassering av data | |
| Databeskyttelse | Metoder for kryptering, tilgangskontroll og sikkerhet | |
| Arkitektur | Nettverksdiagram | Visualisering av nettverkets struktur og forbindelser |
| Dataflytdiagram | Oversikt over hvordan data beveger seg mellom systemer | |
| Autentisering og autorisering | Metoder for å kontrollere hvem som får tilgang til systemet | |
| Kryptering | Beskyttelse av data både i lagring og under overføring | |
| Compliance | GDPR | Sikre at løsningen oppfyller kravene i personvernforordninger |
| Personopplysninger | Identifisere og håndtere sensitive personopplysninger | |
| Avtaler for databehandling | Sikre at eksterne avtaler følger regulatoriske krav | |
| Trusselmodellering | Identifisere trusler | Kartlegge potensielle trusler mot systemet |
| Risikovurdering | Vurdere sannsynlighet og konsekvens av identifiserte trusler | |
| Mitigering | Tiltak for å redusere risiko og minimere konsekvenser | |
| Testing | Testing av sikkerhet | Generell vurdering av systemets sikkerhet |
| Penetrasjonstesting | Simulere angrep for å identifisere sårbarheter | |
| Skanning etter sårbarheter | Automatisert eller manuell gjennomgang for å oppdage svakheter |
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.
| Kategori | Logg |
|---|---|
| Autentisering | Vellykkede innlogginger |
| Mislykkede innlogginger | |
| Multifaktorautentisering | |
| Innlogging fra nye lokasjoner og enheter | |
| Autorisasjon | Tilgang til ressurser |
| Endringer i rettigheter | |
| Administrative handlinger | Opprettelse og sletting av ressurser |
| Endringer i konfigurasjon | |
| Brukeradministrasjon | |
| Data | Handlinger (Lese og skrive) mot sensitiv data |
| Eksportering av data |
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.
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
Kontakt
Har du spørsmål eller tilbakemeldinger? Ta kontakt med oss!
E-post: markedsplassen [at] dfo.no (markedsplassen[at]dfo[dot]no)