Característica de RBAC Basado en Propietarios (Owner-Based RBAC)

En esta guía, exploraremos el RBAC Basado en Propietarios (Owner-Based RBAC): una funcionalidad diseñada para grandes organizaciones donde múltiples equipos operan dentro de la misma plataforma. Permite ajustar con precisión el acceso a los elementos de la plataforma en función de la lista de Propietarios (Owners) a los que tienen acceso los usuarios.

Modelo de Acceso Sin RBAC Basado en Propietarios

Antes del RBAC Basado en Propietarios, la plataforma utiliza un control de acceso basado en roles a nivel de toda la organización:

graph TB ORG[🏢 Organización<br/>Todos los Recursos] subgraph "Cuatro Roles - Acceso a Nivel de Organización" ADMIN[👑 Admin<br/>Lectura + Escritura + Acciones de Admin<br/>Integraciones, IAM, Configuración] USER[👨‍💼 User<br/>Lectura + Escritura<br/>Sin Acciones de Admin] READER[👁️ Reader<br/>Solo Lectura<br/>Todos los Recursos] AUDITOR[🔍 Attack Surface Auditor<br/>Gestión de Activos vía Owners<br/>Rol Heredado] end ORG -.->|Acceso Total| ADMIN ORG -.->|Lectura+Escritura| USER ORG -.->|Solo Lectura| READER ORG -.->|Activos basados en Owners| AUDITOR style ORG fill:#95a5a6,color:#fff style ADMIN fill:#e74c3c,color:#fff style USER fill:#3498db,color:#fff style READER fill:#95a5a6,color:#fff style AUDITOR fill:#f39c12,color:#fff

Admin: Acceso completo de lectura y escritura a todo, además de acciones administrativas como la gestión de integraciones, ajustes de IAM y configuración de la organización.

User: Acceso de lectura y escritura a todos los recursos de la organización: activos, escaneos y tickets. No puede realizar acciones administrativas como modificar integraciones o ajustes de IAM.

Reader: Acceso de solo lectura a todos los recursos de la organización. Ideal para partes interesadas (stakeholders) que requieren visibilidad sin permisos de modificación.

Attack Surface Auditor: Rol heredado (legacy) que ya utilizaba Owners para gestionar el acceso a activos. Este rol está obsoleto (deprecated) y será eliminado próximamente.

El problema: todos ven todo dentro de la organización. No existen límites entre equipos. En entornos grandes con múltiples equipos, esto genera ruido, confusión y posibles interferencias entre ellos.

El RBAC Basado en Propietarios resuelve esto añadiendo un control de acceso granular basado en equipos.

¿Qué es el RBAC Basado en Propietarios?

El RBAC Basado en Propietarios introduce una capa de acceso intermedia llamada "Owners" (Propietarios): grupos lógicos que representan equipos dentro de su organización.

graph LR O[📁 Owners<br/>Grupos] -->|Asignados a| U[👤 Usuarios] O -->|Controlan| A[📦 Activos<br/>Apps, Dominios, IPs] O -->|Controlan| TG[🏷️ Etiquetas<br/>Metadatos] S[🔍 Escaneos<br/>Pruebas de Seguridad] -->|Se ejecutan en| A S -->|Crean| T[🎫 Tickets<br/>Vulnerabilidades] style U fill:#3498db,color:#fff style O fill:#2ecc71,color:#fff style A fill:#f39c12,color:#fff style TG fill:#8e44ad,color:#fff style S fill:#9b59b6,color:#fff style T fill:#e74c3c,color:#fff

El flujo es simple: los Owners se asignan a los Usuarios. Los Owners controlan los Activos (como aplicaciones móviles, dominios y direcciones IP) y las Etiquetas (Tags). Los Escaneos se ejecutan sobre los Activos. Tras su finalización, los Escaneos generan Tickets para las vulnerabilidades detectadas. El acceso se propaga automáticamente: si tiene acceso a un Owner, accede automáticamente a todos sus activos, etiquetas, escaneos y tickets. Las etiquetas sin Owners asignados son estrictamente visibles únicamente para los Administradores de la Organización. No se requiere una gestión manual de permisos. El sistema es jerárquico: los Owners pueden tener relaciones padre-hijo reflejando la estructura de su organización. Esto crea patrones de acceso naturales y manejables, mientras la plataforma procesa los cálculos complejos de forma automática.

Roles de Usuario en el RBAC Basado en Propietarios

Cuando el RBAC Basado en Propietarios está habilitado, las capacidades de los roles cambian:

flowchart TB subgraph roles["Permisos de Roles"] A["👑 Admin<br>Acceso Total a la Organización<br>Omite restricciones de Owner"] B["👨‍💼 User<br>Lectura + Escritura<br>Dentro de Owners asignados<br>Sin Owners = Acceso Total"] C["👁️ Reader<br>Solo Lectura<br>Dentro de Owners asignados<br>Sin Owners = Acceso Total"] D["🔍 Attack Surface Auditor<br>Igual que User<br>Obsoleto - Será eliminado"] end A -. Sin restricciones .-> ALL["Todos los Recursos"] B -. Restringido .-> OWN1["Recursos Propios<br>o Todos si no hay Owners asignados"] C -. Restringido .-> OWN2["Recursos Propios<br>o Todos si no hay Owners asignados"] D -. Restringido .-> OWN3["Igual que User"] style A fill:#e74c3c,color:#fff style B fill:#3498db,color:#fff style C fill:#95a5a6,color:#fff style D fill:#f39c12,color:#fff,stroke-dasharray: 5 5

Admin: Sin cambios: acceso total y sin restricciones a todo. Omite todas las restricciones de Owner. Puede realizar acciones de administración como gestionar integraciones y ajustes de IAM.

User: Acceso de lectura y escritura a activos y etiquetas dentro de los Owners asignados. Puede iniciar escaneos, gestionar vulnerabilidades y trabajar con tickets para los recursos de su Owner. Importante: si no tiene Owners asignados, el User tiene acceso a TODOS los recursos de la organización.

Reader: Acceso de solo lectura a activos y etiquetas dentro de los Owners asignados. No puede modificar nada. Importante: si no tiene Owners asignados, el Reader tiene acceso de lectura a TODOS los recursos de la organización.

Attack Surface Auditor: Rol heredado obsoleto. Actualmente se comporta de la misma manera que el rol User. Será eliminado en versiones futuras; utilice el rol User en su lugar.

Distinción clave: los Admins ignoran los límites de Owner. Los Users y Readers respetan las asignaciones de Owner o reciben acceso total cuando no tienen Owners asignados.

Jerarquía de Acceso: El Fundamento

El acceso fluye a través de una cadena clara:

graph TD O[📁 Owners] -->|1. Asignados a| U[👤 Usuarios] O -->|2. Controlan| A[📦 Activos] O -->|2. Controlan| TG[🏷️ Etiquetas] A -->|3. Tienen| S[🔍 Escaneos] S -->|4. Generan| T[🎫 Tickets] ST[📝 Tickets Independientes] -.->|Visibles para TODOS| U style U fill:#3498db,color:#fff style O fill:#2ecc71,color:#fff style A fill:#f39c12,color:#fff style TG fill:#8e44ad,color:#fff style S fill:#9b59b6,color:#fff style T fill:#e74c3c,color:#fff style ST fill:#e67e22,color:#fff,stroke-dasharray: 5 5

Paso 1: Los Owners se asignan a los Usuarios: el fundamento de todo acceso.

Paso 2: Los Owners controlan los Activos (aplicaciones móviles, dominios, direcciones IP) y las Etiquetas.

Paso 3: Los Escaneos se ejecutan sobre los Activos. Si tiene acceso al activo, tiene acceso a sus escaneos.

Paso 4: Los Escaneos generan Tickets. Si tiene acceso al escaneo, tiene acceso a sus tickets.

Excepción: Los Tickets Independientes (Standalone Tickets)—creados manualmente sin escaneos—son visibles para TODOS los usuarios a nivel de toda la organización. Esto garantiza que los anuncios importantes y los hallazgos manuales lleguen a todos.

La jerarquía crea un acceso automático y en cascada que refleja los flujos reales de trabajo de seguridad.

Jerarquía de Propietarios: Relaciones Padre-Hijo

Los Owners pueden formar jerarquías: relaciones padre-hijo que reflejan la estructura organizativa.

graph TD P[👔 Equipo de Ingeniería<br/>Owner PADRE] C1[📱 Equipo Mobile<br/>Owner HIJO] C2[🌐 Equipo Web<br/>Owner HIJO] P --> C1 P --> C2 C1 --> A1[Apps iOS] C1 --> A2[Apps Android] C2 --> A3[Dominios] C2 --> A4[APIs] U1[👤 Usuario asignado al<br/>Padre Ingeniería] -.->|Ve| P U1 -.->|Ve| C1 U1 -.->|Ve| C2 U2[👤 Usuario asignado al<br/>Hijo Mobile] -.->|Ve ÚNICAMENTE| C1 style P fill:#e74c3c,color:#fff style C1 fill:#3498db,color:#fff style C2 fill:#3498db,color:#fff style U1 fill:#2ecc71,color:#fff style U2 fill:#f39c12,color:#fff

El acceso descendente es la clave:

El usuario asignado a un Owner Padre ve todos los Owners hijos y sus activos. Ideal para directores o responsables que supervisan múltiples equipos.

El usuario asignado a un Owner Hijo ve ÚNICAMENTE ese hijo y sus activos, no el padre ni los hermanos. Esto asegura que los miembros del equipo se concentren en su propio alcance sin ver datos no relacionados.

Ejemplo: ¿Asignado al Equipo Mobile? Ve ÚNICAMENTE los activos de Mobile, no el departamento padre de Ingeniería ni el equipo hermano de Web.

¿Asignado al Padre de Ingeniería? Ve Ingeniería más TODOS sus hijos: los Equipos Mobile y Web.

Esto es recursivo: los nietos son visibles para los abuelos. Construya estructuras organizativas profundas con límites de acceso definidos.

Ejemplo de Propagación de Acceso: Siguiendo la Cadena

Rastreemos un ejemplo real de propagación de acceso.

flowchart LR U[👤 Jane] -->|Asignada| O[📁 Equipo Mobile] O -->|Controla| A1[📱 Banking App] O -->|Controla| A2[📱 Payment App] A1 -->|Escaneada| S1[🔍 Escaneo #12345] A2 -->|Escaneada| S2[🔍 Escaneo #12346] S1 -->|Detectó| T1[🎫 Inyección SQL] S1 -->|Detectó| T2[🎫 XSS] S2 -->|Detectó| T3[🎫 Criptografía Débil] U -.->|✓ Accede a| A1 U -.->|✓ Accede a| A2 U -.->|✓ Accede a| S1 U -.->|✓ Accede a| S2 U -.->|✓ Accede a| T1 U -.->|✓ Accede a| T2 U -.->|✓ Accede a| T3 style U fill:#3498db,color:#fff style O fill:#2ecc71,color:#fff style A1 fill:#f39c12,color:#fff style A2 fill:#f39c12,color:#fff

Jane está asignada al Owner Equipo Mobile.

El Equipo Mobile controla dos activos: Banking App y Payment App. Jane accede automáticamente a ambos.

Se ejecutan los escaneos: Escaneo #12345 sobre Banking App y Escaneo #12346 sobre Payment App. Jane puede acceder a ambos escaneos porque se realizaron sobre los activos de su Owner.

Vulnerabilidades detectadas: Inyección SQL y XSS en Banking App; Criptografía Débil en Payment App. Jane accede a los tres tickets automáticamente.

Una asignación → Siete recursos accesibles. La cadena funciona de forma automática: Usuario → Owner → Activos → Escaneos → Tickets. No requiere ninguna gestión manual de permisos.

Activar el RBAC Basado en Propietarios

Para activar el RBAC Basado en Propietarios, comience haciendo clic en el botón de menú en la parte superior izquierda de la pantalla.

A continuación, localice Settings (Configuración) en el menú.

Y haga clic en Organization (Organización).

Desplácese hacia abajo hasta encontrar el interruptor de Enable Object Level Access Control (Habilitar Control de Acceso a Nivel de Objeto).

Si el interruptor está desactivado, la plataforma utilizará el modo heredado en el que todos los usuarios ven todos los recursos dentro de la organización. Si activa el interruptor, se activará el nuevo sistema de RBAC Basado en Propietarios, filtrando todas las consultas por asignaciones de Owner y habilitando la interfaz de asignación de Owners.

En esta guía, exploramos el RBAC Basado en Propietarios, una potente funcionalidad diseñada para grandes organizaciones con múltiples equipos que trabajan en la misma plataforma. Vimos cómo proporciona un control de acceso granular basado en equipos que elimina el ruido y la confusión de que todos vean todo.