소프트웨어 정의 네트워킹에 대한 인증서 관리
적용 대상: Azure Stack HCI, 버전 22H2 및 21H2; Windows Server 2022, Windows Server 2019, Windows Server 2016
이 항목을 사용하여 Windows Server 2019 또는 2016 Datacenter에서 SDN(소프트웨어 정의 네트워킹)을 배포하고 SDN 관리 클라이언트로 SCVMM(System Center Virtual Machine Manager)을 사용할 때 네트워크 컨트롤러 Northbound 및 Southbound 통신에 대한 인증서를 관리하는 방법을 알아볼 수 있습니다.
참고
네트워크 컨트롤러에 대한 개요 정보는 네트워크 컨트롤러를 참조하세요.
네트워크 컨트롤러 통신 보안을 위해 Kerberos를 사용하지 않는 경우 인증, 권한 부여 및 암호화에 X.509 인증서를 사용할 수 있습니다.
Windows Server 2019 및 2016 Datacenter의 SDN은 자체 서명된 인증서와 CA(인증 기관)에서 서명한 X.509 인증서를 모두 지원합니다. 이 항목에서는 이러한 인증서를 만들고 SLB(소프트웨어 Load Balancer)와 같은 네트워크 디바이스와의 사우스바운드 통신 및 관리 클라이언트를 사용하여 보안 네트워크 컨트롤러 Northbound 통신 채널에 적용하기 위한 단계별 지침을 제공합니다.
인증서 기반 인증을 사용하는 경우 다음과 같은 방법으로 사용되는 네트워크 컨트롤러 노드에 하나의 인증서를 등록해야 합니다.
- 네트워크 컨트롤러 노드와 System Center Virtual Machine Manager 같은 관리 클라이언트 간에 SSL(Secure Sockets Layer)을 사용하여 Northbound Communication을 암호화합니다.
- Hyper-V 호스트 및 SLL(소프트웨어 부하 분산 장치)과 같은 네트워크 컨트롤러 노드와 사우스바운드 디바이스 및 서비스 간의 인증.
X.509 인증서 만들기 및 등록
자체 서명된 인증서 또는 CA에서 발급한 인증서를 만들고 등록할 수 있습니다.
참고
SCVMM을 사용하여 네트워크 컨트롤러를 배포하는 경우 네트워크 컨트롤러 서비스 템플릿을 구성하는 동안 Northbound 통신을 암호화하는 데 사용되는 X.509 인증서를 지정해야 합니다.
인증서 구성에는 다음 값이 포함되어야 합니다.
- RestEndPoint 텍스트 상자의 값은 네트워크 컨트롤러 FQDN(정규화된 도메인 이름) 또는 IP 주소여야 합니다.
- RestEndPoint 값은 X.509 인증서의 주체 이름(일반 이름, CN)과 일치해야 합니다.
Self-Signed X.509 인증서 만들기
네트워크 컨트롤러의 단일 노드 및 다중 노드 배포에 대해 다음 단계에 따라 자체 서명된 X.509 인증서를 만들고 프라이빗 키(암호로 보호됨)로 내보낼 수 있습니다.
자체 서명된 인증서를 만들 때 다음 지침을 사용할 수 있습니다.
- DnsName 매개 변수에 네트워크 컨트롤러 REST 엔드포인트의 IP 주소를 사용할 수 있지만 네트워크 컨트롤러 노드가 모두 단일 관리 서브넷(예: 단일 랙) 내에 있어야 하므로 권장되지 않습니다.
- 여러 노드 NC 배포의 경우 지정한 DNS 이름은 네트워크 컨트롤러 클러스터의 FQDN이 됩니다(DNS 호스트 A 레코드가 자동으로 생성됨).
- 단일 노드 네트워크 컨트롤러 배포의 경우 DNS 이름은 네트워크 컨트롤러의 호스트 이름 뒤에 전체 도메인 이름이 될 수 있습니다.
다중 노드
New-SelfSignedCertificate Windows PowerShell 명령을 사용하여 자체 서명된 인증서를 만들 수 있습니다.
구문
New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("<NCRESTName>")
사용 예
New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "MultiNodeNC" -DnsName @("NCCluster.Contoso.com")
단일 노드
New-SelfSignedCertificate Windows PowerShell 명령을 사용하여 자체 서명된 인증서를 만들 수 있습니다.
구문
New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("<NCFQDN>")
사용 예
New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "SingleNodeNC" -DnsName @("SingleNodeNC.Contoso.com")
CA-Signed X.509 인증서 만들기
CA를 사용하여 인증서를 만들려면 AD CS(Active Directory Certificate Services)를 사용하여 PKI(공개 키 인프라)를 이미 배포했어야 합니다.
참고
타사 CA 또는 openssl과 같은 도구를 사용하여 네트워크 컨트롤러에서 사용할 인증서를 만들 수 있지만 이 항목의 지침은 AD CS와 관련이 있습니다. 타사 CA 또는 도구를 사용하는 방법을 알아보려면 사용 중인 소프트웨어에 대한 설명서를 참조하세요.
CA를 사용하여 인증서를 만드는 방법에는 다음 단계가 포함됩니다.
- 사용자 또는 organization 도메인 또는 보안 관리자가 인증서 템플릿을 구성합니다.
- 사용자 또는 organization 네트워크 컨트롤러 관리자 또는 SCVMM 관리자가 CA에서 새 인증서를 요청합니다.
인증서 구성 요구 사항
다음 단계에서 인증서 템플릿을 구성하는 동안 구성하는 템플릿에 다음과 같은 필수 요소가 포함되어 있는지 확인합니다.
- 인증서 주체 이름은 Hyper-V 호스트의 FQDN이어야 합니다.
- 인증서는 로컬 머신 개인 저장소(My – cert:\localmachine\my)에 배치해야 합니다.
- 인증서에는 서버 인증(EKU: 1.3.6.1.5.5.7.3.1) 및 클라이언트 인증(EKU: 1.3.6.1.5.5.7.3.2) 애플리케이션 정책이 모두 있어야 합니다.
참고
Hyper-V 호스트의 개인(My – cert:\localmachine\my) 인증서 저장소에 호스트 FQDN(정규화된 도메인 이름)으로 주체 이름(CN)이 있는 X.509 인증서가 두 개 이상 있는 경우 SDN에서 사용할 인증서에는 OID 1.3.6.1.4.1.311.95.1.1.1.1이 포함된 추가 사용자 지정 고급 키 사용 속성이 있습니다. 그렇지 않으면 네트워크 컨트롤러와 호스트 간의 통신이 제대로 작동하지 않을 수 있습니다.
인증서 템플릿을 구성 하려면
참고
이 절차를 수행하기 전에 인증서 템플릿 콘솔에서 인증서 요구 사항 및 사용 가능한 인증서 템플릿을 검토해야 합니다. 기존 템플릿을 수정하거나 기존 템플릿의 복제본을 만든 다음 템플릿의 복사본을 수정할 수 있습니다. 기존 템플릿의 복사본을 만드는 것이 좋습니다.
- AD CS가 설치된 서버의 서버 관리자 도구를 클릭한 다음 인증 기관을 클릭합니다. 인증 기관 Microsoft Management Console (MMC)가 열립니다.
- MMC에서 CA 이름을 두 번 클릭 마우스 오른쪽 단추로 클릭 인증서 템플릿, 를 클릭 하 고 관리합니다.
- 인증서 템플릿 콘솔이 열립니다. 인증서 템플릿의 모든 세부 정보 창에 표시 됩니다.
- 세부 정보 창에서 복제할 템플릿을 클릭합니다.
- 클릭 된 작업 메뉴를 차례로 클릭 중복 된 템플릿합니다. 서식 파일 속성 대화 상자가 열립니다.
- 템플릿 속성 대화 상자의 주체 이름 탭 에서 요청에서 제공을 클릭합니다. (이 설정은 네트워크 컨트롤러 SSL 인증서에 필요합니다.)
- 템플릿 속성 대화 상자의 요청 처리 탭에서 프라이빗 키를 내보낼 수 있도록 허용 이 선택되어 있는지 확인합니다. 또한 서명 및 암호화 목적이 선택되어 있는지 확인합니다.
- 템플릿 속성 대화 상자의 확장 탭에서 키 사용을 선택한 다음 편집을 클릭합니다.
- 서명에서 디지털 서명이 선택되어 있는지 확인합니다.
- 템플릿 속성 대화 상자의 확장 탭에서 애플리케이션 정책을 선택한 다음 편집을 클릭합니다.
- 애플리케이션 정책에서 클라이언트 인증 및 서버 인증이 나열되어 있는지 확인합니다.
- 인증서 템플릿의 복사본을 네트워크 컨트롤러 템플릿과 같은 고유한 이름으로 저장합니다.
CA에서 인증서를 요청하려면
인증서 스냅인을 사용하여 인증서를 요청할 수 있습니다. 인증서 요청을 처리하는 CA의 관리자가 미리 구성하고 사용할 수 있는 모든 유형의 인증서를 요청할 수 있습니다.
사용자 또는 로컬 관리자는 이 절차를 완료하는 데 필요한 최소 그룹 멤버 자격입니다.
- 컴퓨터에 대한 인증서 스냅인을 엽니다.
- 콘솔 트리에서 인증서(로컬 컴퓨터)를 클릭합니다. 개인 인증서 저장소를 선택합니다.
- 작업 메뉴에서** 모든 작업을 가리킨 다음 **새 인증서 요청을 클릭하여 인증서 등록 마법사를 시작합니다. 다음을 클릭합니다.
- 관리자가 구성한 인증서 등록 정책을 선택하고 다음을 클릭합니다.
- 이전 섹션에서 구성한 CA 템플릿에 따라 Active Directory 등록 정책을 선택합니다.
- 세부 정보 섹션을 확장하고 다음 항목을 구성합니다.
- 키 사용에디지털 서명 **과 **키 암호화가 모두 포함되어 있는지 확인합니다.
- 애플리케이션 정책에서버 인증(1.3.6.1.5.5.7.3.1) 및 클라이언트 인증(1.3.6.1.5.5.7.3.2)이 모두 포함되어 있는지 확인합니다.
- 속성을 클릭합니다.
- 제목 탭의 주체 이름에 있는 형식에서 일반 이름을 선택합니다. 값에서 네트워크 컨트롤러 REST 엔드포인트를 지정합니다.
- 적용, 확인을 차례로 클릭합니다.
- 등록을 클릭합니다.
인증서 MMC에서 개인 저장소를 클릭하여 CA에서 등록한 인증서를 확인합니다.
SCVMM 라이브러리로 인증서 내보내기 및 복사
자체 서명된 인증서 또는 CA 서명된 인증서를 만든 후 인증서 스냅인에서 프라이빗 키(.pfx 형식)와 프라이빗 키(Base-64 .cer 형식)가 없는 인증서를 내보내야 합니다.
그런 다음 내보낸 두 개의 파일을 NC 서비스 템플릿을 가져올 때 지정한 ServerCertificate.cr 및 NCCertificate.cr 폴더에 복사해야 합니다.
- 인증서 스냅인(certlm.msc)을 열고 로컬 컴퓨터의 개인 인증서 저장소에서 인증서를 찾습니다.
- 인증서를 마우스 오른쪽 단추로 클릭하고 모든 작업을 클릭한 다음 내보내기를 클릭합니다. 인증서 내보내기 마법사가 열립니다. 다음을 클릭합니다.
- 예를 선택하고 프라이빗 키 옵션을 내보내고 다음을 클릭합니다.
- 개인 정보 교환 - PKCS #12(를 선택합니다. PFX) 및 는 가능하면 인증 경로에 모든 인증서 포함 기본값을 적용합니다.
- 내보낼 인증서에 대한 사용자/그룹 및 암호를 할당하고 다음을 클릭합니다.
- 내보낼 파일 페이지에서 내보낸 파일을 저장할 위치를 찾은 다음 이름을 지정합니다.
- 마찬가지로 에서 인증서를 내보냅니다. CER 형식입니다. 참고: .CER 형식으로 내보내려면 예, 프라이빗 키 내보내기 옵션의 선택을 취소합니다.
- .PFX를 ServerCertificate.cr 폴더에 복사합니다.
- .CER 파일을 NCCertificate.cr 폴더에 복사합니다.
완료되면 SCVMM 라이브러리에서 이러한 폴더를 새로 고치고 이러한 인증서를 복사했는지 확인합니다. 네트워크 컨트롤러 서비스 템플릿 구성 및 배포를 계속 진행합니다.
사우스바운드 디바이스 및 서비스 인증
호스트 및 SLB MUX 디바이스와의 네트워크 컨트롤러 통신은 인증에 인증서를 사용합니다. 호스트와의 통신은 OVSDB 프로토콜을 통해 진행되며 SLB MUX 디바이스와의 통신은 WCF 프로토콜을 통해 진행됩니다.
네트워크 컨트롤러와 Hyper-V 호스트 통신
OVSDB를 통해 Hyper-V 호스트와 통신하려면 네트워크 컨트롤러가 호스트 컴퓨터에 인증서를 제공해야 합니다. 기본적으로 SCVMM은 네트워크 컨트롤러에 구성된 SSL 인증서를 선택하고 호스트와의 사우스바운드 통신에 사용합니다.
이것이 SSL 인증서에 클라이언트 인증 EKU가 구성되어 있어야 하는 이유입니다. 이 인증서는 "서버" REST 리소스에서 구성되며(Hyper-V 호스트는 네트워크 컨트롤러에서 서버 리소스로 표시됨) Windows PowerShell 명령 Get-NetworkControllerServer를 실행하여 볼 수 있습니다.
다음은 서버 REST 리소스의 부분 예제입니다.
"resourceId": "host31.fabrikam.com",
"properties": {
"connections": [
{
"managementAddresses": [
"host31.fabrikam.com"
],
"credential": {
"resourceRef": "/credentials/a738762f-f727-43b5-9c50-cf82a70221fa"
},
"credentialType": "X509Certificate"
}
],
상호 인증의 경우 Hyper-V 호스트에는 네트워크 컨트롤러와 통신할 인증서도 있어야 합니다.
CA(인증 기관)에서 인증서를 등록할 수 있습니다. 호스트 컴퓨터에서 CA 기반 인증서를 찾을 수 없는 경우 SCVMM은 자체 서명된 인증서를 만들어 호스트 컴퓨터에 프로비전합니다.
네트워크 컨트롤러와 Hyper-V 호스트 인증서는 서로 신뢰할 수 있어야 합니다. Hyper-V 호스트 인증서의 루트 인증서는 로컬 컴퓨터에 대한 네트워크 컨트롤러 신뢰할 수 있는 루트 인증 기관 저장소에 있어야 하며 그 반대의 경우도 마찬가지입니다.
자체 서명된 인증서를 사용하는 경우 SCVMM은 필요한 인증서가 로컬 컴퓨터의 신뢰할 수 있는 루트 인증 기관 저장소에 있는지 확인합니다.
Hyper-V 호스트에 CA 기반 인증서를 사용하는 경우 로컬 컴퓨터에 대한 네트워크 컨트롤러의 신뢰할 수 있는 루트 인증 기관 저장소에 CA 루트 인증서가 있는지 확인해야 합니다.
네트워크 컨트롤러와 소프트웨어 Load Balancer MUX 통신
소프트웨어 Load Balancer 멀티플렉서(MUX) 및 네트워크 컨트롤러는 인증을 위해 인증서를 사용하여 WCF 프로토콜을 통해 통신합니다.
기본적으로 SCVMM은 네트워크 컨트롤러에 구성된 SSL 인증서를 선택하고 Mux 디바이스와의 남향 통신에 사용합니다. 이 인증서는 "NetworkControllerLoadBalancerMux" REST 리소스에서 구성되며 PowerShell cmdlet Get-NetworkControllerLoadBalancerMux를 실행하여 볼 수 있습니다.
MUX REST 리소스의 예(부분):
"resourceId": "slbmux1.fabrikam.com",
"properties": {
"connections": [
{
"managementAddresses": [
"slbmux1.fabrikam.com"
],
"credential": {
"resourceRef": "/credentials/a738762f-f727-43b5-9c50-cf82a70221fa"
},
"credentialType": "X509Certificate"
}
],
상호 인증의 경우 SLB MUX 디바이스에 인증서도 있어야 합니다. 이 인증서는 SCVMM을 사용하여 소프트웨어 부하 분산 장치를 배포할 때 SCVMM에서 자동으로 구성됩니다.
중요
호스트 및 SLB 노드에서는 신뢰할 수 있는 루트 인증 기관 인증서 저장소에 "발급 대상"이 "발급자"와 동일하지 않은 인증서가 포함되지 않는 것이 중요합니다. 이 경우 네트워크 컨트롤러와 사우스바운드 디바이스 간의 통신이 실패합니다.
네트워크 컨트롤러와 SLB MUX 인증서는 서로 신뢰할 수 있어야 합니다(SLB MUX 인증서의 루트 인증서는 네트워크 컨트롤러 컴퓨터 신뢰할 수 있는 루트 인증 기관 저장소에 있어야 하며 그 반대의 경우도 마찬가지입니다). 자체 서명된 인증서를 사용하는 경우 SCVMM은 필요한 인증서가 로컬 컴퓨터의 신뢰할 수 있는 루트 인증 기관 저장소에 있는지 확인합니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기