Control de acceso en Autonomous Database on Dedicated Exadata Infrastructure

Control de acceso de usuario de Oracle Cloud

Puede controlar qué acceso tienen los usuarios de Oracle Cloud en su arrendamiento a los recursos en la nube que componen su despliegue de Autonomous Database on Dedicated Exadata Infrastructure.

Utilice el servicio Identity and Access Management (IAM) para asegurarse de que los usuarios de la nube tienen acceso para crear y utilizar solo los tipos adecuados de recursos de Autonomous Database para realizar las tareas de su trabajo. Para establecer controles de acceso para los usuarios de la nube, debe definir políticas que otorguen a grupos específicos de usuarios derechos de acceso específicos a tipos de recurso específicos en compartimentos específicos.

El servicio IAM proporciona varios tipos de componentes para ayudarle a definir e implantar una estrategia segura de acceso de usuarios en la nube:

Compartimento: recopilación de recursos relacionados. Los compartimentos son un componente fundamental de Oracle Cloud Infrastructure para la organización y el aislamiento de sus recursos en la nube.
Grupo: recopilación de usuarios que necesitan el mismo tipo de acceso a un determinado juego de recursos o compartimento.
Grupo dinámico: tipo de grupo especial que contiene recursos que coinciden con las reglas que defina. Por lo tanto, la afiliación puede cambiar de forma dinámica a medida que se crean o suprimen recursos coincidentes.
Política: grupo de sentencias que especifican quién puede acceder a qué recursos y cómo. El acceso se otorga en el nivel de grupo y compartimento, lo que significa que debe escribir una sentencia de política que otorgue a un grupo específico un tipo específico de acceso a un tipo específico de recurso dentro de un compartimento específico.

Sentencias Policy y Policy

La herramienta principal que se utiliza para definir el control de acceso para los usuarios de la nube es la política, un recurso de IAM (Identity and Access Management) que contiene sentencias de política que especifican el acceso en términos de "quién", "cómo", "qué" y "dónde".

El formato de una sentencia de política es:

Allow 
  group <group-name> 
  to <control-verb> 
  <resource-type> 
  in compartment <compartment-name>

group <group-name> especifica el "quién" proporcionando el nombre de un grupo de IAM existente, un recurso de IAM al que se pueden asignar usuarios individuales de la nube.
to <control-verb> especifica "cómo" utilizando uno de estos verbos de control predefinidos:
- inspect: capacidad para mostrar recursos del tipo determinado, sin acceso a información confidencial ni a metadatos especificados por el usuario que puedan formar parte de ese recurso.
- read: inspect junto con la capacidad de obtener metadatos especificados por el usuario y el propio recurso.
- use: read junto con la capacidad de trabajar con recursos existentes, pero no de crearlos ni suprimirlos. Además, "trabajar con" significa diferentes operaciones para diferentes tipos de recursos.
- manage: todos los permisos para el tipo de recurso, incluidas la creación y la supresión.
En el contexto de la función de infraestructura dedicada, un administrador de conjunto puede gestionar (manage) bases de datos de contenedores autónomas, mientras que un administrador de base de datos solo puede utilizarlas (use) para crear bases de datos autónomas.
<resource-type> especifica "qué" utilizando un tipo de recurso predefinido. Los valores de tipo de recurso para los recursos de la infraestructura dedicada son:
- exadata-infrastructures
- autonomous-container-databases
- autonomous-databases
- autonomous-backups
Dado que los recursos de la infraestructura dedicada utilizan recursos de red, algunas de las sentencias de política que crea harán referencia al valor de tipo de recurso virtual-network-family. Además, puede crear sentencias de política que hagan referencia al valor de tipo de recurso tag-namespaces si se utiliza el etiquetado en su arrendamiento.
in compartment <compartment-name> especifica el "dónde" proporcionando el nombre de un compartimento de IAM existente, un recurso de IAM en el que se crean los recursos. Los compartimentos son un componente fundamental de Oracle Cloud Infrastructure para organizar y aislar los recursos en la nube.

Para obtener más información sobre la política de Autonomous Database, consulte Políticas de IAM para Autonomous Database en infraestructura de Exadata dedicada.

Para obtener información sobre cómo funcionan el servicio IAM y sus componentes, y cómo utilizarlos, consulte Visión general de Oracle Cloud Infrastructure Identity and Access Management. Para obtener respuestas rápidas a preguntas comunes sobre IAM, consulte Preguntas frecuentes de Identity and Access Management.

Mejores prácticas al planificar e implantar controles de acceso

Al planificar e implantar controles de acceso para la función de infraestructura dedicada, debe tener en cuenta estas mejores prácticas.

Cree una VCN independiente que contenga solo subredes privadas. En casi todos los casos, las instancias de Autonomous Database creadas en la infraestructura dedicada alojan datos confidenciales de la compañía y, por lo general, solo se puede acceder a ellos desde la red privada de la compañía. Incluso los datos compartidos con socios, proveedores, consumidores y clientes se ponen a su disposición a través de canales regulados y seguros.

Por lo tanto, el acceso de red que proporcione a dichas bases de datos debe ser privado de su compañía. Para ello, cree una VCN que utilice subredes privadas y FastConnect o una VPN con IPSec para la conexión a la red privada de su compañía. Para obtener información sobre la definición de esta configuración, consulte Escenario B: subredes privadas con una VPN en la Documentación de Oracle Cloud Infrastructure.

Para obtener más información sobre la protección de la conectividad de red a las bases de datos, consulte Formas de proteger la red en la Documentación de Oracle Cloud Infrastructure.
Cree al menos dos subredes. Debe crear al menos dos subredes: una para los recursos de la base de datos de contenedores autónoma y el cluster de VM de Exadata autónomo y otra para los recursos asociados a clientes y aplicaciones de Autonomous Database.
Cree al menos dos compartimentos. Debe crear al menos dos compartimentos: uno para los recursos de la infraestructura de Exadata, el cluster de VM de Exadata autónomo y la base de datos de contenedores autónoma, y otro para los recursos de Autonomous Database.
Cree al menos dos grupos. Debe crear al menos dos grupos: uno para los administradores de conjunto y otro para los administradores de base de datos.

Control de acceso de cliente

El control de acceso de cliente se implanta en Autonomous Database mediante el control del control de acceso de red y las conexiones de cliente.

Control de acceso de red

El control de acceso de red a las bases de datos autónomas se define al establecer y configurar el despliegue dedicado de Oracle Autonomous Database. El modo de hacerlo depende de si el despliegue dedicado está en Oracle Public Cloud o en Exadata Cloud@Customer:

En Oracle Public Cloud, defina el control de acceso de red mediante componentes del servicio Networking. Cree una red virtual en la nube (VCN) que contenga subredes privadas en las que pueda acceder a sus bases de datos autónomas a través de la red. Además, puede crear reglas de seguridad para permitir un tipo concreto de tráfico que entra o sale de las direcciones IP de una subred.

Para obtener información detallada sobre la creación de estos recursos, ejecute el laboratorio 1 sobre la preparación de una red privada para la implantación de OCI de Oracle Autonomous Database Dedicated for Fleet Administrators.
En Exadata Cloud@Customer, defina los controles de acceso de red especificando una red de cliente en el centro de datos y registrándola en un recurso de red de cluster de VM en el recurso de infraestructura de Exadata.

Enrutamiento de paquetes de confianza cero (ZPR)

Se aplica a: Oracle Public Cloud solo

El enrutamiento de paquetes de confianza cero (ZPR) de Oracle Cloud Infrastructure protege los datos confidenciales del acceso no autorizado mediante políticas de seguridad basadas en intenciones que escribe para los recursos, como un cluster de VM de Exadata autónomo (AVMC) al que asigna atributos de seguridad.

Los atributos de seguridad son etiquetas que ZPR utiliza para identificar y organizar recursos. ZPR aplica la política en el nivel de red cada vez que se solicita acceso, independientemente de posibles cambios en la arquitectura de red o configuraciones incorrectas. ZPR se basa en las reglas existentes de grupo de seguridad de red (NSG) y lista de control de seguridad (SCL). Para que un paquete alcance un destino, debe transferir todas las reglas de NSG y SCL y la política ZPR. La solicitud se borra si alguna regla o política de NSG, SCL o ZPR no permite el tráfico.

Puede proteger redes con ZPR en tres pasos:

Cree artefactos ZPR, es decir, espacios de nombres de atributos de seguridad y atributos de seguridad.
Escriba políticas ZPR para conectar recursos mediante atributos de seguridad. ZPR utiliza un lenguaje de políticas ZPR (ZPL) y aplica restricciones de acceso a los recursos definidos. Como cliente de Autonomous Database on Dedicated Exadata Infrastructure, puede escribir políticas basadas en ZPL en su arrendamiento para garantizar que solo los usuarios y recursos autorizados accedan a los datos de AVMCs.
Asigne atributos de seguridad a recursos para activar las políticas ZPR.

Note:

Evite introducir información confidencial al asignar descripciones, etiquetas, atributos de seguridad o nombres fáciles de recordar a los recursos en la nube mediante la consola de Oracle Cloud Infrastructure, la API o la CLI.

Consulte Getting Started with Zero Trust Packet Routing para obtener más información.

Tiene las siguientes opciones para aplicar atributos de seguridad ZPR a un AVMC:

Aplique atributos de seguridad al aprovisionar un AVMC. Consulte Creación de un cluster de VM de Exadata autónomo para obtener más información.
Aplicar atributos de seguridad a un recurso de AVMC existente. Consulte Configure Zero Trust Packet Routing (ZPR) for an AVMC para obtener más información.

Como requisito, se deben definir las siguientes políticas de IAM para agregar correctamente atributos de seguridad ZPR a AVMC:

allow group <group_name>
to { ZPR_TAG_NAMESPACE_USE, SECURITY_ATTRIBUTE_NAMESPACE_USE }
in tenancy

allow group <group_name>
to manage autonomous-database-family
in tenancy

allow group <group_name>
to read security-attribute-namespaces
in tenancy

listas de control de acceso (ACL)

Para mayor seguridad, puede activar las listas de control de acceso (ACL) en despliegues dedicados de Oracle Public Cloud y Exadata Cloud@Customer. Una ACL proporciona protección adicional a la base de datos al permitir que solo el cliente con direcciones IP específicas se conecte a la base de datos. Puede agregar las direcciones IP de forma individual o en bloques de CIDR. Están soportadas las IP/CIDR basados en IPv4 y IPv6. Esto le permite formular una política de control de acceso detallada limitando el acceso de red de Autonomous Database a clientes o aplicaciones específicos.

Opcionalmente, puede crear una ACL durante el aprovisionamiento de la base de datos o en cualquier momento posterior. También puede editar una ACL en cualquier momento. La activación de una ACL con una lista vacía de direcciones IP hace que la base de datos sea inaccesible. Consulte Definición de la lista de control de acceso para una instancia de Autonomous Database dedicada para obtener más información.

Tenga en cuenta lo siguiente acerca del uso de una ACL con Autonomous Database:

La consola del servicio Autonomous Database no está sujeta a las reglas de la ACL.
Oracle Application Express (APEX), los servicios RESTful, SQL Developer Web y el hub de rendimiento no están sujetos a las ACL.
Al crear una Autonomous Database, si falla la definición de una ACL, también falla el aprovisionamiento de la base de datos.
La actualización de una ACL solo si la base de datos tiene el estado Disponible.
La restauración de una base de datos no sobrescribe las ACL existentes.
La clonación de una base de datos, completa y con metadatos, tendrá la misma configuración de control de acceso que la base de datos de origen. Podrá realizar los cambios que sean necesarios.
La copia de seguridad no está sujeta a las reglas de la ACL.
Durante una actualización de ACL, se permiten todas las operaciones de base de datos de contenedores autónoma (CDB), pero no se permiten las operaciones de Autonomous Database.

Web Application Firewall (WAF)

Para controles de red avanzados más allá de las listas de control de acceso, Oracle Autonomous Database soporta el uso de Web Application Firewall (WAF). WAF protege las aplicaciones frente al tráfico de Internet no deseado y malicioso. WAF puede proteger cualquier punto final orientado a Internet, lo que proporciona un cumplimiento de reglas consistente en todas las aplicaciones de clientes. WAF proporciona a los usuarios la capacidad de crear y gestionar reglas para amenazas de Internet, incluidos los archivos de comandos entre sitios (XSS) y SQL Injection, entre otros. Las reglas de acceso pueden establecer límites según la geografía o la firma de la solicitud. Consulte Introducción a las políticas de Web Application Firewall para obtener información sobre cómo configurar WAF.

Control de conexión de cliente

Oracle Autonomous Database implementa el control de conexión de cliente con autenticación basada en certificado TLS 1.2 y TLS 1.3 estándar para autenticar una conexión de cliente. Sin embargo, TLS 1.3 solo está soportado en Oracle Database 23ai o posterior.

Por defecto, Autonomous Database utiliza certificados autofirmados. Sin embargo, puede instalar el certificado del servidor firmado por una CA desde la consola de Oracle Cloud Infrastructure (OCI). 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. Para obtener más información, consulte Gestión de certificados en una instancia de Autonomous Database dedicada.

Control de acceso de usuario de base de datos

Oracle Autonomous Database configura las bases de datos que crea para utilizar la función de gestión de usuarios estándar de Oracle Database. Crea una cuenta de usuario administrativo, ADMIN, que se utiliza para crear cuentas de usuario adicionales y para proporcionar controles de acceso para las cuentas.

La gestión de usuarios estándar proporciona un sólido juego de funciones y controles, como privilegios de sistema y objeto, roles, perfiles de usuario y políticas de contraseñas, que permiten definir e implantar una estrategia de acceso de usuario de base de datos segura en la mayoría de los casos. Consulte Creación y gestión de usuarios de base de datos para obtener instrucciones detalladas.

Para obtener información básica sobre la gestión de usuarios estándar, consulte la sección sobre cuentas de usuario en Oracle Database Concepts. Para obtener más información y orientación, consulte Gestión de seguridad para usuarios de Oracle Database en Oracle Database 19c Security Guide u Oracle Database 23ai Security Guide.

Si la estrategia de acceso de usuario de base de datos requiere más controles de los que proporciona la gestión de usuarios estándar, puede configurar la base de datos autónoma para que utilice cualquiera de las siguientes herramientas con el fin de cumplir requisitos más rigurosos.

Herramienta	Descripción
Database Vault	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. Consulte Protección de datos en Funciones de seguridad de Autonomous Database para obtener más información.
Oracle Cloud Infrastructure Identity and Access Management (IAM)	Puede configurar Autonomous Database para utilizar la autenticación y la autorización de Oracle Cloud Infrastructure Identity and Access Management (IAM) para permitir a los usuarios de IAM acceder a una instancia de Autonomous Database con credenciales de IAM. Consulte Uso de la autenticación de Identity and Access Management (IAM) con Autonomous Database para utilizar esta opción con la base de datos.
Tokens de acceso OAuth2 de Azure	Puede gestionar de forma centralizada los usuarios de Oracle Autonomous Database en un servicio de Microsoft Azure Active Directory (Azure AD) con la ayuda de tokens de acceso `oAuth2` de Azure. Este tipo de integración permite al usuario de Azure AD acceder a una instancia de Oracle Autonomous Database. Los usuarios y las aplicaciones de Azure AD se pueden conectar con credenciales de conexión única (SSO) de Azure AD para obtener un token de acceso `OAuth2` de Azure AD que enviar a la base de datos. Para obtener más información sobre la integración de Microsoft Azure Active Directory con las bases de datos, consulte Autenticación y autorización de usuarios de Microsoft Azure Active Directory para Autonomous Database.
Microsoft Active Directory (CMU-AD)	Si utiliza Microsoft Active Directory como repositorio de usuarios, puede configurar las instancias de Autonomous Database para autenticar y autorizar usuarios de Microsoft Active Directory. Esta integración puede permitirle consolidar el repositorio de usuarios mientras implanta una estrategia de acceso de usuario de base de datos rigurosa, independientemente de si utiliza la gestión de usuarios estándar, Database Vault, Real Application Security o Base de datos privada virtual. Para obtener más información sobre la integración de Microsoft Active Directory con las bases de datos, consulte Uso de Microsoft Active Directory con Autonomous Database.
Kerberos	Kerberos es un sistema de autenticación de terceros de confianza que utiliza secretos compartidos. Presume que el tercero es seguro y proporciona capacidades de inicio de sesión único, almacenamiento centralizado de contraseñas, autenticación de enlaces de base de datos y seguridad de PC mejorada. Esto se realiza mediante un servidor de autenticación de Kerberos. El soporte de Autonomous Database para Kerberos proporciona las ventajas de la conexión única y la autenticación centralizada de los usuarios de Oracle. Para obtener más información, consulte Autenticación de usuarios de Autonomous Database con Kerberos.
Kerberos con CMU-AD	La autenticación Kerberos se puede configurar sobre CMU-AD para proporcionar autenticación Kerberos CMU-AD para usuarios de Microsoft Active Directory. Para proporcionar autenticación Kerberos CMU-AD para usuarios de Microsoft Active Directory, puede activar la autenticación de Kerberos sobre CMU-AD definiendo `type` en `CMU` mientras activa la autenticación externa, como se muestra en el ejemplo descrito en Activación de la autenticación de Kerberos en Autonomous Database.
Real Application Security y Virtual Private Database	Oracle Real Application Security (RAS) proporciona un modelo declarativo que activa políticas de seguridad que incluyen por completo no solo los objetos de negocio que se van a proteger, sino también los principales (usuarios y roles) que tienen permisos para operar en dichos objetos de negocio. RAS es más seguro, escalable y rentable que su predecesor, Oracle Virtual Private Database. Con Oracle RAS, los usuarios de aplicación se autentican en el nivel de aplicación y en la base de datos. Independientemente de la ruta de acceso a los datos, las políticas de seguridad de datos se aplican en el núcleo de la base de datos en función de la sesión nativa del usuario final en la base de datos. Los privilegios asignados al usuario controlan el tipo de operaciones (seleccionar, insertar, actualizar y suprimir) que se pueden realizar en filas y columnas de los objetos de base de datos. Para obtener más información sobre Oracle RAS, consulte Introducción a Oracle Database Real Application Security en Oracle Database 19c Real Application Security Administrator's and Developer's Guide u Oracle Database 23ai Real Application Security Administrator's and Developer's Guide. Oracle Autonomous Database también soporta Oracle Virtual Private Database (VPD), el predecesor de Oracle RAS. Si ya está familiarizado con Oracle VPD y lo utiliza, puede configurarlo y utilizarlo con sus bases de datos autónomas. Para obtener más información sobre Virtual Private Database, consulte Using Oracle Virtual Private Database to Control Data Access en Oracle Database 19c Security Guide u Oracle Database 23ai Security Guide.

Gestión de privilegios de acceso (PAM)

La estrategia de seguridad de Oracle en torno al acceso de usuarios y la gestión de privilegios en sus productos y servicios se documenta en Oracle Access Control.

Autonomous Database on Dedicated Exadata Infrastructure está diseñada para aislar y proteger los servicios al cliente y los datos de la base de datos del acceso no autorizado. Autonomous Database separa las tareas entre el cliente y Oracle. El cliente controla el acceso a los esquemas de la base de datos. Oracle controla el acceso a los componentes de software e infraestructura gestionados por Oracle.

Autonomous Database on Dedicated Exadata Infrastructure está diseñada para ayudar a proteger los datos para 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 los miembros del personal de operaciones de Oracle Cloud. Entre las medidas de seguridad diseñadas para protegerse contra el acceso no autorizado a la infraestructura de Exadata, las máquinas virtuales autónomas y los datos de la base de datos Oracle se incluyen las siguientes:

Los datos de Oracle Database están protegidos por las claves del cifrado de datos transparente (TDE) de Oracle.
El cliente controla el acceso a las claves de cifrado de TDE y puede optar por almacenar dichas claves en un sistema de gestión de claves de Oracle Key Vault externo.
Oracle Database Vault está preconfigurado para evitar que los usuarios con privilegios accedan a los datos del cliente en instancias de Autonomous Database.
Los clientes pueden optar por aprobar el acceso del operador mediante la inscripción en el servicio Operator Access Control.
Todo el acceso del operador se basa en la autenticación multifactor de hardware de nivel 3 de FIPS 140-2, implementada con un hardware YubiKey implementado con dispositivos aprobados por Oracle.
Todas las acciones del operador se registran en el nivel de comando y se pueden enviar al servicio de registro de OCI o a un SIEM del cliente casi en tiempo real.
Oracle Operations Access Control garantiza que las cuentas de usuario que utiliza el personal de soporte y operaciones de Oracle Cloud para supervisar y analizar el rendimiento no puedan acceder a los datos de las instancias de Autonomous Database. El personal de operaciones y soporte de Oracle Cloud no tiene acceso a los datos de las instancias de Autonomous Database. Al crear una base de datos de contenedores autónoma, Autonomous Database on Dedicated Exadata Infrastructure activa y configura la función Operations Control de Oracle Database Vault para impedir que los usuarios comunes accedan a los datos de las instancias de Autonomous Database creadas en la base de datos de contenedores.
Puede confirmar que el control de operaciones está activo introduciendo esta sentencia SQL en una instancia de Autonomous Database:
```
SELECT * FROM DBA_DV_STATUS;
```
El estado de APPLICATION CONTROL indica que el control de operaciones está activo.

Note:
El control de operaciones se conocía anteriormente como control de aplicaciones.

El PAM también se implanta con Database Vault para la protección de datos, como se explica en Funciones de seguridad de Autonomous Database.