Slik begynner det nesten alltid
Tirsdag ettermiddag, klokken 16.40. I venstre fane står Admin Center åpent, Global Admin-rollen har vært aktiv i tolv minutter fordi en Conditional Access-policy krøllet seg. I høyre fane lander en faktura fra en leverandør som administratoren kjenner navnet på. Han klikker, PDF-en viser seg å være et program, og angriperen sitter nå på samme enhet som den mektigste rollen i selskapet. Han trengte verken et sikkerhetshull eller noe særskilt talent til det, bare en enhet som betjener to verdener samtidig.
Vi kjenner denne scenen fra nesten hvert eneste incident response-oppdrag, i mellomstore bedrifter like mye som i store konsern, og den har lært oss én ting: enda et varsel hjelper ikke når angriperen allerede sitter ved siden av administratoren. Det som hjelper, er en grense som ligger foran deteksjonen, og som et klikk ikke kommer forbi.
bruker en angriper i gjennomsnitt fra første tilgang til neste system. Rekorden ligger på 27 sekunder.
av angrepene klarer seg uten skadevare. Angriperen logger inn som en kollega, med gyldig påloggingsinformasjon.
av alle bekreftede datainnbrudd endte med ransomware.
enheter slettet en eneste kapret admin-konto hos Stryker på tre timer. Én konto, tre timer.
Managed Red Tenant i tre deler
Tre episoder, ingen av dem to minutter lange, der Jan Geisbauer og Thomas Naunheim forklarer hvorfor atskilte admin-kontoer alene ikke holder, hvorfor en PAW uten egen tenant bare er halve jobben, og hvordan Red Tenant knytter begge deler sammen til en arkitektur som tåler hverdagen.
697 dokumenterte veier inn. Angriperen trenger én.
MITRE ATT&CK lister 222 teknikker og 475 subteknikker som angripere bruker til å eskalere rettigheter og arbeide seg gjennom et miljø. Det høres ut som mangfold, men er rutine: først klikket, så fotfestet, så flere rettigheter, så neste system. Managed Red Tenant kutter denne kjeden på det ene stedet der den blir farlig, ved grensen til Tier 0-administratoren.
Kill chain-trinn etter MITRE ATT&CK Enterprise. Illustrasjon glueckkanja.
Hva du får ut av det
En Red Tenant er ikke enda et produkt teamet ditt må drifte. Den er en beslutning om arkitektur, og den endrer fire ting på én gang.
Ett signal,
ingen støy
All legitim admin-tilgang kommer fra Red Tenant. Alt annet er per definisjon et angrep, og SOC-en din vet det i samme sekund. Ingen sorterer falske alarmer lenger, og ingen må gjette klokken tre om natten på om Global Admin virkelig er en kollega akkurat nå.
En mur, ikke en fartsdump
Faller en laptop i kontorverdenen, blir angriperen værende der. PAW-en på pulten ved siden av ligger for ham i en annen tenant, og dit fører ingen vei. Spranget opp på adminnivået er dermed ikke lenger et spørsmål om tid, men om arkitektur.
Dokumentasjon, ikke skjermbilder
Hver endring ligger versjonert, kontrollert og godkjent av deg i repositoriet. Når NIS2, ISO 27001 eller revisoren ber om belegg, åpner du repositoriet i stedet for å samle skjermbilder. Compliance oppstår her på kjøpet, som et biprodukt av ryddig arbeid.
Administratorer som liker å jobbe med det
Sikkerhet som irriterer i hverdagen, blir omgått, og det av de skarpeste folkene i huset. Derfor får administratorene dine verktøy som er raskere enn enhver omvei. Til slutt er den sikre varianten også den behagelige, og det er den eneste grunnen til at den holder.
Halv separasjon er ingen separasjon.
På en kompromittert admin-arbeidsplass finnes det fem vanlige svar, og hvert av dem løser en bit av problemet. Ingen av dem isolerer administrasjonen for alvor, for alle fem kjører inne i risikosonen de skal beskytte.
Slik ser grensen ut
Managed Red Tenant er en egen Microsoft Entra-tenant, satt opp greenfield, uten avhengighet til produksjonstenanten din og uten avhengighet til vår. Der bor bare de privilegerte identitetene, enhetene deres og ressursene som formidler tilgangen. Rettighetene dine blir hos deg og tildeles via cross-tenant-policyer, Entitlement Management og Privileged Identity Management, alltid just-in-time og aldri på lager.
En rød identitet logger bare inn med FIDO2, og bare fra en enhet som Red Tenant administrerer, for Conditional Access i tenanten din slipper ikke gjennom noe annet. Veien til on-premises-systemer tar Global Secure Access seg av uten et eneste offentlig endepunkt, og stemmer noe ikke, trekker Continuous Access Evaluation tilgangen tilbake i løpet av sekunder, ikke først ved neste pålogging.
Tenantgrense
- 1Rød identitet, bare FIDO2
- 2Enhet fra Red Tenant
- 3Conditional Access kontrollerer begge
- 4PIM aktiverer rollen just-in-time
- 5Tilgang til tenanten din, logget
Cross-tenant-relasjonen etableres én gang under onboarding. Illustrasjon glueckkanja.
To enhetsklasser, slik at separasjonen holder i hverdagen
Det er ikke IP-adressen som bestemmer tier, men tastaturet noen sitter ved. Derfor får hvert nivå den enheten som passer til det, og ingen som kan mer enn nødvendig.
PAW: dedikert maskinvare for Tier 0
For Global Admins og alle som tar i Control Plane: én egen enhet, én person, én oppgave. Det som ikke har noe på denne maskinen å gjøre, kommer aldri inn på den, fordi Application Control ikke tillater det.
- Application Control, ingen lokal admin
- TPM, Secure Boot, Defender-overvåking
- FIDO2 only, web bare mot admin-endepunkter
VAW: virtuell workstation for Tier 1
For den brede administrasjonen av Azure, Microsoft 365 og on-premises: en virtuell workstation, tilgjengelig fra kontorenheten, men aldri en del av den. Den skalerer til hundrevis av administratorer uten at noen bestiller maskinvare.
- Azure Virtual Desktop i Red Tenant
- Entra Private Access, ingen offentlige endepunkter
- Identitetsbytte, Compliant Device, FIDO2
Din vei inn i Red Tenant
- ParametriseringsworkshopParametriseringsworkshopVi setter oss ned sammen med deg og fastsetter roller, tiering, personas og prosesser. Underveis blir det klart hvilke av administratorene dine som trenger en PAW og hvem som klarer seg med en VAW, og som regel er det færre PAW-er enn alle hadde ventet.
- Oppbygging som kodeOppbygging som kodeRed Tenant-en din bygges ut fra vår blueprint, fullstendig som kode: Entra ID, Intune, Conditional Access, enhetsprofiler og cross-tenant-relasjonen til produksjonstenanten din, alt versjonert, alt sporbart.
- Overlevering og driftOverlevering og driftDe første Tier 0-administratorene dine flytter inn, resten følger i bølger. Fra da av drifter vi miljøet døgnet rundt til en fast månedspris, og du har én bekymring mindre.
Managed as code, med din vetorett
Red Tenant røres aldri i portalen. Hver endring, enten det er en ny policy, en ny enhet eller en ny Microsoft-funksjon, går gjennom de samme fem stasjonene, hver eneste gang, og den trer først i kraft når du har godkjent den.
- 1Endring som kodeKonfigurasjon, policyer og enhetsprofiler ligger versjonert i repositoriet. Hver endring starter der som en pull request, ingen andre steder.
- 2Fire øyne-prinsippetEn annen person hos oss går gjennom endringen faglig før den kjører noe sted.
- 3Test i stagingEndringen kjører først i vårt staging-miljø, før den i det hele tatt legges fram for deg.
- 4Customer ApprovalDin approver godkjenner eller avviser. Uten denne godkjenningen skjer ingenting, heller ikke hos oss.
- 5DeploymentPipelinen ruller endringen ut i Red Tenant-en din, logget, sporbart og mulig å gjenta når som helst.
Fra start ved hver endring, også ved våre egne.
Dermed er også spørsmålet besvart som enhver innkjøper burde stille, nemlig hva som skjer hvis leverandøren selv blir kompromittert. Svaret er ingenting. Uten din godkjenning trer ingen endring i kraft, og vi drifter miljøet ditt fra vår egen Red Tenant, etter de samme reglene som gjelder for din.
Hva du stiller med, hva vi tar oss av
En Red Tenant er ikke noe du bestiller på fredag og tar i bruk på mandag. Den er et prosjekt med en tydelig slutt, og deretter en drift du ikke trenger å bære selv. Så ingen blir overrasket, her er den ærlige fordelingen.
Du stiller med
- En produksjonstenant du vil beskytte, gjerne flere, gjerne hybrid med Active Directory
- PAW-maskinvaren til Tier 0-rollene dine, og vi sier på forhånd nøyaktig hvilke enheter som er aktuelle
- To til tre personer på din side som gir godkjenninger og bestiller kontoer
- Viljen til virkelig å skille administrasjon fra hverdag, selv om det kjennes uvant de første ukene
Vi tar oss av
- Oppbyggingen av Red Tenant ut fra vår blueprint, fullstendig som kode
- Herding, enhetsprovisjonering og hele livssyklusen til de privilegerte identitetene
- Driften døgnet rundt, koblet til vårt CSOC
- Hver nyhet Microsoft leverer, gjennom den samme pipelinen og med den samme godkjenningen
Fordi hele Red Tenant foreligger som kode, går deployment unna på svært kort tid, og de første Tier 0-administratorene dine jobber i Red Tenant lenge før resten følger etter. Driften løper til en fast månedspris, uten overraskelser på fakturaen.
Angrep på kontrollnivået
Rundt 20 sider, tre reelle hendelser plukket fra hverandre steg for steg, og et tydelig svar på hvordan et isolert administrasjonsmiljø driftet som kode ser ut i praksis. Skrevet for CISO-er og IT-ledelse, og for alle som må løfte temaet oppover internt og trenger argumenter som holder foran et styre.
- Storm-0501, Storm-2949 og Stryker: tre angrepskjeder, tre lærdommer
- Hvorfor MFA, EDR og SOC ikke beskytter administrasjonsnivået
- Fra Red Forest til Red Tenant: sju kjennetegn ved målarkitekturen
- Kobling til NIS2 artikkel 21, ISO 27001 vedlegg A og DORA
Hvem som drifter Red Tenant
Vi drifter Red Tenants for DAX-konsern og operatører av kritisk infrastruktur, og vi administrerer disse miljøene fra vår egen Red Tenant. Standarden vi drifter for deg, gjelder altså først for oss selv.
Som BSI-kvalifisert APT Response-leverandør står vi jevnlig på den andre siden når det allerede brenner hos en bedrift. Det vi ser der, går rett tilbake inn i arkitekturen, og det er grunnen til at Red Tenant ser ut som den gjør.
Managed Dark Tenant
Red Tenant sørger for at en kompromittert klient aldri blir et kompromittert domene. Managed Dark Tenant svarer på det andre spørsmålet, nemlig hvordan du forblir handlingsdyktig hvis det likevel skjer: et forberedt Microsoft-miljø som hviler i normal drift, som vekkes av én telefon til vår 24/7-hotline, og der kriseteamet ditt innen få timer har sikker kommunikasjon, arbeidsplasser og en recovery-pipeline for Active Directory. Det ene er muren, det andre er sikkerhetsnettet.
Til Managed Dark TenantTre måter å begynne på. Ingen av dem forplikter deg.
Spørsmål vi hører i det første samtalen
Kort og ærlig besvart, og mangler spørsmålet ditt, still det til oss i skjemaet nedenfor.
Hva er en Red Tenant, og hvorfor administrerer man ikke inne i produksjonstenanten?
En Red Tenant er en egen Microsoft Entra-tenant som utelukkende finnes for privilegerte identiteter og enhetene deres, og produksjonstenanten administreres derfra, aldri fra seg selv.
Grunnen er enkel: den som kompromitterer en tenant, kontrollerer automatisk også kontoene man skulle reparert den med. Ligger disse kontoene i en annen tenant, er veien fra en kompromittert bruker til full kontroll brutt. Navnet spiller på Red Forest, Microsofts tidligere modell med en egen admin-skog for Active Directory.
Hva er Microsoft Enterprise Access Model, og hva hører hjemme i Tier 0, Tier 1 og Tier 2?
Enterprise Access Model deler miljøet ditt i nivåer: Control Plane (Tier 0) inneholder alt som forvalter identiteter og rettigheter, Management Plane (Tier 1) omfatter servere, applikasjoner og workloads, og User Access Plane (Tier 2) består av endeenheter og brukere.
Regelen bak er at et høyere nivå aldri skal kunne kontrolleres fra et lavere. I Entra ID hører derfor roller som Global Administrator, Privileged Role Administrator, Conditional Access Administrator og Intune Administrator til Tier 0, i tillegg til Entra Connect og alt som patcher, sikkerhetskopierer eller overvåker disse systemene.
Hvordan gjennomfører man et tiering-konsept i praksis, og hvor begynner man?
Helst med en ærlig inventering av Control Plane, altså spørsmålet om hvilke kontoer, grupper, tjenestekontoer og applikasjoner som i dag kan endre identiteter eller rettigheter. I de fleste miljøer er det atskillig flere enn man hadde trodd på forhånd.
Deretter skiller du kontoene per nivå, erstatter permanente tildelinger med PIM og begrenser pålogging til dedikerte enheter. Vår gratis tiering-check viser deg grafisk hvor tier-grenser krysses i dag, og er dermed den raskeste inngangen vi kjenner til.
Hvorfor holder ikke PIM og Conditional Access alene for privilegerte tilganger?
Begge kontrollerer identiteten og omstendighetene rundt påloggingen, men ingen av dem kontrollerer enheten som tastaturet henger på.
En vellykket, sterk autentisering ender i et token på endeenheten, og er denne enheten kompromittert, blir tokenet stjålet eller sesjonen overtatt, selv om PIM og Conditional Access har gjort jobben sin riktig fram til da. Red Tenant bruker begge og krever i tillegg at selve enheten kommer fra det isolerte miljøet.
Hva er en Privileged Access Workstation, og når trenger den dedikert maskinvare?
En Privileged Access Workstation (PAW) er en herdet arbeidsplass som utelukkende brukes til administrative oppgaver, altså uten e-post og alminnelig surfing, med Application Control, uten lokal admin og med et tillitsanker via TPM og Secure Boot.
Dedikert maskinvare trenger den for alle roller med tilgang til Control Plane, for der gjelder prinsippet om det rene tastaturet: påloggingsinformasjon skal aldri berøre en enhet med lavere tillitsnivå enn målet. For Tier 1 holder den virtuelle varianten.
PAW eller virtuell admin-workstation: når holder den virtuelle varianten?
For alt under Control Plane. Den virtuelle Access Workstation (VAW) kjører som Azure Virtual Desktop i Red Tenant, og du når den fra en compliant kontorenhet via Entra Private Access, med identitetsbytte og FIDO2.
Den skalerer uten maskinvare og dekker Azure, Microsoft 365 og on-premises, men en restrisiko blir igjen, fordi tilgangen går via en Tier 2-enhet. Nettopp derfor forblir Control Plane forbeholdt PAW-en på egen maskinvare.
Trenger hver administrator en egen workstation?
Nei, men hver administrator trenger en egen identitet og en egen tilgangsvei, og om det blir en fysisk PAW eller en virtuell VAW, avgjøres av nivået personen jobber på.
I praksis har bare noen få personer Tier 0-rettigheter og får en PAW på egen maskinvare, mens det store flertallet jobber via VAW-er. Nettopp derfor skalerer modellen fra 5 til 5 000 administratorer.
Hva skiller en Red Tenant fra en PAW i egen tenant?
Forskjellen ligger i tillitsankeret. En PAW der konto, policyer og enhetsadministrasjon ligger i samme tenant som produksjonssystemene, deler skjebne med dem, for den som kontrollerer tenanten, kontrollerer også Intune-policyen som herder PAW-en.
Red Tenant flytter konto, enhet og administrasjon inn i en egen tenant som ikke kan nås fra produksjonstenanten. PAW-en forblir den samme byggeklossen, den står bare på et annet fundament.
Hva skiller Red Tenant fra Privileged Access Management?
PAM-løsninger oppbevarer påloggingsinformasjon og formidler sesjoner, de sikrer altså credentialet, men ikke enheten det brukes fra. Er endepunktet kompromittert, blir angriperen rett og slett med i den formidlede sesjonen, og Microsoft skriver selv at PAM-løsninger alene ikke dekker enhetsrisikoen på en pålitelig måte.
Red Tenant erstatter ikke PAM, men utfyller det: PIM og eksisterende hvelv kan fortsatt brukes, bare at tilgangen nå kommer fra en enhet utenfor risikosonen.
Hva skjer hvis glueckkanja selv blir kompromittert?
Ingenting som ville trådt i kraft uten din godkjenning. Hver endring i Red Tenant går som kode gjennom en pipeline og krever godkjenning fra en Customer Approver på din side, og nødtilganger er delt opp slik at ingen av partene kan handle alene.
I tillegg administrerer vi miljøet ditt fra vår egen Red Tenant, etter de samme reglene som gjelder for ditt. Vetoretten blir alltid hos kunden.
Hva krever NIS2 for admin-kontoer og privilegerte tilganger?
Artikkel 21 nr. 2 nevner blant annet konsepter for tilgangskontroll, multifaktorautentisering og sikkerhet ved anskaffelse, utvikling og vedlikehold av systemer, og artikkel 20 gjør ledelsen ansvarlig for å følge opp og dokumentere gjennomføringen.
I Tyskland gjelder dette siden desember 2025 gjennom BSI-loven, i Østerrike fra 1. oktober 2026 gjennom NISG 2026. Den tyske BSI IT-Grundschutz regner separasjon av administrative oppgaver som et basiskrav og utflytting av administrasjonen til en egen struktur som et forhøyet krav. Red Tenant er cloud-gjennomføringen av nettopp det, og det versjonerte repositoriet er dokumentasjonen din.
Er et tiering-konsept for komplekst eller for dyrt for mellomstore bedrifter?
For komplekst til å drifte selv er det ofte faktisk, for den dyre delen er ikke teknikken, men den vedvarende herdingen, vedlikeholdet, overvåkingen og dokumentasjonen, som ingen rekker ved siden av alt annet.
Nettopp det er grunnen til at dette er en managed service: innsatsen ligger hos oss, der automation og gjentakelse gjør den håndterbar, og en Red Tenant for 20 administratorer er den samme koden som en for 2 000.
Microsoft har trukket tilbake Red Forest-modellen. Hvorfor da en egen admin-tenant?
Microsoft trakk tilbake ESAE fordi modellen bare dekket administratorer on-premises og var for kompleks i drift, ikke fordi separasjonen hadde vært virkningsløs.
Den samme dokumentasjonen slår fast at Microsoft fortsatt drifter en tilsvarende arkitektur internt, anbefaler PAW-er for alle administrative oppgaver og nevner uttrykkelig isolasjon over flere tenants for ressurser med særlig høyt beskyttelsesbehov. Red Tenant er cloud-utgaven av dette prinsippet, og driftsbyrden som ESAE strandet på, ligger hos den managed servicen.
Vi har tiering, PIM og Conditional Access. Hva endrer en Red Tenant på det?
Tiering styrer hvem som får lov til hva, PIM styrer når, og Conditional Access styrer under hvilke betingelser. Alle tre ligger imidlertid i det samme miljøet som de skal beskytte, og forvaltes av roller som en angriper med Global Admin-rettigheter også har.
Red Tenant henter administrasjonen ut av dette miljøet, de eksisterende kontrollene dine blir stående og får et tillitsanker som ikke lenger kan nås innenfra.
