Grondbeginselen van Azure-resourcebeheer

Het is belangrijk om inzicht te krijgen in de structuur en termen die specifiek zijn voor Azure-resources. In de volgende afbeelding ziet u een voorbeeld van de vier bereikniveaus die worden geleverd door Azure:

Terminologie

Hier volgen enkele van de termen waarmee u bekend moet zijn:

Resource: een beheerbaar item dat beschikbaar is via Azure. Virtuele machines, opslagaccounts, web-apps, databases en virtuele netwerken zijn voorbeelden van resources.

Resourcegroep- een container met gerelateerde resources voor een Azure-oplossing, zoals een verzameling virtuele machines, gekoppelde VNets en load balancers die beheer van specifieke teams vereisen. De resourcegroep bevat die resources die u als groep wilt beheren. U bepaalt welke resources deel uitmaken van een resourcegroep op basis van wat voor uw organisatie het meest zinvol is. Resourcegroepen kunnen ook worden gebruikt om te helpen bij het levenscyclusbeheer door alle resources met dezelfde levensduur tegelijk te verwijderen. Deze aanpak biedt ook beveiligingsvoordelen door geen fragmenten te laten die mogelijk worden misbruikt.

Abonnement - vanuit het perspectief van een organisatiehiërarchie is een abonnement een facturerings- en beheercontainer van resources en resourcegroepen. Een Azure-abonnement heeft een vertrouwensrelatie met een Microsoft Entra ID Een abonnement vertrouwt Microsoft Entra ID om gebruikers, services en apparaten te verifiëren.

Notitie

Een abonnement kan slechts één Microsoft Entra-tenant vertrouwen. Elke tenant kan echter meerdere abonnementen en abonnementen vertrouwen, kan worden verplaatst tussen tenants.

Beheergroep - Azure-beheergroepen bieden een hiërarchische methode voor het toepassen van beleidsregels en naleving op verschillende bereiken boven abonnementen. Dit kan zich in de hoofdbeheergroep van de tenant bevinden (hoogste bereik) of op lagere niveaus in de hiërarchie. U ordent abonnementen in containers, zogenaamde 'beheergroepen', en past uw governancevoorwaarden hierop toe. Alle abonnementen in een beheergroep nemen automatisch de voorwaarden over die op de beheergroep zijn toegepast. Opmerking: beleidsdefinities kunnen worden toegepast op een beheergroep of abonnement.

Resourceprovider - een service die zorgt voor Azure-resources. Een veelvoorkomende resourceprovider is bijvoorbeeld Microsoft. Compute, die de virtuele machine levert. Microsoft. Opslag is een andere veelvoorkomende resourceprovider.

Resource Manager-sjabloon: een JSON-bestand (JavaScript Object Notation) waarmee één of meer resources worden gedefinieerd voor implementatie in een resourcegroep, abonnement, beheergroep of tenant. De sjabloon kan worden gebruikt om de resources consistent en herhaaldelijk te implementeren. Zie Overzicht van sjabloonimplementatie. Daarnaast kan de Bicep-taal worden gebruikt in plaats van JSON.

Azure Resource Management Model

Elk Azure-abonnement is gekoppeld aan besturingselementen die worden gebruikt door Azure Resource Manager. Resource Manager is de implementatie- en beheerservice voor Azure, het heeft een vertrouwensrelatie met Microsoft Entra-id voor identiteitsbeheer voor organisaties en het Microsoft-account (MSA) voor personen. Resource Manager biedt een beheerlaag waarmee u resources in uw Azure-abonnement kunt maken, bijwerken en verwijderen. U kunt beheerfuncties gebruiken, zoals toegangscontrole, vergrendelingen en tags, om uw resources te beveiligen en te organiseren na de implementatie.

Notitie

Vóór ARM was er een ander implementatiemodel met de naam Azure Service Manager (ASM) of 'klassiek'. Zie voor meer informatie Azure Resource Manager versus klassieke implementatie. Het beheren van omgevingen met het ASM-model valt buiten het bereik van deze inhoud.

Azure Resource Manager is de front-endservice die als host fungeert voor de REST API's die worden gebruikt door PowerShell, de Azure Portal of andere clients voor het beheren van resources. Wanneer een client een aanvraag indient voor het beheren van een specifieke resource, Resource Manager de aanvraag naar de resourceprovider proxyt om de aanvraag te voltooien. Als een client bijvoorbeeld een aanvraag indient om een virtuele-machineresource te beheren, Resource Manager de aanvraag naar Microsoft proxy's. Rekenresourceprovider. Resource Manager vereist dat de client een id opgeeft voor zowel het abonnement als de resourcegroep om de resource van de virtuele machine te beheren.

Voordat een resourcebeheeraanvraag kan worden uitgevoerd door Resource Manager, wordt een set besturingselementen gecontroleerd.

• Geldige gebruikerscontrole : de gebruiker die de resource aanvraagt, moet een account hebben in de Microsoft Entra-tenant die is gekoppeld aan het abonnement van de beheerde resource.

• Controle van gebruikersmachtigingen: machtigingen worden toegewezen aan gebruikers met behulp van op rollen gebaseerd toegangsbeheer (RBAC). Een RBAC-rol geeft een set machtigingen op die een gebruiker kan overnemen van een specifieke resource. Het gebruik van Azure RBAC helpt u bij het beheren van wie er toegang heeft tot Azure-resources, wat ze kunnen doen met die resources en tot welke gebieden ze toegang hebben.

• Controle van Azure-beleid - Azure-beleid geeft de bewerkingen op die zijn toegestaan of expliciet zijn geweigerd voor een specifieke resource. Een beleid kan bijvoorbeeld opgeven dat gebruikers alleen zijn toegestaan (of niet zijn toegestaan) om een specifiek type virtuele machine te implementeren.

In het volgende diagram ziet u een overzicht van het resourcemodel dat we zojuist hebben beschreven.

Azure Lighthouse - Azure Lighthouse maakt resourcebeheer mogelijk voor tenants. Organisaties kunnen rollen op abonnements- of resourcegroepniveau delegeren aan identiteiten in een andere tenant.

Abonnementen die gedelegeerd resourcebeheer met Azure Lighthouse mogelijk maken, hebben kenmerken die aangeven welke tenant-id's abonnementen of resourcegroepen kunnen beheren, en toewijzing tussen de ingebouwde RBAC-rol in de resourcetenant aan identiteiten in de tenant van de serviceprovider. Tijdens runtime gebruikt Azure Resource Manager deze kenmerken om tokens te autoriseren die afkomstig zijn van de tenant van de serviceprovider.

Het is de moeite waard om te vermelden dat Azure Lighthouse zelf is gemodelleerd als een Azure-resourceprovider, wat betekent dat aspecten van de delegatie in een tenant kunnen worden gericht via Azure-beleid.

Microsoft 365 Lighthouse - Microsoft 365 Lighthouse is een beheerportal waarmee Managed Service Providers (MSP's) apparaten, gegevens en gebruikers op schaal kunnen beveiligen en beheren voor kleine en middelgrote zakelijke klanten (SMB) die gebruikmaken van Microsoft 365 Business Premium, Microsoft 365 E3 of Windows 365 Business.

Azure-resourcebeheer met Microsoft Entra-id

Nu u een beter inzicht hebt in het resourcebeheermodel in Azure, gaan we kort enkele mogelijkheden van Microsoft Entra ID bekijken die identiteits- en toegangsbeheer voor Azure-resources kunnen bieden.

Billing

Facturering is belangrijk voor resourcebeheer omdat sommige factureringsrollen communiceren met of resources kunnen beheren. Facturering werkt anders, afhankelijk van het type overeenkomst dat u hebt met Microsoft.

Enterprise-overeenkomsten

Klanten van Azure Enterprise Agreement (Azure EA) worden bij de uitvoering van hun commerciële contract met Microsoft onboarding naar Azure EA Portal uitgevoerd. Bij het onboarden wordt een identiteit gekoppeld aan een factureringsrol 'hoofdbeheerder'. De portal biedt een hiërarchie van beheerfuncties:

• Afdelingen helpen bij het segmenteren van kosten in logische groeperingen en het instellen van een budget of quotum op afdelingsniveau.

• Accounts worden gebruikt om afdelingen verder te segmenteren. U kunt accounts gebruiken om abonnementen te beheren en rapporten te bekijken. De EA-portal kan Microsoft-accounts (MSA) of Microsoft Entra-accounts autoriseren (geïdentificeerd in de portal als 'Werk- of schoolaccounts'). Identiteiten met de rol 'Accounteigenaar' in de EA-portal kunnen Azure-abonnementen maken.

Enterprise-facturering en Microsoft Entra-tenants

Wanneer een accounteigenaar een Azure-abonnement binnen een Enterprise Agreement maakt, wordt het identiteits- en toegangsbeheer van het abonnement als volgt geconfigureerd:

• Het Azure-abonnement is gekoppeld aan dezelfde Microsoft Entra-tenant van de accounteigenaar.

• De accounteigenaar die het abonnement heeft gemaakt, krijgt de rollen Servicebeheerder en Accountbeheerder toegewezen. (Azure EA Portal wijst Azure Service Manager (ASM) of klassieke rollen toe om abonnementen te beheren. Zie Azure Resource Manager versus klassieke implementatie voor meer informatie.)

Een Enterprise Agreement kan worden geconfigureerd om meerdere tenants te ondersteunen door het verificatietype 'Werk- of schoolaccount kruistenant' in de Azure EA-portal in te stellen. Op basis van het bovenstaande kunnen organisaties meerdere accounts instellen voor elke tenant en meerdere abonnementen voor elk account, zoals wordt weergegeven in het onderstaande diagram.

Het is belangrijk te weten dat de standaardconfiguratie die hierboven wordt beschreven, de bevoegdheden van de Eigenaar van het Azure EA-account verleent voor het beheren van de resources in abonnementen die ze hebben gemaakt. Voor abonnementen met productieworkloads kunt u het facturerings- en resourcebeheer ontkoppelen door de servicebeheerder van het abonnement direct na het maken te wijzigen.

Als u de accounteigenaar verder wilt loskoppelen en wilt voorkomen dat de accounteigenaar weer toegang krijgt tot het abonnement, kan de tenant van het abonnement worden gewijzigd nadat deze is gemaakt. Als de accounteigenaar geen gebruikersobject heeft in de Microsoft Entra-tenant waarnaar het abonnement wordt verplaatst, kan deze de rol van service-eigenaar niet meer terugkrijgen.

Ga voor meer informatie naar Azure-rollen, Microsoft Entra-rollen en klassieke abonnementsbeheerdersrollen.

Microsoft-klantovereenkomst

Klanten die zijn ingeschreven met een Microsoft-klantovereenkomst (MCA) hebben een ander systeem voor factureringsbeheer met hun eigen rollen.

Uw factureringsaccount voor de Microsoft-klantovereenkomst bevat een of meer factureringsprofielen waarmee u uw facturen en betalingsmethoden kunt beheren. Elk factureringsprofiel bevat een of meer factuursecties waarmee u kosten op de factuur van het factureringsprofiel kunt organiseren.

In een Microsoft-klantovereenkomst komen factureringsrollen uit één Microsoft Entra-tenant. Als u abonnementen voor meerdere tenants wilt inrichten, moeten de abonnementen in eerste instantie worden gemaakt in dezelfde Microsoft Entra-tenant als de MCA en vervolgens worden gewijzigd. In het onderstaande diagram zijn de abonnementen voor de preproductieomgeving bedrijfs-IT verplaatst naar de ContosoSandbox-tenant na het maken.

RBAC en roltoewijzingen in Azure

In de sectie Microsoft Entra Fundamentals hebt u geleerd dat Azure RBAC het autorisatiesysteem is dat gedetailleerd toegangsbeheer biedt voor Azure-resources en veel ingebouwde rollen bevat. U kunt aangepaste rollen maken en rollen toewijzen op verschillende bereiken. Machtigingen worden afgedwongen door RBAC-rollen toe te wijzen aan objecten die toegang tot Azure-resources aanvragen.

Microsoft Entra-rollen werken op concepten als op rollen gebaseerd toegangsbeheer van Azure. Het verschil tussen deze twee op rollen gebaseerde toegangsbeheersystemen is dat Azure RBAC gebruikmaakt van Azure Resource Management voor het beheren van de toegang tot Azure-resources, zoals virtuele machines of opslag, en microsoft Entra-rollen beheren de toegang tot Microsoft Entra-id, toepassingen en Microsoft-services zoals Office 365.

Zowel Microsoft Entra-rollen als Azure RBAC-rollen kunnen worden geïntegreerd met Microsoft Entra Privileged Identity Management om Just-In-Time-activeringsbeleid in te schakelen, zoals goedkeuringswerkstroom en MFA.

ABAC en roltoewijzingen in Azure

Op kenmerken gebaseerd toegangsbeheer (ABAC) is een autorisatiesysteem waarmee toegang wordt gedefinieerd op basis van kenmerken die zijn gekoppeld aan beveiligingsprincipals, resources en omgevingen. Met ABAC kunt u een beveiligingsprincipal toegang verlenen tot een resource op basis van kenmerken. Azure ABAC verwijst naar de implementatie van ABAC voor Azure.

Azure ABAC bouwt voort op Azure RBAC door roltoewijzingsvoorwaarden toe te voegen op basis van kenmerken in de context van specifieke acties. Een voorwaarde voor roltoewijzing is een extra controle die u optioneel kunt toevoegen aan uw roltoewijzing om geavanceerder toegangscontrole te bieden. Met een voorwaarde worden machtigingen gefilterd die zijn verleend als onderdeel van de roldefinitie en roltoewijzing. U kunt bijvoorbeeld een voorwaarde toevoegen waarvoor een object een specifieke tag moet hebben om het object te lezen. U kunt de toegang tot specifieke resources niet expliciet weigeren met behulp van voorwaarden.

Voorwaardelijke toegang

Voorwaardelijke toegang van Microsoft Entra kan worden gebruikt om de toegang tot Azure-beheereindpunten te beheren. Beleidsregels voor voorwaardelijke toegang kunnen worden toegepast op de Cloud-app windows Azure Service Management API om de Eindpunten voor Azure-resourcebeheer te beveiligen, zoals:

• Azure Resource Manager Provider (services)

• Azure Resource Manager API's

• Azure PowerShell

• Azure-CLI

• Azure Portal

Een beheerder kan bijvoorbeeld een beleid voor voorwaardelijke toegang configureren, waardoor een gebruiker zich alleen vanaf goedgekeurde locaties kan aanmelden bij Azure Portal en ook meervoudige verificatie (MFA) of een hybride Apparaat dat lid is van een Microsoft Entra-domein vereist.

Door Azure beheerde identiteiten

Een veelvoorkomende uitdaging bij het bouwen van cloud-apps is het beheren van de referenties in uw code voor verificatie bij cloudservices. Het is belangrijk dat de referenties veilig worden bewaard. In het ideale geval worden de referenties nooit weergegeven op werkstations van ontwikkelaars en niet ingecheckt in broncodebeheer. Beheerde identiteiten voor Azure-resources bieden Azure-services met een automatisch beheerde identiteit in Microsoft Entra-id. U kunt de identiteit gebruiken om te verifiëren bij elke service die Ondersteuning biedt voor Microsoft Entra-verificatie zonder referenties in uw code.

Er zijn twee typen beheerde identiteit:

• Een door het systeem toegewezen beheerde identiteit wordt rechtstreeks ingeschakeld op een Azure-resource. Wanneer de resource is ingeschakeld, maakt Azure een identiteit voor de resource in de vertrouwde Microsoft Entra-tenant van het gekoppelde abonnement. Nadat de identiteit is gemaakt, worden de referenties op het exemplaar ingericht. De levenscyclus van een door het systeem toegewezen identiteit is rechtstreeks gekoppeld aan het Azure-service-exemplaar waarop de identiteit is ingeschakeld. Als de resource wordt verwijderd, worden de referenties en de identiteit in Microsoft Entra ID automatisch opgeschoond.

• Een door de gebruiker toegewezen beheerde identiteit wordt gemaakt als een zelfstandige Azure-resource. Azure maakt een identiteit in de Microsoft Entra-tenant die wordt vertrouwd door het abonnement waaraan de resource is gekoppeld. Nadat de identiteit is gemaakt, kan deze worden toegewezen aan een of meer Azure-service-exemplaren. De levenscyclus van een door de gebruiker toegewezen identiteit wordt afzonderlijk beheerd van de levenscyclus van de Azure-exemplaren waaraan de identiteit is toegewezen.

Interne beheerde identiteiten zijn service-principals van een speciaal type, die alleen kunnen worden gebruikt met Azure-resources. Wanneer de beheerde identiteit wordt verwijderd, wordt de bijbehorende service-principal automatisch verwijderd. Noe dat autorisatie van Graph API machtigingen alleen kan worden uitgevoerd door PowerShell, zodat niet alle functies van beheerde identiteit toegankelijk zijn via de gebruikersinterface van de portal.

Microsoft Entra Domain Services.

Microsoft Entra Domain Services biedt een beheerd domein voor het vergemakkelijken van verificatie voor Azure-workloads met behulp van verouderde protocollen. Ondersteunde servers worden verplaatst van een on-premises AD DS-forest en gekoppeld aan een door Microsoft Entra Domain Services beheerd domein en blijven verouderde protocollen gebruiken voor verificatie (bijvoorbeeld Kerberos-verificatie).

Azure AD B2C-mappen en Azure

Een Azure AD B2C-tenant is gekoppeld aan een Azure-abonnement voor facturerings- en communicatiedoeleinden. Azure AD B2C-tenants hebben een zelfstandige rolstructuur in de directory, die onafhankelijk is van de azure RBAC-rollen van het Azure-abonnement.

Wanneer de Azure AD B2C-tenant in eerste instantie is ingericht, moet de gebruiker die de B2C-tenant maakt, inzender- of eigenaarmachtigingen hebben in het abonnement. Bij het maken wordt die gebruiker de eerste globale beheerder van de Azure AD B2C-tenant en kunnen ze later andere accounts maken en toewijzen aan directoryrollen.

Het is belangrijk te weten dat de eigenaren en inzenders van het gekoppelde Microsoft Entra-abonnement de koppeling tussen het abonnement en de directory kunnen verwijderen, wat van invloed is op de lopende facturering van het Azure AD B2C-gebruik.

Identiteitsoverwegingen voor IaaS-oplossingen in Azure

In dit scenario worden vereisten voor identiteitsisolatie beschreven die organisaties hebben voor IaaS-workloads (Infrastructure-as-a-Service).

Er zijn drie belangrijke opties met betrekking tot isolatiebeheer van IaaS-workloads:

• Virtuele machines die zijn toegevoegd aan zelfstandige Active Directory Domain Services (AD DS)

• Aan Microsoft Entra Domain Services gekoppelde virtuele machines

• Aanmelden bij virtuele machines in Azure met behulp van Microsoft Entra-verificatie

Een belangrijk concept bij de eerste twee opties is dat er twee identiteitsgebieden bij deze scenario's betrokken zijn.

• Wanneer u zich aanmeldt bij een Azure Windows Server-VM via extern bureaubladprotocol (RDP), meldt u zich doorgaans aan bij de server met behulp van uw domeinreferenties, waarmee een Kerberos-verificatie wordt uitgevoerd op basis van een on-premises AD DS-domeincontroller of Microsoft Entra Domain Services. Als de server niet lid is van een domein, kan een lokaal account ook worden gebruikt om u aan te melden bij de virtuele machines.

• Wanneer u zich aanmeldt bij Azure Portal om een virtuele machine te maken of te beheren, moet u verifiëren met Microsoft Entra-id (mogelijk met dezelfde referenties als u de juiste accounts hebt gesynchroniseerd). Dit kan leiden tot verificatie op uw domeincontrollers als u Active Directory Federation Services (AD FS) of PassThrough-verificatie gebruikt.

Virtuele machines die zijn gekoppeld aan zelfstandige Active Directory Domain Services

AD DS is de op Windows Server gebaseerde adreslijstservice die organisaties grotendeels hebben gebruikt voor on-premises identiteitsservices. AD DS kan worden geïmplementeerd wanneer er een vereiste bestaat om IaaS-workloads te implementeren in Azure waarvoor identiteitsisolatie van AD DS-beheerders en -gebruikers in een ander forest is vereist.

In dit scenario moeten de volgende overwegingen worden gemaakt:

AD DS-domeincontrollers: minimaal twee AD DS-domeincontrollers moeten worden geïmplementeerd om ervoor te zorgen dat verificatieservices maximaal beschikbaar en presterend zijn. Voor meer informatie, zie AD DS Design and Planning.

AD DS-ontwerp en -planning - er moet een nieuw AD DS-forest worden gemaakt met de volgende services die correct zijn geconfigureerd:

• AD DS Domain Name Services (DNS) - AD DS DNS moet worden geconfigureerd voor de relevante zones binnen AD DS om ervoor te zorgen dat naamomzetting correct werkt voor servers en toepassingen.

• AD DS-sites en -services - deze services moeten worden geconfigureerd om ervoor te zorgen dat toepassingen een lage latentie en krachtige toegang hebben tot domeincontrollers. De relevante virtuele netwerken, subnetten en datacenterlocaties waar servers zich bevinden, moeten worden geconfigureerd in sites en services.

• AD DS FSMOs - De FSMO-rollen (Flexible Single Master Operation) die vereist zijn, moeten worden gecontroleerd en toegewezen aan de juiste AD DS-domeincontrollers.

• AD DS-domeindeelname - alle servers (met uitzondering van 'jumpboxes') waarvoor AD DS is vereist voor verificatie, configuratie en beheer, moeten worden gekoppeld aan het geïsoleerde forest.

• AD DS groepsbeleid (GPO) - AD DS GPO's moeten worden geconfigureerd om ervoor te zorgen dat de configuratie voldoet aan de beveiligingsvereisten en dat de configuratie is gestandaardiseerd op de forest- en domeincomputers.

• AD DS-organisatie-eenheden (OE) - AD DS OE's moeten worden gedefinieerd om ervoor te zorgen dat AD DS-resources worden gegroepeerd in logische beheer- en configuratiesilo's voor beheer en toepassing van configuratie.

• Op rollen gebaseerd toegangsbeheer - RBAC moet worden gedefinieerd voor beheer en toegang tot resources die zijn gekoppeld aan dit forest. Dit zijn onder andere de nieuwe mogelijkheden:

  • AD DS-groepen - groepen moeten worden gemaakt om de juiste machtigingen toe te passen voor gebruikers op AD DS-resources.

  • Beheeraccounts - Zoals vermeld aan het begin van deze sectie zijn er twee beheeraccounts vereist om deze oplossing te beheren.

    • Een AD DS-beheeraccount met de minst bevoegde toegang die is vereist voor het uitvoeren van het beheer dat is vereist in AD DS en servers die lid zijn van een domein.

    • Een Microsoft Entra-beheeraccount voor Toegang tot Azure Portal om virtuele machines, VNets, netwerkbeveiligingsgroepen en andere vereiste Azure-resources te verbinden, beheren en configureren.

  • AD DS-gebruikersaccounts - Relevante gebruikersaccounts moeten worden ingericht en toegevoegd aan de juiste groepen om gebruikers toegang te geven tot toepassingen die door deze oplossing worden gehost.

Virtuele netwerken (VNets) - Configuratierichtlijnen

• IP-adres van AD DS-domeincontroller - de domeincontrollers mogen niet worden geconfigureerd met statische IP-adressen binnen het besturingssysteem. De IP-adressen moeten worden gereserveerd op het Azure-VNet om ervoor te zorgen dat ze altijd hetzelfde blijven en DC moeten worden geconfigureerd voor het gebruik van DHCP.

• VNet DNS-server - DNS-servers moeten worden geconfigureerd op VNets die deel uitmaken van deze geïsoleerde oplossing om naar de domeincontrollers te verwijzen. Dit is vereist om ervoor te zorgen dat toepassingen en servers de vereiste AD DS-services of andere services die zijn gekoppeld aan het AD DS-forest, kunnen omzetten.

• Netwerkbeveiligingsgroepen (NSG's): de domeincontrollers moeten zich op hun eigen VNet of subnet bevinden met NSG's die zijn gedefinieerd om alleen toegang te verlenen tot domeincontrollers vanaf de vereiste servers (bijvoorbeeld computers die lid zijn van een domein of jumpboxes). Jumpboxes moeten worden toegevoegd aan een toepassingsbeveiligingsgroep (ASG) om het maken en beheren van NSG's te vereenvoudigen.

Uitdagingen: De onderstaande lijst markeert belangrijke uitdagingen met het gebruik van deze optie voor identiteitsisolatie:

• Een extra AD DS-forest voor het beheren, beheren en bewaken van het resultaat dat het IT-team meer werk kan uitvoeren.

• Mogelijk is verdere infrastructuur vereist voor het beheer van patching en software-implementaties. Organisaties moeten overwegen om Azure Update Management, groepsbeleid (GPO) of sccm (System Center Configuration Manager) te implementeren om deze servers te beheren.

• Aanvullende referenties voor gebruikers om te onthouden en te gebruiken voor toegang tot resources.

Belangrijk

Voor dit geïsoleerde model wordt ervan uitgegaan dat er geen verbinding is met of van de domeincontrollers van het bedrijfsnetwerk van de klant en dat er geen vertrouwensrelaties zijn geconfigureerd met andere forests. Er moet een jumpbox- of beheerserver worden gemaakt om een punt toe te staan waaruit de AD DS-domeincontrollers kunnen worden beheerd en beheerd.

Aan Microsoft Entra Domain Services gekoppelde virtuele machines

Wanneer er een vereiste bestaat om IaaS-workloads te implementeren in Azure waarvoor identiteitsisolatie van AD DS-beheerders en gebruikers in een ander forest is vereist, kan een door Microsoft Entra Domain Services beheerd domein worden geïmplementeerd. Microsoft Entra Domain Services is een service die een beheerd domein biedt om verificatie te vergemakkelijken voor Azure-workloads met behulp van verouderde protocollen. Dit biedt een geïsoleerd domein zonder de technische complexiteit van het bouwen en beheren van uw eigen AD DS. De volgende overwegingen moeten worden gemaakt.

Door Microsoft Entra Domain Services beheerd domein : er kan slechts één door Microsoft Entra Domain Services beheerd domein worden geïmplementeerd per Microsoft Entra-tenant en dit is gebonden aan één VNet. Het is raadzaam dat dit VNet de 'hub' vormt voor Microsoft Entra Domain Services-verificatie. Vanuit deze hub kunnen 'spokes' worden gemaakt en gekoppeld om verouderde verificatie toe te staan voor servers en toepassingen. De spokes zijn extra VNets waarop aan Microsoft Entra Domain Services gekoppelde servers zich bevinden en zijn gekoppeld aan de hub met behulp van Azure-netwerkgateways of VNet-peering.

Locatie van beheerd domein : er moet een locatie worden ingesteld bij het implementeren van een door Microsoft Entra Domain Services beheerd domein. De locatie is een fysieke regio (datacenter) waar het beheerde domein wordt geïmplementeerd. Aanbevolen wordt dat u:

• Overweeg een locatie die geografisch is gesloten voor de servers en toepassingen waarvoor Microsoft Entra Domain Services-services zijn vereist.

• Overweegt regio's die Beschikbaarheidszones mogelijkheden bieden voor vereisten voor hoge beschikbaarheid. Zie Regio's die beschikbaarheidszones ondersteunen in Azure voor meer informatie

Objectinrichting : Microsoft Entra Domain Services synchroniseert identiteiten van de Microsoft Entra-id die is gekoppeld aan het abonnement waarop Microsoft Entra Domain Services is geïmplementeerd. Het is ook de moeite waard om te vermelden dat als de bijbehorende Microsoft Entra-id synchronisatie heeft ingesteld met Microsoft Entra Connect (gebruikersforestscenario), de levenscyclus van deze identiteiten ook kan worden weerspiegeld in Microsoft Entra Domain Services. Deze service heeft twee modi die kunnen worden gebruikt voor het inrichten van gebruikers- en groepsobjecten van Microsoft Entra-id.

• Alle: Alle gebruikers en groepen worden gesynchroniseerd vanuit Microsoft Entra ID naar Microsoft Entra Domain Services.

• Scoped: Alleen gebruikers binnen het bereik van een groep(en) worden gesynchroniseerd vanuit Microsoft Entra ID naar Microsoft Entra Domain Services.

Wanneer u Microsoft Entra Domain Services voor het eerst implementeert, wordt automatisch eenrichtingssynchronisatie geconfigureerd om de objecten te repliceren vanuit Microsoft Entra-id. Deze eenrichtingssynchronisatie blijft op de achtergrond worden uitgevoerd om het beheerde domein van Microsoft Entra Domain Services up-to-date te houden met eventuele wijzigingen van Microsoft Entra-id. Er wordt geen synchronisatie uitgevoerd van Microsoft Entra Domain Services naar Microsoft Entra ID. Zie Hoe objecten en referenties worden gesynchroniseerd in een door Microsoft Entra Domain Services beheerd domein voor meer informatie.

Het is de moeite waard om te weten dat als u het type synchronisatie moet wijzigen van Alles naar Scoped (of omgekeerd), het beheerde domein van Microsoft Entra Domain Services moet worden verwijderd, opnieuw gemaakt en geconfigureerd. Daarnaast moeten organisaties rekening houden met het gebruik van 'scoped'-inrichting om de identiteiten te beperken tot alleen de identiteiten die toegang nodig hebben tot Microsoft Entra Domain Services-resources als een goede gewoonte.

Groepsbeleidsobjecten (GPO): als u groepsbeleidsobjecten wilt configureren in een door Microsoft Entra Domain Services beheerd domein, moet u hulpprogramma's voor groepsbeleidsbeheer gebruiken op een server die is toegevoegd aan het beheerde domein van Microsoft Entra Domain Services. Zie Groepsbeleid beheren in een door Microsoft Entra Domain Services beheerd domein voor meer informatie.

Secure LDAP - Microsoft Entra Domain Services biedt een secure LDAP-service die kan worden gebruikt door toepassingen waarvoor dit is vereist. Deze instelling is standaard uitgeschakeld en om Secure LDAP in te schakelen, moet een certificaat worden geüpload. Daarnaast moet de NSG waarmee het VNet wordt beveiligd waarop Microsoft Entra Domain Services is geïmplementeerd, poort 636-connectiviteit met de beheerde domeinen van Microsoft Entra Domain Services toestaan. Zie Secure LDAP configureren voor een door Microsoft Entra Domain Services beheerd domein voor meer informatie.

Beheer : als u beheertaken wilt uitvoeren op Microsoft Entra Domain Services (bijvoorbeeld computers voor domeindeelname of het bewerken van GPO), moet het account dat voor deze taak wordt gebruikt, deel uitmaken van de microsoft Entra DC-beheerdersgroep. Accounts die lid zijn van deze groep kunnen zich niet rechtstreeks aanmelden bij domeincontrollers om beheertaken uit te voeren. In plaats daarvan maakt u een beheer-VM die is gekoppeld aan het beheerde domein van Microsoft Entra Domain Services en installeert u vervolgens uw reguliere AD DS-beheerprogramma's. Zie Beheerconcepten voor gebruikersaccounts, wachtwoorden en beheer in Microsoft Entra Domain Services voor meer informatie.

Wachtwoordhashes: verificatie met Microsoft Entra Domain Services werkt alleen als wachtwoordhashes voor alle gebruikers een indeling hebben die geschikt is voor NT LAN Manager -verificatie (NTLM) en Kerberos-verificatie. Om ervoor te zorgen dat verificatie met Microsoft Entra Domain Services werkt zoals verwacht, moeten de volgende vereisten worden uitgevoerd.

• Gebruikers die zijn gesynchroniseerd met Microsoft Entra Connect (van AD DS): de verouderde wachtwoordhashes moeten worden gesynchroniseerd vanuit on-premises AD DS naar Microsoft Entra-id.

• Gebruikers die zijn gemaakt in Microsoft Entra-id : moet hun wachtwoord opnieuw instellen voor de juiste hashes die moeten worden gegenereerd voor gebruik met Microsoft Entra Domain Services. Zie Synchronisatie van wachtwoordhashes inschakelen voor meer informatie.

Netwerk : Microsoft Entra Domain Services wordt geïmplementeerd op een Azure VNet, dus er moeten overwegingen worden gemaakt om ervoor te zorgen dat servers en toepassingen zijn beveiligd en toegang hebben tot het beheerde domein correct. Zie Ontwerpoverwegingen en configuratieopties voor virtuele netwerken voor Microsoft Entra Domain Services voor meer informatie.

• Microsoft Entra Domain Services moet worden geïmplementeerd in een eigen subnet: gebruik geen bestaand subnet of gatewaysubnet.

• Een netwerkbeveiligingsgroep (NSG) - wordt gemaakt tijdens de implementatie van een door Microsoft Entra Domain Services beheerd domein. Deze groep bevat de vereiste regels voor de juiste servicecommunicatie. Maak of gebruik geen netwerkbeveiligingsgroep met uw eigen aangepaste regels.

• Microsoft Entra Domain Services vereist 3-5 IP-adressen : zorg ervoor dat het IP-adresbereik van uw subnet dit aantal adressen kan opgeven. Het beperken van de beschikbare IP-adressen kan voorkomen dat Microsoft Entra Domain Services twee domeincontrollers onderhoudt.

• VNet DNS-server - Zoals eerder besproken over het 'hub and spoke'-model, is het belangrijk dat DNS correct is geconfigureerd op de VNets om ervoor te zorgen dat servers die zijn toegevoegd aan het beheerde domein van Microsoft Entra Domain Services de juiste DNS-instellingen hebben om het beheerde domein van Microsoft Entra Domain Services op te lossen. Elk VNet heeft een DNS-serververmelding die wordt doorgegeven aan servers wanneer ze een IP-adres verkrijgen en deze DNS-vermeldingen moeten de IP-adressen zijn van het door Microsoft Entra Domain Services beheerde domein. Zie DNS-instellingen bijwerken voor het virtuele Azure-netwerk voor meer informatie.

Uitdagingen - in de volgende lijst worden belangrijke uitdagingen gemarkeerd met het gebruik van deze optie voor identiteitsisolatie.

• Sommige Configuratie van Microsoft Entra Domain Services kan alleen worden beheerd vanaf een server die lid is van Microsoft Entra Domain Services.

• Er kan slechts één door Microsoft Entra Domain Services beheerd domein worden geïmplementeerd per Microsoft Entra-tenant. Zoals we in deze sectie beschrijven, wordt het hub- en spoke-model aanbevolen om Microsoft Entra Domain Services-verificatie te bieden aan services op andere VNets.

• Verdere infrastructuur mogelijk vereist voor het beheer van patches en software-implementaties. Organisaties moeten overwegen om Azure Update Management, groepsbeleid (GPO) of sccm (System Center Configuration Manager) te implementeren om deze servers te beheren.

Voor dit geïsoleerde model wordt ervan uitgegaan dat er geen verbinding is met het VNet dat als host fungeert voor het door Microsoft Entra Domain Services beheerde domein van het bedrijfsnetwerk van de klant en dat er geen vertrouwensrelaties zijn geconfigureerd met andere forests. Er moet een jumpbox- of beheerserver worden gemaakt om een punt toe te staan waarop de Microsoft Entra Domain Services kunnen worden beheerd en beheerd.

Aanmelden bij virtuele machines in Azure met behulp van Microsoft Entra-verificatie

Wanneer er een vereiste bestaat om IaaS-workloads te implementeren in Azure waarvoor identiteitsisolatie is vereist, is de laatste optie om Microsoft Entra-id te gebruiken voor aanmelding bij servers in dit scenario. Dit biedt de mogelijkheid om Microsoft Entra ID de identiteitsrealm te maken voor verificatiedoeleinden en identiteitsisolatie kan worden bereikt door de servers in te richten in het relevante abonnement, dat is gekoppeld aan de vereiste Microsoft Entra-tenant. De volgende overwegingen moeten worden gemaakt.

Ondersteunde besturingssystemen: aanmelden bij virtuele machines in Azure met behulp van Microsoft Entra-verificatie wordt momenteel ondersteund in Windows en Linux. Raadpleeg de documentatie voor Windows en Linux voor meer informatie over ondersteunde besturingssystemen.

Referenties: Een van de belangrijkste voordelen van het aanmelden bij virtuele machines in Azure met behulp van Microsoft Entra-verificatie is de mogelijkheid om dezelfde federatieve of beheerde Microsoft Entra-referenties te gebruiken die u normaal gesproken gebruikt voor toegang tot Microsoft Entra-services voor aanmelding bij de virtuele machine.

Notitie

De Microsoft Entra-tenant die wordt gebruikt voor aanmelding in dit scenario, is de Microsoft Entra-tenant die is gekoppeld aan het abonnement waarin de virtuele machine is ingericht. Deze Microsoft Entra-tenant kan een tenant zijn die identiteiten heeft gesynchroniseerd vanuit on-premises AD DS. Organisaties moeten een geïnformeerde keuze maken die overeenkomt met hun isolatie-principals bij het kiezen van welk abonnement en welke Microsoft Entra-tenant ze willen gebruiken voor aanmelding bij deze servers.

Netwerkvereisten: deze virtuele machines moeten toegang krijgen tot Microsoft Entra-id voor verificatie, zodat u ervoor moet zorgen dat de netwerkconfiguratie van de virtuele machines uitgaande toegang tot Microsoft Entra-eindpunten op 443 toestaat. Zie de documentatie voor Windows en Linux voor meer informatie.

Op rollen gebaseerde Access Control (RBAC):er zijn twee RBAC-rollen beschikbaar om het juiste toegangsniveau tot deze virtuele machines te bieden. Deze RBAC-rollen kunnen worden geconfigureerd via Azure Portal of via de Azure Cloud Shell Experience. Zie Roltoewijzingen configureren voor de VM voor meer informatie.

• Aanmelding van de beheerder van virtuele machines: gebruikers met deze rol die aan hen zijn toegewezen, kunnen zich aanmelden bij een virtuele Azure-machine met beheerdersbevoegdheden.

• Aanmelding van gebruikers van virtuele machines: gebruikers met deze rol die aan hen zijn toegewezen, kunnen zich aanmelden bij een virtuele Azure-machine met normale gebruikersbevoegdheden.

Voorwaardelijke toegang: Een belangrijk voordeel van het gebruik van Microsoft Entra ID voor het aanmelden bij virtuele Azure-machines is de mogelijkheid om voorwaardelijke toegang af te dwingen als onderdeel van het aanmeldingsproces. Dit biedt organisaties de mogelijkheid om te vereisen dat aan voorwaarden wordt voldaan voordat toegang tot de virtuele machine wordt toegestaan en meervoudige verificatie moet worden gebruikt om sterke verificatie te bieden. Zie Voorwaardelijke toegang gebruiken voor meer informatie.

Notitie

Externe verbinding met virtuele machines die zijn gekoppeld aan Microsoft Entra ID is alleen toegestaan vanaf Windows 10-, Windows 11- en Cloud PC-pc's die zijn toegevoegd aan Microsoft Entra of hybride Microsoft Entra gekoppeld aan dezelfde map als de virtuele machine.

Uitdagingen: In de onderstaande lijst worden de belangrijkste uitdagingen beschreven met het gebruik van deze optie voor identiteitsisolatie.

• Geen centraal beheer of configuratie van servers. Er is bijvoorbeeld geen groepsbeleid die kunnen worden toegepast op een groep servers. Organisaties moeten overwegen updatebeheer in Azure te implementeren om patches en updates van deze servers te beheren.

• Niet geschikt voor toepassingen met meerdere lagen die vereisten hebben voor verificatie met on-premises mechanismen zoals geïntegreerde Windows-verificatie op deze servers of services. Als dit een vereiste is voor de organisatie, is het raadzaam om de zelfstandige Active Directory-domein Services of de Microsoft Entra Domain Services-scenario's te verkennen die in deze sectie worden beschreven.

Voor dit geïsoleerde model wordt ervan uitgegaan dat er geen verbinding is met het VNet dat als host fungeert voor de virtuele machines van het bedrijfsnetwerk van de klant. Er moet een jumpbox- of beheerserver worden gemaakt om een punt toe te staan waaruit deze servers kunnen worden beheerd en beheerd.

Volgende stappen

• Inleiding tot gedelegeerd beheer en geïsoleerde omgevingen

• Basisprincipes van Microsoft Entra

• Resource-isolatie in één tenant

• Resource-isolatie met meerdere tenants

• Aanbevolen procedures