Cómo funcionan las políticas
En este tema se describe cómo funcionan las políticas y las funciones básicas.
Visión general de las políticas
Una política es un documento que especifica los usuarios que pueden acceder a recursos determinados 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 Identity and Access Management.
A continuación, se muestra el proceso genérico que debe seguir un administrador de IAM en su organización:
- Definir usuarios, grupos y uno o más compartimentos para mantener los recursos en la nube de su organización.
- Crear una o más políticas escritas en el lenguaje de la política. Consulte Políticas comunes.
- Colocar los usuarios en los grupos adecuados en función de los compartimentos y los recursos con los que necesiten trabajar.
- 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.
Aspectos 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 <group_name> to <verb> <resource-type> in compartment <compartment_name>
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 Verbos 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 <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 cuyo trabajo es gestionar usuarios y sus credenciales. Esta es una política que permite hacerlo:
Allow group 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, supongamos que tiene un compartimento denominado Project-A y un grupo 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 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 A-Admins to manage instance-family in compartment Project-A
Allow group A-Admins to manage volume-family in compartment Project-A
Allow group 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:
Allow group A-Admins, B-Admins to manage instance-family in compartment Projects-A-and-B
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 de Load Balancer: tenga en cuenta que inspect load-balancers
permite obtener toda la información sobre los equilibradores de carga y los componentes relacionados ( juegos de backends, 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
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 de familia denominado volume-family
. Para obtener una lista completa de los tipos de recursos family, consulte Tipos de recursos.
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.
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 Política y grupo Administradores). Existe una política incorporada que permite al grupo Administradores 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:
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 NewtworkAdmins to manage virtual-network-family in compartment CompartmentA
permite al grupo NetworkAdmins 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 la asocie determinará quién puede modificarla o suprimirla. Si la asocia al arrendamiento (es decir, si la política está en el compartimento raíz), cualquier usuario con acceso para gestionar políticas en el arrendamiento podrá cambiarla o suprimirla. Normalmente, se trata del grupo Administradores o cualquier grupo similar que se crea y al que se proporciona acceso amplio. Un usuario que solo tenga acceso a un compartimento secundario no puede modificar 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 (es decir, un grupo con permiso 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 tienen automáticamente la capacidad de gestionar 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, simplemente asegúrese de que está en el compartimento deseado en el momento en que crea la política. Si utiliza la API, especifique el OCID del compartimento deseado (ya sea el arrendamiento u otro compartimento) como parte de la solicitud para crear la política.
Cuando asocia una política a un compartimento, debe estar en ese compartimento y debe indicar directamente en la sentencia a qué compartimento se aplica. Si no se encuentra en el compartimento, recibirá un error si intenta asociar la política a otro compartimento diferente. Tenga en cuenta que la asociación se produce durante la creación de la política, lo que significa que una política se puede asociar solo a un compartimento. Para aprender a asociar una política a un compartimento, consulte Para crear una 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í:
Desea crear una política para permitir a NetworkAdmins gestionar 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 NewtworkAdmins 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 NewtworkAdmins 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 NewtworkAdmins 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.
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.