O Exadata Cloud Infrastructure é gerenciado em conjunto pelo cliente e pela Oracle e está dividido em duas áreas de responsabilidade.

Os clientes controlam e monitoram o acesso aos serviços do cliente, incluindo o acesso da rede a suas VMs (por meio de Redes Virtuais na Nuvem do OCI e Listas de Segurança do OCI), autenticação para acessar a VM e autenticação para acessar bancos de dados em execução nas VMs. A Oracle controla e monitora o acesso aos componentes de Infraestrutura Gerenciada pela Oracle e à segurança do servidor físico. A equipe da Oracle não está autorizada a acessar os serviços do cliente, incluindo as VMs e os bancos de dados do cliente, exceto nos casos em que os clientes não conseguirem acessar suas respectivas VMs.

Os clientes acessam os Bancos de Dados (DB) Oracle em execução no Exadata Cloud Infrastructure por meio de VCNs de clientes e de backup para os bancos de dados em execução na VM do cliente usando métodos de conexão de banco de dados Oracle padrão, como o Oracle Net, na porta 1521. O acesso do cliente à VM que executa os bancos de dados Oracle por meio de métodos Oracle Linux padrão, como ssh baseado em token na porta 22.

Recursos consecutivos oferecidos pelo Exadata Cloud Infrastructure.

• Segurança Física do Oracle Cloud

  Os data centers do Oracle Cloud são alinhados com os padrões TIA (Uptime Institute and Telecommunications Industry Association) ANSI/TIA-942-A Nível 3 (99.982% de Disponibilidade) ou Nível 4 (99.995% de Disponibilidade) e seguem uma metodologia de redundância N2 ('N' significa Necessidade) para a operação de equipamentos críticos. Os data centers que hospedam serviços do Oracle Cloud Infrastructure usam fontes de energia redundantes e mantêm geradores como backup em caso de falha generalizada na rede elétrica. As salas de servidor são rigorosamente monitoradas em relação à umidade e à temperatura do ar. Também é verificada a existência de sistemas de supressão de incêndio. A equipe do data center é treinada nos procedimentos de escalonamento e de resposta a incidentes para atender a eventos de segurança e de disponibilidade que possam surgir. Para obter mais informações, consulte o: Guia de Segurança do Oracle Cloud Infrastructure. Para obter mais detalhes sobre a conformidade do Data Center do Oracle Cloud Infrastructure, consulte Oracle Cloud Compliance. Consulte também: Práticas de Segurança Corporativa da Oracle: Segurança de Dados: Controles Físicos e Ambientais.

• Controles de Acesso ao Oracle Data Center

  Para fornecer sistemas seguros, os protocolos de acesso da Oracle aos data centers físicos incluem o seguinte:

  • O acesso físico às instalações para data centers é limitado a funcionários, contratados e visitantes autorizados da Oracle.
  • Funcionários, subcontratados e visitantes autorizados da Oracle recebem cartões de identificação que devem ser usados nas instalações da Oracle.
  • Os visitantes precisam assinar o registro de um visitante, ser acompanhados e/ou observados quando estiverem nas instalações da Oracle e/ou estar vinculados aos termos de um contrato de confidencialidade com a Oracle.
  • A segurança monitora a posse de chaves/placas de acesso e monitora a capacidade de acessar as instalações. Os funcionários que deixarem o emprego da Oracle deverão devolver as chaves/os cartões, e estes serão desativados após o desligamento.
  • A segurança autoriza todos os reparos e modificações nas barreiras de segurança física ou controles de entrada nos locais de serviço.
  • A Oracle usa uma mistura de administradores de segurança no local 24 horas por dia, 7 dias por semana ou agentes de patrulha, dependendo do nível de risco/proteção da instalação. Em todos os casos, os agentes são responsáveis por patrolas, resposta de alarme e registro de incidentes de segurança.
  • A Oracle implementou sistemas de controle de acesso eletrônico gerenciados centralmente com capacidade integrada de alarme de intrusão. Os logs de acesso são mantidos por um mínimo de seis meses. Além disso, o período de retenção de monitoramento e gravação por câmeras varia entre 30 e 90 dias no mínimo, dependendo das funções e do nível de risco da instalação.

  Para obter mais detalhes sobre os controles de acesso ao site da Oracle, consulte: Práticas de Segurança Corporativa da Oracle: Oracle Access Control

• Isolamento do Cliente do Hipervisor

  O hipervisor é o software que gerencia dispositivos virtuais em um ambiente de nuvem, manipulando a virtualização de servidor e de rede. Em ambientes de virtualização tradicionais, o hipervisor gerencia o tráfego de rede, permitindo que ele flua entre instâncias de VM e entre instâncias de VM e hosts físicos. Isso adiciona uma complexidade considerável e uma sobrecarga computacional no hipervisor. Os ataques à segurança do computador de prova de conceito, como ataques de escape de máquina virtual, destacaram o risco substancial que pode vir com esse design. Esses ataques exploram a complexidade do hipervisor permitindo que um invasor "quebra" de uma instância de VM, acesse o sistema operacional subjacente e obtenha controle do hipervisor. O invasor poderá acessar outros hosts às vezes sem detecção. O Oracle Cloud Infrastructure reduz esse risco, separando a virtualização de rede do hipervisor.

  Para lidar com possíveis ataques, a Oracle implementou uma arquitetura de segurança em primeiro lugar usando a virtualização de rede isolada, que é um elemento fundamental da arquitetura da infraestrutura da Oracle Cloud. Essa arquitetura interrompe o malware em seus trilhos com um SmartNIC personalizado para isolar e virtualizar a rede. A virtualização de rede isolada reduz o risco, limitando a superfície de ataque. Mesmo que um ator malicioso tenha sucesso com um ataque de escape de VM em um único host, a arquitetura virtual foi projetada para que o ator não possa acessar outros hosts na infraestrutura de nuvem. O ataque está efetivamente contido em um host. A arquitetura de virtualização de rede isolada segura é implementada em cada data center em cada região. Cada locatário da Oracle Cloud Infrastructure recebe os benefícios dessa arquitetura de segurança em primeiro lugar.

  Figura 6-1 A Virtualização de Rede Isolada Reduz o Risco na Nuvem de 2ª Geração da Oracle

  
  Descrição de "Figura 6-1 Virualização de Rede Isolada Reduz Riscos no Oracle Generation 2 Cloud"
• Segurança Multitenant

  Consistente com nossa filosofia de segurança de Ampla Defesa, o Multitenant tem uma arquitetura de isolamento abrangente.

  Existem quatro categorias principais para isso, com vários recursos importantes em cada categoria.

  1. Mecanismo de Controle de Acesso
  2. Impedir o Acesso de Administrador Não Autorizado
  3. Proteger do acesso direto aos Arquivos de Dados
  4. Isolamento do Recurso
  e

  Figura 6-2 Arquitetura de Isolamento Abrangente do Multitenant

  
  Descrição de "Figura 6-2 Arquitetura de isolamento abrangente do multilocatário"

• Ampla Defesa O Exadata Cloud Infrastructure oferece uma série de controles para garantir confidencialidade, integridade e disponibilidade em todo o serviço.

  Em primeiro lugar, o Exadata Cloud Infrastructure é criado com base na imagem protegida do sistema operacional que o Exadata Database Machine fornece (https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmsq/exadata-security-overview.html). Isso protege o ambiente operacional principal, restringindo a imagem de instalação apenas aos pacotes de software necessários, desativando serviços desnecessários e implementando parâmetros de configuração seguros em todo o sistema.

  Além de herdar toda a força da plataforma madura do Exadata Database Machine, como o Exadata Cloud Infrastructure provisiona os sistemas para os clientes, opções adicionais de configuração padrão seguras são implementadas nas instâncias de serviço. Por exemplo, todos os tablespaces de banco de dados exigem criptografia transparente de dados (TDE), imposição de senha forte para usuários iniciais e superusuários do banco de dados e regras aprimoradas de auditoria e evento.

  O Exadata Cloud Infrastructure também constitui uma implantação e um serviço completos; por isso, ele é submetido a auditorias externas padrão do setor, como PCI, HIPPA e ISO27001. Esses requisitos de auditoria externa impõem recursos adicionais de serviço de valor agregado, como verificação de vírus, alerta automatizado para alterações inesperadas no sistema e verificações diárias de vulnerabilidade em todos os sistemas de infraestrutura gerenciada pela Oracle na frota.

• Privilégio mínimo

  Os Padrões de Codificação Segura da Oracle exigem que os processos de software sejam executados no nível mínimo de privilégios para implementar sua funcionalidade.

  Cada processo e daemon devem ser executados como usuário normal e sem privilégios, a menos que possa provar um requisito para um nível mais alto de privilégio. Isso ajuda a conter qualquer problema ou vulnerabilidade imprevisto no espaço de usuário sem privilégios e a não comprometer todo o sistema.

  Esse princípio também se aplica aos membros das equipes de operações da Oracle que usam contas nomeadas individuais para acessar o Exadata Cloud Infrastructure para manutenção ou solução de problemas. Somente quando necessário, eles usarão o acesso auditado a níveis mais altos de privilégio para resolver um problema. A maioria dos problemas é resolvida por meio da automação. Por isso, também empregamos o privilégio mínimo, não permitindo que operadores humanos acessem um sistema, a menos que a automação não o resolva.

• Auditoria e responsabilidade

  Quando necessário, o acesso ao sistema é permitido, mas todos os acessos e ações são registrados e rastreados para prestação de contas.

  Os logs de auditoria do Exadata Cloud Infrastructure são controlados pela Oracle e usados para fins de monitoramento de segurança e conformidade. A Oracle pode compartilhar logs de auditoria relevantes com clientes de acordo com as Práticas de Resposta a Incidentes da Oracle e o Oracle Data Processing Agreement.

  Os recursos de auditoria são fornecidos em todos os componentes da infraestrutura para garantir que todas as ações sejam capturadas. Os clientes também podem configurar a auditoria de seus bancos de dados e VMs convidadas e podem optar por integrá-los com outros sistemas de auditoria da empresa.

• Automatizando as operações na nuvem

  Eliminando as operações manuais exigidas para provisionar, aplicar patch, manter, solucionar problemas e configurar sistemas, a oportunidade de erro é reduzida.

• Imagem protegida do sistema operacional

  • Instalação de pacote mínimo:

    Somente os pacotes necessários para executar um sistema eficiente são instalados. Ao instalar um conjunto menor de pacotes, a superfície de ataque do sistema operacional é reduzida e o sistema permanece mais seguro.

  • Configuração segura:

    Muitos parâmetros de configuração não padrão são definidos durante a instalação para aprimorar a postura de segurança do sistema e de seu conteúdo. Por exemplo, o SSH é configurado para detectar apenas determinadas interfaces de rede, o sendmail é configurado para só aceitar conexões de host local e muitas outras restrições semelhantes são implementadas durante a instalação.

  • Execute apenas os serviços necessários:

    Todos os serviços que podem ser instalados no sistema, mas não são necessários para a operação normal por padrão, são desativados. Por exemplo, embora o NFS seja um serviço frequentemente configurado pelos clientes para vários fins de aplicativo, ele é desativado por padrão, pois não é necessário nas operações normais do banco de dados. Os clientes podem optar por configurar os serviços de acordo com suas necessidades.

• Superfície de ataque minimizada

  Como parte da imagem protegida, a superfície de ataque é reduzida ao instalar e executar apenas o software necessário para fornecer o serviço.

• Recursos de segurança adicionais ativados (senhas do grub, inicialização segura)

  • Aproveitando os recursos de imagem do Exadata, o ExaDB-D utiliza os recursos integrados na imagem base, como senhas do grub e inicialização segura, além de muitos outros.
  • Por meio da personalização, os clientes poderão aprimorar ainda mais sua postura de segurança com configurações adicionais.
• Métodos de acesso seguro
  • Acessar servidores de banco de dados via SSH usando cifragens criptográficas fortes. As cifragens fracas são desativadas por padrão.
  • Acessar bancos de dados por meio de conexões do Oracle Net criptografadas. Por padrão, nossos serviços estão disponíveis com o uso de canais criptografados e um cliente Oracle Net configurado padrão usará sessões criptografadas.
  • Acessar diagnósticos via interface Web (https) do Exadata MS.
• Auditoria e registro em log
  • Por padrão, a auditoria é ativada para operações administrativas e os registros de auditoria são comunicados aos sistemas internos do OCI para revisão automatizada e alerta quando necessário.

Várias contas de usuário gerenciam regularmente os componentes do Exadata Cloud Infrastructure. Esses usuários são obrigatórios e não podem ser modificados.

Em todas as máquinas do ExaDB-D, a Oracle usa e recomenda o log-in via SSH baseado em token.

Há três classes de usuários:

• Usuários Padrão: Nenhum Privilégio de Log-on
  
• Usuários Padrão COM Acesso a SHELL RESTRITO
  Esses usuários são utilizados para realizar uma tarefa definida com um log-in de shell restrito. Esses usuários não devem ser removidos porque a tarefa definida falhará caso eles sejam excluídos.
• Usuários Padrão com Permissões de Log-in
  Esses usuários privilegiados são utilizados para realizar a maioria das tarefas do sistema. Eles nunca devem ser alterados ou excluídos uma vez que isso teria impacto significativo no sistema em execução.

Além de todos os recursos do Exadata explicados em Recursos de Segurança do Oracle Exadata Database Machine, as definições de segurança a seguir também são aplicáveis às instâncias do Exadata Cloud Infrastructure.

• Implantação personalizada de banco de dados com parâmetros não padrão.
  O comando host_access_control deve configurar as definições de segurança do Exadata:

  • Implementando políticas de complexidade e validade de senhas.
  • Definindo políticas de timeout de sessão e bloqueio de conta.
  • Restringindo o acesso raiz remoto.
  • Restringindo o acesso da rede a determinadas contas.
  • Implementando banner de advertência de log-in.
• account-disable: Desativa uma conta de usuário quando determinadas condições configuradas são atendidas.
• pam-auth: Várias definições de PAM para alterações e autenticação de senha.
• rootssh: Ajusta o valor PermitRootLogin em /etc/ssh/sshd_config, que permite ou nega que o usuário root faça log-in por meio do SSH.
  • Por padrão, PermitRootLogin é definido como no.
  • PermitRootLogin=without-password é obrigatório para que a automação da nuvem execute algumas operações de gerenciamento do ciclo de vida. A desativação do log-in raiz causará falha na funcionalidade do serviço.
• session-limit: Define o parâmetro * hard maxlogins em /etc/security/limits.conf, que é o número máximo de logins para todos os usuários. Esse limite não se aplica a um usuário com uid=0.

  O padrão é * hard maxlogins 10, sendo este o valor seguro recomendado.

• ssh-macs: Especifica os algoritmos MAC (Message Authentication Code) disponíveis.
  • O algoritmo MAC é usado no protocolo versão 2 para proteção de integridade de dados.
  • O padrão é hmac-sha1, hmac-sha2-256, hmac-sha2-512 para servidor e cliente.
  • Valores recomendados seguros: hmac-sha2-256, hmac-sha2-512 para servidor e cliente.
• password-aging: Define ou exibe o vencimento da senha atual para contas de usuário interativo.
  • -M: Número máximo de dias que uma senha pode ser usada.
  • -m: Número mínimo de dias permitido entre alterações de senha.
  • -W: Número de dias em que a advertência é fornecida antes de uma senha expirar.
  • O padrão é -M 99999, -m 0, -W 7
  • --strict_compliance_only-M 60, -m 1, -W 7
  • Valores recomendados seguros: -M 60, -m 1, -W 7

Uma lista dos processos executados por padrão na VM do cliente, também chamada DOMU, ou na VM Convidada e no sistema operacional Convidado

• Agente da VM do Exadata Cloud Infrastructure:

  Agente da nuvem para tratar as operações do ciclo de vida do banco de dados.

  • É executado como usuário opc
  • A tabela de processos mostra a execução como processo Java com nomes jar - dbcs-agent-VersionNumber-SNAPSHOT.jar e dbcs-admin-VersionNumver-SNAPSHOT.jar.
• Agente do Oracle Trace File Analyzer:

  O Oracle Trace File Analyzer (TFA) fornece várias ferramentas de diagnóstico em um único pacote, facilitando reunir informações de diagnóstico sobre o banco de dados e o clusterware da Oracle, que por sua vez ajuda a resolver problemas ao tratar com o Suporte Técnico da Oracle

  • É executado como usuário root
  • É executado como daemon de inicialização (/etc/init.d/init.tfa)
  • As tabelas de processos mostram um aplicativo Java (oracle.rat.tfa.TFAMain)
  • É executado como usuários root e exawatch.
  • É executado como script backgroud, ExaWatcher.sh e todo o seu processo secundário executado como processo Perl.
  • A tabela de processos é mostrada como vários aplicativos Perl.ExaWatcher:
• Banco de Dados e GI (clusterware):
  • Executado como usuários dbmsvc e grid
  • A tabela de processos mostra os seguintes aplicativos:
    • oraagent.bin, apx_* e ams_* como usuário grid
    • Aplicativos dbrsMain e Java - derbyclient.jar, weblogic.Server como usuário oracle.
• Servidor de Gerenciamento (MS):

  Parte do software de imagem do Exadata para gerenciar e monitorar as funções de imagem.

  • É executado como dbmadmin.
  • A tabela de processos mostra a execução como processo Java.

• Segurança da Rede da VM Convidada
  
• Requisitos de Conformidade
  

Recursos de segurança de banco de dados padrão ativados e usados:

• A TDE (Transparent Database Encryption) é usada para tablespaces de banco de dados criados pelas ferramentas do Oracle Database Cloud.
  • CDB$ROOT: o tablespace dos usuários é criptografado
  • PDBs: todos os tablespaces criptografados
  • A senha da wallet é fornecida durante a criação inicial do banco de dados. As senhas da wallet podem ser alteradas usando dbaascli. Os clientes devem alterar essa senha periodicamente.
• Usuários no banco de dados
  • Nenhum usuário adicional é criado no banco de dados.
  • Após a criação do banco de dados, todos os usuários do banco de dados são bloqueados, exceto SYS, SYSTEM e DBSNMP.
  • A auditoria é ativada para as seguintes operações:
    • DATABASE LINK
    • PUBLIC DATABASE LINK
    • PUBLIC SYNONYM
    • DROP ANY PROCEDURE
    • PROCEDURE
    • ALTER SYSTEM
    • TRIGGER
    • CREATE DATABASE LINK
    • ALTER DATABASE LINK
    • CREATE PROCEDURE
    • ALTER SYSTEM
    • CREATE TRIGGER
    • CREATE ANY TRIGGER
    • SELECT ANY DICTIONARY
    • BD VERSION_11_2: EXEMPT REDACTION POLICY
    • DB VERSION_12_1 ou DB VERSION_12_2: BECOME USER
    • BD VERSION_12_1: SESSION
    • O perfil DBAASSECURE é criado e definido como perfil padrão para a conta de usuário do banco de dados.

• Criptografia nativa do SQL*Net para todas as conexões de rede - Os parâmetros sqlnet.ora relevantes definidos no Exadata Cloud Infrastructure por padrão são:

  • SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)

  • SQLNET.ENCRYPTION_SERVER = requested

  • SQLNET.CRYPTO_CHECKSUM_SERVER = accepted

  • SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)

• Protocolo TCPS oferecido para conexão de rede com o banco de dados na porta 2484 (wallet configurado em /var/opt/oracle/dbaas_acfs/grid/tcps_wallets). Os parâmetros sqlnet.ora relevantes definidos no Exadata Cloud Infrastructure por padrão são:

  • SSL_CIPHER_SUITES = (SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
    SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
    SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 
    SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384)

  • WALLET_LOCATION = (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets)))

  • SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS = TRUE

  • SSL_VERSION = 1.2

• Registro de listener remoto - os listeners são executados no home do GI. O Exadata Cloud Infrastructure implanta a versão do Grid Infrastructure especificada no Documento 2333222.1 (Versões do Software Exadata Cloud Service) do Suporte Técnico da Oracle. A configuração padrão do Exadata Cloud Infrastructure inclui o parâmetro listener.ora VALID_NODE_CHECKING_REGISTRATION_LISTENER=SUBNET combinado com REMOTE_REGISTRATION_ADDRESS_<SCANLISTENER>=<value> para restringir os registros de listener remotos para fins de segurança.
• Integração do OCI Vault - A chave de criptografia de TDE pode ser armazenada no OCI Vault (um Sistema de Gerenciamento de Chaves). Para obter mais informações e instruções para configurar principais, vaults etc., consulte Chaves Gerenciadas pelo Cliente no Exadata Cloud Infrastructure. Os tipos de vault privado e compartilhado são suportados para a integração do OCI Vault do Exadata Cloud Infrastructure. A autenticação do usuário do banco de dados não é integrada ao OCI Vault.

Backups de sistema operacional/VM:

A Oracle faz um backup completo da VM convidada semanalmente e mantém uma ou mais cópias de backup. Esses backups são snapshots de disco completos da VM convidada (sistemas de arquivos locais do sistema operacional, não grupos de discos do ASM que residem no armazenamento do Exadata). Esse backup é acionado em um horário predefinido toda semana. Os backups são armazenados localmente no dom0. Os clientes podem solicitar à Oracle que restaure a imagem de VM convidada do backup mais recente registrando uma Solicitação de Serviço (SR) no MOS (My Oracle Support). A Oracle não pode restaurar arquivos específicos do backup de imagem. Os clientes deverão executar backups em nível de arquivo na VM convidada se precisarem da capacidade de fazer a restauração de um único arquivo.

Backups de bancos de dados gerenciados:

• Backup completo semanal (nível 0)
• Backup incremental diário (nível 1) em um ciclo de sete dias
• Backup automático diário em um horário específico definido durante o processo de criação da implantação do banco de dados

O período de retenção para backups varia de 30 dias (no Object Storage) a 7 dias (no armazenamento local)

Criptografia:

• Object Storage e armazenamento local: Todos os backups no armazenamento na nuvem são criptografados.
• Somente Object Storage: Todos os backups no armazenamento na nuvem são criptografados.

Todos os backups podem ser configurados por meio da IU do CP ou da API do CP.

Todos os backups são criptografados com a mesma chave principal usada para criptografia de wallet de TDE (Criptografia Transparente de Dados).

Somente o conjunto de ferramentas automatizado tem permissão para acessar a VM convidada para fins de automação do ciclo de vida.

Um caso de uso específico é quando a VM convidada não pode ser inicializada. Nesse caso, os clientes devem fornecer permissão para acessar a VM convidada para fins de recuperação. Os detalhes para tratar esse cenário estão descritos na seção "Exception Workflows" do documento Exadata Cloud Service Security Controls.

Os clientes controlam e monitoram o acesso aos serviços do cliente, incluindo o acesso da rede a suas VMs convidadas (por meio de VLANs e firewalls de camada 2 implementados na VM convidada), autenticação para acessar a VM convidada e bancos de dados em execução nas VMs convidadas. A Oracle controla e monitora o acesso aos componentes de infraestrutura gerenciados pela Oracle. A equipe da Oracle não está autorizada a acessar os serviços do cliente, incluindo VMs convidadas e bancos de dados.

PII (Informações de Identificação Pessoal) Essas informações são consideradas confidenciais e sigilosas e devem ser protegidas para evitar o uso não autorizado das informações pessoais para fins de regulamentação legal, responsabilidade financeira e reputação pessoal.

Você deve configurar um conjunto de regras explícitas para impedir que as Informações de Identificação Pessoal (PII) sejam exibidas em seus dados.

As regras padrão do serviço Application Performance Monitoring ocultam PII em URLs, reconhecendo valores monetários, números de conta bancária e datas. No entanto, as regras padrão só capturam PII óbvias e não são detalhadas. Você deve avaliar as regras padrão e configurar mais regras para garantir a geração correta de relatórios no seu ambiente e garantir que PII não sejam exibidas em seus dados.

Para obter mais informações, consulte Ocultar Informações de Identificação Pessoal e Informações de Segurança e Identificação Pessoal

Retenção de Backup

Quando você ativa o recurso Backup Automático, ele cria backups incrementais diários do banco de dados no Object Storage. O primeiro backup criado é um backup de nível 0. Depois, os backups de nível 1 são criados todos os dias até o próximo fim de semana. Todo fim de semana, o ciclo é repetido, começando com um novo backup de nível 0.

Se você optar por ativar backups automáticos, poderá escolher um dos seguintes períodos de retenção predefinidos: 7 dias, 15 dias, 30 dias, 45 dias ou 60 dias. O sistema exclui automaticamente seus backups incrementais no fim do período de retenção escolhido.

Para obter mais informações, consulte Gerenciar Backup e Recuperação de Banco de Dados no Oracle Exadata Database Service on Dedicated Infrastructure

Período de Retenção do Log de Auditoria

O serviço OCI Audit fornece registros de operações de API executadas em serviços suportados como uma lista de eventos de log. Por padrão, os registros do serviço Audit são mantidos por 365 dias.

Para obter mais informações, consulte Período de Retenção do Log de Auditoria

Retenção de Log de Serviço

Serviços do Oracle Cloud Infrastructure, como API Gateway, Events, Functions, Load Balancing, Object Storage e Logs de Fluxo da VCN, emitem logs de serviço. Cada um desses serviços suportados tem um recurso de Logs que permite ativar ou desativar o registro em log desse serviço. Por padrão, a retenção de Log é de 1 mês, mas pode ser definida para até 6 meses.

Os grupos de logs podem ser usados para limitar o acesso a logs confidenciais gerados por serviços usando a política do IAM. Você não precisa depender de hierarquias de compartimento complexas para proteger seus logs. Por exemplo, digamos que o grupo de logs padrão em um único compartimento seja onde você armazena logs para toda a tenancy. Você concede acesso ao compartimento para administradores de log com a política do serviço IAM como normalmente faria. No entanto, digamos que alguns projetos contenham informações de identificação pessoal (PII) e esses logs só podem ser exibidos por um grupo seleto de administradores de logs. Os grupos de log permitem que você coloque logs que contenham PII em um grupo de logs separado e, em seguida, use a política do serviço IAM para restringir o acesso a todos, exceto alguns administradores de log.

Para obter mais informações, consulte Logs de Serviço e Gerenciando Logs e Grupos de Logs

Há situações em que alguns problemas só podem ser resolvidos fazendo log-in na VM convidada do cliente pela Oracle.

Veja a seguir as situações em que o acesso à VM convidada do cliente é necessário e procedimentos recomendados para acessar a VM convidada:

1. Situações em que o banco de dados inicial ainda não foi criado e o cliente ainda não tem acesso ssh à VM convidada. Um exemplo seria a SR aberta pelo cliente para solucionar problemas porque o cliente não consegue criar um banco de dados inicial. Nessa situação, o cliente nunca teve acesso à VM convidada e ainda não foi criado um banco de dados; portanto, não existem dados do cliente na VM convidada.

   De acordo com a política de segurança associada ao serviço ExaDB-D, o pessoal da Oracle está proibido de acessar a VM convidada do cliente sem a permissão explícita do cliente. Para obedecer a essa política, a Oracle exige a permissão do Cliente para acessar a VM convidada, fazendo a pergunta a seguir.

   "Para que a Oracle resolva o problema descrito nesta SR, precisamos da permissão explícita do cliente, o que nos permite fazer log-in na VM convidada do cliente. Ao conceder-nos permissão explícita para acessar a VM convidada, você confirma que não há dados confidenciais armazenados na VM convidada do cliente ou em bancos de dados associados e que a equipe de segurança do cliente autoriza a Oracle a ter acesso à VM convidada do cliente para que a Oracle ajude a corrigir esse problema. Tenho sua permissão explícita para acessar a VM convidada?"

   Após uma resposta afirmativa do cliente, a equipe de suporte da Oracle pode fazer log-in na VM convidada do cliente para resolver o problema.

2. Situações em que um número de bancos de dados existe no sistema do cliente e o cliente tem acesso à VM convidada, mas agora o suporte precisa fazer log-in na VM convidada para resolver uma das muitas situações

   Encontramos (os nós não são iniciados por causa de alterações na VM convidada; por exemplo, montagens não existentes no fstab, necessidade de executar o fsck, modificação de Hugepage/sysctl conf ou backup do lvm não concluído com sucesso, o fstab tem entradas incorretas para montações não existentes, o cliente alterou as configurações ou permissões do sshd no arquivo /etc/ssh/sshd_config, etc., ou simplesmente porque o cliente deseja que a Oracle ajude a resolver o problema que ele está enfrentando.

   Este caso é mais sério do que o primeiro, pois pode haver alguns dados confidenciais no sistema de arquivos ou banco de dados da VM convidada do cliente. Nesse caso, nossa equipe de suporte deverá pedir ao cliente para abrir uma nova SR explícita especificamente para obter essa permissão com o seguinte título e conteúdo da SR.

   De acordo com a política de segurança associada ao serviço ExaDB-D, o pessoal da Oracle está proibido de acessar a VM convidada do cliente sem a permissão explícita do cliente. Para que a Oracle obedeça a essa política, é necessário solicitar que você abra uma nova SR com o idioma exato conforme mostrado abaixo, concedendo à Oracle uma permissão explícita para acessar a VM convidada. Observe que qualquer modificação no idioma abaixo pode atrasar a resolução da sua SR.

   Novo Título da SR: SR que concede permissão explícita à Oracle para acessar a DomU do ExaDB-C@C com número de série AK AK99999999

   Novo Conteúdo da SR: Estamos abrindo esta SR para conceder permissão explícita à Oracle para acessar nossa DomU e obter suporte para ajudar a resolver o problema descrito na SR# 1-xxxxxxxx.

   Reconhecemos que ao fornecer essa permissão, entendemos que a Oracle terá acesso a TODOS OS ARQUIVOS na DomU e concordamos que não há

   arquivos confidenciais armazenados em qualquer um dos sistemas de arquivos da DomU. Além disso, também concordamos que a equipe de segurança do cliente autorizou a Oracle a ter acesso à DomU do cliente

   para resolver o problema descrito na SR acima.

   Após a resposta afirmativa do cliente na SR acima, a equipe de suporte da Oracle poderá fazer log-in na VM convidada do cliente para resolver o problema.

Uma lista de responsabilidades do Oracle Cloud Operations e responsabilidades do cliente para várias operações por componentes

• Integração do KMS (chaves HSM)
  
• Usando Algoritmos de Criptografia Não Padrão para Criptografia de Tablespace de TDE