Aanbevelingen voor beveiliging voor Azure Virtual Desktop

  • 7 minuten

Azure Virtual Desktop is een beheerde virtuele bureaubladservice die veel beveiligingsmogelijkheden bevat om uw organisatie veilig te houden. De architectuur van Azure Virtual Desktop bestaat uit veel onderdelen waaruit de service bestaat die gebruikers verbindt met hun desktops en apps.

Azure Virtual Desktop heeft veel ingebouwde geavanceerde beveiligingsfuncties, zoals Reverse Connect waar geen binnenkomende netwerkpoorten moeten worden geopend, wat het risico vermindert dat externe bureaubladen vanaf elke locatie toegankelijk zijn. De service profiteert ook van veel andere beveiligingsfuncties van Azure, zoals meervoudige verificatie en voorwaardelijke toegang. In dit artikel worden de stappen beschreven die u als beheerder kunt uitvoeren om uw Azure Virtual Desktop-implementaties veilig te houden, ongeacht of u desktops en apps levert aan gebruikers in uw organisatie of aan externe gebruikers.

Beveiliging met gedeelde verantwoordelijkheden

Voordat Azure Virtual Desktop wordt gebruikt, moeten on-premises virtualisatieoplossingen, zoals Extern bureaublad-services, gebruikers toegang verlenen tot rollen zoals Gateway, Broker, Web Access, enzovoort. Deze rollen moesten volledig redundant zijn en de piekcapaciteit kunnen verwerken. Beheerders zouden deze rollen installeren als onderdeel van het Windows Server-besturingssysteem en ze moesten lid zijn van een domein met specifieke poorten die toegankelijk zijn voor openbare verbindingen. Om implementaties veilig te houden, moesten beheerders er voortdurend voor zorgen dat alles in de infrastructuur werd onderhouden en up-to-date was.

In de meeste cloudservices is er echter een gedeelde set beveiligingsverantwoordelijkheden tussen Microsoft en de klant of partner. Voor Azure Virtual Desktop worden de meeste onderdelen door Microsoft beheerd, maar sessiehosts en sommige ondersteunende services en onderdelen worden door de klant beheerd of door een partner beheerd. Zie de azure Virtual Desktop-servicearchitectuur en -tolerantie voor meer informatie over de door Microsoft beheerde onderdelen van Azure Virtual Desktop.

Hoewel sommige onderdelen al zijn beveiligd voor uw omgeving, moet u andere gebieden zelf configureren om te voldoen aan de beveiligingsbehoeften van uw organisatie of klant. Hier volgen de onderdelen waarvan u verantwoordelijk bent voor de beveiliging in uw Azure Virtual Desktop-implementatie:

Onderdeel Verantwoordelijkheid
Identiteit Klant of partner
Gebruikersapparaten (mobiel en pc) Klant of partner
App-beveiliging Klant of partner
Sessiehostbesturingssysteem Klant of partner
Implementatieconfiguratie Klant of partner
Netwerkbediening Klant of partner
Virtualisatiebesturingsvlak Microsoft
Fysieke hosts Microsoft
Fysiek netwerk Microsoft
Fysiek datacenter Microsoft

Beveiligingsgrenzen

Beveiligingsgrenzen scheiden de code en gegevens van beveiligingsdomeinen met verschillende vertrouwensniveaus. Er is bijvoorbeeld meestal een beveiligingsgrens tussen kernelmodus en gebruikersmodus. De meeste Microsoft-software en -services zijn afhankelijk van meerdere beveiligingsgrenzen om apparaten te isoleren op netwerken, virtuele machines (VM's) en toepassingen op apparaten. De volgende tabel bevat elke beveiligingsgrens voor Windows en wat ze doen voor de algehele beveiliging.

Beveiligingsgrens Beschrijving
Netwerkgrens Een niet-geautoriseerd netwerkeindpunt kan geen toegang krijgen tot of knoeien met code en gegevens op het apparaat van een klant.
Kernelgrens Een niet-beheerdersmodusproces heeft geen toegang tot kernelcode en -gegevens of kan er niet mee worden geknoeid. Administrator-to-kernel is geen beveiligingsgrens.
Procesgrens Een niet-geautoriseerd gebruikersmodusproces heeft geen toegang tot of manipulatie met de code en gegevens van een ander proces.
AppContainer-sandboxgrens Een sandbox-proces op basis van AppContainer heeft geen toegang tot code en gegevens buiten de sandbox of kan er niet mee worden geknoeid op basis van de containermogelijkheden.
Gebruikersgrens Een gebruiker kan geen toegang krijgen tot of knoeien met de code en gegevens van een andere gebruiker zonder toestemming.
Sessiegrens Een gebruikerssessie kan geen toegang krijgen tot of knoeien met een andere gebruikerssessie zonder geautoriseerd te zijn.
Webbrowsergrens Een niet-geautoriseerde website kan niet in strijd zijn met hetzelfde origin-beleid en kan ook geen toegang krijgen tot of knoeien met de systeemeigen code en gegevens van de sandbox van de Microsoft Edge-webbrowser.
Grens van virtuele machine Een niet-geautoriseerde virtuele Hyper-V-gastmachine heeft geen toegang tot of manipulatie met de code en gegevens van een andere virtuele gastmachine; dit omvat geïsoleerde Hyper-V-containers.
VsM-grens (Virtual Secure Mode) Code die buiten het vertrouwde VSM-proces of enclave wordt uitgevoerd, heeft geen toegang tot of manipulatie met gegevens en code binnen het vertrouwde proces.

U moet ook bepaalde keuzes maken over beveiligingsgrenzen per geval. Als een gebruiker in uw organisatie bijvoorbeeld lokale beheerdersbevoegdheden nodig heeft om apps te installeren, moet u hen een persoonlijk bureaublad geven in plaats van een gedeelde sessiehost. Het is niet raadzaam om gebruikers lokale beheerdersbevoegdheden te geven in poolscenario's met meerdere sessies, omdat deze gebruikers beveiligingsgrenzen voor sessies of NTFS-gegevensmachtigingen kunnen overschrijden, VM's met meerdere sessies kunnen afsluiten of andere dingen kunnen doen die de service kunnen onderbreken of gegevensverlies kunnen veroorzaken.

Gebruikers van dezelfde organisatie, zoals kenniswerkers met apps waarvoor geen beheerdersbevoegdheden zijn vereist, zijn goede kandidaten voor sessiehosts met meerdere sessies, zoals Windows 11 Enterprise-multisessie. Deze sessiehosts verlagen de kosten voor uw organisatie omdat meerdere gebruikers één VIRTUELE machine kunnen delen, met alleen de overheadkosten van een VIRTUELE machine per gebruiker. Met beheerproducten voor gebruikersprofielen, zoals FSLogix, kunnen gebruikers elke virtuele machine in een hostgroep toewijzen zonder dat er serviceonderbrekingen zijn. Met deze functie kunt u ook kosten optimaliseren door zaken te doen zoals het afsluiten van VM's tijdens daluren.

Als uw situatie vereist dat gebruikers van verschillende organisaties verbinding maken met uw implementatie, raden we u aan een afzonderlijke tenant te hebben voor identiteitsservices zoals Active Directory en Microsoft Entra-id. We raden u ook aan een afzonderlijk abonnement te hebben voor die gebruikers voor het hosten van Azure-resources, zoals Azure Virtual Desktop en VM's.

In veel gevallen is het gebruik van meerdere sessies een acceptabele manier om de kosten te verlagen, maar of het aan te raden is afhankelijk van het vertrouwensniveau tussen gebruikers met gelijktijdige toegang tot een gedeeld exemplaar van meerdere sessies. Normaal gesproken hebben gebruikers die deel uitmaken van dezelfde organisatie een voldoende en overeengekomen vertrouwensrelatie. Een afdeling of werkgroep waar mensen samenwerken en toegang hebben tot elkaars persoonlijke gegevens is bijvoorbeeld een organisatie met een hoog vertrouwensniveau.

Windows maakt gebruik van beveiligingsgrenzen en besturingselementen om ervoor te zorgen dat gebruikersprocessen en gegevens worden geïsoleerd tussen sessies. Windows biedt echter nog steeds toegang tot het exemplaar waaraan de gebruiker werkt.

Implementaties met meerdere sessies profiteren van een uitgebreide beveiligingsstrategie die meer beveiligingsgrenzen toevoegt die voorkomen dat gebruikers binnen en buiten de organisatie onbevoegde toegang krijgen tot persoonlijke gegevens van andere gebruikers. Onbevoegde gegevenstoegang treedt op vanwege een fout in het configuratieproces door de systeembeheerder, zoals een niet-openbaar beveiligingsprobleem of een bekend beveiligingsprobleem dat nog niet is gepatcht.

Het wordt afgeraden gebruikers toe te kennen die voor verschillende of concurrerende bedrijven toegang hebben tot dezelfde omgeving met meerdere sessies. Deze scenario's hebben verschillende beveiligingsgrenzen die kunnen worden aangevallen of misbruikt, zoals netwerk, kernel, proces, gebruiker of sessies. Eén beveiligingsprobleem kan leiden tot onbevoegde gegevens- en referentiediefstal, lekken van persoonlijke gegevens, identiteitsdiefstal en andere problemen. Gevirtualiseerde omgevingsproviders zijn verantwoordelijk voor het aanbieden van goed ontworpen systemen met meerdere sterke beveiligingsgrenzen en waar mogelijk extra veiligheidsfuncties.

De tabel bevat een overzicht van onze aanbevelingen voor elk scenario.

Scenario op vertrouwensniveau Aanbevolen oplossing
Gebruikers van één organisatie met standaardbevoegdheden Een Windows Enterprise-besturingssysteem met meerdere sessies gebruiken.
Gebruikers hebben beheerdersbevoegdheden nodig Gebruik een persoonlijke hostgroep en wijs elke gebruiker een eigen sessiehost toe.
Gebruikers van verschillende organisaties die verbinding maken Afzonderlijk Azure-tenant en Azure-abonnement