Descripción general del RBAC de datos
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 alcances 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 las etiquetas y los permisos trabajan 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 o 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 funciones con 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 de control de acceso integral. Por ejemplo, se le puede permitir a un usuario acceder a una función específica (RBAC de funciones) y, luego, dentro de esa función, se puede 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 y alinea estos roles y permisos 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 alcances.
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 alcance (usuarios con alcance) o acceso a datos global (usuarios globales).
Los usuarios con permisos limitados tienen acceso limitado a los datos según los permisos asignados. Estos ámbitos restringen su visibilidad y acciones a datos específicos. En la siguiente tabla, se detallan los permisos específicos asociados con el acceso limitado.
Los usuarios globales no tienen permisos asignados y tienen acceso sin restricciones a todos los datos de Google SecOps. En la siguiente tabla, se detallan los permisos específicos asociados con el acceso global.
El acceso global anula el acceso con alcance. Si a un usuario se le asignan un rol global y un rol con alcance, tendrá acceso a todos los datos, independientemente de las restricciones impuestas por el rol con alcance.
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 el acceso de un usuario a ciertos permisos, debes asignarle el rol de Acceso a los datos restringidos de la API de Chronicle (roles/chronicle.restrictedDataAccess
) junto con un rol predefinido o personalizado. El rol de acceso a los datos restringidos de la API de Chronicle identifica a un usuario como usuario con alcance. No es necesario que asignes el rol de acceso restringido a los datos de Chronicle a los usuarios que necesitan acceso a los datos globales.
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 alcance predefinido | 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 personalizado con alcance | Acceso a los datos restringidos de la API de Chronicle (roles/chronicle.restrictedDataAccess ) y rol personalizado (para la definición del RBAC de la función)
|
Permisos personalizados dentro de las funciones |
Acceso global personalizado | Permiso de 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 requeridos.
Acceso de solo lectura con alcance predefinido: Este acceso es para los usuarios que necesitan acceso de solo lectura. El rol de acceso a los datos restringidos de la API de Chronicle identifica a un usuario como usuario con alcance. 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 personalizado con permisos: El rol de acceso a los 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 agregados al rol de acceso restringido a los datos de la API de Chronicle especifican los datos a los que los usuarios pueden acceder en las funciones.
Para verificar que los permisos personalizados del RBAC funcionen correctamente, incluye el permiso chronicle.dataAccessScopes.list
cuando crees los roles personalizados. Sin embargo, no incluyas los permisos chronicle.DataAccessScopes.permit
o chronicle.globalDataAccessScopes.permit
. Es posible que estos permisos se incluyan si usaste el editor de la API de Chronicle o el administrador de la API de Chronicle prediseñados 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.
Control de acceso con alcances y etiquetas
Las Operaciones de seguridad de Google te permiten controlar el acceso a los datos de los usuarios con 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, se asignan metadatos a los datos en forma de etiquetas, como el espacio de nombres (opcional), los metadatos de transferencia (opcional) y el tipo de registro (obligatorio). 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 alcances y el nivel de acceso a los datos que definirán los alcances.
Visibilidad de los datos con etiquetas de permiso y denegación
Cada alcance contiene una o más etiquetas de permitir acceso y, de manera opcional, etiquetas de denegar acceso. Las etiquetas de permiso de acceso otorgan a los usuarios acceso a los datos asociados con la etiqueta. Las etiquetas de denegación de acceso impiden que los usuarios accedan a los datos asociados con la etiqueta. Las etiquetas de denegación de acceso anulan las etiquetas de permiso de acceso cuando se restringe el acceso del usuario.
En una definición de alcance, las etiquetas de acceso del mismo tipo (por ejemplo, el tipo de registro) se combinan con el operador OR, mientras que las etiquetas de diferentes tipos (por ejemplo, el tipo de registro y una etiqueta personalizada) se combinan con el operador AND. Las etiquetas de denegación de acceso se combinan con el operador OR. Cuando se aplican varias etiquetas de denegación de acceso dentro de un alcance, 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: Acceso, Sistema, Firewall
Espacio de nombres: App1, App2, Database
Gravedad: Crítica, Advertencia
Considera un alcance llamado Registros restringidos que tiene el siguiente acceso:
Tipo de etiqueta | Valores permitidos | Valores denegados |
---|---|---|
Tipo de registro | Acceso, Firewall | Sistema |
Espacio de nombres | App1 | App2, Database |
Gravedad | Advertencia | Crítico |
La definición del alcance 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 alcance:
- Registro de acceso de App1 con gravedad: Advertencia
- Registro de firewall de App1 con gravedad: Advertencia
Ejemplos de registros que no coinciden con el alcance:
- Registro del sistema de App1 con gravedad: Advertencia
- Registro de acceso de la base de datos con gravedad: Advertencia
- Registro de firewall de App2 con gravedad: Crítica
Visibilidad de los datos en los 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 alcance solo si su evento base es accesible dentro del alcance y ninguna de las etiquetas enriquecidas incluye ninguna de las etiquetas de denegación del alcance.
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 alcance que tiene la etiqueta de denegación user_risk: high
no puede ver los intentos de acceso fallidos de los 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 comenzará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 comprender cómo el RBAC de datos afecta 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.