Einschränken mandantenübergreifender Verbindungen mit privaten Endpunkten in Azure

Artikel
10/11/2023

Kunden nutzen auf ihren Mandanten vermehrt private Endpunkte, um eine private und sichere Verbindung mit ihren PaaS-Diensten (Platform-as-a-Service) herzustellen. Private Endpunkte können eine Verbindung mit Diensten über Microsoft Entra-Mandanten hinweg herstellen. Aus Sicherheits- und Konformitätsgründen müssen Sie übergreifende Verbindungen mit Microsoft Entra-Mandanten auf Ihren privaten Endpunkten ggf. blockieren. In diesem Leitfaden werden die empfohlenen Konfigurationsoptionen zum Einschränken oder Verhindern mandantenübergreifender Verbindungen mit privaten Endpunkten veranschaulicht. Mit diesen Optionen können Sie in Ihrer Azure-Umgebung Steuerungen zur Verhinderung von Datenlecks (Data Leakage Prevention, DLP) erstellen.

Einführung in private Endpunkte

Verwenden Sie private Endpunkte, um den Datenverkehr in Ihrer Azure-Umgebung mithilfe eines vorhandenen Netzwerkumkreises zu steuern. Es gibt jedoch Szenarien, in denen Verbindungen mit privaten Endpunkten den Microsoft Entra-Mandanten des Unternehmens nicht verlassen dürfen. In den folgenden Beispielen werden Verbindungen veranschaulicht, die zu Sicherheitsrisiken führen können.

Verbindung A: Ein nicht autorisierter Administrator erstellt im virtuellen Netzwerk des Kunden private Endpunkte. Diese Endpunkte stellen eine Verbindung mit Diensten her, die außerhalb der Kundenumgebung gehostet werden, z. B. auf einem anderen Microsoft Entra-Mandanten.
Verbindung B: Ein nicht autorisierter Administrator erstellt private Endpunkte auf anderen Microsoft Entra-Mandanten, die eine Verbindung mit Diensten herstellen, welche auf dem Microsoft Entra-Mandanten des Kunden gehostet werden.

Diagramm: Szenarien für mandantenübergreifende Verbindungen mit privaten Endpunkten

Abbildung 1: Szenarien für mandantenübergreifende Verbindungen mit privaten Endpunkten

Bei beiden Szenarien geben Sie die Ressourcen-ID des Diensts an und genehmigen manuell die Verbindung mit dem privaten Endpunkt. Benutzer benötigen auch RBAC-Zugriff (Role-Based Access Control, rollenbasierte Zugriffssteuerung), um diese Aktionen auszuführen.

Die Verbindungen C und D in Abbildung 1 zeigen Szenarien, die Kunden in der Regel zulassen möchten. Die Verbindungen mit privaten Endpunkten bleiben innerhalb des Microsoft Entra-Mandanten des Unternehmens. Sie stellen kein Sicherheitsrisiko dar, daher werden diese beiden Szenarien in diesem Artikel nicht behandelt.

Im Folgenden erhalten Sie Informationen zu den Optionen, mit denen Sie die mandantenübergreifende Bereitstellung privater Endpunkte auf Microsoft Entra-Mandanten verhindern können.

Verweigern privater Endpunkte, die mit Diensten auf anderen Mandanten verknüpft sind

Szenario 1: Ein nicht autorisierter Administrator benötigt in einem Abonnement auf dem Microsoft Entra-Mandanten des Kunden die folgenden Rechte.

Rechte vom Typ Microsoft.Network/virtualNetworks/join/action in einem Subnetz mit Festlegung von privateEndpointNetworkPolicies auf Disabled (Deaktiviert).
Zugriff vom Typ Microsoft.Network/privateEndpoints/write auf eine Ressourcengruppe in der Kundenumgebung.

Mit diesen Rechten kann ein nicht autorisierter Administrator auf dem Microsoft Entra-Mandanten des Kunden einen privaten Endpunkt erstellen. Dieser private Endpunkt stellt eine Verbindung mit einem Dienst in einem separaten Abonnement und auf einem separaten Microsoft Entra-Mandanten her. Abbildung 1 zeigt dieses Szenario als Verbindung A.

Bei diesem Szenario richtet der Benutzer einen externen Microsoft Entra-Mandanten und ein Azure-Abonnement ein. Als Nächstes erstellt er einen privaten Endpunkt in der Kundenumgebung, indem er die Ressourcen-ID des Diensts manuell angibt. Abschließend genehmigt der nicht autorisierte Administrator den privaten Endpunkt für den verknüpften Dienst, der auf dem externen Microsoft Entra-Mandanten gehostet wird, damit der Datenverkehr über die Verbindung fließen kann.

Nachdem der nicht autorisierte Administrator die Verbindung mit dem privaten Endpunkt genehmigt hat, können Unternehmensdaten aus dem virtuellen Unternehmensnetzwerk in einen Azure-Dienst auf einem externen Microsoft Entra-Mandanten kopiert werden. Dieses Sicherheitsrisiko besteht nur, wenn Zugriff über Azure RBAC gewährt wurde.

Lösung für Szenario 1

Verwenden Sie die folgende Azure Policy-Instanz, um die Möglichkeit zum Erstellen eines privaten Endpunkts auf dem unternehmenseigenen Microsoft Entra-Mandanten, der mit einem externen Azure-Dienst verknüpft ist, automatisch zu blockieren.

"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"
}

Bei dieser Richtlinie werden alle privaten Endpunkte abgelehnt, die außerhalb des Abonnements des verknüpften Diensts erstellt wurden, z. B. Verbindung A und D. Für die Richtlinie können auch manualPrivateLinkServiceConnections und privateLinkServiceConnections flexibel genutzt werden.

Sie können diese Richtlinie so aktualisieren, dass private Endpunkte nur in einer bestimmten Gruppe von Abonnements erstellt werden. Sie können diese Änderung vornehmen, indem Sie einen list-Parameter hinzufügen und das "notIn": "[parameters('allowedSubscriptions')]"-Konstrukt verwenden. Dieser Ansatz wird aber nicht empfohlen, da Sie die Liste mit den Abonnements für diese Richtlinie dauerhaft pflegen müssten. Bei jeder Erstellung eines neuen Abonnements innerhalb Ihres Mandanten muss dem Parameter die Abonnement-ID hinzugefügt werden.

Weisen Sie die Richtlinie stattdessen der Verwaltungsgruppe der obersten Ebene zu, und verwenden Sie Ausnahmen nach Bedarf.

Überlegungen zu Szenario 1

Mit dieser Richtlinie wird die Möglichkeit zur Erstellung privater Endpunkte blockiert, die sich in einem anderen Abonnement als der Dienst selbst befinden. Wenn diese Endpunkte für bestimmte Anwendungsfälle erforderlich sind, verwenden Sie Richtlinienausnahmen. Erstellen Sie weitere Richtlinien für Data Factory und Azure Synapse, um sicherzustellen, dass verwaltete private Endpunkte, die im verwalteten virtuellen Netzwerk gehostet werden, nur eine Verbindung mit Diensten herstellen können, die auf Ihrem Microsoft Entra-Mandanten gehostet werden.

Verweigern von Verbindungen von privaten Endpunkten, die auf anderen Mandanten erstellt wurden

Szenario 2: Ein nicht autorisierter Administrator benötigt Schreibzugriff für den Dienst in der Kundenumgebung, für die ein privater Endpunkt erstellt werden soll.

Mit diesem Recht kann ein nicht autorisierter Administrator auf einem externen Microsoft Entra-Mandanten bzw. in einem externen Abonnement einen privaten Endpunkt erstellen. Dieser Endpunkt verweist auf einen Dienst im Microsoft Entra-Mandanten des Kunden. Abbildung 1 zeigt dieses Szenario als Verbindung B.

Bei diesem Szenario muss der nicht autorisierte Administrator zunächst einen externen privaten Microsoft Entra-Mandanten und ein Azure-Abonnement konfigurieren. Als Nächstes erstellt er einen privaten Endpunkt in seiner Umgebung, indem er die Ressourcen-ID und die Gruppen-ID des Diensts auf dem Microsoft Entra-Mandanten des Unternehmens manuell angibt. Abschließend genehmigt er den privaten Endpunkt für den verknüpften Dienst, um zuzulassen, dass Datenverkehr über die Verbindung über Microsoft Entra-Mandanten fließt.

Nachdem der private Endpunkt vom nicht autorisierten Administrator oder dem Dienstbesitzer genehmigt wurde, sind die Daten über das externe virtuelle Netzwerk zugänglich.

Lösung für Szenario 2

Verwenden Sie dienstspezifische Richtlinien, um dieses Szenario für den gesamten Kundenmandanten zu verhindern. Verbindungen mit privaten Endpunkten sind Unterressourcen der jeweiligen Dienste und werden dafür im Abschnitt mit den Eigenschaften angezeigt. Verweigern Sie nicht konforme Verbindungen mithilfe der folgenden Richtliniendefinition:

"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"
}

Mit dieser Richtlinie wird ein Beispiel für Azure Storage veranschaulicht. Replizieren Sie die gleiche Richtliniendefinition für andere Dienste wie Key Vault, Azure KI Services und SQL Server.

Um die Verwaltbarkeit noch weiter zu verbessern, fassen Sie die dienstspezifischen Richtlinien zu einer Initiative zusammen. Mit der Richtlinie wird die Genehmigung von Verbindungen mit privaten Endpunkten verweigert, die außerhalb des Abonnements des jeweiligen Diensts gehostet werden. Die Ablehnung oder Entfernung von Verbindungen mit privaten Endpunkten wird nicht verweigert, und dies ist das von Kunden gewünschte Verhalten. Workflows mit automatischer Genehmigung, z. B. bei Verbindung C, sind von dieser Richtlinie nicht betroffen.

Die Genehmigung konformer Verbindungen mit privaten Endpunkten im Portal wird mit dieser Methode jedoch blockiert. Es kommt zu dieser Blockierung, weil von der Portalbenutzeroberfläche in den Nutzdaten nicht die Ressourcen-ID des verbundenen privaten Endpunkts gesendet wird. Es empfiehlt sich, Azure Resource Manager, Azure PowerShell oder die Azure CLI zu verwenden, um die Verbindung mit dem privaten Endpunkt zu genehmigen.

Weisen Sie die Richtlinie außerdem der Verwaltungsgruppe der obersten Ebene zu, und verwenden Sie Ausnahmen nach Bedarf.

Überlegungen zu Szenario 2

Azure Synapse Analytics und Azure Data Factory bieten verwaltete virtuelle Netzwerke und verwaltete private Endpunkte an. Aufgrund dieser neuen Funktionen blockiert die Richtlinie die sichere und private Nutzung dieser Dienste.

Es wird empfohlen, in der Richtliniendefinition, die Sie in der Entschärfung des zweiten Szenarios verwenden, einen Überwachungseffekt anstelle eines Verweigerungseffekts einzusetzen. Durch diese Änderung können Sie nachverfolgen, welche privaten Endpunkte in separaten Abonnements und Mandanten erstellt werden. Darüber hinaus können Sie auch Richtlinienausnahmen für die jeweiligen Bereiche der Datenplattform verwenden.

Azure Data Factory

Verwenden Sie die folgende Richtliniendefinition, um Szenario 1 im verwalteten virtuellen Netzwerk von Azure Data Factory zu lösen:

"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')]"
}

Mit dieser Richtlinie werden verwaltete private Endpunkte verweigert, die mit Diensten verbunden sind, welche außerhalb des Abonnements der Data Factory gehostet werden. Sie können diese Richtlinie so ändern, dass Verbindungen mit Diensten in mehreren Abonnements gehostet werden. Fügen Sie hierzu den Parameter list hinzu, und verwenden Sie das Konstrukt "notIn": "[parameters('allowedSubscriptions')]". Wir empfehlen diese Änderung für den Datenplattformbereich innerhalb des Mandanten oder der Umgebungen, in denen Dienste mit verwalteten virtuellen Netzwerken und verwalteten privaten Endpunkten viel genutzt werden.

Es empfiehlt sich, diese Richtlinie der Verwaltungsgruppe der obersten Ebene zuzuweisen und bei Bedarf Ausnahmen zu verwenden. Für die Datenplattform nehmen Sie diese Änderungen vor, und weisen Sie die Richtlinie den Datenplattformabonnements zu.

Azure Synapse

Für Azure Synapse werden auch verwaltete virtuelle Netzwerke verwendet. Wir empfehlen Ihnen, eine Richtlinie anzuwenden, die der Data Factory-Richtlinie für Szenario 1 ähnelt. Von Azure Synapse wird kein Richtlinienalias für verwaltete private Endpunkte zur Verfügung gestellt. Es gibt jedoch ein Feature zur Verhinderung der Datenexfiltration, das für Arbeitsbereiche mithilfe der folgenden Richtlinie erzwungen werden kann:

"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"
}

Mit dieser Richtlinie wird die Verwendung des Features für die Datenexfiltration von Azure Synapse erzwungen. Mit Azure Synapse können Sie alle privaten Endpunkte verweigern, die von einem außerhalb des Kundenmandanten gehosteten Dienst stammen. Darüber hinaus können Sie auch private Endpunkte verweigern, die außerhalb einer bestimmten Gruppe mit Mandanten-IDs gehostet werden. Diese Richtlinie lässt nur die Erstellung verwalteter privater Endpunkte zu, die mit auf dem Kundenmandanten gehosteten Diensten verbunden sind.

Diese Richtlinien sind jetzt als integrierte Richtlinien verfügbar.

Für Azure Synapse-Arbeitsbereiche darf ausgehender Datenverkehr nur zu genehmigten Zielen zugelassen sein.

Definitions-ID: /providers/Microsoft.Authorization/policyDefinitions/3484ce98-c0c5-4c83-994b-c5ac24785218
Von Azure Synapse verwaltete private Endpunkte dürfen nur eine Verbindung mit Ressourcen auf genehmigten Microsoft Entra-Mandanten herstellen.

Definitions-ID: /providers/Microsoft.Authorization/policyDefinitions/3a003702-13d2-4679-941b-937e58c443f0

Es empfiehlt sich, die Richtlinie der Verwaltungsgruppe der obersten Ebene zuzuweisen und bei Bedarf Ausnahmen zu verwenden.

Nächste Schritte

Es ist wichtig, dass Sie sich mit den empfohlenen Konnektivitätsmodellen für ein- und ausgehende Verbindungen mit dem öffentlichen Internet vertraut machen. Der nächste Artikel enthält Informationen zu Entwurfsaspekten, Entwurfsempfehlungen und empfohlenen weiteren Dokumenten.

Konnektivität für ein- und ausgehenden Datenverkehr

Freigeben über