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

TFS 2017 | TFS 2015 | TFS 2013

배경

대부분의 릴리스에서 Azure DevOps Server의 기본 웹 사이트 설정 (이전에는 TFS (Team Foundation Server))은 다음과 같습니다.

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

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

  • 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.

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

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

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

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

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

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

인증서 옵션

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

다음 옵션을 사용할 수 있습니다.

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

자체 서명된 인증서

자체 서명 된 인증서는 쉽게 프로 비전 하 고 사용할 수 있기 때문에 Azure DevOps Server의 평가판 배포에 유용 합니다. 이러한 값은 Azure DevOps Server의 프로덕션 배포에 적합 하지 않으며 공용 인터넷에 노출 되는 Azure DevOps Server 배포에 사용 하지 않는 것이 좋습니다. 일반적으로 자체 서명 된 인증서는 메시지 가로채기 (man-in-the-middle) 공격에 취약 합니다. 또한 각 클라이언트 컴퓨터에 루트 인증서가 설치 될 때까지 인증서 경고와 오류가 발생 하기 때문에 사용자에 게 문제가 발생 합니다. 예를 들어 Edge 브라우저에 아래 오류가 표시 됩니다.

Edge에서 인증서 오류가 발생 했습니다.

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

이러한 인증서 경고 및 오류를 방지 하기 위해 루트 인증서를 내보내고 클라이언트 컴퓨터에 설치할 수 있습니다. 다음을 비롯 한 여러 가지 방법으로이 작업을 수행할 수 있습니다.

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

내부 및 외부 인증 기관

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

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

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

공용 URL 변경

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