Desafio 38: Service endpoints e políticas
45-60 minutos | ~$0,01 (sem custo adicional para service endpoints) | Peso do exame: 10-15%
Cenário
A Fourth Coffee é uma empresa de serviços financeiros preocupada com exfiltração de dados. As equipes de desenvolvimento possuem VMs no Azure que acessam contas de Azure Storage, mas a equipe de segurança descobriu que os desenvolvedores poderiam copiar dados para contas de armazenamento não autorizadas. A empresa deseja usar políticas de service endpoint para restringir o acesso de saída de suas sub-redes apenas a contas de armazenamento aprovadas, além de entender quando Private Endpoints podem ser mais adequados.
Sua tarefa é habilitar service endpoints, criar políticas que restrinjam o acesso a contas de armazenamento específicas e validar que contas de armazenamento não autorizadas sejam bloqueadas. Você também comparará service endpoints com Private Endpoints para recomendar a melhor abordagem para diferentes cenários.
Service endpoints vs Private Endpoints
| Recurso | Service Endpoints | Private Endpoints |
|---|---|---|
| Caminho do tráfego | Rota otimizada pelo backbone do Azure, ainda usa IP público do PaaS | Tráfego vai para um IP privado na sua VNet |
| DNS | Nenhuma alteração de DNS necessária | Requer zona de Private DNS ou DNS personalizado |
| Acesso local (on-premises) | Não acessível do on-premises apenas via SE | Acessível do on-premises (com configuração de DNS) |
| Custo | Gratuito | ~$0,01/h por endpoint + processamento de dados |
| Proteção contra exfiltração de dados | Requer políticas de SE (limitado a Storage) | Inerente — tráfego permanece privado |
| IP visto pelo PaaS | IP da sub-rede da VNet (mudança de NAT de origem) | IP privado da VNet |
| Granularidade | Nível de sub-rede | Por recurso |
| Suporte de serviço para políticas | Apenas Azure Storage | N/A (inerentemente restrito) |
Tarefa 1: Criar contas de armazenamento e uma VNet com service endpoints
Azure CLI
# Variables
RG="rg-challenge38"
LOCATION="eastus"
VNET_NAME="vnet-workload"
SUBNET_NAME="snet-app"
ALLOWED_STORAGE="stallowedc38$(shuf -i 1000-9999 -n 1)"
BLOCKED_STORAGE="stblockedc38$(shuf -i 1000-9999 -n 1)"
# Create resource group
az group create --name $RG --location $LOCATION
# Create two storage accounts (one allowed, one to be blocked)
az storage account create \
--resource-group $RG \
--name $ALLOWED_STORAGE \
--location $LOCATION \
--sku Standard_LRS \
--kind StorageV2
az storage account create \
--resource-group $RG \
--name $BLOCKED_STORAGE \
--location $LOCATION \
--sku Standard_LRS \
--kind StorageV2
# Create VNet and subnet with Microsoft.Storage service endpoint enabled
az network vnet create \
--resource-group $RG \
--name $VNET_NAME \
--location $LOCATION \
--address-prefixes "10.1.0.0/16" \
--subnet-name $SUBNET_NAME \
--subnet-prefixes "10.1.0.0/24"
# Enable service endpoint on the subnet
az network vnet subnet update \
--resource-group $RG \
--vnet-name $VNET_NAME \
--name $SUBNET_NAME \
--service-endpoints Microsoft.Storage
Azure PowerShell
# Variables
$rg = "rg-challenge38"
$location = "eastus"
$vnetName = "vnet-workload"
$subnetName = "snet-app"
$allowedStorage = "stallowedc38$(Get-Random -Minimum 1000 -Maximum 9999)"
$blockedStorage = "stblockedc38$(Get-Random -Minimum 1000 -Maximum 9999)"
# Create resource group
New-AzResourceGroup -Name $rg -Location $location
# Create storage accounts
New-AzStorageAccount -ResourceGroupName $rg -Name $allowedStorage `
-Location $location -SkuName Standard_LRS -Kind StorageV2
New-AzStorageAccount -ResourceGroupName $rg -Name $blockedStorage `
-Location $location -SkuName Standard_LRS -Kind StorageV2
# Create VNet
$subnet = New-AzVirtualNetworkSubnetConfig `
-Name $subnetName `
-AddressPrefix "10.1.0.0/24" `
-ServiceEndpoint "Microsoft.Storage"
New-AzVirtualNetwork `
-ResourceGroupName $rg `
-Name $vnetName `
-Location $location `
-AddressPrefix "10.1.0.0/16" `
-Subnet $subnet
Portal
- Crie um grupo de recursos
rg-challenge38em East US. - Crie duas contas de armazenamento: uma com "allowed" e outra com "blocked" no nome.
- Crie uma VNet
vnet-workloadcom espaço de endereço10.1.0.0/16. - Adicione a sub-rede
snet-appcom prefixo10.1.0.0/24. - Nas configurações da sub-rede, em Service endpoints, adicione
Microsoft.Storage.
Tarefa 2: Criar uma política de service endpoint
As políticas de service endpoint restringem quais contas de Azure Storage podem ser acessadas a partir de uma sub-rede via service endpoints.
Azure CLI
# Get the allowed storage account resource ID
ALLOWED_STORAGE_ID=$(az storage account show \
--name $ALLOWED_STORAGE \
--resource-group $RG \
--query id --output tsv)
# Create a service endpoint policy
az network service-endpoint policy create \
--resource-group $RG \
--name "sep-allowed-storage" \
--location $LOCATION
# Add a policy definition restricting to the allowed storage account
az network service-endpoint policy-definition create \
--resource-group $RG \
--policy-name "sep-allowed-storage" \
--name "allow-specific-storage" \
--service "Microsoft.Storage" \
--service-resources $ALLOWED_STORAGE_ID
Azure PowerShell
# Get the allowed storage account resource ID
$storageAccount = Get-AzStorageAccount -ResourceGroupName $rg -Name $allowedStorage
$resourceId = $storageAccount.Id
# Create the policy definition
$policyDefinition = New-AzServiceEndpointPolicyDefinition `
-Name "allow-specific-storage" `
-Description "Allow only approved storage account" `
-Service "Microsoft.Storage" `
-ServiceResource $resourceId
# Create the service endpoint policy
$sepolicy = New-AzServiceEndpointPolicy `
-ResourceGroupName $rg `
-Name "sep-allowed-storage" `
-Location $location `
-ServiceEndpointPolicyDefinition $policyDefinition
Portal
- Pesquise por Service endpoint policies e selecione + Create.
- Defina o grupo de recursos como
rg-challenge38, nome comosep-allowed-storage, região como East US. - Selecione Next: Policy definitions.
- Selecione + Add a resource:
- Service:
Microsoft.Storage - Scope: Single account
- Selecione a conta de armazenamento permitida.
- Service:
- Selecione Add, depois Review + create e então Create.
Tarefa 3: Associar a política à sub-rede
Azure CLI
# Associate the service endpoint policy to the subnet
az network vnet subnet update \
--resource-group $RG \
--vnet-name $VNET_NAME \
--name $SUBNET_NAME \
--service-endpoints Microsoft.Storage \
--service-endpoint-policy "sep-allowed-storage"
Azure PowerShell
$virtualNetwork = Get-AzVirtualNetwork -ResourceGroupName $rg -Name $vnetName
Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $virtualNetwork `
-Name $subnetName `
-AddressPrefix "10.1.0.0/24" `
-ServiceEndpoint "Microsoft.Storage" `
-ServiceEndpointPolicy $sepolicy
$virtualNetwork | Set-AzVirtualNetwork
Portal
- Navegue até a política de service endpoint
sep-allowed-storage. - Expanda Settings e selecione Associated subnets.
- Selecione + Edit subnet association.
- Selecione a VNet
vnet-workloade a sub-redesnet-app. - Selecione Apply.
Uma vez que uma política de service endpoint é aplicada a uma sub-rede, todo o acesso ao armazenamento via service endpoint é restrito apenas às contas listadas na política. Certifique-se de que todas as contas de armazenamento necessárias estejam incluídas antes de aplicar a política.
Tarefa 4: Configurar o firewall da conta de armazenamento com regras de VNet
Azure CLI
# Set default action to Deny on the allowed storage account
az storage account update \
--resource-group $RG \
--name $ALLOWED_STORAGE \
--default-action Deny
# Add a VNet rule allowing access from the subnet
az storage account network-rule add \
--resource-group $RG \
--account-name $ALLOWED_STORAGE \
--vnet-name $VNET_NAME \
--subnet $SUBNET_NAME
Azure PowerShell
# Set default action to Deny
Update-AzStorageAccountNetworkRuleSet `
-ResourceGroupName $rg `
-Name $allowedStorage `
-DefaultAction Deny
# Add VNet rule
$subnet = Get-AzVirtualNetwork -ResourceGroupName $rg -Name $vnetName | `
Get-AzVirtualNetworkSubnetConfig -Name $subnetName
Add-AzStorageAccountNetworkRule `
-ResourceGroupName $rg `
-Name $allowedStorage `
-VirtualNetworkResourceId $subnet.Id
Portal
- Navegue até a conta de armazenamento permitida.
- Em Security + networking, selecione Networking.
- Defina Public network access como Enabled from selected virtual networks and IP addresses.
- Em Virtual networks, selecione + Add existing virtual network.
- Selecione a VNet
vnet-workloade a sub-redesnet-app. - Selecione Add e depois Save.
Tarefa 5: Validar a política de service endpoint
Implante uma VM de teste na sub-rede e verifique se apenas a conta de armazenamento permitida está acessível.
# Create a test VM in the subnet
az vm create \
--resource-group $RG \
--name "vm-test" \
--image Ubuntu2204 \
--vnet-name $VNET_NAME \
--subnet $SUBNET_NAME \
--admin-username azureuser \
--generate-ssh-keys \
--size Standard_B1s \
--no-wait
# After VM is running, SSH in and test connectivity
# This should SUCCEED (allowed storage account)
curl -s -o /dev/null -w "%{http_code}" \
"https://$ALLOWED_STORAGE.blob.core.windows.net/?comp=list"
# Expected: 403 (auth required, but connection works)
# This should FAIL (blocked storage account - connection refused by SE policy)
curl -s -o /dev/null -w "%{http_code}" \
"https://$BLOCKED_STORAGE.blob.core.windows.net/?comp=list"
# Expected: connection timeout or drop (SE policy blocks it)
Cenários de quebra e correção
Cenário 1: Política de service endpoint bloqueando todo o acesso ao armazenamento
Sintoma: Após aplicar a política de service endpoint, nenhuma conta de armazenamento está acessível a partir da sub-rede — mesmo as contas "permitidas" retornam falhas de conexão.
Causa raiz: O valor de --service-resources na definição da política usa um formato de ID de recurso incorreto. O ID do recurso deve ser o ID completo do recurso ARM da conta de armazenamento.
Correção:
# Verify the policy definition has the correct resource ID
az network service-endpoint policy-definition show \
--resource-group $RG \
--policy-name "sep-allowed-storage" \
--name "allow-specific-storage" \
--query "serviceResources" -o tsv
# If incorrect, delete and recreate with the proper resource ID
az network service-endpoint policy-definition delete \
--resource-group $RG \
--policy-name "sep-allowed-storage" \
--name "allow-specific-storage"
CORRECT_ID=$(az storage account show --name $ALLOWED_STORAGE --resource-group $RG --query id -o tsv)
az network service-endpoint policy-definition create \
--resource-group $RG \
--policy-name "sep-allowed-storage" \
--name "allow-specific-storage" \
--service "Microsoft.Storage" \
--service-resources $CORRECT_ID

**Insight principal**: Service endpoints e regras de VNet funcionam juntos. O service endpoint na sub-rede otimiza a rota, e a regra de VNet na conta de armazenamento concede o acesso. Ambos devem estar configurados.
---
### Cenário 3: Restrição de acesso do App Service usando SE, mas tráfego da internet ainda funciona
**Sintoma**: Um App Service tem uma restrição de acesso baseada em service endpoint configurada, mas clientes da internet ainda conseguem acessar a aplicação.
**Causa raiz**: As regras de restrição de acesso possuem uma regra "Allow All" com prioridade mais alta, ou a regra deny-all está ausente. O App Service processa as regras em ordem de prioridade e para na primeira correspondência.
**Correção**:
Verifique as regras de restrição de acesso e certifique-se de que uma regra deny-all existe com a prioridade mais baixa:
```bash
# List current access restrictions
az webapp config access-restriction show \
--resource-group $RG \
--name "app-name" \
--query "ipSecurityRestrictions[].{priority:priority, name:name, action:action, ip:ipAddress, vnetSubnetResourceId:vnetSubnetResourceId}" -o table
# Add a deny-all rule with lowest priority (highest number)
az webapp config access-restriction add \
--resource-group $RG \
--name "app-name" \
--priority 999 \
--action Deny \
--ip-address "0.0.0.0/0" \
--rule-name "DenyAll"
Insight principal: As restrições de acesso do App Service são processadas de cima para baixo por número de prioridade (número mais baixo = prioridade mais alta). Há um "Allow All" implícito no final, a menos que você negue explicitamente. Sempre adicione uma regra catch deny-all.
Verificação de conhecimento
1. Qual é a principal vantagem das políticas de service endpoint em relação aos service endpoints sozinhos?
2. Qual serviço Azure atualmente suporta políticas de service endpoint para proteção contra exfiltração de dados?
3. Como o roteamento de tráfego muda quando um service endpoint é habilitado em uma sub-rede?
4. Uma empresa precisa que clientes locais acessem o Azure Storage de forma privada. Qual abordagem devem usar?
5. O que acontece se você associar uma política de service endpoint a uma sub-rede, mas esquecer de incluir uma conta de armazenamento necessária na política?
6. Qual afirmação sobre service endpoints e Private Endpoints está correta?
Limpeza
# Delete all resources
az group delete --name rg-challenge38 --yes --no-wait
# PowerShell cleanup
Remove-AzResourceGroup -Name "rg-challenge38" -Force -AsJob
Service endpoints e políticas de service endpoint não têm custo adicional. No entanto, a VM de teste e as contas de armazenamento geram cobranças mínimas. Exclua o grupo de recursos após concluir este desafio.
Resumo
Neste desafio, você configurou service endpoints com políticas para prevenir exfiltração de dados para contas de armazenamento não autorizadas. Você aprendeu como as políticas de service endpoint restringem o acesso de saída no nível da sub-rede, como as regras de VNet nas contas de armazenamento concedem acesso de entrada, e as distinções importantes entre service endpoints e Private Endpoints. Entender quando usar cada abordagem — e suas limitações — é um tópico essencial no exame AZ-700.