Cómo funcionan las políticas

Para establecer un marco de comprensión antes de escribir sus propias políticas, obtenga una visión general de qué son las políticas, en qué consisten sus componentes y cuáles son sus características básicas.

En este tema se describe cómo funcionan las políticas, las funciones que afectan a su uso y cómo se integran esas funciones con otros recursos y funciones básicos de Oracle Cloud Infrastructure.

Visión general de las políticas

Una política es un documento que especifica quién puede acceder a qué recursos de Oracle Cloud Infrastructure de la compañía y el método de acceso. Una política simplemente permite a un grupo  trabajar de determinadas formas con tipos específicos de recursos en un compartimento concreto. Si no está familiarizado con los usuarios, los grupos o los compartimentos, consulte Visión general de IAM.

A continuación, se muestra el proceso genérico que debe seguir un administrador de IAM en su organización:

  1. Definir usuarios, grupos y uno o más compartimentos para mantener los recursos en la nube de su organización.
  2. Crear una o más políticas escritas en el lenguaje de la política. Consulte Políticas comunes.
  3. Colocar los usuarios en los grupos adecuados en función de los compartimentos y los recursos con los que necesiten trabajar.
  4. Proporcionar a los usuarios las contraseñas de un solo uso que necesitan para acceder a la consola y trabajar con los compartimentos. Para obtener más información, consulte Credenciales de usuario.

Después de que el administrador realice estos pasos, los usuarios pueden acceder a la consola, cambiar sus contraseñas de un solo uso y trabajar con recursos en la nube específicos según lo establecido en las políticas.

Datos básicos de las políticas

Para gobernar el control de los recursos, la compañía debe tener al menos una política. Cada política consta de una o más sentencias de políticas que siguen esta sintaxis básica:

Allow group <identity_domain_name>/<group_name> to <verb> <resource-type> in compartment <compartment_name>
Nota

Si no incluye <identity_domain_name> antes de <group_name>, la sentencia de política se evaluará como si el grupo perteneciera al dominio de identidad por defecto.

Tenga en cuenta que las sentencias siempre empiezan por la palabra Allow. Las políticas solo permiten el acceso; no pueden denegarlo. En su lugar, hay una denegación implícita, lo que significa que, por defecto, los usuarios no pueden hacer nada y se les debe otorgar acceso mediante políticas. (Hay una excepción a esta regla; consulte ¿Los usuarios pueden llevar a cabo alguna acción sin que un administrador escriba previamente una política?)

Un administrador de su organización define los grupos y compartimentos de su arrendamiento. Oracle define los posibles verbos y tipos de recursos que puede utilizar en las políticas (consulte Verbo y Tipos de recursos).

En algunos casos, querrá que la política se aplique al arrendamiento y no a un compartimento dentro del arrendamiento. En ese caso, cambie el final de la sentencia de política, como por ejemplo:

Allow group <identity_domain_name>/<group_name> to <verb> <resource-type> in tenancy

Para obtener más información sobre la sintaxis, consulte Sintaxis de políticas.

Para obtener más información sobre el número de políticas que puede tener, consulte Límites de servicio.

Algunos ejemplos

Supongamos que el administrador crea un grupo denominado HelpDesk (en el dominio de identidad por defecto) cuyo trabajo es gestionar usuarios y sus credenciales. Esta es una política que permite hacerlo:

Allow group default/HelpDesk to manage users in tenancy

Tenga en cuenta que, debido a que los usuarios residen en el arrendamiento (el compartimento raíz), la política simplemente indica la palabra tenancy, sin la palabra compartment delante de ella.

A continuación, imaginemos que tiene un compartimento denominado Project-A y un grupo (en el dominio de identidad por defecto) denominado A-Admins cuyo trabajo es gestionar todos los recursos de Oracle Cloud Infrastructure del compartimento. A continuación, se muestra una política de ejemplo que permite esto:

Allow group default/A-Admins to manage all-resources in compartment Project-A

Tenga en cuenta que la política inmediatamente anterior incluye la capacidad de escribir políticas para ese compartimento, lo que significa que A-Admins puede controlar el acceso a los recursos del compartimento. Para obtener más información, consulte Anexo de políticas.

Si desea limitar el acceso de A-Admins a iniciar y gestionar instancias informáticas y volúmenes de almacenamiento de bloques (tanto los volúmenes como sus copias de seguridad) en el compartimento Project-A, pero la red en sí reside en el compartimento Networks, entonces la política podría ser:

Allow group default/A-Admins to manage instance-family in compartment Project-A

Allow group default/A-Admins to manage volume-family in compartment Project-A

Allow group default/A-Admins to use virtual-network-family in compartment Networks

La tercera sentencia con el tipo de recurso virtual-network-family activa el proceso de inicio de la instancia, porque la red en la nube está implicada. Específicamente, el proceso de inicio crea una nueva VNIC y la asocia a la subred donde reside la instancia.

Para obtener más ejemplos, consulte Políticas comunes.

Detalles sobre la especificación de grupos y compartimentos

Normalmente, en la política se especifica un grupo o compartimento por su nombre. Sin embargo, en su lugar puede utilizar el OCID. Asegúrese de agregar "id" antes del OCID. Por ejemplo:

Allow group

 id ocid1.group.oc1..aaaaaaaaqjihfhvxmumrl3isyrjw3n6c4rzwskaawuc7i5xwe6s7qmnsbc6a

 to manage instance-family in compartment Project-A

Puede especificar varios grupos separados por comas de IAM:

Allow group default/A-Admins, default/B-Admins to manage instance-family in compartment Projects-A-and-B
Nota

Si utiliza el nombre de un grupo, grupo dinámico o compartimento en una política, la política se asigna al OCID del grupo, grupo dinámico o compartimento cuando se crea la política. Si el OCID del grupo, grupo dinámico o compartimento cambia, debe recompilar una de las políticas que se aplican al grupo o compartimento para actualizar el OCID en todas las políticas.

Para recompilar la política, abra una política y realice una pequeña edición. Guarde la política.

Verbos

Oracle define los posibles verbos que puede utilizar en sus políticas. Este es un resumen de los verbos, de menor a mayor grado de acceso:

Verbo Tipos de acceso cubiertos Usuario de destino
inspect Capacidad para mostrar recursos, sin acceso a información confidencial o metadatos especificados por el usuario que pueden formar parte de ese recurso. Importante: la operación para enumerar políticas incluye el contenido de las propias políticas, y las operaciones de lista de los tipos de recursos de Networking devuelven toda la información (por ejemplo, el contenido de las listas de seguridad y las tablas de rutas). Auditores de terceros
read Incluye inspect y la capacidad de obtener metadatos especificados por el usuario y el propio recurso. Auditores internos
use Incluye read y la capacidad de trabajar con recursos existentes (las acciones varían según el tipo de recurso). Incluye la capacidad de actualizar el recurso, excepto los tipos de recursos en los que la operación "update" tiene el mismo efecto que la operación "create" (p. ej., UpdatePolicy, UpdateSecurityList, etc.), en cuyo caso la capacidad "update" solo está disponible con el verbo manage. En general, este verbo no incluye la capacidad de crear o suprimir ese tipo de recurso. Usuarios finales diarios de recursos
manage Incluye todos los permisos para el recurso. Administradores

El verbo proporciona un determinado tipo de acceso general (por ejemplo, inspect le permite enumerar y obtener recursos). Al unirse a ese tipo de acceso con un determinado tipo de recurso en una política (por ejemplo, Allow group XYZ to inspect compartments in the tenancy), le otorga a dicho grupo acceso a un juego específico de permisos y operaciones de API (por ejemplo, ListCompartments, GetCompartment). Para obtener más ejemplos, consulte Detalles de combinaciones de verbo + tipo de recurso. La referencia de política incluye una tabla similar para cada servicio, lo que le proporciona una lista de las operaciones de API cubiertas para cada combinación de verbo y tipo de recurso.

Existen algunas excepciones o matices especiales para ciertos tipos de recursos.

Usuarios: el acceso a manage users y a manage groups permite realizar cualquier acción con usuarios y grupos, incluidas la creación y la supresión de usuarios y grupos, así como la agregación/eliminación de usuarios de los grupos. Para agregar/eliminar usuarios de los grupos sin acceso a la creación y la supresión de usuarios y grupos, solo se necesita use users y use groups. Consulte Políticas comunes.

Políticas: la capacidad para actualizar una política solo está disponible con manage policies, no use policies, porque la actualización de una política es similar a la creación de una nueva política (puede sobrescribir las sentencias de política existentes). Además, inspect policies le permite obtener el contenido completo de las políticas.

Objetos de Object Storage: inspect objects permite mostrar todos los objetos de un cubo y realizar una operación HEAD para un objeto determinado. En comparación, read objects le permite descargar el objeto en sí.

Recursos del equilibrador de carga: tenga en cuenta que inspect load-balancers permite obtener toda la información sobre los equilibradores de carga y los componentes relacionados (conjuntos de backend, etc.).

Recursos de Networking:

Tenga en cuenta que el verbo inspect no solo devuelve información general sobre los componentes de la red en la nube (por ejemplo, el nombre y el OCID de una lista de seguridad o de una tabla de rutas). También incluye el contenido del componente (por ejemplo, las reglas reales en la lista de seguridad, las rutas en la tabla de rutas, etc.).

Además, los siguientes tipos de capacidades están disponibles solo con el verbo manage, no con el verbo use:

  • Actualizar (activar/desactivar) internet-gateways
  • Actualizar security-lists
  • Actualizar route-tables
  • Actualizar dhcp-options
  • Asociar un gateway de enrutamiento dinámico (DRG) a una red virtual en la nube (VCN)
  • Crear una conexión de IPSec entre un equipo de DRG y equipos locales de cliente (CPE)
  • VCN de peers
Importante

Cada VCN tiene varios componentes que afectan directamente al comportamiento de la red (tablas de rutas, listas de seguridad, opciones DHCP, gateway de Internet, etc.). Cuando crea uno de estos componentes, establece una relación entre dicho componente y la VCN, lo que significa que debe estar autorizado en una política tanto para crear el componente como para gestionar la VCN. Sin embargo, la capacidad de actualizar dicho componente (cambiar las reglas de ruta, las reglas de la lista de seguridad, etc.) NO requiere de permiso para gestionar la VCN en sí, aunque el cambio de dicho componente pueda afectar directamente al comportamiento de la red. Esta discrepancia está diseñada para proporcionarle flexibilidad a la hora de otorgar menos privilegios a los usuarios, de modo que no sea necesario que conceda un acceso excesivo a la VCN para que el usuario pueda gestionar otros componentes de la red. Tenga en cuenta que, al concederle a alguien la posibilidad de actualizar un tipo de componente en particular, está confiándole implícitamente el control del comportamiento de la red.

Tipos de recursos

Oracle también define los tipos de recursos que puede utilizar en sus políticas. En primer lugar, hay tipos individuales. Cada tipo individual representa un tipo específico de recurso. Por ejemplo, el tipo de recurso vcns se emplea específicamente para redes virtuales en la nube (VCN).

Para facilitar la escritura de políticas, hay tipos family que incluyen varios tipos de recursos individuales que se suelen gestionar juntos. Por ejemplo, el tipo virtual-network-family reúne una serie de tipos relacionados con la gestión de VCN (p. ej., vcns, subnets, route-tables, security-lists, etc.). Si necesita escribir una política más granular que solo proporcione acceso a un tipo de recurso individual, puede hacerlo. Pero también puede escribir fácilmente una política para ofrecer acceso a un rango más amplio de recursos.

En otro ejemplo: un volumen en bloque tiene volumes, volume-attachments y volume-backups. Si solo necesita conceder acceso a la realización de copias de seguridad de volúmenes, puede especificar el tipo de recurso volume-backups en la política. Sin embargo, si necesita dar acceso amplio a todos los recursos del volumen en bloque, puede especificar el tipo family denominado volume-family. Para obtener una lista completa de los tipos de recursos family, consulte Tipos de recursos.

Importante

Si un servicio introduce nuevos tipos de recursos individuales, generalmente se incluirán en el tipo family para ese servicio. Por ejemplo, si la Networking introduce un nuevo tipo de recurso individual, este se incluirá automáticamente en la definición del tipo de recurso virtual-network-family. Para obtener más información sobre futuros cambios en las definiciones de tipos de recursos, consulte Políticas y actualizaciones de servicio.

Tenga en cuenta que hay otras maneras de hacer que las políticas sean más granulares, como la capacidad de especificar las condiciones en las que se concede el acceso. Para obtener más información, consulte Funciones avanzadas de políticas.

Importante

Si un servicio introduce nuevos permisos para un tipo de recurso existente, debe actualizar la sentencia de política para el tipo de recurso existente para que se apliquen los nuevos permisos. Consulte No se propagan los nuevos permisos en los tipos de recursos para obtener más información.

Acceso que requiere varios tipos de recursos

Algunas operaciones de API requieren acceso a varios tipos de recursos. Por ejemplo, LaunchInstance requiere la capacidad de crear instancias y trabajar con una red en la nube. La operación CreateVolumeBackup requiere acceso tanto al volumen como a la copia de seguridad del volumen. Esto significa que dispondrá de sentencias específicas para otorgar acceso a cada tipo de recurso (para ver un ejemplo, consulte Permitir a los administradores de copia de seguridad de volúmenes gestionar solo copias de seguridad). Estas sentencias individuales no tienen por qué estar en la misma política. Además, un usuario puede obtener el acceso necesario al estar en diferentes grupos. Por ejemplo, George podría estar en un grupo que proporciona el nivel de acceso necesario al tipo de recurso volumes y en otro grupo que concede el acceso necesario al tipo de recurso volume-backups. La suma de las sentencias individuales, independientemente de su ubicación en el juego general de políticas, proporciona a George acceso a CreateVolumeBackup.

Herencia de políticas

Una función básica de las políticas es el concepto de herencia: los compartimentos heredan todas las políticas de su compartimento principal. El ejemplo más sencillo es el grupo Administradores, que se incluye automáticamente con su arrendamiento (consulte Grupo de administradores, política y roles de administrador). Existe una política incorporada que permite al grupo Administradores (en el dominio de identidad por defecto) realizar cualquier acción en el arrendamiento:

Allow group Administrators to manage all-resources in tenancy

Debido a la herencia de políticas, el grupo Administradores también puede realizar cualquier acción en cualquiera de los compartimentos del arrendamiento.

Para ilustrar mejor esto, piense en un arrendamiento con tres niveles de compartimentos: CompartmentA, CompartmentB y ComparmentC, que se muestran a continuación:

En la imagen se muestra CompartmentA. Jerarquía de CompartmentB y CompartmentC

Las políticas que se aplican a los recursos de CompartmentA también se aplican a los recursos de CompartmentB y CompartmentC. Por lo tanto, esta política:

Allow group default/NetworkAdmins to manage virtual-network-family in compartment CompartmentA

permite al grupo NetworkAdmins (en el dominio de identidad por defecto) gestionar las VCN en CompartmentA, CompartmentB y CompartmentC.

Asociación de políticas

Otra función básica de las políticas es el concepto de asociación. Cuando crea una política, debe asociarla a un compartimento (o al arrendamiento, que es el compartimento raíz). El lugar al que asocie los controles que pueden modificarlo o suprimirlo. Si la asocia al arrendamiento (por ejemplo, si la política está en el compartimento raíz), cualquier usuario con acceso para gestionar políticas en el arrendamiento puede cambiarla o suprimirla. Normalmente, se trata del grupo Administradores o cualquier grupo similar que se crea y al que se proporciona acceso amplio. Los usuarios que solo tengan acceso a un compartimento secundario no pueden cambiar ni suprimir esa política.

En cambio, si asocia la política a un compartimento secundario, cualquiera que tenga acceso para gestionar políticas en ese compartimento podrá cambiarla o suprimirla. En la práctica, esto significa que es fácil otorgar a los administradores de compartimento (por ejemplo, un grupo con acceso manage all-resources en el compartimento) acceso para gestionar sus propias políticas de compartimento, sin asignarles un acceso más amplio para gestionar las políticas que residan en el arrendamiento. Para ver un ejemplo que utilice este tipo de diseño de administrador de compartimento, consulte Escenario de ejemplo. (Recuerde que, debido a la herencia de políticas, los usuarios con acceso para gestionar políticas en el arrendamiento pueden gestionar automáticamente políticas en compartimentos dentro del arrendamiento).

El proceso de asociación de la política es fácil (mediante la asociación a un compartimento o al arrendamiento): si está utilizando la consola, cuando agregue la política a IAM, asegúrese de que está en el compartimento correcto al crear la política. Si utiliza la API, especifique el OCID del compartimento correcto (ya sea el arrendamiento u otro compartimento) como parte de la solicitud para crear la política.

Políticas y jerarquías de compartimentos

Como se describe en la sección anterior, una sentencia de política debe especificar el compartimento para el que se otorga acceso (o el arrendamiento). Dónde se crea la política determina quién puede actualizar la política. Si asocia la política al compartimento o a su principal, puede especificar sin más el nombre del compartimento. Si asocia la política más arriba en la jerarquía, debe especificar la ruta de acceso. El formato de la ruta de acceso es cada nombre de compartimento (o OCID) de la ruta de acceso, separado por dos puntos:

<compartment_level_1>:<compartment_level_2>: . . . <compartment_level_n>

Por ejemplo, suponga que tiene una jerarquía de compartimento de tres niveles, como se muestra aquí:

En la imagen se muestra CompartmentA. Jerarquía de CompartmentB y CompartmentC

Desea crear una política para permitir que NetworkAdmins (en el dominio de identidad por defecto) gestione las VCN en CompartmentC. Si desea asociar esta política a CompartmentC o a su principal, CompartmentB, escriba esta sentencia de política:

Allow group default/NetworkAdmins to manage virtual-network-family in compartment CompartmentC

Sin embargo, si desea asociar esta política a CompartmentA (para que solo los administradores de CompartmentA puedan modificarla), escriba esta sentencia de política que especifica la ruta de acceso:

Allow group default/NetworkAdmins to manage virtual-network-family in compartment CompartmentB:CompartmentC

Para asociar esta política al arrendamiento, escriba esta sentencia de política que especifica la ruta de acceso de CompartmentA a CompartmentC:

Allow group default/NetworkAdmins to manage virtual-network-family in compartment CompartmentA:CompartmentB:CompartmentC

Políticas y actualizaciones de servicio

Es posible que la definición de un verbo o tipo de recurso pueda cambiar en el futuro. Por ejemplo, supongamos que el recurso virtual-network-family cambia para incluir un nuevo tipo de recurso que se ha agregado a Networking. Por defecto, sus políticas se actualizan automáticamente ante cualquier cambio en la definición del servicio, por lo que cualquier política suya que acceda a virtual-network-family incluirá automáticamente el acceso al recurso recién agregado.

Importante

Si un servicio introduce nuevos permisos para un tipo de recurso existente, debe actualizar la sentencia de política para el tipo de recurso existente para que se apliquen los nuevos permisos. Consulte No se propagan los nuevos permisos en los tipos de recursos para obtener más información.

Escritura de políticas para cada servicio

La referencia de política incluye detalles de los tipos de recursos específicos para cada servicio, y qué combinación de verbo + tipo de recurso proporciona acceso a operaciones de API determinadas.