Elementi consigliati per la gestione dell'identità e degli accessi

Si applica a questa raccomandazione dell'elenco di controllo di sicurezza Power Platform Well-Architected:

Questa guida descrive le raccomandazioni per l'autenticazione e l'autorizzazione delle identità che tentano di accedere alle risorse del carico di lavoro.

Dal punto di vista del controllo tecnico, l'identità è sempre il perimetro primario. Questo ambito non si limita solo ai margini del carico di lavoro. Include anche singoli componenti che si trovano all'interno del carico di lavoro.

Le identità tipiche includono:

• Esseri umani. Utenti dell'applicazione, amministratori, operatori, revisori e attori malintenzionati.
• Sistemi. Identità del carico di lavoro, identità gestite, chiavi API, entità servizio e risorse Azure.
• Anonimo. Entità che non hanno fornito alcuna prova di chi sono.

Definizioni

Microsoft Entra ID come provider di identità per Power Platform

Tutti i prodotti Power Platform usano Microsoft Entra ID (in precedenza Azure Active Directory o Azure AD) per la gestione delle identità e degli accessi. Entra ID consente alle organizzazioni di proteggere e gestire l'identità per i propri ambienti ibridi e multicloud. L'ID Entra è essenziale anche per la gestione degli ospiti aziendali che richiedono l'accesso a risorse Power Platform. Power Platform utilizza anche Entra ID per gestire altre applicazioni con cui è necessario eseguire l'integrazione di API Power Platform che utilizzano le funzionalità dell'entità servizio. Utilizzando Entra ID, Power Platform può sfruttare le funzionalità di sicurezza più avanzate di Entra ID come l'accesso condizionale e la valutazione dell'accesso continuo.

Authentication

L'autenticazione è un processo che verifica le identità. L'identità richiedente è necessaria per fornire una forma di identificazione verificabile. Per esempio:

• Nome utente e password.
• Segreto precondiviso, ad esempio una chiave API che concede l'accesso.
• Un token di firma di accesso condiviso (SAS).
• Un certificato utilizzato nell'autenticazione reciproca Transport Layer Security (TLS).

L'autenticazione power platform implica una sequenza di richieste, risposte e reindirizzamenti tra il browser dell'utente e Power Platform o i servizi Azure. La sequenza segue il flusso di concessione del codice di autenticazione Microsoft Entra ID.

La connessione e l'autenticazione a un'origine dati esterna è un passaggio separato dall'autenticazione a un servizio Power Platform. Per altre informazioni, vedi Connessione e autenticazione alle origini dati.

Autorizzazione

Power Platform usa Microsoft Entra ID Microsoft Identity Platform per l'autorizzazione di tutte le chiamate API con il protocollo OAuth 2.0 standard del settore.

Strategie di progettazione chiave

Per comprendere le esigenze di identità per un carico di lavoro, è necessario elencare i flussi di utenti e sistemi, le risorse del carico di lavoro, i personaggi e le azioni che verranno intraprese.

Ogni caso d'uso avrà probabilmente un set di controlli che deve essere progettato nella consapevolezza di una possibile violazione. In base ai requisiti di identità del caso d'uso o degli utenti, identificare le scelte condizionali. Evitare di usare una soluzione per tutti i casi d'uso. Viceversa, i controlli non devono essere così granulari da introdurre un sovraccarico di gestione non necessario.

È necessario registrare la traccia di accesso dell'identità. In questo modo è possibile convalidare i controlli ed è possibile usare i log per i controlli di conformità.

Determinare tutte le identità per l'autenticazione

Accesso dall'esterno all'interno. L'autenticazione power platform implica una sequenza di richieste, risposte e reindirizzamenti tra il browser dell'utente e Power Platform o i servizi Azure. La sequenza segue il flusso di concessione del codice di autenticazione Microsoft Entra ID. Power Platform autentica automaticamente tutti gli utenti che accedono al carico di lavoro per vari scopi.

Accesso dall'interno all'esterno. Il tuo carico di lavoro dovrà accedere ad altre risorse. Ad esempio, la lettura o la scrittura nella piattaforma dati, il recupero di segreti dall'archivio segreto e la registrazione dei dati di telemetria ai servizi di monitoraggio. Potrebbe anche essere necessario accedere a servizi di terze parti. Questi sono tutti requisiti di identità del carico di lavoro. Tuttavia, è necessario considerare anche i requisiti di identità delle risorse; ad esempio, il modo in cui verranno eseguite e autenticate le pipeline di distribuzione.

Determinare le azioni per l'autorizzazione

Successivamente, è necessario conoscere l'operazione che ogni identità autenticata sta tentando di eseguire in modo che tali azioni possano essere autorizzate. Le azioni possono essere divise in base al tipo di accesso richiesto:

• Accesso al piano dei dati. Le azioni che si svolgono nel piano dati causano il trasferimento dei dati. Ad esempio, un'applicazione legge o scrive dati da Microsoft Dataverse o scrive i log in Application Insights.

• Accesso al piano di controllo. Le azioni che hanno luogo nel piano di controllo causano la creazione, la modifica o l'eliminazione di una risorsa Power Platform. Ad esempio, la modifica delle proprietà dell'ambiente o la creazione di criteri sui dati.

Le applicazioni sono in genere destinate alle operazioni del piano dati, mentre le operazioni spesso accedono sia ai piani di controllo che ai piani dati.

Fornire l'autorizzazione basata sui ruoli

In base alla responsabilità di ogni identità, autorizzare azioni che devono essere consentite. Un'identità non deve essere autorizzata a fare di più di quanto debba fare. Prima di impostare le regole di autorizzazione, è necessario avere una chiara comprensione di chi o cosa sta effettuando le richieste, del ruolo consentito e in quale misura può farlo. Questi fattori portano a scelte che combinano identità, ruolo e ambito.

Tenere presente quanto segue:

• Il carico di lavoro deve avere accesso al piano dati Dataverse sia per l'accesso in lettura che per quello in scrittura?
• Il carico di lavoro deve accedere anche alle proprietà dell'ambiente?
• Se l'identità viene compromessa da un malintenzionato, quale sarebbe l'impatto sul sistema in termini di riservatezza, integrità e disponibilità?
• Il carico di lavoro necessita di un accesso permanente o è possibile prendere in considerazione l'accesso condizionato?
• Il carico di lavoro esegue azioni che richiedono autorizzazioni amministrative/elevate?
• In che modo il carico di lavoro interagirà con i servizi di terze parti?
• Per gli agenti esistono requisiti per Single Sign-On (SSO)?
• L'agente funziona in modalità non autenticata, in modalità autenticata o in entrambe?

Assegnazione di ruolo

Un ruolo è un set di autorizzazioni assegnate a un'identità. Assegna ruoli che consentono solo all'identità di completare l'attività e non altro. Quando le autorizzazioni dell'utente sono limitate ai requisiti di lavoro, è più facile identificare comportamenti sospetti o non autorizzati nel sistema.

Porre domande simili alle seguenti:

• L'accesso in sola lettura è sufficiente?
• L'identità necessita delle autorizzazioni per eliminare le risorse?
• Il ruolo deve accedere solo ai record che ha creato?
• È richiesto l'accesso gerarchico in base all'unità aziendale in cui si trova l'utente?
• Il ruolo necessita di autorizzazioni amministrative o elevate?
• Il ruolo necessita dell'accesso permanente a queste autorizzazioni?
• Cosa succede se l'utente cambia lavoro?

Limitare il livello di accesso di utenti, applicazioni o servizi riduce la potenziale superficie di attacco. Se si concedono solo le autorizzazioni minime necessarie per eseguire attività specifiche, il rischio di un attacco riuscito o di un accesso non autorizzato è notevolmente ridotto. Ad esempio, gli sviluppatori necessitano solo dell'accesso del produttore all'ambiente per sviluppatori ma non all'ambiente di produzione; hanno solo bisogno dell'accesso per creare risorse ma non per modificare le proprietà dell'ambiente; e potrebbero aver bisogno solo dell'accesso per leggere/scrivere i dati da Dataverse ma non modificare il modello di dati o gli attributi della tabella Dataverse.

Evita autorizzazioni destinate a singoli utenti. Le autorizzazioni granulari e personalizzate creano complessità e confusione e possono diventare difficili da mantenere quando gli utenti cambiano ruolo e si spostano all'interno dell'azienda o quando nuovi utenti con requisiti di autenticazione simili si uniscono al team. Questa situazione può creare una configurazione legacy complessa, difficile da mantenere e avere un impatto negativo sia sulla sicurezza che sull'affidabilità.

Compromesso: un approccio granulare per il controllo degli accessi consente un controllo e un monitoraggio migliori delle attività degli utenti.

Concedere ruoli che iniziano con privilegi minimi e aggiungere quelli in base alle esigenze operative o di accesso ai dati. I team tecnici devono avere indicazioni chiare per implementare le autorizzazioni.

Scegliere l'accesso condizionale

Non assegnare a tutte le identità lo stesso livello di accesso. Basare le decisioni su due fattori principali:

• Ora. Per quanto tempo l'identità può accedere all'ambiente.
• Privilegio. Livello di autorizzazioni.

Questi fattori non si escludono a vicenda. Un'identità compromessa con più privilegi e durata illimitata di accesso può ottenere un maggiore controllo sul sistema e sui dati o usare tale accesso per continuare a modificare l'ambiente. Vincola questi fattori di accesso sia come misura preventiva che per controllare il raggio dell'esplosione.

Gli approcci JIT (Just-In-Time) forniscono i privilegi necessari solo quando sono necessari.

Just Enough Access (JEA) fornisce solo i privilegi necessari.

Anche se il tempo e i privilegi sono i fattori principali, esistono altre condizioni che si applicano. Ad esempio, è anche possibile usare il dispositivo, la rete e la posizione da cui ha avuto origine l'accesso per impostare i criteri.

Usare controlli sicuri che filtrano, rilevano e bloccano l'accesso non autorizzato, inclusi parametri come identità utente e posizione, integrità dei dispositivi, contesto del carico di lavoro, classificazione dei dati e anomalie.

Ad esempio, potrebbe essere necessario accedere al carico di lavoro da identità di terze parti come fornitori, partner e clienti. Hanno bisogno del livello di accesso appropriato anziché delle autorizzazioni predefinite fornite ai dipendenti a tempo pieno. Una chiara differenziazione degli account esterni rende più semplice prevenire e rilevare gli attacchi provenienti da questi vettori.

Conti a impatto critico

Le identità amministrative introducono alcuni dei rischi di sicurezza con maggiore impatto perché le attività eseguite richiedono l'accesso con privilegi a un ampio set di questi sistemi e applicazioni. La compromissione o l'uso improprio possono avere un effetto dannoso sull'azienda e sui relativi sistemi informativi. La sicurezza dell'amministrazione è una delle aree di sicurezza più critiche.

Per proteggere l'accesso con privilegi da antagonisti specifici è necessario adottare un approccio completo e ponderato per isolare questi sistemi da eventuali rischi. Ecco alcune strategie:

• Ridurre al minimo il numero di account di impatto critici.

• Usare ruoli separati anziché elevare i privilegi per le identità esistenti.

• Evitare l'accesso permanente o esistente utilizzando le funzionalità JIT del tuo IdP. In caso di rottura del vetro, segui una procedura di accesso di emergenza.

• Usare protocolli di accesso moderni come l'autenticazione senza password o l'autenticazione a più fattori. Esternalizza questi meccanismi al tuo IdP.

• Applicare gli attributi di sicurezza chiave usando i criteri di accesso condizionale.

• Disattivare gli account amministrativi che non vengono utilizzati.

Stabilire i processi per gestire il ciclo di vita delle identità

L'accesso alle identità non deve durare più a lungo delle risorse a cui accedono le identità. Assicurarsi di disporre di un processo per disabilitare o eliminare le identità quando sono presenti modifiche alla struttura del team o ai componenti software.

Queste linee guida si applicano al controllo del codice sorgente, ai dati, ai piani di controllo, agli utenti del carico di lavoro, all'infrastruttura, agli strumenti, al monitoraggio di dati, log, metriche e altre entità.

Stabilire un processo di governance delle identità per gestire il ciclo di vita delle identità digitali, degli utenti con privilegi elevati, degli utenti esterni/guest e degli utenti del carico di lavoro. Implementare le verifiche di accesso per assicurarsi che quando le identità lasciano l'organizzazione o il team, le autorizzazioni dei carichi di lavoro vengono rimosse.

Proteggere i segreti svincolati dall'identità

I segreti dell'applicazione come le chiavi precondivise devono essere considerati punti vulnerabili nel sistema. Nella comunicazione bidirezionale, se il provider o il consumer viene compromesso, è possibile introdurre rischi significativi per la sicurezza. Queste chiavi possono anche essere onerose perché introducono processi operativi.

Tratta questi segreti come entità che possono essere estratte dinamicamente da un archivio segreto. Non devono essere hardcoded nelle app, nei flussi, nelle pipeline di distribuzione o in qualsiasi altro artefatto.

Assicurarsi di avere la possibilità di revocare i segreti.

Applicare procedure operative che gestiscono attività come la rotazione delle chiavi e la scadenza.

Per informazioni sui criteri di rotazione, vedere Automatizzare la rotazione di un segreto per le risorse con due set di credenziali di autenticazione e Esercitazione: Aggiornamento della frequenza di rotazione automatica dei certificati in Key Vault.

Mantenere sicuri gli ambienti di sviluppo

L'accesso in scrittura agli ambienti per sviluppatori dovrebbe essere limitato e l'accesso in lettura al codice sorgente dovrebbe essere limitato ai ruoli in base alla necessità di conoscerli. Dovresti disporre di un processo che esegua regolarmente la scansione delle risorse e identifichi le vulnerabilità più recenti.

Mantenere un audit trail

Un aspetto della gestione delle identità è garantire che il sistema sia controllabile. I controlli convalidano se le strategie di presupporre le violazioni sono efficaci. La gestione di un audit trail consente di:

• Verificare che l'identità sia autenticata con l'autenticazione avanzata. Qualsiasi azione deve essere tracciabile per evitare attacchi di ripudio.

• Rilevare protocolli di autenticazione deboli o mancanti e ottenere visibilità e informazioni dettagliate sugli accessi dell'utente e dell'applicazione.

• Valuta l'accesso degli utenti al carico di lavoro sulla base dei requisiti di sicurezza e conformità, considerando il rischio dell'account utente, lo stato del dispositivo e altri criteri e politiche che hai stabilito.

• Tenere traccia del progresso o della deviazione dai requisiti di conformità.

La maggior parte delle risorse ha accesso al piano dati. È necessario conoscere le identità che accedono alle risorse e alle azioni eseguite. È possibile usare tali informazioni per la diagnostica della sicurezza.

Facilitazione di Power Platform

Il controllo degli accessi Power Platform è una parte critica della sua architettura di sicurezza complessiva. I punti di controllo degli accessi possono garantire che gli utenti giusti ottengano l'accesso alle risorse Power Platform. In questa sezione esploreremo i diversi punti di accesso che puoi configurare e il loro ruolo nella tua strategia di sicurezza complessiva.

Microsoft Entra ID

Tutti i prodotti Power Platform usano Microsoft Entra ID (in precedenza Azure Active Directory o Azure AD) per la gestione delle identità e degli accessi. Entra ID consente alle organizzazioni di proteggere e gestire l'identità per i propri ambienti ibridi e multicloud. L'ID Entra è essenziale anche per la gestione degli ospiti aziendali che richiedono l'accesso a risorse Power Platform. Power Platform utilizza anche Entra ID per gestire altre applicazioni con cui è necessario eseguire l'integrazione di API Power Platform che utilizzano le funzionalità dell'entità servizio. Utilizzando Entra ID, Power Platform può sfruttare le funzionalità di sicurezza più avanzate di Entra ID come l'accesso condizionale e la valutazione dell'accesso continuo.

Assegnazione delle licenze

L'accesso a Power Apps e Power Automate inizia con avere una licenza. Il tipo di asset e di dati a cui può accedere un utente è determinato dal tipo di licenza che ha. Nella tabella seguente vengono descritte, a livello elevato, le differenze nelle risorse disponibili per un utente in base al tipo di piano. I dettagli granulari sulle licenze sono in Panoramica sulle licenze.

Criteri di accesso condizionale

L'accesso condizionale descrive i criteri per una decisione di accesso. Per usare l'accesso condizionale, è necessario comprendere le restrizioni necessarie per il caso d'uso. Configurare Microsoft Entra l'accesso condizionale configurando un criterio di accesso basato sulle esigenze operative.

Ulteriori informazioni:

• Impostare l'accesso condizionale Microsoft Entra
• Accesso condizionale e autenticazione a più fattori in Power Automate

Accesso continuo

L'accesso continuo accelera quando vengono valutati determinati eventi per determinare se l'accesso deve essere revocato. Tradizionalmente, con l'autenticazione OAuth 2.0, la scadenza del token di accesso si verifica quando viene eseguito un controllo durante il rinnovo del token. Con l'accesso continuo, gli eventi critici di un utente e le modifiche alla posizione di rete vengono valutati continuamente per determinare se l'utente deve comunque mantenere l'accesso. Queste valutazioni possono comportare la conclusione anticipata delle sessioni attive o richiedere la riautenticazione. Ad esempio, se un account utente viene disabilitato, dovrebbe perdere l'accesso all'app. Anche la posizione è importante; ad esempio, il token potrebbe essere stato autorizzato da una posizione attendibile, ma l'utente ha modificato la propria connessione con una rete non attendibile. L'accesso continuo richiamerebbe la valutazione dei criteri di accesso condizionale e l'utente perderebbe l'accesso perché non si connette più da una posizione approvata.

Attualmente, con Power Platform, solo Dataverse supporta la valutazione continua dell'accesso. Microsoft sta lavorando per aggiungere supporto ad altri servizi e client Power Platform. Per ulteriori informazioni, vedi Valutazione continua dell'accesso.

Con la continua adozione di modelli di lavoro ibridi e l'uso di applicazioni cloud, Entra ID è diventato un perimetro di sicurezza primario cruciale per la salvaguardia di utenti e risorse. L'accesso condizionale estende tale perimetro oltre il perimetro di rete per includere l'identità dell'utente e del dispositivo. L'accesso continuo garantisce che, quando gli eventi o le posizioni degli utenti cambiano, l'accesso venga rivalutato. L'utilizzo di Power Platform di Entra ID ti consente di implementare una governance della sicurezza a livello di organizzazione che puoi applicare in modo coerente a tutto il tuo portafoglio di applicazioni. Consulta queste procedure consigliate per la gestione delle identità per ulteriori indicazioni sulla creazione del tuo piano per l'utilizzo di Entra ID con Power Platform.

Gestione dell'accesso ai gruppi

Anziché concedere autorizzazioni a utenti specifici, assegnare l'accesso ai gruppi in MICROSOFT Entra ID. Se non esiste un gruppo, si dovrebbe collaborare con il team responsabile dell'identità per crearne uno. È quindi possibile aggiungere e rimuovere membri del gruppo all'esterno di Azure e assicurarsi che le autorizzazioni siano aggiornate. Puoi anche utilizzare il gruppo per altri scopi come le mailing list.

Per altre informazioni, vedere Proteggere il controllo di accesso usando i gruppi in Microsoft Entra ID.

Rilevamento delle minacce

Microsoft Entra ID Protection consente di rilevare, analizzare e correggere i rischi basati sull'identità. Per altre informazioni, vedere Che cos'è Identity Protection?.

Il rilevamento delle minacce può assumere la forma di reazione a un avviso di attività sospette o alla ricerca proattiva di eventi anomali nei log attività. Analisi del comportamento dell'utente e dell'entità (UEBA) in Microsoft Sentinel semplifica il rilevamento di attività sospette. Per ulteriori informazioni, vedere Identifica le minacce avanzate con UEBA in Microsoft Sentinel.

Registrazione dell'identità

Power Apps, Power Automate, Copilot Studio, connettori e registrazione delle attività di prevenzione della perdita dei dati vengono rilevati e visualizzati dal portale di conformità Microsoft Purview. Informazioni su Microsoft Purview.

Le modifiche ai registri apportate ai record del cliente in un ambiente con un database Dataverse. Il controllo Dataverse registra anche l'accesso degli utenti tramite un'app o tramite l'SDK in un ambiente. Questo controllo è abilitato a livello di ambiente ed è necessaria una configurazione aggiuntiva per singole tabelle e colonne.

Ruoli di amministratore di servizio

Entra ID contiene una serie di ruoli prestabiliti che possono essere assegnati agli amministratori per concedere loro l'autorizzazione a eseguire attività amministrative. Puoi rivedere la matrice delle autorizzazioni per una ripartizione granulare dei privilegi di ciascun ruolo.

Usare Microsoft Entra Privileged Identity Management (PIM) per gestire i ruoli di amministratore con privilegi elevati nell'interfaccia di amministrazione di Power Platform.

Protezione dei dati Dataverse

Una delle funzionalità principali di Dataverse è il modello di sicurezza avanzato che può essere adattato a molti scenari di utilizzo aziendale. Questo modello di sicurezza è disponibile solo quando un database Dataverse è presente nell'ambiente. In qualità di professionista della sicurezza, probabilmente non creerai tu stesso l'intero modello di sicurezza, ma potresti essere coinvolto nel garantire che l'uso delle funzionalità di sicurezza sia coerente con i requisiti di sicurezza dei dati dell'organizzazione. Dataverse utilizza la sicurezza basata sui ruoli per raggruppare una raccolta di privilegi. Questi ruoli di sicurezza possono essere direttamente associati agli utenti o possono essere associati a Business Unit e team di Dataverse. Per altre informazioni, vedere concetti relativi a Security in Microsoft Dataverse.

Configurare l'autenticazione utente in Copilot Studio

Microsoft Copilot Studio supporta diverse opzioni di autenticazione. Scegli quella più idonea alle tue esigenze. L'autenticazione consente agli utenti di accedere, garantendo all'agente l'accesso a risorse o informazioni limitate. Gli utenti possono accedere usando Microsoft Entra ID o qualsiasi provider di identità OAuth 2.0, ad esempio Google o Facebook. Per altre informazioni, vedere Configurare l'autenticazione utente in Copilot Studio.

Con la sicurezza basata su Direct Line, è possibile limitare l'accesso alle posizioni controllate abilitando l'accesso protetto con segreti o token Direct Line.

Copilot Studio supporta l'accesso tramite Single Sign-On (SSO), il che significa che gli agenti possono accedere per conto dell'utente. L'SSO deve essere implementato nelle pagine Web e nelle applicazioni per dispositivi mobili. Per Microsoft Teams, l'accesso Single Sign-On è facile se si seleziona l'opzione di autenticazione "Solo in Teams". Può anche essere configurato manualmente con Azure AD v2. In questo caso, tuttavia, l'app Teams deve essere distribuita come file ZIP, non tramite la distribuzione di Teams con 1 clic da Copilot Studio.

Ulteriori informazioni:

• Configurare l'accesso Single Sign-On con Microsoft Entra ID
• Configurare l'accesso Single Sign-On con Microsoft Entra ID per gli agenti in Microsoft Teams
• Configurare il Single Sign-On con un provider OAuth generico

Accedere in modo sicuro ai dati utilizzando Customer Lockbox

La maggior parte delle operazioni, del supporto e della risoluzione dei problemi eseguiti dal personale Microsoft (inclusi i responsabili secondari) non richiedono l'accesso ai dati dei clienti. Con Power Platform Customer Lockbox forniamo un'interfaccia affinché i clienti rivedano e approvino (o rifiutino) le richieste di accesso ai dati nelle rare occasioni in cui è necessario l'accesso ai dati dei clienti. Ad esempio, viene utilizzato nei casi in cui un tecnico Microsoft deve accedere ai dati dei clienti, in risposta a un ticket di supporto avviato dal cliente o a un problema identificato da Microsoft. Per altre informazioni, vedere Ascurire l'accesso ai dati dei clienti usando Customer Lockbox in Power Platform e Dynamics 365.

Gestire gli utenti guest

Potrebbe essere necessario consentire agli utenti guest di accedere ad ambienti e risorse Power Platform. Analogamente agli utenti interni, puoi usare l'accesso condizionale e la valutazione dell'accesso continuo di Microsoft Entra ID per garantire che gli utenti ospiti soddisfino un livello di sicurezza elevato.

Per migliorare ulteriormente la sicurezza e ridurre il rischio di condivisione eccessiva, bloccare o abilitare l'accesso da parte degli ospiti di Microsoft Entra agli ambienti supportati da Dataverse secondo necessità.

Informazioni pertinenti

• Configurare la gestione delle identità e degli accessi
• Connessione e autenticazione alle origini dati
• Autenticazione ai servizi Power Platform
• Concetti relativi alla sicurezza in Microsoft Dataverse
• Domande frequenti sulla sicurezza di Power Platform
• Matrice di autorizzazione dell'amministratore del servizio
• Valutazione continua dell'accesso
• Impostare l'accesso condizionale Microsoft Entra
• Raccomandazioni per l'accesso condizionale e l'autenticazione a più fattori in Microsoft Power Automate
• Piattaforma di identità Microsoft e flusso del codice di autorizzazione OAuth 2.0
• Novità di Microsoft Entra ID
• Ruoli predefiniti Microsoft Entra
• Panoramica del controllo degli accessi in base al ruolo in Microsoft Entra ID

Elenco di controllo relativo alla sicurezza

Fare riferimento al set completo di raccomandazioni.