Migração de Secrets entre Azure Key Vaults

Postado em Feb 20, 2026

Por Luiz Henrique

5 min de leitura

Olá pessoal! Blz?

Nesse artigo quero trazer a vocês algo simples mas algo que um dia ou outro você pode necessitar que seria migrar os Secrets de um Azure key vault para outro. Algumas vezes essa cópia se deve por alterar o nome do key vault ou uma restruturação na organização.

Para chegar nesse objetivo o powershell é nosso amigo e trabalha muito bem para isso. Esse cenário aparece com frequência em:

Migração entre ambientes (raro mas pode acontecer)
Mudança de subscription ou tenant
Padronização de ambientes (Landing Zones)
Automação com Terraform ou pipelines

Neste artigo, vou mostrar as formas corretas de fazer isso, com exemplos práticos em PowerShell e considerações reais de projeto.

Entendendo o problema

Antes de simplesmente copiar um secret entre Key Vaults, é importante entender um ponto fundamental:

No Azure Key Vault, um secret vai muito além de um simples valor. Além do conteúdo em si, ele pode incluir:

múltiplas versões (versionamento automático)
data de expiração
tags para organização
content type

Isso significa que, dependendo do método utilizado para cópia, você pode estar transferindo apenas o valor atual e deixando para trás informações importantes — o que pode impactar governança, rastreabilidade e até segurança.

Permissões necessárias

Antes de executar qualquer cópia de secrets entre Key Vaults, é fundamental garantir que a identidade utilizada (usuário, service principal ou managed identity) tenha as permissões corretas em ambos os lados.

O modelo de permissão pode variar dependendo da configuração do Key Vault: Access Policy (modelo clássico) ou RBAC (modelo recomendado).

Access Policy (modelo tradicional)

No modelo de Access Policy, as permissões são definidas diretamente no Key Vault.

Para realizar a cópia de secrets utilizando o método mais comum (Get + Set), você precisa configurar:

No Key Vault de origem: secrets/get → para ler o valor do secret
No Key Vault de destino: secrets/set → para criar ou atualizar o secret
Opcionalmente: secrets/list → necessário em cenários de automação, quando você precisa listar todos os secrets do vault

RBAC (modelo recomendado)

No modelo baseado em RBAC, as permissões são atribuídas através de roles no Azure, trazendo mais controle e integração com governança corporativa.

As roles mais utilizadas nesse cenário são:

Key Vault Secrets User: Permite leitura dos secrets (equivalente ao get)
Key Vault Secrets Officer: Permite criação e atualização de secrets (equivalente ao set)
Key Vault Administrator: Permissão total sobre o Key Vault (incluindo secrets, keys e certificates)

Métodos para cópia de secrets em diferentes modelos de permissão

Em ambientes corporativos Azure, é muito comum encontrar cenários híbridos, como: Key Vaults antigos usando Access Policy, Key Vaults novos utilizando RBAC.

Método 1 — Access Policy → RBAC (migração de modelo)

Esse é um dos cenários mais comuns em ambientes corporativos que estão passando por modernização no Azure.

Historicamente, muitos ambientes foram construídos utilizando o modelo de Access Policy, onde as permissões são definidas diretamente no Key Vault. No entanto, com a evolução das boas práticas de governança, o modelo baseado em RBAC se tornou o padrão recomendado.

No Azure Key Vault, é possível trabalhar com esses dois modelos de forma independente — o que permite realizar migrações de forma gradual, sem necessidade de interrupção do serviço.

  
$sourceVault = "kv-origem-ap"
$targetVault = "kv-destino-rbac"

$secrets = Get-AzKeyVaultSecret -VaultName $sourceVault

foreach ($secret in $secrets) {

    try {
        Write-Host "Copiando secret:" $secret.Name

        $secretValue = Get-AzKeyVaultSecret `
            -VaultName $sourceVault `
            -Name $secret.Name

        Set-AzKeyVaultSecret `
            -VaultName $targetVault `
            -Name $secret.Name `
            -SecretValue $secretValue.SecretValue `
            -Expires $secretValue.Expires `
            -ContentType $secretValue.ContentType `
            -Tag $secretValue.Tags

    } catch {
        Write-Warning "Erro ao copiar $($secret.Name): $_"
    }
}

Se precisamos manter o histórico de versões o mais indicado é usar o método de Backup/Restore:

  
$secretName = "meu-secret"
$sourceVault = "kv-origem"
$targetVault = "kv-destino"
$backupFile = "C:\Temp\meu-secret.backup"

# Backup do secret
Backup-AzKeyVaultSecret `
    -VaultName $sourceVault `
    -Name $secretName `
    -OutputFile $backupFile

# Restore no outro Key Vault
Restore-AzKeyVaultSecret `
    -VaultName $targetVault `
    -InputFile $backupFile

Método 2 — RBAC → RBAC (padrão enterprise)

Esse é o cenário mais comum em ambientes modernos e bem estruturados no Azure, onde o modelo de permissões baseado em RBAC já está consolidado.

Ao utilizar RBAC no Azure Key Vault, o controle de acesso deixa de ser configurado diretamente no recurso e passa a ser gerenciado de forma centralizada, seguindo as práticas de governança do Azure.

  
$sourceVault = "kv-origem-rbac"
$targetVault = "kv-destino-rbac"

$secrets = Get-AzKeyVaultSecret -VaultName $sourceVault

foreach ($secret in $secrets) {

    try {
        Write-Output "Processando secret: $($secret.Name)"

        $secretValue = Get-AzKeyVaultSecret `
            -VaultName $sourceVault `
            -Name $secret.Name

        # Verifica se já existe no destino
        $existing = Get-AzKeyVaultSecret `
            -VaultName $targetVault `
            -Name $secret.Name `
            -ErrorAction SilentlyContinue

        if ($null -ne $existing) {
            Write-Output "Secret já existe no destino: $($secret.Name)"
            continue
        }

        Set-AzKeyVaultSecret `
            -VaultName $targetVault `
            -Name $secret.Name `
            -SecretValue $secretValue.SecretValue `
            -Expires $secretValue.Expires `
            -ContentType $secretValue.ContentType `
            -Tag $secretValue.Tags

        Write-Output "Secret copiado com sucesso: $($secret.Name)"

    } catch {
        Write-Error "Falha ao processar $($secret.Name): $_"
    }
}

Concluindo!

Copiar secrets entre Key Vaults no Azure é uma tarefa comum, mas que exige atenção ao modelo de permissões, método utilizado e impacto na governança. Vimos que, na prática, o uso de Get + Set é o mais flexível para automação e migração, enquanto o Backup/Restore é indicado quando há necessidade de preservar versões.

Mais do que uma simples cópia, esse processo faz parte da evolução do ambiente para um modelo mais moderno, automatizado e alinhado com boas práticas de cloud.

Bom pessoal, eu tenho usado isso em alguns ambientes e acredito que possa ser bem útil a vocês!