Système d'autorisations

La plateforme Mirox contrôle l'accès au moyen d'un modèle d'autorisations multicouche basé sur les rôles, qui vous donne un contrôle précis sur qui peut voir et modifier quelles centrales — sans vous obliger à gérer les droits individuels un par un. Les rôles assurent le regroupement ; la hiérarchie assure l'héritage.

Philosophie des autorisations

Le système d'autorisations repose sur quelques principes qui rendent l'accès à la fois sécurisé et facile à appréhender :

1. Héritage hiérarchique — L'accès suit la hiérarchie naturelle des ressources et organisations : accordez une fois en haut, et l'accès descend en cascade.
2. Moindre privilège — Chaque rôle ne porte que les droits dont sa fonction a réellement besoin.
3. Séparation des responsabilités — Le statut organisationnel et l'accès aux ressources sont deux axes distincts, de sorte que vous pouvez attribuer à quelqu'un un rôle organisationnel élevé sans exposer chaque centrale, et inversement.
4. Attribution explicite — L'accès est accordé intentionnellement, jamais présumé.
5. Sensibilité au contexte — Une même personne peut disposer de droits différents sur différentes centrales.

Ensemble, ces principes maintiennent une approche à la fois sécurisée et flexible de la gestion des accès sur l'ensemble de la plateforme Mirox.

Couches d'autorisations

Une requête traverse une séquence de vérifications. Chaque couche répond à une question ; toutes les couches concernées doivent être en accord avant que l'accès ne soit accordé.

Remarque : la couche API ne s'applique qu'aux requêtes authentifiées par un jeton API ; les sessions interactives passent directement à la couche système.

Les couches :

• Couche API (orange) — Uniquement pour les requêtes par jeton API. Elle valide le jeton et applique son groupe d'autorisations, qui ne peut jamais que restreindre ce que le propriétaire du jeton pouvait déjà faire.
• Couche système (rouge) — La première barrière pour chaque requête. Elle établit le statut au niveau de la plateforme (utilisateur ordinaire ou administrateur de la plateforme) et protège les opérations critiques pour le système, indépendamment de toute autre couche.
• Couche organisation (bleu) — Vérifie que vous appartenez à l'organisation propriétaire de la ressource et applique votre rôle d'organisation.
• Couche fonction (vert) — La vérification la plus granulaire : elle décide de ce que vous pouvez faire sur une centrale ou un portefeuille spécifique.

Le diagramme ci-dessous présente les combinaisons courantes. Les données à l'échelle de l'organisation nécessitent la vérification de l'organisation ; une centrale unique nécessite la vérification de la fonction ; de nombreuses requêtes nécessitent les deux.

Couche d'autorisation système

La couche système est la première barrière de sécurité. Elle distingue les administrateurs de la plateforme des utilisateurs ordinaires et protège les opérations à l'échelle du système :

• Les administrateurs de la plateforme peuvent effectuer des opérations à l'échelle du système.
• Les utilisateurs ordinaires ne peuvent pas réaliser d'actions affectant la plateforme elle-même.
• Cette couche n'évalue pas l'accès au niveau des fonctionnalités (comme la génération de rapports) — cela se produit plus bas.

L'intégrité du système reste protégée même si une vérification plus granulaire est mal configurée.

Couche d'autorisation d'organisation

Chaque utilisateur appartient à exactement une organisation, qui est la porte d'entrée vers les ressources :

• Les organisations possèdent des ressources (portefeuilles et parcs).
• Vous recevez votre accès de base par l'intermédiaire de votre rôle d'organisation.
• Les organisations peuvent établir des accords de coopération pour partager des ressources spécifiques au-delà de la frontière de l'organisation.

Cette couche fait respecter les frontières organisationnelles : vous n'atteignez que les ressources que votre organisation possède ou qui lui ont été accordées par une coopération.

Couche d'autorisation des ressources (fonction)

Le niveau le plus granulaire contrôle ce que vous pouvez faire sur une centrale ou un portefeuille individuel. L'accès y est exprimé sous la forme d'un rôle de fonction (voir ci-dessous) :

• Votre rôle d'organisation fournit un rôle de fonction par défaut sur chaque ressource possédée.
• Les organisations peuvent remplacer cette valeur par défaut en vous accordant un rôle de fonction spécifique sur une ressource spécifique — plus large ou plus restreint que votre valeur par défaut.
• Un octroi direct l'emporte toujours sur la valeur par défaut héritée, ce qui facilite les exceptions.

Cette couche permet un contrôle précis, parc par parc, sans modifier le rôle d'organisation de qui que ce soit.

Couche d'autorisation des jetons API

Une couche facultative pour l'automatisation et les intégrations :

• Les jetons API sont créés par les utilisateurs pour piloter des scripts et des systèmes externes.
• Un jeton ne peut jamais dépasser les autorisations de l'utilisateur qui l'a créé — il ne fait que restreindre.
• Un jeton est lié à un groupe d'autorisations qui le limite à un domaine fonctionnel (voir Groupes d'autorisations API).

Cela maintient l'automatisation sécurisée tout en respectant le principe du moindre privilège. Pour plus de détails, consultez la documentation de la fonctionnalité Jetons API.

Système de contrôle d'accès basé sur les rôles

Mirox utilise le contrôle d'accès basé sur les rôles (RBAC) avec des rôles prédéfinis sur trois axes : un rôle système à l'échelle de la plateforme, un rôle d'organisation et des rôles de fonction par ressource.

Rôles système

Les rôles système définissent le statut à l'échelle de la plateforme :

• Administrateur — Personnel de la plateforme ayant accès aux opérations et à la configuration à l'échelle du système.
• Utilisateur — Le rôle standard pour toute personne utilisant la plateforme ; aucun privilège administratif.

Rôles d'organisation

Votre rôle d'organisation est votre statut par défaut au sein de votre organisation. Les deux rôles de manager sont au cœur de la structure d'autorisations actuelle : ils vous permettent de déléguer une responsabilité de haut niveau sans céder le contrôle complet de modérateur.

Les deux rôles de manager sont des pairs — au même niveau sous Modérateur, l'un technique et l'autre commercial. Cette séparation permet à une même organisation de distinguer proprement la responsabilité d'ingénierie de la responsabilité contractuelle et de facturation.

Autorisations de ressources basées sur la fonction

Les rôles de fonction définissent ce qu'un utilisateur peut faire sur une centrale ou un portefeuille spécifique, indépendamment de son rôle d'organisation :

Le jeton entre parenthèses est l'identifiant utilisé dans les octrois API et les partages de coopération ; partout dans l'interface, vous voyez l'intitulé complet.

Groupes d'autorisations API

Les jetons API sont affectés à exactement un groupe d'autorisations qui délimite ce que le jeton peut atteindre :

• Accès complet — Les mêmes autorisations que l'utilisateur créateur, dans les limites de sa portée.
• Rapports — Limité aux fonctionnalités de rapports : génération de rapports et export de données.
• Base de données temporelle — Accès aux points d'accès de séries temporelles pour la récupération programmatique de données avec MiroxQL.

Pour les cas d'usage et exemples, consultez la documentation de la fonctionnalité Jetons API.

Héritage des autorisations

L'accès descend en cascade dans la hiérarchie des ressources, de sorte que vous accordez en haut et affinez en bas :

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

Ce modèle d'héritage signifie que :

1. L'accès issu de votre rôle d'organisation s'applique à tous les portefeuilles et parcs que votre organisation possède.
2. Un octroi au niveau du portefeuille s'applique à chaque parc de ce portefeuille.
3. Un octroi sur un parc unique affine l'accès pour ce parc seulement, en remplaçant la valeur par défaut héritée.

Correspondance entre rôle d'organisation et rôle de fonction

Lorsque vous accédez à une ressource, votre rôle d'organisation détermine automatiquement votre rôle de fonction par défaut :

Cette séparation maintient les autorisations de ressources (rôles de fonction) distinctes du statut organisationnel. Votre rôle d'organisation définit la valeur par défaut, mais des octrois explicites par ressource peuvent l'augmenter ou l'abaisser pour n'importe quelle centrale individuelle.

Coopération entre organisations

Les organisations peuvent établir des accords de coopération pour partager des ressources spécifiques au-delà de la frontière de l'organisation :

1. Deux organisations forment une coopération formelle.
2. L'organisation propriétaire de la ressource accorde un accès spécifique à l'aide de rôles de fonction.
3. Ce qui est partagé au niveau de la coopération plafonne ce que l'organisation réceptrice peut ensuite déléguer à ses propres membres.
4. Tout accès reste auditable et peut être révoqué par le propriétaire de la ressource à tout moment.

Pour connaître les règles complètes sur la manière dont l'accès partagé est délimité et délégué, consultez Restrictions de coopération.

Bonnes pratiques

Pour une gestion efficace des autorisations dans Mirox :

1. Utilisez les rôles standards — Les rôles d'organisation et de fonction prédéfinis couvrent la grande majorité des situations réelles.
2. Adaptez le manager à la responsabilité — Utilisez le rôle Asset Manager (Technical) pour la responsabilité d'ingénierie et le rôle Asset Manager (Commercial) pour la responsabilité contractuelle et de facturation.
3. Attribuez au niveau approprié le plus élevé — Accordez au niveau de l'organisation ou du portefeuille lorsque l'accès doit s'appliquer largement ; affinez au niveau du parc uniquement pour de véritables exceptions.
4. Révisez régulièrement — Auditez périodiquement les rôles des membres et les octrois par ressource, et définissez des dates d'expiration pour les accès à durée limitée.
5. Vérifiez l'accès — Confirmez une configuration en vérifiant ce qu'un membre donné peut réellement atteindre avant de vous y fier.

Exemples pratiques

Gestion multi-sites

Une organisation gérant plusieurs parcs solaires pourrait mettre en place :

• Un responsable des opérations en tant qu'Admin, avec le contrôle complet de l'organisation.
• Un responsable d'ingénierie en tant qu'Asset Manager (Technical), gérant l'état des composants, les événements et les tickets de toutes les centrales.
• Un responsable financier en tant qu'Asset Manager (Commercial), gérant les contrats et la facturation sans toucher à la configuration technique.

Accès prestataire

Un prestataire de maintenance invité de l'extérieur pourrait recevoir :

• Un rôle d'organisation Externe avec un rôle de fonction Technical Manager ou Spectateur sur les parcs spécifiques qu'il dessert.
• Un octroi par ressource limité uniquement à ces centrales.
• Une date d'expiration afin que l'accès prenne fin automatiquement à la fin de la mission.

Visibilité pour les investisseurs

On peut accorder aux investisseurs :

• Un rôle d'organisation Membre ou Externe avec un rôle de fonction Spectateur sur des portefeuilles spécifiques.
• Un accès en lecture aux données de performance et de rapport, sans aucune capacité de gestion.

Fonctionnalités associées

• Restrictions de coopération — comment l'accès partagé est délimité entre organisations coopérantes
• Coopérations — partage de centrales et de portefeuilles au-delà de la frontière de l'organisation
• Invitations — inviter des membres et attribuer leur rôle d'organisation
• Jetons API — jetons délimités pour l'automatisation et les intégrations
• Journal d'audit — qui a accédé à quels appareils de centrale et quand
• Tickets — la couche de gestion du travail humain conditionnée par le rôle de fonction