Fundamentação Teórica: Configure Storage Account Encryption

1. Intuição Inicial

Imagine que você guarda documentos confidenciais em um cofre. Qualquer pessoa que tiver a chave do cofre pode abrir e ler os documentos. Agora imagine que, antes de colocar os documentos no cofre, você embaralha o texto de cada página com um código secreto. Mesmo que alguém roube o cofre inteiro e force a abertura, os documentos são ilegíveis sem o código para decodificá-los.

Criptografia em repouso é exatamente isso: os dados são transformados em um formato ilegível antes de serem gravados no disco. Quando um sistema autorizado precisa ler os dados, eles são decodificados automaticamente na memória.

No Azure Storage, toda a criptografia em repouso é automática, obrigatória e transparente. Ela não pode ser desativada. O que você controla é quem possui e gerencia as chaves usadas nesse processo.

2. Contexto

2.1 Por que a criptografia em repouso existe

Sem criptografia em repouso, um atacante que conseguisse acesso físico aos discos de um datacenter poderia ler os dados diretamente. Com criptografia, os discos físicos contêm apenas dados embaralhados, sem valor sem as chaves correspondentes.

No Azure, a criptografia de Storage Accounts protege contra:

Acesso físico não autorizado a hardware de datacenter
Exfiltração de discos físicos
Requisitos regulatórios (LGPD, GDPR, HIPAA, PCI-DSS) que exigem dados em repouso criptografados

2.2 O que a criptografia de Storage Account cobre

Serviço	Criptografado?
Blob Storage	Sim
Azure Files	Sim
Queue Storage	Sim
Table Storage	Sim
Metadados dos objetos	Sim
Dados em trânsito (HTTPS)	Sim (configuração separada)

Ponto importante: A criptografia em repouso do Azure Storage é diferente da criptografia de discos de VMs (Azure Disk Encryption / Server-Side Encryption de managed disks). São mecanismos independentes.

3. Construção dos Conceitos

3.1 Como a criptografia funciona internamente

O Azure usa AES-256, um dos padrões criptográficos mais robustos disponíveis. O processo envolve dois níveis de chave:

Data Encryption Key (DEK): Chave que criptografa os dados em si. Cada objeto (blob, arquivo, etc.) pode ter sua própria DEK.

Key Encryption Key (KEK): Chave que criptografa a DEK. Este é o nível onde o controle do cliente é aplicado.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Este modelo de duas camadas significa que:

Se você rotacionar ou revogar a KEK, todos os dados ficam inacessíveis sem precisar recriptografar cada byte.
Os dados em si (protegidos pela DEK) não precisam ser movidos ou recriptografados quando a KEK muda.

3.2 Os dois modelos de gerenciamento de chave

Microsoft Managed Keys (MMK)

O que é: A Microsoft gera, armazena e rotaciona automaticamente as KEKs. Você não tem acesso a elas.

Analogia: É como usar o cofre do hotel. O hotel gerencia a combinação, você usa o serviço sem se preocupar com a chave mestra.

Características:

Habilitado por padrão em todas as Storage Accounts
Sem custo adicional de gerenciamento
Rotação automática gerenciada pela Microsoft
Não há visibilidade ou controle sobre as chaves

Customer Managed Keys (CMK)

O que é: Você cria e gerencia a KEK em um Azure Key Vault ou Azure Managed HSM. O Azure Storage usa essa chave externa para criptografar as DEKs, mas nunca armazena sua chave permanentemente.

Analogia: É como ter um cofre no banco onde apenas você tem a chave mestra. O banco pode acessar o conteúdo quando você permite, mas se você revogar o acesso, o banco não consegue mais abrir o cofre.

Características:

Controle total sobre o ciclo de vida da chave
Capacidade de revogar acesso imediatamente
Auditoria completa de uso da chave (quem usou, quando)
Rotação de chave controlada pelo cliente
Custo adicional: Key Vault e operações de chave são cobrados

Customer Provided Keys (CPK)

O que é: O cliente fornece a chave diretamente em cada requisição HTTP para o Storage. A chave não é armazenada no Azure em nenhum momento.

Analogia: É como você mesmo levar a chave toda vez que quer abrir o cofre. O banco nunca guarda sua chave, mas você precisa trazê-la toda vez.

Características:

A chave existe apenas na memória durante a requisição
Não é armazenada no Azure
Gerenciamento completamente fora do Azure
Aplicável apenas a operações de Blob Storage
Requer implementação no código da aplicação (não configurável no portal)

3.3 Escopo da criptografia: conta vs infraestrutura

O Azure oferece dois escopos onde CMK pode ser aplicado:

Escopo de conta (padrão do CMK): Uma chave do Key Vault criptografa os dados da Storage Account inteira.

Escopo de criptografia (Encryption Scope): Permite usar chaves diferentes por container ou por blob individual, dentro da mesma Storage Account.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Encryption Scopes permitem isolamento criptográfico dentro de uma mesma conta. Dados do departamento de RH e do financeiro podem coexistir na mesma Storage Account com chaves completamente diferentes.

3.4 Infrastructure Encryption (Double Encryption)

Para cenários de conformidade que exigem múltiplas camadas de criptografia, o Azure oferece Infrastructure Encryption, que adiciona uma segunda camada de criptografia no nível de infraestrutura (hardware/hypervisor), independente da criptografia de serviço.

Resultado: dados são criptografados duas vezes com algoritmos e chaves completamente independentes.

Camada	Algoritmo	Chaves
Camada 1 (Storage Service)	AES-256	MMK ou CMK
Camada 2 (Infrastructure)	AES-256	Sempre Microsoft-managed

Importante: Infrastructure Encryption deve ser habilitado no momento da criação da Storage Account. Não pode ser habilitado depois.

4. Visão Estrutural: Fluxo de Escrita e Leitura

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

5.1 Pré-requisitos para CMK

Para usar Customer Managed Keys, você precisa:

Azure Key Vault com as seguintes configurações:
- Soft Delete habilitado (obrigatório)
- Purge Protection habilitado (obrigatório para CMK em Storage)
- Configurado na mesma região da Storage Account (recomendado)
Identidade gerenciada (Managed Identity) atribuída à Storage Account para que ela possa acessar o Key Vault sem credenciais explícitas.
Permissões no Key Vault para a identidade da Storage Account:
- Get (obter chave)
- Wrap Key (criptografar DEK com KEK)
- Unwrap Key (descriptografar DEK com KEK)

5.2 Tipos de identidade gerenciada para CMK

Tipo	Descrição	Quando usar
System-assigned Managed Identity	Criada e vinculada à Storage Account. Deletada junto com a conta.	Cenários simples, uma conta por Key Vault
User-assigned Managed Identity	Criada independentemente, pode ser compartilhada entre recursos.	Múltiplas Storage Accounts usando o mesmo Key Vault

5.3 Rotação de chave

Quando você rotaciona a KEK no Key Vault (cria uma nova versão da chave), o Azure Storage precisa ser notificado para começar a usar a nova versão.

Rotação automática: Configure a Storage Account para usar a versão mais recente da chave. O Azure detecta automaticamente novas versões e as adota.

Rotação manual: Configure a Storage Account para usar uma versão específica da chave. Você controla exatamente quando a nova versão é adotada.

Comportamento crítico ao revogar: Se você revogar o acesso da identidade da Storage Account ao Key Vault (ou deletar a chave), a Storage Account fica inacessível imediatamente. Leituras e escritas falham com erro de autorização. Isso é intencional e é o mecanismo de "kill switch" que CMK proporciona.

5.4 Encryption Scopes: ciclo de vida

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Ponto crítico: Encryption Scopes não podem ser deletados, apenas desabilitados. Um scope desabilitado torna os blobs que o usam inacessíveis, mas não os deleta. Reabilitar o scope restaura o acesso.

6. Formas de Implementação

6.1 Habilitando CMK via Portal Azure

Passos:

Criar Key Vault com Soft Delete e Purge Protection
Criar uma chave no Key Vault (RSA 2048, 3072 ou 4096)
Na Storage Account: Security + networking > Encryption
Selecionar "Customer-managed keys"
Selecionar Key Vault e chave
Atribuir ou criar Managed Identity para a conta
Salvar

O portal configura automaticamente as permissões no Key Vault para a identidade da Storage Account quando você seleciona "Grant access" durante o processo.

6.2 Azure CLI

Criando Key Vault com proteções obrigatórias:

az keyvault create \
  --name myKeyVault \
  --resource-group myRG \
  --location eastus \
  --enable-soft-delete true \
  --enable-purge-protection true

Criando chave RSA:

az keyvault key create \
  --vault-name myKeyVault \
  --name myStorageKey \
  --kty RSA \
  --size 2048

Atribuindo System-assigned Identity à Storage Account:

az storage account update \
  --name mystorageaccount \
  --resource-group myRG \
  --assign-identity

Obtendo o Principal ID da identidade:

PRINCIPAL_ID=$(az storage account show \
  --name mystorageaccount \
  --resource-group myRG \
  --query identity.principalId \
  --output tsv)

Concedendo permissões no Key Vault:

az keyvault set-policy \
  --name myKeyVault \
  --object-id $PRINCIPAL_ID \
  --key-permissions get wrapKey unwrapKey

Configurando CMK na Storage Account:

KEY_URI=$(az keyvault key show \
  --vault-name myKeyVault \
  --name myStorageKey \
  --query key.kid \
  --output tsv)

az storage account update \
  --name mystorageaccount \
  --resource-group myRG \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-uri $KEY_URI

6.3 Azure PowerShell

# Criar identidade e obter principal
$storageAccount = Set-AzStorageAccount `
  -ResourceGroupName "myRG" `
  -Name "mystorageaccount" `
  -AssignIdentity

# Configurar permissões no Key Vault
Set-AzKeyVaultAccessPolicy `
  -VaultName "myKeyVault" `
  -ObjectId $storageAccount.Identity.PrincipalId `
  -PermissionsToKeys get, wrapKey, unwrapKey

# Obter chave
$key = Get-AzKeyVaultKey `
  -VaultName "myKeyVault" `
  -Name "myStorageKey"

# Configurar CMK
Set-AzStorageAccount `
  -ResourceGroupName "myRG" `
  -Name "mystorageaccount" `
  -KeyvaultEncryption `
  -KeyName $key.Name `
  -KeyVersion $key.Version `
  -KeyVaultUri "https://myKeyVault.vault.azure.net"

6.4 Bicep

// Key Vault com proteções obrigatórias
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: 'myKeyVault'
  location: location
  properties: {
    sku: { family: 'A', name: 'standard' }
    tenantId: subscription().tenantId
    enableSoftDelete: true
    enablePurgeProtection: true
    accessPolicies: []
  }
}

// Storage Account com system-assigned identity e CMK
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorageaccount'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    encryption: {
      keySource: 'Microsoft.Keyvault'
      keyvaultproperties: {
        keyname: 'myStorageKey'
        keyvaulturi: keyVault.properties.vaultUri
      }
    }
  }
}

Dependência circular no Bicep/ARM: A Storage Account precisa do Key Vault para existir, mas a política de acesso no Key Vault precisa do Principal ID da Storage Account. Isso exige duas implantações ou uso de RBAC no Key Vault (recomendado) em vez de Access Policies.

6.5 Criando Encryption Scopes

Via CLI:

# Scope com MMK
az storage account encryption-scope create \
  --account-name mystorageaccount \
  --resource-group myRG \
  --name FinanceScope \
  --key-source Microsoft.Storage

# Scope com CMK
az storage account encryption-scope create \
  --account-name mystorageaccount \
  --resource-group myRG \
  --name HRScope \
  --key-source Microsoft.KeyVault \
  --key-uri $KEY_URI

Aplicando scope a um container:

az storage container create \
  --account-name mystorageaccount \
  --name employee-data \
  --default-encryption-scope HRScope \
  --prevent-encryption-scope-override true

O parâmetro --prevent-encryption-scope-override true impede que blobs individuais dentro do container usem um scope diferente do definido no container.

7. Controle e Segurança

7.1 RBAC vs Access Policies no Key Vault

O Azure Key Vault suporta dois modelos de controle de acesso:

Modelo	Recomendado?	Como funciona
Access Policies	Legado	Políticas diretamente no Key Vault por principal
Azure RBAC	Sim (preferido)	Roles do Azure Resource Manager aplicadas ao Key Vault

Com RBAC, atribua o papel Key Vault Crypto Service Encryption User à identidade da Storage Account. Este papel concede exatamente as permissões necessárias (get, wrapKey, unwrapKey) sem excesso.

az role assignment create \
  --role "Key Vault Crypto Service Encryption User" \
  --assignee $PRINCIPAL_ID \
  --scope $(az keyvault show --name myKeyVault --query id --output tsv)

7.2 O "kill switch" do CMK

Um dos principais motivadores para usar CMK é a capacidade de revogar acesso imediato a todos os dados:

Deletar a chave no Key Vault
Revogar as permissões da identidade da Storage Account
Desabilitar o Key Vault inteiro

Qualquer uma dessas ações torna a Storage Account imediatamente inacessível. Isso é útil em cenários de:

Encerramento de contrato com clientes que possuem dados na conta
Resposta a incidentes de segurança
Conformidade regulatória que exige "direito ao esquecimento"

Atenção: O Azure não avisa imediatamente sobre o impacto. Teste o procedimento de revogação e restauração em ambiente de não-produção antes de depender dele.

7.3 Auditoria de uso de chave

Com CMK, cada operação que usa a chave (leitura, escrita, rotação) gera um log no Azure Key Vault diagnostic logs. Esses logs mostram:

Qual identidade usou a chave
Quando foi usada
De qual IP
Se foi bem-sucedida ou negada

Habilite diagnósticos no Key Vault:

az monitor diagnostic-settings create \
  --name "kv-audit-logs" \
  --resource $(az keyvault show --name myKeyVault --query id --output tsv) \
  --logs '[{"category":"AuditEvent","enabled":true}]' \
  --workspace <log-analytics-workspace-id>

8. Tomada de Decisão

8.1 MMK vs CMK vs CPK

Situação	Melhor escolha	Motivo
Dados internos sem requisito regulatório específico	MMK	Simples, sem custo adicional, durabilidade garantida
Conformidade HIPAA, PCI-DSS, LGPD com auditoria de chave	CMK	Auditoria completa e controle de ciclo de vida
Necessidade de "kill switch" imediato	CMK	Revogação instantânea via Key Vault
Diferentes clientes com isolamento criptográfico na mesma conta	CMK + Encryption Scopes	Chaves por departamento/cliente
Chave nunca deve sair do ambiente do cliente	CPK	Chave provida por requisição, nunca armazenada no Azure
Requisito regulatório de double encryption	Infrastructure Encryption + CMK	Duas camadas independentes
HSM dedicado exigido por regulação	Azure Managed HSM + CMK	Hardware dedicado ao cliente

8.2 Quando usar Encryption Scopes

Cenário	Usar Encryption Scope?	Motivo
Múltiplos departamentos com dados sensíveis na mesma conta	Sim	Isolamento criptográfico por departamento
Conta com dados de múltiplos clientes	Sim	Chave por cliente, revogação individual
Conta homogênea com um único nível de sensibilidade	Não	Complexidade desnecessária
Conta com poucos containers não sensíveis	Não	MMK padrão é suficiente

8.3 System-assigned vs User-assigned Identity

Situação	Identidade recomendada	Motivo
Uma Storage Account, um Key Vault	System-assigned	Simplicidade, vinculada ao ciclo de vida da conta
Múltiplas Storage Accounts no mesmo Key Vault	User-assigned	Uma identidade, uma política de acesso
Automação com Terraform/Bicep	User-assigned	Evita dependência circular na implantação
Portabilidade entre contas	User-assigned	Reutilizável em múltiplos recursos

9. Boas Práticas

Habilite Purge Protection no Key Vault antes de vincular ao Storage. Sem isso, uma exclusão acidental do Key Vault pode tornar dados permanentemente inacessíveis.
Use User-assigned Managed Identity em automação (IaC) para evitar dependências circulares entre Storage Account e Key Vault.
Prefira Azure RBAC a Access Policies no Key Vault para gerenciamento mais granular e auditável.
Configure rotação automática de chave e defina a Storage Account para usar a versão mais recente da chave.
Habilite diagnósticos no Key Vault e envie para Log Analytics para auditoria completa de uso de chaves.
Teste o procedimento de revogação em ambientes de não-produção antes de implementar o "kill switch" em produção.
Use Encryption Scopes quando múltiplos contextos de dados com diferentes requisitos regulatórios coexistem na mesma Storage Account.
Documente a dependência entre Storage Account e Key Vault. Se o Key Vault for movido, deletado ou tiver permissões alteradas, a Storage Account para de funcionar.
Habilite Infrastructure Encryption na criação, nunca depois.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Storage Account inacessível após mudança de acesso no Key Vault	Permissões da identidade revogadas inadvertidamente	Teste mudanças de permissão em ambiente de não-produção
Não consegue habilitar Purge Protection no Key Vault	Key Vault já existe sem Purge Protection e não pode ser habilitado retroativamente em alguns casos	Crie Key Vaults com Purge Protection desde o início
Falha na vinculação CMK: "key not found"	Chave deletada ou versão específica expirada	Use rotação automática ou valide a URI da chave
Infrastructure Encryption não habilitado	Esqueceu de marcar a opção na criação	Use templates Bicep/ARM com a configuração definida
Encryption Scope desabilitado inadvertidamente	Blobs ficam inacessíveis imediatamente	Controle RBAC para operações de Encryption Scope
Dependência circular no Bicep/ARM	Storage precisa do Key Vault; Key Vault precisa do Principal ID da Storage	Use User-assigned Identity criada antes de ambos
Usar CPK sem implementação no cliente	CPK requer código na aplicação, não é automático	Só escolha CPK se há capacidade de implementação no SDK
Key Vault e Storage em regiões diferentes	Latência adicional e risco de falha em caso de falha regional	Coloque Key Vault e Storage na mesma região

11. Operação e Manutenção

11.1 Verificando a configuração de criptografia

Via CLI:

az storage account show \
  --name mystorageaccount \
  --resource-group myRG \
  --query encryption

Retorna o estado atual: keySource, keyVaultProperties, e se requireInfrastructureEncryption está ativo.

11.2 Rotacionando a chave manualmente

# Criar nova versão da chave no Key Vault
az keyvault key create \
  --vault-name myKeyVault \
  --name myStorageKey \
  --kty RSA \
  --size 2048

# Obter nova versão
NEW_KEY_VERSION=$(az keyvault key list-versions \
  --vault-name myKeyVault \
  --name myStorageKey \
  --query "[-1].kid" \
  --output tsv)

# Atualizar Storage Account para usar nova versão
az storage account update \
  --name mystorageaccount \
  --resource-group myRG \
  --encryption-key-uri $NEW_KEY_VERSION

11.3 Monitorando problemas de acesso ao Key Vault

Configure alertas no Azure Monitor para:

Falhas de autenticação no Key Vault: Indica que a identidade da Storage Account perdeu permissão.
Chave desabilitada ou expirada: Causa inacessibilidade imediata da Storage Account.
Purge de chave: Evento irreversível.

az monitor activity-log alert create \
  --name "keyvault-key-disabled" \
  --resource-group myRG \
  --condition category=Administrative and operationName=Microsoft.KeyVault/vaults/keys/update \
  --action-group myActionGroup

11.4 Limites importantes

Limite	Valor
Máximo de Encryption Scopes por Storage Account	10.000
Tamanho mínimo da chave RSA para CMK	2048 bits
Tipos de chave suportados	RSA, RSA-HSM
EC (Elliptic Curve) suportado?	Não para Storage

12. Integração e Automação

12.1 Azure Policy para conformidade de criptografia

Garanta que todas as Storage Accounts usem CMK:

# Atribuir policy built-in
az policy assignment create \
  --name "storage-cmk-required" \
  --policy "6fac406b-40ca-413b-bf8e-0bf964659c25" \
  --scope "/subscriptions/<subscription-id>"

A policy built-in Storage accounts should use customer-managed key for encryption audita ou nega contas sem CMK.

12.2 Automação de rotação com Azure Automation

Crie um Runbook PowerShell que:

Lista todas as Storage Accounts com CMK configurado
Verifica a idade da versão atual da chave
Cria nova versão se a chave tiver mais de 90 dias
Atualiza a Storage Account para a nova versão

12.3 Integração com Azure Defender for Storage

O Microsoft Defender for Storage monitora padrões de acesso anômalos à Storage Account, incluindo tentativas de acesso a dados com falhas de descriptografia, o que pode indicar uso de chave errada ou ataque.

az security pricing create \
  --name StorageAccounts \
  --tier Standard

13. Resumo Final

Conceitos essenciais:

Toda Storage Account no Azure tem criptografia AES-256 em repouso ativa obrigatoriamente. Não pode ser desabilitada.
A diferença está em quem controla a KEK (Key Encryption Key): Microsoft (MMK), o cliente via Key Vault (CMK) ou o cliente via requisição (CPK).
O modelo de duas camadas (DEK + KEK) permite rotação e revogação de acesso sem recriptografar os dados físicos.

Diferenças críticas:

MMK: Zero esforço operacional, zero visibilidade e controle sobre a chave.
CMK: Controle total e auditoria completa, mas requer Key Vault com Soft Delete e Purge Protection, Managed Identity e permissões configuradas.
CPK: Chave nunca armazenada no Azure, fornecida por requisição. Requer implementação no código da aplicação.
Encryption Scope: Permite chaves diferentes por container ou blob dentro da mesma Storage Account.
Infrastructure Encryption: Segunda camada de criptografia, habilitada apenas na criação, sempre gerenciada pela Microsoft.

O que precisa ser lembrado:

Key Vault precisa de Soft Delete e Purge Protection habilitados para ser usado com CMK.
A Storage Account acessa o Key Vault via Managed Identity com permissões get, wrapKey, unwrapKey.
Revogar acesso ao Key Vault torna a Storage Account imediatamente inacessível.
Infrastructure Encryption só pode ser habilitado na criação da conta.
Encryption Scopes não podem ser deletados, apenas desabilitados (e dados ficam inacessíveis enquanto desabilitados).
Key Vault e Storage Account devem estar preferencialmente na mesma região para minimizar latência e risco de falha.

1. Intuição Inicial​

2. Contexto​

2.1 Por que a criptografia em repouso existe​

2.2 O que a criptografia de Storage Account cobre​

3. Construção dos Conceitos​

3.1 Como a criptografia funciona internamente​

3.2 Os dois modelos de gerenciamento de chave​

Microsoft Managed Keys (MMK)​

Customer Managed Keys (CMK)​

Customer Provided Keys (CPK)​

3.3 Escopo da criptografia: conta vs infraestrutura​

3.4 Infrastructure Encryption (Double Encryption)​

4. Visão Estrutural: Fluxo de Escrita e Leitura​

5. Funcionamento na Prática​

5.1 Pré-requisitos para CMK​

5.2 Tipos de identidade gerenciada para CMK​

5.3 Rotação de chave​

5.4 Encryption Scopes: ciclo de vida​

6. Formas de Implementação​

6.1 Habilitando CMK via Portal Azure​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep​

6.5 Criando Encryption Scopes​

7. Controle e Segurança​

7.1 RBAC vs Access Policies no Key Vault​

7.2 O "kill switch" do CMK​

7.3 Auditoria de uso de chave​

8. Tomada de Decisão​

8.1 MMK vs CMK vs CPK​

8.2 Quando usar Encryption Scopes​

8.3 System-assigned vs User-assigned Identity​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

11.1 Verificando a configuração de criptografia​

11.2 Rotacionando a chave manualmente​

11.3 Monitorando problemas de acesso ao Key Vault​

11.4 Limites importantes​

12. Integração e Automação​

12.1 Azure Policy para conformidade de criptografia​

12.2 Automação de rotação com Azure Automation​

12.3 Integração com Azure Defender for Storage​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

2.1 Por que a criptografia em repouso existe

2.2 O que a criptografia de Storage Account cobre

3. Construção dos Conceitos

3.1 Como a criptografia funciona internamente

3.2 Os dois modelos de gerenciamento de chave

Microsoft Managed Keys (MMK)

Customer Managed Keys (CMK)

Customer Provided Keys (CPK)

3.3 Escopo da criptografia: conta vs infraestrutura

3.4 Infrastructure Encryption (Double Encryption)

4. Visão Estrutural: Fluxo de Escrita e Leitura

5. Funcionamento na Prática

5.1 Pré-requisitos para CMK

5.2 Tipos de identidade gerenciada para CMK

5.3 Rotação de chave

5.4 Encryption Scopes: ciclo de vida

6. Formas de Implementação

6.1 Habilitando CMK via Portal Azure

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep

6.5 Criando Encryption Scopes

7. Controle e Segurança

7.1 RBAC vs Access Policies no Key Vault

7.2 O "kill switch" do CMK

7.3 Auditoria de uso de chave

8. Tomada de Decisão

8.1 MMK vs CMK vs CPK

8.2 Quando usar Encryption Scopes

8.3 System-assigned vs User-assigned Identity

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Verificando a configuração de criptografia

11.2 Rotacionando a chave manualmente

11.3 Monitorando problemas de acesso ao Key Vault

11.4 Limites importantes

12. Integração e Automação

12.1 Azure Policy para conformidade de criptografia

12.2 Automação de rotação com Azure Automation

12.3 Integração com Azure Defender for Storage

13. Resumo Final