DKE トラブルシューティング
この章では、Microsoft 365 向けの Double Key Encryption (DKE) に焦点を当てます。 Office クライアントから Microsoft Purview の機密ラベルを経由し、オンプレミスの DuoKey DKE 鍵エンドポイント (KMS API コンテナ) に至る経路を扱います。
ここで示す診断アプローチは、Microsoft 公式の DKE トラブルシューティングガイダンス に沿ったものであり、DKE サービスが OpenShift Ingress Router の背後で KMS API Pod として 動作する、コンテナ化されたオンプレミス DuoKey 展開向けに調整されています。
DKE の全体像
2 つの鍵がコンテンツを保護します。Microsoft が管理する鍵と、オンプレミスの エンドポイントから決して外に出ないお客様の DKE 鍵です。このフローのいずれかの側が 壊れると、ユーザーは DKE で保護されたコンテンツを適用したり開いたりできなくなります。
ステップ 1 — DKE 鍵エンドポイントは到達可能か?
最速の最初のテストです。クライアントネットワークからブラウザで鍵 URL を開きます:
https://<dke-endpoint>/<keyname>
- 期待される結果: 公開鍵 (
kid、key、鍵メタデータ) を含む JSON 応答。 - 何も返らない / タイムアウト / 接続拒否: ネットワーク、DNS、Ingress、 または Pod の問題。
クラスター側のチェック:
oc get route -n duokey # is the DKE/KMS route present?
oc get pods -n duokey -l app=duokey-kms-api # is the KMS API pod Running/Ready?
oc logs -n duokey -l app=duokey-kms-api --tail=200
curl -I https://<dke-endpoint>/<keyname> # status + TLS
| 症状 | 想定される原因 | 解決策 |
|---|---|---|
| 接続拒否 / タイムアウト | ファイアウォール / DNS / ルートなし | エンドポイントへの 443 を許可、パブリック DNS が LB に解決されることを確認、OpenShift ルートを確認 |
| 502 / 503 | 正常な KMS API Pod がない | まず KMS API Pod を修正 (oc describe、oc logs) |
/<keyname> で 404 | 鍵名が誤っている | 鍵名が展開済みの鍵構成と一致することを確認 |
ステップ 2 — TLS / 証明書の信頼
DKE クライアントは、エンドポイントに有効で信頼された TLS 証明書を要求します。
| 症状 | 原因 | 解決策 |
|---|---|---|
ブラウザ/Office で certificate not trusted | エンドポイントが信頼されていない / プライベート CA を使用 | クライアントが信頼する証明書を使用するか、内部 CA をクライアントに配布 |
| ハンドシェイク失敗 / リセット | TLS バージョン / 暗号スイートの不一致 | Ingress の tlsSecurityProfile をクライアント要件に合わせる (ネットワークセキュリティ) |
| 名前の不一致 | 証明書の CN/SAN ≠ エンドポイントのホスト名 | 正しい SAN で証明書を再発行 |
ステップ 3 — 認証 (Entra ID)
DKE は Entra ID (Azure AD) トークンを使用して鍵リクエストを認可します。ほとんどの 「鍵を取得できない」エラーは発行者/オーディエンスの不一致です。
KMS API / DKE 構成 (Microsoft の appsettings.json に相当する ConfigMap/Secret として
提供) を確認します:
| 設定 | 一致する必要があるもの |
|---|---|
| 有効な発行者 | Entra ID テナントの発行者 (https://sts.windows.net/<tenantId>/ または v2 login.microsoftonline.com/<tenantId>/v2.0) |
| オーディエンス / JWT オーディエンス | Entra ID に登録された DKE アプリケーションの App ID URI / クライアント ID |
| 認可されたユーザー | 鍵のリクエストを許可されたメール/UPN またはグループ |
| テナント ID | Entra ID テナント |
# Inspect the running DKE config (redact secrets)
oc get configmap duokey-kms-config -n duokey -o yaml
| 症状 | 原因 | 解決策 |
|---|---|---|
| 401 Unauthorized | 発行者/オーディエンスの不一致、またはトークンなし/期限切れ | ValidIssuers/Audience を修正、Entra アプリ登録を確認 |
| 403 Forbidden | ユーザーが認可リストにない | 認可されたユーザーにユーザー/グループを追加 |
| 管理者では動作、ユーザーでは動作しない | 認可のスコープ設定 | 認可されたユーザー / グループマッピングを確認 |
Entra ID の DKE アプリ登録が存在し、期待されるオーディエンス/App ID URI を公開しており、 管理者の同意が付与されていることを確認してください。発行者/オーディエンスの不一致は、 DKE で最も一般的な単一の障害です。
ステップ 4 — 機密ラベル構成 (Purview)
DKE 機密ラベルはお客様のエンドポイントを指し、公開されている必要があります。
- Microsoft Purview で、DKE ラベルの暗号化設定に正確な DKE エンドポイント URL
(
https://<dke-endpoint>) が含まれている必要があります。 - ラベルポリシーが対象ユーザーに公開されている必要があります。
- ラベル/ポリシーがクライアントに伝播するまで時間を見込んでください。
| 症状 | 原因 | 解決策 |
|---|---|---|
| Office にラベルが表示されない | ポリシーが未公開 / 未伝播 | ポリシーを公開、同期を待つ、サインアウト/インする |
| ラベルは適用されるが他所でコンテンツが読めない | そのユーザーにとってエンドポイントに到達できない | 影響を受けたネットワークからステップ 1〜3 を再確認 |
| 誤ったエンドポイント | ラベル内の URL タイプミス | ラベルの DKE エンドポイント URL を修正 |
ステップ 5 — Office クライアント
| 症状 | 原因 | 解決策 |
|---|---|---|
| 適用/オープン時に「問題が発生しました」 | エンドポイント到達不可または認証失敗 | クライアントのネットワークからステップ 1 と 3 を実行 |
| 古いクライアントが DKE を使えない | ビルドが DKE をサポートしていない | DKE 対応の Microsoft 365 Apps ビルドに更新 |
| 構成変更後に断続的に失敗 | 古いトークン / キャッシュ | サインアウトして再度サインイン、Office 資格情報キャッシュをクリア |
| オンラインでは動作、オフラインで失敗 | DKE はオープン時にエンドポイントアクセスを要求 | 保護されたコンテンツを開く際は常にエンドポイントに到達可能である必要がある |
エンドツーエンドのチェックリスト
- 鍵エンドポイントがブラウザで JSON 公開鍵を返す:
https://<dke-endpoint>/<keyname> - KMS API Pod が
Running/Ready、ルートが存在する - TLS 証明書が有効でクライアントに信頼されている
- Entra ID の発行者 + オーディエンスが DKE 構成と一致する
- ユーザーが認可されたユーザー/グループに含まれている
- DKE ラベルが正しいエンドポイントを指し、公開されている
- Office クライアントが DKE 対応ビルドであり、エンドポイントに到達できる
DuoKey へのエスカレーション
以下を収集し、[email protected] に送付してください:
oc logs -n duokey -l app=duokey-kms-api --tail=500
oc get route,pods -n duokey
oc get configmap duokey-kms-config -n duokey -o yaml # redact secrets
含めるもの: 正確なエラー、ブラウザでの鍵エンドポイントテストが成功するかどうか、 影響を受けたユーザー、および最近のラベルまたは Entra ID の変更。