Parte 2: Esigenze di autenticazione in questo scenario di esempio

parte precedente: Introduzione e di sfondo

In questo scenario di esempio, l'applicazione principale ha tre requisiti di autenticazione distinti:

• Azure Key Vault (Archivio chiavi di Azure)

  L'applicazione deve eseguire l'autenticazione con Azure Key Vault per recuperare una chiave API archiviata in modo sicuro necessaria per chiamare un servizio di terze parti.

• API di terze parti

  Dopo aver recuperato la chiave API, l'applicazione la usa per eseguire l'autenticazione con l'API esterna di terze parti.

• Servizio di Coda di Archiviazione Azure

  Dopo l'elaborazione della richiesta, l'applicazione deve eseguire l'autenticazione con Archiviazione code di Azure per inserire un messaggio in coda per un'elaborazione asincrona o differita.

Queste attività richiedono all'app di gestire tre set di credenziali:

• Due per le risorse di Azure (Key Vault e Archiviazione)

• Uno per un servizio esterno (API di terze parti)

Problemi di autenticazione chiave

La creazione di applicazioni cloud sicure richiede un'attenta gestione delle credenziali, soprattutto quando sono coinvolti più servizi. Questo scenario di esempio presenta diverse problematiche critiche:

• Dipendenza circolare da Key Vault

  L'applicazione usa Azure Key Vault per archiviare in modo sicuro i segreti, ad esempio chiavi API di terze parti o credenziali di Archiviazione di Azure. Tuttavia, per recuperare tali segreti, l'app deve prima eseguire l'autenticazione con Key Vault. Questo crea un problema circolare: l'app necessita di credenziali per accedere a Key Vault, ma queste credenziali devono essere archiviate in modo sicuro. Senza una soluzione sicura, ciò potrebbe causare credenziali hardcoded o configurazioni non sicure negli ambienti di sviluppo.

• Gestione sicura delle chiavi API di terze parti

  Dopo aver recuperato la chiave API da Key Vault, l'applicazione deve usarla per chiamare un servizio esterno di terze parti. Questa chiave deve essere gestita con estrema attenzione:

  • Mai inserito in modo fisso nel codice sorgente o nei file di configurazione.
  • Non è mai stato eseguito l'accesso a stdout, stderr o ai log dell'applicazione
  • Mantenuto solo in memoria e accessibile in fase di esecuzione, subito prima dell'uso
  • Eliminato tempestivamente dopo il completamento della richiesta

  L'impossibilità di seguire queste procedure aumenta il rischio di perdita di credenziali o uso non autorizzato.

• Protezione delle credenziali di Azure Queue Storage

  Per scrivere messaggi nell'Archiviazione code di Azure, l'app di solito richiede una stringa di connessione o un token di accesso condiviso. Queste credenziali:

  • Deve essere archiviato in una posizione sicura, ad esempio Key Vault
  • Non deve essere visualizzato nei log, nelle tracce dello stack o negli strumenti di sviluppo
  • L'accesso deve essere eseguito solo tramite meccanismi di runtime sicuri
  • Richiedere una configurazione del controllo degli accessi in base al ruolo appropriata se si usa l'identità gestita

• Flessibilità dell'ambiente

  L'app deve essere eseguita in modo affidabile sia negli ambienti di sviluppo locale che in ambienti di produzione cloud, usando la stessa codebase e la logica condizionale minima.

  Questo significa che:

  • Nessun segreto specifico dell'ambiente incorporato nel codice
  • Non è necessario attivare o disattivare manualmente le credenziali o i percorsi logici
  • Uso coerente dell'autenticazione basata su identità tra ambienti

Azure-First l'autenticazione con Microsoft Entra ID

Man mano che le applicazioni cloud aumentano la complessità e si integrano con più servizi, l'autenticazione sicura e semplificata diventa essenziale. Azure offre un modello di identità "azure-first" tramite Microsoft Entra ID, consentendo la gestione unificata delle identità e l'integrazione senza problemi con i servizi di Azure per l'autenticazione sicura e senza credenziali.

Anziché gestire manualmente i segreti o incorporare le credenziali nel codice dell'applicazione, una pratica soggetta a rischi per la sicurezza, Microsoft Entra ID consente alle app di eseguire l'autenticazione in modo sicuro usando le identità gestite.

I principali vantaggi delle identità gestite di Microsoft Entra sono:

• Nessun segreto nel codice

  Le applicazioni non richiedono più stringhe di connessione hardcoded, segreti client o chiavi.

• Identità predefinita per le app

  Azure può assegnare automaticamente un'identità gestita all'app, consentendo l'accesso sicuro ai servizi, ad esempio Key Vault, Archiviazione e SQL senza credenziali aggiuntive.

• Coerenza degli ambienti

  Lo stesso codice e lo stesso modello di identità funzionano sia in ambienti di sviluppo locale che ospitati in Azure usando DefaultAzureCredential di Azure SDK.

Flusso di identità specifico dell'ambiente

Le applicazioni che usano Microsoft Entra ID per l'autenticazione traggono vantaggio da un modello di identità flessibile che funziona perfettamente sia negli ambienti di sviluppo ospitati in Azure che in ambienti di sviluppo locali. Questa coerenza viene ottenuta usando l'SDK di DefaultAzureCredentialAzure, che seleziona automaticamente il metodo di identità appropriato in base all'ambiente.

Ambiente di Azure

Quando l'applicazione viene distribuita in Azure:

• Un'identità gestita viene assegnata automaticamente all'applicazione.
• Azure gestisce internamente il rilascio dei token e il ciclo di vita delle credenziali, senza richiedere segreti manuali.
• L'applicazione utilizza il controllo di accesso Role-Based (RBAC) o le politiche di accesso di Key Vault per accedere ai servizi

Ambiente di sviluppo locale

Durante lo sviluppo locale:

• Un'entità servizio funge da identità dell'app.
• Gli sviluppatori eseguono l'autenticazione usando l'interfaccia della riga di comando di Azure (az login), le variabili di ambiente o le integrazioni di Visual Studio/VS Code.
• Lo stesso codice dell'applicazione viene eseguito senza modifiche — solo l'origine dell'identità cambia.

In entrambi gli ambienti, gli SDK di Azure usano DefaultAzureCredential, che astrae l'origine dell'identità e seleziona automaticamente il metodo corretto.

Procedure consigliate per lo sviluppo sicuro

Anche se è possibile impostare i segreti come variabili di ambiente (ad esempio, tramite Impostazioni app di Azure), questo approccio presenta svantaggi:

• È necessario replicare manualmente i segreti negli ambienti locali.
• C'è un rischio di perdita di segreti nel controllo del codice sorgente.
• È possibile che sia necessaria una logica aggiuntiva per distinguere gli ambienti.

L'approccio consigliato è invece:

• Usare Key Vault per archiviare chiavi API di terze parti e altri segreti.
• Assegnare all'app distribuita l'identità gestita.
• Usare un principal del servizio per lo sviluppo locale e assegnargli gli stessi diritti di accesso.
• Usare DefaultAzureCredential nel codice per astrarre la logica di autenticazione.
• Evitare di archiviare o registrare le credenziali.

Flusso di autenticazione in pratica

Ecco come funziona l'autenticazione in fase di esecuzione:

• Il codice crea un'istanza DefaultAzureCredential .
• Questa credenziale viene utilizzata per creare un'istanza client, ad esempio SecretClient, QueueServiceClient.
• Quando l'app richiama un metodo (ad esempio, get_secret()), il client usa le credenziali per autenticare la richiesta.
• Azure verifica l'identità e verifica se ha il ruolo o i criteri corretti per eseguire l'operazione.

Questo flusso garantisce che l'app possa accedere in modo sicuro ai servizi di Azure senza incorporare segreti nel codice o nei file di configurazione. Consente anche di passare facilmente tra lo sviluppo locale e la distribuzione cloud senza modificare la logica di autenticazione.

parte 3 - Implementazione dell'API di terze parti >>>