Replicação contínua e failover entre regiões. Vizinho de Backup & Recovery e distinto dele: backup guarda cópia para restaurar depois; DR mantém réplica quente para assumir agora. Quem controla o failover pode redirecionar produção inteira.
O Entra ID não faz DR de infraestrutura. Entra Backup Reader é o equivalente mais próximo e é somente-leitura sobre o Microsoft 365 Backup. Replicação de workload é Azure RBAC.
Permissões
- microsoft.backup/allEntities/allProperties/read — ler configuração e status do Microsoft 365 Backup
- Consultar políticas de proteção aplicadas a caixas de correio e sites
- Acompanhar o histórico de execução de backup do M365
- Verificar cobertura de proteção sem poder alterá-la
- Sem permissão de restauração — leitura apenas
Mitigações
- Registrar o escopo real: esta role cobre Microsoft 365 Backup, não DR de infraestrutura
- Usar Azure RBAC Site Recovery Contributor para replicação de workload
Permissões
- Microsoft.RecoveryServices/vaults/replicationFabrics/* — configurar fabrics de replicação
- Microsoft.RecoveryServices/vaults/replicationPolicies/* — definir RPO e retenção de pontos de recuperação
- Microsoft.RecoveryServices/vaults/replicationProtectedItems/* — proteger e failover de itens
- Microsoft.Network/* — criar a rede da região secundária para o failover
- Microsoft.Compute/virtualMachines/* — recriar VMs no destino
Mitigações
- Exigir aprovação fora da ferramenta para failover não planejado — a ação redireciona produção
- Testar failover em rede isolada trimestralmente, com relatório de RTO e RPO medidos
- Alertar sobre alteração de política de replicação: aumentar RPO degrada a proteção sem erro visível
- Separar de Backup Contributor quando os times de DR e backup forem distintos
- Restringir o escopo ao cofre do Recovery Services, não à subscription
Permissões
- drs:StartRecovery — iniciar recuperação de instâncias na região de destino
- drs:StartFailbackLaunch — executar o failback para a origem
- drs:UpdateReplicationConfiguration — alterar janela e banda de replicação
- drs:DisconnectSourceServer — desconectar servidor de origem, interrompendo a replicação
- ec2:RunInstances — lançar as instâncias de recuperação
Mitigações
- Alertar sobre DisconnectSourceServer — desconectar a origem para a proteção de forma silenciosa
- Restringir drs:StartRecovery por condição de tag no servidor de origem
- Executar drill de recuperação trimestral com métrica de RTO registrada
- Manter a conta de DR separada da conta de produção no Organizations
- Monitorar o lag de replicação como alerta operacional, não como painel consultado ocasionalmente
Permissões
- backupdr.backupPlanAssociations.create — associar recurso a um plano de proteção
- backupdr.backups.restore — restaurar recurso a partir de um backup
- backupdr.backupVaults.get — ler configuração do cofre de backup
- backupdr.managementServers.get — consultar o servidor de gerenciamento
- compute.instances.create — criar a instância de destino da restauração
Mitigações
- Separar de roles/backupdr.admin: restaurar e administrar o cofre não precisam ser a mesma pessoa
- Restaurar sempre em projeto de destino distinto do de produção durante o teste
- Habilitar imutabilidade do cofre para que a restauração não conviva com exclusão de backup
- Auditar backupdr.backups.restore — a restauração recria dado num contexto de IAM possivelmente diferente do original
- Medir RTO em drill trimestral, não em estimativa
A IBM tem 7 roles e nenhuma é específica de serviço: o que varia é o serviço sobre o qual a role é atribuída. Aqui é a role de Operator sobre VPC Infrastructure Services. A IBM não publica a lista de ações por role — cada serviço mapeia as próprias.
Permissões
- Operar snapshots e réplicas de volume entre zonas
- Executar failover de volume replicado para a zona secundária
- Configurar cross-region replication de buckets do Object Storage
- Gerenciar imagens personalizadas usadas na recriação de instâncias
- Acompanhar status de replicação sem alterar a topologia da VPC
Mitigações
- Separar quem executa failover de quem define a política de replicação
- Testar failover entre zonas trimestralmente com RTO registrado
- Manter réplica em região distinta, não apenas em zona distinta
- Auditar mudanças de configuração de replicação via Activity Tracker
- Registrar que a IBM não publica a lista de ações por role: o alcance real depende do serviço
Não há DR administrável pelo cliente no Workspace. O que existe é retenção via Google Vault e a janela de restauração de usuário excluído.
Permissões
- O Workspace é SaaS — não há replicação de infraestrutura a administrar
- A continuidade dos dados é responsabilidade do Google
- Retenção e recuperação de conteúdo ficam no Google Vault
- Restaurar usuário excluído é privilégio do Super Admin, em janela de 20 dias
- Não existe conceito de failover regional exposto ao cliente
Mitigações
- Usar Google Vault para retenção de conteúdo com valor legal
- Documentar a janela de 20 dias para restauração de usuário excluído