Pular para o conteúdo principal

Laboratório Hands-on Guiado: AZ-104 — Microsoft Azure Administrator

Cenário​

A Contoso Saúde Ltda. é uma empresa brasileira de telemedicina que armazena prontuários eletrônicos, imagens de exames e relatórios financeiros em contas de armazenamento do Azure. A empresa opera em duas regiões (Brazil South e East US 2) para atender requisitos de conformidade e continuidade de negócios. O ambiente Azure atual conta apenas com uma assinatura ativa, uma rede virtual com duas sub-redes e um grupo de recursos vazio aguardando a implantação da infraestrutura de armazenamento.

A meta técnica deste laboratório é projetar, implantar e proteger toda a camada de Azure Storage da Contoso Saúde, garantindo redundância geográfica, controle granular de acesso via rede e identidade, criptografia adequada, replicação de objetos entre regiões e operações de transferência de dados em larga escala. Ao final, o ambiente estará pronto para produção, com todas as políticas de acesso validadas por testes comportamentais reais.

Pré-requisitos​

Antes de iniciar a Fase 1, crie ou confirme a existência de todos os recursos listados abaixo. Todos devem residir na mesma assinatura.

  1. Resource Group: crie o grupo de recursos rg-contososaude-lab na região Brazil South.

Via Portal​

Navegue até Portal do Azure > Pesquise "Resource groups" > Clique em "+ Create" > Preencha Subscription com a sua assinatura ativa, Resource group com rg-contososaude-lab, Region com Brazil South > Clique em "Review + create" > Clique em "Create".

Via CLI​

az group create \
  --name rg-contososaude-lab \
  --location brazilsouth
  1. Resource Group secundário: crie o grupo rg-contososaude-dr na região East US 2 (será usado para replicação entre regiões).

Via Portal​

Repita o processo anterior com o nome rg-contososaude-dr e região East US 2.

Via CLI​

az group create \
  --name rg-contososaude-dr \
  --location eastus2
  1. Virtual Network: crie a VNet vnet-contososaude no grupo rg-contososaude-lab com o espaço de endereçamento 10.0.0.0/16 e duas sub-redes:

Via Portal​

Navegue até "Virtual networks" > Clique em "+ Create" > Preencha Resource group com rg-contososaude-lab, Name com vnet-contososaude, Region com Brazil South > Na aba IP addresses, configure Address space 10.0.0.0/16 > Adicione a sub-rede snet-app com intervalo 10.0.1.0/24 > Adicione a sub-rede snet-data com intervalo 10.0.2.0/24 > Clique em "Review + create" > Clique em "Create".

Via CLI​

az network vnet create \
  --resource-group rg-contososaude-lab \
  --name vnet-contososaude \
  --address-prefix 10.0.0.0/16 \
  --location brazilsouth

az network vnet subnet create \
  --resource-group rg-contososaude-lab \
  --vnet-name vnet-contososaude \
  --name snet-app \
  --address-prefixes 10.0.1.0/24

az network vnet subnet create \
  --resource-group rg-contososaude-lab \
  --vnet-name vnet-contososaude \
  --name snet-data \
  --address-prefixes 10.0.2.0/24

  1. Ferramentas locais: confirme a instalação do Azure CLI (versão 2.50+), AzCopy (versão 10+) e Azure Storage Explorer (versão mais recente) na sua máquina local.

  2. Conta Microsoft Entra ID: confirme que seu usuário possui a role Owner ou Contributor + User Access Administrator na assinatura utilizada.

Tabela de Referência de Recursos​

RecursoNome no LabRegião
Resource Group (primário)rg-contososaude-labBrazil South
Resource Group (DR)rg-contososaude-drEast US 2
Virtual Networkvnet-contososaudeBrazil South
Sub-rede aplicaçãosnet-appBrazil South
Sub-rede dadossnet-dataBrazil South
Storage Account (primário)stcontososaude01Brazil South
Storage Account (secundário)stcontososaude02East US 2
Storage Account (Files)stcontosofiles01Brazil South
Blob Container (prontuários)prontuariosBrazil South
Blob Container (exames)examesBrazil South
Blob Container (réplica)examesEast US 2
File SharefinanceiroBrazil South
Stored Access Policypolicy-leitura-prontuariosBrazil South

Fases do Laboratório​

Fase 1 — Criação e Configuração de Contas de Armazenamento​

Nesta fase você criará as contas de armazenamento que servirão de base para todo o laboratório. Serão criadas três contas com configurações distintas de redundância e performance, cobrindo os objetivos Create and configure storage accounts e Configure Azure Storage redundancy. Todos os recursos subsequentes dependem dessas contas.

Tarefa 1.1 — Criar a conta de armazenamento primária com redundância GRS​

A Contoso Saúde precisa de uma conta de armazenamento primária em Brazil South para armazenar prontuários e exames. Como os dados são críticos, a redundância deve ser GRS (Geo-Redundant Storage) para garantir cópias em uma região pareada.

Via Portal​

  1. Navegue até Portal do Azure > Pesquise "Storage accounts" > Clique em "+ Create".
  2. Na aba Basics, preencha: Resource group com rg-contososaude-lab, Storage account name com stcontososaude01, Region com Brazil South, Performance com Standard, Redundancy com Geo-redundant storage (GRS).
  3. Na aba Advanced, mantenha "Require secure transfer for REST API operations" habilitado, mantenha "Allow enabling public access on containers" habilitado (será restringido posteriormente), configure Minimum TLS version como Version 1.2, habilite "Enable blob public access" como Disabled.
  4. Na aba Networking, selecione "Public endpoint (all networks)" temporariamente (será restringido na Fase 2).
  5. Clique em "Review" > Clique em "Create".

Via CLI​

az storage account create \
  --name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --location brazilsouth \
  --sku Standard_GRS \
  --kind StorageV2 \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false \
  --https-only true

O parâmetro --sku Standard_GRS configura a redundância geográfica com seis cópias dos dados (três em Brazil South, três na região pareada). O parâmetro --allow-blob-public-access false impede o acesso público anônimo a contêineres e blobs.

Tarefa 1.2 — Criar a conta de armazenamento secundária (DR) com redundância LRS​

Para a replicação de objetos entre regiões, a Contoso Saúde necessita de uma conta de destino em East US 2. Esta conta utiliza LRS porque já recebe dados replicados da conta primária GRS, e o custo deve ser otimizado.

Via Portal​

  1. Navegue até "Storage accounts" > Clique em "+ Create".
  2. Preencha: Resource group com rg-contososaude-dr, Storage account name com stcontososaude02, Region com East US 2, Performance com Standard, Redundancy com Locally-redundant storage (LRS).
  3. Na aba Advanced, configure os mesmos padrões de segurança da conta primária (TLS 1.2, secure transfer habilitado, blob public access desabilitado).
  4. Clique em "Review" > Clique em "Create".

Via CLI​

az storage account create \
  --name stcontososaude02 \
  --resource-group rg-contososaude-dr \
  --location eastus2 \
  --sku Standard_LRS \
  --kind StorageV2 \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false \
  --https-only true

Tarefa 1.3 — Criar a conta de armazenamento para Azure Files e validar configurações de redundância​

A Contoso Saúde precisa de um file share para a equipe financeira. Esta conta usa ZRS (Zone-Redundant Storage) para alta disponibilidade local sem o custo da geo-redundância.

Via Portal​

  1. Navegue até "Storage accounts" > Clique em "+ Create".
  2. Preencha: Resource group com rg-contososaude-lab, Storage account name com stcontosofiles01, Region com Brazil South, Performance com Standard, Redundancy com Zone-redundant storage (ZRS).
  3. Clique em "Review" > Clique em "Create".

Via CLI​

az storage account create \
  --name stcontosofiles01 \
  --resource-group rg-contososaude-lab \
  --location brazilsouth \
  --sku Standard_ZRS \
  --kind StorageV2 \
  --min-tls-version TLS1_2 \
  --https-only true
  1. Validação: após a criação das três contas, verifique as configurações de redundância de cada uma.

Via Portal​

Navegue até cada conta de armazenamento > Clique em "Redundancy" no menu lateral > Confirme que stcontososaude01 exibe GRS, stcontososaude02 exibe LRS e stcontosofiles01 exibe ZRS.

Via CLI​

az storage account show --name stcontososaude01 --resource-group rg-contososaude-lab --query "sku.name" -o tsv
# Esperado: Standard_GRS

az storage account show --name stcontososaude02 --resource-group rg-contososaude-dr --query "sku.name" -o tsv
# Esperado: Standard_LRS

az storage account show --name stcontosofiles01 --resource-group rg-contososaude-lab --query "sku.name" -o tsv
# Esperado: Standard_ZRS

Tarefa 1.4 — Alterar a redundância e validar a transição de estado​

O time de arquitetura da Contoso Saúde decidiu que a conta stcontososaude01 deve ser promovida de GRS para RA-GRS (Read-Access Geo-Redundant Storage) para permitir leitura na região secundária em caso de desastre. Antes de executar a mudança, valide o estado atual.

  1. Confirme o estado atual: verifique que a conta stcontososaude01 está configurada como GRS (não RA-GRS). Se o output do passo anterior já confirmou isso, prossiga.

Via Portal​

  1. Navegue até stcontososaude01 > Clique em "Redundancy" > No dropdown Redundancy, selecione "Read-access geo-redundant storage (RA-GRS)" > Clique em "Save".
  2. Após salvar, observe que o campo Secondary endpoint agora aparece preenchido na seção de propriedades.

Via CLI​

# Verificar estado antes da mudança
az storage account show --name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --query "sku.name" -o tsv
# Esperado: Standard_GRS

# Aplicar a mudança para RA-GRS
az storage account update \
  --name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --sku Standard_RAGRS

# Verificar estado após a mudança
az storage account show --name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --query "{sku:sku.name, secondaryEndpoints:secondaryEndpoints.blob}" -o json
# Esperado: sku = Standard_RAGRS e secondaryEndpoints preenchido

A promoção de GRS para RA-GRS não causa downtime e habilita um endpoint de leitura secundário. Esse endpoint pode ser usado por aplicações para failover de leitura quando a região primária estiver indisponível.

Fase 2 — Segurança de Rede e Firewalls de Armazenamento​

Nesta fase você restringirá o acesso às contas de armazenamento criadas na Fase 1 usando firewalls e regras de rede virtual. Os objetivos cobertos são Configure Azure Storage firewalls and virtual networks. Os recursos stcontososaude01, stcontosofiles01 e vnet-contososaude serão utilizados.

Tarefa 2.1 — Habilitar o Service Endpoint na sub-rede e configurar firewall da conta primária​

Atualmente, a conta stcontososaude01 aceita conexões de todas as redes (estado padrão). Você deve restringir o acesso apenas à sub-rede snet-data da VNet da Contoso Saúde e ao seu IP público atual.

  1. Verifique o estado atual de acesso à rede:

Via Portal​

Navegue até stcontososaude01 > Clique em "Networking" > Confirme que a opção "Enabled from all networks" está selecionada.

Via CLI​

az storage account show --name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --query "networkRuleSet.defaultAction" -o tsv
# Esperado: Allow
  1. Habilite o Service Endpoint na sub-rede snet-data:

Via Portal​

Navegue até "Virtual networks" > Selecione vnet-contososaude > Clique em "Subnets" > Selecione snet-data > Em Service endpoints, adicione Microsoft.Storage > Clique em "Save".

Via CLI​

az network vnet subnet update \
  --resource-group rg-contososaude-lab \
  --vnet-name vnet-contososaude \
  --name snet-data \
  --service-endpoints Microsoft.Storage
  1. Configure o firewall da conta de armazenamento:

Via Portal​

Navegue até stcontososaude01 > Clique em "Networking" > Selecione "Enabled from selected virtual networks and IP addresses" > Em Virtual networks, clique em "+ Add existing virtual network" > Selecione vnet-contososaude e sub-rede snet-data > Clique em "Add".

Em Firewall, preencha o campo "Address range" com o seu IP público atual (visível no topo da seção ou consulte curl ifconfig.me no terminal) > Clique em "Save".

Via CLI​

# Obter seu IP público
MY_IP=$(curl -s ifconfig.me)

# Alterar default action para Deny
az storage account update \
  --name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --default-action Deny

# Adicionar regra de rede para a sub-rede
az storage account network-rule add \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --vnet-name vnet-contososaude \
  --subnet snet-data

# Adicionar regra de IP para seu IP atual
az storage account network-rule add \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --ip-address $MY_IP

Após essa configuração, a conta stcontososaude01 rejeita qualquer conexão que não venha da sub-rede snet-data ou do seu IP público. O tráfego de outras redes e da internet pública será bloqueado.

Tarefa 2.2 — Testar o bloqueio de acesso e tratar cenário de acesso negado​

Para confirmar que o firewall está funcionando, você simulará um acesso de um IP não autorizado e verificará o comportamento de bloqueio.

  1. Crie um contêiner de teste para ter um recurso que possa ser acessado:

Via Portal​

Navegue até stcontososaude01 > Clique em "Containers" > Clique em "+ Container" > Preencha Name com teste-firewall, Public access level com Private > Clique em "Create".

Via CLI​

az storage container create \
  --name teste-firewall \
  --account-name stcontososaude01 \
  --auth-mode login
  1. Teste de acesso positivo (do seu IP, que está na whitelist):

Via CLI​

az storage container list \
  --account-name stcontososaude01 \
  --auth-mode login \
  --output table
# Esperado: lista de contêineres exibida com sucesso
  1. Teste de acesso negativo: remova temporariamente seu IP da whitelist e tente acessar novamente.

Via Portal​

Navegue até stcontososaude01 > Clique em "Networking" > Remova seu IP do campo Firewall > Clique em "Save". Aguarde 30 segundos.

Via CLI​

# Remover seu IP
az storage account network-rule remove \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --ip-address $MY_IP

# Aguardar propagação
sleep 30

# Tentar listar contêineres (deve falhar)
az storage container list \
  --account-name stcontososaude01 \
  --auth-mode login \
  --output table 2>&1
# Esperado: erro 403 Forbidden ou "This request is not authorized"
  1. Restaure o acesso: adicione seu IP de volta à whitelist.

Via CLI​

az storage account network-rule add \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --ip-address $MY_IP

Via Portal​

Navegue até stcontososaude01 > "Networking" > Readicione seu IP > Clique em "Save".

  1. Limpe o contêiner de teste:
az storage container delete \
  --name teste-firewall \
  --account-name stcontososaude01 \
  --auth-mode login

Esse teste comprova que o firewall de storage rejeita efetivamente o tráfego de IPs não autorizados. A propagação de regras de rede pode levar até 30 segundos.

Fase 3 — Criptografia e Chaves de Acesso​

Nesta fase você configurará a criptografia da conta de armazenamento primária e gerenciará as chaves de acesso. Os objetivos cobertos são Configure storage account encryption e Manage access keys. Você utilizará a conta stcontososaude01 criada na Fase 1.

Tarefa 3.1 — Verificar a criptografia padrão e configurar escopo de criptografia​

Antes de criar contêineres de produção, a Contoso Saúde precisa garantir que a criptografia está ativa e criar um escopo de criptografia separado para dados de exames, permitindo futura migração para chaves gerenciadas pelo cliente (CMK).

  1. Verifique a criptografia padrão:

Via Portal​

Navegue até stcontososaude01 > Clique em "Encryption" > Confirme que Encryption type está configurado como Microsoft-managed keys (MMK) e que Infrastructure encryption está como Not enabled.

Via CLI​

az storage account show --name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --query "encryption.{keySource:keySource, services:services}" -o json
# Esperado: keySource = Microsoft.Storage
  1. Crie um escopo de criptografia para exames:

Via Portal​

Navegue até stcontososaude01 > Clique em "Encryption scopes" > Clique em "+ Add" > Preencha Name com scope-exames, Encryption type com Microsoft-managed keys > Clique em "Create".

Via CLI​

az storage account encryption-scope create \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --name scope-exames \
  --key-source Microsoft.Storage
  1. Verifique o estado do escopo:
az storage account encryption-scope list \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --query "[].{name:name, state:state, source:source}" -o table
# Esperado: scope-exames com state = Enabled

O escopo de criptografia permite isolar a criptografia de contêineres específicos. Quando for necessário migrar para CMK, apenas este escopo precisará ser alterado, sem impactar outros contêineres.

Tarefa 3.2 — Gerenciar chaves de acesso: rotação e regeneração​

As chaves de acesso da conta stcontososaude01 são sensíveis e devem ser rotacionadas periodicamente. Nesta tarefa, você visualizará as chaves atuais, usará a key1 para uma operação, regenerará a key1 e verificará que a chave antiga deixou de funcionar.

  1. Visualize as chaves atuais:

Via Portal​

Navegue até stcontososaude01 > Clique em "Access keys" > Clique em "Show" para revelar ambas as chaves. Copie o valor de key1 para uso no próximo passo.

Via CLI​

# Listar chaves atuais
az storage account keys list \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --query "[].{keyName:keyName, value:value}" -o table

# Capturar key1 em variável
OLD_KEY1=$(az storage account keys list \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --query "[0].value" -o tsv)

echo "Key1 atual: $OLD_KEY1"
  1. Use a key1 atual para listar contêineres (comprovando que funciona):
az storage container list \
  --account-name stcontososaude01 \
  --account-key "$OLD_KEY1" \
  --output table
# Esperado: lista exibida com sucesso
  1. Regenere a key1:

Via Portal​

Navegue até stcontososaude01 > "Access keys" > Ao lado de key1, clique em "Rotate/Regenerate" > Confirme a regeneração.

Via CLI​

az storage account keys renew \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --key key1
  1. Tente usar a chave antiga (deve falhar):
az storage container list \
  --account-name stcontososaude01 \
  --account-key "$OLD_KEY1" \
  --output table 2>&1
# Esperado: erro de autenticação (403 ou "authentication failed")
  1. Confirme que a nova key1 funciona:
NEW_KEY1=$(az storage account keys list \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --query "[0].value" -o tsv)

az storage container list \
  --account-name stcontososaude01 \
  --account-key "$NEW_KEY1" \
  --output table
# Esperado: lista exibida com sucesso

A regeneração de chaves invalida imediatamente a chave anterior. Em produção, o padrão recomendado é alternar entre key1 e key2: atualize todos os clientes para key2, regenere key1, atualize todos para key1, e então regenere key2.

Fase 4 — Tokens SAS e Stored Access Policies​

Nesta fase você criará contêineres de produção, configurará Stored Access Policies e gerará tokens SAS com diferentes escopos. Os objetivos cobertos são Create and use shared access signature (SAS) tokens e Configure stored access policies. Você utilizará a conta stcontososaude01 com o firewall já configurado na Fase 2.

Tarefa 4.1 — Criar contêineres de produção e definir uma Stored Access Policy​

A Contoso Saúde precisa de um contêiner prontuarios com uma política de acesso armazenada que permita leitura e listagem por aplicações de terceiros. A stored access policy centraliza o controle: revogar a política invalida todos os SAS tokens derivados.

  1. Crie o contêiner prontuarios:

Via Portal​

Navegue até stcontososaude01 > Clique em "Containers" > Clique em "+ Container" > Preencha Name com prontuarios, Public access level com Private > Clique em "Create".

Via CLI​

az storage container create \
  --name prontuarios \
  --account-name stcontososaude01 \
  --auth-mode login
  1. Crie o contêiner exames com o escopo de criptografia scope-exames criado na Fase 3:

Via Portal​

Navegue até stcontososaude01 > "Containers" > "+ Container" > Preencha Name com exames, Public access level com Private > Em Advanced, selecione Encryption scope com scope-exames > Clique em "Create".

Via CLI​

az storage container create \
  --name exames \
  --account-name stcontososaude01 \
  --default-encryption-scope scope-exames \
  --auth-mode login
  1. Crie a Stored Access Policy policy-leitura-prontuarios:

Via Portal​

Navegue até stcontososaude01 > "Containers" > Selecione prontuarios > Clique em "Access policy" > Em Stored access policies, clique em "+ Add policy" > Preencha Identifier com policy-leitura-prontuarios, Permissions com Read e List, Start time com a data/hora atual, Expiry time com a data/hora atual + 24 horas > Clique em "OK" > Clique em "Save".

Via CLI​

# Definir datas (ajuste conforme seu fuso)
START_DATE=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
EXPIRY_DATE=$(date -u -d "+24 hours" +"%Y-%m-%dT%H:%M:%SZ")

az storage container policy create \
  --container-name prontuarios \
  --name policy-leitura-prontuarios \
  --account-name stcontososaude01 \
  --permissions rl \
  --start "$START_DATE" \
  --expiry "$EXPIRY_DATE" \
  --auth-mode login

O parâmetro --permissions rl concede read e list. A stored access policy define permissões e validade de forma centralizada no servidor.

Tarefa 4.2 — Gerar tokens SAS com diferentes escopos e testar acesso​

Agora você gerará três tipos de SAS: um Service SAS baseado na stored access policy, um Service SAS ad hoc e um Account SAS, testando o acesso com cada um.

  1. Faça upload de um arquivo de teste para o contêiner prontuarios:
echo "Prontuario de teste - paciente 001" > /tmp/prontuario001.txt

az storage blob upload \
  --container-name prontuarios \
  --name prontuario001.txt \
  --file /tmp/prontuario001.txt \
  --account-name stcontososaude01 \
  --auth-mode login
  1. Gere um Service SAS baseado na stored access policy:

Via CLI​

SAS_POLICY=$(az storage container generate-sas \
  --name prontuarios \
  --account-name stcontososaude01 \
  --policy-name policy-leitura-prontuarios \
  --auth-mode login \
  -o tsv)

echo "SAS via Policy: $SAS_POLICY"
  1. Teste o acesso com o SAS baseado na policy (listagem do contêiner):
az storage blob list \
  --container-name prontuarios \
  --account-name stcontososaude01 \
  --sas-token "$SAS_POLICY" \
  --output table
# Esperado: prontuario001.txt listado com sucesso
  1. Gere um Service SAS ad hoc (sem policy) com permissão apenas de leitura e validade de 1 hora:
SAS_ADHOC=$(az storage blob generate-sas \
  --container-name prontuarios \
  --name prontuario001.txt \
  --account-name stcontososaude01 \
  --permissions r \
  --expiry "$(date -u -d '+1 hour' +%Y-%m-%dT%H:%M:%SZ)" \
  --auth-mode login \
  -o tsv)

echo "SAS Ad Hoc: $SAS_ADHOC"
  1. Baixe o blob usando o SAS ad hoc:
az storage blob download \
  --container-name prontuarios \
  --name prontuario001.txt \
  --account-name stcontososaude01 \
  --sas-token "$SAS_ADHOC" \
  --file /tmp/prontuario001_download.txt

cat /tmp/prontuario001_download.txt
# Esperado: conteúdo do arquivo exibido
  1. Gere um Account SAS com permissões de leitura em todos os serviços:
ACCOUNT_SAS=$(az storage account generate-sas \
  --account-name stcontososaude01 \
  --permissions rl \
  --resource-types sco \
  --services bfqt \
  --expiry "$(date -u -d '+2 hours' +%Y-%m-%dT%H:%M:%SZ)" \
  --https-only \
  -o tsv)

echo "Account SAS: $ACCOUNT_SAS"

O Service SAS baseado na stored access policy é o método recomendado porque permite revogação centralizada. O SAS ad hoc não pode ser revogado antes do vencimento, exceto pela regeneração da chave da conta.

Tarefa 4.3 — Revogar acesso via Stored Access Policy e verificar bloqueio​

A Contoso Saúde detectou que um token SAS foi compartilhado indevidamente. Você deve revogar todos os tokens derivados da stored access policy.

  1. Confirme que o SAS baseado na policy ainda funciona:
az storage blob list \
  --container-name prontuarios \
  --account-name stcontososaude01 \
  --sas-token "$SAS_POLICY" \
  --output table
# Esperado: sucesso
  1. Remova a stored access policy para invalidar todos os SAS derivados:

Via Portal​

Navegue até stcontososaude01 > "Containers" > prontuarios > "Access policy" > Localize policy-leitura-prontuarios > Clique no ícone de exclusão > Clique em "Save".

Via CLI​

az storage container policy delete \
  --container-name prontuarios \
  --name policy-leitura-prontuarios \
  --account-name stcontososaude01 \
  --auth-mode login
  1. Tente usar o SAS baseado na policy excluída (deve falhar):
az storage blob list \
  --container-name prontuarios \
  --account-name stcontososaude01 \
  --sas-token "$SAS_POLICY" \
  --output table 2>&1
# Esperado: erro de autorização (403)
  1. Recrie a stored access policy para uso futuro:
START_DATE=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
EXPIRY_DATE=$(date -u -d "+24 hours" +"%Y-%m-%dT%H:%M:%SZ")

az storage container policy create \
  --container-name prontuarios \
  --name policy-leitura-prontuarios \
  --account-name stcontososaude01 \
  --permissions rl \
  --start "$START_DATE" \
  --expiry "$EXPIRY_DATE" \
  --auth-mode login

A exclusão da stored access policy invalidou imediatamente todos os tokens SAS que faziam referência a ela. Esse é o mecanismo primário de revogação de SAS no Azure Storage.

Fase 5 — Acesso Baseado em Identidade para Azure Files​

Nesta fase você configurará o file share da equipe financeira com acesso baseado em identidade usando Microsoft Entra ID. O objetivo coberto é Configure identity-based access for Azure Files. Você utilizará a conta stcontosofiles01 criada na Fase 1.

Tarefa 5.1 — Criar o file share e habilitar autenticação via Microsoft Entra ID​

A equipe financeira da Contoso Saúde precisa de um compartilhamento de arquivos montável com permissões baseadas em identidade do Microsoft Entra ID, sem usar chaves de armazenamento compartilhadas.

  1. Crie o file share financeiro:

Via Portal​

Navegue até stcontosofiles01 > Clique em "File shares" > Clique em "+ File share" > Preencha Name com financeiro, Tier com Transaction optimized > Clique em "Create".

Via CLI​

az storage share-rm create \
  --storage-account stcontosofiles01 \
  --resource-group rg-contososaude-lab \
  --name financeiro \
  --access-tier TransactionOptimized
  1. Habilite a autenticação via Microsoft Entra ID para o storage account:

Via Portal​

Navegue até stcontosofiles01 > Clique em "File shares" > Clique em "Active Directory" (ou "Identity-based access") > Em Microsoft Entra ID, selecione "Set up" ao lado de "Microsoft Entra Kerberos" > Habilite a opção > Clique em "Save".

Via CLI​

az storage account update \
  --name stcontosofiles01 \
  --resource-group rg-contososaude-lab \
  --enable-files-aadkerb true
  1. Verifique que a autenticação foi habilitada:
az storage account show --name stcontosofiles01 \
  --resource-group rg-contososaude-lab \
  --query "azureFilesIdentityBasedAuthentication" -o json
# Esperado: directoryServiceOptions inclui "AADKERB"

A habilitação do Microsoft Entra Kerberos permite que usuários autentiquem no file share usando credenciais do Entra ID, eliminando a necessidade de distribuir chaves de acesso do storage account.

Tarefa 5.2 — Atribuir permissões RBAC no nível do file share e testar acesso​

Para que usuários do Entra ID acessem o file share, é necessário atribuir roles de RBAC no nível do recurso. Você atribuirá a role Storage File Data SMB Share Contributor ao seu próprio usuário.

  1. Obtenha o ID do seu usuário atual:
CURRENT_USER_ID=$(az ad signed-in-user show --query id -o tsv)
echo "User ID: $CURRENT_USER_ID"
  1. Obtenha o Resource ID da conta de armazenamento:
STORAGE_ID=$(az storage account show \
  --name stcontosofiles01 \
  --resource-group rg-contososaude-lab \
  --query id -o tsv)
  1. Atribua a role Storage File Data SMB Share Contributor:

Via Portal​

Navegue até stcontosofiles01 > Clique em "Access Control (IAM)" > Clique em "+ Add" > "Add role assignment" > Pesquise e selecione "Storage File Data SMB Share Contributor" > Clique em "Next" > Em Members, selecione seu usuário > Clique em "Review + assign".

Via CLI​

az role assignment create \
  --assignee "$CURRENT_USER_ID" \
  --role "Storage File Data SMB Share Contributor" \
  --scope "$STORAGE_ID"
  1. Teste o acesso ao file share:

Via Portal​

Navegue até stcontosofiles01 > "File shares" > Selecione financeiro > Clique em "+ Add directory" > Crie um diretório chamado relatorios-2024 > Se a operação for bem-sucedida, o acesso RBAC está funcionando.

Via CLI​

az storage directory create \
  --share-name financeiro \
  --name relatorios-2024 \
  --account-name stcontosofiles01 \
  --auth-mode login
  1. Teste negativo: tente acessar sem a role correta. Crie uma atribuição temporária com a role de apenas leitura (Storage File Data SMB Share Reader) e verifique que a tentativa de criar um diretório falha (ou verifique removendo a role Contributor e tentando a operação de escrita).

A combinação de autenticação Entra ID com roles RBAC granulares permite controle de acesso por identidade no nível do file share, eliminando o compartilhamento de chaves e habilitando auditoria por usuário.

Fase 6 — Replicação de Objetos entre Regiões​

Nesta fase você configurará a replicação de objetos entre a conta primária (stcontososaude01, Brazil South) e a conta secundária (stcontososaude02, East US 2). O objetivo coberto é Configure object replication. Ambas as contas devem ter change feed e blob versioning habilitados.

Tarefa 6.1 — Habilitar pré-requisitos de replicação de objetos​

A replicação de objetos requer que change feed e blob versioning estejam habilitados em ambas as contas (origem e destino).

  1. Verifique o estado atual de blob versioning e change feed em ambas as contas:
for SA in stcontososaude01 stcontososaude02; do
  RG="rg-contososaude-lab"
  if [ "$SA" = "stcontososaude02" ]; then RG="rg-contososaude-dr"; fi
  
  echo "=== $SA ==="
  az storage account blob-service-properties show \
    --account-name $SA \
    --resource-group $RG \
    --query "{changeFeed:changeFeed.enabled, versioning:isVersioningEnabled}" -o json
done
# Esperado: ambos false/null
  1. Habilite blob versioning e change feed em ambas as contas:

Via Portal​

Para cada conta (stcontososaude01 e stcontososaude02): Navegue até a conta de armazenamento > Clique em "Data protection" > Habilite "Enable versioning for blobs" > Habilite "Enable blob change feed" > Clique em "Save".

Via CLI​

# Conta primária
az storage account blob-service-properties update \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --enable-versioning true \
  --enable-change-feed true

# Conta secundária
az storage account blob-service-properties update \
  --account-name stcontososaude02 \
  --resource-group rg-contososaude-dr \
  --enable-versioning true \
  --enable-change-feed true
  1. Crie o contêiner exames na conta de destino (mesmo nome que na origem):
az storage container create \
  --name exames \
  --account-name stcontososaude02 \
  --auth-mode login

A habilitação de blob versioning cria automaticamente versões para cada modificação de blob. O change feed registra todas as alterações em um log, permitindo que o serviço de replicação rastreie quais blobs precisam ser copiados.

Tarefa 6.2 — Criar a política de replicação de objetos​

Agora você criará a política que replicará blobs do contêiner exames em stcontososaude01 (Brazil South) para o contêiner exames em stcontososaude02 (East US 2).

  1. Crie a política de replicação:

Via Portal​

Navegue até stcontososaude01 > Clique em "Object replication" > Clique em "+ Set up replication rules" > Em Destination account, selecione stcontososaude02 > Configure a regra: Source container com exames, Destination container com exames > Em Filters, deixe o campo Prefix filter vazio para replicar todos os blobs > Em Copy over, selecione "New objects only" > Clique em "Save".

Via CLI​

az storage account or-policy create \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab \
  --destination-account stcontososaude02 \
  --source-container exames \
  --destination-container exames \
  --min-creation-time ""
  1. Verifique que a política foi criada em ambas as contas:
# Origem
az storage account or-policy list \
  --account-name stcontososaude01 \
  --resource-group rg-contososaude-lab -o table

# Destino
az storage account or-policy list \
  --account-name stcontososaude02 \
  --resource-group rg-contososaude-dr -o table

Tarefa 6.3 — Testar a replicação e verificar o estado​

  1. Faça upload de um arquivo de teste na conta de origem:
echo "Exame de teste - paciente 002 - $(date)" > /tmp/exame002.txt

az storage blob upload \
  --container-name exames \
  --name exame002.txt \
  --file /tmp/exame002.txt \
  --account-name stcontososaude01 \
  --auth-mode login
  1. Aguarde a replicação (pode levar alguns minutos) e verifique se o blob apareceu na conta de destino:
# Aguardar e verificar (repita até encontrar o blob)
sleep 60

az storage blob list \
  --container-name exames \
  --account-name stcontososaude02 \
  --auth-mode login \
  --output table
# Esperado: exame002.txt aparece na lista
  1. Verifique o estado de replicação do blob na origem:
az storage blob show \
  --container-name exames \
  --name exame002.txt \
  --account-name stcontososaude01 \
  --auth-mode login \
  --query "properties.replicationStatus" -o tsv

Se o blob ainda não apareceu na conta de destino, aguarde mais alguns minutos e repita a verificação. A replicação assíncrona não tem SLA de tempo, e blobs pequenos geralmente são replicados em menos de 5 minutos.

Fase 7 — Transferência de Dados com AzCopy e Storage Explorer​

Nesta fase final você utilizará AzCopy e Azure Storage Explorer para transferir dados entre contas e entre sua máquina local e o Azure. O objetivo coberto é Manage data by using Azure Storage Explorer and AzCopy. Você utilizará as contas stcontososaude01 e stcontososaude02 configuradas nas fases anteriores.

Tarefa 7.1 — Transferir dados com AzCopy usando autenticação por SAS e login​

O AzCopy é a ferramenta de transferência de dados em larga escala da Microsoft. Você realizará operações de upload, download e cópia entre contas usando diferentes métodos de autenticação.

  1. Autentique o AzCopy com Microsoft Entra ID:
azcopy login
# Siga as instruções para autenticar via navegador
  1. Faça upload de um diretório local para o contêiner prontuarios:
# Criar dados de teste
mkdir -p /tmp/prontuarios-batch
for i in $(seq 1 5); do
  echo "Prontuario paciente $i - dados clínicos" > /tmp/prontuarios-batch/prontuario_$i.txt
done

# Upload com AzCopy
azcopy copy "/tmp/prontuarios-batch/*" \
  "https://stcontososaude01.blob.core.windows.net/prontuarios/" \
  --recursive
  1. Verifique o upload:
azcopy list "https://stcontososaude01.blob.core.windows.net/prontuarios/"
# Esperado: 6 blobs listados (5 novos + prontuario001.txt da Fase 4)
  1. Copie dados entre contas usando AzCopy (server-side copy):
# Gerar SAS para a conta de destino
DEST_SAS=$(az storage account generate-sas \
  --account-name stcontososaude02 \
  --permissions rwdlac \
  --resource-types sco \
  --services b \
  --expiry "$(date -u -d '+2 hours' +%Y-%m-%dT%H:%M:%SZ)" \
  --https-only \
  -o tsv)

# Copiar do contêiner prontuarios da conta 01 para um novo contêiner na conta 02
az storage container create \
  --name prontuarios-backup \
  --account-name stcontososaude02 \
  --auth-mode login

azcopy copy \
  "https://stcontososaude01.blob.core.windows.net/prontuarios/*" \
  "https://stcontososaude02.blob.core.windows.net/prontuarios-backup/?$DEST_SAS" \
  --recursive
  1. Faça download de blobs para a máquina local:
mkdir -p /tmp/download-exames

azcopy copy \
  "https://stcontososaude01.blob.core.windows.net/exames/*" \
  "/tmp/download-exames/" \
  --recursive

ls -la /tmp/download-exames/
# Esperado: exame002.txt baixado com sucesso

O AzCopy utiliza autenticação Microsoft Entra ID por padrão quando autenticado via azcopy login. Para cenários de automação ou acesso a contas sem RBAC, tokens SAS são a alternativa adequada.

Tarefa 7.2 — Gerenciar dados com Azure Storage Explorer e tratar erro de acesso​

O Azure Storage Explorer fornece uma interface gráfica para gerenciar blobs, files, queues e tables. Nesta tarefa você conectará o Explorer às contas de armazenamento e simulará um cenário de erro de acesso relacionado ao firewall.

  1. Abra o Azure Storage Explorer na sua máquina local.

  2. Conecte-se usando conta Microsoft Entra ID: Clique em "Connect to Azure resources" (ícone de tomada no painel lateral esquerdo) > Selecione "Subscription" > Faça login com sua conta Microsoft Entra ID > Selecione sua assinatura e clique em "Open Explorer".

  3. Navegue até stcontososaude01 > "Blob Containers" > prontuarios. Verifique que todos os blobs enviados via AzCopy e CLI estão visíveis.

  4. Faça upload de um arquivo pelo Storage Explorer: Clique em "Upload" > "Upload Files" > Selecione um arquivo de teste da sua máquina local > Clique em "Upload".

  5. Simule erro de firewall: Conecte via SAS a uma conta com firewall restrito onde seu IP não está na whitelist. No Storage Explorer, clique em "Connect to Azure Resources" > Selecione "Storage account or service" > "Shared access signature URL (SAS)" > Cole uma URL SAS da conta stcontososaude01.

  6. Provoque o erro: remova temporariamente seu IP da whitelist da conta (como na Tarefa 2.2) e tente listar blobs no Storage Explorer. Observe a mensagem de erro "This request is not authorized to perform this operation" ou "AuthorizationFailure".

  7. Restaure o acesso: readicione seu IP à whitelist da conta conforme a Tarefa 2.2.

O Storage Explorer respeita as regras de firewall da conta de armazenamento. Quando o IP do cliente não está na whitelist, mesmo com um SAS válido, o acesso é negado pelo firewall antes de validar o token.

Tarefa 7.3 — Sincronizar dados com AzCopy sync​

A Contoso Saúde precisa manter uma cópia sincronizada do contêiner prontuarios em um diretório local para processamento batch.

  1. Crie o diretório de sincronização local:
mkdir -p /tmp/sync-prontuarios
  1. Execute a sincronização inicial:
azcopy sync \
  "https://stcontososaude01.blob.core.windows.net/prontuarios/" \
  "/tmp/sync-prontuarios/" \
  --recursive
  1. Faça upload de um novo blob para simular uma alteração:
echo "Prontuario novo - paciente 006" > /tmp/prontuario006.txt

az storage blob upload \
  --container-name prontuarios \
  --name prontuario006.txt \
  --file /tmp/prontuario006.txt \
  --account-name stcontososaude01 \
  --auth-mode login
  1. Execute a sincronização novamente:
azcopy sync \
  "https://stcontososaude01.blob.core.windows.net/prontuarios/" \
  "/tmp/sync-prontuarios/" \
  --recursive

ls -la /tmp/sync-prontuarios/
# Esperado: prontuario006.txt aparece na lista (apenas o delta foi transferido)

O comando azcopy sync transfere apenas os arquivos que foram adicionados ou modificados desde a última sincronização, otimizando largura de banda e tempo de transferência.

Validação Final​

Ao concluir todas as fases, verifique os critérios abaixo para confirmar a execução completa do laboratório:

Critério 1 — Redundância e contas de armazenamento: confirme que stcontososaude01 está em RA-GRS, stcontososaude02 em LRS e stcontosofiles01 em ZRS executando az storage account show --name <nome> --resource-group <rg> --query "sku.name" -o tsv para cada conta.

Critério 2 — Firewall e bloqueio de rede: remova temporariamente seu IP da whitelist de stcontososaude01, tente executar az storage container list --account-name stcontososaude01 --auth-mode login e confirme que recebe um erro 403. Restaure o IP após o teste.

Critério 3 — Replicação de objetos: verifique que o blob exame002.txt existe no contêiner exames da conta stcontososaude02 em East US 2 usando az storage blob list --container-name exames --account-name stcontososaude02 --auth-mode login --output table.

Critério 4 — Stored Access Policy e SAS: gere um novo SAS token baseado na policy policy-leitura-prontuarios do contêiner prontuarios, use-o para listar blobs com sucesso, exclua a policy, e confirme que o mesmo token retorna erro 403.

Critério 5 — Azure Files com identidade: acesse o file share financeiro na conta stcontosofiles01 usando o Storage Explorer autenticado via Microsoft Entra ID e confirme que o diretório relatorios-2024 está presente e que você consegue criar arquivos sem usar chaves de acesso.

Cleanup do Ambiente​

Após concluir todas as validações, remova os recursos para evitar cobranças desnecessárias. A exclusão dos resource groups remove automaticamente todos os recursos contidos neles.

Via Portal​

  1. Navegue até "Resource groups" > Selecione rg-contososaude-dr > Clique em "Delete resource group" > Digite o nome do grupo para confirmar > Clique em "Delete".
  2. Aguarde a conclusão da exclusão.
  3. Navegue até "Resource groups" > Selecione rg-contososaude-lab > Clique em "Delete resource group" > Digite o nome do grupo para confirmar > Clique em "Delete".
  4. Para confirmar, navegue até "Resource groups" e verifique que nenhum dos dois grupos aparece na lista.

Via CLI​

# Excluir o grupo de DR primeiro (menos dependências)
az group delete --name rg-contososaude-dr --yes --no-wait

# Excluir o grupo principal
az group delete --name rg-contososaude-lab --yes --no-wait

# Verificar a exclusão (pode levar alguns minutos)
az group list --query "[?starts_with(name, 'rg-contososaude')].name" -o tsv
# Esperado: nenhum resultado retornado

O parâmetro --no-wait retorna o controle do terminal imediatamente enquanto a exclusão continua em segundo plano. Execute o último comando após alguns minutos para confirmar que ambos os grupos foram completamente removidos.