Logs y grupos de logs

Utilice Oracle Cloud Infrastructure Logging para gestionar logs y grupos de logs.

Los logs contienen información de diagnóstico crítica que indica el rendimiento y el acceso a los recursos. Puede activar el registro en los recursos soportados. Para ver una lista de los recursos soportados agrupados por servicio, consulte Servicios admitidos.

Los grupos de logs son contenedores lógicos para organizar logs. Los logs siempre deben estar dentro de los grupos de logs. Debe crear un grupo de logs para activar un log.

Utilice grupos de logs para limitar el acceso a los logs confidenciales con la política de IAM. Con los grupos de logs, no tiene que depender de jerarquías de compartimento complejas para proteger los logs. Por ejemplo, supongamos que el grupo de logs por defecto de un único compartimento es donde almacena los logs para todo el arrendamiento. Puede otorgar acceso al compartimento para administradores de logs con la política de IAM como haría normalmente. Sin embargo, supongamos que algunos proyectos contienen información de identificación personal (PII) y que esos logs solo los pueden ver un grupo seleccionado de administradores de logs. Los grupos de logs le permiten poner logs que contienen PII en un grupo de logs independiente y, a continuación, utilizar la política de IAM para restringir el acceso de modo que solo un juego seleccionado de administradores de logs tenga el acceso elevado.

Política de IAM necesaria

Para que pueda utilizar Oracle Cloud Infrastructure, un administrador le debe otorgar acceso de seguridad en una política . Este acceso es necesario tanto si utiliza la Consola como la API de REST con un SDK, una CLI u otra herramienta. Si recibe un mensaje que indica que no tiene permiso o no está autorizado, verifique con el administrador el tipo de acceso que tiene y en qué compartimento debe trabajar.

Administradores: para ver ejemplos de políticas específicos de logs y grupos de logs, consulte Permisos necesarios para trabajar con logs y grupos de logs.

Si no está familiarizado con las políticas, consulte Introducción a las políticas y Políticas comunes. Si desea obtener más información sobre la escritura de políticas para Logging, consulte Detalles de Logging.

Permisos necesarios para trabajar con logs y grupos de logs

Para activar los logs de servicio en un recurso, se debe otorgar a un usuario el acceso manage en el grupo de logs y acceso al recurso. En general, el acceso de inspección en el recurso es suficiente, pero compruebe si hay recursos específicos. El acceso de inspección proporciona permiso para actualizar el recurso y permiso para el grupo de logs que contiene el log.

Los logs y los grupos de logs utilizan el tipo de recurso log-group, pero para buscar el contenido de los logs debe utilizar un tipo de recurso diferente.

Gestión de grupos de logs y objetos de log

Para gestionar grupos u objetos, utilice verbos para grupos de logs:

Allow group A to use log-groups in compartment C
Allow group B to manage log-groups in compartment C
Allow group D to read log-groups in compartment C

Esto permite a los usuarios del grupo A crear, actualizar o suprimir grupos de logs y objetos de log del compartimento C.

Para aprovisionar configuraciones de agente

Se necesitan tres tipos diferentes de acceso:

Acceso para operar en configuraciones.
Acceso para operar en grupos de logs.
Capacidades de inspección en grupos o grupos dinámicos.

Para tener acceso a las configuraciones, la política debe ser:

Allow group B to use unified-configuration in compartment X

Para crear, actualizar o suprimir logs personalizados que se utilizan como destino en una configuración

Esta política permite a los usuarios del compartimento B crear, actualizar o suprimir configuraciones del compartimento X.

Para proporcionar un destino para los logs de entrada de la configuración, necesita el acceso log-groups:

Allow group B to use log-groups in compartment X

Para asignar una configuración a un juego de instancias

Para asignar una configuración a un juego de instancias, debe inspeccionar el acceso al grupo o grupo dinámico que identifica las instancias:

Allow group B {IDENTITY_DYNAMIC_GROUP_INSPECT} in tenancy  / Allow group B {IDENTITY_GROUP_INSPECT} in tenancy

Permitir que las instancias transfieran logs al servicio de registro

Para permitir que las instancias transfieran logs, las instancias necesitan tener acceso para obtener una configuración y transferir los logs. log-content controla este permiso (donde X es el compartimento donde se ubican las configuraciones):

Allow dynamic-group production-fleet to use log-content in compartment X

Para ver los logs

Para ver los logs en la consola (Buscar), se requiere lo siguiente:

Allow group Searchers to read log-content in compartment X

Ejemplo de política de búsqueda de logs

Para permitir que un grupo lea el contenido de los logs indexados:

allow group GroupA to read log-groups in tenancy
allow group GroupA to read log-content in tenancy

Políticas de ejemplo para logs y grupos de logs

En estos ejemplos, las sentencias de política utilizan GroupA como nombre del grupo.

Para permitir que un grupo vea los grupos de logs del arrendamiento (o en un compartimento), necesita el acceso inspect:

allow group GroupA to inspect log-groups in tenancy

Para permitir que un grupo lea metadatos de logs o grupos de logs, necesita el acceso read:

allow group GroupA to read log-groups in tenancy

Para permitir que un grupo actualice grupos de logs o los logs que contienen, necesita el acceso use:

allow group GroupA to use log-groups in tenancy

Para activar un log en un recurso (o para crear y suprimir grupos de logs y los logs que contienen), necesita el acceso manage:

allow group GroupA to manage log-groups in tenancy

Para permitir el uso de grupos o grupos de logs específicos, utilice una cláusula where con la variable target.loggroup.id. Por ejemplo:

Allow group GroupA to manage loggroups in tenancy where 
target.loggroup.id='ocid1.loggroup.oc1.phx.<uniqueID>'

Para especificar varios grupos de logs:

Allow group GroupA to manage log-groups in tenancy where any {target.loggroup.id='ocid1.loggroup'}

Logs personalizados

Para los logs personalizados, se requiere lo siguiente. Esta política es necesaria para permitir al usuario buscar logs en la página Buscar de la consola:

allow group userGroup1 to read log-content in compartment c

Nota

Aunque esta política se describe para su uso con logs personalizados, la política también se aplica para todos los logs. LOG_CONTENT_READ permite leer logs de logs personalizados y del servicio de OCI. Es idéntico en su comportamiento a esta política:

allow group GroupA to read log-content in tenancy

Se necesita lo siguiente para que el agente que utiliza el principal de instancia en la máquina virtual envíe logs:

allow dynamic-group dynamicgroup1 to use log-content in compartment c

Nota

Si está utilizando un grupo de usuarios en lugar de un grupo dinámico para transferir logs personalizados, sustituya el nombre del grupo dinámico por el nombre del grupo de usuarios en estas políticas.

Para los logs personalizados, si utiliza allow dynamic-group dynamicGroup1 to use log-content in compartment c, las instancias de ese grupo dinámico obtienen permiso para descargar la configuración y enviar logs, y pueden buscar logs.

Requisitos de política de IAM para recursos

Además de los permisos para trabajar con el grupo de logs, para agregar logs de servicio a un recurso, debe tener el permiso de actualización para el recurso. En muchos recursos, el permiso de actualización se otorga con el verbo use. Por ejemplo, los usuarios que pueden usar (use) cubos de CompartmentA también pueden activar el registro en un cubo de CompartmentA.

Sin embargo, algunos recursos no incluyen permiso para actualizar un recurso con el verbo use. Por ejemplo, para actualizar una regla para el servicio Events, debe tener el permiso manage completo. Para activar un log en una regla de Events (o cualquier otro recurso que no incluya el permiso de actualización con el verbo use), debe tener el permiso manage.

Para permitir que un grupo active el registro de estos recursos, sin otorgar permisos manage completos, puede agregar una sentencia de política para otorgar solo el permiso <RESOURCE>_UPDATE (o, en el caso del servicio Events, <RESOURCE>_MODIFY) del verbo manage. Por ejemplo, para permitir que un grupo EventUsers active logs en reglas de Events en CompartmentA, podría escribir una política como la siguiente:

Allow group EventUsers to read cloudevents-rules in compartment CompartmentA
Allow group EventUsers to manage cloudevents-rules in compartment CompartmentA 
 where request.permission='EVENTRULE_MODIFY'

Para obtener información sobre los permisos de recursos, consulte Referencia de política.

Política de IAM de logs de flujo de VCN

Además de los Permisos necesarios para trabajar con logs y grupos de logs, se necesitan permisos de lectura y actualización de subred para gestionar logs de flujo de VCN.

Para proporcionar permisos de subred, utilice una de las siguientes políticas, enumeradas por orden de más a menos privilegios:

Allow group FlowLogsEnablers to manage virtual-network-family in tenancy

O bien:

Allow group FlowLogsEnablers to manage subnets in tenancy

O bien:

Allow group FlowLogsEnablers to {SUBNET_READ, SUBNET_UPDATE} in tenancy

Este grupo es similar a la descripción de EventUsers en Requisitos de política de IAM para recursos.

Escenario de ejemplo

Su compañía tiene un departamento Operations. Dentro del departamento Operations hay varios centros de costos. Usted desea poder etiquetar los recursos que pertenezcan al departamento Operations con el centro de costos adecuado.

Cree un grupo de logs denominado "confidential". Evite introducir información confidencial.
Agregue logs con datos confidenciales al grupo de logs "confidential".

Un empleado denominado Alice ya pertenece al grupo BucketManagers. Alice puede gestionar cubos en CompartmentA. Usted desea que Alice y otros miembros del grupo BucketManagers puedan activar logs en cubos de CompartmentA.

Para otorgar al grupo BucketManagers acceso al grupo de logs de datos confidenciales (y solo al grupo de logs de datos confidenciales), agregue las siguientes sentencias a la política BucketManagers:

Allow group BucketManagers to manage log-groups in compartment CompartmentA where 
target.loggroups.id='ocid1.lumloggroup.oc1.phx.<uniqueID>'

Ahora, Alice puede activar logs en recursos de cubo en CompartmentA.

Nombres de log y grupo de logs

Para los nombres de grupo de logs, el primer carácter debe empezar por una letra. De lo contrario, se aplican las siguientes directrices a los nombres de log y grupo de logs:

Utilice entre 1 y 256 caracteres.
Los caracteres válidos son letras (mayúsculas o minúsculas), números, guiones, caracteres de subrayado y puntos.
Los nombres de log y grupo de logs son sensibles a mayúsculas/minúsculas. El registro gestiona write-log and WRITE-log como logs independientes.
Evite introducir información confidencial.