Documentação do Oracle Cloud Infrastructure

Acesso Break Glass para SaaS no Autonomous Database

O Autonomous Database suporta acesso de emergência para provedores SaaS. O acesso de emergência permite que uma equipe de operações do SaaS, quando explicitamente autorizada por um cliente do SaaS, acesse o banco de dados de um cliente para executar operações críticas ou de emergência.

  • Sobre o Acesso ao Break Glass no Autonomous Database
    O acesso ao Break Glass no Autonomous Database suporta provedores SaaS, em que a organização SaaS define procedimentos para permitir que um membro da equipe de operações SaaS acesse o banco de dados de um cliente quando for explicitamente autorizado pelo cliente.
  • Ativar Acesso ao Break Glass
    Depois que a autorização para acessar um banco de dados com SAAS_ADMIN for aprovada por meio de procedimentos definidos pela sua organização, use a CLI ou a API do Autonomous Database para ativar o usuário SAAS_ADMIN.
  • Desativar o Acesso ao Break Glass
    Use a CLI ou a API do Autonomous Database para desativar o acesso do usuário SAAS_ADMIN.
  • Observações sobre Acesso ao Break Glass
    Fornece observações sobre acesso ao break glass.

Tópico principal: Segurança

Sobre o Break Glass Access no Autonomous Database

O acesso de emergência no Autonomous Database suporta provedores SaaS, em que a organização SaaS define procedimentos para permitir que um membro da equipe de operações SaaS acesse o banco de dados de um cliente quando ele é explicitamente autorizado pelo cliente.

Caso de Uso de Amostra de Break Glass com Example.com

Considere um provedor SaaS chamado example.com que esteja usando o Autonomous Database para seu produto. Em operações usuais, o provedor SaaS, example.com, cria uma instância do Autonomous Database para cada cliente SaaS. Neste modelo, um cliente SaaS, por exemplo, um cliente chamado Scott, é um usuário final do produto example.com (e um cliente SaaS cujos dados são armazenados em uma instância do Autonomous Database). O provedor example.com cria e armazena todos os dados de Scott em uma instância do Autonomous Database, e o cliente, Scott, não tem acesso direto ao banco de dados.

Este modelo SaaS é resumido da seguinte forma:

  • O cliente Oracle que cria instâncias do Autonomous Database é a organização SaaS (example.com).

  • O provedor SaaS é example.com.

  • O cliente SaaS é Scott.

Se e quando algo der errado com relação ao desempenho do aplicativo, ou houver algum outro problema crítico que exija a solução de problemas pela equipe de operações SaaS, o cliente Scott poderá conceder acesso para que a equipe de operações possa acessar o banco de dados de Scott para solução de problemas. A equipe de operações SaaS só está autorizada a estabelecer acesso direto à instância do Autonomous Database de Scott por meio de um processo de aprovação definido pelo SaaS (em outras palavras, depois que example.com recebe permissão de seu cliente, Scott).

Break Glass e o Usuário SAAS_ADMIN do Autonomous Database

Quando uma SaaS chama a API de emergência na instância do Autonomous Database de um cliente, isso ativa o usuário SAAS_ADMIN. A equipe de operações SaaS pode acessar a instância usando o usuário SAAS_ADMIN com um conjunto especificado de atribuições por tempo limitado.

Por padrão, o usuário SAAS_ADMIN é bloqueado. Usando um processo de aprovação definido pela organização SaaS, o usuário SAAS_ADMIN pode ser ativado para permitir o acesso a uma instância do Autonomous Database. O nome do quebra-vidro vem de alarmes de incêndio manuais que exigem que seus usuários quebrem um pequeno painel de janela de vidro antes de ativar o alarme (o vidro deve ser quebrado para evitar que o alarme seja acionado por engano). Da mesma forma, o usuário SAAS_ADMIN normalmente não acessa o banco de dados e o acesso requer um processo de aprovação predefinido.

Dependendo do tipo de acesso concedido, quando ativado, o usuário SAAS_ADMIN pode acessar o banco de dados para investigar problemas ou fazer alterações associadas a uma emergência ou outro evento incomum. Quando o acesso de emergência expira ou quando o acesso é explicitamente desativado, a senha/segredos da conta SAAS_ADMIN são imediatamente alternados e o acesso do usuário SAAS_ADMIN é revogado. Todas as ações que o usuário SAAS_ADMIN executa são auditadas.

O usuário SAAS_ADMIN é ativado com um dos três tipos de acesso:

  • read-only: fornece acesso somente para leitura à instância. Este é o tipo de acesso padrão e inclui atribuições padrão: CREATE SESSION, SELECT ANY TABLE, SELECT ANY DICTIONARY, SELECT_CATALOG_ROLE.
  • read/write: fornece acesso de leitura/gravação à instância. As atribuições padrão para esse tipo são: CREATE SESSION, SELECT ANY TABLE, SELECT ANY DICTIONARY, SELECT_CATALOG_ROLE, INSERT ANY TABLE e UPDATE ANY TABLE.
  • admin: fornece acesso de administrador à instância. As atribuições padrão para esse tipo são: CREATE SESSION e PDB_DBA.

API de Emergência

O usuário SAAS_ADMIN só é ativado e desativado por meio da CLI (Command Line Interface) ou usando as APIs REST do Autonomous Database.

Para obter informações sobre como usar as APIs REST e assinar solicitações, consulte APIs REST e credenciais de Segurança.

Para obter informações sobre SDKs, consulte Kits de Desenvolvimento de Software e Interface de Linha de Comando.

Use estas APIs para operações Break Glass:

Ativar Acesso de Emergência

Depois que a autorização para acessar um banco de dados com SAAS_ADMIN for aprovada por meio de procedimentos definidos pela sua organização, use a CLI ou a API do Autonomous Database para ativar o usuário SAAS_ADMIN.

Você deve ter o privilégio de gerenciar o banco de dados autônomo para ativar o usuário SAAS_ADMIN.

Antes de ativar o usuário SAAS_ADMIN para acessar um banco de dados, você deve obter valores para os parâmetros necessários.

Parâmetro Descrição
isEnabled

Especifica um valor Booliano. Use TRUE para ativar.

password

Especifica a senha para o usuário SAAS_ADMIN. Se você especificar secretId, não poderá especificar password.

A senha fornecida como parâmetro deve estar de acordo com os requisitos de senha do Autonomous Database. Consulte Sobre Senhas de Usuário no Autonomous Database para obter mais informações.

secretId

Especifica o valor do OCID do segredo do Oracle Cloud Infrastructure Vault de um segredo. Se você especificar password, não poderá especificar secretId. Consulte Visão Geral do Serviço Vault para obter mais informações.

A senha fornecida como segredo no Oracle Cloud Infrastructure Vault deve estar em conformidade com os requisitos de senha do Autonomous Database. Consulte Sobre Senhas de Usuário no Autonomous Database para obter mais informações.

secretVersionNumber

Especifica o número da versão do segredo especificado com secretId. Esse parâmetro é opcional. O padrão é usar a versão de segredo mais recente. Esse parâmetro só se aplica quando secretId também é especificado.

accessType

Um dos seguintes: read-only, read/write ou admin. O padrão é read-only.

duration

Especifica a duração em horas, no intervalo de 1 hora a 24 horas. O default é 1 hora.

Para ativar o usuário SAAS_ADMIN em uma instância do Autonomous Database, defina o acesso necessário usando as instruções de política do OCI Identity and Access Management gravadas por um administrador.

A seguinte política é obrigatória:

Allow group Group_Name to manage autonomous-databases in compartment Compartment_Name

Consulte Políticas do Serviço IAM para o Autonomous Database e Conceitos Básicos de Políticas para obter mais informações.

Tópicos

Tópico principal: Acesso ao Break Glass para SaaS no Autonomous Database

Ativar Acesso ao Break Glass com uma Senha

Use a CLI ou a API do Autonomous Database para ativar SAAS_ADMIN com uma senha.

  1. Use a API ou a CLI e especifique um valor para a senha para ativar SAAS_ADMIN com um password.

    Por exemplo:

    POST https://dbaas-api.svc.ad3.us-phoenix-1/20160918/autonomousDatabases/ocid1.autonomousdatabase.oc1.phx.uniqueId/actions/configureSaasAdminUser

{  "isEnabled": true,
   "password": password,
   "accessType": "READ_ONLY",
   "duration": 17
}

    Consulte configureSaasAdminUser para obter mais informações.

  2. Verifique se o usuário SAAS_ADMIN está ativado.
    POST https://dbaas-api.svc.ad3.us-phoenix-1/20160918/autonomousDatabases/ocid1.autonomousdatabase.oc1.phx.uniqueId/actions/getSaasAdminUserStatus

{    "isEnabled": true,
     "accessType": "READ_ONLY",
     "timeSaasAdminUserEnabled": "2023-11-23T01:59:07.032Z"
}

    Essa resposta mostra que o usuário SAAS_ADMIN está ativado e que o tipo de acesso é READ_ONLY. O timestamp mostra a hora em que SAAS_ADMIN foi ativado (a hora está em UTC).

    Consulte getSaasAdminUserStatus para obter mais informações.

Tópico principal: Ativar Acesso ao Break Glass

Ativar Acesso ao Break Glass com um Segredo do Vault

Use a CLI ou a API do Autonomous Database para ativar SAAS_ADMIN com um secretId, quando o segredo for armazenado no Oracle Cloud Infrastructure Vault.

Quando você especifica um secretId, para que o Autonomous Database alcance o segredo no Oracle Cloud Infrastructure Vault, as seguintes condições devem ser aplicadas:

  • O segredo deve estar no estado current ou previous.

  • Você deve ter a política de grupo de usuários adequada que permita o acesso READ ao segredo específico em um determinado compartimento. Por exemplo: 

    Allow userGroup1 to read secret-bundles in compartment training

Para ativar SAAS_ADMIN com um secretId com o segredo armazenado no Oracle Cloud Infrastructure Vault:

  1. Use a API ou a CLI e especifique um valor de OCID para secretId.

    Por exemplo:

    POST https://dbaas-api.svc.ad3.us-phoenix-1/20160918/autonomousDatabases/ocid1.autonomousdatabase.oc1.phx.uniqueId/actions/configureSaasAdminUser

{  "isEnabled": true,
   "secretId": "ocid1.key.co1.ap-mumbai-1.example..aaaaaaaauq5ok5nq3bf2vwetkpqsoa",
   "accessType": "READ_ONLY",
   "duration": 20
}

    A especificação de uma versão de segredo é opcional. Se você especificar uma versão de segredo na chamada de API com secretVersionNumber, a versão de segredo especificada será usada. Se você não especificar uma versão de segredo, a chamada usará a versão de segredo mais recente.

    Consulte configureSaasAdminUser para obter mais informações.

  2. Verifique se o usuário SAAS_ADMIN está ativado.

    Por exemplo:

    POST https://dbaas-api.svc.ad3.us-phoenix-1/20160918/autonomousDatabases/ocid1.autonomousdatabase.oc1.phx.uniqueId/actions/getSaasAdminUserStatus

{    "isEnabled": true,
     "accessType": "READ_ONLY",
     "timeSaasAdminUserEnabled": "2023-11-23T01:59:07.032Z"
}

    Essa resposta mostra que o usuário SAAS_ADMIN está ativado e o tipo de acesso é READ_ONLY. O timestamp mostra a hora em que o usuário foi ativado (a hora está no UTC).

    Consulte getSaasAdminUserStatus para obter mais informações.

Tópico principal: Ativar Acesso ao Break Glass

Desativar Acesso de Emergência

Use a CLI ou a API do Autonomous Database para desativar o acesso do usuário SAAS_ADMIN.

Por padrão, o acesso expirará após uma hora se o parâmetro duration não for definido quando SAAS_ADMIN estiver ativado. Se o parâmetro duration for definido quando SAAS_ADMIN estiver ativado, o acesso expirará após o número especificado de horas duration. Como alternativa para permitir que o acesso expire com base no tempo de expiração padrão ou na duração especificada, você pode usar configureSaasAdminUser para desativar explicitamente o acesso do usuário SAAS_ADMIN.

Para desativar o usuário SAAS_ADMIN em uma instância do Autonomous Database, defina o acesso necessário usando as instruções de política do OCI Identity and Access Management gravadas por um administrador.

A seguinte política é obrigatória:

Allow group Group_Name to manage autonomous-databases in compartment Compartment_Name

Consulte Políticas do Serviço IAM para o Autonomous Database e Conceitos Básicos de Políticas para obter mais informações.

  1. Desative o acesso do usuário SAAS_ADMIN.

    Por exemplo:

    POST https://dbaas-api.svc.ad3.us-phoenix-1/20160918/autonomousDatabases/ocid1.autonomousdatabase.oc1.phx.uniqueId/actions/configureSaasAdminUser
{
  "isEnabled": false
}

    Consulte configureSaasAdminUser API para obter mais informações.

  2. Verifique se o usuário SAAS_ADMIN está desativado.

    Por exemplo:

    POST https://dbaas-api.svc.ad3.us-phoenix-1/20160918/autonomousDatabases/ocid1.autonomousdatabase.oc1.phx.uniqueId/actions/getSaasAdminUserStatus

{    "isEnabled": false
}

    Essa resposta indica que o usuário SAAS_ADMIN está desativado.

    Consulte getSaasAdminUserStatus para obter mais informações.

Quando você desativa o usuário SAAS_ADMIN, o acesso ao banco de dados é revogado e o Autonomous Database rotaciona a senha ou o segredo usado para acessar o banco de dados.

Observações para Acesso de Emergência

Fornece notas para acesso de vidro de quebra.

Notas para acesso de vidro de ruptura:

  • O duration especificado quando você ativa SAAS_ADMIN se aplica até que o tempo especificado expire ou até que você desative explicitamente o usuário SAAS_ADMIN. Não é possível alterar esse valor depois de ativar o usuário SAAS_ADMIN.

  • O Autonomous Database Always Free não suporta o acesso com o usuário SAAS_ADMIN.

  • A view DBA_CLOUD_CONFIG fornece informações sobre o usuário SAAS_ADMIN.

    Por exemplo, use a seguinte consulta para obter informações sobre o status do usuário SAAS_ADMIN: 

    SELECT PARAM_VALUE FROM DBA_CLOUD_CONFIG WHERE
             param_name ='saas_admin_access' order by 1;

    A presença de um valor para auth_revoker significa que o acesso foi revogado e mostra o usuário que revogou o acesso.

    O auth_end mostra uma hora planned. Depois que a autorização for revogada, se a autorização expirar no final do duration especificado quando o usuário SAAS_ADMIN foi ativado, o horário planned será igual ao horário actual. Se o horário planned e actual forem diferentes, isso significa que a autorização SAAS_ADMIN foi revogada antes de o duration expirar.

    Por exemplo, se SAAS_ADMIN estiver ativado com uma duração de 2 horas e, após 1 hora, o acesso for desativado chamando a API configureSaasAdminUser para desativar o usuário SAAS_ADMIN, as vezes auth_end planned e actual serão diferentes.

    Se essa consulta não mostrar linhas, o usuário SAAS_ADMIN não existirá. Ele pode ter sido criado e abandonado ou nunca foi criado.