Condividi tramite


Proteggere i segreti in Azure Pipelines

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Questo articolo illustra le procedure consigliate per la protezione dei segreti in Azure Pipelines. Un segreto è qualsiasi elemento per cui si vuole controllare rigorosamente l'accesso, ad esempio chiavi API, password, certificati o chiavi crittografiche.

Azure Pipelines non genera valori segreti. Potrebbe tuttavia essere necessario aggiungere un segreto a una pipeline per archiviare dati sensibili come una chiave API. Per altre informazioni sull'impostazione delle variabili segrete, vedere Impostare le variabili segrete.

Non usare segreti se è disponibile un altro metodo

Il metodo migliore per proteggere un segreto non è avere un segreto al primo posto. Verificare se la pipeline può usare un metodo diverso rispetto all'uso di un segreto per eseguire un'attività.

  • Usare le connessioni al servizio:
    • Quando si usa Azure o altri servizi, usare le connessioni al servizio anziché gestire i segreti nelle variabili.
    • Le connessioni al servizio consentono di connettersi in modo sicuro a servizi esterni senza esporre informazioni riservate direttamente nella configurazione della pipeline.
    • Per altre informazioni, vedere Gestire le connessioni al servizio e Connettersi a Microsoft Azure con una connessione al servizio Azure Resource Manager.
  • Usare le identità gestite:

    • È consigliabile usare le identità gestite anziché gestire direttamente i segreti.
    • Le identità gestite consentono alle applicazioni e ai servizi di autenticare la sicurezza con i servizi di Azure senza richiedere credenziali esplicite.
    • È possibile usare le identità gestite per accedere ad altri servizi di Azure.
  • Attività dell'interfaccia della riga di comando di Azure:

    • Se si usa l'attività dell'interfaccia della riga di comando di Azure, nella pipeline è consigliabile usare l'impostazione addSpnToEnvironment per accedere ai dettagli dell'entità servizio nello script senza passare in modo esplicito i segreti.

Per altre informazioni, vedere Usare entità servizio e identità gestite

Usare le variabili segrete

Non archiviare mai i valori sensibili come testo non crittografato in un file di azure Pipelines .yml .

Le variabili segrete possono essere usate per informazioni private come password, ID e altri dati di identificazione che non si desidera esporre in una pipeline. È consigliabile impostare le variabili segrete con Azure Key Vault. È anche possibile impostare variabili segrete nell'interfaccia utente o in un gruppo di variabili. Non è consigliabile usare un comando di registrazione per impostare una variabile privata. Quando si imposta un segreto con un comando di registrazione, chiunque possa accedere alla pipeline può anche visualizzare il segreto.

Le variabili segrete vengono crittografate e possono essere usate nelle pipeline senza esporre i relativi valori. Anche se i valori non sono esposti, non eseguono mai l'eco dei segreti come output e non passano segreti nella riga di comando. È invece consigliabile eseguire il mapping dei segreti alle variabili di ambiente.

Quando si crea un segreto, seguire le linee guida per la denominazione delle variabili e assicurarsi che il nome del segreto non divulghi informazioni riservate.

Limitare l'accesso alle variabili segrete

Per limitare l'accesso ai segreti in Azure DevOps, seguire queste procedure consigliate:

  • Archiviare i segreti in Azure Key Vault. Con Azure Key Vault è quindi possibile usare il modello di controllo degli accessi in base al ruolo di Azure per limitare l'accesso a un segreto o a un gruppo di segreti.
  • Impostare le variabili segrete nell'interfaccia utente per una pipeline. Le variabili segrete impostate nell'interfaccia utente delle impostazioni della pipeline per una pipeline hanno come ambito la pipeline in cui sono impostate. È quindi possibile avere segreti visibili solo agli utenti con accesso a tale pipeline.
  • Impostare i segreti in un gruppo di variabili. I gruppi di variabili seguono il modello di sicurezza della libreria. È possibile controllare chi può definire nuovi elementi in una raccolta e chi può usare un elemento esistente.

Non scrivere segreti nei log

Azure Pipelines tenta di eseguire lo scrub dei segreti dai log laddove possibile, ma non è infallibile. Evitate di ripetere i segreti nella console, di usarli nei parametri della riga di comando o di registrarli nei file. Prestare attenzione quando si usano i comandi dell'interfaccia della riga di comando di Azure che generano informazioni riservate. None output formatUsare e se è necessario recuperare un segreto da una chiamata all'interfaccia della riga di comando di Azure, Use none output format and retrieve security information to a secret variable.

Non usare dati strutturati come segreti

Evitare di usare formati di dati strutturati come JSON, XML o YAML, per incapsulare i valori dei segreti, inclusi i caratteri di controllo, ad esempio ritorno a capo, \re avanzamento riga.\n Creare invece singoli segreti per ogni valore sensibile. Questo approccio garantisce una migliore accuratezza dell'azione e riduce al minimo il rischio di esporre i dati sensibili inavvertitamente.

Controllare come vengono gestiti i segreti

Per controllare come vengono usati i segreti in Azure Pipelines, seguire queste procedure consigliate:

  • Esaminare il codice sorgente: esaminare il codice sorgente del repository che ospita la pipeline. Per garantire che i segreti vengano gestiti correttamente, controllare le attività usate nella pipeline. Ad esempio, verificare che i segreti non vengano inavvertitamente inviati a host indesiderati o stampati in modo esplicito nell'output del log.
  • Esaminare i log di esecuzione: dopo il test di input validi e non validi, visualizzare i log di esecuzione per la pipeline. Assicurarsi che i segreti siano correttamente elaborati e non esposti. In alcuni casi, gli errori nei comandi o negli strumenti potrebbero inavvertitamente perdere segreti nei log degli errori. Anche se Azure Pipelines tenta di eseguire lo scrub dei segreti dai log, la revisione manuale è ancora essenziale.

Controllare e ruotare i segreti

Per controllare e ruotare i segreti, seguire queste procedure consigliate:

  • Esaminare i segreti registrati: valutare periodicamente i segreti registrati nelle pipeline. Verificare che siano ancora necessari e rimuovere eventuali elementi non più necessari, che consentono di ridurre i rischi di sicurezza e i rischi potenziali per la sicurezza.
  • Ruotare i segreti: ruotare regolarmente i segreti per ridurre al minimo l'intervallo di tempo durante il quale potrebbe essere sfruttato un segreto compromesso. Modificando periodicamente i segreti, si migliora la sicurezza.
  • Scegliere il metodo di autenticazione corretto

Usare i modelli YAML

Anziché includere script inline con parametri segreti direttamente nella pipeline YAML, usare i modelli. Questo approccio migliora la sicurezza astraendo le informazioni riservate dalla pipeline principale.

Per implementare questo approccio, creare un file YAML separato per lo script e quindi archiviare lo script in un repository separato e sicuro. È quindi possibile fare riferimento al modello e passare una variabile privata nel file YAML come parametro. La variabile sicura deve provenire da Azure Key Vault, da un gruppo di variabili o dall'interfaccia utente della pipeline. Per altre informazioni sull'uso dei modelli, vedere informazioni di riferimento sull'utilizzo dei modelli.

Limitare i segreti con i criteri dei rami e le autorizzazioni dei gruppi di variabili

Per assicurarsi che i segreti siano associati al main ramo e non siano accessibili a rami casuali, è possibile usare una combinazione di autorizzazioni di gruppo di variabili, inserimento di processi condizionali e criteri di ramo.

Con i criteri di ramo, è possibile applicare criteri di convalida della compilazione che consentono solo compilazioni dal ramo principale. È quindi possibile usare le autorizzazioni del gruppo di variabili per assicurarsi che solo le pipeline autorizzate abbiano accesso ai segreti archiviati nel gruppo di variabili. Infine, è possibile usare una condizione nella pipeline per assicurarsi che il gruppo di variabili possa essere fatto riferimento solo da un push al main ramo.

jobs:
- job: ExampleJob
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: echo "This runs only for the main branch"
    displayName: 'Conditional Step'
  variables:
  - group: your-variable-group-name

Passaggi successivi