Condividi tramite


Gestione avanzata della sicurezza

Con questo aggiornamento è ora possibile abilitare o disabilitare Sicurezza avanzata per l'intero progetto o l'organizzazione. È anche possibile abilitare automaticamente La sicurezza avanzata per tutti i repository o i progetti appena creati.

In Azure Pipelines è stato aggiunto un controllo centralizzato per migliorare la sicurezza delle richieste pull compilate dai repository GitHub forked.

Per altre informazioni su queste funzionalità, vedere le note sulla versione.

Generale

Azure Pipelines

Azure Repos

Azure Artifacts

Generale

Abilitazione a livello di progetto e organizzazione per la sicurezza avanzata

È ora possibile abilitare o disabilitare Sicurezza avanzata per l'intero progetto o l'organizzazione. In combinazione con la nuova aggiunta del conteggio del commiter visualizzato prima dell'abilitazione, selezionare "Abilita tutto" a livello di progetto o organizzazione fornirà una stima del numero di nuovi commit attivi fatturati. È anche possibile scegliere di abilitare automaticamente La sicurezza avanzata per tutti i repository o i progetti appena creati nel rispettivo progetto o organizzazione. Tutti i repository abilitati tramite questa impostazione avranno l'analisi del repository segreto e la protezione push attiva.

Abilitazione a livello di progetto:

Screenshot dell'abilitazione a livello di progetto.

Abilitazione a livello di organizzazione:

Screenshot dell'abilitazione a livello di organizzazione.

Conteggio del commiter stimato durante l'abilitazione di Sicurezza avanzata

Come parte dell'esperienza di onboarding di Sicurezza avanzata , è ora possibile visualizzare una stima del numero di commit attivi che potrebbero essere stati aggiunti come risultato dell'abilitazione di Sicurezza avanzata per un determinato repository, progetto o organizzazione. Questo conteggio è un'approssimazione e potrebbe verificarsi una leggera discrepanza tra la stima fornita e ciò che viene segnalato per la fatturazione dopo l'abilitazione. Questa stima può essere ottenuta anche tramite API con documentazione aggiuntiva che illustra presto questo processo.

Screenshot dell'abilitazione della sicurezza avanzata.

Azure Pipelines

Riprovare una fase quando le approvazioni e verifica il timeout

Quando le approvazioni e controlla il timeout, la fase a cui appartiene viene ignorata. Le fasi che hanno una dipendenza dalla fase ignorata vengono ignorate anche.

A questo punto è possibile riprovare una fase quando le approvazioni e controlla il timeout. In precedenza, questo è stato possibile solo quando un timeout di approvazione.

Screenshot della ripetizione dei tentativi di fase.

Ruolo amministratore per tutti gli ambienti

Gli ambienti nelle pipeline YAML rappresentano una risorsa di calcolo a cui si distribuisce l'applicazione, ad esempio un cluster del servizio Azure Kubernetes o un set di macchine virtuali. Forniscono controlli di sicurezza e tracciabilità per le distribuzioni.

La gestione degli ambienti può essere molto complessa. Questo perché, quando viene creato un ambiente, la persona che lo crea automaticamente diventa l'unico amministratore. Ad esempio, se si desidera gestire le approvazioni e i controlli di tutti gli ambienti in modo centralizzato, è necessario chiedere a ogni amministratore dell'ambiente di aggiungere un utente o un gruppo specifico come amministratore e quindi usare l'API REST per configurare i controlli. Questo approccio è noioso, soggetto a errori e non ridimensiona quando vengono aggiunti nuovi ambienti.

Con questo sprint è stato aggiunto un ruolo amministratore a livello di hub degli ambienti. In questo modo, gli ambienti si avvicinano alla parità con le connessioni del servizio o i pool di agenti. Per assegnare il ruolo amministratore a un utente o a un gruppo, è necessario essere già un amministratore dell'hub ambienti o un proprietario dell'organizzazione.

Screenshot del ruolo amministratore.

Un utente con questo ruolo amministratore può amministrare autorizzazioni, gestire, visualizzare e usare qualsiasi ambiente. Ciò include l'apertura di ambienti a tutte le pipeline.

Quando si concede un ruolo amministratore utente a livello di ambiente-hub, diventano amministratori per tutti gli ambienti esistenti e per tutti gli ambienti futuri.

Controllo centralizzato per la compilazione di richieste da repository GitHub forked

Se si creano repository pubblici da GitHub, è necessario prendere in considerazione la posizione sulle build fork. I fork sono particolarmente pericolosi perché provengono dall'esterno dell'organizzazione.

È possibile migliorare la sicurezza delle pipeline che compilano repository pubblici di GitHub esaminando i consigli su come compilare repository GitHub e protezione repository. Purtroppo, la gestione di numerose pipeline e la loro conformità alle procedure consigliate possono richiedere un notevole sforzo.

Per migliorare la sicurezza delle pipeline, è stato aggiunto un controllo a livello di organizzazione per definire il modo in cui vengono compilate le pipeline da repository GitHub forked. La nuova impostazione è denominata Limit building pull request from forked GitHub repository e funziona a livello di organizzazione e progetto.

L'impostazione a livello di organizzazione limita i progetti di impostazioni e l'impostazione a livello di progetto limita le pipeline delle impostazioni.

Si esaminerà il funzionamento dell'interruttore a livello di organizzazione. Il nuovo controllo è disattivato per impostazione predefinita, quindi nessuna impostazione viene applicata universalmente.

Screenshot dell'interruttore a livello di organizzazione.

Quando si attiva l'interruttore, è possibile scegliere di disabilitare la compilazione di richieste da repository GitHub forked. Ciò significa che non verrà eseguita alcuna pipeline quando tale richiesta viene creata.

Screenshot della visualizzazione dell'attivazione attiva.

Quando si sceglie l'opzione Pull delle richieste pull in modo sicuro dai repository forked , tutte le pipeline, a livello di organizzazione, non possono rendere disponibili i segreti per le compilazioni di richieste da repository forked, non possono rendere queste compilazioni uguali alle compilazioni normali e devono essere attivate da un commento pr. I progetti possono comunque decidere di non consentire alle pipeline di compilare tali richieste.

Screenshot della richiesta richiesta di compilazione sicura.

Quando si sceglie l'opzione Personalizza , è possibile definire come limitare le impostazioni della pipeline. Ad esempio, è possibile assicurarsi che tutte le pipeline richiedano un commento per creare una richiesta di richiesta da un repository GitHub forked, quando la richiesta di richiesta appartiene ai membri non del team e ai non collaboratori. Tuttavia, è possibile scegliere di consentire loro di rendere disponibili i segreti per tali compilazioni. I progetti possono decidere di non consentire alle pipeline di compilare tali richieste o di compilarli in modo sicuro o di avere impostazioni ancora più restrittive specificate a livello di organizzazione.

Screenshot di Personalizza.

Azure Repos

Nuovo "Criterio di ramo" che impedisce agli utenti di approvare le proprie modifiche

Per migliorare il controllo sulle modifiche approvate dall'utente e soddisfare i requisiti normativi/conformità più rigorosi, è possibile impedire all'utente di approvare le proprie modifiche a meno che non sia consentito in modo esplicito.

L'utente con la possibilità di gestire i criteri di ramo può ora passare all'opzione appena aggiunta "Richiedi almeno un'approvazione per ogni iterazione" nella sezione "Quando vengono push nuove modifiche". Quando questa opzione è selezionata, è necessario almeno un voto di approvazione per l'ultima modifica del ramo di origine. L'approvazione dell'utente non viene conteggiata rispetto a qualsiasi iterazione precedente non approvata eseguita da tale utente. Di conseguenza, è necessaria l'approvazione aggiuntiva per l'ultima iterazione da parte di un altro utente.

L'immagine seguente mostra la richiesta pull creata dall'utente A e 4 commit aggiuntivi (iterazioni) effettuate a tale richiesta pull dagli utenti B, C, A e C. Dopo aver eseguito la seconda iterazione (commit eseguito dall'utente B), l'utente C ha approvato tale operazione. In quel momento, l'approvazione implicita del primo commit dell'utente A (quando è stata creata la richiesta pull) e il criterio appena introdotto avrà esito positivo. Dopo la quinta iterazione (ultimo commit dell'utente C), l'approvazione è stata eseguita dall'utente A. Questa approvazione implicita per il commit precedente eseguita dall'utente C, ma non implicava l'approvazione del secondo commit eseguito dall'utente A nella quarta iterazione. Per apportare al successo il criterio appena introdotto, l'iterazione non approvata deve essere approvata dall'utente B, C o da qualsiasi altro utente che non ha apportato alcuna modifica alla richiesta pull.

Immagine di gestione delle autorizzazioni.

Azure Artifacts

Introduzione al supporto degli artefatti di Azure per Le cassette di carico (anteprima pubblica)

Siamo lieti di annunciare che Gli artefatti di Azure offrono ora supporto nativo per le cassette di carico. Questo supporto include la parità delle funzionalità rispetto ai protocolli esistenti, oltre a crates.io disponibile come origine upstream. Gli sviluppatori e i team di Rust possono ora usare, pubblicare, gestire e condividere facilmente le proprie cassette di carico, tutto mentre si usa l'infrastruttura affidabile di Azure e si trova nell'ambiente Azure DevOps familiare.

Non è necessaria alcuna iscrizione per l'anteprima; È possibile iniziare passando al progetto Azure DevOps, selezionando Artefatti e seguendo le istruzioni per connettere il progetto Rust al feed di Elementi di Azure.

Passaggi successivi

Nota

Queste funzionalità verranno implementate nei prossimi due-tre settimane.

Passare ad Azure DevOps e guardare.

Come fornire commenti e suggerimenti

Ci piacerebbe sentire quello che pensi a queste funzionalità. Usare il menu della Guida per segnalare un problema o fornire un suggerimento.

Screenshot Creare un suggerimento.

È anche possibile ottenere consigli e domande risposte dalla community in Stack Overflow.

Grazie,

Silviu Andrica