はじめに
Cockpit の Apps カタログから Azure EKM プロキシエンドポイントをデプロイする
前提条件
前提条件
- 外部キーマネージャープロトコルをサポートする Azure Managed HSM(または Managed HSM の顧客管理鍵で構成された Azure サービス)
- Azure のクライアント証明書を発行するクライアント CA 証明書(PEM)— Azure Managed HSM の構成から取得します
- AES-256 鍵または RSA-2048/4096 鍵を含む、作成済みの DuoKey vault
- Apps を管理する権限を持つ DuoKey Cockpit の管理者アクセス
このステップでは、サーバー証明書と秘密鍵は任意です。mTLS のサーバー秘密鍵が DuoKey に送信・保存されることはありません。プロキシの前段で TLS を終端するイングレスに保持されたままとなります。
EKM エンドポイントをデプロイする
DuoKey ダッシュボードで Apps を開き、+ Create new app をクリックして Azure EKM を選択します。ウィザードは 5 つのステップで構成されています。
最後のステップまで Azure には何も公開されません。Test Connection と Deploy はどちらも、選択した vault 保持の鍵に対して実行されます。
EKM Proxy
次の項目を設定します。
- Proxy Name — このエンドポイントの名前(例:
Azure EKM Production) - Description — 任意の自由記述テキスト
- Endpoint Slug — 自動生成される GUID で、読み取り専用で表示されます。エンドポイント URL の一部になります:
/azureekm/{slug} - Proxy Vendor — プロキシ情報のレスポンスで Azure に返されるベンダー文字列。既定値は
DKE Cockpitです
mTLS Certificates
Azure Managed HSM は相互 TLS でプロキシに対して認証を行います。次の項目を設定します。
- Client CA Certificate (PEM) — Azure のクライアント証明書を発行した CA。mTLS が有効な場合は必須です。
- Server Certificate (PEM) — 任意。表示用、またはイングレスのプロビジョニング用です
- Server Private Key (PEM) — 任意。mTLS を終端するイングレスのプロビジョニングを補助するためだけに使用され、DuoKey が永続化することはありません
- Require mTLS client authentication — 既定で有効です。本番環境では有効のままにし、ローカルテストの場合にのみ無効にしてください
- Expected client CN — 任意の ID ピン留め(例:
<hsm-name>.managedhsmclient.azure.net)。設定すると、検証済みのクライアント証明書は Subject CN が一致する場合にのみ受け入れられます(大文字・小文字は区別されません)。空のままにすると、上記の CA にチェーンするすべての証明書を信頼します
mTLS が必須であるにもかかわらずクライアント CA 証明書が設定されていない場合、そのエンドポイントへのすべてのリクエストは拒否されます。
Vault & Key
鍵暗号化鍵(KEK)として使用する vault と鍵を選択します。鍵タイプによって、次のステップで利用できるラップアルゴリズムが決まります。AES-256 鍵は A256KW/A256KWP を、RSA 鍵は RSA-OAEP-256 をサポートします。
Algorithms
選択した鍵タイプと互換性のあるアルゴリズムの中から、このエンドポイントで許可するものを選びます。
| 鍵タイプ | 利用可能なアルゴリズム |
|---|---|
| AES-256 | A256KW(RFC 3394)、A256KWP(RFC 5649) |
| RSA-2048 / RSA-4096 | RSA-OAEP-256 |
すべてのオプションをチェックしないままにすると、選択した鍵と互換性のあるすべてのアルゴリズムが許可されます。
Review & Deploy
プロキシ名、エンドポイントのスラッグ、mTLS の状態、クライアント CA のアップロード状況、ピン留めした CN(設定した場合)、vault、鍵、許可されたアルゴリズムといったサマリーを確認し、Test Connection でラップ/アンラップのセルフテストを実行するか、Deploy EKM Proxy をクリックします。
デプロイ後
デプロイすると、アプリの作成とエンドポイントの構成が 1 つのステップで完了します。別途有効化する操作はありません。レスポンスには、エンドポイントのベース URL と個々の操作のパスが含まれます。
ekm_url: /azureekm/<slug>
info_endpoint: /azureekm/<slug>/info
wrap_endpoint: /azureekm/<slug>/{key_name}/wrapkey
unwrap_endpoint: /azureekm/<slug>/{key_name}/unwrapkey
metadata_endpoint:/azureekm/<slug>/{key_name}/metadata
health_endpoint: /azureekm/<slug>/healthエンドポイントを Azure に登録する
Azure がラップ/アンラップのリクエストの送信先を把握できるように、Azure Managed HSM / Azure SQL Managed HSM の構成に、プロキシのベース URL と API バージョン(0.1-preview)を設定します。
セルフテストを実行する
アプリの Test アクションで、ラップ/アンラップの往復テストを実行します。AES-256 の KEK では実際の vault の鍵をエンドツーエンドで検証します。RSA の KEK の場合(または鍵を選択する前)は、代わりに合成的な鍵を使ってラップ/アンラップの処理経路を検証します。本番投入前に RSA ベースのエンドポイントの実際の鍵を検証するには、代わりにエンドポイントのヘルスチェックを使用してください(次のステップ)。
エンドポイントのヘルスを確認する
アプリのヘルスチェックは、エンドポイントがデプロイされて有効になっていること、鍵が存在し動作可能であること、セルフテストが成功すること、mTLS が正しく構成されていることを確認します。本番投入前の検証や継続的な監視に役立ちます。
エンドポイントのスラッグと、アップロードした mTLS のトラストアンカーは資格情報として機能します。これらが漏洩した疑いがある場合は、新しいクライアント CA でエンドポイントを再デプロイするか、アプリの詳細ページから無効にしてください。