Skyreisen

Anskaffe skytjenester

Eksempler på krav til sikkerhet ved kjøp av skytjenester

Finn eksempler på krav til leverandøren og til skytjenesten, samt kilder til sikkerhetstiltak.

Eksemplene er utarbeidet med utgangspunkt i kjente standarder som ISO-rammeverket og Cloud Control Matrix fra Cloud Security Alliance.

Krav til leverandør

Et eksempel på kvalifikasjonskrav som kan stilles til leverandør er krav om styringssystem for informasjonssikkerhet, jf. FOA § 16-7.

Det er ulike rammeverk og standarder for styringssystem for informasjonssikkerhet. En av de vanligste er ISO/IEC 27001, hvor en leverandør som etterlever kravene kan bli sertifisert og få utstedt sertifikat.

ISO/IEC 27001-sertifisering

Det er leverandørens virksomhet som blir sertifisert, og ikke tjenestene eller produktene som leveres. ISO/IEC 27001-sertifisering gir ingen garanti for at tjenestene som leveres er sikre.

Sjekk omfanget/scope for sertifikatet til leverandøren. Dersom den aktuelle tjenesten ikke er dekket av sertifikatet, så sier ikke sertifikatet noe om styringen av sikkerheten knyttet til selve tjenesten.

ISO/IEC 27001 har et tillegg med en referansekatalog med sikkerhetstiltak, Annex A, som benyttes som en sjekkliste. Brukere av standarden kan sammenligne sine valgte sikkerhetstiltak mot listen for å undersøke om noe vesentlig er utelatt. Innholdet i Annex A er hentet fra ISO/IEC 27002 (ledende praksis for implementering av sikkerhetstiltak).

Krav - forslag til tekst i kravspesifikasjon

Leverandørens kvalitetssikringsstandard jf. FOA § 16-7.

Leverandøren skal ha styringssystem for informasjonssikkerhet som tilfredsstiller kravene i ISO/IEC 27001 eller tilsvarende. 

Forslag til dokumentasjonskrav

Gyldig ISO/IEC 27001-sertifikat eller tilsvarende, eller attest utstedt av uavhengig organ som dokumentasjon for at leverandøren oppfyller kravene etter ISO/IEC 27001 eller tilsvarende.

12 standardkrav til sikkerhet i skytjenester

Nedenfor finner du 12 forslag til krav i en kravspesifikasjon (K1-K12). De fleste eksemplene presenteres som BØR-krav/evalueringskrav, men du kan også velge å angi dette som SKAL-krav/minimumskrav.

Formålet med kravene er å håndtere risiko R1 til R12 i risikobanken.

Risiko_og_kravbank_1.0
xlsx 31.34 KB

Last ned regneark med alle kravene over. Regnarket inneholder også risikoene som kravene er rettet mot.

K1 Leverandørens risikostyring

Dette kravet er utarbeidet for å redusere risiko R1 i risikobanken.

Tiltak - hvordan redusere risiko

Leverandøren må holde seg oppdatert på risikobildet, analyserer løpende potensielle trusler og sårbarheter, og ha rutiner for å sikre at det blir gjennomført relevante tiltak.

Krav - forslag til tekst i kravspesifikasjon

Leverandøren skal ha en løpende prosess for å identifisere, vurdere og håndtere sårbarheter i tjenesten.

Dokumentasjonskrav - forslag til tekst

Beskriv prosessen for trussel- og sårbarhetsvurderinger. Beskriv også hvordan sårbarheter håndteres og hvilke prosedyrer med tidsrammer som brukes for de ulike typer av sårbarheter.

K2 Lock-in

Dette kravet er laget for å redusere risiko R2 i risikobanken.

Tiltak - hvordan redusere risiko for Lock-In

  • Planlegg tidlig for exit: Allerede når du planlegger for implementering bør du legge en plan for exit og forstå kostnadene ved å bytte skyleverandør. Ikke planlegg for lengre enn et par år for å ivareta fleksibiliteten din, dog nedsiden ved det er at dette kan hindre en virksomhet i å rabattordninger som knyttes til lengre engasjement.
  • Design dine applikasjoner frikoblet fra skyplattform: Skyapplikasjonskomponenter bør være så løst knyttet som mulig til skyplattformens applikasjonskomponenter som samhandler med dem. Dette øker fleksibiliteten.
  • Sørg for høy portabilitet av dine data: Unngå proprietær formatering for å maksimere portabiliteten til dine data. Beskriv datamodeller så tydelig som mulig ved å bruke skjemastandarder for å lage detaljert lesbar dokumentasjon. I tillegg bør du sørge for at skyleverandøren din tilbyr deg en måte å trekke ut data enkelt og rimelig.
  • Vurder multi-sky strategi: Du kan for eksempel bruke en leverandør til prosessering og en annen for datavarehuset, mens du bruker en tredje til din kunstige intelligens. Ved å gå multi-sky blir du mindre avhengig av én leverandør for alle dine behov. En annen fordel er at du kan plukke det beste fra hver skyleverandør ("best-of-breed-tjenester") slik at du får de applikasjonene og funksjonene som best passer din virksomhet. En potensiell bakside er økt kompleksitet og større behov for leverandørkontroll.
  • Implementer DevOps verktøy og prosesser: Containerteknologi levert av ulike tilbydere bidrar til fjerne avhengigheter til skyleverandørene. De fleste skytjenesteleverandører støtter standard containerformat, som gjør det være enkelt å overføre applikasjonene dine til en ny skyleverandør om nødvendig.

Krav - forslag til tekst i kravspesifikasjon

Leverandøren skal yte bistand til Kunden dersom Kunden ønsker å avslutte avtalen. Leverandøren skal legge til rette for at Kundens data blir overført til Kunden eller til tredjepart utpekt av Kunden.

Kunden skal beholde eierskapet til Kundens data etter at kontrakten er avsluttet og til data er flyttet og/eller slettet fra tjenesten.

Dokumentasjonskrav - forslag til tekst

Beskriv hvilken bistand som ytes i forbindelse med avslutning av avtalen og hvilke aktiviteter med ansvarsmatrise for de ulike aktivitetene dersom Kunden ønsker å flytte Tjenestene. Beskriv hvilke forutsetninger som legges til grunn for slik bistand og hvilke begrensninger som gjelder. Bistanden skal prises i Prisbilaget.

K3 Beskyttelse av data under overføring

Dette kravet er laget for å redusere risiko R3 i risikobanken.

Tiltak - hvordan redusere risiko for tap eller endring av data under overføring eller avlytting

Beskytte nettverk for å hindre uvedkommende tilgang til data og kryptering for å hindre uvedkommende å lese data.

Krav - forslag til tekst i kravspesifikasjon

Data som overføres via nettverk må sikres. Dette gjelder både data som overføres til og fra tjenesten, internt i tjenesten og data som utveksles med andre tjenester.

Dokumentasjonskrav - forslag til tekst

Beskriv hvordan data under overføring beskyttes, herunder beskyttelse av nettverk og bruk av kryptering.

K4 Beskyttelse av datasenter

Dette kravet er utarbeidet for å redusere risiko R4 i risikobanken.

Tiltak - hvordan redusere risiko for uautorisert adgang til datasenter

Datasenter som benyttes i tjenesten må kunne dokumentere fysisk sikring.

Krav - forslag til tekst i kravspesifikasjon

Leverandør skal forhindre uautorisert tilgang til sine datasenter samt beskytte mot tyveri, skade, tap og at utstyr svikter for å sikre kontinuerlig drift.

Dokumentasjonskrav - forslag til tekst

Beskriv hvilke fysiske sikringstiltak som benyttes i de datasenter som brukes for å levere tjenesten slik at uvedkommende ikke får tilgang til data, systemer og utstyr.

K5 Beskytte lagret informasjon

Dette kravet er utarbeidet for å redusere risiko R5 i risikobanken.

Tiltak - hvordan redusere risiko for uautorisert tilgang til dine data

En kombinasjon av fysisk sikring (se risiko R4) og kryptering av lagrede data.

Du bør kreve at lagrede data skal være kryptert og sikre at håndtering av krypteringsnøkler følger beste praksis, f. eks. å skille nøkkeladministrasjon og bruk av nøkler. Du burde også gjøre en vurdering på om krypterte nøkler burde lagres i sky eller ikke.

Krav - forslag til tekst i kravspesifikasjon

Leverandøren skal definere, velge, dimensjonere og implementere passende kryptografiske mekanismer støttet av en tilstrekkelig nøkkeladministrasjonsinfrastruktur for å sikre sikker drift av tjenestene. Det gjelder data i ro så vel som data i bevegelse (data in transit).

Dokumentasjonskrav - forslag til tekst

Beskriv hvordan plattform og lagrede data sikres ved bruk av kryptering. Beskriv hvordan krypteringsnøkler håndteres. Hvordan sikrer man skille mellom administrasjon av krypteringsnøkler og bruk av krypteringsnøkler.

K6 Separasjon mellom kunder

Dette kravet er utarbeidet for å redusere risiko R6 i risikobanken.

Tiltak - hvordan redusere risiko for at andre kunder skal kunne påvirke tjenesten

Leverandøren skal sørge for tilstrekkelig skille mellom kundene sine. Dette kan gjøres ved bruk av anerkjente virtualiseringsteknikker for både prosessering, nettverk og lagring. Man kan også separere kunder ved bruk av operativsystem, webtjenere eller applikasjoner.

Krav - forslag til tekst i kravspesifikasjon

Leverandøren må skille kundens tjenester og data fra andre kunder.

Dokumentasjonskrav - forslag til tekst

Beskriv hvordan kundenes tjenester og data skilles fra hverandre og hvordan denne separasjonen kan kontrolleres og styres av Kunden.

K7 Sletting av data

Dette kravet er utarbeidet for å redusere risiko R7 i risikobanken.

Tiltak - hvordan redusere risiko for usikker og ukomplett sletting av data

Leverandøren skal kunne dokumentere hvordan leverandøren sletter data og hvordan leverandøren sikrer at slettede data ikke kommer på avveie eller kan gjenskapes. Den mest pålitelige måten å fullstendig slette data på er å ødelegge lagringsmediet. Det er det vanskelig å få gjennomført siden det ofte er andre kunder som også bruker samme ressurser til sine data.

Krav - forslag til tekst i kravspesifikasjon

Leverandøren må kunne dokumentere hvordan han sletter data og hvordan han sikrer at slettede data ikke kommer på avveie eller kan gjenskapes.

Dokumentasjonskrav - forslag til tekst

Beskriv hvilke tiltak og prosedyrer som er etablert for sletting av data og for å sikre at data som er slettet ikke blir tilgjengelig for andre eller kan gjenskapes. Beskriv også hvordan du sikrer at slettede data ikke blir tilgjengelig ved utskifting og fornyelse av infrastruktur.

K8 Tilgjengelighet

Dette kravet er utarbeidet for å redusere risiko R8 i risikobanken.

Tiltak - Hvordan redusere risiko for utilgjengelighet og nedetid

Leverandøren skal forplikte seg til tilgjengelighet i tjenesten og garantere oppetid. Leverandøren bør også kunne vise til statistikk og historiske data for oppetid/tilgjengelighet.

Du kan også vurdere å be om informasjon om hvordan leverandøren har designet tjenesten for å kunne være robust og sikre oppetid/tilgjengelighet.

Krav - forslag til tekst i kravspesifikasjon

Tjenesten skal være tilgjengelig for kunden når kunden har behov for tjenesten. Leverandøren skal kunne garantere oppetid og dokumentere historisk oppetid/tilgjengelighet.

Dokumentasjonskrav - forslag til tekst

Beskriv den garanterte tilgjengelighet og dokumenter oppetidsgarantien med historiske data. Dersom det brukes ulike tilgjengelighetsgarantier, så skal disse beskrives og hvilke betingelser som gjelder for de ulike garantiene.

Beskriv hvilke tiltak og prosedyrer som er etablert for å sikre tjenestens robusthet og tilgjengelighet.

K9 Endringshåndtering

Dette kravet er utarbeidet for å redusere risiko R9 i risikobanken.

Tiltak - hvordan redusere risiko for hendelser ved endringer

Leverandøren må ha prosess for å håndtere endringer. Prosessen skal sikre at endringer som kan påvirke sikkerheten identifiseres og håndteres, og at uautoriserte endringer kan oppdages.

Krav - forslag til tekst i kravspesifikasjon

Leverandøren skal ha prosess for å håndtere endringer for å sikre at endringer som kan påvirke sikkerheten identifiseres og håndteres, og at uautoriserte endringer kan oppdages

Dokumentasjonskrav - forslag til tekst

Beskriv prosessen for endringshåndtering for både utvikling, integrasjoner, applikasjoner, nettverk og systemkomponenter. Beskriv også hvordan endringshåndtering ivaretas i hele verdikjeden for tjenesten. Beskriv i tillegg hvordan leverandøren sikrer at det kun er autoriserte endringer som blir implementert i tjenesten.

K10 Sporbarhet

Dette kravet er utarbeidet for å redusere risiko R10 i risikobanken.

Tiltak - hvordan redusere risiko for mangelfull sporbarhet

Alle handlinger som utføres av leverandøren skal logges. Loggen skal ikke kunne manipuleres. Kunden skal få tilgang til loggene på forespørsel.

Alle handlinger skal loggføres og kunne kobles til den personen som har utført handlingen. Systemdesign skal sikre at det ikke er mulig å omgå logging f.eks. ved å logge inn på systemer på lavere nivå eller foreta spørringer direkte mot en database i stedet for å benytte applikasjonsgrensesnitt.

Kunden har rett til å revidere leverandørens virksomhet knyttet til behandling av kundens data, eller å få innsyn i revisjonsrapporter fra en uavhengig tredjepart med revisjonsrett.

Krav - forslag til tekst i kravspesifikasjon

Alle handlinger som utføres av leverandøren skal logges. Loggen skal ikke kunne manipuleres. Kunden skal få tilgang til loggene på forespørsel.

Dokumentasjonskrav - forslag til tekst

Beskriv hvordan og på hvilket detaljnivå handlinger utført av leverandøren som kan endre eller eksponere data logges, og hvordan loggene sikres mot manipulasjon.

Beskriv hvordan kunden får tilgang til disse loggene. Beskriv kundens rett til revisjon av leverandørens virksomhet knyttet til behandling av kundens data.

K11 Tilgangskontroll/autentisering

Dette kravet er utarbeidet for å redusere risiko R11 i risikobanken.

Tiltak - Hvordan redusere risiko for at tilgangskontroll/autentisering feiler

Leverandøren skal sørge for tilstrekkelig isolasjonsstyrke og robusthet i tilgangskontrollen for å gi rett person tilgang til rett datasett og rette funksjoner i løsningen, og kunne dokumentere at dette er implementert.

Leverandøren skal tilby verktøy for administrasjon av kundens brukere og deres tilganger, ha tilstrekkelig støtte for bruk av eksterne identitetstilbydere og støtte for eksterne identitethåndteringsløsninger – IdM (støtte for standardprotokoller og APIer for kundens deling av brukertilganger og -roller med leverandørens løsning).

Krav - forslag til tekst i kravspesifikasjon

Løsningen skal ha tilstrekkelig isolasjonsstyrke og robusthet i tilgangskontroll.

Leverandør skal tilby verktøy for administrasjon av kundens brukere og deres tilganger og ha tilstrekkelig støtte for bruk av eksterne identitetstilbydere.

Dokumentasjonskrav - forslag til tekst

Beskriv hvordan løsningen kan sikre at kunden kan autentisere, autorisere og administrere tilganger for personer, prosesser eller applikasjoner, og hvordan slik tilgang kan etterprøves (audit).

Dette inkluderer muligheter for Single Sign-on (SSO), multifaktor autentisering (MFA), føderasjon med eksterne identitetstilbydere, integrasjon med identitetshåndteringsløsninger (IdM) og aksessloggmuligheter.

K12 Sikkerhetsovervåking

Dette kravet er utarbeidet for å redusere risiko R12 i risikobanken.

Tiltak - hvordan redusere risiko for at sikkerhetsbrudd oppstår og hvordan sikre gode varslingsrutiner

Leverandør har mange tiltak for å både oppdage og forhindre innbrudd.  En virksomhet kan be om å få tilgang til leverandørens revisjonsrapporter fra en tredjepart for deres vurdering av leverandørens sikkerhetsovervåkning, vurdering av tilgangsstyringen til systemer og komponenter for leverandørens egne administratorer og hvilke prosedyrer og rutiner de har for varsling til kunder.

Spør leverandøren om å få tilgang til sikkerhetslogger og integrer disse med egen løsning for sikkerhetsovervåkning.

Varslingsrutiner og tidsfrister skal også beskrives i databehandleravtalen man har med leverandøren

Som kunde, etabler en mottakende organisasjon for varsler om sikkerhetsbrudd og behandling av disse for å vurdere tiltak som må iverksettes for å varsle videre og begrense skadeomfanget.

Krav - forslag til tekst i kravspesifikasjon

Leverandøren skal ha tilstrekkelig sikkerhetsovervåkning av tjenesten og rutiner for varsling ved hendelser.

Leverandør skal på forespørsel gi kunden tilgang til revisjonsrapporter for vurdering av sikkerhetsovervåkningen, vurdering av tilgangsstyringen til systemer og komponenter for leverandørens egne administratorer og hvilke prosedyrer og rutiner de har for varsling.

Sikkerhetslogger skal gjøres tilgjengelig for kunden på forespørsel.

Dokumentasjonskrav - forslag til tekst

Beskriv prosesser, rutiner og funksjonalitet som utgjør sikkerhetsovervåkingen av løsningen, og beskrive hvilke type loggdata som kan tilgjengeliggjøres for kunden (definerte og valgfrie sikkerhetsalarmer, sikkerhetsadvarsler og sikkerhetsloggingstjenester).

Leverandøren skal beskrive hvordan sikkerhetslogger, alarmer og advarsler kan integreres med Kundens egen sikkerhetsovervåking.

Leverandøren bes beskrive hvordan de bruker ekstern penetrasjons- og sikkerhetstesting eller andre mekanismer for testing og kontroll av plattform-, applikasjons- og infrastruktursikkerhet.

Kilder til sikkerhetstiltak

Her finner du eksempler på ulike kilder med forslag til sikkerhetstiltak. Vurder virksomhetens behov for sikkerhetstiltak. Det er sjelden nødvendig å bruke alle sikkerhetstiltakene i en kilde som krav. Vurder å hente forslag til tiltak fra flere kilder.

ISO/IEC 27002 eller tilsvarende
ISO/IEC 27017 eller tilsvarende
ISO/IEC 22313 eller tilsvarende

ISO 22313 er en veiledning som bygger på kravene i ISO 22301 om krav til styring og kontroll av kontinuitet i tjenesten, Business Continuity Management Systems (BCMS).

Veiledningen er basert på god internasjonal praksis for PLANLEGGING, ETABLERING, IMPLEMENTERING, DRIFT, OVERVÅKING, GJENNOMGANG, VEDLIKEHOLD og KONTINUERLIG FORBEDRING av et styringssystem som gjør det mulig være forberedt på hendelser som kan forstyrre tjenesten og å kunne være i stand til å respondere når hendelser oppstår for å sikre kontinuerlig drift.

NSMs Grunnprinsipper for IKT-sikkerhet

Grunnprinsippene beskriver hva en virksomhet bør gjøre for å sikre et IKT-system. De beskriver også hvorfor det bør gjøres, men ikke hvordan.

Grunnprinsippene er inndelt i fire kategorier:

  1. Identifisere og kartlegge
  2. Beskytte
  3. Opprettholde og oppdage
  4. Håndtere og gjenopprette

NSMs Grunnprinsipper for IKT-sikkerhet v2.0

Norm for informasjonssikkerhet i personvern i helse- og omsorgstjenesten

Normen er en bransjenorm som er utarbeidet og forvaltes av organisasjoner og virksomheter i helse- og omsorgssektoren. Normen tar sikte på å bidra til tilfredsstillende informasjonssikkerhet og personvern hos den enkelte virksomhet og i sektoren generelt. Den skal også bidra til at det etableres mekanismer hvor virksomhetene kan ha gjensidig tillit til at øvrige virksomheters behandling av helse- og personopplysninger gjennomføres på et forsvarlig sikkerhetsnivå.

Normen kapittel 5 - Informasjonssikkerhet

Den beskriver sentrale sikkerhetstiltak som skal gjennomføres av virksomheter som behandler helse- og personopplysninger. Dette omfatter både dataansvarlige og databehandlere.  Alle sikkerhetstiltak skal være egnede, og velges basert på risikovurderinger. Det kan dermed være nødvendig å gjennomføre mer omfattende tiltak enn det som er beskrevet her.

Norm for informasjonssikkerhet og personvern i helse og omsorgstjenesten (Normen)

NIST Cyber Security Framework v.1.1 (NIST CSF)

NIST Cyber Security Framework er et rammeverk for anskaffelser og leverandørstyring for internasjonale skyleverandører.

Oppdatert: 21. november 2023

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.