上級者リファレンス : Advanced Operations Guide : Zen セキュリティ
  
このページをシェアする                  
Zen セキュリティ
データベース エンジンのためのセキュリティに関する概念と作業
Zen は、MicroKernel エンジンを呼び出す SQL ベース アプリケーションおよび Btrieve アプリケーションに対し、それぞれリレーショナル データベース レベルおよびファイル レベルのセキュリティを提供します。データ アクセスは、オペレーティング システムや Active Directory アカウントを介したユーザー認証によって、もしくは Zen データベース ユーザーとして保護することができます。ユーザー ID が確認されると、そのユーザー権限は、オペレーティング システムまたは Active Directory の権限グループによって、もしくはユーザー/グループ レベルで定義された Zen データベース権によって承認されます。
以下のセクションでは、これらのセキュリティ モデルとそれらモデルの使用方法、および Zen のデータ ファイルの暗号化機能について説明します。
リレーショナル エンジンのセキュリティ モデル
MicroKernel エンジンのセキュリティ モデル
MicroKernel エンジンのセキュリティ計画
MicroKernel エンジン セキュリティのクイック スタート
ネットワーク上のデータの暗号化
リレーショナル エンジンのセキュリティ モデル
Zen では、SQL アプリケーションは、次の表に示す認証設定および許可設定を使用できます。
データベース セキュリティ
認証
許可
セキュリティのレベル
無効
オペレーティング システム
サーバー接続用のユーザー名とパスワード
制限なし
オーナー ネーム(省略可能)
なし。SQL 接続でアクセス可能なすべてのテーブル。
ローカル データベース
Zen ユーザー
オペレーティング システムやドメインとは無関係のユーザー名およびパスワード
Zen ユーザー権限(グループがない場合)
Zen グループ権限(ユーザー権限がない場合)
PUBLIC の権限
オーナー ネーム(省略可能)
データベース
テーブル
テーブル列
ストアド プロシージャ(V2 形式の場合)
ビュー(V2 形式の場合)
Windows ドメイン
Active Directory ユーザー
ユーザー名とパスワード
Zen データベース グループ名を使って付けられた名前を持つドメイン グループに割り当てられたユーザー
Zen グループ権限(必須)
PUBLIC の権限
オーナー ネーム(省略可能)
個々のユーザー権限/権利なし
ローカル データベースの場合と同じ
新しいデータベースを作成したとき、デフォルトでは、データベース セキュリティは無効になっています。これを有効にするには、セキュリティを有効にしたときに作成された Master ユーザーのパスワードを入力します。使用可能なパスワードの詳細については、識別子の種類別の制限を参照してください。
データベースのセキュリティを有効にした後で、さまざまなデータベース活動のために権限を設定するのに必要となるユーザーやグループを作成する必要があります。ローカル データベース セキュリティを設定するには、ユーザーに直接権限を割り当てる方法と、グループ レベルで権限を割り当ててからそのグループにユーザーを割り当てる方法の 2 つがあります。Windows ドメインのセキュリティを設定するには、グループのみを作成します。このグループの名前には、ネットワーク ユーザーがメンバーになっている権限グループと同じ名前を使用します。各データベースのユーザーやグループを管理するには、ZenCC または SQL スクリプトを使用します。
また、データベースに接続しているすべてのユーザーに適用されるデフォルトの PUBLIC グループの権限を設定することもできます。各ユーザーの権限は、ユーザー権限またはグループ権限と PUBLIC グループの権限の組み合わせとなります。新しいデータベースの PUBLIC グループには、権限が設定されておらず、すべての権限がグループ レベルまたは個々のユーザーのレベルで管理されている場合には設定は必要ありません。
これらの概念について、以降のセクションでさらに詳しく説明します。
Master ユーザー
特殊なグループである PUBLIC
ユーザーとグループ
SQL および Zen のセキュリティ
Master ユーザー
Zen データベースのセキュリティを有効にすると、そのデータベースヘのフル アクセス権を持つ Master という名前のユーザーが作成されます。Master ユーザーにはパスワードが必要です。このパスワードは、セキュリティを有効にするときに設定します。各データベースに設定する Master パスワードは互いに無関係のため、異なる値を設定できます。データベースのセキュリティ設定を変更するには Master パスワードを入力する必要があるため、Master パスワードを忘れないようにしてください。
データベースの Master ユーザーとして認証された後で、ZenCC を使用することで、そのデータベースのユーザーの作成、ユーザーの割り当て先となるグループの作成、グループ レベルとユーザー レベルでのデータへのアクセス権限の管理を行うことができます。また、グループの作成とそのグループへのユーザーの作成を行う SQL ステートメントを実行することもできます。ユーザーは、作成した 1 つのグループだけのメンバーになることができます。すべてのユーザーは各データベースの特殊なグループである PUBLIC のメンバーに自動的になります。
特殊なグループである PUBLIC
すべてのユーザーに同様のアクセス権を付与したい場合は、それらのアクセス権を PUBLIC という名前の特殊なグループに付与することができます。セキュリティを有効にすると、データベース エンジンは自動的に PUBLIC という特殊なグループを作成します。最初、PUBLIC には何のアクセス権も割り当てられていません。PUBLIC 権限を割り当てるか、独自の権限を持つユーザーやグループを作成するまでは、Zen データへのアクセスはブロックされます。
PUBLIC はすべてのユーザーにデフォルトの権限を与える特殊なグループです。別の Zen グループにユーザーを割り当てた場合でも、そのユーザーは PUBLIC のメンバーであり続けます。PUBLIC のアクセス権の適用方法をわかりやすくするために 2 つの例を示します。ZenCC で、PUBLIC に CREATE TABLE 権限を割り当てるとします。次に、ZenCC で myuser という名前のユーザーを作成しますが、ユーザーのアクセス権にテーブルを作成するための個別の権限は含めないものとします。データベース エンジンは最初に PUBLIC のアクセス権を調べるため、この場合、テーブル作成の権限は PUBLIC から付与されることになり、myuser はテーブルを作成できます。
逆に言えば、PUBLIC にアクセス権が付与されていない場合は、個々のユーザーまたはグループに付与されているアクセス権が適用されます。たとえば、ZenCC で、PUBLIC に CREATE TABLE 権限を割り当てないとします。ユーザーまたはユーザーが属するグループのアクセス権がテーブルの作成を許可しない限り、どのユーザーもテーブルを作成できません。
ユーザーとグループ
ローカル データベース認証を有効にした後で、そのデータベースのユーザーとグループの権限を管理できます。Windows ドメイン認証の場合には、ユーザー メンバーシップは Active Directory で割り当てられるため、グループ権限のみを管理することができます。どちらの認証の場合でも、ZenCC の Zen エクスプローラーには管理できるユーザーとグループが表示されます。次の表は、ユーザーとグループに適用される一般的な規則を示します。
ユーザーとグループに関する規則
ローカル データベース
Windows ドメイン
ユーザーは、グループのメンバーになる必要はなく、個人としての権限設定を持つことができる
* 
適用外
グループ内のすべてのユーザーは、そのグループに定義された権限を持つ
* 
* 
ユーザーは、グループのメンバーになる場合には、個人としての権限を持たない
* 
* 
ユーザーの権限は PUBLIC グループの権限と結合される
* 
適用外
グループの権限は PUBLIC グループの権限と結合される
* 
* 
ユーザーは、一度に 1 つのグループ(PUBLIC グループはカウントしない)だけのメンバーになることができる
* 
* 
グループは別のグループのメンバーになることができない
* 
* 
詳細については、『Zen User's Guide』のユーザーとグループの作業を参照してください。
SQL および Zen のセキュリティ
SQL スクリプトを使ってリレーショナル エンジンのセキュリティを管理する場合は、『SQL Engine Reference』の以下のセクションに役立つ情報が記載されているのでご覧ください。
ビューおよびストアド プロシージャに対する権限
ALTER GROUP
ALTER USER
CREATE GROUP
CREATE USER
DROP GROUP
DROP USER
GRANT
REVOKE
SET PASSWORD
SET SECURITY
psp_groups
psp_procedure_rights
psp_table_rights
psp_view_rights
psp_users
複数のデータベースのデータにアクセスする
1 つの接続内の複数のデータベースが同じマシン上に存在する場合には、SQL アプリケーションはそれらのデータベース内のデータにアクセスできます。ただし、一度にログインできるデータベースは 1 つのため、ログインしていない別のデータベースにアクセスできるかどうかは両方のデータベースのセキュリティ設定によります。
表 21 セキュリティ設定に基づくデータベースのアクセス権
ログインしているデータベースのセキュリティ
もう 1 つのデータベースのセキュリティ
もう 1 つのデータベースへのアクセス
有効
なし
すべての権限/権利を使用したアクセスが可能です。
有効
有効
データベースは、ログインしているデータベースと同じユーザー名とパスワードを使用します。
もう 1 つのデータベースに設定されている権限/権利を使用したアクセスが可能です。
有効
有効
データベースは、ログインしているデータベースと異なるユーザー名とパスワードを使用します。
アクセスは拒否されます。
無効
有効
アクセスは拒否されます。
MicroKernel エンジンのセキュリティ モデル
Zen では、Btrieve アプリケーションは、次の表に示す認証設定および許可設定を使用できます。
Btrieve セキュリティ
認証
許可
クラシック
オペレーティング システム
ユーザー名とパスワード
ファイル システムに対する権限
オーナー ネーム(省略可能)
ローカル データベース認証によってセキュリティ保護されたデータベース
Zen ユーザー
オペレーティング システムやドメインとは無関係のユーザー名およびパスワード
Zen ユーザー権限/権利
Zen グループ権限(省略可能)
PUBLIC 権限(省略可能)
オーナー ネーム(省略可能)
Windows ドメイン認証によってセキュリティ保護されたデータベース
Active Directory ユーザー
ユーザー名とパスワード
Zen データベース グループと同じ名前を持つドメイン権限グループに割り当てられたユーザー
Zen グループ権限(必須)
PUBLIC 権限(省略可能)
オーナー ネーム(省略可能)
個々のユーザー権限/権利なし
混合
オペレーティング システムまたはドメイン
ユーザー名とパスワード
個々のユーザー権限/権利(ローカル データベース セキュリティを使用する場合)
グループ権限(Windows ドメイン セキュリティを使用する場合)
PUBLIC 権限(省略可能)
オーナー ネーム(省略可能)
これらの設定について、以降のセクションでさらに詳しく説明します。
Btrieve のクラシック セキュリティ
Btrieve の混合セキュリティ
Btrieve ファイルのデータベース セキュリティ
Btrieve のクラシック セキュリティおよび混合セキュリティに関する注意事項
Btrieve の混合セキュリティおよびデータベース セキュリティに関する注意事項
Btrieve の混合セキュリティやデータベース セキュリティの設定
オーナー ネーム
これらのセクションは、MicroKernel エンジンを呼び出すアプリケーションにのみ適用されます。「資格情報」、「ログイン資格情報」、または「ユーザー資格情報」とは、有効なユーザー名とパスワードのことです。
MicroKernel エンジンに対する Zen データベースの認証および許可は、オペレーティング システムに対して依存させるか、または独立させるかを設定できます。Btrieve ユーザーにデータ ファイルへのオペレーティング システム アクセスが許可されていなくても、そのユーザーにデータベースヘのアクセスを許可できます。
Btrieve のクラシック セキュリティ
クラシック セキュリティは、本データベースのすべてのリリースで提供されている Btrieve セキュリティ モデルです。Btrieve ユーザーの場合、認証はオペレーティング システムによって実行され、データ アクセス権限は当該ユーザーのファイル システム権限によって決定されます。ユーザーには Btrieve 経由でファイルにアクセスするための同様の権限があります。オペレーティング システムによって制御される別の種類のファイルに対してもその権限があります。
Btrieve オーナー ネームは、個々のファイルに対するアクセスを制限することによって、別のセキュリティ レイヤーを追加できます。詳細については、オーナー ネームを参照してください。
Btrieve のクラシック セキュリティの設定
クラシック セキュリティでは、アプリケーションのユーザーおよびアクセス権限の設定は、オペレーティング システムのユーザーを作成し、ファイルおよびフォルダーへの権限を割り当てるだけで行うことができます。これら以外の操作を行う必要はありません。
Btrieve の混合セキュリティ
Btrieve の混合セキュリティは、ユーザーにオペレーティング システム ファイルへの権限を付与せずに、Btrieve データ ファイルへのアクセス権を提供します。このオプションを使用できる環境は、ファイルを指定する URI や API ログインを使用するように Btrieve アプリケーションを変更できないようにセキュリティを強化している環境です。
混合セキュリティ モデルでは、Btrieve の Open 要求が発生すると、データベース エンジンは DefaultDB という名前の特別なデータベースに登録されているユーザーのリストに照らして、オペレーティング システム ユーザーを認証します。オペレーティング システムがユーザーを認識すると、データベース エンジンはデータベースの権限テーブルを使って、開こうとしているファイルへの当該ユーザーのアクセス権を決定します。このため、ユーザーの権限が、そのユーザーが使用しようとしているデータベース内に定義されている必要があります。オペレーティング システムの権限に関係なく、データベース エンジンはその権限を適用します。
Btrieve アプリケーションのデータベース許可は、リレーショナル エンジン セキュリティ モデルを拡張することによって提供されているため、Btrieve アプリケーションでも使用できます。ユーザーとグループを作成、定義して権限を設定する機能は、ZenCC によって、また、GRANT、REVOKE、ALTER GROUP、CREATE USER、ALTER USER、DROP USER などの SQL ステートメントによっても提供されます。
混合セキュリティ モデルにおいて、ローカル データベース認証と Windows ドメイン認証は多少異なります。混合セキュリティ モデルでは、DefaultDB データベースに定義されているユーザー名はすべて、オペレーティング システムに定義されているユーザー名と一致していなければなりません。データベース エンジンは、Btrieve ファイルの作成中やオープン操作中は、入力されたユーザー名とパスワードを認証用にオペレーティング システムに渡すだけです。オペレーティング システムが資格情報を認証したら、データベースはユーザー個人の権限またはそのユーザーが割り当てられているグループの権限を使用します。個々のユーザーまたはグループの権限を定義する代わりに、PUBLIC グループを使えば、それらの権限を一度に定義することができます。
Windows ドメイン認証との混合セキュリティでは、Active Directory 内のグループ名はデータベースに定義されているグループと同じである必要がありますが、ユーザー メンバーシップは Active Directory 内でのみ処理されます。データベース エンジンは、Btrieve ファイルの作成中やオープン操作中は、、ユーザーが入力したユーザー名とパスワードを認証用にネットワークに渡します。ネットワークが資格情報を認証したら、データベースはユーザーに割り当てられているグループを使って権限を決定します。データベースにユーザーを追加する必要はありません。事実、ZenCC には[ユーザー]ノードが表示されなくなっています。様々なグループの権限を定義する代わりに、PUBLIC グループを使えば、それらの権限を一度に定義することができます。
混合セキュリティの設定手順については、Btrieve の混合セキュリティやデータベース セキュリティの設定を参照してください。
Btrieve のクラシック セキュリティおよび混合セキュリティに関する注意事項
ワークグループ エンジンはオペレーティング システム認証を実行しないため、ワークグループ エンジンを使用している場合の、クラシックおよび混合セキュリティ ポリシーの動作は同じです。ワークグループ エンジンを使って Btrieve データベースをセキュリティで保護したい場合は、データベース セキュリティ ポリシーを選択し、必要なユーザーやグループをすべて設定する必要があります。
Btrieve ファイルのデータベース セキュリティ
Btrieve ファイルのデータベース セキュリティでは、アプリケーションが Btrieve ログイン オペレーションを実行するか、Btrieve URI を使って Open オペレーションのファイルを指定する必要があります。どちらの場合も、データベースはログインまたは URI の中から参照されます。このデータベースは、指定されたユーザーに権限を付与します。Btrieve データベース セキュリティでは、Zen データベースは、ローカルの Zen データベースに定義されたユーザーのリストと照合するか、あるいはユーザーが Zen データベース内のグループと同じ名前を持つ権限グループのメンバーになっている Windows Active Directory に定義された、ネットワーク ログインのリストと照合することで、ユーザーを認証し、それらのユーザーに対して Btrieve データ ファイルへのアクセスを許可します。後記する 1 つの例外を除いて、ユーザーがデータに接続しアクセスする権限は、そのユーザーが必要なアプリケーションを実行するシステムに正常にログインできる限り、ファイル システム権限とは関係ありません。データベースのユーザーとグループを定義して権限を設定する機能は、ZenCC によって、また GRANT や REVOKE などの SQL ステートメントによって提供されます。
メモ:新しいデータベースを作成する場合は、ユーザーはオペレーティング システムで管理者権限を持っている必要があります。
Btrieve の混合セキュリティおよびデータベース セキュリティに関する注意事項
混合またはデータベース セキュリティ モデルは、当該データベースに属するものとして定義されているディレクトリに存在する Btrieve データ ファイルでのみ使用できます。このデータベースには、デフォルトのデータベースと現在のデータベースに記載されているデフォルト データベース DefaultDB も含まれます。データベースと関連付けられていないディレクトリにあるデータ ファイルにはアクセスできません。
これらのセキュリティ モデルの主な利点の 1 つは、ユーザーのデータ ファイルへの直接アクセスを制限する一方で、データベース エンジンを介したデータ アクセスにはフル アクセスを許可できることです。対照的にクラシック モデルでは、データ ファイルへのレコードの追加が許可されているユーザーは、必ずオペレーティング システムからもデータ ファイルのコピー、削除ができなければなりません。
Btrieve の混合セキュリティやデータベース セキュリティの設定
混合セキュリティまたはデータベース セキュリティに移行するには、多数の選択を行った上、慎重に計画を立てる必要があります。既に確立している環境では、お使いの製品環境が混乱しないように、Btrieve ファイルをデータベースにまとめる方法を考え、移行の予定を立てる必要があるかもしれません。
デフォルトのクラシック セキュリティから混合またはデータベース セキュリティに移行する手順については、『Zen User's Guide』のセキュリティの作業を参照してください。
オーナー ネーム
オーナー ネームは、Btrieve データ ファイルへのアクセスを制限するために使用するバイト文字列です。オーナー ネームは、個々のファイルにアクセスできるようにするパスワードと考えることができます。さらに、Zen がファイルを暗号化すると、オーナ ネームはプライベート暗号化キーとして機能します。オーナー ネームはファイル ヘッダーに存在します。このオーナー ネームは、ファイルが暗号化されているかどうかにかかわらず、常に暗号化されます。一般のパスワードと同様に、オーナー ネームでは大文字と小文字が区別されます。
サポートされているすべての Zen データベース エンジンのリリースでは、ファイルに対して 1 ~ 8 文字の ASCII 文字の「短い」オーナー ネームを設定する機能が提供されます。アクセス制限に加え、短いオーナー ネームは、Function Executor の[暗号化ファイル]設定や Maintenance ツールの[ファイルのデータを暗号化する]設定を選択した場合に、独自の暗号化を適用するために使用されます。
Zen 10.10 から、1 ~ 24 文字の ASCII 文字の「長い」オーナー ネームが導入されました。これにより、ファイル セキュリティが強化され、より強力な 128 ビット暗号化を使用できるようになりました。
Zen 13.30 では、AES-192 暗号化が追加され、16進数文字列の長いオーナー ネームがサポートされました。
Zen 14.00 では、長いオーナー ネームの最大 ASCII 文字数が 32 に延ばされ、それに応じて 16 進数の制限も拡張され、AES-256 暗号化が追加されました。
長いオーナー ネームとファイル暗号化の可能性を次の表に要約します。
 
Zen バージョン
長いオーナー ネーム
ファイルの暗号化
14.00
13.0 形式
1 ~ 32 文字の ASCII 文字
32 ~ 64 文字の 16 進数+0x または 0X のプレフィックス
9.5 形式
1 ~ 24 文字の ASCII 文字
32 ~ 48 文字の 16 進数+0x または 0X のプレフィックス
13.0 形式で、長いオーナー ネームが 25 ~ 32 文字の ASCII 文字であるか、50 ~ 64 文字の 16 進数であるファイルは、AES-256 暗号化を使用します。
13.0 形式で、長いオーナー ネームが 1 ~ 24 文字の ASCII 文字であるか、32 ~ 48 文字の 16 進数であるファイルは、AES-192 暗号化を使用します。
9.5 形式で長いオーナー ネームを持つファイルは、128 ビット暗号化を使用します。
13.30
13.0 形式
1 ~ 24 文字の ASCII 文字
32 ~ 48 文字の 16 進数+0x または 0X のプレフィックス
9.5 形式
1 ~ 24 文字の ASCII 文字
32 ~ 48 文字の 16 進数+0x または 0X のプレフィックス
13.0 形式で長いオーナー ネームを持つファイルは、AES-192 暗号化を使用します。
9.5 形式で長いオーナー ネームを持つファイルは、128 ビット暗号化を使用します。
10.10 ~ 13.20
9.5 形式
1 ~ 24 文字の ASCII 文字
9.5 形式で長いオーナー ネームを持つファイルは、128 ビット暗号化を使用します。
16 進数の長いオーナー ネームは以下の要件を満たす必要があります。
オーナー ネーム文字列は、先頭に文字 0x または 0X が付いている。
オーナー ネーム文字列は、16 進数の文字 0123456789abcdefABCDEF のみを使用し、スペースが入っていない。
ヌル文字(00 としてエンコードされる)を使用していない。
13.0 形式ファイルの場合の桁数は、32 ~ 64 文字とプレフィックス 0x または 0X を合わせて偶数である必要がある。9.5 形式ファイルの場合の桁数は、32 ~ 48 文字とプレフィックス 0x または 0X を合わせて偶数である必要がある。ここで留意する点は、プレフィックスは 16 進値を示すためだけに使用され、暗号化アルゴリズムでは使用されないということです。
長いオーナー ネームを持つファイルには、以下の制限が適用されます。
Zen v14 以降におけるオーナー ネーム文字列の暗号化はより強力になっているため、Zen v14 で長いオーナー ネームを割り当てられた 13.0 形式のファイルは、Zen v14 以降でのみ読み取り可能になります。これは、そのファイル自体が暗号化されているかどうかにかかわらず適用されます。9.5 形式のファイルは強力な暗号化を持たないため、影響を受けません。
10.10 バージョンより前の Zen は長いオーナー ネームをサポートしていないため、長いオーナー ネームを持つファイルを読み取ることができません。
ファイルを 9.5 より前のファイル形式にリビルドするには、まず、そのオーナー ネームを削除しておく必要があります。
メモ:オーナー ネームは、ネットワーク、システム、またはデータベース レベルで認証されるユーザー名とは関係ありません。たとえば、ファイル オーナー ネームの Master はデフォルト Master ユーザーとは異なります。
以下のトピックではより詳しい説明を提供します。
オーナー ネームを選択および設定する
オーナー ネームおよび SQL アクセス
オーナー ネームと暗号化
オーナー ネームの例
オーナー ネームを選択および設定する
Maintenance および Function Executor ツールで、ファイルのオーナー ネームを設定またはクリアすることができます。SQL スクリプトを使用して、テーブルのオーナー ネームを設定または管理することはできませんが、SET OWNER および GRANT ステートメントを使用すれば必要に応じてオーナーネームを提供できます。
ユーザーは、オーナー ネームが割り当てられたときに選択したオプション(次の表を参照)に応じてファイルにアクセスすることができます。
オプション
説明
読み取り専用
オーナー ネームを指定しなくても、ユーザーはデータ ファイルの変更を行わないデータ アクセス操作を行うことができます。
読み取り専用、暗号化
オーナー ネームを指定しなくても、ユーザーはデータ ファイルの変更を行わないデータ アクセス操作を行うことができます。このオプションを設定すると、データベース エンジンはオーナー ネームをキーに使用してファイルの全レコードを暗号化します。後から追加されるレコードも暗号化されます。
ノーマル
オーナー ネームを指定しないと、ユーザーはファイル アクセス操作を一切行うことができません。
暗号化のみ
オーナー ネームを指定しないと、ユーザーはファイル アクセス操作を一切行うことができません。このオプションを設定すると、データベース エンジンはオーナー ネームをキーに使用してファイルの全レコードを暗号化します。後から追加されるレコードも暗号化されます。
オーナー ネームおよび SQL アクセス
SQL データベースでテーブルとして機能するファイルに Btrieve オーナー ネームが設定されている場合に、そのテーブルにアクセスするには、そのデータベースでセキュリティが有効になっているかどうかによって、2 つある方法のうち、いずれかを使用します。セキュリティが無効な場合は、SET OWNER ステートメントをその他のテーブル アクセス試行より前に実行することにより、オーナー ネームを取得できます。セキュリティが有効な場合は、データベースの Master ユーザーは、そのテーブルに対するアクセス許可を任意のユーザー(Master ユーザー自身を含む)に発行する場合、GRANT ステートメントでオーナー ネームを提供する必要があります。
オペレーティング システムでオーナー ネームが含まれるファイルが読み取り専用の場合、Master ユーザーはオーナー ネームを使って自分自身に SELECT 権を特に付与しなくても、自動的に SELECT 権限を持ちます。この場合、他のユーザーには、この自動的に付与されるアクセス権はありませんが、Master ユーザーはオーナー ネームを提供しなくても SELECT 権限を付与することはできます。
オーナー ネームと暗号化
ファイルに暗号化を指定したオーナー ネームを最初に設定したときに、データベース エンジンはファイル全体を直ちに暗号化します。ファイルのサイズが大きくなるほど、暗号化には時間がかかります。
暗号化されたファイルに対するデータ アクセス操作は、暗号化されていないファイルに比べて時間がかかります。データベース エンジンは、ディスクからページを読み取る際にそのページを復号し、それをディスクに書き戻す前に再度暗号化する必要があります。
注意: ファイルのオーナー ネームを忘れたりなくしたりしないようにしてください。ファイル自体が暗号化されていなければ、Btrieve API を使ってそのファイルを読み取ることはできますが、オーナー ネームを指定せずに、ファイルに書き込むことはできません。ファイルのオーナー ネームは、ファイルの内容を調べても見つかりません。これは、ファイル データが暗号化されるかどうかにかかわらず、オーナー ネーム文字列が、その割り当て対象のファイルのヘッダーで常に暗号化されるからです。
オーナー ネームの例
Btrieve オーナー ネームを使用してファイルへのアクセスを許可する例については、『SQL Engine Reference』の GRANT を参照してください。
MicroKernel エンジンのセキュリティ計画
新しいデータベースではすべて、[Btrieve セキュリティ]設定はデフォルトで "クラシック" になります。つまり、データベース エンジンはオペレーティング システムを使って認証を行い、フォルダーとファイルの権限を使ってアクセスの許可を行います。オペレーティング システム認証でデータ ファイルへのアクセスが許可されているユーザーは、Btrieve オーナー ネームを使ってアクセスが制限されていない限り、ファイルに対する権限と同レベルの権限をファイルに含まれているデータ レコードに対しても持ちます。
以下のセクションでは、デフォルト データベースやアクセスを許可されたユーザーなど、Btrieve セキュリティ ポリシーの要素を設定する手順について説明します。
使用可能なオプション
ポリシーの選択
セキュリティを設定するための準備
処理の概要
使用可能なオプション
使用できるセキュリティ オプションは 3 つあります。これらのオプションのうち最適なオプションを選択できるように、各オプションの機能を次の表に示します。暗号化はどの設定でも任意です。
表 22 セキュリティ設定の機能比較
機能
クラシック
混合
データベース
ローカル データベース セキュリティを使用する場合は、管理者がユーザーごとにオペレーティング システム(OS)とデータベースのユーザー アカウントを別々に設定する必要がある。
 
* 
* 
データベースのユーザー アカウントは OS のユーザー アカウントから直接派生する。これは、Windows ドメイン認証によるデータベース セキュリティが使用される場合には常に該当する。
* 
* 
 
データ アクセス権はファイル システム権には関連付けられていない。管理者は、データベースのデータ アクセス権限を個々のユーザーまたはグループに割り当てる必要がある。
 
* 
* 
ユーザーのデータ アクセス権は、OS ユーザーのファイル システム権から直接派生する。
* 
 
 
Zen をベースとする Windows アプリケーションから、データベースのユーザー名とパスワードを入力する自動ログイン ダイアログを表示できる。
*1
*1
* 
データベースは OS にログインできたユーザーを有効なデータベース ユーザーとして受け入れる。
* 
* 
*2
ユーザーは、コンピューターにログインするのとは別にデータベースにログインする必要がある。
 
 
*3
1 ログイン ダイアログは、リクエスターがオペレーティング システムを介して ID を決定できない場合に現れます。
2 Windows ドメイン認証を使ってセキュリティ保護されたデータベースの場合。
3 ローカル データベース認証を使ってセキュリティ保護されたデータベースの場合。
Btrieve データベース セキュリティおよびリレーショナルのローカル データベース セキュリティの下では、データベースのユーザー アカウントはオペレーティング システムのユーザー アカウントとはまったく無関係です。
これとは対照的に、クラシック セキュリティでは、コンピューターへのログインに成功したユーザーは、データを含んでいるファイルに対してユーザーに割り当てられているファイル システム権限のレベルに従った、そのデータベース コンテンツへのアクセス権を持ちます。
最後に、Btrieve 混合セキュリティ ポリシーは、ほかの 2 つのポリシーの要素を持っています。この方式では、ユーザーはオペレーティング システムのユーザー名とパスワードを使ってログインしますが、データに対するユーザーのアクセス権はセキュリティ保護されたデータベースに設定されているユーザーまたはグループの権限によって決定されます。
ポリシーの選択
以下のセクションでは、複数のセキュリティ ポリシーの中から 1 つを選び出す上での主な判断材料のいくつかを述べます。
クラシックを選択する理由
ユーザーがデータ ファイルへのファイル システム アクセス権を持っていることを安心して受け入れられる。たとえば、データ ファイルからレコードを削除する権限を持っているユーザーは、オペレーティング システムからそのファイル自体を削除することもできます。
管理上の面倒な作業は最小限にしたい。各ユーザーの OS ユーザー アカウントと、少なくとも 1 つのデータベース アカウントの両方を設定することはしたくない。
各ユーザーのファイル システム権限によって異なる、さまざまなデータ アクセス権を持つ必要がない。
ユーザーにデータベースのログインを個別に行わせたくない。
混合を選択する理由
Btrieve ログインや、ファイルを開くための Btrieve URI パスを使用するように変更できない既存の Btrieve アプリケーションがある。
ユーザーにデータベースのログインを個別に行わせたくない。
有効なデータベース ユーザーには、オペレーティング システムにおけるデータ ファイルへのいかなる権限も持たせないようにしたい。たとえば、データベースに対するあらゆる権限を持っているユーザーに、オペレーティング システムからデータ ファイルを削除する権限を持たせないようにすることができます。
ローカル データベース セキュリティを使用しており、OS のユーザー アカウントと同じユーザー名のデータベース ユーザー アカウントを作成するつもりである。また、データベース ユーザーまたはデータベース ユーザーが所属する各グループに権限を割り当てるつもりである。選択すれば、特殊グループの PUBLIC から権限を継承することによって、すべてのユーザーが同レベルの権限を持つことができます。
Windows ドメイン セキュリティを使用しており、データベースに定義されている Zen グループと同じ名前の権限グループを Active Directory 内に作成するつもりである。また、各 Zen グループに権限を割り当てるつもりである。Active Directory では、権限は割り当てられず、ユーザーのグループ メンバーシップだけが割り当てられます。
データベースを選択する理由
Btrieve ログイン オペレーションや Btrieve URI パス形式を使用する Btrieve アプリケーションがある。
ユーザーにデータベースのログインを個別に行わせたい。これは、オペレーティング システムへのログイン後、ユーザーはもう一度データベースにログインする必要があるということです。この動作は、権限を与えられたコンピューター ユーザーの一部にはデータベースヘのアクセスが許可されているが、一部には許可されていない場合に有用です。
有効なデータベース ユーザーであっても、オペレーティング システムにおけるデータ ファイルへの権限を持たせないようにしたい。たとえば、データベースに対するあらゆる権限を持っているユーザーに、オペレーティング システムからデータ ファイルを削除する権限を持たせないようにすることができます。これは、混合セキュリティ ポリシーを使っても実現できます。
データベースのユーザー アカウントには、オペレーティング システムのアカウントとは異なる名前を使いたい。たとえば、オペレーティング システムのユーザー jsmith が john としてデータベースにログインすることを要求されるかもしれません。
ユーザーとその権限は、サーバーやマシンでなくデータベースの下にある。これにより、データベースのユーザーやユーザーの権限を再作成しなくても、データベースをあるマシンから別のマシンへ移動することができます。
セキュリティを設定するための準備
MicroKernel エンジンのセキュリティ設定は 1 つの簡単な処理です。しかし、この処理には十分な柔軟性があるため、いくつかの準備を必要とします。このセクションでは、Btrieve セキュリティの設定を開始する前に知っておくべき情報について説明します。
Btrieve アプリケーションでデータにアクセスする方法
アプリケーションが Btrieve ログイン オペレーションを使用したり URI でファイルを開いたりするように変更されているか、変更可能な場合は、データベース セキュリティまたは Btrieve の混合セキュリティを選択できます。どちらを選択した場合でも、セキュリティで保護するデータベースは ZenCC に登録されます。アプリケーションで Btrieve ログインや URI を使用しない場合にアクセス権を管理するには、混合セキュリティを選択して、DefaultDB データベースを設定します。
データベースの数
混合またはデータベース セキュリティの場合は、すべてのユーザーに同レベルの権限を割り当てるか、もしくはデータベースごとに定義済みユーザーのセットを作成する必要があります。
まったく関連のないデータの本体を含んでいる Btrieve データ ファイルが 2 つ以上ある場合は、別個のデータベースを 2 つ以上設定し、それぞれに固有の許可されたユーザーのセットを持ちたいと思われるかもしれません。しかし、一般的に言えば、定義済みユーザーのセットを複数作成して管理する必要がないよう、別々にするデータベースの数は最小限にしたいでしょう。ほとんどの場合は、1 つのデータベースで十分です。データベースにおけるユーザー権限では、各ユーザーのデータベースへのアクセスを規制できるため、ある特定のユーザーのアクセスを制限するためだけに別のデータベースを作成する必要はありません。
1 つのデータベースのみが必要であると判断した場合は、既存のデータベース DefaultDB を Btrieve ファイルと関連付けられているデータベースとして使用することができます。そうではなく、独自の名前を付けたデータベースを設定することもできます。
データ ファイルの場所
名前付きデータベースのデータ ディレクトリに、データ ファイルが格納されているディレクトリを指定することによって、Btrieve データ ファイルをデータベースと関連付けます。そのため、データベースと関連付けるすべてのデータ ファイルが格納されているディレクトリを知っておく必要があります。データ ファイルがすべて特定のディレクトリのサブディレクトリ ツリーに存在する場合は、トップレベルのディレクトリのパス名さえわかっていれば十分です。ハード ディスク ドライブ上のすべてのデータ ファイルを含めたい場合は、"C:\" を使用することもできます。
ユーザー名の使用方法
ローカル データベース認証との混合セキュリティを使用する予定ならば、すべてのユーザーに同一の権限を割り当てるか、もしくは異なる権限を持つユーザーのユーザー アカウントを設定する必要があります。個々のユーザーを設定するつもりならば、データベース ユーザー名にしたいオペレーティング システム ユーザー名の一覧が必要です。データベース ユーザー名は、オペレーティング システム ユーザー名と完全に一致している必要があります。
Windows ドメイン認証との混合セキュリティを使用する予定ならば、すべてのユーザーに PUBLIC グループの同一権限を割り当てるか、もしくは異なる権限を持つ複数の Zen ユーザー グループを作成する必要があります。どちらの場合も、ネットワーク グループ名の一覧が必要です。このネットワーク グループ名をデータベース グループ名としてコピーします。データベース グループ名はネットワーク グループ名と一致している必要があるためです。
セキュリティ ポリシーとは?
セキュリティを設定する前に、使用する予定のポリシーがどういうものであるかを知っておく必要があります。セットアップ処理はポリシーによって若干異なります。ポリシーを選択する上での考慮点は、ポリシーの選択に記載されています。
処理の概要
データベースのセキュリティを設定する手順の概要を以下に示します。手順の詳細については、MicroKernel エンジン セキュリティのクイック スタートで説明しています。
1 準備をします。セキュリティを設定するための準備の説明に従って、必要な情報を収集し、開始するために必要な決定を行います。データベースの数はいくつにしますか?Btrieve ファイルが保存されている場所は?ユーザー名は何ですか?どのセキュリティ ポリシーを使用しますか?
2 Btrieve ファイルとともに使用するデータベースを選択し、そのデータベースにデータ ファイルの場所を示すデータ ディレクトリを設定します。この手順は、混合またはデータベース セキュリティでのみ必要となります。
この手順の詳細については、『Zen User's Guide』の定義済みの DefaultDB も含め、既存のデータベースを Zen ファイルと使用するにはを参照してください。
3 セキュリティを有効(オン)にします。
この手順の詳細については、『Zen User's Guide』の Zen エクスプローラーを使用してセキュリティを有効にするにはを参照してください。
4 ユーザー(および必要に応じてグループ)を作成し、SQL ステートメントまたは ZenCC を使ってユーザー(およびグループ)に対して権限を設定します。この手順は、混合セキュリティまたはデータベース セキュリティでのみ必要となります。
ユーザーのアクセス権を付与する最も簡単な方法については、『Zen User's Guide』の Zen エクスプローラーを使用してすべてのユーザーに権限を割り当てるにはを参照してください。
5 データベースの Btrieve セキュリティに[混合]または[データベース]を設定します。
この手順の詳細については、『Zen User's Guide』のデータベースのセキュリティ ポリシーを設定または変更するにはを参照してください。
6 オペレーティング システムでデータ ファイルをセキュリティ保護します。混合またはデータベース セキュリティの場合、これでユーザーは、オペレーティング システムにおけるデータ ファイルへのアクセス権を何も持っていなくても、データにアクセスできるようになります。ファイルへのセキュリティ保護されたアクセスに関する情報は、オペレーティング システムのドキュメントを参照してください。
MicroKernel エンジン セキュリティの作業の概要
次の表は、異なるセキュリティ モデルを使用するために必要となる作業の基本レベルを示しています。セキュリティ モデルを実装するために必要な作業については、『Zen User's Guide』のセキュリティの作業を参照してください。
セキュリティ モデル
認証/許可
動作および高レベル セットアップ作業の概要
クラシック
オペレーティング システム/オペレーティング システム
ユーザーにすべてのデータベース ファイルへのファイル アクセス権限を付与します。
よりアクセスを制限するために、Btrieve ファイルにオーナー ネームを追加します(任意)。
混合
オペレーティング システム/データベース
オペレーティング システムでユーザーを作成します。このユーザー名とパスワードと対照することで、ユーザーが認証されます。
ZenCC を使って、データベース内の複数のドメインに同じ名前のユーザーを作成します。認証は OS によって行われますが、権限はデータベースに格納されるため、OS のユーザーやドメイン グループはデータベース内のユーザーやグループと一致する必要があります。
ZenCC または SQL ステートメントを使って、ユーザーやグループの権限を定義します。もう 1 つの方法として、PUBLIC グループに権限のセットを定義します。認証されたすべてのユーザーは、PUBLIC と同様の権限を持ちます。どのユーザーも、PUBLIC に与えられた権限より低い権限を持つことはありません。
ワークグループ エンジンでは、このセキュリティ モデルはクラシック セキュリティ モデルと同様に動作します。
データベース
データベース/データベース
オペレーティング システムのユーザー名とパスワードは、Zen データベース セキュリティとは関係ありません。
ZenCC または SQL ステートメントを使って、ユーザーやグループを定義します。
ZenCC または SQL ステートメントを使って、データベース権限を定義します。
MicroKernel エンジン セキュリティのクイック スタート
このセクションでは、オペレーティング システムで Btrieve データ ファイルをセキュリティ保護する一方、データベース ユーザーには引き続きデータへのアクセスを許可するための、最も簡単な方法についての手順を説明します。
この手続きが完了したら、アプリケーションを介してデータにアクセスするためのデータベース ユーザー権利に影響を与えることなく、データ ファイルに対するオペレーティング システム ユーザー権利を取り消すことができます。
メモ:データベース エンジンがインストールされているコンピューターに、管理者権限を持つオペレーティング システム ユーザーとして、または Zen_Admin セキュリティ グループのメンバーであるユーザーとしてログインする必要があります。
1 Zen Control Center(ZenCC)を起動します。ZenCC の起動方法については、『Zen User's Guide』の Windows での ZenCC の起動を参照してください。
2 混合セキュリティを使用する場合、以下の手順で使用するデータベースは DefaultDB になります。データベース セキュリティを使用する場合は、お使いのデータベースが ZenCC に登録されていることを確認してください。データベース エンジンの登録方法については、『Zen User's Guide』のリモート サーバー エンジンを登録するにはを参照してください。
3 使用するデータベースが DefaultDB とアプリケーションのデータベースのどちらである場合も、データベースのノードの左にある展開アイコンをクリックします。
4 ZenCC で、データベース DefaultDB を右クリックしてから[プロパティ]をクリックします。
5 ディレクトリ ノードを選択し、[新規]ボタンをクリックします。
6 Btrieve ファイルのパスを入力したら[OK]をクリックし、その後[適用]をクリックします。
ファイルが複数のディレクトリに散在している場合は、ファイルすべてに共通の上位ディレクトリを指定します。必要であればルート レベルを指定することもできますが、そうすると、ルート レベルとその下位ディレクトリにあるすべての Btrieve ファイルが DefaultDB に含まれてしまいます。たとえば、Windows の場合のルート レベルは C:\ となります。『Zen User's Guide』の定義済みの DefaultDB も含め、既存のデータベースを Zen ファイルと使用するにはを参照してください。
すべてのディレクトリを入力する必要はありません。データベースに含めたい Btrieve ファイルすべてに共通する最下位のディレクトリのみ入力します。
7 このデータベースのセキュリティを有効にします。それには、[プロパティ]のツリーで[セキュリティ]ノードをクリックします。
8 [Btrieve セキュリティ]タブをクリックし、"混合セキュリティ" または "データベース セキュリティ" を選択します。
9 [データベース セキュリティ]タブをクリックし、"ローカル データベース認証" または "Windows ドメイン認証" オプションを選択します。
10 Master ユーザーに使用するパスワードを入力します。指示に従って、2 回入力します。
これでセキュリティは有効になりました。しかし、ユーザーは現在のところ以前と同様のアクセス権を持っているため、デフォルトでは OS のユーザー権利に基づいてアクセスが行われます。次の段階では、この状況に対処します。
パスワードは最大 8 バイトに制限されているので注意してください。パスワードには、セミコロン(;)と疑問符(?)以外のあらゆる表示可能な文字を使用できます。
11 OK]をクリックして、[プロパティ]ダイアログを閉じます。
12 お使いのデータベースの下の[グループ]を展開(ノードの左にある展開アイコンをクリック)し、グループ PUBLIC を右クリックします。
13 プロパティー]をクリックした後、ツリーで[権限]をクリックします。
14 [データベース]タブをクリックします。
15 必要な権限をクリックします。
たとえば、すべての認証ユーザーに読み取り専用の権限を付与したい場合は、[選択]をオンにします。このオプションにより、データの読み取り専用の権限がすべてのユーザーに与えられます。すべてのユーザーに更新権限を付与する場合は[更新]をオンにし、その他同様に行います。
ユーザーによって異なる権限を付与する場合は、グループ アカウント(ドメイン認証を使用する場合)または個々のユーザー アカウント(ローカル データベース認証を使用する場合)を作成する必要があります。これは、SQL で GRANT ステートメントを使用するか、または ZenCC を使用して行います。詳細については、『Zen User's Guide』のセキュリティの作業を参照してください。
16 OK]をクリックします。
17 お使いのオペレーティング システムの手順に従って、オペレーティング システムでデータ ファイルをセキュリティ保護します。これで、データベース エンジンを介してデータにアクセスする能力に影響を与えることなく、オペレーティング システム ユーザーがデータ ファイルに対するあらゆる権限も持つことを拒否できるようになりました。
注意: 必ずオペレーティング システムでデータ ファイルをセキュリティ保護してください。この手順を実行しないと、ユーザーは依然としてこの処理より前の段階と同じレベルの権限によって、オペレーティング システムからファイルにアクセスできてしまいます。ユーザーが直接ファイルを変更、削除できないようにするには、ユーザーのデータ ファイルに対するオペレーティング システム権限を取り消す必要があります。
ネットワーク上のデータの暗号化
Zen では、Zen とそれを呼び出すアプリケーションの間のネットワーク トラフィックを暗号化することができます。この種の暗号化は、多くの場合「ワイヤ暗号化」と呼ばれます。これは、データがネットワーク ワイヤ上、あるいはワイヤレスも含め、あらゆるネットワーク インフラストラクチャ上を通るときに保護されるからです。ワイヤ暗号化の使用が要求されていないときは、アプリケーションによって送信されるデータへの不正アクセスに対する追加の抑止力を提供します。
Zen のワイヤ暗号化は、特定のセキュリティ モデルとは関係ありません。どの Zen セキュリティ設定も、ワイヤ暗号化をオンにして、またはオンにしないで使用できます。このトピックの残り部分では、以下の項目について説明します。
ワイヤ暗号化の設定プロパティ
ワイヤ暗号化に関する注記
暗号化を設定する
暗号化の影響
ディスク上のファイルの暗号化
ワイヤ暗号化の設定プロパティ
ワイヤ暗号化に関連する設定は 2 つあります。これらの設定は、サーバーはもちろん、各クライアント マシンで設定する必要があります。これらの設定の詳細については、以下のトピックを参照してください。
ワイヤ暗号化
ワイヤ暗号化レベル
ワイヤ暗号化の設定にアクセスするには
1 ZenCC で、次のいずれかを実行します。
サーバーの場合は、[エンジン]ノードの下にあるサーバー名を右クリックします。プラス(+)記号をクリックすると、ノードを展開させることができます。
クライアントの場合は、[ローカル クライアント]ノードの下にある[MicroKernel ルーター]を右クリックします。
2 プロパティ]をクリックします。
3 ツリーで[アクセス]をクリックします。
ワイヤ暗号化に関する注記
Zen では、ネットワーク経由でデータを渡す前にデータの暗号化を行うために、Blowfish という有名かつ実績のあるパブリック ドメイン アルゴリズムを使用します。この手法では 40 ビット、56 ビット、および 128 ビットのキーを実装します。40 ビット キーを使用する暗号化では、最少量の保護がデータに提供されます。56 ビット キーまたは 128 ビット キーを使用する暗号化では、解析が次第に困難になります。
暗号化と複合化の実行にはある程度のプロセッサ時間が必要なので、暗号化を使用するすべてのセキュリティと同様に、抑止力が向上すればパフォーマンスは低下します。
以前のバージョンとの互換性
ワイヤ暗号化をサポートしていない旧バージョンの Zen は、暗号化を提供する新しいリリースのクライアントまたはサーバーと通信することができません。暗号化をサポートしていないクライアントまたはサーバーは、暗号化を使用するクライアントまたはサーバーに接続しようとすると、エラーを返します。
暗号化を設定する
お使いの環境で暗号化の設定をオンにする前に、まず暗号化の必要性についてお考えください。状況に応じて、暗号化環境を次の 4 つの方式から選択できます。
暗号化なし
すべての通信を暗号化
特定のクライアントとの通信を暗号化
特定のサーバーとの通信を暗号化
暗号化なし
まず最初に、そのデータに暗号化が必要であると考えられる特性があるかどうかを検討します。データは機密か?権限のないユーザーの管理下にあって利用価値のあるデータか?組織に危害を加えるために利用することができるか?これらの質問やその他類似する質問の答えが「いいえ」である場合は、データを暗号化する必要はまったくなさそうです。このような状況では、暗号化を必要とする代わりにパフォーマンスが低下することを受け入れるメリットがありません。確信が持てない場合は、データ セキュリティのエキスパートにご相談ください。
データを保護する必要があるとしても、まだ暗号化する必要はない可能性があります。アプリケーションを LAN 上で単独に実行しており、ネットワークの既存のセキュリティに満足しているのであれば、暗号化を実行しても利点がない可能性があります。
特定のクライアントとの通信を暗号化
次に、あなたのデータベースに接続する大口の取引先がリモート サイトにあるとします。リモート クライアントとの通信でのみ暗号化を使用したいと思われるかもしれません。これは、リモート クライアントの[ワイヤ暗号化]を[常時]に設定し、そのリモート クライアントがアクセスするサーバー値を[必要な場合]に設定することによって実現できます。内部クライアントはすべて[しない]に設定します。このようにして、サーバーは、暗号化を要求するリモート クライアントと通信する場合にのみ暗号化を使用するようになります。
特定のサーバーとの通信を暗号化
立場が逆転して、お使いの環境に 1 つ以上のリモート サーバーが入っており、それらのサーバーはあなたが 100% 信頼していないネットワーク インフラストラクチャによってアクセスされているものとします。この場合は、それらのサーバー値を[常時]に設定し、ローカル クライアント値を[必要な場合]に設定することができます。そうすると、暗号化を要求するリモート サーバーとの通信のみが暗号化されます。
すべての通信を暗号化
最後に、Zen アプリケーションを頻繁に WAN や VPN、またはその他の完全に信頼していない外部ネットワーク上で実行している場合は、データベース通信を 100% 暗号化したいと思われるかもしれません。この状況では、すべてのクライアントとサーバーで、[ワイヤ暗号化]を[常時]に設定します。
暗号化レベルの選択
クライアントおよびサーバーは暗号化された通信を必要とするという結論に達したら、どの抑止レベルが要望に沿うかを決定する必要があります。
Actian Corporation は、お客様の特定の要望に沿った暗号化レベルについてアドバイスすることはできませんので、お客様が適切なデータ セキュリティ専門家を交えて検討される際に情報提供できるよう、いくつかのガイドラインを用意しています。これらのガイドラインは、暗号化されたデータを第三者から読み取られたりデコードされたりしないことを Actian Corporation が保証するものではありません。あらゆる暗号化方式と同様に、「解読できない」コードの類はありません。暗号化の種類によって解析する難易度が変化するだけです。Zen で使用する 128 ビット暗号化は、極めて専門的な個人ハッカーが持てる技術と設備をもってしても、デコード(復号)することが非常に困難であると認められています。
低度(40 ビット)暗号化
データが渡ってはいけない人の手に渡ってしまったとしても、そのデータによって組織や顧客が被る被害レベルがそれほど深刻でない場合には、この暗号化レベルの使用を検討してください。低度の暗号化を検討するもう 1 つの判断材料は、単純に、データがワイヤを通っている最中に不用意なネットワーク監視者にデータを読み取られたくないかどうかということです。
中度(56 ビット)暗号化
セキュリティに無頓着な監視者に備えてもっと強力な保護が何か必要であると確信しているが、最強レベルのセキュリティが必要だとは思わないような状況では、この暗号化レベルの使用を検討してください。
高度(128 ビット)暗号化
データにクレジット カード番号、社会保障番号、金融口座番号、または法律で保護されているその他の情報など、非常に秘匿性の高い情報が含まれているような状況では、この暗号化レベルの使用を検討してください。特に、お使いのデータベースが、インターネット ショッピング Web サイトやオンライン証券会社 Web サイトなど、慎重を期するデータを含んでいることで知られるネットワークのエンティティと関連付けられている場合には、この暗号化レベルを考慮してください。また、所属する組織が以前にデータ セキュリティを解析されそうになったことがある場合には、この暗号化レベルを検討してください。
暗号化の影響
暗号化を使用すると、クライアント/サーバーのパフォーマンスは低下します。暗号化をオンにした場合は、送信側でデータの各断片を暗号化し、受信側でそれをデコードする必要があります。暗号化なしで同様の操作を実行した場合と比べ、この処理には余分な CPU サイクルが必要となります。暗号化のレベルはパフォーマンスに影響しません。暗号化の使用によるパフォーマンスの低下は、3 つの暗号化レベルのうちどれを選択しても、おおよそ同じです。
ディスク上のファイルの暗号化
Zen を使用すると、データ ファイルをディスクに書き込む際に暗号化することができます。この機能を使用するには、各ファイルにオーナー ネームを設定し、暗号化オプションを選択する必要があります。詳細については、オーナー ネームを参照してください。