Limitar conexões de ponto de extremidade privado entre locatários no Azure
Os clientes estão cada vez mais usando pontos de extremidade privados em seus locatários para se conectar aos serviços de PaaS (plataforma como serviço) do Azure de forma privada e segura. Os pontos de extremidade privados podem se conectar a serviços em locatários do Microsoft Entra. Para fins de segurança e conformidade, talvez seja necessário bloquear conexões cruzadas de locatários do Microsoft Entra em seus pontos de extremidade privados. Estas diretrizes mostram as opções de configuração recomendadas para limitar ou impedir conexões de ponto de extremidade privado entre locatários. Essas opções o ajudam a criar controles de prevenção contra vazamento de dados (DLP) dentro do seu ambiente Azure.
Introdução aos pontos de extremidade privados
Use pontos de extremidade privados para controlar o tráfego em seu ambiente do Azure usando um perímetro de rede existente. Mas há cenários em que você precisa manter as conexões de ponto de extremidade privadas somente dentro do locatário corporativo do Microsoft Entra. Os exemplos a seguir mostram conexões que podem criar riscos à segurança.
- Conexão A: um administrador não autorizado cria pontos de extremidade privados na rede virtual do cliente. Esses pontos de extremidade são vinculados a serviços hospedados fora do ambiente do cliente, como outro locatário do Microsoft Entra.
- Conexão B: um administrador desonesto cria pontos de extremidade privados em outros locatários do Microsoft Entra que se vinculam a serviços hospedados no locatário do Microsoft Entra do cliente.
Figura 1: ilustração de cenários de ponto de extremidade privado entre locatários.
Em ambos os cenários, você especifica a ID do recurso do serviço e aprova manualmente a conexão do ponto de extremidade privado. Os usuários também precisam de acesso de controle de acesso baseado em função (RBAC) para executar essas ações.
As conexões C e D na Figura 1 mostram cenários que os clientes geralmente desejam permitir. As conexões de ponto de extremidade privado são mantidas no locatário corporativo do Microsoft Entra. Eles não representam um risco de segurança, portanto, esses dois cenários não são abordados neste artigo.
As informações a seguir oferecem opções para impedir o provisionamento de pontos de extremidade privados entre locatários do Microsoft Entra.
Negar pontos de extremidade privados vinculados a serviços em outros locatários
Cenário um: um administrador desonesto requer os direitos a seguir em uma assinatura no locatário do Microsoft Entra do cliente.
- Direitos Microsoft.Network/virtualNetworks/join/action em uma sub-rede com privateEndpointNetworkPolicies definida como Desabilitada.
- Acesso Microsoft.Network/privateEndpoints/write a um grupo de recursos no ambiente do cliente.
Com esses direitos, um administrador desonesto pode criar um ponto de extremidade privado no locatário do Microsoft Entra do cliente. Esse ponto de extremidade privado é vinculado a um serviço em uma assinatura separada e em um locatário do Microsoft Entra. A Figura 1 mostra esse cenário como conexão A.
Para esse cenário, o usuário configura um locatário externo do Microsoft Entra e uma assinatura do Azure. Em seguida, eles criam um ponto de extremidade privado no ambiente do cliente, especificando manualmente o ID do recurso do serviço. Por fim, o administrador desonesto aprova o ponto de extremidade privado no serviço vinculado que está hospedado no locatário externo do Microsoft Entra para permitir o tráfego pela conexão.
Depois que o administrador desonesto aprova a conexão do ponto de extremidade privado, os dados corporativos podem ser copiados da rede virtual corporativa para um serviço do Azure em um locatário externo do Microsoft Entra. Esse risco de segurança só poderá ocorrer se o acesso tiver sido concedido usando o RBAC do Azure.
Mitigação do cenário um
Use a seguinte Azure Policy para bloquear automaticamente a capacidade de criar um ponto de extremidade privado no locatário corporativo do Microsoft Entra que esteja vinculado a um serviço externo do 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"
}
Essa política nega quaisquer pontos de extremidade privados criados fora da assinatura do serviço vinculado, como as conexões A e D. A política também fornece a flexibilidade para usar manualPrivateLinkServiceConnections e privateLinkServiceConnections.
Você pode atualizar essa política para que os pontos de extremidade privados sejam criados somente em um determinado conjunto de assinaturas. Você pode fazer essa alteração adicionando um list parâmetro e usar a "notIn": "[parameters('allowedSubscriptions')]" construção. Mas essa abordagem não é recomendada, porque significa que você teria que manter constantemente a lista de assinaturas dessa política. Toda vez que uma nova assinatura é criada em seu locatário, o ID da assinatura deve ser adicionado ao parâmetro.
Em vez disso, atribua a política ao grupo de gerenciamento de nível superior e, em seguida, use isenções quando necessário.
Considerações sobre o cenário um
Essa política bloqueia a capacidade de criar pontos de extremidade privados que estejam em uma assinatura diferente da do próprio serviço. Se esses pontos de extremidade forem necessários para determinados casos de uso, use isenções de política. Crie mais políticas para o Data Factory e o Azure Synapse para garantir que os pontos de extremidade privados gerenciados hospedados na rede virtual gerenciada só possam se conectar a serviços hospedados em seu locatário do Microsoft Entra.
Negar conexões de pontos de extremidade privados criados em outros locatários
Cenário dois: um administrador desonesto requer acesso de gravação sobre o serviço no ambiente do cliente para o qual um ponto de extremidade privado deve ser criado.
Com esse direito, um administrador desonesto pode criar um ponto de extremidade privado em um locatário e uma assinatura externos do Microsoft Entra. Esse ponto de extremidade é vinculado a um serviço no locatário do Microsoft Entra do cliente. A Figura 1 mostra esse cenário como conexão B.
Nesse cenário, o administrador desonesto precisa primeiro configurar um locatário privado externo do Microsoft Entra e uma assinatura do Azure. Em seguida, eles criam um ponto de extremidade privado em seu ambiente, especificando manualmente a ID do recurso e a ID do grupo do serviço no locatário corporativo do Microsoft Entra. Por fim, eles aprovam o ponto de extremidade privado no serviço vinculado para permitir o tráfego pela conexão entre os locatários do Microsoft Entra.
Depois que o administrador desonesto ou o proprietário do serviço aprova o ponto de extremidade privado, os dados são acessados a partir da rede virtual externa.
Mitigação do cenário um
Use políticas específicas do serviço para evitar esse cenário no locatário do cliente. As conexões de ponto de extremidade privado são sub-recursos dos respectivos serviços e aparecem na seção de propriedades. Negue conexões fora de conformidade usando a seguinte definição de política:
"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"
}
Esta política mostra um exemplo para o Armazenamento do Microsoft Azure. Replique a mesma definição de política para outros serviços, como Key Vault, Serviços de IA do Azure e SQL Server.
Para melhorar ainda mais a capacidade de gerenciamento, agrupe as políticas específicas do serviço em uma iniciativa. A política nega a aprovação de conexões de ponto de extremidade privado para pontos de extremidade privados hospedados fora da assinatura do respectivo serviço. Ela não nega a rejeição ou a remoção de conexões de ponto de extremidade privado, que é o comportamento que os clientes querem. Fluxos de trabalho de aprovação automática, como a conexão C, não são afetados por essa política.
Mas a aprovação de conexões de ponto de extremidade privado em conformidade dentro do portal é bloqueada com esse método. Esse bloqueio ocorre porque a interface do usuário do portal não envia a ID do recurso do ponto de extremidade privado conectado em seu conteúdo. É recomendado usar o Azure Resource Manager, o Azure PowerShell ou a CLI do Azure para aprovar a conexão de ponto de extremidade privado.
Além disso, atribua a política ao grupo de gerenciamento de nível superior e use isenções quando necessário.
Considerações sobre o cenário dois
O Azure Synapse Analytics e o Azure Data Factory oferecem redes virtuais gerenciadas e pontos de extremidade privados gerenciados. Devido a esses novos recursos, a política bloqueia o uso seguro e privado desses serviços.
É recomendado que você use um efeito Auditoria em vez de um efeito Negar na definição de política que você usa na mitigação do cenário dois. Essa alteração ajuda a manter o controle dos pontos de extremidade privados que estão sendo criados em assinaturas e locatários separados. Você também pode usar isenções de política para os respectivos escopos de plataforma de dados.
Fábrica de dados do Azure
Para superar o cenário um na rede virtual gerenciada do Azure Data Factory, use a seguinte definição de política:
"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')]"
}
Essa política nega pontos de extremidade privados gerenciados que estejam vinculados a serviços hospedados fora da assinatura do Data Factory. Você pode alterar essa política para permitir conexões com serviços hospedados em um conjunto de assinaturas adicionando um parâmetro list e usando o constructo "notIn": "[parameters('allowedSubscriptions')]". Recomendamos essa alteração para o escopo da plataforma de dados dentro do locatário ou ambientes em que os serviços com redes virtuais gerenciadas e pontos de extremidade privados gerenciados são amplamente usados.
É recomendado que você atribua essa política ao grupo de gerenciamento de nível superior e use isenções quando necessário. Para a plataforma de dados, faça essas alterações e atribua a política ao conjunto de assinaturas da plataforma de dados.
Azure Synapse
O Azure Synapse também usa redes virtuais gerenciadas. É recomendável aplicar uma política semelhante à política do Data Factory para o cenário um. O Azure Synapse não fornece um alias de política para pontos de extremidade privados gerenciados. Mas há um recurso de prevenção de exfiltração de dados, que pode ser aplicado aos espaços de trabalho usando a seguinte política:
"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"
}
Esta política impõe o uso do recurso de exfiltração de dados do Azure Synapse. Com o Azure Synapse, você pode negar qualquer ponto de extremidade privado proveniente de um serviço hospedado fora do locatário do cliente. Você também pode negar qualquer ponto de extremidade privado hospedado fora de um conjunto especificado de IDs de locatário. Essa política só permite a criação de pontos de extremidade privados gerenciados que estejam vinculados a serviços hospedados no locatário do cliente.
Estas políticas estão agora disponíveis como internas.
Os workspaces do Azure Synapse devem permitir tráfego de dados de saída somente para destinos aprovados.
ID da definição:
/providers/Microsoft.Authorization/policyDefinitions/3484ce98-c0c5-4c83-994b-c5ac24785218Os pontos de extremidade privados gerenciados pelo Azure Synapse só devem se conectar a recursos em locatários aprovados do Microsoft Entra.
ID da definição:
/providers/Microsoft.Authorization/policyDefinitions/3a003702-13d2-4679-941b-937e58c443f0
É recomendado que você atribua a política ao grupo de gerenciamento de nível superior e use isenções quando necessário.
Próximas etapas
É importante entender os modelos de conectividade recomendados para conectividade de entrada e saída de e para a Internet pública. O próximo artigo analisa considerações de design, recomendações de design e conteúdo recomendado para leitura posterior.