JP2010524410A - 暗号鍵を識別および管理するための方法およびシステム - Google Patents

Abstract

暗号鍵を管理するためのシステムおよび方法であって、鍵のうちの１つ以上が無効化された状態を組み込み、該システムは名前空間をさらに組み込む、方法。

Description

本明細書は、３５ Ｕ．Ｓ．Ｃ． § １１９（ｅ）に基づき、２００７年４月２４日に出願された米国仮出願第６０／９２６，２０３号、および２００７年４月１２日に出願された第６０／９２３，４９７号の優先権の利益を主張し、これらは両者とも、参照することによってその全体を本明細書に組み込む。

本願明細書に記載の技術は、概して暗号鍵を管理するためのシステムおよび方法に関し、より具体的には、かかる鍵のための有用な状態とスキームの指標付けに関する。

ここ数年、コンピュータシステムに対する悪意のある攻撃やコンピュータによる個人情報の盗用が急増している。そして、新聞の見出しに掲載されるそれぞれのデータ漏洩や露出は、企業に次は我が身ではないか、そしてこうした事件がそもそも発生しないようにするにはどうしたらよいかと考えさせる。

これらの攻撃からの防御を提供するため、ファイヤウォールと仮想私設ネットワーク（ＶＰＮ）を使用してペリメータセキュリティ戦略を実施することで、ほとんどの企業は自社のシステムおよびネットワークの部外者からの安全を確保し、適切な認証を持たない外部ユーザが極秘データアクセスできないようにした。しかし、ＣＳＩ／ＦＢＩによる２００５年のコンピュータとセキュリティに関する調査（Ｃｏｍｐｕｔｅｒ Ｃｒｉｍｅ ａｎｄ Ｓｅｃｕｒｉｔｙ Ｓｕｒｖｅｙ）によると、内部の脅威は外部の脅威と同程度に蔓延している。４５３人の回答者のうち、５６％が過去１２ヶ月以内に内部ソースからの少なくとも１つの事故を経験している（米国司法省、ｈｔｔｐ：／／ｗｗｗ．ｕｓｄｏｊ．ｇｏｖ／ｃｒｉｍｉｎａｌ／ｃｙｂｅｒｃｒｉｍｅ／ＦＢＩ２００５．ｐｄｆ）。ほとんどの企業が依存するペリメータセキュリティによるソリューションは、内部の脅威を抑えるためには効果がない。

こうした格差、またデータ保持およびプライバシーに関する政府および業界主導の規制の拡大の需要を認識し、いくつかの企業はデータのセキュリティのため、伝統的なペリメータセキュリティの方法を越えたものを見据えている（業界主導の構想の一例は、金融業界におけるＰａｙｍｅｎｔ Ｃａｒｄ Ｉｎｄｕｓｔｒｙ Ｄａｔａ Ｓｅｃｕｒｉｔｙ Ｓｔａｎｄａｒｄ（ＰＣＩ ＤＳＳ）である）。これらの企業はむしろ、自社内のストレージ媒体に常駐のデータ（保存データ）およびネットワークおよびストレージデバイス上の自社システムの間を移動するデータ（通信中のデータまたは送信中のデータ）のセキュリティに注目している。これは、ストレージセキュリティとしても知られている。適切なストレージセキュリティを使用すれば、企業はデータの完全性を確保することができ、また、改ざんまたは盗まれたデータが長期の企業イメージおよび財務状態に与える可能性のあるダメージを軽減することができる。典型的には、ストレージセキュリティは認証、アクセス制御、および暗号化の３つの構成要素を含む。暗号化とは、無許可の人物が読むことを防止するためにデータにスクランブルをかけるプロセスであり、暗号化アルゴリズムと鍵の２つの主要構成要素を有する。

任意の暗号化アルゴリズムに、特定のセキュリティ要件に基づいて鍵が生成または割り当てられる。暗号化操作のためのセキュリティが維持されることを確実にするために、データを暗号化および解読するために使用される鍵の完全な制御とセキュリティを可能にするプロセスが設置されなければならない。

今日、インターネットによる商取引、ＶＰＮ、および通信中のデータシステムにおいて、データ暗号化は一般的となった。新しい規制の到来および最近の報道機関による注目とともに、保存データ（ｄａｔａ ａｔ ｒｅｓｔ）に関して、いま、アプリケーション、ファイル、および媒体レベルにおける暗号化要件が急増している。

今日使用されている多くの暗号化アルゴリズムは、政府機関または標準化団体によって作成された。ごく最近、米国標準技術局（Ｎａｔｉｏｎａｌ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｓｔａｎｄａｒｄｓ ａｎｄ Ｔｅｃｈｎｏｌｏｇｙ（ＮＩＳＴ））は、公開提案依頼書に基づいてＡｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（ＡＥＳ）を選択した。他の暗号アルゴリズムおよび標準試験基準は、Ｆｅｄｅｒａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ Ｓｔａｎｄａｒｄｓ（ＦＩＰＳ）に基づいてＮＩＳＴによって確立された。ＦＩＰＳとは、米国政府機関のための、データの安全確保に関する一連の要件および推奨される実践法である（ｈｔｔｐ：／／ｃｓｒｃ．ｎｉｓｔ．ｇｏｖ）。

米国外の政府は、特定の試験基準を持つことがあり、暗号化システムが配備されることになる国の試験基準を満たすことが認定されたデバイスを使用することは、優れた実践である。

本明細書において、本開示は１つ以上の方法に言及する。これらの方法は、１つ以上のコンピュータベースのシステム（例えば、１つ以上のプロセッサを備える）によって実行され、これらの方法を実行する命令は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、フラッシュドライブ、ＣＤ−ＲＯＭ等の物理媒体のうちの１つ以上に記録されるということを理解されたい。

暗号鍵が鍵管理システム内の１つ以上の鍵管理サーバに存在する、暗号鍵の使用を制御するための方法であって、その暗号鍵を無効にするステップを含み、無効にするステップは、すべての暗号ユニットから暗号鍵を削除するステップと、鍵管理システム内の鍵管理サーバの内部で、暗号鍵を隔離するステップとを含み、暗号鍵を隔離するステップは、無効な暗号鍵へのすべてのアクセスを封鎖するステップを含む方法。
新しい状態を示すために、無効な暗号鍵のメタデータを更新するステップをさらに含む該方法。

暗号鍵が使用可能な状態に復帰されてもよいかどうか判断するステップと、暗号鍵が有効化されてもよい場合、暗号ユニットが暗号鍵を使用できるように、鍵を使用可能な状態に戻すことにより有効化するステップとをさらに含む該方法であって、判断するステップは、適切な信用証明を持つユーザを持つユーザによって実施される。
適切な信用証明を持つユーザは、鍵管理者またはマネージャを含む該方法。
使用可能な状態は、無効状態より高い任意の状態を含む該方法。

適切な信用証明を持つユーザは、暗号鍵と関連のあるセキュリティポリシーに関連して、無効な鍵が有効化されてもよいかどうかを判断する権限がある該方法。

暗号鍵が有効化されると、その新しい状態を示すために、暗号鍵のメタデータを更新するステップをさらに含む該方法。

無効鍵を２つ以上のコンポーネントシェアに分割するステップと、各コンポーネントシェアを格納するステップをさらに含み、各コンポーネントシェアへの権利が１名の管理者またはマネージャに与えられ、いかなる管理者またはマネージャも２つ以上のコンポーネントシェアへの権利を有しない該方法。

暗号鍵が使用可能な状態に復帰されてもよいかどうかを判断するステップと、２つ以上のコンポーネントシェアを戻すステップを含む、暗号鍵を使用可能な状態に戻すステップとをさらに含む該方法であって、判断するステップは、適切な信用証明を持つユーザによって実施される。

本開示は、暗号鍵の状態を設定する方法をさらに含み、暗号鍵は、管理システム内の１つ以上の鍵管理サーバに存在し、暗号鍵の状態を、暗号鍵が無効化されたことを示す状態に設定するステップを含む。

暗号鍵が有効化されてもよいかどうかを判断するステップと、暗号鍵が有効化されてもよい場合、鍵の状態を使用可能な状態に設定するステップをさらに含む該方法であって、判断するステップは、適切な信用証明を持つユーザによって実施される。
適切な信用証明を持つユーザは、鍵管理者またはマネージャを含む該方法。
使用可能な状態は、無効状態より高い任意の状態を含む方法該方法。

適切な信用証明を持つユーザは、暗号鍵と関連のあるセキュリティポリシーに関連して、無効な鍵が有効化されてもよいかどうかを判断する権限がある該方法。

その新しい状態を表示するために、無効な暗号鍵のメタデータを更新するステップをさらに含む該方法。

本開示は、鍵管理システム内でオブジェクトを識別する方法をさらに含み、オブジェクトのためのＧＵＩＤを作成するステップであって、ＧＵＩＤはＵＲＩによって表され、ＵＲＩはプレフィックス、領域要素、オブジェクト要素、およびパス要素を含む、ステップと、ＵＲＩを鍵管理システムの中の１つ以上の鍵管理サーバにマッピングするステップと、オブジェクトを鍵管理システムの中の１つ以上の鍵管理サーバに格納するステップとを含む。
プレフィックスは「ｋｍ」または「ｋｍｓ」である該方法。
領域要素は、Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｉｃｅドメイン名を含む該方法。
領域要素は、鍵管理システム内の権限のゾーンの名称を含む該方法。
オブジェクト要素は、鍵管理システムの制御下の任意の鍵を含むオブジェクトスペースを含む該方法。
オブジェクト空間は「鍵」と名づけられる該方法。
オブジェクト要素は、任意の鍵管理ポリシーを含む方法。
オブジェクト空間は「ポリシー」と名づけられる該方法。
オブジェクト要素は、任意の鍵管理クライアントを含む該方法。
オブジェクト空間は「クライアント」と名づけられる該方法。
オブジェクト要素は、任意の鍵管理グループを含む該方法。
オブジェクト空間は「グループ」と名づけられる該方法。
オブジェクト要素は、任意の鍵管理プールを含む該方法。
オブジェクト空間は「プール」と名づけられる該方法。
オブジェクト要素は、任意の鍵管理セットを含む該方法。
オブジェクト空間は「セット」と名づけられる該方法。
オブジェクト要素は、任意の鍵管理ログを含む該方法。
オブジェクト空間は「ログ」と名づけられる該方法。
オブジェクト要素は、任意の鍵管理セッションを含む該方法。
オブジェクトスペースは「セッション」と名づけられる、請求項３３に記載の方法。
オブジェクト要素は、ＤＮＳドメインのために確保されたオブジェクトスペースを含む方法。
オブジェクト空間は「．ドメイン」と名づけられる該方法。
パス要素は、マルチエレメントパスを含む該方法。
マルチエレメントパスは、オブジェクトのための共通の既定のアクセス制御を画定する該方法。
マッピングは、ＫＭＳＳを使用するステップを含む該方法。
マッピングは、ＫＭＣＳを使用するステップを含む該方法。
オブジェクトを、鍵管理システムの中の１つ以上の暗号ユニットに格納するステップをさらに含む該方法。
オブジェクトを、鍵管理システムの中の１つ以上のＫＭクライアントに格納するステップをさらに含む該方法。
オブジェクトを、鍵管理システムの中の１つ以上のＫＭクライアントに配布するステップをさらに含む該方法。

鍵管理システム内のオブジェクトを取り出す方法であって、オブジェクトのためのＵＲＩを受け取るステップと、ＵＲＩを鍵管理システムの中の１つ以上の鍵管理サーバにマッピングするステップと、鍵管理システムの中の１つ以上の鍵管理サーバのうちの１つからオブジェクトを取り出すステップとを含む該方法。
マッピングは、ＫＭＳＳを使用するステップを含む該方法。
マッピングは、ＫＭＣＳを使用するステップを含む該方法。

本技術の１つ以上の実施形態の詳細は、付随の図面および以下の説明に定義される。本技術の他の特長、目的、および利点は、説明および図面、ならびに請求項から明らかとなろう。

暗号鍵の階層を表す。 保存データのための暗号鍵の、作成から削除までのライフサイクルを示す。 例示的鍵管理システムアーキテクチャの概略図である。 集中型鍵管理システムの動作を説明する図である。 分散型鍵管理システムの動作を説明する図である。 ハイブリッド鍵管理システムの動作を説明する図である。 ディスクアレイ特定鍵を持つディスクアレイの実施形態を示す。 １つ以上の鍵を１つ以上のディスクデバイスに関連付ける、異なる可能な方途を示す。 鍵状態およびこれらの鍵状態の間の一部の移行を示す図である。 ホストが鍵管理クライアント（ＫＭクライアント）である、例示的アーキテクチャの概略図であり、すべてのストレージは、内部であるか、直接ホストに取り付けられる。 ホストに属するいくつかの二次ストレージデバイスの任意のものが、ＫＭクライアントであり得る、例示的アーキテクチャの概略図である。 いくつかの一次ストレージデバイスの任意のものが（ホストからディスクへの接続性にＳＡＮおよびＮＡＳソリューションの両者を使用）ＫＭクライアントであり得る、例示的アーキテクチャの概略図である。 ６段階の暗号鍵のライフサイクルを示す。

はじめに
サービスベースのシステムは、集中制御ベースのシステムよりも優れたいくつかの利点を有する。これは、ある組織の要件を最も満たすベンダーからの製品を追加することにより、サービスを増加的に発展させるのが容易である。集中制御のモデルは、組織を自らが選択した第１の生産ラインに縛り付ける傾向がある。その第１の製品が、選択時の組織の要件に完全に合致するとしても、その後は最適に合致するとは限らない。暗号鍵を管理するための本明細書に記載の方法および装置は、特にサービスベースのシステム内部のインストールや動作に特に適しているが、集中ベースのシステムにも適用され得る。

組織の要件は経時的に変化する。サービスベースのシステムでは、新しい一連の要件を持つ組織は、その既存の基礎構造を危険にさらすことなく、その新しい要件をもっとも満たす任意の製品ラインを追加することができる。組織は、大規模なアップグレードやソフトウェアおよび設備の全面的な交換を必要とせずに、サービスベースのシステムに追加することができる。

可能な場合、鍵管理サービスは、例えば、通信および認証標準規格等の既存の標準規格を最大限に活用することが前提であるが、しかしながら、本技術は、本明細書に記載の標準規格を使用することに限定されず、本技術は、本明細書の出願時に既存の標準規格を使用することに限定されない。

鍵管理サービス（ＫＭＳ）モデルの例示的実施形態は、保存データ使用の事例によるところが大きい。本願明細書に記載の実施形態は保存データに重点を置くが、本技術は、保存データに限定されない。さらに、本明細書に記載のＫＭＳアーキテクチャは、記載の保存データ使用の事例のみに限定されない。本明細書に示されるシステムは、データの種類を問わず、保存データのための鍵管理要件を網羅するのに十分な柔軟性を有する。

定義の抜粋
「通信中のデータ」とは、１つの場所から別の場所に移動している任意のデータをいう。企業は、すべての種類の通信中のデータの安全を確保するために、暗号化を取り入れてきた。一例に、公共ネットワークを行き来する、ビジネス間の安全なトランザクションのためにＶＰＮを使用した財務データがある。

「保存データ」とは、媒体に置かれているデータである。媒体には、ディスク、テープ、光、または他の任意の電子ベースの媒体を含み得る。しかしながら、テープ媒体上のデータがテープライブラリから現場外のストレージ設備に伝送される場合、これは保存データではなく通信中のデータであると考慮されるべきである。それは、コンピュータネットワーク内部のデータよりもずっと低速で移動するが、目的地が物理的な倉庫である場合でも、依然として１つの場所から別の場所へと移動しているためである。

「認証」は、ユーザおよびシステムが、自称と一致することを確認する。ネットワーク上でユーザを認証するためのいくつかの標準規格およびプロトコルが、世界中の企業において広く実装されており、Ｌｏｃａｌ Ａｃｃｅｓｓ Ｄｉａｌ−ｉｎ Ｕｓｅｒ Ｓｅｃｕｒｉｔｙ（ＲＡＤＩＵＳ）およびＣｈａｌｌｅｎｇｅ Ｈａｎｄｓｈａｋｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＣＨＡＰ）を含む。Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ ＣＨＡＰ等の、組織がストレージ基礎構造に認証を追加することを可能にする、新しいストレージ固有の方法および標準規格が出現しつつある。言い換えると、これらはユーザまたはデバイスの認証が、情報が保存される前に行われることを可能にする。

「アクセス制御」は、データにアクセスするユーザまたはシステムの能力を限定する。ネットワーク上において、ユーザはルータアクセス制御一覧およびアクセスを制御するディレクトリサービスによって許可されたデータの閲覧のみが可能である。ストレージ基礎構造の内部において、どのサーバがどのデータへのアクセスを有するかは、ゾーニングおよび（論理装置番号：Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）ＬＵＮマッピングによって制御されている。

「暗号化」とは、無許可の人物が読むことを防止するためにデータにスクランブルをかけるプロセスであり、暗号化アルゴリズムと鍵の２つの主要構成要素を有する。暗号化アルゴリズムが種々の標準規格を使用して実現されるのに対し、ほとんどのシステムは、特定の命令に対し、保存データを暗号化するためにトリプルデータ暗号化標準規格（３ＤＥＳ：：Ｔｒｉｐｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）等の特定のアルゴリズムを、および通信中のデータを暗号化するために新暗号規格（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ：ＡＥＳ）を使用する。

「対称鍵」とは、２つ以上のシステムの間で共有される、データを暗号化および解読する秘密鍵である。暗号化および解読するために使用される対称秘密鍵は、いかなる状況においても公開されてはならない。対称鍵は、保存データのために推奨される手法である。現在のところ、保存データのために開発中の２つの対称鍵標準規格が存在する。ディスクのための第１の標準規格は、ＩＥＥＥ Ｐｌ ６１９によって作成されている。テープ媒体を中心とする第２の標準規格は、ＩＥＥＥ Ｐ１６１９．１によって構築されている。

「非対称暗号鍵」は、公開鍵と秘密鍵の対から成る。秘密鍵は、他者と共有されないという例外を除き、コンセプトの点で対称秘密鍵と類似している。一方、公開鍵は、広く配布され、共有される。公開鍵を公表することは、対応する秘密鍵を露出または改ざんしない。暗号化のために非対称暗号鍵を使用する際、公開鍵はデータを暗号化するために使用され、秘密鍵は、データを解読するために使用される。したがって、他の組織やビジネスパートナーと情報を共有する際、非対称暗号鍵を実装することが有用となり得る。

「鍵管理システム」とは、デバイスと、ユーザによる入力を伴い、又は伴わず鍵を作成、維持、コントロールするために有用な命令とを組み合わせるシステムである。システムは、効果的に実行するために実施される運用技術を含むことができる。鍵管理システムにおいて使用されるいくつかの共通構成要素には、鍵ジェネレータ、スマートカード、トークン、またはフロッピー（登録商標）ディスク、電子輸送、暗号化デバイス、鍵アーカイブシステム、鍵のバックアップファイルまたはデバイス、ロギングシステムまたはデバイス、およびアラートや監査等の運用技術が含まれる。
データフォーマット

本明細書の対象とするデータフォーマットには、ディスク、テープ、ファイル、データベース、およびオブジェクトを含む。ディスクの実施形態は、ブロックベースのディスクストレージ、および直接取り付けの、またはＳＡＮ（局所取り付けの）ストレージ（例えば、ディスク、ＣＤＲＯＭ、フラッシュディスク）を含むがこれに限定されない。テープの実施形態は、リニアテープオープン（ＬＴＯ）および仮想テープを含むがこれに限定されない。ファイルの実施形態は、オペレーティングシステムによって使用されるファイルシステムの中に存在するドキュメントまたは他のファイルを含むがこれに限定されない。データベースの実施形態は、列、行の表、レコードおよび／またはフィールド、リレーショナルデータベース、階層型データベース、ネットワークデータベース、オブジェクトデータベース、およびポストリレーショナルデータベースから成る任意のデータ表現を含むがこれに限定されない。アプリケーションデータの実施形態は、データストレージの位置に関わらず特定のアプリケーションによって使用されるために暗号化または解読された任意のデータを含むがこれに限定されない。オブジェクトの実施形態は、上記に列挙されたいかなる形態と、上記に記載のデータ副構成要素をも含む、いかなる保存データをも含むがこれに限定されない。

異なる使用事例を有する追加的なデータの種類は、今後定義される可能性があり、これはＫＭＳ標準規格を作成する際に考慮されなければならない。可能な場合、すべてのデータの種類は媒体やデータの種類に関わらず、暗号化されたオブジェクトとみなされることになる。

ストレージセキュリティおよび暗号化
本明細書に記載の技術の使用および実現と一致する、ストレージ環境における鍵管理システムの典型的な特性は、以下を含むことができる。

任意のストレージセキュリティの実行の出発点は、脅威を理解することである。ベストプラクティスは、企業がリスク評価を行うことを指示する。次いで、コストに加え、リスク評価と関連する改善措置の組み合わせを使用して、企業はその特定の需要のための最良のストレージセキュリティの手法を決定することができる。

典型的には、データが設備から離れる際には常に、暗号化されるべきである。このモデルの考慮することが必要な構成要素には、データネットワーク、ラップトップ、デスクトップ、サーバ、アプリケーション、テープ媒体、およびディスクアレイ媒体さえも含む。

その企業のサイトを離れる媒体を防御するには、媒体のワイピング、媒体の破棄、および暗号化を含むいくつかの選択肢が存在する。この３つの選択肢は、それぞれが関連するコストを有しており、データの機密性に基づいて１つの選択肢が他より優先され得る。暗号化については、すべてのコストは前払いか、システムの寿命の全期間にわたるかのどちらかである。媒体のワイピングおよび媒体の破棄のコストは、エンドオブライフのコストに追加される。
データ暗号化は、対称、非対称、および公開／秘密を含む、任意の適合する暗号化アルゴリズムによって実行することができ、保存データに加えて、通信中のデータに適用することができる。

保存データおよび通信中のデータのための追加的な検討事項は、暗号化されたデータが変造されたり不正に変更されたりしていないことを確実にする能力（暗号認証ともよばれる）である。メッセージダイジェスト、またはセキュアハッシュは、データの妥当性を検証するために使用されることができる固定長ビット列から成り、保存データおよび通信中のデータの両者のために強く推奨される。暗号解読に先立ってデータを認証することにより、ユーザはセキュアハッシュに基づいてデータが正しいと知る。

セキュアハッシュを演算するための種々の機構がある。最も一般的な機構はＭＤ５とＳＨＡ１であるが脆弱性知られており、ＳＨＡ２５６、ＳＨＡ３８４およびＳＨＡ５１２等のより強力なハッシュが推奨される。代替的に、より強力なハッシュを用いたＫｅｙｅｄ−Ｈａｓｈ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（ＨＭＡＣ）もまた良好なソリューションである。

デジタル署名は、１枚の紙への署名と類似する電子的な操作である。公証人に対応する署名照合は、インターネットベースの証明機関（ＣＡ）、組織ベースの機関、によって実施されてもよく、またはユーザが自己書名を提供することができる。鍵管理システムについては、いかなる鍵の交換にも先立って認証を確実にするために、ＣＡが使用推奨される手法である。

典型的には２種類の鍵がある。第１の種類は、データの解読および暗号化の両方のために使用される単一の鍵である、対称鍵である。第２の種類の鍵は、暗号化および暗号解読作業を提供するために２つの異なる鍵を使用する、非対称暗号鍵である。これらの鍵の種類のすべては、本明細書に記載の技術によって管理することができる。

どの種類の鍵を使用するかに関わらず、ベストプラクティスは、企業が安全保護のために鍵の階層を作成することを勧める。例示的実施形態において、鍵の階層は、データ暗号鍵と鍵暗号鍵（ＫＥＫ）から成る、少なくとも２つのレベルの鍵から成り、後者は鍵を暗号化された形式で保存するために使用される。セキュアハッシュまたはＨＭＡＣ署名から成り得る、キーメッセージ認証子（ＫＭＡＣ）を使用して鍵を認証することもまた、ベストプラクティスであるとされる。

鍵の階層を作成することにより、組織はまた、任意のまたはすべてのキーイング材料へのよりよいアクセスを提供することができる。階層が深いほど、操作のために必要とされる、鍵管理システムはより強固となる。図１は、例示的な鍵の階層を示す。

適正な鍵階層において、暗号化鍵が暗号的にも認証されることができるように、ＫＥＫはまた、同時に作成されるＫＭＡＣを有する。

図１において、最上階層の鍵は、その下のリージョナル鍵を暗号化し、および署名するためにのみ使用されるので強力に防御され、めったに使用されない。これは、すべてのリージョナル鍵が破壊されてしまったが、操作を再開するために回復しなければならない最悪の事態に役立つ。

一実施形態において、図１によると、組織鍵は、その下のリージョナル鍵を暗号化するために使用され、リージョナル鍵は、その下のポリシー鍵を暗号化するために使用される。組織鍵は、リージョナル鍵を暗号化し、署名する場合を除き、絶対に他者の知るところとなってはならない。組織鍵がバックアップ目的でエクスポートされる場合、知識分割システムを使用して行われなければならない。これは、すべてのリージョナル鍵が破壊されてしまったが、操作を再開するために下の鍵が回復されなければならない場合に重要である。

ストレージセキュリティは、鍵管理システムの使用によって恩恵を受ける。任意の鍵管理システムの運用上の態様は、おそらくシステム全体で最も見過ごされる態様である。プロセスは、今日の組織における鍵管理の要件を満たすように、反復可能、複製可能、およびセキュアであるべきである。使用される鍵管理システムから独立して、あらゆる鍵は「保存期間」を有し、これは監視、維持、および制御されるべきである。

鍵のライフサイクル管理
生成または入力された瞬間から削除されるまで、鍵のライフサイクルを管理することは、絶対に露出したり不適切使用されたりしないことを確実にするにために重要である。組織は、管理者または他の認証されたユーザによる不適切な使用ですらも禁止することにより、鍵のセキュリティを確実にするように気をつけるべきである。

図２は、保存データの暗号鍵の作成から削除までのライフサイクルを示す。図示される鍵のライフサイクルの中のそれぞれの段階は、鍵管理システムの関連する構成要素とともに、図２を参照として使用しながら以下に詳細に記載される。

鍵の生成：鍵は、手動生成または自動生成のどちらかを使用して作成されることができる。しかしながら、広く浸透している見識は、人間の介在が少ないほど、鍵はよりセキュアである。加えて、使用毎のベースで（例えば、各テープのために生成される一意鍵）で生成される一意の鍵は、その法人内のすべてのテープ上のデータを暗号化するために生成された単一鍵よりも強力なセキュリティを提供する。

鍵作成の一方法は、システムに入力する（例えば、キーボード、キーパッド、またはタッチスクリーンを介して）ことによって、鍵を手作業で生成することを伴い、これはデータを暗号化または解読するためにそれらの鍵を使用する。しかしながら、システムがすべての他の接続から隔離されており、および鍵をタイプするために使用される鍵ボードが、メモリまたはネットワーク接続性を持たないものでない限り、鍵をシステム内にタイピングすることは、推奨される鍵生成の方法ではない。これは、鍵ロガーまたはメモリマッピングユーティリティが、入力される際に鍵を捕捉することを防ぐ。

別の鍵生成方法は自動であり、乱数ジェネレータ（ＲＮＧ）としても知られるランダムビットジェネレータ（ＲＢＧ）を使用することを伴う。今日使用されるランダムビットジェネレータは、決定性（ＤＲＢＧ）と非決定性（ＮＲＢＧ）の２つのカテゴリのうちの１つに属する。ＤＲＢＧはまた、擬似乱数ジェネレータ（ＰＲＮＧ：Ｐｓｅｕｄｏ−Ｒａｎｄｏｍ Ｎｕｍｂｅｒ Ｇｅｎｅｒａｔｏｒ）ともよばれる。ＮＲＢＧは、真性乱数ジェネレータ（ＴＲＮＧ：Ｔｒｕｅ Ｒａｎｄｏｍ Ｎｕｍｂｅｒ Ｇｅｎｅｒａｔｏｒ）とよばれることもある。

種々の標準化団体によって定義され、種々の政府や他の機関によって認定された、いくつかの推奨される種類のＤＲＢＧがある。標準規格検証プロセスの欠如のため、認定または承認されたＮＲＢＧは今までに存在していない。それが開発されるまでは、適切な機関によって認定されたＤＲＢＧ（ＰＲＮＧ）を使用することが優れた実践である。

自動鍵ジェネレータは、単独型デバイスであってもよく、１台の暗号機器に含まれてもよい。ジェネレータは、既成のシステム上で動作するソフトウェアの内部ではなく、セキュアなハードウェアコンポーネントに内包されなければならない。

鍵の配布：いったん作成されると、鍵はデータを暗号化および／または解読するすべてのユーザに配布されなければならない。ここでも、これを実施するためにいくつかの選択肢がある。第１の、および好ましい方法は、電子鍵の配布である。第２の方法は、スマートカードを介した手動配布である。どちらの方法が継続的な様式として使用されても、鍵を電子的に共有することを開始するために、セキュアな通信を始めることができるように、鍵の最初の共有および証明は典型的には手作業で行われる。

配布される時、鍵をアーカイブに、したがって、バックアップ設備に直接送信したほうがよい（図２、接続ａを参照）。鍵のユーザがこれをアーカイブに転送する能力を有する場合、ユーザはデータを暗号化するために鍵を使用する前にそれを行うべきである。

スニーカーネットおよび他の手動の交換機構：手作業の鍵交換の方法を使用する際、データのために使用される鍵のための、および他の鍵を防御するための鍵のために推奨される実践は、「知識分割システム」を使用することである。Ｍ ｏｆ Ｎ（Ｋ ｏｆ Ｎともよばれる）システム等のこれらのシステムは、複数の個人の間で、鍵をいくつかに分割する。知識分割システムの普通の実践では、鍵を５人の異なるユーザに与えられるコンポーネントシェアに分け、次いで、鍵を再確立するために、これらのユーザのうち最小で２人の出席を必要とすることである（例えば、Ａ． Ｓｈａｍｉｒの「Ｈｏｗ ｔｏ Ｓｈａｒｅ ａ Ｓｅｃｒｅｔ」を参照）。

この実践は、レベルが上の鍵またはＫＥＫが遠隔システム上に存在しない場合、いかなる手作業による鍵交換にも推奨される。これは、災害発生時の最上位の鍵リカバリのためにもよい実践である。

どのように鍵が配布されるかに関わらず、強力な方法を使用して、または知識分割トラストを使用して、複数のシェアに分割して、少なくとも１回は暗号化されるべきである。

ネットワークベースの鍵交換：ネットワークベースの鍵交換機構を使用する前に、以下を含むいくつかの検討事項が存在する。
・リンクはどのようにセキュアにされているか。
・リンク上を送信された鍵は、伝送に先立って暗号化されるか（例えば、二重に暗号化されるか）。
・完全なセキュリティは確保されるか。

ネットワーク接続を通じて鍵を交換する前に、エンドポイントはパスワード認証プロトコル（ＰＡＰ：Ｐａｓｓｗｏｒｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）またはチャレンジハンドシェイク認証プロトコル（ＣＨＡＰ：Ｃｈａｌｌｅｎｇｅ Ｈａｎｄｓｈａｋｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）等の強力なネットワーク認証機構を使用して互いに認証し合うべきである。

鍵交換には多くの定義が存在し、その環境に適応した技術が使用されるようにするために、徹底的に調査されるべきである。標準ベースの鍵交換機構の例は、インターネット鍵交換バージョン２（ＩＫＥｖ２）を含む。

ストレージセキュリティを実装する際（例えば、データストレージネットワーク内で鍵を使用すること）、第１のステップは、どの暗号化の方法を使用するか決定することである。典型的には、保存データの状況においては、性能およびフットプリントの問題により、対称鍵が選択のソリューションである。今日、ほとんどの法人は、利用可能な最も強力な暗号化の形式であるため、ＡＥＳを使用している。

いったん暗号化アルゴリズムが選択されたら、次いで、法人は鍵の粒度を決定する。言い換えると、ディスク、ディレクトリレベル、または個々のファイルのどのレベルでデータを暗号化するかということである。鍵の粒度は、典型的にはデータの機密性およびその組織にとっての重大さによって異なる。鍵の粒度は、鍵の変更要件にも影響を与えることがある。

ストレージ環境における鍵の変更：鍵の変更とは、データを暗号化および解読するために新しい鍵が使用される際の作業である。通信中のデータに対しては、作業に影響を与えない鍵の変更方法が存在する。一方、保存データに対しては、作業に影響を与えないために、鍵の変更は計画を必要とする。

別の配慮事項は、システムの鍵変更が、鍵またはデータの潜在的な暴露の結果である場合、古い鍵は削除されるようにマークされなければならない。いったん鍵の変更作業が完了すると、図２接続ｃに示すように、鍵は自動的に、または運用プロセスの一環として、削除されるべきである。

保存データの鍵の変更が計画されなければならない状況がある。そうした事例の１つは、鍵の変更が長時間を必要とすることのあるテープ媒体である。テープ媒体の鍵の変更は、媒体または設備が老朽化のために循環される場合、リカバリを確実にするために計画されるべきである。

加えて、保存データの鍵の変更操作を実施するよい機会を提供し、媒体の整備を通じた現場外のストレージコストを潜在的に削減し、それによって所有権コストを削減することができるため、企業はバックアップおよびアーカイブ操作においても媒体の循環を考慮すべきである。

テープは何年も保管されることができるため、媒体が復元、置換、または期限切れとなる際の鍵の回復性を確保するために、優れたアーカイブ化機構が不可欠である。

継続的な鍵の変更の操作の懸念を軽減することのできる最後の配慮は、それぞれの種類の媒体（例えば、テープ、ＬＵＮ、ファイル、フィールド、オブジェクト、メール）に少なくとも１つの鍵が存在するように、粒度の細かい鍵を使用することである。

鍵のアーカイブ化：鍵のアーカイブ化は、鍵を迅速に復元する能力を提供する。典型的には、鍵のアーカイブ化のプロセスは自動であるが、必要に応じて手作業で行なうこともできる。鍵のアーカイブは、鍵のセキュリティを確保するため、典型的には不正操作防止機能のついた形式のハードウェアの内部に実装される。ハードウェアベースの鍵のアーカイブ化ソリューションの４つの例は、以下を含む。

セキュアメモリ：セキュアメモリは、改ざんや変更される恐れのない、特化したプラットフォーム内部の特定のメモリである。これは操作上の使用においてはまれにしか見受けられず、通常はハードウェアセキュリティモジュール（ＨＳＭ）またはセキュアなハードウェアアプライアンスの副構成要素として付属する。

ハードウェアセキュリティモジュール：ハードウェアセキュリティモジュールまたはＨＳＭは、鍵または他のセキュリティ関連のアイテムにセキュリティを提供する、システム内のモジュールである。鍵管理には、鍵ストレージのためのセキュアな場所を提供し、鍵が別の所で使用される場合、オペレーティングシステムからの防御を提供することができる。

理想的な鍵管理システムは、不適切なユーザ、オペレーティングシステムまたはアプリケーションに絶対に鍵が露出しないようにする、セキュアな通信を提供するＨＳＭを有する。ＨＳＭを含むシステムは、ＨＳＭへの制限されたアクセスを有するべきであり、可能であれば、ＨＳＭは自身が設置されているシステムの外に、自らの管理インターフェースを有するべきである。

セキュアなハードウェアアプライアンス：ストレージセキュリティが暗号化のさらなる需要を作り出すにつれて、鍵の長期のストレージのために必要な量のディスクスペースも増加することになる。セキュアなハードウェアアプライアンスは、大規模な実装および法規制の順守のために必要なストレージスペースを提供する、完全に鍵のアーカイブ化専用のハードウェアプラットフォームである。

専用暗号化システムのベンダーは、これらのソリューションの長期間の保持要件のために、提供商品に鍵管理機能性の追加を開始し始めている。かかる暗号化システムは、それにより内蔵型である。ほとんどの提供商品が完全な鍵のアーカイブ化機能性を提供する一方で、手作業による鍵移動に加えて、外部バックアップとリカバリを必要とするソリューションもある。

内蔵型のシステムが自らのアーカイブを含んでいる場合でも、利用可能な第２のアーカイブまたはバックアップシステムのどちらかが存在するべきである。

鍵リカバリ：保存データ内のアーカイブからの鍵リカバリのシナリオは、規制や他の要件のために、暗号化されたデータが数年間保存されなければならない際に特に重要である。アーカイブは、長期間にわたって鍵を保有することと、必要な時にそれらの鍵を提供することが可能であるべきである。

組織が自動鍵リカバリの実装を選択した場合、組織の需要を確実に満たすために、どういった種類のアーカイブに鍵が保存されるかに関わらず、プロセスは定期的な間隔をおいて試験されるべきである。

鍵のバックアップおよびリカバリ：鍵のアーカイブ化と鍵のバックアップの違いを理解することは、この２つのプロセスは非常に異なる機能を果たすため、重要である。鍵のアーカイブ化は、鍵を保存するが、これらをデータの解読または暗号化のために容易に、およびすぐに利用可能にする。対照的に、鍵のバックアップは、災害発生時に鍵をセキュアにバックアップし、格納する実践である。鍵のバックアップ機構の制御を確実にすることは、鍵のセキュリティおよびインテグリティにとって非常に重要である。不適切な場所に置かれたバックアップファイルは、誰にとっても有用ではないが、一方、セキュリティの弱いバックアップファイルは、事故につながる。

鍵のバックアップの制御を向上させるため、鍵のバックアップを維持するために、遠隔の、組織が所有するセキュアな設備、または認定された／保証付きの第三者の場所に鍵エスクローを実装することが推奨される。しかしながら、これは鍵のバックアップが自動鍵管理システムの一環ではないということを意味しない。鍵のバックアップは、複数のアーカイブから鍵を受け取る第２のアーカイブであってもよい。唯一の警告は、バックアップがアーカイブ自身から離れた、別個の場所に置かれるべきであるということである。

図２、接続ｂに示すように、週に１回のフルバックアップや毎日の増分または差分バックアップ等の通常の実践に基づいてアーカイブをバックアップすることは重要である。

鍵エスクロー：鍵エスクローは、鍵をセキュアな第三者のサイトに維持することの実践であり、これは要求者が適切なアクセス、権限、および信用証明を有する限り、鍵が取り出されることを可能にする。鍵エスクローサービスは、より長期間の鍵管理が業務上の要件となるにつれて、さらに一般的になってきている。

組織は、選択する鍵エスクロー企業がすべての鍵ストレージおよび取り出し要件を満たすことを確認すべきである。これらの能力を定期的に、または災害対策計画の一環として試験することは、常によい実践である。

鍵削除：任意の鍵管理システムへの重要な課題は、いったん鍵が暴露または使用済みになった際、またはそれが保存されていたデータ媒体が紛失、盗難、または交換された際、どのような悪意のある者からも回復されることができないように、確実に削除されることができるようにすることである。

優良な鍵管理システムは、自動と手作業の両者のプロセスを有し、鍵のすべての複製が、すべてのデバイス、アーカイブ、およびバックアップから確実に削除されるようにする。

著しい操作的な間接費を軽減する一方で、自動削除機能性は理想的には、必要通りに削除が確実に機能するように、適切なプロセスを実装する。これは確かに操作サイクルを消費するが、手作業による鍵削除ほどは必要とせず、最高レベルのセキュリティが維持されることを確実にする。

削除できないところに鍵を保持することは推奨されないが、例えば、連邦監査のために、それ以前に紛失されたか不適切な場所に置かれたテープ上のデータの回復のために鍵が必要になる可能性がある。この場合、鍵は１つか２つのセキュアアーカイブ内に存在するべきであり、知識分割機構が採用されていない限り、回復可能であるべきでない。

鍵ロギング：前述において、鍵管理はライフサイクルの観点から記載された。しかしながら、優良な鍵管理システムは、どのユーザが使用したか、その鍵によってユーザがいつ、どのようなアクションを実行したかを記録して、あらゆる鍵を追跡する。これは鍵ロギングとよばれる。

鍵が生成された時から、最後に削除されるまで、その鍵に関係するすべてのイベントは、１つ以上の種類のログに記録されるべきである。次いで、鍵の本質、それが防御するデータ、および鍵イベントが誰に通知されるべきかに応じて、コンソールログ、ＳＮＭＰトラップ、システムログ、安全監査ログ、またはＥメールアラートを含む、１つ以上の種類のアラートが必要とされてもよい。コンソールログは、鍵管理システムとの接続性の喪失からログを防御するため、大容量のバッファを持つ端末サーバを使用する。ＳＮＭＰトラップは、鍵管理業務のための自動化を提供することのできる、標準規格ベースのネットワークまたはシステム管理プラットフォームにアラートを送る。システムログは、自動アクションまたは操作手順を生成するために、相関エンジンまたはＳＮＭＰベースのネットワーク管理システムに入力されることのできるアラートを受け取る。安全監査ログは、犯罪科学の業務または独立した監査活動とともに使用するための、検索可能な監査機構を提供する。安全監査ログは、セキュリティ関連の機能および情報のみを含む。Ｅメールアラートは、個人またはグループによって特定のアクションが要求される場合に、Ｅメール通知を送る。

イベントに基づくアラートは、鍵またはシステムの潜在的な誤用、または潜在的に悪意のあるアクティビティ、ならびに偶発的な人為エラーを相関させるために使用することができる。鍵管理システムの日常業務を簡略化し、イベント発生時に適切な個人が時宜を得た様式で通知されるようにする、アラートプロセスを自動化することは重要である。
以下の表は、５つの一般的な種類のアラートと、これらのアラートが割り当てられるロギングツールを示す。

安全監査ログ：安全監査ログとは、ユーザに許可された、制限されたアクセスを持つシステム上に存在するログである。ほとんどのアクセスは、ブラウザまたはコマンドラインインターフェースのどちらかを介して提供される。安全監査ログは、鍵管理システム内のそれぞれの鍵に発生する、作成、配布、使用、鍵の変更、アーカイブ場所、バックアップ（内部および外部の両者）、および削除を含むあらゆるイベントを捕捉する。

安全監査ログが従来のシステムログと同様にふるまう一方で、アクセス制御およびイベントのためのデジタルサイン等の追加的なセキュリティ機能を含むため、これはよりよいトラッキング機構を提供する。これは、監査または犯罪科学の業務の際の、課題の供給源と決議を決定するための、時間とイベントの相関を可能にする。

安全監査ログは、セキュリティ機能にのみ使用であるべきであり、２つの役割のみを有する。第１に、安全監査ログは、ログ自身へのアクセスを提供することなく、管理者が基本的なシステムセットアップを行い、制御することを可能にするべきである。第２に、特定のイベントを検索し、フィルタをかけ、コメントをつけることのできる監査役を有するべきである。

加えて、安全監査ログは、セキュアタイムスタンプ、メッセージ認証、およびイベントのデジタルサイン等の、従来のセキュリティデバイスに含まれていないサービスを提供するべきである。通常のシステムログにおいて見受けられるイベント削除、修正、手動エントリ等の他の機能は、安全監査ログにおいて許可されるべきでない。

安全監査ログがセキュアなアプライアンスの形式である場合このアプライアンスは、鍵アーカイブ、バックアップ、およびポリシー管理を含む他の機能のために使用されてもよい。しかしながら、ＩＴ組織は、組織のセキュリティおよび動作要件の両者を満たすことを確実にするために、あらゆる機能を個別に評価するべきである。

典型的には、デバイスからの通信および／またはログに記録されたイベントが失われる可能性を軽減するため、別個の場所に少なくとも２つの安全監査ログが存在するべきである。最後に、基本的なセキュア監査ログ機能が、鍵を使用または維持する任意のデバイスに内蔵されるべきである。

鍵管理の概説
理想的な鍵管理システムにおいて、鍵管理は公開のユニバーサルサービスである。鍵の所有者は、その鍵を自ら選択した任意の事業体と共有する能力を有する。コア鍵の管理は、公開標準規格および自由に利用可能な技術に基づく。鍵管理サーバと通信する任意の鍵管理クライアントは、同一のコア鍵管理サービスを受けることが可能である。暗号データの所有者は、自らの暗号データを、好きなように体系化、共有、および維持することが可能である。

鍵管理システムの一態様は、サービスベースのＫＭＳである。鍵管理（ＫＭ）サーバは、鍵管理サービス（ＫＭＳ）のプロバイダである。ＫＭＳにおいて、複数のＫＭサーバがネットワーク全体を通じてサービスを提供する。（ドメイン名サービス（ＤＮＳ：Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｉｃｅ）は、広く展開されるサービスベースのアーキテクチャの例である。）ＫＭクライアントは、ＫＭＳの消費者である。

本技術の目的は、メディアデバイス非依存のプロトコルの利用であり、したがってＫＭサーバが媒体に関する知識有する必要を最小限にすることである。別の目的は、ＫＭサーバおよびＫＭクライアントアクティビティの監査を促進することである。

別の目的は、鍵管理ポリシー（ＫＭＰ）を促進することである。ＫＭＰは、典型的には、ＫＭ担当者によって確立され、ＫＭＳによって維持される。ほとのどのＫＭＰは、ＫＭサーバによって設定され、ＫＭクライアントによって実施されるが、いくつかのＫＭＰはＫＭサーバによって設定され、実施されてもよく、いくつかのＫＭＰは、ＫＭサーバによって設定され、ＫＭサーバおよびＫＭクライアントによって合同で実施され得る。

図３は、種々の種類のストレージ媒体に接続されるホスト、関連するバックアップを持つＫＭサーバ、およびＫＭクライアントからＫＭサーバ（ＫＭＣＳ）、およびＫＭサーバからＫＭサーバ（ＫＭＳＳ）通信への基本図を含む、例示的アーキテクチャの概略図である。鍵は、ＫＭクライアント（通常は暗号ユニット（ＣＵ）を介して）によって、またはＫＭサーバによって、ＫＭクライアントの要求により生成される。ＫＭＳが高可用性のサービスを提供するために、ＫＭサーバはクラスタ化されてもよく、ローカルおよび／または遠隔ＫＭサーバに対して複製が実施されてもよい。

図３において、ＫＭＣＳおよびＫＭＳＳ通信は、暗号化されたリンク（例えば、ＨＴＴＰＳ等のＴＬＳまたはＳＳＬを介するＸＭＬ）を通って送信される。媒体へのＫＭクライアントリンクは、暗号化されてもされなくてもよい。ＫＭクライアンおよびメディアデバイスにＣＵがある場合、次いで、暗号化されたＴ１０−、Ｔ１１−、またはＩＰベースの暗号化が使用され得る。

ＫＭＣＳおよびＫＭＳＳは、言語非依存のＡＰＩを有する。ＫＭＣＳ ＡＰＩは、ＫＭＳアクション（例えば、「鍵生成」、「鍵取得」、「鍵保存」、「ＫＭＳログエントリ作成」）を促進することによって、ＫＭクライアントがＫＭＳを使用することを可能にする。また、ＡＰＩは、可撓性鍵生成ＫＭＰを提供し、ＡＰＩがＫＭクライアントの鍵生成ＫＭＰの実装を助けることができる。

ＫＭＣＳ鍵値は、ＫＭサーバとＫＭクライアントとの間で暗号化される。例示的実施形態において、ＫＭＣＳは通常、ＴＬＳ保護リンクを通じてＸＭＬを送信する。ＫＭＣＳ ＡＰＩは、ＫＭクライアントに解読された鍵値を提供し、鍵は暗号化されたリンクを通じて送信される前に暗号化され、ＫＭＣＳ ＡＰＩによって随意に解読されてもよい。

一実施形態では、ＫＭＳは、ＫＭユーザセッションを提供することができる。ＫＭクライアントセッションモデルは、ＫＭサーバが複数の並列ＫＭクライアントをサポートすることを可能にする。ＫＭセッションは状態ベースであり、ＫＭサーバはそれぞれのＫＭクライアントのために別個の状態を保つ。これは、ＫＭクライアントが、前の要求への返答を待機することなく、並列ＫＭＳ要求を発行することを可能にする。ＫＭクライアントセッションは、ＫＭサーバへのログインを介して開始する（ログインセッションは複数のＴＬＳ接続にわたって存続し得る）。ログインすると、ＫＭクライアントおよびＫＭサーバは、能力交渉、ポリシー通知、セッション情報等のための情報を交換する。セッションは、ＫＭクライアントまたはＫＭサーバのどちらによって終了されてもよく、セッションはまた、制限時間およびＡＰＩログアウトに左右される。

ＡＫＭＳは、ＫＭクライアント・ロールをさらに提供することができる。種々の鍵管理の申し出の間に相互運用性が存在するように、種々の管理者の役割を設ける必要がある。これらの役割は、法人鍵管理が適切に機能するために、最低限、管理者、セキュリティオフィサ、ポリシー管理者、監査役、リカバリオフィサ、鍵ディレクトリマネージャというユーザの役割のクラスを含む。列挙されたユーザの役割は、複数のＫＭサーバ、および潜在的に、インテリジェントＫＭクライアントの間で共有されることのできるユーザの権利の基準レベルを提供する。追加的な役割または副次的な役割は、特定の鍵管理システムにおいて要求される粒度に応じて存在することがあるが、すべてのデバイスによって合意されることのできる、最低限の特定の種類の定義が存在するべきである。

管理者（ＫＭ＿Ａｄｍｉｎ）は、ネットワーク管理、アラートおよびイベント管理、ユーザ作成（役割の割り当てなし）、および非セキュリティ関連の日常業務に責任を負う。セキュリティオフィサ（ＫＭ＿Ｏｆｆｉｃｅｒ）は、役割の割り当て、システムレベルセキュリティ構成、最上位鍵のリカバリの設定、および鍵レポジトリリカバリに責任を負う。ポリシー管理者（ＫＭ＿Ｐｏｌｉｃｙ）は、鍵ディレクトリに適用されるグローバルセキュリティポリシーを作成することと、単一の、または２人の人員を制御するためのユーザポリシーを作成することに責任を負う。監査役（ＫＭ＿Ａｕｄｉｔ）は、セキュリティおよび一般イベントログの両者からのすべてのログ情報にアクセスすることに責任を負う。リカバリオフィサ（ＫＭ＿Ｒｅｃｏｖｅｒ）は、知識分割または多人数の鍵材料制御を使用する際に、最上位鍵のリカバリに責任を負う複数の人員のうちの１人である。鍵ディレクトリマネージャ（Ｋｅｙ＿Ｄｉｒ＿Ｍｇｒ）は、特定の部署または組織の内部の鍵の階層を取り扱うユーザか、またはＫＭＳ環境内の一連のデバイスに対するセキュリティ責務を持つユーザである。

追加的な制御の粒度は、これらのユーザが必要に応じて一般的な役割にマッピングされることができる限り、個々のベンダーに任されるべきである。

ＫＭの一実施例は、以下のとおりＲＡＩＤコントローラの中にＫＭクライアントを提供する。まず、ＫＭオフィサがＫＭＳ内にＫＭクライアントを登録し、ＫＭクライアントのＫＭＰがＫＭディレクトリマネージャによって設定される。その後、ＫＭクライアントがＫＭＳの使用を所望した際、ＫＭクライアントはこれらの一般的なステップに従う。（１）ＫＭクライアントがＫＭＳ内のＫＭサーバを特定し、（２）ＫＭクライアントがＡＰＩを介してＫＭサーバへのログインを実施し、（３）ＫＭクライアントが新しいディスク媒体を検出し、（４）ＫＭクライアントがＫＭＣＳ ＡＰＩを介して暗号鍵のためのＫＭＳ要求を発行し、（５）ＫＭサーバがＫＭクライアント要求を受信して応答し、（６）ＫＭクライアントが新しいディスク＆ログイベントのために鍵の値を使用する。

別のＫＭ実施例は、バックアップアプリケーションのための可撤性メディアデバイスの制御をＫＭクライアントに提供する。まず、ＫＭオフィサがＫＭＳ内にＫＭクライアントを登録し、ＫＭクライアントのＫＭＰがＫＭディレクトリマネージャによって設定される。その後、ＫＭクライアントがＫＭＳの使用を所望した際、ＫＭクライアントはこれらの一般的なステップに従う。（１）ＫＭクライアントがＫＭＳ内のＫＭサーバを特定し、（２）ＫＭクライアントがＡＰＩを介してＫＭサーバへのログインを実施し、（３）バックアップアプリケーションがＫＭクライアントを認識してストレージ媒体を読み込み、（４）ＫＭクライアントがＫＭＣＳ ＡＰＩを介して暗号鍵のためのＫＭＳ要求を発行し、（５）ＫＭサーバがＫＭクライアント要求を受信して応答し、（６）ＫＭクライアントが新しいディスク＆ログイベントのために鍵の値を使用する。

世界的に一意のＩＤおよびＵＲＩ名前空間
一鍵管理システムにおいて、１つ以上のいくつかの利点が存在する。（１）顧客は、自身の鍵組織的なモデルを選択し、自身の鍵を体系化できる。（２）簡易（フラット）と複雑（階層型）鍵組織モデルの両者がサポートされる、（３）ベンダー拡張がサポートされる、（４）将来の標準規格拡張のための予約済みスペースが利用可能である、（５）鍵管理システム内のそれぞれの鍵のために、世界的に一意のＩＤ（ＧＵＩＤ）が作成される。

鍵ＧＵＩＤのためにシステムサポートを有効にする目標は、特に鍵のための統一資源識別子（ＵＲＩ：Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）ベースの名前空間の手段によって達成されることができ、かかる場合、ＫＭＧＵＩＤは、標準形の完全に適確なＫＭＳ ＵＲＩであるということができる。

フォーマット：一実施形態では、ＵＲＩ名前空間は４つの属性を有し、ｋｍｓ：／／ｒｅａｌｍ／ｏｂｊｅｃｔ／ｐａｔｈで表すことができる。ｋｍｓプレフィックスは、ＫＭＳ ＵＲＩ名前空間を識別し、区別する。レルム要素とは、ＤＮＳドメイン名およびＫＭＳ権限のゾーンであり、レルムドメインは一意である。オブジェクト要素は、レルム内部のオブジェクト名前空間を識別し、オブジェクト名前空間はレルム内部で一意である。パス要素は、レルム下のオブジェクトスペース内において一意の要素である。以下にいくつかのＫＭＳ ＵＲＩの実施例を記載する。
・簡易鍵ＧＵＩＤ−ｋｍｓ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｋｅｙ／ｋｅｙｉｄｌ
・ｖａｕｌｔ鍵ディレクトリ下の鍵ＧＵＩＤ−
ｋｍｓ：／／ｂｉｇｂａｎｋ．ｅｘａｍｐｌｅ．ｏｒｇ／ｋｅｙ／ｖａｕｌｔ／ａｃｃｏｕｎｔ＿１２３４５
・ｉｓｐ．ｅｘａｍｐｌｅ．ｃｏｍのＫＭＳユーザのＧＵＩＤ−
ｋｍｓ：／／ｉｓｐ．ｅｘａｍｐｌｅ．ｎｅｔ／ｕｓｅｒ／ｔａｐｅ＿ｖａｕｌｔ＿ｌ
・鍵によるそれ以上の暗号化を禁止するポリシーのＧＵＩＤ−
ｋｍｓ：／／ｆｉｎａｎｃｅ．ｍｙｃｏｒｐ．ｅｘａｍｐｌｅ．ｂｉｚ／ｐｏｌｉｃｙ／ｄｅｃｒｙｐｔ＿ｏｎｌｙ

定義上、ＫＭＳ ＵＲＩは鍵管理下のオブジェクトを識別する。ＫＭＳ ＵＲＩは、典型的には物理的位置ではなく、ＧＵＩＤである。複製鍵のすべての複製が同一のＵＲＩを有するため、ＫＭＳ ＵＲＩは必ずしも特定のＫＭサーバを識別しない。最後に、例示的実施形態において、メタデータは１つのＵＲＩから別のものに複製することができるため、ＫＭＳ ＵＲＩは変更または名前の変更がされてはならず、その必要は絶対にない。

ＤＮＳドメインがＫＭＳ ＵＲＩの要素である場合があるが、ＫＭＳ ＵＲＩモデルはウェブモデルを暗示せず、必要ともしない。ＫＭＳ ＵＲＩは統一資源位置指定子（ＵＲＬ：Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）である必要はない。ＫＭＳ ＵＲＩモデルは、ウェブサーバまたはウェブブラウザのどちらの使用も必要としない。

ＫＭＳ ＵＲＩのレルム要素は、ＤＮＳドメイン名とＫＭＳ権限のゾーンとの組み合わせであることができ、したがって、レルムはＫＭＳ権限のゾーンを示す。

ドメインの所有者のみが、対応するＫＭＳレルム下にオブジェクトを作成することができる。例えば、ＵＲＩ ｋｍｓ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｋｅｙ／ｖａｕｌｔ／ａｃｃｏｕｎｔ＿１２３４５を例にとると、ｅｘａｍｐｌｅ．ｏｒｇ下のＫＭサーバのみがこのＵＲＩを作成することができる。ある状況においては、ＵＲＩはｅｘａｍｐｌｅ．ｏｒｇの外部のＫＭサーバ内で見受けられることがあり、そのＵＲＩに関連付けられた鍵は、ｅｘａｍｐｌｅ．ｏｒｇレルム内のＫＭサーバ内で作成され、その鍵は非ｅｘａｍｐｌｅ．ｏｒｇ ＫＭサーバにエクスポートされる。

ＫＭＳ ＵＲＩの処理において、ＫＭサーバはＫＭＳＳを使用してＵＲＩを１つ以上のＫＭサーバにマッピングし、ＫＭサーバも同様にＫＭＳＳを使用して｛Ｓｅｒｖｅｒ，ＵＲＩ，ｄａｔａ｝マップを取り扱う。

ＫＭＳＳおよびＫＭＣＳには、ＴＬＳが推奨されるが、要求はされない。ＫＭＳＳおよびＫＭＣＳは両者とも、他のネットワーク送信との衝突を避けるため、自身のそれぞれのポートを用意するべきである。

例示的実施形態において、標準規格ＫＭＳ ＵＲＩオブジェクトスペースには、ｋｅｙ（鍵）、ｐｏｌｉｃｙ（ポリシー）、ｃｌｉｅｎｔ（クライアント）、ｇｒｏｕｐ（グループ）、ｐｏｏｌ（プール）、ｓｅｔ（セット）、ｌｏｇ（ログ）、ｓｅｓｓｉｏｎ（セッション）、および．ｄｏｍａｉｎ（ドメイン）を含む。

ｋｅｙオブジェクトスペースは、ＫＭＳ制御下の任意の鍵を含む。実施例ＵＲＩ ｋｍｓ：／／ｒｅａｌｍ．ｄｏｍａｉｎ／ｋｅｙ／ｄｉｒｅｃｔｏｒｙ／ｋｅｙｉｄ、内において、鍵ディレクトリは、／鍵要素と最後の／ｋｅｙｉｄ（注：／はデフォルト鍵ディレクトリ）との間の全体のパスである。鍵ディレクトリは、鍵のための共通の既定のアクセス制御を定義する。ＫＭＳ鍵のＵＲＩは鍵ＧＵＩＤであり、鍵ディレクトリ内部において、ｋｅｙｉｄは一意である。鍵オブジェクトは、鍵の値および鍵のメタデータを保持する。

ｐｏｌｉｃｙオブジェクトスペースは、任意のＫＭＰ名（注：任意のＫＭＳオブジェクトは、ゼロ以上の関連するＫＭＰを有することができる）を含む。ｐｏｌｉｃｙオブジェクトは、ＫＭＰを実行するために必要なメタデータを保持する。ＫＭＳオブジェクトは、そのＵＲＩを介してＫＭＰを参照する。実施例ＵＲＩ ｋｍｓ：／／ｒｅａｌｍ．ｄｏｍａｉｎ／ｐｏｌｉｃｙ／ｐｏｌｉｃｙ＿ｎａｍｅ内において、ＫＭＰへのアクセス制御を画定することができるように、ｐｏｌｉｃｙ＿ｎａｍｅはマルチエレメントパス（例えば、ｋｍｓ：／／ｒｅａｌｍ．ｄｏｍａｉｎ／ｐｏｌｉｃｙ／ａｕｄｉｔ／ａｕｄｉｔ＿ｐｏｌｉｃｙ）であってもよい。

ｃｌｉｅｎｔオブジェクトスペースは、任意のＫＭクライアント名（例えば、ｋｍｓ：／／ｒｅａｌｍ．ｄｏｍａｉｎ／ｃｌｉｅｎｔ／ｃｌｉｅｎｔ＿ｎａｍｅ）、ならびにＫＭクライアントメタデータ（例えば、ホーム鍵ディレクトリ、ユーザポリシー、グループメンバーシップ）を含む。

グループオブジェクトスペースは、ＫＭクライアント名（例えば、ｋｍｓ：／／ｒｅａｌｍ．ｄｏｍａｉｎ／ｇｒｏｗｐ／ｇｒｏｕｐ＿ｎａｍｅ）の任意の一群を含み、ＫＭクライアントは、ゼロ以上のグループに属し得る。ＫＭＳ ＵＲＩアクセス制御を、グループに割り当てることができる。

ｐｏｏｌオブジェクトスペースは、任意のＫＭＳ鍵プールを含み、鍵はゼロ以上の鍵プールに属し得る。鍵プールは、任意の鍵の一群の可能にする。鍵プールはまた、鍵ディレクトリ内の鍵の組織化、取り扱い、および検索のために有用である。実施例ＵＲＩ ｋｍｓ：／／ｒｅａｌｍ．ｄｏｍａｉｎ／ｐｏｏｌ／ｐｏｏｌ＿ｎａｍｅ内において、ｐｏｏｌ＿ｎａｍｅは、アクセス制御に従って、プールへの鍵の追加、またはプールからの鍵の除去が可能になるように、マルチエレメントパスであり得る。例えば、ＵＲＩ ｋｍｓ：／／ｒｅａｌｍ．ｄｏｍａｉｎ／ｐｏｏｌ／ｔａｐｅ＿ｂａｃｋｕｐ／Ｅｕｒｏｐｅ＿ｄａｔａ＿ｃｅｎｔｅｒ、プールへのアクセスは、／ｔａｐｅ＿ｂａｃｋｕｐアクセス制御およびＥｕｒｏｐｅ＿ｄａｔａ＿ｃｅｎｔｅｒアクセス制御に従う。

ｓｅｔオブジェクトスペースは、任意の鍵の時間順序一覧を含み、一覧上のすべての鍵は、同一のデータオブジェクトに関連付けされる。例えば、鍵の変更が必要なデータは、典型的には、オブジェクトの古いバージョンの復元を促進するように、鍵セットに属する。ｓｅｔオブジェクトスペースはまた、鍵セットメタデータ（例えば、最も古い鍵、最も新しい鍵）を含む。鍵は、ゼロ以上の鍵セットに属し得る。例ＵＲＩ ｋｍｓ：／／ｒｅａｌｍ．ｄｏｍａｉｎ／ｓｅｔ／ｖｅｒｓｉｏｎ＿ｓｅｔ＿ｎａｍｅ内において、ｖｅｒｓｉｏｎ＿ｓｅｔ＿ｎａｍｅは、アクセス制御に従って、プールへの鍵の追加、またはプールからの鍵の除去が可能になるように、マルチエレメントパスであり得る。

ｌｏｇオブジェクトスペースは、任意のＫＭサーバログを含み、また、ログに関する統計を含む（注：いくつかのログＵＲＩはＫＭＳの外部に書き込まれた場合、書き込み専用である）。ｌｏｇオブジェクトは、ＫＭＳイベントおよびＫＭクライアント要求イベントを記録する。例ＵＲＩ ｋｍｓ：／／ｒｅａｌｍ．ｄｏｍａｉｎ／ｌｏｇ／ｌｏｇ＿ｎａｍｅ内において、ｌｏｇ＿ｎａｍｅは、アクセス制御に従って、ログの追加もしくは読み込みが可能になるように、マルチエレメントパスであり得る。

ｓｅｓｓｉｏｎオブジェクトスペースは、アクティブセッションに関する任意の情報を含む。例えば、かかる情報には、ＫＭクライアントが読み出すべきメッセージを含み得、メッセージＵＲＩは、ｋｍｓ：／／ｒｅａｌｍ．ｄｏｍｅｉｎ／ｓｅｓｓｉｏｎ／ｓｅｓｓｉｏｎ＿ｉｄ／ｍｅｓｓａｇｅ／ｍｅｓｓａｇｅ＿ｉｄの形式である。ｓｅｓｓｉｏｎオブジェクトスペースはまた、ＫＭサーバによって受信されるが、ＫＭサーバに応答されない、セッションおよびＫＭＳ ｏｐ ＩＤに関する統計的な情報を保持する。ｓｅｓｓｉｏｎ＿ｉｄはノンスとなり、例示的実施形態は、ＡＳＣＩＩ１６進形式で示される５１２ビットの値によって表されるｓｅｓｓｉｏｎ＿ｉｄを利用する。ｓｅｓｓｉｏｎ＿ｉｄは、典型的には予測が困難な値であり、例示的実施形態では、エントロピーが少なくとも３２０ビットのＳＨＡ−５１２ハッシュを用いる。

．ｄｏｍａｉｎオブジェクトスペースは、ＤＮＳドメインのために予約されたオブジェクトスペースであり、これはベンダーおよびアプリケーションの拡張を可能にし、これはレガシー鍵管理システム、特別なベンダー機能性、および特別なアプリケーションスペースに有用である。予約済みのオブジェクトスペースは「．」で、予約済みのドメインは「．．」で開始する。

鍵管理アーキテクチャ
本明細書に別に記載するとおり、鍵管理システムの構成要素は典型的に、暗号化デバイス、鍵生成能力、鍵アーカイブ、鍵のバックアップシステム、鍵保持ポリシー、ロギング、イベント、およびすべての適切な操作手順を含むがこれに限定されない。これらの構成要素に基づいて、組織の需要およびセキュリティ要件に最も適した鍵管理アーキテクチャが選択されなければならない。

典型的には、集中型および分散型の２種類の鍵管理アーキテクチャが存在する。ハイブリッドアーキテクチャも可能である。

集中型鍵管理システムは、あらゆる機能が単一の中央の位置に生じることを必ずしも意味しない。そうではなく、これは典型的には、鍵管理プロセスのそれぞれの部分が、どこで発生し、鍵、およびしたがってデータが暗号化を実施するユーザまたはデバイスによってアクセスされることができるポイントを限定するかに関して、管理者が集中型の制御を有することを意味する。

図４は、集中型鍵管理システムの機能を示す。この図において、各管理者は、一部または全体のシステムに影響を与える任意の鍵動作を行うために、集中型システムを使用する。

集中型鍵管理システムは、アラートおよびアクションがより効率的に伝播することを確実にすることにより、いくつかの分散型鍵管理システムよりもより容易に、より多くの数のプロセスが自動化されることを可能にする。しかしながら、鍵を遠隔サイトで再確立するためには、より多くの時間が要求されるため、集中型システムにおいては鍵リカバリプロセスの速度が低下する可能性がある。

分散型鍵管理システムは、利益共同体および信用が存在する動作の需要を満たすために設計される。これは、組織内の他の部門のユーザが、特定の部門またはグループによって作成された鍵へのアクセスを必要としないか、これを持たないことを意味する。

ユーザは、生成、配布、使用、アーカイブ化、および削除のそれぞれの鍵管理機能に、集中場所を通じてではなく、場所または領域レベルで、直接アクセスする。図５に示すように、鍵は複数の位置に存在する。

これは、鍵リカバリを集中型システムよりも操作上容易にすることができるが、しばしば集中型監査軌跡を犠牲にする。例えば、１つのサイトが自身の鍵を失うと、ただちに行動を開始する人員がいない可能性がある中央サイトからのバックアップの復元を必要とすることなく、別のサイトがその鍵を回復するために使用することができる。

分散型システムはまた、特定の関心を持った個人または一群の人々が、遠隔の場所で使用することが必要とされる可能性のある鍵またはログを、不注意で、または悪意を持って削除することができないように、より優れたセキュリティ機構を適所に提供する。副次的な利点としては、障害や大惨事の発生時に、１つのシステムが別のシステムを停止させることがない。

しかしながら、１つの鍵管理の１つのコンポーネントを１つの場所に、別のものを別個の場所に置くことは、実装の行き届いた鍵管理システムに役立つ。例えば、鍵アーカイブおよび鍵のバックアップを同一の場所におくことは、サイトの機能停止時に、潜在的に鍵管理システムに惨事を引き起こす。

長年にわたり、分散型鍵管理システムは集中型システムよりも実装が容易であったが、潜在的な鍵管理システムや、これを操作するために要求される人員の数のために、大規模な組織で計ることは困難であり得る。

分散型アーキテクチャについて、セキュリティがプロセスにおいて犠牲にならないことは重要である。アクセス制御は、可能であれば集中型の場所から依然として維持されるべきである。

暗号化システムが内部の鍵生成およびアーカイブを含む場合、典型的には、少なくとも遠隔設備への、自動の様式による鍵のバックアップが可能であるべきである。より多くの鍵ライフサイクルの機能が暗号化デバイス内に設置されるほど、配布機構はより強固にならなければならない。

多数の鍵管理プロセスを自動化する企業にとっては、分散型鍵管理は優良な代替案でない場合がある。

ハイブリッド鍵管理システムは、組織のセキュリティおよび操作上の必要条件に基づいて、集中型および分散型システムの両者の最良点を生かす。

図６に示すように、鍵生成は中央の位置においてのみ発生する。しかしながら、ロギングおよびイベントは、分散型および集中型のロギング設備を提供するために、組織内の種々の場所から渡される。ローカルと集中型ロギングの組み合わせはまた、ログ比較プロセスを使用して、監査または他の犯罪科学の要求のために、見過ごされたログイベントを防ぐ。

市場のほとんどの鍵管理システムは、集中型であるように見えるが分散型機能性を有しており、ハイブリッドとして設計されるべきである。そのよい実施例の１つは、鍵を中央で生成するが、鍵リカバリ機構をネットワーク末端に実装する鍵管理システムである。

鍵は、１つ以上の分散型アーカイブに保存されるべきであるが、バックアップは使用され、アーカイブされる場所から離れた遠隔設備で行われる一方、制御およびロギングは中央に位置する。

上記の３つのアーキテクチャの使用にあたり、組織は単一または複数のサイト構成に基づいてシステムをどうやって最良に実装するかを考慮することが必要である。

鍵管理を単一のまたは複数のサイトに実装する際、異なる検討事項が存在する。

単一サイトでの実装において、鍵のバックアップとリカバリに対して特別な注意が払われなければならない。鍵の変更および／または鍵の削除は、キーイング材料の任意の部分へのアクセスを有する人事に変更があった任意の時に発生するべきである。加えて、組織は、第三者設備への鍵エスクローの設置を深く考慮するべきであるが、エスクローサービスが組織のセキュリティおよびデータリカバリに対する動作要件を満たすかどうかの評価をその前に行なうべきである。

一方、複数サイトでの実装には、適切なセキュリティ機構が実装されている限り、組織の内部で鍵を複製する、遠隔サイトの利点がある。完全なリカバリ能力を提供するために、最低限、鍵はローカルでアーカイブされるべきであり、定期的なバックアップは遠隔で行われるべきである。ロギングもまた、集中型安全監査ロギングに加え、ローカルでは少なくとも２つのサイトの間で複製されるべきである。

実装のサイトの数次第では、組織が発展したり、サイトの数が拡大したりした際に集中型またはハイブリッド鍵管理システムに移行する能力を提供する限り、分散型鍵管理システムから開始したほうが容易であることがある。

複数サイトの実装において、情報が企業または特定の部署に対して極秘である可能性があるため、組織内のすべてのサイトがデータへのアクセスを持たず、これを必要とすることのないように、セキュリティ機能に対する管理等、任務の分離はより重要になる。この場合、それに本来備わるアクセス制御のため、集中型鍵管理システムが好ましい。

鍵管理システムが総合的なセキュリティ戦略の一環である一方で、セキュリティは、アクセス制御、認証、およびロギングの形式において、鍵管理自体で非常に重要な役割を果たす。

鍵管理システム内部のアクセス制御は、誰がまたは何が、どの鍵へのアクセスを有するかを保証する。最も単純な機構は、すべての鍵管理者およびすべての暗号化デバイスに、すべての鍵へのアクセスを許可することである。しかしながら、現実にはあらゆる人物またはすべてのデバイスが同一鍵へのアクセスを必要としているわけではない。鍵へのアクセスを制限することにより、組織はセキュリティリスクに対するその脆弱性をも制限する。

鍵の認証は、鍵が保存される際に暗号化される場合、常に推奨される。認証機構自体はセキュアであるべきであり、平文データが漏洩しないことを確実にするように、認証は暗号化されたデータ上のみで実施されるべきである。

最後に、鍵管理システムは、システム内のあらゆるイベントをログ記録するため、安全監査ログサーバを使用するように構成されるべきである。管理者は、このサーバに制限されたアクセスを有するべきであり、暗号化されたファイルのために暗号化、認証、およびデジタル署名を使用して、まずアーカイブ化がされないうちは、ログの削除を許可するべきでない。ログを閲覧するためのサーバへのアクセスは、監査ユーザのみに限定されるべきである。

例示的暗号ユニット（ＣＵ）
本項では、種々の媒体やデータの種類に関して差異が考慮に入れられるべき場合を除いて、すべての保存データをオブジェクトと呼び、そうである場合にはそのように記載される。

今日、暗号化の場所に基づいて、単一の鍵から数万の鍵がおそらく管理を必要とする。要件が進化するにつれて、この数は管理下にある１兆の鍵を軽く越えるであろう。この理由により、単純な、使いやすい鍵管理サービスが、以下の検討材料を念頭に置いて定義されるべきである。

問題となっているデータの種類、機密性、およびセキュリティ要件に基づいて、２つ以上の暗号化の場所が使用される事例があり得る。

暗号化の場所：暗号化は、システム内の種々の場所で実施することができる。システムは、アプリケーション、オペレーティングシステム、ファイルシステム、ホスト、ネットワークインターフェース、ネットワーク、ストレージコントローラ、およびストレージデバイスを含む。正確に何が暗号化されるのかは異なる場合があるが、それぞれの暗号化地点は、異なるレベルのセキュリティを提供する。

暗号化の場所に応じて、暗号化はハードウェアおよび／またはソフトウェアのどちらかで実施され得る。本明細書の目的のためには、この２つの選択肢の間には差異が設けられず、動作にとってどちらの方法が正しいかの判断は、エンドユーザの決定に委ねられる。

現行のアーキテクチャに基づくと、組織が複数の暗号化場所を使用し続けるであろうことは、非常に起こり得ることである。組織は、データ要件、企業ポリシー、および／または規制基準に基づいて、特定の環境に最適に合致するように、種類や場所を決める。

暗号化の場所は、自身の鍵生成および／またはストレージ能力を有してもよいが、キーイング材料を取り扱う際の使いやすさを提供するため、集中型鍵管理サービスと統合される必要が依然としてある。

鍵管理機能がＣＵに内蔵されているか否かに関わらず、集中型鍵管理は、階層型、またはピアツーピアをベースとしたシステムの鍵管理セットのどちらかを使用する。以下は種々の側面である。

１．アプリケーションの暗号化
アプリケーションの暗号化には、多くの形式がある。ここで暗号化されたデータベースアプリケーションと、バックアップの暗号化の両者を考察する。データベースの暗号化は、自らのストレージに保存されている間のデータの暗号化を提供する。バックアップアプリケーションの暗号化は通常、データを可撤性メディアデバイスに保存する。どちらのアプリケーションも暗号化機能を有するが、それぞれは暗号化をまったく異なる目的のために使用する。どちらもデータベース毎に１個の鍵から潜在的に数万個の鍵にわたる、種々のレベルの暗号化を、記録毎、１回毎にアクティブの原則で提供する。

鍵は異種のアプリケーション間では絶対に共有されないが、Ｅメールやデータベースサービス等の高可用性のアプリケーションを実行する複数のサーバによってアクセスされることが必要となり得ることは、依然として可能性が高い。

２．ホストエージェント暗号化
システム外のＣＵに暗号化またはリンクを提供するエージェントは、アプリケーションレベル、ＯＳレベル、またはファイルシステムレベルにおいて、エージェントの使用や機能に応じて使用することができる。鍵の数は、他のそれぞれの暗号化の場所のものと近くなる。

３．ホストハードウェアの暗号化
暗号化エンジンは、システムハードウェアに内蔵されるか、システムに追加されることのできるプラグ脱着可能なモジュールとして実装される。これらのデバイスはしばしば、ハードウェアアクセラレータとよばれる。

ハードウェアアクセラレータは、アプリケーション、ＯＳ、またはＣＵへのアクセスを必要とする他のシステムコンポーネントと連動するために、概してソフトウェアドライバの使用を必要とする。

４． オペレーティングシステム暗号化
暗号化を提供するオペレーティングシステムは通常、ファイルシステムレベルか、またはアプリケーションがオペレーティングシステムソフトウェアまたはホストシステムの内部の暗号化ハードウェアのどちらかに内蔵される暗号化を使用することを可能にするＡＰＩのレベルでこれを実施する。

５．ファイルシステム暗号化
ファイルシステムレベルで実装される暗号化は、ディスク、ディレクトリ、またはファイルシステムレベルに設定された規則に基づいて、ディレクトリ、シェア、または個々のファイルの暗号化を提供する。この方法は、システム毎の鍵からファイル毎の鍵までの間の任意のレベルを必要とする。

大規模な組織において存在する非常に多くの鍵には、ファイル毎の鍵がどのようにＫＭＳに影響し得るか、特別な配慮が与えられるべきである。この鍵は潜在的に、長い地理的な距離にわたって配布される、数１０億の鍵に及ぶ。

このような事例は、これらの環境全体にわたって、どこに、どうやってＫＭサーバを置くかに関わる、許容範囲にある実践、および、鍵検索の実施のための応答時間がどのように影響を受けるかに特定の配慮が与えられることを必要とする。

６．ＮＩＣおよびＨＢＡの暗号化
ホストインターフェースレベルでの暗号化は、暗号化を特定の標的媒体（ディスクまたはテープ）を基礎に置くか、もしくはアプリケーションがドライバを呼び出して、特定のデータの種類を、保存される際にはっきりと暗号化することを可能にするかを基礎に置くかという決定が下されることができるように、送信されるデータの種類の理解を必要とする。

７．ネットワークおよびファブリックの暗号化
ネットワークまたはファブリック内で実装される暗号化は、スイッチやルータ等のネットワークデバイス内、または暗号化タスクのために製造されたアプライアンスで行なうことができる。デバイスは、ファイル暗号化、テープ暗号化および／またはディスクブロックベースの暗号化等の特定のアプリケーションをサポートすることができる。アプライアンスの扱いは、電気器具の手法は、プロキシデバイスとしてネットワークの脇にあるか、またはプロキシとして、もしくはｂｕｍｐ−ｉｎ−ｔｈｅ−ｗｉｒｅとして不可視で、直接インラインであってもよい。

８．ストレージコントローラの暗号化
ストレージコントローラは、データが複数のストレージデバイス上でマネージドされることを可能にする。ストレージコントローラは、アレイコントローラ、テープライブラリ、ＣＤ／ＤＶＤ ＲＯＭジュークボックスコントローラ、またはやはりホストとライブラリまたはアレイ等のストレージシステムとの間のネットワークに据えられ得る仮想化コントローラを含む。ストレージコントローラにおいて実施される暗号化は通常、ストレージアプリケーションに特有の暗号化を提供する。

９．ストレージデバイスの暗号化
ストレージデバイスは、追加的なソフトウェアまたはハードウェアを必要とすることなく、媒体に書き込まれる際に暗号化を実施する能力を有するドライブである。暗号ユニットは、ＣＤ／ＤＶＤ−ＲＯＭドライブ、ディスクドライブ、フラッシュメモリシステム、およびテープドライブ等のデバイスを含む。

ストレージデバイスは暗号化を実装する能力を持つことになるが、外部デバイスが鍵管理機能を提供することを必要とする可能性がある。これらの外部デバイスは、ストレージコントローラ、アプリケーション、または標準規格ＫＭＳへの接続性を提供することになる専用の鍵管理インターフェースであり得る。

しかしながら、デバイスの暗号化は、検討材料媒体の種類に基づいて、多数の検討事項をもたらす。本明細書では、実施例としてテープとディスクを使用するが、別の媒体種類は追加的な検討事項を有する可能性がある。

テープ媒体暗号化について、現行では媒体が２つ以上の鍵を必要とすることは絶対にないという主張が存在する一方で、今後のバージョンのドライブが、その媒体のための２つ以上の鍵をサポートすることは可能である。これは、任意の媒体のための任意の時間において、複数の鍵が保たれる必要がある可能性があることを意味する。現在、利用可能な唯一の一意のＩＤは、媒体製造番号である。これは、媒体製造番号がディレクトリ内の鍵セットＩＤとして使用されるべきであり、この媒体のために使用されるそれぞれの鍵が、鍵セット内のグローバル一意識別子（ＧＵＩＤ）として割り当てられるべきであるということを示唆する。こうすることにより、テープデバイスは、この媒体のために生成された最後の鍵を鍵セットから、または依然としてアクティブな、この媒体のための鍵のグループ（セット）を読み出すことができる。

もはや使用されなくなった鍵は、まずは無効化されるかまたは破壊される。この場合、鍵が破壊される場合、そのメタデータは監査を目的として保持され、キーイング材料のみがゼロ化されるべきである。

ディスク環境について、鍵の数は、暗号化のレベルに基づくことになる。図７および図８に示すように、ディスクアレイ毎に、ＲＡＩＤグループ毎に、ＲＡＩＤグループ内のディスク毎に、与えられたＬＵＮ毎に、ＲＡＩＤグループ内のスライス毎に、およびＬＵＮ上の毎に１つ以上の鍵を有することが可能であるが、本技術は本明細書に記載の構成に限定されない。

他の選択肢と異なり、ディスクアレイ毎に１つ以上の鍵を使用することは、データを暗号化する単一のまたは潜在的に２つの鍵のみを必要とする。この場合第２の鍵は、アレイ内部にローカルで保存された場合、第１の鍵を保護するために、鍵を暗号化する鍵（ＫＥＫ）として使用される。

ドライブの暗号化の他の事例（図８を参照）は、同一アレイの内部に同時に構成されることができる。そのようなに事例おいて、アレイは、そのアレイおよび能力に応じて、数１０から数１００万の鍵を有し得る。図８は、最良の柔軟性およびセキュリティをエンドユーザに提供するために、サポートされるべき異なる種類のディスク暗号化構成を示す。第１の構成は、共通鍵を使用するＲＡＩＤグループを示し、ＲＡＩＤグループ１は第１の鍵を使用し、ＲＡＩＤグループ２は第２の鍵を使用して暗号化される。これは、ＲＡＩＤグループが単一のディスク、または類似のデータ（同一所有者には同一の分類）のために使用される複数のディスクとなることを可能にする。

第２の選択肢は、ディスク毎の鍵を提供する。これは、ディスク障害の発生時に単一鍵の除去を可能にすることで、ＲＡＩＤ毎の鍵を上回る利益を有する。

第３の選択肢は、ＲＡＩＤグループ内の異なるスライスが異なる鍵を使用することを可能にし、ユーザが同一のＲＡＩＤグループ内の異なる種類のデータのためにストレージを配分することを可能にする。これは、ＬＵＮが複数のＲＡＩＤグループを横断しない場合に、次の選択肢に示されるＬＵＮ毎の鍵でも機能する。

第４の選択肢は、与えられたＬＵＮ毎に鍵を使用する能力をもたらす。これは、どうやって最多のストレージを取り扱うかと合致するレベルでの制御を可能にする。ＬＵＮ毎の鍵のサポートを提供することにより、単一の事業体としてディスクはさらに容易に鍵の変更、複製、または破壊することができる。

最後の選択肢は、ＬＵＮのサイズが大型化した際にいくつかの効果を有し、デバイスに書き込まれるデータの量は、通常、潜在的にデータまたは鍵を露出することなく、同一鍵を使用して安全に暗号化されることのできるデータの量を上回る。スライス毎の鍵の問題は、ブロック範囲に、または単一のホストまたは複数のホストによってＬＵＮ上に論理的に保存されるパーティションに基づいて暗号化が実施され、ストレージアレイまたはドライブに追加的なオーバーヘッドを必要とする可能性があることである。

１０．暗号化されたキャッシュ
一般的に使用はされないが、将来においては、データが一時的に保存される潜在性を有する場所を暗号化することが好ましい可能性がある。データのキャッシングもまた、データの物理的ユーザと最終ストレージ場所との間の任意の場所において発生し得る。

この理由のため、キャッシングは本明細書の対象とはならない可能性のある、特別な一連の要件を有する可能性がある。キャッシュは、たとえ一時的であっても、データが保存される任意の場所と考えるべきである。

１１．ユーザエンドポイントの暗号化
通常のストレージネットワーク環境に該当しない１つの場所は、デスクトップシステム、ラップトップ、ＰＤＡまたは取り外し可能な媒体（フラッシュメモリストレージデバイスを含む）または外部に取り付けられたスタンドアロンのドライブ等の移動データデバイス等のユーザエンドポイントである。

鍵管理標準規格は、ＫＭＳにアクセスするためには、ネットワークへの接続性を有しない可能性のあるシステムの要件を考慮にいれなければならならず、したがってキーイング材料のローカルストレージを必要とする。これはまた、これらの鍵に対するセキュリティについて、およびデバイスの内部でこれらがどのように維持され、制御されるかについての熟考を必要とする。

ここでのベストプラクティスは、データが認証されていない宛て先に不注意で暗号文ではなくプレーンテキストとして複製されないようにするために、ＰＫＩの大規模な利用および証明を必要とする可能性がある。最後の選択肢は、データの悪意のある複製を拒絶する能力を提供しない。オブジェクトベースの暗号化、および組織のすみずみまで広範囲に拡張することができる関連する鍵管理には、どのように使用、複製、または操作されるかに関わらず、実際のデータを保護するために、追加的な配慮が与えられるべきである。

鍵管理業務：クライアント／サーバの動作および相互アクションの記載がある際、クライアントは、ＫＭクライアント、ＣＵ、または別の鍵管理システムであることができ、一方サーバは、クエリが行われるか、または鍵管理アクションを実施する鍵管理システムである。

鍵が既存の鍵管理システムから、アップグレードパスが使用可能でない、より新しい、または異なるシステムに移動することができるように、インポートおよびエクスポートのための追加的な機構が、任意のシステムに含まれるべきである。

鍵レポジトリとＣＵとの間の接続性には、鍵がセキュアに伝送されることができるように、暗号化された通信を使用するべきである。接続性は、要求に応じてセキュアな様式で確立されるべきである。さらなる通信要件は、本明細書の別の箇所に記載される。以下はその種々の側面である。

１．自動対ユーザ主導
鍵管理サービスは、自動およびユーザ主導機能の両者、および特定の種類の動作が使用される場合、またはアクションを必要とするイベントが発生した場合、介入を考慮にいれるべきである。特定のアクションまたは反応のためのどちらの方法も、鍵管理業務によって実装される特定の鍵管理サービス次第である。

２．鍵の生成
自身の鍵を生成する能力を有しないＣＵには、外部の鍵生成サービスへの要求が行われるべきである。鍵生成要求には、提供される鍵のビットサイズを含むべきである。

鍵生成は、手動か、またはＲＮＧのどちらかによって鍵が作成される際のことである。鍵は、暗号化デバイスか、または鍵管理サービスによって、からの要求に応じて自動的に生成されることが可能であるべきである。

鍵が手作業で作成されると、次いで、鍵は安全保護のため、ＫＭクライアントまたは好ましくは、暗号ユニットに入力されるべきである。鍵の手動作成またはエントリは、ＫＭサーバにおいては許可されるべきではない。手動で入力された鍵は、ＫＭクライアントによって保存された場合、または認証されたＫＭクライアントによって読み出された場合、ＫＭサーバのみに入るべきである。

ランダムビットジェネレータに当てはまる用語には、ＤＲＢＧ、ＤＲＮＧ、ＮＲＢＧ、ＮＲＮＧ、ＰＲＮＧ、およびＴＲＮＧを含む。それぞれは、使用されるジェネレータの種類を定義する。これらの用語はしばしば、当技術分野において同義に使用される。

３．鍵の保存
いったん鍵が生成されると、認証されたデバイスによって必要とされた際に取り出せるように、セキュアなレポジトリの中に保存されるべきである。鍵の保存は、ＣＵが鍵をセキュアであると見なされない可能性のあるネットワークやシステムに暴露する潜在性なしに、セキュアに鍵の認証、接続、および保存を行うことのできる機構を提供するべきである。この機能は、ＫＭＣＳおよびＫＭＳＳ通信において使用される。

鍵管理サービス、およびその内在する要件のうちのいくつかに関連する情報および概念は、ＮＩＳＴ ｓｐｅｃｉａｌ ｐｕｂｌｉｃａｔｉｏｎ ＳＰ８００−５７パート１およびパート２に見出すことができる。

４．鍵の取り出し
鍵を格納する機能と同様、鍵を同程度セキュアに取り出すことができる必要性が存在する。これは、鍵がもともとデータを暗号化するために使用された場所、および潜在的に、媒体または問題となっているオブジェクトを解読することを必要とするＤＲサイト、遠隔施設（支店）またはパートナーのサイト等の他の場所からの取り出しを含む。この機能は、ＫＭＣＳおよびＫＭＳＳ通信において使用される。

５．鍵の修正
鍵の修正には、いくつかの理由が存在する。最初の理由は、有効期限や、または任意の鍵に関連付けられたメタデータのいくつかの他のコンポーネントの変更等の、関連するメタデータを修正することである。鍵を修正することは、鍵を無効化する、または破壊することを意味しない。これらの機能は、鍵の除去に該当する。この機能は、ＫＭＣＳおよびＫＭＳＳ通信において使用される。

６．鍵の検索
鍵検索機能は、ＫＭレルムの作成の一環ではないが、キーイング材料への権利を有するデバイスによって、媒体が読まれる場合に、鍵検索のために要求される。ロギング設備が証拠として受け入れられないか、受け入れられることができない場合、検索にはまた、監査の証拠が必要とされる。この機能は、鍵検索においてＫＭＳＳを使用して使用される。

７．鍵の権利
鍵にアクセス権利を設定することで、ディレクトリ構造が論理デバイスに対する場所に基づく場合、１つの鍵ディレクトリで作成された鍵が、別の鍵ディレクトリで使用されることを可能にすることにより、媒体がモバイルであることを可能となる。これは、鍵へのアクセス権利を予め決定する一連のポリシーに基づいて、ＣＵが媒体にアクセスすることを可能にする。このクエリ機能は、ＫＭＳＳ鍵交換および検索に使用される。

８．鍵の汚染
鍵が、鍵の安全プロファイルを満たしていないシステム上で使用された場合、次いで、その鍵は汚染されたと印付けされるように、鍵を汚染する能力は存在するべきである。

いったん鍵が汚染されると、これはその鍵、鍵ディレクトリ、またはレルム安全プロファイルに基づいて整えられたポリシーに基づいて、依然として使用されることができる（または使用できない）。

汚染鍵のためのポリシー考慮事項は、汚染された後、鍵がどのように使用されるか、または使用されないかであり、無効化するか、自動でまたは手動のどちらかで破壊することを含むべきである。

９．鍵の除去
鍵を削除する際に考慮されるべきいくつかの機能は、鍵を無効化すること、取り消すこと、および破壊することを含む。それぞれは、暗号鍵を取り扱う際に要求される特定の機能を供給する。

鍵を無効化することは、データを暗号化するために使用される対称鍵に適用される。この無効化機能は、鍵をＫＭＳの中に留める。この機能はまた、鍵がＫＭクライアントアクセスから確実に除去されるようにする。例示的実施形態において、無効化鍵を使用するためには、ＫＭクライアントは１つ以上の認証されたオフィサからの許可を必要とする特別なアクセスを供与されなければならない。無効な鍵は、復元されるか、または破壊されるまで、その鍵の生涯において、無効な鍵のままである。

鍵を無効化することは、取り消された鍵は再び使用されるために回復されることがない点で鍵を取り消すこととは異なり、一方、ＫＭレルム内のＫＭクライアントは、再び使用するために後で無効な鍵を復元することができる。この機能は、ＫＭＣＳおよびＫＭＳＳ通信において使用される。特に、無効化された鍵は、鍵を保存する能力を有する任意のＫＭクライアントから物理的に除去されるべきである。

ほとんどの場合、この鍵取り消し機能は、ＫＭＳシステムと統合するＰＫＩ実装のみに適用される。これらの事例において、証明書失効リスト（ＣＲＬ：ｃｅｒｔｉｆｉｃａｔｅ ｒｅｖｏｃａｔｉｏｎ ｌｉｓｔ）は、取り消されたすべての鍵を追跡し、これらのリストの管理は、従来のＣＡの責務である。

ＰＫＩが実装されず、公開鍵と秘密鍵の対が保存データの認証および暗号化のために使用されるという事例があり得る。これらの場合において、取り消しは、単一の、または小グループのユーザに基づいて、ファイルまたはオブジェクトを暗号化するために使用され得るこれらの鍵の対に適用される。これらの鍵にはまた、標準規格鍵取り消しの実行が維持されるように、サービスとＣＵとの間の通信が必要とされる。この機能は、ＫＭＣＳおよびＫＭＳＳ通信において使用される。

鍵が、ライフサイクルまたは暴露基準に基づいて、有用性の限界に達した場合、この鍵自身は、キーイング材料にゼロ化機能を実施することによって破壊されるべきであり、これはゼロ化の後の記録の除去を含み得る。監査を目的として、破壊後のいくらかの期間、関連するメタデータを保持することが望ましい場合がある。この機能は、ＫＭＣＳおよびＫＭＳＳ通信において使用される。

１０．鍵の復元
具体的には、既知の理由により、追加的な認証を必要とすることなく、鍵が依然として継続的に安全に使用できると見なされる場合、無効化鍵に適用される。この機能は、鍵の無効化が許可される場合のみに必要とされる。

１１．鍵の複製
この機能は、具体的には鍵が保存されていた元のサーバから追加的なサーバに鍵を複製するために、ＫＭサーバ間で使用される。この機能は、ＫＭサーバに障害が発生した際、認証されたＫＭクライアントが依然としてこの鍵にアクセスすることができるように、鍵ストレージの冗長性を提供する。この機能は、鍵の保存とは異なる。その違いは、受け取る側のＫＭサーバが、これは鍵の発信レポジトリではないと認識しており、したがって鍵に対するポリシーを設定する権利を有しない可能性があることである。

１２．鍵のインポートとエクスポート
２つの別個のサービス間に接続性が存在しない場合に、ときどき、鍵のＫＭＳへのインポートまたはエクスポートの必要性が生じる。一般的なファイル／ストレージフォーマットおよびセキュリティ機構が、ラップトップやＰＤＡデバイス等のモバイルデバイスを含む取り外し可能な媒体にエクスポートされる鍵のために存在するべきである。

別の検討事項は、どの鍵がエクスポートされるのか、誰がそれらをエクスポートすることができるのか、および遠端において誰がそれらをインポートすることができるのかに関するインポート／エクスポートのために使用されるポリシーである。また、既存の鍵が暴露されないように、鍵をその現行の鍵ラッパーから翻訳するための方法があるべきである。この理由のため、ＫＭＳは、鍵にサポートされるラップの数に限定されるべきである。標準規格によって定義される優良な鍵タイピングがある限り、技術の変化に伴って異なるラップがとして追加されることができる。

エクスポートは、多数の鍵がエクスポートされる場合でも、セキュリティ機構か、またはファイル自身のどちらかのために、知識分割を要求する能力を有するべきである。

ＫＭＳ動作および鍵の状態
以下のサブセクションは、鍵管理サービスを運用する際に使用される、鍵状態および基本の鍵機能を説明する。本項は、クライアントとサービスの間、またはサービスとサービスの間で実施される、それぞれの機能の要件について記載する。

本項において、サービスとは、ＫＭＳアーキテクチャに関わらず、単一のＫＭサーバまたは複数のＫＭサーバを指す。

鍵状態：図９は、鍵状態（推奨される状態値を持つ）に推奨されるモデルを図示する。鍵動作は、鍵を特定の状態に設定する。

前起動（状態０）：生成されたが暗号ユニットに返されていない鍵は、前起動状態に設定される。暗号ユニットによって生成された鍵は、絶対に前起動状態にあるとされることはない。

アクティブ（状態１）：ＫＭＳサービスが暗号ユニットからの鍵を生成または保存した後、これはアクティブ状態に設定される。

汚染（状態２）：鍵のセキュリティ要件を満たさなかった、暗号ユニットによって要求され、使用のために認証された鍵を明記する状態この鍵は暗号化および解読するプロセスの両者にとって依然として使用可能である。

非アクティブ（状態３）：解読するためのみに使用される鍵は、非アクティブ鍵状態に設定される。ある実施形態において、この機能は、ユーザインターフェースまたはタイムスタンプを介して、グループマネージャによって設定可能でなければならない。

改ざん（状態４）：潜在的に改ざんされたが、認証されたＣＵによって暗号解読のために利用可能でなければならない鍵は、改ざん状態に設定される。この状態は、鍵がデータを解読するためのみに使用されることを可能にする。この状態は、実行されるためには、暗号ユニットによって引き受けられなければならない。

無効化（状態５）：この状態は、具体的には、保存データに適用される。この状態は、すべての暗号ユニット上で破壊され、ＫＭＳサービスのみにおいて存在するが、いかなるＫＭクライアントによってもアクセス可能でない鍵を定義する。媒体が紛失したか盗まれた事例において、鍵は、アクティブから直接移行して、暗号ユニットによる使用を不可能にさせることができる。ＫＭクライアントは、鍵がなぜ無効化されたかに応じて、この鍵を非アクティブ鍵状態または無効化改ざん状態に移行して戻すことができる。

無効化改ざん（状態６）：現行のライフサイクルの間のどこかの段階で改ざんされた鍵は、改ざん状態または無効状態のどちらかから直接、この状態に移すことができる。これは、無効化された後に改ざんされた可能性があるという発見を含む。

ゼロ化鍵（状態７）：ゼロ化された状態とは、システムからの除去を待つ鍵を意味する。ゼロ化された鍵は、すべての他のメタデータおよびタイムスタンプを、依然として同じ場所に有する。この状態は、エクスポートされたか、バックアップされたか、別の場所に保存された可能性のある鍵が、システム内に再びインポートされないようにする。

ゼロ化改ざん鍵（状態８）：この状態は、改ざんされて次いで破壊されたか、破壊されて次いで改ざんされたことが発見された鍵を意味する。

消去鍵（状態９）：鍵記録（メタデータ）がもはや必要でない場合、ＳＯ ＧＵＩＤとＲｅｃｏｒｄ ＩＤを再使用するために開放するために、これはシステムによって消去されてもよい。ゼロ化された鍵と関連するメタデータのみが削除される。ログに記録された鍵についてのすべての情報は、依然として維持されなければならない。

状態移行鍵：図９のモデルは、以下のとおりに例示される鍵状態移行をも図示する。

移行１：ＫＭＳシステム内で鍵が生成されたが、暗号ユニットに返されない場合、前起動状態に置かれる。暗号ユニットによって生成され、ＫＭサーバに保存された鍵は、ただちにアクティブ状態に置かれる。

移行２：鍵は、前起動から鍵記録消去への直接の移動が可能でなければならない。鍵が一度もアクティブであったことがないが、もはや必要でない場合、その鍵に付随する情報に対する要件が、その鍵が作成され、消去されたというログ情報以外にはないため、全体の記録が消去され得る。

移行３：前起動された状態の鍵がＫＭクライアントによって要求される場合、これはアクティブ状態に移行する。鍵が単独でエクスポートされる場合、ＳＯコンテクストの一環として、またはＳＯドメインの一環として、アクティブに移行されなければならない。

移行４：潜在的に露出されたか、改ざんされたと考えられるアクティブ鍵は、改ざん状態に移行する。

移行５：鍵が期限切れでもはや使用の必要がない場合、無効状態に直接移行されてもよい。これは、付随する期限切れを有する対称鍵に適用される。

移行６：情報を解読するためのみに使用されることになる鍵は、非アクティブ鍵状態に移行される。解読のみの機能をサポートしないデバイスは、このデバイスに返ってくる鍵を有することはない。

移行７：鍵が最低限のセキュリティレベルセットを有し、セキュリティレベルが満たない鍵をデバイスが要求することを許可された場合、鍵は汚染に移行される。

移行８：汚染状態にあり、依然として解読するために使用されることのできる鍵は、改ざん状態に移行するのみである。汚染鍵は、その鍵に要求されるセキュリティレベルがそのライフサイクルのどこかの段階で満たされなかったため、改ざん状態にのみ移動することができる。

移行９：要求されるよりも低いセキュリティレベルを持つデバイスによって使用される、潜在的に露出されたか、露出されたが依然として使用が要求される、暗号解読のみのために非アクティブ化された鍵は、改ざん状態に移行する。

移行１０：いかなる使用にももはや必要とされない、非アクティブ化された鍵は、無効状態に送られる。

移行１１：改ざんされた鍵がもはや必要でない場合、無効改ざん状態に移動される。

移行１２：再度使用されるために要求された鍵は、解読のみを目的として非アクティブ化された鍵状態に復帰することができる。

移行１３：無効化改ざん状態にある鍵は、暗号解読のみの動作に改ざんとして使用されるために戻され得る。

移行１４：ライフサイクルのアクセス可能な段階において、または無効化された後に、露出されたか、露出された可能性のある無効化された鍵は、無効化改ざん状態に移行される。

移行１５：いったん鍵が無効化され、もはや存在する必要がない場合、鍵のメタデータが依然として存在する一方で、キーイング材料はゼロ化されてもよい。鍵は、ゼロ化された鍵状態に移行される。

移行１６：ゼロ化された、無効化され改ざんされた鍵は、ゼロ化改ざん鍵状態に移動される。

移行１７：ゼロ化された鍵状態における存在中に、露出されたことが確認された鍵は、ゼロ化改ざん鍵状態に移動され得る。

移行１８：特定の鍵に関するすべての情報がもはや必要でない場合、このメタデータおよびゼロ化された鍵は、システムから完全に消去することができる。これは、ＳＯ ＧＵＩＤとＲｅｃｏｒｄ＿ＩＤを再度使用するために自由にすることを確認することを含み得る。鍵に付随するロギング情報は、削除後であっても依然として維持されなければならない。

移行１９：いったん記録がもはや必要でなくなったら、もはや必要でない、ゼロ化改ざん鍵の鍵もまた、消去されることができる。

任意の鍵管理サービスがＫＭクライアントに提供される前に、鍵を移動するセキュアな機構が確立されるべきである。この機構に対する要件は、認証、セキュア通信、および一般的なメッセージフォーマットを含むべきである。ＫＭサーバでＫＭクライアントを認証することによって、デバイス（ＫＭクライアント）が自称するとおりのものであることを確認し、そのデバイスによって見られるべき鍵のみへのアクセスを可能にする。

セキュアな通信は、交渉された鍵を持つリンク暗号化を含み、ＫＭクライアントとＫＭサーバとの間で送信され得る鍵に対する保護を提供する。

共通のメッセージフォーマットは、複数の鍵管理システムとの相互運用およびＫＭクライアント等の間の鍵の交換を確保するため、ベンダーに、プログラミングの簡便さを提供する。

この機構の一環として含まれ得る他の機能は、標準規格の定義に基づくＫＭクライアントの交渉されたセキュリティレベル、名前またはアドレスによる二次的な鍵管理サービスの場所、ＫＭクライアントのための鍵ライフサイクルポリシーの定義、名前またはアドレスによるポリシー管理システム、名前またはアドレスによる監査設備の場所、および名前またはアドレスによる他のセキュリティ関連のサービス場所である。

いったんサービスの確立が完了すると、他の鍵管理サービスがＫＭクライアントに対して利用可能となり得る。

ＫＭクライアントから鍵管理への通信は、クライアント／サーバモデルに基づく。ほとんどの場合、ＫＭクライアント（クライアント）は鍵マネージャ（ＫＭサーバ等）への接続を開始し、これにサービスを提供する。このアプリケーションは、リンク暗号化または他の容認できる方法を使用して、通信がセキュアであることを前提にする。

図１０、図１１、および図１２において、文字は３つのうちの１つのシナリオにおいて、暗号化のために使用されることができる種々のデバイスを表す。

複数の鍵マネージャが利用可能である場合、正常な鍵動作（鍵の取得、鍵の保存、等）を実施するために、ＫＭクライアントは、主要な、そして潜在的に二次的な、ＫＭクライアントが通信することができるＫＭサーバを選択することができることが必要である。

ＫＭクライアントがどのようにＫＭサーバと通信するかに応じて、既存の標準規格に基づいて、メッセージがプロトコルおよびフォーマットを変更しなければならない場合がある。この実施例は、図１０、図１１、および図１２に見ることができ、そこではＫＭクライアントは暗号化機能を実施するメディアドライブである。

図１０は、暗号化が、アプリケーションの一部、暗号エージェント、ＯＳの一部、ハードウェアアクセラレータまたはメディアドライブベースの暗号化として、ホスト上に実装されることができる、内部の、またはホストに直接接続されたストレージを示す。メディアドライブ（Ｂ、ＣおよびＤ）がＣＵを含む場合、鍵はＫＭサーバによってホストＯＳまたはアプリケーション（Ａ）に送信されるべきである。ホストは次いで、鍵をメディアドライブＣＵが把握する形式に、通常はドライバを通じて転換する。

アプライアンスがＫＭクライアントとして使用される図１１および図１２について、この構成は製造業者に関わらず、プロキシまたは隠しデバイスのどちらかとして機能することができるため、アプライアンスは直列で示される。

図１１は、種々のＫＭクライアントがどのようにその媒体の関連付けされた鍵を取得するかを説明する。ほとんどのＫＭクライアントは、ＩＰ接続性を使用して、ＬＡＮ、ＭＡＮ、またはＷＡＮを通じてＫＭＳと直接通信する（１）。ＳＣＳＩプロトコルを使用してストレージネットワークに接続されたデバイスは、自らの鍵を取得するためにＴ１０ ＳＳＣ３信号の使用を要求することができる（２）。

ＳＣＳＩ通信の場合において、鍵がＣＵに直接わたされることができない場合、関連するアプリケーションまたは中間デバイスに存在する、ＫＭクライアントとして機能する翻訳機能が、ＫＭＳサーバとＣＵとの間の鍵メッセージを解釈し、翻訳する。

アプライアンスおよびネットワークスイッチが鍵のゲートウェイの役割を果たすことが可能である場合があるが、考慮される必要のある理由によって実用的でない場合もある。

ＳＣＳＩ信号を使用して、ドライブ自身の接続性に応じてＩＰ、ＳＣＳＩまたはファイバーチャネルによって鍵をＫＭクライアントにわたす要件が依然として存在する。ＫＭＳは、ＩＰベースの接続性のみを有する場合がある。したがって、ＦＤＥドライブ（ＣＵ）にディスクアレイを使用する場合、すべての要求がホスト（例えば、バックアップアプリケーション）かストレージコントローラ（ＫＭクライアントとして機能する）のどちらかにある翻訳機能を介して送信される必要がある。

図１２は、ホストとディスクの接続性のためのＳＡＮおよびＮＡＳソリューションを使用する主要なストレージを示す。ここでも、暗号化は、データが処理される場所と、データが保存される場所との間の接続の任意の場所において発生し得る。アイコンＢは、ＮＡＳゲートウェイを表す。図１０に示すホストは、ここでも、暗号化がファイラの内部で、またはドライブ自身で発生することができるように、直接取り付けられたストレージを持つＮＡＳファイラであってもよい。

前述のすべての事例において、通信はセキュアであるべきである。可能であれば、プロトコルの選択肢は最小とする。

ＫＭクライアントは、ＫＭＳに対して鍵生成要求（Ｋｅｙ Ｇｅｎｅｒａｔｉｏｎ Ｒｅｑｕｅｓｔ）を発行することができる。本明細書の別の箇所に記載のとおり、すべてのＫＭクライアントが外部鍵生成を必要とするわけではない。必要とするか、またはより強力なＲＮＧ供給源が外部で使用可能である事例において、そのような場合、要求はＫＭクライアントユニットからＫＭサーバへ発生するべきである。

ＫＭクライアントから鍵への要求メッセージは、ＫＭサーバか、またはＫＭクライアントに責任を負うサーバに送られる。デバイスが、ＩＰ、ＳＣＳＩまたはファイバーチャネルを介するＳＣＳＩを介してのみ接続する場合、次いで前述のゲートウェイ機能が必要とされる場合がある。

加えて、問題とされるＫＭサーバが要件を満たす自身のＲＮＧ機能を有しない場合には、外部ＲＮＧデバイスに要求を転送しなければならない場合がある。この理由により、事前に割り当てられたアクションが起きる前に、障害や何らかの要求に対するタイムアウトへの特別な配慮が与えられる必要がある。

生成された鍵は、使用されるまで保存されてはならない。デバイスが鍵を要求したことは、そのデバイスがただちにその鍵を使用することを意味しない。ＫＭサーバとの通信時に限られた能力を有するデバイスは、鍵を要求することができるべきであり、次いで、鍵がいったん使用される予定となるか、または使用中となったら、これを別個のトランザクションとして保存することができるべきである。

ＫＭクライアントは、鍵保存要求をＫＭＳに発行することができる。鍵の格納には、ＫＭクライアントからＫＭレルムへの単一のセッションのみを必要とするべきであり、ＫＭクライアントをＫＭレルム内の２つのＫＭサーバと通信させることを好むベンダーも存在するが、２つの異なる識別子を使用して同一の鍵が格納することを避けるため、機構が整えられるべきである。

この問題を避けるため、任意のレルム／ディレクトリ／鍵のセット／鍵ｉｄの中の一意のＩＤに基づくＧＵＩＤが、ＫＭサーバによって割り当てられるべきである。ＫＭクライアント（ＣＵ）は、鍵ＩＤを媒体に関連付ける。ＣＵは、媒体製造番号を使用することができ、または鍵ＩＤとして前に使用されていないランダムに生成された値を使用することができる。鍵が保存される時、ＫＭＳは鍵ＩＤをＧＵＩＤに変換し、そのＧＵＩＤをＣＵに返す。これは、ＣＵがそのＧＵＩＤを用いて異なるＫＭサーバから鍵を受け取ることができるようにするために行われる。

これはまた、場合によっては鍵のエスクロー時にＫＭレルムのメンバーでない可能性のある、第２のＫＭサーバ上への鍵のストレージを可能にする。

いったん鍵がＫＭＳに保存されると、その鍵にアクセスするための要求ＫＭクライアントによるすべての適切な信用証明および特権が存在する限り、鍵はどこにでもアクセス可能であるべきである。

ＫＭクライアントは、ＫＭＳに対して鍵取得要求（Ｇｅｔ Ｋｅｙ Ｒｅｑｕｅｓｔ）を発行することができる。ＫＭサーバからの鍵の取得は、主要ＫＭサーバからそのＫＭクライアントのための鍵を要求する単一のステップのプロセスである。鍵がＫＭサーバ上に存在しない場合、鍵のＧＵＩＤまたは任意の鍵を特定または突き止めることを助けることのできる他の検索可能なメタデータを使用してＫＭＳ内で検索が実施される。

ＫＭクライアントが、その鍵が作成された鍵ディレクトリから鍵を要求する際、鍵を取得するために要求されるすべては、鍵ＩＤである。テープ媒体の場合、これは媒体製造番号であり得る。

世界的に一意の値である場合、媒体ＩＤが鍵ＩＤとして使用されてもよい。ボリューム製造番号や外部媒体バーコードは一意の値でない可能性があるため、これらは鍵名として使用されるのがいちばんよい。媒体の鍵は、「鍵発見（Ｆｉｎｄ Ｋｅｙ）」動作を用いて名によって取り出されることができる。

ＫＭクライアントが提供することができるさらなる情報は、（完全なＧＵＩＤを有していない場合）適切な鍵がＫＭクライアントに戻されることをＫＭＳに確認させることができる。さらに、ＫＭクライアントおよび媒体は、暗号認証か、または鍵のデジタル署名のどちらかを使用して、鍵が確実に、適切に特定されることができるようにするべきである。これは、正しくない鍵での暗号解読を防ぐことを助けることになる。Ｐ１６１９等の標準規格は、これがディスクおよびテープベースのストレージの両者に該当することを保証する。ＫＭクライアントがどこに設置されるかに関わらず、同一のことが、暗号化を使用する任意のストレージ媒体にも当てはまるべきである。

ＫＭクライアントは、ＫＭＳに対して鍵発見要求（Ｆｉｎｄ Ｋｅｙ Ｒｅｑｕｅｓｔ）を発行することができる。ＫＭクライアントが非一意の鍵名で、または作成日などのとある他の非一意の基準で鍵を手に入れることが必要な場合、ＫＭクライアントはＫＭＳに鍵発見動作を発行する。鍵発見は、ゼロ以上の鍵を返す。ＫＭクライアントは、から返された鍵の中から鍵を選択する。ＫＭクライアントは、アプリケーションに複数の鍵から選択するように要求しなければならない場合がある。

鍵の発見は、任意の鍵ディレクトリの直下にある鍵を検索するＫＭＳに限定され得る。ディレクトリ階層のとある任意の鍵ディレクトリを起点とする鍵を再帰的に検索し得る。

ＫＭクライアントは、ＫＭＳに対して鍵除去要求（Ｒｅｍｏｖｅ Ｋｅｙ Ｒｅｑｕｅｓｔ）を発行することができる。前述のとおり、鍵除去は実際にはいくつかの機能のうちの１つである。

ほとんどの場合、ＫＭクライアントは鍵を破壊することを許可されない。これは、ＫＭレルム内の鍵を無効化する能力のみを有する。これは、クライアント側で破壊される一方で、ＫＭレルム内で無効化されるのみである場合がある鍵へのアクセスを制限する。また、１つ以上のＫＭＳ鍵管理者が、その鍵にどのような措置をとるかを決定するまでは、鍵破壊機能が他のクライアントにわたされることを許可しないこと望ましい場合がある。１つの提案は、ＫＭレルム内の鍵を無効化し、すべてのクライアントＣＵ上でこれを破壊し、残るＫＭレルムの内部の鍵の種類に基づいて、鍵が無効化される、取り消される、または破壊されるべきかどうかＫＭＳ鍵管理者に決定させる生成アラートまたはイベントを生成することである。

ＫＭクライアントは、ＫＭＳに対して鍵取り消し要求（Ｒｅｖｏｋｅ Ｋｅｙ Ｒｅｑｕｅｓｔ）を発行することができる。標準規格ＰＫＩシステムの利用ができず、公開キーイングの使用がある場合、データオブジェクトを暗号化するために、別の鍵を暗号化するために、またはセキュア認証のために使用される、署名された公開／秘密鍵の対を、ＫＭＳ鍵管理者が取り消すことが可能であるべきである。

これは、認証の事例においてもっとも普及したものとなり、ＫＭＳまたはクライアントが鍵の取り消しを要求する一方で、それがその鍵の署名権限である場合、そうすることのみが可能であるべきである。ＫＭクライアントが削除鍵機能を供給することに類似したほとんどの場合、鍵の取り消しのための既存の標準規格を使用して、公開秘密鍵の対が取り消されるべきであるかどうかの決定は、適切な署名権限管理者または証明機関に任されるべきである。

ＫＭクライアントからＫＭサーバへ、ＰＫＩシステムへの取り消し要求機構が存在するべきである。

ＫＭクライアントは、ＫＭＳに対して鍵破壊要求（Ｄｅｓｔｒｏｙ Ｋｅｙ Ｒｅｑｕｅｓｔ）を発行することができる。どのような機能が実施されるかに関わらず、ＫＭクライアントおよびＣＵは、破壊されるすべての複製鍵をゼロ化するべきである。これは、ＫＭレルム内で無効化された、取り消された、または破壊された鍵は、標準規格のメッセージングおよび認知されたものを使用して、ＫＭクライアントからまず除去されるべきであるということを意味する。

これは、他の通信要件と異なり、サービスがＫＭクライアントとの通信を開始する場合の事例である場合がある。しかしながら、ＫＭサーバが、ＫＭサーバ同士以外での通信を開始することを許可しないようにする本格的に検討するべきである。

複数のユーザがＫＭレルム内の鍵を破壊することを要求される事例において、鍵がＫＭＳ内で無効化され、キャッシュされるか保存される場合があるＣＵで破壊されることができない限り、エッジデバイスのためのものも同一のポリシーであるべきである。

ＫＭサーバは、ＫＭサーバに対して鍵複製要求（Ｒｅｐｌｉｃａｔｅ Ｋｅｙ Ｒｅｑｕｅｓｔ）を発行することができる。任意のＫＭＳの典型的な特徴は、冗長性と高可用性を、特に暗号化された保存データ対して提供する能力である。

鍵は、ＫＭクライアントによって、またはその鍵が元々保存されたＫＭサーバによって、２つ以上の異なるＫＭサーバ内に置かれることができる。これらの選択肢は、鍵管理サービスを使用する組織の特定の要件を満たす限り、同期か、または非同期の性質を有することができる。

ＫＭクライアントからのプロセスをオフロードし、それらが主要な機能に集中することを可能にするため、鍵を受け取ったＫＭサーバは、鍵の複製に責任を負う。また、これは２つのＫＭサーバ内で同一鍵が異なるＧＵＩＤを持つことを避けることを助けることになる。

ＫＭサーバは、ＫＭサーバに対して鍵検索要求（Ｌｏｏｋｕｐ Ｋｅｙ Ｒｅｑｕｅｓｔ）を発行することができる。鍵検索動作は、媒体が可撤性であり、データ暗号鍵が保存されるＫＭサーバへのアクセスを有していない場所でアクセスされることが必要な場合に使用される。これが発生する潜在性は、テープまたは他の可撤性媒体等の媒体を使用した場合、著しく増加する。

この事例が発生した場合、ＫＭＳサーバ間検索が、適切な鍵を発見するために使用される。例示的実施形態は、サーバ、鍵ディレクトリ、および鍵の階層が存在する際、保証された一意のＩＤを作成する方法が存在するように、それぞれのＫＭサーバに世界的に一意の識別子を有する。

ＫＭサーバおよびＫＭクライアントが時間の経過とともに廃棄される場合があるため、ＧＵＩＤは、鍵がどこで作成されたかを識別する際において、物理アドレスを使用してこれを行うべきでない。具体的には、鍵検索を迅速に、および鍵が物理的にどこに位置するかといういかなる予見も必要とすることなく行うために使用されることができるプロトコルが存在する必要がある。

最後に、検索に関して、ＫＭクライアントが要求される鍵を使用するする権限があることを確認することは、要求側ＫＭＳと任意の応答側ＫＭＳの責任であるべきである。この理由により、鍵にアクセスするポリシーは、ＫＭレルム内のすべてのＫＭサーバ間において全体的に複製される必要がある。代替的に、ＫＭレルム内のすべてのポリシーを追跡する集中型鍵ポリシーサーバは、ポリシー情報が維持される１つ以上の中央の位置をはっきりと指定する。

ＫＭサーバは、ＫＭサーバに対して鍵無効化要求（Ｄｉｓａｂｌｅ Ｋｅｙ Ｒｅｑｕｅｓｔ）を発行することができる。この鍵無効化機能は、ＫＭサーバが互いに使用するために確保されたものであるべきである。鍵が無効化される際にはいつでも、鍵は任意のＫＭクライアントまたは保存され、キャッシュされ、または問題となっている鍵をアクティブに使用していたＣＵ内で破壊されるべきである。この鍵は、次いで、この鍵が複製されたすべてのＫＭサーバ内で無効化されるべきである。

ＫＭクライアントによって破壊コマンドが発行される際、ＫＭレルム内においてのみこれを無効化することは、自由意志によるものであるべきである。

無効な鍵へのアクセスを一時的に許可する特定の理由がある場合がある。適切な機関または複数の機関が、鍵が復元されるか破壊されるまでこれを使用毎の原則によって許可する場合においてのみ行われるべきである。鍵を戻すことに関する無効化鍵のための特定の制御も考慮されるべきである。

ＫＭサーバは、ＫＭサーバに対して鍵取り消し要求（Ｒｅｖｏｋｅ Ｋｅｙ Ｒｅｑｕｅｓｔ）を発行することができる。鍵取り消し一覧は通常、証明機関によって制御されるが、しかしながら、ＣＡが存在せず、ＫＭサーバが自らの署名権限としての役割を果たしている場合において、証明および公開秘密鍵の対をＫＭクライアントから取り消すための機構が存在するべきである。

ＫＭクライアントが２つ以上の証明を有する場合、ＫＭＳはＫＭレルム内のすべての証明を取り消すための単一の取り消しを随意に許可するべきである。

ＫＭサーバは、ＫＭサーバに鍵破壊要求（Ｄｅｓｔｒｏｙ Ｋｅｙ Ｒｅｑｕｅｃｔ）を発行することができる。その鍵が本当に破壊されたことを確認するため、ＫＭレルム内での鍵の破壊は、鍵を保存またはアクセスした可能性のあるすべてのＫＭサーバに伝播することができるべきである。ＫＭサーバはまた、保存されたデータの潜在的な暴露を防ぐために、必要に応じて追跡されることができるように、鍵で実施された任意のエクスポートを追跡するべきである。

これは、媒体が紛失したか盗まれた際、および鍵破壊の監査が要求される際の事例において、非常に重要である。この理由により、データを解読するためではなく、報告の目的において、記録自体が依然としてアクセス可能であることができるように、全体の記録を破壊せず、鍵をゼロ化するのみとすることが望ましい場合がある。

ゼロの値を有する鍵が通常有効であるとはいえ、これはほとんど許可されない。この理由において、ＨＭＡＣや他のとあるセキュアハッシュ機能等の暗号認証を使用して、鍵を使用する前にテストする機構が存在するべきである。

ＡＫＭサーバは、ＫＭサーバに鍵復元要求（Ｒｅｓｔｏｒｅ Ｋｅｙ Ｒｅｑｕｅｓｔ）を発行することができる。無効化された鍵の復元は、ＫＭレルム内でのみ発生するべきである。復元された鍵が、すでにエッジで破壊されているべきであるため、この媒体が挿入された場合、復元された鍵は、これにアクセスするためのいかなる特別な許可が要求されることなく、認証されたＫＭクライアントによって即座に利用可能となる。

また、モバイルデバイスと通信するようにＫＭＳを構成することも可能である。データを暗号化するために、厳密に対称な鍵ではなく、公開秘密キーイングを使用することが最良である１つの事例は、モバイル媒体においてである。例えば、秘密鍵データを単一システム上に保存し得る。

制御および接続性はときどきローカル以外では利用可能でない場合があるため、モバイルデバイスにおいてどのように、何が暗号化されるかについて、追加的な考えが与えられる必要がある。

鍵管理サービス
ＫＭレルムによって提供される実際のサービスは、鍵の管理に直接関連するいくつかのサービスを含む。これらは、鍵管理業務を行う際に必要な基本的なサービスである。機能は、典型的には実際の鍵管理、クライアント相互アクション、およびサービス間の相互アクションを含む（がこれに限定されない）。

鍵の管理は、同時に使用されると、保存される際に、データがそのライフサイクルを通して保護されることをセキュリティ担当者が確実にすることができるようにする制御のシステムを形成する、本明細書の別の箇所に記載の機能から成る。鍵の管理の基本は、プロセスにおいて自動または手作業である、上記の鍵管理業務を含み、また鍵が有用な寿命を通しておよびそれ以上に、要求に応じて追跡されることを可能にする、ライフサイクル管理機能を含む。

ＫＭＳ機能：前述のとおり、いくつかのＫＭＳ機能があるが、しかしながら本技術は本明細書に記載の機能に限定されるものではない。他の機能が、報告およびアクセス制御を含むさらなる管理機能性を提供することができる場合がある。例えば、より進化した機能は、鍵を作成から除去まで制御し、鍵の変更、無効化、取り消しまたは破壊が自動的に可能となるようにする基本保持ポリシーを設定することを可能にするライフサイクル管理を含む。

ライフサイクル管理：ライフサイクル管理は、作成、配布、保存、共有、回復および除去を含む鍵の一生のすべての段階を網羅する。これらの段階はそれぞれ、ＫＭＳによって自動化されてもされなくてもよい、これらに関連付けられた特定のアクションを有する。他のものは、手動のまたはスクリプトされた一連のアクションを生成するために、アラートおよびイベント機構を含む場合がある。

図１３の略図は、暗号鍵の６段階のライフサイクルを説明する。種々の鍵管理スキームはさらに含む場合もあるが、それらのほとんどは通常、この６段階のうちの１つに該当する。生成段階は、ＫＭクライアントによって使用されるために、鍵が手作業で、または自動で作成された際に生じる。配布段階は、適切なおよび認証された、保存されたデータを解読するために鍵を必要とするＫＭクライアントまたはＫＭサーバに、鍵をセキュアな様式で提供することを含む。アーカイブ段階は、必要に応じた取り出しを可能にする、鍵のＫＭサーバ内のストレージを含む。共有段階は、この鍵が作成された正常なＫＭレルム以外の事業体と鍵が共有されることを許可された時である。回復段階は、ＫＭＳマネージャの１つ以上の部分において、深刻な災害または悪意のあるアクションの事例において生じ、鍵のリカバリはＫＭレルムの外部でのバックアップのために、典型的にはセキュアな機構を使用する。除去段階は、前述のとおり、無効化、取り消しおよび破壊を含む、複数の種類の鍵除去から成る。

鍵管理ライフサイクルに関する別の、より詳細なモデルは、ＮＩＳＴ ＳＰ８００−５７ Ｍａｒｃｈ ２００７ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ ｆｏｒ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ− Ｐａｒｔ １ ： Ｇｅｎｅｒａｌ（Ｒｅｖｉｓｅｄ）Ｓｅｃｔｉｏｎｓ ７および８に記載され、参照することによって全体として本明細書に組み込まれる。これらの本願明細書に記載のもの以外のモデルは確かに存在し、特に保存データ鍵管理に適用される完全なモデルを構築するために考慮されることができる。本技術は、本明細書に記載の鍵管理ライフサイクルの実施形態に限定されない。

保持ポリシー：鍵保持ポリシーは、ＫＭＳサービスの重要な要素である別の基本的な一連のポリシーである。保持とは、鍵の変更または除去がされなければならなくなるまでの、鍵が使用されることができる時間である。この機能は、レルム内に保存される時はいつでもポリシーが鍵に適用されるように、最低限ＫＭレルムレベルで行われるべきである。

保持が個々の鍵に設定されることができる場合、ＫＭＳは、例外を報告する機構を提供するべきである。例えば、鍵の除去時間を制御するポリシーがあり、鍵の保持時間がこの除去時間を越えて修正される場合、次いで、例外が告げられるべきである。

ここで鍵保持ポリシーとともに、１年間の鍵の変更ポリシーの制御下にあるオブジェクトの事例を考察する。ＫＭ Ａｄｍｉｎが鍵の変更ポリシー時間を越えて保持ポリシーを延長した場合、ＫＭＳはポリシー例外イベントをログ記録するべきである。通知された場合、ＫＭ Ａｄｍｉｎは、ポリシー不一致を解決する必要がある。

Ｗｒｉｔｅ Ｍａｎｙ／Ｒｅａｄ Ｍａｎｙディスク等の媒体上に保存される、データを保護するために使用される鍵には、暗号化アルゴリズムのバースデーバウンドを超過する潜在性があるため（使用されるモードによって異なる）、特別な配慮をするべきである。

鍵共有：鍵の共有は新しい概念ではないが、組織の種々の部署の間だけでなく、極秘情報へのアクセスを必要とするパートナーとの間でも機能するモデルを構築するために、モデルは鍵にアクセスするための共通フォーマット、ポリシーおよび通信機構を使用するべきである。これらの方法は、ネットワーク、Ｅメールを経由して、スマートカードまたは他のそのような機構を経由して鍵を共有するセキュアな方法を含むべきである。

共有された鍵は、特定のアプリケーションのための共通フォーマットにラップされるべきであり、ＫＭＳは、アンラップおよび再ラップする能力を有するべきである。これは、データ暗号鍵を暗号化するために、パートナーからの公開鍵を使用して行なうことができる可能性がある。

ＫＭクライアント相互アクション：ＫＭクライアントからＫＭサーバへの相互アクションは、ＫＭＳによる影響を受けずにその機能を実施するようにＫＭクライアントに要求されるアクションに基づく。この目的を達成するために、ＫＭサーバとの通信を確立し、維持する場合、ＫＭクライアントが扱うべきである、オーバーヘッドの制限のための特別な熟考を行うべきである。

ＫＭクライアントによるＫＭサーバの発見：ＫＭクライアントによるＫＭサーバの発見は、ＫＭＳのＩＰアドレスの手動入力を最低限サポートするべきである。プロトコルの定義には、ＫＭクライアントによって使用されているＫＭサーバが故障した場合、ＫＭクライアントが特定のフェイルオーバシステムまたは遠隔ＫＭサーバ等の使用を許可された別のＫＭＳを検索し、発見することができるように、ＫＭＳが自動的に発見されることを可能にする検討をするべきである。

ＫＭサーバがフェイルオーバまたは遠隔ＫＭサーバとして使用される場合、次いで、ＫＭクライアントは、これに対して鍵を複製するべきである。したがって、ＫＭクライアントの鍵の要求が受信された場合、フェイルオーバまたは遠隔ＫＭサーバは、この要求に直接応答することができる。最悪の事例として、ＫＭＳは、それが自動的に発見されることができない場合、適切なＫＭＳを見つけるための方法を有するべきである。

相互アクションおよびセキュリティのレベル：ＫＭクライアントとＫＭサーバの間の相互アクションのレベルは、基本暗号デバイスが最小限の努力で相互運用可能であることができるように定義されるべきである。これは、通信プロトコル、メッセージフォーマット、および鍵情報を含む。

ＫＭＳ：サーバ間相互アクション：ＫＭサーバ間の相互アクション（ＫＭＳＳ）は、追加的な信号伝達を利用する。ＫＭＳＳは、ＫＭレルム内のより多くの情報を交換する。この情報には、鍵の複製、ポリシーの複製、および既存のＫＭＳ階層またはピア通信の確立を含み得る。

また、この情報は、それぞれのＫＭサーバによって提供される、ＦＩＰＳ １４０−２暗号境界、一般基準から得た保証レベル、またはセキュリティの業界標準規格のどちらとして定義されるかについての機能性のレベルを含むべきである。

これは、鍵にアクセスするためのセキュリティ要件を満たさないシステムによってキーイング材料が潜在的に暴露されることのないように、鍵の制御を助けることになる。これは、汚染鍵をもたらすことがある。

鍵およびポリシーの複製：鍵の複製は、複数のＫＭサーバを構成する際に、決定的に重要である。複製ポリシーは、鍵が保存されるべき最小の数のＫＭサーバを含む、潜在的な複製するＫＭサーバの識別を含む。また、ポリシーは、どのサーバが複製を行うかを定義するべきである。例えば、鍵が元々保存されていたＫＭサーバのみか、または鍵が到着するそれぞれのＫＭサーバかである。

鍵のためのポリシーはまた、特定の保持規則が存在する鍵のディレクトリまたはサブディレクトリと関連するため、明確に複製される必要がある。例えば、どの機能が、鍵に実行されることができか、どの鍵ディレクトリのセキュリティ要件がストレージ用であるか、または他のそのようなポリシーである。

このプロトコルは、定義において具体的であるべきであり、これらがほかで定義される場合、可能であれば、新しいプロトコルまたはメッセージフォーマットの開発の必要性を軽減するために、限定された数の既存の標準規格を使用するべきである。

ＫＭＳ階層またはピアの発見：最後に、環境と、どうすれば組織の需要を最適に満たすことができるかに応じて、ピアベースのＫＭＳまたは階層型ベースのＫＭＳを使用することが、エンドユーザの利益となる場合がある。

ピアベースのシステムは、それぞれのＫＭサーバに鍵配布およびポリシーの施行の責任を負わせる。

階層型ＫＭＳは通常、エッジＫＭサーバを持つ中央コンソールを有し、その監督下にあり、またこの集中型ＫＭＳオーソリティからポリシーおよび他の鍵管理要件を受け取る。

通信機構を開発する際、階層型システムに変換するほうが容易であるため、ピアベースへの優先をもって両者のトポロジーが考慮に入れられるべきである。

鍵管理サービスのための他の要件
ＫＭＳのための他の要件には、ほとんどの動作において重要であるが、監視、アラート、および監査を行う以外に日常の鍵管理業務影響を与えない、追加的なサービスを含むがこれに限定されない。

ポリシー管理サービス：ポリシー管理は、鍵のための保持ポリシーを設定することに留まらない。真のポリシー管理は、データが最初に保存される際、正しい種類の暗号化および他のセキュリティメトリクスによって適切にセキュアとされるように、鍵ライフサイクル要件、鍵保持、鍵セキュリティ要件、データ分類、および他のセキュリティベースのパラメータを考慮に入れる。

ポリシー管理は、当業者によって概して理解されており、本明細書の別の箇所に記載されているが、以下にＫＭＳを設計する際の検討事項のうちのいくつかの一覧を示す。

１．ＫＭクライアントによるアクセス制御
ポリシー構成は、特定のＫＭサーバへのＫＭクライアントのアクセスを制限する能力、ならびに取り出しのために特定の鍵にアクセスする能力を限定することを含むべきである。アクセス制御は、ＫＭレルム、ＫＭサーバ、および鍵ディレクトリレベル、および潜在的に個々の鍵レベルにおいて、全体的な既定値とともに構成されるべきである。

自らの鍵を特定の鍵ディレクトリに保存するＫＭクライアントによって鍵が共有される場合、および要求される鍵が異なる鍵ディレクトリからのものである場合、個々の鍵のサポートが必要とされる。

２．保存データのセキュリティ要件
保存されるデータがオブジェクトによって異なる要件を有する場合、保存されるデータの特定の要件に基づいて、同一のＫＭクライアントに対して異なる種類や長所を持つ鍵を提供することが必要となる場合がある。

セキュリティベースのポリシーを設定する際に配慮される必要がある可能性のあるいくつかのパラメータには、データ分類、使用中のストレージデバイス、データへのユーザアクセス、データの移動性、および複製要件を含む。例示的実施形態（正しく構成されたストレージ環境）において、データ分類は一覧にある他のパラメータを考慮に入れる。

３．鍵管理ユーザ権利
ユーザＩＤまたはユーザのクラスに基づいて、セキュリティ権利は、実装されることができるそれぞれの機能が、個々のＫＭクライアントに譲渡されることができる程度に設定することができる。しかしながら、いくらかのレベルの相互運用が確実に存在することができるようにするために、前述のような機能の共通のセットおよびユーザのクラスが定義されなければならない。

鍵への権利は、特定のユーザに、ディレクトリ階層内の特定の鍵へのアクセスのみが与えられることができるように、ディレクトリ構造に基づいて定義されるべきである。これらの鍵の制御の粒度は、単一の鍵ほど高くてもよいが、しかし、ここでも、相互運用を目的として、少なくともルートディレクトリの直下のディレクトリレベルに定義するという検討が与えられるべきである。

このモデルにおいて、ルートディレクトリは、１つ以上の位置のＣＵまたはＣＵに基づいて分類される、複数の鍵ディレクトリから成る。これらのＣＵは、鍵の共通のセットを共有し、鍵の共有のための追加的なポリシーの制定の要件なしに、鍵がこれらのＣＵ間で共有されることを可能にする。これは、個々の鍵または鍵のプールにＫＭＰを設定することにより、ディレクトリ内部の鍵へのアクセスを制限する能力を奪うものではない。

鍵管理のユーザは、このユーザが責任を負うディレクトリが別のＫＭサーバに複製される場合、ＫＭサーバに拡張されるべきである。一般的な認証機構が使用される事例において、これは問題でない場合がある。

４．鍵共有機構
鍵共有は、特定のデータへのアクセスを必要とする複数の部署、または潜在的にパートナーの間でデータが共有される際に重要となる。例えば、暗号化されたファイルまたは暗号化された媒体（例えば、暗号化されたテープ）がＫＭレルムの外に送信されなければならない場合、鍵は共有されることが必要になる場合がある。つまり、暗号化されたファイルまたは媒体を読むために必要な鍵が外部事業体に与えられる。

他の部署またはパートナーが、ファイル内の、またはテープ上のデータへのアクセスのための特定の鍵へのアクセスを必要とすることある。他のグループがディレクトリ構造内のすべての鍵へのアクセスを必要としないため、多くの手作業または介入を必要とすることなく、鍵が個別に共有されることができるように、ポリシー機構が存在するべきである。

鍵ラッピング：鍵がビジネスパートナーと共有される特定の種類のテープ媒体を暗号化するために使用される場合、パートナーのサイトにあるデバイスが、使用されているラッピング機構を理解し、使用前に鍵を認証することができるように、共通鍵ラッピング機構のための検討材料もまた整備される必要がある。

鍵ラッピングに関する１つの留意点は、同様のアプリケーションまたは媒体が共通の一連の鍵ラッピング技術を使用すること、またはＫＭＳサーバが、同一のデータ、したがって同一の鍵へのアクセスを必要とする２つの異種システムの間で鍵を理解し、翻訳することができることを確実にすることである。

暗号化の実践および特定の種類のデータおよび／または媒体に対する使用を定義する標準規格は、その鍵のためのラッピング方法を推奨するべきであり、または、特定のラッピング機構がシステム全体の仕様の一部として定義されるべきである。

鍵共有ポリシー：いったん鍵が共有されると、許可されたシェアの期間、鍵が使用されることができる回数、またはそれが暗号化されたファイルにエクスポートされる場合、誰がアクセスすることができるかについて、配慮する必要がある。

この理由によって、個々の鍵に関連するポリシーは、エクスポートされる暗号化される鍵ファイルの一部として伝送されることが可能であるべきである。

鍵のエクスポート：鍵ファイルが公開である際、Ｅメール、遠隔システムログ、または監査目的のために発信元に返送されることができる他の通知機構を介して通知機構が存在するという点にまで、ポリシーが施行されるべきである。

トークンまたは他の可撤性媒体を介して手作業で転送される、ネットワーク接続されていないデバイスにおいて使用される鍵に、どのレベルの制御が制御されるかについての追加的な配慮をする必要がある。

５．鍵の変更のデータ
ときどき、暗号化されたデータの鍵の変更の必要がある。この機能を自動化する選択肢が考慮されるべきである。１つの選択肢としては、ポリシーまたは自動化機能を、データチャーン（同一の鍵を使用して、ある時間内に書き込まれるデータの量）に基づいて予め定義することである。ほとんどの場合、これは暗号化アルゴリズムのバースデーバウンドおよび動作のモードを超過する可能性のある媒体のためのものである。

標準規格は、鍵の利用に基づいて、または時間に基づいて、施行された鍵の変更を考慮するべきである。鍵の利用は、使用されるアルゴリズムに基づいて鍵の変更に対する適切な推奨を行うために、時間とともに判定されるべきである。

媒体のほとんどの種類にとっては関連がないかもしれないが、ディスクアプリケーションで使用されるより大型のＬＵＮは、深慮を必要とする場合がある。一例は、ＡＥＳ２５６の使用である。ＡＥＳ２５６は、バースデーバウンドが超過する前に（ＡＥＳアルゴリズムと使用されるモードに応じて）、２^６４を少し下回るバイト（１８，４４６，７４４，０７３，７０９，５５１，６１６バイト）を書き込むことができる。ほとんどのＬＵＮがこのサイズに近いサイズとはならないが、利用度の高いディスクにおいてはほんの２年で書き込まれるデータの量が潜在的にこれを超過する可能性がある。

保存データの鍵の変更をする場合はいつでも、バージョンを追跡するために使用される鍵セットの使用に配慮するべきである。これは、データが暗号化される間に複製され、それが複製された部門のリアルタイムでの鍵の変更が行われない場合に、どのような潜在的な問題も軽減する。

媒体の種類を問わず、鍵を変更する別の理由は、キーイング材料にアクセスを有する人員が組織を去る場合である。その人員が直接のアクセスを有していた鍵のレベルが、何の鍵が変更されるべきかを決定する。

手作業による暗号化されたデータ鍵の変更を自動化するか、計画することによって、鍵の変更動作に通常関連するほとんどの業務負担を軽減することが可能となるべきである。

６．鍵複製のポリシー
複数のＫＭサーバ間で鍵を複製するためのポリシーは、適切な権限保持者が鍵の配布を制御することができるように、任意の標準規格に含まれるべきである。

鍵が複製される際、複数のＫＭサーバ上に存在し得る共通ディレクトリ構造に複製されなければならない。ディレクトリ構造は、一般的な名に基づいてローカルの機械の複製物が存在しないようにするため、パスに発信ＫＭサーバを含まなければならない。

また、これは、複数のＫＭサーバに複製されたディレクトリに権利を有するユーザが潜在的に統合され、共有もされることを可能にする。これは、当然ながら、ユーザが自称する人物と一致することを確認するために、一般的な認証機構が使用されることができる場合に限る。

監視サービス：監視機能は、ＫＭレルムが通常どおりに動作していることを確認する目的を果たす。ＫＭＳは任意の組織の内部にある保存データに影響を与える能力を有するため、セキュリティ関連の動作の外側の従来の動作によって種々の機能が監視される必要がある。

考慮されるべきである機能は、基本てきな動作に関連する機能およびセキュリティ関連の機能である。

１．基本的な動作に関連する監視機能
基本的な監視機能は、性能を低下させたり、ＫＭサーバをすべて一緒に無効化したりする可能性のある、システム状態、アップタイム、環境のおよび他の動作条件を含む。この理由により、ＫＭレルムへの基本アクセスを有するために、ＳＮＭＰ管理ツール、ＳＭＩ−Ｓ／ＩＬＭツール、システムロギングおよび他のイベント相関システム等の従来の管理ツールを可能にする機能が含まれるべきである。

２．基本的なセキュリティ関連の監視機能
セキュリティ関連の監視の需要は、サーバ、ＫＭクライアント、および通信するネットワークを含む、ＫＭレルム内の２つのエンドポイントの間の通信に関連するものとして容易に定義される。

これは、すべての鍵保管、鍵要求、鍵使用、鍵エクスポート／インポート動作、鍵複製、鍵除去およびＫＭサーバに影響を与える他のアクションが監視され、ログに記録され、適用される場合にはアラートが出されなければならないということを意味する。

セキュア監視機能のための任意の検討事項に含まれるべきであるセキュアロギング機能のための新しい標準規格が、現在開発中である。

報告サービス：報告サービスは、潜在的な、または新しい課題の通知を、積極的に、ほぼリアルタイムで可能にするサービスである。状態の重篤度に応じて定期的な間隔で繰り返す特定のイベントの必要性がある場合がある。

ＫＭＳアラートのベースレベルを定義する際、監視および報告の標準規格によって確立される既存の重篤性レベルに基づいて、重篤性が考慮に入れられるべきである。以下は、報告サービスの要素である。

１．標準規格アラート機構
イベントおよびアラート通知のための現行の標準規格は、ＳＮＭＰトラップ、アクティブシステムログ構文解析、Ｅメールイベント通知、およびコンソールアラートを含む。ＫＭサーバは、エンドユーザに課題が存在することをアクティブにアラートするための、少なくとも１つの機構を提供するべきである。

ＫＭサーバのエンドユーザ組織に、既存の動作に統合される能力を提供するためにこれらに含まれるべきである、他の機構が存在してもよい。これはまた、イベントおよび相関管理ツールを使用して自動化機能が有効となり得るように、一連の条件に基づいてＫＭサーバのエンドユーザ組織が適切な応答を設定することを可能にするべきである。

２．イベント管理および相関
自動化およびアラート機能を提供するために非常に有用なツールは、セキュリティ、ネットワーク、およびシステム管理のために使用されるイベント駆動型の相関エンジンである。これらのツールは、課題や潜在的なセキュリティ脅威を、発生前にまたは発生時に見抜くことを容易にする。

最終的な鍵管理の仕様に基づいて、適切なインターフェース機構をこれらのツールに与えて、組織が多くの運営上のオーバーヘッドを追加することなく、容易にＫＭＳサービスを採用することができることを確実にするために、真の配慮をするべきである。

安全監査サービス：監査ログは、順次的な順序で、鍵に対して行われたアクションに対するあらゆるイベントを含むべきである。時差や１つのイベントに対するアクションの潜在的な課題を避けるため、すべてのアラート、イベント、およびセキュリティ関連のロギングは、イベントが時差なしで順次的に報告されるように、および時間の修正の潜在性を防ぐために、世界的にすべてのＫＭＳサービス向けに使用されている番号付け機構を有するべきである。

今日の組織の中において、暗号化のための鍵が文字通り王国への鍵となるため、ＫＭＳ標準規格の開発において、機能を監査するための最低限の要件を含むためのあらゆる努力が払われるべきである。これは、潜在性および規制への不服従および個人的に識別可能な情報（ＰＩＩデータ）の喪失に関連する実際の義務のためである。

安全監査ログの提供の背後にある考え方は、組織が特定のデータのための鍵がいつどこで使用されたか、アクセスされたか、および最終的に破壊されたかを示すことができるなら、暗号化される間に失われたデータの保護に関する義務が制御され得るということである。

安全監査ログの使用のための別の検討事項は、鍵が共有される場合、ログイベントが送信され、鍵がインポートされた際に、および鍵の使用に先立って承認されることを必要とすることをエクスポート側に許可することである。これは、エンドユーザシステムのセキュリティの制約のため、可能でない場合があるが、どうすれば達成することができるかについて考慮するべきである。これは、異なる組織の間で共有されるデータに関連する義務の限定を支援する。
以下は、安全監査ログの望ましい属性である。

セキュア監査ログエントリとは、１つの鍵に関連するすべてのアクションおよびイベントを指す。これらは、利用可能なできるだけ多くの情報を含むべきである。この情報は、（１）そのアクションを実施した事業体の種類（例えば、ＫＭクライアント、ＫＭサーバ）、（２）そのアクションが取られた理由（例えば、読み出し／書き込み動作のためにロードされた暗号化されたテープ、遠隔システムに複製されたファイル等のＫＭクライアントの入力またはメッセージの可能性）、（３）そのアクションがどこから取られたか（例えば、アクション時のＫＭクライアントのＩＰアドレス、ＣＵ識別子、ＫＭクライアント、ＫＭサーバ）、（４）そのアクションがいつ実施されたか（例えば、セキュアタイムスタンプ、イベント番号）を最低限含むべきである。

セキュア監査ログイベントは、複数の人員による制御を可能にするメトリックに基づいて、外部の使用のための除去またはエクスポートが制御されるように管理されるべきであり、特定のアラートが生成されるべきである。

安全監査ログへのいかなるエントリも、記録の全体にわたって暗号的に認証されるべきである。記録がエクスポートされる場合、これらはファイルを受け取る予定の単数または複数の人員の公開秘密鍵の対を使用して暗号化され、署名され、また、個別に、およびエクスポートされる一覧の全体にわたって再び暗号的に認証されるべきである。

安全監査ログのバックアップおよびアーカイブは、典型的には任意のアクティブログエントリの除去の前に実施されなければならない。性能またはストレージの目的により、エントリがクリアされる場合、異なる場所に２つ以上のアーカイブを必要とすることに考慮するべきである。

追加的な鍵管理サービス検討材料
ＫＭＳ標準規格のための最後の一連の検討事項は、標準規格を定義するために、必要とされる場合もされない場合もある。これらは、任意の拡張子を標準規格またはＫＭＳのために将来開発される他の標準規格に確実に適合させるように配慮されるべきである、前述の使用の事例のために立てられた追加的な仮定である。
鍵属性：以下の表に示す鍵属性の一覧は、ＫＭクライアントに既知でない可能性のある属性を含む。いくつかの属性は、監査、鍵ライフサイクル管理、および値がＫＭレルムの外に示されることを必要としない他の機能等の管理機能を可能にするためにとりわけ含まれる。

それぞれのデバイスは、最小の数の属性をサポートするべきであり、それらの属性は、相互運用のため、および任意の標準規格ＫＭＳと連動するための要件の最小セットとして決定されるべきである。最低限、人間の可読性のための鍵名称（Ｋｅｙ Ｎａｍｅ）、鍵のディレクトリ内で一意の識別子であることができる鍵ＩＤの属性が考慮されるべきである。

グローバルアーキテクチャに基づいて、それぞれの鍵は、ＫＭクライアントによって割り当てられた鍵ＩＤと、ＫＭサーバによって割り当てられた、保証のある、世界的に一意の識別子の両者を有することになる。ＧＵＩＤは、ＫＭサーバ情報および鍵ＩＤから成るべきである。この２つを同時に使用することによって、あらゆるＫＭＳがそもそも一意に特定される限り（Ｅｔｈｅｒｎｅｔ（登録商標） ＭＡＣアドレス、製造番号または他の世界的に一意の識別子等によって）、任意の鍵の一意性が可能となる。しかしながら、ＧＵＩＤは、鍵が場所から場所へと動く必要がある一方、暗号化するためにこれらの鍵が使用される媒体が、これらの鍵を見つけるための元の識別子しか持たないことになるため、特定のアドレスと混同されるべきではない。これに基づいて、世界的な距離や複製が伴う場合に、ＧＵＩＤは鍵を見つける際に重要となる。

セキュア通信の検討事項：ＫＭクライアントがＫＭサーバとの通信を希望する場合、通信を確立し、使用し、維持するためのセキュアな機構が存在するべきである。どの輸送機構が使用されるかは問題とならない。ＩＰネットワークであろうとＳＣＳＩ輸送であろうと、鍵を含むすべてのトランザクションがセキュアであるべきである。以下は、ＫＭサーバとの通信の態様である。

１．通信プロトコル
現在、ＫＭサーバによる使用のために、複数の標準プロトコルが考慮され得る。ＩＰベースの通信のためのプロトコルを決定する際、プロトコルは、アプリケーションおよびプロセッサのオーバーヘッド最小に保たれるような方法によって、ＫＭＣＳおよびＫＭＳＳ通信の両者をサポートすることができるべきである。

ＴＬＳとＩＰＳｅｃの両者が、ＩＰベースの通信をセキュアにすることのできる潜在的なプロトコルとして考慮される。両プロトコルは極めてよく理解されており、欠陥について暗号およびプロトコルセキュリティの専門家によって検査が行われている。これらのプロトコルは両者とも、ＫＭＳと使用されるために適合させることができる。他の全ての点が同様であるので、多くの環境においてＴＬＳの使用がＩＰＳｅｃの使用に数で勝ると思われるため、ＴＬＳを使用することを推奨する。

セキュアな接続の確立には、セッション鍵交渉および認証機構の両者を必要とするべきである。鍵交渉は、ほとんどの標準規格セキュア通信プロトコルにおいてすでに内蔵されているが、そうでない場合、ＩＫＥｖ２が選択肢となり得る。

２．認証機構
認証とは、廉価なＫＭクライアントとＫＭＳサーバ間の通信の両者対して対処されねばならない課題である。認証は双方向であるべきであるが、ＫＭクライアントがサーバに対して認証される必要であり、ＫＭサーバは暗号ユーザに対して認証される必要がない場合がある。

他のＫＭＳユーザは、ユーザＩＤおよびパスワード認証を必要とする場合があり、ＫＭサーバとともに認証するＫＭクライアントのために２つ以上の要素認証がサポートされることが強く推奨される。

３．メッセージングフォーマット
通信プロトコルおよび認証機構に類似して、ＫＭＳのためにいくつかのメッセージフォーマットが使用することができる。

２つの最も一般的なものは、ＡＳＮ．１とＸＭＬである。それぞれが、サービスモデルの全体にどちらが最も適しているかを決定するために、調査が行われることを必要とする効果を有する。両者とも、または別のフォーマットを使用することが許容可能である場合がある一方、ＫＭＳ標準規格の第１の反復において単一のフォーマットをサポートすることには大きな配慮が与えられるべきである。

ＫＭクライアントおよびＫＭサーバの識別：ＫＭサーバとＫＭクライアントとの間に、概要描写がされるべきである。ＫＭクライアントは通常、保存データの暗号化および暗号解読を実施するＣＵを含むか、または制御する。ＫＭサーバは、ＫＭクライアントにサービスを提供するソフトウェアまたはハードウェアデバイスである。

中小サイズの組織には、ＫＭＳ動作を統合する（例えば、ＫＭクライアント内への鍵のストレージ）選択肢および潜在的な必要性が存在する。これらの事例において、スタンドアロンのＫＭサーバに接続される場合、デバイスは自身をＫＭクライアントとして識別し、そのように扱われるべきである。これは具体的には集中型システムによって解決される必要がある可能性のある、鍵が破壊されるのではなく無効化される際のような衝突を避けることを助ける。

これは、インテリジェントＫＭクライアントがより大きいＫＭレルムに所属する場合、必要に応じて機能をオフロードし、正常なＫＭクライアントのようにＫＭＳサービスに報告することができるように、エクスポート／インポート機能を自動化することが必要であり得る別の理由である。

能力交渉：時間とともにＫＭＳがサービスまたは機能を確実に追加することができるようにするために、ＫＭサーバおよびＫＭクライアントは、どの機能をそれぞれがサポートするか、最初の接続時にただちに交渉するべきである。能力交渉とは、ＫＭＳとＫＭクライアントが、どの機能をそれらが互いに通信することができるか（鍵の取得、鍵の保存、鍵の修正、鍵の検索等）、およびＫＭクライアントがＫＭサーバにどのような鍵メタデータを提供するかを決定することを意味する。

このような同一の種類の交渉が、要求された場合に発信ＫＭサーバから第２のＫＭサーバへ鍵が完全に複製されることができることを確実にするために、最初に接続を確立する際に２つのＫＭサーバの間で行われるべきである。これらの機能は、設定された時間より長く通信が中断されたか、デバイスのうちの１つがアップグレードされた時はいつでも、再び交渉されるべきである。これは、任意のデバイスのファームウェアの少なくとも１つの主要なバーションに対して、ベンダーが下位互換性を保証することを可能にする。

可能な時に、既定の一連の機能のための相互運用は、標準規格におけるアップデートとアップデートの間、特に互換性について維持されるべきである。互換性が失われることを必要とする変更が行われた場合、既存のおよび新しいデバイスがサポートされることができるように、標準規格において動作のレガシーモードを許可することへの考慮がなされるべきである。

ライトウェイトクライアントに対する特別な検討事項：ＫＭクライアントがサポートする必要のある最低限の機能は、鍵生成、鍵保存、および鍵取得である。これらの機能は、最低限の相互運用レベル、ならびに試験および証明の方法を提供する。これは、ＫＭクライアントがこのアクションを開始し、制御するため、ＫＭクライアントが自身の鍵を生成し、生成された鍵を要求しないことを妨げるものではない。

ＫＭクライアントベンダーに対する別の検討事項は、暗号化および鍵がどのように使用されるか規定し、履行するポリシーを受け入れる機構を含む。

これらの機能を超えて、ＫＭクライアントは、拡張された一連の機能において、どういった機能がサポートされるか交渉することができるべきである。

本技術のいくつかの実施形態を記載した。それでもなお、本技術の精神および範囲を逸脱することなく、種々の変更が行われることができることを理解されるであろう。したがって、他の実施形態は、以下の請求項の範囲内である。

Claims (22)

1. 暗号鍵の使用を制御するための方法であって、前記暗号鍵は、鍵管理システム内の１つ以上の鍵管理サーバに存在し、前記方法は、
   前記暗号鍵を無効にするステップを含み、前記無効にするステップは、
   すべての暗号ユニットから前記暗号鍵を削除するステップと、
   前記鍵管理システム内の前記鍵管理サーバ内で、前記暗号鍵を隔離するステップとを含み、
   前記暗号鍵を隔離するステップは、前記無効な暗号鍵へのすべてのアクセスを封鎖するステップを含む、方法。
2. 前記暗号鍵が使用可能な状態に復帰することができるかどうかを決定するステップであって、その決定は、適切な信用証明を持つユーザを持つユーザによって実行される、ステップと、
   前記暗号鍵を有効化することができる場合、前記鍵を使用可能な状態に戻すことにより、前記暗号鍵を使用するため、前記暗号ユニットによって有効化するステップとをさらに含む、請求項１に記載の方法。
3. 適切な信用証明を有するユーザは、鍵管理者またはマネージャを含む、請求項２に記載の方法。
4. 使用可能な状態は、前記無効状態よりも高い任意の状態を含む、請求項２に記載の方法。
5. 適切な信用証明を有するユーザは、前記暗号鍵と関連するセキュリティポリシーに関して、無効な鍵を有効化することができるかどうかを判断する権限がある、請求項２に記載の方法。
6. 前記無効鍵を２つ以上のコンポーネントシェアに分割するステップと、各コンポーネントシェアを格納するステップをさらに含み、
   各コンポーネントシェアへの権利が１名の管理者またはマネージャに与えられ、いかなる管理者またはマネージャも２つ以上のコンポーネントシェアへの権利を有しない、請求項１に記載の方法。
7. 前記暗号鍵が使用可能な状態に復帰されてもよいかどうかを決定するステップであって、その決定は、適切な信用証明を有するユーザによって実行される、ステップと、
   前記暗号鍵を使用可能な状態に戻すステップであって、前記コンポーネントシェアの２つ以上を戻すステップを含む、ステップと、をさらに含む、請求項６に記載の方法。
8. 鍵管理システム内のオブジェクトを識別する方法であって、
   前記オブジェクトのためのＧＵＩＤを作成するステップであって、前記ＧＵＩＤはＵＲＩによって表され、前記ＵＲＩはプレフィックス、レルム要素、オブジェクト要素、およびパス要素を含む、ステップと、
   前記ＵＲＩを前記鍵管理システムの中の１つ以上の鍵管理サーバにマッピングするステップと、
   前記オブジェクトを前記鍵管理システムの中の前記１つ以上の鍵管理サーバに格納するステップとを含む、方法。
9. 前記プレフィックスは、「ｋｍ」または「ｋｍｓ」である、請求項６に記載の方法。
10. 前記レルム要素は、前記鍵管理システム内の権限のゾーンの名称を含む、請求項６に記載の方法。
11. 前記オブジェクト要素は、前記鍵管理システムの制御下の任意の鍵を含むオブジェクトスペースを含む、請求項６に記載の方法。
12. 前記オブジェクトスペースは、「鍵」、「ポリシー」、「クライアント」、「グループ」、「プール」、「セット」、「ログ」、「セッション」、または「．ドメイン」のうちの１つと名づけられる、請求項１１に記載の方法。
13. 前記オブジェクト要素は、任意の鍵管理ポリシー、クライアント、グループ、プール、セット、ログ、またはセッションのうちの１つを含むオブジェクトスペースを含む、請求項６に記載の方法。
14. 前記オブジェクト要素は、ＤＮＳドメインのために確保されたオブジェクトスペースを含む、請求項６に記載の方法。
15. 前記パス要素は、マルチエレメントパスを含む、請求項６に記載の方法。
16. 前記マルチエレメントパスは、前記オブジェクトのための共通の既定のアクセス制御を画定する、請求項１５に記載の方法。
17. マッピングするステップは、ＫＭＳＳまたはＫＭＣＳを使用するステップを含む、請求項６に記載の方法。
18. 前記オブジェクトを、前記鍵管理システムの中の１つ以上の暗号ユニットに格納するステップをさらに含む、請求項６に記載の方法。
19. 前記オブジェクトを、前記鍵管理システムの中の１つ以上のＫＭクライアントに格納するステップをさらに含む、請求項６に記載の方法。
20. 前記オブジェクトを、前記鍵管理システムの中の１つ以上のＫＭクライアントに配布するステップをさらに含む、請求項６に記載の方法。
21. 鍵管理システム内のオブジェクトを取り出す方法であって、
    前記オブジェクトのためのＵＲＩを受け取るステップと、
    前記ＵＲＩを前記鍵管理システムの中の１つ以上の鍵管理サーバにマッピングするステップと、
    前記鍵管理システムの中の前記１つ以上の鍵管理サーバのうちの１つから前記オブジェクトを取り出すステップとを含む、方法。
22. マッピングするステップは、ＫＭＳＳまたはＫＭＣＳを使用するステップを含む、請求項２１に記載の方法。