Privé-eindpuntverbindingen tussen tenants in Azure beperken
Klanten gebruiken steeds vaker privé-eindpunten in hun tenants om privé en veilig verbinding te maken met hun PaaS-services (Platform as a Service). Privé-eindpunten kunnen verbinding maken met services in Microsoft Entra-tenants. Voor beveiliging en naleving moet u mogelijk verbindingen tussen Microsoft Entra-tenants op uw privé-eindpunten blokkeren. In deze richtlijnen ziet u aanbevolen configuratieopties om verbindingen tussen privé-eindpunten tussen tenants te beperken of te voorkomen. Deze opties helpen u bij het maken van DLP-besturingselementen (Preventie van gegevenslekken) in uw Azure-omgeving.
Inleiding tot privé-eindpunten
Gebruik privé-eindpunten om het verkeer in uw Azure-omgeving te beheren met behulp van een bestaande netwerkperimeter. Er zijn echter scenario's waarin u alleen privé-eindpuntverbindingen binnen de Microsoft Entra-tenant van het bedrijf moet bewaren. In de volgende voorbeelden ziet u verbindingen die beveiligingsrisico's kunnen opleveren.
- Verbinding maken ion A: Een rogue beheerder maakt privé-eindpunten in het virtuele netwerk van de klant. Deze eindpunten zijn gekoppeld aan services die buiten de klantomgeving worden gehost, zoals een andere Microsoft Entra-tenant.
- Verbinding maken ion B: Een rogue beheerder maakt privé-eindpunten in andere Microsoft Entra-tenants die zijn gekoppeld aan services die worden gehost in de Microsoft Entra-tenant van de klant.
Afbeelding 1: Afbeelding van scenario's voor meerdere tenants voor privé-eindpunten.
Voor beide scenario's geeft u de resource-id van de service op en keurt u de privé-eindpuntverbinding handmatig goed. Gebruikers hebben ook op rollen gebaseerd toegangsbeheer (RBAC) nodig om deze acties uit te voeren.
Verbinding maken ions C en D in afbeelding 1 laten scenario's zien die klanten over het algemeen willen toestaan. De privé-eindpuntverbindingen worden bewaard binnen de Microsoft Entra-tenant van het bedrijf. Ze vertegenwoordigen geen beveiligingsrisico, dus deze twee scenario's worden niet behandeld in dit artikel.
De volgende informatie bevat opties voor het voorkomen van inrichting van privé-eindpunten in Microsoft Entra-tenants.
Privé-eindpunten weigeren die zijn gekoppeld aan services in andere tenants
Scenario 1: Een rogue beheerder vereist de volgende rechten in een abonnement in de Microsoft Entra-tenant van de klant.
- Microsoft.Network/virtualNetworks/join/action rights on a subnet with privateEndpointNetworkPolicies set to Disabled.
- Microsoft.Network/privateEndpoints/schrijftoegang tot een resourcegroep in de klantomgeving.
Met deze rechten kan een rogue beheerder een privé-eindpunt maken in de Microsoft Entra-tenant van de klant. Dit privé-eindpunt is gekoppeld aan een service in een afzonderlijk abonnement en de Microsoft Entra-tenant. In afbeelding 1 ziet u dit scenario als verbinding A.
Voor dit scenario stelt de gebruiker een externe Microsoft Entra-tenant en een Azure-abonnement in. Vervolgens maken ze een privé-eindpunt in de klantomgeving door handmatig de resource-id van de service op te geven. Ten slotte keurt de rogue-beheerder het privé-eindpunt goed op de gekoppelde service die wordt gehost in de externe Microsoft Entra-tenant om verkeer via de verbinding toe te staan.
Nadat de rogue-beheerder de privé-eindpuntverbinding goedkeurt, kunnen bedrijfsgegevens worden gekopieerd van het virtuele bedrijfsnetwerk naar een Azure-service op een externe Microsoft Entra-tenant. Dit beveiligingsrisico kan alleen optreden als toegang is verleend met behulp van Azure RBAC.
Risicobeperking voor scenario één
Gebruik het volgende Azure Policy om automatisch de mogelijkheid te blokkeren om een privé-eindpunt te maken in de Zakelijke Microsoft Entra-tenant die is gekoppeld aan een externe Azure-service.
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Network/privateEndpoints"
},
{
"anyOf": [
{
"count": {
"field": "Microsoft.Network/privateEndpoints/manualprivateLinkServiceConnections[*]",
"where": {
"allOf": [
{
"field": "Microsoft.Network/privateEndpoints/manualprivateLinkServiceConnections[*].privateLinkServiceId",
"notEquals": ""
},
{
"value": "[split(concat(first(field('Microsoft.Network/privateEndpoints/manualprivateLinkServiceConnections[*].privateLinkServiceId')), '//'), '/')[2]]",
"notEquals": "[subscription().subscriptionId]"
}
]
}
},
"greaterOrEquals": 1
},
{
"count": {
"field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*]",
"where": {
"allOf": [
{
"field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].privateLinkServiceId",
"notEquals": ""
},
{
"value": "[split(concat(first(field('Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].privateLinkServiceId')), '//'), '/')[2]]",
"notEquals": "[subscription().subscriptionId]"
}
]
}
},
"greaterOrEquals": 1
}
]
}
]
},
"then": {
"effect": "Deny"
}
Dit beleid weigert alle privé-eindpunten die buiten het abonnement van de gekoppelde service zijn gemaakt, zoals verbindingen A en D. Het beleid biedt ook de flexibiliteit om te gebruiken manualPrivateLinkServiceConnections en privateLinkServiceConnections.
U kunt dit beleid bijwerken, zodat privé-eindpunten alleen worden gemaakt in een bepaalde set abonnementen. U kunt deze wijziging aanbrengen door een list parameter toe te voegen en de "notIn": "[parameters('allowedSubscriptions')]" constructie te gebruiken. Maar deze benadering wordt niet aanbevolen, omdat dit betekent dat u de lijst met abonnementen voor dit beleid voortdurend moet bijhouden. Wanneer er een nieuw abonnement in uw tenant wordt gemaakt, moet de abonnements-id worden toegevoegd aan de parameter.
Wijs in plaats daarvan het beleid toe aan de beheergroep op het hoogste niveau en gebruik waar nodig uitzonderingen.
Overwegingen voor scenario één
Dit beleid blokkeert de mogelijkheid om privé-eindpunten te maken die zich in een ander abonnement bevinden dan de service zelf. Als deze eindpunten vereist zijn voor bepaalde use cases, gebruikt u beleidsvrijstellingen. Maak meer beleidsregels voor Data Factory en Azure Synapse om ervoor te zorgen dat beheerde privé-eindpunten die worden gehost op het beheerde virtuele netwerk alleen verbinding kunnen maken met services die worden gehost binnen uw Microsoft Entra-tenant.
Verbindingen weigeren van privé-eindpunten die zijn gemaakt in andere tenants
Scenario 2: Een rogue beheerder vereist schrijftoegang voor de service in de klantomgeving waarvoor een privé-eindpunt moet worden gemaakt.
Met dit recht kan een rogue beheerder een privé-eindpunt maken in een externe Microsoft Entra-tenant en -abonnement. Dit eindpunt is gekoppeld aan een service in de Microsoft Entra-tenant van de klant. In afbeelding 1 ziet u dit scenario als verbinding B.
In dit scenario moet de rogue-beheerder eerst een externe persoonlijke Microsoft Entra-tenant en een Azure-abonnement configureren. Vervolgens maken ze een privé-eindpunt in hun omgeving door handmatig de resource-id en groeps-id van de service op te geven in de Microsoft Entra-tenant van het bedrijf. Ten slotte keuren ze het privé-eindpunt van de gekoppelde service goed om verkeer via de verbinding tussen Microsoft Entra-tenants toe te staan.
Nadat de rogue beheerder of service-eigenaar het privé-eindpunt goedkeurt, worden gegevens geopend vanuit het externe virtuele netwerk.
Risicobeperking voor scenario twee
Gebruik servicespecifieke beleidsregels om dit scenario in de tenant van de klant te voorkomen. Privé-eindpuntverbindingen zijn subresources van de respectieve services en worden weergegeven onder hun eigenschappensectie. Niet-compatibele verbindingen weigeren met behulp van de volgende beleidsdefinitie:
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts/privateEndpointConnections"
},
{
"field": "Microsoft.Storage/storageAccounts/privateEndpointConnections/privateLinkServiceConnectionState.status",
"equals": "Approved"
},
{
"anyOf": [
{
"field": "Microsoft.Storage/storageAccounts/privateEndpointConnections/privateEndpoint.id",
"exists": false
},
{
"value": "[split(concat(field('Microsoft.Storage/storageAccounts/privateEndpointConnections/privateEndpoint.id'), '//'), '/')[2]]",
"notEquals": "[subscription().subscriptionId]"
}
]
}
]
},
"then": {
"effect": "Deny"
}
Dit beleid toont een voorbeeld voor Azure Storage. Repliceer dezelfde beleidsdefinitie voor andere services, zoals Key Vault, cognitieve services en SQL Server. Houd er rekening mee dat Azure-app Service deze beperking op dit moment niet ondersteunt.
Om de beheerbaarheid verder te verbeteren, bundelt u het servicespecifieke beleid in een initiatief. Het beleid weigert de goedkeuring van privé-eindpuntverbindingen met privé-eindpunten die buiten het abonnement van de respectieve service worden gehost. De weigering of verwijdering van privé-eindpuntverbindingen wordt niet geweigerd. Dit is het gewenste gedrag van klanten. Werkstromen voor automatische goedkeuring, zoals verbinding C, worden niet beïnvloed door dit beleid.
Maar de goedkeuring van compatibele privé-eindpuntverbindingen in de portal wordt geblokkeerd met deze methode. Dit blok treedt op omdat de gebruikersinterface van de portal de resource-id van het verbonden privé-eindpunt niet in de nettolading verzendt. Het is raadzaam om Azure Resource Manager, Azure PowerShell of Azure CLI te gebruiken om de privé-eindpuntverbinding goed te keuren.
Wijs ook het beleid toe aan de beheergroep op het hoogste niveau en gebruik waar nodig uitzonderingen.
Overwegingen voor scenario twee
Azure Synapse Analytics en Azure Data Factory bieden beheerde virtuele netwerken en beheerde privé-eindpunten. Vanwege deze nieuwe mogelijkheden blokkeert het beleid het veilige en privégebruik van deze services.
Het is raadzaam om een controle-effect te gebruiken in plaats van een weigeringseffect in de beleidsdefinitie die u in het scenario twee risicobeperking gebruikt. Deze wijziging helpt u bij het bijhouden van privé-eindpunten die worden gemaakt in afzonderlijke abonnementen en tenants. U kunt ook beleidsvrijstellingen gebruiken voor de respectieve gegevensplatformbereiken.
Azure Data Factory
Gebruik de volgende beleidsdefinitie om scenario één op het beheerde virtuele netwerk van Azure Data Factory te overwinnen:
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.DataFactory/factories/managedVirtualNetworks/managedPrivateEndpoints"
},
{
"anyOf": [
{
"field": "Microsoft.DataFactory/factories/managedVirtualNetworks/managedPrivateEndpoints/privateLinkResourceId",
"exists": false
},
{
"value": "[split(field('Microsoft.DataFactory/factories/managedVirtualNetworks/managedPrivateEndpoints/privateLinkResourceId'), '/')[2]]",
"notEquals": "[subscription().subscriptionId]"
}
]
}
]
},
"then": {
"effect": "[parameters('effect')]"
}
Dit beleid weigert beheerde privé-eindpunten die zijn gekoppeld aan services, die buiten het abonnement van de Data Factory worden gehost. U kunt dit beleid wijzigen om verbindingen met services toe te staan die worden gehost in een set abonnementen door een list parameter toe te voegen en met behulp van de "notIn": "[parameters('allowedSubscriptions')]" constructie. We raden deze wijziging aan voor het gegevensplatformbereik binnen de tenant of omgevingen waar services met beheerde virtuele netwerken en beheerde privé-eindpunten uitgebreid worden gebruikt.
Het is raadzaam dit beleid toe te wijzen aan de beheergroep op het hoogste niveau en waar nodig uitzonderingen te gebruiken. Breng voor het gegevensplatform deze wijzigingen aan en wijs het beleid toe aan de set abonnementen op het gegevensplatform.
Azure Synapse
Azure Synapse maakt ook gebruik van beheerde virtuele netwerken. We raden u aan een vergelijkbaar beleid toe te passen op het Data Factory-beleid voor scenario 1. Azure Synapse biedt geen beleidsalias voor beheerde privé-eindpunten. Er is echter een functie voor preventie van gegevensexfiltratie, die kan worden afgedwongen voor werkruimten met behulp van het volgende beleid:
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Synapse/workspaces"
},
{
"anyOf": [
{
"field": "Microsoft.Synapse/workspaces/managedVirtualNetworkSettings.preventDataExfiltration",
"exists": false
},
{
"field": "Microsoft.Synapse/workspaces/managedVirtualNetworkSettings.preventDataExfiltration",
"notEquals": true
},
{
"count": {
"field": "Microsoft.Synapse/workspaces/managedVirtualNetworkSettings.allowedAadTenantIdsForLinking[*]",
"where": {
"field": "Microsoft.Synapse/workspaces/managedVirtualNetworkSettings.allowedAadTenantIdsForLinking[*]",
"notEquals": "[subscription().tenantId]"
}
},
"greaterOrEquals": 1
}
]
}
]
},
"then": {
"effect": "Deny"
}
Met dit beleid wordt het gebruik van de functie voor gegevensexfiltratie van Azure Synapse afgedwongen. Met Azure Synapse kunt u elk privé-eindpunt weigeren dat afkomstig is van een service die buiten de tenant van de klant wordt gehost. U kunt ook elk privé-eindpunt weigeren dat buiten een opgegeven set tenant-id's wordt gehost. Met dit beleid kunt u alleen beheerde privé-eindpunten maken die zijn gekoppeld aan services, die worden gehost in de tenant van de klant.
Deze beleidsregels zijn nu beschikbaar als ingebouwd.
Azure Synapse-werkruimten moeten uitgaand gegevensverkeer alleen naar goedgekeurde doelen toestaan.
Definitie-id:
/providers/Microsoft.Authorization/policyDefinitions/3484ce98-c0c5-4c83-994b-c5ac24785218Beheerde privé-eindpunten van Azure Synapse mogen alleen verbinding maken met resources in goedgekeurde Microsoft Entra-tenants.
Definitie-id:
/providers/Microsoft.Authorization/policyDefinitions/3a003702-13d2-4679-941b-937e58c443f0
Het wordt aanbevolen om het beleid toe te wijzen aan de beheergroep op het hoogste niveau en waar nodig uitzonderingen te gebruiken.
Volgende stappen
Het is belangrijk om inzicht te hebben in de aanbevolen connectiviteitsmodellen voor binnenkomende en uitgaande connectiviteit van en naar het openbare internet. In het volgende artikel worden ontwerpoverwegingen, ontwerpaanvelingen en aanbevolen inhoud besproken voor meer informatie.