Os clientes controlam e monitoram o acesso aos serviços do cliente, incluindo o acesso da rede a suas VMs (por meio de VLANs e firewalls de camada 2 implementados na VM do cliente), 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 gerenciados pela Oracle. A equipe da Oracle não está autorizada a acessar os serviços do cliente, incluindo VMs e bancos de dados.

Os clientes acessam os Oracle Databases em execução no Exadata Cloud@Customer por meio de uma conexão de camada 2 (VLAN com tag) do equipamento do cliente para os bancos de dados em execução na VM do cliente usando métodos de conexão padrão do Oracle Database, como Oracle Net na porta 1521. Os clientes acessam a 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.

• Defesa em profundidade

  O Exadata Cloud@Customer oferece vários controles para garantir confidencialidade, integridade e responsabilidade em todo o serviço.

  Em primeiro lugar, o Exadata Cloud@Customer foi criado com base na imagem do sistema operacional fortalecida que o Exadata Database Machine fornece. Para obter mais informações, consulte Visão Geral da Segurança do Oracle Exadata Database Machine. 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@Customer provisiona os sistemas para os clientes, opções adicionais de configuração padrão segura 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@Customer também constitui uma implantação e um serviço completos; por isso, é 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

  Para garantir que os processos tenham apenas acesso aos privilégios necessários, os Padrões de Codificação Segura da Oracle exigem o paradigma do privilégio mínimo.

  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 a infraestrutura do Oracle Exadata Cloud@Customer 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.

  Isso garante que a Oracle e os clientes saibam o que foi feito no sistema e quando ocorreu. Esses fatos não apenas garantem que continuemos em conformidade com as necessidades de relatórios de auditorias externas, mas também podem ajudar a fazer a correspondência de algumas alterações com uma mudança de comportamento percebida no aplicativo.

  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 e uma configuração segura é garantida.

  O serviço foi projetado para ser seguro e, automatizando todas as tarefas de provisionamento, configuração e a maioria das outras tarefas operacionais, é possível evitar configurações perdidas e garantir que todos os caminhos necessários para o sistema sejam fechados corretamente.

• Imagem Aprimorada 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 com a desativação de serviços.

• Recursos de Segurança Adicionais Ativados (senhas do grub, inicialização segura)
  • Aproveitando os recursos de imagem do Exadata, o Exadata Cloud@Customer 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 detalhadas posteriormente neste capítulo.
• Métodos de Acesso Seguro
  • Acessar servidores de banco de dados por meio do 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 por meio da 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.

• Considerações sobre o Tempo de Implantação
  • Conteúdo de download e confidencialidade do arquivo da wallet: O download do arquivo da wallet obtido por um cliente para permitir que a implantação ocorra contém informações confidenciais e deve ser tratado corretamente para garantir que o conteúdo seja protegido. O conteúdo do download do arquivo da wallet não é necessário após a conclusão da implantação; portanto, deverá ser destruído para garantir que não ocorra vazamento de informações.
  • Control Plane Server (CPS):
    • Os requisitos de implantação do CPS incluem permitir acesso HTTPS de saída para que o CPS possa estabelecer conexão com a Oracle e permitir administração, monitoramento e manutenção remotos. Encontre mais detalhes no Guia de Implantação.
    • As responsabilidades do cliente incluem oferecer segurança física ao equipamento Exadata Cloud@Customer no data center. Enquanto o Exadata Cloud@Customer emprega muitos recursos de segurança de software, o comprometimento físico do servidor deve ser tratado pela segurança física do cliente para garantir a segurança do conteúdo dos servidores.

Várias contas de usuário gerenciam regularmente os componentes do Oracle Exadata Cloud@Customer. Em todas as máquinas do Exadata Cloud@Customer, a Oracle usa e recomenda somente log-in baseado em SSH. Nenhum usuário ou processo Oracle usa sistema de autenticação baseado em senha.

Veja a seguir os diferentes tipos de usuários criados por padrão.

• Usuários Padrão: Nenhum Privilégio de Log-on

  Essa é uma lista de usuários padrão do sistema operacional, com alguns usuários especializados, como exawatch e dbmsvc. Esses usuários não devem ser alterados. Esses usuários não podem fazer log-in no sistema porque todos estão definidos como /bin/false.

  • exawatch:

    O usuário exawatch é responsável por coletar e arquivar estatísticas do sistema nos servidores de banco de dados e nos servidores de armazenamento.

  • dbmsvc:

    O usuário é utilizado para o Servidor de Gerenciamento do serviço de nó de banco de dados no Sistema Oracle Exadata.

  NOLOGIN Users

  bin:x:1:1:bin:/bin:/bin/false
  daemon:x:2:2:daemon:/sbin:/bin/false
  adm:x:3:4:adm:/dev/null:/bin/false
  mail:x:8:12:mail:/var/spool/mail:/bin/false
  nobody:x:99:99:Nobody:/:/bin/false
  systemd-network:x:192:192:systemd Network Management:/:/bin/false
  dbus:x:81:81:System message bus:/:/bin/false
  rpm:x:37:37::/var/lib/rpm:/bin/false
  sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/bin/false
  rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/bin/false
  nscd:x:28:28:NSCD Daemon:/:/bin/false
  saslauth:x:999:76:Saslauthd user:/run/saslauthd:/bin/false
  mailnull:x:47:47::/var/spool/mqueue:/bin/false
  smmsp:x:51:51::/var/spool/mqueue:/bin/false
  chrony:x:998:997::/var/lib/chrony:/bin/false
  rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/bin/false
  uucp:x:10:14:Uucp user:/var/spool/uucp:/bin/false
  nslcd:x:65:55:LDAP Client User:/:/bin/false
  tcpdump:x:72:72::/:/bin/false
  exawatch:x:1010:510::/:/bin/false
  sssd:x:997:508:User for sssd:/:/bin/false
  tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/bin/false
  dbmsvc:x:12137:11137::/home/dbmsvc:/bin/false

• Usuários Padrão com Acesso de 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 alterados porque a tarefa definida falhará caso eles sejam alterados ou excluídos.

  dbmmonitor: O usuário dbmmonitor é utilizado para o Utilitário DBMCLI. Para obter mais informações, consulte Usando o Utilitário DBMCLI.

  Usuários de Shell Restrito

  dbmmonitor:x:2003:2003::/home/dbmmonitor:/bin/rbash

• 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.

  As chaves SSH são usadas para log-in pela equipe do cliente e automação da nuvem.

  As chaves SSH adicionadas pelo cliente podem ser adicionadas pelo método UpdateVmCluster ou pelos clientes acessando diretamente a VM do cliente e gerenciando chaves SSH dentro da VM do cliente. Os clientes são responsáveis por adicionar comentários às chaves para torná-las identificáveis. Quando um cliente adiciona a chave SSH pelo método UpdateVmCluster, a chave só é adicionada ao arquivo authorized_keys do usuário opc.

  As chaves de automação da nuvem são temporárias, específicas de uma determinada tarefa de automação da nuvem, por exemplo, redimensionamento da Memória do Cluster de VMs, e exclusivas. As chaves de acesso de automação da nuvem podem ser identificadas pelos seguintes comentários: OEDA_PUB, EXACLOUD_KEY, ControlPlane. As chaves de automação da nuvem são removidas após a conclusão da tarefa de automação da nuvem, de modo que os arquivos authorized_keys das contas root, opc, oracle e grid só devem conter chaves de automação da nuvem enquanto as ações de automação da nuvem estão em execução.

  Usuários Privilegiados

  root:x:0:0:root:/root:/bin/bash
  oracle:x:1001:1001::/home/oracle:/bin/bash
  grid:x:1000:1001::/home/grid:/bin/bash
  opc:x:2000:2000::/home/opc:/bin/bash
  dbmadmin:x:2002:2002::/home/dbmadmin:/bin/bash

  • root: Requisito do Linux, usado com moderação para executar comandos privilegiados locais. root também é usado em alguns processos como Oracle Trace File Analyzer Agent e ExaWatcher.
  • grid: Possui a instalação do software Oracle Grid Infrastructure e executa os processos do Grid Infastructure.
  • oracle: Possui a instalação do software de banco de dados Oracle e executa os processos do Oracle Database.
  • opc:
    • Usado pela automação do Oracle Cloud para tarefas de automação.
    • Tem a capacidade de executar determinados comandos privilegiados sem autenticação adicional (para suportar funções de automação).
    • Executa o agente local, também conhecido como "Agente do DCS" que executa operações do ciclo de vida do software Oracle Database e Oracle Grid Infastructure (aplicar patch, criar banco de dados etc.).
  • dbmadmin:
    • O usuário dbmadmin é usado para o utilitário DBMCLI (Database Machine Command-Line Interface) do Oracle Exadata.
    • O usuário dbmadmin deve ser utilizado para executar todos os serviços no servidor de banco de dados. Para obter mais informações, consulte Usando o Utilitário DBMCLI.

Os grupos a seguir são criados por padrão na máquina virtual convidada.

root:x:0:
bin:x:1:
daemon:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:
mem:x:8:
kmem:x:9:
wheel:x:10:
cdrom:x:11:
mail:x:12:
man:x:15:
dialout:x:18:
tape:x:33:
video:x:39:
lock:x:54:
audio:x:63:
nobody:x:99:
users:x:100:
utmp:x:22:
utempter:x:35:
input:x:999:
systemd-journal:x:190:
systemd-network:x:192:
dbus:x:81:
ssh_keys:x:998:
sshd:x:74:
rpm:x:37:
rpc:x:32:
unbound:x:997:
nscd:x:28:
tss:x:59:
saslauth:x:76:
mailnull:x:47:
smmsp:x:51:
chrony:x:996:
rpcuser:x:29:
ldap:x:55:
slocate:x:21:
uucp:x:14:
tcpdump:x:72:
exawatch:x:510:
cgred:x:509:
fuse:x:508:
screen:x:84:
sssd:x:507:
printadmin:x:506:
docker:x:505:
dbmsvc:x:2001:
dbmadmin:x:2002:
dbmmonitor:x:2003:
dbmusers:x:2004:
floppy:x:19:
oinstall:x:1001:
asmdba:x:1004:
asmoper:x:1005:
asmadmin:x:1006:
dba:x:1002:
racoper:x:1003:
opc:x:2000:

root:x:0:
bin:x:1:
daemon:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:
mem:x:8:
kmem:x:9:
wheel:x:10:
cdrom:x:11:
mail:x:12:
man:x:15:
dialout:x:18:
tape:x:33:
video:x:39:
lock:x:54:
audio:x:63:
users:x:100:
nobody:x:2001:
utmp:x:22:
utempter:x:35:
dbus:x:81:
input:x:999:
kvm:x:36:
render:x:998:
systemd-journal:x:190:
systemd-coredump:x:997:
systemd-resolve:x:193:
tss:x:59:
ssh_keys:x:996:
sshd:x:74:
unbound:x:995:
nscd:x:28:
rpc:x:32:
saslauth:x:76:
mailnull:x:47:
smmsp:x:51:
rpcuser:x:29:
ldap:x:55:
slocate:x:21:
chrony:x:994:
tcpdump:x:72:
cgred:x:993:
fapolicyd:x:992:
printadmin:x:991:
polkitd:x:990:
sssd:x:989:
rpm:x:37:
screen:x:84:
dnsmasq:x:988:
exawatch:x:510:
dbmsvc:x:2002:
dbmadmin:x:2003:
dbmmonitor:x:2004:
dbmusers:x:2005:
uucp:x:14:
floppy:x:19:
mausers:x:2006:
secscan:x:1009:
oinstall:x:1001:
asmdba:x:1004:
asmoper:x:1005:
asmadmin:x:1006:
dba:x:1002:
racoper:x:1003:
opc:x:2000:

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.

• 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 without-password.
  • É recomendável deixar essa definição para permitir que o subconjunto de automação da nuvem que usa esse caminho de acesso (por exemplo, aplicação de patch no Sistema Operacional da VM do cliente) funcione. A definição de PermitRootLogin como no desativará esse subconjunto de funcionalidades de automação da nuvem.
• 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

• Agente da VM Convidada do Exadata Cloud@Customer: 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 Oracle Database e o Oracle Clusterware, 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 initd, /etc/init.d/init.tfa.
  • As tabelas de processos mostram um aplicativo Java, oracle.rat.tfa.TFAMain.

• ExaWatcher:

  • É 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.
• Oracle Database e Oracle Grid Infrastructure (Oracle 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 e 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 usuário dbmadmin.
  • A tabela de processos mostra a execução como processo Java.

Regras padrão do iptables para a VM Convidada:

#iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination