Exadata Cloud Infrastructure está gestionado conjuntamente por el cliente y Oracle, y se divide en dos áreas de responsabilidad.

Los clientes controlan y supervisan el acceso a los servicios del cliente, incluido el acceso de red a sus VM (a través de las redes virtuales en la nube de OCI y las listas de seguridad de OCI), la autenticación para acceder a la VM y la autenticación para acceder a las bases de datos que se ejecutan en las VM. Oracle controla y supervisa el acceso a los componentes de la infraestructura gestionada de Oracle y la seguridad del servidor físico. El personal de Oracle no está autorizado a acceder a los servicios del cliente, incluidas las VM y las bases de datos del cliente, excepto cuando los clientes no puedan acceder a la VM del cliente.

Los clientes acceden a las bases de datos (DB) de Oracle que se ejecutan en Exadata Cloud Infrastructure mediante el cliente y las redes virtuales en la nube de copia de seguridad a las bases de datos que se ejecutan en la máquina virtual del cliente mediante métodos de conexión a bases de datos de Oracle estándar, como Oracle Net en el puerto 1521. Los clientes acceden a la VM que ejecuta las bases de datos de Oracle a través de métodos estándar de Oracle Linux, como ssh basado en token en el puerto 22.

Funciones de seguridad que ofrece Exadata Cloud Infrastructure.

• Seguridad física de Oracle Cloud

  Los centros de datos de Oracle Cloud se alinean con los estándares de nivel 3 (disponibilidad del 99,982 %) o nivel 4 (disponibilidad del 99,995 %) ANSI/TIA-942-A de Uptime Institute y Telecommunications Industry Association (TIA) y siguen la metodología de redundancia N2 ("N" significa "Need" en inglés) para el funcionamiento de equipos esenciales. Los centros de datos que alojan servicios de Oracle Cloud Infrastructure utilizan fuentes de alimentación redundantes y mantienen generadores de reserva en caso de una interrupción eléctrica generalizada. Se supervisa de cerca la temperatura ambiente y la humedad de las salas de servidores, que están dotadas de sistemas de extinción de incendios. El personal del centro de datos cuenta con formación en procedimientos de respuesta y escalada de incidentes para resolver los eventos relacionados con la seguridad y la disponibilidad que pueden surgir. Para obtener más información, consulte: Guía de seguridad de Oracle Cloud Infrastructure. Para obtener más información sobre la conformidad del centro de datos de Oracle Cloud Infrastructure, consulte Conformidad de Oracle Cloud. Consulte también Prácticas de Seguridad Corporativa de Oracle: Seguridad de Datos: Controles Físicos y Ambientales.

• Controles de acceso a centros de datos de Oracle

  Para proporcionar sistemas seguros, los protocolos de acceso de Oracle a los centros de datos físicos incluyen lo siguiente:

  • El acceso físico a las instalaciones de los centros de datos está limitado a determinados empleados, contratistas y visitantes autorizados de Oracle.
  • Los empleados, los subcontratistas y los visitantes autorizados de Oracle reciben tarjetas de identificación que deben usar mientras se encuentran en las instalaciones de Oracle.
  • Los visitantes deben firmar un registro de visitante, ser escoltados y/u observados cuando estén en las instalaciones de Oracle o estar sujetos a los términos de un acuerdo de confidencialidad con Oracle.
  • La seguridad supervisa la posesión de claves/tarjetas de acceso y supervisa la capacidad de acceder a las instalaciones. El personal que deja el empleo de Oracle debe devolver las claves/tarjetas, y las claves/tarjetas se desactivan cuando se produce el cese.
  • La seguridad autoriza todas las reparaciones y modificaciones de las barreras de seguridad físicas o los controles de entrada en las ubicaciones de servicio.
  • Oracle utiliza una combinación de agentes de seguridad u oficiales de patrulla in situ de forma continuada, según el nivel de riesgo/protección de la instalación. En todos los casos, los oficiales son responsables de las patrullas, la respuesta a las alarmas y el registro de incidentes de seguridad.
  • Oracle ha implantado sistemas de control de acceso electrónico gestionados de forma centralizada con capacidad integrada de alarma contra intrusos. Los logs de acceso se conservan durante un mínimo de seis meses. Además, el período de conservación de la supervisión y la grabación del circuito cerrado de televisión oscila entre 30 y 90 días como mínimo, dependiendo de las funciones y el nivel de riesgo de las instalaciones.

  Para obtener más información sobre los controles de acceso a sitios de Oracle, consulte: Prácticas de seguridad corporativa de Oracle: Oracle Access Control

• Aislamiento del cliente de hipervisor

  El hipervisor es el software que gestiona los dispositivos virtuales en un entorno de nube, gestionando la virtualización de la red y el servidor. En entornos de virtualización tradicionales, el hipervisor gestiona el tráfico de red, lo que le permite fluir entre instancias de VM y entre instancias de VM y hosts físicos. Esto agrega una considerable complejidad y sobrecarga computacional en el hipervisor. Los ataques de seguridad informática de prueba de concepto, como los ataques de escape de máquina virtual, han puesto de relieve el considerable riesgo que puede conllevar este diseño. Estos ataques aprovechan la complejidad del hipervisor al permitir a un atacante "salir" de una instancia de máquina virtual, acceder al sistema operativo subyacente y obtener el control del hipervisor. El atacante puede acceder a otros hosts, a veces sin que sea detectado. Oracle Cloud Infrastructure reduce este riesgo desacoplando la virtualización de red del hipervisor.

  Para abordar posibles ataques, Oracle ha implementado una arquitectura que prioriza la seguridad mediante la virtualización de red aislada, que es un elemento fundamental de la arquitectura de la infraestructura de Oracle Cloud. Esta arquitectura detiene el malware en sus pistas con un SmartNIC de diseño personalizado para aislar y virtualizar la red. La virtualización de red aislada reduce el riesgo al limitar la superficie de ataque. Aunque un actor malicioso tenga éxito con un ataque de escape de máquina virtual en un único host, la arquitectura virtual está diseñada de modo que el actor no pueda acceder a otros hosts de la infraestructura en la nube. El ataque se contiene de forma eficaz en ese único host. La arquitectura de virtualización de red aislada y segura se implementa en todos los centros de datos de cada región. A cada inquilino de Oracle Cloud Infrastructure se le proporcionan las ventajas de esta arquitectura que prioriza la seguridad.

  Figura 6-1 La virtualización de red aislada reduce el riesgo en la nube de 2ª generación de Oracle

  
  Descripción de la "Figura 6-1 Virualización de Red Aislada Reduce el Riesgo en Oracle Generation 2 Cloud"
• Seguridad de Multitenant

  En consonancia con nuestra filosofía de seguridad Defensa en profundidad, Multitenant cuenta con una arquitectura de aislamiento completa.

  Existen cuatro categorías principales en ella, con varias características importantes en cada categoría.

  1. Mecanismo de control de acceso
  2. Impedir el acceso no autorizado al administrador
  3. Proteger del acceso directo a los archivos de datos
  4. Aislamiento de recursos
  e

  Figura 6-2 Arquitectura de aislamiento completa de Multitenant

  
  Descripción de "Figura 6-2 Arquitectura de aislamiento completa de Multitenant"

• Defensa en profundidad Exadata Cloud Infrastructure ofrece una serie de controles para garantizar la confidencialidad, la integridad y la disponibilidad en todo el servicio.

  En primer lugar, Exadata Cloud Infrastructure se crea a partir de la imagen de sistema operativo reforzada proporcionada por Exadata Database Machine (https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmsq/exadata-security-overview.html). Esto protege el entorno operativo principal mediante la restricción de la imagen de instalación a únicamente los paquetes de software necesarios, la desactivación de los servicios innecesarios y la implementación de parámetros de configuración seguros en todo el sistema.

  Además de heredar toda la potencia de la plataforma madura de Exadata Database Machine, ya que Exadata Cloud Infrastructure aprovisiona sistemas para los clientes, se implantan opciones de configuración por defecto seguras adicionales en las instancias de servicio. Por ejemplo, todos los tablespaces de base de datos requieren cifrado de datos transparente (TDE), implementación de contraseñas seguras para los usuarios y superusuarios iniciales de la base de datos y reglas de eventos y auditorías mejoradas.

  Exadata Cloud Infrastructure también constituye un despliegue y un servicio completos, por lo que está sujeto a auditorías externas estándar del sector como PCI, HIPPA e ISO27001. Estos requisitos de auditoría externa imponen funciones de servicio adicionales de valor añadido, como análisis antivirus, alertas automatizadas sobre cambios inesperados en el sistema y exploraciones diarias en busca de vulnerabilidades en todos los sistemas de infraestructura de la flota gestionados por Oracle.

• Privilegio mínimo

  Los estándares de codificación segura de Oracle requieren que los procesos de software se ejecuten en el nivel de privilegio mínimo para implantar su funcionalidad.

  Cada proceso y daemon se debe ejecutar con un usuario normal sin privilegios a menos que pueda demostrar un requisito de un nivel superior de privilegios. Esto ayuda a contener cualquier problema imprevisto o vulnerabilidad en un espacio de usuario sin privilegios y a no poner en peligro todo un sistema.

  Este principio también se aplica a los miembros del equipo de operaciones de Oracle que utilizan cuentas con nombre individuales para acceder a Exadata Cloud Infrastructure para su mantenimiento o la solución de problemas. El acceso auditado a niveles superiores de privilegio solo lo utilizarán cuando sea necesario para resolver un problema. La mayoría de los problemas se resuelven mediante automatización, por lo que también empleamos los privilegios mínimos al no permitir que los operadores humanos accedan a un sistema a menos que la automatización no sea capaz de resolver el problema.

• Auditoría y responsabilidad

  Cuando es necesario, se permite el acceso al sistema, pero se lleva a cabo un registro y un seguimiento de todos los accesos y las acciones con fines de responsabilidad.

  Los logs de auditoría de Exadata Cloud Infrastructure los controla Oracle y se utilizan para fines de supervisión de la seguridad y conformidad. Oracle puede compartir logs de auditoría relevantes con los clientes de acuerdo con las prácticas de respuesta a incidentes de Oracle y el acuerdo sobre procesamiento de datos de Oracle.

  Las funciones de auditoría se proporcionan en todos los componentes de infraestructura para garantizar que se capturan todas las acciones. Además, los clientes también tienen la capacidad de configurar las auditorías para adaptarlas a su configuración de VM de invitado y base de datos, y pueden optar por integrarlas con otros sistemas de auditoría empresarial.

• Automatización de las operaciones en la nube

  Con la eliminación de las operaciones manuales necesarias para aprovisionar, aplicar parches, mantener, solucionar problemas y configurar los sistemas, se reduce la oportunidad de que se produzcan errores.

• Imagen de sistema operativo reforzada

  • Instalación mínima de paquetes:

    Solo se instalan los paquetes necesarios para ejecutar un sistema eficaz. Al instalar un juego de paquetes más pequeño, la superficie de ataque del sistema operativo se reduce y el sistema continúa siendo más seguro.

  • Configuración segura:

    Durante la instalación, se definen muchos parámetros de configuración que no son por defecto para mejorar la estrategia de seguridad del sistema y su contenido. Por ejemplo, SSH se configura para recibir únicamente en determinadas interfaces de red, sendmail se configura para aceptar solo conexiones de host local y muchas otras restricciones similares se implementan durante la instalación.

  • Ejecución de únicamente los servicios necesarios:

    Cualquier servicio que se pueda instalar en el sistema, pero que no sea necesario para el funcionamiento normal, se encuentra desactivado por defecto. Por ejemplo, aunque NFS es un servicio que suelen configurar los clientes para diversos fines de la aplicación, este se encuentra desactivado por defecto porque no es necesario para las operaciones normales de la base de datos. Los clientes pueden optar por configurar los servicios de manera opcional según sus necesidades.

• Superficie de ataque minimizada

  Como parte de la imagen reforzada, la superficie de ataque se reduce mediante la instalación y la ejecución solo del software necesario para ofrecer el servicio.

• Funciones de seguridad adicionales activadas (contraseñas de grub, inicio seguro)

  • Al aprovechar las capacidades de imagen de Exadata, ExaDB-D disfruta de las funciones integradas en la imagen base, como contraseñas de grub e inicio seguro, además de muchas otras.
  • A través de la personalización, puede que los clientes deseen mejorar aún más su estrategia de seguridad con configuraciones adicionales.
• Métodos de acceso seguro
  • Acceso a servidores de base de datos mediante SSH con cifrado criptográfico potente. Los cifrados débiles están desactivados por defecto.
  • Acceso a bases de datos a través de conexiones cifradas de Oracle Net. Por defecto, nuestros servicios están disponibles utilizando canales cifrados y un cliente de Oracle Net configurado por defecto utilizará sesiones cifradas.
  • Acceso a diagnósticos a través de la interfaz web de MS de Exadata (https).
• Auditoría y registro
  • Por defecto, las auditorías están activadas para las operaciones administrativas y esos registros de auditoría se comunican a los sistemas internos de OCI para llevar a cabo revisiones y enviar alertas automatizadas cuando es necesario.

Varias cuentas de usuario gestionan con regularidad los componentes de Exadata Cloud Infrastructure. Estos usuarios son necesarios y no se pueden modificar.

En todas las máquinas ExaDB-D, Oracle utiliza y recomienda la conexión SSH basada en token.

Hay tres clases de usuarios:

• Usuarios por defecto: sin privilegios de conexión
  
• Usuarios por defecto CON ACCESO SHELL RESTRINGIDO
  Estos usuarios se utilizan para realizar una tarea definida con una conexión de shell restringida. Estos usuarios no se deben eliminar, ya que la tarea definida fallará en caso de que se supriman los usuarios.
• Usuarios por defecto con permisos de conexión
  Estos usuarios con privilegios se utilizan para realizar la mayoría de las tareas del sistema. Estos usuarios nunca se deben modificar ni suprimir, ya que eso tendría un impacto significativo en el sistema en ejecución.

Además de todas las funciones de Exadata explicadas en Funciones de seguridad de Oracle Exadata Database Machine, también se aplica la siguiente configuración de seguridad a las instancias de Exadata Cloud Infrastructure.

• Despliegue de base de datos personalizado con parámetros que no son por defecto.
  El comando host_access_control sirve para configurar la configuración de seguridad de Exadata:

  • Implementación de políticas de complejidad y caducidad de las contraseñas.
  • Definición de políticas de timeout de sesión y bloqueo de cuentas.
  • Restricción del acceso raíz remoto.
  • Restricción del acceso de red a determinadas cuentas.
  • Implementación de banner de advertencia de conexión.
• account-disable: desactiva una cuenta de usuario cuando se cumplen determinadas condiciones configuradas.
• pam-auth: varios valores de PAM para cambios de contraseñas y autenticación de contraseñas.
• rootssh: ajusta el valor PermitRootLogin en /etc/ssh/sshd_config, que permite o deniega al usuario root conectarse mediante SSH.
  • Por defecto, PermitRootLogin está definido en no.
  • PermitRootLogin=without-password es necesario para que la automatización en la nube realice algunas operaciones de gestión del ciclo de vida. La desactivación de la conexión de root provocará que falle la funcionalidad del servicio.
• session-limit: define el parámetro * hard maxlogins en /etc/security/limits.conf, que es el número máximo de conexiones de todos los usuarios. Este límite no se aplica a un usuario con uid=0.

  El valor por defecto es * hard maxlogins 10 y este es el valor seguro y recomendado.

• ssh-macs: especifica los algoritmos disponibles del código de autenticación de mensajes (MAC).
  • El algoritmo MAC se utiliza en la versión de protocolo 2 para la protección de la integridad de los datos.
  • Los valores predeterminados son hmac-sha1, hmac-sha2-256, hmac-sha2-512 tanto para el servidor como el cliente.
  • Valores recomendados seguros: hmac-sha2-256, hmac-sha2-512 tanto para el servidor como el cliente.
• password-aging: define o muestra la caducidad actual de las contraseñas para las cuentas de usuario interactivas.
  • -M: número máximo de días que se puede utilizar una contraseña.
  • -m: número mínimo de días permitidos entre cambios de contraseña.
  • -W: número de días de advertencia proporcionados antes de que caduque una contraseña.
  • Los valores por defecto son -M 99999, -m 0, -W 7.
  • --strict_compliance_only-M 60, -m 1, -W 7.
  • Valores recomendados seguros: -M 60, -m 1, -W 7.

Lista de los procesos que se ejecutan por defecto en la VM del cliente, también denominada DOMU, o en la VM de invitado y el sistema operativo de invitado

• Agente de VM de Exadata Cloud Infrastructure:

  Agente en la nube para gestionar operaciones del ciclo de vida de la base de datos.

  • Se ejecuta con el usuario opc
  • La tabla de procesos lo muestra ejecutándose como un proceso Java con nombres jar - dbcs-agent-VersionNumber-SNAPSHOT.jar y dbcs-admin-VersionNumver-SNAPSHOT.jar.
• Agente de Oracle Trace File Analyzer:

  Oracle Trace File Analyzer (TFA) proporciona una serie de herramientas de diagnóstico en un solo paquete, lo que facilita la recopilación de información de diagnóstico sobre la base de datos y el clusterware de Oracle, que a su vez ayuda a resolver problemas al tratar con los Servicios de Soporte Oracle

  • Se ejecuta con el usuario root
  • Se ejecuta como el daemon initd (/etc/init.d/init.tfa)
  • Las tablas de procesos muestran una aplicación Java (oracle.rat.tfa.TFAMain)
  • Se ejecuta con los usuarios root y exawatch.
  • Se ejecuta como un script en segundo plano, ExaWatcher.sh, y todos sus procesos secundarios se ejecutan como un proceso Perl.
  • En la tabla de procesos se muestra como varias aplicaciones Perl.:
• Base de datos y GI (clusterware):
  • Se ejecuta con los usuarios dbmsvc y grid
  • La tabla de procesos muestra las siguientes aplicaciones:
    • oraagent.bin, apx_* y ams_* con usuario grid
    • dbrsMain y aplicaciones Java - derbyclient.jar, weblogic.Server como usuario oracle.
• Management Server (MS):

  Parte del software de imagen de Exadata para gestionar y supervisar las funciones de imagen.

  • Se ejecuta como dbmadmin.
  • La tabla de procesos lo muestra ejecutándose como un proceso Java.

• Seguridad de red de VM de invitado
  
• Requisitos de conformidad
  

Funciones de seguridad de base de datos por defecto activadas y utilizadas:

• El cifrado de base de datos transparente (TDE) se utiliza para los tablespaces de base de datos creados por las herramientas de Oracle Database Cloud.
  • CDB$ROOT: el tablespace de usuarios está cifrado
  • PDB: todos los tablespaces cifrados
  • La contraseña de cartera se proporciona durante la creación inicial de la base de datos. Las contraseñas de cartera se pueden cambiar mediante dbaascli. Los clientes deben cambiar esta contraseña periódicamente.
• Usuarios de la base de datos
  • No se crean usuarios adicionales en la base de datos.
  • Después de la creación de la base de datos, todos los usuarios de la base de datos están bloqueados, excepto SYS, SYSTEM y DBSNMP.
  • La auditoría está activada para las siguientes operaciones:
    • 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
    • DB VERSION_11_2: EXEMPT REDACTION POLICY
    • Base de datos VERSION_12_1 o base de datos VERSION_12_2: BECOME USER
    • DB VERSION_12_1: SESSION
    • Se crea el perfil DBAASSECURE y se define como perfil por defecto para la cuenta de usuario de base de datos.

• cifrado nativo de SQL*Net para todas las conexiones de red: los parámetros sqlnet.ora relevantes definidos por defecto en Exadata Cloud Infrastructure son:

  • 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 ofrecido para la conexión de red a la base de datos en el puerto 2484 (wallet configurado en /var/opt/oracle/dbaas_acfs/grid/tcps_wallets). Los parámetros sqlnet.ora relevantes definidos por defecto en Exadata Cloud Infrastructure son:

  • 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: los listeners se ejecutan desde el directorio raíz de GI. Exadata Cloud Infrastructure despliega la versión de Grid Infrastructure especificada en el documento 2333222.1 de los Servicios de Soporte Oracle (versiones de software de Exadata Cloud Service). La configuración por defecto de Exadata Cloud Infrastructure incluye el parámetro listener.ora VALID_NODE_CHECKING_REGISTRATION_LISTENER=SUBNET combinado con REMOTE_REGISTRATION_ADDRESS_<SCANLISTENER>=<value> para restringir los registros remotos del listener por motivos de seguridad.
• Integración de OCI Vault: la clave de cifrado de TDE se puede almacenar en OCI Vault (un sistema de gestión de claves). Para obtener más información e instrucciones para configurar principales, almacenes, etc., consulte Claves gestionadas por el cliente en Exadata Cloud Infrastructure. Tanto el tipo de almacén privado como el compartidos están soportados para la integración de OCI Vault de Exadata Cloud Infrastructure. La autenticación de usuario de base de datos no está integrada con OCI Vault.

Copias de seguridad de sistema operativo/máquina virtual:

Oracle realiza una copia de seguridad completa de la máquina virtual de invitado semanalmente y mantiene una o más copias de seguridad. Estas copias de seguridad son instantáneas de disco completas de la VM de invitado (sistemas de archivos del sistema operativo local, no grupos de discos de ASM que residen en el almacenamiento de Exadata). Esta copia de seguridad se dispara a una hora predefinida cada semana. Las copias de seguridad se almacenan localmente en dom0. Los clientes pueden solicitar a Oracle que restaure la imagen de VM de invitado a partir de la copia de seguridad más reciente mediante la presentación de una solicitud de servicio (SR) de My Oracle Support (MOS). Oracle no puede restaurar archivos específicos a partir de la copia de seguridad de imagen. Los clientes deben realizar copias de seguridad de nivel de archivo en la máquina virtual de invitado si necesitan la capacidad de realizar la restauración de un solo archivo.

Copias de seguridad de base de datos gestionadas:

• Copia de seguridad completa semanal (nivel 0)
• Copia de seguridad incremental gradual diaria (nivel 1) en un ciclo de siete días
• Copias de seguridad automáticas diarias en un momento específico definido durante el proceso de creación del despliegue de base de datos

El período de retención para las copias de seguridad varía de 30 días (en Object Storage) a 7 días (en el almacenamiento local)

Cifrado:

• Object Storage y almacenamiento local: se cifran todas las copias de seguridad en el almacenamiento en la nube.
• Solo Object Storage: se cifran todas las copias de seguridad en el almacenamiento en la nube.

Todas las copias de seguridad se pueden configurar mediante una interfaz de usuario de CP o una API de CP.

Todas las copias de seguridad se cifran con la misma clave maestra que se utiliza para el cifrado de cartera de cifrado de datos transparente (TDE).

Solo las herramientas automatizadas pueden acceder a las máquinas virtuales de invitado para la automatización del ciclo de vida.

Un caso de uso específico es cuando la VM de invitado no se puede iniciar. En este caso, los clientes deben proporcionar permiso para acceder a la VM de invitado para fines de recuperación. Los detalles para manejar este escenario se describen en la sección sobre flujos de trabajo de excepción de Exadata Cloud Service Security Controls.

Los clientes controlan y supervisan el acceso a los servicios del cliente, incluido el acceso de red a sus VM de invitado (a través de firewalls y VLAN de capa 2 implantados en la VM de invitado), la autenticación para acceder a la VM de invitado y la autenticación para acceder a las bases de datos que se ejecutan en las VM de invitado. Oracle controla y supervisa el acceso a los componentes de infraestructura gestionados por Oracle. El personal de Oracle no está autorizado a acceder a los servicios del cliente, incluidas las VM y las bases de datos de invitado.

PII (información de identificación personal) Esta información se considera confidencial y se protege para evitar el uso no autorizado de la información personal para fines de regulación legal, responsabilidad financiera y reputación personal.

Debe configurar un juego de reglas explícitas para evitar que se muestre información de identificación personal (PII) en los datos.

Las reglas de Application Performance Monitoring por defecto ocultan la información de identificación personal en las URL mediante el reconocimiento de valores monetarios, números de cuenta bancaria y fechas. Sin embargo, las reglas por defecto solo capturan información de identificación personal obvia y no son exhaustivas. Debe evaluar las reglas por defecto y configurar más reglas para garantizar la correcta generación de informes en su entorno y garantizar que no se muestre la información de identificación personal en sus datos.

Para obtener más información, consulte Ocultación de información de identificación personal e Información de seguridad e identificación personal

Retención de copia de seguridad

Cuando activa la función Copia de seguridad automática, el servicio crea copias de seguridad incrementales diarias de la base de datos en Object Storage. La primera copia de seguridad creada es una copia de seguridad de nivel 0. Después, se crean copias de seguridad de nivel 1 se crean cada día hasta el siguiente fin de semana. Cada fin de semana, el ciclo se repite, empezando por una nueva copia de seguridad de nivel 0.

Si decide activar las copias de seguridad automáticas, puede seleccionar uno de los siguientes períodos de retención predefinidos: 7 días, 15 días, 30 días, 45 días o 60 días. El sistema suprime automáticamente las copias de seguridad incrementales al final del período de retención seleccionado.

Para obtener más información, consulte Gestión de copia de seguridad y recuperación de bases de datos en Oracle Exadata Database Service on Dedicated Infrastructure

Período de retención de log de auditoría

El servicio OCI Audit proporciona registros de las operaciones de API realizadas en los servicios soportados como una lista de eventos de log. Por defecto, los registros del servicio Audit se retienen durante 365 días.

Para obtener más información, consulte Periodo de retención de log de auditoría

Retención de logs de servicio

Los servicios de Oracle Cloud Infrastructure, como API Gateway, Events, Functions, Load Balancing, Object Storage y los logs de flujo de VCN emiten logs de servicios. Cada uno de estos servicios soportados tiene un recurso Logs que permite activar o desactivar el registro de ese servicio. Por defecto, la retención de logs es de 1 mes, pero se puede definir en un valor de hasta 6 meses.

Los grupos de logs se pueden utilizar para limitar el acceso a los logs confidenciales generados por los servicios mediante la política de IAM. No tiene que depender de jerarquías de compartimento complejas para proteger los logs. Por ejemplo, supongamos que el grupo de logs por defecto de un único compartimento es donde almacena los logs para todo el arrendamiento. Puede otorgar acceso al compartimento para administradores de logs con la política de IAM como haría normalmente. Sin embargo, supongamos que algunos proyectos contienen información de identificación personal (PII) y que esos logs solo los pueden ver un grupo seleccionado de administradores de logs. Los grupos de logs le permiten poner logs que contienen PII en un grupo de logs independiente y, a continuación, utilizar la política de IAM para restringir el acceso a todos los administradores de logs menos a algunos.

Para obtener más información, consulte Logs de servicio y Gestión de logs y grupos de logs

Existen situaciones en las que algunos problemas solo se pueden resolver mediante la conexión de Oracle a la máquina virtual de invitado del cliente.

A continuación se muestran las situaciones en las que se requiere acceso de VM de invitado del cliente y los procedimientos recomendados para acceder a la VM de invitado:

1. Situaciones en las que la base de datos inicial aún no se ha creado y el cliente aún no tiene acceso ssh a su máquina virtual de invitado. Un ejemplo sería una solicitud de servicio abierta por el cliente para solucionar el motivo por el que el cliente no puede crear una base de datos inicial. En esta situación, el cliente nunca ha tenido acceso a la VM de invitado y aún no se ha creado ninguna base de datos y, por lo tanto, no existen datos de cliente en la VM de invitado.

   Según la política de seguridad asociada al servicio ExaDB-D, el personal de Oracle tiene prohibido acceder a la VM de invitado del cliente sin el permiso explícito del cliente. Para cumplir con esta política, Oracle requiere obtener permiso del cliente para acceder a la VM de invitado haciendo la siguiente pregunta.

   "Para que Oracle resuelva la incidencia descrita en esta solicitud de servicio, necesitamos el permiso explícito del cliente que nos permita conectarnos a la máquina virtual de invitado del cliente. Al otorgarnos permiso explícito para acceder a la máquina virtual de invitado, confirma que no hay datos confidenciales almacenados en la máquina virtual de invitado del cliente ni en las bases de datos asociadas, y que el equipo de seguridad del cliente autoriza a Oracle a tener acceso a la máquina virtual de invitado del cliente para que Oracle le ayude a solucionar esta incidencia. ¿Tengo permiso explícito para acceder a la máquina virtual de invitado?"

   Después de la respuesta afirmativa del cliente, el personal de soporte de Oracle puede conectarse a la máquina virtual de invitado del cliente para resolver la incidencia.

2. Situaciones en las que existen varias bases de datos en el sistema del cliente y el cliente tiene acceso a la VM de invitado, pero ahora el soporte necesita conectarse a la máquina virtual de invitado para resolver una de las muchas situaciones

   Hemos encontrado (los nodos no se inician debido a cambios en la VM de invitado, por ejemplo, montajes no existentes en fstab, la necesidad de ejecutar fsck, la modificación de configuración de Hugepage/sysctl o la copia de seguridad de lvm no se ha completado correctamente, fstab tiene entradas incorrectas para montajes no existentes, el cliente ha cambiado las configuraciones o los permisos de sshd en el archivo /etc/ssh/sshd_config, etc.) o simplemente porque el cliente desea que Oracle le ayude a resolver el problema al que se enfrenta.

   Este caso es más grave que el primero, ya que podría haber algunos datos confidenciales en la base de datos o el sistema de archivos de VM de invitado del cliente. En este caso, nuestro personal de soporte necesitará pedir al cliente que abra una nueva solicitud de servicio explícita específicamente para obtener este permiso con el siguiente título y contenido de solicitud de servicio.

   Según la política de seguridad asociada al servicio ExaDB-D, el personal de Oracle tiene prohibido acceder a la VM de invitado del cliente sin el permiso explícito del cliente. Para que Oracle cumpla esta política, es necesario que le solicitemos que abra una nueva solicitud de servicio con el lenguaje exacto, como se muestra a continuación, otorgando a Oracle un permiso explícito para acceder a la VM de invitado. Tenga en cuenta que cualquier modificación en el lenguaje que se muestra a continuación puede retrasar la resolución de su solicitud de servicio.

   Nuevo título de solicitud de servicio: solicitud de servicio que otorga a Oracle permiso explícito para acceder a DomU de ExaDB-Cloud at Customer con el número de serie de AK AK99999999

   Nuevo contenido de solicitud de servicio: abrimos esta solicitud de servicio para otorgar permiso explícito a Oracle para acceder a nuestro DomU con el fin de que el soporte ayude a resolver la incidencia descrita en la solicitud de servicio número 1-xxxxxxxx.

   Confirmamos que, al otorgar este permiso, comprendemos que Oracle tendrá acceso a TODOS LOS ARCHIVOS de DomU y acordamos que no hay ningún

   archivo confidencial almacenado en ninguno de los sistemas de archivos de DomU. Además, también estamos de acuerdo en que el equipo de seguridad del cliente ha autorizado a Oracle a acceder al DomU del cliente

   para resolver la incidencia descrita en la solicitud de servicio anterior.

   Después de la respuesta afirmativa del cliente en la solicitud de servicio anterior, el personal de soporte de Oracle puede conectarse a la máquina virtual de invitado del cliente para resolver la incidencia.

Lista de responsabilidades de Oracle Cloud Operations y responsabilidades del cliente para diversas operaciones por componentes

• Integración de KMS (claves de HSM)
  
• Uso de algoritmos de cifrado no por defecto para el cifrado de tablespace de TDE