Descripción general del RBAC de datos

Compatible con:

El control de acceso basado en roles de datos (RBAC de datos) es un modelo de seguridad que usa roles de usuario individuales para restringir el acceso de los usuarios a los datos dentro de una organización. Con el RBAC de datos, los administradores pueden definir permisos y asignarlos a los usuarios para garantizar que estos solo puedan acceder a los datos necesarios para sus funciones laborales.

En esta página, se proporciona una descripción general del RBAC de datos y se explica cómo funcionan las etiquetas y los permisos en conjunto para definir los permisos de acceso a los datos.

Diferencia entre el RBAC de datos y el RBAC de funciones

El RBAC de datos y el RBAC de funciones son métodos para controlar el acceso dentro de un sistema, pero se enfocan en diferentes aspectos.

El RBAC de funciones controla el acceso a funciones o funcionalidades específicas dentro de un sistema. Determina a qué funciones pueden acceder los usuarios según sus roles. Por ejemplo, un analista junior podría tener acceso solo para ver paneles, pero no para crear ni modificar reglas de detección, mientras que un analista sénior podría tener los permisos para crear y administrar reglas de detección. Para obtener más información sobre el RBAC de funciones, consulta Configura el control de acceso a las funciones con la IAM.

El RBAC de datos controla el acceso a datos o información específicos dentro de un sistema. Controla si un usuario puede ver, editar o borrar datos según sus roles. Por ejemplo, en un sistema de administración de relaciones con clientes (CRM), un representante de ventas podría tener acceso a los datos de contacto de los clientes, pero no a los datos financieros, mientras que un gerente de finanzas podría tener acceso a los datos financieros, pero no a los datos de contacto de los clientes.

El RBAC de datos y el RBAC de funciones suelen usarse juntos para proporcionar un sistema integral de control de acceso. Por ejemplo, se le podría permitir a un usuario acceder a una función específica (RBAC de funciones) y, luego, dentro de esa función, se podría restringir su acceso a datos específicos según su rol (RBAC de datos).

Planifica tu implementación

Para planificar tu implementación, revisa la lista de roles y permisos predefinidos de Google SecOps de Google Security Operations predefinidos de Google SecOps y alinéalos con las necesidades de tu organización. Diseña una estrategia para definir permisos y etiquetar los datos entrantes. Asegúrate de tener el rol de visualizador de roles (roles/iam.roleViewer) para administrar los permisos. Identifica qué miembros deben tener acceso a los datos dentro de estos permisos.

Si tu organización requiere políticas de IAM más allá de los roles predefinidos de Google SecOps, crea roles personalizados para satisfacer requisitos específicos.

Funciones de usuario

Los usuarios pueden tener acceso a datos con permisos (usuarios con permisos) o acceso a datos globales (usuarios globales).

  • Los usuarios con permisos tienen acceso limitado a los datos según los permisos asignados. Estos permisos restringen su visibilidad y acciones a datos específicos. Los permisos específicos asociados con el acceso con permisos se detallan en la siguiente tabla.

  • Los usuarios globales no tienen permisos asignados y tienen acceso sin restricciones a todos los datos dentro de Google SecOps. Los permisos específicos asociados con el acceso global se detallan en la siguiente tabla.

El acceso global anula el acceso con permisos. Si a un usuario se le asignan un rol global y un rol con permisos, tendrá acceso a todos los datos, independientemente de las restricciones impuestas por el rol con permisos.

Los administradores de RBAC de datos pueden crear permisos y asignarlos a los usuarios para controlar su acceso a los datos dentro de Google SecOps. Para restringir un usuario a ciertos permisos, debes asignarle el rol de acceso a los datos restringido de la API de Chronicle (roles/chronicle.restrictedDataAccess) junto con un rol predefinido o personalizado. El rol de acceso a los datos restringido de la API de Chronicle identifica a un usuario como un usuario con permisos. No es necesario que asignes el rol de acceso a los datos restringido de Chronicle a los usuarios que necesitan acceso global a los datos.

Se pueden asignar los siguientes roles a los usuarios:

Tipo de acceso Funciones Permisos
Acceso global predefinido A los usuarios globales se les puede otorgar cualquiera de los roles de IAM predefinidos.
Acceso de solo lectura con permisos predefinidos Acceso a los datos restringido de la API de Chronicle (roles/chronicle.restrictedDataAccess) y Visualizador de acceso a los datos restringido de la API de Chronicle (roles/chronicle.restrictedDataAccessViewer) Visualizador de acceso a los datos restringido de la API de Chronicle
Acceso con permisos personalizado Acceso a los datos restringido de la API de Chronicle (roles/chronicle.restrictedDataAccess) y rol personalizado (para la definición de RBAC de funciones) Permisos personalizados dentro de las funciones
Acceso global personalizado Permiso chronicle.globalDataAccessScopes.permit y Acceso global a datos de la API de Chronicle (roles/globalDataAccess) Permisos globales dentro de las funciones

A continuación, se incluye una descripción de cada tipo de acceso que se presenta en la tabla:

Acceso global predefinido: Por lo general, este acceso es necesario para los usuarios que necesitan acceder a todos los datos. Puedes asignar uno o más roles a un usuario según los permisos necesarios.

Acceso de solo lectura con permisos predefinidos: Este acceso es para los usuarios que necesitan acceso de solo lectura. El rol de acceso a los datos restringido de la API de Chronicle identifica a un usuario como un usuario con permisos. El rol de visualizador de acceso a los datos restringido de la API de Chronicle otorga acceso de visualización a los usuarios dentro de sus funciones.

Acceso con permisos personalizado: El rol de acceso a los datos restringido de la API de Chronicle identifica a un usuario como un usuario con permisos. El rol personalizado especifica las funciones a las que puede acceder el usuario. Los permisos agregados al rol de acceso a los datos restringido de la API de Chronicle especifican los datos a los que pueden acceder los usuarios en las funciones.

Para verificar que los permisos personalizados de RBAC funcionen correctamente, incluye el permiso chronicle.dataAccessScopes.list cuando crees los roles personalizados. Sin embargo, no incluyas los permisos chronicle.DataAccessScopes.permit ni chronicle.globalDataAccessScopes.permit. Estos permisos podrían incluirse si usaste el editor de la API de Chronicle o el administrador de la API de Chronicle precompilados como punto de partida para tus roles personalizados.

Acceso global personalizado: Este acceso es para los usuarios que necesitan permisos sin restricciones dentro de las funciones asignadas. Para otorgar acceso global personalizado a un usuario, debes especificar el permiso chronicle.globalDataAccessScopes.permit además del rol personalizado que se le asigna al usuario.

Roles de usuario para paneles

El acceso a los paneles se controla mediante dos factores principales: el rol funcional de un usuario y su permiso de acceso a los datos. La combinación de estos dos elementos determina el acceso al panel. El rol asignado a un usuario cambia directamente su interfaz de usuario y capacidades disponibles. A continuación, se indican los roles predefinidos más comunes que otorgan a los usuarios acceso a los paneles:

Tipo de acceso Funciones Descripción
Visualizador roles/chroniclesiem.viewer Otorga acceso de solo lectura. Los usuarios pueden abrir todos los paneles y interactuar con ellos, pero no pueden crearlos ni editarlos.
Editor roles/chroniclesiem.editor Otorga acceso a todos los datos y todos los permisos, incluida la capacidad de crear, editar y borrar paneles personalizados.
Administrador roles/chroniclesiem.admin Otorga permisos completos, similares al rol de editor, con acceso a todos los datos.
Lector restringido roles/chroniclesiem.restrictedViewer Similar al rol de visualizador, pero todos los datos que se muestran en el panel se filtran según el permiso de registro asignado al usuario (RBAC de datos).

Para obtener más información sobre el RBAC de datos y el RBAC de funciones, consulta Diferencia entre el RBAC de datos y el RBAC de funciones.

Permisos para roles personalizados

Puedes definir permisos detallados mediante la creación de roles personalizados.

Los siguientes permisos se aplican a los paneles:

  • chronicle.dashboards.list: Permite que los usuarios vean la lista de paneles disponibles.

  • chronicle.dashboards.get: Permite que los usuarios abran y vean el contenido de un panel.

  • chronicle.dashboards.create: Permite que los usuarios creen paneles nuevos.

  • chronicle.dashboards.update: Permite que los usuarios editen y guarden los cambios en los paneles existentes.

  • chronicle.dashboards.delete: Permite que los usuarios borren paneles personalizados.

Por ejemplo, puedes crear un rol personalizado de creador de paneles solo con chronicle.dashboards.create y chronicle.dashboards.list permissions. Un usuario con este rol puede crear un panel nuevo, pero no puede editar uno existente.

Control de acceso con permisos y etiquetas

Google SecOps te permite controlar el acceso a los datos de los usuarios mediante el uso de permisos. Los permisos se definen con la ayuda de etiquetas que definen los datos a los que tiene acceso un usuario dentro del permiso. Durante la transferencia, los metadatos se asignan a los datos en forma de etiquetas, como el espacio de nombres (opcional), los metadatos de transferencia (opcional) y el tipo de registro (obligatorio). Estas son etiquetas predeterminadas que se aplican a los datos durante la transferencia. Además, puedes crear etiquetas personalizadas. Puedes usar etiquetas predeterminadas y personalizadas para definir tus permisos y el nivel de acceso a los datos que definirán los permisos.

Visibilidad de los datos con etiquetas de permiso y denegación

Cada permiso contiene una o más etiquetas de permitir acceso y, de manera opcional, etiquetas de denegar acceso. Las etiquetas de permitir acceso otorgan a los usuarios acceso a los datos asociados con la etiqueta. Las etiquetas de denegar acceso deniegan a los usuarios el acceso a los datos asociados con la etiqueta. Las etiquetas de denegar acceso anulan las etiquetas de permitir acceso para restringir el acceso del usuario.

En una definición de permiso, las etiquetas de permitir acceso del mismo tipo (por ejemplo, tipo de registro) se combinan con el operador OR, mientras que las etiquetas de diferentes tipos (por ejemplo, tipo de registro y una etiqueta personalizada) se combinan con el operador AND. Las etiquetas de denegar acceso se combinan con el operador OR. Cuando se aplican varias etiquetas de denegar acceso dentro de un permiso, se deniega el acceso si coinciden con CUALQUIERA de esas etiquetas.

Por ejemplo, considera un sistema de Cloud Logging que categoriza los registros con los siguientes tipos de etiquetas:

Tipo de registro: Access, System, Firewall

Espacio de nombres: App1, App2, Database

Gravedad: Critical, Warning

Considera un permiso llamado registros restringidos que tiene el siguiente acceso:

Tipo de etiqueta Valores permitidos Valores denegados
Tipo de registro Access, Firewall System
Espacio de nombres App1 App2, Database
Gravedad Warning Critical

La definición del permiso se ve de la siguiente manera:

Permitir: (Log type: "Access" OR "Firewall") AND (Namespace: "App1") AND (Severity: "Warning")

Denegar: Log type: "System" OR Namespace: App2 OR Namespace: Database OR Severity: "Critical"

Ejemplos de registros que coinciden con el permiso:

  • Registro de acceso de App1 con gravedad: Warning
  • Registro de firewall de App1 con gravedad: Warning

Ejemplos de registros que no coinciden con el permiso:

  • Registro del sistema de App1 con gravedad: Warning
  • Registro de acceso de la base de datos con gravedad: Warning
  • Registro de firewall de App2 con gravedad: Critical

Visibilidad de los datos en eventos enriquecidos

Los eventos enriquecidos son eventos de seguridad que se mejoraron con contexto e información adicionales más allá de lo que contienen los datos de registro sin procesar. Se puede acceder a los eventos enriquecidos dentro de un permiso solo si se puede acceder a su evento base dentro del permiso y si ninguna de las etiquetas enriquecidas incluye ninguna de las etiquetas de denegación del permiso.

Por ejemplo, considera un registro sin procesar que indica un intento de acceso fallido desde una dirección IP y tiene una etiqueta enriquecida user_risk: high (indica un usuario de alto riesgo). Un usuario con un permiso que tiene la etiqueta de denegación user_risk: high no puede ver los intentos de acceso fallidos de usuarios de alto riesgo.

Impacto del RBAC de datos en las funciones de Google Security Operations

Después de configurar el RBAC de datos, los usuarios comienzan a ver datos filtrados en las funciones de Google Security Operations. El impacto depende de cómo se integre la función con los datos subyacentes. Para comprender cómo afecta el RBAC de datos a cada función, consulta Impacto del RBAC de datos en las funciones de Google Security Operations.

¿Qué sigue?

¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.