Funciones avanzadas de políticas

Como parte de una sentencia de política, puede especificar una o más condiciones que se deben cumplir para poder otorgar acceso.

Cada condición consta de una o más variables predefinidas para las que especifica valores en la sentencia de la política. Más tarde, cuando alguien solicita acceso al recurso en cuestión, si se cumple la condición de la política, se evalúa como truey se permite la solicitud. Si no se cumple la condición, se evalúa como falsey no se permite la solicitud.

Hay dos tipos de variables: las que son relevantes para la propia solicitud y las relevantes para el recurso sobre el que se está realizando la acción en la solicitud, también denominado destino. El nombre de la variable debe llevar el prefijo request o target, según corresponda, seguido de un punto. Por ejemplo, hay una variable de solicitud llamada request.operation para representar la operación de API que se está solicitando. Esta variable permite escribir una sentencia de política amplia, pero agregar una condición basada en la operación de API específica. Para ver un ejemplo, consulte Permitir a los usuarios escribir objetos en los cubos de Object Storage.

Los permisos son las unidades atómicas de autorización que controlan la capacidad de un usuario para realizar operaciones en recursos. Oracle define todos los permisos en el lenguaje de la política. Cuando escribe una política que proporciona a un grupo acceso a un verbo y un tipo de recurso específicos, en realidad concede a ese grupo acceso a uno o más permisos predefinidos. El propósito de los verbos es simplificar el proceso de concesión de varios permisos relacionados que abarquen un amplio juego de accesos o un escenario operativo concreto. En las siguientes secciones se proporcionan más detalles y ejemplos.

En una sentencia de política se pueden utilizar condiciones combinadas con permisos u operaciones de API para reducir el ámbito de acceso otorgado por un verbo concreto.

Por ejemplo, supongamos que desea que el grupo XYZ pueda mostrar, obtener, crear o actualizar grupos (es decir, cambiar su descripción), pero no suprimirlos. Para mostrar, obtener, crear y actualizar grupos, necesita una política con manage groups como verbo y tipo de recurso. De acuerdo con la tabla de Detalles de combinaciones de verbo + tipo de recurso, los permisos cubiertos son:

• GROUP_INSPECT
• GROUP_UPDATE
• GROUP_CREATE
• GROUP_DELETE

Para restringir el acceso a los permisos deseados, podría agregar una condición que indique explícitamente los permisos que desea conceder:

Allow group XYZ to manage groups in tenancy

 where any {request.permission='GROUP_INSPECT',
            request.permission='GROUP_CREATE',
            request.permission='GROUP_UPDATE'}

Una alternativa sería una política que conceda todos los permisos, excepto GROUP_DELETE:

Allow group XYZ to manage groups in tenancy where request.permission != 'GROUP_DELETE'

Sin embargo, tenga en cuenta que, con este enfoque, cualquier nuevo permiso que el servicio pudiera agregar en el futuro se otorgará automáticamente al grupo XYZ. Solo se omitiría GROUP_DELETE.

Otra alternativa sería escribir una condición basada en las operaciones de API específicas. Tenga en cuenta que, de acuerdo con la tabla de Permisos necesarios para cada operación de API, tanto ListGroups como GetGroup necesitan solo el permiso GROUP_INSPECT. Esta sería la política:

Allow group XYZ to manage groups in tenancy

 where any {request.operation='ListGroups',  
            request.operation='GetGroup',
            request.operation='CreateGroup',
            request.operation='UpdateGroup'}

Puede ser beneficioso utilizar permisos en lugar de operaciones de API en las condiciones. En el futuro, si se agrega una nueva operación de API que requiera uno de los permisos enumerados en la política basada en permisos anterior, esa política ya controlará el acceso del grupo XYZ a esa nueva operación de API.

Sin embargo, tenga en cuenta que puede delimitar aún más el acceso de un usuario a un permiso especificando también una condición basada en una operación de API. Por ejemplo, podría dar a un usuario acceso a GROUP_INSPECT, pero solo a ListGroups.

Allow group XYZ to manage groups in tenancy

 where all {request.permission='GROUP_INSPECT',  
            request.operation='ListGroups'}

Puede restringir el acceso solo a un conjunto de direcciones IP permitidas. Por ejemplo, puede escribir una política que permita que solo las solicitudes de un rango de IP públicas determinado accedan a un cubo de Object Storage específico; o bien, puede permitir que solo subredes específicas de una VCN en particular realicen solicitudes por un gateway de servicios.

Para restringir el acceso a un conjunto de direcciones IP, realice lo siguiente:

1. Cree un objeto de origen de red que especifique las direcciones IP permitidas. Consulte Gestión de orígenes de red para obtener más información.
2. Escriba una política que utilice el objeto de origen de red en una condición.

Utilice la siguiente variable en la política:

request.networkSource.name='<network_source_name>'

Por ejemplo:

allow group GroupA to manage object-family in tenancy where request.networkSource.name='corpnet'

Puede utilizar variables basadas en el tiempo en las políticas para restringir el acceso otorgado en la política solo a determinados marcos temporales. Esta función permite restringir las acciones en los recursos a tiempos concretos. Por ejemplo, puede crear una política que permita el acceso solo hasta una fecha especificada. Una política como esta sería útil si su compañía contrata contratistas y desea asegurarse de que el acceso no esté permitido después de la fecha de finalización del contrato. O bien, puede permitir el acceso a los recursos solo durante el horario laborable (por ejemplo, de lunes a viernes de 9:00 a. m. a 5:00 p. m.). Esta restricción puede reducir el riesgo de que un mal actor realice cambios cuando es más probable que pasen desapercibidos.

Las variables que puede utilizar para definir el ámbito de acceso en función del tiempo son:

El uso de estas variables se describe con más detalle en las siguientes secciones.

Allow group Contractors to manage instance-family in tenancy where request.utc-timestamp before '2022-01-01T00:00Z'

Allow group SummerInterns to manage instance-family in tenancy where ANY {request.utc-timestamp.month-of-year in ('6', '7', '8')}

Allow group ComplianceAuditors to read all-resources in tenancy where request.utc-timestamp.day-of-month = '1'

Allow group WorkWeek to manage instance-family where ANY {request.utc-timestamp.day-of-week in ('monday', 'tuesday', 'wednesday', 'thursday', 'friday')}

Allow group DayShift to manage instance-family where request.utc-timestamp.time-of-day between '17:00:00Z' and '01:00:00Z'

Allow group NightShift to manage instance-family where request.utc-timestamp.time-of-day between '01:00:00Z' and '17:00:00Z'