Federazione tra organizzazioni: collaborare senza compromessi

Nota: Questo articolo descrive l’architettura e il design di Mandraki. Alcune funzionalità discusse vengono rilasciate progressivamente e potrebbero non essere ancora disponibili in tutti i piani.

La collaborazione aziendale non avviene in isolamento. Le organizzazioni lavorano con partner, clienti, regolatori, fornitori e consorzi di settore. Le persone con cui ha bisogno di comunicare sono spesso al di fuori della Sua organizzazione e frequentemente al di fuori della Sua piattaforma di collaborazione.

Le soluzioni tradizionali a questo problema sono insoddisfacenti. Può invitare utenti esterni come ospiti nella Sua piattaforma, il che sfuma i confini di sicurezza e crea sovraccarico amministrativo. Può mantenere account su più piattaforme, frammentando le comunicazioni. Oppure può ripiegare sull’e-mail, che non offre nessuna delle funzionalità di collaborazione in tempo reale che il lavoro moderno richiede.

La federazione tra organizzazioni di Mandraki offre un approccio migliore: due organizzazioni possono collaborare in canali e chiamate condivisi mantenendo ciascuna la piena sovranità sui propri dati, sulle proprie politiche di sicurezza e sul proprio controllo amministrativo.

Come funziona la federazione

La federazione in Mandraki è una relazione bilaterale basata sul consenso tra due organizzazioni. Nessuna delle due parti può imporre la federazione all’altra. Il processo inizia quando un’organizzazione invia una richiesta di federazione a un’altra.

La richiesta specifica quali capacità di collaborazione l’organizzazione richiedente desidera abilitare: messaggistica, chiamate, condivisione di file e canali condivisi. L’organizzazione destinataria esamina la richiesta e può approvarla con il proprio insieme di autorizzazioni. Entrambe le parti devono essere d’accordo, e ciascuna può modificare o revocare la relazione in qualsiasi momento.

Una volta stabilita una relazione di federazione, gli utenti di entrambe le organizzazioni possono partecipare a canali e chiamate condivisi. L’esperienza è fluida — un canale condiviso appare accanto ai canali interni dell’organizzazione, e gli utenti dell’organizzazione federata sono chiaramente identificati con un badge “Esterno”.

Proprietà dei dati nei canali condivisi

Un canale condiviso in Mandraki ha un’unica organizzazione proprietaria. Le politiche dell’organizzazione proprietaria governano le impostazioni di crittografia, le politiche di conservazione e la disponibilità delle funzionalità IA del canale. Le altre organizzazioni partecipano al canale ma non ne controllano la configurazione.

In modo critico, ogni messaggio in un canale condiviso porta un originOrgId che identifica a quale organizzazione appartiene il mittente. Ciò garantisce la tracciabilità: ogni organizzazione può vedere quali messaggi provengono dai propri membri e quali da partecipanti esterni.

Per scopi di conformità, ogni organizzazione mantiene l’accesso ai messaggi inviati dai propri membri. Se un’organizzazione lascia una federazione, mantiene i propri messaggi ma perde l’accesso ai messaggi dell’altra organizzazione. La proprietà dei dati segue il confine dell’organizzazione, non il confine del canale.

Controlli di governance e policy

La federazione in Mandraki è governata da controlli policy granulari a livello di organizzazione.

Policy cross-org. Gli amministratori impostano la posizione di federazione dell’organizzazione: disabilitata (nessuna federazione consentita), solo federata (federazione solo con organizzazioni approvate) o aperta (richieste di federazione accettate per impostazione predefinita, soggette ad approvazione individuale).

Lista di consenso. Le organizzazioni possono mantenere un elenco esplicito di partner di federazione approvati. Solo le organizzazioni nell’elenco possono stabilire relazioni di federazione.

Requisito di approvazione. Quando abilitato, tutte le richieste di federazione richiedono l’approvazione esplicita dell’amministratore, anche se l’organizzazione richiedente è nella lista di consenso.

Autorizzazioni per singola funzionalità. Le relazioni di federazione hanno interruttori granulari per funzionalità. Un’organizzazione potrebbe consentire la messaggistica con un partner ma non la condivisione di file, oppure consentire chiamate ma non canali condivisi. Queste autorizzazioni possono essere modificate in qualsiasi momento.

Questi controlli riflettono la realtà che organizzazioni diverse hanno propensioni al rischio e requisiti normativi diversi. Un’istituzione finanziaria potrebbe federarsi con il proprio revisore solo per la messaggistica, senza condivisione di file. Un dipartimento governativo potrebbe federarsi con un ente di settore per canali condivisi ma richiedere approvazione per ogni nuovo partecipante.

Confini di sicurezza

La federazione non unisce i domini di sicurezza di due organizzazioni. Ogni organizzazione mantiene le proprie chiavi di crittografia, la propria gestione utenti, i propri controlli di accesso e i propri log di audit. L’SFU e il server API applicano i confini organizzativi a ogni livello.

Quando un messaggio viene inviato in un canale condiviso, viene crittografato con il contesto di crittografia del canale (che appartiene all’organizzazione proprietaria). Gli utenti delle organizzazioni federate a cui è stato concesso l’accesso possono decifrare e leggere il messaggio. Ma la relazione di federazione non concede accesso a nessun altro dato all’interno dell’organizzazione proprietaria — canali interni, messaggi diretti o impostazioni organizzative rimangono completamente isolati.

Per le chiamate in contesti federati si applica lo stesso principio. I partecipanti di entrambe le organizzazioni si uniscono alla chiamata attraverso il normale flusso di segnalazione WebRTC, autenticati rispetto alle rispettive organizzazioni. L’SFU instrada i media tra i partecipanti senza riguardo all’organizzazione di appartenenza, ma l’API applica che solo i partecipanti con autorizzazioni di federazione valide possano partecipare.

Identità dell’installazione e federazione tra installazioni

Il modello di federazione di Mandraki si estende oltre le organizzazioni all’interno di una singola installazione per supportare la comunicazione tra distribuzioni Mandraki separate — quella che chiamiamo federazione tra installazioni.

Ogni installazione Mandraki ha un’identità unica, inclusa una coppia di chiavi Ed25519 per l’autenticazione crittografica. Le installazioni pubblicano un descrittore well-known su /.well-known/eurocom-server che include la loro chiave pubblica, le capacità e la versione.

Quando due installazioni comunicano, tutti i payload sono firmati con la chiave privata dell’installazione mittente e verificati con la chiave pubblica dell’installazione destinataria. Ciò impedisce l’impersonificazione e garantisce che i messaggi di federazione siano autentici.

La federazione tra installazioni è particolarmente rilevante per le organizzazioni con requisiti di residenza dei dati. Un’installazione Mandraki in Germania può federarsi con un’installazione in Francia, consentendo la collaborazione transfrontaliera mentre ciascuna installazione mantiene la residenza dei dati all’interno della propria giurisdizione.

L’esperienza dell’utente esterno

Abbiamo prestato grande attenzione a come appaiono gli utenti federati nell’interfaccia. Gli utenti esterni sono sempre visivamente distinti con un chiaro badge “Esterno”. Questo non è opzionale o configurabile — è applicato dalla piattaforma per evitare confusione su chi sia presente in una conversazione.

Quando compone un messaggio in un canale condiviso, l’area di composizione ricorda all’utente che i partecipanti esterni possono vedere i suoi messaggi. Quando avvia una chiamata in un contesto federato, i partecipanti vedono un’indicazione chiara di quali organizzazioni sono rappresentate.

Queste decisioni di design riflettono un principio: la federazione dovrebbe rendere facile la collaborazione tra organizzazioni, ma non dovrebbe mai renderla invisibile. Gli utenti dovrebbero sempre sapere quando stanno comunicando attraverso confini organizzativi.

Il caso a favore della federazione rispetto agli account ospite

Molte piattaforme di collaborazione affrontano la comunicazione tra organizzazioni attraverso account ospite — agli utenti esterni vengono assegnati account limitati all’interno dello spazio di lavoro dell’organizzazione ospitante. Questo approccio presenta diversi svantaggi che la federazione evita.

Gli account ospite creano oneri amministrativi: qualcuno deve creare, gestire e infine disattivare ogni ospite. Gli account ospite sfumano i confini di sicurezza: l’ospite esiste all’interno del dominio di sicurezza dell’ospitante, che potrebbe non allinearsi con le politiche di sicurezza della propria organizzazione. Gli account ospite frammentano la comunicazione: l’ospite deve mantenere identità e contesti separati per ogni organizzazione con cui collabora.

La federazione mantiene ogni utente all’interno del dominio della propria organizzazione. Si autenticano con le proprie credenziali, vedono i canali della propria organizzazione accanto a quelli condivisi e sono governati dalle politiche della propria organizzazione. Nessun account ospite da gestire, nessun confine sfumato, nessuna identità frammentata.

Per le organizzazioni europee che hanno bisogno di collaborare attraverso i confini mantenendo la sovranità, la federazione è l’architettura che rende questo possibile senza compromessi.