Bewerken

Beveiligingsoverwegingen voor zeer gevoelige IaaS-apps in Azure

Azure Disk Encryption
Azure Firewall
Azure Key Vault
Microsoft Defender for Cloud
Azure Virtual Network

Er zijn veel beveiligingsoverwegingen voor het implementeren van IaaS-apps (Infrastructure-as-a-Service) in Azure. Dit artikel bouwt voort op referentiearchitecturen voor workloads op basis van virtuele machines en hybride netwerkinfrastructuren om zich te richten op beveiliging voor zeer gevoelige IaaS-workloads in Azure, op basis van de basisprincipes van Azure-beveiliging.

Zie ook het beveiligingsoverzicht van virtuele Azure-machines en aanbevolen beveiligingsprocedures voor IaaS-workloads in Azure.

Azure-VM's

Het rekenplatform van Azure is gebaseerd op machinevirtualisatie. Een hypervisor wordt uitgevoerd op de fysieke hardware van elk Azure-knooppunt of netwerkeindpunt en maakt een variabel aantal virtuele Hyper-V-gastmachines (VM's) in het knooppunt. Alle gebruikerscode wordt uitgevoerd op de VM's. Zie Een Virtuele Linux-machine uitvoeren in Azure of een Windows-VM uitvoeren in Azure voor eenvoudige instructies voor de implementatie van Azure-VM's. De meeste implementatieprocessen zijn hetzelfde voor de twee besturingssystemen (BESTURINGSSYSTEMen), maar besturingssysteemspecifieke hulpprogramma's zoals schijfversleuteling kunnen verschillen.

U kunt Microsoft Defender voor Cloud voor VM-patchbeheer gebruiken en antimalwarehulpprogramma's implementeren en bewaken. U kunt ook uw eigen patch- en antimalwarehulpprogramma's van derden beheren. Dit is gebruikelijk bij het uitbreiden of migreren van bestaande infrastructuren naar Azure.

Microsoft biedt DDoS-beveiliging (Basic Distributed Denial of Service) als onderdeel van het Azure-platform. Apps met openbare eindpunten kunnen Standard Azure DDoS Protection gebruiken voor extra beveiliging. Zeer gevoelige workloads hebben echter meestal geen openbare eindpunten en kunnen alleen worden geopend vanaf specifieke locaties via een VPN (virtueel particulier netwerk) of een geleasede lijn.

N-tier architecturen

Veel IaaS-toepassingen bestaan uit meerdere lagen, zoals een weblaag, bedrijfslaag en gegevenslaag, die worden gehost op meerdere VM's. Belangrijke aspecten van het implementeren van n-tier-app-architecturen op Azure-VM's zijn onder andere:

  • Hoge beschikbaarheid (HA). Ha-apps moeten meer dan 99,9% van de tijd beschikbaar zijn. Het plaatsen van vm's in de laag in verschillende Azure-beschikbaarheidszones (AZ's) zorgt voor hoge beschikbaarheid, omdat AZ's een of meer datacenters omvatten, waardoor tolerantie wordt geboden door weerstand tegen storingen in datacenters. Regio's die geen ondersteuning bieden voor AZ's, kunnen beschikbaarheidssets (ASs) gebruiken, waarmee VM's worden gedistribueerd over meerdere geïsoleerde hardwareknooppunten.
  • Taakverdeling. Load balancers verdelen verkeer tussen VM's om de belasting te verdelen en voor tolerantie wanneer een VIRTUELE machine uitvalt. U hebt geen load balancers nodig als de toepassing taakverdeling beheert en de afzonderlijke VM's bekend zijn bij de aanroeper.
  • Virtuele netwerken. Virtuele netwerken en subnetten segmenteren uw netwerk, waardoor eenvoudiger beveiligingsbeheer en geavanceerde routering mogelijk is.
  • Domain Name System (DNS). Azure DNS biedt een maximaal beschikbare en beveiligde DNS-service. Met een privézone in Azure DNS kunt u aangepaste domeinen in uw virtuele netwerken gebruiken.

Back-ups en herstellen

Ter bescherming tegen menselijke fouten, het verwijderen van schadelijke gegevens en ransomware moet u ten minste een back-up maken van uw vm's in de gegevenslaag. Met Azure Backup kunt u back-ups maken van versleutelde VM's en deze herstellen als deze toegang heeft tot de versleutelingssleutels in Azure Key Vault.

Voor de web- en bedrijfslagen kunt u regels voor automatisch schalen van virtuele-machineschaalsets gebruiken om gecompromitteerde VM's automatisch te vernietigen en nieuwe VM-exemplaren te implementeren vanuit een basisinstallatiekopieën.

Rekenisolatie

Op elk Azure-knooppunt of netwerkeindpunt zorgen de hypervisor en een speciaal hoofdbesturingssystemen ervoor dat gast-VM's geen toegang hebben tot de fysieke hostserver en dat gebruikerscode alleen wordt uitgevoerd op gast-VM's. Deze isolatie voorkomt dat gebruikers onbewerkte lees-, schrijf- of uitvoertoegang tot het systeem verkrijgen en het risico op het delen van resources beperken. Azure beschermt tegen alle bekende side-channel-aanvallen en lawaaierige buren via de hypervisor en een geavanceerd algoritme voor VM-plaatsing. Zie Compute-isolatie voor meer informatie.

Voor zeer gevoelige workloads kunt u extra beveiliging toevoegen tegen side-channel-aanvallen met geïsoleerde VM's of toegewezen hosts.

Geïsoleerde VM's

Geïsoleerde VM's zijn grote VM-grootten die zijn geïsoleerd voor een specifiek hardwaretype en toegewezen aan één klant. Het gebruik van een geïsoleerde VM-grootte garandeert dat uw VIRTUELE machine de enige is die wordt uitgevoerd op een specifiek serverexemplaren. U kunt de resources van geïsoleerde VM's verder onderverdelen met behulp van ondersteuning voor Azure voor geneste virtuele machines.

De minimale grootte van een geïsoleerde VM is 64 virtuele CPU-kernen en 256 GiB aan geheugen. Deze VM's zijn veel groter dan de meeste n-tier-toepassingen vereisen en kunnen een grote kostenoverhead tot gevolg hebben. Als u de overhead wilt verminderen, kunt u meerdere app-lagen uitvoeren op één VIRTUELE machine met geneste virtualisatie of in verschillende processen of containers. U moet nog steeds verschillende VM's in AZ's implementeren voor tolerantie en gedemilitariseerde zoneapparaten (DMZ) uitvoeren op afzonderlijke VM's. Het combineren van meerdere apps op één infrastructuur om economische redenen kan ook conflicteren met het scheidingsbeleid voor organisatie-apps.

Naarmate de mogelijkheden van Azure-regio's in de loop van de tijd worden uitgebreid, kan Azure ook isolatiegaranties van bepaalde VM-grootten verwijderen, met een kennisgeving van één jaar.

Azure Dedicated Hosts

Azure Dedicated Host is de voorkeursoplossing voor rekenisolatie voor zeer gevoelige workloads. Een toegewezen host is een fysieke server die is toegewezen aan één klant voor het hosten van meerdere VM's. Naast het isoleren van VM's kunt u met toegewezen hosts onderhoud en VM-plaatsing beheren om lawaaierige buren te voorkomen.

Toegewezen hosts

Toegewezen hosts hebben dezelfde minimale grootte en veel van dezelfde overwegingen voor de grootte als geïsoleerde VM's. Een toegewezen host kan echter VM's hosten die zich in verschillende virtuele netwerken bevinden om te voldoen aan beleid voor scheiding van toepassingen. U moet nog steeds DMZ-VM's uitvoeren op een andere host om aanvallen aan de zijkant van een gecompromitteerde VM in de DMZ te voorkomen.

Versleuteling

Gegevensversleuteling is een belangrijk onderdeel van het beveiligen van workloads. Versleuteling codeert informatie zodat alleen geautoriseerde ontvangers deze kunnen decoderen met behulp van een sleutel of certificaat. Versleuteling omvat schijfversleuteling, voor data encryption-at-rest en TLS (Transport Level Security) voor versleuteling in transit via netwerken.

Azure Key Vault

U kunt versleutelingssleutels en certificaten beveiligen door ze op te slaan in Azure Key Vault, een HSM-oplossing (Cloud Hardware Security Module) die is gevalideerd voor Federal Information Processing Standards (FIPS) 140-2 Level 2. Zie Beveiligde toegang tot een sleutelkluis voor aanbevolen procedures om alleen geautoriseerde toepassingen en gebruikers toegang te geven tot Key Vault.

Als u sleutels in Key Vault wilt beveiligen, kunt u voorlopig verwijderen inschakelen, waardoor verwijderde sleutels kunnen worden hersteld. Voor extra beveiliging kunt u een back-up maken van afzonderlijke sleutels naar een versleuteld bestand dat u kunt gebruiken om de sleutels te herstellen, mogelijk naar een andere Azure-regio in dezelfde geografie.

Wanneer u SQL Server host op een virtuele machine, kunt u de SQL Server-connector voor Microsoft Azure Key Vault gebruiken om sleutels op te halen voor TDE (Transparent Data Encryption), versleuteling op kolomniveau (CLE) en back-upversleuteling. Zie Azure Key Vault-integratie configureren voor SQL Server op virtuele Azure-machines voor meer informatie.

Azure Disk Encryption

Azure Disk Encryption maakt gebruik van een externe BitLocker-sleutelbeveiliging om volumeversleuteling te bieden voor het besturingssysteem en de gegevensschijven van Azure-VM's en kan worden geïntegreerd met Azure Key Vault om u te helpen bij het beheren en beheren van schijfversleutelingssleutels en -geheimen. Elke VIRTUELE machine genereert zijn eigen versleutelingssleutels en slaat deze op in Azure Key Vault. Als u Azure Key Vault wilt configureren om Azure Disk Encryption in te schakelen, raadpleegt u Een sleutelkluis maken en configureren voor Azure Disk Encryption.

Voor zeer gevoelige workloads moet u ook een sleutelversleutelingssleutel (KEK) gebruiken voor een extra beveiligingslaag. Wanneer u een KEK opgeeft, gebruikt Azure Disk Encryption die sleutel om de versleutelingsgeheimen te verpakken voordat u naar Key Vault schrijft. U kunt een KEK genereren in Azure Key Vault, maar een veiligere methode is het genereren van een sleutel in uw on-premises HSM en deze importeren in Azure Key Vault. Dit scenario wordt vaak Bring Your Own Key of BYOK genoemd. Omdat de geïmporteerde sleutels de HSM-grens niet kunnen verlaten, zorgt het genereren van de sleutel in uw HSM ervoor dat u volledig beheer hebt over de versleutelingssleutels.

Met HSM beveiligde versleuteling

Zie HSM-beveiligde sleutels genereren en overdragen voor Azure Key Vault voor meer informatie over met HSM beveiligde sleutels.

Versleuteling van netwerkverkeer

Netwerkprotocollen zoals HTTPS versleutelen gegevens tijdens overdracht met certificaten. Client-naar-toepassingsverkeer maakt meestal gebruik van een certificaat van een vertrouwde certificeringsinstantie (CA). Interne apps kunnen een certificaat van een interne CA of een openbare CA zoals DigiCert of GlobalSign gebruiken. Communicatie tussen lagen maakt doorgaans gebruik van een certificaat dat is uitgegeven door een interne CA of een zelfondertekend certificaat. Azure Key Vault kan geschikt zijn voor elk van deze certificaattypen. Zie Methoden voor het maken van certificaten voor meer informatie over het maken van verschillende certificaattypen.

Azure Key Vault kan fungeren als een zelfondertekende certificaat-CA voor verkeer van laag naar laag. De Key Vault VM-extensie biedt bewaking en automatische vernieuwing van opgegeven certificaten op VM's, met of zonder de persoonlijke sleutel, afhankelijk van de use-case. Als u de Key Vault-VM-extensie wilt gebruiken, raadpleegt u de extensie voor virtuele Machines van Key Vault voor Linux of Key Vault voor Windows.

Key Vault kan ook sleutels opslaan voor netwerkprotocollen die geen certificaten gebruiken. Voor aangepaste workloads kan het uitvoeren van scripts een aangepaste scriptextensie nodig zijn waarmee een sleutel uit Key Vault wordt opgehaald en opgeslagen voor toepassingen die moeten worden gebruikt. Apps kunnen ook de beheerde identiteit van een virtuele machine gebruiken om geheimen rechtstreeks uit Key Vault op te halen.

Netwerkbeveiliging

Netwerkbeveiligingsgroepen (NSG's) filteren verkeer tussen resources in virtuele Azure-netwerken. NSG-beveiligingsregels staan netwerkverkeer naar of van Azure-resources toe of weigeren op basis van IP-adressen en poorten. NSG's blokkeren standaard inkomend verkeer van internet, maar staan uitgaande verbindingen van VM's naar internet toe. Als u onbedoeld uitgaand verkeer wilt voorkomen, voegt u een aangepaste regel toe met de laagste prioriteit, 4096, om al het binnenkomende en uitgaande verkeer te blokkeren. Vervolgens kunt u regels met een hogere prioriteit toevoegen om specifiek verkeer toe te staan.

NSG's maken stroomrecords voor bestaande verbindingen en staan communicatie toe of weigeren op basis van de verbindingsstatus van de stroomrecord. Met de stroomrecord kan een NSG stateful zijn. Als u bijvoorbeeld een uitgaande beveiligingsregel opgeeft voor een adres via poort 443, is het niet nodig om ook een binnenkomende beveiligingsregel voor het antwoord op te geven. U hoeft alleen een binnenkomende beveiligingsregel op te geven als de communicatie extern wordt gestart.

Met de meeste Azure-services kunt u een servicetag voor een virtueel netwerk gebruiken in plaats van een NSG. Een servicetag vertegenwoordigt een groep IP-adresvoorvoegsels van een Azure-service en helpt de complexiteit te minimaliseren van frequente updates voor netwerkbeveiligingsregels. Met een Azure Key Vault-servicetag kan een VIRTUELE machine certificaten, sleutels en geheimen ophalen uit Azure Key Vault.

Een andere manier om netwerkbeveiliging te beheren, is via routering van virtueel netwerkverkeer en geforceerde tunneling. Azure maakt automatisch systeemroutes en wijst de routes toe aan elk subnet in een virtueel netwerk. U kunt geen systeemroutes maken of verwijderen, maar u kunt bepaalde systeemroutes overschrijven met aangepaste routes. Met aangepaste routering kunt u verkeer routeren via een virtueel netwerkapparaat (NVA), zoals een firewall of proxy, of ongewenst verkeer verwijderen, wat vergelijkbaar is met het blokkeren van het verkeer met een NSG.

U kunt NVA's zoals Azure Firewall gebruiken om netwerkverkeer toe te staan, te blokkeren en te inspecteren. Azure Firewall is een beheerde, maximaal beschikbare platformfirewallservice. U kunt ook NVA's van derden implementeren vanuit Azure Marketplace. Zie Virtuele netwerkapparaten implementeren om deze NVA's maximaal beschikbaar te maken.

Toepassingsbeveiligingsgroepen

Als u verkeer wilt filteren tussen toepassingslagen binnen een virtueel netwerk, gebruikt u toepassingsbeveiligingsgroepen (ASG's). Met ASG's kunt u netwerkbeveiliging configureren als een uitbreiding van de structuur van een toepassing, zodat u VM's kunt groeperen en netwerkbeveiligingsbeleid kunt definiëren op basis van de groepen. U kunt uw beveiligingsbeleid op schaal opnieuw gebruiken zonder expliciete IP-adressen handmatig te onderhouden.

Toepassingsbeveiligingsgroepen

Aangezien ASG's worden toegepast op een netwerkinterface in plaats van een subnet, maken ze microsegmentatie mogelijk. U kunt nauwkeurig bepalen welke VM's met elkaar kunnen communiceren, zelfs het verkeer tussen VM's in dezelfde laag blokkeren en het eenvoudig maken om een VIRTUELE machine in quarantaine te plaatsen door ASG's van die VM te verwijderen.

Hybride netwerken

Hybride architecturen verbinden on-premises netwerken met openbare clouds zoals Azure. Er zijn verschillende manieren om on-premises netwerken te verbinden met toepassingen die worden uitgevoerd in Azure:

  • Openbaar eindpunt via internet. U kunt vertrouwen op identiteit, beveiliging op transportniveau (HTTPS) en de toepassingsgateway om de toepassing te beveiligen, mogelijk in combinatie met een firewall. Voor zeer gevoelige workloads wordt het blootstellen van een openbaar eindpunt via internet echter niet aanbevolen.
  • Azure- of externe VPN-gateway. U kunt een on-premises netwerk verbinden met Azure met behulp van een Azure VPN-gateway. Verkeer wordt nog steeds via internet verzonden, maar via een versleutelde tunnel die gebruikmaakt van TLS. U kunt ook een gateway van derden uitvoeren op een VIRTUELE machine als u specifieke vereisten hebt die niet worden ondersteund door de Azure VPN-gateway.
  • ExpressRoute. ExpressRoute-verbindingen gebruiken een persoonlijke, exclusieve verbinding via een connectiviteitsprovider van derden. De privéverbinding breidt uw on-premises netwerk uit naar Azure en biedt schaalbaarheid en een betrouwbare SLA (Service Level Agreement).
    • ExpressRoute met VPN-failover. Deze optie maakt gebruik van ExpressRoute in normale omstandigheden, maar voert een failover uit naar een VPN-verbinding als er sprake is van een verlies van connectiviteit in het ExpressRoute-circuit, wat hogere beschikbaarheid biedt.
    • VPN via ExpressRoute. Deze optie is het beste voor zeer gevoelige workloads. ExpressRoute biedt een privécircuit met schaalbaarheid en betrouwbaarheid en VPN biedt een extra beveiligingslaag waarmee de versleutelde verbinding in een specifiek virtueel Azure-netwerk wordt beëindigd.

Zie Een oplossing kiezen voor het verbinden van een on-premises netwerk met Azure voor meer informatie over het kiezen tussen verschillende typen hybride connectiviteit.

Een DMZ implementeren

Verbinding maken on-premises en Azure-omgevingen biedt on-premises gebruikers toegang tot Azure-toepassingen. Een perimeternetwerk of gedemilitariseerde zone (DMZ) biedt extra beveiliging voor zeer gevoelige workloads.

Een architectuur zoals die in netwerk-DMZ tussen Azure en een on-premises datacenter implementeert alle DMZ- en toepassingsservices in hetzelfde virtuele netwerk, met NSG-regels en door de gebruiker gedefinieerde routes om de DMZ- en toepassingssubnetten te isoleren. Deze architectuur kan het beheersubnet beschikbaar maken via openbaar internet, om apps te beheren, zelfs als de on-premises gateway niet beschikbaar is. Voor zeer gevoelige workloads moet u echter alleen toestaan dat de gateway wordt overgeslagen in een break glass-scenario. Een betere oplossing is om Azure Bastion te gebruiken, waardoor toegang rechtstreeks vanuit Azure Portal mogelijk is, terwijl de blootstelling van openbare IP-adressen wordt beperkt.

U kunt ook Just-In-Time -VM-toegang (JIT) gebruiken voor extern beheer terwijl de blootstelling van openbare IP-adressen wordt beperkt. Met toegang tot JIT-VM's blokkeert een NSG standaard poorten voor extern beheer, zoals RDP (Remote Desktop Protocol) en SSH (Secure Shell). Op aanvraag schakelt JIT-VM-toegang de poort alleen in voor een opgegeven tijdvenster en mogelijk voor een specifiek IP-adres of -bereik. JIT-toegang werkt ook voor VM's met alleen privé-IP-adressen. U kunt Azure Bastion gebruiken om verkeer naar een VIRTUELE machine te blokkeren totdat JIT VM-toegang is ingeschakeld.

Als u meer toepassingen wilt implementeren, kunt u een sternetwerktopologie in Azure gebruiken, met de DMZ in het virtuele hubnetwerk en de toepassingen in virtuele spoke-netwerken. Het virtuele hubnetwerk kan een VPN- en/of ExpressRoute-gateway, firewall NVA, beheerhosts, identiteitsinfrastructuur en andere gedeelde services bevatten. De virtuele spoke-netwerken zijn verbonden met de hub met peering van virtuele netwerken. Een virtueel Azure-netwerk staat transitieve routering via de hub niet toe van de ene spoke naar de andere. Spoke-to-spoke-verkeer is alleen mogelijk via de firewallapparaten in de hub. Met deze architectuur worden toepassingen effectief van elkaar geïsoleerd.

Implementatie in meerdere regio's

Voor bedrijfscontinuïteit en herstel na noodgevallen moet uw toepassing mogelijk worden geïmplementeerd in meerdere Azure-regio's, wat van invloed kan zijn op de gegevenslocatie en -beveiliging. Zie Een N-tier-toepassing uitvoeren in meerdere Azure-regio's voor hoge beschikbaarheid voor een referentiearchitectuur voor implementaties met meerdere regio's.

Regionale paren

Een Azure-geografie is een gedefinieerd gebied van de wereld met ten minste één Azure-regio, elk met een of meer datacenters. Elke Azure-regio wordt gekoppeld aan een andere regio in dezelfde geografie in een regionaal paar. Regionale paren worden niet beide tegelijkertijd bijgewerkt en als een noodgeval beide regio's raakt, krijgt een van de regio's prioriteit om eerst weer online te komen. Voor bedrijfscontinuïteit moet u ten minste zeer gevoelige apps implementeren op regionale paren als u in meerdere regio's implementeert.

Zie BCDR (Bedrijfscontinuïteit en herstel na noodgevallen): gekoppelde Azure-regio's voor meer informatie. Het technisch document Compatibele gegevenslocatie en -beveiliging bereiken met Azure bespreekt gegevenslocatie en wat u moet doen om te voldoen aan de vereisten voor gegevenslocatie.

Replicatie tussen regio's

In IaaS-architecturen is het repliceren van gegevens tussen regio's de verantwoordelijkheid van de toepassing. Het meest voorkomende replicatiescenario maakt gebruik van databasereplicatietechnologieën die zijn ingebouwd in het databaseserverproduct, zoals SQL Server AlwaysOn-beschikbaarheidsgroepen, Oracle Data Guard of MySQL-replicatie.

Het instellen van replicatie tussen IaaS-databaseservers is niet eenvoudig en u moet rekening houden met vereisten voor bedrijfscontinuïteit. Azure Database-services zoals Azure SQL Database, Azure Database for MySQL en Azure Cosmos DB maken replicatie tussen regio's eenvoudiger, maar voldoen mogelijk niet aan de beveiligingsvereisten voor zeer gevoelige workloads.

Zie voor meer informatie en richtlijnen voor SQL Server- en Oracle-implementaties met meerdere regio's:

Peering tussen regio's

U kunt beveiligde communicatie tussen virtuele netwerken in verschillende regio's inschakelen met behulp van wereldwijde peering voor virtuele netwerken. Globale peering werkt hetzelfde als peering binnen regio's. Het verkeer tussen regio's loopt via de Microsoft-backbone, gaat niet via internet en is geïsoleerd van ander verkeer. Voor meer beveiliging kunt u VPN NVA's in beide regio's implementeren en door de gebruiker gedefinieerde routes gebruiken om verkeer tussen regio's via de NVA's af te dwingen, vergelijkbaar met het implementeren van een DMZ.

Routering van failoververkeer

Met openbare eindpunten kunt u Traffic Manager of Azure Front Door gebruiken om verkeer naar de actieve regio of dichtstbijzijnde regio te leiden in een configuratie voor actieve failover. Traffic Manager en Azure Front Door vereisen echter beide openbare eindpunten om de beschikbaarheid te bewaken en de bijbehorende DNS-vermeldingen zijn openbaar. Voor zeer gevoelige workloads is de alternatieve oplossing het implementeren van DNS on-premises en het wijzigen van de vermeldingen in de actieve regio voor failover.

Beheer en governance

Het beveiligen van uw zeer gevoelige IaaS-apps vereist meer dan alleen het implementeren van de juiste architecturen en het implementeren van netwerkbeveiligingsregels. Omdat cloudomgevingen eenvoudig worden gewijzigd, is het vooral belangrijk om ervoor te zorgen dat wijzigingen alleen met bepaalde machtigingen en binnen de grenzen van beveiligingsbeleid kunnen worden aangebracht. U moet bijvoorbeeld voorkomen dat een kwaadwillende actor een netwerkbeveiligingsregel kan wijzigen om verkeer van internet toe te staan.

Als u workloads in Azure wilt implementeren, hebt u een of meer beheeraccounts nodig. Het beveiligen van beheeraccounts is essentieel voor het beveiligen van uw workloads. Zie Beveiligde bevoegde toegang voor hybride en cloudimplementaties in Microsoft Entra ID voor meer informatie.

Gebruik de resources in uw beheersubnet om app-laag alleen toegang te verlenen aan personen die die laag moeten beheren. U kunt bijvoorbeeld Microsoft Identity Manager gebruiken met Microsoft Entra-id. Voor cloudeigen scenario's heeft Microsoft Entra Privileged Identity Management (PIM) echter de voorkeur.

Er zijn verschillende andere manieren om Azure-rollen en -beleidsregels te beheren:

  • Met op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) voor Azure-resources kunt u ingebouwde of aangepaste rollen toewijzen aan gebruikers, zodat ze alleen de bevoegdheden hebben die ze nodig hebben. U kunt Azure RBAC combineren met PIM om een gecontroleerde goedkeuringswerkstroom te implementeren waarmee bevoegdheden gedurende een beperkte periode worden verhoogd.
  • Beleidsregels dwingen bedrijfsregels, standaarden en SLA's af. Azure Policy is een Azure-service die beleidsregels maakt, toewijst en beheert, en uw resources evalueert voor beleidsnaleving.
  • Azure Blueprints combineert roltoewijzingen, beleidstoewijzingen en implementatiesjablonen om een set repliceerbare Azure-resources te definiëren die de standaarden, patronen en vereisten van een organisatie implementeren en volgen. Blauwdrukken zijn een declaratieve manier om de implementatie van resourcesjablonen en andere artefacten te organiseren. U kunt zelf blauwdrukken maken of bestaande blauwdrukken gebruiken. Met de blauwdruk iso 27001 voor gedeelde services wordt bijvoorbeeld een gedeelde serviceshub geïmplementeerd die u kunt wijzigen en uitbreiden naar de vereisten van uw organisatie.

Controleren

Microsoft Defender voor Cloud biedt bewaking en waarschuwingen waarmee u de beveiliging van uw omgeving kunt behouden. De gratis service controleert automatisch op beveiligingsproblemen, zoals ontbrekende besturingssysteempatches, onjuiste configuratie van beveiliging en basisnetwerkbeveiliging. De betaalde versie van Standard biedt extra functies, zoals gedragsanalyse, Adaptieve netwerkbeveiliging en JIT-VM-toegang. Zie Functiedekking voor computers voor een volledige lijst met functies. Defender voor Cloud biedt ook beveiliging tegen bedreigingen voor andere resources, zoals Azure Key Vault.

U kunt Azure Monitor gebruiken voor verdere bewaking en analyse. Als u identiteit en toegang wilt bewaken, kunt u activiteitenlogboeken van Microsoft Entra routeren naar Azure Monitor. U kunt ook VM's, netwerken en Azure Firewall bewaken en geïmporteerde logboeken analyseren met krachtige logboekquerymogelijkheden. U kunt Azure Monitor integreren met uw SIEM (Security Information and Event Manager), wat een SIEM van derden of Microsoft Sentinel kan zijn.