Managed Red Tenant
Where Architecture Draws the Line
Så börjar det nästan alltid
Tisdag eftermiddag, klockan 16.40. I den vänstra fliken står Admin Center öppet, rollen Global Admin har varit aktiv i tolv minuter eftersom en Conditional Access-policy krånglade. I den högra fliken landar en faktura från en leverantör vars namn adminen känner igen. Han klickar, PDF-filen visar sig vara ett program, och angriparen sitter nu på samma enhet som företagets mäktigaste roll. Han behövde varken en sårbarhet eller någon särskild begåvning för det, bara en enhet som betjänar två världar samtidigt.
Vi känner igen den här scenen från nästan varje incident response-insats, i medelstora bolag likaväl som i koncerner, och den har lärt oss en sak: ytterligare ett larm hjälper inte när angriparen redan sitter bredvid adminen. Det som hjälper är en gräns som ligger före detekteringen och som en klick inte kan ta sig förbi.
behöver en angripare i genomsnitt från den första åtkomsten till nästa system. Rekordet ligger på 27 sekunder.
av angreppen klarar sig utan skadlig kod. Angriparen loggar in som en kollega, med giltiga inloggningsuppgifter.
av alla bekräftade dataintrång slutade med ransomware.
enheter raderade ett enda kapat adminkonto hos Stryker på tre timmar. Ett konto, tre timmar.
Managed Red Tenant i tre delar
Tre avsnitt, inget längre än två minuter, där Jan Geisbauer och Thomas Naunheim förklarar varför separata adminkonton inte räcker på egen hand, varför en PAW utan egen tenant bara är halva jobbet och hur Red Tenant förenar båda till en arkitektur som håller i vardagen.
697 dokumenterade vägar. Angriparen behöver en.
MITRE ATT&CK listar 222 tekniker och 475 subtekniker som angripare använder för att utöka sina rättigheter och arbeta sig genom en miljö. Det låter som mångfald men är rutin: först klicket, sedan foten i dörren, sedan fler rättigheter, sedan nästa system. Managed Red Tenant kapar den kedjan på den enda punkt där den blir farlig, vid gränsen till Tier 0-adminen.
Kill chain-steg enligt MITRE ATT&CK Enterprise. Illustration glueckkanja.
Vad ni får ut av det
En Red Tenant är inte ännu en produkt som ert team måste driva. Den är ett beslut om arkitektur, och det förändrar fyra saker på en gång.
En signal,
inget brus
All legitim adminåtkomst kommer från Red Tenant. Allt annat är per definition ett angrepp, och ert SOC vet det i samma sekund. Ingen sorterar falsklarm längre, och ingen behöver gissa klockan tre på natten om Global Admin verkligen är en kollega just nu.
En mur, inget farthinder
Faller en laptop i kontorsvärlden stannar angriparen där. PAW:en på skrivbordet bredvid ligger för honom i en annan tenant, och dit leder ingen väg. Språnget upp till adminnivån är därmed inte längre en fråga om tid utan en fråga om arkitektur.
Ett bevis, ingen skärmdump
Varje ändring ligger versionerad, granskad och godkänd av er i repositoryt. När NIS2, ISO 27001 eller revisorn ber om underlag öppnar ni repositoryt i stället för att samla skärmdumpar. Compliance uppstår här på köpet, som en biprodukt av rent arbete.
Admins som gärna arbetar med det
Säkerhet som stör i vardagen blir kringgången, och det av de klokaste personerna i huset. Därför får era admins verktyg som är snabbare än varje omväg. Till slut är det säkra alternativet det bekväma, och det är det enda skälet till att det håller.
Halv separation är ingen separation.
På en komprometterad adminarbetsstation finns fem vanliga svar, och vart och ett löser en del av problemet. Inget av dem isolerar administrationen på riktigt, eftersom alla fem körs inne i den riskzon de ska skydda.
Så ser gränsen ut
Managed Red Tenant är en egen Microsoft Entra-tenant, uppsatt greenfield, utan beroende till er produktionstenant och utan beroende till vår. Där bor bara de privilegierade identiteterna, deras enheter och de resurser som förmedlar åtkomsten. Era rättigheter stannar hos er och tilldelas via cross-tenant-policyer, Entitlement Management och Privileged Identity Management, alltid just-in-time och aldrig på lager.
En röd identitet loggar in enbart med FIDO2 och enbart från en enhet som Red Tenant hanterar, för Conditional Access i er tenant släpper inte igenom något annat. Vägen till on-premises-system tar Global Secure Access hand om utan en enda publik slutpunkt, och stämmer något inte drar Continuous Access Evaluation tillbaka åtkomsten inom sekunder, inte först vid nästa inloggning.
Tenantgräns
- 1Röd identitet, endast FIDO2
- 2Enhet från Red Tenant
- 3Conditional Access kontrollerar båda
- 4PIM aktiverar rollen just-in-time
- 5Åtkomst till er tenant, loggad
Cross-tenant-relationen etableras en gång vid onboardingen. Illustration glueckkanja.
Två enhetsklasser, så att separationen håller i vardagen
Tiern bestäms inte av IP-adressen utan av tangentbordet någon sitter vid. Därför får varje nivå den enhet som passar den, och ingen som kan mer än nödvändigt.
PAW: dedikerad hårdvara för Tier 0
För Global Admins och alla som rör vid Control Plane: en egen enhet, en person, en uppgift. Det som inte hör hemma på den här maskinen kommer inte ens dit, eftersom Application Control inte tillåter det.
- Application Control, ingen lokal admin
- TPM, Secure Boot, Defender-övervakning
- FIDO2 only, webb endast mot adminslutpunkter
VAW: virtuell arbetsstation för Tier 1
För den breda administrationen av Azure, Microsoft 365 och on-premises: en virtuell arbetsstation, nåbar från kontorsenheten men aldrig en del av den. Den skalar till hundratals admins utan att någon beställer hårdvara.
- Azure Virtual Desktop i Red Tenant
- Entra Private Access, ingen publik slutpunkt
- Identitetsbyte, compliant device, FIDO2
Er väg in i Red Tenant
- ParametriseringsworkshopParametriseringsworkshopVi sätter oss ner tillsammans med er och fastställer roller, tiering, personas och processer. Under tiden klarnar det vilka av era admins som behöver en PAW och vem som klarar sig med en VAW, och oftast blir det färre PAW:ar än alla har räknat med.
- Uppbyggnad som kodUppbyggnad som kodEr Red Tenant växer fram ur vår blueprint, helt och hållet som kod: Entra ID, Intune, Conditional Access, enhetsprofiler och cross-tenant-relationen till er produktionstenant, allt versionerat, allt spårbart.
- Handover och driftHandover och driftEra första Tier 0-admins flyttar in, resten följer i vågor. Därefter driver vi miljön dygnet runt till ett fast månadspris, och ni har en sak mindre att oroa er för.
Managed as code, med er vetorätt
Red Tenant rörs aldrig i portalen. Varje ändring, vare sig det är en ny policy, en ny enhet eller en ny Microsoft-funktion, går genom samma fem stationer, varje gång, och den träder i kraft först när ni har godkänt den.
- 1Ändring som kodKonfiguration, policyer och enhetsprofiler ligger versionerade i repositoryt. Varje ändring börjar där som en pull request, ingen annanstans.
- 2FyraögonsgranskningEn andra person hos oss granskar ändringen fackmässigt innan den körs någonstans.
- 3Test i stagingÄndringen körs först i vår staging-miljö, innan den ens läggs fram för er.
- 4Customer ApprovalEr approver godkänner eller avslår. Utan det godkännandet händer ingenting, inte heller hos oss.
- 5DeploymentPipelinen rullar ut ändringen i er Red Tenant, loggat, spårbart, upprepbart när som helst.
Vid varje ändring från början igen, även vid våra egna.
Därmed är också den fråga besvarad som varje inköpare borde ställa, nämligen vad som händer om tjänsteleverantören själv blir komprometterad. Svaret är: ingenting. Utan ert godkännande träder ingen ändring i kraft, och vi driver er miljö från vår egen Red Tenant, enligt samma regler som gäller för er.
Vad ni bidrar med, vad vi tar hand om
En Red Tenant är inget ni beställer på fredagen och använder på måndagen. Den är ett projekt med ett tydligt slut och därefter en drift som ni inte behöver bära själva. För att ingen ska bli överraskad kommer här den ärliga uppdelningen.
Ni bidrar med
- En produktionstenant som ni vill skydda, gärna flera, gärna hybrid med Active Directory
- PAW-hårdvaran för era Tier 0-roller, och vi talar om för er i förväg exakt vilka enheter som kommer i fråga
- Två till tre personer på er sida som ger godkännanden och ansöker om konton
- Viljan att verkligen skilja administration från vardag, även om det känns ovant de första veckorna
Vi tar hand om
- Uppbyggnaden av Red Tenant utifrån vår blueprint, helt och hållet som kod
- Härdning, enhetsprovisionering och hela livscykeln för de privilegierade identiteterna
- Driften dygnet runt, ansluten till vårt CSOC
- Varje nyhet Microsoft levererar, genom samma pipeline och med samma godkännande
Eftersom hela Red Tenant finns som kod går deployment på mycket kort tid, och era första Tier 0-admins arbetar i Red Tenant långt innan resten följer. Driften löper till ett fast månadspris, utan överraskningar på fakturan.
Angrepp mot kontrollplanet
Runt 20 sidor, tre verkliga incidenter isärplockade steg för steg, och ett tydligt svar på hur en isolerad administrationsmiljö som drivs som kod ser ut i praktiken. Skriven för CISO:er och IT-ledning och för alla som måste bära ämnet uppåt internt och behöver argument som håller inför en styrelse.
- Storm-0501, Storm-2949 och Stryker: tre angreppskedjor, tre lärdomar
- Varför MFA, EDR och SOC inte skyddar administrationsplanet
- Från Red Forest till Red Tenant: sju kännetecken för målarkitekturen
- Koppling till NIS2 artikel 21, ISO 27001 bilaga A och DORA
Vem som driver Red Tenant
Vi driver Red Tenants för DAX-koncerner och operatörer av kritisk infrastruktur, och vi hanterar de miljöerna från vår egen Red Tenant. Den standard vi driver åt er gäller alltså först för oss själva.
Som BSI-kvalificerad APT Response-leverantör står vi regelbundet på andra sidan, när det redan brinner hos ett företag. Det vi ser där flyter direkt tillbaka in i arkitekturen, och det är skälet till att Red Tenant ser ut som den gör.
Managed Dark Tenant
Red Tenant ser till att en komprometterad klient aldrig blir en komprometterad domän. Managed Dark Tenant besvarar den andra frågan, nämligen hur ni förblir handlingskraftiga om det ändå händer: en förberedd Microsoft-miljö som vilar i normal drift, som väcks av ett samtal till vår 24/7-hotline och där ert kristeam inom några timmar har säker kommunikation, arbetsplatser och en recovery-pipeline för Active Directory. Det ena är muren, det andra är hoppnätet.
Till Managed Dark TenantTre sätt att börja. Inget av dem förpliktar er.
Frågor vi hör i det första samtalet
Kort och ärligt besvarade, och om er fråga saknas, ställ den till oss i formuläret nedan.
Vad är en Red Tenant, och varför administrerar man inte i produktionstenanten?
En Red Tenant är en egen Microsoft Entra-tenant som uteslutande finns till för privilegierade identiteter och deras enheter, och produktionstenanten administreras därifrån, aldrig ur sig själv.
Skälet är enkelt: den som komprometterar en tenant kontrollerar automatiskt också de konton man skulle reparera den med. Ligger de kontona i en annan tenant är vägen från komprometterad användare till fullständig kontroll bruten. Namnet anknyter till Red Forest, Microsofts tidigare modell för en separat adminskog för Active Directory.
Vad är Microsoft Enterprise Access Model, och vad hör hemma i Tier 0, Tier 1 och Tier 2?
Enterprise Access Model delar in er miljö i nivåer: Control Plane (Tier 0) innehåller allt som hanterar identiteter och rättigheter, Management Plane (Tier 1) omfattar servrar, applikationer och workloads, och User Access Plane (Tier 2) består av slutenheter och användare.
Regeln bakom lyder att en högre nivå aldrig får vara kontrollerbar från en lägre. I Entra ID hör därför roller som Global Administrator, Privileged Role Administrator, Conditional Access Administrator och Intune Administrator till Tier 0, därtill Entra Connect och allt som patchar, säkerhetskopierar eller övervakar de systemen.
Hur genomför man ett tiering-koncept i praktiken, och var börjar man?
Helst med en ärlig inventering av Control Plane, alltså frågan om vilka konton, grupper, tjänstekonton och applikationer som i dag kan förändra identiteter eller rättigheter. I de flesta miljöer är det betydligt fler än man hade trott.
Därefter separerar ni kontona per nivå, ersätter permanenta tilldelningar med PIM och begränsar inloggningen till dedikerade enheter. Vår kostnadsfria tiering-check visar er grafiskt var tier-gränser överskrids i dag, och är därmed den snabbaste starten vi känner till.
Varför räcker inte PIM och Conditional Access på egen hand för privilegierade åtkomster?
Båda kontrollerar identiteten och omständigheterna kring inloggningen, men ingen av dem kontrollerar enheten som tangentbordet sitter på.
En lyckad, stark autentisering slutar i en token på slutenheten, och är den enheten komprometterad blir token stulen eller sessionen kapad, trots att PIM och Conditional Access har gjort sitt jobb korrekt fram till dess. Red Tenant använder båda och kräver dessutom att enheten själv kommer från den isolerade miljön.
Vad är en Privileged Access Workstation, och när behöver den dedikerad hårdvara?
En Privileged Access Workstation (PAW) är en härdad arbetsstation som uteslutande används för administrativa uppgifter, alltså utan mail och allmänt surfande, med Application Control, utan lokal admin och med ett förtroendeankare via TPM och Secure Boot.
Dedikerad hårdvara behöver den för alla roller med åtkomst till Control Plane, för där gäller principen om det rena tangentbordet: en inloggningsuppgift får aldrig röra en enhet vars förtroendenivå är lägre än målets. För Tier 1 räcker den virtuella varianten.
PAW eller virtuell adminarbetsstation: När räcker den virtuella varianten?
För allt under Control Plane. Den virtuella Access Workstation (VAW) körs som Azure Virtual Desktop i Red Tenant, och ni når den från en compliant kontorsenhet via Entra Private Access, med identitetsbyte och FIDO2.
Den skalar utan hårdvara och täcker Azure, Microsoft 365 och on-premises, men en restrisk kvarstår eftersom åtkomsten går via en Tier 2-enhet. Just därför förblir Control Plane förbehållen hårdvaru-PAW:en.
Behöver varje admin en separat arbetsstation?
Nej, men varje admin behöver en separat identitet och en separat åtkomstväg, och om det blir en fysisk PAW eller en virtuell VAW avgörs av den nivå personen arbetar på.
I praktiken har bara ett fåtal personer Tier 0-rättigheter och får en hårdvaru-PAW, medan den breda majoriteten arbetar via VAW:ar. Just därför skalar modellen från 5 till 5 000 admins.
Vad skiljer en Red Tenant från en PAW i den egna tenanten?
Skillnaden ligger i förtroendeankaret. En PAW vars konto, policyer och enhetshantering ligger i samma tenant som de produktiva systemen delar deras öde, för den som kontrollerar tenanten kontrollerar också den Intune-policy som härdar PAW:en.
Red Tenant flyttar konto, enhet och hantering till en egen tenant som inte är nåbar från produktionstenanten. PAW:en förblir samma byggsten, den står bara på en annan grund.
Vad skiljer Red Tenant från Privileged Access Management?
PAM-lösningar förvarar inloggningsuppgifter och förmedlar sessioner, de skyddar alltså uppgiften men inte enheten den används från. Är slutpunkten komprometterad rider angriparen helt enkelt med i den förmedlade sessionen, och Microsoft skriver själva att PAM-lösningar på egen hand inte täcker enhetsrisken på ett tillförlitligt sätt.
Red Tenant ersätter inte PAM utan kompletterar det: PIM och befintliga valv går att använda vidare, bara att åtkomsten nu kommer från en enhet utanför riskzonen.
Vad händer om glueckkanja själv blir komprometterat?
Ingenting som skulle träda i kraft utan ert godkännande. Varje ändring i Red Tenant går som kod genom en pipeline och kräver godkännande från en customer approver på er sida, och nödåtkomsterna är uppdelade så att ingen sida kan agera ensam.
Till det kommer att vi hanterar er miljö från vår egen Red Tenant, enligt samma regler som gäller för er. Vetorätten stannar alltid hos kunden.
Vad kräver NIS2 för adminkonton och privilegierade åtkomster?
Artikel 21 punkt 2 nämner bland annat koncept för åtkomstkontroll, multifaktorautentisering och säkerhet vid anskaffning, utveckling och underhåll av system, och artikel 20 gör företagsledningen ansvarig för att övervaka och styrka genomförandet.
I Tyskland gäller det sedan december 2025 via BSI-lagen, i Österrike från den 1 oktober 2026 via NISG 2026. BSI:s IT-Grundschutz känner separationen av administrativa uppgifter som baskrav och utlokaliseringen av administrationen till en egen struktur som förhöjt krav. Red Tenant är molnimplementationen av precis det, och det versionerade repositoryt är ert bevis.
Är ett tiering-koncept för komplext eller för dyrt för medelstora företag?
För komplext för egen drift är det ofta faktiskt, för den dyra delen är inte tekniken utan den varaktiga härdningen, underhållet, övervakningen och bevisföringen, som ingen klarar av vid sidan om.
Just det är skälet till den managed servicen: arbetet ligger hos oss, där automatisering och upprepning gör det hanterbart, och en Red Tenant för 20 admins är samma kod som en för 2 000.
Microsoft har dragit tillbaka Red Forest-modellen. Varför då en separat admintenant?
Microsoft drog tillbaka ESAE för att modellen bara täckte on-premises-administratörer och var för komplex i drift, inte för att separationen skulle ha varit verkningslös.
Samma dokumentation slår fast att Microsoft internt fortfarande driver en jämförbar arkitektur, rekommenderar PAW:ar för alla administrativa uppgifter och nämner uttryckligen isolering över flera tenants för resurser med särskilt skyddsbehov. Red Tenant är molnversionen av den principen, och driftarbetet som ESAE föll på ligger hos den managed servicen.
Vi har tiering, PIM och Conditional Access. Vad ändrar en Red Tenant på det?
Tiering reglerar vem som får göra vad, PIM reglerar när, och Conditional Access reglerar under vilka villkor. Alla tre ligger dock i samma miljö som de ska skydda och hanteras av roller som en angripare med Global Admin-rättigheter också har.
Red Tenant lyfter ut administrationen ur den miljön, era befintliga kontroller består och får ett förtroendeankare som inte längre går att nå inifrån.
