PSQL は、Btrieve や SQL ベースのアプリケーションで使用できる完全なリレーショナル データベース セキュリティを提供します。この章では、これら 2 つの関係と互いにどのように動作するのかについて説明します。

PSQL v12 で新しいデータベースを作成したとき、デフォルトでは、データベース セキュリティはオフになっています。 これは、Master ユーザーのパスワードを指定することによってオンになります。パスワードに関する制約については、識別子の種類別の制限の表を参照してください。

データベース セキュリティは、セキュリティをオンにしたときに、データベースヘのフル アクセス権を持つ Master という名前のデフォルト ユーザーが存在するかどうかに基づきます。デフォルトでは、Master ユーザーのパスワードは設定されていません。Master ユーザーのパスワードを指定すると、セキュリティが有効、つまりオンになります。

Master ユーザーは、グループやほかのユーザーを作成したり、作成したグループやユーザーにデータ アクセス権限のセットを定義することができます。ユーザーやグループは、SQL ステートメントを使用して、あるいは PSQL Control Center（PCC）を使用して追加できます。

すべてのユーザーに同様のアクセス権を付与したい場合は、それらのアクセス権を PUBLIC という名前の特殊なグループに付与することができます。 セキュリティをオンにすると、データベース エンジンは自動的に PUBLIC という特殊なグループを作成します。最初、PUBLIC には何のアクセス権も割り当てられていません。

PUBLIC はすべてのユーザーおよびグループにデフォルトのアクセス権を与えることから、特殊なグループと呼ばれます。データベース エンジンは常に、まず PUBLIC に割り当てられているアクセス権を調べます。PUBLIC のアクセス権の適用方法をわかりやすくするために 2 つの例を示します。

PCC で、PUBLIC に CREATE TABLE 権限を割り当てるとします。 次に、PCC で myuser という名前のユーザーを作成しますが、ユーザーのアクセス権にテーブルを作成するための個別の権限は含めないものとします。データベース エンジンは最初に PUBLIC のアクセス権を調べるため、この場合、テーブル作成の権限は PUBLIC から付与されることになり、myuser はテーブルを作成できます。

逆に言えば、PUBLIC にアクセス権が付与されていない場合は、個々のユーザーまたはグループに付与されているアクセス権が適用されます。たとえば、PCC で、PUBLIC に CREATE TABLE 権限を割り当てないとします。ユーザーまたはユーザーが属するグループのアクセス権がテーブルの作成を許可しない限り、どのユーザーもテーブルを作成できません。

データベース セキュリティをオンにしたら、グループとユーザーを定義することができます。PCC の PSQL エクスプローラー にグループおよびユーザーのノードが現れます。『PSQL User's Guide』のユーザーとグループの作業を参照してください。

このセクションでは、MicroKernel エンジンおよびリレーショナル エンジンで使用できるセキュリティ モデルについて説明します。両方のエンジンは、ユーザーに権限を割り当てる方法の選択に際して、同レベルの精度を共有します。また、どちらもデータベース セキュリティをサポートします。MicroKernel エンジンには、アクセス許可の方法を決定するセキュリティ ポリシーが追加されています。リレーショナル エンジンは列レベルのセキュリティをサポートしています。

リレーショナル エンジンの場合、セキュリティはオンかオフのいずれかです（上記の「メモ」を参照してください）。デフォルトで、セキュリティはオフになっています。セキュリティは、Master ユーザーのパスワードを指定することによってオンになります。

セキュリティをオンにしたら、PCC を使って最低でも、データベースヘのログインを許可するユーザーを定義する必要があります。ユーザーごとにオブジェクトの権限を設定することができます。さらに、ユーザーのグループを定義したり、各グループにオブジェクトの権限を設定することもできます。

『SQL Engine Reference』では、以下の内容がリレーショナル エンジン用のセキュリティに適用されます。

複数のデータベースのデータは、データベースが同じマシン上に存在するのであれば、アクセスできます。ただし、一度に 1 つのデータベースにしかログインできません。各データベースのセキュリティを基に、適用されるデータベース アクセスの状況を示します。

これ以降のセキュリティについての説明は、MicroKernel エンジンにのみ当てはまります。リレーショナル エンジン以外の説明が不要であれば、データの暗号化へ進んでください。

MicroKernel エンジンで使用可能な認証および許可モデルには、次のモデルがあります。

このセクション、およびこれ以降のセキュリティについて説明は、MicroKernel エンジンのみを使用するアプリケーションに当てはまります。「資格情報」、「ログイン資格情報」、または「ユーザー資格情報」は、有効なユーザー名とパスワードの一組を指します。

PSQL v12 では、OS に依存しないデータベース認証および許可の機能が MicroKernel エンジンで利用できます。従来の（オペレーティング システム）認証モデルは本リリースでも今までどおり使用できますが、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 ファイルをデータベースにまとめる方法を考え、移行の予定を立てる必要があるかもしれません。

クラシック セキュリティから混合またはデータベース セキュリティへの変換方法に関する情報については、『PSQL User's Guide』のセキュリティの作業を参照してください。次のトピックでは、User's Guide で取り上げる題材の概要について簡単に説明します。

オーナー ネームは、Btrieve ファイルへのアクセスのロックを解除するバイトの文字列です。オーナー ネームと、システム ユーザー名あるいはリレーショナル データベース ユーザー名とはまったく関係がありません。オーナー ネームは、ファイル パスワードと考えてください。オーナー ネームは大文字小文字を区別します。

短いオーナー ネームは半角 8 文字までの範囲で指定できます。 長いオーナー ネームは半角 24 文字までの範囲で指定できます。長いオーナー ネームを設定することを選択した場合は、以下のすべての事項が適用されます。

PCC では現在、ファイルのセキュリティ プロパティでオーナー ネームを設定する方法は提供していません。ただし、『SQL Engine Reference』のオーナー ネームで説明されているように、PCC の SQL Editor で GRANT ステートメントを使ってオーナー ネームを設定することができます。Maintenance ユーティリティまたは Function Executor ツールを使用して、ファイルのオーナー ネームを設定またはクリアすることもできます。オーナー ネームの使用に関する詳細については、Maintenance ユーティリティについて記述されたセクションのオーナー ネームの管理を参照してください。

オーナー ネームには、表 23 に示すように、いくつかの属性があります。

ファイルに暗号化を指定したオーナー ネームを最初に設定したときに、データベース エンジンはファイル全体を直ちに暗号化します。この処理はファイルが大きいほど時間がかかります。

暗号化されたファイルに対するデータ アクセス操作は、通常のファイルに比べて時間がかかります。データベース エンジンは、ディスクからページを読み取る際にそのページを復号し、それをディスクに書き戻す前に再度暗号化する必要があります。

保護されたデータベース内のテーブルであるファイルに Btrieve オーナー ネームが設定されている場合、データベースの Master ユーザーは、そのテーブルに対する権限を任意のユーザー（Master ユーザーを含む）に与える場合、GRANT ステートメントでオーナー ネームを使用する必要があります。

あるユーザーのためにオーナー ネームを含む GRANT ステートメントを発行すると、そのユーザーはデータベースにログインすることにより、毎回オーナー ネームを指定することなく、指定されたテーブルにアクセスすることができます。

Master ユーザーが GRANT ステートメントで正しいオーナー ネームを使ってテーブルに対する権限をあるユーザーに許可していなければ、そのユーザーが ODBC 経由でそのテーブルにアクセスを試みた場合、アクセスは許可されません。

テーブルが読み取り専用属性のオーナー ネームを持っている場合、Master ユーザーはオーナー ネームを使って自分自身に SELECT 権を特に許可しなくても、自動的に SELECT 権限を持ちます。

データ ファイルにオーナー ネームが設定されていない場合、そのファイルのリレーショナル セキュリティを有効にすると、ファイルへの Btrieve アクセスは許可されなくなります。ファイルのアクセス時にオーナー ネームの指定が可能なユーザーが Btrieve アクセスを回復できるように、そのファイルにオーナー ネームを設定する必要があります。この動作により、デフォルトの Btrieve ユーザーはリレーショナル セキュリティを迂回できなくなります。

Btrieve オーナー ネームを使用してファイルへのアクセスを許可する例については、『SQL Engine Reference』の GRANT を参照してください。

複数のデータベースのデータは、データベースが同じマシン上に存在するのであれば、アクセスできます。ただし、一度に 1 つのデータベースにしかログインできません。各データベースのセキュリティを基に、適用されるデータベース アクセスの状況を示します。

PSQL v12 をインストールした後も、セキュリティのデフォルトの動作は以前のリリースと変わりません。つまり、データベース エンジンは「クラシック」、すなわち OS ベースの認証および許可を使用します。オペレーティング システムを通して特定データ ファイルへのアクセスが許可されているユーザーは、Btrieve オーナー ネームを使ってデータ ファイルへのアクセスが制限されていない限り、ファイルに対する権限と同レベルの権限をファイルに含まれているデータ レコードに対しても持ちます。

このセクションでは、デフォルト データベースや許可されたユーザー、および Btrieve セキュリティ ポリシーのその他の側面を設定するために必要な手順について説明します。

使用できるセキュリティ オプションは 3 つあります。最適なオプションを選択するための手助けとなるよう、これらのオプションの機能を以下に示します。暗号化はどの設定でも任意です。

データベースのセキュリティの下では、データベースのユーザー アカウントは OS のユーザー アカウントとはまったく無関係です。

対照的に、クラシック セキュリティでは、コンピューターへのログインに成功したユーザーは、データを含んでいるファイルに対してユーザーに割り当てられているファイル システム権限のレベルに従った、そのデータベース コンテンツへのアクセス権を持ちます。

最後に、混合セキュリティ ポリシーは、ほかの両方のポリシーの側面を持っています。この方式では、ユーザーは OS のユーザー名とパスワードを使ってログインしますが、データに対するユーザーのアクセス権はデータベースに設定されているユーザー権限によって決定されます。

このセクションでは、複数のセキュリティ ポリシーの中から 1 つを選び出す上での主な判断材料をいくつかを述べます。

MicroKernel エンジンのセキュリティ設定は 1 つの簡単な処理です。しかし、この処理には十分な柔軟性があるため、いくつかの準備を必要とします。このセクションでは、Btrieve セキュリティの設定を開始する前に知っておくべき情報について説明します。

混合またはデータベース セキュリティの場合は、すべてのユーザーに同レベルの権限を割り当てるか、もしくはデータベースごとに定義済みユーザーのセットを作成する必要があります。

まったく関連のないデータの本体を含んでいる Btrieve データ ファイルが 2 つ以上ある場合は、別個のデータベースを 2 つ以上設定し、それぞれに固有の許可されたユーザーのセットを持ちたいと思われるかもしれません。しかし、一般的に言えば、定義済みユーザーのセットを複数作成して管理する必要がないよう、別々にするデータベースの数は最小限にしたいでしょう。ほとんどの場合は、1 つのデータベースで十分です。データベースにおけるユーザー権限では、各ユーザーのデータベースへのアクセスを規制できるため、ある特定のユーザーのアクセスを制限するためだけに別のデータベースを作成する必要はありません。

1 つのデータベースのみが必要であると判断した場合は、既存のデータベース DefaultDB を Btrieve ファイルと関連付けられているデータベースとして使用することができます。そうではなく、独自の名前を付けたデータベースを設定することもできます。

名前付きデータベースのデータ ディレクトリに、データ ファイルが格納されているディレクトリを指定することによって、Btrieve データ ファイルをデータベースと関連付けます。そのため、データベースと関連付けるすべてのデータ ファイルが格納されているディレクトリを知っておく必要があります。データ ファイルがすべて特定のディレクトリ内のサブディレクトリ ツリーに存在する場合は、トップレベルのディレクトリのパス名さえわかっていれば十分です。ハード ディスク ドライブ上のすべてのデータ ファイルを含めたい場合は、"C:\" を使用することもできます。

混合セキュリティを使用する予定ならば、すべてのユーザーに同一の権限を割り当てるか、もしくは異なる権限を持つユーザーのユーザー アカウントを設定する必要があります。個々のユーザーを設定するつもりならば、データベース ユーザー名にしたいオペレーティング システム ユーザー名の一覧が必要です。設定するデータベース ユーザー名は、オペレーティング システム ユーザー名と完全に一致している必要があります。後からユーザー名を追加することはいつでもできますが、一度に複数のユーザーを作成した方がより効率的です。

セキュリティを設定する前に、使用する予定のポリシーがどういうものであるかを知っておく必要があります。セットアップ処理はポリシーによって若干異なります。ポリシーを選択する上での考慮点は、ポリシーの選択に記載されています。

このセクションでは、データベースのセキュリティの設定に使用される高レベルな手順の概要を示します。より詳細な作業手順の説明については後述のセクションで提供されています。

次の表は、異なるセキュリティ モデルを使用するために必要となる作業の基本レベルを示しています。セキュリティ モデルを実装するために必要な作業については、『PSQL User's Guide』のセキュリティの作業を参照してください。

このセクションでは、オペレーティング システムで Btrieve データ ファイルをセキュリティ保護する一方、データベース ユーザーには引き続きデータへのアクセスを許可するための、最も簡単な方法についての手順を説明します。

この手続きが完了したら、アプリケーションを介してデータにアクセスするためのデータベース ユーザー権利に影響を与えることなく、データ ファイルに対するオペレーティング システム ユーザー権利を取り消すことができます。

PSQL v12 には、PSQL 使用時に発生するデータベース関連のネットワーク トラフィックを暗号化する機能があります。この種の暗号化は、多くの場合「ワイヤ暗号化」と呼ばれます。これは、データがネットワーク ワイヤ上、あるいはワイヤレスも含め、あらゆる介在するネットワーク インフラストラクチャ上を通るときに保護されるからです。ワイヤ暗号化の使用が要求されていないときは、アプリケーションによってネットワーク上で送信されるデータへの不正アクセスに対する追加の抑止力を提供します。

この暗号化機能は、セキュリティ モデルとは直接関係ありません。どのセキュリティ モデルも、ワイヤ暗号化をオンにして、またはオンにしないで使用できます。

ワイヤ暗号化に関連する 2 つの設定があります。これらの設定は、サーバーはもちろん、各クライアント マシンで設定する必要があります。これらの設定の詳細については以下を参照してください。

製品の本リリースは、ネットワークを通じてデータを渡す前に、Blowfish というよく知られた、実績のあるパブリック ドメインの暗号化アルゴリズムを使って暗号化を実行しています。

40 ビット キーを使用する暗号化では、最少量の保護がデータに提供されます。56 ビット キーを使用する暗号化では、解析がより困難になります。最後に、128 ビット キーを使用する暗号化は、一般に最も解析が困難であると見なされています。

以前のバージョンの PSQL はワイヤ暗号化をサポートしていなかったため、これらは、本リリースの暗号化を要求するクライアントまたはサーバーと通信することができません。暗号化をサポートしていないクライアントまたはサーバーは、暗号化を要求するクライアントまたはサーバーに接続しようとすると、エラーを返します。

お使いの環境で暗号化の設定をオンにする前に、まず、暗号化の必要性について考慮してください。状況に応じて、さまざまな方法で暗号化環境を設定することができます。次の 4 つの一般的な方式を設定できます。

まず最初に、そのデータに暗号化が必要であると考えられる特性があるかどうかを検討します。データは機密か？権限のないユーザーの管理下にあって利用価値のあるデータか？組織に危害を加えるために利用することができるか？これらの質問やその他類似する質問の答えが「いいえ」である場合は、データを暗号化する必要はまったくなさそうです。このような状況では、暗号化の代償にパフォーマンスの低下を受け入れるメリットがありません。確信が持てない場合は、データ セキュリティのエキスパートにご相談ください。

データを保護する必要があるとしても、まだ暗号化する必要はない可能性があります。アプリケーションを LAN 上で単独に実行しており、ネットワーク インフラストラクチャの物理的なセキュリティに満足しているのであれば、暗号化は必要ありません。

次に、あなたのデータベースに接続する大口の取引先がリモート サイトにあるとします。リモート クライアントとの通信でのみ暗号化を使用したいと思われるかもしれません。これは、リモート クライアントの［ワイヤ暗号化］を［常時］に設定し、そのリモート クライアントがアクセスするサーバー値を［必要な場合］に設定することによって実現できます。内部クライアントはすべて［しない］に設定します。このようにして、サーバーは、暗号化を要求するリモート クライアントと通信する場合にのみ暗号化を使用するようになります。

立場が逆転して、お使いの環境に 1 つ以上のリモート サーバーが入っており、それらのサーバーはあなたが 100% 信頼していないネットワーク インフラストラクチャによってアクセスされているものとします。この場合は、それらのサーバー値を［常時］に設定し、ローカル クライアント値を［必要な場合］に設定することができます。そうすると、暗号化を要求するリモート サーバーとの通信のみが暗号化されます。

最後に、PSQL アプリケーションを頻繁に WAN や VPN、またはその他の完全に信頼していない外部ネットワーク上で実行している場合は、データベース通信を 100% 暗号化したいと思われるかもしれません。この状況では、すべてのクライアントとサーバーで、［ワイヤ暗号化］を［常時］に設定します。

クライアントおよびサーバーは暗号化された通信を必要とするという結論に達したら、どの抑止レベルが要望に沿うかを決定する必要があります。

Actian Corporation は、お客様の特定の要望に沿った暗号化レベルについてアドバイスすることはできませんので、お客様が適切なデータ セキュリティ専門家を交えて検討される際に情報提供できるよう、いくつかのガイドラインを用意しています。これらのガイドラインは、暗号化されたデータを第三者から読み取られたりデコードされたりしないことを Actian Corporation が保証するものではありません。 あらゆる暗号化方式と同様に、「解読できない」コードの類はありません。暗号化の種類によって解析する難易度が変化するだけです。 PSQL で使用する 128 ビット暗号化は、極めて専門的な個人ハッカーが持てる技術と設備をもってしても、デコード（復号）することが非常に困難であると認められています。

データが渡ってはいけない人の手に渡ってしまったとしても、そのデータによって組織や顧客が被る被害レベルがそれほど深刻でない場合には、この暗号化レベルの使用を検討してください。低度の暗号化を検討するもう 1 つの判断材料は、単純に、データがワイヤを通っている最中に不用意なネットワーク監視者にデータを読み取られたくないかどうかということです。

セキュリティに無頓着な監視者に備えてもっと強力な保護が何か必要であると確信しているが、最強レベルのセキュリティが必要だとは思わないような状況では、この暗号化レベルの使用を検討してください。

データにクレジット カード番号、社会保障番号、金融口座番号、または法律で保護されているその他の情報など、非常に秘匿性の高い情報が含まれているような状況では、この暗号化レベルの使用を検討してください。特に、お使いのデータベースが、インターネット ショッピング Web サイトやオンライン証券会社 Web サイトなど、慎重を期するデータを含んでいることで知られるネットワークのエンティティと関連付けられている場合には、この暗号化レベルを考慮してください。また、所属する組織が以前にデータ セキュリティを解析されそうになったことがある場合には、この暗号化レベルを検討してください。

暗号化を使用すると、クライアント/サーバーのパフォーマンスは低下します。暗号化をオンにした場合は、送信側でデータの各断片を暗号化し、受信側でそれをデコードする必要があります。暗号化なしで同様の操作を実行した場合と比べ、この処理には余分な CPU サイクルが必要となります。暗号化のレベルはパフォーマンスに影響しません。暗号化の使用によるパフォーマンスの低下は、3 つの暗号化レベルのうちどれを選択しても、おおよそ同じです。

PSQL は、ディスク上のデータ ファイルの暗号化をサポートします。データ ファイルがディスクに書き込まれる際に暗号化を必要とする場合、各ファイルにオーナー ネームを設定する必要があります。

詳細については、オーナー ネームを参照してください。