Säkerhetsrekommendationer för Azure Virtual Desktop

  • 7 minuter

Azure Virtual Desktop är en hanterad tjänst för virtuellt skrivbord som innehåller många säkerhetsfunktioner för att skydda din organisation. Arkitekturen för Azure Virtual Desktop består av många komponenter som utgör tjänsten som ansluter användare till deras skrivbord och appar.

Azure Virtual Desktop har många inbyggda avancerade säkerhetsfunktioner, till exempel Reverse Connect där inga inkommande nätverksportar krävs för att vara öppna, vilket minskar risken för att fjärrskrivbord är tillgängliga var som helst. Tjänsten drar också nytta av många andra säkerhetsfunktioner i Azure, till exempel multifaktorautentisering och villkorlig åtkomst. Den här artikeln beskriver de steg du kan vidta som administratör för att skydda dina Azure Virtual Desktop-distributioner, oavsett om du tillhandahåller skrivbord och appar till användare i din organisation eller till externa användare.

Delade ansvarsområden för säkerhet

Före Azure Virtual Desktop kräver lokala virtualiseringslösningar som Fjärrskrivbordstjänster att användarna får åtkomst till roller som Gateway, Broker, Web Access och så vidare. De här rollerna måste vara helt redundanta och kunna hantera toppkapacitet. Administratörer skulle installera dessa roller som en del av Windows Server-operativsystemet och de var tvungna att vara domänanslutna med specifika portar som är tillgängliga för offentliga anslutningar. För att skydda distributionerna var administratörerna tvungna att hela tiden se till att allt i infrastrukturen underhålls och är uppdaterat.

I de flesta molntjänster finns det dock en delad uppsättning säkerhetsansvar mellan Microsoft och kunden eller partnern. För Azure Virtual Desktop är de flesta komponenter Microsoft-hanterade, men sessionsvärdar och vissa stödtjänster och komponenter är kundhanterade eller partnerhanterade. Mer information om Microsoft-hanterade komponenter i Azure Virtual Desktop finns i Azure Virtual Desktop-tjänstens arkitektur och motståndskraft.

Vissa komponenter är redan skyddade för din miljö, men du måste konfigurera andra områden själv så att de passar organisationens eller kundens säkerhetsbehov. Här är de komponenter som du ansvarar för säkerheten i din Azure Virtual Desktop-distribution:

Komponent Ansvar
Identitet Kund eller partner
Användarenheter (mobil och dator) Kund eller partner
Appsäkerhet Kund eller partner
Sessionsvärdoperativsystem Kund eller partner
Distributionskonfiguration Kund eller partner
Nätverkskontroller Kund eller partner
Virtualiseringskontrollplan Microsoft
Fysiska värdar Microsoft
Fysiskt nätverk Microsoft
Fysiska datacentra Microsoft

Säkerhetsgränser

Säkerhetsgränser separerar kod och data för säkerhetsdomäner med olika förtroendenivåer. Det finns till exempel vanligtvis en säkerhetsgräns mellan kernelläge och användarläge. De flesta Microsoft-program och -tjänster är beroende av flera säkerhetsgränser för att isolera enheter på nätverk, virtuella datorer och program på enheter. I följande tabell visas varje säkerhetsgräns för Windows och vad de gör för övergripande säkerhet.

Säkerhetsgräns Beskrivning
Nätverksgräns En obehörig nätverksslutpunkt kan inte komma åt eller manipulera kod och data på en kunds enhet.
Kernelgräns En icke-administrativ användarlägesprocess kan inte komma åt eller manipulera kernelkod och data. Administratör till kernel är inte en säkerhetsgräns.
Processgräns En process för obehörigt användarläge kan inte komma åt eller manipulera kod och data i en annan process.
AppContainer-sandbox-gräns En AppContainer-baserad sandbox-process kan inte komma åt eller manipulera kod och data utanför sandbox-miljön baserat på containerfunktionerna.
Användargräns En användare kan inte komma åt eller manipulera kod och data för en annan användare utan att ha behörighet.
Sessionsgräns En användarsession kan inte komma åt eller manipulera en annan användarsession utan att ha behörighet.
Webbläsargräns En obehörig webbplats kan inte bryta mot principen för samma ursprung, och den kan inte heller komma åt eller manipulera den interna koden och data i microsoft Edge-webbläsarens sandbox-miljö.
Gräns för virtuell dator En obehörig virtuell Hyper-V-gästdator kan inte komma åt eller manipulera kod och data för en annan virtuell gästdator. Detta inkluderar isolerade Hyper-V-containrar.
Gränsen för virtuellt säkert läge (VSM) Kod som körs utanför den betrodda VSM-processen eller enklaven kan inte komma åt eller manipulera data och kod i den betrodda processen.

Du måste också göra vissa val om säkerhetsgränser från fall till fall. Om en användare i din organisation till exempel behöver lokal administratörsbehörighet för att installera appar måste du ge dem ett personligt skrivbord i stället för en delad sessionsvärd. Vi rekommenderar inte att du ger användarna lokal administratörsbehörighet i poolscenarier med flera sessioner eftersom dessa användare kan korsa säkerhetsgränser för sessioner eller NTFS-databehörigheter, stänga av virtuella datorer med flera sessioner eller göra andra saker som kan störa tjänsten eller orsaka dataförluster.

Användare från samma organisation, till exempel kunskapsarbetare med appar som inte kräver administratörsbehörighet, är bra kandidater för sessionsvärdar med flera sessioner, till exempel Windows 11 Enterprise multi-session. Dessa sessionsvärdar minskar kostnaderna för din organisation eftersom flera användare kan dela en enskild virtuell dator, med endast omkostnader för en virtuell dator per användare. Med användarprofilhanteringsprodukter som FSLogix kan användare tilldelas valfri virtuell dator i en värdpool utan att märka några tjänstavbrott. Med den här funktionen kan du också optimera kostnaderna genom att stänga av virtuella datorer under låg belastning.

Om din situation kräver att användare från olika organisationer ansluter till distributionen rekommenderar vi att du har en separat klientorganisation för identitetstjänster som Active Directory och Microsoft Entra-ID. Vi rekommenderar också att du har en separat prenumeration för de användare som är värdar för Azure-resurser som Azure Virtual Desktop och virtuella datorer.

I många fall är användning av flera sessioner ett acceptabelt sätt att minska kostnaderna, men om vi rekommenderar det beror på förtroendenivån mellan användare med samtidig åtkomst till en delad instans med flera sessioner. Användare som tillhör samma organisation har vanligtvis en tillräcklig och överenskommen förtroenderelation. Till exempel är en avdelning eller arbetsgrupp där personer samarbetar och kan komma åt varandras personliga information en organisation med hög förtroendenivå.

Windows använder säkerhetsgränser och kontroller för att säkerställa att användarprocesser och data isoleras mellan sessioner. Windows ger dock fortfarande åtkomst till den instans som användaren arbetar med.

Distributioner med flera sessioner skulle dra nytta av en djupgående säkerhetsstrategi som lägger till fler säkerhetsgränser som hindrar användare inom och utanför organisationen från att få obehörig åtkomst till andra användares personliga information. Obehörig dataåtkomst inträffar på grund av ett fel i konfigurationsprocessen av systemadministratören, till exempel en hemlig säkerhetsrisk eller en känd sårbarhet som inte har korrigerats ännu.

Vi rekommenderar inte att du ger användare som arbetar för olika eller konkurrerande företag åtkomst till samma miljö med flera sessioner. Dessa scenarier har flera säkerhetsgränser som kan attackeras eller missbrukas, till exempel nätverk, kernel, process, användare eller sessioner. En enda säkerhetsrisk kan orsaka obehöriga data och stöld av autentiseringsuppgifter, läckage av personlig information, identitetsstöld och andra problem. Virtualiserade miljöleverantörer ansvarar för att erbjuda väl utformade system med flera starka säkerhetsgränser och extra säkerhetsfunktioner aktiverade där det är möjligt.

Tabellen sammanfattar våra rekommendationer för varje scenario.

Scenario på förtroendenivå Rekommenderad lösning
Användare från en organisation med standardprivilegier Använd ett Windows Enterprise-operativsystem med flera sessioner (OS).
Användare kräver administratörsbehörighet Använd en personlig värdpool och tilldela varje användare en egen sessionsvärd.
Användare från olika organisationer som ansluter Separera Azure-klientorganisation och Azure-prenumeration