トラステッド・コンテキストおよびトラステッド接続

3 層アプリケーション・モデルには多くの利点がありますが、データベース・サーバーとのすべての相互作用 (例えば、ユーザー要求) を中間層の許可 ID で行うようにすると、いくつかのセキュリティー上の問題が生じます。これらを要約すると以下のようになります。

• ユーザー ID の消失

  企業によっては、アクセス制御の目的で、データベースにアクセスしている実際のユーザーの ID を知りたい場合があります。

• ユーザーの説明責任の減少

  監査による説明責任は、データベース・セキュリティーにおける基本原則です。 ユーザーの ID が不明であると、中間層の固有の目的のために中間層により実行されるトランザクションと、ユーザーのために中間層により実行されるトランザクションを区別することが難しくなります。

• 中間層の許可 ID に特権を付与しすぎる

  中間層の許可 ID には、すべてのユーザーからのすべての要求を実行するために必要なすべての特権が含まれていなければなりません。 これには、特定の情報にアクセスする必要がないユーザーがアクセス権限を取得できてしまうというセキュリティー問題があります。

• 弱いセキュリティー

  前述の特権の問題に加えて、現行方式では、接続するために中間層により使用される許可 ID には、ユーザー要求によりアクセスされる可能性があるすべてのリソースへの特権を付与する必要があります。 中間層の許可 ID の暗号漏えいが発生すると、それらすべてのリソースは公開されてしまいます。

• 同じ接続を使用するユーザー間で相互に影響を及ぼす

  直前のユーザーによる変更が現行ユーザーに影響を与える場合があります。

明らかに、実際のユーザーの ID およびデータベース特権が、そのユーザーに代わって中間層により実行されるデータベース要求で使用されるようなメカニズムが必要です。 この目標を達成するための最も簡単な方法は、中間層がユーザーの ID とパスワードを使用して新規接続を確立した後、ユーザーの要求をその接続を介して送信するというものです。 この方法は単純ですが、以下に挙げるようないくつかの欠点があります。

• 特定の中間層では不適当。 多くの中間層サーバーには、接続を確立するために必要なユーザー認証資格情報がありません。
• パフォーマンス上のオーバーヘッド。 新しい物理接続を作成し、データベース・サーバーでユーザーを再認証することに関連した、パフォーマンス上の明らかなオーバーヘッドがあります。
• 保守上のオーバーヘッド。 一元的なセキュリティー・セットアップ、またはシングル・サインオンを使用していない状況では、2 つのユーザー定義 (1 つは中間層上、もう 1 つはサーバー上) を持つことによる保守上のオーバーヘッドがあります。 この状況では、異なる場所にあるパスワードを変更することが必要です。

トラステッド・コンテキスト機能は、この問題を解決します。 セキュリティー管理者は、データベースと中間層の間の信頼関係を定義するトラステッド・コンテキスト・オブジェクトをデータベースに作成できます。 その後、中間層ではデータベースへの明示的トラステッド接続を確立できますが、この接続では、接続の現行ユーザー ID を、認証のあるなしに関係なく別のユーザー ID に切り替える機能が中間層に付与されます。 トラステッド・コンテキストは、エンド・ユーザーの ID アサーション問題を解決するだけでなく、別の利点もあります。 それは、データベース・ユーザーが特権を使用できるようになる時期を制御する機能です。 ユーザーが特権を使用できる時期を制御できないと、全体的なセキュリティーの低下につながります。 例えば、特権が、最初に意図した目的以外で使用される場合があります。 セキュリティー管理者は、1 つ以上の特権を 1 つのロールに割り当て、そのロールをトラステッド・コンテキスト・オブジェクトに割り当てることができます。 そのトラステッド・コンテキストの定義と一致するトラステッド・データベース接続 (明示的または暗黙的) のみがそのロールに関連付けられた特権を利用できます。

トラステッド接続を使用すると以下の利点があるため、パフォーマンスを最大限に発揮します。

• 接続の現行ユーザー ID が切り替わる時に新規接続は確立されません。
• トラステッド・コンテキスト定義が切り替え先のユーザー ID の認証を必要としない場合には、データベース・サーバーで新規ユーザーを認証することに関連したオーバーヘッドは発生しません。