JP2007233970A

JP2007233970A - セキュリティ管理システム

Info

Publication number: JP2007233970A
Application number: JP2006058344A
Authority: JP
Inventors: Atsushi Takeoka; 厚竹岡
Original assignee: Mitsubishi Electric Information Systems Corp; Mitsubishi Electric Information Technology Corp
Current assignee: Mitsubishi Electric Information Systems Corp; Mitsubishi Electric Information Technology Corp
Priority date: 2006-03-03
Filing date: 2006-03-03
Publication date: 2007-09-13
Anticipated expiration: 2026-03-03
Also published as: JP4469804B2

Abstract

【課題】セキュリティポリシーが異なる複数の環境において、全端末に同一の暗号鍵を付与する際の作業効率を向上させることができるセキュリティ管理システムを提供する。
【解決手段】管理端末１は、暗号鍵を作成するセキュリティＩＤ定義手段２２と、インストーラ生成手段２３とを含む。セキュリティＩＤ定義手段２２は、暗号鍵を作成する際に、管理端末１に接続されるＵＳＢキーのＩＤを受け取り、これを暗号鍵と関連付けてセキュリティＩＤ記憶手段３２に記憶させる。インストーラ生成手段２３は、インストーラを生成する際に、そのインストーラに含まれるべき暗号鍵に関連付けられたＵＳＢキーが、管理端末１に接続されているかどうかの判定を行う。
【選択図】図１

Description

本発明は、セキュリティ管理システムに関する。

セキュリティ管理に関する仕組みの一つとして、セキュリティポリシーを実装するためのプログラムを含むインストーラを利用する技術が知られている。このような技術では、まず管理者が使用する管理端末によってインストーラが生成され、次にこのインストーラによって管理対象端末にセキュリティポリシーが実装される。
このような技術の例は、特許文献１に開示される。

このようなインストーラには、データの暗号化に使用される暗号鍵の情報を含むものもある。この場合、インストーラが生成された時点で内部的にユニークな暗号鍵を含むセキュリティＩＤを生成し、これをそのインストーラ固有のＩＤとする。

特開２００５−５６１３７号公報

しかしながら、従来の技術では、セキュリティポリシーが異なる複数の環境において、全端末に同一の暗号鍵を付与しようとすると、たとえば以下に示すように、作業効率が低くなるという問題があった。
従来の技術では、同一の暗号鍵を有する異なるインストーラを作成することができないため、セキュリティポリシーが異なる複数の環境に対応するインストーラの暗号鍵を同一のものとすることができない。したがって、セキュリティポリシーが異なる環境で同一の暗号鍵を使用する際には、いったん一つのセキュリティポリシーに対応するインストーラによって全端末に暗号鍵を付与し、その後一部の端末のセキュリティポリシーを個別に変更するという作業が必要になり、作業効率が低下する。

この発明は、このような問題点を解決するためになされたものであり、セキュリティポリシーが異なる複数の環境において、全端末に同一の暗号鍵を付与する際の作業効率を向上させることができるセキュリティ管理システムを提供することを目的とする。

上述の問題点を解決するため、この発明に係るセキュリティ管理システムは、暗号鍵を作成する暗号鍵定義手段と、暗号鍵を記憶する暗号鍵記憶手段と、暗号鍵を含むインストーラを生成するインストーラ生成手段と、物理鍵が接続される物理鍵接続手段とを有し、暗号鍵定義手段は、暗号鍵の作成に関連して物理鍵接続手段に接続される物理鍵の識別情報を受け取るとともに、受け取った物理鍵の識別情報を暗号鍵に関連付け、インストーラ生成手段は、暗号鍵を含むインストーラの生成に関連して、生成されるインストーラに含まれるべき暗号鍵に関連付けられた物理鍵の識別情報を有する物理鍵が、物理鍵接続手段に接続されたかどうかの判定を行う。

暗号鍵定義手段は、複数の物理鍵の識別情報を暗号鍵に関連付けてもよい。
物理鍵はＵＳＢキーであり、物理鍵の識別情報はＵＳＢキーのシリアルナンバーを表してもよい。

この発明によれば、セキュリティ管理システムは、同一のセキュリティＩＤおよび異なるセキュリティポリシーを有する複数のインストーラを生成する。これによって、複数の管理対象端末に、同一の暗号鍵を与えつつそれぞれ異なるセキュリティポリシーを直接的に実装することができ、作業効率を向上させることができる。

以下、この発明の実施の形態を添付図面に基づいて説明する。
実施の形態１．
図１は、本発明に係るセキュリティ管理システムである、管理端末１の構成を示す。管理端末１は周知の構成を有するコンピュータであり、使用者からの入力を受け取る入力手段１０と、演算を行う演算手段２０と、情報を格納する記憶手段３０と、ＵＳＢ（Universal Serial Bus）対応機器を接続するためのＵＳＢポート５０とを備える。入力手段１０はキーボードおよびマウスを含み、演算手段２０はＣＰＵ（中央処理装置）を含み、記憶手段３０はメモリおよびＨＤＤ（ハードディスクドライブ）を含む。
管理端末１は、さらに、出力装置であるディスプレイおよびプリンタ、通信ネットワークに対する入力装置と出力装置とを兼ねるネットワークインタフェースを備える。

管理端末１は、セキュリティポリシー、セキュリティＩＤ、およびインストーラを扱うものである。
本明細書において、セキュリティポリシーとは、コンピュータ単位に実装されるセキュリティ、すなわちデータの改竄および漏洩を防止する方法の組合せを意味する。セキュリティポリシーに含まれる項目の例としては、いったん起動されたいわゆるスクリーンセーバーを解除するためにパスワードの入力を要求するかどうかの指定、ＨＤＤに記憶されるデータを暗号化するかどうかの指定、および、取り外し可能媒体へのデータ記憶を許可するかどうかの指定、等が挙げられる。
また、本明細書において、セキュリティＩＤとは、データの暗号化に関する処理に使用される暗号鍵に関連付けられる識別情報を意味する。たとえば、ある暗号鍵を含むインストーラを作成する処理には、その暗号鍵に関連付けられたセキュリティＩＤを指定することが必要である。
また、本明細書において、インストーラとは、暗号鍵およびセキュリティポリシーを表すデータを含み、この暗号鍵およびセキュリティポリシーをコンピュータに実装するためのプログラムを意味する。セキュリティ管理の対象となる端末が、プログラムであるインストーラを実行することにより、そのインストーラに含まれるセキュリティポリシーの内容に対応するプログラムおよびその他のデータが、その端末に入力される。すなわち、そのセキュリティポリシーが管理対象端末に実装される。
インストーラは、管理側の端末において作成された後、管理対象端末に配布され、管理対象端末によって実行される。配布の方法としては、ネットワーク経由、フロッピー（登録商標）ディスク経由、ＣＤ−Ｒ経由等が可能である。なお、インストーラは、セキュリティポリシーの実装には直接関連しないプログラムおよびデータも入力するものであってもよい。

管理端末１の演算手段２０は、記憶手段３０に格納されるプログラム（図示せず）を実行することによって、複数の機能を実現する。すなわち、セキュリティポリシーの定義を行うセキュリティポリシー定義手段２１としての機能、セキュリティＩＤの定義を行うセキュリティＩＤ定義手段２２としての機能、および、セキュリティポリシーおよびセキュリティＩＤを結び合わせてインストーラの生成を行うインストーラ生成手段２３としての機能である。
ここで、セキュリティＩＤ定義手段２２は、暗号鍵の作成を行う暗号鍵定義手段としても機能する。また、セキュリティポリシー定義手段２１、セキュリティＩＤ定義手段２２、およびインストーラ生成手段２３は、それぞれ、出力装置（図示せず）を介してＧＵＩ（Graphic User Interface）を提供し、このＧＵＩと入力手段１０とによって管理端末１の使用者に対する入出力を行う。

記憶手段３０は、セキュリティポリシーに関する情報を記憶するセキュリティポリシー記憶手段３１と、セキュリティＩＤに関する情報を記憶するセキュリティＩＤ記憶手段３２と、インストーラに関する情報を記憶するインストーラ記憶手段３３とを含む。
ここで、後述するように、セキュリティＩＤにはそれぞれ対応する暗号鍵が関連付けられているので、セキュリティＩＤ記憶手段３２は、暗号鍵を記憶する暗号鍵記憶手段としても機能する。

また、管理端末１のＵＳＢポート５０は物理鍵接続手段であり、物理鍵としてのＵＳＢキーであるＵＳＢキーＡ４１、ＵＳＢキーＢ４２、およびＵＳＢキーＣ４３が接続可能である。図１ではＵＳＢキーＡ４１が接続されている。
これらのＵＳＢキーはそれぞれ、ＵＳＢキーを互いに識別するためのＩＤである識別情報をその内部に記憶しており、コンピュータ（たとえば管理端末１）に接続されることによってこの識別情報をそのコンピュータに入力する。または、コンピュータがこの識別情報をＵＳＢキーから読み取ってもよい。このＩＤは、各ＵＳＢキーのシリアルナンバーを表す固有のもので、変更不可能である。たとえば、ＵＳＢキーＡ４１には「１２３４５ＡＡＡ」という文字列が、ＵＳＢキーＢ４２には「９８７６５ＢＢＢ」という文字列が、ＵＳＢキーＣ４３には「７８９４５ＣＣＣ」という文字列が、それぞれシリアルナンバーとして記憶されている。図１の例では、管理端末１にはＵＳＢキーＡ４１が接続されているので、管理端末１にＵＳＢキーのＩＤとして「１２３４５ＡＡＡ」という文字列がＵＳＢポート５０を介して入力される。
このように、複数のＵＳＢキーを用意し、適宜ＵＳＢポート５０に接続することにより、複数のＵＳＢキーのＩＤを選択的に管理端末１に入力することが可能である。なお、後述するように、これらのＵＳＢキーはセキュリティＩＤ定義手段２２およびインストーラ生成手段２３の処理において必要とされる。

以上のように構成される管理端末１における処理の流れを、図２のフローチャートを用いて説明する。
まず、セキュリティポリシー定義手段２１がセキュリティポリシーの定義を行う（ステップＳ１）。ここで、セキュリティポリシー定義手段２１は、入力手段１０を介してセキュリティポリシーの定義に関連する使用者からの入力を受け取り、また、定義されたセキュリティポリシーをセキュリティポリシー記憶手段３１に記憶させる。

図３に、セキュリティポリシー記憶手段３１に記憶されるセキュリティポリシー一覧表の構成の例を示す。このセキュリティポリシー一覧表は、定義されたセキュリティポリシーに関連する項目の一部を記憶する。ポリシーＩＤは、そのセキュリティポリシーを特定するための識別情報を表す。ポリシー名は、そのセキュリティポリシーに関連付けられる名称を表し、主に使用者によって利用される。ポリシー内容は、各セキュリティポリシーの内容として指定される項目の内容を表す。作成日は、そのセキュリティポリシーが作成された日付、すなわちステップＳ１が実行された日付を表す。更新日は、そのセキュリティポリシーが、作成後、最後に更新された日付を表す。
なお、この一覧表において、各行が一つのセキュリティポリシーに対応し、ポリシーＩＤが各行を区別するキーとなる。

次に、セキュリティＩＤ定義手段２２が、入力手段１０を介して、セキュリティＩＤの定義に関連する使用者からの入力を受け取る（ステップＳ２）。
次に、セキュリティＩＤ定義手段２２は、管理端末１のＵＳＢポート５０にＵＳＢキーが接続されているかどうか判定する（ステップＳ３）。ここで、セキュリティＩＤ定義手段２２は、判定を行う前に、セキュリティＩＤの定義に使用するＵＳＢキーの接続を促す表示を行ってもよい。
ＵＳＢキーが接続されている場合、セキュリティＩＤ定義手段２２は、暗号鍵の情報を含むセキュリティＩＤの定義を作成し、暗号鍵そのものを表すデータとともにセキュリティＩＤ記憶手段３２に記憶させる（ステップＳ４）。ここで、セキュリティＩＤ定義手段２２は、新たに作成された暗号鍵と、ステップＳ２において受け取った入力と、ＵＳＢポート５０を介して受け取るＵＳＢキーのＩＤとに基づき、これらを関連付けてセキュリティＩＤの定義を作成する。

図４に、セキュリティＩＤ記憶手段３２に記憶されるセキュリティＩＤ一覧表の構成の例を示す。このセキュリティＩＤ一覧表は、定義されたセキュリティＩＤに関連する項目の一部を記憶する。
セキュリティＩＤ名は、そのセキュリティＩＤに関連付けられる名称を表し、主に使用者によって利用される。
定義済ＩＤは、各セキュリティＩＤに関連付けられるＵＳＢキーのＩＤを表す。ここで、ＵＳＢＩＤ１は、各セキュリティＩＤが定義される際に関連付けられるＩＤであり、ステップＳ３において接続されていたＵＳＢキーのＩＤが指定される。また、ＵＳＢＩＤ２およびＵＳＢＩＤ３は、各セキュリティＩＤが定義された後に、追加で関連付けられるＩＤであり、図２のフローチャートには示されないＩＤ追加処理によって指定される。このＩＤ追加処理は、たとえば、まずセキュリティＩＤ定義手段２２が、該当のセキュリティＩＤにすでに関連付けられ、ＵＳＢＩＤ１として定義されたＵＳＢキーの接続を確認し、次にＵＳＢＩＤ２またはＵＳＢＩＤ３として定義すべきＵＳＢキーの接続を要求するという処理を含む。ここで、まずＵＳＢＩＤ１の接続を確認するという処理は、一度作成されたセキュリティＩＤを変更するためには、すでに関連付けられているＩＤを持つＵＳＢキー（ＩＤ追加処理によって追加されたＩＤがある場合にはそれも含む）のいずれかを接続する必要があるというセキュリティ要件が課されることを意味する。

また、図４のセキュリティＩＤ一覧表において、暗号鍵は、そのセキュリティＩＤに関連付けられる暗号鍵を表す。
作成日は、そのセキュリティＩＤが作成された日付、すなわちステップＳ４が実行された日付を表す。更新日は、そのセキュリティＩＤが、作成後、最後に更新された日付を表す。
なお、この一覧表において、各行が一つのセキュリティＩＤに対応し、セキュリティＩＤが各行を区別するキーとなる。

また、ステップＳ３において、ＵＳＢキーが接続されていない場合は、セキュリティＩＤ定義手段２２はエラー出力を行い（ステップＳ８）、処理を終了する。

ステップＳ４の後、インストーラ生成手段２３が、入力手段１０を介して、インストーラの作成に関連する使用者からの入力を受け取る（ステップＳ５）。ここで、入力はそのインストーラに関連付けられるべきセキュリティＩＤを表す情報を含む。
次に、インストーラ生成手段２３は、入力されたセキュリティＩＤに対応するＵＳＢキーが接続されているかどうかを判定する（ステップＳ６）。ここで、インストーラ生成手段２３は、図４のセキュリティＩＤ一覧表において、入力されたセキュリティＩＤに関連付けられた定義済ＩＤを参照し、接続されているＵＳＢキーのＩＤが定義済ＩＤに含まれるかどうかを判定するものである。この判定は、作成されたセキュリティＩＤを使用してインストーラを生成するためには、そのセキュリティＩＤに関連付けられた定義済ＩＤを持つＵＳＢキーを接続する必要があるというセキュリティ要件が課されることを意味する。
ここで、インストーラ生成手段２３は、判定を行う前に、インストーラの生成に使用するＵＳＢキーの接続を促す表示を行ってもよい。

対応するＵＳＢキーが接続されている場合、インストーラ生成手段２３は、インストーラを生成して記憶手段３０に記憶させるとともに、インストーラに関連する情報をインストーラ記憶手段３３に記憶させる（ステップＳ７）。ここで生成されるインストーラの具体的なデータ形式は、たとえば実行可能ファイル、すなわちファイル名に「．ｅｘｅ」拡張子を有するものである。この実行可能ファイルは、管理対象端末で動作するセキュリティ管理に係るプログラムと、セキュリティポリシー記憶手段３１に記憶されているセキュリティポリシーに係る情報と、暗号鍵そのものとを含み、さらにこれらを管理対象端末にインストールするためのプログラムを含む。
また、インストーラそのものが記憶される具体的な場所は、たとえば管理端末１で一時保存データ用の領域として汎用される領域（Ｃ：￥ｔｅｍｐ等）や、フロッピー（登録商標）ディスク、ＵＳＢメモリ、メモリスティック等である。この場所はその都度使用者によって指定されるものであってもよい（その場合、ステップＳ７はその場所に関する使用者からの入力を受け付ける処理を含む）。ただし、上述のように、インストーラに関連する情報のうち、紛失を避ける必要性が高いデータ、たとえば暗号鍵そのもの等は、管理が容易かつ確実に行えるインストーラ記憶手段３３に記憶される。
ステップＳ７の後、インストーラ生成手段２３は処理を終了する。
なお、ステップＳ７において作成されるインストーラは、その後管理対象端末において実行され、これによってインストールが行われる。インストール後、その管理対象端末では、上述のように定義されたセキュリティポリシーに従い、各種データの管理や、暗号化などを行うことができる。

図５に、インストーラ記憶手段３３に記憶されるインストーラ一覧表の構成の例を示す。このインストーラ一覧表は、生成されたインストーラに関連する項目の一部を記憶する。
インストーラＩＤは、そのインストーラを特定するための識別情報を表す。ポリシーＩＤおよびセキュリティＩＤは、そのインストーラに関連付けられるセキュリティポリシーのポリシーＩＤ、および、セキュリティＩＤを表す。このように、インストーラは、セキュリティポリシーおよびセキュリティＩＤの二つが揃って初めて生成可能となるものである。
作成日は、そのインストーラが作成された日付、すなわちステップＳ７が実行された日付を表す。更新日は、そのインストーラが、作成後、最後に更新された日付を表す。
なお、この一覧表において、各行が一つのインストーラに対応し、インストーラＩＤが各行を区別するキーとなる。

なお、ステップＳ６において、入力されたセキュリティＩＤに対応するＵＳＢキーが接続されていない場合は、インストーラ生成手段２３はエラー出力を行い（ステップＳ９）、処理を終了する。

以上のように説明される処理の流れは、セキュリティポリシーの定義入力、セキュリティＩＤの定義入力、およびインストーラの作成にそれぞれ対応するステップがすべて実行される場合のものであるが、状況に応じて、これらのうちいずれかに対応するステップ（またはステップの処理の一部）が実行されないものであってもよい。
たとえば、既存のセキュリティポリシーおよび既存のセキュリティＩＤを用いてインストーラの作成が行われる場合には、ステップＳ１、Ｓ２、およびＳ４は実行されない。これは、たとえば、作成済みのインストーラを保存していなかった場合や、紛失してしまった場合に、これと同一のインストーラを再作成する際の処理の流れに相当する。
また、既存のセキュリティポリシーの一部を変更したものと、既存のセキュリティＩＤとを用いてインストーラの作成が行われる場合には、ステップＳ１ではセキュリティポリシーのうち変更される部分に関する入力のみを処理すればよく、Ｓ２およびＳ４は実行されない。これは、たとえば、既存のインストーラのセキュリティポリシーを一部変更して新たなインストーラを作成する際の処理の流れに相当する。
なお、上述のように、セキュリティＩＤに関連付けられるＵＳＢキーのＩＤを追加する場合（すなわちＩＤ追加処理を行う場合）や、セキュリティＩＤの定義内容を変更する場合、または、定義済セキュリティＩＤを使用してインストーラの新規作成・変更後の再作成・単なる再作成を行う場合等には、ステップＳ３またはＳ６において該当のセキュリティＩＤに関連付けられたＵＳＢキーとの照合が行われる。

このように、本発明に係る管理端末１は、あらかじめ作成されたセキュリティＩＤを利用してインストーラを生成するので、セキュリティＩＤおよび暗号鍵とインストーラとが必ずしも一対一に対応していなくとも良い。このため、同一の暗号鍵および異なるセキュリティポリシーを有する複数のインストーラを生成することができ、複数の管理対象端末にそれぞれ異なるセキュリティポリシーを直接的に実装することができる。したがって、いったんセキュリティポリシーを実装した後のセキュリティポリシー変更作業が不要となる。このようにして、管理端末１は、セキュリティポリシーが異なる複数の環境において、全端末に同一の暗号鍵を付与する際の作業効率を向上させることができる。

また、インストーラがバージョンアップされた際にも、同様にして、既存である旧バージョンのインストーラと同一のセキュリティＩＤを有する新バージョンのインストーラを生成することができるので、新バージョンのインストーラを用いてセキュリティポリシーの実装を直接的に実施することができる。したがって、いったん旧バージョンのインストーラを使用してセキュリティポリシーを実装しておき、その後に管理対象端末をアップデートするという作業が不要となり、管理対象端末を展開する際の作業効率を向上させることができる。

また、本発明に係る管理端末１は、セキュリティＩＤの作成および変更の際と、セキュリティＩＤを使用したインストーラ生成の際とに、ＵＳＢキーの接続を要求し、適切なＵＳＢキーの接続がなされない場合には処理を中止する。すなわち、電子データである暗号鍵を含むセキュリティＩＤと、物理的な鍵であるＵＳＢキーとを組み合わせて管理する。このため、たとえセキュリティＩＤやこれに関連付けられた暗号鍵が外部に流出しても、物理鍵が盗まれない限りセキュリティＩＤは悪用されない。このように、セキュリティＩＤの管理における安全性を向上させることができる。
ここで、ＵＳＢキーの接続が要求されるのは管理端末１に対してのみなので、ＵＳＢキーの運搬等に関する困難は生じない。また、固有のＩＤすなわちシリアルナンバーを有するＵＳＢキーの作成・複製は自由にはできないので、ＵＳＢキーの偽装に対しても安全性が保たれる。
さらに、このため、物理鍵以外のなんらかの仕組みによって単に同一のセキュリティＩＤを再利用可能とするような技術に対して、本発明に係る管理端末１は、同様の効果を維持しつつ、物理鍵を組み合わせることによる安全性の向上を実現することができる。

また、本発明に係る管理端末１は、一つのセキュリティＩＤに対して複数のＵＳＢキーを割り当てることも可能である。このため、ＵＳＢキーの紛失や故障に備えて予備のＵＳＢキーを用意することができるので、セキュリティを保ちつつ利便性を向上させることができる。

また、本発明に係る管理端末１は、インストーラとは独立してセキュリティＩＤを管理し、インストーラが生成された後もその生成に使用されたセキュリティＩＤを保持する。このため、事故等によってインストーラが存在しなくなった場合であっても、同一のセキュリティＩＤを有するインストーラを新たに生成することができるので、セキュリティを保ちつつ利便性を向上させることができる。

上述の実施の形態１において、物理鍵はＵＳＢキーであり、物理鍵接続手段はＵＳＢポートであるが、これは他のものであってもよい。たとえば、物理鍵をＩＣカードとし、物理鍵接続手段をＩＣカードリーダとしてもよい。また、物理鍵を特定人物の指紋とし、物理鍵接続手段を指紋認証センサーとしてもよい。

上述の実施の形態１において、管理端末１は、セキュリティ管理システムの全体を含む。すなわち、セキュリティポリシー定義手段２１、セキュリティＩＤ定義手段２２、インストーラ生成手段２３、セキュリティポリシー記憶手段３１、セキュリティＩＤ記憶手段３２、および、インストーラ記憶手段３３は、すべて単一のコンピュータに含まれる。
これとは異なる実施形態として、これらが複数のコンピュータに分散して設けられてもよい。たとえば、セキュリティＩＤ記憶手段３２とインストーラ記憶手段３３とがそれぞれ独立したコンピュータに設けられてもよい。

本発明の実施の形態１に係る管理端末の構成を示す図である。管理端末における処理の流れを示すフローチャートである。セキュリティポリシー一覧表の構成の例を示す図である。セキュリティＩＤ一覧表の構成の例を示す図である。インストーラ一覧表の構成の例を示す図である。

符号の説明

１管理端末（セキュリティ管理システム）、２２セキュリティＩＤ定義手段（暗号鍵定義手段）、２３インストーラ生成手段、３２セキュリティＩＤ記憶手段（暗号鍵記憶手段）、４１ＵＳＢキーＡ（物理鍵）、４２ＵＳＢキーＢ（物理鍵）、４３ＵＳＢキーＣ（物理鍵）、５０ＵＳＢポート（物理鍵接続手段）。

Claims

セキュリティ管理システムであって、
暗号鍵を作成する暗号鍵定義手段と、
前記暗号鍵を記憶する暗号鍵記憶手段と、
前記暗号鍵を含むインストーラを生成するインストーラ生成手段と、
物理鍵が接続される物理鍵接続手段と
を有し、
前記暗号鍵定義手段は、前記暗号鍵の前記作成に関連して前記物理鍵接続手段に接続される物理鍵の識別情報を受け取るとともに、受け取った前記物理鍵の前記識別情報を前記暗号鍵に関連付け、
前記インストーラ生成手段は、前記暗号鍵を含むインストーラの前記生成に関連して、前記生成されるインストーラに含まれるべき暗号鍵に関連付けられた前記物理鍵の前記識別情報を有する物理鍵が、前記物理鍵接続手段に接続されたかどうかの判定を行う
セキュリティ管理システム。
前記暗号鍵定義手段は、複数の前記物理鍵の前記識別情報を前記暗号鍵に関連付ける、請求項１に記載のセキュリティ管理システム。
前記物理鍵はＵＳＢキーであり、前記物理鍵の前記識別情報は前記ＵＳＢキーのシリアルナンバーを表す、請求項１または２に記載のセキュリティ管理システム。