高可用性を実現するためにOCIロード・バランサを使用するThales CipherTrust Managerを使用したOCI HYOKの有効化

はじめに

前のチュートリアルでは、Thales CipherTrust ManagerとOracle Cloud Infrastructure (OCI)の統合を検討して、OCI API Gatewayの有無にかかわらず、Hold Your Own Key (HYOK)機能を有効にしました。CipherTrust Managerのクラスタリングはリカバリ可能性のレベルを提供しますが、ネットワークの観点から正確な高可用性を保証するものではありません。

Thales CipherTrust Managerでは、ノード間のシームレスなフェイルオーバーのために仮想IPアドレス(VIPアドレス)をネイティブにサポートしていません。

このチュートリアルでは、OCIロード・バランサを導入して、Thales CipherTrust Managerインスタンスに高いネットワーク可用性を提供することで、この制限に対処します。クラスタ化されたCipherTrustマネージャをOCIロード・バランサの背後に配置することで、ノード障害やデータ・センターが中断した場合でも、OCIの外部キー管理サービスの継続的な可用性とフォルト・トレランスを確保できます。

このチュートリアルでは、この設定をOCI環境にデプロイするためのアーキテクチャ、構成および考慮事項について説明します。

目的

• タスク1: 既存のOCIおよびThales CipherTrust Manager HYOKアーキテクチャの確認
• タスク2: OCIロード・バランサの作成
• タスク3: OCIロード・バランサと既存のOCI APIゲートウェイベースのHYOKデプロイメントの統合
• タスク4: OCIロード・バランサとOCI API Gatewayを使用しない既存のHYOKデプロイメントの統合
• タスク5: すべてのOCIおよびThales CipherTrust Manager HYOKアーキテクチャを確認して、Thales CipherTrust Managerの高可用性を実現します。

タスク1: 既存のOCIおよびThales CipherTrust Manager HYOKアーキテクチャの確認

OCIロード・バランサをアーキテクチャに導入する前に、既存のOCIおよびThales CipherTrust Manager HYOKデプロイメントを再確認する必要があります。以前の実装では、次の2つの主なパターンについて説明しました。

• OCI APIゲートウェイを使用したThales CipherTrust Managerを使用したOCI Hold Your Own Keyの設定

• OCI API Gatewayを使用しないThales CipherTrust Managerを使用したOCI Hold Your Own Keyの設定

この項では、これら2つの設計について簡単に要約し、その長所と制限事項を強調して、可用性ギャップを埋めるためにOCIロード・バランサを導入するための基盤を設定します。

どちらのアーキテクチャも、リカバリ性を提供するために複数のThales CipherTrust Managerをクラスタリングすることに依存していましたが、Thales CipherTrust ManagerにネイティブVIPアドレスサポートがないため、ネットワークレベルの正確な高可用性が不足していました。各デプロイメントは、キー管理を効果的に処理しましたが、ネットワーク・ルーティングとサービスのアクセシビリティの観点から、潜在的な単一障害点が導入されました。

開始する前に、次の場所があることを確認してください。

• 異なる可用性ドメインまたはフォルト・ドメイン(およびクラスタ化)にデプロイされた2つ以上のThales CipherTrust Managerインスタンス。詳細は、OCIでの2つのThales CipherTrust Cloud Key Managerアプライアンスの設定、それらの間のクラスタの作成、および認証局としての1つの構成を参照してください。

• 適切なサブネット(アーキテクチャに応じてプライベートまたはパブリック)を持つVCN。ここでは、OCIロード・バランサを配置します。

• 証明書(OCIロード・バランサでSSL終端を使用している場合)。これは、このチュートリアルで説明する内容です。

タスク2: OCIロード・バランサの作成

ネットワーク・レイヤーでThales CipherTrust Managerの高可用性を実現するために、OCI Load Balancerをアーキテクチャに導入します。OCIロード・バランサは、クラスタ化されたThales CipherTrust Managerノード間で受信リクエストをインテリジェントに分散する、単一の自己回復性のあるアクセス・ポイントになります。

このタスクは、複数のThales CipherTrust Managerインスタンスに対応するOCIロード・バランサを提供します。OCI API Gatewayを使用しているかどうかに関係なく、バックエンド・セット、ヘルス・チェック、SSL終了(該当する場合)およびHYOKデプロイメントに合せたリスナー・ルールを構成します。

このOCIロード・バランサの設定により、Thales CipherTrust Managerノードの1つが使用できなくなった場合でも、キー管理サービスにアクセスできるようになるため、OCIとの外部キー管理統合の信頼性とフォルト・トレランスが大幅に向上します。

• OCIコンソールにログインし、「ネットワーキング」に移動して、「ロード・バランサ」をクリックします。

  

• 「ロード・バランサの作成」をクリックします。

  

• 次の情報を入力します

  • 名前:わかりやすい名前(たとえばLoad_Balancer_for_CCKM)を入力します。
  • タイプ:ユースケースに応じて、「プライベート」または「パブリック」を選択します。

  

  • VCNおよびサブネット: OCIロード・バランサが適切なコンパートメントにデプロイされるVCNおよびサブネットを選択します。
  • 「次」をクリックします。

  

  • ポリシー: 「重み付けラウンド・ロビン」を選択します。
  • 「バックエンド・サーバーの選択」は空白のままにします。後で構成します。

  

  • ヘルス・チェック・ポリシー:ここでは、ポート80のHTTPを選択します。これは後で変更します。

  

  • バックエンド・セット名:わかりやすい名前(CTM_Appliancesなど)を入力します。
  • 「次」をクリックします。

  

  • リスナー名:わかりやすい名前(たとえばLISTENER)を入力します。
  • リスナー・トラフィック・タイプおよびポート: TCPおよびポート80。これらは後で変更します。
  • 「次」をクリックします。

  

  • すべてのロギング設定はデフォルトのままにします。
  • 「次」をクリックします。

  

• 情報を確認し、「発行」をクリックします。

  

• OCIロード・バランサが作成されることに注意してください。数分後、「アクティブ」と表示されます。

  

• 「リスナー」をクリックして、編集する必要があるリスナーを確認します。

  

• 「バックエンド・セット」をクリックして、編集する必要があるバックエンド・セットを確認します。また、健全性は「未完了」と表示されます。これは、ThalesのCipherTrust Managerバックエンド・サーバーをセットに追加する必要があるためです。

  

• リスナーおよびバックエンド・セットをSSLで構成する前に、証明書を追加する必要があります。追加するには、「証明書および暗号」に移動し、「証明書の追加」をクリックします。

  

• OCIロード・バランサに対して有効な署名付き証明書および秘密キーが作成されていることを確認します。

  証明書署名リクエスト(CSR)を作成し、Thales CipherTrust Managerを使用してローカルCAで証明書に署名するには、「Thales CCKMアプライアンスとCAによる署名の両方のCSRの作成」を参照してください。

  

• また、ルートCA(バンドル準備完了)があることを確認してください。

  

• 「証明書の追加」で、次の情報を入力します。

  • 証明書名:わかりやすい名前(LB-CTM-CERTなど)を入力します。
  • 「SSL証明書の貼付け」を選択します。
  • SSL証明書:署名付きSSL証明書を貼り付けます。

  

  • 「CA証明書の指定」を選択します。
  • 「CA証明書の貼付け」を選択します。
  • CA証明書: CA (バンドル)証明書を貼り付けます。

  

  • 「秘密キーを指定」を選択します。
  • 「秘密キーの貼付け」を選択します。
  • 秘密キー:秘密キーを貼り付けます。
  • 「証明書の追加」をクリックします。

  

• 「発行された作業リクエスト」が受け入れられ、「すべての作業リクエストの表示」をクリックします。

  

• リクエストが成功したことに注意してください。

  

• 「証明書と暗号」にナビゲートし、証明書が追加されたことを確認します。

  

• 「バックエンド・セット」にナビゲートし、3つのドットをクリックして、作成したバックエンド・セットのメニューを開き、「編集」をクリックします。

  

• 「バックエンド・セットの編集」で、次の情報を入力します。

  • SSLを有効にするには、「SSLの使用」を選択します。
  • 証明書リソース: 「ロード・バランサ管理対象証明書」を選択します。
  • 証明書名を選択します。
  • 「変更の保存」をクリックします。

  

• 「閉じる」をクリックします。

  

• 「リスナー」にナビゲートし、3つのドットをクリックして、作成したバックエンド・セットのメニューを開き、「編集」をクリックします。

  

• 「リスナーの編集」で、次の情報を入力します。

  • プロトコル: 「TCP」を選択します。
  • ポート: 「443」を選択します。
  • 「SSLの使用」を選択します。
  • 証明書リソース: 「ロード・バランサ管理対象証明書」を選択します。
  • 「証明書名」を選択します。
  • 「変更の保存」をクリックします。

  

• 「閉じる」をクリックします。

  

• リスナーは、TCPポート443でリスニングしています。

  

• 「バックエンド・セット」にナビゲートし、ヘルスがまだ不完全であることを確認します。これは、セットにバックエンドとしてサーバーを追加していないためです。

  

• 3つのドットをクリックして、作成したバックエンド・セットのメニューを開き、「ヘルス・チェックの更新」をクリックします。

  

• 「ヘルス・チェックの更新」で、次の情報を入力します。

  • プロトコル: 「TCP」を選択します。
  • ポート: 「443」を選択します。
  • 「変更の保存」をクリックします。

  

• 「閉じる」をクリックします。

  

• 前に作成したバックエンド・セットをクリックします。

  

• 「バックエンド」をクリックし、「バックエンドの追加」をクリックします。

  

• 「バックエンドの追加」で、次の情報を入力します。

  • バックエンド・タイプ: IPアドレスを選択します。
  • 次のバックエンド(CTMのIPアドレス)を追加します。
    • CTM 1 (ミリ秒)
      • IPアドレス: 10.111.10.32と入力します。
      • ポート: 「443」を選択します。
      • 重み: 「1」を選択します。
    • CTM 2 (アッシュ)
      • IPアドレス: 10.222.10.111と入力します。
      • ポート: 「443」を選択します。
      • 重み: 「2」を選択します。
  • 「追加」をクリックします。

  

• 健全性は「クリティカル」として表示されます。Thales CipherTrust Managerサーバーでのヘルス・チェックの実行には、1分かかる場合があります。

  

• ヘルスが「OK」に変更されました。次に、バックエンド・セットの概要に戻ります。

  

• バックエンド・セットの全体的なヘルスも「OK」であることに注意してください。次に、OCIロード・バランサの概要に戻ります。

  

• OCIロード・バランサがアクティブで、全体的な状態が「OK」で、ロード・バランサにIPアドレスがあることに注意してください。

  

ロード・バランサのDNSレコードを作成してください。OCI VCN内のプライベートDNSリスナーにAレコードを作成しました。

タスク3: OCIロード・バランサと既存のOCI APIゲートウェイベースのHYOKデプロイメントの統合

このタスクでは、OCIロード・バランサを既存のOCI APIゲートウェイベースのHYOKデプロイメントに統合し、シームレスで可用性の高いアーキテクチャを確保します。

このアーキテクチャでは、OCI API GatewayとOCI Load Balancerの長所を組み合わせて、OCI HYOKとThales CipherTrust Managerとの統合の信頼性とセキュリティを強化しています。

OCI API Gatewayは、引き続きセキュアな公開エントリ・ポイントとして機能し、認証、認可およびルーティング・ポリシーを適用します。その背後には、OCIロード・バランサが複数のCipherTrust Managerノードにリクエストを分散し、ネットワーク・レイヤーでの高可用性とフォルト・トレランスを確保します。

この階層設計では、OCI APIゲートウェイを介してセキュアなアクセス・モデルを維持します。これは、OCIロード・バランサを介して回復力のあるバックエンドを導入することで、Thales CipherTrust ManagerのネイティブVIPアドレスサポートの欠如に対処します。

• 次のチュートリアルで作成したOCI API Gatewayに移動します: Thales CipherTrust ManagerとOCI API Gatewayを使用したOCI Hold Your Own Keyの設定。

  

• 「デプロイメント」に移動して、「デプロイメント」をクリックします。

  

• 「編集」をクリックします。

  

• 「ルート」をクリックします。

  

• URLは、AMS CTMであるctm1.oci-thales.lab FQDNを指していることに注意してください。

  

• 「URL」を、作成したOCIロード・バランサであるlb-ctm.oci-thales.lab FQDNを指すように変更し、「次へ」をクリックして、必ず変更を保存します。

  

次の図は、OCI APIゲートウェイおよびOCIロード・バランサがアーキテクチャに統合されたエンドツーエンドのトラフィック・フローを示しています。

タスク4: OCI APIゲートウェイベースのHYOKデプロイメントを使用せずに、OCIロード・バランサを既存に統合する

このタスクでは、OCI HYOKデプロイメントでThales CipherTrust Managerの唯一のアクセス・ポイントとしてOCIロード・バランサを構成して使用する方法を学習します。これにより、クリーンで高性能な高可用性アーキテクチャを実現できます。

このアーキテクチャでは、OCI API Gatewayを削除し、OCIロード・バランサをThales CipherTrust Managerクラスタの前に直接配置することで、デプロイメントを簡素化します。このアプローチは、パブリック・アクセスが不要で、安全な内部ネットワーク内で高可用性を確保することが目的であるプライベート統合に最適です。

OCIロード・バランサを介してリクエストをルーティングすることで、ノードまたは可用性ドメインに障害が発生した場合でも、セッションの自己回復性およびフェイルオーバー機能を維持しながら、複数のThales CipherTrust Managerノードにトラフィックを分散できます。この設定は、OCI APIゲートウェイ・ポリシーおよび認証フローの複雑さを増すことなく、Thales CipherTrust ManagerのネイティブVIPアドレス・サポートの欠如の主な制限に対処します。

次のチュートリアルにリストされているタスクに従います: OCI APIゲートウェイを使用しないThales CipherTrust Managerを使用したOCI Hold Your Own Keyの設定。ただし、現在、すべての(AMS) CTM1 IPアドレスがロード・バランサのIPアドレスに変更されています。

• OCI統合アプリケーション・リソース・アプリケーション。
• CTM1外部VaultエンドポイントURLホスト名。CTMがクラスタ内にある場合、この変更は(ASH) CTM2にも同期されます。
• OCIプライベート・エンドポイント(OCI外部キー管理サービスはこれを使用します)。

これは、OCIとThales CipherTrust Managerの統合(HYOK)とパス内のOCIロード・バランサのみの詳細な統合フローです。

次の図は、OCIロード・バランサのみがアーキテクチャに統合されたエンドツーエンドのトラフィック・フローを示しています。

タスク5: すべてのOCIおよびThales CipherTrust Manager HYOKアーキテクチャを確認して、Thales CipherTrust Managerを高可用性にする

Thales CipherTrust Manager for Hold Your Own Key (HYOK)をOCIに導入するための汎用的なアプローチはありません。クラウドベースかオンプレミスかに関係なく、ネットワーク・トポロジ、セキュリティ要件および使用可能なインフラストラクチャに応じて、回復力のある可用性の高いデプロイメントを実現するために、複数のアーキテクチャ・オプションを使用できます。

この項では、高可用性に焦点を当てて、Thales CipherTrust ManagerとOCI HYOKを統合するためにサポートされているすべてのアーキテクチャ・パターンの統合概要を示します。次の組合せがあります。

• 単一またはデュアルのデータ・センターのデプロイメント。
• OCI API Gatewayの使用。
• OCIロード・バランサの使用。
• 高可用性の有無にかかわらず、オンプレミスまたはデータ・センターがホストするロード・バランサを使用します。

各アーキテクチャには、複雑さ、フェイルオーバー機能および制御に関するメリットとトレードオフがあります。完全なクラウドネイティブ設定を実行する場合でも、ハイブリッド環境で運用する場合でも、データ・センターでレガシー・ロード・バランサを活用する場合でも、適合するモデルがあります。

対象となるアーキテクチャは次のとおりです。

アーキテクチャ番号	説明
1	単一のデータ・センターでのCTM–OCI API GatewayまたはOCI Load Balancerを使用しない基本設定
2	OCI API Gatewayによる単一データ・センターでのCTM– 外部アクセス、HAなし
3	OCI API GatewayとOCI Load Balancerを備えた2つのデータセンターのCTM– 完全なHAソリューション
4	OCI API Gatewayとオンプレミス・ロード・バランサ(HAなし)を備えた2つのデータセンターのCTM– 部分的な自己回復性
5	OCI API Gatewayとオンプレミス・ロード・バランサ(HA)を備えた2つのデータセンターのCTM–HAを外部で管理
6	OCI API Gatewayとオンプレミス・ロード・バランサ(HAなし)による1つのデータセンターでのCTM– 限定フェイルオーバー
7	OCIロード・バランサのみを使用する2つのデータ・センターのCTM– 内部アクセス、OCI API Gatewayを使用しない完全なネットワーク・レベルのHA

この概要は、技術要件および運用要件に最も適合するアーキテクチャを比較および選択するのに役立ちます。

• アーキテクチャ1:次の図は、OCI API Gatewayがなく、ロード・バランシングがアーキテクチャに統合されていないエンドツーエンドのトラフィック・フローを示しています。

  

• アーキテクチャ2:次の図は、OCI APIゲートウェイのみを使用し、アーキテクチャにロード・バランシングが統合されていないエンドツーエンドのトラフィック・フローを示しています。

  

• アーキテクチャ3:次の図は、OCI APIゲートウェイおよびOCIロード・バランサがアーキテクチャに統合されたエンドツーエンドのトラフィック・フローを示しています。

  

• アーキテクチャ4、5および6:次の図は、OCI API Gatewayとオンプレミス・ロード・バランサがアーキテクチャに統合されたエンドツーエンドのトラフィック・フローを示しています。

  

• アーキテクチャ7:次の図は、OCIロード・バランサのみがアーキテクチャに統合されたエンドツーエンドのトラフィック・フローを示しています。

  

まとめ

Oracle Cloud Infrastructure (OCI) HYOKデプロイメントでThales CipherTrust Managerの高可用性を確保することは、顧客管理暗号化キーへのセキュアで中断のないアクセスを維持するために不可欠です。CipherTrust Managerをクラスタ化するとリカバリ性が向上しますが、ネットワーク・レベルで高可用性要件を満たすには不十分です。

このチュートリアルでは、OCIロード・バランサが、OCI APIゲートウェイとともに、または内部アクセス用のスタンドアロン・ソリューションとして、そのギャップをどのようにクローズできるかを実証しました。また、オンプレミスのロード・バランサを活用するハイブリッド・モデルなど、いくつかの現実世界のアーキテクチャ・パターンも確認し、インフラストラクチャ戦略と可用性の目標に沿った設計の選択を支援します。

OCIのネットワーク・サービスをThales CipherTrust Managerと慎重に統合することで、企業は、エンタープライズグレードのコンプライアンスと運用継続性をサポートする、回復力のある安全な外部キー管理ソリューションを構築できます。

確認

• 作者 - Iwan Hoogendoorn (クラウド・ネットワーキング・ブラック・ベルト)

その他の学習リソース

docs.oracle.com/learnで他のラボを確認するか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスして、Oracle Learning Explorerになります。

製品ドキュメントについては、Oracle Help Centerを参照してください。

---

タイトルおよび著作権情報

Enable OCI HYOK with Thales CipherTrust Manager Using OCI Load Balancer for High Availability

G40054-01

Copyright ©2025, Oracle and/or its affiliates.