Kort perspektiv

Kort tid for endring

Perspektiver for skytjenester og portabilitet når man har dårlig tid

I dette scenarioet er situasjonen at virksomheten så raskt som mulig må flytte fra skytjenesten. Forholdene tilsier at virksomheten må over på ny tjeneste i løpet av 0-6 måneder. Dette omfatter både tilfeller der virksomheten selv bestemmer at behovet for flytting er akutt, og der tjenesten av andre årsaker midlertidig eller permanent bortfaller. Scenarioet innebærer at det er svært begrenset eller ingen tid til forberedelser.

Strategisk tilnærming

I dette scenarioet må virksomhetens strategiske tilnærming ta utgangspunkt i at bortfall av skytjenester kan være både en teknisk hendelse eller krise av lokalt omfang, men også en bred operativ og samfunnsmessig krise. Dersom tilgangen til skytjenester faller bort som følge av geopolitisk ustabilitet, sanksjoner, leverandørsvikt eller sikkerhetspolitiske kriser, vil virksomheten kunne stå overfor en situasjon der normale forutsetninger for drift, leverandørstøtte og markedskapasitet ikke lenger gjelder.

Målet må være å sikre virksomhetens overlevelsesevne. Det innebærer ikke å opprettholde full funksjonalitet eller normal tjenestekvalitet, men å sikre at de mest kritiske delene av samfunnsoppdraget kan videreføres. Strategien bør bygge på en erkjennelse av at tid, kompetanse, infrastruktur og leverandørkapasitet vil være knapphetsressurser i en krisesituasjon.

Virksomheten må også legge til grunn at den ikke nødvendigvis vil være alene om å stå i et slikt scenario. Dersom flere offentlige og private virksomheter samtidig får behov for nød-migrasjon, alternativ drift eller bistand fra de samme underleverandørene, vil kapasiteten i markedet raskt bli utilstrekkelig. Dette gjelder både datasenterkapasitet, maskinvare, nettverk, sikkerhetsressurser, migrasjonskompetanse og juridisk/kontraktsmessig støtte. Kapasitet hos underleverandører og partnere må derfor inngå som en sentral del av den strategiske vurderingen.

Følgende prinsipper bør ligge til grunn for virksomhetens strategiske arbeid i dette scenarioet:

Kritikalitetsstyring: Prioritering under press

Når tiden er knapp og ressursene er begrensede, kan ikke alle systemer, data og tjenester prioriteres likt. Virksomheten bør derfor legge en verdikjedebasert tilnærming til grunn, der det tydelig identifiseres hvilke funksjoner som er nødvendige for å videreføre samfunnsoppdraget på et minimumsnivå.

Kritikalitetsstyring handler om å skille mellom det som er virksomhetskritisk, det som er viktig, og det som midlertidig kan stanses. Dette må være avklart før krisen oppstår, slik at virksomheten ikke må gjøre grunnleggende prioriteringer under tidspress og usikkerhet.

Identifisering

Virksomheten bør kartlegge hvilke systemer, data og prosesser som understøtter samfunnskritiske og lovpålagte funksjoner. Dette omfatter både primære fagsystemer, nødvendige registre, autentiseringsløsninger, integrasjoner og informasjonsgrunnlag som er avgjørende for å opprettholde liv, helse, sikkerhet, rettigheter eller andre kjerneoppgaver. Kartleggingen bør gi et tydelig bilde av hvilke deler av systemporteføljen som må prioriteres ved alvorlig bortfall av skytjenester.

Differensiering

Ressurser bør styres mot de funksjonene som er nødvendige for å sikre liv, helse, kritiske rettigheter og virksomhetens mest sentrale leveranser. Støttefunksjoner, analysekapasitet, avanserte digitale tjenester og sekundære prosesser må kunne aksepteres nedstengt, redusert eller satt i ventemodus. En slik differensiering gjør det mulig å bruke begrenset kapasitet der den gir størst samfunnsmessig effekt.

Minimumsleveranse framfor full funksjonalitet

I en krisesituasjon er full funksjonalitet ikke et realistisk mål. Strategien bør derfor skifte fokus fra normal drift og sømløs brukeropplevelse, til minimumsleveranse og kontinuitet i kjerneoppgaver. Det avgjørende er at virksomheten kan opprettholde et forsvarlig tjenestenivå innenfor de mest kritiske områdene, selv om store deler av den ordinære digitale støtten faller bort.

Dette krever at virksomheten på forhånd har definert hva som er et akseptabelt minimumsnivå for drift. Minimumsleveranse må være konkret nok til å kunne styre tekniske, organisatoriske og ledelsesmessige prioriteringer i en krise.

Minimum Viable Operations

Virksomheten bør definere det absolutte minimumsnivået for drift, datatilgang, saksbehandling, kommunikasjon og beslutningsstøtte. Dette kan innebære at enkelte tjenester kjøres i sterkt forenklet form, at data oppdateres sjeldnere, eller at manuelle prosesser erstatter automatiserte arbeidsflyter. Minimumsnivået bør knyttes til konkrete funksjoner og verdikjeder, ikke bare til enkeltstående systemer.

Aksept for tap

Ledelsen bør på forhånd ha avklart hvilke funksjoner, tjenester og kvalitetskrav som kan tapes midlertidig uten at virksomhetens samfunnsoppdrag bryter sammen. Dette innebærer en eksplisitt aksept for at avansert funksjonalitet, automatisering, analyse, rapportering og brukerkomfort kan falle bort, til fordel for enklere, mer robuste og eventuelt manuelle løsninger. En slik aksept må være forankret før krisen oppstår, slik at organisasjonen kan handle raskt og samlet.

Avhengighetsforståelse: Kartlegging av økosystemet

En offentlig skytjeneste er sjelden en isolert teknisk løsning. Den inngår som regel i et komplekst økosystem av underleverandører, tredjepartstjenester, integrasjoner, sikkerhetsmekanismer, autentiseringsløsninger, dataplattformer og driftsprosesser. I en krisesituasjon kan svikt i ett ledd få konsekvenser for hele tjenestekjeden.

Virksomheten bør derfor ha en dypere forståelse av hele leveranseøkosystemet, ikke bare hovedleverandøren. Dette er særlig viktig dersom mange virksomheter samtidig er avhengige av de samme underleverandørene eller teknologikomponentene. Manglende oversikt kan føre til at virksomheten overvurderer egen beredskap eller planlegger for alternativer som i praksis ikke er tilgjengelige.

Dyp innsikt

Virksomheten bør kartlegge kritiske tredjepartskomponenter som SaaS-tillegg, API-er, identitets- og tilgangsstyring, sikkerhetsverktøy, nettverkskomponenter, driftsleverandører og integrasjonstjenester. Kartleggingen bør vise hvilke komponenter som er nødvendige for minimumsdrift, hvilke som har alternative leverandører, og hvilke som representerer enkeltpunkter for svikt. Slik innsikt gir bedre grunnlag for realistisk beredskapsplanlegging.

Relasjonell beredskap

Virksomheten bør identifisere hvilke partnere, underleverandører og myndighetsaktører som er nødvendige for å gjennomføre nød-migrasjon, alternativ drift eller gjenoppretting. Det bør etableres kontaktveier, eskaleringsrutiner og avtaleverk som tar høyde for krisescenarioer. Relasjonell beredskap handler ikke bare om å vite hvem som skal kontaktes, men om å sikre at samarbeid kan fungere når markedet er presset og flere aktører konkurrerer om de samme ressursene.

Kapasitetsrealisme: Planlegging for knapphet

Virksomheten bør planlegge ut fra en realistisk forståelse av at kapasitet vil være knapp i en alvorlig krisesituasjon. Dersom mange virksomheter samtidig må flytte tjenester, etablere alternativ drift eller sikre tilgang til lokal infrastruktur, vil markedet raskt kunne bli overbelastet. Det kan derfor ikke legges til grunn at nødvendige ressurser vil være tilgjengelige når behovet oppstår.

Kapasitetsrealisme innebærer at virksomheten må vurdere hvilke ressurser som må sikres på forhånd, hvilke som kan deles med andre, og hvilke som ikke realistisk kan skaffes i en krise. Dette gjelder både teknisk infrastruktur, personell, leverandørstøtte, lokaler, nettverk, sikkerhetskapasitet og beslutningsstøtte.

Infrastruktur

Virksomheten bør ikke legge til grunn at det finnes ledig maskinvare, datasenterplass, nettverkskapasitet eller lagringsressurser i det åpne markedet ved en nasjonal eller sektorovergripende krise. Dersom alternativ drift krever konkret fysisk eller logisk kapasitet, må dette vurderes og eventuelt sikres på forhånd gjennom avtaler, reserverte miljøer, rammeavtaler eller sektorvise beredskapsløsninger. Uten slik forhåndsavklaring kan en nødplan vise seg å være urealistisk.

Kompetanse

Ekspertisen som kreves for å flytte komplekse arbeidslaster, gjenopprette tjenester, rekonfigurere sikkerhetsmodeller og etablere alternativ drift, vil være en begrenset ressurs. Virksomheten bør derfor sikre et minimum av intern kompetanse på kritiske systemer, dataflyter og gjenopprettingsprosesser. I tillegg bør det vurderes beredskapsavtaler med utvalgte partnere som gir tydelig prioritet, responstid og tilgang til relevant kompetanse i en krisesituasjon. Dette reduserer risikoen for at virksomheten blir stående i kø når behovet for bistand er størst.

Tekniske valg

Scenarioet ‘Kort tid for endring’ gir lite rom for tilrettelegging av tekniske løsninger og standarder for å understøtte skytjenesteportabilitet. Dette er et scenario der man trenger rask flytting av skytjeneste, uten nødvendigvis å ha tilrettelagt for portabilitet på forhånd. All forutgående tilrettelegging, som beskrevet i scenarioene for lang og mellomlang tid, vil imidlertid være til stor hjelp.

Tiltakene i dette kapittelet er primært ment som et teknisk førstehjelpsskrin i en akutt situasjon. Hvis man må flytte systemer på under seks måneder, er det sjelden tid til å skrive om store mengder kode eller gjøre store nyinnkjøp – man må løse problemet med de verktøyene man har.

Beskrivelser av tekniske valg i dette kapittelet kan derfor benyttes i to perspektiver:

• I en normalsituasjon fungerer punktene godt som et utgangspunkt for øvelse eller testing av portabilitet. Målet er ikke nødvendigvis at man skal ha alt ferdig oppsatt i dag, men at man har tenkt gjennom problemstillingene. Selv en ren «papirøvelse» rundt et møtebord gir et enormt forsprang den dagen noe skjer. De punktene som lar seg teste uten å forstyrre produksjonsmiljøet, bør testes.
• Står man midt i en oppstått krise når dette leses, fungerer punktene mer som en sjekkliste for hva fagmiljøene bør prioritere å redde eller etablere aller først.

Teknisk tilrettelegging for effektiv portering

Infrastructure-as-a-Service (IaaS)

Overordnet anbefaling for IaaS-området er å finne raskeste mulighet for reetablering av tilsvarende skytjeneste eller andre løsninger på minimumsnivå.

Følgende tilnærminger kan understøtte dette:

• Identifiser kritiske data: Prioritere umiddelbar uthenting av databaser og filområder.
• Etabler "Landing Zone": Opprette et minimalt driftsmiljø hos en alternativ leverandør i Norge eller Europa eller omdisponere eventuelle onprem ressurser.
• Gjenopprett fra backup: Benytte de siste sikkerhetskopiene lagret uavhengig av primærleverandøren.
• DNS-ompeking: Klargjøre endring av DNS-oppføringer med lav TTL (Time to Live) for rask ompeking til det nye miljøet.
• Bulk-eksport av secrets: Hente ut alle passord, API-nøkler og tilkoblingsstrenger fra leverandørens "Secret Manager", til en sikker offline-lokasjon. Dette må løses med skript, da de fleste skyleverandører - av sikkerhetsmessige årsaker - ikke tilbyr dette "ut-av-boksen".
• Manuelt sertifikatskifte: Dersom leverandøren kontrollerer virksomhetens SSL-/TLS-sertifikater, må man umiddelbart utstede nye sertifikater via en uavhengig part, for å kunne gjenopprette kryptert trafikk i mottaksmiljøet.
• Nødomruting via BGP: Ved bruk av Bring Your Own IP (BYOIP), utføre teknisk ompeking av trafikk på ruting-nivå, for å flytte innkommende trafikk til det nye miljøet umiddelbart.
• Snapshotkonvertering: Bruk verktøy for å konvertere disksnapshot fra proprietære formater til åpne formater (som RAW eller QCOW2), for umiddelbar import i det nye miljøet. Få skyleverandører tilbyr nedlasting av snapshots som enkelt kan konverteres, ta derfor først backup til uavhengig leverandør eller koble disker til en virtuell maskin i skymiljøet for å klone disse.

Platform as a Service (PaaS)

Overordnet anbefaling for PaaS-området er å finne raskeste mulighet for reetablering av tilsvarende skytjeneste eller andre løsninger på minimumsnivå.

Følgende tilnærminger kan understøtte dette:

• Containerflytting/-gjenoppretting: Distribuere eksisterende container-images til alternative kjøremiljøer som støtter standardiserte orkestreringsverktøy.
• Sikre krypteringsnøkler: Hente ut nøkler og sertifikater umiddelbart fra leverandørens hvelv, slik at data kan dekrypteres i det nye miljøet.
• Råeksport: Utføre en "database dump", fremfor å prøve komplisert synkronisering under tidspress (ved svært lite tid til rådighet, for å sikre dataene mot tap/sletting).
• Ompeking av API-endepunkt: Oppdatere konfigurasjonsfiler eller miljøvariabler for å peke mot de nye IP-adressene eller vertsnavnene i mottaksmiljøet.
• Nødproxy: Ved behov, sette opp en midlertidig proxy-tjeneste for å rute trafikk mellom den gamle og den nye lokasjonen, mens migreringen pågår.
• Injeksjon av miljøvariabler: Bruke skript for å injisere nye tilkoblingsstrenger og miljøkonfigurasjoner i orkestreringen, slik at tjenester finner nye databaseendepunkter etter oppstart.
• Automatisert gjenoppretting av tilgangsstyring (RBAC): Benytt skript for å gjenskape rollestyrte tilgangskontroller i det nye mottaksmiljøet, og løsninger basert på åpne standarder for identitetssynkronisering (eks. SCIM eller OIDC) for identiteter. Dette for å kunne gjenskape identiteter og tilganger under tidspress, samt unngå manuelle feiloppsett.

Software-as-a-Service (SaaS)

Overordnet anbefaling for SaaS-området er å finne best mulig reetablering av tilsvarende skytjeneste. Anbefalingene omfatter ikke kontorstøtterelatert SaaS.

Følgende tilnærminger kan understøtte dette:

• API-uthenting: Bruke tilgjengelige API-grensesnitt for å dumpe ut rådata i formater som JSON eller CSV.
• Manuelle reserveløsninger: Klargjøre enkle verktøy (f.eks. regneark eller lokale databaser) for å kunne lese de eksporterte dataene og opprettholde kritisk drift og saksbehandling.
• Identiteter: Aktivere/ta i bruk alternative autentiseringskilder hvis den primære påloggingsløsningen blir utilgjengelig.
• Integritetssjekk: Utføre (automatisert) sammenligning av sjekksummer (“hashes”) på de viktigste datasettene før og etter flytting, for å sikre at ingen data ble korrupte under transporten.
• Minimumstest: Verifisere kritiske verdikjeder - f.eks. pålogging og lagring av nye data - før systemet åpnes for brukere.
• Datavask: Ha ferdige skript (f.eks. Python eller ETL-verktøy) klare for å transformere dataeksport til formatet som kreves av en ny løsning.
• Nødprioritering av metadata: Ved flytting av data mellom SaaS-løsninger under tidspress, må tekniske prosedyrer prioritere eksport av metadata (relasjoner, historikk og tilgangsrettigheter), da disse kan være like kritiske for tjenestegjenoppretting som rådata alene. Relasjonsdata må eksporteres i et flatt, menneske- og maskinlesbart format (eks. CSV- eller JSON-fil). Dette sikrer at dataene forblir sporbare også i enkle reserveløsninger.