Ograniczanie połączeń prywatnych punktów końcowych między dzierżawami na platformie Azure

Klienci coraz częściej korzystają z prywatnych punktów końcowych w swoich dzierżawach, aby łączyć się z usługami platformy Azure jako usługi (PaaS) prywatnie i bezpiecznie. Prywatne punkty końcowe mogą łączyć się z usługami w dzierżawach firmy Microsoft Entra. W celu zapewnienia bezpieczeństwa i zgodności może być konieczne zablokowanie połączeń między dzierżawami firmy Microsoft w prywatnych punktach końcowych. W tych wskazówkach przedstawiono zalecane opcje konfiguracji, aby ograniczyć lub uniemożliwić połączenia prywatnych punktów końcowych między dzierżawami. Te opcje ułatwiają tworzenie kontrolek ochrony przed wyciekami danych (DLP) wewnątrz środowiska platformy Azure.

Wprowadzenie do prywatnych punktów końcowych

Użyj prywatnych punktów końcowych, aby kontrolować ruch w środowisku platformy Azure przy użyciu istniejącego obwodu sieci. Istnieją jednak scenariusze, w których należy zachować połączenia prywatnych punktów końcowych tylko w ramach firmowej dzierżawy firmy Microsoft Entra. W poniższych przykładach pokazano połączenia, które mogą powodować zagrożenia bezpieczeństwa.

  • Połączenie ion A: Nieuczciwy administrator tworzy prywatne punkty końcowe w sieci wirtualnej klienta. Te punkty końcowe łączą się z usługami hostowanymi poza środowiskiem klienta, takimi jak inna dzierżawa firmy Microsoft Entra.
  • Połączenie ion B: Nieautoryzujący administrator tworzy prywatne punkty końcowe w innych dzierżawach firmy Microsoft Entra, które łączą się z usługami hostowanymi w dzierżawie firmy Microsoft Entra klienta.

Diagram that shows cross-tenant private endpoint connection scenarios.

Rysunek 1. Ilustracja scenariuszy między dzierżawami prywatnego punktu końcowego.

W obu scenariuszach należy określić identyfikator zasobu usługi i ręcznie zatwierdzić połączenie prywatnego punktu końcowego. Użytkownicy wymagają również dostępu kontroli dostępu opartej na rolach (RBAC) w celu uruchomienia tych akcji.

Połączenie ions C i D na rysunku 1 pokazują scenariusze, na które klienci zazwyczaj chcą zezwolić. Połączenia prywatnego punktu końcowego są przechowywane w firmowej dzierżawie firmy Microsoft Entra. Nie reprezentują one zagrożenia bezpieczeństwa, więc te dwa scenariusze nie zostały omówione w tym artykule.

Poniższe informacje zawierają opcje zapobiegania aprowizacji prywatnych punktów końcowych w dzierżawach firmy Microsoft Entra.

Odmowa prywatnych punktów końcowych połączonych z usługami w innych dzierżawach

Scenariusz pierwszy: nieautoryzowy administrator wymaga następujących praw w subskrypcji w dzierżawie firmy Microsoft firmy Microsoft klienta.

  • Microsoft.Network/virtualNetworks/join/action rights on a subnet with privateEndpointNetworkPolicies ( Wyłączone).
  • Microsoft.Network/privateEndpoints/write access do grupy zasobów w środowisku klienta.

Dzięki tym prawom nieautoryzny administrator może utworzyć prywatny punkt końcowy w dzierżawie firmy Microsoft firmy Microsoft. Ten prywatny punkt końcowy łączy się z usługą w oddzielnej subskrypcji i dzierżawie firmy Microsoft Entra. Rysunek 1 przedstawia ten scenariusz jako połączenie A.

W tym scenariuszu użytkownik konfiguruje zewnętrzną dzierżawę firmy Microsoft Entra i subskrypcję platformy Azure. Następnie tworzą prywatny punkt końcowy w środowisku klienta, ręcznie określając identyfikator zasobu usługi. Na koniec nieuczciwy administrator zatwierdza prywatny punkt końcowy w połączonej usłudze hostowanej w zewnętrznej dzierżawie firmy Microsoft Entra, aby zezwolić na ruch przez połączenie.

Gdy nieautoryzowany administrator zatwierdzi połączenie prywatnego punktu końcowego, dane firmowe można skopiować z firmowej sieci wirtualnej do usługi platformy Azure w zewnętrznej dzierżawie firmy Microsoft Entra. To zagrożenie bezpieczeństwa może wystąpić tylko wtedy, gdy udzielono dostępu przy użyciu kontroli dostępu opartej na rolach platformy Azure.

Środki zaradcze dla scenariusza 1

Użyj poniższej usługi Azure Policy , aby automatycznie zablokować możliwość tworzenia prywatnego punktu końcowego w firmowej dzierżawie firmy Microsoft Entra połączonej z zewnętrzną usługą platformy Azure.

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

Te zasady odrzucają wszelkie prywatne punkty końcowe utworzone poza subskrypcją połączonej usługi, takie jak połączenia A i D. Zasady zapewniają również elastyczność używania manualPrivateLinkServiceConnections i privateLinkServiceConnections.

Te zasady można zaktualizować, aby prywatne punkty końcowe zostały utworzone tylko w określonym zestawie subskrypcji. Tę zmianę list można wprowadzić, dodając parametr i używając "notIn": "[parameters('allowedSubscriptions')]" konstrukcji. Jednak takie podejście nie jest zalecane, ponieważ oznacza to, że należy stale utrzymywać listę subskrypcji dla tych zasad. Za każdym razem, gdy nowa subskrypcja zostanie utworzona wewnątrz dzierżawy, identyfikator subskrypcji musi zostać dodany do parametru .

Zamiast tego przypisz zasady do grupy zarządzania najwyższego poziomu, a następnie w razie potrzeby użyj wykluczeń.

Zagadnienia dotyczące scenariusza 1

Te zasady blokują możliwość tworzenia prywatnych punktów końcowych, które znajdują się w innej subskrypcji niż sama usługa. Jeśli te punkty końcowe są wymagane w niektórych przypadkach użycia, użyj wykluczeń zasad. Utwórz więcej zasad dla usług Data Factory i Azure Synapse, aby upewnić się, że zarządzane prywatne punkty końcowe hostowane w zarządzanej sieci wirtualnej mogą łączyć się tylko z usługami hostowanymi w dzierżawie firmy Microsoft Entra.

Odmów połączeń z prywatnych punktów końcowych utworzonych w innych dzierżawach

Scenariusz drugi: nieuczciwy administrator wymaga dostępu do zapisu w usłudze w środowisku klienta, dla którego należy utworzyć prywatny punkt końcowy.

Mając to prawo, administrator nieuczciwy może utworzyć prywatny punkt końcowy w zewnętrznej dzierżawie i subskrypcji firmy Microsoft Entra. Ten punkt końcowy łączy się z usługą w dzierżawie firmy Microsoft firmy Microsoft. Rysunek 1 przedstawia ten scenariusz jako połączenie B.

W tym scenariuszu nieuczciwy administrator musi najpierw skonfigurować zewnętrzną prywatną dzierżawę firmy Microsoft Entra i subskrypcję platformy Azure. Następnie tworzą prywatny punkt końcowy w swoim środowisku, ręcznie określając identyfikator zasobu i identyfikator grupy usługi w firmowej dzierżawie firmy Microsoft Entra. Na koniec zatwierdzają prywatny punkt końcowy w połączonej usłudze, aby zezwolić na ruch przez połączenie między dzierżawami firmy Microsoft Entra.

Po zatwierdzeniu prywatnego punktu końcowego przez nieautoryzowanego administratora lub właściciela usługi dane są uzyskiwane z zewnętrznej sieci wirtualnej.

Ograniczenie ryzyka dla scenariusza drugiego

Użyj zasad specyficznych dla usługi, aby zapobiec temu scenariuszowi w dzierżawie klienta. Połączenia prywatnego punktu końcowego są podźródłami odpowiednich usług i są wyświetlane w sekcji właściwości. Odmów niezgodnych połączeń przy użyciu następującej definicji zasad:

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

Te zasady przedstawiają przykład usługi Azure Storage. Zreplikuj tę samą definicję zasad dla innych usług, takich jak Key Vault, Cognitive Services i SQL Server. Należy pamiętać, że usługa aplikacja systemu Azure nie obsługuje obecnie tego ograniczenia ryzyka.

Aby jeszcze bardziej zwiększyć możliwości zarządzania, należy powiązać zasady specyficzne dla usługi z inicjatywą. Zasady odrzucają zatwierdzenie połączeń prywatnych punktów końcowych z prywatnymi punktami końcowymi hostowanymi poza subskrypcją odpowiedniej usługi. Nie odrzuca odrzucenia ani usuwania połączeń prywatnych punktów końcowych, co jest zachowaniem, jakiego chcą klienci. Te zasady nie mają wpływu na przepływy pracy automatycznego zatwierdzania, takie jak połączenie C.

Jednak zatwierdzenie zgodnych połączeń prywatnych punktów końcowych w portalu jest blokowane za pomocą tej metody. Ten blok występuje, ponieważ interfejs użytkownika portalu nie wysyła identyfikatora zasobu połączonego prywatnego punktu końcowego w ładunku. Zaleca się użycie usługi Azure Resource Manager, programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure w celu zatwierdzenia połączenia prywatnego punktu końcowego.

Ponadto przypisz zasady do grupy zarządzania najwyższego poziomu i w razie potrzeby użyj wykluczeń.

Zagadnienia dotyczące scenariusza drugiego

Usługi Azure Synapse Analytics i Azure Data Factory oferują zarządzane sieci wirtualne i zarządzane prywatne punkty końcowe. Ze względu na te nowe możliwości zasady blokują bezpieczne i prywatne użycie tych usług.

Zaleca się użycie efektu inspekcji zamiast efektu Odmów w definicji zasad używanej w scenariuszu dwóch środków zaradczych. Ta zmiana ułatwia śledzenie prywatnych punktów końcowych tworzonych w oddzielnych subskrypcjach i dzierżawach. Możesz również użyć wykluczeń zasad dla odpowiednich zakresów platformy danych.

Azure Data Factory

Aby pokonać scenariusz jeden w zarządzanej sieci wirtualnej usługi Azure Data Factory, użyj następującej definicji zasad:

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

Te zasady odrzucają zarządzane prywatne punkty końcowe połączone z usługami hostowanymi poza subskrypcją usługi Data Factory. Te zasady można zmienić tak, aby zezwalały na połączenia z usługami hostowanymi w zestawie subskrypcji, dodając list parametr i używając "notIn": "[parameters('allowedSubscriptions')]" konstrukcji. Zalecamy zmianę zakresu platformy danych w dzierżawie lub środowiskach, w których usługi z zarządzanymi sieciami wirtualnymi i zarządzanymi prywatnymi punktami końcowymi są szeroko używane.

Zaleca się przypisanie tych zasad do grupy zarządzania najwyższego poziomu i użycie wykluczeń tam, gdzie jest to wymagane. W przypadku platformy danych wprowadź te zmiany i przypisz zasady do zestawu subskrypcji platformy danych.

Azure Synapse

Usługa Azure Synapse używa również zarządzanych sieci wirtualnych. W scenariuszu zalecamy zastosowanie podobnych zasad do zasad usługi Data Factory. Usługa Azure Synapse nie udostępnia aliasu zasad dla zarządzanych prywatnych punktów końcowych. Istnieje jednak funkcja zapobiegania eksfiltracji danych, która może być wymuszana dla obszarów roboczych przy użyciu następujących zasad:

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

Te zasady wymuszają użycie funkcji eksfiltracji danych usługi Azure Synapse. Za pomocą usługi Azure Synapse możesz odmówić dowolnego prywatnego punktu końcowego pochodzącego z usługi hostowanej poza dzierżawą klienta. Możesz również odmówić dowolnego prywatnego punktu końcowego hostowanego poza określonym zestawem identyfikatorów dzierżawy. Te zasady umożliwiają tworzenie zarządzanych prywatnych punktów końcowych połączonych z usługami hostowanymi w dzierżawie klienta.

Te zasady są teraz dostępne jako wbudowane.

  • Obszary robocze usługi Azure Synapse powinny zezwalać na ruch wychodzący danych tylko do zatwierdzonych obiektów docelowych.

    Identyfikator definicji: /providers/Microsoft.Authorization/policyDefinitions/3484ce98-c0c5-4c83-994b-c5ac24785218

  • Zarządzane prywatne punkty końcowe usługi Azure Synapse powinny łączyć się tylko z zasobami w zatwierdzonych dzierżawach firmy Microsoft Entra.

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

Zaleca się przypisanie zasad do grupy zarządzania najwyższego poziomu i użycie wykluczeń tam, gdzie jest to wymagane.

Następne kroki

Ważne jest, aby zrozumieć zalecane modele łączności dla połączeń przychodzących i wychodzących do i z publicznego Internetu. W następnym artykule opisano zagadnienia dotyczące projektowania, zalecenia dotyczące projektowania i zalecaną zawartość, aby uzyskać dalsze informacje.