Concedere a un'app l'accesso alle risorse dell'hub di Azure Stack

Un'applicazione che distribuisce o configura le risorse tramite Azure Resource Manager deve essere rappresentata dalla propria identità, nota come entità di sicurezza. Proprio come un utente è rappresentato da un'entità utente, un'app è rappresentata da un'entità servizio.

L'identità può essere usata anche per delegare solo le autorizzazioni necessarie all'utente o all'app. Ad esempio, un'app di gestione della configurazione potrebbe usare Azure Resource Manager per inventariare le risorse di Azure. L'app verrà registrata nella directory, quindi aggiunta al ruolo "lettore" nell'ambito appropriato, limitando l'app all'accesso in sola lettura.

Panoramica

Come un utente, un'app deve presentare le credenziali durante l'autenticazione, che richiede due elementi:

• Un ID applicazione, talvolta detto ID client. Un GUID che identifica in modo univoco la registrazione dell'app nel tenant di Active Directory.
• Segreto. È possibile generare una stringa di segreto client (simile a una password) o specificare un'identificazione personale del certificato X509 (che usa la chiave pubblica).

L'esecuzione di un'app con la propria identità è preferibile rispetto all'esecuzione con l'identità dell'utente per i motivi seguenti:

• Credenziali più sicure: un'app può accedere usando un certificato X509 invece di una password o un segreto condiviso costituito da testo.
• Autorizzazioni più restrittive che è possibile assegnare a un'app. In genere, queste autorizzazioni sono limitate solo a ciò che l'app deve fare e si parla infatti di principio dei privilegi minimi.
• Credenziali e autorizzazioni cambiano meno di frequente nel caso di un'app rispetto alle credenziali utente. Quando le responsabilità dell'utente cambiano o quando un utente lascia l'azienda, i requisiti delle password richiedono ad esempio una modifica.

Si inizia creando una nuova registrazione dell'app nella directory, che crea un oggetto entità servizio associato per rappresentare l'identità dell'app all'interno della directory. Il processo di registrazione varia a seconda della directory scelta per l'istanza dell'hub di Azure Stack:

• Microsoft Entra ID: Microsoft Entra ID è un servizio multi-tenant, basato sul cloud, directory e gestione delle identità. È possibile usare Microsoft Entra ID con un'istanza dell'hub di Azure Stack connessa. Gli esempi presentati più avanti useranno il portale di Azure per la registrazione dell'app Microsoft Entra.
• Active Directory Federation Services (AD FS): AD FS offre funzionalità di accesso Single Sign-On (SSO) semplificate, protette e Single Sign-On (SSO). È possibile usare AD FS con istanze dell'hub di Azure Stack connesse e disconnesse. Gli esempi presentati più avanti useranno Azure Stack Hub PowerShell per la registrazione delle app AD FS.

Dopo aver registrato l'app, si apprenderà come assegnarla a un ruolo, limitandone l'accesso alle risorse.

Gestire un'app AD FS

Se l'hub di Azure Stack è stato distribuito con AD FS come servizio di gestione delle identità, è necessario usare PowerShell per gestire l'identità dell'app. Gli esempi seguenti illustrano sia un certificato X509 che una credenziale del segreto client.

Gli script devono essere eseguiti in una console di PowerShell con privilegi elevati ("Esegui come amministratore"), che apre un'altra sessione a una macchina virtuale che ospita un endpoint con privilegi per l'istanza dell'hub di Azure Stack. Dopo aver stabilito la sessione dell'endpoint con privilegi, vengono usati cmdlet aggiuntivi per creare e gestire la registrazione dell'app. Per altre informazioni sull'endpoint con privilegi, vedere Uso dell'endpoint con privilegi nell'hub di Azure Stack.

Creare una registrazione dell'app che usa una credenziale del certificato

Quando si creano credenziali del certificato, è necessario soddisfare i requisiti seguenti:

• Per la produzione, il certificato deve essere rilasciato da un'autorità di certificazione interna o da un'autorità di certificazione pubblica. Quando si usa un'autorità pubblica, è necessario includere l'autorità nell'immagine del sistema operativo di base come parte del programma Microsoft Trusted Root Authority. Per l'elenco completo, vedere Elenco dei partecipanti - Microsoft Trusted Root Program. Un esempio di creazione di un certificato di test "autofirmato" verrà visualizzato in un secondo momento durante l'aggiornamento delle credenziali di un certificato.
• Il provider di crittografia deve essere specificato come provider di chiavi CSP (Cryptographic Service Provider) legacy di Microsoft.
• Il formato del certificato deve essere indicato nel file PFX, perché sono necessarie sia le chiavi pubbliche che private. Nei server Windows si usano file PFX che contengono il file di chiave pubblica (file di certificato TLS/SSL) e il file di chiave privata associato.
• L'infrastruttura dell'hub di Azure Stack deve avere accesso di rete al percorso dell'elenco di revoche di certificati (CRL) dell'autorità di certificazione pubblicato nel certificato. Questo CRL deve essere un endpoint HTTP.

Dopo aver ottenuto un certificato, usare lo script di PowerShell seguente per registrare l'app e accedere usando l'identità dell'app. Sostituire i propri valori per i segnaposto seguenti:

Aggiornare le credenziali di un certificato

Dopo aver registrato l'applicazione, questa sezione illustra come:

1. Creare un nuovo certificato X509 autofirmato per il test.
2. Aggiornare le credenziali dell'applicazione aggiornando la relativa proprietà Thumbprint in modo che corrisponda al nuovo certificato.

Aggiornare le credenziali del certificato usando PowerShell, sostituendo i propri valori per i segnaposto seguenti:

1. Usando la sessione di Windows PowerShell con privilegi elevati, eseguire i cmdlet seguenti:

   # Create a PSSession to the PrivilegedEndpoint VM
   $Session = New-PSSession -ComputerName "<PepVM>" -ConfigurationName PrivilegedEndpoint -Credential $Creds -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US)
   
   # Create a self-signed certificate for testing purposes, using the New-SelfSignedCertificate cmdlet 
   # See https://video2.skills-academy.com/powershell/module/pki/new-selfsignedcertificate for usage details, including using the -Provider parameter
   $NewCert = New-SelfSignedCertificate -CertStoreLocation "cert:\CurrentUser\My" -Subject "CN=<YourAppName>" -KeySpec KeyExchange
   # In production, use Get-Item to retrieve a managed certificate from the certificate store.
   # Alteratively, use Get-Certificate for a .cer file, or Get-PfxCertificate for a .pfx file.
   # $Cert = Get-Item "<YourCertificateLocation>"
   
   # Use the privileged endpoint to update the certificate thumbprint, used by <AppIdentifier>
   $SpObject = Invoke-Command -Session $Session -ScriptBlock {Set-GraphApplication -ApplicationIdentifier "<AppIdentifier>" -ClientCertificates $using:NewCert}
   $Session | Remove-PSSession
   
   # Output the updated service principal details
   $SpObject
   

2. Al termine dello script, vengono visualizzate le informazioni di registrazione dell'app aggiornate, incluso il valore di identificazione personale per il nuovo certificato autofirmato.

   ApplicationIdentifier : S-1-5-21-1512385356-3796245103-1243299919-1356
   ClientId              : 
   Thumbprint            : AF22EE716909041055A01FE6C6F5C5CDE78948E9
   ApplicationName       : Azurestack-MyApp-c30febe7-1311-4fd8-9077-3d869db28342
   ClientSecret          : 
   PSComputerName        : azs-ercs01
   RunspaceId            : a580f894-8f9b-40ee-aa10-77d4d142b4e5
   

Creare una registrazione dell'app che usa credenziali del segreto client

Ora si crea un'altra registrazione dell'app, ma questa volta si specifica una credenziale del segreto client. A differenza di una credenziale del certificato, la directory ha la possibilità di generare credenziali del segreto client. Anziché specificare il segreto client, usare l'opzione -GenerateClientSecret per richiedere che venga generata. Sostituire i propri valori per i segnaposto seguenti:

Aggiornare le credenziali di un segreto client

Aggiornare le credenziali del segreto client usando PowerShell, usando il parametro ResetClientSecret , che modifica immediatamente il segreto client. Sostituire i propri valori per i segnaposto seguenti:

1. Usando la sessione di Windows PowerShell con privilegi elevati, eseguire i cmdlet seguenti:

   # Create a PSSession to the PrivilegedEndpoint VM
   $Session = New-PSSession -ComputerName "<PepVM>" -ConfigurationName PrivilegedEndpoint -Credential $Creds -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US)
   
   # Use the privileged endpoint to update the client secret, used by <AppIdentifier>
   $SpObject = Invoke-Command -Session $Session -ScriptBlock {Set-GraphApplication -ApplicationIdentifier "<AppIdentifier>" -ResetClientSecret}
   $Session | Remove-PSSession
   
   # Output the updated service principal details
   $SpObject
   

2. Al termine dello script, vengono visualizzate le informazioni di registrazione dell'app aggiornate, incluso il segreto client appena generato.

   ApplicationIdentifier : S-1-5-21-1634563105-1224503876-2692824315-2623
   ClientId              : 11112222-bbbb-3333-cccc-4444dddd5555
   Thumbprint            : 
   ApplicationName       : Azurestack-YourApp-6967581b-497e-4f5a-87b5-0c8d01a9f146
   ClientSecret          : MKUNzeL6PwmlhWdHB59c25WDDZlJ1A6IWzwgv_Kn
   PSComputerName        : azs-ercs01
   RunspaceId            : 6ed9f903-f1be-44e3-9fef-e7e0e3f48564
   

Rimuovere una registrazione dell'app

Si vedrà ora come rimuovere una registrazione dell'app dalla directory usando PowerShell.

Sostituire i propri valori per i segnaposto seguenti:

# Sign in to PowerShell interactively, using credentials that have access to the VM running the Privileged Endpoint (typically <domain>\cloudadmin)
$Creds = Get-Credential

# Create a PSSession to the PrivilegedEndpoint VM
$Session = New-PSSession -ComputerName "<PepVM>" -ConfigurationName PrivilegedEndpoint -Credential $Creds -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US)

# OPTIONAL: Use the privileged endpoint to get a list of applications registered in AD FS
$AppList = Invoke-Command -Session $Session -ScriptBlock {Get-GraphApplication}

# Use the privileged endpoint to remove application <AppIdentifier>
Invoke-Command -Session $Session -ScriptBlock {Remove-GraphApplication -ApplicationIdentifier "<AppIdentifier>"}

Non verrà restituito alcun output dalla chiamata al cmdlet Remove-GraphApplication nell'endpoint con privilegi, ma verrà visualizzato l'output di conferma verbatim nella console durante l'esecuzione del cmdlet:

VERBOSE: Deleting graph application with identifier S-1-5-21-1634563105-1224503876-2692824315-2623.
VERBOSE: Remove-GraphApplication : BEGIN on AZS-ADFS01 on ADFSGraphEndpoint
VERBOSE: Application with identifier S-1-5-21-1634563105-1224503876-2692824315-2623 was deleted.
VERBOSE: Remove-GraphApplication : END on AZS-ADFS01 under ADFSGraphEndpoint configuration

Assegnare un ruolo

L'accesso alle risorse di Azure da parte di utenti e app viene autorizzato tramite Role-Based Controllo di accesso il controllo degli accessi in base al ruolo (RBAC). Per consentire a un'app di accedere alle risorse nella sottoscrizione, è necessario assegnare l'entità servizio a un ruolo per una risorsa specifica. Prima di tutto decidere quale ruolo rappresenta le autorizzazioni appropriate per l'app. Per informazioni sui ruoli disponibili, vedere Ruoli predefiniti per le risorse di Azure.

Il tipo di risorsa scelto stabilisce anche l'ambito di accesso per l'app. È possibile impostare l'ambito di accesso a livello di sottoscrizione, gruppo di risorse o risorsa. Le autorizzazioni vengono ereditate a livelli inferiori dell'ambito. Ad esempio, aggiungendo un'app al ruolo "Lettore" per un gruppo di risorse, significa che può leggere il gruppo di risorse e tutte le risorse in esso contenute.

1. Accedere al portale appropriato, in base alla directory specificata durante l'installazione dell'hub di Azure Stack , ad esempio il portale di Azure per Microsoft Entra ID o il portale utenti dell'hub di Azure Stack per AD FS. In questo esempio viene mostrato un utente che ha eseguito l'accesso al portale utenti dell'hub di Azure Stack.

   Nota

   Per aggiungere assegnazioni di ruolo per una determinata risorsa, l'account utente deve appartenere a un ruolo che dichiara l'autorizzazione Microsoft.Authorization/roleAssignments/write . Ad esempio, i ruoli predefiniti Proprietario o Amministratore accesso utenti .

2. Passare alla risorsa a cui si vuole consentire l'accesso all'app. In questo esempio assegnare l'app a un ruolo nell'ambito della sottoscrizione selezionando Sottoscrizioni e quindi una sottoscrizione specifica. È invece possibile selezionare un gruppo di risorse o una risorsa specifica come una macchina virtuale.

   

3. Selezionare la pagina Controllo di accesso (IAM), che è universale per tutte le risorse che supportano il controllo degli accessi in base al ruolo.

4. Selezionare + Aggiungi

5. In Ruolo selezionare il ruolo da assegnare all'app.

6. In Seleziona cercare l'app usando un nome applicazione completo o parziale. Durante la registrazione, il nome dell'applicazione viene generato come Azurestack-YourAppName-GUID<><>. Ad esempio, se si usa un nome applicazione di App2 e GUID 2bbe67d8-3fdb-4b62-87cf-cc41ddd434ff è stato assegnato durante la creazione, il nome completo sarà Azurestack-App2-2bbe67d8-3fdb-4b62-87cf-cc41ddd444ff. È possibile cercare la stringa esatta o una parte, ad esempio Azurestack o Azurestack-App2.

7. Dopo aver trovato l'app, selezionarla e verrà visualizzata in Membri selezionati.

8. Selezionare Salva per completare l'assegnazione del ruolo.

   

9. Al termine, l'app visualizzerà nell'elenco delle entità assegnate per l'ambito corrente, per il ruolo specificato.

   

Dopo aver assegnato all'app un'identità e autorizzata per l'accesso alle risorse, è possibile abilitare lo script o il codice per accedere e accedere in modo sicuro alle risorse dell'hub di Azure Stack.

Passaggi successivi

Gestire le autorizzazioni utente
documentazione Microsoft Entra
Active Directory Federation Services