Información general sobre el control de acceso basado en roles de datos

Disponible en:

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 de una organización. Con el RBAC de datos, los administradores pueden definir ámbitos y asignarlos a los usuarios para asegurarse de que estos solo puedan acceder a los datos necesarios para sus funciones.

En esta página se ofrece una descripción general del control de acceso basado en roles 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 control de acceso basado en roles de datos y el control de acceso basado en roles de funciones

El control de acceso basado en roles de datos y el control de acceso basado en roles de funciones son dos métodos para controlar el acceso en un sistema, pero se centran en aspectos diferentes.

El RBAC de funciones controla el acceso a funciones o características específicas de un sistema. Determina a qué funciones pueden acceder los usuarios en función de sus roles. Por ejemplo, un analista junior solo puede ver los paneles de control, pero no crear ni modificar reglas de detección, mientras que un analista sénior puede crear y gestionar reglas de detección. Para obtener más información sobre el control de acceso basado en roles de funciones, consulta el artículo Configurar el control de acceso a funciones con la gestión de identidades y accesos.

El control de acceso basado en roles de datos controla el acceso a datos o información específicos de un sistema. Controla si un usuario puede ver, editar o eliminar datos en función de sus roles. Por ejemplo, en un sistema de gestión de relaciones con los clientes (CRM), un representante de ventas puede tener acceso a los datos de contacto de los clientes, pero no a los datos financieros, mientras que un responsable de finanzas puede 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 se suelen usar juntos para proporcionar un sistema de control de acceso completo. Por ejemplo, se puede permitir que un usuario acceda a una función específica (control de acceso basado en roles de funciones) y, dentro de esa función, se puede restringir su acceso a datos específicos en función de su rol (control de acceso basado en roles de datos).

Planificar la implementación

Para planificar tu implementación, consulta la lista de roles y permisos predefinidos de Google SecOps y adáptalos a las necesidades de tu organización. Diseña una estrategia para definir los permisos y etiquetar los datos entrantes. Asegúrese de que tiene el rol Lector de roles (roles/iam.roleViewer) para gestionar los ámbitos. Identifica qué miembros deben tener acceso a los datos de estos ámbitos.

Si tu organización necesita políticas de gestión de identidades y accesos que vayan más allá de los roles de SecOps predefinidos de Google, crea roles personalizados para satisfacer requisitos específicos.

Funciones de usuario

Los usuarios pueden tener acceso a datos concretos (usuarios con acceso limitado) o acceso a todos los datos (usuarios con acceso global).

  • Los usuarios con permisos tienen acceso limitado a los datos en función de los permisos asignados. Estos permisos restringen su visibilidad y sus acciones a datos específicos. En la siguiente tabla se detallan los permisos específicos asociados al acceso limitado.

  • Los usuarios globales no tienen ningún permiso asignado y tienen acceso sin restricciones a todos los datos de Google SecOps. En la siguiente tabla se detallan los permisos específicos asociados al acceso global.

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

Los administradores del control de acceso basado en roles de datos pueden crear ámbitos y asignarlos a los usuarios para controlar su acceso a los datos en Google SecOps. Para restringir el acceso de un usuario a determinados permisos, debes asignarle el rol de acceso restringido a datos de la API de Chronicle (roles/chronicle.restrictedDataAccess) junto con un rol predefinido o personalizado. El rol de acceso a datos restringidos de la API de Chronicle identifica a un usuario como usuario con ámbito. No es necesario que asignes el rol de acceso a datos restringidos de Chronicle a los usuarios que necesiten acceso a datos globales.

Se pueden asignar los siguientes roles a los usuarios:

Tipo de acceso Roles Permisos
Acceso global predefinido A los usuarios globales se les puede conceder cualquiera de los roles de gestión de identidades y accesos predefinidos.
Acceso de solo lectura predefinido Acceso a datos restringidos de la API de Chronicle (roles/chronicle.restrictedDataAccess) y lector de acceso a datos restringidos de la API de Chronicle (roles/chronicle.restrictedDataAccessViewer) Visor de acceso a datos restringidos de la API de Chronicle
Acceso personalizado con ámbito Acceso a datos restringidos de la API Chronicle (roles/chronicle.restrictedDataAccess) y rol personalizado (para la definición de RBAC de funciones) Permisos personalizados en las funciones
Acceso global personalizado Permiso chronicle.globalDataAccessScopes.permit y acceso global a datos de la API de Chronicle (roles/globalDataAccess) Permisos globales en las funciones

A continuación, se describe cada tipo de acceso que se muestra en la tabla:

Acceso global predefinido: este acceso suele ser necesario para los usuarios que necesitan acceder a todos los datos. Puedes asignar uno o varios roles a un usuario en función de los permisos necesarios.

Acceso de solo lectura predefinido: este acceso es para los usuarios que necesitan acceso de solo lectura. El rol de acceso a datos restringidos de la API de Chronicle identifica a un usuario como usuario con ámbito. El rol Lector de acceso a datos restringidos de la API de Chronicle permite a los usuarios ver datos en sus funciones.

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

Para verificar que los ámbitos personalizados de RBAC funcionan correctamente, incluye el permiso chronicle.dataAccessScopes.list al crear los roles personalizados. Sin embargo, no incluyas los permisos chronicle.DataAccessScopes.permit ni chronicle.globalDataAccessScopes.permit. Es posible que estos permisos se incluyan si has usado los roles predefinidos Editor de API de Chronicle o Administrador de API de Chronicle como punto de partida para tus roles personalizados.

Acceso global personalizado: este acceso es para los usuarios que necesitan permisos sin restricciones en las funciones que se les han asignado. Para dar acceso global personalizado a un usuario, debes especificar el permiso chronicle.globalDataAccessScopes.permit, además del rol personalizado que se le haya asignado.

Control de acceso con ámbitos y etiquetas

Google SecOps te permite controlar el acceso de los usuarios a los datos mediante 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 ingestión, se asignan metadatos a los datos en forma de etiquetas, como el espacio de nombres (opcional), los metadatos de ingestión (opcionales) y el tipo de registro (obligatorio). Estas son las etiquetas predeterminadas que se aplican a los datos durante la ingestión. Además, puedes crear etiquetas personalizadas. Puede usar etiquetas predeterminadas y personalizadas para definir sus ámbitos y el nivel de acceso a los datos que definirán los ámbitos.

Visibilidad de los datos con etiquetas de permitir y denegar

Cada permiso contiene una o varias etiquetas de permitir acceso y, opcionalmente, etiquetas de denegar acceso. Las etiquetas de acceso permiten que los usuarios accedan a los datos asociados a la etiqueta. Las etiquetas de denegación de acceso impiden que los usuarios accedan a los datos asociados a la etiqueta. Las etiquetas de denegación de acceso anulan las etiquetas de permiso de acceso al restringir el acceso de los usuarios.

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

Por ejemplo, supongamos que tienes un sistema de Cloud Logging que clasifica los registros mediante los siguientes tipos de etiquetas:

Tipo de registro: acceso, sistema y cortafuegos

Espacio de nombres: App1, App2, Database

Gravedad: crítica, advertencia

Supongamos que hay un ámbito llamado Registros restringidos que tiene el siguiente acceso:

Tipo de etiqueta Valores permitidos Valores denegados
Tipo de registro Acceso, cortafuegos Sistema
Espacio de nombres App1 App2, Database
Gravedad Advertencia Crítica

La definición del ámbito tiene este aspecto:

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 ámbito:

  • Registro de acceso de App1 con gravedad: Advertencia
  • Registro de cortafuegos de App1 con gravedad: Warning

Ejemplos de registros que no se ajustan al ámbito:

  • Registro del sistema de la aplicación 1 con gravedad: advertencia
  • Registro de acceso de la base de datos con gravedad: advertencia
  • Registro de cortafuegos de App2 con gravedad crítica

Visibilidad de los datos en eventos enriquecidos

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

Por ejemplo, imagina un registro sin procesar que indica un intento de inicio de sesión fallido desde una dirección IP y tiene una etiqueta enriquecida user_risk: high (indica que se trata de un usuario de alto riesgo). Un usuario con un ámbito que tenga la etiqueta de denegación user_risk: high no puede ver los intentos de inicio de sesión fallidos de usuarios de alto riesgo.

Impacto del control de acceso basado en roles de datos en las funciones de Google Security Operations

Una vez configurado el control de acceso basado en roles de datos, los usuarios empezarán 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 saber cómo afecta el RBAC de datos a cada función, consulta el artículo Impacto del RBAC de datos en las funciones de Google Security Operations.

Siguientes pasos

¿Necesitas más ayuda? Recibe respuestas de los miembros de la comunidad y de los profesionales de Google SecOps.