| Oracle Database Gatewayインストレーションおよび構成ガイド 11gリリース1（11.1） for AIX 5L Based Systems（64-bit）, HP-UX PA-RISC（64-bit）, HP-UX Itanium, Solaris Operating System （SPARC 64-bit）, Linux x86, and Linux x86-64 E05708-01 |
|
 戻る |
 次へ |
| Oracle Database Gatewayインストレーションおよび構成ガイド 11gリリース1（11.1） for AIX 5L Based Systems（64-bit）, HP-UX PA-RISC（64-bit）, HP-UX Itanium, Solaris Operating System （SPARC 64-bit）, Linux x86, and Linux x86-64 E05708-01 |
|
戻る |
次へ |
ゲートウェイ・アーキテクチャには、別個のセキュリティ機能および制限を持つ複数のコンピュータ設定が関連します。この章では、セキュリティ・システムを計画および実装するための情報を提供します。
この章の内容は次のとおりです。
複数の異なるシステムを接続する場合、一般的にはセキュリティ要件が最も厳格なシステムによりシステム全体が統制および管理されます。
ゲートウェイのセキュリティには、次の2つのグループが関連します。
特定のゲートウェイ・インスタンスおよびDRDAデータベース・サーバーへのアクセスを許可されたユーザーおよびアプリケーション
ユーザーおよびアプリケーションにより問合せおよび更新可能なサーバー・データベース・オブジェクト
ゲートウェイ・アーキテクチャにおけるアクセスは、複数の点で制御できます。データベース・オブジェクトへのアクセスは、GRANTと、ユーザーIDに基づく固有の関連認可メカニズムの使用により各DRDAデータベース・サーバーによって制御されます。
ゲートウェイがSQLリクエストに関連する場合、セキュリティ・メカニズムは、ゲートウェイによって処理される各DRDAシステム・コンポーネントに対して有効です。処理される最初のシステム・コンポーネントは、アプリケーション・ツールまたは3GLプログラムです。処理される最後のシステム・コンポーネントは、DRDAデータベースです。
アプリケーションは、ゲートウェイを使用する前にOracle Databaseに接続する必要があります。使用するログオン認証のタイプに応じて、結果となるOracleユーザーIDが決定し、ゲートウェイの動作が影響を受けます。認証には次の2つの基本タイプがあります。
Oracle認証: Oracle認証では、各OracleユーザーIDが、Oracle Databaseにより認識されるパスワードを保持します。アプリケーションは、サーバーに接続すると、ユーザーIDとパスワードを提供します。Oracle Databaseは、そのユーザーIDが存在することと、パスワードがデータベースに保存されているものと一致することを確認します。
オペレーティング・システム認証: オペレーティング・システム認証では、サーバーの基礎となるオペレーティング・システムにより認証が行われます。オペレーティング・システム認証では、パスワードのかわりにIDENTIFIED EXTERNALLY属性を使用して作成されたOracleユーザーIDにアクセスします。このユーザーIDにログインする場合、アプリケーションはユーザーIDに対してスラッシュ文字（/）を提供し、パスワードは提供しません。
オペレーティング・システム認証を実行するため、サーバーは、リクエスト側のオペレーティング・システム・ユーザーIDを特定し、オプションでそれに固定の接頭辞を追加して、その結果をOracleユーザーIDとして使用します。サーバーは、そのユーザーIDが存在し、IDENTIFIED EXTERNALLY属性を備えていることを確認しますが、パスワード・チェックは行いません。この場合の基礎となる前提条件は、オペレーティング・システムへのログイン時にユーザーが認証されていることです。
オペレーティング・システム認証は、すべてのプラットフォームで使用できるわけではなく、一部のOracle Net（クライアント/サーバー）構成やマルチスレッド・サーバー構成では使用できません。この機能が使用できるかどうかを確認する方法は、Oracle Databaseのインストレーション・ガイドおよびOracle Netのドキュメントを参照してください。
アプリケーション・ログオンの認証方法の詳細は、『Oracle Databaseリファレンス』を参照してください。
ここでの情報は、ゲートウェイに固有です。データベース・リンクの詳細は、『Oracle Databaseリファレンス』を参照してください。
データベース・リンクは、特定のユーザーからアクセス可能である必要があります。パブリック・データベース・リンクは、すべてのユーザーIDで使用できます。プライベート・データベース・リンクは、それを作成したユーザーのみが使用できます。サーバーでは、使用タイプ（読取り専用と更新または書込みなど）またはリモート・オブジェクトへのアクセス可能性に関する区別は行われません。これらの区別を行うのは、アクセスされるDRDAデータベースです。
CONNECT句は、データベース・リンクのセキュリティ関連のもう1つの属性です。CONNECT句を使用して、明示的なユーザーIDおよびパスワードを指定できます（これらはユーザーのOracle DatabaseユーザーIDおよびパスワードとは異なることがあります）。このCONNECTによるユーザーIDとパスワードの組合せは、データベース・リンク接続が最初にオープンされたときにゲートウェイに送信されます。ユーザーIDとパスワードは、ゲートウェイのオプションによっては、検証のためにゲートウェイからDRDAサーバーに送信されることもあります。
データベース・リンクがCONNECT句なしで作成されると、接続のオープン時に、ユーザーのOracle DatabaseユーザーIDとパスワードがゲートウェイに送信されます。ユーザーがオペレーティング・システム認証を使用してOracle Databaseにログインする場合、ゲートウェイは、Oracle DatabaseからユーザーIDやパスワードを受け取りません。この場合、DRDAサーバーにおけるユーザーIDのマッピング機能が使用され、このような接続が可能になります（同じホスト上のすべてのユーザーが同じDRDAデータベース・ユーザーIDを使用できる場合）。
現在のDRDAサーバーには、インバウンド（クライアント）のDRDAセッション・リクエストのセキュリティ処理を操作するオプションがあります。
DRDAサーバーの最も有益なセキュリティ機能は、ユーザーIDマッピングです。ユーザーIDマッピングとは、着信DRDAリクエストに関連付けられたユーザーIDを、そのサーバーが認識できる他のユーザーIDに変換することを意味します。この機能は、Oracle Database Gatewayのインストール環境に、すべてのシステムおよびデータベース全体を対象とする統一的なユーザーID構造がない場合に便利です。
DB2 DDFの通信データベース（CDB）には、インバウンドDRDAセッションのセキュリティ・オプションが格納されます。
インバウンド・セッションに関する次の表は、セキュリティ処理に関連します。
SYSIBM.IPNAMES表
SYSIBM.IPNAMES表は、TCP/IPベースのセッションに対して適用されるインバウンド・セキュリティを制御し、特定のホスト・システムからのすべてのDRDA接続に影響します。この表は、インバウンド接続ユーザーIDが変換とマッピングのどちらに依存するかも制御します。
SYSIBM.SYSUSERNAMES表
変換が使用される場合、SYSIBM.SYSUSERNAMES表の行により、変換されたユーザーIDがIP名およびインバウンド・ユーザーIDごとに指定されます。すべてのIPおよびすべてのインバウンド・ユーザーIDに関連するデフォルト・エントリは、両方の表に作成可能です。マッピング表は、特定のIPまたはすべてのIPから許可されるインバウンド・ユーザーIDを単純に示す場合にも使用できます（ユーザーIDがマップされているかどうかは関係ありません）。
この実装により、柔軟なマッピング構造が提供されます。特定のIPからのすべての接続で単一のDB2ユーザーIDを使用するか、特定のインバウンド・ユーザーIDを（元のユーザーIDとは関係なく）常に特定のDB2ユーザーIDにマップするよう指定できます。空白のIP名とインバウンド・ユーザーIDを含むSYSUSERNAMESエントリは、IP名またはユーザーID（あるいはその両方）ごとのより個別的なエントリが存在しないかぎり、すべての接続に対応する単一のデフォルトDB2ユーザーIDを指定します。
CDB表は、DB2 SPUFIユーティリティなどのSQLツールを使用して、更新権限を持つユーザーにより更新できます。たとえば、多くのデータベース管理者、システム・プログラマおよびセキュリティ担当者は、CDB表を更新できます。CDBの変更を反映するには、DB2 DDFコンポーネントを停止して再起動する必要があります。
DB2のDRDA固有ではないセキュリティ機能も、DRDA接続に関連しています。ユーザーIDは、接続またはサインオン終了処理に加え、通常のDB2またはSAF/RACF検証の対象となります。パスワードも検証の対象です。接続が確立されると、ユーザーIDに関連付けられたすべての標準認可またはGRANTが有効になります。ユーザーIDは、任意のSQL文を処理するために、ゲートウェイDRDAパッケージに対する実行権限を持っている必要があります。
DB2/400には、DB2/OS390のユーザーIDマッピング機能に相当する機能がありません。通常、着信DRDA接続リクエストのユーザーIDは、DB2/400における有効なユーザーIDである必要があります。
DB2/400サブシステムのゲートウェイ用の通信エントリでは、ゲートウェイがセキュアな場所ではないことを指定し、*NONEのデフォルト・ユーザーIDを含める必要があります。
DB2/400に対するDRDA接続を完了したアプリケーションは、使用中のユーザーIDに関連するすべての権限およびGRANTによる制御を受けます。
ユーザーIDは、任意のSQL文を実行するために、ゲートウェイDRDAパッケージに対する実行権限を持っている必要があります。
ゲートウェイでは、ユーザーIDとパスワードを使用してDRDAサーバー上のリモート・データベースの情報にアクセスします。一部のユーザーIDおよびパスワードは、リソース・リカバリなどの機能を処理するためにゲートウェイ初期化ファイルに定義する必要があります。セキュリティを意識した現在の環境では、初期化ファイルでアクセス可能なプレーン・テキスト・パスワードは、セキュアではないとみなされます。セキュリティを向上するために、異機種間サービスの汎用接続性の一部として暗号化機能が追加されました。この機能には、ゲートウェイからアクセスできます。この機能により、機密値を含む初期化パラメータは、暗号化された形式で格納できます。この機能の使用方法の詳細は、『Oracle Database Heterogeneous Connectivity管理者ガイド』の第4章の「初期化パラメータの暗号化」を参照してください。
