Ett konto.
Allt borta?
Inte nödvändigtvis.
NIS2 föreskriver tio riskåtgärder. Med Managed Red Tenant och Dark Tenant stöttar vi vid den tekniska implementeringen. För en avsevärt minskad angreppsrisk och tryggheten att vara handlingskraftig igen inom timmar om det värsta händer.
Det intressanta med Stryker-attacken den 11 mars 2026 är inte antalet drabbade enheter, även om 80 000 enheter i 79 länder är en anmärkningsvärd siffra, utan medlets banalitet: ingen exploit, ingen zero-day, ingen sofistikerad attack mot infrastrukturkomponenter som bara ett fåtal känner till. Ett enda komprometterat Intune-admin-konto räckte, och utifrån såg attacken ut som normal drift, eftersom den i teknisk mening var det, bara utförd av någon annan. Exakt vad som hände står i blogginlägget om Stryker-attacken.
De flesta företagsinfrastrukturer är byggda så att denna skada är möjlig, inte för att de ansvariga varit försumliga, utan för att privilegierade konton med långtgående rättigheter under år ansetts praktiska: ett konto som har åtkomst överallt sparar tid i det dagliga arbetet, och tid är som bekant det enda som är ännu knappare än budget på IT-avdelningar. NIS2 artikel 21 drar konsekvenserna av denna praxis: privilegierade identiteter måste vara så isolerade att en kompromettering av dem inte drar med sig hela infrastrukturen, och den som ändå drabbas måste vara handlingskraftig igen inom timmar.
Vad NIS2 är och vem direktivet berör förklarar vi här. Den här sidan handlar om stödet vid den tekniska implementeringen av riskåtgärderna med Managed Red Tenant och Managed Dark Tenant.
Managed Red Tenant: så att ett komprometterat konto inte blir en generalnyckel
Angreppsmönstret som fungerade vid Stryker-incidenten är inget nytt: angripare komprometterar ett konto som ger dem åtkomst till privilegierade system, rör sig därifrån vidare till resten av infrastrukturen och åstadkommer den skada de har flest behörigheter för. Det fungerar så tillförlitligt eftersom det i de flesta företag inte finns någon strukturell separation mellan vanliga arbetsmiljöer och de administrativa åtkomster som faktiskt skulle räcka för att ta över hela infrastrukturen.
Managed Red Tenant bryter detta mönster genom att flytta administrativa identiteter och tillhörande slutenheter till en helt separerad Microsoft-tenant, med egna Entra ID-konton, egna härdade enheter och ingen nätverksförbindelse till produktionsmiljön som en angripare skulle kunna utnyttja via lateral movement. Den som från en komprometterad standardarbetsplats försöker ta sig fram till de kritiska systemen möter här en gräns som inte fanns tidigare.
Till Managed Red Tenant
Managed Dark Tenant: den förberedda miljön för det fall som inte ska inträffa, men kan
Efter en storskalig ransomware-attack faller de problem ett företag måste hantera in i två kategorier: de tekniska, som går att lösa om än inte snabbt, och de organisatoriska, där ingen i förväg har fastställt vem som gör vad i skarpt läge, i vilken ordning beslut fattas och på vilken grund man överhuvudtaget kan kommunicera när den egna infrastrukturen inte längre är tillförlitlig. Coveware mäter den genomsnittliga driftstopptiden efter en ransomware-attack till 24 dagar, och erfarenheten från verkliga incidenter visar att tiden inte främst går förlorad på grund av avsaknad av tekniska medel, utan för att processer som aldrig behövs i normal drift måste uppfinnas för första gången under extremt tryck.
Managed Dark Tenant är en förprovisionerad, fullständigt isolerad Microsoft-miljö som i skarpt läge aktiveras via en 24/7-hotline och ger kristeamet driftklar kommunikation, Windows 365-arbetsplatser och en AD-recovery-pipeline inom några timmar, allt baserat på Infrastructure as Code, allt definierat och testat innan det behövs. Arkitekturprincipen bakom kallas Minimum Viable Company: kommunikation först, sedan kritiska dokument, sedan kärnapplikationer, i en ordning som fastställts i förväg och regelbundet provats i fire drills.
Till Managed Dark TenantVi stöttar vid den tekniska implementeringen
| Risk Measures | GK Services | NIS2 | CSOC | APT Response | Preventive Services | Managed Red Tenant | Managed Dark Tenant | Data Security | Workplace / Azure |
|---|---|---|---|---|---|---|---|---|
| Risk Analysis and Information System Security | 21.2 a) | |||||||
| Incident Handling | 21.2 b) | NEU | NEU | |||||
| Business Continuity | 21.2 c) | NEU | ||||||
| Supply Chain Security | 21.2 d) | NEU | ||||||
| Security in Network and Information Systems | 21.2 e) | |||||||
| Effectiveness of Cybersecurity Risk Management Measures | 21.2 f) | NEU | NEU | |||||
| Basic Computer Hygiene Practices and Cybersecurity Training | 21.2 g) | |||||||
| Cryptography | 21.2 h) | |||||||
| Human Resources Security, Access Control Policies and Asset Management | 21.2 i) | NEU | ||||||
| Multifactor Authentication or Secured Communication | 21.2 j) | NEU |
Två tjänster, ett svar på NIS2 artikel 21
Managed Red Tenant
Privilegierade identiteter och slutenheter i en helt separerad Microsoft-tenant utan nätverksförbindelse till produktionsmiljön. Ingen lateral movement, inget komprometterat standardkonto som blir en generalnyckel.
Managed Dark Tenant
En förprovisionerad, isolerad Microsoft-miljö som i skarpt läge aktiveras via en dygnet-runt-hotline. Kommunikation, Windows 365-arbetsplatser och AD-recovery-pipeline är definierade och testade innan de behövs.
MRT & MDT tillsammans
Red Tenant minskar sannolikheten att en attack träffar hela infrastrukturen. Dark Tenant minskar driftstopptiden om den ändå gör det. NIS2 eller inte: tillsammans är de meningsfulla oberoende av regulatoriskt tryck.
Mer om ämnet
Admin och vardag på samma dator? Game Over.
Varför en tenant inte räcker för CIO:er, och varför den andra sällan tänks med. Managed Red Tenant separerar administrativt arbete ...
