Webbplatsinställningar och säkerhet för lokal Azure DevOps

TFS 2017 | TFS 2015 | TFS 2013

Bakgrund

För många versioner har standardinställningarna för webbplatsen för Azure DevOps Server, tidigare med namnet Team Foundation Server (TFS), varit:

• En enda HTTP-bindning för Azure DevOps Server-webbplatsen på port 8080, utan angivet värdnamn eller IP-adress.
• En offentlig URL (kallades tidigare meddelande-URL) för formuläret http://machine-name:8080/tfs.

Den främsta fördelen med de här inställningarna är att de är mycket enkla att konfigurera och praktiska för slutanvändare i de flesta scenarier. I synnerhet:

• Om du använder HTTP i stället för HTTPS undviker du behovet av att hämta och installera certifikat.
• Om du använder 8080 i stället för 80 undviks potentiella konflikter med andra platser på samma dator.
• Om du använder "tfs" som den virtuella katalogen för webbplatsen blir det enklare att vara värd för Azure DevOps Server och andra webbplatser på samma port på samma server.
• Genom att använda datornamnet i stället för det fullständigt kvalificerade domännamnet (FQDN) sparar du mycket skrivtid i den offentliga webbadressen.
• Att lämna värdnamnet i bindningen ospecificerat ger flexibilitet vid anslutning – datornamn, FQDN eller IP-adress fungerar när användarna försöker ansluta till sina servrar.

De här inställningarna är dock inte säkra som standard. I synnerhet genom att inte använda en HTTPS-bindning krypteras inte kommunikation till och från Azure DevOps Server under överföring om inte andra lösningar som IPSec används. De är därför potentiellt sårbara för övervakning av skadliga aktörer eller till och med ändring av innehållet i kommunikationen. De här problemen åtgärdas i viss utsträckning när Azure DevOps Server distribueras på ett intranät bakom en företagsbrandvägg, som de allra flesta Azure DevOps Server-instanser är. Men även i dessa scenarier innehåller data som skickas till och från Azure DevOps Server källkod, arbetsobjektdata och annan information som ofta kan dra nytta av ytterligare säkerhet.

I TFS 2017 finns det dessutom nya autentiseringsscenarier (autentisering av build/release-agenttjänstkonto, personliga åtkomsttoken) som skickar bärartoken över nätverket. Om dessa token hämtas av skadliga användare kan de sedan användas för att personifiera de användare som de tillhör.

Med tanke på allt detta bestämde vi oss för att det var dags att kraftfullare förespråka användningen av HTTPS-bindningar i Azure DevOps Server-distributioner.

Inställningar för grupper

TFS 2017 presenterar konfigurationsalternativ för webbplatsinställningar i alla serverkonfigurationsscenarier. Flera inställningsgrupper tillhandahålls, som paketerar kombinationer av platsbindningar, virtuella kataloger och offentliga URL:er som vi rekommenderar och tror kommer att användas oftast. För scenarier där ingen av dessa inställningsgrupper är lämpliga kan inställningarna anpassas helt med hjälp av dialogrutan Redigera webbplatsinställningar.

Inställningsgruppen Standard innehåller samma inställningar som används i tidigare versioner av Azure DevOps Server. Av alla orsaker som anges ovan är de här inställningarna fortfarande standard för nya Azure DevOps Server-distributioner. För befintliga distributioner försöker vi bevara befintliga inställningar, vilket ofta resulterar i att standardinställningsgruppen väljs.

Inställningsgruppen HTTPS och HTTP (med omdirigering) etablerar två bindningar:

• En HTTPS-bindning på port 443, med det fullständigt kvalificerade domännamnet (FQDN) på datorn som värdnamn.
• En HTTP-bindning på port 80, återigen med FQDN för datorn som värdnamn.

HTTP-bindningen på port 80 läggs bara till som en bekvämlighet för slutanvändare – en omdirigering konfigureras så att all trafik slutar använda HTTPS-bindningen på port 443. Den offentliga URL:en för den här inställningsgruppen har formen https://fully-qualified-domain-name. Som standard etablerar den här inställningsgruppen nya självsignerade certifikat och använder dem för HTTPS-bindningen. Vi rekommenderar vanligtvis inte att du använder självsignerade certifikat för TFS-produktionsdistributioner. Se Certifikatalternativ nedan för mer information om när det är lämpligt att använda självsignerade certifikat och vilka andra alternativ som är tillgängliga.

HTTPS-inställningsgruppen etablerar endast en enda HTTPS-bindning på port 443, med FQDN för datorn som värdnamn. Återigen är den offentliga URL:en för den här inställningsgruppen av formuläret https://fully-qualified-domain-name, och självsignerade certifikat kommer att tillhandahållas som standard.

Inställningsgruppen HTTP Only etablerar en enda HTTP-bindning på port 80 utan angivet värdnamn. Den offentliga URL:en för den här inställningsgruppen är i formatet http://machine-name.

När du använder inställningsgruppen HTTPS och HTTP (med omdirigering) rekommenderas inte användning av en offentlig HTTP-URL. De flesta moderna webbläsare anser att det blandade HTTP- och HTTPS-innehållet är osäkert som standard och kan visa tomma sidor. Även om det vanligtvis är möjligt att åsidosätta standardinställningarna för webbläsaren och tillåta osäkert innehåll, resulterar detta i en upplevelse som liknar att bläddra på en webbplats med ett utgånget SSL-certifikat.

Certifikatalternativ

Distribution av webbplatser med HTTPS-bindningar och SSL/TLS-kryptering är nära relaterat till det bredare ämnet offentlig nyckelinfrastruktur (PKI), vilket är ett omfattande och intressant ämne där det redan finns en mängd olika dokumentationer. Vi kommer inte att försöka täcka all komplexitet här, utan fokuserar snarare på högnivåalternativ för att konfigurera HTTPS-bindningar för Azure DevOps Server-distributioner. Många organisationer har specifika principer för att distribuera certifikat, så det första steget i att bestämma vilket certifikat som ska användas för en Azure DevOps Server-distribution är ofta att prata med en informationsteknikgrupp på organisationsnivå.

Alternativen inkluderar:

• Tillåta att TFS-konfigurationsguiden genererar självsignerade certifikat för användning av distributionen.
• Hämta ett certifikat från en intern certifikatutfärdare.
• Hämta ett certifikat från en extern certifikatutfärdare.

Självsignerade certifikat

Självsignerade certifikat är användbara för utvärderingsdistributioner av Azure DevOps Server, eftersom de är mycket enkla att etablera och använda. De är mindre lämpliga för produktionsdistributioner av Azure DevOps Server och vi rekommenderar inte att de används för Azure DevOps Server-distributioner som exponeras för det offentliga Internet. I allmänhet är självsignerade certifikat mottagliga för man-in-the-middle-attacker. De orsakar också problem för användare, eftersom de kommer att orsaka certifikatvarningar och fel tills deras rotcertifikat har installerats på varje klientdator. Till exempel visar Edge-webbläsaren felet nedan.

När TFS-konfigurationsguiden genererar självsignerade certifikat för distributionen skapas två – ett som placeras i arkivet Betrodda rotcertifikatutfärdare på servern, och ett andra, signerat av det första, som placeras i det personliga arkivet på servern och används av Azure DevOps Server. Genom att konfigurera saker och ting på det här sättet kan du minimera risken för man-in-the-middle-attacker och aktivera rotation av certifikatet som används i HTTPS-bindningen utan att du behöver distribuera ett nytt certifikat till alla klienter för att undvika certifikatfel som det som visas ovan.

För att undvika dessa certifikatvarningar och fel kan du exportera rotcertifikatet och installera det på klientdatorer. Det finns flera sätt att åstadkomma detta, bland annat:

• Använda MMC-snapin-modulen Certifikat för att manuellt exportera certifikatet på servern och sedan importera det på varje klient.
• Med powershell-cmdleten Exportera certifikat , som finns i Windows 8/Windows Server 2012 och senare operativsystem, för att exportera certifikatet. Importcertifikat kan sedan användas för att importera det på varje klient.
• Använda grupprincip för att automatisera distributionen till klienter.

Interna och externa certifikatutfärdare

Många stora organisationer har en egen infrastruktur för offentliga nycklar och kan utfärda certifikat från sina egna certifikatutfärdare. När så är fallet distribueras vanligtvis de betrodda rotcertifikaten för dessa myndigheter redan till klientdatorer, vilket undviker behovet av att distribuera ytterligare certifikat för Azure DevOps Server. Om din organisation har en egen infrastruktur för offentliga nycklar kan det vara ett bra alternativ för din Azure DevOps Server-distribution.

När andra alternativ inte är lämpliga eller tillgängliga kan certifikat erhållas (vanligtvis till en kostnad) från en extern certifikatutfärdare (CA). Instruktioner för den här processen, som börjar med att skapa en begäran om certifikatsignering, finns på de flesta CA-webbplatser. Några viktiga kommentarer:

• Kontrollera att det gemensamma namn som anges i certifikatbegäran matchar det värdnamn som du vill använda i den offentliga URL:en, till exempel tfs.contoso.com.
• I egenskaperna för kryptografitjänstprovidern rekommenderar vi att du väljer Microsoft RSA SChannel Cryptographic Provider och en bit längd på 2048 eller senare.

Ändra din offentliga URL

Det bör också noteras att när du uppgraderar en befintlig Azure DevOps Server-distribution, kommer en ändring av den offentliga URL:en att påverka slutanvändarna. Även om vi fortfarande rekommenderar att konvertera från HTTP till HTTPS-bindningar måste Visual Studio-klientanslutningar återupprättas, gamla bokmärken löser sig inte längre korrekt och så vidare. Det är därför viktigt att samordna den här typen av ändringar med användarna av din Azure DevOps Server-distribution för att undvika betydande störningar.