Notas para Usar Chaves Gerenciadas pelo Cliente com o Autonomous Database
Fornece informações e observações adicionais para usar chaves gerenciadas pelo cliente com o Autonomous Database
- Cuidado com as Chaves de Criptografia Gerenciadas pelo Cliente quando a Chave estiver Inacessível
Depois de alternar para chaves gerenciadas pelo cliente, algumas operações do banco de dados poderão ser afetadas quando a chave estiver inacessível. - Cuidado ao Usar Chaves de criptografia gerenciadas pelo cliente quando a chave principal for desativada ou excluída
Depois que você alternar para chaves gerenciadas pelo cliente, algumas operações do banco de dados poderão ser afetadas se a chave principal for desativada ou excluída. - Cuidado com o Uso de Backups e Histórico de Chaves de Criptografia Gerenciadas pelo Cliente
Depois de alternar para chaves gerenciadas pelo cliente, algumas operações do banco de dados poderão ser afetadas se a chave principal for rotacionada, desativada ou excluída e você não tiver uma chave válida para restaurar seus dados de um backup salvo anteriormente ou de um clone. - Observações sobre Chaves Gerenciadas pelo Cliente no OCI Vault com o Autonomous Data Guard
O Autonomous Data Guard é suportado ao usar chaves gerenciadas pelo cliente com o provedor de chaves Oracle Cloud Infrastructure Vault. - Observações sobre Chaves de Criptografia Gerenciadas pelo Cliente com Clones Atualizáveis
Lista limitações e observações para o uso de chaves gerenciadas pelo cliente com clones atualizáveis. - Observações sobre Chaves Gerenciadas pelo Cliente com o Vault na Tenancy Remota
Para usar chaves de criptografia principais gerenciadas pelo cliente com um Vault em uma tenancy remota, observe o seguinte:
Tópico principal: Gerenciar Chaves de criptografia no Autonomous Database
Cuidado com as Chaves de Criptografia Gerenciadas pelo Cliente quando a Chave estiver Inacessível
Depois de alternar para chaves gerenciadas pelo cliente, algumas operações do banco de dados poderão ser afetadas quando a chave está inacessível.
Se o banco de dados não puder acessar sua chave por algum motivo, como uma interrupção de rede, o Autonomous Database tratará a interrupção da seguinte forma:
-
Há um período de tolerância de 2 horas em que o banco de dados permanece em funcionamento.
-
Se a chave não estiver acessível no final do período de tolerância de 2 horas, o estado do Ciclo de Vida do banco de dados será definido como Inacessível. Nesse estado, as conexões existentes são eliminadas e novas conexões não são permitidas.
-
Se o Autonomous Data Guard estiver ativado ao usar o Oracle Cloud Infrastructure Vault, durante ou após o período de tolerância de 2 horas, você poderá tentar executar manualmente uma operação de failover. O failover automático do Autonomous Data Guard não é acionado quando você está usando chaves de criptografia gerenciadas pelo cliente e o Oracle Cloud Infrastructure Vault está inacessível.
Observação
Somente o Oracle Cloud Infrastructure Vault é suportado com o Autonomous Data Guard. -
Se o Autonomous Database for interrompido, você não poderá iniciar o banco de dados quando as chaves estiverem inacessíveis.
Para esse caso, a solicitação de serviço mostrada quando você clica na guia Solicitações de serviço na página de detalhes do Autonomous Database na Console do Oracle Cloud Infrastructure mostra:
The Vault service is not accessible. Your Autonomous Database could not be started. Please contact Oracle Support.
cuidado ao usar chaves de criptografia gerenciadas pelo cliente quando a chave principal for desativada ou excluída
Depois que você alternar para chaves gerenciadas pelo cliente, algumas operações do banco de dados poderão ser afetadas se a chave principal estiver desativada ou for excluída.
-
Para desativar/excluir operações de chave em que o Estado da Chave de Criptografia Principal é qualquer um dos seguintes:
Vault Principal Status da Chave Vault do Oracle Cloud Infrastructure (OCI) DISABLING
DISABLED
DELETING
DELETED
SCHEDULING_DELETION
PENDING_DELETION
Sistema de Gerenciamento de Chaves da AWS (KMS) Disabled
PendingDeletion
Vault Principal do Azure DISABLED
DELETED
Oracle Key Vault (OKV) COMPROMISED
DEACTIVATED
DESTROYED
O banco de dados se torna Inacessível depois que o estado do Ciclo de Vida da chave entra em um desses estados. Quando a chave está em qualquer um desses estados, o Autonomous Database elimina as conexões existentes e não permite novas conexões.
O banco de dados que se torna inacessível pode levar até 15 minutos após as principais operações (o Autonomous Database verifica o provedor de chaves em intervalos de 15 minutos).
-
Se você desativar ou excluir a chave do Oracle Cloud Infrastructure Vault usada pelo Autonomous Database enquanto o Autonomous Data Guard estiver ativado, o Autonomous Data Guard não executará um failover automático.
Observação
Somente o Oracle Cloud Infrastructure Vault é suportado com o Autonomous Data Guard. -
Se você ativar uma chave desativada, o banco de dados entrará automaticamente no estado Disponível.
-
Se você excluir a chave principal, verifique o histórico da chave na Console do Oracle Cloud Infrastructure para localizar as chaves que foram usadas para o banco de dados. O histórico mostra o nome da chave, juntamente com um timestamp de ativação. Se uma das chaves mais antigas da lista do histórico ainda estiver disponível, você poderá restaurar o banco de dados até o momento em que ele estava usando essa chave ou poderá clonar de um backup para criar um novo banco de dados com esse timestamp.
Consulte Exibir Histórico de Chaves de Criptografia Gerenciadas pelo Cliente no Autonomous Database para obter mais informações.
cuidado ao usar o histórico e backups de chaves de criptografia gerenciadas pelo cliente
Depois de alternar para chaves gerenciadas pelo cliente, algumas operações do banco de dados poderão ser afetadas se a chave principal for rotacionada, desativada ou excluída e você não tiver uma chave válida para restaurar seus dados de um backup salvo anteriormente ou de um clone.
-
É recomendável criar uma nova chave que não seja usada para rotação nos últimos 60 dias e usá-la para rotação. Certifique-se de que você possa voltar a um backup se a chave atual for excluída ou desativada.
-
Quando você executa várias rotações de chave de criptografia em 60 dias, é recomendável criar uma nova chave para cada operação de rotação de chave de criptografia principal ou especificar uma chave que não tenha sido usada nos últimos 60 dias. Isso ajuda a salvar pelo menos uma chave que você pode usar para recuperar seus dados de um backup, no caso de uma chave de criptografia principal gerenciada pelo cliente ser desativada ou excluída.
Consulte Exibir Histórico de Chaves de Criptografia Gerenciadas pelo Cliente no Autonomous Database para obter mais informações.
Observações sobre Chaves Gerenciadas pelo Cliente no OCI Vault com o Autonomous Data Guard
O Autonomous Data Guard é suportado ao usar chaves gerenciadas pelo cliente com o provedor de chaves Oracle Cloud Infrastructure Vault.
Ao usar chaves gerenciadas pela Oracle, você só pode alternar para chaves gerenciadas pelo cliente do banco de dados principal. Da mesma forma, ao usar chaves gerenciadas pelo cliente, você só pode rotacionar chaves ou alternar para chaves gerenciadas pela Oracle do banco de dados principal. A opção Gerenciar chave de criptografia em Mais ações está desativada em um banco de dados stand-by.
Observe o seguinte quando você está usando o Autonomous Data Guard com um banco de dados stand-by com chaves gerenciadas pelo cliente:
-
Para que um stand-by remoto use a mesma chave de criptografia principal que o principal, a chave de criptografia principal deve ser replicada para a região remota.
Só há suporte para Chaves de Criptografia Gerenciadas pelo Cliente com um único stand-by do Autonomous Data Guard entre regiões. Não há suporte para vários standbys entre regiões porque o Oracle Cloud Infrastructure Vault só suporta replicação para uma região remota.
-
O banco de dados principal e o banco de dados standby usam a mesma chave. No caso de um switchover ou failover para o stand-by, você poderá continuar a usar a mesma chave.
-
Quando você rotaciona a chave gerenciada pelo cliente no banco de dados principal, isso se reflete no banco de dados stand-by.
-
Quando você muda de chaves gerenciadas pelo cliente para chaves gerenciadas pela Oracle, a alteração é refletida no banco de dados stand-by.
-
Quando o Oracle Cloud Infrastructure Vault está inacessível, há um período de tolerância de 2 horas antes que o banco de dados entre no estado
INACCESSIBLE
. Você pode executar um failover durante ou após esse período de cortesia de 2 horas. -
Se você desativar ou excluir a chave de criptografia principal do Oracle Cloud Infrastructure que seu Autonomous Database está usando com chaves gerenciadas pelo cliente enquanto o Autonomous Data Guard estiver ativado, o Autonomous Data Guard não executará um failover automático.
-
Não há suporte para Chaves de Criptografia Gerenciadas pelo Cliente com o Autonomous Data Guard entre Tenancies.
Para obter mais informações, consulte:
Observações sobre Chaves de Criptografia Gerenciadas pelo Cliente com Clones Atualizáveis
Lista limitações e observações para usar chaves gerenciadas pelo cliente com clones atualizáveis.
A opção de usar chaves gerenciadas pelo cliente com um clone atualizável só está disponível quando o banco de dados de origem usa o modelo de computação ECPU.
Mesmo Clone Atualizável da Região com Origem Usando Observações das Chaves de Criptografia Gerenciadas pelo Cliente
O Autonomous Database suporta o uso de chaves de criptografia gerenciadas pelo cliente com um clone atualizável na mesma região, da seguinte forma:
-
Quando o banco de dados de origem usa chaves gerenciadas pelo cliente, você pode criar um ou mais clones atualizáveis locais (mesma região). Os clones atualizáveis usam as mesmas chaves gerenciadas pelo cliente que o banco de dados de origem e não suportam a opção de selecionar uma chave diferente de forma independente ou alterar o tipo de chave em clones atualizáveis.
-
Todos os provedores de chaves gerenciados pelo cliente suportados são suportados para um mesmo clone atualizável de região, incluindo: Oracle Cloud Infrastructure Vault, Microsoft Azure Key Vault, Amazon Web Services (AWS) Key Management Service (KMS) e Oracle Key Vault (OKV).
Consulte Sobre o Gerenciamento Principal de Chaves de Criptografia no Autonomous Database para obter mais informações.
-
Você pode alterar o tipo de chave ou girar a chave no banco de dados de origem quando o banco de dados de origem tiver um ou mais clones atualizáveis locais. Nesse caso, depois que o banco de dados de origem é alternado para outro tipo de chave ou sua chave é alternada, um clone atualizável continua usando a chave antiga existente. Depois que um clone atualizável é atualizado, o clone atualizável é alternado para usar o novo tipo de chave de origem ou para usar a chave girada.
-
Ao provisionar um clone atualizável de uma origem usando uma chave gerenciada pelo cliente, os grupos dinâmicos e as políticas devem abranger o clone atualizável para que o clone atualizável também possa acessar a chave. Se os grupos dinâmicos e as políticas não incluírem o clone atualizável, o provisionamento falhará. Da mesma forma, se a origem já tiver um clone atualizável e estiver alternando de chaves gerenciadas pela Oracle para chaves gerenciadas pelo cliente, o switch não será bem-sucedido se os grupos dinâmicos e as políticas não incluírem o clone atualizável.
Consulte Pré-requisitos para Criar um Clone Atualizável para obter mais informações.
Consulte Create a Refreshable Clone for an Autonomous Database Instance para obter mais informações.
Clone Atualizável entre Regiões com Origem Usando Notas de Chaves de Criptografia Gerenciadas pelo Cliente
O Autonomous Database suporta o uso de chaves de criptografia gerenciadas pelo cliente com um clone atualizável entre regiões, da seguinte forma:
-
Quando o banco de dados de origem usa chaves gerenciadas pelo cliente, você pode criar um clone atualizável entre regiões. O clone atualizável usa as mesmas chaves gerenciadas pelo cliente que o banco de dados de origem e não oferece suporte à opção de selecionar uma chave diferente de forma independente ou alterar o tipo de chave no clone atualizável.
Nesse caso, só há suporte para o OCI Vault no clone atualizável entre regiões e a chave da origem deve ser replicada na região remota.
-
O provedor de chaves gerenciado pelo cliente suportado com um clone atualizável entre regiões é: Oracle Cloud Infrastructure Vault.
Consulte Sobre o Gerenciamento Principal de Chaves de Criptografia no Autonomous Database para obter mais informações.
-
Quando um clone atualizável entre regiões usa uma chave gerenciada pelo cliente, os grupos dinâmicos e as políticas devem abranger o clone atualizável. Se os grupos dinâmicos e as políticas não incluírem o clone atualizável, o provisionamento falhará. Da mesma forma, se a origem já tiver um clone atualizável e estiver alternando de chaves gerenciadas pela Oracle para chaves gerenciadas pelo cliente, o switch não será bem-sucedido se os grupos dinâmicos e as políticas não incluírem o clone atualizável.
Consulte Pré-requisitos para Criar um Clone Atualizável para obter mais informações.
Consulte Criar uma Tenancy Cruzada ou um Clone Atualizável entre Regiões para obter mais informações.
Clone Atualizável entre Tenancies com Origem Usando Observações de Chaves de Criptografia Gerenciadas pelo Cliente
O Autonomous Database não suporta a utilização de chaves de criptografia gerenciadas pelo cliente com um clone atualizável entre tenancies.
Consulte Criar uma Tenancy Cruzada ou um Clone Atualizável entre Regiões para obter mais informações.
Restaurar Banco de Dados de Origem com um Clone Atualizável Usando Observações das Chaves de Criptografia Gerenciadas pelo Cliente
Se um banco de dados de origem tiver um clone atualizável e o banco de dados de origem for restaurado com base em backups, o banco de dados de origem começará a usar a chave que estava em uso no momento em que o banco de dados de origem foi restaurado.
Nesse caso, considere os seguintes casos:
-
Se o clone atualizável estava em atraso e seu ponto de atualização era anterior ao ponto de restauração, o que significa que o clone atualizável tinha dados anteriores ao banco de dados de origem restaurado, ele começará a usar a mesma chave do banco de dados de origem após a próxima atualização (uma atualização recria o clone atualizável do banco de dados de origem).
-
Se o ponto de atualização do clone atualizável for posterior ao ponto de restauração, o que significa que o clone atualizável tinha dados mais recentes do que o banco de dados de origem restaurado, o clone atualizável será automaticamente recriado quando atingir o mesmo ponto no tempo com atualizações. Nesse momento, deve começar a mostrar a mesma chave que a origem.
Consulte Restaurar e Recuperar seu Autonomous Database para obter mais informações.
Clone Atualizável Desconectado Usando Observações das Chaves de Criptografia Gerenciadas pelo Cliente
Se um clone atualizável com um banco de dados de origem usando chaves gerenciadas pelo cliente for desconectado, o clone atualizável poderá se reconectar ao banco de dados de origem. Se, enquanto o clone atualizável estiver desconectado da origem, a chave no banco de dados de origem for alterada, o clone atualizável será alternado para usar a nova chave quando o clone atualizável for reconectado e atualizado.
Observações para Chaves Gerenciadas pelo Cliente com o Vault na Tenancy Remota
Para usar chaves de criptografia principais gerenciadas pelo cliente com um Vault em uma tenancy remota, observe o seguinte:
Quando você usa chaves de criptografia principais gerenciadas pelo cliente com um Vault em uma tenancy remota, o Vault e a instância do Autonomous Database devem estar na mesma região. Para alterar a tenancy, na página de sign-on, clique em Alterar tenancy. Depois de alterar a tenancy, certifique-se de selecionar a mesma região para a instância do Vault e do Autonomous Database.