Sistema de permisos

La plataforma Mirox controla el acceso mediante un modelo de permisos en capas y basado en roles que te da un control preciso sobre quién puede ver y modificar qué plantas, sin obligarte a gestionar los derechos individuales uno por uno. Los roles hacen la agrupación; la jerarquía hace la herencia.

Filosofía de permisos

El sistema de permisos se construye sobre unos pocos principios que mantienen el acceso seguro y fácil de razonar:

1. Herencia jerárquica — El acceso sigue la jerarquía natural de los recursos y las organizaciones: concede una vez en lo alto y fluye hacia abajo.
2. Privilegio mínimo — Cada rol incluye solo los derechos que su función realmente necesita.
3. Separación de responsabilidades — La posición dentro de la organización y el acceso a los recursos son dos ejes distintos, de modo que puedes dar a alguien un rol de organización senior sin exponer todas las plantas, y viceversa.
4. Asignación explícita — El acceso se concede a propósito, nunca se da por supuesto.
5. Conciencia del contexto — La misma persona puede tener distintos derechos en distintas plantas.

En conjunto, mantienen un enfoque seguro pero flexible para gestionar el acceso en toda la plataforma Mirox.

Capas de permisos

Una solicitud pasa por una secuencia de comprobaciones. Cada capa responde a una pregunta; todas las capas relevantes deben coincidir antes de conceder el acceso.

Nota: la capa de API solo se aplica a las solicitudes autenticadas con un token de API; las sesiones interactivas pasan directamente a la capa del sistema.

Las capas:

• Capa de API (naranja) — Solo para solicitudes con token de API. Valida el token y aplica su grupo de permisos, que solo puede restringir lo que el propietario del token ya podía hacer.
• Capa del sistema (rojo) — La primera puerta para cada solicitud. Establece la posición a nivel de plataforma (usuario normal frente a administrador de la plataforma) y protege las operaciones críticas del sistema con independencia de cualquier otra capa.
• Capa de organización (azul) — Confirma que perteneces a la organización propietaria del recurso y aplica tu rol de organización.
• Capa de trabajo (verde) — La comprobación más granular: decide qué puedes hacer en una planta o un portfolio concretos.

El siguiente diagrama muestra las combinaciones habituales. Los datos a nivel de toda la organización requieren la comprobación de organización; una sola planta requiere la comprobación de trabajo; muchas solicitudes requieren ambas.

Capa de permisos del sistema

La capa del sistema es la primera puerta de seguridad. Distingue a los administradores de la plataforma de los usuarios normales y protege las operaciones que afectan a todo el sistema:

• Los administradores de la plataforma pueden realizar operaciones a nivel de todo el sistema.
• Los usuarios normales no pueden realizar acciones que afecten a la propia plataforma.
• Esta capa no evalúa el acceso a nivel de función (como la generación de informes); eso ocurre más abajo.

La integridad del sistema permanece protegida incluso si una comprobación más detallada está mal configurada.

Capa de permisos de organización

Cada usuario pertenece exactamente a una organización, que es la puerta de entrada a los recursos:

• Las organizaciones son propietarias de los recursos (portfolios y parques).
• Recibes tu acceso de base a través de tu rol de organización.
• Las organizaciones pueden establecer acuerdos de cooperación para compartir recursos específicos más allá del límite de la organización.

Esta capa hace cumplir los límites de la organización: solo llegas a los recursos que tu organización posee o que se le han concedido a través de una cooperación.

Capa de permisos de recurso (trabajo)

El nivel más granular controla lo que puedes hacer en una planta o un portfolio individual. El acceso aquí se expresa como un rol de trabajo (ver más abajo):

• Tu rol de organización proporciona un rol de trabajo por defecto en cada recurso propio.
• Las organizaciones pueden sobrescribir ese valor por defecto concediéndote un rol de trabajo específico en un recurso específico, más amplio o más restringido que tu valor por defecto.
• Una concesión directa siempre prevalece sobre el valor por defecto heredado, por lo que las excepciones son fáciles.

Esta capa permite un control preciso por planta sin cambiar el rol de organización de nadie.

Capa de permisos del token de API

Una capa opcional para la automatización y las integraciones:

• Los tokens de API los crean los usuarios para impulsar scripts y sistemas externos.
• Un token nunca puede superar los permisos del usuario que lo creó: solo restringe.
• Un token está vinculado a un grupo de permisos que lo limita a un área de funciones (ver Grupos de permisos de API).
• A un token nunca se le pide un segundo factor, y las reglas sobre la duración del inicio de sesión no lo finalizan. Una regla: un usuario sin segundo factor no puede crear un token nuevo mientras su propia organización exija la autenticación de dos factores (2FA).

Esto mantiene la automatización segura respetando el privilegio mínimo. Para más detalles, consulta la documentación de la función de tokens de API.

La exigencia de dos factores, por encima de los roles

Los roles deciden qué plantas puedes alcanzar. Una organización puede añadir una condición por encima: puede exigir la autenticación de dos factores (2FA) para acceder a sus plantas.

• Un rol concede la planta. La exigencia decide si se te muestra. Si la organización propietaria de una planta exige 2FA y tu cuenta no tiene segundo factor (aplicación de autenticación o passkey), no ves las plantas de esa organización — tengas el rol que tengas en ellas.
• No se quita nada. Tus roles y concesiones siguen como están. Tu sesión sigue iniciada, y un aviso en la cabecera te indica que actives la 2FA. En cuanto la activas, las plantas vuelven a aparecer.
• Decide el propietario de la planta. La exigencia se aplica a todo el que alcanza la planta: los miembros de la propia organización y los usuarios de un socio de cooperación.

Quién fija la exigencia y qué se oculta exactamente se describe en la página Política de seguridad de la organización.

Sistema de control de acceso basado en roles

Mirox utiliza el control de acceso basado en roles (RBAC) con roles predefinidos en tres ejes: un rol de sistema a nivel de plataforma, un rol de organización y roles de trabajo por recurso.

Roles de sistema

Los roles de sistema definen la posición a nivel de plataforma:

• Administrador — Personal de la plataforma con acceso a operaciones y configuración de todo el sistema.
• Usuario — El rol estándar para todo el que usa la plataforma; sin privilegios administrativos.

Roles de organización

Tu rol de organización es tu posición por defecto dentro de tu organización. Los dos roles de gestor son el núcleo de la estructura de permisos actual: te permiten delegar responsabilidad senior sin ceder el control completo de moderador.

Los dos roles de gestor son hermanos: pares bajo el Moderador, uno técnico y uno comercial. Esta división permite que una sola organización separe limpiamente la propiedad de ingeniería de la propiedad de contratos y facturación.

Contenido compartido de la organización. Los Administradores, los Moderadores y los dos roles de Gestor de activos crean, duplican, cambian y eliminan las plantillas, los capítulos y las métricas de informes de la organización, sus plantillas y fórmulas de exportación de datos, y las reglas, receptores, plantillas y silencios del Gestor de alertas; los Miembros los ven y los usan. Un elemento marcado como Privado solo lo cambian su creador, un Administrador o un Moderador; consulta Informes y Gestor de alertas. Los comercializadores directos quedan en manos de los Administradores y los Moderadores.

Permisos de recurso basados en el trabajo

Los roles de trabajo definen lo que un usuario puede hacer en una planta o un portfolio específicos, con independencia de su rol de organización:

Responsable de seguridad solo se concede de forma explícita. Ningún rol de organización se asigna a él, así que nadie se convierte en responsable de seguridad al unirse a una organización: se concede deliberadamente, por planta o por cartera, o se comparte mediante una cooperación.

Cliente también se concede solo de forma explícita, y es el único rol cuyo permiso puede reducir una cuenta: los permisos se suman, así que un Miembro que recibe un permiso de Cliente conserva el acceso de Visualizador del Miembro — la vista limitada solo surte efecto para un miembro Externo o una compartición por cooperación. Un permiso de Cliente puede llevar fecha de caducidad.

El token entre paréntesis es el identificador utilizado en las concesiones de API y en los recursos compartidos por cooperación; en toda la interfaz ves la etiqueta detallada.

Grupos de permisos de API

A los tokens de API se les asigna exactamente un grupo de permisos que limita lo que el token puede alcanzar:

• Acceso completo — Los mismos permisos que el usuario creador, dentro de su alcance.
• Metric Export — Limitado a la lectura de la exportación de datos: métricas como series temporales, plantillas de exportación, el catálogo de métricas, información de la planta y eventos. No puede cambiar nada.
• Base de datos de series temporales — Acceso a los endpoints de series temporales para leer las series de medición brutas.

Para casos de uso y ejemplos, consulta la documentación de la función de tokens de API.

Herencia de permisos

El acceso fluye hacia abajo por la jerarquía de recursos, de modo que concedes arriba y refinas abajo:

Organization
├── Organization Role (your default standing)
│
├── Portfolio 1
│   ├── Inherits organization-level access
│   ├── Portfolio-specific grants (optional)
│   │
│   ├── Park A
│   │   ├── Inherits portfolio access
│   │   └── Park-specific grants (optional)
│   │
│   └── Park B
│       ├── Inherits portfolio access
│       └── Park-specific grants (optional)
│
└── Portfolio 2
    └── Park C
        └── Inherits portfolio access

Este modelo de herencia significa que:

1. El acceso de tu rol de organización se aplica a todos los portfolios y parques que tu organización posee.
2. Una concesión a nivel de portfolio se aplica a todos los parques de ese portfolio.
3. Una concesión en un solo parque refina el acceso únicamente para ese parque, sobrescribiendo el valor por defecto heredado.

Asignación de rol de organización a rol de trabajo

Cuando accedes a un recurso, tu rol de organización determina automáticamente tu rol de trabajo por defecto:

Esta separación mantiene los permisos de recurso (roles de trabajo) distintos de la posición dentro de la organización. Tu rol de organización establece el valor por defecto, pero las concesiones explícitas por recurso pueden elevarlo o reducirlo para cualquier planta individual.

Cooperación entre organizaciones

Las organizaciones pueden establecer acuerdos de cooperación para compartir recursos específicos más allá del límite de la organización:

1. Dos organizaciones forman una cooperación formal.
2. La organización propietaria del recurso concede un acceso específico mediante roles de trabajo.
3. Lo que se comparte a nivel de cooperación limita lo que la organización receptora puede luego delegar a sus propios miembros.
4. Todo el acceso queda auditable y el propietario del recurso puede revocarlo en cualquier momento.

Si la organización propietaria de una planta compartida exige 2FA, esto vale también para el Administrador receptor y para cada miembro con delegación — consulta La exigencia de dos factores, por encima de los roles.

Para conocer las reglas completas sobre cómo se acota y delega el acceso compartido, consulta Restricciones de cooperación.

Buenas prácticas

Para una gestión eficaz de los permisos en Mirox:

1. Usa los roles estándar — Los roles predefinidos de organización y de trabajo cubren la gran mayoría de las situaciones reales.
2. Ajusta el gestor a la responsabilidad — Usa el rol Asset Manager (Technical) para la propiedad de ingeniería y el rol Asset Manager (Commercial) para la propiedad de contratos y facturación.
3. Asigna en el nivel apropiado más alto — Concede a nivel de organización o de portfolio cuando el acceso deba aplicarse de forma amplia; refina a nivel de parque solo para excepciones genuinas.
4. Revisa con regularidad — Audita periódicamente los roles de los miembros y las concesiones por recurso, y establece fechas de caducidad para el acceso temporal.
5. Verifica el acceso — Confirma una configuración comprobando a qué puede llegar realmente un miembro determinado antes de confiar en ella.

Ejemplos prácticos

Gestión multiemplazamiento

Una organización que gestiona varios parques solares podría configurar:

• Un responsable de operaciones como Administrador, con control total de la organización.
• Un responsable de ingeniería como Asset Manager (Technical), encargado del estado de los componentes, los eventos y los tickets en todas las plantas.
• Un responsable financiero como Asset Manager (Commercial), que gestiona contratos, facturación y tarifas sin ningún acceso remoto a las redes de la planta.

Acceso de contratistas

Un contratista de mantenimiento invitado desde fuera podría recibir:

• Un rol de organización Externo con un rol de trabajo Gestor técnico o Visualizador en los parques concretos a los que da servicio.
• Una concesión por recurso limitada únicamente a esas plantas.
• Una fecha de caducidad para que el acceso termine automáticamente cuando finalice el encargo.

Visibilidad para inversores

A los inversores se les puede dar:

• Un rol de organización Miembro o Externo con un rol de trabajo Visualizador en portfolios concretos.
• Acceso de lectura a los datos de rendimiento y de informes, sin capacidades de gestión.

Funciones relacionadas

• Restricciones de cooperación — cómo se acota el acceso compartido entre organizaciones cooperantes
• Política de seguridad de la organización — la exigencia de 2FA y las reglas de inicio de sesión que fija una organización
• Cooperaciones — compartir plantas y portfolios más allá del límite de la organización
• Invitaciones — invitar a miembros y asignarles su rol de organización
• Tokens de API — tokens acotados para automatización e integraciones
• Registro de auditoría — quién accedió a qué dispositivos de planta y cuándo
• Tickets — la capa humana de gestión del trabajo regulada por el rol de trabajo