Administración del acceso a las áreas de trabajo de Log Analytics

Los datos de un área de trabajo de Log Analytics a los que puede acceder están determinados por una combinación de los siguientes factores:

  • Configuración de la propia área de trabajo.
  • Acceso a los recursos que envían datos al área de trabajo.
  • Método utilizado para acceder al área de trabajo.

En este artículo se describe cómo se administra el acceso y cómo se realiza cualquier configuración necesaria.

Información general

Los factores que definen los datos a los que puede acceder se describen en la tabla siguiente. Cada factor se describe con más detalle en las secciones siguientes.

Factor Descripción
Modo de acceso Método utilizado para acceder al área de trabajo. Define el ámbito de los datos disponibles y el modo de control de acceso que se aplica.
Modo de control de acceso Configuración en el área de trabajo que define si los permisos se aplican en el nivel de área de trabajo o recurso.
Control de acceso basado en rol (RBAC) de Azure Permisos aplicados a usuarios individuales o grupos de usuarios para el área de trabajo o el recurso que envía datos al área de trabajo. Define los datos a los que tendrá acceso.
Permiso de Azure RBAC de nivel de tabla Permisos opcionales que definen los tipos de datos específicos del área de trabajo a los que puede acceder. Se aplican a todos los usuarios independientemente de su modo de acceso o su modo de control de acceso.

Modo de acceso

El modo de acceso hace referencia a cómo accede a un área de trabajo de Log Analytics y define los datos a los que puede tener acceso durante la sesión actual. El modo se determina según el ámbito que seleccione en Log Analytics.

Hay dos modos de acceso:

  • Contexto del área de trabajo: puede ver todos los registros del área de trabajo para los que tenga permiso. Las consultas en este modo se limitan a todos los datos de todas las tablas en el área de trabajo. Este es el modo de acceso utilizado cuando se accede a los registros con el área de trabajo como ámbito, como cuando se selecciona Registros desde el menú Azure Monitor en Azure Portal.
  • Contexto del recurso: al acceder al área de trabajo para un recurso, un grupo de recursos o una suscripción determinados (por ejemplo, cuando se selecciona Registros en un menú de recursos de Azure Portal), puede ver los registros solo de los recursos de todas las tablas a las que tiene acceso. Las consultas de este modo se limitan solo a los datos asociados a ese recurso. Este modo también permite Azure RBAC pormenorizado. Las áreas de trabajo usan un modelo de registro de contexto del recurso donde cada entrada del registro emitida por un recurso de Azure se asocia automáticamente a este recurso.

Los registros solo están disponibles en las consultas del contexto del recurso si están asociados al recurso pertinente. Para comprobar esta asociación, ejecute una consulta y compruebe que se haya rellenado la columna _ResourceId.

Existen limitaciones conocidas con los siguientes recursos:

Comparación de los modos de acceso

En la tabla siguiente se resumen los modos de acceso:

Incidencia Contexto del área de trabajo Contexto del recurso
¿Para quién está pensado cada modelo? Administración central.
Los administradores que tienen que configurar colecciones de datos y los usuarios que necesitan acceder a una amplia variedad de recursos. También lo requieren actualmente los usuarios que necesitan acceder a registros de recursos fuera de Azure.
Equipos de la aplicación.
Los administradores de los recursos de Azure que se están supervisando. Les permite centrarse en su recurso sin filtrar.
¿Qué requiere un usuario para ver los registros? Permisos para el área de trabajo.
Consulte "Permisos del área de trabajo" en Administración del acceso mediante permisos del área de trabajo.
Acceso de lectura al recurso.
Consulte "Permisos de recurso" en Administración del acceso mediante permisos de Azure. Los permisos se pueden heredar del grupo de recursos o suscripción o asignar directamente al recurso. Se asignará automáticamente el permiso a los registros para el recurso. El usuario no requiere acceso al área de trabajo.
¿Qué es el ámbito de los permisos? Área de trabajo.
Los usuarios con acceso al área de trabajo pueden consultar todos los registros del área de trabajo desde las tablas para las que tengan permisos. Consulte Establecimiento del acceso de lectura de nivel de tabla.
Recurso de Azure.
Un usuario puede consultar los registros de recursos, grupos de recursos o suscripciones específicos a los que tenga acceso en cualquier área de trabajo, pero no puede consultar los registros de otros recursos.
¿Cómo puede el usuario acceder a los registros? Seleccione Registros en el menú Azure Monitor.

Seleccione Registros desde las áreas de trabajo de Log Analytics.

Desde los libros de Azure Monitor.
Seleccione Registros en el menú del recurso de Azure. Los usuarios tendrán acceso a los datos de ese recurso.

Seleccione Registros en el menú Azure Monitor. Los usuarios tendrán acceso a los datos de todos los recursos a los que tengan acceso.

Seleccione Registros desde las áreas de trabajo de Log Analytics. Los usuarios tendrán acceso a los datos de todos los recursos a los que tengan acceso.

Desde los libros de Azure Monitor.

Modo de control de acceso

El modo de control de acceso es una configuración de cada área de trabajo que define cómo se determinan los permisos para el área de trabajo.

  • Requerir permisos de área de trabajo. Este modo de control no admite RBAC granular de Azure. Para acceder al área de trabajo, el usuario debe tener permisos concedidos en el área de trabajo o en tablas específicas.

    Si un usuario accede al área de trabajo en el modo de contexto del área de trabajo, tendrá acceso a todos los datos de todas las tablas a las que se le haya concedido acceso. Si un usuario accede al área de trabajo en el modo de contexto del recurso, tendrá acceso solo a los datos de ese recurso en todas las tablas a las que se le haya concedido acceso.

    Es la configuración predeterminada para todas las áreas de trabajo creadas antes de marzo de 2019.

  • Usar permisos de recurso o de área de trabajo. este modo de control permite Azure RBAC granular. A los usuarios se les puede conceder acceso solo a los datos asociados a los recursos que pueden ver mediante la asignación del permiso read de Azure.

    Cuando un usuario accede al área de trabajo en modo contexto del área de trabajo, se aplican los permisos del área de trabajo. Cuando un usuario accede al área de trabajo en modo contexto del recurso, solo se comprueban los permisos de los recursos y se omiten los del área de trabajo. Para habilitar Azure RBAC para un usuario, quítelos de los permisos del área de trabajo y permita que sus permisos de recursos sean reconocidos.

    Es la configuración predeterminada para todas las áreas de trabajo creadas después de marzo de 2019.

    Nota

    Si un usuario solo tiene permisos de recurso en el área de trabajo, solo podrá acceder al área de trabajo mediante el modo de contexto de recurso, siempre que el modo de acceso al área de trabajo esté establecido en Usar permisos de recurso o de área de trabajo.

Configuración del modo de control de acceso para un área de trabajo

Vea el modo de control de acceso del área de trabajo actual en la página Introducción del área de trabajo en el menú Área de trabajo de Log Analytics.

Captura de pantalla que muestra el modo de control de acceso al área de trabajo.

Cambie esta configuración en la página Propiedades del área de trabajo. Si no tiene permisos para configurar el área de trabajo, el cambio de la configuración está deshabilitado.

Captura de pantalla que muestra el cambio del modo de acceso al área de trabajo.

Azure RBAC

El acceso a un área de trabajo se administra mediante RBAC de Azure. Para conceder acceso al área de trabajo de Log Analytics mediante permisos de Azure, siga los pasos que se describen en Asignación de roles de Azure para administrar el acceso a los recursos de la suscripción de Azure.

Permisos de área de trabajo

Cada área de trabajo puede tener varias cuentas asociadas. Cada cuenta puede acceder a varias áreas de trabajo. En la tabla siguiente se enumeran los permisos de Azure para las diferentes acciones del área de trabajo:

Acción Permisos de Azure necesarios Notas
Cambiar el plan de tarifa. Microsoft.OperationalInsights/workspaces/*/write
Creación de un área de trabajo en Azure Portal. Microsoft.Resources/deployments/*
Microsoft.OperationalInsights/workspaces/*
Ver las propiedades básicas del área de trabajo y entrar al panel del área de trabajo en el portal. Microsoft.OperationalInsights/workspaces/read
Consultar los registros con cualquier interfaz. Microsoft.OperationalInsights/workspaces/query/read
Acceder a todos los tipos de registros mediante consultas. Microsoft.OperationalInsights/workspaces/query/*/read
Acceder a una tabla de registro específica. Microsoft.OperationalInsights/workspaces/query/<table_name>/read
Leer las claves del área de trabajo para permitir el envío de registros a esta área de trabajo. Microsoft.OperationalInsights/workspaces/sharedKeys/action
Agregar y quitar soluciones de supervisión. Microsoft.Resources/deployments/*
Microsoft.OperationalInsights/*
Microsoft.OperationsManagement/*
Microsoft.Automation/*
Microsoft.Resources/deployments/*/write

Es necesario conceder estos permisos en el nivel de suscripción o grupo de recursos.
Ver datos en los iconos de las soluciones Backup y Site Recovery. Administrador o coadministrador

Accede a los recursos implementados mediante el modelo de implementación clásica.

Roles integrados

Asigne usuarios a estos roles para concederles acceso en distintos ámbitos:

  • Suscripción: acceso a todas las áreas de trabajo de la suscripción
  • Grupo de recursos: acceso a todas las áreas de trabajo del grupo de recursos
  • Recurso: acceso solo al área de trabajo especificada

Cree asignaciones en el nivel de recurso (área de trabajo) para asegurarse de que el control de acceso es preciso. Use roles personalizados para crear roles con los permisos específicos necesarios.

Nota:

Para agregar y quitar usuarios de un rol de usuario, debe tener los permisos Microsoft.Authorization/*/Delete y Microsoft.Authorization/*/Write.

Lector de Log Analytics

Los miembros del rol Lector de Log Analytics pueden ver todos los datos y la configuración de supervisión, incluida la configuración de Azure Diagnostics en todos los recursos de Azure.

Los miembros del rol Lector de Log Analytics pueden:

  • Ver y buscar todos los datos de supervisión.
  • Ver la configuración de supervisión, incluida la visualización de la configuración de Azure Diagnostics en todos los recursos de Azure.

El rol Lector de Log Analytics incluye las siguientes acciones de Azure:

Tipo Permiso Descripción
Acción */read Capacidad para ver todos los recursos de Azure y la configuración de los recursos.
Incluye la visualización de:
- Estado de la extensión de máquina virtual.
- Configuración de diagnósticos de Azure en los recursos.
- Todas las propiedades y configuraciones de todos los recursos

En el caso de las áreas de trabajo, permite permisos completos sin restricciones para leer la configuración del área de trabajo y consultar los datos. Consulte opciones más detalladas en la lista anterior.
Acción Microsoft.Support/* Capacidad de abrir casos de soporte técnico.
No acción Microsoft.OperationalInsights/workspaces/sharedKeys/read Evita la lectura de la clave del área de trabajo necesaria para usar la API de recopilación de datos e instalar agentes. Esto impide que el usuario agregue nuevos recursos al área de trabajo.
Acción Microsoft.OperationalInsights/workspaces/analytics/query/action En desuso.
Acción Microsoft.OperationalInsights/workspaces/search/action En desuso.

Colaborador de Log Analytics

Los miembros del rol Colaborador de Log Analytics pueden:

  • Leer todos los datos de supervisión concedidos por el rol de lector de Log Analytics.
  • Editar la configuración de supervisión de los recursos de Azure, lo que incluye:
    • Agregar la extensión de máquina virtual a las máquinas virtuales.
    • Configurar los diagnósticos de Azure en todos los recursos de Azure.
  • Crear y configurar cuentas de Automation. Los permisos se deben conceder en el nivel de suscripción o grupo de recursos.
  • Agregar y eliminar soluciones de administración. Los permisos se deben conceder en el nivel de suscripción o grupo de recursos.
  • Leer las claves de la cuenta de almacenamiento.
  • Configurar la recopilación de registros de Azure Storage.
  • Configure reglas de exportación de datos.
  • Ejecute un trabajo de búsqueda.
  • Restaure registros archivados.

Advertencia

Puede usar el permiso a fin de agregar una extensión de máquina virtual a una máquina virtual para obtener el control total sobre una máquina virtual.

El rol Colaborador de Log Analytics incluye las siguientes acciones de Azure:

Permiso Descripción
*/read Capacidad para ver todos los recursos de Azure y la configuración de los recursos.

Incluye la visualización de:
- Estado de la extensión de máquina virtual.
- Configuración de diagnósticos de Azure en los recursos.
- Todas las propiedades y configuraciones de todos los recursos

En el caso de las áreas de trabajo, permite permisos completos sin restricciones para leer la configuración del área de trabajo y consultar los datos. Consulte opciones más detalladas en la lista anterior.
Microsoft.Automation/automationAccounts/* Capacidad para crear y configurar cuentas de Azure Automation, incluido agregar y editar runbooks.
Microsoft.ClassicCompute/virtualMachines/extensions/*
Microsoft.Compute/virtualMachines/extensions/*
Agregar, actualizar y eliminar extensiones de máquina virtual, incluida la extensión de Microsoft Monitoring Agent y el agente de OMS para la extensión de Linux.
Microsoft.ClassicStorage/storageAccounts/listKeys/action
Microsoft.Storage/storageAccounts/listKeys/action
Ver la clave de la cuenta de almacenamiento. Necesaria para configurar Log Analytics para leer los registros de las cuentas de Azure Storage.
Microsoft.Insights/alertRules/* Agregar, actualizar y eliminar reglas de alertas.
Microsoft.Insights/diagnosticSettings/* Agregar, actualizar y eliminar la configuración de diagnósticos en los recursos de Azure.
Microsoft.OperationalInsights/* Agregar, actualizar y eliminar la configuración de áreas de trabajo de Log Analytics. Para editar la configuración avanzada del área de trabajo, el usuario necesita Microsoft.OperationalInsights/workspaces/write.
Microsoft.OperationsManagement/* Agregar y eliminar soluciones de administración.
Microsoft.Resources/deployments/* Crear y eliminar implementaciones. Necesario para agregar y eliminar soluciones, áreas de trabajo y cuentas de Automation.
Microsoft.Resources/subscriptions/resourcegroups/deployments/* Crear y eliminar implementaciones. Necesario para agregar y eliminar soluciones, áreas de trabajo y cuentas de Automation.

Permisos de recurso

Cuando los usuarios consulten los registros desde un área de trabajo mediante el acceso de contexto de recurso, tendrán los siguientes permisos en el recurso:

Permiso Descripción
Microsoft.Insights/logs/<tableName>/read

Ejemplos:
Microsoft.Insights/logs/*/read
Microsoft.Insights/logs/Heartbeat/read
Capacidad para ver todos los datos de registro del recurso
Microsoft.Insights/diagnosticSettings/write Capacidad para configurar diagnósticos a fin de permitir la configuración de los registros de este recurso

El permiso /read se suele conceder desde un rol que incluye los permisos */read o* como los roles integrados Lector y Colaborador. Los roles personalizados que contienen acciones específicas o roles integrados dedicados no incluyen este permiso.

Roles personalizados de ejemplo

Además de usar los roles integrados para un área de trabajo de Log Analytics, puede crear roles personalizados para asignar permisos más pormenorizados. Estos son algunos ejemplos comunes.

Ejemplo 1: Conceder a un usuario acceso a los datos de registro desde sus recursos.

  • Configure el modo de control de acceso del área de trabajo para usar permisos de recursos o áreas de trabajo.
  • Conceda a los usuarios los permisos */read o Microsoft.Insights/logs/*/read a sus recursos. Si ya se les ha asignado el rol Lector de Log Analytics en el área de trabajo, es suficiente.

Ejemplo 2: Conceder a los usuarios acceso a los datos de registro desde sus recursos y configurar sus recursos para que envíen registros al área de trabajo.

  • Configure el modo de control de acceso del área de trabajo para usar permisos de recursos o áreas de trabajo.
  • Conceda a los usuarios los permisos siguientes en el área de trabajo: Microsoft.OperationalInsights/workspaces/read y Microsoft.OperationalInsights/workspaces/sharedKeys/action. Con estos permisos, los usuarios no pueden realizar consultas en el nivel de área de trabajo. Solo pueden enumerar el área de trabajo y usarla como destino para la configuración de diagnóstico o del agente.
  • Conceda a los usuarios los permisos siguientes a sus recursos: Microsoft.Insights/logs/*/read y Microsoft.Insights/diagnosticSettings/write. Si ya se les ha asignado el rol Colaborador de Log Analytics, el rol Lector o se les ha concedido permisos */read en este recurso, es suficiente.

Ejemplo 3: Conceder a un usuario acceso a los datos de registro desde sus recursos sin la capacidad de leer eventos de seguridad y enviar datos.

  • Configure el modo de control de acceso del área de trabajo para usar permisos de recursos o áreas de trabajo.
  • Conceda a los usuarios los permisos siguientes a sus recursos: Microsoft.Insights/logs/*/read.
  • Agregue el atributo NonAction siguiente para impedir que los usuarios lean el tipo SecurityEvent: Microsoft.Insights/logs/SecurityEvent/read. El atributo NonAction debe estar en el mismo rol personalizado que la acción que proporciona el permiso de lectura (Microsoft.Insights/logs/*/read). Si el usuario hereda la acción de lectura de otro rol asignado a este recurso, a la suscripción o al grupo de recursos, podrá leer todos los tipos de registro. Esto también ocurre si hereda un permiso */read que ya existe, por ejemplo, con el rol Lector o Colaborador.

Ejemplo 4: Conceder a un usuario acceso a los datos de registro desde sus recursos y leer todos los datos de registro de inicio de sesión de Azure AD y de la solución Update Management desde el área de trabajo.

  • Configure el modo de control de acceso del área de trabajo para usar permisos de recursos o áreas de trabajo.
  • Conceda a los usuarios los permisos siguientes en el área de trabajo:
    • Microsoft.OperationalInsights/workspaces/read: necesario para que el usuario pueda enumerar el área de trabajo y abrir el panel del área de trabajo en Azure Portal
    • Microsoft.OperationalInsights/workspaces/query/read: necesario para todos los usuarios que pueden ejecutar consultas
    • Microsoft.OperationalInsights/workspaces/query/SigninLogs/read: para poder leer los registros de inicio de sesión de Azure AD
    • Microsoft.OperationalInsights/workspaces/query/Update/read: para poder leer los registros de la solución Update Management
    • Microsoft.OperationalInsights/workspaces/query/UpdateRunProgress/read: para poder leer los registros de la solución Update Management
    • Microsoft.OperationalInsights/workspaces/query/UpdateSummary/read: para poder leer los registros de Update Management
    • Microsoft.OperationalInsights/workspaces/query/Heartbeat/read: necesario para poder usar las soluciones de Update Management
    • Microsoft.OperationalInsights/workspaces/query/ComputerGroup/read: necesario para poder usar las soluciones de Update Management
  • Conceder a los usuarios los permisos siguientes para sus recursos: */read, asignado al rol Lector, o Microsoft.Insights/logs/*/read

Establecimiento del acceso de lectura de nivel de tabla

Los roles personalizados de Azure permiten conceder a usuarios o grupos específicos acceso a tablas específicas del área de trabajo. Los roles personalizados de Azure se aplican a las áreas de trabajo con los modos de control de acceso de contexto de área de trabajo o de recurso, independientemente del modo de acceso del usuario.

Para definir el acceso a una tabla determinada, cree un rol personalizado:

  • Establezca los permisos de usuario en la sección Acciones de la definición de roles.
  • Use Microsoft.OperationalInsights/workspaces/query/* para conceder acceso a todas las tablas.
  • Para excluir el acceso a tablas específicas cuando se usa un carácter comodín en Acciones, enumere las tablas excluidas en la sección NotActions de la definición de rol.

Ejemplos

Estos son ejemplos de acciones de rol personalizadas para conceder y denegar el acceso a tablas específicas.

Conceder acceso a las tablas Heartbeat y AzureActivity:

"Actions":  [
    "Microsoft.OperationalInsights/workspaces/read",
    "Microsoft.OperationalInsights/workspaces/query/read",
    "Microsoft.OperationalInsights/workspaces/query/Heartbeat/read",
    "Microsoft.OperationalInsights/workspaces/query/AzureActivity/read"
  ],

Conceder acceso solo a la tabla SecurityBaseline:

"Actions":  [
    "Microsoft.OperationalInsights/workspaces/read",
    "Microsoft.OperationalInsights/workspaces/query/read",
    "Microsoft.OperationalInsights/workspaces/query/SecurityBaseline/read"
],

Conceder acceso a todas las tablas excepto a la tabla SecurityAlert:

"Actions":  [
    "Microsoft.OperationalInsights/workspaces/read",
    "Microsoft.OperationalInsights/workspaces/query/read",
    "Microsoft.OperationalInsights/workspaces/query/*/read"
],
"notActions":  [
    "Microsoft.OperationalInsights/workspaces/query/SecurityAlert/read"
],

Tablas personalizadas

Las tablas personalizadas almacenan datos que se recopilan de orígenes de datos, como registros de texto y la API del recopilador de datos HTTP. Para identificar el tipo de tabla, vea la información de la tabla en Log Analytics.

Nota:

Las tablas creadas por la API de ingesta de registros aún no admiten RBAC de nivel de tabla.

No se puede conceder el acceso a tablas de registros personalizados individuales, pero puede conceder el acceso a todos los registros personalizados. Para crear un rol con acceso a todas las tablas de registros personalizados, cree un rol personalizado con las siguientes acciones:

"Actions":  [
    "Microsoft.OperationalInsights/workspaces/read",
    "Microsoft.OperationalInsights/workspaces/query/read",
    "Microsoft.OperationalInsights/workspaces/query/Tables.Custom/read"
],

Un enfoque alternativo para administrar el acceso a los registros personalizados es asignarlos a un recurso de Azure y administrar el acceso mediante el control de acceso del contexto de recurso. Incluya el identificador de recurso; para ello, debe especificarlo en el encabezado x-ms-AzureResourceId cuando se ingieran los datos en Log Analytics mediante la API del recopilador de datos HTTP. El identificador de recurso debe ser válido y tener reglas de acceso aplicadas. Una vez ingeridos los registros, son accesibles para los usuarios con acceso de lectura al recurso.

Algunos registros personalizados proceden de orígenes que no están directamente asociados a un recurso específico. En este caso, cree un grupo de recursos para administrar el acceso a estos registros. El grupo de recursos no incurre en ningún costo, pero proporciona un identificador de recurso válido para controlar el acceso a los registros personalizados.

Por ejemplo, si un firewall específico envía registros personalizados, cree un grupo de recursos llamado MyFireWallLogs. Asegúrese de que las solicitudes de API contengan el identificador de recurso de MyFireWallLogs. De este modo, las entradas del registro del firewall son accesibles solo para los usuarios a los que se ha concedido acceso a MyFireWallLogs o para aquellos usuarios con acceso completo al área de trabajo.

Consideraciones

  • Si se concede a un usuario permiso de lectura global con los roles Lector o Colaborador estándar que incluyen la acción */read, invalidará el control de acceso por tabla y les otorgará acceso a todos los datos de registro.
  • Si se concede a un usuario el permiso de acceso para cada tabla, pero ningún otro, el usuario puede acceder a los datos de registro de la API, pero no desde Azure Portal. Para proporcionar acceso desde Azure Portal, use Lector de Log Analytics como su rol base.
  • Los administradores y propietarios de la suscripción tendrán acceso a todos los tipos de datos, independientemente de cualquier otra configuración de permisos.
  • Los propietarios del área de trabajo son tratados como cualquier otro usuario para controlar el acceso por tabla.
  • Asigne roles a los grupos de seguridad en lugar de usuarios individuales para reducir el número de asignaciones. Este procedimiento también le ayudará a usar las herramientas de administración de grupos existentes para configurar y comprobar el acceso.

Pasos siguientes