Delen via

Aanbevolen procedures voor alle isolatiearchitecturen

  • Artikel

Hier volgen ontwerpoverwegingen voor alle isolatieconfiguraties. In deze inhoud vindt u veel koppelingen. We koppelen aan inhoud in plaats van deze hier te dupliceren, zodat u altijd toegang hebt tot de meest recente informatie.

Raadpleeg de implementatiehandleiding voor Microsoft Entra-functies voor algemene richtlijnen voor het configureren van Microsoft Entra-tenants (geïsoleerd of niet).

Notitie

Voor alle geïsoleerde tenants raden we u aan duidelijke en gedifferentieerde huisstijl te gebruiken om menselijke fouten bij het werken in de verkeerde tenant te voorkomen.

Isolatiebeveiligingsprincipes

Bij het ontwerpen van geïsoleerde omgevingen is het belangrijk om rekening te houden met de volgende principes:

  • Gebruik alleen moderne verificatie : toepassingen die zijn geïmplementeerd in geïsoleerde omgevingen, moeten moderne verificatie op basis van claims (bijvoorbeeld SAML, * Auth, OAuth2 en OpenID Connect) gebruiken om mogelijkheden te gebruiken, zoals federatie, Microsoft Entra B2B-samenwerking, delegatie en het toestemmingsframework. Op deze manier worden verouderde toepassingen die afhankelijk zijn van verouderde verificatiemethoden, zoals NT LAN Manager (NTLM), niet uitgevoerd in geïsoleerde omgevingen.

  • Sterke verificatie afdwingen: sterke verificatie moet altijd worden gebruikt bij het openen van de geïsoleerde omgevingsservices en -infrastructuur. Waar mogelijk moet verificatie zonder wachtwoord, zoals Windows voor Bedrijven Hello of fido2-beveiligingssleutels, worden gebruikt.

  • Veilige werkstations implementeren Veilige werkstations - bieden het mechanisme om ervoor te zorgen dat het platform en de identiteit die het platform vertegenwoordigt, correct worden getest en beveiligd tegen exploitatie. Er zijn twee andere manieren om rekening mee te houden:

    • Gebruik Windows 365 Cloud-pc s (Cloud PC) met de Microsoft Graph API.

    • Gebruik voorwaardelijke toegang en filter op apparaten als voorwaarde.

  • Verouderde vertrouwensmechanismen elimineren: geïsoleerde mappen en services mogen geen vertrouwensrelaties met andere omgevingen tot stand brengen via verouderde mechanismen zoals Active Directory-vertrouwensrelaties. Alle vertrouwensrelaties tussen omgevingen moeten worden ingesteld met moderne constructies, zoals federatie en op claims gebaseerde identiteit.

  • Services isoleren: minimaliseer het oppervlakaanvalgebied door onderliggende identiteiten en service-infrastructuur te beschermen tegen blootstelling. Schakel alleen toegang in via moderne verificatie voor services en veilige externe toegang (ook beveiligd door moderne verificatie) voor de infrastructuur.

  • Roltoewijzingen op adreslijstniveau: vermijd of verminder het aantal roltoewijzingen op adreslijstniveau (Gebruikersbeheerder voor adreslijstbereik in plaats van AU-bereik) of servicespecifieke directoryrollen met besturingsvlakacties (Kennisbeheerder met machtigingen voor het beheren van lidmaatschappen van beveiligingsgroepen).

Naast de richtlijnen in de algemene handleiding voor Microsoft Entra-bewerkingen raden we ook de volgende overwegingen aan voor geïsoleerde omgevingen.

Inrichting van menselijke identiteiten

Bevoegde accounts

Richt accounts in de geïsoleerde omgeving in voor administratief personeel en IT-teams die de omgeving beheren. Hiermee kunt u sterker beveiligingsbeleid toevoegen, zoals toegangsbeheer op basis van apparaten voor beveiligde werkstations. Zoals in de vorige secties is besproken, kunnen niet-productieomgevingen mogelijk gebruikmaken van Microsoft Entra B2B-samenwerking om bevoegde accounts aan de niet-productietenants te onboarden met dezelfde postuur- en beveiligingscontroles die zijn ontworpen voor bevoegde toegang in hun productieomgeving.

Cloudaccounts zijn de eenvoudigste manier om menselijke identiteiten in te richten in een Microsoft Entra-tenant en het is geschikt voor groene veldomgevingen. Als er echter een bestaande on-premises infrastructuur is die overeenkomt met de geïsoleerde omgeving (bijvoorbeeld een Active Directory-forest vóór productie of beheer), kunt u overwegen om identiteiten van daaruit te synchroniseren. Dit geldt met name als de on-premises infrastructuur die hier wordt beschreven, wordt gebruikt voor IaaS-oplossingen waarvoor servertoegang nodig is om het gegevensvlak van de oplossing te beheren. Zie Microsoft 365 beveiligen tegen on-premises aanvallen voor meer informatie over dit scenario. Synchroniseren vanuit geïsoleerde on-premises omgevingen kan ook nodig zijn als er specifieke nalevingsvereisten voor regelgeving zijn, zoals alleen verificatie voor smartcards.

Notitie

Er zijn geen technische controles voor identiteitscontrole voor Microsoft Entra B2B-accounts. Externe identiteiten die zijn ingericht met Microsoft Entra B2B, worden met één factor opgestart. De beperking is dat de organisatie een proces heeft om de vereiste identiteiten te controleren voordat een B2B-uitnodiging wordt uitgegeven, en regelmatige toegangsbeoordelingen van externe identiteiten om de levenscyclus te beheren. Overweeg om beleid voor voorwaardelijke toegang in te schakelen om de MFA-registratie te beheren.

Uitbesteden van rollen met hoog risico

Als u bedreigingen wilt beperken, is het mogelijk om toegang uit te besteden aan globale beheerders- en bevoorrechte rolbeheerdersrollen om een beheerde serviceprovider te worden met behulp van Azure B2B-samenwerking of het delegeren van toegang via een CSP-partner of lighthouse. Deze toegang kan worden beheerd door intern personeel via goedkeuringsstromen in Azure Privileged Identity Management (PIM). Deze aanpak kan binnen bedreigingen aanzienlijk verminderen. Dit is een benadering die u kunt gebruiken om te voldoen aan nalevingsvereisten voor klanten die zorgen hebben.

Inrichting van niet-menselijke identiteit

Accounts voor noodtoegang

Microsoft raadt aan dat organisaties twee accounts voor alleen-cloudtoegang voor noodgevallen hebben toegewezen aan de rol Globale beheerder . Deze accounts hebben hoge bevoegdheden en worden niet toegewezen aan specifieke personen. De accounts zijn beperkt tot scenario's met nood- of onderbrekingsglas, waarbij normale accounts niet kunnen worden gebruikt of dat alle andere beheerders per ongeluk zijn vergrendeld. Deze accounts moeten worden gemaakt op basis van de aanbevelingen voor toegangsaccounts voor noodgevallen.

Door Azure beheerde identiteiten

Gebruik beheerde Azure-identiteiten voor Azure-resources waarvoor een service-identiteit is vereist. Controleer de lijst met services die beheerde identiteiten ondersteunen bij het ontwerpen van uw Azure-oplossingen.

Als beheerde identiteiten niet worden ondersteund of niet mogelijk zijn, kunt u overwegen om service-principalobjecten in te richten.

Hybride serviceaccounts

Voor sommige hybride oplossingen is mogelijk toegang tot zowel on-premises als cloudresources vereist. Een voorbeeld van een use-case is een toepassing die gebruikmaakt van een serviceaccount in AD DS voor toegang tot on-premises servers die lid zijn van een domein en die ook een account in Microsoft Entra-id heeft, omdat hiervoor toegang tot Microsoft Online Services is vereist.

On-premises serviceaccounts hebben doorgaans niet de mogelijkheid om zich interactief aan te melden, wat betekent dat ze in cloudscenario's niet aan sterke referentievereisten kunnen voldoen, zoals meervoudige verificatie. Gebruik in dit scenario geen serviceaccount dat is gesynchroniseerd vanuit on-premises, maar gebruik in plaats daarvan een beheerde identiteit \ service-principal. Gebruik voor service-principal (SP) een certificaat als referentie of beveilig de SP met voorwaardelijke toegang.

Als er technische beperkingen zijn die dit niet mogelijk maken en hetzelfde account moet worden gebruikt voor zowel on-premises als in de cloud, implementeert u compenserende besturingselementen zoals voorwaardelijke toegang om het hybride account te vergrendelen zodat het afkomstig is van een specifieke netwerklocatie.

Resourcetoewijzing

Een bedrijfsoplossing kan bestaan uit meerdere Azure-resources en de toegang ervan moet worden beheerd en beheerd als een logische toewijzingseenheid: een resourcegroep. In dat scenario kunnen Microsoft Entra-beveiligingsgroepen worden gemaakt en gekoppeld aan de juiste machtigingen en roltoewijzing voor alle oplossingsbronnen, zodat het toevoegen of verwijderen van gebruikers uit deze groepen resulteert in het toestaan of weigeren van toegang tot de hele oplossing.

U wordt aangeraden groepslicenties en beveiligingsgroepen te gebruiken voor Microsoft-services die afhankelijk zijn van een gebruiker die een licentiestoeltoewijzing als vereiste heeft voordat u toegang verleent (bijvoorbeeld Dynamics 365, Power BI).

Systeemeigen Microsoft Entra-cloudgroepen kunnen systeemeigen worden beheerd vanuit de cloud in combinatie met Toegangsbeoordelingen van Microsoft Entra en Microsoft Entra-rechtenbeheer.

Microsoft Entra ID biedt ook ondersteuning voor directe gebruikerstoewijzing aan SaaS-services van derden (bijvoorbeeld Salesforce, Service Now) en on-premises toepassingen voor eenmalige aanmelding en identiteitsinrichting. Directe toewijzingen aan resources kunnen systeemeigen worden beheerd vanuit de cloud in combinatie met toegangsbeoordelingen van Microsoft Entra en Microsoft Entra-rechtenbeheer. Directe toewijzing is mogelijk geschikt voor toewijzing door eindgebruikers.

Voor sommige scenario's moet u mogelijk toegang verlenen tot on-premises resources via on-premises Active Directory-beveiligingsgroepen. Houd voor deze gevallen rekening met de synchronisatiecyclus naar Microsoft Entra ID bij het ontwerpen van de SLA voor processen.

Verificatiebeheer

In deze sectie worden de controles beschreven die moeten worden uitgevoerd en acties die moeten worden uitgevoerd voor referentiebeheer en toegangsbeleid op basis van de beveiligingspostuur van uw organisatie.

Referentiebeheer

Sterke referenties

Alle menselijke identiteiten (lokale accounts en externe identiteiten die zijn ingericht via B2B-samenwerking) in de geïsoleerde omgeving moeten worden ingericht met sterke verificatiereferenties, zoals meervoudige verificatie of een FIDO-sleutel. Omgevingen met een onderliggende on-premises infrastructuur met sterke verificatie, zoals smartcardverificatie, kunnen gebruikmaken van smartcardverificatie in de cloud.

Referenties zonder wachtwoord

Een oplossing zonder wachtwoord is de beste oplossing om de handigste en veilige verificatiemethode te garanderen. Referenties zonder wachtwoord, zoals FIDO-beveiligingssleutels en Windows Hello voor Bedrijven worden aanbevolen voor menselijke identiteiten met bevoorrechte rollen.

Wachtwoordbeveiliging

Als de omgeving wordt gesynchroniseerd vanuit een on-premises Active Directory-forest, moet u Microsoft Entra-wachtwoordbeveiliging implementeren om zwakke wachtwoorden in uw organisatie te elimineren. Slimme vergrendeling van Microsoft Entra moet ook worden gebruikt in hybride of cloudomgevingen om slechte actoren te vergrendelen die proberen de wachtwoorden van uw gebruikers te raden of brute force-methoden te gebruiken om binnen te komen.

Wachtwoordbeheer via selfservice

Gebruikers die hun wachtwoorden moeten wijzigen of opnieuw instellen, zijn een van de grootste bronnen van volume en kosten van helpdeskgesprekken. Naast de kosten is het wijzigen van het wachtwoord als hulpprogramma om het risico van een gebruiker te beperken een fundamentele stap in het verbeteren van de beveiligingspostuur van uw organisatie. Implementeer ten minste selfservicewachtwoordbeheer voor menselijke accounts en testaccounts met wachtwoorden om helpdeskoproepen af te leiden.

Wachtwoorden voor externe identiteiten

Met behulp van Microsoft Entra B2B-samenwerking kunnen externe gebruikers zoals partners, ontwikkelaars en onderaannemers hun eigen referenties gebruiken om toegang te krijgen tot de resources van uw bedrijf. Dit vermindert de noodzaak om meer wachtwoorden in te voeren in de geïsoleerde tenants.

Notitie

Voor sommige toepassingen, infrastructuur of werkstromen is mogelijk een lokale referentie vereist. Evalueer dit per geval.

Referenties voor service-principals

Voor scenario's waarin service-principals nodig zijn, gebruikt u certificaatreferenties voor service-principals of voorwaardelijke toegang voor workloadidentiteiten. Gebruik indien nodig clientgeheimen als uitzondering op organisatiebeleid.

In beide gevallen kan Azure Key Vault worden gebruikt met door Azure beheerde identiteiten, zodat de runtime-omgeving (bijvoorbeeld een Azure-functie) de referentie uit de sleutelkluis kan ophalen.

Bekijk dit voorbeeld om service-principals te maken met een zelfondertekend certificaat voor verificatie van service-principals met certificaatreferenties.

Toegangsbeleid

In de volgende secties ziet u aanbevelingen voor Azure-oplossingen. Raadpleeg de aanbevolen procedures voor voorwaardelijke toegang, microsoft Entra Operations Guide en voorwaardelijke toegang voor Zero Trust voor algemene richtlijnen voor beleid voor voorwaardelijke toegang voor afzonderlijke omgevingen:

  • Definieer beleid voor voorwaardelijke toegang voor de Cloud-app van de Windows Azure Service Management-API om identiteitsbeveiligingspostuur af te dwingen bij het openen van Azure Resource Manager. Dit moet besturingselementen bevatten voor MFA en besturingselementen op basis van apparaten om alleen toegang mogelijk te maken via beveiligde werkstations (meer hierover in de sectie Bevoorrechte rollen onder Identiteitsbeheer). Daarnaast kunt u voorwaardelijke toegang gebruiken om te filteren op apparaten.

  • Alle toepassingen die in geïsoleerde omgevingen worden uitgevoerd, moeten expliciet beleid voor voorwaardelijke toegang hebben toegepast als onderdeel van het onboardingproces.

  • Definieer beleid voor voorwaardelijke toegang voor registratie van beveiligingsgegevens die een veilige basis van het vertrouwensproces on-premises weerspiegelt (bijvoorbeeld voor werkstations op fysieke locaties, identificeerbaar door IP-adressen, die werknemers persoonlijk moeten bezoeken voor verificatie).

  • Overweeg om voorwaardelijke toegang te gebruiken om workloadidentiteiten te beperken. Maak een beleid om de toegang te beperken of beter te beheren op basis van locatie of andere relevante omstandigheden.

Verificatieuitdagingen

  • Externe identiteiten die zijn ingericht met Microsoft Entra B2B, moeten mogelijk meervoudige verificatiereferenties opnieuw inrichten in de resourcetenant. Dit kan nodig zijn als er geen toegangsbeleid voor meerdere tenants is ingesteld met de resourcetenant. Dit betekent dat onboarding naar het systeem wordt opgestart met één factor. Met deze aanpak is de risicobeperking voor de organisatie bedoeld om het risicoprofiel voor gebruikers en referenties te controleren voordat een B2B-uitnodiging wordt uitgegeven. Daarnaast definieert u voorwaardelijke toegang tot het registratieproces zoals eerder beschreven.

  • Gebruik instellingen voor externe identiteiten voor meerdere tenants om te beheren hoe ze samenwerken met andere Microsoft Entra-organisaties en andere Microsoft Azure-clouds via B2B-samenwerking en B2B direct verbinding maken.

  • Voor specifieke apparaatconfiguratie en -beheer kunt u apparaatfilters in het beleid voor voorwaardelijke toegang gebruiken om specifieke apparaten te targeten of uit te sluiten. Hiermee kunt u de toegang tot Azure-beheerhulpprogramma's beperken vanaf een aangewezen beveiligd beheerwerkstation (SAW). Andere benaderingen die u kunt gebruiken, zijn onder andere het gebruik van Azure Virtual Desktop, Azure Bastion of Cloud PC.

  • Factureringsbeheertoepassingen zoals Azure EA Portal of MCA-factureringsaccounts worden niet weergegeven als cloudtoepassingen voor voorwaardelijke toegang. Als compenserende controle definieert u afzonderlijke beheeraccounts en richt u beleid voor voorwaardelijke toegang op die accounts met behulp van een voorwaarde 'Alle apps'.

Identiteitsbeheer

Bevoorrechte rollen

Hieronder vindt u enkele principes voor identiteitsbeheer die u kunt overwegen voor alle tenantconfiguraties voor isolatie.

  • Geen permanente toegang - Geen menselijke identiteiten moeten permanente toegang hebben om bevoegde bewerkingen uit te voeren in geïsoleerde omgevingen. Op rollen gebaseerd toegangsbeheer van Azure (RBAC) kan worden geïntegreerd met Microsoft Entra Privileged Identity Management (PIM). PIM biedt Just-In-Time-activering die wordt bepaald door beveiligingspoorten zoals meervoudige verificatie, goedkeuringswerkstroom en beperkte duur.

  • Aantal beheerders : organisaties moeten minimum- en maximumaantal mensen met een bevoorrechte rol definiëren om risico's voor bedrijfscontinuïteit te beperken. Met te weinig bevoorrechte rollen is er mogelijk onvoldoende tijdzonedekking. Beperk beveiligingsrisico's door zo weinig mogelijk beheerders te hebben, volgens het principe met minimale bevoegdheden.

  • Beperkte toegang : maak alleen-cloud- en roltoewijzingsgroepen voor hoge bevoegdheden of gevoelige bevoegdheden. Dit biedt bescherming van de toegewezen gebruikers en het groepsobject.

  • Toegang met minimale bevoegdheden : identiteiten mogen alleen de machtigingen krijgen die nodig zijn om de bevoegde bewerkingen uit te voeren per hun rol in de organisatie.

    • Aangepaste Azure RBAC-rollen bieden de mogelijkheid om rollen met minimale bevoegdheden te ontwerpen op basis van de behoeften van de organisatie. We raden u aan om aangepaste rollendefinities te ontwerpen of te controleren door gespecialiseerde beveiligingsteams en risico's van onbedoelde overmatige bevoegdheden te beperken. Het ontwerpen van aangepaste rollen kan worden gecontroleerd via Azure Policy.

    • Als u per ongeluk het gebruik van rollen wilt beperken die niet bedoeld zijn voor breder gebruik in de organisatie, gebruikt u Azure Policy om expliciet te definiëren welke roldefinities kunnen worden gebruikt om toegang toe te wijzen. Meer informatie vindt u in dit GitHub-voorbeeld.

  • Bevoegde toegang vanaf beveiligde werkstations : alle bevoegde toegang moet plaatsvinden vanaf beveiligde, vergrendelde apparaten. Door deze gevoelige taken en accounts te scheiden van werkstations en apparaten die dagelijks worden gebruikt, worden bevoegde accounts beschermd tegen phishingaanvallen, beveiligingsproblemen in toepassingen en besturingssystemen, verschillende imitatieaanvallen en diefstal van referenties, zoals logboekregistratie van toetsaanslagen, Pass-the-Hash en Pass-The-Ticket.

Sommige benaderingen die u kunt gebruiken voor het gebruik van beveiligde apparaten als onderdeel van uw verhaal over bevoegde toegang, zijn het gebruik van beleid voor voorwaardelijke toegang om specifieke apparaten te targeten of uit te sluiten, met behulp van Azure Virtual Desktop, Azure Bastion of Cloud PC, of het maken van door Azure beheerde werkstations of bevoegde toegangswerkstations.

  • Kaders voor bevoorrechte rolprocessen - Organisaties moeten processen en technische kaders definiëren om ervoor te zorgen dat bevoegde bewerkingen waar nodig kunnen worden uitgevoerd terwijl ze voldoen aan wettelijke vereisten. Voorbeelden van kadercriteria zijn:

    • Kwalificatie van mensen met bevoorrechte rollen (bijvoorbeeld fulltime werknemer/leverancier, goedkeuringsniveau, burgerschap)

    • Expliciete incompatibiliteit van rollen (ook wel scheiding van taken genoemd). Voorbeelden hiervan zijn teams met Directory-rollen van Microsoft Entra, mogen niet verantwoordelijk zijn voor het beheren van bevoorrechte Rollen van Azure Resource Manager, enzovoort.

    • Of directe toewijzingen van gebruikers of groepen de voorkeur hebben voor welke rollen.

  • Het bewaken van IAM-toewijzingen buiten Microsoft Entra PIM wordt niet geautomatiseerd via Azure-beleid. De beperking is om de rol Abonnementseigenaar of Beheerder van gebruikerstoegang niet toe te kennen aan technische teams. Maak in plaats daarvan groepen die zijn toegewezen aan rollen met minimale bevoegdheden, zoals Inzender en delegeer het beheer van deze groepen aan technische teams.

Resourcetoegang

  • Attestation : identiteiten met bevoorrechte rollen moeten periodiek worden gecontroleerd om lidmaatschap actueel en gerechtvaardigd te houden. Microsoft Entra-toegangsbeoordelingen zijn geïntegreerd met Azure RBAC-rollen, groepslidmaatschappen en externe Microsoft Entra B2B-identiteiten.

  • Levenscyclus : bevoegde bewerkingen vereisen mogelijk toegang tot meerdere resources, zoals Line-Of-Business-toepassingen, SaaS-toepassingen en Azure-resourcegroepen en -abonnementen. Met Microsoft Entra Entitlement Management kunt u toegangspakketten definiëren die een setresource vertegenwoordigen die als eenheid aan gebruikers is toegewezen, een geldigheidsperiode, goedkeuringswerkstromen tot stand brengen, enzovoort.

Levenscyclusbeheer voor tenants en abonnementen

Levenscyclus van tenants

  • U wordt aangeraden een proces te implementeren om een nieuwe Zakelijke Microsoft Entra-tenant aan te vragen. Het proces moet rekening houden met:

    • Zakelijke reden om deze te maken. Het maken van een nieuwe Microsoft Entra-tenant verhoogt de complexiteit aanzienlijk, dus het is belangrijk om te controleren of een nieuwe tenant nodig is.

    • De Azure-cloud waarin deze moet worden gemaakt (bijvoorbeeld Commercial, Government, enzovoort).

    • Of dit nu productie is of niet productie

    • Vereisten voor adreslijstgegevenslocatie

    • Wie zal het beheren

    • Training en begrip van algemene beveiligingsvereisten.

  • Na goedkeuring wordt de Microsoft Entra-tenant gemaakt, geconfigureerd met de benodigde basislijncontroles en onboarding in het factureringsvlak, bewaking, enzovoort.

  • Regelmatige controle van de Microsoft Entra-tenants in het factureringsvlak moet worden geïmplementeerd om het maken van tenants buiten het beheerde proces te detecteren en te detecteren. Raadpleeg de sectie Inventaris en zichtbaarheid van dit document voor meer informatie.

  • Het maken van Azure AD B2C-tenants kan worden beheerd met behulp van Azure Policy. Het beleid wordt uitgevoerd wanneer een Azure-abonnement is gekoppeld aan de B2C-tenant (een vereiste voor facturering). Klanten kunnen het maken van Azure AD B2C-tenants beperken tot specifieke beheergroepen.

  • Er zijn geen technische controles voor het ondergeschikt maken van tenants aan een organisatie. De activiteit wordt echter vastgelegd in het auditlogboek. De onboarding naar het factureringsvlak is een compenserende controle aan de poort. Dit moet worden aangevuld met bewaking en waarschuwingen.

Levenscyclus van abonnement

Hieronder volgen enkele overwegingen bij het ontwerpen van een levenscyclusproces voor een beheerd abonnement:

  • Definieer een taxonomie van toepassingen en oplossingen waarvoor Azure-resources zijn vereist. Alle teams die abonnementen aanvragen, moeten hun 'product-id' opgeven bij het aanvragen van abonnementen. Deze informatietaxonomie bepaalt:

    • Microsoft Entra-tenant voor het inrichten van het abonnement

    • Azure EA-account dat moet worden gebruikt voor het maken van een abonnement

    • Naamgevingsconventie

    • Toewijzing van beheergroep

    • Andere aspecten, zoals taggen, kruislings opladen, gebruik van productweergaven, enzovoort.

  • Sta het maken van ad-hocabonnementen niet toe via de portals of op een andere manier. In plaats daarvan kunt u abonnementen programmatisch beheren met behulp van Azure Resource Manager en programmatisch verbruiks- en factureringsrapporten ophalen. Hiermee kunt u het inrichten van abonnementen beperken tot geautoriseerde gebruikers en uw beleids- en taxonomiedoelen afdwingen. Richtlijnen voor het volgen van AZOps-principals kunnen worden gebruikt om een praktische oplossing te maken.

  • Wanneer een abonnement is ingericht, maakt u Microsoft Entra-cloudgroepen voor standaard Azure Resource Manager-rollen die nodig zijn voor toepassingsteams, zoals Inzender, Lezer en goedgekeurde aangepaste rollen. Hiermee kunt u Azure RBAC-roltoewijzingen beheren met beheerde bevoegde toegang op schaal.

    1. Configureer de groepen om in aanmerking te komen voor Azure RBAC-rollen met behulp van Microsoft Entra PIM met de bijbehorende besturingselementen, zoals activeringsbeleid, toegangsbeoordelingen, goedkeurders, enzovoort.

    2. Delegeer vervolgens het beheer van de groepen aan eigenaren van oplossingen.

    3. Wijs als kader geen producteigenaren toe aan gebruikerstoegangsbeheerder- of eigenaarsrollen om onbedoelde directe toewijzing van rollen buiten Microsoft Entra PIM te voorkomen of het abonnement mogelijk helemaal te wijzigen in een andere tenant.

    4. Voor klanten die ervoor kiezen om abonnementsbeheer tussen tenants in niet-productietenants via Azure Lighthouse in te schakelen, moet u ervoor zorgen dat hetzelfde toegangsbeleid van het account met productiebevoegdheden (bijvoorbeeld alleen bevoegde toegang vanaf beveiligde werkstations) wordt afgedwongen bij het verifiëren voor het beheren van abonnementen.

  • Als uw organisatie vooraf goedgekeurde referentiearchitecturen heeft, kan het inrichten van abonnementen worden geïntegreerd met hulpprogramma's voor resource-implementatie, zoals Azure Blueprints of Terraform.

  • Gezien de tenantaffiniteit met Azure-abonnementen moet het inrichten van abonnementen op de hoogte zijn van meerdere identiteiten voor dezelfde menselijke actor (werknemer, partner, leverancier, enzovoort) voor meerdere tenants en dienovereenkomstig toegang toewijzen.

EA- en MCA-rollen

  • De Azure Enterprise-overeenkomstportal (Azure EA) kan niet worden geïntegreerd met Azure RBAC of voorwaardelijke toegang. De oplossing hiervoor is het gebruik van toegewezen beheeraccounts die kunnen worden gericht op beleid en aanvullende bewaking.

  • De Azure EA Enterprise-portal biedt geen auditlogboek. Om dit te verhelpen, kunt u een geautomatiseerd beheerd proces overwegen om abonnementen in te richten met de hierboven beschreven overwegingen en speciale EA-accounts gebruiken en de verificatielogboeken controleren.

  • Microsoft-klantovereenkomst (MCA)-rollen zijn niet systeemeigen geïntegreerd met PIM. U kunt dit verhelpen door toegewezen MCA-accounts te gebruiken en het gebruik van deze accounts te controleren.

Azure AD B2C-tenants

  • In een Azure AD B2C-tenant bieden de ingebouwde rollen geen ondersteuning voor PIM. Om de beveiliging te verbeteren, raden we u aan Microsoft Entra B2B-samenwerking te gebruiken om de technische teams die CIAM (Customer Identity Access Management) beheren vanuit uw Azure-tenant te onboarden, deze toe te wijzen aan bevoorrechte Rollen van Azure AD B2C en beleid voor voorwaardelijke toegang toe te passen op deze toegewezen beheeraccounts.

  • Bevoorrechte rollen voor Azure AD B2C-tenants zijn niet geïntegreerd met Microsoft Entra-toegangsbeoordelingen. De oplossing is om toegewezen accounts te maken in de Microsoft Entra-tenant van de organisatie, deze accounts toe te voegen aan een groep en regelmatig toegangsbeoordelingen uit te voeren op deze groep.

  • Volg de bovenstaande richtlijnen voor toegang tot noodgevallen voor Microsoft Entra ID en overweeg naast de hierboven beschreven externe beheerders gelijkwaardige accounts voor toegang tot noodgevallen te maken.

  • We raden het logische eigendom aan van het onderliggende Microsoft Entra-abonnement van de B2C-tenant, op dezelfde manier als de rest van Azure-abonnementen worden gebruikt voor de B2C-oplossingen.

Operations

Hieronder vindt u aanvullende operationele overwegingen voor Microsoft Entra ID, specifiek voor meerdere geïsoleerde omgevingen. Raadpleeg het Azure Cloud Adoption Framework, de Microsoft-handleiding voor cloudbeveiliging en Microsoft Entra Operations voor gedetailleerde richtlijnen voor het uitvoeren van afzonderlijke omgevingen.

Rollen en verantwoordelijkheden tussen omgevingen

Bedrijfsbrede SecOps-architectuur : leden van operationele en beveiligingsteams uit alle omgevingen in de organisatie moeten gezamenlijk het volgende definiëren:

  • Principes om te definiëren wanneer omgevingen moeten worden gemaakt, geconsolideerd of afgeschaft.

  • Principes voor het definiëren van de hiërarchie van beheergroepen voor elke omgeving.

  • Factureringsvlak (EA Portal/ MCA) beveiligingspostuur, operationele houding en delegatiebenadering.

  • Proces voor het maken van de tenant.

  • Taxonomie van bedrijfstoepassingen.

  • Inrichtingsproces voor Azure-abonnementen.

  • Isolatie- en beheerautonomiegrenzen en risicobeoordeling tussen teams en omgevingen.

  • Algemene basislijnconfiguratie- en beveiligingscontroles (technische en compenserende) en operationele basislijnen die in alle omgevingen moeten worden gebruikt.

  • Algemene operationele standaardprocedures en hulpprogramma's die meerdere omgevingen omvatten (bijvoorbeeld bewaking, inrichting).

  • Overeengekomen over delegering van rollen in meerdere omgevingen.

  • Scheiding van plicht in omgevingen.

  • Algemeen supply chain-beheer voor bevoegde werkstations.

  • Naamconventies.

  • Correlatiemechanismen tussen omgevingen.

Tenant maken : een specifiek team moet eigenaar zijn van het maken van de tenant volgens gestandaardiseerde procedures die zijn gedefinieerd door de SecOps-architectuur voor de hele onderneming. Dit zijn onder andere de nieuwe mogelijkheden:

  • Onderliggende licentieinrichting (bijvoorbeeld Microsoft 365).

  • Onboarding naar bedrijfsfactureringsplan (bijvoorbeeld Azure EA of MCA).

  • Het maken van de Azure-beheergroephiërarchie.

  • Configuratie van beheerbeleidsregels voor verschillende perimeters, waaronder identiteit, gegevensbescherming, Azure, enzovoort.

  • Implementatie van beveiligingsstack per overeengekomen cyberbeveiligingsarchitectuur, waaronder diagnostische instellingen, SIEM-onboarding, CASB-onboarding, PIM-onboarding, enzovoort.

  • Configuratie van Microsoft Entra-rollen op basis van overeengekomen delegatie.

  • Configuratie en distributie van initiële bevoegde werkstations.

  • Accounts voor noodtoegang inrichten.

  • Configuratie van identiteitsinrichtingsstack.

Architectuur voor hulpprogramma's voor meerdere omgevingen: sommige hulpprogramma's, zoals identiteitsinrichting en pijplijnen voor broncodebeheer, moeten mogelijk in meerdere omgevingen werken. Deze hulpprogramma's moeten als essentieel worden beschouwd voor de infrastructuur en moeten als zodanig worden ontworpen, ontworpen, geïmplementeerd en beheerd. Hierdoor moeten architecten uit alle omgevingen betrokken zijn wanneer hulpprogramma's voor meerdere omgevingen moeten worden gedefinieerd.

Inventaris en zichtbaarheid

Detectie van Azure-abonnementen : voor elke gedetecteerde tenant kan een globale beheerder van Microsoft Entra de toegang verhogen om inzicht te krijgen in alle abonnementen in de omgeving. Met deze uitbreiding wordt de ingebouwde rol Gebruikerstoegangsbeheerder toegewezen aan de hoofdbeheergroep.

Notitie

Deze actie is zeer bevoegd en kan de beheerder toegang geven tot abonnementen die uiterst gevoelige informatie bevatten als die gegevens niet goed zijn geïsoleerd.

Leestoegang inschakelen voor het detecteren van resources - Beheergroepen schakelen RBAC-toewijzing op schaal in voor meerdere abonnementen. Klanten kunnen een lezerrol verlenen aan een gecentraliseerd IT-team door een roltoewijzing te configureren in de hoofdbeheergroep, die wordt doorgegeven aan alle abonnementen in de omgeving.

Resourcedetectie : na het verkrijgen van leestoegang tot resources in de omgeving, kan Azure Resource Graph worden gebruikt om query's uit te voeren op resources in de omgeving.

Logboekregistratie en controle

Centraal beheer van beveiligingslogboeken : neem logboeken van elke omgeving op een gecentraliseerde manier op, volg consistente best practices in omgevingen (bijvoorbeeld diagnostische instellingen, logboekretentie, SIEM-opname, enzovoort). Azure Monitor kan worden gebruikt voor het opnemen van logboeken uit verschillende bronnen, zoals eindpuntapparaten, netwerk, beveiligingslogboeken van besturingssystemen, enzovoort.

Gedetailleerde informatie over het gebruik van geautomatiseerde of handmatige processen en hulpprogramma's voor het bewaken van logboeken als onderdeel van uw beveiligingsbewerkingen is beschikbaar in de handleiding voor beveiligingsbewerkingen van Microsoft Entra.

Sommige omgevingen hebben mogelijk wettelijke vereisten die beperken welke gegevens (indien van toepassing) een bepaalde omgeving kunnen verlaten. Als gecentraliseerde bewaking in omgevingen niet mogelijk is, moeten teams operationele procedures hebben om activiteiten van identiteiten in omgevingen te correleren voor controledoeleinden en forensische doeleinden, zoals laterale verplaatsingspogingen tussen omgevingen. Het wordt aanbevolen dat de unieke object-id's menselijke identiteiten die tot dezelfde persoon behoren, detecteerbaar zijn, mogelijk als onderdeel van de identiteitsinrichtingssystemen.

De logboekstrategie moet de volgende Microsoft Entra-logboeken bevatten voor elke tenant die in de organisatie wordt gebruikt:

  • Aanmeldingsactiviteit

  • Auditlogboeken

  • Risicogebeurtenissen

Microsoft Entra ID biedt Azure Monitor-integratie voor het aanmeldactiviteitenlogboek en auditlogboeken. Risicogebeurtenissen kunnen worden opgenomen via Microsoft Graph API.

In het volgende diagram ziet u de verschillende gegevensbronnen die moeten worden opgenomen als onderdeel van de bewakingsstrategie:

Azure AD B2C-tenants kunnen worden geïntegreerd met Azure Monitor. We raden u aan om azure AD B2C te bewaken met behulp van dezelfde criteria die hierboven zijn besproken voor Microsoft Entra-id.

Abonnementen die beheer tussen tenants met Azure Lighthouse hebben ingeschakeld, kunnen bewaking tussen tenants inschakelen als de logboeken worden verzameld door Azure Monitor. De bijbehorende Log Analytics-werkruimten kunnen zich in de resourcetenant bevinden en kunnen centraal worden geanalyseerd in de beheertenant met behulp van Azure Monitor-werkmappen. Raadpleeg gedelegeerde resources op schaal bewaken - Azure Lighthouse voor meer informatie.

Beveiligingslogboeken van het besturingssysteem voor hybride infrastructuur

Alle os-logboeken van de hybride identiteitsinfrastructuur moeten worden gearchiveerd en zorgvuldig worden bewaakt als een laag 0-systeem, gezien de gevolgen van het oppervlakgebied. Dit zijn onder andere de nieuwe mogelijkheden:

  • AD FS-servers en web-toepassingsproxy

  • Microsoft Entra Connect

  • toepassingsproxy agents

  • Agents voor wachtwoord terugschrijven

  • Gatewaycomputers voor wachtwoordbeveiliging

  • NPS met de RADIUS-extensie voor meervoudige verificatie van Microsoft Entra

Microsoft Entra Connect Health moet worden geïmplementeerd om identiteitssynchronisatie en federatie (indien van toepassing) te bewaken voor alle omgevingen.

Retentie van logboekopslag : alle omgevingen moeten een samenhangende bewaarstrategie voor logboekopslag, ontwerp en implementatie hebben om een consistente toolset (bijvoorbeeld SIEM-systemen zoals Azure Sentinel), veelvoorkomende query's, onderzoek en forensische playbooks te vergemakkelijken. Azure Policy kan worden gebruikt voor het instellen van diagnostische instellingen.

Controle en controle van logboeken : de operationele taken rond identiteitsbewaking moeten consistent zijn en eigenaren in elke omgeving hebben. Zoals hierboven beschreven, streeft u ernaar om deze verantwoordelijkheden in omgevingen te consolideren voor zover toegestaan door nalevings- en isolatievereisten voor regelgeving.

De volgende scenario's moeten expliciet worden bewaakt en onderzocht:

  • Verdachte activiteit : alle risicogebeurtenissen van Microsoft Entra moeten worden gecontroleerd op verdachte activiteiten. Alle tenants moeten de netwerklocaties met de naam definiëren om ruisdetecties op locatiegebaseerde signalen te voorkomen. Microsoft Entra ID Protection is systeemeigen geïntegreerd met Azure Security Center. Het wordt aanbevolen dat elk risicodetectieonderzoek alle omgevingen omvat die de identiteit heeft ingericht (bijvoorbeeld als een menselijke identiteit een actieve risicodetectie heeft in de bedrijfstenant, moet het team dat de klantgerichte tenant beheert ook de activiteit van het bijbehorende account in die omgeving onderzoeken).

  • UEBA-waarschuwingen (User Entity Behavior Analytics) - UEBA moet worden gebruikt om inzichtelijke informatie te krijgen op basis van anomaliedetectie. Microsoft Microsoft 365 Defender voor Cloud-apps biedt UEBA in de cloud. Klanten kunnen on-premises UEBA integreren vanuit Microsoft Microsoft 365 Defender for Identity. MCAS leest signalen van Microsoft Entra ID Protection.

  • Activiteiten van accounts voor noodtoegang : alle toegangsaccounts die gebruikmaken van accounts voor noodtoegang, moeten worden bewaakt en waarschuwingen worden gemaakt voor onderzoek. Deze bewaking moet het volgende omvatten:

    • Aanmeldingen

    • Referentiebeheer

    • Alle updates voor groepslidmaatschappen

    • Toepassingstoewijzingen

  • Factureringsbeheeraccounts : gezien de gevoeligheid van accounts met factureringsbeheerrollen in Azure EA of MCA, en hun aanzienlijke bevoegdheden, is het raadzaam om te controleren en te waarschuwen:

    • Aanmeldingspogingen per account met factureringsrollen.

    • Elke poging om te verifiëren bij andere toepassingen dan de EA-portal.

    • Elke poging om te verifiëren bij andere toepassingen dan Azure Resource Management als u toegewezen accounts gebruikt voor MCA-factureringstaken.

    • Toewijzing aan Azure-resources met behulp van toegewezen accounts voor MCA-factureringstaken.

  • Activiteit van bevoorrechte rol : beveiligingswaarschuwingen configureren en controleren die worden gegenereerd door Microsoft Entra PIM. Als het vergrendelen van directe RBAC-toewijzingen niet volledig kan worden afgedwongen met technische besturingselementen (bijvoorbeeld de rol Eigenaar moet worden verleend aan productteams om hun werk te doen), controleert u de directe toewijzing van bevoorrechte rollen buiten PIM door waarschuwingen te genereren wanneer een gebruiker rechtstreeks wordt toegewezen voor toegang tot het abonnement met Azure RBAC.

  • Klassieke roltoewijzingen : organisaties moeten de moderne Azure RBAC-rolinfrastructuur gebruiken in plaats van de klassieke rollen. Als gevolg hiervan moeten de volgende gebeurtenissen worden bewaakt:

    • Toewijzing aan klassieke rollen op abonnementsniveau

  • Tenantbrede configuraties : elke configuratieservice voor de hele tenant moet waarschuwingen genereren in het systeem.

    • Aangepaste domeinen bijwerken

    • Huisstijl bijwerken

    • Microsoft Entra B2B allow/block list

    • Door Microsoft Entra B2B toegestane id-providers (SAML IDPs via directe federatie of sociale aanmeldingen)

    • Wijzigingen in beleid voor voorwaardelijke toegang

  • Toepassings- en service-principalobjecten

    • Nieuwe toepassingen/service-principals waarvoor mogelijk beleid voor voorwaardelijke toegang is vereist

    • Activiteit voor toepassingstoestemming

  • Activiteiten van beheergroepen : de volgende identiteitsaspecten van beheergroepen moeten worden bewaakt:

    • RBAC-roltoewijzingen bij de MG

    • Azure-beleid toegepast op de MG

    • Abonnementen die zijn verplaatst tussen MG's

    • Wijzigingen in beveiligingsbeleid in de hoofdbeheergroep

  • Aangepaste rollen

    • Updates van de aangepaste roldefinities

    • Nieuwe aangepaste rollen gemaakt

  • Aangepaste scheiding van takenregels : als uw organisaties regels voor scheiding van taken hebben ingesteld, gebruikt u niet-compatibele toegangspakketten van Microsoft Entra Entitlement Management om scheiding van taken af te dwingen en maakt u waarschuwingen of configureert u periodieke beoordelingen om schendingen door beheerders te detecteren.

Andere bewakingsoverwegingen : Azure-abonnementen die resources bevatten die worden gebruikt voor logboekbeheer, moeten worden beschouwd als kritieke infrastructuur (laag 0) en worden vergrendeld voor het Security Operations-team van de bijbehorende omgeving. Overweeg het gebruik van hulpprogramma's zoals Azure Policy om aanvullende besturingselementen af te dwingen voor deze abonnementen.

Operationele hulpprogramma's

Ontwerpoverwegingen voor hulpprogramma's voor meerdere omgevingen :

  • Indien mogelijk moeten operationele hulpprogramma's die worden gebruikt voor meerdere tenants, worden ontworpen om te worden uitgevoerd als een Microsoft Entra-toepassing met meerdere tenants om te voorkomen dat meerdere exemplaren op elke tenant opnieuw worden geïmplementeerd en operationele inefficiënties worden voorkomen. De implementatie moet autorisatielogica bevatten om ervoor te zorgen dat isolatie tussen gebruikers en gegevens behouden blijft.

  • Voeg waarschuwingen en detecties toe om automatisering tussen omgevingen (bijvoorbeeld identiteitsinrichting) en drempelwaarden voor fail-safes te bewaken. U wilt bijvoorbeeld een waarschuwing als het ongedaan maken van de inrichting van gebruikersaccounts een specifiek niveau bereikt, omdat dit kan duiden op een bug of operationele fout die grote gevolgen kan hebben.

  • Elke automatisering die taken voor meerdere omgevingen organiseert, moet worden uitgevoerd als een systeem met hoge bevoegdheden. Dit systeem moet worden gekoppeld aan de hoogste beveiligingsomgeving en moet worden opgehaald uit externe bronnen als gegevens uit andere omgevingen vereist zijn. Gegevensvalidatie en drempelwaarden moeten worden toegepast om de systeemintegriteit te behouden. Een veelvoorkomende taak voor meerdere omgevingen is identiteitslevenscyclusbeheer om identiteiten te verwijderen uit alle omgevingen voor een beëindigde werknemer.

HULPPROGRAMMA's voor IT-servicebeheer : organisaties die GEBRUIKMAKEN van ITSM-systemen (IT Service Management), zoals ServiceNow, moeten de activeringsinstellingen voor microsoft Entra PIM-rollen configureren om een ticketnummer aan te vragen als onderdeel van de activeringsdoeleinden.

Op dezelfde manier kan Azure Monitor worden geïntegreerd met ITSM-systemen via de IT Service Management Connector.

Operationele procedures : minimaliseer operationele activiteiten die directe toegang tot de omgeving tot menselijke identiteiten vereisen. Modelleer ze in plaats daarvan als Azure Pipelines die algemene bewerkingen uitvoeren (voeg bijvoorbeeld capaciteit toe aan een PaaS-oplossing, voer diagnostische gegevens uit, enzovoort) en model directe toegang tot de Azure Resource Manager-interfaces om scenario's met 'glas breken' te maken.

Uitdagingen met betrekking tot bewerkingen

  • De activiteit van bewaking van service-principals is beperkt voor sommige scenario's

  • Microsoft Entra PIM-waarschuwingen hebben geen API. De oplossing is om regelmatig deze PIM-waarschuwingen te bekijken.

  • Azure EA Portal biedt geen bewakingsmogelijkheden. De oplossing is om toegewezen beheeraccounts te hebben en de accountactiviteit te controleren.

  • MCA biedt geen auditlogboeken voor factureringstaken. De oplossing is om toegewezen beheeraccounts te hebben en de accountactiviteit te controleren.

  • Sommige services in Azure die nodig zijn om de omgeving te gebruiken, moeten opnieuw worden geïmplementeerd en opnieuw worden geconfigureerd in omgevingen omdat ze niet meerdere tenants of meerdere clouds kunnen zijn.

  • Er is geen volledige API-dekking in Microsoft Online Services om de infrastructuur als code volledig te realiseren. De oplossing is om API's zoveel mogelijk te gebruiken en portals voor de rest te gebruiken. Dit opensource-initiatief om u te helpen bij het bepalen van een benadering die mogelijk geschikt is voor uw omgeving.

  • Er is geen programmatische mogelijkheid om resourcetenants te detecteren die gedelegeerde abonnementstoegang hebben tot identiteiten in een beherende tenant. Als een e-mailadres bijvoorbeeld een beveiligingsgroep in de contoso.com tenant heeft ingeschakeld voor het beheren van abonnementen in de fabrikam.com tenant, hebben beheerders in de contoso.com geen API om te ontdekken dat deze delegatie heeft plaatsgevonden.

  • Bewaking van specifieke accountactiviteiten (bijvoorbeeld break-glass account, factureringsbeheeraccount) is niet standaard opgegeven. De risicobeperking is bedoeld voor klanten om hun eigen waarschuwingsregels te maken.

  • Bewaking van configuratie voor de hele tenant is niet standaard beschikbaar. De risicobeperking is bedoeld voor klanten om hun eigen waarschuwingsregels te maken.

Volgende stappen