Vuoi aprire la collaborazione tra tre enti pubblici in Microsoft Teams senza esporre la rubrica e senza cambio tenant? Questa guida pratica mostra come usare i canali condivisi e B2B Direct Connect per una condivisione sicura, governata “least‑privilege” e trasparente per gli utenti.
Panoramica della domanda
Un ente governativo (tenant host) intende aprire un canale condiviso di Microsoft Teams con due altri enti governativi, limitando rigorosamente l’accesso a file e conversazioni esclusivamente a quel canale e mantenendo un’esperienza “seamless” per gli utenti esterni (niente cambio tenant). Gli obiettivi sono:
- collaborazione e condivisione file solo all’interno del canale condiviso;
- governance con minimo privilegio (least‑privilege);
- esperienza utente fluida senza contesto cross-tenant visibile.
Le domande chiave cui rispondiamo:
- Come impostare le B2B direct connections e i gruppi di sicurezza per limitare l’accesso?
- Il modello impedisce a proprietari di altri team di invitare liberamente gli stessi utenti?
- È necessario che ogni tenant crei un proprio gruppo di sicurezza e lo condivida con gli altri?
Concetti chiave
Canali condivisi di Microsoft Teams
I canali condivisi (Shared Channels) permettono di collaborare con utenti di altri tenant senza invitarli come “ospiti” del tenant host e senza cambio di contesto. Il canale condiviso:
- genera un sito SharePoint dedicato separato dal team principale;
- isola file, schede e conversazioni ai soli membri del canale;
- non estende l’accesso al resto del team e non espone la rubrica del tenant host.
B2B Direct Connect in Microsoft Entra ID
B2B Direct Connect è il meccanismo di trust organisation‑to‑organisation che abilita gli utenti esterni a usare la propria identità “di casa” per accedere alle risorse condivise nel tenant host (in questo caso, il canale condiviso). A differenza del classico B2B Guest, l’utente esterno:
- resta autenticato nel proprio tenant e non cambia contesto;
- è soggetto alle policy di sicurezza del tenant di origine (MFA, device compliance, ecc.), che il tenant host può fidare tramite le impostazioni di Cross‑tenant Access e i relativi Trust settings (MFA, dispositivo conforme, hybrid join).
Modello least‑privilege con gruppi
Il principio architetturale è che ogni tenant governa i propri utenti in un gruppo di sicurezza dedicato, e che la connessione B2B Direct sia limitata ai soli gruppi autorizzati in ingresso/uscita. In questo modo l’accesso rimane granulare e revocabile in pochi clic.
Modello architetturale consigliato
Supponiamo tre tenant governativi: Host, Ente A, Ente B. Il canale condiviso viene creato nel tenant Host e reso disponibile agli utenti selezionati degli altri due enti tramite B2B Direct Connect a scopo esclusivo del canale.
┌───────────────────────────────────────────────────────┐
│ Tenant HOST │
│ Team X │
│ └── Canale Condiviso ─────────────────────────┐ │
│ (Sito SP dedicato) │ │
└──────────────────────────────────────────────────┼────┘
│ B2B Direct Connect (scoping a gruppi)
┌────────────────────────────────────────┐ │ ┌────────────────────────────────────────┐
│ Ente A │◄──────────────────┘ │ Ente B │
│ Gruppo "EXT-ProgettoX-ENTE-A" │ │ Gruppo "EXT-ProgettoX-ENTE-B" │
│ (utenti A autorizzati) │ │ (utenti B autorizzati) │
└────────────────────────────────────────┘ └────────────────────────────────────────┘
Punti cardine:
- Separazione: canale e sito SharePoint dedicati al canale condiviso.
- Scoping a gruppi: solo i gruppi concordati possono “vedere” il canale.
- Trust reciproco: ciascun tenant configura il proprio lato della connessione.
- Controllo inviti: una Teams Channel Policy impedisce ad altri owner di estendere la condivisione.
Passaggi di configurazione
Prerequisiti
- Ruolo amministrativo adeguato in Entra ID e Teams per ciascun tenant.
- Condivisione esterna abilitata in SharePoint/OneDrive nei limiti di sicurezza previsti dall’ente.
- Definizione dei gruppi di sicurezza dedicati al progetto in ogni tenant.
- Allineamento legale e regolatorio fra enti (accordi inter‑organizzativi, classificazioni dei dati, ecc.).
Creazione dei gruppi e scambio identificativi
- Tenant Host: crea il gruppo di sicurezza “
EXT‑ProgettoX‑HOST” (opzionale, per utenti interni con accesso al canale). - Ente A: crea il gruppo “
EXT‑ProgettoX‑ENTE‑A” e vi inserisce gli utenti da autorizzare. - Ente B: crea il gruppo “
EXT‑ProgettoX‑ENTE‑B” con i rispettivi membri. - Condividere gli Object ID: ogni tenant invia al tenant Host solo l’Object ID del proprio gruppo. Non è necessario che A e B si scambino i gruppi fra loro.
Configurazione B2B Direct Connect in Entra ID
Nel tenant Host
- Inbound: creare una Cross‑tenant access setting per il dominio di Ente A e una per Ente B, consentendo B2B Direct Connect solo per i gruppi esterni ricevuti (Object ID). È qui che si realizza il “filtro in ingresso”.
- Outbound: mantenere l’impostazione predefinita (gli utenti del tenant Host non “escono” verso A/B per B2B DC, se non serve).
- Trust: valutare di fidare le attestazioni di MFA e device compliance provenienti da A e B, così che il canale rispetti requisiti come “ammetti solo utenti MFA e da dispositivo conforme”, pur essendo verificati nel tenant di origine.
Nei tenant esterni (Ente A e Ente B)
- Outbound: creare una Cross‑tenant access setting verso il dominio del tenant Host consentendo B2B Direct Connect esclusivamente al proprio gruppo autorizzato (“scoping in uscita”).
- Inbound: mantenere predefinito, poiché non vogliamo che gli utenti del tenant Host accedano a risorse interne di A o B.
- Trust: se il tenant Host richiede MFA/device compliant da “fidare”, assicurarsi che le policy di Conditional Access del tenant esterno impongano tali requisiti agli utenti del gruppo.
Creazione del canale condiviso e condivisione
- Nel team di progetto del tenant Host, creare un Canale condiviso (non standard, non privato). Dare un nome chiaro, es.: “
Collaborazione ENTE‑A + ENTE‑B”. - Dal menu del canale, scegliere Condividi canale e aggiungere le organizzazioni esterne (domini di A e B). Selezionare l’opzione che usa B2B Direct Connect.
- Aggiungere utenti o gruppi dei tenant esterni: grazie alle impostazioni di scoping lato Entra, solo i membri dei gruppi autorizzati saranno effettivamente ammessi.
Controllo degli inviti con Teams Channel Policy
Poiché i canali condivisi non usano il modello “guest” tradizionale, la policy “solo gli admin possono invitare ospiti” non è applicabile. Per evitare che owner di altri team possano invitare esterni, definire e assegnare tramite Teams Admin Center una Teams Channel Policy che disabiliti la capacità di condividere canali con persone esterne a tutti, eccetto gli owner autorizzati del progetto.
Governance di SharePoint per il canale condiviso
- Il canale crea un sito SharePoint dedicato. Verificare che la condivisione esterna di SharePoint sia coerente con l’uso dei canali condivisi.
- Applicare eventuali etichette di riservatezza e DLP a livello di sito (o di libreria) per proteggere i file.
- Abilitare audit su attività di accesso e condivisione, mantenendo log a fini di compliance.
Conditional Access e Trust
Poiché gli utenti esterni restano nel proprio tenant, il controllo su MFA e device compliance è delegato al tenant di origine. Nel tenant Host si può richiedere che tali attestazioni siano rispettate impostando i Trust settings di Inbound e modellando una policy di Conditional Access che chieda MFA/compliant device accettando i segnali provenienti dai tenant A e B. In alternativa, si possono fissare requisiti di autenticazione specifici (es. authentication strength elevata) se la collaborazione lo richiede.
Tabella riassuntiva della soluzione
| Tema | Soluzione/Comportamento | Note operative |
|---|---|---|
| Tipologia di canale | Il canale condiviso genera un proprio sito SharePoint separato. Solo i membri del canale vedono file e conversazioni. | Protezione nativa: l’accesso non si estende al team principale né ad altri canali. |
| Controllo degli utenti | Creare un gruppo di sicurezza in ciascun tenant con gli utenti autorizzati. Scambiarsi gli Object ID dei gruppi. | Consente un filtraggio granulare in ingresso/uscita e revoche rapide. |
| Configurazione B2B Direct | Host: Inbound “allow” solo per i gruppi esterni; Outbound predefinito. Tenant esterni: Outbound “allow” solo per il proprio gruppo; Inbound predefinito. | È richiesto trust reciproco: tutti i tenant definiscono una connessione B2B Direct con scoping ai gruppi concordati. |
| Inviti e ruoli | Le Shared Channels non usano il meccanismo ospite tradizionale. Per evitare inviti non desiderati, assegnare una Teams Channel Policy che disattivi “Condividi canale con persone esterne”. | Gestibile da Teams Admin Center. Applicare la policy a tutti tranne gli owner del progetto. |
| Necessità di gruppi aggiuntivi | Ogni tenant mantiene il proprio gruppo. Non serve che A e B conoscano i gruppi dell’altro: basta scambiare i rispettivi gruppi con l’Host. | Semplifica onboarding/offboarding e riduce la superficie d’errore. |
Risposte puntuali alle domande
Domanda: Come impostare B2B Direct Connect e gruppi per limitare l’accesso?
Risposta: Ogni tenant crea un gruppo con gli utenti autorizzati. Nel tenant Host si definisce un’eccezione di Inbound B2B DC per il dominio dell’ente esterno, restringendola solo al gruppo ricevuto. Nel tenant esterno si crea la speculare eccezione di Outbound, sempre limitata al proprio gruppo. Così l’accesso è possibile esclusivamente per gli utenti membri dei gruppi autorizzati.
Domanda: Il modello impedisce a proprietari di altri team di invitare liberamente gli stessi utenti?
Risposta: Sì, applicando una Teams Channel Policy che disabilita la condivisione con esterni per tutti gli owner non autorizzati. In questo modo solo i pochi owner consentiti possono creare/estendere canali condivisi verso l’esterno.
Domanda: Ogni tenant deve creare un proprio gruppo di sicurezza e condividerlo con gli altri?
Risposta: Ogni tenant mantiene solo il proprio gruppo e invia l’Object ID al tenant Host. Non è necessario che i tenant esterni si scambino i rispettivi gruppi: il rapporto è bilaterale Host↔Ente esterno.
Playbook operativo rapido
- Definire i gruppi: “
EXT‑ProgettoX‑HOST”, “EXT‑ProgettoX‑ENTE‑A”, “EXT‑ProgettoX‑ENTE‑B”. Inserire gli utenti. - Scambiarsi gli Object ID con il tenant Host.
- Host: Cross‑tenant Inbound per A e B (B2B DC) allow solo ai gruppi esterni.
- Ente A/B: Cross‑tenant Outbound verso Host (B2B DC) allow solo al proprio gruppo.
- Host: creare il Canale condiviso nel Team di progetto.
- Host: condividere il canale con i domini di A e B, aggiungendo utenti/gruppi.
- Host: applicare la Teams Channel Policy restrittiva agli altri owner.
- Tutti: verificare l’accesso e l’apertura dei file dal client Teams e dal sito SharePoint del canale.
Esperienza utente e impatto operativo
- Gli utenti di A e B vedranno il canale nella propria app Teams senza cambiare tenant.
- La chat e i file saranno confinati al canale; nessuna visibilità su altri canali o sul team host.
- Le autorizzazioni sono governate solo tramite appartenenza al gruppo di ciascun tenant.
Varianti architetturali e scelte di design
Gruppo unico multi‑ente vs gruppi per ogni ente
È tecnicamente possibile usare un gruppo “multi‑ente” in Host e inserire account esterni come “riferimenti”. Tuttavia, la separazione per ente è preferibile perché:
- rispetta il principio least‑privilege e la sovranità di ciascuna organizzazione sui propri utenti;
- semplifica audit e access review per ente;
- accelera offboarding selettivo (revoca rapida dell’intero gruppo di A o B).
Quando preferire canali privati o B2B Guest
- Scegli canali privati se la collaborazione è solo interna al tenant Host e serve separare dati sensibili dal resto del team.
- Scegli B2B Guest se vuoi che le Conditional Access del tenant Host si applichino direttamente all’utente esterno (con cambio tenant). Paghi un prezzo in frizione utente, ma guadagni controllo “resource‑side”.
- Scegli Shared Channels + B2B DC se la priorità è seamless UX mantenendo forte controllo tramite scoping a gruppi e trust delle attestazioni di sicurezza del tenant d’origine.
Troubleshooting e errori comuni
- Non riesco ad aggiungere utenti esterni al canale: verificare che esistano due configurazioni speculari (Inbound in Host, Outbound nel tenant esterno) e che entrambe puntino agli Object ID corretti dei gruppi.
- Gli utenti esterni vedono il canale ma non aprono i file: controllare le impostazioni di condivisione esterna di SharePoint e l’eventuale DLP o etichette di riservatezza applicate al sito del canale.
- Un owner di un altro team ha condiviso con esterni: assicurarsi che la Teams Channel Policy restrittiva sia assegnata a tutti gli owner non autorizzati e che il profilo di policy disabiliti “condividi con persone esterne”.
- Si richiede MFA/dispositivo conforme ma l’utente entra lo stesso: in Host abilitare i Trust settings che accettano le attestazioni MFA/device dal tenant esterno, e nel tenant esterno garantire che il gruppo sia soggetto a una Conditional Access che imponga tali requisiti.
- Gli utenti esterni non vedono il canale nell’app: verificare che il canale sia effettivamente condiviso con le organizzazioni e che i domini siano corretti; controllare anche la propagazione delle modifiche (policy e appartenenze ai gruppi).
Best practice operative
- Naming convention: adottare un prefisso chiaro, es.
EXTScambioProgettoX_TenantY, per minimizzare errori di selezione. - Access reviews periodiche: programmare access reviews in Entra ID sui gruppi esterni, con auto‑apply per rimuovere membri inattivi o non riconfermati.
- Audit & logging: abilitare log su accessi a SharePoint e Teams; integrare con SIEM per alert su attività anomale.
- Protezione dei file: applicare etichette di sensibilità e DLP sul sito del canale, con criteri specifici per i dati governativi.
- Principio “zero trust”: richiedere MFA forte (o autenticazione passwordless) e, se possibile, device compliance; per scenari elevati, considerare restrizioni geografiche e session controls (es. limitazioni sul download).
- Segmentazione per progetto: evitare gruppi “riutilizzati” fra progetti diversi; ogni progetto dovrebbe avere il proprio set di gruppi e canali condivisi per confinare il rischio.
Considerazioni per tenant governativi
Gli ambienti governativi hanno spesso vincoli aggiuntivi su residenza del dato, interoperabilità e feature parity rispetto ad ambienti commerciali. Prima di procedere, allinearsi su:
- eventuali limitazioni di funzionalità dei canali condivisi o di B2B Direct Connect nel cloud/regione specifici;
- accordi di trattamento del dato e classificazioni adottate da ciascun ente;
- requisiti di conservazione e discovery, per mappare retention e eDiscovery sul sito del canale condiviso.
Se sono presenti vincoli che impediscono B2B DC, valutare un fallback temporaneo con B2B Guest e canali privati, mantenendo la stessa disciplina di least‑privilege fino all’abilitazione dei canali condivisi.
Checklist finale
- Gruppi creati in tutti i tenant con naming coerente.
- Object ID scambiati con l’Host.
- Cross‑tenant Access impostato: Inbound (Host) e Outbound (A/B) limitati ai gruppi.
- Trust settings definiti secondo i requisiti (MFA, device compliance).
- Canale condiviso creato e condiviso con i domini esterni corretti.
- Teams Channel Policy assegnata in modo restrittivo.
- SharePoint: condivisione esterna, DLP ed etichette verificate.
- Audit attivo e access reviews programmate.
Risultato atteso
- Solo i membri dei gruppi autorizzati accedono a canale e relativo SharePoint.
- Gli utenti esterni non vedono altri canali o team del tenant Host.
- Gli owner interni non possono invitare liberamente esterni grazie alla channel policy.
- L’esperienza è tenant‑seamless: nessun cambio di organizzazione nell’app Teams.
Appendice con esempi di configurazione
Esempio di scoping logico
// HOST - Inbound verso ENTE A
Allow B2B Direct Connect:
Applications: Microsoft Teams (shared channels)
Target: Group Object ID di "EXT‑ProgettoX‑ENTE‑A"
Trust:
Accept MFA claims: true
Accept Device Compliance claims: true
// ENTE A - Outbound verso HOST
Allow B2B Direct Connect:
Target: Group Object ID di "EXT‑ProgettoX‑ENTE‑A"
Conditional Access:
Enforce MFA / Device compliant per i membri del gruppo Linee guida per la policy di Teams
- Creare una policy di canale con “Condividi con persone esterne” = Disabilitato.
- Assegnarla a tutti gli owner ad eccezione del gruppo ristretto che governa il progetto.
- Monitorare periodicamente l’elenco degli assegnatari della policy per evitare regressioni.
Domande frequenti
Posso aggiungere un intero team esterno come membro del canale?
Meglio evitare: prediligere gruppi di sicurezza che contengono solo i profili necessari. Così si riducono errori e si mantiene il perimetro minimo.
Come gestisco gli appaltatori temporanei?
Inseriscili nei gruppi del loro tenant di origine e stabilisci durate definite nelle access reviews. Al termine, vengono rimossi dal gruppo e perdono automaticamente l’accesso.
Come gestire break‑glass e emergenze?
Prevedi un gruppo di emergenza con processi di approvazione e log dedicati; evita accessi perpetui o non tracciati.
In sintesi: con canali condivisi di Teams e B2B Direct Connect, tre enti governativi possono collaborare in modo sicuro e fluido. La chiave è lo scoping a gruppi in Inbound/Outbound, l’uso di Teams Channel Policy per bloccare inviti non autorizzati e la governance costante su SharePoint, DLP e audit.
Risposta e soluzione, in breve
| Tema | Soluzione/Comportamento | Note operative |
|---|---|---|
| Tipologia di canale | Canale condiviso con sito SharePoint dedicato; visibilità limitata ai membri. | Isolamento nativo rispetto al team principale. |
| Controllo utenti | Un gruppo per tenant; scambio Object ID con l’Host. | Filtraggio granulare in ingresso/uscita. |
| Configurazione B2B Direct | Host Inbound allow solo gruppi esterni; Esterni Outbound allow solo il proprio gruppo. | Trust reciproco fra tenant coinvolti. |
| Inviti e ruoli | Usare Teams Channel Policy per impedire inviti esterni non autorizzati. | Gestione via Teams Admin Center. |
| Gruppi aggiuntivi | Ogni tenant mantiene solo il proprio gruppo; non serve interscambio tra esterni. | Semplifica onboarding/offboarding. |
Applicando questa architettura, ottieni la combinazione desiderata: sicurezza perimetrata, governance essenziale e user experience senza attriti.