OCIでの2つのThales CipherTrust Cloud Key Managerアプライアンスの設定、それらの間のクラスタの作成、および認証局としての1つの構成

はじめに

組織は、セキュリティ、コンプライアンス、データ主権の要件を満たすために、今日のクラウドファーストの環境で、暗号鍵の管理を強化することを求めています。Thales CipherTrust Cloud Key Manager (CCKM)は、Oracle Cloud Infrastructure (OCI)を含むマルチクラウドおよびハイブリッド環境で暗号化キーとシークレットを管理するための一元化されたソリューションを提供します。このアーキテクチャの主な機能は、独自のキーを保持(HYOK)をサポートしているため、サードパーティのクラウド・サービスを使用している場合でも暗号化キーを完全に制御できます。

このチュートリアルでは、OCIでの2つのThales CCKMアプライアンスの完全なセットアップについて説明します。

このチュートリアルの最後には、独自のキー持込み(BYOK)HYOK、一元化されたキー・ライフサイクル管理などの主要なユースケースをサポートする、堅牢でスケーラブルなCCKM環境があります。この設定は、最高のデータ・セキュリティ標準に準拠しながら、キー・コントロールをクラウドに拡張することを検討している企業に最適です。

ノート:このチュートリアルでは、Thales CipherTrust Cloud Key Manager (CCKM)およびThales CipherTrust Managerという用語は同じ意味で使用されます。どちらも同じ製品です。

イメージ

目的

タスク1: OCI Virtual Cloud Networks (VCN)インフラストラクチャの確認

Thales CCKMアプライアンスをデプロイする前に、それらをサポートする基礎となるOCIネットワーク・アーキテクチャを理解することが不可欠です。

この設定では、2つの別々のVCNsを使用しています。

これらの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を使用するかわりに、次のことを行います。

  1. .ovaアーカイブから.vmdkファイルを抽出します。
  2. .vmdkファイルをOCIオブジェクト・ストレージ・バケットにアップロードします。
  3. .vmdkファイルからOCIでカスタム・イメージを作成します。
  4. このカスタム・イメージを使用してCCKMインスタンスをデプロイします。

この方法では、イメージ・インポート・プロセスを完全に制御でき、エアギャップまたはカスタム・デプロイメント・シナリオで特に役立ちます。

OCIネットワーク・インフラストラクチャでは、最初のThales CCKMアプライアンスをアムステルダム(AMS)リージョンにデプロイする準備ができています。OCI Consoleにログインします。

.vmdkファイルをOCIオブジェクト・ストレージ・バケットにアップロードした後、次のステップに従ってカスタム・イメージとしてインポートします。

次の図は、これまでのデプロイメントの現在の状態を示しています。

イメージ

タスク3: 最初の販売CCKMアプライアンスでの初期構成の実行

最初のCCKMアプライアンスがデプロイされ、アクセス可能になったので、初期構成を実行します。これには、NTPサーバーを使用してシステム・クロックを設定し、評価ライセンスまたはThalesが提供する実際のライセンスをアクティブ化することが含まれます。

これらの手順により、アプライアンスは証明書の管理、ロギング、および同期に不可欠な正確な時間で動作し、評価または設定フェーズで完全に機能するようになります。

タスク4: 2番目の販売CCKMアプライアンスのデプロイおよび初期構成の実行

タスク2およびタスク3のステップに従って、2番目のCCKMをASHリージョンにデプロイします。

次の図は、これまでのデプロイメントの現在の状態を示しています。

イメージ

タスク5: Thales CCKMアプライアンスRPC間の接続の確認

2つのThales CCKMアプライアンス間の高可用性およびクラスタリングを準備するには、それらがデプロイされているリージョン間の適切な接続を確保することが不可欠です。

このセットアップでは、アムステルダム(AMS)アッシュバーン(ASH)のOCIリージョンの間にRPCが確立されています。このRPCにより、各CCKMアプライアンスが存在する2つのVCNs間のセキュアな低レイテンシの通信が可能になります。

構成内容:

ノート:

このクロスリージョン・ネットワーク設定により、クラスタ作成プロセス中にCCKMがシームレスに通信できるようになり、次の項のいずれかで対処します。

イメージ

タスク6: DNSの構成

2つのアプライアンス間のシームレスな通信を可能にするには、適切なDNS解決が必要です。これは、セキュアなクラスタリング、証明書処理、およびサービス全体の安定性のために特に重要です。

ノート:この時点から、Thales CCKMアプライアンスをThales CipherTrust Managerと呼びます(CyberTrust Managerの略)。

カスタムの内部DNSサーバーを使用しているときに、このデプロイメントではプライベートDNSゾーンでOCI DNSサービスを利用しています。これにより、意味のある完全修飾ドメイン名(FQDN)をThales CipherTrust Managerに割り当て、静的IPに依存することなくリージョン間で通信できるようになります。

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との結合が回避されます。

イメージ

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を使用していることを確認してください。

イメージ

次の図は、これまでのデプロイメントの現在の状態を示しています。

イメージ

タスク8: Thales CCKMアプライアンスとCAによる署名の両方のCSRの作成

CyberTrustマネージャ・アプライアンスがデプロイされ、DNSが構成された状態で、セキュアな証明書ベースの通信を有効にする時期です。AMS Thales CipherTrust ManagerおよびASHはCAとして構成されているため、AMS Thales CipherTrust Managerを使用して、両方のアプライアンスの証明書を生成および署名します。

これにより、すべてのThales CipherTrust Manager-to-Thales CipherTrust Manager通信が信頼され、暗号化されます。これは、クラスタ形成およびセキュアなAPIアクセスのための重要な要件です。

イメージ

ノート:これらのステップは、AMS Thales CipherTrust Managerでのみ実行します。

生成された証明書署名リクエスト(CSR)および秘密キーを追跡するには、ローカル・マシンまたはセキュア管理サーバーにクリーン・フォルダ構造を作成することをお薦めします。単純な構造の例を次に示します。

イメージ

個々のThales CipherTrust Manager証明書に署名するだけでなく、CAルート証明書はトラスト・チェーンの重要な部分です。このルート証明書は、CAとして機能するThales CipherTrust Managerによって発行されたすべての証明書の信頼の基盤を確立します。

イメージ

タスク9: Thales CCKMアプライアンス・クラスタリングの構成

Clustering Thales CipherTrust Cloud Key Manager (CCKM)アプライアンスは、暗号化鍵管理のための高可用性およびロード・バランシングを可能にします。これにより、セキュリティ・インフラストラクチャの継続的なサービスとフォルト・トレランスが保証されます。

クラスタリングは、単一(プライマリ)のThales CipherTrust Managerアプライアンス(この例では、AMSで実行されているThales CipherTrust Manager)の管理コンソールから完全に構成されます。このアプライアンスのインタフェースを使用して、クラスタを作成し、他のThales CipherTrust Managerアプライアンスをクラスタ・ノードとして追加します。

ThalesのCipherTrust Managerクラスタ構成が正しく行われ、正常であるかどうかを確認するには、CTM1およびCTM2をチェックします。

次の図は、これまでのデプロイメントの現在の状態を示しています。

イメージ

次のステップ

このチュートリアルでは、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の設定

確認

その他の学習リソース

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

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