Controla el acceso a casos y alertas de 1P
Esta guía está dirigida a los administradores y analistas de seguridad de Google SecOps que desean controlar el acceso a los casos y las alertas de origen (1P) con el control de acceso basado en roles (RBAC) de datos. Explica cómo configurar los permisos de acceso a los datos en el lado del SIEM de la plataforma y cómo asignarlos a los entornos de SOAR para que los usuarios solo puedan ver las alertas y los casos derivados de los datos a los que están autorizados a acceder. Si sigues este método, podrás aplicar políticas de administración de datos y mejorar la seguridad. Completar el curso con éxito permite a las organizaciones restringir la visibilidad de los datos según los roles y las responsabilidades, lo que mejora el cumplimiento y reduce el riesgo de exposición de los datos.
Terminología clave
En esta guía, se usan los siguientes términos para describir los conceptos y componentes del RBAC de datos.
- Alertas propias (1P): Son las detecciones que genera el motor de detección del SIEM de Google SecOps, como reglas, coincidencias de inteligencia de amenazas o estadísticas de seguridad. Cuando estas detecciones del SIEM se transfieren al componente de SOAR a través del conector de Google SecOps, forman alertas de 1P y se agrupan en casos de 1P.
- Alertas de terceros (3P): Son alertas que se transfieren directamente al componente de SOAR desde herramientas de seguridad externas (por ejemplo, firewalls de terceros o agentes de detección de extremos) a través de integraciones de SOAR independientes. Estas alertas omiten el motor de detección del SIEM y no están sujetas a los alcances de acceso a los datos del SIEM.
En el caso de las alertas de origen, Google SecOps propaga los alcances de datos asociados de los eventos subyacentes al componente de SOAR. Esta propagación permite que los analistas vean las alertas y los casos asociados solo si tienen acceso a los alcances de datos de los eventos subyacentes. Por ejemplo, se le podría otorgar acceso a un usuario de finanzas a los datos financieros que se transfirieron a Google SecOps, pero no a los datos de contacto de los clientes. El usuario de finanzas solo puede ver las alertas y los casos asociados con los datos financieros, y no puede ver ninguna alerta ni caso asociado con los datos de contacto del cliente.
Antes de comenzar
Antes de configurar el RBAC de datos para los casos y las alertas de 1P, asegúrate de que se cumplan los siguientes requisitos:
- Tu instancia de Google SecOps debe estar unificada (SIEM y SOAR habilitados).
- Comportamiento del SIEM de varias instancias: Si tienes varias instancias del SIEM conectadas a una sola instancia de SOAR, la propagación y la aplicación del alcance solo se aplican a la instancia principal del SIEM. Los permisos de las instancias secundarias del SIEM se ignoran en SOAR, y esas alertas son visibles para cualquier usuario que tenga acceso a su entorno asignado en SOAR.
- Conector de Chronicle: El conector de Chronicle que conecta el componente SIEM al componente SOAR usa la API moderna de Chronicle. Antes de habilitar esta función, asegúrate de que el conector se haya actualizado de la API heredada de Backstory a la API de Chronicle. Para obtener más detalles, consulta Actualiza a la API de Chronicle.
Habilita el RBAC de datos para las alertas y los casos de 1P
Los administradores de Google SecOps (rol de administrador de la API de Chronicle en Google Cloud IAM) pueden habilitar el RBAC de datos para las alertas y los casos de 1P en su instancia. Existen dos situaciones:
Situación A: Ya se aplica el acceso a los datos del SIEM
Si los controles de acceso a los datos ya están activos en el componente SIEM, sigue estos pasos para extender la aplicación a las alertas y los casos de 1P en el componente SOAR:
- Accede a Google SecOps.
- Verifica que tus permisos estén configurados correctamente en Configuración del SIEM > Acceso a los datos.
- Asigna permisos de datos a los usuarios en la consola de Google Cloud con Google Cloud IAM.
- En Google SecOps, ve a Configuración del SIEM > Acceso a los datos y haz clic en Habilitar el acceso a los datos en SOAR.
- Asigna tus permisos de SIEM a los entornos de SOAR como se describe en Asigna permisos a entornos.
Ahora se aplica el acceso a los datos para las alertas y los casos de origen en el componente de SOAR. Esto se aplica a todas las alertas y los casos nuevos, así como a los existentes que se crearon después de que se aplicó inicialmente el acceso a los datos del SIEM.
Situación B: AÚN NO se aplica el acceso a los datos del SIEM
Si aún no habilitaste los controles de acceso a los datos en SIEM, la aplicación se habilitará para SIEM y SOAR de forma simultánea.
- Accede a Google SecOps.
- Verifica que tus permisos estén configurados correctamente en Configuración del SIEM > Acceso a los datos.
- Asigna permisos de datos a los usuarios en la consola de Google Cloud con Google Cloud IAM.
- En Google SecOps, ve a SIEM Settings > Data Access y haz clic en Enforce Data Access.
- Asigna tus permisos de SIEM a los entornos de SOAR como se describe en Asigna permisos a entornos.
Ahora se aplica el acceso a los datos en el componente SIEM y para las nuevas alertas y casos de origen en el componente SOAR.
Asigna permisos a entornos
Para vincular los permisos de datos del SIEM con SOAR, asigna tus permisos de acceso a datos del SIEM a los entornos de SOAR.
- Ve a Configuración de SOAR > Entornos para acceder a la página de configuración del entorno.
- Selecciona un entorno existente para modificarlo o haz clic en Agregar entorno.
- Asocia permisos vinculando los permisos de SIEM a este entorno.
- Ubica el campo Data access scopes y selecciona los alcances de acceso a los datos de SIEM necesarios.
- Reglas de asignación:
- Un permiso solo se puede asignar a un entorno.
- Se pueden asignar varios permisos a un solo entorno.
- Haz clic en Guardar para aplicar la asignación del alcance al entorno.
Asignación de resguardo del entorno
Cuando se configura la asignación de permiso a entorno, las alertas de SIEM con un permiso asignado se asignan automáticamente al entorno de SOAR asociado. Esto anula la configuración del entorno en el conector de Chronicle.
Si una alerta del SIEM no tiene un alcance definido (global) o su alcance no está asignado a un entorno, se enruta al entorno de respaldo. El entorno de resguardo se define con el parámetro de configuración Environment o Environment Field Name en el conector de Chronicle.
Información sobre la evaluación de acceso
En esta sección, se describe cómo Google SecOps evalúa el acceso de los usuarios a los casos y las alertas según los entornos y los permisos asignados. Para ver un caso o una alerta de 1P, el usuario debe cumplir con los permisos de entorno y alcance.
Lógica de propagación del alcance
- Alcance de la alerta: Una alerta transferida incluye el permiso de acceso a los datos que le asignan las reglas de detección de Google SecOps SIEM.
- Alcance del caso: Un caso hereda automáticamente la unión de todos los alcances de sus alertas asociadas. Por ejemplo, si un caso agrupa la Alerta 1 (alcance A) y la Alerta 2 (alcance B), el caso hereda el alcance A y el alcance B.
Reglas de acceso
Para acceder a un recurso (caso o alerta), el usuario debe tener lo siguiente:
- Acceso al entorno de SOAR asignado al recurso.
- Acceso a todos los permisos de acceso a datos asignados al recurso.
Situaciones de evaluación
En la siguiente tabla, se muestra cómo se evalúa el acceso del usuario en diferentes situaciones:
| Alertas de casos | Alcances de casos | Permisos asignados por el usuario | Nivel de acceso del usuario | ¿Se otorgó acceso al caso y a las alertas asociadas? | Razones |
|---|---|---|---|---|---|
| Alerta 1 (alcance 1) | Alcance 1 | Alcance 1 | Usuario con permiso | Yes | El usuario tiene acceso al único alcance asignado al caso. |
| Alerta 1 (alcance 1) y Alerta 2 (alcance 2) | Alcance 1 y Alcance 2 | Alcance 1 | Usuario con permiso | No. | Al usuario le falta el alcance 2; debe tener acceso a todos los alcances asignados al caso. |
| Alerta 1 (alcance 1) y Alerta 2 (alcance 2) | Alcance 1 y Alcance 2 | Alcance 1 y Alcance 2 | Usuario con permiso | Yes | El usuario tiene acceso a todos los permisos asignados al caso. |
| Alerta 1 (alcance 1) y Alerta 2 (alcance 2) | Alcance 1 y Alcance 2 | Global | Usuario global | Yes | Los usuarios globales omiten el filtrado de alcance y pueden ver todos los casos. |
| Alerta 1 (permiso global) | Global | Global | Usuario global | Yes | Los usuarios globales omiten el filtrado de alcance y pueden ver todos los casos. |
| Alerta 1 (alcance 1) y Alerta 2 (alcance global) | Global | Alcance 1 | Usuario con permiso | No. | Los casos con alcance global se restringen a los usuarios globales. |
| Alerta 1 (alcance 1) y Alerta 2 (alcance global) | Global | Global | Usuario global | Yes | Los usuarios globales omiten el filtrado de alcance y pueden ver todos los casos. |
| Alerta 1 (permiso global) | Global | Alcance 1 | Usuario con permiso | No. | Los casos con alcance global se restringen a los usuarios globales. |
Reglas de agrupación de casos y alcance de entidades
- Agrupamiento limitado por el entorno: Las alertas solo se pueden agrupar en un solo caso si sus permisos asignados las dirigen al mismo entorno.
- Acumulación de alcance: Cuando las alertas con diferentes alcances se asignan al mismo entorno y se agrupan en un caso, este hereda todos esos alcances.
- Impacto de las alertas sin alcance: Si una alerta sin alcance se agrupa con una alerta con alcance en el entorno de resguardo, el caso hereda el alcance global, lo que hace que solo sea visible para los usuarios globales.
- Alcance de entidades únicas: Una entidad única hereda los alcances de todas las alertas en las que aparece.
- Alcance de las entidades involucradas: Las entidades involucradas solo heredan el alcance de su alerta principal.
Cómo modificar las asignaciones de alcance a entorno
Cuando cambias o quitas una asignación de alcance, el impacto depende de si las alertas y los casos son nuevos o existentes.
- Mover un permiso: Cambiar la asignación de un permiso del entorno A al entorno B:
- Alertas y casos nuevos: Se enrutan al entorno B.
- Alertas y casos existentes: Permanecen en el entorno A. Los usuarios pueden acceder a ellos si tienen permisos para el entorno A y el alcance asignado.
- Quita una asignación de alcance: Para quitar la asignación de un alcance de un entorno, haz lo siguiente:
- Alertas y casos nuevos: Se enrutan al entorno de respaldo. Solo es visible para los usuarios globales y los usuarios con acceso al entorno de resguardo.
- Alertas y casos existentes: Permanecen en su entorno original, pero solo son visibles para los usuarios globales porque ya no se asigna el alcance.
Cómo controlar casos manuales y de desbordamiento
En esta sección, se describe cómo administrar los casos que se crean de forma manual o que resultan de un exceso de alertas.
Crear casos manualmente
- En la pestaña Casos, haz clic en Crear caso manual.
- Selecciona el entorno de destino.
- Selecciona un permiso de acceso a los datos. En la lista, se muestran los permisos que se asignaron a tu cuenta de usuario y que se asignaron al entorno.
- Si no existen permisos superpuestos, la lista estará vacía y no podrás enviar el caso.
- Los usuarios globales pueden seleccionar cualquier alcance asignado al entorno.
- Ingresa los detalles del caso y haz clic en Enviar. El caso y su alerta manual heredan el alcance seleccionado.
Casos de derivación
Los casos de desbordamiento agrupan alertas en varios alcances sin seguir el modelo de entidad compartida. Se les asigna el alcance global y solo son visibles para los usuarios globales.
Cómo encontrar alcances en la página Cases
Puedes ver los permisos de acceso a los datos asignados a un caso en varias ubicaciones dentro de la interfaz de Google SecOps.
Encabezado del caso
Los permisos asignados aparecen como etiquetas de solo lectura junto al campo Environment. Mantén el puntero sobre el área para ver la lista completa.
Tabla de casos de lista
También puedes ver los alcances directamente desde la tabla List cases:
- En la tabla List cases, se encuentra disponible una columna Data access scopes.
- En esta columna, se muestran los alcances asignados al caso (separados por comas si hay varios).
- Puedes filtrar la cola escribiendo los nombres de los alcances en el filtro de texto de la columna.
Cómo controlar las eliminaciones de permisos
En esta sección, se explica qué sucede con los casos y las alertas existentes cuando se borra un permiso de acceso a los datos en el lado del SIEM de la plataforma.
Si un administrador borra un permiso de acceso a los datos en Configuración del SIEM > Acceso a los datos, ocurrirá lo siguiente:
- El alcance se desvincula automáticamente de cualquier entorno de SOAR.
- Aplicación del acceso: Dado que el permiso se borra del componente del SIEM y de Cloud IAM, solo los usuarios globales (o los usuarios que aún conservan la reclamación del token almacenado en caché) podrán acceder a estos casos y alertas históricos.
Soluciona problemas
En esta sección, se describen las expectativas de rendimiento y se proporcionan soluciones de autoservicio para problemas de implementación comunes.
Latencia y límites
Los cambios en las asignaciones de alcance a entorno o la habilitación inicial pueden tardar hasta 30 segundos en propagarse.
Validación y prueba
Para validar tu configuración, prueba el acceso a casos y alertas con cuentas de usuario que tengan diferentes permisos de alcance y entorno. Confirma que los usuarios solo puedan ver los datos para los que están autorizados.
¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.