M（%GOなど）で書かれたユーティリティプログラムは、mumpsプロセスの内で実行し、Mで書かれた他の任意のコードのように振る舞います。mumpsプロセスが暗号化されたデータベースにアクセスする場合、暗号化キーが必要です。暗号化データベースにアクセスしていない、Mで書かれたユーティリティプログラムを実行しているプロセス（例：%RSELのような）は、ユーティリティプログラムを実行するだけで暗号化キーを必要としません。
暗号化キーにアクセスする必要があるM言語（例：MUPIP）で書かれていないユーティリティプログラムは、ディスク上のキーリングへのパスワードの入力を求めません。それらは難読化されたパスワードを環境で利用できるようにする必要があります。前述のように、maskpassプログラムを使用して環境内のパスワードまたは mumpsラッパー・プロセスを設定して、環境で難読化されたパスワードを設定することができます。場合によっては、必要なキーが指定されていない場合または誤ったキーが指定されている場合は、ユーティリティー・プログラムは、後続のアクションが暗号化されたデータへのアクセスを必要としない場合にプロセスの開始時にエラーを報告することを延期し、最初に暗号化または復号化操作を試みるときに通知します。
安心してアプリケーション・データにアクセスしないため、GDEおよびLKEアプリケーションは暗号化されたデータベースを操作するために暗号化キーにアクセスする必要はありません。
MUPIPとDSEはmumpsプロセスと同じプラグイン・アーキテクチャを使用します - gtmcrypt_init() はキーを取得し、gtmcrypt_encrypt() は暗号化します、など。
グローバル・ディレクトリ・ファイルは決して暗号化されないので、GDEは暗号化キーにアクセスする必要はありません。
暗号化をサポートする必要があるため、暗号化を使用するかどうかに関係なく、グローバル・ディレクトリ形式にアップグレードできます。GDEで既存のグローバル・ディレクトリを開き、EXITコマンドでプログラムを閉じるだけで、グローバル・ディレクトリがアップグレードされます。
![[重要]](images/important.jpg) |
重要 |
|---|---|
グローバル・ディレクトリをアップグレードする前に、グローバル・ディレクトリのコピーを作ることを、FISは強く推奨します。グローバル・ディレクトリをダウングレードする方法はありません。再作成する必要があります。 |
誤ってグローバル・ディレクトリを新しい形式にアップグレードし、古いグローバルディレクトリを再作成したい場合は、新しいGT.MリリースでSHOW ALLコマンドを実行し、出力をキャプチャします。SHOW ALLコマンドの情報を使用して、以前のGT.Mリリースで新しいグローバル・ディレクトリ・ファイルを作成するか、もっと良いことは、GDEにフィードして新しいグローバルディレクトリを作成できるスクリプトを作成することをお勧めします。
暗号化されたデータベースを操作するための暗号化キーが不要な次のコマンドを除いて、MUPIPは暗号化されたデータベースを操作するために暗号化キーにアクセスする必要があります：BACKUP -BYTESTREAM, EXIT, EXTEND, FTOK, HELP, INTRPT, REPLICATE, RUNDOWN, STOP 。MUPIP は 環境変数 $gtm_passwd のディスク上のキーリングのパスワードを探し、暗号化されたデータを含むデータベース、ジャーナル、バックアップ、または抽出ファイルに一致するキーを取得できない場合はエラーで終了します。
![[注意]](images/note.jpg) |
注意 |
|---|---|
|
データベースへのアクセスを必要とせずにジャーナル・ファイルでのみ動作するMUPIP JOURNAL操作（EXTRACTおよびSHOW）は、現在のデータベース・ファイル・キーではなくジャーナル・ファイルのキーのみを必要とします。 データベースへのスタンド・アロン・アクセスを必要とするMUPIP SET操作では、暗号化キーは必要ありません。データベースへの同時アクセスで動作できるコマンドは、暗号化キーが必要です。 他のすべてのMUPIP操作では、データベースの暗号化キーにアクセスする必要があります。 MUPIP EXTRACT -FORMAT=ZWRITE または -FORMAT=GLO および MUPIP JOURNAL -EXTRACT は、データベースおよびジャーナルファイルが暗号化されている場合でも、読み取り可能なデータベースコンテンツを生成し、クリアテキスト出力を生成することを目的としています。 MUPIP EXTRACT -FORMAT=BINARY 抽出ファイルには、複数のデータベースファイルから暗号化されたデータが含まれることがあるため、抽出ファイルには、抽出されたデータが取得されたすべてのデータベースファイルのハッシュが含まれます。 暗号化されたデータベースをGT.Mバージョン4（V4）形式にダウングレードすることはできません。 |
MUPIP CREATE は、マスター・キー・ファイル内の database_filename を使用して、対応する key_filename からキーを取得する唯一のコマンドです。別の場所で説明したように、他のすべてのコマンドは、暗号化されたデータの暗号化ハッシュと一致するキーリングのキーをメモリ内で使用します。同じファイル名を持つ複数のファイルがある場合、MUPIP CREATEは最後の database_filename エントリで指定されたキーをマスター・キー・ファイルのその名前で使用します。
MUPIP JOURNAL -SHOW コマンドは、ジャーナル・ファイル・ヘッダーに格納されている対称キーの暗号化ハッシュを表示するようになりました（出力は長い行です）：
$ mupip journal -show -backward mumps.mjl 2>&1 | grep hash Journal file hash F226703EC502E9757848 ... $
FIS GT.Mサポートの具体的な指示の下で行動しているのでなければ、環境内で $gtm_passwd の値を設定することによってDSEに暗号鍵へのアクセスを提供してください。
ファイル・ヘッダー（ CHANGE -FILEHEADER など）で動作するDSE操作では、データベース暗号化キーにアクセスする必要はありませんが、データ・ブロック（DUMP -BLOCKなど）にアクセスするDSE操作では通常、暗号化キーにアクセスする必要があります。ただし、DSEがデータベースを最後に終了するプロセスである場合は、暗号化キーが必要なダーティなグローバル・バッファをフラッシュする必要があるため、すべてのDSE操作で暗号化キーにアクセスする必要があります。DSEはブロックダンプを暗号化しません。ブロック0（ビットマップ）を見るためにデータベース・キーへのアクセスが必要であるという現在の誤った特徴があります。実際には、これは厳しい制限ではありません。通常、ビットマップの検査時にデータレコードも検査されます（それにもかかれらず、キーが必要です）。
DSEは知識のあるユーザーが使用する低レベルのユーティリティであり、コマンドや値の合理性をチェックするものではありません。
DSE DUMP -FILEHEADER -ALL コマンドは、暗号化ハッシュを含むデータベースファイルのヘッダーを表示します（ハッシュは非常に長い行です）。
$ dse dump -fileheader -all 2>&1 | grep hash Database file encryption hash F226703EC502E9757848EEC733E1C3CABE5AC... $
通常の操作条件下では、対称キーの暗号化ハッシュを変更する必要はありません。ただし、ハッシュに対する理論上の攻撃があり、この日付の時点で新しい暗号化ハッシュ規格（SHA-3）が開発中であるため、DSEは、もしハッシュ・ライブラリを変更した時には、データベース・ファイル・ヘッダーに格納されているパスワードのハッシュを変更する機能を提供します。
DSE CHANGE -FILEHEADER -ENCRYPTION_HASH 関数は、キーファイルの対称キーをハッシュし、データベース・ファイル・ヘッダーのハッシュをこの新しい値で置き換えます。ハッシュを変更する手順は次のとおりです：
古いハッシュ関数をプラグインにリンクして、データベースがMUPIP INTEGで構造的に健全であることを確認します。ファイル・ヘッダーのハッシュを変更するとデータ・ブロックは変更されませんが、作業を進める前にデータベースの健全性を検証すると、作業の信頼性が向上し、後続の問題が発生した場合のトラブルシューティングが容易になります。
新しいハッシュ関数を使用するようにプラグインを切り替えます。
DSE CHANGE -FILEHEADER -ENCRYPTION_HASH 操作を実行します。
異なるハッシュを持つ前世代のジャーナル・ファイルではリカバリが不可能なので、データベースがジャーナリングされている場合は、MUPIP SET -JOURNAL -NOPREVJNLコマンドを使用してバックポインタなしで新しいジャーナルファイルを作成します。FISは現時点でデータベースのバックアップを提案しています。
グローバル・ノードまたは DSE DUMP -BLOCKコマンドを読み取って、新しいハッシュ関数の正確性を検証します。
ジャーナル・ファイル・ヘッダーのハッシュを変更する方法がないので、古いジャーナル・ファイルのデータにアクセスできるようにする限り、ジャーナル・ファイルに使用されるハッシュ・パッケージへのアクセスを保持していることを確認してください。異なるハッシュを持つこれらの古いジャーナルファイルは、データベース・リカバリに使用できません。ただし、古いハッシュ関数を使用するMUPIPプロセスによってMUPIP JOURNAL -EXTRACTコマンドを使用して、その中のデータにアクセスできます。
データベース・ファイルの暗号化キーを変更する唯一の方法は、データを抽出し、それを別のキーで作成された新しいデータベースファイルにロードすることです。論理マルチサイト（LMS）アプリケーション構成を使用して、アプリケーションを使用可能にしたままでキーを変更します。たとえば、A が最初に開始（プライマリ）インスタンスであり、B が複製（セカンダリ）インスタンスである場合は、次のようになります：
インスタンスBを停止し、EXTRACTとLOADを使用してデータベース・キーを変更します。ジャーナル・シーケンス番号をオリジナルのデータベース・ファイルに保存し、新しく作成したすべてのデータベース・ファイルのジャーナル・シーケンス番号をオリジナルのデータベース・ファイルの最大番号に設定することを忘れないでください。
インスタンス B を起動し、A に追いついてみましょう。
便利な時に、スイッチオーバーします。これで、アプリケーション・ロジックは B で実行され、A は複製インスタンスになります。
インスタンス A を停止し、EXTRACT / LOAD または B のバックアップを使用してデータベース・キーを変更します。その後、バックアップを戻して追いついてください。
オリジナルの動作設定を復元するには、都合の良いときにスイッチオーバーを行います。今、A は、再び B に複製されるアプリケーションロジックを実行します。
FISでは、異なるインスタンスに対して異なる暗号化キーを使用することを提案しています。そのため、あるインスタンスのキーが侵害された場合、キーが侵害されていない別のインスタンスからアプリケーションを利用できるようにし、侵害されたキーを使用してインスタンスの暗号化キーを変更することができます。