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:

1. Ereditarietà gerarchica — L'accesso segue la gerarchia naturale di risorse e organizzazioni: concedi una volta in alto e fluisce verso il basso.
2. Privilegio minimo — Ogni ruolo porta con sé solo i diritti di cui la sua mansione ha effettivamente bisogno.
3. 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.
4. Assegnazione esplicita — L'accesso viene concesso intenzionalmente, mai presunto.
5. 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).
• A un token non viene mai chiesto un secondo fattore, e le regole sulla durata dell'accesso non lo fanno terminare. Una sola regola: un utente senza secondo fattore non può creare un nuovo token finché la sua organizzazione richiede l'autenticazione a due fattori (2FA).

Questo mantiene l'automazione sicura rispettando il privilegio minimo. Per i dettagli, consulta la documentazione della funzionalità Token API.

Obbligo di 2FA in aggiunta ai ruoli

I ruoli decidono quali impianti puoi raggiungere. Un'organizzazione può aggiungere una condizione: può richiedere l'autenticazione a due fattori (2FA) per l'accesso ai suoi impianti.

• Un ruolo concede l'impianto. L'obbligo decide se ti viene mostrato. Se l'organizzazione proprietaria di un impianto richiede la 2FA e il tuo account non ha un secondo fattore (app di autenticazione o passkey), non vedi gli impianti di quell'organizzazione — qualunque ruolo tu abbia su di essi.
• Non viene tolto nulla. I tuoi ruoli e le tue concessioni restano come sono. Resti connesso, e un avviso nell'intestazione ti invita ad attivare la 2FA. Appena la attivi, gli impianti tornano visibili.
• Decide il proprietario dell'impianto. L'obbligo vale per tutti quelli che raggiungono l'impianto: i membri dell'organizzazione e gli utenti di un partner di cooperazione.

Chi imposta l'obbligo e cosa esattamente viene nascosto è descritto nella pagina Criterio di sicurezza dell'organizzazione.

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.

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.

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.

Contenuti condivisi dell'organizzazione. Admin, Moderatori e i due ruoli Asset Manager creano, duplicano, modificano ed eliminano i modelli, i capitoli e le metriche dei report dell'organizzazione, i suoi modelli e le sue formule di esportazione dati, e le regole, i destinatari, i modelli e i silenziamenti del Gestore allarmi; i Membri li vedono e li usano. Un elemento contrassegnato come Privato lo modificano solo chi lo ha creato, un Admin o un Moderatore — vedi Report e Gestore allarmi. I trader diretti restano riservati ad Admin e Moderatori.

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:

Responsabile sicurezza si assegna solo in modo esplicito. Nessun ruolo dell'organizzazione vi corrisponde: nessuno diventa responsabile sicurezza entrando in un'organizzazione. Viene concesso deliberatamente, per impianto o per portafoglio, oppure condiviso tramite una cooperazione.

Anche Committente si assegna solo in modo esplicito, ed è l'unico ruolo la cui assegnazione può restringere un account: le assegnazioni si sommano, quindi un Membro che riceve un'assegnazione Committente mantiene l'accesso Visualizzatore del Membro — la vista limitata ha effetto solo per un membro Esterno o una condivisione tramite cooperazione. Un'assegnazione Committente può avere una data di scadenza.

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.
• Metric Export — Limitato alla lettura dell'esportazione dati: metriche come serie temporali, modelli di esportazione, il catalogo delle metriche, informazioni sull'impianto ed eventi. Non può modificare nulla.
• Timeseries Database — Accesso agli endpoint delle serie temporali per leggere le serie di misura grezze.

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:

1. L'accesso derivante dal tuo ruolo organizzativo si applica a tutti i portfolio e i parchi di cui la tua organizzazione è proprietaria.
2. Una concessione a livello di portfolio si applica a ogni parco di quel portfolio.
3. 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:

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.

Cooperazione tra organizzazioni

Le organizzazioni possono stabilire accordi di cooperazione per condividere risorse specifiche oltre il confine dell'organizzazione:

1. Due organizzazioni formano una cooperazione formale.
2. L'organizzazione proprietaria della risorsa concede accesso specifico utilizzando i ruoli di mansione.
3. Ciò che viene condiviso a livello di cooperazione limita ciò che l'organizzazione ricevente può poi delegare ai propri membri.
4. Tutti gli accessi rimangono verificabili e possono essere revocati dal proprietario della risorsa in qualsiasi momento.

Se l'organizzazione proprietaria di un impianto condiviso richiede la 2FA, questo vale anche per l'Admin ricevente e per ogni membro delegato — vedi Obbligo di 2FA in aggiunta ai ruoli.

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:

1. Usa i ruoli standard — I ruoli organizzativi e di mansione predefiniti coprono la grande maggioranza delle situazioni reali.
2. 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.
3. 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.
4. Rivedi regolarmente — Verifica periodicamente i ruoli dei membri e le concessioni per risorsa e imposta date di scadenza per gli accessi a tempo limitato.
5. 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, fatturazione e tariffe senza alcun accesso remoto alle reti dell'impianto.

Accesso per appaltatori

Un appaltatore di manutenzione invitato dall'esterno potrebbe ricevere:

• Un ruolo organizzativo Esterno con un ruolo di mansione Responsabile Tecnico 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
• Criterio di sicurezza dell'organizzazione — l'obbligo di 2FA e le regole di accesso che un'organizzazione imposta
• 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