Zen は、MicroKernel エンジンを呼び出す SQL ベース アプリケーションおよび Btrieve アプリケーションに対し、それぞれリレーショナル データベース レベルおよびファイル レベルのセキュリティを提供します。データ アクセスは、オペレーティング システムや Active Directory アカウントを介したユーザー認証によって、もしくは Zen データベース ユーザーとして保護することができます。ユーザー ID が確認されると、そのユーザー権限は、オペレーティング システムまたは Active Directory の権限グループによって、もしくはユーザー/グループ レベルで定義された Zen データベース権によって承認されます。

以下のセクションでは、これらのセキュリティ モデルとそれらモデルの使用方法、および Zen のデータ ファイルの暗号化機能について説明します。

Zen では、SQL アプリケーションは、次の表に示す認証設定および許可設定を使用できます。

新しいデータベースを作成したとき、デフォルトでは、データベース セキュリティは無効になっています。これを有効にするには、セキュリティを有効にしたときに作成された Master ユーザーのパスワードを入力します。使用可能なパスワードの詳細については、識別子の種類別の制限を参照してください。

データベースのセキュリティを有効にした後で、さまざまなデータベース活動のために権限を設定するのに必要となるユーザーやグループを作成する必要があります。ローカル データベース セキュリティを設定するには、ユーザーに直接権限を割り当てる方法と、グループ レベルで権限を割り当ててからそのグループにユーザーを割り当てる方法の 2 つがあります。Windows ドメインのセキュリティを設定するには、グループのみを作成します。このグループの名前には、ネットワーク ユーザーがメンバーになっている権限グループと同じ名前を使用します。各データベースのユーザーやグループを管理するには、ZenCC または SQL スクリプトを使用します。

また、データベースに接続しているすべてのユーザーに適用されるデフォルトの PUBLIC グループの権限を設定することもできます。各ユーザーの権限は、ユーザー権限またはグループ権限と PUBLIC グループの権限の組み合わせとなります。新しいデータベースの PUBLIC グループには、権限が設定されておらず、すべての権限がグループ レベルまたは個々のユーザーのレベルで管理されている場合には設定は必要ありません。

これらの概念について、以降のセクションでさらに詳しく説明します。

Zen データベースのセキュリティを有効にすると、そのデータベースヘのフル アクセス権を持つ Master という名前のユーザーが作成されます。Master ユーザーにはパスワードが必要です。このパスワードは、セキュリティを有効にするときに設定します。各データベースに設定する Master パスワードは互いに無関係のため、異なる値を設定できます。データベースのセキュリティ設定を変更するには Master パスワードを入力する必要があるため、Master パスワードを忘れないようにしてください。

データベースの Master ユーザーとして認証された後で、ZenCC を使用することで、そのデータベースのユーザーの作成、ユーザーの割り当て先となるグループの作成、グループ レベルとユーザー レベルでのデータへのアクセス権限の管理を行うことができます。また、グループの作成とそのグループへのユーザーの作成を行う SQL ステートメントを実行することもできます。ユーザーは、作成した 1 つのグループだけのメンバーになることができます。すべてのユーザーは各データベースの特殊なグループである 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 エクスプローラーには管理できるユーザーとグループが表示されます。次の表は、ユーザーとグループに適用される一般的な規則を示します。

詳細については、『Zen User's Guide』のユーザーとグループの作業を参照してください。

SQL スクリプトを使ってリレーショナル エンジンのセキュリティを管理する場合は、『SQL Engine Reference』の以下のセクションに役立つ情報が記載されているのでご覧ください。

1 つの接続内の複数のデータベースが同じマシン上に存在する場合には、SQL アプリケーションはそれらのデータベース内のデータにアクセスできます。ただし、一度にログインできるデータベースは 1 つのため、ログインしていない別のデータベースにアクセスできるかどうかは両方のデータベースのセキュリティ設定によります。

Zen では、Btrieve アプリケーションは、次の表に示す認証設定および許可設定を使用できます。

これらの設定について、以降のセクションでさらに詳しく説明します。

これらのセクションは、MicroKernel エンジンを呼び出すアプリケーションにのみ適用されます。「資格情報」、「ログイン資格情報」、または「ユーザー資格情報」とは、有効なユーザー名とパスワードのことです。

MicroKernel エンジンに対する Zen データベースの認証および許可は、オペレーティング システムに対して依存させるか、または独立させるかを設定できます。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 URI を使って Open オペレーションのファイルを指定する必要があります。どちらの場合も、データベースはログインまたは URI の中から参照されます。このデータベースは、指定されたユーザーに権限を付与します。Btrieve データベース セキュリティでは、Zen データベースは、ローカルの Zen データベースに定義されたユーザーのリストと照合するか、あるいはユーザーが Zen データベース内のグループと同じ名前を持つ権限グループのメンバーになっている Windows Active Directory に定義された、ネットワーク ログインのリストと照合することで、ユーザーを認証し、それらのユーザーに対して Btrieve データ ファイルへのアクセスを許可します。後記する 1 つの例外を除いて、ユーザーがデータに接続しアクセスする権限は、そのユーザーが必要なアプリケーションを実行するシステムに正常にログインできる限り、ファイル システム権限とは関係ありません。データベースのユーザーとグループを定義して権限を設定する機能は、ZenCC によって、また GRANT や REVOKE などの SQL ステートメントによって提供されます。

混合またはデータベース セキュリティ モデルは、当該データベースに属するものとして定義されているディレクトリに存在する Btrieve データ ファイルでのみ使用できます。このデータベースには、デフォルトのデータベースと現在のデータベースに記載されているデフォルト データベース DefaultDB も含まれます。データベースと関連付けられていないディレクトリにあるデータ ファイルにはアクセスできません。

これらのセキュリティ モデルの主な利点の 1 つは、ユーザーのデータ ファイルへの直接アクセスを制限する一方で、データベース エンジンを介したデータ アクセスにはフル アクセスを許可できることです。対照的にクラシック モデルでは、データ ファイルへのレコードの追加が許可されているユーザーは、必ずオペレーティング システムからもデータ ファイルのコピー、削除ができなければなりません。

混合セキュリティまたはデータベース セキュリティに移行するには、多数の選択を行った上、慎重に計画を立てる必要があります。既に確立している環境では、お使いの製品環境が混乱しないように、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 暗号化が追加されました。

長いオーナー ネームとファイル暗号化の可能性を次の表に要約します。

16 進数の長いオーナー ネームは以下の要件を満たす必要があります。

長いオーナー ネームを持つファイルには、以下の制限が適用されます。

以下のトピックではより詳しい説明を提供します。

Maintenance および Function Executor ツールで、ファイルのオーナー ネームを設定またはクリアすることができます。SQL スクリプトを使用して、テーブルのオーナー ネームを設定または管理することはできませんが、SET OWNER および GRANT ステートメントを使用すれば必要に応じてオーナーネームを提供できます。

ユーザーは、オーナー ネームが割り当てられたときに選択したオプション（次の表を参照）に応じてファイルにアクセスすることができます。

SQL データベースでテーブルとして機能するファイルに Btrieve オーナー ネームが設定されている場合に、そのテーブルにアクセスするには、そのデータベースでセキュリティが有効になっているかどうかによって、2 つある方法のうち、いずれかを使用します。セキュリティが無効な場合は、SET OWNER ステートメントをその他のテーブル アクセス試行より前に実行することにより、オーナー ネームを取得できます。セキュリティが有効な場合は、データベースの Master ユーザーは、そのテーブルに対するアクセス許可を任意のユーザー（Master ユーザー自身を含む）に発行する場合、GRANT ステートメントでオーナー ネームを提供する必要があります。

オペレーティング システムでオーナー ネームが含まれるファイルが読み取り専用の場合、Master ユーザーはオーナー ネームを使って自分自身に SELECT 権を特に付与しなくても、自動的に SELECT 権限を持ちます。この場合、他のユーザーには、この自動的に付与されるアクセス権はありませんが、Master ユーザーはオーナー ネームを提供しなくても SELECT 権限を付与することはできます。

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

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

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

新しいデータベースではすべて、［Btrieve セキュリティ］設定はデフォルトで "クラシック" になります。つまり、データベース エンジンはオペレーティング システムを使って認証を行い、フォルダーとファイルの権限を使ってアクセスの許可を行います。オペレーティング システム認証でデータ ファイルへのアクセスが許可されているユーザーは、Btrieve オーナー ネームを使ってアクセスが制限されていない限り、ファイルに対する権限と同レベルの権限をファイルに含まれているデータ レコードに対しても持ちます。

以下のセクションでは、デフォルト データベースやアクセスを許可されたユーザーなど、Btrieve セキュリティ ポリシーの要素を設定する手順について説明します。

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

Btrieve データベース セキュリティおよびリレーショナルのローカル データベース セキュリティの下では、データベースのユーザー アカウントはオペレーティング システムのユーザー アカウントとはまったく無関係です。

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

最後に、Btrieve 混合セキュリティ ポリシーは、ほかの 2 つのポリシーの要素を持っています。この方式では、ユーザーはオペレーティング システムのユーザー名とパスワードを使ってログインしますが、データに対するユーザーのアクセス権はセキュリティ保護されたデータベースに設定されているユーザーまたはグループの権限によって決定されます。

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

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

アプリケーションが Btrieve ログイン オペレーションを使用したり URI でファイルを開いたりするように変更されているか、変更可能な場合は、データベース セキュリティまたは Btrieve の混合セキュリティを選択できます。どちらを選択した場合でも、セキュリティで保護するデータベースは ZenCC に登録されます。アプリケーションで Btrieve ログインや URI を使用しない場合にアクセス権を管理するには、混合セキュリティを選択して、DefaultDB データベースを設定します。

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

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

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

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

ローカル データベース認証との混合セキュリティを使用する予定ならば、すべてのユーザーに同一の権限を割り当てるか、もしくは異なる権限を持つユーザーのユーザー アカウントを設定する必要があります。個々のユーザーを設定するつもりならば、データベース ユーザー名にしたいオペレーティング システム ユーザー名の一覧が必要です。データベース ユーザー名は、オペレーティング システム ユーザー名と完全に一致している必要があります。

Windows ドメイン認証との混合セキュリティを使用する予定ならば、すべてのユーザーに PUBLIC グループの同一権限を割り当てるか、もしくは異なる権限を持つ複数の Zen ユーザー グループを作成する必要があります。どちらの場合も、ネットワーク グループ名の一覧が必要です。このネットワーク グループ名をデータベース グループ名としてコピーします。データベース グループ名はネットワーク グループ名と一致している必要があるためです。

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

データベースのセキュリティを設定する手順の概要を以下に示します。手順の詳細については、MicroKernel エンジン セキュリティのクイック スタートで説明しています。

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

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

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

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

Zen のワイヤ暗号化は、特定のセキュリティ モデルとは関係ありません。どの Zen セキュリティ設定も、ワイヤ暗号化をオンにして、またはオンにしないで使用できます。このトピックの残り部分では、以下の項目について説明します。

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

Zen では、ネットワーク経由でデータを渡す前にデータの暗号化を行うために、Blowfish という有名かつ実績のあるパブリック ドメイン アルゴリズムを使用します。この手法では 40 ビット、56 ビット、および 128 ビットのキーを実装します。40 ビット キーを使用する暗号化では、最少量の保護がデータに提供されます。56 ビット キーまたは 128 ビット キーを使用する暗号化では、解析が次第に困難になります。

暗号化と複合化の実行にはある程度のプロセッサ時間が必要なので、暗号化を使用するすべてのセキュリティと同様に、抑止力が向上すればパフォーマンスは低下します。

ワイヤ暗号化をサポートしていない旧バージョンの Zen は、暗号化を提供する新しいリリースのクライアントまたはサーバーと通信することができません。暗号化をサポートしていないクライアントまたはサーバーは、暗号化を使用するクライアントまたはサーバーに接続しようとすると、エラーを返します。

お使いの環境で暗号化の設定をオンにする前に、まず暗号化の必要性についてお考えください。状況に応じて、暗号化環境を次の 4 つの方式から選択できます。

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

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

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

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

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

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

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

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

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

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

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

Zen を使用すると、データ ファイルをディスクに書き込む際に暗号化することができます。この機能を使用するには、各ファイルにオーナー ネームを設定し、暗号化オプションを選択する必要があります。詳細については、オーナー ネームを参照してください。