Limitare le connessioni degli endpoint privati tra tenant in Azure
I clienti usano sempre più endpoint privati nei tenant per connettersi ai propri servizi di Azure platform as a service (PaaS) in modo privato e sicuro. Gli endpoint privati possono connettersi ai servizi nei tenant di Microsoft Entra. Per motivi di sicurezza e conformità, potrebbe essere necessario bloccare le connessioni tra tenant di Microsoft Entra sugli endpoint privati. Queste indicazioni illustrano le opzioni di configurazione consigliate per limitare o impedire le connessioni tra endpoint privati tra tenant. Queste opzioni consentono di creare controlli di prevenzione della perdita dei dati (DLP) all'interno dell'ambiente Azure.
Introduzione agli endpoint privati
Usare gli endpoint privati per controllare il traffico all'interno dell'ambiente Azure usando un perimetro di rete esistente. Esistono tuttavia scenari in cui è necessario mantenere solo le connessioni endpoint private all'interno del tenant Microsoft Entra aziendale. Negli esempi seguenti vengono mostrate le connessioni che potrebbero creare rischi per la sicurezza.
- Connessione A: un amministratore non autorizzato crea endpoint privati nella rete virtuale del cliente. Questi endpoint si collegano a servizi ospitati all'esterno dell'ambiente del cliente, ad esempio un altro tenant di Microsoft Entra.
- Connessione ion B: Un amministratore non autorizzato crea endpoint privati in altri tenant di Microsoft Entra che collegano ai servizi ospitati nel tenant di Microsoft Entra del cliente.
Figura 1: illustrazione di scenari tra tenant di endpoint privati.
Per entrambi gli scenari, specificare l'ID risorsa del servizio e approvare manualmente la connessione all'endpoint privato. Gli utenti richiedono anche l'accesso al controllo degli accessi in base al ruolo per eseguire queste azioni.
Connessione ions C e D nella figura 1 mostrano scenari che i clienti vogliono in genere consentire. Le connessioni all'endpoint privato vengono mantenute all'interno del tenant Microsoft Entra aziendale. Non rappresentano un rischio per la sicurezza, quindi questi due scenari non sono trattati in questo articolo.
Le informazioni seguenti offrono opzioni per impedire il provisioning di endpoint privati nei tenant di Microsoft Entra.
Negare gli endpoint privati collegati ai servizi in altri tenant
Scenario uno: un amministratore non autorizzato richiede i diritti seguenti in una sottoscrizione nel tenant di Microsoft Entra del cliente.
- Diritti Microsoft.Network/virtualNetworks/join/action in una subnet con privateEndpointNetworkPolicies impostato su Disattivato.
- Accesso Microsoft.Network/privateEndpoints/write a un gruppo di risorse nell'ambiente del cliente.
Con questi diritti, un amministratore non autorizzato può creare un endpoint privato nel tenant di Microsoft Entra del cliente. Questo endpoint privato si collega a un servizio in una sottoscrizione separata e a un tenant di Microsoft Entra. La figura 1 mostra questo scenario come connessione A.
Per questo scenario, l'utente configura un tenant Microsoft Entra esterno e una sottoscrizione di Azure. Successivamente, creano un endpoint privato nell'ambiente del cliente specificando manualmente l'ID risorsa del servizio. Infine, l'amministratore non autorizzato approva l'endpoint privato nel servizio collegato ospitato nel tenant Esterno di Microsoft Entra per consentire il traffico sulla connessione.
Dopo che l'amministratore non autorizzato approva la connessione all'endpoint privato, i dati aziendali possono essere copiati dalla rete virtuale aziendale a un servizio di Azure in un tenant Microsoft Entra esterno. Questo rischio per la sicurezza può verificarsi solo se l'accesso è stato concesso tramite il controllo degli accessi in base al ruolo di Azure.
Soluzione per lo scenario 1
Usare il Criteri di Azure seguente per bloccare automaticamente la possibilità di creare un endpoint privato nel tenant Microsoft Entra aziendale collegato a un servizio esterno di 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"
}
Questo criterio nega gli endpoint privati creati all'esterno della sottoscrizione del servizio collegato, ad esempio le connessioni A e D. I criteri offrono anche la flessibilità necessaria per usare manualPrivateLinkServiceConnections e privateLinkServiceConnections.
È possibile aggiornare questo criterio in modo che gli endpoint privati vengano creati solo in un determinato set di sottoscrizioni. È possibile apportare questa modifica aggiungendo un list parametro e usando il "notIn": "[parameters('allowedSubscriptions')]" costrutto . Tuttavia, questo approccio non è consigliato, perché significa che è necessario mantenere costantemente l'elenco di sottoscrizioni per questo criterio. Ogni volta che viene creata una nuova sottoscrizione all'interno del tenant, è necessario aggiungere l'ID sottoscrizione al parametro .
Assegnare invece i criteri al gruppo di gestione di primo livello e quindi usare le esenzioni se necessario.
Considerazioni per lo scenario 1
Questo criterio blocca la possibilità di creare endpoint privati che si trovano in una sottoscrizione diversa rispetto al servizio stesso. Se questi endpoint sono necessari per determinati casi d'uso, usare le esenzioni dei criteri. Creare altri criteri per Data Factory e Azure Synapse per assicurarsi che gli endpoint privati gestiti ospitati nella rete virtuale gestita possano connettersi solo ai servizi ospitati all'interno del tenant di Microsoft Entra.
Negare le connessioni da endpoint privati creati in altri tenant
Scenario 2: un amministratore non autorizzato richiede l'accesso in scrittura al servizio nell'ambiente del cliente per cui deve essere creato un endpoint privato.
Con questo diritto, un amministratore non autorizzato può creare un endpoint privato in un tenant e una sottoscrizione Microsoft Entra esterni. Questo endpoint si collega a un servizio nel tenant Microsoft Entra del cliente. La figura 1 mostra questo scenario come connessione B.
In questo scenario, l'amministratore non autorizzato deve prima configurare un tenant Microsoft Entra privato esterno e una sottoscrizione di Azure. Successivamente, creano un endpoint privato nel proprio ambiente specificando manualmente l'ID risorsa e l'ID gruppo del servizio nel tenant Microsoft Entra aziendale. Infine, approvano l'endpoint privato nel servizio collegato per consentire il traffico attraverso la connessione tra i tenant di Microsoft Entra.
Dopo che l'amministratore o il proprietario del servizio non autorizzato approva l'endpoint privato, i dati vengono accessibili dalla rete virtuale esterna.
Soluzione per lo scenario 2
Usare criteri specifici del servizio per evitare questo scenario nel tenant del cliente. Le connessioni endpoint private sono sottorisorse dei rispettivi servizi e vengono mostrate nella relativa sezione delle proprietà. Negare le connessioni non conformi usando la definizione di criteri seguente:
"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"
}
Questo criterio mostra un esempio per Archiviazione di Azure. Replicare la stessa definizione di criteri per altri servizi, ad esempio Key Vault, servizi cognitivi e SQL Server. Si noti che app Azure Servizio non supporta questa mitigazione in questo momento.
Per migliorare ulteriormente la gestibilità, aggregare i criteri specifici del servizio in un'iniziativa. Il criterio nega l'approvazione delle connessioni di endpoint privati agli endpoint privati ospitati all'esterno della sottoscrizione del rispettivo servizio. Non nega il rifiuto o la rimozione di connessioni endpoint private, ovvero il comportamento desiderato dai clienti. I flussi di lavoro di approvazione automatica, ad esempio la connessione C, non sono interessati da questo criterio.
Tuttavia, l'approvazione delle connessioni endpoint private conformi all'interno del portale viene bloccata con questo metodo. Questo blocco si verifica perché l'interfaccia utente del portale non invia l'ID risorsa dell'endpoint privato connesso nel payload. È consigliabile usare Azure Resource Manager, Azure PowerShell o l'interfaccia della riga di comando di Azure per approvare la connessione all'endpoint privato.
Assegnare inoltre i criteri al gruppo di gestione di primo livello e usare le esenzioni, se necessario.
Considerazioni per lo scenario 2
Azure Synapse Analytics e Azure Data Factory offrono reti virtuali gestite ed endpoint privati gestiti. Grazie a queste nuove funzionalità, i criteri bloccano l'utilizzo sicuro e privato di questi servizi.
È consigliabile usare un effetto Audit anziché un effetto Deny nella definizione dei criteri usata nello scenario due mitigazioni. Questa modifica consente di tenere traccia degli endpoint privati creati in sottoscrizioni e tenant separati. È anche possibile usare le esenzioni dei criteri per i rispettivi ambiti della piattaforma dati.
Azure Data Factory
Per superare lo scenario 1 nella rete virtuale gestita di Azure Data Factory, usare la definizione di criteri seguente:
"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')]"
}
Questo criterio nega gli endpoint privati gestiti collegati ai servizi, ospitati all'esterno della sottoscrizione di Data Factory. È possibile modificare questo criterio per consentire le connessioni ai servizi ospitati in un set di sottoscrizioni aggiungendo un parametro list e usando il costrutto "notIn": "[parameters('allowedSubscriptions')]". Questa modifica è consigliabile per l'ambito della piattaforma dati all'interno del tenant o degli ambienti in cui i servizi con reti virtuali gestite e endpoint privati gestiti vengono ampiamente usati.
È consigliabile assegnare questo criterio al gruppo di gestione di primo livello e usare le esenzioni, se necessario. Per la piattaforma dati, apportare queste modifiche e assegnare i criteri al set di sottoscrizioni della piattaforma dati.
Azure Synapse
Azure Synapse usa anche reti virtuali gestite. È consigliabile applicare criteri simili ai criteri di Data Factory per lo scenario 1. Azure Synapse non fornisce un alias di criteri per gli endpoint privati gestiti. Esiste tuttavia una funzionalità di prevenzione dell'esfiltrazione dei dati, che può essere applicata per le aree di lavoro usando i criteri seguenti:
"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"
}
Questo criterio applica l'uso della funzionalità di esfiltrazione di dati di Azure Synapse. Con Azure Synapse, è possibile negare qualsiasi endpoint privato proveniente da un servizio ospitato all'esterno del tenant del cliente. È anche possibile negare qualsiasi endpoint privato ospitato all'esterno di un set specificato di ID tenant. Questo criterio consente solo la creazione di endpoint privati gestiti collegati a servizi ospitati nel tenant del cliente.
Questi criteri sono ora disponibili come predefiniti.
Le aree di lavoro Azure Synapse devono consentire solo il traffico dati in uscita verso le destinazioni approvate.
ID definizione:
/providers/Microsoft.Authorization/policyDefinitions/3484ce98-c0c5-4c83-994b-c5ac24785218Gli endpoint privati gestiti da Azure Synapse devono connettersi solo alle risorse nei tenant approvati di Microsoft Entra.
ID definizione:
/providers/Microsoft.Authorization/policyDefinitions/3a003702-13d2-4679-941b-937e58c443f0
È consigliabile assegnare i criteri al gruppo di gestione di primo livello e usare le esenzioni dove necessario.
Passaggi successivi
È importante comprendere i modelli di connettività consigliati per la connettività in ingresso e in uscita da e verso la rete Internet pubblica. L'articolo successivo esamina le considerazioni di progettazione, le raccomandazioni di progettazione e il contenuto consigliato per un'ulteriore lettura.