Limitar conexões de ponto de extremidade privado entre locatários no Azure
Os clientes estão usando cada vez mais pontos de extremidade privados em seus locatários para se conectar aos seus serviços de plataforma Azure como serviço (PaaS) de forma privada e segura. Os pontos de extremidade privados podem se conectar a serviços entre locatários do Microsoft Entra. Para segurança e conformidade, talvez seja necessário bloquear conexões entre locatários do Microsoft Entra em seus pontos de extremidade privados. Este guia mostra as opções de configuração recomendadas para limitar ou impedir conexões de ponto de extremidade privado entre locatários. Essas opções ajudam você a criar controles de prevenção de vazamento de dados (DLP) dentro do seu ambiente do Azure.
Introdução aos parâmetros de avaliação 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ê deve manter conexões de ponto de extremidade privadas apenas dentro do locatário corporativo do Microsoft Entra. Os exemplos a seguir mostram conexões que podem criar riscos de segurança.
- Conexão A: Um administrador não autorizado cria pontos de extremidade privados na rede virtual do cliente. Esses pontos de extremidade se vinculam a serviços hospedados fora do ambiente do cliente, como outro locatário do Microsoft Entra.
- Conexão B: um administrador não autorizado 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 final privado entre locatários.
Para ambos os cenários, você especifica a ID do recurso do serviço e aprova manualmente a conexão de ponto de extremidade privado. Os usuários também precisam de acesso RBAC (controle de acesso baseado em função) 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 dentro do 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 evitar 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 não autorizado requer os seguintes direitos numa subscrição no inquilino do Microsoft Entra do cliente.
- Direitos Microsoft.Network/virtualNetworks/join/action em uma sub-rede com privateEndpointNetworkPolicies definido como Disabled.
- Acesso Microsoft.Network/privateEndpoints/write a um grupo de recursos no ambiente do cliente.
Com esses direitos, um administrador não autorizado pode criar um ponto de extremidade privado no locatário do Microsoft Entra do cliente. Este ponto de extremidade privado vincula-se a um serviço em uma assinatura separada e ao 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. Finalmente, o administrador não autorizado aprova o ponto de extremidade privado no serviço vinculado hospedado no locatário externo do Microsoft Entra para permitir o tráfego pela conexão.
Depois que o administrador não autorizado aprovar a conexão de ponto de extremidade privado, os dados corporativos poderão 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ó pode ocorrer se o acesso tiver sido concedido usando o Azure RBAC.
Mitigação para o cenário um
Use a seguinte Política do Azure para bloquear automaticamente a capacidade de criar um ponto de extremidade privado no locatário corporativo do Microsoft Entra 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"
}
Esta 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 proporciona a flexibilidade de utilização manualPrivateLinkServiceConnections e privateLinkServiceConnections.
Você pode atualizar essa política para que os pontos de extremidade privados sejam criados apenas 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 para essa política. Sempre que uma nova assinatura é criada dentro do seu locatário, a ID da assinatura deve ser adicionada ao parâmetro.
Em vez disso, atribua a política ao grupo de gerenciamento de nível superior e use isenções quando necessário.
Considerações para o cenário um
Esta política bloqueia a capacidade de criar pontos de extremidade privados que estão em uma assinatura diferente 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 não autorizado requer acesso de gravação no serviço no ambiente do cliente para o qual um ponto de extremidade privado deve ser criado.
Com esse direito, um administrador não autorizado pode criar um ponto de extremidade privado em um locatário e assinatura externos do Microsoft Entra. Este ponto de extremidade vincula-se 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 não autorizado 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. Finalmente, eles aprovam o ponto de extremidade privado no serviço vinculado para permitir o tráfego na conexão entre locatários do Microsoft Entra.
Depois que o administrador não autorizado ou o proprietário do serviço aprova o ponto de extremidade privado, os dados são acessados a partir da rede virtual externa.
Atenuação para o cenário dois
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 subrecursos dos respetivos serviços e aparecem em sua seção de propriedades. Negar conexões não compatíveis 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 Azure. Replique a mesma definição de política para outros serviços, como Cofre de Chaves, serviços cognitivos e SQL Server. Observe que o Serviço de Aplicativo do Azure não oferece suporte a essa atenuação no momento.
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 que são hospedados fora da assinatura do respetivo serviço. Ele não nega a rejeição ou remoção de conexões de ponto de extremidade privadas, que é o comportamento que os clientes desejam. Os fluxos de trabalho de aprovação automática, como a conexão C, não são afetados por esta política.
Mas a aprovação de conexões de ponto final privadas compatíveis 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 sua carga útil. É recomendável usar o Gerenciador de Recursos do Azure, 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 para 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.
É recomendável usar um efeito Auditoria em vez de um efeito Negar na definição de política usada na atenuação do cenário dois. Essa alteração ajuda você a acompanhar os 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 respetivos escopos da plataforma de dados.
Azure Data Factory
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')]"
}
Esta política nega pontos de extremidade privados gerenciados vinculados a serviços, que são 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 list parâmetro e usando a "notIn": "[parameters('allowedSubscriptions')]" construção. Recomendamos essa alteração para o escopo da plataforma de dados dentro do locatário ou ambientes onde os serviços com redes virtuais gerenciadas e pontos de extremidade privados gerenciados são amplamente usados.
É recomendável atribuir essa política ao grupo de gerenciamento de nível superior e usar 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. Recomendamos a aplicação de 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 para 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 vinculados a serviços, que são hospedados no locatário do cliente.
Estas políticas estão agora disponíveis como incorporadas.
Os espaços de trabalho do Azure Synapse devem permitir o tráfego de dados de saída apenas para destinos aprovados.
ID da definição:
/providers/Microsoft.Authorization/policyDefinitions/3484ce98-c0c5-4c83-994b-c5ac24785218Os pontos de extremidade privados gerenciados do 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
É recomendável atribuir a política ao grupo de gerenciamento de nível superior e usar isenções quando necessário.
Próximos passos
É 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 adicional.