Funciones de seguridad en Autonomous AI Database on Dedicated Exadata Infrastructure

En este artículo se describen las funciones de seguridad clave de Autonomous AI 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 determinadas 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 AI 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 de datos confidenciales transparentes y otros, una base de datos de IA autónoma dedicada agrega Database Vault, Data Safe y otras funciones de seguridad avanzadas sin costo adicional.

A continuación, se muestran los componentes básicos de las funciones de seguridad clave de una base de datos de IA autónoma dedicada.

Descripción de la ilustración adbd-security-features.svg

Gestión de la configuración

La base de datos de IA autónoma, creada en Oracle Cloud Infrastructure, proporciona configuraciones para que usted y su equipo no necesiten invertir una gran cantidad de tiempo y dinero gestionando configuraciones en su conjunto de bases de datos de IA autónoma. Todas las cuentas de servicio, como SYS y System, se rotan cada 90 días. Consulte Gestión de la configuración en la base de datos de IA autónoma 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 ante vulnerabilidades e infracciones en materia de seguridad costosas y potencialmente desastrosa. Consulte Mantenimiento del servicio de la base de datos de IA autónoma dedicada para obtener más información.

Cifrado de datos

Autonomous AI 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.

La base de datos de IA autónoma utiliza el cifrado siempre activo que protege los datos estático 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 base de datos de IA autónoma dedicada para obtener más información sobre el cifrado de datos y las claves de cifrado maestras.

Realizar auditorías

Oracle Autonomous AI Database en una infraestructura de Exadata dedicada proporciona sólidas capacidades de auditoría que le permiten realizar un seguimiento a quién hizo qué en el servicio y en bases 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 Auditoría de capacidades en una base de datos de IA autónoma dedicada para obtener más información.

Control de Acceso

Al configurar la función Infraestructura de Exadata dedicada, debe asegurarse de que sus usuarios en la nube tienen acceso para utilizar y crear solo los tipos adecuados de recursos en la nube para realizar sus tareas del trabajo. Además, debe asegurarse de que solo las aplicaciones y el personal autorizados tienen acceso a las bases de datos de IA autónomas creadas en la infraestructura dedicada. De lo contrario, corre el riesgo de un consumo "sin controlar" de los recursos de su infraestructura dedicada o del 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 base de datos de IA autónoma dedicada para obtener más información.

Gestión de Certificados

Cuando un cliente intenta conectarse a una base de datos de IA autónoma a través de un servicio de conexión de base de datos TCPS (TCP seguro), Oracle Autonomous AI Database on Dedicated Exadata Infrastructure utiliza la autenticación basada en certificados TLS 1.2 y TLS 1.3 estándar para autenticar la conexión. Sin embargo, TLS 1.3 solo se admite en Oracle AI 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, la base de datos de IA autónoma 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 se asocian automáticamente con un AVMC. Sin embargo, debe descargar la cartera de cliente de Autonomous AI Database antes de conectarse a sus bases de datos. Con certificados autofirmados, la conexión a bases de datos sin cartera no es una opción. Consulte Descarga de credenciales de cliente para obtener instrucciones sobre la descarga de una cartera para la base de datos.

Según el requisito, cualquiera de los siguientes tipos de certificados están asociados con su AVMC:

Rotación de certificados

Para satisfacer las necesidades de conformidad de 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 los certificados del servidor y del cliente y se restablece su validez a 13 meses. Cuando un certificado del lado del cliente o del servidor 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 dos semanas desde la rotación del certificado, puede conectarse a sus bases de datos mediante la cartera de cliente de base de datos de IA autónoma que ha descargado antes o después de la rotación del certificado.

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

Vamos a discutir esto con un ejemplo:

Considere que un certificado SSL, por ejemplo C1, debe caducar y ha rotado 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 girado (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 a bases 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 de base de datos después de dos semanas desde la rotación.

También puede rotar un certificado SSL de base de datos en menos de dos semanas desde su rotación más reciente. En este escenario, el certificado antiguo (alrededor de invalidarse debido a la primera rotación) se desactiva inmediatamente. El siguiente certificado (que tiene como resultado la primera rotación) permanece activo y un tercer certificado (que tiene como resultado 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 desde la segunda rotación. Después de la finalización de dos semanas desde la segunda rotación, solo puede conectarse a sus bases de datos mediante una cartera de cliente descargada después de la segunda rotación, es decir, una cartera que se descargó dentro de dos semanas desde la segunda rotación o más tarde.

En el ejemplo anterior, si vuelve a rotar el mismo certificado (C1) en dos semanas desde el 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á esperando la 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 conexiones de base de datos. Puede seguir utilizando la cartera de base de datos que descargó después de 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, todas las conexiones de aplicación existentes se perderían con la rotación del certificado y se le 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 cheque regalo (BYOC)

Bring Your Own Certificate (BYOC) te permite utilizar tu certificado de servidor firmado por CA con tus bases de datos de IA autónomas.

Generación de certificados

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

Instalación del certificado

Después de crear el certificado del lado del servidor firmado por la 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 de su certificado BYOC con un AVMC se facilita desde el cuadro de diálogo Gestionar certificados en 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. Sin embargo, si selecciona un grupo de autoridades de certificación para un certificado SSL de ORDS, el grupo solo debe contener certificados que formen parte de la cadena de certificados. 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 bases de datos de IA autónomas asociadas a un servidor firmado por CA con o sin una cartera de cliente de base de datos de IA autónoma.

Rotación de certificados

Para satisfacer las necesidades de conformidad de 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 no TLS, como 1521.

Eventos de certificado

Se publican los siguientes eventos 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 debe caducar en 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. Todas las carteras de base de datos de IA autónoma relacionadas con este cluster de VM de Exadata autónomo caducarán.
sslcertificaterotation.reminder Los certificados SSL tienen más de 365 días 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 cuando caduca.

Consejo: suscríbase a estos eventos mediante 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 la base de datos de IA autónoma en una infraestructura de Exadata dedicada para obtener una lista completa de eventos de la base de datos de IA autónoma.

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 rutas más utilizadas para obtener acceso a datos de aplicaciones confidenciales en la base de datos. Mientras que los usuarios con privilegios, como los operadores ADMIN u 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 AI Database te permite implementar Privileged Access Management (PAM) mediante:

Detección y enmascaramiento de datos confidenciales

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

Certificación de conformidad normativa

La base de datos de IA autónoma en infraestructura de Exadata dedicada cumple un amplio conjunto de estándares de cumplimiento internacionales y específicos del sector, que incluyen:

Para obtener más información y una lista completa de certificaciones, consulte Conformidad de Oracle Cloud. Consulte Documentos de conformidad para descargar copias de los documentos de certificación.

Contenido relacionado