|
このセクションでは、SQL(リレーショナル)および Btrieve(トランザクショナル)で使用できるセキュリティ モデルについて説明します。両方のインターフェイスは、ユーザーに権限を割り当てる方法の選択に際して、同レベルの精度を共有しています。どちらのインターフェイスもデータベース セキュリティをサポートします。トランザクショナル インターフェイスには、アクセス許可の方法を決定するセキュリティ ポリシーが追加されています。リレーショナル インターフェイスは列レベルのセキュリティをサポートしています。
メモ
トランザクショナル インターフェイスのセキュリティ ポリシーを指定しても、リレーショナル インターフェイスのセキュリティには何ら影響ありません。しかし、説明上、トランザクショナル インターフェイス セキュリティで説明されているデータベース ポリシーと、リレーショナル インターフェイスのセキュリティは同じタイプであると考えてください。2 つのインターフェイスのセキュリティにおける主な違いは、リレーショナル インターフェイスのセキュリティ ポリシーを変更できないことです。セキュリティはオンかオフのいずれかです。オンの場合、セキュリティはトランザクショナル インターフェイス用のデータベース ポリシー タイプのセキュリティに類似しています。
リレーショナル インターフェイスの場合、セキュリティはオンかオフのいずれかです(上記の「メモ」を参照してください)。デフォルトで、セキュリティはオフになっています。セキュリティは、Master ユーザーのパスワードを指定することによってオンになります。
セキュリティをオンにしたら、PCC を使って最低でも、データベースヘのログインを許可するユーザーを定義する必要があります。ユーザーごとにオブジェクトの権限を設定することができます。さらに、ユーザーのグループを定義したり、各グループにオブジェクトの権限を設定することもできます。
『SQL Engine Reference』では、以下の内容がリレーショナル インターフェイス用のセキュリティに適用されます。
複数のデータベースのデータは、データベースが同じマシン上に存在するのであれば、アクセスできます。ただし、一度に 1 つのデータベースにしかログインできません。各データベースのセキュリティを基に、適用されるデータベース アクセスの状況を示します。
ログインしているデータベースのセキュリティ
|
ログインしていないデータベースのセキュリティ
|
説明
|
---|---|---|
オン
|
オフ
|
アクセスのすべての権利が付与されます。
|
オン
|
オン
|
ユーザー名とパスワードが、両方のデータベースでまったく同じでなければなりません。
|
オフ
|
オン
|
アクセスは拒否されます。
|
これ以降のセキュリティについての説明は、トランザクショナル インターフェイスにのみ当てはまります。リレーショナル インターフェイス以外の説明が不要であれば、データの暗号化へ進んでください。
トランザクショナル インターフェイスで使用可能な認証および許可モデルには、次のモデルがあります。
このセクション、およびこれ以降のセキュリティについて説明は、トランザクショナル インターフェイスのみを使用するアプリケーションに当てはまります。「資格情報」、「ログイン資格情報」、または「ユーザー資格情報」は、有効なユーザー名とパスワードの一組を指します。
Pervasive PSQL v11 SP3 では、OS に依存しないデータベース認証および許可の機能がトランザクショナル インターフェイスで利用できます。従来の(オペレーティング システム)認証モデルは本リリースでも今までどおり使用できますが、Btrieve のユーザーおよび権限がファイル システムのユーザーおよび権限から派生されない場合に、モデルを選択できるようになりました。ユーザーにデータ ファイルへのオペレーティング システム アクセスが許可されていなくても、そのユーザーにデータベースヘのアクセスを許可できます。
現在ある Btrieve アプリケーションは、アプリケーション コードに何ら変更を加える必要なく、新しいセキュリティ モデルを利用することができます。
クラシック セキュリティは、本製品の以前のリリースで提供された Btrieve セキュリティ モデルです。Btrieve ユーザーの場合、認証はオペレーティング システムによって実行され、データ アクセス権限は当該ユーザーのファイル システム権限によって決定されます。オペレーティング システムに依存しないデータベース エンジンで提供される唯一の許可機能は Btrieve オーナー ネームで、これは実質的にはファイル アクセス パスワードです。
このセキュリティ モデルでは、オペレーティング システムによって認証されるユーザーはみな、オペレーティング システムを介してデータ ファイルを読み書きする必要があるため、Btrieve を介してデータにアクセスする場合も同様の権限を持ちます。Btrieve オーナー ネームはこの規則の例外で、付加的な許可レベルを提供するものです。ただし、この許可レベルはユーザーの ID とは関連付けられません。アプリケーションまたはユーザーが指定されたファイルにオーナー ネームを供給できるかどうかということとのみ関連付けられます。
Btrieve オーナー ネームの詳細については、「オーナー ネーム」を参照してください。
クラシック セキュリティでは、データベースのユーザーおよびアクセス権限の設定は、オペレーティング システムでユーザーを作成し、ファイル権限を割り当てることによって行います。データベース エンジンを構成するために実行する別の操作はありません。
ユーザー アカウントの設定方法および権限の割り当て方法についての説明は、オペレーティング システムに付属のドキュメントを参照してください。
混合セキュリティ モデルでは、データベース ログインの発生時、データベース エンジンはユーザーが入力したユーザー名とパスワードをオペレーティング システムの認証サービスに渡します。オペレーティング システムがユーザー名とパスワードを認証した場合、データベース エンジンはデータベースのユーザーおよび権限テーブルを使って、当該ユーザーの具体的なアクセス権を決定します。したがって、各ユーザーのデータ アクセス権限をデータベース内に定義しておく必要があります。言い換えると、データベース エンジンは、当該ユーザーのデータ ファイルに対するファイル システム権限に関係なく、定義されている権限を適用します。
Btrieve アプリケーションのデータベース許可は、リレーショナル インターフェイスのセキュリティ モデルを拡張することによって提供されているため、Btrieve アプリケーションでも使用できます。ユーザーを定義し権限を設定する機能は、PCC によって、また、GRANT、REVOKE、ALTER GROUP、CREATE USER、ALTER USER、DROP USER などの SQL ステートメントによっても提供されます。
混合セキュリティ モデルでは、データベースに定義されているユーザー名はすべて、オペレーティング システムに定義されているユーザー名と完全に一致していなければなりません。データベース ログイン中は、データベース エンジンはユーザーが入力したユーザー名とパスワードを単にオペレーティング システムの認証モジュールに渡すだけです。オペレーティング システムが資格情報を認証した場合、データベースは自身のユーザーおよび権限テーブルを使って、当該ユーザーの具体的なアクセス権を決定します。各ユーザーをデータベースに追加する必要があります。各ユーザーのアクセス権を個別に定義する代わりに、デフォルト グループの PUBLIC を使って 1 度にアクセス権を定義することができます。有効なユーザーは、PUBLIC グループに付与されているアクセス権を自動的に継承します。
混合セキュリティ環境を設定する詳細な手順については、混合およびデータベース セキュリティの設定を参照してください。
データベース セキュリティ モデルでは、データベース エンジンが Btrieve データ ファイルのユーザーの認証と許可を行います。ユーザーがデータに接続しアクセスする能力は、そのユーザーがアプリケーションを実行するコンピューターに正常にログインできる限りは、オペレーティング システムのアカウント識別情報やファイル システム権限とは関係ありません。
Btrieve アプリケーションのデータベース認証および許可は、リレーショナル インターフェイスのセキュリティ モデルを拡張することによって提供されているため、Btrieve アプリケーションでも使用できます。ユーザーを定義し権限を設定する機能は、PCC によって、また GRANT や REVOKE などの SQL ステートメントによって提供されます。
メモ
新しいデータベースを作成する場合は、今までどおり、ユーザーはオペレーティング システムで管理者レベルの権限を持っている必要があります。
データベース セキュリティ環境を設定する詳細な手順については、混合およびデータベース セキュリティの設定を参照してください。
データベースごとにユーザーのセットを定義する必要があり、ユーザーごとにアクセス権限のセットを定義する必要があります。アクセス権を割り当てる最も簡単な事例は、特殊なグループの PUBLIC にアクセス権を割り当てることです。すべてのユーザーは PUBLIC からデフォルトのアクセス権を継承します。また、当該データベースのメンバーであると判断される必要のあるデータ ファイルが格納されているファイル システム ディレクトリを指定する必要があります。
データベース エンジン(または、混合セキュリティの場合はオペレーティング システム)は、ディレクトリ ツリー内にあるデータ ファイルへのアクセスが試行されるたびに、ユーザー認証および許可を実行します。データベースとディレクトリ間のこの関連付けがないと、Btrieve アプリケーションが特定のデータ ファイルを開こうとしたとき、データベース エンジンには定義済みのユーザーおよび権限の適切なセットを判断するためのデータベース コンテキストがありません。
混合またはデータベース セキュリティ モデルは、当該データベースに属するものとして定義されているディレクトリに存在する Btrieve データ ファイルでのみ使用できます。このデータベースには、「デフォルトのデータベースと現在のデータベース」に記載されているデフォルト データベース DefaultDB も含まれます。データベースと関連付けられていないディレクトリにあるデータ ファイルは、クラシック セキュリティ モデルでのみアクセスできます。
これらのモデルの主な利点の 1 つは、オペレーティング システム ユーザーのデータ ファイルへのアクセスを制限する一方で、データベース エンジンを介したデータ アクセスにはフル アクセスを許可できることです。対照的にクラシック モデルでは、データ ファイルへのレコードの追加が許可されているユーザーは、必ずオペレーティング システムからもデータ ファイルのコピー、削除ができなければなりません。
メモ
ワークグループ エンジンはオペレーティング システム認証を実行しないため、ワークグループ エンジンを使用している場合の、クラシックおよび混合セキュリティ ポリシーの動作は同じです。ワークグループ エンジンを使って Btrieve データベースをセキュリティで保護したい場合は、データベース セキュリティ ポリシーを使用する必要があります。
混合セキュリティまたはデータベース セキュリティに移行するには、多数の選択を行った上、慎重に計画を立てる必要があります。既に確立している環境では、お使いの製品環境が混乱しないように、Btrieve ファイルをデータベースにまとめる方法を考え、移行の予定を立てる必要があるかもしれません。
クラシック セキュリティから混合またはデータベース セキュリティへの変換方法に関する情報については、セキュリティの作業を参照してください。次のセクションでは、セキュリティの作業で取り上げる題材の概要について簡単に説明します。
オーナー ネームは、Btrieve ファイルのアクセスを得るために必要なパスワードです。オーナー ネームとシステム ユーザー名あるいはリレーショナル データベース ユーザー名との間に関連はありません。オーナー ネームは、ファイル パスワードと考えてください。
短いオーナー ネームは半角 8 文字までの範囲で指定できます。長いオーナー ネームは半角 24 文字までの範囲で指定できます。 ただし、長いオーナー ネームを指定した場合、そのデータ ファイルは Pervasive PSQL v10 SP1 より前のデータベース エンジンで読み取ることができないので注意してください。 また、長いオーナー ネームを使用したデータ ファイルは、v9.5 より前のファイル形式にリビルドしようとする場合、そのオーナー ネームを最初に削除しておかないとリビルドすることができません。オーナー ネームは、長いものでも短いものでも、その最大長(8 または 24 バイト)に満たない部分は空白が埋め込まれます。
PCC では現在、ファイルのセキュリティ プロパティを介してオーナー ネームを指定する方法は提供していません。ただし、PCC の SQL Editor で GRANT ステートメントを使ってオーナー ネームを設定することができます。『SQL Engine Reference』の「オーナー ネーム」を参照してください。Maintenance ユーティリティまたは Function Executor ユーティリティを使用して、ファイルのオーナー ネームを設定またはクリアすることもできます。「Maintenance を使用した Btrieve データ ファイルの操作」を参照してください。
オーナー ネームには、表 29 に示すように、いくつかの属性があります。
ファイルに暗号化を指定したオーナー ネームを最初に設定したときに、データベース エンジンはファイル全体を暗号化します。この処理はファイルが大きいほど時間がかかります。
暗号化されたファイルに対するデータ アクセス操作は通常のファイルに比べて時間がかかります。データベース エンジンは、ディスクからページを読み込むと暗号化された各ページを元に戻して解読し、ディスクに書き戻すときに再度暗号化します。
注意
暗号化が設定されている場合には特に、ファイルのオーナー ネームを忘れないよう記録しておいてください。オーナー ネームを見つける方法はありませんし、オーナー ネームなしでデータにアクセスする方法もありません。
保護されたデータベース内のテーブルであるファイルに Btrieve オーナー ネームが設定されている場合、データベースの Master ユーザーは、そのテーブルに対する権限を任意のユーザー(Master ユーザーを含む)に与える場合、GRANT ステートメントでオーナー ネームを使用する必要があります。
あるユーザーのためにオーナー ネームを含む GRANT ステートメントを発行すると、そのユーザーはデータベースにログインすることにより、毎回オーナー ネームを指定することなく、指定されたテーブルにアクセスすることができます。
Master ユーザーが GRANT ステートメントで正しいオーナー ネームを使ってテーブルに対する権限をあるユーザーに許可していなければ、そのユーザーが ODBC 経由でそのテーブルにアクセスを試みた場合、アクセスは許可されません。
テーブルが読み取り専用属性のオーナー ネームを持っている場合、Master ユーザーはオーナー ネームを使って自分自身に SELECT 権を特に許可しなくても、自動的に SELECT 権限を持ちます。
データ ファイルにオーナー ネームが設定されていない場合、そのファイルのリレーショナル セキュリティを有効にすると、ファイルへの Btrieve アクセスは許可されなくなります。ファイルのアクセス時にオーナー ネームの指定が可能なユーザーが Btrieve アクセスを回復できるように、そのファイルにオーナー ネームを設定する必要があります。この動作により、デフォルトの Btrieve ユーザーはリレーショナル セキュリティを迂回できなくなります。
Btrieve オーナー ネームを使用してファイルへのアクセスを許可する例については、『SQL Engine Reference』の「GRANT」を参照してください。
複数のデータベースのデータは、データベースが同じマシン上に存在するのであれば、アクセスできます。ただし、一度に 1 つのデータベースにしかログインできません。各データベースのセキュリティを基に、適用されるデータベース アクセスの状況を示します。
|