Impostazioni e sicurezza del sito Web per Azure DevOps locale

TFS 2017 | TFS 2015 | TFS 2013

Background

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 di Azure DevOps Server sulla porta 8080, senza nome host o indirizzo IP specificato.
• URL pubblico (noto in precedenza come URL di notifica) nel formato 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 di altri siti Web sulla 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: nome computer, FQDN o indirizzo IP funzioneranno tutti quando gli utenti tentano di connettersi ai server.

Queste impostazioni non sono tuttavia sicure per impostazione predefinita. In particolare, non usando un'associazione HTTPS, le comunicazioni da e verso Azure DevOps Server non vengono crittografate 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, poiché la maggior parte delle istanze di Azure DevOps Server sono distribuite in una intranet. 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 esistono nuovi scenari di autenticazione (autenticazione dell'account di servizio degli agenti di build/rilascio, token di accesso personale) che inviano token di tipo 'bearer' in rete. Se questi token vengono ottenuti da utenti malintenzionati, possono essere usati per rappresentare gli utenti a cui appartengono.

Dato tutto questo, è stato deciso che era giunto il momento di sostenere con più forza l'uso di associazioni HTTPS nelle distribuzioni di Azure DevOps Server.

Impostazione di 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 di sito, directory virtuali e URL pubblici consigliati e che si ritiene che verranno usati più comunemente. 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 predefinito 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 la selezione del gruppo di impostazioni predefinite.

Il gruppo di impostazioni HTTPS e HTTP (con reindirizzamento) fornisce due collegamenti:

• 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 FQDN 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 configura una singola associazione HTTPS sulla porta 443, utilizzando il FQDN della macchina come nome host. Anche in questo caso, l'URL pubblico per questo gruppo di impostazioni è assegnato nel formato https://fully-qualified-domain-name, e i certificati autofirmati verranno forniti per impostazione predefinita.

Il gruppo di impostazioni HTTP Only provisiona una singola associazione HTTP sulla porta 80 senza specificare un 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 contenuti non sicuri, ciò comporterà un'esperienza simile all'esplorazione di un sito con un certificato SSL scaduto.

Opzioni di certificati

La distribuzione di siti Web con associazioni HTTPS e crittografia SSL/TLS è strettamente correlata all'argomento più ampio dell'infrastruttura a chiave pubblica (PKI), che è 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 configurare le associazioni HTTPS per le distribuzioni di Azure DevOps Server. Molte organizzazioni hanno 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 di tecnologie informatiche a livello di organizzazione.

Le opzioni includono:

• Consentire alla configurazione guidata TFS di generare certificati autofirmati per l'utilizzo nella 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, perché sono molto facili da effettuare e usare. Sono meno appropriati per le distribuzioni di produzione di Azure DevOps Server e non è consigliabile usare per le distribuzioni di Azure DevOps Server esposte alla rete Internet pubblica. In genere, i certificati autofirmati sono vulnerabili agli attacchi man-in-the-middle. Causano anche problemi per gli utenti, poiché generano avvisi ed errori del certificato, fino a quando i certificati radice non vengono installati in ogni macchina client. Ad esempio, il browser Edge mostrerà l'errore seguente.

Quando la procedura guidata di configurazione di TFS genera certificati autofirmati per la distribuzione, verranno creati due: uno che viene inserito nell'archivio Autorità di certificazione radice attendibili nel server e un secondo, firmato dal primo, che viene inserito nell'archivio Certificati personali nel server e utilizzato 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 versioni successive, 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 una 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à saranno 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. Alcune 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 del servizio di crittografia", consigliamo di selezionare il "Provider di crittografia Microsoft RSA SChannel" 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, le connessioni client di Visual Studio dovranno essere ristabilite, i vecchi segnalibri non verranno più risolti correttamente e così via. È quindi importante coordinare questo tipo di modifica con gli utenti della distribuzione di Azure DevOps Server per evitare interruzioni significative.