Impostazioni e sicurezza del sito Web 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:

• Una singola 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 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.
• L'uso del nome del computer, anziché del nome di dominio completo (FQDN), nell'URL pubblico consente di risparmiare molta digitazione.
• Lasciare il nome host nell'associazione non specificato consente la flessibilità di connessione: il nome del computer, il nome FQDN o l'indirizzo IP funzioneranno tutti quando gli utenti tentano di connettersi ai server.

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

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

Dato tutto ciò, è stato deciso che il tempo era stato più fortemente sostenuto per l'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. Sono disponibili diversi gruppi di impostazioni, che raggruppano combinazioni di associazioni di sito, directory virtuali e URL pubblici consigliati e che sono più comunemente usati. Per gli scenari in cui nessuno di questi gruppi di impostazioni è appropriato, le impostazioni possono essere completamente personalizzate tramite la finestra di dialogo Modifica impostazioni sito.

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

Il gruppo di impostazioni HTTPS e HTTP (con reindirizzamento) effettua 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 per praticità per gli utenti finali. Un reindirizzamento viene 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 impostazioni HTTPS esegue il provisioning di una singola 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 è nel formato e i certificati autofirmati verranno di cui verrà effettuato il provisioning per impostazione predefinita.Again, the Public URL for this setting group is of the form https://fully-qualified-domain-name, and self-signed certificates will be provisioned by default.

Il gruppo di impostazione Solo HTTP effettua il provisioning di una singola associazione HTTP sulla porta 80 senza specificare alcun nome host. L'URL pubblico per questo gruppo di impostazioni è del modulo http://machine-name.

Quando si usa il gruppo di impostazioni HTTPS e HTTP (con reindirizzamento), non è consigliabile usare un URL pubblico HTTP. 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 contenuto non sicuro, ciò comporterà un'esperienza simile all'esplorazione di un sito con un certificato SSL scaduto.

Opzioni del certificato

La distribuzione di siti Web tramite associazioni HTTPS e crittografia SSL/TLS è strettamente correlata all'argomento più ampio dell'infrastruttura a chiave pubblica (PKI), un argomento ricco e interessante per il quale esiste già un'ampia gamma di documentazione. In questo caso non si tenterà di coprire tutte le complessità, ma si concentrerà piuttosto sulle opzioni di alto livello per la configurazione delle associazioni HTTPS per le distribuzioni di Azure DevOps Server. Molte organizzazioni dispongono di criteri specifici per la distribuzione dei certificati, quindi il primo passaggio per decidere quale certificato usare per una distribuzione di Azure DevOps Server è spesso parlare con un gruppo informatico a livello di organizzazione.

Le opzioni includono:

• Consentire alla configurazione guidata di TFS di generare certificati autofirmato per l'uso da parte della 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 alla rete Internet pubblica. In genere, i certificati autofirmati sono soggetti ad attacchi man-in-the-middle. Causano anche problemi per gli utenti, poiché causeranno avvisi ed errori del certificato fino a quando i certificati radice non vengono installati in ogni computer client. Ad esempio, il browser Edge visualizzerà l'errore seguente.

Quando la configurazione guidata TFS genera certificati autofirmati per la distribuzione, ne creerà due, una inserita nell'archivio Autorità di certificazione radice attendibili nel server e una seconda, firmata dal primo, che viene inserita nell'archivio personale nel server e usata da Azure DevOps Server. La configurazione in questo modo consente di ridurre 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 in precedenza.

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:

• Usando lo snap-in MMC Certificati per esportare manualmente il certificato nel server e quindi importarlo in ogni client.
• Usando il cmdlet PowerShell Export-Certificate, disponibile in Windows 8/Windows Server 2012 e sistemi operativi successivi, per esportare il certificato. È quindi possibile usare Import-Certificate per importarlo in ogni client.
• Uso di Criteri di gruppo per automatizzare la distribuzione ai client.

Autorità di certificazione interne ed esterne

Molte organizzazioni di grandi dimensioni hanno la propria infrastruttura a chiave pubblica e sono in grado di rilasciare certificati dalle proprie autorità di certificazione. In genere, in questo caso, i certificati radice attendibili per queste autorità verranno già distribuiti ai computer client, evitando così la necessità di distribuire certificati aggiuntivi per Azure DevOps Server. Se l'organizzazione ha una propria infrastruttura a chiave pubblica, questa può essere un'opzione valida 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 (CA) esterna. 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 della 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 di crittografia è consigliabile selezionare Microsoft RSA SChannel Cryptographic Provider e una lunghezza di bit pari o superiore a 2048.

Modifica dell'URL pubblico

Si noti anche che quando si aggiorna una distribuzione di Azure DevOps Server esistente, la modifica dell'URL pubblico influirà sugli utenti finali. Anche se è comunque consigliabile eseguire la conversione da associazioni HTTP a HTTPS, è necessario ristabilire le connessioni client di Visual Studio, 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.