Fundamentação Teórica: Configure Soft Delete for Blobs and Containers

1. Intuição Inicial

Imagine que você trabalha com um sistema operacional que tem uma lixeira. Quando você exclui um arquivo, ele não desaparece imediatamente: vai para a lixeira e permanece lá por um período. Se você se arrepender, pode restaurá-lo. Só depois de esvaziar a lixeira (ou após o prazo automático) o arquivo é permanentemente removido.

Soft Delete no Azure Blob Storage é exatamente essa lixeira, aplicada a blobs e containers. Quando habilitado, qualquer exclusão é temporária: o dado fica em um estado "soft-deleted" por um período configurável, durante o qual pode ser restaurado com uma única operação. Após esse período, é permanentemente removido.

Isso protege contra dois dos erros mais comuns e devastadores em ambientes cloud: exclusão acidental por um operador e exclusão maliciosa por ransomware ou atacante que comprometeu credenciais.

2. Contexto

2.1 Soft Delete dentro da estratégia de proteção de dados

O Azure oferece múltiplas camadas de proteção para dados no Blob Storage. O Soft Delete é uma delas:

100%

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

Soft Delete é a camada mais simples e de menor custo de implementar. É o mínimo recomendado pela Microsoft para qualquer Storage Account de produção.

2.2 O que Soft Delete protege e o que não protege

Protege contra	Não protege contra
Exclusão acidental de blobs	Corrupção do conteúdo do blob (arquivo sobrescrito com dados errados)
Exclusão acidental de containers	Exclusão após o período de retenção expirar
Ataques de ransomware que deletam blobs	Ransomware que sobrescreve o conteúdo do blob
Scripts com bugs que deletam dados	Exclusão proposital dentro do período (admins com permissão)

Para proteção contra sobrescrita de conteúdo, combine Soft Delete com Blob Versioning.

3. Construção dos Conceitos

3.1 Soft Delete de blob vs Soft Delete de container

Existem dois mecanismos independentes de Soft Delete no Azure Blob Storage:

Soft Delete de Blob:

Aplicado a blobs individuais
Quando um blob é deletado, ele entra no estado soft-deleted
Disponível para restauração pelo período configurado
Configurado em dias (1 a 365)
Funciona para Block Blobs, Append Blobs e Page Blobs

Soft Delete de Container:

Aplicado a containers inteiros
Quando um container é deletado (com todo o seu conteúdo), o container entra no estado soft-deleted
Todo o conteúdo do container é recuperável
Configurado em dias (1 a 365)
Configurado separadamente do Soft Delete de blob

Ponto crítico: Os dois mecanismos são independentes. Você pode habilitar um sem o outro. Se um blob dentro de um container for deletado, o Soft Delete de blob se aplica (não o de container). Se o container inteiro for deletado, o Soft Delete de container se aplica.

3.2 Estados de um blob com Soft Delete habilitado

100%

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

3.3 Estados de um container com Soft Delete habilitado

100%

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

3.4 Interação entre Soft Delete de blob e Blob Versioning

Quando Blob Versioning está habilitado junto com Soft Delete, o comportamento muda:

Cada modificação de um blob cria uma nova versão
Quando o blob atual é deletado, a versão atual se torna uma versão anterior (não entra em soft-delete porque o versioning a preserva automaticamente)
O Soft Delete passa a proteger as versões anteriores que são explicitamente deletadas

Na prática, com Versioning habilitado, o Soft Delete de blob protege versões deletadas, não o blob "atual" (que ao ser deletado simplesmente se torna uma versão anterior).

Esta interação é um dos pontos mais complexos e cobrados no AZ-104.

3.5 Soft Delete e snapshots

Snapshots de blobs também têm interação com Soft Delete:

Se você deleta um blob com seus snapshots, e Soft Delete está ativo, tanto o blob quanto os snapshots entram em estado soft-deleted.
Se você deleta apenas um snapshot específico, ele entra em soft-deleted.
A restauração do blob via Undelete restaura o blob e todos os seus snapshots soft-deleted simultaneamente.

3.6 O custo do Soft Delete

Dados soft-deleted ainda ocupam espaço e ainda são cobrados, no tier de acesso do blob no momento da exclusão:

Um blob de 10 GB em tier Hot deletado no dia 1 continua sendo cobrado por 10 GB em Hot durante todo o período de retenção.
Se o blob foi recentemente movido para Archive e então deletado, o custo de retenção é no tier Archive.

Isso é importante para dimensionar o período de retenção: períodos longos em dados de grande volume podem ter impacto significativo no custo.

4. Visão Estrutural

100%

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

5. Funcionamento na Prática

5.1 O que acontece internamente ao deletar um blob

Quando Soft Delete está habilitado e você executa uma operação Delete Blob:

O Azure não remove fisicamente o dado. Ele marca o blob com a propriedade Deleted: true e registra a data de expiração (data atual + período de retenção).
O blob some das listagens padrão (List Blobs sem o parâmetro de include deleted).
O blob continua ocupando espaço e sendo cobrado.
Qualquer tentativa de acessar o blob pela URL retorna 404 Not Found (como se não existisse).
Para ver blobs soft-deleted, você precisa usar List Blobs com o parâmetro include=deleted.
Para restaurar, você executa Undelete Blob.

5.2 O que acontece ao deletar um container

Quando Soft Delete de Container está habilitado e você executa Delete Container:

O container e todos os seus blobs entram em estado soft-deleted simultaneamente.
O container não aparece mais em listagens normais de containers.
Para listar containers soft-deleted, use List Containers com include=deleted.
Para restaurar, execute Restore Container, que recria o container com o mesmo nome e restaura todos os blobs que estavam nele.

Comportamento não óbvio: Se você tentar criar um novo container com o mesmo nome de um container soft-deleted, a operação falha enquanto o container soft-deleted existir. O Azure reserva o nome durante o período de retenção.

5.3 Restaurando um blob soft-deleted

A operação Undelete Blob (ou Restore Blob em algumas interfaces) restaura o blob para o estado ativo. A operação:

Não requer parâmetros especiais além da identificação do blob
Restaura o blob para o mesmo container onde estava
Restaura também todos os snapshots soft-deleted do blob
Não altera o tier do blob (mantém o tier que tinha antes da exclusão)

6. Formas de Implementação

6.1 Portal Azure

Habilitando Soft Delete de blob:

Storage Account > Data Protection > Enable soft delete for blobs

Você define o período de retenção em dias (1 a 365). O portal mostra um slider visual.

Habilitando Soft Delete de container:

Storage Account > Data Protection > Enable soft delete for containers

Período configurado separadamente, também de 1 a 365 dias.

Restaurando blobs deletados no portal:

Storage Account > Containers > [container] > Show deleted blobs

O portal exibe blobs soft-deleted com um ícone distinto e permite restaurar individualmente clicando no blob e selecionando "Undelete".

Restaurando container deletado no portal:

Storage Account > Containers > (selecionar "Show deleted containers" no topo da listagem)

Containers soft-deleted aparecem na lista com status "Deleted". Selecione e clique em "Restore".

6.2 Azure CLI

Habilitando Soft Delete de blob e container:

# Habilitar Soft Delete de blob com 7 dias de retenção
az storage account blob-service-properties update \
  --account-name myaccount \
  --resource-group myRG \
  --enable-delete-retention true \
  --delete-retention-days 7

# Habilitar Soft Delete de container com 30 dias de retenção
az storage account blob-service-properties update \
  --account-name myaccount \
  --resource-group myRG \
  --enable-container-delete-retention true \
  --container-delete-retention-days 30

Verificando configuração atual:

az storage account blob-service-properties show \
  --account-name myaccount \
  --resource-group myRG \
  --query "{blobSoftDelete: deleteRetentionPolicy, containerSoftDelete: containerDeleteRetentionPolicy}"

Listando blobs soft-deleted:

az storage blob list \
  --account-name myaccount \
  --container-name mycontainer \
  --include d \
  --auth-mode login \
  --output table

O parâmetro --include d instrui a listar blobs em estado deleted.

Restaurando um blob soft-deleted:

az storage blob undelete \
  --account-name myaccount \
  --container-name mycontainer \
  --name relatorio-deletado.xlsx \
  --auth-mode login

Listando containers soft-deleted:

az storage container list \
  --account-name myaccount \
  --include-deleted \
  --auth-mode login \
  --output table

Restaurando um container soft-deleted:

az storage container restore \
  --account-name myaccount \
  --deleted-container-name mycontainer \
  --deleted-container-version <version-id> \
  --auth-mode login

O --deleted-container-version é obtido na listagem de containers deleted e é um identificador interno gerado no momento da exclusão.

6.3 Azure PowerShell

$ctx = New-AzStorageContext `
  -StorageAccountName "myaccount" `
  -UseConnectedAccount

# Listar blobs soft-deleted
Get-AzStorageBlob `
  -Container "mycontainer" `
  -Context $ctx `
  -IncludeDeleted

# Restaurar blob soft-deleted
$blob = Get-AzStorageBlob `
  -Container "mycontainer" `
  -Blob "relatorio-deletado.xlsx" `
  -Context $ctx `
  -IncludeDeleted

$blob.ICloudBlob.UndeleteAsync()

# Listar containers soft-deleted
Get-AzStorageContainer `
  -Context $ctx `
  -IncludeDeleted

# Restaurar container
Restore-AzStorageContainer `
  -Name "mycontainer" `
  -VersionId "<version-id>" `
  -Context $ctx

6.4 Bicep

resource blobServiceProperties 'Microsoft.Storage/storageAccounts/blobServices@2023-01-01' = {
  name: '${storageAccount.name}/default'
  properties: {
    // Soft Delete de blob: 7 dias
    deleteRetentionPolicy: {
      enabled: true
      days: 7
    }
    // Soft Delete de container: 30 dias
    containerDeleteRetentionPolicy: {
      enabled: true
      days: 30
    }
    // Opcional: habilitar junto com versioning
    isVersioningEnabled: true
  }
}

6.5 Azure Policy para conformidade

Para garantir que toda Storage Account tenha Soft Delete habilitado:

# Atribuir policy built-in de auditoria
az policy assignment create \
  --name "require-blob-soft-delete" \
  --policy "b38aa5b8-ac51-4f91-8a3e-a7ec3f58c62a" \
  --scope "/subscriptions/<sub-id>"

Políticas built-in relevantes:

"Blob soft delete should be enabled" (auditoria)
"Configure blob soft delete for storage accounts" (deploy automático via DeployIfNotExists)

7. Controle e Segurança

7.1 Quem pode fazer Undelete

A operação de restauração (Undelete Blob, Restore Container) requer:

Método de autenticação	Permissão mínima
Azure AD (RBAC)	Storage Blob Data Contributor
Storage Account Key	Acesso total
SAS token	Permissão `d` (delete) no blob ou container

Ponto não óbvio: A permissão necessária para restaurar um blob é a mesma necessária para deletar. Isso faz sentido: Undelete é o inverso de Delete, e ambas são operações de mutação sobre o estado do blob.

7.2 Soft Delete não é proteção contra tudo

Um usuário ou script com permissão Storage Blob Data Contributor pode:

Deletar um blob (ele vai para soft-deleted)
Listar os blobs soft-deleted
Deletar permanentemente os blobs soft-deleted usando a API de purge

A operação Purge Deleted Blob (purge via REST API ou SDK) remove permanentemente um blob soft-deleted antes do período de retenção expirar. Para evitar esse vetor de ataque, combine Soft Delete com Immutability Policies ou restrinja quem tem permissão de delete.

Para proteção contra ransomware que ataca com credenciais comprometidas, Immutability Policies (WORM) são a solução mais robusta, pois nem o próprio administrador pode deletar dados imutáveis antes do prazo.

7.3 Auditoria de operações de delete e restore

Configure diagnósticos para registrar operações de exclusão e restauração:

az monitor diagnostic-settings create \
  --name "storage-audit" \
  --resource <storage-account-id> \
  --logs '[
    {"category": "StorageDelete", "enabled": true},
    {"category": "StorageWrite", "enabled": true}
  ]' \
  --workspace <log-analytics-workspace-id>

Com isso, toda operação de Delete Blob, Undelete Blob, Delete Container e Restore Container fica registrada com identidade do executor, timestamp e resultado.

8. Tomada de Decisão

8.1 Período de retenção: quanto tempo configurar

Situação	Período recomendado	Motivo
Storage Account de desenvolvimento	7 dias	Baixo custo, proteção básica
Aplicação de produção com dados mutáveis	14 a 30 dias	Janela adequada para detectar exclusões acidentais
Dados com requisito regulatório	30 a 365 dias	Conformidade exige janela maior
Dados críticos de negócio	30 dias (blob) + 30 dias (container)	Proteção dupla
Conta com grande volume (TB) em Hot	7 dias	Custo de retenção x segurança

8.2 Soft Delete de blob vs Soft Delete de container: quando um não é suficiente

Situação	Configuração necessária
Proteção contra delete de arquivo individual	Soft Delete de blob
Proteção contra delete de container inteiro	Soft Delete de container
Proteção completa	Ambos habilitados
Proteção contra sobrescrita de conteúdo	Blob Versioning (Soft Delete não ajuda aqui)
Proteção máxima contra ransomware	Immutability Policy + Soft Delete

8.3 Soft Delete vs Blob Versioning: diferenças

Aspecto	Soft Delete	Blob Versioning
Protege contra	Exclusão do blob	Sobrescrita e exclusão
Quando é ativado	Na exclusão	Em cada modificação
Período de proteção	Configurável (dias)	Enquanto versões existirem
Custo	Blob deletado continua sendo cobrado	Cada versão é cobrada separadamente
Restauração	Undelete (uma operação)	Copiar versão anterior sobre a atual
Recomendação	Habilitar sempre	Habilitar quando histórico de modificações é importante

9. Boas Práticas

Habilite Soft Delete em toda Storage Account de produção como política padrão. O custo de armazenamento temporário durante a retenção é muito menor que o custo de uma exclusão acidental irreversível.
Configure Soft Delete de container com período maior que Soft Delete de blob. A exclusão acidental de um container inteiro é mais catastrófica e mais difícil de detectar rapidamente.
Combine Soft Delete com Blob Versioning para proteção completa: Versioning protege contra sobrescrita, Soft Delete protege contra exclusão.
Use Azure Policy com efeito DeployIfNotExists para garantir que novas Storage Accounts sejam criadas automaticamente com Soft Delete habilitado.
Monitore o BlobCapacity de blobs soft-deleted separadamente para entender o custo real da funcionalidade. Use a dimensão BlobType com valor SoftDeletedBlob.
Documente o processo de restauração para a equipe de operações. Em momentos de incidente, ter um runbook claro acelera a recuperação.
Configure alertas para quando o volume de blobs soft-deleted aumentar abruptamente, o que pode indicar um ataque ou script com bug.
Teste a restauração periodicamente em ambiente de não-produção para garantir que o processo funciona corretamente antes de um incidente real.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Soft Delete habilitado mas blob não é recuperável	Período de retenção já expirou	Monitorar blobs soft-deleted e agir dentro do prazo
Não consegue criar container com mesmo nome	Container soft-deleted ainda existe com esse nome	Listar containers deleted e restaurar ou aguardar expiração
Custo inesperado após habilitar Soft Delete	Blobs deletados continuam sendo cobrados durante retenção	Dimensionar período de retenção considerando volume de dados excluídos
Confundir Soft Delete de blob com de container	São mecanismos independentes e configurados separadamente	Verificar ambas as configurações em `Data Protection`
Soft Delete não protege contra sobrescrita	Proteção é apenas para exclusão, não para modificação de conteúdo	Combinar com Blob Versioning para proteção completa
Blob soft-deleted não aparece no portal	Portal não mostra soft-deleted por padrão	Usar "Show deleted blobs" no portal ou `--include d` na CLI
Undelete falha com erro 404	Período de retenção já expirou; blob foi permanentemente removido	Atuar antes do período expirar; aumentar período se necessário
Soft Delete desabilitado acidentalmente	Alguém alterou as configurações de Data Protection	Usar Azure Policy para prevenir desabilitação ou gerar alerta

11. Operação e Manutenção

11.1 Verificando o status atual do Soft Delete

# Verificar configuração completa de proteção de dados
az storage account blob-service-properties show \
  --account-name myaccount \
  --resource-group myRG \
  --query "{
    blobSoftDelete: deleteRetentionPolicy,
    containerSoftDelete: containerDeleteRetentionPolicy,
    versioning: isVersioningEnabled,
    changeFeed: changeFeed
  }"

11.2 Monitorando volume de blobs soft-deleted

No Azure Monitor:

az monitor metrics list \
  --resource <storage-account-id> \
  --metric BlobCapacity \
  --dimension BlobType \
  --interval PT1H

O valor retornado com BlobType=SoftDeletedBlob indica quanto espaço está sendo ocupado por dados soft-deleted.

Configure um alerta para detectar aumentos abruptos:

az monitor metrics alert create \
  --name "soft-deleted-spike" \
  --resource-group myRG \
  --scopes <storage-account-id> \
  --condition "total BlobCapacity > 10000000000" \
  --condition-dimension BlobType=SoftDeletedBlob \
  --window-size 1h \
  --evaluation-frequency 15m \
  --action myActionGroup

11.3 Forçando expiração antecipada (purge)

Em cenários onde você precisa liberar espaço imediatamente (dados soft-deleted de testes, por exemplo), você pode purgar blobs soft-deleted via REST API ou SDK:

from azure.storage.blob import BlobServiceClient

client = BlobServiceClient.from_connection_string(conn_str)
blob_client = client.get_blob_client(container="mycontainer", blob="test-blob.txt")

# Purgar versão soft-deleted (requer versão específica)
blob_client.delete_blob(delete_snapshots="include", version_id="<version-id>")

Esta operação é irreversível. Apenas use quando tiver certeza que os dados não são necessários.

11.4 Limites importantes

Aspecto	Limite
Período mínimo de retenção	1 dia
Período máximo de retenção	365 dias
Soft Delete disponível em tipos de conta	Standard GPv2, Premium Block Blob, Standard GPv1 (blob apenas)
Soft Delete de container em Premium	Disponível
Custo de dados soft-deleted	Cobrado no tier do blob no momento da exclusão
Soft Delete se aplica a	Block Blobs, Append Blobs, Page Blobs, Snapshots, Versões

12. Integração e Automação

12.1 Automação de restauração com Azure Functions

Para criar um sistema automatizado de detecção e alerta de exclusões:

import azure.functions as func
from azure.storage.blob import BlobServiceClient
import logging

def main(timer: func.TimerRequest):
    """
    Executa diariamente e lista todos os blobs soft-deleted,
    enviando alerta se volume exceder threshold.
    """
    client = BlobServiceClient.from_connection_string(conn_str)
    
    soft_deleted_count = 0
    for container in client.list_containers():
        for blob in client.get_container_client(container['name']).list_blobs(include=['deleted']):
            if blob['deleted']:
                soft_deleted_count += 1
                logging.warning(f"Blob soft-deleted: {container['name']}/{blob['name']}")
    
    if soft_deleted_count > 100:
        # Acionar alerta via Logic Apps, Teams ou email
        logging.error(f"ALERTA: {soft_deleted_count} blobs soft-deleted detectados!")

12.2 Azure Policy: DeployIfNotExists para Soft Delete

Crie uma policy que automaticamente habilita Soft Delete em novas Storage Accounts:

{
  "if": {
    "field": "type",
    "equals": "Microsoft.Storage/storageAccounts"
  },
  "then": {
    "effect": "DeployIfNotExists",
    "details": {
      "type": "Microsoft.Storage/storageAccounts/blobServices",
      "existenceCondition": {
        "field": "Microsoft.Storage/storageAccounts/blobServices/deleteRetentionPolicy.enabled",
        "equals": true
      },
      "deployment": {
        "properties": {
          "mode": "incremental",
          "template": {
            "$schema": "...",
            "resources": [{
              "type": "Microsoft.Storage/storageAccounts/blobServices",
              "name": "[concat(parameters('storageAccountName'), '/default')]",
              "properties": {
                "deleteRetentionPolicy": {
                  "enabled": true,
                  "days": 7
                },
                "containerDeleteRetentionPolicy": {
                  "enabled": true,
                  "days": 30
                }
              }
            }]
          }
        }
      }
    }
  }
}

13. Resumo Final

Conceitos essenciais:

Soft Delete funciona como uma lixeira: dados deletados ficam em estado soft-deleted por um período configurável (1 a 365 dias) e podem ser restaurados durante esse período.
Existem dois mecanismos independentes: Soft Delete de blob e Soft Delete de container, cada um configurado com seu próprio período de retenção.
Dados soft-deleted são invisíveis em listagens normais mas continuam ocupando espaço e sendo cobrados.
Soft Delete protege contra exclusão, não contra sobrescrita. Para proteção contra modificação de conteúdo, combine com Blob Versioning.

Diferenças críticas:

Soft Delete de blob vs Soft Delete de container: Blob protege arquivos individuais; Container protege o container inteiro com todo o seu conteúdo. Devem ser configurados separadamente.
Soft Delete vs Immutability Policy: Soft Delete é recuperação pós-exclusão. Immutability previne a exclusão antes que ela ocorra.
Soft Delete vs Blob Versioning: Soft Delete recupera blobs deletados. Versioning mantém histórico de versões de um blob modificado. São complementares, não excludentes.
Restaurar blob vs restaurar container: Undelete Blob restaura um blob individual. Restore Container restaura o container e todos os blobs que estavam nele.

O que precisa ser lembrado:

Habilite Soft Delete em toda Storage Account de produção como prática padrão mínima.
O período de retenção deve ser configurado antes de qualquer exclusão. Soft Delete não retroage para exclusões anteriores à habilitação.
Containers soft-deleted reservam o nome: não é possível criar outro container com o mesmo nome até que o soft-deleted expire ou seja explicitamente restaurado.
A operação de Undelete restaura o blob e todos os seus snapshots simultaneamente.
Dados soft-deleted podem ser purgados antecipadamente via API por usuários com permissão de delete. Para proteção contra isso, use Immutability Policies.
Monitore o volume de SoftDeletedBlob no Azure Monitor para controlar custos e detectar padrões anômalos de exclusão.

1. Intuição Inicial​

2. Contexto​

2.1 Soft Delete dentro da estratégia de proteção de dados​

2.2 O que Soft Delete protege e o que não protege​

3. Construção dos Conceitos​

3.1 Soft Delete de blob vs Soft Delete de container​

3.2 Estados de um blob com Soft Delete habilitado​

3.3 Estados de um container com Soft Delete habilitado​

3.4 Interação entre Soft Delete de blob e Blob Versioning​

3.5 Soft Delete e snapshots​

3.6 O custo do Soft Delete​

4. Visão Estrutural​

5. Funcionamento na Prática​

5.1 O que acontece internamente ao deletar um blob​

5.2 O que acontece ao deletar um container​

5.3 Restaurando um blob soft-deleted​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep​

6.5 Azure Policy para conformidade​

7. Controle e Segurança​

7.1 Quem pode fazer Undelete​

7.2 Soft Delete não é proteção contra tudo​

7.3 Auditoria de operações de delete e restore​

8. Tomada de Decisão​

8.1 Período de retenção: quanto tempo configurar​

8.2 Soft Delete de blob vs Soft Delete de container: quando um não é suficiente​

8.3 Soft Delete vs Blob Versioning: diferenças​

9. Boas Práticas​

10. Erros Comuns​

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

11.1 Verificando o status atual do Soft Delete​

11.2 Monitorando volume de blobs soft-deleted​

11.3 Forçando expiração antecipada (purge)​

11.4 Limites importantes​

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

12.1 Automação de restauração com Azure Functions​

12.2 Azure Policy: DeployIfNotExists para Soft Delete​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

2.1 Soft Delete dentro da estratégia de proteção de dados

2.2 O que Soft Delete protege e o que não protege

3. Construção dos Conceitos

3.1 Soft Delete de blob vs Soft Delete de container

3.2 Estados de um blob com Soft Delete habilitado

3.3 Estados de um container com Soft Delete habilitado

3.4 Interação entre Soft Delete de blob e Blob Versioning

3.5 Soft Delete e snapshots

3.6 O custo do Soft Delete

4. Visão Estrutural

5. Funcionamento na Prática

5.1 O que acontece internamente ao deletar um blob

5.2 O que acontece ao deletar um container

5.3 Restaurando um blob soft-deleted

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep

6.5 Azure Policy para conformidade

7. Controle e Segurança

7.1 Quem pode fazer Undelete

7.2 Soft Delete não é proteção contra tudo

7.3 Auditoria de operações de delete e restore

8. Tomada de Decisão

8.1 Período de retenção: quanto tempo configurar

8.2 Soft Delete de blob vs Soft Delete de container: quando um não é suficiente

8.3 Soft Delete vs Blob Versioning: diferenças

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Verificando o status atual do Soft Delete

11.2 Monitorando volume de blobs soft-deleted

11.3 Forçando expiração antecipada (purge)

11.4 Limites importantes

12. Integração e Automação

12.1 Automação de restauração com Azure Functions

12.2 Azure Policy: DeployIfNotExists para Soft Delete

13. Resumo Final