OCIでの2つのThales CipherTrust Cloud Key Managerアプライアンスの設定、それらの間のクラスタの作成、および認証局としての1つの構成
はじめに
組織は、セキュリティ、コンプライアンス、データ主権の要件を満たすために、今日のクラウドファーストの環境で、暗号鍵の管理を強化することを求めています。Thales CipherTrust Cloud Key Manager (CCKM)は、Oracle Cloud Infrastructure (OCI)を含むマルチクラウドおよびハイブリッド環境で暗号化キーとシークレットを管理するための一元化されたソリューションを提供します。このアーキテクチャの主な機能は、独自のキーを保持(HYOK)をサポートしているため、サードパーティのクラウド・サービスを使用している場合でも暗号化キーを完全に制御できます。
このチュートリアルでは、OCIでの2つのThales CCKMアプライアンスの完全なセットアップについて説明します。
- 2つのCCKMインスタンスのデプロイ。
- それらの間に高可用性クラスタを作成します。
- 内部証明書を発行および管理するための認証局(CA)としてアプライアンスの1つを構成します。
このチュートリアルの最後には、独自のキー持込み(BYOK)、HYOK、一元化されたキー・ライフサイクル管理などの主要なユースケースをサポートする、堅牢でスケーラブルなCCKM環境があります。この設定は、最高のデータ・セキュリティ標準に準拠しながら、キー・コントロールをクラウドに拡張することを検討している企業に最適です。
ノート:このチュートリアルでは、Thales CipherTrust Cloud Key Manager (CCKM)およびThales CipherTrust Managerという用語は同じ意味で使用されます。どちらも同じ製品です。
目的
- タスク1: OCI virtual cloud Network (VCN)インフラストラクチャの確認
- タスク2: 最初のThales CCKMアプライアンスをデプロイします。
- タスク3: 最初のThales CCKMアプライアンスで初期構成を実行します。
- タスク4: 2番目のThales CCKMアプライアンスをデプロイし、CCKMで初期構成を実行します。
- タスク5: Thales CCKMアプライアンスのリモート・ピアリング接続(RPC)間の接続の確認
- タスク6: DNSの構成
- タスク7: 最初のThales CCKMアプライアンスを認証局(CA)として構成します。
- タスク8: Thales CCKMアプライアンスの両方のcloud serviceプロバイダ(CSR)を作成し、CAによって署名します。
- タスク9: Thales CCKMアプライアンス・クラスタリングの構成
タスク1: OCI Virtual Cloud Networks (VCN)インフラストラクチャの確認
Thales CCKMアプライアンスをデプロイする前に、それらをサポートする基礎となるOCIネットワーク・アーキテクチャを理解することが不可欠です。
この設定では、2つの別々のVCNsを使用しています。
- 1つのVCNがアムステルダム(AMS) OCIリージョンにあります。
- 2番目のVCNは、アッシュバーン(ASH) OCIリージョンにあります。
これらの2つのリージョンはRPCを介して接続され、リージョン間のCCKMアプライアンス間のセキュアおよび低レイテンシ通信が可能になります。このリージョン間の接続は、CCKMの高可用性、冗長性およびクラスタリングに不可欠です。
このチュートリアルでは、CCKMアプライアンスが各VCN内のパブリック・サブネットにデプロイされます。このアプローチは、たとえばSSHやWebインタフェースを介して、インターネットを介した初期アクセスと管理を簡素化します。ただし、本番環境でのベスト・プラクティスは、これらのアプライアンスをプライベート・サブネットにデプロイし、要塞ホストまたはステップストーン(ジャンプ)サーバーを介したアクセスを管理することです。これにより、パブリック・インターネットへのアプライアンスの露出が減少し、より安全なネットワーク・ポスチャと連携します。
次のタスクで、このレビュー済VCN設定内にCCKMをデプロイします。
タスク2: 最初のThales CCKMアプライアンスのデプロイ
最初のThales CCKMアプライアンスをデプロイする前に、必要なイメージがOCIで使用可能であることを確認する必要があります。
Thalesの公式ドキュメントでは、通常、CCKMイメージをOCIに直接インポートするためのOCIオブジェクト・ストレージURLを取得するためのサポート・ケースを開くことを推奨していますが、別の方法を使用します。
Thalesからローカルの610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA.ova
ファイルを受信しました。提供されたURLを使用するかわりに、次のことを行います。
.ova
アーカイブから.vmdk
ファイルを抽出します。.vmdk
ファイルをOCIオブジェクト・ストレージ・バケットにアップロードします。.vmdk
ファイルからOCIでカスタム・イメージを作成します。- このカスタム・イメージを使用してCCKMインスタンスをデプロイします。
この方法では、イメージ・インポート・プロセスを完全に制御でき、エアギャップまたはカスタム・デプロイメント・シナリオで特に役立ちます。
-
ローカル・ディスク上の新しいフォルダ内に
610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA.ova
ファイルを保存します。 -
.ova
ファイルを抽出します。 -
抽出されたフォルダの
.vmdk
ファイルを確認します。
OCIネットワーク・インフラストラクチャでは、最初のThales CCKMアプライアンスをアムステルダム(AMS)リージョンにデプロイする準備ができています。OCI Consoleにログインします。
-
「ストレージ」、「オブジェクト・ストレージ」にナビゲートし、「バケット」をクリックします。
-
正しいコンパートメントにいることを確認し、「バケットの作成」をクリックします。
-
次の情報を入力し、「作成」をクリックして終了します。
- バケット名:
CCKM_Bucket
と入力します。 - ストレージ層: 「標準(デフォルト)」を選択します。
- 他のすべての設定はデフォルトのままにします(ユースケースに暗号化またはアクセス・ポリシーが必要な場合を除く)。
- バケット名:
-
新しく作成したOCIオブジェクト・ストレージ・バケットをクリックします。
-
下へスクロール
-
「アップロード」をクリックします。
-
次の情報を入力します
- 「オブジェクト名の接頭辞」に、
610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA
と入力します。 - 他のすべての設定はデフォルトのままにします。
- ローカル・マシンから
.vmdk
ファイル(k170v-2.19.0+14195-disk1.vmdk
など)を選択し、「アップロード」をクリックしてプロセスが完了するまで待機します。
- 「オブジェクト名の接頭辞」に、
-
アップロードが終了したら、「閉じる」をクリックします。
-
.vmdk
ファイルがアップロードされていることを確認します。
.vmdk
ファイルをOCIオブジェクト・ストレージ・バケットにアップロードした後、次のステップに従ってカスタム・イメージとしてインポートします。
-
OCIコンソールに移動し、「コンピュート」に移動して、「カスタム・イメージ」をクリックします。
-
「イメージのインポート」をクリックします。
-
次を入力し、「イメージのインポート」をクリックします。
- 名前:
610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA
と入力します。 - オペレーティング・システムのバージョン: CCKMイメージ内のOSと一致します(Thalesのドキュメント(通常はDebianまたはUbuntuのバージョン)を確認してください)。
- 「OCIオブジェクト・ストレージ・バケットからのインポート」を選択します。
- バケット:バケットを選択します。
- オブジェクト:前のセクションでアップロードしたオブジェクト(
.vmdk
ファイル)を選択します。 - イメージ・タイプ: 「VMDK」を選択します。
- 名前:
-
下へスクロール
-
インポート状態が進行中で、インポート中に完了したパーセンテージがあります。
-
イメージのインポートが完了すると、イメージが使用可能になります。
-
OCIコンソールに移動し、「コンピュート」に移動して、「インスタンス」をクリックします。
-
「インスタンスの作成」をクリックします。
-
次の情報を入力します
-
名前:インスタンス名を入力します。たとえば、
CCKM-1
です。 -
選択したリージョンで使用可能なAD (アムステルダムの
AD-1
など)を選択します。
-
-
「イメージとシェイプ」セクションの下の「イメージの変更」をクリックし、「カスタム・イメージ」を選択します。
-
次の情報を入力し、「イメージの選択」をクリックします。
-
「自分のイメージ」を選択します。
-
「カスタム・イメージ」を選択します。
-
カスタム・イメージ名:インポートしたイメージを選択します。たとえば、
610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA
です。
-
-
「シェイプ」(
VM.Standard.E5.Flex
)を選択し、OCPUおよびメモリーを構成します。注意: Thales for CCKMの最小仕様要件(通常は2 OCPU / 8 GB RAM以上)を確認してください。
-
既存のVCNおよびサブネットを選択します。SSH/Webへの直接アクセス(ベスト・プラクティスに従う場合は要塞を含むプライベート・サブネット)が必要な場合は、パブリック・サブネットを使用します。
-
「プライベートIPv4アドレスの自動割当て」および「パブリックIPv4アドレスの自動割当て」を選択します。
-
「SSHキーの追加」で、「公開キー・ファイルのアップロード」を選択し、
.pub
ファイルをアップロードします。このキーは、SSHを介してVMにアクセスするために使用されます。「作成」をクリックします。インスタンスは「プロビジョニング中」状態です。
-
プロビジョニングが正常に完了すると、インスタンスの状態はRUNNINGに変わります。後で構成および管理に必要なパブリックおよびプライベートIPアドレスに注意してください。
-
SSHをテストするには、Royal TSXアプリケーションを使用し、SSHセッションを構成します。
-
Royal TSXセッションの「資格証明」タブで、ユーザー名を指定します。たとえば、
ksadmin
です。 -
対応する秘密キー・ファイルも選択してください。
-
新しくデプロイしたCCKMにSSHでログインします。
-
CCKMを構成するには、Web GUIを使用します。
-
Webブラウザを使用して内部で接続する場合は、パブリックIPアドレスまたはプライベートIPを参照します。
-
どのCAも自己署名証明書を検証できないため、「拡張」をクリックします。
-
接続を続行します。
-
次のエラーが表示されることがあります。これは、インスタンス上のすべてのサービスが起動されていないことを意味します。すべてのサービスが起動するまで待機します。これには最大5分かかる場合があります。
-
すべてのサービスが開始されると、すべてのサービスで問題ないというメッセージが表示されます。
-
admin
として「ユーザー名」、admin
として「パスワード」を使用してログインします。初回ログイン後に、パスワードの変更を求められます。 -
手順に従ってパスワードを変更します。
-
新しいパスワードを使用してログインします。
-
ログインし、CCKMが正常にデプロイされていることを確認します。
次の図は、これまでのデプロイメントの現在の状態を示しています。
タスク3: 最初の販売CCKMアプライアンスでの初期構成の実行
最初のCCKMアプライアンスがデプロイされ、アクセス可能になったので、初期構成を実行します。これには、NTPサーバーを使用してシステム・クロックを設定し、評価ライセンスまたはThalesが提供する実際のライセンスをアクティブ化することが含まれます。
これらの手順により、アプライアンスは証明書の管理、ロギング、および同期に不可欠な正確な時間で動作し、評価または設定フェーズで完全に機能するようになります。
-
「管理設定」、「NTP」にナビゲートし、「NTPサーバーの追加」を選択します。
-
信頼できるNTPサーバーのホスト名またはIPアドレス(たとえば、
169.254.169.254
(OracleのパブリックNTPサーバーIP)または組織の内部NTPソース)を入力し、「NTPサーバーの追加」をクリックします。 -
NTPサーバーが正常に追加されたことを示すメッセージが表示されます。「閉じる」をクリックします。
-
時刻が正しく同期されていることを確認します。
-
「管理設定」、「ライセンス」に移動して、「CipherTrustプラットフォーム評価の開始」をクリックします。
-
下へスクロール
-
Click Start CipherTrust Platform Evaluation.
-
ライセンスがアクティブ化されるまでに数分かかります。
-
アクティブ化されたライセンスを確認します。
タスク4: 2番目の販売CCKMアプライアンスのデプロイおよび初期構成の実行
タスク2およびタスク3のステップに従って、2番目のCCKMをASHリージョンにデプロイします。
-
2番目のCCKMがデプロイされ、RUNNINGであることを確認します。
-
SSHと2番目のCCKMの間の接続をテストします。
-
Webと2番目のCCKM間の接続をテストします。
次の図は、これまでのデプロイメントの現在の状態を示しています。
タスク5: Thales CCKMアプライアンスRPC間の接続の確認
2つのThales CCKMアプライアンス間の高可用性およびクラスタリングを準備するには、それらがデプロイされているリージョン間の適切な接続を確保することが不可欠です。
このセットアップでは、アムステルダム(AMS)とアッシュバーン(ASH)のOCIリージョンの間にRPCが確立されています。このRPCにより、各CCKMアプライアンスが存在する2つのVCNs間のセキュアな低レイテンシの通信が可能になります。
構成内容:
- リモート・ピアリング接続(RPC)が確立され、AMSとASHの間でアクティブになります。
- ルーティング表は、2つのVCNs間のトラフィックが正しく転送されるように適切に構成されます。
- 両方のリージョンのセキュリティ・リストは現在、すべてのイングレス・トラフィックとエグレス・トラフィックを許可するように構成されています。これは、概念実証(PoC)のテストを簡素化し、初期設定およびクラスタリング・プロセス中の接続関連の問題を排除するために行われます。
ノート:
- 本番環境では、クラスタリングおよび管理のために、トラフィックを必要なポートのみに制限することを強くお薦めします。
- 正確なポート要件(たとえば、
443
、8443
、5432
などのTCPポート、およびCCKMクラスタ・プロトコルで使用されるその他のポート)については、Thalesのドキュメントを参照してください。
このクロスリージョン・ネットワーク設定により、クラスタ作成プロセス中にCCKMがシームレスに通信できるようになり、次の項のいずれかで対処します。
タスク6: DNSの構成
2つのアプライアンス間のシームレスな通信を可能にするには、適切なDNS解決が必要です。これは、セキュアなクラスタリング、証明書処理、およびサービス全体の安定性のために特に重要です。
ノート:この時点から、Thales CCKMアプライアンスをThales CipherTrust Managerと呼びます(CyberTrust Managerの略)。
カスタムの内部DNSサーバーを使用しているときに、このデプロイメントではプライベートDNSゾーンでOCI DNSサービスを利用しています。これにより、意味のある完全修飾ドメイン名(FQDN)をThales CipherTrust Managerに割り当て、静的IPに依存することなくリージョン間で通信できるようになります。
- プライベートDNSゾーン名:
oci-thales.lab
と入力します。 - スコープ: 「プライベート」を選択します。
- 関連付けられたVCNs: AMSとASHの両方のVCNs (リージョン間の名前解決を許可するため)。
oci-thales.lab
ゾーン内に2つのAレコードを作成し、各Thales CipherTrust ManagerアプライアンスのプライベートIPを指しています。
ホスト名 | FQDN | ポイント |
---|---|---|
ctm1 |
ctm1.oci-thales.lab |
AMSのThales CipherTrust ManagerのプライベートIP |
ctm2 |
ctm2.oci-thales.lab |
ASHのThales CipherTrust ManagerのプライベートIP |
FQDNを使用すると、証明書およびクラスタ構成の管理が容易になり、構成と固定IPとの結合が回避されます。
-
OCIコンソールに移動し、Virtual Cloud Networksに移動します。AMSリージョンにいることを確認します。
-
VCNをクリックします。
-
(そのVCNの)「DNSリゾルバ」をクリックします。
-
「デフォルト・プライベート・ビュー」(そのDNSリゾルバおよびVCN)をクリックします。
-
「ゾーンの作成」をクリックします。
-
次の情報を入力し、「作成」をクリックします。
- ゾーン名:
oci-thales.lab
と入力します。 - コンパートメント:正しいコンパートメントを選択します。
- ゾーン名:
-
ゾーンをクリックします。
-
「レコードの管理」をクリックします。
-
「レコードの追加」をクリックします。
-
ctm1
のレコードを作成するには、次の情報を入力します。- レコード・タイプ: A - IPv4 addressと入力します。
- 名前:
ctm1
と入力します。 - TTL:デフォルトのままにします(たとえば、
300
)。
-
「Private IP of Thales CipherTrust Manager in AMS」にRDATA (IP Address)と入力し、「Save Changes」をクリックします。
-
ctm2
の2番目のAレコードを作成します。- レコード・タイプ: A - IPv4 addressと入力します。
- 名前:
ctm2
と入力します。 - TTL:デフォルトのままにします(たとえば、
300
)。
-
「ASHのThales CipherTrust ManagerのプライベートIP」にRDATA (IPアドレス)と入力し、「変更の保存」をクリックします。
-
「変更の公開」をクリックします。
-
ASHでAMSに対して実行した同じステップを繰り返して、ASHでのDNS名解決を許可します。
DNSが期待どおりに機能していることを確認するには、Thales CipherTrust ManagerインスタンスのいずれかにSSHで接続し、最初のThales CipherTrust Manager (AMSで実行)からping ctm2.oci-thales.lab
を実行します。
FQDNは正しいIPアドレスに解決され、RPC、ルーティングおよびセキュリティ・リストが正しく構成されると、pingは成功します。
pingをCTM2 (ASHで実行)から繰り返して、双方向の解決を確認します。
タスク7: 最初のThales CCKMアプライアンスを認証局(CA)として構成する
CipherTrustマネージャを初めて起動すると、新しいローカルCipherTrust Manager Root CA
が自動的に生成されます。このCAは、システムで使用可能なインタフェースの初期サーバー証明書を発行するために使用されます。そのため、新しいものを作る必要はありません。
ノート: AMS Thales CipherTrust Managerを使用していることを確認してください。
-
「CA」をクリックし、「ローカル」を選択します。
-
CSRの作成および署名に使用するローカルで自動生成されたCA (CipherTrustマネージャ・ルートCA)を確認します。
次の図は、これまでのデプロイメントの現在の状態を示しています。
タスク8: Thales CCKMアプライアンスとCAによる署名の両方のCSRの作成
CyberTrustマネージャ・アプライアンスがデプロイされ、DNSが構成された状態で、セキュアな証明書ベースの通信を有効にする時期です。AMS Thales CipherTrust ManagerおよびASHはCAとして構成されているため、AMS Thales CipherTrust Managerを使用して、両方のアプライアンスの証明書を生成および署名します。
-
主なステップは次のとおりです:
-
AMS Thales CipherTrust Managerで、Thales CipherTrust Manager (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
)を「表示名」として使用し、生成されたCSRの内容をCSRフィールドにコピーします。 -
「証明書の目的」として「サーバー」を選択し、「証明書の発行」をクリックします。
-
署名付き証明書エントリの最後にある3つのドットをクリックし、「ダウンロード」をクリックして、CTM1の署名付き証明書をダウンロードします。
-
同じステップ(Thales CipherTrust Manager AMS CA)を繰り返します。
-
Thales CipherTrust ManagerのFQDN (たとえば、
ctm2.oci-thales.lab
)を「表示名」として使用し、生成されたCSRの内容をCSRフィールドにコピーします。 -
「証明書の目的」として「サーバー」を選択し、「証明書の発行」をクリックします。
-
署名付き証明書エントリの最後にある3つのドットをクリックし、「ダウンロード」をクリックして、CTM2の署名付き証明書をダウンロードします。
-
署名付き証明書の名前を変更して、作成したフォルダ構造に格納します。
個々のThales CipherTrust Manager証明書に署名するだけでなく、CAルート証明書はトラスト・チェーンの重要な部分です。このルート証明書は、CAとして機能するThales CipherTrust Managerによって発行されたすべての証明書の信頼の基盤を確立します。
-
「CA」、「ローカル」にナビゲートし、Thales CipherTrust Manager AMS CAの最後にある3つのドットをクリックし、「ダウンロード」をクリックして、Thales CipherTrust Manager AMS CAのルートCA証明書をダウンロードします。
-
ダウンロードしたルート証明書を、作成したフォルダ構造に格納します。
-
次のステップでは、署名付き証明書、CAルート証明書および秘密キーを1つのファイルにバンドルする完全な証明書チェーン・ファイルを作成します。
これは、シームレスな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から始めます。
-
「管理設定」、「インタフェース」にナビゲートし、Webインタフェースの3つのドットをクリックして、「証明書の更新オプション」を選択します。
-
「アップロード/生成」を選択し、「OK」をクリックします。
-
PEM形式を使用してCTM1の完全なチェーン証明書をアップロードし、「証明書のアップロード」をクリックします。
-
再度、Webインタフェースの3つのドットをクリックし、「証明書の更新オプション」を選択します。
-
「適用」を選択し、「OK」をクリックします。
-
「適用」をクリックします。
-
「サービス・ページ」をクリックします。
-
「システム再起動」をクリックします。
-
「サービスの再起動」をクリックして、サーバーおよびWebサービスを再起動し、新しい証明書をアクティブ化します。
-
ASHで実行されているCTM2に対して同じステップを繰り返します。
-
Google Chromeを使用してローカル環境で新しく署名された証明書をテストするには、まず、その証明書とそのCAチェーンをオペレーティング・システムの信頼できる証明書ストアにインストールする必要があります。
これはこのチュートリアルの範囲外ですが、Thales CipherTrust Manager AMS CAによって署名された新しいThales CipherTrust Manager証明書をテストする方法を説明します。
-
Google Chromeブラウザの設定を開き、「プライバシとセキュリティ」に移動して「セキュリティ」をクリックします。
-
「証明書の管理」をクリックします。
-
「ローカル証明書」をクリックし、「カスタム」セクションで「インストール済」をクリックします。
-
ローカルOSに完全なチェーン証明書およびルート証明書がすでにインポートされています。
ここで証明書をインポートすることもできます。この「インポート」ボタンをクリックすると、OSレベルの証明書設定が表示されます。
-
インターネット上でDNSサーバーを構成していないため、FQDNを使用してローカル・マシンから証明書をテストするために、手動ホスト・エントリでローカルの
/etc/hosts
ファイルを更新しています。 -
Google Chromeを使用してCTM1 FQDNを参照し、セキュリティ設定をクリックします。
-
「接続は安全です」をクリックします。
-
「証明書は有効です」をクリックします。
-
「発行先」の詳細を確認します。
タスク9: Thales CCKMアプライアンス・クラスタリングの構成
Clustering Thales CipherTrust Cloud Key Manager (CCKM)アプライアンスは、暗号化鍵管理のための高可用性およびロード・バランシングを可能にします。これにより、セキュリティ・インフラストラクチャの継続的なサービスとフォルト・トレランスが保証されます。
クラスタリングは、単一(プライマリ)のThales CipherTrust Managerアプライアンス(この例では、AMSで実行されているThales CipherTrust Manager)の管理コンソールから完全に構成されます。このアプライアンスのインタフェースを使用して、クラスタを作成し、他のThales CipherTrust Managerアプライアンスをクラスタ・ノードとして追加します。
-
「管理設定」、「クラスタ」にナビゲートし、「クラスタの管理」をクリックします。
-
「クラスタの追加」をクリックします。
-
「次」をクリックします。
-
AMS Thales CipherTrust Manager (プライベートIP 10.222.10.111を持つAMSのCTM1)のホスト名を入力します。
パブリックIPを使用してインターネット上でクラスタを使用(または作成)するつもりはないため、両方のフィールドでプライベートIPアドレスを使用しています。
-
「クラスタの追加」をクリックします。
-
このマシンが新しいクラスタを作成し、そのクラスタの一部であることを確認します。
-
同じAMS CTM1で、「クラスタの管理」をクリックし、「ノードの追加」を選択してASH CTM2を追加します。
-
クラスタに追加するノードとしてASH Thales CipherTrust Manager IPアドレスを指定します。ここではDNS名を使用できます。
-
「ノードの追加」をクリックします。
-
新しいブラウザ・ウィンドウ/タブがASH CMT2に対して開きます。ASH CMT2にログインしていない場合は、最初にログイン・プロンプトが表示されることがあります。
-
一部のクラスタ構成アクティビティーはバックグラウンドで発生します。
-
「結合」をクリックして結合を確認します。
-
バックグラウンドでさらにいくつかのクラスタ構成アクティビティが発生します。
-
「終了」をクリックして、「成功」メッセージを確認します。
-
新しく開いたブラウザ・ウィンドウ/タブがまだ開いている場合は、手動で閉じることができます。
-
AMS CTM1で、「終了」をクリックして確認します。
-
最初に、新しく追加されたノード(ASH CTM2)が表示されます。クラスタがその存在を検出できるように、数分待ちます。
-
また、画面上部にエラー・メッセージが表示される場合もあります。つまり、クラスタはまだ構成モードです。メッセージが消えるまで数分待ちます。
ThalesのCipherTrust Managerクラスタ構成が正しく行われ、正常であるかどうかを確認するには、CTM1およびCTM2をチェックします。
-
CTM1で、「管理設定」にナビゲートし、「クラスタ」をクリックします。
- IPアドレス
10.222.10.111
は、このサーバー(AMS CTM1)からのものです。 - リモート・サーバー(ASH CTM2)のもう一方のノード(
10.111.10.32
)を確認します。
- IPアドレス
-
CTM2で、「管理設定」にナビゲートし、「クラスタ」をクリックします。
-
IPアドレス
10.111.10.32
は、このサーバー(ASH CTM2)からのものです。 -
リモート・サーバー(AMS CTM1)からの他のノード(
10.222.10.111
)を確認します。
-
次の図は、これまでのデプロイメントの現在の状態を示しています。
次のステップ
このチュートリアルでは、OCI内で2つのThales CCKMアプライアンスを正常に設定し、それらの間にセキュアなクラスタを確立し、1つのアプライアンスをCAとして構成しました。アプライアンスのデプロイ、ネットワーク・インフラストラクチャの構成からCSRの作成と署名、およびクラスタリングの有効化までのステップバイステップのプロセスに従って、可用性が高くセキュアなキー管理環境を構築しました。この設定により、一元化された証明書管理による堅牢な暗号化操作が保証され、OCI環境でのセキュリティと運用の回復力が最適化されます。
Hold Your Own Key (HYOK) using Thales CipherTrust Manager without OCI API Gatewayオプションを実装する場合は、次のチュートリアルに従います: OCI API Gatewayを使用しないThales CipherTrust Managerを使用したOCI Hold Your Own Keyの設定。
Hold Your Own Key (HYOK) using Thales CipherTrust Manager with the OCI API Gatewayオプションを実装する場合は、次のチュートリアルに従います: Thales CipherTrust Manager with OCI API Gatewayを使用した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
G38089-01
Copyright ©2025, Oracle and/or its affiliates.