Recursos de Segurança no Autonomous Database on Dedicated Exadata Infrastructure

Este artigo descreve os principais recursos de segurança no Autonomous Database on Dedicated Exadata Infrastructure.

Observe que, ao longo desta seção, o termo "você" é amplamente usado para significar qualquer administrador em sua organização que tenha a responsabilidade de executar determinadas tarefas. Em alguns casos, esse é o administrador da frota, em outros é o administrador do banco de dados.

Juntamente com os recursos de segurança padrão do Oracle Database, como análise de privilégio, criptografia de rede, usuários gerenciados centralmente, atribuições de aplicativos seguros, proteção de dados confidenciais transparente etc., o Autonomous Database dedicado adiciona Database Vault, Data Safe e outros recursos de segurança avançados sem custo adicional.

Você pode ver os blocos de construção dos principais recursos de segurança do Autonomous Database dedicado descritos abaixo.

Dica:

Na imagem a seguir, você pode clicar no recurso que deseja explorar mais.

Figura - Principais Recursos de Segurança



Descrição da "Figura - Principais Recursos de Segurança"

Tópicos Relacionados

Gerenciamento de Configurações

Desenvolvido com base no Oracle Cloud Infrastructure, o Autonomous Database fornece configurações de segurança padrão e reforçadas para que você e sua equipe não precisem gastar grandes quantidades de tempo e dinheiro gerenciando configurações em toda a sua frota de bancos de dados autônomos. Todas as contas de serviço, como SYS e System, são rotacionadas a cada 90 dias. Consulte Gerenciamento de Configuração no Autonomous Database para explorar ainda mais.

Os patches e atualizações de segurança são feitos automaticamente, portanto você não precisa se preocupar em manter a segurança atualizada. Esses recursos protegem seus bancos de dados e dados altamente confidenciais de vulnerabilidades e violações de segurança caras e potencialmente desastrosas. Consulte Manutenção de Serviços do Autonomous Database Dedicado para obter mais detalhes.

Criptografia de Dados

O Autonomous Database armazena todos os dados em formato criptografado no Oracle Database. Somente usuários e aplicativos autenticados podem acessar os dados quando se conectam ao banco de dados.

O Autonomous Database usa criptografia sempre ativa que protege os dados em armazenamento e em trânsito. Por padrão, todos os dados armazenados e a comunicação de rede com o Oracle Cloud são criptografados. A criptografia não pode ser desativada.

Consulte Criptografia de Dados no Autonomous Database Dedicado para obter mais detalhes sobre criptografia de dados e chaves de criptografia principais.

Auditing

O Oracle Autonomous Database on Dedicated Exadata Infrastructure fornece recursos avançados de auditoria que permitem rastrear quem fez o quê no serviço e em bancos de dados específicos. Dados de log abrangentes permitem auditar e monitorar ações nos seus recursos, o que ajuda a atender aos seus requisitos de auditoria e a reduzir os riscos operacionais e de segurança.

Consulte Auditando Recursos no Autonomous Database Dedicado para obter mais detalhes.

Controle de Acesso

Ao configurar o recurso de infraestrutura dedicada do Exadata, você precisa garantir que seus usuários da nuvem tenham acesso para usar e criar apenas os tipos apropriados de recursos de nuvem para executar suas tarefas. Além disso, você precisa garantir que somente pessoas e aplicativos autorizados tenham acesso aos bancos de dados autônomos criados em uma infraestrutura dedicada. Caso contrário, você corre o risco de consumo "sem controle" de seus recursos da infraestrutura dedicada ou de acesso inadequado a dados de missão crítica.

A proteção do acesso aos seus dados e aos bancos de dados que os contêm compreende vários tipos diferentes de controle de acesso. Consulte Controle de Acesso no Autonomous Database Dedicado para obter mais detalhes.

Gerenciamento de Certificado

Quando um cliente tenta estabelecer conexão com um Autonomous Database por meio do serviço TCPS (TCP Seguro), o Oracle Autonomous Database on Dedicated Exadata Infrastructure usa a autenticação baseada em certificado TLS 1.2 e TLS 1.3 padrão para autenticar a conexão. No entanto, o TLS 1.3 só é suportado no Oracle Database 23ai ou em uma versão posterior. Independentemente de o cliente ter tentado se conectar por meio do serviço TCPS ou de conexão do banco do dados TCP, o acesso do cliente ao banco do dados é restrito pelos direitos de acesso do usuário do banco para o qual o cliente usa para se conectar.

Certificado Autoassinado Gerenciado pela Oracle

Por padrão, o Autonomous Database usa certificados auto assinados. Um certificado autoassinado é um certificado de segurança gerado pelo sistema.

Geração de certificados

Os certificados autoassinados gerenciados pela Oracle são gerados automaticamente durante o provisionamento de um Cluster de VMs do Autonomous Exadata (AVMC) e se aplicam a todos os bancos de dados criados nesse AVMC.

Gerenciamento de certificados

Os certificados autoassinados são gerados e associados a um AVMC automaticamente. No entanto, faça download da wallet do cliente do Autonomous Database antes de estabelecer conexão com seus bancos de dados. Com certificados autoassinados, a conexão com bancos de dados sem uma wallet não é uma opção. Consulte Fazer Download das Credenciais do Cliente para obter instruções sobre como fazer download de uma wallet para seu banco de dados.

Dependendo do requisito, um dos seguintes tipos de certificado está associado ao seu AVMC:
  • Certificado SSL do banco de dados: Certificado SSL para conexões de cliente do banco de dados.
  • Certificado SSL do ORDS: Certificado SSL para aplicativos do Application Express (APEX).
Rotação do certificado

Para atender às necessidades de conformidade de segurança da sua organização, você pode alternar os certificados autoassinados gerenciados pela Oracle usando a console ou a API do Oracle Cloud Infrastructure (OCI). Consulte Gerenciar Certificados de Segurança para um Recurso de Cluster de VMs do Autonomous Exadata para obter instruções passo a passo. Isso é chamado de rotação do certificado.

Para recursos recém-provisionados do Cluster de VMs do Autonomous Exadata (AVMC), os certificados autoassinados gerenciados pela Oracle têm uma validade de 13 meses a partir de sua criação. A rotação de um certificado SSL usando a console ou a API rotaciona os certificados do servidor e do cliente e redefine sua validade para 13 meses. Quando um certificado do lado do servidor ou do cliente gerenciado pela Oracle não é rotacionado antes de sua expiração, a Oracle os rotaciona automaticamente e gera novas wallets.

No caso de certificados SSL do banco de dados, a rotação do certificado não invalida o certificado existente imediatamente.

Dentro de duas semanas a partir da rotação do certificado, você pode estabelecer conexão com seus bancos de dados usando a wallet do cliente do Autonomous Database que você fez download antes ou depois da rotação do certificado.

Após duas semanas da rotação do certificado:

  • A wallet do banco de dados download feito antes da rotação do certificado é invalidada e não pode ser usada para estabelecer conexão com seus bancos de dados.
  • A wallet do banco de dados download feito em duas semanas da rotação do certificado permanece ativa e pode ser usada para estabelecer conexão com seus bancos de dados.
  • Qualquer nova wallet de banco de dados baixada após duas semanas da rotação do certificado pode ser usada para estabelecer conexão com seus bancos de dados.

Vamos discutir isso com um exemplo:

Considere que um certificado SSL, digamos C1, está prestes a expirar e você rotacionou esse certificado em 1o de fevereiro. Por duas semanas a partir de 1o de fevereiro, que até 14 de fevereiro, o certificado antigo (C1) ainda está disponível para uso. Você pode continuar usando o certificado antigo (C1) ou fazer download de uma nova wallet de banco de dados para o certificado rotacionado (C2) para suas conexões de banco de dados. Após duas semanas a partir de 1o de fevereiro, ou seja, a partir de 14 de fevereiro, o certificado antigo (C1) é invalidado e não pode ser usado para conexões de banco de dados. Você pode continuar usando a wallet do banco de dados que fez download após a rotação do certificado (C2) durante essas duas semanas. Você também pode fazer download de uma nova wallet de banco de dados e começar a usá-la para suas conexões de banco de dados após duas semanas da rotação.

Você também pode alternar um certificado SSL de banco de dados dentro de duas semanas a partir de sua rotação mais recente. Nesse cenário, o certificado antigo (sobre ser invalidado devido à primeira rotação) é desativado imediatamente. O próximo certificado (resultando da primeira rotação) permanece ativo, e um terceiro certificado (resultando da segunda rotação) aguardará a ativação por duas semanas a partir da segunda rotação. Qualquer wallet de banco de dados baixada antes da primeira rotação ser invalidada logo após a segunda rotação. Você pode continuar estabelecendo conexão com o banco de dados com qualquer wallet de banco de dados baixada após a primeira rotação até duas semanas a partir da segunda rotação. Após a conclusão de duas semanas a partir da segunda rotação, você só poderá estabelecer conexão com seus bancos de dados usando uma wallet do cliente baixada após a segunda rotação, ou seja, uma wallet que foi baixada dentro de duas semanas a partir da segunda rotação ou mais tarde.

No exemplo acima, se você girar o mesmo certificado (C1) novamente dentro de duas semanas a partir de 1o de fevereiro, o certificado passará por rotação dupla. Nesse caso, o certificado antigo (certificado antes da primeira rotação, ou seja, C1) é invalidado imediatamente. O certificado resultante da primeira rotação (C2) permanece ativo e um terceiro certificado resultante da segunda rotação, digamos C3, aguardará a ativação por duas semanas a partir da segunda rotação. Após duas semanas da segunda rotação, o certificado resultante da primeira rotação (C2) também é invalidado e qualquer wallet de banco de dados baixada antes da segunda rotação não pode ser usada para conexões de banco de dados. Você pode continuar usando a wallet do banco de dados que fez download após a rotação do certificado (C3) durante essas duas semanas. Você também pode fazer download de uma nova wallet de banco de dados e começar a usá-la para suas conexões de banco de dados após duas semanas da segunda rotação.

No caso de certificados SSL ORDS, todas as conexões de aplicativos existentes serão perdidas com a rotação do certificado e você deverá reiniciar o ORDS. O período de buffer de duas semanas discutido acima não se aplica quando você rotaciona um certificado SSL do ORDS.

Traga seu próprio certificado (BYOC)

O BYOC (Bring Your Own Certificate) permite que você use seu certificado do lado do servidor assinado pela CA com seus Autonomous Databases.

Geração de certificados

Para trazer seu próprio certificado, primeiro crie o certificado usando o Serviço de Certificado do Oracle Cloud Infrastructure (OCI), conforme demonstrado em Criando um Certificado. Esses certificados devem ser assinados e estar no formato PEM, ou seja, sua extensão de arquivo deve ser somente .pem, .cer ou .crt.

Instalação do certificado

Depois de criar o certificado do servidor assinado pela CA, você deverá instalá-lo com o AVMC para que todos os bancos de dados criados nele possam usar esse certificado para conexões seguras. A associação do seu certificado BYOC com um AVMC é facilitada na caixa de diálogo Gerenciar Certificados na console do OCI. Nessa caixa de diálogo, escolha na lista de seleção Traga seu próprio certificado e selecione o certificado que você teria criado anteriormente. Opcionalmente, você também pode especificar um certificado de CA com autoridade de certificação e bundle de CAs. Consulte Gerenciar Certificados de Segurança para um Recurso de Cluster de VMs do Autonomous Exadata para obter instruções passo a passo.

Gerenciamento de certificados
Você pode estabelecer conexão com Autonomous Databases associados a um servidor assinado pela CA com ou sem uma wallet do cliente do Autonomous Database.
  • Para estabelecer conexão com seu banco de dados usando uma wallet de banco de dados, primeiro faça download das credenciais do cliente na página Detalhes do banco de dados usando a console do OCI. Consulte Fazer Download das Credenciais do Cliente para obter instruções.
  • Para estabelecer conexão com seu banco de dados sem uma wallet do cliente, você deve garantir que:
    • Conexões TLS unidirecionais são ativadas no nível AVMC. Esta é uma definição definida usando o parâmetro Listener em Opções avançadas ao provisionar o AVMC. Consulte Criar um Cluster de VMs Autonomous Exadata para obter orientação.
    • O certificado do lado do servidor assinado pela CA é assinado por uma CA pública conhecida para que seja confiável pelo sistema operacional do cliente por padrão.
Rotação do certificado

Para atender às necessidades de conformidade de segurança da sua organização, você pode rotacionar os certificados do lado do servidor assinados pela CA usando a console ou a API do Oracle Cloud Infrastructure (OCI). Consulte Gerenciar Certificados de Segurança para um Recurso de Cluster de VMs do Autonomous Exadata para obter instruções passo a passo.

Você deve rotacioná-los antes da data de expiração, caso contrário, os bancos de dados neste AVMC não estarão acessíveis nas portas TLS até que você forneça um certificado válido. No entanto, você pode continuar a acessar os bancos de dados em uma porta não TLS, como a 1521.

Eventos de Certificado

Os seguintes eventos são publicados para gerenciamento de certificados de segurança:
Evento Gerado quando
sslcertificateexpiry.reminder Um Cluster de VMs do Autonomous Exadata determina que uma wallet deve expirar em menos de seis (6) semanas. Este evento é reportado no máximo uma vez por semana. Este evento é acionado quando há uma conexão que usa a wallet que está prestes a expirar.
sslcertificate.expired O Certificado SSL expira. Todas as wallets do Autonomous Database relacionadas a este Cluster de VMs do Autonomous Exadata expirarão.
sslcertificaterotation.reminder Um certificado SSL tem mais de 365 dias e recomenda que o cliente alterne o certificado. Depois que um certificado SSL ultrapassar 365 dias, esse lembrete será exibido uma vez por semana até que seja alternado.
sslcertificate.rotated O certificado SSL é rotacionado manualmente (usando a console ou a API do Oracle Cloud Infrastructure) ou automaticamente na expiração.

Dica:

Inscreva-se nesses eventos usando o OCI Notifications Service para recebê-los sempre que forem publicados. Consulte Criando uma Assinatura para obter mais detalhes.

Consulte Eventos do Autonomous Database na Infraestrutura Dedicada do Exadata para obter uma lista abrangente de eventos do Autonomous Database.

Proteção de Dados

A proteção de dados é um aspecto crítico da segurança de dados em qualquer banco de dados. Contas de banco de dados privilegiadas são um dos caminhos mais usados para obter acesso a dados de aplicativos confidenciais no banco de dados. Embora usuários privilegiados, como operadores ADMIN ou Oracle, precisem de acesso amplo e irrestrito para facilitar a manutenção do banco de dados, o mesmo acesso também cria um ponto de ataque para obter acesso a grandes quantidades de dados.

O Autonomous Database permite implementar o PAM (Privileged Access Management) usando:

  • O Oracle Database Vault vem pré-configurado e pronto para ser usado no Autonomous Database. Você pode usar seus controles de segurança avançados para restringir o acesso a dados de aplicativos por usuários privilegiados de banco de dados, reduzindo o risco de ameaças internas e externas e tratando-se de requisitos comuns de conformidade.

    Você pode implantar controles para bloquear o acesso da conta privilegiada aos dados do aplicativo e controlar operações confidenciais dentro do banco de dados. Você pode configurar caminhos confiáveis para adicionar controles de segurança extras ao acesso autorizado a dados e alterações de banco de dados. Por meio da análise de run-time de privilégios e atribuições, você pode aumentar a segurança de aplicativos existentes implementando o mínimo de privilégios e reduzindo o perfil de ataque das suas contas de banco de dados. O Database Vault protege os ambientes de banco de dados existentes de forma transparente, eliminando alterações caras e demoradas nos aplicativos.

    O Oracle Database Vault aborda predominantemente as seguintes questões de segurança de banco de dados:

    • Acesso de conta privilegiada administrativa aos dados do aplicativo: Embora o administrador do banco de dados seja o usuário mais avançado e confiável, esse administrador não precisa acessar os dados do aplicativo que residem no banco de dados.

      Os realms do Oracle Database Vault em torno de esquemas de aplicativos, tabelas confidenciais e procedimentos armazenados fornecem controles para evitar que contas privilegiadas sejam exploradas por intrusos e internos para acessar dados confidenciais de aplicativos. Consulte How Oracle Database Vault Protects Privileged User Accounts no Oracle Database 19c Administrator's Guide ou no Oracle Database 23ai Administrator's Guide para obter mais detalhes.

    • Separação de obrigações para acesso a dados de aplicativos: a separação de controles de obrigações do Oracle Database Vault pode ser personalizada e as organizações com recursos limitados podem atribuir várias responsabilidades do Oracle Database Vault ao mesmo administrador, mas usando contas separadas para cada atribuição de separação de obrigações para minimizar os danos ao banco de dados se uma conta for roubada e aproveitada. Consulte How Oracle Database Vault Addresses Database Consolidation Concerns no Oracle Database 19c Administrator's Guide ou Oracle Database 23ai Administrator's Guide para obter mais detalhes.

    Antes de usar o Database Vault, consulte What to Expect After You Enable Oracle Database Vault no Oracle Database 19c Administrator's Guide ou no Oracle Database 23ai Administrator's Guide para entender o impacto da configuração e ativação do Database Vault.

    Para obter informações sobre como configurar e ativar o Database Vault no seu banco de dados autônomo, consulte Usar o Oracle Database Vault para Gerenciar Privilégios de Usuário do Banco de Dados.

    Dica:

    Para testar o processo de configuração do Database Vault, confira o Lab 1: Protect Data With Database Vault no Oracle Autonomous Database Dedicated for Security Administrators Workshop.
  • O PAM também é usado para ajudar a proteger dados para uso autorizado pelo cliente e para ajudar a proteger dados contra acesso não autorizado, o que inclui impedir o acesso aos dados do cliente pelo Oracle Cloud Operations e pelos membros da equipe de suporte. O Oracle Operations Access Control garante que as contas de usuário que a equipe de operações e suporte do Oracle Cloud usa para monitorar e analisar o desempenho não podem acessar dados em Autonomous Databases. Consulte Gerenciamento de Acesso Privilegiado para obter mais informações.

Descoberta de Dados Sensíveis e Mascaramento de Dados

Identificar dados confidenciais (como número do cartão de crédito, SSN) e mascará-los ou ocultá-los conforme necessário aumenta a proteção de dados e a segurança geral dos dados.

  • O Oracle Autonomous Database on Dedicated Exadata Infrastructure suporta a integração com o serviço Oracle Data Safe para ajudar você a avaliar e proteger seu banco de dados. O Oracle Data Safe ajuda você a entender a confidencialidade dos seus dados, avaliar riscos a dados, mascarar dados confidenciais, implementar e monitorar controles de segurança, avaliar a segurança do usuário, monitorar a atividade do usuário e tratar dos requisitos de conformidade com a segurança dos dados em seus bancos de dados.

    Ele oferece o seguinte conjunto de recursos em uma única console de gerenciamento fácil de usar:

    • A avaliação de Segurança ajuda você a avaliar a segurança da configuração do seu banco de dados.

    • A Avaliação do Usuário ajuda você a avaliar a segurança dos usuários do seu banco de dados e a identificar usuários de alto risco.

    • A Descoberta de Dados ajuda você a localizar dados confidenciais no seu banco de dados. O Mascaramento de Dados oferece uma forma de mascarar dados confidenciais para que eles fiquem seguros para fins de não produção.

    • A auditoria de Atividades permite auditar a atividade do usuário em seu banco de dados de forma que você possa monitorar o uso do banco de dados e ser alertado de atividades de banco de dados incomuns.

    Para obter mais informações sobre o uso do Data Safe, consulte Visão Geral do Oracle Data Safe em Usando o Oracle Data Safe.

    Para usar o Oracle Data Safe para identificar e proteger dados confidenciais e regulamentados do seu Autonomous Database, registre o seu banco de dados no serviço Data Safe. Depois de registrar seu banco de dados no serviço Data Safe, você poderá ir para a console do serviço Data Safe diretamente da página Detalhes do Autonomous Database. Para obter mais informações sobre como registrar seu banco de dados, consulte Registrar ou Cancelar o Registro de um Banco de Dados Dedicado no Data Safe.

  • Quando uma consulta emitida por um aplicativo no runtime retorna um conjunto de resultados com informações confidenciais, como números de cartão de crédito ou IDs pessoais, o Oracle Data Redaction pode ajudá-lo a mascarar os detalhes confidenciais antes de retornar o conjunto de resultados ao aplicativo. Você pode implementar políticas para redação de dados usando o Pacote PL/SQL DBMS_REDACT . Consulte DBMS_REDACT em Oracle Database 19c PL/SQL Packages and Types Reference ou Oracle Database 23ai PL/SQL Packages and Types Reference.

Certificação de Conformidade Regulatória

O Autonomous Database on Dedicated Exadata Infrastructure atende a um amplo conjunto de padrões de conformidade internacionais e específicos do setor, incluindo:

  • FedRAMP High — Programa Federal de Gerenciamento de Riscos e Autorizações (somente Regiões do Setor Governamental dos EUA)
  • HIPAA — Health Insurance Portability and Accountability Act
  • ISO/IEC 27001:2013 — Organização Internacional para Padronização 27001
  • ISO/IEC 27017:2015 — Código de Prática para Controles de Segurança de Informações Baseados na ISO/IEC 27002 para Serviços de Nuvem
  • ISO/IEC 27018:2014 — Código de Prática para Proteção de Informações de Identificação Pessoal (PII) em Nuvens Públicas que Atuam como Processadores de PII
  • PCI DSS — O Payment Card Industry Data Security Standard é um conjunto de requisitos destinados a garantir que todas as empresas que processam, armazenam ou transmitem informações de cartão de crédito mantenham um ambiente seguro.
  • SOC 1 — Controles de Sistema e Organização 1
  • SOC 2 — Controles de Sistema e Organização 2

Para obter mais informações e uma lista completa de certificações, consulte Conformidade do Oracle Cloud.