Categories
KMS は本番データから分離して運用する必要があります
企業がキー管理相互運用プロトコル（KMIP）の導入を始める際、KMS は本番データを保存するデバイスとは分離して運用すべきです。汎用的なストレージデバイスが両方の役割を担うのは避けてください。これは職務分離（SoD）の基本原則です。KMS と本番データの管理者は、明確に分けられた役割である必要があります。
キー管理システム（KMS）は環境全体の信頼の根幹となるため、最小限の構成と最大限の堅牢化が求められます。一方、NAS は大容量かつ多機能なストレージシステムとして設計されており、KMIP クライアントとして機能します。両者は本質的に性質が異なります。
QNAP の設計理念：QNAP が QNAP NAS を KMS としてサポートしないのは、意図的なアーキテクチャ設計です。職務分掌の原則を守るため、鍵管理の権限は専用かつ監査可能な KMS に委ね、NAS は必要なときに暗号鍵を要求する役割のみに限定しています。これにより、組織の暗号化アーキテクチャが常にコンプライアンスを満たし、効果的に機能することを保証します。
NAS を KMS として利用すること：見落とされがちなコンプライアンス上の落とし穴
実際には、セキュリティ監査要件を満たすため、共有フォルダーやボリュームの暗号鍵を一元管理する KMS が必要になるケースが多く見られます。しかし、市販の KMS ソリューションは高額なため、コスト削減の目的でストレージデバイスを利用することがあります。
しかし、これは危険な見せかけの節約です。KMS のコストを削減できたと思っても、最も重要な役割を誤ったアーキテクチャに任せてしまっています。節約した費用が本当のセキュリティ向上につながるとは限らず、KMS の本来の設計理念からも逸脱しています。
市場にはストレージに KMS 機能を内蔵したソリューションもありますが、監査の観点から見ると、データと鍵が同一システム上に存在する設計では責任分担が明確になりません。データと鍵の両方を管理できる単一の管理インターフェースは、それ自体が単一障害点となり、暗号技術がどれほど強力でも監査人が受け入れることはまずありません。
信頼の根幹：KMS が一般的なシステムよりはるかに高いセキュリティ要件を持つ理由
この理解の鍵となるのが「シングル・ルート・オブ・トラスト（単一の信頼の根幹）」という概念です。
組織が KMIP の導入を検討する段階に至った場合、それは暗号鍵を NAS システムだけでなく、環境全体で一元的に管理する必要があることを意味します。一般的なオンプレミスのエンタープライズ活用例としては、次のようなケースが挙げられます：
- 仮想化プラットフォーム：VMware vSphere/vSAN の仮想マシンおよびデータストア暗号化、Hyper-V、Nutanix
- データベース透過的データ暗号化（TDE）：Oracle、SQL Server
- バックアップシステム：Veeam や Commvault などエンタープライズ向けバックアップソフトウェアの暗号化キー
- 共有ストレージサーバー（NAS）
- 自己暗号化ストレージアレイ
- 自己暗号化ハードウェア：自己暗号化ドライブ（SED）、テープライブラリ、自己暗号化ストレージアレイ
KMS が上記すべてのデバイスに対する単一の信頼のルートとなる場合、そのセキュリティ要件は管理対象デバイスよりもはるかに高くなります。具体的には、エンタープライズ向け KMS ソリューションには、HSM（ハードウェアセキュリティモジュール）対応のキーストア、厳格な職務分掌、完全かつ監査可能なキーライフサイクル、独立した暗号モジュール検証が求められます。
したがって、KMS は管理対象システムよりも高いセキュリティレベルで役割を果たします。
鍵そのものは非常に小さく、鍵・メタデータ・ポリシーを合わせても多くの企業で数メガバイト程度です。理想的な KMS は最小化の原則に従い、鍵管理に無関係な機能を排除し、単一の責任だけを持ち、信頼境界を最小限に抑え、独立した監査を容易にします。
一方で、NAS の価値は、大容量、ファイルサービス、豊富なアプリケーションエコシステム、多様な通信プロトコル対応など、多機能性に基づいています。これらはデータプラットフォームとしての NAS の強みですが、KMS に求められる「ミニマルかつ単一用途」という設計方針とは異なります。
QNAP QuTS hero：「KMIP クライアント」役割の正しい実践
QNAP のアーキテクチャでは、NAS は高度な KMIP クライアントとして、鍵の管理は専用 KMS に任せ、自身は本来のストレージ機能に集中します。QuTS hero の KMIP クライアントは、以下の設計特長を備えています。
- リモート鍵管理：暗号鍵はリモートの KMIP サーバーに保存されるため、NAS 側での不正アクセスや鍵の喪失リスクを最小限に抑えます。
- FIPS 140-3 準拠キー交換：キー交換プロセスは、FIPS 140-3 のセキュリティ要件およびエンタープライズ向けコンプライアンス基準に基づいて設計されています。
- 相互 TLS 暗号化チャネル：NAS と KMIP サーバーは、相互 TLS（mTLS）経由で通信します。デフォルトでポート 5696 を使用し、両者とも有効期限内の正規証明書がインストールされている必要があります。
- 自動キー適用と起動時アンロック：暗号化された共有フォルダーや暗号化 LUN（論理ユニット番号）は、キーを自動取得できます。クライアントとサーバーの接続が維持されていれば、システム再起動後もアクセスが可能です。
- 証明書ライフサイクルの一元管理：証明書の生成、インポート、置換、ダウンロード、削除に対応し、ユーザーはステータスや有効期限も確認できます。
対応バージョンについて、KMIP クライアントはQuTS hero h6.0以降で利用可能です。インストールと設定は、App Center から「KMIP Client」をインストールし、コントロールパネル > システム > セキュリティ > KMIP設定に進んでください。
この責任分担の最大の利点は、CMVP 暗号モジュール認証に関する最高レベルのセキュリティ責任を、各ストレージデバイスが個別に担うのではなく、専門の KMS が担う点にあります。NAS はキー交換に関して FIPS 140-3 の設計要件を満たし、信頼のルートは適切な認証機関に委ねるだけで済みます。
KMIP 対応 KMS の選び方
「NAS クライアントモデル」が確立したら、次は適切なキー管理機関を選定します。推奨される方法は、監査要件や予算に応じて 2 つの選択肢から選ぶことです：
| ユースケース | 推奨方法 | 代表的なソリューション |
| 厳格な監査要件 | 既存の認定済み商用 KMS ソリューションを利用 | Thales CipherTrust Manager、Entrust KeyControl、IBM Guardium Key Lifecycle Manager、HashiCorp Vault Enterprise（KMIP シークレットエンジン） |
| 予算が最優先事項 | 専用の管理・監査可能なホスト上にコンテナを用いて自社運用の KMIP サーバーを導入 | HashiCorp Vault / OpenBao（KMIP エンジン）、Cosmian KMS、PyKMIP はテスト用途のみ |
重要なのは、KMS をどのホストで動かすかではなく、ホストが堅牢化されているか、アクセス制御が徹底されているか、監査証跡がレビュー可能な形で生成されるかです。鍵管理権限が本番ストレージから独立し、上記のガバナンス要件を満たしていれば、商用・自社運用どちらのソリューションでも暗号化基盤として十分な堅牢性を提供できます。
KMIP と FIPS の理解：完全ガイド
暗号化監査の検証時、3 つの用語が混同されがちですが、監査人はそれぞれ全く異なる観点で確認します：
| 概念 | 検証対象 | 説明 |
| 相互運用性 | KMS が KMIP を用いて接続し、正常に動作できるか | “ プロトコル接続が正常に動作する ” |
| アルゴリズム検証（NIST CAVP） | AES/SHA/RSA などのアルゴリズムがベンダー実装で正しく動作するか | “ 数学的演算が正しい ” |
| 暗号モジュール認証（NIST CMVP、FIPS 140-2/140-3） | キー管理や暗号モジュールの境界を含む、暗号モジュール全体が認証を取得し、有効な証明書を取得しているかどうか | 金庫全体がセキュリティ要件に対して認証されています |
監査人にとって最も重要かつ厳格な要件は、暗号モジュールの認証です。アルゴリズム実装がCAVPに合格したり、モジュールがテスト中であったりしても、信頼しているキー管理コンポーネントをカバーする有効な CMVP証明書があるとは限りません。そのため、どの KMS ソリューションを選択する場合でも、NIST CMVP 認証リストで認証状況を直接確認し、証明書の範囲を監査人と確認することを推奨します。
KMIP 自体は、異なるベンダーの KMIP クライアントとサーバー間の相互通信を可能にするオープン標準プロトコルです。しかし、「相互運用性がある」ことは出発点に過ぎません。実際にソリューションがコンプライアンス認証を通過できるかどうかこそが、企業が乗り越えるべき本当の課題です。
結論：鍵と錠は分離して管理する
KMIP を導入する目的は、NAS を KMS 化することではなく、環境全体のために独立した信頼性の高い監査可能なキー管理機関を確立することです。
KMIP クライアントとして、QNAP NAS はキー管理を専門の KMS に委ねて一元管理を実現し、ストレージやデータサービスに専念します。これは機能が不足しているのではなく、信頼の根本を本来あるべき場所に置くという意図的な判断です。鍵と錠を分離することで、セキュリティの有効性と監査の成功が実現します。
QuTS hero の KMIP クライアント構成手順についてもっと見るには、QNAP 公式のチュートリアルをご参照ください。
https://www.qnap.com/go/how-to/tutorial/article/how-to-use-kmip-client-for-secure-key-management
よくある質問（FAQ）
Q: QNAP NAS は KMIP サーバーとして利用できますか？
A: QNAP NAS は、KMIP クライアント機能のみをサポートするよう設計されています。サーバー機能は対応していません。KMS は信頼の根拠となるシステムであり、単一責任・最小限の信頼境界という原則に従って運用されます。一方、NAS は大容量かつ多目的なデータプラットフォームです。両者は設計目的が異なります。KMS 専用として別の NAS を購入しても、多目的プラットフォームを単一用途に使うことになり、ほとんどの容量が未使用となります。正しい方法は、NAS をクライアントとして利用し、鍵は専用かつ監査可能な独立した KMS で管理・保護することです。
Q: QNAP ソフトウェアのどのバージョンから KMIP クライアントをサポートしていますか？
A: KMIP クライアントは QuTS hero h6.0 から対応しています。App Center から KMIP クライアントをインストールし、コントロールパネルのセキュリティ設定で有効化してください。
Q: 予算が限られている場合、高価な商用 KMSを購入する必要がありますか？
A: 必ずしも必要ではありません。企業は、HashiCorp Vault（Enterprise）や OpenBao など、KMIP エンジンを備えたオープンソース／コミュニティ対応のソリューションを、独立した強化済みの仮想マシンやコンテナ環境に導入できます。重要なのは、この環境を NAS から物理的に分離し、アクセス制御も分けることです。また、完全なアクセス監査記録を生成できるようにしてください。
