Elementi consigliati per la gestione dell'identità e degli accessi
Si applica a questa raccomandazione della checklist di sicurezza ben progettata: Power Platform
SE:05 | Implementa una gestione delle identità e degli accessi (IAM) rigorosa, condizionale e verificabile per tutti gli utenti del carico di lavoro, i membri del team e i componenti di sistema. Limita l'accesso esclusivamente a se necessario. Utilizza i moderni standard di settore per tutte le implementazioni di autenticazione e autorizzazione. Limita e controlla rigorosamente l'accesso non basato sull'identità. |
---|
Questa guida descrive gli elementi consigliati per l'autenticazione e l'autorizzazione delle identità che potrebbero tentare di accedere alle risorse del carico di lavoro.
Dal punto di vista del controllo tecnico, l'identità è sempre il perimetro primario. Questo ambito non include solo i limiti 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 soggetti malintenzionati.
- Sistemi. Identità del carico di lavoro, identità gestite, chiavi API, entità servizio e risorse di Azure.
- Anonimo. Entità che non hanno fornito alcuna prova su chi siano.
Definizioni
Terms | Definizione |
---|---|
Autenticazione (AuthN) | Un processo che verifica che un'identità sia chi o cosa dice di essere. |
Autorizzazione (AuthZ) | Un processo che verifica se un'identità dispone dell'autorizzazione per eseguire un'azione richiesta. |
Accesso condizionale | Un insieme di regole che consente azioni in base a criteri specifici. |
IdP | Un provider di identità, come Microsoft Entra ID. |
Utente tipo | Una funzione lavorativa o un titolo che prevede una serie di responsabilità e azioni. |
Chiavi precondivise | Un tipo di segreto condiviso tra un fornitore e un consumatore e utilizzato attraverso un meccanismo sicuro e concordato. |
Identità risorsa | Un'identità definita per le risorse cloud gestite dalla piattaforma. |
Ruolo | Un insieme di autorizzazioni che definiscono cosa può fare un utente o un gruppo. |
Scope | Diversi livelli di gerarchia organizzativa in cui un ruolo può operare. Anche un gruppo di funzionalità in un sistema. |
Entità di sicurezza | Un'identità che fornisce autorizzazioni. Può essere un utente, un gruppo o un'entità servizio. Tutti i membri del gruppo ottengono lo stesso livello di accesso. |
Identità utente | Un'identità per una persona, come un dipendente o un utente esterno. |
Identità del carico di lavoro | Un'identità di sistema per un'applicazione, un servizio, uno script, un contenitore o un altro componente di un carico di lavoro utilizzato per autenticarsi su altri servizi e risorse. |
Nota
Un'identità può essere raggruppata con altre identità simili sotto un padre chiamato entità di sicurezza. Un gruppo di sicurezza è un esempio di entità di sicurezza. Questa relazione gerarchica semplifica la manutenzione e migliora la coerenza. Poiché gli attributi di identità non vengono gestiti a livello individuale, vengono ridotte anche le possibilità di errori. In questo articolo, il termine identità è comprensivo delle entità di sicurezza.
Microsoft Entra ID come provider di identità per Power Platform
Tutti i prodotti Power Platform utilizzano Microsoft Entra ID (precedentemente 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 l'ID Entra, Power Platform può sfruttare le funzionalità di sicurezza più avanzate di Entra ID come l'accesso condizionale e la valutazione dell'accesso continuo.
Autenticazione
L'autenticazione è un processo che verifica le identità. L'identità richiedente è tenuta a fornire una qualche forma di identificazione verificabile. Ad esempio:
- Un nome utente e una password.
- Un segreto precondiviso, come una chiave API che garantisce l'accesso.
- Un token di firma di accesso condiviso (SAS).
- Un certificato utilizzato nell'autenticazione reciproca Transport Layer Security (TLS).
L'autenticazione Power Platform comporta una sequenza di richieste, risposte e reindirizzamenti tra il browser dell'utente e Power Platform o Servizi di Azure. La sequenza segue il flusso di concessione del codice di autorizzazione di 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 utilizza Microsoft Entra ID Microsoft Identity Platform per l'autorizzazione di tutte le chiamate API con il protocollo standard del settore OAuth 2.0.
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 il proprio set di controlli che è necessario progettare con una mentalità basata sulla presunzione di violazione. In base ai requisiti di identità del caso d'uso o degli utenti tipo, identifica le scelte condizionali. Evita di utilizzare un'unica soluzione per tutti i casi d'uso. Al contrario, i controlli non dovrebbero essere così granulari da introdurre inutili spese di gestione.
È necessario registrare la traccia di accesso dell'identità. Ciò aiuta a convalidare i controlli e puoi utilizzare i log per i controlli di conformità.
Determinare tutte le identità per l'autenticazione
Accesso dall'esterno all'interno. L'autenticazione Power Platform comporta una sequenza di richieste, risposte e reindirizzamenti tra il browser dell'utente e Power Platform o Servizi di Azure. La sequenza segue il flusso di concessione del codice di autorizzazione di Microsoft Entra ID. Power Platform autentica automaticamente tutti gli utenti che accedono al carico di lavoro per vari scopi.
Accesso dall'interno verso l'esterno. Il tuo carico di lavoro dovrà accedere ad altre risorse. Ad esempio, leggi o scrivi sulla piattaforma dati, recupera segreti dall'archivio segreto e registra la telemetria nei 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 sapere cosa sta tentando di fare ciascuna identità autenticata in modo che tali azioni possano essere autorizzate. Le azioni possono essere suddivise in base al tipo di accesso che richiedono:
Accesso al piano dati. Le azioni che si svolgono nel piano dati causano il trasferimento dei dati. Ad esempio, un'applicazione che legge o scrive dati da Microsoft Dataverse o scrive log su 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 in genere mirano alle operazioni del piano dati, mentre le operazioni spesso accedono sia al piano di controllo che a quello dei dati.
Fornire l'autorizzazione basata sui ruoli
In base alla responsabilità di ciascuna identità, autorizzare le azioni che dovrebbero essere consentite. Non si deve consentire a un'identità di fare più di quanto sia necessario. Prima di impostare le regole di autorizzazione, è necessario avere una chiara comprensione di chi o cosa sta effettuando le richieste, cosa è consentito fare a quel ruolo e in che misura può farlo. Questi fattori portano a scelte che combinano identità, ruolo e portata.
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 i copiloti, sono previsti requisiti di Single Sign-On (SSO)?
- Il copilota sta operando in modalità non autenticata, 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 lavorativi, è più semplice identificare comportamenti sospetti o non autorizzati nel sistema.
Porre questioni come queste:
- L'accesso in sola lettura è sufficiente?
- L'identità necessita di 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 viene notevolmente ridotto. Ad esempio, gli sviluppatori necessitano solo dell'accesso del produttore all'ambiente di sviluppo 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 di controllo degli accessi granulare consente un migliore controllo e monitoraggio delle attività degli utenti.
Concedi ruoli che iniziano con il privilegio minimo e aggiungine altri in base alle tue esigenze operative o di accesso ai dati. I tuoi team tecnici devono avere indicazioni chiare per implementare le autorizzazioni.
Fai scelte di accesso condizionale
Non assegnare a tutte le identità lo stesso livello di accesso. Basa le tue decisioni su due fattori principali:
- Ora. Per quanto tempo l'identità può accedere al tuo ambiente.
- Privilegio. Il livello di autorizzazioni.
Questi fattori non si escludono a vicenda. Un'identità compromessa che dispone di più privilegi e di una durata di accesso illimitata può ottenere un maggiore controllo sul sistema e sui dati o utilizzare tale accesso per continuare a modificare l'ambiente. Limitare tali fattori di accesso sia come misura preventiva sia per controllare il raggio del mailing.
Gli approcci Just in Time (JIT) forniscono i privilegi richiesti solo quando sono necessari.
Just Enough Access (JEA) fornisce solo i privilegi richiesti.
Sebbene tempo e privilegi siano i fattori principali, ci sono altre condizioni che si applicano. Ad esempio, puoi anche utilizzare il dispositivo, la rete e la posizione da cui ha avuto origine l'accesso per impostare i criteri.
Utilizzare controlli rigorosi che filtrino, rilevino e blocchino gli accessi non autorizzati, inclusi parametri quali identità e posizione dell'utente, integrità del dispositivo, contesto del carico di lavoro, classificazione dei dati e anomalie.
Ad esempio, potrebbe essere necessario che identità di terze parti accedano al tuo carico di lavoro, 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 facilita la prevenzione e il rilevamento degli attacchi provenienti da questi vettori.
Conti a impatto critico
Le identità amministrative introducono alcuni dei rischi per la sicurezza con il maggiore impatto perché le attività che svolgono richiedono un accesso privilegiato a un'ampia gamma di questi sistemi e applicazioni. Il compromesso o l'uso improprio possono avere un effetto dannoso sulla vostra azienda e sui suoi sistemi informativi. La sicurezza dell'amministrazione è uno degli ambiti di sicurezza più critici.
La protezione dell'accesso privilegiato da determinati avversari richiede l'adozione di un approccio completo e ponderato per isolare questi sistemi dai rischi. Di seguito sono riportati alcune strategie:
Ridurre al minimo il numero di account con impatto critico.
Utilizzare ruoli separati invece di elevare i privilegi per le identità esistenti.
Evita l'accesso permanente o permanente utilizzando le funzionalità JIT del tuo IdP. In caso di rottura del vetro, segui una procedura di accesso di emergenza.
Utilizzare protocolli di accesso moderni come l'autenticazione senza password o l'autenticazione a più fattori. Esternalizza questi meccanismi al tuo IdP.
Applica gli attributi di sicurezza chiave utilizzando criteri di accesso condizionato.
Disattivare gli account amministrativi che non vengono utilizzati.
Stabilire processi per gestire il ciclo di vita dell'identità
L'accesso alle identità non deve durare più a lungo delle risorse a cui accedono le identità. Assicurati di disporre di un processo per disabilitare o eliminare le identità quando si verificano modifiche nella struttura del team o nei 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 dell'identità per gestire il ciclo di vita delle identità digitali, degli utenti con privilegi elevati, degli utenti esterni/ospiti e degli utenti del carico di lavoro. Implementare le revisioni degli accessi per garantire che quando le identità lasciano l'organizzazione o il team, le relative autorizzazioni per il carico di lavoro vengano rimosse.
Proteggi i segreti non basati sull'identità
I segreti dell'applicazione come le chiavi precondivise dovrebbero essere considerati punti vulnerabili nel sistema. Nella comunicazione bidirezionale, se il fornitore o il consumatore vengono compromessi, possono essere introdotti notevoli rischi per la sicurezza. Tali chiavi possono anche essere gravose 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.
Assicurati di avere la capacità di revocare i segreti.
Applica procedure operative che gestiscono attività come rotazione e scadenza della chiave.
Per informazioni sui criteri di rotazione, vedi Automatizzare la rotazione di un segreto per le risorse che hanno due set di credenziali di autenticazione ed Esercitazione: aggiornamento automatico del certificato di frequenza di rotazione in Key Vault.
Mantieni lo sviluppo di ambienti sicuro
L'accesso in scrittura agli ambienti per gli 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 verificabile. I controlli verificano se le strategie di presunzione di violazione sono efficaci. Mantenere un audit trail consente di:
Verificare che l'identità sia autenticata con l'autenticazione avanzata. Ogni azione deve essere tracciabile per prevenire attacchi di ripudio.
Rileva protocolli di autenticazione deboli o mancanti e ottieni visibilità e informazioni dettagliate sugli accessi degli utenti e delle applicazioni.
Valuta l'accesso dalle identità al carico di lavoro in base ai requisiti di conformità e considera il rischio dell'account utente, lo stato del dispositivo e altri criteri impostati.
Monitorare i progressi o gli scostamenti dai requisiti di conformità.
La maggior parte delle risorse ha accesso al piano dati. È necessario conoscere le identità che accedono alle risorse e le azioni che eseguono. È possibile utilizzare 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.
ID Microsoft Entra
Tutti i prodotti Power Platform utilizzano Microsoft Entra ID (precedentemente 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. Entra ID è 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 di licenze
L'accesso a Power Apps e Power Automate inizia con l'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 la politica per una decisione di accesso. Per utilizzare l'accesso condizionale, è necessario comprendere le restrizioni richieste per il caso d'uso. Configura l'accesso condizionale di Microsoft Entra impostando criteri di accesso basati sulle tue esigenze operative.
Per altre informazioni, vedi:
- Imposta Microsoft Entra Accesso condizionato
- Accesso condizionale e autenticazione multifattoriale 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 token di accesso si verifica quando un controllo è Fatto 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 Power Platform servizi e client. 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
Invece di concedere autorizzazioni a utenti specifici, assegna l'accesso ai gruppi in Microsoft Entra ID. Se un gruppo non esiste, collabora con il tuo team di 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 ulteriori informazioni, vedi Controllo degli accessi sicuro utilizzando i gruppi in Microsoft Entra ID.
Rilevamento delle minacce
La protezione di Microsoft Entra ID può aiutarti a rilevare, indagare e correggere i rischi basati sull'identità. Per altre informazioni su Intune, vedi Cos'è Identity Protection?.
Il rilevamento delle minacce può assumere la forma della reazione a un avviso di attività sospetta o della ricerca proattiva di eventi anomali nei registri delle attività. L'analisi del comportamento degli utenti e delle entità (UEBA) in Sentinel semplifica il rilevamento di attività sospette. Microsoft Per ulteriori informazioni, vedere Identificare minacce avanzate con UEBA in Microsoft Sentinel.
Registrazione delle identità
Power Apps, Power Automate, Copilot Studio, i connettori e la registrazione delle attività dei dati prevenzione delle perdite vengono monitorati e visualizzati dal portale di conformità Purview. Microsoft Per ulteriori informazioni, vedere Scopri di più 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.
Utilizza Privileged Identity Management (PIM) di Microsoft Entra per gestire ruoli di amministratore con privilegi elevati nell'interfaccia di amministrazione di Power Platform.
Sicurezza dei dati Dataverse
Una delle funzionalità principali di Dataverse è il modello di sicurezza avanzato, in grado di adattarsi a numerosi scenari di uso 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 usa 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 Dataverse. Per altre informazioni, consultare Concetti di sicurezza in Microsoft Dataverse.
Configurazione dell'autenticazione dell'utente in Copilot Studio
Copilot Studio supporta diverse opzioni di autenticazione. Scegli quella più idonea alle tue esigenze. L'autenticazione consente agli utenti di effettuare l'accesso, garantendo così al tuo copilota l'accesso a risorse o informazioni riservate. Gli utenti possono effettuare l'accesso utilizzando Microsoft Entra ID o qualsiasi OAuth provider di identità 2.0, come Google o Facebook. Per ulteriori informazioni, vedere Configurare l'autenticazione utente in Copilot Studio.
Grazie alla sicurezza basata su Direct Line, puoi limitare l'accesso alle posizioni che controlli abilitando l'accesso protetto con segreti o token. Direct Line
Copilot Studio supporta l'accesso singolo (SSO), il che significa che i copiloti possono registrare l'utente. È necessario implementare l'SSO sulle tue pagine web e sulle tue applicazioni mobili. Per Microsoft Teams, l'SSO è semplice se Seleziona si seleziona l'opzione di autenticazione "Solo in Teams". Può anche essere configurato manualmente con Azure AD v2; tuttavia, in questo caso l'app Teams deve essere distribuita come file zip, non tramite la distribuzione di Teams con 1 clic da Copilot Studio.
Altre informazioni:
- Configurare l'accesso singolo con Microsoft Entra ID
- Configurare l'accesso singolo con ID per i copiloti in Microsoft Entra Microsoft Teams
- Configurare l'accesso Single Sign-On con un provider generico OAuth
Accedere in modo sicuro ai dati utilizzando Customer Lockbox
La maggior parte delle operazioni, del supporto e della risoluzione dei problemi eseguiti dal personale (inclusi i sub-responsabili) non richiedono l'accesso ai dati dei clienti. Microsoft 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 quando un tecnico deve accedere ai dati del cliente, sia in risposta, sia in un ticket di supporto avviato dal cliente o in un problema identificato da. Microsoft Microsoft Per ulteriori informazioni, vedi Accedere in modo sicuro ai dati dei clienti utilizzando Customer Lockbox in Power Platform e Dynamics 365.
Informazioni correlate
- Connessione e autenticazione alle fonti dati
- Autenticazione ai servizi Power Platform
- Concetti di sicurezza in Microsoft Dataverse
- Power Platform Domande frequenti sulla sicurezza
- Matrice dei permessi del servizio amministratore
- Valutazione dell'accesso continuo
- Imposta Microsoft Entra Accesso condizionato
- Raccomandazioni per l'accesso condizionale e l'autenticazione multifattoriale in Microsoft Power Automate
- Microsoft piattaforma di identità e flusso di codice di autorizzazione 2.0 OAuth
- Quali sono le novità in Microsoft Entra ID?
- Microsoft Entra ruoli incorporati
- Panoramica del controllo degli accessi basato sui ruoli in Microsoft Entra ID
Elenco di controllo della sicurezza
Fai riferimento alla serie completa di elementi consigliati.