Isolamento delle risorse con più tenant
Esistono scenari specifici quando la delega dell'amministrazione in un singolo limite del tenant non soddisfa le esigenze. In questa sezione sono previsti requisiti che possono essere necessari per creare un'architettura multi-tenant. Le organizzazioni multi-tenant possono estendersi su due o più tenant di Microsoft Entra. Ciò può comportare requisiti univoci di collaborazione e gestione tra tenant. Le architetture multi-tenant aumentano il sovraccarico di gestione e la complessità e devono essere usate con cautela. È consigliabile usare un singolo tenant se le esigenze possono essere soddisfatte con tale architettura. Per informazioni più dettagliate, vedere Gestione utenti multi-tenant.
Un tenant separato crea un nuovo limite e quindi la gestione disaccoppiata dei ruoli della directory di Microsoft Entra, degli oggetti directory, dei criteri di Accesso condizionale, dei gruppi di risorse di Azure, dei gruppi di gestione di Azure e di altri controlli, come descritto nelle sezioni precedenti.
Un tenant separato è utile per il reparto IT di un'organizzazione per convalidare le modifiche a livello di tenant nei servizi Microsoft, ad esempio Intune, Microsoft Entra Connect o una configurazione di autenticazione ibrida, proteggendo al tempo stesso gli utenti e le risorse di un'organizzazione. Sono incluse le configurazioni del servizio di test che potrebbero avere effetti a livello di tenant e che non possono essere limitati a un subset di utenti nel tenant di produzione.
La distribuzione di un ambiente non di produzione in un tenant separato potrebbe essere necessaria durante lo sviluppo di applicazioni personalizzate in grado di modificare i dati degli oggetti utente di produzione con MS Graph o API simili, ad esempio le applicazioni a cui è concesso Directory.ReadWrite.All o un ambito wide simile.
Nota
Sincronizzazione di Microsoft Entra Connect a più tenant, che può essere utile quando si distribuisce un ambiente non di produzione in un tenant separato. Per altre informazioni, vedere Microsoft Entra Connect: Topologie supportate.
Risultati
Oltre ai risultati ottenuti con un'architettura a tenant singolo, come descritto in precedenza, le organizzazioni possono separare completamente le interazioni tra risorse e tenant:
Separazione delle risorse
Visibilità: le risorse in un tenant separato non possono essere individuate o enumerate da utenti e amministratori in altri tenant. Analogamente, i report sull'utilizzo e i log di audit sono contenuti entro il nuovo limite del tenant. Questa separazione della visibilità consente alle organizzazioni di gestire le risorse necessarie per i progetti riservati.
Footprint degli oggetti: le applicazioni che scrivono in Microsoft Entra ID e/o altri servizi online Microsoft tramite Microsoft Graph o altre interfacce di gestione possono operare in uno spazio di oggetti separato. In questo modo i team di sviluppo possono eseguire test durante il ciclo di vita di sviluppo software senza influire sugli altri tenant.
Quote: il consumo di quote e limiti di Azure a livello di tenant è separato da quello degli altri tenant.
Separazione della configurazione
Un nuovo tenant fornisce un set separato di impostazioni a livello di tenant in grado di supportare risorse e applicazioni attendibili che hanno requisiti che richiedono configurazioni diverse a livello di tenant. Inoltre, un nuovo tenant fornisce un nuovo set di servizi Microsoft Online, ad esempio Office 365.
Separazione amministrativa
Un nuovo limite del tenant prevede un set separato di ruoli della directory Microsoft Entra, che consente di configurare diversi set di amministratori.
Utilizzo comune
Il diagramma seguente illustra un utilizzo comune per l'isolamento delle risorse in più tenant: un ambiente di pre-produzione o "sandbox" che richiede più separazione di quanto sia possibile ottenere con l'amministrazione delegata in un singolo tenant.
Contoso è un'organizzazione che ha ampliato l'architettura del tenant aziendale con un tenant di pre-produzione denominato ContosoSandbox.com. Il tenant sandbox viene usato per supportare lo sviluppo continuo di soluzioni aziendali che scrivono in Microsoft Entra ID e Microsoft 365 usando Microsoft Graph. Queste soluzioni vengono distribuite nel tenant aziendale.
Il tenant sandbox viene portato online per impedire alle applicazioni in fase di sviluppo di influire direttamente o indirettamente sui sistemi di produzione, usando risorse tenant e influisce sulle quote o sulla limitazione.
I developer richiedono l'accesso al tenant sandbox durante il ciclo di vita di sviluppo, idealmente con l'accesso self-service che richiede autorizzazioni aggiuntive limitate nell'ambiente di produzione. Esempi di queste autorizzazioni aggiuntive possono includere la creazione, l'eliminazione e l'aggiornamento degli account utente, la registrazione di applicazioni, il provisioning e il deprovisioning delle risorse di Azure e le modifiche ai criteri o alla configurazione complessiva dell'ambiente.
In questo esempio Contoso usa Collaborazione B2B di Microsoft Entra per effettuare il provisioning degli utenti dal tenant aziendale e abilitare gli utenti in grado di gestire e accedere alle risorse nelle applicazioni nel tenant sandbox senza gestire diverse credenziali. Questa funzionalità è principalmente orientata agli scenari di collaborazione tra organizzazioni. Tuttavia, le aziende con più tenant come Contoso possono usare questa funzionalità per evitare ulteriori complessità di amministrazione del ciclo di vita delle credenziali e esperienza utente.
Usare le impostazioni di accesso tra tenant di identità esterne per gestire le modalità di collaborazione con altre organizzazioni di Microsoft Entra tramite la collaborazione B2B. Queste impostazioni determinano sia il livello di accesso in ingresso che gli utenti di organizzazioni esterne a Microsoft Entra hanno verso le risorse interne sia il livello di accesso in uscita che gli utenti interni hanno verso organizzazioni esterne. Consentono inoltre di considerare attendibile le attestazioni dell’autenticazione a più fattori (MFA) e dei dispositivi (attestazioni conformi e attestazioni aggiunte ibride di Microsoft Entra) da altre organizzazioni di Microsoft Entra. Per informazioni dettagliate e considerazioni sulla pianificazione, vedere Accesso tra tenant in Microsoft Entra per ID esterno.
Un altro approccio potrebbe essere stato quello di usare le funzionalità di Microsoft Entra Connect per sincronizzare le stesse credenziali di Microsoft Entra locali con più tenant, mantenendo la stessa password ma differenziando il dominio UPN degli utenti.
Isolamento delle risorse multi-tenant
Con un nuovo tenant è disponibile un set separato di amministratori. Le organizzazioni possono scegliere di usare le identità aziendali tramite Collaborazione B2B di Microsoft Entra. Analogamente, le organizzazioni possono implementare Azure Lighthouse per la gestione tra tenant delle risorse di Azure in modo che le sottoscrizioni di Azure non di produzione vengano gestite dalle identità nella controparte di produzione. Azure Lighthouse non può essere usato per gestire i servizi all'esterno di Azure, ad esempio Microsoft Intune. Per i provider di servizi gestiti (MSP), Microsoft 365 Lighthouse è un portale di amministrazione che contribuisce a proteggere e gestire dispositivi, dati e utenti su larga scala per i clienti di piccole e medie dimensioni (SMB) che usano Microsoft 365 Business Premium, Microsoft 365 E3 o Windows 365 Business.
Ciò consentirà agli utenti di continuare a usare le proprie credenziali aziendali, ottenendo al tempo stesso i vantaggi della separazione.
La collaborazione B2B di Microsoft Entra nei tenant sandbox deve essere configurata per consentire l'onboarding esclusivamente delle identità dell'ambiente aziendale tramite elenchi di autorizzazioni/rifiuto di Azure B2B. Per i tenant che si desidera consentire per B2B, è consigliabile usare le impostazioni di accesso tra identità esterne tra tenant per l'autenticazione a più fattori tenant\Attendibilità del dispositivo.
Importante
Le architetture multi-tenant con accesso alle identità esterne abilitate forniscono solo l'isolamento delle risorse, ma non abilitano l'isolamento delle identità. L'isolamento delle risorse con Collaborazione B2B di Microsoft Entra e Azure Lighthouse non riduce i rischi correlati alle identità.
Se l'ambiente sandbox condivide le identità con l'ambiente aziendale, gli scenari seguenti sono applicabili al tenant sandbox:
Un attore malintenzionato che compromette un utente, un dispositivo o un'infrastruttura ibrida nel tenant aziendale e viene invitato nel tenant sandbox potrebbe ottenere l'accesso alle app e alle risorse del tenant sandbox.
Un errore operativo (ad esempio, l'eliminazione o la revoca delle credenziali dell'account utente) nel tenant aziendale potrebbe influire sull'accesso di un utente invitato nel tenant sandbox.
È necessario eseguire l'analisi dei rischi e potenzialmente considerare l'isolamento delle identità tramite più tenant per le risorse critiche per l'azienda che richiedono un approccio altamente difensivo. Azure Privileged Identity Management può aiutare nel ridurre alcuni dei rischi imponendo una maggiore sicurezza per l'accesso a tenant e risorse business critical.
Oggetti directory
Il tenant usato per isolare le risorse può contenere gli stessi tipi di oggetti, risorse di Azure e applicazioni attendibili del tenant primario. Potrebbe essere necessario effettuare il provisioning dei tipi di oggetto seguenti:
Utenti e gruppi: identità necessarie per i team di progettazione della soluzione, ad esempio:
Amministratori dell'ambiente sandbox.
Proprietari tecnici delle applicazioni.
Developer di applicazioni line-of-business.
Testare gli account utente finale.
È possibile effettuare il provisioning di queste identità per:
Dipendenti che vengono con il proprio account aziendale tramite Collaborazione B2B di Microsoft Entra.
Dipendenti che necessitano di account locali per l'amministrazione, l'accesso amministrativo di emergenza o altri motivi tecnici.
I clienti che hanno o richiedono Active Directory non di produzione in locale possono anche sincronizzare le identità locali con il tenant sandbox, se necessario, dalle risorse e dalle applicazioni sottostanti.
Dispositivi: il tenant non di produzione contiene un numero ridotto di dispositivi nella misura in cui sono necessari nel ciclo di progettazione della soluzione:
Workstation di amministrazione
Computer non di produzione e dispositivi mobili necessari per lo sviluppo, il test e la documentazione
Applicazioni
Applicazioni integrate di Microsoft Entra: oggetti applicativi ed entità servizio per:
Testare le istanze delle applicazioni distribuite nell'ambiente di produzione, ad esempio le applicazioni che scrivono in Microsoft Entra ID e nei servizi online Microsoft.
Servizi di infrastruttura per gestire e gestire il tenant non di produzione, potenzialmente un subset delle soluzioni disponibili nel tenant aziendale.
Microsoft Online Services:
In genere, il team proprietario di Microsoft Online Services nell'ambiente di produzione deve essere quello proprietario dell'istanza non di produzione di tali servizi.
Gli amministratori di ambienti di test non di produzione non devono effettuare il provisioning di Microsoft Online Services a meno che tali servizi non vengano testati in modo specifico. In questo modo si evita l'uso inappropriato dei servizi Microsoft, ad esempio la configurazione di siti di SharePoint di produzione in un ambiente di test.
Analogamente, il provisioning dei servizi Microsoft Online che possono essere avviati dagli utenti finali (noti anche come sottoscrizioni ad hoc) deve essere bloccato. Per altre informazioni, vedere Che cos'è l'iscrizione self-service per Microsoft Entra ID?.
In genere, tutte le funzionalità di licenza non essenziali devono essere disabilitate per il tenant tramite licenze basate su gruppi. Questa operazione deve essere eseguita dallo stesso team che gestisce le licenze nel tenant di produzione, per evitare errori di configurazione da parte dei developer che potrebbero non conoscere l'effetto dell'abilitazione delle funzionalità con licenza.
Risorse di Azure
È anche possibile distribuire tutte le risorse di Azure necessarie tramite l'attendibilità delle applicazioni. Ad esempio, database, macchine virtuali, contenitori, funzioni di Azure e così via. Per l'ambiente sandbox, è necessario valutare il risparmio sui costi dell'uso di SKU meno costosi per prodotti e servizi con le funzionalità di sicurezza meno disponibili.
Il modello di controllo degli accessi in base al ruolo per il controllo di accesso deve essere ancora utilizzato in un ambiente non di produzione nel caso in cui le modifiche vengano replicate in produzione dopo la conclusione dei test. In caso contrario, i difetti di sicurezza nell'ambiente non di produzione possono propagarsi al tenant di produzione.
Isolamento delle risorse e delle identità con più tenant
Risultati dell'isolamento
Esistono situazioni limitate in cui l'isolamento delle risorse non può soddisfare i requisiti. È possibile isolare sia le risorse che le identità in un'architettura multi-tenant disabilitando tutte le funzionalità di collaborazione tra tenant e creando in modo efficace un limite di identità separato. Questo approccio è una difesa dagli errori operativi e dalla compromissione delle identità utente, dei dispositivi o dell'infrastruttura ibrida nei tenant aziendali.
Uso comune dell'isolamento
Un limite di identità separato viene in genere usato per applicazioni e risorse critiche per l'azienda, ad esempio i servizi rivolti ai clienti. In questo scenario Fabrikam ha deciso di creare un tenant separato per il prodotto SaaS rivolto ai clienti per evitare il rischio di compromissione delle identità dei dipendenti che interessano i clienti SaaS. Nella figura seguente viene illustrata questa architettura:
Il tenant FabrikamSaaS contiene gli ambienti usati per le applicazioni offerte ai clienti come parte del modello aziendale di Fabrikam.
Isolamento degli oggetti directory
Gli oggetti directory in FabrikamSaas sono i seguenti:
Utenti e gruppi: le identità necessarie per i team IT della soluzione, il personale del supporto clienti o altro personale necessario vengono create all'interno del tenant SaaS. Per mantenere l'isolamento, vengono usati solo gli account locali e Collaborazione B2B di Microsoft Entra non è abilitato.
Oggetti directory di Azure Active Directory B2C: se gli ambienti tenant sono accessibili dai clienti, può contenere un tenant di Azure Active Directory B2C e gli oggetti identità associati. Le sottoscrizioni che contengono queste directory sono buoni candidati per un ambiente isolato rivolto ai consumatori.
Dispositivi: questo tenant contiene un numero ridotto di dispositivi; solo quelli necessari per eseguire soluzioni rivolte ai clienti:
Proteggere le workstation di amministrazione.
Workstation del personale di supporto (che possono includere tecnici "su chiamata", come descritto in precedenza).
Isolamento delle applicazioni
Applicazioni integrate di Microsoft Entra: oggetti applicativi ed entità servizio per:
Applicazioni di produzione (ad esempio, definizioni di applicazioni multi-tenant).
Servizi di infrastruttura per gestire e gestire l'ambiente rivolto ai clienti.
Risorse di Azure: ospita le risorse IaaS, PaaS e SaaS delle istanze di produzione rivolte ai clienti.
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per