Oracle® Database

セキュリティ・ガイド

11g リリース2(11.2)

B56285-13(原本部品番号:E36292-09)

2017年1月

Oracle Databaseセキュリティ・ガイド, 11g リリース2(11.2)

B56285-13

Copyright © 2006, 2017, Oracle and/or its affiliates. All rights reserved.

原本著者: Patricia Huey

原本協力者: Tammy Bednar、Naveen Gopal、Don Gosselin、Sumit Jeloka、Peter Knaggs、Sergei Kucherov、Nina Lewis、Bryn Llewellyn、Rahil Mir、Narendra Manappa、Gopal Mulagund、Janaki Narasinghanallur、Paul Needham、Deb Owens、Robert Pang、Preetam Ramakrishna、Vipin Samar、Digvijay Sirmukaddam、Richard Smith、Sachin Sonawane、James Spiller、Ashwini Surpur、Srividya Tata、Kamal Tbeileh、Rodney Ward、Daniel Wong

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

例一覧

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

Oracle Databaseセキュリティの新機能

- Oracle Database 11gリリース2 (11.2.0.2)の新しいセキュリティ機能

- Oracle Database 11gリリース2 (11.2.0.1)の新しいセキュリティ機能

- Oracle Database 11gリリース1 (11.1)の新しいセキュリティ機能

1 Oracle Databaseセキュリティの概要

- Oracle Databaseセキュリティの概要

- その他のデータベース・セキュリティ・リソース

2 Oracle Databaseユーザーのセキュリティの管理

- ユーザー・セキュリティの概要

- ユーザー・アカウントの作成

- 新規ユーザー・アカウントの作成

- ユーザー名の指定

- ユーザーへのパスワードの割当て

- ユーザーに対するデフォルト表領域の割当て

- ユーザーに対する表領域割当て制限の割当て

- 表領域でのユーザー・オブジェクトに対する割当て限度の制限

- ユーザーへのUNLIMITED TABLESPACEシステム権限の付与

- ユーザーに対する一時表領域の割当て

- ユーザーに対するプロファイルの指定

- ユーザーに対するデフォルト・ロールの設定

- ユーザー・アカウントの変更

- ユーザー・アカウントの変更について

- ALTER USER文を使用したユーザー・アカウントの変更

- SYS以外のユーザー・パスワードの変更

- SYSユーザー・パスワードの変更

- ユーザー・リソース制限の構成

- ユーザー・リソース制限の概要

- システム・リソースのタイプと制限

- ユーザー・セッション・レベルの制限

- データベース・コール・レベルの制限

- CPUタイムの制限

- 論理読取りの制限

- その他のリソース制限

- プロファイルのリソース制限の値の決定

- プロファイルによるリソースの管理

- プロファイルの作成

- プロファイルの削除

- ユーザー・アカウントの削除

- データベース・ユーザーとプロファイルに関する情報の検索

- データ・ディクショナリ・ビューを使用したユーザーとプロファイルに関する情報の検索

- すべてのユーザーとその関連情報のリスト

- すべての表領域割当て制限のリスト

- すべてのプロファイルと割り当てられている制限のリスト

- 各ユーザー・セッションのメモリー使用の表示

3 認証の構成

- 認証の概要

- パスワード保護の構成

- Oracle Databaseの組込みパスワード保護の概要

- パスワードの最低要件

- パスワード管理ポリシーの使用

- パスワード管理の概要

- デフォルト・パスワードが設定されているユーザー・アカウントの検索

- デフォルト・プロファイルのパスワード設定の構成

- デフォルトのパスワード・セキュリティ設定の有効化および無効化

- ログイン失敗後のユーザー・アカウントの自動ロック

- ユーザーによる以前のパスワードの再利用の制御

- パスワード・エイジングおよび期限切れの制御

- パスワード変更のライフ・サイクル

- PASSWORD_LIFE_TIMEプロファイル・パラメータを低い値に設定

- パスワードの複雑度検証の規定

- パスワードでの大/小文字の区別の有効化または無効化

- パスワードのセキュリティへの脅威からのSHA-1ハッシュ・アルゴリズムによる保護

- パスワード資格証明用の安全性の高い外部パスワード・ストアの管理

- 安全性の高い外部パスワード・ストアの概要

- 外部パスワード・ストアの機能

- クライアントを外部パスワード・ストアを使用するように構成

- 外部パスワード・ストア資格証明の管理

- データベース管理者の認証

- データベース管理者の厳密認証と集中管理

- 管理ユーザーのディレクトリ認証の構成

- 管理ユーザーのKerberos認証の構成

- 管理ユーザーのSecure Sockets Layer認証の構成

- オペレーティング・システムを使用したデータベース管理者の認証

- パスワードを使用したデータベース管理者の認証

- データベースを使用したユーザーの認証

- データベース認証の概要

- データベース認証の利点

- データベースによって認証されるユーザーの作成

- オペレーティング・システムを使用したユーザーの認証

- ネットワークを使用したユーザーの認証

- Secure Sockets Layerを使用した認証

- サード・パーティ・サービスを使用した認証

- グローバルなユーザー認証と認可の構成

- ディレクトリ・サービスによって認可されるユーザーの作成

- プライベート・スキーマを持つグローバル・ユーザーの作成

- スキーマを共有する複数のエンタープライズ・ユーザーの作成

- グローバル認証とグローバル認可の利点

- ユーザーとパスワード認証のための外部サービスの構成

- 外部認証の概要

- 外部認証の利点

- 外部認証されるユーザーの作成

- オペレーティング・システムを使用したユーザー・ログインの認証

- ネットワーク認証を使用したユーザー・ログインの認証

- 複数層の認証と認可の使用

- クライアント、アプリケーション・サーバーおよびデータベース・サーバーの管理とセキュリティ

- 複数層環境でのユーザー識別情報の保持

- 中間層サーバーを使用したプロキシ認証

- プロキシ認証の概要

- プロキシ認証の利点

- プロキシ・ユーザー・アカウントの作成者とは

- プロキシ・ユーザー・アカウントの作成と、作成したプロキシ・ユーザー・アカウントを介したユーザー接続の認可

- 安全性の高い外部パスワード・ストアとプロキシ認証の使用

- プロキシ認証を使用した実際のユーザーの識別情報の引渡し

- 中間層の権限の制限

- ユーザーのプロキシとして機能し、ユーザーを認証する中間層を認可する方法

- 他の方式で認証されたユーザーのプロキシとして機能するために、中間層を認可する方法

- 中間層からデータベースへのユーザーの再認証

- データベースに認識されないアプリケーション・ユーザーの識別でのクライアント識別子の使用

- クライアント識別子について

- 中間層システムでのクライアント識別子の使用方法

- CLIENT_IDENTIFIER属性を使用したユーザー識別情報の保持

- グローバル・アプリケーション・コンテキストから独立したCLIENT_IDENTIFIERの使用

- DBMS_SESSION PL/SQLパッケージを使用したクライアント識別子の設定と消去

- ユーザー認証に関する情報の検索

4 権限とロール認可の構成

- 権限とロールの概要

- 権限付与の対象者

- ユーザーへのSYSDBAおよびSYSOPER管理権限の付与

- システム権限の管理

- システム権限の概要

- システム権限を制限することが重要な理由

- データ・ディクショナリの保護によるシステム権限の制限

- SYSスキーマ内のオブジェクトへのアクセスの許可

- システム権限の付与と取消し

- システム権限を付与したり、取り消すことができるユーザー

- ANY権限とPUBLICロールの概要

- ユーザー・ロールの管理

- ユーザー・ロールの概要

- ロールの機能

- ロールの特性とそのメリット

- ロールの一般的な使用方法

- ロールがユーザーの権限範囲に与える影響

- PL/SQLブロックでのロールの機能

- ロールによるDDL使用の支援または制限

- オペレーティング・システムによるロールの支援方法

- 分散環境でのロールの機能

- Oracle Databaseのインストールで事前に定義されているロール

- ロールの作成

- ロール認可のタイプの指定

- データベースを使用したロールの認可

- アプリケーションを使用したロールの認可

- 外部ソースを使用したロールの認可

- エンタープライズ・ディレクトリ・サービスによるグローバル・ロールの認可

- ロールの付与と取消し

- ロールの付与と取消しについて

- ロールを付与したり、取り消すことができるユーザー

- ロールの削除

- SQL*Plusユーザーによるデータベース・ロール使用の制限

- セキュリティに関する潜在的な問題となる非定型ツールの使用

- PRODUCT_USER_PROFILE表を介したロールの制限

- ストアド・プロシージャを使用したビジネス・ロジックのカプセル化

- セキュア・アプリケーション・ロールを使用したロール権限の保護

- オブジェクト権限の管理

- オブジェクト権限の概要

- オブジェクト権限の付与または取消し

- オブジェクト権限の管理

- オブジェクト権限の付与と取消し

- オブジェクト権限を付与できるユーザー

- シノニムを持つオブジェクト権限の使用

- 表に対する権限の管理

- 表に対する権限がデータ操作言語操作に与える影響

- 表に対する権限がデータ定義言語操作に与える影響

- ビューに対する権限の管理

- ビューに対する権限の概要

- ビューの作成に必要な権限

- ビューによる表セキュリティの強化

- プロシージャに対する権限の管理

- プロシージャに対するEXECUTE権限の使用

- プロシージャの実行とセキュリティ・ドメイン

- プロシージャに対する権限が定義者権限に与える影響

- プロシージャに対する権限が実行者権限に与える影響

- プロシージャの作成または置換に必要なシステム権限

- プロシージャのコンパイルに必要なシステム権限

- プロシージャに対する権限がパッケージおよびパッケージ・オブジェクトに与える影響

- 型に対する権限の管理

- 名前付きの型に対するシステム権限

- オブジェクト権限

- メソッド実行モデル

- 型の作成と型を使用した表の作成に必要な権限

- 型の作成と型を使用した表の作成に必要な権限の例

- 型アクセスとオブジェクト・アクセスの権限

- 型の依存性

- ユーザー権限とロールの付与

- システム権限とロールの付与

- ADMINオプションの付与

- GRANT文を使用した新規ユーザーの作成

- オブジェクト権限の付与

- GRANT OPTION句の指定

- オブジェクト所有者にかわるオブジェクト権限の付与

- 列に対する権限の付与

- 行レベルのアクセス制御

- ユーザー権限とロールの取消し

- システム権限とロールの取消し

- オブジェクト権限の取消し

- オブジェクト所有者にかわるオブジェクト権限の取消し

- 列を選択するオブジェクト権限の取消し

- REFERENCESオブジェクト権限の取消し

- 権限の取消しによる連鎖的な影響

- システム権限の取消しによる連鎖的な影響

- オブジェクト権限の取消しによる連鎖的な影響

- PUBLICロールに対する付与と取消し

- オペレーティング・システムまたはネットワークを使用したロールの付与

- オペレーティング・システムまたはネットワークを使用したロールの付与の概要

- オペレーティング・システムのロール識別機能の使用

- オペレーティング・システムのロール管理機能の使用

- OS_ROLESがTRUEに設定されている場合のロールの付与と取消し

- OS_ROLESがTRUEに設定されている場合のロールの有効化と無効化

- オペレーティング・システムによるロール管理使用時のネットワーク接続の使用

- 権限の付与と取消しが有効になるとき

- SET ROLE文が付与と取消しに与える影響

- デフォルトのロールの指定

- ユーザーが使用可能にできるロールの最大数

- PL/SQLパッケージおよびタイプでのファイングレイン・アクセスの管理

- 外部ネットワーク・サービスに対するファイングレイン・アクセス・コントロールについて

- ウォレットに対するアクセス制御について

- 外部ネットワーク・サービスを使用するパッケージに依存しているアプリケーションのアップグレード

- 外部ネットワーク・サービスに対するアクセス制御リストの作成

- 手順1: アクセス制御リストとその権限の定義の作成

- 手順2: 1つ以上のネットワーク・ホストへのアクセス制御リストの割当て

- ウォレットに対するアクセス制御の構成

- 手順1: Oracleウォレットの作成

- 手順2: ウォレット権限を付与するアクセス制御リストの作成

- 手順3: ウォレットへのアクセス制御リストの割当て

- 手順4: パスワードとクライアント証明書を使用するHTTPリクエストの作成

- アクセス制御リストの作成例

- 1つのロールと1つのネットワーク接続を割り当てるアクセス制御リストの例

- 複数のホストに複数のロールを割り当てるアクセス制御リストの例

- 非共有ウォレットのパスワードを使用するアクセス制御リストの例

- 共有データベース・セッションに使用するウォレットのアクセス制御リストの例

- ネットワーク・ホスト・コンピュータのグループの指定

- 複数のアクセス制御リスト割当てでのホスト・コンピュータの優先順位

- ポート範囲指定によるアクセス制御リスト割当てでのホストの優先順位

- ネットワーク・ホストへのユーザー・アクセスに影響を与える権限割当てのチェック

- DBAによるユーザーのネットワーク接続およびドメインに対する権限のチェック方法

- ユーザーによる各自のネットワーク接続およびドメインに対する権限のチェック方法

- 単一アクセス制御リスト内の複数のユーザーとロールに対する優先順位の設定

- ユーザー・アクセス用に構成されたアクセス制御リストに関する情報の検索

- ユーザー権限とロールに関する情報の検索

- 付与されているすべてのシステム権限のリスト

- 付与されているすべてのロールのリスト

- ユーザーに付与されているオブジェクト権限のリスト

- セッションの現在の権限ドメインのリスト

- データベースのロールのリスト

- ロールの権限ドメイン情報のリスト

5 アプリケーション開発者のセキュリティの管理

- アプリケーション・セキュリティ・ポリシーの概要

- アプリケーション・ベースのセキュリティの使用に関する考慮事項

- アプリケーション・ユーザーはデータベース・ユーザーでもあるか

- アプリケーション内またはデータベース内でのセキュリティ規定

- アプリケーション設計におけるパスワードの保護

- アプリケーションでのパスワードの保護に関する一般的なガイドライン

- プラットフォーム固有のセキュリティへの脅威

- パスワード入力を処理するアプリケーションの設計

- パスワードの形式と動作の構成

- SQL*PlusおよびSQLスクリプトにおけるパスワードの処理

- 外部パスワード・ストアを使用したパスワードの保護

- orapwdユーティリティを使用したパスワードの保護

- Javaでのパスワード読取り例

- アプリケーション権限の管理

- アプリケーションへのアクセスを制御するセキュア・アプリケーション・ロールの作成

- 手順1: セキュア・アプリケーション・ロールの作成

- 手順2: アプリケーションに対するアクセス・ポリシーを定義するPL/SQLパッケージの作成

- 権限とユーザー・データベース・ロールの関連付け

- ユーザーの権限が現在のデータベース・ロールのみである理由

- ロールを自動的に使用可能または使用禁止にするSET ROLE文の使用

- スキーマを使用したデータベース・オブジェクトの保護

- 一意スキーマでのデータベース・オブジェクトの保護

- 共有スキーマでのデータベース・オブジェクトの保護

- アプリケーションでのオブジェクト権限の管理

- アプリケーション開発者に必要なオブジェクト権限に関する知識

- オブジェクト権限によって許可されるSQL文

- データベース通信のセキュリティを強化するためのパラメータ

- プロトコル・エラーによってデータベースで受信した不正パケットのレポート

- 不正パケット受信後のサーバー実行の終了または再開

- 認証の最大試行回数の構成

- データベース・バージョン・バナーの表示制御

- 不正なアクセスおよびユーザー・アクションの監査に関するバナーの構成

6 アプリケーション・コンテキストを使用したユーザー情報の取得

- アプリケーション・コンテキストの概要

- アプリケーション・コンテキストとは

- アプリケーション・コンテキストの構成要素

- アプリケーション・コンテキストの値の格納場所

- アプリケーション・コンテキストを使用する利点

- エディションがアプリケーション・コンテキストの値に与える影響

- アプリケーション・コンテキストの種類

- データベース・セッション・ベースのアプリケーション・コンテキストの使用

- データベース・セッション・ベースのアプリケーション・コンテキストの概要

- データベース・セッション・ベースのアプリケーション・コンテキストの作成

- データベース・セッション・ベースのアプリケーション・コンテキストを設定するためのPL/SQLパッケージの作成

- データベース・セッション・ベースのアプリケーション・コンテキストを管理するパッケージの概要

- SYS_CONTEXTを使用したセッション情報の取得

- SYS_CONTEXTでの動的SQLの使用

- パラレル問合せでのSYS_CONTEXTの使用

- データベース・リンクでのSYS_CONTEXTの使用

- DBMS_SESSION.SET_CONTEXTを使用したセッション情報の設定

- データベース・セッション・ベースのアプリケーション・コンテキスト・パッケージを実行するためのログイン・トリガーの作成

- 例: データベース・セッション・ベースのアプリケーション・コンテキストの作成と使用

- このチュートリアルの概要

- 手順1: ユーザー・アカウントの作成とユーザーSCOTTがアクティブであることの確認

- 手順2: データベース・セッション・ベースのアプリケーション・コンテキストの作成

- 手順3: セッション・データを取得してアプリケーション・コンテキストを設定するパッケージの作成

- 手順4: パッケージに対するログイン・トリガーの作成

- 手順5: アプリケーション・コンテキストのテスト

- 手順6: この例で使用したコンポーネントの削除

- データベース・セッション・ベースのアプリケーション・コンテキストの外部での初期化

- ユーザーからのデフォルト値の取得

- 他の外部リソースからの値の取得

- 中間層サーバーからのアプリケーション・コンテキスト値の初期化

- データベース・セッション・ベースのアプリケーション・コンテキストのグローバルな初期化

- データベース・セッション・ベースのアプリケーション・コンテキストのグローバルな初期化について

- LDAPでのデータベース・セッション・ベースのアプリケーション・コンテキストの使用

- グローバルに初期化されたデータベース・セッション・ベースのアプリケーション・コンテキストの動作

- データベース・セッション・ベースのアプリケーション・コンテキストをグローバルに初期化する例

- 外部化されたデータベース・セッション・ベースのアプリケーション・コンテキストの使用

- グローバル・アプリケーション・コンテキストの使用

- グローバル・アプリケーション・コンテキストの概要

- Oracle Real Application Clusters環境でのグローバル・アプリケーション・コンテキストの使用

- グローバル・アプリケーション・コンテキストの作成

- グローバル・アプリケーション・コンテキストを管理するためのPL/SQLパッケージの作成

- グローバル・アプリケーション・コンテキストを管理するパッケージの概要

- エディションがグローバル・アプリケーション・コンテキストのPL/SQLパッケージの結果に与える影響

- DBMS_SESSION.SET_CONTEXTのusernameおよびclient_idパラメータの設定

- 全データベース・ユーザーを対象としたグローバル・アプリケーション・コンテキスト値の共有

- 複数のアプリケーション間を移動するデータベース・ユーザーに対するグローバル・コンテキストの設定

- 非データベース・ユーザーに対するグローバル・アプリケーション・コンテキストの設定

- セッションをクローズする際のセッション・データの消去

- クライアント・セッションIDを管理するための中間層アプリケーションへのコールの埋込み

- 中間層アプリケーションを使用したクライアント・セッションIDの管理の概要

- 中間層アプリケーションを使用したクライアント・セッションIDの取得

- 中間層アプリケーションを使用したクライアント・セッションIDの設定

- 中間層アプリケーションを使用したセッション・データの消去

- 例: クライアント・セッションIDを使用するグローバル・アプリケーション・コンテキストの作成

- このチュートリアルの概要

- 手順1: ユーザー・アカウントの作成

- 手順2: グローバル・アプリケーション・コンテキストの作成

- 手順3: グローバル・アプリケーション・コンテキストのパッケージの作成

- 手順4: グローバル・アプリケーション・コンテキストのテスト

- 手順5: この例で使用したコンポーネントの削除

- グローバル・アプリケーション・コンテキスト・プロセス

- 単純なグローバル・アプリケーション・コンテキスト・プロセス

- 軽量ユーザー用のグローバル・アプリケーション・コンテキスト・プロセス

- クライアント・セッション・ベースのアプリケーション・コンテキストの使用

- クライアント・セッション・ベースのアプリケーション・コンテキストの概要

- CLIENTCONTEXTネームスペースへの値の設定

- CLIENTCONTEXTネームスペースの取得

- CLIENTCONTEXTネームスペースの設定の消去

- CLIENTCONTEXTネームスペースのすべての設定の消去

- アプリケーション・コンテキストに関する情報の検索

7 Oracle Virtual Private Databaseを使用したデータ・アクセスの制御

- Oracle Virtual Private Databaseの概要

- Oracle Virtual Private Database

- Oracle Virtual Private Databaseポリシーを使用するメリット

- アプリケーションではなくデータベース・オブジェクトに基づくセキュリティ・ポリシー

- Oracle Databaseによるポリシー関数の評価方法の制御

- Oracle Virtual Private Databaseポリシー関数を実行するために使用する権限

- Oracle Virtual Private Databaseでのアプリケーション・コンテキストの使用

- Oracle Virtual Private Databaseポリシーのコンポーネント

- 動的なWHERE句を生成する関数の作成

- 保護するオブジェクトに関数を付加するポリシーの作成

- Oracle Virtual Private Databaseポリシーの構成

- Oracle Virtual Private Databaseポリシーの概要

- データベース表、ビューまたはシノニムへのポリシーの付加

- 特定のSQL文に対するポリシーの規定

- ポリシーを使用した列データ表示の制御

- 列レベルのOracle Virtual Private Databaseポリシーの追加

- 問合せで参照する列の行のみの表示

- 列のマスクを使用して機密性の高い列をNULL値で表示

- Oracle Virtual Private Databaseポリシー・グループの使用

- Oracle Virtual Private Databaseポリシー・グループの概要

- 新しいOracle Virtual Private Databaseポリシー・グループの作成

- SYS_DEFAULTポリシー・グループを使用したデフォルト・ポリシー・グループの指定

- 各表、ビューまたはシノニムに対する複数のポリシーの設定

- データベースへの接続に使用されるアプリケーションの検証

- Oracle Virtual Private Databaseポリシー・タイプを使用したパフォーマンスの最適化

- Oracle Virtual Private Databaseポリシー・タイプの概要

- 動的ポリシー・タイプの使用によるポリシー関数の自動再実行

- 静的ポリシーの使用によるポリシー関数の問合せごとの再実行の回避

- 共有の静的ポリシーの使用による複数オブジェクト間でのポリシーの共有

- 静的ポリシーおよび共有の静的ポリシーを使用する場合

- 解析後に変更されない述語に対する状況依存ポリシーの使用

- 共有の状況依存ポリシーの使用による複数オブジェクト間でのポリシーの共有

- 状況依存ポリシーおよび共有の状況依存ポリシーを使用する場合

- 5種類のOracle Virtual Private Databaseポリシー・タイプの要約

- 例: Oracle Virtual Private Databaseポリシーの作成

- 例: 単純なOracle Virtual Private Databaseポリシーの作成

- このチュートリアルの概要

- 手順1: OEユーザー・アカウントがアクティブであることの確認

- 手順2: ポリシー関数の作成

- 手順3: Oracle Virtual Private Databaseポリシーの作成

- 手順4: ポリシーのテスト

- 手順5: この例で使用したコンポーネントの削除

- 例: データベース・セッション・ベースのアプリケーション・コンテキストを使用したポリシーの実装

- このチュートリアルの概要

- 手順1: ユーザー・アカウントとサンプル表の作成

- 手順2: データベース・セッション・ベースのアプリケーション・コンテキストの作成

- 手順3: アプリケーション・コンテキストを設定するPL/SQLパッケージの作成

- 手順4: アプリケーション・コンテキストのPL/SQLパッケージを実行するログイン・トリガーの作成

- 手順5: ユーザー・アクセスを自分の注文に制限するPL/SQLポリシー関数の作成

- 手順6: 新しいセキュリティ・ポリシーの作成

- 手順7: 新しいポリシーのテスト

- 手順8: この例で使用したコンポーネントの削除

- 例: Oracle Virtual Private Databaseポリシー・グループの実装

- このチュートリアルの概要

- 手順1: この例で使用するユーザー・アカウントと他のコンポーネントの作成

- 手順2: 2つのポリシー・グループの作成

- 手順3: ポリシー・グループを制御するPL/SQLファンクションの作成

- 手順4: PL/SQLファンクションのポリシー・グループへの追加

- 手順5: 駆動アプリケーション・コンテキストの作成

- 手順6: ポリシー・グループのテスト

- 手順7: この例で使用したコンポーネントの削除

- 他のOracle機能でのOracle Virtual Private Databaseの使用

- Oracle Virtual Private Databaseポリシーとエディションの併用

- VPD保護表に対するユーザーの問合せでのSELECT FOR UPDATEの使用

- Oracle Virtual Private Databaseポリシーの外部結合操作またはANSI結合操作への影響

- アプリケーションでのOracle Virtual Private Databaseセキュリティ・ポリシーの使用

- ファイングレイン・アクセス・コントロールのポリシー関数に対する自動再解析の使用

- Oracle Virtual Private Databaseポリシーとフラッシュバック問合せの使用

- Oracle Virtual Private DatabaseおよびOracle Label Securityの使用

- Oracle Virtual Private Databaseを使用したOracle Label Securityポリシーの規定

- Oracle Virtual Private DatabaseおよびOracle Label Securityの例外

- EXPDPユーティリティaccess_methodパラメータを使用したデータのエクスポート

- ユーザー・モデルとOracle Virtual Private Database

- Oracle Virtual Private Databaseポリシーに関する情報の検索

8 データの暗号化APIを使用したアプリケーションの開発

- 暗号化で解決しないセキュリティの問題

- 原則1: 暗号化はアクセス制御の問題を解決しない

- 原則2: 暗号化は不正なデータベース管理者からデータを保護しない

- 原則3: すべてのデータを暗号化してもデータは保護されない

- データ暗号化の課題

- 索引付けされたデータの暗号化

- 暗号化鍵の生成

- 暗号化鍵の転送

- 暗号化鍵の格納

- データベースへの暗号化鍵の格納

- オペレーティング・システムへの暗号化鍵の格納

- ユーザー自身による暗号化鍵の管理

- 透過的データベース暗号化および表領域暗号化の使用

- 暗号化鍵の変更

- バイナリ・ラージ・オブジェクトの暗号化

- DBMS_CRYPTOパッケージを使用した格納データの暗号化

- データの暗号化APIの使用例

- データ暗号化プロシージャの例

- AES 256ビット・データ暗号化および復号化プロシージャの例

- BLOBデータの暗号化および復号化プロシージャの例

- 暗号化データに関する情報の検索

9 監査を使用したセキュリティ・アクセスの検証

- 監査の概要

- 監査とは

- 監査を使用する理由

- データベース監査証跡の保護

- 標準監査レコードおよびファイングレイン監査レコードに常に書き込まれるアクティビティ

- すべてのプラットフォームについて常に監査されるアクティビティ

- 分散データベースでの監査

- 監査のベスト・プラクティス

- 監査タイプの選択

- SQL文、権限および他の一般アクティビティの監査

- 一般的に使用されるセキュリティ関連アクティビティの監査

- 特定のファイングレイン・アクティビティの監査

- 標準監査を使用した一般的なアクティビティの監視

- 標準監査の概要

- 標準監査とは

- 標準監査の実行者

- 標準監査レコードが作成される場合

- AUDIT_TRAIL初期化パラメータを使用した標準監査の構成

- 標準監査証跡を使用可能または使用禁止にする方法

- AUDIT_TRAIL初期化パラメータの設定

- オペレーティング・システム監査証跡とデータベース監査証跡の共通点

- オペレーティング・システム監査証跡の使用

- オペレーティング・システム証跡の概要

- オペレーティング・システム監査証跡レコードの表示形式

- オペレーティング・システム監査証跡の利点

- オペレーティング・システム監査証跡の機能

- オペレーティング・システム監査証跡のディレクトリの指定

- UNIXシステムでのsyslog監査証跡の使用

- syslog監査証跡の概要

- syslog監査証跡に格納される情報の形式

- syslog監査証跡の表示形式

- syslog監査の構成

- AUDITおよびNOAUDIT SQL文の動作

- AUDIT SQL文による標準監査の使用可能化

- 文の実行の監査: 正常な実行、異常終了した実行またはその両方の監査

- 標準監査レコードの生成の仕組み

- カーソルが標準監査に与える影響

- AUDIT文でBY ACCESS句を使用する利点

- 特定のユーザーが実行したアクションの監査

- NOAUDIT SQL文を使用した監査オプションの解除

- SQL文の監査

- SQL文監査の概要

- 監査されるSQL文のタイプ

- SQL文監査の構成

- SQL文監査の解除

- 権限の監査

- 権限監査の概要

- 監査可能な権限のタイプ

- 権限監査の構成

- 権限監査の解除

- 複数層環境におけるSQL文および権限の監査

- スキーマ・オブジェクトの監査

- スキーマ・オブジェクト監査の概要

- 監査可能なスキーマ・オブジェクトのタイプ

- 標準監査とエディション付きオブジェクトの併用

- ビュー、プロシージャおよびその他の要素のスキーマ・オブジェクト監査オプション

- スキーマ・オブジェクト監査の構成

- オブジェクト監査の解除

- 将来作成される可能性のあるオブジェクトに対する監査オプションの設定

- ディレクトリ・オブジェクトの監査

- ディレクトリ・オブジェクト監査の概要

- ディレクトリ・オブジェクト監査の構成

- ディレクトリ・オブジェクト監査の解除

- ファンクション、プロシージャ、パッケージおよびトリガーの監査

- ファンクション、プロシージャ、パッケージおよびトリガーの監査の概要

- ファンクション、プロシージャ、パッケージおよびトリガーの監査の構成

- ファンクション、プロシージャ、パッケージおよびトリガーの監査の解除

- ネットワーク・アクティビティの監査

- ネットワーク監査の概要

- ネットワーク監査の構成

- ネットワーク監査の解除

- セキュリティに関連するSQL文および権限に対するデフォルト監査の使用

- デフォルトの監査設定の概要

- Oracle Databaseがデフォルトで監査する権限

- デフォルト監査設定の無効化および有効化

- ファイングレイン監査を使用した特定のアクティビティの監査

- ファイングレイン監査の概要

- ファイングレイン監査レコードが格納される場所

- ファイングレイン監査の利点

- ファイングレイン監査ポリシーの作成に必要な権限

- ファイングレイン監査で常に監査されるアクティビティ

- ファイングレイン監査ポリシーとエディションの併用

- ファイングレイン監査レコードの監査証跡の作成

- ファイングレイン監査証跡レコードの生成の仕組み

- DBMS_FGAパッケージを使用したファイングレイン監査ポリシーの管理

- DBMS_FGA PL/SQLパッケージの概要

- ファイングレイン監査ポリシーの作成

- ファイングレイン監査ポリシーを使用可能および使用禁止にする方法

- ファイングレイン監査ポリシーの削除

- 例: ファイングレイン監査ポリシーへの電子メール・アラートの追加

- このチュートリアルの概要

- 手順1: UTL_MAIL PL/SQLパッケージのインストールと構成

- 手順2: ユーザー・アカウントの作成

- 手順3: ネットワーク・サービスに対するアクセス制御リスト・ファイルの構成

- 手順4: 電子メール・セキュリティ・アラートPL/SQLプロシージャの作成

- 手順5: ファイングレイン監査ポリシー設定の作成とテスト

- 手順6: アラートのテスト

- 手順7: この例で使用したコンポーネントの削除

- 例: 非データベース・ユーザーの監査

- このチュートリアルの概要

- 手順1: ユーザー・アカウントの作成とユーザーHRがアクティブであることの確認

- 手順2: ファイングレイン監査ポリシーの作成

- 手順3: ポリシーのテスト

- 手順4: この例で使用したコンポーネントの削除

- SYS管理ユーザーの監査

- ユーザーSYSTEMの監査

- ユーザーSYS、およびSYSDBAまたはSYSOPERとして接続するユーザーの監査

- トリガーを使用して監査データを個別の表に書き込む方法

- 監査証跡レコードの管理

- 監査レコードの概要

- データベース監査証跡の管理

- データベース監査証跡の内容

- データベース監査証跡のサイズの制御

- データベース監査証跡の別の表領域への移動

- データベース監査証跡の監査

- データベース監査証跡のアーカイブ

- オペレーティング・システム監査証跡の管理

- オペレーティング・システム監査証跡がいっぱいになった場合

- オペレーティング・システム監査証跡のサイズの設定

- オペレーティング・システム監査証跡の有効期間の設定

- オペレーティング・システム監査証跡のアーカイブ

- 監査証跡レコードの削除

- 監査証跡レコードの削除の概要

- 監査証跡の削除方法の選択

- 監査証跡の自動削除ジョブのスケジューリング

- 手順1: オンラインREDOログとアーカイブREDOログのサイズのチューニング(必要に応じて)

- 手順2: タイムスタンプおよびアーカイブ方針の計画

- 手順3: クリーン・アップ操作のための監査証跡の初期化

- 手順4: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)

- 手順5: 削除ジョブの作成とスケジューリング

- 手順6: 監査証跡レコードのバッチ削除の構成(必要に応じて)

- 監査証跡の手動削除

- データベース監査証跡内のレコードのサブセットの削除

- 他の監査証跡削除操作

- 監査証跡がクリーン・アップ用に初期化されたことの確認

- 任意の監査証跡タイプに対するデフォルトの監査証跡削除間隔の設定

- 初期化クリーン・アップ設定の取消し

- 監査証跡の削除ジョブを使用可能または使用禁止にする方法

- 指定した削除ジョブに対するデフォルトの監査証跡削除ジョブの間隔の設定

- 監査証跡の削除ジョブの削除

- アーカイブ・タイムスタンプ設定の消去

- データベース監査証跡のバッチ・サイズの消去

- 例: データベース監査証跡の削除操作の直接コール

- 監査アクティビティに関する情報の検索

- データ・ディクショナリ・ビューを使用した監査証跡に関する情報の検索

- 監査証跡ビューを使用した疑わしいアクティビティの調査

- アクティブな文監査オプションのリスト

- アクティブな権限監査オプションのリスト

- 特定のオブジェクトに対するアクティブなオブジェクト監査オプションのリスト

- デフォルトのオブジェクト監査オプションのリスト

- 監査レコードのリスト

- AUDIT SESSIONオプションの監査レコードのリスト

- 監査証跡ビューの削除

10 Oracle Databaseの安全性の維持

- この章で説明するセキュリティ・ガイドラインの概要

- セキュリティ・パッチのダウンロードと脆弱性についてのOracleへの連絡

- セキュリティ・パッチと回避ソリューションの適用

- Oracle Databaseの脆弱性に関するOracleのセキュリティ窓口への連絡

- ユーザー・アカウントと権限の保護に関するガイドライン

- ロールの保護に関するガイドライン

- パスワードの保護に関するガイドライン

- データの保護に関するガイドライン

- ORACLE_LOADERアクセス・ドライバの保護に関するガイドライン

- データベースのインストールと構成の保護に関するガイドライン

- ネットワークの保護に関するガイドライン

- クライアント接続の保護

- ネットワーク接続の保護

- Secure Sockets Layer接続の保護

- 監査に関するガイドライン

- 機密情報の監査

- 監査済情報の管理しやすい状態での維持

- 通常のデータベース・アクティビティの監査

- 疑わしいデータベース・アクティビティの監査

- 監査の推奨設定

- CONNECTロール変更への対処

- CONNECTロールが変更された理由

- CONNECTロール変更がアプリケーションに与える影響

- CONNECTロール変更がデータベース・アップグレードに与える影響

- CONNECTロール変更がアカウント・プロビジョニングに与える影響

- CONNECTロール変更が新規のデータベースを使用するアプリケーションに与える影響

- CONNECTロール変更がユーザーに与える影響

- CONNECTロール変更が一般ユーザーに与える影響

- CONNECTロール変更がアプリケーション開発者に与える影響

- CONNECTロール変更がクライアント・サーバー・アプリケーションに与える影響

- CONNECTロール変更に対処する方法

- 方法1: 新しいデータベース・ロールの作成

- 方法2: CONNECT権限のリストア

- 方法3: 「最低限の権限」分析の実施

用語集

索引

例一覧

- 2-1 CREATE SESSION権限を持つユーザー・アカウントの作成

- 2-2 ユーザー・アカウントの変更

- 2-3 ORAPWDを使用したSYSユーザー・パスワードの変更

- 2-4 ユーザーのセッションIDに関するV$SESSIONの問合せ

- 2-5 ユーザー・セッションの削除

- 2-6 ユーザーが所有するオブジェクトの検索

- 2-7 ユーザー・アカウントの削除

- 3-1 パスワード作成のSQL文

- 3-2 CREATE PROFILE文を使用したアカウントのロック

- 3-3 CREATE PROFILEを使用したパスワード・エイジングと期限切れの設定

- 3-4 パスワードでの大/小文字の区別の有効化

- 3-5 ウォレット・パラメータが設定されたサンプルSQLNET.ORAファイル

- 4-1 O7_DICTIONARY_ACCESSIBILITYのFALSEへの設定

- 4-2 パスワードによって認可されるユーザー・ロールの作成

- 4-3 外部ソースによる認可が必要なロールへの変更

- 4-4 SET ROLEを使用したパスワード認証ロールの設定

- 4-5 PL/SQLパッケージによって認可されるアプリケーション・ロールの作成

- 4-6 外部ソースによって認可されるロールの作成

- 4-7 グローバル・ロールの作成

- 4-8 CASCADE CONSTRAINTSを使用したすべてのオブジェクト権限の取消し

- 4-9 プロシージャのコンパイル

- 4-10 プロシージャに対する権限の影響を受けるパッケージ・オブジェクト

- 4-11 ユーザーへのシステム権限とロールの付与

- 4-12 ディレクトリ・オブジェクトに対するEXECUTE権限の付与

- 4-13 ADMINオプションの付与

- 4-14 GRANT文を使用した新規ユーザーの作成

- 4-15 ユーザーへのオブジェクト権限の付与

- 4-16 SET ROLEを使用したロールの付与とパスワードの指定

- 4-17 SET ROLEを使用した全ロールの無効化

- 4-18 ALTER USERを使用したデフォルト・ロールの設定

- 4-19 1つのロールと1つのネットワーク接続を割り当てるアクセス制御リストの作成

- 4-20 複数のロールと複数のネットワーク接続を割り当てるアクセス制御リストの作成

- 4-21 DBA_NETWORK_ACL_PRIVILEGESビューを使用した付与権限の表示

- 4-22 DBA_NETWORK_ACLSビューを使用したホスト割当ての表示

- 4-23 非共有ウォレットのパスワードを使用するACLアクセスの構成

- 4-24 共有データベース・セッションに使用するウォレットのACLアクセスの構成

- 4-25 管理者によるネットワーク・ホスト接続に関するユーザー権限のチェック

- 4-26 管理者によるドメイン名解決権限のチェック

- 4-27 ユーザーによるネットワーク・ホスト接続に関する権限のチェック

- 4-28 ユーザーによるドメイン名解決権限のチェック

- 5-1 パスワードを読み取るためのJavaコード

- 6-1 データベース・セッション・ベースのアプリケーション・コンテキストの作成

- 6-2 SYS_CONTEXT値の検索

- 6-3 アプリケーション・コンテキストの値を作成する単純なプロシージャ

- 6-4 単純なログイン・トリガーの作成

- 6-5 本番環境用のログイン・トリガーの作成

- 6-6 開発環境用のログイン・トリガーの作成

- 6-7 セッション・データを取得してデータベース・セッション・コンテキストを設定するためのパッケージ

- 6-8 外部化されたデータベース・セッション・ベースのアプリケーション・コンテキストの作成

- 6-9 グローバル・アプリケーション・コンテキストの作成

- 6-10 全データベース・ユーザーを対象としてグローバル・アプリケーション値を管理するためのパッケージ

- 6-11 複数のアプリケーション間を移動するユーザーのグローバル・アプリケーション・コンテキスト値を管理するためのパッケージ

- 6-12 非データベース・ユーザーのグローバル・アプリケーション・コンテキスト値を管理するためのパッケージ

- 6-13 OCIStmtExecuteを使用したクライアント・セッションID値の取得

- 6-14 クライアント・セッション・ベース・コンテキストのクライアント・セッションID値の取得

- 7-1 表への単純なOracle Virtual Private Databaseポリシーの付加

- 7-2 DBMS_RLS.ADD_POLICYを使用したSQL文の指定

- 7-3 列レベルのOracle Virtual Private Databaseポリシーの作成

- 7-4 Oracle Virtual Private Databaseポリシーへの列のマスクの追加

- 7-5 DBMS_RLS.ADD_POLICYを使用したDYNAMICポリシーの作成

- 7-6 DBMS_RLS.ADD_POLICYを使用したSTATICポリシーの作成

- 7-7 DBMS_RLS.ADD_POLICYを使用したSHARED_STATICポリシーの作成

- 7-8 DBMS_RLS.ADD_POLICYを使用したCONTEXT_SENSITIVEポリシーの作成

- 7-9 DBMS_RLS.ADD_POLICYを使用したSHARED_CONTEXT_SENSITIVEポリシーの作成

- 9-1 AUDIT_TRAIL初期化パラメータの現在の値を調べる方法

- 9-2 標準監査証跡を使用可能にする方法

- 9-3 テキスト・ファイル形式のオペレーティング・システム監査証跡

- 9-4 XMLファイル形式のオペレーティング・システム監査証跡

- 9-5 SYSユーザーのsyslog監査証跡

- 9-6 AUDITを使用してユーザー・アクションを監査する方法

- 9-7 AUDITを使用してSQL文監査を使用可能にする方法

- 9-8 異常終了した文の監査

- 9-9 NOAUDITを使用してセッションおよびSQL文監査を解除する方法

- 9-10 NOAUDITを使用してすべての文の監査を解除する方法

- 9-11 AUDITを使用して権限監査を構成する方法

- 9-12 AUDITを使用して、ユーザーのSQL文を監査する方法

- 9-13 スキーマ表の監査の構成

- 9-14 スキーマ表に対する正常終了した文の監査

- 9-15 DEFAULT句を使用して新規オブジェクトの監査を構成する方法

- 9-16 プロシージャまたはファンクションの実行の監査

- 9-17 ディレクトリ・オブジェクトの監査

- 9-18 すべてのファンクション、プロシージャ、パッケージおよびトリガーの監査

- 9-19 ユーザーによるファンクション、プロシージャ、パッケージおよびトリガーの実行の監査

- 9-20 スキーマ内のプロシージャまたはファンクションの実行の監査

- 9-21 DBMS_FGA.ADD_POLICYを使用してファイングレイン監査ポリシーを作成する方法

- 9-22 ファイングレイン監査ポリシーを使用禁止にする方法

- 9-23 ファイングレイン監査ポリシーを使用可能にする方法

- 9-24 ファイングレイン監査ポリシーを削除する方法

- 9-25 ユーザーSYSTEMによる表挿入操作の監査

- 9-26 表の変更前と変更後の情報を記録する監査トリガー

- 9-27 データベース監査証跡の削除操作の直接コール

図一覧

- 3-1 パスワードの存続期間と猶予期間の推移

- 3-2 複数層認証

- 4-1 ロールの一般的な使用方法

- 6-1 LDAPディレクトリの情報ツリーにおけるアプリケーション・コンテキストの位置

- 9-1 プロキシ・ユーザーの監査

- 9-2 複数のセッションにわたるクライアント識別子情報の監査

表一覧

- 2-1 ユーザーとプロファイルに関する情報を表示するデータ・ディクショナリ・ビュー

- 3-1 デフォルト・プロファイルのパスワード固有の設定

- 3-2 前のパスワードの再利用を制御するパラメータ

- 3-3 ユーザー認証を示すデータ・ディクショナリ・ビュー

- 4-1 SYSスキーマ・オブジェクトにアクセスできるロール

- 4-2 ロールの特性とその説明

- 4-3 Oracle Databaseの事前定義ロール

- 4-4 名前付きの型に対するシステム権限

- 4-5 オブジェクト表に対する権限

- 4-6 アクセス制御リストに関する情報を表示するデータ・ディクショナリ・ビュー

- 4-7 権限とロールに関する情報を表示するデータ・ディクショナリ・ビュー

- 5-1 One Big Application Userモデルの影響を受ける機能

- 5-2 権限とスキーマ・オブジェクトとの関連

- 5-3 データベース・オブジェクト権限によって許可されるSQL文

- 6-1 アプリケーション・コンテキストの種類

- 6-2 DBMS_SESSION.SET_CONTEXTのusernameおよびclient_idパラメータの設定

- 6-3 アプリケーション・コンテキストに関する情報を表示するデータ・ディクショナリ・ビュー

- 7-1 DBMS_RLSのプロシージャ

- 7-2 DBMS_RLS.ADD_POLICYのポリシー・タイプ

- 7-3 様々なユーザー・モデルでのOracle Virtual Private Database

- 7-4 VPDポリシーに関する情報を表示するデータ・ディクショナリ・ビュー

- 8-1 DBMS_CRYPTOとDBMS_OBFUSCATION_TOOLKITとの機能の比較

- 8-2 暗号化データに関する情報を表示するデータ・ディクショナリ・ビュー

- 9-1 AUDIT_TRAIL初期化パラメータの設定

- 9-2 オペレーティング・システム監査証跡とデータベース監査証跡で共通して監査されるアクション

- 9-3 標準監査レベルとその影響

- 9-4 監査可能なネットワーク・エラーの状況

- 9-5 組込みの監査とトリガーベースの監査の比較

- 9-6 監査証跡の削除方法の選択

- 9-7 データベース監査証跡に関する情報を表示するデータ・ディクショナリ・ビュー

- 10-1 DBA_CONNECT_ROLE_GRANTEESの列と内容

はじめに

『Oracle Databaseセキュリティ・ガイド』へようこそ。このマニュアルでは、デフォルトのデータベース機能を使用してOracle Databaseのセキュリティを構成する方法について説明します。

内容は次のとおりです。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Databaseセキュリティ・ガイド』は、データベース管理者(DBA)、セキュリティ管理者、アプリケーション開発者、そして他にも次の業務を安全かつ効率的に行う任務を負う担当者を対象としています。

- 組織のデータ、ユーザーおよびアプリケーションを不慮、不適切または不正な操作から保護するセキュリティ・ポリシーの設計および実装

- 不適切または不正な操作に対する監査とアカウンタビリティに関するポリシーと手続きの作成および実施

- ユーザー・アカウント、パスワード、ロールおよび権限の作成、メンテナンス、停止

- 様々なコンピューティング・モデルに必要なサービスを安全に提供するアプリケーションの開発、およびデータベースやディレクトリ・サービスを活用した、効率と操作性の最大化

このマニュアルの読者は、データベースの使用方法や使用する理由を基本的に理解していることを前提としています。また、SQLに関する基本的な知識も必要です。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWeb サイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

セキュリティに関連する情報の詳細は、次のOracleドキュメントを参照してください。

- 『Oracle Database管理者ガイド』

- 『Oracle Database 2日でデータベース管理者』

- 『Oracle Database 2日でセキュリティ・ガイド』

- 『Oracle Database概要』

- 『Oracle Databaseリファレンス』

- 『Oracle Database Vault管理者ガイド』

このマニュアルの多くの例では、Oracle Databaseのインストール時に作成できるシード・データベースのサンプル・スキーマを使用しています。これらのスキーマがどのように作成されたか、およびその使用方法の詳細は、『Oracle Databaseサンプル・スキーマ』を参照してください。

Oracle Technology Network (OTN)

リリース・ノート、インストール関連ドキュメント、ホワイト・ペーパーまたはその他の関連ドキュメントは、Oracle Technology Network (OTN)から、無償でダウンロードできます。すでにOTNのユーザー名およびパスワードを取得している場合は、次のURLでOTN Webサイトのドキュメントのセクションに直接接続できます。

http://www.oracle.com/technetwork/index.html

セキュリティ固有の情報は、OTNを参照してください。

http://www.oracle.com/technetwork/topics/security/whatsnew/index.html

このマニュアルを含むOracleマニュアルの最新バージョンは、次の場所を参照してください。

http://www.oracle.com/technetwork/documentation/index.html

My Oracle Support

セキュリティ・パッチ、動作要件およびサポート・ナレッジ・ベースに関する情報を確認するには、My Oracle Support(旧OracleMetaLink)に接続してください。場所は次のとおりです。

https://support.oracle.com

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

Oracle Databaseセキュリティの新機能

この項で説明するOracle Database 11g リリース2(11.2)のセキュリティ機能と拡張機能には、今回リリースされたOracle Databaseに優れたアクセス制御、プライバシおよびアカウンタビリティを提供するための全体的な取り組みが反映されています。

次の各項では、Oracle Database 11g リリース2(11.2)の新しいセキュリティ機能について説明し、追加情報の参照先を示します。

- Oracle Database 11gリリース2 (11.2.0.2)の新しいセキュリティ機能

- Oracle Database 11gリリース2 (11.2.0.1)の新しいセキュリティ機能

- Oracle Database 11gリリース1 (11.1)の新しいセキュリティ機能

Oracle Database 11g リリース2(11.2.0.2)の新しいセキュリティ機能

この項の内容は、次のとおりです。

- 外部サービスおよびウォレットに対するファイングレイン・アクセスの拡張

- Virtual Private Databaseポリシーに対するMERGE INTO文のサポート

- AUDIT文のデフォルトになったBY ACCESS監査証跡オプション

- UTL_SMTP PL/SQLパッケージの拡張

- DBMS_SCHEDULER PL/SQLパッケージの新しいグローバル・スケジューラ属性

- UNLIMITED TABLESPACEシステム権限への変更

外部サービスおよびウォレットに対するファイングレイン・アクセスの拡張

このリリースでは、ファイングレイン・アクセス・コントロールを使用して外部ネットワーク・サービスおよびウォレットを構成すると、DBMS_LDAP PL/SQLパッケージにアクセスできるようになります。デフォルトのデータベース・インストールでは、このパッケージは、PUBLICユーザーに付与されるEXECUTE権限付きで作成されます。このリリースでは、このパッケージを使用するデータベース内のアプリケーションへのアクセスをユーザーが制御できるようにして、このパッケージのセキュリティを強化しています。この拡張の一部として、DBMS_LDAPパッケージは実行者の権限パッケージになりました。ユーザーがリモート・ネットワーク・ホストに接続する前に、リモート・ネットワーク・ホストに割り当てられたアクセス制御リストでconnect権限が付与されている必要があります。

DBMS_LDAPパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

Virtual Private Databaseポリシーに対するMERGE INTO文のサポート

Oracle Databaseの以前のリリースでは、MERGE INTO文を含むアプリケーションでOracle Virtual Private Databaseポリシーを作成すると、Virtual Private Databaseポリシーが存在するために、MERGE INTO文はORA-28132「MERGE INTO構文ではセキュリティ・ポリシーをサポートしていません」エラーにより回避されていました。このリリースでは、MERGE INTO操作を含むアプリケーションでポリシーを作成できます。そのためには、DBMS_RLS.ADD_POLICY statement_typesパラメータにINSERT、UPDATEおよびDELETE文を含めるか、statement_typesパラメータを完全に省略します。

詳細は、「特定のSQL文に対するポリシーの規定」を参照してください。

AUDIT文のデフォルトになったBY ACCESS監査証跡オプション

このリリース以降、標準監査レコードはデフォルトでAUDIT文のBY ACCESS句の機能を使用して生成されます。BY ACCESS句とBY SESSION句はどちらも監査対象イベントごとに個別の監査レコードを書き込みますが、BY ACCESS句は監査対象イベントのより詳細な情報を取得します。

詳細は、「AUDIT文でBY ACCESS句を使用する利点」を参照してください。

UTL_SMTP PL/SQLパッケージの拡張

このリリース以降、UTL_SMTP PL/SQLパッケージには次の新機能が含まれています。

- UTL_SMTP PL/SQLパッケージをTransport Layer Security(TLS)とSecure Sockets Layer(SSL)の両方のサーバーで使用できるようになりました。

- UTL_SMTPで、PLAIN、LOGONおよびCRAM_MD5のパスワード認証スキームがサポートされるようになりました。

UTL_SMTPパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

DBMS_SCHEDULER PL/SQLパッケージの新しいグローバル・スケジューラ属性

DBMS_SCHEDULER PL/SQLパッケージには、次の2つの新しいグローバル・スケジューラ属性が含まれています。この属性を使用して、メール・サーバーへの接続の暗号化が制御されます。

- email_server_credentialを使用すると、ユーザーSYSがEXECUTEオブジェクト権限を持つ既存の資格証明オブジェクトのスキーマおよび名前を指定できます。

- email_server_encryptionを使用すると、メール・サーバーの3つの暗号化設定の1つを設定できます。

- ssl_tlsはSSLまたはTLSを使用して、接続の開始時からメール・サーバーへの接続を暗号化します。

- starttlsでは、メール・サーバーへの接続が暗号化されずに開始されますが、暗号化された接続に切り替わります。

- noneでは、メール・サーバーへの接続に暗号化は使用されません。

スケジューラのプリファレンスの詳細は、『Oracle Database管理者ガイド』を参照してください。

UNLIMITED TABLESPACEシステム権限への変更

以前のリリースでは、UNLIMITED TABLESPACEシステム権限をユーザーから取り消した場合は明示的な割当て制限が再び有効になりました。このリリースから、UNLIMITED TABLESPACEシステム権限を取り消した後は、個々の表領域に割当て制限を明示的に付与する必要があります。

UNLIMITED TABLESPACEシステム権限の詳細は、「ユーザーへのUNLIMITED TABLESPACEシステム権限の付与」を参照してください。

Oracle Database 11g リリース2(11.2.0.1)の新しいセキュリティ機能

この項の内容は、次のとおりです。

- 外部サービスおよびウォレットに対するファイングレイン・アクセスの拡張

- Virtual Private Databaseポリシーに対するMERGE INTO文のサポート

- 複数のOracle RACインスタンスで使用可能なグローバル・アプリケーション・コンテキスト

- Secure Sockets Layer(SSL)バージョン2のサポートの変更

- ディレクトリ・オブジェクトの拡張

- 透過的データ暗号化の拡張

- 監査証跡のクリーン・アップ・プロセスの拡張

- 非推奨となったセキュリティ関連機能

外部サービスおよびウォレットに対するファイングレイン・アクセスの拡張

前のリリースのOracle Databaseでは、外部ネットワーク・サービスおよびウォレットに対するファイングレイン・アクセス・コントロールを作成する機能が追加されました。このリリースでは、次の拡張が加えられました。

- UTL_HTTP PL/SQLパッケージに対する更新。Amazon.com Webサイトへのアクセスを構成するAmazon Simple Storage Service (S3)スキームを使用するためのネットワーク・サービスを構成できるようになりました。さらに、個々のアプリケーションがそれぞれのプライベート・ウォレットとHTTP Cookie表を、同じデータベース・セッション内の他のアプリケーションと共有せず使用することにより、HTTPリクエストを実行できます。この機能により、パスワード資格証明のかわりにアクセス制御リスト(ACL)権限を使用したウォレットの保護も可能になります。

- IPバージョン6(IPv6)アドレスのサポート。DBMS_NETWORK_ACL_ADMINおよびDBMS_NETWORK_ACL_UTILTIYパッケージ、さらにPL/SQLネットワーク・ユーティリティ・パッケージ(UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDRなど)で、IPバージョン4(IPv4)とIPv6アドレスの両方がサポートされるようになりました。

詳細は、「PL/SQLパッケージおよびタイプでのファイングレイン・アクセスの管理」を参照してください。

複数のOracle RACインスタンスで使用可能なグローバル・アプリケーション・コンテキスト

このリリースでは、グローバル・アプリケーション・コンテキスト値の変更が、すべてのOracle Real Application Clusters(Oracle RAC)インスタンスで自動的に利用可能になります。

グローバル・アプリケーション・コンテキストの作成方法の詳細は、「グローバル・アプリケーション・コンテキストの使用」を参照してください。

Secure Sockets Layer(SSL)バージョン2のサポートの変更

Oracle Database 11g リリース(11.2)以降、SSLバージョン2は、サポートされるデフォルト・プロトコルのデフォルト・リストから除外されました。アプリケーションでSSLバージョン2を使用する必要がある場合、このような接続を使用する間は、SSLバージョン2を明示的に設定することによって対応できます。

詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

ディレクトリ・オブジェクトの拡張

この項の内容は、次のとおりです。

- ディレクトリ・オブジェクトで使用可能なEXECUTE権限

- ディレクトリ・オブジェクトの監査

ディレクトリ・オブジェクトで使用可能なEXECUTE権限

ORACLE_LOADERアクセス・ドライバが使用するためのユーザー指定プリプロセッサ・プログラムを含むディレクトリ・オブジェクトに対するEXECUTE権限をユーザーに付与できるようになりました。これにより、ユーザーが誤って(または意図的に)プリプロセッサ・プログラムを破損してしまうのを防ぐことができます。EXECUTE権限による影響を受けるSQL文は、GRANTおよびREVOKEです。ORACLE_LOADERアクセス・パラメータには、現在PREPROCESSOR句が含まれています。この句を使用すると、データ・ファイルの内容を変更するプリプロセッサ・プログラムの名前と場所を指定して、ORACLE_LOADERアクセス・ドライバがこのプリプロセッサ・プログラムを読み取れるようにできます。

ORACLE_LOADERアクセス・ドライバ・プリプロセッサの使用の詳細は、次の各項およびマニュアルを参照してください。

- ORACLE_LOADERアクセス・ドライバの詳細は、『Oracle Databaseユーティリティ』を参照してください。

- ディレクトリ・オブジェクトに対するEXECUTE権限を付与する構文については、「システム権限とロールの付与」を参照してください。

- 「ORACLE_LOADERアクセス・ドライバの保護に関するガイドライン」

- SQL文GRANTとREVOKEの更新については、『Oracle Database SQL言語リファレンス』を参照してください。

ディレクトリ・オブジェクトの監査

ディレクトリ・オブジェクトに対するEXECUTE権限を監査できるようになりました。これにより、ディレクトリ・オブジェクトに追加されたプリプロセッサ・プログラム(ORACLE_LOADERアクセス・ドライバによって使用されます)を実行するユーザーを監視できます。

詳細は、「ディレクトリ・オブジェクトの監査」を参照してください。

透過的データ暗号化の拡張

この項の内容は、次のとおりです。

- 統合マスター暗号化鍵

- 表領域のマスター鍵のキー更新: 暗号化鍵のパスワードの変更

- Oracle Exadataに対する透過的なデータ暗号化のサポート

- Oracle RACインスタンス間での自動ウォレット管理

統合マスター暗号化鍵

このリリースでは、透過的表領域暗号化および透過的列暗号化のマスター暗号化鍵が、1つの統合マスター暗号化鍵に結合されました。これらの鍵を結合することで、マスター暗号化鍵がOracle Walletに格納されるか、RSA、SafeNet、Thales(nCipherを含む)およびUtimacoが提供する認証済のハードウェア・セキュリティ・モジュールの1つに格納されるかに関係なく、これらの両方の透過的データ暗号化機能を透過的に更新できます。

透過的データ暗号化の詳細は『Oracle Database Advanced Security管理者ガイド』を参照してください。

表領域のマスター鍵のキー更新: 暗号化鍵のパスワードの変更

このリリースでは、Oracle Advanced Securityを使用して、Oracle Database表領域を暗号化するために使用される暗号化鍵を保護するマスター鍵を変更できます。Payment Card Industry Data Security Standard(PCI DSS)などの業界構想によって、クレジット・カード・データに関連付けられている暗号化鍵を定期的に変更することが義務付けられています。

表領域の暗号化の詳細は『Oracle Database Advanced Security管理者ガイド』を参照してください。

Oracle Exadataに対する透過的なデータ暗号化のサポート

このリリース以降、マスター暗号化鍵はインテリジェント・ストレージ・セルにコピーされ、透過的表領域暗号化または透過的列暗号化によって暗号化されたデータは、結果セットのプレフィルタリングが行われる前に復号化されます。この機能により、透過的データ暗号化を使用するデータベースのパフォーマンスが向上します。

Oracle Exadataの詳細は、『Oracle Database高可用性概要』を参照してください。

Oracle RACインスタンス間での自動ウォレット管理

Oracleウォレットを開くまたは閉じるか、Oracle RACインスタンスのマスター暗号化鍵を更新すると、ユーザーが加えた変更が他のすべてのOracle RACインスタンスに自動的に伝播されます。

詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

監査証跡のクリーン・アップ・プロセスの拡張

Oracle Database 11gリリース2(11.2)では、監査証跡のクリーン・アップ・プロセスにいくつかの拡張が施されています。このリリースでは、次のことが可能です。

- アーカイブ日付に基づくタイムスタンプ監査証跡レコード。後日、このアーカイブ日付の前に作成されたすべてのレコードを削除できます。
詳細は、「手順4: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)」を参照してください。

- 監査証跡レコードを1つの操作で削除するか、削除ジョブを作成します。システム内のすべての監査証跡レコード、またはデータベース監査証跡内のすべてのファイングレイン監査証跡レコードなど、個別タイプの監査証跡レコードを削除できます。削除操作では、タイムスタンプ・アーカイブ日付の前に作成された監査証跡レコード、または特定の監査証跡タイプのすべての監査証跡レコードが削除されます。この削除ジョブにより、時間間隔に基づいてレコードを削除し、タイムスタンプ・アーカイブ日付に基づいてレコードを削除できます。
次の各項を参照してください。

- 「監査証跡の自動削除ジョブのスケジューリング」

- 「監査証跡の手動削除」

- データベース監査証跡表を、SYSTEM表領域から別の表領域に移動します。標準監査証跡表、ファイングレイン監査証跡表または標準監査証跡表とファイングレイン監査証跡表の両方を移動できます。SYSTEM表領域がビジー状態である場合は、この表領域からのデータベース監査証跡の移動を検討します。
詳細は、「データベース監査証跡の別の表領域への移動」を参照してください。

- データベース監査証跡レコードが削除される際、削除操作で各バッチが削除されるように、レコードのバッチ・サイズを設定します。削除操作では、すべてまたは一部の監査証跡レコードを削除します。一般に、この操作は監査証跡のアーカイブ後に行います。その後、監査証跡は監査データの収集を再開します。バッチ・プロセスにより、すべてのレコードを一度に削除するのではなく、一度に10,000レコードなど、レコードのグループを削除できます。
詳細は、「手順6: 監査証跡レコードのバッチ削除の構成(必要に応じて)」を参照してください。

- オペレーティング・システム監査証跡の最大サイズおよび最大有効期間を設定します。現在の監査ファイルがこの最大値に到達すると、現在のファイルへの移入が中止され、その後の監査証跡レコードのために新しいファイルが作成されます。
次の各項を参照してください。

- 「オペレーティング・システム監査証跡のサイズの設定」

- 「オペレーティング・システム監査証跡の有効期間の設定」

非推奨となったセキュリティ関連機能

この項の内容は、次のとおりです。

- AUDIT_TRAILパラメータのDB_EXTENDED設定の非推奨化

- WKUSERロールおよびUltra Searchスキーマの非推奨化

- Database Configuration Assistantでのデフォルトのセキュリティ設定の使用不可

- ALTER USERのAUTHENTICATED USING PASSWORD句の非推奨化

- listener.oraファイルのパスワードの非推奨化

AUDIT_TRAILパラメータのDB_EXTENDED設定の非推奨化

AUDIT_TRAIL初期化パラメータのDB_EXTENDED設定は非推奨となりました。かわりに、DB, EXTENDED設定を使用します。

詳細は、「AUDIT_TRAIL初期化パラメータを使用した標準監査の構成」を参照してください。

WKUSERロールおよびUltra Searchスキーマの非推奨化

WKUSERロールおよびWKSYS、WKTEST、WKPROXYスキーマが非推奨となりました。Oracle Ultra Searchの詳細は、『Oracle Ultra Search管理者ガイド』を参照してください。

Database Configuration Assistantでのデフォルトのセキュリティ設定の使用不可

以前のリリースのOracle Databaseでは、Database Configuration Assistant(DBCA)を使用して、パスワード・セキュリティおよび監査オプションを新しいデータベースに追加できました。このリリースでは、このオプションは使用できません。このリリースでは、DBCAによって、監査オプションおよびパスワード・ポリシーが新しいデータベースに自動的に追加されます。

詳細は、次の各項を参照してください。

- 「デフォルト・プロファイルのパスワード設定の構成」

- 「セキュリティに関連するSQL文および権限に対するデフォルト監査の使用」

ALTER USERのAUTHENTICATED USING PASSWORD句の非推奨化

このリリースでは、ALTER USER文のAUTHENTICATED USING PASSWORD句が非推奨となりました。この句を使用すると、Oracle DatabaseによってAUTHENTICATION REQUIRED句に変換されます。AUTHENTICATION REQUIRED句を指定しなかった場合は、AUTHENTICATED USING CERTIFICATE句またはAUTHENTICATED USING DISTINGUISHED NAME句のいずれかが使用されます。

ALTER USER文のオプションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

listener.oraファイルのパスワードの非推奨化

このリリースでは、listener.oraファイルに対するパスワードの設定が非推奨となりました(不要になったため)。次回のリリースでは、リスナーのパスワードはサポートされなくなります。

Oracle Database 11g リリース1(11.1)の新しいセキュリティ機能

この項の内容は、次のとおりです。

- 安全性の高い構成の自動作成

- 新しいパスワード保護

- SYSDBAおよびSYSOPERの厳密な認証

- Automatic Storage Management用のSYSASM権限

- 暗号化の拡張機能

- データベースのネットワーク・サービスに対するファイングレイン・アクセス・コントロール

- AUDIT BY SESSIONの変更

- Oracle XML DBのセキュリティ拡張機能

- ディレクトリのセキュリティ拡張機能

- Oracle Call Interfaceのセキュリティ拡張機能

安全性の高い構成の自動作成

新しいデータベースの作成時に、Database Configuration Assistant(DBCA)を使用すると、以前のリリースのOracle Databaseより安全性の高い構成を自動的に作成できます。次のような安全性の高い構成の設定を1回の操作で使用可能にできます。

- デフォルト・プロファイルのパスワード固有の設定。この機能を使用すると、パスワードの期限切れやその他のパスワード・ポリシーを規定できます。詳細は、「デフォルト・プロファイルのパスワード設定の構成」を参照してください。

- 監査。この機能によって、データベース接続などの特定イベントの監査が使用可能になります。詳細は、「セキュリティに関連するSQL文および権限に対するデフォルト監査の使用」を参照してください。

データベースを構成してセキュリティを向上させるには、第10章「Oracle Databaseの安全性の維持」のガイドラインに従ってください。

新しいパスワード保護

Oracle Databaseには、次の新しいパスワード保護が組み込まれています。

- デフォルトのパスワードの容易な検索。以前のリリースのOracle Databaseからアップグレードした場合は、デフォルト・パスワードが設定されているユーザー・アカウントが存在していることがあります。セキュリティを向上させるため、これらのパスワードを検索して変更する必要があります。詳細は、「デフォルト・パスワードが設定されているユーザー・アカウントの検索」を参照してください。

- パスワード検証。パスワードの検証により、ユーザーはパスワードの設定または再設定時に複雑なパスワードを設定するようになります。Oracle Databaseで提供されているデフォルト設定を使用してパスワードを規定できます。または、カスタム要件を作成して、サイトのパスワードに関する要件の安全性を強化できます。
組込みのパスワード検証の説明は、「パスワードの複雑度検証の規定」を参照してください。

- 大/小文字の区別の規定。詳細は、「パスワードでの大/小文字の区別の有効化または無効化」を参照してください。

- パスワード・ハッシュ・アルゴリズムの強化。この拡張により、ユーザーは大/小文字や特殊文字の混在するパスワードを作成できます。詳細は、「パスワードのセキュリティへの脅威からのSHA-1ハッシュ・アルゴリズムによる保護」を参照してください。

SYSDBAおよびSYSOPERの厳密な認証

SYSDBAおよびSYSOPER権限のあるユーザーを認証するために、Secure Sockets Layer(SSL)とKerberosの厳密な認証方式を使用できるようになりました。

詳細は、「データベース管理者の厳密認証と集中管理」を参照してください。

Automatic Storage Management用のSYSASM権限

Oracle Database 11gリリース2 (11.2)に追加されたSYSASMシステム権限は、Automatic Storage Management (ASM)を管理するためにのみ使用します。ASMインスタンスに接続し管理するには、SYSDBA権限ではなく、SYSASM権限を使用します。

SYSASM権限の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

暗号化の拡張機能

ここでは、暗号化の拡張機能について説明します。この項の内容は、次のとおりです。

- SecureFileを使用したインテリジェントなLOB圧縮、重複除外および暗号化

- 圧縮および暗号化されたダンプ・ファイル・セット

- 透過的データ暗号化のハードウェア・セキュリティ・モジュールとの統合

- 透過的表領域暗号化

SecureFileを使用したインテリジェントなLOB圧縮、重複除外および暗号化

Oracle Databaseでは、SecureFileと呼ばれる、処理速度が向上した新しいスケーラブルなラージ・オブジェクト(LOB)記憶域パラダイムがサポートされています。SecureFileでは、パフォーマンスの向上に加えて、効率的な圧縮、重複除外(重複データの結合)および暗号化がサポートされます。LOBデータをOracle Databaseで暗号化できるようになり、ランダムな読み書きに使用できます。

SecureFileの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。この機能をサポートするためのCREATE TABLEおよびALTER TABLE文の更新については、『Oracle Database SQL言語リファレンス』も参照してください。

圧縮および暗号化されたダンプ・ファイル・セット

このリリースでは、Oracle Data Pumpを使用してダンプ・ファイル・セット全体を圧縮および暗号化できます。オプションで、Oracle Data Pumpによるエクスポート時にデータ、メタデータまたは完全なダンプ・ファイル・セットを圧縮および暗号化できます。

詳細は、『Oracle Databaseユーティリティ』を参照してください。

透過的データ暗号化のハードウェア・セキュリティ・モジュールとの統合

透過的データ暗号化(TDE)では、暗号化されたソフトウェア・ウォレットにマスター鍵が格納され、この鍵を使用して列キーが暗号化され、その列キーを使用して列データが暗号化されます。多くのアプリケーションはこの鍵管理の方法で十分ですが、さらに厳密なセキュリティを必要とする環境では不十分な場合があります。TDEが拡張され、ハードウェア・セキュリティ・モジュール(HSM)が使用されるようになりました。この拡張によって、マスター鍵の保護に高信頼性要件が適用されます。

このリリースでは、鍵管理機能を活用することによりいつでもTDEマスター暗号化鍵をハードウェア・セキュリティ・モジュール(HSM)内に格納できます。表キー(TDE列暗号化の場合)と表領域キー(TDE表領域暗号化の場合)のみが、データベースに返される前にHSMで復号化されるため、アプリケーション・データの暗号化と復号化はデータベースに残ります。HSMデバイスとデータベース間のトラフィックの暗号化をお薦めします。この新機能では、マスター暗号化鍵はクリアテキストの場合も暗号化形式の場合でもHSMに存在するため、透過的データ暗号化のセキュリティが向上します。さらに、Oracle Real Applications Clusters (Oracle RAC)またはData Guard環境内の複数のデータベースおよびインスタンス間で同じ鍵を共有できます。

透過的データ暗号化をハードウェア・セキュリティ・モジュールと統合するように構成する方法は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

透過的表領域暗号化

透過的表領域暗号化により、アプリケーションの表領域全体を暗号化し、これらの表領域内のデータをすべて暗号化できます。適切な認可を受けたアプリケーションが表領域にアクセスすると、アプリケーションに関連するデータ・ブロックが透過的に復号化されます。

透過的表領域暗号化はTDE列暗号化に代わる機能です。この方法では、暗号化する列を判別するためにアプリケーションを詳細に分析する必要がありません。特に社会保障番号や患者受診記録など、個人を特定できる情報(PII)が格納されている列が多数あるアプリケーションに有効です。表の中に暗号化するデータが少量しかない場合は、TDE列暗号化を使用し続けてもかまいません。

透過的暗号化の概要は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。透過的表領域暗号化の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

データベースのネットワーク・サービスに対するファイングレイン・アクセス・コントロール

Oracle Databaseには、UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDRなど、データベース・ユーザーがデータベースのネットワーク・サービスにアクセスできるように設計されたPL/SQLユーティリティ・パッケージのセットが用意されています。PL/SQLユーティリティ・パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

デフォルトのデータベース・インストールでは、これらのパッケージは、PUBLICユーザーに付与されるEXECUTE権限付きで作成されます。このリリースでは、これらのパッケージを使用するデータベース内のアプリケーションへのアクセスをデータベース管理者が制御できるようにして、これらのパッケージのセキュリティを強化しています。

詳細は、「PL/SQLパッケージおよびタイプでのファイングレイン・アクセスの管理」を参照してください。

AUDIT BY SESSIONの変更

AUDIT文のBY SESSION句を使用すると、監査対象イベントごとに1つの監査レコードが書き込まれるようになりました。以前のリリースでは、BY SESSIONにより、すべてのSQL文、または同一ユーザー・セッション内の同一スキーマ・オブジェクトに実行された同一タイプの操作に対して、1つの監査レコードが書き込まれていました。現在は、BY SESSIONとBY ACCESSの両方によって、監査操作ごとに1つの監査レコードが書き込まれます。これ以外に、LOGONイベントとLOGOFFイベント用の個別の監査レコードがあります。BY ACCESS句を省略すると、BY SESSIONがデフォルトで使用されます。

BY SESSIONによって生成される監査レコードは、BY ACCESSの監査レコードとは異なります。より詳細な監査レコードが作成されるように、すべてのAUDIT文にBY ACCESS句を指定することをお薦めします。LOGOFFイベントについては、監査レコードのタイムスタンプの精度が以前のリリースより高くなっています。

この変更は、データ定義言語(DDL)文以外のSQL文を監査するスキーマ・オブジェクト監査オプション、文オプションおよびシステム権限に適用されることに注意してください。DDL文を監査するすべてのSQL文およびシステム権限については、常にBY ACCESS句を使用して監査が行われます。

詳細は、次の各項を参照してください。

- 「標準監査レコードの生成の仕組み」

- 「AUDIT文でBY ACCESS句を使用する利点」

Oracle XML DBのセキュリティ拡張機能

この項の内容は、次のとおりです。

- Oracle Database XMLに対するXML変換サポート

- Webサービスのサポート

Oracle Database XMLに対するXML変換サポート

セキュリティ・オブジェクトは、Oracle XML DBリポジトリにXMLTypeオブジェクトとして格納されるようになりました。これらのセキュリティ・オブジェクトには、別の言語で検索または表示できるように、その言語に変換する必要がある文字列を格納できます。開発者は、変換した複数の文字列をXMLTypeで格納し、ユーザーの言語設定に応じてこれらの文字列を取得および操作できます。この機能の利点は、ユーザーのターゲット優先言語に依存しないアプリケーションの開発関連コストが削減されることです。

XMLTypeオブジェクトのセキュリティを構成する方法は、『Oracle XML DB開発者ガイド』を参照してください。

Webサービスのサポート

サービス指向アーキテクチャ(SOA)の操作にOracle XML DB HTTPサーバーを使用できるようになりました。この結果、SOA環境でデータベースを単純に別のサービス・プロバイダとして扱うことができます。セキュリティ管理者は、事前定義のロールであるXDB_WEBSERVICES、XDB_WEBSERVICES_OVER_HTTPおよびXDB_WEBSERVICES_WITH_PUBLICを使用して、Oracle Database Webサービスとその関連データベース・オブジェクトへのユーザー・アクセスを制御できます。

Oracle Database Webサービスの構成方法は、『Oracle XML DB開発者ガイド』を参照してください。この機能の事前定義のロールに関する詳細は、表4-3「Oracle Databaseの事前定義ロール」を参照してください。

ディレクトリのセキュリティ拡張機能

このリリースでは、管理者は、ディレクトリ内のデータベース・サービス情報への匿名アクセスを禁止し、LDAPディレクトリベースの名前参照の実行時に、クライアントに認証を要求できるようになりました。Microsoft Active Directoryベースの名前参照を使用している場合、Oracle Databaseでは、オペレーティング・システムベースのネイティブ認証が使用されます。Oracle Internet Directory(OID)ベースの名前参照を使用している場合は、ウォレットを使用して認証が実行されます。

ディレクトリのセキュリティの構成方法は、『Oracle Database Net Servicesリファレンス』を参照してください。

Oracle Call Interfaceのセキュリティ拡張機能

Oracle Call Interface(OCI)で使用できるセキュリティ拡張機能は、次のとおりです。

- 悪意のあるユーザーまたは侵入者が送信元の可能性がある不正なパケットのレポート。

- 不正なパケット受信時のクライアントまたはサーバー・プロセスの終了または再開。

- 認証の最大試行回数の構成。

- Oracleデータベース・バージョンのバナー表示の制御。これは、バージョンによってデータベース・ソフトウェアに存在するセキュリティ上の脆弱性に関する情報を侵入者が検出できないようにするためです。

- サーバー接続に対する「不正なアクセス」や「ユーザー・アクション監査済」などのバナー情報の追加。クライアントでこの情報を表示できます。

データベース管理者は、新しい一連の初期化パラメータを構成することによって、Oracle Call Interface開発者のためにこれらのセキュリティ拡張機能を管理できます。詳細は、「データベース通信のセキュリティを強化するためのパラメータ」を参照してください。Oracle Call Interfaceの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』も参照してください。

1 Oracle Databaseセキュリティの概要

この章の内容は、次のとおりです。

- Oracle Databaseセキュリティの概要

- その他のデータベース・セキュリティ・リソース

Oracle Databaseセキュリティの概要

デフォルトのOracle Database機能を使用すると、Oracle Databaseインストールの次の領域でセキュリティを構成できます。

- ユーザー・アカウント。作成したユーザー・アカウントは様々な方法で保護できます。サイトのパスワード・ポリシーを強化するために、パスワード・プロファイルを作成することもできます。第2章「Oracle Databaseユーザーのセキュリティの管理」では、ユーザー・アカウントの管理方法について説明します。

- 認証方式。Oracle Databaseには、ユーザーおよびデータベース管理者用の認証を構成する方法がいくつかあります。たとえば、ユーザーは、データベース・レベル、オペレーティング・システムおよびネットワークで認証できます。第3章「認証の構成」では、Oracle Databaseにおける認証の機能について説明します。

- 権限とロール。権限とロールを使用すると、データに対するユーザー・アクセスを制限できます。付録P「権限とロール認可の構成」では、ユーザーの権限とロールの作成方法と管理方法について説明します。

- アプリケーション・セキュリティ。データベース・アプリケーションを作成する最初のステップは、データベース・アプリケーションが適切に保護されるようにすることです。付録P「アプリケーション開発者のセキュリティの管理」では、アプリケーション・セキュリティをアプリケーション・セキュリティ・ポリシーに組み込む方法について説明します。

- アプリケーション・コンテキストを使用したユーザー・セッション情報。アプリケーション・コンテキストは、セッション情報を保持する名前と値のペアです。この情報に基づいて、ユーザーの名前や端末などのユーザーに関するセッション情報を取得し、そのユーザーのデータベース・アクセスおよびアプリケーション・アクセスを制限できます。第6章「アプリケーション・コンテキストを使用したユーザー情報の取得」では、アプリケーション・コンテキストの使用方法について説明します。

- 仮想プライベート・データベースを使用した行および列レベルでのデータベース・アクセス。仮想プライベート・データベース・ポリシーは、ユーザーが発行したSQL文にWHERE述語を動的に埋め込みます。第7章「Oracle Virtual Private Databaseを使用したデータ・アクセスの制御」では、仮想プライベート・データベース・ポリシーの作成方法と管理方法について説明します。

- 暗号化。ネットワーク上のデータを変換して、そのデータへの不正なアクセスを防止できます。付録P「データ暗号化APIを使用したアプリケーションの開発」では、DBMS_CRYPTOおよびPL/SQLパッケージを使用したデータの暗号化方法について説明します。

- データベース・アクティビティの監査。データベース・アクティビティは、すべてのSQL文、SQL権限、スキーマ・オブジェクト、ネットワーク・アクティビティの監査など、一般的な条件で監査できます。または、社内ネットワーク外部のIPアドレスが使用されているような場合は、きめ細かい方法で監査できます。この章では、データベース監査証跡の削除方法についても説明します。付録P「監査を使用したセキュリティ・アクセスの検証」では、データベース監査を使用可能にして構成する方法について説明します。

さらに、第10章「Oracle Databaseの安全性の維持」では、Oracle Databaseインストールを保護する際に従う必要のあるガイドラインを示します。

その他のデータベース・セキュリティ・リソース

このマニュアルで説明するセキュリティ・リソース以外に、Oracle Databaseには、次のデータベース・セキュリティ製品が用意されています。

- 高度なセキュリティ機能。透過的データ暗号化、ウォレット管理、ネットワーク暗号化、およびRADIUS、Kerberos、Secure Sockets Layer認証などの高度な機能の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

- Oracle Label Security。Oracle Label Securityは、データベース表を行レベルで保護し、行データに対するユーザー・アクセスを権限に基づいてフィルタ処理できるようにします。Oracle Label Securityの詳細は、『Oracle Label Security管理者ガイド』を参照してください。

- Oracle Database Vault。Oracle Database Vaultには、権限を持つユーザーからのデータ保護など、機密データに対するファイングレイン・アクセス・コントロールが用意されています。Oracle Database Vaultの使用方法は、『Oracle Database Vault管理者ガイド』を参照してください。

- Oracle Audit Vault。Oracle Audit Vaultでは、Oracle Databaseの監査証跡表、データベース・オペレーティング・システム監査ファイル、データベースのREDOログなどのソースからデータベース監査データを収集します。Oracle Audit Vaultを使用すると、不審なアクティビティに対するアラートを作成したり、権限を持つユーザーの変更、スキーマの変更およびデータ・レベルのアクセスに関する履歴のレポートを作成できます。Oracle Audit Vaultの管理方法は、『Oracle Audit Vault管理者ガイド』を参照してください。

- Oracle Enterprise User Security。Oracle Enterprise User Securityを使用すると、ユーザー・セキュリティをエンタープライズ・レベルで管理できます。Oracle Enterprise User Securityの構成方法は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

これらの製品に加えて、新製品およびセキュリティ・パッチやアラートに関する重要な情報など、Oracle Databaseセキュリティに関する最新情報を入手するには、Oracle Technology Networkの「Security Technology Center」を参照してください。次の場所でアクセスできます。

http://www.oracle.com/technetwork/topics/security/whatsnew/index.html">>http://www.oracle.com/technetwork/topics/security/whatsnew/index.html

2 Oracle Databaseユーザーのセキュリティの管理

この章の内容は、次のとおりです。

- ユーザー・セキュリティの概要

- ユーザー・アカウントの作成

- ユーザー・アカウントの変更

- ユーザー・リソース制限の構成

- ユーザー・アカウントの削除

- データベース・ユーザーとプロファイルに関する情報の検索

ユーザー・セキュリティの概要

各Oracleデータベースには、有効なデータベース・ユーザーのリストがあります。データベースにアクセスするには、ユーザーは、データベース・アプリケーションを実行し、データベースに定義されている有効なユーザー名を使用して、データベース・インスタンスに接続する必要があります。Oracle Databaseでは、ユーザーのセキュリティを様々な方法で設定できます。ユーザー・アカウントの作成時に、ユーザー・アカウントに対して制限を指定できます。ユーザーのセキュリティ・ドメインの一部として、各ユーザーが使用できる各種のシステム・リソースの容量に制限を設定することもできます。Oracle Databaseには、リソースやセッションなどの情報を検索する際に問い合せることができる一連のデータベース・ビューが用意されています。この章では、プロファイルについても説明します。プロファイルとは、ユーザーに適用される属性の集合です。それらの属性を共有する複数ユーザーの中の任意のユーザーに関する単一の参照になります。

ユーザー・セキュリティの別の管理方法は、ユーザー権限とロールを割り当てることです。詳細は、第4章「権限とロール認可の構成」を参照してください。

ユーザー・アカウントの作成

この項の内容は、次のとおりです。

- 新規ユーザー・アカウントの作成

- ユーザー名の指定

- ユーザーへのパスワードの割当て

- ユーザーに対するデフォルト表領域の割当て

- ユーザーに対する表領域割当て制限の割当て

- ユーザーに対する一時表領域の割当て

- ユーザーに対するプロファイルの指定

- ユーザーに対するデフォルト・ロールの設定

ユーザー・アカウントおよびパスワードの作成と管理のガイドラインは、次の各項を参照してください。

- 「ユーザー・アカウントと権限の保護に関するガイドライン」

- 「パスワードの保護に関するガイドライン」

新規ユーザー・アカウントの作成

データベース・ユーザーを作成するには、CREATE USER文を使用します。 ユーザーを作成するには、CREATE USERシステム権限が必要です。CREATE USERは強力なシステム権限であるため、通常、この権限を持つユーザーはデータベース管理者またはセキュリティ管理者のみです。

例2-1 では、ユーザーを作成し、ユーザー・パスワード、デフォルト表領域、一時セグメントが作成される一時表領域、表領域割当て制限、およびプロファイルを指定します。また、ユーザーに最低限の権限、つまりデータベース・セッションにログインするためのCREATE SESSIONも付与します。

例2-1 CREATE SESSION権限を持つユーザー・アカウントの作成

CREATE USER jward
IDENTIFIED BY password
DEFAULT TABLESPACE data_ts
QUOTA 100M ON test_ts
QUOTA 500K ON data_ts
TEMPORARY TABLESPACE temp_ts
PROFILE clerk;
GRANT CREATE SESSION TO jward;

passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。

新しく作成したユーザーは、CREATE SESSIONシステム権限が付与されるまで、データベースに接続できません。そのため、ユーザー・アカウントの作成直後に、GRANT SQL文を使用して、この権限をユーザーに付与します。Oracle Enterprise Managerへのアクセスが必要なユーザーには、SELECT ANY DICTIONARY権限も付与する必要があります。

注意:
セキュリティ管理者は、独自のロールを作成し、必要な権限のみを割り当てる必要があります。たとえば、それまでCONNECT権限を付与されていた多くのユーザーは、CONNECTで提供されていた追加権限を必要とはしていませんでした。そのかわり、実際にはCREATE SESSIONのみが必要であったため、事実、CONNECTが今も保持しているのはこの権限のみです。
組織固有のロールを作成することによって、組織で割り当てる権限を詳細に制御でき、Oracle Databaseが定義するロールが将来のリリースで変更された場合に組織を保護できます。ロールの作成方法と管理方法は、第4章「権限とロール認可の構成」を参照してください。

ユーザー名の指定

各データベース内のユーザー名は、他のユーザー名およびロールと比較して一意であることが必要です。ユーザーとロールに同じ名前を付けることはできません。また、各ユーザーには対応するスキーマがあります。スキーマ内の各スキーマ・オブジェクトには、必ず一意の名前を指定する必要があります。次の例で、太字のテキストはユーザー名の作成方法を示しています。

ユーザーjwardはデータベースに大文字で格納されます。次に例を示します。

CREATE USER jward
IDENTIFIED BY password
DEFAULT TABLESPACE data_ts
QUOTA 100M ON test_ts
QUOTA 500K ON data_ts
TEMPORARY TABLESPACE temp_ts
PROFILE clerk
CONTAINER = CURRENT;

SELECT USERNAME FROM ALL_USERS;

USERNAME
---------
JWARD
...

しかし、ユーザー名を二重引用符で囲むと、このユーザー名は名前に使用した大/小文字の区別を使用して格納されます。例:

CREATE USER "jward" IDENTIFIED BY password;

そのため、ALL_USERSデータ・ディクショナリ・ビューを問い合せると、ユーザー・アカウントが作成に使用した大/小文字を使用して格納されていることがわかります。

SELECT USERNAME FROM ALL_USERS;

USERNAME
---------
jward
...

ユーザーJWARDとユーザーjwardは、どちらも別々のユーザー・アカウントとしてデータベースに格納されています。後で、二重引用符を使用して作成したユーザーを変更または削除する場合は、そのユーザー名を二重引用符で囲む必要があります。

例:

DROP USER "jward";

ユーザーへのパスワードの割当て

例2-1では、データベースを使用して新規ユーザーを認証しています。この場合、接続に成功するために、接続ユーザーはデータベースに対して正しいパスワードを指定する必要があります。ユーザーのパスワードを指定するには、CREATE USER文のIDENTIFIED BY句を使用します。

CREATE USER jward
IDENTIFIED BY password
DEFAULT TABLESPACE data_ts
QUOTA 100M ON test_ts
QUOTA 500K ON data_ts
TEMPORARY TABLESPACE temp_ts
PROFILE clerk;

関連項目:

- パスワードを作成するための最低要件は、「パスワードの最低要件」を参照してください。

- パスワードを保護する別の方法については、「パスワードの保護に関するガイドライン」を参照してください。

- Oracle Databaseユーザーが使用できる認証方式の詳細は、第3章「認証の構成」を参照してください。

ユーザーに対するデフォルト表領域の割当て

各ユーザーには、デフォルト表領域が必要です。スキーマ・オブジェクトがユーザーのスキーマ内に作成され、かつそのDDL文でそのオブジェクトを格納する表領域が指定されていない場合、そのオブジェクトはユーザーのデフォルト表領域に格納されます。

すべてのユーザーのデフォルト表領域に対するデフォルト設定は、SYSTEM表領域です。ユーザーがオブジェクトを作成せず、オブジェクトを作成するための権限も持っていない場合は、デフォルト設定のままで問題ありません。ただし、任意のタイプのオブジェクトを作成する可能性があるユーザーには、デフォルト表領域(USERS表領域など)を明示的に割り当てる必要があります。SYSTEM以外の表領域を使用すると、同じデータ・ファイルに対するデータ・ディクショナリ・オブジェクトとユーザー・オブジェクト間の競合が解消されます。通常、ユーザー・データはSYSTEM表領域に格納しないでください。

CREATE TABLESPACE SQL文を使用して、データベースの作成時に、データベースの永続オブジェクトのデフォルトとして使用される、SYSTEM以外のデフォルト永続表領域を作成できます。ユーザー・データをシステム・データと区切ることにより、状況次第ではデータベース全体が機能不全になる場合もある、SYSTEM表領域に関する問題が生じる可能性を減らすことができます。このデフォルトの永続表領域は、システム・ユーザー、つまりデフォルトの永続表領域がSYSTEMであるSYS、SYSTEM、およびOUTLNが使用するものではありません。デフォルト永続表領域として指定されている表領域は削除できません。目標を達成するためには、最初にデフォルトの永続表領域として他の表領域を指定する必要があります。ALTER TABLESPACE SQL文を使用して、デフォルトの永続表領域を他の表領域に変更できます。この変更はALTER DDL文のコミット後に作成されたすべてのユーザーまたはオブジェクトに影響を及ぼすことに注意してください。

ユーザー作成時に、そのユーザーのデフォルト表領域を設定しておき、作成後にALTER USER文を使用して変更することもできます。ユーザーのデフォルト表領域を変更すると、設定の変更後に作成されたオブジェクトのみがこの変更の影響を受けます。

ユーザーのデフォルト表領域を指定するときは、その表領域に対する割当て制限もあわせて指定してください。

次のCREATE USER文では、ユーザーjwardのデフォルト表領域はdata_tsであり、その表領域でのjwardの割当て制限は500KBです。

CREATE USER jward
IDENTIFIED BY password
DEFAULT TABLESPACE data_ts
QUOTA 100M ON test_ts
QUOTA 500K ON data_ts
TEMPORARY TABLESPACE temp_ts
PROFILE clerk;

ユーザーに対する表領域割当て制限の割当て

各ユーザーには、任意の表領域(一時表領域を除く)に対する表領域割当て制限を設定できます。割当て制限による影響は、次のとおりです。

- 特定タイプのオブジェクトを作成する権限があるユーザーは、指定した表領域内にオブジェクトを作成できます。

- Oracle Databaseでは、指定した表領域内にあるユーザーのオブジェクトの記憶域に対して割当て可能な領域は、割当て制限以内に制限されます。

デフォルトでは、ユーザーに対するデータベースの表領域の割当て制限はありません。ユーザーがスキーマ・オブジェクトを作成する権限を持っている場合は、このユーザーがオブジェクトを作成できるようにするための割当て制限を割り当てる必要があります。最低でも、ユーザーにはデフォルト表領域の割当て制限と、ユーザーがオブジェクトを作成する他の表領域の追加割当て制限を割り当てます。

次のCREATE USER文では、test_tsおよびdata_ts表領域に対して次の割当て制限を割り当てています。

CREATE USER jward
IDENTIFIED BY password
DEFAULT TABLESPACE data_ts
QUOTA 100M ON test_ts
QUOTA 500K ON data_ts
TEMPORARY TABLESPACE temp_ts
PROFILE clerk;

ユーザーの割当て制限では、各表領域の一定量のディスク領域を個別に割り当てるか、またはすべての表領域のディスク領域を無制限に割り当てるかのどちらかを選択できます。一定量の割当て制限を設定すると、ユーザーのオブジェクトによってデータベースの領域が大量に使用されるのを防止できます。表領域に割り当てることができる最大領域は2 TBです。より多くの領域が必要な場合は、QUOTA句にUNLIMITEDを指定します。

ユーザーの表領域に対する割当て制限は、ユーザーを作成するときに割り当てることができ、後で割当て制限の追加または変更もできます。(USER_TS_QUOTASビューを問い合せることで、既存ユーザーの割当て制限を確認できます。)新しい割当て制限が古い割当て制限より少ない場合は、次の状況が当てはまります。

- ユーザーがすでに新しい表領域割当て制限を超過している場合は、これらのオブジェクトをあわせた領域が新しい割当て制限より少なくならないかぎり、その表領域のユーザー・オブジェクトに追加の領域を割り当てることはできません。

- ユーザーが新しい表領域割当て制限を超過していない場合、つまり表領域内でユーザーのオブジェクトが使用している領域が新しい表領域割当て制限よりも少ない場合は、そのユーザーのオブジェクトに新しい割当て制限までの領域を割り当てることができます。

表領域でのユーザー・オブジェクトに対する割当て限度の制限

表領域内のユーザー・オブジェクトの割当て制限を制限するには、ALTER USER SQL文を使用してユーザーの現在の割当て制限を0 (ゼロ)に変更します。ゼロの割当て制限が割り当てられると、表領域内のユーザーのオブジェクトはそのまま残り、ユーザーは引き続き新規オブジェクトを作成できますが、既存のオブジェクトには新しい領域が割り当てられなくなります。たとえば、このユーザーの既存の表の1つにデータを挿入することはできません。操作は失敗し、 ORA-1536表に対する領域割当て制限を使い果たしました。エラーが発生します。

ユーザーへのUNLIMITED TABLESPACEシステム権限の付与

データベース内の表領域を無制限に使用することをユーザーに許可するには、そのユーザーにUNLIMITED TABLESPACEシステム権限を付与します。これによって、ユーザーに対して明示的に指定されている表領域割当て制限がすべて置き換えられます。後で権限を取り消す場合、個々の表領域に対して割当て制限を明示的に付与する必要があります。この権限は、ロールに対してではなく、ユーザーに対してのみ付与できます。

UNLIMITED TABLESPACEシステム権限を付与する前に、この方法のメリットとデメリットを考慮する必要があります。

メリット

データベースのすべての表領域に無制限にアクセスできる権限を1つの文でユーザーに付与できます。

デメリット

- この権限によって、そのユーザーに対する明示的な表領域割当て制限がすべて置き換えられます。

- UNLIMITED TABLESPACEシステム権限を持つユーザーから表領域へのアクセス権を選択的に取り消すことはできません。この権限を取り消した後でのみ、選択的または制限付きアクセス権を付与できます。

ユーザーに対する一時表領域の割当て

各ユーザーには、一時表領域を割り当てる必要があります。ユーザーが一時セグメントを必要とするSQL文を実行すると、このセグメントはそのユーザーの一時表領域に格納されます。これらの一時セグメントは、ソート操作または結合操作の実行時にシステムによって作成されます。一時セグメントは、すべての表領域のリソースに関する権限を持つSYSが所有します。

次の例では、jwardの一時表領域はtemp_tsです。これは一時セグメントのみを格納するために明示的に作成された表領域です。

CREATE USER jward
IDENTIFIED BY password
DEFAULT TABLESPACE data_ts
QUOTA 100M ON test_ts
QUOTA 500K ON data_ts
TEMPORARY TABLESPACE temp_ts
PROFILE clerk;

一時表領域を作成するには、CREATE TEMPORARY TABLESPACE SQL文を使用します。

ユーザーの一時表領域を明示的に割り当てない場合、そのユーザーには、データベース作成時に指定された、または作成後にALTER DATABASE文によって指定されたデフォルト一時表領域が割り当てられます。デフォルトの一時表領域が明示的に割り当てられていない場合、デフォルトはSYSTEM表領域またはシステム管理者が設定した別のデフォルト永続表領域になります。ユーザー・データはSYSTEM表領域に格納しないでください。一時表領域として使用する表領域を明示的に割り当てることによって、一時セグメントとそれ以外のタイプのセグメントとの間で発生するファイルの競合が解消されます。

注意:
SYSTEM表領域がローカル管理の場合、ユーザーには特定のデフォルト(ローカル管理)一時表領域を割り当てる必要があります。永続的なローカル管理表領域には、一時オブジェクトを格納できないため、SYSTEM表領域の使用はデフォルトで禁止されます。

ユーザー作成時に、そのユーザーの一時表領域を設定しておき、作成後にALTER USER文を使用して変更できます。個々の一時表領域を割り当てるかわりに、表領域グループを設定することもできます。

関連項目:

- 『Oracle Database管理者ガイド』の一時表領域に関する項

- 『Oracle Database管理者ガイド』の複数の一時表領域: 表領域グループの使用に関する項

ユーザーに対するプロファイルの指定

ユーザーの作成時に、プロファイルを指定できます。プロファイルとは、データベース・リソースとそのデータベースへのパスワード・アクセスに関する一連の制限です。プロファイルを指定しない場合、ユーザーにはデフォルト・プロファイルが割り当てられます。

次の例は、ユーザーにプロファイルを割り当てる方法を示しています。

CREATE USER jward
IDENTIFIED BY password
DEFAULT TABLESPACE data_ts
QUOTA 100M ON test_ts
QUOTA 500K ON data_ts
TEMPORARY TABLESPACE temp_ts
PROFILE clerk;

関連項目:
「プロファイルによるリソースの管理」

ユーザーに対するデフォルト・ロールの設定

ロールは、関連する権限のグループに名前を付けたもので、ユーザーや他のロールに付与します。デフォルト・ロールは、ユーザーがセッションを作成したときに、自動的にそのユーザーに対して使用可能になります。ユーザーには複数のデフォルト・ロールを割り当てることができますが、割り当てなくてもかまいません。

CREATE USER文ではユーザーのデフォルト・ロールを設定できません。ユーザーを最初に作成すると、ユーザーのデフォルト・ロール設定はALLであり、ユーザーにその後に付与されるすべてのロールがデフォルト・ロールになります。ALTER USER文を使用して、ユーザーのデフォルト・ロールを変更します。例:

GRANT USER jward clerk_role;

ALTER USER jward DEFAULT ROLE clerk_role;

ロールをユーザーのデフォルト・ロールにするには、そのロールがユーザーに付与されている必要があります。

関連項目:
「ユーザー・ロールの管理」

ユーザー・アカウントの変更

この項の内容は、次のとおりです。

- ユーザー・アカウントの変更について

- ALTER USER文を使用したユーザー・アカウントの変更

- SYS以外のユーザー・パスワードの変更

- SYSユーザー・パスワードの変更

ユーザー・アカウントの変更について

ユーザーは、自分のパスワードを変更できます。ただし、ユーザーのセキュリティ・ドメインの他のオプションを変更するには、ALTER USERシステム権限が必要です。通常は、セキュリティ管理者のみがこのシステム権限を持ちます。これは、この権限によってすべてのユーザーのセキュリティ・ドメインを変更できるためです。この権限には、データベースの任意の表領域に対するユーザーの表領域割当て制限を設定する許可が含まれています。これは、変更を実行するユーザーが、指定した表領域に対する割当て制限を持っていない場合も同じです。

ALTER USER文を使用したユーザー・アカウントの変更

ユーザーのセキュリティ設定を変更するには、ALTER USER SQL文を使用します。ユーザーのセキュリティ設定の変更は、現行セッションではなく、それより後のユーザー・セッションから反映されます。

例2-2に、ALTER USER文を使用してユーザーavyrrosのセキュリティ設定を変更する方法を示します。

例2-2 ユーザー・アカウントの変更

ALTER USER avyrros
IDENTIFIED EXTERNALLY
DEFAULT TABLESPACE data_ts
TEMPORARY TABLESPACE temp_ts
QUOTA 100M ON data_ts
QUOTA 0 ON test_ts
PROFILE clerk;

このALTER USER文によって、ユーザーavyrrosのセキュリティ設定は次のように変更されます。

- 認証方式は、ユーザーavyrrosのオペレーティング・システム・アカウントが使用されます。

- ユーザーAVYRROSのデフォルト表領域と一時表領域が明示的に設定されます。

- ユーザーavyrrosのDATA_TS表領域に対する割当て制限が100MBになります。

- ユーザーavyrrosのtest_tsに対する割当て制限が取り消されます。

- ユーザーavyrrosがclerkプロファイルに割り当てられます。

SYS以外のユーザー・パスワードの変更

ほとんどのユーザーが、次のようにPASSWORD文を使用して自分のパスワードを変更できます。

PASSWORD andy
Changing password for andy
New password: password
Retype new password: password

ユーザーが自分のパスワードを変更するには、特別な権限(データベースへの接続およびセッションの作成権限以外)は不要です。ユーザーには、自分のパスワードを頻繁に変更することを薦めてください。パスワードを保護する最適な方法に関するガイドラインは、「パスワードの保護に関するガイドライン」を参照してください。ALL_USERSビューを問い合せることで、現行データベース・インスタンスの既存のユーザーを検索できます。

ユーザーは、ALTER USER SQL文を使用して自分のパスワードを変更することもできます。例:

ALTER USER andy IDENTIFIED BY password

ただし、セキュリティを強化するには、PASSWORD文を使用してアカウントのパスワードを変更します。ALTER USER文では、新規パスワードが画面に表示されるため、他者に見られる可能性があります。PASSWORDコマンドでは新規パスワードが表示されないため、自分のみが把握し、他者に知られることはありません。どちらの場合も、パスワードはネットワーク上で暗号化されます。

ユーザーが認証方式を切り替えるには、PASSWORDとALTER USER権限が必要です。通常、この権限を持つのは管理者のみです。

関連項目:

- パスワードを作成するための最低要件は、「パスワードの最低要件」を参照してください。

- パスワードを保護する別の方法については、「パスワードの保護に関するガイドライン」を参照してください。

- Oracle Databaseユーザーが使用できる認証方式の詳細は、第3章「認証の構成」を参照してください。

SYSユーザー・パスワードの変更

SYSユーザーのパスワードを変更する場合は、 ORAPWDコマンドライン・ユーティリティを使用して、使用するパスワードが含まれたパスワード・ファイルを新規作成する必要があります。ALTER USER文やPASSWORDコマンドを使用したSYSユーザー・パスワードの変更はしないでください。次のことに注意してください。

- SYSユーザー・アカウントは、ほとんどの内部再帰的SQLが使用します。そのため、ALTER USER文を使用してこのパスワードを変更しようとするときにデータベースがオープンしていると、デッドロックが生じる可能性があります。

- ALTER USERを使用してSYSユーザー・パスワードを変更しようとする場合に、インスタンス初期化パラメータREMOTE_LOGIN_PASSWORDFILEがSHAREDに設定されていると、SYSパスワードを変更できません。ALTER USER文は、ORA-28046: SYSのパスワードは変更できませんのエラーで失敗します。

例2-3では、ORAPWDを使用して新しいSYSパスワードが含まれたパスワード・ファイルを作成する方法を示しています。この例では、新規パスワードはorapworclという名前のパスワード・ファイルに格納されます。(このパスワード・ファイルがすでに存在する場合は、 OPW-00005: 同一名のファイルがあります。 - 削除または名前を変更してください。のエラーにより他の名前を選択するように警告されます。既存のパスワード・ファイルを上書きする場合は、force=y引数をORAPWDコマンドに追加してください。)

例2-3 ORAPWDを使用したSYSユーザー・パスワードの変更

orapwd file='orapworcl'
Enter password for SYS: new_password

関連項目:
orapwdコマンド構文と引数の詳細は、『Oracle Database管理者ガイド』を参照してください。

ユーザー・リソース制限の構成

この項の内容は、次のとおりです。

- ユーザー・リソース制限の概要

- システム・リソースのタイプと制限

- プロファイルのリソース制限の値の決定

- プロファイルによるリソースの管理

ユーザー・リソース制限の概要

ユーザーのセキュリティ・ドメインの一部として、各ユーザーが使用できる各種のシステム・リソースの容量に制限を設定できます。そうすることで、CPUタイムなど貴重なシステム・リソースが無制限に消費されることを防ぐことができます。リソース制限を設定するには、データベース・リソース・マネージャを使用します。データベース・リソース・マネージャは、『Oracle Database管理者ガイド』で説明されています。

このリソース制限機能は、システム・リソースに多額の費用がかかる大規模なマルチ・ユーザー・システムでは非常に有効です。1人以上のユーザーが過度にリソースを使用すると、データベースの他のユーザーに有害な影響を与える可能性があります。シングル・ユーザー・データベースや小規模なマルチ・ユーザー・データベースの場合は、ユーザーがシステム・リソースを消費しても影響は少ないため、システム・リソース機能はそれほど重要ではありません。

ユーザーのリソース制限は、データベース・リソース・マネージャを使用して管理します。パスワード管理の作業環境は、ユーザーごとに個別にプロファイルを使用して設定するか、または多数のユーザー用のデフォルト・プロファイルを使用して設定できます。それぞれのOracleデータベースに指定できるプロファイルの数に、制限はありません。Oracle Databaseでは、セキュリティ管理者が、プロファイルによるリソース制限の規定を全体的に使用可能または使用禁止に設定できます。

リソース制限を設定すると、ユーザーによるセッション作成時に、パフォーマンスがわずかに低下します。これは、各ユーザーがデータベースに接続した時点で、そのユーザーのすべてのリソース制限データがロードされるためです。

関連項目:
リソース管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

システム・リソースのタイプと制限

Oracle Databaseでは、CPUタイムや論理読取りなど様々なタイプのシステム・リソースの使用を制限できます。一般にこれらのリソースの各々を、セッション・レベル、コール・レベル、または両方のレベルで制御できます。これを次のセクションで説明します。

- ユーザー・セッション・レベルの制限

- データベース・コール・レベルの制限

- CPUタイムの制限

- 論理読取りの制限

- その他のリソース制限

ユーザー・セッション・レベルの制限

ユーザーがデータベースに接続するたびに、セッションが作成されます。それぞれのセッションは、Oracle Databaseを実行するコンピュータのCPUタイムとメモリーを使用します。複数のリソース制限をセッション・レベルで設定できます。

ユーザーがセッション・レベルのリソース限度を超えると、Oracle Databaseは現在の文を終了(ロールバック)して、セッション限度に達したことを示すメッセージを返します。この時点で、カレント・トランザクションのそれ以前の文のすべてがそのまま残り、ユーザーが実行できる操作のみがCOMMIT、ROLLBACK、または切断になります(この場合、カレント・トランザクションはコミットされます)。他のすべての操作はエラーになります。トランザクションがコミットまたはロールバックされた後も、ユーザーはこれ以上の作業をカレント・セッション中は完了できません。

データベース・コール・レベルの制限

ユーザーがSQL文を実行するたびに、Oracle Databaseでは、いくつかのステップが実行され文が処理されます。この処理では、データベースに対して複数のコールが異なる実行フェーズの一部として発行されます。1回のコールで過度にシステムが使用されないように、Oracle Databaseでは、複数のリソース制限をコール・レベルで設定できます。

ユーザーがコール・レベルのリソース制限を超えると、Oracle Databaseは文の処理を停止してその文をロールバックし、エラーを戻します。ただし、カレント・トランザクションのそれ以前の文の結果はそのまま残り、そのユーザー・セッションは接続されたままになります。

CPUタイムの制限

SQL文やその他のタイプのコールがOracle Databaseに発行されると、そのコールを処理するために一定量のCPUタイムが必要になります。平均的なコールであれば、わずかなCPUタイムですみます。ただし、大量のデータや冗長な問合せを伴うSQL文はCPUタイムを大量に使用することがあるため、他の処理に使用できるCPUタイムが少なくなります。

CPUタイムが無制限に消費されないようにするため、1回のコール当たりのCPUタイムと、1つのセッション中にOracle Databaseコールに使用されるCPUタイムの合計に対して、固定した制限または動的な制限を設定できます。これらの制限は、コールやセッションに使用される1/100秒(0.01秒)単位のCPUタイムで設定し、測定されます。

論理読取りの制限

入出力(I/O)は、データベース・システムで最もリソースの使用量が多い操作の1つです。I/Oを集中的に実行するSQL文は、メモリーとディスクの使用を独占することがあるため、他のデータベース操作がこれらのリソースをめぐって競合する原因になる可能性があります。

単一の原因による過度のI/Oが発生しないようにするために、1コール当たりおよび1セッション当たりの論理データ・ブロック読取り数を制限できます。論理データ・ブロック読取りには、メモリーとディスクの両方からの論理データ・ブロック読取りが含まれます。これらの制限は、1コールまたは1セッション中に実行されるブロック読取りの数として設定し、測定されます。

その他のリソース制限

Oracle Databaseでは、いくつかのその他のセッション・レベルのリソース制限が提供されています。

- ユーザー当たりの同時実行セッション数の制限。各ユーザーは、事前に定義された数まで同時実行セッションを作成できます。

- セッションのアイドル時間の制限。1つのセッションでのコール間の時間がアイドル制限時間に達すると、カレント・トランザクションがロールバックされてセッションは終了し、そのセッションのリソースはシステムに戻されます。次のコールは、ユーザーがインスタンスから切断されたことを示すエラーを受け取ります。この制限は、分単位の経過時間として設定します。

注意:
セッションがアイドル時間の制限を超えたために終了すると、その少し後に、終了したセッションの後処理としてプロセス・モニター(PMON)・バックグラウンド・プロセスがクリーン・アップを実行します。PMONがこのプロセスを完了するまでは、終了したセッションも、セッションまたはユーザー・レベルのリソース制限に加算されます。

- セッション当たりの経過接続時間の制限。セッションの持続時間が経過制限時間を超えると、カレント・トランザクションがロールバックされてセッションが削除され、そのセッションのリソースがシステムに戻されます。この制限は、分単位の経過時間として設定します。

注意:
Oracle Databaseは、経過アイドル時間や経過接続時間を絶えず監視しているわけではありません。絶えず監視した場合、システム・パフォーマンスが低下します。そのかわり数分ごとにチェックします。このため、Oracle Databaseがこの制限を規定してからセッションを終了させるまでの間に、セッションはこの制限をわずかに(5分など)超える可能性があります。

- セッションのプライベート・システム・グローバル領域(SGA)(プライベートSQL領域に使用)の容量の制限。この制限が重要になるのは、共有サーバーの構成を使用するシステムの場合のみです。それ以外のシステムの場合、プライベートSQL領域はプログラム・グローバル領域(PGA)内にあります。この制限は、インスタンスのSGAに使用するメモリーのバイト数として設定します。KBまたはMBで指定するには、KまたはMの文字を使用します。

関連項目:
リソース制限を使用可能および使用禁止にする手順は、次を参照してください。

- 「データベース・ユーザーとプロファイルに関する情報の検索」

- 「ユーザー・ロールの管理」

- リソース管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

プロファイルのリソース制限の値の決定

プロファイルを作成し、そのプロファイルに含めるリソース制限を決定する前に、各リソース制限について適切な値を決定する必要があります。これらの値は、典型的なユーザーが実行する操作のタイプを基準として決定できます。たとえば、あるクラスのユーザーが通常は大量の論理データ・ブロック読取りを実行しない場合は、ALTER RESOURCE COST SQL文を使用して、LOGICAL_READS_PER_SESSION設定を控えめに設定します。

通常、ユーザー・プロファイルの適切なリソース制限値を決定するには、それぞれのタイプのリソースの使用状況について履歴情報を収集するのが最善です。たとえば、データベース管理者やセキュリティ管理者は、AUDIT SESSION句を使用して、CONNECT_TIMEおよびLOGICAL_READS_PER_SESSIONの制限値についての情報を収集できます。

その他の制限値の統計情報は、Oracle Enterprise Manager(またはSQL*Plus)のモニター機能、特に統計モニターを使用して収集できます。

関連項目:

- 「データ・ディクショナリ・ビューを使用したユーザーとプロファイルに関する情報の検索」

- 第9章「監査を使用したセキュリティ・アクセスの検証」

- Database Controlの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- 監視機能の詳細は、Enterprise Managerのオンライン・ヘルプを参照してください。

プロファイルによるリソースの管理

プロファイルとは、ユーザーのデータベース使用とインスタンス・リソースを制限する一連のリソース制限およびパスワード・パラメータに名前を付けたものです。ユーザーごとのプロファイルの割当て、およびすべてのユーザーに対するデフォルト・プロファイルの割当てが可能です。各ユーザーに割り当てることができるプロファイルは1つのみで、新しいプロファイルを作成すると、旧バージョンと置き換えられます。

ユーザー・プロファイルを作成して管理する必要があるのは、リソース制限がデータベースのセキュリティ・ポリシーの要件である場合のみです。プロファイルを使用するには、最初にデータベース内のユーザーの関連タイプを分類します。ロールを使用して関連ユーザーの権限を管理するのと同様に、プロファイルを使用して関連ユーザーのリソース制限を管理します。データベース内のすべてのタイプのユーザーを含めるために必要なプロファイル数を決定してから、プロファイルごとに適切なリソース制限を決定します。

一般的に、プロファイルとはユーザーに適用される属性の集合で、それらの属性を共有する複数ユーザーの中の任意のユーザーに関する単一の参照になります。Oracle Internet Directoryのユーザー・プロファイルには、各ユーザーのディレクトリ使用と認証に関連した属性が含まれています。同様に、Oracle Label Securityのプロファイルには、Oracle Label Securityのユーザー管理や操作管理に役立つ属性が含まれています。プロファイル属性にはシステム・リソースに関する制限を含めることができます。データベース・リソース・マネージャを使用すると、これらのタイプのリソース制限を設定できます。

プロファイルのリソース制限が適用されるのは、対応するデータベースのリソース制限が使用可能な場合のみです。このリソース制限が使用可能になるのは、データベースの起動前(RESOURCE_LIMIT初期化パラメータを使用)またはオープン中(ALTER SYSTEM文を使用)のいずれかです。

パスワード・パラメータはプロファイル内にありますが、RESOURCE_LIMITまたはALTER SYSTEMの影響は受けず、パスワード管理は常に使用可能です。Oracle Databaseでは、主にデータベース・リソース・マネージャによって、リソースの割当てと制限が処理されます。

関連項目:

- リソース管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

- リソース情報の表示については、「データベース・ユーザーとプロファイルに関する情報の検索」を参照してください。

- ALTER SYSTEMまたはRESOURCE_LIMITの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

プロファイルの作成

認可されたデータベース・ユーザーは、プロファイルの作成、ユーザーへの割当て、変更および削除を(CREATE USERまたはALTER USER文を使用して)随時実行できます。プロファイルは、ロールや他のプロファイルではなく、ユーザーにのみ割り当てることができます。プロファイルの割当ては現行のセッションには影響を与えず、それより後のセッションにのみ有効です。プロファイルを外部ユーザーまたは グローバル・ユーザーに割り当てる際、それらのユーザーに対してパスワード・パラメータは有効にならないことに注意してください。

現行のプロファイルに関する情報を検索するには、DBA_PROFILESビューを問い合せます。

関連項目:

- プロファイルの管理に使用されるSQL文(ALTER PROFILE、CREATE PROFILE、およびDROP PROFILE)の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- リソース管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 「ユーザー・アカウントの作成」

- 「ユーザー・アカウントの変更」

プロファイルの削除

プロファイルを削除するには、DROP PROFILEシステム権限が必要です。SQL文DROP PROFILEを使用して、プロファイル(デフォルト・プロファイル以外)を削除できます。ユーザーに現在割り当てられているプロファイルを正常に削除するには、CASCADEオプションを使用します。

次の文は、プロファイルclerkを削除します。このプロファイルがユーザーに割り当てられていても削除されます。

DROP PROFILE clerk CASCADE;

削除するプロファイルに現在割り当てられているユーザーは、自動的にDEFAULTプロファイルに割り当てられます。DEFAULTプロファイルは削除できません。プロファイルを削除しても、現在アクティブなセッションには影響を与えません。プロファイルの削除後に作成されたセッションのみが、変更されたプロファイル割当てを使用します。

ユーザー・アカウントの削除

ユーザー・アカウントを削除すると、Oracle Databaseではこのユーザー・アカウントおよび対応するスキーマがデータ・ディクショナリから削除されます。さらに、ユーザー・スキーマに含まれているすべてのスキーマ・オブジェクトも(存在する場合)削除されます。

注意:

- ユーザーのスキーマとそれに対応するオブジェクトは残したままで、データベースへのアクセスを拒否する場合は、そのユーザーからCREATE SESSION権限を取り消してください。

- SYSユーザーまたはSYSTEMユーザーは削除しないでください。これらのユーザーを削除すると、データベースが破損します。

現在データベースに接続されているユーザーは削除できません。接続中のユーザーを削除するには、最初にKILL SESSION句を指定したSQL文ALTER SYSTEMを使用して、そのユーザーのセッションを停止する必要があります。V$SESSIONビューを問い合せることで、セッションID(SID)を検索できます。

例2-4に、V$SESSIONを問い合せる方法を示し、ユーザーANDYのセッションID、シリアル番号およびユーザー名を表示します。

例2-4 ユーザーのセッションIDに関するV$SESSIONの問合せ

SELECT SID, SERIAL#, USERNAME FROM V$SESSION;

SID         SERIAL#     USERNAME
------- --------------- ----------------------
127          55234      ANDY
...

例2-5に、ユーザーandyのセッションを停止する方法を示します。

例2-5 ユーザー・セッションの削除

ALTER SYSTEM KILL SESSION '127, 55234';

データベースからユーザーを削除するには、DROP USER文を使用します。ユーザーとそのユーザーのスキーマ・オブジェクト(ある場合)をすべて削除するには、DROP USERシステム権限が必要です。DROP USERシステム権限は強力な権限であるため、通常はセキュリティ管理者のみがこの権限を持ちます。

ユーザーのスキーマに依存型のスキーマ・オブジェクトが含まれている場合に、ユーザーと対応付けられているすべてのオブジェクト、およびそのユーザーの表に依存している外部キーをすべて削除するには、CASCADEオプションを使用します。CASCADEを指定していない場合は、ユーザーのスキーマに依存型のオブジェクトが含まれていると、エラー・メッセージが戻され、ユーザーは削除されません。

スキーマ内にオブジェクトを格納しているユーザーを削除する前に、スキーマ内のオブジェクトおよびそれらを削除する場合の影響を徹底的に調べます。DBA_OBJECTSビューを問い合せると、特定のユーザーが所有しているオブジェクトを確認できます。

例2-6に、ユーザーandyが所有するオブジェクトを検索する方法を示します。

例2-6 ユーザーが所有するオブジェクトの検索

SELECT OWNER, OBJECT_NAME FROM DBA_OBJECTS WHERE OWNER LIKE 'ANDY';

(ユーザー名を大文字で入力します。)事前に認識できない連鎖的な影響に注意してください。たとえば、表を所有するユーザーを削除する場合は、ビューまたはプロシージャがその表に依存していないかどうかを確認してください。

例2-7では、ユーザーandyとそれに対応付けられたすべてのオブジェクト、およびandyが所有する表に依存するすべての外部キーを削除します。

例2-7 ユーザー・アカウントの削除

DROP USER andy CASCADE;

関連項目:
セッション終了の詳細は、『Oracle Database管理者ガイド』を参照してください。

データベース・ユーザーとプロファイルに関する情報の検索

この項の内容は、次のとおりです。

- データ・ディクショナリ・ビューを使用したユーザーとプロファイルに関する情報の検索

- すべてのユーザーとその関連情報のリスト

- すべての表領域割当て制限のリスト

- すべてのプロファイルと割り当てられている制限のリスト

- 各ユーザー・セッションのメモリー使用の表示

データ・ディクショナリ・ビューを使用したユーザーとプロファイルに関する情報の検索

表2-1に、データベース・ユーザーとプロファイルに関する情報が含まれたデータ・ディクショナリ・ビューを示します。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表2-1 ユーザーとプロファイルに関する情報を表示するデータ・ディクショナリ・ビュー

ビュー

説明

ALL_OBJECTS

現行ユーザーがアクセス可能なすべてのオブジェクトが表示されます。

ALL_USERS

現行ユーザーに対して表示可能なユーザーがリストされますが、それらの記述は表示されません。

DBA_PROFILES

すべてのプロファイルとそれぞれの制限が表示されます。

DBA_TS_QUOTAS

ユーザーの表領域割当て制限が表示されます。

DBA_OBJECTS

データベース内のすべてのオブジェクトが表示されます。

DBA_USERS

データベースのすべてのユーザーの記述が表示されます。

DBA_USERS_WITH_DEFPWD

デフォルト・パスワードが設定されているすべてのユーザー・アカウントがリストされます。

PROXY_USERS

他のユーザーの識別情報を引き継ぐことができるユーザーの記述が表示されます。

RESOURCE_COST

セッション当たりのCPU、セッション当たりの読取り、接続時間およびSGAの観点から各リソースのコストがリストされます。

USER_PASSWORD_LIMITS

ユーザーに割り当てられているパスワード・プロファイル・パラメータが表示されます。

USER_RESOURCE_LIMITS

現行ユーザーのリソース制限が表示されます。

USER_TS_QUOTAS

ユーザーの表領域割当て制限が表示されます。

USER_OBJECTS

現行ユーザーが所有するすべてのオブジェクトが表示されます。

USER_USERS

現行ユーザーの記述のみが表示されます。

V$SESSION

現行セッションごとに、ユーザー名を含んだセッション情報が表示されます。

V$SESSTAT

ユーザー・セッションの統計がリストされます。

V$STATNAME

V$SESSTATビューに表示される統計のデコードされた統計名が表示されます。

次の各項では、これらのビューの使用例を示します。各例では、次の文がすでに実行されていることを前提としています。

CREATE PROFILE clerk LIMIT
SESSIONS_PER_USER 1
IDLE_TIME 30
CONNECT_TIME 600;

CREATE USER jfee
IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp_ts
QUOTA 500K ON users
PROFILE clerk;

CREATE USER dcranney
IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp_ts
QUOTA unlimited ON users;

CREATE USER userscott
IDENTIFIED BY password;

すべてのユーザーとその関連情報のリスト

データベースに定義されているすべてのユーザーとそのユーザーに関連する情報を検索するには、DBA_USERSビューを問い合せます。DBA_USERSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

例:

SELECT USERNAME, PROFILE, ACCOUNT_STATUS, AUTHENTICATION_TYPE FROM DBA_USERS;

USERNAME        PROFILE         ACCOUNT_STATUS   AUTHENTICATION_TYPE
--------------- --------------- ---------------  -------------------
SYS             DEFAULT         OPEN             PASSWORD
SYSTEM          DEFAULT         OPEN             PASSWORD
USERSCOTT       DEFAULT         OPEN             PASSWORD
JFEE            CLERK           OPEN             GLOBAL
DCRANNEY        DEFAULT         OPEN             EXTERNAL

すべての表領域割当て制限のリスト

DBA_TS_QUOTASビューを使用すると、各ユーザーに明示的に割り当てられている表領域割当て制限がすべてリストされます。(このビューの詳細は、『Oracle Databaseリファレンス』を参照してください)。例:

SELECT * FROM DBA_TS_QUOTAS;

TABLESPACE    USERNAME    BYTES     MAX_BYTES    BLOCKS    MAX_BLOCKS
----------    ---------  --------   ----------   -------   ----------
USERS         JFEE              0       512000         0          250
USERS         DCRANNEY          0           -1         0           -1

固有の割当て制限が割り当てられている場合は、正確な数値がMAX_BYTES列に示されます。この数値は常にデータベース・ブロック・サイズの倍数となるため、倍数でない表領域割当て制限を指定すると、適切な値に切り上げられます。無制限割当ての場合は、-1が表示されます。

すべてのプロファイルと割り当てられている制限のリスト

DBA_PROFILEビューには、データベース内のすべてのプロファイル、および各プロファイルの制限ごとの関連設定がリストされます。(このビューの詳細は、『Oracle Databaseリファレンス』を参照してください)。例:

SELECT * FROM DBA_PROFILES ORDER BY PROFILE;

PROFILE             RESOURCE_NAME              RESOURCE_TYPE  LIMIT
-----------------   -------------------------  -------------  --------------
CLERK               COMPOSITE_LIMIT            KERNEL         DEFAULT
CLERK               FAILED_LOGIN_ATTEMPTS      PASSWORD       DEFAULT
CLERK               PASSWORD_LIFE_TIME         PASSWORD       DEFAULT
CLERK               PASSWORD_REUSE_TIME        PASSWORD       DEFAULT
CLERK               PASSWORD_REUSE_MAX         PASSWORD       DEFAULT
CLERK               PASSWORD_VERIFY_FUNCTION   PASSWORD       DEFAULT
CLERK               PASSWORD_LOCK_TIME         PASSWORD       DEFAULT
CLERK               PASSWORD_GRACE_TIME        PASSWORD       DEFAULT
CLERK               PRIVATE_SGA                KERNEL         DEFAULT
CLERK               CONNECT_TIME               KERNEL         600
CLERK               IDLE_TIME                  KERNEL         30
CLERK               LOGICAL_READS_PER_CALL     KERNEL         DEFAULT
CLERK               LOGICAL_READS_PER_SESSION  KERNEL         DEFAULT
CLERK               CPU_PER_CALL               KERNEL         DEFAULT
CLERK               CPU_PER_SESSION            KERNEL         DEFAULT
CLERK               SESSIONS_PER_USER          KERNEL         1
DEFAULT             COMPOSITE_LIMIT            KERNEL         UNLIMITED
DEFAULT             PRIVATE_SGA                KERNEL         UNLIMITED
DEFAULT             SESSIONS_PER_USER          KERNEL         UNLIMITED
DEFAULT             CPU_PER_CALL               KERNEL         UNLIMITED
DEFAULT             LOGICAL_READS_PER_CALL     KERNEL         UNLIMITED
DEFAULT             CONNECT_TIME               KERNEL         UNLIMITED
DEFAULT             IDLE_TIME                  KERNEL         UNLIMITED
DEFAULT             LOGICAL_READS_PER_SESSION  KERNEL         UNLIMITED
DEFAULT             CPU_PER_SESSION            KERNEL         UNLIMITED
DEFAULT             FAILED_LOGIN_ATTEMPTS      PASSWORD       10
DEFAULT             PASSWORD_LIFE_TIME         PASSWORD       180
DEFAULT             PASSWORD_REUSE_MAX         PASSWORD       UNLIMITED
DEFAULT             PASSWORD_LOCK_TIME         PASSWORD       1
DEFAULT             PASSWORD_GRACE_TIME        PASSWORD       7
DEFAULT             PASSWORD_VERIFY_FUNCTION   PASSWORD       UNLIMITED
DEFAULT             PASSWORD_REUSE_TIME        PASSWORD       UNLIMITED
32 rows selected.

デフォルト・プロファイル値を検索するには、次の問合せを実行します。

SELECT * FROM DBA_PROFILES WHERE PROFILE = 'DEFAULT';

PROFILE             RESOURCE_NAME              RESOURCE_TYPE  LIMIT
-----------------   -------------------------  -------------  --------------
DEFAULT             COMPOSITE_LIMIT            KERNEL         UNLIMITED
DEFAULT             SESSIONS_PER_USER          KERNEL         UNLIMITED
DEFAULT             CPU_PER_SESSION            KERNEL         UNLIMITED
DEFAULT             CPU_PER_CALL               KERNEL         UNLIMITED
DEFAULT             LOGICAL_READS_PER_SESSION  KERNEL         UNLIMITED
DEFAULT             LOGICAL_READS_PER_CALL     KERNEL         UNLIMITED
DEFAULT             IDLE_TIME                  KERNEL         UNLIMITED
DEFAULT             CONNECT_TIME               KERNEL         UNLIMITED
DEFAULT             PRIVATE_SGA                KERNEL         UNLIMITED
DEFAULT             FAILED_LOGIN_ATTEMPTS      PASSWORD       10
DEFAULT             PASSWORD_LIFE_TIME         PASSWORD       180
DEFAULT             PASSWORD_REUSE_TIME        PASSWORD       UNLIMITED
DEFAULT             PASSWORD_REUSE_MAX         PASSWORD       UNLIMITED
DEFAULT             PASSWORD_VERIFY_FUNCTION   PASSWORD       NULL
DEFAULT             PASSWORD_LOCK_TIME         PASSWORD       1
DEFAULT             PASSWORD_GRACE_TIME        PASSWORD       7

16 rows selected.

各ユーザー・セッションのメモリー使用の表示

各ユーザー・セッションのメモリー使用を検索するには、V$SESSIONビューを問い合せます。(このビューの詳細は、『Oracle Databaseリファレンス』を参照してください)。次の問合せを実行するとすべてのカレント・セッションがリストされ、各セッションのOracle Databaseユーザーと現在のユーザー・グローバル領域(UGA)メモリー使用が示されます。

SELECT USERNAME, VALUE || 'bytes' "Current UGA memory"
FROM V$SESSION sess, V$SESSTAT stat, V$STATNAME name
WHERE sess.SID = stat.SID
AND stat.STATISTIC# = name.STATISTIC#
AND name.NAME = 'session uga memory';

USERNAME                       Current UGA memory
------------------------------ ---------------------------------------------
18636bytes
17464bytes
19180bytes
18364bytes
39384bytes
35292bytes
17696bytes
15868bytes
USERSCOTT                      42244bytes
SYS                            98196bytes
SYSTEM                         30648bytes

11 rows selected.

インスタンスの起動以降、各セッションに割り当てられた最大のUGAメモリーを表示するには、この問合せの'session uga memory'を'session uga memory max'に置き換えてください。

3 認証の構成

この章の内容は、次のとおりです。

- 認証の概要

- パスワード保護の構成

- データベース管理者の認証

- データベースを使用したユーザーの認証

- オペレーティング・システムを使用したユーザーの認証

- ネットワークを使用したユーザーの認証

- グローバルなユーザー認証と認可の構成

- ユーザーとパスワード認証のための外部サービスの構成

- 複数層の認証と認可の使用

- 複数層環境でのユーザー識別情報の保持

- ユーザー認証に関する情報の検索

認証の概要

認証とは、データ、リソースまたはアプリケーションの使用を希望するエンティティ(ユーザーやデバイスなど)の識別を検証することです。識別を検証することで、その後の対話に関する信頼関係が確立されます。認証によって、アクセスとアクションを特定の識別にリンクでき、アカウンタビリティも有効化されます。認証後は、認可プロセスでそのエンティティが実行できるアクセスとアクションのレベルを許可または制限できます。

Oracle Databaseのデータベース・ユーザーと非データベース・ユーザーの両方を認証できます。簡潔性を考慮して、すべてのデータベース・ユーザーに同じ認証方式を使用するのが一般的ですが、Oracle Databaseでは1つのデータベース・インスタンスで一部またはすべての方法を使用できます。Oracle Databaseでは、データベース管理者が特別なデータベース操作を実行するため、そのための特別な認証プロシージャが必要です。また、Oracle Databaseでは、ネットワーク認証のセキュリティを確保するために送信時にパスワードの暗号化も実行されます。

認証後は、認可プロセスでそのエンティティが実行できるアクセスとアクションのレベルを許可または制限できます。認可については、第4章「権限とロール認可の構成」を参照してください。

パスワード保護の構成

この項の内容は、次のとおりです。

- Oracle Databaseの組込みパスワード保護の概要

- パスワードの最低要件

- パスワード管理ポリシーの使用

- パスワードのセキュリティへの脅威からのSHA-1ハッシュ・アルゴリズムによる保護

- パスワード資格証明用の安全性の高い外部パスワード・ストアの管理

パスワードの保護に関するガイドラインは、「パスワードの保護に関するガイドライン」も参照してください。パスワードを暗号化してユーザーを認証するようにOracle XML DBを構成するとき、他のデータは暗号化する必要がない場合(例: イントラネットの電子メール)の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

Oracle Databaseの組込みパスワード保護の概要

Oracle Databaseでは、ユーザーのパスワードを保護するように設計された一連の組込みパスワード保護が提供されています。提供されるパスワード保護は、次のとおりです。

- パスワード暗号化。Oracle Databaseでは、Advanced Encryption Standard(AES)を使用して、ネットワーク(クライアントとサーバー間、双方のサーバー間)接続中にパスワードを自動的かつ透過的に暗号化し、その後ネットワーク経由で送信します。

- パスワードの複雑度のチェック。デフォルト・インストールでは、新しいパスワードまたは変更されたパスワードがパスワードを推測してシステムに入ろうとする侵入者を防げるだけ十分に複雑であることを保証するために、Oracle Databaseにverify_function_11gパスワード検証関数が用意されています。パスワードの複雑性チェックを手動で有効にする必要があります。さらに、ユーザーのパスワードの複雑度はカスタマイズできます。詳細は、「パスワードの複雑度検証の規定」を参照してください。

- パスワード突破の防止。ユーザーが誤ったパスワードを使用してOracle Databaseへのログインを複数回試行した場合、Oracle Databaseによってログインが遅延されます。この保護は、異なるIPアドレスまたは複数のクライアント接続からのログインに適用されます。4回目以降は、ユーザーが別のパスワードを使用してログインを試行するまで、次第に遅延時間が長くなり、最大10秒まで遅延します。ユーザーが正しいパスワードを入力すると、遅延なしで正常にログインできます。
この機能により、侵入者がログインを試みるときに一定時間内に試すことができるパスワードの数が大幅に減少します。ログイン失敗による遅延によって、各ログイン試行の失敗にかかる時間が延び、(通常、こうした攻撃では非常に多くの試行に失敗せざるを得ないため)パスワード推測攻撃全体にかかる時間が増加します。

- パスワードでの大/小文字の区別の規定。パスワードは大/小文字が区別されます。たとえば、パスワードがhPP5620qrの場合、hpp5620QRまたはhPp5620Qrと入力すると失敗します。以前のリリースでは、パスワードは大/小文字が区別されませんでした。パスワードでの大/小文字の区別、およびパスワード・ファイルやデータベース・リンクへの影響については、「パスワードでの大/小文字の区別の有効化または無効化」を参照してください。

- セキュア・ハッシュ・アルゴリズム(SHA)の暗号ハッシュ関数SHA-1を使用したパスワードのハッシュ化。Oracle Databaseは、SHA-1を使用してユーザーのパスワードを認証し、ユーザーのセッションを確立します。また、大文字と小文字を区別し、パスワードを160ビットに制限します。SHA-1を使用する利点として、SHA-1はOracle Databaseユーザーによく使用されており、ネットワークをアップグレードすることなくセキュリティを強化できる点があげられます。また、強力なパスワード・ハッシュ・アルゴリズムにより保護されている強力なパスワードを使用するというコンプライアンス要件を満たします。詳細は、「パスワードのセキュリティへの脅威からのSHA-1ハッシュ・アルゴリズムによる保護」を参照してください。

パスワードの最低要件

パスワードは30文字、つまり30バイト以内にする必要があります。ただし、より高いセキュリティを確保するには、「パスワードの保護に関するガイドライン」で説明する追加ガイドラインに従ってください。

ユーザーのパスワードを作成するには、CREATE USERまたはALTER USER SQL文を使用します。IDENTIFIED BY句を受け入れるSQL文でもパスワードを作成できます。例3-1に、IDENTIFIED BY句でパスワードを作成するSQL文をいくつか示しています。

例3-1 パスワード作成のSQL文

CREATE USER psmith IDENTIFIED BY password;
GRANT CREATE SESSION TO psmith IDENTIFIED BY password;
ALTER USER psmith IDENTIFIED BY password;
CREATE DATABASE LINK AUTHENTICATED BY psmith IDENTIFIED BY password;

関連項目:

- パスワードがサイトに対して十分な複雑度を備えていることを確認する方法は、「パスワードの複雑度検証の規定」を参照してください。

- パスワードを保護する別の方法については、「パスワードの保護に関するガイドライン」を参照してください。

- アプリケーション開発者が順守する必要があるパスワード保護ガイドラインについては、「アプリケーション設計におけるパスワードの保護」を参照してください。

- CREATE USER、ALTER USER、GRANTおよびCREATE DATABASE LINK SQL文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

パスワード管理ポリシーの使用

この項の内容は、次のとおりです。

- パスワード管理の概要

- デフォルト・パスワードが設定されているユーザー・アカウントの検索

- デフォルト・プロファイルのパスワード設定の構成

- デフォルトのパスワード・セキュリティ設定の有効化および無効化

- ログイン失敗後のユーザー・アカウントの自動ロック

- パスワード・エイジングおよび期限切れの制御

- パスワード変更のライフ・サイクル

- PASSWORD_LIFE_TIMEプロファイル・パラメータを低い値に設定

- ユーザーによる以前のパスワードの再利用の制御

- パスワードの複雑度検証の規定

- パスワードでの大/小文字の区別の有効化または無効化

関連項目:

- 「プロファイルによるリソースの管理」

- この項で説明するSQL文の構文および各文に固有の情報は、『Oracle Database SQL言語リファレンス』を参照してください。

パスワード管理の概要

パスワードに依存しているデータベース・セキュリティ・システムでは、パスワードの機密を常に保つ必要があります。パスワードは盗難や悪用などの被害を受けやすいため、Oracle Databaseではパスワード管理ポリシーが使用されています。データベース管理者およびセキュリティ管理者がユーザー・プロファイルを介してパスワード管理ポリシーを制御することで、データベース・セキュリティの管理を強化できます。

ユーザー・プロファイルを作成するには、CREATE PROFILE文を使用します。プロファイルは、CREATE USERまたはALTER USER文を使用してユーザーに割り当てます。ここでは、データベース・ユーザーの作成と変更の詳細は説明しません。この項では、CREATE PROFILE(またはALTER PROFILE)文で指定できるパスワード・パラメータについて説明します。

デフォルト・パスワードが設定されているユーザー・アカウントの検索

Oracle Database 11g リリース2(11.2)でデータベースを作成すると、デフォルト・アカウントの大部分は期限切れのパスワードでロックされます。以前のリリースのOracle Databaseからアップグレードした場合は、デフォルト・パスワードが設定されているユーザー・アカウントが存在していることがあります。それらは、データベースの作成時に作成されたデフォルト・アカウント(HR、OE、SCOTTアカウントなど)です。

セキュリティを強化するために、それらのアカウントのパスワードを変更してください。周知されているデフォルト・パスワードを使用すると、データベースが侵入者から攻撃を受けやすくなります。デフォルト・パスワードを使用するアカウント(ロック済とロック解除済の両方)を検索するには、SYSDBA権限を使用してSQL*Plusにログインし、DBA_USERS_WITH_DEFPWDデータ・ディクショナリ・ビューを問い合せます。

次に、デフォルトのパスワードが設定されているアカウントの名前とステータスの両方を検索する例を示します。

SELECT d.username, u.account_status
FROM DBA_USERS_WITH_DEFPWD d, DBA_USERS u
WHERE d.username = u.username
ORDER BY 2,1;

USERNAME  ACCOUNT_STATUS
--------- ---------------------------
SCOTT     EXPIRED & LOCKED

次に、DBA_USERS_WITH_DEFPWDビューにリストされたアカウントのパスワードを変更します。これらのアカウントに、旧リリースのOracle Databaseで指定されていた可能性のあるパスワードを割り当てないことをお薦めします。

ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。パスワードの最低要件については、「パスワードの最低要件」を参照してください。

デフォルト・プロファイルのパスワード設定の構成

プロファイルとは、データベース・リソースに関する制限を設定するパラメータの集合です。プロファイルをユーザーに割り当てた場合、そのユーザーはそれらの制限を超えることはできません。プロファイルを使用すると、ユーザーごとのセッション数、ロギングやトレースの機能など、データベース設定を構成できます。また、プロファイルによってユーザー・パスワードも制御できます。プロファイル内の現行のパスワード設定に関する情報は、DBA_PROFILESデータ・ディクショナリ・ビューを問い合せることで確認できます。

表3-1に、デフォルト・プロファイルのパスワード固有のパラメータ設定を示します。

表3-1 デフォルト・プロファイルのパスワード固有の設定

パラメータ

デフォルト設定

説明

FAILED_LOGIN_ATTEMPTS

10

ユーザーがログインを試行して失敗する最大回数。この回数を超えるとアカウントがロックされます。

注意:

- このパラメータを設定する場合、CONNECT THROUGH権限を使用してログインするユーザーを考慮します。

- 未認可ユーザー(侵入者の可能性があります)がOracle Call Interface(OCI)アプリケーションにログインを試行する回数の制限を設定するには、SEC_MAX_FAILED_LOGIN_ATTEMPTS初期化パラメータを使用できます。このパラメータの詳細は、「認証の最大試行回数の構成」を参照してください。
詳細は、「ログイン失敗後のユーザー・アカウントの自動ロック」も参照してください。

PASSWORD_GRACE_TIME

7

パスワードが期限切れになる前に、ユーザーがパスワードを変更するための日数を設定します。

詳細は、「パスワード・エイジングおよび期限切れの制御」を参照してください。

PASSWORD_LIFE_TIME

180

ユーザーが現行のパスワードを使用できる日数を設定します。

詳細は、「パスワード・エイジングおよび期限切れの制御」を参照してください。

PASSWORD_LOCK_TIME

1

ログインを指定の回数だけ連続して失敗した後に、アカウントがロックされる日数を設定します。この期間が経過すると、アカウントのロックは解除されます。このユーザー・プロファイル・パラメータは、管理者のメンテナンス負荷を高めることなく、ユーザー・パスワードに対する総当り攻撃を容易に防止するのに役立ちます。

詳細は、「ログイン失敗後のユーザー・アカウントの自動ロック」を参照してください。

PASSWORD_REUSE_MAX

UNLIMITED

現行のパスワードを再利用できるようになるまでに必要なパスワード変更の回数を設定します。

詳細は、「ユーザーによる以前のパスワードの再利用の制御」を参照してください。

PASSWORD_REUSE_TIME

UNLIMITED

パスワードを再利用できない日数を設定します。

詳細は、「ユーザーによる以前のパスワードの再利用の制御」を参照してください。

セキュリティを強化するために、必要に応じて、表3-1に示すデフォルト設定を使用してください。CREATE PROFILE文またはALTER PROFILE文を使用して、パスワード固有のパラメータを個別に作成または変更できます。例:

ALTER PROFILE prof LIMIT
FAILED_LOGIN_ATTEMPTS 9
PASSWORD_LOCK_TIME 10;

CREATE PROFILE、ALTER PROFILE、およびこの項で説明したパスワード関連のパラメータの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

デフォルトのパスワード・セキュリティ設定の有効化および無効化

アプリケーションでOracle Database 10g リリース2(10.2)のデフォルトのパスワード・セキュリティ設定を使用している場合、リリース11gのパスワード・セキュリティ設定を使用するようにアプリケーションを変更するまでは、設定の復元が可能です。このことを行うには、undopwd.sqlスクリプトを実行します。

リリース11gのパスワード・セキュリティ設定に準拠するようにアプリケーションを変更した後は、実際のビジネス・ニーズに合ったパスワード・セキュリティ構成を使用するためにデータベースを手動で更新したり、secconf.sqlスクリプトを実行して、リリース11gのデフォルトのパスワード設定を適用できます。必要に応じて、異なるセキュリティ設定を使用するようにこのスクリプトをカスタマイズできますが、元のスクリプトにリストされている設定は、Oracle推奨の設定であることに注意してください。

データベースを手動で作成した場合は、secconf.sqlスクリプトを実行して、リリース11gのデフォルトのパスワード設定をデータベースに適用する必要があります。Database Configuration Assistant(DBCA)を使用して作成されたデータベースではこの設定が使用されますが、手動で作成したデータベースでは使用されません。

undopwd.sqlおよびsecconf.sqlスクリプトは、$ORACLE_HOME/rdbms/adminディレクトリにあります。undopwd.sqlスクリプトはパスワード設定にのみ影響を与え、secconf.sqlスクリプトはパスワード設定と監査設定の両方に影響を与えます。いずれも他のセキュリティ設定には影響を与えません。

ログイン失敗後のユーザー・アカウントの自動ロック

Oracle Databaseでは、ログイン試行に指定の回数だけ連続して失敗した後、ユーザーのアカウントをロックできます。PASSWORD_LOCK_TIMEユーザー・プロファイル・パラメータを設定することによって、指定した時間間隔が経過した後で自動的にロックを解除するか、またはロックを解除するにはデータベース管理者の介入を必要とするように、このアカウントを構成できます。また、データベース管理者は、データベース管理者が明示的に解除する必要があるように、手動でアカウントをロックすることもできます。

ログインの失敗が許容される回数は、CREATE PROFILE文を使用して指定します。また、アカウントがロックされる時間の長さも指定できます。

例3-2では、ユーザーjohndoeに対して許容されているログイン失敗の最大回数は10回(デフォルト)、アカウントがロックされる時間の長さは30日です。アカウントのロックは、30日が経過すると自動的に解除されます。

例3-2 CREATE PROFILE文を使用したアカウントのロック

CREATE PROFILE prof LIMIT
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LOCK_TIME 30;
ALTER USER johndoe PROFILE prof;

ユーザーがログインに失敗するたびに、Oracle Databaseでは次第に遅延時間が長くなります。

アカウントのロック解除の間隔を指定しない場合、PASSWORD_LOCK_TIMEはデフォルト・プロファイルに指定されている値を想定します。(推奨値は1日です。)PASSWORD_LOCK_TIMEをUNLIMITEDとして指定すると、ALTER USER文を使用してアカウントを明示的にロック解除する必要があります。たとえば、PASSWORD_LOCK_TIME UNLIMITEDがjohndoeに指定されていると想定して、次の文を使用してjohndoeアカウントをロック解除します。

ALTER USER johndoe ACCOUNT UNLOCK;

ユーザーが正常にアカウントにログインすると、Oracle Databaseでは、そのユーザーが失敗したログインの回数が0(ゼロ)にリセットされます(0でない場合)。

セキュリティ管理者はユーザー・アカウントを明示的にロックすることもできます。ロックされると、このアカウントは自動的にはロック解除できず、セキュリティ管理者のみがアカウントをロック解除する必要があります。CREATE USER文またはALTER USER文は、ユーザー・アカウントを明示的にロックまたはロック解除します。たとえば、次の文はユーザー・アカウントsusanをロックします。

ALTER USER susan ACCOUNT LOCK;

ユーザーによる以前のパスワードの再利用の制御

指定した期間、または指定したパスワード変更回数を経過するまで、ユーザーが以前のパスワードを再利用しないようにできます。これを行うには、CREATE PROFILE文またはALTER PROFILE文を使用してパスワードの再利用のルールを構成します。これらの文の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表3-2に、ユーザーによる前のパスワードの再利用を制御するCREATE PROFILEとALTER PROFILEのパラメータを示します。

表3-2 前のパスワードの再利用を制御するパラメータ

パラメータ名

説明および使用方法

PASSWORD_REUSE_TIME

次のいずれかを指定する必要があります。

- 以前に使用していた同じパスワードを次に使用できるようになるまでの日数(または1日の一部分)を示す数字

- UNLIMITEDの文字

PASSWORD_REUSE_MAX

次のいずれかを指定する必要があります。

- パスワードを再利用できるようになるまでに必要なパスワード変更の回数を示す整数

- UNLIMITEDの文字

パラメータを指定しない場合は、ユーザーがいつでもパスワードを再利用できる状況になります。これはセキュリティの方法としては適切ではありません。

どちらもUNLIMITEDではない場合、両方の条件に一致した場合にのみ再利用できます。つまり、そのパスワードを最後に使用してから、指定された回数のパスワード変更を行っていること、および指定された日数が経過している必要があります。

たとえば、ユーザーAのプロファイルでPASSWORD_REUSE_MAXが10、PASSWORD_REUSE_TIMEが30に指定されている場合を考えます。ユーザーAのパスワードは、そのパスワードを最後に使用してから30日が経過し、パスワードを10回再設定するまでは再利用できません。

一方のパラメータがUNLIMITEDに指定されている場合、ユーザーはパスワードを再利用できません。

両方のパラメータをUNLIMITEDに設定している場合は、両方が無視され、ユーザーはいつでもパスワードを再利用できます。

注意:
いずれかのパラメータにDEFAULTを指定すると、DEFAULTのプロファイルに定義されている値が使用されます。このプロファイルでは、すべてのパラメータがUNLIMITEDに設定されています。したがって、DEFAULTのプロファイルでそのパラメータの設定を変更していない場合は、DEFAULTとして指定されているパラメータにはUNLIMITEDが使用されます。

パスワード・エイジングおよび期限切れの制御

パスワードの存続期間を指定して、この期間を過ぎるとパスワードを期限切れにできます。つまり、ユーザーは現行の正しいパスワードを使用して次回ログインする際に、パスワードの変更を求められるということです。デフォルトでは、複雑度チェックやパスワード履歴チェックは行われないため、ユーザーは以前のパスワードや脆弱なパスワードを再利用できます。PASSWORD_REUSE_TIME、PASSWORD_REUSE_MAXおよびPASSWORD_VERIFY_FUNCTIONパラメータを設定することによって、これらの要素を制御します。(詳細は、「ユーザーによる以前のパスワードの再利用の制御」および「パスワードの複雑度検証の規定」を参照してください。)

さらに、猶予期間を設定できます。この期間中は、データベース・アカウントへのログインを試行するたびに、パスワードの変更を求める警告メッセージが発行されます。ユーザーがこの期間内にパスワードを変更しないと、Oracle Databaseではアカウントを期限切れにします。

データベース管理者は、手動でパスワードを期限切れ状態に設定できます(アカウント・ステータスをEXPIREDに設定します)。この場合、ユーザーはログオンを続行する前に、プロンプトに従ってパスワードを変更する必要があります。

たとえば、SQL*Plusにおいて、ユーザーSCOTTは正しい資格証明を使用してログインを試行しますが、パスワードが期限切れだとします。続いて、ユーザーSCOTTに「ORA-28001: パスワードが期限切れです。」エラーが表示され、次のようにパスワードの変更を求められます。

Changing password for scott
New password: new_password
Retype new password: new_password
Password changed.

パスワードの存続期間を指定するには、CREATE PROFILE文またはALTER PROFILE文を使用します。パスワードのライフ・サイクルの詳細は、「パスワード変更のライフ・サイクル」を参照してください。

例3-3は、プロファイルを作成してユーザーjohndoeに割り当てる方法を示しています。PASSWORD_LIFE_TIMEパラメータによって、johndoeはパスワードの期限が切れるまで180日間同じパスワードを使用できることが指定されています。

例3-3 CREATE PROFILEを使用したパスワード・エイジングと期限切れの設定

CREATE PROFILE prof LIMIT
FAILED_LOGIN_ATTEMPTS 4
PASSWORD_LOCK_TIME 30
PASSWORD_LIFE_TIME 180;
ALTER USER johndoe PROFILE prof;

次の問合せを実行することにより、任意のアカウントのステータス(オープンか、猶予期間か、期限切れか)を確認できます。

SELECT ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'username';

パスワード変更のライフ・サイクル

図3-1は、パスワードの存続時間と猶予期間のライフサイクルを示しています。

- フェーズ1: ユーザー・アカウントが作成されたか、既存のアカウントのパスワードが変更された後、パスワードの存続期間が開始されます。

- フェーズ2: このフェーズは、パスワードの存続期間が終了した後で、正しいパスワードを使用してユーザーが再度ログインする前の期間を表しています。Oracle Databaseによってアカウント・ステータスが更新されるためには、正しい資格証明が必要です。それ以外の場合、アカウント・ステータスは変更されません。Oracle Databaseには、アカウント・ステータスを更新するためのバックグラウンド・プロセスは存在しません。アカウント・ステータスの変更はすべて、認証されたユーザーにかわって、Oracle Databaseのサーバー・プロセスによって実行されます。

- フェーズ3: 最終的にユーザーがログインすると、猶予期間が開始されます。Oracle Databaseによって、現在の時間にそのアカウントのパスワード・プロファイルのPASSWORD_GRACE_TIME設定の値を加えた値が使用されて、DBA_USERS.EXPIRY_DATE列の値が更新されます。この時点でユーザーは、近い将来にパスワードが期限切れするというORA-28002警告メッセージ(たとえば、PASSWORD_GRACE_TIMEが7日に設定されている場合は、「ORA-28002 パスワードは、7日以内に期限切れになります。」)を受け取りますが、依然としてパスワードを変更することなくログインできます。DBA_USERS.EXPIRY_DATE列には、ユーザーがパスワードを変更するよう求められる将来の時間が示されます。

- フェーズ4: 猶予期間(フェーズ3)が終了した後、ユーザーが現行の正しいパスワードを入力すると、認証が続行される前に「ORA-28001: パスワードが期限切れです。」エラーが表示されて、パスワードを変更するよう求められます。ユーザーが、Oracle Active Data Guard構成を使用しており(その場合は、プライマリ・データベースとスタンバイ・データベースが存在します)、認証がスタンバイ・データベース(読取り専用データベース)で試行された場合は、「ORA-28032: パスワードの期限が切れており、データベースは読取り専用に設定されています」エラーが表示されます。ユーザーは、プライマリ・データベースにログインして、そこでパスワードを変更する必要があります。

これら4フェーズのいずれの間も、DBA_USERSデータ・ディクショナリ・ビューに問い合せて、DBA_USERS.ACCOUNT_STATUS列でユーザーのアカウント・ステータスを検索できます。

図3-1 パスワードの存続期間と猶予期間の推移

次の例では、johndoeに割り当てられたプロファイルに、猶予期間PASSWORD_GRACE_TIME = 3(推奨値)が指定されています。johndoeは90日後に初めてデータベースにログインしようとすると(これは90日目より後の任意の日、つまり91日目や100日目でも構いません)、パスワードが3日で期限切れになるという警告メッセージを受け取ります。3日経過してもパスワードを変更しない場合は、パスワードの期限が切れます。その後、このユーザーがログインしようとするたびに、パスワードの変更を求めるプロンプトが表示されます。

CREATE PROFILE prof LIMIT
FAILED_LOGIN_ATTEMPTS 4
PASSWORD_LIFE_TIME 90
PASSWORD_GRACE_TIME 3;

ALTER USER johndoe PROFILE prof;

データベース管理者またはALTER USERシステム権限を持つユーザーは、CREATE USER文およびALTER USER文を使用して、任意のパスワードを明示的に期限切れにできます。次の文は、期限切れのパスワードを持つユーザーを作成します。この設定によって、ユーザーがデータベースにログインする前に、強制的にパスワードを変更させることができます。

CREATE USER jbrown
IDENTIFIED BY password
...
PASSWORD EXPIRE;

CREATE USER文にパスワードの期限切れを解除する句はありませんが、アカウントのパスワードを変更することによって、期限切れは解除されます。

PASSWORD_LIFE_TIMEプロファイル・パラメータを低い値に設定

CREATE PROFILEまたはALTER PROFILEの PASSWORD_LIFE_TIMEパラメータを低い値(たとえば1日)に設定する場合は、注意が必要です。プロファイルのPASSWORD_LIFE_TIME制限は、アカウントのパスワードが最後に変更された時点、またはパスワードが一度も変更されていない場合はアカウントの作成時点から測定されます。これらの日付は、SYS.USER$システム表のPTIME (パスワード変更時間)列およびCTIME (アカウント作成時間)列に記録されています。PASSWORD_LIFE_TIME制限の測定は、PASSWORD_LIFE_TIMEプロファイル・パラメータが最後に変更された時点のタイムスタンプから開始されるのではありません(最初はそう考えがちです)。そのため、変更されたプロファイルによって影響を受けるアカウントで、パスワードの最終変更時間がPASSWORD_LIFE_TIME日前より以前のアカウントは、ただちに期限切れとなり、次回の接続時点で猶予期間に入り、「ORA-28002: パスワードは、n日以内に期限切れになります。」警告が発行されます。

データベース管理者は、次の方法で、アカウントのパスワードの最終変更時間を調べることができます。

ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS';
SELECT PTIME FROM SYS.USER$ WHERE NAME = 'user_name'; -- Password change time

アカウントの作成時間とパスワードの有効期限を調べるには、次の問合せを発行します。

SELECT CREATED, EXPIRY_DATE FROM DBA_USERS WHERE USERNAME = 'user_name';

管理者がPASSWORD_LIFE_TIMEパラメータを設定した時点で、このプロファイルを割り当てられているユーザーがログイン中であり、そのままログインし続ける場合、現在記載されている有効期限を過ぎても、このユーザーのアカウント・ステータスは、OPENからEXPIRED(GRACE)に変更されません。時間測定が開始されるのは、ユーザーがデータベースにログインした時点のみです。

パスワードのプロファイルを変更する際にデータベース管理者が注意すべきなのは、このプロファイルの対象となるユーザーの一部が、管理者がパスワードのプロファイルを更新している時点でOracle Databaseにログイン中であれば、これらのユーザーは、パスワードの有効期限を越えてシステムにログインし続けることが可能だということです。現在ログインしているユーザーを見つけるには、V$SESSIONビューのUSERNAME列を問い合せます。

これは、ユーザーのパスワードの有効期限が、パスワード最終変更時点のタイムスタンプに、管理者の設定したPASSWORD_LIFE_TIMEパスワード・プロファイル・パラメータの値を加えたものに基づいているためです。パスワード・プロファイル自体の最終変更時点のタイムスタンプに基づいているのではありません。

次のことに注意してください。

- PASSWORD_LIFE_TIMEを低い値に設定しているときにユーザーがログインしていない場合、ユーザーのアカウント・ステータスはユーザーがログインするまで変わりません。

- PASSWORD_LIFE_TIMEパラメータをUNLIMITEDに設定できますが、この設定が作用するのは猶予期間に入っていないアカウントのみです。猶予期間に入っているユーザーは、その期間を過ぎるとパスワードを変更する必要があります。

パスワードの複雑度検証の規定

複雑度検証では、各パスワードが、パスワードを推定してシステムに入ろうとする侵入者に対して十分に保護できる複雑なものであることがチェックされます。このため、ユーザーはデータベース・ユーザー・アカウント用に強固で安全性の高いパスワードを作成するように要求されます。ユーザーのパスワードは、パスワードを推定してシステムに入ろうとする侵入者に対して、十分保護可能な複雑なものである必要があります。

Oracle Databaseによるパスワードの複雑度のチェック方法

Oracle Databaseは、PL/SQLスクリプトutlpwdmg.sql($ORACLE_HOME/rdbms/adminにあります)の中にverify_function_11Gというサンプルのパスワード検証関数が用意されており、この関数を有効にすると、ユーザーがパスワードを適正に作成または変更しているかがチェックされます。utlpwdmg.sqlスクリプトには2つのパスワード検証関数があります。1つは以前のリリースのOracle Database用で、もう1つはOracle Databaseリリース11g用の更新バージョンです。

パスワードのセキュリティを強化するために、verify_function_11G関数をデフォルト・プロファイルに関連付けることをお薦めします。「パスワードの複雑度検証のカスタマイズ」に、これを実行する方法の例が示されています。

utlpwdmg.sqlスクリプトでは、ユーザーがパスワードを作成または変更したときに、次の要件をチェックします。

- パスワードの長さが8文字以上30文字以内であること。

- パスワードがユーザー名と同一でないこと。ユーザー名のスペルを逆にしたり、ユーザー名に数字1から100を追加したパスワードでないこと。

- サーバー名と同一であったり、サーバー名に数字1から100を追加したパスワードでないこと。

- 単純なパスワードでないこと(例: welcome1、database1、account1、user1234、password1、oracle、oracle123、computer1、abcdefg1、change_on_install)。

- oracleやoracleに数字1から100を追加したパスワードでないこと。

- パスワードに少なくとも数字が1つと英字が1つ含まれていること。

- 以前のパスワードとの違いが3文字以上あること。

パスワード複雑度ファンクションを使用できるユーザー

パスワード複雑度検証ファンクションをCREATE PROFILE文またはALTER PROFILE文で使用する前に、そのファンクションに対するEXECUTE権限が付与される必要があります。パスワード検証ファンクションは、SYSスキーマにあります。

パスワードの複雑度検証のカスタマイズ

独自のパスワード複雑度検証関数を作成するには、utlpwdmg.sqlスクリプトのverify_function_11G関数をバックアップしてカスタマイズします。サイトのパスワードの保護を強化するために、独自のパスワード複雑度検証関数を作成することをお薦めします。パスワードの作成に関するガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1も参照してください。ただし、パスワードの複雑度のチェックはSYSユーザーに対して適用されないことに注意してください。

デフォルトでは、パスワードの複雑度検証は使用可能ではありません。パスワードの複雑度検証を使用可能にする手順は、次のとおりです。

1. 管理者権限を使用してSQL*Plusにログインします。
例:

CONNECT SYS AS SYSDBA
Enter password: password

2. utlpwdmg.sqlスクリプト(またはこのスクリプトの変更されたバージョン)を実行して、SYSスキーマのパスワード複雑度関数を作成します。

@$ORACLE_HOME/RDBMS/ADMIN/utlpwdmg.sql

3. このファンクションを使用する必要があるユーザーに、ファンクションに対するEXECUTE権限を付与します。
例:

GRANT pmsith EXECUTE ON verify_function_11G;

4. デフォルト・プロファイルまたはユーザー・プロファイルで、PASSWORD_VERIFY_FUNCTION設定を、utlpwdmg.sqlスクリプトのサンプルのパスワード複雑度関数か、カスタマイズした関数に設定します。次のいずれかの方法を使用します。

- 管理者権限でSQL*Plusにログインし、CREATE PROFILE文またはALTER PROFILE文を使用して関数を使用可能にします。たとえば、デフォルト・プロファイルを更新してverify_function_11G関数を使用するには、次のようにします。

ALTER PROFILE default LIMIT
PASSWORD_VERIFY_FUNCTION verify_function_11G;

- Oracle Enterprise Managerで、「プロファイルの編集」ページに移動し、「複雑なパスワード検証」の下にある「複雑なパスワード検証のための関数」リストからパスワード複雑度関数の名前を選択します。

パスワード複雑度検証は、使用可能にするとすぐに有効になります。

注意:
ALTER USER文でREPLACE句を使用できます。ユーザーは、この句を使用して、自身を認証するために以前のパスワードを指定し、期限が切れていない自分のパスワードを変更できます。
パスワードが期限切れになると、ユーザーはSQLにログインしてALTER USERコマンドを発行できません。かわりにOCIPasswordChange()関数を使用しますが、この場合は以前のパスワードも必要になります。

ALTER ANY USER権限が付与されているデータベース管理者は、古いパスワードを指定せずにユーザーのパスワードを変更(新しいパスワードを適用)できます。

パスワードでの大/小文字の区別の有効化または無効化

この項の内容は、次のとおりです。

- パスワードでの大/小文字の区別の有効化または無効化について

- パスワードでの大/小文字の区別を有効化するプロシージャ

- ユーザー・アカウントのパスワード・バージョンを見つける

- 大/小文字の区別がパスワード・ファイルに与える影響

- データベース・リンク接続用に作成されたアカウントに対する大/小文字の区別の影響

パスワードでの大/小文字の区別の有効化または無効化について

ユーザー・アカウントを作成または変更するとき、パスワードはデフォルトで大/小文字の区別があります。パスワードでの大/小文字の区別の使用を制御するには、SEC_CASE_SENSITIVE_LOGON初期化パラメータを設定します。SEC_CASE_SENSITIVE_LOGONパラメータを設定できるのは、ALTER SYSTEM権限を持つユーザーのみです。このパラメータをTRUEに設定すると大/小文字の区別が有効になり、FALSEに設定すると大/小文字の区別が無効になります。

セキュリティを強化するために、パスワードで大/小文字の区別を有効にすることをお薦めします。ただし、アプリケーションで互換性の問題がある場合は、このパラメータを使用して、パスワードで大/小文字の区別を無効にできます。アプリケーションでの互換性の問題の例として、アプリケーションのパスワードが大/小文字の区別なしでハードコードされている場合、または、データベース・セッションを起動するために資格証明を送信するときに複数のアプリケーション・モジュール間で大/小文字の区別が一貫していない場合があります。

排他モードが有効なとき( SQLNET.ALLOWED_LOGON_VERSIONパラメータが11に設定されているとき)は、排他モードで使用されているセキュリティ度の強い検証では大文字/小文字を区別するパスワード・チェックのみがサポートされるため、SEC_CASE_SENSITIVE_LOGONパラメータをFALSEに設定しないでください。互換性上の理由により、Oracle DatabaseではSQLNET.ALLOWED_LOGON_VERSIONパラメータが11に設定されているときにSEC_CASE_SENSITIVE_LOGONでFALSEの設定の使用が禁止されてはいません。この結果、これらの設定が有効な場合に、ユーザーが自分のパスワードを変更したり新しいユーザー・アカウントが作成されると、アカウントがアクセス不可能になる場合があります。

パスワードでの大/小文字の区別を有効化するプロシージャ

パスワードで大/小文字を区別できるようにする手順は、次のとおりです。

1. パスワード・ファイルを使用している場合は、IGNORECASEパラメータをNに設定して作成したことを確認します。
IGNORECASEパラメータによりSEC_CASE_SENSITIVE_LOGONパラメータが上書きされます。デフォルトでは、IGNORECASEはパスワードの大/小文字が区別されないことを意味するYに設定されます。パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

2. 次のALTER SYSTEM文を入力します。

ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = TRUE

ユーザー・アカウントのパスワード・バージョンを見つける

Oracle Databaseの以前のリリースでは、パスワードで大文字と小文字は区別されませんでした。Release 10gなどの以前のリリースから現行のデータベース・リリースにユーザー・アカウントをインポートすると、ユーザーがパスワードを変更するまで、大文字と小文字が区別されないパスワードは大文字と小文字が区別されないまま使用されます。アカウントにSYSDBAまたはSYSOPER権限が付与されると、パスワード・ファイルにインポートされます。(詳細は、「大/小文字の区別がパスワード・ファイルに与える影響」を参照してください。)以前のリリースのユーザー・アカウントのパスワードは変更されると、大/小文字が区別されるようになります。

大/小文字の区別があるパスワード、または大/小文字の区別がないパスワードが設定されているユーザーを検索するには、DBA_USERSビューを問い合せます。このビューのPASSWORD_VERSIONS列に、パスワードが作成されたリリースが示されます。例:

SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;

USERNAME                       PASSWORD_VERSIONS
------------------------------ -----------------
JONES                          10G 11G
ADAMS                          10G 11G
CLARK                          10G 11G
PRESTON                        11G
BLAKE                          10G

アカウントjones、adamsおよびclarkのパスワードは、最初にリリース10gで作成され、その後、リリース11gで再設定されています。大/小文字の区別が有効になっている場合、これらのパスワードは、prestonのパスワードと同様に大/小文字が区別されます。しかし、blakeのアカウントはリリース10g基準のままであるため、大/小文字は区別されません。この場合は、セキュリティ強化のために、大/小文字が区別されるようにパスワードの再設定を要請します。

DBA_USERSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

大/小文字の区別がパスワード・ファイルに与える影響

パスワード・ファイルの大/小文字の区別を有効または無効にするには、ORAPWDコマンドライン・ユーティリティでignorecase引数を使用します。ignorecaseのデフォルト値はn(no)で、大/小文字の区別が適用されます。

例3-4に、パスワード・ファイルで大/小文字の区別を有効にする方法を示します。

例3-4 パスワードでの大/小文字の区別の有効化

orapwd file=orapw entries=100 ignorecase=n
Enter password for SYS: password

これによってorapwdというパスワード・ファイルが作成されます。ignorecaseがn(いいえ)に設定されているため、passwordパラメータに入力されるパスワードは大/小文字が区別されます。その後、このパスワードを使用して接続する場合、パスワードの作成時と大/小文字を同じにして入力すれば成功します。同じパスワードでありながら大/小文字の区別が異なるパスワードを入力すると、失敗します。

ignorecaseをyに設定した場合、パスワード・ファイル内のパスワードは大/小文字が区別されません。これは、大/小文字を自由に使用してパスワードを入力できることを意味します。

以前のリリースからユーザー・アカウントをインポートし、そのアカウントがSYSDBAまたはSYSOPER権限を使用して作成されている場合、アカウントはパスワード・ファイルに格納されます。この時点で、アカウントのパスワードは大/小文字が区別されません。大/小文字の区別が有効な場合、次にユーザーがパスワードを変更すると、パスワードは大/小文字が区別されます。セキュリティを強化するために、そのユーザーに対してパスワードを変更するように要請してください。

パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

データベース・リンク接続用に作成されたアカウントに対する大/小文字の区別の影響

データベース・リンク接続を作成する場合は、接続用のユーザー名とパスワードを定義する必要があります。データベース・リンク接続を作成すると、パスワードは大/小文字が区別されます。ユーザーが接続用のパスワードをどのように入力するかは、データベース・リンクが作成されたリリースによって決まります。

- ユーザーはリリース11gより前のデータベースからリリース11gデータベースに接続できます。リリース11gデータベースで大文字/小文字の区別が無効な場合、ユーザーはどちらの文字を使用してもパスワードを入力できます。しかし大文字/小文字の区別が有効な場合、ユーザーはリリース11gデータベースでパスワードが作成されたときの大文字/小文字を使用してパスワードを入力する必要があります。

- ユーザーがリリース11gのデータベースからリリース11gより前のデータベースに接続する場合、パスワードは大/小文字が区別されないため、大/小文字に関係なくパスワードを入力できます。

既存のデータベース・リンクのユーザー・アカウントを検索するには、V$DBLINKビューを実行します。次に例を示します。

SELECT DB_LINK, OWNER_ID FROM V$DBLINK;

V$DBLINKビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

パスワードのセキュリティへの脅威からのSHA-1ハッシュ・アルゴリズムによる保護

SHA-1暗号化ハッシュ・アルゴリズムは、パスワードでの大/小文字、特殊文字およびマルチバイト・キャラクタの混在をサポートすることで、パスワード・ベースのセキュリティに対する脅威からデータを保護します。さらに、SHA-1ハッシュ・アルゴリズムにより、ハッシュ時にパスワードにsaltが追加され、さらなる保護が提供されます。これにより、ユーザーはさらに複雑なパスワードを作成できるため、侵入者がこれらのパスワードにアクセスするのがさらに困難になります。SHA-1ハッシュ・アルゴリズムを使用することをお薦めします。

パスワード・バージョン(パスワード・ハッシュ値とも呼ばれる)は、サーバーとログインしているユーザー間の「共有秘密」として使用されるため、非常に機密性が高いとみなされます。侵入者にこの秘密を知られると、認証の保護はただちに重大な危険にさらされます。アカウント管理権限を持つ管理ユーザー、SYSDBAシステム権限を持つ管理ユーザーまたはEXP_FULL_DATABASEロールを持つユーザーはすぐにパスワードのハッシュ値にアクセスできることに注意してください。したがって、データベースのパスワードベースの認証の整合性を保持するには、このタイプの管理ユーザーは信頼できるユーザーである必要があります。これらの管理者が信頼できない場合、パスワード・バージョンが「エンタープライズ・ユーザー・セキュリティ」ディレクトリ内に保持され、エンタープライズ・ユーザー・セキュリティ管理者以外はアクセスできないように、ディレクトリ・サーバー(Oracle Databaseエンタープライズ・ユーザー・セキュリティなど)をデプロイすることをお薦めします。

オプションで、Oracle Databaseがリリース11以降の排他モードで実行されるように構成できます。排他モードを有効にすると、Oracle DatabaseはSHA-1ハッシュ・アルゴリズムを排他的に使用します。Oracle Database 11gの排他モードは、OCIベースのドライバを使用するOracle Database 10g以降の製品(SQL*Plus、ODBC、Oracle .NET、Oracle Forms、そして様々なサード・パーティ製Oracle Databaseアダプタなど)と互換性があります。ただし、リリース11gの排他モードは、Oracle Database 11gより前のJDBCタイプ-4 (シン)バージョン、またはOracle Database 10gより前のOracle Database Client interface (OCI)ベースのドライバとは互換性がありません。排他モードを構成した後は、前のパスワード・ハッシュ値をデータ・ディクショナリから削除することをお薦めします。

手順は、次のとおりです。

1. 排他モードを使用可能にします。

1. sqlnet.oraパラメータ・ファイルのバックアップ・コピーを作成します。このファイルのデフォルトの場所は、UNIXオペレーティング・システムでは$ORACLE_HOME/network/adminディレクトリ、Microsoft Windowsオペレーティング・システムでは%ORACLE_HOME%\network\adminディレクトリです。

2. sqlnet.oraファイルに次の行が含まれていることを確認します。

SQLNET.ALLOWED_LOGON_VERSION=12

October 2012 CPUを適用している場合またはOracle Databaseリリース11.2.0.3を使用している場合は、SQLNET.ALLOWED_LOGON_VERSIONが11ではなく、12に設定されていることを確認します。

3. sqlnet.oraファイルを保存して終了します。

2. テスト・スクリプトまたはバッチ・ジョブ内のパスワードに、大/小文字と特殊文字が一貫して混在していることを確認します。

3. パスワードすべてを、大/小文字と特殊文字が混在するように変更します。
12文字以上のランダムなパスワードを使用することをお薦めします。複雑であっても覚えやすいパスワードの作成技法と、パスワード作成に関する追加ガイドラインについては、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。

関連項目:
セキュリティ・パッチのダウンロードと脆弱性に関する問合せ

パスワード資格証明用の安全性の高い外部パスワード・ストアの管理

この項の内容は、次のとおりです。

- 安全性の高い外部パスワード・ストアの概要

- 外部パスワード・ストアの機能

- クライアントを外部パスワード・ストアを使用するように構成

- 外部パスワード・ストア資格証明の管理

安全性の高い外部パスワード・ストアの概要

データベースに接続するためのパスワード資格証明は、クライアント側のOracleウォレットを使用して格納できます。Oracleウォレットは、認証および署名用資格証明を格納する安全性の高いソフトウェア・コンテナです。

このウォレットの使用方法により、データベースに接続する際にパスワード資格証明に依存する大規模な配置を簡素化できます。この機能が構成されている場合、アプリケーション・コード、バッチ・ジョブおよびスクリプトにユーザー名およびパスワードを埋め込む必要がありません。これによりパスワードが危険にさらされることがなくなるため、リスクが軽減します。また、ユーザー名またはパスワードが変更されるたびにアプリケーション・コードを変更する必要がなくなるため、パスワード管理ポリシーの適用が容易になります。

関連項目:

- 「安全性の高い外部パスワード・ストアとプロキシ認証の使用」

- Oracleウォレットの概要は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

注意:
ウォレットの外部パスワード・ストアは、公開鍵インフラストラクチャ(PKI)資格証明が格納されている領域とは別の場所にあります。そのため、ウォレットの外部パスワード・ストアの資格証明管理には、Oracle Wallet Managerを使用できません。かわりに、コマンドライン・ユーティリティmkstoreを使用して資格証明を管理します。

外部パスワード・ストアの機能

通常、ユーザー(アプリケーション、バッチ・ジョブおよびスクリプトを含む)は、データベースへの接続には、データベース接続文字列を指定する標準のCONNECT文を使用します。この文字列には、ユーザー名、パスワード、およびOracle Databaseネットワーク上のデータベースを識別するOracle Netサービス名が含まれています。パスワードを省略すると、ユーザーは接続時にパスワードが要求されます。

たとえば、このサービス名は、データベースを識別するURL、またはデータベースのtnsnames.oraファイルに入力したTNS別名になります。または、host:port:sidの文字列となる場合もあります。

次の例は、外部パスワード・ストアを使用するように構成されていないクライアントにも使用できる標準CONNECT文です。

CONNECT salesapp@sales_db.us.example.com
Enter password: password

CONNECT salesapp@orasales
Enter password: password

CONNECT salesapp@ourhost37:1527:DB17
Enter password: password

これらの例では、salesappがユーザー名で、一意のデータベースの接続文字列が3つの方法で示されています。URL形式のsales_db.us.example.com、tnsnames.oraファイルでのTNS別名orasales、またはhost:port:sid形式の文字列を使用できます。

ただし、クライアントが安全性の高い外部パスワード・ストアを使用するように構成されている場合は、アプリケーションは、データベースのログイン接続情報を指定せずに、次のCONNECT文の構文を使用してデータベースに接続できます。

CONNECT /@db_connect_string

CONNECT /@db_connect_string AS SYSDBA

CONNECT /@db_connect_string AS SYSOPER

ここでdb_connect_stringは、前述の例にあったように、サービス名、URL、別名など、対象のデータベースにアクセスするための有効な接続文字列です。各ユーザー・アカウントにはそれぞれ専用の一意の接続文字列が必要です。複数のユーザー用に1つの接続文字列を作成することはできません。

この場合、データベースの資格証明、ユーザー名およびパスワードが、安全性を目的に作成されたOracleウォレットに格納されています。このウォレットの自動ログイン機能が使用状態になるため、システムにはウォレットを開くためのパスワードは不要です。ウォレットから、システムはデータベースにアクセスするための資格証明を、資格を証明するユーザーのために取得します。

関連項目:
自動ログイン・ウォレットの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

クライアントを外部パスワード・ストアを使用するように構成

クライアントがすでにWindowsネイティブ認証やSecure Sockets Layer(SSL)などの外部認証を使用するように構成されている場合、Oracle Databaseではその認証方式が使用されます。通常は、そのタイプの認証で使用されるものと同じ資格証明が、データベースへのログインにも使用されます。

データベース認証として、その認証方式を使用しないかまたは変更するクライアントには、sqlnet.oraのSQLNET.WALLET_OVERRIDEパラメータをTRUEに設定できます。SQLNET.WALLET_OVERRIDEのデフォルト値はFALSEで、今までと同様に認証資格証明の標準的な使用が許可されます。

安全性の高い外部パスワード・ストア機能をクライアントで使用する場合は、次の構成タスクを実行します。

1. コマンドラインで次の構文を使用して、クライアント上にウォレットを作成します。

mkstore -wrl wallet_location -create

例:

mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -create
Enter password: password

wallet_locationは、ウォレットを作成して格納するディレクトリのパスです。このコマンドにより、指定した場所にOracleウォレットが作成され、自動ログイン機能が使用可能になります。この自動ログイン機能により、クライアントは、パスワードを指定しなくてもウォレットの内容にアクセスできます。自動ログイン・ウォレットの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

mkstoreユーティリティの-createオプションを指定すると、パスワードの複雑度検証が使用されます。詳細は、「パスワードの複雑度検証の規定」を参照してください。

2. コマンドラインで次の構文を使用して、ウォレットにデータベース接続の資格証明を作成します。

mkstore -wrl wallet_location -createCredential db_connect_string username
Enter password: password

例:

mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -createCredential orcl system
Enter password: password

次のように値を指定します。

- wallet_locationは、手順1でウォレットを作成したディレクトリのパスです。

- db_connect_stringは、tnsnames.oraファイルでデータベースを指定するために使用するTNS別名、またはOracleネットワーク上のデータベースを識別するために使用するサービス名です。デフォルトで、tnsnames.oraは$ORACLE_HOME/network/adminディレクトリ(UNIXシステムの場合)またはORACLE_HOME\network\admin(Windowsの場合)にあります。

- usernameは、データベース・ログイン資格証明です。プロンプトが表示された後に、このユーザーのパスワードを入力します。

アクセス可能にする各データベースに対し、CONNECT /@db_connect_string構文を使用してこの手順を繰り返します。

注意:
CONNECT /@db_connect_string文で使用するdb_connect_stringは、-createCredentialコマンドで指定するdb_connect_stringと同じにする必要があります。

3. クライアントのsqlnet.oraファイルに、WALLET_LOCATIONパラメータを入力し、手順1で作成したウォレットのディレクトリの場所に設定します。
たとえば、$ORACLE_HOME/network/adminにウォレットを作成し、Oracleホームが/private/ora11に設定されている場合、クライアントのsqlnet.oraファイルには次のように指定する必要があります。

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /private/ora11/network/admin)
)
)

4. クライアントのsqlnet.oraファイルにSQLNET.WALLET_OVERRIDEパラメータを入力し、それを次のようにTRUEに設定します。

SQLNET.WALLET_OVERRIDE = TRUE

この設定により、すべてのCONNECT /@db_connect_string文で、データベースへの認証に、指定された場所にあるウォレットの情報が使用されます。

外部認証が使用されている場合、そのウォレットによる認証ユーザーはCONNECT /@db_connect_string構文を使用し、前述の手順で指定したデータベースにユーザー名およびパスワードを使用せずにアクセスできます。ただし、ユーザーがこの外部認証に失敗した場合は、これらの接続文の実行も失敗します。

注意:
アプリケーションが暗号化にSSLを使用する場合、sqlnet.oraパラメータSQLNET.AUTHENTICATION_SERVICESによりSSLが指定され、SSLウォレットが作成されます。このアプリケーションが、データベースへの認証にSSL証明書ではなく秘密のストア資格証明を使用する場合、これらの資格証明をSSLウォレットに格納する必要があります。SSL認証の後、SQLNET.WALLET_OVERRIDE = TRUEに設定されている場合は、ウォレットのユーザー名およびパスワードがデータベースへの認証に使用されます。SQLNET.WALLET_OVERRIDE = FALSEの場合は、SSL証明書が使用されます。

例3-5では、手順3および手順4で説明したWALLET_LOCATIONおよびSQLNET.WALLET_OVERRIDEパラメータが指定されているサンプルsqlnet.oraファイルを示します。

例3-5 ウォレット・パラメータが設定されたサンプルSQLNET.ORAファイル

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /private/ora11/network/admin)
)
)

SQLNET.WALLET_OVERRIDE = TRUE
SSL_CLIENT_AUTHENTICATION = FALSE
SSL_VERSION = 0

外部パスワード・ストア資格証明の管理

この項では、mkstoreコマンドライン・ユーティリティを使用して、外部パスワード・ストアで資格証明を管理するために実行できる次の各タスクの概要を示します。

- 外部パスワード・ストアの内容のリスト表示

- 外部パスワード・ストアへの資格証明の追加

- 外部パスワード・ストアの資格証明の変更

- 外部パスワード・ストアからの資格証明の削除

外部パスワード・ストアの内容のリスト表示

定期的に、クライアント・ウォレットの外部パスワード・ストアのすべての内容を表示する、または特定の資格証明を表示してチェックする必要のある場合があります。外部パスワード・ストアの内容をリスト表示することによって、ストアに資格証明を追加または削除するかどうかの判断に使用できる情報が提供されます。

外部パスワード・ストアの内容をリスト表示するには、コマンドラインで次のコマンドを入力します。

mkstore -wrl wallet_location -listCredential

例:

mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -listCredential

wallet_locationでは、表示する外部パスワード・ストアの内容が格納されているウォレットのディレクトリ・パスを指定します。このコマンドにより、資格証明にあるデータベース・サービス名(別名)および対応するユーザー名(スキーマ)がすべてリスト表示されます。パスワードはリスト表示されません。

外部パスワード・ストアへの資格証明の追加

1つのクライアント・ウォレットに複数の資格証明を格納できます。たとえば、クライアントのバッチ・ジョブがhr_databaseに接続し、スクリプトがsales_databaseに接続する場合、同じクライアント・ウォレットにこのログイン資格証明を格納できます。ただし、同じウォレット内の同じデータベースに対する、(複数のスキーマにログインするための)複数の資格証明を格納することはできません。同じデータベースに対する複数のログイン資格証明がある場合、別のウォレットに格納する必要があります。

既存のクライアント・ウォレットにデータベース・ログイン資格証明を追加するには、コマンドラインで次のコマンドを指定します。

mkstore -wrl wallet_location -createCredential db_alias username

例:

mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -createCredential orcl system
Enter password: password

次のように値を指定します。

- wallet_locationは、資格証明を追加するクライアント・ウォレットが格納されるディレクトリのパスです。

- db_aliasは、tnsnames.oraファイルでデータベースを指定するために使用するTNS別名、またはOracleネットワーク上のデータベースを識別するために使用するサービス名です。

- usernameは、アプリケーションが接続するスキーマに対するデータベース・ログイン資格証明です。プロンプトが表示された後に、このユーザーのパスワードを入力します。

外部パスワード・ストアの資格証明の変更

データベース接続文字列が変更された場合、ウォレットに格納されているデータベース・ログイン資格証明も変更できます。

ウォレット内のデータベース・ログイン資格証明を変更するには、コマンドラインで次のコマンドを入力します。

mkstore -wrl wallet_location -modifyCredential dbase_alias username

例:

mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -modifyCredential sales_db
Enter password: password

次のように値を指定します。

- wallet_locationは、ウォレットが格納されているディレクトリのパスです。

- db_aliasは、データベースの識別に使用する新規または個別の別名です。これは、tnsnames.oraファイルでデータベースを指定するために使用するTNS別名、もしくはOracleネットワークのデータベースを識別するために使用する任意のサービス名になります。

- usernameは、新規または他のデータベース・ログイン資格証明です。プロンプトが表示された後に、このユーザーのパスワードを入力します。

外部パスワード・ストアからの資格証明の削除

データベースが存在しなくなった場合、または特定のデータベースへの接続を無効にする場合は、そのデータベースのすべてのログイン資格情報をウォレットから削除できます。

ウォレットのデータベース・ログイン資格証明を削除するには、コマンドラインで次のコマンドを入力します。

mkstore -wrl wallet_location -deleteCredential db_alias

例:

mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -deleteCredential orcl

次のように値を指定します。

- wallet_locationは、ウォレットが格納されているディレクトリのパスです。

- db_aliasは、tnsnames.oraファイルでデータベースを指定するために使用するTNS別名、またはOracle Databaseネットワーク上のデータベースを識別するために使用するサービス名です。

データベース管理者の認証

データベース管理者は、管理者以外のデータベース・ユーザーが実行できない特別な操作(データベースの停止や起動など)を実行します。Oracle Databaseには、SYSDBA権限またはSYSOPER権限のいずれかを持つデータベース管理者の認証を保護するために、次の方式が用意されています。

- データベース管理者の厳密認証と集中管理

- オペレーティング・システムを使用したデータベース管理者の認証

- パスワードを使用したデータベース管理者の認証

データベース管理者の厳密認証と集中管理

厳密認証を使用すると、複数のデータベースに対するSYSDBAおよびSYSOPERのアクセスを集中管理できます。データベース管理のこのような認証は、次の状況で使用を検討してください。

- パスワード・ファイルの脆弱性が懸念される場合。

- サイトで非常に強固なセキュリティが要求される場合。

- アイデンティティ管理をデータベースから分離する必要がある場合。たとえば、Oracle Internet Directory(OID)などのディレクトリ・サーバーを使用すると、そのサーバーを個別にメンテナンス、保護および管理できます。

Oracle Internet Directoryサーバーを使用してSYSDBAおよびSYSOPERの接続を認可するには、使用している環境に応じて、次のいずれかの方式を使用します。

- 管理ユーザーのディレクトリ認証の構成

- 管理ユーザーのKerberos認証の構成

- 管理ユーザーのSecure Sockets Layer認証の構成

管理ユーザーのディレクトリ認証の構成

管理ユーザーのディレクトリ認証を構成する手順は、次のとおりです。

1. 通常のユーザーを構成するのと同じ手順で、管理ユーザーを構成します。

2. Oracle Internet Directoryで、このユーザーが管理するデータベースに対して、SYSDBAまたはSYSOPER権限をユーザーに付与します。
SYSDBAまたはSYSOPERは信頼できるユーザーにのみ付与してください。この項の内容に関するガイドラインは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください。

3. LDAP_DIRECTORY_SYSAUTH初期化パラメータをYESに設定します。

ALTER SYSTEM SET LDAP_DIRECTORY_SYSAUTH = YES;

LDAP_DIRECTORY_SYSAUTHパラメータをYESに設定すると、SYSDBAおよびSYSOPERユーザーは、厳密認証方式を使用してデータベースへの認証を行うことができます。

LDAP_DIRECTORY_SYSAUTHの詳細は、『Oracle Databaseリファレンス』を参照してください。

4. LDAP_DIRECTORY_ACCESSパラメータをPASSWORDまたはSSLのいずれかに設定します。次に例を示します。

ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = PASSWORD;

LDAP_DIRECTORY_ACCESS初期化パラメータをNONEに設定しないでください。このパラメータをPASSWORDまたはSSLに設定すると、Oracle Internet DirectoryからSYSDBAまたはSYSOPER権限を使用してユーザーを認証できます。LDAP_DIRECTORY_ACCESSの詳細は、『Oracle Databaseリファレンス』を参照してください。

この結果、ユーザーは、SQL*PlusでCONNECT文にネット・サービス名を指定してログインできるようになります。たとえば、ネット・サービス名がorclの場合、SYSDBAとしてログインするには、次のように入力します。

CONNECT SOMEUSER@ORCL AS SYSDBA
Enter password: password

リモート認証でパスワード・ファイルを使用するようにデータベースが構成されている場合、Oracle Databaseでは最初にパスワード・ファイルをチェックします。

管理ユーザーのKerberos認証の構成

管理ユーザーのKerberos認証を構成する手順は、次のとおりです。

1. 通常のユーザーを構成するのと同じ手順で、管理ユーザーを構成します。
詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

2. Kerberos認証用にOracle Internet Directoryを構成します。
詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

3. Oracle Internet Directoryで、このユーザーが管理するデータベースに対して、SYSDBAまたはSYSOPER権限をユーザーに付与します。
SYSDBAまたはSYSOPERは信頼できるユーザーにのみ付与してください。この項の内容に関するガイドラインは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください。

4. LDAP_DIRECTORY_SYSAUTH初期化パラメータをYESに設定します。

ALTER SYSTEM SET LDAP_DIRECTORY_SYSAUTH = YES;

LDAP_DIRECTORY_SYSAUTHパラメータをYESに設定すると、SYSDBAおよびSYSOPERユーザーは、厳密認証方式を使用してデータベースへの認証を行うことができます。LDAP_DIRECTORY_SYSAUTHの詳細は、『Oracle Databaseリファレンス』を参照してください。

5. LDAP_DIRECTORY_ACCESSパラメータをPASSWORDまたはSSLのいずれかに設定します。次に例を示します。

ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = SSL;

LDAP_DIRECTORY_ACCESS初期化パラメータをNONEに設定しないでください。このパラメータをPASSWORDまたはSSLに設定すると、Oracle Internet DirectoryからSYSDBAまたはSYSOPERを使用してユーザーを認証できます。LDAP_DIRECTORY_ACCESSの詳細は、『Oracle Databaseリファレンス』を参照してください。

この結果、ユーザーは、SQL*PlusでCONNECT文にネット・サービス名を指定してログインできるようになります。たとえば、ネット・サービス名がorclの場合、SYSDBAとしてログインするには、次のように入力します。

CONNECT /@orcl AS SYSDBA

管理ユーザーのSecure Sockets Layer認証の構成

管理ユーザーのSecure Sockets Layer(SSL)認証を構成する手順は、次のとおりです。

1. SSLを使用するように、次の手順でクライアントを構成します。

1. クライアント・ウォレットおよびユーザー証明書を構成します。sqlnet.ora構成ファイルのウォレットの場所を更新します。
ウォレット・マネージャを使用して、クライアント・ウォレットおよびユーザー証明書を構成します。詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

2. サーバーDNを含み、SSLとともにTCP/IPを使用するように、tnsnames.oraのOracleネット・サービス名を構成します。

3. listener.oraでSSLとともにTCP/IPを構成します。

4. sqlnet.oraで、クライアントSSL暗号スイートおよび必要なSSLバージョンを設定し、SSLを認証サービスとして設定します。

2. SSLを使用するように、次の手順でサーバーを構成します。

1. TCPSのデータベース・リスナーに対してSSLを使用可能にし、対応するTNS名を指定します。TNS名はNet Configuration Assistantを使用して構成できます。

2. データベースPKI資格証明をデータベース・ウォレットに格納します。この操作は、ウォレット・マネージャを使用して実行できます。

3. LDAP_DIRECTORY_ACCESS初期化パラメータをSSLに設定します。

ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = SSL;

LDAP_DIRECTORY_ACCESSの詳細は、『Oracle Databaseリファレンス』を参照してください。

3. SSLユーザー認証用にOracle Internet Directoryを構成します。
エンタープライズ・ユーザー・セキュリティのSSL認証の構成方法は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

4. Oracle Internet Directoryで、このユーザーが管理するデータベースに対して、SYSDBAまたはSYSOPER権限をユーザーに付与します。

5. サーバー・コンピュータで、LDAP_DIRECTORY_SYSAUTH初期化パラメータをYESに設定します。

ALTER SYSTEM SET LDAP_DIRECTORY_SYSAUTH = YES;

LDAP_DIRECTORY_SYSAUTHパラメータをYESに設定すると、SYSDBAおよびSYSOPERユーザーは、厳密認証方式を使用してデータベースへの認証を行うことができます。LDAP_DIRECTORY_SYSAUTHの詳細は、『Oracle Databaseリファレンス』を参照してください。

この結果、ユーザーは、SQL*PlusでCONNECT文にネット・サービス名を指定してログインできるようになります。たとえば、ネット・サービス名がorclの場合、SYSDBAとしてログインするには、次のように入力します。

CONNECT /@orcl AS SYSDBA

オペレーティング・システムを使用したデータベース管理者の認証

通常、データベース管理者のオペレーティング・システム認証には、オペレーティング・システムにグループを作成すること、そのグループにDBA権限を付与すること、および権限を付与する管理者の名前をグループに追加することが含まれます。(UNIXシステムでは、このグループはdbaグループです。)

Microsoft Windowsシステムでは、SYSDBA権限で接続するユーザーはWindows固有の認証を利用できます。このユーザーがドメイン・アカウントを使用してOracle Databaseを操作する場合は、ローカル管理権限およびORA_DBAメンバーシップを明示的に付与する必要があります。

関連項目:
データベース管理者のオペレーティング・システム認証の構成の詳細は、オペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

パスワードを使用したデータベース管理者の認証

Oracle Databaseでは、データベース固有のパスワード・ファイルを使用して、SYSDBAおよびSYSOPER権限を付与したデータベース・ユーザー名を追跡します。これらの権限によって、次のアクティビティが使用可能になります。

- SYSOPERシステム権限によって、データベース管理者はSTARTUP、SHUTDOWN、ALTER DATABASE OPEN/MOUNT、ALTER DATABASE BACKUP、ARCHIVE LOGおよびRECOVERの各操作を実行できます。また、SYSOPER権限には、RESTRICTED SESSION権限も含まれます。

- SYSDBAシステム権限には、ADMIN OPTIONおよびSYSOPERシステム権限も含めて、すべてのシステム権限が含まれます。CREATE DATABASEと時間ベースのリカバリが許可されます。

- SYSDBAまたはSYSOPERの権限のあるユーザーを含むパスワード・ファイルを、異なるデータベース間で共有できます。SYSユーザー以外のユーザーが含まれた共有パスワード・ファイルも保持できます。異なるデータベース間でパスワード・ファイルを共有するには、init.oraファイルのREMOTE_LOGIN_PASSWORDFILEパラメータをSHAREDに設定します。
REMOTE_LOGIN_PASSWORDFILE初期化パラメータの設定をNONEからEXCLUSIVEまたはSHAREDに変更する場合は、パスワード・ファイルとディクショナリ・パスワードを必ず同期化してください。詳細は、『Oracle Database管理者ガイド』を参照してください。

- パスワード・ファイル・ベースの認証が、デフォルトで使用可能です。つまり、データベースは、SYSDBAまたはSYSOPERシステム権限のあるユーザーの認証についてパスワード・ファイルを使用できます。パスワード・ファイル・ベースの認証は、ORAPWDユーティリティを使用してパスワード・ファイルを作成すると、アクティブになります。
$ORACLE_HOME/dbsディレクトリに対してEXECUTE権限および書込み権限を持つユーザーがORAPWDユーティリティを実行できます。

ただし、パスワード・ファイルの使用は、セキュリティ上のリスクを伴う可能性があることに注意してください。このため、「データベース管理者の厳密認証と集中管理」で説明した認証方式を使用することを検討してください。パスワードによるセキュリティのリスクの例は、次のとおりです。

- 侵入者がパスワード・ファイルを盗んだり攻撃する可能性があります。

- 多くのユーザーがデフォルト・パスワードを変更しない場合があります。

- パスワードが簡単に推定される場合があります。

- パスワードがディレクトリ内に存在すると、無防備になります。

- 短かすぎたり簡単に入力できるパスワードは、侵入者がパスワードの暗号化ハッシュを取得した場合に無防備になります。

注意:
AS SYSDBAまたはAS SYSOPERで要求された接続は、これらのフレーズを使用する必要があります。使用していない場合、接続は失敗します。Oracle DatabaseパラメータO7_DICTIONARY_ACCESSIBILITYはデフォルトではFALSEに設定されており、大切なデータ・ディクショナリへのアクセスを認可ユーザーのみに制限しています。このパラメータによって、AS SYSDBAまたはAS SYSOPER構文も必須になります。

関連項目:
パスワード・ファイルの作成およびメンテナンスの詳細は、『Oracle Database管理者ガイド』を参照してください。

データベースを使用したユーザーの認証

この項の内容は、次のとおりです。

- データベース認証の概要

- データベース認証の利点

- データベースによって認証されるユーザーの作成

データベース認証の概要

Oracle Databaseでは、データベース自体に格納されている情報を使用して、データベースに接続しようとするユーザーを認証できます。データベース認証を使用するようにOracle Databaseを構成するには、対応するパスワードを指定して各ユーザーを作成する必要があります。ユーザー名にはマルチバイトを使用できますが、各パスワードは、データベースでマルチバイト・キャラクタ・セットが使用されている場合でも、シングルバイト・キャラクタで構成する必要があります。ユーザーは、接続の確立時にそのユーザー名およびパスワードを入力する必要があります。Oracle Databaseでは、ユーザーのパスワードは暗号化された形式でデータ・ディクショナリに格納されます。

クライアントまたはデータベースで許可される認証プロトコルを識別するために、データベース管理者はサーバーのsqlnet.oraファイルにSQLNET.ALLOWED_LOGON_VERSIONパラメータを明示的に設定できます。各接続がテストされ、クライアントまたはサーバーがパートナが指定する最低バージョンを満たしていない場合は、認証に失敗してORA-28040「一致する認証プロトコルがありません」エラーが発生します。このパラメータの値には、11、10、9または8を指定できます。デフォルト値は8です。これらの値はデータベース・サーバーのバージョンを表します。保護レベルを最大にするには、値11をお薦めします。ただし、SQLNET.ALLOWED_LOGON_VERSIONを11に設定した場合、Oracle Databaseリリース11.1以前のクライアント・アプリケーションまたはJDBCシン・クライアントは、パスワード・ベースの認証を使用してOracleデータベースへの認証を行うことができない点に注意してください。

データベース認証使用時のセキュリティを高めるために、アカウントのロック、パスワード・エイジングと期限切れ、パスワード履歴およびパスワードの複雑度検証も含めたパスワード管理の使用をお薦めします。パスワード管理の詳細は、「パスワード管理ポリシーの使用」を参照してください。

データベース認証の利点

データベース認証の利点は、次のとおりです。

- ユーザー・アカウントとすべての認証がデータベースによって制御されます。データベースの外部のものには依存しません。

- Oracle Databaseには、データベース認証使用時のセキュリティを高めるために、強力なパスワード管理機能が組み込まれています。

- 小規模なユーザー・コミュニティがある場合の管理が容易になります。

データベースによって認証されるユーザーの作成

次のSQL文は、Oracle Databaseによって識別および認証されるユーザーを作成します。ユーザーsebastianは、Oracle Databaseに接続するたびに割り当てられたパスワードを指定する必要があります。

CREATE USER sebastian IDENTIFIED BY password;

オペレーティング・システムを使用したユーザーの認証

一部のオペレーティング・システムでは、オペレーティング・システムが維持している情報を、ユーザーの認証用にOracle Databaseで使用できます。この方式には、次の利点があります。

- オペレーティング・システムから認証を受けたユーザーは、より簡単にOracle Databaseに接続できます。ユーザー名やパスワードを指定する必要はありません。たとえば、オペレーティング・システムにより認証されたユーザーはSQL*Plusを起動して、コマンドラインで次のコマンドを入力することによりユーザー名とパスワードのプロンプトを省略できます。

SQLPLUS /

SQL*Plusで、次のように入力します。

CONNECT /

- ユーザー認証はオペレーティング・システムで集中管理され、Oracle Databaseがユーザーのパスワードを格納したり管理する必要がなくなります。ただし、ユーザー名は引き続きデータベース内で管理されます。

- データベースとオペレーティング・システムの監査証跡には、同じユーザー名を使用できます。

- 同じシステムで、オペレーティング・システム・ユーザーと非オペレーティング・システム・ユーザーの両方を認証できます。例:

- オペレーティング・システムによってユーザーを認証します。CREATE USER文のIDENTIFIED EXTERNALLY句を使用してユーザー・アカウントを作成し、OS_AUTHENT_PREFIX初期化パラメータを設定して、サーバーに接続しようとするユーザーをOracle Databaseが認証するために使用する接頭辞を指定します。

- 非オペレーティング・システム・ユーザーを認証します。これは、パスワードが割り当てられ、データベースによって認証されるユーザーです。

- Oracle Database Enterprise User Securityユーザーを認証します。このユーザー・アカウントはCREATE USER文のIDENTIFIED GLOBALLY句を使用して作成され、現行の同じデータベースでOracle Internet Directory(OID)によって認証されます。

ただし、オペレーティング・システムを使用してユーザーを認証する場合には、次のデメリットがあります。

- ユーザーには、アクセスが必要なコンピュータのオペレーティング・システム・アカウントが必要です。必ずしもすべてのユーザー(特に管理ユーザー以外のユーザー)がオペレーティング・システム・アカウントを持っているわけではありません。

- ユーザーがこの方式を使用してログインし、端末の前から離れた場合、別のユーザーはパスワードや資格証明が必要ないため簡単にログインできます。これは、深刻なセキュリティ問題になる可能性があります。

- データベース・ユーザーの認証にオペレーティング・システムを使用する場合は、分散データベース環境とデータベース・リンクの管理に特別な注意が必要です。オペレーティング・システム認証のデータベース・リンクは、セキュリティ上の弱点を生み出す可能性があります。そのため、これらのリンクは使用しないことをお薦めします。

関連項目:

- 認証、オペレーティング・システム、分散データベースの概要および分散データ管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

- オペレーティング・システムによる認証の詳細は、そのオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

ネットワークを使用したユーザーの認証

ネットワークでのユーザーの認証は、サード・パーティ・サービスでSecure Sockets Layerを使用して行うことができます。

- Secure Sockets Layerを使用した認証

- サード・パーティ・サービスを使用した認証

Secure Sockets Layerを使用した認証

Secure Sockets Layer(SSL)プロトコルは、アプリケーション・レイヤー・プロトコルです。Oracle Internet Directoryでのグローバル・ユーザー管理とは関係なく、データベースに対するユーザー認証に使用できます。つまり、ユーザーは、ディレクトリ・サーバーを指定しなくても、SSLを使用してデータベースへの認証を行うことができます。

SSLを構成する手順は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

サード・パーティ・サービスを使用した認証

ネットワーク上のOracle Databaseユーザーを認証する場合は、サード・パーティ・ネットワーク認証サービスを使用する必要があります。顕著な例としては、Kerberos、PKI (公開鍵インフラストラクチャ)、RADIUS (Remote Authentication Dial-In User Service)、およびディレクトリ・ベース・サービスがあり、次のセクションで説明しています。

ネットワーク認証サービスを使用できる場合、Oracle Databaseはこれらのネットワーク・サービスによる認証を受け入れることができます。ネットワーク認証サービスを使用する場合は、ネットワーク・ロールとデータベース・リンクについて特別な考慮事項があります。

注意:
Oracle Databaseでネットワーク認証サービスを使用するには、Oracle Database Advanced Securityオプションを備えたOracle Database Enterprise Editionが必要です。

関連項目:
Oracle Database Advanced Securityオプションを備えたOracle Enterprise Editionの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

Kerberosを使用した認証

Kerberosは、共有秘密を使用するサード・パーティの認証システムです。サード・パーティがセキュアであることを保障し、シングル・サインオン機能、集中化されたパスワード・ストレージ、データベース・リンク認証、拡張されたPCセキュリティを提供します。これは、Kerberos認証サーバーまたはCybersafe Active Trust (Kerberosをベースとした商用の認証サーバー)を介して提供されます。

関連項目:
Kerberosの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

RADIUSを使用した認証

Oracle Databaseでは、ユーザー認証、認可、およびアカウンティングに使用される標準のライトウェイト・プロトコルであるRemote Authentication Dial-In User Service (RADIUS)によるユーザーのリモート認証がサポートされています。この機能により、ユーザーはRSA One-Time Password Specifications (OTPS)を使用してOracleデータベースに対する認証もできるようになります。

関連項目:

- RADIUSの構成の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

- OTPSに関するRSAのドキュメント

ディレクトリベース・サービスを使用した認証

中核となるディレクトリを使用すると、認証とその管理が効率的になります。次のようなディレクトリベース・サービスがあります。

- Lightweight Directory Access Protocol (LDAP)を使用するOracle Internet Directoryにより、中央リポジトリを使用してユーザー(エンタープライズ・ユーザーと呼ばれます)に関する情報を格納および管理できます。エンタープライズ・ユーザーのアカウントは、分散環境で作成されます。データベース・ユーザーの場合は、アクセスするデータベースごとにパスワードとともに作成する必要がありますが、エンタープライズ・ユーザーの情報にはOracle Internet Directoryで集中的にアクセスできます。このディレクトリをMicrosoft Active DirectoryやSunOneと統合することもできます。
Oracle Internet Directoryの詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。

- Oracle Enterprise Security Managerを使用すると、Oracle Internet Directoryからのロールの取得と保管ができ、これにより権限の集中管理が可能になることで管理が容易になり、セキュリティ・レベルが向上します。Oracle Enterprise Security Managerの詳細は、「Oracle Enterprise Managerの拡張構成」を参照してください。

公開鍵インフラストラクチャを使用した認証

公開鍵インフラストラクチャ(PKI)に基づいた認証システムではデジタル証明がユーザー・クライアントに発行され、ユーザー・クライアントはこの証明を使用して、認証サーバーを直接使用することなく、企業内のサーバーに対して直接認証を行います。Oracle Databaseで提供されている、公開鍵と証明書を使用するためのPKIは、次のコンポーネントで構成されています。

- SSLによる認証および保護セッション鍵管理。詳細は、「Secure Sockets Layerを使用した認証」を参照してください。

- 信頼できる証明書。識別情報を検証するときに、ユーザー証明書の署名者として信頼するサード・パーティ・エンティティを識別するために使用します。ユーザーの証明書が確認されるとき、署名者は、検証システムに格納されている認証局のトラスト・ポイントまたは信頼できる証明連鎖を使用してチェックされます。この連鎖内に複数レベルの信頼できる証明書がある場合は、下位レベルの証明書を信頼するため、それより上のレベルの証明書をすべて再検証する必要はありません。信頼できる証明書の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

- OracleAS Certificate Authority。これはOracle Identity Managementインフラストラクチャのコンポーネントであり、認証、SSL、S/MIMEなどのPKIベース操作の証明書を必要とする個人、アプリケーション、およびサーバーのX.509バージョン3証明書をプロビジョニングするための統合ソリューションを提供します。OracleAS Certificate Authorityの詳細は、『Oracle Application Server Certificate Authority管理者ガイド』を参照してください。

- Oracle Wallet Manager。Oracleウォレットは、ユーザーの秘密鍵、ユーザー証明書および一連のトラスト・ポイント(信頼できる認証局)を含むデータ構造です。Oracleウォレットの管理方法は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
Oracle Wallet Managerを使用してOracleウォレットを管理できます。これは、Oracleウォレットのセキュリティ資格証明を管理および編集するために使用するスタンドアロンのJavaアプリケーションです。次の操作を実行します。

- 公開鍵と秘密鍵のペアを生成し、認証局に提出する証明書要求を作成して、ウォレットを作成します。

- エンティティの証明書をインストールします。

- Oracle Databaseのクライアントとサーバー上でX.509v3証明書を管理します。

- エンティティの信頼できる証明書を構成します。

- ウォレットをオープンして、PKIベースのサービスにアクセスできるようにします。

- 信頼できるエンティティ、認証局から取得された(署名された) X.509バージョン3証明書。認証局は信頼されているため、これらの証明は要求側エンティティの情報が正確であることと証明書上の公開鍵が認定されるエンティティに属していることを証明します。証明書はOracleウォレットにロードされるため、今後の認証が可能になります。

グローバルなユーザー認証と認可の構成

Oracle Advanced Securityを使用すると、認可も含めたユーザー関連情報を、LDAPベースのディレクトリ・サービスで集中管理できます。ユーザーおよび管理者はデータベース内でグローバル・ユーザーとして識別されます。これは、そのユーザーがSSLによって認証され、ユーザーの管理がデータベースの外部で集中化されたディレクトリ・サービスによって行われることを意味します。グローバル・ロールはデータベース内で定義され、そのデータベースに対してのみ認識されますが、グローバル・ロールに対する認可はディレクトリ・サービスによって行われます。

注意:
ユーザーはSSLで認証されるユーザーであっても構いません。この場合、認可はディレクトリで管理されておらず、これらのユーザーが持っているのはローカル・データベース・ロールのみです。詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

このような集中管理によって、エンタープライズ・ユーザーとエンタープライズ・ロールの作成が可能になります。エンタープライズ・ユーザーの定義と管理は、ディレクトリ内で行います。エンタープライズ・ユーザーには企業内で一意の識別情報があり、複数データベースにまたがるアクセス権限を決定するエンタープライズ・ロールを割り当てることができます。エンタープライズ・ロールは1つ以上のグローバル・ロールで構成されているため、グローバル・ロールのコンテナとみなすことができます。

関連項目:
SYSDBAまたはSYSOPERのアクセスを集中管理する場合は、「データベース管理者の厳密認証と集中管理」を参照してください。

ディレクトリ・サービスによって認可されるユーザーの作成

ディレクトリ・サービスによって認可されるユーザーの指定方法には、次のようなオプションがあります。

- プライベート・スキーマを持つグローバル・ユーザーの作成

- スキーマを共有する複数のエンタープライズ・ユーザーの作成

プライベート・スキーマを持つグローバル・ユーザーの作成

次の文は、SSLによって認証され、エンタープライズ・ディレクトリ・サービスによって認可されるプライベート・スキーマを持ったグローバル・ユーザーの作成方法を示しています。

CREATE USER psmith IDENTIFIED GLOBALLY AS 'CN=psmith,OU=division1,O=oracle,C=US';

AS句に指定されている文字列は、エンタープライズ・ディレクトリにとって意味のある識別子(識別名、つまりDN)です。

この場合は、psmithがグローバル・ユーザーです。ただし、ここでのデメリットは、このユーザーpsmithを、アクセスが必要なすべてのデータベースとディレクトリに作成する必要があることです。

スキーマを共有する複数のエンタープライズ・ユーザーの作成

複数のエンタープライズ・ユーザーがデータベース内の1つのスキーマを共有する可能性があります。これらのユーザーは、エンタープライズ・ディレクトリ・サービスによって認可されますが、データベース内に個々のプライベート・スキーマを持ちません。また、ユーザーはデータベース内に個別に作成されません。ユーザーは、データベース内の共有スキーマに接続します。

スキーマに依存しないユーザーを作成する手順は、次のとおりです。

1. 次の例を使用して、データベースに共有スキーマを作成します。

CREATE USER appschema IDENTIFIED GLOBALLY AS '';

2. ディレクトリに、複数のエンタープライズ・ユーザーとマッピング・オブジェクトを作成します。
このマッピング・オブジェクトは、ユーザーのDNを共有スキーマにマップする方法をデータベースに伝えます。完全なDNマッピング(一意のDN 1つに対して1つのディレクトリ・エントリが対応する)を作成するか、または、ユーザーごとに複数のDNコンポーネントを1つのスキーマにマップできます。例:

OU=division,O=Oracle,C=US

関連項目:
これらのマッピングの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

ほとんどのユーザーは専用スキーマを必要としないため、スキーマに依存しないユーザーを実装することで、ユーザーをデータベースから切り離すことができます。データベース内で同じスキーマを共有する複数のユーザーを作成すると、各ユーザーは他のデータベース内の共有スキーマにもエンタープライズ・ユーザーとしてアクセスできます。

グローバル認証とグローバル認可の利点

グローバルなユーザー認証と認可には、次の利点があります。

- SSL、KerberosまたはWindowsネイティブ認証を使用して、厳密な認証が行われます。

- ユーザーと権限を全社規模で集中管理できます。

- 管理が容易です。ユーザーごとに、社内の各データベースにスキーマを作成する必要がありません。

- シングル・サインオンが容易になります。ユーザーは1回のサインオンのみで複数のデータベースおよびサービスにアクセスできます。さらに、パスワードを使用しているユーザーは、パスワード認証されたエンタープライズ・ユーザーを受け入れる複数データベースにアクセスするための単一パスワードを持つことができます。

- グローバルなユーザー認証と認可はパスワード・ベースのアクセスを提供するため、以前に定義されたパスワード認証方式のデータベース・ユーザーを、集中管理されているディレクトリに(ユーザー移行ユーティリティを使用して)移行できます。これによって、以前のリリースのOracle Databaseクライアントで使用可能だったグローバル認証と認可が引き続きサポートされます。

- CURRENT_USERデータベース・リンクはグローバル・ユーザーとして接続します。ローカル・ユーザーはストアド・プロシージャとの関連においてグローバル・ユーザーとして、グローバル・ユーザー・パスワードをリンク定義に保管することなく、接続できます。

関連項目:
グローバル認証と認可、エンタープライズ・ユーザーおよびエンタープライズ・ロールの詳細は、次のマニュアルを参照してください。

- 『Oracle Database Advanced Security管理者ガイド』

- 『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』

ユーザーとパスワード認証のための外部サービスの構成

この項の内容は、次のとおりです。

- 外部認証の概要

- 外部認証の利点

- 外部認証されるユーザーの作成

- オペレーティング・システムを使用したユーザー・ログインの認証

- ネットワーク認証を使用したユーザー・ログインの認証

外部認証の概要

ユーザー・アカウントに対して外部認証を使用する場合、ユーザー・アカウントはOracle Databaseでメンテナンスされますが、パスワード管理とユーザー認証は外部サービスによって実行されます。この外部サービスは、オペレーティング・システムでもOracle Netのようなネットワーク・サービスでもかまいません。

外部認証の場合、データベースはデータベース・アカウントへのアクセス制限を、その基礎となるオペレーティング・システムまたはネットワーク認証サービスに依存します。データベース・パスワードは、このタイプのログインには使用されません。オペレーティング・システムまたはネットワーク・サービスで許可されている場合は、それにより、ユーザーがデータベースにログインする前にユーザーを認証できます。この機能を使用可能にするには、初期化パラメータOS_AUTHENT_PREFIXを設定し、この接頭辞をOracle Databaseユーザー名で使用します。このOS_AUTHENT_PREFIXパラメータは、Oracle Databaseで全ユーザーのオペレーティング・システム・アカウント名の先頭に追加する接頭辞を定義します。Oracle Databaseは、ユーザーが接続しようとすると、接頭辞付きのユーザー名をデータベース内のOracle Databaseユーザー名と比較します。

OS_AUTHENT_PREFIXをNULL文字列(空の二重引用符""で指定)に設定する必要があります。NULL文字列を使用すると、オペレーティング・システム・アカウント名に接頭辞は追加されないため、Oracle Databaseユーザー名とオペレーティング・システム・ユーザー名は完全に一致します。

OS_AUTHENT_PREFIX=" "

設定したOS_AUTHENT_PREFIXは、データベースの存続期間中は同じ設定が維持されます。接頭辞を変更した場合、古い接頭辞を含むデータベース・ユーザー名は、パスワード認証を使用するように変更しないかぎり、接続に使用できません。

このパラメータのデフォルト値はOPS$であり、これによって古いバージョンのOracle Databaseとの下位互換性を維持しています。たとえば、OS_AUTHENT_PREFIXを次のように設定する場合を想定します。

OS_AUTHENT_PREFIX=OPS$

注意:
OS_AUTHENT_PREFIX初期化パラメータに指定する文字列は、オペレーティング・システムによって大/小文字が区別される場合があります。この初期化パラメータの詳細は、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

オペレーティング・システム・アカウント名tsmithを持つユーザーが、Oracleデータベース・インストールに接続する際にオペレーティング・システムによって認証された場合、Oracle Databaseは対応するデータベース・ユーザーOPS$tsmithの存在をチェックし、存在している場合はこのユーザーを接続できます。オペレーティング・システムによって認証されたユーザーへの参照には、OPS$tsmithのように、必ず接頭辞OPS$が含まれる必要があります。

外部認証の利点

外部認証の利点は、次のとおりです。

- スマートカード、指紋、Kerberos、オペレーティング・システムなど、使用可能な認証メカニズムの選択肢が増えます。

- Kerberosなどのネットワーク認証サービスの多くがシングル・サインオンをサポートしているため、ユーザーは多数のパスワードを記憶する必要がありません。

- 前述の外部認証メカニズムのいずれかをすでに使用している場合は、そのメカニズムをデータベースで使用することで、管理費用を節減できます。

外部認証されるユーザーの作成

次の文は、Oracle Databaseによって識別され、オペレーティング・システムまたはネットワーク・サービスによって認証されるユーザーを作成します。この例では、OS_AUTHENT_PREFIXパラメータは空白(" ")に設定されていると想定しています。

CREATE USER psmith IDENTIFIED EXTERNALLY;

CREATE USER ... IDENTIFIED EXTERNALLY文を使用して、オペレーティング・システムまたはネットワーク・サービスによる認証が必要なデータベース・アカウントを作成できます。Oracle Databaseがこの外部ログイン認証に依存するのは、特定のユーザーのデータベース・リソースへのアクセス権を特定のオペレーティング・システム・ユーザーに付与する場合です。

関連項目:
外部認証の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

オペレーティング・システムを使用したユーザー・ログインの認証

デフォルトでは、Oracle Databaseで許可されるオペレーティング・システム認証ログインは、保護された接続のみを介したログインであるため、Oracle Netおよび共有サーバー構成を使用したログインは含まれません。この制限によって、リモート・ユーザーが、ネットワーク接続を介して別のオペレーティング・システムのユーザーになりすますことを防止します。

データベース初期化パラメータ・ファイルでREMOTE_OS_AUTHENTパラメータをTRUEに設定すると、データベースは保護されていない接続を介して受け取ったクライアント・オペレーティング・システム・ユーザー名を受け入れてアカウント・アクセスに使用します。一般にPCなどのクライアントは、オペレーティング・システムの認証を適切に実行していない場合があるため、この機能を有効にするとセキュリティが非常に低下します。

デフォルトの設定REMOTE_OS_AUTHENT = FALSEを使用すると、安全性の高い構成となり、Oracleデータベースに接続するクライアントがサーバーベースで適切に認証されます。

このパラメータに対する変更は、次回インスタンスを起動して、データベースをマウントしたときに有効となります。一般的に、ホスト・オペレーティング・システムを介したユーザー認証では、個別のデータベース・ユーザー名やパスワードを指定せずに、Oracle Databaseに迅速かつ簡便に接続できます。ユーザー・エントリも、データベースとオペレーティング・システムの各監査証跡で互いに対応します。

REMOTE_OS_AUTHENTパラメータは、Oracle Database 11g リリース1(11.1)では非推奨となっており、下位互換性のためにのみ保持されている点に注意してください。

ネットワーク認証を使用したユーザー・ログインの認証

Oracle Advanced Securityが実行するネットワーク認証は、Kerberosなどのサード・パーティ・サービスを使用するよう構成できます。Oracle Advanced Securityを唯一の外部認証サービスとして使用している場合、Oracle Advanced Securityで可能になるのは保護された接続のみであるため、REMOTE_OS_AUTHENTパラメータの設定は無意味になります。

複数層の認証と認可の使用

複数層の環境では、Oracle Databaseは中間層アプリケーションのセキュリティを管理するために、権限を制限し、すべての層のクライアントの識別情報を保持し、クライアントのかわりに行われたアクションを監査します。トランザクション処理モニターのようにタスクの非常に多い中間層を使用するアプリケーションでは、中間層に接続しているクライアントの識別情報が保持される必要があります。中間層を使用することの1つの利点が接続プーリングであり、これにより複数のユーザーは、それぞれが個別の接続を必要とせずに、データベース・サーバーにアクセスできるようになります。このような環境では、接続を非常に迅速に設定および停止できる必要があります。

この種の環境では、Oracle Call Interfaceを使用して、各ユーザーのデータベース・パスワード認証を可能にする軽量セッションを作成できます。この方法によって、中間層を介して実際のユーザーの識別性が保たれるため、各ユーザーの個別のデータベース接続によるオーバーヘッドは生じません。

パスワードあり、またはパスワードなしで軽量セッションを作成できます。ただし、中間層がファイアウォールの外部またはファイアウォールにある場合は、軽量セッションごとに専用パスワードを設定する方がセキュリティが向上します。内部アプリケーション・サーバーの場合は、パスワードなしの軽量セッションの方が適している場合があります。

クライアント、アプリケーション・サーバーおよびデータベース・サーバーの管理とセキュリティ

複数層環境では、アプリケーション・サーバーはクライアントにデータを提供し、クライアントと1つ以上のデータベース・サーバーとの間のインタフェースとして機能します。アプリケーション・サーバーでは、Webブラウザなどのクライアントの資格証明を検証できます。また、データベース・サーバーでは、アプリケーション・サーバーで実行される操作を監査できます。監査対象の操作には、クライアントで表示する情報の要求など、クライアントのためにアプリケーション・サーバーが実行する操作が含まれます。特定のクライアントに関連しないアプリケーション・サーバー操作の例には、データベース・サーバーへの接続要求があります。

複数層環境における認証は、トラスト領域に基づいています。クライアント認証は、アプリケーション・サーバーのドメインで実行されます。アプリケーション・サーバー自身は、データベース・サーバーによって認証されます。次の操作が実行されます。

- エンド・ユーザーは通常、パスワードまたはX.509証明書を使用して、アプリケーション・サーバーに認証の証明を提供します。

- アプリケーション・サーバーは、エンド・ユーザーを認証してから、それ自体をデータベース・サーバーに対して認証します。

- データベース・サーバーは、アプリケーション・サーバーを認証し、エンド・ユーザーの存在を検証して、そのエンド・ユーザーへの接続権限がアプリケーション・サーバーにあることを検証します。

アプリケーション・サーバーでは、かわりに接続するエンド・ユーザーのロールを使用可能にすることもできます。アプリケーション・サーバーは、これらのロールを認証リポジトリとして機能するディレクトリから取得できます。アプリケーション・サーバーが要求できるのは、これらのロールを使用可能にすることのみです。データベースは、次の要件を検証します。

- クライアント内部のロール・リポジトリをチェックして、そのクライアントにこれらのロールがあることを検証します。

- アプリケーション・サーバーに、ユーザーのために接続し、これらのロールをユーザーのように使用できる権限があることを検証します。

図3-2に、複数層認証の例を示します。

図3-2 複数層認証

次のアクションが実行されます。

1. ユーザーは、パスワードまたはSecure Sockets Layerを使用してログインします。認証情報はOracle Application Serverを介して渡されます。

2. Oracle Internet Directoryはユーザーを認証し、そのユーザーに対応付けられたロールをウォレットから取得して、この情報をOracle Application Serverに戻します。

3. Oracle Application Serverは、ユーザーの識別情報が格納されているウォレットを含むOracle Databaseでこの情報をチェックし、そのユーザーのロールを設定します。

中間層アプリケーションのセキュリティでは、次のような重要な問題に対処する必要があります。

- アカウンタビリティ。データベース・サーバーは、アプリケーションのアクションとアプリケーションがクライアントのかわりに行うアクションを識別できる必要があります。この2種類のアクションを監査できる必要があります。

- 最低限の権限。不慮または不正による無許可のアクティビティの危険性を排除するため、ユーザーと中間層には、それぞれのアクションを実行するために必要最小限の権限を与える必要があります。

複数層環境でのユーザー識別情報の保持

多くの組織では、中間層のメリットを犠牲にせずに、アプリケーションのすべての層でユーザーを認識する必要があります。Oracle Databaseは、次の方法によって、アプリケーションの中間層を介したユーザー識別情報の保持をサポートしています。

- 中間層サーバーを使用したプロキシ認証

- データベースに認識されないアプリケーション・ユーザーの識別でのクライアント識別子の使用

関連項目:
「複数層環境におけるSQL文および権限の監査」

中間層サーバーを使用したプロキシ認証

次の各項では、プロキシ認証の使用方法について説明します。

- プロキシ認証の概要

- プロキシ認証の利点

- プロキシ・ユーザー・アカウントの作成者とは

- プロキシ・ユーザー・アカウントの作成と、作成したプロキシ・ユーザー・アカウントを介したユーザー接続の認可

- 安全性の高い外部パスワード・ストアとプロキシ認証の使用

- プロキシ認証を使用した実際のユーザーの識別情報の引渡し

- 中間層の権限の制限

- ユーザーのプロキシとして機能し、ユーザーを認証する中間層を認可する方法

- 他の方式で認証されたユーザーのプロキシとして機能するために、中間層を認可する方法

- 中間層からデータベースへのユーザーの再認証

プロキシ認証の概要

Oracle Databaseでは、Oracle Call Interface(OCI)、JDBC/OCIまたはJDBCシン・ドライバによって、データベース・ユーザーまたはエンタープライズ・ユーザーにプロキシ認証を提供します。エンタープライズ・ユーザーは、Oracle Internet Directoryで管理されるユーザーで、データベースの共有スキーマにアクセスします。

次の3つの形式のプロキシ認証を使用して、クライアントを認証する中間層サーバーを安全な方法で設計できます。

- 中間層サーバーは、データベース・サーバーを使用してそれ自体を認証し、クライアント(この場合はアプリケーション・ユーザーまたは別のアプリケーション)は、この中間層サーバーを使用してそれ自体を認証します。クライアントの識別情報は、データベースに到達するまで確実に保持されます。

- クライアント(この場合はデータベース・ユーザー)は、中間層サーバーによって認証されません。クライアントの識別情報とデータベース・パスワードは、中間層サーバーを経由してデータベース・サーバーに渡され、そこで認証されます。

- クライアント(この場合はグローバル・ユーザー)は中間層サーバーによって認証され、中間層を介して次のいずれかを渡します。クライアントのユーザー名はそこから取得されます。

- 識別名(DN)

- 証明書

注意:
プロキシ認証と認可に対する証明書の使用は、Oracle Databaseの将来のリリースでサポートされなくなる可能性があります。

いずれの場合でも、中間層サーバーにクライアントの代理としての機能を与えるために、管理者は中間層サーバーを認可する必要があります。

関連項目:
プロキシ・ユーザーに対する中間層サーバーの設計の詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』および『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

プロキシ認証の利点

複数層環境では、プロキシ認証を使用すると、すべての層を通じてクライアントの識別情報と権限が保持され、クライアントのかわりに実行されるアクションが監査されるため、中間層アプリケーションのセキュリティを制御できます。たとえば、この機能によって、Webアプリケーション(プロキシとして機能する)を使用するユーザーの識別情報を、アプリケーションを介してデータベース・サーバーに渡すことができます。

3層システムは、組織にとって次のようなメリットがあります。

- 組織は、アプリケーション・ロジックをアプリケーション・サーバーに、データ記憶域をデータベースにパーティション化することによって、アプリケーション・ロジックとデータ記憶域を分離できます。

- アプリケーション・サーバーおよびWebサーバーを使用して、データベースに格納されているデータにアクセスできます。

- ユーザーは、操作が簡単で使い慣れたブラウザ・インタフェースを使用できます。

- 組織では、多数のシック・クライアントを多数のシン・クライアントと1つのアプリケーション・サーバーに置き換えることによって、コンピューティング・コストを低く抑えることもできます。

さらに、Oracle Databaseのプロキシ認証には、次のセキュリティ上のメリットがあります。

- 中間層がかわりに接続できるユーザー、および中間層がユーザーに対して想定できるロールを制御することによって制限付きトラスト・モデルが実現します。

- OCI、JDBC/OCIまたはJDBCシン・ドライバでユーザー・セッションをサポートし、クライアント再認証のためのオーバーヘッドを排除することによってスケーラビリティが得られます。

- 実際のユーザーの識別情報をデータベースに到達するまで保持し、実際のユーザーのかわりに行われるアクションの監査を可能にすることによって、アカウンタビリティが得られます。

- ユーザーがデータベースに認識されている環境と、ユーザーが単なるアプリケーション・ユーザーでデータベースには認識されていない環境の両方をサポートすることによって柔軟性が得られます。

注意:
Oracle Databaseはこのプロキシ認証機能を3つの層のみでサポートしています。複数の中間層を横断してのサポートはありません。

プロキシ・ユーザー・アカウントの作成者とは

プロキシ・ユーザー・アカウントを作成するためには、ユーザーが次の最低限の権限を持っている必要があります。

- プロキシ・ユーザー・アカウントとして使用されるデータベース・ユーザー・アカウントを作成するためのCREATE USERシステム権限

- Oracle Database Vaultが有効な場合にプロキシ・ユーザー・アカウントを作成するためのDV_ACCTMGRロール

- CREATE SESSIONシステム権限をプロキシ・ユーザー・アカウントに付与できること

- 既存のユーザー・アカウントがプロキシ・アカウントを介してデータベースに接続できるようにするためのALTER USERシステム権限

プロキシ・ユーザー・アカウントを作成する際には、次のガイドラインに従います。

- セキュリティを高めて最小限の権限の原則を守るために、プロキシ・ユーザー・アカウントにCREATE SESSION権限のみを付与します。このユーザーに他の一切の権限を付与しないでください。プロキシ・ユーザー・アカウントは、他のユーザーがプロキシ・アカウントを使用して接続できるようにする場合にのみ使用されます。接続中に実施されるすべての権限は、プロキシ・アカウントではなく、接続しているユーザーに属する必要があります。

- すべてのパスワードと同様、プロキシ・ユーザーに作成するパスワードも強力であり容易に推測されないものにしてください。複数のユーザーがプロキシ・ユーザーとして接続することになるため、このパスワードを強力にすることが特に重要であることを忘れないでください。強力なパスワードの作成に関するガイドラインは、「パスワードの保護に関するガイドライン」を参照してください。

- 「アドバンスト・セキュリティ・オプション」ネットワーク接続機能を使用してネットワーク傍受を防ぐことを検討してください。

- 接続ユーザーが持っている制御の量をさらに微調整する場合は、接続ユーザーがプロキシ・アカウントを介して接続しているときに使用するロールを制限することを検討してください。ALTER USER文を使用すると、指定されたロールまたは指定されたロール以外のロールを使用して接続するユーザー、あるいはロールをまったく使用せずに接続するユーザーを構成できます。

プロキシ・ユーザー・アカウントの作成と、作成したプロキシ・ユーザー・アカウントを介したユーザー接続の認可

CREATE USER文を使用すると次のタイプのユーザー・アカウントを作成でき、これらのすべてがプロキシ・アカウントとして使用できます。

- パスワードによって認証されるデータベース・ユーザー・アカウント

- 外部ユーザー・アカウント。Secure Socket Layer (SSL)やKerberosなどの外部ソースによって認証されます。

- グローバル・ユーザー・アカウント。エンタープライズ・ディレクトリ・サービス(Oracle Internet Directory)によって認証されます。

プロキシ・ユーザー・アカウントを作成し、このプロキシ・ユーザー・アカウントを介したユーザーの接続を認可する手順は、次のとおりです。

1. CREATE USER文を使用してプロキシ・ユーザー・アカウントを作成します。
例:

CREATE USER appuser IDENTIFIED BY password;

2. ALTER USER文のGRANT CONNECT THROUGH句を使用して、既存のユーザーがプロキシ・ユーザー・アカウントを介して接続できるようにします。
例:

ALTER USER preston GRANT CONNECT THROUGH appuser;

ユーザーprestonは多数のロールを持っているが、このユーザーがappuserプロキシ・アカウントを介してデータベースに接続しているときに使用するのは1つのロール(たとえばappuser_role)のみになるようにするとします。次のALTER USER文を使用できます。

ALTER USER preston GRANT CONNECT THROUGH appuser WITH ROLE appuser_role;

ユーザーprestonが持っている他のロールはすべて、このユーザーがappuserプロキシとして接続しているかぎり使用できなくなります。

これらの手順が完了した後で、ユーザーprestonは、次のようにappuserプロキシ・ユーザーを使用して接続できます。

CONNECT appuser[preston]
Enter password: appuser_password

次のことに注意してください。

- プロキシ・ユーザーが実行できるのは、ユーザーprestonが実行権限を持っているアクティビティのみです。プロキシ・ユーザーのappuser自身が持っているのは、最低限の権限(CREATE SESSION)のみであることに注意してください。

- 中間層クライアントでのロールの使用。クライアントとして接続したときに、中間層でアクティブにすることが可能なロールも指定できます。中間層サーバーがクライアントのかわりに実行する操作は、監査の対象にできます。

- プロキシ・ユーザーの検索。現在中間層経由での接続が認可されているユーザーを検索するには、PROXY_USERSデータ・ディクショナリ・ビューを、たとえば次のように問い合せます。

SELECT * FROM PROXY_USERS;

- プロキシ接続の取消し。プロキシ接続の認可を取り消すには、ALTER USER文のREVOKE CONNECT THROUGH句を使用します。たとえば、ユーザーprestonを、プロキシ・ユーザーappuserを介した接続から取り消すには、次の文を実行します。

ALTER USER preston REVOKE CONNECT THROUGH appuser

- パスワードの期限切れとプロキシ接続。中間層で使用されるuse ofパスワードの期限切れは、プロキシを介して認証されたアカウントに適用されません。パスワードを期限切れにするかわりに、アカウントをロックしてください。

関連項目:

- CREATE USER文に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- ALTER USER文に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- エンタープライズ・ユーザー環境におけるプロキシ・ユーザーの管理に関する詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- ネットワーク暗号化と厳密認証の使用に関する詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

- ユーザーのかわりに中間層が行う認証操作の詳細は、「複数層環境におけるSQL文および権限の監査」を参照してください。

安全性の高い外部パスワード・ストアとプロキシ認証の使用

プロキシ認証に使用しているパスワードが不正なユーザーによって取得される懸念がある場合は、プロキシ認証で安全性の高い外部パスワード・ストアを使用してパスワード資格証明をウォレットに格納できます。プロキシ認証と安全性の高い外部パスワード・ストアを使用したOracle Databaseへの接続は、バッチ・ファイルを実行するなどの状況に理想的です。プロキシ・ユーザーがデータベースに接続し、安全性の高い外部パスワードを使用して認証を行うと、不正なユーザーが取得しようとしてもパスワードは公開されません。

安全性の高い外部パスワード・ストアとプロキシ認証を使用する手順は、次のとおりです。

1. プロキシ認証アカウントを、「プロキシ・ユーザー・アカウントの作成と、作成したプロキシ・ユーザー・アカウントを介したユーザー接続の認可」の下の手順で示すように構成します。

2. 安全性の高い外部パスワード・ストアを構成します。詳細は、「クライアントを外部パスワード・ストアを使用するように構成」を参照してください。

その後、ユーザーはパスワードを指定せずにプロキシを使用して接続できます。例:

sqlplus [preston]/@db_alias

安全性の高い外部パスワード・ストアを使用すると、ユーザーはログイン時にユーザー名とパスワードを入力する必要がありません。指定する必要があるのは、tnsnames.oraファイルのSERVICE_NAME値(つまり、db_alias)のみです。

プロキシ認証を使用した実際のユーザーの識別情報の引渡し

エンタープライズ・ユーザーの場合もデータベース・ユーザーの場合も、Oracle Call Interface、JDBC/OCI、またはシン・ドライバによって、中間層は複数のユーザー・セッションを1つのデータベース接続内で設定して各々のユーザー・セッションが接続ユーザーを一意に識別するようにできます(接続プーリング)。これらのセッションにより、中間層からデータベースまで別個のネットワーク接続を作成することによるネットワーク・オーバーヘッドが削減されます。

クライアントからデータベースへの中間層を介した認証を使用する場合の完全な認証順序は次のようになります。

1. クライアントは、中間層が受け入れる任意の認証形式を使用して、中間層に対する認証を行います。たとえば、クライアントは、ユーザー名とパスワード、またはSSLによるX.509証明書を使用して、中間層に対する認証を実行できます。

2. 中間層は、データベースが受け入れる任意の認証形式を使用して、中間層自体をデータベースに対して認証します。認証形式には、パスワード、またはKerberosチケットやX.509証明書(SSL)などのOracle Advanced Securityがサポートしている認証メカニズムがあります。

3. 次に、中間層はOCI、JDBC/OCIまたはシン・ドライバを使用して、ユーザーに対して1つ以上のセッションを作成します。

- ユーザーがデータベース・ユーザーの場合、セッションには少なくともデータベース・ユーザー名が含まれている必要があります。データベースで必要な場合は、このセッションにパスワードを含めることができます(データベースでは、このパスワードをデータベース内のパスワード・ストアに対して検証します)。また、ユーザーに対するデータベース・ロールのリストを含めることもできます。

- ユーザーがエンタープライズ・ユーザーの場合、セッションはユーザーの認証方法に応じて異なる情報を提供します。
例1: ユーザーがSSLを介して中間層に認証された場合、中間層は、そのユーザーのX.509証明書またはセッション内の証明書自体からDNを提供できます。データベースは、DNを使用してOracle Internet Directoryでユーザーを検索します。

例2: ユーザーがパスワード認証方式のエンタープライズ・ユーザーの場合、中間層は、少なくともユーザーのグローバルな一意の名前を提供する必要があります。データベースは、この名前を使用してOracle Internet Directoryでユーザーを検索します。セッションがユーザーのパスワードも提供する場合、データベースでは、このパスワードをOracle Internet Directoryに対して検証します。ユーザー・ロールは、セッションが確立した後でOracle Internet Directoryから自動的に取得されます。

- 中間層は、必要に応じてクライアントに対するデータベース・ロールのリストを提供する場合があります。クライアントのかわりにロールを使用する権限がプロキシにある場合は、これらのロールが使用可能になります。

4. データベースは、ユーザーのかわりにセッションを作成する権限が中間層にあるかどうかを検証します。
アプリケーション・サーバーがクライアントのかわりにプロキシ認証を実行することを管理者によって許可されていない場合、またはアプリケーション・サーバーが指定されたロールをアクティブにすることを許可されていない場合、OCISessionBeginコールは失敗します。

中間層の権限の制限

「最低限の権限」とは、ユーザーの権限は各自の職務を行うのに必要な最小限の権限までにする必要があるという原則です。これを中間層アプリケーションに当てはめると、中間層は必要以上の権限を持つ必要はないということを意味します。Oracle Databaseでは、中間層が特定のデータベース・ユーザーのかわりとしてのみ、特定のデータベース・ロールのみを使用して接続できるように、中間層を制限できます。LDAPディレクトリに保存されたエンタープライズ・ユーザーのかわりに接続するよう中間層の権限を制限するために、マップされたデータベース・ユーザーとして接続する権限を中間層に付与します。たとえば、エンタープライズ・ユーザーがAPPUSERスキーマにマップされている場合は、少なくともAPPUSERのかわりに接続する機能を中間層に付与する必要があります。そうでない場合は、エンタープライズ・ユーザーのセッションを作成しようとした場合に失敗します。

ただし、中間層がエンタープライズ・ユーザーのかわりに接続する機能は制限できません。たとえば、ユーザーSarahが中間層appsrv(データベース・ユーザーでもある)を介してデータベースに接続するとします。Sarahには複数のロールがありますが、Sarahのかわりにclerkロールのみを使用できるように中間層を制限します。

管理者は、appsrvに対して、Sarahのclerkロールのみを使用してSarahのかわりに接続を開始する許可を効果的に付与できます。次の構文を使用します。

ALTER USER sarah GRANT CONNECT THROUGH appsrv WITH ROLE clerk;

デフォルトでは、中間層はどのクライアントに対する接続も確立できません。許可はユーザーごとに付与する必要があります。

appsrvに対して、クライアントSarahに付与されているすべてのロールの使用を許可するには、次の文を使用します。

ALTER USER sarah GRANT CONNECT THROUGH appsrv;

中間層が別のデータベース・ユーザーのOCI、JDBC/OCIまたはシン・ドライバ・セッションを開始するたびに、データベースでは指定されたロールを使用して、そのユーザーに対する接続を開始する権限が中間層にあることを検証します。

注意:
デフォルトのロールを使用せずに、独自のロールを作成し、そのロールに必要な権限のみを割り当ててください。独自のロールを作成すると、ロールによって付与される権限を制御でき、Oracle Databaseでデフォルトのロールが変更または削除された場合も保護されます。たとえば、現在、CONNECTロールには、データベースへの接続で直接必要になるCREATE SESSION権限のみが含まれています。
しかし以前、CONNECTには、ほとんどのユーザーには不要または不適切ないくつかの追加権限がありました。余分な権限は、データベースやアプリケーションのセキュリティを危険にさらす可能性があります。これらは、CONNECTから削除されています。

ロールの詳細は、第4章「権限とロール認可の構成」を参照してください。

ユーザーのプロキシとして機能し、ユーザーを認証する中間層を認可する方法

次の文は、中間層サーバーappserveがユーザーbillとして接続するのを認可します。WITH ROLE句を使用して、appserveがbillに関連付けられた、payrollを除くすべてのロールをアクティブにするよう指定します。

ALTER USER bill
GRANT CONNECT THROUGH appserve
WITH ROLE ALL EXCEPT payroll;

ユーザーbillとして接続するための中間層サーバーの(appserve)認可を取り消すには、次の文を使用します。

ALTER USER bill REVOKE CONNECT THROUGH appserve;

他の方式で認証されたユーザーのプロキシとして機能するために、中間層を認可する方法

ALTER USER ... GRANT CONNECT THROUGH文の AUTHENTICATION REQURED句を使用して、中間層がプロキシ化するユーザーを認可するが、認証はしません。現在サポートされている認証方式は、PASSWORDのみです。

次の文は、この認証方式の例を示しています。

ALTER USER mary
GRANT CONNECT THROUGH midtier
AUTHENTICATION REQUIRED;

この文の中間層サーバーmidtierは、maryとしての接続を認可されており、midtierは、認証のためにユーザー・パスワードをデータベース・サーバーにも渡す必要があります。

中間層からデータベースへのユーザーの再認証

管理者は、ALTER USER SQL文でAUTHENTICATION REQUIREDプロキシ句を使用して、認証が必要であることを指定できます。この場合、中間層はユーザーの認証資格証明を提供する必要があります。

たとえば、ユーザーSarahが中間層appsrvを介してデータベースに接続するとします。管理者は、次の構文を使用して、appsrvに対してSarahの認証資格証明を提供するように要求できます。

ALTER USER sarah GRANT CONNECT THROUGH appsrv AUTHENTICATION REQUIRED;

AUTHENTICATION REQUIRED句は、ユーザーが指定されたプロキシを介して認証される場合に、ユーザーの認証資格証明が提示される必要があることを示しています。

注意:
下位互換性を維持するために、AUTHENTICATED USING PASSWORDプロキシ句を使用した場合は、Oracle DatabaseによってAUTHENTICATION REQUIREDに変換されます。

パスワード・ベースのプロキシ認証の使用

パスワード・ベースのプロキシ認証を使用すると、Oracle Databaseはクライアントのパスワードを中間層サーバーに渡します。次に、中間層サーバーは、そのパスワードを属性として、検証のためにデータ・サーバーに渡します。この認証の主な利点は、データベース操作を実行するために、クライアント・コンピュータにOracleソフトウェアをインストールする必要がないことです。

クライアントのパスワードを渡す場合、中間層サーバーは、設定する属性のタイプとしてOCI_ATTR_PASSWORDを渡して、次のようにOCIAttrSet()関数をコールします。

OCIAttrSet(
session_handle,    /* Pointer to a handle whose attribute gets modified. */
OCI_HTYPE_SESSION, /* Handle type: OCI user session handle. */
password_ptr,      /* Pointer to the value of the password attribute. */
0,                 /* The size of the password attribute value is already
known by the OCI library. */
OCI_ATTR_PASSWORD, /* The attribute type. */
error_handle);     /* An error handle used to retrieve diagnostic
information in the event of an error. */

エンタープライズ・ユーザーでのプロキシ認証の使用

中間層がエンタープライズ・ユーザーであるクライアントとしてデータベースに接続している場合は、識別名または識別名を含むX.509証明書のいずれかが、データベース・ユーザー名のかわりに渡されます。ユーザーがパスワード認証方式のエンタープライズ・ユーザーの場合、中間層は、少なくともユーザーのグローバルな一意の名前を提供する必要があります。データベースは、この名前を使用してOracle Internet Directoryでユーザーを検索します。

クライアントの識別名を渡す場合、アプリケーション・サーバーは、属性タイプとしてOCI_ATTR_DISTINGUISHED_NAMEを持つOracle Call InterfaceメソッドOCIAttrSet()を、次のようにコールします。

OCIAttrSet(session_handle,
OCI_HTYPE_SESSION,
distinguished_name,
0,
OCI_ATTR_DISTINGUISHED_NAME,
error_handle);

証明書全体を渡す場合、中間層は、属性タイプとしてOCI_ATTR_CERTIFICATEを持つOCIAttrSet()を、次のようにコールします。

OCIAttrSet(session_handle,
OCI_HTYPE_SESSION,
certificate,
certificate_length,
OCI_ATTR_CERTIFICATE,
error_handle);

証明書のタイプが指定されていない場合、データベースはデフォルトの証明書タイプX.509を使用します。

注意:

- OCI_ATTR_CERTIFICATEは、Distinguished Encoding Rules(DER)でエンコードされています。

- OCI_ATTR_CERTIFICATEを使用する証明書ベースのプロキシ認証は、Oracle Databaseの将来のリリースではサポートされない予定です。かわりに、OCI_ATTR_DISTINGUISHED_NAMEまたはOCI_ATTR_USERNAME属性を使用してください。

パスワード認証方式のエンタープライズ・ユーザーにプロキシ認証を使用する場合は、パスワードで認証されるデータベース・ユーザーと同じOCI属性(OCI_ATTR_USERNAME)を使用します。Oracle Databaseでは、最初にユーザー名をデータベースに対してチェックします。ユーザーが見つからなかった場合、データベースはディレクトリ内のユーザー名をチェックします。このユーザー名はグローバルに一意である必要があります。

データベースに認識されないアプリケーション・ユーザーの識別でのクライアント識別子の使用

次の各項では、クライアント識別子の使用方法について説明します。

- クライアント識別子について

- 中間層システムでのクライアント識別子の使用方法

- CLIENT_IDENTIFIER属性を使用したユーザー識別情報の保持

- グローバル・アプリケーション・コンテキストから独立したCLIENT_IDENTIFIERの使用

- DBMS_SESSION PL/SQLパッケージを使用したクライアント識別子の設定と消去

クライアント識別子について

Oracle Databaseでは、アプリケーション・ユーザーに対して、組込みアプリケーション・コンテキスト・ネームスペースUSERENVのCLIENT_IDENTIFIER属性を提供します。アプリケーション・ユーザーは、アプリケーションには認識されますが、データベースには認識されません。CLIENT_IDENTIFIER属性は、アプリケーションで識別またはアクセス制御に使用する任意の値を取得し、その値をデータベースに渡すことができます。CLIENT_IDENTIFIER属性は、OCI、JDBC/OCIまたはシン・ドライバでサポートされています。

中間層システムでのクライアント識別子の使用方法

多くのアプリケーションがセッション・プーリングを使用して、複数のアプリケーション・ユーザーが再利用する複数のセッションを設定します。ユーザーは、単一識別情報を使用してデータベースにログイン後、すべてのユーザー接続を維持する中間層アプリケーションに対して認証します。このモデルでは、アプリケーション・ユーザーはアプリケーションの中間層に対して認証されているがデータベースには認識されていないユーザーです。ここでは、これらのタイプのアプリケーションのアプリケーション・ユーザー・プロキシのように機能するCLIENT_IDENTIFIER属性を使用できます。

このモデルでは、中間層はセッション確立時にクライアント識別子をデータベースに渡します。クライアント識別子は、中間層に接続しているクライアント表す任意のもの(たとえばCookieやIPアドレスなど)です。アプリケーション・ユーザーを表しているクライアント識別子はユーザー・セッション情報の中にあり、(USERENVネーミング・コンテキストを使用して)アプリケーション・コンテキストによりアクセスすることもできます。このようにして、アプリケーションはセッションを設定して再利用できると同時に、セッション内でアプリケーション・ユーザーを追跡できます。アプリケーションはクライアント識別子をリセットできるため、異なるユーザーでセッションを再利用し、パフォーマンスが向上します。

CLIENT_IDENTIFIER属性を使用したユーザー識別情報の保持

組込みアプリケーション・コンテキスト・ネームスペースUSERENVの事前定義の属性CLIENT_IDENTIFIERを使用すると、グローバル・アプリケーション・コンテキストで使用するアプリケーション・ユーザー名を取得できます。CLIENT_IDENTIFIER属性は独立して使用することもできます。CLIENT_IDENTIFIER属性をグローバル・アプリケーション・コンテキストから独立して使用する場合、CLIENT_IDENTIFIERは、DBMS_SESSIONインタフェースを使用して設定できます。CLIENT_IDENTIFIERをデータベースに渡す機能は、Oracle Call Interface(OCI)、JDBC/OCIまたはシン・ドライバでサポートされています。

CLIENT_IDENTIFIER属性をグローバル・アプリケーション・コンテキストで使用すると、アプリケーションの作成に必要な柔軟性と高いパフォーマンスが得られます。たとえば、ビジネス・パートナに情報を提供するWebベース・アプリケーションに、ゴールド・パートナ、シルバー・パートナおよびブロンズ・パートナという3タイプのユーザーが用意されていて、それぞれが異なるレベルの使用可能な情報を表しているとします。アプリケーションでは、ユーザーごとに個別のアプリケーション・コンテキストを持つユーザー独自のセッションを設定するのではなく、ゴールド・パートナ、シルバー・パートナおよびブロンズ・パートナ用のグローバル・アプリケーション・コンテキストを設定できます。次に、CLIENT_IDENTIFIERを使用して正しいコンテキストのセッションを指すことによって、適切なタイプのデータを取得します。アプリケーションでは、この3つのグローバル・コンテキストを一度初期化すれば、CLIENT_IDENTIFIERを使用して適切なアプリケーション・コンテキストにアクセスし、データ・アクセスを制限できます。これには、セッションを再利用できるということと、セッションごとにアプリケーション・コンテキストを個別に初期化する必要がなく、一度設定したグローバル・アプリケーション・コンテキストにアクセスできるというパフォーマンス上のメリットがあります。

関連項目:

- グローバル・アプリケーション・コンテキストの実装方法は、「グローバル・アプリケーション・コンテキストの使用」を参照してください。

- 「例: クライアント・セッションIDを使用するグローバル・アプリケーション・コンテキストの作成」

グローバル・アプリケーション・コンテキストから独立したCLIENT_IDENTIFIERの使用

CLIENT_IDENTIFIER属性は、ユーザーがデータベースに認識されていないアプリケーションで特に役立ちます。このような場合、アプリケーションは通常、単一のデータベース・ユーザーとして接続し、すべてのアクションがそのユーザーで実行されます。すべてのユーザー・セッションが同じユーザーとして作成されるため、このセキュリティ・モデルでは、ユーザーごとにデータを分離することが困難になります。これらのアプリケーションでは、CLIENT_IDENTIFIER属性を使用すると、実際のアプリケーション・ユーザーの識別情報をデータベースに保持できます。

この方法によると、CLIENT_IDENTIFIER属性の値を変更することで、複数のユーザーがセッションを再利用できます(この属性は、実際のアプリケーション・ユーザーの名前を取得します)。結果として、ユーザーごとに個別のセッションと属性を設定するためのオーバーヘッドが回避され、アプリケーションによるセッションの再利用が可能になります。CLIENT_IDENTIFIER属性の値が変更されると、その変更は次のOCIコール、JDBC/OCIコールまたはシン・ドライバ・コールに伝達されるため、パフォーマンスが向上します。

たとえば、ユーザーDanielはWeb Expenseアプリケーションに接続します。Danielはデータベース・ユーザーではなく、一般的なWeb Expenseアプリケーション・ユーザーです。アプリケーションは組込みアプリケーション・コンテキスト・ネームスペースにアクセスして、DANIELをCLIENT_IDENTIFIER属性値として設定します。DanielはWeb Expenseフォームを記入し終わるとアプリケーションを終了します。その後に、AjitがWeb Expenseアプリケーションに接続します。Ajitのために新しいセッションを設定するかわりに、アプリケーションはCLIENT_IDENTIFIERをAJITに変更することにより、現在Danielに存在しているセッションを再利用します。これによりデータベースに新しい接続を設定するオーバーヘッドと、グローバル・アプリケーション・コンテキストを設定するオーバーヘッドを回避できます。CLIENT_IDENTIFIER属性は、アプリケーションがアクセス制御のベースにする任意の値に設定できます。アプリケーション・ユーザー名である必要はありません。

CLIENT_IDENTIFIER属性をOCIによって設定する場合は、OCIAttrSet()のコールでOCI_ATTR_CLIENT_IDENTIFIER属性を使用します。この結果、サーバーに対する次のリクエスト時にその情報が伝播され、サーバー・セッションに格納されます。次に例を示します。

OCIAttrSet (session,

OCI_HTYPE_SESSION,
(dvoid *) "appuser1",
(ub4)strlen("appuser1"),
OCI_ATTR_CLIENT_IDENTIFIER,
*error_handle);

JDBCを使用するアプリケーションの場合、JDBCではクライアント識別子が設定されないことに注意してください。クライアント識別子を接続プール環境で設定するには、Dynamic Monitoring Service (DMS)メトリックを使用します。DMSを使用できない場合は、connection.setClientInfoメソッドを使用してください。次に例を示します。

connection.setClientInfo("E2E_CONTEXT.CLIENT_IDENTIFIER", "appuser");

関連項目:

- OCI_ATTR_CLIENT_IDENTIFIERユーザー・セッション・ハンドル属性の中間層アプリケーションでの使用方法は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

- JDBCを使用してクライアント接続を構成する方法の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

DBMS_SESSION PL/SQLパッケージを使用したクライアント識別子の設定と消去

DBMS_SESSIONパッケージを使用して、中間層でCLIENT_IDENTIFIERの値を設定および消去するには、次のインタフェースを使用します。

- SET_IDENTIFIER

- CLEAR_IDENTIFIER

中間層では、SET_IDENTIFIERを使用してデータベース・セッションを特定のユーザーまたはグループに対応付けます。この結果、CLIENT_IDENTIFIERはセッションの属性になるため、セッション情報で確認できます。

DBMS_SESSION.SET_IDENTIFIERプロシージャを使用する場合は、DBMS_APPLICATION_INFO.SET_CLIENT_INFOプロシージャでクライアント識別子の値を上書きできることに注意してください。通常、これらの値は一致する必要があるため、CLIENTID_OVERWRITEイベントがONに設定されている場合は、SET_CLIENT_INFOが設定されていれば、その値をSET_IDENTIFIERにより設定された値に自動的に伝播できます。

CLIENTID_OVERWRITEイベントのステータスをチェックするには、SQL*PlusにログインしてSHOW PARAMETERコマンドを入力します。たとえば、CLIENTID_OVERWRITEが使用可能になっているとします。

SHOW PARAMETER EVENT

NAME                           TYPE               VALUE
------------------------------ ------------------ ------------------
event                          string             clientid_overwrite

CLIENTID_OVERWRITEイベントをシステム全体で使用可能にするには、SYSDBA権限を使用してSQL*PlusにSYSとして接続し、次のALTER SYSTEM文を入力します。

ALTER SYSTEM SET EVENTS 'CLIENTID_OVERWRITE';

または、init.oraファイルに次の行を入力します。

event="clientid_overwrite"

その後、データベースを再起動します。CLIENTID_OVERWRITEイベントを使用禁止にするには、SYSDBA権限を使用してSQL*PlusにSYSでログインし、次のALTER SYSTEM文を実行します。

ALTER SYSTEM SET EVENTS 'CLIENTID_OVERWRITE OFF';

セッションについてのみCLIENTID_OVERWRITEの値を変更する場合は、ALTER SESSION文を使用します。

その後、DBMS_APPLICATION_INFO.SET_CLIENT_INFOプロシージャを使用してクライアント識別子を設定する場合は、クライアント識別子の設定が同一になるようにDBMS_SESSION.SET_IDENTIFIERを実行する必要があります。

関連項目:

- クライアント識別子をグローバル・アプリケーション・コンテキストで使用する方法は、「グローバル・アプリケーション・コンテキストの使用」を参照してください。

- DBMS_SESSIONパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ユーザー認証に関する情報の検索

表3-3に、ユーザー認証に関する情報を提供するデータ・ディクショナリ・ビューを示します。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表3-3 ユーザー認証を示すデータ・ディクショナリ・ビュー

ビュー

説明

DBA_PROFILES

設定や制限など、プロファイルに関する情報を表示します。

DBA_ROLES

データベース・ロールがデータベースにログインする際に使用する認証の種類を表示します。NONEまたはGLOBALなどがあります(AUTHENTICATION_TYPE列を問い合せます)

DBA_USERS

その他のユーザー情報から、次の情報を表示します。

- PASSWORDまたはEXTERNALなどの、ユーザーがデータベースにログインする際に使用する認証の種類を表示します(AUTHENTICATION_TYPE列)

- ユーザーが自分のパスワードを作成したリリース(PASSWORD_VERSIONS列)

DBA_USERS_WITH_DEFPWD

ユーザー・アカウント・パスワードがデフォルト・パスワードかどうかを表示します

PROXY_USERS

現在中間層経由での接続が認可されているユーザーを表示します

V$DBLINK

既存のデータベース・リンク用のユーザー・アカウントを表示します(DB_LINK、OWNER_ID列)

V$SESSION

USERNAME列を問い合せると、同時ログインしているユーザーが表示されます

4 権限とロール認可の構成

この章の内容は、次のとおりです。

- 権限とロールの概要

- 権限付与の対象者

- ユーザーへのSYSDBAおよびSYSOPER管理権限の付与

- システム権限の管理

- ユーザー・ロールの管理

- オブジェクト権限の管理

- ユーザー権限とロールの付与

- ユーザー権限とロールの取消し

- PUBLICロールに対する付与と取消し

- オペレーティング・システムまたはネットワークを使用したロールの付与

- 権限の付与と取消しが有効になるとき

- PL/SQLパッケージおよびタイプでのファイングレイン・アクセスの管理

- ユーザー権限とロールに関する情報の検索

権限とロールの概要

認可には、主に次の2つのプロセスがあります。

- データへのアクセス、処理または変更を特定のユーザーにのみ許可します。

- ユーザーによるアクセスまたは操作に様々な制限を適用します。ユーザーに適用(または除外)する制限は、スキーマ、表または行などのオブジェクトや、時間(CPU、接続またはアイドル時間)などのリソースに適用できます。

ユーザー権限とは、特定タイプのSQL文を実行する権利、別のユーザーのオブジェクトにアクセスする権利、PL/SQLパッケージを実行する権利などを指します。権限のタイプは、Oracle Databaseによって定義されています。

ロールは、ユーザー(通常は管理者)が権限や他のロールをグループ化するために作成します。ロールを使用すると、複数の権限またはロールをユーザーに簡単に付与できます。

ここでは、次の一般的なカテゴリについて説明します。

- システム権限。この権限の受領者は、データベースで標準的な管理作業を実行できます。権限受領者は信頼できるユーザーのみに制限してください。システム権限の詳細は、「システム権限の管理」を参照してください。

- ユーザー・ロール。ロールでは、複数の権限やロールがグループ化されるため、複数のユーザーに対して権限を同時に付与したり、取り消すことができます。ユーザーによるロールの使用を可能にするには、そのユーザーに対してロールを使用可能にしておく必要があります。詳細は、「ユーザー・ロールの管理」を参照してください。

- オブジェクト権限。オブジェクトの各タイプには、オブジェクト権限が対応付けられています。異なるタイプのオブジェクト権限を管理する方法は、「オブジェクト権限の管理」を参照してください。

権限付与の対象者

権限をユーザーに付与すると、そのユーザーはそれぞれの業務に必要な作業を実行できます。なお、権限は、必要な作業を実行する上でその権限が必要なユーザーにのみ付与してください。必要でない権限まで付与すると、セキュリティを維持できなくなる可能性があります。たとえば、管理作業を実行しないユーザーには、SYSDBA管理権限またはSYSOPER権限を付与しないでください。

ユーザーは次の2つの方法で権限を受け取ることができます。

- 権限を明示的にユーザーに付与します。たとえば、employees表にレコードを挿入する権限を、ユーザーpsmithに明示的に付与できます。

- 権限をロール(名前付きの権限グループ)に付与した上で、そのロールを1人以上のユーザーに付与します。たとえば、employees表からレコードを選択、挿入、更新および削除する権限を、clerkという名前のロールに付与し、このロールをユーザーpsmithやrobertに付与できます。

ロールを使用することで権限の管理が容易になり、改善されるため、通常は権限を個々のユーザーではなくロールに付与してください。

関連項目:

- 権限を付与する際に従うベスト・プラクティスは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください。

- システム権限の完全なリストとその詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ユーザーへのSYSDBAおよびSYSOPER管理権限の付与

強力な権限同様、SYSDBAおよびSYSOPER管理権限は信頼できるユーザーにのみ付与してください。ただし、名前に非ASCII文字(HÜBERという名前に含まれるウムラウトなど)を使用しているユーザーには制限があります。こうしたユーザーに管理権限を付与することは可能ですが、Oracle Databaseインスタンスが停止した場合、名前に非ASCII文字を使用しているユーザーには、付与されている権限を使用した認証がサポートされません。データベース・インスタンスが稼働中であれば、この認証はサポートされます。

システム権限の管理

この項の内容は、次のとおりです。

- システム権限の概要

- システム権限を制限することが重要な理由

- システム権限の付与と取消し

- システム権限を付与したり、取り消すことができるユーザー

- ANY権限とPUBLICロールの概要

システム権限の概要

システム権限とは、特定のアクションを実行する権限、または特定のタイプのスキーマ・オブジェクトに対してアクションを実行する権限のことです。たとえば、表領域を作成する権限や、データベース内の任意の表から行を削除する権限などがシステム権限です。

システム権限には100以上の種類があります。各システム権限によって、ユーザーは特定のデータベース操作、またはあるクラスのデータベース操作を実行できます。システム権限は非常に強力な権限であることに注意してください。システム権限は、必要な場合のみ、データベースのロールと信頼できるユーザーに付与してください。システム権限の完全なリストとその詳細は、『Oracle Database SQL言語リファレンス』を参照してください。ユーザーに付与されているシステム権限を検索するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せてください。

システム権限を制限することが重要な理由

システム権限は非常に強力であるため、データベースは、通常のユーザー(管理者以外)がデータ・ディクショナリに対してANYシステム権限(UPDATE ANY TABLEなど)を行使できないようにデフォルトで構成されています。システム権限の制限に関するその他のガイドラインは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください。

- データ・ディクショナリの保護によるシステム権限の制限

- SYSスキーマ内のオブジェクトへのアクセスの許可

データ・ディクショナリの保護によるシステム権限の制限

データ・ディクショナリを保護するには、O7_DICTIONARY_ACCESSIBILITY初期化パラメータをFALSE(デフォルト)に設定します。この機能を、ディクショナリ保護メカニズムと呼びます。

O7_DICTIONARY_ACCESSIBILITY初期化パラメータは、Oracle Databaseリリース7からOracle8i以上のリリースにアップグレードした場合の、システム権限に対する制限を制御します。このパラメータをTRUEに設定すると、SYSスキーマ内のオブジェクトへのアクセスが可能になります(Oracle Databaseリリース7の動作)。ANY権限はデータ・ディクショナリに適用されるため、ANY権限を持つ不正なユーザーがデータ・ディクショナリ表にアクセスし、変更する危険性があります。

O7_DICTIONARY_ACCESSIBILTY初期化パラメータを設定する場合は、initSID.oraファイルで変更します。あるいは、サーバー・パラメータ・ファイル(SPFILE)を使用してデータベースを起動した場合は、SYSDBA権限を持つユーザーSYSとしてSQL*PlusにログインしてからALTER SYSTEM文を入力することもできます。

例4-1では、SQL*PlusのALTER SYSTEM文を発行して、O7_DICTIONARY_ACCESSIBILTY初期化パラメータをFALSEに設定する方法を示しています。

例4-1 O7_DICTIONARY_ACCESSIBILITYのFALSEへの設定

ALTER SYSTEM SET O7_DICTIONARY_ACCESSIBILITY=FALSE SCOPE=SPFILE;

O7_DICTIONARY_ACCESSIBILITYをFALSEに設定すると、任意のスキーマ内のオブジェクトへのアクセスを可能にするシステム権限(たとえば、CREATE ANY PROCEDUREのようなANY権限を持つユーザー)ではSYSスキーマ内のオブジェクトへのアクセスが許可されません。これは、SYSスキーマ内のオブジェクト(データ・ディクショナリ・オブジェクト)へのアクセスがSYSDBA権限を使用して接続するユーザーに制限されていることを意味します。SYSユーザーはSYSDBA権限とSYSOPER権限のどちらかでログインする必要があることに注意してください。それ以外の場合、 ORA-28009「SYSでの接続はSYSDBAまたはSYSOPERで行う必要があります」エラーが発生します。O7_DICTIONARY_ACCESSIBILITYをTRUEに設定すると、データベースにユーザーSYSとしてログインできるようになり、SYSDBA権限やSYSOPER権限を指定する必要もありません。

他のスキーマのオブジェクトへのアクセスを提供するシステム権限で、他のユーザーがSYSスキーマ内のオブジェクトにアクセスすることはできません。たとえば、SELECT ANY TABLE権限を持つユーザーは、他のスキーマのビューや表にはアクセスできますが、ディクショナリ・オブジェクト(動的パフォーマンス・ビューの実表、通常のビュー、パッケージおよびシノニム)は選択できません。ただし、これらのユーザーは、明示的なオブジェクト権限を付与することで、SYSスキーマ内のオブジェクトにアクセスできるようになります。

O7_DICTIONARY_ACCESSIBILITY初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

SYSスキーマ内のオブジェクトへのアクセスの許可

明示的なオブジェクト権限のあるユーザーまたは管理権限で接続しているユーザー(SYSDBA)は、SYSスキーマ内のオブジェクトにアクセスできます。

表4-1に、SYSスキーマ内のオブジェクトへのアクセスが必要なユーザーに対して付与できるロールをリストします。

表4-1 SYSスキーマ・オブジェクトにアクセスできるロール

ロール

説明

SELECT_CATALOG_ROLE

このロールを付与されたユーザーには、データ・ディクショナリ・ビューに対するSELECT権限が与えられます。

EXECUTE_CATALOG_ROLE

このロールを付与されたユーザーには、データ・ディクショナリ内にあるパッケージとプロシージャに対するEXECUTE権限が与えられます。

DELETE_CATALOG_ROLE

このロールを付与されたユーザーは、システム監査表SYS.AUD$およびSYS.FGA_LOG$からレコードを削除できます。

さらにSELECT ANY DICTIONARYシステム権限を、SYSスキーマで作成された表にアクセスが必要なユーザーに付与できます。このシステム権限により、SYSスキーマのあらゆるオブジェクト(そのスキーマに作成された表を含む)への問合せアクセスが可能になります。このシステム権限は、これを必要とする各ユーザーへ個別に付与する必要があります。これはGRANT ALL PRIVILEGESには含まれていませんが、ロールを通じて付与できます。

注意:
これらのロールおよびSELECT ANY DICTIONARYシステム権限は、悪用されるとシステムの整合性が損われる危険があるため、付与する際には十分な注意が必要です。

システム権限の付与と取消し

システム権限は、ユーザーとロールに対して付与したり、取り消すことができます。システム権限をロールに付与すると、そのロールを使用してシステム権限を行使できます。たとえば、ロールを使用すると権限を選択的に使用できるようになります。「ロールの保護に関するガイドライン」で説明する業務分離のガイドラインに従っていることを確認してください。

ユーザーやロールに対するシステム権限の付与と取消しには、次のいずれかの方法を使用します。

- SQL文のGRANTおよびREVOKE

- Oracle Enterprise Manager Database Control

関連項目:

- 「ユーザー権限とロールの付与」

- 「ユーザー権限とロールの取消し」

- 「権限の付与と取消しが有効になるとき」

- 「ユーザー権限とロールに関する情報の検索」

- Database Controlの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

システム権限を付与したり、取り消すことができるユーザー

他のユーザーにシステム権限を付与したり、他のユーザーのシステム権限を取り消すことができるのは、次のタイプのユーザーのみです。

- ADMIN OPTIONによって特定のシステム権限を付与されているユーザー

- GRANT ANY PRIVILEGEシステム権限を付与されているユーザー

そのため、これらの権限は信頼できるユーザーにのみ付与してください。

ANY権限とPUBLICロールの概要

ANYキーワードを使用するシステム権限を使用すると、データベース内のオブジェクトのカテゴリ全体に対して権限を設定できます。たとえば、CREATE ANY PROCEDUREシステム権限により、ユーザーはデータベース内のどこにでもプロシージャを作成可能になります。ANY権限を持つユーザーが作成したオブジェクトの動作は、そのオブジェクトが作成されたスキーマに限定されません。たとえば、ユーザーJSMITHにはCREATE ANY PROCEDURE権限があり、プロシージャをスキーマJONESに作成すると、そのプロシージャはJONESとして実行されることになります。ただし、JONESはJSMITHによって作成されたプロシージャがJONESとして機能していることに気付かない可能性があります。JONESにDBA権限が付与されている場合は、JSMITHがJONESとしてプロシージャを実行することで、セキュリティ違反が発生する可能性があります。

PUBLICロールは、データベース・ユーザー・アカウントが作成されるときすべてのアカウントに自動的に与えられる特別なロールです。デフォルトでは付与されている権限がありませんが、多数の付与があり、ほとんどがJavaオブジェクトに対する付与です。PUBLICロールは削除できません。また、ユーザー・アカウントは常にこのロールを前提とするため、このロールの手動の付与や取消しは意味がありません。PUBLICロールはすべてのデータベース・ユーザー・アカウントが前提とするため、DBA_ROLESおよびSESSION_ROLESデータ・ディクショナリ・ビューには表示されません。

PUBLICロールに権限を付与できますが、付与した権限はOracleデータベースのすべてのユーザーが利用できるようになることに注意してください。このため、PUBLICロールに権限を付与するとき、特にANY権限やシステム権限のように強力な権限の場合は注意してください。たとえば、JSMITHがCREATE PUBLIC SYNONYMシステム権限を持っている場合、他の誰もが使用するとわかっているインタフェースを再定義し、それから自分で作成したPUBLIC SYNONYMでこのインタフェースを指し示すことができます。ユーザーは正しいインタフェースではなくJSMITHのインタフェースにアクセスし、ユーザーのログイン資格証明が盗まれるなど、不正な行為が実行される可能性があります。

この種の権限は非常に強力であるため、不適切な個人に付与するとセキュリティ上のリスクが発生する可能性があります。ANYまたはPUBLICを使用した権限の付与には注意が必要です。他のすべての権限と同様に、これらの権限をユーザーに付与する場合は、「最低限の権限」を付与する原則に従ってください。

強力なANYシステム権限を1つ以上持つユーザーからデータ・ディクショナリ(SYSスキーマの内容)を保護するには、O7_DICTIONARY_ACCESSIBILITY初期化パラメータをFALSEに設定します。このパラメータは、ALTER SYSTEM文(例4-1「O7_DICTIONARY_ACCESSIBILITYのFALSEへの設定」を参照)を使用するか、またはinitSID.oraファイルを変更することで設定できます。その他のガイドラインは、「データベースのインストールと構成の保護に関するガイドライン」を参照してください。

ユーザー・ロールの管理

この項の内容は、次のとおりです。

- ユーザー・ロールの概要

- Oracle Databaseのインストールで事前に定義されているロール

- ロールの作成

- ロール認可のタイプの指定

- ロールの削除

- SQL*Plusユーザーによるデータベース・ロール使用の制限

- セキュア・アプリケーション・ロールを使用したロール権限の保護

ユーザー・ロールの概要

権限の管理と制御は、ロールを使用すると簡単になります。ロールとは、関連する権限のグループに名前を付けたもので、ユーザーや他のロールに付与します。データベース内では、各ロール名を一意にする必要があり、すべてのユーザー名や他のすべてのロール名とは異なる名称にする必要があります。スキーマ・オブジェクトとは異なり、ロールはいずれのスキーマにも含まれません。したがって、ロールを作成するユーザーを、ロールに影響をおよぼすことなく削除できます。

この項の内容は、次のとおりです。

- ロールの機能

- ロールの特性とそのメリット

- ロールの一般的な使用方法

- ロールがユーザーの権限範囲に与える影響

- PL/SQLブロックでのロールの機能

- ロールによるDDL使用の支援または制限

- オペレーティング・システムによるロールの支援方法

- 分散環境でのロールの機能

ロールの機能

ロールとは、ユーザーに権限を素早く簡単に付与するために便利なものです。Oracle Databaseで定義されているロールを使用することもできますが、必要な権限のみを含む独自のロールを作成すると、より継続的な制御が可能になります。Oracle Database定義ロールの権限は変更または削除される場合があります。たとえばCONNECTロールの場合、現在持っている権限はCREATE SESSION権限のみです。以前は、CONNECTロールには他に8個の権限がありました。

ロールは、次の機能を備えています。

- ロールには、システム権限またはオブジェクト権限を付与できます。

- 任意のロールを任意のデータベース・ユーザーに付与できます。

- ユーザーに付与した各ロールは、任意の時点で使用可能または使用禁止にできます。ユーザーのセキュリティ・ドメインには、そのユーザーに対して現在使用可能になっているすべてのロールの権限が含まれており、ユーザーに対して現在使用禁止になっているロールの権限は除外されています。権限を選択的に使用できるように、Oracle Databaseでは、データベース・アプリケーションとユーザーがロールを使用可能または使用禁止にできます。

- 1つのロールを別のロールにも付与できます。ただし、ロールをそのロール自体に付与したり、循環的に付与することはできません。たとえば、role2があらかじめロールrole1に付与されている場合、ロールrole1をロールrole2に付与することはできません。

- ロールがパスワード認証ロールまたはセキュア・アプリケーション・ロールでない場合は、ユーザーに間接的に付与できます。間接的に付与するロールとは、ユーザーにすでに付与されている別のロールを通じて同じユーザーに付与するロールのことです。たとえば、ユーザーpsmithにrole1ロールを付与するとします。その後、role2ロールとrole3ロールをrole1ロールに付与します。これで、role2とrole3の2つのロールは、role1に含まれることになります。つまり、psmithには、直接付与されたrole1に加え、role2ロールとrole3ロールが間接的に付与されたことになります。psmithに対して、直接付与されたロールrole1を使用可能にすると、間接的に付与されたロールrole2およびrole3も同様に使用可能になります。

- 必要に応じて、直接付与されたロールをデフォルト・ロールにできます。直接付与されたロールに対してデフォルト・ロール・ステータスを使用可能または使用禁止にするには、ALTER USER文のDEFAULT ROLE句を使用します。DEFAULT ROLE句は、ユーザーに直接付与されたロールのみを示すようにしてください。ユーザーに直接付与されたロールを検索するには、DBA_ROLE_PRIVSデータ・ディクショナリ・ビューを問い合せます。このビューには、ユーザーに間接的に付与されたロールは含まれません。他のロールに付与されたロールを検索するには、ROLE_ROLE_PRIVSビューを問い合せます。

- ロールがパスワード認証ロールまたはセキュア・アプリケーション・ロールの場合は、ユーザーに間接的に付与することも、デフォルト・ロールにすることもできません。このタイプのロールは、ユーザーに直接付与する必要があります。通常、パスワード認証ロールまたはセキュア・アプリケーション・ロールを使用可能にするには、SET ROLE文を使用します。

ロールの特性とそのメリット

表4-2では、データベース内での権限管理をさらに容易にする、ロールの特性について説明します。

表4-2 ロールの特性とその説明

特性

説明

権限管理に要する労力の削減

複数のユーザーに対して同一の権限セットを明示的に付与するかわりに、関連するユーザー・グループのための権限をまとめて1つのロールに付与しておき、そのグループの各メンバーにはそのロールを付与するだけですみます。

動的な権限管理

あるグループの権限を変更する必要がある場合、修正が必要なのは、そのロールの権限のみです。グループのロールを付与した全ユーザーのセキュリティ・ドメインには、そのロールに対して加えられる変更が自動的に反映されます。

権限の選択的な可用性

あるユーザーに付与したロールを、選択的に使用可能または使用禁止にできます。この機能によって、どのような状況でもユーザー権限を個々に制御できます。

アプリケーションによる認識

ロールの存在はデータ・ディクショナリに記録されます。したがって、ユーザーが特定のユーザー名でアプリケーションを実行したときに、アプリケーションがディクショナリに問い合せ、自動的に特定のロールを使用可能(または使用禁止)にするようにアプリケーションを設計できます。

アプリケーション固有のセキュリティ

ロールの使用はパスワードを使用して保護できます。正しいパスワードを入力するとロールが使用可能になるようなアプリケーションを作成できます。パスワードを知らないユーザーは、ロールを使用可能にできません。

データベース管理者は、データベース・アプリケーションのロールを頻繁に作成します。セキュア・アプリケーション・ロールに対して、アプリケーションを実行するために必要なすべての権限を付与する必要があります。それから保護アプリケーション・ロールを他のロールやユーザーに付与できます。1つのアプリケーションは複数の異なるロールを持つことができ、各ロールには異なる権限のセットが付与され、アプリケーション使用中のデータ・アクセスの可否が決定されます。

DBAはパスワード付きのロールを作成することで、そのロールに付与されている権限が無許可で使用されるのを防止できます。通常、アプリケーションは起動時に適切なロールが使用可能になるように設計されます。そのため、アプリケーション・ユーザーは、アプリケーション・ロールのパスワードを知る必要がありません。

関連項目:
プロシージャに関する制限の詳細は、「ロールによるDDL使用の支援または制限」を参照してください。

ロールの一般的な使用方法

通常は、次のいずれかの目的でロールを作成します。

- データベース・アプリケーションに対する権限の管理(「アプリケーション・ロールの一般的な使用方法」を参照)

- ユーザー・グループに対する権限の管理(「ユーザー・ロールの一般的な使用方法」を参照)

図4-1とその後の各項で、ロールの2通りの使用方法について説明します。

図4-1 ロールの一般的な使用方法

アプリケーション・ロールの一般的な使用方法

アプリケーション・ロールには、特定のデータベース・アプリケーションを実行するために必要な権限をすべて付与します。次に、そのセキュア・アプリケーション・ロールを、他のロールや特定のユーザーに対して付与します。1つのアプリケーションに対して複数の異なるロールを設定し、アプリケーション使用時のデータ・アクセスの量や範囲にあわせて異なる権限セットを各ロールに割り当てることができます。

ユーザー・ロールの一般的な使用方法

ユーザー・ロールは、共通の権限要件を持つデータベース・ユーザーのグループのために作成されるロールです。ユーザーの権限は、セキュア・アプリケーション・ロールと権限をユーザー・ロールに付与し、そのユーザー・ロールを適切なユーザーに付与することで管理できます。

ロールがユーザーの権限範囲に与える影響

各ロールと各ユーザーには、それぞれ独自のセキュリティ・ドメインがあります。ロールのセキュリティ・ドメインには、ロール自体に付与されている権限と、そのロールに付与されたロールに対して付与されている権限が含まれます。

ユーザーのセキュリティ・ドメインには、対応するスキーマ内のすべてのスキーマ・オブジェクトに対する権限、ユーザーに付与された権限、そして現在使用可能なユーザーに付与されたロールの権限が含まれます。(ロールをあるユーザーに対して使用可能にすると同時に、他のユーザーに対して使用禁止にできます。)このドメインには、ロールPUBLICに付与された権限とロールも含まれます。PUBLICロールは、データベース内のすべてのユーザーを表します。

PL/SQLブロックでのロールの機能

PL/SQLブロック内でのロールの使用方法は、そのブロックが無名ブロックであるか、名前付きブロック(ストアド・プロシージャ、ファンクションまたはトリガー)であるか、および定義者権限または実行者権限のどちらで実行されるかによって異なります。

定義者権限を持つ名前付きブロックで使用されるロール

定義者権限で実行される名前付きPL/SQLブロック(ストアド・プロシージャ、ファンクションまたはトリガー)では、すべてのロールは使用禁止になっています。ロールは権限チェックに使用されず、定義者権限プロシージャ内ではロールを設定できません。

SESSION_ROLESビューには、現在使用可能なすべてのロールが表示されます。定義者権限で実行される名前付きPL/SQLブロックでSESSION_ROLESを問い合せると、その問合せは行を戻しません。

関連項目:
『Oracle Databaseリファレンス』

実行者権限を持つ名前付きブロックおよび無名PL/SQLブロックで使用されるロール

実行者権限を使用して実行する名前付きPL/SQLブロックと無名PL/SQLブロックは、使用可能なロールを通じて付与された権限に基づいて実行されます。現行ロールは、実行者権限PL/SQLブロック内での権限チェックに使用されます。動的SQLを使用して、セッション内にロールを設定できます。

関連項目:

- 実行者権限と定義者権限を使用して名前解決と権限チェックを行う方法については、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- PL/SQLの動的SQLの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

ロールによるDDL使用の支援または制限

ユーザーがDDL文を正常に実行するには、その文に応じて1つ以上の権限が必要になります。たとえば、表を作成するには、CREATE TABLEまたはCREATE ANY TABLEシステム権限が必要です。別のユーザーに属する表のビューを作成するには、CREATE VIEWまたはCREATE ANY VIEWシステム権限のみでなく、その表に対するSELECT object権限またはSELECT ANY TABLEシステム権限も必要です。

Oracle Databaseでは、特定のDDL文での特定の権限の使用を制限することで、ロールを介して受け取った権限への依存性を回避します。次の規則は、DDL文に関する権限の制限を示しています。

- DDL操作の実行をユーザーに許可するすべてのシステム権限およびオブジェクト権限は、ロールを介して受け取った場合でも使用可能。例:

- システム権限: CREATE TABLE、CREATE VIEWおよびCREATE PROCEDURE権限

- オブジェクト権限: 表に対するALTERおよびINDEX権限
表に対するREFERENCESオブジェクト権限は、ロールを介して付与されている場合、表の外部キー定義には使用できません。

- DDL文を発行するために必要なDML操作をユーザーが実行できるようにするすべてのシステム権限とオブジェクト権限は、ロールを通じて受け取った場合には使用できません。CREATE VIEW文が使用されているとき、セキュリティ・ドメインにはロールが含まれません。たとえばユーザーはSELECT ANY TABLEシステム権限を付与されている場合、または表に対するSELECT object権限をロールを通じて付与されている場合、これらの権限のどちらを使用しても他のユーザーに属する表でビューは作成できません。これは、ビューが定義者権限のオブジェクトであり、ビューを作成するとき、自分にロールを通じて付与された権限はいずれも(システム権限もオブジェクト権限も)使用できないためです。権限が直接自分に付与されている場合は、この権限を使用できます。しかし権限が後で取り消されると、ビュー定義は無効になり(エラーとなり)、再度使用する前に再コンパイルする必要があります。

ロールを介して受け取った権限の使用許可と使用制限について、次の例で具体的に説明します。

次のようなユーザーを想定します。

- CREATE VIEWシステム権限を持つロールが付与されています。

- employees表に対するSELECT object権限を持つロールが直接付与されています。

- departments表に対するSELECT object権限が直接付与されています。

前述の権限がこのユーザーに直接的および間接的に付与されているとすると、

- このユーザーはemployees表とdepartments表の両方に対してSELECT文を発行できます。

- このユーザーには、employees表のCREATE VIEW権限とSELECT権限がロールを介して付与されていますが、employees表のSELECT object権限がロールを介して付与されていたため、employees表のビューは作成できません。

- このユーザーにはCREATE VIEW権限がロールを介して付与され、departments表のSELECT権限が直接付与されているため、departments表のビューは作成できます。

オペレーティング・システムによるロールの支援方法

環境によっては、オペレーティング・システムを使用してデータベース・セキュリティを管理できます。オペレーティング・システムを使用して、データベース・ロールの付与と取消し、パスワードの認証を管理できます。この機能は、すべてのオペレーティング・システムで利用できるとはかぎりません。

関連項目:
オペレーティング・システムによるロールの管理方法の詳細は、そのオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

分散環境でのロールの機能

分散データベース環境でロールを使用する場合は、必要なすべてのロールを分散(リモート)セッションのデフォルト・ロールとして設定する必要があります。ローカル・データベース・セッション内からリモート・データベースに接続しているときは、これらのロールを使用可能にすることはできません。たとえば、ユーザーは、リモート・サイトでロールを使用可能にしようとするリモート・プロシージャを実行できません。

関連項目:
『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』

Oracle Databaseのインストールで事前に定義されているロール

Oracle Databaseには、データベース管理を容易にする一連の事前定義ロールが用意されています。表4-3に示すこれらのロールは、データベース作成の一部である標準スクリプトの実行時に、Oracleデータベースに対して自動的に定義されます。他のオプションや製品をインストールすると、他の事前定義のロールが作成される場合があります。

表4-3 Oracle Databaseの事前定義ロール

事前定義のロール

説明

ADM_PARALLEL_EXECUTE_TASK

DBMS_PARALLEL_EXECUTE PL/SQLパッケージを使用して表のデータをパラレルに更新するための権限を提供します。

関連項目: DBMS_PARALLEL_EXECUTE PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

AQ_ADMINISTRATOR_ROLE

アドバンスト・キューイングを管理するための権限を提供します。ENQUEUE ANY QUEUE、DEQUEUE ANY QUEUE、MANAGE ANY QUEUE、アドバンスト・キューイングの表に対するSELECT権限、およびアドバンスト・キューイングのパッケージに対するEXECUTE権限が含まれます。

AQ_USER_ROLE

使用されていませんが、主にリリース8.0との互換性のために残されています。DBMS_AQおよびDBMS_AQINパッケージに対するEXECUTE権限を提供します。

AUTHENTICATEDUSER

システムにログインしたユーザーを定義するために、XDBプロトコルで使用されます。

CAPI_USER_ROLE

情報ライフサイクル管理(ILM)、階層ストレージおよび他のアプリケーションを実装する場合に使用されるパッケージへのアクセスを提供します。

関連項目: 『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』

CONNECT

CREATE SESSIONシステム権限を提供します。

このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せることで判別できます。

注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。

関連項目: DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

CSW_USR_ROLE

Oracle SpatialのCatalog Services for the Web(CSW)コンポーネントを管理するユーザー権限を提供します。

関連項目: 詳細は、『Oracle Spatial開発者ガイド』を参照してください。

CTXAPP

Oracle Textの索引および索引プリファレンスの作成権限およびPL/SQLパッケージの使用権限を提供します。このロールはOracle Textユーザーに付与される必要があります。

関連項目: 詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください。

CWM_USER

Oracleデータ・ウェアハウスおよび意思決定支援で使用されるリポジトリ標準であるCommon Warehouse Metadata(CWM)の管理権限を提供します。

関連項目: 詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

DATAPUMP_EXP_FULL_DATABASE

Oracle Data Pumpを使用してOracleデータベースからデータをエクスポートする権限を提供します。

注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。

関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。

DATAPUMP_IMP_FULL_DATABASE

Oracle Data Pumpを使用してOracleデータベースにデータをインポートする権限を提供します。

注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。

関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。

DBA

ADMINオプションを使用して作成されたすべてのシステム権限を提供します。

このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せることで判別できます。

注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。

関連項目: DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

DBFS_ROLE

DBFS(データベース・ファイルシステム)パッケージおよびオブジェクトへのアクセスを提供します。

関連項目: 『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』

DELETE_CATALOG_ROLE

システム監査表(AUD$)に対するDELETE権限を提供します。

EJBCLIENT

Javaストアド・プロシージャからEJBに接続する権限を提供します。

EXECUTE_CATALOG_ROLE

データ・ディクショナリ内のオブジェクトに対するEXECUTE権限を提供します。

EXP_FULL_DATABASE

エクスポート・ユーティリティ(後継はOracle Data Pump)を使用してデータベースの全インポートおよび増分エクスポートを実行するために必要な権限を提供します。含まれる権限は、SELECT ANY TABLE、BACKUP ANY TABLE、EXECUTE ANY PROCEDURE、EXECUTE ANY TYPE、ADMINISTER RESOURCE MANAGER、そして表SYS.INCVID、SYS.INCFIL、SYS.INCEXPに対するINSERT、DELETE、およびUPDATEです。さらにEXECUTE_CATALOG_ROLEロールとSELECT_CATALOG_ROLEロールも含まれます。

このロールは、エクスポート・ユーティリティおよびインポート・ユーティリティを簡単に使用できるように用意されています。

注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。

関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。

GATHER_SYSTEM_STATISTICS

DBMS_STATS.GATHER_SYSTEM_STATISTICSプロシージャを使用して収集されるシステム統計の更新権限を提供します。

関連項目: オプティマイザ統計の管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

GLOBAL_AQ_USER_ROLE

Oracle Streams AQで使用されるLDAPサーバーへの接続を確立する権限を提供します。

関連項目: 詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。

HS_ADMIN_EXECUTE_ROLE

異機種間サービス(HS)PL/SQLパッケージの使用を希望するユーザーに対してEXECUTE権限を提供します。

関連項目: 詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

HS_ADMIN_ROLE

異機種間サービス(HS)PL/SQLパッケージの使用権限およびHS関連のデータ・ディクショナリ・ビューの問合せ権限を提供します。

関連項目: 詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

HS_ADMIN_SELECT_ROLE

異機種間サービスのデータ・ディクショナリ・ビューの問合せ権限を提供します。

関連項目: 詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

IMP_FULL_DATABASE

インポート・ユーティリティ(後継はOracle Data Pump)を使用してデータベースの全インポートを実行するために必要な権限を提供します。システム権限の詳細リスト(権限を表示するにはビューDBA_SYS_PRIVSを使用)と、ロールEXECUTE_CATALOG_ROLEおよびSELECT_CATALOG_ROLEが含まれます。

このロールは、エクスポート・ユーティリティおよびインポート・ユーティリティを簡単に使用できるように用意されています。

注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。

関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。

JAVADEBUGPRIV

Oracle Database Javaアプリケーション・デバッガの実行権限を提供します。

関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

JAVAIDPRIV

このリリースでは非推奨となりました。

JAVASYSPRIV

Oracle JVMで保護されたパッケージの更新を含む、Java 2を使用するための主要な権限を提供します。

関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

JAVAUSERPRIV

Java 2を使用するための制限された権限を提供します。

関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

JAVA_ADMIN

Oracle Database Javaアプリケーションのポリシー表を更新する管理権限を提供します。

関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

JAVA_DEPLOY

ncompおよびdeploynsユーティリティを使用してjavavm/adminディレクトリにncomp DLLをデプロイする権限を提供します。このロールを使用しないと、javavm/deployおよびjavavm/adminディレクトリにアクセスできません。

関連項目: 詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

JMXSERVER

データベース・セッションでJMXエージェントを起動およびメンテナンスする権限を提供します。

関連項目: Oracle Javaアプリケーションの管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

LBAC_DBA

SA_SYSDBA PL/SQLパッケージの使用権限を提供します。

関連項目: 詳細は、『Oracle Label Security管理者ガイド』を参照してください。

LOGSTDBY_ADMINISTRATOR

SQL Apply(ロジカル・スタンバイ・データベース)環境を管理する管理権限を提供します。

関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。

MGMT_USER

SYSMANスキーマに使用される様々なビューに対するSELECT権限を付与します。

OEM_ADVISOR

DBMS_SQLTUNE PL/SQLパッケージによってSQL Tuning Setを作成、削除、選択(読取り)、ロード(書込み)および削除する権限と、ADVISOR PL/SQLパッケージを使用してアドバイザ・フレームワークにアクセスする権限を提供します。

関連項目: 詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

OEM_MONITOR

Oracle Enterprise Managerの管理エージェント・コンポーネントで必要とされる、データベースを監視および管理する権限を提供します。

関連項目: 詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

OLAP_DBA

Oracle OLAPの異なるスキーマでディメンション・オブジェクトを作成する管理権限を提供します。

関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

OLAP_USER

アプリケーション開発者に対し、Oracle OLAPの独自のスキーマでディメンション・オブジェクトを作成する権限を提供します。

関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

OLAP_XS_ADMIN

Oracle OLAPのセキュリティの管理権限を提供します。

関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

ORDADMIN

Oracle Multimedia DICOMの管理権限を提供します。

関連項目: 『Oracle Multimedia DICOM開発者ガイド』

OWB$CLIENT

プロジェクト、モジュール、表、ビュー、マップなどの作成のように、Oracle Warehouse Builderの標準クライアント関連タスクを実行する権限を提供します。Warehouse Builderでは、このロールが作業領域のすべての所有者およびユーザーに自動的に付与されます。(つまり、Warehouse Builderを使用する必要があるユーザーにのロールを明示的に付与する必要がないということになります。)セキュリティ上の理由から、OWB$CLIENTはWarehouse Builderユーザーのデフォルト・ロールではありません。Oracle Warehouse Builderでは、このロールは必要なときのみ使用可能になります。

関連項目: 詳細は、『Oracle Warehouse Builderインストレーションおよび管理ガイド』を参照してください。

OWB_DESIGNCENTER_VIEW

登録されたOracle Warehouse BuilderユーザーがWarehouse Builderパブリック・ビューを問い合せるための、データベース・レベルの権限(ALL_IV_PROJECTSなど)を提供します。Warehouse Builder管理者は、Warehouse Builderセキュリティ・レベルのACCESS_PUBLICVIEW_BROWSERシステム権限を使用して、Warehouse Builderユーザーのパブリック・ビューへのアクセス権を制御できます。

関連項目: 詳細は、『Oracle Warehouse Builderインストレーションおよび管理ガイド』を参照してください。

OWB_USER

Oracle Warehouse Builder作業領域を作成および所有する権限を提供します。作業領域の所有者がこの作業領域にその他のデータベース・ユーザーを登録した場合、Oracle Databaseによりこのロールがこれらのユーザーに付与されます。このロールが付与されたユーザーは、Warehouse Builder Control Centerパブリック・ビューおよびその他のControl Centerユーティリティにもアクセスできます。Oracle Warehouse Builderでは、すべてのWarehouse Builderユーザーにこのロールが付与されます。

関連項目: 詳細は、『Oracle Warehouse Builderインストレーションおよび管理ガイド』を参照してください。

RECOVERY_CATALOG_OWNER

リカバリ・カタログの所有者の権限を提供します。CREATE SESSION、ALTER SESSION、CREATE SYNONYM、CREATE VIEW、CREATE DATABASE LINK、CREATE TABLE、CREATE CLUSTER、CREATE SEQUENCE、CREATE TRIGGER、およびCREATE PROCEDUREが含まれます。

RESOURCE

CREATE CLUSTER、CREATE INDEXTYPE、CREATE OPERATOR、CREATE PROCEDURE、CREATE SEQUENCE、CREATE TABLE、CREATE TRIGGER、CREATE TYPEの各システム権限を提供します。

このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せることで判別できます。

注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。

関連項目: DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

SCHEDULER_ADMIN

権限受領者がDBMS_SCHEDULERパッケージのプロシージャを実行できるようにします。すべてのジョブ・スケジューラ・システム権限が含まれ、DBAロールに含まれます。

関連項目: DBMS_SCHEDULERパッケージに関する詳細は、『Oracle Database管理者ガイド』を参照してください。

SELECT_CATALOG_ROLE

データ・ディクショナリ内のオブジェクトに対するSELECT権限を付与します。

SNMPAGENT

Enterprise Managerの管理エージェントで使用されます。

SPATIAL_CSW_ADMIN

Oracle SpatialのCatalog Services for the Web(CSW)コンポーネントを管理する管理権限を提供します。

関連項目: 詳細は、『Oracle Spatial開発者ガイド』を参照してください。

SPATIAL_WFS_ADMIN

Oracle SpatialのWeb Feature Service(WFS)コンポーネントを管理する管理権限を提供します。

関連項目: 詳細は、『Oracle Spatial開発者ガイド』を参照してください。

WFS_USR_ROLE

Oracle SpatialのWeb Feature Service(WFS)コンポーネントに対するユーザー権限を提供します。

関連項目: 詳細は、『Oracle Spatial開発者ガイド』を参照してください。

WM_ADMIN_ROLE

Oracle Workspace Managerの管理権限を提供します。これにより、ユーザーはDBMS_WMプロシージャをすべてのバージョン対応表、作業領域、およびセーブポイントで、それぞれの所有者に関係なく実行できるようになります。また、ユーザーはWorkspace Managerに固有のシステム・パラメータも変更できるようになります。

関連項目: 詳細は、『Oracle Database Workspace Manager開発者ガイド』を参照してください。

XDBADMIN

権限受領者がXMLスキーマを、その所有者のみが使用したりアクセスするために登録するのではなく、グローバルに登録できるようにします。また権限受領者がOracle XML DB Repositoryにアクセスしているときはアクセス制御リスト(ACL)チェックを回避できるようにもします。

関連項目: XMLスキーマとXML DBリポジトリの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XDB_SET_INVOKER

権限受領者が実行者権限ハンドラを定義して、XMLリポジトリのトリガーのリソース構成を作成または更新できるようにします。デフォルトでは、このロールはDBAロールに付与されますが、XDBADMINロールには付与されません。

関連項目: Oracle DatabaseのXMLリポジトリのトリガーの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XDB_WEBSERVICES

権限受領者がHTTPSを使用してOracle DatabaseのWebサービスにアクセスできるようにします。ただし、パブリックなデータベース内のオブジェクトに対するユーザー・アクセスは提供されません。パブリック・アクセスを許可するには、ユーザーにXDB_WEBSERVICES_WITH_PUBLICロールを付与する必要があります。ユーザーがこれらのWebサービスを使用するには、SYSで、Webサービスのサーブレットを使用可能にする必要があります。

関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XDB_WEBSERVICES_OVER_HTTP

権限受領者がHTTPを使用してOracle DatabaseのWebサービスにアクセスできるようにします。ただし、パブリックなデータベース内のオブジェクトに対するユーザー・アクセスは提供されません。パブリック・アクセスを許可するには、ユーザーにXDB_WEBSERVICES_WITH_PUBLICロールを付与する必要があります。

関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XDB_WEBSERVICES_WITH_PUBLIC

権限受領者が、Oracle DatabaseのWebサービスを介してパブリック・オブジェクトにアクセスできるようにします。

関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

注意:
各インストールで独自のロールが作成されて、必要な権限のみが割り当てられます。このようにして、使用中の権限の詳細な制御が維持されます。このプロセスにより、Oracle Databaseで定義されるロールがOracle Databaseで変更や削除されたとき、既存のロール、権限、またはプロシージャを調整する必要もなくなります。

ロールの作成

ロールはCREATE ROLE文を使用して作成できますが、そのためにはCREATE ROLEシステム権限が必要です。通常、このシステム権限はセキュリティ管理者のみが持っています。

作成した直後のロールには、権限は対応付けられていません。次のステップで、新しいロールに権限または他のロールを付与します。

作成する各ロールには、データベースの既存のユーザー名やロール名とは異なる、一意の名前を指定する必要があります。ロールはどのユーザーのスキーマ内にも格納されません。マルチバイト・キャラクタ・セットを使用するデータベースでは、各ロール名に少なくとも1つのシングルバイト・キャラクタを含めることをお薦めします。ロール名がマルチバイト・キャラクタのみの場合、暗号化されたロール名とパスワードの組合せの安全性は大幅に低くなります。パスワードのガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。

例4-2では、clerkロールを作成しています。

例4-2 パスワードによって認可されるユーザー・ロールの作成

CREATE ROLE clerk IDENTIFIED BY password;

IDENTIFIED BY句を使用して、パスワードによってロールを認可します。CREATE ROLE文のIDENTIFIED BY句は、このロールを付与された特定ユーザーがロールを使用する前に、どの認可方式で認可される必要があるかを指定します。この句を指定しないか、またはNOT IDENTIFIEDを指定すると、認可がなくてもロールが使用可能になります。ロールには、必要な認可方式として次の方式を指定できます。

- パスワードを使用したデータベースによる認可

- 指定のパッケージを使用したアプリケーションによる認可

- オペレーティング・システム、ネットワークまたはその他の外部ソースによる外部認可

- エンタープライズ・ディレクトリ・サービスによるグローバル認可

これらの認可については、次の各項で説明します。

パスワードで保護されたロールの作成の代替手段として、セキュア・アプリケーション・ロールの使用をお薦めします。詳細は、「セキュア・アプリケーション・ロールを使用したロール権限の保護」を参照してください。

ロールの認可方式を設定または変更するには、ALTER ROLE文を使用します。 セキュア・アプリケーション・ロールまたはパスワード認証ロールはユーザーに直接付与する必要があることに注意してください。

例4-3は、clerkロールの変更方法を示しています。これによって、ロールを使用可能にするには、ユーザーが外部ソースによって認可されている必要があることが指定されます。

例4-3 外部ソースによる認可が必要なロールへの変更

ALTER ROLE clerk IDENTIFIED EXTERNALLY;

ロールの認可方式を変更するには、ALTER ANY ROLEシステム権限またはADMINオプション付きのロールが付与されている必要があります。

関連項目:
ロールと権限の管理に使用するSQL文の構文、制限事項および認可情報は、『Oracle Database SQL言語リファレンス』を参照してください。

ロール認可のタイプの指定

ここでは、ロールの認可方式について説明します。ロールを使用するには、ユーザーに対してロールを使用可能にする必要があります。

この項の内容は、次のとおりです。

- データベースを使用したロールの認可

- アプリケーションを使用したロールの認可

- 外部ソースを使用したロールの認可

関連項目:
ロールの使用可能の詳細は、「権限の付与と取消しが有効になるとき」を参照してください。

データベースを使用したロールの認可

データベースによって認可されたロールを、ロール・パスワードを割り当てることで保護できます。パスワードで保護されたロールがユーザーに付与された場合、SET ROLE文でそのロールの正しいパスワードを入力することでロールを使用可または使用禁止にできます。パスワード認証ロールをデフォルト・ロールのリストに追加した場合でも、このパスワード認証ロールをログオン時に認証することはできません。SET ROLE文で必須パスワードを使用して、明示的に使用可能にする必要があります。

例4-4は、SET ROLE文を使用してパスワード認証ロールを設定する方法を示しています。

例4-4 SET ROLEを使用したパスワード認証ロールの設定

SET ROLE clerk IDENTIFIED BY password;

例4-2「パスワードによって認可されるユーザー・ロールの作成」は、clerkというロールを作成するCREATE ROLE文を示しています。このロールを使用可能にするには、パスワードを入力する必要があります。

注意:
マルチバイト・キャラクタ・セットを使用するデータベースの場合も、ロールのパスワードにはシングルバイト・キャラクタのみを使用してください。マルチバイト・キャラクタのパスワードは受け入れられません。パスワードのガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。

アプリケーションを使用したロールの認可

アプリケーション・ロール(セキュア・アプリケーション・ロール)を使用可能にできるのは、認可されたPL/SQLパッケージを使用するアプリケーションのみです。アプリケーション開発者は、アプリケーション内部にパスワードを埋め込むことによってロールを保護する必要はありません。かわりに、アプリケーション・ロールを作成して、ロールを使用可能にすることを認可するPL/SQLパッケージを指定できます。

認可されたPL/SQLパッケージによって使用可能になるロールを作成するには、CREATE ROLE SQL文でIDENTIFIED USING package_name句を使用します。

例4-5では、ロールadmin_roleがアプリケーション・ロールであり、このロールは、PL/SQLパッケージhr.admin内に定義されているモジュールによってのみ使用可能にできることを示しています。

例4-5 PL/SQLパッケージによって認可されるアプリケーション・ロールの作成

CREATE ROLE admin_role IDENTIFIED USING hr.admin;

セキュア・アプリケーション・ロールの詳細は、次の各項を参照してください。

- 「セキュア・アプリケーション・ロールを使用したロール権限の保護」

- 「アプリケーションへのアクセスを制御するセキュア・アプリケーション・ロールの作成」

- 『Oracle Database 2日でセキュリティ・ガイド』

外部ソースを使用したロールの認可

外部ロールは、データベースにローカルに定義できますが、グローバル・ユーザー、グローバル・ロールまたはデータベース内の他のロールには付与できません。オペレーティング・システムまたはネットワーク・クライアントによって認可されるロールを作成できます。

例4-6では、accts_recという名前のロールを作成しています。このロールを使用可能にするには、その前に、ユーザーが外部ソースによって認可されている必要があります。

例4-6 外部ソースによって認可されるロールの作成

CREATE ROLE accts_rec IDENTIFIED EXTERNALLY;

オペレーティング・システムを使用したロールの認可

オペレーティング・システムによるロール認証が有効となるのは、そのオペレーティング・システムによって、オペレーティング・システム権限をアプリケーションと動的にリンクできる場合のみです。ユーザーがアプリケーションを開始すると、オペレーティング・システムはオペレーティング・システム権限をそのユーザーに付与します。付与されたオペレーティング・システム権限は、アプリケーションに対応付けられたロールと一致します。この時点で、アプリケーションはアプリケーション・ロールを使用可能にできます。アプリケーションが終了すると、先に付与されたオペレーティング・システム権限は、そのユーザーのオペレーティング・システム・アカウントから取り消されます。

ロールをオペレーティング・システムによって認可する場合は、オペレーティング・システム・レベルで各ユーザーの情報を構成する必要があります。この操作は、オペレーティング・システムによって異なります。

ロールがオペレーティング・システムによって付与されている場合は、そのオペレーティング・システムによるロールの認可は不要です。

関連項目:
オペレーティング・システムによって付与されるロールの詳細は、「オペレーティング・システムまたはネットワークを使用したロールの付与」を参照してください。

ネットワーク・クライアントを使用したロールの認可

ユーザーがデータベースにOracle Net経由で接続する場合、オペレーティング・システムはデフォルトではユーザーのロールを認証できません。この接続ではOracle Netが必要となるため、共有サーバー構成を介した接続が含まれます。リモート・ユーザーはネットワーク接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。REMOTE_OS_ROLESをFALSE(デフォルト)に設定することをお薦めします。

このようなセキュリティの危険性の心配がないときに、ネットワーク・クライアントに対してオペレーティング・システムのロール認証を使用する場合は、データベース初期化パラメータ・ファイル内の初期化パラメータREMOTE_OS_ROLESをTRUEに設定します。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効となります。

エンタープライズ・ディレクトリ・サービスによるグローバル・ロールの認可

ロールはグローバル・ロールとして定義できます。この場合、そのロールを使用するために(グローバル)ユーザーはエンタープライズ・ディレクトリ・サービスによる認可を受ける必要があります。グローバル・ロールは、権限とロールを付与することによってデータベース内でローカルに定義しますが、グローバル・ロール自体をそのデータベース内のユーザーや他のロールに付与することはできません。グローバル・ユーザーがデータベースへの接続を試みると、エンタープライズ・ディレクトリへの問合せが実行され、そのユーザーに対応付けられたグローバル・ロールが取得されます。

例4-7では、グローバル・ロールを作成しています。

例4-7 グローバル・ロールの作成

CREATE ROLE supervisor IDENTIFIED GLOBALLY;

グローバル・ロールは、エンタープライズ・ユーザー・セキュリティの構成要素の1つです。グローバル・ロールは1つのデータベースにのみ適用されますが、エンタープライズ・ディレクトリに定義されたエンタープライズ・ロールに付与できます。エンタープライズ・ロールは複数データベースのグローバル・ロールを含んだディレクトリ構造であり、エンタープライズ・ユーザーに付与できます。

ユーザーのグローバル認証とグローバル認可、およびエンタープライズ・ユーザー管理におけるロールの概要については、「グローバルなユーザー認証と認可の構成」を参照してください。

関連項目:
エンタープライズ・ユーザー管理の実装の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

ロールの付与と取消し

この項の内容は、次のとおりです。

- ロールの付与と取消しについて

- ロールを付与したり、取り消すことができるユーザー

関連項目:

- 「ユーザー権限とロールの付与」

- 「ユーザー権限とロールの取消し」

- 「権限の付与と取消しが有効になるとき」

- 「ユーザー権限とロールに関する情報の検索」

- Database Controlの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

ロールの付与と取消しについて

システム権限やオブジェクト権限をロールに付与できます。そしていずれのロールも任意のデータベース・ユーザーや他のロールに付与できます(ただしそのロール自体に付与することはできません)。ただし、ロールを循環的に付与することはできません。つまり、ロールYがすでにロールXに付与されている場合は、ロールXをロールYに付与することはできません。

権限を選択的に使用できるように、Oracle Databaseでは、データベース・アプリケーションとユーザーがロールを使用可能または使用禁止にできます。ユーザーに付与した各ロールは、任意の時点で使用可能または使用禁止にできます。ユーザーのセキュリティ・ドメインには、そのユーザーに対して現在使用可能になっているすべてのロールの権限が含まれており、ユーザーに対して現在使用禁止になっているロールの権限は除外されています。

ロールに対して付与されたロールは、間接的に付与されたロールと呼ばれます。この種のロールは、ユーザーに対して明示的に使用可能または使用禁止にできます。ただし、別のロールを含んだロールを使用可能にすると、直接的に付与されたロールに含まれる間接的に付与されたロールは、すべて暗黙のうちに使用可能になります。

ユーザーや別のロールに対してロールを付与したり、取り消すには、次のいずれかの方法を使用します。

- Oracle Enterprise Manager Database Control

- SQL文のGRANTおよびREVOKE

ロールに対して権限を付与または取り消す場合にも同じオプションを使用します。

セキュアなロール(つまりIDENTIFIED BYロール、IDENTIFIED USINGロールまたはIDENTIFIED EXTERNALLYロール)を非セキュアなロールに付与することはできません。SET ROLE文を使用して、セッションに対してセキュアなロールを有効化できます。

ロールを付与したり、取り消すことができるユーザー

GRANT ANY ROLEシステム権限を持っているユーザーであれば、グローバル・ロールを除くあらゆるロールを、データベースの他のユーザーやロールに付与または取り消すことができます。(グローバル・ロールはOracle Internet Directoryなどのディレクトリ内で管理されますが、その権限は単一のデータベース内に含まれます。)デフォルトでは、SYSまたはSYSTEMユーザーがこの権限を持っています。このシステム権限は非常に強力であるため、付与する場合は控えめに設定する必要があります。

ADMIN OPTION付きでロールを付与されたユーザーは、データベースの他のユーザーやロールに対してロールを付与したり、そのロールを取り消すことができます。つまり、このオプションによって、選択的なロール付与の管理が可能になります。

関連項目:
グローバル・ロールの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

ロールの削除

状況によっては、データベースからロールを削除した方がよい場合があります。削除したロールを付与されていたすべてのユーザーとロールのセキュリティ・ドメインは、削除したロール権限がなくなったことを反映するために、ただちに変更されます。削除したロールによって間接的に付与されていたロールもすべて、関連するセキュリティ・ドメインから削除されます。ロールを削除することによって、すべてのユーザーのデフォルト・ロール・リストからそのロールが自動的に削除されます。

オブジェクトの存在はロールを介して受け取った権限に依存しないため、ロールが削除されても、表や他のオブジェクトは削除されません。

ロールは、SQL文DROP ROLEを使用して削除します。ロールを削除するには、DROP ANY ROLEシステム権限またはADMINオプション付きのロールが付与されている必要があります。

次の文は、ロールCLERKを削除します。

DROP ROLE clerk;

SQL*Plusユーザーによるデータベース・ロール使用の制限

この項では、SQL*Plusユーザーによるデータベース・ロールの使用を制限する機能について説明します(これによって、セキュリティに関わる深刻な問題を回避できます)。

- セキュリティに関する潜在的な問題となる非定型ツールの使用

- PRODUCT_USER_PROFILE表を介したロールの制限

- ストアド・プロシージャを使用したビジネス・ロジックのカプセル化

セキュリティに関する潜在的な問題となる非定型ツールの使用

事前作成データベース・アプリケーションは、アプリケーション使用中にユーザー・ロールを使用可能および使用禁止にすることも含めて、ユーザーのアクションを明示的に制御します。一方、SQL*Plusなどの非定型の問合せツールを使用すると、ユーザーは付与されたロールを使用可能および使用禁止にする文も含めて、あらゆるSQL文を発行できます(正常終了する場合としない場合があります)。

アプリケーションのユーザーは、そのアプリケーションに付加された権限を使用し、非定型ツールによってデータベース表に破壊的なSQL文を発行する恐れがあります。

たとえば、次の使用例を考えてみます。

- Vacation(休暇)アプリケーションには、それに対応するvacationロールがあります。

- このvacationロールには、emp_tab表に対してSELECT、INSERT、UPDATEおよびDELETE文を発行する権限が含まれています。

- Vacationアプリケーションは、vacationロールを介して取得した権限の使用を制御します。

ここで、vacationロールを付与されたユーザーを考えてみます。このユーザーが、Vacationアプリケーションを使用するかわりに、SQL*Plusを実行するとします。この時点でユーザーが制限を受けるのは、明示的に付与された権限またはロール(vacationロールを含む)を介して付与されている権限からのみです。SQL*Plusは非定型の問合せツールであるため、設計されたデータベース・アプリケーションを使用する場合のように、ユーザーは一連の事前定義アクションに制限されることはありません。ユーザーは、emp_tab表のデータの問合せや変更を自由に実行できます。

PRODUCT_USER_PROFILE表を介したロールの制限

PRODUCT_USER_PROFILE表(これはSYSTEMスキーマです)を使用して、特定のSQLおよびSQL*Plusコマンドを各ユーザーのSQL*Plus環境で使用禁止にできます。Oracle DatabaseでなくSQL*Plusでこのセキュリティが実行されます。GRANT、REVOKE、およびSET ROLEコマンドへのアクセスを制限して、ユーザーによる各自のデータベース権限の変更を制御することもできます。

PRODUCT_USER_PROFILE表を使用すると、ユーザーがアプリケーションでアクティブにできないロールをリストできます。また、様々なコマンド(SET ROLEなど)の使用を明示的に禁止できます。

たとえば、PRODUCT_USER_PROFILE表にエントリを作成して、次の処理を実行できます。

- SQL*Plusで、clerkおよびmanagerロールの使用を禁止できます。

- SQL*Plusで、SET ROLEの使用を禁止できます。

ユーザーMarlaが、SQL*Plusを使用してデータベースに接続するとします。Marlaには、clerk、managerおよびanalystのロールがあります。前述のPRODUCT_USER_PROFILEのエントリによって、Marlaは、SQL*Plusでanalystロールのみを使用できます。また、GinnyがSET ROLE文を発行しようとすると、SET ROLEの使用を禁止するPRODUCT_USER_PROFILE表のエントリが原因で、発行を明示的に禁止されます。

PRODUCT_USER_PROFILE表は、様々な理由からセキュリティが完全には保証されないことに注意してください。前述の例では、SET ROLEがSQL*Plusで禁止されていますが、Marlaに直接付与されているその他の権限がある場合、MarlaはSQL*Plusを使用してそれらの権限を使用できます。

関連項目:
PRODUCT_USER_PROFILE表の詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

ストアド・プロシージャを使用したビジネス・ロジックのカプセル化

ストアド・プロシージャは、ビジネス・ロジックによって権限の使用をカプセル化し、適正なビジネス・トランザクションのコンテキストでのみ権限が実行されるようにします。たとえば、アプリケーション開発者は、employees表にある従業員の名前および住所を、通常の勤務時間内にのみ更新するプロシージャを作成できます。また、セキュリティ管理者は、人事部門の担当者にemployees表のUPDATE権限を付与するのではなく、プロシージャのみに権限を付与できます。これによって、人事部門の担当者が権限を使用できるのはプロシージャのコンテキスト内のみになり、employees表を直接更新できなくなります。

セキュア・アプリケーション・ロールを使用したロール権限の保護

セキュア・アプリケーション・ロールは、認可されたPL/SQLパッケージ(またはプロシージャ)でのみ使用可能にできるロールです。PL/SQLパッケージ自体には、アプリケーションへのアクセスを制御するために必要なセキュリティ・ポリシーが反映されます。

この方法でロールを作成すると、起動対象アプリケーションに対してこのタイプのロールを使用可能にする場合に制限が加えられます。たとえば、アプリケーションはユーザーがプロキシを介して接続しているかどうかをチェックするなど、認証およびカスタマイズ認可を実行できます。

このタイプのロールでは、パスワードがアプリケーションのソース・コードに埋め込まれたり、表に格納されることがないため、セキュリティが強化されます。このように、データベースが実行する処理は、セキュリティ・ポリシーの実装に基づいており、その定義は1箇所(アプリケーション内ではなくデータベース内)に格納されます。ポリシーの変更が必要な場合は、アプリケーションを修正することなく1箇所の変更で済みます。ポリシーはロールと結び付けられているため、ユーザーがデータベースに接続する方法に関係なく、結果は常に同じです。

セキュア・アプリケーション・ロールを使用可能にするには、ユーザーがセキュア・アプリケーション・ロールによって付与された権限を行使する前のログイン時に、基礎となるパッケージをアプリケーションから直接起動して実行する必要があります。ログイン・トリガーを使用してセキュア・アプリケーション・ロールを使用可能にすることも、このタイプのロールをデフォルト・ロールにすることもできません。

セキュア・アプリケーション・ロールを使用可能にすると、認可されたPL/SQLパッケージがコール・スタックにあることが検証されます。つまり、認可されたPL/SQLパッケージがロールを使用可能にするコマンドを発行しているかどうかが検証されます。

セキュア・アプリケーション・ロールは、データベース接続の存在を保証するために使用できます。セキュア・アプリケーション・ロールはパッケージによって実装されるロールであるため、このパッケージによって、ユーザーが中間層を介して、または特定のIPアドレスからデータベースに接続できることを検証できます。この方法により、セキュア・アプリケーション・ロールは、ユーザーがアプリケーション外のデータにアクセスすることを防ぎます。ユーザーは、付与されているアプリケーション権限のフレームワーク内で作業するように規定されます。

関連項目:

- 「アプリケーションへのアクセスを制御するセキュア・アプリケーション・ロールの作成」

- 『Oracle Database 2日でセキュリティ・ガイド』

オブジェクト権限の管理

この項の内容は、次のとおりです。

- オブジェクト権限の概要

- オブジェクト権限の付与または取消し

- オブジェクト権限の管理

- 表に対する権限の管理

- ビューに対する権限の管理

- プロシージャに対する権限の管理

- 型に対する権限の管理

オブジェクト権限の概要

オブジェクト権限は、データベース・オブジェクトに対してユーザーに認める権利です。たとえば、次のことをする権利がオブジェクト権限です。

- エディションの使用

- 表の更新

- 他のユーザーの表からの行の選択

- 他のユーザーのストアド・プロシージャの実行

関連項目:
オブジェクト権限とそれぞれで許可されている操作のリストは、『Oracle Database SQL言語リファレンス』を参照してください。

オブジェクト権限の付与または取消し

オブジェクトの各タイプには、異なるオブジェクト権限が対応付けられています。

ALL [PRIVILEGES]を指定して、オブジェクトに対するすべての使用可能なオブジェクト権限の付与または取消しが可能です。ALLは権限ではなくショートカットのようなもので、つまり1つのGRANT文またはREVOKE文ですべてのオブジェクト権限を付与または取消しするための方法です。すべてのオブジェクト権限がALLショートカットを使用して付与された場合でも、権限を個別に取り消すことができます。

同様に、個別に付与した権限をALLを指定してすべて取り消すこともできます。ただし、REVOKE ALLによって整合性制約が削除される場合(整合性制約は取り消そうとしているREFERENCES権限に依存しているため)は、REVOKE文にCASCADE CONSTRAINTSオプションを指定する必要があります。

例4-8では、CASCADE CONSTRAINTSを使用してHRスキーマ内の注文表に対するすべての権限を取り消しています。

例4-8 CASCADE CONSTRAINTSを使用したすべてのオブジェクト権限の取消し

REVOKE ALL
ON orders FROM hr
CASCADE CONSTRAINTS;

オブジェクト権限の管理

オブジェクト権限では、特定のスキーマ・オブジェクトに対して特定のアクションを実行する権限を付与します。

各タイプのスキーマ・オブジェクトごとに、異なるオブジェクト権限があります。オブジェクト権限の例には、departments表から行を削除する権限があります。

クラスタ、索引、トリガー、データベース・リンクなど、一部のスキーマ・オブジェクトには、対応付けられたオブジェクト権限がありません。これらのオブジェクトの使用は、システム権限によって決定されます。たとえば、クラスタを変更するには、ユーザーはそのクラスタを所有しているか、またはALTER ANY CLUSTERシステム権限が必要です。

次の各項では、このような権限の付与と取消しについて説明します。

- 「オブジェクト権限の付与と取消し」

- 「オブジェクト権限を付与できるユーザー」

- 「シノニムを持つオブジェクト権限の使用」

次の各項では、特定のスキーマ・オブジェクトに適用されるオブジェクト権限について説明します。

- 「表に対する権限の管理」

- 「ビューに対する権限の管理」

- 順序(『Oracle Database管理者ガイド』の順序の管理に関する項を参照)

- 「プロシージャに対する権限の管理」

- ファンクションとパッケージ(『Oracle Database管理者ガイド』のオブジェクト依存性の管理に関する項を参照)

- 「型に対する権限の管理」

オブジェクト権限の付与と取消し

オブジェクト権限は、ユーザーとロールに対して付与したり、取り消すことができます。オブジェクト権限をロールに付与した場合は、その権限を選択的に使用可能にできます。

ユーザーとロールに対するオブジェクト権限の付与と取消しには、次のいずれかの方法を使用できます。

- SQL文のGRANTおよびREVOKE

- Oracle Enterprise Manager Database Control

関連項目:
Database Controlの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

オブジェクト権限を付与できるユーザー

ユーザーは、自分のスキーマに含まれているスキーマ・オブジェクトに関しては、すべてのオブジェクト権限が自動的に付与されています。GRANT ANY OBJECT PRIVILEGEを持つユーザーは、GRANT文のWITH GRANT OPTION句を使用してもしなくても、指定したオブジェクト権限を別のユーザーに付与できます。また、GRANT ANY OBJECT PRIVILEGEを持つユーザーは、その権限を使用して、オブジェクト所有者またはGRANT ANY OBJECT PRIVILEGE権限を持つ他のユーザーによって付与されたオブジェクト権限を取り消すことができます。この句を指定しない場合、権限受領者はその権限を使用できますが、別のユーザーには付与できません。

関連項目:
GRANTおよびGRANT ANY OBJECT PRIVILEGEの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

シノニムを持つオブジェクト権限の使用

CREATE SYNONYM文を使用して、表、ビュー、順序、演算子、プロシージャ、ストアド・ファンクション、パッケージ、マテリアライズド・ビュー、Javaクラス・スキーマ・オブジェクト、ユーザー定義オブジェクト・タイプのシノニム、または他のシノニムを作成できます。ユーザーにシノニムを使用する権限を付与すると、基礎オブジェクトで付与されたオブジェクト権限は、ユーザーがベース・オブジェクトを名前で参照するかシノニムを使用して参照するかに関係なく適用されます。

たとえば、ユーザーOEが次のシノニムをCUSTOMERS表に作成するとします。

CREATE SYNONYM customer_syn FOR CUSTOMERS;

それから、OEはcustomer_synシノニムに対するSELECT権限をユーザーHRに付与します。

GRANT SELECT ON customer_syn TO HR;

ユーザーHRは、次のどちらかの問合せを試みます。

SELECT COUNT(*) FROM OE.customer_syn;

SELECT COUNT(*) FROM OE.CUSTOMERS;

どちらの問合せも同じ結果になります。

COUNT(*)
----------
319

シノニムを他のユーザーに権限付与すると、権限付与はシノニム自体に適用されるのでなく、シノニムが表す基礎オブジェクトに適用されることに注意してください。たとえば、ユーザーHRが自分の権限についてALL_TAB_PRIVSデータ・ディクショナリ・ビューを問い合せると、次のことを知ります。

SELECT TABLE_SCHEMA, TABLE_NAME, PRIVILEGE
FROM ALL_TAB_PRIVS
WHERE TABLE_SCHEMA = 'OE';

TABLE_SCHEMA  TABLE_NAME  PRIVILEGE
------------  ----------  ----------
OE            CUSTOMER    SELECT
OE            ORDERS      UPDATE

結果にはこのユーザーが、他の権限に加えて、customer_synシノニムの基礎オブジェクト、つまりOE.CUSTOMER表に対するSELECT権限を持っていることが示されます。

この時点でユーザーOEがcustomer_synシノニムに対するSELECT権限をHRから取り消した場合に、HRが自分の権限を再度調べたときの結果を次に示します。

TABLE_SCHEMA  TABLE_NAME  PRIVILEGE
------------  ----------  ---------
OE            ORDERS      UPDATE

ユーザーHRは、OE.CUSTOMER表に対するSELECT権限を失っています。このユーザーがOE.CUSTOMERS表を問い合せると、次のエラーが表示されます。

SELECT COUNT(*) FROM OE.CUSTOMERS;

ERROR at line 1:
ORA-00942: table or view does not exist

表に対する権限の管理

表に対するオブジェクト権限によって、DML(データ操作言語)またはDDL(データ定義言語)操作レベルでの表のセキュリティが実現します。

次の各項では、表に対する権限とDMLおよびDDL操作について説明します。

- 表に対する権限がデータ操作言語操作に与える影響

- 表に対する権限がデータ定義言語操作に与える影響

表に対する権限がデータ操作言語操作に与える影響

表またはビューでDELETE、INSERT、SELECTおよびUPDATEの各DML操作を使用する権限を付与できます。これらの権限は、表のデータの問合せや操作が必要なユーザーとロールに対してのみ付与してください。

表に対するINSERT権限とUPDATE権限は、表の特定の列に制限できます。選択的なINSERT権限を付与されたユーザーは、選択した列に値を持つ行を挿入できます。他のすべての列には、NULLまたはその列のデフォルト値が挿入されます。選択的なUPDATE権限によって、ユーザーは行の特定の列に限ってその値を更新できます。機密データに対するユーザー・アクセスを制限するには、INSERT権限とUPDATE権限を選択的に使用します。

たとえば、データ入力ユーザーにemployees表のsalary列を変更させないようにするには、そのsalary列を除外した選択的なINSERT権限またはUPDATE権限を付与できます。また、salary列を除外したビューによって、同じ制限をさらに高いセキュリティ・レベルで実現できます。

関連項目:
DML操作の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表に対する権限がデータ定義言語操作に与える影響

ALTER、INDEXおよびREFERENCESの各権限は、表に対するDDL操作の実行を許可します。これらの権限によって、他のユーザーは表への依存性を変更または作成できるため、権限の付与は控えめに行う必要があります。

表に対してDDL操作を実行するユーザーには、さらに他のシステム権限やオブジェクト権限が必要な場合があります。たとえば、表にトリガーを作成するには、その表に対するALTER TABLEオブジェクト権限とCREATE TRIGGERシステム権限の両方が必要です。

INSERT権限やUPDATE権限と同様に、REFERENCES権限は、表の特定の列を対象として付与できます。REFERENCES権限を付与されたユーザーは、付与の対象となった表を、自分の表の中に作成する外部キーの親キーとして使用できます。外部キーの存在によって、親キーに対して実行できるデータ操作と表の変更が制限されるため、このアクションは特殊な権限によって制御されます。列固有のREFERENCES権限によって、権限受領者が使用できるのは、指定された列(この列には、当然、親表の主キーまたは一意キーが最低1つ含まれている)に制限されます。

関連項目:
主キー、一意キーおよび整合性制約の詳細は、『Oracle Database概要』のデータ整合性に関する項を参照してください。

ビューに対する権限の管理

この項の内容は、次のとおりです。

- ビューに対する権限の概要

- ビューの作成に必要な権限

- ビューによる表セキュリティの強化

ビューに対する権限の概要

ビューとは、1つ以上の表から選択されたデータを表現したもので、他のビューが含まれていることもあります。ビューには、基礎となる表の構造が表示されます。ビューに表示されたデータは、ストアド・クエリーの結果とみなすことができます。ビュー内に実際のデータはなく、表示する内容は基礎となる表とビューから導出されます。ビューを問い合せて、表示するデータを変更できます。ビュー内のデータは更新または削除でき、新規データも挿入できます。これらの操作は、ビューの基礎である表を直接変更するため、実表の整合性制約とトリガーに従います。

DMLオブジェクト権限は、表の場合と同様にビューに対しても適用できます。ビューに対するオブジェクト権限は、ビューの導出元の実表に実際に影響を与える様々なDML操作を許可します。

ビューの作成に必要な権限

ビューを作成するには、次に示す要件を満たす必要があります。

- 次のどちらかのシステム権限が、明示的に、またはロールを介して付与されている必要があります。

- CREATE VIEWシステム権限(自分のスキーマ内にビューを作成するため)

- CREATE ANY VIEWシステム権限(別のユーザーのスキーマ内にビューを作成するため)

- 次のいずれかの権限が明示的に付与されている必要があります。

- ビューの基礎となるすべてのベース・オブジェクトに対するSELECT、INSERT、UPDATEまたはDELETEオブジェクト権限

- SELECT ANY TABLE、INSERT ANY TABLE、UPDATE ANY TABLEまたはDELETE ANY TABLEシステム権限

- さらに、自分のビューへのアクセス権を他のユーザーに付与するためには、ベース・オブジェクトに対するGRANT OPTION句付きのオブジェクト権限、またはADMIN OPTION句付きの適切なシステム権限を持っている必要があります。これらの権限を持っていない場合は、自分のビューに対するアクセス権を他のユーザーに付与できません。付与しようとすると、 ORA-01720「object_nameに対するGRANTオプションは存在しません。」エラーが発生します。object_nameはビューの基礎となるオブジェクトを参照しており、ユーザーにはこのオブジェクトに対する十分な権限がありません。

関連項目:
『Oracle Database SQL言語リファレンス』

ビューによる表セキュリティの強化

ユーザーがビューを使用するには、ビュー自体に対する適切な権限のみが必要であり、ビューの基礎となるオブジェクトに対する権限は不要です。ただし、ビューの基礎となるオブジェクトに対するアクセス権限が削除されると、ユーザーはアクセスできなくなります。このように動作するのは、ユーザーがビューを問い合せるときに使用されるセキュリティ・ドメインが、そのビューの定義者のセキュリティ・ドメインであるためです。基礎となるオブジェクトに対する権限がビューの定義者によって取り消されると、そのビューは無効になり、いかなるユーザーも使用できなくなります。したがって、ビューに対するアクセス権が付与されているユーザーでも、ビューの基礎となるオブジェクトに対する定義者権限が取り消された場合は、そのビューを使用できません。

たとえば、ユーザーAがビューを作成するとします。ユーザーAは、ビューの基礎となるオブジェクトに対する定義者権限を持っています。この場合、ユーザーAがそのビューに対するSELECT権限をユーザーBに付与すると、ユーザーBがそのビューの問合せを実行できるようになります。ただし、ユーザーAがそのビューの基礎となるオブジェクトにアクセスできなくなった場合は、ユーザーBも同様にアクセスできなくなります。

ビューの場合は、次のように、表に対してさらに2つのセキュリティ・レベル(列レベルと値ベースのセキュリティ)が追加されます。

- ビューは、実表の中から選択した列へのアクセスを提供できます。たとえば、employees表の中からemployee_id列、last_name列およびmanager_id列のみを表示するようにビューを定義できます。

CREATE VIEW employees_manager AS
SELECT last_name, employee_id, manager_id FROM employees;

- ビューでは、表の情報に対して、値ベースのセキュリティを実現できます。ビュー定義でWHERE句を使用すると、実表の中から選択した行のみが表示されます。次の2つの例を考えてみます。

CREATE VIEW lowsal AS
SELECT * FROM employees
WHERE salary < 10000;

lowsalビューでは、employees表のうち給与値が10000未満のすべての行にアクセスできます。lowsalビューでは、employees表のすべての列にアクセスできることに注目してください。

CREATE VIEW own_salary AS
SELECT last_name, salary
FROM employees
WHERE last_name = USER;

own_salaryビューでは、このビューの現行ユーザーと一致するlast_nameの行のみにアクセスできます。own_salaryビューはuser疑似列を使用しており、この列の値は常に現行ユーザーを指します。このビューは、列レベルのセキュリティと値ベースのセキュリティの両方を兼ね備えています。

プロシージャに対する権限の管理

この項の内容は、次のとおりです。

- プロシージャに対するEXECUTE権限の使用

- プロシージャの実行とセキュリティ・ドメイン

- プロシージャに対する権限が定義者権限に与える影響

- プロシージャに対する権限が実行者権限に与える影響

- プロシージャの作成または置換に必要なシステム権限

- プロシージャのコンパイルに必要なシステム権限

- プロシージャに対する権限がパッケージおよびパッケージ・オブジェクトに与える影響

プロシージャに対するEXECUTE権限の使用

スタンドアロン・プロシージャ、ファクションおよびパッケージを含め、プロシージャに対するオブジェクト権限は、EXECUTE権限のみです。 この権限は、プロシージャの実行、または必要なプロシージャをコールする他のプロシージャのコンパイルが必要なユーザーにのみ付与してください。

プロシージャの実行とセキュリティ・ドメイン

特定プロシージャに対するEXECUTEオブジェクト権限があるユーザーは、そのプロシージャを実行したり、それを参照するプログラム・ユニットをコンパイルできます。PL/SQLユニットのコール時には、Oracle Databaseによって実行時権限チェックが実行されます。EXECUTE ANY PROCEDUREシステム権限があるユーザーは、データベース内の任意のプロシージャを実行できます。プロシージャの実行権限は、ロールを介してユーザーに付与できます。

関連項目:
Oracle Databaseの実行時権限チェックの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

プロシージャに対する権限が定義者権限に与える影響

定義者と呼ばれるプロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。プロシージャ所有者が別のユーザーにそのプロシージャを使用する権限を付与すると、(プロシージャで参照されるオブジェクトに対する)プロシージャ所有者の権限が、権限受領者ユーザーのプロシージャ実行に適用されます。プロシージャの定義者の権限は、ロールを介してではなく、ユーザーに直接付与する必要があります。このような権限は、定義者権限と呼ばれます。

所有者以外のプロシージャのユーザーは、実行者と呼ばれます。実行者権限プロシージャの場合は、参照オブジェクトに対する追加の権限が必要ですが、定義者権限プロシージャの場合は不要です。

関連項目:
「PL/SQLブロックでのロールの機能」

定義者権限プロシージャのユーザーに必要なのは、そのプロシージャを実行する権限のみで、そのプロシージャでアクセスする基礎となるオブジェクトに対する権限は不要です。これは、定義者権限プロシージャは、その実行者に関係なく、プロシージャを所有するユーザーのセキュリティ・ドメインの下で動作するためです。プロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。定義者権限プロシージャのユーザーに付与する権限は、できるかぎり控えめに付与してください。これによって、データベース・アクセスを厳密に制御できます。

定義者権限プロシージャを使用すると、プライベート・データベース・オブジェクトへのアクセスを制御し、データベースのセキュリティ・レベルを強化できます。定義者権限プロシージャを記述し、ユーザーにEXECUTE権限のみを付与することによって、そのプロシージャを介さない場合には、ユーザーが参照オブジェクトにアクセスできないように規定できます。

実行時には、定義者権限ストアド・プロシージャの所有者の権限によってそのプロシージャの参照オブジェクトへのアクセスが許可されているかどうかが、プロシージャの実行前にチェックされます。参照オブジェクトに対して必要な権限が、定義者権限プロシージャの所有者から取り消されていると、所有者もその他のユーザーも、プロシージャを実行できません。

注意:
トリガーの処理は、定義者権限プロシージャと同じパターンに従います。ユーザーは、実行権限があるSQL文を実行します。このSQL文の実行結果として、トリガーが起動されます。トリガーされたアクション内の文は、そのトリガーを所有するユーザーのセキュリティ・ドメインで一時的に実行されます。詳細は、『Oracle Database概要』のトリガーの概要に関する項を参照してください。

プロシージャに対する権限が実行者権限に与える影響

実行者権限プロシージャは、すべての実行者権限で実行されます。実行者の使用可能な任意のロールを介してその実行者に付与された権限は、定義者権限プロシージャによって実行者権限プロシージャが直接または間接的にコールされないかぎり有効です。実行者権限プロシージャのユーザーには、そのプロシージャが実行者のスキーマ内で解決される外部参照を介してアクセスする、オブジェクトに対する権限(直接またはロールを介して付与されたもの)が必要です。

実行者には、DML文または動的SQL文に埋め込まれているプログラム参照にアクセスする権限が実行時に必要です。これは、この種のプログラム参照は実質的に実行時に再コンパイルされるためです。

PL/SQLファンクションの直接コールなど、他のすべての外部参照の場合、所有者権限はコンパイル時にチェックされ、実行時にはチェックされません。したがって、実行者権限プロシージャのユーザーには、DML文や動的SQL文の外側にある外部参照に対する権限は不要です。また、実行者権限プロシージャの開発者による権限の付与が必要なのは、プロシージャ自体に対する権限付与のみで、その実行者権限プロシージャによって直接参照されるすべてのオブジェクトに対する権限付与は必要ありません。

複数のプログラム・ユニットからなり、そのうちのいくつかは定義者権限、その他は実行者権限とするソフトウェア・バンドルを作成して、プログラム・エントリ・ポイントを制限できます(制御されたステップイン)。エントリ・ポイント・プロシージャの実行権限があるユーザーは、内部プログラム・ユニットも間接的に実行できますが、内部プログラムを直接コールすることはできません。問合せ処理を厳密に制御するには、PL/SQLパッケージ仕様を明示的なカーソルを使用して作成できます。

関連項目:

- 「Oracle Virtual Private Databaseポリシーの構成」

- Oracle Databaseで名前の解決を処理する方法と、実行者権限および定義者権限を使用して実行時の権限チェックを処理する方法の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- CREATE PACKAGE文で明示的なカーソルを定義する方法の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

プロシージャの作成または置換に必要なシステム権限

自分のスキーマ内でプロシージャを作成または置換するには、CREATE PROCEDUREシステム権限が必要です。別のユーザーのスキーマ内でプロシージャを作成または置換するには、CREATE ANY PROCEDUREシステム権限が必要です。

プロシージャを所有するユーザーには、プロシージャ本体で参照されるスキーマ・オブジェクトに対する権限も必要です。プロシージャを作成するには、そのプロシージャによって参照されるすべてのオブジェクトに対する必要な権限(システム権限やオブジェクト権限)が明示的に付与されている必要があります。これらの必要な権限は、ロールを介して取得することはできません。これには、作成中のプロシージャ内でコールするプロシージャに対するEXECUTE権限も含まれます。

注意:
トリガーの場合、参照オブジェクトに対する権限をトリガーの所有者に直接付与する必要があります。権限が明示的に、またはロールを介して付与されていても、無名PL/SQLブロックでは任意の権限を使用できます。

プロシージャのコンパイルに必要なシステム権限

スタンドアロン・プロシージャをコンパイルするには、COMPILE句を使用してALTER PROCEDURE文を実行します。パッケージの一部であるプロシージャをコンパイルするには、ALTER PACKAGE文を実行します。

例4-9に、スタンドアロン・プロシージャをコンパイルする方法を示します。

例4-9 プロシージャのコンパイル

ALTER PROCEDURE psmith.remove_emp COMPILE;

スタンドアロン・プロシージャまたはパッケージ・プロシージャが別のユーザーのスキーマ内にある場合、プロシージャを再コンパイルするにはALTER ANY PROCEDURE権限が必要です。自分のスキーマ内にあるプロシージャは、権限なしで再コンパイルできます。

プロシージャに対する権限がパッケージおよびパッケージ・オブジェクトに与える影響

パッケージに対するEXECUTEオブジェクト権限を保持するユーザーは、そのパッケージ内の任意のパブリック・プロシージャまたはファンクションを実行し、任意のパブリック・パッケージ変数の値へのアクセスや変更を実行できます。パッケージの各構成メンバーに、特定のEXECUTE権限を付与することはできません。したがって、データベース・アプリケーションのプロシージャ、ファンクションおよびパッケージを開発する場合は、セキュリティの確立に関して2つの選択肢を考慮してください。これらの選択肢について、次の例で説明します。

プロシージャに対する権限およびパッケージとパッケージ・オブジェクト: 例1

例4-10では、2つのパッケージの本体に4つのプロシージャを作成しています。

例4-10 プロシージャに対する権限の影響を受けるパッケージ・オブジェクト

CREATE PACKAGE BODY hire_fire AS
PROCEDURE hire(...) IS
BEGIN
INSERT INTO employees . . .
END hire;
PROCEDURE fire(...) IS
BEGIN
DELETE FROM employees . . .
END fire;
END hire_fire;

CREATE PACKAGE BODY raise_bonus AS
PROCEDURE give_raise(...) IS
BEGIN
UPDATE employees SET salary = . . .
END give_raise;
PROCEDURE give_bonus(...) IS
BEGIN
UPDATE employees SET bonus = . . .
END give_bonus;
END raise_bonus;

次のGRANT EXECUTE文を発行すると、big_bossesロールとlittle_bossesロールが適切なプロシージャを実行できるようになります。

GRANT EXECUTE ON hire_fire TO big_bosses;
GRANT EXECUTE ON raise_bonus TO little_bosses;

注意:
EXECUTE権限をパッケージに対して付与することで、すべてのパッケージ・オブジェクトへの均一なアクセスが提供されます。

プロシージャに対する権限およびパッケージとパッケージ・オブジェクト: 例2

この例は、単一のパッケージ本体にある4つのプロシージャ定義を示しています。2つの追加スタンドアロン・プロシージャと1つのパッケージが特別に作成され、メイン・パッケージ内に定義されているプロシージャへのアクセスを提供します。

CREATE PACKAGE BODY employee_changes AS
PROCEDURE change_salary(...) IS BEGIN ... END;
PROCEDURE change_bonus(...) IS BEGIN ... END;
PROCEDURE insert_employee(...) IS BEGIN ... END;
PROCEDURE delete_employee(...) IS BEGIN ... END;
END employee_changes;

CREATE PROCEDURE hire
BEGIN
employee_changes.insert_employee(...)
END hire;

CREATE PROCEDURE fire
BEGIN
employee_changes.delete_employee(...)
END fire;

PACKAGE raise_bonus IS
PROCEDURE give_raise(...) AS
BEGIN
employee_changes.change_salary(...)
END give_raise;

PROCEDURE give_bonus(...)
BEGIN
employee_changes.change_bonus(...)
END give_bonus;

この方法を使用すると、実際に作業を実行するプロシージャ(employee_changesパッケージ内のプロシージャ)が1つのパッケージ内に定義され、宣言されたグローバル変数やカーソルなどを共有できます。トップ・レベルのプロシージャであるhireとfire、および追加のパッケージraise_bonusを宣言することによって、選択的なEXECUTE権限をメイン・パッケージ内のプロシージャに対して付与できます。

GRANT EXECUTE ON hire, fire TO big_bosses;
GRANT EXECUTE ON raise_bonus TO little_bosses;

型に対する権限の管理

次の各項では、型、メソッドおよびオブジェクトに対する権限の使用について説明します。

- 名前付きの型に対するシステム権限

- オブジェクト権限

- メソッド実行モデル

- 型の作成と型を使用した表の作成に必要な権限

- 型の作成と型を使用した表の作成に必要な権限の例

- 型アクセスとオブジェクト・アクセスの権限

- 型の依存性

名前付きの型に対するシステム権限

表4-4に、名前付きの型(オブジェクト型、VARRAYおよびネストした表)に対するシステム権限のリストを示します。

表4-4 名前付きの型に対するシステム権限

権限

許可される操作

CREATE TYPE

名前付きの型を自分のスキーマ内に作成できます。

CREATE ANY TYPE

名前付きの型を任意のスキーマ内に作成できます。

ALTER ANY TYPE

任意のスキーマにある名前付きの型を変更できます。

DROP ANY TYPE

任意のスキーマにある名前付きの型を削除できます。

EXECUTE ANY TYPE

任意のスキーマにある名前付きの型を使用および参照できます。

RESOURCEロールには、CREATE TYPEシステム権限が含まれています。DBAロールには、これらの権限すべてが含まれています。

オブジェクト権限

名前付きの型に適用されるオブジェクト権限は、EXECUTEのみです。名前付きの型に対するEXECUTE権限があるユーザーは、その型を使用して次の操作を実行できます。

- 表の定義

- リレーショナル表への列の定義

- 名前付きの型の変数またはパラメータの宣言

EXECUTE権限によって、ユーザーは、型コンストラクタも含めて、その型のメソッドを起動できます。これは、ストアドPL/SQLプロシージャに対するEXECUTE権限と同じです。

メソッド実行モデル

メソッドの実行は、他のストアドPL/SQLプロシージャと同じです。

関連項目:
「プロシージャに対する権限の管理」

型の作成と型を使用した表の作成に必要な権限

型を作成するには、次の要件を満たす必要があります。

- 自分のスキーマにタイプを作成するにはCREATE TYPEシステム権限が必要になり、他のユーザーのスキーマにタイプを作成するにはCREATE ANY TYPEシステム権限が必要になります。これらの権限は、明示的にまたはロールを介して取得できます。

- 型の所有者には、その型の定義内で参照されている他のすべての型にアクセスするためのEXECUTEオブジェクト権限が明示的に付与されているか、EXECUTE ANY TYPEシステム権限が付与されている必要があります。所有者は、ロールを介して必要な権限を取得することはできません。

- 型の所有者が型へのアクセス権を他のユーザーに付与する場合、その所有者には、参照される型に対するEXECUTE権限(GRANT OPTION付きで指定)またはEXECUTE ANY TYPEシステム権限(ADMIN OPTION付きで指定)が必要です。どちらの権限もない型の所有者は、権限不足のため、型へのアクセス権を他のユーザーに付与できません。

型を使用して表を作成するには、表の作成要件と次の要件を満たす必要があります。

- 表の所有者には、その表で参照されているすべての型にアクセスするためのEXECUTEオブジェクト権限が直接付与されているか、EXECUTE ANY TYPEシステム権限が付与されている必要があります。これらの権限がロールを介して付与されている場合、所有者は必要な権限を行使できません。

- 表の所有者が表へのアクセス権を他のユーザーに付与する場合、その所有者には、参照される型に対するEXECUTE権限(GRANT OPTION付きで指定)またはEXECUTE ANY TYPEシステム権限(ADMIN OPTION付きで指定)が必要です。どちらの権限もない表の所有者は、権限不足のため、表へのアクセス権を付与できません。

関連項目:
表の作成要件については、「表に対する権限の管理」を参照してください。

型の作成と型を使用した表の作成に必要な権限の例

CONNECTロールとRESOURCEロールを持つ次の3名のユーザーが存在するとします。

- user1

- user2

- user3

次のDDLは、user1のスキーマで実行されます。

CREATE TYPE type1 AS OBJECT (
attr1 NUMBER);

CREATE TYPE type2 AS OBJECT (
attr2 NUMBER);

GRANT EXECUTE ON type1 TO user2;
GRANT EXECUTE ON type2 TO user2 WITH GRANT OPTION;

次のDDLは、user2のスキーマで実行されます。

CREATE TABLE tab1 OF user1.type1;
CREATE TYPE type3 AS OBJECT (
attr3 user1.type2);
CREATE TABLE tab2 (
col1 user1.type2);

次の文は、正常に実行されます。user2には、user1.type2に対するGRANT OPTION付きのEXECUTE権限があるためです。

GRANT EXECUTE ON type3 TO user3;
GRANT SELECT on tab2 TO user3;

ただし、次の権限付与は正しく実行されません。user2には、user1.type1に対するGRANT OPTION付きのEXECUTE権限がないためです。

GRANT SELECT ON tab1 TO user3;

次の文は、user3によって正常に実行されます。

CREATE TYPE type4 AS OBJECT (
attr4 user2.type3);
CREATE TABLE tab3 OF type4;

注意:
顧客はCONNECTおよびRESOURCEロールの使用を中断する必要があります。CONNECTロールが現在保持している権限は、CREATE SESSIONのみです。

型アクセスとオブジェクト・アクセスの権限

DML文に対する列レベルと表レベルの既存の権限は、列オブジェクトと行オブジェクトの両方に適用されます。

表4-5に、オブジェクト表に対する権限をリストします。

表4-5 オブジェクト表に対する権限

権限

許可される操作

SELECT

オブジェクトとその属性に表からアクセスできます。

UPDATE

表の行を構成するオブジェクトの属性を変更できます。

INSERT

表に新規オブジェクトを作成できます。

DELETE

行を削除できます。

同様に、列オブジェクトには表に対する権限と列に対する権限が適用されます。インスタンスの取得のみでは、型情報は明らかになりません。ただし、クライアントは、型インスタンスのイメージを解釈する際に名前付きの型の情報にアクセスする必要があります。クライアントが型情報を要求すると、その型に対するEXECUTE権限がチェックされます。

次のスキーマを考えてみます。

CREATE TYPE emp_type (
eno NUMBER, ename CHAR(31), eaddr addr_t);
CREATE TABLE emp OF emp_t;

さらに、次の2つの問合せについて考えます。

SELECT VALUE(emp) FROM emp;
SELECT eno, ename FROM emp;

どちらの問合せの場合も、Oracle Databaseは、emp表に対するユーザーのSELECT権限をチェックします。最初の問合せの場合、ユーザーは、emp_typeの型情報を取得してデータを解釈する必要があります。問合せによってemp_type型がアクセスされると、ユーザーのEXECUTE権限がチェックされます。

ただし、2番目の問合せでは、名前付きの型が含まれていないため、型の権限はチェックされません。

さらに、user3は、前の項のスキーマを使用して次の問合せを実行できます。

SELECT tab1.col1.attr2 FROM user2.tab1 tab1;
SELECT attr4.attr3.attr2 FROM tab3;

どちらのSELECT文でも、user3には基礎となる型に対する明示的な権限がありませんが、文には成功することに注意してください。これは、型の所有者と表の所有者に、GRANT OPTIONを備えた必要な権限があるためです。

Oracle Databaseは、次のイベントに対する権限をチェックし、アクションに対する権限がクライアントにない場合はエラーを戻します。

- オブジェクトのREF値を使用してオブジェクト・キャッシュ内でオブジェクトを確保すると、Oracle Databaseは、そのオブジェクトが含まれているオブジェクト表に対するSELECT権限をチェックします。

- 既存のオブジェクトを修正したり、オブジェクト・キャッシュからオブジェクトをフラッシュしたりすると、Oracle Databaseは目的のオブジェクト表に対するUPDATE権限をチェックします。

- 新しいオブジェクトをフラッシュすると、Oracle Databaseは目的のオブジェクト表に対するINSERT権限をチェックします。

- オブジェクトを削除すると、Oracle Databaseは目的の表に対するDELETE権限をチェックします。

- 名前付きの型のオブジェクトを確保すると、そのオブジェクトに対するEXECUTE権限がチェックされます。

クライアントの第三世代言語アプリケーションのオブジェクトの属性を変更すると、Oracle Databaseでオブジェクト全体の更新が行われます。そのため、ユーザーにはオブジェクト表に対するUPDATE権限が必要になります。オブジェクト表の特定列に対してのみUPDATE権限を持つことは、アプリケーションがこれらの列に対応した属性のみ変更する場合でも、十分とはいえません。そのため、Oracle Databaseではオブジェクト表の列レベルの権限をサポートしていません。

型の依存性

プロシージャや表などのストアド・オブジェクトと同様に、他のオブジェクトから参照される型を依存性があると呼びます。表が依存する型については、特殊な問題点がいくつかあります。表には、アクセス用の型定義に依存するデータが含まれているため、その型を変更すると、格納されているすべてのデータにアクセスできなくなります。変更によってこのような結果になるのは、型を使用するために必要な権限が取り消された場合や、型または依存型が削除された場合です。いずれかのアクションが発生すると、表は無効になり、アクセスできなくなります。

必要な権限が再び付与されると、権限がないために無効になった表は自動的に有効になり、アクセスできるようになります。依存型が削除されたことで無効になった表は、アクセス不能のままで、実行できるアクションは表の削除のみです。

型に対する権限の取消しや型の削除は重大な影響があるため、デフォルトでは、SQL文のREVOKEとDROP TYPEは限定されたセマンティクスで実装されます。つまり、どちらの文でも、名前付きの型が表または型に依存している場合は、エラーが戻されて文は取り消されます。ただし、どちらの文も、FORCE句を使用すると常に正常終了します。依存する表がある場合、その表は無効になります。

関連項目:
REVOKE、DROP TYPEおよびFORCE句の使用方法の詳細は、『Oracle Databaseリファレンス』を参照してください。

ユーザー権限とロールの付与

この項の内容は、次のとおりです。

- システム権限とロールの付与

- オブジェクト権限の付与

- 列に対する権限の付与

ロールは、中間層またはプロキシを介して接続したユーザーにも付与できます。この操作については、「中間層サーバーを使用したプロキシ認証」を参照してください。

システム権限とロールの付与

システム権限とロールを他のユーザーやロールに付与するには、GRANT SQL文を使用します。次の権限が必要です。

- システム権限を付与するには、ユーザーにADMINオプション付きのシステム権限またはGRANT ANY PRIVILEGEシステム権限が付与されている必要があります。

- ロールを付与するには、ユーザーにADMINオプション付きのロールまたはGRANT ANY ROLEシステム権限が付与されている必要があります。

例4-11では、システム権限CREATE SESSIONとaccts_payロールをユーザーjwardに付与しています。

例4-11 ユーザーへのシステム権限とロールの付与

GRANT CREATE SESSION, accts_pay TO jward;

例4-11 では、exec_dirディレクトリ・オブジェクトに対するEXECUTE権限をユーザーjwardに付与しています。

例4-12 ディレクトリ・オブジェクトに対するEXECUTE権限の付与

GRANT EXECUTE ON DIRECTORY exec_dir TO jward;

注意:
オブジェクト権限は、同じGRANT文でシステム権限やロールと同時に付与することはできません。

ADMINオプションの付与

ユーザーまたはロールに権限またはロールを付与するときにWITH ADMIN OPTION句を指定すると、権限受領者は、次の拡張機能を使用できるようになります。

- 権限受領者は、データベース内の他のユーザーまたはロールに対して、システム権限またはロールの付与または取消しができます。ただし、自分自身からロールを取り消すことはできません。

- 権限受領者は、ADMINオプション付きのシステム権限やロールを付与できます。

- ロールの権限受領者は、そのロールを変更または削除できます。

例4-13では、new_dbaロールをWITH ADMIN OPTION句付きでユーザーmichaelに付与しています。

例4-13 ADMINオプションの付与

GRANT new_dba TO michael WITH ADMIN OPTION;

ユーザーmichaelは、new_dbaロール内の権限をすべて暗黙的に使用できることに加え、必要に応じてnew_dbaロールを付与、取消しおよび削除できます。このように、ADMINオプションは非常に強力な機能であるため、このオプションを付けてシステム権限やロールを付与する際は、十分に注意してください。通常、これらの権限はセキュリティ管理者向けに用意されており、システム内の他の管理者やユーザーに付与することはほとんどありません。

注意:
ユーザーがロールを作成すると、そのロールは自動的にADMINオプション付きでその作成ユーザーに付与されます。

GRANT文を使用した新規ユーザーの作成

Oracle Databaseでは、GRANT文を使用して新しいユーザーを作成できます。IDENTIFIED BY句を使用してパスワードを指定することで、ユーザー名がデータベースに存在しない場合も、指定したユーザー名とパスワードで新しいユーザーが作成されます。

例4-14では、新規ユーザーとしてpsmithを作成し、CREATE SESSIONシステム権限をpsmithに付与しています。

例4-14 GRANT文を使用した新規ユーザーの作成

GRANT CREATE SESSION TO psmith IDENTIFIED BY password;

関連項目:

- 「ユーザー・アカウントの作成」

- 「パスワードの最低要件」

オブジェクト権限の付与

GRANT文を使用すると、ロールとユーザーにオブジェクト権限を付与できます。オブジェクト権限を付与するには、次のいずれかの条件を満たしている必要があります。

- 指定するオブジェクトを所有している。

- GRANT ANY OBJECT PRIVILEGEシステム権限を付与されている。この権限を使用すると、オブジェクト所有者のかわりに権限の付与と取消しを実行できます。

- オブジェクト権限が付与されるときに、WITH GRANT OPTION句が指定されている。

注意:
同じGRANT文で、オブジェクト権限とともにシステム権限とロールを付与することはできません。

例4-15では、emp表のすべての列に対するSELECT、INSERTおよびDELETEのオブジェクト権限をユーザーjfeeとtsmithに付与しています。

例4-15 ユーザーへのオブジェクト権限の付与

GRANT SELECT, INSERT, DELETE ON emp TO jfee, tsmith;

salaryビューのすべてのオブジェクト権限をユーザーjfeeに付与するには、次の例のようにALLキーワードを使用します。

GRANT ALL ON salary TO jfee;

注意:
権限受領者は、最初の権限付与にGRANT OPTIONが含まれていないかぎり、オブジェクトへのアクセス権を再度付与することはできません。したがって、前述の例では、jfeeはGRANT文を使用してオブジェクト権限を他の誰かに付与することができません。

GRANT OPTION句の指定

GRANT文にWITH GRANT OPTION句を指定すると、権限受領者はオブジェクト権限を他のユーザーに付与できるようになります。スキーマ内にオブジェクトを格納しているユーザーには、関連するすべてのオブジェクト権限がGRANT OPTION付きで自動的に付与されます。この特別な権限によって、権限受領者の権限は次のように拡張されます。

- 権限受領者は、データベース内の任意のユーザーにGRANT OPTIONの有無を問わずオブジェクト権限を付与でき、そしてデータベース内の任意のロールに付与できます。

- 次の2つの条件が成立する場合、権限受領者は表に対するビューを作成し、そのビューの対応する権限をデータベース内の任意のユーザーまたはロールに対して付与できます。

- 権限受領者が、表に対するGRANT OPTION付きのオブジェクト権限を受領している。

- 権限受領者に、CREATE VIEWまたはCREATE ANY VIEWシステム権限がある。

注意:
オブジェクト権限をロールに付与する場合、GRANT OPTIONは無効です。Oracle Databaseでは、ロールによるオブジェクト権限の伝播を禁止しているため、ロールの権限受領者は、ロールを介して受領したオブジェクト権限を他に伝播することはできません。

オブジェクト所有者にかわるオブジェクト権限の付与

GRANT ANY OBJECT PRIVILEGEシステム権限を持つユーザーは、オブジェクト所有者のかわりに、すべてのオブジェクト権限の付与と取消しを実行できます。この権限によって、データベース管理者やアプリケーション管理者は、スキーマに接続せずにスキーマ内のオブジェクトへのアクセス権を付与できます。この権限を持つスキーマ所有者のログイン資格証明はメンテナンスする必要がなく、構成時に必要な接続数が減少します。

このシステム権限はOracle Databaseに用意されているDBAロールに付属しているため、AS SYSDBAで接続するユーザー(ユーザーSYS)に(ADMIN option付きで)付与されます。他のシステム権限と同様に、GRANT ANY OBJECT PRIVILEGEシステム権限を付与できるのは、ADMIN option権限を持っているユーザーのみです。

オブジェクトに対するアクセス権の記録された権限付与者は、オブジェクト所有者とGRANT ANY OBJECT PRIVILEGEシステム権限を行使している個人のどちらかです。GRANT ANY OBJECT PRIVILEGEを持つ権限付与者がGRANT OPTION付きのオブジェクト権限を持っていない場合、オブジェクト所有者が権限付与者として表示されます。権限付与者がGRANT OPTION付きのオブジェクト権限を持っている場合は、その権限付与者が付与者として記録されます。

注意:
GRANT文によって生成された監査レコードには、常に権限付与を実際に実行したユーザーが示されます。

たとえば、次の使用例を考えてみます。ユーザーadamsにGRANT ANY OBJECT PRIVILEGEシステム権限があります。他の付与権限は所持していないとします。このユーザーが次の文を発行します。

GRANT SELECT ON HR.EMPLOYEES TO blake WITH GRANT OPTION;

DBA_TAB_PRIVSビューを調べると、hrが権限付与者として表示されていることがわかります。

SELECT GRANTEE, GRANTOR, PRIVILEGE, GRANTABLE
FROM DBA_TAB_PRIVS
WHERE TABLE_NAME = 'EMPLOYEES' and OWNER = 'HR';

GRANTEE  GRANTOR PRIVILEGE    GRANTABLE
-------- ------- -----------  ----------
BLAKE    HR       SELECT      YES

ここで、ユーザーblakeにもGRANT ANY OBJECT PRIVILEGEシステム権限があると想定します。このユーザーが次の文を発行します。

GRANT SELECT ON HR.EMPLOYEES TO clark;

この場合は、DBA_TAB_PRIVSビューを再び問い合せると、blakeが権限付与者として表示されます。

GRANTEE  GRANTOR  PRIVILEGE  GRANTABLE
-------- -------- ---------  ----------
BLAKE    HR       SELECT     YES
CLARK    BLAKE    SELECT     NO

これは、blakeがすでにHR.EMPLOYEESに対してGRANT OPTION付きのSELECT権限を持っているためです。

関連項目:
「オブジェクト所有者にかわるオブジェクト権限の取消し」

列に対する権限の付与

表の個々の列に対してINSERT、UPDATEまたはREFERENCES権限を付与できます。

注意:
列固有のINSERT権限を付与する前に、NOT NULL制約が定義されている列が表に含まれているかどうかを確認してください。挿入できる列を選んで権限を付与したときにNOT NULL列が抜けていると、ユーザーは表に行を挿入できません。このような状況を回避するには、各NOT NULL列が挿入可能であること、またはNULL以外のデフォルト値があることを確認してください。そうでない場合、権限受領者は表に行を挿入できず、エラーが発生します。

次の文は、accounts表のacct_no列に対するINSERT権限をpsmithに付与しています。

GRANT INSERT (acct_no) ON accounts TO psmith;

次の例では、emp表のenameおよびjob列に対するオブジェクト権限が、ユーザーjfeeおよびtsmithに付与されます。

GRANT INSERT(ename, job) ON emp TO jfee, tsmith;

行レベルのアクセス制御

行レベルで、つまりオブジェクト内でアクセスを制御することもできます。これには、仮想プライベート・データベース(VPD)またはOracle Label Security(OLS)を使用します。

関連項目:

- 第7章「Oracle Virtual Private Databaseを使用したデータ・アクセスの制御」

- 「列レベルのOracle Virtual Private Databaseポリシーの追加」

- 『Oracle Label Security管理者ガイド』

ユーザー権限とロールの取消し

この項の内容は、次のとおりです。

- システム権限とロールの取消し

- オブジェクト権限の取消し

- 権限の取消しによる連鎖的な影響

システム権限とロールの取消し

システム権限およびロールを取り消すには、SQL文REVOKEを使用します。 ADMINオプション付きでシステム権限またはロールを付与されているユーザーは、他のデータベース・ユーザーまたはロールから権限またはロールを取り消すことができます。取消しを行うユーザーは、権限やロールを最初に付与したユーザーでなくてもかまいません。GRANT ANY ROLEがあるユーザーは、任意のロールを取り消すことができます。

次の文は、psmithからCREATE TABLEシステム権限とaccts_recロールを取り消します。

REVOKE CREATE TABLE, accts_rec FROM psmith;

注意:
システム権限またはロールのADMINオプションを選択的に取り消すことはできません。権限またはロールを取り消してから、同じ権限またはロールをADMINオプションを指定せずに再度付与する必要があります。

オブジェクト権限の取消し

オブジェクト権限を取り消すには、次のどちらかの条件を満たしている必要があります。

- 以前にユーザーまたはロールにオブジェクト権限を付与している。

- オブジェクト所有者のかわりに権限を付与したり取り消すことができるGRANT ANY OBJECT PRIVILEGEシステム権限を所持している。

取り消すことができるのは、権限付与者として自身で直接認可した権限のみです。GRANT OPTIONを付与した他のユーザーによる権限付与を取り消すことはできません。ただし、連鎖的な影響があります。権限付与者のオブジェクト権限を取り消すと、GRANT OPTIONを使用して伝播されたオブジェクト権限も取り消されます。

最初の権限付与者が次の文を発行すると、ユーザーjfeeとpsmithからemp表のSELECT権限とINSERT権限が取り消されます。

REVOKE SELECT, INSERT ON emp FROM jfee, psmith;

次の文は、最初にhuman_resourceロールに付与したdept表に対するすべてのオブジェクト権限を取り消します。

REVOKE ALL ON dept FROM human_resources;

注意:
オブジェクト権限のGRANT OPTIONを選択的に取り消すことはできません。オブジェクト権限を取り消してから、同じ権限をGRANT OPTIONを指定せずに再度付与する必要があります。ユーザーが自分自身からオブジェクト権限を取り消すことはできません。

オブジェクト所有者にかわるオブジェクト権限の取消し

GRANT ANY OBJECT PRIVILEGEシステム権限を使用すると、オブジェクト所有者が権限付与者である指定のオブジェクト権限を取り消すことができます。この操作を実行できるのは、オブジェクト所有者によって、または所有者のかわりにGRANT ANY OBJECT PRIVILEGEシステム権限を持つユーザーによって、オブジェクト権限が付与されている場合です。

オブジェクト権限が、オブジェクト所有者とREVOKE文を実行するユーザー(特定のオブジェクト権限とGRANT ANY OBJECT PRIVILEGEシステム権限の両方を持つユーザー)の両方によって付与されている場合は、REVOKE文を発行したユーザーによって付与されたオブジェクト権限のみが取り消されます。この使用例については、「オブジェクト所有者にかわるオブジェクト権限の付与」の例を使用して説明します。

ここでは、blakeがHR.EMPLOYEESに対するSELECT権限をclarkに付与しているとします。blakeはGRANT ANY OBJECT PRIVILEGEシステム権限を所有していますが、特定のオブジェクト権限も保有しているため、この付与はblakeに起因します。ここでは、ユーザーHRもHR.EMPLOYEESに対するSELECT権限をユーザーclarkに付与しているとします。DBA_TAB_PRIVSビューの問合せでは、HR.EMPLOYEES表について次の権限付与が有効であることが表示されています。

GRANTEE  GRANTOR PRIVILEGE    GRANTABLE
-------- ------- -----------  ----------
BLAKE    HR       SELECT       YES
CLARK    BLAKE    SELECT       NO
CLARK    HR       SELECT       NO

ユーザーblakeが次のREVOKE文を発行します。

REVOKE  SELECT ON HR.EMPLOYEES FROM clark;

ユーザーblakeがユーザーclarkに付与したオブジェクト権限のみが削除されます。オブジェクト所有者HRによる権限付与はそのまま残ります。

GRANTEE  GRANTOR PRIVILEGE    GRANTABLE
-------- ------- -----------  ----------
BLAKE    HR       SELECT      YES
CLARK    HR       SELECT      NO

blakeが再度REVOKE文を発行すると、今度は(HRのかわりに)adamsがGRANT ANY OBEJCT PRIVILEGEシステム権限を使用して付与したオブジェクト権限が削除されます。

関連項目:
「オブジェクト所有者にかわるオブジェクト権限の付与」

列を選択するオブジェクト権限の取消し

表やビューの列を指定してINSERT、UPDATEおよびREFERENCES権限を付与することは可能ですが、同じようなREVOKE文を使用して、列固有の権限を選択的に取り消すことはできません。かわりに、権限付与者は表またはビューの全列に対するオブジェクト権限を取り消してから、残しておく列固有の権限を選択的に再度付与する必要があります。

たとえば、human_resourcesロールには、dept表のdeptno列およびdname列に対するUPDATE権限が付与されているとします。このUPDATE権限をdeptno列のみから取り消すには、次の2つの文を発行します。

REVOKE UPDATE ON dept FROM human_resources;
GRANT UPDATE (dname) ON dept TO human_resources;

このREVOKE文によって、ロールhuman_resourcesからdept表の全列に対するUPDATE権限が取り消されます。次にGRANT文によって、human_resourcesロールに対して、dname列のUPDATE権限の付与がやりなおし、リストアまたは再発行されます。

REFERENCESオブジェクト権限の取消し

REFERENCESオブジェクト権限の権限受領者がその権限を使用して外部キー制約を作成し、その制約が現在も存在している場合、権限付与者がその権限を取り消すには、REVOKE文に必ずCASCADE CONSTRAINTSオプションを指定する必要があります。

REVOKE REFERENCES ON dept FROM jward CASCADE CONSTRAINTS;

CASCADE CONSTRAINTS句を指定すると、取り消されるREFERENCES権限を使用して現在も定義されている外部キー制約が削除されます。

権限の取消しによる連鎖的な影響

権限のタイプによっては、権限の取消しによって連鎖的な影響が発生する場合があります。次の各項で、これについて説明します。

- システム権限の取消しによる連鎖的な影響

- オブジェクト権限の取消しによる連鎖的な影響

システム権限の取消しによる連鎖的な影響

DDL操作に関連するシステム権限を取り消すときには、この権限がADMINオプション付きで付与されたか無しで付与されたかに関係なく、連鎖的な影響はありません。たとえば、次のような場合を考えてみます。

1. セキュリティ管理者が、ADMIN optionを指定して、ユーザーjfeeにCREATE TABLEシステム権限を付与します。

2. ユーザーjfeeが表を作成します。

3. ユーザーjfeeが、ユーザーtsmithにCREATE TABLEシステム権限を付与します。

4. ユーザーtsmithが表を作成します。

5. セキュリティ管理者が、ユーザーjfeeからCREATE TABLEシステム権限を取り消します。

6. ユーザーjfeeが作成した表はそのまま残ります。ユーザーtsmithの表とCREATE TABLEシステム権限はそのまま残ります。

連鎖的な影響は、DML操作に関連するシステム権限を取り消したときに発生する場合があります。ユーザーのSELECT ANY TABLE権限を取り消すと、そのユーザーのスキーマ内に存在し、この権限に依存しているすべてのプロシージャは、権限が再度認可されないかぎり、正常に実行できなくなります。

オブジェクト権限の取消しによる連鎖的な影響

オブジェクト権限を取り消すと、連鎖的な影響が発生する場合があります。次のことに注意してください。

- DMLオブジェクト権限を取り消すと、そのDMLオブジェクト権限に依存するオブジェクト定義にまで影響が及ぶ可能性があります。たとえば、testプロシージャの本体に、emp表のデータを問い合せるSQL文が記述されているとします。testプロシージャの所有者からemp表のSELECT権限を取り消すと、それ以降そのプロシージャを正常に実行できなくなります。

- 表に対するREFERENCES権限をユーザーから取り消すと、そのユーザーが定義した外部キー整合性制約の中で、取り消されたREFERENCES権限を必要とする制約が自動的に削除されます。たとえば、ユーザーjwardにdept表のdeptno列に対するREFERENCES権限が付与されているとします。このユーザーが、emp表のdeptno列に、dept表のdeptno列を参照する外部キーを作成します。dept表のdeptno列に対するREFERENCES権限を取り消すと、同じ操作でemp表のdeptno列に対する外部キー制約も削除されます。

- GRANT OPTIONを使用して伝播されたオブジェクト権限付与は、権限付与者のオブジェクト権限が取り消されると取り消されます。たとえば、GRANT OPTION付きのemp表に対するSELECTオブジェクト権限を付与されているuser1が、user2に対してemp表に対するSELECT権限を付与したとします。その後、user1からSELECT権限を取り消します。このREVOKE文はuser2にも連鎖します。user1とuser2の取り消されたSELECT権限に依存するオブジェクトもすべて、前述のように影響を受ける可能性があります。

ALTERまたはINDEXオブジェクト権限を取り消しても、ALTERおよびINDEX DDLの各オブジェクト権限を必要とするオブジェクト定義には影響を与えません。たとえば、別のユーザーに属する表に索引を作成したユーザーからINDEX権限を取り消しても、その索引はそのまま残ります。

PUBLICロールに対する付与と取消し

ロールPUBLICに対して、権限とロールの付与および取消しを実行できます。PUBLICにはすべてのデータベース・ユーザーがアクセスできるため、PUBLICに対して付与されたすべての権限またはロールには、すべてのデータベース・ユーザーがアクセスできます。

セキュリティ管理者とデータベース・ユーザーは、すべてのデータベース・ユーザーが権限またはロールを必要としている場合のみ、PUBLICに権限またはロールを付与してください。これによって、各データベース・ユーザーには常に、現在のグループ・タスクの正常実行に必要な権限のみが付与されているという一般規則が保証されます。

PUBLICから権限を取り消すと、かなりの規模で影響が連鎖する可能性があります。DML操作に関連する任意の権限をPUBLICから取り消すと(たとえばSELECT ANY TABLEまたはUPDATE ON emp)、データベース内のファンクションとパッケージを含むすべてのプロシージャが再認可されるまで再び使用できなくなります。したがって、DMLに関連する権限をPUBLICに付与したり、取り消す場合には注意が必要です。

関連項目:

- オブジェクト依存性の詳細は、『Oracle Database管理者ガイド』のオブジェクト依存性の管理に関する項を参照してください。

- 「データの保護に関するガイドライン」

オペレーティング・システムまたはネットワークを使用したロールの付与

この項の内容は、次のとおりです。

- オペレーティング・システムまたはネットワークを使用したロールの付与の概要

- オペレーティング・システムのロール識別機能の使用

- オペレーティング・システムのロール管理機能の使用

- OS_ROLESがTRUEに設定されている場合のロールの付与と取消し

- OS_ROLESがTRUEに設定されている場合のロールの有効化と無効化

- オペレーティング・システムによるロール管理使用時のネットワーク接続の使用

オペレーティング・システムまたはネットワークを使用したロールの付与の概要

セキュリティ管理者がGRANT文とREVOKE文を使用して、ユーザーに対し明示的にデータベース・ロールを付与または取り消すかわりに、Oracle Databaseが稼働しているオペレーティング・システムによって、接続時にユーザーにロールを付与できます。つまり、オペレーティング・システムを使用してロールを管理し、ユーザーのセッション作成時にOracle Databaseにそのロールを渡すことができます。このメカニズムの一部として、ユーザーのデフォルト・ロールや、ADMINオプション付きでユーザーに付与するロールを識別できます。オペレーティング・システムを使用してロールを使用するユーザーを認可する場合は、必ずすべてのロールをデータベース内に作成し、GRANT文を使用してそのロールに権限を割り当てる必要があります。

ロールは、ネットワーク・サービスを介しても付与できます。

ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の利点は、Oracleデータベースの権限管理をデータベースの外部で実施できることです。オペレーティング・システムに組み込まれたセキュリティ機能によって、ユーザーの権限が制御されます。また、このオプションを使用すると、いくつかのシステム・アクティビティのセキュリティを集中管理できるため、次のような状況で役立ちます。

- MVS版Oracleの管理者が、データベース・ユーザーのロールを識別するためにRACFグループを使用する場合

- UNIX版Oracleの管理者が、データベース・ユーザーのロールを識別するためにUNIXグループを使用する場合

- VMS版Oracleの管理者が、データベース・ユーザーのロールを識別するために権限識別子を使用する場合

ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の主なデメリットは、権限管理がロール・レベルでしか実施できないことです。個々の権限は、オペレーティング・システムを使用して付与することはできません。ただし、GRANT文を使用してデータベース内で付与することは可能です。

この機能を使用する際の第2のデメリットは、オペレーティング・システムがロールを管理している場合に、デフォルトではユーザーが共有サーバーまたはその他のネットワーク接続を介してデータベースに接続できないことです。ただし、このデフォルトは「オペレーティング・システムによるロール管理使用時のネットワーク接続の使用」の説明に従って変更できます。

注意:
この項で説明されている機能は、一部のオペレーティング・システムでしか使用できません。これらの機能が使用できるかどうかを確認するには、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

オペレーティング・システムのロール識別機能の使用

セッションの作成時に、データベースがオペレーティング・システムを使用して各ユーザーのデータベース・ロールを識別するように、初期化パラメータOS_ROLESをTRUEに設定します(インスタンスが実行中の場合は再起動が必要)。ユーザーがデータベースとのセッションを作成しようとすると、Oracle Databaseはオペレーティング・システムによって識別されるデータベース・ロールを使用して、そのユーザーのセキュリティ・ドメインを初期化します。

ユーザーのデータベース・ロールを識別するためには、各Oracle Databaseユーザーのオペレーティング・システム・アカウントが、どのデータベース・ロールをユーザーが使用できるようになるかを示すオペレーティング・システム識別子(これらはグループ、権限識別子、または他の類似した名前で呼ばれる場合があります)を持っている必要があります。ロールの指定は、どのロールがユーザーのデフォルト・ロールであるか、どのロールがADMINオプションで使用可能かを示すことも可能です。どのオペレーティング・システムを使用している場合も、オペレーティング・システム・レベルでのロールの指定は次の形式になります。

ora_ID_ROLE[[_d][_a][_da]]

次のように値を指定します。

- IDの定義は、オペレーティング・システムが異なると変わります。たとえばVMSでは、IDはデータベースのインスタンス識別子、VMSではコンピュータ・タイプ、UNIXではシステムIDです。

注意:
IDは、ORACLE_SIDと照合する際に大/小文字が区別されます。ROLEでは、大/小文字は区別されません。

- ROLEは、データベース・ロールの名前です。

- dは、このロールがデータベース・ユーザーのデフォルト・ロールであることを示すオプション文字です。

- aは、このロールがADMINオプション付きでユーザーに付与されることを示すオプション文字です。このオプション文字を指定することによって、ユーザーはこのロールを他のロールにのみ付与できるようになります。オペレーティング・システムを使用してロールを管理している場合は、ユーザーにロールを付与できません。

注意:
dまたはaのいずれかを指定する場合は、その文字の直前にアンダースコア(_)を指定してください。

たとえば、オペレーティング・システム・アカウントが、プロファイルで識別される次のロールを持っているとします。

ora_PAYROLL_ROLE1
ora_PAYROLL_ROLE2_a
ora_PAYROLL_ROLE3_d
ora_PAYROLL_ROLE4_da

対応するユーザーがOracle Databaseのpayrollインスタンスに接続すると、role3とrole4がデフォルト・ロールになり、role2とrole4がADMINオプション付きで付与されます。

オペレーティング・システムのロール管理機能の使用

オペレーティング・システムによって管理されているロールを使用する場合は、データベース・ロールがオペレーティング・システムのユーザーに付与されることに注意してください。オペレーティング・システム・ユーザーが接続できるデータベース・ユーザーは、認可されたデータベース・ロールを使用できます。このため、OS_ROLES = TRUEを使用している場合は、権限が付与されているオペレーティング・システム・アカウントにデータベース・アカウントを対応付けるために、すべてのOracle DatabaseユーザーをIDENTIFIED EXTERNALLYとして定義することを考慮してください。

OS_ROLESがTRUEに設定されている場合のロールの付与と取消し

OS_ROLESパラメータがTRUEに設定されている場合は、ユーザーに対するロールの付与と取消しがオペレーティング・システムによって完全に管理されます。それまでにGRANT文によってユーザーに付与されたロールは適用されません。ただし、それらのロールはデータ・ディクショナリには残っています。オペレーティング・システム・レベルでのユーザーへのロールの付与のみが適用されます。この場合も、ユーザーは権限をロールとユーザーに付与できます。

注意:
オペレーティング・システムによってADMINオプション付きでロールが付与された場合、ユーザーはそのロールを他のロールにのみ付与できます。

OS_ROLESがTRUEに設定されている場合のロールの有効化と無効化

OS_ROLES初期化パラメータがTRUEに設定されている場合、オペレーティング・システムによって付与されたロールは、SET ROLE文を使用して動的に使用可能にできます。ロールがパスワードやオペレーティング・システムによる認可を必要とするように定義されていた場合でも、この文は適用されます。ただし、ユーザーのオペレーティング・システム・アカウントで識別されないロールは、SET ROLE文では指定できません。これは、OS_ROLES = FALSEのときにGRANT文を使用してロールを付与していた場合でも同じです。(このようなロールを指定しても無視されます。)

OS_ROLESがTRUEに設定されている場合、ユーザーは最大148個のロールを使用可能にできます。この数には、ロールに付与されている可能性のある他のロールも含まれることに注意してください。

オペレーティング・システムによるロール管理使用時のネットワーク接続の使用

オペレーティング・システムでロールを管理する場合、ユーザーは、デフォルトでは共有サーバーを介してデータベースに接続できません。リモート・ユーザーは保護されていない接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。

このようなセキュリティに対する危険性の心配がない場合は、初期化パラメータREMOTE_OS_ROLESをTRUEに設定することで、共有サーバーまたはその他のネットワーク接続でオペレーティング・システムのロール管理を使用できます。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効になります。このパラメータのデフォルト設定はFALSEです。

権限の付与と取消しが有効になるとき

付与と取消しがいつ有効になるかは、付与または取り消す対象によって異なります。

- 任意の対象(ユーザー、ロールおよびPUBLIC)に対するシステム権限とオブジェクト権限の付与および取消しは、即時に有効になります。

- 任意の対象(ユーザー、他のロール、PUBLIC)に対するロールの付与および取消しが有効になるのは、その付与および取消しの実行後、ロールを再度使用可能にするために現行のユーザー・セッションでSET ROLE文を発行したとき、あるいはその付与または取消しを実行した後に新しくユーザー・セッションを作成したときです。

現在使用可能なロールは、SESSION_ROLESデータ・ディクショナリ・ビューを問い合せることによって確認できます。

SET ROLE文が付与と取消しに与える影響

ユーザーまたはアプリケーションは、ユーザー・セッション中にSET ROLE文を何度でも使用して、現在そのセッションで使用可能になっているロールを変更できます。ユーザーには、SET ROLE文で指定したロールが、事前に付与されている必要があります。

例4-16では、すでに付与されているロールclerkを使用可能にして、パスワードを指定しています。

例4-16 SET ROLEを使用したロールの付与とパスワードの指定

SET ROLE clerk IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。パスワードの最低要件については、「パスワードの最低要件」を参照してください。

例4-17は、SET ROLEを使用してすべてのロールを使用禁止にする方法を示しています。

例4-17 SET ROLEを使用した全ロールの無効化

SET ROLE NONE;

デフォルトのロールの指定

ユーザーがログインすると、そのユーザーに明示的に付与されている権限と、そのユーザーのデフォルト・ロールに含まれる権限が、すべて使用可能になります。

ユーザーのデフォルト・ロールのリストは、ALTER USER SQL文を使用して設定および変更できます。ALTER USER文では、ユーザーがデータベースに接続するときに使用可能になるロールを指定します。この場合、ユーザーにこれらのロールがGRANT文で直接付与されているか、これらのロールがCREATE ROLE権限を持つユーザーによって作成されている必要があります。ALTER USER文のDEFAULT ROLE句の制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。

例4-18では、ユーザーjaneに対してデフォルト・ロールのpayclerkとpettycashを設定しています。

例4-18 ALTER USERを使用したデフォルト・ロールの設定

ALTER USER jane DEFAULT ROLE payclerk, pettycash;

CREATE USER文ではユーザーのデフォルト・ロールを設定できません。ユーザーを最初に作成すると、デフォルトのユーザー・ロール設定はALLであり、ユーザーにその後に付与されるすべてのロールがデフォルト・ロールになります。デフォルトのユーザー・ロールを制限するには、ALTER USER文を使用します。

注意:
(グローバル・ロールやアプリケーション・ロール以外の)ロールを作成すると、このロールが自分に暗黙的に付与され、自分のデフォルト・ロールのセットが新しいロールを含むように更新されます。ユーザー・セッションで有効にできるロールは148個のみであることに注意してください。DBAロールのような集計ロールがユーザーに付与されると、そのロールに付与されるロールはユーザーが持っているロール数に含まれます。たとえば、あるロールには20個のロールが付与されており、そのロールをユーザーに付与すると、そのユーザーは21個の追加ロールを持っていることになります。したがって、新しいロールをユーザーに付与するときは、ALTER USER文のDEFAULT ROLE句を使用してそのユーザーのデフォルト・ロールとして指定されるロールが多すぎないよう確認してください。

ユーザーが使用可能にできるロールの最大数

ユーザーが使用可能にできるロール数は148個までです。ユーザーには必要な数だけロールを付与できますが、ユーザーに付与するロール数は、ユーザーが必要な最小限のロール数に制限する必要があります。ユーザーへのロール付与に関する追加ガイドラインは、「ロールの保護に関するガイドライン」を参照してください。

PL/SQLパッケージおよびタイプでのファイングレイン・アクセスの管理

PL/SQLパッケージUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDR、DBMS_LDAPおよびHttpUriType型を介した外部ネットワーク・サービスおよびウォレットへのユーザー・アクセスの制御を構成できます。

- データベースから外部ネットワーク・サービスへのアクセスが必要なユーザーやロールに、ファイングレイン・アクセス・コントロールを構成します。これによって、特定のユーザー・グループは、付与されている権限に基づいて1つ以上のホスト・コンピュータに接続できます。通常、この機能は、特定のホスト・アドレスで実行されるアプリケーションへのアクセスを制御するために使用します。

- パスワードまたはクライアント証明書認証を必要とするHTTPリクエストを処理するために、Oracleウォレットにファイングレイン・アクセス・コントロールを構成します。この機能により、Oracleウォレットに格納されているパスワードとクライアント証明書を使用するユーザーに、保護されている外部HTTPリソースにUTL_HTTPパッケージを介してアクセスする権限を付与できます。たとえば、アプリケーションで資格証明をハードコードするかわりに、ウォレットに格納されている資格証明を使用するようにアプリケーションを構成できます。ウォレットを使用してパスワードと資格証明を格納する方法の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

この項の内容は、次のとおりです。

- 外部ネットワーク・サービスに対するファイングレイン・アクセス・コントロールについて

- ウォレットに対するアクセス制御について

- 外部ネットワーク・サービスを使用するパッケージに依存しているアプリケーションのアップグレード

- 外部ネットワーク・サービスに対するアクセス制御リストの作成

- ウォレットに対するアクセス制御の構成

- アクセス制御リストの作成例

- ネットワーク・ホスト・コンピュータのグループの指定

- 複数のアクセス制御リスト割当てでのホスト・コンピュータの優先順位

- ポート範囲指定によるアクセス制御リスト割当てでのホストの優先順位

- ネットワーク・ホストへのユーザー・アクセスに影響を与える権限割当てのチェック

- 単一アクセス制御リスト内の複数のユーザーとロールに対する優先順位の設定

- ユーザー・アクセス用に構成されたアクセス制御リストに関する情報の検索

外部ネットワーク・サービスに対するファイングレイン・アクセス・コントロールについて

外部ネットワーク・サービスに対するファイングレイン・アクセス・コントロールを構成するために、Oracle XML DBに保管されるアクセス制御リスト(ACL)を作成します。アクセス制御リストは、Oracle XML DBそのものを使用するか、DBMS_NETWORK_ACL_ADMINおよびDBMS_NETWORK_ACL_UTILITY PL/SQLパッケージを使用して作成できます。このマニュアルでは、これらのパッケージを使用してアクセス制御リストを作成および管理する方法について説明します。Oracle XML DBを使用してアクセス制御リストを作成する場合の説明とアクセス制御リストに関する全体的な概念情報は、『Oracle XML DB開発者ガイド』を参照してください。

この機能を使用することで、データベース・ユーザーがPL/SQLネットワーク・ユーティリティ・パッケージUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDR、PL/SQLパッケージDBMS_LDAPおよびHttpUriType型を使用して接続できる外部ネットワーク・ホストが制限されるため、ネットワーク接続のセキュリティが強化されます。この機能を使用しない場合、デフォルトでは、PL/SQLユーティリティ・パッケージは、PUBLICユーザーに付与されるEXECUTE権限付きで作成されるため、データベースへのアクセス権を獲得した侵入者が故意にネットワークを攻撃する可能性があります。これらのPL/SQLネットワーク・ユーティリティ・パッケージおよびDBMS_NETWORK_ACL_ADMINとDBMS_NETWORK_ACL_UTILITYパッケージは、IPバージョン4(IPv4)アドレスとIPバージョン6(IPv6)アドレスの両方をサポートしています。このマニュアルでは、両方のバージョンに対してアクセス制御を管理する方法について説明します。Oracle DatabaseでのIPv4およびIPv6表記法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

関連項目:
電子メール・アラート用に外部ネットワーク・サービスへのアクセス制御を構成する例は、「例: ファイングレイン監査ポリシーへの電子メール・アラートの追加」を参照してください。

ウォレットに対するアクセス制御について

リモートのWebサーバーで保護されているWebページにアクセスする際、ユーザーはOracleウォレットに格納されているパスワードとクライアント証明書を使用して認証を行うことができます。Oracleウォレットでは、ユーザーのパスワードとクライアント証明書を安全に格納できます。

ウォレットに対するアクセス制御を構成するには、次のコンポーネントが必要です。

- Oracleウォレット。Oracleウォレットは、Oracle DatabaseのmkstoreユーティリティまたはOracle Wallet Managerを使用して作成できます。HTTPリクエストでは、外部パスワード・ストアまたはウォレット内のクライアント証明書を使用してユーザーが認証されます。

- ユーザーにウォレットの使用権限を付与するアクセス制御リスト。アクセス制御リストは、DBMS_NETWORK_ACL_ADMIN PL/SQLパッケージを使用して作成します。

- ウォレットとアクセス制御リストを関連付ける方法。DBMS_NETWORK_ACL_ADMIN PL/SQLパッケージを使用します。

ウォレットを使用すると、保護されているWebページへのアクセスに必要なパスワードとクライアント証明書を安全に格納できます。

関連項目:
「ウォレットに対するアクセス制御の構成」

外部ネットワーク・サービスを使用するパッケージに依存しているアプリケーションのアップグレード

Oracle Database 11g リリース1(11.1)より前のリリースからアップグレードしているときに、アプリケーションがPL/SQLネットワーク・ユーティリティ・パッケージUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDR、PL/SQLパッケージDBMS_LDAPまたはHttpUriType型に依存している場合は、そのアプリケーションの実行を試みたときに、次のエラーが発生する可能性があります。

ORA-24247: network access denied by access control list (ACL)

その場合は、この項に記載されている手順を使用してアプリケーションのネットワーク・アクセスを再構成してください。PL/SQLネットワーク・ユーティリティ・パッケージに依存しているアプリケーションの互換性に関する問題については、『Oracle Databaseアップグレード・ガイド』も参照してください。ネットワーク・ユーティリティ・パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

外部ネットワーク・サービスに対するアクセス制御リストの作成

ネットワーク接続用にアクセス制御リストを作成する場合は、共通するユーザー(例: 特定のホスト・コンピュータ上の特定のアプリケーションにアクセスする必要があるユーザー)のグループ専用に1つのアクセス制御リストを作成してください。管理の容易性と良好なシステム・パフォーマンスを確保するために、アクセス制御リストは必要以上に多く作成しないでください。同じユーザー・グループがアクセスできる複数のネットワーク・ホストで、同じアクセス制御リストを共有する必要があります。

DBMS_NETWORK_ACL_ADMINパッケージを使用してアクセス制御リストを作成する手順は、次のとおりです。

- 手順1: アクセス制御リストとその権限の定義の作成

- 手順2: 1つ以上のネットワーク・ホストへのアクセス制御リストの割当て

手順1: アクセス制御リストとその権限の定義の作成

DBMS_NETWORK_ACL_ADMIN.CREATE_ACLプロシージャを使用して、アクセス制御リストの内容を作成します。内容は、アクセス制御リストの名前、簡単な説明、そしてアクセス制御リストに対応付ける1つのユーザーまたはロールの権限設定からなります。アクセス制御リストでは、各ユーザーまたはロールの権限はアクセス制御エントリ(ACE)としてグループ化されています。アクセス制御リストには、少なくとも1つのユーザーまたはロールの権限設定が必要です。

注意:
アクセス制御リストの設定は、Oracle Databaseのインポートまたはエクスポート・ユーティリティ(Oracle Data Pumpなど)を使用してインポートまたはエクスポートすることはできません。

次に例を示します。

BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
acl          => 'file_name.xml',
description  => 'file description',
principal    => 'user_or_role',
is_grant     => TRUE|FALSE,
privilege    => 'connect|resolve',
start_date   => null|timestamp_with_time_zone,
end_date     => null|timestamp_with_time_zone);
END;

次のように値を指定します。

- acl: アクセス制御リストのXMLファイル名を入力します。このファイルは、データベースのXML DBリポジトリにある/sys/aclsディレクトリに作成されます。.xml拡張子を指定してください。例:

acl => 'us-example-com-permissions.xml',

- description: ファイルの目的に関する簡単な説明を入力します。例:

description => 'Network connection permission for ACCT_MGR role',

- principal: 権限を付与または拒否する最初のユーザー・アカウントまたはロールを入力します。例:

principal => 'ACCT_MGR',

ユーザー・アカウントまたはロールの名前は大/小文字を区別して入力します。たとえば、ロール名ACCT_MGRがすべて大文字でデータベースに格納されている場合は、大文字と小文字の両方を使用したり、小文字で入力しても機能しません。DBA_USERSビューとDBA_ROLESデータ・ディクショナリ・ビューを問い合せることで、現行のデータベース・インスタンス内のユーザー・アカウントとロールを確認できます。通常、ユーザー名とロールは大文字で保存されます。

複数のユーザーを入力する場合、またはこのユーザーまたはロールに追加の権限を付与する場合、このアクセス制御リストのXMLファイルを作成した後、次に説明するDBMS_NETWORK_ACL.ADD_PRIVILEGEプロシージャを使用します。

- is_grant: TRUEまたはFALSEを入力し、権限を付与するか拒否するかを示します。例:

is_grant => TRUE,

- privilege: connectまたはresolveを入力します。この設定は、大/小文字が区別されるため、必ず小文字で入力してください。例:

privilege => 'connect',

connect権限は、外部ホストのネットワーク・サービスに接続する権限をユーザーに付与します。resolve権限は、ネットワーク・ホスト名またはIPアドレスを解決する権限をユーザーに付与します。

UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、DBMS_LDAPのパッケージおよびHttpUriType型を使用してホストに接続するデータベース・ユーザーには、外部ネットワークのホスト・コンピュータへのconnect権限が必要です。かわりに、UTL_INADDRパッケージを使用して、ホストのIPアドレスが指定されたホスト名またはホスト名が指定されたIPアドレスを解決するには、データベース・ユーザーにresolve権限を付与します。

既存の権限とネットワーク接続の詳細を検索するには、「ユーザー・アクセス用に構成されたアクセス制御リストに関する情報の検索」で説明しているデータ・ディクショナリ・ビューを使用できます。

- start_date: (オプション)アクセス制御エントリ(ACE)の開始日をTIMESTAMP WITH TIME ZONE書式(YYYY-MM-DD HH:MI:SS.FF TZR)で入力します。開始日を指定すると、アクセス制御エントリは指定日以降にのみ有効になります。デフォルトはnullです。たとえば、開始日を米国カリフォルニア州サンフランシスコ(太平洋タイムゾーン)の2008年2月28日午前6時30分に設定するには、次のように指定します。

start_date => '2008-02-28 06:30:00.00 US/Pacific',

NLS_TIMESTAMP_FORMAT初期化パラメータは、デフォルトのタイムスタンプ書式を設定します。詳細は、『Oracle Databaseリファレンス』を参照してください。

- end_date: (オプション)アクセス制御エントリ(ACE)の終了日をTIMESTAMP WITH TIME ZONE書式(YYYY-MM-DD HH:MI:SS.FF TZR)で入力します。終了日を指定すると、アクセス制御エントリは指定日を経過すると無効になります。end_dateには、start_date以降の日時を設定する必要があります。デフォルトはnullです。
たとえば、終了日を米国カリフォルニア州サンフランシスコ(太平洋タイムゾーン)の2008年12月10日午後11時59分に設定するには、次のように指定します。

end_date => '2008-12-10 23:59:00.00 US/Pacific');

アクセス制御リストにユーザーまたはロールを追加するか、1つのユーザーまたはロールに追加の権限を付与するには、DBMS_NETWORK_ACL.ADD_PRIVILEGEプロシージャを使用します。構文は、次のとおりです。

BEGIN
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE (
acl         => 'file_name.xml',
principal   => 'user_or_role',
is_grant    => TRUE|FALSE,
privilege   => 'connect|resolve',
position    => null|value,
start_date  => null|timestamp_with_time_zone,
end_date    => null|timestamp_with_time_zone);
END;

このように、権限を追加するためのパラメータは、CREATE_ACLプロシージャのパラメータに類似していますが、descriptionがないことと、複数のユーザーまたはロールの優先順位を設定するpositionパラメータが追加されている点が異なります。ここでは、複数のユーザーやロールを追加しているため、優先順位の設定が必要となる可能性があります。詳細は、「単一アクセス制御リスト内の複数のユーザーとロールに対する優先順位の設定」を参照してください。

この手順で使用できる他のDBMS_NETWORK_ACL_ADMINプロシージャには、DELETE_PRIVILEGEおよびDROP_ACLがあります。

これまでの手順で、ネットワーク・ホストへの接続に必要な権限を定義するアクセス制御リストを作成しました。ただし、このアクセス制御リストは、手順2: 1つ以上のネットワーク・ホストへのアクセス制御リストの割当てを完了するまでは無効です。

手順2: 1つ以上のネットワーク・ホストへのアクセス制御リストの割当て

作成したアクセス制御リストは、1つ以上のネットワーク・ホスト・コンピュータに割り当てることができます。この割当てには、DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACLプロシージャを使用します。

例:

BEGIN
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
acl         => 'file_name.xml',
host        => 'network_host',
lower_port  => null|port_number,
upper_port  => null|port_number);
END;

次のように値を指定します。

- acl: ネットワーク・ホストに割り当てるアクセス制御リストのXMLファイル名を入力します(「手順1: アクセス制御リストとその権限の定義の作成」)。このファイルは、データベースのXML DBリポジトリにある/sys/aclsディレクトリに作成されます。.xml拡張子を指定してください。例:

acl => 'us-example-com-permissions.xml',

- host: このアクセス制御リストを割り当てるネットワーク・ホストを入力します。この設定には、ネットワーク・ホストの名前またはIPアドレスを使用できます。ホスト名は大/小文字が区別されません。例:

host => 'us.example.com',

localhostを指定し、ローカル・ホストが想定されている状況でPL/SQLパッケージUTL_INADDRおよびUTL_HTTPを使用してホスト名が指定されていない場合、これらのパッケージは、host設定のlocalhostが割り当てられているACLを検索して使用します。

アクセス制御リスト割当てにおけるネットワーク・ホスト・コンピュータの動作の詳細は、次の各項を参照してください。

- 「ネットワーク・ホスト・コンピュータのグループの指定」

- 「ネットワーク・ホストへのユーザー・アクセスに影響を与える権限割当てのチェック」

- 「複数のアクセス制御リスト割当てでのホスト・コンピュータの優先順位」

- 「ポート範囲指定によるアクセス制御リスト割当てでのホストの優先順位」

- lower_port:(オプション)TCP接続に対するポート範囲の下限を入力します。この設定は、connect権限の場合にのみ使用し、resolve権限の場合は省略します。デフォルトはnullで、ポート制限がない(つまり、すべてのポートにACLが適用される)ことを意味します。ポート番号の範囲は1から65535です。
例:

lower_port => 80,

- upper_port:(オプション)TCP接続に対するポート範囲の上限を入力します。この設定は、connect権限の場合にのみ使用し、resolve権限の場合は省略します。デフォルトはnullで、ポート制限がない(つまり、すべてのポートにACLが適用される)ことを意味します。ポート番号の範囲は1から65535です。
例:

upper_port => 3999);

lower_portに値を入力してupper_portをnullのままに(または省略)すると、upper_portの設定は、lower_portと同じ設定とみなされます。たとえば、lower_portを80に設定し、upper_portを省略すると、このupper_portの設定は80とみなされます。

アクセス制御リスト割当てにポート範囲が指定されている場合、アクセス制御リストのresolve権限は機能しません。

ホスト・コンピュータ、ドメイン、IPサブネットまたはTCPポート範囲(指定されている場合)に対して指定できるアクセス制御リストは、1つのみです。新しいアクセス制御リストをネットワーク・ターゲットに割り当てると、同じターゲットに割り当てられていた以前のアクセス制御リストの割当ては解除されます。ただし、アクセス制御リストは削除されません。アクセス制御リストを削除するには、DROP_ACLプロシージャを使用します。アクセス制御リスト割当てを解除するには、UNASSIGN_ACLプロシージャを使用します。

アクセス制御リストの作成方法やメンテナンス方法によっては、2つの手順が重複する可能性があります。たとえば、5人のユーザーに対する権限を記載したアクセス制御リストを作成し、そのリストを2台のホスト・コンピュータに適用します。その後、異なる(または追加の)ユーザーと権限を保持するようにこのアクセス制御リストを変更し、異なる(または追加の)ホスト・コンピュータにそのリストを適用します。

アクセス制御リストの変更は、ネットワーク・ホストへの割当ても含めて、すべてトランザクションです。変更内容は、トランザクションがコミットされるまで無効です。

既存の権限とネットワーク接続に関する情報は、表4-6「アクセス制御リストに関する情報を表示するデータ・ディクショナリ・ビュー」に説明されているデータ・ディクショナリ・ビューを使用して確認できます。

DBMS_NETWORK_ACL_ADMINパッケージの使用方法は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ウォレットに対するアクセス制御の構成

この方法では、Oracleウォレットに保管されるパスワードとクライアント証明書に対するアクセス権をユーザーに付与して、ユーザーが外部のWebサーバーに対して自身を認証できるようにします。これにより、ユーザーは保護されたWebページをWebサーバーから取得できるようになります。

この項の内容は、次のとおりです。

- 手順1: Oracleウォレットの作成

- 手順2: ウォレット権限を付与するアクセス制御リストの作成

- 手順3: ウォレットへのアクセス制御リストの割当て

- 手順4: パスワードとクライアント証明書を使用するHTTPリクエストの作成

手順1: Oracleウォレットの作成

ウォレットは、mkstoreコマンドライン・ユーティリティまたはOracle Wallet Managerユーザー・インタフェースを使用して作成できます。ウォレットにパスワードを格納するには、mkstoreを使用する必要があります。標準ウォレット・タイプとPKCS11ウォレット・タイプのどちらも使用可能で、必要であればウォレットを自動ログイン・ウォレットにすることもできます。ウォレットの作成の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

ウォレットを作成するには、次のようにします。

- ウォレットがファイルにエクスポートされていることを確認します。

- ウォレットを作成したディレクトリを書き留めておきます。このディレクトリ・パスは、このセクションの手順の終了後に必要になります。

関連項目:

- 「非共有ウォレットのパスワードを使用するアクセス制御リストの例」

- 「共有データベース・セッションに使用するウォレットのアクセス制御リストの例」

手順2: ウォレット権限を付与するアクセス制御リストの作成

ウォレットを作成した後、HTTP認証でウォレットのパスワード資格証明を使用する際にユーザーが必要なパスワードまたはクライアント証明書権限を割り当てるアクセス制御リストを作成できます。

例:

BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
acl         => 'file_name.xml',
description => 'description',
principal   => 'user_or_role',
is_grant    => TRUE|FALSE,
privilege   => 'privilege';
...
END;

次のように値を指定します。

- acl: ACLの名前を入力し、この名前を書き留めておきます。この名前は、「手順3: ウォレットへのアクセス制御リストの割当て」で必要になります。このファイルは、データベースのXML DBリポジトリにある/sys/aclsディレクトリに作成されます。.xml拡張子を指定してください。例:

acl         => 'hr_access_wallet_acl.xml',

- description: ファイルの目的に関する簡単な説明を入力します。例:

description => 'Wallet ACL for the hr_access application',

- principal: 権限を付与または拒否するユーザー・アカウントまたはロールを入力します。例:

principal   => 'HR_CLERK',

この名前は、大/小文字を区別して入力します。たとえば、ロール名HR_CLERKがすべて大文字でデータベースに格納されている場合は、大文字と小文字の両方を使用したり、小文字で入力しても機能しません。DBA_USERSビューとDBA_ROLESデータ・ディクショナリ・ビューを問い合せることで、現行のデータベース・インスタンス内のユーザー・アカウントとロールを確認できます。通常、ユーザー名とロールは大文字で保存されます。

複数のユーザーを追加する場合、またはこのユーザーに追加の権限を付与する場合、このアクセス制御リストのXMLファイルを作成した後、DBMS_NETWORK_ACL.ADD_PRIVILEGEプロシージャを使用できます。

- is_grant: TRUEまたはFALSEを入力し、権限を付与するか拒否するかを示します。例:

is_grant    => TRUE,

- privilege: 次のいずれかの設定を、小文字とハイフンを使用して入力します。権限名は大/小文字が区別されることに注意してください。

- use-passwords: ウォレットのパスワードを使用する権限をユーザーに付与します。

- use-client-certificates: ウォレットのクライアント証明書でユーザーを認証します。

例:

privilege    => 'use-client-certificates');

手順3: ウォレットへのアクセス制御リストの割当て

この手順では、このアクセス制御リストを先に作成したウォレットに割り当てます。この結果、DBA_WALLET_ACLSデータ・ディクショナリ・ビューを問い合せて設定を確認できるようになります。

例:

BEGIN
...
DBMS_NETWORK_ACL_ADMIN.ASSIGN_WALLET_ACL (
acl         => 'file_name.xml',
wallet_path => 'file:path_to_directory_containing_wallet');
END;

次のように値を指定します。

- acl: 前のセクションの「手順2: ウォレット権限を付与するアクセス制御リストの作成」でウォレットに作成した名前を入力します。例:

acl         => 'hr_access_wallet_acl.xml',

- wallet_path: ウォレットが格納されているディレクトリのパスを入力します。ウォレットのパスを指定する際は、絶対パスを使用し、ディレクトリ・パスの前にfile:を入れる必要があります。$ORACLE_HOMEなどの環境変数を使用したり、file:の後およびパス名の前にスペースを挿入することはできません。例:

wallet_path => 'file:/oracle/wallets/hr_access_access'

手順4: パスワードとクライアント証明書を使用するHTTPリクエストの作成

この手順では、UTL_HTTP PL/SQLパッケージを使用して、HTTPリクエストとそのレスポンスで個別に使用されるリクエスト・コンテキスト・オブジェクトを作成します。UTL_HTTPパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

例:

DECLARE
req_context UTL_HTTP.REQUEST_CONTEXT_KEY;
req         UTL_HTTP.REQ;
BEGIN
req_context := UTL_HTTP.CREATE_REQUEST_CONTEXT (
wallet_path          => 'file:path_to_directory_containing_wallet',
wallet_password      => 'wallet_password'|NULL);
req := UTL_HTTP.BEGIN_REQUEST(
url                  => 'URL_to_application',
request_context      => 'request_context'|NULL);
...
END;

次のように値を指定します。

- req_context: UTL_HTTP.CREATE_REQUEST_CONTEXT_KEYデータ型を使用して、リクエスト・コンテキスト・オブジェクトを作成します。このオブジェクトには、Oracle Databaseがリクエスト・コンテキストの識別に使用する、ランダムに生成された数値キーが格納されています。UTL_HTTP.CREATE_REQUEST_CONTEXTファンクションは、リクエスト・コンテキスト自体を作成します。

- req: UTL_HTTP.REQデータ型を使用して、HTTPリクエストを開始するためのオブジェクトを作成します。このオブジェクトは後で、パスワードで保護されたWebページにアクセスするために、ウォレットからユーザー名とパスワードを設定する際に参照します。

- wallet_path: ウォレットが格納されているディレクトリのパスを入力します。このパスは、前のセクションの「手順3: ウォレットへのアクセス制御リストの割当て」でアクセス制御リストを作成したときに指定したパスと同じであることを確認してください。ディレクトリ・パスの前にfile:を含める必要があります。$ORACLE_HOMEなどの環境変数を使用しないでください。
例:

wallet_path     => 'file:/oracle/wallets/hr_access_access',

- wallet_password: ウォレットを開くためのパスワードを入力します。デフォルトはNULLで、自動ログイン・ウォレットに使用します。例:

wallet_password      => NULL);

- url: ウォレットを使用するアプリケーションのURLを入力します。
例:

url                  => 'www.hr_access.example.com',

- request_context: このセクションの前の方で作成したリクエスト・コンテキスト・オブジェクトの名前を入力します。このオブジェクトにより、ウォレットは同一データベース・セッション内の他のアプリケーションとは共有されなくなります。
例:

request_context      => req_context);

他のアプリケーションとセッションを共有している場合に、リクエスト・コンテキストを使用してウォレットを保留

他のアプリケーションとデータベース・セッションを共有している場合は、リクエスト・コンテキストを使用してウォレットを保留にする必要があります。アプリケーションがデータベース・セッションを排他的に使用している場合は、かわりにSET_WALLETプロシージャを使用してデータベース・セッションでウォレットを保留できます。

例:

DECLARE
req         UTL_HTTP.REQ;
BEGIN
UTL_HTTP.SET_WALLET(
path          => 'file:path_to_directory_containing_wallet',
password      => 'wallet_password'|NULL);
req := UTL_HTTP.BEGIN_REQUEST(
url           => 'URL_to_application');
...
END;

要求された保護されているURLが、認証にユーザー名とパスワードを必要とする場合は、SET_AUTHENTICATION_FROM_WALLETプロシージャを使用してウォレットからユーザー名とパスワードを設定して認証します。

クライアント証明書のみを使用する認証

要求された保護されているURLが、認証にクライアント証明書のみを必要とする場合、BEGIN_REQUESTファンクションはウォレットに割り当てられているACLでユーザーにuse-client-certificates権限が付与されているものと見なして、ウォレットから必要なクライアント証明書を送信します。認証はリモートWebサーバーで成功し、ユーザーはGET_RESPONSEファンクションを使用してHTTP応答を取得できます。

パスワードを使用した認証

要求された保護されているURLが、認証にユーザー名とパスワードを必要とする場合は、SET_AUTHENTICATION_FROM_WALLETプロシージャを使用してウォレットからユーザー名とパスワードを設定して認証する必要があります。

例:

DECLARE
req_context UTL_HTTP.REQUEST_CONTEXT_KEY;
req         UTL_HTTP.REQ;
BEGIN
...
UTL_HTTP.SET_AUTHENTICATION_FROM_WALLET(
r               => HTTP_REQUEST,
alias           => 'alias_to_retrieve_credentials_stored_in_wallet',
scheme          => 'AWS|Basic',
for_proxy       => TRUE|FALSE);
END;

次のように値を指定します。

- r: 前のセクションで作成したUTL_HTTP.BEGIN_REQUESTプロシージャで定義したHTTPリクエストを入力します。例:

r               => req,

- alias: Oracleウォレットに格納されているユーザー名とパスワード資格証明を識別および取得するための別名を入力します。たとえば、このユーザー名とパスワード資格証明を識別するための別名がhr_accessであるとします。

alias           => 'hr_access',

- scheme: 次のいずれかを入力します。

- AWS: Amazon Simple Storage Service(S3)スキームを指定します。このスキームは、Amazon.comのWebサイトへのアクセスを構成する場合にのみ使用します。(この設定の詳細は、Amazonにお問い合せください。)

- Basic: HTTP basic認証を指定します。デフォルトはBasicです。

例:

scheme          => 'Basic',

- for_proxy: HTTP認証情報がWebサーバーではなくHTTPプロキシ・サーバーへのアクセス用かどうかを指定します。デフォルトはFALSEです。
次に例を示します。

for_proxy       => TRUE);

ウォレットのユーザー名とパスワードを使用するには、ウォレットに割り当てられているACLでユーザーにuse-passwords権限が付与されている必要があります。

アクセス制御リストの作成例

次の各例は、アクセス制御リストの使用方法を示しています。

- 1つのロールと1つのネットワーク接続を割り当てるアクセス制御リストの例

- 複数のホストに複数のロールを割り当てるアクセス制御リストの例

- 非共有ウォレットのパスワードを使用するアクセス制御リストの例

- 共有データベース・セッションに使用するウォレットのアクセス制御リストの例

関連項目:
管理者がUTL_MAIL PL/SQLパッケージを使用して電子メール・アラートを構成する必要がある場合の、アクセス制御リストの使用方法を示した例については、『Oracle Database Vault管理者ガイド』を参照してください。

1つのロールと1つのネットワーク接続を割り当てるアクセス制御リストの例

例4-19は、us-example-com-permissions.xmlというアクセス制御リストの作成方法を示しています。このアクセス制御リストは、ACCT_MGRロールを持つユーザーに対して、ホストus.example.comで実行されるネットワーク・サービスへのアクセス権を付与します。

例4-19 1つのロールと1つのネットワーク接続を割り当てるアクセス制御リストの作成

-- 1. Create the access control list, which includes one role:
BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
acl          => 'us-example-com-permissions.xml',
description  => 'Network connection permission for ACCT_MGR',
principal    => 'ACCT_MGR', -- Must be in upper case
is_grant     => TRUE,
privilege    => 'connect');
END;
/

-- 2. Assign the access control list a network host:
BEGIN
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
acl         => 'us-example-com-permissions.xml',
host        => 'www.us.example.com',
lower_port  => 80,
upper_port  => 80);
END;
/

この例ではus-example-com-permissions.xmlファイルを、デフォルトの場所である/sys/aclsディレクトリに作成します。XMLファイルは次のようになります。

<acl description="Network connection permission for ACCT_MGR"
xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
xmlns:plsql="http://xmlns.oracle.com/plsql"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd    http://xmlns.oracle.com/xdb/acl.xsd">
<security-class>plsql:network</security-class>
<ace>
<grant>true</grant>
<principal>ACCT_MGR</principal>
<privilege><plsql:connect/></privilege>
</ace>
</acl>

xmlns要素とxsi要素は固定です。テキスト・エディタなどで変更しないでください。

アクセス制御リストの内容はSQL*Plusでチェックできます。例については、『Oracle XML DB開発者ガイド』を参照してください。

複数のホストに複数のロールを割り当てるアクセス制御リストの例

例4-20は、us-example-com-permissions.xmlアクセス制御リストより少し複雑なリストの作成方法を示しています。この例では、複数のロール権限とその優先順位を指定し、複数のホスト・コンピュータに割り当てます。

ホスト名の詳細は、「ネットワーク・ホスト・コンピュータのグループの指定」および「複数のアクセス制御リスト割当てでのホスト・コンピュータの優先順位」を参照してください。アクセス制御リストXMLファイル内の複数のACE要素の順序を判断するには、「単一アクセス制御リスト内の複数のユーザーとロールに対する優先順位の設定」も参照してください。

例4-20 複数のロールと複数のネットワーク接続を割り当てるアクセス制御リストの作成

-- 1. Create the access control list:
BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
acl          => 'us-example-com-permissions.xml',
description  => 'Network connection permission for ACCT_MGR and ACCT_CLERK',
principal    => 'ACCT_MGR', -- Must be in upper case
is_grant     => TRUE,
privilege    => 'resolve');
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE ( -- Creates the second role privilege
acl          => 'us-example-com-permissions.xml',
principal    => 'ACCT_CLERK',
is_grant     => TRUE,
privilege    => 'connect',
position     => null);
END;
/

-- 2. Assign the access control list to hosts:
BEGIN
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( -- Creates the first target host
acl          => 'us-example-com-permissions.xml',
host         => '*.us.example.com');
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( -- Creates the second target host
acl          => 'us-example-com-permissions.xml',
host         => '*.uk.example.com',
lower_port   => 80,
upper_port   => 99);
END;
/

us-example-com-permissions.xmlは、次のようになります。

<acl description="Network connection permission for ACCT_MGR and ACCT_CLERK"
xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
xmlns:plsql="http://xmlns.oracle.com/plsql"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd    http://xmlns.oracle.com/xdb/acl.xsd">
<security-class>plsql:network</security-class>
<ace>
<grant>true</grant>
<principal>ACCT_MGR</principal>
<privilege><plsql:resolve/></privilege>
</ace>
<ace>
<grant>true</grant>
<principal>ACCT_CLERK</principal>
<privilege><plsql:connect/></privilege>
</ace>
</acl>

例4-21は、前述のアクセス制御リストで付与された権限をDBA_NETWORK_ACL_PRIVILEGESデータ・ディクショナリ・ビューに表示する方法を示しています。

例4-21 DBA_NETWORK_ACL_PRIVILEGESビューを使用した付与権限の表示

ACL
ACLID                                  PRINCIPAL  PRIVILEGE IS_GRANT INVERT
START_DATE END_DATE
------------------------------------------
-------------------------------- ---------- -------   -------- -------
---------- ----------
/sys/acls/us-example-com-permissions.xml 2EF86135D0E29B2AE040578CE4043250 ACCT_
MGR   resolve   true       false
/sys/acls/us-example-com-permissions.xml 2EF86135D0E29B2AE040578CE4043250 ACCT_
CLERK connect   true       false

例4-22は、アクセス制御リストのホスト割当てをDBA_NETWORK_ACLSデータ・ディクショナリ・ビューに表示する方法を示しています。

例4-22 DBA_NETWORK_ACLSビューを使用したホスト割当ての表示

HOST                     LOWER_PORT UPPER_PORT
ACL
ACLID
-------------------- ---------- ----------
------------------------------------------
--------------------------------
*.us.example.com
/sys/acls/us-example-com-permissions.xml 2EF86135D0E29B2AE040578CE4043250
*.uk.example.com      80             99
/sys/acls/us-example-com-permissions.xml 2EF86135D0E29B2AE040578CE4043250

これらの例では、ACCT_MGRロールは最初のホストに対するresolve権限を持っており、ACCT_CLERKロールは1番目と2番目のターゲット・ホストに対する接続権限を持っています。ACCT_MGRロールは2番目のホストに対するresolve権限を持っていませんが、これはポート範囲が2番目のホストに対する割当てで指定されているためです。

SQL*Plusを使用してアクセス制御リストの内容をチェックする方法は、『Oracle XML DB開発者ガイド』を参照してください。

非共有ウォレットのパスワードを使用するアクセス制御リストの例

例4-23では、人事部門の2つのロール、hr_clerkとhr_managerによるウォレットへのアクセスを構成しています。これらのロールは、use-passwords権限を使用して、ウォレットに格納されているパスワードにアクセスします。この例では、ウォレットは同一データベース・セッション内の他のアプリケーションとは共有されません。

例4-23 非共有ウォレットのパスワードを使用するACLアクセスの構成

/* 1. At a command prompt, create the wallet. The following example uses the
user name hr_access as the alias to identify the user name and password
stored in the wallet. You must use this alias name when you call the
SET_AUTHENTICATION_FROM_WALLET procedure later on. */
$ mkstore -wrl $ORACLE_HOME/wallets/hr_access_access -create
Enter password: password
Enter password again: password
$ mkstore -wrl $ORACLE_HOME/wallets/hr_access_access -createCredential hr_access hr_usr
Your secret/Password is missing in the command line
Enter your secret/Password: password
Re-enter your secret/Password: password
Enter wallet password: password

/* 2. In SQL*Plus, create an access control list to grant privileges for the
wallet. The following example grants the use-passwords privilege to the
hr_clerk and hr_manager roles, and then it assigns this ACL to the wallet.*/
BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL(
acl         => 'hr_access_wallet_acl.xml',
description => 'Wallet ACL for hr_access application',
principal   => 'HR_CLERK', -- Must be in upper case
is_grant    => TRUE,
privilege   => 'use-passwords');

DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
acl         => 'hr_access_wallet_acl.xml',
principal   => 'HR_MANAGER',
is_grant    => TRUE,
privilege   => 'use-passwords');

DBMS_NETWORK_ACL_ADMIN.ASSIGN_WALLET_ACL(
acl         => 'hr_access_wallet_acl.xml',
wallet_path => 'file:/oracle/wallets/hr_access_access');
END;
/
COMMIT;

/* 3. Create a request context and request object, and then set the
authentication for the wallet. */
DECLARE
req_context  UTL_HTTP.REQUEST_CONTEXT_KEY;
req          UTL_HTTP.REQ;

BEGIN
req_context := UTL_HTTP.CREATE_REQUEST_CONTEXT(
wallet_path          => 'file:/oracle/wallets/hr_access_access',
wallet_password      => NULL,
enable_cookies       => TRUE,
max_cookies          => 300,
max_cookies_per_site => 20);
req := UTL_HTTP.BEGIN_REQUEST(
url                  => 'www.hr_access.example.com',
request_context      => req_context);
UTL_HTTP.SET_AUTHENTICATION_FROM_WALLET(
r                    => req,
alias                => 'hr_access'),
scheme               => 'Basic',
for_proxy            => FALSE);
END;
/

共有データベース・セッションに使用するウォレットのアクセス制御リストの例

例4-24は、ウォレットを共有データベース・セッションに使用するように構成し、現在のデータベース・セッション内のすべてのアプリケーションがこのウォレットへのアクセス権を持つ点を除いて、例4-23とほぼ同じです。

例4-24 共有データベース・セッションに使用するウォレットのACLアクセスの構成

/* Follow these steps:
1. Use Oracle Wallet Manager to create the wallet and add the client
certificate. See Oracle Database Advanced Security Administrator's Guide
for detailed information about using Oracle Wallet Manager.

2. In SQL*Plus, create an access control list to grant privileges for the
wallet. The following example grants the use-client-certificates privilege
to the hr_clerk and hr_manager roles, then it assigns this ACL to the
wallet. */
BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL(
acl         => 'hr_access_wallet_acl.xml',
description => 'Wallet ACL for hr_access application',
principal   => 'HR_CLERK', -- Must be in upper case
is_grant    => TRUE,
privilege   => 'use-client-certificates');

DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
acl         => 'hr_access_wallet_acl.xml',
principal   => 'HR_MANAGER',
is_grant    => TRUE,
privilege   => 'use-client-certificates');

DBMS_NETWORK_ACL_ADMIN.ASSIGN_WALLET_ACL(
acl         => 'hr_access_wallet_acl.xml',
wallet_path => 'file:/oracle/wallets/hr_access_access');
END;
/
COMMIT;

/* 3. Create a request object to handle the HTTP authentication for the wallet.*/
DECLARE
req  UTL_HTTP.req;
BEGIN
UTL_HTTP.SET_WALLET(
path            => 'file: $ORACLE_HOME/wallets/hr_access_access',
password        => NULL);
req := UTL_HTTP.BEGIN_REQUEST(
url             => 'www.hr_access.example.com',
method          => 'POST',
http_version    => NULL,
request_context => NULL);
END;
/

ネットワーク・ホスト・コンピュータのグループの指定

アクセス制御リストをネットワーク・ホスト・コンピュータのグループに割り当てる場合は、アスタリスク(*)ワイルドカード文字を使用できます。たとえば、ドメインに属しているホスト・コンピュータには*.example.comを入力し、IPサブネットに属しているIPv4アドレスには192.0.2.*を入力します。アスタリスク・ワイルドカードは、最初(ドメインのピリオド(.)の前)または最後(IPサブネットのピリオド(.)の後)に配置する必要があります。たとえば、*.example.comは有効ですが、*example.comや*.example.*は無効です。ワイルドカード文字の使用は、同じホスト・コンピュータに割り当てられている複数のアクセス制御リストの優先順位に影響を与えることに注意してください。IPv6アドレスには、ワイルドカード文字を使用できません。

クラスレス・ドメイン間ルーティング(CIDR)表記法では、インターネット上でのIPパケット・ルーティングにおけるIPv4アドレスとIPv6アドレスの分類が定義されています。DBMS_NETWORK_ACL_ADMINパッケージは、IPv4アドレスとIPv6アドレスの両方に対してCIDR表記法をサポートしています。このパッケージでは、IPv4射影IPv6アドレスまたはサブネットは、IPv4ネイティブ・アドレスまたはサブネットと同等であるとみなします。たとえば、::ffff:192.0.2.1は192.0.2.1と同等で、::ffff:192.0.2.1/120は192.0.2.*と同等です。

複数のアクセス制御リスト割当てでのホスト・コンピュータの優先順位

ホスト・コンピュータとそのドメインに割り当てられている複数のアクセス制御リストでは、ホスト・コンピュータに割り当てられているアクセス制御リストが、ドメインに割り当てられているアクセス制御リストよりも優先されます。ドメインに割り当てられているアクセス制御リストの優先順位は、サブ・ドメインに割り当てられているアクセス制御リストの優先順位よりも低くなります。

たとえば、ホストserver.us.example.comに割り当てられているアクセス制御リストが、そのドメインに割り当てられている他のアクセス制御リストに先行して最初に選択されます。追加のアクセス制御リストがサブ・ドメインに割り当てられていた場合、優先順位は次のようになります。

1. server.us.example.com

2. *.us.example.com

3. *.example.com

4. *.com

5. *

同様に、IPアドレス(IPv4とIPv6の両方)とIPアドレスが所属するサブネットに割り当てられている複数のアクセス制御リストでは、IPアドレスに割り当てられているアクセス制御リストが、サブネットに割り当てられているアクセス制御リストよりも優先されます。サブネットに割り当てられているアクセス制御リストの優先順位は、サブネットに含まれる小さいサブネットに割り当てられているアクセス制御リストの優先順位よりも低くなります。

たとえば、IPアドレス192.0.2.3に割り当てられているアクセス制御リストが、そのIPアドレスが所属するサブネットに割り当てられている他のアクセス制御リストに先行して最初に選択されます。追加のアクセス制御リストがサブネットに割り当てられていた場合、優先順位は次のようになります。

1. 192.0.2.3(または::ffff:192.0.2.3)

2. 192.0.2.3/31(または::ffff:192.0.2.3/127)

3. 192.0.2.3/30(または::ffff:192.0.2.3/126)

4. 192.0.2.3/29(または::ffff:192.0.2.3/125)

5. ...

6. 192.0.2.3/24(または::ffff:192.0.2.3/120または192.0.2.*)

7. ...

8. 192.0.2.3/16(または::ffff:192.0.2.3/112または192.0.*)

9. ...

10. 192.0.2.3/8(または::ffff:192.0.2.3/104または192.*)

11. ...

12. ::ffff:192.0.2.3/95

13. ::ffff:192.0.2.3/94

14. ...

15. *

ポート範囲指定によるアクセス制御リスト割当てでのホストの優先順位

ポート範囲の指定があるアクセス制御リストがホスト・コンピュータ、ドメインまたはIPサブネットに割り当てられている場合、そのアクセス制御リストは、同じホスト、ドメインまたはIPサブネットに割り当てられているポート範囲の指定がないアクセス制御リストよりも優先されます。

たとえば、server.us.example.comのポート80から99のいずれかのポートへのTCP接続では、ポート範囲外のserver.us.example.comに割り当てられている他のアクセス制御リストに先行して、server.us.example.comでポート80から99が割り当てられているアクセス制御リストが最初に選択されます。

ネットワーク・ホストへのユーザー・アクセスに影響を与える権限割当てのチェック

データベース管理者は、DBA_NETWORK_ACL_PRIVILEGESデータ・ディクショナリ・ビューを使用して、アクセス制御リストでデータベース・ユーザーまたはロールに対して付与または拒否したネットワーク権限を問い合せ、それらの権限が特定の期間のみ有効かどうかを問い合せることができます。現時点でユーザーに権限が付与されているかどうか、ユーザーに割り当てられているロール、アクセス制御エントリの順序などを判断するために、ビューで提供される情報を使用したデータの組合せが必要になる場合があります。このような権限の評価を簡素化するために、次のDBMS_NETWORK_ACL_ADMINファンクションを使用して、アクセス制御リストでユーザーに付与した権限をチェックできます。

- CHECK_PRIVILEGE: アクセス制御リストで、指定された権限が指定のユーザーに対して付与されているか、拒否されているかどうかをチェックします。このプロシージャは、アクセス制御リストをXML DBリポジトリ内のパスで識別します。パスが判明している単一のアクセス制御リストを評価する場合は、CHECK_PRIVILEGEを使用します。

- CHECK_PRIVILEGE_ACLID: アクセス制御リストのオブジェクトIDを指定できること以外は、CHECK_PRIVILEGEプロシージャと同じです。CHECK_PRIVILEGE_ACLIDデータ・ディクショナリ・ビューを問い合せる際に複数のアクセス制御リストを評価する必要がある場合は、DBA_NETWORK_ACLSを使用します。各アクセス制御リストについてCHECK_PRIVILEGEを個別に使用するよりも、複数のアクセス制御リストについてCHECK_PRIVILEGE_ACLIDをコールするほうが高いパフォーマンスを確保できます。

データベース管理者権限のないユーザーには、アクセス制御リストにアクセスしたり、DBMS_NETWORK_ACL_ADMINの各ファンクションを起動する権限はありません。ただし、データベース管理者権限のないユーザーは、USER_NETWORK_ACL_PRIVILEGESデータ・ディクショナリ・ビューを問い合せて各自の権限をチェックすることはできます。

データベース管理者とユーザーは、次のDBMS_NETWORK_ACL_UTILITYファンクションを使用して、2つのホスト、ドメインまたはサブネットが同じかどうか、あるいはホスト、ドメインまたはサブネットが他のホスト、ドメインまたはサブネットと同じ、または他のホスト、ドメインまたはサブネットに含まれるかどうか、を判断します。

- EQUALS_HOST: 2つのホスト、ドメインまたはサブネットが同じかどうかを示す値を戻します。

- CONTAINS_HOST: ホスト、ドメインまたはサブネットが他のホスト、ドメインまたはサブネットと同じかどうか、または他のホスト、ドメインまたはサブネットに含まれるかどうかを示す値を示します。また、ACL割当てのために、含まれているドメインまたはサブネットの相対的な優先順位も示します。

IPv6アドレスを使用しない場合、データベース管理者およびユーザーは、次のDBMS_NETWORK_ACL_UTILITYファンクションを使用して、ホストが所属しているドメインまたはIPv4サブネットのリストを生成し、ホストの割当てに従って優先順位別にアクセス制御リストをソートできます。

- DOMAINS: アクセス制御リストが、指定のネットワーク・ホスト、サブドメインまたはIPサブネットに対する権限に影響を与える可能性があるドメインまたはIPサブネットのリストを戻します。

- DOMAIN_LEVEL: 指定のホストのドメイン・レベルを戻します。

次の各項では、ユーザーがネットワーク・ホストに接続したり、ドメイン名を解決する際に必要な権限について、データベース管理者およびユーザーがチェックする方法を説明します。

- DBAによるユーザーのネットワーク接続およびドメインに対する権限のチェック方法

- ユーザーによる各自のネットワーク接続およびドメインに対する権限のチェック方法

DBAによるユーザーのネットワーク接続およびドメインに対する権限のチェック方法

データベース管理者は、DBA_NETWORK_ACLSビューを問い合せて、指定のホスト・コンピュータについてアクセス制御リストがあるかどうかを判断できます。このビューには、ネットワーク接続またはドメインへのアクセスを決定するアクセス制御リストが表示され、各アクセス制御リストについて、ユーザーのアクセス権限が付与されている(GRANTED)か、拒否されている(DENIED)か、あるいは適用外(NULL)かを確認できます。このビューの問合せを実行できるのは、データベース管理者のみです。

次の各項では、データベース管理者による、ネットワーク接続とドメイン名解決に関するユーザー権限のチェック方法について例を示します。

- データベース管理者によるユーザーの接続権限のチェック

- データベース管理者によるユーザーのドメイン名解決権限のチェック

データベース管理者によるユーザーの接続権限のチェック

例4-25は、ユーザーprestonによるwww.us.example.comへの接続について、データベース管理者がユーザーの権限をチェックする方法を示しています。CHECK_PRIVILEGE_ACLIDプロシージャのuserパラメータに入力するユーザー名は、大/小文字が区別されることに注意してださい。この例では、ユーザー名prestonというユーザー名は正しい入力ですが、Prestonおよびprestonは誤りとなります。

次のように、DBA_USERSデータ・ディクショナリ・ビューを問い合せることで、現行のデータベース・インスタンス内のユーザーを確認できます。

SELECT USERNAME FROM DBA_USERS;

例4-25 管理者によるネットワーク・ホスト接続に関するユーザー権限のチェック

SELECT HOST, LOWER_PORT, UPPER_PORT, ACL,
DECODE(
DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE_ACLID(ACLID, 'PRESTON',
'connect'),
1, 'GRANTED', 0, 'DENIED', NULL) PRIVILEGE
FROM (SELECT HOST, LOWER_PORT, UPPER_PORT, ACL, ACLID,
DBMS_NETWORK_ACL_UTILITY.CONTAINS_HOST('www.us.example.com',
HOST) PRECEDENCE
FROM DBA_NETWORK_ACLS)
WHERE PRECEDENCE IS NOT NULL
ORDER BY PRECEDENCE DESC,
LOWER_PORT NULLS LAST,
UPPER_PORT NULLS LAST;

HOST                 LOWER_PORT UPPER_PORT ACL                  PRIVILEGE
-------------------- ---------- ---------- -------------------- ---------
www.us.example.com           80         80 /sys/acls/www.xml    GRANTED
www.us.example.com         3000       3999 /sys/acls/www.xml    GRANTED
www.us.example.com                         /sys/acls/www.xml    GRANTED
*.example.com                              /sys/acls/all.xml
*                                          /sys/acls/all.xml

この例では、ユーザーprestonにはwww.us.example.comで見つかったすべてのネットワーク・ホスト接続の権限が付与されました。ところが、prestonはポート80でのホスト接続へのアクセス権を付与されたが、ポート3000から3999でのホスト接続へのアクセス権を拒否されたと仮定します。この場合は、ポート80でのホスト接続のために1つのアクセス制御リストを作成し、ポート3000から3999でのホスト接続のために別個のアクセス制御リストを作成する必要があります。

データベース管理者によるユーザーのドメイン名解決権限のチェック

例4-26は、ユーザーprestonによるホストwww.us.example.comのドメイン名の解決について、データベース管理者がユーザーの権限をチェックする方法を示しています。この例では、ポート範囲を指定せずにホストに割り当てられているアクセス制御リストのみが表示されています。これは、resolve権限はポート範囲が指定されているアクセス制御リストでは無効なためです。(CHECK_PRIVILEGE_ACLIDのuserパラメータに入力するユーザー名は、大/小文字が区別されることに注意してください。)

例4-26 管理者によるドメイン名解決権限のチェック

SELECT HOST, ACL,
DECODE(
DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE_ACLID(ACLID, 'PRESTON',
'resolve'),
1, 'GRANTED', 0, 'DENIED', NULL) PRIVILEGE
FROM (SELECT HOST, LOWER_PORT, UPPER_PORT, ACL, ACLID,
DBMS_NETWORK_ACL_UTILITY.CONTAINS_HOST('www.us.example.com',
HOST) PRECEDENCE
FROM DBA_NETWORK_ACLS
WHERE LOWER_PORT IS NULL AND UPPER_PORT IS NULL)
WHERE PRECEDENCE IS NOT NULL
ORDER BY PRECEDENCE DESC;

HOST                 ACL                  PRIVILEGE
-------------------- -------------------- ---------

www.us.example.com   /sys/acls/www.xml    GRANTED
*.example.com        /sys/acls/all.xml
*                    /sys/acls/all.xml

ユーザーによる各自のネットワーク接続およびドメインに対する権限のチェック方法

ユーザーはUSER_NETWORK_ACL_PRIVILEGESビューを問い合せて、自分のネットワークおよびドメインの権限を調べることができます。USER_NETWORK_ACL_PRIVILEGESビューはPUBLICであるため、すべてのユーザーがそこから選択できます。

このビューでは、アクセス制御リストはユーザーに表示されません。このビューでユーザーの権限ステータスが判定され(GRANTEDまたはDENIED)、NULLの場合、ユーザーはアクセス制御リストが自分に適用されないときは知る必要がないため、除外されます。言い換えるとOracle Databaseが提示するのは、Oracle Databaseによってアクセス権が明示的に付与または拒否されるネットワーク・ホスト上のユーザーのみです。そのため出力には、データベース管理者固有のDBA_NETWORK_ACLSビューからの出力に見られる*.example.comおよび*は表示されません。

次の各項では、データベース管理者による、ネットワーク接続とドメイン名解決に関するユーザー権限のチェック方法について例を示します。

- ユーザーによる各自のネットワーク接続権限のチェック

- ユーザーによる各自のドメイン名解決権限のチェック

ユーザーによる各自のネットワーク接続権限のチェック

例4-27は、ユーザーprestonが、www.us.example.comへの接続について、自分の権限をチェックする方法を示しています。

例4-27 ユーザーによるネットワーク・ホスト接続に関する権限のチェック

SELECT HOST, LOWER_PORT, UPPER_PORT, STATUS PRIVILEGE
FROM (SELECT HOST, LOWER_PORT, UPPER_PORT, STATUS,
DBMS_NETWORK_ACL_UTILITY.CONTAINS_HOST('www.us.example.com',
HOST) PRECEDENCE
FROM USER_NETWORK_ACL_PRIVILEGES
WHERE PRIVILEGE = 'connect')
WHERE PRECEDENCE IS NOT NULL
ORDER BY PRECEDENCE DESC,
LOWER_PORT NULLS LAST,
UPPER_PORT NULLS LAST;

HOST                 LOWER_PORT UPPER_PORT ACL                  PRIVILEGE
-------------------- ---------- ---------- -------------------- ---------
www.us.example.com           80         80 /sys/acls/www.xml    GRANTED
www.us.example.com         3000       3999 /sys/acls/www.xml    GRANTED
www.us.example.com                         /sys/acls/www.xml    GRANTED

ユーザーによる各自のドメイン名解決権限のチェック

例4-26は、ユーザーprestonが、www.us.example.comのドメイン名の解決について、自分の権限をチェックする方法を示しています。

例4-28 ユーザーによるドメイン名解決権限のチェック

SELECT HOST, STATUS PRIVILEGE
from (SELECT HOST, STATUS,
DBMS_NETWORK_ACL_UTILITY.CONTAINS_HOST('www.us.example.com',
HOST) PRECEDENCE
FROM USER_NETWORK_ACL_PRIVILEGES
WHERE PRIVILEGE = 'resolve' AND
LOWER_PORT IS NULL AND UPPER_PORT IS NULL)
WHERE PRECEDENCE IS NOT NULL
ORDER BY PRECEDENCE DESC;

HOST                 PRIVILEGE
-------------------- ---------
www.us.example.com   GRANTED

単一アクセス制御リスト内の複数のユーザーとロールに対する優先順位の設定

デフォルトでは、ユーザーとロールに対する権限は、そのユーザーとロールのアクセス制御リスト内での物理的な位置に基づいて付与または拒否されます。1番目にリストされているユーザーまたはロールに対して権限が最初に付与または拒否され、2番目にリストされているユーザーまたはロールが次に処理され、その後も順に処理されます。たとえば、例4-20のコードでACCT_MGRというロールと、sebastianおよびprestonという2人のユーザーが定義され、次の順序でアクセス制御リストXMLファイルに記載されているとします。

<acl ...>
...
<ace>
<principal>ACCT_MGR</principal>
<grant>true</grant>
<privilege><plsql:connect/></privilege>
</ace>
<ace>
<principal>SEBASTIAN</principal>
<grant>false</grant>
<privilege><plsql:connect/></privilege>
</ace>
<ace>
<principal>PRESTON</principal>
<grant>false</grant>
<privilege><plsql:connect/></privilege>
</ace>
</acl>

最初にACCT_MGRに権限が付与され、次にsebastianへの権限が拒否され、その後prestonへの権限が拒否されます。ただし、sebastianとprestonにACCT_MGRロールが付与されている場合は、そのACCT_MGRロールがリストの最初に記載されるため、この2人のユーザーはログインできます。

この2人のユーザーにはacct_mgrロールが付与されていますが、それぞれの固有のジョブでは、www.example.comホストに対するアクセス権は不要です。位置が逆の場合(sebastianとprestonの後にacct_mgrロールが記載されている場合)は、これらのユーザーに対するネットワーク接続権限は拒否されることになります。CREATE_ACL文およびADD_PRIVILEGE文で、ACE要素の物理的な位置に関係なく優先順位を設定するには、position属性を使用します。

たとえば、次の文では、結果のXMLファイルにACE要素が設定される順序は、次のようになります。

1. 最初にsebastianのACE要素が記載されます。

2. 次にprestonのACE要素が記載されます。

3. 最後にacct_mgrロールが記載されます。

この場合、FALSEに設定されている2人の付与権限はacct_mgrロールより前に評価されるため、いずれのユーザーも接続できません。

BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
acl          => 'us-example-com-permissions.xml',
description  => 'Network connection permission for ACCT_MGR and users',
principal    => 'ACCT_MGR',
is_grant     => TRUE,
privilege    => 'connect');
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE (
acl          => 'us-example-com-permissions.xml',
principal    => 'SEBASTIAN',
is_grant     => FALSE,
privilege    => 'connect',
position     => 1);
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE (
acl          => 'us-example-com-permissions.xml',
principal    => 'PRESTON',
is_grant     => FALSE,
privilege    => 'connect',
position     => 2);
END;
/

ユーザー・アクセス用に構成されたアクセス制御リストに関する情報の検索

表4-6に、既存のアクセス制御リストに関する情報の検索に使用できるデータ・ディクショナリ・ビューをリストします。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表4-6 アクセス制御リストに関する情報を表示するデータ・ディクショナリ・ビュー

ビュー

説明

DBA_NETWORK_ACLS

ネットワーク・ホストに対するアクセス制御リスト割当てが表示されます。このビューのSELECT権限は、SELECT_CATALOG_ROLEロールのみに付与されます。

DBA_NETWORK_ACL_PRIVILEGES

ネットワーク・ホストに現在割り当てられ、すべてのアクセス制御リストに定義されているネットワーク権限が表示されます。このビューのSELECT権限は、SELECT_CATALOG_ROLEロールのみに付与されます。

DBA_WALLET_ACLS

アクセス制御リストが割り当てられているウォレットが表示されます。

USER_NETWORK_ACL_PRIVILEGES

現行ユーザーがネットワーク・ホストにアクセスするためのネットワーク権限のステータスが表示されます。このビューのSELECT権限はPUBLICに付与されます。

ユーザー権限とロールに関する情報の検索

表4-7に、権限とロールの付与に関する情報を入手するために問合せ可能なデータ・ディクショナリ・ビューをリストします。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表4-7 権限とロールに関する情報を表示するデータ・ディクショナリ・ビュー

ビュー

説明

ALL_COL_PRIVS

オブジェクト所有者、権限付与者または権限受領者が現行ユーザーまたはPUBLICである列オブジェクトの権限付与がすべて表示されます。

ALL_COL_PRIVS_MADE

オブジェクト所有者または権限付与者が現行ユーザーである列オブジェクトの権限付与がリストされます。

ALL_COL_PRIVS_RECD

権限受領者が現行ユーザーまたはPUBLICである列オブジェクトの権限付与が表示されます。

ALL_TAB_PRIVS

権限受領者がユーザーまたはPUBLICであるオブジェクトの権限付与がリストされます。

ALL_TAB_PRIVS_MADE

現行ユーザーが行ったオブジェクトの権限付与、または現行ユーザーが所有するオブジェクトに対する権限付与がすべてリストされます。

ALL_TAB_PRIVS_RECD

権限受領者がユーザーまたはPUBLICであるオブジェクトの権限付与がリストされます。

DBA_COL_PRIVS

データベース内の列オブジェクトの権限付与がすべて表示されます。

DBA_EPG_DAD_AUTHORIZATION

別のユーザー権限の使用が許可されたデータベース・アクセス記述子(DAD)が表示されます。

DBA_TAB_PRIVS

データベース内のすべてのオブジェクトに対するすべての権限付与がリストされます。

DBA_ROLES

セキュア・アプリケーション・ロールを含めて、データベース内に存在するすべてのロールがリストされます。

DBA_ROLE_PRIVS

ユーザーとロールに直接付与されているロールがリストされます。PUBLICロールはリストされません。

DBA_SYS_PRIVS

ユーザーとロールに付与されているシステム権限がリストされます。

ROLE_ROLE_PRIVS

他のロールに付与されているロールがリストされます。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。

ROLE_SYS_PRIVS

ロールに付与されているシステム権限がリストされます。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。

ROLE_TAB_PRIVS

ロールに付与されているオブジェクト権限がリストされます。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。

SESSION_PRIVS

ユーザーに対して現在使用可能になっている権限がリストされます。

SESSION_ROLES

現在のユーザーに対して使用可能になっているすべてのロールがリストされます。PUBLICロールはリストされません。

USER_COL_PRIVS

オブジェクト所有者、権限付与者または権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。

USER_COL_PRIVS_MADE

オブジェクト所有者が現行ユーザーである列オブジェクトの権限付与が表示されます。

USER_COL_PRIVS_RECD

権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。

USER_EPG_DAD_AUTHORIZATION

別のユーザー権限の使用が許可されたデータベース・アクセス記述子(DAD)が表示されます。

USER_ROLE_PRIVS

現行ユーザーに直接付与されているロールがリストされます。

USER_TAB_PRIVS

権限受領者が現行ユーザーであるすべてのオブジェクトの権限付与がリストされます。

USER_SYS_PRIVS

現行ユーザーに付与されているシステム権限がリストされます。

USER_TAB_PRIVS_MADE

現行ユーザーが所有しているすべてのオブジェクトの権限付与がリストされます。

USER_TAB_PRIVS_RECD

権限受領者が現行ユーザーであるオブジェクトの権限付与がリストされます。

ここでは、これらのビューの使用例をいくつか示します。各例では、次の文がすでに発行されていることを前提としています。

CREATE ROLE security_admin IDENTIFIED BY password;

GRANT CREATE PROFILE, ALTER PROFILE, DROP PROFILE,
CREATE ROLE, DROP ANY ROLE, GRANT ANY ROLE, AUDIT ANY,
AUDIT SYSTEM, CREATE USER, BECOME USER, ALTER USER, DROP USER
TO security_admin WITH ADMIN OPTION;

GRANT SELECT, DELETE ON SYS.AUD$ TO security_admin;

GRANT security_admin, CREATE SESSION TO swilliams;

GRANT security_admin TO system_administrator;

GRANT CREATE SESSION TO jward;

GRANT SELECT, DELETE ON emp TO jward;

GRANT INSERT (ename, job) ON emp TO swilliams, jward;

関連項目:
これらのデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

付与されているすべてのシステム権限のリスト

次の問合せを実行すると、ロールとユーザーに対して付与されているシステム権限がすべて表示されます。

SELECT * FROM DBA_SYS_PRIVS;

GRANTEE            PRIVILEGE                         ADM
--------------     --------------------------------- ---
SECURITY_ADMIN     ALTER PROFILE                     YES
SECURITY_ADMIN     ALTER USER                        YES
SECURITY_ADMIN     AUDIT ANY                         YES
SECURITY_ADMIN     AUDIT SYSTEM                      YES
SECURITY_ADMIN     BECOME USER                       YES
SECURITY_ADMIN     CREATE PROFILE                    YES
SECURITY_ADMIN     CREATE ROLE                       YES
SECURITY_ADMIN     CREATE USER                       YES
SECURITY_ADMIN     DROP ANY ROLE                     YES
SECURITY_ADMIN     DROP PROFILE                      YES
SECURITY_ADMIN     DROP USER                         YES
SECURITY_ADMIN     GRANT ANY ROLE                    YES
SWILLIAMS          CREATE SESSION                    NO
JWARD              CREATE SESSION                    NO

DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

付与されているすべてのロールのリスト

次の問合せを実行すると、ユーザーと他のロールに対して付与されているロールがすべて表示されます。

SELECT * FROM DBA_ROLE_PRIVS;

GRANTEE            GRANTED_ROLE                         ADM
------------------ ------------------------------------ ---
SWILLIAMS          SECURITY_ADMIN                       NO

DBA_ROLE_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ユーザーに付与されているオブジェクト権限のリスト

次の問合せを実行すると、特定のユーザーに対して付与されているオブジェクト権限(列固有の権限を除く)がすべて表示されます。

SELECT TABLE_NAME, PRIVILEGE, GRANTABLE FROM DBA_TAB_PRIVS
WHERE GRANTEE = 'jward';

TABLE_NAME   PRIVILEGE    GRANTABLE
-----------  ------------ ----------
EMP          SELECT       NO
EMP          DELETE       NO

付与されている列固有の権限をすべて表示するには、次の問合せを使用します。

SELECT GRANTEE, TABLE_NAME, COLUMN_NAME, PRIVILEGE
FROM DBA_COL_PRIVS;

GRANTEE      TABLE_NAME     COLUMN_NAME      PRIVILEGE
-----------  ------------   -------------    --------------
SWILLIAMS    EMP            ENAME            INSERT
SWILLIAMS    EMP            JOB              INSERT
JWARD        EMP            NAME             INSERT
JWARD        EMP            JOB              INSERT

DBA_TAB_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

セッションの現在の権限ドメインのリスト

次の問合せを実行すると、発行者が現在使用できるロールがすべてリストされます。

SELECT * FROM SESSION_ROLES;

ユーザーswilliamsに対してsecurity_adminロールが使用可能になっている場合に、この問合せを実行すると、Oracle Databaseから次の情報が戻されます。

ROLE
------------------------------
SECURITY_ADMIN

次の問合せを実行すると、発行者のセキュリティ・ドメインで現在使用可能なシステム権限がすべて表示されます。これには、明示的に付与されている権限と使用可能なロールから付与された権限の両方が含まれています。

SELECT * FROM SESSION_PRIVS;

ユーザーswilliamsに対してsecurity_adminロールが使用可能になっている場合に、この問合せを実行すると、Oracle Databaseから次の結果が戻されます。

PRIVILEGE
----------------------------------------
AUDIT SYSTEM
CREATE SESSION
CREATE USER
BECOME USER
ALTER USER
DROP USER
CREATE ROLE
DROP ANY ROLE
GRANT ANY ROLE
AUDIT ANY
CREATE PROFILE
ALTER PROFILE
DROP PROFILE

ユーザーswilliamsに対してsecurity_adminロールが使用禁止になっている場合、最初の問合せでは何も表示されず、2番目の問合せではCREATE SESSION権限の付与に関する行が1行のみ表示されます。

SESSION_ROLESビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

データベースのロールのリスト

DBA_ROLESデータ・ディクショナリ・ビューを使用すると、データベースのすべてのロールと各ロールに対して使用されている認証を表示できます。たとえば、次の問合せを実行すると、データベース内のすべてのロールが表示されます。

SELECT * FROM DBA_ROLES;

ROLE                  PASSWORD
----------------      --------
CONNECT               NO
RESOURCE              NO
DBA                   NO
SECURITY_ADMIN        YES

DBA_ROLESビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ロールの権限ドメイン情報のリスト

ROLE_ROLE_PRIVS、ROLE_SYS_PRIVSおよびROLE_TAB_PRIVSの各データ・ディクショナリ・ビューには、ロールの権限ドメインに関する情報が含まれています。たとえば、次の問合せを実行すると、system_adminロールに付与されているロールがすべて表示されます。

SELECT GRANTED_ROLE, ADMIN_OPTION
FROM ROLE_ROLE_PRIVS
WHERE ROLE = 'SYSTEM_ADMIN';

GRANTED_ROLE              ADM
----------------          ----
SECURITY_ADMIN            NO

次の問合せを実行すると、security_adminロールに付与されているシステム権限がすべて表示されます。

SELECT * FROM ROLE_SYS_PRIVS WHERE ROLE = 'SECURITY_ADMIN';

ROLE                    PRIVILEGE                      ADM
----------------------- -----------------------------  ---
SECURITY_ADMIN           ALTER PROFILE                 YES
SECURITY_ADMIN           ALTER USER                    YES
SECURITY_ADMIN           AUDIT ANY                     YES
SECURITY_ADMIN           AUDIT SYSTEM                  YES
SECURITY_ADMIN           BECOME USER                   YES
SECURITY_ADMIN           CREATE PROFILE                YES
SECURITY_ADMIN           CREATE ROLE                   YES
SECURITY_ADMIN           CREATE USER                   YES
SECURITY_ADMIN           DROP ANY ROLE                 YES
SECURITY_ADMIN           DROP PROFILE                  YES
SECURITY_ADMIN           DROP USER                     YES
SECURITY_ADMIN           GRANT ANY ROLE                YES

次の問合せを実行すると、security_adminロールに付与されているオブジェクト権限がすべて表示されます。

SELECT TABLE_NAME, PRIVILEGE FROM ROLE_TAB_PRIVS
WHERE ROLE = 'SECURITY_ADMIN';

TABLE_NAME                     PRIVILEGE
---------------------------    ----------------
AUD$                           DELETE
AUD$                           SELECT

ROLE_ROLE_PRIVS、ROLE_SYS_PRIVSおよびROLE_TAB_PRIVSの各ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

5 アプリケーション開発者のセキュリティの管理

この章の内容は、次のとおりです。

- アプリケーション・セキュリティ・ポリシーの概要

- アプリケーション・ベースのセキュリティの使用に関する考慮事項

- アプリケーション設計におけるパスワードの保護

- アプリケーション権限の管理

- アプリケーションへのアクセスを制御するセキュア・アプリケーション・ロールの作成

- 権限とユーザー・データベース・ロールの関連付け

- スキーマを使用したデータベース・オブジェクトの保護

- アプリケーションでのオブジェクト権限の管理

- データベース通信のセキュリティを強化するためのパラメータ

アプリケーション・セキュリティ・ポリシーの概要

安全なデータベース・アプリケーションを作成する最初のステップは、アプリケーション・セキュリティ・ポリシーの作成です。アプリケーション・セキュリティ・ポリシーは、アプリケーション・セキュリティの要件およびデータベース・オブジェクトへのユーザー・アクセスを規制するルールのリストです。

セキュリティ・ポリシーは、データベース・アプリケーションごとに立案する必要があります。たとえば、各データベース・アプリケーションには、アプリケーションの実行時に異なるレベルのセキュリティを提供する1つ以上のデータベース・ロールが必要です。データベース・ロールは、他のロールに付与するか、または特定のユーザーに直接付与できます。

(SQL*PlusやSQL Developerなどのツールを使用して)SQL文を制限なしで処理できるアプリケーションの場合でも、機密扱いのスキーマ・オブジェクトや重要なスキーマ・オブジェクトへの不当なアクセスを防ぐために、セキュリティ・ポリシーが必要です。特に、使用するアプリケーションでパスワードが安全に処理されることを確認する必要があります。

次の各項では、安全なデータベース・アプリケーションの計画と開発に使用できる、アプリケーション・セキュリティとOracle Databaseの機能について説明します。

アプリケーション・ベースのセキュリティの使用に関する考慮事項

アプリケーション・セキュリティを構築および実装する際の2つの主な課題を、次の各項で説明します。

- アプリケーション・ユーザーはデータベース・ユーザーでもあるか

- アプリケーション内またはデータベース内でのセキュリティ規定

アプリケーション・ユーザーはデータベース・ユーザーでもあるか

できるかぎり、アプリケーション・ユーザーがデータベース・ユーザーであるアプリケーションを作成する必要があります。これによって、データベースに本来備わっているセキュリティ・メカニズムを活用できます。

多くの市販のパッケージ・アプリケーションでは、アプリケーション・ユーザーは、データベース・ユーザーではありません。これらのアプリケーションでは、複数のユーザーがユーザー自身をアプリケーションに対して認証し、次に、アプリケーションが単一の高い権限を持つユーザーとしてデータベースに接続します。これを、One Big Application Userモデルと呼びます。

この方法で作成されたアプリケーションは、通常、データベースに本来備わっているセキュリティ機能の多くを使用できません。これは、ユーザーの識別情報がデータベースで認識されないためです。

表5-1では、One Big Application Userモデルが様々なOracle Databaseセキュリティ機能にどのように影響するかを説明します。

表5-1 One Big Application Userモデルの影響を受ける機能

Oracle Database機能

One Big Application Userモデルの制限

監査

セキュリティの基本原則の1つは、監査によるアカウンタビリティです。One Big Application Userがデータベース内のすべての操作を実行する場合、データベース監査では、個々のユーザーが実行したアクションに対する責任をそのユーザー自身に持たせることができません。アプリケーションでは、独自の監査メカニズムを実装して、ユーザーのアクションを個別に捕捉する必要があります。

Oracle Advanced Securityの拡張認証

データベースに対するクライアントの認証が、個々のユーザーではなくアプリケーションの場合、Oracle Advanced Securityでサポートされている認証の厳密な形式(たとえば、SSLやトークンなどでのクライアント認証)は使用できません。

ロール

ロールは、データベース・ユーザーに割り当てられます。エンタープライズ・ロールは、データベース内で作成されていない場合でも、エンタープライズ・ユーザーに割り当てられ、データベースに認識されます。アプリケーション・ユーザーがデータベース・ユーザーではない場合、ロールの有用性は低くなります。この場合、アプリケーションでは独自のメカニズムを作成して、様々なアプリケーション・ユーザーがアプリケーション内のデータへアクセスするのに必要とする権限を識別する必要があります。

Oracle Advanced Securityのエンタープライズ・ユーザー管理機能

エンタープライズ・ユーザー管理機能は、Oracle Internet DirectoryなどのLDAPベースのディレクトリにユーザー情報を安全に格納して認可を管理することで、OracleデータベースがOracle Identity Managementインフラストラクチャを使用できるようにします。エンタープライズ・ユーザーは、データベース内に作成する必要はありませんが、データベースに認識される必要があります。One Big Application Userモデルでは、Oracle Identity Managementを利用できません。

アプリケーション内またはデータベース内でのセキュリティ規定

ユーザーがデータベース・ユーザーでもあるアプリケーションは、アプリケーションの中にセキュリティを組み込むか、きめ細かい権限、仮想プライベート・データベース(アプリケーション・コンテキストによるファイングレイン・アクセス・コントロール)、ロール、ストアド・プロシージャ、および監査(ファイングレイン監査を含む)などのデータベースに本来備わっているセキュリティ・メカニズムを使用できます。アプリケーションでできるだけ多くのデータベース・セキュリティ・メカニズムが使用されるようにすることをお薦めします。

セキュリティがアプリケーション内ではなくデータベース自体で規定されている場合は、セキュリティを回避することはできません。アプリケーション・ベースのセキュリティの主なデメリットは、ユーザーがアプリケーションを回避してデータにアクセスすると、セキュリティが回避されることです。たとえば、データベースへのSQL*Plusアクセス権を持つユーザーは、人事管理アプリケーションを介さずに問合せを実行できます。したがって、このユーザーは、アプリケーション内のセキュリティ対策のすべてをバイパスします。

One Big Application Userモデルを使用するアプリケーションでは、データベースのセキュリティ・メカニズムを使用せずに、アプリケーション内にセキュリティ規定を作成する必要があります。ユーザーを認識するのは、データベースではなくアプリケーションであるため、アプリケーション自体が各ユーザーに対してセキュリティ対策を規定する必要があります。

このアプローチでは、データにアクセスする各アプリケーションでのセキュリティの再実装が必要になります。組織では複数のアプリケーションに同じセキュリティ・ポリシーを実装する必要があるため、セキュリティが高コストになり、新規アプリケーションごとに高コストな再実装が必要になります。

関連項目:
「セキュリティに関する潜在的な問題となる非定型ツールの使用」

アプリケーション設計におけるパスワードの保護

この項では、バッチ・ジョブ、スクリプト、インストール・ファイルまたはアプリケーションからパスワードで保護されたサービスを安全に起動する戦略について説明します。パスワード保護に加えて、これらの戦略の多くはその他の機密データ(暗号化鍵など)に適用できます。

この項の内容は、次のとおりです。

- アプリケーションでのパスワードの保護に関する一般的なガイドライン

- 外部パスワード・ストアを使用したパスワードの保護

- orapwdユーティリティを使用したパスワードの保護

- Javaでのパスワード読取り例

関連項目:

- 「パスワードの最低要件」

- Oracleデータベースの保護に関する一般的なガイドラインについては、第10章「Oracle Databaseの安全性の維持」を参照してください。

アプリケーションでのパスワードの保護に関する一般的なガイドライン

これらのガイドラインは次のカテゴリに分類されます。

- プラットフォーム固有のセキュリティへの脅威

- パスワード入力を処理するアプリケーションの設計

- パスワードの形式と動作の構成

- SQL*PlusおよびSQLスクリプトにおけるパスワードの処理

プラットフォーム固有のセキュリティへの脅威

次の潜在的なセキュリティへの脅威は、わかりにくい可能性があるので注意してください。

- UNIXおよびLinuxプラットフォームでは、同じホスト・コンピュータ上のすべてのオペレーティング・システム・ユーザーがコマンド・パラメータを表示できます。結果として、コマンドラインに入力したパスワードは他のユーザーに公開される可能性があります。ただし、UNIXおよびLinux以外のプラットフォームがこの脅威を回避できるとは考えないでください。

- HP Tru64およびIBM AIXなど一部のUNIXプラットフォームでは、すべてのオペレーティング・システム・ユーザーがあらゆるプロセスの環境変数を表示できます。ただし、UNIXおよびLinux以外のプラットフォームがこの脅威を回避できるとは考えないでください。

- Microsoft Windowsでは、コマンド・リコール機能(上矢印)に、コマンド起動間のユーザー入力が記憶されます。たとえば、SQL*PlusのCONNECT SYSTEM/password表記法を使用し、終了してから上矢印を押してCONNECTコマンドを繰り返した場合、コマンド・リコール機能により接続文字列が明らかになり、パスワードが表示されます。また、Microsoft Windows以外のプラットフォームがこの脅威を回避できるとは考えないでください。

パスワード入力を処理するアプリケーションの設計

次のガイドラインに従ってください。

- パスワードの入力を対話形式で求めるアプリケーションを設計します。コマンドライン・ユーティリティの場合、コマンド・プロンプトでパスワードを公開することをユーザーに強制しないでください。
アプリケーションの設計に使用するプログラミング言語のAPIについて、ユーザーからのパスワードを処理する最適な方法を確認します。この機能を処理するJavaコードの例については、「Javaでのパスワード読取り例」を参照してください。

- SQLインジェクション攻撃からデータベースを保護します。SQLインジェクション攻撃では、PL/SQLアプリケーションで想定されない方法でSQL文が追加または変更されます。たとえば、侵入者はWHERE句をTRUEに設定してパスワード認証を回避できます。
SQLインジェクション攻撃の問題に対処するには、バインド変数引数を使用するか妥当性チェックを作成します。バインド変数を使用できない場合は、DBMS_ASSERT PL/SQLパッケージを使用して入力値のプロパティを検証することを検討してください。DBMS_ASSERTパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。また、PUBLICなどのロールに対する権限付与も検討してください。

SQLインジェクションの防止の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- 可能な場合は、認証を遅延するアプリケーションを設計します。次に例を示します。

- ログインに証明書を使用します。

- オペレーティング・システムで提供される機能を使用してユーザーを認証します。たとえば、Microsoft Windows上で動作するアプリケーションはドメイン認証を使用できます。

- パスワードをマスクまたは暗号化します。パスワードを格納する必要がある場合、パスワードをマスクまたは暗号化します。たとえば、ログ・ファイルでパスワードをマスクし、リカバリ・ファイルでパスワードを暗号化できます。

- 各接続を認証します。たとえば、スキーマAがデータベース1に存在する場合、データベース2のスキーマAが同一のユーザーであるとは考えないでください。同様に、ローカル・オペレーティング・システム・ユーザーpsmithは、必ずしもリモート・ユーザーpsmithと同じユーザーではありません。

- ファイルまたはリポジトリにクリアテキスト・パスワードを格納しないでください。パスワードをファイルに格納すると、侵入者がパスワードにアクセスする危険性が高まります。

- 1つのマスター・パスワードを使用します。次に例を示します。

- 1人のデータベース・ユーザーに、他のデータベース・ユーザーとなるためのプロキシ認証を付与できます。この場合、必要となるデータベース・パスワードは1つのみです。詳細は、「プロキシ・ユーザー・アカウントの作成と、作成したプロキシ・ユーザー・アカウントを介したユーザー接続の認可」を参照してください。

- マスター・パスワードでオープンできるパスワード・ウォレットを作成できます。ウォレットにはその他のパスワードが含められます。Wallet Managerの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

パスワードの形式と動作の構成

次のガイドラインに従ってください。

- パスワードの存続期間を制限します。パスワード存続期間を設定して、その期間が過ぎるとパスワードが期限切れになり、変更しないとユーザーがアカウントにログインできなくなるようにすることができます。パスワードの存続期間を制御するために使用できるパラメータは、「パスワード・エイジングおよび期限切れの制御」を参照してください。

- ユーザーが古いパスワードを再利用する機能を制限します。詳細は、「ユーザーによる以前のパスワードの再利用の制御」を参照してください。

- 強力かつ安全なパスワードを作成するようユーザーに要求します。強力なパスワードの作成に関するガイドラインは、「パスワードの保護に関するガイドライン」を参照してください。「パスワードの複雑度検証の規定」では、パスワードの要件をカスタマイズする方法について説明しています。

- パスワードで大/小文字を区別できるようにします。詳細は、「パスワードでの大/小文字の区別の有効化または無効化」を参照してください。

関連項目:

- 「パスワードの最低要件」

- 「パスワードの複雑度検証の規定」

- 「パスワードの保護に関するガイドライン」

SQL*PlusおよびSQLスクリプトにおけるパスワードの処理

次のガイドラインに従ってください。

- プログラムまたはスクリプトのコマンドラインにパスワードを指定してSQL*Plusを起動しないでください。パスワードが必須であるにもかかわらず省略した場合、SQL*Plusではパスワードの入力を求めるプロンプトが表示され、パスワードが表示されないようにエコー機能が自動的に無効となります。
次の各例は、パスワードがコマンドライン上で公開されないため安全です。また、Oracle Databaseではこれらのパスワードがネットワークを介して自動的に暗号化されます。

$ sqlplus system
Enter password: password

SQL> connect system
Enter password: password

次の例では、パスワードが他のオペレーティング・システム・ユーザーに公開されます。

sqlplus system/password

次の例は、2つのセキュリティ上のリスクをもたらします。1つ目の例では、覗き込んでいる可能性のある他のユーザーにパスワードを公開してしまいます。2つ目の例では、Microsoft Windowsなどの一部のプラットフォームにおいて、パスワードがコマンドラインのリコール攻撃を受けやすくなります。

$ sqlplus /nolog
SQL> connect system/password

- たとえばパスワードまたは秘密鍵を必要とするSQLスクリプトの場合、アカウントを作成したりあるアカウントでログインするには、置換変数&1、&2などの位置パラメータを使用しないでください。かわりに、ユーザーに値の入力を求めるプロンプトを表示するスクリプトを設計します。また、スクリプトから、またはスプール・モードを使用している場合に出力を表示するエコー機能を無効にする必要があります。エコー機能を無効にするには、次の設定を使用します。

SET ECHO OFF

スクリプトにより値の目的を明白にする必要があります。たとえば、値によりアカウントまたは証明書などの新しい値が設定されるかどうか、または既存のアカウントへのログインなど、値が認証されるかどうかを明白にする必要があります。

次の例は、セキュリティ上のリスクをもたらす方法でユーザーがスクリプトを起動することが回避されるため安全です。パスワードはエコーされず、スプール・ファイルに記録されません。

SET VERIFY OFF
ACCEPT user CHAR PROMPT &rsquor;Enter user to connect to: &rsquor;
ACCEPT password CHAR PROMPT &rsquor;Enter the password for that user: ' HIDE
CONNECT &user/&password

この例の説明は、次のとおりです。

- SET VERIFY OFF:は、パスワードの表示を防止します。(SET VERIFYは、置換の前後にスクリプトの各行をリストします。)SET VERIFY OFFコマンドをHIDEコマンド(3行目)と結合する方法は、パスワードおよびその他の機密入力データを非表示にする便利なテクニックです。

- ACCEPT password: ACCEPT passwordプロンプトにHIDEオプションを含めます。これによって入力パスワードのエコーが回避されます。

次の例では位置パラメータを使用しており、ユーザーがコマンドライン上でパスワードを渡すことでスクリプトを起動できるため、セキュリティ上のリスクをもたらします。ユーザーがパスワードを入力せず、入力を求めるプロンプトが表示される場合、ユーザーが入力した内容がすべて画面およびスプール・ファイル(スプールが有効な場合)にエコーされるため危険です。

CONNECT &1/&2

- バッチ・スクリプトのログイン時間を制御します。パスワードを必要とするバッチ・スクリプトでは、実行されることになっている時間内のみにバッチ・スクリプトがログインできるようにアカウントを構成します。たとえば、毎日午後8時から1時間実行するバッチ・スクリプトを想定します。この時間のみスクリプトがログインできるようにアカウントを設定します。侵入者がアクセスしようとした場合、安全性の低いアカウントが利用される可能性は低くなります。

- パスワードの入力を求めるDML文またはDDL SQL文を使用する場合は注意してください。この場合、機密情報がネットワークを介してクリアテキストで渡されます。Oracle Advanced Securityを使用してこの問題を解決できます。詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
次のパスワード変更例は、パスワードが公開されないため安全です。

password psmith
Changing password for psmith
New password: password
Retype new password: password

この例は、パスワードがコマンドラインおよびネットワーク上の両方に公開されるため、セキュリティ上のリスクをもたらします。

ALTER USER psmith IDENTIFIED BY password

外部パスワード・ストアを使用したパスワードの保護

データベースに接続するためのパスワード資格証明は、クライアント側のOracleウォレットを使用して格納できます。Oracleウォレットは、ユーザーのログインに必要な認証および署名用証明書を格納する安全性の高いソフトウェア・コンテナです。

安全性の高い外部パスワード・ストアの詳細は、「パスワード資格証明用の安全性の高い外部パスワード・ストアの管理」を参照してください。また、Oracle Wallet Managerを使用したOracleウォレットの構成方法は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

orapwdユーティリティを使用したパスワードの保護

ネットワークを介してSYSDBAまたはSYSOPER権限を使用してアプリケーションに接続する必要があるユーザーについて、パスワード・ファイルを作成できます。パスワード・ファイルを作成するには、ORAPWDユーティリティを使用します。パスワード・ファイルの作成およびメンテナンスの詳細は、『Oracle Database管理者ガイド』を参照してください。

Javaでのパスワード読取り例

例5-1では、パスワードの読取りに使用できるJavaパッケージの作成方法を示しています。

例5-1 パスワードを読み取るためのJavaコード

// Change the following line to a name for your version of this package
package passwords.sysman.emSDK.util.signing;

import java.io.IOException;
import java.io.PrintStream;
import java.io.PushbackInputStream;
import java.util.Arrays;

/**
* The static readPassword method in this class issues a password prompt
* on the console output and returns the char array password
* entered by the user on the console input.
*/
public final class ReadPassword {
//----------------------------------
/**
* Test driver for readPassword method.
* @param args the command line args
*/
public static void main(String[] args) {
char[] pass = ReadPassword.readPassword("Enter password: ");
System.out.println("The password just entered is \""
+ new String(pass) + "\"");
System.out.println("The password length is " + pass.length);
}
* Issues a password prompt on the console output and returns
* the char array password entered by the user on the console input.
* The password is not displayed on the console (chars are not echoed).
* As soon as the returned char array is not needed,
* it should be erased for security reasons (Arrays.fill(charArr, ' '));
* A password should never be stored as a java String.
*
* Note that Java 6 has a Console class with a readPassword method,
* but there is no equivalent in Java 5 or Java 1.4.
* The readPassword method here is based on Sun's suggestions at
* http://java.sun.com/developer/technicalArticles/Security/pwordmask.
*
* @param prompt the password prompt to issue
* @return new char array containing the password
* @throws RuntimeException if some error occurs
*/
public static final char[] readPassword(String prompt)
throws RuntimeException {
try {
StreamMasker masker = new StreamMasker(System.out, prompt);
Thread threadMasking = new Thread(masker);
int firstByte = -1;
PushbackInputStream inStream = null;
try {
threadMasking.start();
inStream = new PushbackInputStream(System.in);
firstByte = inStream.read();
} finally {
masker.stopMasking();
}
try {
threadMasking.join();
} catch (InterruptedException e) {
throw new RuntimeException("Interrupt occurred when reading password");
}
if (firstByte == -1) {
throw new RuntimeException("Console input ended unexpectedly");
}
if (System.out.checkError()) {
throw new RuntimeException("Console password prompt output error");
}
inStream.unread(firstByte);
return readLineSecure(inStream);
}
catch (IOException e) {
throw new RuntimeException("I/O error occurred when reading password");
}
}
//----------------------------------
/**
* Reads one line from an input stream into a char array in a secure way
* suitable for reading a password.
* The char array will never contain a '\n' or '\r'.
*
* @param inStream the pushback input stream
* @return line as a char array, not including end-of-line-chars;
*  never null, but may be zero length array
* @throws RuntimeException if some error occurs
*/
private static final char[] readLineSecure(PushbackInputStream inStream)
throws RuntimeException {
if (inStream == null) {
throw new RuntimeException("readLineSecure inStream is null");
}
try {
char[] buffer = null;
try {
buffer = new char[128];
int offset = 0;
// EOL is '\n' (unix), '\r\n' (windows), '\r' (mac)
loop:
while (true) {
int c = inStream.read();
switch (c) {
case -1:
case '\n':
break loop;
case '\r':
int c2 = inStream.read();
if ((c2 != '\n') && (c2 != -1))
inStream.unread(c2);
break loop;
default:
buffer = checkBuffer(buffer, offset);
buffer[offset++] = (char) c;
break;
}
}
char[] result = new char[offset];
System.arraycopy(buffer, 0, result, 0, offset);
return result;
}
finally {
if (buffer != null)
Arrays.fill(buffer, ' ');
}
}
catch (IOException e) {
throw new RuntimeException("I/O error occurred when reading password");
}
}
//----------------------------------
/**
* This is a helper method for readLineSecure.
*
* @param buffer the current char buffer
* @param offset the current position in the buffer
* @return the current buffer if it is not yet full;
*  otherwise return a larger buffer initialized with a copy
*  of the current buffer and then erase the current buffer
* @throws RuntimeException if some error occurs
*/
private static final char[] checkBuffer(char[] buffer, int offset)
throws RuntimeException
{
if (buffer == null)
throw new RuntimeException("checkBuffer buffer is null");
if (offset < 0)
throw new RuntimeException("checkBuffer offset is negative");
if (offset < buffer.length)
return buffer;
else {
try {
char[] bufferNew = new char[offset + 128];
System.arraycopy(buffer, 0, bufferNew, 0, buffer.length);
return bufferNew;
} finally {
Arrays.fill(buffer, ' ');
}
}
}
//----------------------------------
/**
* This private class prints a one line prompt
* and erases reply chars echoed to the console.
*/
private static final class StreamMasker
extends Thread {
private static final String BLANKS = StreamMasker.repeatChars(' ', 10);
private String m_promptOverwrite;
private String m_setCursorToStart;
private PrintStream m_out;
private volatile boolean m_doMasking;
//----------------------------------
/**
* Constructor.
* @throws RuntimeException if some error occurs
*/
public StreamMasker(PrintStream outPrint, String prompt)
throws RuntimeException {
if (outPrint == null)
throw new RuntimeException("StreamMasker outPrint is null");
if (prompt == null)
throw new RuntimeException("StreamMasker prompt is null");
if (prompt.indexOf('\r') != -1)
throw new RuntimeException("StreamMasker prompt contains a CR");
if (prompt.indexOf('\n') != -1)
throw new RuntimeException("StreamMasker prompt contains a NL");
m_out = outPrint;
m_setCursorToStart = StreamMasker.repeatChars('\010',
prompt.length() + BLANKS.length());
m_promptOverwrite = m_setCursorToStart + prompt + BLANKS
+ m_setCursorToStart + prompt;
}
//----------------------------------
/**
* Begin masking until asked to stop.
* @throws RuntimeException if some error occurs
*/
public void run()
throws RuntimeException {
int priorityOriginal = Thread.currentThread().getPriority();
Thread.currentThread().setPriority(Thread.MAX_PRIORITY);
try {
m_doMasking = true;
while (m_doMasking) {
m_out.print(m_promptOverwrite);
if (m_out.checkError())
throw new RuntimeException("Console output error writing prompt");
try {
Thread.currentThread().sleep(1);
} catch (InterruptedException ie) {
Thread.currentThread().interrupt();
return;
}
}
m_out.print(m_setCursorToStart);
} finally {
Thread.currentThread().setPriority(priorityOriginal);
}
}
//----------------------------------
/**
* Instructs the thread to stop masking.
*/
public void stopMasking() {
m_doMasking = false;
}
//----------------------------------
/**
* Returns a repeated char string.
*
* @param c the char to repeat
* @param length the number of times to repeat the char
* @throws RuntimeException if some error occurs
*/
private static String repeatChars(char c, int length)
throws RuntimeException {
if (length < 0)
throw new RuntimeException("repeatChars length is negative");
StringBuffer sb = new StringBuffer(length);
for (int i = 0; i < length; i++)
sb.append(c);
return sb.toString();
}
}
}

アプリケーション権限の管理

ほとんどのデータベース・アプリケーションでは、異なるスキーマ・オブジェクトごとに異なる権限が関与します。各アプリケーションに必要な権限の追跡は、複雑な場合があります。また、アプリケーションを実行するユーザーの認可には、多くのGRANT操作が関与する場合があります。

アプリケーションの権限管理を簡素化するために、アプリケーションごとに作成した1つのロールに、1人のユーザーがそのアプリケーションを実行するために必要なすべての権限を付与できます。実際には、1つのアプリケーションに複数のロールがある可能性があり、各ロールには、アプリケーションの実行中に使用できる機能の多少を決める権限の特定サブセットが付与されます。

たとえば、すべての管理アシスタントが休暇アプリケーションを使用して、部門のメンバーが取得した休暇を記録するとします。このアプリケーションを効率的に管理するには、次の操作手順が必要です。

1. VACATIONロールを作成します。

2. 休暇アプリケーションに必要なすべての権限をVACATIONロールに付与します。

3. VACATIONロールをすべての管理アシスタントに付与します。より効率的な方法は、管理アシスタントが持つ権限を定義したロールを作成し、VACATIONロールをそのロールに付与します。

複数のアプリケーション権限を1つのロールにグループ化すると、権限の管理に役立ちます。次の管理オプションを考えてみます。

- アプリケーションを実行するユーザーに、多数の個別の権限ではなく、ロールを付与できます。したがって、従業員が業務を変更するときは、多くの権限ではなく、1つのロールのみを付与または取り消す必要があります。

- アプリケーションに対応付けられている権限の変更は、そのアプリケーションのすべてのユーザーが保持する権限ではなく、ロールに付与されている権限のみを修正することで実行できます。

- 特定のアプリケーションの実行に必要な権限は、ROLE_TAB_PRIVSとROLE_SYS_PRIVSの各データ・ディクショナリ・ビューを問い合せることで判断できます。

- どのユーザーに、どのアプリケーションの権限があるかは、DBA_ROLE_PRIVSデータ・ディクショナリ・ビューを問い合せることで判断できます。

関連項目:

- ロールの作成、使用可能化と使用禁止化、および権限の付与と取消しの詳細は、第4章「権限とロール認可の構成」を参照してください。

- ROLE_TAB_PRIVS、ROLE_SYS_PRIVSおよびDBA_ROLE_PRIVSデータ・ディクショナリ・ビューのセキュリティ使用の詳細は、「ユーザー権限とロールに関する情報の検索」を参照してください。

アプリケーションへのアクセスを制御するセキュア・アプリケーション・ロールの作成

「セキュア・アプリケーション・ロールを使用したロール権限の保護」で説明したように、セキュア・アプリケーション・ロールは、ロールに対応付けられているPL/SQLパッケージまたはプロシージャを介してのみ有効化できるロールです。このパッケージは、アプリケーションへのアクセスを制御するために必要なポリシーを定義します。

この項の内容は、次のとおりです。

- 手順1: セキュア・アプリケーション・ロールの作成

- 手順2: アプリケーションに対するアクセス・ポリシーを定義するPL/SQLパッケージの作成

関連項目:
セキュア・アプリケーション・ロールの作成例は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

手順1: セキュア・アプリケーション・ロールの作成

セキュア・アプリケーション・ロールは、IDENTIFIED USING句が指定されたCREATE ROLE SQL文を使用して作成します。この文を実行するには、CREATE ROLEシステム権限が必要です。

たとえば、sec_mgr.hr_adminパッケージに対応付けられるhr_adminというセキュア・アプリケーション・ロールを作成するには、次の手順を実行します。

1. 次のようにセキュア・アプリケーション・ロールを作成します。

CREATE ROLE hr_admin IDENTIFIED USING sec_mgr.hr_admin_role_check;

この例から次のようなことがわかります。

- 作成されるhr_adminは、セキュア・アプリケーション・ロールです。

- ロールを使用可能にできるのは、PL/SQLプロシージャsec_mgr.hr_admin_role_check内で定義されたモジュールのみです。この時点で、このプロシージャは終了する必要がありません。「手順2: アプリケーションに対するアクセス・ポリシーを定義するPL/SQLパッケージの作成」で、パッケージまたはプロシージャを作成する方法を説明しています。

2. セキュア・アプリケーション・ロールに対して、このロールに通常対応付ける権限を付与します。
たとえば、HR.EMPLOYEES表に対するSELECT、INSERT、UPDATEおよびDELETE権限をhr_adminロールに付与するには、次の文を入力します。

GRANT SELECT, INSERT, UPDATE, DELETE ON HR.EMPLOYEES TO hr_admin;

このロールをユーザーに直接付与しないでください。ユーザーがセキュリティ・ポリシーを通過した場合は、PL/SQLプロシージャまたはパッケージによってこのロールが自動的に付与されます。

手順2: アプリケーションに対するアクセス・ポリシーを定義するPL/SQLパッケージの作成

セキュア・アプリケーション・ロールを使用可能または使用禁止にするには、PL/SQLパッケージ内にロールのセキュリティ・ポリシーを作成します。個別のプロシージャを作成してこれを実行することもできますが、パッケージを使用すると、一連のプロシージャをグループ化できます。これにより、一緒に使用するポリシーのグループを作成して、アプリケーションを保護するための強固なセキュリティ戦略を提示できます。セキュリティ・ポリシーに失敗したユーザー(潜在的な侵入者)については、監査チェックをパッケージに追加して、その失敗を記録できます。通常、このパッケージは、セキュリティ管理者のスキーマに作成します。

このパッケージまたはプロシージャは、次の内容を実行する必要があります。

- 実行者権限を使用してロールを有効にする必要があります。実行者権限を使用してパッケージを作成するには、AUTHIDプロパティをCURRENT_USERに設定する必要があります。定義者権限を使用してパッケージを作成することはできません。
実行者権限と定義者権限の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- ユーザーを検証するためのセキュリティ・チェックを1つ以上組み込む必要があります。ユーザーを検証する方法の1つは、SYS_CONTEXT SQLファンクションを使用することです。SYS_CONTEXTの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。ユーザーに関するセッション情報を検索するために、アプリケーション・コンテキストでSYS_CONTEXTを使用できます。詳細は、第6章「アプリケーション・コンテキストを使用したユーザー情報の取得」を参照してください。

- ユーザーがセキュリティ・チェックを通過するときにSET ROLE SQL文またはDBMS_SESSION.SET_ROLEプロシージャを発行する必要があります。パッケージは実行者権限を使用して作成するため、SET ROLE SQL文またはDBMS_SESSION.SET_ROLEプロシージャを発行することによりロールを設定する必要があります。(ただし、このタイプのロール有効化でSET ROLE ALL文を使用することはできません。)PL/SQL埋込みSQL構文はSET ROLE文をサポートしませんが、動的SQL(たとえばEXECUTE IMMEDIATEにより)を使用することによりSET ROLEを起動できます。
EXECUTE IMMEDIATEの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

このパッケージまたはプロシージャの作成方法が原因で、セキュア・アプリケーション・ロールを使用可能または使用禁止にする際にログイン・トリガーを使用できません。かわりに、ユーザーがセキュリティ・アプリケーション・ロールで付与された権限を使用する前のユーザー・ログイン時に、アプリケーションからパッケージを直接起動します。

たとえば、hr_adminロールを使用するユーザーを、午前8時から午後5時の間にオンサイトになっている(つまり、特定の端末を使用している)従業員に制限する場合を想定します。システム管理者またはセキュリティ管理者は、次の手順を実行します。(最初の行のCREATE OR REPLACEの前にカーソルを置くことで、このテキストをコピーして貼り付けることができます。)

1. 次のようにプロシージャを作成します。

CREATE OR REPLACE PROCEDURE hr_admin_role_check
AUTHID CURRENT_USER
AS
BEGIN
IF (SYS_CONTEXT ('userenv','ip_address')
BETWEEN '192.0.2.10' and '192.0.2.20'
AND
TO_CHAR (SYSDATE, 'HH24') BETWEEN 8 AND 17)
THEN
EXECUTE IMMEDIATE 'SET ROLE hr_admin';
END IF;
END;
/

この例の説明は、次のとおりです。

- AUTHID CURRENT_USERは、実行者権限を使用できるように、AUTHIDプロパティをCURRENT_USERに設定します。

- IF (SYS_CONTEXT ('userenv','ip_address')は、ユーザー・セッション情報を取得するSYS_CONTEXT SQLファンクションを使用してユーザーを検証します。

- BETWEEN ... TO_CHARは、アクセス権を付与または拒否するテストを作成します。テストはオンサイト(つまり、特定の端末を使用中)で午前8:00から午後5:00までの時間に作業するユーザーについて、アクセスを制限します。ユーザーがこのチェックを通過すると、hr_adminロールが付与されます。

- THEN... EXECUTEは、EXECUTE IMMEDIATEコマンドを使用してSET ROLE文を発行し、そのユーザーにロールを付与します。

2. ロールが割り当てられたユーザーに対して、hr_admin_role_checkプロシージャのEXECUTE権限を付与します。
例:

GRANT EXECUTE ON hr_admin_role_check TO psmith;

セキュア・アプリケーション・ロールをテストするには、そのユーザーでSQL*Plusにログインし、ロールを使用可能にして、ロールで付与される権限が必要なアクションを実行してみます。

例:

CONNECT PSMITH
Enter password: password

EXECUTE sec_admin.hr_admin_role_check;

-- Actions requiring privileges granted by the role

権限とユーザー・データベース・ロールの関連付け

ユーザーの権限が、現在のデータベース・ロールに関連した権限のみであることを確認します。

この項の内容は、次のとおりです。

- ユーザーの権限が現在のデータベース・ロールのみである理由

- ロールを自動的に使用可能または使用禁止にするSET ROLE文の使用

ユーザーの権限が現在のデータベース・ロールのみである理由

1人のユーザーが、多数のアプリケーションおよび多数の対応付けられたロールを使用できます。ただし、このユーザーの権限は、現在のデータベース・ロールに関連した権限のみであることを確認する必要があります。次の使用例を考えてみます。

- (「受注」というアプリケーションの)ORDERロールには、INVENTORY表に対するUPDATE権限が含まれています。

- (「在庫」というアプリケーションの)INVENTORYロールには、INVENTORY表に対するSELECT権限が含まれています。

- 何人かの受注入力担当には、ORDERロールとINVENTORYロールの両方が付与されています。

このシナリオでは、両方のロールを付与された受注入力担当がINVENTORYアプリケーションの実行時にORDERロールの権限を使用してINVENTORY表を更新できます。問題は、INVENTORY表の更新は、INVENTORYアプリケーションにとって承認された操作ではないということです。ORDERアプリケーションにとって承認された操作です。この問題を防ぐには、SET ROLE文を次のセクションの説明のとおりに使用します。

ロールを自動的に使用可能または使用禁止にするSET ROLE文の使用

各アプリケーションの開始時にSET ROLE文を使用して、各アプリケーションに対応付けられているロールを自動的に使用可能にし、他のすべてのロールを使用禁止にします。この方法によって、各アプリケーションでは、必要な場合にのみ、ユーザーの特定の権限を動的に使用可能にします。

SET ROLE文は、権限の管理を簡素化します。ユーザーがどのような情報にアクセスできるかと、その情報にいつアクセスできるかを制御します。また、このSET ROLE文によって、ユーザーは、明確に定義された権限ドメイン内で操作を続行できます。あるユーザーがロールからのみ権限を取得している場合、そのユーザーはこれらの権限を組み合せて不正な操作を実行することはできません。

関連項目:

- ロールの使用可能および使用禁止の詳細は、「権限の付与と取消しが有効になるとき」を参照してください。

- 「SET ROLE文が付与と取消しに与える影響」

スキーマを使用したデータベース・オブジェクトの保護

スキーマとは、データベース・オブジェクトを含めることができるセキュリティ・ドメインです。各ユーザーまたはロールに付与された権限によって、これらのデータベース・オブジェクトへのアクセスが制御されます。

この項の内容は、次のとおりです。

- 一意スキーマでのデータベース・オブジェクトの保護

- 共有スキーマでのデータベース・オブジェクトの保護

一意スキーマでのデータベース・オブジェクトの保護

ほとんどのスキーマはユーザー名と考えることができます。つまり、ユーザーがデータベースに接続してそのデータベース・オブジェクトへのアクセスを可能にするアカウントです。ただし、一意スキーマではデータベースへの接続は許可されませんが、関連する一連のオブジェクトを格納するために使用されます。この種のスキーマは通常ユーザーとして作成されますが、CREATE SESSIONシステム権限は(明示的にもロールを介しても)付与されません。しかし、CREATE SCHEMAを使用して、1つのトランザクション内に複数の表とビューを作成する場合は、一意スキーマにCREATE SESSIONおよびRESOURCE権限を一時的に付与する必要があります。

たとえば、所定のスキーマが特定のアプリケーションのスキーマ・オブジェクトを所有する場合があります。アプリケーション・ユーザーに権限がある場合、そのユーザーは、一般的なデータベース・ユーザー名を使用してデータベースに接続し、アプリケーションとそれに対応するオブジェクトを使用できます。ただし、ユーザーはアプリケーションに設定されたスキーマを使用して、データベースに接続することはできません。この構成は、対応付けられたオブジェクトへのスキーマを介したアクセスを防ぎ、スキーマ・オブジェクトの保護を強化します。この場合、アプリケーションではALTER SESSION SET CURRENT_SCHEMA文を発行して、ユーザーを適切なアプリケーション・スキーマに接続できます。

共有スキーマでのデータベース・オブジェクトの保護

多くのアプリケーションでは、ユーザーはデータベースで自分自身のアカウントつまりスキーマを必要としません。これらのユーザーに必要なのは、アプリケーション・スキーマへのアクセスのみです。たとえば、ユーザーJohn、FiruzehおよびJaneはすべて給与アプリケーションのユーザーで、financeデータベースのpayrollスキーマにアクセスする必要があるとします。この場合、データベースに自分自身のオブジェクトを作成する必要があるユーザーはいません。これらのユーザーに必要なのは、payrollオブジェクトへのアクセスのみです。この問題に対処するために、Oracle Advanced Securityではエンタープライズ・ユーザー(スキーマに依存しないユーザー)が提供されています。

エンタープライズ・ユーザー、つまりディレクトリ・サービスで管理されるユーザーは、共有データベース・スキーマを使用するため、データベース・ユーザーとして作成する必要はありません。管理コストを削減するために、管理者はディレクトリに1つのエンタープライズ・ユーザーを1回作成し、他の多数のユーザーもアクセスできる共有スキーマで、そのユーザーを指し示すことができます。

エンタープライズ・ユーザー管理の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

アプリケーションでのオブジェクト権限の管理

アプリケーション設計の一部として、そのアプリケーションで作業するユーザーのタイプ、およびユーザーが担当のタスクを達成するために必要なアクセスのレベルを決定する必要があります。これらのユーザーを複数のロール・グループに分類し、各ロールに付与する権限を決定する必要があります。

この項の内容は、次のとおりです。

- アプリケーション開発者に必要なオブジェクト権限に関する知識

- オブジェクト権限によって許可されるSQL文

アプリケーション開発者に必要なオブジェクト権限に関する知識

通常、エンド・ユーザーにはオブジェクト権限が付与されています。オブジェクト権限によって、ユーザーは、特定の表、ビュー、順序、プロシージャ、ファンクションまたはパッケージに対して特定のアクションを実行できます。

表5-2に、オブジェクトの各タイプで使用できるオブジェクト権限の概要を示します。

表5-2 権限とスキーマ・オブジェクトとの関連

オブジェクト権限

表への適用

ビューへの適用

順序への適用

プロシージャへの適用脚注 1

ALTER

あり

なし

あり

なし

DELETE

あり

あり

なし

なし

EXECUTE

なし

なし

なし

あり

INDEX

あり脚注 2

なし

なし

なし

INSERT

あり

あり

なし

なし

REFERENCES

あり脚注 2

なし

なし

なし

SELECT

あり

あり脚注 3

あり

なし

UPDATE

あり

あり

なし

なし

脚注1スタンドアロンのストアド・プロシージャ、ファンクションおよびパブリック・パッケージ構成

脚注2ロールに付与できない権限

脚注3スナップショットにも付与可能

スキーマ・オブジェクトの監査方法の詳細は、「スキーマ・オブジェクトの監査」も参照してください。

オブジェクト権限によって許可されるSQL文

アプリケーションの実装時およびテスト時には、必要な各ロールを作成する必要があります。各ロールの使用例をテストし、データベースへのアクセス権がアプリケーション・ユーザーに正しく付与されることを確認します。テスト終了後は、アプリケーションの管理者と共同で各ユーザーに適切なロールが割り当てられていることを確認します。

表5-3に、表5-2で示したオブジェクト権限によって許可されるSQL文を示します。

表5-3 データベース・オブジェクト権限によって許可されるSQL文

オブジェクト権限

許可されるSQL文

ALTER

ALTERオブジェクト(表または順序)

CREATE TRIGGER ONオブジェクト(表のみ)

DELETE

DELETE FROMオブジェクト(表、ビューまたはシノニム)

EXECUTE

EXECUTEオブジェクト(プロシージャまたはファンクション)

パブリック・パッケージ変数への参照

INDEX

CREATE INDEX ONオブジェクト(表、ビューまたはシノニム)

INSERT

INSERT INTOオブジェクト(表、ビューまたはシノニム)

REFERENCES

オブジェクト(表のみ)に対するFOREIGN KEY整合性制約を定義するCREATEまたはALTER TABLE文

SELECT

SELECT...FROMオブジェクト(表、ビュー、シノニムまたはスナップショット)

順序を使用するSQL文

オブジェクト権限の詳細は、「権限とロールの概要」を参照してください。SQL文の監査方法の詳細は、「SQL文の監査」も参照してください。

データベース通信のセキュリティを強化するためのパラメータ

データベース管理者は、この項の次の手順に従ってアプリケーションのセキュリティを管理できます。

- プロトコル・エラーによってデータベースで受信した不正パケットのレポート

- 不正パケット受信後のサーバー実行の終了または再開

- 認証の最大試行回数の構成

- データベース・バージョン・バナーの表示制御

- 不正なアクセスおよびユーザー・アクションの監査に関するバナーの構成

プロトコル・エラーによってデータベースで受信した不正パケットのレポート

サーバーが不正なパケット、順序に誤りがあるパケット、プライベートまたは未使用のリモート・プロシージャ・コールを受信した場合、Oracle Call Interface(OCI)やTwo-Task Common(TTC)などのネットワーキング通信ユーティリティでは、スタック・トレースおよびヒープ・ダンプを格納する大規模なディスク・ファイルを生成できます。通常、このディスク・ファイルは、非常に大規模になる可能性があります。侵入者は、サーバーに不正なパケットを繰り返し送信し、ディスクあふれやサービスの拒否を発生させることで、システムを使用できないようにする可能性があります。認証されていないクライアントが、この種の攻撃を仕掛ける可能性もあります。

これらの攻撃は、SEC_PROTOCOL_ERROR_TRACE_ACTION初期化パラメータを次の値のいずれかに設定することで防止できます。

- None: サーバーが不正なパケットを無視し、トレース・ファイルまたはログ・メッセージを生成しないように構成します。サーバーの可用性が不正なパケットの受信を認識することよりも圧倒的に重要な場合は、この設定を使用します。
例:

SEC_PROTOCOL_ERROR_TRACE_ACTION = None

- Trace(デフォルト設定): トレース・ファイルを作成します。これは、ネットワーク・クライアントが不具合の結果として不正なパケットを送信している場合など、デバッグを目的とする場合に便利です。
例:

SEC_PROTOCOL_ERROR_TRACE_ACTION = Trace

- Log: サーバー・トレース・ファイルに1行の短いメッセージを書き込みます。この選択肢では、一定レベルの監査とシステムの可用性とのバランスがとれます。
例:

SEC_PROTOCOL_ERROR_TRACE_ACTION = Log

- Alert: データベース管理者または監視コンソールにアラート・メッセージを送信します。
例:

SEC_PROTOCOL_ERROR_TRACE_ACTION = Alert

不正パケット受信後のサーバー実行の終了または再開

Oracle Databaseは、クライアントまたはサーバー・プロトコルからエラーを検出した後も実行を継続する必要があります。ただし、これによって、ディスクあふれまたはサービス拒否攻撃を発生させる可能性のある不正なパケットを、サーバーがさらに受信する可能性があります。

サーバーが悪意のあるクライアントから不正なパケットを受信しているときに、サーバー・プロセスの実行を詳細に制御するには、SEC_PROTOCOL_ERROR_FURTHER_ACTION初期化パラメータを次の値のいずれかに設定します。

- Continue(デフォルト設定): サーバーの実行を継続します。ただし、サーバーがさらに攻撃を受ける可能性があることに注意してください。
例:

SEC_PROTOCOL_ERROR_FURTHER_ACTION = Continue

- Delay,m: クライアントをm秒間遅延させます(サーバーが次のリクエストを同じクライアント接続から受け付けるまで)。この設定により悪意のあるクライアントはサーバー・リソースを過剰使用できなくなります。正当なクライアントのパフォーマンスも低下しますが、引き続き機能します。
例:

SEC_PROTOCOL_ERROR_FURTHER_ACTION = Delay,3

- Drop,n: クライアント接続は、n個の不正パケットを受信した後に強制的に終了します。この設定を使用すると、トランザクションの損失など、クライアントを犠牲にしてサーバー自体を保護できます。ただし、クライアントは再度接続して、同じ操作を再試行できます。
例:

SEC_PROTOCOL_ERROR_FURTHER_ACTION = Drop,10

認証の最大試行回数の構成

Oracle Databaseでは、サーバー・プロセスが最初に起動し、次にクライアントがこのサーバー・プロセスで認証を受けます。侵入者は、最初にサーバー・プロセスを起動し、様々なユーザー名とパスワードを使用して認証リクエストを無制限に発行し、データベースへのアクセスを試みます。

アプリケーション接続に対するログイン失敗回数を制限するには、SEC_MAX_FAILED_LOGIN_ATTEMPTS初期化パラメータを設定して、接続に対する認証試行回数を制限します。指定した認証試行回数を失敗すると、データベース・プロセスは接続を切断します。デフォルトでは、SEC_MAX_FAILED_LOGIN_ATTEMPTSは10に設定されます。

SEC_MAX_FAILED_LOGIN_ATTEMPTS初期化パラメータは、潜在的侵入者がアプリケーションを攻撃できないようにするためのものであることに注意してください。正当なユーザーには適用しません。sqlnet.ora INBOUND_CONNECT_TIMEOUTパラメータとFAILED_LOGIN_ATTEMPTS初期化パラメータもログイン失敗を制限しますが、違いはこの2つのパラメータが正当なユーザー・アカウントにのみ適用するということです。

たとえば、最大試行回数を5に制限するには、initsid.ora初期化パラメータ・ファイルで、次のようにSEC_MAX_FAILED_LOGIN_ATTEMPTSを設定します。

SEC_MAX_FAILED_LOGIN_ATTEMPTS = 5

データベース・バージョン・バナーの表示制御

クライアント接続(Oracle Call Interfaceクライアントを含む)が認証されてから、詳細な製品バージョン情報にアクセスできるようにする必要があります。侵入者は、データベース・バージョンを使用して、データベース・ソフトウェアに存在するセキュリティの脆弱性に関する情報を検出する可能性があります。

認証されていないクライアントに対してデータベース・バージョン・バナーの表示を制限するには、initsid.ora初期化パラメータ・ファイルでSEC_RETURN_SERVER_RELEASE_BANNER初期化パラメータをTRUEまたはFALSEのいずれかに設定します。デフォルトでは、SEC_RETURN_SERVER_RELEASE_BANNERはFALSEに設定されます。

たとえば、TRUEに設定すると、Oracle Databaseに正確なデータベース・バージョンが表示されます。

Oracle Database 11g Enterprise Edition Release 11.2.0.0 - Production

今後、たとえばOracle Database 11.2.0.2をインストールした場合は、次のバナーが表示されます。

Oracle Database 11g Enterprise Edition Release 11.2.0.2 - Production

ただし、同じリリースでこのパラメータをFALSEに設定すると、このバナーは制限されて、リリース11.2で開始する次の固定テキストで表示されます。

Oracle Database 11g Release 11.2.0.0.0 - Production

不正なアクセスおよびユーザー・アクションの監査に関するバナーの構成

不正なアクセスおよびユーザー・アクション監査をユーザーに警告するには、バナーを作成して構成する必要があります。この通知は、クライアント・アプリケーションがデータベースにログインすると使用可能になります。

これらのバナーを構成して表示するには、データベース・サーバー側で次のsqlnet.oraパラメータを設定して、バナー情報が含まれるテキスト・ファイルを指し示します。

- SEC_USER_UNAUTHORIZED_ACCESS_BANNER。次に例を示します。

SEC_USER_UNAUTHORIZED_ACCESS_BANNER = /opt/Oracle/11g/dbs/unauthaccess.txt

- SEC_USER_AUDIT_ACTION_BANNER。次に例を示します。

SEC_USER_AUDIT_ACTION_BANNER = /opt/Oracle/11g/dbs/auditactions.txt

デフォルトでは、これらのパラメータは設定されません。さらに、バナー・テキストに使用される文字数には512バイトの制限があることを注意してください。

これらのパラメータを設定した後に、Oracle Call Interfaceアプリケーションでは、適切なOCI APIを使用してこれらのバナーを取得し、エンド・ユーザーに表示する必要があります。

6 アプリケーション・コンテキストを使用したユーザー情報の取得

この章の内容は、次のとおりです。

- アプリケーション・コンテキストの概要

- アプリケーション・コンテキストの種類

- データベース・セッション・ベースのアプリケーション・コンテキストの使用

- グローバル・アプリケーション・コンテキストの使用

- クライアント・セッション・ベースのアプリケーション・コンテキストの使用

- アプリケーション・コンテキストに関する情報の検索

アプリケーション・コンテキストの概要

この項の内容は、次のとおりです。

- アプリケーション・コンテキストとは

- アプリケーション・コンテキストの構成要素

- アプリケーション・コンテキストの値の格納場所

- アプリケーション・コンテキストを使用する利点

- エディションがアプリケーション・コンテキストの値に与える影響

アプリケーション・コンテキストとは

アプリケーション・コンテキストとは、Oracle Databaseがメモリーに格納する名前と値のペアです。アプリケーション・コンテキストには、ネームスペースと呼ばれるラベル(たとえば、従業員IDを取得するアプリケーション・コンテキストはempno_ctx)があります。コンテキスト内は名前と値のペア(結合配列)です。名前は、値を保持するメモリー内の場所を指定します。アプリケーションはアプリケーション・コンテキストを使用して、ユーザーに関するセッション情報(ユーザーIDまたは他のユーザー固有の情報など)またはクライアントIDにアクセスして、その情報をデータベースに安全に引き渡すことができます。この情報を使用して、ユーザーがアプリケーションを通じてデータにアクセスできるようにしたりアクセスできないようにできます。アプリケーション・コンテキストを使用して、データベース・ユーザーと非データベース・ユーザーの両方を認証できます。

アプリケーション・コンテキストの構成要素

名前と値のペアの構成要素は、次のとおりです。

- 名前:値に関連付けられている属性セットの名前を示します。たとえば、empno_ctxアプリケーション・コンテキストは従業員IDをHR.EMPLOYEES表から取得する場合、名前をemployee_idにすることができます。

- 値:属性により設定される値を示します。たとえば、empno_ctxアプリケーション・コンテキストでは、HR.EMPLOYEES表から従業員IDを取得する場合、このIDの値を設定する、emp_idと呼ばれる値を作成できます。

アプリケーション・コンテキストは、データベース・セッション中にアクセスされる情報を保持するグローバル変数と考えてください。セキュア・アプリケーション・コンテキストの値を設定するには、DBMS_SESSION.SET_CONTEXTプロシージャを使用するPL/SQLパッケージ・プロシージャを作成する必要があります。実際、コンテキストがINITIALIZED EXTERNALLYまたはINITIALIZED GLOBALLYとマークされていない場合は、事実上、この方法がアプリケーション・コンテキスト値を設定できる唯一の方法となります。アプリケーション・コンテキスト属性には、アプリケーション・コンテキストの作成時ではなく、実行時に値を割り当てることができます。ユーザーではなくトラステッド・プロシージャによって値が割り当てられるため、これはセキュア・アプリケーション・コンテキストと呼ばれます。クライアント・セッション・ベースのアプリケーション・コンテキストの場合、Oracle Call Interface(OCI)コールを使用してアプリケーション・コンテキストを設定することもできます。

アプリケーション・コンテキストの値の格納場所

アプリケーション・コンテキストの値は、ユーザー・グローバル領域(UGA)またはシステム・グローバル領域(SGA)(共有グローバル領域と呼ばれる場合もあります)内の使用可能な保護データ・キャッシュに格納されます。格納されたアプリケーション・コンテキストの値はセッション中に取得されます。アプリケーション・コンテキストには、このデータ・キャッシュ内の値が格納されるため、アプリケーションのパフォーマンスが向上します。アプリケーション・コンテキストは単独で使用でき、Oracle Virtual Private Databaseポリシーまたはその他のファイングレイン・アクセス制御ポリシーと併用することもできます。アプリケーション・コンテキストと仮想プライベート・データベース・ポリシーの併用については、「Oracle Virtual Private Databaseでのアプリケーション・コンテキストの使用」を参照してください。

アプリケーション・コンテキストを使用する利点

ほとんどのアプリケーションには、アプリケーション・コンテキストに使用可能なある種の情報が含まれています。たとえば、ORDER_NUMBER列とCUSTOMER_NUMBER列を備えた表を使用する受注管理アプリケーションでは、それらの列の値をセキュリティ属性として使用して、顧客によるアクセスをその顧客のIDに基づいて顧客自身の注文のみに制限できます。

アプリケーション・コンテキストは、次の目的で使用されます。

- ファイングレイン・アクセス・コントロールの規定(Oracle Virtual Private Databaseポリシーなどで)

- 複数層環境でのユーザー識別情報の保持

- アプリケーションに対する強力なセキュリティの規定(アプリケーション・コンテキストはユーザーではなくトラステッド・プロシージャによって制御されるため)

- アプリケーションがファイングレイン監査やPL/SQL条件文またはループで使用する際に必要な属性に対して、保護データ・キャッシュとしての機能を果たすことによるパフォーマンスの向上
このキャッシュによって、これらの属性が必要になるたびにデータベースに問い合せるというオーバーヘッドが軽減されます。アプリケーションはセッション・データを表から繰り返し取得する必要がなく、このデータがアプリケーション・コンテキストによってキャッシュに格納されるため、アプリケーションのパフォーマンスが大幅に向上します。

- アプリケーションで定義、変更およびアクセスできる名前と値のペアの保持領域として機能

エディションがアプリケーション・コンテキストの値に与える影響

Oracle Databaseでは、アプリケーション・コンテキスト・パッケージの影響を受けるすべてのエディションでアプリケーション・コンテキストが設定されます。アプリケーション・コンテキストで設定される値は、アプリケーション・コンテキストが影響するすべてのエディションで表示されます。

関連項目:
エディションの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

アプリケーション・コンテキストの種類

アプリケーション・コンテキストには、3種類の一般的なカテゴリがあります。

- データベース・セッション・ベースのアプリケーション・コンテキスト。このタイプのアプリケーション・コンテキストは、データベース・ユーザー・セッション(つまりUGA)のキャッシュに格納されているデータを取得します。データベース・セッション・ベースのアプリケーション・コンテキストは、3つのカテゴリに分類されます。

- ローカルで初期化。ユーザーのセッションに対してアプリケーション・コンテキストをローカルで初期化します。

- 外部で初期化。Oracle Call Interface(OCI)アプリケーション、ジョブ・キュー・プロセスまたは接続ユーザーのデータベース・リンクからアプリケーション・コンテキストを初期化します。

- グローバルに初期化。LDAPディレクトリなどの集中格納場所から属性と値を使用します。

このタイプのアプリケーション・コンテキストについては、「データベース・セッション・ベースのアプリケーション・コンテキストの使用」を参照してください。

- グローバル・アプリケーション・コンテキスト。このタイプは、システム・グローバル領域(SGA)に格納されるデータを取得するため、3層アーキテクチャの中間層アプリケーションなど、セッションを使用しないアプリケーションに対して使用できます。グローバル・アプリケーション・コンテキストは、セッション・コンテキストをセッション間で、たとえば接続プールの実装を通じて共有する場合に便利です。
このタイプのアプリケーション・コンテキストについては、「グローバル・アプリケーション・コンテキストの使用」を参照してください。

- クライアント・セッション・ベースのアプリケーション・コンテキスト。このタイプのアプリケーション・コンテキストは、クライアント側のOracle Call Interface関数を使用してユーザー・セッション・データを設定し、次に、必要なセキュリティ・チェックを実行してユーザー・アクセスを制限します。
このタイプのアプリケーション・コンテキストについては、「クライアント・セッション・ベースのアプリケーション・コンテキストの使用」を参照してください。

表6-1に、異なるタイプのアプリケーション・コンテキストの要約を示します。

表6-1 アプリケーション・コンテキストの種類

アプリケーション・コンテキストの種類

UGAへの格納

SGAへの格納

接続ユーザー・データベース・リンクのサポート

ユーザーのアプリケーション・コンテキストの集中保管のサポート

セッションを使用しない複数層アプリケーションのサポート

ローカルで初期化されるデータベース・セッション・ベースのアプリケーション・コンテキスト

あり

なし

なし

なし

なし

外部で初期化されるデータベース・セッション・ベースのアプリケーション・コンテキスト

あり

なし

あり

なし

なし

グローバルに初期化されるデータベース・セッション・ベースのアプリケーション・コンテキスト

あり

なし

なし

あり

なし

グローバル・アプリケーション・コンテキスト

なし

あり

なし

なし

あり

クライアント・セッション・ベースのアプリケーション・コンテキスト

あり

なし

あり

なし

あり

データベース・セッション・ベースのアプリケーション・コンテキストの使用

この項の内容は、次のとおりです。

- データベース・セッション・ベースのアプリケーション・コンテキストの概要

- データベース・セッション・ベースのアプリケーション・コンテキストの作成

- データベース・セッション・ベースのアプリケーション・コンテキストを設定するためのPL/SQLパッケージの作成

- データベース・セッション・ベースのアプリケーション・コンテキスト・パッケージを実行するためのログイン・トリガーの作成

- 例: データベース・セッション・ベースのアプリケーション・コンテキストの作成と使用

- データベース・セッション・ベースのアプリケーション・コンテキストの外部での初期化

- データベース・セッション・ベースのアプリケーション・コンテキストのグローバルな初期化

- 外部化されたデータベース・セッション・ベースのアプリケーション・コンテキストの使用

データベース・セッション・ベースのアプリケーション・コンテキストの概要

データベース・ユーザーのセッション情報を取得する必要がある場合は、データベース・セッション・ベースのアプリケーション・コンテキストを使用します。このタイプのアプリケーション・コンテキストは、Oracle Database内でPL/SQLプロシージャを使用し、管理の対象となるデータを取得、設定および保護します。

注意:
ユーザーがアプリケーション・ユーザー(つまり、データベースに存在しないユーザー)の場合は、グローバル・アプリケーション・コンテキストの使用を考慮してください。詳細は、「グローバル・アプリケーション・コンテキストの使用」を参照してください。

データベース・セッション・ベースのアプリケーション・コンテキストは、Oracle Databaseの中で完全管理されます。Oracle Databaseが値を設定し、ユーザーがセッションを終了すると、キャッシュに保管されたアプリケーション・コンテキスト値を自動的に消去します。ユーザー接続が異常終了すると(たとえば停電)、PMONバックグラウンド・プロセスはアプリケーション・コンテキスト・データをクリーン・アップします。アプリケーション・コンテキストをキャッシュから消去する必要はありません。

アプリケーション・コンテキストをOracle Databaseで管理する利点は、アプリケーション・コンテキストを集中管理できる点です。このデータベースにアクセスするアプリケーションは、このアプリケーション・コンテキストを使用して、そのアプリケーションに対するユーザーのアクセスを許可または防止する必要があります。これによって、パフォーマンス向上とセキュリティ強化の両方の利点が得られます。

データベース・セッション・ベースのアプリケーション・コンテキストを作成して使用するには、次のコンポーネントを使用します。

- アプリケーション・コンテキスト。アプリケーション・コンテキストを作成するには、CREATE CONTEXT SQL文を使用します。この文は、アプリケーション・コンテキスト(ネームスペース)名を設定し、セッション・データを取得してアプリケーション・コンテキストを設定するように設計されたPL/SQLプロシージャに対して、その名前を関連付けます。

- データの取得とコンテキストの設定を実行するPL/SQLプロシージャ。このプロシージャで実行する必要があるタスクについては、「データベース・セッション・ベースのアプリケーション・コンテキストを管理するパッケージの概要」を参照してください。理想的には、必要に応じて他のプロシージャ(タスクのエラー・チェックなど)を挿入できるように、このプロシージャは1つのパッケージ内に作成します。

- ユーザーのログイン時にアプリケーション・コンテキストを設定する手段。アプリケーション・コンテキストを使用するアプリケーションにログインするユーザーは、そのアプリケーション・コンテキストを設定するPL/SQLパッケージを実行する必要があります。そのためには、ユーザーがログインするたびに起動するログイン・トリガーを使用するか、この機能をアプリケーションに埋め込むことができます。

ローカルで初期化されるデータベース・セッション・ベースのアプリケーション・コンテキストの作成方法と使用方法は、「例: データベース・セッション・ベースのアプリケーション・コンテキストの作成と使用」を参照してください。

セッション・ベースのアプリケーション・コンテキストは外部で、またはグローバルに初期化することもできます。いずれの場合も、コンテキスト情報はユーザー・セッションに格納されます。

- 外部での初期化。この初期化は、OCIインタフェース、ジョブ・キュー・プロセスまたは接続ユーザーのデータベース・リンクから発生します。詳細は、「データベース・セッション・ベースのアプリケーション・コンテキストの外部での初期化」を参照してください。

- グローバルな初期化。この初期化では、LDAPディレクトリなどの集中格納場所から属性と値を使用します。詳細は、「データベース・セッション・ベースのアプリケーション・コンテキストのグローバルな初期化」を参照してください。

データベース・セッション・ベースのアプリケーション・コンテキストの作成

データベース・セッション・ベースのアプリケーション・コンテキストを作成するには、CREATE CONTEXT SQL文を使用します。ここで、アプリケーション・コンテキストのネームスペースを作成してから、ユーザーのセッション情報を保持する名前と値のペアを管理するPL/SQLパッケージに関連付けます。この文を実行するために、CREATE ANY CONTEXTシステム権限が必要です。アプリケーション・コンテキストを削除する場合は、DROP CONTEXT文を使用するためにDROP ANY CONTEXT権限が必要になります。データベース・セッション・ベースのアプリケーション・コンテキストでは、データはデータベース・ユーザー・セッション(UGA)のネームスペース内に保管され、これはCREATE CONTEXT SQL文を使用して作成されます。

各アプリケーション・コンテキストには一意の属性が必要で、1つのネームスペースに属している必要があります。つまり、コンテキスト名は、スキーマ内のみでなくデータベース内でも一意である必要があります。

アプリケーション・コンテキストの所有権については、CREATE ANY CONTEXT権限とDROP ANY CONTEXT権限を付与されたユーザーがそのアプリケーション・コンテキストを作成および削除できた場合でも、SYSスキーマが所有しています。Oracle Databaseは、作成したスキーマ・アカウントにコンテキストを関連付けますが、このユーザーを削除した場合、コンテキストはそれでもSYSスキーマの中に存在します。ユーザーSYSであれば、アプリケーション・コンテキストを削除できます。

例6-1に、CREATE CONTEXTを使用してデータベース・セッション・ベースのアプリケーション・コンテキストを作成する方法を示します。

例6-1 データベース・セッション・ベースのアプリケーション・コンテキストの作成

CREATE CONTEXT empno_ctx USING set_empno_ctx_pkg;

ここで、empno_ctxはコンテキスト・ネームスペース、set_empno_ctx_pkgはそのempno_ctxネームスペースの属性を設定するパッケージです。PL/SQLパッケージは、アプリケーション・コンテキストの作成時には不要ですが、実行時には存在している必要があります。このアプリケーション・コンテキストで使用可能なパッケージの作成方法の例は、「手順3: セッション・データを取得してアプリケーション・コンテキストを設定するパッケージの作成」を参照してください。

コンテキストを作成するときは、そのコンテキストの名前/値の属性をCREATE CONTEXT文に設定しないでください。これらの属性は、アプリケーション・コンテキストに関連付けるパッケージに設定してください。これは、不正なユーザーによって、適切な属性の検証なしにコンテキスト属性が変更されないようにするためです。

注意:
CLIENTCONTEXTというコンテキストは作成できません。これは、クライアント・セッション・ベースのアプリケーション・コンテキストで使用される予約語です。このタイプのアプリケーション・コンテキストの詳細は、「クライアント・セッション・ベースのアプリケーション・コンテキストの使用」を参照してください。

各アプリケーションには、独自の属性を持つアプリケーション・コンテキストを作成できます。たとえば、General Ledger(一般会計)、Order Entry(受注管理)およびHuman Resources(人事管理)という3つのアプリケーションがあるとします。これらの各アプリケーションには、異なる属性を指定できます。

- 受注管理アプリケーション・コンテキストには、CUSTOMER_NUMBER属性を指定できます。

- 一般会計アプリケーション・コンテキストには、SET_OF_BOOKS属性とTITLE属性を指定できます。

- 人事管理アプリケーション・コンテキストには、ORGANIZATION_ID、POSITION、COUNTRYの各属性を指定できます。

属性がアクセスするデータは、アプリケーション外の表に保管されます。たとえば、受注管理アプリケーションではOE.CUSTOMERSという名前の表が使用されており、この中のCUSTOMER_NUMBER列にはCUSTOMER_NUMBER属性のデータが入ります。いずれの場合にも、アプリケーション・コンテキストを厳密なセキュリティ・ニーズに適用できます。

データベース・セッション・ベースのアプリケーション・コンテキストを設定するためのPL/SQLパッケージの作成

この項の内容は、次のとおりです。

- データベース・セッション・ベースのアプリケーション・コンテキストを管理するパッケージの概要

- SYS_CONTEXTを使用したセッション情報の取得

- SYS_CONTEXTでの動的SQLの使用

- パラレル問合せでのSYS_CONTEXTの使用

- データベース・リンクでのSYS_CONTEXTの使用

- DBMS_SESSION.SET_CONTEXTを使用したセッション情報の設定

データベース・セッション・ベースのアプリケーション・コンテキストを管理するパッケージの概要

PL/SQLパッケージは、通常、セキュリティ管理者のスキーマに作成され、アプリケーション・コンテキストによって表されるセッション・データを管理するプロシージャを定義します。次のタスクを実行する必要があります。

- セッション情報の取得。ユーザー・セッション情報の取得には、SYS_CONTEXT SQL関数を使用できます。このSYS_CONTEXT関数は、コンテキストのネームスペースに関連付けられているパラメータの値を戻します。この関数は、SQL文とPL/SQL文の両方で使用できます。通常は、組み込まれているUSERENVネームスペースを使用してユーザーのセッション情報を取得します。(SYS_CONTEXT関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。)

- CREATE CONTEXTで作成したアプリケーション・コンテキストの名前/値の属性の設定。アプリケーション・コンテキストの名前/値の属性の設定には、DBMS_SESSION.SET_CONTEXTプロシージャを使用できます。この名前/値の属性には、ユーザーID、IPアドレス、認証モード、アプリケーション名などの情報を格納できます。設定した属性の値は、再設定するまで、またはユーザーがセッションを終了するまでそのまま残ります。次のことに注意してください。

- ネームスペース内のパラメータの値がすでに設定されている場合は、SET_CONTEXTによってこの値が上書きされます。

- コンテキストの値が変更された場合、その内容はただちに反映され、SYS_CONTEXTファンクションによって値を取得する後続のコールでは、最新の値が戻されます。

- ユーザーによる実行。パッケージを作成した後、ログインする場合ユーザーはそのパッケージを実行する必要があります。ユーザーがログインするときパッケージを自動的に実行するためのログイン・トリガーを作成するか、この機能をアプリケーションに埋め込むことができます。アプリケーション・コンテキスト・セッション値はユーザーがセッションを終了すると自動的に消去されるので、セッション・データを手動で削除する必要はありません。

プロシージャはトラステッド・プロシージャであることに注意してください。ユーザーが自分独自のアプリケーション・コンテキスト属性値を設定できないように設計されています。ユーザーはプロシージャを実行しますが、プロシージャがアプリケーション・コンテキスト値を設定します、ユーザーではありません。

データベース・セッション・ベースのアプリケーション・コンテキストの作成方法は、「例: データベース・セッション・ベースのアプリケーション・コンテキストの作成と使用」を参照してください。

SYS_CONTEXTを使用したセッション情報の取得

PL/SQLファンクションのSYS_CONTEXTの構文は、次のとおりです。

SYS_CONTEXT ('namespace','parameter'[,length])

次のように値を指定します。

- namespace: アプリケーション・コンテキストの名前。文字列、または文字列として評価される式を指定できます。SYS_CONTEXTファンクションは、現時点でコンテキストのネームスペースに関連付けられているパラメータの値を戻します。ネームスペース内のパラメータの値がすでに設定されている場合は、SET_CONTEXTによってこの値が上書きされます。

- parameter: namespaceアプリケーション・コンテキスト内のパラメータ。この値には、文字列または式を指定できます。

- length: オプションです。戻り型の最大サイズはデフォルトで256バイトですが、最大で4000バイトの値を指定して長さを変更できます。NUMBERデータ型の値を入力するか、NUMBERに明示的に変換できる値を入力します。SYS_CONTEXT戻り型のデータ型はVARCHAR2です。

SYS_CONTEXT関数には、ログインしたユーザーのカレント・セッションを表すデフォルト・ネームスペースUSERENVがあります。SYS_CONTEXTを使用して、ユーザー・ホスト・コンピュータID、ホストIPアドレス、オペレーティング・システム・ユーザー名など、ユーザーに関する様々なタイプのセッション・ベースの情報を取得できます。セッション・データを設定ではなく、取得するにはUSERENVのみを使用することに注意してください。事前定義の属性は、『Oracle Database SQL言語リファレンス』のPL/SQLファンクションの説明でリストされています。

たとえば、次のようにUSERENVのHOSTパラメータを使用して、クライアントが接続しているホスト・コンピュータの名前を取得できます。

SYS_CONTEXT ('userenv','host')

SYS_CONTEXT設定は、DUAL表に対してSELECT SQL文を発行することでチェックできます。DUAL表はデータ・ディクショナリ内の小さい表で、既知の結果を保証するためにOracle Databaseおよびユーザーが記述したプログラムから参照できます。この表には、DUMMYという列と、値Xが格納されている行があります。

例6-2では、ログインしたホスト・コンピュータの検索方法を示しています。この例では、EMP_USERSの下のSHOBEEN_PCホスト・コンピュータにログインしたと想定しています。

例6-2 SYS_CONTEXT値の検索

SELECT SYS_CONTEXT ('USERENV', 'HOST') FROM DUAL;

SYS_CONTEXT(USERENV,HOST)
-------------------------
EMP_USERS\SHOBEEEN_PC

注意:
USERENVアプリケーション・コンテキスト・ネームスペースは、Oracle Databaseの以前のリリースで提供されていたUSERENV関数にかわる機能です。

SYS_CONTEXTでの動的SQLの使用

指定した問合せを実行する間にポリシーの変更が予想されるセッション中は、その問合せに動的SQLを使用する必要があります。静的SQLと動的SQLでは文の解析方法が異なるため、必ず動的SQLを使用してください。

- 静的SQL文はコンパイル時に解析されます。パフォーマンス上の理由から実行時には再解析されません。

- 動的SQL文は、実行されるたびに解析されます。

SQL文のコンパイル時にはポリシーAを規定し、その後、ポリシーBに変更して文を実行する場合を考えてみます。静的SQLでは、ポリシーAが規定されたままです。文はコンパイル時に解析されますが、実行時には再解析されません。動的SQLでは、文は実行時に解析されるため、ポリシーBへの切替えが有効となります。

たとえば、次のポリシーを考えてみます。

EMPLOYEE_NAME = SYS_CONTEXT ('USERENV', 'SESSION_USER')

ポリシーEMPLOYEE_NAMEは、データベース・ユーザー名と一致しています。Oracle Virtual Private DatabaseではSQL述語の形で表され、述語はポリシーとみなされます。述語が変更された場合、正しい結果を生成するために文を再度解析する必要があります。

関連項目:
「ファイングレイン・アクセス・コントロールのポリシー関数に対する自動再解析の使用」

パラレル問合せでのSYS_CONTEXTの使用

パラレル問合せに埋め込まれているSQL関数内でSYS_CONTEXTを使用すると、この関数にアプリケーション・コンテキストが挿入されます。

ユーザーIDを5に設定する、SQL文内のユーザー定義関数を考えてみます。

CREATE FUNCTION set_id
RETURN NUMBER IS
BEGIN
IF SYS_CONTEXT ('hr', 'id') = 5
THEN RETURN 1; ELSE RETURN 2;
END IF;
END;

次の文を考えてみます。

SELECT * FROM emp WHERE set_id( ) = 1;

この文をパラレル問合せとして実行すると、アプリケーション・コンテキスト情報を含むユーザー・セッションはパラレル実行サーバー(問合せ子プロセス)に伝播されます。

データベース・リンクでのSYS_CONTEXTの使用

ユーザー・セッション内のSQL文にデータベース・リンクが含まれている場合は、そのデータベース・リンクのホスト・コンピュータでSYS_CONTEXT SQL関数が実行され、そのホスト・コンピュータにあるコンテキスト情報が取得されます。

リモートのPL/SQLプロシージャ・コールがデータベース・リンクで実行されている場合は、そのプロシージャ内部のすべてのSYS_CONTEXT関数が、そのリンクの宛先データベースで実行されます。この場合、データベース・リンクの宛先サイトで使用できるのは、外部で初期化されたアプリケーション・コンテキストのみです。セキュリティ上の理由から、データベース・リンクの開始サイトから宛先サイトに伝播されるのは、外部で初期化されたアプリケーション・コンテキストのみです。

DBMS_SESSION.SET_CONTEXTを使用したセッション情報の設定

SYS_CONTEXT関数を使用してユーザーのセッション・データを取得後、アプリケーション・コンテキスト値をこのユーザーのセッションから設定できます。そのためには、DBMS_SESSION.SET_CONTEXTプロシージャを使用します。(DBMS_SESSION PL/SQLパッケージに対するEXECUTE権限を所有していることを確認してください。)

構文は、次のとおりです。

DBMS_SESSION.SET_CONTEXT (
namespace VARCHAR2,
attribute VARCHAR2,
value     VARCHAR2,
username  VARCHAR2,
client_id VARCHAR2);

次のように値を指定します。

- namespace: 設定するアプリケーション・コンテキストのネームスペース(30バイトに制限)。たとえば、custno_ctxという名前のネームスペースを使用していた場合は、次のように指定します。

namespace => 'custno_ctx',

- attribute: 設定するアプリケーション・コンテキストの属性(30バイトに制限)。たとえばcustno_ctxネームスペースのctx_attrib属性を作成する場合は、次のようになります。

attribute => 'ctx_attrib',

- value: 設定するアプリケーション・コンテキストの値(4000バイトに制限)。通常、これはSYS_CONTEXT関数で取得されて変数に格納された値です。次に例を示します。

value => ctx_value,

- username: オプション。アプリケーション・コンテキストのデータベース・ユーザー名属性。デフォルトはNULLで、すべてのユーザーにセッションへのアクセスを許可します。データベース・セッション・ベースのアプリケーション・コンテキストでは、この設定は省略され、デフォルトのNULLが使用されます。
usernameおよびclient_idパラメータは、グローバルにアクセスされるアプリケーション・コンテキストに対して使用されます。詳細は、「DBMS_SESSION.SET_CONTEXTのusernameおよびclient_idパラメータの設定」を参照してください。

- client_id: オプション。アプリケーション・コンテキストのアプリケーション固有のclient_id属性(最大64バイト)です。デフォルトはNULLで、クライアントIDが指定されていないことを意味します。データベース・セッション・ベースのアプリケーション・コンテキストでは、この設定は省略され、デフォルトのNULLが使用されます。

DBMS_SESSIONパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

例6-1で作成したアプリケーション・コンテキストを例にします。

CREATE CONTEXT empno_ctx USING set_empno_ctx_proc;

例6-3に、empno_ctxアプリケーション・コンテキストの属性を作成する単純なプロシージャの作成方法を示します。

例6-3 アプリケーション・コンテキストの値を作成する単純なプロシージャ

CREATE OR REPLACE PROCEDURE set_empno_ctx_proc(
emp_value IN VARCHAR2)
IS
BEGIN
DBMS_SESSION.SET_CONTEXT('empno_ctx', 'empno_attrib', emp_value);
END;
/

この例の説明は、次のとおりです。

- emp_value IN VARCHAR2はemp_valueを入力パラメータとして使用します。このパラメータは、アプリケーション・コンテキスト属性empno_attribに関連付けられている値を指定します。制限は4000バイトです。

- DBMS_SESSION.SET_CONTEXT('empno_ctx', 'empno_attrib', emp_value)は、DBMS_SESSION.SET_CONTEXTプロシージャを次のように使用して、アプリケーション・コンテキストの値を設定します。

- 'empno_ctx': アプリケーション・コンテキストのネームスペースを示します。ネームスペース名は一重引用符で囲みます。

- 'empno_attrib': アプリケーション・コンテキストのネームスペースに関連付ける属性を作成します。

- emp_value: empno_attrib属性の値を指定します。ここでは2行目に定義されているemp_valueパラメータを参照しています。

これで、set_empno_ctx_procプロシージャを実行して、アプリケーション・コンテキストを設定できます。

EXECUTE set_empno_ctx_proc ('42783');

(実際には、アプリケーション・コンテキストの値はプロシージャ自体に設定することになるため、そのプロシージャがトラステッド・プロシージャとなります。この例は、データが設定される様子を示すことのみを目的に記載しています。)

アプリケーション・コンテキストの設定をチェックするには、次のSELECT文を実行します。

SELECT SYS_CONTEXT ('empno_ctx', 'empno_attrib') empno_attrib FROM DUAL;

EMPNO_ATTRIB
--------------
42783

SESSION_CONTEXTデータ・ディクショナリ・ビューを問い合せると、データベース・インスタンスのカレント・セッションにあるすべてのアプリケーション・コンテキスト設定を検索することもできます。次に例を示します。

SELECT * FROM SESSION_CONTEXT;

NAMESPACE                ATTRIBUTE          VALUE
--------------------------------------------------
EMPNO_CTX                EMP_ID             42783

関連項目:

- ユーザー・セッション情報を取得するパッケージを作成し、その情報に基づいてアプリケーション・コンテキストを設定する方法については、「例: データベース・セッション・ベースのアプリケーション・コンテキストの作成と使用」を参照してください。

- DBMS_SESSION.SET_CONTEXTプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

データベース・セッション・ベースのアプリケーション・コンテキスト・パッケージを実行するためのログイン・トリガーの作成

アプリケーション・コンテキストと関連のパッケージを作成した後は、ユーザーはログイン時にそのパッケージ・プロシージャを実行する必要があります。これを自動的に処理するようにログイン・トリガーを作成できます。パッケージを実行するためのEXECUTE権限をユーザーに付与する必要はありません。

例6-4に、PL/SQLプロシージャを実行する単純なログイン・トリガーを示します。

例6-4 単純なログイン・トリガーの作成

CREATE OR REPLACE TRIGGER set_empno_ctx_trig AFTER LOGON ON DATABASE
BEGIN
sec_mgr.set_empno_ctx_proc;
END;

例6-5は、WHEN OTHERS例外を使用するログイン・トリガーの作成方法を示しています。一方、PL/SQLロジックにエラーが発生して未処理例外を引き起こす場合は、データベースへのすべての接続がブロックされます。この例は、セキュリティ管理者のスキーマの表にエラーを書き込むWHEN OTHERS例外を示しています。本番環境では、こちらのほうが、出力をユーザー・セッションへ送信することでセキュリティ攻撃を受けやすくなるよりも安全です。

例6-5 本番環境用のログイン・トリガーの作成

CREATE OR REPLACE TRIGGER set_empno_ctx_trig AFTER LOGON ON DATABASE
BEGIN
sec_mgr.set_empno_ctx_proc;
EXCEPTION
WHEN OTHERS THEN
v_code := SQLCODE;
v_errm := SUBSTR(SQLERRM, 1 , 64);
-- Invoke another procedure,
-- declared with PRAGMA AUTONOMOUS_TRANSACTION,
-- to insert information about errors.
INSERT INTO sec_mgr.errors VALUES (v_code, v_errm, SYSTIMESTAMP);
END;
/

例6-6に、同じログイン・トリガーを開発環境用に作成する方法を示します。この場合、エラーをデバッグのためにユーザー・セッションに出力できます。

例6-6 開発環境用のログイン・トリガーの作成

CREATE TRIGGER set_empno_ctx_trig
AFTER LOGON ON DATABASE
BEGIN
sysadmin_ctx.set_empno_ctx_pkg.set_empno;
EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR(
-20000, 'Trigger sysadmin_ctx.set_empno_ctx_trig violation. Login denied.');
END;
/

次のことに注意してください。

- ログイン・トリガーによって呼び出されたPL/SQLパッケージ・プロシージャに未処理例外があるか(たとえばセキュリティ・チェックに失敗したために)なんらかの例外を発生すると、ログイン・トリガーは失敗します。ログイン・トリガーに失敗すると、ログインは失敗し、つまりユーザーはデータベースにログインする権限が拒否されます。

- ログイン・トリガーがパフォーマンスに影響を与える可能性があります。また、ログイン・トリガーは、最初にサンプル・スキーマ・ユーザーでテストしてから、データベース用に作成してください。これによって、エラーがあった場合は簡単に修正できます。

- 会計帳簿の変更や職階の変更が頻繁にある場合は注意が必要です。この場合、新しい属性値はすぐに選択できない可能性があるため、カーソルの再解析を強制実行して、新しい属性値を選択する必要があります。

注意:
ユーザー・コンテキスト(EMPNO、GROUP、MANAGERなどの情報)は、ユーザーがデータにアクセスする前に設定されるため、ログイン・トリガーを使用できます。

例: データベース・セッション・ベースのアプリケーション・コンテキストの作成と使用

この項の内容は、次のとおりです。

- このチュートリアルの概要

- 手順1: ユーザー・アカウントの作成とユーザーSCOTTがアクティブであることの確認

- 手順2: データベース・セッション・ベースのアプリケーション・コンテキストの作成

- 手順3: セッション・データを取得してアプリケーション・コンテキストを設定するパッケージの作成

- 手順4: パッケージに対するログイン・トリガーの作成

- 手順5: アプリケーション・コンテキストのテスト

- 手順6: この例で使用したコンポーネントの削除

このチュートリアルの概要

この例では、データベースにログインを試行するデータベース・ユーザーの従業員IDをチェックするアプリケーション・コンテキストの作成方法を示します。

手順1: ユーザー・アカウントの作成とユーザーSCOTTがアクティブであることの確認

1. ユーザーSYSでログインし、AS SYSDBA権限を使用して接続します。

sqlplus sys as sysdba
Enter password: password

2. sysadmin_ctxアカウントを作成します。このアカウントは、データベース・セッション・ベースのアプリケーション・コンテキストを管理します。

GRANT CREATE SESSION, CREATE ANY CONTEXT, CREATE PROCEDURE, CREATE TRIGGER, ADMINISTER DATABASE TRIGGER TO sysadmin_ctx IDENTIFIED BY password;
GRANT SELECT ON HR.EMPLOYEES TO sysadmin_ctx;
GRANT EXECUTE ON DBMS_SESSION TO sysadmin_ctx;

passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。

3. Lisa Ozerに対して、次のユーザー・アカウントを作成します。HR.EMPLOYEES表には、lozerというLisa Ozerの電子メール・アカウントがあります。

GRANT CREATE SESSION TO LOZER IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。

4. この例ではサンプル・ユーザーSCOTTも使用するため、DBA_USERSデータ・ディクショナリ・ビューを問い合せて、SCOTTがロックされていたり、期限切れになっていないことを確認します。

SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'SCOTT';

DBA_USERSビューに、ユーザーSCOTTがロックされて期限切れになっていると表示された場合は、次の文を入力して、SCOTTアカウントのロックを解除し、新しいパスワードを作成します。

ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY password;

安全なパスワードを入力します。セキュリティを向上させるため、以前のリリースのOracle Databaseと同じパスワードをSCOTTアカウントに指定しないでください。パスワードを作成するための最低要件は、「パスワードの最低要件」を参照してください。

手順2: データベース・セッション・ベースのアプリケーション・コンテキストの作成

1. sysadmin_ctxでSQL*Plusにログインします。

CONNECT sysadmin_ctx
Enter password: password

2. 次の文を使用してアプリケーション・コンテキストを作成します。

CREATE CONTEXT empno_ctx USING set_empno_ctx_pkg;

ユーザーsysadmin_ctxがこのアプリケーション・コンテキストを作成した場合でも、SYSスキーマがこのコンテキストを所有することに注意してください。

手順3: セッション・データを取得してアプリケーション・コンテキストを設定するパッケージの作成

例6-7に、セッション・データを取得してアプリケーション・コンテキストを設定するために必要なパッケージの作成方法を示します。パッケージを作成する前に、ユーザーsysadmin_ctxでログインしていることを確認してください。(最初の行のCREATE OR REPLACEの前にカーソルを置くことで、このテキストをコピーして貼り付けることができます。)

例6-7 セッション・データを取得してデータベース・セッション・コンテキストを設定するためのパッケージ

CREATE OR REPLACE PACKAGE set_empno_ctx_pkg IS
PROCEDURE set_empno;
END;
/
CREATE OR REPLACE PACKAGE BODY set_empno_ctx_pkg IS
PROCEDURE set_empno
IS
emp_id HR.EMPLOYEES.EMPLOYEE_ID%TYPE;
BEGIN
SELECT EMPLOYEE_ID INTO emp_id FROM HR.EMPLOYEES
WHERE email = SYS_CONTEXT('USERENV', 'SESSION_USER');
DBMS_SESSION.SET_CONTEXT('empno_ctx', 'employee_id', emp_id);
EXCEPTION
WHEN NO_DATA_FOUND THEN NULL;
END;
END;
/

このパッケージでは、次の処理を実行するset_empnoというプロシージャが作成されます。

- emp_id HR.EMPLOYEES.EMPLOYEE_ID%TYPEは、ログインするユーザーの従業員IDを格納する変数emp_idを宣言します。HR.EMPLOYEESのEMPLOYEE_ID列と同じデータ型を使用します。

- SELECT EMPLOYEE_ID INTO emp_id FROM HR.EMPLOYEESは、SELECT文を実行し、HR.EMPLOYEES表のemployee_id列データに格納されている従業員IDをemp_id変数にコピーします。

- WHERE email = SYS_CONTEXT('USERENV', 'SESSION_USER')は、WHERE句を使用して、セッション・ユーザーの電子メール・アカウントと一致するすべての従業員IDを検索します。SYS_CONTEXT関数は、事前定義のUSERENVコンテキストを使用してユーザー・セッションID (これはemail列データと同じです)を取得します。たとえば、Lisa OzerのユーザーIDと電子メール・アドレスはどちらも同じでlozerです。

- DBMS_SESSION.SET_CONTEXT('empno_ctx', 'employee_id', emp_id)は、DBMS_SESSION.SET_CONTEXTプロシージャを使用して、アプリケーション・コンテキストを設定します。

- 'empno_ctx': アプリケーション・コンテキストempno_ctxをコールします。empno_ctxは一重引用符で囲みます。

- 'employee_id': 属性にemployee_idという名前を指定して、empno_ctxアプリケーション・コンテキストの名前と値のペアの属性値を作成します。employee_idは一重引用符で囲みます。

- emp_id: employee_id属性の値をemp_id変数に格納された値に設定します。emp_id変数は8行目で作成され、従業員IDは10から11行目で取得されます。

要約すると、set_empno_ctx_pkg.set_empnoプロシージャは、「ユーザーのセッションIDを取得して、このユーザーIDをHR.EMPLOYEES表にリストされたユーザーの従業員IDおよび電子メール・アドレスと照合する」プロシージャです。

- EXCEPTION ... WHEN_NO_DATA_FOUNDは、WHEN NO_DATA_FOUNDシステム例外を追加して、SELECT文によって発生した可能性のあるno data foundエラーを捕捉します。この例外がないと、パッケージとログイン・トリガーは正常に機能し、必要に応じてアプリケーション・コンテキストが設定されますが、HR.EMPLOYEES表にリストされたユーザーを除き、システム管理者以外のユーザーはデータベースにログインできなくなります。他のユーザーは、有効なデータベース・ユーザーであればデータベースにログインできます。アプリケーション・コンテキスト情報が設定された後は、特定のアプリケーションへのユーザー・アクセスを制御する手段として、このセッション情報を使用できます。

手順4: パッケージに対するログイン・トリガーの作成

ユーザーsysadmin_ctxで、次のトリガーを作成します。

CREATE TRIGGER set_empno_ctx_trig AFTER LOGON ON DATABASE
BEGIN
sysadmin_ctx.set_empno_ctx_pkg.set_empno;
END;
/

手順5: アプリケーション・コンテキストのテスト

1. ユーザーlozerでログインします。

CONNECT lozer
Enter password: password

ユーザーlozerがログインすると、このユーザーの従業員IDがempno_ctxアプリケーション・コンテキストによって収集されます。これは次のようにして確認できます。

SELECT SYS_CONTEXT('empno_ctx', 'employee_id') emp_id FROM DUAL;

次の出力が表示されます。

EMP_ID
--------------------------------------------------------
168

2. ユーザーSCOTTでログインします。

CONNECT SCOTT
Enter password: password

ユーザーSCOTTはHR.EMPLOYEES表に従業員としてリストされていないため、empno_ctxアプリケーション・コンテキストではこのユーザーの従業員IDを収集できません。

SELECT SYS_CONTEXT('empno_ctx', 'employee_id') emp_id FROM DUAL;

次の出力が表示されます。

EMP_ID
--------------------------------------------------------

これ以降、アプリケーションではユーザー・セッション情報を使用してユーザーがデータベース内で許可されるアクセス数を判別できます。そのためには、Oracle Virtual Private Databaseを使用できます。詳細は、第7章「Oracle Virtual Private Databaseを使用したデータ・アクセスの制御」を参照してください。

手順6: この例で使用したコンポーネントの削除

1. SYSでログインし、AS SYSDBAを使用して接続します。

CONNECT SYS/AS SYSDBA
Enter password: password

2. ユーザーsysadmin_ctxとlozerを削除します。

DROP USER sysadmin_ctx CASCADE;
DROP USER lozer;

3. アプリケーション・コンテキストを削除します。

DROP CONTEXT empno_ctx;

このアプリケーション・コンテキストはsysadmin_ctxが作成しましたが、SYSスキーマの所有となっていることに注意してください。

4. 他のユーザーがSCOTTを使用しない場合、このアカウントはロックして期限切れにできます。

ALTER USER SCOTT PASSWORD EXPIRE ACCOUNT LOCK;

データベース・セッション・ベースのアプリケーション・コンテキストの外部での初期化

データベース・セッション・ベースのアプリケーション・コンテキストを外部で初期化するときは、外部リソースからの属性値の初期化を受け入れてからローカル・ユーザー・セッションに保管する特殊なタイプのネームスペースを指定します。アプリケーション・コンテキストは外部で初期化することによりUGAに格納されて、属性をセッションから別のセッションへ自動伝播できるようになるため、パフォーマンスが向上します。接続ユーザー・データベース・リンクをサポートするのは、OCIベースの外部ソースから初期化されたアプリケーション・コンテキストのみです。

この項の内容は、次のとおりです。

- ユーザーからのデフォルト値の取得

- 他の外部リソースからの値の取得

- 中間層サーバーからのアプリケーション・コンテキスト値の初期化

ユーザーからのデフォルト値の取得

ユーザーからデフォルトを取得することが必要な場合があります。最初、これらのデフォルト値はヒントまたはプリファレンスとして機能し、検証後にトラステッド・コンテキストになります。同様に、クライアントでは、一部のデフォルト値を初期化してから、ログイン・イベント・トリガーまたはアプリケーションを使用して値の検証を行うと便利です。

ジョブ・キューに関しては、ジョブ発行ルーチンで、ジョブの発行時に設定されたコンテキストを記録し、バッチ・ジョブの実行時にそのコンテキストをリストアします。コンテキストの整合性を保持するために、ジョブ・キューは、コンテキストを設定する特定のPL/SQLパッケージを回避できません。一方、外部で初期化されたアプリケーション・コンテキストは、コンテキスト値の初期化をジョブ・キュー・プロセスから受け入れます。

リモート・セッションへのコンテキストの自動伝播によって、セキュリティ上の問題が発生する場合があります。開発者または管理者は、ユーザーのログイン時にログイン・トリガーを使用してコンテキストを再設定することで、特定のPL/SQLプロシージャ以外のリソースからデフォルト値を取得するコンテキストを効果的に処理できます。

他の外部リソースからの値の取得

外部リソースを介して属性と値の初期化を受け入れるアプリケーション・コンテキストを作成できます。このような外部リソースには、OCIインタフェース、ジョブ・キュー・プロセスまたはデータベース・リンクなどが含まれます。

外部で初期化されたアプリケーション・コンテキストでは、次の機能が提供されます。

- リモート・セッションの場合は、外部で初期化されたアプリケーション・コンテキスト・ネームスペースにあるコンテキスト値を自動的に伝播します。

- ジョブ・キューの場合は、外部で初期化されたアプリケーション・コンテキスト・ネームスペースにあるコンテキスト値をリストアします。

- OCIインタフェースの場合は、外部で初期化されたアプリケーション・コンテキスト・ネームスペースにあるコンテキスト値を初期化するメカニズムを提供します。

Oracle Call Interfaceを使用しているクライアント・プログラムであればこのタイプのネームスペースの初期化は可能ですが、ログイン・イベント・トリガーを使用して値を検証できます。属性の値を解釈して信頼するかどうかはアプリケーションによって異なります。

例6-8に、外部ソースから値を取得するデータベース・セッション・ベースのアプリケーション・コンテキストを作成する方法を示します。

例6-8 外部化されたデータベース・セッション・ベースのアプリケーション・コンテキストの作成

CREATE CONTEXT ext_ctx USING ext_ctx_pkg INITIALIZED EXTERNALLY;

中間層サーバーからのアプリケーション・コンテキスト値の初期化

中間層サーバーは、データベース・ユーザーのかわりにアプリケーション・コンテキスト値を初期化できます。コンテキスト属性は、初期化時にリモート・セッションに対して伝播され、ネームスペースが外部で初期化されている場合、リモート・データベースはこれらの値を受け入れます。

たとえば、OCIまたはJDBC/OCI経由の軽量ユーザー・セッションを作成する3層アプリケーションの場合は、USERENVのPROXY_USER属性にアクセスできます。この属性を使用すると、ユーザー・セッションが中間層アプリケーションによって作成されたかどうかを判断できます。ユーザーがデータへのアクセスを許可されるのは、そのユーザーがプロキシ化されている接続に対してのみです。ユーザーがデータベースに直接接続している場合、そのユーザーはどのデータにもアクセスできません。

Oracle Virtual Private Database内のUSERENVネームスペースからPROXY_USER属性を使用すると、ユーザーによるデータへのアクセスを特定の中間層アプリケーションを経由した場合のみに制限できます。他の方法では、セキュア・アプリケーション・ロールを作成し、ユーザーは特定のプロキシ経由でのみデータベースにアクセスするというポリシーを規定できます。

関連項目:

- プロキシ認証の詳細およびUSERENV属性CLIENT_IDENTIFIERを使用して複数層にわたってユーザー識別情報を保持する方法は、「複数層環境でのユーザー識別情報の保持」を参照してください。

- セキュア・アプリケーション・ロールを使用して特定のプロキシを経由するようにポリシーを規定する方法は、「中間層サーバーを使用したプロキシ認証」を参照してください。

- 『Oracle Database JDBC開発者ガイド』

- 『Oracle Call Interfaceプログラマーズ・ガイド』

データベース・セッション・ベースのアプリケーション・コンテキストのグローバルな初期化

この項の内容は、次のとおりです。

- データベース・セッション・ベースのアプリケーション・コンテキストのグローバルな初期化について

- LDAPでのデータベース・セッション・ベースのアプリケーション・コンテキストの使用

- グローバルに初期化されたデータベース・セッション・ベースのアプリケーション・コンテキストの動作

- データベース・セッション・ベースのアプリケーション・コンテキストをグローバルに初期化する例

データベース・セッション・ベースのアプリケーション・コンテキストのグローバルな初期化について

ユーザーのデータベース・セッション・ベースのアプリケーション・コンテキストは、集中格納場所を使用して格納できます。これによって、アプリケーションでは、初期化中にユーザーの識別情報に基づいてユーザー・コンテキストを設定できます。特に、この機能では、Oracle Label Securityのラベルと権限がサポートされます。アプリケーション・コンテキストをグローバルに初期化すると、多数のユーザーとデータベースのコンテキストを簡単に管理できます。

たとえば、多くの組織では、LDAPベースのディレクトリでユーザー情報を集中管理する必要があります。Oracle Advanced Securityの機能の1つであるエンタープライズ・ユーザー・セキュリティは、Oracle Internet Directoryでのユーザーと認可の集中管理をサポートします。ただし、Oracle Virtual Private Databaseの規定に使用するために、アプリケーションではLightweight Directory Access Protocol(LDAP)から追加の属性(ユーザーの職位、組織、物理的な位置など)を取得することが必要な場合があります。これらのタイプの属性は、アプリケーション・コンテキストをグローバルに初期化することで取得できます。

LDAPでのデータベース・セッション・ベースのアプリケーション・コンテキストの使用

グローバルに初期化されたアプリケーション・コンテキストは、拡張可能で効率的な標準ディレクトリ・アクセス・プロトコルであるLDAPを使用します。LDAPディレクトリには、このアプリケーションが割り当てられているユーザーのリストが格納されます。Oracle Databaseでは、ディレクトリ・サービス(通常はOracle Internet Directory)を使用して、エンタープライズ・ユーザーを認証および認可します。

注意:

- エンタープライズ・ユーザー・セキュリティを使用するにはOracle Advanced Securityが必要です。

- Microsoft Active DirectoryやSun MicrosystemsのSunONEなどのサード・パーティ製ディレクトリもディレクトリ・サービスとして使用できます。

orclDBApplicationContext LDAPオブジェクト(groupOfUniqueNamesのサブクラス)は、アプリケーション・コンテキスト値をディレクトリに格納します。アプリケーション・コンテキスト・オブジェクトの場所は、Human Resourcesの例に基づく図6-1で説明しています。

LDAPオブジェクトinetOrgPersonにより、一部の属性では複数のエントリが存在可能です。ただし、これらのエントリがデータベースにロードされ、SYS_LDAP_USER_DEFAULTコンテキスト・ネームスペースでアクセスされると、これらのエントリのうち最初のエントリだけが返されます。たとえば、ユーザーに対するinetOrgPersonオブジェクトでは、telephoneNumberに複数のエントリが可能です(そのため、ユーザーは複数の電話番号を保存できます)。SYS_LDAP_USER_DEFAULTコンテキスト・ネームスペースを使用すると、最初の電話番号だけが取得されます。

LDAP側では、アプリケーション・コンテキスト値のリストをデータベースに返すorclDBApplicationContext値を取得するための内部C関数が必要になります。この例では、HRはネームスペース、「Title」と「Project」は属性、「Manager」と「Promotion」が値です。

図6-1 LDAPディレクトリの情報ツリーにおけるアプリケーション・コンテキストの位置

グローバルに初期化されたデータベース・セッション・ベースのアプリケーション・コンテキストの動作

グローバルに初期化されたセキュア・アプリケーションを使用するには、Oracle Advanced Securityの機能の1つであるエンタープライズ・ユーザー・セキュリティを最初に構成する必要があります。次に、ユーザーのアプリケーション・コンテキスト値をデータベースとディレクトリに設定します。

グローバル・ユーザー(エンタープライズ・ユーザー)がデータベースに接続すると、エンタープライズ・ユーザー・セキュリティ機能によって、データベースに接続しているユーザーの識別情報が検証されます。認証後、グローバル・ユーザー・ロールとアプリケーション・コンテキストがディレクトリから取得されます。ユーザーがデータベースにログインするときは、グローバル・ロールと初期アプリケーション・コンテキストがすでに設定されています。

関連項目:
エンタープライズ・ユーザー・セキュリティの構成の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

データベース・セッション・ベースのアプリケーション・コンテキストをグローバルに初期化する例

ユーザーの初期アプリケーション・コンテキスト(部門名や職位など)は、LDAPディレクトリに設定および格納できます。これらの値はユーザーのログイン中に取得されるため、コンテキストは適切に設定されます。さらに、ユーザーに関するすべての情報が取得され、アプリケーション・コンテキスト・ネームスペースSYS_USER_DEFAULTSに格納されます。次に例を示します。

1. データベースにアプリケーション・コンテキストを作成します。

CREATE CONTEXT hr USING hrapps.hr_manage_pkg INITIALIZED GLOBALLY;

2. 新規のエントリを作成し、LDAPディレクトリに追加します。
LDAPディレクトリに追加されたエントリの例を次に示します。これらのエントリは、アプリケーション(ネームスペース)HRに属性値Managerを持つ属性名Titleを作成し、ユーザー名user1およびuser2を割り当てます。次の例では、cn=exampleはドメイン名を示します。

dn: cn=OracleDBAppContext,cn=example,cn=OracleDBSecurity,cn=Products,cn=OracleContext,ou=Americas,o=oracle,c=US
changetype: add
cn: OracleDBAppContext
objectclass: top
objectclass: orclContainer

dn: cn=hr,cn=OracleDBAppContext,cn=example,cn=OracleDBSecurity,cn=Products,cn=OracleContext,ou=Americas,o=oracle,c=US
changetype: add
cn: hr
objectclass: top
objectclass: orclContainer

dn: cn=Title,cn=hr, cn=OracleDBAppContext,cn=example,cn=OracleDBSecurity,cn=Products,cn=OracleContext,ou=Americas,o=oracle,c=US
changetype: add
cn: Title
objectclass: top
objectclass: orclContainer

dn: cn=Manager,cn=Title,cn=hr, cn=OracleDBAppContext,cn=example,cn=OracleDBSecurity,cn=Products,cn=OracleContext,ou=Americas,o=oracle,c=US
cn: Manager
objectclass: top
objectclass: groupofuniquenames
objectclass: orclDBApplicationContext
uniquemember: CN=user1,OU=Americas,O=Oracle,L=Redwoodshores,ST=CA,C=US
uniquemember: CN=user2,OU=Americas,O=Oracle,L=Redwoodshores,ST=CA,C=US

3. このユーザーに関するLDAP inetOrgPersonオブジェクト・エントリが存在する場合、接続では、複数の属性がinetOrgPersonから取得され、これらがネームスペースSYS_LDAP_USER_DEFAULTに割り当てられます。次に、inetOrgPersonエントリの例を示します。

dn: cn=user1,ou=Americas,O=oracle,L=redwoodshores,ST=CA,C=US
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: user1
sn: One
givenName: User
initials: UO
title: manager, product development
uid: uone
mail: uone@us.example.com
telephoneNumber: +1 650 555 0105
employeeNumber: 00001
employeeType: full time

4. データベースに接続します。
user1がドメインexampleに属するデータベースに接続する場合、user1のTitleはManagerに設定されます。user1に関するすべての情報が、LDAPディレクトリから取得されます。値は、次の構文を使用して取得できます。

SYS_CONTEXT('namespace','attribute name')

例:

DECLARE
tmpstr1 VARCHAR2(30);
tmpstr2 VARCHAR2(30);
BEGIN
tmpstr1 = SYS_CONTEXT('HR','TITLE);
tmpstr2 = SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','telephoneNumber');
DBMS_OUTPUT.PUT_LINE('Title is ' || tmpstr1);
DBMS_OUTPUT.PUT_LINE('Telephone Number is ' || tmpstr2);
END;

次に、この例の出力を示します。

Title is Manager
Telephone Number is +1 650 555 0105

外部化されたデータベース・セッション・ベースのアプリケーション・コンテキストの使用

多くのアプリケーションでは、ファイングレイン・アクセス・コントロールに使用される属性をデータベース・メタデータ表に格納します。たとえば、employees表に、コスト・センター、職責、署名認証などのファイングレイン・アクセス・コントロールに有効な情報を含めることができます。ただし、多くの組織ではユーザー情報をOracle Internet DirectoryなどのLDAPベースのディレクトリに集中化して、ユーザーを管理し、アクセス制御しています。アプリケーション・コンテキスト属性は、Oracle Internet Directoryに格納して1人以上のエンタープライズ・ユーザーに割り当てることができます。また、これらの属性は、エンタープライズ・ユーザーがログインすると自動的に取得され、アプリケーション・コンテキストの初期化にも使用されます。

注意:
エンタープライズ・ユーザー・セキュリティはOracle Advanced Securityの機能です。

関連項目:

- OCIインタフェース、ジョブ・キュー・プロセスまたはデータベース・リンクなど、外部リソースを介したローカル・アプリケーション・コンテキストの初期化に関する詳細は、「データベース・セッション・ベースのアプリケーション・コンテキストの外部での初期化」を参照してください。

- Oracle Internet Directoryなどの集中化されたリソースを介したローカル・アプリケーション・コンテキストの初期化に関する詳細は、「データベース・セッション・ベースのアプリケーション・コンテキストのグローバルな初期化」を参照してください。

- エンタープライズ・ユーザーの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

グローバル・アプリケーション・コンテキストの使用

この項の内容は、次のとおりです。

- グローバル・アプリケーション・コンテキストの概要

- Oracle Real Application Clusters環境でのグローバル・アプリケーション・コンテキストの使用

- グローバル・アプリケーション・コンテキストの作成

- グローバル・アプリケーション・コンテキストを管理するためのPL/SQLパッケージの作成

- クライアント・セッションIDを管理するための中間層アプリケーションへのコールの埋込み

- 例: クライアント・セッションIDを使用するグローバル・アプリケーション・コンテキストの作成

- グローバル・アプリケーション・コンテキスト・プロセス

グローバル・アプリケーション・コンテキストの概要

グローバル・アプリケーション・コンテキストにより、Oracle RACインスタンスを含むデータベース・セッションでアプリケーション・コンテキスト値にアクセス可能になります。グローバル・アプリケーション・コンテキスト情報はシステム・グローバル領域(SGA: 共有グローバル領域でSGAと称する場合もあります)に格納されるため、3層アーキテクチャの中間層アプリケーションなど、セッションを使用しないアプリケーションに対して使用できます。このようなアプリケーションでは、複数のユーザーがアプリケーションに対して認証され、通常は単一の識別情報としてデータベースに接続するため、セッション・ベースのアプリケーション・コンテキストを使用できません。グローバル・アプリケーション・コンテキストは、ユーザー・セッション単位ではなく一度に初期化されます。したがって、接続は接続プールから再利用されるため、パフォーマンスが向上します。

グローバル・アプリケーション・コンテキストには、3種類の一般的な使用方法があります。

- 全データベース・ユーザーを対象にしてアプリケーションの値をグローバルに共有する必要がある場合。たとえば、特定の状況に基づいてアプリケーションへのアクセスを禁止することがあります。この場合、アプリケーション・コンテキストが設定する値はユーザーに固有の値ではなく、ユーザーのプライベート・データに基づく値でもありません。アプリケーション・コンテキストは、ある状況を定義して、実行中のアプリケーション・モジュールのバージョンなどを示します。

- 複数のアプリケーション間を移動する必要があるデータベース・ユーザーがいる場合。この場合、ユーザーの移動先となる第2のアプリケーションには、第1のアプリケーションとは異なるアクセス要件があります。

- 非データベース・ユーザー(つまり、データベースに認識されていないユーザー)を認証する必要がある場合。データベース・アカウントを持たないこのタイプのユーザーは、通常、Webアプリケーション経由で接続プールを使用して接続します。このようなアプリケーションでは、One Big Application User認証モデルを使用して、複数のユーザーを単一のユーザーとしてデータベースに接続します。このタイプのユーザーを認証するには、そのユーザーのクライアント・セッションIDを使用します。

グローバル・アプリケーション・コンテキストには次のコンポーネントがあります。

- グローバル・アプリケーション・コンテキスト。CREATE CONTEXT SQL文にACCESSED GLOBALLY句を指定して、グローバル・アプリケーション・コンテキストを作成します。この文は、アプリケーション・コンテキスト名を設定し、その名前に、アプリケーション・コンテキスト・データを設定するように設計されたPL/SQLプロシージャを関連付けます。グローバル・アプリケーション・コンテキストは、そのコンテキストを作成したセキュリティ管理者のデータベース・スキーマに作成および格納されます。

- 属性を設定するPL/SQLパッケージ。このパッケージには、DBMS_SESSION.SET_CONTEXTプロシージャを使用してグローバル・アプリケーション・コンテキストを設定するプロシージャが含まれている必要があります。SET_CONTEXTプロシージャには、この項に記載されている3種類すべての状況に適応するグローバル・アプリケーション・コンテキストを生成できるパラメータが用意されています。このPL/SQLパッケージは、データベース・サーバーで作成、格納および実行します。通常、このパッケージは、それを作成したセキュリティ管理者のスキーマに属します。

- クライアント・セッションIDを取得および設定する中間層アプリケーション。非データベース・ユーザー(認証にはクライアント・セッションIDが必要)の場合は、中間層アプリケーションでOracle Call Interface(OCI)コールを使用して、それぞれのセッション・データを取得および設定できます。DBMS_SESSION.SET_IDENTIFIERプロシージャを使用してクライアント・セッションIDを設定することもできます。クライアント・セッションIDを作成して非データベース・ユーザー名を保存する利点は、DBA_AUDIT_TRAIL、DBA_FGA_AUDIT_TRAIL、DBA_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビューのCLIENT_ID列を問い合せてこのユーザーのアクティビティを監査できることです。

注意:
DBMS_APPLICATION_INFO.SET_CLIENT_INFO設定で値を上書きできることに注意してください。詳細は、「DBMS_SESSION PL/SQLパッケージを使用したクライアント識別子の設定と消去」を参照してください。

Oracle Real Application Clusters環境でのグローバル・アプリケーション・コンテキストの使用

Oracle RAC環境では、グローバル・アプリケーション・コンテキストがロードまたは変更された場合は、常に、既存のアクティブ・インスタンスによってのみ、そのことが認識されます。Oracle RAC環境でグローバル・アプリケーション・コンテキスト値を設定すると、コンテキスト値をすべてのOracle RACインスタンスに一貫して伝播することによるパフォーマンスのオーバーヘッドが生じることに注意してください。

1つのOracle RACインスタンスでグローバル・アプリケーション・コンテキストをフラッシュすると(ALTER SYSTEM FLUSH GLOBAL_CONTEXT SQL文を使用して)、他のすべてのOracle RACインスタンスでも、すべてのグローバル・アプリケーション・コンテキストがフラッシュされます。

グローバル・アプリケーション・コンテキストの作成

グローバル・アプリケーション・コンテキストを作成するには、CREATE CONTEXT SQL文を使用してグローバル・アプリケーション・コンテキストを作成し、ACCESSED GLOBALLY句をこのSQL文に含めます。CREATE CONTEXT文を使用するにはCREATE ANY CONTEXTシステム権限が必要であり、DROP CONTEXT文でコンテキストを削除するにはDROP ANY CONTEXT権限が必要になります。ローカル・アプリケーション・コンテキストと同様、グローバル・アプリケーション・コンテキストもセキュリティ管理者のデータベース・スキーマで作成および格納されます。

グローバル・アプリケーション・コンテキストの所有権については、CREATE ANY CONTEXT権限とDROP ANY CONTEXT権限を付与されたユーザーがそのグローバル・アプリケーション・コンテキストを作成および削除できた場合でも、SYSスキーマが所有しています。Oracle Databaseは、作成したスキーマ・アカウントにコンテキストを関連付けますが、このユーザーを削除した場合、コンテキストはそれでもSYSスキーマの中に存在します。ユーザーSYSであれば、アプリケーション・コンテキストを削除できます。

例6-9に、グローバル・アプリケーション・コンテキストglobal_hr_ctxの作成方法を示します。このコンテキストは、hr_ctx_pkgパッケージを使用して設定されます。

例6-9 グローバル・アプリケーション・コンテキストの作成

CREATE OR REPLACE CONTEXT global_hr_ctx USING hr_ctx_pkg ACCESSED GLOBALLY;

グローバル・アプリケーション・コンテキストを管理するためのPL/SQLパッケージの作成

この項の内容は、次のとおりです。

- グローバル・アプリケーション・コンテキストを管理するパッケージの概要

- エディションがグローバル・アプリケーション・コンテキストのPL/SQLパッケージの結果に与える影響

- DBMS_SESSION.SET_CONTEXTのusernameおよびclient_idパラメータの設定

- 全データベース・ユーザーを対象としたグローバル・アプリケーション・コンテキスト値の共有

- 複数のアプリケーション間を移動するデータベース・ユーザーに対するグローバル・コンテキストの設定

- 非データベース・ユーザーに対するグローバル・アプリケーション・コンテキストの設定

- セッションをクローズする際のセッション・データの消去

DBMS_SESSIONパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

グローバル・アプリケーション・コンテキストを管理するパッケージの概要

グローバル・アプリケーション・コンテキストに関連付けるPL/SQLパッケージのタスクは、DBMS_SESSIONパッケージを使用したグローバル・アプリケーション・コンテキスト値の設定と消去です。このプロシージャを使用するには、DBMS_SESSIONパッケージに対するEXECUTE権限が必要です。通常、このパッケージはセキュリティ管理者のデータベース・スキーマに作成および格納されます。DBMS_SESSIONパッケージはSYSスキーマの所有です。

ローカル・アプリケーション・コンテキストの設定に使用するPL/SQLパッケージとは異なり、ユーザー・セッション・データを取得するSYS_CONTEXT関数は挿入しません。グローバル・アプリケーション・コンテキストでは、接続しているすべてのユーザーにとって、セッションの所有者(USERENVコンテキストに記録される)は同じ所有者となるため、この関数を挿入する必要はありません。

プロシージャは、グローバル・アプリケーション・コンテキストのPL/SQLパッケージ内でいつでも実行できます。グローバル・アプリケーション・コンテキストに関連付けられているパッケージ・プロシージャを実行するために、ログイン・トリガーとログオフ・トリガーを作成する必要はありません。一般的に、パッケージ・プロシージャはデータベース・アプリケーション内から実行します。また、非データベース・ユーザーには、中間層アプリケーションを使用してクライアント・セッションIDを取得および設定します。

エディションがグローバル・アプリケーション・コンテキストのPL/SQLパッケージの結果に与える影響

グローバル・アプリケーション・コンテキストのパッケージ—およびOracle Virtual Private Databaseとファイングレイン監査ポリシーに使用されるパッケージ—の動作を、複数のエディションで次のように制御できます。

- PL/SQLパッケージの結果が、すべてのエディションで同じになるようにします。そのためには、エディションが使用可能になっていないユーザーのスキーマで、パッケージを作成します。エディションが使用可能になっていないユーザーを検索するには、DBA_USERSおよびUSER_USERSデータ・ディクショナリ・ビューを問い合せます。SYS、SYSTEM、およびDBA_REGISTRYデータ・ディクショナリ・ビューにリストされている他のデフォルトのOracle Database管理者アカウントは、エディションが使用不可であり、使用可能にすることもできません。

- PL/SQLパッケージの結果が、パッケージが実行されているエディションの現在の状態に依存するようにします。その結果は、パッケージが適用されるすべてのエディションで異なることがあります。この場合、エディションが使用可能になっているユーザーのスキーマで、パッケージを作成します。スキーマでエディションが使用可能な場合、各エディションに存在するパッケージの実コピーが異なり、各コピーの動作が異なる可能性があります。これは、次のようなシナリオにおいて役立ちます。

- パッケージで新しいアプリケーション・コンテキストを使用する必要がある場合。

- パッケージで、別のスキームを使用して入力値をエンコードする必要がある場合。

- パッケージで、データベースにログインするユーザーに別の検証ルールを適用する必要がある場合。

グローバル・アプリケーション・コンテキストを設定するPL/SQLパッケージでは、1つのgetter関数を使用して、アプリケーション・コンテキストのキー値のペアを読み取る、プリミティブなSYS_CONTEXTコールをラップします。このgetter関数は、アプリケーション・コンテキストのsetterプロシージャと同じパッケージに配置できます。この方法により、関連する概念を反映するように、アプリケーション・コンテキストのキー値をタグ付けできます。たとえば、setter関数が実際に存在するエディションをタグに使用できます。または、コンテキストを設定するセッションの現行エディションを使用できます、これは、SYS_CONTEXT('USERENV', 'CURRENT_EDITION_NAME')を使用して検索できます。このタグには、setter関数を適用する任意の概念を使用できます。

関連項目:
エディションの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

DBMS_SESSION.SET_CONTEXTのusernameおよびclient_idパラメータの設定

DBMS_SESSION.SYS_CONTEXTプロシージャには、namespace、attributeおよびvalueパラメータの他に、client_idパラメータとusernameパラメータも用意されています。これらの設定はグローバル・アプリケーション・コンテキストに使用します。これらの設定の組合せによって、作成可能なグローバル・アプリケーション・コンテキストのタイプがどのように制御されるかについて、表6-2で説明します。

表6-2 DBMS_SESSION.SET_CONTEXTのusernameおよびclient_idパラメータの設定

設定の組合せ

結果

usernameをNULLに設定

client_idをNULLに設定

この組合せでは、すべてのユーザーがアプリケーション・コンテキストにアクセスできます。詳細は、「全データベース・ユーザーを対象としたグローバル・アプリケーション・コンテキスト値の共有」を参照してください。

これらの設定は、データベース・セッション・ベースのアプリケーション・コンテキストにも使用されます。詳細は、「データベース・セッション・ベースのアプリケーション・コンテキストの使用」を参照してください。

usernameをある値に設定

client_idをNULLに設定

この組合せでは、username設定が同じであるかぎり、複数のセッションによるアプリケーション・コンテキストへのアクセスが可能です。指定されているユーザー名は有効なデータベース・ユーザーであることが必要です。詳細は、「複数のアプリケーション間を移動するデータベース・ユーザーに対するグローバル・コンテキストの設定」を参照してください。

usernameをNULLに設定

client_idをある値に設定

この組合せでは、client_idパラメータが同じ値に設定されているかぎり、複数のユーザー・セッションによる1つのアプリケーションへのアクセスが可能です。これによって、全ユーザーのセッションが、アプリケーション・コンテキスト値を参照できます。

usernameをある値に設定

client_idをある値に設定

この組合せでは、次の2つの場合が考えられます。

- 軽量ユーザー。ユーザーにデータベース・アカウントがない場合は、指定されたユーザー名が接続プール所有者です。client_id設定は、ログインしている非データベース・ユーザーに関連付けられます。

- データベース・ユーザー。ユーザーがデータベース・ユーザーの場合、この組合せはステートレスWebセッションに使用できます。

SET_CONTEXTプロシージャのusernameパラメータをUSERに設定すると、Oracle Databaseに用意されているUSER関数がコールされます。このUSER関数によって、アプリケーション・コンテキスト取得プロセスからセッション所有者が指定され、アプリケーション・コンテキストを設定したユーザーのみがコンテキストにアクセスできるようになります。USER関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

詳細は、「非データベース・ユーザーに対するグローバル・アプリケーション・コンテキストの設定」を参照してください。

全データベース・ユーザーを対象としたグローバル・アプリケーション・コンテキスト値の共有

全データベース・ユーザーを対象としてグローバル・アプリケーションの値を共有するには、SET_CONTEXTプロシージャのnamespace、attributeおよびvalueパラメータを設定します。このシナリオでは、データベース・アカウントを持つすべてのユーザーが、そのデータベース内のデータにアクセスできる可能性があります。

例6-10に、このタイプのグローバル・アプリケーション・コンテキストを設定および消去するパッケージの作成方法を示します。

例6-10 全データベース・ユーザーを対象としてグローバル・アプリケーション値を管理するためのパッケージ

CREATE OR REPLACE PACKAGE hr_ctx_pkg
AS
PROCEDURE set_hr_ctx(sec_level IN VARCHAR2);
PROCEDURE clear_hr_context;
END;
/
CREATE OR REPLACE PACKAGE BODY hr_ctx_pkg
AS
PROCEDURE set_hr_ctx(sec_level IN VARCHAR2)
AS
BEGIN
DBMS_SESSION.SET_CONTEXT(
namespace  => 'global_hr_ctx',
attribute  => 'job_role',
value      => sec_level);
END set_hr_ctx;

PROCEDURE clear_hr_context
AS
BEGIN
DBMS_SESSION.CLEAR_CONTEXT('global_hr_ctx', 'job_role');
END clear_context;
END;
/

この例の説明は、次のとおりです。

- DBMS_SESSION.SET_CONTEXT ... END set_hr_ctxは、DBMS_SESSION.SET_CONTEXTプロシージャを使用して、namespace、attributeおよびvalueパラメータの値を設定します。sec_level値は、データベース・アプリケーションがhr_ctx_pkg.set_hr_ctxプロシージャを実行する際に指定されます。
username値とclient_id値は設定されていません。そのためこれらはNULLです。これによりすべてのユーザー(データベース・ユーザー)が値にアクセスできることになり、サーバー全体として適切な設定になります。

- namespace => 'global_hr_ctx'は、namespaceをglobal_hr_ctxに設定します。

- attribute => 'job_role'は、job_role属性を作成します。

- value => sec_levelは、job_role属性の値をsec_levelに設定します。

- PROCEDURE clear_hr_contextは、コンテキスト値を消去するclear_hr_contextプロシージャを作成します。詳細は、「セッションをクローズする際のセッション・データの消去」を参照してください。

通常、このプロシージャは1つのデータベース・アプリケーション内で実行します。たとえば、ログインしているすべてのユーザーが社員であり、「社員」というセキュリティ・レベルを使用する場合は、次の例のようにデータベース・アプリケーション内にコールを埋め込みます。

BEGIN
hr_ctx_pkg.set_hr_ctx('clerk');
END;
/

プロシージャが正常に完了した場合は、次のようにしてアプリケーション・コンテキストの設定をチェックできます。

SELECT SYS_CONTEXT('global_hr_ctx', 'job_role') job_role FROM DUAL;

JOB_ROLE
-----------
clerk

このアプリケーション・コンテキストを消去するには、次のプロシージャを入力します。

BEGIN
hr_ctx_pkg.clear_hr_context;
END;
/

実際に消去されていることをチェックするには、次のSELECT文で値が戻らないことを確認してください。

SELECT SYS_CONTEXT('global_hr_ctx', 'job_role') job_role FROM DUAL;

JOB_ROLE
-----------

注意:
権限が不十分であることを示すエラー・メッセージが表示された場合は、グローバル・アプリケーション・コンテキストが正しく作成されていることを確認してください。また、DBA_CONTEXTデータベース・ビューを問い合せて、設定が正しいこと(作成したスキーマからプロシージャがコールされていることなど)を確認してください。
NULLが戻る場合は、誤ってクライアント識別子を設定した可能性があります。クライアント識別子を消去するには、次のプロシージャを実行します。

EXEC DBMS_SESSION.CLEAR_IDENTIFIER;

複数のアプリケーション間を移動するデータベース・ユーザーに対するグローバル・コンテキストの設定

複数のアプリケーション間を移動するデータベース・ユーザーに対してグローバル・アプリケーション・コンテキストを設定する場合、特に、移動する複数のアプリケーション間でアクセス要件が異なる場合は、SET_CONTEXTプロシージャにusernameパラメータを指定します。このパラメータは、すべてのセッションを対象として同じスキーマを使用することを指定します。

次のSET_CONTEXTパラメータを使用します。

- namespace

- attribute

- value

- username

Oracle Databaseは、username値を一致させることで、他のアプリケーションがアプリケーション・コンテキストを認識できるようにします。これによって、ユーザーは複数のアプリケーション間を移動できます。

client_id設定を省略すると、その値はデフォルトのNULLになります。これは、異なるアプリケーションで同じコンテキストを保持するデータベース・ユーザーに対して同じusernameが設定されている場合は、複数のセッションで値を参照できることを意味します。たとえば、各ユーザーを1つのジョブ・ロールに制限し、Oracle Virtual Private Databaseポリシーを使用してユーザー・アクセスを制御するアプリケーション一式を保持できます。

例6-11に、特定のユーザーが複数のアプリケーション間を移動できるように、usernameパラメータを設定する方法を示します。この例は、例6-10で作成したパッケージに類似しています。usernameパラメータを使用している部分は、太字で記載しています。

例6-11 複数のアプリケーション間を移動するユーザーのグローバル・アプリケーション・コンテキスト値を管理するためのパッケージ

CREATE OR REPLACE PACKAGE hr_ctx_pkg
AS
PROCEDURE set_hr_ctx(sec_level IN VARCHAR2, user_name IN VARCHAR2);
PROCEDURE clear_hr_context;
END;
/
CREATE OR REPLACE PACKAGE BODY hr_ctx_pkg
AS
PROCEDURE set_hr_ctx(sec_level IN VARCHAR2, user_name IN VARCHAR2)
AS
BEGIN
DBMS_SESSION.SET_CONTEXT(
namespace  => 'global_hr_ctx',
attribute  => 'job_role',
value      => sec_level,
username   => user_name);
END set_hr_ctx;

PROCEDURE clear_hr_context
AS
BEGIN
DBMS_SESSION.CLEAR_CONTEXT('global_hr_ctx');
END clear_context;
END;
/

通常は、次の例のようにコールを埋め込むことで、このプロシージャをデータベース・アプリケーション内で実行します。user_nameパラメータの値(この場合はscott)には、必ず有効なデータベース・ユーザー名を指定してください。

BEGIN
hr_ctx_pkg.set_hr_ctx('clerk', 'scott');
END;

このタイプのグローバル・アプリケーション・コンテキストを安全に管理する方法は、自分のアプリケーション範囲内にコードを埋め込み、セキュア・アプリケーション・ロールをユーザーに付与することです。このコードでは、アプリケーション・コンテキストを設定するトラステッドPL/SQLパッケージに対してEXECUTE権限を指定する必要があります。つまり、アプリケーション(ユーザーではなく)がユーザーのコンテキストを設定します。

非データベース・ユーザーに対するグローバル・アプリケーション・コンテキストの設定

非データベース・ユーザー、つまり、データベースに認識されていないユーザー(Webアプリケーション・ユーザーなど)がクライアント・セッションを開始すると、アプリケーション・サーバーによってクライアント・セッションIDが生成されます。このIDは、アプリケーション・サーバーで設定後にデータベース・サーバー側へ渡す必要があります。そのためには、DBMS_SESSION.SET_IDENTIFIERプロシージャを使用してクライアント・セッションIDを設定します。コンテキストを設定するには、サーバー側のPL/SQLプロシージャのDBMS_SESSION.SET_CONTEXTプロシージャにclient_idパラメータを設定します。これでアプリケーション・コンテキストをグローバルに管理できますが、各クライアントには、各自が割り当てられているアプリケーション・コンテキストのみが表示されます。

ここで、client_id値は、グローバル・アプリケーション・コンテキストの正しい属性を取得および設定するためのキーです。クライアント識別子は中間層アプリケーションによって制御され、一度設定されると消去されるまでオープン状態のままです。

このタイプのアプリケーション・コンテキストを管理する一般的な方法は、session_id(client_identifier)の値をCookieに格納し、次のリクエストで戻されるように、エンド・ユーザーのHTMLページに送信する方法です。また、アプリケーションの参照表にクライアント識別子を保持し、他のユーザーのために使用されたり、エンド・ユーザーのセッション・タイムアウトを実装するために利用されるのを防止する必要があります。

非データベース・ユーザーの場合は、次のSET_CONTEXTパラメータを構成します。

- namespace

- attribute

- value

- username

- client_id

例6-12に、このタイプのグローバル・アプリケーション・コンテキストを管理するパッケージの作成方法を示します。

例6-12 非データベース・ユーザーのグローバル・アプリケーション・コンテキスト値を管理するためのパッケージ

CREATE OR REPLACE PACKAGE hr_ctx_pkg
AS
PROCEDURE set_session_id(session_id_p IN NUMBER);
PROCEDURE set_hr_ctx(sec_level_attr IN VARCHAR2,
sec_level_val IN VARCHAR2);
PROCEDURE clear_hr_session(session_id_p IN NUMBER);
PROCEDURE clear_hr_context;
END;
/
CREATE OR REPLACE PACKAGE BODY hr_ctx_pkg
AS
session_id_global NUMBER;
PROCEDURE set_session_id(session_id_p IN NUMBER)
AS
BEGIN
session_id_global := session_id_p;
DBMS_SESSION.SET_IDENTIFIER(session_id_p);
END set_session_id;

PROCEDURE set_hr_ctx(sec_level_attr IN VARCHAR2,
sec_level_val IN VARCHAR2)
AS
BEGIN
DBMS_SESSION.SET_CONTEXT(
namespace  => 'global_hr_ctx',
attribute  => sec_level_attr,
value      => sec_level_val,
username   => USER,
client_id  => session_id_global);
END set_hr_ctx;

PROCEDURE clear_hr_session(session_id_p IN NUMBER)
AS
BEGIN
DBMS_SESSION.SET_IDENTIFIER(session_id_p);
DBMS_SESSION.CLEAR_IDENTIFIER;
END clear_hr_session;

PROCEDURE clear_hr_context
AS
BEGIN
DBMS_SESSION.CLEAR_CONTEXT('global_hr_ctx', session_id_global);
END clear_hr_context;
END;
/

この例の説明は、次のとおりです。

- session_id_global NUMBERは、クライアント・セッションIDを格納するsession_id_global変数を作成します。このsession_id_global変数は、グローバル・アプリケーション・コンテキストの属性を作成して値を割り当てるプロシージャも含めて、パッケージ定義全体から参照されます。これは、グローバル・アプリケーション・コンテキストの値が、この特定のセッションIDと常に関連付けられることを意味します。

- PROCEDURE set_session_id ... END set_session_idは、set_session_idプロシージャを作成します。これは、クライアント・セッションIDをsession_id_global変数に書き込むプロシージャです。

- PROCEDURE set_hr_ctx ... END set_hr_ctxは、set_hr_ctxプロシージャを作成します。このプロシージャによりグローバル・アプリケーション・コンテキスト属性が作成されて、これらの属性に値を割り当てることができるようになります。このプロシージャ内では、次のように設定されます。

- username = USERは、username値を指定します。この例では、Oracle Databaseによって指定される、コンテキスト取得プロセスからセッション所有者を追加するためのUSER関数を呼び出すことによって設定します。USER関数によって、アプリケーション・コンテキストを設定するユーザーのみがコンテキストにアクセスできるようになります。USER関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
NULL(usernameパラメータのデフォルト)を指定すると、すべてのユーザーがコンテキストにアクセスできるようになります。

username値とclient_id値の両方を設定した場合は、2つの異なる使用目的が考えられます。軽量ユーザーの場合は、usernameパラメータに対して接続プール所有者(APPS_USERなど)を設定し、client_idに対してクライアント・セッションIDを設定します。ステートレスWebセッションを使用する場合は、ログインしたユーザーと同じデータベース・ユーザーをuser_nameパラメータに設定し、このユーザーが同じクライアント・セッションIDを保持していることを確認します。異なるusernameとclient_idを設定した場合の動作の例は、「DBMS_SESSION.SET_CONTEXTのusernameおよびclient_idパラメータの設定」を参照してください。

- client_id => session_id_globalは、client_id値を指定します。この例では、この値をsession_id_global変数に設定しています。これによって、ここで定義したコンテキスト設定が特定のクライアント・セッションID(つまり、set_session_idプロシージャを実行する際に設定されるID)に関連付けられます。client_idパラメータにデフォルトのNULLを指定すると、すべてのセッションでグローバル・アプリケーション・コンテキストの設定を使用できるようになります。

- PROCEDURE clear_hr_session ... END clear_hr_sessionは、クライアント・セッション識別子を消去するclear_hr_sessionプロシージャを作成します。33行目: 正しいセッションID、つまり10行目で定義されている変数session_id_pに格納されているIDを消去するように設定します。

- PROCEDURE clear_hr_context ... END clear_hr_contextは、clear_hr_contextプロシージャを作成します。このプロシージャは、global_hr_ctx変数によって定義された現行のユーザー・セッションのコンテキスト設定を消去します。詳細は、「セッションをクローズする際のセッション・データの消去」を参照してください。

関連項目:

- クライアント・セッションIDを使用するグローバル・アプリケーション・コンテキストがどのように機能するかを示す例は、「例: クライアント・セッションIDを使用するグローバル・アプリケーション・コンテキストの作成」を参照してください。

- 「中間層アプリケーションを使用したクライアント・セッションIDの設定」

- 中間層システムでのクライアント識別子の動作の詳細は、「データベースに認識されないアプリケーション・ユーザーの識別でのクライアント識別子の使用」を参照してください。

セッションをクローズする際のセッション・データの消去

アプリケーション・コンテキストは、すべてがメモリー内に存在します。ユーザーがセッションを終了したときは、client_identifier値のコンテキストを消去する必要があります。この消去によってメモリーが解放され、残存している値を他のユーザーが誤って使用することがなくなります。

ユーザーのセッション終了時にセッション・データを消去するには、サーバー側のPL/SQLパッケージで、次のいずれかの方法を使用します。

- ユーザーがセッションを終了したときにクライアント識別子を消去する方法。DBMS_SESSION.CLEAR_IDENTIFIERプロシージャを使用します。次に例を示します。

DBMS_SESSION.CLEAR_IDENTIFIER;

- コンテキストを消去してもセッションを続行する方法。セッションを続行しながらコンテキストを消去する必要がある場合は、DBMS_SESSION.CLEAR_CONTEXTまたはDBMS_SESSION.CLEAR_ALL_CONTEXTプロシージャを使用します。次に例を示します。

DBMS_SESSION.CLEAR_CONTEXT('my_ctx', 'my_attribute');

CLEAR_CONTEXTプロシージャは現行ユーザーのコンテキストを消去します。たとえば、アプリケーション・サーバーを停止する必要がある場合など、すべてのユーザーのコンテキスト値を消去するには、CLEAR_ALL_CONTEXTプロシージャを使用します。

グローバル・アプリケーション・コンテキスト値は消去されるまで使用可能です。したがって、他のセッションがこれらの値にアクセスしないように、CLEAR_CONTEXTまたはCLEAR_ALL_CONTEXTを使用してください。コンテキストの値が変更された場合、その内容はただちに反映され、SYS_CONTEXTファンクションによって値を取得する後続のコールでは、最新の値が戻されます。

クライアント・セッションIDを管理するための中間層アプリケーションへのコールの埋込み

この項の内容は、次のとおりです。

- 中間層アプリケーションを使用したクライアント・セッションIDの管理の概要

- 中間層アプリケーションを使用したクライアント・セッションIDの取得

- 中間層アプリケーションを使用したクライアント・セッションIDの設定

- 中間層アプリケーションを使用したセッション・データの消去

中間層アプリケーションを使用したクライアント・セッションIDの管理の概要

アプリケーション・サーバーはクライアント・セッションIDを生成します。中間層アプリケーションから、クライアント・セッションIDを取得、設定、および消去できます。そのためには、Oracle Call Interface (OCI)コールとDBMS_SESSION PL/SQLパッケージ・プロシージャのどちらかを中間層アプリケーション・コードに埋め込みます。

アプリケーションによってユーザーが認証され、クライアント識別子が設定されてカレント・セッションに設定されます。PL/SQLパッケージSET_CONTEXTによって、アプリケーション・コンテキストにclient_identifier値が設定されます。詳細は、「非データベース・ユーザーに対するグローバル・アプリケーション・コンテキストの設定」を参照してください。

中間層アプリケーションを使用したクライアント・セッションIDの取得

ユーザーがクライアント・セッションを開始すると、アプリケーション・サーバーでクライアント・セッションIDが生成されます。このクライアントIDを取得するには、次のいずれかの文でOCIStmtExecuteコールを使用します。

SELECT SYS_CONTEXT('userenv', 'client_identifier') FROM dual;

SELECT CLIENT_IDENTIFIER from V$SESSION;

SELECT value FROM session_context WHERE attribute='CLIENT_IDENTIFIER';

例6-13に、OCIStmtExecuteコールを使用してクライアント・セッションIDを取得する方法を示します。

例6-13 OCIStmtExecuteを使用したクライアント・セッションID値の取得

oratext    clientid[31];
OCIDefine  *defnp1 = (OCIDefine *) 0;
OCIStmt    *statementhndle;
oratext    *selcid = (oratext *)"SELECT SYS_CONTEXT('userenv',
'client_identifier') FROM  DUAL";

OCIStmtPrepare(statementhndle, errhp, selcid,
(ub4) strlen((char *) selcid), (ub4) OCI_NTV_SYNTAX, (ub4) OCI_DEFAULT);

OCIDefineByPos(statementhndle, &defnp1, errhp, 1, (dvoid *)clientid, 31,
SQLT_STR, (dvoid *) 0, (ub2 *) 0, (ub2 *) 0, OCI_DEFAULT);

OCIStmtExecute(servhndle, statementhndle, errhp, (ub4) 1, (ub4) 0,
(CONST OCISnapshot *) NULL, (OCISnapshot *) NULL, OCI_DEFAULT);

printf("CLIENT_IDENTIFIER = %s \n", clientid);

この例の説明は、次のとおりです。

- oratext、OCIDefine、OCIStmtおよびoratextは、クライアント・セッションID、OCIDefineの参照コール、文ハンドルおよび使用するSELECT文を格納するための変数を作成します。

- OCIStmtPrepareは、文selcidを実行する準備を整えます。

- OCIDefineByPosは、クライアント・セッションIDの出力変数clientidを定義します。

- OCIStmtExecuteは、selcid変数に格納されている文を実行します。

- printfは、取得したクライアント・セッションIDに書式を設定した出力を表示します。

中間層アプリケーションを使用したクライアント・セッションIDの設定

OCIStmtExecuteコールを使用してクライアント・セッションIDを取得した後は、このIDを設定できます。サーバー側のPL/SQLパッケージのDBMS_SESSION.SET_CONTEXTプロシージャによってこのセッションIDを設定した後、必要に応じてアプリケーション・コンテキスト値を上書きします。

中間層アプリケーション・コードにより、クライアント・セッションID値(前の例でuser_idに書き込まれた値など)がサーバー側のDBMS_SESSION.SET_CONTEXTプロシージャで定義されているclient_id設定と一致することが確認されるようにします。アプリケーション・サーバー側では、次の順序でコールする必要があります。

1. 現行のクライアント・セッションIDを取得します。セッションにはこのIDがすでに設定されていますが、本当に正しい値かどうかを確認するほうが安全です。

2. 現行のクライアント・セッションIDを消去します。消去することで、異なるエンド・ユーザーからのリクエストにサービスを提供するようにアプリケーションを準備します。

3. 新規クライアント・セッションIDまたはエンド・ユーザーに割当て済のクライアント・セッションIDを設定します。この設定によって、セッションは異なるグローバル・アプリケーション・コンテキストの値セットを使用するようになります。

次の方法を使用して、アプリケーション・サーバー側にクライアント・セッションIDを設定できます。

- Oracle Call Interface。OCIAttrSet OCIコールにOCI_ATTR_CLIENT_IDENTIFIER属性を設定します。この属性は、エンド・ユーザーの識別情報を追跡するためのクライアント識別子をセッション・ハンドルに設定します。
次の例は、OCIAttrSetでATTR_CLIENT_IDENTIFIERパラメータを使用する方法を示しています。user_id設定は、ログインしているユーザーのIDが格納されている変数を参照します。

OCIAttrSet((void *)session_handle, (ub4) OCI_HTYPE_SESSION,
(void *) user_id, (ub4)strlen(user_id),
OCI_ATTR_CLIENT_IDENTIFIER, error_handle);

- DBMS_SESSIONパッケージ。DBMS_SESSION.SET_IDENTIFIERプロシージャを使用して、グローバル・アプリケーション・コンテキストのクライアント識別子を設定します。たとえば、ログインしているユーザーのIDをuser_idという変数に格納している場合は、中間層アプリケーションのコードに次の行を入力することになります。

DBMS_SESSION.SET_IDENTIFIER(user_id);

注意:
アプリケーションでCLIENT_IDENTIFIERとして使用するセッションIDを生成する場合、そのセッションIDは適度にランダムで、ネットワーク上では暗号化によって保護されている必要があります。セッションIDがランダムでない場合は、不正なユーザーがセッションIDを推測し、他のユーザーのデータにアクセスする可能性があります。セッションIDがネットワーク上で暗号化されていない場合は、不正なユーザーがセッションIDを取得して、接続にアクセスする可能性があります。
セッションIDは、Oracle Advanced Securityを使用して暗号化できます。詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。ネットワークを介したデータの暗号化については、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

OCIAttrSetおよびDBMS_SESSION.SET_IDENTIFIERでは、次のようにして、この識別子の値をチェックできます。

SELECT SYS_CONTEXT('userenv', 'client_identifier') FROM dual;

この値をチェックする他の方法には、V$SESSIONビューを問い合せる方法があります。

SELECT CLIENT_IDENTIFIER from V$SESSION;

中間層アプリケーションを使用したセッション・データの消去

アプリケーション・コンテキストは、すべてがメモリー内に存在します。ユーザーがセッションを終了したときは、client_identifier値のコンテキストを消去する必要があります。この消去によってメモリーが解放され、残存している値を他のユーザーが誤って使用することがなくなります。

ユーザーのセッション終了時にセッション・データを消去するには、中間層アプリケーションのコードで、次のいずれかの方法を使用します。

- ユーザーがセッションを終了したときにクライアント識別子を消去する方法。DBMS_SESSION.CLEAR_IDENTIFIERプロシージャを使用します。次に例を示します。

DBMS_SESSION.CLEAR_IDENTIFIER;

- コンテキストを消去してもセッションを続行する方法。セッションを続行しながらコンテキストを消去する必要がある場合は、DBMS_SESSION.CLEAR_CONTEXTまたはDBMS_SESSION.CLEAR_ALL_CONTEXTプロシージャを使用します。次に例を示します。

DBMS_SESSION.CLEAR_CONTEXT(namespace, client_identifier, attribute);

CLEAR_CONTEXTプロシージャは現行ユーザーのコンテキストを消去します。たとえば、アプリケーション・サーバーを停止する必要がある場合など、すべてのユーザーのコンテキスト値を消去するには、CLEAR_ALL_CONTEXTプロシージャを使用します。

グローバル・アプリケーション・コンテキスト値は消去されるまで使用可能です。したがって、他のセッションがこれらの値にアクセスしないように、CLEAR_CONTEXTまたはCLEAR_ALL_CONTEXTを使用してください。

例: クライアント・セッションIDを使用するグローバル・アプリケーション・コンテキストの作成

この項の内容は、次のとおりです。

- このチュートリアルの概要

- 手順1: ユーザー・アカウントの作成

- 手順2: グローバル・アプリケーション・コンテキストの作成

- 手順3: グローバル・アプリケーション・コンテキストのパッケージの作成

- 手順4: グローバル・アプリケーション・コンテキストのテスト

- 手順5: この例で使用したコンポーネントの削除

このチュートリアルの概要

この例は、軽量ユーザーのアプリケーション用にクライアント・セッションIDを使用するグローバル・アプリケーション・コンテキストを作成する方法を示しています。非データベース・ユーザーの接続プールを使用したアクセスを制御する方法を示しています。

手順1: ユーザー・アカウントの作成

この例では、2人のユーザー(アプリケーション・コンテキストとそのパッケージを管理するセキュリティ管理者と、接続プールを所有するユーザー・アカウント)を作成する必要があります。

手順は、次のとおりです。

1. SYSでSQL*Plusにログインし、AS SYSDBAを使用して接続します。

sqlplus sys as sysdba
Enter password: password

2. sysadmin_ctxアカウントを作成します。このアカウントは、グローバル・アプリケーション・コンテキストを管理します。

GRANT CREATE SESSION, CREATE ANY CONTEXT, CREATE PROCEDURE TO sysadmin_ctx IDENTIFIED BY password;

GRANT EXECUTE ON DBMS_SESSION TO sysadmin_ctx;

passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。

3. 接続プールの所有者にするデータベース・アカウントapps_userを作成します。

GRANT CREATE SESSION TO apps_user IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。

手順2: グローバル・アプリケーション・コンテキストの作成

1. セキュリティ管理者sysadmin_ctxでログインします。

CONNECT sysadmin_ctx
Enter password: password

2. cust_ctxグローバル・アプリケーション・コンテキストを作成します。

CREATE CONTEXT global_cust_ctx USING cust_ctx_pkg ACCESSED GLOBALLY;

cust_ctxコンテキストが作成され、セキュリティ管理者sysadmin_ctxのスキーマに関連付けられます。ただし、アプリケーション・コンテキストはSYSスキーマが所有します。

手順3: グローバル・アプリケーション・コンテキストのパッケージの作成

1. sysadmin_ctxとして、次のPL/SQLパッケージを作成します。

CREATE OR REPLACE PACKAGE cust_ctx_pkg
AS
PROCEDURE set_session_id(session_id_p IN NUMBER);
PROCEDURE set_cust_ctx(sec_level_attr IN VARCHAR2,
sec_level_val IN VARCHAR2);
PROCEDURE clear_hr_session(session_id_p IN NUMBER);
PROCEDURE clear_hr_context;
END;
/
CREATE OR REPLACE PACKAGE BODY cust_ctx_pkg
AS
session_id_global NUMBER;

PROCEDURE set_session_id(session_id_p IN NUMBER)
AS
BEGIN
session_id_global := session_id_p;
DBMS_SESSION.SET_IDENTIFIER(session_id_p);
END set_session_id;

PROCEDURE set_cust_ctx(sec_level_attr IN VARCHAR2, sec_level_val IN VARCHAR2)
AS
BEGIN
DBMS_SESSION.SET_CONTEXT(
namespace  => 'global_cust_ctx',
attribute  => sec_level_attr,
value      => sec_level_val,
username   => USER, -- Retrieves the session user, in this case, apps_user
client_id  => session_id_global);
END set_cust_ctx;

PROCEDURE clear_hr_session(session_id_p IN NUMBER)
AS
BEGIN
DBMS_SESSION.SET_IDENTIFIER(session_id_p);
DBMS_SESSION.CLEAR_IDENTIFIER;
END clear_hr_session;

PROCEDURE clear_hr_context
AS
BEGIN
DBMS_SESSION.CLEAR_CONTEXT('global_cust_ctx', session_id_global);
END clear_hr_context;
END;
/

このタイプのパッケージの動作に関する詳細説明は、例6-12を参照してください。

2. cust_ctx_pkgパッケージに対するEXECUTE権限を接続プール所有者apps_userに付与します。

GRANT EXECUTE ON cust_ctx_pkg TO apps_user;

手順4: グローバル・アプリケーション・コンテキストのテスト

この時点で、このグローバル・アプリケーション・コンテキストとセッションIDの設定について動作を確認します。

1. 接続プール所有者(ユーザーapps_user)でSQL*Plusにログインします。

CONNECT apps_user
Enter password: password

2. 接続プール・ユーザーのログイン時に、アプリケーションでは、次のようにクライアント・セッション識別子が設定されます。

BEGIN
sysadmin_ctx.cust_ctx_pkg.set_session_id(34256);
END;
/

クライアント・セッション識別子の値は、次のようにテストしてチェックできます。

1. 接続プール・ユーザーapps_userでSQL*Plusに接続します。

2. セッションIDを設定します。

EXEC sysadmin_ctx.cust_ctx_pkg.set_session_id(34256);

3. セッションIDをチェックします。

SELECT SYS_CONTEXT('userenv', 'client_identifier') FROM dual;

次の出力が表示されます。

SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER')
--------------------------------------------------
34256

3. ユーザーapps_userで、グローバル・アプリケーション・コンテキストを次のように設定します。

EXEC sysadmin_ctx.cust_ctx_pkg.set_cust_ctx('Category', 'Gold Partner');
EXEC sysadmin_ctx.cust_ctx_pkg.set_cust_ctx('Benefit Level', 'Highest');

(実際には、手順2でクライアント・セッション識別子を設定した方法と同様に、中間層アプリケーションでグローバル・アプリケーション・コンテキスト値を設定することになります。)

4. 次のSELECT SYS_CONTEXT文を入力し、設定が正しいことをチェックします。

col category format a13
col benefit_level format a14

SELECT SYS_CONTEXT('global_cust_ctx', 'Category') category, SYS_CONTEXT('global_cust_ctx', 'Benefit Level') benefit_level FROM dual;

次の出力が表示されます。

CATEGORY       BENEFIT_LEVEL
-------------  --------------
Gold Partner   Highest

apps_userがここで(クライアント・セッション34256内で)実行したのは、非データベース・ユーザーにかわってグローバル・アプリケーション・コンテキストを設定したことです。このコンテキストは、DBMS_SESSION.SET_CONTEXTのCategoryおよびBenefit Level属性をそれぞれGold PartnerおよびHighestに設定します。このコンテキストは、クライアントID 34256のユーザーapps_userに対してのみ存在します。非データベース・ユーザーがバックグラウンドでログインした場合、そのユーザーは、実際には接続プール・ユーザーapps_userでログインしたことになります。このようにして、非データベース・ユーザーは、Gold PartnerおよびHighestのコンテキスト値を使用できます。

データベース・ユーザーであるユーザーが、相応のアプリケーションを使用せずにログインすると仮定します。(たとえば、SQL*Plusを使用してログインします。)このユーザーは接続プール・ユーザー(apps_user)でログインしていないため、グローバル・アプリケーション・コンテキストは、該当しないユーザーに対して空で表示されます。これは、このコンテキストがapps_userセッションで作成および設定されていたためです。ユーザーがSELECT SYS_CONTEXT文を実行すると、次の出力が表示されます。

CATEGORY       BENEFIT_LEVEL
-------------  --------------

次に、次のテストを試してください。

1. ユーザーapps_userとして、セッションIDを消去します。

EXEC sysadmin_ctx.cust_ctx_pkg.clear_hr_session(34256);

2. グローバル・アプリケーション・コンテキストを再度チェックしてください。

SELECT SYS_CONTEXT('global_cust_ctx', 'Category') category, SYS_CONTEXT('global_cust_ctx', 'Benefit Level') benefit_level FROM dual;

CATEGORY       BENEFIT_LEVEL
-------------  --------------

apps_userによってセッションIDが消去されたため、グローバル・アプリケーション・コンテキストの設定は使用できません。

3. セッションIDに34256をリストアしてから、コンテキスト値をチェックします。

EXEC sysadmin_ctx.cust_ctx_pkg.set_session_id(34256);

SELECT SYS_CONTEXT('global_cust_ctx', 'Category') category, SYS_CONTEXT('global_cust_ctx', 'Benefit Level') benefit_level FROM dual;

次の出力が表示されます。

CATEGORY       BENEFIT_LEVEL
-------------  --------------
Gold Partner   Highest

このように、セッションIDを34256に再設定すると、アプリケーション・コンテキスト値が元に戻ります。要約すると、グローバル・アプリケーション・コンテキストはこのユーザーに対して1度のみ設定しますが、クライアント・セッションIDはユーザーがログインするたびに設定する必要があります。

4. ここで、グローバル・アプリケーション・コンテキストの値を消去した後、その値をチェックしてください。

EXEC sysadmin_ctx.cust_ctx_pkg.clear_hr_context;

SELECT SYS_CONTEXT('global_cust_ctx', 'Category') category, SYS_CONTEXT('global_cust_ctx', 'Benefit Level') benefit_level FROM dual;

次の出力が表示されます。

CATEGORY       BENEFIT_LEVEL
-------------  --------------

この時点では、クライアント・セッションIDの34256は適切に設定されていますが、アプリケーション・コンテキストの設定はすでに存在していません。これで、以前に設定したアプリケーション・コンテキストの値を使用せずに、このユーザーのセッションを続行できます。

手順5: この例で使用したコンポーネントの削除

1. SYSでログインし、AS SYSDBAを使用して接続します。

CONNECT sys/as sysdba
Enter password: password

2. グローバル・アプリケーション・コンテキストを削除します。

DROP CONTEXT global_cust_ctx;

このグローバル・アプリケーション・コンテキストはsysadmin_ctxが作成しましたが、SYSスキーマの所有となっていることに注意してください。

3. 2人のサンプル・ユーザーを削除します。

DROP USER sysadmin_ctx CASCADE;
DROP USER apps_user;

グローバル・アプリケーション・コンテキスト・プロセス

この項の内容は、次のとおりです。

- 単純なグローバル・アプリケーション・コンテキスト・プロセス

- 軽量ユーザー用のグローバル・アプリケーション・コンテキスト・プロセス

単純なグローバル・アプリケーション・コンテキスト・プロセス

クライアント識別子12345をクライアントSCOTTに割り当てたアプリケーション・サーバーAppSvrを想定します。AppSvrアプリケーションは、セッションを作成するためにSCOTTユーザーを使用します(つまり、接続プールではありません)。コンテキスト属性に割り当てる値には、ユーザーの職責コードが入っている表でSELECT文を実行して取得された値など、あらゆる値を使用できます。アプリケーション・コンテキストは移入されると、メモリーに保存されます。そのため、職責コードを必要とするアクションはSYS_CONTEXTコールによってすぐに職責コードにアクセスできるようになり、表にアクセスするオーバーヘッドもありません。このケースのローカル・コンテキストに対するグローバル・コンテキストの唯一の利点は、SCOTTがアプリケーションを頻繁に変更して、各アプリケーションで同じコンテキストを使用したような場合です。

次の手順は、グローバル・アプリケーション・コンテキスト・プロセスでSCOTTのクライアント識別子を設定する方法を示しています。

1. 管理者は次の文を使用して、グローバル・コンテキスト・ネームスペースを作成します。

CREATE OR REPLACE CONTEXT hr_ctx USING hr.init ACCESSED GLOBALLY;

2. 管理者は、hr_ctxアプリケーション・コンテキスト用にPL/SQLパッケージを作成し、このクライアント識別子には、HRネームスペースに値13があるresponsibilityと呼ばれるアプリケーション・コンテキストがあることを示します。

CREATE OR REPLACE PROCEDURE hr.init
AS
BEGIN
DBMS_SESSION.SET_CONTEXT(
namespace => 'hr_ctx',
attribute => 'responsibility',
value     => '13',
username  => 'SCOTT',
client_id => '12345' );
END;
/

このPL/SQLプロシージャはHRデータベース・スキーマに格納されていますが、通常は、セキュリティ管理者のスキーマに格納されます。

3. scottがAppSvrを使用してデータベースに接続するたびに、AppSvrアプリケーションによって、次のコマンドが発行され、接続クライアントの識別情報が指定されます。

EXEC DBMS_SESSION.SET_IDENTIFIER('12345');

4. データベース・セッション内にSYS_CONTEXT('hr_ctx','responsibility')コールがある場合、データベースによって、クライアント識別子12345がグローバル・コンテキストと照合され、値13が戻されます。

5. このデータベース・セッションの終了時には、AppSvrによって、次のプロシージャが発行され、クライアント識別子が消去されます。

EXEC DBMS_SESSION.CLEAR_IDENTIFIER( );

6. アプリケーション・コンテキストによって使用されたメモリーを解放するために、AppSvrは次のプロシージャを発行します。

DBMS_SESSION.CLEAR_CONTEXT('hr_ctx', '12345');

CLEAR_CONTEXTが必要なのは、ユーザー・セッションが、明示的なログアウト、タイムアウトまたはAppSvrアプリケーションで判断される他の状況でアクティブでない場合です。

注意:
セッションのクライアント識別子は、消去されるとNULL値になります。したがって、後続のSYS_CONTEXTコールでは、SET_IDENTIFIERインタフェースを使用してクライアント識別子を再設定しないかぎり、クライアント識別子がNULLのアプリケーション・コンテキストのみが取得されます。

軽量ユーザー用のグローバル・アプリケーション・コンテキスト・プロセス

次の手順は、軽量ユーザー・アプリケーション用のグローバル・アプリケーション・コンテキスト・プロセスを示しています。軽量ユーザーrobertは、アプリケーションを介してデータベースに認識されていません。

1. 管理者は次の文を使用して、グローバル・コンテキスト・ネームスペースを作成します。

CREATE CONTEXT hr_ctx USING hr.init ACCESSED GLOBALLY;

2. HRアプリケーション・サーバーAppSvrが起動し、ユーザーappsmgrとしてHRデータベースへの複数の接続を確立します。

3. ユーザーrobertがHRアプリケーション・サーバーにログインします。

4. AppSvrがアプリケーションに対してrobertを認証します。

5. AppSvrがこの接続に対して一時的なセッションID12345を割り当てます(またはアプリケーション・ユーザーIDを使用します)。

6. セッションIDが、robertが使用するWebブラウザにCookieの一部として戻されるか、またはAppSvrによって保持されます。

7. AppSvrがhr.initパッケージをコールして、このクライアントのアプリケーション・コンテキストを初期化すると、次の文が発行されます。

DBMS_SESSION.SET_CONTEXT( 'hr_ctx', 'id', 'robert', 'APPSMGR', 12345 );
DBMS_SESSION.SET_CONTEXT( 'hr_ctx', 'dept', 'sales', 'APPSMGR', 12345 );

8. AppSvrがこのセッションにデータベース接続を割り当て、次の文を発行してセッションを初期化します。

DBMS_SESSION.SET_IDENTIFIER( 12345 );

9. このデータベース・セッション内のすべてのSYS_CONTEXTコールが、そのクライアントのセッションのみに属するアプリケーション・コンテキストの値を戻します。
たとえば、SYS_CONTEXT('hr','id')は、robertという値を戻します。

10. セッションが終了すると、AppSvrは次の文を発行してクライアントの識別情報を消去します。

DBMS_SESSION.CLEAR_IDENTIFIER ( );

他のユーザーがデータベースにログインした場合でも、このユーザーはAppSvrによって設定されたグローバル・コンテキストにはアクセスできません。これは、AppSvrが、ユーザーAPPSMGRがログインしたアプリケーションのみがこのグローバル・コンテキストを認識できるように指定したためです。AppSvrが次の文を使用した場合、クライアントIDが12345に設定されたあらゆるユーザー・セッションがグローバル・コンテキストを認識できるようになります。

DBMS_SESSION.SET_CONTEXT( 'hr_ctx', 'id', 'robert', NULL , 12345 );
DBMS_SESSION.SET_CONTEXT( 'hr_ctx', 'dept', 'sales', NULL , 12345 );

USERNAMEをNULLに設定すると、異なるユーザーが同一のコンテキストを共有できます。

注意:
グローバル・コンテキストの設定が異なると、セキュリティ上の意味が変わることを認識する必要があります。ユーザー名にNULLが指定されている場合は、すべてのユーザーがそのグローバル・コンテキストにアクセスできます。グローバル・コンテキストのクライアントIDにNULLが指定されている場合、そのグローバル・コンテキストにアクセスできるのは、初期化されていないクライアントIDを持つセッションです。セッションへのアクセスをログインしたユーザーのみに制限するには、NULLのかわりにUSERを指定します。

セッションに設定されたクライアント識別子は、次のように問い合せることができます。

SELECT SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') FROM dual;

次の出力が表示されます。

SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER')
-------------------------------------------------
12345

セキュリティ管理者は、V$SESSIONビューのCLIENT_IDENTIFIERおよびUSERNAMEを問い合せることで、どのセッションにクライアント識別子が設定されているかを確認できます。次に例を示します。

COL client_identifier format a18
SELECT CLIENT_IDENTIFIER, USERNAME from V$SESSION;

次の出力が表示されます。

CLIENT_IDENTIFIER   USERNAME
------------------  --------
12345               APPSMGR

グローバル・コンテキストの使用領域(バイト単位)をチェックするには、次の問合せを使用します。

SELECT SYS_CONTEXT('USERENV','GLOBAL_CONTEXT_MEMORY') FROM dual;

次の出力が表示されます。

SYS_CONTEXT('USERENV','GLOBAL_CONTEXT_MEMORY')
----------------------------------------------
584

関連項目:
USERENVアプリケーション・コンテキストの事前定義属性であるCLIENT_IDENTIFIERの使用の詳細は、次を参照してください。

- 「CLIENT_IDENTIFIER属性を使用したユーザー識別情報の保持」

- 『Oracle Database SQL言語リファレンス』

- 『Oracle Call Interfaceプログラマーズ・ガイド』

クライアント・セッション・ベースのアプリケーション・コンテキストの使用

この項の内容は、次のとおりです。

- クライアント・セッション・ベースのアプリケーション・コンテキストの概要

- CLIENTCONTEXTネームスペースへの値の設定

- CLIENTCONTEXTネームスペースの取得

- CLIENTCONTEXTネームスペースの設定の消去

- CLIENTCONTEXTネームスペースのすべての設定の消去

クライアント・セッション・ベースのアプリケーション・コンテキストの概要

クライアント・セッション・ベースのアプリケーション・コンテキストでは、Oracle Call Interface(OCI)関数を使用してユーザー・セッション情報を設定および消去します。このユーザー・セッション情報はユーザー・グローバル領域(UGA)に格納されます。

このタイプのアプリケーション・コンテキストの利点は、個々のアプリケーションが特定の非データベース・ユーザー・セッション・データを確認でき、このタスクをデータベースで実行しないことです。もう1つの利点は、アプリケーション・コンテキスト値を設定するコールはサーバーに対する次のコールに含まれるため、パフォーマンスが向上するという点です。

ただし、アプリケーション・コンテキストは、クライアント・セッション・ベースのアプリケーション・コンテキストではセキュリティを維持できなくなる点に注意が必要です。具体的には、アプリケーション・ユーザーがクライアント・アプリケーション・コンテキストを設定できるようになり、データベースでのチェックが一切実行されません。

クライアント・セッション・ベースのアプリケーション・コンテキストは、クライアント・アプリケーションに対してのみ構成します。クライアントの接続先データベース・サーバーには、設定を構成しません。データベース・サーバーのアプリケーション・コンテキスト設定は、クライアント・セッション・ベースのアプリケーション・コンテキストに影響を与えません。

クライアント・セッション・ベースのアプリケーション・コンテキストを構成するには、OCI関数OCIAppCtxSetを使用します。CLIENTCONTEXTネームスペースを使用するクライアント・セッション・ベースのアプリケーション・コンテキストは、OCIクライアントまたはアプリケーション・コンテキストの既存のDBMS_SESSIONパッケージで更新できます。このタイプのコンテキストでは、権限またはパッケージ・セキュリティのチェックは実行されません。

CLIENTCONTEXTネームスペースを使用すると、1つのアプリケーション・トランザクションで、ユーザー・コンテキスト情報を変更することと、同じユーザー・セッション・ハンドルを使用して新規ユーザー・リクエストに対応することの両方が可能になります。CLIENTCONTEXTネームスペースで属性の個々の値を設定または消去することも、すべての値を消去することもできます。

- OCIクライアントではOCIAppCtx関数を使用して、ネームスペースOCISessionHandleの可変長データを設定します。OCIネットワークの単一ラウンドトリップ転送は、1回のラウンドトリップで全情報をサーバーに送信します。サーバー側では、ネームスペースに対してSYS_CONTEXT SQL関数を使用することで、アプリケーション・コンテキスト情報を問い合せることができます。次に例を示します。

- JDBCクライアントでは、oracle.jdbc.internal.OracleConnection関数を使用してこれと同じことを実行します。

CLIENTCONTEXTネームスペースはパッケージ・ベースのセキュリティで保護されていないため、すべてのユーザーがこのネームスペース内の情報を設定、消去または収集できます。

関連項目:
クライアント・アプリケーション・コンテキストの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

CLIENTCONTEXTネームスペースへの値の設定

Oracle Call Interfaceの場合、CLIENTCONTEXTネームスペースに値を設定するには、次の構文に従ってコマンドを使用します。

err = OCIAppCtxSet((void *) session_handle,(dvoid *)"CLIENTCONTEXT",(ub4) 13,
(dvoid *)attribute_name, length_of_attribute_name
(dvoid *)attribute_value, length_of_attribute_value, errhp,
OCI_DEFAULT);

次のように値を指定します。

- session_handle: OCISessionHandleネームスペースを表します。

- attribute_name: 属性の名前を示します。たとえば、長さ14のresponsibilityを指定します。

- attribute_value: 属性の値を示します。たとえば、長さ7のmanagerを指定します。

関連項目:
OCIAppCtx関数の詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』のスケーラブル・プラットフォームの管理に関する項を参照してください。

CLIENTCONTEXTネームスペースの取得

CLIENTCONTEXTネームスペースを取得するには、次のいずれかの文でOracle Call Interface OCIStmtExecuteコールを使用します。

SELECT SYS_CONTEXT('CLIENTCONTEXT', 'Attribute-1') FROM dual;

SELECT VALUE FROM SESSION_CONTEXT
WHERE NAMESPACE='CLIENTCONTEXT' AND ATTRIBUTE='attribute-1';

Attribute-1の値は、CLIENTCONTEXTネームスペースですでに設定されているどんな属性値でも構いません。Oracle Databaseは設定された属性のみを取得します。設定済属性がない場合は、NULLを返します。通常、属性を設定するにはOCIAppCtxSetコールを使用します。さらに、DBMS_SESSION.SET_CONTEXTコールをOCIコードに埋め込んで属性値を設定できます。

例6-13に、OCIStmtExecuteコールを使用してクライアント・セッションIDを取得する方法を示します。

例6-14 クライアント・セッション・ベース・コンテキストのクライアント・セッションID値の取得

oratext    clientid[31];
OCIDefine  *defnp1 = (OCIDefine *) 0;
OCIStmt    *statementhndle;
oratext    *selcid = (oratext *)"SELECT SYS_CONTEXT('CLIENTCONTEXT',
attribute) FROM  DUAL";

OCIStmtPrepare(statementhndle, errhp, selcid, (ub4) strlen((char *) selcid),
(ub4) OCI_NTV_SYNTAX, (ub4) OCI_DEFAULT);

OCIDefineByPos(statementhndle, &defnp1, errhp, 1, (dvoid *)clientid, 31,
SQLT_STR, (dvoid *) 0, (ub2 *) 0, (ub2 *) 0, OCI_DEFAULT);

OCIStmtExecute(servhndle, statementhndle, errhp, (ub4) 1, (ub4) 0,
(CONST OCISnapshot *) NULL, (OCISnapshot *) NULL, OCI_DEFAULT);

printf("CLIENT_IDENTIFIER = %s \n", clientid);

この例の説明は、次のとおりです。

- oratext、OCIDefine、OCIStmtおよびoratextは、クライアント・セッションID、OCIDefineの参照コール、文ハンドルおよび使用するSELECT文を格納するための変数を作成します。

- OCIStmtPrepareは、文selcidを実行する準備を整えます。

- OCIDefineByPosは、クライアント・セッションIDの出力変数clientidを定義します。

- OCIStmtExecuteは、selcid変数に格納されている文を実行します。

- printfは、取得したクライアント・セッションIDに書式を設定した出力を表示します。

CLIENTCONTEXTネームスペースの設定の消去

Oracle Call Interfaceの場合、CLIENTCONTEXTの設定を消去するには、次のいずれかのコマンドを使用して、値をNULLまたは空の文字列に設定します。

(void) OCIAppCtxSet((void *) session_handle, (dvoid *)"CLIENTCONTEXT", 13,
(dvoid *)attribute_name, length_of_attribute_name,
(dvoid *)0, 0,errhp
OCI_DEFAULT);

または

(void) OCIAppCtxSet((void *) session_handle, (dvoid *)"CLIENTCONTEXT", 13
(dvoid *)attribute_name, length_of_attribute_name,
(dvoid *)"", 0,errhp,
OCI_DEFAULT);

CLIENTCONTEXTネームスペースのすべての設定の消去

Oracle Call Interface(OCI)の場合は、次の書式のコマンドを使用します。

err = OCIAppCtxClearAll((void *) session_handle,
(dvoid *)"CLIENTCONTEXT", 13,
errhp,                        OCI_DEFAULT);

アプリケーション・コンテキストに関する情報の検索

表6-3に、アプリケーション・コンテキストに関する情報の検索で問合せ可能なデータ・ディクショナリ・ビューをリストします。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表6-3 アプリケーション・コンテキストに関する情報を表示するデータ・ディクショナリ・ビュー

ビュー

説明

ALL_CONTEXT

属性および値がDBMS_SESSION.SET_CONTEXTプロシージャを使用して指定された、カレント・セッション内のすべてのコンテキスト・ネームスペースが表示されます。ネームスペースと、対応付けられているスキーマおよびPL/SQLパッケージがリストされます。

ALL_POLICY_CONTEXTS

現行ユーザーがアクセス可能なシノニム、表およびビューに定義されている駆動コンテキストが表示されます。(駆動コンテキストは、仮想プライベート・データベース・ポリシーで使用されるコンテキストです。)

DBA_CONTEXT

データベース内のすべてのコンテキスト・ネームスペース情報が表示されます。このビューの列は、TYPE列が含まれていること以外はALL_CONTEXTビューの各列と同じです。TYPE列には、アプリケーション・コンテキストのアクセスまたは初期化の方法が表示されます。

DBA_POLICY_CONTEXTS

DBMS_RLS.ADD_POLICY_CONTEXTプロシージャによってデータベースに追加されたすべての駆動コンテキストが表示されます。このビューの列は、ALL_POLICY_CONTEXTSの各列と同じです。

SESSION_CONTEXT

カレント・セッションに設定されているコンテキスト属性とその値が表示されます。

USER_POLICY_CONTEXTS

現行ユーザーが所有するシノニム、表およびビューに定義されている駆動コンテキストが表示されます。このビューの列は、OBJECT_OWNER列以外はALL_POLICY_CONTEXTSの各列と同じです。

V$CONTEXT

カレント・セッションに設定されている属性がリストされます。このビューに対するSELECT権限が付与されていないユーザーは、このビューにアクセスできません。

V$SESSION

各カレント・セッションに関する詳細情報がリストされます。このビューに対するSELECT権限が付与されていないユーザーは、このビューにアクセスできません。

ヒント:
アプリケーション・コンテキストを使用するアプリケーションの実行時にエラーが発生した場合は、これらのビューに加え、データベース・トレース・ファイルも確認してください。トレース・ファイルの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。USER_DUMP_DEST初期化パラメータは、トレース・ファイルのディレクトリの場所を示します。このパラメータの値は、SQL*PlusでSHOW PARAMETER USER_DUMP_DESTを発行して確認できます。

7 Oracle Virtual Private Databaseを使用したデータ・アクセスの制御

この章の内容は、次のとおりです。

- Oracle Virtual Private Databaseの概要

- Oracle Virtual Private Databaseポリシーのコンポーネント

- Oracle Virtual Private Databaseポリシーの構成

- 例: Oracle Virtual Private Databaseポリシーの作成

- 他のOracle機能でのOracle Virtual Private Databaseの使用

- Oracle Virtual Private Databaseポリシーに関する情報の検索

Oracle Virtual Private Databaseの概要

この項の内容は、次のとおりです。

- Oracle Virtual Private Database

- Oracle Virtual Private Databaseポリシーを使用するメリット

- Oracle Virtual Private Databaseポリシー関数を実行するために使用する権限

- Oracle Virtual Private Databaseでのアプリケーション・コンテキストの使用

Oracle Virtual Private Database

Oracle Virtual Private Database(VPD)を使用すると、行および列レベルでデータベース・アクセスを制御するセキュリティ・ポリシーを作成できます。基本的には、Oracle Virtual Private Databaseのセキュリティ・ポリシーが適用された表、ビューまたはシノニムに対して発行されるSQL文に、動的なWHERE句が追加されます。

Oracle Virtual Private Databaseを使用すると、データベース表、ビューまたはシノニムに対するセキュリティを直接詳細なレベルまで規定できます。これらのデータベース・オブジェクトにセキュリティ・ポリシーを直接付加すると、ユーザーがデータにアクセスするたびにポリシーが自動的に適用されるため、セキュリティを回避できません。

ユーザーがOracle Virtual Private Databaseポリシーで保護されている表、ビューまたはシノニムに直接的または間接的にアクセスすると、Oracle DatabaseはユーザーのSQL文を動的に変更します。この変更は、セキュリティ・ポリシーを実装する関数によって戻されたWHERE条件(述語)に基づいて行われます。Oracle Databaseでは、関数内に記述された条件、または関数が戻す条件を使用して、動的かつユーザーに対して透過的に文が変更されます。Oracle Virtual Private Databaseポリシーは、SELECT、INSERT、UPDATE、INDEXおよびDELETE文に適用できます。

たとえば、ユーザーが次の問合せを実行するとします。

SELECT * FROM OE.ORDERS;

Oracle Virtual Private Databaseポリシーにより、WHERE句の文が動的に追加されます。次に例を示します。

SELECT * FROM OE.ORDERS
WHERE SALES_REP_ID = 159;

この例では、ユーザーは営業担当者159の受注のみを表示できます。

このユーザーのセッション情報(ユーザーのIDなど)に基づいてユーザーをフィルタ処理する場合は、WHERE句を作成してアプリケーション・コンテキストを使用できます。次に例を示します。

SELECT * FROM OE.ORDERS
WHERE SALES_REP_ID = SYS_CONTEXT('USERENV','SESSION_USER');

注意:
Oracle Virtual Private Databaseでは、DDL(TRUNCATE文やALTER TABLE文)のフィルタ処理はサポートされていません。

Oracle Virtual Private Databaseポリシーを使用するメリット

Oracle Virtual Private Databaseポリシーを使用するメリットは、次のとおりです。

- アプリケーションではなくデータベース・オブジェクトに基づくセキュリティ・ポリシー

- Oracle Databaseによるポリシー関数の評価方法の制御

アプリケーションではなくデータベース・オブジェクトに基づくセキュリティ・ポリシー

すべてのアプリケーションでアクセス制御を実装するのではなく、Oracle Virtual Private Databaseセキュリティ・ポリシーをデータベース表、ビューまたはシノニムに付加すると、次のようなメリットがあります。

- セキュリティ。データベース表、ビューまたはシノニムにポリシーを対応付けることで、アプリケーション・セキュリティの重大な問題を解決できます。たとえば、アプリケーションの使用を許可されているユーザーが、そのアプリケーションに対応付けられている権限を利用し、SQL*Plusなどの非定型の問合せツールを使用してデータベースを誤って変更してしまう可能性があります。ファイングレイン・アクセス・コントロールでは、セキュリティ・ポリシーを表、ビューまたはシノニムに直接付加することによって、ユーザーがどのような方法でデータにアクセスしても、同じセキュリティが施行されます。

- 簡潔性。セキュリティ・ポリシーは、表ベース、ビュー・ベースまたはシノニム・ベースのアプリケーションごとに繰り返し追加するのではなく、表、ビューまたはシノニムに1回のみ追加します。

- 柔軟性。SELECT文には1つのセキュリティ・ポリシーを、INSERT文には別のポリシーを、さらにUPDATE文およびDELETE文にはまた別のポリシーを指定できます。たとえば、人事部門の担当者には、その部門内のすべての社員のレコードに対するSELECT権限を付与し、名字がAからFで始まるその部門内の社員の給与のみを更新できるように指定できます。さらに、各表、ビューまたはシノニムに対して複数のポリシーを作成できます。

Oracle Databaseによるポリシー関数の評価方法の制御

ポリシー関数を複数回実行すると、パフォーマンスに影響を与える可能性があります。Oracle DatabaseがOracle Virtual Private Database述語をキャッシュする方法を構成することによって、ポリシー関数のパフォーマンスを制御できます。次のオプションがあります。

- 各問合せについてポリシーを1回評価します(静的ポリシー)。

- ポリシー関数内のアプリケーション・コンテキストが変更された場合のみ、ポリシーを評価します(状況依存ポリシー)。

- 実行ごとにポリシーを評価します(動的ポリシー)。

これらのポリシー・タイプの構成方法は、「Oracle Virtual Private Databaseポリシー・タイプを使用したパフォーマンスの最適化」を参照してください。

Oracle Virtual Private Databaseポリシー関数を実行するために使用する権限

セキュリティを強化するために、Oracle Virtual Private Database ポリシー関数は、定義者権限で宣言されたかのように実行されます。実行者権限として宣言すると、自分自身だけでなく、コードをメンテナンスする他のユーザーも混乱させてしまうため、実行者権限では宣言しないでください。

関連項目:
定義者権限の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

Oracle Virtual Private Databaseでのアプリケーション・コンテキストの使用

Oracle Virtual Private Databaseポリシーを使ったアプリケーション・コンテキストを使用できます。アプリケーション・コンテキストを作成すると、ユーザー情報が安全にキャッシュされます。キャッシュ環境を設定できるのは、指定されたアプリケーション・パッケージのみです。ユーザーやパッケージ外部からの変更はできません。さらに、データがキャッシュされるため、パフォーマンスが向上します。第6章「アプリケーション・コンテキストを使用したユーザー情報の取得」では、アプリケーション・コンテキストについて詳細に説明します。

たとえば、ORDERS_TAB表へのアクセスを顧客ID番号を基にして行うとします。顧客ID番号が必要になるたびにログインしたユーザーに問い合せるのではなく、アプリケーション・コンテキスト内に顧客ID番号を格納しておくことができます。このようにすると、顧客番号は必要なときにセッションで使用できます。

アプリケーション・コンテキストは、セキュリティ・ポリシーが複数のセキュリティ属性に基づく場合に特に役立ちます。たとえば、WHERE述語が4つの属性(従業員番号、コスト・センター、職位、支出制限など)に基づくポリシー関数は、この情報を取得するために複数の副問合せを実行する必要があります。このデータがアプリケーション・コンテキストを介して使用可能な場合、パフォーマンスは大きく向上します。

アプリケーション・コンテキストを使用すると、述語により規定される正しいセキュリティ・ポリシーを戻すことができます。たとえば、「顧客は自分の注文のみを参照でき、社員はすべての顧客のすべての注文を参照できる」というルールを規定している受注管理アプリケーションを想定します。この場合は、2つの異なるポリシーがあります。position属性でアプリケーション・コンテキストを定義できます。この属性はポリシー関数内でアクセスでき、その属性の値に基づいて正しい述語を戻します。そのため、職位がclerk (社員)であるユーザーはすべての注文を取得できるようにし、customer (顧客)であるユーザーは自分に関連するレコードのみ参照できるようにすることができます。

属性に対して特定の述語を戻すファイングレイン・アクセス・コントロール・ポリシーを設計するには、ポリシーを実装する関数内でアプリケーション・コンテキストにアクセスする必要があります。たとえば、顧客が自分のレコードのみを参照するように制限する必要があるとします。ユーザーは次の問合せを実行します。

SELECT * FROM orders_tab

ファイングレイン・アクセス・コントロールによって、この問合せはWHERE述語が含まれるように動的に変更されます。

SELECT * FROM orders_tab
WHERE custno = SYS_CONTEXT ('order_entry', 'cust_num');

前述の例で、50,000人の顧客が存在し、各顧客が受け取る述語を同じにするとします。すべての顧客は同一のWHERE述語を共有し、自分の注文のみを参照できます。顧客間で異なるのは、顧客番号のみです。

アプリケーション・コンテキストを使用して、50,000人の顧客に適用されるポリシー関数内で1つのWHERE述語を返すことができます。結果として、顧客番号が実行時に評価されるため、顧客ごとに実行方法が異なる1つの共有カーソルが存在することになります。この値は、すべての顧客で異なります。このようにアプリケーション・コンテキストを使用することで、最適なパフォーマンスと行レベルのセキュリティが実現します。

SYS_CONTEXT関数がバインド変数のように動作するのは、SYS_CONTEXT引数が定数の場合のみです。

Oracle Virtual Private Databaseポリシーのコンポーネント

Oracle Virtual Private Databaseを実装するには、動的なWHERE句を生成する関数、および保護するオブジェクトにその関数を付加するポリシーを作成する必要があります。

- 動的なWHERE句を生成する関数の作成

- 保護するオブジェクトに関数を付加するポリシーの作成

関連項目:

- 「Oracle Virtual Private Databaseポリシー関数を実行するために使用する権限」

- 「例: Oracle Virtual Private Databaseポリシーの作成」

動的なWHERE句を生成する関数の作成

動的なWHERE句(述語)を生成するには、規定する制限を定義した関数(プロシージャではなく)を作成する必要があります。通常は、セキュリティ管理者が自分のスキーマにこの関数を作成します。別の関数のコールを含めたり、ログイン失敗を追跡するためのチェックを追加するなど、複雑な動作が必要な場合は、これらの関数を1つのパッケージ内に作成します。

関数では、次の動作が必要です。

- 引数としてスキーマ名、入力としてオブジェクト(表、ビューまたはシノニム)名を取る必要があります。これらの情報を保持するように入力パラメータを定義しますが、関数内でスキーマ名とオブジェクト名自体を指定しないでください。DBMS_RLSパッケージ(「保護するオブジェクトに関数を付加するポリシーの作成」を参照)を使用して作成したポリシーによって、スキーマ名、およびポリシーが適用されるオブジェクトが提供されます。最初にスキーマのパラメータを作成し、その後にオブジェクトのパラメータを作成する必要があります。

- 生成するWHERE句述語の戻り値を提供する必要があります。WHERE句の戻り値は、常にVARCHAR2データ型です。

- 有効なWHERE句を生成する必要があります。このコードは「例: 単純なOracle Virtual Private Databaseポリシーの作成」に示すように基本的なもので、WHERE句はログインするすべてのユーザーに共通です。
ただし、ほとんどの場合、各ユーザー、ユーザーの各グループ、または保護するオブジェクトにアクセスする各アプリケーションに異なるWHERE句を設計する必要があります。たとえば、マネージャがログインする場合は、そのマネージャの権限に固有のWHERE句を生成できます。これを行うには、ユーザー・セッション情報にアクセスするアプリケーション・コンテキストをWHERE句の生成コードに組み込みます。アプリケーション・コンテキストを使用するOracle Virtual Private Databaseポリシーの作成方法は、「例: データベース・セッション・ベースのアプリケーション・コンテキストを使用したポリシーの実装」で説明します。

アプリケーション・コンテキストを使用しないOracle Virtual Private Database関数を作成することもできますが、アプリケーション・コンテキストを使用すると、ユーザーのセッション属性(ユーザーIDなど)に基づいてユーザー・アクセスが安全に行われるため、より強固なOracle Virtual Private Databaseポリシーを作成できます。様々なタイプのアプリケーション・コンテキストの詳細は、第6章「アプリケーション・コンテキストを使用したユーザー情報の取得」を参照してください。

さらに、CまたはJavaコールを埋め込み、オペレーティング・システム情報にアクセスしたり、オペレーティング・システム・ファイルや他のソースからWHERE句を戻すことができます。

- 関連するポリシー関数内の表から選択しないでください。表へのポリシーの定義は可能ですが、表に定義されたポリシーから表を選択することはできません。

注意:
関数を様々なエディションで実行する場合、関数の結果がすべてのエディションで同一か、または関数が実行されているエディションによって異なるかに関係なく、関数の結果を制御できます。詳細は、「エディションがグローバル・アプリケーション・コンテキストのPL/SQLパッケージの結果に与える影響」を参照してください。

保護するオブジェクトに関数を付加するポリシーの作成

関数を作成したら、その関数を表、ビュー、またはシノニムに関連付けるOracle Virtual Private Databaseポリシーを作成する必要があります。このポリシーを作成するには、DBMS_RLSパッケージを使用します。SYSでない方は、DBMS_RLSパッケージを使用するためにEXECUTE権限を付与される必要があります。このパッケージには、ポリシーの管理とファイングレイン・アクセス・コントロールの設定が可能になるプロシージャが含まれています。たとえば、ポリシーを表に付加するには、DBMS_RLS.ADD_POLICYプロシージャを使用します。この設定の中で、たとえばユーザーがSELECT文やUPDATE文を表またはビューで発行するとポリシーが有効になるよう設定して、ファイングレイン・アクセス・コントロールを設定します。

Oracle Virtual Private Databaseポリシーの作成とは、関数を作成し、その関数を表またはビューに適用することを意味します。

仮想プライベート・データベース・ポリシーの作成方法の例は、「例: Oracle Virtual Private Databaseポリシーの作成」を参照してください。詳細は、「Oracle Virtual Private Databaseポリシーの構成」を参照してください。

Oracle Virtual Private Databaseポリシーの構成

この項の内容は、次のとおりです。

- Oracle Virtual Private Databaseポリシーの概要

- データベース表、ビューまたはシノニムへのポリシーの付加

- 特定のSQL文に対するポリシーの規定

- ポリシーを使用した列データ表示の制御

- Oracle Virtual Private Databaseポリシー・グループの使用

- Oracle Virtual Private Databaseポリシー・タイプを使用したパフォーマンスの最適化

Oracle Virtual Private Databaseポリシーの概要

Oracle Virtual Private DatabaseのWHERE句のアクションを定義する関数を作成した後は、VPDアクションを適用するデータベース表にその関数を対応付ける必要があります。これを行うには、Oracle Virtual Private Databaseポリシーを構成します。ポリシーとは、仮想プライベート・データベース関数を管理するメカニズムです。また、ポリシーを使用すると、ファイングレイン・アクセス・コントロールを追加できるため、たとえば、SQL文のタイプを指定したり、特定の表列にポリシーを適用できます。ユーザーがこのデータベース・オブジェクト内のデータにアクセスすると、ポリシーが自動的に有効になります。

このセクションでは、ポリシーを表、ビュー、およびシノニムに付加するために一般的に使用される方法を説明します。Oracle Virtual Private Databaseポリシーを管理するためには、DBMS_RLSパッケージを使用します。このパッケージについては、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』で詳細に説明されています。

表7-1に、DBMS_RLSパッケージに含まれているプロシージャを示します。

表7-1 DBMS_RLSのプロシージャ

プロシージャ

説明

個別ポリシーの処理用

DBMS_RLS.ADD_POLICY

表、ビューまたはシノニムにポリシーを追加します。

DBMS_RLS.ENABLE_POLICY

表、ビューまたはシノニムに事前に追加したポリシーを使用可能または使用禁止にします。

DBMS_RLS.REFRESH_POLICY

静的ポリシー以外のポリシーに対応付けられたカーソルを無効にします。

DBMS_RLS.DROP_POLICY

表、ビューまたはシノニムからポリシーを削除します。

グループ・ポリシーの処理用

DBMS_RLS.CREATE_POLICY_GROUP

ポリシー・グループを作成します。

DBMS_RLS.DELETE_POLICY_GROUP

ポリシー・グループを削除します。

DBMS_RLS.ADD_GROUPED_POLICY

特定のポリシー・グループにポリシーを追加します。

DBMS_RLS.ENABLE_GROUPED_POLICY

グループ内のポリシーを使用可能にします。

DBMS_RLS.REFRESH_GROUPED_POLICY

リフレッシュされたポリシーに対応付けられたSQL文を再解析します。

DBMS_RLS.DISABLE_GROUPED_POLICY

グループ内のポリシーを使用禁止にします。

DBMS_RLS.DROP_GROUPED_POLICY

特定のグループに属するポリシーを削除します。

アプリケーション・コンテキストの処理用

DBMS_RLS.ADD_POLICY_CONTEXT

アクティブなアプリケーションのコンテキストを追加します。

DBMS_RLS.DROP_POLICY_CONTEXT

アプリケーションのコンテキストを削除します。

関連項目:

- データベース表、ビューまたはシノニムへのユーザー・アクセスを制御するために作成する必要がある関数のタイプについては、「Oracle Virtual Private Databaseポリシーのコンポーネント」を参照してください。

- Oracle Virtual Private Databaseポリシーでアプリケーション・コンテキストを使用する場合は(ほとんどの場合に使用します)、第6章「アプリケーション・コンテキストを使用したユーザー情報の取得」を参照してください。

- Oracle Virtual Private Databaseサンプル関数でのアプリケーション・コンテキストの使用例は、「例: Oracle Virtual Private Databaseポリシーの作成」を参照してください

データベース表、ビューまたはシノニムへのポリシーの付加

ポリシーを表、ビューまたはシノニムに付加するには、DBMS_RLS.ADD_POLICYプロシージャを使用します。ポリシーを追加する表、ビューまたはシノニム、およびポリシーの名前を指定する必要があります。また、ポリシーが制御する文のタイプ(SELECT、INSERT、UPDATE、DELETE、CREATE INDEXまたはALTER INDEX)など、その他の情報も指定できます。

例7-1に、DBMS_RLS.ADD_POLICYを使用して、secure_updateというOracle Virtual Private DatabaseポリシーをHR.EMPLOYEES表に付加する方法を示します。ポリシーに付加される関数はcheck_updatesです。

例7-1 表への単純なOracle Virtual Private Databaseポリシーの付加

BEGIN
DBMS_RLS.ADD_POLICY(
object_schema   => 'hr',
object_name     => 'employees',
policy_name     => 'secure_update',
policy_function => 'check_updates',
...

関数がパッケージ内に作成されている場合は、パッケージ名を指定します。例:

policy_function => 'pkg.check_updates',
...

注意:
表へのポリシーの定義は可能ですが、表に定義されたポリシーから表を選択することはできません。

特定のSQL文に対するポリシーの規定

Oracle Virtual Private Databaseポリシーは、SELECT、INSERT、UPDATE、INDEXおよびDELETE文に規定できます。文のタイプを指定しない場合、Oracle DatabaseではデフォルトでSELECT、INSERT、UPDATEおよびDELETEが指定されますが、INDEXは指定されません。DBMS_RLS.ADD_POLICYプロシージャのstatement_typesパラメータを使用して、これらの文の組合せを入力します。リストは一重引用符で囲みます。

例7-2に、statement_typesパラメータを使用して、ポリシーに対してSELECT文とINDEX文を指定する方法を示します。

例7-2 DBMS_RLS.ADD_POLICYを使用したSQL文の指定

BEGIN
DBMS_RLS.ADD_POLICY(
object_schema   => 'hr',
object_name     => 'employees',
policy_name     => 'secure_update',
policy_function => 'check_updates',
statement_types => 'SELECT,INDEX');
END;
/

statement_typesパラメータを指定する場合は、次の機能に注意してください。

- Virtual Private Databaseポリシーによる影響を受けるアプリケーション・コードとして、MERGE INTO文が含まれる場合があります。しかし、Virtual Private Databaseポリシーでは、statement_typesパラメータにINSERT、UPDATE、およびDELETEの3つの文すべてを含めてポリシーを正常に機能させる必要があります。あるいは、statement_typesパラメータを省略できます。(この機能は、Oracle Database 11gリリース2 (11.2.0.2)で使用できます。)

- 索引をメンテナンスする権限を持っているユーザーは、たとえこのユーザーがSELECTのような標準問合せでは完全な表アクセスを持っていない場合でも、すべての行データを参照できることに注意してください。たとえばユーザーは、列値を引数とする、ユーザー定義関数を含む関数ベースの索引を作成できます。索引作成時に、Oracle Databaseがあらゆる行の列値をユーザー関数へ渡して、索引を作成するユーザーが行データを使用できるようにします。INDEXをstatement_typesパラメータで指定することにより、Oracle Virtual Private Databaseポリシーを索引メンテナンス操作で適用できます。

ポリシーを使用した列データ表示の制御

セキュリティに関連する列が問合せで参照される際に行レベルのセキュリティを規定するポリシーを作成できます。

- 列レベルのOracle Virtual Private Databaseポリシーの追加

- 問合せで参照する列の行のみの表示

- 列のマスクを使用して機密性の高い列をNULL値で表示

列レベルのOracle Virtual Private Databaseポリシーの追加

列レベルのポリシーによって、セキュリティに関連する列が問合せで参照される際の行レベルのセキュリティを規定できます。列レベルのOracle Virtual Private Databaseポリシーは、表やビューに適用できますが、シノニムには適用できません。

ポリシーを列に適用するには、DBMS_RLS.ADD_POLICYプロシージャのSEC_RELEVANT_COLSパラメータを使用して、セキュリティ関連の列を指定します。このパラメータによって、問合せで列が明示的または暗黙的に参照されるたびに、セキュリティ・ポリシーが適用されます。

たとえば、人事部門以外のユーザーは、通常、各自の社会保障番号を参照することのみが許可されます。販売担当者が次の問合せを開始するとします。

SELECT fname, lname, ssn FROM emp;

セキュリティ・ポリシーを実装する関数は述語ssn='my_ssn'を戻します。Oracle Databaseは次のように問合せをリライトして実行します。

SELECT fname, lname, ssn FROM emp
WHERE ssn = 'my_ssn';

例7-3は、営業部門(部門番号30)のユーザーは他部門の従業員の給与を参照できないというOracle Virtual Private Databaseポリシーを示します。このポリシーに関連する列は、salおよびcommです。最初にOracle Virtual Private Databaseポリシー関数を作成し、次にDBMS_RLS PL/SQLパッケージを使用して追加します。

例7-3 列レベルのOracle Virtual Private Databaseポリシーの作成

CREATE OR REPLACE FUNCTION hide_sal_comm (
v_schema IN VARCHAR2,
v_objname IN VARCHAR2)

RETURN VARCHAR2 AS
con VARCHAR2 (200);

BEGIN
con := 'deptno=30';
RETURN (con);
END hide_sal_comm;

次に、DBMS_RLS.ADD_POLICYプロシージャを使用して、ポリシーを構成します。

BEGIN
DBMS_RLS.ADD_POLICY (
object_schema     => 'scott',
object_name       => 'emp',
policy_name       => 'hide_sal_policy',
policy_function   => 'hide_sal_comm',
sec_relevant_cols => 'sal,comm');
END;

問合せで参照する列の行のみの表示

列レベルのOracle Virtual Private Databaseに関するデフォルトの動作では、機密情報が含まれた列を参照する問合せから戻される行の数を制限します。これらのセキュリティ関連の列を指定するには、例7-3に示すように、DBMS_RLS.ADD_POLICYプロシージャのSEC_RELEVANT_COLUMNSパラメータを使用します。

たとえば、営業部門ユーザーはemp表に対してSELECT権限を持っており、この表は例7-3で作成された列レベルのOracle Virtual Private Databaseポリシーによって保護されている場合を想定します。ユーザー(たとえば、ユーザーSCOTT)は次の問合せを実行します。

SELECT ENAME, d.dname, JOB, SAL, COMM
FROM emp e, dept d
WHERE d.deptno = e.deptno;

データベースは次の行を戻します。

ENAME      DNAME          JOB              SAL       COMM
---------- -------------- --------- ---------- ----------
ALLEN      SALES          SALESMAN        1600        300
WARD       SALES          SALESMAN        1250        500
MARTIN     SALES          SALESMAN        1250       1400
BLAKE      SALES          MANAGER         2850
TURNER     SALES          SALESMAN        1500          0
JAMES      SALES          CLERK            950

6 rows selected.

表示されるのは、行のすべての列に対してユーザーがアクセス権を持っている行のみです。

列のマスクを使用して機密性の高い列をNULL値で表示

問合せで機密性の高い列を参照する場合、列レベルのOracle Virtual Private Databaseのデフォルト動作では、戻される行の数が制限されます。列のマスク動作を利用すると、機密性の高い列を参照している場合にもすべての行が表示されます。ただし、機密性の高い列はNULL値で表示されます。列のマスク動作を有効にするには、DBMS_RLS.ADD_POLICYプロシージャのSEC_RELEVANT_COLS_optパラメータを設定します。

たとえば、前述の例に記載されている販売担当者の問合せ結果を考えてみます。列のマスクを使用すると、販売担当者自身の詳細と社会保障番号が格納されている行のみが表示されるのではなく、emp表からすべての行が表示されますが、ssn列の値はNULLになります。この動作は、行のサブセットのみを戻す他のあらゆるタイプのOracle Virtual Private Databaseポリシーとは基本的に異なることに注意してください。

列レベルのOracle Virtual Private Databaseに関するデフォルトのアクションとは対照的に、列のマスク動作ではすべての行が表示されますが、機密情報が含まれた列の値はNULLとして戻されます。ポリシーに列のマスク動作を含めるには、DBMS_RLS.ADD_POLICYプロシージャのSEC_RELEVANT_COLS_OPTパラメータをDBMS_RLS.ALL_ROWSに設定します。

例7-4は、列レベルのOracle Virtual Private Database列のマスク動作を示しています。使用しているのは例7-3と同じVPDポリシーですが、sec_relevant_cols_optがDBMS_RLS.ALL_ROWSとして指定されています。

例7-4 Oracle Virtual Private Databaseポリシーへの列のマスクの追加

BEGIN
DBMS_RLS.ADD_POLICY(
object_schema         => 'scott',
object_name           => 'emp',
policy_name           => 'hide_sal_policy',
policy_function       => 'hide_sal_comm',
sec_relevant_cols     =>' sal,comm',
sec_relevant_cols_opt => dbms_rls.ALL_ROWS);
END;

emp表に対するSELECT権限を持つ営業部門のユーザー(たとえば、SCOTT)が、次の問合せを実行するとします。

SELECT ENAME, d.dname, job, sal, comm
FROM emp e, dept d
WHERE d.deptno = e.deptno;

データベースは、この問合せで指定されたすべての行を戻しますが、Oracle Virtual Private Databaseポリシーによって一部の値はマスクされています。

ENAME      DNAME          JOB              SAL       COMM
---------- -------------- --------- ---------- ----------
CLARK      ACCOUNTING     MANAGER
KING       ACCOUNTING     PRESIDENT
MILLER     ACCOUNTING     CLERK
JONES      RESEARCH       MANAGER
FORD       RESEARCH       ANALYST
ADAMS      RESEARCH       CLERK
SMITH      RESEARCH       CLERK
SCOTT      RESEARCH       ANALYST
WARD       SALES          SALESMAN        1250        500
TURNER     SALES          SALESMAN        1500          0
ALLEN      SALES          SALESMAN        1600        300
JAMES      SALES          CLERK            950
BLAKE      SALES          MANAGER         2850
MARTIN     SALES          SALESMAN        1250       1400

14 rows selected.

列のマスク動作により、営業部門のユーザーの問合せで要求された列がすべて戻されますが、営業部門以外の従業員に関してはsal列とcomm列がNULLになっています。

列のマスク動作には次の考慮事項が適用されます。

- 列のマスクが適用されるのは、SELECT文に対してのみです。

- 通常のOracle Virtual Private Database述語とは異なり、ポリシー関数によって生成される列マスク条件は、単純なブール式であることが必要です。

- 計算を実行するアプリケーションや、NULL値が戻されることが想定されていないアプリケーションの場合は、標準の列レベルのOracle Virtual Private Databaseを使用して、列のマスク動作オプションSEC_RELEVANT_COLS_OPTではなくSEC_RELEVANT_COLSを指定します。

- オブジェクト・データ型(XMLtypeを含む)の列をsec_relevant_cols設定に含めないでください。この列型は、sec_relevant_cols設定ではサポートされていません。

- UPDATE AS SELECTとともに使用される列のマスク動作によって更新されるのは、ユーザーが表示を許可されている列のみです。

- 問合せによっては、列のマスク動作により一部の行が表示されない場合があります。例:

SELECT * FROM emp
WHERE sal = 10;

列のマスク動作オプションが設定されているため、salary列にNULL値が戻される場合は、この問合せを実行しても行が戻されない場合があります。

Oracle Virtual Private Databaseポリシー・グループの使用

この項の内容は、次のとおりです。

- Oracle Virtual Private Databaseポリシー・グループの概要

- 新しいOracle Virtual Private Databaseポリシー・グループの作成

- SYS_DEFAULTポリシー・グループを使用したデフォルト・ポリシー・グループの指定

- 各表、ビューまたはシノニムに対する複数のポリシーの設定

- データベースへの接続に使用されるアプリケーションの検証

関連項目:
「例: Oracle Virtual Private Databaseポリシー・グループの実装」

Oracle Virtual Private Databaseポリシー・グループの概要

複数のセキュリティ・ポリシーをまとめてグループ化して、1つのアプリケーションに適用できます。ポリシー・グループとは、アプリケーションに属する一連のセキュリティ・ポリシーです。有効なポリシー・グループを示すようにアプリケーション・コンテキスト(駆動コンテキストまたはポリシー・コンテキストと呼ばれます)を指定できます。ユーザーが表、ビュー、またはシノニム列にアクセスすると、Oracle Databaseが駆動コンテキストを検索して、有効なポリシー・グループを特定します。ポリシー・グループに属しているすべての関連ポリシーが適用されます。

ポリシー・グループは、複数のセキュリティ・ポリシーを持つ複数のアプリケーションが同一の表、ビューまたはシノニムを共有する場合に便利です。ポリシー・グループによって、表、ビューまたはシノニムがアクセスされたときに有効にするポリシーを識別できます。

たとえば、ホスト環境で、A社が、B社およびC社に対してBENEFIT表をホスティングするとします。この表は、2つの異なるセキュリティ・ポリシーを持つ、Human Resources(人事管理)およびFinance(財務管理)という2つアプリケーションによってアクセスされます。Human Resourcesアプリケーションは社内の序列に基づいてユーザーを認可し、Financeアプリケーションは部門に基づいてユーザーを認可します。これらの2つのポリシーをBENEFIT表に統合するには、2つの企業が共同でポリシーを開発する必要がありますが、それは現実的ではありません。ベース・オブジェクトに一連の特定のポリシーを規定するアプリケーション・コンテキストを定義することにより、各アプリケーションがセキュリティ・ポリシーの集合を個別に実装できます。

これを行うには、セキュリティ・ポリシーをグループ化します。アプリケーション・コンテキストを参照することにより、実行時に有効にするポリシーのグループをOracle Databaseが判断します。サーバーは、そのポリシー・グループに属するすべてのポリシーを規定します。

新しいOracle Virtual Private Databaseポリシー・グループの作成

表、ビューまたはシノニムにポリシーを追加するには、DBMS_RLS.ADD_GROUPED_POLICYプロシージャを使用して、そのポリシーが属するグループを指定します。有効にするポリシーを指定するには、DBMS_RLS.ADD_POLICY_CONTEXTプロシージャを使用して駆動コンテキストを追加できます。駆動コンテキストが不明なポリシー・グループを戻した場合は、エラーが戻されます。

駆動コンテキストが定義されていない場合は、すべてのポリシーが実行されます。同様に、駆動コンテキストがNULLである場合は、すべてのポリシー・グループのポリシーが規定されます。データにアクセスするアプリケーションは、セキュリティ設定モジュール(アプリケーション・コンテキストを設定するモジュール)を回避できないため、該当するすべてのポリシーが適用されます。

同一の表、ビューまたはシノニムに複数の駆動コンテキストを適用して、それぞれを個別に処理できます。これによって、複数のアクティブなポリシーを設定して規定できます。

たとえば、福利厚生アプリケーションと財務アプリケーションをホスティングするホスト企業があり、これらのアプリケーションが、いくつかのデータベース・オブジェクトを共有している場合を想定します。この2つのアプリケーションは、SYS_DEFAULTポリシー・グループのSUBSCRIBERポリシーを使用して、ホスティング用にストライプ化されます。データ・アクセスは、最初にサブスクライバIDごとにパーティション化され、次に、ユーザーが福利厚生アプリケーションと財務アプリケーションのどちらにアクセスしているか(駆動コンテキストによって決定される)によってパーティション化されます。ホスティング・サービスを使用するA社が、自社のデータ・アクセスにのみ関連したカスタム・ポリシーを適用するとします。この場合は、駆動コンテキスト(COMPANY A SPECIALなど)を追加して、追加の特殊ポリシー・グループの適用をA社のデータ・アクセスのみに限定できます。このポリシーはA社のみに関連しているため、SUBSCRIBERポリシーの下では適用できません。基本的なホスティング・ポリシーは、他のポリシーから分離した方がより効率的です。

SYS_DEFAULTポリシー・グループを使用したデフォルト・ポリシー・グループの指定

セキュリティ・ポリシーのグループ内で、1つのセキュリティ・ポリシーをデフォルトのセキュリティ・ポリシーになるよう指定できます。これは、セキュリティ・ポリシーをアプリケーション別に分割して常に有効になるようにする場合に便利です。デフォルト・セキュリティ・ポリシーを使用すると、開発者はすべての条件下で基礎となるセキュリティを規定できます。一方、アプリケーションごとにセキュリティ・ポリシーを分割(セキュリティ・グループを使用)すると、デフォルト・セキュリティ・ポリシーにアプリケーション固有のセキュリティ・レイヤーを追加できます。デフォルト・セキュリティ・ポリシーを実装するには、このデフォルト・セキュリティ・ポリシーをSYS_DEFAULTポリシー・グループに追加します。

このグループ内に定義されている、特定の表、ビューまたはシノニムに対するポリシーは、駆動コンテキストが指定するポリシー・グループとともに実行されます。前述のとおり、駆動コンテキストは、有効なポリシー・グループを指定するアプリケーション・コンテキストです。SYS_DEFAULTポリシー・グループには、ポリシーが含まれる場合と含まれない場合があります。SYS_DEFAULTポリシー・グループは削除できません。このポリシー・グループを削除すると、Oracle Databaseでエラーが発生します。

SYS_DEFAULTポリシー・グループに、複数のオブジェクトに対応付けられているポリシーを追加する場合、各オブジェクトには個別にSYS_DEFAULTポリシー・グループが対応付けられます。たとえば、scottスキーマのemp表に1つのSYS_DEFAULTポリシー・グループがある場合、scottスキーマのdept表には別のSYS_DEFAULTポリシー・グループが対応付けられます。これは、次のようにツリー構造に編成されます。

SYS_DEFAULT
- policy1 (scott/emp)
- policy3 (scott/emp)
SYS_DEFAULT
- policy2 (scott/dept)

同一の名前を持つ複数のポリシー・グループを作成できます。特定のポリシー・グループを選択すると、対応付けられているスキーマとオブジェクト名が、画面右側のプロパティ・シートに表示されます。

各表、ビューまたはシノニムに対する複数のポリシーの設定

同一の表、ビューまたはシノニムに対して複数のポリシーを設定できます。たとえば、受注用の基本アプリケーションがあり、社内の各部門にはそれぞれ独自のデータ・アクセス規則があるとします。基本アプリケーションのポリシー関数を作成しなおさなくても、部門固有のポリシー関数を表に追加できます。

表に適用されるすべてのポリシーは、AND構文で規定されます。そのため、CUSTOMERS表に3つのポリシーを適用している場合、各ポリシーが表に適用されます。データにアクセスするアプリケーションに応じて異なるポリシーが適用されるように、ポリシー・グループおよびアプリケーション・コンテキストを使用して、ファイングレイン・アクセス・コントロールの規定を分割できます。これによって、開発グループ間でポリシーを調整する必要がなくなり、アプリケーションの開発が容易になります。また、常に適用する(たとえば、ホスト環境でサブスクライバによりデータ分割を規定する)デフォルト・ポリシー・グループを保持することもできます。

データベースへの接続に使用されるアプリケーションの検証

駆動コンテキストを実装するパッケージは、データベースへの接続に使用されるアプリケーションを正しく検証する必要があります。Oracle Databaseは、コール・スタックをチェックして、駆動コンテキストを実装するパッケージによるコンテキスト属性の設定を確認しますが、パッケージ内では不適切な検証が発生する可能性があります。

たとえば、データベース・ユーザーまたはエンタープライズ・ユーザーがデータベースに認識されているアプリケーションの場合、ユーザーには、駆動コンテキストを設定するパッケージに対するEXECUTE権限が必要です。次のことを認識しているユーザーを考えてみます。

- BENEFITSアプリケーションの方がHRアプリケーションよりもアクセスが自由であること。

- (正しいポリシー・グループを駆動コンテキスト内に設定する)setctxプロシージャでは、実際に接続しているアプリケーションを判断するための検証が実行されないこと。つまり、このプロシージャでは、(3層システムに対する)着信接続のIPアドレス、またはユーザー・セッションのproxy_user属性がチェックされないこと。

ユーザーは、アクセスがより自由なBENEFITSポリシー・グループにコンテキストを設定する引数を駆動コンテキスト・パッケージに渡してから、かわりにHRアプリケーションにアクセスできます。setctxではアプリケーションに対してそれ以上の検証を行わないため、このユーザーは限定的なHRセキュリティ・ポリシーをバイパスしてしまいます。

一方、Oracle Virtual Private Databaseによるプロキシ認証を実装すると、ユーザーのかわりにデータベースに接続する中間層(およびアプリケーション)の識別情報を確認できます。これによって、データ・アクセスを仲介するアプリケーションごとに正しいポリシーが適用されます。

たとえば、開発者は、プロキシ認証機能を使用して、データベースに接続しているアプリケーション(中間層)がHRAPPSERVERであることを確認できます。このように、駆動コンテキストを実装するパッケージでは、ユーザー・セッションのproxy_user がHRAPPSERVERかどうかを検証できます。その場合、HRポリシー・グループを使用するよう駆動コンテキストを設定できます。proxy_userがHRAPPSERVERでない場合は、アクセスを拒否できます。

このような場合に、次の問合せが実行されるとします。

SELECT * FROM apps.benefit;

Oracle Databaseは、デフォルト・ポリシー・グループ(SYS_DEFAULT)およびアクティブなネームスペースHRのポリシーを選択します。この問合せは、内部で次のようにリライトされます。

SELECT * FROM apps.benefit
WHERE company = SYS_CONTEXT('ID','MY_COMPANY')
and SYS_CONTEXT('ID','TITLE') = 'MANAGER';

Oracle Virtual Private Databaseポリシー・タイプを使用したパフォーマンスの最適化

この項の内容は、次のとおりです。

- Oracle Virtual Private Databaseポリシー・タイプの概要

- 動的ポリシー・タイプの使用によるポリシー関数の自動再実行

- 静的ポリシーの使用によるポリシー関数の問合せごとの再実行の回避

- 共有の静的ポリシーの使用による複数オブジェクト間でのポリシーの共有

- 静的ポリシーおよび共有の静的ポリシーを使用する場合

- 解析後に変更されない述語に対する状況依存ポリシーの使用

- 共有の状況依存ポリシーの使用による複数オブジェクト間でのポリシーの共有

- 状況依存ポリシーおよび共有の状況依存ポリシーを使用する場合

- 5種類のOracle Virtual Private Databaseポリシー・タイプの要約

Oracle Virtual Private Databaseポリシー・タイプの概要

ポリシーに対してポリシー・タイプを指定すると、ポリシーの各実行のパフォーマンスを最適化できます。ポリシー・タイプを使用して、Oracle DatabaseがOracle Virtual Private Databaseポリシーの述語をキャッシュする方法を制御します。ポリシー関数を実行すると、システム・リソースを大量に消費する場合があるため、ポリシーに対してポリシー・タイプを設定することを検討してください。ポリシー関数の実行回数を最小限に抑えることで、データベースのパフォーマンスを最適化できます。

選択できるポリシー・タイプは、DYNAMIC、STATIC、SHARED_STATIC、CONTEXT_SENSITIVEおよびSHARED_CONTEXT_SENSITIVEの5種類です。これらのポリシー・タイプによって、ポリシーの述語を変更する頻度を正確に指定できます。ポリシー・タイプを指定するには、DBMS_RLS.ADD POLICYプロシージャのpolicy_typeパラメータを設定します。

動的ポリシー・タイプの使用によるポリシー関数の自動再実行

DYNAMICポリシー・タイプを指定すると、ユーザーが仮想プライベート・データベースで保護されたデータベース・オブジェクトにアクセスするたびに、ポリシー関数が実行されます。DBMS_RLS.ADD_POLICYプロシージャにポリシー・タイプを指定しない場合、ポリシーはデフォルトで動的になります。ポリシーを動的に構成するには、DBMS_RLS.ADD_POLICYプロシージャのpolicy_typeパラメータをDYNAMICに設定します。

動的ポリシー・タイプでは、静的ポリシーや状況依存ポリシー・タイプの場合と異なり、データベースのパフォーマンスは最適化されません。ただし、ポリシーを静的または状況依存に設定する前に、その都度実行されるDYNAMICポリシー・タイプでテストすることをお薦めします。最初にポリシー関数をDYNAMICポリシーでテストすると、何もキャッシュされていないため、ポリシー関数が各問合せに与える影響を調べることができます。これにより、パフォーマンスを最適化するために静的ポリシーまたは状況依存ポリシーを使用可能にする前に、関数が正常に機能することを確認できます。

文の実行開始時間と終了時間を測定するには、DBMS_UTILITY.GET_TIMEファンクションを使用できます。次に例を示します。

-- 1. Get the start time:
SELECT DBMS_UTILITY.GET_TIME FROM DUAL;

GET_TIME
----------
2312721

-- 2. Run the statement:
SELECT COUNT(*) FROM HR.EMPLOYEES;

COUNT(*)
----------
107

-- 3. Get the end time:
SELECT DBMS_UTILITY.GET_TIME FROM DUAL;

GET_TIME
----------
2314319

例7-5に、DYNAMICポリシー・タイプの作成方法を示します。

例7-5 DBMS_RLS.ADD_POLICYを使用したDYNAMICポリシーの作成

BEGIN
DBMS_RLS.ADD_POLICY(
object_schema   => 'hr',
object_name     => 'employees',
policy_name     => 'secure_update',
policy_function => 'hide_fin',
policy_type     => dbms_rls.DYNAMIC);
END;
/

関連項目:
動的ポリシーの基礎となるポリシー関数の監査の仕組みは、「ファンクション、プロシージャ、パッケージおよびトリガーの監査の概要」を参照してください。

静的ポリシーの使用によるポリシー関数の問合せごとの再実行の回避

静的ポリシー・タイプを指定すると、インスタンス内のすべてのユーザーに対して同じ述語が規定されます。Oracle Databaseでは静的ポリシーの述語がSGAに格納されるため、ポリシー関数は問合せごとに再実行されません。その結果、パフォーマンスが向上します。

静的ポリシーを使用可能にするには、そのポリシーを複数のオブジェクト間で共有するかどうかに応じて、DBMS_RLS.ADD_POLICYプロシージャのpolicy_typeパラメータをSTATICまたはSHARED_STATICのいずれかに設定します。

例7-6に、STATICポリシー・タイプの作成方法を示します。

例7-6 DBMS_RLS.ADD_POLICYを使用したSTATICポリシーの作成

BEGIN
DBMS_RLS.ADD_POLICY(
object_schema   => 'hr',
object_name     => 'employees',
policy_name     => 'secure_update',
policy_function => 'hide_fin',
policy_type     => dbms_rls.STATIC);
END;
/

述語が同じでも、同じカーソルを実行するたびに異なる行セットが生成される場合があります。これは、述語によるデータのフィルタ処理がSYS_CONTEXTやSYSDATEなどの属性によって異なるためです。

たとえば、ポリシーをSTATICまたはSHARED_STATICポリシー・タイプとして使用可能にする場合を想定します。この場合は、ポリシーで保護されたデータベース・オブジェクトに対して実行されるすべての問合せに次の述語が追加されます。

WHERE dept = SYS_CONTEXT ('hr_app','deptno')

述語は、問合せごとに変わりませんが、SYS_CONTEXTのセッション属性に基づいて問合せに適用されます。前述の例の述語では、ポリシーで保護されたデータベース・オブジェクトを問い合せているユーザーの部門番号がSYS_CONTEXTのdeptno属性と一致する行のみを戻します。

注意:
共有の静的ポリシーを使用する場合は、ポリシーの述語に、列名など特定のデータベース・オブジェクト固有の属性が含まれていないことを確認してください。

関連項目:
静的ポリシーの基礎となるポリシー関数の監査の仕組みは、「ファンクション、プロシージャ、パッケージおよびトリガーの監査の概要」を参照してください。

共有の静的ポリシーの使用による複数オブジェクト間でのポリシーの共有

たとえば、使用する財務データを含むHRスキーマの2番目の表に例7-6のポリシーを適用する場合、両方の表でSHARED_STATIC設定を使用します。

例7-7に、同じポリシーを共有する2つの表に対してSHARED_STATICポリシー・タイプを設定する方法を示します。

例7-7 DBMS_RLS.ADD_POLICYを使用したSHARED_STATICポリシーの作成

-- 1. Create a policy for the first table, employees:
BEGIN
DBMS_RLS.ADD_POLICY(
object_schema   => 'hr',
object_name     => 'employees',
policy_name     => 'secure_update',
policy_function => 'hide_fin',
policy_type     => dbms_rls.SHARED_STATIC);
END;
/
-- 2. Create a policy for the second table, fin_data:
BEGIN
DBMS_RLS.ADD_POLICY(
object_schema   => 'hr',
object_name     => 'fin_data',
policy_name     => 'secure_update',
policy_function => 'hide_fin',
policy_type     => dbms_rls.SHARED_STATIC);
END;
/

静的ポリシーおよび共有の静的ポリシーを使用する場合

静的ポリシーは、すべての問合せに同じ述語が必要で、高いパフォーマンスが不可欠なホスト環境などに最適です。このような環境では、ポリシー関数がすべての問合せに同じ述語を追加すると、ポリシー関数を再実行するたびに不要なオーバーヘッドがシステムに加わります。たとえば、競争相手である複数の顧客企業に関する市場調査データが含まれたデータ・ウェアハウスを考えてみます。このウェアハウスでは、各企業が自社の市場調査データのみを参照できるポリシーを規定する必要があり、このポリシーは次の述語で表現されます。

WHERE subscriber_id = SYS_CONTEXT('customer', 'cust_num')

アプリケーション・コンテキストに対してSYS_CONTEXTを使用すると、データベースでは、戻される行を動的に変更できます。関数を再実行する必要はなく、述語はSGAにキャッシュされるため、システム・リソースを節約でき、パフォーマンスが向上します。

解析後に変更されない述語に対する状況依存ポリシーの使用

静的ポリシーとは対照的に、状況依存ポリシーは必ずしも述語をキャッシュしません。状況依存ポリシーの場合、データベースでは、述語は文の解析後に変更されると想定しています。ただし、ローカル・アプリケーション・コンテキストに変更がない場合、Oracle Databaseはユーザー・セッション内でポリシー関数を再実行しません。コンテキストに変更があった場合、データベースはポリシー関数を再実行して、最初の解析以降の述語に対する変更を取得します。

状況依存ポリシーを使用可能にするには、DBMS_RLS.ADD_POLICYプロシージャのpolicy_typeパラメータをCONTEXT_SENSITIVEまたはSHARED_CONTEXT_SENSITIVEに設定します。

例7-8に、CONTEXT_SENSITIVEポリシー・タイプの作成方法を示します。

例7-8 DBMS_RLS.ADD_POLICYを使用したCONTEXT_SENSITIVEポリシーの作成

BEGIN
DBMS_RLS.ADD_POLICY(
object_schema   => 'hr',
object_name     => 'employees',
policy_name     => 'secure_update',
policy_function => 'hide_fin',
policy_type     => dbms_rls.CONTEXT_SENSITIVE);
END;
/

状況依存ポリシーは、異なる述語を、問合せを実行するユーザーに応じて適用する必要がある場合に便利です。たとえば、マネージャには述語WHERE groupがmanagersに設定され、従業員には述語WHERE empnoがemp_idに設定される場合を考えてみます。

共有の状況依存ポリシーは、複数のデータベース・オブジェクト間で共有できる点を除いて、通常の状況依存ポリシーと同じように動作します。このポリシー・タイプの場合、すべてのオブジェクトがUGAのポリシー関数を共有でき、この場合、述語はローカル・セッション・コンテキストが変更されるまでキャッシュされます。

注意:
共有の状況依存ポリシーを使用する場合は、ポリシーの述語に、列名など特定のデータベース・オブジェクト固有の属性が含まれていないことを確認してください。

関連項目:
動的ポリシーの基礎となるポリシー関数の監査の仕組みは、「ファンクション、プロシージャ、パッケージおよびトリガーの監査の概要」を参照してください。

共有の状況依存ポリシーの使用による複数オブジェクト間でのポリシーの共有

例7-9に、複数の表で1つのポリシーを共有する、2つの共有の状況依存ポリシーを作成する方法を示します。

例7-9 DBMS_RLS.ADD_POLICYを使用したSHARED_CONTEXT_SENSITIVEポリシーの作成

-- 1. Create a policy for the first table, employees:
BEGIN
DBMS_RLS.ADD_POLICY(
object_schema   => 'hr',
object_name     => 'employees',
policy_name     => 'secure_update',
policy_function => 'hide_fin',
policy_type     => dbms_rls.SHARED_CONTEXT_SENSITIVE);
END;
/
--2. Create a policy for the second table, fin_data:
BEGIN
DBMS_RLS.ADD_POLICY(
object_schema   => 'hr',
object_name     => 'fin_data',
policy_name     => 'secure_update',
policy_function => 'hide_fin',
policy_type     => dbms_rls.SHARED_CONTEXT_SENSITIVE);
END;
/

状況依存ポリシーおよび共有の状況依存ポリシーを使用する場合

状況依存ポリシーは、ユーザー・セッションごとに述語を変える必要はないが、ポリシーが異なるユーザーまたはグループに複数の異なる述語を規定する必要がある場合に便利です。たとえば、単一のポリシーを持つsales_history表を考えてみます。このポリシーでは、アナリストは自分の製品のみを参照でき、地域担当者は自分の地域のみを参照できます。この場合、データベースは、ユーザーのタイプが変わるたびにポリシー関数を再実行する必要があります。サーバーによるポリシー関数の再実行なしに、ユーザーがログインして保護されたオブジェクトに対していくつかのDML文を発行できる場合は、パフォーマンスが向上します。

注意:
複数のクライアントが1つのデータベース・セッションを共有するセッション・プーリングの場合は、クライアント切替え時に中間層でコンテキストを再設定する必要があります。

5種類のOracle Virtual Private Databaseポリシー・タイプの要約

表7-2に、使用可能なポリシー・タイプの要約を示します。

表7-2 DBMS_RLS.ADD_POLICYのポリシー・タイプ

ポリシー・タイプ

ポリシー関数の実行

使用例

複数オブジェクト間での共有

DYNAMIC

ポリシーで保護されたデータベース・オブジェクトがアクセスされるたびに、ポリシー関数を再実行します。

日中の特定時間は、ユーザーによるデータベース・オブジェクトへのアクセスを拒否する時間依存のポリシーなど、ポリシーの述語を問合せごとに生成する必要があるアプリケーション。

なし

STATIC

1回。それから述語はSGAにキャッシュされます脚注 1

ビューの置換。

なし

SHARED_STATIC

STATICと同じです。

同じ述語を複数のデータベース・オブジェクトに適用する必要があるデータ・ウェアハウスなどのホスト環境。

あり

CONTEXT_SENSITIVE

- 文の解析時。

- 文の実行時(カーソルが最後に使用された後にローカル・アプリケーション・コンテキストが変更された場合)。

ポリシーによって異なるユーザーまたはグループに複数の述語が規定される、3層セッション・プーリング・アプリケーション。

なし

SHARED_CONTEXT_SENSITIVE

データベース・セッションで最初にオブジェクトが参照されたとき。

述語はプライベート・セッション・メモリーであるUGAにキャッシュされるため、ポリシー関数を複数のオブジェクト間で共有できます。

CONTEXT_SENSITIVEと同じですが、複数のオブジェクトがセッションのUGAからポリシー関数を共有できます。

あり

脚注1 述語が同じでも、同じカーソルを実行するたびに異なる行セットが生成される場合があります。これは、述語によるデータのフィルタ処理がSYS_CONTEXTやSYSDATEなどの属性によって異なるためです。

例: Oracle Virtual Private Databaseポリシーの作成

この項の内容は、次のとおりです。

- 例: 単純なOracle Virtual Private Databaseポリシーの作成

- 例: データベース・セッション・ベースのアプリケーション・コンテキストを使用したポリシーの実装

- 例: Oracle Virtual Private Databaseポリシー・グループの実装

例: 単純なOracle Virtual Private Databaseポリシーの作成

この項の内容は、次のとおりです。

- このチュートリアルの概要

- 手順1: OEユーザー・アカウントがアクティブであることの確認

- 手順2: ポリシー関数の作成

- 手順3: Oracle Virtual Private Databaseポリシーの作成

- 手順4: ポリシーのテスト

- 手順5: この例で使用したコンポーネントの削除

このチュートリアルの概要

営業担当者159が作成したOE.ORDERS表内のすべての受注へのアクセスを制限する、単純なOracle Virtual Private Databaseポリシーを作成する必要があるとします。このポリシーは、基本的に次の文で表現されます。

SELECT * FROM OE.ORDERS;

この文を次のように変換します。

SELECT * FROM OE.ORDERS
WHERE SALES_REP_ID = 159;

手順1: OEユーザー・アカウントがアクティブであることの確認

1. ユーザーSYSTEMとしてSYSDBA権限でSQL*Plusにログインします。

sqlplus sys as sysdba
Enter password: password

2. DBA_USERSデータ・ディクショナリ・ビューに対して、次のSELECT文を実行します。

SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'OE';

DBA_USERSビューに、ユーザーOEがロックされて期限切れになっていると表示された場合は、次の文を入力して、OEアカウントのロックを解除し、新しいパスワードを作成します。

ALTER USER OE ACCOUNT UNLOCK IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。セキュリティを向上させるため、以前のリリースのOracle Databaseで使用されたパスワードを再利用しないでください。詳細は、「パスワードの最低要件」を参照してください。

手順2: ポリシー関数の作成

次の関数を作成します。この関数はWHERE SALES_REP_ID = 159句を、OE.ORDERS表の任意のSELECT文に追加します。(最初の行のCREATE OR REPLACEの前にカーソルを置くことで、このテキストをコピーして貼り付けることができます。)

CREATE OR REPLACE FUNCTION auth_orders(
schema_var IN VARCHAR2,
table_var  IN VARCHAR2
)
RETURN VARCHAR2
IS
return_val VARCHAR2 (400);
BEGIN
return_val := 'SALES_REP_ID = 159';
RETURN return_val;
END auth_orders;
/

この例の説明は、次のとおりです。

- schema_varおよびtable_varは、スキーマ名(OE)および表名(ORDERS)を格納するために指定する入力パラメータを作成します。最初に、スキーマ用のパラメータを定義し、次に、オブジェクト(この例では表)用のパラメータを定義します。パラメータは常にこの順序で作成します。作成する仮想プライベート・データベース・ポリシーでは、OE.ORDERS表を指定するためにこれらのパラメータが必要です。

- RETURN VARCHAR2は、WHERE述語句に使用される文字列を返します。戻り値は常にVARCHAR2データ型になります。

- IS ... RETURN return_valは、WHERE SALES_REP_ID = 159述語の作成が含まれます。

手順3: Oracle Virtual Private Databaseポリシーの作成

次に、DBMS_RLSパッケージのADD_POLICYプロシージャを使用して、次のポリシーを作成します。(最初の行のBEGINの前にカーソルを置くことで、このテキストをコピーして貼り付けることができます。)

BEGIN
DBMS_RLS.ADD_POLICY (
object_schema    => 'oe',
object_name      => 'orders',
policy_name      => 'orders_policy',
function_schema  => 'sys',
policy_function  => 'auth_orders',
statement_types  => 'select, insert, update, delete'
);
END;
/

この例の説明は、次のとおりです。

- object_schema => 'oe'は、保護するスキーマ(この例ではOE)を指定します。

- object_name => 'orders'は、保護するスキーマ内のオブジェクト(この例ではORDERS表)を指定します。

- policy_name => 'orders_policy'は、このポリシーの名前をorders_policyと指定します。

- function_schema => 'sys'は、auth_orders関数が作成されたスキーマを指定します。この例では、auth_ordersはSYSスキーマに作成されています。ただし、通常は、セキュリティ管理者のスキーマに作成する必要があります。

- policy_function => 'auth_orders'は、ポリシーを規定する関数を指定します。この例では、「手順2: ポリシー関数の作成」で作成したauth_orders関数を指定します。

- statement_types => 'select'は、ポリシーを適用する操作を指定します。この例では、ポリシーは、ユーザーが実行可能なすべてのSELECT文、INSERT文、UPDATE文およびDELETE文に適用されます。

手順4: ポリシーのテスト

Oracle Virtual Private Databaseポリシーを作成した直後に、ポリシーは有効になります。ユーザー(スキーマの所有者を含む)が次にOE.ORDERSに対してSELECT文を実行すると、営業担当者159の受注のみにアクセスできます。

1. ユーザーOEでログインします。

CONNECT oe
Enter password: password

2. 次のSELECT文を入力します。

SELECT COUNT(*) FROM ORDERS;

次の出力が表示されます。

COUNT(*)
---------
7

ポリシーはユーザーOEに対して有効です。ここに示すように、受注表の105行の内、7行のみが戻されます。

ただし、管理権限を持つユーザーは、表のすべての行にアクセスできます。

3. ユーザーSYSで再度ログインします。

CONNECT sys/as sysdba
Enter password: password

4. 次のSELECT文を入力します。

SELECT COUNT(*) FROM OE.ORDERS;

次の出力が表示されます。

COUNT(*)
---------
105

手順5: この例で使用したコンポーネントの削除

1. ユーザーSYSで、次のように関数とポリシーを削除します。

DROP FUNCTION auth_orders;
EXEC DBMS_RLS.DROP_POLICY('OE','ORDERS','ORDERS_POLICY');

2. OEアカウントをロックして期限切れにする必要がある場合は、次の文を入力します。

ALTER USER OE ACCOUNT LOCK PASSWORD EXPIRE;

例: データベース・セッション・ベースのアプリケーション・コンテキストを使用したポリシーの実装

この項の内容は、次のとおりです。

- このチュートリアルの概要

- 手順1: ユーザー・アカウントとサンプル表の作成

- 手順2: データベース・セッション・ベースのアプリケーション・コンテキストの作成

- 手順3: アプリケーション・コンテキストを設定するPL/SQLパッケージの作成

- 手順4: アプリケーション・コンテキストのPL/SQLパッケージを実行するログイン・トリガーの作成

- 手順5: ユーザー・アクセスを自分の注文に制限するPL/SQLポリシー関数の作成

- 手順6: 新しいセキュリティ・ポリシーの作成

- 手順7: 新しいポリシーのテスト

- 手順8: この例で使用したコンポーネントの削除

このチュートリアルの概要

この例では、データベース・セッション・ベースのアプリケーション・コンテキストを使用して、顧客が自分の注文のみを参照できるというポリシーを実装する方法を示しています。次のようにセキュリティのレイヤーを作成します。

1. ユーザーがログインするとき、データベース・セッション・ベースのアプリケーション・コンテキストによって顧客かどうかがチェックされます。顧客でないユーザーでもログインできますが、このユーザーはこの例で作成する注文表にアクセスできません。

2. ユーザーが顧客の場合はログインできます。顧客がログインした後、Oracle Virtual Private Databaseポリシーによって、このユーザーは自分の注文のみを参照できるように制限されます。

3. さらなる制限として、Oracle Virtual Private Databaseポリシーによって、ユーザーは注文を追加、変更、または削除できなくなります。

手順1: ユーザー・アカウントとサンプル表の作成

1. SQL*Plusを起動して、管理権限を持つユーザーとしてログインします。

sqlplus sys as sysdba
Enter password: password

2. Oracle Virtual Private Databaseポリシーを管理する、次の管理ユーザーを作成します。
次のSQL文では、このユーザーを作成してから、この例を終了するのに必要な権限をユーザーに付与します。

GRANT CREATE SESSION, CREATE ANY CONTEXT, CREATE PROCEDURE, CREATE TRIGGER, ADMINISTER DATABASE TRIGGER TO sysadmin_vpd IDENTIFIED BY password;
GRANT EXECUTE ON DBMS_SESSION TO sysadmin_vpd;
GRANT EXECUTE ON DBMS_RLS TO sysadmin_vpd;

passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。

3. 次のユーザー・アカウントを作成します。

GRANT CREATE SESSION TO tbrooke IDENTIFIED BY password;
GRANT CREATE SESSION TO owoods IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。

4. この例で使用するサンプル・ユーザーSCOTTのステータスをチェックします。

SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'SCOTT';

DBA_USERSビューに、ユーザーSCOTTがロックされて期限切れになっていると表示された場合は、次の文を入力して、SCOTTアカウントのロックを解除し、新しいパスワードを作成します。

ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。セキュリティを向上させるため、以前のリリースのOracle Databaseで使用されたパスワードを再利用しないでください。詳細は、「パスワードの最低要件」を参照してください。

5. ユーザーSCOTTで接続し、customers表を作成して値を入力します。

CONNECT scott
Enter password: password

CREATE TABLE customers (
cust_no    NUMBER(4),
cust_email VARCHAR2(20),
cust_name  VARCHAR2(20));

INSERT INTO customers VALUES (1234, 'TBROOKE', 'Thadeus Brooke');
INSERT INTO customers VALUES (5678, 'OWOODS', 'Oberon Woods');

ユーザーの電子メール・アドレスを入力する際には、大文字で入力します。後でアプリケーション・コンテキストのPL/SQLパッケージを作成するときに、SYS_CONTEXTファンクションのSESSION_USERパラメータではユーザー名が大文字であると想定されます。大文字でないと、そのユーザー用のアプリケーション・コンテキストを設定できません。

6. ユーザーsysadmin_vpdには、ユーザーSCOTTと同様にcustomers表のSELECT権限が必要になるため、この権限をsysadmin_vpdに付与します。

GRANT SELECT ON customers TO sysadmin_vpd;

7. orders_tab表を作成して値を入力します。

CREATE TABLE orders_tab (
cust_no  NUMBER(4),
order_no NUMBER(4));

INSERT INTO orders_tab VALUES (1234, 9876);
INSERT INTO orders_tab VALUES (5678, 5432);
INSERT INTO orders_tab VALUES (5678, 4592);

8. ユーザーtbrookeとowoodsはorders_tab表を問い合せる必要があるため、これらのユーザーにSELECT権限を付与します。

GRANT SELECT ON orders_tab TO tbrooke;
GRANT SELECT ON orders_tab TO owoods;

orders_tab受注表には、2名のサンプル顧客tbrookeとowoodsの購買レコードがあります。この段階では、これらの顧客がこの表を参照すると、すべての受注を参照できます。

手順2: データベース・セッション・ベースのアプリケーション・コンテキストの作成

1. ユーザーsysadmin_vpdで接続します。

CONNECT sysadmin_vpd
Enter password: password

2. 次の文を入力します。

CREATE OR REPLACE CONTEXT orders_ctx USING orders_ctx_pkg;

この文は、orders_ctxアプリケーション・コンテキストを作成します。ユーザーsysadmin_vpdがこのコンテキストを作成してsysadmin_vpdスキーマに対応付けた場合でも、SYSスキーマがこのアプリケーション・コンテキストを所有することに注意してください。

手順3: アプリケーション・コンテキストを設定するPL/SQLパッケージの作成

ユーザーsysadmin_vpdとして、次のPL/SQLパッケージを作成します。このパッケージは、顧客tbrookeおよびowoodsがそれぞれのアカウントにログインすると、データベース・セッション・ベースのアプリケーション・コンテキストを設定します。(最初の行のCREATE OR REPLACEの前にカーソルを置くことで、このテキストをコピーして貼り付けることができます。)

CREATE OR REPLACE PACKAGE orders_ctx_pkg IS
PROCEDURE set_custnum;
END;
/
CREATE OR REPLACE PACKAGE BODY orders_ctx_pkg IS
PROCEDURE set_custnum
AS
custnum NUMBER;
BEGIN
SELECT cust_no INTO custnum FROM SCOTT.CUSTOMERS
WHERE cust_email = SYS_CONTEXT('USERENV', 'SESSION_USER');
DBMS_SESSION.SET_CONTEXT('orders_ctx', 'cust_no', custnum);
EXCEPTION
WHEN NO_DATA_FOUND THEN NULL;
END set_custnum;
END;
/

この例の説明は、次のとおりです。

- custnum NUMBERは、顧客IDを保持するcustnum変数を作成します。

- SELECT cust_no INTO custnumは、SELECT文を実行し、scott.customers表のcust_no列データに格納されている顧客IDをcustnum変数にコピーします。

- WHERE cust_email = SYS_CONTEXT('USERENV', 'SESSION_USER')は、WHERE句を使用して、ログインしたユーザーのユーザー名と一致するすべての顧客IDを検索します。

- DBMS_SESSION.SET_CONTEXT('orders_ctx', 'cust_no', custnum)は、cust_no属性を作成した後、custnum変数に格納されている値に設定することで、orders_ctxアプリケーション・コンテキストの値を設定します。

- EXCEPTION ... WHENは、WHEN NO_DATA_FOUNDシステム例外を追加して、10から11行目のSELECT文によって発生した可能性のあるno data foundエラーを捕捉します。

要約すると、sysadmin_vpd.set_cust_numプロシージャは、セッション・ユーザーの顧客IDを選択してcustnum変数に格納することによって、ユーザーが登録済顧客かどうかを識別します。ユーザーが登録済顧客の場合、Oracle Databaseによってこのユーザーにアプリケーション・コンテキスト値が設定されます。「手順5: ユーザー・アクセスを自分の注文に制限するPL/SQLポリシー関数の作成」に示すように、ポリシー関数では、コンテキスト値を使用して、ユーザーがorders_tab表内のデータに対して持つアクセスを制御します。

手順4: アプリケーション・コンテキストのPL/SQLパッケージを実行するログイン・トリガーの作成

次回ユーザーがログインすると、ログイン・トリガーによって、「手順3: アプリケーション・コンテキストを設定するPL/SQLパッケージの作成」で作成したPL/SQLパッケージのプロシージャが実行されるため、アプリケーション・コンテキストを設定できます。

ユーザーsysadmin_vpdで、次のトリガーを作成します。

CREATE TRIGGER set_custno_ctx_trig AFTER LOGON ON DATABASE
BEGIN
sysadmin_vpd.orders_ctx_pkg.set_custnum;
END;
/

関連項目:
「データベース・セッション・ベースのアプリケーション・コンテキスト・パッケージを実行するためのログイン・トリガーの作成」

この段階で、tbrookeまたはowoodsでログインすると、ログイン・トリガーによってsysadmin_vpd.orders_ctx_pkg.set_custnumプロシージャの起動時にユーザー用のアプリケーション・コンテキストが設定されます。これは次のようにテストできます。

CONNECT tbrooke
Enter password: password

SELECT SYS_CONTEXT('orders_ctx', 'cust_no') custnum FROM DUAL;

次の出力が表示されます。

EMP_ID
-------------------------------------------------------------------
1234

手順5: ユーザー・アクセスを自分の注文に制限するPL/SQLポリシー関数の作成

次の手順では、ログインしたユーザーがSELECT * FROM scott.orders_tab問合せを実行するとそのユーザーの注文のみが表示されるように、PL/SQLファンクションを作成します。

ユーザーsysadmin_vpdで、次の関数を作成します。

CREATE OR REPLACE FUNCTION get_user_orders(
schema_p   IN VARCHAR2,
table_p    IN VARCHAR2)
RETURN VARCHAR2
AS
orders_pred VARCHAR2 (400);
BEGIN
orders_pred := 'cust_no = SYS_CONTEXT(''orders_ctx'', ''cust_no'')';
RETURN orders_pred;
END;
/

この関数は、「表示される注文がログインしたユーザーに属する場合」に変換されるWHERE述語を作成して返します。それからこのWHERE述語を、このユーザーがscott.orders_tab表に対して実行するあらゆる問合せに追加します。問合せが追加されると、この関数をorders_tab表に適用するOracle Virtual Private Databaseポリシーを作成できます。

手順6: 新しいセキュリティ・ポリシーの作成

ユーザーsysadmin_vpdで、次のポリシーを作成します。

BEGIN
DBMS_RLS.ADD_POLICY (
object_schema    => 'scott',
object_name      => 'orders_tab',
policy_name      => 'orders_policy',
function_schema  => 'sysadmin_vpd',
policy_function  => 'get_user_orders',
statement_types  => 'select');
END;
/

この文は、SCOTTスキーマで、orders_policyという名前のポリシーを作成して、顧客が自分の注文について問い合せるためのorders_tab表に適用します。get_user_orders関数が実装するこのポリシーは、sysadmin_vpdスキーマに格納されます。このポリシーは、さらに、ユーザーがSELECT文のみを発行するように制限します。

手順7: 新しいポリシーのテスト

1. ユーザーtbrookeでログインします。

CONNECT tbrooke
Enter password: password

ユーザーtbrookeは、アプリケーション・コンテキストに定義した要件を通過できるため、ログインできます。

2. ユーザーtbrookeで、購買レコードにアクセスします。

SELECT * FROM scott.orders_tab;

次の出力が表示されます。

CUST_NO    ORDER_NO
----------  ----------
1234        9876

ユーザーtbrookeは、2番目のテストを通過します。このユーザーは、scott.orders_tab表にある自分の注文のみにアクセスできます。

3. ユーザーowoodsでログインし、購買レコードにアクセスします。

CONNECT owoods
Enter password: passwords

SELECT * FROM scott.orders_tab

次の出力が表示されます。

CUST_NO    ORDER_NO
----------  ----------
5678        5432
5678        4592

ユーザーtbrookeとユーザーowoodsはログインでき、自分の注文のリストを参照できます。

次のことに注意してください。

- ユーザーの職位に基づいて複数の述語を作成できます。たとえば、営業担当者は自分の担当顧客のレコードのみを参照でき、受注入力担当はすべての顧客注文を参照できます。ユーザーの職位のコンテキスト値に基づいて別の述語を返すようにcustnum_sec機能を拡張できます。

- ファイングレイン・アクセス・コントロール・パッケージ内でアプリケーション・コンテキストを使用することによって、実際には解析済の文の中にバインド変数が指定されます。例:

SELECT * FROM scott.orders_tab
WHERE cust_no = SYS_CONTEXT('order_entry', 'cust_num');

この文は完全に解析および最適化されますが、order_entryコンテキストに対するユーザーのcust_num属性値の評価は、実行時に行われます。これは、最適化された文には、その文を発行するユーザーごとに異なる形態で実行されるという利点があることを意味します。

注意:
この例の関数のパフォーマンスは、cust_noに索引を作成するとさらに向上します。

- コンテキスト属性は、データベース表(複数も可)のデータ、またはLightweight Directory Access Protocol(LDAP)を使用するディレクトリ・サーバーのデータに基づいて設定できます。

関連項目:
トリガーの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

動的に生成された述語の中でアプリケーション・コンテキストを使用するこの例と、述語の中で副問合せを使用する「Oracle Virtual Private Databaseポリシーの概要」を比較してください。

手順8: この例で使用したコンポーネントの削除

1. ユーザーOEで接続し、orders_tabおよびcustomers表を削除します。

CONNNECT SCOTT
Enter password: password

DROP TABLE orders_tab;
DROP TABLE customers;

2. ユーザーSYSとしてAS SYSDBAで接続します。

CONNECT sys/as sysdba
Enter password: password

3. 次の文を実行して、この例で使用したコンポーネントを削除します。

DROP CONTEXT orders_ctx;
DROP USER sysadmin_vpd CASCADE;
DROP USER tbrooke;
DROP USER owoods;

例: Oracle Virtual Private Databaseポリシー・グループの実装

この項の内容は、次のとおりです。

- このチュートリアルの概要

- 手順1: この例で使用するユーザー・アカウントと他のコンポーネントの作成

- 手順2: 2つのポリシー・グループの作成

- 手順3: ポリシー・グループを制御するPL/SQLファンクションの作成

- 手順4: PL/SQLファンクションのポリシー・グループへの追加

- 手順5: 駆動アプリケーション・コンテキストの作成

- 手順6: ポリシー・グループのテスト

- 手順7: この例で使用したコンポーネントの削除

このチュートリアルの概要

アプリケーションで使用する一連のポリシーをグループ化する方法は、「Oracle Virtual Private Databaseポリシー・グループの使用」を参照してください。非データベース・ユーザーがアプリケーションにログインすると、Oracle Databaseでは、適切なポリシー・グループ内で定義されたポリシーに基づいてユーザーにアクセス権が付与されます。

列レベルのアクセス制御の場合、各列または非表示の列セットが1つのポリシーで制御されます。この例では、2つの列セットを非表示にする必要があります。そのため、非表示にする列セットごとに1つずつ、2つのポリシーを作成します。ユーザーごとに必要なポリシーは1つのみのため、駆動アプリケーション・コンテキストによってポリシーが分割されます。

手順1: この例で使用するユーザー・アカウントと他のコンポーネントの作成

1. ユーザーSYSとしてSYSDBA権限でログインします。

sqlplus sys as sysdba
Enter password: password

2. 次のユーザーを作成します。

GRANT CREATE SESSION TO apps_user IDENTIFIED BY password;
GRANT CREATE SESSION, CREATE PROCEDURE, CREATE ANY CONTEXT TO sysadmin_pg IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。

3. ユーザーsysadmin_pgに次の権限を追加付与します。

GRANT EXECUTE ON DBMS_RLS TO sysadmin_pg;

4. ユーザーOEでログインします。

CONNECT OE
Enter password: password

OEアカウントがロックされて期限切れになっている場合、SYSDBA権限を持つユーザーSYSとして再接続してから、次の文を入力してアカウントのロックを解除し、新しいパスワードを指定します。

ALTER USER OE ACCOUNT UNLOCK IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。セキュリティを向上させるため、以前のリリースのOracle Databaseで使用されたパスワードを再利用しないでください。詳細は、「パスワードの最低要件」を参照してください。

5. product_code_names表を作成します。

CREATE TABLE product_code_names(
group_a     varchar2(32),
year_a      varchar2(32),
group_b     varchar2(32),
year_b      varchar2(32));

6. product_code_names表に値をいくつか挿入します。

INSERT INTO product_code_names values('Biffo','2008','Beffo','2004');
INSERT INTO product_code_names values('Hortensia','2008','Bunko','2008');
INSERT INTO product_code_names values('Boppo','2006','Hortensia','2003');

COMMIT;

7. product_code_names表のSELECT権限をapps_userユーザーに付与します。

GRANT SELECT ON product_code_names TO apps_user;

手順2: 2つのポリシー・グループの作成

次に、2人の非データベース・ユーザーprovider_aおよびprovider_bにそれぞれポリシー・グループを作成する必要があります。

1. ユーザーsysadmin_pgで接続します。

CONNECT sysadmin_pg
Enter password: password

2. ユーザーprovider_aにより使用されるprovider_a_groupポリシー・グループを作成します。

BEGIN
DBMS_RLS.CREATE_POLICY_GROUP(
object_schema   => 'oe',
object_name     => 'product_code_names',
policy_group    => 'provider_a_group');
END;
/

3. ユーザーprovider_bにより使用されるprovider_b_groupポリシー・グループを作成します。

BEGIN
DBMS_RLS.CREATE_POLICY_GROUP(
object_schema   => 'oe',
object_name     => 'product_code_names',
policy_group    => 'provider_b_group');
END;
/

手順3: ポリシー・グループを制御するPL/SQLファンクションの作成

「手順2: 2つのポリシー・グループの作成」で作成した各ポリシー・グループには、ユーザーprovider_aおよびprovider_bのデータ・アクセスをアプリケーションで制御する方法を定義した関数が必要です。

1. ユーザーprovider_aがアクセスするデータを制限するvpd_function_provider_a関数を作成します。

CREATE OR REPLACE FUNCTION vpd_function_provider_a
(schema in varchar2, tab in varchar2) return varchar2 as
predicate  varchar2(8) default NULL;
BEGIN
IF LOWER(SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER')) = 'provider_a'
THEN predicate := '1=2';
ELSE NULL;
END IF;
RETURN predicate;
END;
/

この関数では、ログインするユーザーが確かにユーザーprovider_aであるかどうかがチェックされます。間違いない場合、provider_aが表示できるのは、product_code_names表の列group_aおよびyear_a内のデータのみとなります。列group_bおよびyear_b内のデータは、provider_aに表示されません。つまり、predicate := '1=2'を設定すると関連列が非表示になります。「手順4: PL/SQLファンクションのポリシー・グループへの追加」では、これらの列をSEC_RELEVANT_COLSパラメータに指定します。

この関数タイプのコンポーネントの詳細は、「動的なWHERE句を生成する関数の作成」を参照してください。

2. ユーザーprovider_aがアクセスするデータを制限するvpd_function_provider_b関数を作成します。

CREATE OR REPLACE FUNCTION vpd_function_provider_b
(schema in varchar2, tab in varchar2) return varchar2 as
predicate  varchar2(8) default NULL;
BEGIN
IF LOWER(SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER')) = 'provider_b'
THEN predicate := '1=2';
ELSE NULL;
END IF;
RETURN predicate;
END;
/

vpd_function_provider_a関数と同様に、この関数では、ログインするユーザーが確かにユーザーprovider_bであるかどうかがチェックされます。間違いない場合、provider_bが表示できるのは、列group_bおよびyear_b内のデータのみであり、group_aおよびyear_a内のデータはprovider_bには表示されません。vpd_function_provider_a関数と同様に、predicate := '1=2'に指定すると、「手順4: PL/SQLファンクションのポリシー・グループへの追加」でSEC_RELEVANT_COLSパラメータに指定する関連列が非表示になります。

手順4: PL/SQLファンクションのポリシー・グループへの追加

必要な関数を作成したら、適切なポリシー・グループに関数を関連付ける必要があります。

1. vpd_function_provider_a関数をprovider_a_groupポリシー・グループに追加します。

BEGIN
DBMS_RLS.ADD_GROUPED_POLICY(
object_schema         => 'oe',
object_name           => 'product_code_names',
policy_group          => 'provider_a_group',
policy_name           => 'filter_provider_a',
function_schema       => 'sysadmin_pg',
policy_function       => 'vpd_function_provider_a',
statement_types       => 'select',
policy_type           => DBMS_RLS.CONTEXT_SENSITIVE,
sec_relevant_cols     => 'group_b,year_b',
sec_relevant_cols_opt => DBMS_RLS.ALL_ROWS);
END;
/

sec_relevant_colsパラメータで指定したgroup_bおよびyear_b列は、ユーザーprovider_aに対して非表示になります。

2. vpd_function_provider_b関数をprovider_b_groupポリシー・グループに追加します。

BEGIN
DBMS_RLS.ADD_GROUPED_POLICY(
object_schema         => 'oe',
object_name           => 'product_code_names',
policy_group          => 'provider_b_group',
policy_name           => 'filter_provider_b',
function_schema       => 'sysadmin_pg',
policy_function       => 'vpd_function_provider_b',
statement_types       => 'select',
policy_type           => DBMS_RLS.CONTEXT_SENSITIVE,
sec_relevant_cols     => 'group_a,year_a',
sec_relevant_cols_opt => DBMS_RLS.ALL_ROWS);
END;
/

sec_relevant_colsパラメータで指定したgroup_aおよびyear_a列は、ユーザーprovider_bに対して非表示になります。

手順5: 駆動アプリケーション・コンテキストの作成

アプリケーション・コンテキストにより、ログインする非データベース・ユーザーが使用する必要があるポリシーが決定されます。

1. ユーザーsysadmin_pgで、次の駆動アプリケーション・コンテキストを作成します。

CREATE OR REPLACE CONTEXT provider_ctx USING provider_package;

2. アプリケーション・コンテキストに対してPL/SQL provider_packageパッケージを作成します。

CREATE OR REPLACE PACKAGE provider_package IS
PROCEDURE set_provider_context (policy_group varchar2 default NULL);
END;
/
CREATE OR REPLACE PACKAGE BODY provider_package AS
PROCEDURE set_provider_context (policy_group varchar2 default NULL) IS
BEGIN
CASE LOWER(SYS_CONTEXT('USERENV', 'CLIENT_IDENTIFIER'))
WHEN 'provider_a' THEN
DBMS_SESSION.SET_CONTEXT('provider_ctx','policy_group','PROVIDER_A_GROUP');
WHEN 'provider_b' THEN
DBMS_SESSION.SET_CONTEXT('provider_ctx','policy_group','PROVIDER_B_GROUP');
END CASE;
END set_provider_context;
END;
/

3. provider_ctxアプリケーション・コンテキストをproduct_code_names表に関連付け、名前を指定します。

BEGIN
DBMS_RLS.ADD_POLICY_CONTEXT(
object_schema  =>'oe',
object_name    =>'product_code_names',
namespace      =>'provider_ctx',
attribute      =>'policy_group');
END;
/

4. apps_userアカウントにprovider_packageパッケージに対するEXECUTE権限を付与します。

GRANT EXECUTE ON provider_package TO apps_user;

手順6: ポリシー・グループのテスト

これで、2つのポリシー・グループをテストできます。

1. ユーザーapps_userとして接続した後、次の文を入力して、後で作成する出力の書式が適切に設定されるようにします。

CONNECT apps_user
Enter password: password

col group_a format a16
col group_b format a16;
col year_a format a16;
col year_b format a16;

2. セッション識別子をprovider_aに設定します。

EXEC DBMS_SESSION.SET_IDENTIFIER('provider_a');

ここで、アプリケーションが識別子を設定します。識別子をprovider_aに設定すると、apps_userユーザーは、provider_a_groupポリシー・グループ内の製品に使用可能な製品のみが表示されるユーザーとして設定されます。

3. provider_packageを実行し、コンテキストに基づいてポリシー・グループを設定します。

EXEC sysadmin_pg.provider_package.set_provider_context;

この時点で、アプリケーション・コンテキストが設定されたことを、次のように確認できます。

SELECT SYS_CONTEXT('USERENV', 'CLIENT_IDENTIFIER') AS END_USER FROM DUAL;

次の出力が表示されます。

END_USER
-----------------
provider_a

4. 次のSELECT文を入力します。

SELECT * FROM oe.product_code_names;

次の出力が表示されます。

GROUP_A          YEAR_A           GROUP_B          YEAR_B
---------------- ---------------- ---------------- ----------------
Biffo            2008
Hortensia        2008
Boppo            2006

5. クライアント識別子をprovider_bに設定し、次の文を入力します。

EXEC DBMS_SESSION.SET_IDENTIFIER('provider_b');
EXEC sysadmin_pg.provider_package.set_provider_context;
SELECT * FROM oe.product_code_names;

次の出力が表示されます。

GROUP_A          YEAR_A           GROUP_B          YEAR_B
---------------- ---------------- ---------------- ----------------
Beffo            2004
Bunko            2008
Hortensia        2003

手順7: この例で使用したコンポーネントの削除

1. ユーザーOEで接続し、product_code_names表を削除します。

CONNECT OE
Enter password: password

DROP TABLE product_code_names;

2. ユーザーSYSで接続し、この例で使用したアプリケーション・コンテキストとユーザーを削除します。

CONNECT SYS/AS SYSDBA
Enter password: password

DROP CONTEXT provider_ctx;
DROP USER sysadmin_pg cascade;
DROP USER apps_user;

他のOracle機能でのOracle Virtual Private Databaseの使用

この項の内容は、次のとおりです。

- Oracle Virtual Private Databaseポリシーとエディションの併用

- VPD保護表に対するユーザーの問合せでのSELECT FOR UPDATEの使用

- Oracle Virtual Private Databaseポリシーの外部結合操作またはANSI結合操作への影響

- アプリケーションでのOracle Virtual Private Databaseセキュリティ・ポリシーの使用

- ファイングレイン・アクセス・コントロールのポリシー関数に対する自動再解析の使用

- Oracle Virtual Private Databaseポリシーとフラッシュバック問合せの使用

- Oracle Virtual Private DatabaseおよびOracle Label Securityの使用

- EXPDPユーティリティaccess_methodパラメータを使用したデータのエクスポート

- ユーザー・モデルとOracle Virtual Private Database

Oracle Virtual Private Databaseポリシーとエディションの併用

アプリケーションをエディションベースの再定義用に準備し、アプリケーションで使用される各表をエディショニング・ビューで保護する場合は、これらの表を保護するVirtual Private Databaseポリシーをエディショニング・ビューに移動する必要があります。

エディション付きオブジェクトにVirtual Private Databaseポリシーが付加されている場合、そのオブジェクトが表示されるすべてのエディションにそのポリシーが適用されます。エディション付きオブジェクトが実現化されると、そのオブジェクトに付加されているVPDポリシーが新しい実際のオブジェクトに新たに付加されます。継承されたエディション付きオブジェクトに新たにVPDポリシーを適用すると、そのオブジェクトが実現化されます。

関連項目:
エディションの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

VPD保護表に対するユーザーの問合せでのSELECT FOR UPDATEの使用

原則として、ユーザーは、Virtual Private Database保護表を問い合せる場合にFOR UPDATE句を含めないようにします。Virtual Private Databaseテクノロジは、VPDポリシー関数によって生成されたVPD述語を含むインライン・ビューに対するユーザーの問合せをリライトする処理に基づいています。このため、ビューに対する制限事項はVPD保護表にも同様に適用されます。VPD保護表に対するユーザーの問合せでSELECT文にFOR UPDATE句が含まれていると、ほとんどの場合、その問合せは動作しません。ただし、VPDによって生成されたインライン・ビューが非常に単純である場合、ユーザーの問合せが動作することがあります。

関連項目:
SELECT文のFOR UPDATE句の制限事項の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

Oracle Virtual Private Databaseポリシーの外部結合操作またはANSI結合操作への影響

Oracle Virtual Private Databaseでは、動的ビューを使用して、SQLをリライトします。SQLに外部結合操作またはANSI操作が含まれていると、一部のビューがマージされない場合や、一部の索引が使用されない場合があります。この問題は既知の最適化制限です。この問題に対処するには、SQLをリライトして外部結合操作やANSI操作が使用されないようにします。

アプリケーションでのOracle Virtual Private Databaseセキュリティ・ポリシーの使用

Oracle Virtual Private Databaseセキュリティ・ポリシーは、アプリケーション内ではなく、データベース内で適用されます。したがって、ユーザーが異なるアプリケーションを使用してデータにアクセスしようとしても、Oracle Virtual Private Databaseセキュリティ・ポリシーを回避できません。データベースにセキュリティ・ポリシーを作成するもう1つの利点は、複数のアプリケーションで各セキュリティ・ポリシーを保持するのではなく、1箇所でセキュリティ・ポリシーを保持できることです。このため、Oracle Virtual Private Databaseは、アプリケーション・ベースのセキュリティよりも強力なセキュリティを提供し、所有権のコストもより低くなります。

データにアクセスしているアプリケーションに応じて、異なるセキュリティ・ポリシーを規定する必要がある場合があります。Order Entry(受注管理)およびInventory(在庫管理)の2つのアプリケーションが、両方ともorders表にアクセスする場合を考えてみます。Inventoryアプリケーションで、製品の種類に基づいてアクセスを制限するポリシーを使用するとします。同時に、Order Entryアプリケーションでも、顧客番号に基づいてアクセスを制限するポリシーを使用するとします。

この場合、アプリケーションによるファイングレイン・アクセスの使用を分割する必要があります。分割しないと、2つのポリシーが自動的に連結され、目的とする結果が得られません。複数のポリシー・グループ、および特定のトランザクションに対して有効なポリシー・グループを判断する駆動アプリケーションのコンテキストを指定できます。また、データ・アクセスに対して必ず適用するデフォルト・ポリシーも指定できます。たとえば、ホスティングされたアプリケーションでは、データ・アクセスはサブスクライバIDによって制限されます。使用するグループの決定にアプリケーション・コンテキストを使用するポリシー・グループの作成方法の例は、「例: Oracle Virtual Private Databaseポリシー・グループの実装」を参照してください。

ファイングレイン・アクセス・コントロールのポリシー関数に対する自動再解析の使用

デフォルトでは、各ポリシーに対して最新の述語が使用されるように、ファイングレイン・アクセス・コントロール対応のオブジェクトに対する問合せでポリシー関数が実行されます。たとえば、問合せを午前8時から午後5時の間に限定する時間ベースのポリシー関数の場合は、正午にカーソルの実行を解析すると、その時点でこのポリシー関数が実行され、問合せに対してポリシーが再度参照されます。カーソルが午前9時に解析された場合でも、そのカーソルが後で(たとえば、正午に)実行されると、Virtual Private Databaseポリシー関数が再び実行され、カーソルの実行が現時点(正午)でも引き続き許可されるようになります。これにより、常に最新のセキュリティ・チェックが実行されます。

Virtual Private Databaseポリシー関数の自動再実行は、ポリシーを追加するときにDBMS_RLS.ADD_POLICY設定のSTATIC_POLICYをTRUEに設定した場合は行われません。この設定の場合、ポリシー関数は同じ述語を戻します。

Oracle Virtual Private Databaseポリシーとフラッシュバック問合せの使用

デフォルトでは、データベース上での操作では、直前にコミットされた使用可能データが使用されます。フラッシュバック問合せ機能により、過去のどこかの時点でのデータベースの問合せが可能になります。フラッシュバック問合せを使用するアプリケーションを作成するには、SQL問合せでAS OF句を使用して、時間とシステム変更番号(SCN)のどちらかを指定して、指定された時間からコミット済データに対して問い合せます。DBMS_FLASHBACK PL/SQLパッケージを使用することもできます。このPL/SQLパッケージでは必要なコードが増えますが、複数の操作を実行でき、これらの操作のすべてが同じ時点を参照します。

ただし、Oracle Virtual Private Databaseポリシーで保護されているデータベース・オブジェクトに対してフラッシュバック問合せを使用すると、現行のポリシーが過去のデータに適用されます。現行のOracle Virtual Private Databaseポリシーをフラッシュバック問合せのデータに適用すると、最新のビジネス・ポリシーが反映されるため、安全性が高まります。

関連項目:

- フラッシュバック問合せ機能、およびフラッシュバック問合せを使用するアプリケーションの作成方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- DBMS_FLASHBACK PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

Oracle Virtual Private DatabaseおよびOracle Label Securityの使用

この項の内容は、次のとおりです。

- Oracle Virtual Private Databaseを使用したOracle Label Securityポリシーの規定

- Oracle Virtual Private DatabaseおよびOracle Label Securityの例外

関連項目:
『Oracle Label Security管理者ガイド』

Oracle Virtual Private Databaseを使用したOracle Label Securityポリシーの規定

Oracle Virtual Private Databaseポリシーを使用して、Oracle Label Securityユーザー認可に基づいて列または行レベルのアクセス制御を提供できます。一般に、次の手順を実行する必要があります。

1. Oracle Label Securityのポリシーを作成したら、保護する必要がある表にこのポリシーを適用しないでください。(作成した仮想プライベート・データベース・ポリシーによって自動的に処理されます。)SA_SYSDBA.CREATE_POLICYプロシージャで、default_optionsパラメータをNO_CONTROLに設定します。

2. Oracle Label Securityのラベル・コンポーネントを作成し、通常どおりユーザーを認可します。

3. Oracle Virtual Private Databaseポリシーを作成する際には、次の操作を行います。

- ポリシーについて作成するPL/SQLファンクションでは、Oracle Label SecurityのDOMINATESファンクションを使用して、ユーザーの認可を手順2で作成したラベルと比較します。(支配ファンクションの詳細は、『Oracle Label Security管理者ガイド』を参照してください。)DOMINATESファンクションにより、ユーザーの認可が比較で使用されたラベルと等しい、またはラベルより機密性が高いかどうかが判別されます。ユーザー認可が通過した場合、ユーザーは列に対するアクセス権を付与されます。通過しない場合、ユーザーはアクセスを拒否されます。

- 仮想プライベート・データベース・ポリシー定義で、保護する必要がある表にこのファンクションを適用します。DBMS_RLS.ADD_POLICYプロシージャで、機密性の高い列(SEC_RELEVANT_COLSパラメータ)および列のマスク(SEC_RELEVANT_COLS_OPTパラメータ)機能を使用して、Oracle Label Securityユーザー認可に基づいて列を表示または非表示にします。

この方法を示した例については、次のOracle Technology Networkのサイトにアクセスしてください。

http://www.oracle.com/technetwork/database/focus-areas/security/ols-cs1-099558.html">>http://www.oracle.com/technetwork/database/focus-areas/security/ols-cs1-099558.html

Oracle Virtual Private DatabaseおよびOracle Label Securityの例外

Oracle Virtual Private DatabaseおよびOracle Label Securityを使用する場合は、次の例外に注意してください。

- データのエクスポート時、Oracle Virtual Private DatabaseおよびOracle Label Securityのポリシーはダイレクト・パス・エクスポート操作では規定されません。ダイレクト・パス・エクスポート操作では、Oracle Databaseはディスクからバッファ・キャッシュにデータを読み込み、行をエクスポート・クライアントに直接転送します。ダイレクト・パス・エクスポート操作の詳細は、『Oracle Databaseユーティリティ』を参照してください。

- Oracle Virtual Private DatabaseおよびOracle Label Securityのポリシーは、SYSスキーマのオブジェクトに適用できません。SYSユーザーおよびデータベースにDBA権限でアクセスするユーザー(CONNECT/AS SYSDBAなど)の場合、それらのユーザーのアクションにOracle Virtual Private DatabaseまたはOracle Label Securityのポリシーは適用されません。したがって、データベース・ユーザーSYSは、データベースからデータを抽出するために使用するエクスポート・モード、アプリケーションまたはユーティリティに関係なく、常にOracle Virtual Private DatabaseまたはOracle Label Securityの規定対象から除外されます。
ただし、SYSDBAのアクションは、インストール時に監査を有効にし、監査証跡をオペレーティング・システムの保護位置に格納するように指定することによって監査できます。詳細は、「SYS管理ユーザーの監査」を参照してください。SYSユーザーはOracle Database Vaultを使用して詳細に監視できます。

- EXEMPT ACCESS POLICY権限を直接的またはデータベース・ロールを介して付与されているデータベース・ユーザーは、Oracle Virtual Private Databaseの規定対象から除外されます。システム権限EXEMPT ACCESS POLICYを持つユーザーは、すべてのSELECTまたはDML操作(INSERT、UPDATEおよびDELETE)において、ファイングレイン・アクセス・コントロール・ポリシーの対象から除外されます。これによって、インストールや、SYS以外のスキーマを介したデータベースのインポートとエクスポートなどの管理アクティビティが使いやすくなります。
ただし、ポリシーを規定する次のオプションは、EXEMPT ACCESS POLICYが付与されている場合も規定されます。

- INSERT_CONTROL、UPDATE_CONTROL、DELETE_CONTROL、WRITE_CONTROL、LABEL_UPDATEおよびLABEL_DEFAULT

- Oracle Label SecurityのポリシーにALL_CONTROLオプションを指定した場合は、READ_CONTROLおよびCHECK_CONTROL以外のすべてが規定の対象として適用されます。

EXEMPT ACCESS POLICYは、ファイングレイン・アクセス・コントロールを無効にするため、この権限は、ファイングレイン・アクセス・コントロールの規定を回避する正当な理由を持つユーザーに対してのみ付与する必要があります。この権限はWITH ADMIN OPTIONを使用して付与しないでください。これを使用すると、ユーザーが他のユーザーにEXEMPT ACCESS POLICY権限を譲渡して、ファイングレイン・アクセス・コントロールを回避する権限が伝播する可能性があります。

注意:

- EXEMPT ACCESS POLICY権限は、SELECT、INSERT、UPDATEおよびDELETEなどのオブジェクト権限の規定には影響しません。これらのオブジェクト権限は、ユーザーにEXEMPT ACCESS POLICY権限が付与されている場合も規定されます。

- Oracle Virtual Private Databaseが使用するSYS_CONTEXT値は、フェイルオーバーのためのセカンダリ・データベースには伝播されません。

EXPDPユーティリティaccess_methodパラメータを使用したデータのエクスポート

access_methodパラメータがdirect_pathに設定されたOracle Data Pump Export (EXPDP)ユーティリティを使用してデータをスキーマからエクスポートしようとするとき、このスキーマに仮想プライベート・データベース・ポリシーが定義されているオブジェクトが含まれていると、次のエラー・メッセージが表示される場合があり、エクスポート操作は失敗します。

ORA-31696: unable to export/import TABLE_DATA:"schema.table" using client specified DIRECT_PATH method

この問題は、スキーマ・レベルのエクスポートを、EXP_FULL_DATABASEロールを付与されていないユーザーとして実行する場合にのみ発生します。EXP_FULL_DATABASEロールを必要とするフル・データベース・エクスポート時には発生しません。EXP_FULL_DATABASEロールにはEXEMPT ACCESS POLICYシステム権限が含まれており、これにより仮想プライベート・データベース・ポリシーが無視されます。

潜在的な問題を見つけるには、EXPDP起動を再度試してください。ただし、access_methodパラメータをdirect_pathには設定しないでください。かわりに、automaticとexternal_tableのどちらかを使用してください。潜在的な問題とは、たとえば次のような権限の問題です。

ORA-39181: Only partial table data may be exported due to fine grain access control on "schema_name"."object_name"

関連項目:
データ・ポンプ・エクスポートの使用に関する詳細は、『Oracle Databaseユーティリティ』を参照してください。

ユーザー・モデルとOracle Virtual Private Database

Oracle Virtual Private Databaseは、次のタイプのユーザー・モデルで使用できます。

- アプリケーション・ユーザーがデータベース・ユーザーでもある場合。Oracle Databaseでは、ユーザーがデータベース・ユーザーか、データベースに認識されないアプリケーション・ユーザーかに関係なく、アプリケーションはユーザーごとにファイングレイン・アクセス・コントロールを規定できます。アプリケーション・ユーザーがデータベース・ユーザーでもある場合、Oracle Virtual Private Databaseは次のように規定されます。ユーザーがデータベースに接続すると、アプリケーションは各セッションに対するアプリケーション・コンテキストを設定します (様々な種類のユーザー・セッション・データを取得するための多くのパラメータを提供する、デフォルトのUSERENVアプリケーション・コンテキスト・ネームスペースを使用できます)。各セッションは異なるユーザー名で開始されるため、各ユーザーに対して異なるファイングレイン・アクセス・コントロール条件を規定できます。

- OCIまたはJDBC/OCIを使用したプロキシ認証。プロキシ認証により、ユーザーごとに異なるファイングレイン・アクセス・コントロールが可能になります。これは、各セッション(OCIまたはJDBC/OCI)がそれぞれのアプリケーション・コンテキストを持つ個別のデータベース・セッションであるためです。

- エンタープライズ・ユーザー・セキュリティと統合されたプロキシ認証。エンタープライズ・ユーザー・セキュリティを使用してプロキシ認証を統合した場合、Oracle Internet Directoryからユーザー・ロールおよび他の属性を取得してOracle Virtual Private Databaseポリシーを規定できます。(さらに、グローバルに初期化されたアプリケーション・コンテキストもこのディレクトリから取得できます。)

- ユーザーがOne Big Application Userとして接続する場合。すべてのユーザーのかわりにシングル・ユーザーとしてデータベースに接続するアプリケーションでは、ユーザーごとのファイングレイン・アクセス・コントロールを規定できます。この1セッションのユーザーは、「One Big Application User」と呼ばれます。ただし、アプリケーション開発者は、そのセッションのコンテキスト内で、個別のアプリケーション・ユーザー(たとえば、REALUSER)を表すグローバル・アプリケーション・コンテキスト属性を作成できます。すべてのデータベース・セッションおよびすべての監査レコードはOne Big Application Userに対して作成されますが、各セッションはエンド・ユーザーに応じて異なる属性を保持できます。このモデルは、ユーザーの数が限定されていて、セッションが再利用されないアプリケーションに最適です。このモデルの場合、各セッションは同一のデータベース・ユーザーとして作成されるため、ロールやデータベース監査の範囲が限定されます。グローバル・アプリケーション・コンテキストの詳細は、「グローバル・アプリケーション・コンテキストの使用」を参照してください。

- Webベースのアプリケーション。Webベースのアプリケーションには、通常は何百人ものユーザーがいます。多数のユーザー要求に対するデータの取得をサポートするためにデータベースへの接続が持続的に行われる場合でも、このような接続は特定のWebベース・ユーザーに固有のものではありません。通常、Webベースのアプリケーションはスケーラビリティを提供するために、ユーザーごとに異なるセッションを保持するのではなく、接続を設定して再利用します。たとえば、WebユーザーJaneおよびAjitが中間層アプリケーションに接続すると、このアプリケーションは、2人のユーザーのかわりに、使用するデータベース・セッションを1つ確立します。通常、JaneもAjitもデータベースには認識されません。アプリケーションが接続するユーザー名を切り替えるため、どの時点でも、セッションを使用しているのはJaneまたはAjitのいずれかです。
Oracle Virtual Private Databaseを使用すると、複数のグローバル・アプリケーション・コンテキストにアクセスする複数の接続が可能になり、接続プーリングが促進されます。この機能によって、個別ユーザー・セッションごとに別々のアプリケーション・コンテキストを確立する必要がなくなります。

表7-3に、Oracle Virtual Private Databaseをユーザー・モデルに適用する方法の要約を示します。

表7-3 様々なユーザー・モデルでのOracle Virtual Private Database

ユーザー・モデル

個別のデータベース接続

ユーザーごとの個別アプリケーション・コンテキスト

単一データベース接続

アプリケーションによるユーザー名の切替え

アプリケーション・ユーザーがデータベース・ユーザーでもある場合

あり

あり

なし

なし

OCIまたはJDBC/OCIを使用したプロキシ認証

あり

あり

なし

なし

エンタープライズ・ユーザー・セキュリティ脚注 1 と統合されたプロキシ認証

なし

なし

あり

あり

One Big Application User

なし

なし脚注 2

なし

あり^2

Webベースのアプリケーション

なし

なし

あり

あり

脚注1 ユーザー・ロールとその他の属性(グローバルに初期化されたアプリケーション・コンテキストも含む)は、Oracle Internet Directoryから取得してOracle Virtual Private Databaseを規定できます。

脚注2 アプリケーション開発者は、個別アプリケーション・ユーザー(たとえば、REALUSER)を表すグローバル・アプリケーション・コンテキスト属性を作成できます。その後、この属性を使用して、各セッション属性を制御したり、監査することができます。

Oracle Virtual Private Databaseポリシーに関する情報の検索

表7-4に、Oracle Virtual Private Databaseポリシーに関する情報の検索に使用できるデータ・ディクショナリ・ビューをリストします。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表7-4 VPDポリシーに関する情報を表示するデータ・ディクショナリ・ビュー

ビュー

説明

ALL_POLICIES

現行ユーザーがアクセス可能なオブジェクトに対するすべてのOracle Virtual Private Databaseセキュリティ・ポリシーが表示されます。

ALL_POLICY_CONTEXTS

現行ユーザーがアクセス可能なシノニム、表およびビューに定義されている駆動コンテキストが表示されます。駆動コンテキストは、Oracle Virtual Private Databaseポリシーで使用されるアプリケーション・コンテキストです。

ALL_POLICY_GROUPS

現行ユーザーがアクセス可能なシノニム、表およびビューに定義されているOracle Virtual Private Databaseポリシー・グループが表示されます。

ALL_SEC_RELEVANT_COLS

現行ユーザーがアクセス可能な表とビューに対するセキュリティ・ポリシーのセキュリティ関連列が表示されます。

DBA_POLICIES

データベース内のすべてのOracle Virtual Private Databaseセキュリティ・ポリシーが表示されます。

DBA_POLICY_GROUPS

データベース内のすべてのポリシー・グループが表示されます。

DBA_POLICY_CONTEXTS

データベース内のすべての駆動コンテキストが表示されます。このビューの列は、ALL_POLICY_CONTEXTSの各列と同じです。

DBA_SEC_RELEVANT_COLS

データベース内のすべてのセキュリティ・ポリシーのセキュリティ関連列が表示されます。

USER_POLICIES

現行ユーザーが所有するオブジェクトに対応付けられたすべてのOracle Virtual Private Databaseセキュリティ・ポリシーが表示されます。このビューにはOBJECT_OWNER列が表示されません。

USER_POLICY_CONTEXTS

現行ユーザーが所有するシノニム、表およびビューに定義されている駆動コンテキストが表示されます。このビューの列は、OBJECT_OWNER列以外はALL_POLICY_CONTEXTSの各列と同じです。

USER_SEC_RELEVANT_COLS

現行ユーザーが所有している表とビューに対するセキュリティ・ポリシーのセキュリティ関連列が表示されます。このビューの列は、OBJECT_OWNER列以外はALL_SEC_RELEVANT_COLSの各列と同じです。

USER_POLICY_GROUPS

現行ユーザーが所有するシノニム、表およびビューに定義されているポリシー・グループが表示されます。このビューにはOBJECT_OWNER列が表示されません。

V$VPD_POLICY

現在、ライブラリ・キャッシュにキャッシュされているカーソルに対応付けられた、すべてのファイングレイン・セキュリティ・ポリシーと述語が表示されます。このビューは、SQL文に適用されたポリシーを検索するのに便利です。

ヒント:
仮想プライベート・データベース・ポリシーを使用するアプリケーションでエラーが見つかった場合は、これらのビューに加え、データベース・トレース・ファイルも確認してください。トレース・ファイルの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。USER_DUMP_DEST初期化パラメータは、トレース・ファイルの現在の位置を示します。このパラメータの値は、SQL*PlusでSHOW PARAMETER USER_DUMP_DESTを発行して確認できます。

8 データの暗号化APIを使用したアプリケーションの開発

この章の内容は、次のとおりです。

- 暗号化で解決しないセキュリティの問題

- データ暗号化の課題

- DBMS_CRYPTOパッケージを使用した格納データの暗号化

- データの暗号化APIの使用例

- 暗号化データに関する情報の検索

関連項目:

- ネットワーク暗号化の概要は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

- 透過的データ暗号化および表領域暗号化の使用方法は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

暗号化で解決しないセキュリティの問題

データの暗号化には多くのメリットがありますが、多くのデメリットもあります。暗号化はすべてのセキュリティ問題を解決するわけではなく、不都合な問題の原因となる場合もあります。次の各項では、格納データの暗号化に関する誤解のいくつかについて説明します。

- 原則1: 暗号化はアクセス制御の問題を解決しない

- 原則2: 暗号化は不正なデータベース管理者からデータを保護しない

- 原則3: すべてのデータを暗号化してもデータは保護されない

原則1: 暗号化はアクセス制御の問題を解決しない

ほとんどの組織で、データのアクセスを、そのデータを参照する必要があるユーザーのみに制限する必要があります。たとえば、人事管理システムでは、従業員には各自の雇用レコードのみを参照できるように制限し、従業員の上司には直属の部下の雇用レコードを参照できるようにする場合があります。人事部門の担当者が複数の従業員の従業員レコードを参照する必要がある場合もあります。

一般的には、アクセス制御メカニズムを使用して、データを見る必要がある人にデータ・アクセスを制限するセキュリティ・ポリシーに対処できます。Oracle Databaseは、強力で独自に評価されたアクセス制御メカニズムを何年もの間提供してきました。仮想プライベート・データベースにより、アクセス制御を詳細なレベルまで規定できます。

人事部門のレコードは機密情報とみなされるため、セキュリティをより強化するためにこの情報はすべて暗号化する必要があると考えがちです。しかし、暗号化によってきめ細かいアクセス制御を規定できなくなるため、データ・アクセスの妨げとなる場合があります。たとえば、従業員、その上司および人事部門の担当者すべてが、従業員レコードにアクセスする必要がある場合があります。従業員データがすべて暗号化されている場合、この3人は暗号化されていない形式のデータにアクセスできる必要があります。したがって、従業員、上司および人事部門の担当者はデータを復号化するために同じ暗号化鍵を共有する必要があります。このように、アクセス制御の向上という観点では、暗号化によってセキュリティが強化されず、アプリケーションの正しい機能や効率的な機能の妨げとなる場合があります。さらに、システムの複数のユーザー間で暗号化鍵の送信および共有を安全に行うことは難しいという別の問題もあります。

格納データを暗号化するときの基本原則は、暗号化によってアクセス制御が妨げられないようにすることです。たとえば、empに対するSELECT権限を持つユーザーが、基本的には参照できるすべてのデータへの参照を暗号化メカニズムによって制限されないようにする必要があります。また、ユーザーが表のすべての暗号化データを参照する必要がある場合は、ある鍵を使用して表の一部を暗号化し、別の鍵を使用して表の他の部分を暗号化するメリットはほとんどありません。この場合、ユーザーがデータを参照できるように、データを復号化するオーバーヘッドが増加するのみです。アクセス制御が適切に実装されている場合は、暗号化によってデータベース自体の中でセキュリティが強化されることはほとんどありません。データベース内のデータにアクセスする権限を持つユーザーについては、暗号化しても権限は変わりません。したがって、アクセス制御の問題解決に暗号化を使用しないでください。

原則2: 暗号化は不正なデータベース管理者からデータを保護しない

不正なユーザーがパスワードを推測して上位(データベース管理者)の権限を取得する可能性を懸念して、この脅威から保護するために格納データを暗号化することを考える組織もあります。ただし、この問題の正しい解決策は、データベース管理者アカウントを保護し、その他の権限付きアカウントのデフォルトのパスワードを変更することです。データベースに侵入する最も簡単な方法は、管理者が変更しないままにしている権限付きアカウントのデフォルトのパスワードを使用することです。その一例がSYS/CHANGE_ON_INSTALLです。

不正なユーザーがDBA権限を取得すると、データベースに対して多くの破壊的な行為を実行できますが、暗号化ではそれらの行為の多くからデータベースを保護できません。たとえば、データを破壊または削除する行為、ユーザー・データをファイル・システムにエクスポートし、そのデータを電子メールで自分自身に戻してパスワード・クラッカを実行するなどの行為があります。

データベース管理者は通常すべての権限を所有しているため、データベース管理者がデータベース内のすべてのデータを参照できることについて懸念を持つ組織もあります。そのような組織では、データベース管理者はデータベースを管理するのみで、そのデータベースに含まれるデータを参照できないようにする必要があると考えます。また、1人のユーザーに非常に多くの権限が集中することを懸念し、DBA機能を分割するか、または2人でアクセスするルールを規定する方が望ましいと考える組織もあります。

すべてのデータ(または大量のデータ)を暗号化すると、前述の問題が解決すると考えがちですが、このような不正行為からデータを保護するためのより優れた方法があります。たとえば、Oracle DatabaseではDBA権限の制限付きの分割がサポートされています。Oracle Databaseでは、SYSDBAユーザーとSYSOPERユーザーに対するネイティブなサポートが提供されています。SYSDBAはすべての権限を所有しますが、SYSOPERは制限付き権限セット(データベースの起動および停止など)を所有します。

さらに、複数のシステム権限を網羅する、より小さなロールを作成することもできます。たとえば、jr_dbaロールには、すべてのシステム権限を含めるのではなく、準データベース管理者に適切なロールのみ(CREATE TABLE、CREATE USERなど)を含めます。

Oracle Databaseは、SYS(またはSYS権限を持つユーザー)によって実行されたアクションを監査し、オペレーティング・システムの保護位置にその監査証跡を格納できます。このモデルを使用すると、オペレーティング・システムに対してルート権限を持つ別の監査人が、SYSによって実行されたすべてのアクションを監査できるため、監査人は、すべてのデータベース管理者が実行したアクションに対する責任をデータベース管理者自身に持たせることができます。

データベース管理者を監査する方法の詳細は、「SYS管理ユーザーの監査」を参照してください。

データベース管理者のアクセス権と制御権をOracle Database Vaultを使用して調整することもできます。詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

データベース管理者は信頼される立場にいます。諜報機関のような最も機密性の高いデータを扱う組織においても、通常、データベース管理者機能は分割されません。かわりに、データベース管理者には信頼性が必要なため、厳しく管理されます。定期的な監査によって不適切なアクティビティを明らかにできます。

格納データの暗号化が、データベースの管理を妨げないことが重要です。そうでない場合は、より大きいセキュリティ問題になる可能性があります。たとえば、データを暗号化することでそのデータが破損した場合セキュリティ問題となり、データ自体を解釈できず、修復不可能になる可能性があります。

暗号化を使用すると、データベース管理者(または権限を持つその他のユーザー)がデータベース内のデータを参照する機能を制限できます。ただし、これは、データベース管理者の権限を適切に管理すること、または強力なシステム権限の使用を制御することの代用にはなりません。信頼できないユーザーが重要な権限を持っている場合、そのユーザーが組織に多くの脅威をもたらすこととなり、暗号化されていないクレジット・カード番号を参照されるよりもはるかに深刻な状況に陥る場合もあります。

原則3: すべてのデータを暗号化してもデータは保護されない

通常、データの暗号化によってセキュリティが強化されるのであれば、すべてのデータを暗号化することにより、データはすべて保護されると考えますが、これは誤りです。

前述の2つの原則で説明したとおり、暗号化ではアクセス制御の問題に適切に対処できないため、暗号化によって通常のアクセス制御を妨げないことが重要になります。さらに、本番データベース全体を暗号化すると、読取り、更新または削除を行うために、すべてのデータを復号化する必要があります。暗号化は、本来、パフォーマンス集中型の操作であるため、すべてのデータを暗号化するとパフォーマンスに大きい影響を与えます。

可用性はセキュリティの重要な側面です。データの暗号化によって、データを使用できなくなったり、パフォーマンスが低下して可用性に悪影響を与えた場合は、すべてのデータを暗号化することで新たなセキュリティ問題が発生することになります。セキュリティの適切な手続きとして、暗号化鍵を定期的に変更する必要がありますが、このときデータベースにアクセスできなくなります。これも可用性に悪影響を与えます。鍵を変更する場合は、データを復号化して新しい鍵で再度暗号化するまでの間、データベースにアクセスできなくなります。

格納データをオフラインで暗号化することは、メリットもあります。たとえば、組織が半年から1年単位で遠隔地にオフラインでバックアップを格納する場合があります。もちろん、保護の第1段階は、物理的なアクセス制御を確立することによって、データを格納する施設を保護することです。さらに、このデータを格納する前に暗号化すると、メリットがあります。このデータはオンラインでアクセスされないため、パフォーマンスについて考慮する必要はありません。Oracleデータベースにはこの機能が備わっていませんが、暗号化サービスを提供するベンダーがあります。この方法を検討する組織は、バックアップ・データの大規模な暗号化を実施する前に、プロセスを徹底的にテストする必要があります。オフラインで格納する前に、暗号化されたデータを正常に復号化でき、正しく再インポートできることを確認する必要があります。

データ暗号化の課題

暗号化によってセキュリティが強化される場合、次の各項で説明するように、いくつかの技術的な課題が伴います。

- 索引付けされたデータの暗号化

- 暗号化鍵の生成

- 暗号化鍵の転送

- 暗号化鍵の格納

- 暗号化鍵の変更

- バイナリ・ラージ・オブジェクトの暗号化

索引付けされたデータの暗号化

暗号化データが索引付けされている場合は、特別な問題が発生します。たとえば、ある会社が国民識別番号(米国社会保障番号(SSN)など)を各従業員の従業員番号として使用しているとします。会社は従業員番号を機密性の高いデータと考えているため、employees表のemployee_number列のデータを暗号化します。employee_number列には一意の値が含まれているため、データベース設計者は、パフォーマンスを向上するためにそのデータを索引付けします。

ただし、DBMS_CRYPTOまたはDBMS_OBFUSCATION_TOOLKIT(または別のメカニズム)を使用して列のデータを暗号化した場合、その列の索引にも暗号化された値が含まれます。列の索引に暗号化された値が含まれている場合、この索引は等価性チェック(たとえば、SELECT * FROM emp WHERE employee_number = '987654321')には使用できますが、それ以外の目的には事実上使用できません。索引付けされたデータを暗号化しないでください。

国民識別番号は一意のIDとして使用しないことをお薦めします。かわりに、CREATE SEQUENCE文を使用して、一意の識別番号を生成してください。国民識別番号を使用しない理由は、次のとおりです。

- 国民識別番号の乱用に関連するプライバシの問題があること(識別情報の盗難など)

- 国民識別番号に一部の重複があること(例: 米国社会保障番号)

暗号化鍵の生成

暗号化されたデータの安全性は、データの暗号化に使用される鍵の安全性に依存します。暗号化鍵は、安全な暗号化鍵生成方法を使用して安全に生成する必要があります。Oracle Databaseは、DBMS_CRYPTOのRANDOMBYTESファンクションを使用した完全な乱数の生成を提供しています。(このファンクションは、以前のDBMS_OBFUSCATION_TOOLKITのGetKeyプロシージャによって提供されていた機能にかわるものです。)DBMS_CRYPTOは、以前にRSA Securityによって認証された安全な乱数ジェネレータ(RNG)をコールします。

注意:
DBMS_RANDOMパッケージは使用しないでください。DBMS_RANDOMパッケージは擬似乱数を生成します。「セキュリティのための乱雑性についての推奨事項(RFC-1750)」には、擬似乱数プロセスを使用して機密の数値を生成すると、真のセキュリティを維持できなくなると述べられています。

鍵の値を暗号化する場合は、必ず正しいバイト数を指定してください。たとえば、ENCRYPT_AES128暗号化アルゴリズムの場合は、16バイトの鍵を指定する必要があります。

暗号化鍵の転送

暗号化鍵がアプリケーションによってデータベースに渡される場合は、暗号化鍵を暗号化する必要があります。暗号化しないと、鍵の転送時に、侵入者が鍵にアクセスできる可能性があります。Oracle Advanced Securityで提供されるようなネットワーク暗号化では、暗号化鍵を含む送信中のデータはすべて、改ざんまたは傍受から保護されます。

暗号化鍵の格納

暗号化鍵の格納は、暗号化で最も重要で難しい問題の1つです。対称鍵で暗号化されたデータを復元するには、データを復号化しようとする承認済のアプリケーションまたはユーザーが鍵にアクセスできる必要があります。同時に、アクセス権のない暗号化データに不正アクセスしようとするユーザーは、鍵にアクセスできないようにする必要があります。

開発者には次の選択肢があります。

- データベースへの暗号化鍵の格納

- オペレーティング・システムへの暗号化鍵の格納

- ユーザー自身による暗号化鍵の管理

- 透過的データベース暗号化および表領域暗号化の使用

データベースへの暗号化鍵の格納

データベース管理者のアクセスから暗号化データを保護しようとする場合、データベースに鍵を格納すると、常に完全なセキュリティを得られない可能性があります。すべての権限を持つデータベース管理者は暗号化鍵を含む表にもアクセスできます。ただし、明確な意図のない詮索好きなユーザーまたはオペレーティング・システム上のデータベース・ファイルを破壊しようとするユーザーに対しては、適切なセキュリティ対策になる可能性があります。

簡単な例として、従業員データを含む表(EMP)を作成するとします。列の1つに格納されている各従業員の社会保障番号(SSN)を暗号化します。従業員のSSNは、別の列に格納されている鍵を使用して暗号化できます。ただし、表全体に対するSELECT権限を持っているユーザーは、暗号化鍵を取得し、対応するSSNを復号化できます。

この暗号化スキーマは簡単に侵害できるようにみえますが、多少の取り組みで、非常に強力な不正侵入対策ソリューションを作成できます。たとえば、この方法を使用してSSNを暗号化する前に、employee_numberのデータをさらに変換するテクニックを使用することで、SSNを暗号化できます。これは、employee_numberと従業員の誕生日のXOR(排他的論理和)演算を使用して値の妥当性を判別するような単純なテクニックの場合もあります。

別の保護として、暗号化を実行するPL/SQLパッケージの本体を(WRAPユーティリティを使用して)ラップして、コードを不明瞭化(スクランブル化)する方法もあります。WRAPユーティリティは入力SQLファイルを処理し、その中のPL/SQLユニットを不明瞭化します。たとえば、次のコマンドではkeymanage.sqlファイルを入力として使用しています。

wrap iname=/mydir/keymanage.sql

開発者は次に、ラップされたパッケージに含まれる鍵を使用して、パッケージ内のファンクションにDBMS_OBFUSCATION_TOOLKITをコールさせることができます。

Oracle Databaseでは、動的に生成されたPL/SQLコードを不明瞭化できます。DBMS_DDLパッケージには、動的に生成されたPL/SQLプログラム・ユニットを不明瞭化するために使用できるサブプログラムが2つ含まれています。たとえば、次のブロックでは、DBMS_DDL.CREATE_WRAPPEDプロシージャを使用して、動的に生成されたPL/SQLコードをラップします。

BEGIN
......
SYS.DBMS_DDL.CREATE_WRAPPED(function_returning_PLSQL_code());
......
END;

ラップは解読不可能ではありませんが、侵入者が暗号化鍵にアクセスするのはかなり困難になります。各暗号化データの値ごとに異なる鍵が提供されている場合でも、鍵の値をパッケージ内に埋め込まないでください。かわりに、鍵の管理を実行するパッケージをラップ(つまり、データ変換またはパディング)してください。

関連項目:
WRAPコマンドライン・ユーティリティと動的ラップのためのDBMS_DDLサブプログラムの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

また、データをラップするかわりに暗号化鍵を別の表に格納し、プロシージャを使用してキー表に対するコールをエンベロープする方法もあります。キー表は、主キーと外部キー関係を使用してデータ表に結合できます。たとえば、employee_numberは、従業員情報と暗号化されたSSNを格納するemployees表の主キーです。また、employee_number列は、従業員のSSNの暗号化鍵を格納するssn_keys表に対する外部キーです。ssn_keys表に格納された鍵も使用前に(XOR演算により)変換できるため、鍵自体が暗号化されずに格納されることはありません。プロシージャをラップすると、鍵を使用前に変換する方法を隠すことができます。

この方法のメリットは次のとおりです。

- 表への直接アクセス権を持つユーザーは、暗号化されていない機密データを参照することも、鍵を取得してデータを復号化することもできません。

- 復号化されたデータへのアクセスは、暗号化されたデータの選択、キー表からの復号化鍵の取得、およびデータの復号化に使用する鍵の変換を実行するプロシージャを介して制御できます。

- データ変換アルゴリズムは、プロシージャをラップし、プロシージャ・コードを不明瞭化することによって、偶発的な傍受から隠されます。

- データ表とキー表の両方に対するSELECT権限があっても、鍵は使用前に変換されるため、この権限を持つユーザーがそのデータを復号化できる保証はありません。

この方法のデメリットは、キー表とデータ表の両方に対するSELECT権限があり、鍵変換アルゴリズムを導出できるユーザーが、暗号化スキームを解読できることです。

前述の方法は完全ではありませんが、クリアテキストで格納されている機密情報を簡単に取得できないように保護するには十分です。

オペレーティング・システムへの暗号化鍵の格納

もう1つの選択肢は、オペレーティング・システムのフラット・ファイルに鍵を格納する方法です。Oracle Databaseでは、PL/SQLからコールアウトを行い、それを使用して暗号化鍵を取得できます。ただし、オペレーティング・システムに鍵を格納し、それに対してコールアウトを行う場合、データはオペレーティング・システムでの保護と同じ程度にのみ保護されます。セキュリティ上の主な懸念が、オペレーティング・システムからデータベースに侵入される可能性があるということである場合、オペレーティング・システムに鍵を格納することは、データベース自体に鍵を格納することより、侵入者にとっては暗号化されたデータを取得しやすくなります。

ユーザー自身による暗号化鍵の管理

ユーザーに鍵を提供させる場合は、ユーザー自身がその鍵に責任を持つことを想定しています。ヘルプ・デスクへのコールの40%が、パスワードを忘れたユーザーからのコールであることから、ユーザーが暗号化鍵を管理することのリスクは明らかです。多くの場合、ユーザーは暗号化鍵を忘れるか、鍵を書き留めておくため、セキュリティ上の弱点が生じます。ユーザーが暗号化鍵を忘れたり、会社を退職した場合、データは復元できなくなります。

ユーザーに鍵を提供する、またはユーザーが鍵を管理する場合は、ネットワーク暗号化を使用して、鍵がクリアテキストでクライアントからサーバーに渡されないようにする必要があります。また、鍵アーカイブ・メカニズムを開発する必要があります。これも困難なセキュリティの問題です。鍵アーカイブおよびバックドアは、暗号化によって解決しようとしているセキュリティ上の弱点を生み出すことになります。

透過的データベース暗号化および表領域暗号化の使用

透過的データベース暗号化および表領域暗号化は、暗号化された表および表領域に対する鍵を自動的に管理して、安全な暗号化を提供します。アプリケーションで、メディアに格納されている機密性の高い列データの保護を必要とする場合は、これらの2種類の暗号化を使用することで、これを簡単にすばやく行えます。

関連項目:
透過的データ暗号化の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

暗号化鍵の変更

慎重なセキュリティの手続きでは、暗号化鍵を定期的に変更するように指示されます。格納データの場合、これを実行するには、データを定期的に暗号解除し、適切な別の鍵を使用して再度暗号化する必要があります。暗号化鍵の変更は、おそらくデータへのアクセスがない間に実行しますが、また別の課題が生まれます。クレジット・カード番号を暗号化するWebベースのアプリケーションでは、暗号化鍵を切り替える間はアプリケーション全体を停止できないため、特に問題になります。

バイナリ・ラージ・オブジェクトの暗号化

一部のデータ型は、暗号化に手間がかかります。たとえば、Oracle Databaseでは、非常に大規模なオブジェクト(たとえば、数GB)をデータベースに格納するバイナリ・ラージ・オブジェクト(BLOB)をサポートしています。BLOBは、列として内部的に格納するか、または外部ファイルに格納できます。

BLOBデータに対するDBMS_CRYPTOの使用例は、「BLOBデータの暗号化および復号化プロシージャの例」を参照してください。

DBMS_CRYPTOパッケージを使用した格納データの暗号化

DBMS_CRYPTOパッケージは、論じられてきたセキュリティ問題に取り組むための様々な方法を提供します。(下位互換性を維持するために、DBMS_OBFUSCATION_TOOLKITも提供されています。)

暗号化は、複数のセキュリティへの脅威に対処できる理想的なソリューションではありませんが、データベースに格納する前に機密性の高いデータを選択的に暗号化することによって、セキュリティを強化できます。そのようなデータの例は次のとおりです。

- クレジット・カード番号

- 国民識別番号

Oracle Databaseには、格納データの暗号化および復号化のためのPL/SQLパッケージDBMS_CRYPTOが用意されています。このパッケージは、Advanced Encryption Standard(AES)の暗号化アルゴリズムも含めて、複数の業界標準暗号化およびハッシング・アルゴリズムをサポートしています。AESは、データ暗号化規格(DES)にかわる規格として、National Institute of Standards and Technology(NIST)によって承認されました。

DBMS_CRYPTOパッケージは、RAWおよびイメージやサウンドなどのラージ・オブジェクト(LOB)を含むOracle Databaseの一般的なデータ型の暗号化および復号化に使用できます。特に、BLOBとCLOBをサポートしています。さらに、様々なデータベース・キャラクタ・セット間でデータを暗号化するためのグローバリゼーション・サポートも提供します。

次の暗号化アルゴリズムがサポートされています。

- データ暗号化規格(DES)、Triple-DES(3DES、2-key)

- Advanced Encryption Standard(AES)

- SHA-1暗号化ハッシュ

- SHA-1メッセージ認証コード(MAC)

DBMS_CRYPTOではブロック暗号修飾子も提供されています。Public Key Cryptographic Standard(PKCS)#5を含む複数のパディング・オプションおよびCipher Block Chaining(CBC)を含む4つのブロック暗号連鎖モードから選択できます。パディングは8バイトの倍数で実行する必要があります。

注意:

- DESはNational Institute of Standards and Technology(NIST)の推奨対象ではなくなりました。

- SHA-1を使用する方がMD5より安全性が高くなります。

- 鍵付きMD5は、無防備ではありません。

表8-1に、DBMS_CRYPTOパッケージともう1つのPL/SQL暗号化パッケージDBMS_OBFUSCATION_TOOLKITとの機能の比較を示します。

表8-1 DBMS_CRYPTOとDBMS_OBFUSCATION_TOOLKITとの機能の比較

パッケージ機能

DBMS_CRYPTO

DBMS_OBFUSCATION_TOOLKIT

暗号化アルゴリズム

DES、3DES、AES、RC4、3DES_2KEY

DES、3DES

パディング形式

PKCS5、複数ゼロ

サポートなし

ブロック暗号連鎖モード

CBC、CFB、ECB、OFB

CBC

暗号化ハッシュ・アルゴリズム

SHA-1、MD4、MD5

MD5

鍵ハッシュ(MAC)・アルゴリズム

HMAC_MD5、HMAC_SH1

サポートなし

暗号化擬似乱数ジェネレータ

RAW、NUMBER、BINARY_INTEGER

RAW、VARCHAR2

データベース型

RAW、CLOB、BLOB

RAW、VARCHAR2

DBMS_CRYPTOは、使いやすく、新しいシステムと既存システムの両方に対応する広範囲のアルゴリズムをサポートしているため、OBFUSCATION_TOOLKITパッケージと置き換えてください。3DES_2KEYおよびMD4は下位互換性を維持するために提供されていますが、3DES、AESまたはSHA-1を使用するとセキュリティをより強化できます。3DES_2KEYおよびMD4の使用はお薦めしません。

DBMS_CRYPTOパッケージには、比較の際に便利な暗号チェックサム機能(MD5)と、安全な乱数を生成する機能(RANDOMBYTES関数)が含まれています。安全な乱数生成は暗号化の重要な部分です。予測可能な鍵は簡単に推定される鍵であり、鍵を簡単に推定できることによってデータが簡単に復号化される可能性があります。ほとんどの暗号解読が、総当たり解析(可能性のあるすべての鍵を繰り返す)によってではなく、脆弱な鍵や適切に格納されていない鍵を見つけ出すことによって行われています。

注意:
DBMS_RANDOMは暗号化鍵の生成には不適切なため、使用しないでください。

鍵の管理はプログラムによって実行されます。つまり、アプリケーション(またはファンクションのコール側)が、暗号化鍵を提供する必要があります。これは、アプリケーション開発者が鍵を安全に格納し、取得する方法を検討する必要があることを意味します。様々な鍵管理方法の相対的なメリットとデメリットについては、後続の項で説明します。文字列とRAWデータの両方を処理できるDBMS_OBFUSCATION_TOOLKITパッケージには、64ビットの鍵を送信する必要があります。DESアルゴリズム自体の有効な鍵の長さは56ビットです。

注意:
DBMS_OBFUSCATION_TOOLKITは、デフォルトでPUBLICに付与されます。この権限付与を取り消すことをお薦めします。
DBMS_OBFUSCATION_TOOLKITパッケージにはVARCHAR2データ型またはRAWデータ型のいずれかを使用できますが、鍵および暗号化データにはRAWデータ型の使用をお薦めします。暗号化データをVARCHAR2として格納すると、グローバリゼーション・サポート・ルーチンを通過する場合に、問題が発生する可能性があります。たとえば、異なるキャラクタ・セットを使用するデータベース間の転送時に問題が発生します。

VARCHAR2データ型とRAWデータ型間で変換を行う場合は、UTL_RAWパッケージのCAST_TO_RAWファンクションおよびCAST_TO_VARCHAR2ファンクションを使用してください。

関連項目:

- DBMS_CRYPTOパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- OBFUSCATION_TOOLKITパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- UTL_RAWパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

データの暗号化APIの使用例

この項の内容は、次のとおりです。

- データ暗号化プロシージャの例

- AES 256ビット・データ暗号化および復号化プロシージャの例

- BLOBデータの暗号化および復号化プロシージャの例

データ暗号化プロシージャの例

次に、データを暗号化するためのPL/SQLプログラム(dbms_crypto.sql)のサンプルを示します。このサンプル・コードでは、次の処理を実行します。

- 文字列(VARCHAR2型)をRAWデータ型に変換した後、DESを使用して暗号化します。
DBMS_OBFUSCATION_TOOLKITパッケージのファンクションやパッケージとは異なり、DBMS_CRYPTOパッケージの暗号化および復号化ファンクションとプロシージャはRAWデータ型にのみ機能するため、このステップが必要となります。

- SHA-1アルゴリズムを使用した160ビット・ハッシュの作成方法を示します。

- MD5アルゴリズムを使用した鍵依存の一方向ハッシュであるMACの計算方法を示します。

dbms_crypto.sqlプロシージャは次のとおりです。

DECLARE
input_string     VARCHAR2(16) := 'tigertigertigert';
raw_input        RAW(128) :=
UTL_RAW.CAST_TO_RAW(CONVERT(input_string,'AL32UTF8','US7ASCII'));
key_string       VARCHAR2(8)  := 'scottsco';
raw_key          RAW(128) :=
UTL_RAW.CAST_TO_RAW(CONVERT(key_string,'AL32UTF8','US7ASCII'));
encrypted_raw    RAW(2048);
encrypted_string VARCHAR2(2048);
decrypted_raw    RAW(2048);
decrypted_string VARCHAR2(2048);
-- Begin testing Encryption:
BEGIN
dbms_output.put_line('> Input String                     : ' ||
CONVERT(UTL_RAW.CAST_TO_VARCHAR2(raw_input),'US7ASCII','AL32UTF8'));
dbms_output.put_line('> ========= BEGIN TEST Encrypt =========');
encrypted_raw := dbms_crypto.Encrypt(
src => raw_input,
typ => DBMS_CRYPTO.DES_CBC_PKCS5,
key => raw_key);
dbms_output.put_line('> Encrypted hex value              : ' ||
rawtohex(UTL_RAW.CAST_TO_RAW(encrypted_raw)));
decrypted_raw := dbms_crypto.Decrypt(
src => encrypted_raw,
typ => DBMS_CRYPTO.DES_CBC_PKCS5,
key => raw_key);
decrypted_string :=
CONVERT(UTL_RAW.CAST_TO_VARCHAR2(decrypted_raw),'US7ASCII','AL32UTF8');
dbms_output.put_line('> Decrypted string output          : ' ||
decrypted_string);
if input_string = decrypted_string THEN
dbms_output.put_line('> String DES Encyption and Decryption successful');
END if;
dbms_output.put_line('');
dbms_output.put_line('> ========= BEGIN TEST Hash =========');
encrypted_raw := dbms_crypto.Hash(
src => raw_input,
typ => DBMS_CRYPTO.HASH_SH1);
dbms_output.put_line('> Hash value of input string       : ' ||
rawtohex(UTL_RAW.CAST_TO_RAW(encrypted_raw)));
dbms_output.put_line('> ========= BEGIN TEST Mac =========');
encrypted_raw := dbms_crypto.Mac(
src => raw_input,
typ => DBMS_CRYPTO.HMAC_MD5,
key => raw_key);
dbms_output.put_line('> Message Authentication Code      : ' ||
rawtohex(UTL_RAW.CAST_TO_RAW(encrypted_raw)));
dbms_output.put_line('');
dbms_output.put_line('> End of DBMS_CRYPTO tests  ');
END;
/

AES 256ビット・データ暗号化および復号化プロシージャの例

次のPL/SQLブロックは、Cipher Block ChainingとPKCS #5パディングを使用するAES 256ビット・アルゴリズムを使用して、input_stringという事前定義の変数を暗号化および復号化する方法を示します。

declare
input_string       VARCHAR2 (200) := 'Secret Message';
output_string      VARCHAR2 (200);
encrypted_raw      RAW (2000);             -- stores encrypted binary text
decrypted_raw      RAW (2000);             -- stores decrypted binary text
num_key_bytes      NUMBER := 256/8;        -- key length 256 bits (32 bytes)
key_bytes_raw      RAW (32);               -- stores 256-bit encryption key
encryption_type    PLS_INTEGER :=          -- total encryption type
DBMS_CRYPTO.ENCRYPT_AES256
+ DBMS_CRYPTO.CHAIN_CBC
+ DBMS_CRYPTO.PAD_PKCS5;
begin
DBMS_OUTPUT.PUT_LINE ('Original string: ' || input_string);
key_bytes_raw := DBMS_CRYPTO.RANDOMBYTES (num_key_bytes);
encrypted_raw := DBMS_CRYPTO.ENCRYPT
(
src => UTL_I18N.STRING_TO_RAW (input_string, 'AL32UTF8'),
typ => encryption_type,
key => key_bytes_raw
);
-- The encrypted value in the encrypted_raw variable can be used here:
decrypted_raw := DBMS_CRYPTO.DECRYPT
(
src => encrypted_raw,
typ => encryption_type,
key => key_bytes_raw
);
output_string := UTL_I18N.RAW_TO_CHAR (decrypted_raw, 'AL32UTF8');
DBMS_OUTPUT.PUT_LINE ('Decrypted string: ' || output_string);
end;

BLOBデータの暗号化および復号化プロシージャの例

次に、BLOBデータを暗号化および復号化するためのPL/SQLプログラム(blob_test.sql)のサンプルを示します。このサンプル・コードは次の操作を実行し、ステップごとに進捗状況(または問題)を出力します。

- BLOB列の表を作成します。

- RAWの値をその表に挿入します。

- RAWデータを暗号化します。

- 暗号化されたデータを復号化します。

blob_test.sqlプロシージャは次のとおりです。

-- 1. Create a table for BLOB column:
create table table_lob (id number, loc blob);

-- 2. Insert 3 empty lobs for src/enc/dec:
insert into table_lob values (1, EMPTY_BLOB());
insert into table_lob values (2, EMPTY_BLOB());
insert into table_lob values (3, EMPTY_BLOB());

set echo on
set serveroutput on

declare
srcdata    RAW(1000);
srcblob    BLOB;
encrypblob BLOB;
encrypraw  RAW(1000);
encrawlen  BINARY_INTEGER;
decrypblob BLOB;
decrypraw  RAW(1000);
decrawlen  BINARY_INTEGER;

leng       INTEGER;

begin

-- RAW input data 16 bytes
srcdata := hextoraw('6D6D6D6D6D6D6D6D6D6D6D6D6D6D6D6D');

dbms_output.put_line('---');
dbms_output.put_line('input is ' || srcdata);
dbms_output.put_line('---');

-- select empty lob locators for src/enc/dec
select loc into srcblob from table_lob where id = 1;
select loc into encrypblob from table_lob where id = 2;
select loc into decrypblob from table_lob where id = 3;

dbms_output.put_line('Created Empty LOBS');
dbms_output.put_line('---');

leng := DBMS_LOB.GETLENGTH(srcblob);
IF leng IS NULL THEN
dbms_output.put_line('Source BLOB Len NULL ');
ELSE
dbms_output.put_line('Source BLOB Len ' || leng);
END IF;

leng := DBMS_LOB.GETLENGTH(encrypblob);
IF leng IS NULL THEN
dbms_output.put_line('Encrypt BLOB Len NULL ');
ELSE
dbms_output.put_line('Encrypt BLOB Len ' || leng);
END IF;

leng := DBMS_LOB.GETLENGTH(decrypblob);
IF leng IS NULL THEN
dbms_output.put_line('Decrypt  BLOB Len NULL ');
ELSE
dbms_output.put_line('Decrypt BLOB Len ' || leng);
END IF;

-- 3. Write source raw data into blob:
DBMS_LOB.OPEN (srcblob, DBMS_LOB.lob_readwrite);
DBMS_LOB.WRITEAPPEND (srcblob, 16, srcdata);
DBMS_LOB.CLOSE (srcblob);

dbms_output.put_line('Source raw data written to source blob');
dbms_output.put_line('---');

leng := DBMS_LOB.GETLENGTH(srcblob);
IF leng IS NULL THEN
dbms_output.put_line('source BLOB Len NULL ');
ELSE
dbms_output.put_line('Source BLOB Len ' || leng);
END IF;

/*
* Procedure Encrypt
* Arguments: srcblob -> Source BLOB
*            encrypblob -> Output BLOB for encrypted data
*            DBMS_CRYPTO.AES_CBC_PKCS5 -> Algo : AES
*                                         Chaining : CBC
*                                         Padding : PKCS5
*            256 bit key for AES passed as RAW
*                ->
hextoraw('000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F')
*            IV (Initialization Vector) for AES algo passed as RAW
*                -> hextoraw('00000000000000000000000000000000')
*/

DBMS_CRYPTO.Encrypt(encrypblob,
srcblob,
DBMS_CRYPTO.AES_CBC_PKCS5,
hextoraw ('000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F'),
hextoraw('00000000000000000000000000000000'));

dbms_output.put_line('Encryption Done');
dbms_output.put_line('---');

leng := DBMS_LOB.GETLENGTH(encrypblob);
IF leng IS NULL THEN
dbms_output.put_line('Encrypt BLOB Len NULL');
ELSE
dbms_output.put_line('Encrypt BLOB Len ' || leng);
END IF;

-- 4. Read encrypblob to a raw:
encrawlen := 999;

DBMS_LOB.OPEN (encrypblob, DBMS_LOB.lob_readwrite);
DBMS_LOB.READ (encrypblob, encrawlen, 1, encrypraw);
DBMS_LOB.CLOSE (encrypblob);

dbms_output.put_line('Read encrypt blob to a raw');
dbms_output.put_line('---');

dbms_output.put_line('Encrypted data is (256 bit key) ' || encrypraw);
dbms_output.put_line('---');

/*
* Procedure Decrypt
* Arguments: encrypblob -> Encrypted BLOB to decrypt
*            decrypblob -> Output BLOB for decrypted data in RAW
*            DBMS_CRYPTO.AES_CBC_PKCS5 -> Algo : AES
*                                         Chaining : CBC
*                                         Padding : PKCS5
*            256 bit key for AES passed as RAW (same as used during Encrypt)
*                ->
hextoraw('000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F')
*            IV (Initialization Vector) for AES algo passed as RAW (same as
used during Encrypt)
*                -> hextoraw('00000000000000000000000000000000')
*/

DBMS_CRYPTO.Decrypt(decrypblob,
encrypblob,
DBMS_CRYPTO.AES_CBC_PKCS5,
hextoraw
('000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F'),
hextoraw('00000000000000000000000000000000'));

leng := DBMS_LOB.GETLENGTH(decrypblob);
IF leng IS NULL THEN
dbms_output.put_line('Decrypt BLOB Len NULL');
ELSE
dbms_output.put_line('Decrypt BLOB Len ' || leng);
END IF;

-- Read decrypblob to a raw
decrawlen := 999;

DBMS_LOB.OPEN (decrypblob, DBMS_LOB.lob_readwrite);
DBMS_LOB.READ (decrypblob, decrawlen, 1, decrypraw);
DBMS_LOB.CLOSE (decrypblob);

dbms_output.put_line('Decrypted data is (256 bit key) ' || decrypraw);
dbms_output.put_line('---');

DBMS_LOB.OPEN (srcblob, DBMS_LOB.lob_readwrite);
DBMS_LOB.TRIM (srcblob, 0);
DBMS_LOB.CLOSE (srcblob);

DBMS_LOB.OPEN (encrypblob, DBMS_LOB.lob_readwrite);
DBMS_LOB.TRIM (encrypblob, 0);
DBMS_LOB.CLOSE (encrypblob);

DBMS_LOB.OPEN (decrypblob, DBMS_LOB.lob_readwrite);
DBMS_LOB.TRIM (decrypblob, 0);
DBMS_LOB.CLOSE (decrypblob);

end;
/

truncate table table_lob;
drop table table_lob;

暗号化データに関する情報の検索

表8-2に、暗号化データに関する情報にアクセスするために問合せ可能なデータ・ディクショナリ・ビューをリストします。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表8-2 暗号化データに関する情報を表示するデータ・ディクショナリ・ビュー

ビュー

説明

ALL_ENCRYPTED_COLUMNS

ユーザーがアクセスできるすべての表にあるすべての暗号化列の暗号化アルゴリズム情報が表示されます。

DBA_ENCRYPTED_COLUMNS

データベースにあるすべての暗号化列の暗号化アルゴリズム情報が表示されます。

USER_ENCRYPTED_COLUMNS

ユーザー・スキーマのすべての表にあるすべての暗号化列の暗号化アルゴリズム情報が表示されます。

V$ENCRYPTED_TABLESPACES

暗号化された表領域に関する情報が表示されます。

V$ENCRYPTION_WALLET

透過的データ暗号化のウォレットのステータスおよびウォレットの場所に関する情報が表示されます。

V$RMAN_ENCRYPTION_ALGORITHMS

サポートされている暗号化アルゴリズムが表示されます。

9 監査を使用したセキュリティ・アクセスの検証

この章の内容は、次のとおりです。

- 監査の概要

- 監査タイプの選択

- 標準監査を使用した一般的なアクティビティの監視

- セキュリティに関連するSQL文および権限に対するデフォルト監査の使用

- ファイングレイン監査を使用した特定のアクティビティの監査

- SYS管理ユーザーの監査

- トリガーを使用して監査データを個別の表に書き込む方法

- 監査証跡レコードの管理

- 監査証跡レコードの削除

- 監査アクティビティに関する情報の検索

関連項目:
システム監査の際に従う一般的なガイドラインは、「監査に関するガイドライン」を参照してください。

監査の概要

この項の内容は、次のとおりです。

- 監査とは

- 監査を使用する理由

- データベース監査証跡の保護

- 標準監査レコードおよびファイングレイン監査レコードに常に書き込まれるアクティビティ

- すべてのプラットフォームについて常に監査されるアクティビティ

- 分散データベースでの監査

- 監査のベスト・プラクティス

関連項目:
高度な監査機能を提供するOracle Audit Vault and Database Firewallの詳細は、『Oracle Audit Vault and Database Firewall管理者ガイド』を参照してください。

監査とは

監査とは、選択したユーザー・データベース・アクション(データベース・ユーザーおよび非データベース・ユーザーの両方からのアクション)を監視して記録する処理のことです脚注 1 。実行されたSQL文のタイプなどの個々のアクション、またはユーザー名、アプリケーション、時間などの様々なデータの組合せをベースとして使用できます。成功したアクティビティと失敗したアクティビティの両方を監査できます。監査を使用するには、監査を使用可能にした後、監査対象を構成します。監査対象のアクションは、データ・ディクショナリ表またはオペレーティング・システム・ファイルに記録されます。

監査を使用可能にして構成することをお薦めします。監査は、強固な内部制御を規定する有効な方法であるため、サイトでは米国サーベンス・オクスリー法(Sarbanes-Oxley Act)に定義されている法令順守要件を満たすことができます。監査を使用すると、ビジネス操作を監視でき、企業ポリシーから逸脱する可能性があるアクティビティを検出できます。この結果、データベースおよびアプリケーション・ソフトウェアへのアクセスが厳密に制御されるようになり、パッチが予定どおりに適用され、非定型の変更が防止されます。監査をデフォルトで使用可能にすることで、監査要員および特別監査要員に対する監査レコードを生成できます。選択的に監査を行い、ビジネス・コンプライアンスのニーズを満たしていることを確認してください。

監査を使用する理由

監査は、一般的に次のアクティビティを実行するために使用します。

- アクションに対するアカウンタビリティの有効化。特定のスキーマ、表または行に対して実行されるアクション、あるいは特定の内容に影響を与えるアクションなどがあります。

- それぞれのアカウンタビリティに基づいた、ユーザー(または侵入者などの他者)による不適切なアクションの防止。

- 疑わしいアクティビティの調査。たとえば、あるユーザーが表からデータを削除しようとした場合、セキュリティ管理者は、そのデータベースへのすべての接続と、そのデータベースにあるすべての表からの行の削除(削除が正常に実行されたかに関係なく)をすべて監査できます。

- 認可されていないユーザーのアクションを監査人に通知します。たとえば、認可されていないユーザーがデータを変更または削除を実行できるなど、予期した以上の権限を持っている場合に、ユーザー認可を再評価できます。

- 特定のデータベース・アクティビティに関するデータの監視と収集。たとえば、データベース管理者は、更新された表、実行された論理I/Oの回数、またはピーク時に接続していた同時実行ユーザーの数などに関する統計を収集できます。

- 認可またはアクセス制御の実装に関する問題の検出。たとえば、データは他の方法で保護されているため、監査レコードは生成されないと予測される監査ポリシーを作成できます。しかし、これらのポリシーで監査レコードが生成された場合は、他のセキュリティ制御が正しく実装されていないことがわかります。

- コンプライアンスのための監査要件への対処。次のような法規に、監査に関連する一般的な要件が含まれています。

- 米国サーベンス・オクスリー法

- 米国の医療保険の相互運用性と説明責任に関する法律(Health Insurance Portability and Accountability Act、HIPAA)

- 自己資本の測定と基準に関する国際的統一化: 改訂された枠組(バーゼルII)(International Convergence of Capital Measurement and Capital Standards: a Revised Framework、Basel II)

- 日本の個人情報保護法

- 欧州連合のプライバシと電子通信に関する指令(European Union Directive on Privacy and Electronic Communications)

データベース監査証跡の保護

疑わしいデータベース・アクティビティを監査する場合は、監査証跡のレコードの整合性を保護することによって、監査情報が正確かつ完全であることを保証する必要があります。

データベース監査証跡は、SYS.AUD$およびSYS.FGA_LOG$表に書き込まれます。SYS.AUD$およびSYS.FGA_LOG$表に対してオブジェクト監査オプションを設定した結果として生成された監査レコードを監査証跡から削除できるのは、管理者権限で接続しているユーザーのみです。管理者も不正な使用について監査されることに注意してください。詳細は、「SYS管理ユーザーの監査」を参照してください。

データベース監査証跡を保護するには、次の方法もあります。

- O7_DICTIONARY_ACCESSIBILITY初期化パラメータをFALSE(デフォルト)に設定します。これにより、SYS.AUD$およびSYS.FGA_LOG$表内の監査データに対してDMLアクションを実行できるのは、SYSDBA権限を持つユーザーのみとなります。デフォルトのインストールでは、O7_DICTIONARY_ACCESSIBILITYはFALSEに設定されています。

- Oracle Database Vaultをインストール済の場合は、SYSTEM.AUD$表を含むレルムを作成します。デフォルトでは、AUD$表はSYSTEMスキーマにあります。(シノニムSYS.AUD$は、SYSTEM.AUD$表を参照します。)Oracle Database Vaultのレルムの詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

関連項目:

- 「標準監査を使用した一般的なアクティビティの監視」

- 「ファイングレイン監査を使用した特定のアクティビティの監査」

標準監査レコードおよびファイングレイン監査レコードに常に書き込まれるアクティビティ

標準監査が使用可能になっている場合(つまり、AUDIT_TRAILをDBまたはDB,EXTENDEDに設定している場合)、SYS.AUD$およびSYS.FGA_LOG$表に対するINSERT、UPDATE、MERGEおよびDELETEなど、非SYSユーザーによるすべてのデータ操作言語(DML)操作が監査されます。(この監査は、AUD$表とFGA_LOGS$表の監査オプションを設定していない場合にも行われます。)通常、非SYSユーザーは、明示的にアクセス権が付与されている場合を除き、これらの表にアクセスできません。非SYSユーザーがSYS.FGA_LOG$およびSYS.AUD$表内のデータを改ざんすると、各アクションに関して監査レコードが書き込まれます。

AUDIT_SYS_OPERATIONS初期化パラメータをTRUEに設定した場合、Oracle DatabaseはSYS.FGA_LOG$表およびSYS.AUD$表に対するSYSユーザーのDELETE、INSERT、UPDATE、およびMERGE操作を監査します。この場合、すべてのSYS操作の監査レコードは、AUDIT_FILE_DEST初期化パラメータが指しているディレクトリに書き込まれます。AUDIT_FILE_DESTが設定されていない場合、レコードが書き込まれる場所はオペレーティング・システムによって異なります。

関連項目:

- 「標準監査を使用した一般的なアクティビティの監視」

- 「ファイングレイン監査を使用した特定のアクティビティの監査」

すべてのプラットフォームについて常に監査されるアクティビティ

Oracle Databaseは常に特定のデータベース関連操作を監査して、それらをオペレーティング・システムの監査ファイルに書き込みます。中には、SYSDBA権限やSYSOPER権限でログインしたユーザーのアクションが含まれます。これは、必須監査と呼ばれます。データベース監査証跡を有効にした場合(AUDIT_TRAILパラメータをDBに設定した場合)でも、Oracle Databaseは必須レコードをオペレーティング・システム・ファイルに書き込みます。

デフォルトでは、オペレーティング・システムはUNIXシステムとWindowsシステムのどちらの場合も$ORACLE_BASE/admin/$ORACLE_SID/adumpディレクトリの中にあります。Windowsシステムでは、Oracle Databaseがこの情報をWindowsイベントビューアにも書き込みます。このディレクトリの場所はAUDIT_FILE_DEST初期化パラメータを設定することで変更できます。これは「オペレーティング・システム監査証跡のディレクトリの指定」で説明しています。

必須監査には、次の操作が含まれます。

- データベースの起動。インスタンスを起動したオペレーティング・システム・ユーザー、そのユーザーの端末識別子、日時のタイム・スタンプを記述した監査レコードが生成されます。データベース監査証跡は起動処理が正常に完了するまで使用できないため、この監査レコードはオペレーティング・システム監査証跡に格納されます。

- SYSDBAおよびSYSOPERログイン。すべてのSYSDBAおよびSYSOPER接続が記録されます。

- データベースの停止。インスタンスを停止したオペレーティング・システム・ユーザー、そのユーザーの端末識別子および日時のタイム・スタンプを記述した監査レコードが生成されます。

注意:
AUDIT_SYSLOG_LEVEL初期化パラメータを設定すると、必須アクションはUNIX syslogに書き込まれます。syslog監査証跡の詳細は、「UNIXシステムでのsyslog監査証跡の使用」を参照してください。オペレーティング・システムの監査証跡とsyslog監査証跡の詳細は、使用しているオペレーティング・システム固有のOracle Databaseマニュアルも参照してください。

分散データベースでの監査

監査はサイト自律型です。インスタンスでは、直接接続しているユーザーによって発行された文のみが監査されます。ローカルのOracle Databaseノードでは、リモート・データベースで発生するアクションを監査できません。

監査のベスト・プラクティス

ベスト・プラクティスに関する次のガイドラインに従ってください。

- 原則として、法令順守要件を満たすために必要な量の情報を収集するように監査方針を策定しますが、必ず大きいセキュリティ問題の原因となるアクティビティに焦点を合わせてください。たとえば、データベース内のすべての表を監査するのではなく、給与など機密性の高いデータが入った表列を監査するのが実用的です。標準監査とファイングレイン監査の両方により、監査対象の特定のアクティビティに焦点を合わせた監査ポリシーの策定に使用できるメカニズムがあります。

- 監査証跡データを定期的にアーカイブして削除します。詳細は、「監査証跡レコードの削除」を参照してください。

関連項目:
システム監査の際に従う一般的なガイドラインは、「監査に関するガイドライン」を参照してください。

監査タイプの選択

実行する監査のタイプ、つまり一般アクティビティ(SQL文のアクションなど)、一般的に使用される監査アクティビティまたはファイングレイン監査に応じて、特定の手順を実行する必要があります。

これらのタイプの監査に加えて、Oracle Databaseではいくつかのアクティビティを強制的に監査します。詳細は、強制的に監査されるアクティビティを参照してください。

SQL文、権限および他の一般アクティビティの監査

Oracle Databaseには一連のデフォルト監査設定が用意されており、セキュリティに関連する一般的なSQL文と権限に対して使用可能にすることができます。

監査レコードの場所: Oracle Databaseでは、これらの監査レコードはAUDIT_TRAIL初期化パラメータに基づく場所に書き込まれます。「監査レコードの概要」も参照してください。

一般手順

1. 「セキュリティに関連するSQL文および権限に対するデフォルト監査の使用」の指示に従って、デフォルト監査を使用可能にします。
データベース監査証跡の詳細は、「監査証跡レコードの管理」を参照してください。

2. 監査アクティビティを監視するために、データベース監査証跡データ・ディクショナリ・ビューを定期的に問い合せます。「監査アクティビティに関する情報の検索」を参照してください。

3. データベース監査証跡のメンテナンスを実行します。「データベース監査証跡の管理」を参照してください。

4. 監査証跡の内容を定期的にアーカイブして削除します。「監査証跡レコードの削除」を参照してください。

一般的に使用されるセキュリティ関連アクティビティの監査

内容に基づいて、データ・アクセスとアクションを最も細かいレベルで監査できます。value > 7800などのブール基準、またはアクションが発生したIPアドレスを使用します。

監査レコードの場所: 監査レコードは、データベース監査証跡またはオペレーティング・システム監査証跡にXML形式で書き込むことができます。「監査レコードの概要」も参照してください。

一般手順

1. 「ファイングレイン監査を使用した特定のアクティビティの監査」を参照し、特定のアクティビティの監査の詳細を把握します。

2. 監査レコードをデータベース監査証跡とオペレーティング・システム・ファイルのどちらに書き込むかを決定します。「データベース監査証跡の管理」を参照してください。

3. DBMS_FGA PL/SQLパッケージを使用して、ファイングレイン監査ポリシーを構成します。DBMS_FGA.ADD_POLICYプロシージャには、監査証跡タイプの選択に使用するaudit_trailパラメータが用意されています。XMLファイルを使用して、データベース監査証跡またはオペレーティング・システム監査証跡を選択できます。次の各項を参照してください。
「ファイングレイン監査レコードの監査証跡の作成」

「DBMS_FGAパッケージを使用したファイングレイン監査ポリシーの管理」

4. 監査アクティビティを監視するために、構成したオペレーティング・システム・レコードを定期的にチェックするか、または監査証跡データ・ディクショナリ・ビューを問い合せます。「監査アクティビティに関する情報の検索」を参照してください。

5. 監査証跡のメンテナンスを実行します。「監査証跡レコードの管理」を参照してください。

6. 監査証跡の内容を定期的にアーカイブして削除します。「監査証跡レコードの削除」を参照してください。

特定のファイングレイン・アクティビティの監査

SYSDBAまたはSYSOPER権限を使用して接続したユーザーが発行したトップレベルのSQL文を監査できます。(トップレベルとは、ユーザーによって直接発行された文のことです。PL/SQLプロシージャまたはファンクションから実行される文は、トップレベルとはみなされません。)

監査レコードの場所: Oracle Databaseでは、これらの監査レコードはオペレーティング・システム監査証跡にのみ書き込まれます。Windowsの場合、SYS監査レコードはデフォルトでWindowsイベント・ログに書き込まれます。UNIXシステムの場合、レコードをsyslogファイルに書き込むことができます。「監査レコードの概要」も参照してください。

一般手順

1. 「SYS管理ユーザーの監査」を参照して、管理監査を構成します。

2. オペレーティング・システム監査証跡の詳細は、「オペレーティング・システム監査証跡の管理」を参照してください。

3. 監査アクティビティを監視するために、構成したオペレーティング・システム・レコードまたはsyslogレコードを定期的にチェックします。XMLファイルに書き込んでいる場合は、V$XML_AUDIT_TRAILおよびDBA_COMMON_AUDIT_TRAILビューを問合せできます。「監査アクティビティに関する情報の検索」を参照してください。

4. 監査証跡のメンテナンスを実行します。「監査証跡レコードの管理」を参照してください。

5. 監査証跡の内容を定期的にアーカイブして削除します。「監査証跡レコードの削除」を参照してください。

標準監査を使用した一般的なアクティビティの監視

この項の内容は、次のとおりです。

- 標準監査の概要

- AUDIT_TRAIL初期化パラメータを使用した標準監査の構成

- オペレーティング・システム監査証跡とデータベース監査証跡の共通点

- オペレーティング・システム監査証跡の使用

- UNIXシステムでのsyslog監査証跡の使用

- AUDITおよびNOAUDIT SQL文の動作

- SQL文の監査

- 権限の監査

- 複数層環境におけるSQL文および権限の監査

- スキーマ・オブジェクトの監査

- ディレクトリ・オブジェクトの監査

- ファンクション、プロシージャ、パッケージおよびトリガーの監査

- ネットワーク・アクティビティの監査

関連項目:

- 標準監査を使用してSYSユーザーを監査する方法は、「SYS管理ユーザーの監査」を参照してください。

- 標準監査証跡の作成例は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

標準監査の概要

この項の内容は、次のとおりです。

- 標準監査とは

- 標準監査の実行者

- 標準監査レコードが作成される場合

標準監査とは

標準監査では、SQL文、権限、スキーマ・オブジェクトおよびネットワーク・アクティビティを監査します。AUDIT SQL文を使用して標準監査を構成し、NOAUDITを使用してこの構成を解除します。監査レコードは、データベース監査証跡またはオペレーティング・システム監査ファイルに書き込むことができます。

標準監査の実行者

どのユーザーでも、AUDIT文を使用して、独自のスキーマ内のオブジェクトに対して監査を構成できます。また、NOAUDIT文を使用して、対象のオブジェクトに対する監査構成を元に戻すことができます。このタスクを実行するために追加権限は必要ありません。ユーザーは、AUDIT_TRAILパラメータの設定に関係なく、AUDIT文を実行して監査オプションを設定できます。監査が使用禁止になっている場合、次回使用可能にしたときに、Oracle Databaseでは、AUDIT文で設定した監査アクティビティが記録されます。標準監査を使用可能にする方法は、「標準監査証跡を使用可能および使用禁止にする方法」を参照してください。

次のことに注意してください。

- 別のスキーマ内のオブジェクトを監査するには、ユーザーにAUDIT ANYシステム権限が必要です。

- システム権限を監査するには、ユーザーにAUDIT SYSTEM権限が必要です。

- O7_DICTIONARY_ACCESSIBILITY初期化パラメータがFALSE(デフォルト)に設定されている場合、SYS.AUD$およびSYS.FGA_LOG$表内の監査データに対してDMLアクションを実行できるのは、SYSDBA権限を持つユーザーのみとなります。セキュリティを強化するためには、O7_DICTIONARY_ACCESSIBILITYパラメータをFALSEに設定して、非SYSDBAユーザーがSYSオブジェクトを監査できないようにします。

関連項目:

- 使用可能なシステム権限およびオブジェクト権限のリストは、『Oracle Database SQL言語リファレンス』のGRANTに関する項を参照してください。

- 監査オプションの全リストは、『Oracle Database SQL言語リファレンス』のAUDITに関する項を参照してください。

標準監査レコードが作成される場合

データベース全体の標準監査は、セキュリティ管理者が使用可能または使用禁止にします。使用禁止の場合、監査レコードは作成されません。監査オプションの構成の詳細は、前の項「標準監査の実行者」を参照してください。

データベースの監査機能が使用可能なときに、監査対象として構成されたアクションが発生すると、SQL文の実行フェーズ時または実行フェーズ後に監査レコードが生成されます。PL/SQLプログラム・ユニット内のSQL文は、プログラム・ユニットの実行時に必要に応じて個別に監査されます。

監査証跡レコードの生成と挿入は、ユーザー・トランザクションのコミットからは独立して実行されます。つまり、ユーザー・トランザクションがロールバックされても、監査証跡レコードはコミットされたままになります。

データベース・ユーザーがデータベースに接続した時点で有効になっていた文監査オプションと権限監査オプションは、そのセッションの持続期間中は有効です。セッションがすでにアクティブになっている場合、文監査または権限監査のオプションを設定または変更しても、そのセッション中は有効になりません。修正した文監査オプションまたは権限監査オプションは、カレント・セッションを終了し、新しいセッションを作成した時点で有効になります。

一方、オブジェクト監査オプションについて変更した内容は、カレント・セッションでただちに有効になります。

関連項目:
SQL文処理の様々なフェーズや共有SQLについては、『Oracle Database概要』を参照してください。

AUDIT_TRAIL初期化パラメータを使用した標準監査の構成

この項の内容は、次のとおりです。

- 標準監査証跡を使用可能または使用禁止にする方法

- AUDIT_TRAIL初期化パラメータの設定

標準監査証跡を使用可能または使用禁止にする方法

標準監査証跡を使用可能にするには、AUDIT_TRAIL初期化パラメータを設定します。この設定によって、データベース監査証跡に監査証跡を作成するかどうか、オペレーティング・システム・ファイルに監査アクティビティを書き込むかどうか、監査を使用禁止にするかどうかが判別されます。

標準監査証跡を使用可能または使用禁止にするには、管理権限でSQL*Plusにログインし、ALTER SYSTEM文を使用します。その後、データベース・インスタンスを再起動する必要があります。

AUDIT_TRAILパラメータの現在の値を調べるには、SQL*PlusでSHOW PARAMETERコマンドを使用します。

例9-1に、AUDIT_TRAILパラメータの設定を調べる方法を示します。

例9-1 AUDIT_TRAIL初期化パラメータの現在の値を調べる方法

SHOW PARAMETER AUDIT_TRAIL

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------
audit_trail                          string      DB

例9-2に、SQL*Plusにログインし、標準監査証跡を使用可能にして、データベース・インスタンスを再起動する方法を示します。

例9-2 標準監査証跡を使用可能にする方法

CONNECT SYSTEM
Enter password: password

ALTER SYSTEM SET AUDIT_TRAIL=DB SCOPE=SPFILE;
System altered.

CONNECT SYS/AS SYSOPER
Enter password: password

SHUTDOWN
Database closed.
Database dismounted.
ORACLE instance shut down.

STARTUP
ORACLE instance started.

この例では、データベース・インスタンスはサーバー・パラメータ・ファイル(SPFILE)を使用して起動されているため、SCOPE句を使用します。サーバー・パラメータ・ファイルを使用したデータベースの起動は、データベース・インスタンスの推奨される起動方法です。サーバー・パラメータ・ファイルの作成および構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

AUDIT_TRAIL初期化パラメータの設定

表9-1に、AUDIT_TRAIL初期化パラメータに使用できる設定を示します。

表9-1 AUDIT_TRAIL初期化パラメータの設定

AUDIT_TRAILの値

説明

DB

オペレーティング・システムの監査証跡に常に書き込まれる必須監査レコードおよびSYS監査レコードを除いて、監査レコードをデータベース監査証跡(SYS.AUD$表)に書き込みます。(監査タイプの選択に、監査のタイプごとの監査レコードの場所を説明します。)管理を容易にするために、汎用データベースの場合はこの設定を使用してください。DBは、AUDIT_TRAILパラメータのデフォルト設定です。

AUDIT_TRAILがDBに設定されている状態でデータベースが読取り専用モードで起動された場合、Oracle DatabaseによってAUDIT_TRAILはOSに内部的に設定されます。詳細は、アラート・ログをチェックしてください。

「データベース監査証跡の管理」も参照してください。

DB,EXTENDED

AUDIT_TRAIL=DBの場合と同じように動作し、可能な場合は、SYS.AUD$表のSQLバインドおよびSQLテキストのCLOB型の列にデータを移入します。

DB,EXTENDEDを使用すると、監査されたアクションで使用されたSQL文を取得できます。監査が行われたSQL文と関連バインド変数の両方を取得できます。ただし取得できるデータは、CHAR、NCHAR、VARCHAR、VARCHAR2、NVARCHAR2、NUMBER、FLOAT、BINARY_FLOAT、BINARY_DOUBLE、LONG、ROWID、DATE、TIMESTAMP、およびTIMESTAMP WITH TIMEZONEの列データ型からのみであることに注意してください。また、DB, EXTENDEDがクレジット・カード情報のような機密性の高いデータを取得できることも注意してください。「機密情報の監査」も参照してください。

AUDIT_TRAILがDB, EXTENDEDに設定されている状態でデータベースが読取り専用モードで起動された場合、Oracle DatabaseによってAUDIT_TRAILはOSに内部的に設定されます。詳細は、アラート・ログをチェックしてください。

DB,EXTENDEDを次のいずれかの方法で指定できます。

ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE;
ALTER SYSTEM SET AUDIT_TRAIL=DB, EXTENDED SCOPE=SPFILE;
ALTER SYSTEM SET AUDIT_TRAIL='DB','EXTENDED' SCOPE=SPFILE;
ALTER SYSTEM SET AUDIT_TRAIL=EXTENDED,DB SCOPE=SPFILE;
ALTER SYSTEM SET AUDIT_TRAIL=EXTENDED, DB SCOPE=SPFILE;

ただし、DB, EXTENDEDを引用符で囲まないでください。次に例を示します。

ALTER SYSTEM SET AUDIT_TRAIL='DB, EXTENDED' SCOPE=SPFILE;

以前のリリースでは、設定はDB_EXTENDEDでした。この設定は下位互換性のために維持されましたが、将来のリリースでは使用できなくなる可能性があります。

OS

すべての監査レコードをオペレーティング・システム・ファイルに書き込みます。

特に安全性の非常に高いデータベース構成を使用している場合は、OS設定を使用することをお薦めします。詳細は、「オペレーティング・システム監査証跡の利点」を参照してください。例9-3「テキスト・ファイル形式のオペレーティング・システム監査証跡」も参照してください。

AUDIT_TRAILをOSに設定した場合は、次の初期化パラメータも設定します。

- AUDIT_FILE_DEST (オペレーティング・システムの監査レコード・ファイルの場所を指定します)。UNIXシステムでは、デフォルトの場所は$ORACLE_BASE/admin/$ORACLE_SID/adumpです。UNIXシステムでのパフォーマンスを向上するために、AUDIT_FILE_DESTパラメータを、Oracle Databaseインスタンスを実行しているホストにローカル接続されたディスク上のディレクトリに設定してください。Windowsでは、OS設定により監査証跡はWindowsイベントビューアのApplication領域に書き込まれます。

- AUDIT_SYS_OPERATIONSは、SYSDBAまたはSYSOPER権限で接続したユーザーにより直接発行されたトップレベルのSQL文を監査する場合に設定します。この監査を使用可能にするには、AUDIT_SYS_OPERATIONSをTRUEに設定します。
AUDIT_SYS_OPERATIONSをTRUEに設定し、AUDIT_TRAILをXMLまたはXML,EXTENDEDに設定すると、SYS監査レコードのオペレーティング・システム・ファイルはXML形式で書き込まれます。

- AUDIT_SYSLOG_LEVEL (SYSおよび標準OS監査レコードを、SYSLOGユーティリティを使用してシステム監査ログに書き込みます)。このオプションはUNIX環境にのみ適用されます。詳細は、「syslog監査の構成」を参照してください。

「オペレーティング・システム監査証跡の管理」も参照してください。

XML

XML形式でオペレーティング・システム監査レコード・ファイルに書き込みます。http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail-11_2.xsdのXML文により指定されたAuditRecordノードの、Sql_TextおよびSql_Bindを除くすべての要素を、オペレーティング・システムのXML監査ファイルに記録します。(この.xsdファイルは、XML監査ファイルのスキーマ定義を表します。XMLスキーマはXMLスキーマ言語で記述された文書です。)

「オペレーティング・システム監査証跡の利点」および例9-4「XMLファイル形式のオペレーティング・システム監査証跡」も参照してください。

値XMLを設定した場合は、AUDIT_FILE_DESTパラメータも設定します。Windowsを含めてすべてのプラットフォームで、XML監査証跡レコードのデフォルトの場所は$ORACLE_BASE/admin/$ORACLE_SID/adumpです。

XML AUDIT_TRAILの値は、syslog監査ファイルには影響しません。つまり、AUDIT_TRAILパラメータをXMLに設定した場合、syslog監査レコードは、XMLファイル形式ではなく、引き続きテキスト形式になります。

SYSおよび必須監査レコードの出力は、次のように制御できます。

- SYSおよび必須監査ファイルをXML形式のオペレーティング・システム・ファイルに書き込む場合: AUDIT_TRAILをXMLまたはXML,EXTENDEDに設定し、AUDIT_SYS_OPERATIONSをTRUEに設定します。ただし、AUDIT_SYSLOG_LEVELパラメータは設定しません。

- SYSおよび必須監査レコードをsyslog監査ファイルに書き込み、標準監査レコードをXML監査ファイルに書き込む場合: AUDIT_TRAILをXMLまたはXML,EXTENDEDに設定し、AUDIT_SYS_OPERATIONSをTRUEに設定します。また、AUDIT_SYSLOG_LEVELパラメータも設定します。

XML, EXTENDED

AUDIT_TRAIL=XMLと同様に動作する以外に、SQLテキストおよびSQLバインド情報をオペレーティング・システムXML監査ファイルに追加します。

XML,EXTENDEDを次のいずれかの方法で指定できます。

ALTER SYSTEM SET AUDIT_TRAIL=XML, EXTENDED SCOPE=SPFILE;
ALTER SYSTEM SET AUDIT_TRAIL='XML','EXTENDED' SCOPE=SPFILE;

ただし、XML, EXTENDEDを引用符で囲まないでください。次に例を示します。

ALTER SYSTEM SET AUDIT_TRAIL='XML, EXTENDED' SCOPE=SPFILE;

次の各項も参照してください。

- 「オペレーティング・システム監査証跡の利点」

- 「機密情報の監査」

NONE

標準監査を使用禁止にします。

次のことに注意してください。

- AUDITまたはNOAUDIT文を実行した後、データベースを再起動する必要はありません。データベースの再起動が必要になるのは、AUDIT_TRAIL初期化パラメータの変更など、全般的な変更を加えた場合のみです。

- ファイングレイン監査またはSYS監査を使用可能にする場合、AUDIT_TRAILの設定は不要です。ファイングレイン監査の場合は、ファイングレイン監査ポリシーを必要に応じて追加および削除して、監視する特定の操作またはオブジェクトに適用します。SYS監査を使用可能にするには、AUDIT_SYS_OPERATIONSパラメータをTRUEに設定します。

オペレーティング・システム監査証跡とデータベース監査証跡の共通点

オペレーティング・システム監査証跡とデータベース監査証跡では、同じタイプの多くのアクションが取得されます。表9-2に、オペレーティング・システム監査証跡レコードを示します。ほとんどのレコードがDBA_AUDIT_TRAILビューの列に対応しています。これらの列の詳細は、『Oracle Databaseリファレンス』を参照してください。

表9-2 オペレーティング・システム監査証跡とデータベース監査証跡で共通して監査されるアクション

オペレーティング・システム監査レコード

DBA_AUDIT_TRAILビューの対応する列

SESSIONID

SESSIONID

ENTRYID

ENTRYID

STATEMENT

STATEMENTID

USERID

USERNAME

USERHOST

USERHOST

TERMINAL

TERMINAL

ACTION

ACTION

SYS$OPTIONS

どの監査オプションが AUDITまたはNOAUDITで設定されたか、またはどの権限が付与あるいは取り消されたかを示します。脚注 1

RETURNCODE

RETURNCODE

OBJ$CREATOR

OWNER

OBJ$NAME

OBJ_NAME

OBJ$PRIVILEGES

OBJ_PRIVILEGE

AUTH$GRANTEE

GRANTEE

NEW$OWNER

NEW_OWNER

NEW$NAME

NEW_NAME

SES$ACTIONS

SES_ACTIONS

LOGOFF$PREAD

LOGOFF_PREAD

LOGOFF$LWRITE

LOGOFF_LWRITE

COMMENT$TEXT

COMMENT_TEXT

OS$USERID

OS_USERNAME

PRIV$USED

PRIV_USED

SES$LABEL

CLIENT_ID

SES$TID

DBA_AUDIT_TRAILビューに対応する列はありませんが、SYS.AUD$表には表示されます。

SPARE2

DBA_AUDIT_TRAILビューに対応する列はありませんが、SYS.AUD$表には表示されます。

脚注1たとえば、ACTIONの値が104(AUDIT)または105(NOAUDIT)の場合、SYS$OPTIONSの数値はSTMT_AUDIT_OPTION_MAP表にリストされた監査オプションを表します。ACTIONの値が108(GRANT)または109(REVOKE)の場合、この数値はSYSTEM_PRIVILEGE_MAP表にリストされた権限を表します。

オペレーティング・システム監査証跡の使用

この項の内容は、次のとおりです。

- オペレーティング・システム証跡の概要

- オペレーティング・システム監査証跡レコードの表示形式

- オペレーティング・システム監査証跡の利点

- オペレーティング・システム監査証跡の機能

- オペレーティング・システム監査証跡のディレクトリの指定

オペレーティング・システム証跡の概要

標準監査レコードは、DBA_AUDIT_TRAIL(SYS.AUD$表)に作成するかわりに、オペレーティング・システム・ファイルに作成できます。監査証跡を含むオペレーティング・システム・ファイルには、次のデータが記録されます。

- データベース監査証跡レコード

- 必須監査レコード(つまり、常に監査されるデータベース・アクション)

- 管理ユーザー(SYS)用の監査レコード

オペレーティング・システム監査レコードは、テキスト・ファイルまたはXMLファイルに書き込むことができます。

オペレーティング・システム監査証跡レコードの表示形式

オペレーティング・システム監査証跡ファイルのファイル形式は、テキストとXMLのいずれかです。テキスト・ファイルとXMLオペレーティング・システム・ファイルの内容にはいくつか違いがあること、そしてリリースが異なると形式が変わる場合があることに注意してください。Oracle Databaseのリリースごとに、監査タイプなど、新しい拡張機能がテキスト・ファイルではなくXMLファイルに対して行われてきました。テキストのオペレーティング・システム・ファイルでは、たとえばタイムスタンプが次のように異なった表示になります。

Wed May  6 00:57:36 2009 -07:00

ただし、このタイムスタンプは、イベント・ログやsyslogには表示されません(イベント・ログやsyslogでは、それぞれ独自の形式のタイムスタンプが使用されます)。このタイムスタンプ文字列は、テキスト形式のオペレーティング・システム監査ファイルにのみ表示されます。

例9-3は、Microsoft WindowsにインストールされているOracleデータベースでのログイン操作についての標準的テキストのオペレーティング・システム監査証跡を示しています。(実際のレコードのテキストは折り返して表示されますが、このマニュアルではわかりやすくするために各項目をそれぞれの行に分けて示しています。)

例9-3 テキスト・ファイル形式のオペレーティング・システム監査証跡

Audit trail:
LENGTH: "349"
SESSIONID:[5] "43464"
ENTRYID:[1] "1"
STATEMENT:[1] "1"
USERID:[6] "DBSNMP"
USERHOST:[7] "SHOBEEN"
TERMINAL:[3] "MAU"
ACTION:[3] "100"
RETURNCODE:[1] "0"
COMMENT$TEXT:[97] "Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.4)(PORT=2955))"
OS$USERID:[19] "NT AUTHORITY\SYSTEM"
DBID:[10] "1212547373"
PRIV$USED:[1] "5"

この例の説明は、次のとおりです。

- LENGTHは、この監査レコードで使用されている合計バイト数を示します。この数値には、監査レコードの末尾の改行バイト(\n)(存在する場合)も含まれます。

- [](括弧)は、各監査エントリの各値の長さを示します。たとえば、USERIDエントリのDBSNMPの長さは6バイトです。

- SESSIONIDは、監査セッションID番号を示します。セッションIDは、V$SESSIONデータ・ディクショナリ・ビューのAUDSID列を問い合せることでも確認できます。

- ENTRYIDは、各監査証跡レコードに現在割り当てられている監査エントリ番号を示します。ENTRYIDの監査順序番号は、ファイングレイン監査レコードと標準監査レコードで共有されます。

- STATEMENTは、ユーザーが実行する文に割り当てられた数値IDです。ユーザー・セッション中に発行される文ごとに表示されますが、これは1つの文で監査レコードが複数になる場合があるためです。

- ACTIONは、ユーザーが実行したアクションを表す数値です。対応するアクション・タイプの名前はAUDIT_ACTIONS表に表示されます。たとえば、アクション100はLOGONを表します。

- RETURNCODEは、監査対象のアクションが成功したかどうかを示します。0 (ゼロ)は、成功したことを示します。アクションが失敗した場合は、リターン・コードにOracle Databaseエラー番号が示されます。たとえば、存在しない表を削除しようとした場合、エラー番号はORA-00903「表名が無効です。」になり、これがRETURNCODE設定で903に変換されます。

- COMMENT$TEXTは、監査レコードに関する追加のコメントを示します。たとえばLOGON監査レコードの場合、認証方式などがコメントとして考えられます。この情報は、DBA_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビューのCOMENT_TEXT列に対応します。

- DBIDは、データベースが作成されるときに算出されるデータベース識別子です。この情報は、V$DATABASEデータ・ディクショナリ・ビューのDBID列に対応します。

- ECONTEXT_IDは、アプリケーション実行コンテキストの識別子を示します。

- PRIVS$USEDは、アクションを実行するために使用された権限を示します。権限を検索するには、SYSTEM_PRIVILEGE_MAP表を問い合せます。たとえば、権限5は、この表では-5として表され、CREATE SESSIONを意味します。PRIVS$USEDは、DBA_COMMON_AUDIT_TRAILのPRIV_USED列に対応します。このビューでは、名前別に権限が示されます。

他の値としては、次のものがあります。

- SCN(たとえば、SCN:8934328925)は、システム変更番号(SCN)を示します。フラッシュバック問合せを実行して設定(たとえば、列)の値を検索する場合に、この値を使用します。たとえば、OE.ORDERS表のORDER_TOTAL列の値をSCN番号に基づいて検索するには、次のSELECT文を使用します。

SELECT ORDER_TOTAL
FROM OE.ORDERS
AS OF SCN = 8934328925
WHERE ORDER_TOTAL = 86;

- SES_ACTIONSは、セッション中に実行されたアクションを示します。このフィールドは、BY SESSION句を使用してイベントが監査された場合にのみ存在します。このフィールドにはセッション中に実行されたアクションの詳細は示されないため、BY ACCESS句を使用して監査イベントを構成する必要があります。
SES_ACTIONSフィールドには16文字が表示されます。14、15および16桁目は、将来の使用のために予約されています。最初の12文字では、各桁がアクションの結果を示します。該当するアクションは、ALTER、AUDIT、COMMENT、DELETE、GRANT、INDEX、INSERT、LOCK、RENAME、SELECT、UPDATEおよびFLASHBACKです。たとえば、ユーザーがALTER文を正常に実行した場合、SES_ACTIONS設定は次のようになります。

S---------------

1桁目のSは(ALTERの場合)、成功を示します。ALTER文が失敗した場合は、かわりに文字Fが表示されます。アクションの結果が成功と失敗の両方の場合は、文字Bが表示されます。

- SES$TIDは、監査対象のアクションの影響を受けたオブジェクトのIDです。

- SPARE2は、ユーザーがSYS.AUD$表を変更したかどうかを示します。0(ゼロ)は、ユーザーがSYS.AUD$を変更したことを意味します。それ以外の場合、値はNULLです。

同様に、例9-4に、XML監査証跡レコードの表示形式を示します。実際のレコードのテキストは折り返して表示されますが、このマニュアルではわかりやすくするために各要素をそれぞれ個別の行に示しています。Webブラウザで次のスキーマを表示して、XML監査ファイルに表示されるすべてのタグを確認できます。

http://www.oracle.com/technology/oracleas/schema/dbserver_audittrail-11_2.xsd

例9-4 XMLファイル形式のオペレーティング・システム監査証跡

<?xml version="1.0" encoding="UTF-8"?>
<Audit xmlns="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail-11_2.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail-11_2.xsd">
<Version>11.2</Version>
<AuditRecord>
<Audit_Type>1</Audit_Type>
<Session_Id>43535</Session_Id>
<StatementId>1</StatementId>
<EntryId>1</EntryId>
<Extended_Timestamp>2009-04-29T18:32:26.062000Z</Extended_Timestamp>
<DB_User>SYSMAN</DB_User>
<OS_User>SYSTEM</OS_User>
<Userhost>shobeen</Userhost>
<OS_Process>3164:3648</OS_Process>
<Terminal>mau</Terminal>
<Instance_Number>0</Instance_Number>
<Action>100</Action>
<TransactionId>0000000000000000</TransactionId>
<Returncode>0</Returncode>
<Comment_Text>Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.4)(PORT=3536))</Comment_Text>
<Priv_Used>5</Priv_Used>
</AuditRecord>
</Audit>

この例の説明は、次のとおりです。

- AuditRecord要素には、監査レコード全体が含まれます。(Audit_Record要素内の要素の詳細は、例9-3を参照してください。)

- Audit_Typeは、監査証跡のタイプを示します。次の値があります。

- 1: 標準監査レコード

- 2: ファイングレイン監査レコード

- 4: SYS監査レコード

- 8: 必須監査レコード

このフィールドは、XML形式の監査ファイルにのみ表示され、テキスト形式のオペレーティング・システム監査ファイルには表示されません。

- Extended_Timestampは、監査対象の操作が実行された時間(AUDIT SESSIONで作成されたエントリに対するユーザー・ログインのタイムスタンプ)を示します。この時間は、協定世界時(UTC)またはグリニッジ標準時(GMT)で示されます。このフィールドは、XML形式の監査ファイルにのみ表示され、テキスト形式のオペレーティング・システム監査ファイルには表示されません。

- Instance_Numberは、Oracle Real Application Clusters環境でユーザーが接続しているインスタンスの番号を示します。この例では、番号は0で、単一インスタンス・データベース・インストールに使用されます。この番号は、INSTANCE_NUMBER初期化パラメータで指定します。

AUDIT_TRAILパラメータをXML, EXTENDEDに設定すると、次の値が表示されます。これらの値はどちらもDBA_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビューにリストされます。

- Sql_Bind(たとえば、<Sql_Bind>#1(5):89</Sql_Bind>)は、バインド変数の値を示します。構文は、次のとおりです。

VariablePosition(LengthOfVariableValue):ValueofBindVariable

例の#1(5):89は、バインド変数が1つ存在し、その値の長さが5文字であり、バインド変数の値が89であることを示します。

- Sql_Text(たとえば、<Sql_Text>begin procedure_one(:num); end; </Sql_Text>)は、AUDIT_TRAILパラメータをXML, EXTENDEDに設定している場合に表示されます。これは、ユーザーが入力したSQLテキストを示します。

オペレーティング・システム監査証跡の利点

オペレーティング・システム監査証跡を使用する利点は、次のとおりです。

- サービス拒否(DoS)攻撃の可能性が低くなります。

- 監査証跡の保護が容易になります。監査人がデータベース管理者とは別のユーザーである場合は、OS、XML、またはXML, EXTENDED設定を使用する必要があります。この設定を使用しない場合、データベースに格納される監査情報をデータベース管理者が表示および変更できます。

- オペレーティング・システム監査証跡では、監査証跡が特定のユーザーに制限可能な特定の場所へ書き込まれているため、業務分離の概念が規定されます。

- 監査証跡をオペレーティング・システム・ファイルに書き込むと、データベースのオーバーヘッドが最小になります。この理由から、大規模なデータベースには最適です。

- オペレーティング・システム・ファイルに格納された監査レコードは、データベース管理者にはないファイル権限をアクセス時に必要とするため、データベースに格納された監査レコードよりも安全です。また、オペレーティング・システムでの監査レコードの格納では、データベースが一時的にアクセス不可能な状態でも監査レコードが使用可能であるため、可用性の向上というもう1つの利点があります。

- AUDIT_TRAIL初期化パラメータがXML(またはXML, EXTENDED)に設定されている場合、監査レコードはXMLファイルとしてオペレーティング・システムに書き込まれます。V$XML_AUDIT_TRAILビューを使用すると、データベース管理者はSQL問合せを介してXML監査レコードを使用できるため、使いやすさが向上します。

- DBA_COMMON_AUDIT_TRAILビューには、データベース表に書き込まれる標準およびファイングレイン監査証跡、XML形式の監査証跡レコード、およびV$XML_AUDIT_TRAIL動的ビューの内容(標準、ファイングレイン、SYSおよび必須)が含まれます。

- オペレーティング・システム監査証跡を使用すると、Oracle Databaseや他のアプリケーションを含む複数のソースからの監査レコードを整理統合できます。そのため、すべての監査レコードが1箇所にまとめられ、システム・アクティビティの調査をより効率的に行うことができます。XML監査レコードを使用すると、任意の標準XML編集ツールを使用して、これらのレコードの情報を確認または抽出できます。

オペレーティング・システム監査証跡の機能

オペレーティング・システム監査証跡では、監査データがオペレーティング・システム・ファイルに書き込まれます。この機能は、AUDIT_TRAIL初期化パラメータを次のいずれかの値に設定することで使用可能にできます。

- OS: 監査証跡レコードは、UNIXシステムの場合はテキスト形式のオペレーティング・システム・ファイルに、Microsoft Windowsの場合はアプリケーションのイベントビューアに書き込まれます。

- XML: 監査証跡レコードはXMLファイルに書き込まれます。

- XML, EXTENDED: XMLファイルに監査証跡レコードを書き込み、SQLテキストおよびSQLバインド情報をオペレーティング・システムXML監査ファイルに追加します。

AUDIT_FILE_DEST初期化パラメータでは、オペレーティング・システム監査ファイルの場所を設定します。データベースにSYSDBAまたはSYSOPER権限でログインするユーザーによって発行されたトップレベルの文を監査する場合は、AUDIT_SYS_OPERATIONSパラメータをTRUEに設定します。これらの設定の詳細は、表9-1「AUDIT_TRAIL初期化パラメータの設定」を参照してください。

オペレーティング・システム・ファイルに書き込まれるレコードは、SYS.AUD$およびSYS.FGA_LOG$表には記録されません。この場合も、DBA_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せると、XML形式のオペレーティング・システム監査ファイルの内容を表示できます。このビューを問い合せると、AUDIT_FILE_DESTディレクトリ内のすべてのXMLファイル(.xml拡張子を持つすべてのファイル)が解析され、リレーショナル表の形式で表示されます。XMLは標準文書形式であるため、XMLデータを解析および分析できる多くのユーティリティがあります。使用しているオペレーティング・システムにこの機能が実装されているかどうかは、そのオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

オペレーティング・システム監査証跡のディレクトリの指定

AUDIT_TRAIL初期化パラメータがOS、XML、またはXML, EXTENDEDに設定されている場合は、AUDIT_FILE_DEST初期化パラメータを使用して監査証跡が書き込まれるオペレーティング・システム・ディレクトリを指定します。AUDIT_FILE_DESTを、権限がOracleソフトウェアの所有者とDBAグループに制限された有効なディレクトリに設定する必要があります。必須監査情報もそのディレクトリに入り、AUDIT_SYS_OPERATIONS初期化パラメータが指定されている場合はユーザーSYSの監査レコードと同様にこのディレクトリに入ります。AUDIT_FILE_DESTパラメータはALTER SYSTEM文を使用して変更できます。この文により、以降のすべてのセッションで新しい宛先を有効にすることができます。

ALTER SYSTEM SET AUDIT_FILE_DEST = directory_path DEFERRED;

AUDIT_FILE_DESTパラメータの現行の設定を調べるには、次のコマンドを発行します。

SHOW PARAMETER AUDIT_FILE_DEST

オペレーティング・システム・ファイルの場所は、次の状況によって異なります。

- データベースが実行されておらず、AUDIT_FILE_DESTパラメータを設定していない場合、オペレーティング・システム・ファイルは最初のデフォルトの場所($ORACLE_BASE/admin/$ORACLE_SID/adumpディレクトリ)に配置されます。

- データベースが実行されておらず、最初のデフォルトの場所($ORACLE_BASE/admin/$ORACLE_SID/adumpディレクトリ)がアクセス不能か書込み不能になっている場合、またはOracleプロセスで環境変数を識別できない場合、2番目のデフォルトの場所($ORACLE_HOME/rdbms/audit)が使用されます。

- データベースがオープンされており、Oracle Databaseでデータベース・インスタンスの初期化ファイル(initSID.ora)が読み取られた場合、AUDIT_FILE_DESTパラメータの値がオペレーティング・システム監査ファイル・ディレクトリとして使用されます。

- UNIXおよびSolarisシステムの場合、すべてのオペレーティング・システム・ファイルがオペレーティング・システム内のディレクトリに書き込まれます。Windowsの場合、テキスト形式のオペレーティング・システム・レコードについては、Windowsイベントビューアから使用でき、XML形式のオペレーティング・システム・ファイルについては、前述の箇条書き項目に示すようにオペレーティング・システム・ディレクトリから使用できます。

注意:
UNIX、SolarisおよびWindows以外のプラットフォームを使用している場合は、そのプラットフォームのマニュアルでオペレーティング・システム・ファイルの正しいターゲット・ディレクトリを確認してください。

UNIXシステムでのsyslog監査証跡の使用

UNIXシステムでは、syslog監査証跡を作成することによって、ユーザー(権限を持つユーザーを含む)のアクティビティを監査して、syslogファイルにこれらのアクティビティを記録できます。

この項の内容は、次のとおりです。

- syslog監査証跡の概要

- syslog監査証跡に格納される情報の形式

- syslog監査証跡の表示形式

- syslog監査の構成

syslog監査証跡の概要

syslog監査証跡を使用して、オペレーティング・システムのSyslog機能で提供される集中化された監査機能を構成できます。syslogとは、ネットワークの様々なコンポーネントからのログ情報のUNIXベース・システムでの標準プロトコルです。アプリケーションはsyslogデーモンに情報を記録するためのsyslog()関数をコールし、syslogデーモンは情報をどこに記録するかを決定します。syslogファイルを使用するよう構成すると、メッセージがsyslogデーモン・プロセスに送信されることに注意してください。syslogデーモン・プロセスは、syslogファイルへのコミットされた書込みを示す確認応答をOracle Databaseに返しません。

Oracleプロセスなどのアプリケーションがsyslog()関数を使用して情報をsyslogデーモンに記録するため、権限を持つユーザーにはsyslogメッセージの記録先ファイル・システムへのアクセス権はありません。このため、syslog監査証跡を使用して格納された監査レコードは、オペレーティング・システムの監査証跡を使用して格納された監査レコードよりも安全に保護されます。権限を持つユーザーに対するファイル・システムへのアクセス権の制限に加えて、syslog監査証跡をセキュリティで保護するために、権限を持つユーザーもOracleプロセスも、監査レコードが書き込まれるシステムへのrootアクセスはできないようにする必要があります。

注意:
syslog監査を使用可能にする前に、syslogの使用方法をよく理解しておく必要があります。syslogの詳細は次の資料を参照してください。

- AUDIT_SYSLOG_LEVEL初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- facility.priorityの設定とそのディレクトリ・パスの詳細は、syslogdユーティリティのUNIX man pageを参照してください。

syslog監査証跡に格納される情報の形式

オペレーティング・システムの監査証跡レコードと同様に、Oracle Databaseでは、セキュリティを強化するためにsyslogレコードがエンコードされます。Oracle Audit Vaultをインストール済の場合は、Syslog Collectorを使用し、syslog監査レコードを抽出して中央のOracle Audit Vaultサーバーに転送できます。

syslog監査証跡の表示形式

例9-5は、表示されるsyslog監査証跡を示しています。(この例では、わかりやすくするためにテキストは書式変更されています。実際には、テキストはすべてが1行で表示されます。)他のOracle Database監査証跡と同じように、括弧内は監査された値の長さを示しています。syslog監査証跡では、LENGTH:以降のテキストがOracle Database監査レコードです。先頭に追加されたテキスト(日付とOracle Audit [10085]の行)は、syslogユーティリティによって追加されています。

例9-5 SYSユーザーのsyslog監査証跡

May 14 23:40:15 shobeen
Oracle Audit[10085]:
LENGTH : '171'
ACTION :[18] 'select * from aud$'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[7] 'laurelh'
CLIENT TERMINAL:[6] 'pts/12'
STATUS:[1] '0'
DBID:[9] '562317007'

syslog監査の構成

syslog監査を使用可能にする手順は、次のとおりです。

1. AUDIT_TRAIL初期化パラメータに値OSを割り当てます(「標準監査証跡を使用可能および使用禁止にする方法」を参照)。
次に例を示します。

ALTER SYSTEM SET AUDIT_TRAIL=OS SCOPE=SPFILE;

2. AUDIT_SYSLOG_LEVELパラメータを初期化パラメータ・ファイルinitsid.oraに手動で設定します。
AUDIT_SYSLOG_LEVELパラメータは、AUDIT_SYSLOG_LEVEL=facility.priorityの形式で機能と優先度を指定するように設定します。

- facility: メッセージをログに記録するオペレーティング・システムの一部を示します。指定できる値は、user、local0–local7、syslog、daemon、kern、mail、auth、lpr、news、uucpおよびcronです。
local0–local7の値は、syslogメッセージをカテゴリに分類できる事前定義のタグです。これらのカテゴリは、ログ・ファイルまたはsyslogユーティリティでアクセスできる宛先にできます。このようなタイプのタグの詳細は、syslogユーティリティのman pageを参照してください。

- priority: メッセージの重大度を定義します。指定できる値は、notice、info、debug、warning、err、crit、alertおよびemergです。

syslogデーモンは、AUDIT_SYSLOG_LEVELパラメータの機能引数に割り当てられた値とsyslog.confファイルを比較し、情報の記録先を決定します。

たとえば、次の文では、機能をlocal1、優先度レベルをwarningとして識別します。

AUDIT_SYSLOG_LEVEL=local1.warning

AUDIT_SYSLOG_LEVELの詳細は、『Oracle Databaseリファレンス』を参照してください。

3. syslog構成ファイル/etc/syslog.confが存在するコンピュータにスーパーユーザー(ルート)権限でログインします。

4. 監査ファイルの宛先をsyslog構成ファイルsyslog.confに追加します。
たとえば、AUDIT_SYSLOG_LEVELをlocal1.warningに設定したとすると、次のように入力します。

local1.warning /var/log/audit.log

この設定では、すべての警告メッセージが/var/log/audit.logファイルに記録されます。

5. syslogログ出力を再起動します。

$/etc/rc.d/init.d/syslog restart

これで、すべての監査レコードがsyslogデーモンを介してファイル/var/log/audit.logに取得されます。

6. データベース・インスタンスを再起動します。

CONNECT SYS / AS SYSOPER
Enter password: password

SHUTDOWN IMMEDIATE
STARTUP

AUDITおよびNOAUDIT SQL文の動作

この項の内容は、次のとおりです。

- AUDIT SQL文による標準監査の使用可能化

- 文の実行の監査: 正常な実行、異常終了した実行またはその両方の監査

- 標準監査レコードの生成の仕組み

- カーソルが標準監査に与える影響

- AUDIT文でBY ACCESS句を使用する利点

- 特定のユーザーが実行したアクションの監査

- NOAUDIT SQL文を使用した監査オプションの解除

関連項目:
AUDIT文の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

AUDIT SQL文による標準監査の使用可能化

標準監査オプションを構成するには、AUDIT SQL文を使用します。

表9-3に、AUDIT文を使用できるカテゴリを示します。

表9-3 標準監査レベルとその影響

レベル

影響

文

特定の型のデータベース・オブジェクトに影響を与える特定のSQL文または文のグループを監査します。たとえば、AUDIT TABLEを実行すると、CREATE TABLE、TRUNCATE TABLE、COMMENT ON TABLEおよびDELETE [FROM] TABLE文が監査されます。

権限

特定のシステム権限によって許可されるSQL文を監査します。たとえば、AUDIT CREATE ANY TRIGGER文を実行すると、CREATE ANY TRIGGERシステム権限を使用して発行された文が監査されます。

オブジェクト

HR.EMPLOYEES表に対するALTER TABLE文など、特定のオブジェクトに対する特定の文を監査します。

ネットワーク

ネットワーク・プロトコルの不測エラーまたはネットワーク・レイヤーの内部エラーを監査します。

文の実行の監査: 正常な実行、異常終了した実行またはその両方の監査

文、権限およびスキーマ・オブジェクトの監査では、文の正常な実行、異常終了した実行、またはその両方の文実行を選択して監査できます。このため、監査対象の文が正常終了しなかった場合にも、アクションを監視できます。異常終了したSQL文を監視することで、アクセス違反や不当な処理を行っているユーザーを判別できます。ただし、異常終了したSQL文の原因はそのどちらでもない場合がほとんどです。

この監査方法は、監査証跡が減少するため特定のアクションに重点を置きやすくなるという点でも役立ちます。これにより、データベースの良好なパフォーマンスを維持できます。

オプションは、次のとおりです。

- WHENEVER SUCCESSFUL句: この句を指定すると、監査対象の文の正常な実行のみが監査されます。

- WHENEVER NOT SUCCESSFUL句: この句を指定すると、監査対象の文の異常終了した実行のみが監査されます。
異常終了した文の監査では、有効なSQL文を実行しても適切な認可がないために異常終了した場合や、存在しないスキーマ・オブジェクトを参照したために異常終了した場合にのみ監査レポートが生成されます。有効ではなかったために異常終了した文は監査できません。

たとえば、異常終了した文の実行を監査するように権限監査オプションが設定されている場合は、対象のシステム権限を使用しても他の原因で異常終了した文が監査されます。1つの例として、CREATE TABLE監査条件を設定したが、指定した表領域に対する割当て制限が不十分だったためにCREATE TABLE文が異常終了した場合などがあります。

- WHENEVER SUCCESSFULまたはWHENEVER NOT SUCCESSFULを省略した場合: これらの句を省略すると、Oracle Databaseでは監査対象の文の正常な実行と異常終了した実行の両方が監査されます。

次に例を示します。

AUDIT CREATE TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;

標準監査レコードの生成の仕組み

Oracle Databaseでは、次のように、監査対象の文または操作が実行されるたびに監査レコードが生成されます。

- 監査が設定されたSQL文が実行されるたび。これには、PL/SQLプロシージャ内でのSQL文の実行も含まれます。

- 監査が構成されている権限が使用されるたび

- 監査が構成されているオブジェクトが操作されるたび

カーソルが標準監査に与える影響

カーソル内で監査対象の操作が実行されるたびに、Oracle Databaseでは監査証跡に監査レコードが1つ挿入されます。カーソルを再利用させるイベントは、次のとおりです。

- カーソルを再利用のためにオープン状態にしておく、Oracle Formsなどのアプリケーション

- 新しいバインド変数を使用したカーソルの継続実行

- 1つのカーソルを再利用するためにPL/SQLエンジンにより文が最適化される場合に、PL/SQLループ内で実行される文

監査は、カーソルが共有されているかどうかの影響を受けません。それぞれのユーザーは、カーソルの最初の実行時に自分の監査証跡レコードを作成します。

AUDIT文でBY ACCESS句を使用する利点

デフォルトでは、Oracle DatabaseはBY ACCESS句の機能を使用して、監査対象イベントごとに新しい監査レコードを書き込みます。この機能を使用するには、AUDIT文にBY ACCESSを指定します。これはデフォルト設定であるため、省略することもできます (Oracle Database 11g リリース2(11.2.0.2)の時点では、BY ACCESS句はデフォルト設定です)。

AUDIT文では、BY SESSIONではなくBY ACCESSを監査することをお薦めします。AUDIT文でBY ACCESS句を使用する利点は、次のとおりです。

- BY ACCESS監査オプションを使用した場合、実行ステータス(リターン・コード)、実行日時、使用された権限、アクセスされたオブジェクト、SQLテキスト自体とそのバインド値など、より多くの情報を含む監査レコードが生成されます。また、BY ACCESS監査オプションを使用すると、実行ごとにSCNが取得されるため、フラッシュバック問合せに役立ちます。

- Oracle Databaseでは、SQL文の各実行、権限の使用および監査対象オブジェクトへのアクセスを個別に記録します。各実行に対してリターン・コード、タイムスタンプおよびSQLテキストの値が正確に記録されることによって、そのアクションの実行回数を特定することが容易になります。

- BY ACCESS監査レコードには、それぞれにファイングレイン・タイムスタンプが付けられたLOGONエントリとLOGOFFエントリが別個に存在します。

次に例を示します。

AUDIT SELECT TABLE BY ACCESS;

この使用例は、次のとおりです。

- ユーザーjwardでデータベースに接続し、departmentsという表に対して5つのSELECT文を発行した後、そのデータベースとの接続を切断します。

- ユーザーswilliamsでデータベースに接続し、departments表に対して3つのSELECT文を発行した後、そのデータベースとの接続を切断します。

監査証跡には、SELECT文ごとに1レコードずつ、8件のレコードが記録されます。

特定のユーザーが実行したアクションの監査

文監査オプションと権限監査オプションでは、任意のユーザーが発行した文を監査するか、特定のユーザー・リストに含まれるユーザーが発行する文を監査するかを選択できます。特定のユーザーに限定すると、生成される監査レコードの数は最小限に抑えられます。

例9-6に、ユーザーscottとblakeが表やビューを問い合せたり更新するときに、ユーザー別に文を監査する方法を示します。

例9-6 AUDITを使用してユーザー・アクションを監査する方法

AUDIT SELECT TABLE, UPDATE TABLE BY scott, blake BY ACCESS;

ユーザー別の監査の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

NOAUDIT SQL文を使用した監査オプションの解除

NOAUDIT文を使用すると、監査オプションが解除されます。このオプションは、文監査オプション、権限監査オプションおよびオブジェクト監査オプションの設定を解除するために使用します。文監査オプションおよび権限監査オプションを設定するNOAUDIT文では、BY user句によってユーザーのリストを指定し、各監査オプションの適用範囲を限定できます。

NOAUDIT文では、WHENEVER句を使用して監査オプションを選択的に使用禁止にできます。この句の指定がない場合は、正常終了と異常終了のどちらの場合にも監査オプションは完全に使用禁止となります。

NOAUDIT文では、BY ACCESS句はサポートされていません。このため、監査オプションは、その設定状況(有効かどうか)に関係なく、適切なNOAUDIT文によって解除できます。

関連項目:
NOAUDIT文の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

SQL文の監査

この項の内容は、次のとおりです。

- SQL文監査の概要

- 監査されるSQL文のタイプ

- SQL文監査の構成

- SQL文監査の解除

SQL文監査の概要

SQL文監査とは、特定タイプのデータベース構造やスキーマ・オブジェクトに関するSQL文の関連グループに対する選択的な監査のことです。ただし、監査の対象として特定の構造やスキーマ・オブジェクトを指定することはできません。

監査されるSQL文のタイプ

監査可能な文は、次のカテゴリに分類されます。

- DDL文。たとえば、AUDIT TABLEはすべてのCREATE文とDROP TABLE文を監査します。

- DML文。たとえば、AUDIT SELECT TABLEは、表かビューかに関係なくすべてのSELECT ... FROM TABLE/VIEW文を監査します。

文監査では、監査の対象を拡大してすべてのデータベース・ユーザーのアクティビティを監査したり、対象を限定して特定のアクティビティ・リストのアクティビティのみを監査できます。

SQL文監査の構成

SQL文監査を構成するには、AUDIT文を使用します。監査を使用可能にするには、AUDIT SYSTEMシステム権限が必要です。通常、このシステム権限はセキュリティ管理者にのみ付与されています。

例9-7に、SELECT TABLE SQL文を監査する方法を示します。

例9-7 AUDITを使用してSQL文監査を使用可能にする方法

AUDIT SELECT TABLE BY ACCESS;

例9-8に、すべての表の異常終了したSELECT、INSERTおよびDELETE文を、全データベース・ユーザーに対して個々の監査対象文別にすべて監査する方法を示します。

例9-8 異常終了した文の監査

AUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE
BY ACCESS
WHENEVER NOT SUCCESSFUL;

すべてのSQL文、個々のユーザー接続または存在しないオブジェクトへの参照を監査する予定の場合は、次のガイドラインに従ってください。

- 個々のユーザーのすべてのSQL文を監査する場合。ALL STATEMENTS句を使用して、トップレベルのSQL文のみを監査できます。この監査オプションの動作は、他の文の監査オプションとは異なります。PL/SQLプロシージャ内から発行されたSQL文は、ALL STATEMENTS監査オプションでは監査されません。この監査オプションは、設定済の他のAUDITオプションには影響しません。
たとえば、ユーザーjwardおよびjsmithによって発行され、正常終了したすべての文を監査するには、次のように入力します。

AUDIT ALL STATEMENTS BY jward, jsmith BY ACCESS WHENEVER SUCCESSFUL;

- 個別のユーザーが実行するすべてのSQL文ショートカット・アクティビティを監査する場合。ALL句を使用すると、『Oracle Database SQL言語リファレンス』の表13-1および表13-2にリストされているすべてのSQL文ショートカットを監査できます。
次に例を示します。

AUDIT ALL BY jward BY ACCESS;

- ユーザーに関係なく、現行セッションのすべてのSQL文を監査する場合。ALL STATEMENTS監査オプションでIN SESSION CURRENT句を使用して、ユーザー・セッションの存続期間におけるトップレベルのSQL文を監査できます。特定のユーザーに対してIN SESSION CURRENT句を使用することはできません。監査はユーザー・セッションが続いているかぎり継続し、NOAUDIT文を使用して取り消すことはできません。ユーザーがセッションを終了すると、監査は終了します。
たとえば、現行ユーザー・セッションにおいて異常終了したすべての文を監査するには、次のように入力します。

AUDIT ALL STATEMENTS IN SESSION CURRENT BY ACCESS WHENEVER NOT SUCCESSFUL;

AUDIT ALL STATEMENTS監査オプションとIN SESSION CURRENT句は、データベース・ログイン・トリガー内に指定できます。データベース・ログイン・トリガーでは、SYS_CONTEXT関数を使用して、午後6時30分から午前9時までの期間のユーザー・ログインなど、特定の条件に限定してこの監査を構成できます。これにより、営業時間外にデータベースにログインしたユーザーによって実行されたSQL文を取得できるようになります。

このタイプの監査は、対象の接続がセキュアでないか、内部の脅威をもたらす疑いがある場合に、監査アクティビティの収集を拡張するのに役立ちます。たとえば、データベース・ログイン・トリガーを使用すると、SYS_CONTEXTファンクションによって接続コンテキストの内容を問い合せることができます。

ログイン・トリガー機能によって、対象の接続についてより徹底した監査を実施できるようになります。次のSQLコマンドを発行します。

AUDIT ALL STATEMENTS IN SESSION CURRENT;

このタイプの監査は、対象のセッションが終了するまで有効です。

- ログイン時とログオフ時の接続と切断を監査する場合。AUDIT SESSION文では、ログイン・イベントとログオフ・イベントごとに独立した監査レコードが生成されます。これにより、ユーザーに関係なく、データベースとの間で正常終了および異常終了した接続と切断をすべて監査できます。
次に例を示します。

AUDIT SESSION BY ACCESS;

次の例に示すように、このオプションはユーザーごとに設定することもできます。

AUDIT SESSION BY jward, jsmith BY ACCESS;

- オブジェクトがないために異常終了した文を監査する場合。AUDIT文のNOT EXISTSオプションを指定して、ターゲット・オブジェクトがないために異常終了したすべてのSQL文を監査できます。
次に例を示します。

AUDIT NOT EXISTS;

AUDIT SQL文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

SQL文監査の解除

SQL文監査を解除するには、NOAUDIT SQL文を使用します。(権限監査は有効のままになります。)SQL文監査を解除するには、AUDIT SYSTEMシステム権限が必要です。AUDIT ALL STATEMENTSオプションを構成した場合は、NOAUDIT AUDIT STATEMENTS文を発行しても、設定してある他の監査オプションへの影響はありません。IN SESSION CURRENT句をAUDIT文に含めた場合は、NOAUDIT文を使用してこのAUDIT文を解除できません。(監査設定は、ユーザーのセッションが終了すると中断します。)

例9-9に、NOAUDIT文を使用して監査を解除する例を示します。

例9-9 NOAUDITを使用してセッションおよびSQL文監査を解除する方法

NOAUDIT session;
NOAUDIT session BY preston, sebastian;
NOAUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE;

例9-10に、NOAUDIT文を使用してすべての文の監査を解除する方法を示します。

例9-10 NOAUDITを使用してすべての文の監査を解除する方法

NOAUDIT ALL STATEMENTS;

NOAUDIT文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

権限の監査

この項の内容は、次のとおりです。

- 権限監査の概要

- 監査可能な権限のタイプ

- 権限監査の構成

- 権限監査の解除

権限監査の概要

権限監査は、SELECT ANY TABLEなど、システム権限を使用する文を監査します。このような種類の監査では、正常に実行するには監査権限が必要なSQL文が記録されます。

監査可能な権限のタイプ

任意のシステム権限の使用を監査できます。文監査と同様に、権限監査では、すべてのデータベース・ユーザーのアクティビティを監査したり、特定のデータベース・ユーザーのアクティビティのみを監査します。

文監査と権限監査の両方について類似の監査オプションを設定しても、生成される監査レコードは1つのみです。たとえば、文の句TABLEとシステム権限のCREATE TABLEの両方を監査すると、表が作成されるたびに監査レコードが1つのみ生成されます。

権限監査は、アクションが既存の所有者およびオブジェクト権限によってすでに許可されている場合は実行されません。権限監査がトリガーされるのは、権限が不十分な場合、つまりアクションを可能にする権限がシステム権限である場合のみです。たとえば、ユーザーSCOTTにSELECT ANY TABLE権限が付与されており、SELECT ANY TABLEが監査対象であるとします。SCOTTが自分の表(たとえば、SCOTT.EMP)を選択した場合、SELECT ANY TABLE権限は使用されません。自分自身のスキーマ内でSELECT文を実行したため、監査レコードは生成されません。一方、SCOTTが他のスキーマ(たとえばHR.EMPLOYEES表)から選択すると、監査レコードが生成されます。SCOTTは自分自身のスキーマ外にある表を選択したため、SELECT ANY TABLE権限を使用する必要がありました。

権限監査は文監査よりも対象が絞られますが、これは各々の権限監査オプションは、文の関連リストではなく、特定タイプの文のみ監査するためです。たとえば、文監査句TABLEはCREATE TABLE文、ALTER TABLE文、およびDROP TABLE文を監査します。ところが権限監査オプションCREATE TABLEが監査するのはCREATE TABLE文のみですが、これはCREATE TABLE文のみがCREATE TABLE権限を必要とするためです。

『Oracle Database SQL言語リファレンス』のGRANT SQL文に関する項のシステム権限のリストを参照してください。

権限監査の構成

権限監査オプションは、対応するシステム権限と同じです。たとえば、DELETE ANY TABLE権限の使用を監査するためのオプションは、DELETE ANY TABLEです。

例9-11に、DELETE ANY TABLE権限を監査する方法を示します。

例9-11 AUDITを使用して権限監査を構成する方法

AUDIT DELETE ANY TABLE BY ACCESS;

DELETE ANY TABLEシステム権限の正常な使用の場合と異常終了した使用の場合をすべて監査するには、次の文を実行します。

AUDIT DELETE ANY TABLE BY ACCESS;

権限監査の解除

権限監査オプションをすべて解除するには、次の文を入力します。

NOAUDIT ALL PRIVILEGES;

この例では、例9-11の監査設定を使用禁止にしています。

NOAUDIT DELETE ANY TABLE;

権限監査オプションを使用禁止にするには、AUDIT SYSTEMシステム権限が必要です。通常、このシステム権限はセキュリティ管理者にのみ付与されています。

複数層環境におけるSQL文および権限の監査

AUDIT文を使用して、複数層環境のクライアントのアクティビティを監査できます。複数層環境では、クライアントの識別情報をすべての層を通して保持できます。したがって、クライアントにかわって中間層アプリケーションにより行われたアクションを、AUDIT文の中でBY user句を使用することで監査できます。監査は、プロキシ・セッションを含むすべてのユーザー・セッションに適用されます。

中間層では、データベース・セッションでユーザーのクライアント識別情報を設定し、中間層アプリケーションでエンド・ユーザーのアクションを監査することもできます。そうすることにより、エンド・ユーザーのクライアント識別情報が監査証跡に記録されます。

例9-12は、ユーザーjacksonによって発行されたSELECT TABLE文を監査する方法を示しています。

例9-12 AUDIT文を使用して、ユーザーのSQL文を監査する方法

AUDIT SELECT TABLE BY jackson;

複数層環境でユーザー・アクティビティを監査できます。監査を開始した後で、DBA_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることでこれらのアクティビティを確認できます。

図9-1に、DBA_AUDIT_TRAILビューのCOMMENT_TEXT、PROXY_SESSIONID、ACTION_NAMEおよびSESSION_ID列を問い合せることで、プロキシ・ユーザーを監査する方法を示します。このシナリオでは、データベース・ユーザーとプロキシ・ユーザーの両方のアカウントがデータベースに認識されます。セッション・プーリングを使用できます。

図9-1 プロキシ・ユーザーの監査

図9-2に、DBA_AUDIT_TRAILデータ・ディクショナリ・ビューのCLIENT_ID列を問い合せることで、複数のデータベース・セッションにわたるクライアント識別子情報を監査する方法を示します。この例では、クライアント識別子はCLIENT_Aに設定されています。図9-1に示すプロキシ・ユーザー/データベース・ユーザーの例と同様に、セッション・プーリングを使用できます。

図9-2 複数のセッションにわたるクライアント識別子情報の監査

関連項目:
複数層環境でのユーザー認証の詳細は、「複数層環境でのユーザー識別情報の保持」を参照してください。

スキーマ・オブジェクトの監査

この項の内容は、次のとおりです。

- スキーマ・オブジェクト監査の概要

- 監査可能なスキーマ・オブジェクトのタイプ

- 標準監査とエディション付きオブジェクトの併用

- ビュー、プロシージャおよびその他の要素のスキーマ・オブジェクト監査オプション

- スキーマ・オブジェクト監査の構成

- オブジェクト監査の解除

- 将来作成される可能性のあるオブジェクトに対する監査オプションの設定

スキーマ・オブジェクト監査の概要

スキーマ・オブジェクト監査では、表やビューなど、監査対象のオブジェクトに対して実行されるアクションが監視されます。オブジェクト監査はすべてのユーザーに適用されますが、監査対象のオブジェクトのみに限定されます。ユーザーは、自分のスキーマ内のオブジェクトに対してAUDITおよびNOAUDIT文を使用できます。

監査可能なスキーマ・オブジェクトのタイプ

監査できる文は表、ビュー、順序、スタンドアロンのストアド・プロシージャまたはファンクション、およびパッケージを参照する文です。パッケージ内の個々のプロシージャを参照する文は監査できません。(これらのタイプのオブジェクトの監査の詳細は、「ファンクション、プロシージャ、パッケージおよびトリガーの監査」を参照してください。)

クラスタ、データベース・リンク、索引またはシノニムを参照する文は、直接監査できません。ただし、実表に影響を与える操作を監査することによって、これらのスキーマ・オブジェクトへのアクセスを間接的に監査できます。

スキーマ・オブジェクトを監査する場合、監査はデータベースのすべてのユーザーに適用されます。これらのオプションは、特定のユーザーのリストに対しては設定できません。監査対象のすべてのスキーマ・オブジェクトに対して、デフォルトのスキーマ・オブジェクト監査オプションを設定できます。

関連項目:
監査対象のスキーマ・オブジェクトの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

標準監査とエディション付きオブジェクトの併用

エディション付きオブジェクトに監査ポリシーが付加されている場合、そのオブジェクトが表示されるすべてのエディションにそのポリシーが適用されます。エディション付きオブジェクトが実現化されると、そのオブジェクトに付加されている監査ポリシーが新しい実際のオブジェクトに新たに付加されます。継承されたエディション付きオブジェクトに新たに監査ポリシーを適用すると、そのオブジェクトが実現化されます。

監査対象のオブジェクトが表示されるエディションを調べるには、DBA_COMMON_AUDIT_TRAILおよびV$XML_AUDIT_TRAILデータ・ディクショナリ・ビューのOBJECT_NAMEおよびOBJ_EDITION_NAME列を問い合せます。

関連項目:
エディションの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

ビュー、プロシージャおよびその他の要素のスキーマ・オブジェクト監査オプション

ビューとプロシージャ(ストアド・ファンクション、パッケージおよびトリガーを含む)の定義は、基礎となるスキーマ・オブジェクトを参照します。この依存性があるために、複数の監査レコードが生成される場合があるなど、ビューとプロシージャの監査には、固有の特性がいくつかあります。

ビューとプロシージャは、デフォルトの監査オプションも含め、ベース・スキーマ・オブジェクトで使用可能な監査オプションに依存します。これらのオプションは、結果のSQL文にも適用されます。

次の一連のSQL文について考えてみます。

AUDIT SELECT ON HR.EMPLOYEES BY ACCESS;

CREATE VIEW employees_departments AS
SELECT employee_id, last_name, department_id
FROM employees, departments
WHERE employees.department_id = departments.department_id;

AUDIT SELECT ON employees_departments BY ACCESS;

SELECT * FROM employees_departments;

employees_departmentsビューでの問合せの結果、2つの監査レコードが生成されます。1つはemployees_departmentsビューでの問合せに対するレコードで、もう1つは実表employeesでの(employees_departmentsビューを通して間接的な)問合せに対するレコードです。実表departmentsでの問合せでは、この表のSELECT監査オプションが有効ではないため、監査レコードが生成されません。すべての監査レコードが、employees_departmentsビューを問い合せたユーザーに関連するものです。

前述の例で、AUDIT SELECT ON HR.EMPLOYEES;文を削除すると、employees_departmentsビューを使用しても、EMPLOYEES表の監査レコードは生成されません。

スキーマ・オブジェクト監査の構成

AUDIT文を使用して、現行エディションにオブジェクト監査を構成できます。AUDITに有効なオブジェクト監査オプションと、各オプションが使用できるスキーマ・オブジェクトのタイプの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ユーザーは、自分のスキーマ内にあるオブジェクトのオブジェクト監査オプションを設定できます。他のユーザーのスキーマ内にあるオブジェクトのオブジェクト監査オプションを設定したり、デフォルトのオブジェクト監査オプションを設定するには、AUDIT ANYシステム権限が必要です。通常、AUDIT ANY権限はセキュリティ管理者にのみ付与されています。

図9-2に、laurel.emp表に対する正常終了および異常終了したDELETE文をすべて監査する方法を示します。

例9-13 スキーマ表の監査の構成

AUDIT DELETE ON laurel.emp BY ACCESS;

例9-14に、ユーザーjwardが所有するdept表に対する正常終了したSELECT、INSERTおよびDELETE文をすべて監査する方法を示します。

例9-14 スキーマ表に対する正常終了した文の監査

AUDIT SELECT, INSERT, DELETE
ON jward.dept
BY ACCESS
WHENEVER SUCCESSFUL;

例9-15に、ON DEFAULT句を使用して、AUDIT文の設定後に作成された新規オブジェクト(表、ビューおよび順序)に適用する方法を示します。この例では、将来作成される新規オブジェクトが、異常終了したすべてのSELECT文について監査されます。

例9-15 DEFAULT句を使用して新規オブジェクトの監査を構成する方法

AUDIT SELECT
ON DEFAULT
BY ACCESS
WHENEVER NOT SUCCESSFUL;

例9-16に、PL/SQLプロシージャまたはファンクションの実行を監査する方法を示します。

例9-16 プロシージャまたはファンクションの実行の監査

AUDIT EXECUTE ON sec_mgr.auth_orders BY ACCESS;

オブジェクト監査の解除

オブジェクト監査を解除するには、NOAUDIT文を使用します。対応する監査オプションを使用禁止にするには、次の文を実行します。

NOAUDIT DELETE
ON emp;
NOAUDIT SELECT, INSERT, DELETE
ON jward.dept;

emp表に対するオブジェクト監査オプションをすべて解除するには、次の文を入力します。

NOAUDIT ALL ON emp;

デフォルトのオブジェクト監査オプションをすべて解除するには、次の文を入力します。

NOAUDIT ALL ON DEFAULT;

このNOAUDIT文を発行する前に作成されたすべてのスキーマ・オブジェクトは、作成後にNOAUDIT文を使用して明示的に設定を変更しないかぎり、引き続き作成時に指定されたデフォルトのオブジェクト監査オプションが使用されます。

特定のオブジェクトのオブジェクト監査オプションを解除するには、そのスキーマ・オブジェクトの所有者であることが必要です。他のユーザーのスキーマ内にあるオブジェクトのオブジェクト監査オプションや、デフォルトのオブジェクト監査オプションを解除するには、AUDIT ANYシステム権限が必要です。オブジェクトのオブジェクト監査オプションを解除する権限を持っているユーザーは、他のユーザーによって設定されたオプションを変更できます。

将来作成される可能性のあるオブジェクトに対する監査オプションの設定

作成される表の挿入や削除など、まだ存在しないオブジェクトに対する監査設定を作成できます。これには2つの方法があります。一方の方法は、AUDIT文で文監査オプションを使用することです。たとえば、将来の表に対するすべての挿入を監査するには、次のSQL文を実行します。

AUDIT INSERT TABLE BY ACCESS;

他方の方法は、ON DEFAULT句を使用してAUDIT文を起動することです。次に例を示します。

AUDIT ALL ON DEFAULT BY ACCESS;

この文では、デフォルトで以降のすべてのオブジェクト作成文が監査されます。ONキーワードは、オブジェクト監査を指定します。ON DEFAULT句では、以降に作成されて次の文の影響を受けるオブジェクトの監査を構成します。

文A-D

文E-I

文I-R

文S-Y

ALTER

EXECUTE

INSERT

SELECT

AUDIT

GRANT

LOCK

UPDATE

COMMENT

FLASHBACK

READ

-

DELETE

INDEX

RENAME

-

ON DEFAULTを特定のアクションに限定するには、次のような文を入力します。

AUDIT ALTER, DELETE ON DEFAULT BY ACCESS;

監査オプションとAUDIT SQL文のON DEFAULT句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。デフォルトで監査対象となるオブジェクトを検索するには、ALL_DEF_AUDIT_OPTSデータ・ディクショナリ・ビューを問い合せます。

ディレクトリ・オブジェクトの監査

この項の内容は、次のとおりです。

- ディレクトリ・オブジェクト監査の概要

- ディレクトリ・オブジェクト監査の構成

- ディレクトリ・オブジェクト監査の解除

ディレクトリ・オブジェクト監査の概要

ディレクトリ・オブジェクトは監査可能です。たとえば、ORACLE_LOADERアクセス・ドライバで使用されるプリプロセッサ・プログラムを含むディレクトリ・オブジェクトを作成するとします。ディレクトリ・オブジェクト内のこのプログラムを実行するすべてのユーザーを監査できます。

ディレクトリ・オブジェクト監査の構成

オブジェクト監査を使用可能にするには、AUDIT文を使用します。例9-17に、ディレクトリ・オブジェクトmy_execに対するEXECUTE権限を監査する方法を示します。

例9-17 ディレクトリ・オブジェクトの監査

AUDIT EXECUTE ON DIRECTORY my_exec BY ACCESS;

ディレクトリ・オブジェクト監査の解除

ディレクトリ・オブジェクト監査を使用禁止にするには、NOAUDIT文を使用します。次に例を示します。

NOAUDIT EXECUTE ON DIRECTORY my_exec;

ファンクション、プロシージャ、パッケージおよびトリガーの監査

この項の内容は、次のとおりです。

- ファンクション、プロシージャ、パッケージおよびトリガーの監査の概要

- ファンクション、プロシージャ、パッケージおよびトリガーの監査の構成

- ファンクション、プロシージャ、パッケージおよびトリガーの監査の解除

ファンクション、プロシージャ、パッケージおよびトリガーの監査の概要

ファンクション、プロシージャ、PL/SQLパッケージおよびトリガーを監査できます。監査可能な領域は次のとおりです。

- スタンドアロン・ファンクション、スタンドアロン・プロシージャおよびPL/SQLパッケージは個別に監査できます。

- PL/SQLパッケージを監査すると、パッケージ内のすべてのファンクションおよびプロシージャが監査されます。

- すべての実行の監査を使用可能にすると、データベース内のすべてのトリガーおよびPL/SQLパッケージ内のすべてのファンクションとプロシージャが監査されます。

- PL/SQLパッケージ内のファンクションまたはプロシージャを個別に監査することはできません。

Oracle Virtual Privateデータベース・ポリシーに関連付けられているファンクションを監査する場合は、次のことに注意してください。

- 動的ポリシー: ポリシー関数が2回(SQL文の解析時に1回と実行時に1回)評価されます。結果として、各評価で2つの監査レコードが生成されます。

- 静的ポリシー: ポリシー関数が1回評価され、SGA内にキャッシュされます。これにより、監査レコードは1つのみ生成されます。

- 状況依存ポリシー: ポリシー関数が文の解析時に1回実行されます。これにより、監査レコードは1つのみ生成されます。

ファンクション、プロシージャ、パッケージおよびトリガーの監査の構成

例9-18に、データベースの任意のユーザーによるファンクション、プロシージャ、パッケージまたはトリガーの実行を監査する方法を示します。

例9-18 すべてのファンクション、プロシージャ、パッケージおよびトリガーの監査

AUDIT EXECUTE PROCEDURE BY ACCESS;

例9-19に、ユーザーpsmithによるファンクション、プロシージャ、パッケージおよびトリガーの正常終了および異常終了した実行を監査する方法を示します。

例9-19 ユーザーによるファンクション、プロシージャ、パッケージおよびトリガーの実行の監査

AUDIT EXECUTE PROCEDURE BY psmith BY ACCESS;

例9-20に、sales_dataスキーマ内のcheck_workという名前のスタンドアロン・プロシージャを監査する方法を示します。この方法は、スタンドアロン・ファンクションにも適用されます。

例9-20 スキーマ内のプロシージャまたはファンクションの実行の監査

AUDIT EXECUTE ON sales_data.check_work BY ACCESS WHENEVER SUCCESSFUL;

ファンクション、プロシージャ、パッケージおよびトリガーの監査の解除

ファンクション、プロシージャおよびトリガーの監査を解除するには、NOAUDIT文を使用します。次に例を示します。

NOAUDIT EXECUTE PROCEDURE;

NOAUDIT EXECUTE PROCEDURE BY psmith;

NOAUDIT EXECUTE ON sales_data.checkwork;

ネットワーク・アクティビティの監査

この項の内容は、次のとおりです。

- ネットワーク監査の概要

- ネットワーク監査の構成

- ネットワーク監査の解除

ネットワーク監査の概要

AUDIT文を使用して、ネットワーク・プロトコルの予期しないエラーやネットワーク層で発生した内部エラーを監査できます。ネットワーク監査によって、ネットワーク上のクライアントとの通信中に発生するエラーが取得されます。これらのエラーは、SQL*Netドライバによってスローされます。ネットワーク・エラーの原因には様々なものがあります。たとえば、データベース・エンジニアがテスト目的で設定した内部イベントがネットワーク・エラーの原因になることもあります。他にも、ネットワークが暗号化の作成または処理に必要な情報を見つけられないなど、暗号化の構成設定の競合などが原因として考えられます。ネットワーク監査で発見されるエラー(ACTION 122 ネットワーク・エラーなど)は接続障害ではありません。ネットワーク監査で対象となるのは、ネットワーク上を移動するデータに限られます。

ネットワーク監査の監査レコードでは、監査レコードのCOMMENT_TEXTフィールドにクライアント(使用可能な場合)の認証タイプとSQL*Netアドレスが次の形式でリストされます。

Authenticated by: authentication_type; Client Address: SQLNetAddress_of_client

Client Address: SQLNetAddress_of_client部分は、この情報が使用可能な場合にのみ表示されます。

表9-4に、4つの一般的なエラー状況の解決方法を示します。

表9-4 監査可能なネットワーク・エラーの状況

エラー

原因

処置

TNS-02507

暗号化: アルゴリズムがインストールされていません

アルゴリズムの選択後、サーバーはアルゴリズムの表でその索引を見つけることができませんでした。アルゴリズムが(間接的に)このリストから選択されているため、処理ができません。

詳細を調べるためにトレースをオンにしてから、操作を再実行してください。(このエラーは、通常はユーザーに表示されません。)エラーが解決しない場合は、Oracleサポート・サービスまでお問い合せください。

TNS-12648

暗号化またはデータ整合性アルゴリズム・リストが空です。

Oracle Advanced Securityのアルゴリズム・リスト・パラメータが空です。

インストールされているアルゴリズムのうち、少なくとも1つのアルゴリズム名が含まれるようにリストを変更するか、インストールされているすべてのアルゴリズムが許容できない場合は、リスト全体を削除します。

TNS-12649

不明な暗号化またはデータ整合性のアルゴリズムです。

Oracle Advanced Securityのアルゴリズム・リスト・パラメータに、認識されていないアルゴリズム名が含まれています。

アルゴリズム名を削除、スペルが間違っている場合はスペルを修正、あるいは欠落しているアルゴリズムのドライバをインストールします。

TNS-12650

共通の暗号化またはデータ整合性アルゴリズムがありません。

クライアントとサーバーには、暗号化またはデータ整合性、あるいはこれら両方についての共通のアルゴリズムがありません。

共通のアルゴリズム・セットを選択します。つまり、クライアント・アルゴリズムの選択肢の1つをサーバー・リストに追加するか、サーバー・リストの選択肢の1つをクライアント・アルゴリズムに追加します。

ネットワーク監査の構成

ネットワーク監査を構成するには、AUDIT文を使用します。次に例を示します。

AUDIT NETWORK BY ACCESS;

ネットワーク監査の解除

ネットワーク監査を解除するには、次の文を使用します。

NOAUDIT NETWORK;

セキュリティに関連するSQL文および権限に対するデフォルト監査の使用

この項の内容は、次のとおりです。

- デフォルトの監査設定の概要

- Oracle Databaseがデフォルトで監査する権限

- デフォルト監査設定の無効化および有効化

デフォルトの監査設定の概要

Database Configuration Assistant (DBCA)を使用して、新しいデータベースを作成する場合、Oracle Databaseはセキュリティに関連する最も一般的に使用されるSQL文と権限を監査するようにデータベースを構成します。また、AUDIT_TRAIL初期化パラメータをDBに設定します。別の監査証跡のタイプ(たとえば、監査証跡レコードをオペレーティング・システム・ファイルに記録する場合はOS)を使用する場合は、そのような設定もでき、Oracle Databaseは、デフォルトで監査された権限を引き続き監査します。AUDIT_TRAILパラメータをNONEに設定して監査を無効にすると、監査は実行されません。

If データベースを手動で作成した後、secconf.sqlスクリプトを実行して、デフォルト監査設定をデータベースに適用する必要があります。詳細は、「デフォルト監査設定の無効化および有効化」を参照してください。

SQL文および権限の監査を個別に制御するには、AUDIT文とNOAUDIT文を使用します。詳細は、「SQL文の監査」および「権限の監査」を参照してください。

Oracle Databaseがデフォルトで監査する権限

Oracle Databaseでは、デフォルトで次の権限が監査されます。

権限A-C

権限C-D

権限D-G

ALTER ANY PROCEDURE

CREATE ANY LIBRARY

DROP ANY TABLE

ALTER ANY TABLE

CREATE ANY PROCEDURE

DROP PROFILE

ALTER DATABASE

CREATE ANY TABLE

DROP USER

ALTER PROFILE

CREATE EXTERNAL JOB

EXEMPT ACCESS POLICY

ALTER SYSTEM

CREATE PUBLIC DATABASE LINK

GRANT ANY OBJECT PRIVILEGE

ALTER USER

CREATE SESSION

GRANT ANY PRIVILEGE

AUDIT SYSTEM

CREATE USER

GRANT ANY ROLE

CREATE ANY JOB

DROP ANY PROCEDURE

-

Oracle Databaseでは、デフォルトで次のSQLショートカットが監査されます。

ショートカットD-P

ショートカットP-R

ショートカットS

DATABASE LINK

PUBLIC SYNONYM

SYSTEM AUDIT

PROFILE

ROLE

SYSTEM GRANT

関連項目:

- この項で説明するSQL文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
AUDIT文で使用できるSQLショートカットのリストは、『Oracle Database SQL言語リファレンス』のsql_statement_shortcutに関する項を参照してください。

デフォルト監査設定の無効化および有効化

アプリケーションでOracle Database 10g リリース2(10.2)のデフォルトの監査設定を使用している場合、リリース11gの監査設定を使用するようにアプリケーションを変更するまでは、設定の復元が可能です。そのためには、undoaud.sqlスクリプトを実行します。

リリース11gの監査設定に準拠するようにアプリケーションを変更した後は、データベースを手動で更新して、実際のビジネス・ニーズに合った監査構成を使用することも、secconf.sqlスクリプトを実行して、リリース11gのデフォルトの監査設定を適用することもできます。必要に応じて、異なるセキュリティ設定を使用するようにこのスクリプトをカスタマイズできますが、元のスクリプトにリストされている設定は、Oracle推奨の設定であることに注意してください。

データベースを手動で作成した場合は、secconf.sqlスクリプトを実行して、リリース11gのデフォルト監査設定をデータベースに適用する必要があります。Database Configuration Assistantを使用して作成されたデータベースではこの設定が使用されますが、手動で作成したデータベースでは使用されません。

undoaud.sqlおよびsecconf.sqlスクリプトは、$ORACLE_HOME/rdbms/adminディレクトリにあります。undoaud.sqlスクリプトは監査設定にのみ影響し、secconf.sqlスクリプトは監査設定とパスワード設定の両方に影響します。いずれも他のセキュリティ設定には影響を与えません。

ファイングレイン監査を使用した特定のアクティビティの監査

この項の内容は、次のとおりです。

- ファイングレイン監査の概要

- ファイングレイン監査レコードが格納される場所

- ファイングレイン監査の利点

- ファイングレイン監査ポリシーの作成に必要な権限

- ファイングレイン監査で常に監査されるアクティビティ

- ファイングレイン監査ポリシーとエディションの併用

- ファイングレイン監査レコードの監査証跡の作成

- ファイングレイン監査証跡レコードの生成の仕組み

- DBMS_FGAパッケージを使用したファイングレイン監査ポリシーの管理

- 例: ファイングレイン監査ポリシーへの電子メール・アラートの追加

- 例: 非データベース・ユーザーの監査

ファイングレイン監査の概要

ファイングレイン監査では、ポリシーを作成して、監査が実行される特定の条件を定義できます。これにより、内容に基づいてデータ・アクセスを監視できるようになります。問合せと、INSERT、UPDATE、およびDELETE操作に対して詳細な監査を提供します。たとえば、中央の税務当局は、所員による権限外の閲覧を防止するために、どのデータがアクセスされたかを判断できる十分な詳細を使用して納税申告書へのアクセスを追跡する必要があります。特定の表に対して特定のユーザーによってSELECT権限が使用されたことを知るのみでは不十分です。ファイングレイン監査によって、完全な監視機能が実現します。

通常、ファイングレイン監査ポリシーは、選択的監査の条件である、表オブジェクトに対する単純なユーザー定義SQL述語に基づいています。フェッチ中に行がポリシーの条件を満たすと、その問合せが監査対象となります。

ファイングレイン監査を使用すると、次のタイプのアクションを監査できます。

- 午後9時から午前6時の間、または土曜日と日曜日に表にアクセスする場合

- 社内ネットワーク外部のIPアドレスを使用する場合

- 表の列を選択または更新する場合

- 表の列の値を変更する場合

注意:

- ファイングレイン監査は、コストベースの最適化でのみサポートされています。ルールベースの最適化を使用する問合せでは、行フィルタを適用する前にファイングレイン監査が行われるため、不要な監査イベント・トリガーが発生します。

- フラッシュバック問合せに含まれるオブジェクトで現在有効なポリシーが、指定したフラッシュバック・スナップショット(時間またはシステム変更番号(SCN)に基づく)から戻されたデータに適用されます。

- ファイングレイン監査を使用して直接ロードされるデータを監査する場合(たとえばOracle Warehouse Builderを使用してDML文を実行する場合)、Oracle Databaseは透過的にデータベース・インスタンスで実行されているすべてのダイレクト・ロードを従来型ロードにします。データのダイレクト・ロードを保持する場合は、かわりに標準監査を使用することを検討してください。

ファイングレイン監査レコードが格納される場所

ファイングレイン監査レコードは、SYS.FGA_LOG$表に格納されます。有効な監査ポリシーに対して生成されたレコードを検索するには、DBA_FGA_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。DBA_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビューは、標準監査とファイングレイン監査の両方のログ・レコードを結合します。また、V$XML_AUDIT_TRAILビューを問い合せて、XML形式のファイルに書き込まれたファイングレイン監査レコードを検索できます。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

Oracle Databaseは、SYS.FGA_LOG$ (およびSYS.AUD$)表に対するDELETE、INSERT、UPDATE、およびMERGE操作を常に監査し、SYS.AUD$表に記録します。監査レコードは、ユーザーSYSが操作を実行する場合を除いて削除できません。AUDIT_SYS_OPERATIONS初期化パラメータをTRUEに設定した場合は、ユーザーSYSの操作が監査されます。この場合、すべてのSYS操作の監査レコードは、AUDIT_FILE_DEST初期化パラメータが指しているディレクトリに書き込まれます。AUDIT_FILE_DESTが設定されていない場合、レコードが書き込まれる場所はオペレーティング・システムによって異なります。

ファイングレイン監査の利点

ファイングレイン監査を実行すると、監査対象に指定したアクションのみを含む、より有用な監査証跡を作成できます。各表へのアクセスが記録された場合に生じる不要な情報が排除されます。ファイングレイン監査には、標準監査と比べて次のような利点があります。

- ブール条件のチェックが実行されます。指定したブール条件と一致すると(表が土曜日にアクセスされているなど)、監査が行われます。

- 監査をトリガーしたSQLが取得されます。監査が行われたSQL文と関連バインド変数の両方を取得できます。取得できるのは、スカラー列型のデータのみであることに注意してください。オブジェクト列、LOBまたはユーザー定義の列型のデータは取得できません。たとえば、次の問合せを考えてみます。

SELECT NAME FROM EMPLOYEE WHERE SSN = :1

この例で、:1が整数型でSSNの値が987654321の場合は、監査証跡でこの情報を取得できます。ただし、:1がBLOB、CLOB、オブジェクトまたはユーザー定義の型の場合、この情報は取得できません。

この機能を使用できるのは、DBMS_FGA.ADD_POLICY PL/SQLプロシージャのaudit_trailパラメータをDB+EXTENDEDまたはXML+EXTENDEDに設定してファイングレイン監査ポリシーを作成する場合です。

- 機密情報が含まれた列に特別な保護を追加します。給与または社会保障番号など、機密情報が格納されている可能性のある特定の関連列を監査できます。

- イベント処理機能が提供されます。たとえば、夜中に変更されないようにする必要がある監査対象の列が更新された場合に、セキュリティ管理者に電子メール・アラートを送信する関数を作成できます。

- ファイングレイン監査を使用可能にするために初期化パラメータを設定する必要がありません。AUDIT_TRAILなどの初期化パラメータを設定するかわりに、DBMS_FGA PL/SQLパッケージを使用して、監視する特定の操作またはオブジェクトに適用するファイングレイン監査ポリシーを必要に応じて追加および削除します。

ファイングレイン監査ポリシーの作成に必要な権限

ファイングレイン監査ポリシーを作成するには、DBMS_FGA PL/SQLパッケージに対するEXECUTE権限が必要です。パッケージは、SYSユーザーが所有します。

ファイングレイン監査で常に監査されるアクティビティ

SYS.AUD$表には、非SYSユーザーがSYS.FGA_LOG$表に対して実行したINSERT、UPDATE、MERGE、DELETEなど、すべてのデータ操作言語(DML)文が記録されます。これらのアクティビティが実行されるSYS.FGA_LOG$表に対して監査が構成されていない場合でも、監査は実行されます。これらのアクティビティを調べるには、DBA_FGA_AUDIT_TRAILビューおよびDBA_COMMON_AUDIT_TRAILビューを問い合せます。「標準監査レコードおよびファイングレイン監査レコードに常に書き込まれるアクティビティ」も参照してください。

ファイングレイン監査ポリシーとエディションの併用

アプリケーションをエディションベースの再定義用に準備し、アプリケーションで使用される各表をエディショニング・ビューで保護する場合は、これらの表を保護するファイングレイン監査ポリシーをエディショニング・ビューに移動する必要があります。

ファイングレイン監査レコードの監査証跡の作成

監査ポリシーの作成時に、DBMS_FGA.ADD_POLICYポリシーのaudit_trailパラメータ(AUDIT_TRAIL初期化パラメータではない)を設定して、ファイングレイン監査の監査証跡の形式を指定します。このパラメータをXMLまたはXML+EXTENDEDに設定すると、レコードはXML形式でオペレーティング・システム・ファイルに書き込まれます。ファイングレイン監査レコードをSYS.FGA_LOG$表に書き込む場合は、DBMS_FGA.ADD_POLICYパラメータのaudit_trailパラメータをDBまたはDB+EXTENDEDに設定します。監査レコードをオペレーティング・システム・ファイルに書き込むことが有益な理由のリストは、「オペレーティング・システム監査証跡の利点」を参照してください。

V$XML_AUDIT_TRAILデータ・ディクショナリ・ビューを使用すると、DBAはSQL問合せを介してXMLファイルの監査レコードを使用できるため、使いやすさが向上します。このビューを問い合せると、AUDIT_FILE_DESTディレクトリ内のすべてのXMLファイル(.xml格納子を持つすべてのファイル)が解析され、リレーショナル表の形式で表示されます。

DBA_COMMON_AUDIT_TRAILビューには、標準およびファイングレイン監査レコードのV$XML_AUDIT_TRAIL動的ビューの内容が含まれます。

監査XMLファイルは、すべてのプラットフォームで.xml拡張子を持つファイルに格納されるため、動的ビューには、すべてのプラットフォームで監査情報が同じように表示されます。V$XML_AUDIT_TRAILビューの内容の詳細は、『Oracle Databaseリファレンス』を参照してください。

注意:
機密データを含む表を監査する場合は、DBMS_FGA.ADD_POLICY audit_trailパラメータのDB+EXTENDEDおよびXML+EXTENDED設定によりこのデータが取得されることに注意してください。この状況に対処する方法は、「機密情報の監査」を参照してください。

ファイングレイン監査証跡レコードの生成の仕組み

ファイングレイン監査証跡では、SQL文内の表またはビューの参照ごとに監査レコードが取得されます。たとえば、HR.EMPLOYEES表を2回参照するUNION文を実行した場合、文の監査ポリシーによって2つ(HR.EMPLOYEES表へのアクセスごとに1つ)の監査レコードが生成されます。

DBMS_FGAパッケージを使用したファイングレイン監査ポリシーの管理

この項の内容は、次のとおりです。

- DBMS_FGA PL/SQLパッケージの概要

- ファイングレイン監査ポリシーの作成

- ファイングレイン監査ポリシーを使用可能および使用禁止にする方法

- ファイングレイン監査ポリシーの削除

DBMS_FGA PL/SQLパッケージの概要

ファイングレイン監査ポリシーを管理するには、DBMS_FGA PL/SQLパッケージを使用します。このパッケージを使用すると、SELECT、INSERT、UPDATEおよびDELETE文のすべての組合せを1つのポリシーに追加できます。また、基礎となるアクションのINSERTおよびUPDATEを監査することによって、MERGE文も監査できます。MERGE文を監査するには、INSERTおよびUPDATE文に対するファイングレイン・アクセスを構成します。成功したMERGE操作についてポリシーごとにレコードが1つのみ生成されます。ファイングレイン監査ポリシーを管理するには、DBMS_FGAパッケージに対するEXECUTE権限が必要です。

監査ポリシーは、監査ポリシーを作成した表にバインドされます。この結果、ポリシーの変更は、アプリケーションごとにではなくデータベースで1回のみで済むため、監査ポリシーの管理が容易になります。また、データベースへの接続方法(接続元がアプリケーション、Webインタフェース、SQL*PlusやOracle SQL Developerのいずれであるか)に関係なく、ポリシーに影響を与えるアクションがすべて記録されます。

問合せから戻された行が定義した監査条件と一致すると、ファイングレイン監査証跡に監査エントリが挿入されます。このエントリでは、通常の監査証跡でレポートされるすべての情報が除外されます。つまり、TRUEと評価されたすべてのファイングレイン監査ポリシーに対して、1行の監査情報のみが監査証跡に挿入されます。

DBMS_FGAパッケージの構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』も参照してください。

注意:
DBMS_FGAパッケージ・ポリシーを異なる複数のエディションで使用する場合、ポリシーの結果を制御できます。つまり、結果をすべてのエディションで同一にするか、またはポリシーが使用されているエディションに固有にすることができます。詳細は、「エディションがグローバル・アプリケーション・コンテキストのPL/SQLパッケージの結果に与える影響」を参照してください。

ファイングレイン監査ポリシーの作成

ファイングレイン監査ポリシーを作成するには、DBMS_FGA.ADD_POLICYプロシージャを使用します。このプロシージャは、監査条件として提供された述語を使用して、監査ポリシーを作成します。ポリシーの述語は、ポリシーを作成したユーザーの権限で実行されます。表オブジェクトまたはビュー・オブジェクトに設定可能なファイングレイン・ポリシーの最大数は256です。Oracle Databaseでは、ポリシーはデータ・ディクショナリ表に格納されますが、SYSスキーマ内に存在しない表またはビューに関するポリシーを作成できます。

作成したファイングレイン監査ポリシーは特定のスキーマには属しておらず、その定義はSYS.FGA$データ・ディクショナリ表に格納されています。

ファイングレイン監査ポリシーを作成後に変更することはできません。ポリシーの変更が必要になった場合は、削除してから再作成します。

表の列にファイングレイン監査ポリシーが含まれている場合は、(UPDATE文を使用して)この列を暗号化することも復号化することもできないことに注意してください。実行した場合、ORA-28133「完全な表アクセスがファイングレイン・セキュリティによって制限されています」エラーが発生します。列を更新する場合は、まずファイングレイン監査ポリシーを一時的に無効にし、それから列を暗号化または復号化します。その後に、ファイングレイン監査ポリシーを再有効化します。詳細は、「ファイングレイン監査ポリシーの無効化および有効化」を参照してください。

ADD_POLICYプロシージャの構文は、次のとおりです。

DBMS_FGA.ADD_POLICY(
object_schema      VARCHAR2,
object_name        VARCHAR2,
policy_name        VARCHAR2,
audit_condition    VARCHAR2,
audit_column       VARCHAR2,
handler_schema     VARCHAR2,
handler_module     VARCHAR2,
enable             BOOLEAN,
statement_types    VARCHAR2,
audit_trail        BINARY_INTEGER IN DEFAULT,
audit_column_opts  BINARY_INTEGER IN DEFAULT);

次のように値を指定します。

- object_schema: 監査するオブジェクトのスキーマを指定します。(NULLの場合、現行のログイン・ユーザーのスキーマと想定されます。)

- object_name: 監査するオブジェクトの名前を指定します。

- policy_name: 作成するポリシーの名前を指定します。この名前は必ず一意にしてください。

- audit_condition: 行のブール条件を指定します。NULLも指定できます(TRUEとして機能します)。詳細は、「特定の列および行の監査」を参照してください。監査条件にNULLを指定するか、何も指定しない場合は、そのポリシーが設定された表に対するアクションが行われると、行が戻されるかどうかに関係なく監査レコードが作成されます。
次のガイドラインに従ってください。

- ファンクションは、同じ実表で監査可能な文を実行するため、audit_condition設定に含めないでください。たとえば、HR.EMPLOYEES表に対してINSERT文を実行するファンクションを作成するとします。ポリシーのaudit_conditionには、このファンクションが含まれていて、これは(statement_typesにより設定される)INSERT文のポリシーです。このポリシーが使用されると、ファンクションはシステムのメモリーが足りなくなるまで再帰的に実行します。これにより、 ORA-1000: 最大オープン・カーソル数を超えました。または ORA-00036: 再帰的SQLレベルの最大値(50)を超えましたのエラーが発生する場合があります。

- DBMS_FGA.ENABLE_POLICY文またはDBMS_FGA.DISABLE_POLICY文を、ポリシーの条件に含まれるファンクションから発行しないでください。

- audit_column: 監査対象の1つ以上の列(非表示列も含む)を指定します。NULLに設定するかまたは省略すると、すべての列が監査されます。Oracle Label Securityの非表示列やオブジェクト・タイプ列も対象になります。デフォルトのNULLでは、列へのアクセスや影響があった場合に監査が行われます。

- handler_schema: ポリシーに違反した場合の応答のトリガーにアラートが使用される場合は、イベント・ハンドラが含まれているスキーマの名前を指定します。デフォルトのNULLでは、現行のスキーマが使用されます。「例: ファイングレイン監査ポリシーへの電子メール・アラートの追加」も参照してください。

- handler_module: イベント・ハンドラの名前を指定します。イベント・ハンドラが含まれるパッケージも対象になります。このファンクションは、問合せの監査条件と一致する最初の行が処理された後でのみ実行されます。
次のガイドラインに従ってください。

- 再帰的ファイングレイン監査ハンドラを作成しないでください。たとえば、HR.EMPLOYEES表に対してINSERT文を実行するハンドラを作成するとします。このハンドラに関連付けられるポリシーは、(statement_typesパラメータにより設定される)INSERT文のポリシーです。このポリシーが使用されると、ハンドラはシステムのメモリーが足りなくなるまで再帰的に実行します。これにより、 ORA-1000: 最大オープン・カーソル数を超えました。または ORA-00036: 再帰的SQLレベルの最大値(50)を超えましたのエラーが発生する場合があります。

- DBMS_FGA.ENABLE_POLICY文またはDBMS_FGA.DISABLE_POLICY文をポリシー・ハンドラから発行しないでください。これらの文を発行すると、 ORA-28144: ファイングレイン監査ハンドラの実行に失敗しましたエラーが発生する場合があります。

- enable: TRUEまたはFALSEを使用してポリシーを使用可能または使用禁止にします。省略した場合、ポリシーは使用可能になります。デフォルトはTRUEです。

- statement_types: 監査対象のSQL文を指定します。INSERT、UPDATE、DELETEまたはSELECTのみです。デフォルト値はSELECTです。

- audit_trail: ファイングレイン監査レコードの宛先(DBまたはXML)を指定します。LSQLTEXTおよびLSQLBINDをFGA_LOG$に移入するかどうかも指定します。ただし、クレジット・カード情報などの機密データもクリアテキストで記録できることに注意してください。この状況に対処する方法は、「機密情報の監査」を参照してください。
audit_trailパラメータをXMLに設定すると、XMLファイルはAUDIT_FILE_DEST初期化パラメータで指定されたディレクトリに書き込まれます。

読取り専用データベースの場合、audit_trailの設定に関係なく、ファイングレイン監査証跡はXMLファイルに書き込まれます。

- audit_column_opts: audit_columnパラメータで複数の列を指定した場合は、すべての列を監査するか特定の列を監査するかをこのパラメータで決定します。詳細は、「特定の列および行の監査」を参照してください。

ADD_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

例9-21に、表HR.EMPLOYEESに対する文INSERT、UPDATE、DELETEおよびSELECTを監査する方法を示します。この例では、audit_column_optsパラメータが必須パラメータではないため省略されていることに注意してください。

例9-21 DBMS_FGA.ADD_POLICYを使用してファイングレイン監査ポリシーを作成する方法

BEGIN
DBMS_FGA.ADD_POLICY(
object_schema      => 'HR',
object_name        => 'EMPLOYEES',
policy_name        => 'chk_hr_employees',
enable             =>  TRUE,
statement_types    => 'INSERT, UPDATE, SELECT, DELETE',
audit_trail        =>  DBMS_FGA.DB);
END;
/

この時点で、DBA_AUDIT_POLICIESビューを問い合せると、新しいポリシーがリストされることを確認できます。

SELECT POLICY_NAME FROM DBA_AUDIT_POLICIES;

POLICY_NAME
-------------------------------
CHK_HR_EMPLOYEES

その後、次のようなSQL文を発行すると、監査イベント・レコードが記録されます。

SELECT COUNT(*) FROM HR.EMPLOYEES WHERE COMMISSION_PCT = 20 AND SALARY > 4500;

SELECT SALARY FROM HR.EMPLOYEES WHERE DEPARTMENT_ID = 50;

DELETE FROM HR.EMPLOYEES WHERE SALARY > 1000000;

特定の列および行の監査

条件が一致した場合の監査対象を関連列と呼ばれる特定の列にすることで、監査動作を細かく調節できます。これを実行するには、audit_columnパラメータを使用して、機密情報が含まれた列を1つ以上指定します。また、audit_conditionパラメータを使用してブール条件を定義すると、特定の行のデータを監査できます。

例9-21では、部門50のユーザーがsalaryおよびcommission_pct列にアクセスしようとしたときに監査を実行します。

audit_condition    => 'DEPARTMENT_ID = 50',
audit_column       => 'SALARY,COMMISSION_PCT,'

この機能は非常に有用です。監査対象を特定の重要なデータ・タイプに限定できるだけでなく、社会保障番号、給与情報、診断書などの機密データを含む列をより強力に保護できます。

audit_columnに複数の列がリストされている場合は、audit_column_optsパラメータを使用すると、文の監査が、audit_columnパラメータで指定されたいずれかの列が問合せで参照されたときに実行されるか、またはすべての列が参照されたときにのみ実行されるかを指定できます。次に例を示します。

audit_column_opts   => DBMS_FGA.ANY_COLUMNS,

audit_column_opts   => DBMS_FGA.ALL_COLUMNS,

関連列を指定しない場合、監査はすべての列に適用されます。

DBMS_FGA.ADD_POLICYプロシージャ内のaudit_condition、audit_columnおよびaudit_column_optsパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。その項のADD_POLICYプロシージャの使用方法も参照してください。

ファイングレイン監査ポリシーを使用可能および使用禁止にする方法

ファイングレイン監査ポリシーを使用禁止にするには、DBMS_FGA.DISABLE_POLICYプロシージャを使用します。DISABLE_POLICYの構文は、次のとおりです。

DBMS_FGA.DISABLE_POLICY(
object_schema  VARCHAR2,
object_name    VARCHAR2,
policy_name    VARCHAR2 );

例9-22に、例9-21で作成したファイングレイン監査ポリシーを使用禁止にする方法を示します。

例9-22 ファイングレイン監査ポリシーを使用禁止にする方法

DBMS_FGA.DISABLE_POLICY(
object_schema        => 'HR',
object_name          => 'EMPLOYEES',
policy_name          => 'chk_hr_employees');
/

DISABLE_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

例9-23に、DBMS_FGA.ENABLE_POLICYプロシージャを使用してchk_hr_empポリシーを再度使用可能にする方法を示します。

例9-23 ファイングレイン監査ポリシーを使用可能にする方法

DBMS_FGA.ENABLE_POLICY(
object_schema        => 'HR',
object_name          => 'EMPLOYEES',
policy_name          => 'chk_hr_employees',
enable               => TRUE);
/

ENABLE_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ファイングレイン監査ポリシーの削除

DBMS_FGA.ADD_POLICYプロシージャのobject_nameパラメータで指定されたオブジェクトを削除したり、監査ポリシーを作成したユーザーを削除した場合、自動的に監査ポリシーが削除されます。

例9-24に、DBMS_FGA.DROP_POLICYプロシージャを使用して、ファイングレイン監査ポリシーを手動で削除する方法を示します。

例9-24 ファイングレイン監査ポリシーを削除する方法

DBMS_FGA.DROP_POLICY(
object_schema      => 'HR',
object_name        => 'EMPLOYEES',
policy_name        => 'chk_hr_employees');

DROP_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

例: ファイングレイン監査ポリシーへの電子メール・アラートの追加

この項の内容は、次のとおりです。

- このチュートリアルの概要

- 手順1: UTL_MAIL PL/SQLパッケージのインストールと構成

- 手順2: ユーザー・アカウントの作成

- 手順3: ネットワーク・サービスに対するアクセス制御リスト・ファイルの構成

- 手順4: 電子メール・セキュリティ・アラートPL/SQLプロシージャの作成

- 手順5: ファイングレイン監査ポリシー設定の作成とテスト

- 手順6: アラートのテスト

- 手順7: この例で使用したコンポーネントの削除

このチュートリアルの概要

ユーザー(または侵入者)がポリシーに違反した場合に実施される電子メール・アラートをファイングレイン監査ポリシーに追加できます。そのためには、最初にアラートを生成するプロシージャを作成し、次のDBMS_FGA.ADD_POLICYパラメータを使用して、ユーザーがこのポリシーに違反した場合にこのファンクションをコールする必要があります。

- handler_schema: ハンドラ・イベントが格納されるスキーマ

- handler_module: イベント・ハンドラの名前

アラートは、電子メールまたはポケベルによる通知や、特定のファイルまたは表の更新など、環境に適した形式で生成できます。アラートを作成すると、California Senate Bill 1386などの特定のコンプライアンス規制を満たすことも可能です。この例では、電子メール・アラートを作成します。

この例では、セキュリティ管理者に対して、人事部門の担当者がHR.EMPLOYEES表内の給与情報を選択または変更しようとしていることを通知する電子メール・アラートを作成します。担当者はこの表を変更することを許可されていますが、コンプライアンス規制を満たすために、表内の給与情報に対するすべての選択および変更操作に関するレコードを作成できます。

手順1: UTL_MAIL PL/SQLパッケージのインストールと構成

1. ユーザーSYSとしてSYSDBA権限でログインします。

sqlplus sys as sysdba
Enter password: password

2. UTL_MAILパッケージをインストールします。

@$ORACLE_HOME/rdbms/admin/utlmail.sql
@$ORACLE_HOME/rdbms/admin/prvtmail.plb

UTL_MAILパッケージにより、電子メールの管理が可能になります。UTL_MAILの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

現在、UTL_MAIL PL/SQLパッケージではSSLサーバーはサポートされていないことに注意してください。

3. この例が終了した後に元に戻すことができるよう、SMTP_OUT_SERVER初期化パラメータの現行の値を調べて書き留めておきます。

次に例を示します。

SHOW PARAMETER SMTP_OUT_SERVER

SMTP_OUT_SERVERパラメータがすでに設定されている場合は、次のような出力が表示されます。

NAME                    TYPE              VALUE
----------------------- ----------------- ----------------------------------
SMTP_OUT_SERVER         string            some_imap_server.example.com

4. 次のALTER SYSTEM文を発行します。

ALTER SYSTEM SET SMTP_OUT_SERVER="imap_mail_server.example.com";

imap_mail_serverを、電子メール・ツールのアカウント設定にあるSMTPサーバーの名前に置き換えます。これらの設定を引用符で囲んでください。次に例を示します。

ALTER SYSTEM SET SMTP_OUT_SERVER="my_imap_server.example.com"

5. SYSとしてSYSOPER権限で接続し、データベースを再起動します。

CONNECT SYS/AS SYSOPER
Enter password: password

SHUTDOWN IMMEDIATE
STARTUP

6. SMTP_OUT_SERVERパラメータ設定が正しいことを確認します。

CONNECT SYS/AS SYSDBA
Enter password: password

SHOW PARAMETER SMTP_OUT_SERVER

次のような出力が表示されます。

NAME                    TYPE              VALUE
----------------------- ----------------- ----------------------------------
SMTP_OUT_SERVER         string            my_imap_server.example.com

手順2: ユーザー・アカウントの作成

1. SYSとしてSYSDBA権限で接続していることを確認し、sysadmin_fgaアカウント(ファイングレイン監査ポリシーの作成者)を作成します。
次に例を示します。

CONNECT SYS/AS SYSDBA
Enter password: password

GRANT CREATE SESSION, DBA TO sysadmin_fga IDENTIFIED BY password;
GRANT EXECUTE ON DBMS_FGA TO sysadmin_fga;
GRANT CREATE PROCEDURE, DROP ANY PROCEDURE TO sysadmin_fga;
GRANT EXECUTE ON UTL_TCP TO sysadmin_fga;
GRANT EXECUTE ON UTL_SMTP TO sysadmin_fga;
GRANT EXECUTE ON UTL_MAIL TO sysadmin_fga;
GRANT EXECUTE ON DBMS_NETWORK_ACL_ADMIN TO sysadmin_fga;

passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。

UTL_TCP、UTL_SMTP、UTL_MAILおよびDBMS_NETWORK_ACL_ADMIN PL/SQLパッケージは、作成する電子メール・セキュリティ・アラートで使用されます。

2. ユーザーSYSTEMで接続します。

CONNECT SYSTEM
Enter password: password

3. HRスキーマ・アカウントのロックが解除され、パスワードが付与されていることを確認します。必要に応じて、HRのロックを解除し、このユーザーにパスワードを付与します。

SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'HR';

DBA_USERSビューに、ユーザーHRがロックされて期限切れになっていると表示された場合は、次の文を入力して、HRアカウントのロックを解除し、新しいパスワードを作成します。

ALTER USER HR ACCOUNT UNLOCK IDENTIFIED BY password;

安全なパスワードを入力します。セキュリティを向上させるため、以前のリリースのOracle Databaseと同じパスワードをHRアカウントに指定しないでください。パスワードを作成するための最低要件は、「パスワードの最低要件」を参照してください。

4. 人事部門の担当者であるSusan Mavris用のユーザー・アカウントを作成し、このユーザーにHR.EMPLOYEES表へのアクセス権を付与します。

GRANT CREATE SESSION TO smavris IDENTIFIED BY password;
GRANT SELECT, INSERT, UPDATE, DELETE ON HR.EMPLOYEES TO SMAVRIS;

手順3: ネットワーク・サービスに対するアクセス制御リスト・ファイルの構成

UTL_MAILなどのPL/SQLネットワーク・ユーティリティ・パッケージを使用する場合は、外部ネットワーク・サービスに対するファイングレイン・アクセスを可能にする、アクセス制御リスト(ACL)ファイルを事前に構成する必要があります。詳細は、「PL/SQLパッケージおよびタイプでのファイングレイン・アクセスの管理」を参照してください。

電子メール・アラート用にアクセス制御リストを構成する手順は、次のとおりです。

1. ユーザーsysadmin_fgaでSQL*Plusに接続します。

CONNECT sysadmin_fga
Enter password: password

2. 次のアクセス制御リストとその権限定義を作成します。

BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
acl          => 'email_server_permissions.xml',
description  => 'Enables network permissions for the email server',
principal    => 'SYSADMIN_FGA',
is_grant     => TRUE,
privilege    => 'connect');
END;
/

principal設定には、正確なユーザー名を大文字で入力してください。この例では、principalの名前としてSYSADMIN_FGAを入力します。

3. アクセス制御リストを電子メール・サーバーの送信SMTPネットワーク・ホストに割り当てます。

BEGIN
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
acl         => 'email_server_permissions.xml',
host        => 'SMTP_OUT_SERVER_setting',
lower_port  => port);
END;
/

この例の説明は、次のとおりです。

- SMTP_OUT_SERVER_setting: 「手順1: UTL_MAIL PL/SQLパッケージのインストールと構成」のSMTP_OUT_SERVERパラメータに設定したSMTP_OUT_SERVER設定を入力します。この設定は、使用している電子メール・ツールで送信サーバー用に指定されている設定と完全に一致させる必要があります。

- port: 電子メール・ツールで送信サーバーに指定されているポート番号を入力します。通常、この設定は25です。この値をlower_port設定に入力します。(現在、UTL_MAILパッケージではSSLをサポートしていません。電子メール・サーバーがSSLサーバーの場合、その電子メール・サーバーが別のポート番号を使用していても、ポート番号に25を入力します。)

手順4: 電子メール・セキュリティ・アラートPL/SQLプロシージャの作成

ユーザーsysadmin_fgaで、次のプロシージャを作成します。(最初の行のCREATE OR REPLACEの前にカーソルを置くことで、このテキストをコピーして貼り付けることができます。)

CREATE OR REPLACE PROCEDURE email_alert (sch varchar2, tab varchar2, pol varchar2)
AS
msg varchar2(20000) := 'HR.EMPLOYEES table violation. The time is: ';
BEGIN
msg := msg||TO_CHAR(SYSDATE, 'Day DD MON, YYYY HH24:MI:SS');
UTL_MAIL.SEND (
sender      => 'youremail@example.com',
recipients  => 'recipientemail@example.com',
subject     => 'Table modification on HR.EMPLOYEES',
message     => msg);
END email_alert;
/

この例の説明は、次のとおりです。

- CREATE OR REPLACE PROCEDURE ...AS: 次の手順で監査ポリシーに定義するスキーマ名(sch)、表名(tab)および監査プロシージャ名(pol)を表す署名を指定する必要があります。

- senderおよびrecipients: youremail@example.comを自分の電子メール・アドレス、recipientemail@example.comを通知の受信対象者の電子メール・アドレスに置き換えます。

手順5: ファイングレイン監査ポリシー設定の作成とテスト

1. ユーザーsysadmin_fgaで、chk_hr_empポリシーをファイングレイン監査ポリシーとして次のように作成します。

BEGIN
DBMS_FGA.ADD_POLICY (
object_schema      =>  'HR',
object_name        =>  'EMPLOYEES',
policy_name        =>  'CHK_HR_EMP',
audit_column       =>  'SALARY',
handler_schema     =>  'SYSADMIN_FGA',
handler_module     =>  'EMAIL_ALERT',
enable             =>   TRUE,
statement_types    =>  'SELECT, UPDATE',
audit_trail        =>   DBMS_FGA.DB + DBMS_FGA.EXTENDED);
END;
/

2. データベースに加えた変更をコミットします。

COMMIT;

3. 今までに作成した設定をテストします。

EXEC email_alert ('hr', 'employees', 'chk_hr_emp');

SQL*Plusに「PL/SQLプロシージャが正常に終了しました。」というメッセージが表示されます。まもなく、電子メール・サーバーの速度に応じて、電子メール・アラートを受信します。

ORA-24247「アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました」エラーの後にORA-06512「string行string」エラーが発生した場合は、アクセス制御リスト・ファイル内の設定を確認してください。

手順6: アラートのテスト

1. ユーザーsmavrisでSQL*Plusに接続し、自分の給与を確認して金額を引き上げます。

CONNECT smavris
Enter password: password

SELECT SALARY FROM HR.EMPLOYEES WHERE LAST_NAME = 'Mavris';

SALARY
-----------
6500

UPDATE HR.EMPLOYEES SET SALARY = 13000 WHERE LAST_NAME = 'Mavris';

2. 次に、HR.EMPLOYEES表のSALARY以外の列から選択します。

SELECT FIRST_NAME, LAST_NAME FROM HR.EMPLOYEES WHERE LAST_NAME = 'Raphaely';

次の出力が表示されます。

FIRST_NAME           LAST_NAME
-------------------- --------------------
Den                  Raphaely

ここまでの手順を実行すると、電子メール・サーバーの速度に応じて、自分自身(または通知の受信対象者)にTable modification on HR.EMPLOYEESという件名ヘッダーの電子メールが届き、HR.EMPLOYEES表の改ざんについて通知されます。

3. ユーザーsysadmin_fgaで、Susan Mavrisの監査対象アクティビティを含むDBA_FGA_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。

CONNECT sysadmin_fga
Enter password: password

col dbuid format a10
col lsqltext format a66
col ntimestamp# format a15

SELECT DBUID, LSQLTEXT, NTIMESTAMP# FROM SYS.FGA_LOG$ WHERE POLICYNAME='CHK_HR_EMP';

次のような出力が表示されます。

DBUID      LSQLTEXT
---------- ------------------------------------------------------------------
NTIMESTAMP#
--------------------------------------------------------------------------
SMAVRIS    SELECT SALARY FROM HR.EMPLOYEES WHERE LAST_NAME = 'Mavris'
23-JUN-09 03.48.59.111000 PM

SMAVRIS    UPDATE HR.EMPLOYEES SET SALARY = 13000 WHERE LAST_NAME = 'Mavris'
23-JUN-09 03.49.07.330000 PM

監査証跡では、Susan Mavrisが実行し、HR.EMPLOYEES表のSALARY列に影響を与えた2つのSQL文が取得されます。Susan Mavrisが実行した3つ目の文(Den Raphaelyに関して尋ねた文)は、監査ポリシーの影響を受けなかったため、記録されませんでした。これは、Oracle Databaseでは、監査関数は自律型トランザクションとして実行され、handler_module設定のアクションのみをコミットし、ユーザー・トランザクションはコミットしないためです。この関数はユーザーのSQLトランザクションには影響を与えません。

手順7: この例で使用したコンポーネントの削除

1. SYSTEM権限を持つユーザーでSQL*Plusに接続し、ユーザーsysadmin_fga(sysadmin_fgaスキーマ内のオブジェクトを含む)とsmavrisを削除します。

CONNECT SYSTEM
Enter password: password

DROP USER sysadmin_fga CASCADE;
DROP USER smavris;

2. ユーザーHRで接続し、Susan Mavrisの引き上げた給与を元に戻します。

CONNECT HR
Enter password: password

UPDATE HR.EMPLOYEES SET SALARY = 6500 WHERE LAST_NAME = 'Mavris';

3. 他のユーザーがHRを使用しない場合、このアカウントはロックして期限切れにできます。

ALTER USER HR PASSWORD EXPIRE ACCOUNT LOCK;

4. SYSDBA権限を持つユーザーSYSで接続し、email_server_permissions.xmlアクセス制御リストを削除します。

BEGIN
DBMS_NETWORK_ACL_ADMIN.DROP_ACL(
acl => 'email_server_permissions.xml');
END;
/

アクセス制御リストは、作成者ユーザーのスキーマ内ではなく、SYSスキーマ内に存在します。

5. 次のALTER SYSTEM文を発行して、「手順1: UTL_MAIL PL/SQLパッケージのインストールと構成」の手順4からSMTP_OUT_SERVERパラメータを前の値にリストアします。

ALTER SYSTEM SET SMTP_OUT_SERVER="previous_value";

この設定は引用符で囲みます。次に例を示します。

ALTER SYSTEM SET SMTP_OUT_SERVER="some_imap_server.example.com"

6. データベース・インスタンスを再起動します。

SHUTDOWN

STARTUP

例: 非データベース・ユーザーの監査

この項の内容は、次のとおりです。

- このチュートリアルの概要

- 手順1: ユーザー・アカウントの作成とユーザーHRがアクティブであることの確認

- 手順2: ファイングレイン監査ポリシーの作成

- 手順3: ポリシーのテスト

- 手順4: この例で使用したコンポーネントの削除

このチュートリアルの概要

この例では、クライアント識別子に設定された識別情報に基づいて、非データベース・ユーザーのアクションを監査するファイングレイン監査ポリシーを作成する方法を示します。

手順1: ユーザー・アカウントの作成とユーザーHRがアクティブであることの確認

1. ユーザーSYSとしてSYSDBA権限でログインします。

sqlplus SYS AS SYSDBA
Enter password: password

2. sysadmin_fgaアカウントを作成します。このアカウントでファイングレイン監査ポリシーを作成します。

GRANT CREATE SESSION, DBA TO sysadmin_fga IDENTIFIED BY password;
GRANT SELECT ON OE.ORDERS TO sysadmin_fga;
GRANT EXECUTE ON DBMS_FGA TO sysadmin_fga;
GRANT SELECT ON SYS.FGA_LOG$ TO sysadmin_fga;

passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。

3. この例ではサンプル・ユーザーOEも使用するため、DBA_USERSデータ・ディクショナリ・ビューを問い合せて、OEがロックされていたり、期限切れになっていないことを確認します。

SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'OE';

DBA_USERSビューに、ユーザーOEがロックされて期限切れになっていると表示された場合は、ユーザーSYSTEMでログインし、次の文を入力して、OEアカウントのロックを解除し、新しいパスワードを作成します。

ALTER USER OE ACCOUNT UNLOCK IDENTIFIED BY password;

安全なパスワードを入力します。セキュリティを向上させるため、以前のリリースのOracle Databaseと同じパスワードをOEアカウントに指定しないでください。パスワードを作成するための最低要件は、「パスワードの最低要件」を参照してください。

手順2: ファイングレイン監査ポリシーの作成

1. ユーザーsysadmin_fgaでSQL*Plusに接続します。

CONNECT sysadmin_fga
Enter password: password

2. 次のポリシーを作成します。

BEGIN
DBMS_FGA.ADD_POLICY(OBJECT_SCHEMA => 'OE',
OBJECT_NAME                     => 'ORDERS',
POLICY_NAME                     => 'ORDERS_FGA_POL',
AUDIT_CONDITION                 => 'SYS_CONTEXT(''USERENV'', ''CLIENT_IDENTIFIER'') = ''Robert''',
HANDLER_SCHEMA                  => NULL,
HANDLER_MODULE                  => NULL,
ENABLE                          => True,
STATEMENT_TYPES                 => 'INSERT,UPDATE,DELETE,SELECT',
AUDIT_TRAIL                     => DBMS_FGA.DB + DBMS_FGA.EXTENDED,
AUDIT_COLUMN_OPTS               => DBMS_FGA.ANY_COLUMNS);
END;
/

この例では、AUDIT_CONDITIONパラメータで非データベース・ユーザーの名前がRobertであると想定しています。ポリシーでは、Robertが実行するINSERT、UPDATE、DELETEおよびSELECT文を監視します。

手順3: ポリシーのテスト

1. ユーザーOEで接続し、OE.ORDERS表から選択します。

CONNECT OE
Enter password: password

SELECT COUNT(*) FROM ORDERS;

次の出力が表示されます。

COUNT(*)
----------
105

2. ユーザーsysadmin_fgaで接続し、監査レコードが生成されたかどうかを確認します。

CONNECT sysadmin_fga
Enter password: password

SELECT DBUID, LSQLTEXT FROM SYS.FGA_LOG$ WHERE POLICYNAME='ORDERS_FGA_POL';

次の出力が表示されます。

no rows selected

ログインしてOE.ORDERS表の問合せを行う非データベース・ユーザーは存在しなかったため、監査証跡は空です。

3. ユーザーOEで再接続し、クライアント識別子をRobertに設定し、OE.ORDERS表から再選択します。

CONNECT OE
Enter password: password

EXEC DBMS_SESSION.SET_IDENTIFIER('Robert');

SELECT COUNT(*) FROM ORDERS;

次の出力が表示されます。

COUNT(*)
----------
105

4. ユーザーsysadmin_fgaで再接続し、監査証跡を再び確認します。

CONNECT sysadmin_fga
Enter password: password

SELECT DBUID, LSQLTEXT FROM SYS.FGA_LOG$ WHERE POLICYNAME='ORDERS_FGA_POL';

今回は、Robertが存在し、OE.ORDERS表を問い合せたため、監査証跡ではそのアクションが取得されます。

DBUID            LSQLTEXT
---------------- ----------------------------
OE               SELECT COUNT(*) FROM ORDERS;

手順4: この例で使用したコンポーネントの削除

1. ユーザーSYSTEMでSQL*Plusに接続し、ユーザーsysadmin_fga(sysadmin_fgaスキーマ内のオブジェクトを含む)を削除します。

CONNECT SYSTEM
Enter password: password

DROP USER sysadmin_fga CASCADE;

2. 他のユーザーがOEを使用しない場合、このアカウントはロックして期限切れにできます。

ALTER USER OE PASSWORD EXPIRE ACCOUNT LOCK;

SYS管理ユーザーの監査

この項の内容は、次のとおりです。

- ユーザーSYSTEMの監査

- ユーザーSYS、およびSYSDBAまたはSYSOPERとして接続するユーザーの監査

ユーザーSYSTEMの監査

標準およびファイングレイン監査機能を使用して、SYSTEMユーザーを監査できます。監査に関するかぎり、ユーザーSYSTEMは一般的なデータベース・ユーザー(HR、OEなど)であり、監査対象の特別な構成はありません。

例9-25に、ユーザーSYSTEMによって発行された表挿入操作を監査する方法を示します。

例9-25 ユーザーSYSTEMによる表挿入操作の監査

AUDIT INSERT ANY TABLE BY SYSTEM BY ACCESS;

ユーザーSYS、およびSYSDBAまたはSYSOPERとして接続するユーザーの監査

SYSとして接続するユーザーと、SYSDBAまたはSYSOPER権限を使用して接続しているすべてのユーザーのセッションを完全に監査できます。これによりAUDIT_TRAILパラメータがNONE、DB、またはDB, EXTENDEDに設定されていても、管理ユーザーのアクションをオペレーティング・システム・ファイルに書き込むことができるようになります。管理ユーザーはSYS.AUD$表から不正な行動を示す行を削除できるため、管理者ユーザーのアクションをオペレーティング・システム監査ファイルに書き込むことは、SYS.AUD$表に書き込むよりも安全です。

ユーザーSYSDBAおよびSYSOPERの監査設定を構成する手順は、次のとおりです。

1. AUDIT_SYS_OPERATIONS初期化パラメータをTRUEに設定します。

ALTER SYSTEM SET AUDIT_SYS_OPERATIONS=TRUE SCOPE=SPFILE;

この設定は、データベースにSYSDBAまたはSYSOPER権限を使用して接続したユーザーによって直接発行されたトップレベルの操作を記録します。監査レコードはオペレーティング・システム監査証跡に書き込まれます。すべての文のSQLテキストは、オペレーティング・システム監査証跡レコードのACTIONフィールドに書き込まれます。

2. システム管理者によるアクティビティをXMLファイルに書き込む場合は、AUDIT_TRAIL初期化パラメータをXMLまたはXML, EXTENDEDに設定します。
次に例を示します。

ALTER SYSTEM SET AUDIT_TRAIL=XML, EXTENDED SCOPE=SPFILE;

どのオペレーティング・システムでも、AUDIT_TRAILをXMLまたはXML,EXTENDEDに設定すると、監査レコードはAUDIT_FILE_DEST初期化パラメータで指定したディレクトリにXMLファイルとして書き込まれます。デフォルトでは、監査レコードはオペレーティング・システム・ファイルに書き込まれます。

これらの設定の詳細は、表9-1「AUDIT_TRAIL初期化パラメータの設定」を参照してください。「標準監査証跡を使用可能または使用禁止にする方法」も参照してください。

3. データベースを再起動します。

データベースを再起動すると、SYSDBAおよびSYSOPERユーザーによって実行され、正常終了したすべてのアクションが監査され、これらの監査レコードが、SYS.AUD$表ではなく、オペレーティング・システム監査証跡に書き込まれます。

Windowsでは、AUDIT_TRAIL初期化パラメータをOSに設定している場合、監査レコードはイベントビューアのログ・ファイルにイベントとして書き込まれます。

注意:
AUDIT_FILE_DEST初期化パラメータが設定されていないか、有効なディレクトリを指し示していない場合は、$ORACLE_BASE/admin/$ORACLE_SID/adumpディレクトリが最初のデフォルトの場所として使用されます。最初のデフォルトの場所への書込みが失敗するか、データベースがクローズされている場合、$ORACLE_HOME/rdbms/auditディレクトリがバックアップのデフォルトの場所として使用されます。この試みも失敗すると、監査した操作が失敗し、アラート・ログにメッセージが書き込まれます。
AUDIT_TRAIL+がOSに設定されている場合、監査ファイル名の形式は次のままです。

$ORACLE_SID_short_form_process_name_processid_sequence_number.aud

順序番号の開始番号は1です。

たとえば、専用サーバー・プロセスとして短いプロセス名oraが使用され、共有サーバー・プロセスとしてs001やs002などの名前が使用されます。

AUDIT_TRAILがXMLまたはXML, EXTENDEDに設定されている場合、同じ監査ファイル名の拡張子はaudではなくxmlになります。

AUDIT_FILE_DEST初期化パラメータを指定しない場合、デフォルトの場所は、LinuxとSolarisでは$ORACLE_BASE/admin/$ORACLE_SID/adump、Microsoft Windowsでは%ORACLE_BASE%\admin\%ORACLE_SID%\adumpです。他のオペレーティング・システムについては、監査証跡に関するそれぞれのドキュメントを参照してください。

Oracle Databaseでは、SYSが発行したすべてのSQL文が、AUDIT_TRAIL初期化パラメータの設定に関係なく無差別に監査されます。

次のSYSセッションを考えてみます。

CONNECT SYS AS SYSDBA;
Enter password: password

ALTER SYSTEM FLUSH SHARED_POOL;
UPDATE salary SET base=1000 WHERE name='laurel';

SYS監査が有効なとき、ALTER SYSTEM文とUPDATE文の両方がオペレーティング・システム監査ファイルに、次の出力のように表示されます。(この書式は、Oracle Databaseの異なるリリースでは変わる場合があることに注意してください。)

Tue May  5 04:53:37 2009 -07:00
LENGTH : '159'
ACTION :[7] 'CONNECT'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[7] 'laurelh'
CLIENT TERMINAL:[5] 'pts/0'
STATUS:[1] '0'
DBID:[9] '561542328'

Tue May  5 04:53:40 2009 -07:00
LENGTH : '183'
ACTION :[30] 'ALTER SYSTEM FLUSH SHARED_POOL'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[7] 'laurelh'
CLIENT TERMINAL:[5] 'pts/0'
STATUS:[1] '0'
DBID:[9] '561542328'

Tue May  5 04:53:49 2009 -07:00
LENGTH : '200'
ACTION :[47] 'UPDATE salary SET base=1000 WHERE name='laurel''
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[7] 'laurelh'
CLIENT TERMINAL:[5] 'pts/0'
STATUS:[1] '0'
DBID:[9] '561542328'

括弧は値の長さを示します。たとえば、PRIVILEGEは、6文字のSYSDBAに設定されています。また、SYSおよび必須監査レコードの場合は、値が一重引用符で囲まれています。

SYSDBAで接続したユーザーはスーパーユーザー権限を使用できるため、データベース管理者にはこの接続を必要な場合にのみ使用することをお薦めします。データベース管理者は通常、日常的なメンテナンス・アクティビティを実行できます。これらのデータベース管理者は、DBAロールを持つ標準のデータベース・ユーザーであるか、または組織でカスタマイズされたDBAロール(mydbaやjr_dbaなど)と同等の権限が付与されているデータベース・ユーザーです。

トリガーを使用して監査データを個別の表に書き込む方法

トリガーを使用して、Oracle Databaseの組込みの監査機能を補完できます。作成するトリガーでは、ユーザー・アクションが個別のデータベース表に記録されます。アクティビティによってトリガーが起動されると、そのトリガーによってアクションがこの表に記録されます。トリガーは、表の変更前と変更後の情報など、カスタマイズされた情報を記録する場合に役立ちます。トリガーの作成方法の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

監査を使用可能にしていなくても、どのタイプの監査を使用可能にしていても、トリガーは動作します。トリガーの動作は、データベース監査機能とは独立しています。

監査トリガーを作成する場合は、次のガイドラインに従ってください。

- データをSYS.AUD$表に書き込むトリガーは記述しないでください。つまり、SYS.AUD$表の内容は変更しないでください。SYS.AUD$に値を書き込もうとし、トリガーが期待どおりに動作しなかった場合、標準監査に悪影響が及ぶ可能性があります。SYS.AUD$表はOracle Databaseが所有する表であり、Oracle Databaseのみが書込み可能です。

- 可能な場合、トリガーはAFTERトリガーとして作成してください。トリガー文は、適用される制約が存在する場合、その影響を受けます。レコードが見つからない場合、AFTERトリガーは起動せず、監査処理が不必要に実行されることはありません。

- トリガーはAFTER行トリガーまたはAFTER文トリガーとして作成してください。AFTER行トリガーとAFTER文トリガーのどちらを選択するかは、監査対象の情報によって決まります。たとえば、行トリガーでは、表の行ごとに値ベースの監査が可能です。トリガーでは、監査対象のSQL文を発行するための理由コードの入力を要求することもできます。これは、行レベルと文レベルのどちらの監査でも役立ちます。

表9-5に、トリガーベースの監査と組込みのデータベース監査機能の比較を示します。

表9-5 組込みの監査とトリガーベースの監査の比較

監査機能

説明

DMLおよびDDL監査

標準監査オプションでは、すべてのタイプのスキーマ・オブジェクトと構造に関して、DMLおよびDDL文の監査が可能です。それに対し、トリガーでは、表に対して入力されたDML文の監査およびSCHEMAまたはDATABASEレベルでのDDL監査が可能です。

集中監査証跡

データベースの監査機能を使用すると、すべてのデータベース監査情報が集中的および自動的に記録されます。

宣言方法

標準データベース機能を使用して有効化する監査機能は、トリガーで定義する監査機能と比べて、宣言とメンテナンスが容易で、エラーが発生しにくくなります。

監査オプションの監査

既存の監査オプションの変更も監査して、不正なデータベース・アクティビティから保護できます。

セッションと実行時間の監査

データベース監査機能を使用すると、監査対象の文が入力されるたびにレコードが生成されます。トリガーを使用した場合は、トリガーで監査されている表が参照されるたびに監査レコードが生成されます。

データ・アクセスの失敗の監査

データベース監査は、データ・アクセスの失敗を監査するように設定できます。ただし、自律型トランザクションを使用しないかぎり、トリガー文がロールバックされると、トリガーによって生成されたすべての監査情報がロールバックされます。自律型トランザクションの詳細は、『Oracle Database概要』を参照してください。

セッションの監査

標準データベース監査を使用すると、接続、切断およびセッション・アクティビティ(物理I/O、論理I/O、デッドロックなど)を記録できます。

例9-26では、emp_tab表の特定の行に対する変更をトリガーで監査しています。トリガーによって、更新を行ったユーザーと更新時刻を含め、古い値と新しい値がemp_audit_tab表に書き込まれます。

例9-26 表の変更前と変更後の情報を記録する監査トリガー

/* 1. Create the following table: */
CREATE TABLE emp_tab (
empno               NUMBER(4),
ename               VARCHAR2(10),
job                 VARCHAR2(9),
mgr                 NUMBER(4),
hiredate            DATE,
sal                 NUMBER(8,2),
deptno              NUMBER(2));

/* 2. Create a table to capture the audit data. */
CREATE TABLE emp_audit_tab (
oldname             VARCHAR2(10),
oldjob              VARCHAR2(9),
oldsal              NUMBER (8,2),
newname             VARCHAR2(10),
newjob              VARCHAR2(9),
newsal              NUMBER(8,2),
user1               varchar2(10),
systemdate          TIMESTAMP);

/* 3. Create a trigger to record the old and new values, the author of the change,
and when the change took place. */
CREATE OR REPLACE TRIGGER emp_audit_trig
AFTER INSERT OR DELETE OR UPDATE ON emp_tab
FOR EACH ROW
BEGIN
INSERT INTO emp_audit_tab (
oldname, oldjob, oldsal,
newname, newjob, newsal,
user1, systemdate
)
VALUES (
:OLD.ename, :OLD.job, :OLD.sal,
:NEW.ename, :NEW.job, :NEW.sal,
user, sysdate
);
END;
/

このトリガーをテストするには、行をemp_tab表に追加し、emp_tab表のename、jobまたはsal列の値を変更します。その後、emp_audit_tab表を問い合せて監査データを調べます。

監査証跡レコードの管理

この項の内容は、次のとおりです。

- 監査レコードの概要

- データベース監査証跡の管理

- オペレーティング・システム監査証跡の管理

監査レコードの概要

監査レコードには、監査された操作、操作を行ったユーザー脚注 2 、そして操作の日時に関する情報が含まれます。選択した監査タイプに応じて、監査レコードをデータ・ディクショナリ表(データベース監査証跡)またはオペレーティング・システム・ファイル(オペレーティング・システム監査証跡)に書き込むことができます。

監査レコードをデータベース監査証跡に書き込むように選択すると、デフォルト監査と標準監査の場合はSYS.AUD$表に、ファイングレイン監査の場合はSYS.FGA_LOG$表に、監査レコードが書き込まれます。この2つの表はどちらもSYSTEM表領域にあり、SYSスキーマの所有となっています。これらの表の内容は、次のデータ・ディクショナリ・ビューを問い合せることで確認できます。

- SYS.AUD$の内容の場合はDBA_AUDIT_TRAIL

- SYS.FGA_LOG$の内容の場合はDBA_FGA_AUDIT_TRAIL

- SYS.AUD$とSYS.FGA_LOG$の両方の内容の場合はDBA_COMMON_AUDIT_TRAIL

SYS.AUD$およびSYS.FGA_LOG$表の内容の表示に使用できる他のデータ・ディクショナリ・ビューについては、「監査アクティビティに関する情報の検索」を参照してください。

監査レコードをオペレーティング・システム・ファイルに書き込むように選択した場合は、テキスト・ファイルまたはXMLファイルに書き込むことができます。監査XMLファイルの内容は、V$XML_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることで確認できます。

データベース監査証跡の管理

この項の内容は、次のとおりです。

- データベース監査証跡の内容

- データベース監査証跡のサイズの制御

- データベース監査証跡の別の表領域への移動

- データベース監査証跡の保護

- データベース監査証跡の監査

- データベース監査証跡のアーカイブ

関連項目:
「監査証跡レコードの削除」

データベース監査証跡の内容

データベース監査証跡は、AUD$表(標準監査用)とFGA_LOG$表(ファイングレイン監査用)のペアであり、各Oracle Databaseデータ・ディクショナリのSYSスキーマにあります。標準監査とファイングレイン監査の両方のアクティビティを記録します。各種データ・ディクショナリ・ビューは、この表の情報を使用する場合に役立ちます。「監査アクティビティに関する情報の検索」では、すべての監査関連ビューがリストされてます。

監査対象のイベントと設定されている監査オプションに応じて、データベース監査証跡には様々な種類の情報が記録されます。たとえば、AUDIT_TRAIL初期化パラメータをDB、EXTENDEDまたはXML, EXTENDEDに設定している場合、SQL_BINDおよびSQL_TEXT列に、SQL文で使用されているSQLバインド変数および監査のトリガーとなったSQLテキストがそれぞれ示されます。これらのビューの内容の詳細は、『Oracle Databaseリファレンス』を参照してください。ただし、DBA_AUDIT_TRAILビューの形式と列はOracle Databaseの各リリースで異なる場合があることに注意してください。

注意:
AUDIT_TRAIL初期化パラメータがXMLまたはXML, EXTENDEDに設定されている場合、標準監査レコードはXML形式でオペレーティング・システム・ファイルに送信されます。XMLは標準文書形式であるため、XMLデータを解析および分析できる多くのユーティリティがあります。

監査レコードのデータベースの宛先がいっぱいか使用できなくなったために新規レコードが入らなくなると、監査対象のアクションは完了できません。かわりにエラー・メッセージが生成され、監査対象のアクションは実行されません。監査証跡のサイズを調節すると、管理しやすくなります。(これは特にお薦めします。)詳細は、「データベース監査証跡のサイズの制御」を参照してください。「監査済情報の管理しやすい状態での維持」も参照してください。

監査証跡には、監査対象の文に関連するデータ値の情報は格納されません。たとえば、UPDATE文を監査しているときに、更新された行の新旧のデータ値は格納されません。ただし、ファイングレイン監査方法を使用すれば、この特別なタイプの監査を実行できます。

フラッシュバック問合せ機能を使用すると、現在有効な監査ポリシーに従って、更新された行の新旧のデータ値を表示できます。フラッシュバックが、最初は別のポリシーに従っていた旧問合せに対する内容の場合でも、現在のポリシーが適用されます。現行のビジネス・アクセス・ルールが常に適用されます。

関連項目:

- ファイングレイン監査の方法の詳細は、「ファイングレイン監査を使用した特定のアクティビティの監査」を参照してください。

- フラッシュバック・トランザクション問合せを使用した表変更の監査の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 『Oracle Database SQL言語リファレンス』のGRANT SQL文に関する項に記載されているシステム権限の表内のフラッシュバック・エントリ。

注意:
V$LOGMNR_CONTENTSデータ・ディクショナリ・ビューを問い合せることで、ログの履歴に関する情報を確認できます。このビューのCLIENT_ID列には、セッションのクライアント識別子に対する変更が記録されます。このビューを問い合せるには、SELECT ANY TRANSACTIONシステム権限が必要です。

データベース監査証跡のサイズの制御

データベース監査証跡がいっぱいになり、これ以上監査レコードを挿入できなくなった場合は、監査証跡を削除しないかぎり、基礎となる文を正常に完了できません。Oracle Databaseでは、監査が行われる文を発行するすべてのユーザーに対してエラーが発行されます。このため、監査証跡の増加とサイズを制御する必要があります。

監査が使用可能で、監査レコードが生成されているときは、次の2つの要因によって監査証跡が増加します。

- 使用可能な監査オプションの数

- 監査対象の文の実行頻度

監査証跡の増加を制御するには、次の方法を使用します。

- データベース監査を使用可能および使用禁止にします。使用可能にすると、監査レコードが生成されて監査証跡に格納されます。使用禁止の場合、監査レコードは生成されません。(一部のアクティビティは常に監査されることに注意してください。)

- 使用可能な監査オプションを選択的に絞り込みます。選択的な監査を実施すると、不要な監査情報が生成されず、監査証跡に格納されません。ファイングレイン監査を使用すると、特定の条件のみを選択的に監査できます。

- オブジェクト監査を実行できるかを厳密に制御します。これには次の方法があります。

- セキュリティ管理者がすべてのオブジェクトを所有し、AUDIT ANYシステム権限を他のユーザーには付与しない方法。また、すべてのスキーマ・オブジェクトを、対応するユーザーにCREATE SESSION権限がないスキーマに所属させることもできます。

- すべてのオブジェクトを、実際のデータベース・ユーザーに対応していない(つまり、対応するユーザーにCREATE SESSION権限が付与されていない)スキーマに格納しておく方法。セキュリティ管理者のみにAUDIT ANYシステム権限を付与します。

どちらの方法でも、セキュリティ管理者がオブジェクト監査を完全に制御できます。

データベース監査証跡表(AUD$およびFGA_LOG$表)の最大サイズは、その表がデフォルトで格納されているSYSTEM表領域のデフォルトの記憶域パラメータによって決まります。データベース監査証跡が大きくなりすぎてSYSTEM表のパフォーマンスに影響することが懸念される場合は、データベース監査証跡表を別の表領域に移動することを検討します。

関連項目:
監査レコードをオペレーティング・システムの監査証跡に書き込んでいる場合の、オペレーティング・システム監査証跡の管理方法の詳細は、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

データベース監査証跡の別の表領域への移動

デフォルトでは、SYSTEM表領域にデータベース監査証跡SYS.AUD$およびSYS.FGA_LOG$表が格納されます。このデフォルトの場所を別の表領域(SYSAUX表領域やユーザーが作成した表領域など)に変更できます。SYSTEM表領域がいっぱいの場合、必要に応じてデータベース監査証跡表を別の表領域に移動できます。また、DBMS_AUDIT_MGMT PL/SQLパッケージ・プロシージャを使用して監査証跡表を削除する場合も、それらの監査証跡表を別の表領域に移動できます。

データベース監査証跡表を別の表領域に移動する場合、監査表内の監査データの量によっては処理に時間がかかることがあります。そのため、この処理は、データベースの負荷が低い時間帯に行うのが賢明です。

SYSTEM内のデータベース監査証跡を別の表領域に移動する手順は、次のとおりです。

1. DBMS_AUDIT_MGMT PL/SQLパッケージに対するEXECUTE権限を持つ管理者としてSQL*Plusにログインします。
DBMS_AUDIT_MGMT PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

2. データベース監査証跡表の移動先の表領域を確認します。
SYSAUX補助表領域を含め、対象の表領域を最適化してより多くの領域を割り当てることが必要となる場合があります。詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

3. DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION PL/SQLプロシージャを実行して、移動先の表領域の名前を指定します。
次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(
AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
AUDIT_TRAIL_LOCATION_VALUE  => 'AUD_AUX');
END;

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: データベース監査証跡タイプを表します。次のいずれかの値を入力します。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: 標準監査証跡表とファイングレイン監査証跡表の両方です。

- AUDIT_TRAIL_LOCATION_VALUE: 移動先の表領域を指定します。この例では、AUD_AUXという名前の表領域を指定しています。

データベース監査証跡の監査

アプリケーションで、通常のユーザー(SYSDBA以外のユーザー)にSYS.AUD$システム表へのアクセス権を付与することが必要な場合があります。たとえば、監査レポート生成者は、可能性のある違反に関する日次レポートを生成するために、AUD$表へのアクセスを必要とします。また、多くのインストールでは、業務を分離するために個別の監査人ロールを設けています。

この場合、INSERT、UPDATE、MERGE、DELETEなどのDML文は常に監査され、SYS.AUD$表に記録されることに注意してください。これらのアクティビティを調べるには、DBA_AUDIT_TRAILビューおよびDBA_COMMON_AUDIT_TRAILビューを問い合せます。

SYS.AUD$に対するSELECT、UPDATE、INSERTおよびDELETE権限があるユーザーがSELECT操作を実行すると、監査証跡にその操作のレコードが記録されます。つまり、SYS.AUD$には、それ自体に対するSELECTアクションを識別する、row1などの行が記録されます。

ユーザーが後でSYS.AUD$のこの行を削除しようとした場合、このユーザーにはこのアクションを実行する権限があるため、DELETE操作は成功します。ただし、SYS.AUD$に対するこのDELETEアクションも監査証跡に記録されます。このタイプの監査の設定はセーフティ機能の役割を果たし、異常なアクションや不正なアクションを検出できる場合があります。

注意:
SYS.AUD$表とSYS.FGA_LOG$表に対するDELETE、INSERT、UPDATE、およびMERGE操作は常に監査されます。これらの監査レコードは削除できません。

関連項目:
「機密情報の監査」

データベース監査証跡のアーカイブ

監査証跡が大きくなりすぎないように、定期的にアーカイブしてから削除する必要があります。アーカイブと削除により、監査証跡の領域が解放され、データベース監査証跡の削除が容易になります。監査証跡レコードの別の削除方法は、「監査証跡レコードの削除」を参照してください。

次のいずれかの方法でデータベース監査証跡のアーカイブを作成できます。

- Oracle Audit Vault。Oracle Audit VaultをOracle Databaseとは別にインストールします。詳細は、『Oracle Audit Vault管理者ガイド』を参照してください。

- Oracle Data Warehouse。Oracle Data Warehouseは、Oracle Databaseとともに自動的にインストールされます。詳細は、『Oracle Warehouse Builderインストレーションおよび管理ガイド』を参照してください。

アーカイブが完了したら、データベース監査証跡の内容を削除できます。詳細は、「監査証跡レコードの削除」を参照してください。

標準監査レコードとファイングレイン監査レコードをアーカイブするには、関連するレコードを通常のデータベース表にコピーします。次に例を示します。

INSERT INTO table SELECT ... FROM SYS.AUD$ ...;
INSERT INTO table SELECT ... FROM SYS.FGA_LOG$ ...;

関連項目:
データベース監査証跡の様々なパージ方法は、次のセクションを参照してください。

- 「監査証跡の自動削除ジョブのスケジューリング」

- 「監査証跡の手動削除」

- 「データベース監査証跡内のレコードのサブセットの削除」

オペレーティング・システム監査証跡の管理

この項の内容は、次のとおりです。

- オペレーティング・システム監査証跡がいっぱいになった場合

- オペレーティング・システム監査証跡のサイズの設定

- オペレーティング・システム監査証跡の有効期間の設定

- オペレーティング・システム監査証跡のアーカイブ

関連項目:

- 「監査証跡レコードの削除」

- 「UNIXシステムでのsyslog監査証跡の使用」

- 「すべてのプラットフォームについて常に監査されるアクティビティ」

オペレーティング・システム監査証跡がいっぱいになった場合

オペレーティング・システムの監査証跡またはファイル・システム(Windowsイベント・ログなど)がいっぱいになることがあり、そのためにOracle Databaseの監査レコードも含めて、新しいレコードが入らなくなる可能性があることに注意してください。この場合、Oracle Databaseでは、通常は常に監査される操作を含めて、実行される操作が取り消されてロールバックされます。(「すべてのプラットフォームについて常に監査されるアクティビティ」を参照してください。)オペレーティング・システム監査証跡がいっぱいになった場合は、データベース監査証跡を使用するようにAUDIT_TRAILパラメータを設定します(DBまたはDB, EXTENDEDなど)。これにより、監査レコードを格納できない場合は監査対象のアクションの完了が防止されます。このようなタイプの障害を防止するためには、オペレーティング・システム監査ファイルを定期的にアーカイブして削除する必要があります。

オペレーティング・システム監査を使用する場合は、オペレーティング・システムの監査証跡またはファイル・システムがいっぱいにならないようにしてください。ほとんどのオペレーティング・システムでは、このような状況を回避できるように十分な情報と警告が管理者に提供されています。データベースの監査証跡を使用するように監査を構成すると、監査情報を失う危険性を回避できます。監査証跡が文に関するデータベース監査レコードを受け入れられない場合は、監査されているイベントの発生をOracle Databaseが防止しているためです。

オペレーティング・システム監査証跡の内容を定期的にアーカイブして削除します。詳細は、「オペレーティング・システム監査証跡のアーカイブ」および「監査証跡レコードの削除」を参照してください。

オペレーティング・システム監査証跡のサイズの設定

オペレーティング・システム監査証跡のサイズを制御するには、DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY PL/SQLプロシージャを使用してDBMS_AUDIT_MGMT.OS_FILE_MAX_SIZEプロパティを設定します。このプロシージャを使用するには、DBMS_AUDIT_MGMT PL/SQLパッケージに対するEXECUTE権限が必要です。オペレーティング・システム・ファイルがサイズ制限の設定値に達すると、現行ファイルへのレコードの追加が停止され、それ以降のレコード用に新しいオペレーティング・システム・ファイルが作成されます。DBMS_AUDIT_MGMT PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZEとDBMS_AUDIT_MGMT.OS_FILE_MAX_AGE(「オペレーティング・システム監査証跡の有効期間の設定」の説明を参照)の両方のプロパティを設定した場合は、最初に達したほうのプロパティ値の制限に基づいてアクションが実行されます。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
AUDIT_TRAIL_TYPE            =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
AUDIT_TRAIL_PROPERTY        =>  DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE,
AUDIT_TRAIL_PROPERTY_VALUE  =>  10240);
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: オペレーティング・システム監査証跡を指定します。次のいずれかの値を入力します。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。また、AUDIT_SYSLOG_LEVEL初期化パラメータが設定されているときは、syslog監査レコードにも適用されません。)

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML監査証跡ファイルです。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: オペレーティング・システム監査証跡ファイルとXML監査証跡ファイルの両方です。

- AUDIT_TRAIL_PROPERTY: DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZEプロパティを指定して、最大サイズを設定します。現行のプロパティ設定のステータスを調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューのPARAMETER_NAMEおよびPARAMETER_VALUE列を問い合せます。

- AUDIT_TRAIL_PROPERTY_VALUE: 最大サイズを10240KB(つまり、10MB)に設定します。デフォルト設定は10000KB(約10MB)です。2GBを超えることはできません。

DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE設定の消去

ファイルの最大サイズの設定を消去するには、DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTYプロシージャを使用します。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY(
AUDIT_TRAIL_TYPE        =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
AUDIT_TRAIL_PROPERTY    =>  DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE,
USE_DEFAULT_VALUES      =>  TRUE );
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: オペレーティング・システム監査証跡を指定します。「オペレーティング・システム監査証跡のサイズの設定」に示したAUDIT_TRAIL_TYPE値のいずれかを入力します。

- AUDIT_TRAIL_PROPERTY: DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZEプロパティを指定します。このプロパティの現行のステータスを調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューを問い合せます。

- USE_DEFAULT_VALUES: 次のいずれかの値を入力します。

- TRUE: 現行の値を消去し、かわりにデフォルト値の10000KBを使用します。

- FALSE: オペレーティング・システム・ファイルまたはXMLファイルの増大にデフォルトの最大サイズは適用されません。DBMS_AUDIT_MGMT.OS_FILE_MAX_AGEプロパティを構成しないかぎり、ファイルは無制限に大きくなります。デフォルト設定はFALSEです。

オペレーティング・システム監査証跡の有効期間の設定

オペレーティング・システム監査証跡の有効期間を制御するには、DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY PL/SQLプロシージャを使用します。このプロシージャを使用するには、DBMS_AUDIT_MGMT PL/SQLパッケージに対するEXECUTE権限が必要です。オペレーティング・システム・ファイルが有効期間制限の設定値に達すると、現行ファイルへのレコードの追加が停止され、それ以降のレコード用に新しいオペレーティング・システム・ファイルが作成されます。DBMS_AUDIT_MGMT PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

DBMS_AUDIT_MGMT.OS_FILE_MAX_AGEとDBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE(「オペレーティング・システム監査証跡のサイズの設定」の説明を参照)の両方のプロパティを設定した場合は、最初に達したほうのプロパティ値の制限に基づいて監査ファイルの増大が制御されます。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
AUDIT_TRAIL_TYPE            =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
AUDIT_TRAIL_PROPERTY        =>  DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE,
AUDIT_TRAIL_PROPERTY_VALUE  =>  10 );
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: オペレーティング・システム監査証跡を指定します。次のいずれかの値を入力します。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。また、AUDIT_SYSLOG_LEVEL初期化パラメータが設定されているときは、syslog監査レコードにも適用されません。)

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML監査証跡ファイルです。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: オペレーティング・システム監査証跡ファイルとXML監査証跡ファイルの両方です。

- AUDIT_TRAIL_PROPERTY: DBMS_AUDIT_MGMT.OS_FILE_MAX_AGEプロパティを指定して、最大有効期間を設定します。現行のプロパティ設定のステータスを調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューを問い合せます。

- AUDIT_TRAIL_PROPERTY_VALUE: 最大有効期間を10日に設定します。1から495の値を入力します。デフォルトの有効期間は5日です。

DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE設定の消去

ファイルの最大有効期間の設定を消去するには、DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTYプロシージャを使用します。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY(
AUDIT_TRAIL_TYPE        =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
AUDIT_TRAIL_PROPERTY    =>  DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE,
USE_DEFAULT_VALUES      =>  TRUE );
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: オペレーティング・システム監査証跡を指定します。「オペレーティング・システム監査証跡の有効期間の設定」に示したAUDIT_TRAIL_TYPE値のいずれかを入力します。

- AUDIT_TRAIL_PROPERTY: DBMS_AUDIT_MGMT.OS_FILE_MAX_AGEプロパティを指定します。このプロパティの現行のステータスを調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューのPARAMETER_NAMEおよびPARAMETER_VALUE列を問い合せます。

- USE_DEFAULT_VALUES: 次のいずれかの値を指定します。

- TRUE: 現行の値を消去し、かわりにデフォルト値の5日を使用します。

- FALSE: オペレーティング・システム・ファイルまたはXMLファイルの増大にデフォルトの最大有効期間は適用されません。この場合、DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZEプロパティを構成しないかぎり、ファイルは無期限で使用されます。デフォルト設定はFALSEです。

オペレーティング・システム監査証跡のアーカイブ

オペレーティング・システム監査証跡は定期的にアーカイブする必要があります。プラットフォーム固有のオペレーティング・システム・ツールを使用して、オペレーティング・システム監査ファイルのアーカイブを作成します。

オペレーティング・システム監査ファイルをアーカイブするには、次の方法を使用します。

- Oracle Audit Vaultを使用します。Oracle Audit VaultをOracle Databaseとは別にインストールします。詳細は、『Oracle Audit Vault管理者ガイド』を参照してください。

- テープまたはディスクにバックアップを作成します。監査ファイルの圧縮ファイルを作成し、それをテープまたはディスクに格納できます。詳細は、使用しているオペレーティング・システムのマニュアルを参照してください。

その後、監査証跡の領域を解放して監査証跡管理を容易にするために、オペレーティング・システム監査レコードをパージ(削除)する必要があります。オペレーティング・システム監査証跡レコードの別の削除方法は、「監査証跡レコードの削除」を参照してください。

監査証跡レコードの削除

この項の内容は、次のとおりです。

- 監査証跡レコードの削除の概要

- 監査証跡の削除方法の選択

- 監査証跡の自動削除ジョブのスケジューリング

- 監査証跡の手動削除

- データベース監査証跡内のレコードのサブセットの削除

- 他の監査証跡削除操作

- 例: データベース監査証跡の削除操作の直接コール

監査証跡レコードの削除の概要

監査証跡が大きくなりすぎると新しいレコードが入らなくなるため、監査証跡レコードを定期的にアーカイブしてから削除(パージ)する必要があります。この項では、データベース監査証跡レコードとオペレーティング・システム監査証跡レコードの両方を削除するために使用できる様々な方法について説明します。データベース監査証跡レコードのサブセットを削除できます。データベース監査証跡とオペレーティング・システム監査証跡のどちらのタイプについても、レコードを手動で削除したり、削除ジョブを作成して指定した時間間隔で実行できます。その場合、削除操作ではアーカイブ・タイムスタンプより前に作成された監査証跡レコードが削除されるか、すべての監査証跡レコードが削除されます。

監査証跡の削除タスクを実行するには、ほとんどの場合、DBMS_AUDIT_MGMT PL/SQLパッケージを使用します。DBMS_AUDIT_MGMTを使用するには、そのEXECUTE権限が必要です。

Oracle Audit Vaultをインストールしている場合は、このマニュアルで説明しているプロシージャとは異なる監査証跡削除プロセスを使用します。たとえば、Oracle Audit Vaultでは、監査証跡が自動的にアーカイブされます。『Oracle Audit Vault管理者ガイド』を参照してください。

注意:
Oracle Databaseでは、監査証跡からのレコードの削除はすべて例外なく監査されます。「データベース監査証跡の監査」および「SYS管理ユーザーの監査」を参照してください。

関連項目:

- DBMS_AUDIT_MGMT PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- DBA_AUDIT_MGMT関連のビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

監査証跡の削除方法の選択

表9-6に、監査証跡の削除方法を選択するための手引きを示します。

表9-6 監査証跡の削除方法の選択

削除対象

このタイプの削除方法の概要

すべての監査レコードまたは指定したタイムスタンプより前に作成された監査レコード(定期的)

削除操作を特定の時間に実行するようにスケジューリングできます。たとえば、土曜日の午前2時に毎回実行するようにスケジューリングできます。

一般手順

1. 必要に応じて、監査表の削除プロセス中に追加生成されるレコードに対応するために、オンラインREDOログとアーカイブREDOログのサイズをチューニングします。

2. タイムスタンプおよびアーカイブ方針を計画します。

3. 監査証跡をクリーン・アップ操作用に初期化します。

4. 監査レコードのアーカイブ・タイムスタンプを設定します。

5. 削除ジョブを作成してスケジューリングします。

6. 必要に応じて、監査証跡をバッチで削除するように構成します。

詳細は、「監査証跡の自動削除ジョブのスケジューリング」を参照してください。

すべての監査レコードまたは指定したタイムスタンプより前に作成されたレコード(必要に応じて)

削除スケジュールを作成するのではなく、1回の手動操作で監査レコードを即座に削除できます。

一般手順

1. 必要に応じて、監査表の削除プロセス中に追加生成されるレコードに対応するために、オンラインREDOログとアーカイブREDOログのサイズをチューニングします。

2. タイムスタンプおよびアーカイブ方針を計画します。

3. 監査証跡をクリーン・アップ操作用に初期化します。

4. 監査レコードのアーカイブ・タイムスタンプを設定します。

5. 必要に応じて、監査証跡をバッチで削除するように構成します。

6. 削除操作を実行します。

詳細は、「監査証跡の手動削除」を参照してください。

データベース監査証跡内の監査レコードのサブセットのみ

監査レコードのサブセットのみを手動で削除できます。たとえば、2010年5月14日から2010年6月14日までの期間に作成されたすべての監査レコードを削除できます。

一般手順

1. 必要に応じて、監査表の削除プロセス中に追加生成されるレコードに対応するために、オンラインREDOログとアーカイブREDOログのサイズをチューニングします。

2. 削除対象の監査レコードをアーカイブします。

3. 管理権限を持つユーザーで、SYS.AUD$表から削除します。

詳細は、「データベース監査証跡内のレコードのサブセットの削除」を参照してください。

監査証跡の自動削除ジョブのスケジューリング

監査証跡全体を削除することも、タイムスタンプより前に作成された一部の監査証跡のみを削除することもできます。データベース監査証跡の場合、タイムスタンプより前に作成された個々の監査レコードを削除できます。オペレーティング・システム監査証跡の場合、タイムスタンプより前に作成された監査ファイルを削除します。

監査証跡(特に、大きいもの)を削除する場合は、完了するまでに時間がかかることがあります。削除ジョブは、データベースの負荷が低い時間帯に実行するようにスケジューリングするのが賢明です。

競合しないかぎり、異なる監査証跡タイプに対する複数の削除ジョブを作成できます。たとえば、標準監査証跡表の削除ジョブを作成し、その後でファイングレイン監査証跡表の削除ジョブを作成できます。ただし、DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STDまたはDBMS_AUDIT_MGMT.AUDIT_TRAIL_ALLプロパティを使用して、両方のタイプまたはすべてのタイプをまとめて処理する削除ジョブを作成することはできません。

自動削除ジョブを作成してスケジューリングする手順は、次のとおりです。

- 手順1: オンラインREDOログとアーカイブREDOログのサイズのチューニング(必要に応じて)

- 手順2: タイムスタンプおよびアーカイブ方針の計画

- 手順3: クリーン・アップ操作のための監査証跡の初期化

- 手順4: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)

- 手順5: 削除ジョブの作成とスケジューリング

- 手順6: 監査証跡レコードのバッチ削除の構成(必要に応じて)

手順1: オンラインREDOログとアーカイブREDOログのサイズのチューニング(必要に応じて)

削除プロセスでは、REDOログが追加生成される場合があります。監査表の削除プロセスを実行する前に、プロセス中に追加生成されるレコードに対応するために、オンラインREDOログとアーカイブREDOログのサイズのチューニングが必要になる場合があります。ログ・ファイルのチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Database管理者ガイド』を参照してください。

手順2: タイムスタンプおよびアーカイブ方針の計画

データベース監査レコードとオペレーティング・システム監査レコードをアーカイブするには、これらのレコードのタイムスタンプを記録する必要があります。タイムスタンプの日付は、DBA_AUDIT_MGMT_LAST_ARCH_TSデータ・ディクショナリ・ビューを問い合せることで確認できます。その後、削除を実行すると、このタイムスタンプの日付より前に作成された監査証跡レコードのみが削除されます。詳細は、「手順4: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)」を参照してください。

レコードのタイムスタンプを設定したら、アーカイブを開始できます。詳細は、次の各項を参照してください。

- 「データベース監査証跡のアーカイブ」

- 「オペレーティング・システム監査証跡のアーカイブ」

手順3: クリーン・アップ操作のための監査証跡の初期化

DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャを使用して監査証跡を削除するには、事前に監査証跡をクリーン・アップ操作用に初期化する必要があります。データベース監査証跡については、SYSTEM表領域のデータベース監査証跡表(SYS.AUD$およびSYS.FGA_LOG$)を別の表領域に移動していない場合、このプロセスにより、これらの表がSYSAUX表領域または「データベース監査証跡の別の表領域への移動」で指定した表領域に移動されます。これらの表の移動には時間がかかるため、初期化プロセスはデータベースの負荷が低い時間帯にスケジューリングするのが賢明です。

監査証跡をクリーン・アップ操作用に初期化する手順は、次のとおりです。

1. DBMS_AUDIT_MGMT PL/SQLパッケージに対するEXECUTE権限を持つ管理ユーザーとしてSQL*Plusにログインします。

2. まだログインしていない場合は、DBMS_AUDIT_MGMT.INIT_CLEANUPプロシージャを実行して監査証跡クリーン・アップ操作を初期化します。(この手順は1回だけ実行する必要があります。
DBMS_AUDIT_MGMT.IS_CLEANUP_INITIALIZED関数を実行して、監査証跡がクリーン・アップ用に初期化されたかどうかを確認できます。「監査証跡がクリーン・アップ用に初期化されたことの確認」を参照してください。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.INIT_CLEANUP(
AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
DEFAULT_CLEANUP_INTERVAL    => 12 );
END;
/

次のように値を指定します。

- AUDIT_TRAIL_TYPE: 次のいずれかの値を入力します。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: 標準監査証跡表とファイングレイン監査証跡表の両方です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。)

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XMLオペレーティング・システム監査証跡ファイルです。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: オペレーティング・システム監査証跡ファイルとXML監査証跡ファイルの両方です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: すべての監査証跡レコード、つまりデータベース監査証跡タイプとオペレーティング・システム監査証跡タイプの両方です。

- DEFAULT_CLEANUP_INTERVAL: 目的のデフォルト削除間隔(時間単位)を指定します(たとえば、12時間ごとに実行する場合は12)。DBMS_AUDIT_MGMTプロシージャでは、この値に基づいて監査レコードの削除方法が決定されます。DBMS_AUDIT_MGMT.INIT_CLEANUPプロシージャを実行すると、計時が開始されます。この値を後で更新するには、DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTYプロシージャのDBMS_AUDIT_MGMT.CLEAN_UP_INTERVALプロパティを設定します。
DEFAULT_CLEANUP_INTERVAL設定には、DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILをコールする頻度を指定する必要があります。頻度が不確定の場合は、概略値を設定します。この値は、後でDBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTYプロパティを使用して変更できます。

手順4: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)

すべての監査証跡を削除する場合は、この手順を省略できます。

最後の監査レコードがアーカイブされた時点のタイムスタンプを設定できます。設定したアーカイブ・タイムスタンプは、クリーン・アップ・インフラストラクチャに対するヒントとなり、それに基づいてクリーン・アップ操作が6時間ごとに実行されます。

データベース監査証跡の場合、監査証跡をクリーン・アップ操作用に初期化した後でタイムスタンプを設定する必要があります。監査証跡の最終アーカイブ・タイムスタンプを調べるには、DBA_AUDIT_MGMT_LAST_ARCH_TSデータ・ディクショナリ・ビューを問い合せます。タイムスタンプを設定した後でDBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャを実行すると、そのタイムスタンプより前の時間を示すすべての監査レコードが監査証跡から削除されます。アーカイブ・タイムスタンプ設定を消去する場合は、「アーカイブ・タイムスタンプ設定の消去」を参照してください。

オペレーティング・システム監査証跡の場合、オペレーティング・システム監査ファイル(XMLを含む)内の監査レコードは個別に削除できないことに注意してください。かわりに、タイムスタンプが設定されたレコードを含むファイル全体が削除されます。

Oracle Real Application Clusters(Oracle RAC)を使用している場合は、ネットワーク・タイム・プロトコル(NTP)を使用して、Oracle Databaseインスタンスをインストールしている各コンピュータ上の時間を同期化してください。たとえば、1つのOracle RACインスタンス・ノードの時間を午前11:00:00に設定し、次のOracle RACインスタンス・ノードの時間を11:00:05に設定するとします。その結果、2つのノードの時間に矛盾が生じます。ネットワーク・タイム・プロトコル(NTP)を使用して、これらのOracle RACインスタンス・ノードの時間を同期化できます。

タイムスタンプを設定するには、DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP PL/SQLプロシージャを使用します。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP(
AUDIT_TRAIL_TYPE     =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
LAST_ARCHIVE_TIME    =>  '2009-05-28 06:30:00.00'
RAC_INSTANCE_NUMBER  =>  0 );
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: 次のいずれかの設定を入力します。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$を指定します。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$を指定します。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。)

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML監査証跡ファイルを指定します。

- LAST_ARCHIVE_TIME: タイムスタンプを入力します。AUDIT_TRAIL_DB_AUDおよびAUDIT_TRAIL_FGA_STD(標準監査証跡およびファイングレイン監査証跡)の場合は、YYYY-MM-DD HH:MI:SS.FF UTC(協定世界時)形式で入力し、AUDIT_TRAIL_OSおよびAUDIT_TRAIL_XML(オペレーティング・システム監査証跡およびXML監査証跡)の場合は、ローカル・タイム・ゾーンで入力します。

- RAC_INSTANCE_NUMBER: Oracle RACインストールのインスタンス番号を指定します。監査証跡タイプとしてDBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STDまたはDBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STDを指定した場合は、RAC_INSTANCE_NUMBER引数を省略できます。これは、Oracle RACインストールの場合でも、存在するAUD$およびFGA_LOG$表は1つのみであるためです。デフォルトは0(ゼロ)で、単一インスタンス・データベース・インストールに使用されます。

通常、タイムスタンプを設定したら、DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャを使用して、タイムスタンプの日付より前に作成された監査レコードを削除できます。

手順5: 削除ジョブの作成とスケジューリング

DBMS_AUDIT_MGMT.CREATE_PURGE_JOB PL/SQLプロシージャを実行して、削除ジョブを作成してスケジューリングします。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.CREATE_PURGE_JOB (
AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
AUDIT_TRAIL_PURGE_INTERVAL  => 12,
AUDIT_TRAIL_PURGE_NAME      => 'Standard_Audit_Trail_PJ',
USE_LAST_ARCH_TIMESTAMP     => TRUE );
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: 次のいずれかの値を入力します。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: 標準監査証跡表とファイングレイン監査証跡表の両方です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。)

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML監査証跡ファイルです。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: オペレーティング・システム監査証跡ファイルとXML監査証跡ファイルの両方です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: すべての監査証跡レコード、つまりデータベース監査証跡タイプとオペレーティング・システム監査証跡タイプの両方です。

- AUDIT_TRAIL_PURGE_INTERVAL: この削除ジョブを実行する間隔(時間単位)を指定します。DBMS_AUDIT_MGMT.CREATE_PURGE_JOBプロシージャを実行すると、計時が開始されます(この例では、このプロシージャを実行してから12時間後)。後でこの値を更新する場合は、DBMS_AUDIT_MGMT.SET_PURGE_JOB_INTERVALプロシージャを実行します。

- USE_LAST_ARCH_TIMESTAMP: 次の設定のいずれかを入力します。

- TRUE: 最終アーカイブ・タイムスタンプより前に作成された監査レコードを削除します。最後に記録されたタイムスタンプを調べるには、DBA_AUDIT_MGMT_LAST_ARCH_TSデータ・ディクショナリ・ビューのLAST_ARCHIVE_TS列を問い合せます。デフォルト値はTRUEです。USE_LAST_ARCH_TIMESTAMPはTRUEに設定することをお薦めします。

- FALSE: 最終アーカイブ・タイムスタンプを考慮せずに、すべての監査レコードを削除します。削除してはならない監査レコードを誤って削除しないように、この設定を使用する際には注意が必要です。

手順6: 監査証跡レコードのバッチ削除の構成(必要に応じて)

デフォルトでは、DBMS_AUDIT_MGMTパッケージ・プロシージャでデータベース監査証跡レコードおよびオペレーティング・システム監査証跡レコードを削除する場合、バッチで10000個のデータベース監査レコードまたは1000個のオペレーティング・システム監査ファイルが削除されます。必要に応じて、このバッチ・サイズを別の値に設定できます。その後、Oracle Databaseで削除ジョブを実行すると、すべてのレコードではなく、各バッチが削除されます。監査証跡が非常に大きい場合(および、非常に大きくなる可能性がある場合)、バッチでレコードを削除すると削除操作の効率が向上します。

現行のバッチ設定を調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューのPARAMETER_NAMEおよびPARAMETER_VALUE列を問い合せます。バッチ・サイズを設定するには、DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTYプロシージャを使用します。後でこの設定を消去する場合は、「データベース監査証跡のバッチ・サイズの消去」を参照してください。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
AUDIT_TRAIL_PROPERTY        => DBMS_AUDIT_MGMT.DB_DELETE_BATCH_SIZE,
AUDIT_TRAIL_PROPERTY_VALUE  => 100000);
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: 監査証跡タイプ(この例では、データベース・システム監査証跡)を指定します。次のいずれかの値を入力します。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: オペレーティング・システム監査ファイルです。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML監査ファイルです。

- AUDIT_TRAIL_PROPERTY: DBMS_AUDIT_MGMT.DB_DELETE_BATCH_SIZEプロパティを使用して、データベース監査証跡のバッチ・サイズ設定を指定します。オペレーティング・システム監査証跡のバッチを作成するには、FILE_DELETE_BATCH_SIZEプロパティを使用します。

- AUDIT_TRAIL_PROPERTY_VALUE: 監査レコード・ファイルの数をバッチごとに100000個に設定します。100から1000000の値を入力します。この数を決定する際には、削除対象のレコードの合計数および削除操作を実行する時間間隔を考慮します。デフォルトは、データベース監査証跡の場合は10000、オペレーティング・システム監査証跡レコードの場合は1000です。

監査証跡の手動削除

監査証跡は、削除ジョブをスケジューリングしなくても、手動で即座に削除できます。削除ジョブと同様に、アーカイブ・タイムスタンプの日付より前に作成された監査証跡レコード、または監査証跡内のすべてのレコードを削除できます。

DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャに関しては、次のことに注意してください。

- このプロシージャを実行した場合、現行の監査ディレクトリのみがクリーン・アップされます。

- DBMS_AUDIT_MGMTパッケージではWindowsイベントビューアのクリーン・アップはサポートされていないため、Microsoft WindowsでAUDIT_TRAIL_TYPEプロパティをDBMS_AUDIT_MGMT.AUDIT_TRAIL_OSに設定しても効果はありません。Windows上のオペレーティング・システム監査レコードはWindowsイベントビューアに書き込まれるためです。DBMS_AUDIT_MGMTパッケージでは、このタイプのクリーン・アップ操作はサポートされていません。

- UNIXプラットフォームでは、AUDIT_SYSLOG_LEVEL初期化パラメータを、『Oracle Databaseリファレンス』に示されている有効な値に設定すると、オペレーティング・システムのログ・ファイルがsyslogファイルに書き込まれます。AUDIT_TRAIL_TYPEプロパティをDBMS_AUDIT_MGMT.AUDIT_TRAIL_OSに設定すると、監査ディレクトリ内の.audファイルのみが削除されます(このディレクトリは、AUDIT_FILE_DEST初期化パラメータで指定します)。

- AUDIT_TRAIL_TYPEパラメータをDBMS_AUDIT_MGMT.AUDIT_TRAIL_XMLに設定すると、現行の監査ディレクトリ内のXML監査ファイル(.xml)のみがクリーン・アップされます。XML監査で生成されたXMLファイルをリストした索引ファイル(adx_$ORACLE_SID.txt)は保持されます。クリーン・アップ・プロシージャでは、このファイルは削除されません。

データベース監査証跡の場合、DBMS_AUDIT_MGMT.INIT_CLEANUPプロシージャを実行してから、「データベース監査証跡内のレコードのサブセットの削除」で説明する方法を使用してデータベース監査証跡を削除することによって、クリーン・アップ・インフラストラクチャを初期化する必要があります。

監査証跡を手動で削除する手順は、次のとおりです。

1. 「監査証跡の自動削除ジョブのスケジューリング」で説明した次の手順を実行します。

- 手順1: オンラインREDOログとアーカイブREDOログのサイズのチューニング(必要に応じて)

- 手順2: タイムスタンプおよびアーカイブ方針の計画

- 手順3: クリーン・アップ操作のための監査証跡の初期化

- 手順4: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)

- 手順5: 削除ジョブの作成とスケジューリング

- 手順6: 監査証跡レコードのバッチ削除の構成(必要に応じて)

2. DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャを実行して、監査証跡レコードを削除します。
次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
AUDIT_TRAIL_TYPE           =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
USE_LAST_ARCH_TIMESTAMP    =>  TRUE );
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: 次のいずれかの値を入力します。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: 標準監査証跡表とファイングレイン監査証跡表の両方です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。)

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML監査証跡ファイルです。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: オペレーティング・システム監査証跡ファイルとXML監査証跡ファイルの両方です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: すべての監査証跡レコード、つまりデータベース監査証跡タイプとオペレーティング・システム監査証跡タイプの両方です。

- USE_LAST_ARCH_TIMESTAMP: 次の設定のいずれかを入力します。

- TRUE: 最終アーカイブ・タイムスタンプより前に作成された監査レコードを削除します。アーカイブ・タイムスタンプを設定する方法は、「手順4: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)」を参照してください。デフォルト(推奨)値はTRUEです。USE_LAST_ARCH_TIMESTAMPはTRUEに設定することをお薦めします。

- FALSE: 最終アーカイブ・タイムスタンプを考慮せずに、すべての監査レコードを削除します。削除されているはずの監査レコードを誤って削除しないように、この設定を使用する際には注意が必要です。

データベース監査証跡内のレコードのサブセットの削除

データベース監査証跡表からレコードを手動で削除できます。この方法は、レコードの特定のサブセットを削除する場合に役立ちます。データベース監査証跡表が表領域(SYSTEM表領域を含む)に存在する場合に、この方法を使用できます。

たとえば、2009年2月28日の夜から2009年3月28日までに作成された監査レコードを削除するには、次の文を入力します。

DELETE FROM SYS.AUD$
WHERE NTIMESTAMP# > TO_TIMESTAMP ('28-FEB-09 09.07.59.907000 PM') AND
NTIMESTAMP# < TO_TIMESTAMP ('28-MAR-09 09.07.59.907000 PM');

また、すべての監査レコードを監査証跡から削除するには、次の文を入力します。

DELETE FROM SYS.AUD$;

データベース監査証跡からレコードを削除できるのは、ユーザーSYS、またはSYSがSYS.AUD$に対するDELETE権限を付与したユーザーのみです。

注意:
監査証跡がいっぱいになっている場合に、接続が監査されているとき(つまり、AUDIT SESSION文を設定している場合)は、その接続に対応する監査レコードを監査証跡に挿入できないため、通常のユーザーはデータベースに接続できません。この場合、SYSDBA権限を持つSYSで接続し、領域を監査証跡で使用可能にします。SYSによる操作は標準監査証跡には記録されませんが、AUDIT_SYS_OPERATIONSパラメータをTRUEに設定した場合は監査されます。

データベース監査証跡表から行を削除すると、解放された領域をその表で再利用できるようになります。(SYS.AUD$表には、現行の監査証跡レコードを保持するために必要な数だけエクステントが割り当てられます)。この領域を表で再利用できるようにするのに特に必要な操作はありません。この領域を他の表に使用する場合は、次の手順を実行します。

1. AUD$表を、自動セグメント領域管理表領域に移動します。
次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION
(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD,
audit_trail_location_value => 'USERS');
END;
/

2. 次の文を実行します。

ALTER TABLE SYSTEM.AUD$ ENABLE ROW MOVEMENT;
ALTER TABLE SYSTEM.AUD$ SHRINK SPACE CASCADE;

3. AUD$表をSYSTEM表領域に戻すには、次の文を実行してください。

BEGIN
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION
(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD,
audit_trail_location_value => 'SYSTEM');
END;
/

データベース監査証跡表からすべての行を削除し、さらに他の表領域オブジェクト用に使用済領域を解放する場合、TRUNCATE TABLE文を使用します。次に例を示します。

TRUNCATE TABLE SYS.AUD$;

注意:
直接変更できるSYSオブジェクトは、SYS.AUD$およびSYS.FGA_LOG$のみです。

他の監査証跡削除操作

この項の内容は、次のとおりです。

- 監査証跡がクリーン・アップ用に初期化されたことの確認

- 任意の監査証跡タイプに対するデフォルトの監査証跡削除間隔の設定

- 初期化クリーン・アップ設定の取消し

- 監査証跡の削除ジョブを使用可能または使用禁止にする方法

- 指定した削除ジョブに対するデフォルトの監査証跡削除ジョブの間隔の設定

- 監査証跡の削除ジョブの削除

- アーカイブ・タイムスタンプ設定の消去

- データベース監査証跡のバッチ・サイズの消去

監査証跡がクリーン・アップ用に初期化されたことの確認

DBMS_AUDIT_MGMT.IS_CLEANUP_INITIALIZED関数を実行して、監査証跡がクリーン・アップ用に初期化されたかどうかを確認できます。監査証跡が初期化されている場合は、TRUEが戻されます。初期化されていない場合は、FALSEが戻されます。

次に例を示します。

SET SERVEROUTPUT ON
BEGIN
IF
DBMS_AUDIT_MGMT.IS_CLEANUP_INITIALIZED(DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD)
THEN
DBMS_OUTPUT.PUT_LINE('AUD$ is initialized for cleanup');
ELSE
DBMS_OUTPUT.PUT_LINE('AUD$ is not initialized for cleanup.');
END IF;
END;
/

この例では、データベースの標準監査証跡が初期化されているかどうかを確認し、そのステータスを示すメッセージを戻しています。別の監査証跡の設定を選択するには、「手順3: クリーン・アップ操作のための監査証跡の初期化」で説明したAUDIT_TRAIL_TYPE設定から選択します。

任意の監査証跡タイプに対するデフォルトの監査証跡削除間隔の設定

指定した監査証跡タイプに対して次の削除操作が実行されるまでのデフォルトの削除操作間隔を時間単位で設定できます。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
AUDIT_TRAIL_PROPERTY        => DBMS_AUDIT_MGMT.CLEAN_UP_INTERVAL,
AUDIT_TRAIL_PROPERTY_VALUE  => 24 );
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: 監査証跡タイプ(この例では、データベースの標準監査証跡)を指定します。次の設定から選択します。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: 標準監査証跡表とファイングレイン監査証跡表の両方です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。)

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XMLオペレーティング・システム監査証跡ファイルです。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: オペレーティング・システム監査証跡ファイルとXML監査証跡ファイルの両方です。

- DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: すべての監査証跡レコード、つまりデータベース監査証跡タイプとオペレーティング・システム監査証跡タイプの両方です。

競合しないかぎり、複数の監査証跡タイプに対してデフォルトの間隔を設定できます。たとえば、DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STDおよびDBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STDプロパティに対しては個別の間隔を設定できますが、DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STDプロパティに対しては設定できません。

- AUDIT_TRAIL_PROPERTY: DBMS_AUDIT_MGMT.CLEAN_UP_INTERVALプロパティを設定して、削除操作の間隔設定を指定します。現行のプロパティ設定を調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューのPARAMETER_NAMEおよびPARAMETER_VALUE列を問い合せます。DBMS_AUDIT_MGMT.CLEAN_UP_INTERVALプロパティを設定すると、計時が開始されます。

- AUDIT_TRAIL_PROPERTY_VALUE: DBMS_AUDIT_MGMT.INIT_CLEANUPプロシージャで設定したデフォルトの間隔(時間単位)を更新します。1から999の値を入力します。

初期化クリーン・アップ設定の取消し

DBMS_AUDIT_MGMT.DEINIT_CLEANUPプロシージャを実行して、DBMS_AUDIT_MGMT.INIT_CLEANUP設定(つまり、デフォルトのクリーン・アップ間隔)を取り消すことができます。

たとえば、標準監査証跡のすべての削除設定を取り消すには、次のように入力します。

BEGIN
DBMS_AUDIT_MGMT.DEINIT_CLEANUP(
AUDIT_TRAIL_TYPE  => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD);
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: 「手順3: クリーン・アップ操作のための監査証跡の初期化」に示したAUDIT_TRAIL_TYPE設定のいずれかを入力します。

監査証跡の削除ジョブを使用可能または使用禁止にする方法

監査証跡の削除ジョブを使用可能または使用禁止にするには、DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUS PL/SQLプロシージャを使用します。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUS(
AUDIT_TRAIL_PURGE_NAME      => 'OS_Audit_Trail_PJ',
AUDIT_TRAIL_STATUS_VALUE    => DBMS_AUDIT_MGMT.PURGE_JOB_ENABLE);
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_PURGE_NAME: OS_Audit_Trail_PJという削除ジョブを指定します。既存の削除ジョブを調べるには、DBA_AUDIT_MGMT_CLEANUP_JOBSデータ・ディクショナリ・ビューのJOB_NAMEおよびJOB_STATUS列を問い合せます。

- AUDIT_TRAIL_STATUS_VALUE: 次のプロパティのいずれかを入力します。

- DBMS_AUDIT_MGMT.PURGE_JOB_ENABLE: 指定した削除ジョブを使用可能にします。

- DBMS_AUDIT_MGMT.PURGE_JOB_DISABLE: 指定した削除ジョブを使用禁止にします。

指定した削除ジョブに対するデフォルトの監査証跡削除ジョブの間隔の設定

次の削除ジョブ操作が実行されるまでのデフォルトの削除操作間隔を時間単位で設定できます。DBMS_AUDIT_MGMT.CREATE_PURGE_JOBプロシージャで使用される間隔設定が、この設定よりも優先されます。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.SET_PURGE_JOB_INTERVAL(
AUDIT_TRAIL_PURGE_NAME       => 'OS_Audit_Trail_PJ',
AUDIT_TRAIL_INTERVAL_VALUE   => 24 );
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_PURGE_NAME: 監査証跡の削除ジョブの名前を指定します。既存の削除ジョブのリストを調べるには、DBA_AUDIT_MGMT_CLEANUP_JOBSデータ・ディクショナリ・ビューのJOB_NAMEおよびJOB_STATUS列を問い合せます。

- AUDIT_TRAIL_INTERVAL_VALUE: DBMS_AUDIT_MGMT.CREATE_PURGE_JOBプロシージャで設定したデフォルトの間隔(時間単位)を更新します。1から999の値を入力します。削除ジョブを実行すると、計時が開始されます。

監査証跡の削除ジョブの削除

監査証跡の削除ジョブを削除するには、DBMS_AUDIT_MGMT.DROP_PURGE_JOB PL/SQLプロシージャを使用します。既存の削除ジョブを調べるには、DBA_AUDIT_MGMT_CLEANUP_JOBSデータ・ディクショナリ・ビューのJOB_NAMEおよびJOB_STATUS列を問い合せます。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.DROP_PURGE_JOB(
AUDIT_TRAIL_PURGE_NAME  => 'FGA_Audit_Trail_PJ');
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_PURGE_NAME: FGA_Audit_Trail_PJという削除ジョブを指定します。

アーカイブ・タイムスタンプ設定の消去

アーカイブ・タイムスタンプ設定を消去するには、DBMS_AUDIT_MGMT.CLEAR_LAST_ARCHIVE_TIMESTAMP PL/SQLプロシージャを使用します。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.CLEAR_LAST_ARCHIVE_TIMESTAMP(
AUDIT_TRAIL_TYPE     =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML',
RAC_INSTANCE_NUMBER  =>  1 );
END;
/

この例の説明は、次のとおりです。

- RAC_INSTANCE_NUMBER: AUDIT_TRAIL_TYPEプロパティをDBMS_AUDIT_MGMT.AUDIT_TRAIL_OSまたはDBMS_AUDIT_MGMT.AUDIT_TRAIL_XMLに設定している場合、RAC_INSTANCE_NUMBERを0に設定することはできません。この設定は省略することも、インスタンス番号を示す1を指定することもできます。
AUDIT_TRAIL_TYPEをDBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STDまたはDBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STDに設定している場合、またはデータベースがOracle RACデータベースでない場合は、RAC_INSTANCE_NUMBER設定を省略できます。それ以外の場合は、正しいインスタンス番号を指定します。インスタンス番号を調べるには、SQL*PlusでSHOW PARAMETER INSTANCE_NUMBERコマンドを発行します。

データベース監査証跡のバッチ・サイズの消去

バッチ・サイズの設定を消去するには、DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTYプロシージャを使用します。

次に例を示します。

BEGIN
DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY(
AUDIT_TRAIL_TYPE        =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
AUDIT_TRAIL_PROPERTY    =>  DBMS_AUDIT_MGMT.DB_DELETE_BATCH_SIZE,
USE_DEFAULT_VALUES      =>  TRUE );
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: 監査証跡タイプ(この例では、データベース・システム監査証跡)を指定します。「手順6: 監査証跡レコードのバッチ削除の構成(必要に応じて)」に示したAUDIT_TRAIL_TYPE値のいずれかを入力します。

- AUDIT_TRAIL_PROPERTY: DB_DELETE_BATCH_SIZEプロパティを指定します。このプロパティの現行のステータスを調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューを問い合せます。

- USE_DEFAULT_VALUES: TRUEに設定します。これにより、監査レコードの現行のバッチ・サイズが消去され、かわりにデフォルト値の10000が使用されます。

例: データベース監査証跡の削除操作の直接コール

例9-27の疑似コードはデータベース監査証跡削除操作を作成します。この操作は、ユーザーがDBMS_ADUIT.CLEAN_AUDIT_TRAILプロシージャを起動することでコールします。この削除操作では、ループを使用することで、前回アーカイブされたタイムスタンプより前に作成されたレコードを削除します。ループは監査レコードをアーカイブし、どの監査レコードがアーカイブされたかを計算してSetCleanUpAuditTrailコールを使用して最終アーカイブ・タイムスタンプを設定し、それからCLEAN_AUDIT_TRAILプロシージャをコールします。これにより、データベース監査証跡レコードが100,000個のレコードのバッチごとに削除されます。この例では、重要な手順は太字で示しています。

例9-27 データベース監査証跡の削除操作の直接コール

-- 1. Initialize the AUD$ table for cleanup:
PROCEDURE CleanUpAuditTrailMain()
BEGIN
-- Connect to the database using appropriate login.
CALL ConnectToDatabase();
-- The login used must have privileges to modify Audit settings.
-- Currently, the DBA will be the authorized user

DBMS_AUDIT_MGMT.INIT_CLEANUP(
AUDIT_TRAIL_TYPE           => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
DEFAULT_CLEANUP_INTERVAL   => 12 );
END; /*PROCEDURE */
/
-- 2. Optionally, set the batch size:
BEGIN
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
AUDIT_TRAIL_TYPE           => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
AUDIT_TRAIL_PROPERTY       => DBMS_AUDIT_MGMT.DB_DELETE_BATCH_SIZE,
AUDIT_TRAIL_PROPERTY_VALUE => 100000 /* delete batch size */);
END; /*PROCEDURE */
/
-- 3. Set the last archive timestamp:
PROCEDURE SetCleanUpAuditTrail()
BEGIN
CALL FindLastArchivedTimestamp(AUD$);
DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP(
AUDIT_TRAIL_TYPE          => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
LAST_ARCHIVE_TIME         => '20-AUG-2009 00:00:00');
END /* PROCEDURE */
/
-- 4. Run a customized archive procedure to purge the audit trail records:
BEGIN
CALL MakeAuditSettings();
LOOP (/* How long to loop*/)
-- Invoke function for audit record archival
CALL DoAuditRecordArchival(AUD$);

CALL SetCleanUpAuditTrail();
IF(/* Clean up is needed immediately */)
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
AUDIT_TRAIL_TYPE        => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
USE_LAST_ARCH_TIMESTAMP => TRUE);
END IF
END LOOP /*LOOP*/
END; /* PROCEDURE */
/

監査アクティビティに関する情報の検索

この項の内容は、次のとおりです。

- データ・ディクショナリ・ビューを使用した監査証跡に関する情報の検索

- 監査証跡ビューを使用した疑わしいアクティビティの調査

- 監査証跡ビューの削除

ヒント:
監査ポリシーに関するエラー情報を検索するには、トレース・ファイルを確認します。USER_DUMP_DEST初期化パラメータは、トレース・ファイルの位置を示します。

データ・ディクショナリ・ビューを使用した監査証跡に関する情報の検索

表9-7に、監査情報を提供するデータ・ディクショナリ・ビューを示します。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表9-7 データベース監査証跡に関する情報を表示するデータ・ディクショナリ・ビュー

ビュー

説明

ALL_AUDIT_POLICIES

現行ユーザーがアクセス可能な表とビューに対するファイングレイン監査ポリシーが表示されます。

ALL_AUDIT_POLICY_COLUMNS

現行ユーザーがアクセス可能な表とビューに対するファイングレイン監査ポリシーの列が表示されます。

ALL_DEF_AUDIT_OPTS

オブジェクトの作成時に適用されるデフォルトのオブジェクト監査オプションがリストされます。

AUDIT_ACTIONS

監査証跡のアクション・タイプ・コードが表示されます。

DBA_AUDIT_EXISTS

BY AUDIT NOT EXISTSによって生成された監査証跡エントリがリストされます。

DBA_AUDIT_MGMT_CLEAN_EVENTS

削除イベントの履歴が表示されます。定期的に、SYSDBA権限を持つユーザーSYSで接続し、このビューが大きくなりすぎないように、内容を削除する必要があります。次に例を示します。

DELETE FROM DBA_AUDIT_MGMT_CLEAN_EVENTS;

DBA_AUDIT_MGMT_CLEANUP_JOBS

現在構成されている監査証跡の削除ジョブが表示されます。

DBA_AUDIT_MGMT_CONFIG_PARAMS

現在構成されている監査証跡プロパティが表示されます。これらのプロパティは、DBMS_AUDIT_MGMT PL/SQLパッケージで使用されます。

DBA_AUDIT_MGMT_LAST_ARCH_TS

監査証跡の削除用に設定された最後のアーカイブ・タイムスタンプが表示されます。

DBA_AUDIT_OBJECT

システム内にあるすべてのオブジェクトの監査証跡レコードがリストされます。

DBA_AUDIT_POLICIES

システム上にあるすべてのファイングレイン監査ポリシーがリストされます。

DBA_AUDIT_SESSION

CONNECTおよびDISCONNECTに関する監査証跡レコードがすべてリストされます。

DBA_AUDIT_POLICY_COLUMNS

データベース全体の表とビューに対するファイングレイン監査ポリシーの列が表示されます。

DBA_AUDIT_STATEMENT

データベース全体のGRANT、REVOKE、AUDIT、NOAUDITおよびALTER SYSTEM文に関する監査証跡レコードがリストされます。

DBA_AUDIT_TRAIL

AUD$表にある標準監査証跡のエントリがすべてリストされます。

DBA_COMMON_AUDIT_TRAIL

標準監査とファイングレイン監査のログ・レコードが結合され、XML形式で書き込まれたSYSおよび必須監査レコードが含まれます。

DBA_FGA_AUDIT_TRAIL

ファイングレイン監査の監査証跡レコードがリストされます。

DBA_OBJ_AUDIT_OPTS

監査オプションが有効なオブジェクトが表示されます。

DBA_PRIV_AUDIT_OPTS

監査対象となっている現行のシステム権限がシステム全体およびユーザー別に表示されます。

DBA_STMT_AUDIT_OPTS

現行の文監査オプションがシステム全体およびユーザー別に表示されます。

USER_AUDIT_OBJECT

現行ユーザーがアクセス可能なオブジェクトに関する文の監査証跡レコードがリストされます。

USER_AUDIT_POLICIES

現行ユーザーがアクセス可能な表とビューに対するファイングレイン監査ポリシーの列が表示されます。

USER_AUDIT_SESSION

現行ユーザーの接続および切断に関する監査証跡レコードがすべてリストされます。

USER_AUDIT_STATEMENT

ユーザーが発行したGRANT、REVOKE、AUDIT、NOAUDITおよびALTER SYSTEM文に関する監査証跡レコードがリストされます。

USER_AUDIT_TRAIL

AUD$表にある現行ユーザー関連の標準監査証跡のエントリがすべてリストされます。

USER_OBJ_AUDIT_OPTS

現行ユーザーが所有するすべてのオブジェクトの監査オプションが表示されます。

V$LOGMNR_CONTENTS

ログの履歴情報が表示されます。このビューを問い合せるには、SELECT ANY TRANSACTION権限が必要です。

V$XML_AUDIT_TRAIL

XML形式のファイルに書き込まれた標準監査、ファイングレイン監査、SYS監査および必須監査のレコードが表示されます。

監査証跡ビューを使用した疑わしいアクティビティの調査

ここでは、監査証跡情報の検討方法と解釈方法の具体例を説明します。次の疑わしいアクティビティについて、データベースを監査するとします。

- データベース・ユーザーのパスワード、表領域の設定および割当て制限が許可なく変更されている。

- おそらく排他的に表ロックを取得しているユーザーが原因で、デッドロックが頻繁に発生している。

- laurelのスキーマ内にあるemp表から行が任意に削除されている。

これらの不正なアクションのいくつかは、ユーザーjwardとswilliamsによって行われた疑いがあります。

調査を行うには、次の文を順序どおりに発行します。

AUDIT ALTER, INDEX, RENAME ON DEFAULT;
CREATE VIEW laurel.employee AS SELECT * FROM laurel.emp;
AUDIT SESSION BY jward, swilliams;
AUDIT ALTER USER;
AUDIT LOCK TABLE
BY ACCESS
WHENEVER SUCCESSFUL;
AUDIT DELETE ON laurel.emp
BY ACCESS
WHENEVER SUCCESSFUL;

その後、ユーザーjwardによって次の文が発行されました。

ALTER USER tsmith QUOTA 0 ON users;
DROP USER djones;

その後、ユーザーswilliamsによって次の文が発行されました。

LOCK TABLE laurel.emp IN EXCLUSIVE MODE;
DELETE FROM laurel.emp WHERE mgr = 7698;
ALTER TABLE laurel.emp ALLOCATE EXTENT (SIZE 100K);
CREATE INDEX laurel.ename_index ON laurel.emp (ename);
CREATE PROCEDURE laurel.fire_employee (empid NUMBER) AS
BEGIN
DELETE FROM laurel.emp WHERE empno = empid;
END;
/

EXECUTE laurel.fire_employee(7902);

次の各項では、データ・ディクショナリ内の監査証跡ビューを使用して表示できる情報のうち、この調査に関連するものを示します。

- アクティブな文監査オプションのリスト

- アクティブな権限監査オプションのリスト

- 特定のオブジェクトに対するアクティブなオブジェクト監査オプションのリスト

- デフォルトのオブジェクト監査オプションのリスト

- 監査レコードのリスト

- AUDIT SESSIONオプションの監査レコードのリスト

アクティブな文監査オプションのリスト

次の問合せを実行すると、設定されている文監査オプションがすべて表示されます。

SELECT * FROM DBA_STMT_AUDIT_OPTS;

次のような出力が表示されます。

USER_NAME               AUDIT_OPTION         SUCCESS         FAILURE
--------------------    -------------------  ----------      ---------
JWARD                   DROP ANY CLUSTER     BY ACCESS       BY ACCESS
SWILLIAMS               DEBUG PROCEDURE      BY ACCESS       BY ACCESS
MSEDLAK                 ALTER RESOURCE COST  BY ACCESS       BY ACCESS

アクティブな権限監査オプションのリスト

次の問合せを実行すると、設定されている権限監査オプションがすべて表示されます。

SELECT * FROM DBA_PRIV_AUDIT_OPTS;

次のような出力が表示されます。

USER_NAME           PRIVILEGE            SUCCESS      FAILURE
------------------- -------------------- ---------    ----------
PSMITH              BY ACCESS            BY ACCESS

特定のオブジェクトに対するアクティブなオブジェクト監査オプションのリスト

次の問合せを実行すると、名前がempという文字で始まり、かつlaurelのスキーマ内に格納されているオブジェクトについて、監査オプションの設定がすべて表示されます。

SELECT * FROM DBA_OBJ_AUDIT_OPTS
WHERE OWNER = 'LAUREL' AND OBJECT_NAME LIKE 'EMP%';

次のような出力が表示されます。

OWNER   OBJECT_NAME OBJECT_TY ALT AUD COM DEL GRA IND INS LOC ...
-----   ----------- --------- --- --- --- --- --- --- --- --- ...
LAUREL EMP         TABLE     S/S -/- -/- A/- -/- S/S -/- -/- ...
LAUREL EMPLOYEE    VIEW      -/- -/- -/- A/- -/- S/S -/- -/- ...

このビューでは、指定したオブジェクトに対するすべての監査オプションの情報が表示されます。このビューの情報は、次のように解釈します。

- ハイフン(-)は、監査オプションが何も設定されていないことを示します。

- 文字Sは、監査オプションがBY SESSIONに設定されていることを示します。

- 文字Aは、監査オプションがBY ACCESSに設定されていることを示します。

- 各監査オプションには、可能な設定としてWHENEVER SUCCESSFULとWHENEVER NOT SUCCESSFULの2つがあり、スラッシュ(/)で区切られています。たとえば、laurel.empに対するDELETE監査オプションは、正常終了したDELETE文に対してBY ACCESSが設定されています。異常終了したDELETE文に対しては何も設定されていません。

デフォルトのオブジェクト監査オプションのリスト

次の問合せを実行すると、デフォルトのオブジェクト監査オプションがすべて表示されます。

SELECT * FROM ALL_DEF_AUDIT_OPTS;

次のような出力が表示されます。

ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE FBK REA
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
S/S -/- -/- -/- -/- S/S -/- -/- S/S -/- -/- -/- -/- /-  -/-

このビューでは、USER_OBJ_AUDIT_OPTSとDBA_OBJ_AUDIT_OPTSの各ビューに類似した情報が表示されます(前出の例を参照)。

監査レコードのリスト

次の問合せを実行すると、データベース内のすべてのオブジェクトについて生成された監査レコードがリストされます。

SELECT * FROM DBA_AUDIT_OBJECT;

AUDIT SESSIONオプションの監査レコードのリスト

次の問合せを実行すると、AUDIT SESSION文監査オプションに対応する監査情報がリストされます。

SELECT USERNAME, LOGOFF_TIME, LOGOFF_LREAD, LOGOFF_PREAD,
LOGOFF_LWRITE, LOGOFF_DLOCK
FROM DBA_AUDIT_SESSION;

次のような出力が表示されます。

USERNAME   LOGOFF_TI LOGOFF_LRE LOGOFF_PRE LOGOFF_LWR LOGOFF_DLO
---------- --------- ---------- ---------- ---------- ----------
JWARD      02-AUG-91         53          2         24          0
SWILLIAMS  02-AUG-91       3337        256        630          0

監査証跡ビューの削除

監査機能を使用禁止にしていて監査証跡ビューが不要な場合は、SYSでデータベースに接続して、スクリプト・ファイルCATNOAUD.SQLを実行することによって、ビューを削除できます。CATNOAUD.SQLスクリプトの位置は、オペレーティング・システムによって異なります。

脚注

脚注1: 非データベース・ユーザーとは、CLIENT_IDENTIFIER属性を使用してデータベースで認識されるアプリケーション・ユーザーのことです。このタイプのユーザーを監査するには、ファイングレイン監査ポリシーを使用します。詳細は、「ファイングレイン監査を使用した特定のアクティビティの監査」を参照してください。
脚注2: Oracle Databaseでは、データベース・ユーザーおよび非データベース・ユーザーの両方のアクションがSYS.AUD$表およびSYS.FGA_LOG$表に記録されます。これらの表にあるCLIENTID列には、非データベース・ユーザーの名前が記録されます。SYS.AUD$表のUSERID列とSYS.FGA_LOG$のDBUID列には、データベース・ユーザーのアカウントが保存されます。非データベース・ユーザーの場合、USERIDおよびDBUID列には、非データベース・ユーザーがデータベースにアクセスできるように作成されたデータベース・ユーザー・アカウントが保存されます。DBA_AUDIT_TRAIL、DBA_FGA_AUDIT_TRAILおよびDBA_COMMON_AUDIT_TRAILビューでは、この情報がCLIENT_ID、USERNAMEおよびDB_USER列に保存されます。

10 Oracle Databaseの安全性の維持

この章の内容は、次のとおりです。

- この章で説明するセキュリティ・ガイドラインの概要

- セキュリティ・パッチのダウンロードと脆弱性についてのOracleへの連絡

- ユーザー・アカウントと権限の保護に関するガイドライン

- ロールの保護に関するガイドライン

- パスワードの保護に関するガイドライン

- データの保護に関するガイドライン

- ORACLE_LOADERアクセス・ドライバの保護に関するガイドライン

- データベースのインストールと構成の保護に関するガイドライン

- ネットワークの保護に関するガイドライン

- 監査に関するガイドライン

- CONNECTロール変更への対処

この章で説明するセキュリティ・ガイドラインの概要

この章では、Oracle Databaseの安全性を維持するための一連のガイドラインを示します。情報のセキュリティとプライバシ、および企業の資産とデータの保護は、どのようなビジネスにおいても非常に重要です。Oracle Databaseは、厳重なデータ保護、監査、スケーラブルなセキュリティ、安全なホスティング、データ交換などの最先端のセキュリティ機能を提供することによって、情報セキュリティに対するニーズに幅広く対応します。

Oracle Databaseは、セキュリティ機能において業界をリードしています。Oracle Databaseが提供するセキュリティ機能をすべてのビジネス環境で最大限に活用するには、データベース自体の保護が万全であることが必須条件です。

セキュリティ・ガイドラインは、運用データベースのデプロイメントに関する業界標準として推奨されるセキュリティ・プラクティスに準拠し、それを推奨することによって、Oracle Databaseを安全に構成する方法を示しています。この項で説明するガイドラインの多くは、米国サーベンス・オクスリー法(Sarbanes-Oxley Act)で規定されているような一般的な規制要件に対応しています。法令順守、個人を特定できる情報の保護、および内部の脅威に対するOracle Databaseの対処方法の詳細は、次の場所を参照してください。

http://www.oracle.com/technetwork/topics/security/whatsnew/index.html

セキュリティ・パッチのダウンロードと脆弱性についてのOracleへの連絡

この項の内容は、次のとおりです。

- セキュリティ・パッチと回避ソリューションの適用

- Oracle Databaseの脆弱性に関するOracleのセキュリティ窓口への連絡

セキュリティ・パッチと回避ソリューションの適用

Oracle Databaseを稼働しているオペレーティング・システムとOracle Database自体、およびインストール済のOracle Databaseのオプションとコンポーネントすべてについて、関連するセキュリティ・パッチはすべて適用してください。

次のOracle Technology Networkのセキュリティ・サイトを定期的にチェックし、オラクル社からリリースされるセキュリティ・アラートの詳細を確認してください。

http://www.oracle.com/technetwork/topics/security/alerts-086861.html">>http://www.oracle.com/technetwork/topics/security/alerts-086861.html

また、Oracleワールドワイド・サポート・サービスのサイト、My Oracle Supportもチェックして、セキュリティに関するパッチの入手可能性や予定などを確認してください。

https://support.oracle.com

Oracle Databaseの脆弱性に関するOracleのセキュリティ窓口への連絡

OracleユーザーまたはOracleパートナであるユーザーがOracle製品の潜在的なセキュリティ上の脆弱性を発見した場合は、My Oracle Supportを使用してサービス・リクエストを発行してください。もしくは、製品のバージョンやプラットフォームも含めた問題の詳細を、スクリプトと例を添えて、電子メールでsecalert_us@oracle.comに送信してください。オラクル社にお問合せの際は、弊社の暗号鍵を使用して、電子メールを暗号化することをお薦めします。

ユーザー・アカウントと権限の保護に関するガイドライン

ユーザー・アカウントと権限を保護するには、次のガイドラインに従います。

1. 「最低限の権限」原則を実践する。

次のガイドラインに従うことをお薦めします。

1. 必要な権限のみを付与する。
データベース・ユーザーまたはロールに、必要以上の権限を付与しないでください。(可能な場合、ユーザーではなくロールに権限を付与してください。)つまり、最小権限の原則とは、ユーザーに、効率的かつ簡潔に作業を行うために実際に必要な権限のみを与えることです。

この原則を実装するには、次の項目について可能なかぎり制限します。

- データベース・ユーザーに付与するSYSTEMおよびOBJECT権限の数。

- SYS権限によってデータベースに接続できるユーザーの数。

- DROP ANY TABLE権限などのANY権限を付与する対象のユーザー数。たとえば、通常、DBA権限のないユーザーにCREATE ANY TABLE権限を付与する必要はありません。

- データベース・オブジェクトを(TRUNCATE TABLE、DELETE TABLE、DROP TABLE文などで)作成、変更または削除を実行できるユーザーの数。

2. CREATE ANY EDITIONおよびDROP ANY EDITION権限の付与を制限する。
オブジェクトの追加バージョンを維持するために、エディションではデータベース内のリソースおよびディスク領域の使用量を増やすことができます。CREATE ANY EDITIONおよびDROP ANY EDITION権限は、アップグレードの実行を担当する信頼できるユーザーにのみ付与します。

3. CREATE ANY JOB、BECOME USER、EXP_FULL_DATABASEおよびIMP_FULL_DATABASE権限を制限する。
これらは強力なセキュリティ関連権限です。これらの権限は、必要とするユーザーにのみ付与してください。

4. ライブラリ関連の権限を信頼できるユーザーのみに制限する。
CREATE LIBRARY、CREATE ANY LIBRARY、ALTER ANY LIBRARY、およびEXECUTE ANY LIBRARY権限と、EXECUTE ON library_nameの付与によって、ユーザーに大きい力が与えられます。ライブラリへのPL/SQLインタフェースを作成する場合は、PL/SQLインタフェースにEXECUTE権限を付与するのみにしてください。基礎となるライブラリにEXECUTEを付与しないでください。ライブラリへのPL/SQLインタフェースを作成するためには、ライブラリに対するEXECUTE権限が必要です。しかしユーザーは、自分自身のスキーマで作成するライブラリに対して暗黙的にこの権限を持っています。EXECUTE ON library_nameの明示的付与が必要になることはほとんどありません。これらの権限の明示的付与は、信頼できるユーザーに対してのみ行ってください。決してPUBLICロールに対して付与しないでください。

5. 制限シノニム関連の権限を信頼できるユーザーのみに制限する。
CREATE PUBLIC SYNONYMおよびDROP PUBLIC SYNONYMシステム権限によって、これらのユーザーに大きい力が与えられます。信頼できないかぎり、これらの権限をユーザーに付与しないでください。

6. SYSスキーマが所有するオブジェクトに、管理者以外のユーザーがアクセスできないようにする。
ユーザーが表の行やSYSスキーマのスキーマ・オブジェクトを変更できないようにしてください。変更されると、データ整合性が損われる危険があります。DROP TABLE、TRUNCATE TABLE、DELETE、INSERTなどの文、または類似したオブジェクト変更文のSYSオブジェクトに対する使用を、強い権限を持つ管理ユーザーのみに制限してください。

SYSスキーマはデータ・ディクショナリを所有します。データ・ディクショナリは、O7_DICTIONARY_ACCESSIBILITYパラメータをFALSEに設定することで保護できます。詳細は、「データの保護に関するガイドライン」の下にあるガイドライン1を参照してください。

7. DBMS_RANDOM PL/SQLパッケージに対するEXECUTE権限を、信頼できるユーザーにのみ付与する。
DBMS_RANDOMパッケージのEXECUTE権限は、通常は最低限のアクセス権しか持たないユーザーが、このパッケージに関連付けられたファンクションを実行するのを許可できます。

8. ランタイム機能の権限を制限する。
多くのOracle Database製品は、Oracle Java Virtual Machine(OJVM)などのランタイム機能を使用しています。データベース・ランタイム機能に対してすべての権限を割り当てないでください。かわりに、データベース外部のファイルやパッケージを実行する機能については、特定の権限を明示的なドキュメント・ルート・ファイル・パスに設定してください。

個別ファイルが指定された無防備なランタイム・コールの例:

call dbms_java.grant_permission('wsmith', 'SYS:java.io.FilePermission','<<ALL FILES>>','read');

かわりにディレクトリ・パスが指定された、適切な(安全性の高い)ランタイム・コールの例:

call dbms_java.grant_permission('wsmith', 'SYS:java.io.FilePermission','<<actual directory path>>','read');

2. デフォルト(事前定義)のユーザー・アカウントをロックし、期限切れにする。

Oracle Databaseをインストールすると、いくつかのデフォルトのデータベース・ユーザー・アカウントがインストールされます。Database Configuration Assistantは、データベースが正常にインストールされると、デフォルトのデータベース・ユーザー・アカウントの大半を自動的にロックし、期限切れにします。

Database Configuration Assistantを利用せずに手動でOracle Databaseをインストールした場合は、データベース・サーバーが正常にインストールされたときに、デフォルトのデータベース・ユーザーは一切ロックされません。あるいは、以前のリリースのOracle Databaseからアップグレードした場合、以前のリリースからのデフォルト・アカウントが設定されていることがあります。これらのデータベース・ユーザーをデフォルト状態のままにしておくと、それらのユーザー・アカウントを悪用してデータが不正にアクセスされたり、データベース操作が妨害される可能性があります。

デフォルトのデータベース・ユーザー・アカウントはすべてロックし、期限切れにする必要があります。Oracle Databaseには、この操作を実行するためのSQL文が用意されています。次に例を示します。

ALTER USER ANONYMOUS PASSWORD EXPIRE ACCOUNT LOCK;

ALTER USER文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

初期インストールの後に、製品およびコンポーネントを追加インストールすると、デフォルトのデータベース・アカウントがさらに作成されます。Database Configuration Assistantは、追加作成されたデータベースのすべてのユーザー・アカウントを自動的にロックし、期限切れにします。定期的にアクセスする必要があるアカウントのロックのみを解除し、解除した各アカウントに強固で有効なパスワードを割り当てます。この操作を実行するためのSQLおよびパスワード管理が用意されています。

なんらかの理由で、OPEN以外の状態にあるデフォルトのデータベース・ユーザー・アカウントが必要な場合、データベース管理者(DBA)は、そのアカウントのロックを解除し、安全性の高い新しいパスワードを設定してアクティブにする必要があります。

Oracle Databaseのインストール時に作成される事前定義のユーザー・アカウントの詳細は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

なんらかの理由で、OPEN以外の状態にあるデフォルトのデータベース・ユーザー・アカウントが必要な場合、データベース管理者(DBA)は、そのアカウントのロックを解除し、安全性の高い新しいパスワードを設定してアクティブにできます。

Oracle Enterprise Managerのアカウント

Oracle Enterprise Managerをインストールする場合は、Oracle Enterprise Managerを集中管理用に構成しないかぎり、SYSMANとDBSNMPアカウントはOPENとなります。この場合、SYSMANアカウント(存在する場合)はロックされます。

Oracle Enterprise Managerをインストールしない場合は、SYSとSYSTEMアカウントのみがOPENとなります。Database Configuration Assistantは、他のすべてのアカウント(SYSMANとDBSNMPを含む)をロックし、期限切れにします。

3. 次のデータ・ディクショナリ・ビューを使用して、データベースへのユーザー・アクセスに関する情報を検索する。

- DBA_*

- DBA_ROLES

- DBA_SYS_PRIVS

- DBA_ROLE_PRIVS

- DBA_TAB_PRIVS

- DBA_AUDIT_TRAIL(標準監査が使用可能な場合)

- DBA_FGA_AUDIT_TRAIL(ファイングレイン監査が使用可能な場合)

4. 次の権限が、それらを必要としているユーザーとロールのみに付与されていることを監視する。

デフォルトでは、次の権限がOracle Databaseによって監査されます。

- ALTER SYSTEM

- AUDIT SYSTEM

- CREATE EXTERNAL JOB

次の権限も監査することをお薦めします。

- ALL PRIVILEGES(BECOME USER、CREATE LIBRARY、CREATE PROCEDUREなどの権限を含む)

- DBMS_BACKUP_RESTOREパッケージ

- DBMS_SYS_SQLに対するEXECUTE権限

- SELECT ANY TABLE

- PERFSTAT.STATS$SQLTEXTに対するSELECT権限

- PERFSTAT.STATS$SQL_SUMMARYに対するSELECT権限

- SYS.SOURCE$に対するSELECT

- WITH ADMIN句付きの権限

- WITH GRANT句付きの権限

- CREATEキーワード付きの権限

5. 次のビューまたはロールからアクセス権を取り消す。

- SYSとDBAアカウント以外のすべてのユーザーからSYS.USER_HISTORY$表を取り消します。

- 通常のアプリケーション・アカウントからRESOURCEロールを取り消します。

- 通常のアプリケーション・アカウントからCONNECTロールを取り消します。

- DBAロールが不要なユーザーから、このロールを取り消します。

6. ロールに対してのみ権限を付与する。

個々のユーザーではなくロールに権限を付与すると、権限の管理および追跡が容易になります。

7. プロキシ・アカウント(プロキシ認可の場合)の権限をCREATE SESSIONのみに制限する。

8. セキュア・アプリケーション・ロールを使用して、アプリケーション・コードによって有効化するロールを保護する。

セキュア・アプリケーション・ロールでは、ユーザーがアプリケーションにログインできるかどうかを判断する一連の条件を、PL/SQLパッケージ内で定義できます。ユーザーはセキュア・アプリケーション・ロールではパスワードを使用する必要がありません。

ロールがアプリケーション内で使用可能または使用禁止になるのを防ぐ別の方法は、ロールのパスワードを使用することです。この方法では、ユーザーが、データベースにSQL(アプリケーションではなく)で直接アクセスして、ロールに関連付けられている権限を使用することを防ぎます。ただし、別の一連のパスワードを管理する必要がないように、セキュア・アプリケーション・ロールの使用をお薦めします。

9. ユーザーが、SQL文でNOLOGGING句を使用できないようにする。

いくつかのSQL文で、ユーザーはオプションとしてNOLOGGING句を指定できます。このオプションを指定すると、データベース操作がオンラインREDOログ・ファイルに記録されません。ユーザーがこの句を指定しても、REDOレコードがオンラインREDOログ・ファイルに書き込まれます。しかし、このレコードに関連付けられたデータはありません。このため、NOLOGGINGを使用すると、不正コードが入力されて、監査証跡に記録されずに実行される可能性があります。

ロールの保護に関するガイドライン

ロールを管理する際には、次のガイドラインに従います。

1. ロールは、そのロールの権限すべてを必要とするユーザーにのみ付与する。
ロール(権限のグループ)は、ユーザーに許可を素早く簡単に付与する場合に便利です。Oracleで定義されているロールを使用することもできますが、必要な権限のみを含む独自のロールを作成すると、より継続的な制御が可能になります。Oracle Database定義ロールの権限は変更または削除される場合があります。たとえばCONNECTロールの場合、現在持っている権限はCREATE SESSION権限のみです。以前は他に8個の権限がありました。

定義したロールには担当業務を反映する権限のみが含まれていることを確認してください。アプリケーション・ユーザーが既存のロールに組み込まれている権限のすべては必要としていない場合は、適切な権限のみを含む異なるロールのセットを適用してください。または、さらに権限が制限されているロールを作成して割り当てます。

たとえば、ユーザーSCOTTはよく知られているアカウントで、侵入されやすい可能性があるため、このユーザーの権限を厳密に制限する必要があります。CREATE DBLINK権限ではあるデータベースから別のデータベースへのアクセスが許可されるため、SCOTTに対するこの権限を削除します。次に、このユーザーのロール全体を削除します。これは、ロールによって付与される権限は、個別に削除できないためです。必要な権限のみを含む独自のロールを再作成し、新しいロールをユーザーに付与します。同様に、セキュリティを高めるために、CREATE DBLINK権限を必要としないすべてのユーザーからこの権限を削除します。

2. アプリケーション開発者にはユーザー・ロールを付与しない。
ストアド・プログラム構文内のスキーマ・オブジェクトにアクセスする権限は直接付与される必要があるため、ロールはアプリケーション開発者の使用を目的としていません。実行者権限プロシージャを除くストアド・プロシージャ内ではロールが有効でないことに注意してください。詳細は、「PL/SQLブロックでのロールの機能」を参照してください。

3. Oracle Databaseのインストールごとに固有のロールを作成して割り当てる。
これにより、組織でロールおよび権限を詳細に制御できます。また、現在はCREATE SESSION権限のみとなっているCONNECTなどのOracle Database定義のロールを、Oracle Databaseで変更または削除した場合の調整が不要となります。以前は他にも8つの権限がありました。

4. エンタープライズ・ユーザーに対してグローバル・ロールを作成する。
グローバル・ロールは、Oracle Internet Directoryなどのエンタープライズ・ディレクトリ・サービスで管理されます。グローバル・ロールの詳細は次の各項を参照してください。

- 「グローバルなユーザー認証と認可の構成」

- 「エンタープライズ・ディレクトリ・サービスによるグローバル・ロールの認可」

- 『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』

パスワードの保護に関するガイドライン

ユーザー・アカウントを作成すると、そのユーザーに対してデフォルトのパスワード・ポリシーが割り当てられます。このパスワード・ポリシーには、パスワードの作成方法(最小文字数や期限切れの時期など)についてのルールが定義されています。パスワードは、パスワード・ポリシーを使用することで強化できます。パスワードを保護するための別の方法については、「パスワード保護の構成」も参照してください。

パスワードをさらに強化するには、次のガイドラインに従います。

1. パスワードを慎重に選択する。

パスワードの最低要件については、「パスワードの最低要件」を参照してください。パスワードを作成または変更する際には、次の追加のガイドラインに従います。

- パスワードは12から30文字の英数字にします。

- パスワードには、数値、大文字および小文字を少なくとも1文字ずつ含めます。

- パスワードには、大/小文字と特殊文字を混在させて使用します。(詳細は、「パスワードのセキュリティへの脅威からのSHA-1ハッシュ・アルゴリズムによる保護」を参照してください。)

- パスワードには、マルチバイト・キャラクタを含めることができます。

- パスワードの文字にはデータベース・キャラクタ・セットを使用します。このセットには、アンダースコア(_)、ドル記号($)および番号記号(#)の各文字があります。

- 次のパスワードは二重引用符で囲む必要があります。

- マルチバイト・キャラクタを含むパスワード。

- 数値または特殊文字で始まり、アルファベットを含むパスワード。例:
"123abc"

"#abc"

"123dc$"

- アルファベット、数値および特殊文字以外の文字を含むパスワード。例:
"abc>"

"abc@"

" "

- 次のパスワードは二重引用符で囲む必要はありません。

- アルファベット(aからz、AからZ)で始まり、数字(0から9)または特殊文字($、#、_)を含むパスワード。次に例を示します。
abc123

ab23a

ab$#_

- 数値のみを含むパスワード。

- アルファベットのみを含むパスワード。

- 意味のある単語のみで構成されるパスワードを使用しないでください。

2. より長く複雑で覚えやすいパスワードを作成するには、次のテクニックを使用します。

- 覚えやすいセンテンスの各語の1文字目からパスワードを作成します。たとえば、"I usually work until 6 almost every day of the week"であれば、Iuwu6aedotwとなります。

- welcome1とbinkyのように、解読可能な2つのパスワードを組み合せてWelBinkyCome1とします。

- パスワードの先頭または末尾の1文字を繰り返します。

- 作成するパスワードの先頭または末尾に、文字列、別のパスワードまたは同じパスワードの一部を追加します。たとえば、パスワードfussy2allは次のように変更できます。

- fussy2all34hj2

- WelBinkyCome1fussy2all

- fusfussy2all

- 一部またはすべての文字を重複させます。たとえば、welcome13をwwellCcooMmee13とすることができます。

3. 十分複雑なパスワードを使用するようにする。
Oracle Databaseには、パスワードの複雑度が十分であるかどうかをチェックするためのパスワード検証ルーチン(PL/SQLスクリプトUTLPWDMG.SQL)が用意されています。理想的には、UTLPWDMG.SQLスクリプトを編集して、パスワードの安全性を高めます。パスワードのチェックに使用できるサンプル・ルーチンについては、「パスワードの複雑度検証の規定」も参照してください。

4. ユーザー・プロファイルまたはデフォルト・プロファイルに対してパスワード・ファンクションを関連付けます。
CREATE PROFILE文とALTER PROFILE文のPASSWORD_VERIFY_FUNCTION句により、ユーザー・プロファイルまたはデフォルト・プロファイルにパスワード・ファンクションが関連付けられます。パスワード・ファンクションでは、ユーザーがそのサイトに固有のガイドラインを使用して強力なパスワードを作成しているかどうかを確認します。また、パスワード・ファンクションでは、(ALTER USERシステム権限を使用せずに)ユーザーが各自のパスワードを変更して、古いパスワードと新しいパスワードの両方を指定する必要があります。独自のパスワード・ファンクションを作成したり、Oracle Databaseが提供するパスワード・ファンクションを使用できます。

詳細は、「パスワードの複雑度検証のカスタマイズ」を参照してください。

5. デフォルトのユーザー・パスワードを変更する。

Oracle Databaseは、事前定義のデフォルト・ユーザー・アカウントのセットとともにインストールされます。セキュリティは、デフォルトのデータベース・ユーザー・アカウントがインストール後もデフォルト・パスワードを使用している場合に最も崩壊しやすくなります。ユーザー・アカウントSCOTTはよく知られているアカウントで侵入されやすい可能性があるため、これが特に当てはまります。Oracle Database 11gリリース2 (11.2)では、デフォルトのアカウントはロックされ、パスワードは期限切れの状態でインストールされますが、以前のリリースからのアップグレードの場合は、デフォルトのパスワードを使用しているアカウントが存在している場合があります。

デフォルトのパスワードが設定されているユーザー・アカウントを検索するには、DBA_USERS_WITH_DEFPWDデータ・ディクショナリ・ビューを問い合せます。詳細は、「デフォルト・パスワードが設定されているユーザー・アカウントの検索」を参照してください。

6. 管理ユーザーのデフォルト・パスワードを変更する。

SYS、SYSTEM、SYSMANおよびDBSNMPの管理アカウントには、同じパスワードまたは異なるパスワードを使用できます。それぞれに対して異なるパスワードを使用することをお薦めします。つまり、すべてのOracle環境(本番またはテスト)において、これらの管理アカウントに強固で安全性の高い、個別のパスワードを割り当てます。Database Configuration Assistantを使用して新規データベースを作成する場合は、SYSおよびSYSTEMアカウントにパスワードを入力して、デフォルトのパスワードCHANGE_ON_INSTALLおよびMANAGERを使用できないようにします。

同様に、本番環境では、SYSMANおよびDBSNMPも含めて、管理アカウントにはデフォルトのパスワードを使用しないでください。

デフォルト・パスワードの変更の詳細は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

7. パスワード管理を徹底する。
基本的なパスワード管理ルール(パスワードの長さ、履歴など)をすべてのユーザー・パスワードに適用します。Oracle Databaseには、デフォルト・プロファイルで使用可能なパスワード・ポリシーがあります。この項のガイドライン1には、これらのパスワード・ポリシーがリストされています。ユーザー・パスワードの安全性をさらに高めるために使用できる初期化パラメータについては、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

ユーザー・アカウントの情報を検索するには、DBA_USERSビューを問い合せます。DBA_USERSビューのPASSWORD列は、パスワードがグローバル、外部またはNULLのいずれであるかを示します。DBA_USERSビューには、ユーザー・アカウントの状態、アカウントがロックされているかどうか、パスワードのバージョンなどの有用な情報が表示されます。

また、可能な場合は、Oracle Advanced Security(Oracle Database Enterprise Editionのオプション)を、ネットワーク認証サービス(Kerberosなど)、トークン・カード、スマート・カードまたはX.509証明書と一緒に使用することもお薦めします。これらのサービスを使用すると、ユーザーの厳密な認証が可能になるため、Oracle Databaseを不正なアクセスから保護できます。

8. Oracle表にはユーザー・パスワードをクリアテキストで格納しない。
セキュリティを強化するために、Oracle表には、ユーザー・パスワードをクリアテキスト(判読可能なテキスト)で格納しないでください。この問題は、安全性の高い外部パスワード・ストアを使用してパスワードが記載されている表の列を暗号化することで解決できます。詳細は、「パスワード資格証明用の安全性の高い外部パスワード・ストアの管理」を参照してください。

ユーザー・アカウントのパスワードを作成または変更すると、Oracle Databaseでは、そのパスワードの暗号化ハッシュまたはダイジェストが自動的に作成されます。DBA_USERSビューを問い合せてユーザー・アカウントの情報を検索する場合、PASSWORD列のデータはユーザー・パスワードがグローバル、外部またはNULLのいずれかであるかを示します。

データの保護に関するガイドライン

システムのデータを保護するには、次のガイドラインに従います。

1. データ・ディクショナリの保護を有効にする。

ANYシステム権限を持つユーザーがデータ・ディクショナリに対してそれぞれの権限を使用しないように、データ・ディクショナリを保護することをお薦めします。データ・ディクショナリ表のデータを変更または操作すると、データベースの操作に永続的に有害な影響を与える可能性があります。

データ・ディクショナリ保護を有効にするには、initsid.ora制御ファイルで、次の初期化パラメータをFALSE(デフォルト)に設定します。

O7_DICTIONARY_ACCESSIBILITY = FALSE

O7_DICTIONARY_ACCESSIBILITYパラメータは、サーバー・パラメータ・ファイルに設定できます。サーバー・パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

O7_DICTIONARY_ACCESSIBILTYをFALSEに設定した後は、SELECT ANY DICTIONARY権限を持つユーザーと、DBA権限での接続(たとえば、CONNECT / AS SYSDBA)を許可されたユーザーのみがデータ・ディクショナリに対してANYシステム権限を使用できます。O7_DICTIONARY_ACCESSIBILITYパラメータがFALSEに設定されていない場合は、たとえば、DROP ANY TABLEシステム権限を持つユーザーであればだれでも、データ・ディクショナリの一部を削除できます。ただし、データ・ディクショナリへの参照アクセスが必要なユーザーには、SELECT ANY DICTIONARYシステム権限を付与できます。

注意:

- デフォルトのインストールでは、O7_DICTIONARY_ACCESSIBILITYパラメータはFALSEに設定されています。ただし、Oracle8iでは、デフォルトでTRUEに設定されているため、FALSEに変更して有効にする必要があります。

- SELECT ANY DICTIONARY権限はGRANT ALL PRIVILEGES文では付与できませんが、ロールを介して付与できます。ロールの詳細は、第4章「権限とロール認可の構成」を参照してください。

2. オペレーティング・システムのアクセスを制限する。
次のガイドラインに従ってください。

- オペレーティング・システムのユーザー数を制限します。

- Oracle Databaseが稼働しているホスト・コンピュータ上のオペレーティング・システム・アカウントの権限(管理、ルート権限またはDBA)を、ユーザーによる業務の遂行に必要な最小限の権限に制限してください。

- Oracle Databaseホーム(インストール)ディレクトリやその内容について、デフォルトのファイルやディレクトリのアクセス権を変更できる権限を制限します。オラクル社から特に指示がないかぎり、権限を持つオペレーティング・システム・ユーザーとOracle所有者は、これらのアクセス権を変更しないでください。

- シンボリック・リンクを制限します。データベースへのパスやファイルを指定する場合は、そのファイルやパスのどの部分も、信頼のおけないユーザーによる変更が不可能であることを確認します。ファイル、およびパスのすべての構成要素は、データベース管理者、またはrootなどの信頼できるアカウントが所有する必要があります。
この推奨事項は、データ・ファイル、ログ・ファイル、トレース・ファイル、外部表、BFILEデータ型など、あらゆるタイプのファイルに適用されます。

3. 機密性の高いデータと、データベース・ファイルが格納された全バックアップ・メディアを暗号化する。
一般的な法令順守要件に従って、クレジット・カード番号とパスワードなどの機密性の高いデータを暗号化する必要があります。データベースから機密性の高いデータを削除した場合、暗号化されたデータはデータ・ブロック、オペレーティング・システム・ファイルまたはディスク上のセクターに残りません。

多くの場合、透過的データ暗号化を使用して機密性の高いデータを暗号化する必要があります。詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。また、データを暗号化してはならないケースについては、「暗号化で解決しないセキュリティの問題」を参照してください。

4. LinuxおよびUNIXシステムでのOracle Automatic Storage Management(Oracle ASM)環境の場合、Oracle ASM File Access Controlを使用してOracle ASMディスク・グループへのアクセスを制御します。
様々なオペレーティング・システム・ユーザーおよびグループをOracle Databaseインストールで使用する場合は、Oracle ASM File Access Controlを構成して、Oracle ASMディスク・グループ内のファイルへのアクセスを、認可されたユーザーのみに制限できます。たとえば、データベース管理者がアクセスできるのは、データベース管理者が管理するデータベースのデータ・ファイルのみになります。この管理者は、他のデータベースに属している(使用される)データ・ファイルは参照することも上書きすることもできなくなります。

Oracle ASM File Access Controlのディスク・グループ管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。Linuxシステムでの複数のソフトウェア所有者に必要な様々な権限の詳細は、『Oracle Automatic Storage Management管理者ガイド』も参照してください。

ORACLE_LOADERアクセス・ドライバの保護に関するガイドライン

ORACLE_LOADERアクセス・ドライバを保護するには、次のガイドラインに従います。

1. アクセス・ドライバ・プリプロセッサを格納する、別個のオペレーティング・システム・ディレクトリを作成します。Oracle Databaseの各ユーザーが異なるプリプロセッサを実行する場合、オペレーティング・システム・マネージャは複数のディレクトリを作成する必要がある場合があります。特定のユーザーに対して、別のプリプロセッサへのアクセスを許可しながら、あるプリプロセッサの使用を禁止するには、そのプリプロセッサを別個のディレクトリに配置します。すべてのユーザーに同等のアクセス権を付与する必要がある場合は、プリプロセッサをまとめて1つのディレクトリに配置できます。これらのオペレーティング・システム・ディレクトリを作成した後、SQL*Plusで各ディレクトリのディレクトリ・オブジェクトを作成できます。

2. オペレーティング・システム・ユーザーORACLEに、アクセス・ドライバ・プリプロセッサを実行するための適切なオペレーティング・システム権限を付与します。また、プリプロセッサ・プログラムを、プリプロセッサ・プログラムの管理担当ユーザー以外のオペレーティング・システム・ユーザーによるWRITEアクセスから保護します。

3. ディレクトリ・オブジェクト内のプリプロセッサ・プログラムを実行する各ユーザーに、EXECUTE権限を付与します。このユーザーには、ディレクトリ・オブジェクトに対するWRITE権限を付与しないでください。ユーザーにディレクトリ・オブジェクトに対するEXECUTE権限とWRITE権限の両方を付与することはできません。

4. プリプロセッサを含むディレクトリ・オブジェクトを管理するユーザーに、慎重にWRITE権限を付与します。これにより、データベース・ユーザーが誤ってまたは意図的にプリプロセッサ・プログラムを上書きするのを防ぐことができます。

5. 外部表に必要なすべてのデータ・ファイルに対して、別個のオペレーティング・システム・ディレクトリおよびディレクトリ・オブジェクトを作成します。これらのディレクトリおよびディレクトリ・オブジェクトは、アクセス・ディレクトリ・プリプロセッサが使用するディレクトリおよびディレクトリ・オブジェクトとは別個であることが必要です。

オペレーティング・システム・マネージャとともに作業して、このディレクトリへのアクセス権が適切なオペレーティング・システム・ユーザーのみに付与されていることを確認します。ORACLEオペレーティング・システム・ユーザーに、データベース・ユーザーに付与されたREAD権限を持つディレクトリ・オブジェクトを含むすべてのディレクトリへのREADアクセス権を付与します。同様に、ORACLEオペレーティング・システム・ユーザーに、データベース・ユーザーに付与されたWRITE権限を持つすべてのディレクトリへのWRITEアクセス権を付与します。

6. アクセス・ドライバが生成するあらゆるファイルに対して、別々のオペレーティング・システム・ディレクトリおよびディレクトリ・オブジェクトを作成します。これには、ログ・ファイル、不良ファイル、および廃棄ファイルが含まれます。オペレーティング・システム・マネージャとともに、このディレクトリとディレクトリ・オブジェクトが、ガイドライン5で説明されているように適切な保護を受けていることを確認してください。データ・ファイル内の問題を解決するとき、データベース・ユーザーはこれらのファイルへのアクセスが必要になる場合があるため、このユーザーがこれらのファイルを読み取る方法をオペレーティング・システム・マネージャとともに決める必要があります。

7. CREATE ANY DIRECTORY権限とDROP ANY DIRECTORY権限を慎重に付与します。これらの権限を付与されたユーザーおよびDBAロールを付与されたユーザーは、すべてのディレクトリ・オブジェクトへの完全なアクセス権を持ちます。

8. DROP ANY DIRECTORY権限の監査を検討します。権限の監査の詳細は、「権限の監査」を参照してください。

9. ディレクトリ・オブジェクトの監査を検討します。詳細は、「ディレクトリ・オブジェクトの監査」を参照してください。

関連項目:
ORACLE_DATAPUMPアクセス・ドライバの詳細は、『Oracle Databaseユーティリティ』を参照してください。

データベースのインストールと構成の保護に関するガイドライン

このリリースでは、安全性を高めるために、Oracle Databaseのデフォルト構成に変更が加わりました。この項の推奨事項には、この新規のデフォルト構成が追加されています。

データベースのインストールと構成を保護するには、次のガイドラインに従います。

1. UNIXシステムの場合は、Oracle Databaseのインストールを開始する前に、Oracle所有者アカウントのumask値が022であることを確認する。
LinuxおよびUNIXシステム上のOracle Databaseを管理する方法の詳細は、『Oracle Database管理者リファレンス for Linux and UNIX-Based Operating Systems』を参照してください。

2. 必要なもののみをインストールする。
オプションと製品: Oracle DatabaseのCDパックには、データベース・サーバーだけでなく、製品およびオプションが含まれています。必要な場合にかぎり、製品およびオプションを追加してインストールします。カスタム・インストール機能を使用して必要のない製品のインストールを防止するか、もしくは通常のインストールを実行してから不要な製品およびオプションを削除してください。使用していない製品およびオプションは、維持する必要はありません。製品およびオプションは、必要に応じて簡単にインストールできます。

サンプル・スキーマ: Oracle Databaseには、例を示すための共通のプラットフォームを提供するサンプル・スキーマが用意されています。このサンプル・スキーマは、データベースを本番環境で使用する場合はインストールしないでください。サンプル・スキーマをテスト・データベースにインストールした場合は、本番に移行する前に、そのサンプル・スキーマのアカウントを削除または再びロックしてください。サンプル・スキーマの詳細は、『Oracle Databaseサンプル・スキーマ』を参照してください。

3. インストール時に、パスワードの入力を求めるプロンプトが表示された場合は、安全性の高いパスワードを作成する。
「パスワードの保護に関するガイドライン」のガイドライン1、5および6に従います。

4. インストール直後に、デフォルトのユーザー・アカウントをロックし、期限切れにする。
「ユーザー・アカウントと権限の保護に関するガイドライン」のガイドライン2を参照してください。

ネットワークの保護に関するガイドライン

ネットワーク通信のセキュリティは、クライアント、リスナー、および完全な保護を確保するためのネットワーク・ガイドラインを使用することで改善されます。SSLの使用はこれらのリストにおける必須要素であり、SSLを使用することで認証および通信に関してトップ・レベルのセキュリティが可能になります。

これらのガイドラインは、次のとおりです。

- クライアント接続の保護

- ネットワーク接続の保護

- Secure Sockets Layer接続の保護

クライアント接続の保護

クライアント・コンピュータの認証には問題が多いため、通常は、かわりにユーザー認証が実施されます。このアプローチは、クライアント・システムで、偽造されたIPアドレス、ハッキングされたオペレーティング・システムまたはアプリケーション、および偽造または盗用されたクライアント・システムIDが使用される問題を回避します。また、次のガイドラインによって、クライアント接続のセキュリティが向上します。

1. 効果的なアクセス制御と厳密なクライアント認証を規定する。
デフォルトでは、Oracleで許可されるオペレーティング・システム認証ログインは、保護された接続のみを介したログインであるため、Oracle Netおよび共有サーバー構成を使用したログインは含まれません。このデフォルトの制限によって、リモート・ユーザーが、ネットワーク接続を介して別のオペレーティング・システムのユーザーになりすますことを防止します。

初期化パラメータREMOTE_OS_AUTHENT をTRUEに設定すると、データベースはセキュアでない接続を介して受信したクライアントのオペレーティング・システムのユーザー名を受け入れ、このユーザー名をアカウント・アクセスに使用します。PCなどのクライアントは、オペレーティング・システムの認証を正しく実行していない場合があるため、この機能を使用するとセキュリティが非常に低下します。

デフォルトの設定REMOTE_OS_AUTHENT = FALSEを使用すると、安全性の高い構成となり、Oracleデータベースに接続するクライアントがサーバーベースで適切に認証されます。REMOTE_OS_AUTHENTは、Oracle Databaseリリース11g(11.1)では非推奨となっており、下位互換性のためにのみ保持されている点に注意してください。

したがって、REMOTE_OS_AUTHENT初期化パラメータのデフォルト設定FALSEは変更しないでください。

このパラメータをFALSEに設定しても、ユーザーがリモートから接続できなくなるわけではありません。クライアントがすでに認証されていたとしても、データベースにより標準の認証プロセスが適用されるだけです。

REMOTE_OS_AUTHENTパラメータは、Oracle Database 11g リリース1(11.1)では非推奨となっており、下位互換性のためにのみ保持されている点に注意してください。

2. 暗号化を使用するように接続を構成する。
Oracleネットワークの暗号化を使用すると、傍受が困難となります。暗号化の構成方法の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

3. 強力な認証を設定する。
Kerberosおよび公開鍵インフラストラクチャ(PKI)の使用方法の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

ネットワーク接続の保護

不適切なアクセスまたは変更からネットワークとその通信を保護することは、ネットワーク・セキュリティの最重要点です。データが移動するすべてのパスを検討し、各パスおよびノードに対する脅威を評価してください。次に、脅威およびセキュリティが侵害された場合の結果を抑制または排除する手順を実行します。また、監視および監査を実施し、脅威レベルの増加または侵入試行を検出します。

ネットワーク接続の管理には、Oracle Net Managerを使用できます。Oracle Net Managerの使用方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。『Oracle Database Net Services管理者ガイド』も参照してください。

次の手続きでネットワーク・セキュリティを改善します。

1. リスナーの管理にSecure Sockets Layer(SSL)を使用する。
詳細は、「Secure Sockets Layer接続の保護」を参照してください。

2. リスナーのアクティビティを監視する。
リスナーのアクティビティは、Enterprise Manager Database Controlを使用して監視できます。Database Controlホームページの「一般」の下で、使用しているリスナーのリンクをクリックします。「リスナー」ページが表示されます。このページには、生成された警告のカテゴリ、警告メッセージ、警告がトリガーされた時期などの詳細が表示されます。このページには、リスナーのパフォーマンス統計などの他の情報も表示されます。

3. リスナーのパスワードおよびサーバー上のlistener.oraファイルへの書込み権限は、管理者が保持するように規定することで、オンライン管理を回避する。

1. この行をlistener.oraファイルに追加するか、またはこの行を変更してください。

ADMIN_RESTRICTIONS_LISTENER=ON

2. RELOADを使用して構成を再ロードします。

3. 次のように、アドレス・リストでTCPSプロトコルを最初のエントリにすることで、リスナーの管理にSSLを使用します。

LISTENER=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=tcps)
(HOST = sales.us.example.com)
(PORT = 8281)))

リスナーをリモート管理するために、クライアント・コンピュータのlistener.oraファイルにリスナーを定義します。たとえば、リスナーUSER281にリモートでアクセスするには、次の構成を使用します。

user281 =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = tcps)
(HOST = sales.us.example.com)
(PORT = 8281))
)
)

listener.oraのパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

4. リスナーのパスワードを設定しない。
listener.oraファイルにパスワードが設定されていないことを確認します。ローカルのオペレーティング・システム認証によって、リスナー管理が保護されます。パスワードが設定されていない場合、リモートのリスナー管理は使用禁止になります。このため、リスナーのパスワードの総当り攻撃が防止されます。

リスナーのパスワードは、このリリースでは非推奨となりました。次回のOracle Databaseリリースではサポートされなくなります。

5. ホスト・コンピュータに、複数のNetwork Interface Controller(NIC)カードに関連付けられている複数のIPアドレスがある場合は、特定のIPアドレスに対してリスナーを構成する。
これによって、リスナーはすべてのIPアドレスをリスニングできます。また、リスナーが特定のIPアドレスをリスニングするように制限できます。このタイプのコンピュータでは、リスナーですべてのIPアドレスをリスニングするのではなく、特定のIPアドレスを指定することをお薦めします。リスナーを特定のIPアドレスに限定することで、侵入者が、リスナー・プロセスからTCPエンド・ポイントを盗むのを防止できます。

6. リスナーの権限を制限して、データベースまたはOracleサーバーのアドレス空間にあるファイルを読取り/書込みできないようにする。
この制限によって、リスナー(またはエージェントが実行するプロシージャ)によって起動された外部プロシージャ・エージェントは、読取りまたは書込み操作の実行機能を継承しないようになります。この個別のリスナー・プロセスの所有者には、Oracle Databaseをインストールした所有者またはOracle Databaseインスタンスを実行する所有者(デフォルトの所有者であるORACLEなど)を指定しないでください。

リスナーの外部プロシージャの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

7. 暗号化を使用して、転送中のデータを保護する。
ネットワーク・データの暗号化の詳細は、『Oracle Database 2日でセキュリティ・ガイド』および『Oracle Database Advanced Security管理者ガイド』を参照してください。

8. ファイアウォールを利用する。
ファイアウォールを適切に配置および構成することで、データベースへの外部からのアクセスを防止できます。

- データベース・サーバーはファイアウォールの内側に配置してください。Oracle Databaseのネットワーク・インフラストラクチャであるOracle Net(旧称Net8およびSQL*Net)は、様々なベンダーの各種ファイアウォールに対するサポートを提供しています。プロキシ対応のファイアウォールでは、Network Associates社のGauntletとAxent社のRaptorをサポートしています。パケット・フィルタ型のファイアウォールではCisco社のPIX Firewall、ステートフル・インスペクション型のファイアウォール(より高機能のパケット・フィルタ型ファイアウォール)ではCheckPoint社のFirewall-1をサポートしています。

- ファイアウォールは、保護するネットワークの外側に配置されている必要があります。

- 安全性が確認されているプロトコル、アプリケーションまたはクライアント/サーバーのソースのみを受け入れるようにファイアウォールを構成します。

- Oracle Connection Managerなどの製品を使用して、データベースへの単一のネットワーク接続を介した複数のクライアント・ネットワーク・セッションの多重化を管理します。これにより送信元、送信先およびホスト名でフィルタ処理できます。この製品を使用すると、物理的に保護された端末または既知のIPアドレスを備えたアプリケーションWebサーバーからの接続のみを受け入れるようにできます 。(IPアドレスは偽造可能なため、IPアドレスのみでフィルタ処理した認証では不十分です。)

9. Oracleリスナーの不正な管理を防止する。
リスナーの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

10. ネットワークIPアドレスをチェックする。
Oracle Netの有効なノードの確認セキュリティ機能を利用すると、指定のIPアドレスを持つネットワーク・クライアントからOracleサーバー・プロセスへのアクセスを許可または拒否できます。この機能を使用するには、sqlnet.ora構成ファイルの各パラメータを次のように設定します。

tcp.validnode_checking = YES

tcp.excluded_nodes = {list of IP addresses}

tcp.invited_nodes = {list of IP addresses}

tcp.validnode_checkingパラメータによって、この機能が有効になります。tcp.excluded_nodesおよびtcp.invited_nodesパラメータは、Oracleリスナーに接続しようとする特定のクライアントのIPアドレスを拒否および使用可能にします。これによって、サービス拒否攻撃を防止できます。

これらのパラメータの構成には、Oracle Net Managerを使用できます。詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

11. ネットワーク・トラフィックを暗号化します。
可能な場合は、Oracle Advanced Securityを使用して、クライアント、データベースおよびアプリケーション・サーバー間のネットワーク通信を暗号化します。ネットワーク暗号化の概要は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。ネットワーク暗号化の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

12. ホスト・オペレーティング・システム(Oracle Databaseがインストールされているシステム)を保護する。
オペレーティング・システムの不要なサービスをすべて使用禁止にして、ホスト・オペレーティング・システムを保護します。UNIXおよびWindowsには様々なオペレーティング・システム・サービスが組み込まれていますが、それらの大部分は、一般的なデプロイメントには不要です。これらのサービスには、FTP、TFTP、TELNETなどがあります。使用を禁止している各サービスのUDPポートとTCPポートは、両方とも必ず閉じてください。一方のポートを使用禁止にしていても、他方のポートが使用可能であると、オペレーティング・システムの安全性が低下します。

Secure Sockets Layer接続の保護

Secure Sockets Layer (SSL)は保護された通信のためのインターネット標準プロトコルで、データの整合性と暗号化のメカニズムを提供します。これらのメカニズムは、証明書(および必要な場合は暗号化)を使用して、安全性の高い認証、認可およびメッセージ機能をサポートし、ユーザーあるいはアプリケーションおよびサーバーが送受信するメッセージを保護できます。適切なセキュリティの実施により、保護が最大限に発揮され、セキュリティを脅かすギャップや露見が最小限に抑えられます。次の各ガイドラインでは、SSLを正しく使用する方法についての注意を詳細に説明します。Oracle SSL構成の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

1. 構成ファイル(クライアントおよびリスナー用など)では、インストール時に構成された正しいポートをSSLに対して使用する。
HTTPSは任意のポートで実行できますが、標準的には、すべてのHTTPS準拠のブラウザがデフォルトで確認できるポート443を指定します。たとえば、次のようにポートをURLに指定することもできます。

https://secure.example.com:4445/

ファイアウォールを使用している場合は、保護された(SSL)通信のために同じポートを使用する必要もあります。

2. tnsnames.oraファイル(通常はクライアント上またはLDAPディレクトリ内)のADDRESSパラメータに、PROTOCOLとしてTCPSが指定されていることを確認する。
同一の仕様が、(通常は$ORACLE_HOME/network/adminディレクトリ内の)listener.oraファイルに指定されている必要もあります。

3. 各通信の両サイドでSSLモードが一致していることを確認する。たとえば、データベース(一方)とユーザーまたはアプリケーション(もう一方)が同じSSLモードである必要があります。
クライアントまたはサーバー認証(一方向)、クライアントおよびサーバー認証(双方向)、または認証なしのモードを指定できます。

4. サーバーがクライアントの暗号スイートをサポートしていること、および証明書の鍵のアルゴリズムが使用されていることを確認する。

5. サーバーとクライアントの両方でDN一致を使用可能にし、接続時にサーバーがクライアントに対してその識別情報を偽造するのを防ぐ。
この設定では、サーバーの識別情報のグローバル・データベース名をサーバー証明書のDNと照合することで、その情報が正しいことが確認されます。

DN一致は、tnsnames.oraファイルで使用可能にできます。次に例を示します。

set:SSL_SERVER_CERT_DN="cn=finance,cn=OracleContext,c=us,o=example"

この設定を使用可能にしない場合、クライアント・アプリケーションはサーバー証明書をチェックできず、サーバーによる識別情報の偽造が可能となります。

6. server.keyファイル内部のRSA秘密鍵から暗号化を削除しない。このファイルを読み取り、解析するためにパスフレーズを入力する必要があります。

注意:
SSL非対応のサーバーではパスフレーズは不要です。

サーバーが十分に保護されていると判断した場合は、元のファイルを保持しながらRSA秘密鍵から暗号化を削除できます。これによって、パスフレーズが不要になるため、システム・ブート・スクリプトでデータベース・サーバーを起動できるようになります。理想的には、権限をルート・ユーザーのみに制限し、Webサーバーをrootとして起動し、別のユーザーとしてログインします。そうしないと、この鍵を取得しただれもがネット上でルート・ユーザーになりすましたり、サーバーに送信されたデータを復号化する可能性があります。

関連項目:

- 構成も含めた一般的なSSL情報については、『Oracle Database Advanced Security管理者ガイド』を参照してください。

- sqlnet.oraのTCP関連パラメータについては、『Oracle Database Net Servicesリファレンス』を参照してください。

監査に関するガイドライン

この項の内容は、次のとおりです。

- 機密情報の監査

- 監査済情報の管理しやすい状態での維持

- 通常のデータベース・アクティビティの監査

- 疑わしいデータベース・アクティビティの監査

- 監査の推奨設定

機密情報の監査

SQLテキストを収集すると、クレジット・カード番号などの機密データがファイングレイン監査証跡に表示されることに注意してください。標準監査の場合は、AUDIT_TRAIL初期化パラメータをDB, EXTENDEDまたはXML, EXTENDEDに設定すると、SQLテキストの収集が有効になります。ファイングレイン監査の場合は、DBMS_FGA PL/SQLパッケージのaudit_trailパラメータをDBMS_FGA.DB + DBMS_FGA.EXTENDEDまたはDBMS_FGA.XML + DBMS_FGA.EXTENDEDに設定します。

監査の対象に機密データが含まれている場合は、次のソリューションのいずれかを使用することを検討してください。

- 監査証跡をSYSTEM表領域からSYSAUXまたは別の表領域に移動します。「データベース監査証跡の別の表領域への移動」を参照してください。その後、この表領域を暗号化します。表領域の暗号化の詳細は『Oracle Database Advanced Security管理者ガイド』を参照してください。

- 監査証跡でのSQLテキストの収集は有効にしないようにします。かわりに、次の設定を使用します。

- 標準監査の場合: AUDIT_TRAIL初期化パラメータをDB、OSまたはXMLに設定します。「AUDIT_TRAIL初期化パラメータを使用した標準監査の構成」を参照してください。

- ファイングレイン監査の場合: DBMS_FGA.ADD_POLICY audit_trailパラメータをDBMS_FGA.DBまたはDBMS_FGA.XMLを設定します。「ファイングレイン監査ポリシーの作成」を参照してください。

監査済情報の管理しやすい状態での維持

監査は比較的低コストですが、監査するイベントの数はできるだけ制限してください。この制限によって、監査対象の文を実行したときのパフォーマンスへの影響が最小限に抑えられ、監査証跡のサイズが最小限になるため、分析と理解が容易になります。

監査方針を企画する際は、次のガイドラインに従ってください。

1. 監査の目的を評価する。
監査の目的を明確にしておくと、適切な監査方針を企画でき、不要な監査を回避できます。

たとえば、不審なデータベース・アクティビティの調査のために監査すると仮定します。この情報のみでは不明確です。どのデータベース・アクティビティが疑わしい、または注意を要するといった具体的な情報が必要です。そのために、たとえば、データベース内の表から無許可にデータが削除されていないかを監査するというように、監査方針を絞り込みます。このような目的を設定すれば、監査の対象となるアクションの種類や、疑わしいアクティビティによって影響を受けるオブジェクトの種類を限定できます。

2. 監査について十分理解する。
目標とする情報の取得に必要な最小限の文、ユーザーまたはオブジェクトを監査します。これによって、不要な監査情報のために重要な情報の識別が困難になることや、SYSTEM表領域内の貴重な領域が無駄に使用されることがなくなります。収集が必要なセキュリティ情報の量と、その情報を格納して処理する能力とのバランスを保つ必要があります。

たとえば、データベース・アクティビティに関する情報を収集するために監査する場合は、追跡するアクティビティの種類を正確に判断した上で、必要な情報を収集するために必要な期間内で、目的のアクティビティのみを監査します。別の例として、各セッションの論理I/O情報のみを収集する場合は、オブジェクトを監査しないでください。

3. 監査方針を実施する前に法務部門と打ち合せる。
組織の法務部門に監査方針を検討するように依頼する必要があります。監査では組織の他のユーザーが監視されるため、サイトのコンプライアンス・ポリシーと会社の方針に適切に従っていることを確認する必要があります。

通常のデータベース・アクティビティの監査

監査目的が特定のデータベース・アクティビティに関する履歴情報を収集することにある場合は、次のガイドラインに従ってください。

1. 関連のあるアクションのみを監査する。
少なくとも、ユーザー・アクセス、システム権限の使用およびデータベース・スキーマ構造の変更を監査します。役に立たない監査レコードのために重要な情報が識別できない事態を避け、監査証跡管理の量を削減するために、目的のデータベース・アクティビティのみを監査してください。監査対象が多すぎるとデータベースのパフォーマンスに影響する可能性があることにも注意してください。

たとえば、データベースのすべての表に対する変更を監査すると、監査証跡レコードが多くなりすぎてデータベースのパフォーマンスが低下する可能性があります。ただし、Human Resources(人事管理)表内の給与のように、重要な表に対する変更を監査することは有益です。

ファイングレイン監査を使用することで、特定のアクションを監査できます。ファイングレイン監査については、「ファイングレイン監査を使用した特定のアクティビティの監査」を参照してください。

2. 監査レコードをアーカイブし、監査証跡を削除する。
必要な情報を収集した後は、目的の監査レコードをアーカイブし、この情報の監査証跡を削除します。次の各項を参照してください。

- 「データベース監査証跡のアーカイブ」

- 「オペレーティング・システム監査証跡のアーカイブ」

- 「監査証跡レコードの削除」

- 「データベース監査証跡のサイズの制御」

- 「オペレーティング・システム監査証跡のサイズの設定」

3. 自社のプライバシに関する考慮事項を検討する。
プライバシに関する法規によって、追加のビジネス・プライバシ・ポリシーが必要となる場合があります。プライバシに関するほとんどの法規では、個人を特定できる情報(PII)へのアクセスをビジネスで監視する必要があり、このような監視は監査によって実施されます。ビジネス・レベルのプライバシ・ポリシーでは、技術的、法的および企業ポリシーの問題など、データ・アクセスおよびユーザー・アカウンタビリティに関するすべての事項を処理する必要があります。

4. その他の監査情報をOracle Databaseのログ・ファイルでチェックする。
Oracle Databaseによって生成されたログ・ファイルには、データベースの監査時に使用できる有益な情報が含まれています。たとえば、Oracle Databaseではアラート・ファイルが作成され、STARTUP操作、SHUTDOWN操作およびデータベースにデータ・ファイルを追加するなどの構造上の変更が記録されます。

たとえば、コミットまたはロールバックされたトランザクションを監査する場合は、REDOログ・ファイルを使用できます。

疑わしいデータベース・アクティビティの監査

監査の目的が疑わしいデータベース・アクティビティを監視することにある場合は、次のガイドラインに従ってください。

1. 最初に一般的な監査を行い、特定の対象を監査する。
疑わしいデータベース・アクティビティの監査を開始するとき、通常は対象のユーザーまたはスキーマ・オブジェクトの特定に使用できる情報がありません。そのため、監査オプションを最初はより一般的に、つまり第9章「監査を使用したセキュリティ・アクセスの検証」で説明している標準監査オプションを使用して設定してください。この章では、標準監査オプションを使用してSQL文、スキーマ・オブジェクト、権限などを監査する方法を説明しています。

準備的な監査情報の記録と分析を終了した後は、一般的な監査を使用禁止にして特定のアクションを監査します。「ファイングレイン監査を使用した特定のアクティビティの監査」で説明するように、ファイングレイン監査を使用して特定のアクションを監査できます。この処理は、疑わしいデータベース・アクティビティの原因について結論が出せるだけの十分な裏付けが収集できるまで継続してください。

2. 一般的な疑わしいアクティビティを監査する。
一般的な疑わしいアクティビティは、次のとおりです。

- 通常以外の時間中にデータベースにアクセスするユーザー

- 複数回失敗したユーザー・ログイン試行

- 存在しないユーザーによるログイン試行

さらに、アカウントを共有しているユーザー、または同じIPアドレスからログインしている複数のユーザーを監視します。この種のアクティビティは、DBA_AUDIT_SESSIONデータ・ディクショナリ・ビューを問い合せることで検索できます。非常にきめ細かい方法では、ファイングレイン監査ポリシーを作成します。

3. 監査証跡を保護する。
疑わしいデータベース・アクティビティを監査する場合は、監査と無関係に監査情報が追加、変更または削除されないように、監査証跡を保護します。標準の監査証跡を監査するには、AUDIT SQL文を使用します。

例:

AUDIT SELECT ON SYS.AUD$ BY ACCESS;

「データベース監査証跡の監査」も参照してください。

ファイングレイン監査証跡を監査するには、ユーザーSYSで、次の文を入力します。

AUDIT SELECT ON SYS.FGA$ BY ACCESS;

Oracle Database Vaultを有効にしていると、SYS.AUDIT$表、SYSTEM.AUD$表、SYS.FGA$表、およびSYS.FGA_LOG$表を、レルムに囲むことによりさらに保護できます。(Oracle Database Vault環境では、Oracle Label Securityが使用可能になっている場合、AUD$表はSYSTEMスキーマに移動されます。SYS.AUD$がSYSTEM.AUD$表のシノニムになります。)詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

監査の推奨設定

データベース・スキーマまたは構造の変更。次のAUDIT文の設定を使用します。

- AUDIT ALTER ANY PROCEDURE BY ACCESS;

- AUDIT ALTER ANY TABLE BY ACCESS;

- AUDIT ALTER DATABASE BY ACCESS;

- AUDIT ALTER SYSTEM BY ACCESS;

- AUDIT CREATE ANY EDITION;

- AUDIT CREATE ANY JOB BY ACCESS;

- AUDIT CREATE ANY LIBRARY BY ACCESS;

- AUDIT CREATE ANY PROCEDURE BY ACCESS;

- AUDIT CREATE ANY TABLE BY ACCESS;

- AUDIT CREATE EXTERNAL JOB BY ACCESS;

- AUDIT DROP ANY EDITION;

- AUDIT DROP ANY PROCEDURE BY ACCESS;

- AUDIT DROP ANY TABLE BY ACCESS;

データベースへのアクセスと権限。次のAUDIT文の設定を使用します。

- AUDIT ALTER PROFILE BY ACCESS;

- AUDIT ALTER USER BY ACCESS;

- AUDIT AUDIT SYSTEM BY ACCESS;

- AUDIT CREATE PUBLIC DATABASE LINK BY ACCESS;

- AUDIT CREATE SESSION BY ACCESS;

- AUDIT CREATE USER BY ACCESS;

- AUDIT DROP PROFILE BY ACCESS;

- AUDIT DROP USER BY ACCESS;

- AUDIT EXEMPT ACCESS POLICY BY ACCESS;

- AUDIT GRANT ANY OBJECT PRIVILEGE BY ACCESS;

- AUDIT GRANT ANY PRIVILEGE BY ACCESS;

- AUDIT GRANT ANY ROLE BY ACCESS;

- AUDIT ROLE BY ACCESS;

CONNECTロール変更への対処

CONNECTロールはOracle Databaseリリース7で導入され、これにより、データベース・ロールに新しい堅牢なサポートが追加されました。CONNECTロールは、サンプル・コード、アプリケーション、ドキュメントおよび技術論文に使用されています。Oracle Database 10gリリース2 (10.2)では、CONNECTロールは変更されました。Oracle Database 10.2より前のリリースから現行のリリースにアップグレードする場合は、この項を参照してください。

この項の内容は、次のとおりです。

- CONNECTロールが変更された理由

- CONNECTロール変更がアプリケーションに与える影響

- CONNECTロール変更がユーザーに与える影響

- CONNECTロール変更に対処する方法

CONNECTロールが変更された理由

CONNECTロールは、当初、次の権限を伴って設定されていました。

権限A-C

権限C

ALTER SESSION

CREATE SESSION

CREATE CLUSTER

CREATE SYNONYM

CREATE DATABASE LINK

CREATE TABLE

CREATE SEQUENCE

CREATE VIEW

Oracle Database 10g リリース2以降のCONNECTロールには、CREATE SESSION権限のみが含まれ、他の権限はすべて削除されています。

CONNECTロールは、Oracle Databaseでの新規アカウントのプロビジョニングで頻繁に使用されましたが、データベースへの接続に前述の権限がすべて必要なわけではありません。この変更によって、優れたセキュリティ手続きを簡単に規定できるようになります。

各ユーザーにはそれぞれのタスクに必要な権限のみを付与します。これが「最低限の権限」原則と呼ばれる考え方です。最低限の権限により権限を制限することでリスクが軽減されるため、必要なことはこれまでどおり簡単に実行できると同時に、不適切な行為を不注意に、あるいは意図的に実行される可能性が低くなります。

CONNECTロール変更がアプリケーションに与える影響

CONNECTロールへの変更は、データベース・アップグレード、アカウント・プロビジョニングおよび新しいデータベースを使用したアプリケーションのインストールに影響を与えています。

CONNECTロール変更がデータベース・アップグレードに与える影響

既存のOracleデータベースをOracle Database 10gリリース2 (10.2)にアップグレードすると、CONNECTロールの権限はCREATE SESSION権限のみになるよう自動的に変更されます。ほとんどのアプリケーションは、アプリケーション・オブジェクトがすでに存在するため、この影響を受けません。新たに表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成する必要はありません。

表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSIONコマンドを動的に使用するアプリケーションは、権限が不十分なために失敗する場合があります。

CONNECTロール変更がアカウント・プロビジョニングに与える影響

アプリケーションまたはDBAがアカウント・プロビジョニング・プロセスの一部としてCONNECTロールを付与する場合は、CREATE SESSION権限のみが含まれます。追加の権限は、直接または別のロールを介して付与する必要があります。

この問題は、カスタマイズされた新しいデータベース・ロールを作成することで対処できます。

関連項目:
CONNECTロール変更に対処する方法

CONNECTロール変更が新規のデータベースを使用するアプリケーションに与える影響

Oracle Database 10g リリース2(10.2)のユーティリティ(DBCA)、またはDBCAから生成されたデータベース作成テンプレートを使用して作成された新しいデータベースでは、CREATE SESSION権限のみを伴ったCONNECTロールが定義されます。新しいデータベースを使用するアプリケーションのインストールは、そのアプリケーションに使用されているデータベース・スキーマの権限がCONNECTロールのみを介して付与されている場合、失敗する可能性があります。

CONNECTロール変更がユーザーに与える影響

CONNECTロールへの変更による影響は、一般ユーザー、アプリケーション開発者およびクライアント/サーバー・アプリケーションの3つのクラスのユーザーではそれぞれ異なります。

CONNECTロール変更が一般ユーザーに与える影響

新しいCONNECTロールは、CREATE SESSION権限のみを提供します。アプリケーションを使用するためにデータベースに接続するユーザーの場合、CONNECTロールにはまだCREATE SESSION権限があるため影響はありません。

ただし、CONNECTロールのみでプロビジョニングされた特定のユーザーの場合は、適切な権限がないことになります。表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSIONコマンドを使用するユーザーです。これらのユーザーに必要な権限は、CONNECT ロールでは提供されなくなりました。必要な追加権限を認可するには、データベース管理者が該当する権限用の追加ロールを作成および適用するか、その権限を必要としているユーザーに直接付与する必要があります。

ALTER SESSION権限は、イベントを設定するために必要です。ALTER SESSION権限が必要なデータベース・ユーザーはほとんどいません。

ALTER SESSION SET EVENTS ........

ALTER SESSION権限は、他のALTER SESSIONコマンドには必要ありません。

ALTER SESSION SET NLS_TERRITORY = FRANCE;

CONNECTロール変更がアプリケーション開発者に与える影響

CONNECTロールのみでプロビジョニングされたアプリケーション開発者には、表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSION文を使用するための適切な権限はありません。データベース管理者が、該当する権限用の追加ロールを作成および適用するか、その権限を必要としているアプリケーション開発者に直接付与する必要があります。

CONNECTロール変更がクライアント・サーバー・アプリケーションに与える影響

専用のユーザー・アカウントを使用するほとんどのクライアント/サーバー・アプリケーションは、この変更の影響は受けません。ただし、アカウント・プロビジョニングまたはランタイム操作時に、動的SQLを使用してユーザー・スキーマ内にプライベート・シノニムまたは一時表を作成するアプリケーションは影響を受けます。この場合は、その動作に適したシステム権限を取得するための追加ロールや権限付与が必要です。

CONNECTロール変更に対処する方法

この変更の影響に対処するために次の3つの方法をお薦めします。

方法1: 新しいデータベース・ロールの作成

CONNECTロールから削除された権限は、新しいデータベース・ロールを作成することで管理できます。

まず、アップグレードされたOracleデータベースに接続して新しいデータベース・ロールを作成します。次の例では、my_app_developerというロールを使用しています。

CREATE ROLE my_app_developer;
GRANT CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE SYNONYM, CREATE CLUSTER, CREATE DATABASE LINK, ALTER SESSION TO my_app_developer;

次に、CONNECTロールを持っているユーザーまたはデータベース・ロールを判別し、そのユーザーまたはロールに新しいロールを付与します。

SELECT USER$.NAME, ADMIN_OPTION, DEFAULT_ROLE
FROM USER$, SYSAUTH$, DBA_ROLE_PRIVS
WHERE PRIVILEGE# =
(SELECT USER# FROM USER$ WHERE NAME = 'CONNECT')
AND USER$.USER# = GRANTEE#
AND GRANTEE = USER$.NAME
AND GRANTED_ROLE = 'CONNECT';

NAME                           ADMIN_OPTI DEF
------------------------------ ---------- ---
R1                             YES        YES
R2                             NO         YES

GRANT my_app_developer TO R1 WITH ADMIN OPTION;
GRANT my_app_developer TO R2;

ユーザーが必要としている権限は、Oracle Auditingを使用することで判別できます。この監査情報を分析して、よりきめ細かい追加のデータベース・ロール作成に使用できます。

特定のユーザーについて使用されていない権限は取り消すことができます。監査の前に、データベース初期化パラメータAUDIT_TRAILを初期化してデータベースを再起動する必要があることに注意してください。

AUDIT CREATE TABLE, CREATE SEQUENCE, CREATE SYNONYM, CREATE DATABASE LINK, CREATE CLUSTER, CREATE VIEW, ALTER SESSION;

これでデータベース権限の使用状況を定期的に監視できます。

SELECT USERID, NAME FROM AUD$, SYSTEM_PRIVILEGE_MAP
WHERE - PRIV$USED = PRIVILEGE;

USERID                         NAME
------------------------------ ----------------
ACME                           CREATE TABLE
ACME                           CREATE SEQUENCE
ACME                           CREATE TABLE
ACME                           ALTER SESSION
APPS                           CREATE TABLE
APPS                           CREATE TABLE
APPS                           CREATE TABLE
APPS                           CREATE TABLE

8 rows selected.

方法2: CONNECT権限のリストア

Oracle Database 10g リリース2(10.2)以降、オラクル社では$ORACLE_HOME/rdbms/adminディレクトリにrstrconn.sqlというスクリプトを提供してきました。データベースのアップグレードまたは新しいデータベースの作成後は、このスクリプトを使用して、Oracle Database 10g リリース2(10.2)でCONNECTロールから削除された権限を付与できます。

この方法を使用した場合、使用されていない権限は必要としていないユーザーから取り消してください。そのような権限およびユーザーを識別するには、データベース初期化パラメータAUDIT_TRAILを、たとえばAUDIT_TRAIL=DBと初期化してデータベースを再起動する必要があります。その後、使用されている権限を監視するには、次のようにOracle Databaseの監査をオンにしてください。

AUDIT CREATE TABLE, CREATE SEQUENCE, CREATE SYNONYM, CREATE DATABASE LINK, CREATE CLUSTER, CREATE VIEW, ALTER SESSION;

データベース権限の使用状況も定期的に監視できます。

SELECT USERID, NAME FROM AUD$, SYSTEM_PRIVILEGE_MAP WHERE - PRIV$USED = PRIVILEGE;

USERID                         NAME
------------------------------ ----------------
ACME                           CREATE TABLE
ACME                           CREATE SEQUENCE
ACME                           CREATE TABLE
ACME                           ALTER SESSION
APPS                           CREATE TABLE
APPS                           CREATE TABLE
APPS                           CREATE TABLE
APPS                           CREATE TABLE
8 rows selected.

CONNECT権限受領者を表示する新しいビュー

新しいビューを使用すると、古いCONNECTロールを継続して使用する管理者は、どのユーザーがそのロールを持っているかをすばやく確認できます。

表10-1に、新しいDBA_CONNECT_ROLE_GRANTEESビューの各列を示します。

表10-1 DBA_CONNECT_ROLE_GRANTEESの列と内容

列名

内容

Grantee

CONNECTロールを付与されたユーザー。

Path_of_connect_role_grant

ユーザーへのCONNECTの付与に使用されたロール(またはネストされたロール)。

Admin_opt

VARCHAR2(3)。ユーザーのCONNECTにADMINオプションがある場合はYES、ない場合はNO。

方法3: 「最低限の権限」分析の実施

Oracleパートナおよびアプリケーション・プロバイダは、この方法を使用して、より安全性の高い製品をOracleの顧客ベースに供給する必要があります。「最低限の権限」原則は、所定の機能を実行するために必要な最低限のセットに権限を制限することでリスクを軽減します。

分析によって同一の権限セットが必要とされたユーザーのクラスごとに、その権限のみを持ったロールを作成します。他の権限はすべて該当するユーザーから取り消し、作成したロールを割り当てます。必要な権限が変化したときは、追加の権限を直接またはこれらの新しいロールを介して付与するか、新たに必要となった権限に応じた新しいロールを作成できます。この方法を使用すると、不適切な権限が制限され、不注意または意図的な被害が軽減されます。

用語集

アプリケーション・コンテキスト

名前と値のペア。このペアによって、アプリケーションは、ユーザーに関するセッション情報(ユーザーIDや他のユーザー固有の情報など)にアクセスして、その情報をデータベースに安全に引き渡すことができます。

「グローバル・アプリケーション・コンテキスト」も参照してください。

アプリケーション・ロール

アプリケーション・ユーザーに付与されるデータベース・ロール。アプリケーション内に埋め込まれているパスワードによって保護されています。

「セキュア・アプリケーション・ロール」も参照してください。

証明書

公開鍵に対して識別情報を安全にバインドするITUのx.509 v3標準データ構造。

証明書は、エンティティの公開鍵が、信頼されている機関(認証局)によって署名されたときに作成されます。この証明書は、そのエンティティの情報が正しいこと、および公開鍵がそのエンティティに属していることを保証します。

証明書にはエンティティの名前、認証情報および公開鍵が含まれます。また、証明書に関する権利、ユーザーおよび権限についてのシリアル番号、有効期限、その他の情報が含まれる場合もあります。さらに、発行元の認証局についての情報も含まれます。

証明書失効リスト(CRL)

「CRL」を参照してください。

クラスレス・ドメイン間ルーティング

「CIDR」を参照してください。

クリアテキスト

暗号化されていないプレーン・テキスト。

CIDR

IPアドレスに使用する標準の表記法。CIDR表記法では、IPv6サブネットは、サブネット接頭辞およびビットで示した接頭辞のサイズ(小数)がスラッシュ文字(/)で区切られて示されます。たとえば、fe80:0000:0217:f2ff::/64は、アドレスfe80:0000:0217:f2ff:0000:0000:0000:0000からfe80:0000:0217:f2ff:ffff:ffff:ffff:ffffまでのサブネットを示します。CIDR表記法には、IPv4アドレスのサポートが含まれます。たとえば、192.0.2.1/24は、アドレス192.0.2.1から192.0.2.255までのサブネットを示します。

CRL

失効した証明書のリストを含む一連の署名付きデータ構造。CRLの信頼性および整合性は、証明書に添付されているデジタル署名により提供されます。CRL署名者は通常、発行された証明書に署名したエンティティと同一です。

定義者権限プロシージャ

現行ユーザーではなく、所有者の権限で実行されるプロシージャ(プログラム・ユニット)。定義者権限サブプログラムは、これらのサブプログラムが格納されるスキーマにバインドされます。

たとえば、ユーザーblakeとユーザーscottのそれぞれがdeptという名前の表を、それぞれのユーザー・スキーマの中に持っています。ユーザーblakeがdept表を更新するためにユーザーscottが所有している定義者権限プロシージャをコールすると、このプロシージャはdept表をscottスキーマで更新します。これは、プロシージャはプロシージャを所有している(定義した)ユーザー(つまりscott)の権限で実行するためです。

「実行者権限プロシージャ」も参照してください。

復号化

暗号化されたメッセージを判読可能な書式に変換すること。

サービス拒否(DoS)攻撃

Webサイトをアクセス不能または使用不能にする攻撃。サービス拒否攻撃は様々な手法で行われますが、よく利用される攻撃手法としては、サイトをクラッシュさせるもの、サイトへの接続を拒否するもの、または低速化によりサイトを使用不能にするものがあります。DoS攻撃には、次の2つの形式があります。

- 基本サービス拒否攻撃(1台のみまたは数台のコンピュータが必要)

- 分散型サービス拒否(DDoS)攻撃(多数のコンピュータの実行が必要)

直接付与されたロール

間接的に付与されたロールとは対照的に、ユーザーに直接付与されたロール。

暗号化

メッセージを宛先の受信者以外の第三者が判読できない書式に変換すること。

強制クリーン・アップ

すべての監査レコードをデータベースから強制的にクリーン・アップ(つまり、削除)するための機能。この処理を行うには、DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILプロシージャのUSE_LAST_ARCH_TIMESTAMP引数をFALSEに設定します。

「削除ジョブ」も参照してください。

転送可能なチケット認可チケット

プロキシに転送できる特殊なKerberosチケット。プロキシ認証用に、プロキシはクライアントにかわって追加Kerberosチケットを取得することが許可されます。

「Kerberosチケット」も参照してください。

グローバル・アプリケーション・コンテキスト

アプリケーション・コンテキスト値を複数のデータベース・セッションにわたってアクセス可能にする名前と値のペア。

「アプリケーション・コンテキスト」も参照してください。

間接的に付与されたロール

ユーザーにすでに付与されている別のロールを通じてこのユーザーに付与されるロールのことです。その後、role2ロールとrole3ロールをrole1ロールに付与します。これで、role2とrole3の2つのロールは、role1に含まれることになります。つまり、psmithには、直接付与されたrole1に加え、role2ロールとrole3ロールが間接的に付与されたことになります。psmithに対して、直接付与されたロールrole1を使用可能にすると、間接的に付与されたロールrole2およびrole3も同様に使用可能になります。

整合性

受信したメッセージの内容が、送信された元のメッセージの内容から変更されていないという保証。

実行者権限プロシージャ

現行ユーザー、つまりプロシージャを起動するユーザーの権限で実行されるプロシージャ(プログラム・ユニット)。これらのプロシージャは、特定のスキーマにバインドされません。このプロシージャは様々なユーザーが実行でき、これによって、複数のユーザーが、集中化したアプリケーション・ロジックを使用してそれぞれのデータを管理できます。実行者権限プロシージャは、プロシージャ・コードの宣言セクションにあるAUTHID句を使用して作成されます。

たとえば、ユーザーblakeとユーザーscottのそれぞれがdeptという名前の表を、それぞれのユーザー・スキーマの中に持っています。ユーザーblakeがdept表を更新するためにユーザーscottが所有している実行者権限プロシージャをコールすると、このプロシージャはdept表をblakeスキーマで更新します。これは、プロシージャはプロシージャを起動したユーザー(つまりblake)の権限で実行するためです。

「定義者権限プロシージャ」も参照してください。

KDC

Kerberosチケットを発行するコンピュータ。

「Kerberosチケット」も参照してください。

Kerberosチケット

特定サービスに関するクライアントの識別情報を検証する一時的な電子資格証明。サービス・チケットとも呼ばれます。

Key Distribution Center (KDC)

「KDC」を参照してください。

最終アーカイブ・タイムスタンプ

監査レコードが最後にアーカイブされた時間を示すタイムスタンプ。データベース監査証跡の場合、このタイムスタンプは、最後にアーカイブされた監査レコードを示します。オペレーティング・システム監査ファイルの場合、このタイムスタンプは、アーカイブされた監査ファイルの最終変更タイムスタンプ・プロパティを示します。このタイムスタンプを設定するには、DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP PL/SQLプロシージャを使用します。

「削除ジョブ」も参照してください。

軽量ユーザー・セッション

ユーザーがログインしているアプリケーションに関連した情報のみが含まれるユーザー・セッションです。軽量ユーザー・セッションには、このセッションのデータベース・リソース(トランザクションやカーソルなど)は入っていません。そのため「軽量」とみなされます。軽量ユーザー・セッションが消費するシステム・リソースは、従来のデータベース・セッションよりはるかに少ない量です。軽量ユーザー・セッションが消費するサーバー・リソースは非常に少ないものになるため、軽量ユーザー・セッションを各エンド・ユーザー専用にして、アプリケーションにより必要とみなされるかぎり持続させることができます。

必須監査

監査が有効かどうかにかかわらず、デフォルトで監査されるアクティビティ。これらのアクティビティには、管理者権限でのインスタンスへの接続、データベースの起動、データベースの停止などがあります。これらのアクティビティは、オペレーティング・システム監査証跡に書き込まれます。

ネームスペース

Oracle Databaseのセキュリティにおけるアプリケーション・コンテキストの名前。CREATE CONTEXT文でこの名前を作成します。

Oracle Virtual Private Database

行および列レベルでデータベース・アクセスを制御するセキュリティ・ポリシーを作成できる一連の機能。基本的には、Oracle Virtual Private Databaseのセキュリティ・ポリシーが適用された表、ビューまたはシノニムに対して発行されるSQL文に、動的なWHERE句が追加されます。

PUBLICロール

すべてのデータベース・アカウントが自動的に保有する特殊なロール。デフォルトでは割り当てられている権限がありませんが、多くのJavaオブジェクトに対する付与があります。PUBLICロールは削除できません。また、ユーザー・アカウントは常にこのロールを前提とするため、このロールの手動の付与や取消しは意味がありません。PUBLICロールはすべてのデータベース・ユーザー・アカウントが前提とするため、DBA_ROLESおよびSESSION_ROLESデータ・ディクショナリ・ビューには表示されません。

削除ジョブ

DBMS_AUDIT_MGMT.CREATE_PURGE_JOBプロシージャにより作成されたデータベース・ジョブで、監査証跡の削除を管理します。データベース管理者が削除ジョブをスケジューリングおよび使用可能/使用禁止にします。削除ジョブはアクティブになると、監査レコードをデータベース監査表から削除したり、Oracle Databaseオペレーティング・システム監査ファイルを削除します。

「強制クリーン・アップ」、「最終アーカイブ・タイムスタンプ」も参照してください。

ロール

関連する権限のグループに名前を付けたもの。ユーザーや他のロールに付与します。

「間接的に付与されたロール」も参照してください。

salt

暗号化技術において、暗号化されたデータのセキュリティを強化する方法。データが暗号化される前に追加されるランダムな文字列で、攻撃者が暗号文のパターンを既知の暗号文サンプルに一致させてデータを盗むことを困難にします。saltは通常、辞書攻撃(悪意のあるハッカー(攻撃者)がパスワードを盗むために使用する方法)を防ぐために、暗号化される前のパスワードにも追加されます。暗号化されたsalt処理済の値により、暗号化されたパスワードのハッシュ値(ベリファイアとも呼ばれます)と、一般のパスワード・ハッシュ値の辞書リストとの照合が困難になります。

セキュア・アプリケーション・ロール

アプリケーション・ユーザーに付与されるデータベース・ロール。ただし、実行者権限ストアド・プロシージャを使用して保護され、ロールのパスワードをデータベース表から取得します。セキュア・アプリケーション・ロールのパスワードは、アプリケーション内に埋め込まれていません。

「アプリケーション・ロール」も参照してください。

業務分離

アクティビティを、それを実行する必要があるユーザーのみに制限すること。たとえば、SYSDBA権限は一般ユーザーには付与しないようにします。この権限は管理ユーザーにのみ付与します。業務分離は、多くのコンプライアンス・ポリシーで必要です。適切なユーザーへの権限付与に関するガイドラインは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください。

サービス・チケット

「Kerberosチケット」を参照してください。

ウォレット

個々のエンティティのセキュリティ資格証明を格納したり、管理するために使用されるデータ構造。

索引
A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X

A

アクセス制御

暗号化、解決しない問題, 8.1.1

規定, 10.9.1

オブジェクト権限, 4.6.1

パスワード暗号化, 3.2.1

アクセス制御リスト(ACL)

例

電子メール・アラートのための外部ネットワーク接続, 9.5.10.1

外部ネットワーク接続, 4.12.6

ウォレット・アクセス, 4.12.6

外部ネットワーク・サービス

概要, 4.12.1

ユーザーまたは権限の追加, 4.12.4.1

利点, 4.12

以前のリリースからのアップグレードの影響, 4.12.3

ACLの作成, 4.12.4

DBMS_NETWORK_ACL_ADMINパッケージ、一般プロセス, 4.12.4

監査違反の電子メール・アラートの例, 9.5.10.1

情報の検索, 4.12.12

ホスト, 割当て, 4.12.4.2

ネットワーク・ホスト、ワイルドカードを使用した指定, 4.12.7

ORA-24247エラー, 4.12.3

優先順位、ホスト, 4.12.8

ポート範囲, 4.12.9

権限割当て, 概要, 4.12.10

権限割当て、データベース管理者によるチェック, 4.12.10.1

権限割当て、ユーザーによるチェック, 4.12.10.2

優先順位の設定、複数のロール, 4.12.11

優先順位の設定、複数のユーザー, 4.12.11

作成用の構文, 4.12.4.1

ホスト

ローカル・ホスト, 4.12.4.2

localhost設定, 4.12.4.2 ウォレット・アクセス

概要, 4.12.2

利点, 4.12.2

クライアント証明書資格証明、使用, 4.12.5

情報の検索, 4.12.12

非共有ウォレット, 4.12.5

パスワード資格証明, 4.12.5

パスワード資格証明, 使用, 4.12.5

共有データベース・セッション, 4.12.5

機密情報を含むウォレット, 4.12.5

機密情報を含まないウォレット, 4.12.5

アカウントのロック

例, 3.2.3.5

明示的, 3.2.3.5

パスワード管理, 3.2.3.5

PASSWORD_LOCK_TIMEプロファイル・パラメータ, 3.2.3.5

非定型ツール

データベース・アクセス、セキュリティの問題, 4.5.7.1

ADM_PARALLEL_EXECUTE_TASKロール

概要, 4.5.2

Admin Option

概要, 4.7.1.1

権限の取消し, 4.8.1

ロールの取消し, 4.8.1

ロール, 4.5.5.2

システム権限, 4.4.4

管理権限

ユーザーへの付与, 4.3

管理用ユーザーのパスワード

デフォルト、変更の重要性, 10.5

管理者権限

アクセス, 10.9.2

オペレーティング・システム認証, 3.3.2

パスワード, 3.3.3, 10.5

SYSDBAおよびSYSOPERのアクセス、集中管理, 3.3.1, 3.3.1

書込み、listener.oraファイル, 10.9.2

adump監査ファイルのディレクトリ, 9.6.2 アラート、ファイングレイン監査ポリシーで使用, 9.5.10.1 すべての権限, 10.3 ALTER ANY LIBRARY文

セキュリティ・ガイドライン, 10.3

ALTER権限文

許可されるSQL文, 5.8.2

ALTER PROCEDURE文

プロシージャのコンパイルに使用, 4.6.6.6

ALTER PROFILE文

パスワード管理, 3.2.3.1

ALTER RESOURCE COST文, 2.4.4.2 ALTER ROLE文

認可方式の変更, 4.5.3

ALTER SESSION文

スキーマ、現在の設定, 5.7.1

ALTER USER権限, 2.3.1 ALTER USER文

非推奨となったAUTHENTICATION USER PASSWORD句, はじめに

デフォルト・ロール, 4.11.2

明示的なアカウントのロック解除, 3.2.3.5

GRANT CONNECT THROUGH句, 3.10.1.4

パスワード、変更, 2.3.3

パスワード, 期限切れ, 3.2.3.8

プロファイル, 変更, 3.2.3.8

REVOKE CONNECT THROUGH句, 3.10.1.4

ユーザー・プロファイル, 3.2.3.1

ユーザーの変更, 2.3.2 ANSI操作

Oracle Virtual Private Databaseの影響, 7.5.3

ANYシステム権限

セキュリティに関するガイドライン, 10.6

アプリケーション・コンテキスト

概要, 6.1.1

保護データ・キャッシュ, 6.1.4

使用する利点, 6.1.4

バインド変数, 7.1.4

コンポーネント, 6.1.2

DBMS_SESSION.SET_CONTEXTプロシージャ, 6.3.3.6, 6.3.3.6

駆動コンテキスト, 6.6

エディション、影響, 6.1.5

トレース・ファイルの確認によるエラーの検索, 6.6

情報の検索, 6.6

グローバル・アプリケーション・コンテキスト

複数のアプリケーションに対するユーザーの認証, 6.4.4.5

作成, 6.4.3

ログイン・トリガー、作成, 6.3.4 Oracle Virtual Private Database、使用, 7.1.4 パフォーマンス, 7.4.2.8 ポリシー・グループ、使用, 7.3.5.1 述語を戻す, 7.1.4 セッション情報、取得, 6.3.3.2 データベース・リンクのサポート, 6.3.6 種類, 6.2 ユーザー, 非データベース接続, 6.4.1, 6.4.4.6 値の格納場所, 6.1.3 「クライアント・セッション・ベースのアプリケーション・コンテキスト、データベース・セッション・ベースのアプリケーション・コンテキスト、グローバル・アプリケーション・コンテキスト」も参照 アプリケーション開発者

CONNECTロール変更, 10.11.3.2

アプリケーション・セキュリティ

ウォレット・アクセスを現在のアプリケーションに制限, 4.12.5

他のアプリケーションとのウォレットの共有, 4.12.5

属性の指定, 6.3.2

データベース・ユーザーであるアプリケーション・ユーザー

Oracle Virtual Private Database、仕組み, 7.5.9

アプリケーション

セキュリティ・ポリシーの概要, 5.1

データベース・ユーザー, 5.2.1

セキュリティの強化, 4.5.1.2

オブジェクト権限, 5.8.1

SQL文を許可するオブジェクト権限, 5.8.2

One Big Application Userの認証

セキュリティ上の考慮事項, 5.2.2

セキュリティ上のリスク, 5.2.1

Oracle Virtual Private Database、仕組み, 7.5.4 パスワードの処理、ガイドライン, 5.3.1.2 パスワード保護戦略, 5.3 権限、管理, 5.4 ロール

複数, 4.5.1.3.1

権限、データベース・ロールとの関連付け, 5.6

セキュリティ, 4.5.7, 5.2.2 セキュリティの使用に関する考慮事項, 5.2 セキュリティの制限, 7.5.4 セキュリティ・ポリシー, 7.3.5.3 セキュリティ・ポリシーでの検証, 7.3.5.5 AQ_ADMINISTRATOR_ROLEロール

概要, 4.5.2

AQ_USER_ROLEロール

概要, 4.5.2

アーカイブ

オペレーティング・システム監査ファイル, 9.8.3.4

標準監査証跡, 9.8.2.5

監査証跡のタイムスタンプ設定, 9.9.3.4

攻撃

「セキュリティ攻撃」を参照

AUDIT EXECUTE PROCEDURE文, 9.3.12.2 監査ファイル

常に書き込まれるアクティビティ, 9.1.5

ディレクトリ, 9.6.2

ファイル名、形式, 9.6.2

オペレーティング・システム監査証跡

アーカイブ、タイムスタンプの設定, 9.9.3.4

データベース監査証跡と共通して監査されるアクション, 9.3.3

オペレーティング・システム・ファイル

使用する利点, 9.3.4.3

テキスト・ファイルの表示形式, 9.3.4.2

XMLファイルの表示形式, 9.3.4.2

アーカイブ, 9.8.3.4

内容, 9.3.4.1

ディレクトリの場所, 9.3.4.5

機能, 9.3.4.4

いっぱいになった場合, 9.8.3.1

標準監査証跡

アーカイブ、タイムスタンプの設定, 9.9.3.4

オペレーティング・システム監査証跡と共通して監査されるアクション, 9.3.3

レコード、アーカイブ, 9.8.2.5

書込み先, 9.6.2 AUDIT文

概要, 9.3.1.1

スキーマ・オブジェクト, 9.3.10.5

監査証跡

概要, 9.8.1

アーカイブ, 9.8.2.5

ビューの削除, 9.10.3

情報の検索, 9.10.1

解釈, 9.10.2

タイプ, 9.8.1

「標準監査証跡、SYS.AUD$表、SYS.FGA_LOG$表」も参照

AUDIT_FILE_DEST初期化パラメータ

概要, 9.3.4.5

OS監査用の設定, 9.3.4.5

AUDIT_SYS_OPERATIONS初期化パラメータ

SYSの監査, 9.6.2

AUDIT_SYSLOG_LEVEL初期化パラメータ

必須監査レコードに与える影響, 9.1.5

AUDIT_TRAIL初期化パラメータ

概要, 9.3.2.1

SYSの監査, 9.6.2

データベース、読取り専用モードで起動, 9.3.2.2

DB(データベース)設定, 9.3.2.2

DB、EXTENDED設定, 9.3.2.2

使用禁止, 9.3.2.2

OS(オペレーティング・システム)設定, 9.3.2.2

設定, 9.3.2.1

値, 9.3.2.2

XML設定, 9.3.2.2

XML、EXTENDED設定, 9.3.2.2

監査

管理者

「標準監査」を参照

監査オプション, 9.2 監査レコード, 9.8.1 機密性の高いデータ、監査証跡内の, 10.10.1 監査証跡, 9.8.1 変更前と変更後の情報、トリガーでの記録, 9.7 コミット済データ, 9.3.6.2, 10.10.3 データベース・ユーザー名, 3.5 デフォルト監査、使用可能, 9.4.1 分散データベース, 9.1.6 情報の検索, 9.10.1 ファイングレイン

「ファイングレイン監査」を参照

ファンクション, 9.3.12.1 関数、Oracle Virtual Private Database, 9.3.12.1 一般手順, 9.2 セキュリティに関するガイドライン, 10.10 履歴情報, 10.10.3 情報の管理しやすい状態での維持, 10.10.2 LOB、監査

ユーザー定義の列, 9.5.3

ログイン・イベントとログオフ・イベント, 9.3.7.3 複数層環境

「標準監査」を参照

ネットワーク

「標準監査」を参照

オブジェクト列, 9.5.3 オブジェクト

「標準監査」を参照

One Big Application Userの認証、制限, 5.2.1 オペレーティング・システム・ファイル

表示形式, 9.3.4.2

構成, 9.3.2.2

管理, 9.8.3

オペレーティング・システム・ユーザー名, 3.5 Oracle Virtual Private Databaseポリシー関数, 9.3.12.1 パッケージ, 9.3.12.1 パフォーマンス, 9.1.7 PL/SQLパッケージ, 9.3.12.1 権限

「標準監査」を参照

プロシージャ, 9.3.12.1 対象範囲, 9.2 推奨設定, 10.10.5 米国サーベンス・オクスリー法

監査、順守を満たす, 9.1.1

スキーマ・オブジェクト

「標準監査」を参照

将来作成されるスキーマ・オブジェクト, 9.3.10.5 SQL文

「標準監査」を参照

標準

「標準監査証跡、標準監査」を参照

文

「標準監査」を参照

STMT_AUDIT_OPTION_MAP表, 9.3.3 疑わしいアクティビティ, 10.10.4 SYSユーザー, 9.6.2 SYS.FGA_LOG$表, 9.5.5 SYSTEMユーザー, 9.6.1 SYSTEM_PRIVILEGE_MAP表, 9.3.3 トリガー, 9.3.12.1 トリガーの使用, 9.7 UNIXのsyslog, 9.1.5 ビュー

アクティブなオブジェクト・オプション, 9.10.2.3

アクティブな権限オプション, 9.10.2.2

アクティブな文オプション, 9.10.2.1

デフォルトのオブジェクト・オプション, 9.10.2.4

監査オプションが有効になる時点, 9.3.1.3 XMLファイル

表示形式, 9.3.4.2

構成, 9.3.2.2

「SYS.AUD$表、SYS.FGA_LOG$表、標準監査、標準監査証跡、ファイングレイン監査」も参照 監査、レコードの削除

概要, 9.9.1

アーカイブ・タイムスタンプの取消し, 9.9.6.7

データベース監査証跡のバッチ・サイズの消去, 9.9.6.8

監査証跡の作成

削除ジョブ, 9.9.3

削除ジョブの作成, 9.9.3.5 データベース監査証跡

レコードのサブセットの削除, 9.9.5

削除ジョブの削除, 9.9.6.6 削除ジョブを使用禁止にする, 9.9.6.4 削除ジョブを使用可能にする, 9.9.6.4 例, 9.9.7 一般手順, 9.9.2 初期化

取消し, 9.9.6.3

クリーン・アップ操作の初期化, 9.9.3.3 初期化されたかどうかの確認, 9.9.6.1 監査証跡の手動削除, 9.9.4 バッチによるグループでのレコード削除, 9.9.3.6 手引き, 9.9.2 削除ジョブのスケジュール, 9.9.3.5 アーカイブ・タイムスタンプの設定, 9.9.3.4 すべての削除ジョブの時間間隔, 9.9.6.2 指定した削除ジョブの時間間隔, 9.9.6.5 AUTHENTICATEDUSERロール, 4.5.2 認証

概要, 3.1

管理者

オペレーティング・システム, 3.3.2

パスワード, 3.3.3

SYSDBAおよびSYSOPERのアクセス、集中管理, 3.3.1

データベースによる, 3.4 SSLによる, 3.7.1.1 クライアント, 10.9.1 クライアントから中間層を介したプロセス, 3.10.1.6 データベース管理者, 3.3 データベース、使用

概要, 3.4.1

利点, 3.4.2

プロシージャ, 3.4.3

ディレクトリ・サービス, 3.7.1 ディレクトリベース・サービス, 3.6.2 外部認証

概要, 3.8.1

利点, 3.8.2

オペレーティング・システム認証, 3.8.4

ユーザーの作成, 3.8.3

グローバル認証

概要, 3.7

利点, 3.7.2

プライベート・スキーマを持つユーザーの作成, 3.7.1.1

スキーマを共有するユーザーの作成, 3.7.1.2

中間層の認証

プロキシ、例, 3.10.1.8

複数層, 3.9 ネットワーク認証

Secure Sockets Layer, 3.6.1

サード・パーティ・サービス, 3.6.2

One Big Application User、制限, 5.2.1 オペレーティング・システム認証

概要, 3.5

利点, 3.5

デメリット, 3.5

プロキシ・ユーザー認証

概要, 3.10.1.1

期限切れのパスワード, 3.10.1.4

公開鍵インフラストラクチャ, 3.6.2 RADIUS, 3.6.2 リモート, 10.9.1, 10.9.1 ユーザー作成時の指定, 2.2.3 厳密, 10.5 WindowsシステムのSYSDBA, 3.3.2 Windows固有の認証, 3.3.2 「パスワード、プロキシ認証」も参照 AUTHID DEFINER句

Oracle Virtual Private Database機能での使用, 7.1.3

認可

概要, 4

ロールに対する変更, 4.5.3

グローバル

概要, 3.7

利点, 3.7.2

複数層, 3.9 ロールに対して省略, 4.5.3 オペレーティング・システム, 4.5.4.3.1 ロール, 概要, 4.5.4 自動再解析

Oracle Virtual Private Database、仕組み, 7.5.5

Automatic Storage Management (ASM)

SYSASM権限, はじめに

B

バナー

ユーザー・アクションの監査、構成, 5.9.5

不正なアクセス、構成, 5.9.5

バッチ・ジョブ、ユーザーの認証, 3.2.5.1 BFILE

セキュリティに関するガイドライン, 10.6

バインド変数

アプリケーション・コンテキスト、使用, 7.1.4

監査証跡で取得した情報, 9.3.2.2

BLOB

暗号化, 8.2.6

BY ACCESS句

概要, 9.3.6.5

使用する利点, 9.3.6.5

文監査オプションの検索, 9.10.2.1

NOAUDIT文でサポートされていない, 9.3.6.7

使用, 9.3.6.5

C

CAPI_USER_ROLEロール, 4.5.2

連鎖的な取消し, 4.8.3

CATNOAUD.SQLスクリプト

概要, 9.10.3

監査証跡ビュー、削除, 9.10.3

証明書の鍵のアルゴリズム

Secure Sockets Layer, 10.9.3

デフォルトのchange_on_installパスワード, 10.5 キャラクタ・セット

ロール名、マルチバイト・キャラクタ, 4.5.3

ロール・パスワード、マルチバイト・キャラクタ, 4.5.4.1

暗号スイート

Secure Sockets Layer, 10.9.3

クライアント接続

セキュリティに関するガイドライン, 10.9.1

安全性の高い外部パスワード・ストア, 3.2.5.3

保護, 10.9.1

クライアント識別子

JDBCを使用するアプリケーションに対する設定, 3.10.2.4

クライアント識別子

概要, 3.10.2.1

ユーザーの監査, 9.3.9

DBMS_SESSION.SET_IDENTIFIERとDBMS_APPLICATION_INFO.SET_CLIENT_INFOの整合性, 3.10.2.5

グローバル・アプリケーション・コンテキスト、独立, 3.10.2.4

DBMS_SESSION.SET_IDENTIFIERプロシージャを使用した設定, 6.4.1

「非データベース・ユーザー」も参照

クライアント・セッション・ベースのアプリケーション・コンテキスト

概要, 6.5.1

CLIENTCONTEXTネームスペース、値の消去, 6.5.4

CLIENTCONTEXTネームスペース、値の設定, 6.5.2

CLIENTCONTEXTネームスペースの取得, 6.5.3

「アプリケーション・コンテキスト」も参照

CLIENT_IDENTIFIER USERENV属性

DBMS_SESSIONパッケージを使用した設定および消去, 3.10.2.5

OCIユーザー・セッション・ハンドル属性を使用した設定, 3.10.2.4

「USERENVネームスペース」を参照

CLIENTID_OVERWRITEイベント, 3.10.2.5 列のマスク動作, 7.3.4.3

列の仕様, 7.3.4.3

制限, 7.3.4.3

列

選択した列に対する権限の付与, 4.7.2.3

権限の付与, 4.7.2.3

INSERT権限, 4.7.2.3

付与されているユーザーのリスト, 4.13.3

権限, 4.7.2.3

疑似列

USER, 4.6.5.3

権限の取消し, 4.8.2.2 コマンドラインのリコール攻撃, 5.3.1.1, 5.3.1.4 コミット済データ

監査, 9.3.6.2, 10.10.3

構成

セキュリティに関するガイドライン, 10.8

構成ファイル

listener.ora, 10.9.2

サンプルlistener.oraファイル, 10.9.2

server.key暗号化ファイル, 10.9.3

tsnames.ora, 10.9.3

標準的なディレクトリ, 10.9.3, 10.9.3

CONNECTロール

概要, 10.11

アプリケーション

アカウント・プロビジョニング, 10.11.2.2

影響, 10.11.2

データベース・アップグレード, 10.11.2.1

インストール, 10.11.2.3

作成するためのスクリプト, 4.5.2 ユーザー

アプリケーション開発者、影響, 10.11.3.2

クライアント/サーバー・アプリケーション、影響, 10.11.3.3

一般ユーザー、影響, 10.11.3.1

影響, 10.11.3

変更された理由, 10.11.1 CONNECTロール、使用できる権限, 4.5.1.1 接続プーリング

概要, 3.9

グローバル・アプリケーション・コンテキスト, 6.4.1

非データベース・ユーザー, 6.4.4.6

プロキシ認証, 3.10.1.6

接続

SYS権限, 10.3

CPUタイムの制限, 2.4.2.3 CREATE ANY LIBRARY文

セキュリティ・ガイドライン, 10.3

CREATE ANY PROCEDUREシステム権限, 4.6.6.5 CREATE ANY TABLE文

管理者以外のユーザー, 10.3

CREATE CONTEXT文

概要, 6.3.2

例, 6.3.2

CREATE LIBRARY文

セキュリティ・ガイドライン, 10.3

CREATE PROCEDUREシステム権限, 4.6.6.5 CREATE PROFILE文

アカウントのロック期間, 3.2.3.5

ログインの失敗, 3.2.3.5

パスワード・エイジングおよび期限切れ, 3.2.3.7

パスワード管理, 3.2.3.1

パスワード, 例, 3.2.3.8

CREATE ROLE文

IDENTIFIED EXTERNALLYオプション, 4.5.4.3

CREATE SCHEMA文

保護, 5.7.1

CREATE SESSION文, 4.5.1.1

CONNECTロール権限, 10.4

保護, 5.7.1

CREATE USER文

明示的なアカウントのロック, 3.2.3.5

IDENTIFIED BYオプション, 2.2.3

IDENTIFIED EXTERNALLYオプション, 2.2.3

パスワード, 期限切れ, 3.2.3.8

ユーザー・プロファイル, 3.2.3.1

CSW_USR_ROLEロール, 4.5.2 CTXAPPロール, 4.5.2 カーソル

再解析、アプリケーション・コンテキスト, 6.3.4

共有、仮想プライベート・データベースで使用, 7.1.4

カスタム・インストール, 10.8, 10.8 CWM_USERロール, 4.5.2

D

データ定義言語(DDL)

ロールおよび権限, 4.5.1.6

標準監査, 9.3.7.2

データ・ディクショナリ

保護, 10.6

O7_DICTIONARY_ACCESSIBILITYによる保護, 4.4.2.1

データ・ディクショナリ・ビュー

「ビュー」を参照

データ・ファイル, 10.6

セキュリティに関するガイドライン, 10.6

データ操作言語(DML)

権限の制御, 4.6.4.1

標準監査, 9.3.7.2

データ・セキュリティ

暗号化、解決しない問題, 8.1.3

データベース管理者(DBA)

アクセス、制御, 8.1.2

認証, 3.3

不正、暗号化では解決しない, 8.1.2

データベース監査証跡

オペレーティング・システム監査証跡と共通して監査されるアクション, 9.3.3

削除におけるレコードのバッチサイズ, 9.9.3.6

保護, 9.1.3

SYSTEM以外の表領域への移動, 9.8.2.3

Database Configuration Assistant(DBCA)

デフォルトのパスワード、変更, 10.5

ユーザー・アカウント、自動的にロックして期限切れにする, 10.3

データベース・リンク

アプリケーション・コンテキストのサポート, 6.3.6

アプリケーション・コンテキスト, 6.3.3.5

監査, 9.3.10.2

Kerberosを使用した認証, 3.6.2

サード・パーティ・サービスを使用した認証, 3.6.2

グローバルなユーザー認証, 3.7.2

オブジェクト権限, 4.6.3

オペレーティング・システム・アカウント、注意が必要, 3.5

セッション・ベースのアプリケーション・コンテキスト、アクセス, 6.3.3.5

データベース・セッション・ベースのアプリケーション・コンテキスト

概要, 6.3.1

ユーザー終了後のクリーン・アップ, 6.3.1

コンポーネント, 6.3.1

作成, 6.3.2

データベース・リンク, 6.3.3.5

動的SQL, 6.3.3.3

外部化、使用, 6.3.8

使用方法, 6.3

外部での初期化, 6.3.6

グローバルな初期化, 6.3.7.1

所有権, 6.3.2

パラレル問合せ, 6.3.3.4

PL/SQLパッケージの作成, 6.3.3

セッション情報、設定, 6.3.3.6

SYS_CONTEXT関数, 6.3.3.2

トラステッド・プロシージャ, 6.1.2

例, 6.3.5.1

「アプリケーション・コンテキスト」も参照

データベース・アップグレードとCONNECTロール, 10.11.2.1 データベース

アクセス制御

パスワード暗号化, 3.2.1

その他のセキュリティ・リソース, 1.2 認証, 3.4 データベース・ユーザーとアプリケーション・ユーザー, 5.2.1 デフォルト監査設定

概要, 9.4.1

DBCAが作成したデータベース, 9.4.1

手動で作成したデータベース, 9.4.1

デフォルトのパスワード・セキュリティ設定, 3.2.3.4

DBCAが作成したデータベース, 3.2.3.4

手動で作成したデータベース, 3.2.3.4

デフォルトのセキュリティ機能、要約, 1.1 権限の付与, 4.7 ロールの付与, 4.7 使用の制限, 2.4.1 読取り専用モード、起動, 9.3.2.2 セキュリティとスキーマ, 5.7 セキュリティの埋込み、利点, 5.2.2 基づくセキュリティ・ポリシー, 7.1.2.1 DATAPUMP_EXP_FULL_DATABASEロール, 4.5.2 DATAPUMP_IMP_FULL_DATABASEロール, 4.5.2 AUDIT_TRAIL初期化パラメータでのDB_EXTENDED設定, はじめに DBAロール

概要, 4.5.2

DBA_NETWORK_ACL_PRIVILEGESビュー, 4.12.10 DBA_ROLE_PRIVSビュー

アプリケーション権限、検索, 5.4

DBA_ROLESデータ・ディクショナリ・ビュー

PUBLICロール, 4.4.5

DBFS_ROLEロール, 4.5.2 DBMS_APPLICATION.SET_CLIENT_INFOプロシージャ

DBMS_SESSION.SET_IDENTIFIERの値、上書き, 3.10.2.5

DBMS_CRYPTOパッケージ

概要, 8.3

サポートされる暗号化アルゴリズム, 8.3

例, 8.4.1

DBMS_FGAパッケージ

概要, 9.5.9.1

ADD_POLICYプロシージャ, 9.5.9.2

DISABLE_POLICYプロシージャ, 9.5.9.3

DROP_POLICYプロシージャ, 9.5.9.4

ENABLE_POLICYプロシージャ, 9.5.9.3

DBMS_OBFUSCATION_TOOLKITパッケージ

下位互換性, 8.3

「DBMS_CRYPTOパッケージ」も参照

DBMS_RLSパッケージ

概要, 7.3.1

DBMS_RLS.ADD_CONTEXTプロシージャ, 7.3.1 DBMS_RLS.ADD_GROUPED_POLICYプロシージャ, 7.3.1 DBMS_RLS.ADD_POLICY

sec_relevant_colsパラメータ, 7.3.4.1

sec_relevant_cols_optパラメータ, 7.3.4.3

DBMS_RLS.ADD_POLICYプロシージャ

概要, 7.3.1

DBMS_RLS.CREATE_POLICY_GROUPプロシージャ, 7.3.1 DBMS_RLS.DELETE_POLICY_GROUPSプロシージャ, 7.3.1 DBMS_RLS.DISABLE_GROUPED_POLICYプロシージャ, 7.3.1 DBMS_RLS.DROP_CONTEXTプロシージャ, 7.3.1 DBMS_RLS.DROP_GROUPED_POLICYプロシージャ, 7.3.1 DBMS_RLS.DROP_POLICYプロシージャ, 7.3.1 DBMS_RLS.ENABLE_GROUPED_POLICYプロシージャ, 7.3.1 DBMS_RLS.ENABLE_POLICYプロシージャ, 7.3.1 DBMS_RLS.REFRESH_GROUPED_POLICYプロシージャ, 7.3.1 DBMS_RLS.REFRESH_POLICYプロシージャ, 7.3.1 DBMS_SESSIONパッケージ

クライアント識別子、使用, 3.10.2.5

グローバル・アプリケーション・コンテキスト、使用, 6.4.4

SET_CONTEXTプロシージャ

概要, 6.3.3.6

アプリケーション・コンテキストの名前と値のペア, 6.3.3.1

DBMS_SESSION.SET_CONTEXTプロシージャ

概要, 6.3.3.6

構文, 6.3.3.6

usernameおよびclient_idの設定, 6.4.4.3

DBMS_SESSION.SET_IDENTIFIERプロシージャ

クライアント・セッションID、設定, 6.4.1

DBMS_APPLICATION.SET_CLIENT_INFOの値、上書き, 3.10.2.5

DBSNMPユーザー・アカウント

パスワードの使用方法, 10.5

DDL

「データ定義言語」を参照

デフォルトのパスワード, 10.5, 10.5, 10.5, 10.5

change_on_installまたはmanagerパスワード, 10.5

変更、重要性, 3.2.3.2

検索, 3.2.3.2

デフォルトの権限, 10.6 デフォルト・プロファイル

概要, 3.2.3.3

デフォルト・ロール

ユーザーに対する設定, 2.2.8

指定, 4.11.2

デフォルトのユーザー

アカウント, 10.3, 10.3

Enterprise Managerのアカウント, 10.3

パスワード, 10.5

デフォルト

表領域割当て制限, 2.2.5

ユーザー表領域, 2.2.4

定義者権限

概要, 4.6.6.3

プロシージャ権限、使用, 4.6.6.3

プロシージャのセキュリティ, 4.6.6.3

セキュア・アプリケーション・ロール, 5.5.2

Oracle Virtual Private Database機能での使用, 7.1.3

DELETE権限

許可されるSQL文, 5.8.2

DELETE_CATALOG_ROLEロール

概要, 4.5.2

SYSスキーマ・オブジェクト、アクセスの許可, 4.4.2.2

サービス拒否攻撃

概要, Glossary

サービス拒否(DoS)攻撃

不正なパケット、防止, 5.9.1

ネットワーク、保護, 10.9.2

サービス拒否(DoS)攻撃

監査証跡、オペレーティング・システム・ファイルへの書込み, 9.3.4.3

非推奨となったセキュリティ機能, はじめに ディクショナリ保護メカニズム, 4.4.2.1 ダイレクト・パス・ロード

ファイングレイン監査の影響, 9.5.1

ディレクトリ認証、SYSDBAまたはSYSOPERアクセスの構成, 3.3.1.1 ディレクトリ・オブジェクト監査

構成, 9.3.11.2

削除, 9.3.11.3

ディレクトリ・オブジェクト

監査, 9.3.11.1

EXECUTE権限の付与, 4.7.1

ディレクトリベース・サービスを使用した認証, 3.6.2 不要なサービスを使用禁止にする

FTP、TFTP、TELNET, 10.9.2

ディスパッチャ(Dnnn)プロセス

セッション当たりのSGA領域の制限, 2.4.2.5

分散データベース

監査, 9.1.6

DML

「データ操作言語」を参照

駆動コンテキスト, 6.6 DROP PROFILE文

例, 2.4.4.2

DROP ROLE文

例, 4.5.6

セキュリティ・ドメイン, 関連, 4.5.6

DROP USER文

概要, 2.5

削除したユーザーのスキーマ・オブジェクト, 2.5

DUAL表

概要, 6.3.3.2

Oracle Virtual Private Databaseの動的ポリシー・タイプ, 7.3.6.2 DYNAMICポリシー・タイプ, 7.3.6.2

E

エディション

アプリケーション・コンテキスト、影響, 6.1.5

ファイングレイン監査パッケージ、結果, 6.4.4.2

グローバル・アプリケーション・コンテキスト、影響, 6.4.4.2

Oracle Virtual Private Databaseパッケージ、結果, 6.4.4.2

EJBCLIENTロール, 4.5.2 電子メール・アラートの例, 9.5.10.1 暗号化

アクセス制御, 8.1.1

BLOB, 8.2.6

課題, 8.2

データ・セキュリティ、解決しない問題, 8.1.3

データ転送, 10.9.2

DBMS_CRYPTOパッケージ, 8.3, 8.3

削除された暗号化データ, 10.6

例, 8.4.1

情報の検索, 8.5

暗号化列のファイングレイン監査ポリシー, 9.5.9.2

索引付けされたデータ, 8.2.1

鍵の生成, 8.2.2

鍵の格納, 8.2.4

鍵の転送, 8.2.3

鍵、変更, 8.2.5

不正なデータベース管理者, 8.1.2

ネットワーク通信, 10.9.2

解決しない問題, 8.1

透過的データ暗号化, 8.2.4.4

透過的表領域暗号化, 8.2.4.4

エンタープライズ・ディレクトリ・サービス, 4.5.4.4 Enterprise Edition, 10.5 Enterprise Manager

ロールの付与, 4.5.5.1

統計モニター, 2.4.3

エンタープライズ・ロール, 3.7, 4.5.4.4 エンタープライズ・ユーザー管理, 5.2.1 エンタープライズ・ユーザー・セキュリティ

アプリケーション・コンテキスト、グローバルに初期化, 6.3.7.3

プロキシ認証

Oracle Virtual Private Database、仕組み, 7.5.9

エンタープライズ・ユーザー

集中管理, 3.7

グローバル・ロール, 作成, 4.5.4.4

One Big Application Userの認証、制限, 5.2.1

プロキシ認証, 3.10.1.1

共有スキーマ、ユーザーの保護, 5.7.2

エラー

OPW-00005, 2.3.4

ORA-00036, 9.5.9.2, 9.5.9.2

ORA-01720, 4.6.5.2

ORA-06512, 9.5.10.6

ORA-1000, 9.5.9.2, 9.5.9.2

ORA-24247, 4.12.3, 9.5.10.6

ORA-28009, 4.4.2.1

ORA-28040, 3.4.1

ORA-28046

ORA-28046エラー, 2.3.4

ORA-28132, はじめに ORA-28133, 9.5.9.2 ORA-28144, 9.5.9.2 例

アクセス制御リスト

外部ネットワーク接続, 4.12.6

ウォレット・アクセス, 4.12.6

アカウントのロック, 3.2.3.5 監査証跡の削除, 9.9.7 変更前と変更後の値を記録する監査トリガー, 9.7 データの暗号化

BLOBデータの暗号化および復号化, 8.4.3

AES 256ビットを使用した暗号化および復号化プロシージャ, 8.4.2

ディレクトリ・オブジェクト、EXECUTE権限の付与, 4.7.1 暗号化プロシージャ, 8.4.1 パスワードを読み取るためのJavaコード, 5.3.4 CREATE PROFILEを使用したアカウントのロック, 3.2.3.5 ログイン試行の猶予期間, 3.2.3.8 非データベース・ユーザー認証, 6.4.4.6 O7_DICTIONARY_ACCESSIBILITY初期化パラメータ、設定, 4.4.2.1 パスワード

エイジングおよび期限切れ, 3.2.3.7

変更, 2.3.3

ユーザーへの作成, 2.2.3

権限

ADMIN OPTIONの付与, 4.7.1.1

ビュー, 4.13

プロシージャ権限がパッケージに与える影響, 4.6.6.7, 4.6.6.7 プロファイル、ユーザーに対する割当て, 2.2.7 ロール

外部認可方式の変更, 4.5.3

アプリケーションによる認可の作成, 4.5.4.2

外部による認可の作成, 4.5.4.3

パスワードによる認可の作成, 4.5.3

デフォルト, 設定, 4.11.2

SET ROLEを使用したパスワード認証ロールの設定, 4.5.4.1

ビュー, 4.13

安全性の高い外部パスワード・ストア, 3.2.5.2 ユーザーのセッションID

検索, 2.5

終了, 2.5

システム権限とロール、付与, 4.7.1 表領域

ユーザーに対するデフォルトの割当て, 2.2.4

割当て制限、ユーザーに対する割当て, 2.2.5

一時, 2.2.6

種類の作成, 4.6.7.5 ユーザー

アカウントの作成, 2.2.1

GRANT文を使用した作成, 4.7.1.2

削除, 2.5

クライアントのプロキシとなる中間層サーバー, 3.10.1.4

名前の指定, 2.2.2

オブジェクト権限の付与, 4.7.2

プロキシ・ユーザー、接続, 3.10.1.4

「チュートリアル」も参照 例外

WHEN NO DATA FOUND、アプリケーション・コンテキスト・パッケージで使用, 6.3.5.4

WHEN OTHERS、トリガーで使用

開発環境(デバッグ)の例, 6.3.4

本番環境の例, 6.3.4

排他モード

SHA-1パスワード・ハッシュ・アルゴリズム、使用可能, 3.2.4

EXECUTE ANY LIBRARY文

セキュリティ・ガイドライン, 10.3

EXECUTE権限

許可されるSQL文, 5.8.2

EXECUTE_CATALOG_ROLEロール

概要, 4.5.2

SYSスキーマ・オブジェクト、アクセスの許可, 4.4.2.2

文の実行時間、測定, 7.3.6.2 EXEMPT ACCESS POLICY権限

Oracle Virtual Private Databaseの規定対象、除外, 7.5.7.2

EXP_FULL_DATABASEロール

概要, 4.5.2

パスワードを期限切れにする

明示的, 3.2.3.8

データのエクスポート

Oracle Virtual Private Databaseへのダイレクト・パス・エクスポートの影響, 7.5.7.2

ポリシーの規定, 7.5.7.2

外部認証

概要, 3.8.1

利点, 3.8.2

ネットワーク, 3.8.5

オペレーティング・システム, 3.8.4, 3.8.4

ユーザーの作成, 3.8.3

外部ネットワーク・サービス、ファイングレイン・アクセス

アクセス制御リスト(ACL)を参照

外部表, 10.6

F

ログインの失敗

アカウントのロック, 3.2.3.5

パスワード管理, 3.2.3.5

リセット, 3.2.3.5

機能、新しいセキュリティ

「新機能、セキュリティ」を参照

ファイル

BFILE

オペレーティング・システムのアクセス、制限, 10.6

BLOB, 8.2.6 データ

オペレーティング・システムのアクセス、制限, 10.6

外部表

オペレーティング・システムのアクセス、制限, 10.6

鍵, 8.2.4.2 listener.oraファイル

セキュリティに関するガイドライン, 10.9.2, 10.9.3

ログ

Windowsでの監査ファイルの場所, 9.6.2

監査ファイルの位置, 9.3.4.5

オペレーティング・システムのアクセス、制限, 10.6

リスナーのアクセス権の制限, 10.9.2 server.key暗号化ファイル, 10.9.3 シンボリック・リンク、制限, 10.6 tnsnames.ora, 10.9.3 トレース

オペレーティング・システムのアクセス、制限, 10.6

ファイングレイン・アクセス・コントロール

「Oracle Virtual Private Database (VPD)」を参照

ファイングレイン監査

概要, 9.5.1

常に記録されるアクティビティ, 9.5.5

利点, 9.5.3, 9.5.3

アラート、ポリシーへの追加, 9.5.10.1

監査証跡のアーカイブ, 9.8.2.5

列、特定, 9.5.9.2

監査証跡の作成, 9.5.7

DBMS_FGAパッケージ, 9.5.9.1

データのダイレクト・ロード, 9.5.1, 9.5.1

エディションベースの再定義, 9.5.6

エディション, 結果, 6.4.4.2

暗号化された表列, 9.5.9.2

トレース・ファイルの確認によるエラーの検索, 9.10

監査レコードの生成方法, 9.5.8

使用方法, 9.5.1

監査レコードの場所, 9.5.2

監査対象の非SYSアクティビティ, 9.1.4

ポリシー

追加, 9.5.9.2

無効化, 9.5.9.3

削除, 9.5.9.4

有効化, 9.5.9.3

変更, 9.5.9.2

作成場所, 9.5.9.2

必要な権限, 9.5.4 レコード

アーカイブ, 9.8.2.5

「SYS.FGA_LOG$表」も参照 ファイアウォール

使用に関するアドバイス, 10.9.2

データベース・サーバーの場所, 10.9.2

ポート, 10.9.3

サポートされるタイプ, 10.9.2

フラッシュバック問合せ

監査、使用, 9.8.2.1

Oracle Virtual Private Database、仕組み, 7.5.6

外部キー

親キーを使用するための権限, 4.6.4.2

FTPサービス, 10.9.2 ファンクション

監査, 9.3.12.1

Oracle Virtual Private Database

コンポーネント, 7.2.1

実行に使用する権限, 7.1.3

権限, 4.6.6.1 ロール, 4.5.1.5

G

GATHER_SYSTEM_STATISTICSロール, 4.5.2

グローバル・アプリケーション・コンテキスト

概要, 6.4.1

非データベース・ユーザーの認証, 6.4.4.6

コンポーネント, 6.4.1

エディション, 影響, 6.4.4.2

非データベース・ユーザーを認証する例, 6.4.4.6

異なるアプリケーションに移動するユーザーを認証する例, 6.4.4.5

全ユーザーに値を設定する例, 6.4.4.4

Oracle RAC環境, 6.4.2

Oracle RACインスタンス, 6.4.1

所有権, 6.4.3

PL/SQLパッケージの作成, 6.4.4.1

プロセス, 軽量ユーザー, 6.4.7.2

プロセス, 標準, 6.4.7.1

全ユーザーを対象として値をグローバルに共有, 6.4.4.4

システム・グローバル領域, 6.4.1

クライアント・セッションIDの例, 6.4.6.1

One Big Application Userシナリオの使用, 7.5.9

USER関数を使用したユーザー名の取得, 6.4.4.3

使用, 7.5.9

「アプリケーション・コンテキスト」も参照

グローバル認証

概要, 3.7

利点, 3.7.2

プライベート・スキーマを持つユーザーの作成, 3.7.1.1

スキーマを共有するユーザーの作成, 3.7.1.2

グローバル認可

概要, 3.7

利点, 3.7.2

ロールの作成, 4.5.4.4

ロール, 3.7

グローバル・ロール

概要, 4.5.4.4

グローバル・ユーザー, 3.7 GLOBAL_AQ_USER_ROLEロール, 4.5.2 ログイン試行の猶予期間

例, 3.2.3.8

パスワード期限切れの猶予期間, 3.2.3.8 GRANT ALL PRIVILEGES文

SELECT ANY DICTIONARY権限、除外, 10.6

GRANT ANY OBJECT PRIVILEGEシステム権限, 4.7.2.2, 4.8.2.1 GRANT ANY PRIVILEGEシステム権限, 4.4.4 GRANT CONNECT THROUGH句

FAILED_LOGIN_ATTEMPTSパラメータ設定時の考慮事項, 3.2.3.3

プロキシ認可, 3.10.1.4

GRANT文, 4.7.1

ADMIN OPTION, 4.7.1.1

新規ユーザーの作成, 4.7.1.2

オブジェクト権限, 4.7.2, 5.8.1

システム権限とロール, 4.7

有効になるとき, 4.11

WITH GRANT OPTION, 4.7.2.1

権限とロールの付与

概要, 4.4.3

情報の検索, 4.13

ALLの指定, 4.6.2

セキュリティに関するガイドライン

監査, 10.10

カスタム・インストール, 10.8, 10.8

データ・ファイルおよびディレクトリ, 10.6

機密性の高いデータの暗号化, 10.6

インストールと構成, 10.8

ネットワーク・セキュリティ, 10.9

オペレーティング・システム・アカウント、権限の制限, 10.6

オペレーティング・システム・ユーザー、数の制限, 10.6

Oracleホームのデフォルト権限、変更禁止, 10.6

ORACLE_DATAPUMPアクセス・ドライバ, 10.7

パスワード, 10.5

Secure Socket Layer

モード, 10.9.3

TCPSプロトコル, 10.9.3

シンボリック・リンク、制限, 10.6 ユーザー・アカウントと権限, 10.3

H

ハッカー

「セキュリティ攻撃」を参照

HS_ADMIN_EXECUTE_ROLEロール

概要, 4.5.2

HS_ADMIN_ROLEロール

概要, 4.5.2

HS_ADMIN_SELECT_ROLEロール

概要, 4.5.2

HTTP認証

「アクセス制御リスト(ACL)」、「ウォレット・アクセス」を参照、

HTTPS

ポート、正しい実行, 10.9.3

I

IMP_FULL_DATABASEロール

概要, 4.5.2

INDEX権限

許可されるSQL文, 5.8.2

索引付けされたデータ

暗号化, 8.2.1

間接的に付与されたロール, 4.5.1.1 初期化パラメータ

アプリケーションの保護, 5.9

AUDIT_FILE_DEST, 9.1.5, 9.6.2

AUDIT_SYS_OPERATIONS, 9.6.2

AUDIT_SYSLOG_LEVEL, 9.3.5.4

AUDIT_TRAIL

概要, 9.3.2.1

使用, 9.3.2.2

現在の値、調べる, 9.3.2.1 MAX_ENABLED_ROLES, 4.11.3 O7_DICTIONARY_ACCESSIBILITY, 4.4.2.1 OS_AUTHENT_PREFIX, 3.8.1 OS_ROLES, 4.5.4.3.1 REMOTE_OS_AUTHENT, 10.9.1 RESOURCE_LIMIT, 2.4.4 SEC_CASE_SENSITIVE_LOGON, 3.2.3.11 SEC_MAX_FAILED_LOGIN_ATTEMPTS, 5.9.3 SEC_PROTOCOL_ERROR_FURTHER_ACTION, 5.9.2 SEC_PROTOCOL_ERROR_TRACE_ACTION, 5.9.1 SEC_RETURN_SERVER_RELEASE_BANNER, 5.9.4 SEC_USER_AUDIT_ACTION_BANNER, 5.9.5 SEC_USER_UNAUTHORIZED_ACCESS_BANNER, 5.9.5 INSERT権限

付与, 4.7.2.3

取消し, 4.8.2.2

許可されるSQL文, 5.8.2

インストール

セキュリティに関するガイドライン, 10.8

侵入者

「セキュリティ攻撃」を参照

実行者権限

概要, 4.6.6.4

プロシージャ権限、使用, 4.6.6.3

プロシージャのセキュリティ, 4.6.6.4

セキュア・アプリケーション・ロール, 5.5.2

セキュア・アプリケーション・ロール、使用可能にするための要件, 5.5.2

IPアドレス

偽造, 10.9.2

J

JAVA_ADMINロール, 4.5.2

JAVA_DEPLOYロール, 4.5.2

JAVADEBUGPRIVロール, 4.5.2

JAVAIDPRIVロール, 4.5.2

JAVASYSPRIVロール, 4.5.2

JAVAUSERPRIVロール, 4.5.2

JDBC接続

JDBCシン・ドライバ・プロキシ認証

構成, 3.10.1.1

実際のユーザー, 3.10.1.6

JDBC/OCIプロキシ認証, 3.10.1.1

複数のユーザー・セッション, 3.10.1.6

Oracle Virtual Private Database, 7.5.9

JMXSERVERロール, 4.5.2

K

Kerberos認証, 3.6.2

SYSDBAまたはSYSOPERアクセスの構成, 3.3.1.2

パスワード管理, 10.5

鍵の生成

暗号化, 8.2.2

鍵の格納

暗号化, 8.2.4

鍵の転送

暗号化, 8.2.3

L

LBAC_DBAロール, 4.5.2

「最低限の権限」原則, 10.3

概要, 10.3

ユーザー権限の付与, 10.3

中間層の権限, 3.10.1.7

ライブラリ

セキュリティ・ガイドライン, 10.3

軽量ユーザー

グローバル・アプリケーション・コンテキストを使用した例, 6.4.6.1

Lightweight Directory Access Protocol(LDAP), 7.4.2.8

リスナー

非Oracle所有者, 10.9.2

オンライン管理の回避, 10.9.2

権限の制限, 10.9.2, 10.9.2

安全性の高い管理, 10.9.2

listener.oraファイル

リモート管理, 10.9.2, 10.9.2

デフォルトの場所, 10.9.3

オンライン管理、回避, 10.9.2

TCPS、保護, 10.9.3

LOB

監査, 9.5.3

ロックおよび期限切れ

デフォルトのアカウント, 10.3

事前定義のユーザー・アカウント, 10.3

ログ・ファイル

監査、デフォルトの位置, 9.3.4.5

信頼できるユーザーが所有, 10.6

Windowsイベントビューア, 9.6.2

論理読取りの制限, 2.4.2.4 ログイン・トリガー

現行セッションの監査, 9.3.7.3

例, 6.3.4

外部で初期化されたアプリケーション・コンテキスト, 6.3.4

セキュア・アプリケーション・ロール, 4.5.8

LOGSTDBY_ADMINISTRATORロール, 4.5.2

M

不正なデータベース管理者

「セキュリティ攻撃」も参照

デフォルトのmanagerパスワード, 10.5 必須監査

概要, 9.1.5

syslogへの書込み, 9.1.5

メモリー

ユーザー、表示, 2.6.5

MERGE INTO文、DBMS_RLS.ADD_POLICY statement_typesパラメータの影響を受けた, 7.3.3 メソッド

権限, 4.6.7

MGMT_USERロール, 4.5.2 中間層システム

クライアント識別子, 3.10.2.2

エンタープライズ・ユーザーでの接続, 3.10.1.10.2

パスワード・ベースのプロキシ認証, 3.10.1.10.1

権限、制限, 3.10.1.7

プロキシ認証ユーザー, 3.10.1.8

プロキシとして機能していても認証されないユーザー, 3.10.1.9

データベースへのユーザーの再認証, 3.10.1.10

USERENVネームスペース属性、アクセス, 6.3.6.3

ユーザー・アクションの監視

「監査、標準監査、ファイングレイン監査」も参照

複数のクライアント・ネットワーク・セッションの多重化, 10.9.2 My Oracle Support

セキュリティ・パッチ、ダウンロード, 10.2.1

N

Net8

「Oracle Net」を参照

ネットワーク監査

概要, 9.3.13.1

削除, 9.3.13.3

ネットワーク認証

外部認証, 3.8.5

保護に関するガイドライン, 10.5

ロール, 使用した付与, 4.10

Secure Sockets Layer, 3.6.1

スマート・カード, 10.5

サード・パーティ・サービス, 3.6.2

トークン・カード, 10.5

X.509証明書, 10.5

ネットワーク接続

サービス拒否(DoS)攻撃、対処, 10.9.2

セキュリティに関するガイドライン, 10.9, 10.9.1, 10.9.2

保護, 10.9.2

ネットワークIPアドレス

セキュリティに関するガイドライン, 10.9.2

新機能、セキュリティ, はじめに NOAUDIT文

監査オプション、削除, 9.3.6.7

デフォルトのオブジェクト監査オプション、使用禁止, 9.3.10.6

ネットワーク監査、削除, 9.3.13.3

オブジェクト監査、削除, 9.3.10.6

権限監査、削除, 9.3.8.4

文監査、削除, 9.3.7.4, 9.3.7.4

非データベース・ユーザー

概要, 6.4.1

監査レコード情報, 9.8.1

監査, 9.5.11.1

セッション・データの消去, 6.4.4.7

クライアント・セッション・ベース・アプリケーション・コンテキストの作成, 6.5.1

グローバル・アプリケーション・コンテキスト

パッケージの例, 6.4.4.6

使用理由, 6.4.1

設定, 6.4.4.6

チュートリアル, 6.4.6.1

One Big Application Userの認証

概要, 7.5.9

使用できない機能, 5.2.1

セキュリティ上のリスク, 5.2.1

Oracle Virtual Private Database

仕組み, 7.5.9

ポリシー・グループの作成の例, 7.4.3.1

「アプリケーション・コンテキスト」、「クライアント識別子」も参照

O

O7_DICTIONARY_ACCESSIBILITY初期化パラメータ

概要, 4.4.2.1

SYSオブジェクトに対する権限の監査, 9.1.3, 9.3.1.2

データ・ディクショナリの保護, 10.6

デフォルト設定, 10.6

データ・ディクショナリの保護, 4.4.2.1

オブジェクト列

監査, 9.5.3

オブジェクト権限, 10.3

概要, 4.6.3

所有者にかわる付与, 4.7.2.2

管理, 5.8

取消し, 4.8.2

所有者にかわる取消し, 4.8.2.1

シノニム, 4.6.3.3

「スキーマ・オブジェクト権限」も参照

オブジェクト

アプリケーション、権限の管理, 5.8

権限の付与, 5.8.2

権限

アプリケーション, 5.8.1

管理, 4.6.7

共有スキーマでの保護, 5.7.2 一意スキーマでの保護, 5.7.1 SYSスキーマ、アクセス, 4.4.2.2 OEM_ADVISORロール, 4.5.2 OEM_MONITORロール, 4.5.2 OLAP_DBAロール, 4.5.2 OLAP_USERロール, 4.5.2 OLAP_XS_ADMINロール, 4.5.2 One Big Application Userの認証

「非データベース・ユーザー」を参照

オペレーティング・システム監査証跡

有効期間、制御, 9.8.3.3

データベース監査証跡と共通して監査されるアクション, 9.3.3

サイズ、制御, 9.8.3.2

オペレーティング・システム

アカウント, 4.10.2

認証

概要, 3.5

利点, 3.5

デメリット, 3.5

ロール, 使用, 4.10

認証、外部, 3.8.4 デフォルトの権限, 10.6 ロールを使用可能および使用禁止にする方法, 4.10.5 オペレーティング・システム・アカウント権限、制限, 10.6 ロール識別機能, 4.10.2 ロール, 4.5.1.7 ロール, 使用した付与, 4.10 ユーザー、数の制限, 10.6 OPW-00005エラー, 2.3.4 ORA-01720エラー, 4.6.5.2 ORA-06512エラー, 9.5.10.6 ORA-1536エラー, 2.2.5.1 ORA-24247エラー, 4.12.3, 9.5.10.6 ORA-28009エラー, 4.4.2.1 ORA-28040エラー, 3.4.1 ORA-28132エラー, はじめに Oracle Advanced Security

ネットワーク認証サービス, 10.5

ネットワーク通信の暗号化, 10.9.2

アプリケーション・スキーマへのユーザー・アクセス, 5.7.2

Oracle Call Interface(OCI)

アプリケーション・コンテキスト、クライアント・セッション・ベース, 6.5.1

プロキシ認証, 3.10.1.1

Oracle Virtual Private Database、仕組み, 7.5.9

実際のユーザーによるプロキシ認証, 3.10.1.6 セキュリティに関する初期化パラメータ, 5.9 Oracle Connection Manager

クライアント・ネットワークの保護, 10.9.2

Oracle Data Pump

VPDポリシーからのエクスポート・データ, 7.5.8

Oracle Database Enterprise User Security

パスワードのセキュリティ脅威, 3.2.4

Oracle Enterprise Security Manager

ロール管理, 3.6.2

Oracleホーム

デフォルトの権限、変更禁止, 10.6

Oracle Internet Directory(OID)

ディレクトリベース・サービスを使用した認証, 3.6.2

SYSDBAおよびSYSOPERのアクセス、管理, 3.3.1

Oracle Java Virtual Machine(OJVM)

権限、制限, 10.3

Oracle Label Security(OLS)

Oracle Virtual Private Database、使用, 7.5.7.1

Oracle Net

ファイアウォールのサポート, 10.9.2

Oracle Real Application Clusters

監査レコードのアーカイブ・タイムスタンプ, 9.9.3.4

グローバル・アプリケーション・コンテキスト, 6.4.2

グローバル・コンテキスト, 6.4.1

Oracle Technology Network

セキュリティ・アラート, 10.2.1

Oracle Virtual Private Database(VPD)

概要, 7.1.1

ANSI操作, 7.5.3

アプリケーション・コンテキスト

例, 7.4.2.1

使用, 7.1.4

アプリケーション

仕組み, 7.5.4

データベース・ユーザーであるユーザー、仕組み, 7.5.9

セキュリティのために使用するアプリケーション, 5.2.2 自動再解析、仕組み, 7.5.5 メリット, 7.1.2 列レベル, 7.3.4.1 列のマスク動作

有効, 7.3.4.3

制限, 7.3.4.3

列レベルの表示, 7.3.4.1 コンポーネント, 7.2 構成, 7.3 カーソル、共有, 7.1.4 エディションベースの再定義, 7.5.1 エディション, 結果, 6.4.4.2 エンタープライズ・ユーザー・セキュリティ・プロキシ認証、仕組み, 7.5.9 データのエクスポート, 7.5.7.2 データ・ポンプ・エクスポートを使用してデータをエクスポート, 7.5.8 情報の検索, 7.6 フラッシュバック問合せ、仕組み, 7.5.6 関数

監査, 9.3.10.2

コンポーネント, 7.2.1

実行方法, 7.1.3

JDBCプロキシ認証、仕組み, 7.5.9 MERGE INTO、ORA-28132エラー, はじめに 非データベース・ユーザー・アプリケーション、仕組み, 7.5.9 OCIプロキシ認証、仕組み, 7.5.9 Oracle Label Security

動作の例外, 7.5.7.2

使用, 7.5.7.1

外部結合操作, 7.5.3 パフォーマンス、メリット, 7.1.2.2 ポリシー、Oracle Virtual Private Database

概要, 7.3.1

アプリケーション、検証, 7.3.5.5

データベース・オブジェクトへの付加, 7.3.2

列の表示, 7.3.4.1

列レベルの表示、デフォルト, 7.3.4.2

動的, 7.3.6.2

複数, 7.3.5.4

パフォーマンスの最適化, 7.3.6.1

実行に使用する権限, 7.1.3

SQL文、指定, 7.3.3

ポリシー・グループ

概要, 7.3.5.1

メリット, 7.3.5.1

作成, 7.3.5.2

デフォルト, 7.3.5.3

例、実装, 7.4.3.1

ポリシー・タイプ

状況依存、概要, 7.3.6.6

状況依存、使用する場合, 7.3.6.8

状況依存、監査対象, 9.3.12.1

DYNAMIC, 7.3.6.2

動的、監査対象, 9.3.12.1

共有の状況依存、概要, 7.3.6.7

共有の状況依存、使用する場合, 7.3.6.8

共有の静的、概要, 7.3.6.4

共有の静的、使用する場合, 7.3.6.5

静的、概要, 7.3.6.3

静的、監査対象, 9.3.12.1

静的、使用する場合, 7.3.6.5

機能の要約, 7.3.6.9

ポリシー内のSELECT FOR UPDATE文, 7.5.2 例、単純, 7.4.1.1 ユーザー・モデル, 7.5.9 Webベースのアプリケーション、仕組み, 7.5.9 Oracle Wallet Manager

X.509v3証明書, 3.6.2

Oracleウォレット

認証方式, 3.6.2

Oracle Warehouse Builder

ロール, 事前定義, 4.5.2

ORACLE_DATAPUMPアクセス・ドライバ

セキュリティに関するガイドライン, 10.7

OracleMetaLink

「My Oracle Support」を参照

ORAPWDパスワード・ユーティリティ

パスワードの大/小文字の区別, 3.2.3.11

パスワード・ファイル認証, 3.3.3

実行権限, 3.3.3

ORAPWDユーティリティ

SYSパスワードを変更, 2.3.4

ORDADMINロール, 4.5.2 OS_ROLES初期化パラメータ

オペレーティング・システムによるロール付与, 4.10.5

オペレーティング・システムによる認可, 4.5.4.3.1

REMOTE_OS_ROLES, 4.10.6

使用, 4.10.2

外部結合操作

Oracle Virtual Private Databaseの影響, 7.5.3

OWB_DESIGNCENTER_VIEWロール, 4.5.2 OWB_USERロール, 4.5.2 OWB$CLIENTロール, 4.5.2

P

パッケージ

監査, 9.3.12.1

例, 4.6.6.7

権限の使用例, 4.6.6.7

権限

構成メンバーごとに分割, 4.6.6.7

実行, 4.6.6.1, 4.6.6.7

パラレル実行サーバー, 6.3.3.4 パラレル問合せ、SYS_CONTEXT, 6.3.3.4 パスフレーズ

server.keyファイルの読取りと解析, 10.9.3

パスワード・ファイル

大/小文字の区別、SEC_CASE_SENSITIVE_LOGONパラメータへの影響, 3.2.3.11

管理者を認証するための使用方法, 3.3.3

PASSWORD文

概要, 2.3.3

PASSWORD_LIFE_TIMEプロファイル・パラメータ, 3.2.3.7 PASSWORD_LOCK_TIMEプロファイル・パラメータ, 3.2.3.5 PASSWORD_REUSE_MAXプロファイル・パラメータ, 3.2.3.6 PASSWORD_REUSE_TIMEプロファイル・パラメータ, 3.2.3.6 パスワード

管理の概要, 3.2.3.1

アカウントのロック, 3.2.3.5, 3.2.3.5

管理者

認証, 3.3.3

保護に関するガイドライン, 10.5

エイジングおよび期限切れ, 3.2.3.7 ALTER PROFILE文, 3.2.3.1 変更, 2.3.3 アプリケーション設計のガイドライン, 5.3.1.2 アプリケーション、パスワード保護の戦略, 5.3 総当り攻撃, 3.2.1 大/小文字の区別の設定、SEC_CASE_SENSITIVE_LOGIN, 3.2.3.11 大/小文字の区別, 構成, 3.2.3.11 ロールに対する変更, 4.5.3 複雑度の検証

概要, 3.2.3.10

セキュリティに関するガイドライン, 10.5

指定しない接続, 3.5 CREATE PROFILE文, 3.2.3.1 クリアテキストで格納する危険性, 10.5, 10.5 データベース・ユーザーの認証, 3.4.1 デフォルト・プロファイルの設定

概要, 3.2.3.3

デフォルト・ユーザー・アカウント, 10.5 デフォルト、検索, 3.2.3.2 誤ったパスワードに対する遅延, 3.2.1 期間, 10.5 暗号化, 3.2.1, 10.5, 10.5 作成例, 3.2.2 期限切れ

明示的, 3.2.3.8

プロシージャ, 3.2.3.7

プロキシ・アカウントのパスワード, 3.10.1.4

猶予期間, 3.2.3.8

ログインの失敗、リセット, 3.2.3.5 バージョンの確認, 3.2.3.11 猶予期間, 例, 3.2.3.8 セキュリティに関するガイドライン, 10.5 履歴, 3.2.3.6, 3.2.3.6 パスワードを読み取るためのJavaコード例, 5.3.4 存続期間の設定が低すぎます, 3.2.3.9 存続期間, 3.2.3.7 ロック時間, 3.2.3.5 管理ルール, 10.5 管理, 3.2.3 最大再利用回数, 3.2.3.6 ORAPWDパスワード・ユーティリティ, 3.2.3.11 パスワードの複雑度の検証, 3.2.3.10 パスワード・ファイルのリスク, 3.3.3 PASSWORD_LOCK_TIMEプロファイル・パラメータ, 3.2.3.5 PASSWORD_REUSE_MAXプロファイル・パラメータ, 3.2.3.6 PASSWORD_REUSE_TIMEプロファイル・パラメータ, 3.2.3.6 ポリシー, 3.2.3 ロールに対して変更するための権限, 4.5.3 変更するための権限, 2.3.1 保護、組込み, 3.2.1 プロキシ認証, 3.10.1.10.1 要件

追加, 10.5

最小, 3.2.2

再利用, 3.2.3.6, 10.5 パスワードの再利用, 3.2.3.6 パスワードによって認証されるロール, 4.5.3 SET ROLE文によって使用可能になるロール, 4.5.4.1 安全性の高い外部パスワード・ストア, 3.2.5.1 セキュリティ上のリスク, 3.3.3 SYSアカウント, 2.3.4 SYSおよびSYSTEM, 10.5, 10.5 ロールでの使用, 4.5.1.2 UTLPWDMG.SQLパスワード・スクリプト

パスワード管理, 3.2.3.10

SHA-1ハッシュ・アルゴリズムを使用した検証, 3.2.4, 3.2.4 「認証、およびアクセス制御リスト(ACL)、ウォレット・アクセス」も参照 パフォーマンス

アプリケーション・コンテキスト, 6.1.3

監査, 9.1.7

データベース監査証跡、異なる表領域への移動, 9.8.2.3

Oracle Virtual Private Databaseポリシー, 7.1.2.2

Oracle Virtual Private Databaseのポリシー・タイプ, 7.3.6.1

リソース制限, 2.4.1

権限

デフォルト, 10.6

ランタイム機能, 10.3

PKI

公開鍵インフラストラクチャ(PKI)を参照

PL/SQL

文の監査, 9.3.1.3

プロシージャでのロール, 4.5.1.5

PL/SQLファンクション

監査, 9.3.12.2

PL/SQLパッケージ

監査, 9.3.12.1, 9.3.12.2

PL/SQLプロシージャ

監査, 9.3.12.2

アプリケーション・コンテキストの設定, 6.3.3.1

PMONバックグラウンド・プロセス

アプリケーション・コンテキスト、クリーン・アップ, 6.3.1

位置パラメータ

セキュリティ上のリスク, 5.3.1.4

「最低限の権限」原則, 10.3

概要, 10.3

ユーザー権限の付与, 10.3

中間層の権限, 3.10.1.7

権限

概要, 4.1

アクセス制御リスト、外部ネットワーク・サービスのチェック, 4.12.10

変更

パスワード, 2.3.3

ユーザー, 2.3.1

ロールの認証方式の変更, 4.5.3 アプリケーション、管理, 5.4 デフォルト監査が使用可能な場合の監査, 9.4.2 使用の監査, 9.3.8.1, 9.3.8.3 監査、推奨設定, 10.10.5 連鎖的な取消し, 4.8.3 列, 4.7.2.3 プロシージャのコンパイル, 4.6.6.6 プロシージャの作成または置換, 4.6.6.5 ユーザーの作成, 2.2.1 プロファイルの削除, 2.4.4.2 情報の検索, 4.13 付与

概要, 4.4.3, 4.7

例, 4.6.6.7, 4.6.6.7

オブジェクト権限, 4.6.3.1, 4.7.2

システム, 4.7.1

システム権限, 4.7

権限付与, リスト, 4.13.1 ロールによるグループ化, 4.5 管理, 5.8 中間層, 3.10.1.7 オブジェクト, 4.6.1, 4.6.2, 5.8.2

付与と取消し, 4.6.3.1

選択した列, 4.8.2.2 プロシージャ, 4.6.6.1

作成と置換, 4.6.6.5

実行, 4.6.6.1

パッケージ, 4.6.6.7

付与する理由, 4.2 権限の取消し

概要, 4.4.3

オブジェクト, 4.8.2

オブジェクト権限、連鎖的な影響, 4.8.3.2

オブジェクト権限、要件, 4.8.2

スキーマ・オブジェクト, 4.6.3.1

システム権限の取消し, 4.8.1 ロール

作成, 4.5.3

削除, 4.5.6

制限, 4.5.1.6

ロール、付与が推奨される理由, 4.2 スキーマ・オブジェクト, 4.6.3

DML操作とDDL操作, 4.6.4

パッケージ, 4.6.6.7

プロシージャ, 4.6.6.1

許可されるSQL文, 5.8.2 シノニムと基礎オブジェクト, 4.6.3.3 システム

付与と取消し, 4.4.3

SELECT ANY DICTIONARY, 10.6

SYSTEMおよびOBJECT, 10.3 システム権限

概要, 4.4.1

トリガー権限, 4.6.6.3 Oracle Virtual Private Databaseポリシー関数での使用, 7.1.3 ビューに対する権限

ビューの作成, 4.6.5.2

ビューの使用, 4.6.5.3

ビュー, 4.6.5.1 「アクセス制御リスト(ACL)」および「システム権限」も参照 プロシージャ

監査, 9.3.10.4, 9.3.12.1

コンパイル, 4.6.6.6

定義者権限

概要, 4.6.6.3

ロールの使用禁止, 4.5.1.5.1

例, 4.6.6.7 権限の使用例, 4.6.6.7 実行者権限

概要, 4.6.6.4

使用されるロール, 4.5.1.5.2

プロシージャに対する権限

作成または置換, 4.6.6.5

実行, 4.6.6.1

パッケージ内での実行, 4.6.6.7

必要な権限, 4.6.6.5 セキュリティの強化, 4.6.6.3 プロセス・モニター(PMON)・プロセス

タイムアウト・セッションのクリーン・アップ, 2.4.2.5

PRODUCT_USER_PROFILE表, 4.5.7.2

SQLコマンド、使用禁止, 4.5.7.2

製品およびオプション

必要な場合のみインストール, 10.8

プロファイル・パラメータ

FAILED_LOGIN_ATTEMPTS, 3.2.3.3

PASSWORD_GRACE_TIME, 3.2.3.3, 3.2.3.8

PASSWORD_LIFE_TIME, 3.2.3.3, 3.2.3.7, 3.2.3.9

PASSWORD_LOCK_TIME, 3.2.3.3, 3.2.3.5

PASSWORD_REUSE_MAX, 3.2.3.3, 3.2.3.6

PASSWORD_REUSE_TIME, 3.2.3.3, 3.2.3.6

プロファイル, 2.4.4

概要, 2.4.4

作成, 2.4.4.1

削除, 2.4.4.2, 2.4.4.2

情報の検索, 2.6.1

デフォルト・プロファイルの設定の検索, 2.6.4

管理, 2.4.4

パスワード管理, 3.2.3.1

削除するための権限, 2.4.4.2

ユーザーに対する指定, 2.2.7

表示, 2.6.4

プロキシ認証

概要, 3.10.1.1, 3.10.1.1

利点, 3.10.1.2

監査対象操作, 3.9.1

ユーザーの監査, 9.3.9

クライアントから中間層を介した順序, 3.10.1.6

プロキシ・ユーザー・アカウントの作成, 3.10.1.3

中間層

認証されないユーザーの認可, 3.10.1.9

ユーザーのプロキシとしての機能とユーザーの認証の認可, 3.10.1.8

権限の制限, 3.10.1.7

ユーザーの再認証, 3.10.1.10

パスワード、期限切れ, 3.10.1.4 ユーザーの作成に必要な権限, 3.10.1.3 安全性の高い外部パスワード・ストア、使用, 3.10.1.5 セキュリティ上のメリット, 3.10.1.2 ユーザー、実際の識別情報の引渡し, 3.10.1.6 プロキシ・ユーザー・アカウント

作成に必要な権限, 3.10.1.3

PROXY_USER属性, 6.3.6.3 PROXY_USERSビュー, 3.10.1.4 疑似列

USER, 4.6.5.3

PUBLIC

プロシージャ, 4.9

ロール, 4.9

公開鍵インフラストラクチャ(PKI)

概要, 3.6.2

PUBLICロール

概要, 4.4.5

権限の付与と取消し, 4.9

ユーザーのセキュリティ・ドメイン, 4.5.1.4

付与された権限のセキュリティ・リスク, 4.4.5

PUBLIC_DEFAULTプロファイル

プロファイル、削除, 2.4.4.2

Q

割当て制限

表領域, 2.2.5

一時セグメント, 2.2.5

無制限, 2.2.5.2

表示, 2.6.3

R

RADIUS認証, 3.6.2

読取り専用モード、AUDIT_TRAILパラメータへの影響, 9.3.2.2

読取り

データ・ブロックの制限, 2.4.2.4

RECOVERY_CATALOG_OWNERロール

概要, 4.5.2

ログ・ファイル

コミットおよびロールバックされたトランザクションの監査, 10.10.3

REFERENCES権限

CASCADE CONSTRAINTSオプション, 4.8.2.3

取消し, 4.8.2.2, 4.8.2.3

許可されるSQL文, 5.8.2

リモート認証, 10.9.1, 10.9.1 REMOTE_OS_AUTHENT初期化パラメータ

保護に関するガイドライン, 10.9.1

設定, 3.8.4

remote_os_authentication, 10.9.1 REMOTE_OS_ROLES初期化パラメータ

ネットワークでのOSロール管理のリスク, 4.10.6

設定, 4.5.4.3.2

リソース制限

概要, 2.4.1

コール・レベル、制限, 2.4.2.2

セッション当たりの接続時間, 2.4.2.5

CPUタイム、制限, 2.4.2.3

値の決定, 2.4.3

セッション当たりのアイドル時間, 2.4.2.5

論理読取り、制限, 2.4.2.4

セッション当たりのプライベートSGA領域, 2.4.2.5

プロファイル, 2.4.4, 2.4.4

セッション・レベル、制限, 2.4.2.1

セッション

ユーザー当たりの同時数, 2.4.2.5

経過接続時間, 2.4.2.5

アイドル時間, 2.4.2.5

SGA領域, 2.4.2.5

タイプ, 2.4.2 RESOURCE権限

CREATE SCHEMA文、必要, 5.7.1

RESOURCEロール, 4.6.7.1

概要, 4.5.2

REVOKE CONNECT THROUGH句

プロキシ認可の取消し, 3.10.1.4

REVOKE文

システム権限とロール, 4.8.1

有効になるとき, 4.11

権限とロールの取消し

連鎖的な影響, 4.8.3

選択した列, 4.8.2.2

REVOKE文, 4.8.1

ALLの指定, 4.6.2

オペレーティング・システム・ロールを使用した場合, 4.10.4

ロール識別機能

オペレーティング・システム・アカウント, 4.10.2

ROLE_SYS_PRIVSビュー

アプリケーション権限, 5.4

ROLE_TAB_PRIVSビュー

アプリケーション権限、検索, 5.4

ロール

概要, 4.1, 4.5.1

ADM_PARALLEL_EXECUTE_TASKロール, 4.5.2

ADMIN OPTION, 4.7.1.1

アプリケーションに使用する利点, 5.4

アプリケーション, 4.5.1.3.1, 4.5.7, 5.6, 5.6, 5.8

アプリケーション権限, 5.4

アプリケーション、ユーザー, 5.6

AQ_ADMINISTRATOR_ROLEロール, 4.5.2

AQ_USER_ROLEロール, 4.5.2

AUTHENTICATEDUSERロール, 4.5.2

認可, 4.5.4

エンタープライズ・ディレクトリ・サービスによる認可, 4.5.4.4

CAPI_USER_ROLEロール, 4.5.2

認可の変更, 4.5.3

パスワードの変更, 4.5.3

CONNECT, 4.5.1.1

CONNECTロール

概要, 4.5.2

独自の作成, 10.4 CSW_USR_ROLEロール, 4.5.2 CTXAPPロール, 4.5.2 CWM_USERロール, 4.5.2 データベース・ロール、ユーザー, 5.6.1 DATAPUMP_EXP_FULL_DATABASEロール, 4.5.2 DATAPUMP_IMP_FULL_DATABASEロール, 4.5.2 DBAロール, 4.5.2 DBFS_ROLEロール, 4.5.2 DDL文, 4.5.1.6 デフォルト, 4.11.2 デフォルト、ユーザーに対する設定, 2.2.8 定義者権限プロシージャでは使用禁止, 4.5.1.5.1 DELETE_CATALOG_ROLEロール, 4.5.2 依存性管理, 4.5.1.6 無効化, 4.11.1 削除, 4.5.6 EJBCLIENTロール, 4.5.2 使用可能または使用禁止, 4.5.1.1, 4.5.5.1 有効化, 4.11.1, 5.6 エンタープライズ, 3.7, 4.5.4.4 EXECUTE_CATALOG_ROLEロール, 4.5.2 EXP_FULL_DATABASEロール, 4.5.2 情報の検索, 4.13 機能, 4.2, 4.5.1.1 機能, 4.5.1.1 GATHER_SYSTEM_STATISTICSロール, 4.5.2 グローバル認可, 4.5.4.4

概要, 4.5.4.4

グローバル・ロール

概要, 3.7

作成, 4.5.4.4

外部ソース, および, 4.5.4.3

GLOBAL_AQ_USER_ROLEロール, 4.5.2 GRANT文, 4.10.5 別のロールへの付与, 4.5.1.1 ロールの付与

概要, 4.7

メソッド, 4.5.5.1

システム, 4.7.1

システム権限, 4.4.3

セキュリティに関するガイドライン, 10.4 HS_ADMIN_EXECUTE_ROLEロール, 4.5.2 HS_ADMIN_ROLEロール, 4.5.2 HS_ADMIN_SELECT_ROLEロール, 4.5.2 IMP_FULL_DATABASEロール, 4.5.2 アプリケーション, 4.5.1.2 間接的に付与された, 4.5.1.1 実行者権限プロシージャの使用, 4.5.1.5.2 JAVA_ADMINロール, 4.5.2 JAVA_DEPLOYロール, 4.5.2 JAVADEBUGPRIVロール, 4.5.2 JAVAIDPRIVロール, 4.5.2 JAVASYSPRIVロール, 4.5.2 JAVAUSERPRIVロール, 4.5.2 JMXSERVERロール, 4.5.2 担当業務の権限のみ, 10.4 LBAC_DBAロール, 4.5.2 権限付与のリスト, 4.13.2 権限とロールのリスト, 4.13.6 ロールのリスト, 4.13.5 LOGSTDBY_ADMINISTRATORロール, 4.5.2 オペレーティング・システムを使用した管理, 4.10 ロールの管理

概要, 4.5

ユーザーの分類, 5.8

オペレーティング・システムを介した管理, 4.5.1.7 1ユーザーが使用可能にできる最大数, 4.11.3 MGMT_USERロール, 4.5.2 名前に含まれているマルチバイト・キャラクタ, 4.5.3 パスワードに含まれているマルチバイト・キャラクタ, 4.5.4.1 ネーミング, 4.5.1 ネットワーク認可, 4.5.4.3.2 ネットワーク・クライアントによる認可, 4.5.4.3.2 OEM_ADVISORロール, 4.5.2 OEM_MONITORロール, 4.5.2 OLAP_DBAロール, 4.5.2 OLAP_USERロール, 4.5.2 OLAP_XS_ADMINロール, 4.5.2 One Big Application User、制限, 5.2.1 オペレーティング・システム, 4.10.2 オペレーティング・システムによる認可, 4.5.4.3.1 オペレーティング・システムによる付与, 4.10.5 オペレーティング・システムによる識別, 4.10.2 オペレーティング・システム管理と共有サーバー, 4.10.6 オペレーティング・システムによる管理, 4.10.3, 4.10.4 オペレーティング・システムによる認可, 4.5.4.3 ORDADMINロール, 4.5.2 OWB_DESIGNCENTER_VIEWロール, 4.5.2 OWB_USERロール, 4.5.2 OWB$CLIENTロール, 4.5.2 事前定義, 4.5.2 作成するための権限, 4.5.3 削除するための権限, 4.5.6 権限、認可方式の変更, 4.5.3 権限、パスワードの変更, 4.5.3 RECOVERY_CATALOG_OWNERロール, 4.5.2 RESOURCEロール, 4.5.2 ツール・ユーザーからの制限, 4.5.7 権限に関する制限, 4.5.1.6 REVOKE文, 4.10.5 取消し, 4.5.5.1, 4.8.1 ADMINオプションの取消し, 4.8.1 SCHEDULER_ADMINロール, 4.5.2 スキーマには含まれない, 4.5.1 セキュリティ・ドメイン, 4.5.1.4 SELECT_CATALOG_ROLEロール, 4.5.2 SET ROLE文, 4.10.5 PL/SQLブロック内で設定, 4.5.1.5.2 SNMPAGENTロール, 4.5.2 SPATIAL_CSW_ADMINロール, 4.5.2 SPATIAL_WFS_ADMINロール, 4.5.2 一意の名前, 4.5.3 パスワードの使用, 4.5.1.2 ユーザー, 4.5.1.3.2, 5.8 付与できるユーザー, 4.5.5.2 使用, 4.5.1.1, 4.5.1.3 WFS_USR_ROLEロール, 4.5.2 WITH GRANT OPTION, 4.7.2.1 認可なし, 4.5.3 WKUSERロール, Preface WM_ADMIN_ROLEロール, 4.5.2 XDB_SET_INVOKERロール, 4.5.2 XDB_WEBSERVICESロール, 4.5.2 XDB_WEBSERVICES_OVER_HTTPロール, 4.5.2 XDB_WEBSERVICES_WITH_PUBLICロール, 4.5.2 XDBADMINロール, 4.5.2 セキュア・アプリケーション・ロールも参照 ルート・ファイル・パス

データベース外部のファイルおよびパッケージ, 10.3

行レベルのセキュリティ

「ファイングレイン・アクセス・コントロール、Oracle Virtual Private Database (VPD)」を参照

RSA秘密鍵, 10.9.3 ランタイム機能, 10.3

権限の制限, 10.3

S

サンプル・スキーマ, 10.8

サンプル・スキーマ

本番のために削除または再びロック, 10.8

テスト・データベース, 10.8

米国サーベンス・オクスリー法

順守を満たすための監査, 9.1.1

SCHEDULER_ADMINロール

概要, 4.5.2

スキーマ・オブジェクトの監査

使用可能化, 9.3.10.5

削除, 9.3.10.6

スキーマ・オブジェクト権限, 4.6.3 スキーマ・オブジェクト

監査オプション、削除, 9.3.10.6

監査, 9.3.10.1

プロシージャまたはファンクションの監査, 9.3.10.5

取消しの連鎖的影響, 4.8.3.2

デフォルト監査オプション, 9.3.10.5

デフォルト表領域, 2.2.4

削除したユーザー、所有, 2.5

監査オプションを使用可能にする, 9.3.10.5

権限の付与, 4.7.2

権限

DML操作とDDL操作, 4.6.4

付与と取消し, 4.6.3.1

ビューに対する権限, 4.6.5.1

権限, 4.6.3 アクセスするための権限, 4.6.2 権限, 4.6.2 監査オプションの解除, 9.3.8.4 権限の取消し, 4.8.2 スキーマに依存しないユーザー, 5.7.2 スキーマ

監査、推奨設定, 10.10.5

プライベート, 3.7.1.1

エンタープライズ・ユーザーで共有, 3.7.1.2

共有、オブジェクトの保護, 5.7.2

一意, 5.7

一意、オブジェクトの保護, 5.7.1

SCOTTユーザー・アカウント

権限の制限, 10.4

スクリプト・ファイル

監査証跡ビュー、削除, 9.10.3

CATNOAUD.SQL, 9.10.3

スクリプト、ユーザーの認証, 3.2.5.1 SEC_CASE_SENSITIVE_LOGON初期化パラメータ

概要, 3.2.3.11

SQLNET.ALLOWED_LOGON_VERSION設定と競合, 3.2.3.11

SEC_MAX_FAILED_LOGIN_ATTEMPTS初期化パラメータ, 5.9.3 SEC_PROTOCOL_ERROR_FURTHER_ACTION初期化パラメータ, 5.9.2 SEC_PROTOCOL_ERROR_TRACE_ACTION初期化パラメータ, 5.9.1 sec_relevant_cols_optパラメータ, 7.3.4.3 SEC_RETURN_SERVER_RELEASE_BANNER初期化パラメータ, 5.9.4 SEC_USER_AUDIT_ACTION_BANNER初期化パラメータ, 5.9.5 SEC_USER_UNAUTHORIZED_ACCESS_BANNER初期化パラメータ, 5.9.5 secconf.sqlスクリプト

監査設定, 9.4.3

パスワード設定, 3.2.3.4

セキュア・アプリケーション・ロール

概要, 4.5.8

作成, 5.5.1

PL/SQLパッケージの作成, 5.5.2

DBA_ROLESビューを使用した検索, 4.13

実行者権限, 5.5.2

実行者権限の要件, 5.5.2

パッケージ, 5.5.2

SET ROLE文, 5.5.2

SYS_CONTEXT SQL関数からのユーザーの環境情報, 5.5.2, 5.5.2

データベース接続を保証するための使用, 4.5.8

安全性の高い外部パスワード・ストア

概要, 3.2.5.1

クライアント構成, 3.2.5.3

例, 3.2.5.2

機能, 3.2.5.2

プロキシ認証、使用, 3.10.1.5

Secure Sockets Layer(SSL)

概要, 3.6.1

証明書の鍵のアルゴリズム, 10.9.3

暗号スイート, 10.9.3

構成ファイル、保護, 10.9.3

SYSDBAまたはSYSOPERアクセスの構成, 3.3.1.3

プライベート・スキーマを持つグローバル・ユーザー, 3.7.1.1

セキュリティに関するガイドライン, 10.9.3, 10.9.3

リスナー、管理, 10.9.2

モード, 10.9.3

パスフレーズ, 10.9.3

RSA秘密鍵, 10.9.3

SSL接続の保護, 10.9.3

server.keyファイル, 10.9.3

TCPS, 10.9.3

バージョンのサポート, Preface

セキュリティ

アプリケーションを使用して規定, 4.5.1.2

デフォルトのユーザー・アカウント

自動的にロックして期限切れにする, 10.3

ロックして期限切れにする, 10.3

ドメイン、使用可能なロール, 4.5.5.1 アプリケーション内の規定, 5.2.2 データベース内の規定, 5.2.2 ロール名に含まれているマルチバイト・キャラクタ, 4.5.3 ロールのパスワードに含まれているマルチバイト・キャラクタ, 4.5.4.1 パスワード, 3.4.1 ポリシー

アプリケーション, 5.1

SQL*Plusユーザー、制限, 4.5.7

表またはビュー, 7.1.2.1

プロシージャによる強化, 4.6.6.3 リソース、その他, 1.2 ロール、アプリケーションに使用する利点, 5.4 「セキュリティ・リスク」も参照 セキュリティ・アラート, 10.2.1 セキュリティ攻撃

プロトコル・エラー後のサーバーへのアクセス、防止, 5.9.2

アプリケーション・コンテキスト値、変更の試み, 6.3.2

攻撃を防ぐために設計されたアプリケーション, 5.3

コマンドラインのリコール攻撃, 5.3.1.1, 5.3.1.4

サービス拒否, 10.9.2

サービス拒否

不正なパケット、対処, 5.9.1

リスナーを介したサービス拒否攻撃, 10.9.2 ディスクあふれ、防止, 5.9.1 傍受, 10.9.1 暗号化、解決しない問題, 8.1.2 偽造されたIPアドレス, 10.9.1 偽造または盗用されたクライアント・システムID, 10.9.1 ハッキングされたオペレーティング・システムまたはアプリケーション, 10.9.1 侵入者, 8.1.2 監査対象の非SYSアクティビティ, 9.1.4 パスワードのクラッキング, 3.2.1 パスワード保護, 3.2.1 クライアントからの悪意のある攻撃の防止, 5.9 プロキシ認証と安全性の高い外部パスワード・ストアによるパスワードの盗難防止, 3.10.1.5 セッションID、暗号化の必要性, 6.4.5.3 ショルダー・サーフィン, 5.3.1.4 SQLインジェクション攻撃, 5.3.1.2 無制限の認証リクエスト、防止, 5.9.3 ユーザー・セッションの出力、侵入者から隠す, 6.3.4 「セキュリティ・リスク」も参照 セキュリティ・ドメイン

使用可能にするロール, 4.5.1.1

セキュリティ・パッチ

概要, 10.2.1

ダウンロード, 10.2.1

セキュリティ・ポリシー

「Oracle Virtual Private Database、ポリシー」を参照

セキュリティ上のリスク

非定型ツール, 4.5.7.1, 4.5.7.1

データベース・ユーザーではないアプリケーション・ユーザー, 5.2.1

データベース内ではなくアプリケーション内で規定, 5.2.2

改ざんされている監査レコード, 9.3.5.1

サーバーへの不正なパケット, 5.9.1

データベース監査証跡、保護, 9.1.3

データベース・バージョンの表示, 5.9.4

暗号化鍵、ユーザーによる管理, 8.2.4.3

パスワード・ファイル, 3.3.3

大規模なデプロイメントで露出するパスワード, 3.2.5.1

パスワード、プログラムまたはスクリプトでの露出, 5.3.1.4

SQLスクリプトの位置パラメータ, 5.3.1.4

軽率に付与された権限, 4.4.5

PUBLICロールに付与された権限, 4.4.5

別のユーザーになりすますリモート・ユーザー, 4.5.4.3.2

監査証跡内の機密性の高いデータ, 10.10.1

識別情報を偽造するサーバー, 10.9.3

複数のロールを持つユーザー, 5.6.1

「セキュリティ攻撃」も参照

セキュリティ設定スクリプト

監査設定

secconf.sql, 9.4.3

パスワード設定

secconf.sql, 3.2.3.4

undoaud.sql, 9.4.3 undopwd.sql, 3.2.3.4 SELECT ANY DICTIONARY権限

データ・ディクショナリ、アクセス, 10.6

GRANT ALL PRIVILEGES権限から除外, 10.6

Virtual Private Databaseポリシー内のSELECT FOR UPDATE文, 7.5.2 SELECT権限

許可されるSQL文, 5.8.2

SELECT_CATALOG_ROLEロール

概要, 4.5.2

SYSスキーマ・オブジェクト、アクセスの許可, 4.4.2.2

業務分離の概念, 用語集 順序

監査, 9.3.10.2

server.keyファイル

読取りおよび解析するパスフレーズ, 10.9.3

サービス指向アーキテクチャ(SOA)

Oracle XML DBに対するセキュリティの強化, はじめに

SESSION_ROLESデータ・ディクショナリ・ビュー

PUBLICロール, 4.4.5

SESSION_ROLESビュー

PL/SQLブロックからの問合せ, 4.5.1.5.1

セッション

権限ドメインのリスト, 4.13.4

メモリー使用、表示, 2.6.5

時間制限, 2.4.2.5

監査オプションが有効になる時点, 9.3.1.3

SET ROLE文

アプリケーション・コード、挿入, 5.6.2

権限とロールの関連付け, 5.6.1

ロールの無効化, 4.11.1

ロールの有効化, 4.11.1

セキュア・アプリケーション・ロール, 5.5.2

オペレーティング・システム・ロールを使用した場合, 4.10.5

SGA

システム・グローバル領域(SGA)を参照

SHA-1ハッシュ・アルゴリズム

概要, 3.2.4

排他モードを使用可能にする, 3.2.4

パスワードの安全性の向上, 3.2.4

Oracleによる推奨, 3.2.4

共有グローバル領域(SGA)

システム・グローバル領域(SGA)を参照

共有サーバー

プライベートSQL領域の制限, 2.4.2.5

オペレーティング・システムによるロール管理の制限, 4.10.6

ショルダー・サーフィン, 5.3.1.4 SHOW PARAMETERコマンド, 9.3.2.1 スマートカード

セキュリティに関するガイドライン, 10.5

SNMPAGENTロール

概要, 4.5.2

SOA

「サービス指向アーキテクチャ」を参照

SPATIAL_CSW_ADMINロール, 4.5.2 SPATIAL_WFS_ADMINロール, 4.5.2 SQLインジェクション攻撃, 5.3.1.2 SQL文

デフォルト監査が使用可能な場合の監査, 9.4.2

監査

概要, 9.3.7.1

構成, 9.3.7.3

削除, 9.3.7.4

レコードが生成される場合, 9.3.1.3

動的, 6.3.3.3 アプリケーションで許可するオブジェクト権限, 5.8.2 必要な権限, 4.6.3, 5.8.2 リソース制限, 2.4.2.2 非定型の使用を制限, 4.5.7.1, 4.5.7.1 SQL*Net

「Oracle Net」を参照

SQL*Plus

接続, 3.5

非定型の使用を制限, 4.5.7.1, 4.5.7.1

統計モニター, 2.4.3

SQLNET.ALLOWED_LOGON_VERSIONパラメータ

SEC_CASE_SENSITIVE_LOGON FALSE設定と競合, 3.2.3.11

SSL

Secure Sockets Layerを参照

標準監査証跡

常に記録されるアクティビティ, 9.1.5

AUDIT SQL文, 9.3.6.1

標準監査証跡の監査, 9.8.2.4

サイズの制御, 9.8.2.2

使用禁止, 9.3.2.1

使用可能化, 9.3.2.1

最大サイズ, 9.8.2.2

NOAUDIT SQL文, 9.3.6.7

レコード、削除, 9.8.3.4

サイズ、削減, 9.9.5

トランザクションに依存しない, 9.3.1.3

作成される場合, 9.3.1.3

標準監査

概要, 9.3.1.1

すべてのプラットフォームの管理ユーザー, 9.6.2

エディションによる影響, 9.3.10.3

監査証跡のアーカイブ, 9.8.2.5

監査オプション・レベル, 9.3.6.1

監査証跡

データベース, 9.8.2.1

監査

デフォルト監査、使用可能, 9.4.1

カーソル、監査に与える影響, 9.3.6.4 データベース監査証跡レコード, 9.8.2.1 DDL文の監査, 9.3.7.2 デフォルトのオプション, 9.3.10.5 デフォルトのオプション、使用禁止, 9.3.10.6 ディレクトリ・オブジェクト監査

概要, 9.3.11.1

構成, 9.3.11.2

削除, 9.3.11.3

オプションの使用禁止と監査機能の使用禁止, 9.3.6.7 DML文, 9.3.7.2 オペレーティング・システム・ファイルに格納される情報, 9.3.4.1 必須監査, 9.1.5 ネットワーク監査

概要, 9.3.13.1

構成, 9.3.13.2

記録されるエラーのタイプ, 9.3.13.1

削除, 9.3.13.3

監査対象の非SYSアクティビティ, 9.1.4 オブジェクト監査

標準監査、スキーマ・オブジェクトを参照

オペレーティング・システム監査証跡, 9.3.4.1

ファイルの位置, 9.3.4.5

オペレーティング・システム監査証跡の使用, 9.3.4.3 権限監査

概要, 9.3.8.1

構成, 9.3.8.3

複数層環境, 9.3.9

オプション, 9.3.8.3

削除, 9.3.8.4

タイプ, 9.3.8.2

必要な権限, 9.3.1.2 プロシージャまたはファンクション, 9.3.10.5 対象範囲, 9.3.6 レコード

アーカイブ, 9.8.2.5

削除, 9.3.6.7 スキーマ・オブジェクト

将来作成されるオブジェクト, 9.3.10.7

スキーマ・オブジェクトの監査

概要, 9.3.10.1

使用可能化, 9.3.10.5

例, 9.3.10.5

オプション, 9.3.10.4

削除, 9.3.10.6

タイプ, 9.3.10.2

SQL文

標準監査、文監査を参照

文監査

概要, 9.3.7.1

個々のユーザーのすべての文, 9.3.7.3

現行セッションのすべての文, 9.3.7.3

構成, 9.3.7.3

複数層環境, 9.3.9

削除, 9.3.7.4

個別のユーザーによるSQL文ショートカット, 9.3.7.3

文レベル, 9.3.7.3

監査できるタイプ, 9.3.7.2

文の実行、数, 9.3.6.3 正常または異常終了, 9.3.6.2

設定, 9.3.6.2

SYSユーザー, 9.6.2, 9.6.2 UNIXシステムでのsyslog監査証跡, 9.3.5 ユーザー, 9.3.6.6 「監査、標準監査証跡、SYS.AUD$表」も参照 DBMS_RLS.ADD_POLICYプロシージャのstatement_typesパラメータ, 7.3.3 STMT_AUDIT_OPTION_MAP表, 9.3.3 記憶域

割当て制限, 2.2.5

無制限の割当て, 2.2.5.2

ストアド・プロシージャ

PUBLICに付与された権限の使用, 4.9

厳密認証

複数のデータベースへのSYSDBAおよびSYSOPERのアクセスの集中管理, 3.3.1

ガイドライン, 10.5

シンボリック・リンク

制限, 10.6

シノニム

オブジェクト権限, 4.6.3.3

権限、ガイドライン, 10.3

SYSアカウント

パスワードの変更, 2.3.4

ポリシーの規定, 7.5.7.2

SYSとSYSTEM

パスワード, 10.5, 10.5

SYSスキーマ

オブジェクト, アクセス, 4.4.2.2

SYS_CONTEXT関数

概要, 6.3.3.1

現行セッションの監査, 9.3.7.3

非データベース・ユーザーの監査, 9.5.11.3

データベース・リンク, 6.3.3.5

動的SQL文, 6.3.3.3

例, 6.3.3.6

パラレル問合せ, 6.3.3.4

STATICポリシー, 7.3.6.5

構文, 6.3.3.2, 6.3.3.2

ユーザーの検証, 5.5.2

SYS_DEFAULT Oracle Virtual Private Databaseポリシー・グループ, 7.3.5.3 SYSASM権限, はじめに SYS.AUD$表

概要, 9.8.2.1

アーカイブ, 9.8.2.5

監査レコード、書込み, 9.3.2.2

内容, 9.8.2.1

監査対象の文のデータ値, 9.8.2.1

Oracle Database Vault環境での場所, 9.1.3

手動での変更、危険性, 9.7

監査対象の非SYSアクション, 9.1.4

削除, 9.8.2.5

いっぱいになるか使用できなくなった場合, 9.8.2.1

「標準監査」も参照

SYSAUX表領域

データベース監査証跡表の移動先, 9.8.2.3

SYS.FGA_LOG$

ファイングレイン監査, 9.5.5

SYS.FGA_LOG$表

概要, 9.8.2.1

アーカイブ, 9.8.2.5

内容, 9.8.2.1

監査対象の文のデータ値, 9.8.2.1

監査対象の非SYSアクション, 9.1.4

削除, 9.8.2.5

いっぱいになるか使用できなくなった場合, 9.8.2.1

SYS.FGA_LOGS$表

「ファイングレイン監査」も参照

syslog監査証跡

概要, 9.3.5.1

表示形式, 9.3.5.3

構成, 9.3.5.4

形式, 9.3.5.2

AUDIT_TRAILがXMLに設定されている場合の形式, 9.3.2.2

書き込まれる必須監査レコード, 9.1.5

SYSMANユーザー・アカウント, 10.5, 10.5 SYS権限による接続, 10.3 システム・グローバル領域(SGA)

アプリケーション・コンテキスト、格納, 6.1.3

グローバル・アプリケーション・コンテキスト情報の場所, 6.4.1

プライベートSQL領域の制限, 2.4.2.5

システム権限, 10.3

概要, 4.4.1

ADMIN OPTION, 4.4.4

ANY

セキュリティに関するガイドライン, 10.6

ANYシステム権限, 4.4.2 GRANT ANY OBJECT PRIVILEGE, 4.7.2.2, 4.8.2.1 GRANT ANY PRIVILEGE, 4.4.4 付与, 4.7.1 付与と取消し, 4.4.3 効力, 4.4.1 制限の必要性, 4.4.2 取消し、連鎖的な影響, 4.8.3.1 SELECT ANY DICTIONARY, 10.6 SYSASM権限, はじめに SYSTEM_PRIVILEGE_MAP表, 9.3.3

T

表

監査, 9.3.10.2

権限, 4.6.4

表領域

ユーザーに対するデフォルトの割当て, 2.2.4

デフォルトの割当て制限, 2.2.5

ユーザーに対する割当て制限, 2.2.5

割当て制限、表示, 2.6.3

一時

ユーザーに対する割当て, 2.2.6

無制限の割当て, 2.2.5.2 TCPSプロトコル

Secure Sockets Layer、使用, 10.9.2

tnsnames.oraファイル、使用, 10.9.3

TELNETサービス, 10.9.2 TFTPサービス, 10.9.2 文実行の時間測定, 7.3.6.2 トークン・カード, 10.5 トップレベルSQL文, 9.2.3 トレース・ファイル

アクセス、制限の重要性, 10.6

不正なパケット, 5.9.1

位置、検索, 6.6

透過的データ暗号化, 8.2.4.4 透過的表領域暗号化, 8.2.4.4 トリガー

監査データ、記録, 9.7

監査, 9.3.10.4, 9.3.12.1, 9.3.12.2

CREATE TRIGGER ON, 5.8.2

ログイン

例, 6.3.4

外部で初期化されたアプリケーション・コンテキスト, 6.3.4

実行権限, 4.6.6.3

ロール, 4.5.1.5

WHEN OTHERS例外, 6.3.4 トラブルシューティング

トレース・ファイルの確認によるエラーの検索, 6.6

トラステッド・プロシージャ

データベース・セッション・ベースのアプリケーション・コンテキスト, 6.1.2

tsnames.ora構成ファイル, 10.9.3 例

アプリケーション・コンテキスト、データベース・セッション・ベース, 6.3.5.1

監査

非データベース・ユーザーを監査するポリシーの作成, 9.5.11.1

電子メール・アラートを使用するポリシーの作成, 9.5.10.1

外部ネットワーク・サービス、電子メール・アラートの使用, 9.5.10.1 クライアント・セッションIDを使用するグローバル・アプリケーション・コンテキスト, 6.4.6.1 非データベース・ユーザー

Oracle Virtual Private Databaseポリシー・グループの作成, 7.4.3.1

グローバル・アプリケーション・コンテキスト, 6.4.6.1

Oracle Virtual Private Database

ポリシー・グループ, 7.4.3.1

ポリシーの実装, 7.4.2.1

単純な例, 7.4.1.1

「例」も参照 型

作成, 4.6.7.5

権限, 4.6.7

ユーザー定義

作成要件, 4.6.7.4

U

UDPおよびTCPポート

使用禁止の全サービスに対して閉じる, 10.9.2

UGA

「ユーザー・グローバル領域(UGA)」を参照

Ultra Search

非推奨となったロールとスキーマ, はじめに

undoaud.sqlスクリプト, 9.4.3 undopwd.sqlスクリプト, 3.2.3.4 UNIXシステム

syslogに書き込まれる監査データ, 9.1.5

UNIXシステム、ユーザーの監査, 9.3.5 UNLIMITED TABLESPACE権限, 2.2.5.2, 2.2.5.2 UPDATE権限

取消し, 4.8.2.2

ユーザー・アカウント

管理用ユーザーのパスワード, 10.5

デフォルト・ユーザー・アカウント, 10.5

パスワードのガイドライン, 10.5

パスワード、暗号化, 10.5, 10.5

プロキシ・ユーザー, 3.10.1.3

USER関数

グローバル・アプリケーション・コンテキスト, 6.4.4.3

ユーザー・グローバル領域(UGA)

アプリケーション・コンテキスト、格納, 6.1.3

ユーザー名

スキーマ, 5.7

USER疑似列, 4.6.5.3 ユーザー・セッション、単一のデータベース接続内に複数, 3.10.1.6 ユーザー定義の列

監査, 9.5.3

USERENV関数, 6.3.3.2, 8.3 USERENVネームスペース

概要, 6.3.3.2

クライアント識別子, 3.10.2.1

「CLIENT_IDENTIFIER USERENV属性」も参照

ユーザー

管理オプション(ADMIN OPTION), 4.7.1.1

変更, 2.3.2

データベースに認識されないアプリケーション・ユーザー, 3.10.2.1

割当て制限のない割当て, 2.2.5.2

監査, 9.3.6.6

データベース・ロール、現在, 5.6.1

デフォルト・ロール、変更, 2.2.8

デフォルト表領域, 2.2.4

削除, 2.5, 2.5

プロファイルの削除, 2.4.4.2

ロールの削除, 4.5.6

ロールを使用可能にする, 5.6

エンタープライズ, 3.7, 4.5.4.4

エンタープライズ、共有スキーマによる保護, 5.7.2

外部認証

概要, 3.8.1

利点, 3.8.2

プロファイルの割当て, 2.4.4.1

オペレーティング・システム, 3.8.4

ユーザーの作成, 3.8.3

情報の検索, 2.6.1 認証に関する情報の検索, 3.11 グローバル, 3.7

プロファイルの割当て, 2.4.4.1

ホスト、複数への接続

「外部ネットワーク・サービス, ファイングレイン・アクセス」を参照

情報、表示, 2.6.2 付与されているロールのリスト, 4.13.2 メモリー使用、表示, 2.6.5 ネットワーク認証、外部, 3.8.5 非データベース, 6.4.1, 6.4.4.6 削除後のオブジェクト, 2.5 オペレーティング・システム外部認証, 3.8.4 パスワード暗号化, 3.2.1 権限

パスワードの変更, 2.3.1

作成, 2.2.1

権限付与, リスト, 4.13.1

現在のデータベース・ロール, 5.6.1

プロファイル

作成, 2.4.4.1

指定, 2.2.7

プロキシ認証, 3.10.1.1 プロキシ・ユーザー、接続, 3.10.1.1 PUBLICロール, 4.5.1.4, 4.9 表領域の割当て制限, 2.2.5.1 アプリケーション・ロールの制限, 4.5.7 ロール, 4.5.1.2

ユーザーのタイプ, 4.5.1.3.2

スキーマに依存しない, 5.7.2 スキーマ、プライベート, 3.7.1.1 セキュリティ・ドメイン, 4.5.1.4 セキュリティ、概要, 2.1 表領域割当て制限, 2.2.5 表領域割当て制限、表示, 2.6.3 ユーザー・アカウント、作成, 2.2.1 ユーザー・モデルとOracle Virtual Private Database, 7.5.9 ユーザー名、CREATE USER文での指定, 2.2.2 情報の検索に使用できるビュー, 2.6 UTLPWDMG.SQL

概要, 3.2.3.10

セキュリティに関するガイドライン, 10.5

V

V$LOGMNR_CONTENTSデータ・ディクショナリ・ビュー, 9.8.2.1

有効ノード・チェック, 10.9.2

ビュー

概要, 4.6.5.1

アクセス制御リストのデータ

外部ネットワーク・サービス, 4.12.12

ウォレット・アクセス, 4.12.12

アプリケーション・コンテキスト, 6.6 監査証跡, 9.10.1, 9.10.1 監査, 9.3.10.2, 9.3.10.4 認証, 3.11 DBA_COL_PRIVS, 4.13.3 DBA_NETWORK_ACL_PRIVILEGES, 4.12.10, 4.12.12 DBA_NETWORK_ACLS, 4.12.12 DBA_ROLE_PRIVS, 4.13.2 DBA_ROLES, 4.13.5 DBA_SYS_PRIVS, 4.13.1 DBA_TAB_PRIVS, 4.13.3 DBA_USERS_WITH_DEFPWD, 3.2.3.2 DBA_WALLET_ACLS, 4.12.12 データの暗号化, 8.5 Oracle Virtual Private Databaseポリシー, 7.6 権限, 4.6.5.1, 4.13 プロファイル, 2.6.1 ROLE_ROLE_PRIVS, 4.13.6 ROLE_SYS_PRIVS, 4.13.6 ROLE_TAB_PRIVS, 4.13.6 ロール, 4.13 セキュリティ・アプリケーション, 4.6.5.3 SESSION_PRIVS, 4.13.4 SESSION_ROLES, 4.13.4 USER_NETWORK_ACL_PRIVILEGES, 4.12.12 ユーザー, 2.6.1 仮想プライベート・データベース

「Oracle Virtual Private Database」を参照

VPD

「Oracle Virtual Private Database」を参照

無防備なランタイム・コール, 10.3

安全性の改善, 10.3

W

ウォレット・マネージャ

「Oracle Wallet Manager」を参照

ウォレット

認証方式, 3.6.2

「アクセス制御リスト(ACL)」、「ウォレット・アクセス」も参照、

Webアプリケーション

ユーザー接続, 6.4.1, 6.4.4.6

Webサービス

Oracle XML DBに対するセキュリティの強化, はじめに

Webベースのアプリケーション

Oracle Virtual Private Database、仕組み, 7.5.9

WFS_USR_ROLEロール, 4.5.2 WHEN OTHERS例外

ログイン・トリガー、使用, 6.3.4

WHERE句、動的SQL, 7.2.1 Windows固有の認証, 3.3.2 WKUSERロール, Preface WM_ADMIN_ROLEロール, 4.5.2

X

X.509証明書

セキュリティに関するガイドライン, 10.5

XDB_SET_INVOKERロール, 4.5.2 XDB_WEBSERVICESロール, 4.5.2 XDB_WEBSERVICES_OVER_HTTPロール

概要, 4.5.2

XDB_WEBSERVICES_WITH_PUBLICロール, 4.5.2 XDBADMINロール, 4.5.2 XML

AUDIT_TRAIL XML設定, 9.3.2.2

AUDIT_TRAIL XML, EXTENDED設定, 9.3.2.2

XML, EXTENDED AUDIT_TRAIL設定

AUDIT_TRAILでのDBの使用, 9.3.2.2

AUDIT_TRAILでのXMLの使用, 9.3.2.2

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。