Impostazioni del sito Web e sicurezza per Azure DevOps locale

TFS 2017 | TFS 2015 | TFS 2013

Sfondo

Per molte versioni, le impostazioni predefinite del sito Web per Azure DevOps Server, denominate in precedenza Team Foundation Server (TFS), sono state:

  • Un'unica associazione HTTP per il sito Web Azure DevOps Server sulla porta 8080, senza nome host o indirizzo IP specificato.
  • URL pubblico (indicato in precedenza come URL di notifica) del modulo http://machine-name:8080/tfs.

Il vantaggio principale di queste impostazioni è che sono molto semplici da configurare e pratici per gli utenti finali nella maggior parte degli scenari. In particolare:

  • L'uso di HTTP anziché HTTPS evita la necessità di ottenere e installare i certificati.
  • L'uso di 8080 anziché 80 evita potenziali conflitti con altri siti nello stesso computer.
  • L'uso di "tfs" come directory virtuale per il sito semplifica l'hosting di Azure DevOps Server e altri siti Web nella stessa porta nello stesso server.
  • Usando il nome del computer, anziché il nome di dominio completo (FQDN), nell'URL pubblico viene salvato un sacco di digitazione.
  • L'uscita del nome host nell'associazione non specificata consente la flessibilità nella connessione: nome computer, FQDN o indirizzo IP funzioneranno tutti quando gli utenti tentano di connettersi ai propri server.

Queste impostazioni non sono tuttavia sicure per impostazione predefinita. In particolare, non usando un'associazione HTTPS, la comunicazione verso e da Azure DevOps Server non viene crittografata in transito a meno che non vengano usate altre soluzioni come IPSec. Sono quindi potenzialmente vulnerabili al monitoraggio degli attori malintenzionati o anche alla modifica del contenuto della comunicazione. Questi problemi sono ridotti in qualche misura quando Azure DevOps Server viene distribuito in una intranet dietro un firewall aziendale, poiché la maggior parte delle istanze di Azure DevOps Server sono. Tuttavia, anche in questi scenari, i dati inviati a e da Azure DevOps Server includono codice sorgente, dati degli elementi di lavoro e altre informazioni che possono spesso trarre vantaggio da una maggiore sicurezza.

Inoltre, in TFS 2017 esistono nuovi scenari di autenticazione (autenticazione dell'account del servizio build/release agent, token di accesso personale) che inviano token di connessione tramite la rete. Se questi token vengono ottenuti da utenti malintenzionati, possono essere usati per rappresentare gli utenti a cui appartengono.

Dato tutto questo, abbiamo deciso che il tempo era arrivato a un più forte sostenitore dell'uso di associazioni HTTPS nelle distribuzioni di Azure DevOps Server.

Impostazione dei gruppi

TFS 2017 presenta le opzioni di configurazione delle impostazioni del sito Web in tutti gli scenari di configurazione del server. Vengono forniti diversi gruppi di impostazioni, che raggruppano combinazioni di associazioni del sito, directory virtuali e URL pubblici che è consigliabile e che si ritiene che vengano usati più comunemente. Per gli scenari in cui nessuno di questi gruppi di impostazioni è appropriato, le impostazioni possono essere completamente personalizzate usando la finestra di dialogo Modifica sito Impostazioni.

Default setting group

Il gruppo Impostazione predefinita include le stesse impostazioni usate nelle versioni precedenti di Azure DevOps Server. Per tutti i motivi elencati in precedenza, queste impostazioni sono ancora le impostazioni predefinite per le nuove distribuzioni di Azure DevOps Server. Per le distribuzioni esistenti, si tenterà di mantenere le impostazioni esistenti, che spesso comportano l'selezione del gruppo Impostazione predefinita.

HTTPS and HTTP with redirect setting group.

Il gruppo di impostazione HTTPS e HTTP (con reindirizzamento) esegue il provisioning di due associazioni:

  • Un'associazione HTTPS sulla porta 443, con il nome di dominio completo (FQDN) del computer come nome host.
  • Un'associazione HTTP sulla porta 80, di nuovo con il nome di dominio completo del computer come nome host.

L'associazione HTTP sulla porta 80 viene aggiunta solo come praticità per gli utenti finali: un reindirizzamento è configurato in modo che tutto il traffico finisca usando l'associazione HTTPS sulla porta 443. L'URL pubblico per questo gruppo di impostazioni è del modulo https://fully-qualified-domain-name. Per impostazione predefinita, questo gruppo di impostazioni eseguirà il provisioning di nuovi certificati autofirmato e li userà per l'associazione HTTPS. In genere non è consigliabile usare certificati autofirmato per le distribuzioni TFS di produzione. Per altre informazioni su quando è appropriato usare certificati autofirmati e quali altre opzioni sono disponibili, vedere Opzioni certificato di seguito.

Il gruppo di impostazione HTTPS esegue il provisioning di un'unica associazione HTTPS sulla porta 443, con il nome di dominio completo del computer come nome host. Anche in questo caso, l'URL pubblico per questo gruppo di impostazioni è del modulo https://fully-qualified-domain-namee i certificati autofirmati verranno con provisioning per impostazione predefinita.

Il gruppo di impostazione SOLO HTTP esegue il provisioning di un'unica associazione HTTP sulla porta 80 senza alcun nome host specificato. L'URL pubblico per questo gruppo di impostazioni è del modulo http://machine-name.

Quando si usa il gruppo di impostazione HTTPS e HTTP (con reindirizzamento), l'uso di un URL pubblico HTTP non è consigliato. La maggior parte dei browser moderni considererà il contenuto HTTP e HTTPS misto non sicuro per impostazione predefinita e potrebbe visualizzare pagine vuote. Anche se in genere è possibile eseguire l'override delle impostazioni predefinite del browser e consentire il contenuto non sicuro, ciò comporterà un'esperienza simile all'esplorazione di un sito con un certificato SSL scaduto.

Opzioni certificato

La distribuzione di siti Web con associazioni HTTPS e crittografia SSL/TLS è strettamente correlata all'argomento più ampio dell'infrastruttura di chiave pubblica (PKI), che è un argomento ricco e interessante per cui esiste già una vasta gamma di documentazione. Non si tenterà di coprire tutte le complessità, ma si concentrerà piuttosto sulle opzioni di alto livello per configurare le associazioni HTTPS per le distribuzioni di Azure DevOps Server. Molte organizzazioni hanno criteri specifici relativi alla distribuzione dei certificati, quindi il primo passaggio per decidere quale certificato usare per una distribuzione di Azure DevOps Server è spesso parlare con un gruppo di tecnologie informatiche a livello di organizzazione.

Le opzioni includono:

  • Consentire alla configurazione guidata TFS di generare certificati autofirmato da usare dalla distribuzione.
  • Ottenere un certificato da un'autorità di certificazione interna.
  • Ottenere un certificato da un'autorità di certificazione esterna.

Certificati autofirmati

I certificati autofirmati sono utili per le distribuzioni di valutazione di Azure DevOps Server, poiché sono molto facili da effettuare e usare. Sono meno appropriati per le distribuzioni di produzione di Azure DevOps Server e non è consigliabile utilizzarle per le distribuzioni Azure DevOps Server esposte a Internet pubblico. In genere, i certificati autofirmati sono soggetti agli attacchi man-in-the-middle. Causano anche problemi per gli utenti, poiché causano avvisi e errori del certificato fino a quando i certificati radice non vengono installati in ogni computer client. Ad esempio, il browser Edge mostrerà l'errore seguente.

Certificate errors in Edge.

Quando la configurazione guidata TFS genera certificati autofirmati per la distribuzione, creerà due, uno inserito nell'archivio Autorità di certificazione radice attendibili nel server e un secondo, firmato dal primo, che viene inserito nell'archivio personale nel server e usato da Azure DevOps Server. L'impostazione delle operazioni in questo modo consente di attenuare la possibilità di attacchi man-in-the-middle e consente la rotazione del certificato usato nell'associazione HTTPS senza dover distribuire un nuovo certificato a tutti i client per evitare errori di certificato come quello illustrato sopra.

Per evitare gli avvisi e gli errori del certificato, è possibile esportare il certificato radice e installarlo nei computer client. Esistono diversi modi per eseguire questa operazione, tra cui:

Autorità di certificazione interne ed esterne

Molte organizzazioni di grandi dimensioni hanno una propria infrastruttura di chiave pubblica e sono in grado di emettere certificati dalle proprie autorità di certificazione. In genere, quando si tratta del caso, i certificati radice attendibili per queste autorità saranno già distribuiti ai computer client, evitando così la necessità di distribuire certificati aggiuntivi per Azure DevOps Server. Se l'organizzazione dispone di una propria infrastruttura di chiave pubblica, questa può essere un'ottima opzione per la distribuzione di Azure DevOps Server.

Quando altre opzioni non sono appropriate o disponibili, i certificati possono essere ottenuti (in genere a un costo) da un'autorità di certificazione esterna (CA). Le istruzioni per questo processo, che inizia con la creazione di una richiesta di firma del certificato, sono disponibili nella maggior parte dei siti Web ca. Note importanti:

  • Assicurarsi che il nome comune specificato nella richiesta di certificato corrisponda al nome host desiderato nell'URL pubblico, ad esempio tfs.contoso.com.
  • Nelle proprietà del provider di servizi crittografici è consigliabile selezionare Microsoft RSA SChannel Cryptographic Provider e una lunghezza di bit pari a 2048 o successiva.

Modifica dell'URL pubblico

Si noti anche che quando si aggiorna una distribuzione di Azure DevOps Server esistente, la modifica dell'URL pubblico influisce sugli utenti finali. Anche se è ancora consigliabile convertire da HTTP a associazioni HTTPS, Visual Studio le connessioni client dovranno essere riristabilite, i segnalibri precedenti non verranno più risolti correttamente e così via. È quindi importante coordinare questo tipo di modifica con gli utenti della distribuzione Azure DevOps Server per evitare interruzioni significative.