Team Foundation Server에 대해 HTTPS를 SSL(Secure Sockets Layer)과 함께 설정

SSL(Secure Sockets Layer)과 함께 HTTPS(Hypertext Transfer Protocol Secure)를 사용하도록 구성하여 Visual Studio Team Foundation Server(TFS)의 배포 보안을 강화할 수 있습니다. 이 프로토콜을 사용해야 하도록 선택하여 배포의 보안을 최대화하거나 기본 프로토콜인 HTTP 외에 HTTPS/SSL을 지원하도록 선택할 수 있습니다. Visual Studio 2013용 Release Management를 사용하는 경우에는 Release Management도 HTTPS/SSL을 사용하도록 구성할 수 있습니다. 그러나 HTTP와 HTTPS/SSL을 모두 지원하도록 구성할 수는 없습니다.

구성을 선택하기 전에 여기에 설명된 장단점을 검토합니다. 조직의 보안 요구 사항에 가장 적합한 구성을 파악한 다음 이 항목의 단계에 따라 배포를 구성하십시오.

항목 내용

• 개념 정보

  • HTTP 외에도 HTTPS/SSL을 지원할 경우의 장점

  • 모든 연결에 HTTPS/SSL을 사용할 경우의 장점

  • HTTPS/SSL을 지원하거나 요구할 경우의 단점

  • 필수 조건

  • Assumptions

• 서버 구성

  • 인증서 가져오기

  • 인증서를 사용하여 웹 사이트 요청, 설치 및 구성

  • 방화벽 구성

  • SQL Server Reporting Services 구성

  • TFS에 대해 HTTPS 구성

• 선택적인 구성 작업

  • 배포에 대한 액세스 테스트(선택 사항)

  • HTTPS/SSL을 요구하도록 배포 구성(선택 사항)

• 빌드 구성

  • 빌드 서버에 인증서 설치

  • 빌드 구성 업데이트

• Release Management 구성

  • Release Management와 TFS

  • HTTPS를 사용하도록 Release Management 서버 구성

  • 모든 Release Management 연결 설정 시 HTTPS 사용

• 클라이언트 구성

  1. 클라이언트 컴퓨터 구성

  2. Git 리포지토리 구성

     1. 인증서에 대한 Git 구성

HTTP 외에도 HTTPS/SSL을 지원할 경우의 장점

두 프로토콜을 모두 지원하도록 TFS 배포를 구성할 경우, HTTPS/SSL을 사용하도록 구성된 컴퓨터의 사용자는 이 프로토콜을 사용하여 연결하므로 배포의 보안이 향상됩니다. 또한 HTTP만 사용하도록 구성된 컴퓨터의 사용자도 배포에 연결할 수 있습니다. 공용 네트워크에는 이 구성을 배포할 수 없지만 제어된 네트워크 환경에서 HTTP 연결을 계속 지원하여 다음과 같은 장점을 얻을 수 있습니다.

• 일정이 허락하는 한 클라이언트 컴퓨터에 HTTPS/SSL을 구성하여 시간이 지날수록 배포의 보안을 향상시킬 수 있습니다. 단계별 접근 방식을 사용할 경우 모든 컴퓨터를 동시에 업그레이드할 필요가 없으며 컴퓨터를 아직 업그레이드하지 않은 사용자도 계속 배포에 연결할 수 있습니다.

• Team Foundation Server를 보다 쉽게 구성하고 유지 관리할 수 있습니다.

• 웹 서버 간의 호출은 HTTP가 HTTPS/SSL보다 빠릅니다. 따라서 성능 요구 사항이 보안 위험보다 더 중요한 클라이언트 컴퓨터에서는 HTTP 연결을 계속 지원할 수 있습니다.

모든 연결에 HTTPS/SSL을 사용할 경우의 장점

모든 연결에 HTTPS/SSL을 요구할 경우 다음과 같은 이점을 얻을 수 있습니다.

• Team Foundation에 대한 응용 프로그램 계층, 데이터 계층 및 클라이언트 계층 간의 모든 웹 연결은 인증서가 필요하기 때문에 보다 안전합니다.

• 프로젝트 단계가 종료될 예정일 때 인증서가 종료되도록 구성하여 액세스를 보다 쉽게 제어할 수 있습니다.

HTTPS/SSL을 지원하거나 요구할 경우의 단점

SSL로 HTTPS를 지원하거나 요구하기 위해 TFS를 구성하기 전에 다음과 같은 단점을 고려해야 합니다.

• 지속적인 관리 작업이 복잡해질 수 있습니다. 예를 들어 서비스 팩 또는 기타 업그레이드를 적용하려면 HTTPS/SSL 지원을 중지하도록 배포를 다시 구성해야 할 수 있습니다.

• CA(인증 기관) 및 인증서 신뢰를 구성할 뿐만 아니라 관리도 수행해야 합니다. Windows Server 2003 및 Windows Server 2008에서 인증서 서비스를 사용할 수 있지만 보안 PKI(공개 키 인프라)를 배포하려면 시간과 리소스가 필요합니다.

• 이러한 구성을 설정 및 테스트하는 데는 상당한 시간이 필요하며 배포 문제를 해결하기가 더 어렵습니다.

• 두 프로토콜을 계속 지원할 경우 Team Foundation의 응용 프로그램 계층이 올바르게 보안되지 않으면 외부 연결이 암호화되지 않을 수 있습니다.

• HTTPS/SSL을 요구할 경우 배포 성능이 낮아집니다.

HTTPS/SSL을 지원 및 요구하도록 배포 구성

이 항목의 절차에서는 TFS에서 SSL 연결에 필요한 인증서를 요청, 발급 및 할당하기 위한 한 가지 프로세스에 대해 설명합니다. 이 항목에서 설명하는 소프트웨어와 다른 소프트웨어를 사용할 경우 다른 단계를 수행해야 할 수 있습니다. TFS 배포에 대한 외부 연결을 지원하려면 IIS(인터넷 정보 서비스)에서 기본 인증이나 다이제스트 인증 또는 두 가지 인증을 모두 사용하도록 설정해야 합니다.

이 항목의 절차에 따라 다음 작업을 수행합니다.

1. Team Foundation Server 배포 사용되는 웹 사이트에 대한 인증서를 가져옵니다.

2. 인증서를 설치 및 할당합니다.

3. Team Foundation Server를 구성합니다.

4. Team Foundation Build를 구성합니다.

5. Visual Studio 2013용 Release Management 구성

6. 클라이언트 컴퓨터를 구성합니다.

필수 조건

이 항목의 절차를 수행하려면 다음과 같은 요구 사항을 충족해야 합니다.

• TFS 자체의 경우 반드시 구성할 필요는 없지만, Team Foundation의 데이터 및 응용 프로그램 계층에 논리적 구성 요소를 설치해야 합니다. 이러한 계층에는 IIS, SQL Server 그리고 SharePoint 제품, Team Foundation Build, Release Management, SQL Server Reporting Services와 같이 이미 통합했을 수 있는 추가적인 구성 요소가 포함됩니다.

  이 항목의 절차에서는 Team Foundation에 대한 응용 프로그램 계층과 Team Foundation에 대한 데이터 계층에서 논리적 구성 요소를 실행 중인 서버를 참조합니다. Team Foundation Server 설치 가이드에 설명된 것처럼, 응용 프로그램 및 데이터 계층은 동일한 서버 또는 여러 서버에서 실행될 수 있습니다.

• 인증서를 발급할 수 있는 CA(인증 기관)가 있어야 하거나 신뢰할 수 있는 체인을 사용하여 타사 인증 기관에 가입해야 합니다. 이 항목에서는 인증서 서비스를 CA로 사용하지만 배포에 대해 구성한 모든 CA 또는 신뢰할 수 있는 타사 인증 기관의 인증서를 사용할 수 있습니다. 인증 기관이 없는 경우에는 인증서 서비스를 설치하고 인증 기관을 구성할 수 있습니다. 자세한 내용은 Microsoft 웹 사이트에서 다음 설명서 집합 중 하나를 참조하십시오.

  • Windows Server 2012: Active Directory 인증서 서비스

  • Windows Server 2008: Active Directory 인증서 서비스 및 공개 키 관리

필요한 권한

HTTPS 및 SSL에 대한 배포의 모든 구성 요소를 구성하려면 관리자여야 합니다. 다른 사람이 SharePoint와 같은 개별 구성 요소에 대한 관리 권한이 있는 분산된 배포 환경에서 작업하는 경우, 이런 사람들과 협력하여 구성을 완료해야 합니다.

특히, 사용자가 Team Foundation 관리자 그룹과 Team Foundation에 대한 응용 프로그램 계층, 데이터 계층 및 TFS 프록시 서버에 대한 관리자 그룹에 속해야 합니다. 빌드 서버를 구성하려면 해당 서버에서 Administrators 그룹에 속해야 합니다. Release Management를 구성하려면 Release Management 서버를 호스팅하는 서버의 Administrators 그룹에 속해야 하며 Release Management의 릴리스 관리자 역할 멤버여야 합니다. 배포에 SharePoint 제품가 사용될 경우 SharePoint 중앙 관리를 호스팅하는 서버에서 Administrators 그룹에 속해야 합니다. 또한 팜 관리자 그룹에도 속해야 합니다. 배포에서 보고를 사용하는 경우, 관리자 보안 그룹의 구성원이거나 보고 서비스 구성을 위해 개별적으로 설정된 동등한 권한을 가지고 있어야 합니다. 권한에 대한 자세한 내용은 Team Foundation Server에 대한 사용 권한 참조을 참조하십시오.

Assumptions

이 항목의 절차에서는 다음 조건에 해당하는 것으로 가정합니다.

• 데이터 계층 및 응용 프로그램 계층 서버는 보안 환경에 설치 및 배포되며 최선의 보안 방법에 따라 구성됩니다.

• Visual Studio 2013용 Release Management를 설치했습니다.

• 사용자가 PKI 구성 및 관리 방법과 인증서 요청, 발급 및 할당 작업에 익숙합니다.

• 사용자가 개발 환경의 네트워크 토폴로지에 대한 실무 지식이 있고 네트워크 설정, IIS 및 SQL Server를 구성하는 데 익숙합니다.

인증서 가져오기

SSL을 쓰는 HTTPS를 사용하기 위해 TFS를 구성하려면 먼저 배포 환경에 서버의 서버 인증서를 구하여 설치해야 합니다. 서버 인증서를 가져오려면 고유한 인증 기관을 설치 및 구성하거나 신뢰할 수 있는 외부 조직의 인증 기관(타사 인증서)을 사용해야 합니다.

인증 기관을 설치하는 방법에 대한 자세한 내용은 Microsoft 웹 사이트에서 다음 항목을 참조하십시오.

• Windows Server 2012: AD CS 2단계 PKI 계층 배포

• Windows Server 2008: Active Directory 인증서 서비스 및 공개 키 관리

인증서를 사용하여 웹 사이트 요청, 설치 및 구성

인증 기관에 등록한 후에는 IIS 관리자를 사용하여 인증서를 요청하거나 배포에 포함된 다음과 같은 각 서버에 인증서를 수동으로 설치해야 합니다.

• 각 응용 프로그램 계층 서버

• 배포에 대해 구성된 항목이 있는 경우 Team Foundation Server Proxy를 실행하는 각 서버

• 배포에 대해 구성된 항목이 있는 경우 Team Foundation Build Service를 빌드 컨트롤러 또는 빌드 에이전트로 실행하는 각 서버

• Release Management 서버를 실행하는 각 서버 또는 배포 에이전트를 실행하는 릴리스 환경의 모든 서버¹(배포에 Release Management가 포함되는 경우)

• SharePoint 제품가 배포용으로 구성되어 있는 경우 SharePoint 제품를 실행 중인 각각의 서버.

  참고

  HTTPS와 인증서를 사용하도록 SharePoint 사이트를 구성하는 경우에는 대체 액세스 매핑 구성 및 인증 인프라 구성과 같은 추가 단계를 수행해야 하는 경우가 많습니다.자세한 내용은 사용 중인 제품 버전의 최신 SharePoint 설명서를 참조하세요.

• 배포에 대해 구성된 항목이 있는 경우 Reporting Services를 실행하는 서버

또한, 배포 환경의 클라이언트 컴퓨터는 인증서 체인에 등록되어야 하고 필요한 인증서를 요청해야 합니다. Release Management를 사용하는 경우 여기에는 Release Management 클라이언트를 실행 중인 모든 컴퓨터와 릴리스 환경에서 배포 에이전트를 실행 중인 모든 클라이언트¹가 포함됩니다. 또한, 하나 이상의 프로젝트에서 버전 관리를 위해 Git를 사용하는 경우 해당 프로젝트의 사용자는 컴퓨터의 Git가 클라이언트 인증서를 인식하고 사용하도록 구성해야 합니다. 특정 CA에서 클라이언트 인증서를 요청하는 방법에 대한 자세한 내용은 해당 인증 기관에 대한 설명서를 참조하십시오.

¹ 여기서는 클라이언트와 서버를 별도로 지칭하지만 이러한 표기는 이 문서의 규칙일 뿐이며, 배포 에이전트를 실행하는 모든 컴퓨터에는 인증서를 설치해야 합니다.

1. IIS(인터넷 정보 서비스) 관리자를 엽니다.

2. 서버를 확장하고, 서버 인증서로 이동하고, 인증서 요청을 만들고 완료합니다.

   

   

   자세한 내용은 IIS에서 서버 인증서 구성을 참조하세요.

3. 인증서를 가져옵니다.

4. 이제는 적절한 설정으로 이 인증서를 요구하는 각 웹 사이트를 구성해야 합니다. 단, 나중에 구성할 Release Management 웹 사이트는 예외입니다. 특히, 다음의 각 웹 사이트에 대해 이 작업을 수행해야 합니다.

   • 기본 웹 사이트

   • Team Foundation Server

   • Microsoft Team Foundation Server Proxy(배포에서 사용하는 경우)

   • SharePoint 중앙 관리(배포에서 SharePoint를 사용하는 경우)

   구성하려는 웹 사이트를 호스팅하는 각 서버에서 인터넷 정보 서비스(IIS) 관리자를 엽니다.

5. ComputerName과 사이트를 차례로 확장하고 구성하려는 웹 사이트의 하위 메뉴(예: Team Foundation Server)를 연 다음 작업 창에서 바인딩을 선택합니다.

   

6. 사이트 바인딩에서 추가를 선택합니다.

   그러면 사이트 바인딩 추가 대화 상자가 나타납니다.

7. 유형 목록에서 https를 선택합니다.

   포트에 다른 포트 번호를 입력합니다.

   중요

   SSL 연결의 기본 포트 번호는 443이지만 기본 웹 사이트, Team Foundation Server, Microsoft Team Foundation Server Proxy(배포에 사용되는 경우) 및 SharePoint 중앙 관리(배포에서 SharePoint를 사용하는 경우)의 각 사이트에 대해 고유한 포트 번호를 할당해야 합니다.

   구성하는 각 웹 사이트의 SSL 포트 번호를 기록해 두어야 합니다.Team Foundation의 관리 콘솔에서 해당 포트 번호를 지정해야 합니다.

   SSL 인증서에서 가져온 인증서를 선택한 다음, 확인을 선택하고 바인딩 페이지를 닫습니다.

   

8. 구성 중인 웹 사이트의 홈 페이지에서 기능 보기를 엽니다.

9. IIS에서 인증을 선택합니다.

10. 구성하고자 하는 인증 방법을 선택하고 하위 메뉴를 연 후 보안 요구에 가장 적합한 메서드에 대해 추가 구성을 활성화, 비활성화 또는 수행합니다. 예를 들어, 익명 인증을 비활성화하려고 한 경우 익명 인증 메서드를 선택하고 작업 메뉴에서 사용 안 함을 선택합니다.

    

11. 구성을 마친 후 웹 서비스를 다시 시작합니다.

방화벽 구성

바로 전에 IIS에서 지정한 SSL 포트를 트래픽이 통과하도록 방화벽을 구성해야 합니다. 자세한 내용은 방화벽 설명서를 참조하십시오.

중요

다른 컴퓨터에서 지정한 포트에서 트래픽을 테스트해야 합니다.기본 웹 사이트 또는 Team Web Access에 액세스할 수 없는 경우 IIS에서는 이런 웹 사이트에 대해 지정한 포트 설정을 중복 확인하고 방화벽이 해당 포트에서 트래픽을 허용하도록 제대로 구성되어 있는지 확인합니다.

SQL Server Reporting Services 구성

배포에 보고가 사용될 경우 HTTPS/SSL을 지원하고 Team Foundation Server에 대해 IIS에서 지정된 포트를 사용하도록 SQL Server Reporting Services를 구성해야 합니다. 그렇지 않으면 보고서 서버가 배포에 대해 올바르게 작동하지 않습니다. 자세한 내용은 SSL(Secure Sockets Layer) 연결에 대한 보고서 서버 구성을 참조하세요.

팁

배포에 보고가 사용되지 않는 경우 이 절차를 건너뛸 수 있습니다.

TFS에 대해 HTTPS 구성

다음 지침에 따라 기본값 및 Team Foundation Server 웹 사이트에 대해 IIS에서 구성한 HTTPS 포트와 값으로 TFS 배포를 구성합니다.

HTTPS를 사용하거나 이를 필수로 하도록 Team Foundation Server를 다시 구성하려면

1. Team Foundation에 대한 관리 콘솔을 열고 응용 프로그램 계층 노드를 찾아봅니다.

2. 응용 프로그램 계층 요약에서 URL 변경을 선택합니다.

   URL 변경 창이 열립니다.

3. 알림 URL에 IIS에서 Team Foundation Server 웹 사이트에 대해 구성한 HTTPS URL을 입력합니다.

   예를 들어, 포트 444를 사용하도록 웹 사이트를 구성했을 수 있습니다. 이 경우에는 https://ServerName:444/tfs를 입력합니다. localhost 대신 서버의 전체 도메인 이름을 사용해야 합니다.

   

4. 테스트를 선택합니다. 테스트에 통과하지 못하는 경우 확인을 선택하지 마십시오. 뒤로 이동하여 올바른 URL 및 포트 정보를 입력하고, 모든 방화벽이 해당 포트에서 트래픽을 허용하도록 구성되어 있고, 사이트를 사용할 수 있고 IIS 관리자에서 작동 중인지 확인하십시오.

5. HTTPS를 요구하려면 서버 URL에서 사용을 선택한 다음 Team Foundation Server 웹 사이트에 대해 구성한 HTTPS URL을 입력합니다.

   localhost 대신 서버의 전체 도메인 이름을 사용해야 합니다.

6. 테스트를 선택한 후 테스트가 통과되면 확인을 선택합니다.

7. 배포에 SharePoint 제품가 사용되는 경우 관리 콘솔에서 SharePoint 웹 응용 프로그램을 선택합니다. 그렇지 않을 경우 다음 6개 단계를 건너뜁니다.

8. SharePoint 웹 응용 프로그램의 이름 목록에서 웹 응용 프로그램을 선택한 후 변경을 선택합니다.

   SharePoint 웹 응용 프로그램 설정 페이지가 열립니다.

9. 웹 응용 프로그램 URL에서 URL을 응용 프로그램의 HTTPS 값으로 변경합니다.

10. 중앙 관리 URL에서 URL을 중앙 관리 웹 사이트에 대한 HTTPS 값으로 변경합니다.

11. (선택 사항) 이름에서 이 응용 프로그램의 HTTPS 주소를 반영하도록 값을 변경합니다.

12. 확인을 선택합니다.

13. 배포에 포함된 모든 SharePoint 웹 응용 프로그램에 대해 앞의 5단계를 반복합니다.

14. 배포에 Reporting Services가 사용되는 경우 관리 콘솔에서 보고를 선택합니다. 그렇지 않으면 이 절차의 나머지 단계를 건너뜁니다.

15. 보고에서 편집을 선택합니다.

    오프라인으로 설정 대화 상자가 열리면 확인을 선택합니다.

    보고 창이 열립니다.

16. 보고서 탭을 선택합니다. 보고서 서버의 URL에서 웹 서비스 및 보고서 관리자에 대해 HTTPS URL을 입력한 다음 확인을 선택합니다.

배포에 대한 액세스 테스트

변경 사항이 예상한 대로 작동하는지 테스트해야 합니다. 이 단계는 선택 사항이지만 반드시 수행하는 것이 좋습니다.

배포에 대한 액세스를 테스트하려면

1. 응용 프로그램 계층을 호스트하지 않는 컴퓨터에서 웹 브라우저를 열고 팀 홈 페이지로 이동합니다.

2. 관리 페이지를 포함하여, Team Web Access에서 팀과 프로젝트에 액세스할 수 있는지 확인합니다.

3. Team Web Access를 통해 배포에 액세스할 수 없으면 바로 전에 완료한 단계를 검토하고 모든 구성이 성공적으로 변경되었는지 확인합니다.

HTTPS/SSL을 요구하도록 배포 구성(선택 사항)

TFS 응용 프로그램 계층에 대한 모든 연결에서는 SSL을 포함한 HTTPS 사용을 필수 요건으로 지정할 수 있습니다. 이 추가 보안은 선택 사항이지만 수행하는 것이 좋습니다.

SSL 연결을 요구하려면

1. 직접 구성하고자 하는 웹 사이트를 수용하는 서버에서 시작을 선택하고 관리 도구를 선택한 후 IIS(인터넷 정보 서비스) 관리자를 선택합니다.

2. IIS 버전에 따라 적합한 단계를 수행합니다.

   IIS 7.0을 사용하는 배포의 경우:

   1. ComputerName, 웹 사이트를 차례로 확장한 다음 구성하려는 웹 사이트를 선택합니다.

   2. 해당 웹 사이트의 홈 페이지에서 SSL 설정을 선택합니다.

   3. SSL 설정 창에서 SSL 필요 확인란을 선택합니다.

      (선택 사항) 128비트 SSL 필요 확인란을 선택합니다.

   4. 클라이언트 인증서에서 배포의 보안 요구 사항에 따라 무시, 수락 또는 필요를 선택합니다.

   5. 작업에서 적용을 선택합니다.

   6. SSL을 요구하려는 각 웹 사이트에 대해 이 단계를 반복합니다.

빌드 서버에 인증서 설치

하나 이상의 서버에 Team Foundation Build Service를 설치한 경우 각 서버의 신뢰할 수 있는 루트 인증 기관 저장소에 인증서를 설치해야 합니다. 자세한 내용은 이 항목 앞부분에 있는 인증서 가져오기 및 인증서를 사용하여 웹 사이트 요청, 설치 및 구성을 참조하세요. 컨트롤러와 에이전트에는 모두 HTTPS 연결에서 자신을 식별할 수 있도록 공개 키가 포함된 인증서가 포함됩니다.

참고

SSL을 통해 빌드를 수행하려면 빌드 컨트롤러 및 빌드 에이전트 모두의 신뢰할 수 있는 루트 저장소에 인증서가 설치되어 있어야 합니다.

빌드 구성 업데이트

Team Foundation Build에서 SSL 연결을 구성하려면 빌드 구성에서 지원하는 응용 프로그램 계층 및 컬렉션에 대해 구성한 HTTPS URL을 사용하도록 빌드 서비스를 구성해야 합니다. 배포에 포함된 각 빌드 구성에 대해 이 URL을 구성해야 합니다.

HTTPS를 사용하도록 빌드 구성을 변경하려면

1. 구성하려는 빌드 구성을 호스팅하는 서버에서 Team Foundation 관리 콘솔을 엽니다.

2. Team Foundation에서 서버 이름을 확장한 후 빌드 구성을 선택합니다.

   빌드 구성 창이 나타납니다.

3. 서비스 구성에서 중지를 선택한 후 속성을 선택합니다.

   빌드 서비스 속성 대화 상자가 열립니다.

4. 통신에서 팀 프로젝트 컬렉션에 대한 URL이 올바른 HTTPS 주소 및 전체 서버 이름을 사용하는지 확인합니다.

5. **로컬 빌드 서비스 끝점(수신)**에서 변경을 선택합니다.

   빌드 서비스 끝점 대화 상자가 열립니다.

6. 끝점 정보에서 포트 번호가 구성 정보와 일치하는지 확인합니다.

7. 프로토콜에서 HTTPS를 선택합니다.

8. SSL 인증서 목록에서 이 배포에 사용할 목적으로 설치하고 구성한 인증서를 선택한 후 확인을 선택합니다.

   

9. 빌드 서비스 속성 대화 상자에서 시작을 선택합니다.

Release Management와 TFS

TFS에 대해 사용 중인 프로토콜 또는 TFS 자체를 사용 중인지 여부에 관계없이 TFS와 완전히 별도로 HTTPS를 사용해 Release Management를 배포할 수 있습니다. Release Management를 배포하려는 방법에 관계없이 Release Management의 안전한 배포를 만드는 지침은 여기서 TFS에 대해 설명하는 지침과 매우 비슷합니다. 두 배포 간의 가장 큰 차이점은 Release Management 웹 사이트에 HTTPS 프로토콜을 바인딩하는 절차입니다. 아래에서 해당 절차에 대해 설명합니다.

HTTPS를 사용하여 Release Management를 배포하려면 아래 작업 목록을 사용합니다. TFS를 사용하여 Release Management를 구성하는 경우 TFS 구성을 위해 이미 완료한 작업을 건너뜁니다.

1. 인증서를 가져옵니다. 자세한 내용은 인증서 가져오기를 참조하세요.

2. HTTPS를 사용하도록 Release Management 서버를 구성합니다. 다음 섹션인 HTTPS를 사용하도록 Release Management 서버 구성을 참조하세요.

3. Release Management 클라이언트 또는 Microsoft Deployment Agent를 실행하는 컴퓨터의 신뢰할 수 있는 루트 저장소에 인증서를 설치합니다. 자세한 내용은 클라이언트 컴퓨터 구성을 참조하세요.

4. 방화벽을 엽니다. 인증서를 설치한 후에는 SSL 트래픽에 사용한 포트를 열어야 합니다. 자세한 내용은 방화벽 구성을 참조하세요.

5. 테스트를 진행합니다. Release Management 서버의 웹 사이트는 검색할 수 있도록 구성되지 않으므로 해당 웹 사이트를 사용할 수 있는지 테스트하려면 Release Management 클라이언트에 웹 사이트를 연결하고 환경의 에이전트를 연결한 후에 릴리스를 만들어야 합니다. 자세한 내용은 모든 Release Management 연결 설정 시 HTTPS 사용 및 릴리스 관리를 참조하세요.

HTTPS를 사용하도록 Release Management 서버 구성

Release Management에서는 HTTPS 또는 HTTP 프로토콜 중 하나를 지원하며 두 프로토콜을 동시에 지원하지는 않습니다. Release Management 웹 사이트에 HTTPS 프로토콜을 바인딩하려면 다음 절차를 수행합니다.

1. Release Management 서버에서 HTTPS를 선택하고 HTTPS 트래픽에 사용할 포트 번호를 웹 서비스 포트에 입력한 후에 설정 적용을 선택합니다.

   

2. IIS(인터넷 정보 서비스) 관리자를 엽니다.

3. ComputerName과 사이트를 차례로 확장하고 Release Management 웹 사이트의 하위 메뉴를 연 다음 작업 창에서 바인딩을 선택합니다.

4. 사이트 바인딩에서 추가를 선택합니다.

5. 유형 목록에서 https를 선택합니다.

6. 포트에 다른 포트 번호를 입력합니다. 이 포트 번호는 구성을 완료하는 데 필요한 임시 포트 번호입니다.

   

7. SSL 인증서에서 사용할 인증서를 선택한 다음 확인을 선택하여 바인딩 페이지를 닫습니다.

   원래 HTTP 바인딩과 방금 만든 HTTPS 바인딩이 표시됩니다.

8. 원래 HTTP 바인딩을 선택하고 제거를 선택합니다.

9. HTTPS 바인딩을 선택하고 편집을 선택합니다.

10. 포트를 6단계에서 추가한 임시 값에서 1단계에서 Release Management 서버에 사용한 포트 번호로 변경하고 확인과 닫기를 선택합니다.

    

    IIS에서 Release Management 웹 사이트의 HTTPS 포트 바인딩은 Release Management 서버 구성 도구에 원래 입력한 포트와 일치합니다.

    

모든 Release Management 연결 설정 시 HTTPS 사용

Release Management 클라이언트 및 Microsoft Deployment Agent를 실행 중인 모든 컴퓨터에 인증서를 설치한 후에는 SSL을 통해 Release Management 서버에 컴퓨터를 연결할 수 있습니다. TFS에서 HTTPS/SSL을 실행 중인 경우에는 HTTPS를 사용하도록 TFS 연결을 구성해야 합니다.

TFS 연결을 처음 설정하는 경우, 추가로 수행해야 하는 단계와 충족해야 하는 계정 권한 요구 사항이 있습니다. 자세한 내용은 TFS에 Release Management 연결을 참조하세요.

HTTPS를 사용하여 Release Management 서버에 Release Management 클라이언트 연결

1. Release Management 클라이언트를 실행합니다.

   팁

   더 이상 서버에 액세스할 수 없다는 오류 메시지가 표시되면 Release Management 클라이언트를 다시 설치하거나 명령줄 도구를 통해 새 포트와 프로토콜을 사용하여 클라이언트가 서버를 가리키도록 지정할 수 있습니다.자세한 내용은 이 블로그 게시물을 참조하세요.

2. 관리와 설정을 차례로 선택합니다.

3. Release Management 서버 URL에서 편집을 선택합니다.

4. 서비스 구성 대화 상자에서 HTTPS를 선택하고 Release Management 서버의 정규화된 도메인 이름과 SSL 포트를 입력한 후에 확인을 선택합니다. 응용 프로그램을 다시 시작해야 한다는 메시지가 표시됩니다.

HTTPS를 사용하여 Release Management 서버에 Microsoft Deployment Agent 연결

1. Microsoft Deployment Agent를 실행합니다.

2. Release Management 서버에 Release Management 서버의 URL을 입력하고 설정 적용을 선택합니다. IIS에서 설정한 포트, 서버의 정규화된 도메인 이름 및 HTTPS 프로토콜을 사용해야 합니다.

HTTPS를 사용하여 TFS에 Release Management 서버 연결

1. Release Management 클라이언트를 실행합니다.

2. 관리와 TFS 관리를 차례로 선택합니다.

3. 연결 프로토콜을 HTTPS로 변경하고 필요한 경우 포트를 업데이트한 다음 확인을 선택합니다.

클라이언트 컴퓨터 구성

사용자가 Team Foundation에 액세스하는 모든 클라이언트 컴퓨터에서 인증서를 로컬로 설치하고 해당 컴퓨터에서 Team Foundation에 액세스한 모든 사용자에 대한 클라이언트 캐시를 지워야 합니다. 그렇지 않으면 사용자가 해당 컴퓨터에서 Team Foundation에 연결할 수 없습니다. 자세한 내용은 신뢰할 수 있는 루트 인증서 관리를 참조하세요.

중요

Team Foundation Server와 하나 이상의 Team Foundation 클라이언트를 모두 실행하는 컴퓨터에서는 이 절차를 수행하지 마십시오.

클라이언트 컴퓨터에 인증서를 설치하려면

1. 해당 컴퓨터의 Administrators 그룹에 속하는 계정을 사용하여 컴퓨터에 로그온합니다.

2. 로컬 컴퓨터에 대한 신뢰할 수 있는 루트 인증 기관 폴더에 인증서를 설치합니다.

클라이언트 컴퓨터에서 캐시를 지우려면

1. 캐시를 지우려는 사용자의 자격 증명을 사용하여 컴퓨터에 로그온합니다.

2. 열려 있는 Visual Studio 인스턴스를 모두 닫습니다.

3. 브라우저 창에서 다음 폴더를 엽니다.

   Drive**:\Users\UserName\AppData\Local\Microsoft\Team Foundation\4.0\Cache**

4. Cache 디렉터리의 내용을 삭제합니다. 이때 하위 폴더도 모두 삭제해야 합니다.

5. 시작과 실행을 선택한 후 devenv /resetuserdata를 입력한 다음 확인을 선택합니다.

6. 해당 컴퓨터에서 Team Foundation에 액세스한 모든 사용자의 계정에 대해 이 단계를 반복합니다.

   참고

   사용자가 직접 캐시를 비울 수 있도록 모든 Team Foundation 사용자에게 캐시를 비우는 방법을 배포해야 할 수 있습니다.

다시 구성된 배포에 클라이언트 컴퓨터를 연결하려면

• Visual Studio에서 새 HTTPS URL을 사용하여 Team Foundation Server에 연결합니다.

  자세한 내용은 Team Foundation Server에서 팀 프로젝트에 연결을 참조하십시오.

Git 구성

기본적으로, 버전 관리에 Git를 사용하는 프로젝트는 TFS에 대해 구성한 SSL 인증서의 유효성 검사에 실패합니다. 이는 TFS 및 Visual Studio와 달리 Git가 Windows 인증서 저장소를 인식하지 못하기 때문입니다. 대신, 인증서 저장소용 OpenSSL을 사용합니다. SSL로 구성된 프로젝트에 Git 리포지토리를 사용하기 위해, TFS 2013 배포를 위한 인증 체인 루트에서 인증서로 Git를 구성해야 합니다. 이는 Git 리포지토리 프로젝트에만 적용되는 클라이언트 구성 작업입니다.

Visual Studio 2013에서 Git 네트워크 작업이 이루어지는 방법에 대한 자세한 내용은 이 블로그 게시물을 참조하세요.

팁

Windows 인증 등 다른 Git 자격 증명 관리 작업의 경우, Git용 Windows 자격 증명 저장소를 다운로드하여 설치하는 방법을 고려해 볼 수 있습니다.

Git에 대한 인증서 저장소를 구성하려면

• 해당 컴퓨터의 Administrators 그룹에 속하는 계정을 사용하여 컴퓨터에 로그온합니다.

• 위와 같이 필수적인 인증서가 컴퓨터에 설치 및 구성되었는지 확인하십시오.

• 지원되는 웹 브라우저에서 TFS 루트 인증서를 base64로 인코딩된 X.509 CER/PEM 파일로 추출합니다.

• Git 루트 인증서 저장소의 개인 복사본을 만들고 이를 저장소의 개인 사용자 복사본에 추가합니다.

스크린샷을 포함한 이 절차의 전체 연습은 Philip Kelley의 블로그를 참조하세요.

참고 항목

기타 리소스

Securing Team Foundation Server with HTTPS and Secure Sockets Layer (SSL)

Team Foundation Server, HTTPS, and Secure Sockets Layer (SSL)