Sistema di permessi
La piattaforma Mirox controlla l'accesso attraverso un modello di permessi a livelli e basato sui ruoli, che ti offre un controllo preciso su chi può vedere e modificare quali impianti — senza costringerti a gestire i singoli diritti uno per uno. I ruoli si occupano del raggruppamento; la gerarchia si occupa dell'ereditarietà.
Filosofia dei permessi
Il sistema di permessi si fonda su alcuni principi che mantengono l'accesso sia sicuro sia facile da comprendere:
- Ereditarietà gerarchica — L'accesso segue la gerarchia naturale di risorse e organizzazioni: concedi una volta in alto e fluisce verso il basso.
- Privilegio minimo — Ogni ruolo porta con sé solo i diritti di cui la sua mansione ha effettivamente bisogno.
- Separazione delle responsabilità — Posizione organizzativa e accesso alle risorse sono due assi distinti, così puoi assegnare a qualcuno un ruolo organizzativo elevato senza esporre ogni impianto, e viceversa.
- Assegnazione esplicita — L'accesso viene concesso intenzionalmente, mai presunto.
- Consapevolezza del contesto — La stessa persona può avere diritti diversi su impianti diversi.
Insieme, questi principi mantengono un approccio sicuro ma flessibile alla gestione dell'accesso attraverso la piattaforma Mirox.
Livelli di permesso
Una richiesta attraversa una sequenza di controlli. Ogni livello risponde a una domanda; tutti i livelli pertinenti devono concordare prima che l'accesso venga concesso.
Nota: il livello API si applica solo alle richieste autenticate con un token API; le sessioni interattive passano direttamente al livello di sistema.
I livelli:
- Livello API (arancione) — Solo per le richieste con token API. Convalida il token e applica il suo gruppo di permessi, che può solo ed esclusivamente restringere ciò che il proprietario del token poteva già fare.
- Livello di sistema (rosso) — Il primo varco per ogni richiesta. Stabilisce la posizione a livello di piattaforma (utente regolare vs. amministratore della piattaforma) e protegge le operazioni critiche per il sistema indipendentemente da qualsiasi altro livello.
- Livello organizzazione (blu) — Conferma che appartieni all'organizzazione proprietaria della risorsa e applica il tuo ruolo organizzativo.
- Livello mansione (verde) — Il controllo più granulare: decide cosa puoi fare su uno specifico impianto o portfolio.
Il diagramma seguente mostra le combinazioni più comuni. I dati a livello di organizzazione richiedono il controllo dell'organizzazione; un singolo impianto richiede il controllo della mansione; molte richieste richiedono entrambi.
Livello di permesso di sistema
Il livello di sistema è il primo varco di sicurezza. Distingue gli amministratori della piattaforma dagli utenti regolari e protegge le operazioni a livello di sistema:
- Gli amministratori della piattaforma possono eseguire operazioni a livello di sistema.
- Gli utenti regolari non possono intraprendere azioni che incidono sulla piattaforma stessa.
- Questo livello non valuta l'accesso a livello di funzionalità (come la generazione di report) — ciò avviene più in basso.
L'integrità del sistema rimane protetta anche se un controllo più granulare è configurato in modo errato.
Livello di permesso dell'organizzazione
Ogni utente appartiene esattamente a una organizzazione, che è il varco di accesso alle risorse:
- Le organizzazioni possiedono risorse (portfolio e parchi).
- Ricevi il tuo accesso di base attraverso il tuo ruolo organizzativo.
- Le organizzazioni possono stabilire accordi di cooperazione per condividere risorse specifiche oltre il confine dell'organizzazione.
Questo livello applica i confini organizzativi: raggiungi solo le risorse di cui la tua organizzazione è proprietaria o che le sono state concesse tramite una cooperazione.
Livello di permesso delle risorse (mansione)
Il livello più granulare controlla cosa puoi fare su un singolo impianto o portfolio. L'accesso qui è espresso come un ruolo di mansione (vedi sotto):
- Il tuo ruolo organizzativo fornisce un ruolo di mansione predefinito su ogni risorsa posseduta.
- Le organizzazioni possono sovrascrivere quel valore predefinito concedendoti un ruolo di mansione specifico su una risorsa specifica — più ampio o più ristretto del tuo valore predefinito.
- Una concessione diretta prevale sempre sul valore predefinito ereditato, così le eccezioni sono semplici.
Questo livello consente un controllo preciso, per singolo impianto, senza modificare il ruolo organizzativo di nessuno.
Livello di permesso del token API
Un livello opzionale per automazione e integrazioni:
- I token API vengono creati dagli utenti per pilotare script e sistemi esterni.
- Un token non può mai superare i permessi dell'utente che lo ha creato — può solo restringere.
- Un token è vincolato a un gruppo di permessi che ne limita l'ambito a un'area di funzionalità (vedi Gruppi di permessi API).
Questo mantiene l'automazione sicura rispettando il privilegio minimo. Per i dettagli, consulta la documentazione della funzionalità Token API.
Sistema di controllo degli accessi basato sui ruoli
Mirox utilizza il controllo degli accessi basato sui ruoli (RBAC) con ruoli predefiniti su tre assi: un ruolo di sistema a livello di piattaforma, un ruolo organizzativo e ruoli di mansione per risorsa.
Ruoli di sistema
I ruoli di sistema definiscono la posizione a livello di piattaforma:
- Amministratore — Personale della piattaforma con accesso alle operazioni e alla configurazione a livello di sistema.
- Utente — Il ruolo standard per chiunque utilizzi la piattaforma; nessun privilegio amministrativo.
Account demo
Esiste anche un ruolo demo limitato per gli account di valutazione. Si comporta come un utente regolare con diritti ridotti e non è qualcosa che ti assegni da solo.
Ruoli organizzativi
Il tuo ruolo organizzativo è la tua posizione predefinita all'interno della tua organizzazione. I due ruoli di manager sono il cuore dell'attuale struttura dei permessi: ti permettono di delegare responsabilità di livello elevato senza cedere il pieno controllo da moderatore.
| Ruolo organizzativo | A chi è destinato |
|---|---|
| Admin | Gestisce ogni aspetto dell'organizzazione — membri, cooperazioni, fatturazione e tutte le risorse. |
| Moderatore | Gestisce membri e risorse con ampia autorità operativa, appena al di sotto del pieno controllo dell'organizzazione. |
| Asset Manager (Technical) | Asset manager tecnico. Gestione completa di impianti e portfolio, incluse le azioni tecniche distruttive e la gestione completa dei ticket. |
| Asset Manager (Commercial) | Asset manager commerciale. Gestisce impianti, portfolio e dati commerciali, ma non può eseguire azioni tecniche distruttive e può solo leggere e creare ticket. |
| Membro | Membro standard con accesso in lettura alle risorse dell'organizzazione. |
| Esterno | Posizione limitata senza accesso predefinito alle risorse; raggiunge le risorse solo tramite concessioni esplicite. |
I due ruoli di manager sono fratelli — pari sotto il Moderatore, uno tecnico e uno commerciale. Questa suddivisione consente a una singola organizzazione di separare in modo netto la titolarità ingegneristica da quella contrattuale e di fatturazione.
Assegnazione consapevole dei pari
Puoi assegnare solo ruoli al tuo livello o inferiori, e i due ruoli di manager non possono assegnarsi a vicenda. Un Asset Manager (Technical) può invitare membri, esterni e altri Asset Manager (Technical); un Asset Manager (Commercial) può invitare membri, esterni e altri Asset Manager (Commercial). Solo i Moderatori e gli Admin possono concedere uno qualsiasi dei due ruoli di manager.
Permessi sulle risorse basati sulla mansione
I ruoli di mansione definiscono cosa un utente può fare su uno specifico impianto o portfolio, indipendentemente dal suo ruolo organizzativo:
| Ruolo di mansione | Accesso |
|---|---|
Operatore (operator) | Accesso operativo completo: gestione di configurazione, componenti, eventi, ticket e impostazioni. |
Technical Manager (tom) | Autorità tecnica su una risorsa, inclusa la gestione di componenti/eventi e l'amministrazione completa dei ticket. |
Asset Manager (com) | Autorità commerciale; gestisce la risorsa ma non può eseguire azioni tecniche distruttive e può solo leggere e creare ticket. |
Visualizzatore (viewer) | Accesso in sola lettura ai dati e alle metriche di prestazione di una risorsa. |
| None | Nessun accesso. |
Il token tra parentesi è l'identificatore utilizzato nelle concessioni API e nelle condivisioni di cooperazione; ovunque nell'interfaccia vedi l'etichetta estesa.
Gruppi di permessi API
I token API sono assegnati esattamente a un gruppo di permessi che ne limita l'ambito di accesso:
- Full Access — Gli stessi permessi dell'utente che lo crea, all'interno del suo ambito.
- Reporting — Limitato alle funzionalità di reporting: generazione di report ed esportazione di dati.
- Timeseries Database — Accesso agli endpoint delle serie temporali per il recupero programmatico dei dati con MiroxQL.
Per casi d'uso ed esempi, consulta la documentazione della funzionalità Token API.
Ereditarietà dei permessi
L'accesso fluisce verso il basso lungo la gerarchia delle risorse, così concedi in alto e affini in basso:
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
Questo modello di ereditarietà significa che:
- L'accesso derivante dal tuo ruolo organizzativo si applica a tutti i portfolio e i parchi di cui la tua organizzazione è proprietaria.
- Una concessione a livello di portfolio si applica a ogni parco di quel portfolio.
- Una concessione su un singolo parco affina l'accesso solo per quel parco, sovrascrivendo il valore predefinito ereditato.
Mappatura dal ruolo organizzativo al ruolo di mansione
Quando accedi a una risorsa, il tuo ruolo organizzativo determina automaticamente il tuo ruolo di mansione predefinito:
| Ruolo organizzativo | Ruolo di mansione predefinito |
|---|---|
| Admin | Operatore (gestione completa delle risorse) |
| Moderatore | Operatore (gestione completa delle risorse) |
| Asset Manager (Technical) | Technical Manager (autorità tecnica) |
| Asset Manager (Commercial) | Asset Manager (autorità commerciale) |
| Membro | Visualizzatore (accesso in sola lettura) |
| Esterno | None (nessun accesso predefinito alle risorse) |
Questa separazione mantiene i permessi sulle risorse (ruoli di mansione) distinti dalla posizione organizzativa. Il tuo ruolo organizzativo imposta il valore predefinito, ma concessioni esplicite per risorsa possono alzarlo o abbassarlo per qualsiasi singolo impianto.
Autorità commerciale vs. tecnica
I due ruoli di manager si mappano su due distinti ruoli di mansione. Un Asset Manager (Technical) (ruolo di mansione Technical Manager) può eliminare componenti ed eventi e amministrare completamente i ticket. Un Asset Manager (Commercial) (ruolo di mansione Asset Manager) mantiene la gestione di impianti e portfolio ma non può eliminare componenti o eventi e può solo leggere e creare ticket, mai chiuderli, riaprirli o eliminarli.
Cooperazione tra organizzazioni
Le organizzazioni possono stabilire accordi di cooperazione per condividere risorse specifiche oltre il confine dell'organizzazione:
- Due organizzazioni formano una cooperazione formale.
- L'organizzazione proprietaria della risorsa concede accesso specifico utilizzando i ruoli di mansione.
- Ciò che viene condiviso a livello di cooperazione limita ciò che l'organizzazione ricevente può poi delegare ai propri membri.
- Tutti gli accessi rimangono verificabili e possono essere revocati dal proprietario della risorsa in qualsiasi momento.
Solo accesso amministratore
Solo gli amministratori dell'organizzazione cooperante possono raggiungere le risorse condivise. Membri regolari, manager ed esterni non possono accedere alle risorse di cooperazione anche quando la cooperazione esiste.
Per le regole complete su come l'accesso condiviso viene delimitato e delegato, consulta Restrizioni di cooperazione.
Buone pratiche
Per una gestione efficace dei permessi in Mirox:
- Usa i ruoli standard — I ruoli organizzativi e di mansione predefiniti coprono la grande maggioranza delle situazioni reali.
- Abbina il manager alla responsabilità — Usa il ruolo Asset Manager (Technical) per la titolarità ingegneristica e il ruolo Asset Manager (Commercial) per la titolarità contrattuale e di fatturazione.
- Assegna al livello più appropriato — Concedi a livello di organizzazione o portfolio quando l'accesso deve applicarsi ampiamente; affina a livello di parco solo per autentiche eccezioni.
- Rivedi regolarmente — Verifica periodicamente i ruoli dei membri e le concessioni per risorsa e imposta date di scadenza per gli accessi a tempo limitato.
- Verifica l'accesso — Conferma una configurazione controllando ciò che un determinato membro può effettivamente raggiungere prima di farci affidamento.
Esempi pratici
Gestione multi-sito
Un'organizzazione che gestisce diversi parchi solari potrebbe configurare:
- Un responsabile delle operazioni come Admin, con il pieno controllo dell'organizzazione.
- Un titolare ingegneristico come Asset Manager (Technical), che si occupa dello stato dei componenti, degli eventi e dei ticket su tutti gli impianti.
- Un titolare finanziario come Asset Manager (Commercial), che gestisce contratti e fatturazione senza toccare la configurazione tecnica.
Accesso per appaltatori
Un appaltatore di manutenzione invitato dall'esterno potrebbe ricevere:
- Un ruolo organizzativo Esterno con un ruolo di mansione Technical Manager o Visualizzatore sui parchi specifici che serve.
- Una concessione per risorsa limitata solo a quegli impianti.
- Una data di scadenza in modo che l'accesso termini automaticamente al termine dell'incarico.
Visibilità per investitori
Agli investitori può essere assegnato:
- Un ruolo organizzativo Membro o Esterno con un ruolo di mansione Visualizzatore su portfolio specifici.
- Accesso in lettura ai dati di prestazione e ai report, senza capacità di gestione.
Funzionalità correlate
- Restrizioni di cooperazione — come l'accesso condiviso viene delimitato tra organizzazioni cooperanti
- Cooperazioni — condivisione di impianti e portfolio oltre il confine dell'organizzazione
- Inviti — invitare membri e assegnare il loro ruolo organizzativo
- Token API — token con ambito limitato per automazione e integrazioni
- Registro di audit — chi ha avuto accesso a quali dispositivi di impianto e quando
- Ticket — il livello umano di gestione del lavoro regolato dal ruolo di mansione