Condividi tramite

Framework del modello di applicazione sicura

  • Articolo

Microsoft sta introducendo un framework sicuro e scalabile per l'autenticazione di partner cloud solution provider (CSP) e fornitori di Pannello di controllo (CPV) tramite l'architettura di Autenticazione a più fattori (MFA) di Microsoft Azure. I partner CSP e i fornitori di Pannello di controllo possono basarsi sul nuovo modello per elevare la sicurezza per le chiamate di integrazione delle API del Centro per i partner. Ciò consente a tutte le parti, inclusi Microsoft, partner CSP e fornitori di Pannello di controllo di proteggere l'infrastruttura e i dati dei clienti dai rischi per la sicurezza.

Importante

Azure Active Directory (Azure AD) Graph è deprecato a partire dal 30 giugno 2023. In futuro non verranno effettuati ulteriori investimenti in Azure AD Graph. Le API Graph di Azure AD non hanno alcun contratto di servizio o impegno di manutenzione oltre alle correzioni correlate alla sicurezza. Gli investimenti in nuove funzionalità e funzionalità verranno effettuati solo in Microsoft Graph.

Azure AD Graph verrà ritirato nei passaggi incrementali in modo da avere tempo sufficiente per eseguire la migrazione delle applicazioni alle API Di Microsoft Graph. A una data successiva che verrà annunciata, si bloccherà la creazione di nuove applicazioni usando Azure AD Graph.

Per altre informazioni, vedere Importante: Ritiro di Azure AD Graph e Deprecazione del modulo PowerShell.

Ambito

Questo articolo si applica ai partner seguenti:

  • Pannello di controllo fornitori (CPV) sono fornitori di software indipendenti che sviluppano app per l'uso da parte dei partner CSP per l'integrazione con le API del Centro per i partner. Un CPV non è un partner CSP con accesso diretto al dashboard o alle API del partner. Sono le aziende che sviluppano applicazioni (in genere app Web) che consentono ai provider di servizi cloud di vendere i propri prodotti tramite un marketplace unificato.
  • I fornitori indiretti CSP e i partner diretti CSP che usano l'autenticazione ID app + utente e si integrano direttamente con le API del Centro per i partner.

Nota

Per qualificarsi come CPV, è prima necessario eseguire l'onboarding nel Centro per i partner come CPV. Se si è un partner CSP esistente che è anche un CPV, questo prerequisito si applica anche all'utente.

Sviluppo di applicazioni sicure

Nel processo di inserimento degli ordini per i prodotti Microsoft per conto dei CSP, le applicazioni del marketplace dalle CPU interagiscono con le API Microsoft per effettuare ordini e effettuare il provisioning delle risorse per i clienti.

Alcune di queste API includono:

  • API del Centro per i partner che implementano operazioni commerciali come l'inserimento di ordini e la gestione dei cicli di vita delle sottoscrizioni.
  • API Microsoft Graph che implementano la gestione delle identità per i tenant CSP e i tenant del cliente CSP.
  • API di Azure Resource Manager (ARM) che implementano la funzionalità di distribuzione di Azure.

I partner CSP sono autorizzati a usare privilegi delegati per agire per conto dei propri clienti quando chiamano le API Microsoft. I privilegi delegati consentono ai partner CSP di completare scenari di acquisto, distribuzione e supporto per i clienti.

Le applicazioni marketplace sono progettate per aiutare i partner CSP a elencare le proprie soluzioni per i clienti. A tale scopo, le applicazioni del marketplace devono rappresentare i privilegi dei partner CSP per chiamare le API Microsoft.

Poiché i privilegi dei partner CSP sono elevati e forniscono l'accesso a tutti i clienti del partner, è importante comprendere come queste applicazioni devono essere progettate per resistere ai vettori di sfruttamento della sicurezza. Gli attacchi alla sicurezza di queste applicazioni sensibili possono compromettere i dati dei clienti. Pertanto, le concessioni di autorizzazione e la rappresentazione dei privilegi partner devono essere progettate per rispettare il principio dei privilegi minimi. I principi e le procedure consigliate seguenti assicurano che le applicazioni marketplace siano sostenibili e possano resistere a compromessi.

Principi di sicurezza per la rappresentazione delle credenziali

  • Le applicazioni marketplace non devono archiviare credenziali dai partner CSP.

  • Le password utente partner CSP non devono essere condivise.

  • Le chiavi dell'app Web del tenant del partner CSP non devono essere condivise con i fornitori di Pannello di controllo.

  • Un'applicazione marketplace deve presentare l'identità dell'applicazione insieme alle informazioni sui partner anziché usare solo le credenziali del partner quando effettuano chiamate che rappresentano un'identità partner CSP.

  • L'accesso a un'applicazione marketplace deve essere basato sul principio dei privilegi minimi e chiaramente articolato nelle autorizzazioni.

  • L'autorizzazione per un'applicazione marketplace deve essere votata per più credenziali.

  • Le credenziali dell'applicazione e le credenziali del partner devono essere fornite insieme per ottenere l'accesso.

    Importante

    È importante che non vi sia un unico punto di compromesso.

  • L'accesso deve essere limitato a un gruppo di destinatari o api specifico.

  • L'accesso deve identificare lo scopo della rappresentazione.

  • Le autorizzazioni di accesso per un'applicazione marketplace devono essere associate al tempo. I partner CSP devono essere in grado di rinnovare o revocare l'accesso all'applicazione marketplace.

  • I processi di controllo rapido o correzione devono essere applicati per gestire le compromissioni delle credenziali dell'applicazione del Marketplace.

  • Tutti gli account utente devono usare l'autenticazione a due fattori (2FA).

  • Il modello applicativo deve essere compatibile con le disposizioni di sicurezza aggiuntive, ad esempio l'accesso condizionale a un modello di sicurezza migliore.

Nota

I provider indiretti CSP e i partner diretti CSP che usano l'ID app e l'autenticazione utente e si integrano direttamente con le API del Centro per i partner sono tenuti a seguire i principi precedenti per proteggere le proprie applicazioni del marketplace.

Identità e concetti dell'applicazione

Applicazioni multi-tenant

Un'applicazione multi-tenant è in genere un'applicazione SaaS (Software as a Service). È possibile configurare l'applicazione per accettare gli accessi da qualsiasi tenant di Microsoft Entra configurando il tipo di applicazione come multi-tenant nel dashboard di Azure. Gli utenti di qualsiasi tenant di Microsoft Entra potranno accedere all'applicazione dopo aver acconsentito all'uso del proprio account con l'applicazione.

Per altre informazioni sulla creazione di un'applicazione multi-tenant, vedere Accedere a qualsiasi utente di Microsoft Entra usando il modello di applicazione multi-tenant.

Affinché un utente possa accedere a un'applicazione in Microsoft Entra ID, l'applicazione deve essere rappresentata nel tenant dell'utente, che consente all'organizzazione di eseguire operazioni come applicare criteri univoci quando gli utenti dal tenant accedono all'applicazione. Per un'applicazione a tenant singolo, questa registrazione è semplice: è quella che si verifica quando si registra l'applicazione nel dashboard di Azure.

Per un'applicazione multi-tenant, la registrazione iniziale per l'applicazione si trova nel tenant di Microsoft Entra usato dallo sviluppatore. Quando un utente di un tenant diverso accede all'applicazione per la prima volta, Microsoft Entra ID chiede di fornire il consenso alle autorizzazioni richieste dall'applicazione. Se hanno il consenso, viene creata una rappresentazione dell'applicazione denominata entità servizio nel tenant dell'utente e il processo di accesso può continuare. Viene creata anche una delega nella directory che registra il consenso dell'utente all'applicazione.

Nota

I provider indiretti CSP e i partner diretti CSP che usano l'ID app e l'autenticazione utente e si integrano direttamente con le API del Centro per i partner dovranno fornire il consenso all'applicazione marketplace usando lo stesso framework di consenso.

L'esperienza di consenso è influenzata dalle autorizzazioni richieste dall'applicazione. Microsoft Entra ID supporta due tipi di autorizzazioni, solo app e delegate.

  • L'autorizzazione solo app viene concessa direttamente all'identità dell'applicazione. Ad esempio, è possibile concedere a un'applicazione l'autorizzazione per leggere l'elenco di utenti in un tenant, indipendentemente dall'utente che ha eseguito l'accesso all'applicazione.
  • L'autorizzazione delegata concede a un'applicazione la possibilità di agire come utente connesso per un subset delle operazioni che l'utente può eseguire. Ad esempio, è possibile concedere a un'applicazione l'autorizzazione delegata per leggere il calendario dell'utente connesso.

Alcune autorizzazioni vengono concesse da un utente normale, mentre altre richiedono il consenso di un amministratore tenant. Per altre informazioni sul framework di consenso di Microsoft Entra, vedere Informazioni sulle esperienze di consenso dell'applicazione Microsoft Entra.

Flusso di token OAuth (Open Authorization) dell'applicazione multi-tenant

In un flusso OAuth (Open Authorization) di un'applicazione multi-tenant, l'applicazione viene rappresentata come applicazione multi-tenant nel tenant del partner CPV o CSP.

Per accedere alle API Microsoft (API del Centro per i partner, API Graph e così via), i partner CSP devono accedere all'applicazione e fornire il consenso per consentire all'applicazione di chiamare le API per loro conto.

Nota

I provider indiretti CSP e i partner diretti CSP che usano l'ID app e l'autenticazione utente e si integrano direttamente con le API del Centro per i partner dovranno fornire il consenso all'applicazione marketplace per usare lo stesso framework di consenso.

L'applicazione ottiene l'accesso alle risorse del partner, ad esempio le API graph e del Centro per i partner, tramite il consenso e le concessioni OAuth.

Creare un'applicazione multi-tenant

Un'applicazione multi-tenant deve rispettare i requisiti seguenti:

  • Deve essere un'app Web con un ID applicazione e una chiave privata.
  • Deve avere la modalità di autenticazione implicita disattivata.

È inoltre consigliabile attenersi a queste procedure consigliate:

  • Usare un certificato per la chiave privata.
  • Abilitare l'accesso condizionale per applicare restrizioni dell'intervallo IP. Ciò potrebbe richiedere l'abilitazione di altre funzionalità nel tenant di Microsoft Entra.
  • Applicare i criteri di durata dei token di accesso per l'applicazione.

Quando si acquisisce un token, è necessario presentare l'ID app e la chiave privata. La chiave privata può essere un certificato.

L'applicazione può essere configurata per chiamare più API, incluse le API di Azure Resource Manager. Di seguito è riportato il set minimo di autorizzazioni necessarie per le API del Centro per i partner:

  • Autorizzazioni delegate per l'ID Di Microsoft Entra: accedere alla directory come utente connesso
  • Autorizzazioni delegate per le API del Centro per i partner: Accesso

Un'applicazione multi-tenant deve acquisire il consenso dei partner e usare il consenso e concedere per effettuare ulteriori chiamate alle API del Centro per i partner. Il consenso viene acquisito tramite un flusso di codice di autenticazione OAuth.

Per acquisire il consenso, i partner CPV o CSP devono creare un sito Web di onboarding in grado di accettare una concessione di codice di autenticazione da Microsoft Entra ID.

Per altre informazioni, vedere Autorizzare l'accesso alle applicazioni Web di Azure Active e Directory usando il flusso di concessione del codice OAuth 2.0.

Ecco i passaggi per un'applicazione multi-tenant per acquisire il consenso del partner CSP insieme a un token riutilizzabile per effettuare chiamate alle API del Centro per i partner.

Per acquisire il consenso del partner, seguire questa procedura.

  1. Creare un'applicazione Web di onboarding partner in grado di ospitare un collegamento di consenso che il partner possa fare clic per accettare il consenso per l'applicazione multi-tenant.
  2. Il partner CSP fa clic sul collegamento di consenso. Ad esempio, https://login.microsoftonline.com/common/oauth2/authorize?&client_id=<marketplaceappid>&response_ty
  3. La pagina di accesso di Microsoft Entra illustra le autorizzazioni che verranno concesse all'applicazione per conto dell'utente. Il partner CSP può decidere di usare le credenziali dell'agente di amministrazione o dell'agente di vendita per accedere e approvare il consenso. All'applicazione vengono concesse le autorizzazioni in base al ruolo utente usato per accedere.
  4. Dopo aver concesso il consenso, Microsoft Entra ID crea un'entità servizio dell'applicazione multi-tenant CPV nel tenant del partner CSP. All'applicazione vengono concesse concessioni OAuth per agire per conto dell'utente. Queste concessioni consentono all'applicazione multi-tenant di chiamare le API del Centro per i partner per conto del partner. A questo punto, la pagina di accesso di Microsoft Entra reindirizza all'applicazione Web di onboarding partner. L'applicazione Web riceve un codice di autorizzazione da Microsoft Entra ID. L'applicazione Web di onboarding del partner deve usare il codice di autorizzazione insieme all'ID applicazione e alla chiave privata per chiamare l'API Token ID Entra Microsoft per ottenere un token di aggiornamento.
  5. Archiviare in modo sicuro il token di aggiornamento. Il token di aggiornamento fa parte delle credenziali del partner usate per ottenere l'accesso alle API del Centro per i partner per conto del partner. Dopo aver acquisito il token di aggiornamento, crittografarlo e archiviarlo in un archivio chiavi segrete, ad esempio l'insieme di credenziali delle chiavi di Azure.

Flusso di chiamata della richiesta di token

Le CPU o l'applicazione del partner CSP devono acquisire un token di accesso prima di effettuare chiamate alle API del Centro per i partner. Queste API sono rappresentate nell'URL https://api.partnercenter.microsoft.comdella risorsa .

Un'applicazione CPV deve identificare l'account partner che deve rappresentare per chiamare le API del Centro per i partner in base al prodotto o all'accesso federato. L'applicazione recupera il token di aggiornamento crittografato per il tenant partner dall'archivio chiavi segrete. Il token di aggiornamento deve essere decrittografato prima dell'uso.

Per i partner CSP in cui è presente un solo tenant che fornisce il consenso, l'account partner fa riferimento al tenant del partner CSP.

Il token di aggiornamento è un token multi-audience. Ciò significa che il token di aggiornamento può essere usato per ottenere un token per più destinatari in base al consenso concesso. Ad esempio, se viene fornito il consenso del partner per le API del Centro per i partner e le API Microsoft Graph, il token di aggiornamento può essere usato per richiedere un token di accesso per entrambe le API. Il token di accesso ha la concessione "per conto di" e consente a un'applicazione del marketplace di rappresentare il partner che ha acconsentito durante la chiamata di queste API.

Un token di accesso può essere acquisito per un singolo gruppo di destinatari alla volta. Se un'applicazione deve accedere a più API, deve richiedere più token di accesso per il gruppo di destinatari di destinazione. Per richiedere un token di accesso, l'applicazione deve chiamare l'API Token ID Microsoft Entra. In alternativa, potrebbe anche usare AuthenticationContext.AcquireTokenAsync di Microsoft Entra SDK e passare le informazioni seguenti:

  • URL della risorsa, ovvero l'URL dell'endpoint per l'applicazione da chiamare. Ad esempio, l'URL della risorsa per l'API del Centro per i partner Microsoft è https://api.partnercenter.microsoft.com.
  • Credenziali dell'applicazione costituite dall'ID applicazione e dalla chiave privata dell'app Web.
  • Token di aggiornamento

Il token di accesso risultante consente all'applicazione di effettuare chiamate alle API indicate nella risorsa. L'applicazione non può richiedere un token di accesso per le API a cui non è stata concessa l'autorizzazione come parte della richiesta di consenso. Il valore dell'attributo UserPrincipalName (UPN) è il nome utente di Microsoft Entra per gli account utente.

Altre considerazioni

Accesso condizionale

Quando si tratta di gestire le risorse cloud, un aspetto chiave della sicurezza del cloud è l'identità e l'accesso. In un mondo mobile-first, cloud-first, gli utenti possono accedere alle risorse dell'organizzazione usando vari dispositivi e app da qualsiasi luogo. Concentrandosi semplicemente su chi può accedere a una risorsa non è più sufficiente. Per bilanciare l'equilibrio tra sicurezza e produttività, è anche necessario considerare il modo in cui si accede a una risorsa. Usando l'accesso condizionale Microsoft Entra, è possibile soddisfare questo requisito. Con l'accesso condizionale è possibile implementare decisioni di controllo di accesso automatiche per l'accesso alle app cloud in base a determinate condizioni.

Per altre informazioni, vedere Che cos'è l'accesso condizionale in Microsoft Entra ID?

Restrizioni basate sull'intervallo IP

È possibile limitare il rilascio dei token solo a un intervallo specifico di indirizzi IP. Questa funzionalità consente di limitare la superficie di attacco solo a una rete specifica.

Autenticazione a più fattori

L'applicazione dell'autenticazione a più fattori consente di limitare le situazioni di compromissione delle credenziali applicando la verifica delle credenziali a due o più moduli. Questa funzionalità consente a Microsoft Entra ID di convalidare l'identità del chiamante tramite canali secondari sicuri, ad esempio dispositivi mobili o e-mail, prima di emettere token.

Per altre informazioni, vedere Funzionamento: Azure Multi.

Contenuto correlato