Ansvaret for driften følger tjenesteformen: ved infrastruktur som tjeneste styrer I selv styresystem, lager og programmer, og når udbyderen leverer færre administrerede tjenester, overtager I mere af det daglige arbejde. Flytter I fra en stor udbyder med mange administrerede tjenester til en platform med færre, kan opgaver, der før lå hos udbyderen, blive jeres.
Artiklen viser, hvordan en driftsansvarlig fordeler ansvaret lag for lag, før skiftet. Den bygger på den amerikanske standardiseringsinstitution NIST’s definition af tjenesteformerne og på faglig fremgangsmåde. Sikkerhedsansvaret i bred forstand, når driften er lagt ud, er et andet emne.
Tjenesteformerne og hvem der styrer hvad
NIST’s definition af cloud, SP 800-145 fra 2011, beskriver tre tjenesteformer. Forenklet gengivet:
- Infrastruktur som tjeneste (IaaS). Kunden styrer ikke den underliggende infrastruktur, men har kontrol over styresystemer, lager og de programmer, kunden installerer, og muligvis begrænset kontrol over udvalgte dele af netværket.
- Platform som tjeneste (PaaS). Kunden styrer de programmer, kunden selv har lagt på platformen, og muligvis opsætningen af miljøet. Netværk, servere, styresystemer og lager styres af udbyderen.
- Program som tjeneste (SaaS). Kunden styrer højst begrænsede brugerindstillinger.
Definitionen er amerikansk og ældre end mange af dagens tjenester. Skellet kan stadig bruges. Hvor meget en tjeneste tager af jeres arbejde, afhænger af, hvor højt oppe i lagene udbyderen overtager.
Hvorfor fordelingen flytter sig ved et skifte
Bruger I i dag en administreret database, en administreret Kubernetes-tjeneste, en tjeneste til nøgler og en til overvågning, ligger opdatering, backup og en del af overvågningen hos udbyderen. Tilbyder den nye platform ikke en tilsvarende tjeneste, skal I selv drive en afløser på virtuelle servere. Det flytter opgaven ned i IaaS-laget, hvor I har ansvaret.
Vi vurderer, at kataloget hos en mindre udbyder kan være smallere end hos de største, så kunden selv skal drive mere. Det er ingen generel regel. Katalogerne varierer også mellem europæiske udbydere. Sammenlign derfor tjeneste for tjeneste. Fremgangsmåden står i Hvad mangler hos de europæiske?
Fordel ansvaret lag for lag
Lav en tabel pr. system med lagene som rækker og tre kolonner: udbyderen, en eventuel partner og jer. Lagene kan være:
- Bygning, strøm og køling.
- Fysiske servere, lager og netværk.
- Virtualisering og kontrolpanel.
- Styresystem og opdateringer.
- Database, beskedkøer og andre fælles komponenter.
- Programmet selv.
- Identitet og adgang.
- Backup og gendannelse.
- Overvågning, logning og vagt.
- Kryptering og nøgler.
For hvert felt skrives, hvem der gør arbejdet, og hvem der har ansvaret, hvis det ikke bliver gjort. De to kan være forskellige. En partner kan udføre opdateringerne, mens ansvaret over for jeres ledelse stadig ligger hos jer.
Tabellen er sitets egen fremgangsmåde og ingen standard. Den er nyttig, fordi den gør tomme felter synlige. Et lag uden navn er et lag, ingen passer.
Felter, der er lette at overse
Fire felter er lette at overse, og det er værd at se på dem først. Backup af virtuelle servere, hvor det skal afklares, om udbyderens kopier af platformen også omfatter jeres data. Opdatering af styresystemer, når ingen har sat automatisk opdatering op. Overvågning uden for åbningstid. Og nøgler, som ingen ved, hvor ligger.
Hvordan sikkerhedsmodellen bygges op igen hos en ny udbyder, står i Sikkerhedsmodellen følger ikke med.
Brug tabellen i aftalen og i vagtplanen
Tabellen skal kunne genfindes i aftalen med udbyderen og partneren. Står der i tabellen, at partneren har vagt om natten, skal det stå i partnerens aftale med svartid. Står der, at udbyderen tager backup af platformen, skal I kunne se, hvad det omfatter. Hvad aftalen skal rumme, står i Hostingaftalen.
Tabellen er også grundlaget for jeres vagtplan og for beregningen af, hvor mange folk driften kræver efter skiftet. Se Driftsfolkene i regnestykket.
Hvad det kræver, og hvad det koster at lade være
Tabellen tager en arkitekt og en driftsansvarlig en halv dag pr. system at udfylde. Afstemningen med udbyderens og partnerens aftaler tager en dag mere. Arbejdet kan laves før skiftet og bruges i sammenligningen af udbydere.
Lader I være, opdager I tomme felter, når noget går galt. Et system uden opdateringer, en backup, ingen har prøvet at gendanne, eller en alarm om natten, ingen modtager. Hver af dem kan koste mere end hele arbejdet med tabellen, og de kan ramme allerede i de første måneder efter skiftet.
Det skal I lade være med
- At gå ud fra, at udbyderens backup dækker jeres data · læs, hvad den omfatter.
- At blande udførelse og ansvar sammen · en partner kan gøre arbejdet, mens ansvaret er jeres.
- At regne tjenesterne for ens hos to udbydere · sammenlign tjeneste for tjeneste.
Det skal valget kunne vise
- ☐ En tabel pr. system med lag, udførende og ansvarlig.
- ☐ Ingen tomme felter, eller en beslutning om hvert tomt felt.
- ☐ Tabellen afstemt med aftalerne med udbyder og partner.
- ☐ Vagtplan, der svarer til tabellen.
Kilder
- NIST SP 800-145, The NIST Definition of Cloud Computing, september 2011: tjenesteformerne.
Senest gennemgået: november 2026.
Næste skridt
Udfyld tabellen for det system, I overvejer at flytte først, og se, hvilke felter der flytter fra udbyderen til jer.
Læs også: Applikationer bygget på udbyderens egne tjenester · Med egne IT-folk
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
