MiroxMirox
  • Piattaforma

    • Filosofia
    • Panoramica della piattaforma
    • Risorse della piattaforma
  • Mirox-Cloud

    • Panoramica del cloud
    • Microservizi connessi
  • Mirox-Agent

    • Panoramica dell'agente
    • Opzioni di distribuzione
    • Data Scraper
    • Gemello digitale
  • Dettagli tecnici

    • Raccolta delle metriche
  • Informazioni

    • Impianti supportati
  • Tipi di impianto

    • Impianti solari
    • Parchi eolici
    • Accumulo a batteria
  • Monitoraggio e visualizzazione

    • Monitoraggio in tempo reale
    • Gemello digitale
    • Stati dei componenti
    • Rilevamento delle perdite
    • Rilevamento dell'efficienza
    • Dashboard KPI
  • Gestione dei dati

    • Eventi
    • Ticket
    • Previsioni
    • Report
  • Integrazione e condivisione

    • Cooperazioni
    • Token API
    • VPN
    • Proxy
  • IA

    • Assistente IA e wizard
    • Accesso agentico (MCP)
  • Fatturazione

    • Mercato e tariffe
    • Contabilità e fatturazione
  • Collaborazione

    • Inviti
  • Sicurezza

    • Autenticazione
    • Sistema di permessi
    • Restrizioni di cooperazione
    • Audit log degli accessi
  • Nodi

    • mrxnode
  • Applicazione

    • Controllo della porta
    • Relè generico
  • Cluster edge

    • Orchestrazione
  • Per iniziare

    • Per iniziare
  • Personale

    • Usare la VPN
    • Usare il proxy
    • Autenticazione a due fattori
    • Sessioni
    • Token API
  • Per impianto

    • Contatti
    • Dispositivi di rete
    • Datalogger
    • Componenti
    • VPN diretta (per agente)
  • Organizzazione

    • Permessi dei membri
    • Cooperazioni
    • Archiviazione file
  • Esportazione di dati

    • API di esportazione metriche
    • MiroxQL — linguaggio di query
    • Generazione esterna di report
    • Grafana
    • Panoramica dell'API
  • Assistenza

    • Richiedi una guida all'integrazione
  • mrxnode

    • Panoramica
    • Guide
    • Distribuzione su container
    • Riferimento comandi
    • Risoluzione dei problemi
  • Reportistica

    • Generatore di report esterno
  • English
  • Deutsch
  • Español
  • Français
  • Português
  • Italiano
  • English
  • Piattaforma

    • Filosofia
    • Panoramica della piattaforma
    • Risorse della piattaforma
  • Mirox-Cloud

    • Panoramica del cloud
    • Microservizi connessi
  • Mirox-Agent

    • Panoramica dell'agente
    • Opzioni di distribuzione
    • Data Scraper
    • Gemello digitale
  • Dettagli tecnici

    • Raccolta delle metriche
  • Informazioni

    • Impianti supportati
  • Tipi di impianto

    • Impianti solari
    • Parchi eolici
    • Accumulo a batteria
  • Monitoraggio e visualizzazione

    • Monitoraggio in tempo reale
    • Gemello digitale
    • Stati dei componenti
    • Rilevamento delle perdite
    • Rilevamento dell'efficienza
    • Dashboard KPI
  • Gestione dei dati

    • Eventi
    • Ticket
    • Previsioni
    • Report
  • Integrazione e condivisione

    • Cooperazioni
    • Token API
    • VPN
    • Proxy
  • IA

    • Assistente IA e wizard
    • Accesso agentico (MCP)
  • Fatturazione

    • Mercato e tariffe
    • Contabilità e fatturazione
  • Collaborazione

    • Inviti
  • Sicurezza

    • Autenticazione
    • Sistema di permessi
    • Restrizioni di cooperazione
    • Audit log degli accessi
  • Nodi

    • mrxnode
  • Applicazione

    • Controllo della porta
    • Relè generico
  • Cluster edge

    • Orchestrazione
  • Per iniziare

    • Per iniziare
  • Personale

    • Usare la VPN
    • Usare il proxy
    • Autenticazione a due fattori
    • Sessioni
    • Token API
  • Per impianto

    • Contatti
    • Dispositivi di rete
    • Datalogger
    • Componenti
    • VPN diretta (per agente)
  • Organizzazione

    • Permessi dei membri
    • Cooperazioni
    • Archiviazione file
  • Esportazione di dati

    • API di esportazione metriche
    • MiroxQL — linguaggio di query
    • Generazione esterna di report
    • Grafana
    • Panoramica dell'API
  • Assistenza

    • Richiedi una guida all'integrazione
  • mrxnode

    • Panoramica
    • Guide
    • Distribuzione su container
    • Riferimento comandi
    • Risoluzione dei problemi
  • Reportistica

    • Generatore di report esterno
  • English
  • Deutsch
  • Español
  • Français
  • Português
  • Italiano
  • English
  • Monitoraggio e visualizzazione

    • Monitoraggio in tempo reale
    • Gemello digitale
    • Stati dei componenti
    • Rilevamento delle perdite
    • Rilevamento Efficienza (PRRC)
    • Local Network Inspector
    • Monitoraggio degli accessi
    • Dashboard KPI
    • Visualizzazione a grafici
  • Gestione dei dati

    • Eventi
    • Ticket
    • Previsioni
    • Report
  • Integrazione e condivisione

    • Cooperazioni
    • Token API
    • VPN
    • Proxy (Accesso web ai dispositivi dell'impianto)
  • IA

    • Assistente AI e Wizard
    • Accesso agentico (MCP)
  • Fatturazione

    • Mercato e tariffe
    • Contabilità e fatturazione
  • Collaborazione

    • Inviti
  • Sicurezza

    • Autenticazione
    • Sistema di permessi
    • Restrizioni dei permessi di cooperazione
    • Audit Logging degli Accessi

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).

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 organizzativoA chi è destinato
AdminGestisce ogni aspetto dell'organizzazione — membri, cooperazioni, fatturazione e tutte le risorse.
ModeratoreGestisce 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.
MembroMembro standard con accesso in lettura alle risorse dell'organizzazione.
EsternoPosizione 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 mansioneAccesso
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.
NoneNessun 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:

  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:

Ruolo organizzativoRuolo di mansione predefinito
AdminOperatore (gestione completa delle risorse)
ModeratoreOperatore (gestione completa delle risorse)
Asset Manager (Technical)Technical Manager (autorità tecnica)
Asset Manager (Commercial)Asset Manager (autorità commerciale)
MembroVisualizzatore (accesso in sola lettura)
EsternoNone (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:

  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.

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:

  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 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
Prev
Autenticazione
Next
Restrizioni dei permessi di cooperazione
MIT Licensed | Copyright 2026 Mirox Verwaltungs GmbH