Azure DevOps 온-프레미스에 대한 웹 사이트 설정 및 보안

TFS 2017 | TFS 2015 | TFS 2013

배경

많은 릴리스에서 이전에 이름이 TFS(Team Foundation Server)인 Azure DevOps Server 대한 기본 웹 사이트 설정은 다음과 같습니다.

• 호스트 이름 또는 IP 주소가 지정되지 않은 포트 8080의 Azure DevOps Server 웹 사이트에 대한 단일 HTTP 바인딩입니다.
• 양식 http://machine-name:8080/tfs의 공용 URL(이전에는 알림 URL이라고 함)입니다.

이러한 설정의 주요 이점은 대부분의 시나리오에서 최종 사용자에게 매우 간단하게 설정하고 편리하다는 것입니다. 특히 다음 사항에 주의하십시오.

• HTTPS 대신 HTTP를 사용하면 인증서를 가져오고 설치할 필요가 없습니다.
• 80이 아닌 8080을 사용하면 동일한 컴퓨터의 다른 사이트와 잠재적 충돌을 방지할 수 있습니다.
• 사이트의 가상 디렉터리로 "tfs"를 사용하면 동일한 서버의 동일한 포트에서 Azure DevOps Server 및 기타 웹 사이트를 더 쉽게 호스트할 수 있습니다.
• 공용 URL에서 FQDN(정규화된 도메인 이름)이 아닌 컴퓨터 이름을 사용하면 많은 입력이 저장됩니다.
• 호스트 이름을 바인딩에 지정되지 않은 상태로 두면 사용자가 서버에 연결하려고 할 때 컴퓨터 이름, FQDN 또는 IP 주소가 모두 작동합니다.

그러나 이러한 설정은 기본적으로 안전하지 않습니다. 특히 HTTPS 바인딩을 사용하지 않으면 IPSec과 같은 다른 솔루션을 사용하지 않는 한 Azure DevOps Server 통신이 전송 중에 암호화되지 않습니다. 따라서 통신 내용을 모니터링하거나 수정하는 악의적인 행위자에게 잠재적으로 취약할 수 있습니다. 이러한 문제는 대부분의 Azure DevOps Server 인스턴스와 마찬가지로 Azure DevOps Server 회사 방화벽 뒤의 인트라넷에 배포될 때 어느 정도 완화됩니다. 그러나 이러한 시나리오에서도 Azure DevOps Server 주고 받는 데이터에는 소스 코드, 작업 항목 데이터 및 추가 보안을 활용할 수 있는 기타 정보가 포함됩니다.

또한 TFS 2017에는 전달자 토큰을 유선으로 보내는 새로운 인증 시나리오(빌드/릴리스 에이전트 서비스 계정 인증, 개인용 액세스 토큰)가 있습니다. 악의적인 사용자가 이러한 토큰을 가져온 경우 해당 토큰을 사용하여 자신이 속한 사용자를 가장할 수 있습니다.

이 모든 것을 감안할 때, 우리는 Azure DevOps Server 배포에서 HTTPS 바인딩의 사용을 더 강력하게 옹호할 때가 되었다고 결정했습니다.

그룹 설정

TFS 2017은 모든 서버 구성 시나리오에서 웹 사이트 설정 구성 옵션을 제공합니다. 사이트 바인딩, 가상 디렉터리 및 공용 URL의 조합을 번들로 묶는 몇 가지 설정 그룹이 제공됩니다. 이 조합은 가장 일반적으로 사용됩니다. 이러한 설정 그룹이 적절하지 않은 시나리오의 경우 사이트 설정 편집 대화 상자를 사용하여 설정을 완전히 사용자 지정할 수 있습니다.

기본 설정 그룹에는 이전 버전의 Azure DevOps Server 사용된 것과 동일한 설정이 포함됩니다. 위에 나열된 모든 이유로 이러한 설정은 여전히 새 Azure DevOps Server 배포의 기본값입니다. 기존 배포의 경우 기존 설정을 유지하려고 시도합니다. 이로 인해 기본 설정 그룹이 선택되는 경우가 많습니다.

HTTPS 및 HTTP(리디렉션 포함) 설정 그룹은 두 개의 바인딩을 프로비전합니다.

• 포트 443에서 컴퓨터의 FQDN(정규화된 도메인 이름)을 호스트 이름으로 사용하는 하나의 HTTPS 바인딩입니다.
• 포트 80에서 하나의 HTTP 바인딩, 다시 컴퓨터의 FQDN을 호스트 이름으로 사용합니다.

포트 80의 HTTP 바인딩은 최종 사용자의 편의를 위해 추가됩니다. 모든 트래픽이 포트 443에서 HTTPS 바인딩을 사용하도록 리디렉션이 구성됩니다. 이 설정 그룹의 공용 URL은 형식입니다. https://fully-qualified-domain-name. 기본적으로 이 설정 그룹은 새 자체 서명된 인증서를 프로비전하고 HTTPS 바인딩에 사용합니다. 일반적으로 프로덕션 TFS 배포에는 자체 서명된 인증서를 사용하지 않는 것이 좋습니다. 자체 서명된 인증서를 사용하는 것이 적절한 시기 및 사용 가능한 다른 옵션에 대한 자세한 내용은 아래 인증서 옵션을 참조하세요.

HTTPS만 설정 그룹은 컴퓨터의 FQDN을 호스트 이름으로 사용하여 포트 443에 단일 HTTPS 바인딩을 프로비전합니다. 이 설정 그룹의 공용 URL은 형식 https://fully-qualified-domain-name이며 자체 서명된 인증서는 기본적으로 프로비전됩니다.

HTTP 전용 설정 그룹은 호스트 이름이 지정되지 않은 포트 80에 단일 HTTP 바인딩을 프로비전합니다. 이 설정 그룹의 공용 URL은 형식입니다. http://machine-name.

HTTPS 및 HTTP(리디렉션 포함) 설정 그룹을 사용하는 경우 HTTP 공용 URL을 사용하지 않는 것이 좋습니다. 대부분의 최신 브라우저는 기본적으로 혼합 HTTP 및 HTTPS 콘텐츠가 안전하지 않다고 간주하고 빈 페이지를 표시할 수 있습니다. 일반적으로 기본 브라우저 설정을 재정의하고 안전하지 않은 콘텐츠를 허용할 수 있지만, 이로 인해 만료된 SSL 인증서로 사이트를 검색하는 것과 유사한 환경이 발생합니다.

인증서 옵션

HTTPS 바인딩 및 SSL/TLS 암호화를 사용하여 웹 사이트를 배포하는 것은 다양한 설명서가 이미 존재하는 풍부하고 흥미로운 항목인 PKI(공개 키 인프라)의 광범위한 항목과 밀접한 관련이 있습니다. 여기서는 모든 복잡성을 다루지 않고 Azure DevOps Server 배포에 대한 HTTPS 바인딩을 구성하기 위한 높은 수준의 옵션에 초점을 맞출 것입니다. 많은 조직에 인증서 배포와 관련된 특정 정책이 있으므로 Azure DevOps Server 배포에 사용할 인증서를 결정하는 첫 번째 단계는 종종 organization 수준 정보 기술 그룹과 통신하는 것입니다.

표시되는 옵션은 다음과 같습니다.

• TFS 구성 마법사가 배포에서 사용할 자체 서명된 인증서를 생성하도록 허용합니다.
• 내부 인증 기관에서 인증서를 가져옵니다.
• 외부 인증 기관에서 인증서를 가져옵니다.

자체 서명된 인증서

자체 서명된 인증서는 프로비전 및 사용이 매우 쉽기 때문에 Azure DevOps Server 평가판 배포에 유용합니다. Azure DevOps Server 프로덕션 배포에는 적합하지 않으며 공용 인터넷에 노출된 Azure DevOps Server 배포에는 사용하지 않는 것이 좋습니다. 일반적으로 자체 서명된 인증서는 중간자 공격에 취약합니다. 또한 루트 인증서가 각 클라이언트 컴퓨터에 설치될 때까지 인증서 경고 및 오류가 발생하므로 사용자에게 문제가 발생합니다. 예를 들어 Edge 브라우저에는 아래 오류가 표시됩니다.

TFS 구성 마법사가 배포에 대해 자체 서명된 인증서를 생성하면 서버의 신뢰할 수 있는 루트 인증 기관 저장소에 배치되고 두 번째 인증서는 서버의 개인 저장소에 배치되고 Azure DevOps Server 사용하는 두 번째 인증서를 만듭니다. 이러한 방식으로 작업을 설정하면 맨인더중 공격의 가능성을 완화하고 위에 표시된 것과 같은 인증서 오류를 방지하기 위해 모든 클라이언트에 새 인증서를 배포할 필요 없이 HTTPS 바인딩에 사용되는 인증서를 회전할 수 있습니다.

이러한 인증서 경고 및 오류를 방지하려면 루트 인증서를 내보내고 클라이언트 컴퓨터에 설치할 수 있습니다. 이 작업을 수행하는 방법에는 다음이 포함됩니다.

• 인증서 MMC 스냅인을 사용하여 서버에서 인증서를 수동으로 내보낸 다음 각 클라이언트에서 가져옵니다.
• Windows 8/Windows Server 2012 이상 운영 체제에서 사용할 수 있는 Export-Certificate powershell cmdlet을 사용하여 인증서를 내보냅니다. 그런 다음, Import-Certificate를 사용하여 각 클라이언트에서 가져올 수 있습니다.
• 그룹 정책 사용하여 클라이언트에 대한 배포를 자동화합니다.

내부 및 외부 인증 기관

많은 대규모 조직에는 자체 공개 키 인프라가 있으며 자체 인증 기관에서 인증서를 발급할 수 있습니다. 일반적으로 이 경우 이러한 기관에 대한 신뢰할 수 있는 루트 인증서가 클라이언트 컴퓨터에 이미 배포되므로 Azure DevOps Server 위해 추가 인증서를 배포할 필요가 없습니다. organization 자체 공개 키 인프라가 있는 경우 Azure DevOps Server 배포에 적합한 옵션이 될 수 있습니다.

다른 옵션이 적절하지 않거나 사용할 수 없는 경우 외부 CA(인증 기관)에서 인증서를 얻을 수 있습니다(일반적으로 비용). 인증서 서명 요청 만들기로 시작하는 이 프로세스에 대한 지침은 대부분의 CA 웹 사이트에서 찾을 수 있습니다. 몇 가지 중요한 참고 사항:

• 인증서 요청에 제공된 일반 이름이 공용 URL에서 원하는 호스트 이름(예: tfs.contoso.com)과 일치하는지 확인합니다.
• 암호화 서비스 공급자 속성에서 Microsoft RSA SChannel 암호화 공급자 및 비트 길이 2048 이상을 선택하는 것이 좋습니다.

공용 URL 변경

또한 기존 Azure DevOps Server 배포를 업그레이드할 때 공용 URL을 변경하면 최종 사용자에게 영향을 미칩니다. HTTP에서 HTTPS 바인딩으로 변환하는 것이 권장되지만 Visual Studio 클라이언트 연결을 다시 설정해야 하며 이전 책갈피가 더 이상 제대로 resolve 않습니다. 따라서 상당한 중단을 방지하기 위해 이러한 종류의 변경을 Azure DevOps Server 배포의 사용자와 조정하는 것이 중요합니다.