Funciones de seguridad en Autonomous Database on Dedicated Exadata Infrastructure

En este artículo se describen las funciones de seguridad clave de Autonomous Database on Dedicated Exadata Infrastructure.

Tenga en cuenta que a lo largo de esta sección, el término "usted" se utiliza ampliamente para referirse a cualquier administrador de su organización que tenga la responsabilidad de realizar ciertas tareas. En algunos casos, ese es el administrador del conjunto, en otros es el administrador de la base de datos.

Junto con las funciones de seguridad estándar de Oracle Database, como el análisis de privilegios, el cifrado de red, los usuarios gestionados de forma centralizada, los roles de aplicación seguros, la protección transparente de datos confidenciales, entre otras, la instancia de Autonomous Database dedicada agrega Database Vault, Data Safe y otras funciones de seguridad avanzadas sin costo adicional.

Puede ver los componentes básicos de las funciones de seguridad clave de la instancia de Autonomous Database dedicada que se muestran a continuación.

Sugerencia:

En la siguiente imagen, puede hacer clic en la función que desea explorar más a fondo.

Figura: Funciones clave de seguridad



Descripción de la "Figura: Funciones Clave de Seguridad"

Temas relacionados

Gestión de la configuración

La instancia de Autonomous Database, creada en Oracle Cloud Infrastructure, proporciona configuraciones de seguridad estándar y reforzadas para que usted y su equipo no necesiten invertir una gran cantidad de tiempo y dinero gestionando las configuraciones en su conjunto de base de datos autónoma. Todas las cuentas de servicio, como SYS y System, se rotan cada 90 días. Consulte Gestión de configuración en Autonomous Database para obtener más información.

Los parches y las actualizaciones de seguridad se realizan automáticamente, por lo que no tendrá que preocuparse por mantener la seguridad actualizada. Estas capacidades protegen sus bases de datos y datos altamente confidenciales frente a vulnerabilidades e infracciones de seguridad costosas y potencialmente desastrosas. Consulte Mantenimiento del servicio de la instancia de Autonomous Database dedicada para obtener más información.

Cifrado de datos

Autonomous Database almacena todos los datos en formato cifrado en Oracle Database. Solo los usuarios y las aplicaciones autenticados pueden acceder a los datos cuando se conectan a la base de datos.

Autonomous Database utiliza un cifrado siempre activado que protege los datos estáticos y en tránsito. Por defecto, se cifran todos los datos almacenados y la comunicación de red con Oracle Cloud. El cifrado no se puede desactivar.

Consulte Cifrado de datos en una instancia de Autonomous Database dedicada para obtener más información sobre el cifrado de datos y las claves de cifrado maestras.

Realizar auditorías

Oracle Autonomous Database on Dedicated Exadata Infrastructure proporciona sólidas capacidades de auditoría que le permiten realizar un seguimiento de quién hizo qué en el servicio y en bases de datos específicas. Los datos de log completos permiten auditar y supervisar acciones en los recursos, lo que le ayuda a satisfacer los requisitos de auditoría y a reducir el riesgo operativo y de seguridad.

Consulte Capacidades de auditoría en instancia de Autonomous Database dedicada para obtener más información.

Control de Acceso

Al configurar la función de infraestructura de Exadata dedicada, debe asegurarse de que los usuarios de la nube tienen acceso para utilizar y crear solo los tipos adecuados de recursos en la nube para realizar las tareas de su trabajo. Además, debe asegurarse de que solo el personal y las aplicaciones autorizados tienen acceso a las bases de datos autónomas creadas en una infraestructura dedicada. De lo contrario, corre el riesgo de un consumo "sin control" de los recursos de la infraestructura dedicada o de un acceso inadecuado a los datos fundamentales.

La protección del acceso a los datos y a las bases de datos que los contienen incluye varios tipos diferentes de control de acceso. Consulte Control de acceso en una instancia de Autonomous Database dedicada para obtener más información.

Gestión de Certificados

Cuando un cliente intenta conectarse a una instancia de una instancia de Autonomous Database mediante un servicio Oracle Autonomous Database on Dedicated Exadata Infrastructure utiliza una autenticación estándar basada en certificados TLS 1.2 y TLS 1.3 para autenticar la conexión. Sin embargo, TLS 1.3 solo está soportado en Oracle Database 23ai o posterior. Independientemente de si el cliente intenta conectarse a través de un servicio TCPS o TCP, el acceso del cliente a la base del usuario está restringido por los derechos de acceso del usuario que el cliente utiliza para conectarse.

Certificado autofirmado gestionado por Oracle

Por defecto, Autonomous Database utiliza certificados autofirmados. Un certificado autofirmado es un certificado de seguridad generado por el sistema.

Generación de certificados

Los certificados autofirmados gestionados por Oracle se generan automáticamente al aprovisionar un cluster de VM de Exadata autónomo (AVMC) y se aplican a todas las bases de datos creadas en ese AVMC.

Gestión de certificados

Los certificados autofirmados se generan y asocian automáticamente a un AVMC. Sin embargo, debe descargar la cartera de cliente de Autonomous Database antes de conectarse a las bases de datos. Con certificados autofirmados, la conexión a bases de datos sin una cartera no es una opción. Consulte Descarga de credenciales de cliente para obtener instrucciones sobre cómo descargar una cartera para la base de datos.

Dependiendo del requisito, cualquiera de los siguientes tipos de certificados están asociados a su AVMC:
  • Certificado SSL de base de datos: certificado SSL para las conexiones de cliente de base de datos.
  • Certificado SSL de ORDS: certificado SSL para las aplicaciones de Application Express (APEX).
Rotación de certificados

Para satisfacer las necesidades de conformidad con la seguridad de su organización, puede rotar los certificados autofirmados gestionados por Oracle mediante la consola o la API de Oracle Cloud Infrastructure (OCI). Consulte Gestión de certificados de seguridad para un recurso de cluster de VM de Exadata autónomo para obtener instrucciones paso a paso. Esto se denomina rotación de certificados.

Para los recursos de cluster de VM de Exadata autónomo (AVMC) recién aprovisionados, los certificados autofirmados gestionados por Oracle tienen una validez de 13 meses desde su creación. Al rotar un certificado SSL mediante la consola o la API, se rotan tanto los certificados del servidor como los del cliente y se restablece su validez a 13 meses. Cuando un certificado de servidor o de cliente gestionado por Oracle no se rota antes de su caducidad, Oracle los rota automáticamente y genera nuevas carteras.

En el caso de los certificados SSL de base de datos, la rotación de certificados no invalida el certificado existente inmediatamente.

Dentro de las dos semanas siguientes a la rotación del certificado, puede conectarse a las bases de datos mediante la cartera de cliente de Autonomous Database que ha descargado antes o después de la rotación del certificado.

Después de dos semanas desde la rotación del certificado:

  • La cartera de base de datos descargada antes de la rotación del certificado se invalida y no se puede utilizar para conectarse a las bases de datos.
  • La cartera de base de datos descargada en dos semanas de la rotación del certificado permanece activa y se puede utilizar para conectarse a las bases de datos.
  • Cualquier cartera de base de datos nueva descargada después de dos semanas de la rotación del certificado se puede utilizar para conectarse a las bases de datos.

Analicemos esto con un ejemplo:

Considere que un certificado SSL, por ejemplo C1, debe caducar y rotó este certificado el 1 de febrero. Durante dos semanas desde el 1 de febrero, que hasta el 14 de febrero, el antiguo certificado (C1) todavía está disponible para su uso. Puede seguir utilizando el certificado antiguo (C1) o descargar una nueva cartera de base de datos para el certificado rotado (C2) para las conexiones de base de datos. Después de dos semanas desde el 1 de febrero, es decir, desde el 14 de febrero en adelante, el certificado antiguo (C1) se invalida y no se puede utilizar para conexiones de base de datos. Puede seguir utilizando la cartera de base de datos que ha descargado tras la rotación del certificado (C2) durante estas dos semanas. También puede descargar una nueva cartera de base de datos y empezar a utilizarla para las conexiones a la base de datos después de dos semanas desde la rotación.

También puede rotar un certificado SSL de base de datos en un plazo de dos semanas a partir de su rotación más reciente. En este escenario, el certificado antiguo (alrededor de ser invalidado debido a la primera rotación) se desactiva inmediatamente. El siguiente certificado (como resultado de la primera rotación) permanece activo, y un tercer certificado (como resultado de la segunda rotación) estará esperando la activación durante dos semanas desde la segunda rotación. Cualquier cartera de base de datos descargada antes de la primera rotación se invalida poco después de la segunda rotación. Puede seguir conectándose a la base de datos con cualquier cartera de base de datos descargada después de la primera rotación hasta dos semanas después de la segunda rotación. Tras la finalización de dos semanas desde la segunda rotación, solo puede conectarse a las bases de datos mediante una cartera de cliente descargada después de la segunda rotación, es decir, una cartera que se descargó en dos semanas desde la segunda rotación o más tarde.

En el ejemplo anterior, si vuelve a rotar el mismo certificado (C1) dentro de dos semanas a partir del 1 de febrero, el certificado se somete a una doble rotación. En este caso, el certificado antiguo (certificado antes de la primera rotación, es decir, C1) se invalida inmediatamente. El certificado resultante de la primera rotación (C2) permanece activo y un tercer certificado resultante de la segunda rotación, por ejemplo, C3, estará a la espera de activación durante dos semanas desde la segunda rotación. Después de dos semanas desde la segunda rotación, el certificado resultante de la primera rotación (C2) también se invalida y las carteras de base de datos descargadas antes de la segunda rotación no se pueden utilizar para las conexiones de base de datos. Puede seguir utilizando la cartera de base de datos que ha descargado tras la rotación del certificado (C3) durante estas dos semanas. También puede descargar una nueva cartera de base de datos y empezar a utilizarla para las conexiones de base de datos después de dos semanas desde la segunda rotación.

En el caso de los certificados SSL de ORDS, se perderían todas las conexiones de aplicación existentes con la rotación del certificado y se recomienda reiniciar ORDS. El período de buffer de dos semanas descrito anteriormente no se aplica al rotar un certificado SSL de ORDS.

Traiga su propio certificado (BYOC)

Traiga su propio certificado (BYOC) le permite utilizar su certificado de servidor firmado por una CA con sus instancias de Autonomous Database.

Generación de certificados

Para traer su propio certificado, primero debe crear el certificado mediante el servicio de certificado de Oracle Cloud Infrastructure (OCI), como se demuestra en Creación de un certificado. Estos certificados deben estar firmados y tener formato PEM, es decir, su extensión de archivo debe ser solo .pem, .cer o .crt.

Instalación del certificado

Después de crear el certificado del servidor firmado por una CA, debe instalarlo con su AVMC para que las bases de datos creadas en él puedan utilizar este certificado para conexiones seguras. La asociación del certificado BYOC a un AVMC se facilita desde el cuadro de diálogo Gestionar certificados de la consola de OCI. En este cuadro de diálogo, seleccione Traiga su propio certificado y seleccione el certificado que habría creado anteriormente en la lista de selección. Opcionalmente, también puede especificar un certificado de CA con autoridad de certificación y grupo de autoridades de certificación. Consulte Gestión de certificados de seguridad para un recurso de cluster de VM de Exadata autónomo para obtener instrucciones paso a paso.

Gestión de certificados
Puede conectarse a instancias de Autonomous Database asociadas a un servidor firmado por una CA con o sin una cartera de cliente de Autonomous Database.
  • Para conectarse a la base de datos mediante una cartera de base de datos, primero debe descargar las credenciales de cliente de la página Detalles de la base de datos mediante la consola de OCI. Consulte Descarga de credenciales de cliente para obtener instrucciones.
  • Para conectarse a la base de datos sin una cartera de cliente, debe asegurarse de que:
    • Las conexiones TLS unidireccionales están activadas en el nivel de AVMC. Esta es una configuración definida mediante el parámetro Listener en Opciones avanzadas al aprovisionar AVMC. Consulte Creación de un cluster de VM de Exadata autónomo para obtener instrucciones.
    • El certificado del servidor firmado por una autoridad de certificación pública conocida firma el certificado del servidor, de modo que el sistema operativo del cliente confía en él por defecto.
Rotación de certificados

Para satisfacer las necesidades de conformidad con la seguridad de su organización, puede rotar los certificados del servidor firmados por CA mediante la consola o la API de Oracle Cloud Infrastructure (OCI). Consulte Gestión de certificados de seguridad para un recurso de cluster de VM de Exadata autónomo para obtener instrucciones paso a paso.

Debe rotarlos antes de su fecha de caducidad; en caso contrario, no se podrá acceder a las bases de datos de este AVMC en los puertos TLS hasta que proporcione un certificado válido. Sin embargo, puede seguir accediendo a las bases de datos en un puerto que no sea TLS, como 1521.

Eventos de certificado

Los siguientes eventos se publican para la gestión de certificados de seguridad:
Evento Generado cuando
sslcertificateexpiry.reminder Un cluster de VM de Exadata autónomo determina que una cartera caducará dentro de menos de seis (6) semanas. Este evento se notifica como máximo una vez por semana. Este evento se dispara cuando hay una conexión que utiliza la cartera que va a caducar.
sslcertificate.expired El certificado SSL caduca. Caducarán todas las carteras de Autonomous Database relacionadas con este cluster de VM de Exadata autónomo.
sslcertificaterotation.reminder Un certificado SSL tiene más de 365 días de antigüedad y recomienda al cliente rotar el certificado. Una vez que un certificado SSL ha superado los 365 días, este recordatorio se produce una vez por semana hasta que se rota.
sslcertificate.rotated El certificado SSL se rota manualmente (mediante la consola o la API de Oracle Cloud Infrastructure) o automáticamente tras su caducidad.

Sugerencia:

Suscríbase a estos eventos utilizando el servicio OCI Notifications para recibirlos cada vez que se publiquen. Consulte Creación de una suscripción para obtener más información.

Consulte Eventos para Autonomous Database en infraestructura de Exadata dedicada para obtener una lista completa de eventos de Autonomous Database.

Protección de Datos

La protección de datos es un aspecto crítico de la seguridad de los datos en cualquier base de datos. Las cuentas de base de datos con privilegios son una de las vías más utilizadas para obtener acceso a datos de aplicaciones confidenciales en la base de datos. Si bien los usuarios con privilegios como ADMIN u operadores de Oracle necesitan un acceso amplio y sin restricciones para facilitar el mantenimiento de la base de datos, el mismo acceso también crea un punto de ataque para obtener acceso a grandes cantidades de datos.

Autonomous Database permite implantar Privileged Access Management (PAM) mediante:

  • Oracle Database Vault viene preconfigurado y listo para su uso en Autonomous Database. Puede utilizar sus avanzados controles de seguridad para restringir el acceso a los datos de aplicación por parte de usuarios de base de datos con privilegios, de ese modo se reduce el riesgo de amenazas internas y externas y se cumplen los requisitos comunes de conformidad.

    Puede desplegar controles para bloquear el acceso de cuentas con privilegios a los datos de aplicación y controlar las operaciones delicadas dentro de la base de datos. Puede configurar rutas de confianza para agregar controles de seguridad adicionales a los cambios autorizados en la base de datos y el acceso a los datos. Mediante el análisis en tiempo de ejecución de privilegios y roles, puede aumentar la seguridad de las aplicaciones existentes mediante la implantación de privilegios mínimos y la reducción del perfil de ataque de las cuentas de la base de datos. Database Vault protege los entornos de base de datos existentes de forma transparente, eliminando cambios en la aplicación costosos que consumen mucho tiempo.

    Oracle Database Vault aborda principalmente los siguientes problemas de seguridad de la base de datos:

    • Acceso de cuenta con privilegios administrativos a los datos de la aplicación: aunque el administrador de la base de datos es el usuario más potente y de confianza, este administrador no necesita acceso a los datos de la aplicación que residen en la base de datos.

      Los dominios de Oracle Database Vault en torno a esquemas de aplicaciones, tablas confidenciales y procedimientos almacenados proporcionan controles para evitar que los intrusos e internos aprovechen las cuentas con privilegios para acceder a datos confidenciales de la aplicación. Consulte How Oracle Database Vault Protects Privileged User Accounts en Oracle Database 19c Administrator's Guide o Oracle Database 23ai Administrator's Guide para obtener más información.

    • Separación de tareas para el acceso a datos de la aplicación: la separación de controles de tareas de Oracle Database Vault se puede personalizar y las organizaciones con recursos limitados pueden asignar varias responsabilidades de Oracle Database Vault al mismo administrador, pero utilizando cuentas independientes para cada rol de separación de tareas a fin de minimizar los daños en la base de datos si se roba y se aprovecha alguna cuenta. Consulte How Oracle Database Vault Addresses Database Consolidation Concerns in Oracle Database 19c Administrator's Guide o Oracle Database 23ai Administrator's Guide para obtener más información.

    Antes de utilizar Database Vault, consulte What to Expect After You Enable Oracle Database Vault en la Oracle Database 19c Administrator's Guide o la Oracle Database 23ai Administrator's Guide para comprender el impacto de configurar y activar Database Vault.

    Para obtener información sobre cómo configurar y activar Database Vault en la base de datos autónoma, consulte Uso de Oracle Database Vault para gestionar privilegios de usuario de base de datos.

    Sugerencia:

    Para probar el proceso de configuración de Database Vault, ejecute el laboratorio 1 sobre protección de datos con Database Vault de Oracle Autonomous Database Dedicado para administradores de seguridad.
  • El PAM también se utiliza para proteger los datos para el uso autorizado por el cliente y para ayudar a proteger los datos del acceso no autorizado, lo que incluye la prevención del acceso a los datos del cliente por parte de las operaciones de Oracle Cloud y los miembros del personal de soporte. Oracle Operations Access Control garantiza que las cuentas de usuario que utiliza el personal de operaciones y soporte de Oracle Cloud para supervisar y analizar el rendimiento no puedan acceder a los datos de las instancias de Autonomous Database. Consulte Privileged Access Management para obtener más información.

Detección y enmascaramiento de datos confidenciales

La identificación de datos confidenciales (como número de tarjeta de crédito, NSS) y el enmascaramiento o la redacción de datos según sea necesario mejoran la protección de datos y la seguridad general de los datos.

  • Oracle Autonomous Database on Dedicated Exadata Infrastructure soporta la integración con el servicio Oracle Data Safe para ayudarle a evaluar y proteger sus bases de datos. Oracle Data Safe le ayuda a comprender la confidencialidad de los datos, evaluar riesgos para los datos, enmascarar datos confidenciales, implantar y supervisar controles de seguridad, evaluar la seguridad del usuario, supervisar la actividad del usuario y abordar los requisitos de conformidad con la seguridad de los datos en las bases de datos.

    Esta proporciona el siguiente conjunto de funciones en una única consola de gestión fácil de usar:

    • Evaluación de seguridad le ayuda a evaluar la seguridad de la configuración de la base de datos.

    • Evaluación de usuario le ayuda a evaluar la seguridad de los usuarios de base de datos y a identificar a los usuarios de alto riesgo.

    • Detección de datos le ayuda a encontrar datos confidenciales en la base de datos. Enmascaramiento de datos le proporciona una manera de enmascarar datos confidenciales para que los datos estén seguros para fines que no sean de producción.

    • Auditación de actividad le permite auditar la actividad del usuario en la base de datos para que pueda supervisar el uso de la base de datos y recibir alertas sobre actividades inusuales de la base de datos.

    Para obtener más información sobre el uso de Data Safe, consulte Visión general de Oracle Data Safe en Uso de Oracle Data Safe.

    Para utilizar Oracle Data Safe para identificar y proteger datos confidenciales y regulados de Autonomous Database, debe registrar la base de datos con Data Safe. Después de registrar la base de datos con Data Safe, puede ir a la consola de Data Safe directamente desde la página Detalles de la instancia de Autonomous Database. Para obtener más información sobre el registro de la base de datos, consulte Registro o anulación de registro de una base de datos dedicada con Data Safe.

  • Cuando una consulta emitida por una aplicación en tiempo de ejecución devuelve un juego de resultados con información confidencial, como números de tarjeta de crédito o ID personales, Oracle Data Redaction puede ayudarle a enmascarar los detalles confidenciales antes de devolver el juego de resultados a la aplicación. Puede implantar políticas para la ocultación de datos mediante el paquete PL/SQL DBMS_REDACT . Consulte DBMS_REDACT en Referencia de tipos y paquetes PL/SQL de Oracle Database 19c o Referencia de tipos y paquetes PL/SQL de Oracle Database 23ai.

Certificación de conformidad normativa

Autonomous Database on Dedicated Exadata Infrastructure cumple un amplio juego de estándares de conformidad internacionales y específicos del sector, que incluyen:

  • FedRAMP High - Programa federal de gestión de riesgos y autorizaciones (solo regiones del Gobierno de EE. UU.)
  • HIPAA - Ley de portabilidad y responsabilidad de seguros de salud
  • ISO/IEC 27001:2013 - International Organization for Standardization 27001
  • ISO/IEC 27017:2015 - Código de buenas prácticas para controles de seguridad de la información basado en ISO/IEC 27002 para servicios en la nube
  • ISO/IEC 27018:2014 - Código de buenas prácticas para la protección de información de identificación personal (PII) en nubes públicas que actúan como procesadores PII
  • PCI DSS - las normas de seguridad de datos de la industria de tarjetas de pago son un juego de requisitos destinados a garantizar que todas las compañías que procesan, almacenan o transmiten información de tarjetas de crédito mantengan un entorno seguro.
  • SOC 1 - System and Organization Controls 1
  • SOC 2 - System and Organization Controls 2

Para obtener más información y una lista completa de certificaciones, consulte Conformidad de Oracle Cloud.