네트워크 컨트롤러 보안
적용 대상: Azure Stack HCI, 버전 22H2 및 21H2; Windows Server 2022, Windows Server 2019, Windows Server 2016
이 항목에서는 네트워크 컨트롤러 와 다른 소프트웨어 및 디바이스 간의 모든 통신에 대한 보안을 구성하는 방법을 알아봅니다.
보호할 수 있는 통신 경로에는 관리 평면의 Northbound 통신, 클러스터의 VM(네트워크 컨트롤러 가상 머신) 간의 클러스터 통신 및 데이터 평면의 Southbound 통신이 포함됩니다.
노스바운드 통신. 네트워크 컨트롤러는 WINDOWS POWERSHELL 및 SCVMM(System Center Virtual Machine Manager)과 같은 SDN 지원 관리 소프트웨어와 관리 평면에서 통신합니다. 이러한 관리 도구는 실제 네트워크 구성을 비교하여 실제 구성을 목표 상태와 패리티로 가져올 수 있는 네트워크 정책을 정의하고 네트워크에 대한 목표 상태를 만드는 기능을 제공합니다.
네트워크 컨트롤러 클러스터 통신. 네트워크 컨트롤러 클러스터 노드로 3개 이상의 VM을 구성하는 경우 이러한 노드는 서로 통신합니다. 이 통신은 노드 간 데이터 동기화 및 복제 또는 네트워크 컨트롤러 서비스 간의 특정 통신과 관련이 있을 수 있습니다.
Southbound Communication. 네트워크 컨트롤러는 SDN 인프라 및 소프트웨어 부하 분산 장치, 게이트웨이 및 호스트 머신과 같은 기타 디바이스와 데이터 평면에서 통신합니다. 네트워크 컨트롤러를 사용하여 네트워크에 대해 구성한 목표 상태를 유지하도록 이러한 사우스바운드 디바이스를 구성하고 관리할 수 있습니다.
노스바운드 통신
네트워크 컨트롤러는 Northbound 통신에 대한 인증, 권한 부여 및 암호화를 지원합니다. 다음 섹션에서는 이러한 보안 설정을 구성하는 방법에 대한 정보를 제공합니다.
인증
네트워크 컨트롤러 Northbound 통신에 대한 인증을 구성할 때 네트워크 컨트롤러 클러스터 노드 및 관리 클라이언트가 통신하는 디바이스의 ID를 확인할 수 있도록 허용합니다.
네트워크 컨트롤러는 관리 클라이언트와 네트워크 컨트롤러 노드 간에 다음 세 가지 인증 모드를 지원합니다.
참고
System Center Virtual Machine Manager 사용하여 네트워크 컨트롤러를 배포하는 경우 Kerberos 모드만 지원됩니다.
Kerberos. 관리 클라이언트와 모든 네트워크 컨트롤러 클러스터 노드를 Active Directory 도메인에 조인할 때 Kerberos 인증을 사용합니다. Active Directory 도메인에는 인증에 사용되는 도메인 계정이 있어야 합니다.
X509. Active Directory 도메인에 가입되지 않은 관리 클라이언트의 경우 인증서 기반 인증에 X509를 사용합니다. 모든 네트워크 컨트롤러 클러스터 노드 및 관리 클라이언트에 인증서를 등록해야 합니다. 또한 모든 노드 및 관리 클라이언트는 서로의 인증서를 신뢰해야 합니다.
없음. 테스트 환경에서 테스트 목적으로 None을 사용하므로 프로덕션 환경에서는 사용하지 않는 것이 좋습니다. 이 모드를 선택하면 노드와 관리 클라이언트 간에 인증이 수행되지 않습니다.
ClientAuthentication 매개 변수와 함께 Windows PowerShell 명령 Install-NetworkController를 사용하여 Northbound 통신에 대한 인증 모드를 구성할 수 있습니다.
권한 부여
네트워크 컨트롤러 Northbound 통신에 대한 권한 부여를 구성할 때 네트워크 컨트롤러 클러스터 노드 및 관리 클라이언트가 통신하는 디바이스가 신뢰할 수 있고 통신에 참여할 수 있는 권한이 있는지 확인할 수 있습니다.
네트워크 컨트롤러에서 지원하는 각 인증 모드에 대해 다음 권한 부여 방법을 사용합니다.
Kerberos. Kerberos 인증 방법을 사용하는 경우 Active Directory에서 보안 그룹을 만든 다음 권한 있는 사용자 및 컴퓨터를 그룹에 추가하여 네트워크 컨트롤러와 통신할 권한이 있는 사용자 및 컴퓨터를 정의합니다. Install-NetworkController Windows PowerShell 명령의 ClientSecurityGroup 매개 변수를 사용하여 권한 부여에 보안 그룹을 사용하도록 네트워크 컨트롤러를 구성할 수 있습니다. 네트워크 컨트롤러를 설치한 후 Set-NetworkController 명령을 매개 변수 -ClientSecurityGroup과 함께 사용하여 보안 그룹을 변경할 수 있습니다. SCVMM을 사용하는 경우 배포 중에 보안 그룹을 매개 변수로 제공해야 합니다.
X509. X509 인증 방법을 사용하는 경우 네트워크 컨트롤러는 인증서 지문이 네트워크 컨트롤러에 알려진 관리 클라이언트의 요청만 수락합니다. Install-NetworkController Windows PowerShell 명령의 ClientCertificateThumbprint 매개 변수를 사용하여 이러한 지문을 구성할 수 있습니다. Set-NetworkController 명령을 사용하여 언제든지 다른 클라이언트 지문을 추가할 수 있습니다.
없음. 이 모드를 선택하면 노드와 관리 클라이언트 간에 인증이 수행되지 않습니다. 테스트 환경에서 테스트 목적으로 None을 사용하므로 프로덕션 환경에서는 사용하지 않는 것이 좋습니다.
암호화
Northbound 통신은 SSL(Secure Sockets Layer)을 사용하여 관리 클라이언트와 네트워크 컨트롤러 노드 간에 암호화된 채널을 만듭니다. Northbound 통신용 SSL 암호화에는 다음 요구 사항이 포함됩니다.
모든 네트워크 컨트롤러 노드에는 EKU(고급 키 사용) 확장의 서버 인증 및 클라이언트 인증 용도를 포함하는 동일한 인증서가 있어야 합니다.
관리 클라이언트가 네트워크 컨트롤러와 통신하는 데 사용하는 URI는 인증서 주체 이름이어야 합니다. 인증서 주체 이름에는 FQDN(정규화된 도메인 이름) 또는 네트워크 컨트롤러 REST 엔드포인트의 IP 주소가 포함되어야 합니다.
네트워크 컨트롤러 노드가 서로 다른 서브넷에 있는 경우 인증서의 주체 이름은 Install-NetworkController Windows PowerShell 명령의 RestName 매개 변수에 사용되는 값과 동일해야 합니다.
모든 관리 클라이언트는 SSL 인증서를 신뢰해야 합니다.
SSL 인증서 등록 및 구성
네트워크 컨트롤러 노드에 SSL 인증서를 수동으로 등록해야 합니다.
인증서가 등록되면 Install-NetworkController Windows PowerShell 명령의 -ServerCertificate 매개 변수와 함께 인증서를 사용하도록 네트워크 컨트롤러를 구성할 수 있습니다. 네트워크 컨트롤러를 이미 설치한 경우 Set-NetworkController 명령을 사용하여 언제든지 구성을 업데이트할 수 있습니다.
참고
SCVMM을 사용하는 경우 인증서를 라이브러리 리소스로 추가해야 합니다. 자세한 내용은 VMM 패브릭에서 SDN 네트워크 컨트롤러 설정을 참조하세요.
네트워크 컨트롤러 클러스터 통신
네트워크 컨트롤러는 네트워크 컨트롤러 노드 간의 통신을 위한 인증, 권한 부여 및 암호화를 지원합니다. 통신은 WCF( Windows Communication Foundation ) 및 TCP를 통해 이루어집니다.
Install-NetworkControllerCluster Windows PowerShell 명령의 ClusterAuthentication 매개 변수를 사용하여 이 모드를 구성할 수 있습니다.
자세한 내용은 Install-NetworkControllerCluster를 참조하세요.
인증
네트워크 컨트롤러 클러스터 통신에 대한 인증을 구성하면 네트워크 컨트롤러 클러스터 노드가 통신하는 다른 노드의 ID를 확인할 수 있습니다.
네트워크 컨트롤러는 네트워크 컨트롤러 노드 간에 다음과 같은 세 가지 인증 모드를 지원합니다.
참고
SCVMM을 사용하여 네트워크 컨트롤러를 배포하는 경우 Kerberos 모드만 지원됩니다.
Kerberos. 모든 네트워크 컨트롤러 클러스터 노드가 인증에 사용되는 도메인 계정을 사용하여 Active Directory 도메인에 조인될 때 Kerberos 인증을 사용할 수 있습니다.
X509. X509는 인증서 기반 인증입니다. 네트워크 컨트롤러 클러스터 노드가 Active Directory 도메인에 가입되지 않은 경우 X509 인증을 사용할 수 있습니다. X509를 사용하려면 모든 네트워크 컨트롤러 클러스터 노드에 인증서를 등록해야 하며 모든 노드는 인증서를 신뢰해야 합니다. 또한 각 노드에 등록된 인증서의 주체 이름은 노드의 DNS 이름과 동일해야 합니다.
없음. 이 모드를 선택하면 네트워크 컨트롤러 노드 간에 인증이 수행되지 않습니다. 이 모드는 테스트 목적으로만 제공되며 프로덕션 환경에서는 사용하지 않는 것이 좋습니다.
권한 부여
네트워크 컨트롤러 클러스터 통신에 대한 권한 부여를 구성할 때 네트워크 컨트롤러 클러스터 노드가 통신하는 노드가 신뢰할 수 있고 통신에 참여할 수 있는 권한이 있는지 확인할 수 있습니다.
네트워크 컨트롤러에서 지원하는 각 인증 모드에 대해 다음 권한 부여 방법이 사용됩니다.
Kerberos. 네트워크 컨트롤러 노드는 다른 네트워크 컨트롤러 컴퓨터 계정의 통신 요청만 수락합니다. New-NetworkControllerNodeObject Windows PowerShell 명령의 Name 매개 변수를 사용하여 네트워크 컨트롤러를 배포할 때 이러한 계정을 구성할 수 있습니다.
X509. 네트워크 컨트롤러 노드는 다른 네트워크 컨트롤러 컴퓨터 계정의 통신 요청만 수락합니다. New-NetworkControllerNodeObject Windows PowerShell 명령의 Name 매개 변수를 사용하여 네트워크 컨트롤러를 배포할 때 이러한 계정을 구성할 수 있습니다.
없음. 이 모드를 선택하면 네트워크 컨트롤러 노드 간에 권한 부여가 수행되지 않습니다. 이 모드는 테스트 목적으로만 제공되며 프로덕션 환경에서는 사용하지 않는 것이 좋습니다.
암호화
네트워크 컨트롤러 노드 간의 통신은 WCF 전송 수준 암호화를 사용하여 암호화됩니다. 이 암호화 형식은 인증 및 권한 부여 방법이 Kerberos 또는 X509 인증서일 때 사용됩니다. 자세한 내용은 다음 항목을 참조하십시오.
사우스바운드 통신
네트워크 컨트롤러는 사우스바운드 통신을 위해 다양한 유형의 디바이스와 상호 작용합니다. 이러한 상호 작용은 서로 다른 프로토콜을 사용합니다. 이 때문에 네트워크 컨트롤러가 디바이스와 통신하는 데 사용하는 디바이스 및 프로토콜 유형에 따라 인증, 권한 부여 및 암호화에 대한 요구 사항이 다릅니다.
다음 표에서는 다른 사우스바운드 디바이스와의 네트워크 컨트롤러 상호 작용에 대한 정보를 제공합니다.
| 사우스바운드 디바이스/서비스 | 프로토콜 | 사용된 인증 |
|---|---|---|
| 소프트웨어 부하 분산 장치 | WCF(MUX), TCP(호스트) | 인증서 |
| 방화벽 | OVSDB | 인증서 |
| 게이트웨이 | WinRM | Kerberos, 인증서 |
| 가상 네트워킹 | OVSDB, WCF | 인증서 |
| 사용자 정의 라우팅 | OVSDB | 인증서 |
이러한 각 프로토콜에 대해 통신 메커니즘은 다음 섹션에 설명되어 있습니다.
인증
Southbound 통신의 경우 다음 프로토콜 및 인증 방법이 사용됩니다.
WCF/TCP/OVSDB. 이러한 프로토콜의 경우 X509 인증서를 사용하여 인증을 수행합니다. 네트워크 컨트롤러와 피어 SLB(소프트웨어 부하 분산) MUX(멀티플렉서)/호스트 컴퓨터는 상호 인증을 위해 서로 인증서를 제공합니다. 각 인증서는 원격 피어에서 신뢰할 수 있어야 합니다.
사우스바운드 인증의 경우 Northbound 클라이언트와의 통신을 암호화하도록 구성된 동일한 SSL 인증서를 사용할 수 있습니다. 또한 SLB MUX 및 호스트 디바이스에서 인증서를 구성해야 합니다. 인증서 주체 이름은 디바이스의 DNS 이름과 동일해야 합니다.
WinRM. 이 프로토콜의 경우 인증은 Kerberos(도메인에 가입된 컴퓨터의 경우)를 사용하고 인증서(도메인에 가입되지 않은 컴퓨터의 경우)를 사용하여 수행됩니다.
권한 부여
Southbound 통신의 경우 다음 프로토콜 및 권한 부여 방법이 사용됩니다.
WCF/TCP. 이러한 프로토콜의 경우 권한 부여는 피어 엔터티의 주체 이름을 기반으로 합니다. 네트워크 컨트롤러는 피어 디바이스 DNS 이름을 저장하고 권한 부여에 사용합니다. 이 DNS 이름은 인증서에 있는 디바이스의 주체 이름과 일치해야 합니다. 마찬가지로 네트워크 컨트롤러 인증서는 피어 디바이스에 저장된 네트워크 컨트롤러 DNS 이름과 일치해야 합니다.
WinRM. Kerberos를 사용하는 경우 WinRM 클라이언트 계정은 Active Directory의 미리 정의된 그룹 또는 서버의 로컬 관리자 그룹에 있어야 합니다. 인증서를 사용하는 경우 클라이언트는 서버가 주체 이름/발급자를 사용하여 권한을 부여하는 인증서를 서버에 제공하고 서버는 매핑된 사용자 계정을 사용하여 인증을 수행합니다.
OVSDB. 권한 부여는 피어 엔터티의 주체 이름을 기반으로 합니다. 네트워크 컨트롤러는 피어 디바이스 DNS 이름을 저장하고 권한 부여에 사용합니다. 이 DNS 이름은 인증서에 있는 디바이스의 주체 이름과 일치해야 합니다.
암호화
Southbound 통신의 경우 프로토콜에 다음 암호화 방법이 사용됩니다.
WCF/TCP/OVSDB. 이러한 프로토콜의 경우 클라이언트 또는 서버에 등록된 인증서를 사용하여 암호화를 수행합니다.
WinRM. WinRM 트래픽은 기본적으로 Kerberos SSP(보안 지원 공급자)를 사용하여 암호화됩니다. WinRM 서버에서 추가 암호화를 SSL 형식으로 구성할 수 있습니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기