CISCO HyperFlex HX 데이터 플랫폼 지침

디스크 암호화/복호화는 드라이브 하드웨어에서 처리되므로 전체 시스템 성능에 영향을 미치지 않습니다.
규정 준수 기준에 대한 특정 요구 사항이 있는 경우 HX SED 암호화 드라이브는 드라이브 제조업체의 FIPS 140-2 레벨 2 기준을 충족하는 반면, 플랫폼의 HX Encryption은 FIPS 140-2 레벨 1 기준을 충족한다는 점을 알아두십시오.

개별 VM을 암호화해야 하는 경우 Hytrust 또는 Vormetric의 투명한 클라이언트와 같은 타사 소프트웨어를 사용하는 것을 고려하세요. 또는 vSphere 3에 도입된 VMware의 기본 VM 암호화를 활용할 수 있습니다.
HX SED 기반 암호화에 VM 암호화 클라이언트를 사용하면 데이터가 두 번 암호화된다는 점을 명심하세요.

HX 복제는 암호화되지 않으므로 안전한 복제를 위해 HX 클러스터가 신뢰할 수 있는 네트워크나 암호화된 터널을 통해 연결되었는지 확인하세요.

HX 보안 암호화 FAQ

HXDP 5.01b부터 HyperFlex는 하드웨어 기반 암호화를 지원하지 않는 시스템이나 하드웨어 솔루션보다 이 기능을 원하는 사용자를 위해 Intersight Key Manager를 사용하는 소프트웨어 기반 솔루션을 제공합니다. 이 FAQ는 HX 암호화를 위한 SED 기반 하드웨어 솔루션에만 초점을 맞춥니다. 소프트웨어 기반 암호화에 대한 정보는 관리 문서나 백서를 참조하십시오.

편견 진술
이 제품의 설명서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 이 설명서 세트의 목적상 편견 없는 언어는 나이, 장애, 성별, 인종적 정체성, 민족적 정체성, 성적 지향, 사회경제적 지위 및 교차성에 따른 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에 하드코딩된 언어, 표준 설명서에 따라 사용된 언어 또는 참조된 타사 제품에서 사용되는 언어로 인해 설명서에 예외가 있을 수 있습니다.

보안 및 HX 암호화를 위한 Cisco의 선택 이유

질문 1.1: 안전한 개발을 위해 어떤 프로세스가 시행되고 있나요?
A 1.1: Cisco 서버는 Cisco Secure Development Lifecycle(CSDL)을 준수합니다.
- Cisco는 오버레이가 아닌 Cisco 서버에 내장된 보안을 개발하기 위한 프로세스, 방법론, 프레임워크를 제공합니다.
- UCS 제품 포트폴리오에 대한 위협 모델링/정적 분석을 위한 전담 Cisco 팀
- Cisco Advanced Security Initiative Group(ASIG)는 위협이 어떻게 들어오는지 이해하고 CDETS 및 엔지니어링을 통해 HW 및 SW를 향상시켜 문제를 해결하기 위해 사전 침투 테스트를 수행합니다.
- 아웃바운드 취약성을 테스트하고 처리하고 고객에게 보안 고문으로 소통하기 위한 전담 Cisco 팀
- 모든 기본 제품은 Cisco 제품의 보안 표준을 규정하는 제품 보안 기준 요구 사항(PSB)을 거칩니다.
- Cisco는 모든 UCS 릴리스에 대해 취약성/프로토콜 견고성 테스트를 수행합니다.
질문 1.2: SED가 중요한 이유는 무엇입니까?
A 1.2: SED는 저장 데이터 암호화에 사용되며 대부분의 연방, 의료 및 금융 기관에서 필수 사항입니다.

일반 정보view

질문 2.1: SED란 무엇인가요?
A 2.1: SED(자체 암호화 드라이브)에는 실시간으로 들어오는 데이터를 암호화하고 나가는 데이터를 해독하는 특수 하드웨어가 있습니다.
질문 2.2: HX의 암호화 범위는 무엇입니까?
A 2.2: HX의 암호화는 현재 암호화된 드라이브(SED)를 사용하여 휴면 데이터에 대해서만 하드웨어로 구현됩니다. HX 암호화는 클러스터 전체에 적용됩니다. 개별 VM 암호화는 Hytrust 또는 Vormetric의 투명한 클라이언트와 같은 타사 소프트웨어에서 처리하며 HX 책임 범위를 벗어납니다. HX는 vSphere 3에 도입된 VMware의 기본 VM 암호화 사용도 지원합니다. HX SED 기반 암호화 위에 VM 암호화 클라이언트를 사용하면 데이터가 이중으로 암호화됩니다. HX 복제는 암호화되지 않으며 최종 사용자가 배포한 신뢰할 수 있는 네트워크 또는 암호화된 터널에 의존합니다.
질문 2.3: HX 암호화는 어떤 규정 준수 기준을 충족합니까?
A 2.3: HX SED 암호화 드라이브는 드라이브 제조업체의 FIPS 140-2 레벨 2 표준을 충족합니다. 플랫폼의 HX Encryption은 FIPS 140-2 레벨 1 표준을 충족합니다.
질문 2.4: 암호화를 위해 HDD와 SSD를 모두 지원합니까?
A 2.4: 네, Micron의 HDD와 SSD SED를 모두 지원합니다.
질문 2.5: HX 클러스터는 암호화된 드라이브와 암호화되지 않은 드라이브를 동시에 가질 수 있습니까?
A 2.5: 클러스터의 모든 노드는 균일해야 합니다(SED 또는 비 SED)
질문 2.6: SED에는 어떤 키가 사용되며, 어떻게 사용합니까?
A 2.6: 각 SED에 사용되는 키는 두 개입니다. 미디어 암호화 키(MEK)는 DEK(디스크 암호화 키)라고도 하며, 디스크에 대한 데이터의 암호화 및 복호화를 제어하며 하드웨어에서 보안 및 관리됩니다. 키 암호화 키(KEK)는 DEK/MEK를 보안하며 로컬 또는 원격 키스토어에서 유지 관리됩니다.
질문 2.7: 키가 메모리에 존재하는 경우가 있나요?
A 2.7: 암호화 키는 노드 메모리에 존재하지 않습니다.
질문 2.8: 암호화/복호화 프로세스는 성능에 어떤 영향을 미칩니까?
A 2.8: 디스크 암호화/복호화는 드라이브 하드웨어에서 처리됩니다. 전체 시스템 성능에는 영향을 미치지 않으며 시스템의 다른 구성 요소를 타겟으로 하는 공격의 대상이 되지 않습니다.
질문 2.9: 저장 중 암호화 외에도 SED를 사용하는 다른 이유는 무엇입니까?
A 2.9: SED는 즉각적인 암호화 삭제를 통해 드라이브 은퇴 및 재배치 비용을 줄일 수 있습니다. 또한 데이터 프라이버시에 대한 정부 또는 산업 규정을 준수하는 데에도 도움이 됩니다. 또 다른 이점tag하드웨어가 생태계에서 제거되면 데이터를 읽을 수 없으므로 디스크 도난 및 노드 도난의 위험이 줄어듭니다.
Q2.10: SED를 사용한 중복제거 및 압축은 어떻게 되나요? 타사 소프트웨어 기반 암호화는 어떻게 되나요?
A2.10: HX에서 SED를 사용한 중복 제거 및 압축은 쓰기 프로세스의 마지막 단계에서 저장 데이터 암호화가 수행되므로 유지됩니다. 중복 제거 및 압축은 이미 수행되었습니다. 타사 소프트웨어 기반 암호화 제품을 사용하면 VM이 암호화를 관리하고 암호화된 쓰기를 하이퍼바이저와 HX로 전달합니다. 이러한 쓰기는 이미 암호화되어 있으므로 중복 제거 또는 압축되지 않습니다. HX 소프트웨어 기반 암호화(3.x 코드라인)는 쓰기 최적화(중복 제거 및 압축)가 발생한 후 스택에 구현되는 소프트웨어 암호화 솔루션이므로 이 경우 이점이 유지됩니다.

아래 그림은 오버입니다view HX를 이용한 SED 구현

드라이브 세부정보

질문 3.1: HX에 사용되는 암호화 드라이브를 제조하는 곳은 어디입니까?
A 3.1: HX는 Micron에서 제조한 드라이브를 사용합니다. Micron 관련 문서는 이 FAQ의 지원 문서 섹션에 링크되어 있습니다.
질문 3.2: FIPS 규격을 준수하지 않는 SED도 지원합니까?
A 3.2: 또한 FIPS는 아니지만 SED(TCGE)를 지원하는 일부 드라이브도 지원합니다.
질문 3.3: TCG는 무엇인가요?
A 3.3: TCG는 암호화된 데이터 저장을 위한 사양 표준을 만들고 관리하는 Trusted Computing Group의 약자입니다.
Q 3.4: 데이터 센터용 SAS SSD와 관련하여 엔터프라이즈급 보안으로 간주되는 것은 무엇입니까? 이러한 드라이브는 보안을 보장하고 공격으로부터 보호하는 특정 기능이 무엇입니까?
A 3.4: 이 목록은 HX에 사용되는 SED의 엔터프라이즈급 기능과 TCG 표준과의 관계를 요약한 것입니다.
1. 자체 암호화 드라이브(SED)는 SED에 저장된 데이터에 대한 강력한 보안을 제공하여 무단 데이터 액세스를 방지합니다. Trusted Computing Group(TCG)은 HDD와 SSD 모두에 대한 자체 암호화 드라이브의 기능 및 이점 목록을 개발했습니다. TCG는 TCG Enterprise SSC(Security Subsystem Class)라고 하는 표준을 제공하며 저장 데이터에 초점을 맞춥니다. 이는 모든 SED에 대한 요구 사항입니다. 이 사양은 엔터프라이즈 스토리지에서 작동하는 데이터 저장 장치 및 컨트롤러에 적용됩니다. 목록에는 다음이 포함됩니다.
  - 투명도: 시스템이나 애플리케이션을 수정할 필요가 없습니다. 암호화 키는 온보드 순수 난수 생성기를 사용하여 드라이브 자체에서 생성됩니다. 드라이브는 항상 암호화됩니다.
  - 관리의 용이성: 관리할 암호화 키가 없습니다. 소프트웨어 공급업체는 원격 관리, 부팅 전 인증, 암호 복구를 포함하여 SED를 관리하기 위해 표준화된 인터페이스를 활용합니다.
  - 폐기 또는 재활용 비용: SED를 사용하여 온보드 암호화 키를 지웁니다.
  - 재암호화: SED를 사용하면 데이터를 다시 암호화할 필요가 없습니다.
  - 성능: SED 성능 저하 없음; 하드웨어 기반
  - 표준화: 전체 드라이브 산업은 TCG/SED 사양을 구축하고 있습니다.
  - 쉽게 한: 상류 공정에 간섭 없음
2. SSD SED는 드라이브를 암호화하여 지울 수 있는 기능을 제공합니다. 즉, 간단한 인증 명령을 드라이브에 보내 드라이브에 저장된 256비트 암호화 키를 변경할 수 있습니다. 이렇게 하면 드라이브가 깨끗이 지워지고 데이터가 남지 않습니다. 원래 호스트 시스템도 데이터를 읽을 수 없으므로 다른 시스템에서는 절대 읽을 수 없습니다. 암호화되지 않은 HDD에서 유사한 작업을 수행하는 데 몇 분 또는 몇 시간이 걸리는 것과 달리 이 작업은 몇 초 밖에 걸리지 않으며 값비싼 HDD 디가우징 장비나 서비스 비용을 피할 수 있습니다.
3. FIPS(Federal Information Processing Standard) 140-2는 민감하지만 비밀이 아닌 용도에 대해 IT 제품이 충족해야 하는 암호화 및 관련 보안 요구 사항을 설명하는 미국 정부 표준입니다. 이는 종종 금융 서비스 및 의료 산업의 정부 기관과 회사에도 요구 사항입니다. FIPS-140-2 검증을 받은 SSD는 승인된 암호화 알고리즘을 포함한 강력한 보안 관행을 사용합니다. 또한 개인 또는 기타 프로세스가 제품을 활용하기 위해 어떻게 권한을 부여받아야 하는지, 그리고 모듈 또는 구성 요소가 다른 시스템과 안전하게 상호 작용하도록 어떻게 설계되어야 하는지 지정합니다. 사실, FIPS-140-2 검증을 받은 SSD 드라이브의 요구 사항 중 하나는 SED라는 것입니다. TCG가 인증된 암호화 드라이브를 얻는 유일한 방법은 아니지만 TCG Opal 및 Enterprise SSC 사양은 FIPS 검증을 위한 발판을 제공한다는 점을 명심하세요. 4. 또 다른 필수 기능은 보안 다운로드 및 진단입니다. 이 펌웨어 기능은 펌웨어에 내장된 디지털 서명을 통해 드라이브를 소프트웨어 공격으로부터 보호합니다. 다운로드가 필요할 때 디지털 서명은 드라이브에 대한 무단 액세스를 차단하여 위조 펌웨어가 드라이브에 로드되는 것을 방지합니다.

SED를 사용한 Hyperflex 설치

Q 4.1: 설치 프로그램은 SED 배포를 어떻게 처리합니까? 특별한 확인 사항이 있습니까?
A 4.1: 설치 프로그램은 UCSM과 통신하고 시스템 펌웨어가 올바르고 감지된 하드웨어에 대해 지원되는지 확인합니다. 암호화 호환성이 확인되고 강제됩니다(예: SED와 비 SED의 혼합 없음).
질문 4.2: 그 외에 배포에 다른 점이 있나요?
A 4.2: 설치는 일반적인 HX 설치와 유사하지만, SED에 대한 사용자 정의 워크플로는 지원되지 않습니다. 이 작업에는 SED에 대한 UCSM 자격 증명도 필요합니다.
Q 4.3: 암호화와 함께 라이선싱은 어떻게 작동합니까? 추가로 필요한 것이 있습니까?
A 4.3: SED 하드웨어(공장에서 주문, 개조 아님) + HXDP 2.5 + UCSM(3.1(3x))은 키 관리를 통해 암호화를 활성화하는 데 필요한 유일한 것입니다. 2.5 릴리스에서 필요한 기본 HXDP 구독 외에 추가 라이선싱은 없습니다.

Q 4.4: 더 이상 사용할 수 없는 드라이브가 있는 SED 시스템이 있는 경우 어떻게 됩니까? 이 클러스터를 어떻게 확장할 수 있습니까?
A 4.4: 공급업체에서 수명이 다한 PID가 있을 때마다 이전 PID와 호환되는 대체 PID가 있습니다. 이 대체 PID는 RMA, 노드 내 확장 및 클러스터 확장(새 노드 포함)에 사용할 수 있습니다. 모든 방법이 지원되지만 특정 릴리스로 업그레이드해야 할 수 있으며 이는 전환 릴리스 노트에도 나와 있습니다.

핵심 관리

질문 5.1: 키 관리란 무엇인가요?
A 5.1: 키 관리란 암호화 키를 보호, 저장, 백업 및 구성하는 것과 관련된 작업입니다. HX는 이를 UCSM 중심 정책으로 구현합니다.
질문 5.2: 키 구성을 지원하는 메커니즘은 무엇입니까?
A 5.2: UCSM은 보안 키 구성에 대한 지원을 제공합니다.

질문 5.3: 어떤 유형의 키 관리가 가능합니까?
A 5.3: 타사 키 관리 서버를 통한 엔터프라이즈급 원격 키 관리와 함께 키의 로컬 관리가 지원됩니다.
질문 5.4: 원격 키 관리 파트너는 누구입니까?
A 5.4: 현재 Vormetric과 Gemalto(Safenet)를 지원하고 있으며 고가용성(HA)을 포함합니다. HyTrust는 테스트 중입니다.
질문 5.5: 원격 키 관리가 어떻게 구현되나요?
A 5.5: 원격 키 관리가 KMIP 1.1을 통해 처리됩니다.

질문 5.6: 로컬 관리가 어떻게 구성되나요?
A 5.6: 보안 키(KEK)는 사용자가 HX Connect에서 직접 구성합니다.
질문 5.7: 원격 관리가 어떻게 구성되나요?
A 5.7: 원격 키 관리(KMIP) 서버 주소 정보와 로그인 자격 증명은 사용자가 HX Connect에서 구성합니다.
질문 5.8: HX의 어떤 부분이 구성을 위해 KMIP 서버와 통신합니까?
A 5.8: 각 노드의 CIMC는 이 정보를 사용하여 KMIP 서버에 연결하고 해당 서버에서 보안 키(KEK)를 검색합니다.

질문 5.9: 키 생성/검색/업데이트 프로세스에서 어떤 유형의 인증서가 지원됩니까?
A 5.9: CA 서명 인증서와 자체 서명 인증서가 모두 지원됩니다.
질문 5.10: 암호화 프로세스에서는 어떤 워크플로가 지원되나요?
A 5.10: 사용자 지정 암호를 사용하여 보호/보호 해제가 로컬에서 원격 키 관리로 변환되는 것과 함께 지원됩니다. 키 재설정 작업이 지원됩니다. 안전한 디스크 지우기 작업도 지원됩니다.

사용자 워크플로: 로컬

질문 6.1: HX Connect에서 로컬 키 관리를 어디에서 설정해야 합니까?
A 6.1: 암호화 대시보드에서 구성 버튼을 선택하고 마법사를 따릅니다.

질문 6.2: 시작하기 위해 무엇을 준비해야 합니까?
A 6.2: 32자리 보안 암호를 입력해야 합니다.
질문 6.3: 새로운 SED를 삽입해야 하는 경우 어떻게 되나요?
6.3년: UCSM에서는 로컬 보안 정책을 편집하고 배포된 키를 기존 노드 키로 설정해야 합니다.
질문 6.4: 새 디스크를 삽입하면 어떻게 되나요?
A 6.4: 디스크의 보안 키가 서버(노드)의 보안 키와 일치하면 자동으로 잠금 해제됩니다. 보안 키가 다르면 디스크가 "잠김"으로 표시됩니다. 디스크를 지워 모든 데이터를 삭제하거나 올바른 키를 제공하여 잠금을 해제할 수 있습니다. 이때 TAC를 사용하기에 좋은 시기입니다.

사용자 워크플로: 원격

질문 7.1: 원격 키 관리 구성에서 주의해야 할 사항은 무엇입니까?
A 7.1: 클러스터와 KMIP 서버 간의 통신은 각 노드의 CIMC를 통해 이루어집니다. 즉, CIMC 관리에서 Inband IP 주소와 DNS가 구성된 경우에만 호스트 이름을 KMIP 서버에 사용할 수 있습니다.
질문 7.2: SED를 교체하거나 새 SED를 삽입해야 하는 경우 어떻게 되나요?
A 7.2: 클러스터는 디스크에서 식별자를 읽고 자동으로 잠금 해제를 시도합니다. 자동 잠금 해제가 실패하면 디스크가 "잠김"으로 표시되고 사용자는 디스크를 수동으로 잠금 해제해야 합니다. 자격 증명 교환을 위해 인증서를 KMIP 서버로 복사해야 합니다.
질문 7.3: 클러스터에서 KMIP 서버로 인증서를 복사하려면 어떻게 해야 합니까?
A 7.3: 이를 수행하는 방법은 두 가지가 있습니다. BMC에서 KMIP 서버로 직접 인증서를 복사하거나 CSR을 사용하여 CA 서명 인증서를 얻고 UCSM 명령을 사용하여 CA 서명 인증서를 BMC로 복사할 수 있습니다.

질문 7.4: 원격 키 관리를 사용하는 클러스터에 암호화된 노드를 추가하는 데 있어 어떤 고려 사항이 있습니까?
A 7.4: KMIP 서버에 새 호스트를 추가할 때 사용되는 호스트 이름은 서버의 일련 번호여야 합니다. KMIP 서버의 인증서를 얻으려면 브라우저를 사용하여 KMIP 서버의 루트 인증서를 가져올 수 있습니다.

사용자 워크플로: 일반

질문 8.1: 디스크를 지우려면 어떻게 해야 하나요?
A 8.1: HX Connect 대시보드에서 시스템 정보를 선택하세요 view여기에서 안전하게 삭제할 디스크를 개별적으로 선택할 수 있습니다.
질문 8.2: 실수로 디스크를 지운 경우에는 어떻게 해야 합니까?
A 8.2: 보안 지우기를 사용하면 데이터가 영구적으로 파기됩니다.

질문 8.3: 노드를 서비스 해제하거나 서비스 연결을 해제하려고 할 때 어떻게 됩니까?file?
A 8.3: 이러한 작업을 수행해도 디스크/컨트롤러의 암호화는 제거되지 않습니다.
질문 8.4: 암호화는 어떻게 비활성화되나요?
A 8.4: 사용자는 HX Connect에서 암호화를 명시적으로 비활성화해야 합니다. 사용자가 연관된 서버가 보안된 상태에서 UCSM에서 보안 정책을 삭제하려고 하면 UCSM은 config-failure를 표시하고 작업을 허용하지 않습니다. 보안 정책을 먼저 비활성화해야 합니다.

사용자 워크플로: 인증서 관리

질문 9.1: 원격 관리 설정 중에 인증서는 어떻게 처리됩니까?
A 9.1: 인증서는 HX Connect와 원격 KMIP 서버를 사용하여 생성됩니다. 인증서가 생성되면 거의 삭제되지 않습니다.

질문 9.2: 어떤 종류의 인증서를 사용할 수 있나요?
A 9.2: 자체 서명 인증서 또는 CA 인증서를 사용할 수 있습니다. 설정 중에 선택해야 합니다. CA 서명 인증서의 경우 인증서 서명 요청(CSR) 세트를 생성합니다. 서명된 인증서는 KMIP 서버에 업로드됩니다.
질문 9.3: 인증서를 생성할 때 어떤 호스트 이름을 사용해야 합니까?
A 9.3: 인증서 생성에 사용되는 호스트 이름은 서버의 일련 번호여야 합니다.

펌웨어 업데이트

질문 10.1: 디스크 펌웨어 업그레이드에 제한이 있나요?
A 10.1: 암호화가 가능한 드라이브가 감지되면 해당 디스크에 대한 디스크 펌웨어 변경이 허용되지 않습니다.

질문 10.2: UCSM 펌웨어 업그레이드에 제한이 있나요?
A 10.2: 보안 상태의 컨트롤러가 있는 경우 UCSM/CIMC를 UCSM 3.1(3x) 이전 버전으로 다운그레이드하는 것은 제한됩니다.

보안 지우기 세부 정보

질문 11.1: 보안 삭제란 무엇입니까?
A 11.1: 보안 지우기는 드라이브의 데이터를 즉시 지우는 것입니다(디스크 암호화 키 삭제). 즉, 간단한 인증 명령을 드라이브에 보내 드라이브에 저장된 256비트 암호화 키를 변경할 수 있습니다. 이렇게 하면 드라이브가 깨끗이 지워지고 데이터가 남지 않습니다. 원래 호스트 시스템도 데이터를 읽을 수 없으므로 다른 시스템에서 읽을 수 없습니다. 암호화되지 않은 디스크에서 유사한 작업을 수행하는 데 몇 분 또는 몇 시간이 걸리는 것과 달리 이 작업은 몇 초 밖에 걸리지 않으며 값비싼 자기 소거 장비나 서비스 비용을 피할 수 있습니다.
질문 11.2: 보안 지우기는 어떻게 수행되나요?
A 11.2: 이는 한 번에 하나의 드라이브에서 수행되는 GUI 작업입니다.

질문 11.3: 보안 지우기는 일반적으로 언제 수행됩니까?
A 11.3: 사용자가 단일 디스크를 보안 지우는 작업은 흔치 않습니다. 이는 주로 교체를 위해 디스크를 물리적으로 제거하거나, 다른 노드로 옮기거나, 가까운 미래에 발생할 오류를 피하고자 할 때 수행됩니다.
질문 11.4: 보안 삭제에는 어떤 제한이 있나요?
A 11.4: 보안 지우기 작업은 클러스터가 정상 상태인 경우에만 수행할 수 있으며, 이를 통해 클러스터의 장애 복원력에 영향을 미치지 않습니다.
질문 11.5: 노드 전체를 제거해야 하는 경우 어떻게 되나요?
A 11.5: 모든 드라이브의 안전한 지우기를 지원하기 위한 노드 제거 및 노드 교체 워크플로가 있습니다. 자세한 내용은 관리자 가이드를 참조하거나 Cisco TAC에 문의하세요.

질문 11.6: 안전하게 지워진 디스크를 재사용할 수 있나요?
A 11.6: 안전하게 지워진 디스크는 다른 클러스터에서만 재사용할 수 있습니다. SED의 안전한 지우기는 디스크 암호화 키(DEK)를 삭제하여 수행됩니다. DEK 없이는 디스크의 데이터를 해독할 수 없습니다. 이를 통해 데이터를 손상시키지 않고 디스크를 재사용하거나 폐기할 수 있습니다.
질문 11.7: 지우려는 디스크에 클러스터 데이터의 마지막 기본 사본이 포함되어 있는 경우 어떻게 되나요?
A 11.7: 디스크의 데이터는 데이터 손실을 방지하기 위해 클러스터에 다른 사본이 있어야 합니다. 그러나 마지막 기본 사본인 디스크에서 보안 지우기를 요청하면 최소한 하나 이상의 사본이 사용 가능할 때까지 이 작업이 거부됩니다. 리밸런싱은 백그라운드에서 이 사본을 만들어야 합니다.
Q 11.8: 디스크를 안전하게 지워야 하는데 클러스터가 정상이 아닙니다. 어떻게 해야 하나요?
A 11.8: 명령줄(STCLI/HXCLI)은 클러스터가 정상적이지 않고 디스크에 마지막 기본 사본이 없는 경우 보안 삭제를 허용하지만, 그렇지 않은 경우에는 허용되지 않습니다.

질문 11.9: 노드 전체를 안전하게 지우려면 어떻게 해야 하나요?
A 11.9: 이것은 드문 시나리오입니다. 노드의 모든 디스크를 안전하게 지우는 것은 노드를 클러스터에서 제거하려고 할 때 수행됩니다. 의도는 노드를 다른 클러스터에 배포하거나 노드를 폐기하는 것입니다. 이 시나리오에서 노드 제거를 두 가지 다른 방법으로 분류할 수 있습니다.
1. 암호화를 비활성화하지 않고 모든 디스크를 안전하게 지웁니다.
2. 모든 디스크를 안전하게 지우고 해당 노드(및 디스크)에 대한 암호화를 비활성화합니다. 도움이 필요하면 Cisco TAC에 문의하세요.

클러스터의 안전한 확장

질문 12.1: 암호화된 클러스터를 확장할 수 있는 노드 유형은 무엇입니까?
A 12.1: SED가 가능한 노드만 SED가 있는 HX 클러스터에 추가할 수 있습니다.

질문 12.2: 로컬 키 관리를 통한 확장은 어떻게 처리됩니까?
A 12.2: 로컬 키 확장은 외부 구성이 필요 없이 원활하게 작동합니다.
질문 12.3: 원격 키 관리를 통한 확장은 어떻게 처리되나요?
A 12.3: 원격 키 확장에는 인증서/키 관리 인프라와 긴밀한 협력이 필요합니다.
- 새로운 노드를 안전하게 추가하려면 인증서가 필요합니다.
- 배포에는 인증서 다운로드 링크를 포함한 진행 단계와 함께 경고가 표시됩니다.
- 사용자는 인증서를 업로드하기 위한 단계를 따른 다음 배포를 다시 시도합니다.

지원 서류

미크론:

FIPS

FIPS 140-2에 승인된 암호 알고리즘 목록: https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf

CDET::

프로젝트: CSC.nuova 제품: ucs-blade-server 구성 요소: ucsm

SED 기능 사양:

전자발찌: 1574090

SED CIMC 사양:

http://wwwin-eng.cisco.com/Eng/SAVBU/Projects/Rackmount/Freel_Peak/SW_Specs/Remote_Key_Mgmt_sw_design_spec.doc

메일링 리스트:

문서 / 리소스

CISCO HyperFlex HX 데이터 플랫폼 [PDF 파일] 지침
HyperFlex HX 데이터 플랫폼, HyperFlex, HX 데이터 플랫폼, 데이터 플랫폼, 플랫폼

참고문헌

사용자 설명서

CISCO HyperFlex HX 데이터 플랫폼

제품 정보

제품 사용 지침

HX 보안 암호화 FAQ

지원 서류

문서 / 리소스

참고문헌

댓글을 남겨주세요

답변 취소