XenServer 네트워크 및 스토리지 보호

XenServer 환경에서 네트워킹은 물리적 수준뿐만 아니라 논리적 수준에서도 발생합니다. 네트워크 계층 2 관점에서 XenServer는 호스트 내부(예: 개인 네트워크) 및 외부적으로 물리적 네트워크로 트래픽을 보낼 수 있는 가상 네트워크 스위치로 작동합니다.

따라서 XenServer 환경은 가상 머신(게스트) 계층, 하이퍼바이저 계층, 스토리지 네트워크를 포함한 물리적 네트워크 계층 등 모든 수준에서 보안을 유지하는 것이 중요합니다.

추천

하이퍼바이저 계층의 논리 네트워크를 포함하여 네트워크 간에 교차하는 데이터가 없는지 확인하는 것이 좋습니다.

네트워크 트래픽 분리

XenServer에는 각 풀에 (a) 관리 트래픽, (b) 스토리지 트래픽 및 (c) VM(게스트 운영 체제) 트래픽이라는 세 가지 범주의 네트워크 트래픽이 있습니다. 이 트래픽을 별도의 네트워크 또는 공유 네트워크를 통해 전송하도록 XenServer 호스트를 구성할 수 있습니다.

다음 그림에서는 서로 다른 트래픽 클래스가 서로 다른 물리적 NIC를 사용하는 이러한 분리의 예를 제공합니다.

이 그림에서는 관리 또는 스토리지 트래픽에 대해 지정되지 않은 NIC가 VM 트래픽만 전달하는 방법을 보여 줍니다.

• 관리 트래픽: XenServer는 호스트 간 트래픽, 실시간 마이그레이션, VM 가져오기 및 내보내기, 리소스 풀 메타데이터 백업을 포함한 XenServer 관리 통신에 관리 네트워크를 사용합니다. 관리 네트워크는 관리 인터페이스로 구성된 NIC에 연결된 네트워크입니다. 관리 트래픽에는 게스트 가상 시스템 간의 통신이 포함되지 않지만 관리 콘솔인 XenCenter와 관련된 트래픽은 포함됩니다.

  XenServer를 설치하면 각 호스트에 관리 네트워크가 생성되고 관리 인터페이스로 작동할 특정 NIC에 할당됩니다. XenServer를 사용하면 관리, 스토리지 및 게스트의 세 가지 트래픽 유형 모두에 대해 단일 인터페이스를 사용할 수 있습니다. 그러나 이는 가장 안전한 네트워킹 구성이 아니며 이 섹션 전체에서 설명된 대로 트래픽을 분리하는 것이 좋습니다.

• 스토리지 트래픽: 스토리지 트래픽이라는 용어는 파이버 채널 트래픽 및 IP 기반 스토리지 트래픽(예: iSCSI 소프트웨어 이니셔에이터 트래픽, NFS 트래픽 및 SMBv3 트래픽)을 나타냅니다. 그러나 이 가이드에서 자체 네트워크에 스토리지 트래픽을 배치하는 방법에 대해 설명할 때는 특히 iSCSI 및 NFS 트래픽을 참조합니다. (파이버 채널 트래픽은 기본적으로 자체 네트워크에 있습니다.) 스토리지 트래픽은 이 섹션과 다음에서 자세히 설명합니다. 가상화된 스토리지 보호.

• 게스트 트래픽: 게스트 트래픽은 게스트 가상 머신으로 또는 게스트 가상 머신에서 전송되는 트래픽을 나타냅니다.

  물리적 네트워크 분리는 추가 보안을 제공합니다. 다음 그림에 예가 나와 있습니다.

이 그림은 관리 인터페이스, 관리 통신에 사용되는 NIC 및 관리 네트워크를 보여줍니다. 관리 네트워크는 스토리지 네트워크 및 게스트 네트워크와 분리되어 있습니다.

추천:

NIC, 케이블, 스위치, 포트 및 네트워크 구성을 통해 관리, 스토리지 및 게스트 네트워크를 물리적으로 분리하고 XenServer의 구성을 통해 논리적으로 분리하는 것이 좋습니다. 여기에는 다음 섹션에 설명된 대로 관리 네트워크를 통해 게스트 트래픽을 실수로 전송하지 않도록 하는 것이 포함됩니다.

트래픽이 분리되어 있는지 확인

트래픽을 분리하는 방법을 이해하려면 VM이 통신하는 방법을 이해하는 것이 중요합니다.

VM은 NIC와 동일한 네트워크에 가상 네트워크 인터페이스가 있는 경우에만 게스트 트래픽에 NIC를 사용할 수 있습니다.

모든 NIC에 가상 네트워크 인터페이스가 연결되어 있는 것은 아닙니다. 관리 네트워크에 연결하는 가상 네트워크 인터페이스를 구성하지 않으면 관리 NIC가 관리 트래픽 전용이 됩니다. 예를 들어 이전 그림에는 해당 가상 네트워크 인터페이스가 없는 관리 및 스토리지 네트워크에 연결된 NIC가 있습니다.

이전 그림에서는 게스트 네트워크에 대한 가상 네트워크 인터페이스만 있는 VM을 보여 줍니다. VM이 관리 또는 스토리지 네트워크에 연결되어 있지 않음: VM에는 해당 네트워크에 연결되는 가상 네트워크 인터페이스가 없습니다.

추천:

프로덕션 네트워크를 스테이징, 테스트 및 개발 네트워크에서 격리하는 것이 좋습니다.

별도의 스토리지 네트워크 계획

추천

IP 기반 스토리지 트래픽에 대한 추가 스토리지 인터페이스를 구성하고 해당 인터페이스를 통해 스토리지에 액세스하도록 XenServer를 구성하여 트래픽을 분리하는 것이 좋습니다. (그러나 그런 다음 게스트 네트워크를 물리적으로 격리하고 가상 머신을 구성하여 격리된 네트워크만 사용하도록 해야 합니다.) 추가 인터페이스는 일부 문헌에서 보조 인터페이스라고도 합니다.

별도의 스토리지 네트워크를 만드는 전체 프로세스는 다음과 같습니다.

1. 서로 다른 트래픽이 서로 다른 서브넷에 있도록 물리적 네트워크 인프라를 구성합니다.
2. 새 네트워크를 사용하기 위한 스토리지 인터페이스를 생성합니다.

원하는 경우 위의 단계 중에 다중 경로 지정 또는 본딩으로 중복을 구성하는 것이 좋습니다.

위의 프로세스를 따르면 다음과 같은 경우 IP 기반 트래픽에 대해 별도의 네트워크를 설정할 수 있습니다.

• 다른 용도로(예: 가상 네트워크 인터페이스를 이 네트워크에 연결) 이 네트워크를 사용하도록 XenServer를 구성하지 않습니다.
• 적절한 물리적 네트워크 구성이 마련되어 있습니다.

예를 들어 NIC를 스토리지 트래픽 전용으로 사용하려면 할당된 NIC를 통해서만 대상에 액세스할 수 있도록 NIC, 스토리지 대상, 스위치 및/또는 VLAN을 구성해야 합니다.

스토리지 트래픽이 관리 트래픽과 분리되도록 하려면 스토리지 네트워크가 다른 서브넷에 있어야 합니다. 스토리지의 서브넷은 관리 인터페이스에서 “라우팅”할 수 없는 별도의 IP 서브넷이어야 합니다. 물리적 또는 논리적 구성에서 트래픽 분리를 적용하지 않는 경우 XenServer가 NIC를 초기화하는 순서에 따라 XenServer가 호스트 재부팅 후 관리 인터페이스를 통해 스토리지 트래픽을 전달할 수 있습니다.

별도의 게스트 네트워크 계획

추천

• 게스트 네트워크만 갖도록 모든 VM을 구성하는 것이 좋습니다. VM은 아래에 설명된 대로 스토리지 및 관리 네트워크에 액세스할 필요가 없습니다.

• 게스트 네트워크를 올바르게 구성하여 실수로 관리 및 스토리지 네트워크를 통해 트래픽을 전송하지 않도록 하는 것이 좋습니다.

  • 게스트 네트워크가 관리 및 스토리지 트래픽과 물리적으로 격리되어 있는지 확인합니다. VM이 게스트 트래픽에 사용할 NIC를 VM 트래픽에만 사용할 스위치 포트에 연결합니다. 이 포트는 스토리지 및 관리 네트워크에서 물리적으로 격리되어야 합니다.
  • NIC와 동일한 네트워크에 가상 네트워크 인터페이스를 만듭니다.
  • 게스트 트래픽 이외의 어떤 유형의 트래픽도 해당 NIC를 통해 라우팅하지 마십시오.
  • VM을 생성할 때 NIC 0에서 관리 인터페이스를 구성한 경우 다음 절차에 설명된 대로 VM을 생성할 때 VM 마법사에서 NIC 0을 사용하도록 설정하지 않았는지 확인합니다.

• 대안: 호스트에 게스트 트래픽 전용 NIC가 하나만 있는 경우 트래픽을 별도의 논리 네트워크로 분리하는 것이 좋습니다. 예를 들어, 일반적인 구성은 응용 프로그램 서버가 “프론트 엔드” 트래픽(예: 웹 서버) 및 “백 엔드” 트래픽(예: 데이터베이스)을 관리하는 것입니다. 이 작업은 VLAN을 사용하여 수행할 수 있습니다. VLAN은 이더넷 트래픽에 개별적으로 태그를 지정하지만 트래픽은 여전히 호스트의 동일한 물리적 NIC를 통과합니다.

• 제어 도메인에 스토리지 네트워크 및 격리된 관리 네트워크 이외의 네트워크에 대한 IP 주소를 할당하지 않는 것이 좋습니다. 제어 도메인 IP 주소가 있는 네트워크에 게스트 VM 트래픽을 배치하지 마세요.

• 조직에서 제어할 수 없는 네트워크(예: 인터넷)에 연결하는 게스트 네트워크가 있는 경우 네트워크의 로컬 세그먼트가 보호되고 있는지 확인하는 것이 좋습니다. 보호되지 않는 네트워크는 공격 대상과 동일한 스위치에서 수행해야 하는 가짜 DHCP 공격과 같은 레벨 2 네트워크 공격에 취약할 수 있습니다.
• 인터넷 액세스가 필요한 VM과 그렇지 않은 VM이 있는 경우 인터넷 액세스가 필요하지 않은 VM이 인터넷의 가능한 공격에 직접 노출되지 않도록 별도의 네트워크를 구성하는 것이 좋습니다.

게스트 네트워크로만 VM을 구성하려면

메모:

에 설명된 대로 네트워크 이름을 변경하여 명확한 이름을 할당하는 경우 이 절차를 더 쉽게 수행할 수 있습니다. 네트워크 이름을 명확하게 지정.

1. XenCenter를 시작한 후 새 VM 마법사 (가상 머신 > 새 VM)에 도달할 때까지 프롬프트를 따릅니다. 네트워킹 페이지.

2. 에 네트워킹 페이지에서 VM이 사용하지 않을 모든 네트워크를 제거합니다. 제거할 네트워크를 선택하고 삭제하다.

   

   기본적으로 XenServer 설치는 네트워크 0(일반적으로 NIC0)에서 관리 인터페이스를 구성합니다.

   결과 네트워크는 다음과 같을 수 있습니다.

   

3. 필요한 경우 속성 QoS 설정 또는 가상 MAC 주소를 구성합니다.

   중요:

   이 대화 상자에 표시되는 모든 가상 네트워크 인터페이스는 가상 컴퓨터에서 네트워크로 만들어집니다.

네트워크 이름을 명확하게 지정

추천

관리 네트워크와 같이 액세스 권한이 없어야 하는 네트워크에 게스트를 실수로 연결하는 것을 방지하기 위해 구성에 의미 있는 명확한 이름을 갖도록 기본 네트워크의 이름을 바꾸는 것이 좋습니다.

예를 들어 XenServer가 NIC에 할당하는 기본 이름을 사용자 환경에서 NIC가 수행하는 기능을 나타내는 이름으로 변경합니다.

네트워크 이름을 변경하려면

안에 네트워킹 탭을 클릭하고 네트워크를 선택한 후 속성, 다음 화면 캡처에 표시된 대로 다음을 수행합니다.

이 화면 캡처에는 명확성을 위해 기본 이름에서 변경된 네트워크 이름이 표시됩니다. 설명 열에 네트워크에 대한 정보를 추가할 수도 있습니다.

다음 명령을 실행하여 네트워크 이름을 변경할 수도 있습니다.

  # xe network-param-set uuid=<network uuid> name-label="<new network name>"
<!--NeedCopy-->

예를 들어 네트워크 1에 “스토리지 네트워크”라는 이름을 할당하려면 다음을 실행합니다.

  # xe network-param-set uuid=213e396e-1e1f-0744-7a43-64c3e9dfd649 \ name-label="Storage Network"
<!--NeedCopy-->

name-label 매개 변수를 사용하는 것은 XenCenter에서 네트워크 이름을 바꾸는 것과 같습니다.

팁:

네트워크 UUID를 얻으려면 다음을 실행합니다. xe 네트워크 목록.

관리 네트워크 보호

이 네트워크는 호스트에 연결된 모든 구성 요소에 대한 액세스를 제공할 수 있으므로 관리 네트워크를 보호하는 것이 중요합니다. XenServer 8.4 호스트와 XenCenter 및 다른 XenServer 8.4 호스트 간의 통신은 포트 443에 대한 (암호화된) TLS 연결을 통해 이루어집니다. 그러나 XenServer 관리 기능은 포트 80(암호화되지 않음) 및 포트 443(TLS 암호화됨)에서 관리 API 요청을 수신합니다. 이를 통해 이전 버전의 제품 및 기타(예: 제3자) 제품.

추천

TLS를 사용할 수 없는 타사 관리 API 에이전트가 없는 경우 CLI 명령을 사용하여 포트 80에 대한 액세스를 차단하는 것이 좋습니다. xe 풀-param-set uuid=<pool uuid> https 전용=참.

예를 들어, 이전 버전의 제품에서 XenServer 8.4 호스트로 VM을 마이그레이션해야 하는 경우와 같이 이 명령을 반대로 실행해야 하는 경우 다음 CLI 명령을 사용하여 해당 작업을 수행할 수 있습니다. xe pool-param-set uuid=<pool uuid> https-only=false.

IP 주소가 바인딩되지 않도록 관리 인터페이스를 구성할 수 있습니다. 그러나 이는 어떤 관리 기능도 XenServer 호스트의 로컬 콘솔 외부에서 작동하지 않음을 의미합니다. 이 구성에서는 리소스 풀을 만들거나, VM을 가져오거나 내보내거나, 이메일 경고와 같은 기능을 활용할 수 없습니다.

스위치 포트 잠금 구성

신뢰할 수 없는 게스트 VM이 있는 환경에서는 스푸핑 보호와 같은 보안 조치를 사용하여 VM이 네트워크를 통해 다른 가상 머신을 공격할 수 있는 기능을 줄이는 것이 바람직할 수 있습니다.

추천

• 잠재적으로 적대적이거나 알 수 없는 게스트 트래픽이 있는 환경에서는 XenServer 스위치 포트 잠금 기능을 구성하는 것이 좋습니다.
• 스위치 포트 잠금 기능을 사용하여 개별 VM이 트래픽을 보낼 수 있는 특정 IP 주소를 정의하는 것이 좋습니다.
• XenServer 스위치 포트 잠금 기능을 사용하면 알 수 없거나, 신뢰할 수 없거나, 잠재적으로 적대적인 VM이 할당되지 않은 MAC 또는 IP 주소가 있는 것처럼 가장하는 기능을 제한하여 VM에서 전송되는 트래픽을 제어할 수 있습니다.
• (a) 중요한 데이터가 포함된 VM과 (b) 신뢰할 수 없는 VM이 모두 있는 환경에서는 스위치 포트 잠금 기능을 사용하여 신뢰할 수 없는 VM이 스푸핑된 트래픽을 중요한 VM으로 보내지 못하도록 하는 것이 좋습니다.

XenServer 스위치 포트 잠금 기능은 각 VM에 인터넷에 연결된 공용 IP 주소가 있는 네트워크 아키텍처가 있는 배포를 지원할 수 있습니다. 스위치 포트 잠금에 대한 자세한 내용은 제품 문서.

물리적 네트워크 보안

추천

• 관리 인터페이스를 게스트 네트워크에 실수로 케이블로 연결하지 않도록 예방 조치를 취하는 것이 좋습니다. 예를 들어:
  • 모든 풀의 모든 호스트에서 동일한 네트워크에서 사용하기 위해 동일한 NIC를 일관되게 지정하는 것이 좋습니다.
  • 여러 풀이 있는 환경에서는 항상 특정 유형의 트래픽에 대해 특정 포트를 지정하고 이러한 포트를 일관되게 사용하는 것이 좋습니다. 예를 들어 모든 풀에서 항상 관리 네트워크에는 첫 번째 네트워크 포트를 사용하고, 스토리지 네트워크에는 두 번째 네트워크 포트를 사용합니다.
  • 조직에 아직 케이블링 표준이 없는 경우 케이블에 레이블을 지정하거나 색상을 구분하여 용도를 표시하는 것이 좋습니다.

• 물리적 스위치를 재사용할 때는 이전 구성을 모두 지우는 것이 좋습니다.

  이전 암호 또는 구성은 잠재적으로 환경을 적대적인 엔터티 또는 트래픽에 노출시킬 수 있습니다. 예를 들어, 누군가 트래픽을 다른 사이트나 네트워크로 자동으로 라우팅하도록 스위치를 구성했을 수 있습니다.

• 네트워크가 위치한 물리적 영역의 보안을 포함하여 네트워크의 물리적 위치를 보호하는 것이 좋습니다.

가상화된 스토리지 보호

데이터 스토리지는 물리적 스토리지 장치와 결과 가상화된 스토리지 장치(또는 디스크) 간에 일대일 관계가 없는 경우 가상화된 것으로 간주됩니다. 예를 들어, 하나의 물리적 저장 장치가 하나 이상의 가상화된 저장 장치로 사용자에게 제공되거나 그 반대로 여러 물리적 장치가 하나의 가상 디스크로 제공되는 경우입니다. 데이터 스토리지를 가상화하면 복잡성에 대한 사용자의 인식이 줄어들지만 스토리지가 안전하게 가상화되도록 하는 것이 중요합니다.

가상화된 스토리지를 보호하고 모니터링하려는 기업의 경우 가상화된 스토리지가 여러 물리적 위치에 동시에 상주할 수 있다는 점에 주목할 가치가 있습니다.

추천

• 디스크의 물리적 보안을 결정할 때 가상화되는 모든 물리적 드라이브의 위치를 고려하고 물리적으로 위험이 있는 위치에 디스크를 배치하지 않는 것이 좋습니다.
• 예를 들어, 원래 SR의 공간이 부족하여 다른 SR을 추가하고 새 SR이 다른 물리적 위치(예: 동일한 머신룸에 있지 않을 수 있는 서버)에 있는 경우 두 위치가 모두 물리적으로 안전한지 확인합니다.

전용 스토리지 NIC에는 기본 관리 인터페이스와 다른 IP 서브넷에 있어야 하는 IP 주소가 필요합니다. XenCenter를 사용하여 스토리지 NIC를 전용으로 사용할 수 있으며 복원력을 위해 여러 NIC를 함께 연결할 수도 있습니다.

추천

• 스토리지 트래픽을 관리 트래픽에서 격리하는 것이 좋습니다. NFS 또는 iSCSI SR과 같은 IP 기반 저장 장치를 사용하는 경우 저장소 트래픽도 XenServer 제어 도메인을 통해 흐릅니다.
• 스토리지 유형에 적합한 경우 대상 및 호스트 인증을 구성하는 것이 좋습니다. 이렇게 하면 스토리지 네트워크가 조직의 신뢰할 수 없는 다른 부분에 노출된 경우 데이터를 보호하는 데 도움이 됩니다. 스토리지 네트워크에 대한 내부 공격을 통해 적대적인 당사자가 스토리지로 향하는 모든 데이터를 가로챌 수 있습니다. 이러한 데이터는 가상 환경의 무결성을 손상시킬 수 있는 데이터부터 가상 머신에 포함된 중요한 데이터에 이르기까지 다양합니다.

엔프에스

파일 기반 NFS 스토리지 저장소는 제어 도메인에 지정된 NFS 저장소를 마운트합니다. 각 SR은 원격 NFS 서버의 디렉토리로 표시되며, 각 가상 디스크는 VHD 파일 형식으로 저장된 해당 디렉토리의 파일입니다.

추천

• VHD는 암호화된 파일 형식이 아니기 때문에 권한이 부여된 XenServer 호스트와 권한이 있는 관리자만 파일 시스템을 탑재할 수 있도록 하는 것이 좋습니다. 특정 IP 주소로 내보내기를 제한하여 올바른 XenServer 호스트만 파일 시스템을 마운트할 수 있도록 할 수 있습니다. 내보내기 제한은 일반적으로 NFS 스토리지 시스템을 설정할 때 수행됩니다.
• 원격 저장 장치의 저장 인터페이스가 전용 저장 네트워크 외부에서 보이지 않도록 하는 것이 좋습니다.
• NFSv4 AUTH_SYS 호스트 인증을 활성화하는 것이 좋습니다.

iSCSI 소프트웨어 이니시에이터

iSCSI 트래픽의 경우 XenServer는 OpenISCSI 초기자 소프트웨어를 사용하여 iSCSI 대상에 연결합니다.

iSCSI 스토리지 네트워크를 다른 XenServer 풀 또는 XenServer 이외의 시스템과 공유하는 경우 iSCSI 스토리지 트래픽을 VLAN과 분리하는 것이 좋습니다.

추천:

• XenServer 풀이 여러 개 있는 경우 신뢰 수준이 서로 다른 풀 간에 iSCSI 스토리지 네트워크를 공유하지 않는 것이 좋습니다. 예를 들어 프로덕션 서버 풀과 테스트 서버 풀은 스토리지 네트워크를 공유해서는 안 됩니다.
• GFS2를 사용하지 않는 한 CHAP 대상 및 호스트 인증을 구성하는 것이 좋습니다.

파이버 채널

추천:

• 파이버 채널 트래픽을 보호하기 위해 SAN에서 LUN 마스킹을 활성화하는 것이 좋습니다.

  LUN 마스킹은 특정 HBA의 요청만 수락하도록 LUN을 구성하는 방법으로, 일부 호스트에서는 LUN을 사용할 수 있고 다른 호스트에서는 사용할 수 없습니다. LUN 마스킹은 대상을 스캔할 때 LUN이 감지되지 않도록 보호합니다. HBA 구성에 따라 LUN 마스킹을 통해 SAN의 볼륨에 액세스할 수 있는 호스트를 제어할 수 있습니다. LUN 마스킹을 사용하면 지정된 호스트가 감지할 수 있는 정확한 LUN을 구성할 수 있습니다.

• 파이버 채널 트래픽을 분리하고 보호하기 위해 SAN에 영역을 만드는 것이 좋습니다.

  SAN 영역 지정은 스토리지 패브릭의 물리적 구성을 통해 파이버 채널 장치를 논리적으로 그룹화하는 방법입니다. 더 취약한 서버(예: 웹 서버 또는 인터넷 트래픽이 많은 기타 서버)의 스토리지 트래픽을 다른 서버의 스토리지 트래픽과 분리하기 위해 SAN 영역 지정을 구현하는 것이 좋습니다.

  영역은 영역 외부의 장치와 영역 내의 장치를 효과적으로 격리하고 영역 외부의 장치가 영역 내의 장치를 감지하지 못하도록 합니다. 구역화는 파이버 채널 스위치에 의해 패브릭에서 구현되기 때문에 구역화는 장치 간의 트래픽을 제어할 수 있으며 본질적으로 SAN에 대한 액세스 제어 방법을 제공할 수 있습니다. 또한 영역은 영역 트래픽이 다른 영역의 트래픽과 격리되기 때문에 보안을 제공하며, 이로 인해 성공적인 공격에서 손상된 트래픽의 양이 제한됩니다.

중소기업

SMB 스토리지 네트워크를 다른 XenServer 풀 또는 XenServer 이외의 시스템과 공유하는 경우 SMB 스토리지 트래픽을 VLAN과 분리하는 것이 좋습니다.

추천:

• XenServer 풀이 여러 개 있는 경우 신뢰 수준이 서로 다른 풀 간에 SMB 저장소 네트워크를 공유하지 않는 것이 좋습니다. 예를 들어 프로덕션 서버 풀과 테스트 서버 풀은 스토리지 네트워크를 공유해서는 안 됩니다.
• SMB 사용자 이름/암호 호스트 인증을 구성하는 것이 좋습니다.