En koncern kan som udgangspunkt samle infrastrukturen på én platform med et fælles fundament og et adskilt rum for hvert selskab. Et selskab skal have sin egen platform eller sin egen udbyder, når dets krav fra kunder, tilsyn eller placering ikke kan opfyldes i det fælles, eller når det skal kunne drives uden resten.
Denne artikel ser på infrastrukturen: hvordan den bygges, så den kan rumme selskaber med forskellige krav.
Det fælles fundament
En landingszone er det fælles grundlag, som de enkelte miljøer i en cloud bygges på. Den rummer kontostrukturen, netværket mellem miljøerne og ud mod internettet, identitet og adgangsstyring, logning og overvågning, sikkerhedsregler og regler for mærkning af ressourcer, så forbruget kan fordeles. Begrebet hører hjemme i public cloud, og den samme tanke kan bruges i en privat platform eller i colocation.
I en koncern giver en fælles landingszone tre ting. Sikkerhed og logning sættes op én gang og gælder alle. Netværk mellem selskaberne er planlagt fra start. Og regningen kan fordeles på selskaberne, fordi alt er mærket. Hvordan koncernen afregner internt, står på cio-sitet.
Et rum pr. selskab
Inden for fundamentet får hvert selskab sit eget rum: en konto, et abonnement eller et projekt hos udbyderen, med egne adgangsrettigheder og eget budget. Selskabets data og systemer ligger i rummet, og kun selskabets egne folk og den fælles drift har adgang.
Rummene oprettes efter en fast opskrift, så et nyt selskab eller et nyt projekt får samme grundopsætning som de andre: samme regler for logning, samme netværksmodel og samme måde at mærke ressourcer på. Opskriften er en del af landingszonen og skal vedligeholdes, når fundamentet ændres.
Adskillelsen skal være reel. Fælles administratorer skal være få og logges. Data må kun flyttes mellem rummene efter regler, der står skrevet. Og et selskab skal kunne få en liste over, hvem der har haft adgang til dets rum. Det er vigtigt, når et selskab har kunder, der spørger, eller et tilsyn, der kræver det.
Når selskaberne har forskellige krav
Det er her, én platform kommer under pres. Tre slags forskelle lægger pres på den.
Placering. Et selskab har kunder, der kræver, at data opbevares i EU, eller at leverandøren er europæisk. Et andet sælger i et marked, hvor det er ligegyldigt. Kan landingszonen rumme begge dele, fx med regioner pr. rum, er det løst. Kræver det en anden kontraktpart, skal selskabet have sin egen udbyder.
Tilsyn. Et selskab er en finansiel enhed under DORA og skal kunne dokumentere sine aftaler med IKT-leverandører og have exitstrategier for kritiske funktioner. De andre selskaber har ikke de krav. Det kan løses med et særskilt rum og ekstra dokumentation, eller det kan kræve en særskilt platform. Se DORA og cloud.
Drift. Et selskab har produktion, der skal køre lokalt og uden forbindelse. Et andet er rent kontor. Den lokale drift skal stå for sig, og den fælles platform skal kunne undværes af produktionen.
Én platform, flere eller en blanding
Svaret kan stilles op som tre modeller.
Én platform, rum pr. selskab. Lettest at drive og at holde sikker. Kræver, at alle selskabers krav kan opfyldes hos samme udbyder.
Fælles fundament på flere platforme. Samme regler for identitet, logning og sikkerhed, men selskaberne står hos forskellige udbydere. Giver plads til forskellige krav og kræver mere af driften, fordi to platforme skal kendes og passes.
Selvstændige platforme. Hvert selskab har sin egen infrastruktur. Giver mest frihed og mest dobbeltarbejde, og koncernen mister overblikket, hvis ingen samler det.
Ender I med den midterste model, skal det være et valg, så den ikke opstår, fordi selskaberne gjorde hver deres.
Hvad det kræver, og hvad det koster at lade være
En kortlægning af selskabernes krav tager en til to uger: placering, kunder, tilsyn og drift pr. selskab. Et design af landingszonen er et projekt på nogle måneder, fordi identitet, netværk og logning skal aftales mellem selskaberne. Derefter kræver det en fælles drift, der ejer fundamentet.
Lader I være, vokser infrastrukturen op selskab for selskab. Så har koncernen flere konti hos flere udbydere, forskellige sikkerhedsregler og ingen samlet oversigt over forbrug eller adgang. Det koster i dobbelt drift, i licenser og i den tid, det tager at svare, når en kunde, revisor eller bestyrelse spørger, hvor data ligger.
Det skal I lade være med
- At lade selskaberne bygge hver deres uden fælles regler · overblikket forsvinder hurtigt.
- At tvinge alle ind på én platform, uanset krav · et selskab med andre krav skal kunne stå for sig.
- At give fælles administratorer ubegrænset adgang · adskillelsen skal kunne dokumenteres.
Det skal valget kunne vise
- ☐ Kravene pr. selskab: placering, kunder, tilsyn og drift.
- ☐ Den valgte model og begrundelsen.
- ☐ Det fælles fundament: identitet, netværk, logning og mærkning.
- ☐ Hvem der har adgang til hvert selskabs rum.
Senest gennemgået: november 2026.
Næste skridt
Skriv kravene op pr. selskab i fire kolonner. Så ser I, om ét fundament kan bære dem alle.
Læs også: FinOps, når regningen ikke længere kommer ét sted fra · Hvem kan logge ind?
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
