Recursos de Segurança no Autonomous AI Database na Dedicated Exadata Infrastructure
Este artigo descreve os principais recursos de segurança no Autonomous AI 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.
Junto com os recursos de segurança padrão do Oracle AI Database, como análise de privilégios, criptografia de rede, usuários gerenciados centralmente, atribuições de aplicações seguras, proteção de dados confidenciais transparente e outros, um Autonomous AI 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 de um Autonomous AI Database Dedicado descritos abaixo.
Dica:
Na imagem a seguir, você pode clicar no recurso que deseja explorar mais.Figura - Principais Recursos de Segurança
Gerenciamento de Configurações
Criado no Oracle Cloud Infrastructure, o Autonomous AI Database oferece configurações padrão de segurança reforçadas, para que você e sua equipe não precisem gastar grandes quantidades de tempo e dinheiro gerenciando configurações em sua frota do Autonomous AI Database. Todas as contas de serviço, como SYS e System, são rotacionadas a cada 90 dias. Consulte Gerenciamento de Configuração no Autonomous AI Database para explorar 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 altamente confidenciais e dados de brechas e vulnerabilidades de segurança dispendiosas e possivelmente desastrosas. Consulte Manutenção de Serviço do Autonomous AI Database Dedicado para obter mais detalhes.
Criptografia de Dados
O Autonomous AI 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 AI Database usa criptografia ininterrupta que protege os dados inativos 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 AI Database Dedicado para obter mais detalhes sobre criptografia de dados e chaves de criptografia mestras.
Auditing
O Oracle Autonomous AI Database on Dedicated Exadata Infrastructure oferece recursos robustos 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 Recursos de Auditoria no Autonomous AI Database Dedicado para obter mais detalhes.
Controle de Acesso
Ao configurar o recurso Dedicated Exadata Infrastructure, você precisa garantir que seus usuários de nuvem tenham acesso para usar e criar somente os tipos apropriados de recursos de nuvem para executar suas tarefas de job. Além disso, você precisa garantir que apenas o pessoal e os aplicativos autorizados tenham acesso ao Autonomous AI Database criado na 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 AI Database Dedicado para obter mais detalhes.
Gerenciamento de Certificado
Quando um cliente tenta se conectar a um Autonomous AI Database por meio de um serviço de conexão de banco de dados TCPS (TCP Seguro), o Oracle Autonomous AI 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 AI Database 23ai ou em versões posteriores. 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 AI Database usa certificados autoassinados. Um certificado autoassinado é um certificado de segurança que é gerado pelo sistema.
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.
Os certificados autoassinados são gerados e associados a um AVMC automaticamente. No entanto, faça download da wallet do cliente do Autonomous AI 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.
- 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).
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.
Em 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 AI Database que você baixou 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 servidor assinado pela CA com seus Autonomous AI Databases.
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.
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.
- 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.
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
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 AI Database relacionadas a este Cluster da VM 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 AI Database em uma Infraestrutura Dedicada do Exadata para obter uma lista abrangente de eventos do Autonomous AI 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 Oracle Database Vault vem pré-configurado e pronto para uso em Autonomous AI Databases. 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 AI Database Vault trata predominantemente das seguintes questões de segurança do 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 AI 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 insiders para acessar dados confidenciais de aplicativos. Consulte How Oracle AI Database Vault Protects Privileged User Accounts no Oracle Database 19c Administrator's Guide ou no Oracle Database 26ai Administrator's Guide para obter mais detalhes.
-
Separação de funções para acesso a dados de aplicativos: os controles de separação de funções do Oracle AI Database Vault podem ser personalizados e as organizações com recursos limitados podem atribuir várias responsabilidades do Oracle AI Database Vault ao mesmo administrador, mas usar contas separadas para cada atribuição de separação de funções para minimizar os danos ao banco de dados se qualquer conta for roubada e aproveitada. Consulte How Oracle AI Database Vault Addresses Database Consolidation Concerns no Oracle Database 19c Administrator's Guide ou no Oracle Database 26ai Administrator's Guide para obter mais detalhes.
Antes de usar o Database Vault, revise What to Expect After You Enable Oracle AI Database Vault no Oracle Database 19c Administrator's Guide ou no Oracle Database 26ai 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 Autonomous AI Database, consulte Usar o Oracle AI Database Vault para Gerenciar Privilégios de Usuário do Banco de Dados.Dica:
Para testar o processo de configuração do Database Vault, execute o Laboratório 1: Protect Data With Database Vault no Workshop do Oracle Autonomous AI Database Dedicated for Security Administrators. -
- O PAM também é usado para ajudar a proteger os dados para uso autorizado pelo cliente e para ajudar a proteger os 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 as contas de usuário que as operações do Oracle Cloud e os funcionários de suporte usam para monitorar e analisar o desempenho não podem acessar dados no Autonomous AI Databases. Consulte Gerenciamento de Acesso Privilegiado para obter mais informações.
Descoberta de Dados Sensíveis e Mascaramento de Dados
-
Oracle Autonomous AI Database on Dedicated Exadata Infrastructure suporta integração com serviço Oracle Data Safe para ajudá-lo a avaliar e proteger seus bancos de dados. O Oracle Data Safe ajuda você a entender a sensibilidade de seus dados, avaliar riscos para dados, mascarar dados confidenciais, implementar e monitorar controlos de segurança, avaliar segurança no usuário, monitorar atividades do usuário e tratar os requisitos para conformidade com segurança 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 usar o Oracle Data Safe para identificar e proteger dados confidenciais e regulamentados do seu Autonomous AI Database, você deve registrar seu banco de dados no Data Safe. Depois de registrar seu banco de dados no Data Safe, você pode ir para a console do Data Safe diretamente na página Detalhes do seu Autonomous AI Database. Para obter mais informações sobre como registrar seu banco de dados, consulte Registrar ou Cancelar Registro de um Autonomous AI Database Dedicado no Data Safe.
-
-
Quando uma consulta emitida por um aplicativo em tempo de execução 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 26ai PL/SQL Packages and Types Reference.
Certificação de Conformidade Regulatória
O Autonomous AI 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.