OCI에서 두 개의 Thales CipherTrust Cloud Key Manager Appliance 설정, 두 어플라이언스 간에 클러스터 생성 및 인증 기관으로 구성

소개

보안, 규정 준수 및 데이터 주권 요구 사항을 충족하기 위해 오늘날의 클라우드 우선 환경에서 암호화 키에 대한 더 큰 통제력을 모색하고 있습니다. Thales CipherTrust Cloud Key Manager(CCKM)는 Oracle Cloud Infrastructure(OCI)를 비롯한 멀티클라우드 및 하이브리드 환경에서 암호화 키 및 암호를 관리할 수 있는 중앙 집중식 솔루션을 제공합니다. 이 아키텍처의 핵심 기능은 HYOK(Hold Your Own Key)를 지원하여 타사 클라우드 서비스를 사용할 때도 암호화 키를 완벽하게 제어할 수 있게 해 줍니다.

이 자습서에서는 다음을 포함하여 OCI에서 두 개의 Thales CCKM 어플라이언스를 완전히 설정하는 과정을 안내합니다.

두 개의 CCKM 인스턴스를 배치하는 중입니다.
이들 사이에 고가용성 클러스터를 생성합니다.
내부 인증서 발급 및 관리를 위해 어플라이언스 중 하나를 CA(인증 기관)로 구성합니다.

이 자습서를 마치면 BYOK(Bring Your Own Key), HYOK, 중앙 집중식 키 수명 주기 관리와 같은 주요 사용 사례를 지원하는 강력하고 확장 가능한 CCKM 환경이 제공됩니다. 이 설정은 최고 수준의 데이터 보안 표준을 준수하면서 키 제어를 클라우드로 확장하려는 기업에 적합합니다.

참고: 이 자습서에서는 Thales CipherTrust Cloud Key Manager(CCKM)와 Thales CipherTrust Manager라는 용어가 같은 의미로 사용됩니다. 둘 다 동일한 제품을 의미합니다.

목표

작업 1: OCI VCN(가상 클라우드 네트워크) 인프라를 검토합니다.
작업 2: 첫번째 Thales CCKM 어플라이언스를 배치합니다.
작업 3: 첫번째 Thales CCKM 어플라이언스에서 초기 구성을 수행합니다.
작업 4: 두번째 Thales CCKM 어플라이언스를 배치하고 CCKM에서 초기 구성을 수행합니다.
작업 5: Thales CCKM 어플라이언스 RPC(원격 피어링 연결) 간의 연결을 검토합니다.
작업 6: DNS를 구성합니다.
작업 7: 첫번째 Thales CCKM 어플라이언스를 CA(인증 기관)로 구성합니다.
작업 8: 두 Thales CCKM 어플라이언스에 대한 CSR(cloud service provider)을 만들고 CA에서 서명합니다.
작업 9: Thales CCKM 어플라이언스 클러스터링을 구성합니다.

작업 1: OCI VCN(가상 클라우드 네트워크) 인프라 검토

Thales CCKM 어플라이언스를 배포하기 전에 이를 지원할 기본 OCI 네트워크 아키텍처를 이해해야 합니다.

이 설정에서는 두 개의 개별 VCN을 사용합니다.

한 VCN은 암스테르담(AMS) OCI 지역에 있습니다.
두번째 VCN은 애슈번(ASH) OCI 지역에 있습니다.

이 두 영역은 RPC를 통해 연결되므로 지역 간 CCKM 어플라이언스 간에 안전하고 대기 시간이 짧은 통신을 수행할 수 있습니다. 이 영역 간 연결은 CCKM의 고가용성, 중복성 및 클러스터화에 필수적입니다.

CCKM 어플라이언스는 이 자습서를 위해 각 VCN 내의 공용 서브넷에 배포됩니다. 이 접근 방식은 SSH 또는 웹 인터페이스를 통해 인터넷을 통한 초기 액세스 및 관리를 단순화합니다. 그러나 운용 환경에서 모범 사례는 이러한 어플라이언스를 프라이빗 서브넷에 배치하고 배스천 호스트 또는 스텝스톤(점프) 서버를 통해 액세스를 관리하는 것입니다. 이로 인해 공용 인터넷에 어플라이언스가 노출되는 일이 줄어들고 보다 안전한 네트워크 상황과 연계됩니다.

다음 작업에서 검토된 이 VCN 설정 내에 CCKM을 배치합니다.

작업 2: 첫 번째 Thales CCKM 어플라이언스 배포

첫 번째 Thales CCKM 어플라이언스를 배포하기 전에 OCI에서 필요한 이미지를 사용할 수 있는지 확인해야 합니다.

공식 Thales 문서는 일반적으로 CCKM 이미지를 OCI로 직접 임포트하기 위한 OCI Object Storage URL을 얻기 위해 지원 사례를 여는 것을 권장하지만, 대체 방법을 사용합니다.

Thales로부터 로컬 610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA.ova 파일을 받았습니다. 제공된 URL을 사용하는 대신 다음을 수행합니다.

.ova 아카이브에서 .vmdk 파일을 추출합니다.
.vmdk 파일을 OCI Object Storage 버킷에 업로드합니다.
.vmdk 파일에서 OCI에 사용자정의 이미지를 생성합니다.
이 사용자정의 이미지를 사용하여 CCKM 인스턴스를 배포합니다.

이 방법을 사용하면 이미지 가져오기 프로세스를 완벽하게 제어할 수 있으며 에어갭 또는 사용자 정의 배포 시나리오에서 특히 유용합니다.

610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA.ova 파일을 로컬 디스크의 새 폴더에 저장합니다.
.ova 파일의 압축을 풉니다.
추출된 폴더의 .vmdk 파일을 확인합니다.

OCI 네트워크 인프라를 통해 암스테르담(AMS) 지역에 첫 번째 Thales CCKM 어플라이언스를 배포할 준비가 되었습니다. OCI 콘솔에 로그인합니다.

스토리지, 오브젝트 스토리지로 이동하고 버킷을 누릅니다.
올바른 컴파트먼트에 있는지 확인하고 버킷 생성을 누릅니다.
완료하려면 다음 정보를 입력하고 생성을 누릅니다.
- 버킷 이름: CCKM_Bucket을 입력합니다.
- 스토리지 계층: 표준(기본값)을 선택합니다.
- 다른 모든 설정은 기본적으로 그대로 둡니다(사용 사례에 암호화 또는 액세스 정책이 필요하지 않은 경우).
새로 생성된 OCI Object Storage 버킷을 누릅니다.
페이지 아래로 이동합니다.
업로드를 누릅니다.
다음 정보를 입력합니다.
- 객체 이름 접두어에 610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA를 입력합니다.
- 다른 모든 설정은 기본적으로 그대로 둡니다.
- 로컬 시스템에서 .vmdk 파일(예: k170v-2.19.0+14195-disk1.vmdk)을 선택하고 업로드를 누른 다음 프로세스가 완료될 때까지 기다립니다.
업로드가 완료되면 닫기를 누릅니다.
.vmdk 파일이 업로드된 것을 확인할 수 있습니다.

.vmdk 파일을 OCI Object Storage 버킷에 업로드한 후 다음 단계에 따라 사용자정의 이미지로 임포트합니다.

OCI 콘솔로 이동하여 컴퓨트로 이동하고 사용자정의 이미지를 누릅니다.
이미지 임포트를 누릅니다.
다음을 입력하고 이미지 임포트를 누릅니다.
- 이름: 610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA을 입력합니다.
- 운영 체제 버전: CCKM 이미지 내에서 OS를 일치시킵니다(일반적으로 Debian 또는 Ubuntu 버전인 Thales 설명서 확인).
- OCI Object Storage 버킷에서 임포트를 선택합니다.
- 버킷: 버킷을 선택합니다.
- 객체: 이전 섹션에서 업로드한 객체(.vmdk 파일)를 선택합니다.
- 이미지 유형: VMDK를 선택합니다.
페이지 아래로 이동합니다.
임포트 상태가 진행 중이며 임포트하는 동안 완료 퍼센트가 있습니다.
이미지 가져오기가 완료되면 이미지를 사용할 수 있습니다.
OCI 콘솔로 이동하여 컴퓨트로 이동하고 인스턴스를 누릅니다.
인스턴스 생성을 누릅니다.
다음 정보를 입력합니다.
- 이름: 인스턴스 이름을 입력합니다. 예를 들어, CCKM-1입니다.
- 선택한 지역에서 사용 가능한 AD를 선택합니다(예: 암스테르담의 AD-1).
이미지 및 구성 섹션에서 이미지 변경을 누르고 사용자정의 이미지를 선택합니다.
다음 정보를 입력하고 이미지 선택을 누릅니다.
- 내 이미지를 선택합니다.
- 사용자정의 이미지를 선택합니다.
- 사용자 정의 이미지 이름: 가져온 이미지를 선택합니다. 예: 610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA.
Shape(VM.Standard.E5.Flex)를 선택하고 OCPU 및 메모리를 구성합니다.

주: Thales for CCKM의 최소 사양 요구 사항을 확인하십시오(일반적으로 OCPU가 2개/8GB RAM 이상).
기존 VCN 및 서브넷을 선택합니다. 직접 SSH/웹 액세스(또는 모범 사례에 따라 배스천이 있는 개인 서브넷)를 원할 경우 공용 서브넷을 사용합니다.
자동으로 프라이빗 IPv4 주소 지정 및 자동으로 퍼블릭 IPv4 주소 지정을 선택합니다.
SSH 키 추가에서 공개 키 파일 업로드를 선택하고 .pub 파일을 업로드합니다. 이 키는 SSH를 통해 VM에 액세스하는 데 사용됩니다. Create를 누릅니다.

인스턴스는 PROVISIONING 상태입니다.
PROVISIONING이 성공적으로 완료되면 인스턴스 상태가 RUNNING으로 변경됩니다. 나중에 구성 및 관리에 필요한 공용 및 전용 IP 주소를 확인합니다.
SSH를 테스트하려면 Royal TSX 응용 프로그램을 사용하고 SSH 세션을 구성합니다.
Royal TSX 세션의 자격 증명 탭에서 사용자 이름을 지정합니다. 예: ksadmin.
해당 개인 키 파일도 선택했는지 확인합니다.
SSH를 사용하여 새로 배치된 CCKM에 로그인합니다.
웹 GUI를 사용하여 CCKM을 구성합니다.
웹 브라우저를 사용하여 내부적으로 연결하는 경우 공용 IP 주소 또는 전용 IP로 이동합니다.
CA는 자체 서명된 인증서를 검증할 수 없으므로 고급을 누릅니다.
그래도 연결을 계속합니다.
다음과 같은 오류가 표시될 수 있습니다. 즉, Instance의 일부 서비스가 시작된 것은 아닙니다. 모든 서비스가 시작될 때까지 기다립니다. 이 작업은 최대 5분이 걸릴 수 있습니다.
모든 서비스가 시작되면 모든 서비스가 정상임을 알리는 메시지가 표시됩니다.
사용자 이름을 admin으로, 비밀번호를 admin로 사용하여 로그인합니다. 처음 로그인한 후 비밀번호를 변경하라는 메시지가 표시됩니다.
지침에 따라 암호를 변경합니다.
새 비밀번호를 사용하여 로그인합니다.
로그인되었으며 CCKM이 성공적으로 배치되었습니다.

다음 이미지는 지금까지 배치의 현재 상태를 보여줍니다.

작업 3: 첫번째 Thales CCKM 어플라이언스에서 초기 구성 수행

이제 첫번째 CCKM 어플라이언스가 배치되고 액세스할 수 있으므로 초기 구성을 수행해야 합니다. 여기에는 NTP 서버를 사용하여 시스템 시계를 설정하고 평가 라이센스 또는 Thales가 제공하는 실제 라이센스를 활성화하는 작업이 포함됩니다.

이러한 단계를 통해 어플라이언스는 인증서 관리, 로깅 및 동기화에 중요한 정확한 시간으로 작동하며 평가 또는 설정 단계에서 완전히 작동합니다.

Admin Settings(관리 설정), NTP로 이동하고 Add NTP Server(NTP 서버 추가)를 선택합니다.
안정적인 NTP 서버의 호스트 이름 또는 IP 주소(예: 169.254.169.254(Oracle의 공용 NTP 서버 IP) 또는 조직의 내부 NTP 소스)를 입력하고 Add NTP Server(NTP 서버 추가)를 누릅니다.
NTP Server가 성공적으로 추가되었다는 메시지가 나타납니다. 닫기를 누르면
시간이 올바르게 동기화되었는지 확인합니다.
관리 설정, 라이센싱으로 이동하고 CipherTrust 플랫폼 평가 시작을 누릅니다.
아래로 이동합니다.
CipherTrust 플랫폼 평가 시작을 누릅니다.
라이센스가 활성화되기까지 몇 분 정도 걸립니다.
활성화된 라이센스를 검토합니다.

작업 4: 두번째 Thales CCKM 어플라이언스 배치 및 초기 구성 수행

작업 2 및 작업 3에 제공된 단계에 따라 ASH 영역에 두번째 CCKM을 배치합니다.

두번째 CCKM이 배치되었고 실행 중인지 확인합니다.
SSH와 두번째 CCKM 간의 연결을 테스트합니다.
웹과 두 번째 CCKM 간의 연결을 테스트합니다.

다음 이미지는 지금까지 배치의 현재 상태를 보여줍니다.

작업 5: Thales CCKM 어플라이언스 RPC 간의 연결 검토

두 Thales CCKM 어플라이언스 간의 고가용성 및 클러스터링을 준비하려면 해당 어플라이언스가 배포된 영역 간에 적절한 연결을 보장해야 합니다.

이 설정에서는 암스테르담(AMS) 및 애슈번(ASH) OCI 리전 간에 RPC가 설정되었습니다. 이 RPC를 사용하면 각 CCKM 어플라이언스가 상주하는 두 VCN 간에 안전하고 대기 시간이 짧은 통신을 수행할 수 있습니다.

구성된 내용:

RPC(원격 피어링 연결)는 AMS와 ASH 간에 설정되고 활성화됩니다.
경로 지정 테이블은 두 VCN 간의 트래픽이 올바르게 전달되도록 적절히 구성됩니다.
두 지역의 보안 목록은 현재 모든 수신 및 송신 트래픽을 허용하도록 구성되어 있습니다. 이 작업은 개념 증명(PoC) 테스트를 단순화하고 초기 설정 및 클러스터링 프로세스 중에 연결 관련 문제를 제거하기 위해 수행됩니다.

참고:

운용 환경에서는 클러스터링 및 관리를 위해 트래픽을 필요한 포트만으로 제한하는 것이 좋습니다.

정확한 포트 요구 사항은 Thales 설명서를 참조하십시오(예: 443, 8443, 5432 등의 TCP 포트 및 CCKM 클러스터 프로토콜에서 사용되는 기타 포트).

이 영역 간 네트워크 설정을 통해 CCKM은 클러스터 만들기 프로세스 중 원활하게 통신할 수 있으며, 다음 절 중 하나에서 설명합니다.

작업 6: DNS 구성

두 어플라이언스 간의 원활한 통신을 사용으로 설정하려면 적절한 DNS 확인이 필요합니다. 이는 보안 클러스터링, 인증서 처리 및 전반적인 서비스 안정성에 특히 중요합니다.

참고: 이 시점부터 Thales CCKM 어플라이언스를 Thales CipherTrust Manager(CyberTrust Manager의 약어)로 지칭합니다.

커스터마이징 내부 DNS 서버를 사용하는 동안 이 배포에서 프라이빗 DNS 영역과 함께 OCI DNS 서비스를 활용하고 있습니다. 이를 통해 Thales CipherTrust Manager에 의미 있는 FQDN(Fully Qualified Domain Names)을 할당할 수 있으며 정적 IP에 의존하지 않고도 여러 지역에서 통신할 수 있습니다.

개인 DNS 영역 이름: oci-thales.lab를 입력합니다.
범위: 비공개를 선택합니다.
연관된 VCN: 영역 간 이름 분석을 허용하기 위해 AMS 및 ASH VCN이 모두 있습니다.

각 Thales CipherTrust Manager 어플라이언스의 개인 IP를 가리키는 oci-thales.lab 영역 내에 두 개의 A 레코드를 만들었습니다.

호스트 이름	FQDN	다음에 대한 포인트
`ctm1`	`ctm1.oci-thales.lab`	AMS의 Thales CipherTrust Manager의 개인 IP
`ctm2`	`ctm2.oci-thales.lab`	ASH에서 Thales CipherTrust Manager의 개인 IP

FQDN을 사용하면 인증서 및 클러스터 구성을 보다 쉽게 관리할 수 있으며 구성을 고정 IP에 결합하는 것을 방지할 수 있습니다.

OCI 콘솔로 이동하여 가상 클라우드 네트워크를 탐색합니다. AMS 영역에 있는지 확인합니다.
VCN을 누릅니다.
DNS 분석기(해당 VCN)를 누릅니다.
기본 프라이빗 뷰(해당 DNS 분석기 및 VCN)를 누릅니다.
영역 만들기를 누릅니다.
다음 정보를 입력하고 생성을 누릅니다.
- 영역 이름: oci-thales.lab을 입력합니다.
- 컴파트먼트: 올바른 항목을 선택합니다.
영역을 누릅니다.
레코드 관리를 누릅니다.
레코드 추가를 누릅니다.
ctm1에 대한 레코드를 생성하려면 다음 정보를 입력합니다.
- 레코드 유형: A - IPv4 주소를 입력합니다.
- 이름: ctm1을 입력합니다.
- TTL: 기본값을 그대로 둡니다(예: 300).
private IP of Thales CipherTrust Manager in AMS를 RDATA (IP Address)로 입력하고 Save Changes를 누릅니다.
ctm2에 대해 두번째 A 레코드를 생성합니다.
- 레코드 유형: A - IPv4 주소를 입력합니다.
- 이름: ctm2을 입력합니다.
- TTL: 기본값을 그대로 둡니다(예: 300).
private IP of Thales CipherTrust Manager in ASH를 RDATA (IP Address)로 입력하고 Save Changes를 누릅니다.
변경 사항 게시를 누릅니다.
ASH에서 DNS 이름 분석을 허용하려면 지금 ASH에서 AMS에 대해 수행한 것과 동일한 단계를 반복합니다.

DNS가 예상대로 작동하는지 확인하기 위해 Thales CipherTrust Manager 인스턴스 중 하나로 SSH를 연결하고 첫 번째 Thales CipherTrust Manager(AMS에서 실행)에서 ping ctm2.oci-thales.lab를 실행합니다.

FQDN이 올바른 IP 주소로 확인되고 RPC, 경로 지정 및 보안 목록이 올바르게 구성된 경우 핑이 성공합니다.

ASH에서 실행되는 CTM2에서 ping을 반복하여 양방향 해상도를 확인합니다.

작업 7: 첫번째 Thales CCKM 어플라이언스를 CA(인증 기관)로 구성

CipherTrust Manager가 처음 시작되면 새 로컬 CipherTrust Manager Root CA가 자동으로 생성됩니다. 이 CA는 시스템에서 사용 가능한 인터페이스에 대한 초기 서버 인증서를 발행하는 데 사용됩니다. 그래서 새로운 것을 만들 필요가 없습니다.

주: AMS Thales CipherTrust Manager에 있는지 확인하십시오.

CA를 누르고 로컬을 선택합니다.
CSR을 만들고 서명하는 데 사용할 로컬 자동 생성 CA(CipherTrust Manager Root CA)를 검토합니다.

다음 이미지는 지금까지 배치의 현재 상태를 보여줍니다.

‌

작업 8: Thales CCKM 어플라이언스에 대한 CSR 생성 및 CA의 서명

CyberTrust Manager 어플라이언스와 DNS를 모두 구성하면 두 어플라이언스 간에 안전한 인증서 기반 통신을 사용으로 설정할 수 있습니다. AMS Thales CipherTrust Manager 및 ASH가 CA로 구성되었으므로 AMS Thales CipherTrust Manager를 사용하여 두 어플라이언스에 대한 인증서를 생성하고 서명합니다.

상위 레벨 단계는 다음과 같습니다.
- AMS Thales CipherTrust 관리자에서 Thales CipherTrust 관리자(AMS 및 ASH)에 대한 CSR(인증서 서명 요청)을 생성합니다.
- AMS Thales CipherTrust Manager CA를 사용하여 두 CSR에 모두 서명합니다.
- 각 Thales CipherTrust Manager에 서명된 인증서를 설치합니다.

이를 통해 모든 Thales CipherTrust Manager-to-Thales CipherTrust Manager 통신이 신뢰되고 암호화되어 클러스터 구성 및 보안 API 액세스에 중요한 요구 사항이 됩니다.

주: AMS Thales CipherTrust Manager에서만 이 단계를 수행합니다.

Thales CipherTrust Manager AMS Console에 로그인합니다.
CA로 이동하고 CSR 생성기를 누릅니다.
다음 정보를 입력하고 CSR 생성 및 개인 키 다운로드를 누릅니다.
- 일반 CSR을 선택합니다.
- 공통 이름: Thales CipherTrust Manager의 FQDN을 입력합니다. 예를 들어, ctm1.oci-thales.lab입니다.
- 표시 이름: 이름을 입력합니다. 예: CTM1 (AMS).
- 알고리즘: ECDSA를 선택합니다.
- 크기: 256을 선택합니다.
- 주제 대체 이름: 여기에 FQDN도 포함합니다. 예: ctm1.oci-thales.lab.
주: 개인 키는 자동으로 다운로드됩니다.
생성된 .csr 파일을 다운로드하여 저장하려면 CSR 다운로드를 누릅니다.
Thales CipherTrust Manager AMS CA에서도 동일한 단계를 반복합니다.
다음 정보를 입력하고 CSR 생성 및 개인 키 다운로드를 누릅니다.
- 일반 CSR을 선택합니다.
- 공통 이름: Thales CipherTrust Manager의 FQDN을 입력합니다. 예를 들어, ctm1.oci-thales.lab입니다.
- 표시 이름: 이름을 입력합니다. 예: CTM2 (AMS).
- 알고리즘: ECDSA를 선택합니다.
- 크기: 256을 선택합니다.
- 주제 대체 이름: 여기에 FQDN도 포함합니다. 예: ctm2.oci-thales.lab.
주: 개인 키는 자동으로 다운로드됩니다.
생성된 .csr 파일을 다운로드하여 저장하려면 CSR 다운로드를 누릅니다.

생성된 CSR(인증서 서명 요청) 및 개인 키를 추적하려면 로컬 시스템 또는 보안 관리 서버에서 깨끗한 폴더 구조를 만드는 것이 좋습니다. 다음은 간단한 예제 구조입니다.

CA, 로컬로 이동하고 CA를 선택합니다.
CSR 업로드를 누릅니다.
Thales CipherTrust Manager의 FQDN(예: ctm1.oci-thales.lab)을 Display Name으로 사용하고 CSR 필드에서 생성된 CSR의 콘텐츠를 복사합니다.
서버를 인증서 용도로 선택하고 인증서 발행을 누릅니다.
서명된 인증서 항목 끝에 있는 3개의 점을 누르고 Download를 눌러 CTM1에 대해 서명된 인증서를 다운로드합니다.
Thales CipherTrust Manager AMS CA에서도 동일한 단계를 반복합니다.
Thales CipherTrust Manager의 FQDN(예: ctm2.oci-thales.lab)을 Display Name으로 사용하고 CSR 필드에서 생성된 CSR의 콘텐츠를 복사합니다.
서버를 인증서 용도로 선택하고 인증서 발행을 누릅니다.
서명된 인증서 항목 끝에 있는 3개의 점을 누르고 Download를 눌러 CTM2에 대해 서명된 인증서를 다운로드합니다.
서명된 인증서의 이름을 바꾸고 생성된 폴더 구조에 저장합니다.

개별 Thales CipherTrust Manager 인증서에 서명하는 것 외에도 CA 루트 인증서는 신뢰 체인의 중요한 부분입니다. 이 루트 인증서는 CA 역할을 하는 Thales CipherTrust Manager에서 발급한 모든 인증서에 대한 신뢰의 기초를 설정합니다.

CA, 로컬로 이동하고 Thales CipherTrust Manager AMS CA 끝에 있는 3개의 점을 누른 다음 다운로드를 눌러 Thales CipherTrust Manager AMS CA의 루트 CA 인증서를 다운로드합니다.
다운로드한 루트 인증서를 생성된 폴더 구조에 저장합니다.
다음 단계는 서명된 인증서, CA 루트 인증서 및 개인 키를 단일 파일로 번들로 제공하는 전체 인증서 체인 파일을 만드는 것입니다.

원활한 TLS 구성을 위해 Thales CipherTrust Manager와 같은 응용 프로그램이나 어플라이언스에 필요합니다.
```
-----BEGIN CERTIFICATE-----
Signed CTM1 Cert by CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Root CA Cert
-----END CERTIFICATE-----
-----BEGIN EC PRIVATE KEY-----
Private Key
-----END EC PRIVATE KEY-----
```
Thales CipherTrust Manager에 대해 이 작업을 수행하고 새로 연결된 인증서 파일을 생성된 폴더 구조에 저장합니다.
CA에서 서명된 인증서를 만들고 전체 인증서 체인 파일을 준비한 후 다음 단계는 각 Thales CipherTrust Manager 어플라이언스에 업로드하는 것입니다.

AMS에서 실행되는 첫 번째 CTM1부터 시작하겠습니다.
Admin Settings(관리 설정), Interfaces(인터페이스)로 이동하고 웹 인터페이스의 3개 점을 누른 다음 Renewal Certificate Options(인증서 옵션 갱신)를 선택합니다.
업로드/생성을 선택하고 확인을 누릅니다.
PEM 형식을 사용하여 CTM1에 대한 전체 체인 인증서를 업로드하고 인증서 업로드를 누릅니다.
다시 웹 인터페이스의 3개 점을 누르고 Renewal Certificate Options를 선택합니다.
Apply(적용)를 선택하고 Ok(확인)를 누릅니다.
적용을 누릅니다.
서비스 페이지를 누릅니다.
System Restart를 누릅니다.
Restart Services를 눌러 서버 및 웹 서비스를 다시 시작하여 새 인증서를 활성화합니다.
ASH에서 실행되는 CTM2에 대해 동일한 단계를 반복합니다.
Google Chrome을 사용하여 로컬 환경에서 새로 서명된 인증서를 테스트하려면 먼저 해당 인증서와 해당 CA 체인을 운영 체제의 신뢰할 수 있는 인증서 저장소에 설치해야 합니다.

이 자습서의 범위를 벗어났지만 Thales CipherTrust Manager AMS CA가 서명한 새로운 Thales CipherTrust Manager 인증서를 테스트한 방법을 보여 드리겠습니다.
Google Chrome 브라우저 설정을 열고 개인 정보 및 보안으로 이동한 다음 보안을 누릅니다.
인증서 관리를 누릅니다.
로컬 인증서를 누르고 사용자정의 섹션에서 설치한 사용자를 누릅니다.

로컬 OS에서 전체 체인 인증서 및 루트 인증서를 이미 가져왔습니다.

또한 인증서를 가져올 수 있습니다. 이 임포트 단추를 누르면 OS 레벨 인증서 설정이 표시됩니다.
인터넷에 DNS 서버를 구성하지 않았기 때문에 수동 호스트 항목으로 로컬 /etc/hosts 파일을 업데이트하여 FQDN을 사용하여 로컬 시스템의 인증서를 테스트하고 있습니다.
Google Chrome을 사용하여 CTM1 FQDN으로 이동하고 보안 설정을 클릭합니다.
Connection is secure를 누릅니다.
인증서가 유효함을 누릅니다.
발행 대상 세부정보를 검토합니다.

작업 9: Thales CCKM 어플라이언스 클러스터링 구성

Clustering Thales CipherTrust Cloud Key Manager(CCKM) 어플라이언스는 암호화 키 관리를 위해 고가용성 및 로드 밸런싱을 지원합니다. 이를 통해 보안 인프라에서 지속적인 서비스와 내결함성을 보장할 수 있습니다.

클러스터링은 전적으로 단일(기본) Thales CipherTrust Manager 어플라이언스의 관리 콘솔에서 구성됩니다(이 예에서는 AMS에서 실행되는 Thales CipherTrust Manager). 이 어플라이언스의 인터페이스를 사용하여 클러스터를 만들고 다른 Thales CipherTrust Manager 어플라이언스를 클러스터 노드로 추가합니다.

관리 설정, 클러스터로 이동하고 클러스터 관리를 누릅니다.
Add cluster(클러스터 추가)를 누릅니다.
다음을 누릅니다.
AMS Thales CipherTrust Manager(개인 IP 10.222.10.111가 있는 AMS의 CTM1)의 호스트 이름을 입력합니다.

공용 IP를 사용하여 인터넷을 통해 클러스터를 사용(또는 생성)할 의도가 없으므로 두 필드 모두에서 전용 IP 주소를 사용하고 있습니다.
클러스터 추가를 누릅니다.
이 시스템은 새 클러스터를 생성했으며 해당 클러스터의 일부입니다.
동일한 AMS CTM1에서 클러스터 관리를 누르고 노드 추가를 선택하여 ASH CTM2를 추가합니다.
ASH Thales CipherTrust Manager IP 주소를 클러스터에 추가할 노드로 지정합니다. 여기서 DNS 이름을 사용할 수 있습니다.
Add Node(노드 추가)를 누릅니다.
새 브라우저 창/탭이 ASH CMT2에 열립니다. ASH CMT2에 로그인하지 않은 경우 먼저 로그인 프롬프트가 표시될 수 있습니다.
일부 클러스터 구성 작업은 백그라운드에서 수행됩니다.
가입을 눌러 조인을 확인합니다.
백그라운드에서 더 많은 클러스터 구성 작업이 발생합니다.
완료!를 눌러 성공 메시지를 확인합니다.
새로 연 브라우저 창/탭이 열려 있는 경우 수동으로 닫을 수 있습니다.
AMS CTM1에서 완료됨을 눌러 확인합니다.
처음에는 새로 추가된 노드(ASH CTM2)가 아래로 나타납니다. 클러스터가 존재하는지 감지할 수 있도록 몇 분 동안 기다립니다.
화면 상단에 오류 메시지가 표시될 수도 있습니다. 즉, 클러스터가 여전히 구성 모드에 있습니다. 메시지가 사라질 때까지 몇 분 정도 기다립니다.

Thales CipherTrust Manager 클러스터 구성이 올바르게 수행되고 정상 상태인지 확인하려면 CTM1 및 CTM2를 확인할 수 있습니다.

CTM1에서 관리 설정으로 이동하고 클러스터를 누릅니다.
- IP 주소 10.222.10.111은 이 서버(AMS CTM1)에서 가져온 것입니다.
- 원격 서버의 다른 노드(10.111.10.32)(ASH CTM2)를 확인합니다.
CTM2에서 관리 설정으로 이동하고 클러스터를 누릅니다.
- IP 주소 10.111.10.32은 이 서버(ASH CTM2)에서 가져온 것입니다.
- 원격 서버의 다른 노드(10.222.10.111)(AMS CTM1)를 확인합니다.

다음 이미지는 지금까지 배치의 현재 상태를 보여줍니다.

다음 단계

이 자습서에서는 OCI 내에 두 개의 Thales CCKM 어플라이언스를 성공적으로 설정하고, 이들 사이에 보안 클러스터를 설정하고, 하나의 어플라이언스를 CA로 구성했습니다. 어플라이언스 배포 및 네트워크 기반구조 구성에서 CSR 만들기/서명, 클러스터링 사용으로 설정까지 단계별 프로세스에 따라 고가용성 보안 키 관리 환경을 구축했습니다. 이 설정은 중앙 집중식 인증서 관리를 통해 강력한 암호화 작업을 보장하여 OCI 환경에서 보안 및 운영 복원성을 최적화합니다.

OCI API 게이트웨이 옵션 없이 Thales CipherTrust Manager를 사용하여 HYOK(Hold Your Own Key)를 구현하려면 다음 자습서를 따르십시오. OCI API Gateway 없이 Thales CipherTrust Manager를 사용하여 OCI Hold Your Own Key 설정.

OCI API Gateway 옵션과 함께 Thales CipherTrust Manager를 사용하여 HYOK(Hold Your Own Key)를 구현하려면 다음 자습서를 따르십시오. OCI API Gateway와 함께 Thales CipherTrust Manager를 사용하여 OCI Hold Your Own Key 설정.

승인

작성자 - Iwan Hoogendoorn(클라우드 네트워킹 블랙 벨트)

추가 학습 자원

docs.oracle.com/learn에서 다른 랩을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 액세스하세요. 또한 education.oracle.com/learning-explorer를 방문하여 Oracle Learning Explorer가 되십시오.

제품 설명서는 Oracle Help Center를 참조하십시오.

제목 및 저작권 정보

Set Up Two Thales CipherTrust Cloud Key Manager Appliances in OCI, Create a Cluster between them, and Configure One as a Certificate Authority

G38090-01

OCI에서 두 개의 Thales CipherTrust Cloud Key Manager Appliance 설정, 두 어플라이언스 간에 클러스터 생성 및 인증 기관으로 구성

소개

목표

작업 1: OCI VCN(가상 클라우드 네트워크) 인프라 검토

작업 2: 첫 번째 Thales CCKM 어플라이언스 배포

작업 3: 첫번째 Thales CCKM 어플라이언스에서 초기 구성 수행

작업 4: 두번째 Thales CCKM 어플라이언스 배치 및 초기 구성 수행

작업 5: Thales CCKM 어플라이언스 RPC 간의 연결 검토

작업 6: DNS 구성

작업 7: 첫번째 Thales CCKM 어플라이언스를 CA(인증 기관)로 구성

작업 8: Thales CCKM 어플라이언스에 대한 CSR 생성 및 CA의 서명

작업 9: Thales CCKM 어플라이언스 클러스터링 구성

다음 단계

관련 링크

승인

추가 학습 자원