選択したプラットフォーム上のGT.Mは、データベースファイルとジャーナルファイルのデータを暗号化できます。暗号化は、休止中のデータ(DAR)を保護します。つまり、ディスク・ファイルにアクセスできる権限のないプロセスによるデータへの不正アクセスから保護します。
プラグインアーキテクチャは、暗号化パッケージを選択的に使用することができます。暗号化の特性は、選択したパッケージによって完全に決定されています - 例えば、GT.Mは、"バックドア" や "キーリカバリ"を実装していません、そして、もしこのような機能が必要な場合は、必要とされる機能を提供するために、暗号化パッケージを選択または作成する必要があります。
FISは、人気があり広く利用されている暗号化ライブラリを使用してプラグインのリファレンス実装の、ソースとオブジェクトコードを配布しています。参照実装プラグインがあなたのニーズを満たしている場合、そのプラグインをディストビューションとして使用することはできますが、 “免責事項” のセクションを読んで理解してください。独自のプラグインを実装するためのベースとしても使用できます。
リファレンス実装では、GT.Mは対称暗号を使用してデータを暗号化します。参照実装は、公開キーと秘密キーを使用して非対称暗号で対称暗号のキーを暗号化します。秘密鍵は、パスワードでロックされたディスク上のキー・リング(またはパスフレーズ - これらの用語は互換的に使用されます)に格納されます。
データベースの暗号化は、包括的なセキュリティ計画の1つのコンポーネントとしてのみ役立ち、データを保護する唯一の手段としては不十分です。データベースの暗号化を使用するには、適切なセキュリティ計画が必要です。このドキュメントでは、暗号化されたGT.Mデータベースの実装について説明します。セキュリティ計画については言及していません。
適切なセキュリティプロトコルは、ディスク上に、難読化されたフォームであっても、および/または、わかりにくい場所であっても、暗号化されていないパスワードを配置することはけっしてしてはいけません。GT.Mデータベースの暗号化では、データベースにアクセスするプロセスのアドレス空間に暗号化されていないパスワードが存在するため、プロセス・メモリがページアウトされたときに暗号化されていないパスワードを理論的にスワップ・ファイルに書き込むことができます。暗号化されたスワップ・デバイスやファイルを使用して、GT.Mプロセスがページアウトされないようにするか、スワップ・ファイルの情報が実行中のプロセスだけが利用できるようにするなどの手段によって、インストールを安全に行う必要があります。言い換えれば、 暗号化に関しても、GT.Mデータベースの暗号化は完全なセキュリティ・インフラストラクチャの一部にすぎません。
FISの専門知識は、暗号化ではなくGT.Mにあります。暗号化のニーズはさまざまです。さらに、暗号化の使用は、あなたの所在地や状況に適用される規制によって、制限または必要とされる場合があります。したがって、我々のアプローチは、あなたが好みの暗号化ソフトウェアを選択できるプラグイン・アーキテクチャを作成することです。開発の過程で、主にGNUプライバシー・ガード、Pretty Good Privacyの広く利用可能な実装(Simson Garfinkel による「PGP:Pretty Good Privacy」参照)でテストしました。暗号化ソフトウェアの障害によってデータが回復不能になる可能性があるため、選択した暗号化ソフトウェアに信頼性があること(およびその信頼性が保証されていること)を確認してください。GT.M自体は暗号化を実行せず、暗号化はインストールおよび設定するソフトウェアによってのみ実行されます。FISは、特定の暗号化アルゴリズムまたはライブラリを保証もサポートもしていません。
さらに、GT.Mがあなたの選択した暗号化ライブラリを使用できるように、暗号化ライブラリには管理する必要のあるキーが必要です。最も単純な形式では、キー管理では、キーを必要とする人だけがそのキーを持っていることと、キーが失われていないことの両方が必要です。キー管理は、GT.Mのデータベース暗号化の実装から2つのステップが削除されていますが、暗号化されたデータベースの使用を成功させる上で重要です。それはあなたの操作運営ポリシーと手順の一部でなければなりません。FISは、選択した特定の暗号化のためにインフラストラクチャを実装する方法を詳細に理解することを強く推奨します。
セキュリティ・インフラストラクチャの要素とGT.Mデータベース暗号化以外の管理プロセスでは、以下のセクションで説明する問題を管理する必要があります。
GT.Mデータベースの暗号化は、安心してデータを保護するように設計されています。アプリケーションは、暗号化されていないデータを操作および生成するビジネスロジックを実行します。暗号化されていないデータはアプリケーションプロセス内に存在しなければならず、暗号化されていないデータを含むプロセスの仮想アドレス空間へのアクセス権を持つプロセスからアクセスできます。また、システム間およびプロセス間の転送中のデータは、GT.Mデータベースの暗号化によって保護されません。
GT.Mは、コアダンプを作成する前に、プロセス・アドレス空間内で認識しているすべてのキーをクリアしようとします。リファレンス実装では、暗号化ライブラリを使用して、キーがコアダンプに現れる可能性を最小限に抑えます。セキュリティポリシーに応じて、キーがプロセス・コア・ダンプに現れないことを保証することはできないため、FISでは、暗号化されたデータベースにアクセスするGT.Mプロセスによるコア・ダンプの作成を無効にするか、その他の手段を使用してコアダンプへのアクセスを制限するかを検討することをお勧めします。また、ランダム・バイト・シーケンスをキーとして使用すると、コアダンプでそれらを識別することが難しくなります [5] 。
これは、保存されていないデータがGT.Mデータベースの暗号化によって保護されていないという事実の結果です。
データベースを暗号化および復号化するには、GT.Mプロセスのアドレス空間/環境にキーが存在していなければなりません。さらに、リファレンス実装では、プロセスもユーザーの秘密鍵にアクセスする必要があり、秘密鍵にアクセスするには、ユーザーのGPGキーリングのパスフレーズにアクセスする必要があります。子プロセスに暗号化を渡すために、パスフレーズは難読化されていてもプロセス環境に存在します。つまり、暗号化されたデータベースにアクセスするGT.Mプロセスのアドレス空間や環境にアクセスできるプロセスは、パスフレーズとキーにアクセスできます。
アプリケーションがシェル・プロンプトまたはGT.Mダイレクトモード・プロンプトへのアクセス権の一部または全部を提供している場合、またはそのユーザがXECUTEできる任意のコードを指定できる場合、これらのユーザはキーとパスフレーズを表示およびキャプチャする方法を見つけることができます。キーまたはパスフレーズをキャプチャできる場合は、誤って使用することができます。たとえば、キャプチャしたGPGキーリングのパスフレーズがキャプチャされた場合は、パスフレーズを変更するために使用できます。したがって、キーとパスフレーズを表示しないユーザーには、アプリケーションからアクセスできないようにする必要があります。
この制限は、シェル・プロンプト、GT.Mダイレクトモード・プロンプトなどにアクセスできるユーザーがセッションをロック解除しないようにすることをより重要なものにします、簡単に言えば、その時間中にセッションにアクセスするために鍵とパスフレーズの知識を持っていてはいけない人にとっては、まったく可能な場合です。
データベース・ファイルの寿命は長いです。典型的な操作では、データベース内のデータのごく一部のみが毎日変更されます。暗号化キーを変更するにはすべてのデータを再暗号化する必要があるため、ファイルの暗号化キーの寿命が長いことを意味します。長期にわたるキーはセキュリティ・リスクがあります。たとえば、従業員が退去したときに変更することはできません。そのため、キー管理はセキュリティ計画全体の一部でなければなりません。長寿命のキーでは、少なくとも2段階のキー管理が必要です。長寿命のデータベース・キーでは、 通常、人間がアクセスまたは閲覧するのではなく、より簡単に変更できる別のキーで暗号化された形式で保存されています。
さらに、キーは、少なくともそのキーで暗号化されたバックアップと同じ長さを保持する必要があります。さもなければバックアップは役に立たなくなります。古いキーを保持し管理するための適切な手順が必要です。成功したデータ回復にはキーとアルゴリズムの両方が必要なため、保存プロセスでも暗号化アルゴリズムを保持する必要があります。
データベース・ファイルとジャーナル・ファイルは大きいです(GBから数百GB)。この大きなボリュームは、暗号化されたマテリアルのサンプル数が多いため、キーを破ることが容易になるため、暗号化された小さなメッセージよりも、データベースの暗号化を攻撃の対象としやすくなります。
FISは、特定の暗号化アルゴリズムを保証もサポートもしていません。
暗号化アルゴリズムの選択は、組織の好み、法的要件、業界標準、計算性能、堅牢性、暗号化ハードウェアの可用性などを含みますが、これらに限定されない多くの要因によって決定されます。すべてのニーズを満たすアルゴリズムはありません。
したがって、GT.Mは、暗号化アルゴリズム用の「プラグイン」アーキテクチャを提供しています。これにより、お好みの暗号化ソフトウェアをGT.Mと統合することができます。GT.M開発環境では、検証のために一般的な暗号化パッケージを使用してリファレンス実装のバリエーションを作成しました。各リファレンス実装のバリエーションを少なくとも1つのコンピューティング・プラットフォーム上でテストし、1つのリファレンス実装のバリエーションを各コンピューティング・プラットフォームでテストしました。このドキュメントでは、どのプラットフォームでどの暗号化パッケージをテストしたかを記載しています。
特定の暗号化パッケージの選択と使用については、すべてあなたが責任を負うものとします。以下の点にご注意ください:
GT.Mプロセスのアドレス空間内で実行されるすべての暗号化ライブラリは、記載されているように、GT.Mのための任意の関数の規則に準拠しなければなりません、しかし、シングルスレッドに限定されなくて、GT.Mのシグナル・ハンドラを変更することはなく、GT.Mなどが提供するAPIへのタイマーの使用の制限などが含まれます [6]。
暗号化ソフトウェアまたはハードウェアの誤動作により、データが回復不能になる可能性があります。包括的な組織リスク管理戦略の一環として、異なる暗号化パッケージを使用し、確かに異なる暗号化キーを使用して論理マルチサイト・アプリケーション構成を使用することを検討してください。
データベースの暗号化に使用される暗号は、暗号化された一連のバイトの長さを変更してはなりません。つまり、クリアテキスト文字列が n バイトの場合、暗号化された文字列も n バイトでなければなりません。
GT.Mデータベース暗号化のリファレンス実装には、紛失したキーを回復するための「バックドア("back door")」や他の手段がありません。また、リファレンス実装で使用されているパッケージのバックドアも認識していません。
失われたキーを使用すると、データがランダムなものやゼロと区別できなくなります。FISは、キーの預託(key escrow)などの技術を含む文書化されたキー管理プロセスを実装することを推奨していますが、最終的には、あなたがキーを管理するすべての責任を負います。
プロセス呼び出しチェーンのある時点では、リファレンス実装では、子プロセスが継承できるプロセス環境に(難読化された形式で)配置されたパスワードを提供する人間が必要です。人為的なやり取りなしに暗号化されたデータベースにアクセスできるようにするには、リファレンス実装を変更するか、独自の実装を作成する必要があります。
たとえば、クライアントからの着信接続要求に応答して xinetd によって起動されるGT.Mベースのアプリケーション・サーバー・プロセスがある場合、クライアントが、ローカル・ディスクからマスター・キー・リング用の暗号化パスワードを抽出し、それを難読化し、xinetdによって開始されたサーバー・プロセスの環境に配置するために使用されるキーをクライアントが送信する方法を検討することができます。クライアントが追加のパスワードを提供できるようにアプリケーションプロトコルを変更できない場合、xinetd は環境内の $gtm_passwd 難読化されたパスワードで開始でき、xinetd passenvパラメータはxinetdプロセスから $gtm_passwdを生成されたサーバプロセスに渡すために使用されます。
GT.Mデータベースの暗号化は、バッファ・グローバル(BG)アクセス方式でのみサポートされています。マップされたメモリ(MM)アクセス方法はサポートされていません。他のオプションについては、 “データベース暗号化の代替方法” を参照してください。
一部のプラットフォームでは、暗号化機能を内蔵したディスク。ドライブ、または暗号化されたファイルシステムを使用して、保存されているデータを保護することができます。これらは、GT.Mデータベースの暗号化ほど安全ではないかもしれません。たとえば、暗号化されたファイルシステムがマウントされると、適切な権限を持つプロセスがそのファイルにアクセスできます。GT.Mデータベースの暗号化では、データベースファイルにアクセスする各プロセスは、そのデータベース・ファイルのキーに個別にアクセスする必要があります。
暗号化の組み込みインターフェースは、データベース、ジャーナル、バックアップ、特定の形式の抽出ファイルのデータに対してのみ実装されています。IO(シーケンシャル・ディスク・ファイルなど)を暗号化するには、IOを使用してPIPEデバイスを使用できます。あるいは、外部呼び出しインタフェースを使用してGT.Mから暗号化ルーチンを呼び出すこともできます。
GT.Mは、レプリケーション・ストリームもGT.CM(GNP / OMI)ネットワーク・トラフィックも暗号化しません。必要に応じて、安全なTCP / IP接続を実装するための優れたサードパーティ製の製品があります。ソフトウェア・ソリューションだけでなく、暗号化ルーターなどのハードウェアソリューションもあります。
データベースにアクセスするGT.Mプロセスと同様に、更新プロセス、ヘルパープロセス、およびGT.CMサーバはすべて、暗号化されたデータベースへのアクセスを可能にするためにキーによるプロビジョニング(事前設定)を必要とします。
GT.CMサーバが暗号化されたデータベースのキーを持っている場合、サーバに接続しているクライアントは、そのデータベースの暗号化されたレコードにアクセスできます。
データベース暗号化の場合、プラグイン・リファレンス実装では、FIPS 140-2準拠の証明書を必要とするサイトのプラグインを変更する必要性を排除し、libccrypto(OpenSSL)をlibcrypto(OpenSSL)を「FIPSモード」で使用するオプションも提供しています。環境変数 $gtmcrypt_FIPS が1に設定されている(または、非ゼロの整数、または "TRUE"または "YES"の大文字小文字を区別しない文字列または先頭の部分文字列として評価される)場合、プラグインリファレンスの実装では、OpenSSLまたはLibgcrypt FIPS 140-2に準拠したデータベース暗号化を提供します。サポートされているプラットフォームは次のとおりです:
プラットフォーム |
Libgcrypt |
OpenSSL |
OpenSSL FIPS |
---|---|---|---|
Linux x86_64 |
1.4.5 |
1.0.0 |
1.0.1e |
Linux x86 |
1.4.5 |
1.0.0 |
1.0.1e |
AIX RS600 |
1.5.1 |
1.0.0e |
1.0.1e |
SunOS SPARC |
1.5.1 |
1.0.0j |
1.0.1e |
HP-UX IA64 |
1.4.1 |
1.0.1e |
1.0.1e |
これらのプラットフォームでFIPSモードを使用する前に、OpenSSLまたはLibgcryptのインストールで有効なFIPS 140-2実装を構成していることを確認してください。
注意 | |
---|---|
FIPS 140-2認証を取得するには、FIPS準拠の証明書ライブラリ、管理コントロールなどを含む基本的な暗号ライブラリを含む、GT.Mの範囲をはるかに超えるアクションとコントロールが必要です。FISはGT.Mで暗号ライブラリを提供しておらず、特定のライブラリの使用を推奨していません。 |