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 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. 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 ajudam você a criar controles de prevenção de vazamento de dados (DLP) dentro do seu ambiente do 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ê deve manter conexões de ponto de extremidade privadas somente no 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 de extremidade 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 privada. 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 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 fornecem 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 não autorizado requer os seguintes direitos 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 não autorizado pode criar um ponto de extremidade privado no locatário do Microsoft Entra do cliente. Esse ponto de extremidade privado se vincula a um serviço em uma assinatura separada e 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 a 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 privada, 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ó poderá ocorrer se o acesso tiver sido concedido usando o RBAC do Azure.
Mitigação do cenário um
Use a Política do Azure a seguir 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"
}
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 apenas em um determinado conjunto de assinaturas. Você pode fazer essa alteração adicionando um list parâmetro e usando 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 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 sobre o cenário um
Essa 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 uma assinatura externos do Microsoft Entra. Esse ponto de extremidade vincula 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 pela conexão entre locatários do Microsoft Entra.
Depois que o administrador não autorizado ou o proprietário do serviço aprovar o ponto de extremidade privado, os dados serão acessados 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. 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 Microsoft 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 mitigaçã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 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 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 seu conteúdo. É 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 privada.
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.
É recomendável usar um efeito de auditoria em vez de um efeito de negação na definição de política usada na mitigação do cenário dois. Essa alteração ajuda você a controlar 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 respectivos escopos de 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')]"
}
Essa política nega pontos de extremidade privados gerenciados 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.
É 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. É 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 imposto 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 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 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ó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.