Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Næsten hver gang en kortlægning går i gang, starter den samme sted: et regneark, ingen vedligeholder, og en liste over SaaS-aftaler, hvor ingen helt ved, hvem der godkendte dem.
Markedsafdelingen har sit eget analyseværktøj, salg har et CRM-tillæg, og et abonnement dukker op på et kreditkort, som chefen for den afdeling for længst har glemt.
Det er ikke en anklage. Organisk cloud-adoption over et årti er normen, og et helt rimeligt udgangspunkt.
Kortlægningen handler ikke om skyld, men om at kunne handle: for at vide, hvad der bør justeres, og hvad der allerede er under kontrol, må du først vide, hvad du har.
De fire lag du skal kortlægge
Suverænitetskortlægningen er enklest at forstå som fire lag.
Infrastruktur (IaaS). Virtuelle maskiner, netværk, lagring. Hvilke udbydere kører din beregningskapacitet? Hvilke geografiske regioner? Dedikerede servere eller delt infrastruktur?
Platform (PaaS). Databasetjenester, containerplatforme, udviklingsværktøjer. De er ofte usynlige i en systemoversigt, men kritiske. En europæisk virtuel maskine, der sender data til en amerikansk administreret database, er ikke suverænitet, uanset hvor infrastrukturen ligger.
Software (SaaS). CRM, HR-systemer, samarbejdsværktøjer, BI-platforme. Dette lag er typisk det største og det mindst kortlagte. Et konservativt skøn for en organisation med 200 ansatte er 30-60 aktive SaaS-tjenester, hvoraf it typisk kender halvdelen.
Identitet og adgang. Hvem kan logge ind på hvad, og via hvilken udbyder? En europæisk cloud-tjeneste, der autentificerer via Microsoft Entra ID, er et forhold, der skal kortlægges, fordi adgangsvejen er en jurisdiktion i sig selv.
Hvem ejer hvad, og under hvilken ret
For hvert system og hver tjeneste skal du besvare tre spørgsmål.
Hvilken juridisk enhed ejer og driver tjenesten?
Det er ikke det samme som det mærke, du betaler til. Mange SaaS-tjenester drives af datterselskaber eller underleverandører i andre lande, end fakturaen antyder.
Kig på databehandleraftalen, ikke fakturaen.
Hvilke underdatabehandlere trækker tjenesten på?
Databeskyttelseslovgivningen kræver, at du kender dine databehandlere, men databehandlerens databehandlere er sjældent fremtrædende i hoveddokumentationen.
Næsten alle større tjenester offentliggør en liste, typisk kaldet "subprocessor list", men den skal man lede efter. Listen kan indeholde overraskende navne.
Hvilken adgang findes til dine data ud over din egen?
Support-adgang, systemovervågning, fejlretning. Mange serviceaftaler giver udbyderen ret til at tilgå kundedata til netop de formål. Det skal fremgå af kortlægningen.
Det du ikke ved, du har
En kortlægning, der kun ser på det, it allerede kender, er ufuldstændig.
I de fleste organisationer har forretningsenheder over tid tegnet abonnementer direkte. Pengene kommer fra driftsbudgetter, ikke it-budgettet, og systemerne er aldrig anmeldt til virksomhedens DPO.
Der er to praktiske måder at afdække det på.
Den første er en gennemgang af kreditkortudgifter og fakturakategorier.
Den anden er en gennemgang af, hvilke applikationer der beder om at logge ind via organisationens identitetsudbyder.
De systemer, der bruger SSO, afslører sig selv. Ingen af metoderne er fuldstændige, men tilsammen giver de et langt mere retvisende billede end en serviceaftale-liste.
Infrastruktur som kode, ikke som dokumentation
Resultatet af kortlægningen skal ikke ende som endnu en fortegnelse i en skuffe. Det skal ende i kode.
Infrastruktur som kode betyder, at din infrastruktur er beskrevet i versionsstyrede filer, med OpenTofu eller tilsvarende, frem for at leve som en sum af manuelle klik i en cloud-konsol.
Det er forudsætningen for, at suverænitetsarbejdet giver reel bevægelsesfrihed i stedet for at blive en engangsflytning fra én låst platform til en anden.
To ting gør det afgørende her: du kan genskabe din infrastruktur på en anden platform, fordi den er defineret som kode, der kan køres mod en anden udbyder, og du kan sammenligne det definerede med det, der faktisk kører, og dermed opdage de ressourcer, der er opstået uden for den kontrollerede proces.
Den kode, der definerer din infrastruktur, er selv en del af din forsyningskæde, og dermed en del af suverænitetsspørgsmålet.
Det overser de fleste.
En organisation, der har flyttet sin cloud-infrastruktur til europæisk kontrol, men gemmer sin IaC (Infrastructure as Code) i GitHub, har sat kontrollen tilbage under Microsofts amerikanske juridiske ramme. Det er en inkonsistens, der skal håndteres bevidst.
Du kan selv hoste det nødvendige (Git-server, byggesystem, CI/CD-pipeline), men det kræver tid og kompetencer at gøre rigtigt og sikkert.
Alternativet er en europæisk Git- og CI/CD-platform, drevet under europæisk ret, hvad enten du hoster den selv eller køber den som driftsleverance.
Det afgørende er ikke produktnavnet, men to ting: at den juridiske enhed bag er europæisk, og at du kan eksportere kode og data uden bindingsklausuler.
En organisation, der ved, at den kører kritiske data på AWS, kan træffe en informeret beslutning om, hvad den vil gøre ved det. En organisation, der ikke ved, at dens HR-system sender medarbejderdata til en underdatabehandler i Virginia, kan ikke. Her gør kortlægningen en forskellen.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
