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