Documentação do Oracle Cloud Infrastructure

Replicando Vaults e Chaves

Replique vaults e chaves para cenários de recuperação de desastres. A replicação ajuda na leitura de chaves em um vault de outra região dentro do mesmo realm.

Você pode replicar vaults de uma região para outra para torná-los e as chaves que eles contêm disponíveis na região remota. A replicação de vaults fornece os seguintes benefícios:

  • Recuperação de Desastres Aprimorada: A replicação de chaves entre regiões garante a acessibilidade dos dados e a recuperação mais rápida em caso de interrupções regionais.
  • Proteção de Dados: Manter proteções redundantes de cópias de chaves contra perda acidental ou acesso não autorizado.
  • Conformidade e Residência de Dados: Para setores regulamentados e organizações com requisitos específicos de residência de dados, a replicação garante a conformidade com as leis relevantes.
Observação

Consulte Replicando Segredos para obter informações sobre como replicar segredos entre regiões.

Como a replicação funciona

Quando você configura a replicação entre regiões para um vault, o serviço sincroniza automaticamente a criação, a exclusão, a atualização ou a movimentação de quaisquer chaves ou versões de chave entre um vault especificado e uma réplica desse vault em outra região. O vault do qual o serviço replica dados é conhecido como vault de origem. O vault na região de destino para o qual o serviço replica dados do vault de origem é conhecido como réplica do vault.

O vault mantém a segurança do FIPS 140-2 Nível 3 durante a replicação regional, e as chaves são exportadas como objetos binários criptografados e restauradas apenas nos módulos de segurança de hardware (HSMs) FIPS 140-2 Nível 3 fornecidos pela Oracle em sua tenancy. As chaves nunca deixam o HSM em texto simples. As operações de inicialização e exclusão de replicação são registradas nos logs do OCI Audit.

Gerenciamento do Vault de Origem e Réplica

O serviço suporta o uso da réplica do vault para operações criptográficas. Não é possível executar operações de gerenciamento diretamente na réplica do vault e suas chaves. Por exemplo, você não pode criar chaves diretamente na réplica do vault, nem pode fazer backup dela. Você pode encontrar o ponto final criptográfico da réplica do vault exibindo os detalhes da réplica do vault e pode usar esse ponto final quando necessário.

Para interromper a replicação de um vault de origem, exclua a réplica do vault na região de destino. Como apenas uma réplica de vault pode existir para um vault de origem a qualquer momento, você deve excluir uma réplica de vault existente para replicar o vault de origem em outra região de destino.

Tempo de Recuperação e Ponto de Recuperação Durante Failover

O RTO (Recovery Time Objective) é o tempo máximo em que os aplicativos podem ficar indisponíveis durante um failover para a região de destino. O RTO é quase zero em um estado estacionário, porque cada chave criada na região de origem é imediatamente replicada para a região de destino. O atraso é principalmente da latência de rede entre regiões e medido em milissegundos. Portanto, os aplicativos podem fazer failover para a região de destino e acessar chaves quase instantaneamente.

O RPO (Recovery Point Objective) é a quantidade máxima de dados que podem ser perdidos na região de origem durante um failover. O RPO para chaves de vault replicadas é zero, porque o KMS não confirma que uma operação de replicação seja bem-sucedida até que uma chave seja confirmada com o armazenamento persistente do HSM, ajudando a garantir que não haja perda de dados.

Observação

O OCI KMS suporta dois tipos de ofertas de vault:

  • Vault virtual: Um serviço multitenant econômico para gerenciar chaves.
  • Vault privado: um serviço de tenant único que fornece isolamento e segurança aprimorados.

Observe as seguintes limitações e considerações:

  • Os vaults virtuais criados antes da introdução do recurso de replicação de vault entre regiões não podem ser replicados entre regiões. No entanto, todos os vaults privados suportam replicação entre regiões. Você pode usar o parâmetro isVaultReplicable da API GetVault para descobrir se um vault virtual suporta replicação entre regiões. Crie um novo vault e novas chaves se você tiver um vault que precise replicar em outra região e a replicação não for suportada para esse vault. As chaves existentes não podem ser copiadas para um novo vault.

    Se você tiver um vault que não suporte replicação entre regiões, o botão Replicar Vault na página de detalhes do vault será desativado.

  • Por padrão, os vaults privados têm um limite de zero; portanto, você deve solicitar um aumento do limite de serviço na região de destino na qual deseja replicar um vault privado antes de criar uma réplica de vault.

Política Obrigatória do Serviço IAM

Para usar o Oracle Cloud Infrastructure, um administrador deve ser membro de um grupo ao qual foi concedido acesso de segurança em uma política por um administrador da tenancy. Esse acesso será necessário se você estiver usando a Console ou a API REST com um SDK, uma CLI ou outra ferramenta. Se você receber uma mensagem informando que não tem permissão ou está não autorizado, verifique com o administrador da tenancy qual tipo de acesso você tem e qual compartimento seu acesso funciona.

Para administradores: para uma política típica que dá acesso a vaults, chaves e segredos, consulte Permitir que os administradores de segurança gerenciem vaults, chaves e segredos. Além das políticas para usuários e grupos, você também deve criar uma política que dê ao serviço Vault a capacidade de fazer tudo com vaults para que ele possa criar e gerenciar vaults em seu nome durante a replicação. Por exemplo, a política a seguir dá permissão ao serviço em todas as regiões do realm:

Allow service keymanagementservice to manage vaults in tenancy

Para restringir permissões a compartimentos específicos, especifique o compartimento. Para obter mais informações sobre permissões, ou se você precisar gravar políticas mais restritivas, consulte Detalhes do Serviço Vault.

Se você for iniciante em políticas, consulte Gerenciando Domínios de Identidades e Políticas Comuns.