Modificare la visibilità del progetto in pubblico o privato

Servizi di Azure DevOps

Informazioni su come modificare la visibilità del progetto Azure DevOps tra pubblico e privato e comprendere le implicazioni di sicurezza e accesso di ogni impostazione di visibilità.

Quali modifiche vengono apportate quando si rende pubblico un progetto

Rendere pubblico un progetto influisce su autorizzazioni, livelli di accesso e funzionalità disponibili.

Modifiche alla sicurezza e alle autorizzazioni

Quando si passa la visibilità del progetto da privata a pubblica, si verificano le modifiche seguenti:

• Le autorizzazioni di negazione vengono ignorate: il sistema non applica alcuna autorizzazione impostata in modo esplicito su "Nega" per gli utenti pubblici.
• Accesso minimo concesso: i non membri ricevono automaticamente l'accesso di base alla lettura del contenuto pubblico.
• Ambito pipeline: Per migliorare la sicurezza, le pipeline impostate su ambito raccolta di progetti vengono eseguite automaticamente con ambito progetto.

Differenze a livello di accesso

Disponibilità delle funzionalità per i membri non membri

La tabella seguente illustra le funzionalità disponibili per gli utenti che non sono membri del progetto:

Prerequisiti

Prima di modificare la visibilità del progetto, assicurarsi di soddisfare questi requisiti:

Elenco di controllo per la sicurezza premigrazione

L'esposizione dell'organizzazione e dell'identità

• [ ] Informazioni sui membri: tutti i nomi e gli indirizzi di posta elettronica dei membri dell'organizzazione diventano visibili
• [ ] Impostazioni dell'organizzazione: visualizzazione di sola lettura di tutte le impostazioni dell'organizzazione e del progetto esposte
• [ ] Elaborare i metadati: tutti i valori di menu a tendina di tutti i progetti dell'organizzazione diventano visibili
• [ ] Cronologia build: nomi e indirizzi di posta elettronica dai trigger di compilazione e commit Git esposti

Considerazioni tra progetti

• [ ] Elementi collegati: verificare la presenza di collegamenti a progetti privati che potrebbero esporre informazioni riservate
• [ ] Risorse condivise: esaminare le risorse a livello di organizzazione a cui si accede dal progetto

Revisione della sicurezza del contenuto

Elementi di lavoro e strumenti Agile

• [ ] Elementi di lavoro cronologici: esaminare tutti gli elementi di lavoro, inclusi quelli chiusi, per informazioni riservate.
• [ ] Sicurezza del percorso dell'area: verificare che nessun percorso di area disponga di restrizioni di sicurezza particolari (i permessi negati vengono ignorati nei progetti pubblici).
• [ ] Discussioni e commenti: controllare tutte le discussioni degli elementi di lavoro per contenuti sensibili o inappropriati.

Repository di codice sorgente

• [ ] Cronologia commit: esaminare l'intera cronologia Git per le credenziali, le vulnerabilità di sicurezza o il codice proprietario.
• [ ] Messaggi di commit: Verificare tutti i messaggi di commit per informazioni riservate o contenuto inappropriato.
• [ ] Contenuto del file: assicurarsi che nessun file contenga credenziali, chiavi API o dati riservati.

Pipeline di compilazione e rilascio

• [ ] Definizioni di pipeline: esaminare le credenziali esposte, gli URL interni o i dettagli dell'ambiente.
• [ ] Log di compilazione: controllare i log storici di compilazione per informazioni riservate.
• [ ] Connessioni al servizio: verificare che non ci siano dipendenze da feed privati che non possano essere accessibili ai non membri.

Artefatti e pacchetti

• [ ] Contenuto del pacchetto: esaminare tutti i pacchetti nei feed con ambito progetto per i problemi di privacy.
• [ ] Impostazioni feed: comprendere che le impostazioni upstream sono disabilitate per i feed di progetti pubblici.

Estensioni e personalizzazioni

• [ ] Estensioni personalizzate: verificare che le estensioni funzionino correttamente per i membri non membri.
• [ ] Personalizzazioni dei moduli degli elementi di lavoro: testare controlli e campi personalizzati con accesso non membro.

Passaggio 1: Abilitare progetti pubblici per l'organizzazione

1. Accedi alla tua organizzazione (https://dev.azure.com/{yourorganization}).

2. Seleziona Impostazioni organizzazione.

   

3. Selezionare Politiche.

4. In Criteri di sicurezza attivare Consenti progetti pubblici.

   

Passaggio 2: Modificare la visibilità del progetto

1. Passare al progetto (https://dev.azure.com/{yourorganization}/{yourproject}).

2. Selezionare Impostazioni progetto.

3. Selezionare Panoramica.

4. Nel menu a discesa Visibilità scegliere Pubblico o Privato.

5. Seleziona Salva.

   

Gestire i collaboratori nei progetti pubblici

Aggiungere membri del progetto

Aggiungere collaboratori a progetti pubblici allo stesso modo dei progetti privati:

1. Passare aAutorizzazioni> progetto.
2. Selezionare Aggiungi per invitare gli utenti.
3. Assegnare i livelli di accesso appropriati (Stakeholder, Base o Base + Piani di Test).

Per altre informazioni, vedere Aggiungere utenti all'organizzazione.

Considerazioni sull'utente esterno

Quando si invitano utenti esterni a progetti pubblici:

• Ottengono l'accesso a tutti i contenuti pubblici dell'organizzazione.
• È consigliabile creare organizzazioni separate per progetti pubblici se si dispone di contenuti sensibili altrove.

Approcci alternativi per il contenuto sensibile

Opzione 1: Organizzazione separata per i progetti pubblici

Se l'organizzazione corrente contiene materiale sensibile:

1. Creare una nuova organizzazione specifica per i progetti pubblici.
2. Eseguire la migrazione solo di contenuto non sensibile alla nuova organizzazione.
3. Mantenere i progetti sensibili nell'organizzazione privata originale.

Opzione 2: Migrazione selettiva del contenuto

Spostare elementi di lavoro sensibili

• Usare la funzionalità Sposta elementi di lavoro per trasferire elementi sensibili a un progetto privato.
• I collegamenti tra progetti continuano a funzionare per i membri, ma rimangono nascosti dai membri non membri.

Migrazione della descrizione del repository Git

Per i repository con cronologia problematica, eseguire la migrazione solo dello stato corrente:

# Clone the existing repository
git clone <original_clone_URL>
cd <repository_name>

# Ensure you're on the desired branch
git checkout main

# Remove Git history
rm -rf .git  # On Windows: rmdir /s .git

# Initialize new repository
git init

# Connect to new repository in public project
git remote add origin <new_public_repo_URL>

# Push current state as initial commit
git add .
git commit -m "Initial public release"
git push --set-upstream origin main

Limitazioni per i membri non membri

I membri non membri di progetti pubblici non possono eseguire le azioni seguenti:

• Modificare o creare qualsiasi contenuto (file, elementi di lavoro, pipeline).
• Visualizzare gli indirizzi di posta elettronica o le informazioni di contatto dei membri del progetto.
• Accedere alle impostazioni amministrative o alle pagine di configurazione.
• Usare le funzionalità di ricerca avanzate nell'organizzazione.
• Spostarsi tra più progetti pubblici nella stessa organizzazione.
• Aggiungi ai preferiti o segui gli artefatti.

Risolvere i problemi di accesso al progetto pubblico

Problemi comuni

Problema: i membri non possono accedere al progetto dopo averlo reso pubblico

• Soluzione: verificare che il criterio "Consenti progetti pubblici" dell'organizzazione sia abilitato

Problema: alcuni contenuti vengono ancora visualizzati con restrizioni

• Soluzione: verificare la presenza di autorizzazioni di rifiuto che potrebbero influire su aree specifiche

Problema: gli utenti esterni non possono contribuire

• Soluzione: assicurarsi che vengano aggiunti come membri del progetto con livelli di accesso appropriati

Passo successivo

Contenuti correlati

• Informazioni sui progetti pubblici
• Eliminare un progetto
• Aggiungere utenti esterni
• Aggiungere un URL dell'informativa sulla privacy