Condividi tramite


Nuovi criteri per i token di accesso personali

In questo sprint sono stati aggiunti nuovi criteri per limitare l'ambito e la durata dei token di accesso personali. Inoltre, è stata aggiornata l'estensione Della shell di Windows Team Foundation Version Control (TFVC) per supportare Visual Studio 2019.

Per informazioni dettagliate, vedere le descrizioni delle funzionalità seguenti.

General

Azure Pipelines

Azure Repos

General

Limitare e controllare l'ambito e la durata del token di accesso personale tramite le politiche del tenant di Azure AD

I token di accesso personale semplificano l'autenticazione con Azure DevOps per l'integrazione con gli strumenti e i servizi. Tuttavia, i token persi potrebbero compromettere l'account e i dati di Azure DevOps, mettendo a rischio le applicazioni e i servizi.

Abbiamo ricevuto feedback sul fatto che gli amministratori non hanno gli strumenti necessari per limitare la superficie di minaccia rappresentata dai token di accesso personali trapelati. In base a questi commenti e suggerimenti, è stato aggiunto un nuovo set di criteri che possono essere usati per limitare l'ambito e la durata dei token di accesso personali di Azure DevOps dell'organizzazione. Ecco come funzionano:

Gli utenti assegnati al ruolo di amministratore di Azure DevOps in Azure Active Directory possono passare alla scheda Azure Active Directory nelle impostazioni dell'organizzazione di qualsiasi organizzazione di Azure DevOps collegata ad Azure AD.

Controlli immagini PAT

In questo caso, gli amministratori possono:

  1. limitare la creazione di token di accesso personale globale (token che funzionano per tutte le organizzazioni di Azure DevOps accessibili dall'utente)
  2. limitare la creazione di token di accesso personali con ambito completo
  3. definire una durata massima per i nuovi token di accesso personali

Questi criteri verranno applicati a tutte le nuove reti PAT create dagli utenti per le organizzazioni di Azure DevOps collegate al tenant di Azure AD. Ognuno dei criteri ha un elenco di elementi consentiti per utenti e gruppi che devono essere esentati dai criteri. L'elenco di utenti e gruppi nell'elenco Consenti non avrà accesso per gestire la configurazione dei criteri.

Questi criteri si applicano solo ai nuovi tipi di infrastruttura e non influiscono sui PT esistenti già creati e in uso. Dopo l'abilitazione dei criteri, tuttavia, tutti i PT esistenti, ora non conformi devono essere aggiornati in modo che siano entro le restrizioni prima di poter essere rinnovati.

Supporto dei criteri di accesso condizionale per il traffico IPv6

È ora in corso l'estensione del supporto dei criteri di accesso condizionale per includere i criteri di isolamento IPv6. Come si può notare, gli utenti accedono sempre più alle risorse di Azure DevOps nei dispositivi dagli indirizzi IPv6, è necessario assicurarsi che i team siano dotati di concedere e rimuovere l'accesso da qualsiasi indirizzo IP, inclusi quelli provenienti dal traffico IPv6.

Azure Pipelines

Conservare le pipeline che vengono impiegate in altre pipeline

Le versioni classiche hanno la possibilità di conservare automaticamente le compilazioni usate. Questo è stato uno dei gap tra le versioni classiche e le pipeline YAML e ha impedito ad alcuni utenti di passare a YAML. Con questa versione, abbiamo risolto questo divario.

È ora possibile creare una pipeline YAML a più fasi per rappresentare la versione e usare un'altra pipeline YAML come risorsa. In questo caso, Azure Pipelines manterrà automaticamente la pipeline di risorse purché venga mantenuta la pipeline di versione. Quando la pipeline di versione viene eliminata, il contratto di locazione nella pipeline di risorse viene rilasciato e vengono seguiti i criteri di conservazione relativi alla pipeline di risorse.

Modifiche alla creazione automatica di ambienti

Quando si crea una pipeline YAML e si fa riferimento a un ambiente che non esiste, Azure Pipelines crea automaticamente l'ambiente. Questa creazione automatica può verificarsi nel contesto utente o nel contesto di sistema. Nei flussi seguenti Azure Pipelines conosce l'utente che esegue l'operazione:

  • Usi la creazione guidata della pipeline YAML nell'interfaccia web di Azure Pipelines e ti riferisci a un ambiente che non è ancora stato creato.
  • Aggiornare il file YAML usando l'editor Web di Azure Pipelines e salvare la pipeline dopo aver aggiunto un riferimento a un ambiente che non esiste.

In ognuno dei casi precedenti, Azure Pipelines ha una conoscenza chiara dell'utente che esegue l'operazione. Di conseguenza, crea l'ambiente e aggiunge l'utente al ruolo di amministratore per l'ambiente. Questo utente dispone di tutte le autorizzazioni per gestire l'ambiente e/o per includere altri utenti in vari ruoli per la gestione dell'ambiente.

Nei flussi seguenti Azure Pipelines non dispone di informazioni sull'utente che crea l'ambiente: si aggiorna il file YAML usando un altro editor di codice esterno, si aggiunge un riferimento a un ambiente che non esiste e quindi si attiva una pipeline di integrazione manuale o continua. In questo caso, Azure Pipelines non conosce l'utente. In precedenza, questo caso è stato gestito aggiungendo tutti i collaboratori del progetto al ruolo di amministratore dell'ambiente. Qualsiasi membro del progetto potrebbe quindi modificare queste autorizzazioni e impedire ad altri utenti di accedere all'ambiente.

Sono stati ricevuti commenti e suggerimenti sulla concessione delle autorizzazioni di amministratore per un ambiente a tutti i membri di un progetto. Durante l'ascolto dei commenti e suggerimenti, abbiamo sentito che non dovremmo creare automaticamente un ambiente se non è chiaro a chi l'utente che esegue l'operazione. Con questa versione sono state apportate modifiche alla modalità di creazione automatica degli ambienti:

  • In futuro, le esecuzioni della pipeline non creeranno automaticamente un ambiente se non esiste e se il contesto utente non è noto. In questi casi, la pipeline si interromperà con un errore di ambiente non trovato. È necessario creare in precedenza gli ambienti con la sicurezza corretta e verificare la configurazione prima di usarla in una pipeline.
  • Le pipeline con contesto utente noto continueranno a creare automaticamente gli ambienti esattamente come in passato.
  • Infine, si noti che la funzionalità per creare automaticamente un ambiente è stata aggiunta solo per semplificare il processo di introduzione ad Azure Pipelines. È stato progettato per gli scenari di test e non per gli scenari di produzione. È consigliabile creare sempre ambienti di produzione con le autorizzazioni e i controlli corretti e usarli nelle pipeline.

Rimuovere la finestra di dialogo Insights dalla pipeline di compilazione

In base al tuo feedback, il box di dialogo di approfondimenti sulle attività/pipeline visualizzato durante la navigazione della Pipeline di Build è stato rimosso per migliorare il flusso di lavoro. L'analisi della pipeline è ancora disponibile in modo da avere le informazioni necessarie.

Azure Repos

Aggiornamenti all'estensione della shell di Windows per il controllo della versione di Team Foundation (TFVC) per Visual Studio 2019

La versione precedente dell'estensione Della shell di Windows TFVC funzionava solo nei computer che avevano installato Visual Studio 2017.

È stata rilasciata una nuova versione di questo strumento compatibile con Visual Studio 2019. L'estensione fornisce l'integrazione con Esplora file e le finestre di dialogo comuni per i file. Con questa integrazione, è possibile eseguire molte operazioni di controllo del codice sorgente senza dover eseguire Visual Studio o uno strumento da riga di comando di Team Foundation.

Passaggi successivi

Annotazioni

Queste funzionalità verranno implementate nelle prossime due o tre settimane.

Passare ad Azure DevOps e dare un'occhiata.

Come fornire commenti e suggerimenti

Ci piacerebbe sentire ciò che pensi a queste funzionalità. Usa il menu di aiuto per segnalare un problema o fornire un suggerimento.

Inviare un suggerimento

È anche possibile ottenere consigli e risposte alle domande della community su Stack Overflow.

Grazie,

Vijay Machiraju