Oracle® Database

セキュリティ・ガイド

12cリリース1 (12.1)

B71285-10(原本部品番号:E48135-19)

2017年6月

Oracle Databaseセキュリティ・ガイド, 12cリリース1 (12.1)

B71285-10

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

原本著者: Patricia Huey

原本協力著者: Sumit Jeloka

原本協力者: Suraj Adhikari、Tammy Bednar、Todd Bottger、Leo Cloutier、Naveen Gopal、Peter Knaggs、Andre Kruklikov、Bryn Llewellyn、Rahil Mir、Gopal Mulagund、Paul Needham、Robert Pang、Dilip Raj、Kathy Rich、Vipin Samar、Sachin Sonawane、Saravana Soundararajan、James Spiller、Srividya Tata、Kamal Tbeileh

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

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

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

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 Security 12cリリース1 (12.1.0.2)の変更

- 新機能

- 12Cパスワード・バージョンのSHA-2サポート

- SHA-2暗号ハッシュ関数のサポート

- コード・ベース・アクセス制御ユーザー・ロールの付与に対するADMINおよびDELEGATEオプションの使用

- 読取り専用データベースでの監査証跡クリーン・アップのサポート

- 事前定義の新しい統合監査ポリシー

- 統合監査セッションIDを取得するUSERENVネームスペースのUNIFIED_AUDIT_SESSIONIDパラメータ

- SELECT操作に対する新しいREADオブジェクト権限およびREAD ANY TABLEシステム権限

- FIPS認定の暗号化モジュール

- AES256アルゴリズムの使用目的でOracleウォレットを変換するための新しいorapkiコマンド

- Oracle Database Security 12cリリース1 (12.1.0.1)の変更

- 新機能

- データのカテゴリを保護する透過的機密データ保護

- 新しいパスワード検証関数

- ロールをプログラム・ユニットに付加する機能

- プロシージャのコール側の権限を使用できるかどうかを制御する機能

- 参照されるビューの実行者権限の動作に対応する機能

- 外部プロシージャのセキュリティの強化

- SHA-2暗号ハッシュ関数のサポート

- Kerberosの機能強化

- さらなる業務分離の権限の変更

- RESOURCEロールはUNLIMITED TABLESPACE権限を付与しなくなりました

- SELECT ANY DICTIONARY権限は一部のSYSデータ・ディクショナリ表にアクセスしなくなりました

- Oracle Virtual Private Database状況依存ポリシーの評価の制御

- 仮想プライベート・データベースのDBMS_RLSパッケージおよびビューの長い識別子のサポート

- サービスおよびウォレットへのファイングレイン・アクセスの構成の変更

- 監査機能の大幅な再設計

- 高速な監査パフォーマンス

- 統合監査データ証跡

- 統合監査証跡の新しいスキーマ

- 監査管理の業務分離

- 名前付きの統合監査ポリシーを作成する機能

- ロールを監査する機能

- 監査アクションの強制的な記録

- Oracle ACFS監査およびOracle Audit Vault Serverに監査データをインポートするためのサポート

- Oracleマルチテナント・オプション用のユーザー、権限およびロールのサポート

- 自動ストレージ管理のパスワード・ファイルを使用する機能

- 新しいSecure Sockets Layer暗号スイート

- 非推奨機能

- SQLNET.ALLOWED_LOGON_VERSIONパラメータの非推奨

- ORAPWDユーティリティのIGNORECASE引数の非推奨

- SEC_CASE_SENSITIVE_LOGON初期化パラメータの非推奨

- 非推奨のDBMS_NETWORK_ACL_ADMINパッケージ・プロシージャおよびビュー

- DELETE_CATALOG_ROLEロールの非推奨

- サポート対象外となった機能

- サポート対象外となったSecure Sockets Layer暗号スイート

- その他の変更

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

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

- その他のOracle Databaseセキュリティ・リソース

第I部 ユーザー認証および認可の管理

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

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

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

- 共通ユーザーおよびローカル・ユーザーについて

- 共通ユーザーについて

- PDBへの接続による共通ユーザーへの影響

- ローカル・ユーザーについて

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

- 最小限のデータベース権限を持つ新しいユーザー・アカウントの作成

- 新しいアカウントのユーザー名の作成に関する制限事項

- ユーザー名の一意性

- マルチテナント環境のユーザー名

- ユーザー名の大/小文字の区別

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

- ユーザーのデフォルト表領域

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

- デフォルト表領域を割り当てるためのDEFAULT TABLESPACE句

- ユーザーへの表領域の割当て制限

- ユーザーへの表領域の割当て制限の割当てについて

- 表領域の割当て制限を割り当てるためのCREATE USER文

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

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

- ユーザーの一時表領域

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

- 一時表領域を割り当てるためのTEMPORARY TABLESPACE句

- ユーザーのプロファイル

- 共通ユーザーまたはローカル・ユーザーの作成

- 共通ユーザー・アカウントの作成について

- 共通ユーザー・アカウントを作成するためのCREATE USER文

- ローカル・ユーザー・アカウントの作成について

- ローカル・ユーザー・アカウントを作成するためのCREATE USER文

- ユーザーのデフォルト・ロールの作成

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

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

- 共通またはローカル・ユーザー・アカウントを変更するためのALTER USER文

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

- SYS以外のユーザーのパスワードの変更について

- PASSWORDコマンドまたはALTER USER文を使用したパスワードの変更

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

- SYSユーザーのパスワードの変更について

- SYSユーザーのパスワードを変更するためのORAPWDユーティリティ

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

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

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

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

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

- CPU時間の制限

- 論理読取りの制限

- その他のリソースの制限

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

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

- プロファイルについて

- プロファイルの作成

- ユーザーへのプロファイルの割当て

- プロファイルの削除

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

- ユーザー・アカウントの削除について

- ユーザー・セッションの終了

- ユーザーがデータベースから切断した後のユーザーの削除について

- スキーマにオブジェクトが含まれるユーザーの削除

- データベース・ユーザーおよびプロファイルのデータ・ディクショナリ・ビュー

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

- すべてのユーザーと関連情報を検索する問合せ

- すべての表領域の割当て制限を表示する問合せ

- すべてのプロファイルと割り当てられている制限を表示する問合せ

- 各ユーザー・セッションのメモリー使用量を表示する問合せ

3 認証の構成

- 認証の概要

- パスワード保護の構成

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

- パスワードの最低要件

- IDENTIFIED BY句を使用したパスワードの作成

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

- パスワード管理の概要

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

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

- ALTER PROFILE文を使用したプロファイル制限の設定

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

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

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

- ユーザー・アカウントの明示的ロック

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

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

- CREATE PROFILE文またはALTER PROFILE文を使用したパスワード存続期間の設定

- ユーザー・アカウントのステータスの確認

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

- PASSWORD_LIFE_TIMEプロファイル・パラメータの低い値

- パスワードの複雑度の管理

- パスワードの複雑度検証の概要

- Oracle Databaseによるパスワードの複雑度のチェック方法

- パスワード複雑度ファンクションを使用できるユーザー

- verify_function_11G関数のパスワード要件

- ora12c_verify_functionのパスワード要件

- ora12c_strong_verify_function関数のパスワード要件

- パスワード複雑度検証のカスタマイズについて

- パスワード複雑度検証の有効化

- パスワードでの大/小文字の区別の管理

- SEC_CASE_SENSITIVE_LOGONパラメータおよびパスワードの大/小文字の区別

- ALTER SYSTEM文を使用したパスワードの大/小文字の区別の有効化

- 安全性の高いロール・パスワードの大/小文字の区別の管理

- ユーザーのパスワード・バージョンの管理

- 10Gパスワード・バージョンを使用するユーザーのパスワードの確認と再設定

- 大/小文字の区別がパスワード・ファイルに与える影響

- 大/小文字の区別がデータベース・リンク接続で使用されるパスワードに与える影響

- パスワードのセキュリティへの脅威からの12Cパスワード・バージョンによる保護

- 12Cバージョンのパスワード・ハッシュについて

- Oracle Database 12Cパスワード・バージョン構成のガイドライン

- 12Cパスワード・バージョンを排他的に使用するためのOracle Databaseの構成

- 12Cパスワード・バージョンを排他的に使用するためのOracle Databaseクライアントの構成

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

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

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

- 外部パスワード・ストアの使用を目的とするクライアントの構成について

- 外部パスワード・ストアの使用を目的とするクライアントの構成

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

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

- 外部パスワード・ストアの内容のリスト表示

- 外部パスワード・ストアへの資格証明の追加

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

- 外部パスワード・ストアからの資格証明の削除

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

- データベース管理者の認証について

- 管理者の厳密認証と集中管理

- データベース管理者の厳密認証について

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

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

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

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

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

- データベース管理者認証のパスワード・ファイルを使用するリスク

- ユーザーのデータベース認証

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

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

- データベースで認証されるユーザーの作成

- ユーザーのオペレーティング・システム認証

- ユーザーのネットワーク認証

- Secure Sockets Layerを使用した認証

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

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

- Kerberosを使用した認証

- RADIUSを使用した認証

- ディレクトリベース・サービスを使用した認証

- 公開鍵インフラストラクチャを使用した認証

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

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

- ディレクトリ・サービスで認可されるユーザーの構成

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

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

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

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

- 外部認証の概要

- 外部認証の利点

- 外部認証の有効化

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

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

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

- 複数層の認証と認可

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

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

- プロキシ認証に対する中間層サーバーの使用

- プロキシ認証の概要

- プロキシ認証の利点

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

- プロキシ・ユーザー・アカウントの作成のガイドライン

- プロキシ・ユーザー・アカウントと、そのアカウントを介して接続するユーザーの認可

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

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

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

- 中間層の権限の制限

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

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

- 中間層を介したデータベースへのユーザーの再認証

- パスワード・ベースのプロキシ認証の使用

- エンタープライズ・ユーザーでのプロキシ認証の使用

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

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

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

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

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

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

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

- システム全体でのCLIENTID_OVERWRITEイベントの有効化

- 現在のセッションに対するCLIENTID_OVERWRITEイベントの有効化

- CLIENTID_OVERWRITEイベントの無効化

- ユーザー認証のデータ・ディクショナリ・ビュー

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

- 権限とロールの概要

- 権限付与の対象者

- Oracleマルチテナント・オプションが権限に影響を与えるしくみ

- 管理権限の管理

- 管理権限について

- ユーザーへの管理権限の付与

- 通常のデータベース操作のためのSYSDBAおよびSYSOPER管理権限

- バックアップおよびリカバリ操作のSYSBACKUP管理権限

- Oracle Data Guard操作のSYSDG管理権限

- 透過的データ暗号化のSYSKM管理権限

- システム権限の管理

- システム権限の概要

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

- システム権限の制限の重要性について

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

- SYSスキーマのオブジェクトへのユーザー・アクセス

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

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

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

- 共通およびローカルに付与される権限の管理

- 共通およびローカルに付与される権限について

- 共通に付与されるシステム権限の使用方法

- 共通に付与されるオブジェクト権限の使用方法

- PDBへのアクセス権限の付与または取消し

- 例: マルチテナント環境での権限の付与

- 共通ユーザーによるCONTAINER_DATAオブジェクトの情報の表示

- ルートに接続中のルート、CDBおよびPDBに関するデータの表示

- 特定のPDBのデータを問い合せる共通ユーザーの有効化

- 共通ロールおよびローカル・ロールの管理

- 共通ロールおよびローカル・ロールの管理について

- 共通ロールの使用方法

- マルチテナント環境でPUBLICロールが機能するしくみ

- 共通ロールの作成、変更または削除に必要な権限

- 共通ロールの作成の規則

- 共通ロールの作成

- ローカル・ロールの作成の規則

- ローカル・ロールの作成

- 共通ユーザーとローカル・ユーザーに対するロールの付与と取消し

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

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

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

- ロールの機能

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

- ロールの通常の使用

- アプリケーション・ロールの一般的な使用方法

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

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

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

- 定義者権限を持つ名前付きブロックで使用されるロール

- 実行者権限を持つ名前付きブロックおよび無名PL/SQLブロックで使用されるロール

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

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

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

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

- ロールの作成

- ロールの作成について

- パスワードを使用して認証されるロールの作成

- パスワード認証のないロールの作成

- 外部またはグローバルのロールの作成

- ロールの変更

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

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

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

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

- オペレーティング・システムを使用したロールの認可

- ネットワーク・クライアントを使用したロールの認可

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

- ロールの付与と取消し

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

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

- プログラム・ユニットに対するロールの付与と取消し

- ロールの削除

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

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

- PRODUCT_USER_PROFILEシステム表がロールを制限できるしくみ

- ストアド・プロシージャがビジネス・ロジックをカプセル化できるしくみ

- ロール権限およびセキュア・アプリケーション・ロール

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

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

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

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

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

- ALL句がすべての使用可能なオブジェクト権限を付与または取り消すしくみ

- READオブジェクト権限とSELECTオブジェクト権限

- READおよびSELECTオブジェクト権限の管理について

- データベース内の任意の表を問い合せるためのREADオブジェクト権限の使用のユーザーへの許可

- READおよびREAD ANY TABLE権限に対する制限

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

- 表権限

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

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

- 表示権限

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

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

- プロシージャ権限

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

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

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

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

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

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

- 例: 1つのパッケージ内で使用されるプロシージャ権限

- 例: プロシージャ権限およびパッケージ・オブジェクト

- タイプ権限

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

- 名前付きの型のオブジェクト権限

- 名前付きの型のメソッド実行モデル

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

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

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

- 型の依存性

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

- ユーザーおよびロールへのシステム権限とロールの付与

- ユーザーおよびロールへのシステム権限とロールの付与のための権限

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

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

- 権限受領ユーザーによる権限付与を可能にするADMINオプションの使用

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

- ユーザーおよびロールへのオブジェクト権限の付与

- ユーザーおよびロールへのオブジェクト権限の付与について

- WITH GRANT OPTION句が機能するしくみ

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

- 列に対する権限の付与

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

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

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

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

- オブジェクト権限の取消しについて

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- SET ROLEおよびデフォルト・ロールの設定による権限の付与と取消しの機能

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

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

- ユーザーのデフォルト・ロールの指定

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

- ユーザー権限およびロールのデータ・ディクショナリ・ビュー

- 権限およびロール付与の情報を確認するデータ・ディクショナリ・ビュー

- すべてのシステム権限の付与を表示する問合せ

- すべてのロール付与を表示する問合せ

- ユーザーに付与されているオブジェクト権限を表示する問合せ

- セッションの現在の権限ドメインを表示する問合せ

- データベースのロールを表示する問合せ

- ロールの権限ドメイン情報を表示する問合せ

5 定義者権限および実行者権限のセキュリティの管理

- 定義者権限および実行者権限について

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

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

- 実行者権限プロシージャを作成する場合

- プロシージャ・コールおよびビュー・アクセスの実行者権限の制御

- スキーマの権限が実行者権限プロシージャの使用に与える影響

- INHERIT [ANY] PRIVILEGES権限による権限アクセスの制御方法

- 他のユーザーへのINHERIT PRIVILEGES権限の付与

- 例: 実行するユーザーへのINHERIT PRIVILEGESの付与

- 例: INHERIT PRIVILEGESの取消し

- 他のユーザーへのINHERIT ANY PRIVILEGES権限の付与

- 例: 信頼できるプロシージャ所有者へのINHERIT ANY PRIVILEGESの付与

- INHERIT PRIVILEGESおよびINHERIT ANY PRIVILEGESの管理

- ビューの定義者権限および実行者権限

- ビューの定義者権限および実行者権限の制御について

- CREATE VIEW文のBEQUEATH句の使用

- 実行するユーザーのユーザー名またはユーザーIDの確認

- BEQUEATH DEFINERおよびBEQUEATH_CURRENT_USERビューの確認

- 定義者権限および実行者権限のコード・ベース・アクセス制御の使用

- アプリケーションのコード・ベース・アクセス制御の使用について

- コード・ベースのアクセス制御ロールをプログラム・ユニットに付与できる者

- コード・ベース・アクセス制御による実行者権限のプログラム・ユニットの処理方法

- コード・ベース・アクセス制御による定義者権限のプログラム・ユニットの処理方法

- CBAC付与のためのユーザーへのデータベース・ロールの付与

- プログラム・ユニットに対するデータベース・ロールの付与と取消し

- チュートリアル: コード・ベース・アクセス制御による機密データへのアクセス制御

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

- ステップ1: ユーザーを作成してHRにCREATE ROLE権限を付与

- ステップ2: print_employees実行者権限プロシージャを作成

- ステップ3: hr_clerkロールを作成して権限を付与

- ステップ4: コード・ベース・アクセス制御HR.print_employeesプロシージャのテスト

- ステップ5: view_emp_roleロールを作成して権限を付与

- ステップ6: HR.print_employeesプロシージャの再テスト

- 手順7: このチュートリアルのコンポーネントの削除

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

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

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

- Oracleウォレットへのアクセス制御について

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

- 外部ネットワーク・サービスのアクセス制御の構成

- 外部ネットワーク・サービスのアクセス制御の構成の構文

- 例: 外部ネットワーク・サービスのアクセス制御の構成

- 外部ネットワーク・サービスのアクセス制御権限の取消し

- 例: 外部ネットワーク・サービス権限の取消し

- Oracleウォレットへのアクセス制御の構成

- Oracleウォレットへのアクセス制御の構成について

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

- 手順2: Oracleウォレットのアクセス制御権限の構成

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

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

- 他のアプリケーションとセッションを共有している場合に、リクエスト・コンテキストを使用してウォレットを保留

- 認証にクライアント証明書のみを使用

- 認証にパスワードを使用

- Oracleウォレットのアクセス制御権限の取消し

- 外部ネットワーク・サービスのアクセス制御の構成の例

- 例: 1つのロールおよびネットワーク接続のアクセス制御の構成

- 例: ユーザーおよびロールのアクセス制御の構成

- 例: DBA_HOST_ACESビューを使用した付与権限の表示

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

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

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

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

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

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

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

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

- 例: 管理者によるユーザー・ネットワーク・アクセス制御権限のチェック

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

- 例: ユーザーによるネットワーク・アクセス制御権限のチェック

- Javaデバッグ・ワイヤ・プロトコル操作のネットワーク・アクセスの構成

- ユーザー・アクセス用に構成されたアクセス制御リストのデータ・ディクショナリ・ビュー

7 Enterprise Managerによるマルチテナント環境のセキュリティの管理

- Enterprise Managerによるマルチテナント環境のセキュリティの管理について

- Enterprise Managerによるマルチテナント環境へのログイン

- CDBまたはPDBへのログイン

- 別のPDBへの、またはルートへの切替え

- Enterprise Managerの共通ユーザーおよびローカル・ユーザーの管理

- Enterprise Managerの共通ユーザー・アカウントの作成

- Enterprise Managerの共通ユーザー・アカウントの編集

- Enterprise Managerの共通ユーザー・アカウントの削除

- Enterprise Managerのローカル・ユーザー・アカウントの作成

- Enterprise Managerのローカル・ユーザー・アカウントの編集

- Enterprise Managerのローカル・ユーザー・アカウントの削除

- Enterprise Managerの共通およびローカル・ロールおよび権限の管理

- Enterprise Managerの共通ロールの作成

- Enterprise Managerの共通ロールの編集

- Enterprise Managerの共通ロールの削除

- Enterprise Managerの共通権限付与の取消し

- Enterprise Managerのローカル・ロールの作成

- Enterprise Managerのローカル・ロールの編集

- Enterprise Managerのローカル・ロールの削除

- Enterprise Managerのローカル権限付与の取消し

第II部 アプリケーション開発のセキュリティ

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

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

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

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

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

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

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

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

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

- パスワードの形式と動作の構成のガイドライン

- SQLスクリプトにおけるパスワードの処理のガイドライン

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

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

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

- 外部プロシージャの保護

- 外部プロシージャの保護について

- 資格証明の認証に対するextprocの構成に関する一般プロセス

- extprocプロセス認証および偽装設定の予期される動作

- 外部プロシージャの認証の構成

- レガシー・アプリケーションの外部プロシージャ

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

- アプリケーション権限の管理にロールを使用する利点

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

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

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

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

- アプリケーションに対するアクセス・ポリシーを定義するPL/SQLパッケージまたはプロシージャの作成

- セキュア・アプリケーション・ロールのテスト

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

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

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

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

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

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

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

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

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

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

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

- 不正パケット受信後のサーバー実行の制御

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

- データベース・バージョン・バナーの表示構成

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

第III部 データへのアクセス制御

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 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の管理の概要

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

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

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

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

- クライアント識別子の値のチェック

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

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

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

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

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

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

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

- 手順5: セッションIDの変更とグローバル・アプリケーション・コンテキストの再テスト

- 手順6: このチュートリアルのコンポーネントの削除

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

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

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

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

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

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

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

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

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

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

- アプリケーション・コンテキストのデータ・ディクショナリ・ビュー

10 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でのアプリケーション・コンテキストの使用

- マルチテナント環境でのOracle Virtual Private Database

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

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

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

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

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

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

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

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

- 例: DBMS_RLS.ADD_POLICYを使用したSQL文の指定

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

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

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

- 問合せに関連する列の行のみの表示

- 機密性の高い列をNULL値で表示するための列のマスク

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

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

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

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

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

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

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

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

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

- ポリシー関数を自動再実行するための動的ポリシー・タイプ

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

- ポリシー関数の問合せごとの再実行を回避するための静的ポリシー

- 例: DBMS_RLS.ADD_POLICYを使用した静的ポリシーの作成

- 例: 複数オブジェクト間でポリシーを共有するための共有の静的ポリシー

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

- 変更されるアプリケーション・コンテキスト属性の状況依存ポリシー

- 例: DBMS_RLS.ADD_POLICYを使用した状況依存ポリシーの作成

- 例: VPD状況依存ポリシーのキャッシュされた文のリフレッシュ

- 例: 既存の状況依存ポリシーの変更

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

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

- 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: ログオン・トリガーのテスト

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

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

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

- 手順9: このチュートリアルのコンポーネントの削除

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

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

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

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

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

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

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

- 手順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のデータ・ディクショナリ・ビュー

11 透過的機密データ保護の使用

- 透過的機密データ保護について

- 透過的機密データ保護を使用する一般的な手順

- 透過的機密データ保護ポリシーのユースケース

- 透過的機密データ保護の使用に必要な権限

- マルチテナント環境が透過的機密データ保護に影響を与えるしくみ

- 透過的機密データ保護ポリシーの作成

- 手順1: 機密タイプの作成

- 手順2: 保護する機密列の識別

- 手順3: ADMからデータベースへの機密列リストのインポート

- 手順4: 透過的機密データ保護ポリシーの作成

- 透過的機密データ保護ポリシーの作成について

- 透過的機密データ保護ポリシーの作成

- Oracle Data Redactionまたは仮想プライベート・データベース機能オプションの設定

- 透過的機密データ保護ポリシーの条件の設定

- DBMS_TSDP_PROTECT.ADD_POLICYプロシージャの指定

- 手順5: ポリシーと機密タイプの関連付け

- 手順6: 透過的機密データ保護ポリシーの有効化

- 保護されたソースの現在のデータベースの保護の有効化

- 特定の表の列の保護の有効化

- 特定の列タイプの保護の有効化

- 手順7: 他のデータベースへのポリシーのエクスポート(オプション)

- 透過的機密データ保護ポリシーの変更

- 透過的機密データ保護ポリシーの無効化

- 透過的機密データ保護ポリシーの削除

- 事前定義のREDACT_AUDITポリシーを使用したバインド値のマスク

- REDACT_AUDITポリシーについて

- 機密列に関連付けられている変数

- 条件式のバインド変数および機密列

- 同じSELECT項目に表示されるバインド変数および機密列

- INSERTまたはUPDATE操作の機密列に割り当てられる式のバインド変数

- ビューでの機密列のバインド変数の動作

- REDACT_AUDITポリシーの無効化

- REDACT_AUDITポリシーの有効化

- データ・リダクションでの透過的機密データ保護ポリシー

- Oracle VPDポリシーでの透過的機密データ保護ポリシーの使用

- TSDPポリシーとOracle Virtual Private Databaseポリシーの併用について

- TSDPポリシーに使用されるDBMS_RLS.ADD_POLICYパラメータ

- チュートリアル: 仮想プライベート・データベース保護を使用するTSDPポリシーの作成

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

- 手順2: 機密列の識別

- 手順3: Oracle Virtual Private Database関数の作成

- 手順4: 透過的機密データ保護ポリシーの作成および有効化

- 手順5: 透過的機密データ保護ポリシーのテスト

- 手順6: このチュートリアルのコンポーネントの削除

- 透過的機密データ保護のデータ・ディクショナリ・ビュー

12 手動によるデータ暗号化

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

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

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

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

- データ暗号化の課題

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

- 生成された暗号化鍵

- 転送された暗号化鍵

- 暗号化鍵の格納

- 暗号化鍵の格納について

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

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

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

- 透過的データベース暗号化および表領域暗号化を使用した手動暗号化

- 暗号化鍵の変更の重要性

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

- DBMS_CRYPTOパッケージを使用したデータ暗号化ストレージ

- OFBモードで暗号化された暗号文のOracle Databaseリリース11gでの使用

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

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

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

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

- 暗号化データのデータ・ディクショナリ・ビュー

第IV部 ネットワーク上のデータの保護

13 Oracle Databaseのネットワーク暗号化とデータ整合性の構成

- Oracle Databaseのネットワーク暗号化とデータ整合性について

- Oracleデータ・ネットワークの暗号化および整合性について

- Advanced Encryption Standard

- Oracle Databaseのネットワーク暗号化のデータ整合性

- データの整合性アルゴリズムのサポート

- Diffie-Hellmanベースの鍵交換

- データの暗号化および整合性の構成

- 暗号化および整合性のアクティブ化について

- 暗号化および整合性のネゴシエーションについて

- 暗号化および整合性のネゴシエーションの値について

- REJECTED構成パラメータ

- ACCEPTED構成パラメータ

- REQUESTED構成パラメータ

- REQUIRED構成パラメータ

- Oracle Net Managerを使用した暗号化および整合性パラメータの構成

- クライアントとサーバーでの暗号化の構成

- クライアントとサーバーでの整合性の構成

14 シンJDBCクライアント・ネットワークの構成

- Java実装について

- Java Database Connectivityのサポート

- シンJDBCの機能

- 実装の概要

- Java暗号化コードの不明瞭化

- シンJDBCネットワーク実装の構成パラメータ

- シンJDBCネットワーク実装の構成パラメータについて

- クライアント暗号化レベルのパラメータ

- クライアント暗号化選択リストのパラメータ

- クライアント整合性レベルのパラメータ

- クライアント整合性選択リストのパラメータ

- クライアント認証サービスのパラメータ

- AnoServices定数

第V部 厳密認証の管理

15 厳密認証の概要

- 厳密認証とは

- 集中化された認証とシングル・サインオン

- 集中化されたネットワーク認証の動作

- サポートされている厳密認証方式

- Kerberosについて

- Remote Authentication Dial-In User Service (RADIUS)について

- Secure Sockets Layerについて

- Oracle Databaseネットワークの暗号化/厳密認証アーキテクチャ

- 厳密認証のシステム要件

- Oracleネットワーク暗号化および厳密認証の制限事項

16 厳密認証の管理ツール

- 構成ツールと管理ツールについて

- ネットワーク暗号化ツールと厳密認証構成ツール

- バージョン情報

- Kerberosアダプタ・コマンドライン・ユーティリティ

- 公開鍵インフラストラクチャ資格証明管理ツール

- Oracle Wallet Managerについて

- orapkiユーティリティについて

- 厳密認証管理者の義務

17 Kerberos認証の構成

- Kerberos認証の有効化

- 手順1: Kerberosのインストール

- 手順2: Oracleデータベース・サーバーに対するサービス・プリンシパルの構成

- 手順3: Kerberosからのサービス・キー表の抽出

- 手順4: Oracleデータベース・サーバーとOracleクライアントのインストール

- 手順5: Oracle Net ServicesとOracle Databaseの構成

- 手順6: Kerberos認証の構成

- 手順6A: クライアントとデータベース・サーバーでのKerberosの構成

- 手順6B: 初期化パラメータの設定

- 手順6C: sqlnet.oraパラメータの設定(オプション)

- 手順7: Kerberosユーザーの作成

- 手順8: 外部認証されたOracleユーザーの作成

- 手順9: Kerberos/Oracleユーザーの初期チケットの取得

- Kerberos認証アダプタのユーティリティ

- 初期チケットを取得するためのokinitユーティリティ・オプション

- 資格証明を表示するためのoklistユーティリティ・オプション

- キャッシュ・ファイルからの資格証明の削除

- Kerberosによって認証されたOracle Databaseサーバーへの接続

- Windows 2008ドメイン・コントローラKDCとの相互運用性の構成

- 手順1: Windows 2008ドメイン・コントローラのためのOracle Kerberosクライアントの構成

- 手順1A: クライアントKerberos構成ファイルの作成

- 手順1B: sqlnet.oraファイルでのOracle構成パラメータの指定

- 手順1C: リスニング・ポート番号の指定

- 手順2: OracleクライアントのためのWindows 2008ドメイン・コントローラKDCの構成

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

- 手順2B: Oracleデータベースのプリンシパル・ユーザー・アカウントの作成

- 手順3: Windows 2008ドメイン・コントローラKDCのためのOracleデータベースの構成

- 手順3A: sqlnet.oraファイルでの構成パラメータの設定

- 手順3B: 外部認証されたOracleユーザーの作成

- 手順4: Kerberos/Oracleユーザーの初期チケットの取得

- Kerberos認証フォールバック動作の構成

- Oracle Kerberos認証の構成のトラブルシューティング

18 Secure Sockets Layer認証の構成

- Secure Sockets LayerおよびTransport Layer Security

- Oracle DatabaseでのSecure Sockets Layerを使用した認証

- Oracle環境におけるSecure Sockets Layerの機能: SSLハンドシェイク

- Oracle環境における公開鍵インフラストラクチャ

- 公開鍵の暗号化について

- Oracle環境における公開鍵インフラストラクチャ・コンポーネント

- 認証局

- 証明書

- 証明書失効リスト

- ウォレット

- ハードウェア・セキュリティ・モジュール

- Secure Sockets Layerと他の認証方式の併用

- アーキテクチャ: Oracle DatabaseとSecure Sockets Layer

- Secure Sockets Layerと他の認証方式の併用

- Secure Sockets Layerとファイアウォール

- Secure Sockets Layer使用時の問題

- Secure Sockets Layerの有効化

- 手順1: サーバーでのSecure Sockets Layerの構成

- 手順1A: サーバーでのウォレット作成の確認

- 手順1B: サーバーでのデータベース・ウォレット・ロケーションの指定

- 手順1C: サーバーでのSecure Sockets Layer暗号スイートの設定(オプション)

- Secure Sockets Layer暗号スイートについて

- SSL暗号スイートの認証、暗号化、整合性およびTLSバージョン

- データベース・サーバーのSecure Sockets暗号スイートの指定

- 手順1D: サーバーでの必要なSecure Sockets Layerバージョンの設定(オプション)

- 手順1E: サーバーでのSSLクライアント認証の設定(オプション)

- 手順1F: サーバーでの認証サービスとしてのSSLの設定(オプション)

- 手順1G: SSL付きTCP/IPを使用するリスニング・エンドポイントのサーバーでの作成

- 手順2: クライアントでのSecure Sockets Layerの構成

- 手順2A: クライアント・ウォレット作成の確認

- 手順2B: サーバーDNの構成とクライアントのSSL付きTCP/IPの使用

- サーバーDNSの構成およびクライアントでのSSL付きTCP/IPの使用について

- サーバーDNSの構成およびクライアントでのSSL付きTCP/IPの使用

- 手順2C: 必要なクライアントSSL構成の指定(ウォレット・ロケーション)

- 手順2D: クライアントのSecure Sockets Layer暗号スイートの設定(オプション)

- クライアントのSecure Sockets Layer暗号スイートの設定について

- クライアントのSecure Sockets Layer暗号スイートの設定

- 手順2E: 必要なSSLバージョンのクライアントでの設定(オプション)

- 手順2F: クライアントにおける認証サービスとしてのSSLの設定(オプション)

- SQLNET.AUTHENTICATION_SERVICESパラメータについて

- SQLNET.AUTHENTICATION_SERVICESパラメータの設定

- 手順2G: クライアントでの認証に使用する証明書の指定(オプション)

- SQLNET.SSL_EXTENDED_KEY_USAGEパラメータについて

- SQLNET.SSL_EXTENDED_KEY_USAGEパラメータの設定

- 手順3: データベース・インスタンスへのログイン

- Secure Sockets Layer構成のトラブルシューティング

- 証明書失効リストによる証明書の検証

- 証明書失効リストによる証明書検証について

- 使用するCRLの選択方法

- CRLチェックの動作の仕組み

- 証明書失効リストによる証明書検証の構成

- 証明書失効リストによる証明書検証の構成について

- クライアントまたはサーバー用の証明書失効ステータス・チェックの有効化

- 証明書失効ステータス・チェックの無効化

- 証明書失効リストの管理

- 証明書失効リストの管理について

- CRLを管理するコマンドのorapkiヘルプの表示

- 証明書検証用ハッシュ値によるCRLの名前変更

- Oracle Internet DirectoryへのCRLのアップロード

- Oracle Internet Directoryに格納されているCRLの一覧表示

- Oracle Internet DirectoryでのCRLの表示

- Oracle Internet DirectoryからのCRLの削除

- CRL証明書検証のトラブルシューティング

- 証明書検証に関連するOracle Netトレース・ファイルのエラー・メッセージ

- ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成

- SSLでハードウェア・セキュリティ・モジュールを使用するための一般的なガイドライン

- nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成

- nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について

- nCipherハードウェア・セキュリティ・モジュールに必要なOracleコンポーネント

- nCipherハードウェア・セキュリティ・モジュールをインストールするためのディレクトリ・パス要件

- SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成

- SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について

- SafeNET Luna SAハードウェア・セキュリティ・モジュールに必要なOracleコンポーネント

- SafeNETハードウェア・セキュリティ・モジュールをインストールするためのディレクトリ・パス要件

- ハードウェア・セキュリティ・モジュールの使用時のトラブルシューティング

- Oracle Netトレース・ファイルのエラー

- ハードウェア・セキュリティ・モジュールの使用に関連するエラー・メッセージ

19 RADIUS認証の構成

- RADIUS認証の構成について

- RADIUSの構成要素

- RADIUS認証モード

- 同期認証モード

- 同期認証モードの順序

- 例: SecurIDトークン・カードによる同期認証

- チャレンジ・レスポンス(非同期)認証モード

- チャレンジ・レスポンス(非同期)認証モードの順序

- 例: スマートカードによる非同期認証

- 例: ActivCardトークンによる非同期認証

- RADIUS認証、認可およびアカウンティングの有効化

- 手順1: RADIUS認証の構成

- 手順1A: OracleクライアントでのRADIUSの構成

- 手順1B: Oracleデータベース・サーバーでのRADIUSの構成

- 手順1B(1): Oracleデータベース・サーバーでのRADIUS秘密鍵ファイルの作成

- 手順1B(2): サーバー(sqlnet.oraファイル)でのRADIUSパラメータの構成

- 手順1B(3): Oracleデータベース・サーバー初期化パラメータの設定

- 手順1C: その他のRADIUS機能の構成

- 手順1C(1): デフォルト設定の変更

- 手順1C(2): チャレンジ・レスポンス・モードの構成

- 手順1C(3): 代替RADIUSサーバーのパラメータの設定

- 手順2: ユーザーの作成とアクセス権の付与

- 手順3: 外部RADIUS認可の構成(オプション)

- 手順3A:Oracle Server (RADIUSクライアント)の構成

- 手順3B: Oracleクライアント(ユーザーがログインする場所)の構成

- 手順3C: RADIUSサーバーの構成

- 手順4: RADIUSアカウンティングの構成

- 手順4A: Oracleデータベース・サーバーでのRADIUSアカウンティングの設定

- Step 4B: RADIUSアカウンティング・サーバーの構成

- 手順5: RADIUSクライアント名のRADIUSサーバー・データベースへの追加

- 手順6: RADIUSとともに使用する認証サーバーの構成

- 手順7: 認証サーバーとともに使用するRADIUSサーバーの構成

- 手順8: マッピング・ロールの構成

- RADIUSを使用したデータベースへのログイン

- RSA ACE/Server構成チェックリスト

20 厳密認証の使用のカスタマイズ

- 厳密認証を使用したデータベースへの接続

- 厳密認証およびネットワーク暗号化の無効化

- 複数の認証方式の構成

- 外部認証のためのOracle Databaseの構成

- sqlnet.oraでのSQLNET.AUTHENTICATION_SERVICESパラメータの設定

- OS_AUTHENT_PREFIXのNull値への設定

第VI部 監査を使用したデータベース・アクティビティの管理

21 監査の概要

- 監査とは

- 監査を使用する理由

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

- 統合監査とは

- 統合監査証跡の利点

- データベースが統合監査に移行したかどうかの確認

- 混合モードの監査

- 混合モードの監査について

- 有効にした監査のタイプがデータベースの作成でどのように決定されるか

- 混合モードの監査の機能

- 監査の実行者

- マルチテナント環境での監査

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

22 監査ポリシーの構成

- 監査タイプの選択

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

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

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

- 統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査

- 統合監査ポリシーおよびAUDITを使用したアクティビティの監査について

- 統合監査ポリシーの作成のベスト・プラクティス

- 統合監査ポリシーの作成の構文

- ロールの監査

- ロールの監査について

- ロールの統合監査ポリシーの構成

- 例: マルチテナント環境でのDBAロールの監査

- システム権限の監査

- システム権限監査について

- 監査できるシステム権限

- 監査できないシステム権限

- システム権限の使用を取得するための統合監査ポリシーの構成

- 例: ANY権限を持つユーザーの監査

- 例: 条件を使用するシステム権限の監査

- 監査証跡でのシステム権限の統合監査ポリシーの表示方法

- 管理ユーザーの監査

- 監査可能な管理ユーザー・アカウント

- 管理者アクティビティを取得するための統合監査ポリシーの構成

- 例: SYSユーザーの監査

- オブジェクト・アクションの監査

- オブジェクト・アクションの監査について

- 監査できるオブジェクト・アクション

- オブジェクト・アクションの統合監査ポリシーの構成

- 例: SYSオブジェクトでのアクションの監査

- 例: 1つのオブジェクトでの複数のアクションの監査

- 例: オブジェクトでのアクションと権限の両方の監査

- 例: 表でのすべてのアクションの監査

- 例: データベースでのすべてのアクションの監査

- 監査証跡でのオブジェクト・アクションの統合監査ポリシーの表示方法

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

- Oracle Virtual Private Databaseポリシー関数の監査ポリシー

- 統合監査とエディション付きオブジェクト

- SELECT、READ ANY TABLEまたはSELECT ANY TABLEの監査

- SELECT文およびREAD ANY TABLEシステム権限の監査について

- READオブジェクト権限操作を取得する統合監査ポリシーの作成

- 統合監査証跡でのREAD ANY TABLEおよびSELECT ANY TABLEの取得方法

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

- 統合監査ポリシーの条件の作成

- 統合監査ポリシーについて

- 条件を使用した統合監査ポリシーの構成

- 例: SQL*Plusへのアクセスの監査

- 例: 特定のホストにはないアクションの監査

- 例: システム全体のアクションおよびスキーマ固有のアクションの両方の監査

- 例: 文の発生ごとの条件の監査

- 例: 現在の管理ユーザー・セッションの統合監査セッションID

- 例: 現在の非管理ユーザー・セッションの統合監査セッションID

- 監査証跡での条件からの監査レコードの表示方法

- アプリケーション・コンテキスト値の監査

- アプリケーション・コンテキスト値の監査について

- アプリケーション・コンテキストの監査設定の構成

- アプリケーション・コンテキストの監査設定の無効化

- 例: デフォルト・データベースでのアプリケーション・コンテキスト値の監査

- 例: Oracle Label Securityのアプリケーション・コンテキスト値の監査

- 監査証跡での監査対象のアプリケーション・コンテキストの表示方法

- Oracle Database Real Application Securityイベントの監査

- Oracle Database Real Application Securityイベントの監査について

- Oracle Database Real Application Securityの監査可能なイベント

- Oracle Database Real Application Securityのユーザーおよびロールの監査イベント

- Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベント

- Oracle Database Real Application Securityのセッションの監査イベント

- Oracle Database Real Application SecurityのALLイベント

- Oracle Database Real Application Securityの統合監査ポリシーの構成

- 例: Real Application Securityのユーザー・アカウントの変更の監査

- 例: Real Application Securityの統合監査ポリシーでの条件の使用

- 監査証跡でのOracle Database Real Application Securityイベントの表示方法

- Oracle Recovery Managerイベントの監査

- Oracle Recovery Managerイベントの監査について

- Oracle Recovery Managerの統合監査証跡イベント

- 監査証跡でのOracle Recovery Managerの監査イベントの表示方法

- Oracle Database Vaultイベントの監査

- Oracle Database Vaultイベントの監査について

- Oracle Database Vaultの監査者

- Oracle Database Vaultの統合監査証跡イベントについて

- Oracle Database Vaultのレルムの監査イベント

- Oracle Database Vaultのルール・セットおよびルールの監査イベント

- Oracle Database Vaultのコマンド・ルールの監査イベント

- Oracle Database Vaultのファクタの監査イベント

- Oracle Database Vaultのセキュア・アプリケーション・ロールの監査イベント

- Oracle Database Vault Oracle Label Securityの監査イベント

- Oracle Database Vault Oracle Data Pumpの監査イベント

- Oracle Database Vaultの有効および無効な監査イベント

- Oracle Database Vaultの統合監査ポリシーの構成

- 例: 2つのOracle Database Vaultイベントの監査

- 例: Oracle Database Vaultのファクタの監査

- 監査証跡でのOracle Database Vaultの監査イベントの表示方法

- Oracle Label Securityイベントの監査

- Oracle Label Securityイベントの監査について

- Oracle Label Securityの統合監査証跡イベント

- Oracle Label Securityの監査可能なユーザー・セッション・ラベル

- Oracle Label Securityの統合監査ポリシーの構成

- 例: Oracle Label Securityのセッション・ラベル属性の監査

- 例: Oracle Label Securityポリシーからのユーザーの除外

- 例: Oracle Label Securityのポリシー・アクションの監査

- 例: 監査済のOLSセッション・ラベルの問合せ

- 監査証跡でのOracle Label Securityの監査イベントの表示方法

- Oracle Data Miningイベントの監査

- Oracle Data Miningイベントの監査について

- Oracle Data Miningの統合監査証跡イベント

- Oracle Data Miningの統合監査ポリシーの構成

- 例: ユーザーによる複数のOracle Data Mining操作の監査

- 例: ユーザーによる失敗したすべてのOracle Data Mining操作の監査

- 監査証跡でのOracle Data Miningイベントの表示方法

- Oracle Data Pumpイベントの監査

- Oracle Data Pumpイベントの監査について

- Oracle Data Pumpの統合監査証跡イベント

- Oracle Data Pumpの統合監査ポリシーの構成

- 例: Oracle Data Pumpのインポート操作の監査

- 例: Oracle Data Pumpのすべての操作の監査

- 監査証跡でのOracle Data Pumpの監査イベントの表示方法

- Oracle SQL*Loaderダイレクト・ロード・パス・イベントの監査

- Oracle SQL*Loaderダイレクト・パス・ロード・イベントの監査について

- Oracle SQL*Loaderダイレクト・ロード・パスの統合監査証跡イベント

- Oracle SQL*Loaderダイレクト・パス・イベントの統合監査証跡ポリシーの構成

- 例: Oracle SQL*Loaderダイレクト・パス・ロード操作の監査

- 監査証跡でのSQL*Loaderダイレクト・パス・ロードの監査イベントの表示方法

- マルチテナント環境での統合監査ポリシーまたはAUDIT設定の使用

- ローカルおよび共通監査ポリシーについて

- マルチテナント環境での従来の監査

- ローカル統合監査ポリシーまたは共通統合監査ポリシーの構成

- 例: ローカル統合監査ポリシー

- 例: CDB共通統合監査ポリシー

- 監査証跡でのローカルまたは共通監査ポリシーまたは設定の表示方法

- 統合監査ポリシーの変更

- 統合監査ポリシーの変更について

- 統合監査ポリシーの変更

- 例: 統合監査ポリシーの条件の変更

- 例: 統合監査ポリシーでのOracle Label Securityコンポーネントの変更

- 例: 統合監査ポリシーのロールの変更

- 例: 統合監査ポリシーからの条件の削除

- ユーザーに対する統合監査ポリシーの有効化

- 統合監査ポリシーの有効化について

- 統合監査ポリシーの有効化

- 例: 統合監査ポリシーの有効化

- 統合監査ポリシーの無効化

- 統合監査ポリシーの無効化について

- 統合監査ポリシーの無効化

- 例: 統合監査ポリシーの無効化

- 統合監査ポリシーの削除

- 統合監査ポリシーの削除について

- 統合監査ポリシーの削除

- 例: 統合監査ポリシーの無効化および削除

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

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

- 手順2: 統合監査ポリシーの作成

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

- 手順4: このチュートリアルのコンポーネントの削除

- 事前定義の統合監査ポリシーを使用したアクティビティの監査

- ログオン失敗の事前定義の統合監査ポリシー

- セキュア・オプションの事前定義の統合監査ポリシー

- Oracle Databaseパラメータ変更の事前定義の統合監査ポリシー

- ユーザー・アカウントおよび権限管理の事前定義の統合監査ポリシー

- Center for Internet Securityで推奨される事前定義の統合監査ポリシー

- Oracle Database Real Application Securityの事前定義の監査ポリシー

- システム管理者操作の事前定義の統合監査ポリシー

- セッション操作の事前定義の統合監査ポリシー

- Oracle Database Vaultの事前定義の統合監査ポリシー

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

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

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

- ファイングレイン監査の実行者

- Oracle VPDポリシーがある表またはビューでのファイングレイン監査

- マルチテナント環境でのファイングレイン監査

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

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

- DBMS_FGA PL/SQL PL/SQLパッケージについて

- DBMS_FGA PL/SQLパッケージとエディション

- マルチテナント環境でのDBMS_FGA PL/SQLパッケージ

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

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

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

- 特定の列および行の監査

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

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

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

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

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

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

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

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

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

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

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

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

- 手順7: このチュートリアルのコンポーネントの削除

- 監査ポリシーのデータ・ディクショナリ・ビュー

23 監査証跡の管理

- 統合監査証跡の管理

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

- 強制的に監査されるアクティビティ

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

- AUDSYSスキーマへの統合監査証跡レコードの書込み

- AUDSYSへの統合監査証跡レコードの書込みについて

- 統合監査証跡レコードでの書込みモードの設定

- キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ

- 現行データベース・インスタンスでのディスクへのレコードの書込み

- Oracle RAC環境間でのディスクへのレコードの書込み

- マルチテナント環境でのディスクへのレコードの書込み

- 統合監査証跡へのオペレーティング・システムの監査レコードの移動

- 統合監査の無効化

- 監査証跡のアーカイブ

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

- 統合監査証跡および従来のデータベースの監査証跡のアーカイブ

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

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

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

- スケジュールに基づいた監査証跡の定期的なパージ

- 指定時間での監査証跡の手動パージ

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

- 自動削除ジョブのスケジューリングについて

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

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

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

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

- 監査証跡の手動削除

- 監査証跡の手動削除について

- DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILを使用した監査証跡の手動パージ

- 他の監査証跡削除操作

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

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

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

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

- 例: 統合監査証跡の削除操作の直接コール

- 監査証跡管理のデータ・ディクショナリ・ビュー

付録

A Oracle Databaseの安全性の維持

- Oracle Databaseセキュリティ・ガイドラインについて

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

- セキュリティ・パッチと回避ソリューションのダウンロード

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

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

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

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

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

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

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

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

- クライアント接続のセキュリティ

- ネットワーク接続のセキュリティ

- Secure Sockets Layer接続のセキュリティ

- 外部プロシージャの保護に関するガイドライン

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

- 監査情報の管理の容易性

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

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

- 監査の推奨設定

- CONNECTロール変更への対処

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

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

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

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

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

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

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

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

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

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

- 新しいデータベース・ロールの作成

- CONNECT権限のリストア

- CONNECT権限受領者を表示するデータ・ディクショナリ・ビュー

- 最低限の権限の分析調査

B データ暗号化および整合性パラメータ

- データ暗号化と整合性のためのsqlnet.oraの使用について

- サンプルsqlnet.oraファイル

- データ暗号化および整合性パラメータ

- データ暗号化および整合性パラメータについて

- SQLNET.ENCRYPTION_SERVER

- SQLNET.ENCRYPTION_CLIENT

- SQLNET.CRYPTO_CHECKSUM_SERVER

- SQLNET.CRYPTO_CHECKSUM_CLIENT

- SQLNET.ENCRYPTION_TYPES_SERVER

- SQLNET.ENCRYPTION_TYPES_CLIENT

- SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER

- SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT

C Kerberos、SSLおよびRADIUS認証パラメータ

- Kerberos認証を使用するクライアントとサーバーのパラメータ

- Secure Sockets Layerを使用するクライアントとサーバーのパラメータ

- クライアントとサーバーのSecure Sockets Layer認証パラメータ

- Secure Sockets Layerの暗号スイート・パラメータ

- サポートされているSecure Sockets Layer暗号スイート

- Secure Sockets Layerバージョン・パラメータ

- Secure Sockets Layerクライアント認証パラメータ

- Secure Sockets Layer X.509サーバー照合パラメータ

- SSL_SERVER_DN_MATCH

- SSL_SERVER_CERT_DN

- Oracleウォレット・ロケーション

- RADIUS認証を使用するクライアントとサーバーのパラメータ

- sqlnet.oraファイルのパラメータ

- SQLNET.AUTHENTICATION_SERVICES

- SQLNET.RADIUS_AUTHENTICATION

- SQLNET.RADIUS_AUTHENTICATION_PORT

- SQLNET.RADIUS_AUTHENTICATION_TIMEOUT

- SQLNET.RADIUS_AUTHENTICATION_RETRIES

- SQLNET.RADIUS_SEND_ACCOUNTING

- SQLNET.RADIUS_SECRET

- SQLNET.RADIUS_ALTERNATE

- SQLNET.RADIUS_ALTERNATE_PORT

- SQLNET.RADIUS_ALTERNATE_TIMEOUT

- SQLNET.RADIUS_ALTERNATE_RETRIES

- SQLNET.RADIUS_CHALLENGE_RESPONSE

- SQLNET.RADIUS_CHALLENGE_KEYWORD

- SQLNET.RADIUS_AUTHENTICATION_INTERFACE

- SQLNET.RADIUS_CLASSPATH

- 最小限のRADIUSパラメータ

- RADIUSの初期化ファイル・パラメータ

D RADIUSを使用した認証デバイスの統合

- RADIUSチャレンジ・レスポンス・ユーザー・インタフェースについて

- RADIUSチャレンジ・レスポンス・ユーザー・インタフェースのカスタマイズ

- 例: OracleRadiusInterfaceインタフェースの使用

E Oracle Database FIPS 140-2の設定

- Oracle Database FIPS 140-2の設定について

- 透過的データ暗号化およびDBMS_CRYPTO用のFIPS 140-2の構成

- Secure Sockets Layerに対するFIPS 140-2の構成

- Secure Sockets LayerのSSLFIPS_140パラメータの構成

- FIPS 140-2用に承認されているSSL暗号スイート

- FIPS 140-2のインストール後のチェック

- FIPS 140-2接続の検証

F orapkiユーティリティを使用したPKI要素の管理

- orapkiユーティリティの使用

- orapkiユーティリティの構文

- テスト用の署名付き証明書の作成

- 証明書の表示

- orapkiユーティリティを使用したOracleウォレットの管理

- orapkiを使用したウォレットの管理について

- orapkiを使用したウォレットの作成、表示および変更

- PKCS#12ウォレットの作成

- 自動ログイン・ウォレットの作成

- PKCS#12ウォレットに関連付けられた自動ログイン・ウォレットの作成

- コンピュータとウォレット作成ユーザーにローカルな自動ログイン・ウォレットの作成

- ウォレットの表示

- ウォレットのパスワードの変更

- AES256アルゴリズムの使用を目的としたOracleウォレットの変換

- orapkiを使用した証明書と証明書リクエストのOracleウォレットへの追加

- 証明書リクエストのOracleウォレットへの追加

- 信頼できる証明書のOracleウォレットへの追加

- ルート証明書のOracleウォレットへの追加

- ユーザー証明書のOracleウォレットへの追加

- PKCS#11ウォレットを使用したハードウェア・デバイス上の資格証明の検証

- PKCS#11情報のOracleウォレットへの追加

- orapkiを使用した証明書と証明書リクエストのOracleウォレットからのエクスポート

- orapkiユーティリティを使用した証明書失効リスト(CRL)の管理

- orapkiの使用方法

- 例: 自己署名証明書を含むウォレットおよび証明書のエクスポート

- 例: ウォレットおよびユーザー証明書の作成

- orapkiユーティリティ・コマンドのサマリー

- orapki cert create

- orapki cert display

- orapki crl deleteコマンド

- orapki crl display

- orapki crl hash

- orapki crl list

- orapki crl upload

- orapki wallet add

- orapki wallet convert

- orapki wallet create

- orapki wallet display

- orapki wallet export

G 統合監査の移行による各監査機能への影響

用語集

索引

表一覧

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

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

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

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

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

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

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

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

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

- 4-6 権限およびロール情報を表示するデータ・ディクショナリ・ビュー

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

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

- 8-2 extprocプロセス認証および偽装設定の予期される動作

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

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

- 9-1 アプリケーション・コンテキストのタイプ

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

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

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

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

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

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

- 11-1 TSDPポリシーに使用されるDBMS_RLS.ADD_POLICYパラメータ

- 11-2 透過的機密データ保護ビュー

- 12-1 DBMS_CRYPTOパッケージ機能の概要

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

- 13-1 2つの形態のネットワーク攻撃

- 13-2 暗号化とデータ整合性のネゴシエーション

- 13-3 有効な暗号化アルゴリズム

- 13-4 有効な整合性アルゴリズム

- 14-1 CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_LEVELの属性

- 14-2 CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_TYPESの属性

- 14-3 CONNECTION_PROPERTY_THIN_NET_CHECKSUM_LEVELの属性

- 14-4 CONNECTION_PROPERTY_THIN_NET_CHECKSUM_TYPESの属性

- 14-5 CONNECTION_PROPERTY_THIN_NET_AUTHENTICATION_SERVICESの属性

- 15-1 認証方式とシステム要件

- 16-1 Kerberosアダプタ・コマンドライン・ユーティリティ

- 16-2 セキュリティ管理者/DBAの一般的な構成および管理タスク

- 17-1 Kerberos固有のsqlnet.oraパラメータ

- 17-2 okinitユーティリティのオプション

- 17-3 oklistユーティリティのオプション

- 18-1 Secure Sockets Layer暗号スイート

- 18-2 SSL_DH Secure Sockets Layer暗号スイート

- 19-1 RADIUS認証の構成要素

- 21-1 混合モード監査と完全な統合監査の違い

- 22-1 管理ユーザーおよび管理権限

- 22-2 オブジェクト・レベルの標準データベース・アクションの監査オプション

- 22-3 READ ANY TABLEおよびSELECT ANY TABLEに対する監査動作

- 22-4 Oracle Database Real Application Securityのユーザーおよびロールの監査イベント

- 22-5 Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベント

- 22-6 Oracle Database Real Application Securityのセッションの監査イベント

- 22-7 Oracle Database Real Application SecurityのALLイベント

- 22-8 UNIFIED_AUDIT_TRAILビューのOracle Recovery Manager列

- 22-9 Oracle Database Vaultのレルムの監査イベント

- 22-10 Oracle Database Vaultのルール・セットおよびルールの監査イベント

- 22-11 Oracle Database Vaultのコマンド・ルールの監査イベント

- 22-12 Oracle Database Vaultのファクタの監査イベント

- 22-13 Oracle Database Vaultのセキュア・アプリケーション・ロールの監査イベント

- 22-14 Oracle Database Vault Oracle Label Securityの監査イベント

- 22-15 Oracle Database Vault Oracle Data Pumpの監査イベント

- 22-16 Oracle Database Vaultの有効および無効な監査イベント

- 22-17 Oracle Label Securityの監査イベント

- 22-18 Oracle Data Miningの監査イベント

- 22-19 監査アクティビティに関する情報を表示するビュー

- 23-1 監査証跡の管理設定に関する情報を表示するビュー

- A-1 DBA_CONNECT_ROLE_GRANTEESの列と内容

- B-1 アルゴリズムのタイプの選択

- B-2 SQLNET.ENCRYPTION_SERVERパラメータの属性

- B-3 SQLNET.ENCRYPTION_CLIENTパラメータの属性

- B-4 SQLNET.CRYPTO_CHECKSUM_SERVERパラメータの属性

- B-5 SQLNET.CRYPTO_CHECKSUM_CLIENTパラメータの属性

- B-6 SQLNET.ENCRYPTION_TYPES_SERVERパラメータの属性

- B-7 SQLNET.ENCRYPTION_TYPES_CLIENTパラメータの属性

- B-8 SQLNET.CRYPTO_CHECKSUM_TYPES_SERVERパラメータの属性

- B-9 SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENTパラメータの属性

- C-1 Kerberos認証パラメータ

- C-2 クライアントとサーバーのSSL認証パラメータ

- C-3 Secure Sockets Layerの暗号スイート・パラメータ

- C-4 Secure Sockets Layerバージョン・パラメータ

- C-5 Secure Sockets Layerクライアント認証パラメータ

- C-6 SSL_SERVER_DN_MATCHパラメータ

- C-7 SSL_SERVER_CERT_DNパラメータ

- C-8 ウォレット・ロケーション・パラメータ

- C-9 SQLNET.AUTHENTICATION_SERVICESパラメータの属性

- C-10 SQLNET.RADIUS_AUTHENTICATIONパラメータの属性

- C-11 SQLNET.RADIUS_AUTHENTICATION_PORTパラメータの属性

- C-12 SQLNET.RADIUS_AUTHENTICATION_TIMEOUTパラメータの属性

- C-13 SQLNET.RADIUS_AUTHENTICATION_RETRIESパラメータの属性

- C-14 SQLNET.RADIUS_SEND_ACCOUNTINGパラメータの属性

- C-15 SQLNET.RADIUS_SECRETパラメータの属性

- C-16 SQLNET.RADIUS_ALTERNATEパラメータの属性

- C-17 SQLNET.RADIUS_ALTERNATE_PORTパラメータの属性

- C-18 SQLNET.RADIUS_ALTERNATE_TIMEOUTパラメータの属性

- C-19 SQLNET.RADIUS_ALTERNATE_RETRIESパラメータの属性

- C-20 SQLNET.RADIUS_CHALLENGE_RESPONSEパラメータの属性

- C-21 SQLNET.RADIUS_CHALLENGE_KEYWORDパラメータの属性

- C-22 SQLNET.RADIUS_AUTHENTICATION_INTERFACEパラメータの属性

- C-23 SQLNET.RADIUS_CLASSPATHパラメータの属性

- E-1 DBFIPS_140初期化パラメータのプラットフォームへの作用

- G-1 移行前後での統合監査機能の可用性

はじめに

『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のインストール時に作成できるシードPDBのサンプル・スキーマを使用しています。スキーマの作成方法および使用方法の詳細は、『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 Security 12cリリース1 (12.1.0.2)の変更

- Oracle Database Security 12cリリース1 (12.1.0.1)の変更

Oracle Database Security 12cリリース1 (12.1.0.2)の変更

Oracle Database 12cリリース1 (12.1.0.2)の『Oracle Databaseセキュリティ・ガイド』の変更は、次のとおりです。

- 新機能

新機能

このリリースの新機能は次のとおりです。

- 12Cパスワード・バージョンのSHA-2サポート

- SHA-2暗号ハッシュ関数のサポート

- コード・ベース・アクセス制御ユーザー・ロールの付与に対するADMINおよびDELEGATEオプションの使用

- 読取り専用データベースでの監査証跡クリーン・アップのサポート

- 事前定義の新しい統合監査ポリシー

- 統合監査セッションIDを取得するUSERENVネームスペースのUNIFIED_AUDIT_SESSIONIDパラメータ

- SELECT操作に対する新しいREADオブジェクト権限およびREAD ANY TABLEシステム権限

- FIPS認定の暗号化モジュール

- AES256アルゴリズムの使用目的でOracleウォレットを変換するための新しいorapkiコマンド

12Cパスワード・バージョンのSHA-2サポート

Oracle Database 12cリリース1 (12.1.0.2)は、SHA-512暗号ハッシュを使用して、12Cパスワード・バージョンを生成します。また、Oracle Call Interface (OCI)およびシンJDBCクライアントの両方で、認証用の12Cパスワード・バージョンがサポートされるようになりました。ネットワーク・チェックサムのSHA-256、SHA-384およびSHA-512ハッシュ関数を使用できます。SHA-256、SHA-384およびSHA-512ハッシュ・ダイジェストを計算するには、DBMS_CRYPTO PL/SQLパッケージを使用します。

内容は次のとおりです。

- パスワードのセキュリティへの脅威からの12Cパスワード・バージョンによる保護

- DBMS_CRYPTO PL/SQLパッケージのSHA-2サポートの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

SHA-2暗号ハッシュ関数のサポート

以前のリリースでは、Oracle DatabaseにほとんどのSHA-2暗号ハッシュ関数のサポートが含まれていました。

ネットワーク・チェックサム(SHA-256およびSHA-384関数)およびDBMS_CRYPTO PL/SQLパッケージ以外に、これらの関数を次の分野に使用できます。

- データベースのパスワード・ベースの認証に使用されるベリファイア(SHA-512関数)

- ネットワーク・チェックサム(SHA-256、SHA-384およびSHA-512関数)

- パスワード・ファイル(SHA-512関数)

「パスワードのセキュリティへの脅威からの12Cパスワード・バージョンによる保護」を参照してください。

コード・ベース・アクセス制御ユーザー・ロールの付与に対するADMINおよびDELEGATEオプションの使用

コード・ベース・アクセス制御のプログラム・ユニットへの付与を行うユーザーは、以前のリリースでの要件に加え、GRANT ANY ROLE権限を持つか、プログラム・ユニットに付与するロールに対してADMINまたはDELEGATEオプションを持つことが必要になりました。

この機能によって、これらのプログラム・ユニットが他のユーザーによって実行される場合、セキュリティのレイヤーが追加されます。

詳細は、「定義者権限および実行者権限のコード・ベース・アクセス制御の使用」を参照してください。

読取り専用データベースでの監査証跡クリーン・アップのサポート

以前のリリースでは、監査証跡クリーン・アップは読取り/書込みデータベースでのみ使用できました。このリリース以降、読取り専用データベースでも使用できます。この機能向上に対応するために、次の変更が行われました。

- DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMPおよびDBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILプロシージャが読取り/書込みおよび読取り専用の両方のデータベースに対して機能するようになりました。

- DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTYプロシージャも読取り/書込みおよび読取り専用の両方のデータベースに対して機能します。読取り専用データベースの場合、このプロシージャはSGAで値を直接設定します。また、読取り専用データベースの場合、構成パラメータCLEANUP_INTERVALおよびDB_DELETE_BATCH_SIZEを設定できません。

- DBMS_AUDIT_MGMT.GET_AUDIT_TRAIL_PROPERTY_VALUEファンクションが追加されました。このファンクションは、ユーザーによる構成パラメータのインメモリーの値の表示を可能にし、読取り/書込みおよび読取り専用の両方のデータベースに使用できます。

- 読取り専用データベースでタイムスタンプ構成を取得するDBMS_AUDIT.MGMT.GET_LAST_ARCHIVE_TIMESTAMPファンクションが追加されました。

- AUD$およびFGA_LOG$システム表を変更できないため、DBMS_AUDIT_MGMT.AUDIT_TRAIL_TYPEパラメータの次のパラメータは読取り専用データベースに適用されません。

- AUDIT_TRAIL_AUD_STD

- AUDIT_TRAIL_FGA_STD

- AUDIT_TRAIL_DB_STD

- AUDIT_TRAIL_ALL

- 読取り専用データベースの監査証跡の削除情報は、DBA_AUDIT_MGMT_CLEAN_EVENTSデータ・ディクショナリ・ビューではなく、データベース・インスタンスのアラート・ログに書き込まれます。

監査証跡クリーン・アップ機能の詳細は、「監査証跡レコードの削除」を参照してください。

事前定義の新しい統合監査ポリシー

このリリースでは、2つの事前定義の新しい統合監査ポリシーを利用できます。パラメータは次のとおりです。

- ORA_CIS_RECOMMENDATIONSは、Center for Internet Security (CIS)で推奨される監査を実行します。

- ORA_DV_AUDPOLは、Oracle Database VaultのDVSYSおよびDVFスキーマ・オブジェクトと、Oracle Label SecurityのLBACSYSスキーマ・オブジェクトに対して実行されるアクションを監査します。

詳細は、次の各項を参照してください。

- 「Center for Internet Securityで推奨される事前定義の統合監査ポリシー」

- 「Oracle Database Vaultの事前定義の統合監査ポリシー」

統合監査セッションIDを取得するUSERENVネームスペースのUNIFIED_AUDIT_SESSIONIDパラメータ

現在のユーザー・セッションの統合監査セッションIDを追跡する新しいUSERENVネームスペースのUNIFIED_AUDIT_SESSIONパラメータを使用できます。

このパラメータは混合モード監査用に設計されています。混合モード監査環境では、SESSIONIDパラメータがUNIFIED_AUDIT_SESSIONIDとは異なる値を返すためです。完全な統合監査では、これらの値は両方とも同じです。

条件付き統合監査ポリシーの作成の詳細は、「統合監査ポリシーの条件の作成」を参照してください。

SELECT操作に対する新しいREADオブジェクト権限およびREAD ANY TABLEシステム権限

READオブジェクト権限を使用して、ユーザーはデータベースの表、ビュー、マテリアライズド・ビューおよびシノニムの問合せを行えるようになりました。引き続きSELECTオブジェクト権限を使用できますが、SELECTオブジェクト権限では、ユーザーはオブジェクトの問合せ以外に次の操作を実行でき、表の行のロックが可能になることに注意してください。

- LOCK TABLE table_name IN EXCLUSIVE MODE;

- SELECT ... FROM table_name FOR UPDATE;

READオブジェクト権限では、これらの追加権限は提供されません。セキュリティの強化のためには、ユーザーの操作を問合せの実行のみに制限する場合、ユーザーにREADオブジェクト権限を付与します。

READオブジェクト権限以外に、READ ANY TABLE権限を付与してユーザーがデータベースの任意の表の問合せを行えるようにすることもできます。

READオブジェクト権限が付与されたユーザーが問合せを実行する場合、ユーザーは引き続きSELECT文を使用する必要があります。READオブジェクト権限に対応するREAD SQL文はありません。

GRANT ALL PRIVILEGES TO user SQL文にはREAD ANY TABLEシステム権限が含まれています。GRANT ALL PRIVILEGES ON object TO user文にはREADオブジェクト権限が含まれています。

詳細は、次の各項を参照してください。

- READオブジェクト権限とSELECTオブジェクト権限

- SELECT、READ ANY TABLEまたはSELECT ANY TABLEの監査

FIPS認定の暗号化モジュール

このリリースより、FIPS_140初期化パラメータをTRUEに設定して、透過的データ暗号化およびDBMS_CRYPTO PL/SQLパッケージ・プログラム・ユニットでFederal Information Processing Standard (FIPS) 140-2モードを有効にしたり、無効にできます。FALSEに設定した場合、Oracle Databaseをインストールしたプラットフォームに応じて異なる標準を使用してデータが保護されます。

詳細は、「Oracle Database FIPS 140の設定」を参照してください。

AES256アルゴリズムの使用目的でOracleウォレットを変換するための新しいorapkiコマンド

このリリース以降では、Oracleウォレット(キーストアとも呼ばれる)を3DESアルゴリズムからAES256アルゴリズム(3DESアルゴリズムよりも強力)に変換できます。

詳細は、「AES256アルゴリズムの使用を目的としたOracleウォレットの変換」を参照してください。

Oracle Database Security 12cリリース1 (12.1.0.1)の変更

Oracle Database 12cリリース1 (12.1.0.1)の『Oracle Databaseセキュリティ・ガイド』の変更は、次のとおりです。

- 新機能

- 非推奨機能

- サポート対象外となった機能

- その他の変更

新機能

このリリースの新機能は次のとおりです。

- データのカテゴリを保護する透過的機密データ保護

- 新しいパスワード検証関数

- ロールをプログラム・ユニットに付加する機能

- プロシージャのコール側の権限を使用できるかどうかを制御する機能

- 参照されるビューの実行者権限の動作に対応する機能

- 外部プロシージャのセキュリティの強化

- SHA-2暗号ハッシュ関数のサポート

- Kerberosの機能強化

- さらなる業務分離の権限の変更

- RESOURCEロールはUNLIMITED TABLESPACE権限を付与しなくなりました

- SELECT ANY DICTIONARY権限は一部のSYSデータ・ディクショナリ表にアクセスしなくなりました

- Oracle Virtual Private Database状況依存ポリシーの評価の制御

- 仮想プライベート・データベースのDBMS_RLSパッケージおよびビューの長い識別子のサポート

- サービスおよびウォレットへのファイングレイン・アクセスの構成の変更

- 監査機能の大幅な再設計

- 高速な監査パフォーマンス

- 統合監査データ証跡

- 統合監査証跡の新しいスキーマ

- 監査管理の業務分離

- 名前付きの統合監査ポリシーを作成する機能

- ロールを監査する機能

- 監査アクションの強制的な記録

- Oracle ACFS監査およびOracle Audit Vault Serverに監査データをインポートするためのサポート

- Oracleマルチテナント・オプション用のユーザー、権限およびロールのサポート

- 自動ストレージ管理のパスワード・ファイルを使用する機能

- 新しいSecure Sockets Layer暗号スイート

データのカテゴリを保護する透過的機密データ保護

データのカテゴリ全体を保護する透過的機密データ保護ポリシーを作成できます。

透過的機密データ保護により、機密データ(クレジット・カードや社会保障番号など)を保持するデータベースのすべての表の列を確認し、このデータを分類して、指定されたクラスのこのデータ全体を保護するポリシーを作成できます。この機能では、所属している組織全体のデータの均一なポリシーを作成できます。

詳細は、「透過的機密データ保護の使用」を参照してください。

新しいパスワード検証関数

以前のリリースで、Oracle Databaseは、スクリプトutlpwdmg.sqlのパスワード検証関数verify_function_11Gを用意していました。このリリースでは、スクリプトは、より強力なレベルのパスワード検証を提供する次の2つの新しい追加の関数で強化されました。

- ora12c_verify_function関数は、以前に設定したパスワードと異なるパスワードの最小文字数などの要件をチェックします。

- ora12c_strong_verify_function関数では、Department of Defense Database Security Technical Implementation Guideで推奨されている要件をチェックします。

詳細は、次の各項を参照してください。

- 「Oracle Databaseによるパスワードの複雑度のチェック方法」

- 「パスワード複雑度検証のカスタマイズについて」

ロールをプログラム・ユニットに付加する機能

データベース・ロールをプログラム・ユニットの関数、プロシージャおよびPL/SQLパッケージに付加できるようになりました。

この機能により、ロールを直接コードの実行者に付与しないでPL/SQLコードの権限を一時的に昇格できます。この機能の利点は、アプリケーションのセキュリティが強化され、最低限の権限の原則を規定できることです。

詳細は、次の各項を参照してください。

- 「プログラム・ユニットに対するロールの付与と取消し」

- 「定義者権限および実行者権限のコード・ベース・アクセス制御の使用」

プロシージャのコール側の権限を使用できるかどうかを制御する機能

ユーザーが実行者権限プロシージャ(またはプログラム・ユニット)を実行する場合、実行するユーザーの権限で実行されます。

プロシージャが実行されると、プロシージャの所有者は、実行するユーザーの権限に一時的にアクセスできます。プロシージャ所有者が実行するユーザーより少ない権限の状況では、プロシージャ所有者がプロシージャを変更して実行するユーザーの権限を使用し、所有者が意図しないまたは禁止されている操作を実行できる可能性があります。

以前のリリースでは、実行するユーザーは、実行者権限プロシージャを実行する場合、このアクセスが可能なユーザーを制御できませんでした。このリリース以降、実行者権限プロシージャ・コールは、プロシージャの所有者が実行者のINHERIT PRIVILEGES権限を持つ場合またはプロシージャの所有者がINHERIT ANY PRIVILEGES権限を持つ場合に実行者の権限でのみ実行できます。

この機能の利点は、実行者権限プロシージャを実行するか、またはBEQUEATH CURRENT_USERビューに問い合せる場合、権限にアクセスできるユーザーの制御が実行するユーザーに付与されることです。

詳細は、次の各項を参照してください。

- 「プロシージャ・コールおよびビュー・アクセスの実行者権限の制御」

- 「参照されるビューの実行者権限の動作に対応する機能」

参照されるビューの実行者権限の動作に対応する機能

以前のリリースのOracle Databaseでは、ユーザー作成ビューで参照される実行者権限関数は、ビューを定義したユーザーの権限、つまり定義者権限として機能するビューで実行されました。

このリリース以降、ビューを構成して、定義者権限または実行者権限として機能するビューでこれらの関数を実行できます。

内容は次のとおりです。

- 詳細は、「ビューの定義者権限および実行者権限」を参照してください。

- この機能に関連付けられている新しいReal Application Security関連関数の使用の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

外部プロシージャのセキュリティの強化

このリリースでは、extprocエージェントを構成して、リスナー・ユーザーまたはOracleサーバー・プロセスのオペレーティング・システム権限を使用するかわりに指定されたオペレーティング・システム資格証明として実行できます。

安全上の理由のため、Oracle外部プロシージャは、Oracleデータベースと物理的に異なるプロセスで実行されます。外部プロシージャを起動する場合、Oracle Databaseは、データベース・インスタンスのリスナーを開始したユーザーのオペレーティング・システム権限を使用して、extprocオペレーティング・システム・プロセス(またはエージェント)を作成します。

指定されたオペレーティング・システム資格証明として実行するようにextprocエージェントを構成できると、extprocプロセスに関連付けられる資格証明を定義でき、ユーザー定義の共有ライブラリをロードして関数を実行する前に認証および偽装(つまり、指定したユーザー資格証明のかわりに実行)できます。extprocユーザー資格証明を構成するには、新しいPL/SQLパッケージDBMS_CREDENTIALを使用します。この新しいリリースの一部として、CREATE LIBRARY文が強化されて、extprocユーザー資格証明とライブラリを関連付けることができます。

内容は次のとおりです。

- 「外部プロシージャの保護」

- DBMS_CREDENTIALパッケージを使用したextprocプロセスの構成の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- CREATE LIBRARY文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

SHA-2暗号ハッシュ関数のサポート

Oracle Databaseは、ほとんどのSHA-2暗号ハッシュ関数をサポートするようになりました。

次の領域でこれらの関数を使用できます。

- ネットワーク・チェックサム(SHA-256およびSHA-384関数)

- DBMS_CRYPTO PL/SQLパッケージ

Kerberosの機能強化

Oracle Advanced Security Kerberosアダプタの機能が強化され、よりセキュアになり、簡単に使用できるようになりました。新しいKerberosアダプタでは、次の機能を使用できます。

- MIT Kerberosリリース1.8ディストリビューションで導入されたセキュリティ機能強化

- KDCおよびKerberosレルムの自動検出による簡略化されたKerberosクライアント構成

- 様々なホスト・オペレーティング・システム上のKerberosサーバーとの最新かつ広範な互換性

Kerberosの機能向上の詳細およびsqlnet.oraパラメータの新しく更新されたリストについては、「Kerberos認証の構成」を参照してください。

さらなる業務分離の権限の変更

業務分離を強化するために、Oracle Databaseは、Oracle Recovery Manager (Oracle RMAN)、Oracle Data Guardおよび透過的データ暗号化の標準管理業務を処理するタスク固有の権限を提供するようになりました。

新しい権限は、ユーザーに特定の関数を実行するために絶対に必要な権限のみ付与される最低限の権限の原則に基づきます。この機能により、多くのタスクのSYSDBA管理権限を不必要に付与する必要が軽減されます。

管理権限の管理の詳細は、「管理権限の管理」を参照してください。

RESOURCEロールはUNLIMITED TABLESPACE権限を付与しなくなりました

このリリース以降、RESOURCEロールがデフォルトでUNLIMITED TABLESPACEシステム権限を付与しなくなりました。このシステム権限をユーザーに付与する場合、手動で付与する必要があります。

デフォルトのロールの詳細は、「Oracle Databaseのインストールで事前に定義されているロール」を参照してください。

SELECT ANY DICTIONARY権限は一部のSYSデータ・ディクショナリ表にアクセスしなくなりました

セキュリティを強化するために、SELECT ANY DICTIONARYシステム権限でSYSスキーマ・システム表DEFAULT_PWD$、ENC$、LINK$、USER$、USER_HISTORY$、CDB_LOCAL_ADMINAUTH$およびXS$VERIFIERSの問合せが許可されなくなりました。ユーザーSYSのみこれらの表にアクセスできますが、ユーザーSYSはオブジェクト権限(GRANT SELECT ON USER$ TO sec_adminなど)を他のユーザーに付与できます。

システムおよびオブジェクト権限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

Oracle Virtual Private Database状況依存ポリシーの評価の制御

以前のリリースでは、Oracle Virtual Private Database (VPD)状況依存ポリシーを作成した場合、Oracle Databaseは、アプリケーション・コンテキスト属性がVPD状況依存ポリシーに影響しない場合でも、状況の属性が変更されるたびにポリシーを評価しました。

このリリース以降、関連付けられているアプリケーション・コンテキスト属性を変更する場合のみ、Oracle DatabaseによってVPD状況依存ポリシーを評価できます。アプリケーション・コンテキストおよびその属性を特定のVPDポリシーに関連付けることができ、関連付けられているアプリケーション・コンテキスト属性が変更される場合のみ、VPDポリシーで新しい述語を生成できます。

詳細は、「変更されるアプリケーション・コンテキスト属性の状況依存ポリシー」を参照してください。

仮想プライベート・データベースのDBMS_RLSパッケージおよびビューの長い識別子のサポート

以前のリリースのOracle Databaseでは、Oracle Virtual Private Database DBMS_RLS PL/SQLパッケージ・プロシージャおよびこのパッケージの関連ビューで指定されたオブジェクト名(表、スキーマ、ポリシーや関数の名前など)の最大長は30バイトでした。このリリース以降、最大長は128バイトです。

Oracle Virtual Private Databaseの詳細は、「Oracle Virtual Private Databaseを使用したデータ・アクセスの制御」を参照してください。

サービスおよびウォレットへのファイングレイン・アクセスの構成の変更

このリリースでは、外部ネットワーク・サービスおよびOracleウォレットへのファイングレイン・アクセスを構成するプロシージャが簡略化されました。

DBMS_NETWORK_ACL_ADMIN PL/SQLパッケージが次のように変更されました。

以前のDBMS_NETWORK_ACL_ADMINプロシージャ

新しい同等のプロシージャ

CREATE_ACL

ADD_PRIVILEGE

ASSIGN_ACL

ASSIGN_WALLET_ACL

APPEND_HOST_ACE

APPEND_WALLET_ACE

N/A

APPEND_HOST_ACL

N/A

APPEND_WALLET_ACL

DELETE_PRIVILEGE

DROP_ACL

UNASSIGN_ACL

UNASSIGN_WALLET_ACL

REMOVE_HOST_ACE

REMOVE_WALLET_ACE

CHECK_PRIVILEGE

なし

CHECK_PRIVILEGE_ACLID

なし

N/A

SET_HOST_ACL

N/A

SET_WALLET_ACL

これらの変更されたプロシージャに対応するため、次の新しいデータ・ディクショナリ・ビューがこのリリースで導入されています。

- DBA_HOST_ACLS

- DBA_HOST_ACES

- USER_HOST_ACES

詳細は、次の各項を参照してください。

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

- 「非推奨のDBMS_NETWORK_ACL_ADMINパッケージ・プロシージャおよびビュー」

監査機能の大幅な再設計

このリリースでは、監査機能が以前のリリースで使用された機能から大幅に再設計されました。新しいリリース12のOracleデータベースをインストールすると、すべての監査強化機能(統合監査)を自動的に取得できます。以前のリリースからアップグレードする場合、一部の新しい監査機能およびアップグレード元のリリースの監査機能を使用するオプションが提供されます。すべての最新の監査機能に移行することをお薦めします。

新しい監査機能への移行の詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

関連項目:

統合監査の移行による各監査機能への影響

高速な監査パフォーマンス

このリリースは、以前のリリースのOracle Databaseより監査パフォーマンスが大幅に向上しています。監査レコードを監査証跡に書き込む方法、即時かメモリーにキューするかどうかも制御できます。

詳細は、「AUDSYSスキーマへの統合監査証跡レコードの書込み」を参照してください。

統合監査データ証跡

Oracle Databaseの以前のリリースでは、コンポーネントごとに個別の監査証跡がありました。

これらのコンポーネントは、データベース監査証跡のSYS.AUD$、ファイングレイン監査のSYS.FGA_LOG$、Oracle Database VaultのDVSYS.AUDIT_TRAIL$、Oracle Label Securityなどです。このリリースでは、これらの監査証跡が1つにすべて統合され、単一インスタンス・インストールのOracle Database Real Application Clusters環境のUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューから表示できます。

統合監査データ証跡には多くの利点があります。これによって、分析を実行する前に1つの場所に最初に収集するのではなく、1つの操作で監査データ全体の分析レポートを実行できます。Oracle Audit Vaultなどの監査マイニング・ツールは、監査レコードを収集するために複数の場所ではなく1つの場所で参照できるようになりました。統合監査証跡は、監査情報が一貫してフォーマットされ、一貫したフィールドが含まれていることを確認します。

詳細は、「統合監査証跡の管理」を参照してください。

統合監査証跡の新しいスキーマ

統合監査証跡の機能強化の一部として、統合監査証跡データ表の記憶域にのみ、新しいスキーマAUDSYSが使用されます。AUD$およびFGA_LOG$システム表の既存の監査データ、監査メタデータおよび監査PL/SQLパッケージは、引き続きSYSスキーマにあります。

詳細は、「統合監査証跡の管理」を参照してください。

監査管理の業務分離

業務分離を強化するために、監査構成および監査証跡管理のAUDIT_ADMINと監査データの表示および分析のAUDIT_VIEWERの2つの新しいデータベース・ロールを監査で使用できるようになりました。

詳細は、「監査を実行できるユーザー」を参照してください。

名前付きの統合監査ポリシーを作成する機能

名前付きの統合監査ポリシーを作成できるようになりました。統合監査ポリシーは、一連の監査オプションを含み、オブジェクトとしてデータベースに格納されます。

名前付きの統合監査ポリシーを作成する利点は、データベース監査ポリシーを作成するために必要なコマンドの数を削減し、セキュリティおよびコンプライアンスの監査構成の実装を簡略化することです。

次の新しいSQL文では、監査ポリシーを管理できます。

- CREATE AUDIT POLICY

- ALTER AUDIT POLICY

- DROP AUDIT POLICY

また、既存のAUDITおよびNOAUDIT文は、統合監査ポリシーの有効化または無効化、ポリシーに対するユーザーの適用または除外および監査された動作が失敗、成功または失敗/成功した場合に監査レコードを作成するかどうかの設定を許可できます。

詳細は、「統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査」を参照してください。

ロールを監査する機能

このリリース以降、ユーザー作成ロールを含むデータベース・ロールを監査できます。

これにより、ロールに付与されたすべてのシステム権限を監査できます。この機能の利点は、ロールに付与されたすべてのアクティビティを単一のコマンドに簡略化することです。これにより、新しいデータベース・ユーザーがデータベースに追加され、ロールが付与される場合、新しい権限でロールを更新するたびに統合監査ポリシーを更新する必要がなくなります。

詳細は、「ロールの監査」を参照してください。

監査アクションの強制的な記録

このリリースでは、監査機能に関連付けられるすべてのアクションが常に監査されます。監査管理者のアクションを監査すると、セキュリティ要件およびコンプライアンス要件に対し、Oracleデータベースで実装された監査ポリシーの整合性を確認できます。

詳細は、「強制的に監査されるアクティビティ」を参照してください。

Oracle ACFS監査およびOracle Audit Vault Serverに監査データをインポートするためのサポート

この機能により、Oracle Automatic Storage Managementクラスタ・ファイルシステム(ACFS)のセキュリティと暗号化の監査が提供されます。また、この機能では、Oracle Audit Vault Serverによってインポート可能なOracle ACFS監査証跡データを格納するXMLファイルも生成されます。これによって、Oracle ACFS監査データの記憶域およびレポートに対するOracle Audit Vault機能を利用できます。

詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

Oracleマルチテナント・オプション用のユーザー、権限およびロールのサポート

このリリースのOracle Databaseでは、Oracle Databaseに個別のデータベースのようにユーザーおよびアプリケーションに表示されるスキーマおよびスキーマ以外のオブジェクト(エディション、ロールなど)の移植性のあるセットを含めることができるOracleマルチテナント・オプションを導入しています。これらのオブジェクトの各セットはプラガブル・データベース(PDB)と呼ばれ、これらのPDBを格納するデータベースはマルチテナント・コンテナ・データベース(CDB)と呼ばれます。

Oracle Database 12cリリース1 (12.1)は、CDBと非CDBの両方をサポートしています。このマニュアルでは、CDBおよびCDB以外のユーザー・アカウント、権限およびロールの管理方法について説明します。

内容は次のとおりです。

- 「共通ユーザーおよびローカル・ユーザーについて」

- 「共通およびローカルに付与される権限について」

- 「共通ロールおよびローカル・ロールの管理」

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

自動ストレージ管理のパスワード・ファイルを使用する機能

Oracle Automatic Storage Management(ASM)は、ASMディスク・グループ内のパスワード・ファイルの格納をサポートするようになりました。

自動ストレージ管理のパスワード・ファイルの管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

新しいSecure Sockets Layer暗号スイート

次のSecure Sockets Layer暗号スイートは、このリリース以降利用できます。

暗号スイート

認証

暗号化

データ整合性

SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

ECDHE_ECDSA

AES 128 CBC

SHA-1

SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

ECDHE_ECDSA

AES 128 CBC

SHA256 (SHA-2)

SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

ECDHE_ECDSA

AES 128 GCM

SHA256 (SHA-2)

SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

ECDHE_ECDSA

AES 256 CBC

SHA-1

SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

ECDHE_ECDSA

AES 256 CBC

SHA384 (SHA-2)

SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

ECDHE_ECDSA

AES 256 GCM

SHA384 (SHA-2)

SSL_RSA_WITH_AES_128_CBC_SHA256

RSA

AES 128 CBC

SHA256 (SHA-2)

SSL_RSA_WITH_AES_128_GCM_SHA256

RSA

AES 128 GCM

SHA256 (SHA-2)

SSL_RSA_WITH_AES_256_CBC_SHA256

RSA

AES 256 CBC

SHA256 (SHA-2)

SSL_RSA_WITH_AES_256_GCM_SHA384

RSA

AES 256 GCM

SHA384 (SHA-2)

サポートされているSecure Sockets Layer暗号スイートの完全なリストは、表18-1を参照してください。

非推奨機能

このリリースの非推奨機能は次のとおりです。

- SQLNET.ALLOWED_LOGON_VERSIONパラメータの非推奨

- ORAPWDユーティリティのIGNORECASE引数の非推奨

- SEC_CASE_SENSITIVE_LOGON初期化パラメータの非推奨

- 非推奨のDBMS_NETWORK_ACL_ADMINパッケージ・プロシージャおよびビュー

- DELETE_CATALOG_ROLEロールの非推奨

SQLNET.ALLOWED_LOGON_VERSIONパラメータの非推奨

このリリース以降、Oracle Net Services SQLNET.ALLOWED_LOGON_VERSIONパラメータが非推奨になります。次の2つのパラメータに置き換わります。

- SQLNET.ALLOWED_LOGON_VERSION_SERVER

- SQLNET.ALLOWED_LOGON_VERSION_CLIENT

SQLNET.ALLOWED_LOGON_VERSIONパラメータのサーバー・バージョンおよびクライアント・バージョンを持つと、データベース・リンクを使用するサーバーを構成する必要がある場合により柔軟性が得られます。接続されたデータベース・リンクを含む問合せを処理すると、サーバーがデータベース・リンクのターゲット・データベースへのクライアントとして機能します。たとえば、Oracle 9iデータベースに接続するOracle Database 12cリリース1 (12.1)データベースがあるとします。SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを11、SQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータを8に設定して、Oracle Databaseリリース11以上を実行するクライアントのみにOracle Database 12cデータベースの接続を制限します。ただし、これらの設定では、古いOracle 9iデータベースへのクライアントとして機能するOracle Database 12cサーバーを引き続き使用できます。

内容は次のとおりです。

- 「SHA-2暗号ハッシュ関数のサポート」

- SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

- SQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

ORAPWDユーティリティのIGNORECASE引数の非推奨

このリリース以降、パスワード・ファイルの作成に使用されるORAPWDユーティリティのIGNORECASE引数は非推奨になります。デフォルトでは、IGNORECASEは、パスワードの大/小文字を区別するN(no)に設定されます。

関連項目:

パスワード・ファイルの大/小文字の区別の詳細は、「大/小文字の区別がパスワード・ファイルに与える影響」を参照してください。

SEC_CASE_SENSITIVE_LOGON初期化パラメータの非推奨

標準ベースのベリファイア(SHA-1)が大/小文字を区別するパスワード照合をサポートしないため、パスワードの大/小文字の区別を有効化または無効化するSEC_CASE_SENSITIVE_LOGON初期化パラメータは非推奨です。下位互換性の理由のため、このパラメータをこのリリースで使用できます。セキュリティを強化するために、データベース・ログオン・パスワードの大/小文字を区別するため、このパラメータがTRUEに設定されていることを確認してください。

内容は次のとおりです。

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

- SEC_CASE_SENSITIVE_LOGONパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

非推奨のDBMS_NETWORK_ACL_ADMINパッケージ・プロシージャおよびビュー

DBMS_NETWORK_ACL_ADMIN PL/SQLパッケージの次のプロシージャが非推奨になりました。

- CREATE_ACL

- ADD_PRIVILEGE

- DELETE_PRIVILEGE

- ASSIGN_ACL

- UNASSIGN_ACL

- DROP_ACL

- ASSIGN_WALLET_ACL

- UNASSIGN_WALLET_ACL

- CHECK_PRIVILEGE

- CHECK_PRIVILEGE_ACLID

次のDBMS_NETWORK_ACL_ADMINパッケージ関連のデータ・ディクショナリ・ビューが非推奨になりました。

- DBA_NETWORK_ACLS

- DBA_NETWORK_ACL_PRIVILEGES

- USER_NETWORK_ACL_PRIVILEGES

詳細は、次の各項を参照してください。

- 「サービスおよびウォレットへのファイングレイン・アクセスの構成の変更」

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

DELETE_CATALOG_ROLEロールの非推奨

Oracle Database 12cリリース1 (12.1)では、DELETE_CATALOG_ROLEロールは非推奨です。

サポート対象外となった機能

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

- サポート対象外となったSecure Sockets Layer暗号スイート

サポート対象外となったSecure Sockets Layer暗号スイート

次のSecure Sockets Layer暗号スイートはサポート対象外になりました。

暗号スイート

認証

暗号化

データ整合性

SSL_DH_anon_WITH_DES_CBC_SHA

DH anon

DES CBC

SHA-1

SSL_RSA_EXPORT_WITH_DES40_CBC_SHA

RSA

DES40 CBC

SHA-1

SSL_RSA_EXPORT_WITH_RC4_40_MD5

RSA

RC4 40

MD5

SSL_RSA_WITH_DES_CBC_SHA

RSA

DES CBC

SHA-1

サポートされているSecure Sockets Layer暗号スイートの完全なリストは、表18-1を参照してください。

その他の変更

可用性の向上のため、Oracle Advanced Securityが再パッケージ化されました。次の機能は、Oracle Advanced Securityの一部ではなくなり、デフォルトのOracle Databaseのインストールで提供されます。

- シンJDBCクライアント・ネットワーク・サポート

- RADIUS厳密認証

- Kerberos厳密認証

- Secure Sockets Layer (SSL)厳密認証

- 複数の厳密認証サポート

これらの機能の詳細は、このマニュアルを参照してください。

次の機能はOracle Advanced Securityの一部で、『Oracle Database Advanced Securityガイド』で説明されています。

- 透過的データ暗号化

- Oracle Data Redaction

この変更の一部として、『Oracle Database Advanced Security管理者ガイド』の名前が『Oracle Database Advanced Securityガイド』に変更されました。

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

Oracle Databaseには、デフォルトのセキュリティ機能が豊富に用意されています。これらを使用して、ユーザー・アカウント、認証、権限、アプリケーション・セキュリティ、暗号化、ネットワーク・トラフィックおよび監査を管理できます。

内容は次のとおりです。

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

- その他のOracle Databaseセキュリティ・リソース

Oracle Databaseセキュリティの概要

デフォルトのOracle Database機能を使用すると、Oracle Databaseインストールのいくつかの領域でセキュリティを構成できます。

セキュリティを構成できる領域は次のとおりです。

- ユーザー・アカウント。作成したユーザー・アカウントは様々な方法で保護できます。サイトのパスワード・ポリシーを強化するために、パスワード・プロファイルを作成することもできます。Oracle Databaseユーザーのセキュリティの管理では、ユーザー・アカウントの管理方法について説明します。

- 認証方式。Oracle Databaseには、ユーザーおよびデータベース管理者用の認証を構成する方法がいくつかあります。たとえば、ユーザーは、データベース・レベル、オペレーティング・システムおよびネットワークで認証できます。認証の構成では、Oracle Databaseにおける認証の機能について説明します。

- 権限とロール。権限とロールを使用すると、データに対するユーザー・アクセスを制限できます。次の章では、権限およびロールを管理する方法について説明します。

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

- 定義者権限および実行者権限のセキュリティの管理

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

- Enterprise Managerによるマルチテナント環境のセキュリティの管理

- アプリケーション・セキュリティ。データベース・アプリケーションを作成する最初のステップは、データベース・アプリケーションが適切に保護されるようにすることです。アプリケーション開発者のセキュリティの管理では、アプリケーション・セキュリティをアプリケーション・セキュリティ・ポリシーに組み込む方法について説明します。

- アプリケーション・コンテキストを使用したユーザー・セッション情報。アプリケーション・コンテキストは、セッション情報を保持する名前と値のペアです。この情報に基づいて、ユーザーの名前や端末などのユーザーに関するセッション情報を取得し、そのユーザーのデータベース・アクセスおよびアプリケーション・アクセスを制限できます。「アプリケーション・コンテキストを使用したユーザー情報の取得」では、アプリケーション・コンテキストの使用方法について説明します。

- 仮想プライベート・データベースを使用した行および列レベルでのデータベース・アクセス。仮想プライベート・データベース・ポリシーは、ユーザーが発行したSQL文にWHERE述語を動的に埋め込みます。Oracle Virtual Private Databaseを使用したデータ・アクセスの制御では、仮想プライベート・データベース・ポリシーの作成方法と管理方法について説明します。

- 異なるカテゴリのデータの分類および保護。機密データ(クレジット・カードや社会保障番号など)を保持するデータベースのすべての表の列を確認し、このデータを分類して、指定されたクラスのこのデータ全体を保護するポリシーを作成できます。透過的機密データ保護の使用では、透過的機密データ保護ポリシーの作成方法について説明します。

- ネットワーク・データの暗号化。手動によるデータ暗号化では、ネットワーク・データへの不正アクセスを防止するために、DBMS_CRYPTO PL/SQLパッケージを使用して、ネットワーク・データを暗号化する方法について説明します。「Oracle Databaseのネットワーク・データ暗号化とデータ整合性の構成」で説明するように、サーバーとクライアントの両方でOracle Net Servicesのネイティブなデータの暗号化と整合性を構成できます。

- シンJDBCクライアント・ネットワーク構成。シンJava Database Connectivity (JDBC)クライアントを構成して、Oracleデータベースに安全に接続できます。シンJDBCクライアント・ネットワークの構成では、詳細情報について示します。

- 厳密認証。データベースを構成して、デジタル証明書を使用するSSLを含む様々なサード・パーティ認証サービスをサポートするOracle認証アダプタを使用した厳密認証を使用できます。Oracle Databaseには、次の厳密認証サポートが用意されています。

- 集中化された認証とシングル・サインオン。

- Kerberos

- Remote Authentication Dial-in User Service(RADIUS)

- Secure Sockets Layer (SSL)

次の章では、厳密認証を扱います。

- 厳密認証の概要

- 厳密認証の管理ツール

- Kerberos認証の構成

- Secure Sockets Layer認証の構成

- RADIUS認証の構成

- 厳密認証の使用のカスタマイズ

- データベース・アクティビティの監査。データベース・アクティビティは、すべてのSQL文、SQL権限、スキーマ・オブジェクト、ネットワーク・アクティビティの監査など、一般的な条件で監査できます。または、社内ネットワーク外部のIPアドレスが使用されているような場合は、きめ細かい方法で監査できます。この章では、データベース監査証跡の削除方法についても説明します。次の章では、データベース監査の構成および管理方法について説明します。

- 監査の概要

- 監査ポリシーの構成

- 監査証跡の管理

さらに、Oracle Databaseの安全性の維持では、Oracle Databaseインストールを保護する際に従う必要のあるガイドラインを示します。

その他のOracle Databaseセキュリティ・リソース

このマニュアルで説明するセキュリティ・リソース以外に、Oracle Databaseには、他のいくつかのデータベース・セキュリティ製品が用意されています。

これらの製品は次のとおりです。

- Oracle Advanced Security。透過的データ暗号化およびOracle Data Redactionの詳細は、『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 and Database Firewall。Oracle Audit Vault and Database Firewallでは、Oracle Databaseの監査証跡表、データベース・オペレーティング・システム監査ファイル、データベースのREDOログなどのソースからデータベース監査データを収集します。Oracle Audit Vault and Database Firewallを使用すると、不審なアクティビティに対するアラートを作成したり、権限を持つユーザーの変更、スキーマの変更およびデータ・レベルのアクセスに関する履歴のレポートを作成できます。『Oracle Audit Vault and Database Firewall管理者ガイド』では、Oracle Audit Vault and Database Firewallの管理方法について説明しています。

- Oracle Enterprise User Security。Oracle Enterprise User Securityを使用すると、ユーザー・セキュリティをエンタープライズ・レベルで管理できます。Oracle Enterprise User Securityの構成方法は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- Oracle Enterprise Manager Data Masking and Subsetting Pack。Data Masking and Subsetting Packを使用すると、元の機密データを架空のデータに不可逆的に置き換え、本番データをIT開発者またはオフショア・ビジネス・パートナと安全に共有できるようにすることで、このようなリスクを低減できます。詳細は、Oracle Database Testingガイドを参照してください。

これらの製品に加えて、新製品およびセキュリティ・パッチやアラートに関する重要な情報など、Oracle Databaseセキュリティに関する最新情報を入手するには、Oracle Technology Networkの「Security Technology Center」を参照してください。次の場所でアクセスできます。

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

第I部 ユーザー認証および認可の管理

第I部では、ユーザー認証および認可の管理方法について説明します。

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

- 認証の構成

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

- 定義者権限および実行者権限のセキュリティの管理

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

- Enterprise Managerによるマルチテナント環境のセキュリティの管理

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

パスワード作成時に制限を適用するなど、Oracle Databaseユーザーのセキュリティは様々な方法で管理できます。

内容は次のとおりです。

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

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

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

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

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

- データベース・ユーザーおよびプロファイルのデータ・ディクショナリ・ビュー

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

厳密なパスワードおよびユーザー用の特別な制限を指定することで、ユーザー・アカウントを保護できます。

各Oracleデータベースには、有効なデータベース・ユーザーのリストがあります。データベースにアクセスするには、ユーザーは、データベース・アプリケーションを実行し、データベースに定義されている有効なユーザー名を使用して、データベース・インスタンスに接続する必要があります。

ユーザー・アカウントの作成時に、ユーザー・アカウントに対して制限を指定できます。ユーザーのセキュリティ・ドメインの一部として、各ユーザーが使用できる各種のシステム・リソースの容量に制限を設定することもできます。Oracle Databaseには、リソースやセッションなどの情報を検索する際に問い合せることができる一連のデータベース・ビューが用意されています。この章では、プロファイルについても説明します。プロファイルとは、ユーザーに適用される属性の集合です。それらの属性を共有する複数ユーザーの中の任意のユーザーに関する単一の参照になります。

関連項目:
「権限とロール認可の構成」に、ユーザー権限およびロールを割り当ててユーザー・セキュリティも管理する方法を示します

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

プロファイル、デフォルト・ロール、表領域制限など、ユーザー・アカウントに制限を設定できます。

内容は次のとおりです。

- 共通ユーザーおよびローカル・ユーザーについて

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

- 最小限のデータベース権限を持つ新しいユーザー・アカウントの作成

- 新しいアカウントのユーザー名の作成に関する制限事項

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

- ユーザーのデフォルト表領域

- ユーザーへの表領域の割当て制限

- ユーザーの一時表領域

- ユーザーのプロファイル

- 共通ユーザーまたはローカル・ユーザーの作成

- ユーザーのデフォルト・ロールの作成

ユーザー・アカウントおよびパスワードの作成と管理のガイドラインは、次の各項を参照してください。

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

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

共通ユーザーおよびローカル・ユーザーについて

マルチテナント環境では、共通ユーザーはCDB全体に対するアクセス権を持ち、ローカル・ユーザーはPDB固有のユーザーです。

内容は次のとおりです。

- 共通ユーザーについて

- PDBへの接続による共通ユーザーへの影響

- ローカル・ユーザーについて

関連項目:

- 共通ユーザーおよびローカル・ユーザーの概要は、『Oracle Database概要』を参照してください

- Enterprise Managerの共通ユーザーおよびローカル・ユーザーの管理

共通ユーザーについて

マルチテナント環境では、共通ユーザーのIDおよびパスワードは、ルートおよび各プラガブル・データベース(PDB)で認識されます。

共通ユーザーは、ルートに接続して操作を実行できます。共通ユーザーに適切な権限がある場合、ローカル・ユーザーへの権限の付与など、PDBで操作を実行できます。

共通ユーザーは、PDBの接続および切断、状態の変更、マルチテナント・コンテナ・データベース(CDB)の一時表領域の指定など、ルートまたはPDBに固有の管理タスクを実行できます。適切な権限を持つ共通ユーザーのみ、CDBに属するコンテナ間を操作できます。

たとえば、共通ユーザーは複数のPDBで次の操作を実行できます。

- 共通ユーザーまたは共通ロールへの権限の付与

- CDB全体に適用するリカバリ句を指定するALTER DATABASE文の実行

- ルートへの接続中に指定されたPDBの状態を変更するALTER PLUGGABLE DATABASE文の実行。PDBに接続されるローカル・ユーザーは、状態、指定された適切な権限も変更できます。

Oracleから提供されるSYSおよびSYSTEMなどのすべての管理ユーザー・アカウントは共通ユーザーで、CDBを操作できます。共通ユーザーは、別のPDBの異なる権限を持つことができます。たとえば、共通ユーザーSYSTEMは、PDB間を切り替えて、現在のPDBのSYSTEMに付与されている権限を使用できます。ただし、PDBのいずれかでOracle Database Vaultが有効な場合、このPDBに接続している間は、ユーザー・アカウントを作成できないSYSTEMなどのDatabase Vault制限が共通SYSTEMユーザーに適用されます。(Oracleから提供される共通ユーザーの権限を変更することはお薦めしません。ただし、コンテナごとに、ユーザー作成の共通ユーザーに異なる権限をローカルで付与することはできます。)

関連項目:

- 共通ユーザー・アカウントの作成について

- PDBでの権限の使用方法の詳細は、共通およびローカルに付与される権限についてを参照してください

- 共通ユーザーの概念については、『Oracle Database概要』を参照してください

PDBへの接続による共通ユーザーへの影響

CDB以外をPDBとしてCDBに差し込むと、Oracle付属の管理アカウント、ユーザー作成アカウントおよびそれらの権限に影響があります。

次のアクションが実行されます。

- Oracleから提供される管理アカウントが既存の共通ユーザー・アカウントにマージされます。

- 既存の共通ユーザー・アカウントのパスワードは、CDB以外のアカウントのパスワードよりも優先されます。

- 元のCDB以外のユーザー・アカウントの権限を変更した場合、これらの権限は保存されますが、ローカルに付与された権限としてCDBにPDBを接続した場合に作成されたPDBにのみ適用されます。たとえば、ユーザーSYSTEMにCDB以外のdb1のhr_mgrと呼ばれるロールを付与したとします。db1データベースがCDBに追加された後、SYSTEMは、他のPDBではなくdb1 PDBのhr_mgrロールのみ使用できます。

共通ユーザーを格納するPDBをCDBに接続する場合は、次のアクションが発生します。

- このPDBの共通ユーザー・アカウントで、SET CONTAINER権限を含む、付与されている可能性がある共通付与された権限が失われます。

- ターゲットCDBに共通ユーザーが存在し、新しく接続されたPDBの共通ユーザーと同じ名前である場合、新しい共通ユーザーはターゲットCDBの共通ユーザーにマージされます。ターゲットCDBの共通ユーザーのパスワードが優先されます。それ以外の場合は、新しく接続されたPDBの共通ユーザーはロックされたアカウントになります。この場合、次のいずれかを実行できます。

- ユーザー・アカウントをロックされた状態にし、このスキーマのオブジェクトを使用します。

- Oracle Data Pumpを使用して、これらのオブジェクトを別のスキーマにコピーし、ロックされているユーザー・アカウントを削除します。

- PDBを閉じ、ルートに接続して、ロックされているアカウントと同じ名前で共通ユーザーを作成します。PDBを再度開くと、Oracle Databaseによって、ロックされているユーザーに共通に付与されたロールと権限の違いが解消されます。後で、PDBのこのユーザー・アカウントのロックを解除できます。ユーザーにローカルに付与されている権限およびロールは変更されません。

ローカル・ユーザーについて

マルチテナント環境では、ローカル・ユーザーとは、単一のPDBにのみ存在するデータベース・ユーザーです。

ローカル・ユーザーは管理権限を持つことができますが、これらの権限はローカル・ユーザー・アカウントが作成されたPDBにのみ適用されます。ローカル・ユーザー・アカウントには、共通ユーザー・アカウントと区別する次の特性があります。

- ローカル・ユーザー・アカウントは、共通ユーザー・アカウントを作成できないまたは権限をローカルに付与できません。適切な権限を持つ共通ユーザーは、共通またはローカル・ユーザー・アカウントを作成および変更し、共通またはローカルに権限を付与および取り消すことができます。ローカル・ユーザーは、ローカル・ユーザー・アカウントを作成または変更したり、指定のPDBの共通またはローカル・ユーザーに権限をローカルに付与できます。

- ローカル・ユーザー・アカウントの共通ロールを付与できます。ただし、共通ロールに関連付けられている権限は、ローカル・ユーザーのPDBにのみ適用されます。

- ローカル・ユーザーは、そのPDB内のみで一意にする必要があります。

- 適切な権限がある場合、ローカル・ユーザーは、共通ユーザーのスキーマのオブジェクトにアクセスできます。たとえば、共通ユーザーのスキーマ内の表にアクセスするためのローカル・ユーザー権限が共通ユーザーに付与されている場合、ローカル・ユーザーはその表にアクセスできます。

- 共通ユーザー・アカウントではなくローカル・ユーザー・アカウントのエディションに対応できます。

関連項目:

- ローカル・ユーザー・アカウントの作成について

- ローカル・ユーザーの概念については、『Oracle Database概要』を参照してください。

ユーザー・アカウントの作成者とは

CREATE USERシステム権限を付与されているユーザーは、ユーザー・アカウント(プロキシ・ユーザーとして使用されるユーザー・アカウントを含む)を作成できます。

CREATE USERは強力なシステム権限であるため、通常、この権限を持つユーザーはデータベース管理者またはセキュリティ管理者のみです。

ユーザーを作成する権限を持つユーザーを作成する場合は、GRANT文にWITH ADMIN OPTION句を含めます。次に例を示します。

GRANT CREATE SESSION TO lbrown WITH ADMIN OPTION;

権限を付与するすべてのユーザー・アカウントと同様に、これらの権限を信頼できるユーザーのみに付与します。

マルチテナント環境で共通ユーザー・アカウントを作成するには、共通に付与されるCREATE USERシステム権限が必要です。ローカル・ユーザー・アカウントを作成するには、ローカル・ユーザー・アカウントを作成するPDB内に、共通に付与されるCREATE USER権限またはローカルに付与されるCREATE USER権限が必要です。

注意:

セキュリティ管理者は、独自のロールを作成し、必要な権限のみを割り当てる必要があります。たとえば、それまでCONNECT権限を付与されていた多くのユーザーは、CONNECTで提供されていた追加権限を必要とはしていませんでした。実際に必要なのはCREATE SESSIONのみでした。デフォルトでは、SET CONTAINER権限がCONNECTロールに付与されます。

組織固有のロールを作成することによって、組織で割り当てる権限を詳細に制御でき、Oracle Databaseが定義するロールが将来のリリースで変更された場合に組織を保護できます。ロールの作成方法と管理方法は、「権限とロール認可の構成」を参照してください。

最小限のデータベース権限を持つ新しいユーザー・アカウントの作成

新しいユーザー・アカウントを作成する場合、このユーザーがデータベースにアクセスできるようにする必要があります。

1. CREATE USER文を使用して新しいユーザー・アカウントを作成します。

例:

CREATE USER jward
IDENTIFIED BY password
DEFAULT TABLESPACE example
QUOTA 10M ON example
TEMPORARY TABLESPACE temp
QUOTA 5M ON system
PASSWORD EXPIRE;

「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。

この例では、ローカル・ユーザー・アカウントを作成し、ユーザー・パスワード、デフォルト表領域、一時セグメントが作成される一時表領域、表領域の割当て制限およびプロファイルを指定します。

2. 少なくとも、データベース・インスタンスにアクセスできるように、ユーザーにCREATE SESSION権限を付与します。

GRANT CREATE SESSION TO jward;

新規作成されたユーザーは、CREATE SESSION権限を持つまでデータベースに接続できません。Oracle Enterprise Managerへのアクセスが必要なユーザーには、SELECT ANY DICTIONARY権限も付与する必要があります。

関連トピック

- 新しいアカウントのユーザー名の作成に関する制限事項

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

- ユーザーのデフォルト表領域

- ユーザーへの表領域の割当て制限

- ユーザーの一時表領域

- ユーザーのプロファイル

- 共通ユーザーまたはローカル・ユーザーの作成

新しいアカウントのユーザー名の作成に関する制限事項

ユーザー・アカウントの名前を指定する場合は、名前が一意かどうかやネーミング規則などの制限事項に注意する必要があります。

内容は次のとおりです。

- ユーザー名の一意性

- マルチテナント環境のユーザー名

- ユーザー名の大/小文字の区別

ユーザー名の一意性

各ユーザーにはスキーマが関連付けられています。スキーマ内の各スキーマ・オブジェクトには、必ず一意の名前を指定する必要があります。

Oracle Databaseでは、すでに存在しているユーザー名は作成できません。DBA_USERSデータ・ディクショナリ・ビューのUSERNAME列を問い合せて、既存の名前を確認できます。

マルチテナント環境のユーザー名

各PDB内のユーザー名は、そのPDB内の他のユーザー名およびロールと比較して一意である必要があります。

次の制約に注意してください:

- ユーザーが作成する共通ユーザーの名前は、C## (またはc##)で始まる必要があります。

- ローカル・ユーザー名をC## (またはc##)で始めることはできません。

- ユーザーとロールに同じ名前を付けることはできません。

ユーザー名の大/小文字の区別

ユーザー名をどのように作成するかによって、データベースに格納されるユーザー名の大文字と小文字の区別が決まります。

例:

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;

ユーザーjwardはデータベースに大文字で格納されます。次に例を示します。

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";

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

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
CONTAINER = CURRENT;

関連項目:

- パスワードを作成するための最低要件は、「パスワードの最低要件」を参照してください。

- パスワードを保護する別の方法については、「パスワードの保護に関するガイドライン」を参照してください。

- Oracle Databaseユーザーが使用できる認証方式の詳細は、認証の構成を参照してください

ユーザーのデフォルト表領域

デフォルト表領域は、ユーザーが作成するオブジェクトを格納します。

内容は次のとおりです。

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

- デフォルト表領域を割り当てるためのDEFAULT TABLESPACE句

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

各ユーザーには、デフォルト表領域が必要です。

スキーマ・オブジェクトがユーザーのスキーマ内に作成され、かつそのDDL文でそのオブジェクトを格納する表領域が指定されていない場合、そのオブジェクトはユーザーのデフォルト表領域に格納されます。

表領域を使用すると、ユーザー・データとシステム・データ(SYSTEM表領域に格納されるデータなど)を区別できます。CREATE USER文またはALTER USER文を使用して、ユーザーにデフォルト表領域を割り当てます。すべてのユーザーのデフォルト表領域に対するデフォルト設定は、SYSTEM表領域です。ユーザーがオブジェクトを作成せず、オブジェクトを作成するための権限も持っていない場合は、デフォルト設定のままで問題ありません。ただし、任意のタイプのオブジェクトを作成する可能性があるユーザーには、デフォルト表領域(USERS表領域など)を明示的に割り当てる必要があります。SYSTEM以外の表領域を使用すると、同じデータ・ファイルに対するデータ・ディクショナリ・オブジェクトとユーザー・オブジェクト間の競合が解消されます。通常、ユーザー・データはSYSTEM表領域に格納しないでください。

CREATE TABLESPACE SQL文を使用して、データベースの作成時に、データベースの永続オブジェクトのデフォルトとして使用される、SYSTEM以外のデフォルト永続表領域を作成できます。ユーザー・データをシステム・データと区切ることにより、状況次第ではデータベース全体が機能不全になる場合もある、SYSTEM表領域に関する問題が生じる可能性を減らすことができます。このデフォルトの永続表領域は、システム・ユーザー、つまりデフォルトの永続表領域がSYSTEMであるSYS、SYSTEM、およびOUTLNが使用するものではありません。デフォルト永続表領域として指定されている表領域は削除できません。目標を達成するためには、最初にデフォルトの永続表領域として他の表領域を指定する必要があります。ALTER TABLESPACE SQL文を使用して、デフォルトの永続表領域を他の表領域に変更できます。この変更はALTER DDL文の実行後に作成されたすべてのユーザーまたはオブジェクトに影響を及ぼすことに注意してください。

ユーザー作成時に、そのユーザーのデフォルト表領域を設定しておき、作成後にALTER USER文を使用して変更することもできます。ユーザーのデフォルト表領域を変更すると、設定の変更後に作成されたオブジェクトのみがこの変更の影響を受けます。

ユーザーのデフォルト表領域を指定するときは、その表領域に対する割当て制限もあわせて指定してください。

デフォルト表領域を割り当てるためのDEFAULT TABLESPACE句

CREATE USER文のDEFAULT TABLESPACE句で、ユーザーにデフォルト表領域を割り当てます。

次のCREATE USER文では、ローカル・ユーザーjwardのデフォルト表領域は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
CONTAINER = CURRENT;

関連項目:

表領域に対する領域割当て制限の割当てについては、「ユーザーの表領域の割当て制限」を参照してください。

ユーザーの表領域の割当て制限

表領域の割当て制限により、ユーザーの表領域に提供される領域の量が決まります。

内容は次のとおりです。

- ユーザーへの表領域の割当て制限の割当てについて

- 表領域の割当て制限を割り当てるためのCREATE USER文

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

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

ユーザーへの表領域割当て制限の割当てについて

各ユーザーには、任意の表領域(一時表領域を除く)に対する表領域割当て制限を設定できます。

割当て制限による影響は、次のとおりです。

- 特定タイプのオブジェクトを作成する権限があるユーザーは、指定した表領域内にオブジェクトを作成できます。

- Oracle Databaseでは、指定した表領域内にあるユーザーのオブジェクトの記憶域に対して割当て可能な領域は、割当て制限以内に制限されます。

デフォルトでは、ユーザーに対するデータベースの表領域の割当て制限はありません。ユーザーがスキーマ・オブジェクトを作成する権限を持っている場合は、このユーザーがオブジェクトを作成できるようにするための割当て制限を割り当てる必要があります。最低でも、ユーザーにはデフォルト表領域の割当て制限と、ユーザーがオブジェクトを作成する他の表領域の追加割当て制限を割り当てます。表領域に割り当てることができる最大領域は2 TBです。より多くの領域が必要な場合は、QUOTA句にUNLIMITEDを指定します。

ユーザーの割当て制限では、各表領域の一定量のディスク領域を個別に割り当てるか、またはすべての表領域のディスク領域を無制限に割り当てるかのどちらかを選択できます。一定量の割当て制限を設定すると、ユーザーのオブジェクトによってデータベースの領域が大量に使用されるのを防止できます。

ユーザーの表領域に対する割当て制限は、ユーザーを作成するときに割り当てることができ、後で割当て制限の追加または変更もできます。(USER_TS_QUOTASビューを問い合せることで、既存ユーザーの割当て制限を確認できます。)新しい割当て制限が古い割当て制限より少ない場合は、次の状況が当てはまります。

- ユーザーがすでに新しい表領域割当て制限を超過している場合は、これらのオブジェクトをあわせた領域が新しい割当て制限より少なくならないかぎり、その表領域のユーザー・オブジェクトに追加の領域を割り当てることはできません。

- ユーザーが新しい表領域割当て制限を超過していない場合、つまり表領域内でユーザーのオブジェクトが使用している領域が新しい表領域割当て制限よりも少ない場合は、そのユーザーのオブジェクトに新しい割当て制限までの領域を割り当てることができます。

表領域の割当て制限を割り当てるためのCREATE USER文

CREATE USER文のQUOTA句は、表領域の割当て制限を割り当てます。

次のCREATE USER文では、test_tsおよびdata_ts表領域に対して次の割当て制限を割り当てています。

CREATE USER jward
IDENTIFIED BY password
DEFAULT TABLESPACE data_ts
QUOTA 500K ON data_ts
QUOTA 100M ON test_ts
TEMPORARY TABLESPACE temp_ts
PROFILE clerk
CONTAINER = CURRENT;

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

現在の割当てがゼロになるように、表領域内のユーザー・オブジェクトに割当て制限を設定できます。

割当て制限を指定するには、ALTER USER SQL文を使用します。

ゼロの割当て制限が割り当てられると、表領域内のユーザーのオブジェクトはそのまま残り、ユーザーは引き続き新規オブジェクトを作成できますが、既存のオブジェクトには新しい領域が割り当てられなくなります。たとえば、このユーザーの既存の表の1つにデータを挿入することはできません。操作は失敗し、 ORA-1536表に対する領域割当て制限を使い果たしました。エラーが発生します。

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

データベース内の表領域を無制限に使用することをユーザーに許可するには、そのユーザーにUNLIMITED TABLESPACEシステム権限を付与します。

UNLIMITED TABLESPACE権限によって、そのユーザーに対する明示的な表領域の割当て制限がすべて置き換えられます。後で権限を取り消す場合、個々の表領域に対して割当て制限を明示的に付与する必要があります。この権限は、ロールに対してではなく、ユーザーに対してのみ付与できます。

UNLIMITED TABLESPACEシステム権限を付与する前に、この方法のメリットとデメリットを考慮してください。

メリット

- データベースのすべての表領域に無制限にアクセスできる権限を1つの文でユーザーに付与できます。

デメリット

- この権限によって、そのユーザーに対する明示的な表領域割当て制限がすべて置き換えられます。

- UNLIMITED TABLESPACEシステム権限を持つユーザーから表領域へのアクセス権を選択的に取り消すことはできません。この権限を取り消した後でのみ、選択的または制限付きアクセス権を付与できます。

ユーザーの一時表領域

一時表領域には、ユーザー・セッションの存続期間中のみ保持される一時データが含まれています。

内容は次のとおりです。

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

- 一時表領域を割り当てるためのTEMPORARY TABLESPACE句

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

各ユーザーには、一時表領域を割り当てる必要があります。

ユーザーが一時セグメントを必要とするSQL文を実行すると、このセグメントはそのユーザーの一時表領域に格納されます。これらの一時セグメントは、ソート操作または結合操作の実行時にシステムによって作成されます。一時セグメントは、すべての表領域のリソースに関する権限を持つSYSが所有します。

一時表領域を作成するには、CREATE TEMPORARY TABLESPACE SQL文を使用できます。

ユーザーの一時表領域を明示的に割り当てない場合、そのユーザーには、データベース作成時に指定された、または作成後にALTER DATABASE文によって指定されたデフォルト一時表領域が割り当てられます。デフォルトの一時表領域が明示的に割り当てられていない場合、デフォルトはSYSTEM表領域またはシステム管理者が設定した別のデフォルト永続表領域になります。一時表領域として使用する表領域を明示的に割り当てることによって、一時セグメントとそれ以外のタイプのセグメントとの間で発生するファイルの競合が解消されます。

注意:

SYSTEM表領域がローカル管理の場合、ユーザーには特定のデフォルト(ローカル管理)一時表領域を割り当てる必要があります。永続的なローカル管理表領域には、一時オブジェクトを格納できないため、SYSTEM表領域の使用はデフォルトで禁止されます。

ユーザー作成時に、そのユーザーの一時表領域を設定しておき、作成後にALTER USER文を使用して変更できます。個々の一時表領域を割り当てるかわりに、表領域グループを設定することもできます。

関連項目:

一時表領域と表領域グループの使用の詳細は、『Oracle Database管理者ガイド』を参照してください。

一時表領域を割り当てるためのTEMPORARY TABLESPACE句

CREATE USER文のTEMPORARY TABLESPACE句で、ユーザーに一時表領域を割り当てます。

次の例では、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
CONTAINER = CURRENT;

ユーザーのプロファイル

プロファイルとは、属性によって定義される、データベース・リソースとそのデータベースへのパスワード・アクセスに関する一連の制限です。

プロファイルを複数のユーザーに適用して、ユーザーがこれらの属性を共有できるようにすることができます。

ユーザーの作成時に、プロファイルを指定できます。CREATE USER文のPROFILE句は、ユーザーにプロファイルを割り当てます。プロファイルを指定しない場合、ユーザーにはデフォルト・プロファイルが割り当てられます。

次に例を示します。

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;

マルチテナント環境では、異なるプロファイルをルートおよびPDBの共通ユーザーに割り当てることができます。共通ユーザーがPDBにログインする場合、設定をセッションに適用するプロファイルは、設定がパスワード関連またはリソース関連のどちらであるかによって異なります。

- パスワード関連のプロファイル設定は、ルートの共通ユーザーに割り当てられるプロファイルからフェッチされます。たとえば、共通プロファイルc##prof(FAILED_LOGIN_ATTEMPTSが1に設定されている)をルートの共通ユーザーc##adminに割り当てるとします。PDBでは、そのユーザーにローカル・プロファイルlocal_prof(FAILED_LOGIN_ATTEMPTSが6に設定されている)が割り当てられます。loc_profが割り当てられているPDBにログインする場合、共通ユーザーc##adminは、1回のログインの失敗のみ許可されます。

- PDBのユーザーに割り当てられているプロファイルに指定されたリソース関連のプロファイル設定は、ルートの共通ユーザーに割り当てられているプロファイルのリソース関連設定を参照せずに使用されます。たとえば、PDBのユーザーc##adminに割り当てられているプロファイルlocal_profでSESSIONS_PER_USERが2に設定されている場合、ルートのこのユーザーに割り当てられているプロファイルのこの設定の値に関係なく、PDB loc_profにログインするときに、c##adminは2回の同時セッションのみが許可されます。

関連項目:

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

共通ユーザーまたはローカル・ユーザーの作成

CREATE USER SQL文を使用して、共通ユーザーとローカル・ユーザーの両方を作成できます。

内容は次のとおりです。

- 共通ユーザー・アカウントの作成について

- 共通ユーザー・アカウントを作成するためのCREATE USER文

- ローカル・ユーザー・アカウントの作成について

- ローカル・ユーザー・アカウントを作成するためのCREATE USER文

関連項目:

Enterprise Managerの共通ユーザーおよびローカル・ユーザーの管理

共通ユーザー・アカウントの作成について

作成できる場所、ネーミング規則、スキーマに保存されるオブジェクトなど、ローカル・ユーザー・アカウントの制限事項に注意してください。

共通ユーザー・アカウントを作成するには、次の規則に従います。

- 共通ユーザーを作成するには、ルートに接続し、共通に付与されるCREATE USERシステム権限が必要です。

- セッションの現在のコンテナがCDB$ROOTである必要があります。

- 共通ユーザーに指定した名前は、C##またはc##で始まり、ASCIIまたはEDCDIC文字のみを含む必要があります。(この要件は、SYSやSYSTEMなど、Oracleから提供された既存のユーザー・アカウントの名前には適用されません。)既存のユーザー・アカウントの名前を確認するには、ALL_USERS、CDB_USERS、DBA_USERSおよびUSER_USERSデータ・ディクショナリ・ビューを問い合せます。

- 共通ユーザーとしてユーザー・アカウントを明示的に指定するには、CREATE USER文で、CONTAINER=ALLを指定します。ルートにログインしている場合に、CREATE USER文からCONTAINER句を省略すると、CONTAINER=ALL句が暗黙のうちに入れられます。

- 共通ユーザーのスキーマにはオブジェクトを作成しないでください。そうすると、接続および切断操作中に問題が発生する場合があります。

- 共通ユーザー・アカウントのCREATE USER文でDEFAULT TABLESPACE、TEMPORARY TABLESPACE、QUOTA...ONおよびPROFILE句を指定する場合、これらのオブジェクト(表領域、表領域グループおよびプロファイル)がCDBのすべてのコンテナに存在することを確認する必要があります。

- 共通ユーザーが所有するユーザー作成のスキーマ・オブジェクトをPDB境界で共有できません。Oracle作成の共通ユーザーによって所有されているスキーマ・オブジェクトは、CDB全体で共有されます。

共通ユーザー・アカウントを作成するためのCREATE USER文

CREATE USER文とCONTAINER句を使用して、共通ユーザー・アカウントを作成できます。共通ユーザー・アカウントを作成するには、ルート内にいる必要があります。

次の例は、CONTAINER句を使用することで共通ユーザー・アカウントを作成し、SET CONTAINERおよびCREATE SESSION権限をユーザーに付与する方法を示しています。共通ユーザーは、コンテナ間を移動するためのこれらの権限が必要です。このアカウントを作成すると、すべてのコンテナでこの共通ユーザーに1つの共通パスワードが作成されます。

CONNECT SYSTEM
Enter password: password
Connected.

CREATE USER c##hr_admin
IDENTIFIED BY password
DEFAULT TABLESPACE data_ts
QUOTA 100M ON test_ts
QUOTA 500K ON data_ts
TEMPORARY TABLESPACE temp_ts
CONTAINER = ALL;

GRANT SET CONTAINER, CREATE SESSION TO c##hr_admin CONTAINER = ALL;

関連項目:

- 「Enterprise Managerの共通ユーザー・アカウントの作成」

- 「共通ユーザーについて」

ローカル・ユーザー・アカウントの作成について

作成できる場所、ネーミング規則、スキーマに保存されるオブジェクトなど、ローカル・ユーザー・アカウントの制限事項に注意してください。

ローカル・ユーザー・アカウントを作成するには、次の規則に従います。

- ローカル・ユーザー・アカウントを作成するには、アカウントを作成するPDBに接続して、CREATE USER権限を持つ必要があります。

- ローカル・ユーザーに指定する名前は、共通ユーザーに予約されている接頭辞(CDB共通ユーザーの場合、デフォルトはC##)で始めることはできません。

- CREATE USER文にCONTAINER=CURRENTを含め、ローカル・ユーザーとしてユーザーを指定できます。PDBに接続しており、この句を省略すると、CONTAINER=CURRENT句が含まれます。

- 共通ユーザーとローカル・ユーザーの名前を同じにすることはできません。ただし、異なるPDBのローカル・ユーザーに同じ名前を使用できます。既存のユーザー・アカウントの名前を確認するには、ALL_USERS、CDB_USERS、DBA_USERSおよびUSER_USERSデータ・ディクショナリ・ビューを問い合せます。

- 適切な権限があれば、PDBに接続されている共通ユーザーとローカル・ユーザーの両方で、ローカル・ユーザー・アカウントを作成できます。

ローカル・ユーザー・アカウントを作成するためのCREATE USER文

CREATE USER文のCONTAINER句を使用して、ローカル・ユーザー・アカウントを作成できます。

ローカル・ユーザー・アカウントは、そのアカウントを配置するPDBに作成する必要があります。

次の例は、CONTAINER句を使用したローカル・ユーザー・アカウントの作成方法を示しています。

CONNECT SYSTEM@hrpdb
Enter password: password
Connected.

CREATE USER kmurray
IDENTIFIED BY password
DEFAULT TABLESPACE data_ts
QUOTA 100M ON test_ts
QUOTA 500K ON data_ts
TEMPORARY TABLESPACE temp_ts
PROFILE hr_profile
CONTAINER = CURRENT;

関連項目:

- Enterprise Managerの共通ユーザー・アカウントの作成

- ローカル・ユーザーについて

ユーザーのデフォルト・ロールの作成

デフォルト・ロールは、ユーザーがセッションを作成したときに、自動的にそのユーザーに対して使用可能になります。

ユーザーには複数のデフォルト・ロールを割り当てることができますが、割り当てなくてもかまいません。CREATE USER文ではユーザーのデフォルト・ロールを設定できません。ユーザーを最初に作成すると、ユーザーのデフォルト・ロール設定はALLであり、ユーザーにその後に付与されるすべてのロールがデフォルト・ロールになります。

- ALTER USER文を使用して、ユーザーのデフォルト・ロールを変更します。

次に例を示します。

GRANT USER rdale clerk_mgr;

ALTER USER rdale DEFAULT ROLE clerk_mgr;

ロールをユーザーのデフォルト・ロールにするには、そのロールがユーザーに付与されている必要があります。

関連項目:

ユーザー・ロールの管理

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

ALTER USER文を使用して、ユーザー・アカウントを変更できます(そのデフォルト表領域やプロファイルの変更など)。さらに、ユーザーは、ユーザーのパスワードを変更できます。

内容は次のとおりです。

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

- 共通またはローカル・ユーザー・アカウントを変更するためのALTER USER文

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

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

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

ユーザーのセキュリティ設定の変更は、現行セッションではなく、それより後のユーザー・セッションから反映されます。

ほとんどの場合、ユーザーのセキュリティ設定を変更するには、ALTER USER SQL文を使用します。ユーザーは、自分のパスワードを変更できます。ただし、ユーザーのセキュリティ・ドメインの他のオプションを変更するには、ALTER USERシステム権限が必要です。通常は、セキュリティ管理者のみがこのシステム権限を持ちます。これは、この権限によってすべてのユーザーのセキュリティ・ドメインを変更できるためです。この権限には、データベースの任意の表領域に対するユーザーの表領域割当て制限を設定する許可が含まれています。これは、変更を実行するユーザーが、指定した表領域に対する割当て制限を持っていない場合も同じです。

マルチテナント環境で共通ユーザー・アカウントを変更するには、共通に付与されるALTER USERシステム権限が必要です。ローカル・ユーザー・アカウントを変更するには、ローカル・ユーザー・アカウントが存在するPDB内で、共通に付与されるALTER USER権限またはローカルに付与されるALTER USER権限が必要です。

共通またはローカル・ユーザー・アカウントを変更するためのALTER USER文

ALTER USER文で、共通およびローカル・ユーザー・アカウントの両方を変更できます。

既存の共通ユーザー・アカウントをローカル・ユーザー・アカウントに変更でき、その逆も同様です。この場合は、共通ユーザー・アカウントまたはローカル・ユーザー・アカウントとして、新しいアカウントを作成する必要があります。

次の例は、ALTER USER文を使用して、ユーザーc##hr_adminがV$SESSION行を表示する機能を、接続先がCDB$ROOTならびにemp_dbおよびhr_db PDBであるセッションに関連するものに制限する方法を示しています。

CONNECT SYSTEM
Enter password: password
Connected.

ALTER USER c##hr_admin
DEFAULT TABLESPACE data_ts
TEMPORARY TABLESPACE temp_ts
QUOTA 100M ON data_ts
QUOTA 0 ON test_ts
SET CONTAINER_DATA = (emp_db, hr_db) FOR V$SESSION
CONTAINER = CURRENT;

このALTER USER文によって、ユーザーc##hr_adminのセキュリティ設定は次のように変更されます。

- DEFAULT TABLESPACEおよびTEMPORARY TABLESPACEは、data_tsおよびtemp_tsにそれぞれ明示的に設定されます。

- QUOTA 100Mは、data_ts表領域に100MBを提供します。

- QUOTA 0は、temp_ts表領域の割当て制限を取り消します。

- SET CONTAINER_DATAは、ユーザーc##hr_adminがemp_dbおよびhr_db PDBに関するデータにアクセスすることを可能にし、このユーザーがルートからV$SESSIONビューを問い合せる場合はルートに関するデータアクセスすることを可能にします。

関連項目:
SET CONTAINER_DATA句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

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

ユーザーは、自身のパスワードを変更できますが、他のユーザーのパスワードを変更するには、正しい権限が必要です。

内容は次のとおりです。

- SYS以外のユーザーのパスワードの変更について

- PASSWORDコマンドまたはALTER USER文を使用したパスワードの変更

SYS以外のユーザーのパスワードの変更について

ユーザーは、PASSWORDコマンドまたはALTER USER文を使用してパスワードを変更できます。

ユーザーが自分のパスワードを変更するには、特別な権限(データベースへの接続およびセッションの作成権限以外)は不要です。ユーザーには、自分のパスワードを頻繁に変更することを薦めてください。パスワードを保護する最適な方法に関するガイドラインは、パスワードの保護に関するガイドラインを参照してください。ALL_USERSビューを問い合せることで、現行データベース・インスタンスの既存のユーザーを検索できます。

セキュリティを強化するには、PASSWORDコマンドを使用してアカウントのパスワードを変更します。ALTER USER文では、新規パスワードが画面に表示されるため、他者に見られる可能性があります。PASSWORDコマンドでは新規パスワードが表示されないため、自分のみが把握し、他者に知られることはありません。どちらの場合も、パスワードはネットワーク上で暗号化されます。

ユーザーが認証方式を切り替えるには、PASSWORDとALTER USER権限が必要です。通常、この権限を持つのは管理者のみです。

関連項目:

- パスワードを作成するための最低要件は、「パスワードの最低要件」を参照してください。

- パスワードを保護する別の方法については、「パスワードの保護に関するガイドライン」を参照してください。

- Oracle Databaseユーザーが使用できる認証方式の詳細は、認証の構成を参照してください

PASSWORDコマンドまたはALTER USER文を使用したパスワードの変更

ほとんどのユーザーが、SQL*PlusのPASSWORDコマンドまたはALTER USER SQL文を使用して自身のパスワードを変更できます。

マルチテナント環境では、共通ユーザーは自分のパスワードをルートで変更する必要があります。

- 次のいずれかの方法を使用して、ユーザーのパスワードを変更します。

- SQL*PlusのPASSWORDコマンドを使用してパスワードを変更するには、ユーザーの名前を指定し、プロンプトが表示された場合は新しいパスワードを入力します。
次に例を示します。

PASSWORD andy
Changing password for andy
New password: password
Retype new password: password

- ALTER USER SQL文を使用してパスワードを変更するには、IDENTIFIED BY句を指定します。
次に例を示します。

ALTER USER andy IDENTIFIED BY password;

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

SYSユーザーのパスワードを変更するには、ORAPWDコマンドライン・ユーティリティを使用する必要があります。

内容は次のとおりです。

- SYSユーザーのパスワードの変更について

- SYSユーザーのパスワードを変更するためのORAPWDユーティリティ

SYSユーザーのパスワードの変更について

ORAPWDコマンドライン・ユーティリティで、SYSユーザー・パスワードが格納された新しいパスワード・ファイルを作成できます。

次のことに注意してください。

- SYSユーザー・アカウントは、ほとんどの内部再帰的SQLが使用します。そのため、ALTER USER文を使用してこのパスワードを変更しようとするときにデータベースがオープンしていると、デッドロックが生じる可能性があります。

- ALTER USERを使用してSYSユーザー・パスワードを変更しようとする場合に、インスタンス初期化パラメータREMOTE_LOGIN_PASSWORDFILEがSHAREDに設定されていると、SYSパスワードを変更できません。ALTER USER文は、ORA-28046: SYSのパスワードは変更できませんのエラーで失敗します。

- 新しいアカウントは、SHA-2 (SHA-512)ベリファイアで作成されます。DBA_USERSデータ・ディクショナリ・ビューのPASSWORD_VERSIONS列を問い合せて、これらのアカウントを識別できます。(これらのパスワード・バージョンは、ビューの出力に12Cとしてリストされます。)このベリファイアが大きすぎて元のパスワード・ファイル形式に合わないため、ORAPWDコマンドのformat=12引数を使用して、パスワード・ファイルを拡張形式で作成する必要があります。そうしないと、PASSWORDコマンドを使用してSYSパスワードを変更しようとする場合、ORA-28017: パスワード・ファイルが拡張形式ではありません。エラーが表示されます。

- Oracle Real Application Clusters (Oracle RAC)環境では、複数のOracle RACインスタンスで共有できるように、パスワードをASMディスク・グループに格納してください。

関連項目:

- パスワードのセキュリティへの脅威からの12Cパスワード・バージョンによる保護

- orapwdコマンド構文と引数の詳細は、『Oracle Database管理者ガイド』を参照してください。

SYSユーザーのパスワードを変更するためのORAPWDユーティリティ

ORAPWDユーティリティでは、SYSユーザーのパスワードを変更できます。

ORAPWDユーティリティでFILEパラメータを使用して、SYSユーザーのパスワードを変更できます。次の例では、orapworclと呼ばれるパスワード・ファイルに格納される新しいSYSパスワードの作成方法を示しています。(このパスワード・ファイルがすでに存在する場合は、 OPW-00005: 同一名のファイルがあります。 - 削除または名前を変更してください。のエラーにより他の名前を選択するように警告されます。既存のパスワード・ファイルを上書きする場合は、force=y引数をORAPWDコマンドに追加してください。)

orapwd file='orapworcl' force=y
Enter password for SYS: new_password

パスワード・ファイルを移行する場合、現在のパスワード・ファイルを指定するためにinput_fileパラメータを含める必要があります。データベースが開いている間にユーザーがALTER USER文を使用してこのパスワードを変更しようとする場合のデッドロックの発生を防ぐには、sysオプションをyに設定します。次に例を示します。

orapwd input_file='orapworcl' file='orapwd' sys=y force=y
Enter password for SYS: new_password

関連項目:

ORAPWDユーティリティの詳細は、『Oracle Database管理者ガイド』を参照してください。

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

リソースの制限により、ユーザーに利用可能なシステム・リソースの量が決まります。

内容は次のとおりです。

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

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

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

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

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

ユーザーのセキュリティ・ドメインの一部として、各ユーザーが使用できるシステム・リソースの容量に制限を設定できます。

そうすることで、CPUタイムなど貴重なシステム・リソースが無制限に消費されることを防ぐことができます。

このリソース制限機能は、システム・リソースに多額の費用がかかる大規模なマルチ・ユーザー・システムでは非常に有効です。1人以上のユーザーが過度にリソースを使用すると、データベースの他のユーザーに有害な影響を与える可能性があります。シングル・ユーザー・データベースや小規模なマルチ・ユーザー・データベースの場合は、ユーザーがシステム・リソースを消費しても影響は少ないため、システム・リソース機能はそれほど重要ではありません。

ユーザーのリソース制限は、データベース・リソース・マネージャを使用して管理します。パスワード管理の作業環境は、ユーザーごとに個別にプロファイルを使用して設定するか、または多数のユーザー用のデフォルト・プロファイルを使用して設定できます。それぞれのOracleデータベースに指定できるプロファイルの数に、制限はありません。Oracle Databaseでは、セキュリティ管理者が、プロファイルによるリソース制限の規定を全体的に使用可能または使用禁止に設定できます。

リソース制限を設定すると、ユーザーによるセッション作成時に、パフォーマンスがわずかに低下します。これは、各ユーザーがデータベースに接続した時点で、そのユーザーのすべてのリソース制限データがロードされるためです。

関連項目:

リソース制限の設定の詳細は、『Oracle Database管理者ガイド』を参照してください

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

Oracle Databaseでは、CPUタイムや論理読取りなど様々なタイプのシステム・リソースの使用を制限できます。一般にこれらの各リソースを、セッション・レベル、コール・レベルまたは両方のレベルで制御できます。

内容は次のとおりです。

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

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

- CPU時間の制限

- 論理読取りの制限

- その他のリソースの制限

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

ユーザーがデータベースに接続すると、セッションが作成されます。セッションではCPU時間とメモリーが使用されますが、これらに制限を設定できます。

複数のリソース制限をセッション・レベルで設定できます。ユーザーがセッション・レベルのリソース限度を超えると、Oracle Databaseは現在の文を終了(ロールバック)して、セッション限度に達したことを示すメッセージを返します。この時点で、カレント・トランザクションのそれ以前の文のすべてがそのまま残り、ユーザーが実行できる操作のみがCOMMIT、ROLLBACK、または切断になります(この場合、カレント・トランザクションはコミットされます)。他のすべての操作はエラーになります。トランザクションがコミットまたはロールバックされた後も、ユーザーはこれ以上の作業をカレント・セッション中は完了できません。

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

ユーザーがSQL文を実行するたびに、Oracle Databaseでは、いくつかのステップが実行され文が処理されます。

SQL文の処理では、データベースに対して複数のコールが異なる実行フェーズの一部として発行されます。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セッション中に実行されるブロック読取りの数として設定し、測定されます。

その他のリソースの制限

ユーザーの同時セッション数やアイドル時間に制限を設定できます。

その他のリソースの制限を次に示します。

- ユーザー当たりの同時実行セッション数の制限。各ユーザーは、事前に定義された数まで同時実行セッションを作成できます。

- セッションのアイドル時間の制限。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)のモニター機能、特に統計モニターを使用して収集できます。

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

プロファイルとは、ユーザーのデータベース使用とインスタンス・リソースを制限する一連のリソース制限およびパスワード・パラメータに名前を付けたものです。

内容は次のとおりです。

- プロファイルについて

- プロファイルの作成

- ユーザーへのプロファイルの割当て

- プロファイルの削除

プロファイルについて

プロファイルは、ユーザーに適用される属性の集合で、それらの属性を共有する複数ユーザーの中の任意のユーザーに関する単一の参照になります。

Oracle Internet Directoryのユーザー・プロファイルには、各ユーザーのディレクトリ使用と認証に関連した属性が含まれています。同様に、Oracle Label Securityのプロファイルには、Oracle Label Securityのユーザー管理や操作管理に役立つ属性が含まれています。プロファイル属性にはシステム・リソースに関する制限を含めることができます。データベース・リソース・マネージャを使用すると、これらのタイプのリソース制限を設定できます。

ユーザーごとにプロファイルを割り当てたり、すべてのユーザーにデフォルトのプロファイルを割り当てる必要があります。各ユーザーに割り当てることができるプロファイルは1つのみで、新しいプロファイルを作成すると、旧バージョンと置き換えられます。ユーザー・プロファイルを作成して管理する必要があるのは、リソース制限がデータベースのセキュリティ・ポリシーの要件である場合のみです。プロファイルを使用するには、最初にデータベース内のユーザーの関連タイプを分類します。ロールを使用して関連ユーザーの権限を管理するのと同様に、プロファイルを使用して関連ユーザーのリソース制限を管理します。データベース内のすべてのタイプのユーザーを含めるために必要なプロファイル数を決定してから、プロファイルごとに適切なリソース制限を決定します。

プロファイルのリソース制限が適用されるのは、対応するデータベースのリソース制限が使用可能な場合のみです。このリソース制限が使用可能になるのは、データベースの起動前(RESOURCE_LIMIT初期化パラメータを使用)またはオープン中(ALTER SYSTEM文を使用)のいずれかです。

パスワード・パラメータはプロファイル内にありますが、RESOURCE_LIMITまたはALTER SYSTEMの影響は受けず、パスワード管理は常に使用可能です。Oracle Databaseでは、主にデータベース・リソース・マネージャによって、リソースの割当てと制限が処理されます。

認可されたデータベース・ユーザーは、プロファイルの作成、ユーザーへの割当て、変更および削除を(CREATE USERまたはALTER USER文を使用して)随時実行できます。プロファイルは、ロールや他のプロファイルではなく、ユーザーにのみ割り当てることができます。プロファイルの割当ては現行のセッションには影響を与えず、それより後のセッションにのみ有効です。

現行のプロファイルに関する情報を検索するには、DBA_PROFILESビューを問い合せます。

関連項目:

- リソース管理の詳細は、『Oracle Database管理者ガイド』を参照してください

- リソース情報の表示の詳細は、「データベース・ユーザーおよびプロファイルのデータ・ディクショナリ・ビュー」を参照してください

- ALTER SYSTEMファンクションの詳細は、『Oracle Database SQL言語リファレンス』を参照

- RESOURCE_LIMITの詳細は、『Oracle Databaseリファレンス』を参照してください

プロファイルの作成

プロファイルには、パスワードの制限やリソースの制限など、特定のカテゴリに対する制限が含まれます。

プロファイルを作成する場合、CREATE PROFILEシステム権限が必要です。すべての既存のプロファイルを検索するには、DBA_PROFILESビューを問い合せます。

- プロファイルを作成するには、CREATE PROFILE文を使用します。

たとえば、パスワードの制限を定義するプロファイルを作成するとします。

CREATE PROFILE password_prof LIMIT
FAILED_LOGIN_ATTEMPTS 6
PASSWORD_LIFE_TIME 60
PASSWORD_REUSE_TIME 60
PASSWORD_REUSE_MAX 5
PASSWORD_LOCK_TIME 1/24
PASSWORD_GRACE_TIME 10
PASSWORD_VERIFY_FUNCTION DEFAULT;

次の例は、リソース制限プロファイルの作成方法を示しています。

CREATE PROFILE app_user LIMIT
SESSIONS_PER_USER          UNLIMITED
CPU_PER_SESSION            UNLIMITED
CPU_PER_CALL               3500
CONNECT_TIME               50
LOGICAL_READS_PER_SESSION  DEFAULT
LOGICAL_READS_PER_CALL     1200
PRIVATE_SGA                20K
COMPOSITE_LIMIT            7500000;

関連項目:

CREATE PROFILE SQL文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ユーザーへのプロファイルの割当て

プロファイルの作成後、ユーザーにプロファイルを割り当てることができます。

すでにプロファイルを割り当てられているユーザーにプロファイルを割り当てることはできますが、直近に割り当てられたプロファイルが優先されます。外部ユーザーまたはグローバル・ユーザーにプロファイルを割り当てる場合、パスワードのパラメータは、そのユーザーに対して有効ではありません。

ユーザーに現在割り当てられているプロファイルを検索するには、DBA_USERSビューを問い合せます。

- ALTER USER文を使用して、ユーザーにプロファイルを割り当てます。

次に例を示します。

ALTER USER psmith PROFILE app_user;

プロファイルの削除

プロファイルは、現在ユーザーに割り当てられている場合でも削除できます。

プロファイルを削除しても、現在アクティブなセッションに影響はありません。プロファイルの削除後に作成されたセッションのみが、変更されたプロファイル割当てを使用します。プロファイルを削除するには、DROP PROFILEシステム権限が必要です。デフォルトのプロファイルは削除できません。

- プロファイルを削除するには、SQL文のDROP PROFILEを使用します。ユーザーに現在割り当てられているプロファイルを削除するには、CASCADEオプションを使用します。

次に例を示します。

DROP PROFILE clerk CASCADE;

削除するプロファイルに現在割り当てられているユーザーは、自動的にDEFAULTプロファイルに割り当てられます。DEFAULTプロファイルは削除できません。

関連項目:

DROP PROFILE SQL文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

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

ユーザーがユーザー・セッションにログインしていない場合、ユーザー・アカウントを削除できます。ユーザーを削除する場合、そのユーザーのスキーマに関連付けられているオブジェクトも削除されます。

内容は次のとおりです。

- ユーザー・アカウントの削除について

- ユーザー・セッションの終了

- ユーザーがデータベースから切断した後のユーザーの削除について

- スキーマにオブジェクトが含まれるユーザーの削除

ユーザー・アカウントの削除について

ユーザー・アカウントを削除する前に、削除に適した権限があることを確認する必要があります。

いずれの環境でユーザー・アカウントを削除する場合でも、DROP USERシステム権限が必要です。マルチテナント環境で共通ユーザー・アカウントを削除するには、共通に付与されるDROP USERシステム権限が必要です。ローカル・ユーザー・アカウントを削除するには、ローカル・ユーザー・アカウントが存在するPDB内で、共通に付与されるDROP USER権限またはローカルに付与されるDROP USER権限が必要です。

ユーザー・アカウントを削除すると、Oracle Databaseではこのユーザー・アカウントおよび対応するスキーマがデータ・ディクショナリから削除されます。さらに、ユーザー・スキーマに含まれているすべてのスキーマ・オブジェクトも(存在する場合)削除されます。

注意:

- ユーザーのスキーマとそれに対応するオブジェクトは残したままで、データベースへのアクセスを拒否する場合は、そのユーザーからCREATE SESSION権限を取り消してください。

- SYSユーザーまたはSYSTEMユーザーは削除しないでください。これらのユーザーを削除すると、データベースが破損します。

ユーザー・セッションの終了

データベースに接続されているユーザーは削除できません。

ユーザーを削除する前に、まずユーザー・セッションを終了する必要があります(または、ユーザーがセッションを終了できます)。

1. V$SESSION動的ビューを問い合せて、セッションを終了するユーザーのセッションIDを確認します。

次に例を示します。

SELECT SID, SERIAL#, USERNAME FROM V$SESSION;

SID         SERIAL# USERNAME
------- --------------- ----------------------
127          55234  ANDY
...

2. ALTER SYSTEM SQL文を使用して、V$SESSIONビューのSID設定とSERIAL#設定に基づき、ユーザーのセッションを終了します。

次に例を示します。

ALTER SYSTEM KILL SESSION '127, 55234';

関連項目:

セッションの終了の詳細は、『Oracle Database管理者ガイド』を参照してください。

ユーザーがデータベースから切断した後のユーザーの削除について

ユーザーがデータベースから切断した後に、DROP USER文を使用してユーザーを削除できます。

ユーザーとそのユーザーのスキーマ・オブジェクト(ある場合)をすべて削除するには、DROP USERシステム権限が必要です。DROP USERシステム権限は強力な権限であるため、通常はセキュリティ管理者のみがこの権限を持ちます。

ユーザーのスキーマに依存型のスキーマ・オブジェクトが含まれている場合に、ユーザーと対応付けられているすべてのオブジェクト、およびそのユーザーの表に依存している外部キーをすべて削除するには、CASCADEオプションを使用します。CASCADEを指定していない場合は、ユーザーのスキーマに依存型のオブジェクトが含まれていると、エラー・メッセージが戻され、ユーザーは削除されません。

スキーマにオブジェクトが含まれるユーザーの削除

スキーマ内にオブジェクトを格納しているユーザーを削除する前に、スキーマ・オブジェクトを削除した場合の影響を徹底的に調べます。

1. DBA_OBJECTSデータ・ディクショナリ・ビューを問い合せて、ユーザーが所有するオブジェクトを確認します。

次に例を示します。

SELECT OWNER, OBJECT_NAME FROM DBA_OBJECTS WHERE OWNER LIKE 'ANDY';

ユーザー名は大文字で入力します。事前に認識できない連鎖的な影響に注意してください。たとえば、表を所有するユーザーを削除する場合は、ビューまたはプロシージャがその表に依存していないかどうかを確認してください。

2. ユーザーとすべての関連オブジェクト、およびそのユーザーが所有する表に依存する外部キーを削除するには、DROP USER SQL文とCASCADE句を使用します。

次に例を示します。

DROP USER andy CASCADE;

データベース・ユーザーおよびプロファイルのデータ・ディクショナリ・ビュー

Oracle Databaseには、ユーザーとプロファイルの作成に使用した設定の情報を提供する、一連のデータ・ディクショナリ・ビューがあります。

内容は次のとおりです。

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

- すべてのユーザーと関連情報を検索する問合せ

- すべての表領域の割当て制限を表示する問合せ

- すべてのプロファイルと割り当てられている制限を表示する問合せ

- 各ユーザー・セッションのメモリー使用量を表示する問合せ

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

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 example
TEMPORARY TABLESPACE temp
QUOTA 500K ON example
PROFILE clerk
CONTAINER = CURRENT;

CREATE USER dcranney
IDENTIFIED BY password
DEFAULT TABLESPACE example
TEMPORARY TABLESPACE temp
QUOTA unlimited ON example
CONTAINER = CURRENT;

CREATE USER userscott
IDENTIFIED BY password
CONTAINER = CURRENT;

すべてのユーザーと関連情報を検索する問合せ

DBA_USERSデータ・ディクショナリ・ビューには、データベースで定義されているすべてのユーザーとその関連情報が表示されます。

DBA_USERSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

次に例を示します。

col username format a11
col profile format a10
col account_status format a19
col authentication_type format a29

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
----------    ---------  --------   ----------   -------   ----------
EXAMPLE       JFEE              0       512000         0          250
EXAMPLE       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のデータベース・ユーザーと非データベース・ユーザーの両方を認証できます。簡潔性を考慮して、すべてのデータベース・ユーザーに同じ認証方式を使用するのが一般的ですが、Oracle Databaseでは1つのデータベース・インスタンスで一部またはすべての方法を使用できます。Oracle Databaseでは、データベース管理者が特別なデータベース操作を実行するため、そのための特別な認証プロシージャが必要です。また、Oracle Databaseでは、ネットワーク認証のセキュリティを確保するために送信時にパスワードの暗号化も実行されます。

認証後は、認可プロセスでそのエンティティが実行できるアクセスとアクションのレベルを許可または制限できます。認可については、「権限とロール認可の構成」を参照してください。

パスワード保護の構成

ユーザーのパスワードは様々な方法で保護できます。たとえば、パスワードの作成要件の制御、パスワード管理ポリシーの使用などの方法があります。

内容は次のとおりです。

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

- パスワードの最低要件

- IDENTIFIED BY句を使用したパスワードの作成

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

- パスワードの複雑度の管理

- パスワードでの大/小文字の区別の管理

- パスワードのセキュリティへの脅威からの12Cパスワード・バージョンによる保護

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

関連項目:

- パスワードの保護に関するガイドラインは、パスワードの保護に関するガイドラインを参照してください

- パスワードを暗号化してユーザーを認証するようにOracle XML DBを構成するとき、他のデータは暗号化する必要がない場合(例: イントラネットの電子メール)の詳細は、『Oracle XML DB開発者ガイド』を参照してください

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

Oracle Databaseでは、ユーザーのパスワードを保護するように設計された組込みパスワード保護が提供されています。

提供されるパスワード保護は、次のとおりです。

- パスワード暗号化。Oracle Databaseでは、Advanced Encryption Standard(AES)を使用して、ネットワーク(クライアントとサーバー間、双方のサーバー間)接続中にパスワードを自動的かつ透過的に暗号化し、その後ネットワーク経由で送信します。ただし、SQL文内で指定されたパスワード(例: CREATE USER user_name IDENTIFIED BY password;)は、ネットワーク・トレース・ファイル内のクリアテキストでネットワーク経由で送信されます。このため、アドバンスト・セキュリティ・オプションのネイティブ・ネットワーク暗号化を有効にするか、Secure Sockets Layer (SSL) 暗号化を構成する必要があります。

- パスワードの複雑度のチェック。デフォルトのインストールでは、Oracle Databaseには、ora12c_verify_functionおよびora12c_strong_verify_functionパスワード検証ファンクションがあります。これらの機能では、新しいパスワードや変更されたパスワードの複雑性が十分であり、パスワードを推測してシステムに侵入しようとする侵入者を防ぐことができるかどうかを確認します。パスワードの複雑性チェックを手動で有効にする必要があります。さらに、ユーザーのパスワードの複雑度はカスタマイズできます。詳細は、「パスワードの複雑度検証の概要」を参照してください。

- パスワード突破の防止。ユーザーが誤ったパスワードを使用してOracle Databaseへのログインを複数回試行した場合、Oracle Databaseによってログインが1秒ずつ遅延されます。この保護は、異なるIPアドレスまたは複数のクライアント接続からのログインに適用されます。この機能により、侵入者がログインを試みるときに一定時間内に試すことができるパスワードの数が大幅に減少します。ログイン失敗による遅延によって、各ログイン試行の失敗にかかる時間が延び、(通常、こうした攻撃では非常に多くの試行に失敗せざるを得ないため)パスワード推測攻撃全体にかかる時間が増加します。
非管理ログインの場合、Oracle Databaseは、ログイン失敗による遅延に対して排他ロックを設定することによって、同時パスワード推測攻撃からデータを保護します。これによって、侵入者がログイン失敗による遅延を回避しようとする(最初の推測に失敗して遅延された後すぐに別のデータベース・セッションで次の同時推測を試行した場合)のを阻止します。侵入者は、このタイプの同時パスワード推測攻撃に対してサーバー使用率を利用します。サーバーを制圧せずに、すべてのCPUリソースを使い果たします。この結果、侵入者が未検出のままになると同時に、侵入者は1秒間に可能なかぎり多くの同時推測を実行できます。

攻撃対象のアカウントに対して排他ロックを保持することによって、Oracle Databaseでは同時パスワード推測攻撃が緩和されますが、同時にそのアカウントはサービス拒否(DoS)攻撃を受けやすいままになります。この問題に対処するには、FAILED_LOGIN_ATTEMPTSパラメータがUNLIMITEDに設定されたパスワード・プロファイルを作成し、このパスワード・プロファイルをそのユーザー・アカウントに適用する必要があります。FAILED_LOGIN_ATTEMPTSパラメータの設定によって、ログイン失敗による遅延は実施されず、ログイン試行失敗回数は制限されません。このようなタイプのアカウントについては、長いランダムなパスワードを使用することをお薦めします。

同時パスワード推測攻撃の保護は、管理ユーザー接続には適用されません。これは、このような接続は常に使用可能な状態である必要があり、サービス拒否攻撃の影響を受けない必要があるためです。したがって、すべての管理権限アカウントに対して長いパスワードを選択することをお薦めします。

- パスワードでの大/小文字の区別の規定。パスワードは大/小文字が区別されます。たとえば、パスワードがhPP5620qrの場合、hpp5620QRまたはhPp5620Qrと入力すると失敗します。パスワードでの大/小文字の区別、およびパスワード・ファイルやデータベース・リンクへの影響については、「パスワードでの大/小文字の区別の管理」を参照してください。

- 12Cパスワード・バージョンを使用したパスワードのハッシュ化。ユーザーのパスワードを検証し、パスワード作成で大/小文字の区別を適用するために、12Cパスワード・バージョンが使用されていて、これは、パスワードベースの鍵導出関数(PBKDF2)およびSHA-512暗号化ハッシュ関数を含む非最適化されたアルゴリズムに基づいています。「パスワードのセキュリティへの脅威からの12Cパスワード・バージョンによる保護」を参照してください。

パスワードの最低要件

パスワードに関する最低要件のセットが提供されています。

パスワードは30バイト以内にする必要があります。パスワードを保護するには、パスワードが適切な長さになるよう要求することから、サイトで適用されるパスワード複雑度ポリシー要件を強制するカスタムのパスワード複雑度検証スクリプトの作成まで、様々な方法があります。「パスワードの保護に関するガイドライン」で説明する追加ガイドラインを参照してください。

IDENTIFIED BY句を使用したパスワードの作成

IDENTIFIED BY句を受け入れるSQL文でもパスワードを作成できます。

- ユーザーのパスワードを作成するには、CREATE USER、ALTER USER、GRANT CREATE SESSIONまたはCREATE DATABASE LINK SQL文を使用します。

次のSQL文は、IDENTIFIED BY句でパスワードを作成します。

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;

関連項目:
パスワードがサイトに対して十分な複雑度を備えていることを確認する方法は、パスワードの複雑度検証の概要を参照してください

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

パスワード管理ポリシーで、ユーザーのパスワードの安全性を強化できる一連の制限事項を作成して実施できます。

内容は次のとおりです。

- パスワード管理の概要

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

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

- ALTER PROFILE文を使用したプロファイル制限の設定

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

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

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

- ユーザー・アカウントの明示的ロック

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

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

- CREATE PROFILE文またはALTER PROFILE文を使用したパスワード存続期間の設定

- ユーザー・アカウントのステータスの確認

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

- PASSWORD_LIFE_TIMEプロファイル・パラメータの低い値

関連項目:

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

- この項で説明するSQL文の構文および各文に固有の情報は、『Oracle Database SQL言語リファレンス』を参照してください

パスワード管理の概要

パスワードに依存しているデータベース・セキュリティ・システムでは、パスワードの機密を常に保つ必要があります。

パスワードは盗難や悪用などの被害を受けやすいため、Oracle Databaseではパスワード管理ポリシーが使用されています。データベース管理者およびセキュリティ管理者がユーザー・プロファイルを介してパスワード管理ポリシーを制御することで、データベース・セキュリティの管理を強化できます。

ユーザー・プロファイルの作成には、CREATE PROFILE文が使用できます。プロファイルは、CREATE USERまたはALTER USER文を使用してユーザーに割り当てます。

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

DBA_USERS_WITH_DEFPWDデータ・ディクショナリ・ビューで、デフォルトのパスワードを使用するユーザー・アカウントを確認できます。

データベースを作成すると、ほとんどのデフォルト・アカウントは、パスワードが期限切れのためロックされます。以前のリリースのOracle Databaseからアップグレードした場合は、デフォルト・パスワードが設定されているユーザー・アカウントが存在している可能性があります。それらは、データベースの作成時に作成されたデフォルト・アカウント(HR、OE、SCOTTアカウントなど)です。

セキュリティを強化するために、それらのアカウントのパスワードを変更してください。周知されているデフォルト・パスワードを使用すると、データベースが侵入者から攻撃を受けやすくなります。

1. SYSDBA管理権限を持つSQL*Plusを使用して、データベース・インスタンスにログインします。

例:

sqlplus sys as sysdba
Enter password: password

2. 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

3. 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

パスワードを再利用できない日数を設定します。

詳細は、ユーザーによる以前のパスワードの再利用の制御を参照してください。

ALTER PROFILE文を使用したプロファイル制限の設定

ログイン試行の失敗、パスワードのロック回数、パスワードの再利用、その他の設定などのプロファイルの制限を変更できます。

これらの設定については、表3-1で説明されています。セキュリティを強化するために、必要に応じて、この表に示すデフォルト設定を使用してください。

- ALTER PROFILE文を使用して、ユーザーのプロファイル制限を変更します。

例:

ALTER PROFILE prof LIMIT
FAILED_LOGIN_ATTEMPTS 9
PASSWORD_LOCK_TIME 10;

関連項目:

- CREATE PROFILE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- ALTER PROFILE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- この項で説明しているパスワード関連パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

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

Oracleは、デフォルトのパスワード・セキュリティ設定を無効化および有効化するために使用できるスクリプトを提供しています。

Oracle Database 10g リリース2 (10.2)のデフォルトのパスワード・セキュリティ設定を使用するアプリケーションがある場合は、Oracle Database 11g以降のデフォルトのパスワード・セキュリティ設定を使用するようにアプリケーションを変更するまで、デフォルトの設定を元に戻すことができます。

1. Oracle Database 11g以降のパスワード・セキュリティ設定に準拠するように、アプリケーションを変更します。

2. 次のいずれかの方法で、ビジネス・ニーズに合うセキュリティ構成を使用するようにデータベースを更新します。

- データベース・セキュリティ構成を手動で更新します。

- secconf.sqlスクリプトを実行して、Oracle Database 11g以降のデフォルトのパスワード設定を適用します。必要に応じて、異なるセキュリティ設定を使用するようにこのスクリプトをカスタマイズできますが、元のスクリプトにリストされている設定は、Oracle推奨の設定であることに注意してください。

データベースを手動で作成した場合は、secconf.sqlスクリプトを実行して、Oracleのデフォルトのパスワード設定をデータベースに適用する必要があります。Database Configuration Assistant(DBCA)を使用して作成されたデータベースではこの設定が使用されますが、手動で作成したデータベースでは使用されません。

secconf.sqlスクリプトは$ORACLE_HOME/rdbms/adminディレクトリにあります。secconf.sqlスクリプトはパスワード設定と監査設定の両方に影響を与えます。他のセキュリティ設定には影響しません。

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

Oracle Databaseでは、ログイン試行に指定の回数だけ連続して失敗した後、ユーザーのアカウントをロックできます。

- 指定した時間間隔が経過した後で自動的にユーザー・アカウントをロックするか、またはロックを解除するためにデータベース管理者の介入を必要とするには、CREATE PROFILE文またはALTER PROFILE文でユーザーのPASSWORD_LOCK_TIMEプロファイル・パラメータを設定します。
たとえば、次に時間間隔を10日に設定します。

PASSWORD_LOCK_TIME = 10

次のことに注意してください。

- また、データベース管理者が明示的に解除する必要があるように、手動でアカウントをロックすることもできます。

- ログインの失敗が許容される回数は、CREATE PROFILE文を使用して指定します。また、アカウントがロックされる時間の長さも指定できます。

- ユーザーがログインに失敗するたびに、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でない場合)。

- マルチテナント環境では、ロックされた共通ユーザー・アカウントがルート内のすべてのPDBでロックされるようになります。

例: CREATE PROFILE文を使用したアカウントのロック

CREATE PROFILE文で、ユーザーのログイン試行がCREATE PROFILE設定に違反した場合にユーザー・アカウントをロックできます。

例3-1では、ユーザーjohndoeに対して許容されているログイン失敗の最大回数は10回(デフォルト)、アカウントがロックされる時間の長さは30日です。アカウントのロックは、30日が経過すると自動的に解除されます。

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

CREATE PROFILE prof LIMIT
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_GRACE_TIME 3

ALTER USER johndoe PROFILE prof;

ユーザー・アカウントの明示的ロック

ユーザー・アカウントを明示的にロックした場合、アカウントのロックは自動的には解除されません。セキュリティ管理者のみがアカウントのロックを解除できます。

マルチテナント環境では、ルートで共通ユーザー・アカウントをロックすると、このユーザーは、このルートに関連付けられたすべてのPDBにログインできなくなり、このアカウントのロックをPDBで解除することもできなくなります。また、共通アカウントをPDBでローカルにロックすることもできます。これにより、共通ユーザーは、そのPDBにログインできなくなります。

- ユーザー・アカウントを明示的にロックするには、CREATE USER文またはALTER USER文を使用します。

たとえば、次の文はユーザー・アカウントsusanをロックします。

ALTER USER susan ACCOUNT LOCK;

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

指定した期間、または指定したパスワード変更回数を経過するまで、ユーザーが以前のパスワードを再利用しないようにできます。

- 指定した期間、ユーザーが以前のパスワードを再利用できないようにするには、CREATE PROFILE文またはALTER PROFILE文を使用してパスワードの再利用のルールを構成できます。

表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が使用されます。

関連項目:

- CREATE PROFILE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- ALTER PROFILE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

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

パスワードの存続期間を指定して、この期間を過ぎるとパスワードを期限切れにできます。

つまり、ユーザーは現行の正しいパスワードを使用して次回ログインする際に、パスワードの変更を求められるということです。デフォルトでは、複雑度チェックやパスワード履歴チェックは行われないため、ユーザーは以前のパスワードや脆弱なパスワードを再利用できます。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文を使用したパスワード存続期間の設定

パスワードの存続期間を設定した場合、存続期間の終了時にユーザーは新しいパスワードを作成する必要があります。

パスワードのライフ・サイクルの詳細は、パスワード変更のライフ・サイクルを参照してください。

- パスワードの存続期間を指定するには、CREATE PROFILE文またはALTER PROFILE文を使用します。

次の例は、プロファイルを作成してユーザーjohndoeに割り当てる方法を示しています。PASSWORD_LIFE_TIME句によって、johndoeはパスワードの期限が切れるまで180日間同じパスワードを使用できることが指定されています。

CREATE PROFILE prof LIMIT
FAILED_LOGIN_ATTEMPTS 4
PASSWORD_GRACE_TIME 3
PASSWORD_LIFE_TIME 180;
ALTER USER johndoe PROFILE prof;

ユーザー・アカウントのステータスの確認

アカウント・ステータスは、オープン、猶予期間、期限切れのいずれの場合も確認できます。

- ユーザー・アカウントのステータスをチェックするには、DBA_USERSデータ・ディクショナリ・ビューのACCOUNT_STATUS列を問い合せます。

例:

SELECT ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'username';

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

パスワードが作成されると、そのパスワードは、次の4つのフェーズのライフ・サイクルと猶予期間をたどります。

図3-1は、パスワードの存続期間および猶予期間のライフ・サイクルを示しています。

図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列でユーザーのアカウント・ステータスを検索できます。

次の例では、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)に変更されません。時間測定が開始されるのは、ユーザーがデータベースにログインした時点のみです。ユーザーの最終ログイン時間を確認する方法は次のとおりです。

SELECT LAST_LOGIN FROM DBA_USERS WHERE USERNAME = 'user_name';

パスワードのプロファイルを変更する際にデータベース管理者が注意すべきなのは、このプロファイルの対象となるユーザーの一部が、管理者がパスワードのプロファイルを更新している時点でOracle Databaseにログイン中であれば、これらのユーザーは、パスワードの有効期限を越えてシステムにログインし続けることが可能だということです。現在ログインしているユーザーを見つけるには、V$SESSIONビューのUSERNAME列を問い合せます。

これは、ユーザーのパスワードの有効期限が、パスワード最終変更時点のタイムスタンプに、管理者の設定したPASSWORD_LIFE_TIMEパスワード・プロファイル・パラメータの値を加えたものに基づいているためです。パスワード・プロファイル自体の最終変更時点のタイムスタンプに基づいているのではありません。

次のことに注意してください。

- PASSWORD_LIFE_TIMEを低い値に設定しているときにユーザーがログインしていない場合、ユーザーのアカウント・ステータスはユーザーがログインするまで変わりません。

- PASSWORD_LIFE_TIMEパラメータをUNLIMITEDに設定できますが、この設定が作用するのは猶予期間に入っていないアカウントのみです。猶予期間に入っているユーザーは、その期間を過ぎるとパスワードを変更する必要があります。

パスワードの複雑度の管理

Oracle Databaseには、パスワードの複雑度の管理に使用できる一連の関数があります。

内容は次のとおりです。

- パスワードの複雑度検証の概要

- Oracle Databaseによるパスワードの複雑度のチェック方法

- パスワード複雑度ファンクションを使用できるユーザー

- verify_function_11G関数のパスワード要件

- ora12c_verify_functionのパスワード要件

- ora12c_strong_verify_function関数のパスワード要件

- パスワード複雑度検証のカスタマイズについて

- パスワード複雑度検証の有効化

パスワードの複雑度検証の概要

複雑度検証では、パスワードを推定してシステムに入ろうとする侵入者から保護できるだけの複雑性が各パスワードに備わっているかがチェックされます。

複雑度検証ファンクションを使用すると、データベース・ユーザー・アカウントに対して強力で安全性の高いパスワードが強制的に作成されます。ユーザーのパスワードは、パスワードを推定してシステムに入ろうとする侵入者に対して、十分保護可能な複雑なものである必要があります。

Oracle Databaseによるパスワードの複雑度のチェック方法

Oracle Databaseにはパスワードの複雑度をチェックするパスワード検証機能が4つ用意されています。

これらの関数はutlpwdmg.sql PL/SQLスクリプト内にあります($ORACLE_HOME/rdbms/adminにある)。これらの関数が有効になっている場合、ユーザーがパスワードを正しく作成または変更したかどうかを確認できます。有効にすると、パスワードの複雑度のチェックはユーザーSYSに対して適用されず、SYS以外のユーザーにのみ適用されます。パスワードのセキュリティを強化するには、パスワード検証ファンクションとデフォルト・プロファイルを関連付けることをお薦めします。パスワード複雑度検証のカスタマイズについてには、これを実行する方法の例が示されています。

パスワード複雑度ファンクションを使用できるユーザー

パスワード複雑度ファンクションを使用すると、ユーザーがデータにアクセスする方法をカスタマイズできます。

パスワード複雑度検証ファンクションをCREATE PROFILE文またはALTER PROFILE文で使用する前に、そのファンクションに対するEXECUTE権限が付与される必要があります。

パスワード検証ファンクションは、SYSスキーマにあります。

verify_function_11G関数のパスワード要件

verify_function_11Gファンクションは、Oracle Databaseリリース11gから開始されました。

このファンクションでは、ユーザーがパスワードを作成または変更したときに、次の要件をチェックします。

- パスワードがユーザー名と同一でないこと。ユーザー名のスペルを逆にしたり、ユーザー名に数字1から100を追加したパスワードでないこと。

- サーバー名と同一であったり、サーバー名に数字1から100を追加したパスワードでないこと。

- パスワードを単純にしすぎないこと(たとえば、oracle、数値1から100を追加したoracle、welcome1、database1、account1、user1234,、password1、oracle123、computer1、abcdefg1、change_on_installなど)。

- パスワードに少なくとも数字が1つと英字が1つ含まれていること。

- 以前のパスワードとの違いが3文字以上あること。

次の内部チェックも適用されます。

- パスワードの長さが8文字以上30文字以内であること。

- パスワードは二重引用符文字(")を含みません。ただし、二重引用符で囲むことができます。

ora12c_verify_functionのパスワード要件

ora12c_verify_functionファンクションは、Department of Defense Database Security Technical Implementation Guideで推奨されている要件を提供します。

このファンクションでは、ユーザーがパスワードを作成または変更したときに、次の要件をチェックします。

- パスワードの長さが8文字以上であり、少なくとも数字が1つと英字が1つ含まれていること。

- パスワードがユーザー名またはユーザー名のスペルを逆にしたものと同一でないこと。

- パスワードがデータベース名と同一でないこと。

- パスワードにoracle (oracle123など)の語が含まれていないこと。

- パスワードを単純にしすぎないこと(たとえば、welcome1、database1、account1、user1234、password1、oracle123、computer1、abcdefg1またはchange_on_install)。

- 以前のパスワードとの違いが3文字以上あること。

- パスワードに少なくとも1つの特殊文字が含まれていること。

次の内部チェックも適用されます。

- パスワードの長さが30文字以内であること。

- パスワードは二重引用符文字(")を含みません。ただし、二重引用符で囲むことができます。

ora12c_strong_verify_function関数のパスワード要件

ora12c_strong_verify_functionファンクションは、Department of Defense Database Security Technical Implementation Guideの要件を満たしています。

このファンクションでは、ユーザーがパスワードを作成または変更したときに、次の要件をチェックします。

- パスワードは、少なくとも2つの大文字、2つの小文字、2つの数値および2つの特殊文字を含む必要があります。これらの特殊文字は次のとおりです。

‘ ~ ! @ # $ % ^ & * ( ) _ - + = { } [ ] \ / < > , . ; ? ' : | (space)

- パスワードは、少なくとも4つの文字が以前のパスワードと異なる必要があります。

次の内部チェックも適用されます。

- パスワードの長さが9文字以上30文字以内であること。

- パスワードは二重引用符文字(")を含みません。ただし、二重引用符で囲むことができます。

パスワード複雑度検証のカスタマイズについて

Oracle Databaseを使用すると、サイトのパスワード複雑度をカスタマイズできます。

utlpwdmg.sqlスクリプトをバックアップして、このスクリプトで作成された関数を編集して、独自のパスワードの複雑度検証関数を作成できます。サイトのパスワードの保護を強化するために、独自のパスワード複雑度検証関数を作成することをお薦めします。

カスタムのパスワードの複雑度検証関数にデータ定義言語(DDL)文を含めないでください。パスワードの複雑度検証関数の実行中、DDLは使用できません。

パスワードの作成に関するガイドラインは、パスワードの保護に関するガイドラインのガイドライン1も参照してください。パスワードの複雑度のチェックはSYSユーザーに対して適用されないことに注意してください。utlpwdmg.sqlスクリプトを変更しない場合、デフォルト関数としてora12c_verify_function関数を使用します。

パスワード複雑度検証の有効化

utlpwdmg.sqlスクリプトをカスタマイズして、パスワードの複雑度検証を有効にできます。

1. 管理者権限を使用してSQL*Plusにログインします。

例:

CONNECT SYSTEM
Enter password: password

2. utlpwdmg.sqlスクリプト(またはこのスクリプトの変更されたバージョン)を実行して、SYSスキーマのパスワード複雑度関数を作成します。

@$ORACLE_HOME/rdbms/admin/utlpwdmg.sql

3. このファンクションを使用する必要があるユーザーに、ファンクションに対するEXECUTE権限を付与します。

例:

GRANT pmsith EXECUTE ON ora12c_strong_verify_function;

4. デフォルト・プロファイルまたはユーザー・プロファイルで、PASSWORD_VERIFY_FUNCTION設定を、utlpwdmg.sqlスクリプトのサンプルのパスワード複雑度関数か、カスタマイズした関数に設定します。次のいずれかの方法を使用します。

- 管理者権限でSQL*Plusにログインし、CREATE PROFILE文またはALTER PROFILE文を使用して関数を使用可能にします。ファンクションに対するEXECUTE権限があることを確認します。
たとえば、デフォルト・プロファイルを更新してora12c_strong_verify_function関数を使用するには、次のようにします。

ALTER PROFILE default LIMIT
PASSWORD_VERIFY_FUNCTION ora12c_strong_verify_function;

- Oracle Enterprise Manager Cloud Controlで、「管理」メニューから、「セキュリティ」を選択し、「プロファイル」を選択します。「パスワード」タブを選択します。「複雑なパスワード検証」で、「複雑なパスワード検証のための関数」リストから、使用する複雑度関数の名前を選択します。「適用」をクリックします。

パスワード複雑度検証は、使用可能にするとすぐに有効になります。無効にする必要がある場合、次の文を実行します。

ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION NULL;

注意:

ALTER USER文でREPLACE句を使用できます。ユーザーは、この句を使用して、自身を認証するために以前のパスワードを指定し、期限が切れていない自分のパスワードを変更できます。

パスワードが期限切れになると、ユーザーはSQLにログインしてALTER USERコマンドを発行できません。かわりにOCIPasswordChange()関数を使用しますが、この場合は以前のパスワードも必要になります。

ALTER ANY USER権限が付与されているデータベース管理者は、古いパスワードを指定せずにユーザーのパスワードを変更(新しいパスワードを適用)できます。

パスワードでの大/小文字の区別の管理

以前のリリースで作成されたユーザー・アカウントのパスワードに対して、パスワードの大/小文字の区別を管理できます。

内容は次のとおりです。

- SEC_CASE_SENSITIVE_LOGONパラメータおよびパスワードの大/小文字の区別

- ALTER SYSTEM文を使用したパスワードの大/小文字の区別の有効化

- 安全性の高いロール・パスワードの大/小文字の区別の管理

- ユーザーのパスワード・バージョンの管理

- 10Gパスワード・バージョンを使用するユーザーのパスワードの確認と再設定

- 大/小文字の区別がパスワード・ファイルに与える影響

- 大/小文字の区別がデータベース・リンク接続で使用されるパスワードに与える影響

SEC_CASE_SENSITIVE_LOGONパラメータおよびパスワードの大/小文字の区別

SEC_CASE_SENSITIVE_LOGON初期化パラメータは、パスワードでの大/小文字の区別の使用を制御します。

SEC_CASE_SENSITIVE_LOGONパラメータを設定できるのは、ALTER SYSTEM権限を持つユーザーのみです。このパラメータがTRUEに設定されていて、ユーザーがパスワードを入力するときに大/小文字の区別が適用されることを確認する必要があります。(ただし、SEC_CASE_SENSITIVE_LOGONパラメータが非推奨ですが、下位互換性のために現在残されていることに注意してください。)

ユーザー・アカウントを作成または変更するとき、パスワードはデフォルトで大/小文字の区別があります。大/小文字の区別は、ユーザーが手動で入力するパスワードのみでなく、パスワード・ファイルにも影響を与えます。

セキュリティを強化するために、パスワードで大/小文字の区別を使用することをお薦めします。ただし、アプリケーションで互換性の問題がある場合は、SEC_CASE_SENSITIVE_LOGONパラメータを使用して、パスワードで大/小文字の区別を無効にできます。アプリケーションでの互換性の問題の例として、Oracleサーバーに対して認証するために使用する前にパスワードが強制的に大文字になるアプリケーションやデータベース・セッションを起動するために資格証明を送信するときに複数のアプリケーション・モジュール間で大/小文字の区別が一貫していない場合などがあります。

SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータが12または12aに設定されている場合は、SEC_CASE_SENSITIVE_LOGONパラメータがFALSEに設定されていないことを確認します。これは、このモードで使用されているセキュリティ度の強いパスワード・バージョンでは、大文字/小文字を区別するパスワード・チェックのみがサポートされているためです。互換性上の理由により、Oracle DatabaseではSQLNET.ALLOWED_LOGON_VERSION_SERVERが12または12aに設定されているときにSEC_CASE_SENSITIVE_LOGONでFALSEの使用が禁止されてはいません。SQLNET.ALLOWED_LOGON_VERSION_SERVERが12または12aに設定されている場合にSEC_CASE_SENSITIVE_LOGONをFALSEに設定すると、すべてのアカウントがアクセス不能になります。SQLNET.ALLOWED_LOGON_VERSION_SERVERが11以下の値に設定されている場合は、Oracle Database 12cの排他モード(SQLNET.ALLOWED_LOGON_VERSION_SERVERが12または12aの場合)で使用されるセキュリティ度の強いパスワード・バージョンが大文字/小文字を区別しないパスワード照合をサポートしないため、SEC_CASE_SENSITIVE_LOGONをTRUEに設定することをお薦めします。

サーバー側の設定に加えて、ユーザーが接続しているクライアント・ソフトウェアにO5L_NP機能フラグがあることを確認する必要があります。Oracle Databaseリリース11.2.0.4以上のすべてのクライアントにO5L_NP機能があります。以前のクライアントがある場合は、CPUOct2012パッチをインストールする必要があります。

ALTER SYSTEM文を使用したパスワードの大/小文字の区別の有効化

パスワードの大/小文字の区別が無効化されている場合、有効化するには、SEC_CASE_SENSITIVE_LOGONパラメータをTRUEに設定します。

1. パスワード・ファイルを使用している場合、ORAPWDユーティリティのIGNORECASEパラメータがNに設定されて作成され、FORMATパラメータが12に設定されていることを確認します。

IGNORECASEパラメータによりSEC_CASE_SENSITIVE_LOGONパラメータが上書きされます。デフォルトでは、IGNORECASEはパスワードの大/小文字が区別されることを意味するNに設定されます。パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

IGNORECASEパラメータおよびSEC_CASE_SENSITIVE_LOGONシステム・パラメータは非推奨なので注意してください。IGNORECASEをNに設定するか、IGNORECASE設定全体を省略することをお薦めします。

2. 次のALTER SYSTEM文を入力します。

ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = TRUE;

安全性の高いロール・パスワードの大/小文字の区別の管理

セキュリティを強化するために、安全性の高いロールのためのパスワードは、大/小文字が区別されるようにする必要があります。

Oracle Database 12cリリース1 (12.1)にアップグレードする前に、CREATE ROLE文のIDENTIFIED BY句を使用して安全性の高いロールを作成し、リリース12cへのアップグレード時にSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを12または12aに設定する場合、これらの安全性の高いロールを引き続き使用可能にするには、パスワードを変更する必要があります。

DBA_ROLESデータ・ディクショナリ・ビューのPASSWORD_REQUIREDおよびAUTHENTICATION_TYPE列を問い合せて、再度使用可能にするためにOracle Database 12cへのアップグレード後にパスワードを変更する必要がある安全性の高いロールを確認できます。

それ以外の場合、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを8に設定しないかぎり、これらの安全性の高いロールのパスワード・バージョンを使用できません。このパラメータが12または12aに設定されている場合、次のSQL文を実行して、大/小文字の区別が有効であることを確認します。そうしないと、パスワードを変更した後でも、安全性の高いロールを使用できません。

ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = "TRUE";

ユーザーのパスワード・バージョンの管理

Oracle Databaseの以前のリリースでは、パスワードで大文字と小文字は区別されませんでした。

以前のリリース(たとえば、リリース10gなど)から現在のデータベース・リリースにユーザー・アカウントをインポートする場合、デフォルトでは、これらのユーザーは、パスワードを大文字/小文字のどちらで入力しても依然としてデータベースにログインできます。しかし、以前のリリースのユーザー・アカウントのパスワードは変更されると、大/小文字が区別されるようになります。

10Gパスワード・バージョンを使用するユーザー・アカウントを検索して、これらのアカウントのパスワードを再設定する必要があります。これにより、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの設定に基づく適切なパスワード・バージョンが次のように生成されます。

- SQLNET.ALLOWED_LOGON_VERSION_SERVER=8は、3つのすべてのパスワード・バージョン10G、11Gおよび12Cを生成します。

- SQLNET.ALLOWED_LOGON_VERSION_SERVER=12は、11Gおよび12Cパスワード・バージョンを生成し、10Gパスワード・バージョンを削除します。

- SQLNET.ALLOWED_LOGON_VERSION_SERVER=12aは、12Cパスワード・バージョンのみ生成します。

10Gパスワード・バージョンを使用するユーザーのパスワードの確認と再設定

10Gパスワード・バージョンを使用するユーザー・アカウントのパスワードを確認および再設定できます。

1. DBA_USERSデータ・ディクショナリ・ビューを問い合せて、アカウントの作成時またはアカウント・パスワードの最終変更時にパスワードから生成されたパスワード・バージョンのリストを確認します。

例:

SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;

USERNAME                       PASSWORD_VERSIONS
------------------------------ -----------------
JONES                          10G 11G 12C
ADAMS                          10G 11G
CLARK                          10G 11G
PRESTON                        11G
BLAKE                          10G

PASSWORD_VERSIONS列は、アカウントに存在するパスワード・バージョンのリストを示しています。10Gは大文字と小文字を区別しない以前のOracleパスワード・バージョンを表し、11GはSHA-1バージョンを表します。また、12CはSHA-2ベースのSHA-512バージョンを表します。

SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの設定が8の場合にjonesのパスワードがリリース12.1で再設定されました。これにより、3つのすべてのパスワード・バージョンを作成できます。アカウントadamsおよびclarkのパスワードは、最初にリリース10gで作成され、その後、リリース11gで再設定されています。リリース11gソフトウェアは、その時点でデフォルトのSQLNET.ALLOWED_LOGON_VERSION設定の8を使用していました。大/小文字の区別がデフォルトで有効になっているため、これらのパスワードは、prestonのパスワードと同様に大/小文字が区別されます。ユーザーprestonのアカウントは、排他モード(つまり、SQLNET.ALLOWED_LOGON_VERSIONが12に設定されている)で実行されていたリリース11gデータベースからインポートされました。ただし、blakeのアカウントは、まだリリース10gパスワード・バージョンを使用しています。この段階では、ユーザーblakeはログインできません。

2. 11Gまたはリリース12cパスワード・バージョンを持たない各ユーザーのアカウントのパスワードを期限切れにします。

例:

ALTER USER blake PASSWORD EXPIRE;

3. ユーザーblakeにログインを依頼します。パスワードを変更するよう求められます。

パスワードが変更されると、Oracle Databaseリリース12cによって大/小文字を区別する11Gおよび12Cパスワード・バージョンが(新規10Gパスワード・バージョンに加えて)生成されます。SQLNET.ALLOWED_LOGON_VERSION_SERVERが11に設定されているかぎり、3つのパスワード・バージョンすべてが生成(および許可)されることに注意してください。

DBA_USERSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

大/小文字の区別がパスワード・ファイルに与える影響

デフォルトでは、パスワード・ファイルは大/小文字を区別します。ORAPWDコマンドライン・ユーティリティのIGNORECASE引数は、パスワード・ファイルの大/小文字の区別を制御します。

IGNORECASEのデフォルト値はN(no)で、大/小文字の区別が適用されます。セキュリティを強化するために、IGNORECASEをNに設定するか、ignorecase引数全体を省略します。IGNORECASEは非推奨なので注意してください。

次の例は、パスワード・ファイルで大/小文字の区別を有効にする方法を示しています。

orapwd file=orapw entries=100
Enter password for SYS: password

このコマンドは、orapwと呼ばれる大/小文字を区別するパスワード・ファイルを作成します。デフォルトでは、パスワードでは大文字と小文字が区別されます。その後、このパスワードを使用して接続する場合、パスワードの作成時と大/小文字を同じにして入力すれば成功します。同じパスワードでありながら大/小文字の区別が異なるパスワードを入力すると、失敗します。

以前のリリースからユーザー・アカウントをインポートし、そのアカウントがSYSDBAまたはSYSOPER管理権限を使用して作成されている場合、アカウントはパスワード・ファイルに格納されます。この時点で、アカウントのパスワードは大/小文字が区別されません。大/小文字の区別が有効な場合、次にユーザーがパスワードを変更すると、パスワードは大/小文字が区別されます。セキュリティを強化するために、そのユーザーに対してパスワードを変更するように要請してください。

パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

大/小文字の区別がデータベース・リンク接続で使用されるパスワードに与える影響

データベース・リンク接続を作成する場合は、接続用のユーザー名とパスワードを定義する必要があります。

データベース・リンク接続を作成すると、パスワードは大/小文字が区別されます。ユーザーが接続用のパスワードをどのように入力するかは、データベース・リンクが作成されたリリースによって決まります。

- ユーザーはOracle Database 12cより前のデータベースからOracle Database 12cデータベースに接続できます。大/小文字の区別が有効なため、ユーザーは、アカウントの作成時に使用された大文字/小文字を使用して、パスワードを入力する必要があります。

- ユーザーがOracle Database 12cデータベースからOracle Database 12cより前のリリースのデータベースに接続する場合、およびリリース12cより前のデータベースのSEC_CASE_SENSITIVE_LOGONパラメータがFALSEに設定されていた場合、大文字/小文字を使用してこのデータベース・リンクのパスワードを指定できます。

既存のデータベース・リンクのユーザー・アカウントを検索するには、V$DBLINKビューを問い合せます。次に例を示します。

SELECT DB_LINK, OWNER_ID FROM V$DBLINK;

V$DBLINKビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

パスワードのセキュリティへの脅威からの12Cパスワード・バージョンによる保護

12Cパスワード・バージョンを使用すると、ユーザーは、コンプライアンス基準を満たす複雑なパスワードを作成できます。

内容は次のとおりです。

- 12Cバージョンのパスワード・ハッシュについて

- Oracle Database 12Cパスワード・バージョン構成のガイドライン

- 12Cパスワード・バージョンを排他的に使用するためのOracle Databaseの構成

- 12Cパスワード・バージョンを排他的に使用するためのOracle Databaseクライアントの構成

12Cバージョンのパスワード・ハッシュについて

12Cバージョンのパスワード・ハッシュは、大/小文字混在のパスワード(大文字と小文字の両方が使用されているパスワード)のサポートを含めることで、パスワード・ベースのセキュリティに対する脅威からデータを保護します。

12Cバージョンのパスワード・ハッシュの生成に使用される暗号化ハッシュ関数は、パスワードベースの鍵導出関数(PBKDF2)およびSHA-512暗号化ハッシュ関数を含む非最適化されたアルゴリズムに基づいています。12Cパスワード・バージョンがある場合、PBKDF2アルゴリズムによって計算上の非対称性が生じ、侵入者が元のパスワードに戻すことが難しくなります。12Cパスワードの生成では、その最後のステップとしてPBKDF2出力のSHA-512ハッシュを実行します。12Cパスワード・バージョンの生成で使用されるこの2段階のアプローチでは、クライアントにO7L_MR機能がある場合、サーバーのCPUリソースの使用が抑えられます。これは、O5LOGON認証のパスワード検証フェーズ中に、パスワード自体でPBKDF2計算全体を繰り返すのではなく、サーバーがO7L_MR対応クライアントによって送信される値の1つのSHA-512ハッシュのみを実行すればよいためです。

さらに、12Cパスワード・バージョンにより、ハッシュ時にパスワードにsaltが追加され、さらなる保護が提供されます。12cパスワード・バージョンでは、ユーザーはより複雑なパスワードを作成できます。12Cパスワード・バージョンでsaltおよびPBKDF2非最適化が使用され、大/小文字混在のパスワードがサポートされることで、侵入者が12Cパスワード・バージョンに対して辞書攻撃や総当り攻撃を行ってユーザーのパスワードに戻すことがより難しくなります。12Cバージョンのパスワード・ハッシュを使用することをお薦めします。

パスワード・ハッシュ値は、サーバーとログインしているユーザー間の「共有秘密」として使用されるため、非常に機密性が高いとみなされます。侵入者にこの秘密を知られると、認証の保護はただちに重大な危険にさらされます。アカウント管理権限を持つ管理ユーザー、SYSDBA管理権限を持つ管理ユーザーまたはEXP_FULL_DATABASEロールを持つユーザーがパスワード・ハッシュ値に直接アクセスできることに注意してください。したがって、データベースのパスワードベースの認証の整合性を保持するには、このタイプの管理ユーザーは信頼できるユーザーである必要があります。これらの管理者が信頼できない場合、パスワード・ハッシュ値が「エンタープライズ・ユーザー・セキュリティ」ディレクトリ内に保持され、エンタープライズ・ユーザー・セキュリティ管理者以外はアクセスできないように、ディレクトリ・サーバー(Oracle Databaseエンタープライズ・ユーザー・セキュリティなど)をデプロイすることをお薦めします。

関連項目:

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

Oracle Database 12Cパスワード・バージョン構成のガイドライン

デフォルトでは、Oracle Databaseによるユーザーの認証には、3つのバージョンのパスワード・ハッシュ(10Gパスワード・バージョン、11Gパスワード・バージョンおよび12Cパスワード・バージョン)が使用されます。

10Gバージョンのパスワード・ハッシュでは、大文字と小文字が区別されません。11Gと12Cの両パスワード・バージョンでは大/小文字は区別されます。

Oracle Database 12cでは、sqlnet.oraパラメータSQLNET.ALLOWED_LOGON_VERSION_SERVERのデフォルトは11(排他モードであり、10Gパスワード・バージョンの使用を禁止します)、およびSQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータのデフォルトは、11です。新しいアカウントについては、クライアントがOracle Database 12cの場合、Oracle Databaseは、Oracle Database 12cリリース・ソフトウェアを実行しているクライアントで12Cパスワード・バージョンを排他的に使用します。リリース12cの前に作成されたアカウントについては、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータが11に設定されている場合、11Gパスワード・バージョンがアカウントに存在するかぎり、SHA-1アルゴリズムを使用したログインは成功します。アカウントのSHA-1ベリファイアを作成するため、ユーザーのパスワードを再設定する必要がある場合があります。新しいアカウントを作成する際、または既存のアカウント・パスワードを変更する際に、12Cパスワード・バージョンを生成するようこのサーバーを構成するには、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを11または12に設定します。

SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの設定は、セキュリティとシステムに必要な古いクライアントとの相互運用性とのバランスによって決まります。

- 最高レベルの互換性: 新しいアカウントを作成する際、または既存のアカウント・パスワードを変更する際に、3つのパスワード・バージョン(12Cパスワード・バージョン、11Gパスワード・バージョンおよびDESベースの10Gパスワード・バージョン)をすべて生成するようサーバーを構成するには、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを値11以下に設定します。(以前のリリースでは値8がデフォルトで使用されていたことに注意してください。)

- 中レベルのセキュリティ: 新しいアカウントを作成する際、または既存のアカウント・パスワードを変更する際に、12Cパスワード・バージョンおよび11Gパスワード・バージョンを生成する(10Gパスワード・バージョンは生成しない)ようにサーバーを構成するには、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを値12に設定します。

- 最高レベルのセキュリティ: 新しいアカウントを作成する際、または既存のアカウント・パスワードを変更する際に、12Cパスワード・バージョンのみを生成するようサーバーを構成するには、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを値12aに設定します。

認証中に、アカウントに存在するパスワード・バージョンの種類および使用するクライアント・ソフトウェアのバージョンに基づき、次のシナリオが可能です。

- 10Gパスワード・バージョンのみを使用したアカウント: サーバーで古いアカウントに対して新しいパスワード・バージョンを生成するよう強制する場合、管理者は10Gパスワード・バージョンのみを持つ(11Gや12Cといったよりセキュアなパスワード・バージョンを持たない)アカウントのパスワードを期限切れにする必要があります。データベースはこれらのパスワード・バージョンを使用してより強固なセキュリティを提供しているため、これらのパスワード・バージョンを生成する必要があります。これらのユーザーは次のようにして検出できます。(10Gに後に空白を含めます。)

SELECT USERNAME FROM DBA_USERS WHERE PASSWORD_VERSIONS='10G ';

次に、各アカウントを次のようにして期限切れにします。

ALTER USER username PASSWORD EXPIRE;

各アカウントを期限切れにした後、これらのユーザーにログインするよう通知します。ログインの際、パスワードを変更するよう求められます。パスワードを変更すると、11Gおよび12Cのパスワード・バージョンがデフォルトで生成されます。Oracle Database 12cクライアントの認証には、12Cパスワード・バージョンのみが使用されます。以前のOracle Databaseクライアントの認証には、11Gパスワード・バージョンが使用されます。12Cパスワード・バージョンを排他的に使用するには、すべてのクライアントをOracle Database 12cにアップグレードする必要があります。アカウント・パスワードの期限が切れ、ALLOWED_LOGON_VERSION_SERVERパラメータが12または12aに設定されている場合、10Gパスワード・バージョンは削除され、パラメータの設定に応じて次のように1つまたは2つの新しいパスワード・バージョンが作成されます。

- ALLOWED_LOGON_VERSION_SERVERが12 (デフォルト)に設定されている場合、11Gと12Cの2つのパスワード・バージョンが生成されます。

- ALLOWED_LOGON_VERSION_SERVERが12aに設定されている場合、12Cパスワード・バージョンのみが生成されます。

詳細は、『Oracle Database Net Servicesリファレンス』のSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの使用上の注意に関する項の表内の生成されるパスワードのバージョンの列を参照してください。

- 10Gおよび11Gパスワード・バージョンを使用したアカウント: リリース10g以上のクライアントを使用しているユーザーは、11Gパスワード・バージョンが使用されるため、ユーザー・ログインは成功します。ただし、最新のパスワード・バージョンを使用するには、前述のアカウントに関する箇条書き項目での説明のようにこれらのパスワードを期限切れにします。

- 11Gパスワード・バージョンのみを使用したアカウント: 認証で11Gパスワード・バージョンを使用します。最新のパスワード・バージョンを使用するには、1つ目の箇条書き項目での説明のようにパスワードを期限切れにします。

Oracle Database 12cのデフォルト構成(SQLNET.ALLOWED_LOGON_VERSION_SERVERは11)は、OCIベースのドライバを使用するOracle Database 11g以降の製品(SQL*Plus、ODBC、Oracle .NET、Oracle Forms、そして様々なサード・パーティ製Oracle Databaseアダプタなど)と互換性があることを意味します。Oracle Database 11g以降のJDBCタイプ4(シン)バージョンおよびOracle Database 10gリリース2 (10.2)以降のOracle Database Clientインタフェース(OCI)ベースのドライバとも互換性があります。

12Cパスワード・バージョンを排他的に使用するためのOracle Databaseの構成

侵入者がより脆弱なパスワード・バージョンを使用するよう認証のダウングレードを試みることが多くあります。このような脆弱なパスワード・バージョンを使用しないようにサーバーを構成するには、サーバーを排他モードで実行する必要があります。

1. 管理ユーザーとしてSQL*Plusにログインします。

2. 次のSQL文を実行して、ユーザーのパスワード・バージョンを確認します。

SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;

3. 11Gまたは12Cパスワード・バージョンを持たない各ユーザーのアカウントを期限切れにします。
たとえば、ユーザーblakeがまだ10Gパスワード・バージョンを使用しているとします。

ALTER USER blake PASSWORD EXPIRE;

これらのユーザーが次にログインする際、パスワードの変更が強制され、サーバーが排他モードに必要なパスワード・バージョンを生成できます。

4. しかるべき期間(30日間など)内にログインするようユーザーに通知します。
ログイン時、パスワードを変更するよう求められ、排他モードでの認証に必要なパスワード・バージョンがサーバーによって生成されます。(排他モードの機能の詳細は、『Oracle Database Net Servicesリファレンス』のSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの使用上の注意に関する項を参照してください。)

5. パスワードの大/小文字を含めてこれらのテスト・スクリプトまたはバッチ・ジョブで使用されるパスワードと正確に一致するように、テスト・スクリプトまたはバッチ・ジョブで使用されるアカウントのパスワードを手動で変更します。

6. 次のようにして排他モード構成を有効にします。

a. sqlnet.oraパラメータ・ファイルのバックアップ・コピーを作成します。このファイルのデフォルトの場所は、UNIXオペレーティング・システムでは$ORACLE_HOME/network/adminディレクトリ、Microsoft Windowsオペレーティング・システムでは%ORACLE_HOME%\network\adminディレクトリです。
マルチテナント環境では、sqlnet.oraファイルの設定がすべてのPDBに適用されることに注意してください。

b. SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを12または12aに設定します。Oracle Database 12cクライアントのみを使用する場合、SQLNET.ALLOWED_LOGON_VERSION_SERVERを12aに設定します。
パスワード・バージョン生成のSQLNET.ALLOWED_LOGON_VERSION_SERVER設定の効果を次の表に示します。

SQLNET.ALLOWED_LOGON_VERSION_SERVER設定

8

11

12

12a

サーバーを排他モードで実行しますか

いいえ

いいえ

はい

はい

10Gパスワード・バージョンを生成しますか

はい

はい

いいえ

いいえ

11Gパスワード・バージョンを生成しますか

はい

はい

はい

いいえ

12Cパスワード・バージョンを生成しますか

はい

はい

はい

はい

設定を高くすると、パスワード・バージョンの使用がさらに制限されます。8に設定すると、ほとんどのパスワード・バージョン(つまり、10G、11Gおよび12Cパスワード・バージョン)がすべて許可され、12aに設定すると、12Cパスワード・バージョンのみが許可されます。セキュリティを強化するために、12aへのSQLNET.ALLOWED_LOGON_VERSION_SERVERの設定を検討してください。12に設定すると、11Gおよび12Cパスワード・バージョンが許可され、認証に使用されます。

SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

c. sqlnet.oraファイルを保存します。

7. 以前のリリースを実行しているターゲット・データベースへの固定データベース・リンクをホストするシステムで、SQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータを設定します。

次の図には接続方法が示されています。SQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータは、データベース・リンク(H)をホストするサーバーのクライアントが許可されたログオン・バージョンに影響します。この設定により、Oracle 9i(T)を実行しているサーバーなどの古いサーバーへのデータベース・リンクを通じてHを接続し、古いパッチが適用されていないクライアント(U)の接続を引き続き拒否できます。Oracle Net Servicesプロトコル・ネゴシエーションに失敗し、Oracle 9i ソフトウェアを使用して認証を試行しているこのクライアントのORA-28040: 一致する認証プロトコルがありませんエラー・メッセージが表示されます。クリティカル・パッチ・アップデートCPUOct2012が適用されているため、リリース10.2.0.xクライアント(E)のOracle Net Servicesプロトコル・ネゴシエーションに成功します。安全性の高いパスワード・バージョンを使用するため、リリース11.2.0.3クライアント(C)のOracle Net Servicesプロトコル・ネゴシエーションに成功します。

このシナリオは、データベース・リンク(H)をホストするシステムの次の設定を使用します。

SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
SQLNET.ALLOWED_LOGON_VERSION_SERVER=12

リモートのOracle Database (T)は次の設定なので注意してください。

SQLNET.ALLOWED_LOGON_VERSION=8

リモートのOracle Database (T)のリリースがホスト(H)に設定されるSQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータで定義された値を満たしていないまたは超えていない場合、データベース・リンク・ユーザーの認証中に固定データベース・リンクの問合せに失敗し、エンドユーザーがデータベース・リンクで表にアクセスしようとすると ORA-28040: 一致する認証プロトコルがありませんエラーになります。SQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

注意:

古いOracle Databaseクライアント(リリース11.1.0.7など)を使用している場合は、アップグレードしてクリティカル・パッチ・アップデートCPUOct2012を使用することをお薦めします。CPUOct2012の詳細は、Oracle Technology Networkのサイトを参照してください。

http://www.oracle.com/technetwork/topics/security/cpuoct2012-1515893.html

12Cパスワード・バージョンを排他的に使用するためのOracle Databaseクライアントの構成

侵入者が偽のサーバーを用意し、認証をダウングレードして、クライアントが、より脆弱なバージョンのパスワード・ハッシュを使用するよう仕向けることが多くあります。

- 10Gバージョンのパスワード・ハッシュまたは10Gと11Gのパスワード・バージョンが使用されないようにするには、サーバーの構成後に、次に示すようにクライアントを構成して排他モードで稼働するようにします。

- クライアント排他モード設定を使用して、11Gおよび12Cの2つのパスワード・バージョンを許可する方法は、次のとおりです。

SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 12

- より制限の厳しいクライアント排他モード設定を使用して、12Cバージョンのパスワード・ハッシュのみを許可する方法は、次のとおりです(この設定では、クライアントはリリース12.1.0.2以降のサーバーにのみ接続できます)。

SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 12a

サーバーとクライアントの両方が同じコンピュータにインストールされている場合、それぞれのTNS_ADMIN環境変数が各Oracle Net Services構成ファイルの正しいディレクトリを指していることを確認します。そうしないと、変数が両方で同じ場合、サーバーが誤ってクライアントのSQLNET.ALLOWED_LOGON_VERSION_CLIENT設定をかわりに使用することがあります。

古いOracle Databaseクライアント(リリース11.1.0.7など)を使用している場合は、これらのクライアントにCPUOct2012以上を適用する必要があります。このパッチを適用しないと、ユーザーはログインできなくなります。

関連項目:

- SQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

- CPUOct2012の詳細は、次のOracle Technology Networkサイトを参照してください。
http://www.oracle.com/technetwork/topics/security/cpuoct2012-1515893.html

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

安全性の高い外部パスワード・ストアは、ストア・パスワードの資格証明に使用されるクライアント側のウォレットになります。

内容は次のとおりです。

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

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

- 外部パスワード・ストアの使用を目的とするクライアントの構成について

- 外部パスワード・ストアの使用を目的とするクライアントの構成

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

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

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

パスワード資格証明データベース接続は、クライアント側のOracleウォレットを使用して格納できます。

Oracleウォレットは、認証および署名用資格証明を格納する安全性の高いソフトウェア・コンテナです。このウォレットの使用方法により、データベースに接続する際にパスワード資格証明に依存する大規模な配置を簡素化できます。この機能が構成されている場合、アプリケーション・コードおよびスクリプトにユーザー名とパスワードを埋め込む必要がありません。これによりパスワードが危険にさらされることがなくなるため、リスクが軽減します。また、ユーザー名またはパスワードが変更されるたびにアプリケーション・コードを変更する必要がなくなるため、パスワード管理ポリシーの適用が容易になります。

注意:

ウォレットの外部パスワード・ストアは、公開鍵インフラストラクチャ(PKI)資格証明が格納されている領域とは別の場所にあります。そのため、ウォレットの外部パスワード・ストアの資格証明管理には、Oracle Wallet Managerを使用できません。かわりに、コマンドライン・ユーティリティmkstoreを使用して資格証明を管理します。

関連項目:

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

- Oracleウォレットの一般情報は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

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

ユーザー(アプリケーション、バッチ・ジョブ、スクリプトを含む)は、データベース接続文字列を指定した標準の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エンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

外部パスワード・ストアの使用を目的とするクライアントの構成について

クライアントがWindowsネイティブ認証やSSLなどの外部認証を使用するように構成されている場合、Oracle Databaseではその認証方式が使用されます。

通常は、そのタイプの認証で使用されるものと同じ資格証明が、データベースへのログインにも使用されます。データベース認証として、その認証方式を使用しないかまたは変更するクライアントには、sqlnet.oraのSQLNET.WALLET_OVERRIDEパラメータをTRUEに設定できます。SQLNET.WALLET_OVERRIDEのデフォルト値はFALSEで、今までと同様に認証資格証明の標準的な使用が許可されます。

外部パスワード・ストアの使用を目的とするクライアントの構成

安全性の高い外部パスワード・ストア機能を使用するようにクライアントを構成するには、mkstoreコマンドライン・ユーティリティを使用します。

1. コマンドラインで次の構文を使用して、クライアント上にウォレットを作成します。

mkstore -wrl wallet_location -create

例:

mkstore -wrl c:\oracle\product\12.2.0\db_1\wallets -create
Enter password: password

wallet_locationは、ウォレットを作成して格納するディレクトリのパスです。このコマンドにより、指定した場所にOracleウォレットが作成され、自動ログイン機能が使用可能になります。この自動ログイン機能により、クライアントは、パスワードを指定しなくてもウォレットの内容にアクセスできます。自動ログイン・ウォレットの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

mkstoreユーティリティの-createオプションを指定すると、パスワードの複雑度検証が使用されます。詳細は、「パスワードの複雑度検証の概要」を参照してください。

2. コマンドラインで次の構文を使用して、ウォレットにデータベース接続の資格証明を作成します。

mkstore -wrl wallet_location -createCredential db_connect_string username
Enter password: password

例:

mkstore -wrl c:\oracle\product\12.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証明書が使用されます。

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

sqlnet.oraファイルに特別なパラメータを設定すると、ウォレットの管理方法を制御できます。

例3-2では、「外部パスワード・ストアの使用を目的とするクライアントの構成」の手順3および手順4で説明したWALLET_LOCATIONおよびSQLNET.WALLET_OVERRIDEパラメータが指定されている、サンプルsqlnet.oraファイルを示します。

例3-2 ウォレット・パラメータが設定されたサンプル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\12.1.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\12.1.0\db_1\wallets -createCredential orcl system
Enter password: password

次のように値を指定します。

- wallet_locationは、資格証明を追加するクライアント・ウォレットが格納されるディレクトリのパスです。

- db_aliasは、tnsnames.oraファイルでデータベースを指定するために使用するTNS別名、またはOracleネットワーク上のデータベースを識別するために使用するサービス名です。

- usernameは、アプリケーションが接続するスキーマに対するデータベース・ログイン資格証明です。プロンプトが表示された後に、このユーザーのパスワードを入力します。

外部パスワード・ストアの資格証明の変更

データベース接続文字列が変わった場合は、ウォレットに格納されているデータベース・ログイン資格証明を変更できます。

- ウォレット内のデータベース・ログイン資格証明を変更するには、コマンドラインで次のコマンドを入力します。

mkstore -wrl wallet_location -modifyCredential db_alias username

次に例を示します。

mkstore -wrl c:\oracle\product\12.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\12.1.0\db_1\wallets -deleteCredential orcl

次のように値を指定します。

- wallet_locationは、ウォレットが格納されているディレクトリのパスです。

- db_aliasは、tnsnames.oraファイルでデータベースを指定するために使用するTNS別名、またはOracle Databaseネットワーク上のデータベースを識別するために使用するサービス名です。

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

データベース管理者を認証するには、強力な認証を使用するか、オペレーティング・システムから行うか、パスワードを使用してデータベースから行います。

内容は次のとおりです。

- データベース管理者の認証について

- 管理者の厳密認証と集中管理

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

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

- データベース管理者認証のパスワード・ファイルを使用するリスク

データベース管理者の認証について

データベース管理者は、データベースの起動や停止などの特別な管理操作を実行します。

Oracle Databaseには、SYSDBA、SYSOPER、SYSBACKUP、SYSDGまたはSYSKM管理権限を持つデータベース管理者の認証を保護するための方式が用意されています。

管理者の厳密認証と集中管理

データベース管理者を一元管理するための強力な認証方式として、直接認証、Kerberos認証、Secure Sockets Layer (SSL)認証があります。

内容は次のとおりです。

- データベース管理者の厳密認証について

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

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

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

データベース管理者の厳密認証について

厳密認証を使用すると、複数のデータベースに対するSYSDBAおよびSYSOPERのアクセスを集中管理できます。

データベース管理のこのような認証は、次の状況で使用を検討してください。

- パスワード・ファイルの脆弱性が懸念される場合。

- サイトで非常に強固なセキュリティが要求される場合。

- アイデンティティ管理をデータベースから分離する必要がある場合。たとえば、Oracle Internet Directory(OID)などのディレクトリ・サーバーを使用すると、そのサーバーを個別にメンテナンス、保護および管理できます。

Oracle Internet Directoryサーバーを使用してSYSDBAおよびSYSOPERの接続を認可するには、使用している環境に応じて、この項で説明する次のいずれかの方式を使用します。

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

Oracle Internet Directoryで、管理ユーザーのディレクトリ認証を構成します。

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ユーザーは、厳密認証方式を使用してデータベースへの認証を行うことができます。

4. LDAP_DIRECTORY_ACCESSパラメータをPASSWORDまたはSSLのいずれかに設定します。次に例を示します。

ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = PASSWORD;

LDAP_DIRECTORY_ACCESS初期化パラメータをNONEに設定しないでください。このパラメータをPASSWORDまたはSSLに設定すると、Oracle Internet DirectoryからSYSDBAまたはSYSOPER管理権限を使用してユーザーを認証できます。

この結果、ユーザーは、SQL*PlusでCONNECT文にネット・サービス名を指定してログインできるようになります。たとえば、ネット・サービス名がorclの場合、SYSDBAとしてログインするには、次のように入力します。

CONNECT SOMEUSER@ORCL AS SYSDBA
Enter password: password

リモート認証でパスワード・ファイルを使用するようにデータベースが構成されている場合、Oracle Databaseでは最初にパスワード・ファイルをチェックします。

関連項目:

- 信頼できるユーザーへの権限付与に関するガイドラインは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください

- LDAP_DIRECTORY_SYSAUTHの詳細は、Oracle Databaseリファレンスを参照してください

- LDAP_DIRECTORY_ACCESSの詳細は、Oracle Databaseリファレンスを参照してください

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

Oracle Internet Directoryを使用して、管理ユーザーのKerberos認証を構成できます。

1. 通常のユーザーを構成するのと同じ手順で、管理ユーザーを構成します。

詳細は、Kerberos認証の構成を参照してください。

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を使用するように、次の手順でクライアントを構成します。

a. クライアント・ウォレットおよびユーザー証明書を構成します。sqlnet.ora構成ファイルのウォレットの場所を更新します。
ウォレット・マネージャを使用して、クライアント・ウォレットおよびユーザー証明書を構成します。詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

b. サーバーDNを含み、SSLとともにTCP/IPを使用するように、tnsnames.oraのOracleネット・サービス名を構成します。

c. listener.oraでSSLとともにTCP/IPを構成します。

d. sqlnet.oraで、クライアントSSL暗号スイートおよび必要なSSLバージョンを設定し、SSLを認証サービスとして設定します。

2. SSLを使用するように、次の手順でサーバーを構成します。

a. TCPSのデータベース・リスナーに対してSSLを使用可能にし、対応するTNS名を指定します。TNS名はNet Configuration Assistantを使用して構成できます。

b. データベースPKI資格証明をデータベース・ウォレットに格納します。この操作は、ウォレット・マネージャを使用して実行できます。

c. 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

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

WindowsおよびUNIXの両システムで、DBA権限のあるグループを使用してオペレーティング・システムに対して認証します。

通常、データベース管理者のオペレーティング・システム認証には、オペレーティング・システムにグループを作成すること、そのグループにDBA権限を付与すること、および権限を付与する管理者の名前をグループに追加することが含まれます。(UNIXシステムでは、このグループはdbaグループです。)

注意:

マルチテナント環境では、PDBではなくCDBルートにのみ、データベース管理者のオペレーティング・システム認証を使用できます。

Microsoft Windowsシステムの場合:

- SYSDBA管理権限で接続するユーザーはWindowsネイティブ認証を利用できます。このユーザーがドメイン・アカウントを使用してOracle Databaseを操作する場合は、ローカル管理権限およびORA_DBAメンバーシップを明示的に付与する必要があります。

- Microsoft Windows組込みのアカウントではなく、権限の低いMicrosoft Windowsのユーザー・アカウントを使用して、Oracle Databaseサービスを実行することをお薦めします。

関連項目:

- Windows固有のオペレーティング・システム・グループの詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。

- WindowsのOracle Databaseサービスの詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。

- データベース管理者のオペレーティング・システム認証の構成の詳細は、オペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

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

SYSDBA、SYSOPER、SYSASM、SYSBACKUP、SYSDGおよびSYSKM管理権限を付与されたOracle Databaseユーザーは、データベース固有のパスワード・ファイルを使用して最初に認証されます。

これらの権限によって、次のアクティビティが使用可能になります。

- 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ユーティリティを実行できます。

- 自動ストレージ管理(ASM)環境では、共有ASMパスワード・ファイルを作成できます。ASMパスワード・ファイルを作成するSYSASMシステム権限が必要なことに注意してください。詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- SESSIONS_PER_USERおよびIDLE_TIMEなどのリソース制限は、管理ログインには適用されません。

注意:

- パスワード・ファイルに含まれているユーザーのリストを検索するには、V$PWFILE_USERSデータ・ディクショナリ・ビューを問い合せることができます。

- AS SYSDBAまたはAS SYSOPERで要求された接続は、これらのフレーズを使用する必要があります。使用していない場合、接続は失敗します。Oracle DatabaseパラメータO7_DICTIONARY_ACCESSIBILITYはデフォルトではFALSEに設定されており、大切なデータ・ディクショナリへのアクセスを認可ユーザーのみに制限しています。このパラメータによって、AS SYSDBAまたはAS SYSOPER構文も必須になります。

データベース管理者認証のパスワード・ファイルを使用するリスク

パスワード・ファイルの使用は、セキュリティ上のリスクを伴う可能性があることに注意してください。

このため、「管理者の厳密認証と集中管理」で説明した認証方式を使用することを検討してください。

パスワードによるセキュリティのリスクの例は、次のとおりです。

- 侵入者がパスワード・ファイルを盗んだり攻撃する可能性があります。

- 多くのユーザーがデフォルト・パスワードを変更しない場合があります。

- パスワードが簡単に推定される場合があります。

- パスワードがディレクトリ内に存在すると、無防備になります。

- 短かすぎたり簡単に入力できるパスワードは、侵入者がパスワードの暗号化ハッシュを取得した場合に無防備になります。

注意:

パスワード・ファイルの作成およびメンテナンスの詳細は、『Oracle Database管理者ガイド』を参照してください。

ユーザーのデータベース認証

ユーザーのデータベース認証では、認証を実行するためにデータベース自体の情報を使用する必要があります。

内容は次のとおりです。

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

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

- データベースで認証されるユーザーの作成

データベース認証の概要

Oracle Databaseでは、データベース自体に格納されている情報を使用して、データベースに接続しようとするユーザーを認証できます。

データベース認証を使用するようにOracle Databaseを構成するには、対応するパスワードを指定して各ユーザーを作成する必要があります。ユーザー名にはNational Language Support (NLS)の文字書式を使用できますが、パスワードに二重引用符文字を含めることはできません。ユーザーは、接続の確立時にそのユーザー名およびパスワードを入力する必要があります。

Oracle Databaseは、ユーザーのパスワードの一方向ハッシュを生成し、入力されたログイン・パスワードの検証時に使用するため格納します。古いクライアントをサポートするために、様々なハッシング・アルゴリズムを使用してユーザーのパスワードの一方向ハッシュを生成するようにOracle Databaseを構成できます。生成されたパスワード・ハッシュはパスワード・バージョンと呼ばれ、その略称は10G、11Gおよび12Cです。略称10G、11Gおよび12Cは、一方向パスワード・ハッシング・アルゴリズムの詳細を略したものに相当します。その詳細は、ドキュメントとしてDBA_USERSビューのPASSWORD_VERSIONS列で説明されています。指定したユーザーのパスワード・バージョンのリストを確認するには、DBA_USERSビューのPASSWORD_VERSIONS列を問い合せます。

クライアントまたはクライアントとして機能するデータベース・サーバーの認証中に許可する認証プロトコルを指定するには、サーバーsqlnet.oraファイルのSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを明示的に設定できます。(このパラメータのクライアント・バージョンは、SQLNET.ALLOWED_LOGON_VERSION_CLIENTです。)各接続がテストされ、クライアントまたはサーバーがパートナが指定する最低バージョンを満たしていない場合は、認証に失敗してORA-28040「一致する認証プロトコルがありません」エラーが発生します。このパラメータの値には、11、10、9または8を指定できます。デフォルト値は11です。これらの値はデータベース・サーバーのバージョンを表します。保護レベルを最大にするには、値11をお薦めします。ただし、SQLNET.ALLOWED_LOGON_VERSION_SERVERおよびSQLNET.ALLOWED_LOGON_VERSION_CLIENTを11に設定した場合、JDBCシン・クライアントを含むOracle Databaseリリース11.1以前のクライアント・アプリケーションは、パスワード・ベースの認証を使用してOracleデータベースへの認証を行うことができない点に注意してください。

データベース認証使用時のセキュリティを高めるために、アカウントのロック、パスワード・エイジングと期限切れ、パスワード履歴およびパスワードの複雑度検証も含めたパスワード管理の使用をお薦めします。

関連項目:

- パスワード複雑度検証関数の詳細は、「パスワードの複雑度検証の概要」を参照してください。

- パスワード管理の詳細は、「パスワード管理ポリシーの使用」を参照してください。

データベース認証の利点

データベースを使用したユーザーの認証では、次の3つのメリットがあります。

これらのメリットは次のとおりです。

- ユーザー・アカウントとすべての認証がデータベースによって制御されます。データベースの外部のものには依存しません。

- Oracle Databaseには、データベース認証使用時のセキュリティを高めるために、強力なパスワード管理機能が組み込まれています。

- 小規模なユーザー・コミュニティがある場合の管理が容易になります。

データベースで認証されるユーザーの作成

データベースで認証されるユーザーを作成する場合、このユーザーにパスワードを割り当てます。

- データベースで認証されるユーザーを作成するには、ユーザーの作成時にIDENTIFIED BY句を指定します。

たとえば、次の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)プロトコルは、アプリケーション・レイヤー・プロトコルです。

SSLは、Oracle Internet Directoryでのグローバル・ユーザー管理とは関係なく、データベースに対するユーザー認証に使用できます。つまり、ユーザーは、ディレクトリ・サーバーを指定しなくても、SSLを使用してデータベースへの認証を行うことができます。

関連項目:

SSLの構成の詳細は、Secure Sockets Layer認証の構成を参照してください

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

ネットワーク経由でOracle Databaseを認証するには、サード・パーティのサービス(Kerberos、RADIUS、ディレクトリベース・サービス、公開鍵インフラストラクチャ)を使用する必要があります。

内容は次のとおりです。

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

- Kerberosを使用した認証

- RADIUSを使用した認証

- ディレクトリベース・サービスを使用した認証

- 公開鍵インフラストラクチャを使用した認証

サード・パーティ・サービスを使用した認証について

ネットワーク上のOracle Databaseユーザーを認証する場合は、サード・パーティ・ネットワーク認証サービスを使用する必要があります。

よく知られている例としては、Kerberos、PKI (公開鍵インフラストラクチャ)、RADIUS (Remote Authentication Dial-In User Service)、およびディレクトリ・ベース・サービスがあります。

ネットワーク認証サービスを使用できる場合、Oracle Databaseはこれらのネットワーク・サービスによる認証を受け入れることができます。ネットワーク認証サービスを使用する場合は、ネットワーク・ロールとデータベース・リンクについて特別な考慮事項があります。

Kerberosを使用した認証

Kerberosは、共有秘密を使用するサード・パーティの認証システムです。

Kerberosは、サード・パーティがセキュアであることを保証し、シングル・サインオン機能、集中化されたパスワード・ストレージ、データベース・リンク認証、拡張されたPCセキュリティを提供します。これは、Kerberos認証サーバーまたはCybersafe Active Trust (Kerberosをベースとした商用の認証サーバー)を介して提供されます。

関連項目:

Kerberosの詳細は、Kerberos認証の構成を参照してください

RADIUSを使用した認証

Remote Authentication Dial-In User Service (RADIUS)はユーザー認証、認可、およびアカウンティングに使用される標準のライトウェイト・プロトコルです。

RADIUSにより、ユーザーはRSA One-Time Password Specifications (OTPS)を使用してOracleデータベースに対する認証もできるようになります。

関連項目:

- RADIUSの構成の詳細は、RADIUS認証の構成を参照してください

- OTPSに関するRSAのドキュメント

ディレクトリベース・サービスを使用した認証

中核となるディレクトリを使用すると、認証とその管理が効率的になります。

次のようなディレクトリベース・サービスがあります。

- Lightweight Directory Access Protocol (LDAP)を使用するOracle Internet Directoryにより、中央リポジトリを使用してユーザー(エンタープライズ・ユーザーと呼ばれます)に関する情報を格納および管理できます。エンタープライズ・ユーザーのアカウントは、分散環境で作成されます。データベース・ユーザーの場合は、アクセスするデータベースごとにパスワードとともに作成する必要がありますが、エンタープライズ・ユーザーの情報にはOracle Internet Directoryで集中的にアクセスできます。このディレクトリをMicrosoft Active DirectoryやSunOneと統合することもできます。

- Oracle Enterprise Security Managerを使用すると、Oracle Internet Directoryからのロールの取得と保管ができ、これにより権限の集中管理が可能になることで管理が容易になり、セキュリティ・レベルが向上します。

公開鍵インフラストラクチャを使用した認証

公開鍵インフラストラクチャ(PKI)に基づく認証システムでは、ユーザー・クライアントに電子証明書が発行されます。

これらのクライアントはこの証明書を使用して直接企業内のサーバーに身分を証明し、認証に直接的に関与しません。Oracle Databaseで提供されている、公開鍵と証明書を使用するためのPKIは、次のコンポーネントで構成されています。

- SSLによる認証および保護セッション鍵管理。詳細は、Secure Sockets Layerを使用した認証を参照してください。

- 信頼できる証明書。識別情報を検証するときに、ユーザー証明書の署名者として信頼するサード・パーティ・エンティティを識別するために使用します。ユーザーの証明書が確認されるとき、署名者は、検証システムに格納されている認証局のトラスト・ポイントまたは信頼できる証明連鎖を使用してチェックされます。この連鎖内に複数レベルの信頼できる証明書がある場合は、下位レベルの証明書を信頼するため、それより上のレベルの証明書をすべて再検証する必要はありません。

- Oracle Wallet Manager。Oracleウォレットは、ユーザーの秘密鍵、ユーザー証明書および一連のトラスト・ポイント(信頼できる認証局)を含むデータ構造です。Oracleウォレットの管理の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
Oracle Wallet Managerを使用してOracleウォレットを管理できます。これは、Oracleウォレットのセキュリティ資格証明を管理および編集するために使用するスタンドアロンのJavaアプリケーションです。次の操作を実行します。

- 公開鍵と秘密鍵のペアを生成し、認証局に提出する証明書要求を作成して、ウォレットを作成します。

- エンティティの証明書をインストールします。

- Oracle Databaseのクライアントとサーバー上でX.509v3証明書を管理します。

- エンティティの信頼できる証明書を構成します。

- ウォレットをオープンして、PKIベースのサービスにアクセスできるようにします。

- 信頼できるエンティティ、認証局から取得された(署名された) X.509バージョン3証明書。認証局は信頼されているため、これらの証明は要求側エンティティの情報が正確であることと証明書上の公開鍵が認定されるエンティティに属していることを証明します。証明書はOracleウォレットにロードされるため、今後の認証が可能になります。

ユーザーのグローバル認証とグローバル認可

ユーザーのグローバル認証とグローバル認可を使用すると、ユーザー関連情報を一元管理できます。

内容は次のとおりです。

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

- ディレクトリ・サービスで認可されるユーザーの構成

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

グローバルなユーザー認証と認可の構成について

LDAPベースのディレクトリ・サービスで、認可も含めたユーザー関連情報を集中管理します。

これにより、ユーザーおよび管理者はデータベース内でグローバル・ユーザーとして識別されます。これは、そのユーザーがSSLによって認証され、ユーザーの管理がデータベースの外部で集中化されたディレクトリ・サービスによって行われることを意味します。グローバル・ロールはデータベース内で定義され、そのデータベースに対してのみ認識されますが、グローバル・ロールに対する認可はディレクトリ・サービスによって行われます。

注意:

ユーザーはSecure Sockets Layer (SSL)で認証されるユーザーであっても構いません。この場合、認可はディレクトリで管理されておらず、これらのユーザーが持っているのはローカル・データベース・ロールのみです。

このような集中管理によって、エンタープライズ・ユーザーとエンタープライズ・ロールの作成が可能になります。エンタープライズ・ユーザーの定義と管理は、ディレクトリ内で行います。エンタープライズ・ユーザーには企業内で一意の識別情報があり、複数データベースにまたがるアクセス権限を決定するエンタープライズ・ロールを割り当てることができます。エンタープライズ・ロールは1つ以上のグローバル・ロールで構成されているため、グローバル・ロールのコンテナとみなすことができます。

関連項目:

- Secure Sockets Layer認証の詳細は、「管理ユーザーのSecure Sockets Layer認証の構成」を参照してください。

- SYSDBAまたはSYSOPERのアクセスを集中管理する場合は、「管理者の厳密認証と集中管理」を参照してください。

ディレクトリ・サービスで認可されるユーザーの構成

ディレクトリ・サービスで認可されるようにグローバル・ユーザーまたは複数のエンタープライズ・ユーザーを構成できます。

内容は次のとおりです。

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

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

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

プライベート・スキーマを持つユーザー・アカウントを作成するには、エンタープライズ・ディレクトリにとって有意義な識別子(識別名またはDN)を指定します。

ただし、ユーザーによるアクセスが必要なすべてのデータベースとディレクトリにこのユーザーを作成する必要があることに注意してください。

- プライベート・スキーマを持つグローバル・ユーザーを作成するには、CREATE USER ... IDENTIFIED GLOBALLY SQL文を使用します。
標準のLDAPデータ交換形式(LDIF)フィールドを含むことができます。たとえば、SSLによって認証され、エンタープライズ・ディレクトリ・サービスによって認可される、プライベート・スキーマを持つグローバル・ユーザー(psmith_gl)を作成するには、次のようにします。

CREATE USER psmith_gl IDENTIFIED GLOBALLY AS 'CN=psmith,OU=division1,O=example,C=US';

次のように値を指定します。

- CNは、このユーザーの共通名psmith_glを示します。

- OUは、ユーザーの組織単位division1を示します。

- Oは、ユーザーの組織Exampleを示します。

- Cは、組織の例が配置される国USを示します。

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

複数のエンタープライズ・ユーザーがデータベース内の1つのスキーマを共有できます

これらのユーザーは、エンタープライズ・ディレクトリ・サービスによって認可されますが、データベース内に個々のプライベート・スキーマを持ちません。また、ユーザーはデータベース内に個別に作成されません。ユーザーは、データベース内の共有スキーマに接続します。

1. 次の例を使用して、データベースに共有スキーマを作成します。

CREATE USER appschema IDENTIFIED GLOBALLY AS '';

2. ディレクトリに、複数のエンタープライズ・ユーザーとマッピング・オブジェクトを作成します。

このマッピング・オブジェクトは、ユーザーのDNを共有スキーマにマップする方法をデータベースに伝えます。完全な識別名(DN)マッピング(一意のDN 1つに対して1つのディレクトリ・エントリが対応する)を作成するか、または、ユーザーごとに複数のDNコンポーネントを1つのスキーマにマップできます。次に例を示します。

OU=division1,O=Example,C=US

関連項目:

これらのマッピングの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』 を参照してください。

ほとんどのユーザーは専用スキーマを必要としないため、スキーマに依存しないユーザーを実装することで、ユーザーをデータベースから切り離すことができます。データベース内で同じスキーマを共有する複数のユーザーを作成すると、各ユーザーは他のデータベース内の共有スキーマにもエンタープライズ・ユーザーとしてアクセスできます。

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

ユーザーのグローバル認証とグローバル認可には、複数のメリットがあります。

- SSL、KerberosまたはWindowsネイティブ認証を使用して、厳密な認証が行われます。

- ユーザーと権限を全社規模で集中管理できます。

- 管理が容易です。ユーザーごとに、社内の各データベースにスキーマを作成する必要がありません。

- シングル・サインオンが容易になります。ユーザーは1回のサインオンのみで複数のデータベースおよびサービスにアクセスできます。さらに、パスワードを使用しているユーザーは、パスワード認証されたエンタープライズ・ユーザーを受け入れる複数データベースにアクセスするための単一パスワードを持つことができます。

- グローバルなユーザー認証と認可はパスワード・ベースのアクセスを提供するため、以前に定義されたパスワード認証方式のデータベース・ユーザーを、集中管理されているディレクトリに(ユーザー移行ユーティリティを使用して)移行できます。これによって、以前のリリースのOracle Databaseクライアントで使用可能だったグローバル認証と認可が引き続きサポートされます。

- CURRENT_USERデータベース・リンクはグローバル・ユーザーとして接続します。ローカル・ユーザーはストアド・プロシージャとの関連においてグローバル・ユーザーとして、グローバル・ユーザー・パスワードをリンク定義に保管することなく、接続できます。

関連項目:

グローバル認証と認可、エンタープライズ・ユーザーおよびエンタープライズ・ロールの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

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

外部サービス(オペレーティング・サービスまたはネットワークのいずれか)は、パスワードの管理とユーザーの認証に使用されます。

内容は次のとおりです。

- 外部認証の概要

- 外部認証の利点

- 外部認証の有効化

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

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

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

外部認証の概要

外部認証を使用する場合、ユーザー・アカウントはOracle Databaseでメンテナンスされますが、パスワード管理とユーザー認証は外部サービスによって実行されます。

この外部サービスは、オペレーティング・システムでもOracle Netのようなネットワーク・サービスでもかまいません。

外部認証の場合、データベースはデータベース・アカウントへのアクセス制限を、その基礎となるオペレーティング・システムまたはネットワーク認証サービスに依存します。データベース・パスワードは、このタイプのログインには使用されません。オペレーティング・システムまたはネットワーク・サービスで許可されている場合は、それにより、ユーザーがデータベースにログインする前にユーザーを認証できます。

外部認証の利点

外部認証には、複数のメリットがあります。

これらのメリットは次のとおりです。

- スマートカード、指紋、Kerberos、オペレーティング・システムなど、使用可能な認証メカニズムの選択肢が増えます。

- Kerberosなどのネットワーク認証サービスの多くがシングル・サインオンをサポートしているため、ユーザーは多数のパスワードを記憶する必要がありません。

- 前述の外部認証メカニズムのいずれかをすでに使用している場合は、そのメカニズムをデータベースで使用することで、管理費用を節減できます。

外部認証の有効化

外部認証を使用可能にするには、初期化パラメータOS_AUTHENT_PREFIXを設定し、この接頭辞をOracle Databaseユーザー名で使用します。

このOS_AUTHENT_PREFIXパラメータは、Oracle Databaseで全ユーザーのオペレーティング・システム・アカウント名の先頭に追加する接頭辞を定義します。Oracle Databaseは、ユーザーが接続しようとすると、接頭辞付きのユーザー名をデータベース内のOracle Databaseユーザー名と比較します。

1. OS_AUTHENT_PREFIXをNULL文字列(空の二重引用符""で指定)に設定します。NULL文字列を使用すると、オペレーティング・システム・アカウント名に接頭辞は追加されないため、Oracle Databaseユーザー名とオペレーティング・システム・ユーザー名は完全に一致します。

次に例を示します。

OS_AUTHENT_PREFIX=" "

2. OS_AUTHENT_PREFIXはデータベースの存続期間中は必ず同じままにします。接頭辞を変更した場合、古い接頭辞を含むデータベース・ユーザー名は、パスワード認証を使用するように変更しないかぎり、接続に使用できません。

OS_AUTHENT_PREFIXパラメータのデフォルト値はOPS$であり、これによって古いバージョンのOracle Databaseとの下位互換性を維持しています。たとえば、OS_AUTHENT_PREFIXを次のように設定する場合を想定します。

OS_AUTHENT_PREFIX=OPS$

オペレーティング・システム・アカウント名tsmithを持つユーザーが、Oracleデータベース・インストールに接続する際にオペレーティング・システムによって認証された場合、Oracle Databaseは対応するデータベース・ユーザーOPS$tsmithの存在をチェックし、存在している場合はこのユーザーを接続できます。オペレーティング・システムによって認証されたユーザーへの参照には、OPS$tsmithのように、必ず接頭辞OPS$が含まれる必要があります。

注意:

OS_AUTHENT_PREFIX初期化パラメータに指定する文字列は、オペレーティング・システムによって大/小文字が区別される場合があります。この初期化パラメータの詳細は、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

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

外部認証されるユーザーは、オペレーティング・システムやネットワーク・サービスで認証されます。

外部認証されるユーザーを作成できます。Oracle Databaseがこの外部ログイン認証に依存するのは、特定のユーザーのデータベース・リソースへのアクセス権を特定のオペレーティング・システム・ユーザーに付与する場合です。

- CREATE USER文のIDENTIFIED EXTERNALLY句を使用して、外部認証されるユーザーを作成します。

次の例では、Oracle Databaseによって識別され、オペレーティング・システムまたはネットワーク・サービスによって認証されるユーザーを作成します。この例では、OS_AUTHENT_PREFIXパラメータは空白(" ")に設定されていると想定しています。

CREATE USER psmith IDENTIFIED EXTERNALLY;

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

Oracle Databaseで許可されるオペレーティング・システム認証ログインは、保護された接続のみを介したログインであるため、Oracle Netおよび共有サーバー構成を使用したログインは含まれません。

このタイプのオペレーティング・システム認証がデフォルトです。この制限によって、リモート・ユーザーが、ネットワーク接続を介して別のオペレーティング・システムのユーザーになりすますことを防止します。

データベース初期化パラメータ・ファイルでREMOTE_OS_AUTHENTパラメータをTRUEに設定すると、データベースは保護されていない接続を介して受け取ったクライアント・オペレーティング・システム・ユーザー名を受け入れてアカウント・アクセスに使用します。一般にPCなどのクライアントは、オペレーティング・システムの認証を適切に実行していない場合があるため、この機能を有効にするとセキュリティが非常に低下します。

デフォルトの設定REMOTE_OS_AUTHENT = FALSEを使用すると、安全性の高い構成となり、Oracleデータベースに接続するクライアントがサーバーベースで適切に認証されます。

REMOTE_OS_AUTHENTパラメータは、Oracle Database 11g リリース1(11.1)では非推奨となっており、下位互換性のためにのみ保持されている点に注意してください。

このパラメータに対する変更は、次回インスタンスを起動して、データベースをマウントしたときに有効となります。一般的に、ホスト・オペレーティング・システムを介したユーザー認証では、個別のデータベース・ユーザー名やパスワードを指定せずに、Oracle Databaseに迅速かつ簡便に接続できます。ユーザー・エントリも、データベースとオペレーティング・システムの各監査証跡で互いに対応します。

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

Oracle厳密認証が実行するネットワーク認証は、Kerberosなどのサード・パーティ・サービスを使用するよう構成できます。

Oracle厳密認証を唯一の外部認証サービスとして使用している場合、Oracle厳密認証で可能になるのは保護された接続のみであるため、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 Call Interface (OCI)、JDBC/OCIまたはJDBCシン・ドライバによって、データベース・ユーザーまたはエンタープライズ・ユーザーのプロキシ認証に中間層を使用できます。

内容は次のとおりです。

- プロキシ認証の概要

- プロキシ認証の利点

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

- プロキシ・ユーザー・アカウントの作成のガイドライン

- プロキシ・ユーザー・アカウントと、そのアカウントを介して接続するユーザーの認可

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

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

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

- 中間層の権限の制限

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

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

- 中間層を介したデータベースへのユーザーの再認証

プロキシ認証の概要

Oracle Databaseでは、Oracle Call Interface(OCI)、JDBC/OCIまたはJDBCシン・ドライバによって、データベース・ユーザーまたはエンタープライズ・ユーザーにプロキシ認証を提供します。

エンタープライズ・ユーザーは、Oracle Internet Directoryで管理されるユーザーで、データベースの共有スキーマにアクセスします。

次の3つの形式のプロキシ認証を使用して、クライアントを認証する中間層サーバーを安全な方法で設計できます。

- 中間層サーバーは、データベース・サーバーを使用してそれ自体を認証し、クライアント(この場合はアプリケーション・ユーザーまたは別のアプリケーション)は、この中間層サーバーを使用してそれ自体を認証します。クライアントの識別情報は、データベースに到達するまで確実に保持されます。

- クライアント(この場合はデータベース・ユーザー)は、中間層サーバーによって認証されません。クライアントの識別情報とデータベース・パスワードは、中間層サーバーを経由してデータベース・サーバーに渡され、そこで認証されます。

- クライアント(この場合はグローバル・ユーザー)は中間層サーバーによって認証され、中間層を介して次のいずれかを渡します。クライアントのユーザー名はそこから取得されます。

- 識別名(DN)

- 証明書

いずれの場合でも、中間層サーバーにクライアントの代理としての機能を与えるために、管理者は中間層サーバーを認可する必要があります。

関連項目:

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

- プロキシ認証の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

プロキシ認証の利点

複数層環境の場合、プロキシ認証は、中間層アプリケーションのすべての層を通じて、クライアント・アクションを監査してクライアントの識別情報と権限を保持します。

たとえば、この機能によって、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権限のみを付与します。このユーザーに他の一切の権限を付与しないでください。プロキシ・ユーザー・アカウントは、他のユーザーがプロキシ・アカウントを使用して接続できるようにする場合にのみ使用されます。接続中に実施されるすべての権限は、プロキシ・アカウントではなく、接続しているユーザーに属する必要があります。

- すべてのパスワードと同様、プロキシ・ユーザーに作成するパスワードも強力であり容易に推測されないものにしてください。複数のユーザーがプロキシ・ユーザーとして接続することになるため、このパスワードを強力にすることが特に重要であることを忘れないでください。強力なパスワードの作成に関するガイドラインは、「パスワードの保護に関するガイドライン」を参照してください。

- Oracle厳密認証ネットワーク接続機能を使用してネットワーク傍受を防ぐことを検討してください。

- 接続ユーザーが持っている制御の量をさらに微調整する場合は、接続ユーザーがプロキシ・アカウントを介して接続しているときに使用するロールを制限することを検討してください。ALTER USER文のWITH ROLE句を使用すると、指定されたロールまたは指定されたロール以外のロールを使用して接続するユーザー、あるいはロールをまったく使用せずに接続するユーザーを構成できます。プロキシ・ユーザーは、WITH ROLE句に含まれているロールのみアクティブにできることに注意してください。プロキシ・ユーザー・セッションには、クライアント(つまり現在の)ユーザーに直接付与されたすべての権限が付与されます。

プロキシ・ユーザー・アカウントと、そのアカウントを介して接続するユーザーの認可

CREATE USER文を使用すると、次のタイプのユーザー・アカウントを作成でき、これらのすべてがプロキシ・アカウントとして使用できます。

これらのアカウントを次に示します。

- パスワードによって認証されるデータベース・ユーザー・アカウント

- 外部ユーザー・アカウント。Secure Socket Layer (SSL)やKerberosなどの外部ソースによって認証されます。

- グローバル・ユーザー・アカウント。エンタープライズ・ディレクトリ・サービス(Oracle Internet Directory)によって認証されます。

次のことに注意してください。

- プロキシ・ユーザーが実行できるのは、ユーザー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パスワードの期限切れは、プロキシを介して認証されたアカウントに適用されません。パスワードを期限切れにするかわりに、アカウントをロックしてください。

関連項目:

- エンタープライズ・ユーザー環境におけるプロキシ・ユーザーの管理に関する詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- ユーザーのかわりに中間層が行う監査操作の詳細は、「複数層環境におけるSQL文および権限の監査」を参照してください。

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

CREATE USERおよびALTER USER文を使用してプロキシ・ユーザーを作成し、このプロキシ・ユーザーを介したユーザーの接続を認可できます。

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

関連項目:

- CREATE USER文に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- ALTER USER文に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

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

不正なユーザーが取得するプロキシ認証で使用されるパスワードが懸念される場合、安全性の高い外部パスワード・ストアを使用します。

これを実行するには、ウォレットにパスワード資格証明を格納するためにプロキシ認証とともに安全性の高い外部パスワード・ストアを使用します。

プロキシ認証と安全性の高い外部パスワード・ストアを使用したOracle Databaseへの接続は、バッチ・ファイルを実行するなどの状況に理想的です。プロキシ・ユーザーがデータベースに接続し、安全性の高い外部パスワードを使用して認証を行うと、不正なユーザーが取得しようとしてもパスワードは公開されません。

安全性の高い外部パスワード・ストアとプロキシ認証を使用する手順は、次のとおりです。

1. 「プロキシ・ユーザー・アカウントと、そのアカウントを介して接続するユーザーの認可」の手順に示すように、プロキシ認証アカウントを構成します。

2. 「外部パスワード・ストアの使用を目的とするクライアントの構成について」の説明に従って、安全性の高い外部パスワード・ストアを構成します。

その後、ユーザーはパスワードを指定せずにプロキシを使用して接続できます。例:

sqlplus [preston]/@db_alias

安全性の高い外部パスワード・ストアを使用すると、ユーザーはログイン時にユーザー名とパスワードを入力する必要がありません。指定する必要があるのは、tnsnames.oraファイルのSERVICE_NAME値(つまり、db_alias)のみです。

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

エンタープライズ・ユーザーまたはデータベース・ユーザー用のOracle Call Interface、JDBC/OCIまたはシン・ドライバを使用できます。

これらのツールにより、中間層で単一データベース接続内の複数のユーザー・セッションを設定できます。それぞれ接続されたユーザーを一意に識別します(接続プーリング)

これらのセッションにより、中間層からデータベースまで別個のネットワーク接続を作成することによるネットワーク・オーバーヘッドが削減されます。

クライアントから中間層を介してデータベースに対して認証する場合の完全な認証順序は次のようになります。

1. クライアントは、中間層が受け入れる任意の認証形式を使用して、中間層に対する認証を行います。たとえば、クライアントは、ユーザー名とパスワード、またはSSLによるX.509証明書を使用して、中間層に対する認証を実行できます。

2. 中間層は、データベースが受け入れる任意の認証形式を使用して、中間層自体をデータベースに対して認証します。認証形式には、パスワード、またはKerberosチケットやX.509証明書(SSL)などのOracle Databaseがサポートしている認証メカニズムがあります。

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ロールのみを使用できるように中間層を制限します。

管理者は、次のSQL文を使用して、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から削除されています。

ロールの詳細は、「権限とロール認可の構成」を参照してください。

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

ユーザーとして接続する中間層サーバーを認可できます。

- ユーザーとして接続する中間層サーバーを認可するには、ALTER USER文を使用します。

次の文は、中間層サーバーappserveがユーザーbillとして接続するのを認可します。WITH ROLE句を使用して、appserveがbillに関連付けられた、payrollを除くすべてのロールをアクティブにするよう指定します。

ALTER USER bill
GRANT CONNECT THROUGH appserve
WITH ROLE ALL EXCEPT payroll;

ユーザーbillとして接続するための中間層サーバーの(appserve)認可を取り消すには、REVOKE CONNECT THROUGH句を使用できます。次に例を示します。

ALTER USER bill REVOKE CONNECT THROUGH appserve;

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

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

現在サポートされている認証方式は、PASSWORDのみです。

- ALTER USER ... GRANT CONNECT THROUGH文の AUTHENTICATION REQURED句を使用して、中間層がプロキシ化するユーザーを認可するが、認証はしません。

次に例を示します。

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でユーザーを検索します。

- エンタープライズ・ユーザーでプロキシ認証を構成するには、適切なOracle Call Interface設定を使用するようにアプリケーション・サーバーと中間層を構成します。

- クライアントの識別名を渡す場合、次のように、属性タイプとして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の使用

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

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

- システム全体でのCLIENTID_OVERWRITEイベントの有効化

- 現在のセッションに対するCLIENTID_OVERWRITEイベントの有効化

- CLIENTID_OVERWRITEイベントの無効化

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

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の設定

グローバル・アプリケーション・コンテキストから独立するように、Oracle Call Interfaceによって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およびDMSメトリックを使用してクライアント接続を構成する方法の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください

- setClientInfoメソッドの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください

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

DBMS_SESSION PL/SQLパッケージは、中間層とデータベース自体の両方でクライアント識別子を管理します。

DBMS_SESSIONパッケージを使用して、中間層でCLIENT_IDENTIFIERの値を設定および消去するには、SET_IDENTIFIERプロシージャとCLEAR_IDENTIFIERプロシージャを使用します。

中間層では、SET_IDENTIFIERを使用してデータベース・セッションを特定のユーザーまたはグループに対応付けます。この結果、CLIENT_IDENTIFIERはセッションの属性になるため、セッション情報で確認できます。

DBMS_SESSION.SET_IDENTIFIERプロシージャを使用する場合、次の点に注意してください。

- DBMS_SESSION.SET_IDENTIFIERのclient_idパラメータのバイトの最大数は64バイトです。64を超える場合、追加のバイトが切り捨てられます。

- DBMS_APPLICATION_INFO.SET_CLIENT_INFOプロシージャは、クライアント識別子の値を上書きできます。通常、これらの値は一致する必要があるため、CLIENTID_OVERWRITEイベントがONに設定されている場合は、SET_CLIENT_INFOが設定されていれば、その値をSET_IDENTIFIERにより設定された値に自動的に伝播できます。CLIENTID_OVERWRITEイベントの状態をチェックするには、SHOW PARAMETERコマンドをEVENTパラメータで実行します。
たとえば、CLIENTID_OVERWRITEが使用可能になっているとします。

SHOW PARAMETER EVENT

NAME                           TYPE               VALUE
------------------------------ ------------------ ------------------
event                          string             clientid_overwrite

システム全体でのCLIENTID_OVERWRITEイベントの有効化

ALTER SYSTEM文では、システム全体でCLIENTID_OVERWRITEイベントを有効化できます。

1. 次のALTER SYSTEM文を入力します。

ALTER SYSTEM SET EVENTS 'CLIENTID_OVERWRITE';

または、init.oraファイルに次の行を入力します。

event="clientid_overwrite"

2. データベースを再起動します。

次に例を示します。

SHUTDOWN IMMEDIATE
STARTUP

関連項目:

- クライアント識別子をグローバル・アプリケーション・コンテキストで使用する方法は、「グローバル・アプリケーション・コンテキスト」を参照してください

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

現在のセッションに対するCLIENTID_OVERWRITEイベントの有効化

ALTER SESSION文では、現在のセッションのみに対してCLIENTID_OVERWRITEイベントを有効化できます。

1. ALTER SESSION文を使用して、セッションのみに対してCLIENTID_OVERWRITEの値を設定します。

次に例を示します。

ALTER SESSION SET EVENTS 'CLIENTID_OVERWRITE OFF';

2. DBMS_APPLICATION_INFO.SET_CLIENT_INFOプロシージャを使用してクライアント識別子を設定する場合は、クライアント識別子の設定が同一になるようにDBMS_SESSION.SET_IDENTIFIERを実行します。

次に例を示します。

DBMS_SESSION.SET_IDENTIFIER(session_id_p);

CLIENTID_OVERWRITEイベントの無効化

ALTER SYSTEM文では、CLIENTID_OVERWRITEイベントを無効化できます。

1. 次のALTER SYSTEM文を入力します。

ALTER SYSTEM SET EVENTS 'CLIENTID_OVERWRITE OFF';

2. データベースを再起動します。

次に例を示します。

SHUTDOWN IMMEDIATE
STARTUP

ユーザー認証のデータ・ディクショナリ・ビュー

Oracle Databaseには、ユーザーのロールや使用しているプロファイルなど、ユーザー認証に関する情報を表示するデータ・ディクショナリ・ビューが用意されています。

表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列)。現在のプラガブル・データベース(PDB)に適用します

V$PWFILE

パスワード・ファイルに含まれている管理ユーザーの名前と付与されている管理権限を表示します。

V$SESSION

USERNAME列を問い合せると、現在のPDBに同時ログインしているユーザーが表示されます

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

権限とロールの認可を使用すると、ユーザーが毎日のタスクを実行するために保持する権限を制御します。

内容は次のとおりです。

- 権限とロールの概要

- 権限付与の対象者

- Oracleマルチテナント・オプションが権限に影響を与えるしくみ

- 管理権限の管理

- システム権限の管理

- 共通およびローカルに付与される権限の管理

- 共通ロールおよびローカル・ロールの管理

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

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

- 表権限

- 表示権限

- プロシージャ権限

- タイプ権限

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

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

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

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

- SET ROLEおよびデフォルト・ロールの設定による権限の付与と取消しの機能

- ユーザー権限およびロールのデータ・ディクショナリ・ビュー

関連項目:

- 定義者権限および実行者権限のセキュリティの管理

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

- 権限の使用を分析するポリシーの作成方法の詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

権限とロールの概要

認可とは、データへのアクセス、処理または変更を特定のユーザーに許可するほか、ユーザーのアクセスやアクションに関する制限を作成するものです。

ユーザーに対して課せられる(または除外される)制限は、スキーマ、表全体または表の行などのオブジェクトに適用できます。

ユーザー権限とは、特定タイプのSQL文を実行する権利、別のユーザーのオブジェクトにアクセスする権利、PL/SQLパッケージを実行する権利などを指します。権限のタイプは、Oracle Databaseによって定義されています。

ロールは、ユーザー(通常は管理者)が権限や他のロールをグループ化するために作成します。ロールを使用すると、複数の権限またはロールをユーザーに簡単に付与できます。

権限は、次の一般的なカテゴリに分類されます。

- システム権限。この権限の受領者は、データベースで標準的な管理作業を実行できます。権限受領者は信頼できるユーザーのみに制限してください。権限について説明している次の項を参照してください。

- 管理権限の管理

- システム権限の管理

- 共通およびローカルに付与される権限の管理

- ロール。ロールでは、複数の権限やロールがグループ化されるため、複数のユーザーに対して権限を同時に付与したり、取り消すことができます。ユーザーによるロールの使用を可能にするには、そのユーザーに対してロールを使用可能にしておく必要があります。詳細は、次の各項を参照してください。

- 共通ロールおよびローカル・ロールの管理

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

- オブジェクト権限。オブジェクトの各タイプには、オブジェクト権限が対応付けられています。異なるタイプのオブジェクト権限を管理する方法は、オブジェクト権限の管理を参照してください。

- 表権限。これらの権限によって、DML (データ操作言語)またはDDL (データ定義言語)レベルでセキュリティが有効になります。表権限の管理方法の詳細は、表権限を参照してください。

- 表示権限。DMLオブジェクト権限は、表の場合と同様にビューに対しても適用できます。詳細は、ビューに対する権限を参照してください。

- プロシージャ権限。スタンドアロン・プロシージャ、ファンクションを含め、プロシージャにはEXECUTE権限を付与できます。詳細は、「プロシージャ権限」を参照してください。

- タイプ権限。システム権限は名前付きタイプ(オブジェクト・タイプ、VARRAYおよびネストした表)に付与できます。詳細は、タイプ権限を参照してください。

関連項目:
権限の使用を分析するポリシーの作成方法の詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

権限付与の対象者

権限をユーザーに付与すると、そのユーザーはそれぞれの業務に必要な作業を実行できます。

なお、権限は、必要な作業を実行する上でその権限が必要なユーザーにのみ付与してください。必要でない権限まで付与すると、セキュリティを維持できなくなる可能性があります。たとえば、管理作業を実行しないユーザーには、SYSDBA管理権限またはSYSOPER権限を付与しないでください。

権限は、次の2つの方法でユーザーに付与できます。

- 権限を明示的にユーザーに付与します。たとえば、employees表にレコードを挿入する権限を、ユーザーpsmithに明示的に付与できます。

- 権限をロール(名前付きの権限グループ)に付与した上で、そのロールを1人以上のユーザーに付与します。たとえば、employees表からレコードを選択、挿入、更新および削除する権限を、clerkという名前のロールに付与し、このロールをユーザーpsmithやrobertに付与できます。

ロールを使用することで権限の管理が容易になり、改善されるため、通常は権限を個々のユーザーではなくロールに付与してください。

関連項目:

- 権限を付与する際に従うベスト・プラクティスは、ユーザー・アカウントと権限の保護に関するガイドラインを参照してください

- 過度の権限付与が懸念される場合は、『Oracle Database Vault管理者ガイド』を参照してください。

- システム権限の完全なリストとその詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

Oracleマルチテナント・オプションが権限に影響を与えるしくみ

マルチテナント環境では、共通ユーザーを含むすべてのユーザーは、現在のコンテナ内でのみ権限を実行できます。

ただし、ルートに接続されているユーザーは、他のプラガブル・データベース(PDB)に影響を与える特定の操作を実行できます。これらの操作には、ALTER PLUGGABLE DATABASE、CREATE USER、CREATE ROLEおよびALTER USERが含まれます。共通ユーザーは、これらの操作を可能にする、共通に付与される権限を所有している必要があります。ルートに接続されている共通ユーザーは、ビューにアクセスするために必要な権限を付与されていて、様々なPDBに関するデータを表示できるようにCONTAINER_DATA属性が設定されている場合、ルートのコンテナ・データ・オブジェクト(たとえば、マルチテナント・コンテナ・データベース(CDB)・ビューやV$ビューなど)を介してPDBに関するメタデータを確認できます。共通ユーザーは、PDBの表またはビューに問合せできません。

共通ユーザーは、他のPDBの権限を実行できません。必要なPDBに最初に切り替えて、そこから権限を実行する必要があります。異なるコンテナに切り替えるには、共通ユーザーにSET CONTAINER権限が必要です。SET CONTAINER権限は、共通に付与するか、ユーザーが切り替えようとしているコンテナ内で付与する必要があります。また、共通ユーザーは、そのPDBのCREATE SESSION権限に応じて、現在の初期コンテナがこのユーザーが必要とするコンテナである新しいデータベース・セッションを開始できます。

共通に付与された権限が個々のPDBに構成されたセキュリティを妨げる場合があるので注意してください。たとえば、アプリケーションPDBのデータベース管理者がPDBのいずれのユーザーも特定のアプリケーション共通オブジェクトを変更できないようにするとします。PUBLICまたはオブジェクトの共通ユーザーもしくは共通ロールに共通に付与された権限(UPDATEなど)は、PDBのデータベース管理者の意図に反した動作をします。

関連項目:

- コンテナ・データ・オブジェクトの詳細は、共通ユーザーによるCONTAINER_DATAオブジェクトの情報の表示を参照してください

- CDBの権限およびロール付与の概要は、『Oracle Database概要』を参照してください

管理権限の管理

一般的なデータベース操作と特定のデータベース操作の両方に管理権限を使用できます。

内容は次のとおりです。

- 管理権限について

- ユーザーへの管理権限の付与

- 通常のデータベース操作のためのSYSDBAおよびSYSOPER管理権限

- バックアップおよびリカバリ操作のSYSBACKUP管理権限

- Oracle Data Guard操作のSYSDG管理権限

- 透過的データ暗号化のSYSKM管理権限

管理権限について

Oracle Databaseではより適切な作業分担を実現するため、一般的に実施される各管理タスク用の管理権限が用意されています。

これらのタスクには、バックアップおよびリカバリ操作、Oracle Data GuardおよびTransparent Data Encryption (TDE)のための暗号化鍵の管理などが含まれます。

ユーザーが持つ管理権限は、V$PWFILE_USERS動的ビューを問い合せるとわかります。このビューにはパスワード・ファイル内のユーザーがリストされます。

以前のリリースでは、これらのタスクを実行するSYSDBA管理権限が必要でした。下位互換性をサポートするには、これらのタスクのSYSDBA権限を引き続き使用できますが、この項で説明する管理権限を使用することをお薦めします。

管理権限の使用は強制的に監査されます。詳細は、管理ユーザーの監査を参照してください。

ユーザーへの管理権限の付与

すべての強力な権限と同様に、管理権限は信頼できるユーザーのみに付与してください。

ただし、名前に非ASCII文字(HÜBERという名前に含まれるウムラウトなど)を使用しているユーザーには制限があります。こうしたユーザーに管理権限を付与することは可能ですが、Oracle Databaseインスタンスが停止した場合、名前に非ASCII文字を使用しているユーザーには、付与されている権限を使用した認証がサポートされません。データベース・インスタンスが稼働中であれば、この認証はサポートされます。

通常のデータベース操作のためのSYSDBAおよびSYSOPER管理権限

SYSDBAおよびSYSOPER管理権限を使用すると、各種標準データベース操作を実行できます。

これらのデータベース操作には、データベースの起動および停止、サーバー・パラメータ・ファイル(SPFILE)の作成またはデータベース・アーカイブ・ログの変更などのタスクがあります。

関連項目:

SYSDBAおよびSYSOPER管理権限の詳細は、『Oracle Database管理者ガイド』を参照してください。

バックアップおよびリカバリ操作のSYSBACKUP管理権限

Oracle Recovery Manager (RMAN)またはSQL*Plusを使用したバックアップおよびリカバリ操作を実行するには、SYSBACKUP管理権限を使用します。

パスワードを使用してSYSBACKUPとしてデータベースに接続するには、そのパスワード・ファイルを作成する必要があります。パスワード・ファイルの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

この権限では、次の操作を実行できます。

- STARTUP

- SHUTDOWN

- ALTER DATABASE

- ALTER SYSTEM

- ALTER SESSION

- ALTER TABLESPACE

- CREATE CONTROLFILE

- CREATE ANY DIRECTORY

- CREATE ANY TABLE

- CREATE ANY CLUSTER

- CREATE PFILE

- CREATE RESTORE POINT(GUARANTEEDリストア・ポイントを含む)

- CREATE SESSION

- CREATE SPFILE

- DROP DATABASE

- DROP TABLESPACE

- DROP RESTORE POINT(GUARANTEEDリストア・ポイントを含む)

- FLASHBACK DATABASE

- RESUMABLE

- UNLIMITED TABLESPACE

- SELECT ANY DICTIONARY

- SELECT ANY TRANSACTION

- SELECT

- X$表(つまり、固定表)

- V$およびGV$ビュー(つまり、動的パフォーマンス・ビュー)

- APPQOSSYS.WLM_CLASSIFIER_PLAN

- SYSTEM.LOGSTDBY$PARAMETERS

- DELETE/INSERT

- SYS.APPLY$_SOURCE_SCHEMA

- SYSTEM.LOGSTDBY$PARAMETERS

- EXECUTE

- SYS.DBMS_BACKUP_RESTORE

- SYS.DBMS_RCVMAN

- SYS.DBMS_DATAPUMP

- SYS.DBMS_IR

- SYS.DBMS_PIPE

- SYS.SYS_ERROR

- SYS.DBMS_TTS

- SYS.DBMS_TDB

- SYS.DBMS_PLUGTS

- SYS.DBMS_PLUGTSP

- SELECT_CATALOG_ROLE

また、SYSBACKUP権限では、データベースをオープンしていない場合でもデータベースに接続できます。

関連項目:

バックアップおよびリカバリ操作の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

Oracle Data Guard操作のSYSDG管理権限

SYSDG管理権限を持つSYSDGユーザーとしてログインして、Data Guard操作を実行できます。

Data Guard BrokerまたはDGMGRLコマンドライン・インタフェースでこの権限を使用できます。パスワードを使用してSYSDGとしてデータベースに接続するには、そのパスワード・ファイルを作成する必要があります。

SYSDG権限では、次の操作を実行できます。

- STARTUP

- SHUTDOWN

- ALTER DATABASE

- ALTER SESSION

- ALTER SYSTEM

- CREATE RESTORE POINT(GUARANTEEDリストア・ポイントを含む)

- CREATE SESSION

- DROP RESTORE POINT(GUARANTEEDリストア・ポイントを含む)

- FLASHBACK DATABASE

- SELECT ANY DICTIONARY

- SELECT

- X$表(つまり、固定表)

- V$およびGV$ビュー(つまり、動的パフォーマンス・ビュー)

- APPQOSSYS.WLM_CLASSIFIER_PLAN

- DELETE

- APPQOSSYS.WLM_CLASSIFIER_PLAN

- EXECUTE

- SYS.DBMS_DRS

また、SYSDG権限では、データベースをオープンしていない場合でもデータベースに接続できます。

関連項目:

- パスワード・ファイルの作成の詳細は、『Oracle Database管理者ガイド』を参照してください

- Oracle Data Guardの詳細は、Oracle Data Guard概要および管理を参照

透過的データ暗号化のSYSKM管理権限

SYSKM管理権限により、SYSKMユーザーは、透過的データ暗号化(TDE)のウォレット操作を管理できます。

パスワードを使用してSYSKMとしてデータベースに接続するには、そのパスワード・ファイルを作成する必要があります。

SYSKM管理権限では、次の操作を実行できます。

- ADMINISTER KEY MANAGEMENT

- CREATE SESSION

- SELECT(データベースをオープンしている場合のみ)

- SYS.V$ENCRYPTED_TABLESPACES

- SYS.V$ENCRYPTION_WALLET

- SYS.V$WALLET

- SYS.V$ENCRYPTION_KEYS

- SYS.V$CLIENT_SECRETS

- SYS.DBA_ENCRYPTION_KEY_USAGE

また、SYSKM権限では、データベースをオープンしていない場合でもデータベースに接続できます。

関連項目:

- パスワード・ファイルの作成の詳細は、『Oracle Database管理者ガイド』を参照してください

- 透過的データ暗号化の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

システム権限の管理

スキーマ・オブジェクトに対するアクションを実行するには、適切なシステム権限が付与されている必要があります。システム権限はかなり強力であるため、信頼できるユーザーのみに権限を制限することが重要です。

内容は次のとおりです。

- システム権限の概要

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

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

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

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

関連項目:

共通に付与されるシステム権限の使用方法

システム権限の概要

システム権限とは、スキーマ・オブジェクトに対して1つまたは複数の操作を実行する権限です。

たとえば、表領域を作成する権限や、データベース内の任意の表から行を削除する権限などがシステム権限です。

システム権限には100以上の種類があります。各システム権限によって、ユーザーは特定のデータベース操作、またはあるクラスのデータベース操作を実行できます。システム権限は非常に強力な権限であることに注意してください。システム権限は、必要な場合のみ、データベースのロールと信頼できるユーザーに付与してください。ユーザーに付与されたシステム権限を検索するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せます。

関連項目:

- システム権限の完全なリストとその詳細は、『Oracle Database SQL言語リファレンス』を参照してください

- 共通に付与されるシステム権限の使用方法

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

システム権限はかなり強力であるため、信頼できるユーザーのみに権限を付与する必要があります。さらに、データ・ディクショナリを保護して、SYSスキーマ内のオブジェクトを制限する必要があります。

内容は次のとおりです。

- システム権限の制限の重要性について

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

- SYSスキーマのオブジェクトへのユーザー・アクセス

システム権限の制限の重要性について

システム権限は非常に強力であるため、通常(非管理)ユーザーがANYシステム権限を実行しないように、デフォルトでデータベースが構成されます。

たとえば、ユーザーは、データ・ディクショナリに対してUPDATE ANY TABLEなどのANYシステム権限を実行できません。

システム権限の制限に関するその他のガイドラインは、ユーザー・アカウントと権限の保護に関するガイドラインを参照してください。

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

O7_DICTIONARY_ACCESSIBILITY初期化パラメータは、Oracle Databaseリリース7からOracle8i以上のリリースにアップグレードした場合の、システム権限に対する制限を制御します。

このパラメータをTRUEに設定すると、SYSスキーマ内のオブジェクトへのアクセスが可能になります(Oracle Databaseリリース7の動作)。ANY権限はデータ・ディクショナリに適用されるため、ANY権限を持つ不正なユーザーがデータ・ディクショナリ表にアクセスし、変更する危険性があります。

- データ・ディクショナリを保護するには、O7_DICTIONARY_ACCESSIBILITY初期化パラメータをFALSE(デフォルト)に設定します。この機能を、ディクショナリ保護メカニズムと呼びます。
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$からレコードを削除できます。

注意: Oracle Database 12c リリース1 (12.1)では、DELETE_CATALOG_ROLEロールは非推奨です。

さらにSELECT ANY DICTIONARYシステム権限を、SYSスキーマで作成された表にアクセスが必要なユーザーに付与できます。このシステム権限により、SYSスキーマのあらゆるオブジェクト(そのスキーマに作成された表を含む)への問合せアクセスが可能になります。このシステム権限は、これを必要とする各ユーザーへ個別に付与する必要があります。これはGRANT ALL PRIVILEGESには含まれていませんが、ロールを通じて付与できます。

注意:

これらのロールおよびSELECT ANY DICTIONARYシステム権限は、悪用されるとシステムの整合性が損われる危険があるため、付与する際には十分な注意が必要です。

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

システム権限は、ユーザーとロールに対して付与したり、取り消すことができます。

システム権限をロールに付与すると、そのロールを使用してシステム権限を行使できます。たとえば、ロールを使用すると権限を選択的に使用できるようになります。ロールの保護に関するガイドラインで説明する業務分離のガイドラインに従っていることを確認してください。

ユーザーやロールに対するシステム権限の付与と取消しには、次のいずれかの方法を使用します。

- SQL文のGRANTおよびREVOKE

- Oracle Enterprise Manager Cloud Control

関連項目:

ユーザー権限およびロールのデータ・ディクショナリ・ビュー

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

他のユーザーにシステム権限を付与したり、他のユーザーのシステム権限を取り消すことができるのは、次の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文を使用するか、initSID.oraファイルを変更して、このパラメータを設定できます。

関連項目:

- 例4-1

- その他のガイドラインは、データベースのインストールと構成の保護に関するガイドラインを参照してください

共通およびローカルに付与される権限の管理

マルチテナント環境では、権限はCDB全体に対して共通に付与するか、特定のPDBに対してローカルに付与できます。

内容は次のとおりです。

- 共通およびローカルに付与される権限について

- 共通に付与されるシステム権限の使用方法

- 共通に付与されるオブジェクト権限の使用方法

- PDBへのアクセス権限の付与または取消し

- 例: マルチテナント環境での権限の付与

- 共通ユーザーによるCONTAINER_DATAオブジェクトの情報の表示

関連項目:

共通権限付与およびローカル権限付与の概要は、『Oracle Database概要』を参照してください

共通およびローカルに付与される権限について

マルチテナント環境では、共通ユーザーとローカル・ユーザーの両方は、相互に権限を付与できます。

権限自体は、共通でもローカルでもありません。権限がどのように適用されるかは、権限が共通に付与されるか、ローカルに付与されるかによって異なります。

共通に付与される権限の場合:

- 共通に付与される権限は、既存および将来のすべてのコンテナで使用できます。

- 権限を共通に付与できるのは共通ユーザーのみで、権限受領者が共通の場合のみです。

- 共通ユーザーは、他の共通ユーザーまたは共通ロールに権限を付与できます。

- 権限付与者は、ルートに接続して、GRANT文のCONTAINER=ALLを指定する必要があります。

- システム権限とオブジェクト権限は、どちらも共通に付与できます。(オブジェクト権限は、指定したオブジェクトに関してのみ実現化します。)

- 共通ユーザーを指定されたコンテナに接続または切り替える場合、様々なアクティビティ(表の作成など)を実行するユーザーの機能は、共通に付与またはローカルに付与されたこのユーザーの両方の権限によって制御されます。

- PUBLICには権限を共通に付与しないでください。

ローカルに付与される権限

- ローカルに付与された権限は、それが付与されたコンテナでのみ使用できます。権限がルートで付与されている場合は、ルートにのみ適用されます。

- 共通ユーザーおよびローカル・ユーザーは、どちらも権限をローカルに付与できます。

- 共通ユーザーおよびローカル・ユーザーは、他の共通ロールまたはローカル・ロールに権限を付与できます。

- 権限付与者は、コンテナに接続して、GRANT文のCONTAINER=CURRENTを指定する必要があります。

- ユーザーは、他のユーザーまたはロール(共通およびローカルの両方)あるいはPUBLICロールにローカルに権限を付与できます。

関連項目:

- CDBの権限およびロール付与の概要は、『Oracle Database概要』を参照してください。

- マルチテナント環境でPUBLICロールが機能するしくみ

共通に付与されるシステム権限の使用方法

ユーザーは、システム権限が付与されているPDB内でのみシステム権限を実行できます。

たとえば、PDB B内の共通ユーザーAにシステム権限がローカルに付与されている場合、ユーザーAは、PDB Bに接続されている間のみ、その権限を実行できます。

システム権限は、ルートでのみ適用可能で、次の要件を満たしている場合は、既存および将来のすべてのPDBで適用できます。

- システム権限付与者が共通ユーザーで、権限受領者が共通ユーザー、共通ロールまたはPUBLICロールです。事実上すべてのユーザーがシステム権限を使用できるようになるため、システム権限をPUBLICロールに共通に付与しないでください。

- システム権限付与者は、共通に付与される権限に対してADMIN OPTIONを所有しています。

- GRANT文には、CONTAINER=ALL句を含める必要があります。

次の例は、共通ユーザーc##hr_adminに対して権限を共通に付与する方法を示しています。

CONNECT SYSTEM
Enter password: password
Connected.

GRANT CREATE ANY TABLE TO c##hr_admin CONTAINER=ALL;

共通に付与されるオブジェクト権限の使用方法

共通オブジェクトのオブジェクト権限は、オブジェクト自体とそのオブジェクト上の関連するすべてのリンクに適用されます。

このリンクには、すべてのメタデータ・リンクおよびデータ・リンク(旧称オブジェクト・リンク)のほか、ルートやコンテナに属するすべてのPDB(将来のPDBを含む)内で特定の要件を満たしたときに関連付けが行われる拡張データ・リンクが含まれます。

この要件を次に示します。

- オブジェクト権限付与者が共通ユーザーで、権限受領者が共通ユーザー、共通ロールまたはPUBLICロールです。

- オブジェクト権限付与者は、共通に付与される権限に対して共通に付与されるGRANT OPTIONを所有しています。

- GRANT文には、CONTAINER=ALL句が含まれています。

次の例は、現在のPDBのuser_data表から選択するための共通ユーザーc##hr_adminへのオブジェクト権限の付与方法を示しています。

CONNECT SYSTEM@hr_pdg
Enter password: password
Connected.

GRANT READ ON user_data TO c##hr_admin CONTAINER=CURRENT;

関連項目:

- メタデータ・リンクおよびオブジェクト・リンクの詳細は、『Oracle Database概要』を参照してください

- マルチテナント環境のオブジェクト権限の範囲の詳細は、『Oracle Database概要』を参照してください。

- マルチテナント環境でPUBLICロールが機能するしくみ

PDBへのアクセス権限の付与または取消し

マルチテナント環境では、PDBアクセスに対する権限の付与および取消を実行できます。

- マルチテナント環境で権限を付与するには、GRANTまたはREVOKE文にCONTAINER句を含めます。

CONTAINERをALLに設定すると、既存および将来のすべてのコンテナに権限が適用され、CURRENTに設定すると、ローカル・コンテナのみに権限が適用されます。CONTAINER句を省略すると、ローカル・コンテナに権限が適用されます。ルートからGRANT文を発行してCONTAINER句を省略すると、権限がローカルに適用されます。

関連項目:

GRANT文に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

例: マルチテナント環境での権限の付与

マルチテナント環境で権限を付与するには、GRANT文を使用できます。

例4-2は、既存および将来のすべてのコンテナでこの権限を使用できるように、共通ユーザーc##hr_adminにCREATE TABLE権限を共通に付与する方法を示しています。

例4-2 マルチテナント環境での権限の付与

CONNECT SYSTEM
Enter password: password
Connected.

GRANT CREATE TABLE TO c##hr_admin CONTAINER=ALL;

共通ユーザーによるCONTAINER_DATAオブジェクトの情報の表示

共通ユーザーは、ルート内のCONTAINER_DATAオブジェクトや特定のPDB内のデータに関する情報を表示できます。

内容は次のとおりです。

- ルートに接続中のルート、CDBおよびPDBに関するデータの表示

- 特定のPDBのデータを問い合せる共通ユーザーの有効化

ルートに接続中のルート、CDBおよびPDBに関するデータの表示

共通ユーザーが問合せを実行する場合の、X$表およびV$、GV$およびCDB_*ビューの情報の表示を制限できます。

X$表およびこれらのビューには、アプリケーション・ルートおよび関連付けられたアプリケーションPDBに関する情報(CDBルートに接続している場合は、CDB全体に関する情報)が含まれます。

他のPDBの機密情報を公開しない場合は、この情報を制限すると便利です。この機能を有効にするために、Oracle Databaseでは、これらの表およびビューをコンテナ・データ・オブジェクトとして提供します。特定の表またはビューがコンテナ・データ・オブジェクトかどうかを確認するには、USER_|DBA_|ALL_VIEWS|TABLESディクショナリ・ビューのTABLE_NAME、VIEW_NAMEおよびCONTAINER_DATA 列を問い合せます。

- デフォルト(ユーザー・レベル)およびオブジェクト固有のCONTAINER_DATA属性の情報を確認するには、CDB_CONTAINER_DATAデータ・ディクショナリ・ビューを問い合せます。

例:

COLUMN USERNAME FORMAT A15
COLUMN DEFAULT_ATTR FORMAT A7
COLUMN OWNER FORMAT A15
COLUMN OBJECT_NAME FORMAT A15
COLUMN ALL_CONTAINERS FORMAT A3
COLUMN CONTAINER_NAME FORMAT A10
COLUMN CON_ID FORMAT A6

SELECT USERNAME, DEFAULT_ATTR, OWNER, OBJECT_NAME, ALL_CONTAINERS, CONTAINER_NAME, CON_ID FROM CDB_CONTAINER_DATA ORDER BY OBJECT_NAME;

USERNAME        DEFAULT OWNER           OBJECT_NAME     ALL CONTAINERS CON_ID
--------------- ------- --------------- --------------- --- ---------- ------
C##HR_ADMIN     N       SYS             V$SESSION       N   CDB$ROOT        1
C##HR_ADMIN     N       SYS             V$SESSION       N   SALESPDB        1
C##HR_ADMIN     Y                                       N   HRPDB           1
C##HR_ADMIN     Y                                       N   CDB$ROOT        1
DBSNMP          Y                                       Y                   1
SYSTEM          Y                                       Y                   1

関連項目:

- コンテナ・データ・オブジェクトの概要は、『Oracle Database概要』を参照してください。

- DBA_CONTAINER_DATAデータ・ディクショナリ・ビューの詳細は、Oracle Databaseリファレンスを参照

特定のPDBのデータを問い合せる共通ユーザーの有効化

共通ユーザーのCONTAINER_DATA属性を調整することで、共通ユーザーが特定のPDBに関するデータにアクセスできるようにすることができます。

- 共通ユーザーが特定のPDBに関するデータにアクセスできるようにするには、ルートでALTER USER文を発行します。

次の例は、ALTER USER文を発行して、共通ユーザーc##hr_adminがV$SESSIONビュー(このユーザーがこのビューを問い合せることができるものと仮定します)のCDB$ROOT、SALES_PDBおよびHRPDBコンテナに関する情報を表示できるようにする方法を示しています。

CONNECT SYSTEM
Enter password: password
Connected.

ALTER USER c##hr_admin
SET CONTAINER_DATA = (CDB$ROOT, SALESPDB, HRPDB)
FOR V$SESSION CONTAINER=CURRENT;

次のように値を指定します。

- SET CONTAINER_DATAは、コンテナのほか、ユーザーがアクセスできる対象に関するデータをリストします。

- FOR V$SESSIONは、共通ユーザーc##hr_adminが問い合せるCONTAINER_DATA動的ビューを指定します。

- ルートに接続する場合にCONTAINER=ALLがALTER USER文のデフォルトのため、CONTAINER = CURRENTを指定する必要がありますが、CONTAINER_DATA属性の変更はルートに制限する必要があります。

ユーザーc##hr_adminが自身がアクセス可能なすべてのCONTAINER_DATAオブジェクト内のCDB$ROOT、SALES_PDB、HRPDBコンテナに関連する情報を表示できるようにするには、FOR V$SESSIONを省略します。次に例を示します。

ALTER USER c##hr_admin
SET CONTAINER_DATA = (CDB$ROOT, SALESPDB, HRPDB)
CONTAINER=CURRENT;

関連項目:

ALTER USER文に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

共通ロールおよびローカル・ロールの管理

共通ロールはルートで作成されるロールであり、ローカル・ロールはPDBで作成されます。

内容は次のとおりです。

- 共通ロールおよびローカル・ロールの管理について

- 共通ロールの使用方法

- マルチテナント環境でPUBLICロールが機能するしくみ

- 共通ロールの作成、変更または削除に必要な権限

- 共通ロールの作成の規則

- 共通ロールの作成

- ローカル・ロールの作成の規則

- ローカル・ロールの作成

- 共通ユーザーとローカル・ユーザーに対するロールの付与と取消し

関連項目:

- 共通およびローカルに付与される権限の管理

- Enterprise Managerの共通およびローカル・ロールおよび権限の管理

共通ロールおよびローカル・ロールの管理について

マルチテナント環境では、データベース・ロールをPDBに固有にするか、またはコンテナ全体で使用できます。

共通ロールとは、IDとパスワードがルートで作成され、既存および将来のすべてのコンテナで認識されるロールです。すべてのOracleから提供される事前定義ロールは共通ロールです。

ローカル・ロールは、1つのPDBにのみ存在し、このPDB内でのみ使用できます。共通に付与される権限は持ちません。

次のことに注意してください。

- 共通ユーザーは、共通ロールを作成して、他の共通ユーザーおよびローカル・ユーザーに付与できます。

- 共通ロールは、共通ユーザーに共通またはローカルに付与できます。

- 共通ロールをローカル・ユーザーに付与する場合、共通ロールの権限がローカル・ユーザーのPDBにのみ適用されます。

- ローカル・ユーザーは共通ロールを作成できませんが、共通ユーザーおよび他のローカル・ユーザーに共通ロールを付与できます。

関連項目:

- 事前定義ロールのリストは、「Oracle Databaseのインストールで事前に定義されているロール」を参照してください。

- 共通ロールおよびローカル・ロールの概要は、『Oracle Database概要』を参照してください。

共通ロールの使用方法

共通ロールは、マルチテナント環境のすべてのPDBで表示できます。

次の要件を満たす場合、共通ロールに共通に付与された権限は、ルートおよび権限付与者が接続できるすべてのPDB(後で追加される可能性があるPDBを含む)で適用されます。

- 権限付与者および権限受領者は、どちらも共通ユーザーです

- 権限付与者は、付与された共通ロールに対してADMIN OPTIONを所有しています。

- GRANT文には、CONTAINER=ALL句が含まれています。

共通ロールがローカルに付与された権限を含む場合、これらの権限は、共通ロールに付与されたPDB内にのみ適用されます。ローカル・ロールは共通に付与できません。

たとえば、共通ユーザーc##hr_mgrに、DBAロールが共通付与されているとします。これは、ユーザーc##hr_mgrは、マルチテナント環境のルートおよび各PDBでDBAロールに関連付けられている権限を使用できることを意味します。一方、共通ユーザーc##hr_mgrに、hr_pdb PDBに対するDBAロールがローカルで付与されているのみであれば、このユーザーは、hr_pdb PDBでのみDBAロールの権限を使用できます。

マルチテナント環境でPUBLICロールが機能するしくみ

OracleによってPUBLICロールに付与されるすべての権限は、ローカルで付与されます。

この機能により、各PDBで個別にPUBLICロールに付与された権限およびロールを必要に応じて取り消すことができます。権限をPUBLICロールに付与する必要がある場合は、ローカルに付与します。PUBLICには権限を共通に付与しないでください。

関連項目:

- 共通およびローカルに付与される権限について

- CDBのPUBLICロールの概要は、『Oracle Database概要』を参照してください。

共通ロールの作成、変更または削除に必要な権限

共通ロールを作成、変更または削除するために、共通ユーザーには共通権限が必要です。

共通に付与されるCREATE ROLE、ALTER ROLEおよびDROP ROLE権限を持つ共通ユーザーのみが、共通ロールの作成、変更または削除ができます。

共通ユーザーはローカル・ロールも作成できますが、作成されたPDBでのみそれらのロールを使用できます。

共通ロールの作成の規則

共通ロールを作成する場合は、特別な規則に従う必要があります。

この規則は次のとおりです。

- ルートにいることを確認します。PDBから共通ロールを作成することはできません。ルートにいるかどうかを確認するには、show con_nameコマンドを実行します。CDB$ROOTと表示される必要があります。

- 共通ロールに指定した名前は、C##またはc##で始まり、ASCIIまたはEDCDIC文字のみを含む必要があります。この要件はDBAやRESOURCEなど、Oracle Databaseによって提供される既存のロールの名前に適用されないことに注意してください。

- オプションで、CONTAINER句をALLに設定します。ルートにいるかぎりは、CONTAINER = ALL句を省略しても、ロールは、デフォルトで共通ロールとして作成されます。

共通ロールの作成

CREATE USER文を使用して、共通ロールを作成できます。

1. 共通ロールを作成するCDBまたはアプリケーション・コンテナのルートに接続します。

例:

CONNECT SYSTEM
Enter password: password
Connected.

2. CONTAINER句をALLに設定してCREATE ROLE文を実行します。

例:

CREATE ROLE c##sec_admin IDENTIFIED BY password CONTAINER=ALL;

関連項目:

- ロールの作成

- Enterprise Managerの共通ロールの作成

ローカル・ロールの作成の規則

ローカル・ロールを作成するには、次の特別な規則に従う必要があります。

これらの規則は次のとおりです。

- ロールを作成するPDBに接続する必要があり、CREATE ROLE権限がある必要があります。

- ローカル・ロールに付ける名前をCOMMON_USER_PREFIXパラメータの値(デフォルトではC##)で始めることはできません。

- CREATE ROLE文にCONTAINER=CURRENTを含め、ローカル・ロールとしてロールを指定できます。PDBに接続しており、この句を省略すると、CONTAINER=CURRENT句が含まれます。

- 共通ロールとローカル・ロールの名前を同じにすることはできません。ただし、異なるPDBのローカル・ロールに同じ名前を使用できます。既存のロールの名前を検索するには、CDB_ROLESおよびDBA_ROLESデータ・ディクショナリ・ビューを問い合せます。

ローカル・ロールの作成

CREATE ROLE文を使用して、ロールを作成できます。

1. ローカル・ロールを作成するPDBに接続します。

例:

CONNECT SYSTEM@hrpdb
Enter password: password
Connected.

2. CONTAINER句をCURRENTに設定してCREATE ROLE文を実行します。

例:

CREATE ROLE sec_admin CONTAINER=CURRENT;

共通ユーザーとローカル・ユーザーに対するロールの付与と取消し

ロールの付与と取消は、共通ユーザーまたはローカル・ユーザーのアクセス範囲にのみ適用されます。

共通ユーザーは、他の共通ユーザーへの共通ロールの付与および取消しを行うことができます。ローカル・ユーザーは、共通ロールを共通ユーザーを含むPDBのユーザーに付与できますが、これは、PDB内のみで適用されます。

次の例は、共通ユーザーc##sec_adminへのすべてのコンテナで使用するAUDIT_ADMIN共通ロールの付与方法を示しています。

CONNECT SYSTEM
Enter password: password
Connected.

GRANT AUDIT_ADMIN TO c##sec_admin CONTAINER=ALL;

同様に、次の例は、ローカル・ユーザーaud_adminによる共通ユーザーc##sec_adminへのhrpdb PDB内で使用するAUDIT_ADMIN共通ロールの付与方法を示しています。

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

GRANT AUDIT_ADMIN TO c##sec_admin CONTAINER=CURRENT;

この例は、ローカル・ユーザーaud_adminがPDBからロールを取り消す方法を示しています。CONTAINER句を省略すると、CURRENTが暗黙のうちに入れられます。

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

REVOKE sec_admin FROM psmith CONTAINER=CURRENT;

関連項目:

Enterprise Managerの共通権限付与の取消し

ユーザー・ロールの管理

ユーザー・ロールは、作成したり他のユーザーに割り当てることができる権限の名前付きコレクションです。

内容は次のとおりです。

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

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

- ロールの作成

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

- ロールの削除

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

- ロール権限およびセキュア・アプリケーション・ロール

関連項目:

共通ロールおよびローカル・ロールの管理

ユーザー・ロールの概要

ユーザー・ロールは、他のユーザーに付与できる権限の名前付きコレクションであり、ユーザー管理の面で多くのメリットがあります。

内容は次のとおりです。

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

- ロールの機能

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

- ロールの通常の使用

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

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

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

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

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

ユーザー・ロールの概要

ユーザー・ロールは、ユーザーまたは他のロールに一括で付与できる関連権限の名前付きグループです。

権限の管理および制御は、ロールを使用すると容易になります。

データベース内では、各ロール名を一意にする必要があり、すべてのユーザー名や他のすべてのロール名とは異なる名称にする必要があります。スキーマ・オブジェクトとは異なり、ロールはいずれのスキーマにも含まれません。したがって、ロールを作成するユーザーを、ロールに影響をおよぼすことなく削除できます。

ロールの機能

ロールとは、ユーザーに権限を素早く簡単に付与するために便利なものです。

Oracle Databaseで定義されているロールを使用することもできますが、必要な権限のみを含む独自のロールを作成すると、より継続的な制御が可能になります。Oracle Databaseで定義されているロールの権限は、Oracleによって変更または削除される場合があります。

ロールは、次の機能を備えています。

- ロールには、システム権限またはオブジェクト権限を付与できます。

- 任意のロールを任意のデータベース・ユーザーに付与できます。

- ユーザーに付与した各ロールは、任意の時点で使用可能または使用禁止にできます。ユーザーのセキュリティ・ドメインには、そのユーザーに対して現在使用可能になっているすべてのロールの権限が含まれており、ユーザーに対して現在使用禁止になっているロールの権限は除外されています。権限を選択的に使用できるように、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ブロックで使用されるロール

定義者権限を持つ名前付きブロックで使用されるロール

定義者権限で実行される名前付きPL/SQLブロックでは、すべてのロールは使用禁止になっています。

名前付きPL/SQLブロックには、ストアド・プロシージャやファンクション、トリガーがあります。

ロールは権限チェックに使用されず、定義者権限プロシージャ内ではロールを設定できません。

PL/SQLブロックが定義者権限で実行する場合、SESSION_ROLESデータ・ディクショナリ・ビューには現在使用可能なすべてのロールが表示されます。定義者権限で実行される名前付きPL/SQLブロックでSESSION_ROLESを問い合せると、その問合せは行を戻しません。

関連項目:

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データベースに対して自動的に定義され、共通ロールとみなされます。他のオプションや製品をインストールすると、他の事前定義のロールが作成される場合があります。Oracleによって作成および維持されるロールは、DBA_ROLESデータ・ディクショナリ・ビューのROLE列とORACLE_MAINTAINED列を問い合せることでわかります。ORACLE_MAINTAINEDの出力がYの場合は、そのロールを変更しないでください。ただし、そのロールの作成に使用したスクリプトを実行することで変更する場合を除きます。

表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権限を提供します。

AUDIT_ADMIN

統合およびファイングレイン監査ポリシーの作成、AUDITおよびNOAUDIT SQL文の使用、監査データの表示および監査証跡の管理を行う権限を提供します

関連項目: 監査の実行者

AUDIT_VIEWER

監査データを表示および分析する権限を提供します

関連項目: 監査の実行者

AUTHENTICATEDUSER

システムにログインしたユーザーを定義するために、XDBプロトコルで使用されます。

関連項目: このロールをDBUriServletセキュリティに使用する方法の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

CAPTURE_ADMIN

権限分析ポリシーの作成および管理に必要な権限を提供します。

関連項目: 詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

CDB_DBA

SET CONTAINER、SELECT ON PDB_PLUG_IN_VIOLATIONS、SELECT ON CDB_LOCAL_ADMIN_PRIVSなどのCDBの管理に必要な権限を提供します。サイトで追加の権限が必要な場合、ロール(共通またはローカル)を作成してこれらの権限に対応し、このロールをCDB_DBAロールに付与できます。

関連項目: CDBの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

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 and Graph開発者ガイドを参照してください。

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

ANY権限(DELETE ANY TABLEなど)やGRANT ANY PRIVILEGE権限など、多数のシステム権限を提供します。

このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せることで確認できます。

注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。

関連項目: DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

DBFS_ROLE

DBFS(データベース・ファイルシステム)パッケージおよびオブジェクトへのアクセスを提供します。

関連項目: 『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』

DELETE_CATALOG_ROLE

統合監査環境以外で、システム監査表(AUD$)のDELETE権限を提供します。

注意: Oracle Database 12c リリース1 (12.1)では、DELETE_CATALOG_ROLEロールは非推奨です。

EJBCLIENT

Javaストアド・プロシージャからEJBに接続する権限を提供します。

EM_EXPRESS_ALL

ユーザーは、Oracle Enterprise Manager (EM) Expressに接続して、EM Expressによって提供されるすべての機能(すべてのEM Express機能への読取りおよび書込みアクセス)を使用できます。EM_EXPRESS_ALLロールは、EM_EXPRESS_BASICロールを含みます。

関連項目: 詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

EM_EXRESS_BASIC

ユーザーは、EM Expressに接続して、読取り専用モードでページを表示できます。EM_EXPRESS_BASICロールは、SELECT_CATALOG_ROLEロールを含みます。

関連項目: 詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

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 SQLチューニング・ガイドを参照してください。

GLOBAL_AQ_USER_ROLE

Oracle Streams AQで使用されるLDAPサーバーへの接続を確立する権限を提供します。

関連項目: 詳細は、Oracle Database SQLチューニング・ガイドを参照してください。

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概要および管理』を参照してください。

OEM_ADVISOR

DBMS_SQLTUNE PL/SQLパッケージによってSQL Tuning Setを作成、削除、選択(読取り)、ロード(書込み)および削除する権限と、ADVISOR PL/SQLパッケージを使用してアドバイザ・フレームワークにアクセスする権限を提供します。

関連項目: 詳細は、Oracle Database SQLチューニング・ガイドを参照してください。

OEM_MONITOR

Oracle Enterprise Managerの管理エージェント・コンポーネントで必要とされる、データベースを監視および管理する権限を提供します。

関連項目: 詳細は、Oracle Database SQLチューニング・ガイドを参照してください。

OLAP_DBA

Oracle OLAPの異なるスキーマでディメンション・オブジェクトを作成する管理権限を提供します。

関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

OLAP_USER

アプリケーション開発者に対し、Oracle OLAPの独自のスキーマでディメンション・オブジェクトを作成する権限を提供します。

関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

OLAP_XS_ADMIN

Oracle OLAPのセキュリティの管理権限を提供します。

関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

OPTIMIZER_PROCESSING_RATE

DBMS_STATSパッケージのGATHER_PROCESSING_RATE、SET_PROCESSING_RATEおよびDELETE_PROCESSING_RATEプロシージャを実行する権限を提供します。これらのプロシージャは、自動的な並列度(Auto DOP)のシステムの処理率を管理します。Auto DOPは、これらの処理率を使用して、SQL文の最適な並列度を決定します。

関連項目: 詳細は、Oracle Database SQLチューニング・ガイドを参照してください。

ORDADMIN

Oracle Multimedia DICOMの管理権限を提供します。

関連項目: 『Oracle Multimedia DICOM開発者ガイド』

PDB_DBA

シードPDBから新しいPDBを作成する場合に作成されるローカル・ユーザーに自動的に付与されます。権限はこのロールに提供されません。

関連項目: シードを使用したPDBの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

PROVISIONER

Oracle Database Real Applicationセッションのグローバル・コールバックを登録および更新してプリンシパルをプロビジョニングする権限を提供します。

関連項目: 詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

RECOVERY_CATALOG_OWNER

リカバリ・カタログの所有者の権限を提供します。CREATE SESSION、ALTER SESSION、CREATE SYNONYM、CREATE ANY SYNONYM、DROP ANY SYNONYM、CREATE VIEW、CREATE DATABASE LINK、CREATE TABLE、CREATE CLUSTER、CREATE SEQUENCE、CREATE TRIGGER、CREATE ANY TRIGGER、QUERY REWRITE、CREATE ANY CONTEXT、EXECUTE ON DBMS_RLS、ADMINISTER DATABASEおよびCREATE PROCEDUREが含まれます。

関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

RESOURCE

CREATE CLUSTER、CREATE INDEXTYPE、CREATE OPERATOR、CREATE PROCEDURE、CREATE SEQUENCE、CREATE TABLE、CREATE TRIGGER、CREATE TYPEの各システム権限を提供します。

RESOURCEがUNLIMITED TABLESPACEシステム権限を提供しないことに注意してください。

このロールは、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権限を付与します。

SPATIAL_CSW_ADMIN

Oracle SpatialのCatalog Services for the Web(CSW)コンポーネントを管理する管理権限を提供します。

関連項目: 詳細は、Oracle Spatial and Graph開発者ガイドを参照してください。

SPATIAL_WFS_ADMIN

Oracle SpatialのWeb Feature Service(WFS)コンポーネントを管理する管理権限を提供します。

関連項目: 詳細は、Oracle Spatial and Graph開発者ガイドを参照してください。

WFS_USR_ROLE

Oracle SpatialのWeb Feature Service(WFS)コンポーネントに対するユーザー権限を提供します。

関連項目: 詳細は、Oracle Spatial and Graph開発者ガイドを参照してください。

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開発者ガイド』を参照してください。

XS_CACHE_ADMIN

Oracle Database Real Application Securityでは、権限受領者が中間層キャッシュを管理できます。XSAccessControllerクラスのcheckAcl(認可)メソッドの中間層レベルでのセキュリティ・ポリシーのキャッシュに必要です。このロールをアプリケーション接続ユーザーまたはReal Application Securityディスパッチャに付与します。

関連項目: 詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

XS_NSATTR_ADMIN

Oracle Database Real Application Securityでは、権限受領者がセッションのネームスペースおよび属性を管理および操作できます。このロールをReal Application Securityセッション・ユーザーに付与します。

関連項目: Real Application Securityセッションの管理の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

XS_RESOURCE

Oracle Database Real Application Securityでは、権限受領者がXS_ACL PL/SQLパッケージを通じて付加されたスキーマのオブジェクトを管理できます。このパッケージは、アクセス制御リスト(ACL)を作成および管理するプロシージャを作成します。ADMIN SEC POLICY権限を含みます。Oracle Database RESOURCEロールと似ています。

関連項目: 詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

XS_SESSION_ADMIN

Oracle Database Real Application Securityでは、権限受領者がセッションを作成、接続、切離しおよび破棄する機能を含むセッションのライフ・サイクルを管理できます。このロールをアプリケーション接続ユーザーまたはReal Application Securityディスパッチャに付与します。

関連項目: Real Application Securityセッションの管理の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

注意:

各インストールで独自のロールが作成されて、必要な権限のみが割り当てられます。このようにして、使用中の権限の詳細な制御が維持されます。このプロセスにより、Oracle Databaseで定義されるロールがOracle Databaseで変更や削除されたとき、既存のロール、権限、またはプロシージャを調整する必要もなくなります。たとえば、CONNECTロールが現在持っている権限はCREATE SESSIONの1つのみです。

ロールの作成

パスワードの有無に関係なく、認証されるロールを作成できます。外部ロールまたはグローバル・ロールも作成できます。ロールは、作成後に変更できます。

内容は次のとおりです。

- ロールの作成について

- パスワードを使用して認証されるロールの作成

- パスワード認証のないロールの作成

- 外部またはグローバルのロールの作成

- ロールの変更

関連項目:

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

- 共通ロールの作成の規則

ロールの作成について

ロールはCREATE ROLE文を使用して作成できます。

ロールを作成する場合、CREATE ROLEシステム権限が必要です。通常、このシステム権限はセキュリティ管理者のみが持っています。作成した直後のロールには、権限は対応付けられていません。次のステップで、新しいロールに権限または他のロールを付与します。

作成する各ロールには、データベースの既存のユーザー名やロール名とは異なる、一意の名前を指定する必要があります。ロールはどのユーザーのスキーマ内にも格納されません。マルチバイト・キャラクタ・セットを使用するデータベースでは、各ロール名に少なくとも1つのシングルバイト・キャラクタを含めることをお薦めします。ロール名がマルチバイト・キャラクタのみの場合、暗号化されたロール名とパスワードの組合せの安全性は大幅に低くなります。パスワードのガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。

IDENTIFIED BY句を使用して、パスワードによってロールを認可します。この句は、このロールを付与された特定ユーザーがロールを使用をする前に、どの認可方式で認可される必要があるかを指定します。この句を指定しないか、またはNOT IDENTIFIEDを指定すると、認可がなくてもロールが使用可能になります。ロールには、必要な認可方式として次の方式を指定できます。

- パスワードを使用したデータベースによる認可

- 指定のパッケージを使用したアプリケーションによる認可

- オペレーティング・システム、ネットワークまたはその他の外部ソースによる外部認可

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

パスワードで保護されたロールの作成の代替手段として、セキュア・アプリケーション・ロールの使用をお薦めします。詳細は、「ロール権限およびセキュア・アプリケーション・ロール」を参照してください。

ロールの作成に関する次の制限に注意してください。

- ロールとユーザーに同じ名前を付けることはできません。

- このロールが共通ロールでないかぎり、ロール名をc## (またはC##)から開始できません。

パスワードを使用して認証されるロールの作成

IDENTIFIED BY句を使用して、パスワードで認証されるロールを作成できます。

ただし、パスワードで保護されたロールを使用するかわりに、セキュア・アプリケーション・ロールの使用を検討してください。詳細は、ロール権限およびセキュア・アプリケーション・ロールを参照してください。

- パスワード認証されるロールを作成するには、IDENTIFIED BY句が指定されたCREATE ROLE文を使用します。

例:

CREATE ROLE clerk IDENTIFIED BY password;

注意:

SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを11以上に設定する場合、IDENTIFIED BY句で作成されたロールを再作成する必要があります。詳細は、安全性の高いロール・パスワードの大/小文字の区別の管理を参照してください。

パスワード認証のないロールの作成

IDENTIFIED BY句を省略することで、パスワードを必要としないロールを作成できます。

- 句を指定せずにCREATE ROLE文を使用して、パスワード認証のないロールを作成します。

例:

CREATE ROLE salesclerk;

外部またはグローバルのロールの作成

外部ユーザーは、ロールを使用可能にする前に、オペレーティング・システムやサード・パーティ・サービスなどの外部サービスによって認可されている必要があります。

グローバル・ユーザーは、ログイン時にロールの使用が可能になる前に、エンタープライズ・ディレクトリ・サービスによってロールの使用を認可されている必要があります。

- グローバルに認可されるロールを作成するには、IDENTIFIED GLOBALLY句を指定してCREATE ROLE文を使用します。

例:

CREATE ROLE clerk IDENTIFIED GLOBALLY;

ロールの変更

ALTER ROLE文で、ロールの認可方法を変更できます。

ロールの認可方式を変更するには、ALTER ANY ROLEシステム権限またはADMINオプション付きのロールが付与されている必要があります。

セキュア・アプリケーション・ロールまたはパスワード認証ロールはユーザーに直接付与する必要があることに注意してください。ルートで共通ロールを作成する場合、それをローカル・ロールに変更できないことに注意してください。

- ロールを変更するには、ALTER ROLE文を使用します。
たとえば、ロールを有効にする前にユーザーが外部ソースによって認可されている必要があるように指定する目的でclerkロールを変更するとします。

ALTER ROLE clerk IDENTIFIED EXTERNALLY;

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

データベース、アプリケーション、外部ソース、オペレーティング・システム、ネットワーク・クライアントまたはエンタープライズ・ディレクトリ・サービスによって認可されるようにロールを構成できます。

内容は次のとおりです。

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

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

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

- オペレーティング・システムを使用したロールの認可

- ネットワーク・クライアントを使用したロールの認可

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

関連項目:

ロールを有効にする方法の詳細は、SET ROLEおよびデフォルト・ロールの設定による権限の付与と取消しの機能を参照してください

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

データベースによって認可されたロールを、ロール・パスワードを割り当てることで保護できます。

パスワードで保護されたロールがユーザーに付与された場合、SET ROLE文でそのロールの正しいパスワードを入力することでロールを使用可または使用禁止にできます。パスワード認証ロールをデフォルト・ロールのリストに追加した場合でも、このパスワード認証ロールをログオン時に認証することはできません。SET ROLE文で必須パスワードを使用して、明示的に使用可能にする必要があります。

1. パスワード認証されるロールを作成するには、IDENTIFIED BY句が指定されたCREATE ROLE文を使用します。

パスワードを使用して認証されるロールの作成には、clerkというロールを作成するCREATE ROLE文が示されています。このロールを使用可能にするには、パスワードを入力する必要があります。

2. パスワード認証されるロールを設定するには、SET ROLE文を使用します。

次の例は、SET ROLE文を使用してパスワード認証ロールを設定する方法を示しています。

SET ROLE clerk IDENTIFIED BY password;

マルチバイト・キャラクタ・セットを使用するデータベースの場合も、ロールのパスワードにはシングルバイト・キャラクタのみを使用してください。マルチバイト・キャラクタのパスワードは受け入れられません。パスワードのガイドラインは、パスワードの保護に関するガイドラインのガイドライン1を参照してください。

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

アプリケーション・ロールを使用可能にできるのは、認可されたPL/SQLパッケージを使用するアプリケーションのみです。

アプリケーション開発者は、アプリケーション内部にパスワードを埋め込むことによってロールを保護する必要はありません。かわりに、アプリケーション・ロール(セキュア・アプリケーション・ロール)を作成して、ロールを使用可能にすることを認可するPL/SQLパッケージを指定できます。

- 認可されたPL/SQLパッケージによって使用可能になるロールを作成するには、CREATE ROLE SQL文でIDENTIFIED USING package_name句を使用します。

たとえば、ロールadmin_roleがアプリケーション・ロールであり、このロールは、PL/SQLパッケージhr.admin内に定義されているモジュールによってのみ使用可能にできることを示すとします。

CREATE ROLE admin_role IDENTIFIED USING hr.admin;

関連項目:

- ロール権限およびセキュア・アプリケーション・ロール

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

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

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

Oracle Databaseでは外部ロールの使用がサポートされますが、一定の制限があります。

外部ロールは、データベースにローカルに定義できますが、グローバル・ユーザー、グローバル・ロールまたはデータベース内の他のロールには付与できません。オペレーティング・システムまたはネットワーク・クライアントによって認可されるロールを作成できます。

- 外部ソースを使用してロールを認可するには、IDENTIFIED EXTERNALLY句を指定してCREATE ROLE文を使用します。

例:

CREATE ROLE accts_rec IDENTIFIED EXTERNALLY;

オペレーティング・システムを使用したロールの認可

Oracle Databaseではオペレーティング・システムを通じたロール認証がサポートされますが、一定の制限があります。

オペレーティング・システムによるロール認証が有効となるのは、そのオペレーティング・システムによって、オペレーティング・システム権限をアプリケーションと動的にリンクできる場合のみです。

ユーザーがアプリケーションを開始すると、オペレーティング・システムはオペレーティング・システム権限をそのユーザーに付与します。付与されたオペレーティング・システム権限は、アプリケーションに対応付けられたロールと一致します。この時点で、アプリケーションはアプリケーション・ロールを使用可能にできます。アプリケーションが終了すると、先に付与されたオペレーティング・システム権限は、そのユーザーのオペレーティング・システム・アカウントから取り消されます。

- ロールをオペレーティング・システムによって認可する場合は、オペレーティング・システム・レベルで各ユーザーの情報を構成します。この操作は、オペレーティング・システムによって異なります。

ロールがオペレーティング・システムによって付与されている場合は、そのオペレーティング・システムによるロールの認可は不要です。

関連項目:

オペレーティング・システムによって付与されるロールの詳細は、オペレーティング・システムまたはネットワークを使用したロールの付与を参照してください

ネットワーク・クライアントを使用したロールの認可

Oracle Databaseではネットワーク・クライアントによるロール認証がサポートされますが、一定のセキュリティ・リスクが伴います。

ユーザーがデータベースにOracle Net経由で接続する場合、オペレーティング・システムはデフォルトではユーザーのロールを認証できません。この接続ではOracle Netが必要となるため、共有サーバー構成を介した接続が含まれます。リモート・ユーザーはネットワーク接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。REMOTE_OS_ROLESをFALSE(デフォルト)に設定することをお薦めします。

- このようなセキュリティの危険性の心配がないときに、ネットワーク・クライアントに対してオペレーティング・システムのロール認証を使用する場合は、データベース初期化パラメータ・ファイル内の初期化パラメータREMOTE_OS_ROLESをTRUEに設定します。

この変更は、次回インスタンスを起動して、データベースをマウントするときに有効になります。

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

グローバル・ロールを使用すると、グローバル・ユーザーの認可の取得先をエンタープライズ・ディレクトリ・サービスに限定できます。

グローバル・ロールは、権限とロールを付与することによってデータベース内でローカルに定義しますが、グローバル・ロール自体をそのデータベース内のユーザーや他のロールに付与することはできません。グローバル・ユーザーがデータベースへの接続を試みると、エンタープライズ・ディレクトリへの問合せが実行され、そのユーザーに対応付けられたグローバル・ロールが取得されます。グローバル・ロールは、エンタープライズ・ユーザー・セキュリティの構成要素の1つです。グローバル・ロールは1つのデータベースにのみ適用されますが、エンタープライズ・ディレクトリに定義されたエンタープライズ・ロールに付与できます。エンタープライズ・ロールは複数データベースのグローバル・ロールを含んだディレクトリ構造であり、エンタープライズ・ユーザーに付与できます。

- エンタープライズ・ディレクトリ・サービスによって認可されるグローバル・ロールを作成するには、IDENTIFIED GLOBALLY句を指定してCREATE ROLE文を使用します。

例:

CREATE ROLE supervisor IDENTIFIED GLOBALLY;

関連項目:

- ユーザーのグローバル認証とグローバル認可、およびエンタープライズ・ユーザー管理におけるロールの概要については、ユーザーのグローバル認証とグローバル認可を参照してください

- エンタープライズ・ユーザー管理の実装の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

ロールの付与と取消し

ロールに権限を付与して、これらのロールをユーザーまたは他のロールに付与できます。同様に、ロールおよびユーザーから権限を取り消すことができます。

内容は次のとおりです。

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

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

- プログラム・ユニットに対するロールの付与と取消し

関連項目:

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

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

- SET ROLEおよびデフォルト・ロールの設定による権限の付与と取消しの機能

- ユーザー権限およびロールのデータ・ディクショナリ・ビュー

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

システム権限やオブジェクト権限をロールに付与できます。そしていずれのロールも任意のデータベース・ユーザーや他のロールに付与できます。

ただし、ロールを自身に付与したり、循環的に付与することはできません。つまり、ロールYがすでにロールXに付与されている場合は、ロールXをロールYに付与することはできません。

権限を選択的に使用できるように、Oracle Databaseでは、データベース・アプリケーションとユーザーがロールを使用可能または使用禁止にできます。ユーザーに付与した各ロールは、任意の時点で使用可能または使用禁止にできます。ユーザーのセキュリティ・ドメインには、そのユーザーに対して現在使用可能になっているすべてのロールの権限が含まれており、ユーザーに対して現在使用禁止になっているロールの権限は除外されています。

ロールに対して付与されたロールは、間接的に付与されたロールと呼ばれます。この種のロールは、ユーザーに対して明示的に使用可能または使用禁止にできます。ただし、別のロールを含んだロールを使用可能にすると、直接的に付与されたロールに含まれる間接的に付与されたロールは、すべて暗黙のうちに使用可能になります。

GRANT文を使用してロールを付与し、REVOKE文を使用して取り消します。ロールに対して権限を付与または取り消す場合にも同じ文を使用します。

セキュアなロール(つまりIDENTIFIED BYロール、IDENTIFIED USINGロールまたはIDENTIFIED EXTERNALLYロール)は、他のセキュアなロールと非セキュアなロールのどちらにも付与することはできません。SET ROLE文を使用して、セッションに対してセキュアなロールを有効化できます。

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

GRANT ANY ROLEシステム権限を使用して、グローバル・ロール以外の任意のロールを他のユーザーまたはロールに付与したり、それらのロールを取り消したりできます。

グローバル・ロールはOracle Internet Directoryなどのディレクトリ内で管理されますが、その権限は単一のデータベース内に含まれます。デフォルトでは、ユーザーSYSまたはSYSTEMには、GRANT ANY ROLE権限があります。このシステム権限は非常に強力であるため、付与する場合は控えめに設定する必要があります。

ADMIN OPTION付きでロールを付与されたユーザーは、データベースの他のユーザーやロールに対してロールを付与したり、そのロールを取り消すことができます。つまり、このオプションによって、選択的なロール付与の管理が可能になります。

関連項目:

グローバル・ロールの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

プログラム・ユニットに対するロールの付与と取消し

関数、プロシージャおよびPL/SQLパッケージ・プログラム・ユニットにロールを付与できます。

ロールは、プログラム・ユニットの実行中に有効になります。ただし、プログラム・ユニットのコンパイル中を除きます。これにより、ロールを直接ユーザーに付与しないで、PL/SQLコードの権限を一時的にエスカレートできます。また、アプリケーションのセキュリティが強化され、最低限の権限の原則を規定できます。

- プログラム・ユニットに対してロールを付与または取り消すには、GRANTまたはREVOKE文を使用します。

次の例は、PL/SQLパッケージcheckstats_pkgへの同じロールの付与方法を示しています。

GRANT clerk_admin TO package psmith.checkstats_pkg;

この例は、PL/SQLパッケージcheckstats_pkgのclerk_adminロールの取消し方法を示しています。

REVOKE clerk_admin FROM package psmith.checkstats_pkg;

次の例は、プロシージャpsmith.check_stats_procへのロールclerk_adminの付与方法を示しています。

GRANT clerk_admin TO PROCEDURE psmith.checkstats_proc;

関連項目:

詳細は、定義者権限および実行者権限のコード・ベース・アクセス制御の使用を参照してください

ロールの削除

ロールの削除は、そのロールを付与されていたユーザーまたはロールのセキュリティ・ドメインに影響します。

つまり、削除したロールを付与されていたすべてのユーザーとロールのセキュリティ・ドメインは、削除したロール権限がなくなったことを反映するために変更されます。

削除したロールによって間接的に付与されていたロールもすべて、関連するセキュリティ・ドメインから削除されます。ロールを削除することによって、すべてのユーザーのデフォルト・ロール・リストからそのロールが自動的に削除されます。

オブジェクトの存在はロールを介して受け取った権限に依存しないため、ロールが削除されても、表や他のオブジェクトは削除されません。

ロールを削除するには、DROP ANY ROLEシステム権限またはADMINオプション付きのロールが付与されている必要があります。

- ロールを削除するには、DROP ROLE文を使用します。

たとえば、ロールCLERKを削除する方法は次のとおりです。

DROP ROLE clerk;

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

SQL*Plusでロールを使用するユーザーに起因するセキュリティ問題の可能性、PRODUCT_USER_PROFILEシステム表を使用したロールの制限方法、ストアド・プロシージャによるビジネス・ロジックのカプセル化について注意してください。

内容は次のとおりです。

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

- 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システム表がロールを制限できるしくみ

SYSTEMスキーマPRODUCT_USER_PROFILE表で、各ユーザーのSQL*Plus環境のSQLおよび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日でセキュリティ・ガイド』

オブジェクト権限の管理

オブジェクト権限を使用すると、表や索引などのスキーマ・オブジェクトに対するアクションを実行できます。

内容は次のとおりです。

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

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

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

- READオブジェクト権限とSELECTオブジェクト権限

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

関連項目:

共通に付与されるオブジェクト権限の使用方法

オブジェクト権限の概要

オブジェクト権限では、特定のスキーマ・オブジェクトに対して特定のアクションを実行する権限を付与します。

各タイプのスキーマ・オブジェクトごとに、異なるオブジェクト権限があります。オブジェクト権限の例には、departments表から行を削除する権限があります。

クラスタ、索引、トリガー、データベース・リンクなど、一部のスキーマ・オブジェクトには、対応付けられたオブジェクト権限がありません。これらのオブジェクトの使用は、システム権限によって決定されます。たとえば、クラスタを変更するには、ユーザーはそのクラスタを所有しているか、またはALTER ANY CLUSTERシステム権限が必要です。

たとえば、次のことをする権利がオブジェクト権限です。

- エディションの使用

- 表の更新

- 他のユーザーの表からの行の選択

- 他のユーザーのストアド・プロシージャの実行

関連項目:

- 共通に付与されるオブジェクト権限の使用方法

- オブジェクト権限とそれぞれで許可されている操作のリストは、『Oracle Database SQL言語リファレンス』を参照してください。

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

ユーザーは、自分のスキーマに含まれているスキーマ・オブジェクトに関しては、すべてのオブジェクト権限が自動的に付与されています。

GRANT ANY OBJECT PRIVILEGEシステム権限を持つユーザーは、GRANT文のWITH GRANT OPTION句を使用してもしなくても、指定したオブジェクト権限を別のユーザーに付与できます。また、GRANT ANY OBJECT PRIVILEGE権限を持つユーザーは、その権限を使用して、オブジェクト所有者またはGRANT ANY OBJECT PRIVILEGE権限を持つ他のユーザーによって付与されたオブジェクト権限を取り消すことができます。

権限受領者がGRANT ANY OBJECT PRIVILEGE権限を持っていない場合、またはGRANT文のWITH GRANT OPTION句を使用せずに権限を付与された場合、そのユーザーは権限を他のユーザーに付与できません。

WITH GRANT OPTIONは、ユーザーへのオブジェクト権限の付与でのみ使用できます。ロールへのオブジェクト権限の付与では使用できません。

関連項目:

GRANTおよびGRANT ANY OBJECT PRIVILEGEの詳細は、『Oracle Database SQL言語リファレンス』を参照してください

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

オブジェクトへの権限の付与およびオブジェクトからの権限の取消しは、ユーザーに直接またはロールを介して行うことができます。GRANT文またはREVOKE文のALL句は、すべてのオブジェクトに影響を与えます。

内容は次のとおりです。

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

- ALL句がすべての使用可能なオブジェクト権限を付与または取り消すしくみ

オブジェクト権限の付与と取消しについて

オブジェクト権限は、ユーザーとロールに対して付与したり、取り消すことができます

オブジェクト権限をロールに付与した場合は、その権限を選択的に使用可能にできます。オブジェクト権限を付与するにはGRANT文を使用し、オブジェクト権限を取り消すにはREVOKE文を使用できます。

ALL句がすべての使用可能なオブジェクト権限を付与または取り消すしくみ

オブジェクトの各タイプには異なるオブジェクト権限が対応付けられていますが、これらはALL句で制御できます。

ALL [PRIVILEGES]を指定して、オブジェクトに対するすべての使用可能なオブジェクト権限の付与または取消しが可能です。ALLは権限ではありません。ショートカットのようなもので、つまり1つのGRANT文およびREVOKE文ですべてのオブジェクト権限を付与または取り消すための方法です。すべてのオブジェクト権限がALLショートカットを使用して付与された場合でも、権限を個別に取り消すことができます。

同様に、個別に付与した権限をALLを指定してすべて取り消すこともできます。ただし、REVOKE ALLによって整合性制約が削除される場合(整合性制約は取り消そうとしているREFERENCES権限に依存しているため)は、REVOKE文にCASCADE CONSTRAINTSオプションを指定する必要があります。

例4-3では、CASCADE CONSTRAINTSを使用してHRスキーマ内の注文表に対するすべての権限を取り消しています。

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

REVOKE ALL
ON ORDERS FROM HR
CASCADE CONSTRAINTS;

READオブジェクト権限とSELECTオブジェクト権限

READ権限を使用すると、ユーザーは、表またはビューに対してのみ問合せを実行できます。SELECT権限により、表やビューへの問合せの他に、追加権限がユーザーに提供されます。

内容は次のとおりです。

- READおよびSELECTオブジェクト権限の管理について

- データベース内の任意の表を問い合せるためのREADオブジェクト権限の使用のユーザーへの許可

- READおよびREAD ANY TABLE権限に対する制限

READおよびSELECTオブジェクト権限の管理について

ユーザーにREADまたはSELECTのオブジェクト権限を付与できます。

これらの権限は、ユーザーに許可するアクセス・レベルに応じて付与します。

次のガイドラインに従ってください。

- ユーザーが表、ビュー、マテリアライズド・ビューまたはシノニムの問合せのみをできるようにする場合、READオブジェクト権限を付与する必要があります。次に例を示します。

GRANT READ ON HR.EMPLOYEES TO psmith;

- ユーザーが、問合せの実行に加えて次のアクションを実行できるようにする場合、ユーザーにSELECTオブジェクト権限を付与する必要があります。

- LOCK TABLE table_name IN EXCLUSIVE MODE;

- SELECT ... FROM table_name FOR UPDATE;

例:

GRANT SELECT ON HR.EMPLOYEES TO psmith;

いずれの場合も、ユーザーpsmithはSELECT文を使用して問合せを実行します。

関連項目:

SELECT、READ ANY TABLEまたはSELECT ANY TABLEの監査

データベース内の任意の表を問い合せるためのREADオブジェクト権限の使用のユーザーへの許可

READ ANY TABLEシステム権限で、データベース内の任意の表を問い合せることができるREADオブジェクト権限を付与します。

- データベース内の任意の表に対するREADオブジェクト権限をユーザーが保持できるようにするには、そのユーザーにREAD ANY TABLEシステム権限を付与します。

例:

GRANT READ ANY TABLE TO psmith;

READオブジェクト権限と同様にREAD ANY TABLEシステム権限では、ユーザーは排他モードで表をロックしたり、更新操作用に表を選択したりできません。反対に、SELECT ANY TABLEシステム権限では、ユーザーは任意の表の問合せ以外に、SELECT ... FOR UPDATE文を使用して表の行をロックしたり、表全体をロックできます。

READおよびREAD ANY TABLE権限に対する制限

READ権限とREAD ANY TABLE権限では特別な制限があります。

これらの権限は次のとおりです。

- READオブジェクト権限は、SQL92_SECURITY標準の要件には影響を及ぼしません。SQL92_SECURITY初期化パラメータがTRUEに設定されている場合、UPDATEまたはDELETE文を実行するためにUPDATEまたはDELETE以外にSELECTオブジェクト権限をユーザーに付与する必要があるという要件が緩和されて、SELECTのかわりにREADで十分であるということにはなりません。

- Oracle Database Vaultが有効な場合、SQL92_SECURITY初期化パラメータは自動的にTRUEに設定されることに注意してください。したがって、ユーザーにREADオブジェクト権限またはREAD ANY TABLEシステム権限のみが付与されている場合、UPDATEおよびDELETE文は失敗します。この場合、ユーザーにSELECTオブジェクト権限を付与するか、ユーザーが信頼できるユーザーの場合はSELECT ANY TABLEシステム権限を付与する必要があります。

シノニムでのオブジェクト権限の使用

CREATE SYNONYM文で、データベース・オブジェクトのシノニムを作成します。

表、ビュー、順序、演算子、プロシージャ、ストアド・ファンクション、パッケージ、マテリアライズド・ビュー、Javaクラス・スキーマ・オブジェクト、ユーザー定義オブジェクト・タイプのオブジェクトのシノニムに加え、別のシノニムのシノニムを作成できます。

ユーザーにシノニムを使用する権限を付与すると、基礎オブジェクトで付与されたオブジェクト権限は、ユーザーがベース・オブジェクトを名前で参照するかシノニムを使用して参照するかに関係なく適用されます。

たとえば、ユーザーOEが次のシノニムをCUSTOMERS表に作成するとします。

CREATE SYNONYM customer_syn FOR CUSTOMERS;

それから、OEはcustomer_synシノニムに対するREAD権限をユーザーHRに付与します。

GRANT READ 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    READ
OE            OE          INHERIT PRIVILEGES

結果にはこのユーザーが、他の権限に加えて、customer_synシノニムの基礎オブジェクト、つまりOE.CUSTOMER表に対するREAD権限を持っていることが示されます。

この時点でユーザーOEがcustomer_synシノニムに対するREAD権限をHRから取り消した場合に、HRが自分の権限を再度調べたときの結果を次に示します。

TABLE_SCHEMA  TABLE_NAME  PRIVILEGE
------------  ----------  ------------------
OE            OE          INHERIT PRIVILEGES

ユーザーHRは、OE.CUSTOMER表に対するREAD権限を失っています。このユーザーがOE.CUSTOMERS表を問い合せると、次のエラーが表示されます。

SELECT COUNT(*) FROM OE.CUSTOMERS;

ERROR at line 1:
ORA-00942: table or view does not exist

表権限

表に対するオブジェクト権限によって、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概要を参照してください。

表示権限

DMLオブジェクト権限は、表の場合と同様にビューに対しても適用できます。ビューに対するオブジェクト権限は、ビューの導出元の実表に実際に影響を与える様々な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権限は、注意して処理する必要がある非常に強力な権限です。

スタンドアロン・プロシージャ、ファクションおよびパッケージを含め、プロシージャに対するオブジェクト権限は、EXECUTE権限のみです。

この権限は、プロシージャの実行、または必要なプロシージャをコールする他のプロシージャのコンパイルが必要なユーザーにのみ付与してください。ユーザーに付与された権限を確認するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューに問い合せます。

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

プロシージャに対するEXECUTEオブジェクト権限を使用して、そのプロシージャを実行したり、それを参照するプログラム・ユニットをコンパイルできます。

PL/SQLユニットのコール時には、Oracle Databaseによって実行時権限チェックが実行されます。EXECUTE ANY PROCEDUREシステム権限があるユーザーは、データベース内の任意のプロシージャを実行できます。プロシージャの実行権限は、ロールを介してユーザーに付与できます。

関連項目:

- 定義者権限および実行者権限について

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

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

自分のスキーマ内または別のユーザーのスキーマ内でプロシージャを作成または置換するには、特定の権限が必要です。

自分のスキーマ内でプロシージャを作成または置換するには、CREATE PROCEDUREシステム権限が必要です。別のユーザーのスキーマ内でプロシージャを作成または置換するには、CREATE ANY PROCEDUREシステム権限が必要です。

プロシージャを所有するユーザーには、プロシージャ本体で参照されるスキーマ・オブジェクトに対する権限も必要です。プロシージャを作成するには、そのプロシージャによって参照されるすべてのオブジェクトに対する必要な権限(システム権限やオブジェクト権限)が明示的に付与されている必要があります。これらの必要な権限は、ロールを介して取得することはできません。これには、作成中のプロシージャ内でコールするプロシージャに対するEXECUTE権限も含まれます。

注意:

トリガーの場合、参照オブジェクトに対する権限をトリガーの所有者に直接付与する必要があります。権限が明示的に、またはロールを介して付与されていても、無名PL/SQLブロックでは任意の権限を使用できます。

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

スタンドアロン・プロシージャとパッケージの一部であるプロシージャの両方をコンパイルするには、特定の権限が必要です。

スタンドアロン・プロシージャをコンパイルするには、COMPILE句を使用してALTER PROCEDURE文を実行する必要があります。パッケージの一部であるプロシージャをコンパイルするには、ALTER PACKAGE文を実行する必要があります。

次の例は、スタンドアロン・プロシージャをコンパイルする方法を示しています。

ALTER PROCEDURE psmith.remove_emp COMPILE;

スタンドアロン・プロシージャまたはパッケージ・プロシージャが別のユーザーのスキーマ内にある場合、プロシージャを再コンパイルするにはALTER ANY PROCEDURE権限が必要です。自分のスキーマ内にあるプロシージャは、権限なしで再コンパイルできます。

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

EXECUTE権限は、ユーザーがパッケージ内のPUBLICプロシージャやファンクションを実行できる強力な権限です。

内容は次のとおりです。

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

- 例: 1つのパッケージ内で使用されるプロシージャ権限

- 例: プロシージャ権限およびパッケージ・オブジェクト

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

パッケージに対するEXECUTEオブジェクト権限は、そのパッケージ内のすべてのプロシージャまたはファンクションに適用されます。

パッケージに対するEXECUTEオブジェクト権限を保持するユーザーは、そのパッケージ内の任意のパブリック・プロシージャまたはファンクションを実行し、任意のパブリック・パッケージ変数の値へのアクセスや変更を実行できます。

パッケージの各構成メンバーに、特定のEXECUTE権限を付与することはできません。したがって、データベース・アプリケーションのプロシージャ、ファンクションおよびパッケージを開発する場合は、セキュリティの確立に関して2つの選択肢を考慮してください。これらの選択肢について、次の例で説明します。

例: 1つのパッケージ内で使用されるプロシージャ権限

CREATE PACKAGE BODY文を使用してプロシージャを含むパッケージ本体を作成し、1つのパッケージ内で使用されるプロシージャ権限を管理できます。

例4-4では、2つのパッケージの本体に4つのプロシージャを作成しています。

例4-4: 1つのパッケージ内で使用されるプロシージャ権限

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;

例: プロシージャ権限およびパッケージ・オブジェクト

CREATE PACKAGE BODY文でプロシージャ定義を含むパッケージ本体を作成し、プロシージャ権限とパッケージ・オブジェクトを管理できます。

例4-5は、単一のパッケージ本体にある4つのプロシージャ定義を示しています。2つの追加スタンドアロン・プロシージャと1つのパッケージが特別に作成され、メイン・パッケージ内に定義されているプロシージャへのアクセスを提供します。

例4-5: プロシージャ権限およびパッケージ・オブジェクト

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;

EXECUTE権限をパッケージに対して付与することで、すべてのパッケージ・オブジェクトへの均一なアクセスが提供されることに注意してください。

タイプ権限

型、メソッドおよびオブジェクトについて、システム権限とオブジェクト権限を制御できます。

内容は次のとおりです。

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

- 名前付きの型のオブジェクト権限

- 名前付きの型のメソッド実行モデル

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

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

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

- 型の依存性

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

名前付きの型に対するシステム権限を使用すると、ユーザーは自分のスキーマ内での名前付きの型の作成などのアクションを実行できます。

表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プロシージャと同じです。

ユーザーには、EXECUTE権限など、名前付きの型を使用するための適切な権限が付与されている必要があります。すべての権限付与と同様に、これらの権限は信頼できるユーザーのみに付与してください。ユーザーに付与された権限を確認するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューに問い合せます。

詳細は、「プロシージャ権限」を参照してください。

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

型を作成するには、適切な権限が必要です。

これらの権限は次のとおりです。

- 自分のスキーマにタイプを作成するには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付きで指定)が必要です。どちらの権限もない表の所有者は、権限不足のため、表へのアクセス権を付与できません。

関連項目:

表の作成要件は、「表権限」を参照してください。

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

型に対するEXECUTE権限を他のユーザーに付与するには、GRANT OPTION付きのEXECUTE権限が必要です。

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ロールが現在保持している権限は、CREATE SESSIONおよびSET CONTAINER権限のみです。

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

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 SQL文の使用の詳細は、Oracle Database SQL言語リファレンスを参照してください

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

GRANT文を使用すると、プロシージャの実行などの特定のアクションの実行に関する権限をユーザーに付与できます。GRANTを使用すると、権限受領者は、他のユーザーにも権限を付与できます。

内容は次のとおりです。

- ユーザーおよびロールへのシステム権限とロールの付与

- ユーザーおよびロールへのオブジェクト権限の付与

関連項目:

中間層またはプロキシを介して接続されるユーザーへのロールの付与の詳細は、「プロキシ認証に対する中間層サーバーの使用」を参照してください。

ユーザーおよびロールへのシステム権限とロールの付与

システム権限とロールをユーザーやロールに付与するには、これらのタイプの付与に対して権限がどのように機能するかについて注意してください。

内容は次のとおりです。

- ユーザーおよびロールへのシステム権限とロールの付与のための権限

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

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

- 権限受領ユーザーによる権限付与を可能にするADMINオプションの使用

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

ユーザーおよびロールへのシステム権限とロールの付与のための権限

システム権限とロールを他のユーザーやロールに付与するには、GRANT SQL文を使用します。

次の権限が必要です。

- システム権限を付与するには、ユーザーにADMINオプション付きのシステム権限またはGRANT ANY PRIVILEGEシステム権限が付与されている必要があります。

- ロールを付与するには、ユーザーにADMINオプション付きのロールまたはGRANT ANY ROLEシステム権限が付与されている必要があります。

注意:

オブジェクト権限は、同じGRANT文でシステム権限やロールと同時に付与することはできません。

例: ユーザーへのシステム権限とロールの付与

システム権限とロールをユーザーに付与するには、GRANT文を使用できます。

例4-6では、システム権限CREATE SESSIONとaccts_payロールをユーザーjwardに付与しています。

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

GRANT CREATE SESSION, accts_pay TO jward;

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

ディレクトリ・オブジェクトに対するEXECUTE権限を付与するには、GRANT文を使用できます。

例4-6 では、exec_dirディレクトリ・オブジェクトに対するEXECUTE権限をユーザーjwardに付与しています。

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

GRANT EXECUTE ON DIRECTORY exec_dir TO jward;

権限受領ユーザーによる権限付与を可能にするADMINオプションの使用

WITH ADMIN OPTION句を使用して、権限付与の能力を拡張できます。

これらの機能は次のとおりです。

- 権限受領者は、データベース内の他のユーザーまたはロールに対して、システム権限またはロールの付与または取消しができます。ただし、自分自身からロールを取り消すことはできません。

- 権限受領者は、ADMINオプション付きのシステム権限やロールを付与できます。

- ロールの権限受領者は、そのロールを変更または削除できます。

例4-8では、new_dbaロールをWITH ADMIN OPTION句付きでユーザーmichaelに付与しています。

例4-8 ADMINオプションの付与

GRANT new_dba TO michael WITH ADMIN OPTION;

ユーザーmichaelは、new_dbaロール内の権限をすべて暗黙的に使用できることに加え、必要に応じてnew_dbaロールを付与、取消しおよび削除できます。このように、ADMINオプションは非常に強力な機能であるため、このオプションを付けてシステム権限やロールを付与する際は、十分に注意してください。通常、これらの権限はセキュリティ管理者向けに用意されており、システム内の他の管理者やユーザーに付与することはほとんどありません。ユーザーがロールを作成すると、そのロールは自動的にADMINオプション付きでその作成ユーザーに付与されることに注意してください。

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

1つのGRANT SQL文で、新規ユーザーを作成してこのユーザーに権限を付与できます。

ほとんどの場合、ユーザーにCREATE SESSION権限を付与します。

- GRANT文を使用して新規ユーザーを作成するには、権限およびIDENTIFIED BY句を含めます。

たとえば、新規ユーザーとしてpsmithを作成し、CREATE SESSIONシステム権限をpsmithに付与する方法は、次のとおりです。

GRANT CREATE SESSION TO psmith IDENTIFIED BY password;

IDENTIFIED BY句を使用してパスワードを指定することで、ユーザー名がデータベースに存在しない場合も、指定したユーザー名とパスワードで新しいユーザーが作成されます。

関連項目:

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

- パスワードの最低要件

ユーザーおよびロールへのオブジェクト権限の付与

ユーザーおよびロールにオブジェクト権限を付与できるほか、権限受領者が他のユーザーにその権限を付与することを許可できます。

内容は次のとおりです。

- ユーザーおよびロールへのオブジェクト権限の付与について

- WITH GRANT OPTION句が機能するしくみ

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

- 列に対する権限の付与

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

ユーザーおよびロールへのオブジェクト権限の付与について

GRANT文を使用すると、ロールとユーザーにオブジェクト権限を付与できます。

オブジェクト権限を付与するには、次のいずれかの条件を満たしている必要があります。

- 指定するオブジェクトを所有している。

- GRANT ANY OBJECT PRIVILEGEシステム権限を付与されている。この権限を使用すると、オブジェクト所有者のかわりに権限の付与と取消しを実行できます。

- オブジェクト権限が付与されるときに、WITH GRANT OPTION句が指定されている。

注意:

同じGRANT文で、オブジェクト権限とともにシステム権限とロールを付与することはできません。

次の例では、emp表のすべての列に対するREAD、INSERTおよびDELETEのオブジェクト権限をユーザーjfeeとtsmithに付与しています。

GRANT READ, INSERT, DELETE ON emp TO jfee, tsmith;

salaryビューのすべてのオブジェクト権限をユーザーjfeeに付与するには、次の例のようにALLキーワードを使用します。

GRANT ALL ON salary TO jfee;

注意:

権限受領者は、最初の権限付与にGRANT OPTIONが含まれていないかぎり、オブジェクトへのアクセス権を再度付与することはできません。したがって、前述の例では、jfeeはGRANT文を使用してオブジェクト権限を他の誰かに付与することができません。

WITH GRANT OPTION句が機能するしくみ

GRANT文でWITH GRANT OPTION句を使用すると、権限受領者はオブジェクト権限を他のユーザーに付与できるようになります。

スキーマ内にオブジェクトを格納しているユーザーには、関連するすべてのオブジェクト権限がWITH GRANT OPTION句付きで自動的に付与されます。この特別な権限によって、権限受領者の権限は次のように拡張されます。

- 権限受領者は、データベース内の任意のユーザーにGRANT OPTIONの有無を問わずオブジェクト権限を付与でき、そしてデータベース内の任意のロールに付与できます。

- 次の2つの条件が成立する場合、権限受領者は表に対するビューを作成し、そのビューの対応する権限をデータベース内の任意のユーザーまたはロールに対して付与できます。

- 権限受領者が、表に対するGRANT OPTION付きのオブジェクト権限を受領している。

- 権限受領者に、CREATE VIEWまたはCREATE ANY VIEWシステム権限がある。

注意:

オブジェクト権限をロールに付与する場合、WITH 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;

行レベルのアクセス制御

行レベルで、つまりオブジェクト内でアクセスを制御できますが、GRANT文で行うことはできません。

このタイプのアクセス制御を実行するには、Oracle Virtual Private Database (VPD)またはOracle Label Security (OLS)のいずれかを使用する必要があります。

関連項目:

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

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

- Oracle Label Security管理者ガイド

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

システム権限とオブジェクト権限をユーザーから取り消すことができます。取消しを行う場合、権限の取消しによるカスケード効果について注意してください。

内容は次のとおりです。

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

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

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

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

REVOKE SQL文で、システム権限およびロールを取り消します。

ADMINオプション付きでシステム権限またはロールを付与されているユーザーは、他のデータベース・ユーザーまたはロールから権限またはロールを取り消すことができます。取消しを行うユーザーは、権限やロールを最初に付与したユーザーでなくてもかまいません。GRANT ANY ROLEがあるユーザーは、任意のロールを取り消すことができます。

例4-9は、CREATE TABLEシステム権限とaccts_recロールをユーザーpsmithから取り消します。

例4-9 ユーザーからのシステム権限とロールの取消し

REVOKE CREATE TABLE, accts_rec FROM psmith;

システム権限またはロールのADMINオプションを選択的に取り消すことはできないことに注意してください。権限またはロールを取り消してから、同じ権限またはロールをADMINオプションを指定せずに再度付与する必要があります。

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

ユーザーが所有する複数のオブジェクト権限、オブジェクト所有者のかわりに付与したオブジェクト権限、列を選択するオブジェクト権限、およびREFERENCESオブジェクト権限を取り消すことができます。

内容は次のとおりです。

- オブジェクト権限の取消しについて

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

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

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

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

オブジェクト権限の取消しについて

オブジェクト権限を取り消す場合、ユーザーは一定の要件を満たしている必要があります。

次のいずれかの条件を満たしている必要があります。

- 以前にユーザーまたはロールにオブジェクト権限を付与している。

- オブジェクト所有者のかわりに権限を付与したり取り消すことができるGRANT ANY OBJECT PRIVILEGEシステム権限を所持している。

取り消すことができるのは、権限付与者として自身で直接認可した権限のみです。GRANT OPTIONを付与した他のユーザーによる権限付与を取り消すことはできません。ただし、連鎖的な影響があります。権限付与者のオブジェクト権限を取り消すと、GRANT OPTIONを使用して伝播されたオブジェクト権限も取り消されます。

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

REVOKE文で、1つのオブジェクトに対する複数の権限を取り消すことができます。

最初の権限付与者が次の文を発行すると、ユーザー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システム権限を使用して付与したオブジェクト権限が削除されます。

関連項目:

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

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

列固有操作に対するGRANTおよびREVOKE操作には異なる権限と制約があります。

表やビューの列を指定して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オブジェクト権限を取り消すと、外部キー制約に影響を与えます。

REFERENCESオブジェクト権限の権限受領者がその権限を使用して外部キー制約を作成し、その制約が現在も存在している場合、権限付与者がその権限を取り消すには、REVOKE文にCASCADE CONSTRAINTSオプションを指定します。

例:

REVOKE REFERENCES ON dept FROM jward CASCADE CONSTRAINTS;

CASCADE CONSTRAINTS句を指定すると、取り消されるREFERENCES権限を使用して現在も定義されている外部キー制約が削除されます。

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

DDL操作に関連するオブジェクト権限の取消しではカスケード効果はありませんが、オブジェクト権限の取消しに関するカスケード効果はあります。

内容は次のとおりです。

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

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

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

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に権限またはロールを付与してください。これによって、各データベース・ユーザーには常に、現在のグループ・タスクの正常実行に必要な権限のみが付与されているという一般規則が保証されます。

PUBLICロールから権限を取り消すと、かなりの規模で影響が連鎖する可能性があります。DML操作に関連する任意の権限をPUBLICから取り消すと(たとえばSELECT ANY TABLEまたはUPDATE ON emp)、データベース内のファンクションとパッケージを含むすべてのプロシージャが再認可されるまで再び使用できなくなります。したがって、DMLに関連する権限をPUBLICに付与したり、取り消す場合には注意が必要です。

関連項目:

- オブジェクト依存性の管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

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

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

オペレーティング・システムまたはネットワークを使用して、ロールを管理できます。これは、大規模エンタープライズでのロールの一元管理に役立ちます。

内容は次のとおりです。

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

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

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

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

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

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

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

Oracle Databaseを実行するオペレーティング・システムを使用して、接続時にロールをユーザーに付与できます。

この機能を使用することでセキュリティ管理者は、ユーザーのデータベース・ロールをGRANT文やREVOKE文を使用して明示的に付与したり取り消したりする必要がなくなります。

つまり、オペレーティング・システムを使用してロールを管理し、ユーザーのセッション作成時にOracle Databaseにそのロールを渡すことができます。このメカニズムの一部として、ユーザーのデフォルト・ロールや、ADMINオプション付きでユーザーに付与するロールを識別できます。オペレーティング・システムを使用してロールを使用するユーザーを認可する場合は、必ずすべてのロールをデータベース内に作成し、GRANT文を使用してそのロールに権限を割り当てる必要があります。

ロールは、ネットワーク・サービスを介しても付与できます。

ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の利点は、Oracleデータベースの権限管理をデータベースの外部で実施できることです。オペレーティング・システムに組み込まれたセキュリティ機能によって、ユーザーの権限が制御されます。また、このオプションを使用すると、いくつかのシステム・アクティビティのセキュリティを集中管理できるため、次のような状況で役立ちます。

- MVS版Oracleの管理者が、データベース・ユーザーのロールを識別するためにRACFグループを使用する場合

- UNIX版Oracleの管理者が、データベース・ユーザーのロールを識別するためにUNIXグループを使用する場合

- VMS版Oracleの管理者が、データベース・ユーザーのロールを識別するために権限識別子を使用する場合

ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の主なデメリットは、権限管理がロール・レベルでしか実施できないことです。個々の権限は、オペレーティング・システムを使用して付与することはできません。ただし、GRANT文を使用してデータベース内で付与することは可能です。

この機能を使用する際の第2のデメリットは、オペレーティング・システムがロールを管理している場合に、デフォルトではユーザーが共有サーバーまたはその他のネットワーク接続を介してデータベースに接続できないことです。ただし、このデフォルトはオペレーティング・システムによるロール管理使用時のネットワーク接続の説明に従って変更できます。

注意:

この項で説明されている機能は、一部のオペレーティング・システムでしか使用できません。これらの機能が使用できるかどうかを確認するには、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

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

OS_ROLES初期化パラメータを使用して、オペレーティング・システムがロールをどのように識別するかを制御できます。

セッションの作成時に、データベースがオペレーティング・システムを使用して各ユーザーのデータベース・ロールを識別するように、初期化パラメータ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です。

SET ROLEおよびデフォルト・ロールの設定による権限の付与と取消しの機能

付与と取消しは、権限付与およびSET ROLE文により左右されます。ユーザーに対してデフォルトのロールおよびロールの最大数を設定できます。

内容は次のとおりです。

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

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

- ユーザーのデフォルト・ロールの指定

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

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

付与と取消しがいつ有効になるかは、付与または取り消す権限によって異なります。

権限の付与と取消しは次のように有効になります。

- 任意の対象(ユーザー、ロールおよびPUBLIC)に対するシステム権限とオブジェクト権限の付与および取消しは、即時に有効になります。

- 任意の対象(ユーザー、他のロール、PUBLIC)に対するロールの付与および取消しが有効になるのは、その付与および取消しの実行後、ロールを再度使用可能にするために現行のユーザー・セッションでSET ROLE文を発行したとき、あるいはその付与または取消しを実行した後に新しくユーザー・セッションを作成したときです。

現在使用可能なロールは、SESSION_ROLESデータ・ディクショナリ・ビューを問い合せることによって確認できます。

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

ユーザーまたはアプリケーションは、ユーザー・セッション中にSET ROLE文を何度でも使用して、そのセッションで使用可能になっているロールを変更できます。

ユーザーには、SET ROLE文で指定したロールが、事前に付与されている必要があります。

次の例では、すでに付与されているロールclerkを使用可能にして、パスワードを指定しています。

SET ROLE clerk IDENTIFIED BY password;

「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。

次の例は、SET ROLEを使用してすべてのロールを使用禁止にする方法を示しています。

SET ROLE NONE;

ユーザーのデフォルト・ロールの指定

ユーザーがログインすると、Oracle Databaseではそのユーザーに明示的に付与されている権限と、そのユーザーのデフォルト・ロールに含まれる権限が、すべて使用可能になります。

1. デフォルト・ロールの設定対象のユーザーにロールがGRANT文で直接付与されているか、CREATE ROLE権限があるユーザーによってロールが作成されていることを確認します。

2. DEFAULT ROLE句を指定してALTER USER文を使用して、ユーザーのデフォルト・ロールを指定します。

たとえば、ユーザーjaneに対してデフォルト・ロールのpayclerkとpettycashを設定する方法は、次のとおりです。

ALTER USER jane DEFAULT ROLE payclerk, pettycash;

ALTER USER文のDEFAULT ROLE句の制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。

CREATE USER文ではユーザーのデフォルト・ロールを設定できません。ユーザーを最初に作成すると、デフォルトのユーザー・ロール設定はALLであり、ユーザーにその後に付与されるすべてのロールがデフォルト・ロールになります。デフォルトのユーザー・ロールを制限するには、ALTER USER文を使用します。

注意:

(グローバル・ロールやアプリケーション・ロール以外の)ロールを作成すると、このロールが自分に暗黙的に付与され、自分のデフォルト・ロールのセットが新しいロールを含むように更新されます。ユーザー・セッションで有効にできるロールは148個のみであることに注意してください。DBAロールのような集計ロールがユーザーに付与されると、そのロールに付与されるロールはユーザーが持っているロール数に含まれます。たとえば、あるロールには20個のロールが付与されており、そのロールをユーザーに付与すると、そのユーザーは21個の追加ロールを持っていることになります。したがって、新しいロールをユーザーに付与するときは、ALTER USER文のDEFAULT ROLE句を使用してそのユーザーのデフォルト・ロールとして指定されるロールが多すぎないよう確認してください。

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

ロールはいくつでもユーザーに付与できますが、任意の時点でログイン・ユーザーに対して有効にできるロール数は最大148個です。

したがって、ユーザー・セッションでこのユーザーはすべての権限を使用できるわけではありません。ベスト・プラクティスとして、ユーザーに付与するロールの数を必要最小限のロールに制限します。

ユーザーへのロール付与に関する追加のガイドラインは、ロールの保護に関するガイドラインを参照してください。

ユーザー権限およびロールのデータ・ディクショナリ・ビュー

Oracle Databaseには、各種の権限とロール付与に関する情報を確認できる、一連のデータ・ディクショナリ・ビューがあります。

内容は次のとおりです。

- 権限およびロール付与の情報を確認するデータ・ディクショナリ・ビュー

- すべてのシステム権限の付与を表示する問合せ

- すべてのロール付与を表示する問合せ

- ユーザーに付与されているオブジェクト権限を表示する問合せ

- セッションの現在の権限ドメインを表示する問合せ

- データベースのロールを表示する問合せ

- ロールの権限ドメイン情報を表示する問合せ

権限およびロール付与の情報を確認するデータ・ディクショナリ・ビュー

Oracle Databaseには、権限およびロール付与に関する情報を表示するデータ・ディクショナリ・ビューが用意されています。

表4-6 に、権限とロールの付与に関する情報を入手するために問合せ可能なデータ・ディクショナリ・ビューをリストします。

表4-6 権限およびロール情報を表示するデータ・ディクショナリ・ビュー

ビュー

説明

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_CONTAINER_DATA

マルチテナント環境では、デフォルト(ユーザーレベル)およびオブジェクト固有のCONTAINER_DATA属性を表示します。CONTAINER_DATA句で作成されるオブジェクトには、CONTAINER_DATA属性が含まれます。

DBA_EPG_DAD_AUTHORIZATION

別のユーザー権限の使用が許可されたデータベース・アクセス記述子(DAD)が表示されます

DBA_TAB_PRIVS

データベース内のすべてのオブジェクトに対するすべての権限付与がリストされます。

DBA_ROLES

セキュア・アプリケーション・ロールを含めて、データベース内に存在するすべてのロールがリストされますPUBLICロールはリストされません

DBA_ROLE_PRIVS

ユーザーとロールに直接付与されているロールがリストされます。

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

権限受領者が現行ユーザーであるオブジェクトの権限付与がリストされます。

V$PWFILE_USERS

管理権限を付与された現在のPDBのすべてのユーザーをリストします

ここでは、これらのビューの使用例をいくつか示します。各例では、次の文がすでに発行されていることを前提としています。

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 READ, 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 READ, DELETE ON emp TO jward;

GRANT INSERT (ename, job) ON emp TO swilliams, jward;

関連項目:

これらのデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

すべてのシステム権限の付与を表示する問合せ

DBA_SYS_PRIVSデータ・ディクショナリ・ビューは、ロールとユーザーに対して付与されているすべてのシステム権限を返します。

次に例を示します。

SELECT GRANTEE, PRIVILEGE, ADM 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リファレンス』を参照してください

すべてのロール付与を表示する問合せ

DBA_ROLE_PRIVS問合せは、ユーザーと他のロールに対して付与されているロールをすべて返します。

次に例を示します。

SELECT * FROM DBA_ROLE_PRIVS;

GRANTEE            GRANTED_ROLE                         ADM
------------------ ------------------------------------ ---
SWILLIAMS          SECURITY_ADMIN                       NO

関連項目:
DBA_ROLE_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください

ユーザーに付与されているオブジェクト権限を表示する問合せ

DBA_TAB_PRIVSおよびDBA_COL_PRIVSデータ・ディクショナリ・ビューには、ユーザーに付与されているオブジェクト権限が表示されます。

DBA_TAB_PRIVSデータ・ディクショナリ・ビューは、指定のユーザーに対して付与されているオブジェクト権限をすべて(列固有の権限を除く)返します。

次に例を示します。

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リファレンス』を参照してください

セッションの現在の権限ドメインを表示する問合せ

SESSION_ROLESおよびSESSION_PRIVSデータ・ディクショナリ・ビューには、データベース・セッションの現在の権限ドメインが表示されます。

SESSION_ROLESビューでは、発行者が現在使用できるロールがすべて表示されます。

次に例を示します。

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の各データ・ディクショナリ・ビューには、ロールの権限ドメインに関する情報が表示されます。

次に例を示します。

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 定義者権限および実行者権限のセキュリティの管理

ユーザー作成プロシージャの実行権限へのアクセス制御で実行者権限および定義者権限を使用すると、セキュリティ上のメリットが得られます。

内容は次のとおりです。

- 定義者権限および実行者権限について

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

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

- 実行者権限プロシージャを作成する場合

- プロシージャ・コールおよびビュー・アクセスの実行者権限の制御

- ビューの定義者権限および実行者権限

- 定義者権限および実行者権限のコード・ベース・アクセス制御の使用

定義者権限および実行者権限について

定義者権限および実行者権限は、ユーザー作成プロシージャまたはプログラム・ユニットの実行に必要な権限へのアクセスを制御するときに使用されます。

定義者権限プロシージャでは、プロシージャが所有者の権限で実行されます。権限は、作成されたスキーマにバインドされます。実行者の権限プロシージャは現行ユーザー(プロシージャを実行するユーザー)の権限で実行されます。

たとえば、ユーザーbixbyが表cust_recordsを変更するために設計されるプロシージャを作成し、このプロシージャのEXECUTE権限をユーザーrlaytonに付与するとします。bixbyが定義者権限でプロシージャを作成した場合、プロシージャはbixbyのスキーマの表cust_recordsを検索します。プロシージャが実行者権限で作成された場合、rlaytonが実行すると、プロシージャはrlaytonのスキーマの表cust_recordsを検索します。

デフォルトでは、すべてのプロシージャは、定義者権限とみなされます。作成時または変更時に、AUTHID CURRENT_USER句を使用してプロシージャを実行者権限プロシージャに指定するか、AUTHID DEFINER句を使用して定義者権限プロシージャに変更できます。

関連項目:

定義者権限および実行者権限プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

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

定義者と呼ばれるプロシージャの所有者は、プロシージャが参照するオブジェクトに対する必要なオブジェクト権限を所有している必要があります。

プロシージャ所有者が別のユーザーにそのプロシージャを使用する権限を付与すると、(プロシージャで参照されるオブジェクトに対する)プロシージャ所有者の権限が、権限受領者のプロシージャ実行に適用されます。プロシージャの定義者の権限は、ロールを介してではなく、プロシージャ所有者に直接付与する必要があります。これらは、定義者権限と呼ばれます。

所有者以外のプロシージャのユーザーは、実行者と呼ばれます。実行者権限プロシージャの場合は、参照オブジェクトに対する追加の権限が必要ですが、 定義者権限プロシージャの場合は不要です。

定義者権限プロシージャのユーザーに必要なのは、そのプロシージャを実行する権限のみで、そのプロシージャでアクセスする基礎となるオブジェクトに対する権限は不要です。これは、定義者権限プロシージャは、その実行者に関係なく、プロシージャを所有するユーザーのセキュリティ・ドメインの下で動作するためです。プロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。定義者権限プロシージャのユーザーに付与する権限は、できるかぎり控えめに付与してください。これによって、データベース・アクセスを厳密に制御できます。

定義者権限プロシージャを使用すると、プライベート・データベース・オブジェクトへのアクセスを制御し、データベースのセキュリティ・レベルを強化できます。定義者権限プロシージャを記述し、ユーザーにEXECUTE権限のみを付与することによって、そのプロシージャを介さない場合には、このユーザーが参照オブジェクトにアクセスできないように規定できます。

実行時には、定義者権限プロシージャの所有者の権限によってそのプロシージャの参照オブジェクトへのアクセスが許可されているかどうかが、プロシージャの実行前にチェックされます。参照オブジェクトに対して必要な権限が、定義者権限プロシージャの所有者から取り消されていると、所有者を含むユーザーは、プロシージャを実行できません。

定義者権限プロシージャを使用する場合の例は次のとおりです。表へのアクセスが制限されていないプロシージャを持つAPIを作成する必要があるとします。ただし、一般ユーザーが表のデータを直接選択し、INSERT文、UPDATE文およびDELETE文を使用して変更しないようにする必要があります。これを実行するには、個別の権限の弱いスキーマで、APIを構成する表およびプロシージャを作成します。デフォルトでは各プロシージャは定義者権限ユニットであるため、作成時にAUTHID DEFINERを指定する必要がありません。次に、EXECUTE権限をこのAPIを使用する必要があるユーザーに付与しますが、データ・アクセスを許可する権限を付与しないでください。この解決策は、API動作の完全な制御およびユーザーが基礎オブジェクトにアクセスする方法を提供します。

独自のスキーマで、定義者権限プロシージャおよびこれらのプロシージャにアクセスするビューを作成することをお薦めします。このスキーマに非常に弱い権限を付与するか、権限を付与しません。これによって、他のユーザーがこれらのプロシージャまたはビューを実行する場合、このスキーマの不要な高い権限にアクセスしません。

注意:

トリガーの処理は、定義者権限プロシージャと同じパターンに従います。ユーザーは、実行権限があるSQL文を実行します。このSQL文の実行結果として、トリガーが起動されます。トリガーされたアクション内の文は、そのトリガーを所有するユーザーのセキュリティ・ドメインで一時的に実行されます。詳細は、『Oracle Database概要』のトリガーの概要に関する項を参照してください。

関連項目:

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

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

実行者権限プロシージャは、すべての実行者権限で実行されます。

実行者の使用可能な任意のロールを介してその実行者に付与された権限は、定義者権限プロシージャによって実行者権限プロシージャが直接または間接的にコールされないかぎり有効です。実行者権限プロシージャのユーザーには、そのプロシージャが実行者のスキーマ内で解決される外部参照を介してアクセスする、オブジェクトに対する権限(直接またはロールを介して付与されたもの)が必要です。実行者が実行者権限プロシージャを実行する場合、このユーザーは、実行者のすべての権限を一時的に保持します。(実行者権限プロシージャのこの側面の詳細は、プロシージャ・コールおよびビュー・アクセスの実行者権限の制御を参照してください。)

実行者には、DML文または動的SQL文に埋め込まれているプログラム参照にアクセスする権限が実行時に必要です。これは、この種のプログラム参照は実質的に実行時に再コンパイルされるためです。

PL/SQLファンクションの直接コールなど、他のすべての外部参照の場合、所有者権限はコンパイル時にチェックされ、実行時にはチェックされません。したがって、実行者権限プロシージャのユーザーには、DML文や動的SQL文の外側にある外部参照に対する権限は不要です。また、実行者権限プロシージャの開発者による権限の付与が必要なのは、プロシージャ自体に対する権限付与のみで、その実行者権限プロシージャによって直接参照されるすべてのオブジェクトに対する権限付与は必要ありません。

複数のプログラム・ユニットからなり、そのうちのいくつかは定義者権限、その他は実行者権限とするソフトウェア・バンドルを作成して、プログラム・エントリ・ポイントを制限できます(制御されたステップイン)。エントリ・ポイント・プロシージャの実行権限があるユーザーは、内部プログラム・ユニットも間接的に実行できますが、内部プログラムを直接コールすることはできません。問合せ処理を厳密に制御するには、PL/SQLパッケージ仕様を明示的なカーソルを使用して作成できます。

実行者権限プロシージャを作成する場合

特定の状況で実行者権限プロシージャを作成することをお薦めします。

これらの状況は次のとおりです。

- 権限の高いスキーマのPL/SQLプロシージャを作成する場合。権限の弱いユーザーがプロシージャを起動する場合、それらのユーザーが実行を許可された部分のみ実行できます。つまり、実行者権限プロシージャは、実行するユーザーの権限で実行されます。

- PL/SQLプロシージャがSQLを含まず、PL/SQLプロシージャを他のユーザーが使用できる場合。DBMS_OUTPUT PL/SQLパッケージは、SQLを含まないすべてのユーザーが使用できるPL/SQLサブプログラムの例です。この状況で実行者権限プロシージャを使用する必要がある理由は、ユニットが実行時にSQL文を発行しないので、実行時システムが権限をチェックする必要がないためです。AUTHID CURRENT_USERを指定すると、実行者権限プロシージャがコール・スタックを使用する場合にCURRENT_USERおよびCURRENT_SCHEMAの値と現在有効なロールが変更されないため、プロシージャの起動がより効率的になります。

関連項目:

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

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

- Oracle Databaseで名前の解決を処理する方法と、実行者権限および定義者権限を使用して実行時の権限チェックを処理する方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 実行者権限と定義者権限のユニットの違いの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- CREATE PACKAGE文で明示的なカーソルを定義する方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

プロシージャ・コールおよびビュー・アクセスの実行者権限の制御

INHERIT PRIVILEGES権限とINHERIT ANY PRIVILEGES権限を使用して、実行者権限プロシージャの実行時に使用される権限を規制できます。

内容は次のとおりです。

- スキーマの権限が実行者権限プロシージャの使用に与える影響

- INHERIT [ANY] PRIVILEGES権限による権限アクセスの制御方法

- 他のユーザーへのINHERIT PRIVILEGES権限の付与

- 例: 実行するユーザーへのINHERIT PRIVILEGESの付与

- 例: INHERIT PRIVILEGESの取消し

- 他のユーザーへのINHERIT ANY PRIVILEGES権限の付与

- 例: 信頼できるプロシージャ所有者へのINHERIT ANY PRIVILEGESの付与

- INHERIT PRIVILEGESおよびINHERIT ANY PRIVILEGESの管理

スキーマの権限が実行者権限プロシージャの使用に与える影響

権限の低いユーザーが権限の高いユーザーが所有するプロシージャを実行するような場合は、実行者権限プロシージャが便利です。

ユーザーが実行者権限プロシージャ(またはAUTHID CURRENT_USER句で作成されたPL/SQLプログラム・ユニット)を実行する場合、プロシージャの実行中に実行するユーザーのすべての権限を一時的に継承します。

その期間中に、プロシージャ所有者は、プロシージャを通じて、この実行するユーザーの権限にアクセスできます。次の使用例を考えてみます。

1. ユーザーebrownは、check_syntax実行者権限プロシージャを作成し、ユーザーjwardにそのEXECUTE権限を付与します。

2. 準プログラマのユーザーebrownは、仕事に必要な最低限のセットの権限のみです。check_syntaxプロシージャは、ebrownのスキーマにあります。

3. マネージャのユーザーjwardは、ユーザーebrownよりさらに強力なセットの権限を持ちます。

4. ユーザーjwardがcheck_syntax実行者権限プロシージャを実行する場合、プロシージャは実行中にユーザーjwardより高い権限を継承します。

5. ユーザーebrownがcheck_syntaxプロシージャを所有するため、jwardがcheck_syntaxプロシージャを実行するたびに、ユーザーjwardの権限にアクセスできます。

jwardがプロシージャを実行するたびに権限の弱いebrownのプロシージャがjwardの高い権限にアクセスできるこのタイプの状況の危険性は、プロシージャ所有者が実行するユーザーの高い権限を悪用できるリスクがあることです。たとえば、ユーザーebrownは、check_syntaxプロシージャをリライトしてebrownを上げるかebrownの不良なパフォーマンス評価レコードを削除して、jwardの高い権限を使用する可能性があります。また、ebrownは、元から定義者権限プロシージャとしてプロシージャを作成し、EXECUTE権限をjwardに付与して、後でjwardに通知することなく不正な可能性のある実行者権限プロシージャに変更できた可能性があります。アプリケーション・ユーザーなどのランダムなユーザーが実行者権限プロシージャを使用するデータベースにアクセスできる場合、これらのタイプのリスクが増加します。

ユーザーjwardがebrownの実行者権限プロシージャを実行する場合、信頼要素が含まれます。ebrownがjwardの権限にアクセスする場合に悪質な方法でcheck_syntaxプロシージャを使用しないことを確認する必要があります。INHERIT PRIVILEGESおよびINHERIT ANY PRIVILEGES権限は、ユーザーjwardに対してユーザーebrownのプロシージャがjwardの権限にアクセスできるかどうかの制御をサポートできます。ユーザーは、実行する実行者権限プロシージャのユーザーへのINHERIT PRIVILEGES権限を付与または取り消すことができます。SYSユーザーは、INHERIT ANY PRIVILEGES権限を管理します。

INHERIT [ANY] PRIVILEGES権限による権限アクセスの制御方法

INHERIT PRIVILEGESおよびINHERIT ANY PRIVILEGES権限を使用して、実行者権限プロシージャを保護します。

INHERIT PRIVILEGESおよびINHERIT ANY PRIVILEGES権限は、ユーザーが実行者権限プロシージャを実行するか、実行者権限プロシージャを参照するBEQUEATH CURRENT_USERビューに問い合せる場合に使用される権限を規制します。

ユーザーが実行者権限プロシージャを実行する場合、Oracle Databaseは、プロシージャ所有者が実行するユーザーのINHERIT PRIVILEGES権限を持っているか、所有者にINHERIT ANY PRIVILEGES権限が付与されているかを確認します。権限チェックに失敗した場合、Oracle Databaseは、 ORA-06598: INHERIT PRIVILEGES権限が不十分ですエラーを戻しません。

これらの2つの権限の利点は、実行者権限プロシージャを実行するか、BEQUEATH CURRENT_USERビューに問い合せる場合、実行するユーザーに権限にアクセスできるユーザーの制御を提供することです。

他のユーザーへのINHERIT PRIVILEGES権限の付与

デフォルトで、すべてのユーザーにINHERIT PRIVILEGES ON USER newuser TO PUBLICが付与されます。

付与が行われるのは、ユーザー・アカウントの作成時または以前に作成されたアカウントが現在のリリースにアップグレードされたときです。

実行するユーザーは、他のユーザーのINHERIT PRIVILEGE権限を取り消して、信頼するユーザーにのみ付与できます。

INHERIT PRIVILEGES権限の付与の構文は次のとおりです。

GRANT INHERIT PRIVILEGES ON USER invoking_user TO procedure_owner;

次のように値を指定します。

- invoking_userは、実行者権限プロシージャを実行するユーザーです。このユーザーは、データベース・ユーザー・アカウントである必要があります。

- procedure_ownerは、実行者権限プロシージャを所有するユーザーです。この値は、データベース・ユーザー・アカウントである必要があります。INHERIT PRIVILEGES権限をプロシージャの所有者に付与するかわりに、プロシージャに付与されるロールに権限を付与できます。

次のユーザーまたはロールは、実行者権限プロシージャを実行するユーザーによって付与されるINHERIT PRIVILEGES権限を持つ必要があります。

- 実行者権限プロシージャを所有するユーザーまたはロール

- BEQUEATH CURRENT_USERビューを所有するユーザーまたはロール

例: 実行するユーザーへのINHERIT PRIVILEGESの付与

GRANT文で、実行するユーザーのINHERIT PRIVILEGES権限をプロシージャ所有者に付与できます。

例5-1は、実行するユーザーjwardがユーザーebrownにINHERIT PRIVILEGES権限を付与する方法を示しています。

例5-1 プロシージャ所有者への実行するユーザーのINHERIT PRIVILEGESの付与

GRANT INHERIT PRIVILEGES ON USER jward TO ebrown;

この文により、jwardが実行するとき、ebrownが書き込むまたは今後書き込む実行者権限プロシージャがjwardの権限にアクセスできます。

例: INHERIT PRIVILEGESの取消し

REVOKE文で、ユーザーのINHERIT PRIVILEGES権限を取り消すことができます。

例5-2は、ユーザーjwardがebrownの権限の使用を取り消す方法を示しています。

例5-2 INHERIT PRIVILEGESの取消し

REVOKE INHERIT PRIVILEGES ON USER jward FROM ebrown;

他のユーザーへのINHERIT ANY PRIVILEGES権限の付与

デフォルトでは、ユーザーSYSは、INHERIT ANY PRIVILEGESシステム権限を持ち、この権限を他のデータベース・ユーザーまたはロールに付与できます。

すべてのANY権限と同様に、信頼できるユーザーまたはロールにのみこの権限を付与します。ユーザーまたはロールにINHERIT ANY PRIVILEGES権限が付与されると、このユーザーの実行者権限プロシージャは、実行するユーザーの権限にアクセスできます。DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せて、INHERIT ANY PRIVILEGES権限を付与されたユーザーを確認できます。

例: 信頼できるプロシージャ所有者へのINHERIT ANY PRIVILEGESの付与

GRANT文で、INHERIT ANY PRIVILEGES権限を信頼できるプロシージャ所有者に付与できます。

例5-3は、ユーザーebrownへのINHERIT ANY PRIVILEGES権限の付与方法を示しています。

例5-3 信頼できるプロシージャ所有者へのINHERIT ANY PRIVILEGESの付与

GRANT INHERIT ANY PRIVILEGES TO ebrown;

強力なユーザーのINHERIT ANY PRIVILEGES権限の取消しに注意してください。たとえば、ユーザーSYSTEMが一連の実行者権限プロシージャを作成したとします。SYSTEMのINHERIT ANY PRIVILEGESを取り消す場合、INHERIT PRIVILEGE権限を特に付与しないかぎり、他のユーザーはプロシージャを実行できません。

INHERIT PRIVILEGESおよびINHERIT ANY PRIVILEGESの管理

デフォルトでは、PUBLICは、新しいユーザー・アカウントおよびアップグレードされたユーザー・アカウントのINHERIT PRIVILEGE権限を持ち、SYSユーザーは、INHERIT ANY PRIVILEGES権限を持ちます。

デフォルトでは、様々なOracleで定義されているユーザーの権限の悪用に対して保護できるよう設計されている一連のINHERIT PRIVILEGESの付与を構成します。

顧客が定義するユーザーのINHERIT PRIVILEGES ON USER user_name TO PUBLICのデフォルトの付与を取り消して、その特定のユーザーに応じて詳細な付与のINHERIT PRIVILEGESを付与できます。INHERIT ANY PRIVILEGES権限を付与されたユーザーを確認するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せます。

1. PUBLICからINHERIT PRIVILEGES権限を取り消します。

例:

REVOKE INHERIT PRIVILEGES ON invoking_user FROM PUBLIC;

失敗したINHERIT PRIVILEGESチェックの実行時エラーのため、この時点で実行者権限プロシージャを実行するユーザーは実行できないことに注意してください。

2. INHERIT PRIVILEGES権限を信頼できるユーザーまたはロールに選択的に付与します。

3. 同様に、INHERIT ANY PRIVILEGES権限を信頼できるユーザーまたはロールにのみ選択的に付与します。

監査ポリシーを作成してこれらの2つの権限の付与および取消しを監査できますが、失敗したINHERIT PRIVILEGES権限チェックによって発生する実行時エラーは監査できません。

関連項目:

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

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

ビューの定義者権限および実行者権限

CREATE VIEW SQL文でBEQEATH句を使用して、ユーザー作成ビューで定義者権限と実行者権限を制御できます。

内容は次のとおりです。

- ビューの定義者権限および実行者権限の制御について

- CREATE VIEW文のBEQUEATH句の使用

- 実行するユーザーのユーザー名またはユーザーIDの確認

- BEQUEATH DEFINERおよびBEQUEATH_CURRENT_USERビューの確認

ビューの定義者権限および実行者権限の制御について

ユーザー定義ビューを構成して、ビューで参照される実行者権限関数に対応できます。

ユーザーがIDまたは権限依存のSQL関数または実行者権限のPL/SQLまたはJava関数を起動すると、現在のスキーマ、現在のユーザーおよび操作の実行内の現在有効なロールがビューの所有者に設定することなく問い合せたユーザーの環境から継承できます。

この構成は、ビュー自体から実行者権限のオブジェクトに変更しません。ビュー所有者のスキーマを使用してビュー内の名前解決が引き続き処理され、ビュー所有者の権限を使用してビューの権限チェックが実行されます。ただし、実行時に、ビューで参照される関数は、ビュー所有者ではなく実行するユーザーの権限で実行されます。

この機能の利点は、関数をビューで参照する場合に一貫した結果を戻すために実行するユーザーに正確な情報を戻す必要がある SYS_CONTEXTや USERENVなどの関数を有効にすることです。

CREATE VIEW文のBEQUEATH句の使用

BEQUEATHは、実行ユーザーの権限を使用してどのように実行者権限関数を実行するかを制御します。

ビューを参照するSQLを発行するユーザーの権限を使用して実行者権限関数を実行するには、CREATE VIEW文で、BEQUEATH句をCURRENT_USERに設定します。

ビューに対するSQL問合せまたはDML文を発行する場合、ビュー所有者は、実行するユーザーのINHERIT PRIVILEGES権限を付与するか、INHERIT ANY PRIVILEGES権限を持つ必要があります。そうしないと、SELECT問合せまたはDML文がBEQUEATH CURRENT_USERビューを含む場合、実行時システムは、エラー「ORA-06598: INHERIT PRIVILEGES権限が不十分です」を表示します。

- BEQUEATH CURRENT_USER句を使用して、実行者権限を使用して実行するビューの関数を設定します。

例:

CREATE VIEW MY_OBJECTS_VIEW BEQUEATH CURRENT_USER AS
SELECT GET_OBJS_FUNCTION;

ビューの所有者の権限を使用してビュー内の関数を実行する場合、BEQUEATH句を省略するか、DEFINERに設定します。

例:

CREATE VIEW my_objects_view BEQUEATH DEFINER AS
SELECT OBJECT_NAME FROM USER_OBJECTS;

関連項目:

- INHERIT PRIVILEGE権限の使用方法の詳細は、プロシージャ・コールおよびビュー・アクセスの実行者権限の制御を参照してください

- INHERIT PRIVILEGESおよびINHERIT ANY PRIVILEGES権限の付与の詳細は、『Oracle Database SQL言語リファレンス』を参照してください

- Oracle Database Real Application SecurityアプリケーションでのBEQUEATH CURRENT_USERビューの使用方法の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

実行するユーザーのユーザー名またはユーザーIDの確認

実行者権限または定義者権限を使用するかどうかに基づいて、PL/SQLファンクションを使用して、実行するユーザーを確認できます。

- 実行者権限または定義者権限のどちらを使用するかに基づいて、ORA_INVOKING_USER関数またはORA_INVOKING_USERID関数を使用して、実行するユーザーを確認します。

- ORA_INVOKING_USER: この関数を使用して、現在の文またはビューを実行しているユーザーの名前を戻します。この関数は、介在しているビューをBEQUEATH句で指定されたとみなします。実行するユーザーがOracle Database Real Application Securityで定義されているユーザーの場合、この関数はXS$NULLを戻します。

- ORA_INVOKING_USERID: この関数を使用して、現在の文またはビューを実行しているユーザーの識別子(ID)を戻します。この関数は、介在しているビューをBEQUEATH句で指定されたとみなします。実行するユーザーがOracle Database Real Application Securityで定義されているユーザーである場合、この関数は、すべてのReal Application Securityセッションに共通でデータベース・ユーザーのIDとは異なるIDを戻します。
例:

CONNECT HR
Enter password: password

SELECT ORA_INVOKING_USER FROM DUAL;

ORA_INVOKING_USER
--------------------
HR

関連項目:

Oracle Database Real Application Securityアプリケーションに使用される類似の関数の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

BEQUEATH DEFINERおよびBEQUEATH_CURRENT_USERビューの確認

ビューがBEQUEATH DEFINERまたはBEQUEATH CURRENT_USERビューであるかどうかを確認できます。

- ビューがBEQUEATH DEFINERまたはBEQUEATH CURRENT_USERビューであるかどうかを確認するには、そのビューの*_VIEWSまたは*_VIEWS_AE静的データ・ディクショナリ・ビューのBEQUEATH列を問い合せます。

関連項目:

- 静的データ・ディクショナリ・ビュー*_VIEWSの詳細は、『Oracle Databaseリファレンス』を参照してください。

- 静的データ・ディクショナリ・ビュー*_VIEWS_AEの詳細は、『Oracle Databaseリファレンス』を参照してください。

例:

SELECT BEQUEATH FROM USER_VIEWS WHERE VIEW_NAME = 'MY_OBJECTS';

BEQUEATH
------------
CURRENT_USER

定義者権限および実行者権限のコード・ベース・アクセス制御の使用

コード・ベース・アクセス制御を使用して、PL/SQLファンクション、プロシージャまたはパッケージにデータベース・ロールをアタッチできます。この機能は、実行者権限および定義者権限のプログラム・ユニットで効果があります。

内容は次のとおりです。

- アプリケーションのコード・ベース・アクセス制御の使用について

- コード・ベースのアクセス制御ロールをプログラム・ユニットに付与できる者

- コード・ベース・アクセス制御による実行者権限のプログラム・ユニットの処理方法

- コード・ベース・アクセス制御による定義者権限のプログラム・ユニットの処理方法

- CBAC付与のためのユーザーへのデータベース・ロールの付与

- プログラム・ユニットに対するデータベース・ロールの付与と取消し

- チュートリアル: コード・ベース・アクセス制御による機密データへのアクセス制御

アプリケーションのコード・ベース・アクセス制御の使用について

コード・ベース・アクセス制御(CBAC)を使用すると、実行者権限のプログラム・ユニットの管理を向上できます。

アプリケーションは、昇格した権限を必要とする一方で、コール側の環境でプログラム・ユニットを頻繁に実行する必要があります。従来PL/SQLプログラムは、定義者権限を使用してプログラムの権限を一時的に昇格します。

ただし、定義者権限ベースのプログラム・ユニットは、実行者のコンテキストではなくプログラム・ユニットの定義者または所有者のコンテキストで実行されます。また、定義者権限ベースのプログラムを使用すると、多くの場合にプログラム・ユニットが必要以上の権限を取得します。

コード・ベース・アクセス制御(CBAC)は、PL/SQLファンクション、プロシージャまたはパッケージへのデータベース・ロールのアタッチを可能にして、解決策を提供します。これらのデータベース・ロールは実行時に有効で、呼び出すユーザーの環境の必要な権限でプログラム・ユニットを実行できます。

コード・ベースのアクセス制御ロールをプログラム・ユニットに付与できる者

次のすべての条件を満たした場合、コード・ベースのアクセス制御ロールをプログラム・ユニットに付与できます。

これらの条件は次のとおりです。

- 権限付与者は、ユーザーSYS、またはプログラム・ユニットの所有者です。

- 権限付与者がプログラム・ユニットを所有する場合、権限付与者はGRANT ANY ROLEシステム権限を持つか、プログラム・ユニットに付与するロールに対してADMINまたはDELEGATEオプションを持つ必要があります。

- 付与対象のロールは、所有者に対して直接付与されるロールです。

- 付与対象のロールは、標準データベース・ロールです。

これらの3つの条件が満たされない場合、1番目の条件が満たされないときは、エラーORA-28702: プログラム・ユニットの文字列が権限付与者によって所有されていませんが生成され、2番目と3番目の条件が満たされないときは、エラーORA-1924: ロールの文字列は付与されていないか、存在していませんが生成されます。

関連項目:

- CBAC付与のためのユーザーへのデータベース・ロールの付与

- プログラム・ユニットに対するデータベース・ロールの付与と取消し

コード・ベース・アクセス制御による実行者権限のプログラム・ユニットの処理方法

コード・ベース・アクセス制御では、実行ユーザーのコンテキストで、そのコンテキストに関連付けられたロールを使用してプログラム・ユニットを実行できます。

2つのアプリケーション・ユーザー1および2が存在するシナリオを検討します。アプリケーション・ユーザー2は、実行者権限のプログラム・ユニットを作成し、データベース・ロール2を実行者権限ユニットに付与して、実行者権限ユニットの実行権限をアプリケーション・ユーザー1に付与します。

図5-1に、アプリケーション・ユーザー1および2に付与されるデータベース・ロール1および2と実行者権限のプログラム・ユニットを示します。

図5-1 アプリケーション・ユーザーに付与されるロールおよび実行者権限のプログラム・ユニット

付与は次のとおりです。

- アプリケーション・ユーザー1に直接データベース・ロール1および4が付与されます。

- アプリケーション・ユーザー2に直接アプリケーション・ロール3および4を含むデータベース・ロール2が付与されます。

- 実行者権限のプログラム・ユニットにデータベース・ロール2が付与されます。

アプリケーション・ユーザー1がログインして実行者権限のプログラム・ユニットを実行する場合、実行者権限ユニットは、ユーザー1の結合されたデータベース・ロールおよび実行者権限ユニットに付加されたデータベース・ロールで実行されます。

図5-2は、実行者権限ユニットが実行されるセキュリティ・コンテキストを示しています。アプリケーション・ユーザー1が最初にログオンする場合、アプリケーション・ユーザー1は、データベースPUBLICロール(デフォルト)およびそれに付与されたデータベース・ロール1および4を持ちます。次に、アプリケーション・ユーザー1は、アプリケーション・ユーザー2によって作成された実行者権限のプログラム・ユニットを実行します。

実行者権限のユニットは、アプリケーション・ユーザー1のコンテキストで実行され、それに付加される追加のデータベース・ロール2を持ちます。データベース・ロール2の一部であるため、データベース・ロール3および4が含まれます。実行者権限ユニットを終了した後、アプリケーション・ユーザー1のみ、それに付与されたアプリケーション・ロール、PUBLIC、ロール1およびロール4を持ちます。

図5-2 実行者権限のプログラム・ユニットIRが実行されるセキュリティ・コンテキスト

コード・ベース・アクセス制御による定義者権限のプログラム・ユニットの処理方法

コード・ベース・アクセス制御を使用して定義者権限を保護できます。

コード・ベース・アクセス制御は、定義するユーザーの権限で動作するプログラム・ユニットを有効にすることで定義者権限のプログラム・ユニットと連携し、このユーザーに関連付けられるデータベース・ロールを組み合せた権限で機能します。

アプリケーション・ユーザー2が定義者権限のプログラム・ユニットを作成し、定義者権限のプログラム・ユニットにロール2を付与して、定義者権限のプログラム・ユニットのEXECUTE権限をアプリケーション・ユーザー1に付与するシナリオを検討します。

図5-3に、アプリケーション・ユーザー1および2に付与されるデータベース・ロールと定義者権限のプログラム・ユニットを示します。

図5-3 アプリケーション・ユーザーに付与されるロールおよび定義者権限のプログラム・ユニット

付与は次のとおりです。

- アプリケーション・ユーザー1に直接データベース・ロール1および4が付与されます。

- アプリケーション・ユーザー2に直接データベース・ロール3および4を含むデータベース・ロール2が付与されます。

- 定義者権限のプログラム・ユニットにデータベース・ロール2が付与されます。

アプリケーション・ユーザー1がログインして定義者権限のプログラム・ユニットを実行する場合、定義者権限ユニットは、アプリケーション・ユーザー2の結合されたデータベース・ロールおよび定義者権限ユニットに付加されたデータベース・ロール(ロール2、3および4)で実行されます。

図5-4は、定義者権限のプログラム・ユニットが実行されるセキュリティ・コンテキストを示しています。アプリケーション・ユーザー1が最初にログオンする場合、アプリケーション・ユーザー1は、データベースPUBLICロール(デフォルト)およびそれに付与されたデータベース・ロール1および4を持ちます。次に、アプリケーション・ユーザー1は、アプリケーション・ユーザー2によって作成された定義者権限のプログラム・ユニットを実行します。

定義者権限のプログラム・ユニットは、アプリケーション・ユーザー2のコンテキストで実行され、それに付加される追加のデータベース・ロール2を持ちます。データベース・ロール2の一部であるため、データベース・ロール3および4が含まれます。定義者権限ユニットを終了した後、アプリケーション・ユーザー1のみ、それに付与されたデータベース・ロール(PUBLIC、ロール1およびロール4)を持ちます。

図5-4 定義者権限のプログラム・ユニットDRが実行されるセキュリティ・コンテキスト

CBAC付与のためのユーザーへのデータベース・ロールの付与

GRANT文のDELEGATEオプションで、CBAC付与を行うユーザーによるロールへの権限付与を制限できます。

データベース・ロールをCBAC付与を行うユーザーに付与する場合、GRANT文にDELEGATEオプションを含めて、権限受領者にロールに対する追加権限が付与されないようにすることができます。

DELEGATEオプションを使用すると、ロールはプログラム・ユニットに付与されますが、他のプリンシパルまたはロール自体の管理にロールを付与することはできません。他のプリンシパルへのロールの付与を可能にするADMINオプションを付与に使用することもできます。ADMINとDELEGATEオプションは共存できます。オプションごとに別のGRANT文で付与する必要はありますが、両方をユーザーに付与することができます。これらのオプション付きでユーザーにロールが付与されているかどうかを確認するには、ユーザーのUSER_ROLE_PRIVSまたはDBA_ROLE_PRIVSのDELEGATE_OPTION列またはADMIN_OPTION列を問い合せます。

DELEGATEおよびADMINオプションを使用するための構文は次のとおりです。

GRANT role_list to user_list WITH DELEGATE OPTION;

GRANT role_list to user_list WITH ADMIN OPTION;

例:

GRANT cb_role1 to usr1 WITH DELEGATE OPTION;

GRANT cb_role1 to usr1 WITH ADMIN OPTION;

GRANT cb_role1, cb_role2 to usr1, usr2 with DELEGATE OPTION;

GRANT cb_role1, cb_role2 to usr1, usr2 with ADMIN OPTION;

マルチテナント環境では、ADMINオプションの場合と同様に共通ロールの共通ユーザーへの付与などの共通付与にDELEGATEオプションを使用できます。

例:

GRANT c##cb_role1 to c##usr1 WITH DELEGATE OPTION CONTAINER = ALL;

CBAC付与自体は、PDBでローカルにのみ行えることに注意してください。

関連項目:

ADMINオプションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

プログラム・ユニットに対するデータベース・ロールの付与と取消し

GRANTおよびREVOKE文で、プログラム・ユニットに対するデータベース・ロールの付与または取消しを行うことができます。

次の構文を使用して、PL/SQLファンクション、プロシージャまたはパッケージのデータベース・ロールを付与または取り消します。

GRANT role_list TO code_list
REVOKE {role_list | ALL} FROM code_list

次のように値を指定します。

role_list ::=  code-based_role_name[, role_list]
code_list ::=  {
{FUNCTION  [schema.]function_name}
|  {PROCEDURE [schema.]procedure_name}
|  {PACKAGE   [schema.]package_name}
}[, code_list]

例:

GRANT cb_role1 TO FUNCTION func1, PACKAGE pack1;

GRANT cb_role2, cb_role3 TO FUNCTION HR.func2, PACKAGE SYS.pack2;

REVOKE cb_role1 FROM FUNCTION func1, PACKAGE pack1;

REVOKE ALL FROM FUNCTION HR.func2, PACKAGE SYS.pack2;

関連項目:

- コード・ベースのアクセス制御ロールをプログラム・ユニットに付与できる者

- CBAC付与のためのユーザーへのデータベース・ロールの付与

チュートリアル: コード・ベース・アクセス制御による機密データへのアクセス制御

このチュートリアルでは、コード・ベース・アクセス制御を使用して、HRスキーマの機密データへのアクセスを制御する方法を示します。

内容は次のとおりです。

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

- ステップ1: ユーザーを作成してHRにCREATE ROLE権限を付与

- ステップ2: print_employees実行者権限プロシージャを作成

- ステップ3: hr_clerkロールを作成して権限を付与

- ステップ4: コード・ベース・アクセス制御HR.print_employeesプロシージャのテスト

- ステップ5: view_emp_roleロールを作成して権限を付与

- ステップ6: HR.print_employeesプロシージャの再テスト

- 手順7: このチュートリアルのコンポーネントの削除

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

このチュートリアルでは、自分の部門のために特定の従業員情報に対するアクセス権が必要なユーザーを作成します。

ただし、HR.EMPLOYEES表には従業員給与などの機密情報が含まれており、ユーザーにはアクセスできないようにする必要があります。アクセス制御は、コード・ベース・アクセス制御を使用して実装します。従業員データは、実行者権限プロシージャを通じてユーザーに表示されます。SELECT権限をユーザーに直接付与するかわりに、データベース・ロールを通じてSELECT権限を実行者権限プロシージャに付与します。このプロシージャでは、給与のような機密情報を非表示にします。このプロシージャは実行者権限プロシージャであるため、プロシージャ内で呼出し元のコンテキストがわかります。この場合、呼出し元のコンテキストは財務部門です。ユーザーの名前は"Finance"であるため、ユーザーは財務部門に勤務する従業員のデータのみにアクセス可能です。

ステップ1: ユーザーを作成してHRにCREATE ROLE権限を付与

開始するには、"Finance"ユーザー・アカウントを作成し、このHRユーザーにCREATE ROLE権限を付与する必要があります。

1. ユーザー・アカウントおよびロールを作成する権限を持つ管理者としてデータベース・インスタンスにログインします。

例:

sqlplus sec_admin
Enter password: password

2. "Finance"ユーザー・アカウントを作成します。

GRANT CONNECT TO "Finance" IDENTIFIED BY password;

"Finance"が、大文字と小文字はこのまま、二重引用符で囲んで入力されていることを確認します。passwordを安全なパスワードに置き換えます。詳細は、パスワードの最低要件を参照してください。

3. CREATE ROLE権限をユーザーHRに付与します。

GRANT CREATE ROLE TO HR;

ステップ2: print_employees実行者権限プロシージャを作成

print_employees実行者権限プロシージャは、現在のユーザーの部門内の従業員情報を表示します。

プロシージャ内で呼出し元がだれであるかを知る必要があるため、このプロシージャを実行者権限プロシージャとして作成する必要があります。

1. ユーザーHRとして接続します。

CONNECT HR
Enter password: password

2. 次のようにprint_employeesプロシージャを作成します。

create or replace procedure print_employees
authid current_user
as
begin
dbms_output.put_line(rpad('ID', 10) ||
rpad('First Name', 15)  ||
rpad('Last Name', 15)   ||
rpad('Email', 15)       ||
rpad('Phone Number', 20));
for rec in (select e.employee_id, e.first_name, e.last_name,
e.email, e.phone_number
from hr.employees e, hr.departments d
where e.department_id = d.department_id
and d.department_name =
sys_context('userenv', 'current_user'))
loop
dbms_output.put_line(rpad(rec.employee_ID, 10)  ||
rpad(rec.first_name, 15)   ||
rpad(rec.last_name, 15)    ||
rpad(rec.email, 15)        ||
rpad(rec.phone_number, 20));
end loop;
end;
/

この例の説明は、次のとおりです。

- dbms_output.put_lineは、表ヘッダーを印刷します。

- for rec in (select ...は、呼出し元の部門の従業員情報を検索します。このチュートリアルでは、ユーザー"Finance"の財務部門となります。"Marketing"(これもHR.EMPLOYEES表のDEPARTMENT_NAME列にリストされています)という名前のユーザーを作成していた場合には、プロシージャはマーケティング部門従業員の情報を取得できました。

- loopおよびdbms_output.put_lineは、出力に財務部門の従業員データを移入します。

ステップ3: hr_clerkロールを作成して権限を付与

次に、hr_clerkロールを作成し、print_employeesプロシージャに対するEXECUTE権限を付与する必要があります。

このロールを作成したら、これを"Finance"に付与する必要があります。

1. hr_clerkロールを作成します。

CREATE ROLE hr_clerk;

2. print_employeesプロシージャのEXECUTE権限をhr_clerkロールに付与します。

GRANT EXECUTE ON print_employees TO hr_clerk;

3. hr_clerkロールを"Finance"に付与します。

GRANT hr_clerk TO "Finance";

ステップ4: コード・ベース・アクセス制御HR.print_employeesプロシージャのテスト

コード・ベース・アクセス制御HR.print_employeesプロシージャをテストする準備が整いました。

コード・ベース・アクセス制御のHR.print_employeesプロシージャをテストするには、ユーザー"Finance"がHR.EMPLOYEES表を問い合せて、HR.print_employeesプロシージャの実行を試みる必要があります。

1. データベース・インスタンスにユーザー"Finance"として接続します。

CONNECT "Finance"
Enter password: password

2. HR.EMPLOYEES表の直接問合せを試行します。

SELECT EMPLOYEE_ID, FIRST_NAME, LAST_NAME, SALARY FROM HR.EMPLOYEES;

ユーザーFinanceにはHR.EMPLOYEESへのSELECT権限がないため、問合せは失敗します。

ERROR at line 1:
ORA-00942: table or view does not exist

3. HR.print_employeesプロシージャを実行します。

EXEC HR.print_employees;

ユーザー"Finance"が適切な権限を持っていないため、問合せは失敗します。

ERROR at line 1:
ORA-00942: table or view does not exist
ORA-06512: at "HR.PRINT_EMPLOYEES", line 13ORA-06512: at line 1

ステップ5: view_emp_roleロールを作成して権限を付与

ここでは、ユーザーHRでview_emp_roleロールを作成し、このロールに権限を付与する必要があります。

ユーザーHRがSELECT権限HR.EMPLOYEESとHR.DEPARTMENTSをview_emp_roleロールに付与し、HR.EMPLOYEESとHR.DEPARTMENTSのSELECTをview_emp_roleロールに付与します。

1. ユーザーHRとして接続します。

CONNECT HR
Enter password: password

2. view_emp_roleロールを作成します。

CREATE ROLE view_emp_role;

3. view_emp_roleロールにHR.EMPLOYEESとHR.DEPARTMENTSのSELECT権限を付与します。

GRANT SELECT ON HR.EMPLOYEES TO view_emp_role;
GRANT SELECT ON HR.DEPARTMENTS TO view_emp_role;

4. view_emp_roleロールをHR.print_employees実行者権限プロシージャに付与します。

GRANT view_emp_role TO PROCEDURE HR.print_employees;

ステップ6: HR.print_employeesプロシージャの再テスト

適切な権限がある場合、ユーザー"Finance"は、HR.print_employeesプロシージャを再試行できます。

1. ユーザー"Finance"として接続します。

CONNECT "Finance"
Enter password: password

2. サーバー出力をディスプレイに設定します。

SET SERVEROUTPUT ON;

3. HR.EMPLOYEES表の直接問合せを試行します。

SELECT EMPLOYEE_ID, FIRST_NAME, LAST_NAME, SALARY FROM HR.EMPLOYEES;

問合せが失敗します。

ERROR at line 1:
ORA-00942: table or view does not exist

4. HR.print_employeesプロシージャを実行して、従業員情報を表示します。

EXEC HR.print_employees;

呼出しが成功します。

ID        First Name     Last Name      Email          Phone Number
108       Nancy          Greenberg      NGREENBE       515.124.4569
109       Daniel         Faviet         DFAVIET        515.124.4169
110       John           Chen           JCHEN          515.124.4269
111       Ismael         Sciarra        ISCIARRA       515.124.4369
112       Jose Manuel    Urman          JMURMAN        515.124.4469
113       Luis           Popp           LPOPP          515.124.4567

PL/SQL procedure successfully completed.

手順7: このチュートリアルのコンポーネントの削除

このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。

1. 管理者権限を持つユーザーとして接続します。

例:

CONNECT sec_admin
Enter password: password

2. ユーザー"Finance"を削除します。

DROP USER "Finance";

3. hr_clerkロールを削除します。

DROP ROLE hr_clerk;

4. ユーザーHRとして接続します。

CONNECT HR
Enter password: password

5. view_emp_roleロールとHR.print_employeesプロシージャを削除します。

DROP ROLE view_emp_role;
DROP PROCEDURE print_employees;

6. 管理者権限ユーザーとして接続します。

CONNECT sec_admin
Enter password: password

7. HRからCREATE ROLE権限を取り消します。

REVOKE CREATE ROLE FROM HR;

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

Oracle Databaseには、一連のPL/SQLパッケージとタイプが用意されています。このパッケージとタイプによって、ユーザーが外部ネットワーク・サービスやウォレットに対して保持するアクセスを制御するファイングレイン・アクセスを使用できます。

内容は次のとおりです。

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

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

- Oracleウォレットへのアクセス制御について

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

- 外部ネットワーク・サービスのアクセス制御の構成

- Oracleウォレットへのアクセス制御の構成

- 外部ネットワーク・サービスのアクセス制御の構成の例

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

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

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

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

- Javaデバッグ・ワイヤ・プロトコル操作のネットワーク・アクセスの構成

- ユーザー・アクセス用に構成されたアクセス制御リストのデータ・ディクショナリ・ビュー

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

PL/SQLパッケージのセットと1つの型を使用して、外部ネットワーク・サービスおよびウォレットに対するユーザー・アクセスを構成できます。

パッケージはUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDR、DBMS_LDAPのPL/SQLパッケージ、型はHttpUriTypeです。

次の使用方法が可能です。

- データベースから外部ネットワーク・サービスへのアクセスが必要なユーザーやロールに、ファイングレイン・アクセス・コントロールを構成します。これによって、特定のユーザー・グループは、付与されている権限に基づいて1つ以上のホスト・コンピュータに接続できます。通常、この機能は、特定のホスト・アドレスで実行されるアプリケーションへのアクセスを制御するために使用します。

- パスワードまたはクライアント証明書認証を必要とするHTTPリクエストを処理するために、Oracleウォレットにファイングレイン・アクセス・コントロールを構成します。この機能により、Oracleウォレットに格納されているパスワードとクライアント証明書を使用するユーザーに、保護されている外部HTTPリソースにUTL_HTTPパッケージを介してアクセスする権限を付与できます。たとえば、アプリケーションで資格証明をハードコードするかわりに、ウォレットに格納されている資格証明を使用するようにアプリケーションを構成できます。

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

Oracle Application Securityアクセス制御リスト(ACL)で、外部ネットワーク・サービスに対するファイングレイン・アクセス・コントロールを実装できます。

このマニュアルでは、DBMS_NETWORK_ACL_ADMIN PL/SQLパッケージを使用してデータベース・ユーザーおよびロールのアクセス制御を構成する方法について説明します。

この機能を使用することで、データベース・ユーザーがPL/SQLネットワーク・ユーティリティ・パッケージUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDR、PL/SQLパッケージDBMS_LDAPとDBMS_DEBUG_JDWPおよび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管理者ガイド』を参照してください。

関連項目:

電子メール・アラート用に外部ネットワーク・サービスへのアクセス制御を構成する例は、例: ファイングレイン監査ポリシーへの電子メール・アラートの追加を参照してください

Oracleウォレットへのアクセス制御について

リモートWebサーバーによって保護されているWebページにアクセスするときに、ユーザーはOracleウォレットに格納されているクライアント資格証明とパスワードを使用して認証を受けることができます。

Oracleウォレットでは、ユーザーのパスワードとクライアント証明書を安全に格納できます。

ウォレットに対するアクセス制御を構成するには、次のコンポーネントが必要です。

- Oracleウォレット。Oracleウォレットは、Oracle DatabaseのmkstoreユーティリティまたはOracle Wallet Managerを使用して作成できます。HTTPリクエストでは、外部パスワード・ストアまたはウォレット内のクライアント証明書を使用してユーザーが認証されます。

- ユーザーにウォレットの使用権限を付与するアクセス制御リスト。アクセス制御リストを構成するには、DBMS_NETWORK_ACL_ADMIN PL/SQLパッケージを使用します。

Oracleウォレットを使用すると、保護されているWebページへのアクセスに必要なパスワードとクライアント証明書を安全に格納できます。

関連項目:

Oracleウォレットへのアクセス制御の構成

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

アップグレードされたアプリケーションでORA-24247ネットワーク・アクセス・エラーが発生することがあります。

Oracle Database 11gリリース1 (11.1)より前のリリースからアップグレードしているときに、アプリケーションがPL/SQLネットワーク・ユーティリティ・パッケージ(UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDRおよびDBMS_LDAP)またはHttpUriType型に依存している場合は、そのアプリケーションの実行を試みたときに、ORA-24247エラーが発生する可能性があります。

エラー・メッセージは次のとおりです。

ORA-24247: network access denied by access control list (ACL)

その場合は、この章に記載されている手順を使用してアプリケーションのネットワーク・アクセスを再構成してください。

関連項目:

PL/SQLネットワーク・ユーティリティ・パッケージに依存しているアプリケーションの互換性に関する問題については、『Oracle Databaseアップグレード・ガイド』を参照してください。

外部ネットワーク・サービスのアクセス制御の構成

DBMS_NETWORK_ACLパッケージは、外部ネットワーク・サービスのアクセス制御を構成します。

内容は次のとおりです。

- 外部ネットワーク・サービスのアクセス制御の構成の構文

- 例: 外部ネットワーク・サービスのアクセス制御の構成

- 外部ネットワーク・サービスのアクセス制御権限の取消し

- 例: 外部ネットワーク・サービス権限の取消し

外部ネットワーク・サービスのアクセス制御の構成の構文

DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACEプロシージャを使用して、アクセス制御権限をユーザーに付与できます。

このプロシージャは、指定された権限を持つアクセス制御エントリ(ACE)を指定されたホストのACLに追加し、存在しない場合はACLを作成します。結果の構成は、作成したユーザーのスキーマでなくSYSスキーマにあります。

構文は次のようになります。

BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE (
host         => 'host_name',
lower_port   => null|port_number,
upper_port   => null|port_number,
ace          => ace_definition);
END;

次のように値を指定します。

- host: ホストの名前を入力します。ホスト名またはホストのIPアドレスのいずれかです。ワイルドカードを使用して、ドメインまたはIPサブネットを指定できます。(ドメイン名でワイルドカードを使用する場合の優先順位は、複数のアクセス制御リスト割当てでのホスト・コンピュータの優先順位を参照してください。)ホストまたはドメイン名は大/小文字が区別されません。次に例を示します。

host     => 'www.example.com',

host     => '*example.com',

- 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権限は機能しません。

- ace: 次の形式のXS$ACE_TYPE定数を使用して、ACEを定義します。

ace    => xs$ace_type(privilege_list => xs$name_list('privilege'),
principal_name => 'user_or_role',
principal_type => xs$ace_type_user));

次のように値を指定します。

- privilege_list: 大/小文字を区別しない1つ以上の次の権限を入力します。一重引用符で各権限を囲み、カンマ('http', 'http_proxy'など)で区切ります。
アクセス制御を強化するために、ユーザーがUTL_HTTP、HttpUriType、UTL_SMTPまたはUTL_MAILのみを使用する場合、connect権限のかわりにhttp、http_proxyまたはsmtp権限のみ付与します。

- http: UTL_HTTPパッケージおよびHttpUriType型を通じてホストへのHTTPリクエストを作成します

- http_proxy: UTL_HTTPパッケージおよびHttpUriType型を通じてプロキシを介したHTTPリクエストを作成します。ユーザーがプロキシを介してHTTPリクエストを作成する場合、http権限と組み合せてhttp_proxyを含む必要があります。

- smtp: UTL_SMTPおよびUTL_MAILパッケージを通じて、SMTPをホストに送信します

- resolve: UTL_INADDRパッケージを通じて、ネットワーク・ホスト名またはIPアドレスを解決します

- connect: UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTPおよびDBMS_LDAPパッケージまたはHttpUriType型を通じて、ホストのネットワーク・サービスに接続するユーザー権限を付与します

- jdwp: JavaまたはPL/SQLストアド・プロシージャのJavaデバッグ・ワイヤ・プロトコル・デバッグ操作に使用されます。詳細は、Javaデバッグ・ワイヤ・プロトコル操作のネットワーク・アクセスの構成を参照してください。

- principal_name: データベース・ユーザー名またはロールを入力します。二重引用符(たとえば、'"ACCT_MGR'"など)で入力しないかぎり、この値は大/小文字を区別しません。

- principal_type: データベース・ユーザーまたはロールのXS_ACL.PTYPE_DBを入力します。principal_type値のデフォルトがOracle Database Real Application Securityアプリケーション・ユーザーの指定に使用されるPTYPE_XSであるため、PTYPE_DBを指定する必要があります。

関連項目:
aceパラメータ設定に含むことができる追加のXS$ACE_TYPEパラメータgranted、inverted、start_dateおよびend_dateの詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

例: 外部ネットワーク・サービスのアクセス制御の構成

DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACEプロシージャで、外部ネットワーク・サービスのアクセス制御を構成できます。

例6-1は、ホストwww.example.comに作成されるACLのacct_mgrデータベース・ロールへのhttpおよびsmtp権限の付与方法を示しています。

例6-1 データベース・ロールの外部ネットワーク・サービスへの権限の付与

BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host       => 'www.example.com',
ace        =>  xs$ace_type(privilege_list => xs$name_list('http', 'smtp'),
principal_name => 'acct_mgr',
principal_type => xs_acl.ptype_db));
END;
/

外部ネットワーク・サービスのアクセス制御権限の取消し

外部ネットワーク・サービスのアクセス制御権限を削除できます。

- 外部ネットワーク・サービスのアクセス制御権限を取り消すには、DBMS_NETWORK_ACL_ADMIN.REMOVE_HOST_ACEプロシージャを実行します。

関連項目:

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

例: 外部ネットワーク・サービス権限の取消し

DBMS_NETWORK_ACL_ADMIN.REMOVE_HOST_ACEプロシージャを使用して、外部ネットワーク・サービス権限を取り消すことができます。

例6-2は、外部ネットワーク権限の取消し方法を示しています。

例6-2 外部ネットワーク・サービス権限の取消し

BEGIN
DBMS_NETWORK_ACL_ADMIN.REMOVE_HOST_ACE (
host       => 'www.example.com',
lower_port => 80,
upper_port => upper_port => 3999,
ace        => xs$ace_type(privilege_list => xs$name_list('http', 'smtp'),
principal_name => 'acct_mgr',
principal_type => xs_acl.ptype_db),
remove_empty_acl => TRUE);
END;
/

ここで、remove_empty_aclのTRUE設定は、ACEの削除時に空になる場合にACLを削除します。

Oracleウォレットへのアクセス制御の構成

パスワードや証明書を必要とするネットワーク・サービスにユーザーがアクセスできるように、Oracleウォレットにファイングレイン・アクセス制御を使用できます。

内容は次のとおりです。

- Oracleウォレットへのアクセス制御の構成について

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

- 手順2: Oracleウォレットのアクセス制御権限の構成

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

- Oracleウォレットのアクセス制御権限の取消し

Oracleウォレットへのアクセス制御の構成について

アクセス制御を構成して、パスワードおよびクライアント証明書にアクセス権を付与できます。

これらのパスワードとクライアント証明書はOracleウォレットに格納されます。アクセス制御を構成すると、PL/SQLネットワーク・ユーティリティ・パッケージを使用するときに外部ネットワーク・サービスに対してユーザーが自身を証明できるようになります。

これにより、ユーザーは、パスワードまたは証明書IDが必要なネットワーク・サービスへのアクセスを取得できます。

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

Oracleウォレットでは標準およびPKCS11の両タイプのウォレットを使用できるほか、自動ログイン・ウォレットにすることもできます。

1. ウォレットを作成するには、mkstoreコマンドライン・ユーティリティまたはOracle Wallet Managerユーザー・インタフェースを使用します。
ウォレットにパスワードを格納するには、mkstoreユーティリティを使用する必要があります。

2. ウォレットがファイルにエクスポートされていることを確認します。

3. ウォレットを作成したディレクトリを書き留めておきます。このディレクトリ・パスは、このセクションの手順の終了後に必要になります。

関連項目:

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

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

手順2: Oracleウォレットのアクセス制御権限の構成

ウォレットを作成した後、ウォレットのアクセス制御権限を構成できます。

- DBMS_NETWORK_ACL_ADMIN.APPEND_WALLET_ACEプロシージャを使用して、ウォレット・アクセス制御権限を構成します。

DBMS_NETWORK_ACL_ADMIN.APPEND_WALLET_ACEプロシージャの構文は次のとおりです。

BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_WALLET_ACE (
wallet_path => 'directory_path_to_wallet',
ace         => xs$ace_type(privilege_list => xs$name_list('privilege'),
principal_name => 'user_or_role',
principal_type => xs$ace_type_user));
END;

次のように値を指定します。

- wallet_path: 手順1: Oracleウォレットの作成で作成したウォレットを含むディレクトリへのパスを入力します。ウォレットのパスを指定する際は、絶対パスを使用し、ディレクトリ・パスの前にfile:を入れる必要があります。$ORACLE_HOMEなどの環境変数を使用したり、file:の後およびパス名の前にスペースを挿入することはできません。例:

wallet_path   => 'file:/oracle/wallets/hr_wallet',

- ace: XS$ACE_TYPE定数を使用して、ACLを定義します。例:

ace         =>  xs$ace_type(privilege_list => xs$name_list(privilege),
principal_name => 'hr_clerk',
principal_type => xs_acl.ptype_db);

ここでは、xs$ace_typeを使用してウォレット権限を入力する場合、privilegeが次のいずれかである必要があります(これらの権限名のアンダースコアの使用に注意してください)。

- use_client_certificates

- use_passwords

これらのパラメータの詳細は、外部ネットワーク・サービスのアクセス制御の構成の構文のaceパラメータの説明を参照してください。ウォレットには、use_client_certificatesまたはuse_passwords権限を指定する必要があります。

関連項目:

aceパラメータ設定に含むことができる追加のXS$ACE_TYPEパラメータgranted、inverted、start_dateおよびend_dateの詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

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

UTL_HTTPパッケージを使用してリクエスト・オブジェクトを作成でき、このオブジェクトを使用してウォレット情報を保持できます。クライアント証明書またはパスワードを使用して認証できます。

内容は次のとおりです。

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

- 他のアプリケーションとセッションを共有している場合に、リクエスト・コンテキストを使用してウォレットを保留

- 認証にクライアント証明書のみを使用

- 認証にパスワードを使用

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

UTL_HTTPパッケージは、SQLとPL/SQLからHypertext Transfer Protocol (HTTP)のコールアウトを行います。

- UTL_HTTP PL/SQLパッケージを使用して、HTTPリクエストとそのレスポンスで個別に使用されるリクエスト・コンテキスト・オブジェクトを作成します。

例:

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: ウォレットが格納されているディレクトリのパスを入力します。このパスは、前のセクションの手順2: Oracleウォレットのアクセス制御権限の構成でアクセス制御リストを作成したときに指定したパスと同じであることを確認してください。ディレクトリ・パスの前にfile:を含める必要があります。$ORACLE_HOMEなどの環境変数を使用しないでください。
例:

wallet_path          => 'file:/oracle/wallets/hr_wallet',

- wallet_password: ウォレットを開くためのパスワードを入力します。デフォルトはNULLで、自動ログイン・ウォレットに使用します。例:

wallet_password      => 'wallet_password');

- url: ウォレットを使用するアプリケーションのURLを入力します。
例:

url                  => 'www.hr_access.example.com',

- request_context: このセクションの前の方で作成したリクエスト・コンテキスト・オブジェクトの名前を入力します。このオブジェクトにより、ウォレットは同一データベース・セッション内の他のアプリケーションとは共有されなくなります。
例:

request_context      => req_context);

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

他のアプリケーションとセッションを共有している場合に、リクエスト・コンテキストを使用してウォレットを保留

他のアプリケーションとデータベース・セッションを共有している場合は、リクエスト・コンテキストを使用してウォレットを保留にする必要があります。

アプリケーションがデータベース・セッションを排他的に使用している場合は、UTL_HTTP.SET_WALLETプロシージャを使用してデータベース・セッションでウォレットを保留できます。

- UTL_HTTP.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プロシージャを使用してウォレットからユーザー名とパスワードを設定して認証します。

認証にクライアント証明書のみを使用

ユーザーに対してACLウォレットで適切な権限が付与されているかぎり、ユーザーの認証にクライアント証明書のみを使用できます。

要求された保護されているURLが、認証にクライアント証明書のみを必要とする場合、BEGIN_REQUESTファンクションはウォレットに割り当てられているACLでユーザーにuse_client_certificates権限が付与されているものとみなして、ウォレットから必要なクライアント証明書を送信します。

認証はリモートWebサーバーで成功し、ユーザーはGET_RESPONSEファンクションを使用してHTTP応答を取得できます。

認証にパスワードを使用

要求したURLが保護されていてユーザー名とパスワードの認証を要求される場合は、ウォレットからユーザー名とパスワードを設定して認証します。

例:

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権限が付与されている必要があります。

Oracleウォレットのアクセス制御権限の取消し

Oracleウォレットのアクセス制御権限を取り消すことができます。

- ウォレットのアクセス制御リスト(ACL)のアクセス制御エントリ(ACE)から権限を取り消すには、DBMS_NETWORK_ACL_ADMIN.REMOVE_WALLET_ACEプロシージャを実行します。

例:

BEGIN
DBMS_NETWORK_ACL_ADMIN.REMOVE_WALLET_ACE (
wallet_path   => 'file:/oracle/wallets/hr_wallet',
ace           =>  xs$ace_type(privilege_list => xs$name_list(privilege),
principal_name => 'hr_clerk',
principal_type => xs_acl.ptype_db),
remove_empty_acl  => TRUE);
END;
/

この例では、remove_empty_aclのTRUE設定により、ウォレットACEの削除時に空になる場合にACLが削除されます。

外部ネットワーク・サービスのアクセス制御の構成の例

様々な状況に合せてアクセス制御を構成できます。たとえば、1つのロールとネットワーク接続、ユーザーとロールの権限、非共有ウォレットのパスワード、共有データベース・セッションのウォレットなどの場合です。

内容は次のとおりです。

- 例: 1つのロールおよびネットワーク接続のアクセス制御の構成

- 例: ユーザーおよびロールのアクセス制御の構成

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

- 例: DBA_HOST_ACESビューを使用した付与権限の表示

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

例: 1つのロールおよびネットワーク接続のアクセス制御の構成

DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACEプロシージャで、1つのロールおよびネットワーク接続のアクセス制御を構成できます。

例6-3は、1つのロール(acct_mgr)のアクセス制御を構成し、このロールにwww.us.example.comホストにアクセスするhttp権限を付与する方法を示しています。権限は、2013年1月1日に期限切れになります。

例6-3 1つのロールおよびネットワーク接続のアクセス制御の構成

BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host       => 'www.us.example.com',
lower_port => 80,
ace        =>  xs$ace_type(privilege_list => xs$name_list('http'),
principal_name => 'acct_mgr',
principal_type => xs_acl.ptype_db,
end_date => TIMESTAMP '2013-01-01 00:00:00.00 -08:00');
END;
/

例: ユーザーおよびロールのアクセス制御の構成

DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACEで、1つのユーザーおよびロールの権限を拒否または付与するアクセス制御を構成できます。

その後、DBA_HOST_ACESデータ・ビュー・ディクショナリを問い合せて、権限付与に関する情報を確認できます。

例6-4では、データベース・ロール(acct_mgr)に付与しますが、ロールを持つ場合でも特定のユーザー(psmith)を拒否します。ACEが指定された順序で評価されるため、順序は重要です。この場合、拒否ACE(granted => false)を最初に追加する必要があり、追加しないとユーザーを拒否できません。

例6-4 ユーザーおよびロールの付与および拒否を使用したアクセス制御の構成

BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host       => 'www.us.example.com',
lower_port => 80,
upper_port => 80,
ace        =>  xs$ace_type(privilege_list => xs$name_list('http'),
principal_name => 'psmith',
principal_type => xs_acl.ptype_db,
granted        => false));

DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host       => 'www.us.example.com',
lower_port => 80,
upper_port => 80,
ace        =>  xs$ace_type(privilege_list => xs$name_list('http'),
principal_name => 'acct_mgr',
principal_type => xs_acl.ptype_db,
granted        => true));
END;

例: DBA_HOST_ACESビューを使用した付与権限の表示

DBA_HOST_ACEデータ・ディクショナリ・ビューにはユーザーに付与されている権限が表示されます。

例6-5は、前述のアクセス制御リストで付与された権限をDBA_HOST_ACESデータ・ディクショナリ・ビューに表示する方法を示しています。

例6-5 DBA_HOST_ACESビューを使用した付与権限の表示

SELECT PRINCIPAL, PRIVILEGE, GRANT_TYPE FROM DBA_HOST_ACE WHERE PRIVILEGE = 'HTTP';

PRINCIPAL    PRIVILEGE  GRANT_TYPE
------------ ---------- --------------------
PSMITH       HTTP       FALSE
ACCT_MGR     HTTP       TRUE

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

DBMS_NETWORK_ACL_ADMINおよびUTL_HTTP PL/SQLパッケージで、非共有ウォレットのパスワードを使用してACLアクセスを構成できます。

例6-6では、人事部門の2つのロール、hr_clerkとhr_managerによるウォレットへのアクセスを構成しています。これらのロールは、use_passwords権限を使用して、ウォレットに格納されているパスワードにアクセスします。この例では、ウォレットは同一データベース・セッション内の他のアプリケーションとは共有されません。

例6-6 非共有ウォレットのパスワードを使用する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_wallet -create
Enter password: password
Enter password again: password
$ mkstore -wrl $ORACLE_HOME/wallets/hr_wallet -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 role.*/
BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_WALLET_ACE (
wallet_path => 'file:/oracle/wallets/hr_wallet',
ace         => xs$ace_type(privilege_list => xs$name_list('use_passwords'),
principal_name => 'hr_clerk',
principal_type => xs_acl.ptype_db));
END;
/

/* 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_wallet',
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;
/

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

DBMS_NETWORK_ACL_ADMINおよびUTL_HTTP PL/SQLパッケージで、共有データベース・セッションに使用するウォレットのACLアクセスを構成できます。

例6-7は、ウォレットを共有データベース・セッションに使用するように構成し、現在のデータベース・セッション内のすべてのアプリケーションがこのウォレットへのアクセス権を持ちます。

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

/* Follow these steps:
1. Use Oracle Wallet Manager to create the wallet and add the client
certificate.

2. In SQL*Plus, configure access control to grant privileges for the wallet.
The following example grants the use_client_certificates privilege
to the hr_clerk and hr_mgr roles. */
BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_WALLET_ACE (
wallet_path => 'file:/oracle/wallets/hr_wallet',
ace         => xs$ace_type(privilege_list => xs$name_list('use-client_certificates'),
principal_name => 'hr_clerk',
principal_type => xs_acl.ptype_db));

DBMS_NETWORK_ACL_ADMIN.APPEND_WALLET_ACE (
wallet_path => 'file:/oracle/wallets/hr_wallet',
ace         => xs$ace_type(privilege_list => xs$name_list('use_client_certificates'),
principal_name => 'hr_mgr',
principal_type => xs_acl.ptype_db));
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/wallets/hr_wallet',
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が割り当てられているアクセス制御リストが最初に選択されます。

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

管理者とユーザーは、どちらもネットワーク接続およびドメイン権限をチェックできます。

内容は次のとおりです。

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

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

- 例: 管理者によるユーザー・ネットワーク・アクセス制御権限のチェック

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

- 例: ユーザーによるネットワーク・アクセス制御権限のチェック

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

OracleにはDBA向けのデータ・ディクショナリ・ビューが用意されており、権限の割当てに関する情報を確認できます。

データベース管理者は、DBA_HOST_ACESデータ・ディクショナリ・ビューを使用して、アクセス制御リストでデータベース・ユーザーまたはロールに対して付与または拒否したネットワーク権限を問い合せ、それらの権限が特定の期間のみ有効かどうかを問い合せることができます

現時点でユーザーに権限が付与されているかどうか、ユーザーに割り当てられているロール、アクセス制御エントリの順序などを判断するために、ビューで提供される情報を使用したデータの組合せが必要になる場合があります。

データベース管理者権限のないユーザーには、アクセス制御リストにアクセスしたり、DBMS_NETWORK_ACL_ADMINの各ファンクションを起動する権限はありません。ただし、データベース管理者権限のないユーザーは、USER_HOST_ACESデータ・ディクショナリ・ビューを問い合せて各自の権限をチェックすることはできます。

データベース管理者とユーザーは、次のDBMS_NETWORK_ACL_UTILITYファンクションを使用して、2つのホスト、ドメインまたはサブネットが同じかどうか、あるいはホスト、ドメインまたはサブネットが他のホスト、ドメインまたはサブネットと同じ、または他のホスト、ドメインまたはサブネットに含まれるかどうか、を判断します。

- EQUALS_HOST: 2つのホスト、ドメインまたはサブネットが同じかどうかを示す値を戻します。

- CONTAINS_HOST: ホスト、ドメインまたはサブネットが他のホスト、ドメインまたはサブネットと同じかどうか、または他のホスト、ドメインまたはサブネットに含まれるかどうかを示す値を示します。また、ACL割当てのために、含まれているドメインまたはサブネットの相対的な優先順位も示します。

IPv6アドレスを使用しない場合、データベース管理者およびユーザーは、次のDBMS_NETWORK_ACL_UTILITYファンクションを使用して、ホストが所属しているドメインまたはIPv4サブネットのリストを生成し、ホストの割当てに従って優先順位別にアクセス制御リストをソートできます。

- DOMAINS: アクセス制御リストが、指定のネットワーク・ホスト、サブドメインまたはIPサブネットに対する権限に影響を与える可能性があるドメインまたはIPサブネットのリストを戻します。

- DOMAIN_LEVEL: 指定のホストのドメイン・レベルを戻します。

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

データベース管理者は、DBA_HOST_ACESデータ・ディクショナリ・ビューを問い合せて、特定のユーザーまたはロールに付与された権限を確認できます。

DBA_HOST_ACESビューには、ネットワーク接続またはドメインへのアクセスを決定するアクセス制御リストが表示され、各アクセス制御リストについて、ユーザーのアクセス権限が付与されている(GRANTED)か、拒否されている(DENIED)か、あるいは適用外(NULL)かを確認できます。このビューの問合せを実行できるのは、データベース管理者のみです。

例: 管理者によるユーザー・ネットワーク・アクセス制御権限のチェック

DBA_HOST_ACESデータ・ディクショナリ・ビューでは、ユーザーのネットワーク・アクセス制御権限をチェックできます。

例6-8は、ユーザーprestonによるwww.us.example.comへの接続について、データベース管理者がユーザーの権限をチェックする方法を示しています。

この例では、ユーザーprestonにはwww.us.example.comで見つかったすべてのネットワーク・ホスト接続の権限が付与されました。ところが、prestonはポート80でのホスト接続へのアクセス権を付与されたが、ポート3000-3999でのホスト接続へのアクセス権を拒否されたと仮定します。この場合は、ポート80でのホスト接続のためにアクセス制御を構成し、ポート3000-3999でのホスト接続のために別個のアクセス制御構成を行う必要があります。

例6-8 管理者によるユーザー・ネットワーク・アクセス制御権限のチェック

SELECT HOST, LOWER_PORT, UPPER_PORT,
ACE_ORDER, PRINCIPAL, PRINCIPAL_TYPE,
GRANT_TYPE, INVERTED_PRINCIPAL, PRIVILEGE,
START_DATE, END_DATE
FROM (SELECT ACES.*,
DBMS_NETWORK_ACL_UTILITY.CONTAINS_HOST('www.us.example.com', HOST) PRECEDENCE
FROM DBA_HOST_ACES ACES)
WHERE PRECEDENCE IS NOT NULL
ORDER BY PRECEDENCE DESC,
LOWER_PORT NULLS LAST,
UPPER_PORT NULLS LAST,
ACE_ORDER;
HOST               LOWER_PORT UPPER_PORT ACE_ORDER PRINCIPAL PRINCIPAL_TYPE   GRANT_TYPE INVERTED_PRINCIPAL PRIVILEGE START_DATE END_DATE
------------------ ---------- ---------- --------- --------- ---------------- ---------- ------------------ --------- ---------- --------
www.us.example.com         80        80          1 PRESTON DATABASE USER      GRANT      NO                 HTTP
www.us.example.com         80        80          2 SEBASTIAN DATABASE USER    GRANT      NO                 HTTP
*.us.example.com                                 1 ACCT_MGR DATABASE USER     GRANT      NO                 CONNECT
*                                                1 HR_DBA DATABASE USER       GRANT      NO                 CONNECT
*                                                1 HR_DBA DATABASE USER       GRANT      NO                 RESOLVE

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

ユーザーはUSER_HOST_ACESデータ・ディクショナリ・ビューを問い合せて、自分のネットワークおよびドメインの権限を調べることができます。

USER_HOST_ACESビューはPUBLICであるため、すべてのユーザーが問い合せることができます。

このビューでは、アクセス制御リストはユーザーに表示されません。このビューでユーザーの権限ステータスが判定され(GRANTEDまたはDENIED)、NULLの場合、ユーザーはアクセス制御リストが自分に適用されないときは知る必要がないため、除外されます。言い換えるとOracle Databaseが提示するのは、Oracle Databaseによってアクセス権が明示的に付与または拒否されるネットワーク・ホスト上のユーザーのみです。そのため出力には、データベース管理者固有のDBA_HOST_ACESビューからの出力に見られる*.example.comおよび*は表示されません。

例: ユーザーによるネットワーク・アクセス制御権限のチェック

USER_HOST_ACESデータ・ディクショナリ・ビューには、ホスト・コンピュータのネットワーク・アクセス制御権限が表示されます。

例6-9は、ユーザーprestonが、www.us.example.comへの接続について、自分の権限をチェックする方法を示しています。

例6-9 ユーザーによるネットワーク・アクセス制御権限のチェック

SELECT HOST, LOWER_PORT, UPPER_PORT, PRIVILEGE, STATUS
FROM (SELECT ACES.*,
DBMS_NETWORK_ACL_UTILITY.CONTAINS_HOST('www.us.example.com', HOST) PRECEDENCE
FROM USER_HOST_ACES ACES)
WHERE PRECEDENCE IS NOT NULL
ORDER BY PRECEDENCE DESC,
LOWER_PORT NULLS LAST,
UPPER_PORT NULLS LAST;

HOST               LOWER_PORT UPPER_PORT PRIVILEGE STATUS
------------------ ---------- ---------- --------- -------
www.us.example.com         80        80  HTTP      GRANTED

Javaデバッグ・ワイヤ・プロトコル操作のネットワーク・アクセスの構成

Java PL/SQLプロシージャをデバッグするには、jdwp ACL権限を付与されていることが必要です。

SQL Developer、JDeveloperまたはOracle Developer Tools For Visual Studio (ODT)などのJavaデバッグ・ワイヤ・プロトコル(JDWP)ベースのデバッガを通じて、データベースのJavaおよびPL/SQLプロシージャをデバッグする場合、jdwp ACL権限を付与して、特定のホストのデバッガにデータベース・セッションを接続する必要があります。

DEBUG CONNECT SESSIONシステム権限と組み合せたjdwp権限が必要です。

jdwp ACL権限が付与されていない場合、リモート・ホストからJavaおよびPL/SQLストアド・プロシージャをデバッグしようとするときに、次のエラーが表示される可能性があります。

ORA-24247: network access denied by access control list (ACL)
ORA-06512: at "SYS.DBMS_DEBUG_JDWP", line line_number

- JDWP操作のネットワーク・アクセスを構成するには、DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACEプロシージャを使用します。

次の例は、JDWP操作のネットワーク・アクセスの構成方法を示しています。

BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host         => 'host',
lower_port   => null|port_number,
upper_port   => null|port_number,
ace => xs$ace_type(privilege_list => xs$name_list('jdwp'),
principal_name => 'username',
principal_type => xs_acl.ptype_db));
END;
/

次のように値を指定します。

- hostは、ホスト名、ドメイン名、IPアドレスまたはサブネットのいずれかです。

- port_numberでは、ポートの範囲を指定できます。ポートを使用する場合、lower_portおよびupper_port値を省略します。

- 引用符で囲まれていないかぎり(たとえば、principal_name => '"PSMITH"'など)、usernameは大/小文字を区別しません。

関連項目:

- JDWPを使用したサーバー・アプリケーションのデバッグの詳細は、『Oracle Database Java開発者ガイド』を参照してください。

- SQL Developerのリモート・デバッグの詳細は、Oracle SQL開発者ユーザーズ・ガイドを参照してください。

ユーザー・アクセス用に構成されたアクセス制御リストのデータ・ディクショナリ・ビュー

Oracle Databaseでは、既存のアクセス制御リストに関する情報の検索に使用できるデータ・ディクショナリ・ビューが提供されています。

表6-1に、これらのビューを示します。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

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

ビュー

説明

DBA_HOST_ACES

ネットワーク・ホストに定義されたネットワーク権限が表示されます。このビューのSELECT権限は、SELECT_CATALOG_ROLEロールのみに付与されます。

DBA_WALLET_ACES

ウォレット・パス、ACE順序、開始時間と終了時間、付与タイプ、権限およびプリンシパルの情報がリストされます

DBA_WALLET_ACLS

ウォレットに対するアクセス制御リスト割当てが表示されます。このビューのSELECT権限は、SELECT_CATALOG_ROLEロールのみに付与されます。

DBA_HOST_ACLS

ネットワーク・ホストに対するアクセス制御リスト割当てが表示されます。このビューのSELECT権限は、SELECT_CATALOG_ROLEロールのみに付与されます。

USER_HOST_ACES

現行ユーザーがネットワーク・ホストにアクセスするためのネットワーク権限のステータスが表示されます。このビューのSELECT権限はPUBLICに付与されます。

USER_WALLET_ACES

ウォレットのコンテンツにアクセスするため、現在のユーザーのウォレット権限のステータスが表示されます。このビューのSELECT権限はPUBLICに付与されます。

7 Enterprise Managerによるマルチテナント環境のセキュリティの管理

Oracle Enterprise Managerを使用して、マルチテナント環境の共通およびローカルのユーザーとロールを管理できます。

内容は次のとおりです。

- Enterprise Managerによるマルチテナント環境のセキュリティの管理について

- Enterprise Managerによるマルチテナント環境へのログイン

- Enterprise Managerの共通ユーザーおよびローカル・ユーザーの管理

- Enterprise Managerの共通およびローカル・ロールおよび権限の管理

Enterprise Managerによるマルチテナント環境のセキュリティの管理について

Oracle Enterprise Manager Cloud Controlではマルチテナント環境のセキュリティ管理がサポートされます。

マルチテナント環境では、Oracle Enterprise Manager Cloud Controlを使用して、ルートと関連のプラガブル・データベース(PDB)の両方の共通ユーザーと共通ロールの作成、管理および監視ができます。

Enterprise Managerによって、ルートと指定されたPDBの間を容易に切り替えることができます。

Enterprise Managerによるマルチテナント環境へのログイン

マルチテナント環境では、CDBまたはPDBにログインしたり、PDBから別のPDBまたはルートに切り替えることができます。

内容は次のとおりです。

- CDBまたはPDBへのログイン

- 別のPDBへの、またはルートへの切替え

CDBまたはPDBへのログイン

様々な種類のEnterprise Managerデータベース・ログイン・ページが、ログイン時にリクエストした機能に基づいて自動的に表示されます。

マルチテナント・コンテナ・データベース(CDB)管理者(CDBターゲットに対してCONNECT権限を持つEnterprise Managerユーザー)としてマルチテナント環境にログインしてCDBの範囲の機能を使用するには、次の手順を実行します。

1. ユーザーSYSTEMまたはSYSMANとしてOracle Enterprise Manager Cloud Controlにログインします。

URLは次のとおりです。

https://host:port/em

2. 「データベース」ページに移動します。

3. アクセスするデータベースを選択します。

データベースのホームページが表示されます。

4. 実行するアクションのメニュー項目を選択します。たとえば、ユーザーを認証するには「管理」、「セキュリティ」、「ユーザー」の順に選択します。

「データベース・ログイン」ページが表示されます。次に示す例はCDBの「データベース・ログイン」ページです(表示されているデータベース名がCDB$ROOTのため)。この名前から、このページは口語的にマルチテナント環境のrootのデータベース・ログイン・ページと呼ばれます。「データベース」フィールドは現在のデータベースを示します。PDBを選択した場合、PDBの名前がこのフィールドに表示されます。

5. 適切な資格証明を使用してログインします。

共通ユーザーのみがルートにログインでき、共通ユーザーの名前はC##またはc##で始まることに注意してください。PDBには、共通ユーザーとローカル・ユーザーの両方がそれぞれの権限に応じてログインできます。

別のPDBへの、またはルートへの切替え

Oracle Enterprise Managerで、PDBから別のPDBまたはルートに切り替えることができます。

1. ページの左上に「データベース」リンクがあります。

「データベース」リンクに、現在のコンテナ名が表示されます。次に示す例では、現在のデータベースは、口語的にルートと呼ばれるCDB自体(CDB$ROOT)です。

2. コンテナの右にあるメニュー・アイコンを選択し、このメニューから、アクセスするデータベースを選択します。

メニュー項目が表示されない場合は、データベースのホームページなど、メニュー項目が表示されるページに移動します。

3. 実行するアクティビティ(ユーザーの作成など)を決定する際は、適切な権限でログインします。

あらかじめ適切な権限で認証を行わずにアクティビティを実行しようとすると、適切な権限でログインするよう要求されます。

Enterprise Managerの共通ユーザーおよびローカル・ユーザーの管理

マルチテナント環境では、Oracle Enterprise Managerを使用すると、共通ユーザーとローカル・ユーザーを作成、編集および削除できます。

内容は次のとおりです。

- Enterprise Managerの共通ユーザー・アカウントの作成

- Enterprise Managerの共通ユーザー・アカウントの編集

- Enterprise Managerの共通ユーザー・アカウントの削除

- Enterprise Managerのローカル・ユーザー・アカウントの作成

- Enterprise Managerのローカル・ユーザー・アカウントの編集

- Enterprise Managerのローカル・ユーザー・アカウントの削除

関連項目:

共通ユーザーおよびローカル・ユーザーについて

Enterprise Managerの共通ユーザー・アカウントの作成

共通ユーザーは、ルートに存在し、CDBのPDBにアクセスできるユーザーです。

1. Enterprise Managerデータベースのホームページで、共通CREATE USERおよびSET CONTAINER権限を持つ共通ユーザーとしてルートにログインします。

別のPDBまたはルートへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください。

共通およびローカルに付与される権限についても参照してください。

2. 「管理」メニューから、「セキュリティ」を選択し、「ユーザー」を選択します。

要求された場合は、ログイン情報を入力します。その後、「ユーザー」ページが表示されます。

3. 「作成」をクリックします。

「ユーザーの作成」ページが表示されます。

4. 共通ユーザーを作成するオプションを選択して、このユーザーに権限を付与します。

ユーザー名の前にC##またはc##を付けてください。

5. 「OK」または「適用」をクリックします。

共通ユーザーは、ルートで作成され、関連付けられているPDBの「ユーザー」ページに表示されます。

関連項目:

共通ユーザー・アカウントの作成について

Enterprise Managerの共通ユーザー・アカウントの編集

共通ユーザー・アカウントは、ルートから編集できます。

1. Enterprise Managerデータベースのホームページで、ルートまたはPDBにログインします。

ルートにログインする場合は、共通CREATE USERおよびSET CONTAINER権限を持つ共通ユーザーである必要があります。PDBにログインする場合は、そのPDBのCREATE USER権限を持っていることを確認してください。

ルートまたは別のPDBへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください。

2. 「管理」メニューから、「セキュリティ」を選択し、「ユーザー」を選択します。

要求された場合は、ログイン情報を入力します。その後、「ユーザー」ページが表示されます。ルートでは、共通ユーザーのみが表示されます。PDBでは、共通ユーザーとローカル・ユーザーの両方がリストされます。

3. 編集する共通ユーザーを選択して、「編集」をクリックします。

ユーザーの編集ページが表示されます。ルートの共通ユーザーについては、その共通ユーザーのすべての設定を変更できます。PDBの共通ユーザーについては、ユーザー・パスワード、デフォルト表領域、一時表領域は変更できません。設定の変更は、現在のPDBにのみ適用されます。次の画面に、PDBでの共通ユーザーの「ユーザーの編集」ページを示します。

4. 必要に応じて、共通ユーザーを変更します。

5. 「適用」をクリックします。

関連項目:

共通またはローカル・ユーザー・アカウントを変更するためのALTER USER文

Enterprise Managerの共通ユーザー・アカウントの削除

共通ユーザーは、CDBルートから削除できます。

1. Enterprise Managerデータベースのホームページで、共通CREATE USERおよびSET CONTAINER権限を持つ共通ユーザーとしてルートにログインします。

PDBから共通ユーザーを削除することはできません。

ルートまたは別のPDBへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください。

2. 「管理」メニューから、「セキュリティ」を選択し、「ユーザー」を選択します。

要求された場合は、ログイン情報を入力します。その後、共通ユーザーのみをリストする「ユーザー」が表示されます。

3. 削除する共通ユーザーを選択して、「削除」をクリックします。

4. 共通ユーザーの削除を確定します。

Enterprise Managerのローカル・ユーザー・アカウントの作成

ローカル・ユーザーは、特定のPDBにのみ存在し、マルチテナント環境の他のPDBにアクセスできないユーザーです。

1. Enterprise Managerデータベースのホームページで、ローカルCREATE USER権限を持つローカル・ユーザーまたは共通ユーザーとしてPDBにログインします。

ルートまたは別のPDBへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください

2. 「管理」メニューから、「セキュリティ」を選択し、「ユーザー」を選択します。

要求された場合は、ログイン情報を入力します。その後、現在のPDBのローカル・ユーザーのみを示す「ユーザー」ページが表示されます。

3. 「作成」をクリックします。

「ユーザーの作成」ページが表示されます。

4. ローカル・ユーザーを作成するオプションを選択して、このユーザーに権限を付与します。

ユーザー名の前にC##またはc##を付けないでください。

5. 「OK」をクリックします。

現在のPDBでローカル・ユーザーが作成されます。

関連項目:

ローカル・ユーザー・アカウントの作成について

Enterprise Managerのローカル・ユーザー・アカウントの編集

ローカル・ユーザーは、そのローカル・ユーザーが存在するPDBから編集できます。

1. Enterprise Managerデータベースのホームページで、ローカルCREATE USER権限を持つローカル・ユーザーまたは共通ユーザーとしてPDBにログインします。

ルートまたは別のPDBへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください

2. 「管理」メニューから、「セキュリティ」を選択し、「ユーザー」を選択します。

要求された場合は、ログイン情報を入力します。その後、現在のPDBのローカル・ユーザーおよび共通ユーザーのみを示す「ユーザー」ページが表示されます。

3. 編集するローカル・ユーザーを選択して、「編集」をクリックします。

ユーザーの編集ページが表示されます。

4. 必要に応じて、ローカル・ユーザーを変更します。

5. 「適用」をクリックします。

関連項目:

共通またはローカル・ユーザー・アカウントを変更するためのALTER USER文

Enterprise Managerのローカル・ユーザー・アカウントの削除

ローカル・ユーザーは、そのローカル・ユーザーが存在するPDBから削除できます。

1. Enterprise Managerデータベースのホームページで、ローカルCREATE USER権限を持つローカル・ユーザーまたは共通ユーザーとしてPDBにログインします。

ルートまたは別のPDBへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください

2. 「管理」メニューから、「セキュリティ」を選択し、「ユーザー」を選択します。

要求された場合は、ログイン情報を入力します。その後、現在のPDBのローカル・ユーザーおよび共通ユーザーのみを示す「ユーザー」ページが表示されます。(PDBから共通ユーザーを削除することはできません。)

3. 削除するローカル・ユーザーを選択して、「削除」をクリックします。

ユーザーを削除してよいかどうか、確認を求められます。

4. ローカル・ユーザーの削除を確定します。

Enterprise Managerの共通およびローカル・ロールおよび権限の管理

マルチテナント環境では、Oracle Enterprise Managerを使用して、共通ロールとローカル・ロールの作成、編集、削除および取消しを行うことができます。

内容は次のとおりです。

- Enterprise Managerの共通ロールの作成

- Enterprise Managerの共通ロールの編集

- Enterprise Managerの共通ロールの削除

- Enterprise Managerの共通権限付与の取消し

- Enterprise Managerのローカル・ロールの作成

- Enterprise Managerのローカル・ロールの編集

- Enterprise Managerのローカル・ロールの削除

- Enterprise Managerのローカル権限付与の取消し

関連項目:

- 共通およびローカルに付与される権限の管理

- 共通ロールおよびローカル・ロールの管理

Enterprise Managerの共通ロールの作成

共通ロールを使用して、共通権限を共通ユーザーに割り当てることができます。

これらのロールは、マルチテナント環境のすべてのコンテナで有効です。

1. Enterprise Managerデータベースのホームページで、共通CREATE ROLEおよびSET CONTAINER権限を持つ共通ユーザーとしてルートにログインします。

ルートまたは別のPDBへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください

2. 「管理」メニューから、「セキュリティ」を選択し、「ロール」を選択します。

要求された場合は、ログイン情報を入力します。その後、「ロールの作成」ページが表示されます。

3. 「作成」をクリックします。

「ロールの作成」ページが表示されます。

4. 共通ロールを作成するオプションを選択して、このロールに権限を付与します。

ロール名の前にC##またはc##を付けてください。

5. 「OK」をクリックします。

共通ロールがルートに作成されます。

関連項目:

- 共通ロールの作成の規則

- PDBへのアクセス権限の付与または取消し

Enterprise Managerの共通ロールの編集

共通ロールは、ルートから編集できます。

1. Enterprise Managerデータベースのホームページで、ルートまたはPDBにログインします。

ルートにログインする場合は、共通CREATE ROLEおよびSET CONTAINER権限を持つ共通ユーザーである必要があります。PDBにログインする場合は、そのPDBのCREATE ROLE権限を持っていることを確認してください。

ルートまたは別のPDBへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください

2. 「管理」メニューから、「セキュリティ」を選択し、「ロール」を選択します。

要求された場合は、ログイン情報を入力します。その後、「ロール」ページが表示されます。ルートでは、共通ロールのみが表示されます。PDBでは、共通ロールとローカル・ロールの両方が表示されます。

3. 編集する共通ロールを選択して、「編集」をクリックします。

ロールの編集ページが表示されます。ルートの共通ユーザーについては、その共通ユーザーのすべての設定を変更できます。

PDBの共通ロールについては、ロールの認証のみ変更可能で、このユーザーに別のロール、システム権限、オブジェクト権限およびコンシューマ・グループ権限を付与します。これらの設定は現在のPDBにのみ適用されます。

4. 必要に応じて、共通ユーザーを変更します。

5. 「適用」をクリックします。

Enterprise Managerの共通ロールの削除

共通ロールは、ルートから削除できます。

1. Enterprise Managerデータベースのホームページで、共通CREATE ROLEおよびSET CONTAINER権限を持つ共通ユーザーとしてルートにログインします。

PDBから共通ロールを削除することはできません。

ルートまたは別のPDBへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください

2. 「管理」メニューから、「セキュリティ」を選択し、「ロール」を選択します。

要求された場合は、ログイン情報を入力します。その後、共通ロールのみを示す「ロール」ページが表示されます。

3. 削除する共通ロールを選択して、「削除」をクリックします。

4. 共通ロールの削除を確定します。

Enterprise Managerの共通権限付与の取消し

共通権限付与は、ルートから取り消すことができます。

1. Enterprise Managerデータベースのホームページで、共通CREATE USER、CREATE ROLEおよびSET CONTAINER権限を持つ共通ユーザーとしてルートにログインします。

ルートまたは別のPDBへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください

2. 「管理」メニューから、「セキュリティ」を選択し、「ユーザー」を選択します。

「ユーザー」ページに、共通ユーザーが表示されます。

3. 権限を取り消すユーザーを選択して、「編集」をクリックします。

ユーザーの編集ページが表示されます。

4. 「ロール」または該当する「権限」タブを選択します。

このユーザーに割り当てられているロールと権限のリストが表示されます。

5. 「リストの編集」を選択し、必要に応じてロールまたは権限を削除します。

6. 「OK」ボタンをクリックします。

関連項目:

PDBへのアクセス権限の付与または取消し

Enterprise Managerのローカル・ロールの作成

共通ロールを使用して、後でローカル・ユーザーに権限のローカル・セットを割り当てることができます。

これらのロールは、定義対象のPDBコンテナ全体で有効になります。

1. Enterprise Managerデータベースのホームページで、ローカルCREATE ROLE権限を持つユーザーとしてPDBにログインします。
「Enterprise Managerによるマルチテナント環境へのログイン」は、別のPDBへのログインと切替えの方法を説明しています。

2. 「管理」メニューから、「セキュリティ」を選択し、「ロール」を選択します。

ロール・ページが表示されます。

3. 「作成」をクリックします。

要求された場合は、ログイン情報を入力します。その後、「ロールの作成」ページが表示されます。

4. ローカル・ロールを作成するオプションを選択して、このロールに権限を付与します。

ロール名の前にC##またはc##を付けないでください。

5. 「OK」をクリックします。

現在のPDBでローカル・ロールが作成されます。

Enterprise Managerのローカル・ロールの編集

ローカル・ロールは、そのローカル・ロールが存在するPDBで編集できます。

1. Enterprise Managerデータベースのホームページで、ローカルCREATE ROLE権限を持つユーザーとしてPDBにログインします。

ルートまたは別のPDBへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください

2. 「管理」メニューから、「セキュリティ」を選択し、「ロール」を選択します。

要求された場合は、ログイン情報を入力します。その後、現在のPDBのローカル・ロールおよび共通ロールのみを示す「ロール」ページが表示されます。

3. 編集するローカル・ロールを選択して、「編集」をクリックします。

ユーザーの編集ページが表示されます。

4. 必要に応じて、ローカル・ユーザーを変更します。

5. 「適用」をクリックします。

Enterprise Managerのローカル・ロールの削除

ローカル・ロールは、そのローカル・ロールが存在するPDBから削除できます。

1. Enterprise Managerデータベースのホームページで、ローカルCREATE ROLE権限を持つユーザーとしてPDBにログインします。

ルートまたは別のPDBへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください

2. 「管理」メニューから、「セキュリティ」を選択し、「ロール」を選択します。

要求された場合は、ログイン情報を入力します。その後、現在のPDBのローカル・ロールおよび共通ロールのみを示す「ロール」ページが表示されます。(PDBから共通ロールを削除することはできません。)

3. 削除するローカル・ロールを選択して、「削除」をクリックします。

ロールを削除してよいかどうか、確認を求められます。

4. ローカル・ロールの削除を確定します。

Enterprise Managerのローカル権限付与の取消し

ローカル権限は、その権限が使用されるPDBで取り消すことができます。

1. Enterprise Managerデータベースのホームページで、CREATE USERおよびCREATE ROLE権限を持つ共通ユーザーまたはローカル・ユーザーとしてPDBにログインします。

ルートまたは別のPDBへのログインと切替えに関する詳細は、Enterprise Managerによるマルチテナント環境へのログインを参照してください

2. 「管理」メニューから、「セキュリティ」を選択し、「ユーザー」を選択します。

要求された場合は、ログイン情報を入力します。その後、「ユーザー」ページが表示されます。PDBでは、共通ユーザーとローカル・ユーザーの両方がリストされます。

3. 権限を取り消すユーザーを選択して、「編集」をクリックします。

ユーザーの編集ページが表示されます。

4. 「ロール」または該当する「権限」タブを選択します。

このユーザーに割り当てられているロールと権限のリストが表示されます。

5. 「リストの編集」を選択し、必要に応じて権限を削除します。

6. 「OK」ボタンをクリックします。

関連項目:

PDBへのアクセス権限の付与または取消し

第II部 アプリケーション開発のセキュリティ

第II部では、アプリケーション開発のセキュリティの管理方法について説明します。

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

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

アプリケーション開発者のセキュリティ・ポリシーには、パスワード管理、外部プロシージャやアプリケーション権限を保護する方法、アプリケーション・ロールとデータベース・ロールの管理、スキーマ・オブジェクトの保護方法などの領域があります。

内容は次のとおりです。

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

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

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

- 外部プロシージャの保護

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

- アプリケーション権限の管理にロールを使用する利点

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

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

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

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

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

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

アプリケーション・セキュリティ・ポリシーは、アプリケーション・セキュリティの要件およびデータベース・オブジェクトへのユーザー・アクセスを規制するルールのリストです。

安全なデータベース・アプリケーションを作成する最初のステップは、アプリケーション・セキュリティ・ポリシーの作成です。セキュリティ・ポリシーは、データベース・アプリケーションごとに立案する必要があります。たとえば、各データベース・アプリケーションには、アプリケーションの実行時に異なるレベルのセキュリティを提供する1つ以上のデータベース・ロールが必要です。データベース・ロールは、他のロールに付与するか、または特定のユーザーに直接付与できます。

(SQL*PlusやSQL Developerなどのツールを使用して)SQL文を制限なしで処理できるアプリケーションの場合でも、機密扱いのスキーマ・オブジェクトや重要なスキーマ・オブジェクトへの不当なアクセスを防ぐために、セキュリティ・ポリシーが必要です。特に、使用するアプリケーションでパスワードが安全に処理されることを確認する必要があります。

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

アプリケーションのセキュリティを策定して実装する場合、アプリケーション・ユーザーとデータベース・ユーザーを区別することに加えて、アプリケーションまたはデータベースで効果的にセキュリティが実施されているかどうかについて考慮してください。

内容は次のとおりです。

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

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

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

できるかぎり、アプリケーション・ユーザーがデータベース・ユーザーであるアプリケーションを作成し、データベースに備わるセキュリティ・メカニズムを使用できるようにします。

多くの市販のパッケージ・アプリケーションでは、アプリケーション・ユーザーは、データベース・ユーザーではありません。これらのアプリケーションでは、複数のユーザーがユーザー自身をアプリケーションに対して認証し、次に、アプリケーションが単一の高い権限を持つユーザーとしてデータベースに接続します。これを、One Big Application Userモデルと呼びます。

この方法で作成されたアプリケーションは、通常、データベースに本来備わっているセキュリティ機能の多くを使用できません。これは、ユーザーの識別情報がデータベースで認識されないためです。ただし、ある種の追跡はクライアント識別子を使用して実行できます。たとえば、Oracle Call InterfaceメソッドOCIAttrSetのOCI_ATTR_CLIENT_IDENTIFIER属性を使用すると、クライアント接続の監査と監視を有効化できます。クライアント識別子を使用して、個別のWebユーザーの監査証跡データを収集し、Webユーザーによるデータ・アクセスを制限するルールを適用し、各Webユーザーが使用するアプリケーションを監視および追跡できます。

表8-1は、One Big Application Userモデルが様々なOracle Databaseセキュリティ機能にどのように影響するかを説明しています。

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

Oracle Database機能

One Big Application Userモデルの制限

監査

セキュリティの基本原則の1つは、監査によるアカウンタビリティです。One Big Application Userがデータベース内のすべての操作を実行する場合、データベース監査では、個々のユーザーが実行したアクションに対する責任をそのユーザー自身に持たせることができません。アプリケーションでは、独自の監査メカニズムを実装して、ユーザーのアクションを個別に捕捉する必要があります。

Oracle厳密認証

データベースに対するクライアントの認証が、個々のユーザーではなくアプリケーションの場合、認証の厳密な形式(たとえば、SSLやトークンなどでのクライアント認証)は使用できません。

ロール

ロールは、データベース・ユーザーに割り当てられます。エンタープライズ・ロールは、データベース内で作成されていない場合でも、エンタープライズ・ユーザーに割り当てられ、データベースに認識されます。アプリケーション・ユーザーがデータベース・ユーザーではない場合、ロールの有用性は低くなります。この場合、アプリケーションでは独自のメカニズムを作成して、様々なアプリケーション・ユーザーがアプリケーション内のデータへアクセスするのに必要とする権限を識別する必要があります。

エンタープライズ・ユーザー管理

エンタープライズ・ユーザー管理機能は、Oracle Internet DirectoryなどのLDAPベースのディレクトリにユーザー情報を安全に格納して認可を管理することで、OracleデータベースがOracle Identity Managementインフラストラクチャを使用できるようにします。エンタープライズ・ユーザーは、データベース内に作成する必要はありませんが、データベースに認識される必要があります。One Big Application Userモデルでは、Oracle Identity Managementを利用できません。

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

アプリケーションでできるだけ多くのデータベース・セキュリティ・メカニズムが使用されるようにすることをお薦めします。

ユーザーがデータベース・ユーザーでもあるアプリケーションは、アプリケーションの中にセキュリティを組み込むか、きめ細かい権限、仮想プライベート・データベース(アプリケーション・コンテキストによるファイングレイン・アクセス・コントロール)、ロール、ストアド・プロシージャ、および監査(ファイングレイン監査を含む)などのデータベースに本来備わっているセキュリティ・メカニズムを使用できます。

セキュリティがアプリケーション内ではなくデータベース自体で規定されている場合は、セキュリティを回避することはできません。アプリケーション・ベースのセキュリティの主なデメリットは、ユーザーがアプリケーションを回避してデータにアクセスすると、セキュリティが回避されることです。たとえば、データベースへのSQL*Plusアクセス権を持つユーザーは、人事管理アプリケーションを介さずに問合せを実行できます。したがって、このユーザーは、アプリケーション内のセキュリティ対策のすべてをバイパスします。

One Big Application Userモデルを使用するアプリケーションでは、データベースのセキュリティ・メカニズムを使用せずに、アプリケーション内にセキュリティ規定を作成する必要があります。ユーザーを認識するのは、データベースではなくアプリケーションであるため、アプリケーション自体が各ユーザーに対してセキュリティ対策を規定する必要があります。

このアプローチでは、データにアクセスする各アプリケーションでのセキュリティの再実装が必要になります。組織では複数のアプリケーションに同じセキュリティ・ポリシーを実装する必要があるため、セキュリティが高コストになり、新規アプリケーションごとに高コストな再実装が必要になります。

関連項目:

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

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

Oracle Databaseには、バッチ・ジョブ、スクリプト、インストール・ファイルまたはアプリケーションからパスワードで保護されたサービスを安全に起動する戦略が用意されています。パスワード保護に加えて、これらの戦略の多くはその他の機密データ(暗号化鍵など)に適用できます。

内容は次のとおりです。

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

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

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

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

関連項目:
Oracleデータベースの保護に関する一般的なガイドラインについては、Oracle Databaseの安全性の維持を参照してください

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

アプリケーションでのパスワード保護のガイドラインでは、プラットフォーム固有のセキュリティ脅威、パスワード入力、パスワードの形式と動作、SQL*PlusおよびSQLスクリプトでのパスワードの取扱い方法が取り上げられています。

内容は次のとおりです。

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

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

- パスワードの形式と動作の構成のガイドライン

- SQLスクリプトにおけるパスワードの処理のガイドライン

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

次の潜在的なセキュリティへの脅威は、わかりにくい可能性があるので注意してください。

これらのセキュリティへの脅威は次のとおりです。

- UNIXおよびLinuxプラットフォームでは、同じホスト・コンピュータ上のすべてのオペレーティング・システム・ユーザーがコマンド・パラメータを表示できます。結果として、コマンドラインに入力したパスワードは他のユーザーに公開される可能性があります。ただし、UNIXおよびLinux以外のプラットフォームがこの脅威を回避できるとは考えないでください。

- HP Tru64およびIBM AIXなど一部のUNIXプラットフォームでは、すべてのオペレーティング・システム・ユーザーがあらゆるプロセスの環境変数を表示できます。ただし、UNIXおよびLinux以外のプラットフォームがこの脅威を回避できるとは考えないでください。

- Microsoft Windowsでは、コマンド・リコール機能(上矢印)に、コマンド起動間のユーザー入力が記憶されます。たとえば、SQL*PlusのCONNECT SYSTEM/password表記法を使用し、終了してから上矢印を押してCONNECTコマンドを繰り返した場合、コマンド・リコール機能により接続文字列が明らかになり、パスワードが表示されます。また、Microsoft Windows以外のプラットフォームがこの脅威を回避できるとは考えないでください。

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

Oracleには、パスワード入力を扱うアプリケーションの設計に関するガイドラインが用意されています。

- パスワードの入力を対話形式で求めるアプリケーションを設計します。コマンドライン・ユーティリティの場合、コマンド・プロンプトでパスワードを公開することをユーザーに強制しないでください。
アプリケーションの設計に使用するプログラミング言語のAPIについて、ユーザーからのパスワードを処理する最適な方法を確認します。この機能を処理するJavaコードの例は、「例: パスワードを読み取るためのJavaコード」を参照してください。

- コード・インジェクション攻撃からデータベースを保護します。コード・インジェクション攻撃の標的は主に、データベースにSQLを送信するクライアント・アプリケーション・ツール(SQL*Plus、Oracle Call Interface (OCI)、JDBCアプリケーションなど)です。これらのツールを使用して作成されたデータベース・ドライバも含まれます。SQLインジェクション攻撃では、PL/SQLアプリケーションで想定されていない方法でSQL文が動作します。インジェクション攻撃は、データベースに文が送信される前に行われます。たとえば、侵入者はWHERE句をTRUEに設定してパスワード認証を回避できます。
SQLインジェクション攻撃の問題に対処するには、バインド変数引数を使用するか妥当性チェックを作成します。バインド変数を使用できない場合は、DBMS_ASSERT PL/SQLパッケージを使用して入力値のプロパティを検証することを検討してください。DBMS_ASSERTパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。また、PUBLICなどのロールに対する権限付与も検討してください。

インジェクションはデータベースに文が送信される前に行われる可能性があるため、クライアント・アプリケーションのユーザーがSQLインジェクションをPL/SQLに結び付けることができるとは限らないことに注意してください。

SQLインジェクションの防止の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- 可能な場合は、認証を遅延するアプリケーションを設計します。次に例を示します。

- ログインに証明書を使用します。

- オペレーティング・システムで提供される機能を使用してユーザーを認証します。たとえば、Microsoft Windows上で動作するアプリケーションはドメイン認証を使用できます。

- パスワードをマスクまたは暗号化します。パスワードを格納する必要がある場合、パスワードをマスクまたは暗号化します。たとえば、ログ・ファイルでパスワードをマスクし、リカバリ・ファイルでパスワードを暗号化できます。

- 各接続を認証します。たとえば、スキーマAがデータベース1に存在する場合、データベース2のスキーマAが同一のユーザーであるとは考えないでください。同様に、ローカル・オペレーティング・システム・ユーザーpsmithは、必ずしもリモート・ユーザーpsmithと同じユーザーではありません。

- ファイルまたはリポジトリにクリアテキスト・パスワードを格納しないでください。パスワードをファイルに格納すると、侵入者がパスワードにアクセスする危険性が高まります。

- 1つのマスター・パスワードを使用します。次に例を示します。

- 1人のデータベース・ユーザーに、他のデータベース・ユーザーとなるためのプロキシ認証を付与できます。この場合、必要となるデータベース・パスワードは1つのみです。詳細は、「プロキシ・ユーザー・アカウントと、そのアカウントを介して接続するユーザーの認可」を参照してください。

- マスター・パスワードでオープンできるパスワード・ウォレットを作成できます。ウォレットにはその他のパスワードが含められます。Wallet Managerの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

パスワードの形式と動作の構成のガイドライン

Oracle Databaseには、パスワードの形式と動作の構成に関するガイドラインが用意されています。

- パスワードの存続期間を制限します。パスワード存続期間を設定して、その期間が過ぎるとパスワードが期限切れになり、変更しないとユーザーがアカウントにログインできなくなるようにすることができます。パスワードの存続期間を制御するために使用できるパラメータは、パスワード・エイジングおよび期限切れの制御についてを参照してください。

- ユーザーが古いパスワードを再利用する機能を制限します。詳細は、ユーザーによる以前のパスワードの再利用の制御を参照してください。

- 強力かつ安全なパスワードを作成するようユーザーに要求します。強力なパスワードの作成に関するガイドラインは、パスワードの保護に関するガイドラインを参照してください。パスワードの複雑度検証の概要では、パスワードの要件をカスタマイズする方法について説明しています。

- パスワードで大/小文字を区別できるようにします。詳細は、パスワードでの大/小文字の区別の管理を参照してください。

関連項目:

- パスワードの最低要件

- パスワードの複雑度検証の概要

SQLスクリプトにおけるパスワードの処理のガイドライン

Oracleには、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 ‘Enter user to connect to: ‘
ACCEPT password CHAR PROMPT ‘Enter the password for that user: ' HIDE
CONNECT &user/&password

この例の説明は、次のとおりです。

- SET VERIFY OFFは、パスワードの表示を防止します。(SET VERIFYは、置換の前後にスクリプトの各行をリストします。)SET VERIFY OFFコマンドをHIDEコマンドと結合する方法は、パスワードおよびその他の機密入力データを非表示にする便利なテクニックです。

- ACCEPT password CHAR PROMPTは、ACCEPT passwordプロンプトにHIDEオプションを含めます。これによって入力パスワードのエコーが回避されます。

次の例では位置パラメータを使用しており、ユーザーがコマンドライン上でパスワードを渡すことでスクリプトを起動できるため、セキュリティ上のリスクをもたらします。ユーザーがパスワードを入力せず、入力を求めるプロンプトが表示される場合、ユーザーが入力した内容がすべて画面およびスプール・ファイル(スプールが有効な場合)にエコーされるため危険です。

CONNECT &1/&2

- バッチ・スクリプトのログイン時間を制御します。パスワードを必要とするバッチ・スクリプトでは、実行されることになっている時間内のみにバッチ・スクリプトがログインできるようにアカウントを構成します。たとえば、毎日午後8時から1時間実行するバッチ・スクリプトを想定します。この時間のみスクリプトがログインできるようにアカウントを設定します。侵入者がアクセスしようとした場合、安全性の低いアカウントが利用される可能性は低くなります。

- パスワードの入力を求めるDML文またはDDL SQL文を使用する場合は注意してください。この場合、機密情報がネットワークを介してクリアテキストで渡されます。Oracle厳密認証を使用して、この問題に対処できます。
次のパスワード変更例は、パスワードが公開されないため安全です。

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エンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

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

SYSDBAまたはSYSOPERユーザーはパスワード・ファイルを使用して、ネットワーク経由でアプリケーションに接続できます。

- パスワード・ファイルを作成するには、ORAPWDユーティリティを使用します。

関連項目:

パスワード・ファイルの作成および管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

例: パスワードを読み取るためのJavaコード

パスワードの読取りに使用できるJavaパッケージを作成できます。

例8-1に、パスワードの読取りに使用できるJavaパッケージの作成方法を示します。

例8-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();
}
}
}

外部プロシージャの保護

外部プロシージャは、データベースとは別に、.dllまたは.soファイルに格納されるプロシージャです。外部プロシージャを保護するには、資格証明を介してその外部プロシージャを認証できます。

内容は次のとおりです。

- 外部プロシージャの保護について

- 資格証明の認証に対するextprocの構成に関する一般プロセス

- extprocプロセス認証および偽装設定の予期される動作

- 外部プロシージャの認証の構成

- レガシー・アプリケーションの外部プロシージャ

関連項目:

外部プロシージャの保護に関するガイドライン

外部プロシージャの保護について

安全上の理由のため、Oracle外部プロシージャは、データベースと物理的に異なるプロセスで実行されます。

ほとんどの場合、このプロセスを構成して、Oracleソフトウェア・アカウント以外のユーザーとして実行します。アプリケーションがこの外部プロシージャを呼び出す場合(.dllまたは.soファイルのライブラリにアクセスする必要がある場合など)、Oracle Databaseがextprocと呼ばれるオペレーティング・システム・プロセスを作成します。デフォルトでは、extprocプロセスは、サーバー・プロセスで直接通信します。つまり、資格証明を使用しない場合、Oracle Databaseは、デフォルトのOracle Databaseサーバー構成でextprocプロセスを作成し、oracleソフトウェア・アカウントとしてextprocを実行します。また、Oracle Databaseリスナーを介して通信できます。

資格証明の認証に対するextprocの構成に関する一般プロセス

セキュリティを強化するために、extprocプロセスを構成して、資格証明を介して認証できます。

一般プロセスは次のとおりです。

1. 資格証明を作成します。
資格証明は、暗号化されたコンテナにあります。パブリック・シノニムとプライベート・シノニムの両方でこの資格証明を参照できます。「外部プロシージャの認証の構成」では、この資格証明を作成し、データベースを構成して使用する方法について説明します。

2. 専用サーバーまたは共有サーバー・プロセスで実行しているデータベースへの最初の接続を行います。

3. アプリケーションは、外部プロシージャへのコールを行います。
これが最初のコールの場合、Oracle Databaseはextprocプロセスを作成します。extprocの資格証明を使用する場合、Oracleリスナーを使用してextprocプロセスを起動できません。

4. extprocプロセスは、偽装(つまり、指定された資格証明のかわりに実行)して、必要な.dll、.so、.slまたは.aファイルをロードし、SQLおよびC間のデータを送信します。

extprocプロセス認証および偽装設定の予期される動作

extprocプロセスには、認証および偽装に対する一連の動作が含まれています。

表8-2では、可能性のある認証および偽装シナリオに基づくextprocプロセスの予期される動作について説明します。

表8-2 extprocプロセス認証および偽装設定の予期される動作

ENFORCE_CREDENTIAL環境変数設定

資格証明を使用したPL/SQLライブラリか

GLOBAL_EXTPROC_CREDENTIAL資格証明の有無(1)

予期される動作

FALSE

なし

なし

OracleリスナーまたはOracleサーバー・プロセスの所有者のオペレーティング・システム権限で認証される12cより前のリリースの認証を使用します。

FALSE

なし

あり

Oracleインスタンス全体の指定されたGLOBAL_EXTPROC_CREDENTIALを使用して認証および偽装します(脚注2)

FALSE

あり

なし

PL/SQLライブラリで定義された資格証明を使用して認証および偽装します

FALSE

あり

あり

認証および偽装します(脚注3)

TRUE

なし

なし

エラーORA-28575: 外部プロシージャ・エージェントへのRPC接続をオープンできませんを戻します

TRUE

なし

あり

Oracleシステム全体の指定されたGLOBAL_EXTPROC_CREDENTIALを使用して認証および偽装します(脚注1)

TRUE

あり

なし

PL/SQLライブラリで定義された資格証明を使用して認証および偽装します

TRUE

あり

あり

認証および偽装します(脚注2)

脚注1 資格証明が明示的に指定されず、ENFORCE_CREDENTIAL環境変数がTRUEに設定されている場合、GLOBAL_EXTPROC_CREDENTIALは、デフォルトの資格証明の予約された資格証明名です。そのため、ENFORCE_CREDENTIALがTRUEに設定されている場合、この名前で資格証明を作成することをお薦めします。

脚注2

GLOBAL_EXTPROC_CREDENTIAL資格証明のみを使用している場合、このグローバル資格証明のEXECUTE権限が暗黙的にすべてのユーザーに自動的に付与されます。

脚注3

PL/SQLライブラリおよびGLOBAL_EXTPROC_CREDENTIAL設定の両方で資格証明が定義された場合、PL/SQLライブラリの資格証明が優先されます。

外部プロシージャの認証の構成

extprocプロセスの資格証明を構成するには、DBMS_CREDENTIAL PL/SQLパッケージを使用します。

1. CREATE CREDENTIALまたはCREATE ANY CREDENTIAL権限が付与されたユーザーを使用してSQL*Plusにログインします。

sqlplus psmith
Enter password: password
Connected.

マルチテナント環境で、適切なプラガブル・データベース(PDB)に接続する必要があります。例:

sqlplus psmith@hpdb
Enter password: password
Connected.

また、CREATE LIBRARYまたはCREATE ANY LIBRARY権限および外部コールを含むライブラリのEXECUTEオブジェクト権限があることも確認します。

2. DBMS_CREDENTIAL PL/SQLパッケージを使用して、新しい資格証明を作成します。

例:

BEGIN
DBMS_CREDENTIAL.CREATE_CREDENTIAL (
credential_name   => 'smith_credential',
user_name         => 'tjones',
password          => 'password')
END;
/

この例の説明は、次のとおりです。

- credential_name: 資格証明の名前を入力します。オプションで、スキーマの名前(たとえば、psmith.smith_credentialなど)で接頭辞を付けます。ENFORCE_CREDENTIAL環境変数がTRUEに設定されている場合、credential_name GLOBAL_EXTPROC_CREDENTIALを使用して資格証明を作成する必要があります。

- user_name: ユーザーとして実行するために使用する有効なオペレーティング・システム・ユーザー名を入力します。

- password: user_nameユーザーに対するパスワードを入力します。

3. 資格証明とPL/SQLライブラリを関連付けます。

例:

CREATE OR REPLACE LIBRARY ps_lib
AS 'smith_lib.so' IN DLL_LOC
CREDENTIAL smith_credential;

この例では、DLL_LOCは、$ORACLE_HOME/binディレクトリを指すディレクトリ・オブジェクトです。DLLへの絶対パスの使用はお薦めしません。

PL/SQLライブラリがextprocプロセスを介して外部プロシージャ・コールによってロードされる場合、extprocでは、定義されたsmith_credential資格証明のかわりに認証および偽装できます。

4. 外部プロシージャのコール方法や渡す引数をPL/SQLに対して通知するPL/SQLプロシージャまたは関数を作成して、外部プロシージャを登録します。

たとえば、Cで記述された外部プロシージャを登録する関数を作成するには、CREATE FUNCTION文のAS LANGUAGE C、LIBRARYおよびNAME句のみ次のように使用します。

CREATE OR REPLACE FUNCTION getInt (x VARCHAR2, y BINARY_INTEGER)
RETURN BINARY_INTEGER
AS LANGUAGE C
LIBRARY ps_lib
NAME "get_int_vals"
PARAMETERS (x STRING, y int);

関連項目:

- 外部プロシージャの保護に関するガイドライン

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

- extprocエージェントの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

- extproc.oraファイルの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

レガシー・アプリケーションの外部プロシージャ

セキュリティを最大にするために、ENFORCE_CREDENTIAL環境変数をTRUEに設定します。

ただし、下位互換性に対応する必要がある場合、ENFORCE_CREDENTIALをFALSEに設定します。FALSEによって、extprocプロセスは、指定された資格証明のかわりにユーザー定義コールアウト関数を認証、偽装および実行できます。

- 資格証明がPL/SQLライブラリで定義されます。

- 資格証明は定義されていませんが、 GLOBAL_EXTPROC_CREDENTIAL資格証明が存在します。

これらの資格証明定義が設定されていない場合、ENFORCE_CREDENTIALパラメータをFALSEに設定すると、OracleリスナーまたはOracleサーバー・プロセスの所有者のオペレーティング・システム権限で認証されるextprocプロセスが設定されます。

extprocプロセス上で実行されるレガシー・アプリケーションでは、レガシー・アプリケーション・コードを変更して、すべての別名ライブラリと資格証明を関連付けることをお薦めします。これを実行できない場合、Oracle DatabaseはGLOBAL_EXTPROC_CREDENTIAL資格証明を使用して、認証の処理方法を決定します。GLOBAL_EXTPROC_CREDENTIAL資格証明が定義されていない場合、extprocプロセスは、OracleリスナーまたはOracleサーバー・プロセスの所有者のオペレーティング・システム権限で認証されます。

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

ほとんどのデータベース・アプリケーションでは、異なるスキーマ・オブジェクトごとに異なる権限が関与します。

各アプリケーションに必要な権限の追跡は、複雑な場合があります。また、アプリケーションを実行するユーザーの認可には、多くのGRANT操作が関与する場合があります。

- アプリケーションの権限管理を簡素化するために、アプリケーションごとに作成した1つのロールに、1人のユーザーがそのアプリケーションを実行するために必要なすべての権限を付与します。
実際には、1つのアプリケーションに複数のロールがある可能性があり、各ロールには、アプリケーションの実行中に使用できる機能の多少を決める権限の特定サブセットが付与されます。

たとえば、すべての管理アシスタントが休暇アプリケーションを使用して、部門のメンバーが取得した休暇を記録するとします。このアプリケーションを効率的に管理するには、次の操作手順が必要です。

1. VACATIONロールを作成します。

2. 休暇アプリケーションに必要なすべての権限をVACATIONロールに付与します。

3. VACATIONロールをすべての管理アシスタントに付与します。より効率的な方法は、管理アシスタントが持つ権限を定義したロールを作成し、VACATIONロールをそのロールに付与します。

関連項目:

- ロールの作成、使用可能化と使用禁止化、および権限の付与と取消しの詳細は、「権限とロール認可の構成」を参照してください。

- ROLE_TAB_PRIVS、ROLE_SYS_PRIVSおよびDBA_ROLE_PRIVSデータ・ディクショナリ・ビューのセキュリティ使用の詳細は、ユーザー権限およびロールのデータ・ディクショナリ・ビューを参照してください

アプリケーション権限の管理にロールを使用する利点

複数のアプリケーション権限を1つのロールにグループ化すると、権限の管理に役立ちます。

次の管理オプションを考えてみます。

- アプリケーションを実行するユーザーに、多数の個別の権限ではなく、ロールを付与できます。したがって、従業員が業務を変更するときは、多くの権限ではなく、1つのロールのみを付与または取り消す必要があります。

- アプリケーションに対応付けられている権限の変更は、そのアプリケーションのすべてのユーザーが保持する権限ではなく、ロールに付与されている権限のみを修正することで実行できます。

- 特定のアプリケーションの実行に必要な権限は、ROLE_TAB_PRIVSとROLE_SYS_PRIVSの各データ・ディクショナリ・ビューを問い合せることで判断できます。

- どのユーザーに、どのアプリケーションの権限があるかは、DBA_ROLE_PRIVSデータ・ディクショナリ・ビューを問い合せることで判断できます。

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

セキュア・アプリケーション・ロールは関連するPL/SQLパッケージまたはプロシージャでのみ使用可能にできます。

内容は次のとおりです。

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

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

関連項目:

セキュア・アプリケーション・ロールの作成例は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください

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

IDENTIFIED USING句を持つCREATE ROLE文で、セキュア・アプリケーション・ロールを作成します。

この文を実行するには、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パッケージを作成できます。

内容は次のとおりです。

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

- アプリケーションに対するアクセス・ポリシーを定義するPL/SQLパッケージまたはプロシージャの作成

- セキュア・アプリケーション・ロールのテスト

アプリケーションに対するアクセス・ポリシーを定義するPL/SQLパッケージの作成について

セキュア・アプリケーション・ロールを有効または無効にするには、PL/SQLパッケージ内にロールのセキュリティ・ポリシーを作成する必要があります。

個別のプロシージャを作成してこれを実行することもできますが、パッケージを使用すると、一連のプロシージャをグループ化できます。これにより、一緒に使用するポリシーのグループを作成して、アプリケーションを保護するための強固なセキュリティ戦略を提示できます。セキュリティ・ポリシーに失敗したユーザー(潜在的な侵入者)については、監査チェックをパッケージに追加して、その失敗を記録できます。通常、このパッケージは、セキュリティ管理者のスキーマに作成します。

このパッケージまたはプロシージャは、次の内容を実行する必要があります。

- 実行者権限を使用してロールを有効にする必要があります。実行者権限を使用してパッケージを作成するには、AUTHIDプロパティをCURRENT_USERに設定する必要があります。定義者権限を使用してパッケージを作成することはできません。
実行者権限と定義者権限の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- ユーザーを検証するためのセキュリティ・チェックを1つ以上組み込む必要があります。ユーザーを検証する方法の1つは、SYS_CONTEXT SQLファンクションを使用することです。SYS_CONTEXTの詳細は、Oracle Database SQL言語リファレンスを参照してください。ユーザーに関するセッション情報を検索するために、アプリケーション・コンテキストでSYS_CONTEXTを使用できます。詳細は、「アプリケーション・コンテキストを使用したユーザー情報の取得」を参照してください。

- ユーザーがセキュリティ・チェックを通過するときに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言語リファレンス』を参照してください。

このパッケージまたはプロシージャの作成方法が原因で、セキュア・アプリケーション・ロールを使用可能または使用禁止にする際にログイン・トリガーを使用できません。かわりに、ユーザーがセキュリティ・アプリケーション・ロールで付与された権限を使用する前のユーザー・ログイン時に、アプリケーションからパッケージを直接起動します。

アプリケーションに対するアクセス・ポリシーを定義するPL/SQLパッケージまたはプロシージャの作成

作成するPL/SQLパッケージまたはプロシージャでは、アクセス・ポリシーを定義するために実行者権限を使用する必要があります。

たとえば、hr_adminロールを使用する全員を、オンサイト(特定の端末を使用)で午前8時から午後5時まで勤務する従業員に限定するとします。システム管理者またはセキュリティ管理者として、アプリケーションに対してアクセス・ポリシーを定義するプロシージャを作成できます。

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;

セキュア・アプリケーション・ロールのテスト

セキュア・アプリケーション・ロールを付与されたユーザーとして、そのロールで付与される権限を要するアクションを実行します。

セキュア・アプリケーション・ロールを付与されたユーザーとしてログインすると、そのロールが有効になります。

1. そのユーザーとしてデータベース・セッションにログインします。
例:

CONNECT PSMITH@hrpdb
Enter password: password

2. セキュア・アプリケーション・ロールで付与される権限を要求するアクションを実行します。
たとえば、そのロールがsec_admin.hr_admin_role_checkプロシージャに対してEXECUTE権限を付与するとします。

EXECUTE sec_admin.hr_admin_role_check;

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

ユーザーの権限が、現在のデータベース・ロールに関連した権限のみであることを確認します。

内容は次のとおりです。

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

- ロールを自動的に使用可能または使用禁止にする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 Databaseではエンタープライズ・ユーザー(スキーマに依存しないユーザー)が提供されています。

エンタープライズ・ユーザー、つまりディレクトリ・サービスで管理されるユーザーは、共有データベース・スキーマを使用するため、データベース・ユーザーとして作成する必要はありません。管理コストを削減するために、管理者はディレクトリに1つのエンタープライズ・ユーザーを1回作成し、他の多数のユーザーもアクセスできる共有スキーマで、そのユーザーを指し示すことができます。

関連項目:

エンタープライズ・ユーザーの管理の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

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

アプリケーション設計の一部として、そのアプリケーションで作業するユーザーのタイプ、およびユーザーが担当のタスクを達成するために必要なアクセスのレベルを決定する必要があります。

内容は次のとおりです。

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

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

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

オブジェクト権限によって、エンド・ユーザーは、表、ビュー、順序、プロシージャ、ファンクション、パッケージなどのオブジェクトに対してアクションを実行できます。

表8-3に、オブジェクトの各タイプで使用できるオブジェクト権限の概要を示します。

表8-3 権限とスキーマ・オブジェクトとの関連

オブジェクト権限

表への適用

ビューへの適用

順序への適用

プロシージャへの適用(4)

ALTER

あり

なし

あり

なし

DELETE

あり

あり

なし

なし

EXECUTE

なし

なし

なし

あり

INDEX

あり脚注5

なし

なし

なし

INSERT

あり

あり

なし

なし

REFERENCES

ありあり(5)

なし

なし

なし

SELECT

あり

あり脚注6

あり

なし

UPDATE

あり

あり

なし

なし

脚注4 スタンドアロンのストアド・プロシージャ、関数およびパブリック・パッケージ構成

脚注5

ロールに付与できない権限

脚注6

スナップショットに対しても付与可能

関連項目:
スキーマ・オブジェクトの監査方法の詳細は、オブジェクト・アクションの監査を参照してください

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

アプリケーションの実装時およびテスト時には、必要な各ロールを作成する必要があります。

各ロールの使用例をテストし、データベースへのアクセス権がアプリケーション・ユーザーに正しく付与されることを確認します。テスト終了後は、アプリケーションの管理者と共同で各ユーザーに適切なロールが割り当てられていることを確認します。

表8-4に、表8-3で示したオブジェクト権限によって許可されるSQL文を示します。

表8-4 データベース・オブジェクト権限によって許可される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文の監査方法の詳細は、オブジェクト・アクションの監査も参照してください。

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

プロトコル・エラーによる不正パケットの処理や認証エラーの上限の構成など、パラメータを使用してセキュリティを管理できます。

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

- 不正パケット受信後のサーバー実行の制御

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

- データベース・バージョン・バナーの表示構成

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

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

SEC_PROTOCOL_ERROR_TRACE_ACTION初期化パラメータで、プロトコル・エラーが発生したときにトレース・ファイルをどのように管理するかを制御します。

サーバーが不正なパケット、順序に誤りがあるパケット、プライベートまたは未使用のリモート・プロシージャ・コールを受信した場合、Oracle Call Interface(OCI)やTwo-Task Common(TTC)などのネットワーキング通信ユーティリティでは、スタック・トレースおよびヒープ・ダンプを格納する大規模なディスク・ファイルを生成できます。

通常、このディスク・ファイルは、非常に大規模になる可能性があります。侵入者は、サーバーに不正なパケットを繰り返し送信し、ディスクあふれやサービス拒否(DOS)攻撃を発生させることで、システムを使用できないようにする可能性があります。認証されていないクライアントが、この種の攻撃を仕掛ける可能性もあります。

これらの攻撃は、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

不正パケット受信後のサーバー実行の制御

SEC_PROTOCOL_ERROR_FURTHER_ACTION初期化パラメータは、サーバーで不正パケットを受信した後のサーバー実行を制御します。

ただし、これによって、ディスクあふれまたはサービス拒否攻撃を発生させる可能性のある不正なパケットを、サーバーがさらに受信する可能性があります。

- サーバーが悪意のあるクライアントから不正なパケットを受信しているときに、サーバー・プロセスの実行を詳細に制御するには、SEC_PROTOCOL_ERROR_FURTHER_ACTION初期化パラメータを次の値のいずれかに設定します。

- Continue(デフォルト設定): サーバーの実行を継続します。ただし、サーバーがさらに攻撃を受ける可能性があることに注意してください。
例:

SEC_PROTOCOL_ERROR_FURTHER_ACTION = Continue

- (Delay,m): クライアントをm秒間遅延させます(サーバーが次のリクエストを同じクライアント接続から受け付けるまで)。この設定により悪意のあるクライアントはサーバー・リソースを過剰使用できなくなります。正当なクライアントのパフォーマンスも低下しますが、引き続き機能します。この設定を入力する場合は、カッコで囲みます。
例:

SEC_PROTOCOL_ERROR_FURTHER_ACTION = (Delay,3)

ALTER SYSTEMまたはALTER SESSION SQL文を使用してSEC_PROTOCOL_ERROR_FURTHER_ACTIONを設定している場合は、Delay設定を一重引用符または二重引用符で囲む必要があります。

ALTER SYSTEM SEC_PROTOCOL_ERROR_FURTHER_ACTION = '(Delay,3)';

- (Drop,n): クライアント接続は、n個の不正パケットを受信した後に強制的に終了します。この設定を使用すると、トランザクションの損失など、クライアントを犠牲にしてサーバー自体を保護できます。ただし、クライアントは再度接続して、同じ操作を再試行できます。この設定はカッコで囲みます。
例:

SEC_PROTOCOL_ERROR_FURTHER_ACTION = (Drop,10)

Delay設定と同様に、ALTER SYSTEMまたはALTER SESSIONを使用してこの設定を変更している場合は、Drop設定を一重引用符または二重引用符で囲む必要があります。

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

SEC_MAX_FAILED_LOGIN_ATTEMPTS初期化パラメータに設定された認証試行回数を超過すると、確立できなかった接続がデータベースで削除されます。

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に正確なデータベース・バージョンが表示されます。この例ではリリース12.1.0.0です。

Oracle Database 12c Enterprise Edition Release 12.1.0.0 - Production

今後、たとえばOracle Databaseリリース12.2.0.2をインストールした場合は、次のバナーが表示されます。

Oracle Database 12c Enterprise Edition Release 12.2.0.2 - Production

ただし、同じリリースでこのパラメータをNOに設定すると、このバナーは制限されて、リリース12.2で開始する次の固定テキストが表示されるため、12.2.0.2ではなく12.2.0.0.0と表示されます。

Oracle Database 12c Release 12.2.0.0.0 - Production

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

SEC_USER_UNAUTHORIZED_ACCESS_BANNERおよびSEC_USER_AUDIT_ACTION_BANNER初期化パラメータで、不正アクセスやユーザーの監査に関するバナーの表示を制御します。

不正なアクセスおよびユーザー・アクション監査をユーザーに警告するには、バナーを作成して構成する必要があります。この通知は、クライアント・アプリケーションがデータベースにログインすると使用可能になります。

- これらのバナーを構成して表示するには、データベース・サーバー側で次のsqlnet.oraパラメータを設定して、バナー情報が含まれるテキスト・ファイルを指し示します。

- SEC_USER_UNAUTHORIZED_ACCESS_BANNER。次に例を示します。

SEC_USER_UNAUTHORIZED_ACCESS_BANNER = /opt/Oracle/12c/dbs/unauthaccess.txt

- SEC_USER_AUDIT_ACTION_BANNER。次に例を示します。

SEC_USER_AUDIT_ACTION_BANNER = /opt/Oracle/12c/dbs/auditactions.txt

デフォルトでは、これらのパラメータは設定されません。さらに、バナー・テキストに使用される文字数には512バイトの制限があることを注意してください。

これらのパラメータを設定したら、これらのバナーを取得してエンドユーザーに表示するように、Oracle Call Interfaceアプリケーションで適切なOCI APIを使用する必要があります。

第III部 データへのアクセス制御

第III部では、データへのアクセスの制御方法について説明します。

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

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

- 透過的機密データ保護の使用

- 手動によるデータ暗号化

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

アプリケーション・コンテキストはユーザーIDを格納します。このIDを使用して、ユーザーによるデータベースのデータへのアクセスを可能または不可にすることができます。

内容は次のとおりです。

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

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

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

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

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

- アプリケーション・コンテキストのデータ・ディクショナリ・ビュー

関連項目:

アプリケーション・コンテキスト値の監査

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

アプリケーション・コンテキストには、ユーザーがデータに対して保持するアクセスを制御する場合に多くのメリットがあります。

内容は次のとおりです。

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

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

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

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

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

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

アプリケーション・コンテキストにより、Oracle Databaseは認証中にデータベース・ユーザーと非データベース・ユーザーに関する情報を入手できます。

アプリケーション・コンテキストとは、Oracle Databaseがメモリーに格納する名前と値のペアです。アプリケーション・コンテキストには、ネームスペースと呼ばれるラベル(たとえば、従業員IDを取得するアプリケーション・コンテキストはempno_ctx)があります。

コンテキスト内は名前と値のペア(結合配列)です。名前は、値を保持するメモリー内の場所を指定します。アプリケーションはアプリケーション・コンテキストを使用して、ユーザーに関するセッション情報(ユーザーIDまたは他のユーザー固有の情報など)またはクライアントIDにアクセスして、その情報をデータベースに安全に引き渡すことができます。

この情報を使用して、ユーザーがアプリケーションを通じてデータにアクセスできるようにしたりアクセスできないようにできます。アプリケーション・コンテキストを使用して、データベース・ユーザーと非データベース・ユーザーの両方を認証できます。

関連項目:

アプリケーション・コンテキスト値の監査

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

アプリケーション・コンテキストには2つのコンポーネントがあり、名前と値のペアを構成します。

これらのコンポーネントは次のとおりです。

- 名前:値に関連付けられている属性セットの名前を示します。たとえば、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)コールを使用してアプリケーション・コンテキストを設定することもできます。

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

Oracle Databaseではアプリケーション・コンテキスト値が保護データ・キャッシュに格納されます。

このキャッシュはユーザー・グローバル領域(UGA)またはシステム("共有"と呼ばれる場合もある)グローバル領域(SGA)にあります。格納されたアプリケーション・コンテキストの値はセッション中に取得されます。アプリケーション・コンテキストには、このデータ・キャッシュ内の値が格納されるため、アプリケーションのパフォーマンスが向上します。アプリケーション・コンテキストは単独で使用でき、Oracle Virtual Private Databaseポリシーまたはその他のファイングレイン・アクセス制御ポリシーと併用することもできます。アプリケーション・コンテキストと仮想プライベート・データベース・ポリシーの併用については、Oracle Virtual Private Databaseでのアプリケーション・コンテキストの使用を参照してください。

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

ほとんどのアプリケーションには、アプリケーション・コンテキストに使用可能なある種の情報が含まれています。

たとえば、ORDER_NUMBER列とCUSTOMER_NUMBER列を備えた表を使用する受注管理アプリケーションでは、それらの列の値をセキュリティ属性として使用して、顧客によるアクセスをその顧客のIDに基づいて顧客自身の注文のみに制限できます。

アプリケーション・コンテキストは、次の目的で使用されます。

- ファイングレイン・アクセス・コントロールの規定(Oracle Virtual Private Databaseポリシーなどで)

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

- アプリケーションに対する強力なセキュリティの規定(アプリケーション・コンテキストはユーザーではなくトラステッド・プロシージャによって制御されるため)

- アプリケーションがファイングレイン監査やPL/SQL条件文またはループで使用する際に必要な属性に対して、保護データ・キャッシュとしての機能を果すことによるパフォーマンスの向上
このキャッシュによって、これらの属性が必要になるたびにデータベースに問い合せるというオーバーヘッドが軽減されます。アプリケーションはセッション・データを表から繰り返し取得する必要がなく、このデータがアプリケーション・コンテキストによってキャッシュに格納されるため、アプリケーションのパフォーマンスが大幅に向上します。

- アプリケーションで定義、変更およびアクセスできる名前と値のペアの保持領域として機能

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

Oracle Databaseでは、アプリケーション・コンテキスト・パッケージの影響を受けるすべてのエディションでアプリケーション・コンテキストが設定されます。

アプリケーション・コンテキストで設定される値は、アプリケーション・コンテキストが影響するすべてのエディションで表示されます。データベース内のすべてのエディション、およびそれが使用可能であるかどうかを検索するには、ALL_EDITIONSデータ・ディクショナリ・ビューを問い合せます。

関連項目:

エディションの詳細は、『Oracle Database開発ガイド』を参照してください。

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

アプリケーション・コンテキストには、3種類の一般的なカテゴリがあります。

カテゴリは次のとおりです。

- データベース・セッション・ベースのアプリケーション・コンテキスト。このタイプのアプリケーション・コンテキストは、データベース・ユーザー・セッション(つまりUGA)のキャッシュに格納されているデータを取得します。データベース・セッション・ベースのアプリケーション・コンテキストは、3つのカテゴリに分類されます。

- ローカルで初期化。ユーザーのセッションに対してアプリケーション・コンテキストをローカルで初期化します。

- 外部で初期化。Oracle Call Interface(OCI)アプリケーション、ジョブ・キュー・プロセスまたは接続ユーザーのデータベース・リンクからアプリケーション・コンテキストを初期化します。

- グローバルに初期化。LDAPディレクトリなどの集中格納場所から属性と値を使用します。

このタイプのアプリケーション・コンテキストについては、「データベース・セッション・ベースのアプリケーション・コンテキストの使用」を参照してください。

- グローバル・アプリケーション・コンテキスト。このタイプは、システム・グローバル領域(SGA)に格納されるデータを取得するため、3層アーキテクチャの中間層アプリケーションなど、セッションを使用しないアプリケーションに対して使用できます。グローバル・アプリケーション・コンテキストは、セッション・コンテキストをセッション間で、たとえば接続プールの実装を通じて共有する場合に便利です。
このタイプについては、「グローバル・アプリケーション・コンテキスト」を参照してください。

- クライアント・セッション・ベースのアプリケーション・コンテキスト。このタイプのアプリケーション・コンテキストは、クライアント側のOracle Call Interface関数を使用してユーザー・セッション・データを設定し、次に、必要なセキュリティ・チェックを実行してユーザー・アクセスを制限します。
このタイプについては、「クライアント・セッション・ベースのアプリケーション・コンテキストの使用」を参照してください。

表9-1に、異なる種類のアプリケーション・コンテキストの要約を示します。

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

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

UGAへの格納

SGAへの格納

接続ユーザー・データベース・リンクのサポート

ユーザーのアプリケーション・コンテキストの集中保管のサポート

セッションを使用しない複数層アプリケーションのサポート

ローカルで初期化されるデータベース・セッション・ベースのアプリケーション・コンテキスト

あり

なし

なし

なし

なし

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

あり

なし

あり

なし

なし

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

あり

なし

なし

あり

なし

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

なし

あり

なし

なし

あり

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

あり

なし

あり

なし

あり

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

データベース・セッション・ベースのアプリケーション・コンテキストを使用すると、ユーザーのセッション・ベースの情報を取得できます。

内容は次のとおりです。

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

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

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

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

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

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

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

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

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

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

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

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

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

データベース・セッション・ベースのアプリケーション・コンテキストは、データベース・ユーザーのセッション情報を取得します。

このタイプのアプリケーション・コンテキストは、Oracle Database内でPL/SQLプロシージャを使用し、管理の対象となるデータを取得、設定および保護します。

注意:

ユーザーがアプリケーション・ユーザー(つまり、データベースに存在しないユーザー)の場合は、グローバル・アプリケーション・コンテキストの使用を考慮してください。詳細は、グローバル・アプリケーション・コンテキストを参照してください。

データベース・セッション・ベースのアプリケーション・コンテキストは、Oracle Databaseの中で完全管理されます。Oracle Databaseが値を設定し、ユーザーがセッションを終了すると、キャッシュに保管されたアプリケーション・コンテキスト値を自動的に消去します。ユーザー接続が異常終了すると(たとえば停電)、PMONバックグラウンド・プロセスはアプリケーション・コンテキスト・データをクリーン・アップします。アプリケーション・コンテキストをキャッシュから消去する必要はありません。

アプリケーション・コンテキストをOracle Databaseで管理する利点は、アプリケーション・コンテキストを集中管理できる点です。このデータベースにアクセスするアプリケーションは、このアプリケーション・コンテキストを使用して、そのアプリケーションに対するユーザーのアクセスを許可または防止する必要があります。これによって、パフォーマンス向上とセキュリティ強化の両方の利点が得られます。

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

データベース・セッション・ベースのアプリケーション・コンテキストは、コンテキストのデータを取得および設定して、ユーザーがログインするときにこのコンテキストを設定します。

データベース・セッション・ベースのアプリケーション・コンテキストを作成して使用するには、アプリケーション・コンテキスト、データの取得とコンテキストの設定を実行するプロシージャ、およびユーザーのログイン時にコンテキストを設定する手段の3つのコンポーネントを使用する必要があります。

- アプリケーション・コンテキスト。アプリケーション・コンテキストを作成するには、CREATE CONTEXT SQL文を使用します。この文は、アプリケーション・コンテキスト(ネームスペース)名を設定し、セッション・データを取得してアプリケーション・コンテキストを設定するように設計されたPL/SQLプロシージャに対して、その名前を関連付けます。

- データの取得とコンテキストの設定を実行するPL/SQLプロシージャ。このプロシージャで実行する必要があるタスクについては、データベース・セッション・ベースのアプリケーション・コンテキストを管理するパッケージの概要を参照してください。理想的には、必要に応じて他のプロシージャ(タスクのエラー・チェックなど)を挿入できるように、このプロシージャは1つのパッケージ内に作成します。

- ユーザーのログイン時にアプリケーション・コンテキストを設定する手段。アプリケーション・コンテキストを使用するアプリケーションにログインするユーザーは、そのアプリケーション・コンテキストを設定するPL/SQLパッケージを実行する必要があります。そのためには、ユーザーがログインするたびに起動するログイン・トリガーを使用するか、この機能をアプリケーションに埋め込むことができます。

ローカルで初期化されるデータベース・セッション・ベースのアプリケーション・コンテキストの作成方法と使用方法は、例: データベース・セッション・ベースのアプリケーション・コンテキストの作成と使用を参照してください。

さらに、セッション・ベースのアプリケーション・コンテキストは、外部で、またはグローバルに初期化できます。いずれの場合も、コンテキスト情報はユーザー・セッションに格納されます。

- 外部での初期化。この初期化は、OCIインタフェース、ジョブ・キュー・プロセスまたは接続ユーザーのデータベース・リンクから発生します。詳細は、データベース・セッション・ベースのアプリケーション・コンテキストの外部での初期化を参照してください。

- グローバルな初期化。この初期化では、LDAPディレクトリなどの集中格納場所から属性と値を使用します。詳細は、データベース・セッション・ベースのアプリケーション・コンテキストのグローバルな初期化を参照してください。

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

データベース・セッション・ベースのアプリケーション・コンテキストは、ユーザーのセッション情報を格納する名前付きのオブジェクトです。

内容は次のとおりです。

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

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

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

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

データベース・ユーザー・セッション(UGA)は、ユーザーが作成したネームスペースを使用して、セッション・ベースのアプリケーション・コンテキストを格納します。

各アプリケーション・コンテキストには一意の属性が必要で、1つのネームスペースに属している必要があります。つまり、コンテキスト名は、スキーマ内のみでなくデータベース内でも一意である必要があります。

アプリケーション・コンテキストを作成するには、CREATE ANY CONTEXTシステム権限が必要です。アプリケーション・コンテキストを削除する場合は、DROP CONTEXT文を使用するためにDROP ANY CONTEXT権限が必要になります。

アプリケーション・コンテキストの所有権については、CREATE ANY CONTEXT権限とDROP ANY CONTEXT権限を付与されたユーザーがそのアプリケーション・コンテキストを作成および削除できた場合でも、SYSスキーマが所有しています。Oracle Databaseは、作成したスキーマ・アカウントにコンテキストを関連付けますが、このユーザーを削除した場合、コンテキストはそれでもSYSスキーマの中に存在します。ユーザーSYSであれば、アプリケーション・コンテキストを削除できます。

既存のアプリケーション・コンテキストの名前は、次の問合せを実行して検索できます。

SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE OBJECT_TYPE ='CONTEXT';

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

CREATE CONTEXT SQL文で、データベース・セッション・ベースのアプリケーション・コンテキストを作成できます。

データベース・セッション・ベースのアプリケーション・コンテキストを作成する場合、そのアプリケーション・コンテキストのネームスペースを作成し、ユーザーのセッション情報を保持する名前と値のペアを管理するPL/SQLパッケージとそのネームスペースを関連付ける必要があります。PL/SQLパッケージは、コンテキストの作成時には不要ですが、実行時には存在している必要があります。

- データベース・セッション・ベースのアプリケーション・コンテキストを作成するには、CREATE CONTEXT SQL文を使用します。
例:

CREATE CONTEXT empno_ctx USING set_empno_ctx_pkg;

この例の説明は、次のとおりです。

- empno_ctxはコンテキスト・ネームスペースです。

- set_empno_ctx_pkgは、そのempno_ctxネームスペースの属性を設定するパッケージです(コンテキストの作成時には不要です)。このアプリケーション・コンテキストで使用可能なパッケージの作成方法の例は、手順3: セッション・データを取得してアプリケーション・コンテキストを設定するパッケージの作成を参照してください。

コンテキストを作成するときは、そのコンテキストの名前/値の属性をCREATE CONTEXT文に設定しないでください。かわりに、これらは、アプリケーション・コンテキストに関連付けるPL/SQLパッケージに設定してください。これは、不正なユーザーによって、適切な属性の検証なしにコンテキスト属性が変更されないようにするためです。このパッケージがアプリケーション・コンテキストと同じコンテナにあることを確認してください。たとえば、アプリケーション・コンテキストをPDBに作成した場合、PL/SQLパッケージはそのPDBに存在する必要があります。

注意:

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 SQL関数を使用できます。このSYS_CONTEXT関数は、コンテキストのネームスペースに関連付けられているパラメータの値を戻します。この関数は、SQL文とPL/SQL文の両方で使用できます。通常は、組み込まれているUSERENVネームスペースを使用してユーザーのセッション情報を取得します。SYS_SESSION_ROLESネームスペースを使用して、セッションに対して指定したロールが現在有効化されているかどうかを示すこともできます。(SYS_CONTEXT関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。)

- CREATE CONTEXTで作成したアプリケーション・コンテキストの名前/値の属性の設定。アプリケーション・コンテキストの名前/値の属性の設定には、DBMS_SESSION.SET_CONTEXTプロシージャを使用できます。この名前/値の属性には、ユーザーID、IPアドレス、認証モード、アプリケーション名などの情報を格納できます。設定した属性の値は、再設定するまで、またはユーザーがセッションを終了するまでそのまま残ります。次のことに注意してください。

- ネームスペース内のパラメータの値がすでに設定されている場合は、SET_CONTEXTによってこの値が上書きされます。

- コンテキストの値が変更された場合、その内容はただちに反映され、SYS_CONTEXTファンクションによって値を取得する後続のコールでは、最新の値が戻されます。

- ユーザーによる実行。パッケージを作成した後、ログインする場合ユーザーはそのパッケージを実行する必要があります。ユーザーがログインするときパッケージを自動的に実行するためのログイン・トリガーを作成するか、この機能をアプリケーションに埋め込むことができます。アプリケーション・コンテキスト・セッション値はユーザーがセッションを終了すると自動的に消去されるので、セッション・データを手動で削除する必要はありません。

プロシージャはトラステッド・プロシージャであることに注意してください。ユーザーが自分独自のアプリケーション・コンテキスト属性値を設定できないように設計されています。ユーザーはプロシージャを実行しますが、プロシージャがアプリケーション・コンテキスト値を設定します、ユーザーではありません。

データベース・セッション・ベースのアプリケーション・コンテキストの作成方法は、例: データベース・セッション・ベースのアプリケーション・コンテキストの作成と使用を参照してください。

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

SYS_CONTEXTファンクションを使用して、アプリケーション・コンテキストのセッション情報を取得できます。

SYS_CONTEXT関数には、ログインしたユーザーのカレント・セッションを表すデフォルト・ネームスペースUSERENVがあります。SYS_CONTEXTを使用すると、ユーザー・ホスト・コンピュータID、ホストIPアドレス、オペレーティング・システム・ユーザー名など、ユーザーに関する様々な種類のセッション・ベースの情報を取得できます。セッション・データを設定ではなく、取得するにはUSERENVのみを使用することに注意してください。事前定義の属性は、『Oracle Database SQL言語リファレンス』のPL/SQLファンクションの説明でリストされています。

- セッション情報を取得するには、ネームスペースとパラメータを設定し、オプションでSYS_CONTEXTファンクションの長さの値を設定します。
例:

SYS_CONTEXT ('USERENV','HOST')

PL/SQLファンクションのSYS_CONTEXTの構文は、次のとおりです。

SYS_CONTEXT ('namespace','parameter'[,length])

次のように値を指定します。

- namespaceはアプリケーション・コンテキストの名前です。文字列、または文字列として評価される式を指定できます。SYS_CONTEXTファンクションは、現時点でコンテキストのネームスペースに関連付けられているパラメータの値を戻します。ネームスペース内のパラメータの値がすでに設定されている場合は、SET_CONTEXTによってこの値が上書きされます。

- parameterは、namespaceアプリケーション・コンテキスト内のパラメータです。この値には、文字列または式を指定できます。

- lengthは戻り型のデフォルト最大サイズ(256バイト)ですが、最大で4000バイトの値を指定して長さを変更できます。NUMBERデータ型の値を入力するか、NUMBERに明示的に変換できる値を入力します。SYS_CONTEXT戻り型のデータ型はVARCHAR2です。この設定はオプションです。

注意:

USERENVアプリケーション・コンテキスト・ネームスペースは、Oracle Databaseの以前のリリースで提供されていたUSERENV関数にかわる機能です。

SYS_CONTEXT設定の確認

DUAL表に格納されるSYS_CONTEXT設定を確認できます。

DUAL表はデータ・ディクショナリ内の小さい表で、既知の結果を保証するためにOracle Databaseおよびユーザーが記述したプログラムから参照できます。この表には、DUMMYという列と、値Xが格納されている行があります。

- SYS_CONTEXT設定を確認するには、DUAL表に対してSELECT SQL文を発行します。

たとえば、ログインしたホスト・コンピュータを確認する場合、EMP_USERSの下のSHOBEEN_PCホスト・コンピュータにログインしたと想定しています。

SELECT SYS_CONTEXT ('USERENV', 'HOST') FROM DUAL;

SYS_CONTEXT(USERENV,HOST)
-------------------------
EMP_USERS\SHOBEEEN_PC

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

SYS_CONTEXTファンクションはデータベース・リンクと一緒に使用できます。

ユーザー・セッション内のSQL文にデータベース・リンクが含まれている場合は、そのデータベース・リンクのホスト・コンピュータでSYS_CONTEXT関数が実行され、そのホスト・コンピュータにあるコンテキスト情報が取得されます。

リモートのPL/SQLプロシージャ・コールがデータベース・リンクで実行されている場合は、そのプロシージャ内部のすべてのSYS_CONTEXT関数が、そのリンクの宛先データベースで実行されます。

この場合、データベース・リンクの宛先サイトで使用できるのは、外部で初期化されたアプリケーション・コンテキストのみです。セキュリティ上の理由から、データベース・リンクの開始サイトから宛先サイトに伝播されるのは、外部で初期化されたアプリケーション・コンテキストのみです。

セッション情報を設定するためのDBMS_SESSION.SET_CONTEXT

SYS_CONTEXTでユーザーのセッション・データを取得した後、ユーザー・セッションからアプリケーション・コンテキスト値を設定できます。

コンテキスト値を設定するには、DBMS_SESSION.SET_CONTEXTプロシージャを使用します。DBMS_SESSION PL/SQLパッケージに対するEXECUTE権限を所有している必要があります。

DBMS_SESSION.SET_CONTEXTの構文は、次のとおりです。

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.SET_CONTEXTプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

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

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

プロシージャでDBMS_SESSION.SET_CONTEXT文を使用して、アプリケーション・コンテキストの値を設定できます。

例9-1に、empno_ctxアプリケーション・コンテキストの属性を作成する単純なプロシージャの作成方法を示します。

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

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属性の値を指定します。ここでは、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

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

データベース・インスタンスにログインする場合、ユーザーは、データベース・セッションのアプリケーション・コンテキスト・パッケージを実行する必要があります。

これを自動的に処理するようにログイン・トリガーを作成できます。パッケージを実行するためのEXECUTE権限をユーザーに付与する必要はありません。

次のことに注意してください。

- ログイン・トリガーによって呼び出されたPL/SQLパッケージ・プロシージャに未処理例外があるか(たとえばセキュリティ・チェックに失敗したために)なんらかの例外を発生すると、ログイン・トリガーは失敗します。ログイン・トリガーに失敗すると、ログインは失敗し、つまりユーザーはデータベースにログインする権限が拒否されます。

- ログイン・トリガーがパフォーマンスに影響を与える可能性があります。また、ログイン・トリガーは、最初にサンプル・スキーマ・ユーザーでテストしてから、データベース用に作成してください。これによって、エラーがあった場合は簡単に修正できます。

- 会計帳簿の変更や職階の変更が頻繁にある場合は注意が必要です。この場合、新しい属性値はすぐに選択できない可能性があるため、カーソルの再解析を強制実行して、新しい属性値を選択する必要があります。

注意:

ユーザー・コンテキスト(EMPNO、GROUP、MANAGERなどの情報)は、ユーザーがデータにアクセスする前に設定されるため、ログイン・トリガーを使用できます。

例: 単純なログイン・トリガーの作成

CREATE TRIGGER文で簡単なログイン・トリガーを作成できます。

例9-2に、PL/SQLプロシージャを実行する単純なログイン・トリガーを示します。

例9-2 単純なログイン・トリガーの作成

CREATE OR REPLACE TRIGGER set_empno_ctx_trig AFTER LOGON ON DATABASE
BEGIN
sec_mgr.set_empno_ctx_proc;
END;

例: 本番環境用のログイン・トリガーの作成

CREATE TRIGGER文で、本番環境のログイン・トリガーを作成できます。

例9-3は、WHEN OTHERS例外を使用するログイン・トリガーの作成方法を示しています。一方、PL/SQLロジックにエラーが発生して未処理例外を引き起こす場合は、データベースへのすべての接続がブロックされます。

この例は、セキュリティ管理者のスキーマの表にエラーを書き込むWHEN OTHERS例外を示しています。本番環境では、こちらのほうが、出力をユーザー・セッションへ送信することでセキュリティ攻撃を受けやすくなるよりも安全です。

例9-3 本番環境用のログイン・トリガーの作成

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;
/

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

CREATE TRIGGER文で、開発環境のログイン・トリガーを作成できます。

例9-4に、同じログイン・トリガーを開発環境用に作成する方法を示します。この場合、エラーをデバッグのためにユーザー・セッションに出力できます。

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

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;
/

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

このチュートリアルでは、データベースにログインを試行するデータベース・ユーザーの従業員IDをチェックするアプリケーション・コンテキストの作成方法を示します。

内容は次のとおりです。

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

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

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

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

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

- 手順6: このチュートリアルのコンポーネントの削除

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

このチュートリアルを開始するには、必要なデータベース・アカウントを作成し、SCOTTユーザー・アカウントがアクティブであることを確認する必要があります。

1. ユーザーSYSとしてログインし、SYSDBA管理権限を使用して接続します。

sqlplus sys as sysdba
Enter password: password

2. マルチテナント環境で、適切なPDBに接続します。

例:

CONNECT SYS@hrpdb AS SYSDBA
Enter password: password

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. sysadmin_ctxローカル・ユーザー・アカウントを作成します。このアカウントは、データベース・セッション・ベースのアプリケーション・コンテキストを管理します。

CREATE USER sysadmin_ctx IDENTIFIED BY password;
GRANT CREATE SESSION, CREATE ANY CONTEXT, CREATE PROCEDURE, CREATE TRIGGER, ADMINISTER DATABASE TRIGGER TO sysadmin_ctx;
GRANT READ ON HR.EMPLOYEES TO sysadmin_ctx;
GRANT EXECUTE ON DBMS_SESSION TO sysadmin_ctx;

「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。

4. Lisa Ozerに対して、次のユーザー・アカウントを作成します。HR.EMPLOYEES表には、lozerというLisa Ozerの電子メール・アカウントがあります。

GRANT CREATE SESSION TO LOZER IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。

5. この例ではサンプル・ユーザーSCOTTも使用するため、DBA_USERSデータ・ディクショナリ・ビューを問い合せて、SCOTTのアカウント・ステータスがOPENになっていることを確認します。

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: データベース・セッション・ベースのアプリケーション・コンテキストの作成

sysadmin_ctxユーザーとして、データベース・セッション・ベースのアプリケーション・コンテキストを作成します。

1. sysadmin_ctxでSQL*Plusにログインします。

CONNECT sysadmin_ctx -- Or, CONNECT sysadmin_ctx@hrpdb
Enter password: password

2. 次の文を使用してアプリケーション・コンテキストを作成します。

CREATE CONTEXT empno_ctx USING set_empno_ctx_pkg;

ユーザーsysadmin_ctxがこのアプリケーション・コンテキストを作成した場合でも、SYSスキーマがこのコンテキストを所有することに注意してください。

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

次に、セッション・データを取得してアプリケーション・コンテキストを設定するPL/SQLパッケージを作成する必要があります。

- パッケージを作成するには、CREATE OR REPLACE PACKAGE文を使用します。

例9-5に、セッション・データを取得してアプリケーション・コンテキストを設定するために必要なパッケージの作成方法を示します。パッケージを作成する前に、ユーザーsysadmin_ctxでログインしていることを確認してください。(最初の行のCREATE OR REPLACEの前にカーソルを置くことで、このテキストをコピーして貼り付けることができます。)

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

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変数に格納された値に設定します。

要約すると、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ユーザーとして、set_empno_ctx_pkg.set_empnoパッケージ・プロシージャのログオン・トリガーを作成します。

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 -- Or, CONNECT lozer@hrpdb
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 -- Or, CONNECT SCOTT@hrpdb
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を使用できます。詳細は、Oracle Virtual Private Databaseを使用したデータ・アクセスの制御を参照してください。

手順6: このチュートリアルのコンポーネントの削除

このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。

1. SYSDBA管理権限を持つSYSとして接続します。

CONNECT SYS AS SYSDBA -- Or, CONNECT SYS@hrpdb 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)に格納されるため、パフォーマンスが向上します。

内容は次のとおりです。

- データベース・セッション・ベースのアプリケーション・コンテキストの外部による初期化について

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

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

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

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

データベース・セッション・ベースのアプリケーション・コンテキストの外部による初期化について

セッション・ベースのアプリケーション・コンテキストを外部で初期化するには、特別な種類のネームスペースを使用する必要があります。

このネームスペースは外部リソースからの属性値の初期化を受け入れ、ローカル・ユーザー・セッションに格納する必要があります。

アプリケーション・コンテキストは外部で初期化することによりUGAに格納されて、属性をセッションから別のセッションへ自動伝播できるようになるため、パフォーマンスが向上します。接続ユーザー・データベース・リンクをサポートするのは、OCIベースの外部ソースから初期化されたアプリケーション・コンテキストのみです。

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

Oracle Databaseでは、アプリケーションのユーザーからデフォルト値を取得して使用できます。

ユーザーからデフォルトを取得することが必要な場合があります。最初、これらのデフォルト値はヒントまたはプリファレンスとして機能し、検証後にトラステッド・コンテキストになります。同様に、クライアントでは、一部のデフォルト値を初期化してから、ログイン・イベント・トリガーまたはアプリケーションを使用して値の検証を行うと便利です。

ジョブ・キューに関しては、ジョブ発行ルーチンで、ジョブの発行時に設定されたコンテキストを記録し、バッチ・ジョブの実行時にそのコンテキストをリストアします。コンテキストの整合性を保持するために、ジョブ・キューは、コンテキストを設定する特定のPL/SQLパッケージを回避できません。一方、外部で初期化されたアプリケーション・コンテキストは、コンテキスト値の初期化をジョブ・キュー・プロセスから受け入れます。

リモート・セッションへのコンテキストの自動伝播によって、セキュリティ上の問題が発生する場合があります。開発者または管理者は、ユーザーのログイン時にログイン・トリガーを使用してコンテキストを再設定することで、特定のPL/SQLプロシージャ以外のリソースからデフォルト値を取得するコンテキストを効果的に処理できます。

他の外部リソースからの値

アプリケーション・コンテキストは、外部リソースを介して属性と値の初期化を受け入れることができます。

このような外部リソースには、Oracle Call Interface(OCI)インタフェース、ジョブ・キュー・プロセスまたはデータベース・リンクなどが含まれます。

外部で初期化されたアプリケーション・コンテキストでは、次の機能が提供されます。

- リモート・セッションの場合は、外部で初期化されたアプリケーション・コンテキスト・ネームスペースにあるコンテキスト値を自動的に伝播します。

- ジョブ・キューの場合は、外部で初期化されたアプリケーション・コンテキスト・ネームスペースにあるコンテキスト値をリストアします。

- OCIインタフェースの場合は、外部で初期化されたアプリケーション・コンテキスト・ネームスペースにあるコンテキスト値を初期化するメカニズムを提供します。

Oracle Call Interfaceを使用しているクライアント・プログラムであればこのタイプのネームスペースの初期化は可能ですが、ログイン・イベント・トリガーを使用して値を検証できます。属性の値を解釈して信頼するかどうかはアプリケーションによって異なります。

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

CREATE CONTEXT SQL文で、外部化されたデータベース・セッション・ベースのアプリケーション・コンテキストを作成できます。

例9-6に、外部ソースから値を取得するデータベース・セッション・ベースのアプリケーション・コンテキストを作成する方法を示します。

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

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 Call Interfaceプログラマーズ・ガイド

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

データベース・セッション・ベースのアプリケーション・コンテキストをグローバルに初期化するには、統合された場所にコンテキストを格納します。これによって、LDAPディレクトリ内のこれらのタイプのコンテキストを使用できます。

内容は次のとおりです。

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

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

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

- データベース・セッション・ベースのアプリケーション・コンテキストのグローバルな初期化

データベース・セッション・ベースのアプリケーション・コンテキストのグローバルな初期化について

ユーザーのデータベース・セッション・ベースのアプリケーション・コンテキストは、集中格納場所を使用して格納できます。

集中格納場所を使用することでアプリケーションでは、初期化中にユーザーの識別情報に基づいてユーザー・コンテキストを設定できます。

特に、この機能では、Oracle Label Securityのラベルと権限がサポートされます。アプリケーション・コンテキストをグローバルに初期化すると、多数のユーザーとデータベースのコンテキストを簡単に管理できます。

たとえば、多くの組織では、LDAPベースのディレクトリでユーザー情報を集中管理する必要があります。エンタープライズ・ユーザー・セキュリティは、Oracle Internet Directoryでのユーザーと認可の集中管理をサポートします。ただし、Oracle Virtual Private Databaseの規定に使用するために、アプリケーションではLightweight Directory Access Protocol(LDAP)から追加の属性(ユーザーの職位、組織、物理的な位置など)を取得することが必要な場合があります。これらのタイプの属性は、アプリケーション・コンテキストをグローバルに初期化することで取得できます。

LDAPでのデータベース・セッション・ベースのアプリケーション・コンテキストの使用

グローバルに初期化されたアプリケーション・コンテキストは、拡張可能で効率的な標準ディレクトリ・アクセス・プロトコルであるLDAPを使用します。

LDAPディレクトリには、このアプリケーションが割り当てられているユーザーのリストが格納されます。Oracle Databaseでは、ディレクトリ・サービス(通常はOracle Internet Directory)を使用して、エンタープライズ・ユーザーを認証および認可します。

注意:

Microsoft Active DirectoryやSun MicrosystemsのSunONEなどのサード・パーティ製ディレクトリもディレクトリ・サービスとして使用できます。

orclDBApplicationContext LDAPオブジェクト(groupOfUniqueNamesのサブクラス)は、アプリケーション・コンテキスト値をディレクトリに格納します。アプリケーション・コンテキスト・オブジェクトの場所は、Human Resourcesの例に基づく図9-1で説明しています。

LDAPオブジェクトinetOrgPersonにより、一部の属性では複数のエントリが存在可能です。ただし、これらのエントリがデータベースにロードされ、SYS_LDAP_USER_DEFAULTコンテキスト・ネームスペースでアクセスされると、これらのエントリのうち最初のエントリだけが返されます。たとえば、ユーザーに対するinetOrgPersonオブジェクトでは、telephoneNumberに複数のエントリが可能です(そのため、ユーザーは複数の電話番号を保存できます)。SYS_LDAP_USER_DEFAULTコンテキスト・ネームスペースを使用すると、最初の電話番号だけが取得されます。

LDAP側では、アプリケーション・コンテキスト値のリストをデータベースに返すorclDBApplicationContext値を取得するための内部C関数が必要になります。この例では、HRはネームスペース、「Title」と「Project」は属性、「Manager」と「Promotion」が値です。

図9-1 LDAPディレクトリの情報ツリーにおけるアプリケーション・コンテキストの位置

グローバルに初期化されたデータベース・セッション・ベースのアプリケーション・コンテキストの動作

グローバルに初期化されたセキュア・アプリケーションを使用するには、エンタープライズ・ユーザー・セキュリティを最初に構成する必要があります。

次に、データベースとディレクトリのユーザーに対してアプリケーション・コンテキスト値を構成します。

グローバル・ユーザー(エンタープライズ・ユーザー)がデータベースに接続すると、エンタープライズ・ユーザー・セキュリティ機能によって、データベースに接続しているユーザーの識別情報が検証されます。認証後、グローバル・ユーザー・ロールとアプリケーション・コンテキストがディレクトリから取得されます。ユーザーがデータベースにログインするときは、グローバル・ロールと初期アプリケーション・コンテキストがすでに設定されています。

関連項目:

エンタープライズ・ユーザー・セキュリティの構成の詳細は、『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人以上のエンタープライズ・ユーザーに割り当てることができます。また、これらの属性は、エンタープライズ・ユーザーがログインすると自動的に取得され、アプリケーション・コンテキストの初期化にも使用されます。

関連項目:

- OCIインタフェース、ジョブ・キュー・プロセスまたはデータベース・リンクなど、外部リソースを介したローカル・アプリケーション・コンテキストの初期化に関する詳細は、データベース・セッション・ベースのアプリケーション・コンテキストの外部での初期化を参照してください

- Oracle Internet Directoryなどの集中化されたリソースを介したローカル・アプリケーション・コンテキストの初期化に関する詳細は、データベース・セッション・ベースのアプリケーション・コンテキストのグローバルな初期化を参照してください

- エンタープライズ・ユーザーの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

グローバル・アプリケーション・コンテキスト

グローバル・アプリケーション・コンテキストを使用して、Oracle Real Application Clusters環境などのデータベース・セッション間でアプリケーション値にアクセスできます。

内容は次のとおりです。

- グローバル・アプリケーション・コンテキストの概要

- グローバル・アプリケーション・コンテキストの使用方法

- グローバル・アプリケーション・コンテキストのコンポーネント

- Oracle Real Application Clusters環境でのグローバル・アプリケーション・コンテキスト

- グローバル・アプリケーション・コンテキストの作成

- グローバル・アプリケーション・コンテキストを管理するためのPL/SQLパッケージ

- クライアント・セッションIDを管理するための中間層アプリケーションへのコールの埋込み

- 例: クライアント・セッションIDを使用するグローバル・アプリケーション・コンテキストの作成

- グローバル・アプリケーション・コンテキスト・プロセス

グローバル・アプリケーション・コンテキストの概要

グローバル・アプリケーション・コンテキストを使用すると、アプリケーション・コンテキスト値を複数のデータベース・セッション(Oracle RACインスタンスを含む)にわたってアクセス可能にできます。

グローバル・アプリケーション・コンテキスト情報はシステム・グローバル領域(SGA: 共有グローバル領域でSGAと称する場合もあります)に格納されるため、3層アーキテクチャの中間層アプリケーションなど、セッションを使用しないアプリケーションに対して使用できます。

このようなアプリケーションでは、複数のユーザーがアプリケーションに対して認証され、通常は単一の識別情報としてデータベースに接続するため、セッション・ベースのアプリケーション・コンテキストを使用できません。グローバル・アプリケーション・コンテキストは、ユーザー・セッション単位ではなく一度に初期化されます。したがって、接続は接続プールから再利用されるため、パフォーマンスが向上します。

グローバル・アプリケーション・コンテキスト値は、ALTER SYSTEM FLUSH GLOBAL_CONTEXT SQL文を実行して消去できます。

グローバル・アプリケーション・コンテキストの使用方法

グローバル・アプリケーション・コンテキストには、3種類の一般的な使用方法があります。

使用方法は次のとおりです。

- 全データベース・ユーザーを対象にしてアプリケーションの値をグローバルに共有する必要がある場合。たとえば、特定の状況に基づいてアプリケーションへのアクセスを禁止することがあります。この場合、アプリケーション・コンテキストが設定する値はユーザーに固有の値ではなく、ユーザーのプライベート・データに基づく値でもありません。アプリケーション・コンテキストは、ある状況を定義して、実行中のアプリケーション・モジュールのバージョンなどを示します。

- 複数のアプリケーション間を移動する必要があるデータベース・ユーザーがいる場合。この場合、ユーザーの移動先となる第2のアプリケーションには、第1のアプリケーションとは異なるアクセス要件があります。

- 非データベース・ユーザー(つまり、データベースに認識されていないユーザー)を認証する必要がある場合。データベース・アカウントを持たないこのタイプのユーザーは、通常、Webアプリケーション経由で接続プールを使用して接続します。このようなアプリケーションでは、One Big Application User認証モデルを使用して、複数のユーザーを単一のユーザーとしてデータベースに接続します。このタイプのユーザーを認証するには、そのユーザーのクライアント・セッションIDを使用します。

グローバル・アプリケーション・コンテキストのコンポーネント

グローバル・アプリケーション・コンテキストはパッケージを使用して属性を管理し、中間層アプリケーションを使用してクライアント・セッション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文を使用できます。コンテキストの場所は、SYSスキーマ内になります。

内容は次のとおりです。

- グローバル・アプリケーション・コンテキストの所有権

- グローバル・アプリケーション・コンテキストの作成

グローバル・アプリケーション・コンテキストの所有権

グローバル・アプリケーション・コンテキストを所有できるのはSYSスキーマのみです。

グローバル・アプリケーション・コンテキストの所有権については、CREATE ANY CONTEXT権限とDROP ANY CONTEXT権限を付与されたユーザーがそのグローバル・アプリケーション・コンテキストを作成および削除できた場合でも、SYSスキーマが所有しています。

Oracle Databaseは、作成したスキーマ・アカウントにコンテキストを関連付けますが、このユーザーを削除した場合、コンテキストはそれでもSYSスキーマの中に存在します。ユーザーSYSであれば、アプリケーション・コンテキストを削除できます。

グローバル・アプリケーション・コンテキストの作成

ローカル・アプリケーション・コンテキストと同様、グローバル・アプリケーション・コンテキストもセキュリティ管理者のデータベース・スキーマで作成および格納されます。

グローバル・アプリケーション・コンテキストを作成するには、CREATE ANY CONTEXTシステム権限が必要であり、DROP CONTEXT文でコンテキストを削除するにはDROP ANY CONTEXT権限が必要になります。

- グローバル・アプリケーション・コンテキストを作成するには、CREATE CONTEXT SQL文を使用してグローバル・アプリケーション・コンテキストを作成し、ACCESSED GLOBALLY句をこのSQL文に含めます。

次に例を示します。

CREATE OR REPLACE CONTEXT global_hr_ctx USING hr_ctx_pkg ACCESSED GLOBALLY;

グローバル・アプリケーション・コンテキストを管理するためのPL/SQLパッケージ

DBMS_SESSION PL/SQLパッケージを使用して、グローバル・アプリケーション・コンテキストを管理できます。

内容は次のとおりです。

- グローバル・アプリケーション・コンテキストを管理するパッケージの概要

- エディションがグローバル・アプリケーション・コンテキストのPL/SQLパッケージの結果に与える影響

- DBMS_SESSION.SET_CONTEXTのusernameおよびclient_idパラメータ

- 例: 全データベース・ユーザーを対象としてグローバル・アプリケーション値を管理するためのパッケージ

- 全データベース・ユーザーを対象としたグローバル・アプリケーション・コンテキスト値の共有

- アプリケーション間を移動するデータベース・ユーザーのグローバル・コンテキスト

- 非データベース・ユーザーのグローバル・アプリケーション・コンテキスト

- 例: 非データベース・ユーザーのグローバル・アプリケーション・コンテキスト値を管理するためのパッケージ

- セッションをクローズする際のセッション・データの消去

関連項目:

DBMS_SESSIONパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

グローバル・アプリケーション・コンテキストを管理するパッケージの概要

グローバル・アプリケーション・コンテキストに関連付けるパッケージは、DBMS_SESSIONパッケージを使用してグローバル・アプリケーション・コンテキスト値の設定と消去を行います。

このプロシージャを使用するには、DBMS_SESSIONパッケージに対するEXECUTE権限が必要です。通常、このパッケージはセキュリティ管理者のデータベース・スキーマに作成および格納されます。DBMS_SESSIONパッケージはSYSスキーマの所有です。

ローカル・アプリケーション・コンテキストの設定に使用するPL/SQLパッケージとは異なり、ユーザー・セッション・データを取得するSYS_CONTEXT関数は挿入しません。グローバル・アプリケーション・コンテキストでは、接続しているすべてのユーザーにとって、セッションの所有者(USERENVコンテキストに記録される)は同じ所有者となるため、この関数を挿入する必要はありません。

プロシージャは、グローバル・アプリケーション・コンテキストのPL/SQLパッケージ内でいつでも実行できます。グローバル・アプリケーション・コンテキストに関連付けられているパッケージ・プロシージャを実行するために、ログイン・トリガーとログオフ・トリガーを作成する必要はありません。一般的に、パッケージ・プロシージャはデータベース・アプリケーション内から実行します。また、非データベース・ユーザーには、中間層アプリケーションを使用してクライアント・セッションIDを取得および設定します。

関連項目:

DBMS_SESSIONパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

エディションがグローバル・アプリケーション・コンテキストの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プロシージャは、グローバル・アプリケーション・コンテキストに使用するclient_idおよびusernameパラメータを提供します。

これらの設定の組合せによって、作成可能なグローバル・アプリケーション・コンテキストのタイプがどのように制御されるかについて、表9-2で説明します。

表9-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パラメータを設定します。

関連項目:

例: 全データベース・ユーザーを対象としてグローバル・アプリケーション値を管理するためのパッケージ

例: 全データベース・ユーザーを対象としてグローバル・アプリケーション値を管理するためのパッケージ

CREATE PACKAGE文で、全データベース・ユーザーを対象としてグローバル・アプリケーション値を管理できます。

例9-7に、全データベース・ユーザーを対象としてグローバル・アプリケーション・コンテキストを設定および消去するパッケージの作成方法を示します。

例9-7 全データベース・ユーザーを対象としてグローバル・アプリケーション値を管理するためのパッケージ

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'は、SET_CONTEXTプロシージャで、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
-----------

権限が不十分であることを示すエラー・メッセージがOracle Databaseで返された場合は、グローバル・アプリケーション・コンテキストが正しく作成されていることを確認してください。また、DBA_CONTEXTデータベース・ビューを問い合せて、設定が正しいこと(作成したスキーマからプロシージャがコールされていることなど)を確認してください。

NULLが戻る場合は、誤ってクライアント識別子を設定した可能性があります。クライアント識別子を消去するには、次のプロシージャを実行します。

EXEC DBMS_SESSION.CLEAR_IDENTIFIER;

アプリケーション間を移動するデータベース・ユーザーのグローバル・コンテキスト

アプリケーションに異なるアクセス要件がある場合でも、アプリケーション間を移動するデータベース・ユーザーはグローバル・アプリケーション・コンテキストを使用できます。

これを行うには、DBMS_SESSION.SET_CONTEXTプロシージャにusernameパラメータを含める必要があります。

このパラメータは、すべてのセッションを対象として同じスキーマを使用することを指定します。

次のDBMS_SESSION.SET_CONTEXTパラメータを使用できます。

- namespace

- attribute

- value

- username

Oracle Databaseは、username値を一致させることで、他のアプリケーションがアプリケーション・コンテキストを認識できるようにします。これによって、ユーザーは複数のアプリケーション間を移動できます。

client_id設定を省略すると、その値はデフォルトのNULLになります。これは、異なるアプリケーションで同じコンテキストを保持するデータベース・ユーザーに対して同じusernameが設定されている場合は、複数のセッションで値を参照できることを意味します。たとえば、各ユーザーを1つのジョブ・ロールに制限し、Oracle Virtual Private Databaseポリシーを使用してユーザー・アクセスを制御するアプリケーション一式を保持できます。

例9-8に、特定のユーザーが複数のアプリケーション間を移動できるように、usernameパラメータを設定する方法を示します。usernameパラメータを使用している部分は、太字で記載しています。

例9-8 複数のアプリケーション間を移動するグローバル・アプリケーション・コンテキスト値のパッケージ

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権限を指定する必要があります。つまり、アプリケーション(ユーザーではなく)がユーザーのコンテキストを設定します。

非データベース・ユーザーのグローバル・アプリケーション・コンテキスト

非データベース・ユーザーがクライアント・セッションを開始すると、アプリケーション・サーバーでクライアント・セッションIDが生成されます。

非データベース・ユーザーとはデータベースにとって未知のユーザーのことで、Webアプリケーション・ユーザーなどがこれに当たります。

この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

関連項目:

- クライアント・セッションIDを使用するグローバル・アプリケーション・コンテキストがどのように機能するかを示す例は、「例: クライアント・セッションIDを使用するグローバル・アプリケーション・コンテキストの作成」を参照してください。

- 手順2: 中間層アプリケーションを使用したクライアント・セッションIDの設定

- 中間層システムでのクライアント識別子の動作の詳細は、「データベースに認識されないアプリケーション・ユーザーの識別でのクライアント識別子の使用」を参照してください。

例: 非データベース・ユーザーのグローバル・アプリケーション・コンテキスト値を管理するためのパッケージ

CREATE PACKAGE文で、非データベース・ユーザーのグローバル・アプリケーション・コンテキスト値を管理できます。

例9-9に、このタイプのグローバル・アプリケーション・コンテキストを管理するパッケージの作成方法を示します。

例9-9 非データベース・ユーザーのグローバル・アプリケーション・コンテキスト値を管理するためのパッケージ

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プロシージャを作成します。AS句は、正しいセッションID、つまりCREATE OR REPLACE PACKAGE BODY hr_ctx_pkgプロシージャで定義されている変数session_id_pに格納されているIDを消去するように設定します。

- PROCEDURE clear_hr_context ... END clear_hr_contextは、clear_hr_contextプロシージャを作成します。このプロシージャは、global_hr_ctx変数によって定義された現行のユーザー・セッションのコンテキスト設定を消去します。詳細は、「セッションをクローズする際のセッション・データの消去」を参照してください。

セッションをクローズする際のセッション・データの消去

アプリケーション・コンテキストはメモリー内に存在するので、ユーザーがセッションを終了したときは、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の管理の概要

- 手順1: 中間層アプリケーションを使用したクライアント・セッションIDの取得

- 手順2: 中間層アプリケーションを使用したクライアント・セッションIDの設定

- 手順3: 中間層アプリケーションを使用したセッション・データの消去

中間層アプリケーションを使用したクライアント・セッションIDの管理の概要

アプリケーション・サーバーはクライアント・セッションIDを生成します。

中間層アプリケーションから、クライアント・セッションIDを取得、設定、および消去できます。そのために、Oracle Call Interface (OCI)コールとDBMS_SESSION PL/SQLパッケージ・プロシージャのどちらかを中間層アプリケーション・コードに埋め込むことができます。

アプリケーションによってユーザーが認証され、クライアント識別子が設定されてカレント・セッションに設定されます。PL/SQLパッケージSET_CONTEXTによって、アプリケーション・コンテキストにclient_identifier値が設定されます。詳細は、「非データベース・ユーザーのグローバル・アプリケーション・コンテキスト」を参照してください。

手順1: 中間層アプリケーションを使用したクライアント・セッションIDの取得

ユーザーがクライアント・セッションを開始すると、アプリケーション・サーバーでクライアント・セッション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';

次に、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に書式を設定した出力を表示します。

手順2: 中間層アプリケーションを使用したクライアント・セッションIDの設定

次に、中間層アプリケーションを使用してクライアント・セッションIDを設定します。

内容は次のとおりです。

- 中間層アプリケーションを使用したクライアント・セッションIDの設定の概要

- 中間層アプリケーションを使用したクライアント・セッション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またはDBMS_SESSION PL/SQLパッケージで、中間層アプリケーションを使用してクライアント・セッション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 Databaseのネットワーク暗号化およびデータ整合性の構成」を参照してください。ネットワークを介したデータの暗号化については、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

クライアント識別子の値のチェック

OCIAttrSetおよびDBMS_SESSION.SET_IDENTIFIERでは、クライアント識別子の値をチェックできます。

- クライアント識別子の値をチェックするには、次のいずれかの方法を使用します。

- SYS_CONTEXT関数を使用してチェックする方法:

SELECT SYS_CONTEXT('userenv', 'client_identifier') FROM DUAL;

- V$SESSIONビューを問い合せてチェックする方法:

SELECT CLIENT_IDENTIFIER from V$SESSION;

手順3: 中間層アプリケーションを使用したセッション・データの消去

アプリケーション・コンテキストは、すべてがメモリー内に存在します。

ユーザーがセッションを終了したときは、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を使用するグローバル・アプリケーション・コンテキストの作成

このチュートリアルでは、クライアント・セッションIDを使用するグローバル・アプリケーション・コンテキストの作成を示しています。

内容は次のとおりです。

- このチュートリアルの概要

- 手順1: ユーザー・アカウントの作成

- 手順2: グローバル・アプリケーション・コンテキストの作成

- 手順3: グローバル・アプリケーション・コンテキストのパッケージの作成

- 手順4: 新規作成したグローバル・アプリケーション・コンテキストのテスト

- 手順5: セッションIDの変更とグローバル・アプリケーション・コンテキストの再テスト

- 手順6: このチュートリアルのコンポーネントの削除

このチュートリアルの概要

この例は、軽量ユーザーのアプリケーション用にクライアント・セッションIDを使用するグローバル・アプリケーション・コンテキストを作成する方法を示しています。

非データベース・ユーザーの接続プールを使用したアクセスを制御する方法を示しています。マルチテナント環境を使用している場合、このチュートリアルは現在のPDBのみに適用されます。

手順1: ユーザー・アカウントの作成

セキュリティ管理者はアプリケーション・コンテキストおよびそのパッケージを管理し、ユーザー・アカウントは接続プールを所有します。

1. SYSDBA管理権限を持つSYSとしてSQL*Plusにログインします。

sqlplus sys as sysdba
Enter password: password

2. マルチテナント環境で、適切なPDBに接続します。

次に例を示します。

CONNECT SYS@my_pdb AS SYSDBA
Enter password: password

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. sysadmin_ctxローカル・ユーザー・アカウントを作成します。このアカウントは、グローバル・アプリケーション・コンテキストを管理します。

CREATE USER sysadmin_ctx IDENTIFIED BY password CONTAINER = CURRENT;
GRANT CREATE SESSION, CREATE ANY CONTEXT, CREATE PROCEDURE TO sysadmin_ctx;

GRANT EXECUTE ON DBMS_SESSION TO sysadmin_ctx;

「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。

4. 接続プールの所有者にするローカル・データベース・アカウントapps_userを作成します。

CREATE USER apps_user IDENTIFIED BY password CONTAINER = CURRENT;
GRANT CREATE SESSION TO apps_user;

passwordを安全なパスワードに置き換えます。

手順2: グローバル・アプリケーション・コンテキストの作成

次に、グローバル・アプリケーション・コンテキストを作成します。

1. セキュリティ管理者sysadmin_ctxでログインします。

CONNECT sysadmin_ctx -- Or, CONNECT sysadmin_ctx@hrpdb
Enter password: password

2. cust_ctxグローバル・アプリケーション・コンテキストを作成します。

CREATE CONTEXT global_cust_ctx USING cust_ctx_pkg ACCESSED GLOBALLY;

cust_ctxコンテキストが作成され、セキュリティ管理者sysadmin_ctxのスキーマに関連付けられます。ただし、アプリケーション・コンテキストはSYSスキーマが所有します。

手順3: グローバル・アプリケーション・コンテキストのパッケージの作成

PL/SQLパッケージは、作成したグローバル・アプリケーション・コンテキストを管理します。

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;
/

このタイプのパッケージの動作の詳細は、例9-9を参照してください。

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 -- Or, CONNECT apps_user@hrpdb
Enter password: password

2. 接続プール・ユーザーのログイン時に、アプリケーションでは、次のようにクライアント・セッション識別子が設定されます。

BEGIN
sysadmin_ctx.cust_ctx_pkg.set_session_id(34256);
END;
/

3. クライアント・セッション識別子の値をテストします。

a. セッションIDを設定します。

EXEC sysadmin_ctx.cust_ctx_pkg.set_session_id(34256);

b. セッションIDをチェックします。

SELECT SYS_CONTEXT('userenv', 'client_identifier') FROM DUAL;

次の出力が表示されます。

SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER')
--------------------------------------------------
34256

4. 次に示すように、グローバル・アプリケーション・コンテキストを設定します。

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でクライアント・セッション識別子を設定した方法と同様に、中間層アプリケーションでグローバル・アプリケーション・コンテキスト値を設定することになります。)

5. 次の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
-------------  --------------

手順5: セッションIDの変更とグローバル・アプリケーション・コンテキストの再テスト

次に、セッションIDを消去して変更し、グローバル・アプリケーション・コンテキストを再テストします。

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は適切に設定されていますが、アプリケーション・コンテキストの設定はすでに存在していません。これで、以前に設定したアプリケーション・コンテキストの値を使用せずに、このユーザーのセッションを続行できます。

手順6: このチュートリアルのコンポーネントの削除

このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。

1. SYSDBA管理権限を持つSYSとして接続します。

CONNECT SYS AS SYSDBA -- Or, CONNECT SYS@mypdb 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;

グローバル・アプリケーション・コンテキスト・プロセス

必要なアクセスの種類に応じて、データベース・ユーザー・アカウントを使用してユーザー・セッションを作成する簡単なグローバル・アプリケーション・コンテキストを構成できます。あるいは、軽量ユーザーに対してグローバル・アプリケーション・コンテキストを構成できます。

内容は次のとおりです。

- 単純なグローバル・アプリケーション・コンテキスト・プロセス

- 軽量ユーザー用のグローバル・アプリケーション・コンテキスト・プロセス

単純なグローバル・アプリケーション・コンテキスト・プロセス

簡単なグローバル・アプリケーション・コンテキストのプロセスでは、アプリケーションは、データベース・ユーザーを使用してユーザー・セッションを作成します。

単純なグローバル・アプリケーション・コンテキスト・プロセスのコンテキスト属性の値は、SELECT文から取得できます。

クライアント識別子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プログラマーズ・ガイド

クライアント・セッション・ベースのアプリケーション・コンテキストの使用

クライアント・セッション・ベースのアプリケーション・コンテキストは、ユーザー・グローバル領域(UGA)に格納されます。

内容は次のとおりです。

- クライアント・セッション・ベースのアプリケーション・コンテキストの概要

- CLIENTCONTEXTネームスペースへの値の設定

- CLIENTCONTEXTネームスペースの取得

- 例: クライアント・セッション・ベース・コンテキストのクライアント・セッションID値の取得

- 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(OCI)を使用して、CLIENTCONTEXTネームスペースを設定できます。

- CLIENTCONTEXTネームスペースに値を設定するには、次の構文でOCIAppCTXSetコマンドを使用します。

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ネームスペースの取得

Oracle Call Interfaceを使用して、CLIEINTCONTEXTネームスペースを取得できます。

- CLIENTCONTEXTネームスペースを取得するには、次のいずれかの文で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コードに埋め込んで属性値を設定できます。

例: クライアント・セッション・ベース・コンテキストのクライアント・セッションID値の取得

OCI OCIStmtExecuteコールで、クライアント・セッション・ベース・コンテキストのクライアント・セッションID値を取得できます。

例9-10に、OCIStmtExecuteコールを使用してクライアント・セッションIDを取得する方法を示します。

例9-10 クライアント・セッション・ベース・コンテキストのクライアント・セッション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ネームスペースを消去できます。

- 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)を使用して、CLIENTCONTEXTネームスペースを消去できます。

- ネームスペースを消去するには、次の構文でOCIAppCtxClearAllコマンドを使用します。

err = OCIAppCtxClearAll((void *) session_handle,
(dvoid *)"CLIENTCONTEXT", 13,
errhp,                        OCI_DEFAULT);

アプリケーション・コンテキストのデータ・ディクショナリ・ビュー

Oracle Databaseには、アプリケーション・コンテキストに関する情報を提供するデータ・ディクショナリ・ビューが用意されています。

表9-3に、これらのデータ・ディクショナリ・ビューを示します。

表9-3 アプリケーション・コンテキストに関する情報を表示するデータ・ディクショナリ・ビュー

ビュー

説明

ALL_CONTEXT

属性および値がDBMS_SESSION.SET_CONTEXTプロシージャを使用して指定された、カレント・セッション内のすべてのコンテキスト・ネームスペースが表示されます。ネームスペースと、対応付けられているスキーマおよびPL/SQLパッケージがリストされます。

ALL_POLICY_CONTEXTS

現行ユーザーがアクセス可能なシノニム、表およびビューに定義されている駆動コンテキストが表示されます。(駆動コンテキストは、仮想プライベート・データベース・ポリシーで使用されるコンテキストです。)

DBA_CONTEXT

データベース内のすべてのコンテキスト・ネームスペース情報が表示されます。このビューの列は、TYPE列が含まれていること以外はALL_CONTEXTビューの各列と同じです。TYPE列には、アプリケーション・コンテキストのアクセスまたは初期化の方法が表示されます。

DBA_OBJECTS

既存のアプリケーション・コンテキストの名前が表示されます。次のように、DBA_OBJECTSビューのOBJECT_TYPE列を問い合せます。

SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE OBJECT_TYPE ='CONTEXT';

DBA_POLICY_CONTEXTS

DBMS_RLS.ADD_POLICY_CONTEXTプロシージャによってデータベースに追加されたすべての駆動コンテキストが表示されます。このビューの列は、ALL_POLICY_CONTEXTSの各列と同じです。

SESSION_CONTEXT

カレント・セッションに設定されているコンテキスト属性とその値が表示されます。

USER_POLICY_CONTEXTS

現行ユーザーが所有するシノニム、表およびビューに定義されている駆動コンテキストが表示されます。このビューの列は、OBJECT_OWNER列以外はALL_POLICY_CONTEXTSの各列と同じです。

V$CONTEXT

カレントPDBセッションに設定されている属性がリストされます。このビューに対するSELECT権限が付与されていないユーザーは、このビューにアクセスできません。

V$SESSION

各カレントPDBセッションに関する詳細情報がリストされます。このビューに対するSELECT権限が付与されていないユーザーは、このビューにアクセスできません。

ヒント:

アプリケーション・コンテキストを使用するアプリケーションの実行時にエラーが発生した場合は、これらのビューに加え、データベース・トレース・ファイルも確認してください。USER_DUMP_DEST初期化パラメータは、トレース・ファイルのディレクトリの場所を示します。このパラメータの値は、SQL*PlusでSHOW PARAMETER USER_DUMP_DESTを発行して確認できます。

関連項目:

- トレース・ファイルの詳細は、Oracle Database SQLチューニング・ガイドを参照してください

- これらのビューの詳細は、Oracle Databaseリファレンスを参照してください。

10 Oracle Virtual Private Databaseを使用したデータ・アクセスの制御

Oracle Virtual Private Database (VPD)を使用すると、データにアクセスするユーザーをフィルタ処理できます。これを行うには、ユーザーがデータへの問合せに使用するSELECTにWHERE句を動的に含めます。

内容は次のとおりです。

- 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 (VPD)には、ユーザーによるデータへのアクセスをフィルタ処理する場合の重要なメリットがあります。VPDポリシーにアプリケーション・コンテキストの使用を組み込むことができます。

内容は次のとおりです。

- 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にはセキュリティ、簡易性、柔軟性という利点があります。

すべてのアプリケーションでアクセス制御を実装するのではなく、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ポリシーの作成者とは

DBMS_RLS PL/SQLパッケージでは、VPDポリシーを作成できます。

DBMS_RLS PL/SQLパッケージのEXECUTE権限が付与されたユーザーは、Oracle Virtual Private Databaseポリシーを作成できます。すべての権限と同様、この権限は信頼できるユーザーにのみ付与してください。ユーザーに付与された権限を確認するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューに問い合せます。

Oracle Virtual Private Databaseポリシー関数を実行するための権限

Oracle Virtual Private Database (VPD)ポリシー関数を実行するには、正しい権限を使用する必要があります。

セキュリティを強化するために、Oracle Virtual Private Database ポリシー関数は、定義者権限で宣言されたかのように実行されます。

実行者権限として宣言すると、自分自身だけでなく、コードをメンテナンスする他のユーザーも混乱させてしまうため、実行者権限では宣言しないでください。

関連項目:

定義者権限の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

Oracle Virtual Private Databaseでのアプリケーション・コンテキストの使用

Oracle Virtual Private Databaseポリシーを使ったアプリケーション・コンテキストを使用できます。

アプリケーション・コンテキストを作成すると、ユーザー情報が安全にキャッシュされます。キャッシュ環境を設定できるのは、指定されたアプリケーション・パッケージのみです。ユーザーやパッケージ外部からの変更はできません。さらに、データがキャッシュされるため、パフォーマンスが向上します。「アプリケーション・コンテキストを使用したユーザー情報の取得」では、アプリケーション・コンテキストについて詳細に説明します。

たとえば、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ポリシーは、現在のプラガブル・データベース(PDB)内のオブジェクトにのみ適用されます。

この制限は、共有の状況依存ポリシーおよびVPDポリシーに関連するビューに適用されます。マルチテナント環境全体に仮想プライベート・データベース・ポリシーを作成することはできません。

Oracle Virtual Private Databaseポリシーのコンポーネント

Oracle Virtual Private Databaseを実装するには、動的なWHERE句を生成する関数、および保護するオブジェクトにその関数を付加するポリシーを作成する必要があります。

内容は次のとおりです。

- 動的なWHERE句を生成する関数

- 保護するオブジェクトに関数を付加するポリシー

関連項目:

- Oracle Virtual Private Databaseポリシー関数を実行するための権限

- 例: Oracle Virtual Private Databaseポリシーの作成

動的なWHERE句を生成する関数

Oracle Virtual Private Database (VPD)関数により、強制適用する制限を定義します。

Oracle Virtual Private Database (VPD)の動的な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ポリシーを作成できます。様々なタイプのアプリケーション・コンテキストの詳細は、「アプリケーション・コンテキストを使用したユーザー情報の取得」を参照してください。

さらに、CまたはJavaコールを埋め込み、オペレーティング・システム情報にアクセスしたり、オペレーティング・システム・ファイルや他のソースからWHERE句を戻すことができます。

- 関連するポリシー関数内の表から選択しないでください。表へのポリシーの定義は可能ですが、表に定義されたポリシーから表を選択することはできません。

- 純関数になっている必要があります。VPD関数は、アプリケーション・コンテキストと関数に渡される引数にのみ依存して、WHERE句を生成する必要があります。この関数は、パッケージ変数に依存しないようにする必要があります。

注意:

関数を様々なエディションで実行する場合、関数の結果がすべてのエディションで同一か、または関数が実行されているエディションによって異なるかに関係なく、関数の結果を制御できます。詳細は、エディションがグローバル・アプリケーション・コンテキストのPL/SQLパッケージの結果に与える影響を参照してください。

保護するオブジェクトに関数を付加するポリシー

Oracle Virtual Private Databaseポリシーで、VPD関数を表やビュー、シノニムに関連付けます。

このポリシーを作成するには、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のポリシーの構成

DBMS_RLS PL/SQLパッケージを使用して、Oracle Virtual Private Database (VPD)ポリシーを構成できます。

内容は次のとおりです。

- Oracle Virtual Private Databaseポリシーの概要

- データベース表、ビューまたはシノニムへのポリシーの付加

- 例: 表への単純なOracle Virtual Private Databaseポリシーの付加

- 特定のSQL文に対するポリシーの規定

- 例: DBMS_RLS.ADD_POLICYを使用したSQL文の指定

- ポリシーを使用した列データ表示の制御

- Oracle Virtual Private Databaseのポリシー・グループ

- Oracle Virtual Private Databaseポリシー・タイプを使用したパフォーマンスの最適化

Oracle Virtual Private Databaseポリシーの概要

Oracle Virtual Private Databaseポリシーで、VPD関数をデータベース表やビュー、シノニムに関連付けます。

この関数はOracle Virtual Private Database WHERE句のアクションを定義します。この関数を、Oracle Virtual Private Database (VPD)アクションが適用されるデータベース表に関連付ける必要があります。

これを行うには、Oracle Virtual Private Databaseポリシーを構成します。ポリシーとは、仮想プライベート・データベース関数を管理するメカニズムです。また、ポリシーを使用すると、ファイングレイン・アクセス・コントロールを追加できるため、たとえば、SQL文のタイプを指定したり、特定の表列にポリシーを適用できます。ユーザーがこのデータベース・オブジェクト内のデータにアクセスすると、ポリシーが自動的に有効になります。

表10-1に、DBMS_RLSパッケージに含まれているプロシージャを示します。

表10-1 DBMS_RLSのプロシージャ

プロシージャ

説明

個別ポリシーの処理用

-

DBMS_RLS.ADD_POLICY

表、ビューまたはシノニムにポリシーを追加します。

DBMS_RLS.ENABLE_POLICY

表、ビューまたはシノニムに事前に追加したポリシーを使用可能または使用禁止にします。

DBMS_RLS.ALTER_POLICY

属性とポリシーの関連付けまたは関連付けの解除のため、既存のポリシーを変更します。

DBMS_RLS.REFRESH_POLICY

静的ポリシー以外のポリシーに対応付けられたカーソルを無効にします。

DBMS_RLS.DROP_POLICY

表、ビューまたはシノニムからポリシーを削除します。

グループ・ポリシーの処理用

-

DBMS_RLS.CREATE_POLICY_GROUP

ポリシー・グループを作成します。

DBMS_RLS.ALTER_GROUPED_POLICY

ポリシー・グループを変更します。

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ポリシーのコンポーネント

- アプリケーション・コンテキストを使用したユーザー情報の取得

データベース表、ビューまたはシノニムへのポリシーの付加

DBMS_RLS PL/SQLパッケージで、表、ビューまたはシノニムにポリシーを付加できます。

- ポリシーをデータベース表、ビューまたはシノニムに付加するには、DBMS_RLS.ADD_POLICYプロシージャを使用します。

ポリシーを追加する表、ビューまたはシノニム、およびポリシーの名前を指定する必要があります。また、ポリシーが制御する文のタイプ(SELECT、INSERT、UPDATE、DELETE、CREATE INDEXまたはALTER INDEX)など、その他の情報も指定できます。

1つのオブジェクトに作成できるポリシーの最大数は255であることに注意してください。

例: 表への単純なOracle Virtual Private Databaseポリシーの付加

DBMS_RLS.ADD_POLICYプロシージャで、Oracle Virtual Private Database (VPD)ポリシーを表、ビューまたはシノニムに付加できます。

例10-1に、DBMS_RLS.ADD_POLICYを使用して、secure_updateというOracle Virtual Private DatabaseポリシーをHR.EMPLOYEES表に付加する方法を示します。ポリシーに付加される関数はcheck_updatesです。

例10-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文に規定できます。

- ポリシーに対してSQL文のタイプを指定するには、DBMS_RLS.ADD_POLICYプロシージャのstatement_typesパラメータを使用します。複数指定するには、それぞれをカンマで区切ります。リストは一重引用符で囲みます。

文のタイプを指定しない場合、Oracle DatabaseではデフォルトでSELECT、INSERT、UPDATEおよびDELETEが指定されますが、INDEXは指定されません。これらの文のタイプの組合せを入力できます。

statement_typesパラメータを指定する場合は、次の機能に注意してください。

- Virtual Private Databaseポリシーによる影響を受けるアプリケーション・コードとして、MERGE INTO文が含まれる場合があります。しかし、Virtual Private Databaseポリシーでは、statement_typesパラメータにINSERT、UPDATE、およびDELETEの3つの文すべてを含めてポリシーを正常に機能させる必要があります。あるいは、statement_typesパラメータを省略できます。

- 索引をメンテナンスする権限を持っているユーザーは、たとえこのユーザーがSELECTのような標準問合せでは完全な表アクセスを持っていない場合でも、すべての行データを参照できることに注意してください。たとえばユーザーは、列値を引数とする、ユーザー定義関数を含む関数ベースの索引を作成できます。索引作成時に、Oracle Databaseがあらゆる行の列値をユーザー関数へ渡して、索引を作成するユーザーが行データを使用できるようにします。INDEXをstatement_typesパラメータで指定することにより、Oracle Virtual Private Databaseポリシーを索引メンテナンス操作で適用できます。

例: DBMS_RLS.ADD_POLICYを使用したSQL文の指定

DBMS_RLS.ADD_POLICYプロシージャのstatement_typesパラメータで、ポリシーのSELECT文とINDEX文を指定できます。

例10-2に、これを行う方法を示します。

例10-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;
/

ポリシーを使用した列データ表示の制御

セキュリティに関連する列が問合せで参照される際に行レベルのセキュリティを規定するポリシーを作成できます。

内容は次のとおりです。

- 列レベルOracle Virtual Private Databaseのポリシー

- 例: 列レベルのOracle Virtual Private Databaseポリシーの作成

- 問合せに関連する列の行のみの表示

- 機密性の高い列をNULL値で表示するための列のマスク

- 例: Oracle Virtual Private Databaseポリシーへの列のマスクの追加

列レベルの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';

例: 列レベルのOracle Virtual Private Databaseポリシーの作成

CREATE FUNCTION文およびDBMS_RLS.ADD_POLICYプロシージャで、列レベルのOracle Virtual Private Databaseポリシーを構成できます。

例10-3は、営業部門(部門番号30)のユーザーは他部門の従業員の給与を参照できないというOracle Virtual Private Databaseポリシーを示します。このポリシーに関連する列は、salおよびcommです。最初にOracle Virtual Private Databaseポリシー関数を作成し、次にDBMS_RLS PL/SQLパッケージを使用して追加します。

例10-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では、機密情報が含まれた列が問合せで参照された場合、戻される行の数が制限されます。

これらのセキュリティ関連の列を指定するには、例10-3に示すように、DBMS_RLS.ADD_POLICYプロシージャのSEC_RELEVANT_COLUMNSパラメータを使用します。

たとえば、営業部門ユーザーはemp表に対してSELECT権限を持っており、この表は例10-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に設定します。

列のマスクに関する考慮事項は次のとおりです。

- 列のマスクが適用されるのは、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ポリシーへの列のマスクの追加

DBMS_RLS.ADD_POLICYプロシージャで、列レベルのOracle Virtual Private Database列のマスク動作を構成できます。

例10-4は、列レベルのOracle Virtual Private Database列のマスク動作を示しています。これは、例: 列レベルのOracle Virtual Private Databaseポリシーの作成と同じVPDポリシーを使用していますが、sec_relevant_cols_optをDBMS_RLS.ALL_ROWSとして指定しています。

例10-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になっています。

Oracle Virtual Private Databaseポリシー・グループ

Oracle Virtual Private Databaseポリシー・グループは、アプリケーションに適用できるVPDポリシーの名前付きコレクションです。

内容は次のとおりです。

- 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プロシージャで、VPDポリシーをVPDポリシー・グループに追加します。

有効にするポリシーを指定するには、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 (VPD)の動的、静的または共有ポリシー・タイプを使用して、パフォーマンスを最適化できます。コンテキスト依存ポリシーを使用して、1つのポリシーを複数のオブジェクトで共有できます。

内容は次のとおりです。

- Oracle Virtual Private Databaseポリシー・タイプの概要

- ポリシー関数を自動再実行するための動的ポリシー・タイプ

- 例: DBMS_RLS.ADD_POLICYを使用したDYNAMICポリシーの作成

- ポリシー関数の問合せごとの再実行を回避するための静的ポリシー

- 例: DBMS_RLS.ADD_POLICYを使用した静的ポリシーの作成

- 例: 複数オブジェクト間でポリシーを共有するための共有の静的ポリシー

- 静的ポリシーおよび共有の静的ポリシーを使用する場合

- 変更されるアプリケーション・コンテキスト属性の状況依存ポリシー

- 例: 共有の状況依存ポリシーの使用による複数オブジェクト間でのポリシーの共有

- 状況依存ポリシーおよび共有の状況依存ポリシーを使用する場合

- 例: DBMS_RLS.ADD_POLICYを使用した状況依存ポリシーの作成

- 例: VPD状況依存ポリシーのキャッシュされた文のリフレッシュ

- 例: 既存の状況依存ポリシーの変更

- 5種類のOracle Virtual Private Databaseポリシー・タイプの要約

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

関連項目:

動的ポリシーの基礎となるポリシー関数の監査の仕組みは、ファンクション、プロシージャ、パッケージおよびトリガーの監査を参照してください

例: DBMS_RLS.ADD_POLICYを使用したDYNAMICポリシーの作成

DBMS_RLS.ADD_POLICYプロシージャで、動的なOracle Virtual Private Databaseポリシーを作成できます。

例10-5に、DYNAMICポリシー・タイプの作成方法を示します。

例10-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のいずれかに設定します。

述語が同じでも、同じカーソルを実行するたびに異なる行セットが生成される場合があります。これは、述語によるデータのフィルタ処理がSYS_CONTEXTやSYSDATEなどの属性によって異なるためです。

たとえば、ポリシーをSTATICまたはSHARED_STATICポリシー・タイプとして使用可能にする場合を想定します。この場合は、ポリシーで保護されたデータベース・オブジェクトに対して実行されるすべての問合せに次の述語が追加されます。

WHERE dept = SYS_CONTEXT ('hr_app','deptno')

述語は、問合せごとに変わりませんが、SYS_CONTEXTのセッション属性に基づいて問合せに適用されます。前述の例の述語では、ポリシーで保護されたデータベース・オブジェクトを問い合せているユーザーの部門番号がSYS_CONTEXTのdeptno属性と一致する行のみを戻します。

注意:

共有の静的ポリシーを使用する場合は、ポリシーの述語に、列名など特定のデータベース・オブジェクト固有の属性が含まれていないことを確認してください。

関連項目:

静的ポリシーの基礎となるポリシー関数の監査の仕組みは、ファンクション、プロシージャ、パッケージおよびトリガーの監査を参照してください

例: DBMS_RLS.ADD_POLICYを使用した静的ポリシーの作成

DBMS_RLS.ADD_POLICYプロシージャで、静的なOracle Virtual Private Database (VPD)ポリシーを作成できます。

例10-6に、STATICポリシー・タイプの作成方法を示します。

例10-6 DBMS_RLS.ADD_POLICYを使用した静的ポリシーの作成

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;
/

例: 複数オブジェクト間でポリシーを共有するための共有の静的ポリシー

複数オブジェクト間でポリシーを共有するために、DBMS_RLS.ADD_POLICYプロシージャで共有の静的Oracle Virtual Private Databaseポリシーを作成できます。

たとえば、使用する財務データを含むHRスキーマの2番目の表に例10-6のポリシーを適用する場合、両方の表でSHARED_STATIC設定を使用します。

例10-7に、同じポリシーを共有する2つの表に対してSHARED_STATICポリシー・タイプを設定する方法を示します。

例10-7 複数オブジェクト間でポリシーを共有するための共有の静的ポリシーの作成

-- 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にキャッシュされるため、システム・リソースを節約でき、パフォーマンスが向上します。

変更されるアプリケーション・コンテキスト属性の状況依存ポリシー

状況依存ポリシーは、何が問合せを実行しているかに応じて異なる述語を適用する必要がある場合に便利です。

たとえば、マネージャには述語WHERE groupがmanagersに設定され、従業員には述語WHERE empno_ctxがemp_idに設定される場合を考えてみます。状況依存ポリシーでは、マネージャのログイン時にマネージャが確認する必要がある情報のみ表示し、従業員のログイン時に従業員が確認する必要がある情報のみ表示できます。このポリシーは、アプリケーション・コンテキストを使用して、使用する述語を決定します。

静的ポリシーとは対照的に、状況依存ポリシーは必ずしも述語をキャッシュしません。状況依存ポリシーの場合、データベースでは、述語は文の解析後に変更されると想定しています。ただし、ローカル・アプリケーション・コンテキストに変更がない場合、Oracle Databaseはユーザー・セッション内でポリシー関数を再実行しません。ユーザー・セッション中にアプリケーション・コンテキストの属性の変更がある場合、デフォルトでは、データベースはポリシー関数を再実行して、初期解析からの述語へのすべての変更を取得していることを確認します。これにより、関連付けられている属性が変更されていない場合、ポリシー関数の再実行が必要なくなります。namespaceおよびattributeパラメータを含めて、特定のアプリケーション・コンテキストへの評価を制限できます。

ポリシーでnamespaceおよびattributeパラメータを使用する場合、次のガイドラインに従います。

- 1つだけではなくnamespaceおよびattributeパラメータの両方を指定していることを確認します。

- ポリシーにDBMS_RLS.CONTEXT_SENSITIVEまたはSHARED_CONTEXT_SENSITIVEに設定されているpolicy_type引数があることを確認します。静的または動的ポリシーのnamespaceおよびattributeパラメータを使用できません。

仮想プライベート・データベースのポリシー関数に関連付けられている属性がない場合、Oracle Databaseは、アプリケーション・コンテキストの変更の状況依存関数を評価します。

共有の状況依存ポリシーは、複数のデータベース・オブジェクト間で共有できる点を除いて、通常の状況依存ポリシーと同じように動作します。このポリシー・タイプの場合、すべてのオブジェクトがUGAのポリシー関数を共有でき、この場合、述語はローカル・セッション・コンテキストが変更されるまでキャッシュされます。

関連項目:

- 例: 共有の状況依存ポリシーの使用による複数オブジェクト間でのポリシーの共有

- チュートリアル: セッション・ベースのアプリケーション・コンテキスト・ポリシーの実装

- 例: Oracle Virtual Private Databaseポリシー・グループの実装

例: DBMS_RLS.ADD_POLICYを使用した状況依存ポリシーの作成

DBMS_RLS.ADD_POLICYプロシージャで、Oracle Virtual Private Database状況依存ポリシーを作成できます。

例10-8は、empno_ctxネームスペースおよびemp_id属性への変更のみにポリシーが評価されるCONTEXT_SENSITIVEポリシーの作成方法を示しています。

例10-8 DBMS_RLS.ADD_POLICYを使用した状況依存ポリシーの作成

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,
namespace       => 'empno_ctx',
attribute       => 'emp_id');
END;
/

例: VPD状況依存ポリシーのキャッシュされた文のリフレッシュ

DBMS_RLS.REFRESH_POLICY文で、Oracle Virtual Private Database状況依存ポリシーのキャッシュされた文をリフレッシュできます。

例10-9は、DBMS_RLS.REFRESH_POLICYプロシージャを実行して仮想プライベート・データベースの状況依存ポリシーに関連付けられているすべてのキャッシュされた文を手動でリフレッシュできることを示しています。

例10-9 VPD状況依存ポリシーのキャッシュされた文のリフレッシュ

BEGIN
DBMS_RLS.REFRESH_POLICY(
object_schema   => 'hr',
object_name     => 'employees',
policy_name     => 'secure_update');
END;
/

例: 既存の状況依存ポリシーの変更

DBMS_RLS.ALTER_POLICYプロシージャで、Oracle Virtual Private Databaseポリシーを変更できます。

例10-10は、関連するコンテキスト属性が変更される場合にのみorder_update_polポリシー関数を実行するためにDBMS_RLS.ALTER_POLICY文を使用して既存の状況依存ポリシーを変更する方法を示しています。

例10-10 既存の状況依存ポリシーの変更

BEGIN
DBMS_RLS.ALTER_POLICY(
object_schema   => 'oe',
object_name     => 'orders',
policy_name     => 'order_update_pol',
alter_option    =>  DBMS_RLS.ADD_ATTRIBUTE_ASSOCIATION,
namespace       => 'empno_ctx',
attribute       => 'emp_role');
END;
/

例: 共有の状況依存ポリシーの使用による複数オブジェクト間でのポリシーの共有

複数オブジェクトがあるポリシーを共有するために、DBMS_RLS.ADD_POLICYプロシージャを使用して、共有の状況依存のOracle Virtual Private Databaseポリシーを作成できます。

例10-11は、複数の表でポリシーを共有する2つの共有の状況依存ポリシーを作成する方法およびempno_ctxネームスペースおよびemp_id属性への変更のみに評価を制限する方法を示しています。

例10-11 DBMS_RLS.ADD_POLICYを使用した共有の状況依存ポリシー

-- 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,
namespace       => 'empno_ctx',
attribute       => 'emp_id');
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,
namespace       => 'empno_ctx',
attribute       => 'emp_id');
END;
/

次のことに注意してください。

- 共有の状況依存ポリシーを使用する場合は、ポリシーの述語に、列名など特定のデータベース・オブジェクト固有の属性が含まれていないことを確認してください。

- 仮想プライベート・データベースの共有の状況依存ポリシーに関連付けられているすべてのキャッシュされた文を手動でリフレッシュするには、DBMS_RLS.REFRESH_GROUPED_POLICYプロシージャを実行します。

状況依存ポリシーおよび共有の状況依存ポリシーを使用する場合

状況依存ポリシーは、ユーザー・セッションごとに述語を変える必要はないが、ポリシーが異なるユーザーまたはグループに複数の異なる述語を規定する必要がある場合に使用します。

たとえば、単一のポリシーを持つsales_history表を考えてみます。このポリシーでは、アナリストは自分の製品のみを参照でき、地域担当者は自分の地域のみを参照できます。この場合、データベースは、ユーザーのタイプが変わるたびにポリシー関数を再実行する必要があります。サーバーによるポリシー関数の再実行なしに、ユーザーがログインして保護されたオブジェクトに対していくつかのDML文を発行できる場合は、パフォーマンスが向上します。

注意:

複数のクライアントが1つのデータベース・セッションを共有するセッション・プーリングの場合は、クライアント切替え時に中間層でコンテキストを再設定する必要があります。

5種類のOracle Virtual Private Databaseポリシー・タイプの要約

Oracle Virtual Private Databaseには、ユーザーのニーズ(ホスト環境での使用など)に基づいて、5種類のポリシー・タイプが用意されています。

表10-2に、使用可能なポリシー・タイプの要約を示します。

表10-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 (VPD)ポリシー、データベース・セッション・ベースのアプリケーション・コンテキストを持つポリシー、およびポリシー・グループの作成方法を示します。

内容は次のとおりです。

- 例: 単純なOracle Virtual Private Databaseポリシーの作成

- チュートリアル: セッション・ベースのアプリケーション・コンテキスト・ポリシーの実装

- 例: Oracle Virtual Private Databaseポリシー・グループの実装

例: 単純なOracle Virtual Private Databaseポリシーの作成

このチュートリアルでは、OEユーザー・アカウントを使用して、簡単なOracle Virtual Private Database (VPD)ポリシーを作成する方法を示します。

内容は次のとおりです。

- このチュートリアルの概要

- 手順1: OEユーザー・アカウントがアクティブであることの確認

- 手順2: ポリシー関数の作成

- 手順3: Oracle Virtual Private Databaseポリシーの作成

- 手順4: ポリシーのテスト

- 手順5: このチュートリアルのコンポーネントの削除

このチュートリアルの概要

このチュートリアルでは、アクセスを営業担当者159が作成したOE.ORDERS表内の受注に制限するVPDポリシーの作成方法を示します。

このポリシーは、基本的に次の文で表現されます。

SELECT * FROM OE.ORDERS;

この文を次のように変換します。

SELECT * FROM OE.ORDERS WHERE SALES_REP_ID = 159;

注意:

マルチテナント環境を使用している場合、このチュートリアルは現在のPDBのみに適用されます。

手順1: OEユーザー・アカウントがアクティブであることの確認

まず、OEユーザー・アカウントが有効であることを確認する必要があります。

1. SYSDBA管理権限を持つユーザーSYSとしてSQL*Plusにログインします。

sqlplus sys as sysdba
Enter password: password

2. マルチテナント環境で、適切なPDBに接続します。

例:

CONNECT SYS@hrpdb AS SYSDBA
Enter password: password

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. OEアカウント・ステータスを調べるには、DBA_USERSデータ・ディクショナリ・ビューを問い合せます。

SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'OE';

このステータスは、OPENになっている必要があります。DBA_USERSビューに、ユーザーOEがロックされて期限切れになっていると表示された場合は、次の文を入力して、OEアカウントのロックを解除し、新しいパスワードを作成します。

ALTER USER OE ACCOUNT UNLOCK IDENTIFIED BY password;

「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。セキュリティを向上させるため、以前のリリースのOracle Databaseで使用されたパスワードを再利用しないでください。

手順2: ポリシー関数の作成

次に、ポリシー関数を作成します。

ユーザーSYSとして、次の関数を作成します。この関数は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ポリシーの作成

ポリシー関数の作成後、その関数をVPDポリシーに関連付けます。

- DBMS_RLSパッケージのADD_POLICYプロシージャを使用して、次のポリシーを作成します。

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'
);
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文にポリシーが適用されます。

手順4: ポリシーのテスト

Oracle Virtual Private Databaseポリシーを作成した直後に、ポリシーは有効になります。

ユーザー(スキーマの所有者を含む)が次にOE.ORDERSに対してSELECT文を実行すると、営業担当者159の受注のみにアクセスできます。

1. ユーザーOEとして接続します。

CONNECT oe -- Or, CONNECT OE@hrpdb
Enter password: password

2. 次のSELECT文を入力します。

SELECT COUNT(*) FROM ORDERS;

次の出力が表示されます。

COUNT(*)
---------
7

ポリシーはユーザーOEに対して有効です。ここに示すように、受注表の105行の内、7行のみが戻されます。

ただし、管理権限を持つユーザーは、表のすべての行にアクセスできます。

3. SYSDBA管理権限を持つユーザーSYSとして接続します。

CONNECT SYS AS SYSDBA -- Or, CONNECT SYS@hrpdb 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;

チュートリアル: セッション・ベースのアプリケーション・コンテキスト・ポリシーの実装

このチュートリアルでは、データベース・セッション・ベースのアプリケーション・コンテキストを使用するOracle Virtual Private Databaseポリシーの作成方法を示します。

内容は次のとおりです。

- このチュートリアルの概要

- 手順1: ユーザー・アカウントとサンプル表の作成

- 手順2: データベース・セッション・ベースのアプリケーション・コンテキストの作成

- 手順3: アプリケーション・コンテキストを設定するPL/SQLパッケージの作成

- 手順4: アプリケーション・コンテキストのPL/SQLパッケージを実行するログイン・トリガーの作成

- 手順5: ログオン・トリガーのテスト

- 手順6: ユーザー・アクセスを自分の注文に制限するPL/SQLポリシー関数の作成

- 手順7: 新しいセキュリティ・ポリシーの作成

- 手順8: 新しいポリシーのテスト

- 手順9: このチュートリアルのコンポーネントの削除

このチュートリアルの概要

この例では、データベース・セッション・ベースのアプリケーション・コンテキストを使用して、顧客が自分の注文のみを参照できるというポリシーを実装する方法を示しています。

マルチテナント環境を使用している場合、このチュートリアルは現在のPDBのみに適用されます。

このチュートリアルでは、次の層のセキュリティを作成します。

1. ユーザーがログインするとき、データベース・セッション・ベースのアプリケーション・コンテキストによって顧客かどうかがチェックされます。顧客でないユーザーでもログインできますが、このユーザーはこの例で作成する注文表にアクセスできません。

2. ユーザーが顧客の場合はログインできます。顧客がログインした後、Oracle Virtual Private Databaseポリシーによって、このユーザーは自分の注文のみを参照できるように制限されます。

3. さらなる制限として、Oracle Virtual Private Databaseポリシーによって、ユーザーは注文を追加、変更、または削除できなくなります。

手順1: ユーザー・アカウントとサンプル表の作成

まず、ユーザー・アカウントとサンプル表を作成します。

1. SQL*Plusを起動して、管理権限を持つユーザーとしてログインします。

sqlplus sys as sysdba
Enter password: password

2. マルチテナント環境で、適切なPDBに接続します。

例:

CONNECT SYS@hrpdb AS SYSDBA
Enter password: password

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. Oracle Virtual Private Databaseポリシーを管理する、次の管理ユーザーを作成します。

次のSQL文では、このユーザーを作成してから、この例を終了するのに必要な権限をユーザーに付与します。

CREATE USER sysadmin_vpd IDENTIFIED BY password CONTAINER = CURRENT;
GRANT CREATE SESSION, CREATE ANY CONTEXT, CREATE PROCEDURE, CREATE TRIGGER, ADMINISTER DATABASE TRIGGER TO sysadmin_vpd;
GRANT EXECUTE ON DBMS_SESSION TO sysadmin_vpd;
GRANT EXECUTE ON DBMS_RLS TO sysadmin_vpd;

「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。

4. 次のローカル・ユーザーを作成します。

CREATE USER tbrooke IDENTIFIED BY password CONTAINER = CURRENT;
CREATE USER owoods IDENTIFIED BY password CONTAINER = CURRENT;

GRANT CREATE SESSION TO tbrooke, owoods;

passwordを安全なパスワードに置き換えます。

5. このチュートリアルで使用する、サンプル・ユーザーSCOTTのアカウント・ステータスを確認します。

SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'SCOTT';

このステータスは、OPENになっている必要があります。DBA_USERSビューに、ユーザーSCOTTがロックされて期限切れになっていると表示された場合は、次の文を入力して、SCOTTアカウントのロックを解除し、新しいパスワードを作成します。

ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY password;

「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。セキュリティを向上させるため、以前のリリースのOracle Databaseで使用されたパスワードを再利用しないでください。

6. ユーザーSCOTTとして接続します。

CONNECT SCOTT -- Or, CONNECT SCOTT@hrpdb
Enter password: password

7. customers表を作成および移入します。

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');

ユーザーの電子メールIDを入力する際には、大文字で入力します。後でアプリケーション・コンテキストのPL/SQLパッケージを作成するときに、SYS_CONTEXTファンクションのSESSION_USERパラメータではユーザー名が大文字であると想定されます。大文字でないと、そのユーザー用のアプリケーション・コンテキストを設定できません。

8. ユーザーsysadmin_vpdには、ユーザーSCOTTと同様にcustomers表のSELECT権限が必要になるため、この権限をsysadmin_vpdに付与します。

GRANT READ ON customers TO sysadmin_vpd;

9. 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);

10. ユーザーtbrookeとowoodsはorders_tab表を問い合せる必要があるため、これらのユーザーにREADオブジェクト権限を付与します。

GRANT READ ON orders_tab TO tbrooke, owoods;

orders_tab受注表には、2名のサンプル顧客tbrookeとowoodsの購買レコードがあります。この段階では、これらの顧客がこの表を参照すると、すべての受注を参照できます。

手順2: データベース・セッション・ベースのアプリケーション・コンテキストの作成

次に、データベース・セッション・ベースのアプリケーション・コンテキストを作成します。

1. ユーザーsysadmin_vpdで接続します。

CONNECT sysadmin_vpd -- Or, CONNECT sysadmin_vpd@hrpdb
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 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システム例外を追加して、SELECT cust_no INTO custnum ...文のSELECT文によって発生した可能性のあるno data foundエラーを捕捉します。

要約すると、sysadmin_vpd.set_cust_numプロシージャは、セッション・ユーザーの顧客IDを選択してcustnum変数に格納することによって、ユーザーが登録済顧客かどうかを識別します。ユーザーが登録済顧客の場合、Oracle Databaseによってこのユーザーにアプリケーション・コンテキスト値が設定されます。「手順6: ユーザー・アクセスを自分の注文に制限するPL/SQLポリシー関数の作成」に示すように、ポリシー関数では、コンテキスト値を使用して、ユーザーがorders_tab表内のデータに対して持つアクセスを制御します。

手順4: アプリケーション・コンテキストのPL/SQLパッケージを実行するログイン・トリガーの作成

ログイン・トリガーがPL/SQLパッケージ・プロシージャを実行し、次回のユーザー・ログイン時にアプリケーション・コンテキストが設定されるようにします。

このトリガーは、「手順3: アプリケーション・コンテキストを設定するPL/SQLパッケージの作成」で作成しました。

- ユーザーsysadmin_vpdで、次のトリガーを作成します。

CREATE TRIGGER set_custno_ctx_trig AFTER LOGON ON DATABASE
BEGIN
sysadmin_vpd.orders_ctx_pkg.set_custnum;
END;
/

関連項目:
データベース・セッションのアプリケーション・コンテキスト・パッケージを実行するログオン・トリガー

手順5: ログオン・トリガーのテスト

ログイン・トリガーがsysadmin_vpd.orders_ctx_pkg.set_custnumプロシージャを実行して、そのユーザーのアプリケーション・コンテキストを設定します。

1. ユーザーtbrookeとして接続します。

CONNECT tbrooke -- For a CDB, connect to the PDB, e.g., @hrpdb
Enter password: password

2. 次の問合せを実行します。

SELECT SYS_CONTEXT('orders_ctx', 'cust_no') custnum FROM DUAL;

次の出力が表示されます。

EMP_ID
-------------------------------------------------------------------
1234

手順6: ユーザー・アクセスを自分の注文に制限するPL/SQLポリシー関数の作成

次の手順では、ユーザーの問合せの表示を制御するPL/SQLファンクションを作成します。

ログインしているユーザーが問合せSELECT * FROM scott.orders_tabを実行したときに、この関数は、そのユーザーの注文のみを表示する出力を生成する必要があります。

1. ユーザーsysadmin_vpdで接続します。

CONNECT sysadmin_vpd -- Or, CONNECT sysadmin_vpd@hrpdb
Enter password: password

2. 次の関数を作成します。

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ポリシーを作成できます。

手順7: 新しいセキュリティ・ポリシーの作成

最後に、VPDセキュリティ・ポリシーを作成します。

- ユーザーsysadmin_vpdとして、DBMS_RLS.ADD_POLICYプロシージャを使用して、ポリシーを次のように作成します。

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',
policy_type      => DBMS_RLS.CONTEXT_SENSITIVE,
namespace        => 'orders_ctx',
attribute        => 'cust_no');
END;
/

この文は、SCOTTスキーマで、orders_policyという名前のポリシーを作成して、顧客が自分の注文について問い合せるためのorders_tab表に適用します。get_user_orders関数が実装するこのポリシーは、sysadmin_vpdスキーマに格納されます。このポリシーは、さらに、ユーザーがSELECT文のみを発行するように制限します。namespaceおよびattributeパラメータは、以前に作成したアプリケーション・コンテキストを指定します。

手順8: 新しいポリシーのテスト

これで、すべてのコンポーネントが作成されたため、ポリシーをテストします。

1. ユーザーtbrookeとして接続します。

CONNECT tbrooke -- Or, CONNECT tbrooke@hrpdb
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 -- For a CDB, connect to the PDB, e.g., @hrpdb
Enter password: password

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ポリシーの概要を比較してください。

手順9: このチュートリアルのコンポーネントの削除

このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。

1. ユーザーSCOTTとして接続します。

CONNECT SCOTT -- Or, CONNECT SCOTT@hrpdb
Enter password: password

2. orders_tabおよびcustomers表を削除します。

DROP TABLE orders_tab;
DROP TABLE customers;

3. ユーザーSYSとしてAS SYSDBAで接続します。

CONNECT SYS AS SYSDBA -- Or, CONNECT SYS@hrpdb AS SYSDBA
Enter password: password

4. 次の文を実行して、この例で使用したコンポーネントを削除します。

DROP CONTEXT orders_ctx;
DROP USER sysadmin_vpd CASCADE;
DROP USER tbrooke;
DROP USER owoods;

例: Oracle Virtual Private Databaseポリシー・グループの実装

このチュートリアルでは、Oracle Virtual Private Database (VPD)ポリシー・グループの作成方法を示します。

内容は次のとおりです。

- このチュートリアルの概要

- 手順1: この例で使用するユーザー・アカウントと他のコンポーネントの作成

- 手順2: 2つのポリシー・グループの作成

- 手順3: ポリシー・グループを制御するPL/SQLファンクションの作成

- 手順4: 駆動アプリケーション・コンテキストの作成

- 手順5: PL/SQLファンクションのポリシー・グループへの追加

- 手順6: ポリシー・グループのテスト

- 手順7: このチュートリアルのコンポーネントの削除

このチュートリアルの概要

このチュートリアルでは、Oracle Virtual Private Database (VPD)を使用してポリシー・グループを作成する方法を示します。

アプリケーションで使用する一連のポリシーをグループ化する方法は、「Oracle Virtual Private Databaseのポリシー・グループ」を参照してください。非データベース・ユーザーがアプリケーションにログインすると、Oracle Databaseでは、適切なポリシー・グループ内で定義されたポリシーに基づいてユーザーにアクセス権が付与されます。

列レベルのアクセス制御の場合、各列または非表示の列セットが1つのポリシーで制御されます。この例では、2つの列セットを非表示にする必要があります。そのため、非表示にする列セットごとに1つずつ、2つのポリシーを作成する必要があります。ユーザーごとに必要なポリシーは1つのみのため、駆動アプリケーション・コンテキストによってポリシーが分割されます。

注意:

マルチテナント環境を使用している場合、このチュートリアルは現在のPDBのみに適用されます。

手順1: この例で使用するユーザー・アカウントと他のコンポーネントの作成

まず、このチュートリアルのユーザー・アカウントと表を作成し、適切な権限を付与する必要があります。

1. SYSDBA管理権限を持つユーザーSYSとしてログインします。

sqlplus sys as sysdba
Enter password: password

2. マルチテナント環境で、適切なPDBに接続します。

例:

CONNECT SYS@hrpdb AS SYSDBA
Enter password: password

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. 次のローカル・ユーザーを作成します。

CREATE USER apps_user IDENTIFIED BY password CONTAINER = CURRENT;
GRANT CREATE SESSION TO apps_user;
CREATE USER sysadmin_pg  IDENTIFIED BY password CONTAINER = CURRENT;
GRANT CREATE SESSION, CREATE PROCEDURE, CREATE ANY CONTEXT TO sysadmin_pg;

「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。

4. ユーザーsysadmin_pgに次の権限を追加付与します。

GRANT EXECUTE ON DBMS_RLS TO sysadmin_pg;

5. ユーザーOEでログインします。

CONNECT OE -- Or, CONNECT OE@hrpdb
Enter password: password

OEアカウントがロックされて期限切れになっている場合、SYSDBA管理権限を持つユーザーSYSとして再接続してから、次の文を入力してアカウントのロックを解除し、新しいパスワードを指定します。

ALTER USER OE ACCOUNT UNLOCK IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。セキュリティを向上させるため、以前のリリースのOracle Databaseで使用されたパスワードを再利用しないでください。

6. product_code_names表を作成します。

CREATE TABLE product_code_names(
group_a     varchar2(32),
year_a      varchar2(32),
group_b     varchar2(32),
year_b      varchar2(32));

7. 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;

8. 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 -- Or, CONNECT sysadmin_pg@hrpdb
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ファンクションの作成

ポリシー・グループには、ユーザーのデータ・アクセスをアプリケーションでどのように制御するかを定義する関数が必要です。

このポリシー・グループに作成する関数はユーザー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'を設定すると関連列が非表示になります。「手順5: PL/SQLファンクションのポリシー・グループへの追加」では、これらの列をSEC_RELEVANT_COLSパラメータに指定します。

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'に指定すると、「手順5: PL/SQLファンクションのポリシー・グループへの追加」でSEC_RELEVANT_COLSパラメータに指定する関連列が非表示になります。

関連トピック

- 動的なWHERE句を生成する関数

手順4: 駆動アプリケーション・コンテキストの作成

アプリケーション・コンテキストにより、ログインする非データベース・ユーザーが使用する必要があるポリシーが決定されます。

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;

手順5: 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,
namespace             => 'provider_ctx',
attribute             => 'provider_group');
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,
namespace             => 'provider_ctx',
attribute             => 'provider_group');
END;
/

sec_relevant_colsパラメータで指定したgroup_aおよびyear_a列は、ユーザーprovider_bに対して非表示になります。

手順6: ポリシー・グループのテスト

これで、2つのポリシー・グループをテストできます。

1. ユーザーapps_userとして接続した後、次の文を入力して、後で作成する出力の書式が適切に設定されるようにします。

CONNECT apps_user -- Or, CONNECT apps_user@hrpdb
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として接続します。

CONNECT OE -- Or, CONNECT OE@hrpdb
Enter password: password

2. product_code_names表を削除します。

DROP TABLE product_code_names;

3. SYSDBA管理権限を持つユーザーSYSとして接続します。

CONNECT SYS AS SYSDBA -- Or, CONNECT SYS@hrpdb AS SYSDBA
Enter password: password

4. このチュートリアルのアプリケーション・コンテキストとユーザーを削除します。

DROP CONTEXT provider_ctx;
DROP USER sysadmin_pg cascade;
DROP USER apps_user;

他のOracle機能でのOracle Virtual Private Databaseの使用

他のOracle機能(SELECT FOR UPDATE文、結合操作、アプリケーションおよびエディションなど)でOracle Virtual Private Database (VPD)を使用する場合の影響に注意してください。

内容は次のとおりです。

- 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 VPDポリシーでの透過的機密データ保護ポリシーの使用」

Oracle Virtual Private Databaseポリシーとエディション

エディションを扱う場合のOracle VPDの使用方法について理解しておく必要があります。

アプリケーションをエディションベースの再定義用に準備し、アプリケーションで使用される各表をエディショニング・ビューで保護する場合は、これらの表を保護する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 (VPD)と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で作成したラベルと比較します。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

関連項目:
支配ファンクションの詳細は、『Oracle Label Security管理者ガイド』を参照してください

Oracle Virtual Private DatabaseおよびOracle Label Securityの例外

Oracle Virtual Private DatabaseおよびOracle Label Securityを使用する場合は、次の例外に注意してください。

これらのセキュリティ例外を次に示します。

- データのエクスポート時、Oracle Virtual Private DatabaseおよびOracle Label Securityのポリシーはダイレクト・パス・エクスポート操作では規定されません。ダイレクト・パス・エクスポート操作では、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ユーザーは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値は、フェイルオーバーのためのセカンダリ・データベースには伝播されません。

関連項目:
ダイレクト・パス・エクスポート操作の詳細は、『Oracle Databaseユーティリティ』を参照してください

EXPDPユーティリティのaccess_methodパラメータを使用したデータのエクスポート

VPDポリシーが定義されているオブジェクトからデータをエクスポートする場合は注意してください。

access_methodパラメータがdirect_pathに設定されたOracle Data Pump Export (EXPDP)ユーティリティを使用して、データをスキーマからエクスポートしようとするとき、このスキーマに仮想プライベート・データベース・ポリシーが定義されているオブジェクトが含まれていると、ORA-31696エラー・メッセージが表示される場合があり、エクスポート操作は失敗します。

エラー・メッセージは次のとおりです。

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を使用すると、複数のグローバル・アプリケーション・コンテキストにアクセスする複数の接続が可能になり、接続プーリングが促進されます。この機能によって、個別ユーザー・セッションごとに別々のアプリケーション・コンテキストを確立する必要がなくなります。

表10-3に、Oracle Virtual Private Databaseをユーザー・モデルに適用する方法の要約を示します。

表10-3 様々なユーザー・モデルでのOracle Virtual Private Database

ユーザー・モデル

個別のデータベース接続

ユーザーごとの個別アプリケーション・コンテキスト

単一データベース接続

アプリケーションによるユーザー名の切替え

アプリケーション・ユーザーがデータベース・ユーザーでもある場合

あり

あり

なし

なし

OCIまたはJDBC/OCIを使用したプロキシ認証

あり

あり

なし

なし

エンタープライズ・ユーザー・セキュリティ脚注2と統合されたプロキシ認証

なし

なし

あり

あり

One Big Application User

なし

なし脚注3

なし

あり^2

Webベースのアプリケーション

なし

なし

あり

あり

脚注2

ユーザー・ロールとその他の属性(グローバルに初期化されたアプリケーション・コンテキストも含む)は、Oracle Internet Directoryから取得してOracle Virtual Private Databaseを規定できます。

脚注3

アプリケーション開発者は、個別アプリケーション・ユーザー(たとえば、REALUSER)を表すグローバル・アプリケーション・コンテキスト属性を作成できます。その後、この属性を使用して、各セッション属性を制御したり、監査することができます。

Oracle Virtual Private Databaseのデータ・ディクショナリ・ビュー

Oracle Databaseには、Oracle Virtual Private Databaseポリシーに関する情報を表示するデータ・ディクショナリ・ビューが用意されています。

表10-4に、仮想プライベート・データベース固有のビューを示します。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表10-4 VPDポリシーに関する情報を表示するデータ・ディクショナリ・ビュー

ビュー

説明

ALL_POLICIES

現行ユーザーがアクセス可能なオブジェクトに対するすべてのOracle Virtual Private Databaseセキュリティ・ポリシーが表示されます。

ALL_POLICY_ATTRIBUTES

ログインしたユーザーがVPDポリシーの所有者であるか、VPDポリシーがPUBLICに属する場合のすべてのアプリケーション・コンテキスト・ネームスペース、属性および仮想プライベート・データベース・ポリシーの関連付けが表示されます。

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_ATTRIBUTES

状況依存および共有の状況依存仮想プライベート・データベース・ポリシーのすべてのアプリケーション・コンテキスト・ネームスペース、属性および仮想プライベート・データベース・ポリシーの関連付けが表示されます。

DBA_POLICY_GROUPS

データベース内のすべてのポリシー・グループが表示されます。

DBA_POLICY_CONTEXTS

データベース内のすべての駆動コンテキストが表示されます。このビューの列は、ALL_POLICY_CONTEXTSの各列と同じです。

DBA_SEC_RELEVANT_COLS

データベース内のすべてのセキュリティ・ポリシーのセキュリティ関連列が表示されます。

USER_POLICIES

現行ユーザーが所有するオブジェクトに対応付けられたすべてのOracle Virtual Private Databaseセキュリティ・ポリシーが表示されます。このビューにはOBJECT_OWNER列が表示されません。

USER_POLICY_ATTRIBUTES

仮想プライベート・データベース・ポリシーの所有者が現在のユーザーである場合のすべてのアプリケーション・コンテキスト・ネームスペース、属性および仮想プライベート・データベース・ポリシーの関連付けが表示されます。

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

現在のPDBの場合、現在ライブラリ・キャッシュにキャッシュされているカーソルに対応付けられた、すべてのファイングレイン・セキュリティ・ポリシーと述語が表示されます。このビューは、SQL文に適用されたポリシーを検索するのに便利です。

ヒント:

仮想プライベート・データベース・ポリシーを使用するアプリケーションでエラーが見つかった場合は、これらのビューに加え、データベース・トレース・ファイルも確認してください。トレース・ファイルの詳細は、Oracle Database SQLチューニング・ガイドを参照してください。USER_DUMP_DEST初期化パラメータは、トレース・ファイルの現在の位置を示します。このパラメータの値は、SQL*PlusでSHOW PARAMETER USER_DUMP_DESTを発行して確認できます。

11 透過的機密データ保護の使用

透過的機密データ保護により、機密データを保持するデータベースのすべての表の列を確認できます。

内容は次のとおりです。

- 透過的機密データ保護について

- 透過的機密データ保護を使用する一般的な手順

- 透過的機密データ保護ポリシーのユースケース

- 透過的機密データ保護の使用に必要な権限

- マルチテナント環境が透過的機密データ保護に影響を与えるしくみ

- 透過的機密データ保護ポリシーの作成

- 透過的機密データ保護ポリシーの変更

- 透過的機密データ保護ポリシーの無効化

- 透過的機密データ保護ポリシーの削除

- 事前定義のREDACT_AUDITポリシーを使用したバインド値のマスク

- データ・リダクションでの透過的機密データ保護ポリシー

- Oracle VPDポリシーでの透過的機密データ保護ポリシーの使用

- 透過的機密データ保護のデータ・ディクショナリ・ビュー

透過的機密データ保護について

透過的機密データ保護は、機密情報を保持する列を表から探し出して分類するための手段です。

この機能を使用して、機密データを保持する列をデータベース表で特定し、このデータを分類して、指定されたクラスのこのデータ全体を保護するポリシーを作成できます。この種の機密データの例としては、クレジット・カード番号や社会保障番号などがあります。

TSDPポリシーは、次にOracle Data RedactionまたはOracle Virtual Private Databaseのいずれかの設定を使用して、これらの表の列の機密データを保護します。TSDPポリシーが保護する表の列レベルで適用され、クレジット・カード情報を含むすべてのNUMBERデータ型の列などの特定の列のデータ型を対象とします。分類するすべてのデータの均一のTSDPポリシーを作成して、コンプライアンス規制が変更される場合に必要に応じてこのポリシーを変更できます。オプションで、他のデータベースで使用するTSDPポリシーをエクスポートできます。

TSDPポリシーの利点は多くあります。多数のデータベースを使用する大きい組織全体にTSDPポリシーを簡単に作成および適用できます。これにより、TSDPポリシーが対象とするデータの保護を見積もることが可能なため、監査者にとって非常に便利です。TSDPは、似たセキュリティ制限を持つデータが多くあり、ポリシーをこのすべてのデータに一貫して適用する必要がある政府の環境に特に役立ちます。ポリシーは、リダクション、暗号化、そのアクセスの制御、そのアクセスの監査、監査証跡でのマスクを行うことができます。TSDPを使用しない場合、各リダクション・ポリシー、列レベルの暗号化構成および列ごとの仮想プライベート・データベース・ポリシーを構成する必要があります。

透過的機密データ保護を使用する一般的な手順

Oracle Data RedactionでTSDPを使用するには、次の一般的な手順に従う必要があります。

1. 機密タイプを作成して、保護する列のタイプを分類します。

たとえば、すべての社会保障番号やクレジット・カード番号を分類するための機密タイプを作成できます。機密タイプを作成するには、DBMS_TSDP_MANAGE.ADD_SENSITIVE_TYPE PL/SQLプロシージャを使用するか、Enterprise Manager Cloud Controlアプリケーション・データ・モデルを使用します。アプリケーション・データ・モデルから1つの操作で複数の機密タイプを追加するには、DBMS_TSDP_MANAGE.IMPORT_SENSITIVE_TYPESプロシージャを使用できます。

2. 機密タイプに関連付けられる機密列のリストを識別します。

このリストを決定および生成するには、次の方法のいずれかを使用できます。

- DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMNプロシージャは、機密列を個々に識別します。

- Oracle Enterprise Manager Cloud Controlアプリケーション・データ・モデルにより、機密列のグループを識別できます。XML形式でこのリストの機密列を準備し、データベースにインポートします。

3. 手順2のアプリケーション・データ・モデルを使用した場合、DBMS_TSDP_MANAGE.IMPORT_DISCOVERY_RESULTプロシージャを使用して、アプリケーション・データ・モデルから機密列のリストをデータベースにインポートします。

4. 使用するデータ・リダクションまたは仮想プライベート・データベースの設定を定義する無名ブロック内のDBMS_TSDP_PROTECT.ADD_POLICYプロシージャを使用して、TSDPポリシーを作成します。

5. DBMS_TSDP_PROTECT.ASSOCIATE_POLICYプロシージャを使用して、TSDPポリシーを1つ以上の機密タイプと関連付けます。

6. DBMS_TSDP_PROTECT.ENABLE_PROTECTION_SOURCE、DBMS_TSDP_PROTECT.ENABLE_PROTECTION_COLUMNまたはDBMS_TSDP_PROTECT.ENABLE_PROTECTION_TYPEプロシージャを使用して、TSDPポリシー保護を有効化します。

7. オプションで、Oracle Data Pumpを使用してフル・データベース・エクスポートを実行して、TSDPポリシーを他のデータベースにエクスポートします。(TSDPポリシーを個々にエクスポートできません。)

透過的機密データ保護ポリシーのユースケース

透過的機密データ保護には、次の利点があります。

これらの利点は次のとおりです。

- 機密データ保護を一度構成して、必要に応じてこの保護をデプロイします。 透過的機密データ保護ポリシーを構成して、実際にターゲット・データを指定することなくどのようにデータのクラス(たとえば、クレジット・カード列など)を保護する必要があるかを指定できます。つまり、透過的機密データ保護ポリシーを作成する場合、保護する実際のターゲット列の参照を含む必要がありません。透過的機密データ保護ポリシーは、データベースの機密列のリストおよび指定された機密タイプのポリシーの関連付けに基づいて、これらのターゲット列を確認します。これは、透過的機密データ保護ポリシーを作成した後に追加の機密データをデータベースに追加する場合に便利です。ポリシーを作成した後、単一の手順で機密データの保護を有効化できます(たとえば、ソース・データベース全体に基づく保護の有効化など)。新しいデータの機密タイプ、機密タイプおよびポリシーの関連付けは、機密データの保護方法を決定します。これによって、新しい機密データが追加される場合、現在の透過的機密データ保護ポリシーの要件を満たしているかぎり、保護を構成する必要がありません。

- 複数の機密列の保護を管理できます。適切な属性(ソース・データベースの識別、機密タイプ自体、特定のスキーマ、表、列など)に基づいて複数の機密列の保護を有効化または無効化できます。この精度により、データ・セキュリティの上位レベルの制御が提供されます。この機能の設計により、これらのコンプライアンス規制の範囲に該当する大きいデータ・セットの特定のコンプライアンス要件に基づいてデータ・セキュリティを管理できます。個別の列ごとではなく特定のカテゴリに基づいて、データ・セキュリティを構成できます。たとえば、クレジット・カード番号または社会保障番号の保護を構成できますが、このデータを含むデータベースの各列の保護を構成する必要はありません。

- Oracle Enterprise Manager Cloud Controlアプリケーション・データ・モデル(ADM)機能を使用して識別された機密列を保護できます。Cloud Control ADM機能を使用して、機密タイプを作成し、機密列のリストで検出できます。次に、このリストの機密列および対応する機密タイプをデータベースにインポートできます。そこから、この情報を使用して、透過的機密データ保護ポリシーを作成および管理できます。

透過的機密データ保護の使用に必要な権限

透過的機密データ保護を使用するには、次のPL/SQLパッケージに対するEXECUTE権限が必要です。

これらの権限は次のとおりです。

- 機密列および機密タイプをデータベースにインポートして管理できるDBMS_TSDP_MANAGE。このパッケージのプロシージャは、実行者権限で実行されます。通常、アプリケーション・データベース管理者には、このパッケージの権限が付与されます。

- TSDPポリシーの作成に使用されるDBMS_TSDP_PROTECT。このパッケージのプロシージャは、実行者権限で実行されます。通常、セキュリティ・データベース管理者には、このパッケージの権限が付与されます。

- データ・リダクション・ポリシーを作成する場合のDBMS_REDACT。通常、セキュリティ・データベース管理者には、このパッケージの権限が付与されます。

- Oracle Virtual Private Database機能をTSDPポリシーに組み込む場合のDBMS_RLS。通常、セキュリティ・データベース管理者には、このパッケージの権限が付与されます。

業務分離を強化するために、アプリケーション・データベース管理者がTSDPポリシー作成の1つの領域(DBMS_TSDP_MANAGEパッケージの場合と同様)を制御するか、セキュリティ・データベース管理者(DBMS_TSDP_PROTECT、DBMS_REDACTおよびDBMS_RLSパッケージ用)が制御できるように、これらのパッケージが設計されています。

マルチテナント環境が透過的機密データ保護に影響を与えるしくみ

マルチテナント環境では、TSDPポリシーを現在のPDBのみに適用できます。

TSDPポリシーをマルチテナント・コンテナ・データベース(CDB)全体に適用することはできません。これは、コンテナで使用するために、TSDPポリシーが現在のPDBでユーザーが作成したオブジェクト用に設計されているためです。DBA_TSDP_POLICY_FEATUREデータ・ディクショナリ・ビューを問い合せて、TSDPポリシー、および関連付けられているセキュリティ機能のリストを確認できます。すべてのPDBを検索するには、DBA_PDBSビューを問い合せます。

透過的機密データ保護ポリシーの作成

透過的機密データ保護ポリシーを作成する前に、機密タイプを作成し、保護が必要な機密列を確認して、機密列をADMからデータベースにインポートする必要があります。

内容は次のとおりです。

- 手順1: 機密タイプの作成

- 手順2: 保護する機密列の識別

- 手順3: ADMからデータベースへの機密列リストのインポート

- 手順4: 透過的機密データ保護ポリシーの作成

- 手順5: ポリシーと機密タイプの関連付け

- 手順6: 透過的機密データ保護ポリシーの有効化

- 手順7: 他のデータベースへのポリシーのエクスポート(オプション)

手順1: 機密タイプの作成

機密タイプは、機密として指定するデータのクラスです。

たとえば、すべてのクレジット・カード番号のcredit_card_type機密タイプを作成できます。

- 機密タイプを作成するには、Enterprise Manager Cloud Controlアプリケーション・データ・モデルから機密タイプを作成するか、DBMS_TSDP_MANAGE.ADD_SENSITIVE_TYPE PL/SQLプロシージャを使用します。
機密タイプを削除するには、DBMS_TSDP_MANAGE.DROP_SENSITIVE_TYPEプロシージャを使用します。

次に、機密タイプcredit_card_num_typeを作成する例を示します。

BEGIN
DBMS_TSDP_MANAGE.ADD_SENSITIVE_TYPE (
sensitive_type  => 'credit_card_num_type',
user_comment    => 'Type for credit card columns using a number data type');
END;
/

この例の説明は、次のとおりです。

- sensitive_type: 取得する機密タイプを説明する名前を作成します。この値は大/小文字を区別するので、後で参照する場合は、作成した大/小文字を使用していることを確認してください。DBA_SENSITIVE_COLUMN_TYPESデータ・ディクショナリ・ビューを問い合せて、既存の機密タイプを確認できます。

- user_comment: オプションで、機密タイプの説明を入力します。

関連項目:

- アプリケーション・データ・モデルの詳細は、Oracle Database Testingガイドを参照してください。

- DBMS_TSDP_MANAGE.ADD_SENSITIVE_TYPE PL/SQLプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

手順2: 保護する機密列の識別

機密列を定義したら、保護する列を特定します。

保護する列を識別するには、定義した機密タイプに基づいて、Enterprise Manager Cloud Controlアプリケーション・データ・モデルを使用してこれらの列を識別するか、DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMNプロシージャを使用できます。

データベースの機密列のリストから列を削除するには、DBMS_TSDP_MANAGE.DROP_SENSITIVE_COLUMNプロシージャを使用します。

1. 使用する機密タイプを確認します。

例:

SELECT NAME FROM DBA_SENSITIVE_COLUMN_TYPES;

NAME
---------------------
credit_card_num_type

2. DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMNプロシージャを実行して、機密タイプと表の列を関連付けます。機密タイプの作成に使用された大/小文字を使用してsensitive_typeパラメータを入力していることを確認します。

例:

BEGIN
DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMN(
schema_name        => 'OE',
table_name         => 'CUST_CC',
column_name        => 'CREDIT_CARD',
sensitive_type     => 'credit_card_num_type',
user_comment       => 'Sensitive column addition of credit_card_num_type');
END;
/

手順3: ADMからデータベースへの機密列リストのインポート

次に、ADMからデータベースに機密列リストをインポートします。

- アプリケーション・データ・モデルを使用して機密列のリストを作成した場合、DBMS_TSDP_MANAGE.IMPORT_DISCOVERY_RESULTプロシージャを実行して、このリストをデータベースにインポートします。
DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMNプロシージャを使用してこれらの列を識別した場合、この手順を回避できます。

次に、Cloud Controlアプリケーション・データ・モデルを現在のデータベースにインポートする例を示します。

BEGIN
DBMS_TSDP_MANAGE.IMPORT_DISCOVERY_RESULT (
discovery_result      => xml_adm_result,
discovery_source      => 'ADM_Demo');
END;
/

この例の説明は、次のとおりです。

- discovery_resultは、機密列および関連付けられている機密タイプのリストを表します。このリストはXML形式です。

- discover_sourceは、discovery_result設定で参照された機密列のリストを含むアプリケーション・データ・モデルの名前を表します。Enterprise Manager Cloud Controlのデータ検出およびモデリング・ページからアプリケーション・データ・モデルのリストを確認できます。(このページにアクセスするには、「エンタープライズ」メニューから、「クオリティ管理」、「データ検出およびモデリング」の順に選択します。「機密列」タブで、機密列および関連付けられているタイプのリストを確認できます。)

手順4: 透過的機密データ保護ポリシーの作成

機密列の特定後、アプリケーション・データ・モデルを使用して機密列のリストを作成し、このリストをデータベースにインポートした場合、透過的機密データ保護ポリシーを作成します。

内容は次のとおりです。

- 透過的機密データ保護ポリシーの作成について

- 透過的機密データ保護ポリシーの作成

- Oracle Data Redactionまたは仮想プライベート・データベース機能オプションの設定

- 透過的機密データ保護ポリシーの条件の設定

- DBMS_TSDP_PROTECT.ADD_POLICYプロシージャの指定

透過的機密データ保護ポリシーの作成について

DBMS_TSDP_PROTECT.ADD_POLICYプロシージャは、透過的機密データ保護ポリシーを作成します。

機密列の特定後、アプリケーション・データ・モデルを使用して機密列のリストを作成し、このリストをデータベースにインポートしたら、透過的機密データ保護ポリシーを作成します。透過的機密データ保護ポリシーを作成するには、使用する仮想プライベート・データベースまたはOracle Data Redaction設定にポリシーを構成し、これらの設定をDBMS_TSDP_PROTECT.ADD_POLICYで定義された透過的機密データ保護ポリシーに適用します。

次の構成要素を持つ無名ブロックを定義して、ポリシーを作成できます。

- ポリシーにOracle Data Redactionを使用している場合、部分的なデータ・リダクションなど、使用するデータ・リダクションのタイプの指定

- ポリシーにOracle Virtual Private Databaseを使用している場合、使用するVPD設定の指定

- ポリシーを有効にする場合にテストする条件。たとえば、ポリシーを有効にする前に満たす必要がある列のデータ型など。

- DBMS_TSDP_PROTECT.ADD_POLICYプロシージャを使用して、これらの構成要素を結合する名前付きの透過的機密データ保護ポリシー

機密タイプが作成された後、SYSスキーマに配置されます。

関連トピック

- チュートリアル: 仮想プライベート・データベース保護を使用するTSDPポリシーの作成

透過的機密データ保護ポリシーの作成

部分的な数値データ型ベースのデータ・リダクション・ポリシーを使用する透過的機密データ保護ポリシーを作成できます。

例11-1に、このタイプのポリシーを作成する方法を示します。

- ポリシーを作成するには、例11-1に示すように、DBMS_TSDP_PROTECT.ADD_POLICYプロシージャを使用します。

例11-1 透過的機密データ保護ポリシーの作成

DECLARE
redact_feature_options DBMS_TSDP_PROTECT.FEATURE_OPTIONS;
policy_conditions DBMS_TSDP_PROTECT.POLICY_CONDITIONS;
BEGIN
redact_feature_options ('expression') :=
'SYS_CONTEXT(''USERENV'',''SESSION_USER'') =''APPUSER''';
redact_feature_options ('function_type') := 'DBMS_REDACT.PARTIAL';
redact_feature_options ('function_parameters') := '0,1,6';
policy_conditions(DBMS_TSDP_PROTECT.DATATYPE) := 'NUMBER';
policy_conditions(DBMS_TSDP_PROTECT.LENGTH) := '16';
DBMS_TSDP_PROTECT.ADD_POLICY ('redact_partial_cc',
DBMS_TSDP_PROTECT.REDACT,redact_feature_options,
policy_conditions);
END;
/

この例の説明は、次のとおりです。

- redact_feature_options DBMS_TSDP_PROTECT.FEATURE_OPTIONSは、FEATURE_OPTIONSデータ型を使用する変数redact_feature_optionsを作成します。詳細は、Oracle Data Redactionまたは仮想プライベート・データベース機能オプションの設定を参照してください。

- policy_conditions DBMS_TSDP_PROTECT.POLICY_CONDITIONSは、POLICY_CONDITIONSデータ型を使用する変数policy_conditionsを作成します。詳細は、透過的機密データ保護ポリシーの条件の設定を参照してください。

- redact_feature_optionsの3行目は、データ・リダクション・ポリシー設定をredact_feature_option変数に書き込みます。この例では、データ・リダクション・ポリシーをユーザーAPPUSERに適用して、数値データ型の部分的なデータ・リダクションとしてポリシーを定義します。この場合のfunction_parametersパラメータの使用方法の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

- policy_conditionsの2行目は、TSDPポリシー条件を保護されたNUMBERデータ型の列のpolicy_conditions変数(つまり、データ型および長さ)に書き込みます。

- DBMS_TSDP_PROTECT.ADD_POLICYは、redact_partial_cc TSDPポリシーを作成するDBMS_TSDP_PROTECT.ADD_POLICYプロシージャを実行します。詳細は、DBMS_TSDP_PROTECT.ADD_POLICYプロシージャの指定を参照してください。

VPD用の類似したポリシーの例を確認する場合は、手順4: 透過的機密データ保護ポリシーの作成および有効化を参照してください。

Oracle Data Redactionまたは仮想プライベート・データベース機能オプションの設定

TSDP機能オプションは、透過的機密データ保護ポリシーに使用するOracle Data Redactionまたは仮想プライベート・データベース設定を示します。

- Data Redactionの場合、redact_feature_options変数名を使用して機能オプションを定義し、型にはデータ型VARCHAR2(TSDP_PARAM_MAX)の結合配列であるDBMS_TSDP_PROTECT.FEATURE_OPTIONS型を使用する必要があります。DBMS_REDACT.ADD_POLICYパラメータに対応するパラメータと値のペアでこれらのオプションを初期化します。

たとえば、部分的なデータ・リダクションを使用するTSDPポリシーを指定する場合、例11-1に次のパラメータと値のペアを示します。

redact_feature_options ('function_type')       := 'DBMS_REDACT.PARTIAL';

保護された列の数値データ型を使用する部分的なデータ・リダクション・ポリシーの場合、例11-1では、次の追加のパラメータと値のペアを指定しています。

redact_feature_options ('expression')          := 'expression';
redact_feature_options ('function_parameters') := 'values';

同様に、仮想プライベート・データベースの場合、vpd_feature_options変数を使用して、VPD機能オプションを定義します。例:

vpd_feature_options ('statement_types')   := 'SELECT, INSERT, UPDATE, DELETE';

関連項目:

- データ・リダクション・ポリシー作成パラメータの詳細は、『Oracle Database Advanced Securityガイド』を参照してください

- 使用できるVPDパラメータの詳細は、TSDPポリシーに使用されるDBMS_RLS.ADD_POLICYパラメータを参照してください

透過的機密データ保護ポリシーの条件の設定

オプションで、透過的機密データ保護ポリシーの条件を指定できます。

ただし、条件を省略する場合、DECLARE変数の次の行を引き続き含む必要があります。(この場合、policy_conditionsのデフォルト値は、空の結合配列です。)

policy_conditions SYS.DBMS_TSDP_PROTECT.POLICY_CONDITIONS;

- 条件を定義するには、policy_conditions変数名を使用し、型にはデータ型VARCHAR2(TSDP_PARAM_MAX)の結合配列であるDBMS_TSDP_PROTECT.POLICY_CONDITIONS型を使用します。2つの条件が単一のターゲット機密列で満たされていることを確認します。ターゲット列のプロパティは、列に適用する対応するDBMS_TSDP_PROTECT.FEATURE_OPTIONS設定のすべての条件プロパティを満たす必要があります

例11-1は、次のポリシー条件を示しています。

policy_conditions(DBMS_TSDP_PROTECT.DATATYPE) := 'NUMBER';
policy_conditions(DBMS_TSDP_PROTECT.LENGTH)   := '16';

オプションで、POLICY_CONDITIONS設定の次の1つ以上のキーを指定できます。

- DBMS_TSDP_PROTECT.DATATYPEでは、データ型を指定できます。

- DBMS_TSDP_PROTECT.LENGTHでは、DBMS_TSDP_PROTECT.DATATYPEキーのデータ型の長さを指定できます。

- DBMS_TSDP_PROTECT.PARENT_SCHEMAでは、ポリシーを特定のスキーマに制限できます。この設定を省略すると、ポリシーはデータベースのすべてのスキーマに適用されます。

- DBMS_TSDP_PROTECT.PARENT_TABLEでは、ポリシーをDBMS_TSDP_PROTECT.PARENT_SCHEMAキーで指定された表に制限できます。この設定を省略すると、ポリシーは指定されたスキーマ内のすべての表に適用されます。

DBMS_TSDP_PROTECT.ADD_POLICYプロシージャの指定

DBMS_TSDP_PROTECT.ADD_POLICYプロシージャでTSDPポリシーに名前を付与し、FEATURE_OPTIONSおよびPOLICY_CONDITIONSの設定を実行します。

ポリシーでは、redact_feature_optionsとpolicy_conditions設定が連携します。ポリシーがターゲット・オブジェクトで有効な場合(DBMS_TSDP_PROTECT.ENABLE_PROTECTION*プロシージャを使用)、redact_feature_options設定は、対応するpolicy_condition設定を満たしている場合のみ適用されます。次のパラメータを入力します。

- 透過的機密データ保護ポリシーの名前を付け、必要な設定を実行するプロシージャを指定するには、次のパラメータを含めます。

- policy_nameは、TSDPポリシーの名前を作成します。入力する名前は、作成時に使用された大/小文字の区別が使用され、データベースに格納されます。たとえば、redact_partial_ccを入力した場合、データベースはredact_partial_ccではなくredact_partial_ccとして格納します。

- security_featureは、TSDPポリシーが使用するセキュリティ機能を表します。DBMS_TSDP_PROTECT.REDACTを入力して、Oracle Data Redactionを指定します。

- policy_enable_optionsは、DBMS_TSDP_PROTECT.FEATURE_OPTIONS型に定義された変数を表します。

- policy_apply_conditionは、DBMS_TSDP_PROTECT.POLICY_CONDITIONS型に定義された変数を表します。

例11-1は、次のポリシー・セットを示しています。

DBMS_TSDP_PROTECT.ADD_POLICY('redact_partial_cc', DBMS_TSDP_PROTECT.REDACT, redact_feature_options, policy_conditions);

手順5: ポリシーと機密タイプの関連付け

DBMS_TSDP_PROTECT.ASSOCIATE_POLICYプロシージャは、TSDPポリシーを機密タイプに関連付けます。

1. 使用する機密タイプを確認します。

すべての機密タイプのリストを確認する例を次に示します。

SELECT NAME FROM DBA_SENSITIVE_COLUMN_TYPES ORDER BY NAME;

NAME
--------------------
credit_card_num_type

2. DBMS_TSDP_PROTECT.ASSOCIATE_POLICYプロシージャを実行して、ポリシーと機密列タイプを関連付けます。

例:

BEGIN
DBMS_TSDP_PROTECT.ASSOCIATE_POLICY(
policy_name        => 'redact_partial_cc',
sensitive_type     => 'credit_card_num_type',
associate          => true);
END;
/

次の問合せは、credit_card_num_typeとredact_partial_ccポリシーが関連付けられたことを示します。

SELECT POLICY_NAME, SENSITIVE_TYPE FROM DBA_TSDP_POLICY_TYPE ORDER BY SENSITIVE_TYPE;

POLICY_NAME       SENSITIVE_TYPE
----------------- --------------------
redact_partial_cc  credit_card_num_type

手順6: 透過的機密データ保護ポリシーの有効化

保護されるソースの現在のデータベース、特定の表の列または特定の列タイプに対して透過的機密データ保護ポリシーを有効にすることができます。

内容は次のとおりです。

- 保護されたソースの現在のデータベースの保護の有効化

- 特定の表の列の保護の有効化

- 特定の列タイプの保護の有効化

保護されたソースの現在のデータベースの保護の有効化

保護されるソースの現在のデータベースに対して透過的機密データ保護を有効にすることができます。

保護を無効化する必要がある場合、DBMS_TSDP_PROTECT.DISABLE_PROTECTION_SOURCEプロシージャを実行します。

- このタイプの保護を有効にするには、DBMS_TSDP_PROTECT.ENABLE_PROTECTION_SOURCEプロシージャを実行します。

次に、orders_dbデータベースの透過的機密データ保護ポリシーを有効化する例を示します。

BEGIN
DBMS_TSDP_PROTECT.ENABLE_PROTECTION_SOURCE(
discovery_source       => 'orders_db');
END;
/

特定の表の列の保護の有効化

表の特定の列に対して透過的機密データ保護を有効にすることができます。

表ごとに1つのポリシーのみ有効化できることに注意してください。保護を無効化する必要がある場合、DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMNプロシージャを実行します。

- このタイプの保護を有効にするには、DBMS_TSDP_PROTECT.ENABLE_PROTECTION_COLUMNプロシージャを実行します。

次に、特定の表の列の透過的機密データ保護ポリシーredact_partial_ccを有効化する例を示します。

BEGIN
DBMS_TSDP_PROTECT.ENABLE_PROTECTION_COLUMN(
schema_name          => 'OE',
table_name           => 'CUST_CC',
column_name          => 'CREDIT_CARD',
policy               => 'redact_partial_cc');
END;
/

「ORA-45622: ポリシーの強制中に警告が生成されました」エラーが表示される場合、ポリシーの構成をチェックします。この例では、この列がNUMBERデータ型で長さが16の場合、redact_partial_ccポリシーが列で有効です。OE.CUST_CC.CREDIT_CARD列がredact_partial_ccポリシーに関連付けられていても、この列が条件(データ型および長さ)を満たさない場合はポリシーが無効です。

特定の列タイプの保護の有効化

VARCHAR2データ型を使用するすべての列など、特定の列タイプに対して透過的機密データ保護を有効にすることができます。

保護を無効化する必要がある場合、DBMS_TSDP_PROTECT.DISABLE_PROTECTION_TYPEプロシージャを実行します。

- このタイプの保護を有効にするには、DBMS_TSDP_PROTECT.ENABLE_PROTECTION_TYPEプロシージャを実行します。

次に、credit_card_num_type機密タイプを使用するすべての列の透過的機密データ保護を有効化する例を示します。

BEGIN
DBMS_TSDP_PROTECT.ENABLE_PROTECTION_TYPE(
sensitive_type           => 'credit_card_num_type');
END;
/

手順7: 他のデータベースへのポリシーのエクスポート(オプション)

別のデータベースに対してポリシーをエクスポートまたはインポートできます。

- 別のデータベースに対してTSDPポリシーをエクスポートまたはインポートするには、Oracle Data Pumpを使用して、ポリシーを含むデータベースのフル・エクスポートまたはインポートを実行します。

エクスポートおよびインポート操作が透過的機密データ保護ポリシーだけでなくデータベース全体に適用されるので注意してください。

関連項目:

- Oracle Data Pumpの使用方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

- Oracle Database Vault環境のOracle Data Pumpの使用の詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

透過的機密データ保護ポリシーの変更

DBMS_TSDP_PROTECT.ALTER_POLICYプロシージャで、TSDPポリシーを変更できます。

透過的データ保護ポリシーを変更する場合、データ・リダクション設定の変更方法を定義して、これらの変更を透過的機密データ保護ポリシー自体に適用する必要があります。

DBA_TSDP_POLICY_FEATUREデータ・ディクショナリ・ビューを問い合せて、既存のポリシーおよび保護定義のリストを確認できます。

- 透過的機密データ保護ポリシーを変更するには、DBMS_TSDP_PROTECT.ALTER_POLICYプロシージャを使用します。

次に、既存の透過的機密データ保護ポリシーを変更する例を示します。

DECLARE
redact_feature_options SYS.DBMS_TSDP_PROTECT.FEATURE_OPTIONS;
policy_conditions SYS.DBMS_TSDP_PROTECT.POLICY_CONDITIONS;
BEGIN
redact_feature_options ('expression') :=
'SYS_CONTEXT(''USERENV'',''SESSION_ USER'') =''APPUSER''';
redact_feature_options ('function_type') := 'DBMS_REDACT.PARTIAL';
redact_feature_options ('function_parameters') := '9,1,6';
policy_conditions(DBMS_TSDP_PROTECT.DATATYPE) := 'NUMBER';
policy_conditions(DBMS_TSDP_PROTECT.LENGTH) := '22';
DBMS_TSDP_PROTECT.ALTER_POLICY ('redact_partial_cc',
redact_feature_options, policy_conditions);
END;
/

この例の説明は、次のとおりです。

- redact_feature_options SYS.DBMS_TSDP_PROTECT.FEATURE_OPTIONSは、FEATURE_OPTIONSデータ型を使用する変数redact_feature_optionsを作成します。

- policy_conditions SYS.DBMS_TSDP_PROTECT.POLICY_CONDITIONSは、POLICY_CONDITIONSデータ型を使用する変数policy_conditionsを作成します。

- redact_feature_options ... redact_feature_optionsは、データ・リダクション・ポリシー設定をredact_feature_option変数に書き込みます。この例では、データ・リダクション・ポリシーをユーザーAPPUSERに適用して、数値データ型の部分的なデータ・リダクションとしてポリシーを定義します。この場合のfunction_parametersパラメータの使用方法の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

- policy_conditions ... policy_conditionsは、TSDPポリシー条件を保護されたNUMBERデータ型の列のpolicy_conditions変数(つまり、データ型および長さ)に書き込みます。

- DBMS_TSDP_PROTECT.ALTER_POLICY ...は、redact_partial_cc TSDPポリシーを変更してredact_feature_optionsおよびpolicy_conditions変数に設定された定義を使用するDBMS_TSDP_PROTECT.ALTER_POLICYプロシージャを実行します。

透過的機密データ保護ポリシーの無効化

DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMNプロシージャは1つまたはすべてのTSDPポリシーを無効にします。

1. DBA_TSDP_POLICY_PROTECTIONデータ・ディクショナリ・ビューを問い合せて、保護された列および関連付けられた透過的機密データ保護ポリシーを確認します。

例:

SELECT COLUMN_NAME, TSDP_POLICY FROM DBA_TSDP_POLICY_PROTECTION WHERE TABLE_NAME = 'CUST_CC';

COLUMN_NAME   TSDP_POLICY
------------  ------------------
CREDIT_CARD   redact_partial_cc

2. DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMNプロシージャを実行します。

CUST_CC表のCREDIT_CARD列のredact_partial_ccポリシーを無効化する例を次に示します。

BEGIN
DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN(
schema_name          => 'OE',
table_name           => 'CUST_CC',
column_name          => 'CREDIT_CARD',
policy               => 'redact_partial_cc');
END;
/

このプロシージャの%ワイルドカードを使用して、複数の項目を指定できます。たとえば、CREDITで始まる列の保護を無効化するには、次のように入力できます。

BEGIN
DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN(
schema_name          => 'OE',
table_name           => 'CUST_CC',
column_name          => 'CREDIT%',
policy               => 'redact_partial_cc');
END;
/

表のすべての透過的機密データ保護ポリシーを無効化するには、policyパラメータを省略できます。例:

BEGIN
DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN(
schema_name          => 'OE',
table_name           => 'CUST_CC',
column_name          => '%');
END;
/

透過的機密データ保護ポリシーの削除

TSDPポリシー全体を削除するか、またはポリシーから条件有効オプションの組合せを削除できます。

ポリシーが1つの条件有効オプションの組合せのみ持つ場合、Oracle Databaseはポリシー全体を削除します。削除する前にポリシーを無効化する必要はありませんが、関連付けられている機密列、機密タイプの順に削除する必要があります。

1. DBA_TSDP_POLICY_FEATUREデータ・ディクショナリ・ビューのPOLICY_NAME列を問い合せて、削除するポリシーを確認します。

SELECT POLICY_NAME FROM DBA_TSDP_POLICY_FEATURE;

POLICY_NAME
-----------------
redact_partial_cc

透過的機密データ保護データ・ディクショナリ・ビューを問い合せるには、SELECT_CATALOG_ROLEロールが付与されている必要があります。

2. このポリシーに関連付けられている機密列を確認します。

例:

SELECT COLUMN_NAME FROM DBA_TSDP_POLICY_PROTECTION WHERE TSDP_POLICY = 'redact_partial_cc';

COLUMN_NAME
-----------------
CREDIT_CARD

3. この機密列を削除します。

例:

BEGIN
DBMS_TSDP_MANAGE.DROP_SENSITIVE_COLUMN (
schema_name        => 'OE',
table_name         => 'CUST_CC',
column_name        => 'CREDIT_CARD');
END;
/

4. このポリシーに関連付けられている機密タイプを確認します。

例:

SELECT SENSITIVE_TYPE FROM DBA_TSDP_POLICY_TYPE WHERE POLICY_NAME = 'redact_partial_cc';

SENSITIVE_TYPE
--------------------
credit_card_num_type

5. この機密タイプを削除します。

例:

BEGIN
DBMS_TSDP_MANAGE.DROP_SENSITIVE_TYPE (   sensitive_type     => 'credit_card_num_type');END;
/

6. DBMS_TSDP_PROTECT.DROP_POLICYプロシージャを実行して、ポリシーを削除します。

ポリシーを完全に削除する例を次に示します。

BEGIN
DBMS_TSDP_PROTECT.DROP_POLICY(
policy_name     => 'redact_partial_cc');
END;
/

ポリシーからデフォルトの条件有効オプションの組合せを削除します。

DECLARE
policy_conditions DBMS_TSDP_PROTECT.POLICY_CONDITIONS;
BEGIN
DBMS_TSDP_PROTECT.DROP_POLICY ('redact_partial_cc', policy_conditions);
END;
/

特定の条件に基づいてポリシーからデフォルトの条件有効オプションを削除します。

DECLARE
policy_conditions DBMS_TSDP_PROTECT.POLICY_CONDITIONS;
BEGIN
policy_conditions (DBMS_TSDP_PROTECT.DATATYPE) := 'NUMBER';
DBMS_TSDP_PROTECT.DROP_POLICY ('redact_partial_cc', policy_conditions);
END;
/

事前定義のREDACT_AUDITポリシーを使用したバインド値のマスク

事前定義のREDACT_AUDITポリシーを使用してバインド値をマスクできます。これは、イベントの設定時にトレース・ファイルに表示されます。

内容は次のとおりです。

- REDACT_AUDITポリシーについて

- 機密列に関連付けられている変数

- ビューでの機密列のバインド変数の動作

- REDACT_AUDITポリシーの無効化

- REDACT_AUDITポリシーの有効化

REDACT_AUDITポリシーについて

事前定義のREDACT_AUDIT透過的機密データ保護ポリシーはバインド値をマスクします。

SQL文で使用されるバインド変数のバインド値は、監査の構成時に監査レコードに表示できます。同様に、バインド値は、適切なイベントの設定時にトレース・ファイルに表示できます。V$SQL_BIND_DATA動的ビューを問い合せる場合、バインド値も表示できます。

REDACT_AUDIT透過的機密データ保護ポリシーは、監査レコード、トレース・ファイルおよびV$SQL_BIND_DATAビューの問合せでアスタリスク(*)としてデータを表示します。デフォルトでは、REDACT_AUDITポリシーがデータベースの機密タイプに関連付けられます。機密として列を識別する場合、デフォルトではREDACT_AUDITポリシーが有効です。

REDACT_AUDITポリシーを無効化および有効化できますが、変更または削除できません。

機密列に関連付けられている変数

バインド変数は、条件やSELECTアイテム、INSERTまたはUPDATE操作のある機密列の使用に影響します。

内容は次のとおりです。

- 条件式のバインド変数および機密列

- 同じSELECT項目に表示されるバインド変数および機密列

- INSERTまたはUPDATE操作の機密列に割り当てられる式のバインド変数

条件式のバインド変数および機密列

WHERE句を含むSQL問合せに機密列を含めることができます。

WHERE句を含むSQL問合せには、比較演算子(=、IS、IS NOT、LIKE、BETWEEN、INなど)とともに使用したり、副問合せで使用する機密列およびバインド変数を含めることができます。

次の比較問合せでは、VAR1および機密列SALARYが比較条件>を使用して比較される式に表示されているため、VAR1のバインド値がマスクされます。

SELECT EMPLOYEE_ID FROM HR.EMPLOYEES WHERE SALARY > :VAR1;

次の問合せでは、VAR1、VAR2および機密列SALARYが比較等価条件=を使用する式に表示されているため、VAR1およびVAR2のバインド値がマスクされます。

SELECT EMPLOYEE_ID FROM HR.EMPLOYEES WHERE SALARY + :VAR1 = TO_NUMBER(:VAR2, '9G999D99');

浮動小数点条件の場合、機密列およびバインド変数が評価される式に表示されます。次の例では、VAR1および機密列SALARYがIS NOT NAN条件の式に表示されているため、VAR1のバインド値がマスクされます。

SELECT COUNT( ) FROM HR.EMPLOYEES WHERE (SALARY * :VAR1) IS NOT NAN;

パターン一致条件では、機密列およびバインド変数が引数として表示されます。次の例では、VAR1および機密列LAST_NAMEがLIKE条件の引数であるため、VAR1のバインド値がマスクされます。

SELECT LAST_NAME FROM HR.EMPLOYEES WHERE LAST_NAME LIKE :VAR1;

BETWEEN条件の場合、機密列およびバインド変数が引数である式に表示されます。次の例では、VAR1、VAR2およびSALARYがBETWEEN条件の引数である式に表示されているため、VAR1およびVAR2のバインド値がマスクされます。

SELECT EMPLOYEE_ID FROM HR.EMPLOYEES WHERE SALARY BETWEEN :VAR1 AND :VAR2;

次の例では、機密列およびバインド変数がIN条件の引数です。ここでは、VAR1、VAR2および機密列SALARYがIN条件の引数として表示されているため、VAR1およびVAR2のバインド値がマスクされます。

SELECT COUNT( ) FROM HR.EMPLOYEES WHERE SALARY IN ( :VAR1, :VAR2);

条件に引数としてネストされた副問合せがある場合、ネストされた副問合せに表示されるバインド変数および機密列は条件に関連付けられているとみなされません。次の問合せでは、機密列SALARY列および副問合せは、次より大きい条件>の式です。

SELECT EMPLOYEE_ID FROM HR.EMPLOYEES WHERE SALARY > (SELECT SALARY FROM HR.EMPLOYEES WHERE MANAGER_ID = :VAR1);

ただし、変数VAR1およびMANAGER_IDが条件=を使用して比較される式に表示されるため、変数VAR1が列MANAGER_IDに関連付けられます。MANAGER_IDが機密列ではないため、変数VAR1は機密とみなされません。変数VAR1は、機密列SALARYと関連付けられているとみなされません。

論理条件、モデル条件、多重集合条件、XML条件、複合条件、IS OF型条件およびEXISTS条件の場合、バインド変数および機密列が相互に関連付けられることはありません。これは、これらの条件の構造または性質のためです。

同じSELECT項目に表示されるバインド変数および機密列

SELECT項目の列が機密である場合、SELECT項目のすべてのバインドが機密とみなされます。

たとえば、HR.EMPLOYEES.SALARYおよびHR.EMPLOYEES.COMMISSION_PCTが機密列であるとします。次の問合せでは、機密列SALARYと同じSELECT項目に表示されているため、バインド変数VAR1が機密とみなされ、バインド値がマスクされます。

SELECT (SALARY * :VAR1) AS BONUS AS FROM HR.EMPLOYEES WHERE EMPLOYEE_ID = :VAR2;

次の例では、SALARYと同じSELECT項目に表示されているため、バインド変数VAR1が機密とみなされます。機密列COMMISSION_PCTと同じSELECT項目に表示されているため、VAR2が機密とみなされます。

SELECT (SALARY * :VAR1), (COMMISSION_PCT * :VAR2), (EMPNO + :VAR3) AS BONUS AS FROM PAYROLL.ACCOUNT;

INSERTまたはUPDATE操作の機密列に割り当てられる式のバインド変数

複数のバインド変数を1つのINSERTまたはUPDATE文の異なる列に割り当てることができます。

次のINSERT文を考えてみます。

INSERT INTO PAYROLL.ACCOUNT (ACCOUNT_NUM, SALARY) VALUES (:VAR1 * :VAR2 , :VAR3);

このINSERT文では、次が発生します。

- バインド変数VAR1およびVAR2が式(:VAR1 * :VAR2)に表示され、機密列ACCOUNT_NUMに割り当てられます。

- バインド変数VAR3が機密列SALARYに割り当てられます。

次のUPDATE文を考えてみます。

UPDATE PAYROLL.ACCOUNT SET ACCOUNT_NUM = :VAR1, SALARY = :VAR2;

このUPDATE文では、次が発生します。

- バインド変数VAR1が機密列ACCOUNT_NUMに割り当てられます。

- バインド変数VAR2が機密列SALARYに割り当てられます。

ビューでの機密列のバインド変数の動作

ビューの列が機密列を参照する場合、ビューの問合せに表示されるバインド変数が機密とみなされます。

たとえば、HR.EMPLOYEES表のSALARY列を機密と識別するとします。次に、ビューEMPLOYEES_VIEWを次のように作成します。

CREATE OR REPLACE VIEW HR.EMPLOYEES_VIEW AS SELECT * FROM HR.EMPLOYEES;

ユーザーがSQL文でこのビューからSALARY列を参照する場合、SALARY列に関連付けられているバインド変数が機密とみなされ、バインド値がマスクされます。

SELECT EMPLOYEE_ID FROM HR.EMPLOYEES_VIEW WHERE SALARY = :VAR1;

この場合、機密列HR.EMPLOYEES.SALARYを参照するHR.EMPLOYEES_VIEW.SALARY列に関連付けられているため、バインド変数VAR1がマスクされます。

REDACT_AUDITポリシーの無効化

デフォルトでは、REDACT_AUDITポリシーがすべての機密列に有効です。

特定の機密列またはすべての機密列に対して無効化できますが、必要に応じて再度有効化できます。REDACT_AUDITポリシーを変更または削除できないことに注意してください。

- REDACT_AUDITポリシーを無効化するには、DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMNプロシージャを使用します。

次に、HR.EMPLOYEESのSALARY列のREDACT_AUDITポリシーを無効化する例を示します。

BEGIN
DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN(
schema_name          => 'HR',
table_name           => 'EMPLOYEES',
column_name          => 'SALARY',
policy               => 'REDACT_AUDIT');
END;
/

次の例は、現在のデータベースのすべての機密列のREDACT_AUDITポリシーを無効化する方法を示します。

BEGIN
DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN(
policy               => 'REDACT_AUDIT');
END;
/

REDACT_AUDITポリシーの有効化

特定の機密列、またはデータベース内のすべての列に対してREDACT_AUDITポリシーを有効化できます。

- REDACT_AUDITポリシーを有効化するには、DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMNプロシージャを使用します。

次に、HR.EMPLOYEESのSALARY列のREDACT_AUDITポリシーを再有効化する例を示します。

BEGIN
DBMS_TSDP_PROTECT.ENABLE_PROTECTION_COLUMN(
schema_name          => 'HR',
table_name           => 'EMPLOYEES',
column_name          => 'SALARY',
policy               => 'REDACT_AUDIT');
END;
/

次の例は、現在のデータベースのすべての機密列のREDACT_AUDITポリシーを有効化する方法を示します。

BEGIN
DBMS_TSDP_PROTECT.ENSABLE_PROTECTION_COLUMN(
policy               => 'REDACT_AUDIT');
END;
/

データ・リダクションでの透過的機密データ保護ポリシー

Oracle Data Redaction機能を透過的機密データ保護ポリシーで使用できます。

Data Redactionの関数タイプ、関数パラメータおよび式をTSDPポリシーの定義に使用できます。たとえば、TSDPポリシーの有効化を設定して、FULLまたはPARTIALデータ・リダクションを使用できます。この章では、TSDPポリシーを管理する例としてデータ・リダクションを使用します。

関連項目:

- データ・リダクション関数タイプを使用するTSDPポリシーの作成方法の例は、透過的機密データ保護ポリシーの作成を参照してください

- Oracle Data Redactionの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

Oracle VPDポリシーでの透過的機密データ保護ポリシーの使用

透過的機密データ保護およびOracle Virtual Private Databaseプロシージャを使用すると、これら2つの機能の保護を組み合せることができます。

内容は次のとおりです。

- TSDPポリシーとOracle Virtual Private Databaseポリシーの併用について

- TSDPポリシーに使用されるDBMS_RLS.ADD_POLICYパラメータ

- チュートリアル: 仮想プライベート・データベース保護を使用するTSDPポリシーの作成

TSDPポリシーとOracle Virtual Private Databaseポリシーの併用について

Oracle Virtual Private Database保護を透過的機密データ保護ポリシーに組み込むには、DBMS_TSDP_PROTECTおよびDBMS_RLSパッケージを使用する必要があります。

この機能の手順は次のとおりです。

1. 適切な述語を使用して、VPDポリシー関数を作成します。後で、TSDPポリシーを作成する場合、DBMS_TSDP_PROTECT.ADD_POLICYプロシージャのfeature_optionsパラメータにDBMS_RLS.ADD_POLICYプロシージャのpolicy_function設定を使用して、このVPDポリシー関数を参照します。

VPD関数の詳細は、動的なWHERE句を生成する関数を参照してください。

2. VPDポリシー関数と似ている必要なVPD設定を使用して、TSDPポリシーを作成します。
TSDPポリシーは、DBMS_RLS.ADD_POLICYプロシージャのパラメータ設定を使用して、VPD保護を提供します。表11-1に、これらのパラメータを示します。DBMS_RLS.ADD_GROUPED_POLICYポリシーのパラメータはサポートされていないので注意してください。

3. DBMS_TSDP_PROTECT.ASSOCIATE_POLICYプロシージャを使用して、TSDPポリシーを必要な機密タイプと関連付けます。

4. 次に、DBMS_TSDP_PROTECT.ENABLE_PROTECTION_*プロシージャのいずれかを使用して、TSDP保護を有効化します。

5. TSDPポリシーを有効化します。この時点で、Oracle Databaseは、手順1で作成した関数を使用する内部VPDポリシーを作成します。
内部ポリシーの名前は、ORA$VPDで始まり、識別子と続きます(たとえば、ORA$VPD_6J6L3RSJSN2VAN0XFなど)。このポリシーは、DBA_POLICIESデータ・ディクショナリ・ビューのPOLICY_NAME列に問い合せて確認できます。

6. ユーザーが表を問い合せる場合、列の出力は、現在設定されているVPD保護およびTSDPポリシーに基づきます。

7. この列のTSDPポリシーを無効化するまで、これらの保護は残ります。この時点で、不要になるため、Oracle Databaseが内部VPDポリシーを自動的に削除します。TSDPポリシーを再度有効化すると、内部VPDポリシーが再作成されます。

TSDPポリシーに使用されるDBMS_RLS.ADD_POLICYパラメータ

Oracle Databaseには、TSDPポリシーの動作を調整するための一連のパラメータが用意されています。

表11-1に、DBMS_TSDP_PROTECT.ADD_POLICYまたはDBMS_TSDP_PROTECT.ALTER_POLICYプロシージャを使用する場合にFEATURE_OPTIONSパラメータで許可できるDBMS_RLS.ADD_POLICYパラメータを示します。

表11-1 TSDPポリシーに使用されるDBMS_RLS.ADD_POLICYパラメータ

パラメータ

説明

デフォルト

function_schema

ポリシー・ファンクションのスキーマ(NULLの場合は現行のデフォルト・スキーマ)。function_schemaが指定されていない場合は、現在のユーザーのスキーマと想定されます。

NULL

policy_function

ポリシーの述語を生成するファンクションの名前。関数がパッケージ内で定義される場合、パッケージの名前(たとえば、my_package.my_functionなど)を含む必要があります。

NULL

statement_types

ポリシーを適用する文タイプ。INDEX、SELECT、INSERT、UPDATEまたはDELETEを任意に組み合せることができます。デフォルトでは、これらの中からINDEX以外のほとんどのタイプが適用されます。

NULL

update_check

文タイプINSERTまたはUPDATEに対するオプションの引数。update_checkをTRUEに設定すると、Oracle Databaseは、INSERTまたはUPDATE操作後に値に対してポリシーをチェックします。

チェックは、ポリシー定義に含まれているセキュリティ関連の列にのみ適用されます。つまり、ポリシーで定義されているセキュリティ関連の列がINSERTまたはUPDATE文で追加または更新された場合にのみ、INSERT操作またはUPDATE操作が失敗します。

FALSE

static_policy

この値がTRUEに設定されている場合は、オブジェクトにアクセスするすべてのユーザー(ただし、SYSまたはEXEMPT ACCESS POLICY権限を持つ特権ユーザーを除く)に対して、静的ポリシーのポリシー・ファンクションが同一の述語文字列を生成するものとOracle Databaseはみなします。

FALSE

policy_type

デフォルト値のNULLは、policy_typeがstatic_policyパラメータの値によって決定されることを意味します。この中から指定したポリシー・タイプは、static_policyの値よりも優先されます。

NULL

long_predicate

デフォルト値のFALSEは、ポリシー・ファンクションから最大4000バイト長の述語が戻されることを意味します。TRUEは、述語テキスト文字列の長さを最大32Kバイトにできることを意味します。long_predicateパラメータを使用する前に存在するポリシーは、32K制限を保持します。

FALSE

sec_relevant_cols_opt

このパラメータを指定すると、透過的機密データ保護は、DBMS_RLS.ADD_POLICYプロシージャのsec_relevant_colsパラメータに対して保護が有効な機密列を入力します。

sec_relevant_cols_optの許可された値は次のとおりです。

- NULLは、sec_relevant_colsで定義されたフィルタ処理を有効にします。

- DBMS_RLS.ALL_ROWSはすべての行を表示しますが、機密情報の列の値があると、列の値がsec_relevant_colsパラメータでフィルタ処理されるため、NULLが表示されます。

NULL

DBMS_RLS.ADD_POLICY PL/SQLプロシージャの詳細は、「データベース表、ビューまたはシノニムへのポリシーの付加」も参照してください。

チュートリアル: 仮想プライベート・データベース保護を使用するTSDPポリシーの作成

このチュートリアルでは、Oracle Virtual Private Database保護を透過的機密データ保護ポリシーに組み込む方法を示します。

- 手順1: hr_appuserユーザー・アカウントの作成

- 手順2: 機密列の識別

- 手順3: Oracle Virtual Private Database関数の作成

- 手順4: 透過的機密データ保護ポリシーの作成および有効化

- 手順5: 透過的機密データ保護ポリシーのテスト

- 手順6: このチュートリアルのコンポーネントの削除

手順1: hr_appuserユーザー・アカウントの作成

まず、サンプル・ユーザー・アカウントを作成し、このユーザーに適切な権限を付与する必要があります。

1. SYSDBA管理権限を持つユーザーSYSとして、データベース・インスタンスにログインします。

sqlplus sys as sysdba
Enter password: password

2. マルチテナント環境を使用している場合は、適切なプラガブル・データベース(PDB)に接続します。

例:

CONNECT SYS@hrpdb AS SYSDBA
Enter password: password

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. 次のユーザー・アカウントを作成します。

GRANT CREATE SESSION TO hr_appuser IDENTIFIED BY password;
GRANT CREATE SESSION TO tsdp_admin IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。詳細は、パスワードの最低要件を参照してください。

4. ユーザーtsdp_adminに次の権限を付与します。

GRANT CREATE PROCEDURE TO tsdp_admin;
GRANT EXECUTE ON DBMS_TSDP_MANAGE TO tsdp_admin;
GRANT EXECUTE ON DBMS_TSDP_PROTECT TO tsdp_admin;
GRANT EXECUTE ON DBMS_RLS to tsdp_admin;

5. ユーザーSCOTTとして接続します。

CONNECT SCOTT -- Or, CONNECT SCOTT@hrpdb
Enter password: password

6. hr_appuserにEMP表のREADオブジェクト権限を付与します。

GRANT READ ON EMP TO hr_appuser;

手順2: 機密列の識別

サンプル・ユーザーtsdp_adminとして、保護する機密データを特定します。

1. ユーザーtsdp_adminとして接続します。

CONNECT tsdp_admin -- Or, CONNECT tsdb_admin@hrpdb
Enter password: password

2. salary_type機密タイプを作成します。

BEGIN
DBMS_TSDP_MANAGE.ADD_SENSITIVE_TYPE (
sensitive_type  => 'salary_type',
user_comment    => 'Type for SCOTT.EMP column');
END;
/

3. salary_type機密タイプとSCOTT.EMP表を関連付けます。

BEGIN
DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMN (
schema_name        => 'SCOTT',
table_name         => 'EMP',
column_name        => 'SAL',
sensitive_type     => 'salary_type',
user_comment       => 'Sensitive column addition of SALARY_TYPE');
END;
/

手順3: Oracle Virtual Private Database関数の作成

TSDPはOracle VPDポリシー関数を、TSDPポリシーが有効になったときに自動作成されるVPDポリシーに関連付けます。

- VPDポリシー関数を作成するには、CREATE OR REPLACE FUNCTIONプロシージャを次のように使用します。

CREATE OR REPLACE FUNCTION vpd_function (
v_schema IN VARCHAR2,
v_objname IN VARCHAR2)
RETURN VARCHAR2 AS
BEGIN
RETURN 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''HR_APPUSER''';
END vpd_function;
/

手順4: 透過的機密データ保護ポリシーの作成および有効化

VPDポリシー関数の作成後、その関数を透過的機密データ保護ポリシーに関連付けることができます。

1. 透過的機密データ保護ポリシーを作成します。

DECLARE
vpd_feature_options DBMS_TSDP_PROTECT.FEATURE_OPTIONS;
policy_conditions DBMS_TSDP_PROTECT.POLICY_CONDITIONS;
BEGIN
vpd_feature_options ('policy_function') := 'vpd_function';
vpd_feature_options ('sec_relevant_cols_opt') := 'DBMS_RLS.ALL_ROWS';
dbms_tsdp_protect.add_policy('tsdp_vpd', DBMS_TSDP_PROTECT.VPD, vpd_feature_options, policy_conditions);
END;
/

この例では、vpd_feature_optionsパラメータは、DBMS_RLS.ADD_POLICYプロシージャからsec_relevant_cols_optパラメータを参照します。TSDPポリシーを有効にすると、自動的に作成されるVPDポリシーは、DBMS_RLS.ADD_POLICYのsec_relevant_colsパラメータをTSDPによってVPDポリシーが有効になる機密列の名前に設定します。sec_relevant_cols_optパラメータを使用しなかった場合、TSDPはDBMS_RLS.ADD_POLICY sec_relevant_cols_optパラメータを使用していません。

2. tsdp_vpd1 TSDPポリシーとsalary_type機密タイプを関連付けます。

BEGIN
DBMS_TSDP_PROTECT.ASSOCIATE_POLICY(
policy_name        => 'tsdp_vpd',
sensitive_type     => 'salary_type',
associate          => TRUE);
END;
/

3. 保護を有効化して、SALARY_TYPEとして識別されるすべての列の仮想プライベート・データベース・ポリシーを規定します。

BEGIN
DBMS_TSDP_PROTECT.ENABLE_PROTECTION_TYPE(
sensitive_type           => 'salary_type');
END;
/

手順5: 透過的機密データ保護ポリシーのテスト

これで、透過的機密データ保護ポリシーをテストする準備ができました。

1. ユーザーhr_appuserとして接続します。

CONNECT hr_appuser -- Or, CONNECT hr_appuser@hrpdb
Enter password: password

2. 次のようにSCOTT.EMP表を問い合せます。

SELECT SAL, COMM, EMPNO FROM SCOTT.EMP;

次の出力が表示されます。

SAL   COMM   EMPNO
--------- ------ ----------
800          7369
1600    300   7499
1250    500   7521
2975          7566
1250   1400   7654
2850          7698
2450          7782
3000          7788
5000          7839
1500     0    7844
1100          7876
950          7900
3000          7902
1300          7934
14 rows selected.

vpd_function関数により、ユーザーhr_appuserはEMP表のSAL列の給与を確認できます。

3. ユーザーSCOTTとして接続し、同じ問合せを実行します。

CONNECT SCOTT -- Or, CONNECT SCOTT@hrpdb
Enter password: password

SELECT SAL, COMM, EMPNO FROM SCOTT.EMP;

次の出力が表示されます。

SAL   COMM   EMPNO
--------- ------ ----------
7369
300   7499
500   7521
7566
1400   7654
7698
7782
7788
7839
0    7844
7876
7900
7902
7934
14 rows selected.

SCOTTがEMP表を所有していても、vpd_function関数は、この表のSAL列の給与を表示しません。

手順6: このチュートリアルのコンポーネントの削除

このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。

1. ユーザーtsdp_adminとして接続します。

CONNECT tsdp_admin -- Or, CONNECT tsdp_admin@hrpdb
Enter password: password

2. 表示されている順序で次の文を実行します。

BEGIN
DBMS_TSDP_MANAGE.DROP_SENSITIVE_COLUMN (
schema_name        => 'SCOTT',
table_name         => 'EMP',
column_name        => 'SAL');
END;
/

BEGIN
DBMS_TSDP_MANAGE.DROP_SENSITIVE_TYPE(
sensitive_type     => 'salary_type');
END;
/

BEGIN
DBMS_TSDP_PROTECT.DROP_POLICY(
policy_name     => 'tsdp_vpd');
END;
/

3. ユーザーSYSTEMで接続します。

CONNECT SYSTEM -- Or, CONNECT SYSTEM@hrpdb
Enter password: password

4. tsdp_adminおよびhr_appuserアカウントを削除します。

DROP USER tsdp_admin CASCADE;
DROP USER hr_appuser

透過的機密データ保護のデータ・ディクショナリ・ビュー

Oracle Databaseには、透過的機密データ保護ポリシーに関する情報を表示するデータ・ディクショナリ・ビューが用意されています。

表11-2に、これらのビューを示します。これらのビューを使用する前に、SELECT_CATALOG_ROLEロールを付与する必要があります。

表11-2 透過的機密データ保護ビュー

ビュー

説明

DBA_DISCOVERY_SOURCE

透過的機密データの保護ポリシーに関するインポート情報の検出を説明します。

DBA_SENSITIVE_COLUMN_TYPES

現在のデータベースに定義されている機密列のタイプを説明します。

DBA_SENSITIVE_DATA

データベースの機密列を説明します。

DBA_TSDP_IMPORT_ERRORS

検出結果のインポート中に発生したエラーに関する情報を表示します。エラー・コード、スキーマ名、表名、列名および機密タイプに関する情報を表示します。

DBA_TSDP_POLICY_CONDITION

透過的機密データ保護ポリシーおよび条件マッピングを示します。このビューは、条件のプロパティと値のペアもリストします。

DBA_TSDP_POLICY_FEATURE

透過的機密データ保護ポリシーのセキュリティ機能マッピングを表示します。(現時点で、Oracle Data RedactionおよびOracle Virtual Private Databaseのみサポートされます。)

DBA_TSDP_POLICY_PARAMETER

透過的機密データ保護ポリシーのパラメータを示します

DBA_TSDP_POLICY_PROTECTION

透過的機密データ保護を通じて保護されている列のリストを表示します

DBA_TSDP_POLICY_TYPE

ポリシーと機密列タイプのマッピングを表示します

関連項目:
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください

12 手動によるデータ暗号化

DBMS_CRYPTO PL/SQLパッケージを使用して、データを手動で暗号化できます。

内容は次のとおりです。

- 暗号化で解決しないセキュリティの問題

- データ暗号化の課題

- DBMS_CRYPTOパッケージを使用したデータ暗号化ストレージ

- OFBモードで暗号化された暗号文のOracle Databaseリリース11gでの使用

- データの暗号化APIの使用例

- 暗号化データのデータ・ディクショナリ・ビュー

関連項目:

- ネットワーク暗号化の概要は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

- 透過的データ暗号化および表領域暗号化の使用方法は、『Oracle Database Advanced Securityガイド』を参照してください。

暗号化で解決しないセキュリティの問題

データの暗号化には多くのメリットがありますが、多くのデメリットもあります。暗号化はすべてのセキュリティ問題を解決するわけではなく、不都合な問題の原因となる場合もあります。格納データの暗号化に関する誤解のいくつかについて説明します。

内容は次のとおりです。

- 原則1: 暗号化はアクセス制御の問題を解決しない

- 原則2: 暗号化は不正な管理者からデータを保護しない

- 原則3: すべてのデータを暗号化してもデータは保護されない

原則1: 暗号化はアクセス制御の問題を解決しない

データを暗号化するとき、暗号化によってアクセス制御の構成が妨げられないように注意する必要があります。

ほとんどの組織で、データのアクセスを、そのデータを参照する必要があるユーザーのみに制限する必要があります。たとえば、人事管理システムでは、従業員には各自の雇用レコードのみを参照できるように制限し、従業員の上司には直属の部下の雇用レコードを参照できるようにする場合があります。人事部門の担当者が複数の従業員の従業員レコードを参照する必要がある場合もあります。

一般的には、アクセス制御メカニズムを使用して、データを見る必要がある人にデータ・アクセスを制限するセキュリティ・ポリシーに対処できます。Oracle Databaseは、強力で独自に評価されたアクセス制御メカニズムを何年もの間提供してきました。仮想プライベート・データベースにより、アクセス制御を詳細なレベルまで規定できます。

人事部門のレコードは機密情報とみなされるため、セキュリティをより強化するためにこの情報はすべて暗号化する必要があると考えがちです。しかし、暗号化によってきめ細かいアクセス制御を規定できなくなるため、データ・アクセスの妨げとなる場合があります。たとえば、従業員、その上司および人事部門の担当者すべてが、従業員レコードにアクセスする必要がある場合があります。従業員データがすべて暗号化されている場合、この3人は暗号化されていない形式のデータにアクセスできる必要があります。したがって、従業員、上司および人事部門の担当者はデータを復号化するために同じ暗号化鍵を共有する必要があります。このように、アクセス制御の向上という観点では、暗号化によってセキュリティが強化されず、アプリケーションの正しい機能や効率的な機能の妨げとなる場合があります。さらに、システムの複数のユーザー間で暗号化鍵の送信および共有を安全に行うことは難しいという別の問題もあります。

格納データを暗号化するときの基本原則は、暗号化によってアクセス制御が妨げられないようにすることです。たとえば、empに対するSELECT権限を持つユーザーが、基本的には参照できるすべてのデータへの参照を暗号化メカニズムによって制限されないようにする必要があります。また、ユーザーが表のすべての暗号化データを参照する必要がある場合は、ある鍵を使用して表の一部を暗号化し、別の鍵を使用して表の他の部分を暗号化するメリットはほとんどありません。この場合、ユーザーがデータを参照できるように、データを復号化するオーバーヘッドが増加するのみです。アクセス制御が適切に実装されている場合は、暗号化によってデータベース自体の中でセキュリティが強化されることはほとんどありません。データベース内のデータにアクセスする権限を持つユーザーについては、暗号化しても権限は変わりません。したがって、アクセス制御の問題解決に暗号化を使用しないでください。

原則2: 暗号化は不正な管理者からデータを保護しない

Oracle Database VaultなどのOracle機能を使用して、不正なデータベース管理者からデータベースを保護できます。

不正なユーザーがパスワードを推測して上位(データベース管理者)の権限を取得する可能性を懸念して、この脅威から保護するために格納データを暗号化することを考える組織もあります。

ただし、この問題の正しい解決策は、データベース管理者アカウントを保護し、その他の権限付きアカウントのデフォルトのパスワードを変更することです。データベースに侵入する最も簡単な方法は、管理者が変更しないままにしている権限付きアカウントのデフォルトのパスワードを使用することです。その一例が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によって実行されたすべてのアクションを監査できるため、監査人は、すべてのデータベース管理者が実行したアクションに対する責任をデータベース管理者自身に持たせることができます。

データベース管理者のアクセス権と制御権をOracle Database Vaultを使用して調整することもできます。詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

データベース管理者は信頼される立場にいます。諜報機関のような最も機密性の高いデータを扱う組織においても、通常、データベース管理者機能は分割されません。かわりに、データベース管理者には信頼性が必要なため、厳しく管理されます。定期的な監査によって不適切なアクティビティを明らかにできます。

格納データの暗号化が、データベースの管理を妨げないことが重要です。そうでない場合は、より大きいセキュリティ問題になる可能性があります。たとえば、データを暗号化することでそのデータが破損した場合セキュリティ問題となり、データ自体を解釈できず、修復不可能になる可能性があります。

暗号化を使用すると、データベース管理者(または権限を持つその他のユーザー)がデータベース内のデータを参照する機能を制限できます。ただし、これは、データベース管理者の権限を適切に管理すること、または強力なシステム権限の使用を制御することの代用にはなりません。信頼できないユーザーが重要な権限を持っている場合、そのユーザーが組織に多くの脅威をもたらすこととなり、暗号化されていないクレジット・カード番号を参照されるよりもはるかに深刻な状況に陥る場合もあります。

原則3: すべてのデータを暗号化してもデータは保護されない

通常、データの暗号化によってセキュリティが強化されるのであれば、すべてのデータを暗号化することにより、データはすべて保護されると考えますが、これは誤りです。

前述の2つの原則で説明したとおり、暗号化ではアクセス制御の問題に適切に対処できないため、暗号化によって通常のアクセス制御を妨げないことが重要になります。さらに、本番データベース全体を暗号化すると、読取り、更新または削除を行うために、すべてのデータを復号化する必要があります。暗号化は、本来、パフォーマンス集中型の操作であるため、すべてのデータを暗号化するとパフォーマンスに大きい影響を与えます。

可用性はセキュリティの重要な側面です。データの暗号化によって、データを使用できなくなったり、パフォーマンスが低下して可用性に悪影響を与えた場合は、すべてのデータを暗号化することで新たなセキュリティ問題が発生することになります。セキュリティの適切な手続きとして、暗号化鍵を定期的に変更する必要がありますが、このときデータベースにアクセスできなくなります。これも可用性に悪影響を与えます。鍵を変更する場合は、データを復号化して新しい鍵で再度暗号化するまでの間、データベースにアクセスできなくなります。

格納データをオフラインで暗号化することは、メリットもあります。たとえば、組織が半年から1年単位で遠隔地にオフラインでバックアップを格納する場合があります。もちろん、保護の第1段階は、物理的なアクセス制御を確立することによって、データを格納する施設を保護することです。さらに、このデータを格納する前に暗号化すると、メリットがあります。このデータはオンラインでアクセスされないため、パフォーマンスについて考慮する必要はありません。Oracleデータベースにはこの機能が備わっていませんが、暗号化サービスを提供するベンダーがあります。この方法を検討する組織は、バックアップ・データの大規模な暗号化を実施する前に、プロセスを徹底的にテストする必要があります。オフラインで格納する前に、暗号化されたデータを正常に復号化でき、正しく再インポートできることを確認する必要があります。

データ暗号化の課題

暗号化によってセキュリティが強化される場合、いくつかの技術的な課題が伴います。

内容は次のとおりです。

- 暗号化され索引付けされたデータ

- 生成された暗号化鍵

- 転送された暗号化鍵

- 暗号化鍵の格納

- 暗号化鍵の変更の重要性

- バイナリ・ラージ・オブジェクトの暗号化

暗号化され索引付けされたデータ

暗号化データが索引付けされている場合は、特別な問題が発生します。

たとえば、ある会社が国民識別番号(米国社会保障番号(SSN)など)を各従業員の従業員番号として使用しているとします。会社は従業員番号を機密性の高いデータと考えているため、employees表のemployee_number列のデータを暗号化します。employee_number列には一意の値が含まれているため、データベース設計者は、パフォーマンスを向上するためにそのデータを索引付けします。

ただし、DBMS_CRYPTO (または別のメカニズム)を使用して列のデータを暗号化した場合、その列の索引にも暗号化された値が含まれます。列の索引に暗号化された値が含まれている場合、この索引は等価性チェック(たとえば、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 Databaseのネットワーク暗号化およびデータ整合性の構成」を参照してください。

暗号化鍵の格納

データベースまたはオペレーティング・システムに暗号化鍵を格納できます。

内容は次のとおりです。

- 暗号化鍵の格納について

- データベースへの暗号化鍵の格納

- オペレーティング・システムへの暗号化鍵の格納

- ユーザー自身による暗号化鍵の管理

- 透過的データベース暗号化および表領域暗号化を使用した手動暗号化

暗号化鍵の格納について

暗号化鍵の格納は、暗号化で最も重要で難しい問題の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_CRYPTOパッケージ・コールをコールさせることができます。

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権限があり、鍵変換アルゴリズムを導出できるユーザーが、暗号化スキームを解読できることです。

前述の方法は完全ではありませんが、クリアテキストで格納されている機密情報を簡単に取得できないように保護するには十分です。

オペレーティング・システムへの暗号化鍵の格納

暗号化鍵をオペレーティング・システムのフラット・ファイルに格納する場合、PL/SQLからコールアウトを実行して暗号化鍵を取得できます。

ただし、オペレーティング・システムに鍵を格納し、それに対してコールアウトを行う場合、データはオペレーティング・システムでの保護と同じ程度にのみ保護されます。

セキュリティ上の主な懸念が、オペレーティング・システムからデータベースに侵入される可能性があるということである場合、オペレーティング・システムに鍵を格納することは、データベース自体に鍵を格納することより、侵入者にとっては暗号化されたデータを取得しやすくなります。

ユーザー自身による暗号化鍵の管理

ユーザーに鍵を提供させる場合は、ユーザー自身がその鍵に責任を持つことを想定しています。

ヘルプ・デスクへのコールの40%が、パスワードを忘れたユーザーからのコールであることから、ユーザーが暗号化鍵を管理することのリスクは明らかです。多くの場合、ユーザーは暗号化鍵を忘れるか、鍵を書き留めておくため、セキュリティ上の弱点が生じます。ユーザーが暗号化鍵を忘れたり、会社を退職した場合、データは復元できなくなります。

ユーザーに鍵を提供する、またはユーザーが鍵を管理する場合は、ネットワーク暗号化を使用して、鍵がクリアテキストでクライアントからサーバーに渡されないようにする必要があります。また、鍵アーカイブ・メカニズムを開発する必要があります。これも困難なセキュリティの問題です。鍵アーカイブおよびバックドアは、暗号化によって解決しようとしているセキュリティ上の弱点を生み出すことになります。

透過的データベース暗号化および表領域暗号化を使用した手動暗号化

透過的データベース暗号化および表領域暗号化は、暗号化された表および表領域に対する鍵を自動的に管理して、安全な暗号化を提供します。

アプリケーションで、メディアに格納されている機密性の高い列データの保護を必要とする場合は、これらの2種類の暗号化を使用することで、これを簡単にすばやく行えます。

関連項目:

透過的データ暗号化の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

暗号化鍵の変更の重要性

慎重なセキュリティの手続きでは、暗号化鍵を定期的に変更するように指示されます。

格納データの場合、これを実行するには、データを定期的に暗号解除し、適切な別の鍵を使用して再度暗号化する必要があります。

暗号化鍵の変更は、おそらくデータへのアクセスがない間に実行しますが、また別の課題が生まれます。クレジット・カード番号を暗号化するWebベースのアプリケーションでは、暗号化鍵を切り替える間はアプリケーション全体を停止できないため、特に問題になります。

バイナリ・ラージ・オブジェクトの暗号化

一部のデータ型は、暗号化に手間がかかります。

たとえば、Oracle Databaseでは、非常に大規模なオブジェクト(たとえば、数GB)をデータベースに格納するバイナリ・ラージ・オブジェクト(BLOB)をサポートしています。BLOBは、列として内部的に格納するか、または外部ファイルに格納できます。

BLOBデータに対するDBMS_CRYPTOの使用例は、BLOBデータの暗号化および復号化プロシージャの例を参照してください。

DBMS_CRYPTOパッケージを使用したデータ暗号化ストレージ

DBMS_CRYPTOパッケージは、セキュリティ問題に取り組むための様々な方法を提供します。

暗号化は、複数のセキュリティへの脅威に対処できる理想的なソリューションではありませんが、データベースに格納する前に機密性の高いデータを選択的に暗号化することによって、セキュリティを強化できます。そのようなデータの例は次のとおりです。

- クレジット・カード番号

- 国民識別番号

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をサポートしています。さらに、様々なデータベース・キャラクタ・セット間でデータを暗号化するためのグローバリゼーション・サポートも提供します。

次の暗号化アルゴリズムがサポートされています。

- Advanced Encryption Standard(AES)

- SHA-2暗号化ハッシュ設定:

- HASH_SH256

- HASH_SH384

- HASH_SH512

- SHA-2メッセージ認証コード(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より安全性が高くなります。

- SHA-2を使用する方がSHA-1より安全性が高くなります。

- 鍵付きMD5は、無防備ではありません。

表12-1に、DBMS_CRYPTOパッケージ機能の概要を示します。

表12-1 DBMS_CRYPTOパッケージ機能の概要

機能

DBMS_CRYPTOでサポートされている機能

暗号化アルゴリズム

AES

パディング形式

PKCS5、複数ゼロ

ブロック暗号連鎖モード

CBC、CFB、ECB、OFB

暗号化ハッシュ・アルゴリズム

SHA-1、SHA-2、MD4、MD5、HASH_SH256、HASH_SH384、HASH_SH512

鍵ハッシュ(MAC)・アルゴリズム

HMAC_MD5、HMAC_SH1、HMAC_SH256、HMAC_SH384、HMAC_SH512

暗号化擬似乱数ジェネレータ

RAW、NUMBER、BINARY_INTEGER

データベース型

RAW、CLOB、BLOB

DBMS_CRYPTOは、新しいシステムと既存のシステムの両方に対応する広範囲のアルゴリズムをサポートしています。3DES_2KEYおよびMD4は下位互換性を維持するために提供されていますが、3DES、AESまたはSHA-1を使用するとセキュリティをより強化できます。3DES_2KEYおよびMD4の使用はお薦めしません。

DBMS_CRYPTOパッケージには、比較の際に便利な暗号チェックサム機能(MD5)と、安全な乱数を生成する機能(RANDOMBYTES関数)が含まれています。安全な乱数生成は暗号化の重要な部分です。予測可能な鍵は簡単に推定される鍵であり、鍵を簡単に推定できることによってデータが簡単に復号化される可能性があります。ほとんどの暗号解読が、総当たり解析(可能性のあるすべての鍵を繰り返す)によってではなく、脆弱な鍵や適切に格納されていない鍵を見つけ出すことによって行われています。

注意:

DBMS_RANDOMは暗号化鍵の生成には不適切なため、使用しないでください。

鍵の管理はプログラムによって実行されます。つまり、アプリケーション(またはファンクションのコール側)が、暗号化鍵を提供する必要があります。これは、アプリケーション開発者が鍵を安全に格納し、取得する方法を検討する必要があることを意味します。様々な鍵管理方法の相対的なメリットとデメリットについては、後続の項で説明します。DESアルゴリズム自体の有効な鍵の長さは56ビットです。

関連項目:

- DBMS_CRYPTOパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- UTL_RAWパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

OFBモードで暗号化された暗号文のOracle Databaseリリース11gでの使用

Oracle Databaseリリース11gでは、出力フィードバック(OFB)を使用するように暗号文が構成されても、かわりに電子コードブック(ECB)モードが使用されました。

Oracle Databaseリリース11gで、DBMS_CRYPTO.CHAIN_OFB暗号ブロック連鎖修飾子を設定して、出力フィードバック(OFB)モードを使用するように暗号文の暗号化を構成すると、Oracle Bug 13001552のため、その構成で電子コードブック(ECB)モードが誤って使用されました。この不具合はOracle Databaseリリース12cで修正されています。したがって、Oracle Databaseリリース11gからリリース12cにアップグレードした後、リリース11gでOFBノードを使用して暗号化された暗号文は、Oracle Databaseリリース12cでは修正されたOFBモードで正しく復号化されません。
この問題を解決するには:

1. DBMS_CRYPTO PL/SQLパッケージに対するEXECUTE権限があるユーザーとして、データベースにログインします。

2. DBMS_CRYPTO.CHAIN_ECBブロック暗号連鎖修飾子を使用して、暗号文を復号化します。

次の例のdbmscrypto11.sqlは、Oracle Databaseリリース11gでの誤った動作を示します。

dbmscrypto11.sql:
set serveroutput on

declare
l_mod_ofb pls_integer;
l_mod_ecb pls_integer;
v_key raw(32);
v_iv  raw(16);
v_test_in raw(16);
v_ciphertext raw(16);
v_test_out_ECB raw(16);
v_test_out_OFB raw(16);
begin
l_mod_ofb := dbms_crypto.ENCRYPT_AES256
+ dbms_crypto.CHAIN_OFB
+ DBMS_CRYPTO.PAD_NONE ;
l_mod_ecb := dbms_crypto.ENCRYPT_AES256
+ dbms_crypto.CHAIN_ECB
+ DBMS_CRYPTO.PAD_NONE ;

v_key := hextoraw
('603deb1015ca71be2b73aef0857d77811f352c073b6108d72d9810a30914dff4');
v_iv :=   hextoraw('000102030405060708090A0B0C0D0E0F');
v_test_in := hextoraw('6bc1bee22e409f96e93d7e117393172a');
v_ciphertext := dbms_crypto.encrypt(src => v_test_in,
TYP => l_mod_ofb,
key => v_key,
iv => v_iv);
v_test_out_ECB := dbms_crypto.decrypt(src => v_ciphertext,
TYP => l_mod_ecb,
key => v_key,
iv => v_iv);
v_test_out_OFB := dbms_crypto.decrypt(src => v_ciphertext,
TYP => l_mod_ofb,
key => v_key,
iv => v_iv);
dbms_output.put_line
('Input plaintext                      : '||rawtohex(v_test_in));
dbms_output.put_line
('11g: Ciphertext (encrypt in OFB mode): '||rawtohex(v_ciphertext));
dbms_output.put_line
('11g: Output of decrypt in ECB mode   : '||rawtohex(v_test_out_ECB));
dbms_output.put_line
('11g: Output of decrypt in OFB mode   : '||rawtohex(v_test_out_OFB));
end;
/

生成される出力は次のようになります。

SQL> @dbmscrypto11.sql

Input plaintext                      : 6BC1BEE22E409F96E93D7E117393172A
11g: Ciphertext (encrypt in OFB mode): F3EED1BDB5D2A03C064B5A7E3DB181F8
11g: Output of decrypt in ECB mode   : 6BC1BEE22E409F96E93D7E117393172A
11g: Output of decrypt in OFB mode   : 6BC1BEE22E409F96E93D7E117393172A

この出力は、Oracle Databaseリリース11gではOFBモードが誤ってECBモードになるため、OFBまたはECBモードのどちらで復号化しても正しいプレーンテキストになることを示しています。

次の例のdbmscrypto12from11.sqlは、Oracle Databaseリリース11gからリリース12cにアップグレードした後、リリース11gのOFBモードで暗号化した暗号文を適切に復号化するには、OFBモードではなく、ECBモードを使用する必要があることを示します。

dbmscrypto12from11.sql:
set serveroutput on

declare
l_mod_ofb pls_integer;
l_mod_ecb pls_integer;
v_key raw(32);
v_iv  raw(16);
v_test_in raw(16);
v_ciphertext11 raw(16);
v_test_out_ECB raw(16);
v_test_out_OFB raw(16);
begin
l_mod_ofb := dbms_crypto.ENCRYPT_AES256
+ dbms_crypto.CHAIN_OFB
+ DBMS_CRYPTO.PAD_NONE ;
l_mod_ecb := dbms_crypto.ENCRYPT_AES256
+ dbms_crypto.CHAIN_ECB
+ DBMS_CRYPTO.PAD_NONE ;

v_key := hextoraw
('603deb1015ca71be2b73aef0857d77811f352c073b6108d72d9810a30914dff4');
v_iv :=   hextoraw('000102030405060708090A0B0C0D0E0F');
v_test_in := hextoraw('6bc1bee22e409f96e93d7e117393172a');
v_ciphertext11 := hextoraw('F3EED1BDB5D2A03C064B5A7E3DB181F8');

v_test_out_ECB := dbms_crypto.decrypt(src => v_ciphertext11,
TYP => l_mod_ecb,
key => v_key,
iv => v_iv);
v_test_out_OFB := dbms_crypto.decrypt(src => v_ciphertext11,
TYP => l_mod_ofb,
key => v_key,
iv => v_iv);
dbms_output.put_line
('Input plaintext (to 11g)             : '||rawtohex(v_test_in));
dbms_output.put_line
('11g: Ciphertext (encrypt in OFB mode): '||rawtohex(v_ciphertext11));
dbms_output.put_line
('12c: Output of decrypt in ECB mode   : '||rawtohex(v_test_out_ECB));
dbms_output.put_line
('12c: Output of decrypt in OFB mode   : '||rawtohex(v_test_out_OFB));
end;
/

生成される出力は次のようになります。

SQL> @dbmscrypto12from11.sql
Input plaintext (to 11g)             : 6BC1BEE22E409F96E93D7E117393172A
11g: Ciphertext (encrypt in OFB mode): F3EED1BDB5D2A03C064B5A7E3DB181F8
12c: Output of decrypt in ECB mode   : 6BC1BEE22E409F96E93D7E117393172A
12c: Output of decrypt in OFB mode   : 4451EBE041EB29E191BBA0E9D67FAEB2

Oracle Databaseリリース11gからリリース12cへのアップグレードを予定している場合は、復号化操作でECBモードを使用するように、OFBモードが指定されたすべてのスクリプトを編集してください。この方法によって、スクリプトはリリース11gとリリース12cの両方で使用できるため、ビジネスの継続性を確保できます。

データの暗号化APIの使用例

データ暗号化APIの使用例として、DBMS_CRYPTO.SQLプロシージャの使用、AES 256ビット・データの暗号化およびBLOBデータの暗号化などがあります。

内容は次のとおりです。

- データ暗号化プロシージャの例

- AES 256ビット・データ暗号化および復号化プロシージャの例

- BLOBデータの暗号化および復号化プロシージャの例

データ暗号化プロシージャの例

DBMS_CRYPTO.SQL PL/SQLプログラムを使用してデータを暗号化できます。

このサンプル・コードでは、次の処理を実行します。

- 文字列(VARCHAR2型)をRAWデータ型に変換した後、DESを使用して暗号化します。
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ブロックを使用して、事前定義された変数を暗号化または復号できます。

次の例では、事前定義の変数input_stringが、Cipher Block ChainingとPKCS #5パディングを使用するAES 256ビット・アルゴリズムを使用しています。

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データを暗号化できます。

次に、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;

暗号化データのデータ・ディクショナリ・ビュー

Oracle Databaseには、暗号化されたデータに関する情報を検索できるデータ・ディクショナリ・ビューが用意されています。

表12-2に、これらのデータ・ディクショナリ・ビューを示します。

表12-2 暗号化データに関する情報を表示するデータ・ディクショナリ・ビュー

ビュー

説明

ALL_ENCRYPTED_COLUMNS

ユーザーがアクセスできるすべての表にあるすべての暗号化列の暗号化アルゴリズム情報が表示されます。

DBA_ENCRYPTED_COLUMNS

データベースにあるすべての暗号化列の暗号化アルゴリズム情報が表示されます。

USER_ENCRYPTED_COLUMNS

ユーザー・スキーマのすべての表にあるすべての暗号化列の暗号化アルゴリズム情報が表示されます。

V$ENCRYPTED_TABLESPACES

暗号化されている現在のプラガブル・データベース(PDB)表領域に関する情報が表示されます。

V$ENCRYPTION_WALLET

透過的データ暗号化のウォレットのステータスおよびウォレットの場所に関する情報が表示され、現在のPDBのみに適用されます。

V$RMAN_ENCRYPTION_ALGORITHMS

現在のPDBでサポートされている暗号化アルゴリズムが表示されます。

関連項目:
これらのビューの詳細は、Oracle Databaseリファレンスを参照してください。

第IV部 ネットワーク上のデータの保護

第IV部では、ネットワーク上のデータの保護方法について説明します。

- Oracle Databaseのネットワーク暗号化とデータ整合性の構成

- シンJDBCクライアント・ネットワークの構成

13 Oracle Databaseのネットワーク暗号化とデータ整合性の構成

サーバーとクライアントの両方について、Oracle Net Services固有のデータの暗号化および整合性を構成できます。

内容は次のとおりです。

- Oracle Databaseのネットワーク暗号化とデータ整合性について

- Oracle Databaseのネットワーク暗号化のデータ整合性

- Diffie-Hellmanベースの鍵交換

- データの暗号化および整合性の構成

Oracle Databaseのネットワーク暗号化とデータ整合性について

Oracle Databaseでは、ネットワークで送信されるデータを暗号化できます。

内容は次のとおりです。

- Oracleデータ・ネットワークの暗号化および整合性について

- Advanced Encryption Standard

Oracleデータ・ネットワークの暗号化および整合性について

Oracle Databaseは、ネットワーク間を移動するデータが保護されるように、データ・ネットワークの暗号化および整合性を提供します。

セキュアな暗号システムの目的は、鍵に基づいて、平文データを解読不能な暗号文に変換することです。正しい鍵がなければ、暗号文を元の平文に変換することはきわめて困難(計算上は不可能)です。

対称暗号システムでは、同じデータの暗号化と復号化の両方に同じ鍵を使用します。Oracle Databaseは、Advanced Encryption Standard (AES)の対称暗号システムを提供して、Oracle Net Servicesトラフィックの機密保護を図ります。

Advanced Encryption Standard

Oracle Databaseでは、米国連邦情報処理標準(FIPS)暗号化アルゴリズムであるAdvanced Encryption Standard (AES)がサポートされています。

AESは、ネットワーク上で機密データを保護するために、あらゆる米国政府組織および企業で使用できます。この暗号化アルゴリズムでは、128ビット、192ビットおよび256ビットの3つの標準の鍵の長さが定義されています。いずれのバージョンも、外部暗号ブロック連鎖(CBC)モードで稼働します。

Oracle Databaseのネットワーク暗号化のデータ整合性

ネットワーク・データを暗号化すると、ネットワーク上で転送される平文データを不正なユーザーが閲覧できなくなり、データのプライバシが保護されます。

また、Oracle Databaseでは、2つの形態の攻撃からデータを保護できます。

表13-1に、これらの攻撃の情報を示します。

表13-1 2つの形態のネットワーク攻撃

攻撃形態

説明

データ変更攻撃

データ変更攻撃とは、不正なユーザーが転送中のデータを傍受し、データを変更して再転送することです。たとえば、銀行への$100の預入れを傍受して、金額を$10,000に変更し、その水増し金額を再転送することをデータ変更攻撃といいます。

再生攻撃

再生攻撃とは、有効なデータ全体を反復的に再送することです。たとえば、銀行からの$100の払戻しを傍受し、その払戻しを10回再転送して、最終的に$1,000受け取るといった攻撃です。

データの整合性アルゴリズムのサポート

鍵で順序付けられたMessage Digest 5 (MD5)アルゴリズムまたはSecure Hash Algorithm (SHA-1およびSHA-2)を使用して、これらの攻撃からデータを保護できます。

いずれのハッシュ・アルゴリズムでも、データがなんらかの方法で変更された場合に変わるチェックサムを作成します。この保護機能は暗号化プロセスとは独立して動作するため、暗号化の有無に関係なくデータ整合性を保つことができます。

関連項目:

- クライアントとサーバーでの整合性の構成

- 表13-4

Diffie-Hellmanベースの鍵交換

Diffie-Hellman鍵交換アルゴリズムを使用して、マルチユーザー環境でデータを保護できます。

マルチユーザー環境では、安全な鍵を配布することは困難です。Oracle Databaseでは、一般的な方法を使用して、暗号化およびデータ整合性の両面において安全な鍵の配布を実現します。

暗号化を使用して暗号データを保護するときは、鍵を頻繁に変更して、鍵の安全性が損われた場合の影響を最小限に抑える必要があります。そのため、Oracle Databaseの鍵管理機能では、セッションごとにセッション鍵が変更されます。

認証鍵フォールドインを使用して、Diffie-Hellman鍵交換アルゴリズムによる鍵交換に対する第三者の攻撃(従来の呼称は介在者攻撃)を阻止できます。この暗号化では、クライアントとサーバーのみが認識している共有秘密鍵とDiffie-Hellmanによって交換される最初のセッション鍵を組み合せることによって、セッション鍵の安全性を大幅に強化しています。

クライアントとサーバーは、Diffie-Hellmanによって生成されるセッション鍵を使用して通信を開始します。サーバーに対するクライアントの認証時に、両者のみが認識する共有秘密鍵が確立されます。Oracle Databaseでは、その共有秘密鍵とDiffie-Hellmanセッション鍵を組み合せることで、介在者攻撃を阻止するためのさらに強力なセッション鍵を生成します。

注意:

認証鍵フォールドイン機能は、Oracle Databaseに組み込まれているため、システム管理者またはネットワーク管理者による構成作業は必要ありません。

データの暗号化および整合性の構成

Oracle Database固有のOracle Net Servicesによる暗号化および整合性を構成できます。この場合、Oracle Net Servicesがインストール済であることを前提としています。

内容は次のとおりです。

- 暗号化および整合性のアクティブ化について

- 暗号化および整合性のネゴシエーションについて

- Oracle Net Managerを使用した暗号化および整合性パラメータの構成

関連項目:

SSL機能を構成して暗号化、整合性および認証のために使用するには、Secure Sockets Layer認証の構成を参照してください

暗号化および整合性のアクティブ化について

どのネットワーク接続でも、クライアントとサーバーの両方が複数の暗号化アルゴリズムと複数の整合性アルゴリズムをサポートできます。

接続が確立されるときに、sqlnet.oraファイルで指定されているアルゴリズムの中から、使用するアルゴリズムをサーバーが選択します。サーバーは、クライアントとサーバーの両方で使用できるアルゴリズム間で一致するものを検索し、サーバー側のリストで最初にあって、クライアント側のリストにも出現するアルゴリズムを選択します。接続の一方の側がアルゴリズム・リストを指定していない場合、その側でインストールされているすべてのアルゴリズムを使用できます。いずれかの側でインストールされていないアルゴリズムを指定すると、エラー・メッセージORA-12650が表示され、接続が失敗します。

暗号化パラメータと整合性パラメータを定義するには、ネットワーク上のクライアントとサーバーのsqlnet.oraファイルを変更します。

利用可能な暗号化アルゴリズムの一部またはすべて、および利用可能な整合性アルゴリズムの一方または両方を構成できます。各接続セッションに使用できるのは、1つの暗号化アルゴリズムと1つの整合性アルゴリズムのみです。

注意:

Oracle Databaseでは、クライアントとサーバーで利用可能なアルゴリズムのうち、最初の暗号化アルゴリズムと最初の整合性アルゴリズムが自動的に選択されます。ネゴシエーションの優先順にアルゴリズムと鍵の長さを選択することをお薦めします(つまり、最も強力な鍵の長さを最初に選択します)。

関連項目:

- 有効な暗号化アルゴリズムをリストする表13-3

- 使用できる整合性アルゴリズムのリストは、Oracle Database Advanced Securityガイドを参照してください

- データ暗号化および整合性パラメータ

暗号化および整合性のネゴシエーションについて

データの暗号化と整合性を使用するクライアント・システムおよびサーバー・システムのプロファイル(sqlnet.oraファイル)には、REJECTED、ACCEPTED、REQUESTEDおよびREQUIREDパラメータの一部またはすべてが含まれている必要があります。

内容は次のとおりです。

- 暗号化および整合性のネゴシエーションの値について

- REJECTED構成パラメータ

- ACCEPTED構成パラメータ

- REQUESTED構成パラメータ

- REQUIRED構成パラメータ

暗号化および整合性のネゴシエーションの値について

Oracle Net Managerを使用して、暗号化と整合性の構成パラメータに4つの値を指定できます。

次の4つの値はセキュリティの低い順で記載されています。暗号化および整合性を使用しているシステムのクライアントとサーバーのプロファイル・ファイル(sqlnet.ora)でこれらを使用する必要があります。

値REJECTEDは、クライアントとサーバーの間の通信に最小レベルのセキュリティを提供し、値REQUIREDは、最高レベルのネットワーク・セキュリティを提供します。

- REJECTED

- ACCEPTED

- REQUESTED

- REQUIRED

各パラメータのデフォルト値はACCEPTEDです。

Oracle Databaseサーバーおよびクライアントは、デフォルトではACCEPT暗号化接続に設定されます。これは、接続の片側のみ(サーバー側またはクライアント側)を構成するだけで、接続ペアに対して目的の暗号化および整合性設定を有効化できることを意味します。

したがって、たとえば、数多くのOracleクライアントがOracleデータベースに接続する場合も、サーバー側でsqlnet.oraに適切な変更を加えることによって、すべての接続に対して必要な暗号化および整合性設定を構成できます。クライアントごとに個別に構成の変更を実装する必要はありません。

表13-2に、クライアントとサーバーの構成パラメータを各種組み合せたときに、セキュリティ・サービスが有効化されるかどうかを示します。サーバーまたはクライアントでREQUIREDが指定されている場合は、共通のアルゴリズムが存在しないと、接続が失敗します 。それ以外の場合は、サービスが有効化されていて、共通のサービス・アルゴリズムが存在しないと、サービスが無効化されます。

表13-2 暗号化とデータ整合性のネゴシエーション

クライアントの設定

サーバーの設定

暗号化とデータのネゴシエーション

REJECTED

REJECTED

OFF

ACCEPTED

REJECTED

OFF

REQUESTED

REJECTED

OFF

REQUIRED

REJECTED

接続失敗

REJECTED

ACCEPTED

OFF

ACCEPTED

ACCEPTED

OFF脚注1

REQUESTED

ACCEPTED

ON

REQUIRED

ACCEPTED

ON

REJECTED

REQUESTED

OFF

ACCEPTED

REQUESTED

ON

REQUESTED

REQUESTED

ON

REQUIRED

REQUESTED

ON

REJECTED

REQUIRED

接続失敗

ACCEPTED

REQUIRED

ON

REQUESTED

REQUIRED

ON

REQUIRED

REQUIRED

ON

脚注1

この値のデフォルトはOFFです。ユーザーがOracle Net Managerを使用するか、sqlnet.oraファイルを変更することによってこのパラメータを変更しないかぎり、暗号化とデータ整合性は有効化されません。

REJECTED構成パラメータ

REJECTED値は、他方が要求している場合でも、セキュリティ・サービスを無効にします。

このシナリオでは、セキュリティ・サービスの使用が許可されないことを接続元で指定します。接続先がREQUIREDに設定されている場合、エラー・メッセージORA-12650が表示されて接続が終了します。接続先がREQUESTED、ACCEPTEDまたはREJECTEDに設定されている場合、エラーは発生せずに、セキュリティ・サービスが無効のまま接続が継続されます。

ACCEPTED構成パラメータ

ACCEPTED値は、他方が必要としている場合または要求している場合に、セキュリティ・サービスを有効にします。

このシナリオでは、接続元からはセキュリティ・サービスを要求しませんが、接続先がREQUIREDまたはREQUESTEDに設定されている場合は、セキュリティ・サービスが有効化されます。接続先がREQUIREDまたはREQUESTEDに設定されていて、該当する暗号化アルゴリズムまたは整合性アルゴリズムが見つかると、エラーは発生せずに、セキュリティ・サービスが有効のまま接続が継続されます。接続先がREQUIREDに設定されていて、該当するアルゴリズムが見つからない場合、エラー・メッセージORA-12650が表示されて接続が終了します。

接続先がREQUESTEDに設定されていて、該当するアルゴリズムが見つからない場合、または接続先がACCEPTEDまたはREJECTEDに設定されている場合、エラーは発生せずに、セキュリティ・サービスが無効のまま接続が継続されます。

REQUESTED構成パラメータ

REQUESTED値は、他方が許可している場合にセキュリティ・サービスを有効にします。

このシナリオでは、接続元がセキュリティ・サービスの使用を希望します(必須ではない)。接続先でACCEPTED、REQUESTEDまたはREQUIREDが指定されている場合、セキュリティ・サービスが有効化されます。接続先に該当するアルゴリズムがある必要があります。見つからない場合、セキュリティ・サービスは有効化されません。接続先でREQUIREDが指定されていて、該当するアルゴリズムが見つからない場合、接続は失敗します 。

REQUIRED構成パラメータ

REQUIRED値は、セキュリティ・サービスを有効にする、または接続を禁止します。

このシナリオでは、接続元がセキュリティ・サービスの有効化を強制します。接続先でREJECTEDが指定されている場合、または接続先に互換性のあるアルゴリズムが見つからない場合、接続は失敗します。

Oracle Net Managerを使用した暗号化および整合性パラメータの構成

Oracle Net Managerを使用して、暗号化および整合性パラメータを設定または変更できます。

内容は次のとおりです。

- クライアントとサーバーでの暗号化の構成

- クライアントとサーバーでの整合性の構成

関連項目:
有効な暗号化アルゴリズムの詳細は、データ暗号化および整合性パラメータを参照してください

クライアントとサーバーでの暗号化の構成

クライアントとサーバーで暗号化を構成するには、Oracle Net Managerを使用します。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。

ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「暗号化」タブを選択します。

5. 「暗号化」ボックスからCLIENTまたはSERVERオプションを選択します。

6. 「暗号化タイプ」リストから、次のいずれかを選択します。

- リクエスト済

- 必須

- ACCEPTED

- REJECTED

7. (オプション)「暗号化シード」フィールドに、10から70字のランダムな文字を入力します。クライアントの暗号化シードは、サーバーの暗号化シードとは別のものにします。

8. 「使用可能なメソッド」リストで暗号化アルゴリズムを選択します。右矢印(>)を選択して「選択メソッド」リストに移動します。追加の方式を使用する場合は、それぞれ同じ手順を繰り返します。

9. 「ファイル」→「ネットワーク構成の保存」を選択します。sqlnet.oraファイルが更新されます。

10. 同じ手順を繰り返して、もう一方のシステムで暗号化を構成します。2つのシステムのsqlnet.oraファイルに、次のエントリが含まれている必要があります。

- サーバー:

SQLNET.ENCRYPTION_SERVER = [accepted | rejected | requested | required]
SQLNET.ENCRYPTION_TYPES_SERVER = (valid_encryption_algorithm [,valid_encryption_algorithm])

- クライアント:

SQLNET.ENCRYPTION_CLIENT = [accepted | rejected | requested | required]
SQLNET.ENCRYPTION_TYPES_CLIENT = (valid_encryption_algorithm [,valid_encryption_algorithm])

表13-3に、有効な暗号化アルゴリズムと対応する有効な値を示します。

表13-3 有効な暗号化アルゴリズム

アルゴリズム名

有効な値

AES 256ビット鍵

AES256

AES 192ビット鍵

AES192

AES 128ビット鍵

AES128

クライアントとサーバーでの整合性の構成

Oracle Net Managerを使用して、クライアントとサーバーの両方でネットワーク整合性を構成できます。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。

ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「整合性」タブを選択します。

5. いずれのシステムを構成しているかに応じて、「整合性」ボックスから「サーバー」または「クライアント」を選択します。

6. 「チェックサム・レベル」リストから、次のチェックサム・レベル値のいずれかを選択します。

- リクエスト済

- 必須

- ACCEPTED

- REJECTED

7. 「使用可能なメソッド」リストで整合性アルゴリズムを選択します。右矢印(>)を選択して「選択メソッド」リストに移動します。追加の方式を使用する場合は、それぞれ同じ手順を繰り返します。

8. 「ファイル」→「ネットワーク構成の保存」を選択します。

sqlnet.oraファイルが更新されます。

9. 同じ手順を繰り返して、もう一方のシステムで整合性を構成します。

2つのシステムのsqlnet.oraファイルに、次のエントリが含まれている必要があります。

- サーバー:

SQLNET.CRYPTO_CHECKSUM_SERVER = [accepted | rejected | requested | required]
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (valid_crypto_checksum_algorithm [,valid_crypto_checksum_algorithm])

- クライアント:

SQLNET.CRYPTO_CHECKSUM_CLIENT = [accepted | rejected | requested | required]
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (valid_crypto_checksum_algorithm [,valid_crypto_checksum_algorithm])

表13-4に、有効な整合性アルゴリズムと対応する有効な値を示します。

表13-4 有効な整合性アルゴリズム

アルゴリズム名

有効な値

MD5

MD5

SHA-1

SHA1

SHA-2

SHA256

SHA-2

SHA384

SHA-2

SHA512

14 シンJDBCクライアント・ネットワークの構成

Oracle Databaseのネットワーク暗号化および厳密認証を使用すると、シンJava Database Connectivity (JDBC)クライアントは、Oracleデータベースに安全に接続できます。

内容は次のとおりです。

- Java実装について

- Java Database Connectivityのサポート

- シンJDBCの機能

- 実装の概要

- Java暗号化コードの不明瞭化

- シンJDBCネットワーク実装の構成パラメータ

関連項目:
JDBCの詳細および例は、『Oracle Database JDBC開発者ガイド』を参照してください。

Java実装について

Oracle Databaseには、ネットワーク暗号化と厳密認証のJava実装が用意されています。

Oracle Databaseのネットワーク暗号化および厳密認証のJava実装では、Oracle Databaseのネットワーク暗号化および厳密認証が構成されているOracle Databaseと通信するシンJDBCクライアントに対して、ネットワーク認証、暗号化および整合性の保護が提供されます。

Java Database Connectivityのサポート

業界標準のJavaインタフェースであるJDBCは、Javaプログラムからリレーショナル・データベースに接続するためのJava標準です。

JDBC標準はSun Microsystemsによって規定され、オラクル社では独自のJDBCドライバによってこの標準を実装および拡張しています。

Oracle JDBCドライバは、Oracleデータベースと通信するJava Database Connectivity (JDBC)アプリケーションを作成するために使用されます。Oracleでは、CベースのOracle Netクライアントの最上部に構築されたシックJDBCドライバ、およびダウンロード可能なアプレットをサポートするシン(Pure Java)JDBCドライバの2つのタイプのJDBCドライバが実装されます。JDBCに対するOracleの拡張機能には、次の機能が含まれます。

- データ・アクセスおよび操作

- LOBアクセスおよび操作

- Oracleオブジェクト型マッピング

- オブジェクト参照アクセスおよび操作

- 配列アクセスおよび操作

- アプリケーション・パフォーマンスの向上

シンJDBCの機能

シンJDBCドライバは、厳密認証、データ暗号化、データ整合性チェックなど、セキュリティ機能を備えています。

シンJDBCドライバは、インターネットで使用されるダウンロード可能なアプレットとともに使用するように設計されているため、オラクル社では、シン・クライアントとともに使用するOracle Databaseのネットワーク暗号化および厳密認証、暗号化および整合性のアルゴリズムがJavaで100%実装されるように設計しました。

Oracle Databaseには、シンJDBCのための次の機能が備えられています。

- 厳密認証

- データ暗号化

- データ整合性チェック

- シンJDBCクライアントからOracle RDBMSへの接続の保護

- 開発者が安全な通信チャネルでデータを転送するアプレットを作成するための機能

- Java Server Pages (JSP)を持つ中間層サーバーからOracle RDBMSへの接続の保護

- Oracle Database 12c リリース1 (12.1)から旧バージョンのOracleデータベースへの接続の保護

Oracle JDBCシン・ドライバは、Oracle DatabaseのSSL実装およびRADIUSやKerberosなどのサード・パーティの認証方式をサポートしています。シンJDBCによるRADIUS、Kerberos、SSLなどの認証方式のサポートは、Oracle Database 11g リリース1 (11.1)で導入されました。

Oracle Databaseのネットワーク暗号化および厳密認証のJava実装では、次の暗号化アルゴリズムのJavaバージョンが提供されます。

- AES256: AES 256ビット鍵

- AES192: AES 192ビット鍵

- AES128: AES 128ビット鍵

注意:

前述のアルゴリズムのリストで、CBCは暗号ブロック連鎖モードのことです。

シンJDBCによるAdvanced Encryption Standard (AES)のサポートは、Oracle Database 12cリリース1 (12.1)で新たに導入されました。

また、この実装により、Secure Hash Algorithm (SHA1)およびMessage Digest 5 (MD5)を使用したシンJDBCのデータ整合性チェックが実行されます。シンJDBCによるSHA1のサポートは、Oracle Database 11g リリース1 (11.1)で導入されました。

関連項目:

シンJDBCクライアントに対する認証、暗号化および整合性の構成の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

実装の概要

サーバー側で、アルゴリズムのネゴシエーションおよび鍵の生成は、Oracle Database固有の暗号化とまったく同様に機能します。

この機能により、クライアントとサーバーの下位および上位互換性が維持されます。

クライアント側では、アルゴリズムのネゴシエーションおよび鍵の生成は、OCIクライアントとまったく同じ方法で行われます。クライアントとサーバーは、従来のOracle Netクライアントと同様の方法で、暗号化アルゴリズムのネゴシエーション、乱数の生成、Diffie-Hellmanを使用したセッション鍵の交換を行い、Oracle Password Protocolを使用します。シンJDBCには、Oracle Netクライアントがpure Javaで完全に実装されています。

Java暗号化コードの不明瞭化

Java暗号化コードの不明瞭化では、不明瞭化ソフトウェアを使用して、暗号化機能と複号化機能を含むJavaクラスおよびメソッドを保護します。

Javaバイト・コードの不明瞭化は、Javaプログラムの形式で作成された知的財産を保護するためによく使用されるプロセスです。これによって、コード内のJavaシンボルが変更されます。プロセスは、元のプログラム構造をそのまま保持し、意図した動作を隠すためにクラス、メソッドおよび変数の名前を変更する一方でプログラムを正常に実行します。不明瞭化されていないJavaコードは再コンパイルして読むことができますが、不明瞭化されたJavaコードは再コンパイルが難しく、米国政府の輸出規制を満たすことができます。

シンJDBCネットワーク実装の構成パラメータ

クライアントにシンJDBCネットワーク実装を設定するには、一連の構成パラメータを使用します。これらのパラメータを使用すると、暗号化レベル、暗号化選択リスト、整合性レベル、整合性選択リストおよび認証サービス・パラメータを設定できます。

内容は次のとおりです。

- シンJDBCネットワーク実装の構成パラメータについて

- クライアント暗号化レベルのパラメータ

- クライアント暗号化選択リストのパラメータ

- クライアント整合性レベルのパラメータ

- クライアント整合性選択リストのパラメータ

- クライアント認証サービスのパラメータ

シンJDBCネットワーク実装の構成パラメータについて

JDBCネットワーク実装の構成パラメータでは、クライアントとサーバー間接続で使用するセキュリティのレベルなど、ネットワーク設定を制御します。

いくつかの構成パラメータを含むプロパティ・クラス・オブジェクトは、Oracle Databaseのネットワーク暗号化および厳密認証インタフェースに渡されます。

Oracle Databaseに関連する接続プロパティを含むすべてのJDBC接続プロパティは、oracle.jdbc.OracleConnectionインタフェースで定数として定義されます。次のリストに、それらの接続プロパティの一部を列挙します。

関連項目:

構成パラメータおよび構成例の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

クライアント暗号化レベルのパラメータ

CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_LEVELパラメータは、クライアントがサーバーとのネゴシエートに使用するセキュリティのレベルを定義します。

表14-1に、このパラメータの属性を示します。

表14-1 CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_LEVEL属性

属性

説明

パラメータ・タイプ

文字列

パラメータ・クラス

静的

設定できる値

REJECTED、ACCEPTED、REQUESTED、REQUIRED

デフォルト値

ACCEPTED

構文

prop.setProperty(OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_LEVEL,level);

propはPropertiesクラスのオブジェクトです。

例

prop.setProperty(OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_LEVEL,"REQUIRED");

propはPropertiesクラスのオブジェクトです。

クライアント暗号化選択リストのパラメータ

CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_TYPESパラメータは、使用する暗号化アルゴリズムを定義します。

表14-2に、このパラメータの属性を示します。

表14-2 CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_TYPESの属性

属性

説明

パラメータ・タイプ

文字列

パラメータ・クラス

静的

設定できる値

AES256 (AES 256ビット鍵)、AES192 (AES 192ビット鍵)、AES128 (AES 128ビット鍵)

構文

prop.setProperty(OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_TYPES,algorithm);

propはPropertiesクラスのオブジェクトです。

例

prop.setProperty(OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_TYPES, "( AES256, AES192 )");

propはPropertiesクラスのオブジェクトです。

クライアント整合性レベルのパラメータ

CONNECTION_PROPERTY_THIN_NET_CHECKSUM_LEVELパラメータは、データ整合性のためにサーバーとネゴシエートする際のセキュリティのレベルを定義します。

表14-3に、このパラメータの属性を示します。

表14-3 CONNECTION_PROPERTY_THIN_NET_CHECKSUM_LEVEL属性

属性

説明

パラメータ・タイプ

文字列

パラメータ・クラス

静的

設定できる値

REJECTED、ACCEPTED、REQUESTED、REQUIRED

デフォルト値

ACCEPTED

構文

prop.setProperty(OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_LEVEL,level);

propはPropertiesクラスのオブジェクトです。

例

prop.setProperty(OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_LEVEL,"REQUIRED");

propはPropertiesクラスのオブジェクトです。

クライアント整合性選択リストのパラメータ

CONNECTION_PROPERTY_THIN_NET_CHECKSUM_TYPESパラメータは、使用するデータ整合性アルゴリズムを定義します。

表14-4に、このパラメータの属性を示します。

表14-4 CONNECTION_PROPERTY_THIN_NET_CHECKSUM_TYPESの属性

属性

説明

パラメータ・タイプ

文字列

パラメータ・クラス

静的

設定できる値

SHA1

構文

prop.setProperty(OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_TYPES, algorithm);

propはPropertiesクラスのオブジェクトです。

例

prop.setProperty(OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_TYPES,"( MD5, SHA1 )");

propはPropertiesクラスのオブジェクトです。

クライアント認証サービスのパラメータ

CONNECTION_PROPERTY_THIN_NET_AUTHENTICATION_SERVICESパラメータは、使用する認証サービスを決定します。

表14-5に、このパラメータの属性を示します。

表14-5 CONNECTION_PROPERTY_THIN_NET_AUTHENTICATION_SERVICESの属性

属性

説明

パラメータ・タイプ

文字列

パラメータ・クラス

静的

設定できる値

RADIUS、KERBEROS、SSL

構文

prop.setProperty(OracleConnection.CONNECTION_PROPERTY_THIN_NET_AUTHENTICATION_SERVICES,authentication);

propはPropertiesクラスのオブジェクトです。

例

prop.setProperty(OracleConnection.CONNECTION_PROPERTY_THIN_NET_AUTHENTICATION_SERVICES,"( RADIUS, KERBEROS, SSL)");

propはPropertiesクラスのオブジェクトです。

AnoServices定数

oracle.net.ano.AnoServicesインタフェースには、JDBCシン・ドライバによってサポートされる暗号化、認証およびチェックサムのアルゴリズムの名前が含まれます。

次の定数がoracle.net.ano.AnoServicesインタフェースに含まれます。

// ---- SUPPORTED ENCRYPTION ALG -----
public static final String ENCRYPTION_RC4_40 = "RC4_40";
public static final String ENCRYPTION_RC4_56 = "RC4_56";
public static final String ENCRYPTION_RC4_128 = "RC4_128";
public static final String ENCRYPTION_RC4_256 = "RC4_256";
public static final String ENCRYPTION_DES40C = "DES40C";
public static final String ENCRYPTION_DES56C = "DES56C";
public static final String ENCRYPTION_3DES112 = "3DES112";
public static final String ENCRYPTION_3DES168 = "3DES168";
public static final String ENCRYPTION_AES128 = "AES128";
public static final String ENCRYPTION_AES192 = "AES192";
public static final String ENCRYPTION_AES256 = "AES256";
// ---- SUPPORTED INTEGRITY ALG ----
public static final String CHECKSUM_MD5 = "MD5";
public static final String CHECKSUM_SHA1 = "SHA1";
// ---- SUPPORTED AUTHENTICATION ADAPTORS ----
public static final String AUTHENTICATION_RADIUS = "RADIUS";
public static final String AUTHENTICATION_KERBEROS = "KERBEROS";

これらの定数を使用して、暗号化、整合性および認証のパラメータを設定できます。例14-1に、その1つの例を示します。

例14-1 JDBCクライアント・コード内でのAnoServices定数の使用

import java.sql.*;
import java.util.Properties;import oracle.jdbc.*;
import oracle.net.ano.AnoServices;
/**
* JDBC thin driver demo: new security features in 11gR1.
*
* This program attempts to connect to the database using the JDBC thin
* driver and requires the connection to be encrypted with either AES256 or AES192
* and the data integrity to be verified with SHA1.
*
* In order to activate encryption and checksumming in the database you need to
* modify the sqlnet.ora file. For example:
*
*   SQLNET.ENCRYPTION_TYPES_SERVER = (AES256,AES192,AES128)
*   SQLNET.ENCRYPTION_SERVER = accepted
*   SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA1)
*   SQLNET.CRYPTO_CHECKSUM_SERVER = accepted
*
* This output of this program is:
*   Connection created! Encryption algorithm is: AES256, data integrity algorithm
*   is: SHA1
*
*/
public class DemoAESAndSHA1
{
static final String USERNAME= "hr";
static final String PASSWORD= "hr";
static final String URL =
"jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=somehost.us.example.com)(PORT=5561))"  +"(CONNECT_DATA=(SERVICE_NAME=itydemo.regress.rdbms.dev.us.example.com)))";

public static final void main(String[] argv)
{
DemoAESAndSHA1 demo = new DemoAESAndSHA1();
try
{
demo.run();
}catch(SQLException ex)
{
ex.printStackTrace();
}
}
void run() throws SQLException
{
OracleDriver dr = new OracleDriver();
Properties prop = new Properties();
// We require the connection to be encrypted with either AES256 or AES192.
// If the database doesn't accept such a security level, then the connection
// attempt will fail.
prop.setProperty(

OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_LEVEL,AnoServices.ANO_REQUIRED);
prop.setProperty(
OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_TYPES,      "( " + AnoServices.ENCRYPTION_AES256 + "," +AnoServices.ENCRYPTION_AES192 + ")");
// We also require the use of the SHA1 algorithm for data integrity checking.
prop.setProperty(

OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_LEVEL,AnoServices.ANO_REQUIRED);
prop.setProperty(
OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_TYPES,      "( " + AnoServices.CHECKSUM_SHA1 + " )");

prop.setProperty("user",DemoAESAndSHA1.USERNAME);
prop.setProperty("password",DemoAESAndSHA1.PASSWORD);
OracleConnection oraConn =
(OracleConnection)dr.connect(DemoAESAndSHA1.URL,prop);

System.out.println("Connection created! Encryption algorithm is: "+oraConn.getEncryptionAlgorithmName()    +", data integrity algorithm is: "+oraConn.getDataIntegrityAlgorithmName());

oraConn.close();
}

}

第V部 厳密認証の管理

第V部では、厳密認証の管理方法について説明します。

- 厳密認証の概要

- 厳密認証の管理ツール

- Kerberos認証の構成

- Secure Sockets Layer認証の構成

- RADIUS認証の構成

- 厳密認証の使用のカスタマイズ

15 厳密認証の概要

厳密認証を使用すると、Secure Sockets Layer (SSL)などの追加のツールを構成して、データベースにログインするユーザーの識別情報を検証できます。

内容は次のとおりです。

- 厳密認証とは

- 集中化された認証とシングル・サインオン

- サポートされている厳密認証方式

- Oracle Databaseネットワークの暗号化/厳密認証アーキテクチャ

- 厳密認証のシステム要件

- Oracleネットワーク暗号化および厳密認証の制限事項

厳密認証とは

認証は、データベースにログインしようとしているユーザーの識別情報を証明するために使用されます。

分散環境では、ユーザーIDを認証することが必須であり、これを行わないとネットワーク・セキュリティの信頼性はほぼありません。パスワードは、認証で最も一般的な手段です。Oracle Databaseでは、Oracle認証アダプタを使用して厳密認証を有効にし、Oracle認証アダプタは、デジタル証明書を使用したSSLを含む様々なサード・パーティ認証サービスをサポートします。

図15-1は、サード・パーティの認証サーバーを使用するように構成されたOracle Databaseインスタンスでのユーザー認証を示しています。ネットワークのすべてのメンバー(クライアントからサーバー、サーバーからサーバー、ユーザーからクライアントとサーバーの両方)を1箇所で集中的に認証する方法は、メンバーのIDを偽造するネットワーク・ノードの脅威に対処する効果的な方法の1つです。

図15-1 Oracle認証アダプタによる厳密認証

集中化された認証とシングル・サインオン

シングル・サインオンでは、ユーザーは1つのパスワードで複数のアカウントとアプリケーションにアクセスできます。

集中化された認証では、シングル・サインオン(SSO)の利点もユーザーに提供されます。

シングル・サイン・オンでは、ユーザーがログインする必要があるのは1回のみであり、ユーザー名とパスワードを再度入力しなくても、他の任意のサービスに自動的に接続できます。シングル・サインオンを使用すると、ユーザーは複数のパスワードを記憶したり管理する必要がなくなるため、複数のサービスへのログインに費やす時間を削減できます。

集中化されたネットワーク認証の動作

集中化されたネットワーク認証システムは、Oracleサーバー、認証サーバー、およびOracleサーバーへ接続するユーザーの間で機能します。

図15-2は、集中化されたネットワーク認証サービスの通常の動作を示しています。

図15-2 ネットワーク認証サービスでのユーザーの認証方法

集中化されたネットワーク認証プロセスは、次のように動作します。

1. ユーザー(クライアント)が認証サービスを要求し、トークンまたはパスワードなどの識別情報を入力します。

2. 認証サーバーによりユーザーの識別情報が検証され、チケットまたは資格証明がクライアントに渡されます。チケットまたは資格証明には期限がある場合があります。

3. クライアントは、これらの資格証明をサービス要求(データベースへの接続など)と一緒にOracleサーバーに渡します。

4. サーバーは資格証明を認証サーバーに渡し、認証を行います。

5. 認証サーバーは資格証明をチェックし、Oracleサーバーに通知します。

6. 認証サーバーが資格証明を受け入れた場合、Oracleサーバーはユーザーを認証します。認証サーバーが資格証明を拒否した場合、認証は失敗し、サービス要求は拒否されます。

サポートされている厳密認証方式

Oracle Databaseは、業界で標準的な次の認証方式をサポートしています。

内容は次のとおりです。

- Kerberosについて

- Remote Authentication Dial-In User Service (RADIUS)について

- Secure Sockets Layerについて

Kerberosについて

Oracle DatabaseはKerberosをサポートしており、Oracleユーザーにシングル・サインオンおよび集中化された認証の利点を提供します。

Kerberosは、共有秘密を使用するサード・パーティの認証システムです。サード・パーティがセキュアであることを保障し、シングル・サインオン機能、集中化されたパスワード・ストレージ、データベース・リンク認証、拡張されたPCセキュリティを提供します。Kerberosは、Kerberos認証サーバーを使用して認証を行います。このアダプタの構成および使用の詳細は、「Kerberos認証の構成」を参照してください。

注意:

Kerberos用のOracle認証では、データベース・リンク認証(プロキシ認証とも呼ばれる)が提供されます。Kerberosは、エンタープライズ・ユーザー・セキュリティでサポートされている認証方式でもあります。

Remote Authentication Dial-In User Service (RADIUS)について

RADIUSは、最も広く知られている、リモートでの認証とアクセスを可能にするクライアント/サーバー・セキュリティ・プロトコルです。

Oracle Databaseは、この標準をクライアント/サーバー・ネットワーク環境で使用して、RADIUSプロトコルをサポートするあらゆる認証方式の使用を可能にします。RADIUSは、トークン・カードやスマートカードなど、いろいろな認証メカニズムで使用できます。

- スマート・カード。RADIUS準拠のスマートカードは、クレジット・カードに似たハードウェア・デバイスであり、メモリーとプロセッサを備えています。クライアント・ワークステーションにあるスマートカード・リーダーで読み取られます。

- トークン・カード。トークン・カード(Secure IDまたはRADIUSに準拠)は、いくつかの異なるメカニズムによって使いやすくできます。一部のトークン・カードは、認証サービスと同期された1回かぎりのパスワードを動的に表示します。サーバーは、認証サービスにアクセスすることにより、トークン・カードによって提供されるパスワードを任意の時点で検証できます。トークン・カードにはキーパッドを持ち、チャレンジ・レスポンス・ベースで動作するものがあります。この場合、サーバーはユーザーがトークン・カードに入力するチャレンジ(番号)を提供します。トークン・カードはレスポンス(チャレンジから暗号的に導出される別の番号)を提供し、ユーザーはそれを入力してサーバーに送信します。
SecurIDトークンはRADIUSアダプタを介して使用できます。

関連項目:
RADIUSの構成および使用の詳細は、RADIUS認証の構成を参照してください

Secure Sockets Layerについて

Secure Sockets Layer(SSL)は、ネットワーク接続を保護するための業界標準プロトコルです。

SSLは、認証、データの暗号化およびデータの整合性を提供します。

SSLプロトコルは、公開鍵インフラストラクチャ(PKI)の基盤です。認証のために、SSLはX.509v3標準に準拠したデジタル証明書と公開鍵/秘密鍵ペアを使用します。

Oracle DatabaseのSSLは、任意のクライアントと任意のサーバー間の通信を保護するために使用できます。SSLは、サーバーのみ、クライアントのみ、またはクライアントとサーバーの両方に認証を提供するように構成できます。また、Oracle Databaseでサポートされている他の認証方式(データベース・ユーザー名とパスワード、RADIUSおよびKerberos)と組み合せて、SSL機能を構成することもできます。

PKI実装をサポートするために、Oracle DatabaseにはSSL以外に次の機能があります。

- Oracleウォレット(PKI資格証明を格納できる)

- Oracle Wallet Manager (Oracleウォレットを管理するために使用できる)

- 証明書失効リスト(CRL)による証明書の検証

- ハードウェア・セキュリティ・モジュールのサポート

関連項目:

- SSL、証明書の検証およびハードウェア・セキュリティ・モジュールの概念、構成および使用の詳細は、Secure Sockets Layer認証の構成を参照してください

- 他の認証方式と組み合せたSSLの構成の詳細は、「厳密認証の使用のカスタマイズ」を参照してください。

Oracle Databaseネットワークの暗号化/厳密認証アーキテクチャ

Oracle Databaseネットワーク暗号化および厳密認証アーキテクチャは、Oracleデータベース・サーバーまたはクライアントのインストールを補完します。

図15-3は、Oracleネットワーク環境におけるこのアーキテクチャを示しています。

図15-3 Oracleネットワーク暗号化および厳密認証アーキテクチャ

Oracle Databaseでは、既存のOracleプロトコル・アダプタと同様のアダプタによって認証がサポートされます。図15-4に示すように、認証アダプタによってOracle Netインタフェースが統合され、既存のアプリケーションを変更しなくてもそれらのアプリケーションで新しい認証システムを透過的に利用できるようになります。

図15-4 認証アダプタを使用したOracle Net Services

関連項目:
Oracleネットワーク環境でのスタック通信の詳細は『Oracle Database Net Services管理者ガイド』を参照してください。

厳密認証のシステム要件

Kerberos、RADIUSおよびSecure Sockets Layer (SSL)には、厳密認証のための一連のシステム要件があります。

表15-1に、厳密認証のためのSSLシステム要件を示します。

表15-1 認証方式とシステム要件

認証方式

システム要件

Kerberos

- MIT Kerberosバージョン5、リリース1.8以上。

- Kerberos認証サーバーを、物理的に安全なシステムにインストールする必要があります。

RADIUS

- Internet Engineering Task Force (IETF) RFC #2138 Remote Authentication Dial In User Service (RADIUS)およびRFC #2139 RADIUS Accountingの規格に準拠するRADIUSサーバー。

- チャレンジ・レスポンス認証を有効にするには、JavaSoftのJava Development Kitのリリース1.1で指定されているJavaネイティブ・インタフェースをサポートするオペレーティング・システムでRADIUSを実行する必要があります。

SSL

- Oracle Wallet Manager 10gリリースと互換性のあるウォレット。以前のリリースのOracle Wallet Managerで作成されたウォレットは、上位互換ではありません。

Oracleネットワーク暗号化および厳密認証の制限事項

Oracleアプリケーションは、Oracleネットワークの暗号化および厳密認証をサポートしています。

ただし、Oracleネットワーク暗号化および厳密認証ではデータを安全に送信するためにOracle Net Servicesが必要であるため、Microsoft Windowsで実行されるOracleの財務管理アプリケーション、人事管理アプリケーションおよび生産管理アプリケーションの一部では、これらの外部認証機能はサポートされません。

Oracle Display Manager (ODM)ではOracle Net Servicesが使用されないため、これらの製品のODMを使用する部分では、Oracleネットワーク暗号化および厳密認証は利用されません。

16 厳密認証の管理ツール

ネットワーク暗号化および公開鍵インフラストラクチャ資格証明には、厳密認証の一連の管理ツールを使用できます。

内容は次のとおりです。

- 構成ツールと管理ツールについて

- ネットワーク暗号化ツールと厳密認証構成ツール

- 公開鍵インフラストラクチャ資格証明管理ツール

- 厳密認証管理者の義務

構成ツールと管理ツールについて

構成ツールと管理ツールで、Oracle Net Servicesの暗号化、整合性(チェックサム)および厳密認証方式を管理します。

厳密認証方式の構成には、KerberosやRADIUSなどのサード・パーティ・ソフトウェアを含めることができ、Secure Sockets Layer (SSL)でデジタル証明書を使用するための公開鍵インフラストラクチャの構成や管理が必要になることがあります。

ネットワーク暗号化ツールと厳密認証構成ツール

Oracle Net Servicesは、標準の暗号化アルゴリズムを使用してデータを暗号化し、Kerberos、RADIUS、SSLなどの厳密認証方式に対応するように構成できます。

内容は次のとおりです。

- バージョン情報

- Kerberosアダプタ・コマンドライン・ユーティリティ

バージョン情報

Oracle Net Managerで、Oracle Net Servicesをローカル・クライアントやサーバー・ホスト上のOracleホーム向けに構成します。

グラフィカル・ユーザー・インタフェース・ツールであるOracle Net Managerを使用して、ネーミング、リスナー、一般的なネットワーク設定などのOracle Net Servicesを構成できますが、Oracle Netプロトコルを使用する次の機能を構成することもできます。

- 厳密認証(Kerberos、RADIUSおよびSecure Sockets Layer)

- ネットワーク暗号化(RC4、DES、Triple-DESおよびAES)

- データ整合性のためのチェックサム(MD5、SHA-1、SHA-2)

Kerberosアダプタ・コマンドライン・ユーティリティ

Kerberosアダプタは、Kerberos資格証明を取得、キャッシュ、表示および削除するコマンドライン・ユーティリティを提供します。

次の表では、これらのユーティリティについて簡単に説明しています。

表16-1 Kerberosアダプタ・コマンドライン・ユーティリティ

ユーティリティ名

説明

okinit

Key Distribution Center (KDC) からKerberosチケットを取得し、それをユーザーの資格証明キャッシュに格納します。

oklist

指定された資格証明キャッシュ内のKerberosチケットのリストを表示します。

okdstry

指定された資格証明キャッシュからKerberos資格証明を削除します。

関連項目:

これらのユーティリティ、構文および使用可能なオプションの詳細は、Kerberos認証アダプタのユーティリティを参照してください

注意:

Cybersafeアダプタは、このリリースからサポートされなくなりました。かわりに、OracleのKerberosアダプタを使用する必要があります。Kerberosアダプタを使用する場合は、Cybersafe KDC (Trust Broker)によるKerberos認証が引き続きサポートされます。

公開鍵インフラストラクチャ資格証明管理ツール

公開鍵インフラストラクチャ(PKI)によって提供されるセキュリティは、PKI資格証明をどの程度効果的に格納、管理および検証しているかに依存します。

内容は次のとおりです。

- Oracle Wallet Managerについて

- orapkiユーティリティについて

Oracle Wallet Managerについて

ウォレットの所有者とセキュリティ管理者はOracle Wallet Managerを使用して、Oracleウォレット内のセキュリティ資格証明を管理および編集します。

ウォレットはパスワードで保護されたコンテナで、認証情報や、SSLに必要な秘密鍵、証明書および信頼できる証明書を含む署名証明書が格納されます。Oracle Wallet Managerを使用して次のタスクを実行できます。

- 公開鍵と秘密鍵のペアの生成

- ユーザー資格証明書の格納および管理

- 証明書リクエストの生成

- 資格証明の格納および管理(ルート鍵証明書および証明連鎖)

- ウォレットのLDAPディレクトリへのアップロードおよびLDAPディレクトリからのダウンロード

- ハードウェア・セキュリティ・モジュールの資格証明書を格納するウォレットの作成

注意:

Oracle Databaseの以前のリリースでは、Oracle Wallet Managerを使用して、透過的データ暗号化のウォレットを構成できます。このリリースでは、かわりにADMINISTER KEY MANAGEMENT SQL文を使用できます。詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

orapkiユーティリティについて

orapkiユーティリティで、証明書失効リスト(CRL)の管理、Oracleウォレットの作成と管理、および署名付き証明書の作成を行います。

このコマンドライン・ユーティリティの基本構文は次のとおりです。

orapki module command -option_1 argument ... -option_n argument

たとえば、次のコマンドを実行すると、machine1.us.example.comにインストールされ、ポート389を使用するOracle Internet DirectoryのインスタンスのCRLサブツリーにあるすべてのCRLがリストされます。

orapki crl list -ldap machine1.us.example.com:389

注意:

透過的データ暗号化を構成するorapkiの使用は非推奨です。かわりに、ADMINISTER KEY MANAGEMENT SQL文を使用します。

関連項目:

- orapkiを使用してディレクトリ内のCRLを管理する方法の詳細は、証明書失効リストの管理を参照してください

- 使用可能なすべてのorapkiコマンドのリファレンス情報は、orapkiユーティリティを使用したPKI要素の管理を参照してください

- ADMINISTER KEY MANAGEMENT SQL文の使用の詳細は、『Oracle Database Advanced Securityガイド』を参照してください

厳密認証管理者の義務

セキュリティ管理者のタスクには、Oracleデータベースとの間の接続の保護が含まれます。

次の表に、厳密認証、タスクの実行に使用するツール、およびタスクのドキュメントの場所へのリンクに対して責任を負うセキュリティ管理者の主要なタスクを示します。

表16-2 セキュリティ管理者/DBAの一般的な構成および管理タスク

タスク

使用するツール

関連項目

データベース・サーバーとクライアント間の暗号化されたOracle Net接続を構成します。

Oracle Net Manager

クライアントとサーバーでの暗号化の構成

データベース・サーバーとクライアント間のOracle Net接続のチェックサムを構成します。

Oracle Net Manager

クライアントとサーバーでの整合性の構成

RADIUS認証を受け入れるようにデータベース・クライアントを構成します。

Oracle Net Manager

手順1A: OracleクライアントでのRADIUSの構成

RADIUS認証を受け入れるようにデータベースを構成します。

Oracle Net Manager

手順1B: Oracleデータベース・サーバーでのRADIUSの構成

RADIUSユーザーを作成し、データベース・セッションへのアクセス権を付与します。

SQL*Plus

「手順2: ユーザーの作成とアクセス権の付与」

データベース・クライアントとサーバーにKerberos認証を構成します。

Oracle Net Manager

手順6: Kerberos認証の構成

Kerberosデータベース・ユーザーを作成します。

- kadmin.local

- Oracle Net Manager

- 手順7: Kerberosユーザーの作成

- 手順8: 外部認証されたOracleユーザーの作成

資格証明キャッシュ内のKerberos資格証明を管理します。

- okinit

- oklist

- okdstry

- okcreate

- 初期チケットを取得するためのokinitユーティリティ・オプション

- 資格証明を表示するためのoklistユーティリティ・オプション

データベース・クライアントまたはサーバーのウォレットを作成します。

Oracle Wallet Manager

Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド

認証局(CA)にSSL認証用のユーザー証明書をリクエストします。

Oracle Wallet Manager

- 証明書リクエストを追加するには、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- Oracleウォレットにユーザー証明書をインポートするには、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

ユーザー証明書とそれに関連する信頼できる証明書(CA証明書)をウォレットにインポートします。

Oracle Wallet Manager

- 信頼できる証明書をインポートするには、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください

- Oracleウォレットにユーザー証明書をインポートするには、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

データベース・クライアントのSSL接続を構成します。

Oracle Net Manager

手順2: クライアントでのSecure Sockets Layerの構成

データベース・サーバーのSSL接続を構成します。

Oracle Net Manager

手順1: サーバーでのSecure Sockets Layerの構成

証明書失効リスト(CRL)を使用した証明書の検証を有効化します。

Oracle Net Manager

証明書失効リストによる証明書検証の構成

17 Kerberos認証の構成

Kerberosは、信頼性のあるサード・パーティ認証システムです。これは、共有秘密に依存するもので、サード・パーティが安全であることが前提になります。Kerberos認証を使用するようにOracle Databaseを構成できます。

内容は次のとおりです。

- Kerberos認証の有効化

- Kerberos認証アダプタのユーティリティ

- Kerberosによって認証されたOracleデータベース・サーバーへの接続

- Windows 2008ドメイン・コントローラKDCとの相互運用性の構成

- Kerberos認証フォールバック動作の構成

- Oracle Kerberos認証の構成のトラブルシューティング

関連項目:
KerberosユーザーをKerberos認証のエンタープライズ・ユーザーに移行する方法の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

Kerberos認証の有効化

Oracle Databaseに対してKerberos認証を有効にするには、これをインストールしてから一連の構成手順に従います。

内容は次のとおりです。

- 手順1: Kerberosのインストール

- 手順2: Oracleデータベース・サーバーに対するサービス・プリンシパルの構成

- 手順3: Kerberosからのサービス・キー表の抽出

- 手順4: Oracleデータベース・サーバーとOracleクライアントのインストール

- 手順5: Oracle Net ServicesとOracle Databaseの構成

- 手順6: Kerberos認証の構成

- 手順7: Kerberosユーザーの作成

- 手順8: 外部認証されたOracleユーザーの作成

- 手順9: Kerberos/Oracleユーザーの初期チケットの取得

手順1: Kerberosのインストール

Kerberosバージョン5をインストールしてください。

Kerberosの構築とインストールに関する注意事項の供給元配布資料に詳細が記載されています。Kerberosのインストール後、POWERシステム(64ビット)でIBM AIXを使用する場合、Kerboros 5が推奨の認証方式であることを確認する必要があります。

1. 認証サーバーとして動作するシステムにKerberosをインストールします。

注意:

32ビット・バージョンのOracle Databaseからアップグレードした後に初めてKerberos認証アダプタを使用すると、エラー・メッセージ「ORA-01637: パケット受信に失敗しました。」が表示されます。

回避策: 64ビット・バージョンのデータベースにアップグレードした後、Kerberos外部認証方式を使用する前に、コンピュータ上の/usr/tmp/oracle_service_name.RCという名前のファイルを確認して削除します。

2. POWERシステム(64ビット)上のIBM AIXの場合、認証方式をチェックします。

例:

/usr/bin/lsauthent

次のような出力が表示されます。

Standard Aix

3. Kerberos 5を推奨方式として構成します。

例:

/usr/bin/chauthent -k5 -std

このコマンドは、Kerberos 5を推奨方式(k5)、標準AIXを2番目の方式(std)として設定します。

4. Kerberos 5が現在推奨方式になっていることを確認するには、新しい構成をチェックします。

/usr/bin/lsauthent

Kerberos 5
Standard Aix

手順2: Oracleデータベース・サーバーに対するサービス・プリンシパルの構成

Kerberosを使用して自己を認証するクライアントの識別情報をOracleデータベース・サーバーで検証できるようにするには、Oracle Databaseのサービス・プリンシパルを作成する必要があります。

1. 次の形式を使用して、サーバー・プリンシパルの名前を決定します。

kservice/kinstance@REALM

サービス・プリンシパル内の各フィールドで次の値を指定します。

サービス・プリンシパル・フィールド

説明

kservice

Oracleサービスを表す、大/小文字を区別する文字列。データベース・サービス名と同じでもかまいません。

kinstance

通常は、Oracle Databaseが実行されているシステムの完全修飾DNS名。

REALM

サービス・プリンシパルが登録されているKerberosレルムの名前。REALMは常に大文字である必要があり、通常はDNSドメイン名です。

この項のユーティリティ名は実行可能プログラムです。ただし、Kerberosユーザー名krbuserおよびレルムEXAMPLE.COMは単なる例です。

たとえば、kserviceがoracle、Oracle Databaseが実行されているシステムの完全修飾名がdbserver.example.com、レルムがEXAMPLE.COMとします。この場合、プリンシパル名は次のようになります。

oracle/dbserver.example.com@EXAMPLE.COM

2. kadmin.localを実行してサーバー・プリンシパルを作成します。UNIXでは、次の構文を使用して、rootユーザーとしてこのコマンドを実行します。

# cd /kerberos-install-directory/sbin
# ./kadmin.local

たとえば、oracle/dbserver.example.com@EXAMPLE.COMという名前のプリンシパルを、Kerberosが認識するサーバー・プリンシパルのリストに追加するには、次のように入力します。

kadmin.local:addprinc -randkey oracle/dbserver.example.com@EXAMPLE.COM

手順3: Kerberosからのサービス・キー表の抽出

次に、Kerberosからサービス・キー表を抽出し、Oracleデータベース・サーバー/Kerberosクライアント・システムにコピーします。

たとえば、dbserver.example.comのサービス・キー表を抽出するには、次の手順を実行します。

1. 次のように入力してサービス・キー表を抽出します。

kadmin.local:  ktadd -k /tmp/keytab oracle/dbserver.example.com
Entry for principal oracle/dbserver.example.com with kvno 2,
encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:
WRFILE:/tmp/keytab

kadmin.local:  exit

2. サービス・キー表をチェックするには、次のコマンドを入力します。

oklist -k -t /tmp/keytab

3. サービス・キー表を抽出した後、古いエントリに加えて新しいエントリが表にあることを確認します。

新しいエントリがない場合、またはさらに追加する必要がある場合は、kadmin.localを使用して追加します。

ktaddを使用するときにレルムを入力しない場合、Kerberosサーバーのデフォルトのレルムが使用されます。kadmin.localは、localhostで実行されているKerberosサーバーに接続されます。

4. Kerberosサービス・キー表がKerberosクライアントと同じシステム上にある場合は、移動できます。Kerberosサービス・キー表がKerberosクライアントと異なるシステム上にある場合は、FTPなどのプログラムを使用してファイルを転送する必要があります。FTPを使用する場合は、ファイルをバイナリ・モードで転送します。

次の例は、UNIXプラットフォームでサービス・キー表を移動する方法を示しています。

# mv /tmp/keytab /etc/v5srvtab

サービス・ファイルのデフォルト名は、/etc/v5srvtabです。

5. Oracleデータベース・サーバー実行可能ファイルの所有者がサービス・キー表(前の例の/etc/v5srvtab)を読み取ることができることを確認します。

そのためには、ファイル所有者をOracleユーザーに設定するか、またはファイルをOracleが属するグループに対して読取り可能にします。

ファイルをすべてのユーザーに対して読取り可能にしないでください。そのことによってセキュリティ侵害が発生する場合があります。

手順4: Oracleデータベース・サーバーとOracleクライアントのインストール

Kerberosからサービス・キー表を抽出した後、Oracleデータベース・サーバーおよびOracleクライアントをインストールします。

- Oracleデータベース・サーバーおよびクライアント・ソフトウェアのインストールの詳細は、Oracle Databaseオペレーティング・システムに固有のインストール・ドキュメントを参照してください。

手順5: Oracle Net ServicesとOracle Databaseの構成

Oracleデータベース・サーバーとクライアントのインストール後、サーバーとクライアントでOracle Net Servicesを構成できます。

- Oracleデータベース・サーバーおよびクライアントでのOracle Net Servicesの構成の詳細は、次のドキュメントを参照してください。

- オペレーティング・システム固有のOracle Databaseインストール関連ドキュメント

- Oracle Database Net Services管理者ガイド

手順6: Kerberos認証の構成

Oracleデータベース・サーバーおよびクライアントのsqlnet.oraファイルで必須パラメータを設定する必要があります。

マルチテナント環境では、sqlnet.oraファイルの設定はすべてのプラガブル・データベース(PDB)に適用されることに注意してください。

- 手順6A: クライアントとデータベース・サーバーでのKerberosの構成

- 手順6B: 初期化パラメータの設定

- 手順6C: sqlnet.oraパラメータの設定(オプション)

手順6A: クライアントとデータベース・サーバーでのKerberosの構成

最初に、クライアントとデータベース・サーバーでKerberos認証サービス・パラメータを構成する必要があります。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。

ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「認証」タブを選択します。

5. 「使用可能なメソッド」リストから、「KERBEROS5」を選択します。

6. 右矢印(>)をクリックして、「KERBEROS5」を「選択メソッド」リストに移動します。

7. 選択したメソッドを使用する順に並べます。

そのためには、「選択メソッド」リストでメソッドを選択し、「上へ」または「下へ」をクリックしてリスト内に配置します。たとえば、最初に使用するサービスをKERBEROS5にするには、リストの先頭に移動します。

8. 「その他のパラメータ」タブを選択します。

9. 「認証サービス」リストから「KERBEROS(V5)」を選択します。

10. 「サービス」フィールドに「Kerberos」と入力します。

このフィールドでは、Kerberosのサービス・チケットを取得するためにOracle Databaseが使用するサービスの名前を定義します。このフィールドに値を入力すると、他のフィールドに入力できるようになります。

11. オプションで、次のフィールドの値を入力します。

- 「資格証明キャッシュ・ファイル」

- 「構成ファイル」

- 「レルム変換ファイル」

- 「キー表」

- 「時間誤差」

構成するフィールドとパラメータの詳細は、Oracle Net Managerオンライン・ヘルプおよび「手順6C: sqlnet.oraパラメータの設定(オプション)」を参照してください。

12. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。

sqlnet.oraファイルは、前述の手順で行った可能性のあるオプションの選択だけでなく、次のエントリでも更新されます。

SQLNET.AUTHENTICATION_SERVICES=(KERBEROS5)
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=kservice

手順6B: 初期化パラメータの設定

次に、OS_AUTHENT_PREFIX初期化パラメータを設定します。

1. init.oraファイルを探します。

デフォルトでは、init.oraファイルは、LinuxおよびUNIXシステムの場合はORACLE_HOME/dbsディレクトリ(または同じデータ・ファイルの場所)、Windowsの場合はORACLE_HOME\databaseディレクトリにあります。

2. init.oraファイルで、init.ora初期化パラメータ・ファイルのOS_AUTHENT_PREFIXの値をnullに設定します。

例:

OS_AUTHENT_PREFIX=""

Kerberosユーザー名は長くてもかまわないためこの値をnullに設定しますが、Oracleユーザー名は30文字までに制限されています。このパラメータをnullに設定すると、OPS$のデフォルト値が上書きされます。

注意:

30文字を超えるKerberosユーザー名を持つ外部データベース・ユーザーを作成できます。詳細は、「手順8: 外部認証されたOracleユーザーの作成」を参照してください。

手順6C: sqlnet.oraパラメータの設定(オプション)

セキュリティを強化するために、必須パラメータに加えて、オプションのsqlnet.oraパラメータを設定できます。

- オプションで、クライアントおよびOracleデータベース・サーバーの両方に、次の表に示すパラメータを設定します。

表17-1 Kerberos固有のsqlnet.oraパラメータ

パラメータ

説明

SQLNET.KERBEROS5_CC_NAME=pathname_to_credentials_cache_file|OS_MEMORY

Kerberos資格証明キャッシュ(CC)ファイルへの完全パス名を指定します。デフォルト値は、オペレーティング・システムによって異なります。UNIXでは、/tmp/krb5cc_useridです。

OS_MEMORYオプションを使用すると、OS管理メモリーの資格証明キャッシュが資格証明キャッシュ・ファイルに使用されるように指定されます。これに対して現在サポートされている値は、OSMSFT (Microsoft Windowsの場合)のみです。

SQLNET.KERBEROS5_CC_NAMEの値は、次の形式を使用して指定できます。

- SQLNET.KERBEROS5_CC_NAME=complete_path_to_cc_file
例:

SQLNET.KERBEROS5_CC_NAME=/tmp/kcache

SQLNET.KERBEROS5_CC_NAME=D:\tmp\kcache

- SQLNET.KERBEROS5_CC_NAME=FILE:complete_path_to_cc_file
例:

SQLNET.KERBEROS5_CC_NAME=FILE:/tmp/kcache

- SQLNET.KERBEROS5_CC_NAME=OSMSFT:
Windowsを実行し、Microsoft KDCを使用している場合は、この値を使用します。

このパラメータはKRB5CCNAME環境変数を使用して設定することもできますが、sqlnet.oraファイルで設定する値は、KRB5CCNAMEで設定する値よりも優先されます。

例:

SQLNET.KERBEROS5_CC_NAME=/usr/tmp/krbcache

SQLNET.KERBEROS5_CLOCKSKEW=number_of_seconds_accepted_as_network_delay

このパラメータは、Kerberos資格証明を期限切れとみなすまでの秒数を指定します。これは、資格証明がクライアントまたはデータベース・サーバーによって実際に受け取られるときに使用されます。また、再生攻撃を受けないように資格証明を格納する必要があるかどうかをOracleデータベース・サーバーが判断するときにも、使用されます。デフォルトは300秒です。

例:

SQLNET.KERBEROS5_CLOCKSKEW=1200

SQLNET.KERBEROS5_CONF=pathname_to_Kerberos_configuration_file|AUTO_DISCOVER

このパラメータは、Kerberos構成ファイルへの完全パス名を指定します。構成ファイルには、デフォルトのKDC (key distribution center)のレルムが含まれており、レルムをKDCホストにマッピングします。デフォルトは、オペレーティング・システムによって異なります。UNIXでは、/krb5/krb.confです。

構成ファイルのかわりにAUTO_DISCOVERオプションを使用すると、KerberosクライアントでKDCを自動検出できます。

例:

SQLNET.KERBEROS5_CONF=/krb/krb.conf
SQLNET.KERBEROS5_CONF=AUTO_DISCOVER

SQLNET.KERBEROS5_CONF_LOCATION=path_to_Kerberos_configuration_directory

このパラメータは、Kerberos構成ファイルがシステムによって作成され、クライアントで指定する必要がないことを示します。構成ファイルは、DNS参照を使用してデフォルトのKDCのレルムを取得し、レルムをKDCホストにマッピングします。

例:

SQLNET.KERBEROS5_CONF_LOCATION=/krb

SQLNET.KERBEROS5_KEYTAB=path_to_Kerberos_principal/key_table

このパラメータは、Kerberosプリンシパル/秘密鍵マッピング・ファイルへの完全パス名を指定します。これは、Oracleデータベース・サーバーが鍵を抽出し、クライアントから受信する認証情報を複号化するために使用されます。デフォルトは、オペレーティング・システムによって異なります。UNIXでは、/etc/v5srvtabです。

例:

SQLNET.KERBEROS5_KEYTAB=/etc/v5srvtab

SQLNET.KERBEROS5_REALMS=path_to_Kerberos_realm_translation_file

このパラメータは、Kerberosレルム変換ファイルへの完全パス名を指定します。変換ファイルを使用して、ホスト名またはドメイン名をレルムにマッピングします。デフォルトは、オペレーティング・システムによって異なります。UNIXでは、/etc/krb.realmsです。

例:

SQLNET.KERBEROS5_REALMS=/krb5/krb.realms

手順7: Kerberosユーザーの作成

管理ツールがインストールされているKerberos認証サーバーでKerberosユーザーを作成する必要があります。

レルムはすでに存在している必要があります。

注意:

この項のユーティリティ名は実行可能プログラムです。ただし、Kerberosユーザー名krbuserおよびレルムEXAMPLE.COMは単なる例です。システムによって異なる場合があります。

- /krb5/admin/kadmin.localをrootとして実行して、krbuserなどの新しいKerberosユーザーを作成します。
たとえば、UNIX固有のKerberosユーザーを作成するとします。

# /krb5/admin/kadmin.local
kadmin.local: addprinc krbuser
Enter password for principal: "krbuser@example.com": (password does not display)
Re-enter password for principal: "krbuser@example.com": (password does not display)
kadmin.local: exit

手順8: 外部認証されたOracleユーザーの作成

次に、外部認証されるOracleユーザーを作成します。

1. CREATE USER権限を持つユーザーとしてSQL*Plusにログインします。

sqlplus sec_admin - Or, CONNECT sec_admin@hrpdb
Enter password: password

2. OS_AUTHENT_PREFIXがnull ("")に設定されていることを確認します。

3. Kerberosユーザーに対応するOracle Databaseユーザー・アカウントを作成します。Oracleユーザー名を大文字で入力して、その名前を二重引用符で囲みます。

例:

CREATE USER "KRBUSER@EXAMPLE.COM" IDENTIFIED EXTERNALLY;
GRANT CREATE SESSION TO "KRBUSER@EXAMPLE.COM";

ユーザーのKerberosプリンシパル名が30文字を超え、最大1024文字の場合は、次の構文を使用してユーザーを作成します。

CREATE USER db_user_name IDENTIFIED EXTERNALLY AS 'kerberos_principal_name';

例:

CREATE USER KRBUSER IDENTIFIED EXTERNALLY AS 'KerberosUser@example.com';

注意:

データベース管理者は、2つのデータベース・ユーザーが同じKerberosプリンシパル名で外部から識別されないことを確認する必要があります。

手順9: Kerberos/Oracleユーザーの初期チケットの取得

データベースに接続するには、Key Distribution Center (KDC)に初期チケットを要求する必要があります。

- 初期チケットを要求するには、クライアントで次のコマンドを実行します。

% okinit username

データベース・リンク間で使用可能な資格証明を有効にするには、-fオプションを含めて、プロンプトが表示された場合はKerberosパスワードを指定します。

% okinit -f
Password for krbuser@EXAMPLE.COM:(password does not display)

Kerberos認証アダプタのユーティリティ

Oracle Kerberos認証アダプタのユーティリティは、Oracle Kerberos認証サポートがインストールされたOracleクライアントで使用するように設計されています。

内容は次のとおりです。

- 初期チケットを取得するためのokinitユーティリティ・オプション

- 資格証明を表示するためのoklistユーティリティ・オプション

- キャッシュ・ファイルからの資格証明の削除

初期チケットを取得するためのokinitユーティリティ・オプション

okinitユーティリティでは、Kerberosチケットを取得し、キャッシュします。

通常は、このユーティリティを使用してチケット認可チケットを取得し、ユーザーが入力したパスワードを使用してkey distribution center (KDC)からの資格証明を復号化します。チケット認可チケットは、ユーザーの資格証明キャッシュに格納されます。

表17-2に、okinitで使用可能なオプションを示します。

表17-2 okinitユーティリティのオプション

オプション

説明

-f

転送可能なチケット認可チケットを要求します。データベース・リンクをたどる場合は、このオプションが必要です。

-l

チケット認可チケットおよびすべての後続チケットの存続期間を指定します。デフォルトで、チケット認可チケットは8時間有効ですが、存続期間がより短いまたは長い資格証明を指定することもできます。KDCはこのオプションを無視したり、各サイトで指定できる時間を制限したりできます。次の例に示すように、存続期間の値は、w (週)、d (日)、h (時間)、m (分)またはs (秒)で修飾された数字で構成される文字列です。

okinit -l 2wld6h20m30s

この例では、存続期間が2週間と1日6時間20分30秒のチケット認可チケットが要求されます。

-c

代替資格証明キャッシュを指定します。UNIXでは、デフォルトは/tmp/krb5cc_uidです。代替資格証明キャッシュは、sqlnet.oraファイルでSQLNET.KERBEROS5_CC_NAMEパラメータを使用して指定することもできます。

-e

使用するKerberos暗号化タイプを表す数字を指定します。

このオプションは、セッションに対して特定のKerberos暗号化タイプの鍵を要求する場合に使用できます。複数の暗号化タイプを指定すると、KDCでは一般的で最も強力な暗号化タイプがリストから選択されます。

許容される値は次のとおりです。

- 18: AES256-CTS

次の例では、AES256-CTS暗号化タイプを要求します。

okinit -e 18 krbuser@REALM

複数の暗号化タイプを要求するには、このオプションを繰り返します。

-?

コマンドライン・オプションのリストを表示します。

資格証明を表示するためのoklistユーティリティ・オプション

oklistユーティリティを実行して、保持しているチケットのリストを表示できます。

表17-3に、使用可能なokinitオプションを示します。

表17-3 oklistユーティリティのオプション

オプション

説明

-f

資格証明のフラグを表示します。関連するフラグは次のとおりです。

- I: 資格証明がチケット認可チケットです。

- F: 資格証明が転送可能です。

- f: 資格証明が転送済です。

-c

代替資格証明キャッシュを指定します。UNIXでは、デフォルトは/tmp/krb5cc_uidです。代替資格証明キャッシュは、sqlnet.oraファイルでSQLNET.KERBEROS5_CC_NAMEパラメータを使用して指定することもできます。

-k

UNIX上のサービス表のエントリ(デフォルト/etc/v5srvtab)をリストします。代替サービス表は、sqlnet.oraファイルでSQLNET.KERBEROS5_KEYTABパラメータを使用して指定することもできます。

フラグ表示オプション(-f)によって、次のような追加情報が表示されます。

% oklist -f
27-Jul-1999 21:57:51   28-Jul-1999 05:58:14
krbtgt/EXAMPLE.COM@EXAMPLE.COM
Flags: FI

キャッシュ・ファイルからの資格証明の削除

キャッシュ・ファイルから資格証明を削除できます。

- okdstryユーティリティを使用して、資格証明キャッシュ・ファイルから資格証明を削除します。

$ okdstry -c

-cコマンド・オプションによって、代替資格証明キャッシュを指定できます。UNIXでは、デフォルトは/tmp/krb5cc_uidです。代替資格証明キャッシュは、sqlnet.oraファイルでSQLNET.KERBEROS5_CC_NAMEパラメータを使用して指定することもできます。

Kerberosによって認証されたOracleデータベース・サーバーへの接続

Kerberosの構成後は、ユーザー名やパスワードを使用しないでOracleデータベース・サーバーに接続できます。

- 次の構文を使用して、ユーザー名やパスワードを入力しないでデータベースに接続します。

$ sqlplus /@net_service_name

ここで、net_service_nameは、Oracle Net Servicesのサービス名です。例:

$ sqlplus /@oracle_dbname

関連項目:

外部認証の詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

Windows 2008ドメイン・コントローラKDCとの相互運用性の構成

Oracle DatabaseはMIT Kerberosに準拠しており、OracleデータベースでのKerberos認証を可能にするために、Windows 2008ドメイン・コントローラ上で、Kerberos Key Distribution Center (KDC)によって発行されたチケットを相互運用できます。

内容は次のとおりです。

- 手順1: Windows 2008ドメイン・コントローラのためのOracle Kerberosクライアントの構成

- 手順2: OracleクライアントのためのWindows 2008ドメイン・コントローラKDCの構成

- 手順3: Windows 2008ドメイン・コントローラKDCのためのOracleデータベースの構成

- 手順4: Kerberos/Oracleユーザーの初期チケットの取得

手順1: Windows 2008ドメイン・コントローラのためのOracle Kerberosクライアントの構成

Microsoft Windows 2008ドメイン・コントローラKDCと相互運用するようにOracle Kerberosクライアントを構成するには、次の手順を実行する必要があります。Oracle Kerberosクライアントで、次の手順を実行します。

内容は次のとおりです。

- 手順1A: クライアントKerberos構成ファイルの作成

- 手順1B: sqlnet.oraファイルでのOracle構成パラメータの指定

- 手順1C: リスニング・ポート番号の指定

手順1A: クライアントKerberos構成ファイルの作成

Windows 2008ドメイン・コントローラをKerberos KDCとして参照するKerberosクライアント構成ファイルを構成する必要があります。

- krb.conf、krb5.confおよびkrb5.realmsファイルを作成します。

たとえば、Windows 2008ドメイン・コントローラがsales3854.us.example.comという名前のノード上で実行されていることを前提とします。

- krb.confファイル
例:

SALES3854.US.EXAMPLE.COM
SALES3854.US.EXAMPLE.COM sales3854.us.example.com admin server

- krb5.confファイル
例:

[libdefaults]
default_realm=SALES.US.EXAMPLE.COM
[realms]
SALES.US.EXAMPLE.COM= { kdc=sales3854.us.example.com:88 }
[domain_realm]
.us.example.com=SALES.US.EXAMPLE.COM

- krb5.realmsファイル
例:

us.example.com SALES.US.EXAMPLE.COM

手順1B: sqlnet.oraファイルでのOracle構成パラメータの指定

sqlnet.oraファイルにはKerbose 5特有のパラメータがあります。

Windows 2008ドメイン・コントローラKDCと相互運用するようにOracleクライアントを構成するには、「手順6A: クライアントとデータベース・サーバーでのKerberosの構成」で示したものと同じsqlnet.oraファイルのパラメータを使用します。

- クライアントのsqlnet.oraファイルで次のパラメータを設定します。

SQLNET.KERBEROS5_CONF=pathname_to_Kerberos_configuration_file
SQLNET.KERBEROS5_CONF_MIT=TRUE
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=Kerberos_service_name
SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5)

注意:

Windows 2008オペレーティング・システムはMIT Kerberosバージョン5に基づくセキュリティ・サービスとのみ相互運用するように設計されているため、SQLNET.KERBEROS5_CONF_MITパラメータがTRUEに設定されていることを確認してください。

手順1C: リスニング・ポート番号の指定

Windows 2008ドメイン・コントローラKDCは、UDP/TCPポート88でリスニングします。

- kerberos5のシステム・ファイル・エントリが、UDP/TCPポート88に設定されていることを確認してください。
UNIX環境では、/etc/servicesファイルの最初のkerberos5エントリが88に設定されていることを確認してください。

手順2: OracleクライアントのためのWindows 2008ドメイン・コントローラKDCの構成

次に、Oracleクライアントと相互運用するようにWindows 2008ドメイン・コントローラKDCを構成します。Windows 2008ドメイン・コントローラで、次の手順を実行する必要があります。

内容は次のとおりです。

- 手順2A: ユーザー・アカウントの作成

- 手順2B: Oracleデータベースのプリンシパル・ユーザー・アカウントの作成

関連項目:

Active Directoryでユーザーを作成する方法の詳細は、Microsoft社のドキュメントを参照してください。

手順2A: ユーザー・アカウントの作成

Microsoft Windows 2008ドメイン・コントローラのKDCにユーザー・アカウントを作成する必要があります。

- Windows 2008ドメイン・コントローラで、Microsoft Active DirectoryにOracleクライアントの新規ユーザー・アカウントを作成します。

手順2B: Oracleデータベースのプリンシパル・ユーザー・アカウントの作成

ユーザー・アカウントの作成後、Oracle Databaseプリンシパル・ユーザー・アカウントを作成します。

ユーザー・アカウントの作成後、Oracle Databaseプリンシパル・ユーザー・アカウントを作成します。

1. Microsoft Active DirectoryでOracleデータベースの新規ユーザー・アカウントを作成します。

たとえば、Oracleデータベースがホストsales3854.us.example.comで実行されている場合は、Active Directoryを使用してユーザー名sales3854.us.example.comとパスワードoracleでユーザーを作成します。

Active Directoryでは、ユーザーをhost/hostname.dns.com (oracle/sales3854.us.example.comなど)として作成しないでください。Microsoft社のKDCは、MIT KDCのようにマルチパートの名前をサポートしていません。MIT KDCは、すべてのプリンシパルをユーザー名として扱うため、マルチパートの名前をサービス・プリンシパルに使用できます。ただし、Microsoft社のKDCでは使用できません。

2. Ktpassコマンドライン・ユーティリティを使用して、次の構文によってkeytabファイルを抽出します。

Ktpass -princ service/hostname@NT-DNS-REALM-NAME -mapuser account -pass password -out keytab.file

次に、前の手順で作成したデータベース・ユーザーを使用したKtpassの使用例を示します。

C:> Ktpass -princ oracle/sales3854.us.example.com@SALES.US.COM -mapuser sales3854 -pass oracle -out C:\temp\v5srvtab

このユーティリティはWindows 2008サポート・ツールの一部であり、\support\reskit\netmgmt\securityフォルダのWindows 2008配布媒体にあります。

3. 抽出したkeytabファイルをOracleデータベースがインストールされているホスト・コンピュータにコピーします。

たとえば、前の手順で作成したkeytabを/krb5/v5svrtabにコピーできます。

関連項目:

Windows 2008とKerberos 5の相互運用の詳細は、次のURLを参照してください。

http://technet.microsoft.com/hi-in/windowsserver/2000/bb735396(en-us).aspx

手順3: Windows 2008ドメイン・コントローラKDCのためのOracleデータベースの構成

Oracleデータベースがインストールされているホスト・コンピュータでドメイン・コントローラに対してOracleデータベースを構成する必要があります。

内容は次のとおりです。

- 手順3A: sqlnet.oraファイルでの構成パラメータの設定

- 手順3B: 外部認証されたOracleユーザーの作成

手順3A: sqlnet.oraファイルでの構成パラメータの設定

最初に、データベースの構成パラメータを設定する必要があります。

- データベース・サーバーのsqlnet.oraファイルで、次のパラメータの値を指定します。

SQLNET.KERBEROS5_CONF=pathname_to_Kerberos_configuration_file
SQLNET.KERBEROS5_KEYTAB=pathname_to_Kerberos_principal/key_table
SQLNET.KERBEROS5_CONF_MIT=TRUE
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=Kerberos_service_name
SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5)

注意:

- Windows 2008オペレーティング・システムはMIT Kerberosバージョン5に基づくセキュリティ・サービスとのみ相互運用するように設計されているため、SQLNET.KERBEROS5_CONF_MITパラメータがTRUEに設定されていることを確認してください。

- マルチテナント環境では、sqlnet.oraファイルの設定がすべてのPDBに適用されることに注意してください。

手順3B: 外部認証されたOracleユーザーの作成

構成パラメータの設定後、外部認証されるOracleユーザーを作成します。

- 手順8: 外部認証されたOracleユーザーの作成の手順に従って、外部認証されたOracleユーザーを作成します。
ユーザー名はすべて大文字で作成します(例: ORAKRB@SALES.US.EXAMPLE.COM)。

関連項目:

Oracle Net Managerを使用してsqlnet.oraファイルのパラメータを設定する方法の詳細は、手順6: Kerberos認証の構成を参照してください。

手順4: Kerberos/Oracleユーザーの初期チケットの取得

クライアントがデータベースに接続するには、初期チケットを要求する必要があります。

- 初期チケットを要求するには、手順9: Kerberos/Oracleユーザーの初期チケットの取得のタスク情報に従います。

注意:

ユーザーは、Windows固有のキャッシュを使用する場合、okinitコマンドを使用して初期チケットを明示的に要求する必要はありません。

OracleクライアントがMicrosoft Windows 2008以上で実行されている場合、KerberosチケットはユーザーがWindowsにログインしたときに自動的に取得されます。

関連項目:

システムのKerberosチケット情報を表示するために使用できるKerbtray.exeユーティリティの詳細は、Microsoft社のドキュメントを参照してください。

Kerberos認証フォールバック動作の構成

Kerberos認証の障害に備え、フォールバック動作(パスワードベースの認証)を構成できます。

OracleクライアントでKerberos認証を構成してOracleデータベースを認証した後に、パスワード・ベースの認証にフォールバックする必要が発生する場合があります。たとえば、ユーザー・データベースのリンクをOracleデータベースに固定している場合などです。

- Kerberos認証からパスワード・ベースの認証へのフォールバックを有効にするには、クライアントとサーバーの両方でsqlnet.ora内のSQLNET.FALLBACK_AUTHENTICATIONパラメータをTRUEに設定します。
このパラメータのデフォルト値はFALSEです。これは、デフォルトでは、Kerberos認証に失敗すると接続が失敗することを意味します。

関連項目:
SQLNET.FALLBACK_AUTHENTICATIONパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

Oracle Kerberos認証の構成のトラブルシューティング

一般的なKerberos構成の問題に対するガイドラインを示します。

一般的な問題は次のとおりです。

- okinitを使用してチケット認証チケットを取得できない場合:

- krb.confファイルを調べて、デフォルトのレルムが正しいことを確認します。

- レルムに対して指定されているホスト上でKDCが実行されていることを確認します。

- KDCにユーザー・プリンシパルのエントリがあること、およびパスワードが一致していることを確認します。

- krb.confファイルおよびkrb.realmsファイルがOracleによって読取り可能であることを確認します。

- TNS_ADMIN環境変数が、sqlnet.ora構成ファイルを含むディレクトリを指していることを確認します。

- 初期チケットはあるが接続できない場合:

- 接続を試みた後で、サービス・チケットを確認します。

- データベース・サーバー側のsqlnet.oraファイルに、Kerberosによって認識されるサービスに対応するサービス名があることを確認します。

- 関連するすべてのシステムでクロックのずれが数分以内に設定されていることを確認するか、sqlnet.oraファイルでSQLNET.KERBEROS5_CLOCKSKEWパラメータを変更します。

- サービス・チケットはあるが接続できない場合:

- クライアントおよびデータベース・サーバー上でクロックを確認します。

- v5srvtabファイルが正しい場所にあり、Oracleによって読取り可能であることを確認します。sqlnet.oraパラメータを忘れずに設定してください。

- データベース・サーバー側のsqlnet.oraファイルで指定されているサービスに対してv5srvtabファイルが生成されていることを確認します。

- 問題がないと考えられるにもかかわらず、発行した問合せが失敗する場合:

- 初期チケットが転送可能であることを確認します。okinitユーティリティを実行して初期チケットを取得している必要があります。

- 資格証明の有効期限を確認します。資格証明の有効期限が切れている場合は、接続をクローズし、okinitを実行して新しい初期チケットを取得します。

18 Secure Sockets Layer認証の構成

Secure Sockets Layer認証を使用するようにOracle Databaseを構成できます。

内容は次のとおりです。

- Secure Sockets LayerおよびTransport Layer Security

- Oracle環境における公開鍵インフラストラクチャ

- Secure Sockets Layerと他の認証方式の併用

- Secure Sockets Layerとファイアウォール

- Secure Sockets Layer使用時の問題

- Secure Sockets Layerの有効化

- Secure Sockets Layer構成のトラブルシューティング

- 証明書失効リストによる証明書の検証

- ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成

Secure Sockets LayerおよびTransport Layer Security

Secure Sockets Layer (SSL)は安全なネットワーク接続を目的に、Netscape社によって設計されました。

Transport Layer Security (TLS)は、Secure Sockets Layer (SSL)バージョン3.0の増分バージョンです。

SSLは最初にNetscape社によって開発されましたが、Internet Engineering Task Force (IETF)がその開発を引き継ぎ、名前をTransport Layer Security (TLS)に変更しました。

関連項目:

IETF Webサイトの次の場所にあるTLSプロトコル・バージョン1.0(RFC 2246)

http://www.ietf.org

注意:

SSLが最も広く認識されている用語であるため、SSLでもTLSでも適切な場合、この章では説明を簡単にするためにSSLという用語を使用します。ただし、これらのプロトコルの使用方法または構成方法に違いがある場合、この章では、記述内容がSSLに該当するか、TLSに該当するかを明記します。

Oracle DatabaseでのSecure Sockets Layerを使用した認証

Oracle Databaseでは、これらのプロトコルのネイティブ暗号化およびデータ整合性機能だけでなく、SSL上でデジタル証明書を使用します。

Oracle DatabaseのSSL機能を使用してクライアントとサーバー間の通信を保護すると、次の操作を実行できます。

- SSLを使用したクライアントとサーバー間の接続の暗号化

- SSL通信用に構成されたOracleデータベース・サーバーに対するクライアントまたはサーバー(Oracle Application Server 10gなど)の認証

SSL機能は、単独で使用するか、Oracle Databaseでサポートされている他の認証方式と組み合せて使用できます。たとえば、SSLから提供されている暗号化をKerberosから提供されている認証と組み合せて使用できます。SSLでは、次の認証モードがサポートされます。

- サーバーのみ、クライアントに対して自己認証を行います。

- クライアントとサーバーは、互いに自己認証を行います。

- クライアントもサーバーも、互いに自己認証を行わず、SSL暗号化機能を単独で使用します。

関連項目:

SSLの詳細は、Internet Engineering Task Forceが公開しているSSLプロトコルのバージョン3.0を参照してください。

Oracle環境におけるSecure Sockets Layerの機能: SSLハンドシェイク

Secure Sockets Layerによるネットワーク接続を開始する場合、クライアントとサーバーは、認証を行う前にSSLハンドシェイクを実行します。

ハンドシェイク・プロセスは次のようになります。

1. クライアントとサーバーは、どの暗号スイートを使用するかを設定します。これには、データ転送に使用する暗号化アルゴリズムも含まれます。

2. サーバーは証明書をクライアントに送信し、クライアントは、サーバーの証明書が信頼できるCAによって署名されていることを検証します。このステップにより、サーバーの身元が検証されます。

3. 同様に、クライアント認証が必要な場合は、クライアントが自分自身の証明書をサーバーに送信し、サーバーは、クライアントの証明書が信頼できるCAによって署名されているかどうかを検証します。

4. クライアントとサーバーが、公開鍵暗号化を使用して鍵情報を交換します。この情報に基づき、双方でセッション鍵が生成されます。クライアントとサーバーとの間の以降の通信はすべて、このセッション鍵と、ネゴシエーションにより決定した暗号スイートを使用して、暗号化または復号化されます。

認証プロセスは次のとおりです。

1. クライアントで、ユーザーがSSLを使用してサーバーへのOracle Net接続を開始します。

2. SSLは、クライアントとサーバー間のハンドシェイクを実行します。

3. ハンドシェイクが成功すると、サーバーは、そのデータベースにアクセスするために必要な認可をユーザーが所有していることを検証します。

Oracle環境における公開鍵インフラストラクチャ

公開鍵インフラストラクチャ(PKI)は、組織全体のセキュリティ基盤を提供するネットワーク・コンポーネントの基質であり、信頼アサーションに基づいています。

内容は次のとおりです。

- 公開鍵の暗号化について

- Oracle環境における公開鍵インフラストラクチャ・コンポーネント

公開鍵の暗号化について

従来の秘密鍵または対称鍵の暗号化では、通信を保護する目的で2者以上が共有する1つの秘密鍵が必要です。

この鍵は、ユーザー間で送信される保護メッセージの暗号化および復号化に使用されるため、各ユーザーへは事前に安全な方法で鍵を配布する必要があります。この方法における問題点は、鍵を安全に転送し、格納することが困難なことです。

公開鍵の暗号化による公開鍵/秘密鍵のペアおよび鍵配布のための安全な方法を採用することで、この問題は解決します。対応する秘密鍵の所有者のみが復号化できるメッセージは、自由に使用できる公開鍵によって暗号化できます。秘密鍵は、その他のセキュリティ資格証明とともに、ウォレットと呼ばれる暗号化されたコンテナに、安全に格納されます。

公開鍵のアルゴリズムでは、メッセージの秘密は保証されますが、安全な通信は必ずしも保証されません。その理由は、通信者間の識別が検証されないためです。安全な通信を確立するには、メッセージの暗号化に使用される公開鍵が相手の受信者に実際に属していることを確認することが重要です。そうしないと、第三者が通信を傍受し、公開鍵のリクエストに割り込み、正当な鍵を独自の公開鍵に置き換えることが可能になります(介在者攻撃)。

この攻撃を回避するには、公開鍵の所有者の確認(認証と呼ばれるプロセス)が必要です。認証は、通信する双方の委託するサード・パーティの認証局(CA)によって行われます。

CAは、エンティティの名前、公開鍵および他のセキュリティ資格証明を含む公開鍵証明書を発行します。通常、このような資格証明には、CA名、CAの署名および証明書の有効日(開始日、終了日)が含まれています。

CAでは独自の秘密鍵を使用してメッセージを暗号化します。一方、そのメッセージの復号化には公開鍵が使用されるため、メッセージがCAによって暗号化されたものであるかどうかが確認されます。CA公開鍵は広く一般に知られているため、アクセスするたびに認証する必要はありません。このようなCA公開鍵はウォレットに格納されます。

Oracle環境における公開鍵インフラストラクチャ・コンポーネント

Oracle環境の公開鍵インフラストラクチャ(PKI)のコンポーネントには、認証局、証明書、証明書失効リストおよびウォレットなどがあります。

内容は次のとおりです。

- 認証局

- 証明書

- 証明書失効リスト

- ウォレット

- ハードウェア・セキュリティ・モジュール

認証局

認証局(CA)は、ユーザー、データベース、管理者、クライアント、サーバーなどのエンティティの識別情報を証明する、信頼できるサード・パーティです。

エンティティが証明書を要求すると、CAはその識別情報を検証し、CAの秘密鍵を使用して署名した証明書を発行します。

CAごとに、証明書の発行時の識別情報要件が異なる可能性があります。CAの中には、要求者の識別情報をドライバのライセンスを使用して確認したり、要求者の指紋で識別情報を確認したり、証明書リクエスト・フォームが認証されていることを必要とするものがあります。

CAは、公開鍵が含まれている独自の証明書を発行します。各ネットワーク・エンティティには、信頼できるCA証明書のリストがあります。通信する前に、ネットワーク・エンティティは証明書を交換し、相互の証明書がそれぞれの信頼できるCA証明書リストのいずれかのCAによって署名されていることを確認します。

ネットワーク・エンティティは、同じCAから、または異なるCAから証明書を取得できます。デフォルトでは、Oracle Databaseは、新規ウォレットの作成時にVeriSign社、RSA社、Entrust社およびGTE CyberTrust社から信頼できる証明書を自動的にインストールします。

関連項目:

ウォレット

証明書

証明書は、エンティティの公開鍵が、信頼できる認証局(CA)によって署名されたときに作成されます。

この証明書は、そのエンティティの識別情報が正しいこと、および公開鍵がそのエンティティに実際に属していることを保証します。

証明書には、エンティティの名前、公開鍵、有効期限、さらにシリアル番号および証明連鎖情報が含まれています。また、証明書に関連付けられた権限に関する情報が含まれている場合もあります。

ネットワーク・エンティティが証明書を受信すると、それが信頼できる証明書、つまり信頼できる認証局によって発行および署名された証明書であるか検証します。証明書は、期限切れになるか失効するまで有効です。

証明書失効リスト

公開鍵ペアをユーザーIDにバインドする証明書にCAが署名すると、証明書は指定された期間有効になります。

ただし、ユーザー名の変更や秘密鍵の漏えいなどの特定のイベントが発生した場合は、有効期間が終了する前に証明書が無効になることがあります。この場合は、CAによって証明書が失効され、そのシリアル番号が証明書失効リスト(CRL)に追加されます。CAは、特定の公開鍵が、関連付けられているユーザーIDの確認に使用できなくなると、定期的にCRLを発行してユーザーに警告します。

サーバーまたはクライアントはOracle環境でユーザー証明書を受信すると、その有効期限、署名および失効ステータスをチェックして証明書を検証できます。証明書失効ステータスは、発行されたCRLに照らして検証することでチェックされます。証明書失効ステータス・チェックが有効になっている場合、サーバーはこの機能の構成方法に応じて適切なCRLを検索します。サーバーは、次の場所で(この順番で) CRLを検索します。

1. ローカル・ファイル・システム

2. Oracle Internet Directory

3. CRL配布ポイント。証明書が発行されたときの、CRL Distribution Point (CRL DP)X.509バージョン3の証明書拡張で指定されている場所。

注意:

他のOracle製品でCRLを使用するには、その製品のドキュメントを参照してください。CRLによる証明書の検証の実装は、Oracle Database 12c リリース1 (12.1)のSSLアダプタでのみ使用できます。

関連項目:

このPKIコンポーネントの構成および管理の詳細は、証明書失効リストによる証明書の検証を参照してください

ウォレット

ウォレットは、認証および署名資格証明(SSLで必要な秘密鍵、証明書、信頼できる証明書など)の格納に使用されるコンテナです。

Oracle環境では、SSL通信を行うどのエンティティにも、X.509バージョン3の証明書、秘密鍵および信頼できる証明書のリストが必要です。ただし、Diffie-Hellmanは例外です。

セキュリティ管理者は、サーバーのセキュリティ資格証明の管理にOracle Wallet Managerを使用します。ウォレットの所有者は、クライアントのセキュリティ資格証明の管理に使用します。具体的には、Oracle Wallet Managerは次のことを行うために使用します。

- 公開鍵と秘密鍵のペアの生成および証明書リクエストの作成

- 秘密鍵と一致するユーザー証明書の格納

- 信頼できる証明書の構成

関連項目:

- Oracle Wallet Managerの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- Oracleウォレットの新規作成の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- Oracleウォレットでの信頼できる証明書の管理の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

ハードウェア・セキュリティ・モジュール

SSLのハードウェア・セキュリティ・モジュールには、様々な機能を処理するデバイスや、暗号情報を格納するハードウェア・デバイスなどがあります。

Oracle Databaseでは、これらのデバイスを次の機能に使用します。

- 秘密鍵などの暗号情報の格納

- 他のトランザクションに応答できるようにCPUを解放して、サーバーにおけるRSA操作の負荷を軽減する暗号操作の実行

暗号情報は、次の2つのタイプのハードウェア・デバイスに格納できます。

- (サーバー側)鍵がボックスに格納され、トークンを使用して管理されるハードウェア・ボックス。

- (クライアント側)トークンへの秘密鍵の格納をサポートするスマートカード・リーダー

Oracle環境では、RSA Security社の公開鍵暗号規格(PKCS)#11仕様に準拠しているAPIを使用したハードウェア・デバイスがサポートされています。

注意:

現在、SafeNETおよびnCipherデバイスがOracle Databaseで認定されています。

関連項目:

構成の詳細は、ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成を参照してください。

Secure Sockets Layerと他の認証方式の併用

Secure Sockets Layer (SSL)をデータベースのユーザー名とパスワード、RADIUSおよびKerberosと同時に使用するようにOracle Databaseを構成できます。

内容は次のとおりです。

- アーキテクチャ: Oracle DatabaseとSecure Sockets Layer

- Secure Sockets Layerと他の認証方式の併用

関連項目:

複数の認証方式が指定されたsqlnet.oraファイルなど、サポートされている他の認証方式によるSSLの構成方法の詳細は、データ暗号化および整合性パラメータを参照してください。

アーキテクチャ: Oracle DatabaseとSecure Sockets Layer

Oracle DatabaseとSSLとの連携のアーキテクチャを理解することが重要です。

Secure Sockets LayerアーキテクチャのOracle Databaseの実装を示す図15-4では、Oracle DatabaseがSSLの上位のセッション・レイヤーで動作し、トランスポート・レイヤーでTCP/IPを使用していることを示しています。

このように機能が分離されているため、SSLを他のサポートされているプロトコルと同時に利用できます。

関連項目:

Oracleネットワーキング環境におけるスタック通信の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

Secure Sockets Layerと他の認証方式の併用

Secure Sockets Layerは、Oracle Databaseでサポートされているその他の認証方式との併用が可能です。

図18-1は、Secure Sockets Layerが別の認証方式と併用されている構成を示しています。

図18-1 Secure Sockets Layerと他の認証方式との関係

この例では、最初のハンドシェイク(サーバー認証)を確立するためにSecure Sockets Layerが使用され、クライアントの認証に別の認証方式が使用されています。このプロセスは、次のとおりです。

1. クライアントがOracleデータベース・サーバーに接続しようとします。

2. Secure Sockets Layerによってハンドシェイクが実行され、その間にサーバーがクライアントに対して自己認証を行い、クライアントとサーバーの両方が使用する暗号スイートを設定します。

3. Secure Sockets Layerハンドシェイクが正常に完了すると、ユーザーはデータベースにアクセスしようとします。

4. Oracleデータベース・サーバーは、KerberosやRADIUSなどの非SSL認証方式を使用して、認証サーバーでユーザーを認証します。

5. 認証サーバーによる検証が完了すると、Oracleデータベース・サーバーによってアクセス権と認可がユーザーに付与され、ユーザーはSSLを使用してデータベースに安全にアクセスできるようになります。

関連項目:

Oracle環境におけるSecure Sockets Layerの機能: SSLハンドシェイク

Secure Sockets Layerとファイアウォール

Oracle Databaseは、アプリケーション・プロキシベースのファイアウォールとステートフル・パケット・インスペクション・ファイアウォールの2つをサポートしています。

ファイアウォールは次のとおりです。

- アプリケーション・プロキシベースのファイアウォール: Network Associates GauntletやAxent Raptorなど。

- ステートフル・パケット・インスペクション・ファイアウォール: Check Point Firewall-1やCisco PIX Firewallなど。

SSLを有効にした場合、ステートフル・インスペクション・ファイアウォールは暗号化されたパケットを復号化しないため、アプリケーション・プロキシ・ファイアウォールと同じように動作します。

ファイアウォールは暗号化されたトラフィックを検査しません。ファイアウォールは、イントラネット・サーバーのSSLポート宛てのデータを検出すると、アクセス・ルールに基づいてターゲットIPアドレスを確認し、許可されたSSLポートに対してはSSLパケットを通過させ、他のすべてのパケットは拒否します。

いくつかのファイアウォール・ベンダーが提供しているOracle Net Firewall Proxyキットを使用すると、ファイアウォール・アプリケーションでデータベース・ネットワーク・トラフィックがサポートされます。プロキシ・キットをファイアウォールに実装すると、次の処理が実行されます。

- Net Proxy (Oracle Net Firewall Proxyキットのコンポーネント)によってトラフィックのルーティング先が決定されます。

- データベース・リスナーは、SSLハンドシェイクに参加するために、証明書 へのアクセスを要求します。リスナーはSSLパケットを検査し、ターゲット・データベースを識別して、ターゲット・データベースがクライアントのリスニングに使用しているポートを戻します。このポートは、SSLポートとして指定されている必要があります。

- クライアントは、以降のすべての接続でこのサーバー指定ポートを使用して通信します。

Secure Sockets Layer使用時の問題

他のOracle製品との通信や、サポート対象の認証方式および暗号化方式のタイプといった、SSLの使用に関する問題に注意する必要があります。

SSLを使用する場合は、次のことを考慮してください。

- SSLを使用すると、Oracle Internet Directoryなどの他のOracle製品との安全な通信が可能になります。

- SSLでは認証と暗号化の両方がサポートされているため、クライアント/サーバー接続が標準のOracle Net TCP/IPトランスポート(ネイティブ暗号化を使用)より多少遅くなります。

- 各SSL認証モードには、構成設定が必要となります。

- マルチスレッド・クライアントでは、現在SSLを使用できません。

注意:

SSL暗号化を構成する場合は、非SSL暗号化を無効にする必要があります。このような暗号化を無効にするには、「厳密認証およびネットワーク暗号化の無効化」を参照してください。

関連項目:

- ハードウェア・アクセラレータでSSLパフォーマンスを改善する方法の詳細は、ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成を参照してください

- Secure Sockets Layerの有効化

Secure Sockets Layerの有効化

Secure Sockets Layerは、サーバーで構成してから、クライアントで構成する必要があります。

内容は次のとおりです。

- 手順1: サーバーでのSecure Sockets Layerの構成

- 手順2: クライアントでのSecure Sockets Layerの構成

- 手順3: データベース・インスタンスへのログイン

手順1: サーバーでのSecure Sockets Layerの構成

インストール中、Oracleデータベース・サーバーとOracleクライアントに、Oracleウォレットの場所を除くSSLパラメータのデフォルトが設定されます。

手順1A: サーバーでのウォレット作成の確認

次の手順に進む前に、ウォレットが作成されていることと、ウォレットに証明書があることを確認する必要があります。

1. Oracle Wallet Managerを起動します。

- (UNIXの場合) $ORACLE_HOME/binから、次のコマンドを入力します。

owm

- (Windowsの場合)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Integrated Management Tools」→「Wallet Manager」の順に選択します。

2. 「ウォレット」メニューから「オープン」を選択します。

ウォレットにステータスがReadyの証明書が含まれ、自動ログインがオンになっている必要があります。自動ログインがオンになっていない場合は、「ウォレット」メニューから選択し、ウォレットを再度保存します。自動ログインがオンになります。

関連項目:
Oracleウォレットの新規作成の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

手順1B: サーバーでのデータベース・ウォレット・ロケーションの指定

次に、ウォレットのサーバー上の場所を指定します。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。

ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「SSL」タブを選択し、「SSL構成: サーバー」を選択します。

5. 「ウォレット・ディレクトリ」ボックスで、Oracleウォレットが配置されているディレクトリを入力するか、「参照」をクリックし、ファイル・システムを検索してディレクトリを探します。

エンタープライズ・ユーザー・セキュリティ用にデータベースとディレクトリ間のSSL接続を構成する場合は、Database Configuration Assistantによって自動的にデータベース・ウォレットが作成され、データベースがディレクトリに登録されます。そのウォレットを使用して、SSLで認証されたエンタープライズ・ユーザー・セキュリティのデータベースPKI資格証明を格納する必要があります。

重要:

- Oracle Wallet Managerを使用してウォレットを作成します。Oracleウォレットの新規作成の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- Oracle Net Managerを使用して、sqlnet.oraファイルにウォレット・ロケーションを設定します。マルチテナント環境では、sqlnet.oraファイルの設定はすべてのプラガブル・データベース(PDB)に適用されることに注意してください。

ウォレットを作成したとき、およびsqlnet.oraファイルに場所を設定したときと同じ場所を入力してください。

6. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。

sqlnet.oraファイルとlistener.oraファイルが次のエントリで更新されます。

wallet_location =
(SOURCE=
(METHOD=File)
(METHOD_DATA=
(DIRECTORY=wallet_location)))

注意:

リスナーでは、listener.oraファイルに定義されているウォレットを使用します。任意のデータベース・ウォレットを使用できます。Net Managerを使用してサーバーのSSLが構成されている場合、ウォレット・ロケーションはlistener.oraファイルとsqlnet.oraファイルに入力されています。listener.oraファイルは、Oracleクライアントには関係ありません。

リスナーが独自のウォレットを所有するようにリスナーのウォレット・ロケーションを変更するには、listener.oraを編集して新しい場所を入力します。

手順1C: サーバーでのSecure Sockets Layer暗号スイートの設定(オプション)

オプションで、Secure Sockets Layer暗号スイートを設定できます。

内容は次のとおりです。

- Secure Sockets Layer暗号スイートについて

- SSL暗号スイートの認証、暗号化、整合性およびTLSバージョン

- データベース・サーバーのSecure Sockets暗号スイートの指定

Secure Sockets Layer暗号スイートについて

暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。

Secure Sockets Layerハンドシェイク時に、2つのエンティティがネゴシエートし、メッセージを送受信するときに使用する暗号スイートを確認します。

Oracle Databaseをインストールすると、表18-1のSecure Sockets Layer暗号スイートがデフォルトで設定され、リスト順にネゴシエートされます。デフォルトの順序は、SSL_CIPHER_SUITESパラメータを設定して上書きできます。

暗号スイートの優先順位を設定できます。クライアントが使用する暗号スイートに関してサーバーとネゴシエートする場合、設定されている優先順位に従います。暗号スイートの優先順位を設定する場合は、次の点を考慮してください。

- 互換性。正常に接続するには、互換性のある暗号スイートを使用するようにサーバーとクライアントを構成する必要があります。

- 暗号の優先順位と強度。最高レベルのセキュリティを確保するために、最も強力なものから最も弱いものの順に暗号スイートの優先順位を設定します。

- 使用するセキュリティ・レベル。

- パフォーマンスへの影響。

注意:

Diffie-Hellman 匿名認証について:

- この暗号スイートを使用するようにサーバーを設定する場合は、同じ暗号スイートをクライアントにも設定する必要があります。設定しない場合、接続に失敗します。

- Diffie-Hellman匿名を使用する暗号スイートを使用する場合、SSL_CLIENT_AUTHENTICATIONパラメータをFALSEに設定する必要があります。詳細は、手順1E: サーバーでのSSLクライアント認証の設定(オプション)を参照してください。

- 既知の不具合があり、クライアントを認証しないDH_ANONを含む暗号スイートを使用する場合でも、OCIクライアントでウォレットが必要です。

SSL暗号スイートの認証、暗号化、整合性およびTLSバージョン

Oracle Databaseでは、Oracle Databaseをインストールするとデフォルトで設定される一連の暗号スイートがサポートされています。

表18-1に、各暗号スイートで使用される認証、暗号化およびデータ整合性のタイプを示します。

表18-1 Secure Sockets Layer暗号スイート

暗号スイート

認証

暗号化

データ整合性

TLSの互換性

SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

ECDHE_ECDSA

AES 128 GCM

SHA256 (SHA-2)

TLS 1.2のみ

SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

ECDHE_ECDSA

AES 128 CBC

SHA-1

TLS 1.0以降

SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

ECDHE_ECDSA

AES 128 CBC

SHA256 (SHA-2)

TLS 1.2のみ

SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

ECDHE_ECDSA

AES 256 CBC

SHA-1

TLS 1.0以降

SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

ECDHE_ECDSA

AES 256 CBC

SHA384 (SHA-2)

TLS 1.2のみ

SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

ECDHE_ECDSA

AES 256 GCM

SHA384 (SHA-2)

TLS 1.2のみ

SSL_RSA_WITH_AES_128_CBC_SHA256

RSA

AES 128 CBC

SHA256 (SHA-2)

TLS 1.2のみ

SSL_RSA_WITH_AES_128_GCM_SHA256

RSA

AES 128 GCM

SHA256 (SHA-2)

TLS 1.2のみ

SSL_RSA_WITH_AES_128_CBC_SHA

RSA

AES 128 CBC

SHA-1

TLS 1.0のみ

SSL_RSA_WITH_AES_256_CBC_SHA

RSA

AES 256 CBC

SHA-1

TLS 1.0以降

SSL_RSA_WITH_AES_256_CBC_SHA256

RSA

AES 256 CBC

SHA256 (SHA-2)

TLS 1.2のみ

SSL_RSA_WITH_AES_256_GCM_SHA384

RSA

AES 256 GCM

SHA384 (SHA-2)

TLS 1.2のみ

表18-2に、使用可能な暗号スイートを示しますが、これらは通信者の認証を提供しないため、介在者攻撃に対して無防備になる可能性があることに注意してください。機密データを保護する場合は、これらの暗号スイートを使用しないことをお薦めします。ただし、これらは、通信者が匿名を維持する場合や、相互認証によって発生するオーバーヘッドを望まない場合に有効です。

表18-2 SSL_DH Secure Sockets Layer暗号スイート

暗号スイート

認証

暗号化

データ整合性

TLSの互換性

SSL_DH_anon_WITH_3DES_EDE_CBC_SHA

DH anon

3DES EDE CBC

SHA-1

TLS 3.0以降

データベース・サーバーのSecure Sockets暗号スイートの指定

最初に、データベース・サーバーのSecure Sockets暗号スイートを指定する必要があります。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。

ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「SSL」タブを選択し、「SSL構成: サーバー」を選択します。

5. 「暗号スイートの構成」領域で、「追加」をクリックします。

使用可能な暗号スイートがダイアログ・ボックスに表示されます。米国内用の暗号スイートを表示するには、米国内用の暗号スイートの表示チェック・ボックスをクリックします。

6. スイートを選択し、「OK」をクリックします。

「暗号スイートの構成」リストが更新されます。

7. 上矢印と下矢印を使用して、暗号スイートの優先順位を設定します。

8. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。

sqlnet.oraファイルが次のエントリで更新されます。

SSL_CIPHER_SUITES= (SSL_cipher_suite1 [,SSL_cipher_suite2])

手順1D: サーバーでの必要なSecure Sockets Layerバージョンの設定(オプション)

SSL_VERSIONパラメータでは、サーバーが通信するシステムで実行する必要があるSSLのバージョンを定義します。

オプションで、sqlnet.oraファイルまたはlistener.oraファイルでSSL_VERSIONパラメータを設定できます。

これらのシステムで有効なバージョンを使用するように設定できます。sqlnet.oraにおけるこのパラメータのデフォルト設定はundeterminedで、これは、「ネットワーク・セキュリティ」ウィンドウの「SSL」タブのリストから「任意」を選択すると設定されます。

1. 「必要なSSLバージョン」リストのデフォルトは「任意」です。

このデフォルトを受け入れるか、使用するSSLバージョンを選択します。

2. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。

「任意」を選択した場合は、sqlnet.oraファイルが次のエントリで更新されます。

SSL_VERSION=UNDETERMINED

注意:

SSL 2.0はサーバー側でサポートされていません。

関連項目:

SSL_VERSIONパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

手順1E: サーバーでのSSLクライアント認証の設定(オプション)

SSL_CLIENT_AUTHENTICATIONパラメータは、クライアントがSSLを使用して認証されるかどうかを制御します。

このパラメータはサーバーのsqlnet.oraファイルで設定する必要があります。SSL_CLIENT_AUTHENTICATIONパラメータのデフォルト値はTRUEです。

Diffie-Hellman匿名認証(DH_anon)を含む暗号スイートを使用する場合は、SSL_CLIENT_AUTHENTICATIONをFALSEに設定できます。

また、KerberosやRADIUSなどのOracle Databaseでサポートされている非SSL認証方式を使用してクライアントがサーバーに対して自己認証を行うようにする場合も、このパラメータをFALSEに設定できます。

注意:

既知の不具合があり、クライアントを認証しないDH_ANONを含む暗号スイートを使用する場合でも、OCIクライアントでウォレットが必要です。

サーバーでSSL_CLIENT_AUTHENTICATIONをFALSEに設定する手順:

1. Oracle Net Managerの「SSL」ページで、「クライアントの認証が必要」の選択を解除します。

2. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。

sqlnet.oraファイルが次のエントリで更新されます。

SSL_CLIENT_AUTHENTICATION=FALSE

手順1F: サーバーでの認証サービスとしてのSSLの設定(オプション)

sqlnet.oraファイルのSQLNET.AUTHENTICATION_SERVICESパラメータでは、SSL認証サービスを設定します。

このパラメータは、SSL認証とOracle Databaseでサポートされている別の認証方式を組み合せて使用する場合に設定します。たとえば、サーバーがSSLを使用してクライアントに対して自己認証を行い、クライアントがKerberosを使用してサーバーに対して自己認証を行う場合に、このパラメータを使用します。

- サーバーでSQLNET.AUTHENTICATION_SERVICESパラメータを設定するには、テキスト・エディタを使用して、sqlnet.oraファイルのこのパラメータにSSL (TCPS)付きTCP/IPを追加します。たとえば、SSL認証とRADIUS認証を組み合せて使用する場合は、このパラメータを次のように設定します。

SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)

SSL認証と別の認証方式を組み合せて使用しない場合は、このパラメータを設定しません。

手順1G: SSL付きTCP/IPを使用するリスニング・エンドポイントのサーバーでの作成

SSL付きTCP/IPを使用するリスニング・エンドポイントをサーバーで構成できます。

- listener.oraファイルでリスナーを構成します。一般的なOracle Netクライアントには、ポート番号2484を使用することをお薦めします

関連項目:
listener.oraファイルの構成方法の詳細は、Oracle Database Net Servicesリファレンスを参照してください

手順2: クライアントでのSecure Sockets Layerの構成

SSLをクライアントで構成する場合、サーバーDNを構成して、SSL付きTCP/IPをクライアントで使用します。

手順2A: クライアント・ウォレット作成の確認

クライアントでウォレットが作成されていることと、クライアントに有効な証明書があることを確認する必要があります。

- Oracle Wallet Managerを使用して、ウォレットが作成されていることを確認します。ウォレットの確認の詳細は、「手順1A: サーバーでのウォレット作成の確認」を参照してください。

注意:

Oracle Wallet Managerを使用して、各認証局に関連付けられたOracleウォレット内の使用していない信頼できる証明書を削除することをお薦めします。

関連項目:

- ウォレットの一般情報は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- 既存のウォレットを開く方法の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- ウォレットの新規作成の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

手順2B: サーバーDNの構成とクライアントのSSL付きTCP/IPの使用

次に、サーバーDNを構成し、クライアントでSSL付きのTCP/IPを使用します。

内容は次のとおりです。

- サーバーDNSの構成およびクライアントでのSSL付きTCP/IPの使用について

- サーバーDNSの構成およびクライアントでのSSL付きTCP/IPの使用

サーバーDNSの構成およびクライアントでのSSL付きTCP/IPの使用について

サーバーDNを含み、クライアントでSSL付きのTCP/IPを使用するようにOracle Net Service名を構成できます。

これを実行するには、クライアント・ネットワーク構成ファイルで、サーバーDNマッチングおよびTCP/IPをSSL接続できるように、プロトコルとしてサーバーの識別名(DN)とTCPSを指定する必要があります。サーバーDNマッチングでは、サーバー証明書からDNに対してサーバーのグローバル・データベース名をマッチングすることで、データベース・サーバーが接続時にクライアントに対するIDの偽装が防止されます。

クライアント・ネットワーク構成ファイルのtnsnames.oraおよびlistener.oraを手動で編集して、サーバーのDNとTCP/IPをSSLプロトコルに指定する必要があります。tnsnames.oraファイルは、クライアントまたはLDAPディレクトリに配置できます。サーバーに配置される場合は、通常、listener.oraファイルと同じディレクトリに存在します。オペレーティング・システムに応じて、これらのファイルは次のディレクトリにあります。

- (UNIXの場合) $ORACLE_HOME/network/admin/

- (Windowsの場合) ORACLE_BASE\ORACLE_HOME\network\admin\

サーバーDNSの構成およびクライアントでのSSL付きTCP/IPの使用

サーバーDNSを構成し、クライアントでSSL付きのTCP/IPを使用するようにtnsnames.oraファイルとlistener.oraファイルを編集する必要があります。

1. クライアントのtnsnames.oraファイルにSSL_SERVER_CERT_DNパラメータを追加して、データベース・サーバーのDNを次のように指定します。

(SECURITY=
(SSL_SERVER_CERT_DN="cn=finance,cn=OracleContext,c=us,o=acme"))

クライアントは、この情報を使用して、各サーバーに予定しているDNのリストを取得して、サーバーのDNとそのサービス名が確実に一致するようにします。次の例では、tnsnames.oraファイルでのFinanceデータベースのエントリを示しています。

finance=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS= (PROTOCOL = tcps) (HOST = finance_server) (PORT = 1575)))
(CONNECT_DATA=
(SERVICE_NAME= Finance.us.example.com))
(SECURITY=
(SSL_SERVER_CERT_DN="cn=finance,cn=OracleContext,c=us,o=acme"))

デフォルトで、tnsnames.oraは$ORACLE_HOME/network/adminディレクトリ(UNIXシステムの場合)またはORACLE_HOME\network\admin(Windowsの場合)にあります。

または、サーバーのDNの共通名(CN)部分がサービス名と一致していることを確認できます。

2. クライアントのtnsnames.oraファイルに、ADDRESSパラメータのPROTOCOLとしてtcpsと入力します。

この指定により、クライアントはSSL付きTCP/IPを使用して、SERVICE_NAMEパラメータに指定されたデータベースに接続します。次に、tnsnames.oraファイル内の接続プロトコルとしてSSL付きTCP/IPを指定するエントリも示します。

LISTENER=
(DESCRIPTION_LIST=
(DESCRIPTION=
(ADDRESS= (PROTOCOL = tcps) (HOST = finance_server) (PORT = 1575))))

3. listener.oraファイルに、ADDRESSパラメータのPROTOCOLとしてtcpsと入力します。

手順2C: 必要なクライアントSSL構成の指定(ウォレット・ロケーション)

Oracle Net Managerを使用して、必要なクライアントSSL構成を指定できます。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。

ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「SSL」タブを選択します。

5. 「SSL構成: クライアント」を選択します。

6. 「ウォレット・ディレクトリ」ボックスで、Oracleウォレットが配置されているディレクトリを入力するか、「参照」をクリックし、ファイル・システムを検索してディレクトリを探します。

7. 「サーバーX.509の名前に一致」リストから、次のいずれかのオプションを選択します。

- はい: サーバーの識別名(DN)がそのサービス名と一致している必要があります。SSLによって証明書がサーバーからのものであることが確認され、一致した場合は接続が成功します。
このチェックは、デフォルト設定であるRSA暗号が選択されている場合にのみ実行できます。

- いいえ(デフォルト): SSLによってDNとサービス名が一致するかどうかが確認されますが、強制はされません。結果に関係なく接続は成功しますが、一致しない場合はエラーが記録されます。

- クライアントで決定: デフォルトを有効にします。
「いいえ」を選択すると、次のアラートが表示されます。

Security Alert
Not enforcing the server X.509 name match allows a server to potentially fake its identity. Oracle recommends selecting YES for this option so that connections are refused when there is a mismatch.

8. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。

クライアントのsqlnet.oraファイルが次のエントリで更新されます。

SSL_CLIENT_AUTHENTICATION =TRUE
wallet_location =
(SOURCE=
(METHOD=File)
(METHOD_DATA=
(DIRECTORY=wallet_location)))

SSL_SERVER_DN_MATCH=(ON/OFF)

関連項目:

サーバー照合パラメータの詳細は、次を参照してください。

- Secure Sockets Layer X.509サーバー照合パラメータ

Oracle Net Managerを使用してSSL付きTCP/IPを構成する方法の詳細は、次を参照してください。

- Oracle Database Net Services管理者ガイド

- 『Oracle Database Net Servicesリファレンス・ガイド』

手順2D: クライアントのSecure Sockets Layer暗号スイートの設定(オプション)

オプションで、SSL暗号スイートを設定できます。Oracle Databaseには、変更可能なデフォルトの暗号スイート設定が用意されています。

内容は次のとおりです。

- クライアントのSecure Sockets Layer暗号スイートの設定について

- クライアントのSecure Sockets Layer暗号スイートの設定

クライアントのSecure Sockets Layer暗号スイートの設定について

暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。

SSLハンドシェイク時に、2つのエンティティがネゴシエートし、メッセージを送受信するときに使用する暗号スイートを確認します。

Oracle Databaseをインストールすると、表18-1のSSL暗号スイートがデフォルトで設定されます。2つのエンティティが接続をネゴシエートするときに、この表のリスト順で暗号スイートが試行されます。デフォルトは、SSL_CIPHER_SUITESパラメータを設定して上書きできます。たとえば、Oracle Net Managerを使用して暗号スイートSSL_RSA_WITH_RC4_128_SHAを追加する場合、デフォルト設定の他のすべての暗号スイートは無視されます。

暗号スイートの優先順位を設定できます。クライアントが使用する暗号スイートに関してサーバーとネゴシエートする場合、設定されている優先順位に従います。暗号スイートの優先順位を設定する場合は、次の点を考慮してください。

- 使用するセキュリティ・レベル。たとえば、Triple-DES暗号化は、DESよりも強力です。

- パフォーマンスへの影響。たとえば、Triple-DES暗号化は、DESよりも低速です。Oracle DatabaseでSSLハードウェア・アクセラレータを使用する方法の詳細は、「ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成」を参照してください。

- 管理要件。クライアントに対して選択された暗号スイートは、サーバーに必要な暗号スイートと互換性がある必要があります。たとえば、Oracle Call Interface (OCI)ユーザーの場合、サーバーはクライアントに自己認証を求めます。この場合、証明書の交換を許可しないDiffie-Hellman匿名認証を利用する暗号スイートは使用できません。

通常、暗号スイートは最も強力なものから弱いものの順に優先順位を設定します。

表18-1に、現在サポートされているSecure Sockets Layer暗号スイートを示します。これらの暗号スイートは、Oracle Databaseをインストールするとデフォルトで設定されます。表では、各暗号スイートで使用される認証、暗号化およびデータ整合性のタイプも示されています。

注意:

sqlnet.oraファイルでSSL_CLIENT_AUTHENTICATIONパラメータをtrueに設定する場合は、Diffie-Hellman匿名認証を使用するすべての暗号スイートを無効にします。設定しない場合、接続に失敗します。

クライアントのSecure Sockets Layer暗号スイートの設定

Oracle Net Managerを使用して、クライアントSSL暗号スイートを設定できます。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。

ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「SSL」タブを選択します。

5. 「暗号スイートの構成」領域で、「追加」をクリックします。

使用可能な暗号スイートがダイアログ・ボックスに表示されます。

6. スイートを選択し、「OK」をクリックします。

次に示すように、「暗号スイートの構成」リストが更新されます。

7. 上矢印と下矢印を使用して、暗号スイートの優先順位を設定します。

8. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。

sqlnet.oraファイルが次のエントリで更新されます。

SSL_CIPHER_SUITES= (SSL_cipher_suite1 [,SSL_cipher_suite2])

手順2E: 必要なSSLバージョンのクライアントでの設定(オプション)

SSL_VERSIONパラメータでは、クライアントが通信するシステムで実行する必要があるSSLのバージョンを定義します。

sqlnet.oraファイルでSSL_VERSIONパラメータを設定する必要があります。これらのシステムで有効なバージョンを使用するように設定できます。

sqlnet.oraにおけるこのパラメータのデフォルト設定はundeterminedで、これは、「ネットワーク・セキュリティ」ウィンドウの「SSL」タブのリストから「任意」を選択すると設定されます。「任意」を選択すると、TLS 1.0が最初に試行され、その後、SSL 3.0、SSL 2.0の順に試行されます。クライアントのSSLバージョンがサーバーで使用されているバージョンと互換性があることを確認します。

1. 「必要なSSLバージョン」リストで、構成するSSLバージョンを選択します。

デフォルトの設定は「任意」です。

2. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。

sqlnet.oraファイルが更新されます。「任意」を選択した場合は、次のエントリで更新されます。

SSL_VERSION=UNDETERMINED

手順2F: クライアントにおける認証サービスとしてのSSLの設定(オプション)

sqlnet.oraファイルのSQLNET.AUTHENTICATION_SERVICESパラメータでは、SSL認証サービスを設定します。

- SQLNET.AUTHENTICATION_SERVICESパラメータについて

- SQLNET.AUTHENTICATION_SERVICESパラメータの設定

SQLNET.AUTHENTICATION_SERVICESパラメータについて

SQLNET.AUTHENTICATION_SERVICESパラメータは、SSL認証とOracle Databaseでサポートされている別の認証方式の併用を可能にします。

たとえば、サーバーがSSLを使用してクライアントに対して自己認証を行い、クライアントがRADIUSを使用してサーバーに対して自己認証を行う場合に、このパラメータを使用します。

SQLNET.AUTHENTICATION_SERVICESパラメータを設定するには、sqlnet.oraファイル(他のネットワーク構成ファイルと同じディレクトリにあります)を編集する必要があります。

プラットフォームに応じて、sqlnet.oraファイルは次のディレクトリにあります。

- (UNIXの場合) $ORACLE_HOME/network/admin

- (Windowsの場合) ORACLE_BASE\ORACLE_HOME\network\admin\

SQLNET.AUTHENTICATION_SERVICESパラメータの設定

sqlnet.oraファイルでSQLNET.AUTHENTICATION_SERVICESパラメータを設定できます。

- クライアントのSQLNET.AUTHENTICATION_SERVICESパラメータを設定するには、テキスト・エディタを使用して、sqlnet.oraファイルのこのパラメータにSSL付きTCP/IP (TCPS)を追加します。
たとえば、SSL認証とRADIUS認証を組み合せて使用する場合は、このパラメータを次のように設定します。

SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)

SSL認証と別の認証方式を組み合せて使用しない場合は、このパラメータを設定しません。

手順2G: クライアントでの認証に使用する証明書の指定(オプション)

sqlnet.oraファイルのSQLNET.SSL_EXTENDED_KEY_USAGEパラメータは、データベース・サーバー認証時に使用する証明書を指定します。

内容は次のとおりです。

- SQLNET.SSL_EXTENDED_KEY_USAGEパラメータについて

- SQLNET.SSL_EXTENDED_KEY_USAGEパラメータの設定

SQLNET.SSL_EXTENDED_KEY_USAGEパラメータについて

sqlnet.oraファイルのSQLNET.SSL_EXTENDED_KEY_USAGEパラメータは、データベース・サーバー認証時に使用する証明書を指定します

セキュリティ・モジュールに複数の証明書があるが、1つの証明書のみにクライアント認証の拡張鍵使用方法フィールドがあり、その証明書がまさに、データベースの認証に使用する証明書である場合、SQLNET.SSL_EXTENDED_KEY_USAGEパラメータを設定します。

たとえば、スマートカードに複数の証明書があり、そのうちの1つのみにclient authenticationの拡張鍵使用方法フィールドがあり、その証明書Cをデータベースの認証に使用する場合、このパラメータを設定します。Windowsクライアントでこのパラメータをclient authenticationに設定すると、MSCAPI証明書の選択ボックスが表示され、証明書Cが自動的に、サーバーへのクライアントのSSL認証に使用されます。

SQLNET.SSL_EXTENDED_KEY_USAGEパラメータの設定

SQLNET.SSL_EXTENDED_KEY_USAGEを設定して、クライアント認証を設定できます。

- クライアントのSQLNET.SSL_EXTENDED_KEY_USAGEパラメータを設定するには、sqlnet.oraファイルを編集し、次の行を含めます。

SQLNET.SSL_EXTENDED_KEY_USAGE = "client authentication"

証明書のフィルタ処理を使用しない場合は、sqlnet.oraファイルからSQLNET.SSL_EXTENDED_KEY_USAGEパラメータ設定を削除します。

手順3: データベース・インスタンスへのログイン

構成の完了後、データベースにログインします。

- SQL*Plusを起動して、次のいずれかの接続コマンドを入力します。

- クライアントにSSL認証を使用する場合は(sqlnet.oraファイルでSSL_CLIENT_AUTHENTICATION=trueを設定)、次のように入力します。

CONNECT/@net_service_name

- SSL認証を使用しない場合は(sqlnet.oraファイルでSSL_CLIENT_AUTHENTICATION=falseを設定)、次のように入力します。

CONNECT username@net_service_name
Enter password: password

関連項目:

証明書失効リストで証明書を検証するようにクライアントを構成する方法の詳細は、証明書失効リストによる証明書の検証を参照してください

Secure Sockets Layer構成のトラブルシューティング

Oracle Database SSLアダプタの使用中に一般的なエラーが発生する場合があります。

Oracle Netトレースを有効にして、エラーの原因を特定することが必要になる場合があります。トレース・パラメータを設定してOracle Netトレースを有効にする方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

ORA-28759: ファイルのオープンに失敗しました

原因: 指定されたファイルをオープンできませんでした。通常、このエラーはウォレットが見つからないために発生します。

処置: 次の点を確認します。

- sqlnet.oraファイルに正しいウォレット・ロケーションが指定されていることを確認します。これは、ウォレットを保存したディレクトリと同じにする必要があります。

- Oracle Netトレースを有効にして、開くことができないファイルの名前とその原因を調べます。

- ウォレットを保存したときに自動ログインが有効になっていたことを確認します。『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

ORA-28786: 暗号化された秘密鍵の復号化に失敗しました

原因: 暗号化された秘密鍵の復号化に不正なパスワードが使用されました。このことは、多くの場合、自動ログイン・ウォレットが使用されていないために発生します。

処置: Oracle Wallet Managerを使用して、ウォレットの自動ログイン機能をオンにします。次に、ウォレットを再度保存します。『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

自動ログイン機能が使用されていない場合は、正しいパスワードを入力します。

ORA-28858: SSLプロトコル・エラーが発生しました

原因: これは、2つのプロセス間のSSLハンドシェイク・ネゴシエーション中に発生する可能性がある一般的なエラーです。

処置: Oracle Netトレースを使用可能にし、再接続してトレース出力を生成します。トレース出力をOracleカスタマ・サポートに連絡してください。

ORA-28859 SSLでネゴシエーションに失敗しました

原因: SSLプロトコルの一部である2つのプロセス間のネゴシエーション中にエラーが発生しました。このエラーは、両プロセスの接続で同じ暗号スイートがサポートされていない場合に発生する可能性があります。

処置: 次の点を確認します。

- Oracle Net Managerを使用して、クライアントとサーバーの両方のSSLバージョンが一致しているか、互換性があることを確認します。たとえば、サーバーでSSL 3.0のみを受け入れ、クライアントでTLS 1.0のみを受け入れる場合、SSL接続は失敗します。

- Oracle Net Managerを使用して、クライアントとサーバーの両方で構成されている暗号スイートをチェックし、両方に互換性のある暗号スイートが設定されていることを確認します。
エラーが繰り返される場合は、Oracle Netトレースを有効にし、再接続してください。トレース出力をOracleカスタマ・サポートに連絡してください。

関連項目:

クライアントとサーバーで互換性のある暗号スイートを設定する方法の詳細は、「手順2D: クライアントのSecure Sockets Layer暗号スイートの設定(オプション)」を参照してください。

注意:

暗号スイートを構成しない場合は、使用可能なすべての暗号スイートが有効になります。

ORA-28862: SSL接続に失敗しました。

原因: このエラーは、ピアが接続をクローズしたために発生しました。

処置: 次の点を確認します。

- ウォレットが検出されるように、sqlnet.oraファイルに正しいウォレット・ロケーションが指定されていることを確認します。

- Oracle Net Managerを使用して、sqlnet.oraファイルに暗号スイートが正しく設定されていることを確認します。このエラーは、sqlnet.oraが手動で編集され、暗号スイート名の綴りが誤っている場合に発生することがあります。暗号スイート名で大/小文字が区別される文字列照合が使用されていることを確認します。

- Oracle Net Managerを使用して、クライアントとサーバーの両方のSSLバージョンが一致しているか、互換性があることを確認します。このエラーは、サーバーとクライアントに指定されているSSLバージョンが一致しないために発生することがあります。たとえば、サーバーでSSL 3.0のみを受け入れ、クライアントでTLS 1.0のみを受け入れる場合、SSL接続は失敗します。

- 診断情報の詳細を確認するために、ピアでOracle Netトレースを有効にします。

ORA-28865: SSL接続はクローズしました。

原因: 基礎となるトランスポート層でエラーが発生したか、ピア・プロセスが突然停止したため、SSL接続がクローズしました。

処置: 次の点を確認します。

- Oracle Net Managerを使用して、クライアントとサーバーの両方のSSLバージョンが一致しているか、互換性があることを確認します。このエラーは、サーバーとクライアントに指定されているSSLバージョンが一致しないために発生することがあります。たとえば、サーバーでSSL 3.0のみを受け入れ、クライアントでTLS 1.0のみを受け入れる場合、SSL接続は失敗します。

- Diffie-Hellman匿名暗号スイートを使用し、サーバーのlistener.oraファイルでSSL_CLIENT_AUTHENTICATIONパラメータがtrueに設定されている場合、クライアントは証明書をサーバーに渡しません。サーバーがクライアントの証明書を受信しない場合、クライアントを認証できないため接続がクローズされます。これを解決するには、別の暗号スイートを使用するか、このlistener.oraパラメータをfalseに設定します。

- Oracle Netトレースを有効にし、トレース出力にネットワーク・エラーがないか確認します。

- 詳細は、「ORA-28862: SSL接続に失敗しました。」の「処置」を参照してください。

ORA-28868: ピア証明連鎖のチェックに失敗しました。

原因: ピアが証明連鎖を提示したときに、その証明連鎖のチェックに失敗しました。この失敗の原因として、いくつかの問題が考えられます。

- 連鎖内のいずれかの証明書が期限切れになっています。

- 連鎖内のいずれかの証明書の認証局がトラスト・ポイントとして認識されていません。

- いずれかの証明書の署名を検証できません。

処置: Oracle Wallet Managerを使用してウォレットを開き、次のことを確認するには、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- ウォレットにインストールされているすべての証明書が使用可能である(期限切れでない)こと。

- ピア証明連鎖からの認証局の証明書が、ウォレットに信頼できる証明書として追加されています。Oracle Wallet Managerを使用して、信頼できる証明書をインポートするには、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

ORA-28885: 必須の鍵使用方法のある証明書が見つかりません。

原因: 証明書は、適切なX.509バージョン3の鍵使用方法の拡張機能を使用して作成されていません。

処置: Oracle Wallet Managerを使用して、証明書の鍵使用方法をチェックします。鍵使用方法の値の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

ORA-29024: 証明書の検証に失敗しました

原因: 反対側から送信された証明書の妥当性チェックに失敗しました。このエラーは、証明書が期限切れか、失効済か、または他の理由で無効になっている場合に発生する可能性があります。

処置: 次の点を確認します。

- 証明書をチェックして、有効かどうかを確認します。必要に応じて、新規の証明書を取得するか、送信者に証明書にエラーがあることを警告するか、または再送します。

- サーバーのウォレットに、クライアントの証明書を検証検証するための適切なトラスト・ポイントがあることを確認します。トラスト・ポイントがない場合は、Oracle Wallet Managerを使用して、適切なトラスト・ポイントをウォレットにインポートします。信頼できる証明書のインポートの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- 証明書が失効していないこと、および証明書失効リスト(CRL)チェックがオンになっていることを確認します。詳細は、証明書失効リストによる証明書検証の構成を参照してください

ORA-29223: 証明連鎖を作成できませんでした

原因: インストールする証明書の既存のトラスト・ポイントを使用して証明連鎖を作成できません。通常、このエラーは、ピアによって完全な連鎖が提供されず、連鎖を完了するのに適切なトラスト・ポイントがない場合に戻されます。

処置: Oracle Wallet Managerを使用して、連鎖の完了に必要なトラスト・ポイントをインストールします。信頼できる証明書のインポートの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

証明書失効リストによる証明書の検証

オラクル社では、証明書失効リストを使用して証明書を検証できるツールを提供しています。

内容は次のとおりです。

- 証明書失効リストによる証明書検証について

- 使用するCRLの選択方法

- CRLチェックの動作の仕組み

- 証明書失効リストによる証明書検証の構成

- 証明書失効リストの管理

- CRL証明書検証のトラブルシューティング

証明書失効リストによる証明書検証について

指定の証明書を指定のコンテキストで使用できるかどうかを判定するプロセスは、証明書の検証と呼ばれます。

証明書の検証には、次が該当するかどうかの判定が含まれます。

- 信頼できる認証局(CA)にデジタル署名された証明書があるかどうか。

- 証明書のデジタル署名が、証明書自体の別個に計算されたハッシュ値および証明書の署名者の(CAの)公開鍵に対応しているかどうか。

- 証明書が期限切れになっていないかどうか。

- 証明書が失効していないかどうか。

SSLネットワーク・レイヤーは、自動的に最初の3つの検証チェックを実行しますが、証明書が失効していないことを確認するには、証明書失効リスト(CRL)のチェックを構成する必要があります。CRLは、失効した証明書のリストを含む署名付きデータ構造体です。これは通常、元の証明書を発行したエンティティと同じエンティティによって発行され署名されます。(「証明書失効リスト(CRL)」を参照。)

使用するCRLの選択方法

使用するトラスト・ポイントすべてについてCRLが必要です。

トラスト・ポイントは、一定の信頼レベルで資格を与えられたサード・パーティ・アイデンティティからの信頼できる証明書です。

通常、信頼する認証局はトラスト・ポイントと呼ばれます。

CRLチェックの動作の仕組み

Oracle Databaseでは証明書の失効状態をCRLに照らして確認します。

CRLはファイル・システム・ディレクトリ(Oracle Internet Directory)に存在するか、または証明書のCRL配布ポイント(CRL DP)拡張で指定された場所からダウンロードして入手します。

通常、CRL定義は数日間有効です。CRLをローカル・ファイル・システムまたはディレクトリに格納する場合、CRLを定期的に更新する必要があります。 CRL配布ポイント(CRL DP)を使用する場合、証明書が使用されるたびにCRLがダウンロードされるため、CRLを定期的に更新する必要はありません。

サーバーは、次の場所で(ここに示されている順番で)CRLを検索します。システムは、証明書のCAのDNと一致するCRLを検出すると、検索を停止します。

1. ローカル・ファイル・システム
システムは、まずsqlnet.oraファイルのSSL_CRL_FILEパラメータを確認し、それからSSL_CRL_PATHパラメータを確認します。システムは、これらの2つのパラメータが指定されていない場合、ウォレット・ロケーションで任意のCRLをチェックします。

注意: CRLをローカル・ファイル・システムに格納する場合、orapkiユーティリティを使用してCRLを定期的に更新する必要があります。詳細は、証明書検証用ハッシュ値によるCRLの名前変更を参照してください。

2. Oracle Internet Directory
サーバーは、ローカル・ファイル・システムでCRLを検出できず、ldap.oraファイルでディレクトリ接続情報が構成されている場合、このディレクトリを検索します。これは、CAの識別名(DN)およびCRLサブツリーのDNを使用してCRLサブツリーを検索します。

ディレクトリでCRLを検索するためには、サーバーに、適切に構成されたldap.oraファイルが存在している必要があります。Oracle Internet Directoryのドメイン・ネーム・システム(DNS)検出機能は使用できません。また、CRLをディレクトリに格納する場合、orapkiユーティリティを使用してCRLを定期的に更新する必要があることに注意してください。詳細は、Oracle Internet DirectoryへのCRLのアップロードを参照してください

3. CRL DP
CAが、証明書が発行されたときのCRL DP X.509、バージョン3、証明書拡張子内の位置を指定すると、その証明書用の失効情報を含む適切なCRLがダウンロードされます。現在、Oracle Databaseは、LDAPを介したCRLのダウンロードをサポートしています。

次のことに注意してください。

- パフォーマンス上の理由から、ユーザー証明書のみがチェックされます。

- CRLをローカル・ファイル・システムではなくディレクトリに格納することをお薦めします。

証明書失効リストによる証明書検証の構成

sqlnet.oraファイルを編集して、証明書失効リストによる証明書検証を構成できます。

内容は次のとおりです。

- 証明書失効リストによる証明書検証の構成について

- クライアントまたはサーバー用の証明書失効ステータス・チェックの有効化

- 証明書失効ステータス・チェックの無効化

証明書失効リストによる証明書検証の構成について

証明書失効ステータス・チェックを有効にするには、sqlnet.oraファイルでSSL_CERT_REVOCATIONパラメータをREQUIREDまたはREQUESTEDに設定する必要があります。

証明書失効ステータス・チェックを有効にするには、sqlnet.oraファイルでSSL_CERT_REVOCATIONパラメータをREQUIREDまたはREQUESTEDに設定する必要があります。

デフォルトでは、このパラメータはNONEに設定され、証明書失効ステータス・チェックはオフになっています。

注意:

CRLをローカル・ファイル・システムまたはOracle Internet Directoryに格納する場合は、コマンドライン・ユーティリティorapkiを使用して、ファイル・システム内のCRLの名前を変更するか、CRLをディレクトリにアップロードします。orapkiの使用方法の詳細は、証明書失効リストの管理を参照してください。

クライアントまたはサーバー用の証明書失効ステータス・チェックの有効化

クライアントまたはサーバー用の証明書失効ステータス・チェックを有効にできます。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。

ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「SSL」タブを選択します。

5. 「失効チェック」リストから次のいずれかのオプションを選択します。

- 必須: 証明書失効ステータス・チェックが必須です。証明書が失効しているかCRLが見つからない場合、SSL接続は拒否されます。証明書がまだ失効していないことが確認された場合にのみ、SSL接続は許可されます。

- リクエスト済: CRLが使用可能な場合に、証明書失効ステータス・チェックを実行します。証明書が失効している場合、SSL接続は拒否されます。CRLが見つからない場合や、証明書がまだ失効していない場合、SSL接続は許可されます。
パフォーマンス上の理由から、ユーザー証明書の失効のみがチェックされます。

6. (オプション)CRLがローカル・ファイル・システムに格納されている場合は、次のフィールドのいずれか、または両方を設定して、格納場所を指定します。これらのフィールドは、「失効チェック」が「必須」または「リクエスト済」に設定されている場合にのみ使用できます。

- 証明書失効リスト・パス: CRLが格納されているディレクトリへのパスを入力するか、または「参照」をクリックし、ファイル・システムを検索してディレクトリを探します。このパスを指定すると、sqlnet.oraファイルのSSL_CRL_PATHパラメータが設定されます。このパラメータでパスを指定しない場合、デフォルトはウォレット・ディレクトリです。DERエンコードされた(バイナリ形式)CRLおよびPEMエンコードされた(BASE64)CRLの両方がサポートされています。

- 証明書失効リスト・ファイル: 包括的CRLファイル(PEMエンコードされた(BASE64) CRLが優先度の順に1つのファイルに連結されたもの)へのパスを入力するか、または「参照」をクリックし、ファイル・システムを検索してディレクトリを探します。このファイルを指定すると、sqlnet.oraファイルのSSL_CRL_FILEパラメータが設定されます。このパラメータを設定した場合、ファイルが指定された場所に存在する必要があります。存在しない場合、アプリケーションは起動中にエラーになります。
「証明書失効リスト・パス」を設定してCRLをローカル・ファイル・システム・ディレクトリに格納する場合は、orapkiユーティリティを使用して、システムが特定できるようにCRLの名前を変更する要があります。証明書検証用ハッシュ値によるCRLの名前変更を参照してください。

7. (オプション)CRLをOracle Internet Directoryからフェッチする場合は、ディレクトリ・サーバーとポート情報をldap.oraファイルで指定する必要があります。

ldap.oraファイルを構成する場合は、ディレクトリに非SSLポートのみを指定する必要があります。CRLダウンロードはSSLプロトコルの一部として実行され、SSL接続内でのSSL接続の確立はサポートされません。

Oracle Internet Directoryの非SSLポートが無効になっている場合、Oracle DatabaseのCRL機能は動作しません。

8. 「ファイル」→「ネットワーク構成の保存」を選択します。sqlnet.oraファイルが更新されます。

証明書失効ステータス・チェックの無効化

証明書失効ステータス・チェックを無効にできます。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。

ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「SSL」タブを選択します。

5. 「失効チェック」リストから「なし」を選択します。

6. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。

sqlnet.oraファイルが次のエントリで更新されます。

SSL_CERT_REVOCATION=NONE

関連項目:

証明書の検証のエラーの解決方法は、CRL証明書検証のトラブルシューティングを参照してください。

証明書失効リストの管理

証明書失効リストの管理では、証明書失効チェックを有効にする前に、CRLが正しい書式であることを確認する必要があります。

内容は次のとおりです。

- 証明書失効リストの管理について

- CRLを管理するコマンドのorapkiヘルプの表示

- 証明書検証用ハッシュ値によるCRLの名前変更

- Oracle Internet DirectoryへのCRLのアップロード

- Oracle Internet Directoryに格納されているCRLの一覧表示

- Oracle Internet DirectoryでのCRLの表示

- Oracle Internet DirectoryからのCRLの削除

証明書失効リストの管理について

Oracle Databaseには、証明書の管理を実行するために使用できるコマンドライン・ユーティリティorapkiがあります。

証明書失効ステータス・チェックを有効にするには、まず、使用するCAから受信したCRLがコンピュータで使用できるフォームである(ハッシュ値で名前変更されている)こと、またはコンピュータで使用できる場所にある(ディレクトリにアップロードされている)ことを確認してください。

LDAPコマンドライン・ツールを使用して、Oracle Internet DirectoryでCRLを管理することもできます。

注意:

CRLは、正常な検証を行うために、(期限切れになる前に)定期的に更新する必要があります。このタスクは、スクリプトでorapkiコマンドを使用して自動化できます。

CRLを管理するコマンドのorapkiヘルプの表示

CRLの管理に使用可能なorapkiコマンドをすべて表示できます。

- CRLの管理に使用可能なorapkiコマンドとそのオプションをすべての表示するには、コマンドラインに次のように入力します。

orapki crl help

注意:

-summary、-completeまたは-walletコマンド・オプションの使用は、常にオプションです。これらのコマンド・オプションが指定されていなくても、コマンドは実行されます。

証明書検証用ハッシュ値によるCRLの名前変更

システムは、証明書を検証するとき、証明書を作成したCAが発行するCRLを見つける必要があります。

システムは、証明書の発行者名とCRLにある発行者名を照合して適切なCRLを検出します。

Oracle Net Managerの「証明書失効リスト・パス」フィールドにCRL格納場所を指定する(sqlnet.oraファイルのSSL_CRL_PATHパラメータを設定する)場合、orapkiユーティリティを使用して発行者名を表すハッシュ値を使用してCRLを名前変更します。ハッシュ値を作成すると、サーバーでCRLをロードできます。

UNIXオペレーティング・システムでは、orapkiによってCRLへのシンボリック・リンクが作成されます。Windowsオペレーティング・システムでは、CRLファイルのコピーが作成されます。どちらの場合も、orapkiによって作成されたシンボリック・リンクまたはコピーは、発行者名のハッシュ値を使用して名前が付けられます。その後、システムが証明書を検証するとき、同じハッシュ関数が使用されて、適切なCRLをロードできるようにリンク(またはコピー)の名前が計算されます。

- オペレーティング・システムに応じて、次のコマンドのいずれかを入力して、ファイル・システムに格納されているCRLの名前を変更します。

- UNIXファイル・システムに格納されているCRLの名前を変更するには:

orapki crl hash -crl crl_filename [-wallet wallet_location] -symlink crl_directory [-summary]

- Windowsファイル・システムに格納されているCRLの名前を変更するには:

orapki crl hash -crl crl_filename [-wallet wallet_location] -copy crl_directory [-summary]

この指定では、crl_filenameはCRLファイルの名前、wallet_locationはCRLを発行したCAの証明書を含むウォレットの場所、crl_directoryはCRLがあるディレクトリです。

-walletおよび-summaryの使用はオプションです。-walletを指定すると、CRLの名前を変更する前に、ツールによってCAの証明書に対するCRLの有効性が確認されます。-summaryオプションを指定すると、ツールによってCRL発行者名が表示されます。

Oracle Internet DirectoryへのCRLのアップロード

ディレクトリでCRLを発行すると、企業全体でのCRL検証が可能になり、個々のアプリケーションに固有のCRLを構成する必要がなくなります。

すべてのアプリケーションで、一元的に管理可能なディレクトリに格納されたCRLを使用できるので、CRL管理および使用の管理オーバーヘッドが大幅に減ります。orapkiを使用してディレクトリにCRLをアップロードするユーザーは、ディレクトリ・グループCRLAdmins(cn=CRLAdmins,cn=groups,%s_OracleContextDN%)のメンバーである必要があります。これらのCRLには企業全体でアクセスできるため、これは特権操作です。この管理ディレクトリ・グループに追加するには、ディレクトリ管理者に連絡してください。

- CRLをディレクトリにアップロードするには:

orapki crl upload -crl crl_location -ldap hostname:ssl_port -user username [-wallet wallet_location] [-summary]

この指定では、crl_locationはCRLがあるファイル名またはURL、hostnameおよびssl_port(認証なしのSSLポート)はディレクトリがインストールされているシステムに対するもの、usernameはCRLをCRLサブツリーに追加する権限があるディレクトリ・ユーザー、wallet_locationはCRLを発行したCAの証明書を含むウォレットの場所です。

-walletおよび-summaryの使用はオプションです。-walletを指定すると、CRLをディレクトリにアップロードする前に、ツールによってCAの証明書に対するCRLの有効性が確認されます。-summaryオプションを指定すると、CRL発行者名、およびCRLがディレクトリに格納されているLDAPエントリがツールによって出力されます。

次の例では、orapkiユーティリティを使用してCRLをアップロードする方法を示しています。

orapki crl upload -crl /home/user1/wallet/crldir/crl.txt -ldap host1.example.com:3533 -user cn=orcladmin

注意:

- orapkiユーティリティを使用すると、この操作の実行時にディレクトリ・パスワードの入力を求めるプロンプトが表示されます。

- Diffie-HellmanベースのSSLサーバーが実行されているディレクトリのSSLポートを指定していることを確認してください。これは、認証を実行しないSSLポートです。サーバー認証も相互認証SSLポートも、orapkiユーティリティではサポートされていません。

Oracle Internet Directoryに格納されているCRLの一覧表示

orapkiを使用してディレクトリに格納されているすべてのCRLのリストを表示できます。特定のCRLを検出してローカル・コンピュータで表示またはダウンロードする際に、このリストを参照すると便利です。

このコマンドを使用すると、CRLを発行したCA(発行者)およびディレクトリのCRLサブツリー内の場所(DN)が表示されます。

- Oracle Internet DirectoryでCRLを一覧表示するには:

orapki crl list -ldap hostname:ssl_port

hostnameおよびssl_portは、ディレクトリがインストールされているシステムに対するものです。これは、前の項で説明した認証なしのディレクトリのSSLポートであることに注意してください。

Oracle Internet DirectoryでのCRLの表示

Oracle Internet Directory CRLは要約された形式で表示できるほか、CRLの失効した証明書のリストを要求することもできます。

Oracle Internet Directoryに格納されているCRLを要約された形式で表示するか、CRLの失効した証明書の完全なリストを要求できます。

サマリー・リストには、CRL発行者名およびその有効期間が記載されています。完全なリストには、そのCRLに含まれるすべての失効した証明書のリストが記載されています。

- Oracle Internet DirectoryでCRLのサマリー・リストを表示するには:

orapki crl display -crl crl_location [-wallet wallet_location] -summary

crl_locationはディレクトリ内のCRLの場所です。orapki crl listコマンドを使用すると表示されるリストからCRLの位置を貼り付けると便利です。Oracle Internet Directoryに格納されているCRLの一覧表示を参照してください。

Oracle Internet Directoryに格納されている指定したCRLに含まれているすべての失効した証明書のリストを表示するには、コマンドラインに次のように入力します。

orapki crl display -crl crl_location [-wallet wallet_location] -complete

たとえば、orapkiコマンドを次のように入力します。

orapki crl display -crl $T_WORK/pki/wlt_crl/nzcrl.txt -wallet $T_WORK/pki/wlt_crl -complete

次の出力が生成されます。これには、CRL発行者のDN、発行日、次の更新日、および含まれる失効した証明書が示されます。

issuer = CN=root,C=us, thisUpdate = Sun Nov 16 10:56:58 PST 2003, nextUpdate = Mon Sep 30 11:56:58 PDT 2013, revokedCertificates = {(serialNo = 153328337133459399575438325845117876415, revocationDate - Sun Nov 16 10:56:58 PST 2003)}
CRL is valid

-walletオプションを使用すると、orapki crl displayコマンドにより、CAの証明書に対してCRLが検証されます。

-completeオプションを選択すると、CRLのサイズによっては、表示に時間がかかる場合があります。

Oracle Directory Manager(Oracle Internet Directoryに付属するグラフィカル・ユーザー・インタフェース)を使用して、ディレクトリ内のCRLを表示することもできます。CRLは、次のディレクトリの場所に格納されます。

cn=CRLValidation,cn=Validation,cn=PKI,cn=Products,cn=OracleContext

Oracle Internet DirectoryからのCRLの削除

orapkiを使用してディレクトリからCRLを削除するユーザーは、ディレクトリ・グループCRLAdminsのメンバーである必要があります。

このディレクトリ管理グループの詳細は、Oracle Internet DirectoryへのCRLのアップロードを参照してください。

- CRLをディレクトリから削除するには:

orapki crl delete -issuer issuer_name -ldap host:ssl_port -user username [-summary]

ここで、issuer_nameはCRLを発行したCAの名前、hostnameおよびssl_portはディレクトリがインストールされているシステムに対するもの、usernameはCRLをCRLサブツリーから削除する権限があるディレクトリ・ユーザーです。このポートは、認証を使用しないディレクトリのSSLポートであることが必要です。このポートの詳細は、「Oracle Internet DirectoryへのCRLのアップロード」を参照してください。

-summaryオプションを使用すると、削除されたCRL LDAPエントリがツールによって印刷されます。

たとえば、orapkiコマンドを次のように入力します。

orapki crl delete -issuer "CN=root,C=us" -ldap machine1:3500 -user cn=orcladmin -summary

次の出力が生成されます。これには、ディレクトリ内の削除されたCRLの場所が示されます。

Deleted CRL at cn=root cd45860c.rN,cn=CRLValidation,cn=Validation,cn=PKI,cn=Products,cn=OracleContext

CRL証明書検証のトラブルシューティング

CRLに対して証明書を検証するかどうかを判断するには、Oracle Netトレースを有効にできます。

CRLを使用して失効した証明書を検証すると、Oracle Netトレース・ファイルに次のエントリが記録され、entryとexitの間にエラー・メッセージは記録されません。

nzcrlVCS_VerifyCRLSignature: entry
nzcrlVCS_VerifyCRLSignature: exit

nzcrlVCD_VerifyCRLDate: entry
nzcrlVCD_VerifyCRLDate: exit

nzcrlCCS_CheckCertStatus: entry
nzcrlCCS_CheckCertStatus: Certificate is listed in CRL
nzcrlCCS_CheckCertStatus: exit

注意:

証明書検証に失敗した場合は、SSLハンドシェイク時にピアに「ORA-29024: 証明書の検証に失敗しました」というメッセージが表示されます。このメッセージが表示された場合は、証明書検証に関連するOracle Netトレース・ファイルのエラー・メッセージでエラーの解決方法を参照してください。

関連項目:

トレース・パラメータを設定してOracle Netトレースを有効にする方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

証明書検証に関連するOracle Netトレース・ファイルのエラー・メッセージ

証明書検証に関連するトレース・メッセージが生成されます。

これらのトレースメッセージは、Oracle Netトレース・ファイルのentryエントリとexitエントリの間に記録されることがあります。Oracle SSLは複数の場所でCRLを検索するため、トレースに複数のエラーが記録されることがあります。

エラーの解決方法の詳細は、次の表示される可能性があるエラー・メッセージのリストを確認できます。

RSAステータスでCRLの署名検証に失敗しました

原因: CRLの署名を検証できません。

処置: ダウンロードしたCRLがピアのCAによって発行されたものであることと、ダウンロード時に破損しなかったことを確認します。CRLは、orapkiユーティリティによって検証されてから、ハッシュ値で名前が変更されるかディレクトリにアップロードされます。

関連項目:

CRL管理にorapkiを使用する方法の詳細は、証明書失効リストの管理を参照してください

RSAステータスでCRLの日付検証に失敗しました

原因: 現在の時刻が次の更新フィールド内の時刻より後になっています。このエラーは、CRL DPを使用している場合には表示されません。CRLは次の順番で検索されます。

1. ファイル・システム

2. Oracle Internet Directory

3. CRL DP

この検索で最初に見つかったCRLが最新であるとはかぎりません。

処置: CRLを最新のコピーで更新します。

CRLが見つかりませんでした

原因: 構成されている場所にCRLがありませんでした。構成で証明書検証が必須に指定されている場合、エラーORA-29024が戻されます。

処置: 次の手順を実行して、構成で指定されているCRLの場所が正しいことを確認します。

1. Oracle Net Managerを使用して、正しいCRLの場所が構成されているかどうかを確認します。証明書失効リストによる証明書検証の構成を参照してください

2. 必要に応じて、orapkiユーティリティを使用してシステムで使用するCRLを次のように構成します。

- ローカル・ファイル・システムに格納されているCRLの場合は、証明書検証用ハッシュ値によるCRLの名前変更を参照してください

- ディレクトリに格納されているCRLの場合は、Oracle Internet DirectoryへのCRLのアップロードを参照してください

Oracle Internet Directoryのホスト名またはポート番号が設定されていません

原因: Oracle Internet Directoryの接続情報が設定されていません。これは致命的エラーではありません。続いてCRL DPが検索されます。

処置: CRLをOracle Internet Directoryに格納する場合は、Oracle Net Configuration Assistantを使用して、Oracleホームのldap.oraファイルを作成し、構成します。

CRL DPからのCRLのフェッチ: CRLが見つかりません

原因: CRL配布ポイント(CRL DP)を使用してCRLをフェッチできませんでした。このことは、証明書にCRL DP拡張で指定された場所がないか、CRL DP拡張で指定されたURLが正しくない場合に発生します。

処置: 認証局が証明書のCRL DP拡張で指定されたURLにCRLを発行することを確認します。

CRLを手動でダウンロードします。次に、それをローカル・ファイル・システムに格納するか、Oracle Internet Directoryに格納するかに応じて、次の手順を実行します。

CRLをローカル・ファイル・システムに格納する場合:

1. Oracle Net Managerを使用して、CRLディレクトリまたはファイルへのパスを指定します。証明書失効リストによる証明書検証の構成を参照してください

2. orapkiユーティリティを使用して、システムで使用するCRLを構成します。証明書検証用ハッシュ値によるCRLの名前変更を参照してください

CRLをOracle Internet Directoryに格納する場合:

1. Oracle Net Configuration Assistantを使用して、ディレクトリ接続情報を含むldap.oraファイルを作成し、構成します。

2. orapkiユーティリティを使用して、CRLをディレクトリにアップロードします。Oracle Internet DirectoryへのCRLのアップロードを参照してください

ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成

Oracle Databaseでは、RSA Security社のPKCS #11仕様に準拠したAPIを使用するハードウェア・セキュリティ・モジュールがサポートされています。

通常、これらのハードウェア・デバイスは、トークンまたはスマートカードの秘密鍵を安全に格納および管理するため、または暗号処理を高速化するために使用されます。

内容は次のとおりです。

- SSLでハードウェア・セキュリティ・モジュールを使用するための一般的なガイドライン

- nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成

- SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成

- ハードウェア・セキュリティ・モジュールの使用時のトラブルシューティング

SSLでハードウェア・セキュリティ・モジュールを使用するための一般的なガイドライン

Oracle Databaseでハードウェア・セキュリティ・モジュールを使用する場合は、次のガイドラインに従ってください。

1. 必要なハードウェア、ソフトウェアおよびPKCS #11ライブラリを取得するには、ハードウェア・デバイス・ベンダーにお問い合せください。

2. 使用しているハードウェア・セキュリティ・モジュールに適したハードウェア、ソフトウェアおよびライブラリをインストールします。

3. ハードウェア・セキュリティ・モジュールのインストールをテストして、正常に動作することを確認します。詳細は、使用するデバイスのドキュメントを参照してください。

4. 秘密鍵をトークンに格納する場合は、Oracle Wallet Managerを使用してPKCS11タイプのウォレットを作成し、PKCS #11ライブラリへの絶対パス(ライブラリ名を含む)を指定します。Oracle PKCS11ウォレットには、秘密鍵にアクセスするためのトークンを指す情報が格納されます。

PKCS #11情報が格納されたウォレットは、任意のOracleウォレットを使用する場合と同様に使用できます。ただし、秘密鍵をハードウェア・デバイスに格納し、暗号操作もそのデバイスで実行する場合を除きます。

関連項目:

ハードウェア・セキュリティ・モジュールの証明書を格納するためにOracleウォレットを作成する方法の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成

暗号化処理でnCipherハードウェア・セキュリティ・モジュールを使用するようにシステムを構成できます。

内容は次のとおりです。

- nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について

- nCipherハードウェア・セキュリティ・モジュールに必要なOracleコンポーネント

- nCipherハードウェア・セキュリティ・モジュールをインストールするためのディレクトリ・パス要件

nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について

nCipher社製のハードウェア・セキュリティ・モジュールは、Oracle Databaseで動作することが証明されています。

これらのモジュールでは、鍵を安全に格納し、暗号処理の負荷を軽減できます。これらのデバイスには、主に次の利点があります。

- 暗号処理の負荷が軽減され、サーバーが他の要求に応答できるようになります。

- デバイス上の秘密鍵の記憶領域が保護されます。

- スマートカードを使用して鍵を管理できます。

注意:

Oracle Databaseで使用する認定済のハードウェアおよびソフトウェアを入手するには、nCipherの代理店にお問い合せください。

nCipherハードウェア・セキュリティ・モジュールに必要なOracleコンポーネント

nCipherハードウェア・セキュリティ・モジュールを使用するには、特別なコンポーネントのセットが必要です。

これらのコンポーネントは次のとおりです。

- nCipherハードウェア・セキュリティ・モジュール

- サポートしているnCipher PKCS #11ライブラリ
次のプラットフォーム固有のPKCS#11ライブラリが必要です。

- libcknfast.soライブラリ(UNIX 32ビットの場合)

- libcknfast-64.soライブラリ(UNIX 64ビットの場合)

- cknfast.dllライブラリ(Windowsの場合)

注意:

ハードウェア・セキュリティ・モジュールまたはセキュア・アクセラレータをインストールし、必要なライブラリを入手するには、nCipherの代理店にお問い合せください。

これらの作業は、Oracle DatabaseでnCipherハードウェア・セキュリティ・モジュールを使用する前に実施する必要があります。

nCipherハードウェア・セキュリティ・モジュールをインストールするためのディレクトリ・パス要件

nCipherハードウェア・セキュリティ・モジュールはnCipher PKCS #11ライブラリを使用します。

セキュア・アクセラレータを使用するには、Oracle Wallet Managerを使用してウォレットを作成するときに、nCipher PKCS #11ライブラリが格納されているディレクトリへの絶対パス(ライブラリ名を含む)を指定する必要があります。これにより、実行時にライブラリをロードできます。

通常、nCipherカードは次の場所にインストールされます。

- /opt/nfast (UNIXの場合)

- C:\nfast (Windowsの場合)

nCipher PKCS #11ライブラリは、通常のインストールでは次の場所に配置されます。

- /opt/nfast/toolkits/pkcs11/libcknfast.so(UNIX 32ビットの場合)

- /opt/nfast/toolkits/pkcs11/libcknfast-64.so(UNIX 64ビットの場合)

- C:\nfast\toolkits\pkcs11\cknfast.dll (Windowsの場合)

注意:

Oracle Databaseの32ビット・リリースを使用する場合は32ビット・ライブラリ・バージョンを使用し、Oracle Databaseの64ビット・リリースを使用する場合は64ビット・ライブラリ・バージョンを使用します。たとえば、Oracle Database for Solaris Operating System (SPARC 64ビット)には、64ビットnCipher PKCS #11ライブラリを使用します。

SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成

暗号化処理でSafeNETハードウェア・セキュリティ・モジュールを使用するようにシステムを構成できます。

内容は次のとおりです。

- SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について

- SafeNET Luna SAハードウェア・セキュリティ・モジュールに必要なOracleコンポーネント

- SafeNETハードウェア・セキュリティ・モジュールをインストールするためのディレクトリ・パス要件

SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について

SafeNET社製のハードウェア・セキュリティ・モジュールは、Oracle Databaseで動作することが証明されています。

これらのモジュールでは、鍵を安全に格納し、暗号処理の負荷を軽減できます。これらのデバイスには、主に次の利点があります。

- 暗号処理の負荷が軽減され、サーバーが他の要求に応答できるようになります。

- デバイス上の秘密鍵の記憶領域が保護されます。

注意:

Oracle Databaseで使用する認定済のハードウェアおよびソフトウェアを入手するには、SafeNETの代理店にお問い合せください。

SafeNET Luna SAハードウェア・セキュリティ・モジュールに必要なOracleコンポーネント

SafeNET Luna SAハードウェア・セキュリティ・モジュールを使用するには、特別なコンポーネントのセットが必要です。

これらのコンポーネントは次のとおりです。

- SafeNET Luna SAハードウェア・セキュリティ・モジュール

- サポートしているSafeNET Luna SA PKCS #11ライブラリ
次のプラットフォーム固有のPKCS#11ライブラリが必要です。

- libCryptoki2.soライブラリ(UNIXの場合)

- cryptoki.dllライブラリ(Windowsの場合)

注意:

ハードウェア・セキュリティ・モジュールまたはセキュア・アクセラレータをインストールし、必要なライブラリを入手するには、SafeNETの代理店にお問い合せください。

これらの作業は、Oracle DatabaseでSafeNETハードウェア・セキュリティ・モジュールを使用する前に実施する必要があります。

SafeNETハードウェア・セキュリティ・モジュールをインストールするためのディレクトリ・パス要件

SafeNETハードウェア・セキュリティ・モジュールはSafeNET PKCS #11ライブラリを使用します。

セキュア・アクセラレータを使用するには、Oracle Wallet Managerを使用してウォレットを作成するときに、SafeNET PKCS #11ライブラリが格納されているディレクトリへの絶対パス(ライブラリ名を含む)を指定する必要があります。これにより、実行時にライブラリをロードできます。

通常、SafeNET Luna SAクライアントは次の場所にインストールされます。

- /usr/lunasa (UNIXの場合)

- C:\Program Files\LunaSA (Windowsの場合)

SafeNET Luna SA PKCS #11ライブラリは、通常のインストールでは次の場所に配置されます。

- /usr/lunasa/lib/libCryptoki2.so (UNIXの場合)

- C:\Program Files\LunaSA\cryptoki2.dll (Windowsの場合)

ハードウェア・セキュリティ・モジュールの使用時のトラブルシューティング

ハードウェア・セキュリティ・モジュールに関するトラブルシューティングのアドバイスを提供します。

内容は次のとおりです。

- Oracle Netトレース・ファイルのエラー

- ハードウェア・セキュリティ・モジュールの使用に関連するエラー・メッセージ

Oracle Netトレース・ファイルのエラー

使用されているモジュールを検出するには、Oracle Netトレースをオンにします。

ウォレットにPKCS #11情報が含まれ、モジュールの秘密鍵が使用されている場合は、Oracle Netトレースに次のエントリが記録され、entryとexitの間にエラー・メッセージは記録されません。

nzpkcs11_Init: entry
nzpkcs11CP_ChangeProviders: entry
nzpkcs11CP_ChangeProviders: exit
nzpkcs11GPK_GetPrivateKey: entry
nzpkcs11GPK_GetPrivateKey: exit
nzpkcs11_Init: exit
...
nzpkcs11_Decrypt: entry
nzpkcs11_Decrypt: exit

nzpkcs11_Sign: entry
nzpkcs11_Sign: exit

関連項目:

トレース・パラメータを設定してOracle Netトレースを有効にする方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

ハードウェア・セキュリティ・モジュールの使用に関連するエラー・メッセージ

PKCS #11ハードウェア・セキュリティ・モジュールの使用に関連するエラーが表示される場合があります。

ORA-43000: PKCS11ライブラリが見つかりません

原因: ウォレットの作成時に指定された場所にPKCS #11ライブラリが見つかりません。これは、ウォレットの作成後にライブラリが移動された場合にのみ発生します。

処置: PKCS #11ライブラリをウォレットが作成されたときの場所にコピーします。

ORA-43001: PKCS11トークンが見つかりません

原因: ウォレットの作成に使用されたスマートカードがハードウェア・セキュリティ・モジュールのスロットにありません。

処置: ウォレットの作成時に使用されたスマートカードがハードウェア・セキュリティ・モジュールのスロットにあることを確認します。

ORA-43002: PKCS11パスワードが無効です

原因: これは、ウォレットの作成時に指定されたパスワードが正しくない場合、またはウォレットの作成後にPKCS #11デバイス・パスワードを変更し、Oracle Wallet Managerを使用してウォレットで更新しなかった場合に発生する可能性があります。

処置: 原因に応じて、次のいずれかの処置を行います。

ウォレットの作成時にこのエラーが表示された場合は、パスワードが正しいことを確認し、再入力します。

ウォレットの作成後にパスワードを変更した場合は、Oracle Wallet Managerを使用してウォレットを開き、新しいパスワードを入力します。

関連項目:

ハードウェア・セキュリティ証明書を格納するためにOracleウォレットを作成する方法の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

注意:

nCipherログ・ファイルは、モジュールがインストールされているディレクトリの次の場所にあります。

/log/logfile

関連項目:

nCipherデバイスとSafeNETデバイスのトラブルシューティングの詳細は、nCipherとSafeNETのドキュメントを参照してください。

19 RADIUS認証の構成

RADIUSは、リモート認証およびアクセスを実現するために広く使用されているクライアント/サーバー・セキュリティ・プロトコルです。Oracle Databaseは、クライアント/サーバー・ネットワーク環境でこの業界標準を使用しています。

内容は次のとおりです。

- RADIUS認証の構成について

- RADIUSの構成要素

- RADIUS認証モード

- RADIUS認証、認可およびアカウンティングの有効化

- RADIUSを使用したデータベースへのログイン

- RSA ACE/Server構成チェックリスト

注意:

RSA Security社の認証製品であるSecurIDは、Oracle Databaseで直接的にはサポートされていませんが、RADIUS準拠として認定されています。したがって、RADIUSのもとでSecurIDを実行できます。

詳細は、RSA Security社のSecurIDのドキュメントを参照してください。

RADIUS認証の構成について

Oracle Databaseネットワークでは、RADIUS標準をサポートする任意の認証方法を使用できます。

RADIUSプロトコルをインストールおよび構成するときには、トークン・カードやスマート・カードといったRADIUS標準もサポートされます。Oracle Databaseは、クライアント/サーバー・ネットワーク環境でRADIUSを使用します。さらに、RADIUSを使用すると、OracleクライアントまたはOracleデータベース・サーバーを変更することなく、認証方式を変更できます。

エンド・ユーザーから見ると、認証手続き全体は透過的です。ユーザーがOracleデータベース・サーバーにアクセスしようとすると、RADIUSクライアントとして機能するOracleデータベース・サーバーはRADIUSサーバーに通知します。RADIUSサーバーは次の処理を行います。

- ユーザーのセキュリティ情報を検索します。

- 適切な認証サーバー(複数可)とOracleデータベース・サーバーの間で認証および認可情報の受渡しを行います。

- Oracleデータベース・サーバーへのユーザー・アクセスを許可します。

- ユーザーがいつ、どのくらいの頻度で、どのくらいの時間、Oracleデータベース・サーバーに接続していたかなどのセッション情報をログに記録します。

注意:

Oracle Databaseでは、データベース・リンクを介したRADIUS認証はサポートされません。

図19-1に、Oracle Database-RADIUS環境を示します。

図19-1 Oracle環境でのRADIUS

Oracle DatabaseサーバーはRADIUSクライアントとして機能し、OracleクライアントとRADIUSサーバーの間で情報の受渡しを行います。同様に、RADIUSサーバーはOracleデータベース・サーバーと適切な認証サーバーの間で情報の受渡しを行います。

RADIUSサーバーのベンダーが認証サーバーのベンダーでもある場合も多くあります。この場合、RADIUSサーバーで認証を処理できます。たとえば、RSA ACE/Serverは、RADIUSサーバーであり認証サーバーでもあります。したがって、ユーザーのパス・コードが認証されます。

注意:

RSA Security社の認証製品であるSecurIDは、Oracle Databaseで直接的にはサポートされていませんが、RADIUS準拠として認定されています。したがって、RADIUSのもとでSecurIDを実行できます。

詳細は、RSA Security社のSecurIDのドキュメントを参照してください。

関連項目:

sqlnet.oraファイルの詳細は、Oracle Database Net Servicesリファレンス を参照してください

RADIUSの構成要素

RADIUSには、構成設定を管理できる一連の認証の構成要素があります。

表19-1に、認証の構成要素を示します。

表19-1 RADIUS認証の構成要素

構成要素

格納される情報

Oracleクライアント

RADIUSによる通信のための構成設定

Oracleデータベース・サーバー/RADIUSクライアント

OracleクライアントとRADIUSサーバーの間で情報の受渡しを行うための構成設定

秘密鍵ファイル

RADIUSサーバー

すべてのユーザーの認証および認可情報

各クライアントの名前またはIPアドレス

各クライアントの共有シークレット

すでに認証されているユーザーが再接続しなくても別のログイン・オプションを選択できるようにする無制限の数のメニュー・ファイル

認証サーバー(複数可)

パス・コードやPINなどのユーザー認証情報(使用中の認証方式によって異なる)

注意: RADIUSサーバーは認証サーバーになることもできます。

RADIUS認証モード

ユーザー認証は、同期認証モードまたはチャレンジ・レスポンス(非同期)認証モードのいずれかで行われます。

内容は次のとおりです。

- 同期認証モード

- チャレンジ・レスポンス(非同期)認証モード

同期認証モード

同期モードでは、RADIUSでパスワードやSecurIDトークン・カードなどの様々な認証方式を使用できます。

内容は次のとおりです。

- 同期認証モードの順序

- 例: SecurIDトークン・カードによる同期認証

同期認証モードの順序

同期認証モードは6ステップの順序です。

図19-2に、同期認証が行われる順序を示します。

図19-2 同期認証の順序

次の手順は、同期認証の順序を示しています。

1. ユーザーが、接続文字列、パス・コードまたはその他の値を入力してログインします。クライアント・システムは、このデータをOracleデータベース・サーバーに渡します。

2. RADIUSクライアントとして機能するOracleデータベース・サーバーは、OracleクライアントからのデータをRADIUSサーバーに渡します。

3. RADIUSサーバーは、検証のためにデータをスマートカードやSecurID ACEなどの適切な認証サーバーに渡します。

4. 認証サーバーは、アクセス受入れまたはアクセス拒否メッセージをRADIUSサーバーに返します。

5. RADIUSサーバーは、このレスポンスをOracleデータベース・サーバー/RADIUSクライアントに渡します。

6. Oracleデータベース・サーバー/RADIUSクライアントは、レスポンスをOracleクライアントに返します。

例: SecurIDトークン・カードによる同期認証

SecurID認証では、各ユーザーにトークン・カードあり、60秒ごとに変わる動的番号が表示されます。

Oracleデータベース・サーバー/RADIUSクライアントにアクセスするために、ユーザーは個人識別番号(PIN)とユーザーのSecurIDカード上に現在表示されている動的番号の両方を含む有効なパス・コードを入力します。Oracleデータベース・サーバーは、Oracleクライアントからのこの認証情報をRADIUSサーバー(この場合は、検証のための認証サーバー)に渡します。認証サーバー(RSA ACE/Server)によってユーザーが検証されると、受入れパケットがOracleデータベース・サーバーに送られ、次に、Oracleクライアントに渡されます。これでユーザーは認証され、適切な表やアプリケーションにアクセスできます。

関連項目:

RSA Security社から提供されるドキュメント

チャレンジ・レスポンス(非同期)認証モード

システムで非同期モードが使用されている場合、ユーザーは、SQL*Plus CONNECT文字列でユーザー名とパスワードを入力する必要はありません。かわりに、ユーザーは後からグラフィカル・ユーザー・インタフェースでこの情報を要求されます。

内容は次のとおりです。

- チャレンジ・レスポンス(非同期)認証モードの順序

- 例: スマートカードによる非同期認証

- 例: ActivCardトークンによる非同期認証

チャレンジ・レスポンス(非同期)認証モードの順序

図19-3に、チャレンジ・レスポンス(非同期)認証が行われる順序を示します。

注意:

RADIUSサーバーが認証サーバーである場合、図19-3の手順3、4、5および手順9、10、11は結合されます。

図19-3 非同期認証の順序

次の手順は、非同期認証の順序を示しています。

1. ユーザーが、Oracleデータベース・サーバーへの接続を開始します。クライアント・システムは、データをOracleデータベース・サーバーに渡します。

2. RADIUSクライアントとして機能するOracleデータベース・サーバーは、OracleクライアントからのデータをRADIUSサーバーに渡します。

3. RADIUSサーバーは、データをスマートカード、SecurID ACE、トークン・カード・サーバーなどの適切な認証サーバーに渡します。

4. 認証サーバーは、ランダム番号などのチャレンジをRADIUSサーバーに送信します。

5. RADIUSサーバーは、チャレンジをOracleデータベース・サーバー/RADIUSクライアントに渡します。

6. Oracleデータベース・サーバー/RADIUSクライアントは、それをOracleクライアントに渡します。グラフィカル・ユーザー・インタフェースで、ユーザーにチャレンジが表示されます。

7. ユーザーは、チャレンジに対するレスポンスを入力します。レスポンスを作成するために、ユーザーは、たとえば、受け取ったチャレンジをトークン・カードに入力できます。トークン・カードによって、グラフィカル・ユーザー・インタフェースに入力する動的なパスワードが提供されます。Oracleクライアントは、ユーザーのレスポンスをOracleデータベース・サーバー/RADIUSクライアントに渡します。

8. Oracleデータベース・サーバー/RADIUSクライアントは、ユーザーのレスポンスをRADIUSサーバーに送信します。

9. RADIUSサーバーは、検証のためにユーザーのレスポンスを適切な認証サーバーに渡します。

10. 認証サーバーは、アクセス受入れまたはアクセス拒否メッセージをRADIUSサーバーに返します。

11. RADIUSサーバーは、レスポンスをOracleデータベース・サーバー/RADIUSクライアントに渡します。

12. Oracleデータベース・サーバー/RADIUSクライアントは、レスポンスをOracleクライアントに渡します。

例: スマートカードによる非同期認証

スマートカード認証では、ユーザーは、スマートカードを読み取るスマートカード・リーダーにスマートカードを挿入することによってログインします。

スマートカードは、情報を格納するための集積回路が埋め込まれた、クレジット・カードのようなプラスチック・カードです。

Oracleクライアントは、Oracleデータベース・サーバー/RADIUSクライアントおよびRADIUSサーバーを経由して、スマートカードに含まれるログイン情報を認証サーバーに送信します。認証サーバーは、RADIUSサーバーおよびOracleデータベース・サーバーを経由してOracleクライアントにチャレンジを戻し、認証情報をユーザーに要求します。この情報は、PINやスマートカードに含まれている他の認証情報などです。

Oracleクライアントは、Oracleデータベース・サーバーおよびRADIUSサーバーを経由して、ユーザーのレスポンスを認証サーバーに送信します。ユーザーが有効な番号を入力した場合、認証サーバーはRADIUSサーバーおよびOracleデータベース・サーバーを経由して、受入れパケットをOracleクライアントに戻します。これでユーザーは認証され、適切な表やアプリケーションへのアクセスが認可されます。ユーザーが誤った情報を入力した場合、認証サーバーはユーザーのアクセスを拒否するメッセージを戻します。

例: ActivCardトークンによる非同期認証

ActivCardトークンの1つに、キーパッドを備えた、動的パスワードを表示するハンドヘルド・デバイスがあります。

ユーザーがパスワードを入力してOracleデータベース・サーバーにアクセスしようとすると、情報はOracleデータベース・サーバー/RADIUSクライアントおよびRADIUSサーバーを経由して、適切な認証サーバーに渡されます。認証サーバーは、RADIUSサーバーおよびOracleデータベース・サーバーを経由して、クライアントにチャレンジを戻します。ユーザーがそのチャレンジをトークンに入力すると、ユーザーがレスポンスで送信する番号がトークンに表示されます。

次に、Oracleクライアントは、Oracleデータベース・サーバーおよびRADIUSサーバーを経由して、ユーザーのレスポンスを認証サーバーに送信します。ユーザーが有効な番号を入力した場合、認証サーバーはRADIUSサーバーおよびOracleデータベース・サーバーを経由して、受入れパケットをOracleクライアントに戻します。これでユーザーは認証され、適切な表やアプリケーションへのアクセスが認可されます。ユーザーが誤ったレスポンスを入力した場合、認証サーバーはユーザーのアクセスを拒否するメッセージを戻します。

RADIUS認証、認可およびアカウンティングの有効化

RADIUS認証、認可およびアカウンティングを有効にするには、Oracle Net Managerを使用します。

内容は次のとおりです。

- 手順1: RADIUS認証の構成

- 手順2: ユーザーの作成とアクセス権の付与

- 手順3: 外部RADIUS認可の構成(オプション)

- 手順4: RADIUSアカウンティングの構成

- 手順5: RADIUSクライアント名のRADIUSサーバー・データベースへの追加

- 手順6: RADIUSとともに使用する認証サーバーの構成

- 手順7: 認証サーバーとともに使用するRADIUSサーバーの構成

- 手順8: マッピング・ロールの構成

手順1: RADIUS認証の構成

RADIUS認証を構成するには、Oracleクライアントで最初に認証を構成してからサーバーで構成する必要があります。その後、追加のRADIUS機能を構成できます。

内容は次のとおりです。

- 手順1A: OracleクライアントでのRADIUSの構成

- 手順1B: Oracleデータベース・サーバーでのRADIUSの構成

- 手順1C: その他のRADIUS機能の構成

注意:

特に示されていないかぎり、これらの構成タスクを実行するには、Oracle Net Managerを使用するか、任意のテキスト・エディタを使用してsqlnet.oraファイルを変更します。マルチテナント環境では、sqlnet.oraファイルの設定はすべてのプラガブル・データベース(PDB)に適用されることに注意してください。

手順1A: OracleクライアントでのRADIUSの構成

Oracle Net Managerを使用して、OracleクライアントでRADIUSを構成できます。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。
ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「認証」タブを選択します。(デフォルトで選択されています。)

5. 「使用可能なメソッド」リストから、RADIUSを選択します。

6. 右矢印(>)を選択して、RADIUSを「選択メソッド」リストに移動します。
使用するその他のメソッドを同じ方法で移動します。

7. 「選択メソッド」リストでメソッドを選択し、「上へ」または「下へ」をクリックしてリスト内での位置を指定して、選択したメソッドを使用に必要な順序に並べます。
たとえば、RADIUSをリストの最も上に置いて、使用される最初のサービスにします。

8. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。
sqlnet.oraファイルが次のエントリで更新されます。

SQLNET.AUTHENTICATION_SERVICES=(RADIUS)

手順1B: Oracleデータベース・サーバーでのRADIUSの構成

RADIUS鍵を保持するファイルを作成して、Oracleデータベース・サーバー上にこのファイルを格納する必要があります。次に、sqlnet.oraファイルで適切なパラメータを構成する必要があります。

内容は次のとおりです。

- 手順1B(1): Oracleデータベース・サーバーでのRADIUS秘密鍵ファイルの作成

- 手順1B(2): サーバー(sqlnet.oraファイル)でのRADIUSパラメータの構成

- 手順1B(3): Oracleデータベース・サーバー初期化パラメータの設定

手順1B(1): Oracleデータベース・サーバーでのRADIUS秘密鍵ファイルの作成

最初に、RADIUS秘密鍵ファイルを作成する必要があります。

1. RADIUSサーバーからRADIUS秘密鍵を取得します。
RADIUSクライアントごとに、RADIUSサーバーの管理者が共有秘密鍵を作成します。長さは16文字以下である必要があります。

2. Oracleデータベース・サーバーで、次のディレクトリを作成します。

- (UNIX) $ORACLE_HOME/network/security

- (Windows) ORACLE_BASE\ORACLE_HOME\network\security

3. RADIUSサーバーからコピーした共有シークレットを格納するために、ファイルradius.keyを作成します。このファイルを手順2で作成したディレクトリに配置します。

4. 共有秘密鍵をコピーし、この鍵のみを、Oracleデータベース・サーバーに作成したradius.keyファイルに貼り付けます。

5. セキュリティのために、radius.keyのファイル権限を読取り専用に変更し、Oracle所有者のみがアクセスできるようにします。
Oracleは、ファイル・システムに依存してこのファイルを秘密にします。

関連項目:

秘密鍵の取得の詳細は、RADIUSサーバーの管理ドキュメントを参照してください。

手順1B(2): サーバー(sqlnet.oraファイル)でのRADIUSパラメータの構成

RADIUS秘密鍵ファイルの作成後、sqlnet.oraファイルで適切なパラメータを構成します。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。
ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「認証」タブを選択します。

5. 「使用可能なメソッド」リストから、RADIUSを選択します。

6. 右矢印(>)を選択して、RADIUSを「選択メソッド」リストに移動します。

7. 選択したメソッドを使用に必要な順序に並べるには、「選択メソッド」リストでメソッドを選択し、「上へ」または「下へ」を選択してリスト内での位置を指定します。
たとえば、RADIUSを使用される最初のサービスにする場合は、リストの最も上に置きます。

8. 「その他のパラメータ」タブを選択します。

9. 「認証サービス」リストから、RADIUSを選択します。

10. 「ホスト名」フィールドで、デフォルトのプライマリRADIUSサーバーとしてlocalhostを受け入れるか、または別のホスト名を入力します。

11. 「シークレット・ファイル」フィールドのデフォルト値が有効であることを確認します。

12. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。
sqlnet.oraファイルは次のエントリで更新されます。

SQLNET.AUTHENTICATION_SERVICES=RADIUS
SQLNET.RADIUS_AUTHENTICATION=RADIUS_server_{hostname|IP_address}

注意:

IP_addressは、インターネット・プロトコル・バージョン4 (IPv4)またはインターネット・プロトコル・バージョン6 (IPv6)のアドレスです。RADIUSアダプタでは、IPv4ベースとIPv6ベースの両方のサーバーがサポートされています。

手順1B(3): Oracleデータベース・サーバー初期化パラメータの設定

sqlnet.oraファイルの構成後、init.ora初期化ファイルを構成する必要があります。

1. 次の設定をinit.oraファイルに追加します。

OS_AUTHENT_PREFIX=""

デフォルトでは、init.oraファイルは、LinuxおよびUNIXシステムの場合はORACLE_HOME/dbsディレクトリ(または同じデータ・ファイルの場所)、Windowsの場合はORACLE_HOME\databaseディレクトリにあります。

2. データベースを再起動します。
例:

SQL> SHUTDOWN
SQL> STARTUP

関連項目:

初期化パラメータの設定の詳細は、『Oracle Databaseリファレンス』を参照してください。

手順1C: その他のRADIUS機能の構成

必要に応じて、デフォルト設定を変更し、チャレンジ・レスポンス・モードを構成して、代替RADIUSサーバーのパラメータを設定できます。

内容は次のとおりです。

- 手順1C(1): デフォルト設定の変更

- 手順1C(2): チャレンジ・レスポンス・モードの構成

- 手順1C(3): 代替RADIUSサーバーのパラメータの設定

手順1C(1): デフォルト設定の変更

Oracle Net Managerを使用して、デフォルトのRADIUS設定を変更できます。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。
ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「その他のパラメータ」タブをクリックします。

5. 「認証サービス」リストから、RADIUSを選択します。

6. 次のフィールドについてデフォルト設定を変更します。

- ポート番号: プライマリRADIUSサーバーのリスニング・ポートを指定します。デフォルト値は1645です。

- タイムアウト(秒): Oracleデータベース・サーバーがプライマリRADIUSサーバーからの応答を待機する時間を指定します。デフォルトは15秒です。

- 再試行回数: Oracleデータベース・サーバーがプライマリRADIUSサーバーにメッセージを再送する回数を指定します。デフォルトは3回の再試行です。RADIUSアカウンティングの構成の詳細は、「手順4: RADIUSアカウンティングの構成」を参照してください。

- シークレット・ファイル: Oracleデータベース・サーバー上の秘密鍵の場所を指定します。このフィールドは、秘密鍵自体ではなく、秘密鍵ファイルの場所を指定します。秘密鍵の指定の詳細は、手順1B(1): Oracleデータベース・サーバーでのRADIUS秘密鍵ファイルの作成を参照してください。

7. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。
sqlnet.oraファイルは次のエントリで更新されます。

SQLNET.RADIUS_AUTHENTICATION_PORT=(PORT)
SQLNET.RADIUS_AUTHENTICATION_TIMEOUT=(NUMBER OF SECONDS TO WAIT FOR response)
SQLNET.RADIUS_AUTHENTICATION_RETRIES=(NUMBER OF TIMES TO RE-SEND TO RADIUS server)
SQLNET.RADIUS_SECRET=(path/radius.key)

手順1C(2): チャレンジ・レスポンス・モードの構成

チャレンジ・レスポンス・モードを構成するには、トークン・カードから取得する動的パスワードなどの情報を指定する必要があります。

RADIUSアダプタでは、このインタフェースはJavaベースであり、最適なプラットフォーム独立性を提供します。

注意:

認証デバイスのサード・パーティ・ベンダーは、その独自のデバイスに合せてこのグラフィカル・ユーザー・インタフェースをカスタマイズする必要があります。たとえば、スマートカード・ベンダーはJavaインタフェースをカスタマイズして、Oracleクライアントがスマートカードから動的パスワードなどのデータを読み取るようにします。スマートカードは、チャレンジを受け取ると、PINなどの追加情報をユーザーに要求することで応答します。

関連項目:

チャレンジ・レスポンス・ユーザー・インタフェースをカスタマイズする方法の詳細は、「RADIUSを使用した認証デバイスの統合」を参照してください

チャレンジ・レスポンス・モードの構成手順

1. JDK 1.1.7またはJRE 1.1.7を使用する場合は、JAVA_HOME環境変数を、Oracleクライアントが実行されるシステム上のJREまたはJDKの場所に設定します。

- UNIXでは、プロンプトで次のコマンドを入力します。

% setenv JAVA_HOME /usr/local/packages/jre1.1.7B

- Windowsでは、「スタート」→「設定」→「コントロール パネル」→「システム」→「環境」の順に選択し、JAVA_HOME変数を次のように設定します。

c:\java\jre1.1.7B

この手順は、他のJDK/JREバージョンでは必要ありません。

2. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

3. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

4. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。
ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

5. 「認証サービス」リストから、RADIUSを選択します。

6. 「チャレンジ・レスポンス」フィールドで、ONと入力してチャレンジ・レスポンスを有効にします。

7. 「デフォルト・キーワード」フィールドで、チャレンジのデフォルト値を受け入れるか、RADIUSサーバーからチャレンジを要求するためのキーワードを入力します。
キーワード機能は、Oracleから提供されており、一部のRADIUSサーバーでサポートされています(すべてではありません)。この機能は、RADIUSサーバーでサポートされている場合にのみ使用できます。

キーワードを設定することで、ユーザーはパスワードを使用しなくても識別情報を証明できます。ユーザーがパスワードを入力しない場合、ここで設定するキーワードがRADIUSサーバーに渡され、RADIUSサーバーは運転免許証の番号や生年月日などを要求するチャレンジで応答します。ユーザーがパスワードを入力する場合、RADIUSサーバーの構成に応じて、RADIUSサーバーはチャレンジで応答する場合と応答しない場合があります。

8. 「インタフェース・クラス名」フィールドで、デフォルト値DefaultRadiusInterfaceを受け入れるか、チャレンジ・レスポンス対話を処理するために作成したクラスの名前を入力します。
デフォルトのRADIUSインタフェース以外を使用する場合は、sqlnet.oraファイルを編集してSQLNET.RADIUS_CLASSPATH=(location)を入力する必要もあります(locationは、jarファイルの完全なパス名です)。これは、デフォルトでは$ORACLE_HOME/network/jlib/netradius.jar: $ORACLE_HOME/JRE/lib/vt.jarです。

9. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。
sqlnet.oraファイルは次のエントリで更新されます。

SQLNET.RADIUS_CHALLENGE_RESPONSE=([ON | OFF])
SQLNET.RADIUS_CHALLENGE_KEYWORD=(KEYWORD)
SQLNET.RADIUS_AUTHENTICATION_INTERFACE=(name of interface including the package name delimited by "/" for ".")

手順1C(3): 代替RADIUSサーバーのパラメータの設定

代替RADIUSサーバーを使用する場合、追加パラメータを設定する必要があります。

- sqlnet.oraファイルで次のパラメータを設定します。

SQLNET.RADIUS_ALTERNATE=(hostname or ip address of alternate radius server)
SQLNET.RADIUS_ALTERNATE_PORT=(1812)
SQLNET.RADIUS_ALTERNATE_TIMEOUT=(number of seconds to wait for response)
SQLNET.RADIUS_ALTERNATE_RETRIES=(number of times to re-send to radius server)

手順2: ユーザーの作成とアクセス権の付与

RADIUS認証の完了後、RADIUS構成に使用するOracle Databaseユーザーを作成する必要があります。

1. SQL*Plusを起動し、次の文を実行して、Oracleデータベース・サーバーで外部で識別されるユーザーを作成してアクセス権を付与します。

CONNECT system@database_name;
Enter password: password
CREATE USER username IDENTIFIED EXTERNALLY;
GRANT CREATE SESSION TO USER username;
EXIT

Windowsを使用する場合は、Oracle Enterprise ManagerのSecurity Managerツールを使用できます。

2. 同じusernameをRADIUSサーバーのusersファイルに入力します。

関連項目:

RADIUSサーバーの管理ドキュメント

手順3: 外部RADIUS認可の構成(オプション)

Oracleデータベースに接続するRADIUSユーザーに対して外部RADIUS認可が必要な場合は、Oracleサーバー、OracleクライアントおよびRADIUSサーバーを構成する必要があります。

内容は次のとおりです。

- 手順3A:Oracle Server (RADIUSクライアント)の構成

- 手順3B: Oracleクライアント(ユーザーがログインする場所)の構成

- 手順3C: RADIUSサーバーの構成

手順3A:Oracle Server (RADIUSクライアント)の構成

init.oraファイルを編集して、RADIUSクライアントのOracleサーバーを構成できます。

これを行うには、init.oraファイルを変更して、データベースを再起動し、RADIUSチャレンジ・レスポンス・モードを設定します。

1. OS_ROLESパラメータをinit.oraファイルに追加し、このパラメータを次のようにTRUEに設定します。

OS_ROLES=TRUE

デフォルトでは、init.oraファイルは、LinuxおよびUNIXシステムの場合はORACLE_HOME/dbsディレクトリ(または同じデータ・ファイルの場所)、Windowsの場合はORACLE_HOME\databaseディレクトリにあります。

2. init.oraファイルに対する変更がシステムに反映されるように、データベースを再起動します。
例:

SQL> SHUTDOWN
SQL> STARTUP

3. 手順1C(2): チャレンジ・レスポンス・モードの構成に記載されている手順に従って、サーバーのRADIUSチャレンジ・レスポンス・モードをONに設定していない場合は設定します。

4. 外部で識別されるユーザーおよびロールを追加します。

手順3B: Oracleクライアント(ユーザーがログインする場所)の構成

次に、ユーザーがログインするOracleクライアントを構成する必要があります。

- 手順1C(2): チャレンジ・レスポンス・モードの構成に記載されている手順に従って、クライアントのRADIUSチャレンジ・レスポンス・モードをONに設定していない場合は設定します。

手順3C: RADIUSサーバーの構成

RADIUSサーバーを構成するには、RADIUSサーバーの属性構成ファイルを変更する必要があります。

1. 次の属性をRADIUSサーバー属性構成ファイルに追加します。

属性名

コード

型

VENDOR_SPECIFIC

26

整数

ORACLE_ROLE

1

文字列

2. SMIネットワーク管理プライベート・エンタープライズ・コード111が含まれているRADIUSサーバー属性構成ファイルで、OracleのベンダーIDを割り当てます。
たとえば、RADIUSサーバー属性構成ファイルに次のように入力します。

VALUE VENDOR_SPECIFIC ORACLE 111

3. 次の構文を使用して、ORACLE_ROLE属性を外部RADIUS認可を使用するユーザーのユーザー・プロファイルに追加します。
ORA_databaseSID_rolename[_[A]|[D]]

詳細は、次のとおりです。

- ORAは、このロールをOracle用に使用することを指定します。

- databaseSIDは、データベースのinit.oraファイル内で構成されているOracleシステム識別子です。
デフォルトでは、init.oraファイルは、LinuxおよびUNIXシステムの場合はORACLE_HOME/dbsディレクトリ(または同じデータ・ファイルの場所)、Windowsの場合はORACLE_HOME\databaseディレクトリにあります。

- rolenameは、データ・ディクショナリで定義されているロール名です。

- Aは、ユーザーがこのロールの管理者の権限を持つことを示すオプションの文字です。

- Dは、このロールをデフォルトで有効にすることを示すオプションの文字です。

OracleロールにマップされるRADIUSグループが、ORACLE_ROLEの構文に準拠していることを確認します。

例:

USERNAME     USERPASSWD="user_password",
SERVICE_TYPE=login_user,
VENDOR_SPECIFIC=ORACLE,
ORACLE_ROLE=ORA_ora920_sysdba

関連項目:

サーバーの構成の詳細は、RADIUSサーバーの管理ドキュメントを参照してください。

手順4:RADIUSアカウンティングの構成

RADIUSアカウンティングは、Oracleデータベース・サーバーへのアクセスに関する情報をログに記録し、RADIUSアカウンティング・サーバー上のファイルに格納します。この機能は、RADIUSサーバーと認証サーバーの両方でサポートされている場合にのみ使用します。

内容は次のとおりです。

- 手順4A: Oracleデータベース・サーバーでのRADIUSアカウンティングの設定

- Step 4B: RADIUSアカウンティング・サーバーの構成

手順4A: Oracleデータベース・サーバーでのRADIUSアカウンティングの設定

RADIUSアカウンティングをサーバーで設定するには、Oracle Net Managerを使用します。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。
ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「その他のパラメータ」タブを選択します。

5. 「認証サービス」リストから、RADIUSを選択します。

6. 「アカウンティングの送信」フィールドで、アカウンティングを有効にするにはONと入力し、無効にするにはOFFと入力します。

7. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。
sqlnet.oraファイルが次のエントリで更新されます。

SQLNET.RADIUS_SEND_ACCOUNTING= ON

Step 4B: RADIUSアカウンティング・サーバーの構成

RADIUSアカウンティング・サーバーは、RADIUS認証サーバーと同じホストまたは別のホストにあります。

- RADIUSアカウンティングの構成の詳細は、RADIUSサーバーの管理ドキュメントを参照してください。

手順5: RADIUSクライアント名のRADIUSサーバー・データベースへの追加

選択するRADIUSサーバーは、RADIUS標準に従う必要があります。

Internet Engineering Task Force (IETF) RFC #2138 Remote Authentication Dial In User Service (RADIUS)およびRFC #2139 RADIUS Accountingの規格に準拠するRADIUSサーバーを使用できます。RADIUSサーバーには様々なものがあるため、固有の相互運用性要件について、使用するRADIUSサーバーのドキュメントで確認してください。

RADIUSクライアント名をLivingston RADIUSサーバーに追加する手順:

1. /etc/raddb/clientsにあるclientsファイルを開きます。
次のテキストと表が表示されます。

@ (#) clients 1.1 2/21/96 Copyright 1991 Livingston Enterprises Inc
This file contains a list of clients which are allowed to make authentication requests and their encryption key. The first field is a valid hostname. The second field (separated by blanks or tabs) is the encryption key.
Client Name                     Key

2. CLIENT NAME列に、Oracleデータベース・サーバーが実行されているホストのホスト名またはIPアドレスを入力します。
KEY列に、共有シークレットを入力します。

CLIENT NAME列に入力する値は、クライアントの名前かIPアドレスかにかかわらず、RADIUSサーバーによって異なります。

3. clientsファイルを保存して閉じます。

関連項目:

RADIUSサーバーの管理ドキュメント

手順6: RADIUSとともに使用する認証サーバーの構成

RADIUSクライアント名をRADIUSサーバー・データベースに追加した後、RADIUSを使用するように認証サーバーを構成できます。

- 認証サーバーの構成の詳細は、認証サーバーのドキュメントを参照してください。

手順7: 認証サーバーとともに使用するRADIUSサーバーの構成

RADIUSで使用するように認証サーバーを構成した後、その認証サーバーを使用するようにRADIUSサーバーを構成できます。

- 認証サーバーで使用するRADIUSサーバーの構成の詳細は、RADIUSサーバーのドキュメントを参照してください。

手順8: マッピング・ロールの構成

RADIUSサーバーでベンダー・タイプ属性がサポートされている場合は、ロールをRADIUSサーバーに格納して管理できます。

RADIUSを使用したCONNECT要求があると、Oracleデータベース・サーバーはロールをダウンロードします。この機能を使用するには、Oracleデータベース・サーバーおよびRADIUSサーバーの両方でロールを構成する必要があります。

1. テキスト・エディタを使用して、Oracleデータベース・サーバーの初期化パラメータ・ファイルでOS_ROLESパラメータを設定します。
デフォルトでは、init.oraファイルは、LinuxおよびUNIXシステムの場合はORACLE_HOME/dbsディレクトリ(または同じデータ・ファイルの場所)、Windowsの場合はORACLE_HOME\databaseディレクトリにあります。

2. Oracleデータベース・サーバーを停止して再起動します。
例:

SHUTDOWN
STARTUP

3. RADIUSサーバーがOracleデータベース・サーバー上で管理する各ロールを、値IDENTIFIED EXTERNALLYを使用して作成します。
RADIUSサーバーでロールを構成するには、次の構文を使用します。

ORA_DatabaseName.DatabaseDomainName_RoleName

次のように値を指定します。

- DatabaseNameは、ロールが作成されているOracleデータベース・サーバーの名前です。これは、DB_NAME初期化パラメータの値と同じです。

- DatabaseDomainNameは、Oracleデータベース・サーバーが属するドメインの名前です。この値は、DB_DOMAIN初期化パラメータの値と同じです。

- RoleNameは、Oracleデータベース・サーバーで作成されたロールの名前です。

例:

ORA_USERDB.US.EXAMPLE.COM_MANAGER

4. RADIUSチャレンジ・レスポンス・モードを構成します。

関連項目:

- チャレンジ・レスポンス(非同期)認証モード

- 手順1C(2): チャレンジ・レスポンス・モードの構成

RADIUSを使用したデータベースへのログイン

RADIUSを使用してデータベースにログインするには、同期認証モードまたはチャレンジ・レスポンス・モードのいずれかを使用します。

- SQL*Plusを起動して、次のいずれかの方法でデータベースにログインします。

- 同期認証モードを使用する場合は、最初にチャレンジ・レスポンス・モードがONになっていないことを確認して、次のコマンドを入力します。

CONNECT username@database_alias
Enter password: password

- チャレンジ・レスポンス・モードを使用する場合は、チャレンジ・レスポンス・モードがONに設定されていることを確認して、次のコマンドを入力します。

CONNECT /@database_alias

注意:

チャレンジ・レスポンス・モードは、ログインのすべてのケースについて構成できます。

RSA ACE/Server構成チェックリスト

RSA ACE/ServerをRADIUSサーバーとして使用している場合は、最初の接続の前にRSA ACE/Serverのホスト・エージェントおよびSecurIDトークンをチェックしてください。

- ノード・シークレットを送信するようにRSA ACE/Serverのホスト・エージェントが設定されていることを確認します。バージョン5.0では、これを行うには「SENT Node secret」ボックスの選択を解除したままにします。RSA ACE/Serverがエージェントへのノード・シークレットの送信に失敗した場合は、ノード検証失敗メッセージがRSA ACE/Serverのログに書き込まれます。

- RSA SecurIDトークンを使用している場合は、トークンがRSA ACE/Serverと同期されていることを確認します。

関連項目:

トラブルシューティングの詳細は、RSA ACE/Serverのドキュメントを参照してください。

20 厳密認証の使用のカスタマイズ

Oracle Databaseのネットワーク暗号化および厳密認証のもとで、複数の認証方法を構成できます。

内容は次のとおりです。

- 厳密認証を使用したデータベースへの接続

- 厳密認証およびネットワーク暗号化の無効化

- 複数の認証方式の構成

- 外部認証のためのOracle Databaseの構成

厳密認証を使用したデータベースへの接続

パスワード認証を使用して、厳密認証を使用するように構成されたデータベースに接続できます。

1. Oracleネットワークおよび厳密認証方式が構成されている場合に、ユーザー名とパスワードを使用してOracleデータベース・サーバーに接続するには、外部認証を無効化します。
Oracleネットワークおよび厳密認証方式が構成されている場合、ユーザー名とパスワードを使用してOracle Databaseサーバーに接続する前に、最初に「厳密認証およびネットワーク暗号化の無効化」の手順に従って外部認証を無効にする必要があります。

2. 外部認証を無効化し、次の形式を使用してデータベースに接続します。

% sqlplus username@net_service_name
Enter password: password

例:

% sqlplus hr@emp
Enter password: password

注意:

単一データベースに、外部認証ユーザーとパスワード認証ユーザーの両方を含む複数の認証方式を構成できます。

厳密認証およびネットワーク暗号化の無効化

Oracle Net Managerを使用して、厳密認証およびネットワーク暗号化を無効にすることができます。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。

ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「認証」タブ(デフォルトで選択されています)を選択します。

5. 「選択メソッド」リスト内の認証方式を順番に選択して左矢印[<]をクリックすることによって「使用可能なメソッド」リストにすべて移動します。

6. 「暗号化」タブを選択します。

7. 次を実行します。

- 「暗号化」メニューから、SERVERを選択します。

- 「暗号化タイプ」をrejectedに設定します。

- 「暗号化シード」フィールドで、暗号化シードが使用された場合の有効な暗号化シードを入力します。

- 「メソッドの選択」で、任意のメソッドを「使用可能なメソッド」フィールドに移動します。

8. これらの手順を繰り返します。「暗号化」メニューからCLIENTを選択して、クライアントのネットワーク暗号化を無効にします。

9. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。

sqlnet.oraファイルは、厳密認証およびネットワーク暗号化が無効化されていることを示す次のエントリで更新されます。

厳密認証:

SQLNET.AUTHENTICATION_SERVICES = (NONE)

ネットワーク暗号化の場合、サーバー側およびクライアント側に個別に設定できます。次の例では、サーバーとクライアントの両方で無効化されているネットワーク暗号化を示します。

SQLNET.ENCRYPTION_SERVER = REJECTED
SQLNET.ENCRYPTION_CLIENT = REJECTED

マルチテナント環境では、sqlnet.oraファイルの設定はすべてのプラガブル・データベース(PDB)に適用されることに注意してください。

関連トピック

- 暗号化および整合性のネゴシエーションの値について

複数の認証方式の構成

多くのネットワークにおいて、単一のセキュリティ・サーバーで複数の認証方式が使用されています。

そのため、Oracle Databaseでは、Oracleクライアントが特定の認証方式を使用できるように、および、Oracleデータベース・サーバーが指定された任意の方式を受け入れることができるように、ネットワークを構成できます。

Oracle Net Managerを使用するか、または任意のテキスト・エディタを使用してsqlnet.oraファイルを変更することによって、クライアント・システムとサーバー・システムの両方で複数の認証方式を設定できます。クライアントとサーバーの両方に認証方式を追加するには、Oracle Net Managerを使用します。

1. Oracle Net Managerを起動します。

- (UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。

netmgr

- (Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。

2. 「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。

3. 「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。

ネットワーク・セキュリティのタブ付きウィンドウが表示されます。

4. 「認証」タブを選択します。

5. 「使用可能なメソッド」リストに一覧表示されている方式を選択します。

6. 右矢印(>)をクリックして、選択した方式を順番に「選択メソッド」リストに移動します。

7. 選択した方式を目的の利用順に並べます。

そのためには、「選択メソッド」リストで方式を選択し、「上へ」または「下へ」を選択してリスト内での位置を変更します。

8. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。

sqlnet.oraファイルが次のエントリで更新され、選択した認証方式が一覧表示されます。

SQLNET.AUTHENTICATION_SERVICES = (KERBEROS5, RADIUS)

注意:

SecurID機能はRADIUSによって提供されます。RADIUSサポートはRSA ACE/Serverに組み込まれています。

関連項目:

詳細は、RADIUS認証の構成を参照してください

外部認証のためのOracle Databaseの構成

パラメータを使用して、ネットワーク認証を使用するようにOracle Databaseを構成できます。

内容は次のとおりです。

- sqlnet.oraでのSQLNET.AUTHENTICATION_SERVICESパラメータの設定

- OS_AUTHENT_PREFIXのNull値への設定

関連項目:

- 特定の認証方式を構成する方法の詳細は、このガイドの該当する章を参照してください。

- Kerberos、SSLおよびRADIUS認証パラメータ

sqlnet.oraでのSQLNET.AUTHENTICATION_SERVICESパラメータの設定

SQLNET.AUTHENTICATION_SERVICESパラメータでは、使用する認証方式とバージョンを定義します。

すべてのクライアントおよびサーバーで、サポートされている認証方式をそれぞれが使用できるようにするには、sqlnet.oraファイルでSQLNET.AUTHENTICATION_SERVICESパラメータを設定する必要があります。

- 次の構文を使用して、SQLNET.AUTHENTICATION_SERVICESパラメータを設定します。

SQLNET.AUTHENTICATION_SERVICES=(oracle_authentication_method)

たとえば、すべてのクライアントとサーバーがKerberos認証を使用する場合は次のようにします。

SQLNET.AUTHENTICATION_SERVICES=(KERBEROS5)

デフォルトでは、sqlnet.oraファイルは、ORACLE_HOME/network/adminディレクトリ、またはTNS_ADMIN環境変数によって設定されている場所にあります。TNS_ADMIN変数が正しいsqlnet.oraファイルを指定するように適切に設定されていることを確認します。

関連項目:
TNS_ADMIN変数の詳細および設定例は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください

OS_AUTHENT_PREFIXのNull値への設定

OS_AUTHENT_PREFIXパラメータでは、Oracle Databaseがサーバーに接続しようとするユーザーの認証に使用する接頭辞を指定します。

認証サービス・ベースのユーザー名は長くてもかまいませんが、Oracleユーザー名は30文字までに制限されています。OS_AUTHENT_PREFIXパラメータをnull値に設定することを強くお薦めします。

- データベース・インスタンスの初期化ファイルで、OS_AUTHENT_PREFIXを次のように設定します。

OS_AUTHENT_PREFIX=""

注意:

- OS_AUTHENT_PREFIXのデフォルト値はOPS$ですが、任意の文字列に設定できます。

- データベースでOS_AUTHENT_PREFIXの値がすでにNULL (" ")以外に設定されている場合は、変更しないでください(変更すると、以前に作成され、外部で識別されたユーザーがOracleサーバーに接続できなくなる可能性があります)。

OS_AUTHENT_PREFIXをnullに設定した後、次の構文を使用して外部ユーザーを作成できます。

CREATE USER os_authent_prefix_username IDENTIFIED EXTERNALLY;

たとえば、ユーザーkingを作成するとします。

CREATE USER king IDENTIFIED EXTERNALLY;

このようにユーザーを作成すると、外部で識別されたユーザーの様々なユーザー名の管理が不要になるという利点があります。これは、サポートされているすべての認証方式に当てはまります。

第VI部 監査を使用したデータベース・アクティビティの管理

第VI部では、監査を使用したデータベース・アクティビティの監視方法について説明します。

- 監査の概要

- 監査ポリシーの構成

- 監査証跡の管理

21 監査の概要

監査は、ユーザーがデータベースで行う変更を追跡します。

内容は次のとおりです。

- 監査とは

- 監査を使用する理由

- 監査のベスト・プラクティス

- 統合監査とは

- 統合監査証跡の利点

- データベースが統合監査に移行したかどうかの確認

- 混合モードの監査

- 監査の実行者

- マルチテナント環境での監査

- 分散データベースでの監査

注意:

この章では、すべての監査レコードが一元管理される完全な統合監査の使用方法について説明します。統合監査を使用するためにまだ移行していない場合は、『Oracle Databaseアップグレード・ガイド』を参照してください。アップグレード・プロセス自体では、統合監査が自動的に有効にならないことに注意してください。『Oracle Databaseアップグレード・ガイド』に説明に従って、統合監査に手動で移行する必要があります。

関連項目:

システム監査の際に従う一般的なガイドラインは、「監査に関するガイドライン」を参照してください。

監査とは

監査とは、構成済のデータベース・アクション(データベース・ユーザーと非データベース・ユーザーの両方からのアクション)を監視して記録することです。

非データベース・ユーザーとは、CLIENT_IDENTIFIER属性を使用してデータベースで認識されるアプリケーション・ユーザーのことです。ユーザーのこの対応を監査する場合は、統合監査ポリシー条件、ファイングレイン監査ポリシー、またはOracle Database Real Application Securityを使用できます。

実行されたSQL文のタイプなどの個々のアクション、またはユーザー名、アプリケーション、時間などの様々なデータの組合せをベースとして使用できます。

成功したアクティビティと失敗したアクティビティの両方の監査が可能で、特定のユーザーを監査対象に含めたり、除外したりできます。マルチテナント環境では、プラガブル・データベース(PDB)の個々のアクション、またはマルチテナント・コンテナ・データベース(CDB)全体の個々のアクションを監査できます。データベースで提供される標準のアクティビティの監査に加えて、監査には、Oracle Database Real Application Security、Oracle Recovery Manager、Oracle Data Pump、Oracle Data Mining、Oracle Database Vault、Oracle Label SecurityおよびOracle SQL*Loaderダイレクト・パス・イベントからのアクティビティを含めることができます。

監査はデフォルトで有効です。すべての監査レコードは、同一の形式で統合監査証跡に書き込まれ、UNIFIED_AUDIT_TRAILビューから使用できます。これらのレコードはAUDSYSスキーマにあります。監査レコードは、デフォルトでSYSAUX表領域に格納されます。統合監査証跡のために別の表領域を構成することをお薦めします。Enterprise Editionを除くほとんどのOracle Databaseエディションでは、統合監査の表領域の関連付けは1回のみになります。この関連付けは、統合監査証跡の監査レコードを生成する前に行う必要があります。表領域を関連付けると、Enterprise Editionではパーティション化のみがサポートされるため、表領域を変更できません。

次のいずれかの方法を使用して監査を構成できます。

- 監査設定を1つの統合監査ポリシーにグループ化する。データベースで必要なすべての監査設定を定義する統合監査ポリシーを1つ以上作成できます。これを実行する方法は、統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査に説明されています。

- デフォルトの統合監査ポリシーのいずれかを使用する。Oracle Databaseでは、一般的な機関で必要な標準の監査設定に対応したデフォルトの統合監査ポリシーが3つ用意されています。事前定義の統合監査ポリシーを使用したアクティビティの監査を参照してください。

- ファイングレイン監査ポリシーを作成する。アクションの発生時刻などのデータを取得するファイングレイン監査ポリシーを作成できます。ファイングレイン監査を使用した特定のアクティビティの監査を参照してください。

データベースを監査することをお薦めします。監査は、強固な内部制御を規定する有効な方法であるため、サイトでは米国サーベンス・オクスリー法(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)

監査のベスト・プラクティス

ベスト・プラクティスに関するガイドラインに従ってください。

- 原則として、法令順守要件を満たすために必要な量の情報を収集するように監査方針を策定しますが、大きなセキュリティ問題の原因となるアクティビティに焦点を合せてください。たとえば、データベース内のすべての表を監査するのではなく、給与など機密性の高いデータが入った表列を監査するのが実用的です。統合監査とファイングレイン監査の両方により、監査対象の特定のアクティビティに焦点を合せた監査ポリシーの策定に使用できるメカニズムがあります。

- 監査証跡データを定期的にアーカイブして削除します。詳細は、監査証跡レコードの削除を参照してください。

関連項目:

システム監査の際に従う一般的なガイドラインは、監査に関するガイドラインを参照してください

統合監査とは

統合監査では、統合監査証跡により、次の各種ソースから監査情報が取得されます。

統合監査では、次のソースから監査レコードを取得できます。

- 統合監査ポリシーおよびAUDIT設定による監査レコード(SYS監査レコードを含む)

- DBMS_FGA PL/SQLパッケージによるファイングレイン監査レコード

- Oracle Database Real Application Security監査レコード

- Oracle Recovery Manager監査レコード

- Oracle Database Vault監査レコード

- Oracle Label Security監査レコード

- Oracle Data Miningのレコード

- Oracle Data Pump

- Oracle SQL*Loaderダイレクト・ロード

統合監査証跡は、SYSAUX表領域のAUDSYSスキーマの読取り専用の表にあり、この情報をUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューで同一の形式で使用できるようにし、単一インスタンスおよびOracle Database Real Application Clustersの両方の環境で使用できます。ユーザーSYSに加えて、AUDIT_ADMINおよびAUDIT_VIEWERロールが付与されているユーザーもこれらのビューを問い合せることができます。ユーザーが監査ポリシーの作成ではなく、ビューの問合せのみを必要としている場合は、AUDIT_VIEWERロールを付与します。

データベースが書込み可能な場合、監査レコードは統合監査証跡に書き込まれます。データベースが書込み可能でない場合、監査レコードは$ORACLE_BASE/audit/$ORACLE_SIDディレクトリの新しい形式のオペレーティング・システム・ファイルに書き込まれます。

関連項目:

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

統合監査証跡の利点

統合監査証跡には、次のように多くの利点があります。

次に例を示します。

- 統合監査の有効化後、以前のリリースで使用されていた初期化パラメータには依存しません。これらの初期化パラメータのリストは、表G-1を参照してください。

- SYS監査証跡のレコードを含む、Oracle Databaseインストールのすべての監査コンポーネントの監査レコードは、1つの場所に1つの形式で配置されるため、様々な場所を参照して各種形式の監査証跡を探す必要はありません。この統合ビューにより、監査者は様々なコンポーネントから監査情報を相互に関連付けることができます。たとえば、INSERT文の実行中にエラーが発生した場合は、標準の監査でエラー番号と実行されたSQLを示すことができます。Oracle Database Vault固有の情報では、このエラーがコマンド・ルール違反またはレルム違反のどちらの原因で発生したかを示すことができます。別のAUDIT_TYPEの監査レコードが2つあります。この統合を適切に設定すると、AUDIT_TYPEがStandard Auditに設定されたSYS監査レコードが表示されます。

- 監査証跡の管理とセキュリティは、監査証跡を単一にすることでも改善されます。

- 監査の全体的なパフォーマンスが大幅に向上します。デフォルトでは、監査レコードがAUDSYSスキーマの内部リレーショナル表に自動的に書き込まれます。

- SYS管理ユーザーだけでなく、サポートされているコンポーネント(この項の最初に記載)を各自で監査できる名前付きの監査ポリシーを作成できます。さらに、条件と除外を各自のポリシーに作成することもできます。

- Oracle Audit Vault and Database Firewall環境を使用している場合は、このデータがすべて1つの場所から取得されるため、統合監査証跡により、監査データの収集がかなり容易になります。詳細は、『Oracle Audit Vault and Database Firewall管理者ガイド』を参照してください。

データベースが統合監査に移行したかどうかの確認

V$OPTION動的ビューは、データベースが統合監査に移行されたかどうかを示します。

- 次に示すようにUnified Auditingを入力して、V$OPTION動的ビューのVALUE列を問い合せます。

SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';

PARAMETER         VALUE
----------------  ----------
Unified Auditing  TRUE

この出力には、統合監査が有効であることが表示されます。統合監査が有効でない場合、出力はFALSEになります。

関連項目:

統合監査を無効にする必要がある場合は、統合監査の無効化を参照してください

混合モードの監査

混合モードの監査は、新しくインストールしたデータベースでのデフォルトの監査です。

内容は次のとおりです。

- 混合モードの監査について

- 有効にした監査のタイプがデータベースの作成でどのように決定されるか

- 混合モードの監査の機能

混合モードの監査について

混合モード監査では、従来の監査機能(リリース12cより前のリリースの監査機能)と新しい監査機能(統合監査)の両方を使用できます。

データベースは2つのモード(混合モード監査または完全な統合監査モード)のいずれでも有効にできます。これらのどちらのモードでも統合監査の機能は有効になりますが、両者に違いがあります。混合モードでは、新しい統合監査機能を従来の監査機能と並行して使用できます。完全な統合監査では、統合監査機能のみ使用します。

表21-1に、これらの2つのモードの機能とその有効化の方法のサマリーを示します。

表21-1 混合モード監査と完全な統合監査の違い

モード

機能

有効化する方法

混合モードの監査

従来の監査と統合監査の両方

任意の統合監査ポリシーを有効にします。データベースを再起動する必要はありません。

完全な統合監査

統合監査のみ

oracleバイナリをuniaud_onにリンクし、データベースを再起動します。

混合モードは統合監査を導入するためのもので、その機能や特徴、利点を知ることができます。混合モードで、統合監査を使用するように既存のアプリケーションおよびスクリプトを移行することができます。完全な統合監査を使用することにしたら、統合監査オプションを有効にしてoracleバイナリを再リンクし、統合監査をOracleデータベースで実行する唯一の監査機能として有効にします。混合モードに戻す必要がある場合は戻すことができます。

以前のリリース同様、従来の監査機能は、AUDIT_TRAIL初期化パラメータの影響を受けます。混合モードの監査の場合のみ、このパラメータを対応する従来の監査証跡に設定する必要があります。この従来の監査証跡には、統合監査証跡とともに、監査レコードが移入されます。

データベースを現在のリリースにアップグレードすると、従来の監査が保存され、新規監査レコードが従来の監査証跡に書き込まれます。移行(『Oracle Databaseアップグレード・ガイド』で説明)の完了後も、以前のリリースの監査レコードはこれらの監査証跡で引き続き使用可能です。企業の保存ポリシーに基づき、DBMS_AUDIT_MGMT PL/SQLプロシージャを使用して、これらの古い監査証跡をアーカイブして削除できます。

関連項目:

- 移行前と移行後の監査環境での機能の可用性の比較は、統合監査の移行による各監査機能への影響を参照してください

- データベースが統合監査に移行したかどうかの確認

- データベースを統合監査に移行する方法と、移行しない場合に使用するドキュメントは、『Oracle Databaseアップグレード・ガイド』を参照してください。

有効にした監査のタイプがデータベースの作成でどのように決定されるか

統合監査では、新しい形式のオペレーティング・システム・ファイルの場所として、$ORACLE_BASE/auditディレクトリが使用されます。

新しく作成されたデータベースでは、事前定義のポリシーORA_SECURECONFIGにより、混合モードの監査がデフォルトで有効になります。

統合監査の使用を開始するには、少なくとも1つの統合監査ポリシーを有効にし、その使用を停止するには、すべての統合監査ポリシーを無効にする必要があります。

関連項目:

ORA_SECURECONFIGポリシーの詳細は、セキュア・オプションの事前定義の統合監査ポリシーを参照してください

混合モードの監査の機能

混合モードの監査では、次の機能が提供されます。

これらの機能は次のとおりです。

- 既存の監査初期化パラメータのAUDIT_TRAIL、AUDIT_FILE_DEST、AUDIT_SYS_OPERATIONSおよびAUDIT_SYSLOG_LEVELをすべて使用できるようにします。

- 従来の監査証跡に必須の監査レコードのみを書き込みます。

- 標準の監査レコードを標準の監査構成に基づくようにし、AUDIT_TRAIL初期化パラメータで指定された監査証跡にこれらのレコードを書き込みます。
ただし。標準の監査証跡レコードは統合監査ポリシーに基づいても生成され、これらの監査レコードのみが統合監査証跡に書き込まれることに注意してください。統合監査ポリシーの結果として生成された標準の監査レコードは、統合監査ポリシーの有効化のセマンティクスに従います。

- 管理ユーザー・セッションにより、SYS監査レコードが生成されます。これらのレコードは、AUDIT_SYS_OPERATIONS初期化パラメータがTRUEに設定されている場合に書き込まれます。このプロセスでは、レコードは従来の監査証跡のみに書き込まれます。ただし、統合監査ポリシーが管理ユーザーで有効な場合は、これらの統合監査レコードも統合監査証跡に書き込まれます。

- 従来の監査証跡に書き込まれる監査レコードの形式は、Oracle Database 11gリリース2と同じままです。

- デフォルトでは、Oracle Databaseで統合監査レコードがシステム・グローバル領域(SGA)キューに書き込まれます。つまり、レコードは即座にではなく定期的に書き込まれます。監査レコードが書き込まれる間隔を制御することはできません。詳細は、AUDSYSスキーマへの統合監査証跡レコードの書込みを参照してください。

- 監査レコードの書込みのパフォーマンス・コストは、監査レコードを生成して従来の監査証跡と統合監査証跡に書き込むのに必要な総時間と同等です。

- 混合モードの監査は、統合監査モードの機能の一部です。新しい形式の監査ポリシーと監査証跡に問題ない場合は、統合監査モードに移行することをお薦めします。統合監査に移行するには、『Oracle Databaseアップグレード・ガイド』を参照してください。

監査の実行者

Oracleでは監査を実行するユーザー用にAUDIT_ADMINとAUDIT_VIEWERという2つのロールが用意されています。

任意の種類の監査を実行するには、AUDIT_ADMINロールが付与されている必要があります。監査者は、AUDIT_VIEWERロールが付与された後に監査データを表示できます。

これらのロールによって提供される権限を次に示します。

- AUDIT_ADMINロール。このロールでは、統合およびファイングレイン監査ポリシーの作成、AUDITおよびNOAUDIT SQL文の使用、監査データの表示、および監査証跡の管理が可能です。このロールは、信頼できるユーザーにのみ付与します。

- AUDIT_VIEWERロール。このロールでは、ユーザーによる監査データの表示と分析が可能です。このロールが必要なユーザーの種類は、通常は外部監査者です。

注意:

以前のリリースでは、ユーザーは、追加の権限なしで、各自のスキーマのオブジェクトへの監査構成の追加と削除が許可されていました。この機能は使用できなくなりました。

マルチテナント環境での監査

統合監査をマルチテナント環境で使用できます。

ポリシーのタイプに応じて、各PDBに監査設定を適用したり、CDB全体に監査設定を適用できます。マルチテナント環境では、ルートを含むPDBにそれぞれ独自の統合監査証跡があります。

詳細は、次の各項を参照してください。

- CREATE AUDIT POLICYおよびAUDIT文で作成された統合監査ポリシー: ルートと個々のPDBの両方のポリシーを作成できます。「マルチテナント環境での統合監査ポリシーまたはAUDIT設定の使用」を参照してください。

- ファイングレイン監査ポリシー: ルートではなく、個々のPDBのポリシーのみを作成できます。「ファイングレイン監査ポリシーの作成」を参照してください

- 監査証跡の削除: ルートと個々のPDBの両方に対して、削除操作を実行できます。「監査証跡レコードの削除」を参照してください。

関連項目:

マルチテナント環境での一般的な監査構成の詳細は、『Oracle Database概要』を参照してください。

分散データベースでの監査

データベース・インスタンスでは直接接続しているユーザーによって発行された文のみが監査されるため、監査はサイトで自律的に実行されるといえます。

ローカルのOracle Databaseノードでは、リモート・データベースで発生するアクションを監査できません。

22 監査ポリシーの構成

統合監査を構成するには、カスタム統合監査ポリシーを作成するか、事前定義の統合監査ポリシーを使用するか、ファイングレイン監査を使用します。

内容は次のとおりです。

- 監査タイプの選択

- 統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査

- 事前定義の統合監査ポリシーを使用したアクティビティの監査

- ファイングレイン監査を使用した特定のアクティビティの監査

- 監査ポリシーのデータ・ディクショナリ・ビュー

監査タイプの選択

実行する監査のタイプ、つまり一般アクティビティ(SQL文のアクションなど)、一般的に使用される監査アクティビティまたはファイングレイン監査に応じて、特定の手順を実行する必要があります。

これらのタイプの監査に加えて、Oracle Databaseではいくつかのアクティビティを強制的に監査します。詳細は、強制的に監査されるアクティビティを参照してください。

内容は次のとおりです。

- SQL文、権限および他の一般アクティビティの監査

- 一般的に使用されるセキュリティ関連アクティビティの監査

- 特定のファイングレイン・アクティビティの監査

SQL文、権限および他の一般アクティビティの監査

SQL文やOracle Database VaultなどのOracle Databaseコンポーネントまで、様々なタイプのオブジェクトを監査できます。

また、条件を使用するポリシーも作成できます。ただし、特定の列を監査したり、イベント・ハンドラを使用する場合は、ファイングレイン監査を使用する必要があります。

このタイプの監査を実行する一般的な手順は次のとおりです。

1. ほとんどの場合は、CREATE AUDIT POLICY文を使用して監査ポリシーを作成します。アプリケーション・コンテキスト値を監査する必要がある場合は、AUDIT文を使用します。

統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査の関連するカテゴリを参照してください。

2. 監査ポリシーを作成する場合は、AUDIT文を使用して有効にし、オプションで、SYSDBA管理権限でログインする管理ユーザー(SYSなど)を含む、1人以上のユーザーに監査設定を適用(または除外)します。

AUDITでは、アクションの成功または失敗(あるいは両方)時に監査レコードを作成することもできます。

「ユーザーに対する統合監査ポリシーの有効化」を参照してください

3. UNIFIED_AUDIT_TRAILビューを問い合せ、生成された監査レコードを検索します。

追加のビューについては、監査ポリシーのデータ・ディクショナリ・ビューも参照してください。

4. 監査証跡の内容を定期的にアーカイブして削除します。

「監査証跡レコードの削除」を参照してください。

一般的に使用されるセキュリティ関連アクティビティの監査

Oracle Databaseには、デフォルトの統合監査ポリシーが用意されており、これらは一般的に使用されるセキュリティ関連の監査用に選択できます。

このタイプの監査を実行する一般的な手順は次のとおりです。

1. デフォルトの監査ポリシーの詳細は、事前定義の統合監査ポリシーを使用したアクティビティの監査を参照してください。

2. AUDIT文を使用してポリシーを有効にし、1人以上のユーザーに監査設定をオプションで適用(または除外)します。

「ユーザーに対する統合監査ポリシーの有効化」を参照してください

3. UNIFIED_AUDIT_TRAILビューを問い合せ、生成された監査レコードを検索します。

追加のビューについては、監査ポリシーのデータ・ディクショナリ・ビューも参照してください。

4. 監査証跡の内容を定期的にアーカイブして削除します。

「監査証跡レコードの削除」を参照してください。

特定のファイングレイン・アクティビティの監査

個々の列を監査またはイベント・ハンドラを使用する場合は、ファイングレイン監査を使用します。

このタイプの監査では、統合監査ポリシーで使用可能なすべての機能が提供されます。

ファイングレイン監査を実行する一般的な手順は次のとおりです。

1. ファイングレイン監査を使用した特定のアクティビティの監査を参照し、特定のアクティビティの監査の詳細を把握します。

2. DBMS_FGA PL/SQLパッケージを使用して、ファイングレイン監査ポリシーを構成します。DBMS_FGA PL/SQLパッケージを使用したファイングレイン監査ポリシーの管理を参照してください。

3. UNIFIED_AUDIT_TRAILビューを問い合せ、生成された監査レコードを検索します。

追加のビューについては、監査ポリシーのデータ・ディクショナリ・ビューも参照してください。

4. 監査証跡の内容を定期的にアーカイブして削除します。

「監査証跡レコードの削除」を参照してください。

統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査

CREATE AUDIT POLICY文とAUDIT文を使用して、統合監査ポリシーを使用できます。

内容は次のとおりです。

- 統合監査ポリシーおよびAUDITを使用したアクティビティの監査について

- 統合監査ポリシーの作成のベスト・プラクティス

- 統合監査ポリシーの作成の構文

- ロールの監査

- システム権限の監査

- 管理ユーザーの監査

- オブジェクト・アクションの監査

- SELECT、READ ANY TABLEまたはSELECT ANY TABLEの監査

- 複数層環境におけるSQL文および権限の監査

- 統合監査ポリシーの条件の作成

- アプリケーション・コンテキスト値の監査

- Oracle Database Real Application Securityイベントの監査

- Oracle Database Vaultイベントの監査

- Oracle Recovery Managerイベントの監査

- Oracle Label Securityイベントの監査

- Oracle Data Miningイベントの監査

- Oracle Data Pumpイベントの監査

- Oracle SQL*Loaderダイレクト・ロード・パス・イベントの監査

- マルチテナント環境での統合監査ポリシーまたはAUDIT設定の使用

- 統合監査ポリシーの変更

- ユーザーに対する統合監査ポリシーの有効化

- 統合監査ポリシーの無効化

- 統合監査ポリシーの削除

- 例: 非データベース・ユーザーの監査

関連項目:

このタイプの監査の実行に関する一般的な手順については、「SQL文、権限および他の一般アクティビティの監査」を参照してください。

統合監査ポリシーおよびAUDITを使用したアクティビティの監査について

統合監査ポリシーおよびAUDIT SQL文を使用して、複数のタイプのアクティビティを監査できます。

監査できるアクティビティの種類は、次のとおりです。

- ユーザー・アカウント(SYSDBA管理権限でログインする管理ユーザーを含む)、ロールおよび権限

- 表の削除やプロシージャの実行などのオブジェクト・アクション

- アプリケーション・コンテキスト値

- Oracle Database Real Application Security、Oracle Recovery Manager、Oracle Data Mining、Oracle Data Pump、Oracle SQL*Loaderダイレクト・パス・イベント、Oracle Database VaultおよびOracle Label Securityからのアクティビティ

これを実行するには、監査する対象に応じて、次を実行します。

- 統合監査ポリシー。統合監査ポリシーとは、データベースでのユーザー動作の特定の部分を監査できる監査設定の名前付きのグループです。ポリシーを作成するには、CREATE AUDIT POLICY文を使用します。ポリシーは、1ユーザーのアクティビティの監査のような単純なものにすることも、条件を使用した複雑な監査ポリシーを作成することもできます。1つのデータベースで同時に複数の監査ポリシーを有効にできます。監査ポリシーには、システム全体の監査オプションとオブジェクト固有の監査オプションの両方を含めることができます。一般的なアクティビティに対する監査の大半(標準監査を含む)に、監査ポリシーを使用する必要があります。

- AUDITおよびNOAUDIT SQL文。AUDITおよびNOAUDIT SQL文では、それぞれ監査ポリシーを有効および無効にできます。AUDIT文では、ポリシーに対して特定のユーザーを含めたり、除外することもできます。AUDITおよびNOAUDIT文では、アプリケーション・コンテキスト値を監査することもできます。

- Oracle Recovery Managerの場合は、統合監査ポリシーを作成しないでください。UNIFIED_AUDIT_TRAILビューでは、一般的に監査されるRecovery Managerイベントを自動的に取得します。

統合監査ポリシーの作成のベスト・プラクティス

データベースで複数のポリシーを一度に有効にできますが、有効にするポリシーの数を制限することが理想的です。

統合監査ポリシーの構文は、データベースで必要なすべての監査設定を網羅する1つのポリシーを作成できるように設計されています。複数の小さいポリシーを作成するのではなく、関連するオプションを1つのポリシーにグループ化することをお薦めします。これにより、ポリシーをより簡単に管理できるようになります。たとえば、事前定義の統合監査ポリシーを使用したアクティビティの監査で説明されているデフォルトの監査ポリシーには、それぞれ1つの統合監査ポリシーに複数の監査設定が含まれています。

ユーザー・セッションで有効な監査ポリシーの数を制限すると、次の利点が得られます。

- 監査ポリシーの詳細をセッションのUGAメモリーにロードすることに伴うログオン・オーバーヘッドを軽減します。有効なポリシーの数が減ると、ポリシー情報のロードにかかる時間が短縮します。

- UGAメモリーにキャッシュするのに必要なポリシーの数が減るため、セッションのUGAメモリー消費量が減ります。

- 関連するイベントの監査レコードを生成するかどうかを決定する内部監査チェック機能が効率的になります。

統合監査ポリシーの作成の構文

統合監査ポリシーを作成するには、CREATE AUDIT POLICY文を使用します。

統合監査ポリシーを作成すると、Oracle Databaseによって、ポリシーを作成したユーザーのスキーマではなく、SYSスキーマによって所有される最初のクラス・オブジェクトに格納されます。

例22-1に、CREATE AUDIT POLICY文の構文を示します。

例22-1 CREATE AUDIT POLICY文の構文

CREATE AUDIT POLICY policy_name
{ {privilege_audit_clause [action_audit_clause ] [role_audit_clause ]}
| { action_audit_clause  [role_audit_clause ] }
| { role_audit_clause }
}
[WHEN audit_condition EVALUATE PER {STATEMENT|SESSION|INSTANCE}]
[CONTAINER = {CURRENT | ALL}];

次のように値を指定します。

- privilege_audit_clauseは、権限に関連する監査オプションを記述します。詳細は、「システム権限の監査」を参照してください。権限の監査オプションを構成するための詳細な構文は、次のとおりです。

privilege_audit_clause  :=  PRIVILEGES  privilege1 [, privilege2]

- action_audit_clauseおよびstandard_actionsは、オブジェクト・アクションに関連する監査オプションを記述します。詳細は、「オブジェクト・アクションの監査」を参照してください。構文は次のようになります。

action_audit_clause := {standard_actions | component_actions}
[, component_actions ]
standard_actions :=
ACTIONS action1 [ ON {schema.obj_name
| DIRECTORY directory_name
| MINING MODEL schema.obj_name
}
]
[, action2 [ ON {schema.obj_name
| DIRECTORY directory_name
| MINING MODEL schema.obj_name
}
]

- component_actionsでは、Oracle Label Security、Oracle Database Real Application Security、Oracle Database Vault、Oracle Data PumpまたはOracle SQL*Loaderの監査ポリシーを作成できます。詳細は、「統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査」の該当する項を参照してください。構文は次のとおりです。

component_actions :=
ACTIONS COMPONENT=[OLS|XS] action1 [,action2 ] |
ACTIONS COMPONENT=DV DV_action ON DV_object_name |
ACTIONS COMPONENT=DATAPUMP [ EXPORT | IMPORT | ALL ] |
ACTIONS COMPONENT=DIRECT_LOAD [ LOAD | ALL ]

- role_audit_clauseでは、ロールを監査できます。「ロールの監査」を参照してください。構文は次のとおりです。

role_audit_clause := ROLES role1 [, role2]

- WHEN audit_condition EVALUATE PERでは、監査ポリシーおよび評価頻度の条件を作成するためのファンクションを指定できます。EVALUATE PER句には、WHEN条件を付ける必要があります。「統合監査ポリシーの条件の作成」を参照してください構文は次のとおりです。

WHEN 'audit_condition := function operation value_list'
EVALUATE PER {STATEMENT|SESSION|INSTANCE}

- CONTAINERは、マルチテナント環境に使用され、ローカル監査ポリシー(ローカル・プラガブル・データベース(PDB)用)または一般的な監査ポリシーとして監査ポリシーを作成できます。「マルチテナント環境での統合監査ポリシーまたはAUDIT設定の使用」を参照してください。

この構文は、ポリシーにリストされているコンポーネントを監査するように設計されています。たとえば、次のポリシーを作成するとします。

CREATE AUDIT POLICY table_pol
PRIVILEGES CREATE ANY TABLE, DROP ANY TABLE
ROLES emp_admin, sales_admin;

監査証跡では、CREATE ANY TABLEシステム権限またはDROP ANY TABLEシステム権限、ロールemp_adminに直接付与されている任意のシステム権限、またはロールsales_adminに直接付与されている任意のシステム権限を必要とするSQL文を取得します。(監査されるのは、ロールを介して再帰的に付与されている権限ではなく、直接付与されている権限であることに注意してください。)

ポリシーを作成したら、AUDIT文を使用して有効にする必要があります。オプションで、1人以上のユーザーに対してポリシーの適用または除外を実行したり、監査アクションの成功または失敗(あるいは両方)時に監査レコードが書き込まれるかどうかを指定できます。「ユーザーに対する統合監査ポリシーの有効化」を参照してください

ロールの監査

CREATE AUDIT POLICY文を使用して、データベース・ロールを監査できます。

内容は次のとおりです。

- ロールの監査について

- ロールの統合監査ポリシーの構成

- 例: マルチテナント環境でのDBAロールの監査

ロールの監査について

ロールを監査すると、このロールに直接付与されたすべてのシステム権限がOracle Databaseによって監査されます。

ユーザー定義のロールを含むすべてのロールを監査できます。ROLES監査オプションでロールに対して共通の統合監査ポリシーを作成する場合、ロール・リストで共通ロールのみを指定する必要があります。このようなポリシーが有効な場合、Oracle Databaseは、共通ロールに対して共通のシステム権限と共通ロールに直接付与されているシステム権限をすべて監査します。共通ロールに対してローカルに付与されているシステム権限は監査されません。ロールが共通に付与されているかどうかを確認するには、DBA_ROLESデータ・ディクショナリ・ビューを問い合せます。ロールに付与された権限が共通に付与されたかどうかを確認するには、ROLE_SYS_PRIVSビューを問い合せます。

関連項目:

事前定義ロールのリストは、「Oracle Databaseのインストールで事前に定義されているロール」を参照してください。

ロールの統合監査ポリシーの構成

ロールの使用を取得する統合監査ポリシーを作成するには、CREATE AUDIT POLICY文にROLES句を含めます。

- 次の構文を使用して、ロールを監査する統合監査ポリシーを作成します。

CREATE AUDIT POLICY policy_name
ROLES role1 [, role2];

例:

CREATE AUDIT POLICY audit_roles_pol
ROLES IMP_FULL_DATABASE, EXP_FULL_DATABASE;

条件を含む場合など、より複雑なロールの統合監査ポリシーを作成できます。ポリシーを作成したら、AUDIT文を使用して有効にする必要があります。

関連項目:
統合監査ポリシーの作成の構文

例: マルチテナント環境でのDBAロールの監査

マルチテナント環境で、CREATE AUDIT POLICY文を使用してロールを監査できます。

例22-2に、マルチテナント環境で事前定義済の共通ロールDBAを監査する方法を示します。

例22-2 マルチテナント環境でのDBAロールの監査

CREATE AUDIT POLICY role_dba_audit_pol
ROLES DBA
CONTAINER = ALL;

AUDIT POLICY role_dba_audit_pol;

システム権限の監査

CREATE AUDIT POLICY文を使用して、システム権限を監査できます。

内容は次のとおりです。

- システム権限監査について

- 監査できるシステム権限

- 監査できないシステム権限

- システム権限の使用を取得するための統合監査ポリシーの構成

- 例: ANY権限を持つユーザーの監査

- 例: 条件を使用するシステム権限の監査

- 監査証跡でのシステム権限の統合監査ポリシーの表示方法

システム権限監査について

システム権限の監査では、システム権限を使用するアクティビティ(READ ANY TABLEなど)を監査します。

この種の監査では、正常終了するために監査対象の権限を必要とするSQL文が記録されます。

1つの統合監査ポリシーに、権限監査およびアクション監査の両方のオプションを含めることができます。SYSなどの管理ユーザーの権限の使用は監査しないでください。かわりに、オブジェクト・アクションを監査してください。詳細は、オブジェクト・アクションの監査を参照してください。

注意:

システム権限、オブジェクト、データベース・イベントなどを監査できます。ただし、データベース権限の使用状況(たとえば、指定のロールに付与されている権限はどれが使用されているか)を検索し、使用されている権限と使用されていない権限のレポートを生成する必要がある場合は、権限キャプチャを作成できます。詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

監査できるシステム権限

ほとんどのシステム権限の使用を監査できます。

監査可能なシステム権限のリストを検索するには、SYSTEM_PRIVILEGE_MAP表を問い合せます。

例:

SELECT NAME FROM SYSTEM_PRIVILEGE_MAP;

NAME
-------------
ALTER ANY CUBE BUILD PROCESS
SELECT ANY CUBE BUILD PROCESS
ALTER ANY MEASURE FOLDER
...

アクション監査オプションと同様、権限監査では、データベース・ユーザーに付与されているシステム権限の使用を監査します。SQL文監査と権限監査の両方について類似の監査オプションを設定しても、生成される監査レコードは1つのみです。たとえば、2つのポリシーが存在しており、一方が、特にHR.PROCプロシージャのEXECUTE PROCEDUREを監査し、もう一方が一般的にEXECUTE PROCEDURE (すべてのプロシージャ)を監査する場合は、監査レコードが1つのみ書き込まれます。

権限監査は、アクションが既存の所有者およびオブジェクト権限によってすでに許可されている場合は実行されません。権限監査がトリガーされるのは、権限が不十分な場合、つまりアクションを可能にする権限がシステム権限である場合のみです。たとえば、ユーザーSCOTTにSELECT ANY TABLE権限が付与されており、SELECT ANY TABLEが監査対象であるとします。SCOTTが自分の表(たとえば、SCOTT.EMP)を選択した場合、SELECT ANY TABLE権限は使用されません。自分自身のスキーマ内でSELECT文を実行したため、監査レコードは生成されません。一方、SCOTTが他のスキーマ(たとえばHR.EMPLOYEES表)から選択すると、監査レコードが生成されます。SCOTTは自分自身のスキーマ外にある表を選択したため、SELECT ANY TABLE権限を使用する必要がありました。

監査できないシステム権限

次のシステム権限は監査できません。

これらの権限を次に示します。

- INHERIT ANY PRIVILEGE

- INHERIT PRIVILEGE

- TRANSLATE ANY SQL

- TRANSLATE SQL

システム権限の使用を取得するための統合監査ポリシーの構成

CREATE AUDIT POLICY文のPRIVILEGES句で、システム権限の使用を監査します。

- 次の構文を使用して、権限を監査する統合監査ポリシーを作成します。

CREATE AUDIT POLICY policy_name
PRIVILEGES privilege1 [, privilege2];

例:

CREATE AUDIT POLICY my_simple_priv_policy
PRIVILEGES SELECT ANY TABLE, CREATE LIBRARY;

条件を含む場合など、より複雑な権限の統合監査ポリシーを作成できます。ポリシーを作成したら、AUDIT文を使用して有効にする必要があります。

関連項目:
統合監査ポリシーの作成の構文

例: ANY権限を持つユーザーの監査

CREATE AUDIT POLICY文で、ANY権限のユーザーを監査できます。

例22-3に、ユーザーHR_MGRの複数のANY権限を監査する方法を示します。

例22-3 ANY権限を持つユーザーの監査

CREATE AUDIT POLICY hr_mgr_audit_pol
PRIVILEGES DROP ANY TABLE, DROP ANY CONTEXT, DROP ANY INDEX, DROP ANY LIBRARY;

AUDIT POLICY hr_mgr_audit_pol BY HR_MGR;

例: 条件を使用するシステム権限の監査

CREATE AUDIT POLICY文で、システム権限の監査に条件を使用する監査ポリシーを作成できます。

例22-4に、psmithおよびjrawlinsの2人のオペレーティング・システム・ユーザーによって使用される権限を監査する方法を示します。

例22-4 条件を使用するシステム権限の監査

CREATE AUDIT POLICY os_users_priv_pol
PRIVILEGES SELECT ANY TABLE, CREATE LIBRARY
WHEN 'SYS_CONTEXT (''USERENV'', ''OS_USER'') IN (''psmith'', ''jrawlins'')'
EVALUATE PER SESSION;

AUDIT POLICY os_users_priv_pol;

監査証跡でのシステム権限の統合監査ポリシーの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはシステム権限の監査イベントを表示します。

必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAILプロシージャを実行して、監査レコードをディスクに書き込みます。

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。

次の例では、例22-4で作成した統合監査ポリシーos_users_priv_polに基づいて、オペレーティング・システム・ユーザーpsmithによって使用される権限のリストが表示されます。

SELECT SYSTEM_PRIVILEGE_USED FROM UNIFIED_AUDIT_TRAIL
WHERE OS_USERNAME = 'PSMITH' AND UNIFIED_AUDIT_POLICIES = 'OS_USERS_PRIV_POL';

SYSTEM_PRIVILEGE_USED
----------------------
SELECT ANY TABLE
DROP ANY TABLE

注意:

SELECT ANY TABLEシステム権限に対する監査ポリシーを作成した場合、ユーザーがREADオブジェクト権限を実行したか、SELECTオブジェクト権限を実行したかによって監査証跡で取得されるアクションが影響を受けます。詳細は、SELECT、READ ANY TABLEまたはSELECT ANY TABLEの監査を参照してください。

管理ユーザーの監査

Oracle Databaseには、SYSなどのデフォルトの管理ユーザー・アカウントのセットがあります。これらのユーザーのアクションを取得する統合監査ポリシーを作成できます。

内容は次のとおりです。

- 監査可能な管理ユーザー・アカウント

- 管理者アクティビティを取得するための統合監査ポリシーの構成

- 例: SYSユーザーの監査

監査可能な管理ユーザー・アカウント

Oracle Databaseでは、管理権限に関連付けられている管理ユーザー・アカウントが用意されています。

表22-1に、デフォルトの管理ユーザー・アカウントと、通常関連付けられている管理権限を示します。

表22-1 管理ユーザーおよび管理権限

管理ユーザー・アカウント

管理権限

SYS

SYSDBA

PUBLIC脚注1

SYSOPER

SYSASM

SYSASM

SYSBACKUP

SYSBACKUP

SYSDG

SYSDG

SYSKM

SYSKM

脚注1

PUBLICはユーザーPUBLICを示し、SYSOPER管理権限でログインしている場合に有効なユーザーです。これはPUBLICロールを示しません。

関連項目:

強制的に監査されるアクティビティ

管理者アクティビティを取得するための統合監査ポリシーの構成

CREATE AUDIT POLICY文で、管理ユーザーを監査できます。

- 管理ユーザーを監査する場合は、統合監査ポリシーを作成して、非管理ユーザーに適用する場合と同じように、このポリシーをユーザーに適用します。管理ユーザーによるトップ・レベルの文は、データベースを開くまで強制的に監査されます。

例: SYSユーザーの監査

CREATE AUDIT POLICY文で、SYSユーザーを監査できます。

例22-5に、ユーザーSYSによるDBMS_FGA PL/SQLパッケージの権限付与を監査する方法を示します。

例22-5 SYSユーザーの監査

CREATE AUDIT POLICY dbms_fga_grants
ACTIONS GRANT
ON DBMS_FGA;

AUDIT POLICY dbms_fga_grants BY SYS;

オブジェクト・アクションの監査

CREATE AUDIT POLICY文を使用して、オブジェクト・アクションを監査できます。

内容は次のとおりです。

- オブジェクト・アクションの監査について

- 監査できるオブジェクト・アクション

- オブジェクト・アクションの統合監査ポリシーの構成

- 例: SYSオブジェクトでのアクションの監査

- 例: 1つのオブジェクトでの複数のアクションの監査

- 例: オブジェクトでのアクションと権限の両方の監査

- 例: 表でのすべてのアクションの監査

- 例: データベースでのすべてのアクションの監査

- 監査証跡でのオブジェクト・アクションの統合監査ポリシーの表示方法

- ファンクション、プロシージャ、パッケージおよびトリガーの監査

- Oracle Virtual Private Databaseポリシー関数の監査ポリシー

- 統合監査とエディション付きオブジェクト

オブジェクト・アクションの監査について

HR.EMPLOYEES表のUPDATE文など、特定のオブジェクトで実行されるアクションを監査できます。

監査は、オブジェクトに使用されたDDLおよびDML文を含むことができます。1つの統合監査ポリシーに、権限監査およびアクション監査の両方のオプションと、複数のオブジェクトの監査オプションのセットを含めることができます。

監査できるオブジェクト・アクション

オブジェクト・アクションの監査では、監査の対象を拡大または限定できます(すべてのユーザー・アクションの監査または一部のユーザー・アクションに限定した監査など)。

表22-2に、オブジェクト・レベルの標準データベース・アクションのオプションを示します。SELECT SQL文に対する監査ポリシーでは、SELECTアクションだけでなくREADアクションも取得されます。

表22-2 オブジェクト・レベルの標準データベース・アクションの監査オプション

オブジェクト

監査できるSQLアクション

表

ALTER、AUDIT、COMMENT、DELETE、FLASHBACK、GRANT、INDEX、INSERT、LOCK、RENAME、SELECT、UPDATE

ビュー

AUDIT、COMMENT、DELETE、FLASHBACK、GRANT、INSERT、LOCK、RENAME、SELECT、UPDATE

シーケンス

ALTER、AUDIT、GRANT、SELECT

プロシージャ(トリガーを含む)

AUDIT、EXECUTE、GRANT

ファンクション

AUDIT、EXECUTE、GRANT

パッケージ

AUDIT、EXECUTE、GRANT

マテリアライズド・ビュー

ALTER、AUDIT、COMMENT、DELETE、INDEX、INSERT、LOCK、SELECT、UPDATE

マイニング・モデル

AUDIT、COMMENT、GRANT、RENAME、SELECT

ディレクトリ

AUDIT、GRANT、READ

ライブラリ

EXECUTE、GRANT

オブジェクト型

ALTER、AUDIT、GRANT

Javaスキーマ・オブジェクト(ソース、クラス、リソース)

AUDIT、EXECUTE、GRANT

関連項目:

- ファンクション、プロシージャ、パッケージおよびトリガーの監査

- Oracle Virtual Private Databaseポリシー関数の監査ポリシー

オブジェクト・アクションの統合監査ポリシーの構成

CREATE AUDIT POLICY文のACTIONS句で、オブジェクト・アクションを取得するポリシーを作成します。

- 次の構文を使用して、オブジェクト・アクションを監査する統合監査ポリシーを作成します。

CREATE AUDIT POLICY policy_name
ACTIONS action1 [, action2 ON object1] [, action3 ON object2];

例:

CREATE AUDIT POLICY my_simple_obj_policy
ACTIONS SELECT ON OE.ORDERS, UPDATE ON HR.EMPLOYEES;

この例に示すように、複数のオブジェクトの複数のアクションを監査できます。

条件を含む場合など、より複雑なオブジェクト・アクションの統合監査ポリシーを作成できます。ポリシーを作成したら、AUDIT文を使用して有効にする必要があります。

関連項目:
統合監査ポリシーの作成の構文

例: SYSオブジェクトでのアクションの監査

CREATE AUDIT POLICY文で、SYSオブジェクトのアクションを監査できます。

例22-6では、SYS.USER$システム表でSELECT文を監査する監査ポリシーの作成方法を示します。この監査ポリシーは、SYSおよびSYSTEMを含むすべてのユーザーに適用されます。

例22-6 SYSオブジェクトの監査アクション

CREATE AUDIT POLICY select_user_dictionary_table_pol ACTIONS SELECT ON SYS.USER$;

AUDIT POLICY select_user_dictionary_table_pol;

例: 1つのオブジェクトでの複数のアクションの監査

CREATE AUDIT POLICY文で、1つのオブジェクト上の複数のアクションを監査できます。

例22-7に、ユーザーjrandolphおよびphawkinsによってapp_libライブラリで実行される複数のSQL文の監査方法を示します。

例22-7 1つのオブジェクトでの複数のアクションの監査

CREATE AUDIT POLICY actions_on_hr_emp_pol1
ACTIONS EXECUTE, GRANT
ON app_lib;

AUDIT POLICY actions_on_hr_emp_pol1 BY jrandolph, phawkins;

例: オブジェクトでのアクションと権限の両方の監査

CREATE AUDIT POLICY文で、単一のポリシーを使用して1つのオブジェクトでの複数のアクションと権限の両方を監査できます。

例22-8に、例22-7のバリエーション(CREATE LIBRARY権限を使用して、app_libライブラリのすべてのEXECUTE文およびGRANT文が監査されます)を示します。

例22-8 オブジェクトでのアクションと権限の両方の監査

CREATE AUDIT POLICY actions_on_hr_emp_pol2
PRIVILEGES CREATE LIBRARY
ACTIONS EXECUTE, GRANT
ON app_lib;

AUDIT POLICY actions_on_hr_emp_pol2 BY jrandolph, phawkins;

ディレクトリ・オブジェクトは監査可能です。たとえば、ORACLE_LOADERアクセス・ドライバで使用されるプリプロセッサ・プログラムを含むディレクトリ・オブジェクトを作成するとします。ディレクトリ・オブジェクト内のこのプログラムを実行するすべてのユーザーを監査できます。

例: 表でのすべてのアクションの監査

CREATE AUDIT POLICY文で、表でのすべてのアクションを監査できます。

キーワードALLを使用してすべてのアクションを監査できます。例22-9に、HR.EMPLOYEES表ですべてのアクション(ユーザーpmulliganによるアクションを除く)を監査する方法を示します。

例22-9 表でのすべてのアクションの監査

CREATE AUDIT POLICY all_actions_on_hr_emp_pol
ACTIONS ALL ON HR.EMPLOYEES;

AUDIT POLICY all_actions_on_hr_emp_pol EXCEPT pmulligan;

例: データベースでのすべてのアクションの監査

CREATE AUDIT POLICY文で、データベースでのすべてのアクションを監査できます。

例22-10に、データベース全体ですべてのアクションを監査する方法を示します。

例22-10 データベースでのすべてのアクションの監査

CREATE AUDIT POLICY all_actions_pol ACTIONS ALL;

AUDIT POLICY all_actions_pol;

監査証跡でのオブジェクト・アクションの統合監査ポリシーの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはオブジェクト・アクションの監査イベントを表示します。

必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAILプロシージャを実行して、監査レコードをディスクに書き込みます。

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。

例:

SELECT ACTION_NAME, OBJECT_SCHEMA, OBJECT_NAME FROM UNIFIED_AUDIT_TRAIL
WHERE DBUSERNAME = 'SYS';

ACTION_NAME OBJECT_SCHEMA OBJECT_NAME
----------- ------------- ------------
SELECT      HR            EMPLOYEES

ファンクション、プロシージャ、パッケージおよびトリガーの監査

ファンクション、プロシージャ、PL/SQLパッケージおよびトリガーを監査できます。

監査可能な領域は次のとおりです。

- スタンドアロン・ファンクション、スタンドアロン・プロシージャおよびPL/SQLパッケージは個別に監査できます。

- PL/SQLパッケージを監査すると、パッケージ内のすべてのファンクションおよびプロシージャが監査されます。

- すべての実行の監査を使用可能にすると、データベース内のすべてのトリガーおよびPL/SQLパッケージ内のすべてのファンクションとプロシージャが監査されます。

- PL/SQLパッケージ内のファンクションまたはプロシージャを個別に監査することはできません。

- PL/SQLストアド・プロシージャまたはストアド・ファンクションでのEXECUTE操作を監査する場合は、監査目的での操作の成否を判断する際に、プロシージャまたはファンクションを検索してその実行を認証する機能のみが監査対象となります。したがって、WHENEVER NOT SUCCESSFUL句を指定すると、無効なオブジェクト・エラー、存在しないオブジェクト・エラー、および認証の失敗が監査されます。プロシージャまたはファンクションの実行時に検出されたエラーは監査されません。WHENEVER SUCCESSFUL句を指定すると、実行時にエラーが検出されたかどうかに関係なく、無効なオブジェクト・エラー、存在しないオブジェクト・エラー、および認証の失敗が監査されます。

Oracle Virtual Private Databaseポリシー関数の監査ポリシー

監査によって動的VPDポリシーや静的VPDポリシー、コンテキスト依存VPDポリシーが影響を受けることがあります。

- 動的ポリシー: ポリシー関数が2回(SQL文の解析時に1回と実行時に1回)評価されます。結果として、各評価で2つの監査レコードが生成されます。

- 静的ポリシー: ポリシー関数が1回評価され、SGA内にキャッシュされます。これにより、監査レコードは1つのみ生成されます。

- 状況依存ポリシー: ポリシー関数が文の解析時に1回実行されます。これにより、監査レコードは1つのみ生成されます。

統合監査とエディション付きオブジェクト

エディション付きオブジェクトに統合監査ポリシーが付加されている場合、そのオブジェクトが表示されるすべてのエディションにそのポリシーが適用されます。

エディション付きオブジェクトが実現化されると、そのオブジェクトに付加されている統合監査ポリシーが新しい実際のオブジェクトに新たに付加されます。継承されたエディション付きオブジェクトに新たに統合監査ポリシーを適用すると、そのオブジェクトが実現化されます。

監査対象のオブジェクトが表示されるエディションを調べるには、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューのOBJECT_NAMEおよびOBJ_EDITION_NAME列を問い合せます。

関連項目:

エディションの詳細は、『Oracle Database開発ガイド』を参照してください。

SELECT、READ ANY TABLEまたはSELECT ANY TABLEの監査

CREATE AUDIT POLICY文を使用して、SELECT文とREAD ANY TABLE権限またはSELECT ANY TABLE権限を監査できます。

内容は次のとおりです。

- SELECT文およびREAD ANY TABLEシステム権限の監査について

- READオブジェクト権限操作を取得する統合監査ポリシーの作成

- 統合監査証跡でのREAD ANY TABLEおよびSELECT ANY TABLEの取得方法

SELECT文およびREAD ANY TABLEシステム権限の監査について

READ ANY TABLEシステム権限の使用を取得する統合監査ポリシーを作成できます。

ユーザーが実行しようとしたアクションおよびユーザーに付与されていた権限に基づいて、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューのSYSTEM_PRIVILEGE_USED列にREAD ANY TABLEシステム権限またはSELECT ANY TABLEシステム権限が記録されます。たとえば、ユーザーにSELECT ANY TABLE権限が付与されていて、表に対する問合せを実行するとします。監査証跡に、ユーザーがSELECT ANY TABLEシステム権限を使用したことが記録されます。ユーザーにREAD ANY TABLEが付与されていて、同じ問合せを実行した場合、READ ANY TABLE権限が記録されます。

READオブジェクト権限操作を取得する統合監査ポリシーの作成

READオブジェクト権限操作を取得する統合監査ポリシーを作成できます。

- READオブジェクト操作を取得する統合監査ポリシーを作成する場合、READ文ではなくSELECT文に対するポリシーを作成します。

例:

CREATE AUDIT POLICY read_hr_employees
ACTIONS SELECT ON HR.EMPLOYEES;

統合監査証跡でのREAD ANY TABLEおよびSELECT ANY TABLEの取得方法

統合監査証跡では、ユーザーにREAD ANY TABLEまたはSELECT ANY TABLE権限が付与されているかどうかに基づいてSELECT動作が取得されます。

表22-3は、統合監査証跡によるこれらのアクションの取得方法を示しています。

表22-3 READ ANY TABLEおよびSELECT ANY TABLEに対する監査動作

ユーザーが発行した文

ユーザーに付与されている権限

監査されるシステム権限

予期されるUNIFIED_AUDIT_TRAILの動作

SELECT

SELECT ANY TABLE

SELECT ANY TABLE

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

SELECT ANY TABLE

SELECT

SELECT ANY TABLE

READ ANY TABLE

レコードなし

SELECT

SELECT ANY TABLE

SELECT ANY TABLEとREAD ANY TABLEの両方

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

SELECT ANY TABLE

SELECT

SELECT ANY TABLE

SELECT ANY TABLEもREAD ANY TABLEも対象外

レコードなし

SELECT

READ ANY TABLE

SELECT ANY TABLE

レコードなし

SELECT

READ ANY TABLE

READ ANY TABLE

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

READ ANY TABLE

SELECT

READ ANY TABLE

SELECT ANY TABLEとREAD ANY TABLEの両方

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

READ ANY TABLE

SELECT

READ ANY TABLE

SELECT ANY TABLEもREAD ANY TABLEも対象外

レコードなし

SELECT

SELECT ANY TABLEとREAD ANY TABLEの両方

SELECT ANY TABLE

READ ANY TABLEがアクセスに使用されたため、レコードなし

SELECT

SELECT ANY TABLEとREAD ANY TABLEの両方

READ ANY TABLE

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

READ ANY TABLE

SELECT

SELECT ANY TABLEとREAD ANY TABLEの両方

SELECT ANY TABLEとREAD ANY TABLEの両方

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

READ ANY TABLE

SELECT

SELECT ANY TABLEとREAD ANY TABLEの両方

SELECT ANY TABLEもREAD ANY TABLEも対象外

レコードなし

SELECT

SELECT ANY TABLEもREAD ANY TABLEも対象外

SELECT ANY TABLE

レコードなし

SELECT

SELECT ANY TABLEもREAD ANY TABLEも対象外

READ ANY TABLE

レコードなし

SELECT

SELECT ANY TABLEもREAD ANY TABLEも対象外

SELECT ANY TABLEとREAD ANY TABLEの両方

レコードなし

SELECT

SELECT ANY TABLEもREAD ANY TABLEも対象外

SELECT ANY TABLEもREAD ANY TABLEも対象外

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLE

SELECT ANY TABLE

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

SELECT ANY TABLE

SELECT ... FOR UPDATE

SELECT ANY TABLE

READ ANY TABLE

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLE

SELECT ANY TABLEとREAD ANY TABLEの両方

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

SELECT ANY TABLE

SELECT ... FOR UPDATE

SELECT ANY TABLE

SELECT ANY TABLEもREAD ANY TABLEも対象外

レコードなし

SELECT ... FOR UPDATE

READ ANY TABLE

SELECT ANY TABLE

レコードなし

SELECT ... FOR UPDATE

READ ANY TABLE

READ ANY TABLE

レコードなし

SELECT ... FOR UPDATE

READ ANY TABLE

SELECT ANY TABLEとREAD ANY TABLEの両方

レコードなし

SELECT ... FOR UPDATE

READ ANY TABLE

SELECT ANY TABLEもREAD ANY TABLEも対象外

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLEとREAD ANY TABLEの両方

SELECT ANY TABLE

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

SELECT ANY TABLE

SELECT ... FOR UPDATE

SELECT ANY TABLEとREAD ANY TABLEの両方

READ ANY TABLE

READ ANY TABLEがアクセスに使用されたため、レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLEとREAD ANY TABLEの両方

SELECT ANY TABLEとREAD ANY TABLEの両方

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

SELECT ANY TABLE

SELECT ... FOR UPDATE

SELECT ANY TABLEとREAD ANY TABLEの両方

SELECT ANY TABLEもREAD ANY TABLEも対象外

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLEもREAD ANY TABLEも対象外

SELECT ANY TABLE

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLEもREAD ANY TABLEも対象外

READ ANY TABLE

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLEもREAD ANY TABLEも対象外

SELECT ANY TABLEとREAD ANY TABLEの両方

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLEもREAD ANY TABLEも対象外

SELECT ANY TABLEもREAD ANY TABLEも対象外

レコードなし

複数層環境におけるSQL文および権限の監査

統合監査ポリシーを作成して、複数層環境のクライアントのアクティビティを監査できます。

複数層環境では、クライアントの識別情報をすべての層を通して保持できます。したがって、クライアントにかわって中間層アプリケーションにより行われたアクションを、ポリシーのAUDIT文の中でBY user句を使用することで監査できます。監査は、プロキシ・セッションを含むすべてのユーザー・セッションに適用されます。

中間層では、データベース・セッションでユーザーのクライアント識別情報を設定し、中間層アプリケーションでエンド・ユーザーのアクションを監査することもできます。そうすることにより、エンド・ユーザーのクライアント識別情報が監査証跡に記録されます。

次の例は、ユーザーjacksonによって発行されたSELECT TABLE文を監査する方法を示しています。

CREATE AUDIT POLICY tab_pol
PRIVILEGES CREATE ANY TABLE
ACTIONS CREATE TABLE;

AUDIT tab_pol BY jackson;

複数層環境でユーザー・アクティビティを監査できます。監査を開始した後で、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることで、これらのアクティビティを確認できます。

図22-1に、UNIFIED_AUDIT_TRAILビューのPROXY_SESSIONID、ACTION_NAMEおよびSESSION_ID列を問い合せることで、プロキシ・ユーザーを監査する方法を示します。このシナリオでは、データベース・ユーザーとプロキシ・ユーザーの両方のアカウントがデータベースに認識されます。セッション・プーリングを使用できます。

図22-1 プロキシ・ユーザーの監査

図22-2に、DBA_AUDIT_TRAILデータ・ディクショナリ・ビューのCLIENT_ID列を問い合せることで、複数のデータベース・セッションにわたるクライアント識別子情報を監査する方法を示します。この例では、クライアント識別子はCLIENT_Aに設定されています。図22-1に示すプロキシ・ユーザー/データベース・ユーザーの例と同様に、セッション・プーリングを使用できます。

図22-2 複数のセッションにわたるクライアント識別子情報の監査

関連項目:

複数層環境でのユーザー認証の詳細は、複数層環境でのユーザー識別情報の保持を参照してください

統合監査ポリシーの条件の作成

CREATE AUDIT POLICY文を使用すると、統合監査ポリシーの条件を作成できます。

内容は次のとおりです。

- 統合監査ポリシーについて

- 条件を使用した統合監査ポリシーの構成

- 例: SQL*Plusへのアクセスの監査

- 例: 特定のホストにはないアクションの監査

- 例: システム全体のアクションおよびスキーマ固有のアクションの両方の監査

- 例: 文の発生ごとの条件の監査

- 例: 現在の管理ユーザー・セッションの統合監査セッションID

- 例: 現在の非管理ユーザー・セッションの統合監査セッションID

- 監査証跡での条件からの監査レコードの表示方法

統合監査ポリシーについて

SYS_CONTEXTネームスペースと属性のペアを使用して条件を指定する統合監査ポリシーを作成できます。

たとえば、監査条件を満たす可能性のある特定のユーザーや、監査条件を満たすコンピュータ・ホストにこの監査条件を適用します。

監査条件が満たされると、Oracle Databaseによってイベントのレコードが監査されます。条件定義の一部として、監査条件が文の発生、セッションまたはデータベース・インスタンスごとに評価されるかどうかを指定する必要があります。

注意:

監査条件では、安全なアプリケーション・コンテキストと安全でないアプリケーション・コンテキストの両方を使用できます。

条件を使用した統合監査ポリシーの構成

CREATE AUDIT POLICY文のWHEN句で、監査ポリシーの条件を定義します。

- 次の構文を使用して、条件を使用する統合監査ポリシーを作成します。

CREATE AUDIT POLICY policy_name
action_privilege_role_audit_option
[WHEN function_operation_value_list_1 [[AND | OR] function_operation_value_list_n]
EVALUATE PER STATEMENT | SESSION | INSTANCE];

次のように値を指定します。

- action_privilege_role_audit_optionは、システム・アクション、オブジェクト・アクション、権限およびロールの監査オプションを示します。

- WHENは、条件を定義します。この項では、次のコンポーネントについて説明します。

- functionは、次のタイプの関数を使用します。
数値関数: BITAND、CEIL、FLOOR、LN POWERなど

文字値を戻す文字関数: CONCAT、LOWER、UPPERなど

数値を戻す文字関数: LENGTH、INSTRなど

環境および識別子関数: SYS_CONTEXT、UIDなど。SYS_CONTEXTでは、ほとんどの場合、『Oracle Database SQL言語リファレンス』に説明されているUSERENVネームスペースを使用できます。

- operationには、AND、OR、IN、NOT IN、=、<、>、<>の演算子を使用できます。

- value_listは、テストする条件を示します。

function_operation_value_listセットごとに、ANDまたはORで区切られた追加の条件を含めることができます。

WHEN句を記述する場合は、次のガイドラインに従います。

- function operation value設定全体を一重引用符で囲みます。句内では、引用符で囲まれたそれぞれの構成要素を、2つのペアの一重引用符で囲みます。二重引用符は使用しないでください。

- WHEN条件は4000バイトを超えないでください。

- EVALUATE PERは、次のオプションを示します。

- STATEMENTは、発生する監査可能な関連する各文の条件を評価します。

- SESSIONは、セッション中に1回のみ条件を評価し、セッションの残りで結果をキャッシュして再利用します。Oracle Databaseでは、ポリシーが最初に使用されるときに条件を評価し、結果をUGAメモリーに後で保存します。

- INSTANCEは、データベース・インスタンスのライフタイム中に1回のみ条件を評価します。Oracle Databaseは条件を評価した後、インスタンスの残りのライフタイムで結果をキャッシュして再利用します。SESSION評価と同様、評価は最初に必要になるときに実行され、結果は後でUGAメモリーに保存されます。

例:

CREATE AUDIT POLICY oe_orders_pol
ACTIONS UPDATE ON OE.ORDERS
WHEN 'SYS_CONTEXT(''USERENV'', ''IDENTIFICATION_TYPE'') = ''EXTERNAL'''
EVALUATE PER STATEMENT;

ポリシーを作成したら、AUDIT文を使用して有効にする必要があります。

関連項目:
条件で使用可能な関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

例: SQL*Plusへのアクセスの監査

CREATE AUDIT POLICY文で、SQL*Plusへのアクセスを監査できます。

例22-11に、HRおよびOEというユーザーによるSQL*Plusを使用したデータベース・アクセスを監査する方法を示します。

例22-11 SQL*Plusへのアクセスの監査

CREATE AUDIT POLICY logon_pol
ACTIONS LOGON
WHEN 'INSTR(UPPER(SYS_CONTEXT(''USERENV'', ''CLIENT_PROGRAM_NAME'')), ''SQLPLUS'') > 0'
EVALUATE PER SESSION;

AUDIT POLICY logon_pol BY HR, OE;

例: 特定のホストにはないアクションの監査

CREATE AUDIT POLICY文で、特定のホストにはないアクションを監査できます。

例22-12に、OE.ORDERS表の2つの監査アクション(UPDATEおよびDELETE文)を監査する方法を示します(ホスト名sales_24およびsales_12は監査から除く)。監査はセッション単位で実行され、失敗した場合にのみ監査レコードが書き込まれます。

例22-12 特定のホストにはないアクションの監査

CREATE AUDIT POLICY oe_table_audit1
ACTIONS UPDATE ON OE.ORDERS, DELETE ON OE.ORDERS
WHEN 'SYS_CONTEXT (''USERENV'', ''HOST'') NOT IN (''sales_24'',''sales_12'')'
EVALUATE PER SESSION;

AUDIT POLICY oe_table_audit1 WHENEVER NOT SUCCESSFUL;

例: システム全体のアクションおよびスキーマ固有のアクションの両方の監査

CREATE AUDIT POLICY文で、システム全体のアクションおよびスキーマ固有のアクションの両方を監査できます。

例22-13に、UPDATE文がシステム全体で監査される例22-12のバリエーションを示します。DELETE文の監査は、OE.ORDERS表に固有です。

例22-13 システム全体のアクションおよびスキーマ固有のアクションの両方の監査

CREATE AUDIT POLICY oe_table_audit2
ACTIONS UPDATE, DELETE ON OE.ORDERS
WHEN 'SYS_CONTEXT (''USERENV'', ''HOST'') NOT IN (''sales_24'',''sales_12'')'
EVALUATE PER SESSION;

AUDIT POLICY oe_table_audit2;

例: 文の発生ごとの条件の監査

CREATE AUDIT POLICY文で、条件を監査できます。

例22-14に、OE.ORDERS表のDELETE文の各発生に基づいて条件を監査する方法を示します(ユーザーjmartinは監査から除く)。

例22-14 文の発生ごとの条件の監査

CREATE AUDIT POLICY sales_clerk_pol
ACTIONS DELETE ON OE.ORDERS
WHEN 'SYS_CONTEXT(''USERENV'', ''CLIENT_IDENTIFIER'') = ''sales_clerk'''
EVALUATE PER STATEMENT;

AUDIT POLICY sales_clerk_pol EXCEPT jmartin;

例: 現在の管理ユーザー・セッションの統合監査セッションID

SYS_CONTEXT関数を使用してセッションIDを確認できます。

例22-15に、管理ユーザーの現在のユーザー・セッションの統合監査セッションIDの確認方法を示します。

例22-15 現在の管理ユーザー・セッションの統合監査セッションID

CONNECT SYS AS SYSDBA
Enter password: password

SELECT SYS_CONTEXT('USERENV', 'UNIFIED_AUDIT_SESSIONID') FROM DUAL;

次のような出力が表示されます。

SYS_CONTEXT('USERENV','UNIFIED_AUDIT_SESSIONID')
--------------------------------------------------------------------------------
2318470183

混合モード監査では、USERENVネームスペースのUNIFIED_AUDIT_SESSIONID値はSESSIONIDパラメータで記録される値とは異なります。このため、混合モード監査を使用し、正しい監査セッションIDを確認する場合、SESSIONIDパラメータではなくUSERENV UNIFIED_AUDIT_SESSIONIDパラメータを使用します。完全な統合監査では、SESSIONIDとUNIFIED_AUDIT_SESSIONIDの値は同じです。

例: 現在の非管理ユーザー・セッションの統合監査セッションID

SYS_CONTEXT関数を使用して、現在の非管理ユーザー・セッションのセッションIDを確認できます。

例22-16に、非管理ユーザーの現在のユーザー・セッションの統合監査セッションIDの確認方法を示します。

例22-16 現在の非管理ユーザー・セッションの統合監査セッションID

CONNECT mblake -- Or, CONNECT mblake@hrpdb for a PDB
Enter password: password

SELECT SYS_CONTEXT('USERENV', 'UNIFIED_AUDIT_SESSIONID') FROM DUAL;

次のような出力が表示されます。

SYS_CONTEXT('USERENV','UNIFIED_AUDIT_SESSIONID')
--------------------------------------------------------------------------------
2776921346

監査証跡での条件からの監査レコードの表示方法

統合監査ポリシーからの監査レコードの条件は、監査証跡には表示されません。

条件がtrueと評価され、レコードが書き込まれると、レコードは監査証跡に表示されます。UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることで、監査証跡をチェックできます。

関連項目:
その他の監査証跡については、監査ポリシーのデータ・ディクショナリ・ビューを参照してください

アプリケーション・コンテキスト値の監査

AUDIT文を使用して、アプリケーション・コンテキスト値を監査できます。

内容は次のとおりです。

- アプリケーション・コンテキスト値の監査について

- アプリケーション・コンテキストの監査設定の構成

- アプリケーション・コンテキストの監査設定の無効化

- 例: デフォルト・データベースでのアプリケーション・コンテキスト値の監査

- 例: Oracle Label Securityのアプリケーション・コンテキスト値の監査

- 監査証跡での監査対象のアプリケーション・コンテキストの表示方法

アプリケーション・コンテキスト値の監査について

統合監査証跡でアプリケーション・コンテキスト値を取得できます。

この機能では、監査対象の文の実行中にデータベース・アプリケーションによって設定されるアプリケーション・コンテキスト値を取得します。

Oracle Label Securityを監査する場合は、この機能により、データベース監査証跡のセッション・ラベルのアクティビティが取得されます。監査証跡では、指定したコンテキストと属性値のペアで取得されたすべての値が記録されます。

アプリケーション・コンテキストの監査設定または監査ポリシーには、セッションの静的セマンティクがあります。つまり、ユーザーに対して新しいポリシーが有効になると、後続のユーザー・セッションにこのコマンドの結果が表示されます。セッションが確立されると、ポリシーとコンテキストの設定がロードされ、このセッションは後続のAUDIT文の影響を受けません。

マルチテナント環境では、アプリケーション・コンテキストの監査ポリシーは現在のPDBのみに適用されます。

関連項目:

- アプリケーション・コンテキストの詳細は、「アプリケーション・コンテキストを使用したユーザー情報の取得」を参照してください。

- マルチテナント環境での統合監査ポリシーまたはAUDIT設定の使用

- Oracle Label Securityの詳細は、『Oracle Label Security管理者ガイド』を参照してください。

アプリケーション・コンテキストの監査設定の構成

CONTEXTキーワードを使用したAUDIT文で、アプリケーション・コンテキスト値の監査を構成します。

このタイプの監査では、統合監査ポリシーを作成しません。

- 次の構文を使用して、アプリケーション・コンテキスト値の監査を構成します。

AUDIT CONTEXT NAMESPACE context_name1 ATTRIBUTES attribute1 [, attribute2]
[, CONTEXT NAMESPACE context_name2 ATTRIBUTES attribute1 [, attribute2]]
[BY user_list];

次のように値を指定します。

- context_name1: オプションでCONTEXTの名前と属性のペアを1つ追加できます。

- user_listは、データベース・ユーザー・アカウントのオプションのリストです。複数の名前はカンマで区切ります。この設定を省略すると、Oracle Databaseによって、すべてのユーザーにアプリケーション・コンテキスト・ポリシーが構成されます。各ユーザーがログインすると、関連するすべてのアプリケーション・コンテキストと属性のリストがユーザー・セッションでキャッシュされます。

例:

AUDIT CONTEXT NAMESPACE clientcontext3 ATTRIBUTES module, action,
CONTEXT NAMESPACE ols_session_labels ATTRIBUTES ols_pol1, ols_pol3
BY appuser1, appuser2;

現在構成されているアプリケーション・コンテキストの監査設定のリストを検索するには、AUDIT_UNIFIED_CONTEXTSデータ・ディクショナリ・ビューを問い合せます。

アプリケーション・コンテキストの監査設定の無効化

NOAUDIT文で、アプリケーション・コンテキストの監査設定を無効にします。

- アプリケーション・コンテキストの監査設定を無効にするには、NOAUDIT文でネームスペースと属性設定を指定します。属性は任意の順序で入力できます(対応するAUDIT CONTEXT文で使用される順序に一致させる必要はありません)。

例:

NOAUDIT CONTEXT NAMESPACE client_context ATTRIBUTES module,
CONTEXT NAMESPACE ols_session_labels ATTRIBUTES ols_pol1, ols_pol3
BY appuser1, appuser2;

現在監査されているアプリケーション・コンテキストを検索するには、AUDIT_UNIFIED_CONTEXTSデータ・ディクショナリ・ビューを問い合せます。

例: デフォルト・データベースでのアプリケーション・コンテキスト値の監査

AUDIT CONTEXT NAMESPACE文で、アプリケーション・コンテキスト値を監査できます。

例22-17に、ユーザーappuser1によるmoduleおよびaction属性のclientcontextアプリケーション値の監査方法を示します。

例22-17 デフォルト・データベースでのアプリケーション・コンテキスト値の監査

AUDIT CONTEXT NAMESPACE clientcontext ATTRIBUTES module, action
BY appuser1;

例: Oracle Label Securityのアプリケーション・コンテキスト値の監査

AUDIT CONTEXT NAMESPACE文で、Oracle Label Securityのアプリケーション・コンテキスト値を監査できます。

例22-18に、属性ols_pol1およびols_pol2に対して、ols_session_labelsという名前のOracle Label Securityのアプリケーション・コンテキストの監査方法を示します。

例22-18 Oracle Label Securityのアプリケーション・コンテキスト値の監査

AUDIT CONTEXT NAMESPACE ols_session_labels ATTRIBUTES ols_pol1, ols_pol2;

監査証跡での監査対象のアプリケーション・コンテキストの表示方法

UNIFIED_AUDIT_POLICIESデータ・ディクショナリ・ビューはアプリケーション・コンテキストの監査イベントを表示します。

必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAILプロシージャを実行して、監査レコードをディスクに書き込みます。

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューのAPPLICATION_CONTEXTS列には、アプリケーション・コンテキストの監査データが表示されます。アプリケーション・コンテキストは、セミコロンで区切られた値のリストとして表示されます。

例:

SELECT APPLICATION_CONTEXTS FROM UNIFIED_AUDIT_TRAIL
WHERE UNIFIED_AUDIT_POLICIES = 'app_audit_pol';

APPLICATION_CONTEXTS
----------------------------------------------------------
CLIENT_CONTEXT.APPROLE=MANAGER;E2E_CONTEXT.USERNAME=PSMITH

Oracle Database Real Application Securityイベントの監査

CREATE AUDIT POLICY文を使用して、Oracle Database Real Application Securityイベントを監査できます。

内容は次のとおりです。

- Oracle Database Real Application Securityイベントの監査について

- Oracle Database Real Application Securityの監査可能なイベント

- Oracle Database Real Application Securityのユーザーおよびロールの監査イベント

- Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベント

- Oracle Database Real Application Securityのセッションの監査イベント

- Oracle Database Real Application SecurityのALLイベント

- Oracle Database Real Application Securityの統合監査ポリシーの構成

- 例: Real Application Securityのユーザー・アカウントの変更の監査

- 例: Real Application Securityの統合監査ポリシーでの条件の使用

- 監査証跡でのOracle Database Real Application Securityイベントの表示方法

関連項目:

- アプリケーション・コンテキスト値の監査

- Oracle Database Real Application Securityの事前定義の監査ポリシー

- Oracle Database Real Application Securityの詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください

Oracle Database Real Application Securityイベントの監査について

Oracle Database Real Application Securityイベントを監査するには、AUDIT_ADMINロールが必要です。

監査証跡にアクセスするには、Real Application Security固有の列がXS_で始まるUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。

Real Application Security固有のビューは次のとおりです。

- DBA_XS_AUDIT_TRAILでは、監査されたReal Application Securityイベントの詳細情報が提供されます。

- DBA_XS_AUDIT_POLICY_OPTIONSでは、Real Application Securityの統合監査ポリシーに定義された監査オプションを記述します。

- DBA_XS_ENB_AUDIT_POLICIESでは、Real Application Securityの統合監査ポリシーが有効なユーザーのリストを表示します。

Oracle Database Real Application Securityの監査可能なイベント

Oracle Databaseには、CREATE USER、UPDATE USERなど、Real Application Securityの監査可能なイベントが用意されています。

監査可能なReal Application Securityイベントのリストを検索するには、次のように、AUDITABLE_SYSTEM_ACTIONSデータ・ディクショナリ・ビューのCOMPONENTおよびNAME列を問い合せます。

SELECT NAME FROM AUDITABLE_SYSTEM_ACTIONS WHERE COMPONENT = 'XS';

NAME
-------------
CREATE USER
UPDATE USER
DELETE USER
...

関連項目:

- Oracle Database Real Application Securityのユーザーおよびロールの監査イベント

- Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベント

- Oracle Database Real Application Securityのセッションの監査イベント

- Oracle Database Real Application SecurityのALLイベント

Oracle Database Real Application Securityのユーザーおよびロールの監査イベント

統合監査証跡では、ユーザー、権限およびロールについてOracle Database Real Application Securityのイベントを取得できます。

表22-4では、これらのイベントについて説明します。

表22-4 Oracle Database Real Application Securityのユーザーおよびロールの監査イベント

監査イベント

説明

CREATE USER

XS_PRINCIPAL.CREATE_USERプロシージャを使用してOracle Database Real Application Securityのユーザー・アカウントを作成します。

UPDATE USER

次のプロシージャを使用してOracle Database Real Application Securityのユーザー・アカウントを更新します。

- XS_PRINCIPAL.SET_EFFECTIVE_DATES

- XS_PRINCIPAL.SET_USER_DEFAULT_ROLES_ALL

- XS_PRINCIPAL.SET_USER_SCHEMA

- XS_PRINCIPAL.SET_GUID

- XS_PRINCIPAL.SET_USER_STATUS

- XS_PRINCIPAL.SET_DESCRIPTION

DELETE USER

XS_PRINCIPAL.DELETE_PRINCIPALプロシージャを使用してOracle Database Real Application Securityのユーザー・アカウントを削除します。

CREATE ROLE

XS_PRINCIPAL.CREATE_ROLEプロシージャを使用してOracle Database Real Application Securityのロールを作成します。

UPDATE ROLE

次のプロシージャを使用してOracle Database Real Application Securityのロールを更新します。

- XS_PRINCIPAL.SET_DYNAMIC_ROLE_SCOPE

- XS_PRINCIPAL.SET_DYNAMIC_ROLE_DURATION

- XS_PRINCIPAL.SET_EFFECTIVE_DATES

- XS_PRINCIPAL.SET_ROLE_DEFAULT

DELETE ROLE

XS_PRINCIPAL.DELETE_ROLEプロシージャを使用してOracle Database Real Application Securityのロールを削除します。

GRANT ROLE

XS_PRINCIPAL.GRANT_ROLESプロシージャを使用してOracle Database Real Application Securityのロールを付与します。

REVOKE ROLE

XS_PRINCIPAL.REVOKE_ROLESプロシージャを使用してOracle Database Real Application Securityのロールを取り消し、付与されたすべてのロールをXS_PRINCIPAL.REVOKE_ALL_GRANTED_ROLESプロシージャを使用して取り消します。

ADD PROXY

XS_PRINCIPAL.ADD_PROXY_USERプロシージャを使用してOracle Database Real Application Securityのプロキシ・ユーザー・アカウントを追加し、データベース・ユーザーに追加されたプロキシをXS_PRINCIPAL.ADD_PROXY_TO_SCHEMAプロシージャを使用して追加します。

REMOVE PROXY

XS_PRINCIPAL.REMOVE_PROXY_USER、XS_PRINCIPAL.REMOVE_ALL_PROXY_USERSおよびXS_PRINCIPAL.REMOVE_PROXY_FROM_SCHEMA PROCEDURESを使用して、Oracle Database Real Application Securityのプロキシ・ユーザー・アカウントを削除します。

SET USER PASSWORD

XS_PRINCIPAL.SET_PASSWORDプロシージャを使用してOracle Database Real Application Securityのユーザー・アカウントのパスワードを設定します。

SET USER VERIFIER

XS_PRINCIPAL.SET_VERIFIERプロシージャを使用してOracle Database Real Application Securityのプロキシ・ユーザー・アカウントのベリファイアを設定します。

Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベント

統合監査証跡では、Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベントを取得できます。

表22-5では、これらのイベントについて説明します。

表22-5 Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベント

監査イベント

説明

CREATE SECURITY CLASS

XS_SECURITY_CLASS.CREATE_SECURITY_CLASSプロシージャを使用してセキュリティ・クラスを作成します。

UPDATE SECURITY CLASS

次のプロシージャを使用してセキュリティ・クラスを作成します。

- XS_SECURITY_CLASS.SET_DEFAULT_ACL

- XS_SECURITY_CLASS.ADD_PARENTS

- XS_SECURITY_CLASS.REMOVE_ALL_PARENTS

- XS_SECURITY_CLASS.REMOVE_PARENTS

- XS_SECURITY_CLASS.ADD_PRIVILEGES

- XS_SECURITY_CLASS.REMOVE_ALL_PRIVILEGES

- XS_SECURITY_CLASS.ADD_IMPLIED_PRIVILEGES

- XS_SECURITY_CLASS.REMOVE_IMPLIED_PRIVILEGES

- XS_SECURITY_CLASS.REMOVE_ALL_IMPLIED_PRIVILEGES

- XS_SECURITY_CLASS.SET_DESCRIPTION

DELETE SECURITY CLASS

XS_SECURITY_CLASS.DELETE_SECURITY_CLASSプロシージャを使用してセキュリティ・クラスを削除します。

CREATE ACL

XS_ACL.CREATE_ACLプロシージャを使用してアクセス制御リスト(ACL)を作成します。

UPDATE ACL

次のプロシージャを使用してACLを更新します。

- XS_ACL.APPEND_ACES

- XS_ACL.REMOVE_ALL_ACES

- XS_ACL.SET_SECURITY_CLASS

- XS_ACL.SET_PARENT_ACL

- XS_ACL.ADD_ACL_PARAMETER

- XS_ACL.REMOVE_ALL_ACL_PARAMETERS

- XS_ACL.REMOVE_ACL_PARAMETER

- XS_ACL.SET_DESCRIPTION

DELETE ACL

XS_ACL.DELETE_ACLプロシージャを使用してACLを削除します。

CREATE DATA SECURITY-

XS_DATA_SECURITY.CREATE_DATA_SECURITYプロシージャを使用してデータ・セキュリティ・ポリシーを作成します。

UPDATE DATA SECURITY

次のプロシージャを使用してデータ・セキュリティ・ポリシーを更新します。

- XS_DATA_SECURITY.CREATE_ACL_PARAMETER

- XS_DATA_SECURITY.DELETE_ACL_PARAMETER

- XS_DATA_SECURITY.SET_DESCRIPTION

DELETE DATA SECURITY

XS_DATA_SECURITY.DELETE_DATA_SECURITYプロシージャを使用してデータ・セキュリティ・ポリシーを削除します。

ENABLE DATA SECURITY

XS_DATA_SECURITY.ENABLE_OBJECT_POLICYプロシージャを使用して、データベース表またはビューの拡張可能データ・セキュリティを有効にします。

DISABLE DATA SECURITY

XS_DATA_SECURITY.DISABLE_XDSプロシージャを使用して、データベース表またはビューの拡張可能データ・セキュリティを無効にします。

Oracle Database Real Application Securityのセッションの監査イベント

統合監査証跡では、Oracle Database Real Application Securityのセッションの監査イベントを取得できます。

表22-4では、これらのイベントについて説明します。

表22-6 Oracle Database Real Application Securityのセッションの監査イベント

監査イベント

説明

CREATE SESSION

DBMS_XS_SESSIONS.CREATE_SESSIONプロシージャを使用してセッションを作成します。

DESTROY SESSION

DBMS_XS_SESSIONS.DESTROY_SESSIONプロシージャを使用してセッションを破棄します。

CREATE SESSION NAMESPACE

DBMS_XS_SESSIONS.CREATE_NAMESPACEプロシージャを使用してネームスペースを作成します。

DELETE SESSION NAMESPACE

DBMS_XS_SESSIONS.DELETE_NAMESPACEプロシージャを使用してネームスペースを削除します。

CREATE NAMESPACE ATTRIBUTE

DBMS_XS_SESSIONS.CREATE_ATTRIBUTEプロシージャを使用してネームスペース属性を作成します。

SET NAMESPACE ATTRIBUTE

DBMS_XS_SESSIONS.SET_ATTRIBUTEプロシージャを使用してネームスペース属性を設定します。

GET NAMESPACE ATTRIBUTE

DBMS_XS_SESSIONS.GET_ATTRIBUTEプロシージャを使用してネームスペース属性を取得します。

DELETE NAMESPACE ATTRIBUTE

DBMS_XS_SESSIONS.DELETE_ATTRIBUTEプロシージャを使用してネームスペース属性を削除します。

CREATE NAMESPACE TEMPLATE

XS_NS_TEMPLATE.CREATE_NS_TEMPLATEプロシージャを使用してネームスペース属性を作成します。

UPDATE NAMESPACE TEMPLATE

次のプロシージャを使用してネームスペース属性を更新します。

- XS_NS_TEMPLATE.SET_HANDLER

- XS_NS_TEMPLATE.ADD_ATTRIBUTES

- XS_NS_TEMPLATE.REMOVE_ALL_ATTRIBUTES

- XS_NS_TEMPLATE.REMOVE_ATTRIBUTES

- XS_NS_TEMPLATE.SET_DESCRIPTION

DELETE NAMESPACE TEMPLATE

XS_NS_TEMPLATE.DELETE_NS_TEMPLATEプロシージャを使用してネームスペースを削除します。

ADD GLOBAL CALLBACK

DBMS_XS_SESSIONS.ADD_GLOBAL_CALLBACKプロシージャを使用してグローバル・コールバックを追加します。

DELETE GLOBAL CALLBACK

DBMS_XS_SESSIONS.DELETE_GLOBAL_CALLBACKプロシージャを使用してグローバル・コールバックを削除します。

ENABLE GLOBAL CALLBACK

DBMS_XS_SESSIONS.ENABLE_GLOBAL_CALLBACKプロシージャを使用してグローバル・コールバックを有効にします。

SET COOKIE

DBMS_XS_SESSIONS.SET_SESSION_COOKIEプロシージャを使用してセッションCookieを設定します。

SET INACTIVE TIMEOUT

DBMS_XS_SESSIONS.SET_INACTIVITY_TIMEOUTプロシージャを使用して、無効なセッションのタイムアウト時間を設定します。

SWITCH USER

DBMS_XS_SESSIONS.SWITCH_USERプロシージャを使用して、指定したユーザーで新しく初期化されたセキュリティ・コンテキストに現在の軽量ユーザー・セッションのセキュリティ・コンテキストを設定します。

ASSIGN USER

DBMS_XS_SESSIONS.ASSIGN_USERプロシージャを使用して、指定したユーザーに対して動的ロールを1つ以上割り当てまたは削除します。

ENABLE ROLE

DBMS_XS_SESSIONS.ENABLE_ROLEプロシージャを使用して、軽量ユーザー・セッションのロールを有効にします。

DISABLE ROLE

DBMS_XS_SESSIONS.DISABLE_ROLEプロシージャを使用して、軽量ユーザー・セッションのロールを無効にします。

Oracle Database Real Application SecurityのALLイベント

統合監査証跡では、Oracle Database Real Application SecurityのALLイベントを取得できます。

表22-7では、これらのイベントについて説明します。

表22-7 Oracle Database Real Application SecurityのALLイベント

監査イベント

説明

ALL

Real Application Securityのすべてのアクションを取得します。

Oracle Database Real Application Securityの統合監査ポリシーの構成

CREATE AUDIT POLICY文で、Oracle Real Application Securityの統合監査ポリシーを作成できます。

- 次の構文を使用して、Oracle Database Real Application Securityの統合監査ポリシーを作成します。

CREATE AUDIT POLICY policy_name
ACTIONS COMPONENT=XS component_action1 [, action2];

例:

CREATE AUDIT POLICY audit_ras_pol
ACTIONS COMPONENT=XS SWITCH USER, DISABLE ROLE;

条件を含む場合など、より複雑なポリシーを作成できます。ポリシーを作成したら、AUDIT文を使用して有効にする必要があります。

関連項目:
統合監査ポリシーの作成の構文

例: Real Application Securityのユーザー・アカウントの変更の監査

CREATE AUDIT POLICY文で、Real Application Securityのユーザー・アカウントの変更を監査できます。

例22-19に、ユーザーbhurstによるユーザーの切替えとロールの無効化の試行を監査する方法を示します。

例22-19 Real Application Securityのユーザー・アカウントの変更の監査

CREATE AUDIT POLICY ras_users_pol
ACTIONS COMPONENT=XS SWITCH USER, DISABLE ROLE;

AUDIT POLICY ras_users_pol BY bhurst;

例: Real Application Securityの統合監査ポリシーでの条件の使用

CREATE AUDIT POLICY文で、Real Application Securityの統合監査ポリシーの条件を設定できます。

例22-20に、nemosityコンピュータ・ホストからのアクションのみに監査を適用するReal Application Securityの統合監査ポリシーを作成する方法を示します。

例22-20 Real Application Securityの統合監査ポリシーでの条件の使用

CREATE AUDIT POLICY ras_acl_pol
ACTIONS DELETE ON OE.CUSTOMERS
ACTIONS COMPONENT=XS CREATE ACL, UPDATE ACL, DELETE ACL
WHEN 'SYS_CONTEXT(''USERENV'', ''HOST'') = ''nemosity'''
EVALUATE PER INSTANCE;

AUDIT POLICY ras_acl_pol BY pfitch;

監査証跡でのOracle Database Real Application Securityイベントの表示方法

DBA_XS_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Real Application Securityの監査イベントを表示します。

必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAILプロシージャを実行して、監査レコードをディスクに書き込みます。

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。

次の例では、Real Application Security固有のビューのDBA_XS_AUDIT_TRAILを問い合せます。

SELECT XS_USER_NAME FROM DBA_XS_AUDIT_TRAIL
WHERE XS_ENABLED_ROLE = 'CLERK';

XS_USER_NAME
-------------
USER2

Oracle Recovery Managerイベントの監査

CREATE AUDIT POLICY文を使用して、Oracle Recovery Managerイベントを監査できます。

内容は次のとおりです。

- Oracle Recovery Managerイベントの監査について

- Oracle Recovery Managerの統合監査証跡イベント

- 監査証跡でのOracle Recovery Managerの監査イベントの表示方法

関連項目:

『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

Oracle Recovery Managerイベントの監査について

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューでは、Oracle Recovery Managerの監査イベントをRMAN_columnに自動的に格納します。

他のOracle Databaseコンポーネントと異なり、Oracle Recovery Managerのイベントには統合監査ポリシーを作成しません。

ただし、UNIFIED_AUDIT_TRAILビューを問い合せて、これらのイベントを確認するには、AUDIT_ADMINまたはAUDIT_VIEWERロールが必要です。SYSBACKUPまたはSYSDBA管理権限がない場合は、V$RMAN_STATUSやV$RMAN_BACKUP_JOB_DETAILSなどのビューを問い合せて、Recovery Managerジョブに関する追加情報を検索できます。

関連項目:

『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

Oracle Recovery Managerの統合監査証跡イベント

統合監査証跡では、Oracle Recovery Managerのイベントを取得します。

表22-8では、これらのイベントについて説明します。

表22-8 UNIFIED_AUDIT_TRAILビューのOracle Recovery Manager列

Recovery Managerの列

説明

RMAN_SESSION_RECID

Recovery Managerのセッション識別子。この列とRMAN_SESSION_STAMP列を組み合せることで、Recovery Managerジョブを一意に識別します。Recovery ManagerのセッションIDは、Recovery Managerジョブを識別する制御ファイルのRECID値です。(Recovery ManagerのセッションIDはユーザー・セッションIDと同じではありません。)

RMAN_SESSION_STAMP

セッションのタイムスタンプ。この列とRMAN_SESSION_RECID列を組み合せることで、Recovery Managerジョブを識別します。

RMAN_OPERATION

ジョブによって実行されるRecovery Manager操作。Recovery Managerのセッション内の操作ごとに行が1つ追加されます。たとえば、バックアップ・ジョブには、BACKUPがRMAN_OPERATION値として含まれます。

RMAN_OBJECT_TYPE

Recovery Managerのセッションに含まれるオブジェクトのタイプ。これには、次のいずれかの値が含まれます。Recovery Managerのセッションがこれらの複数を満たさない場合は、プリファレンスが次の順序(リストの上から下)で指定されます。

1. DB FULL (Database Full)は、データベースの全体バックアップを示します。

2. RECVR AREAは、高速リカバリ領域を示します。

3. DB INCR (Database Incremental)は、データベースの増分バックアップを示します。

4. DATAFILE FULLは、データ・ファイルの全体バックアップを示します。

5. DATAFILE INCRは、データ・ファイルの増分バックアップを示します。

6. ARCHIVELOGは、アーカイブREDOログ・ファイルを示します。

7. CONTROLFILEは、制御ファイルを示します。

8. SPFILEは、サーバー・パラメータ・ファイルを示します。

9. BACKUPSETは、バックアップ・ファイルを示します。

RMAN_DEVICE_TYPE

Recovery Managerのセッションに関連付けられているデバイス。この列は、DISK、SBT (システム・バックアップ・テープ)または* (アスタリスク)になります。アスタリスクは、複数のデバイスを示します。ほとんどの場合、値はDISKおよびSBTになります。

監査証跡でのOracle Recovery Managerの監査イベントの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Recovery Managerの監査イベントを表示します。

必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAILプロシージャを実行して、監査レコードをディスクに書き込みます。

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。

表22-8に、Oracle Recovery Manager固有の監査データを検索するために問合せ可能な、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューの列を示します。

例:

SELECT RMAN_OPERATION FROM UNIFIED_AUDIT_TRAIL
WHERE RMAN_OBJECT_TYPE = 'DB FULL';

RMAN_OPERATION
---------------
BACKUP

Oracle Database Vaultイベントの監査

Oracle Database Vault環境で、CREATE AUDIT POLICY文を使用してDatabase Vaultアクティビティを監査できます。

内容は次のとおりです。

- Oracle Database Vaultイベントの監査について

- Oracle Database Vaultの監査者

- Oracle Database Vaultの統合監査証跡イベントについて

- Oracle Database Vaultのレルムの監査イベント

- Oracle Database Vaultのルール・セットおよびルールの監査イベント

- Oracle Database Vaultのコマンド・ルールの監査イベント

- Oracle Database Vaultのファクタの監査イベント

- Oracle Database Vaultのセキュア・アプリケーション・ロールの監査イベント

- Oracle Database Vault Oracle Label Securityの監査イベント

- Oracle Database Vault Oracle Data Pumpの監査イベント

- Oracle Database Vaultの有効および無効な監査イベント

- Oracle Database Vaultの統合監査ポリシーの構成

- 例: 2つのOracle Database Vaultイベントの監査

- 例: Oracle Database Vaultのファクタの監査

- 監査証跡でのOracle Database Vaultの監査イベントの表示方法

関連項目:

- Oracle Database Vaultの事前定義の統合監査ポリシー

- Oracle Database Vaultの監査ポリシーの詳細は、『Oracle Database Vault管理者ガイド』を参照してください

Oracle Database Vaultイベントの監査について

すべての統合監査と同様、Oracle Database Vaultのイベントを監査するには、AUDIT_ADMINロールが必要です。

Oracle Database Vaultの統合監査ポリシーを作成するには、CREATE AUDIT POLICY文のCOMPONENT句をDVに設定し、Rule Set Failureなどのアクションおよびルール・セットの名前などのオブジェクトを指定します。

監査証跡にアクセスする場合は、次のビューを問い合せることができます。

- UNIFIED_AUDIT_TRAIL

- SYS.DV$CONFIGURATION_AUDIT

- SYS.DV$ENFORCEMENT_AUDIT

UNIFIED_AUDIT_TRAILビューでは、Oracle Database Vault固有の列はDV_で始まります。UNIFIED_AUDIT_TRAILビューを問い合せるには、AUDIT_VIEWERロールが必要です。

これらのビューに加えて、Database Vaultレポートでは、Database Vault固有の統合監査ポリシーの結果も取得します。

関連項目:

- Oracle Database Vaultの事前定義の統合監査ポリシー

- Oracle Database Vaultの監査ポリシーの詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

Oracle Database Vaultの監査者

Oracle Database Vaultの監査対象ユーザーには、Database Vault管理者、およびアクティビティがDatabase Vaultの規定ポリシーに影響するユーザーが含まれます。

これらのユーザーは次のとおりです。

- Database Vault管理者。Oracle Database Vaultに対して行われるすべての構成変更は、強制的に監査されます。監査では、レルム、ファクタ、コマンド・ルール、ルール・セット、ルールなどの作成、変更、削除などのアクティビティを取得します。SYS.DV$CONFIGURATION_AUDITデータ・ディクショナリ・ビューでは、Database Vault管理者によって実行された構成変更を取得します。

- アクティビティがOracle Database Vaultの規定ポリシーに影響するユーザー。SYS.DV$ENFORCEMENT_AUDITデータ・ディクショナリ・ビューでは、規定関連の監査を取得します。

関連項目:

SYS.DV$CONFIGURATION_AUDITおよびSYS.DV$ENFORCEMENT_AUDITデータ・ディクショナリ・ビューの詳細は、Oracle Database Vault管理者ガイドを参照してください

Oracle Database Vaultの統合監査証跡イベントについて

Oracle Database Vault環境の監査証跡は、すべての構成変更やDatabase Vaultポリシーの変更の試行を取得します。

これは、既存のDatabase Vaultのポリシーに対するユーザーの違反も取得します。

次の種類のOracle Database Vaultイベントを監査できます。

- Oracle Database Vaultのポリシーに対するすべての構成変更または変更の試行。Database Vault管理者による変更および権限のないユーザーによる試行の両方が取得されます。

- 既存のDatabase Vaultのポリシーに対するユーザーの違反。たとえば、ユーザーが作業時間以外に特定のスキーマ表にアクセスできないようにするポリシーを作成すると、監査証跡によって、このアクティビティが取得されます。

Oracle Database Vaultのレルムの監査イベント

統合監査証跡によってOracle Database Vaultのレルムのイベントが取得されます。

表22-9では、これらのイベントについて説明します。

表22-9 Oracle Database Vaultのレルムの監査イベント

監査イベント

説明

CREATE_REALM

DVSYS.DBMS_MACADM.CREATE_REALMプロシージャを使用してレルムを作成します。

UPDATE_REALM

DVSYS.DBMS_MACADM.UPDATE_REALMプロシージャを使用してレルムを更新します。

RENAME_REALM

DVSYS.DBMS_MACADM.RENAME_REALMプロシージャを使用してレルムの名前を変更します。

DELETE_REALM

DVSYS.DBMS_MACADM.DELETE_REALMプロシージャを使用してレルムを削除します。

DELETE_REALM_CASCADE

DVSYS.DBMS_MACADM.DELETE_REALM_CASCADEプロシージャを使用して、レルムおよび関連するDatabase Vaultの構成情報を削除します。

ADD_AUTH_TO_REALM

DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALMプロシージャを使用して、レルムに認可を追加します。

DELETE_AUTH_FROM_REALM

DVSYS.DBMS_MACADM.DELETE_AUTH_FROM_REALMプロシージャを使用して、レルムから認可を削除します。

UPDATE_REALM_AUTH

DVSYS.DBMS_MACADM.UPDATE_REALM_AUTHORIZATIONプロシージャを使用して、レルム認可を更新します。

ADD_OBJECT_TO_REALM

DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALMプロシージャを使用して、レルム認可にオブジェクトを追加します。

DELETE_OBJECT_FROM_REALM

DVSYS.DBMS_MACADM.DELETE_OBJECT_FROM_REALMプロシージャを使用して、レルム認可からオブジェクトを削除します。

Oracle Database Vaultのルール・セットおよびルールの監査イベント

統合監査証跡では、Oracle Database Vaultのルール・セットおよびルールの監査イベントを取得できます。

表22-10では、これらのイベントについて説明します。

表22-10 Oracle Database Vaultのルール・セットおよびルールの監査イベント

監査イベント

説明

CREATE_RULE_SET

DVSYS.DBMS_MACADM.CREATE_RULE_SETプロシージャを使用してルール・セットを作成します。

UPDATE_RULE_SET

DVSYS.DBMS_MACADM.UPDATE_RULE_SETプロシージャを使用してルール・セットを更新します。

RENAME_RULE_SET

DVSYS.DBMS_MACADM.RENAME_RULE_SETプロシージャを使用して、ルール・セットの名前を変更します。

DELETE_RULE_SET

DVSYS.DBMS_MACADM.DELETE_RULE_SETプロシージャを使用して、ルール・セットを削除します。

ADD_RULE_TO_RULE_SET

DVSYS.DBMS_MACADM.ADD_RULE_TO_RULE_SETプロシージャを使用して、既存のルール・セットにルールを追加します。

DELETE_RULE_FROM_RULE_SET

DVSYS.DBMS_MACADM.DELETE_RULE_FROM_RULE_SETプロシージャを使用して、既存のルール・セットからルールを削除します。

CREATE_RULE

DVSYS.DBMS_MACADM.CREATE_RULEプロシージャを使用してルールを作成します。

UPDATE_RULE

DVSYS.DBMS_MACADM.UPDATE_RULEプロシージャを使用してルールを更新します。

RENAME_RULE

DVSYS.DBMS_MACADM.RENAME_RULEプロシージャを使用して、ルールの名前を変更します。

DELETE_RULE

DVSYS.DBMS_MACADM.DELETE_RULEプロシージャを使用して、ルールを削除します。

SYNC_RULES

DVSYS.DBMS_MACADM.SYNC_RULESプロシージャを使用して、Oracle Database Vaultのルールとアドバンスト・キューイング・ルール・エンジンを同期します。

Oracle Database Vaultのコマンド・ルールの監査イベント

統合監査証跡では、Oracle Database Vaultのコマンド・ルールの監査イベントを取得できます。

表22-11では、これらのイベントについて説明します。

表22-11 Oracle Database Vaultのコマンド・ルールの監査イベント

監査イベント

説明

CREATE_COMMAND_RULE

DVSYS.DBMS_MACADM.CREATE_COMMAND_RULEプロシージャを使用して、コマンド・ルールを作成します。

DELETE_COMMAND_RULE

DVSYS.DBMS_MACADM.DELETE_COMMAND_RULEプロシージャを使用して、コマンド・ルールを削除します。

UPDATE_COMMAND_RULE

DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULEプロシージャを使用して、コマンド・ルールを更新します。

Oracle Database Vaultのファクタの監査イベント

統合監査証跡では、Oracle Database Vaultのファクタ・イベントを取得できます。

表22-12では、これらのイベントについて説明します。

表22-12 Oracle Database Vaultのファクタの監査イベント

監査イベント

説明

CREATE_FACTOR_TYPE

DVSYS.DBMS_MACADM.CREATE_FACTOR_TYPEプロシージャを使用して、ファクタ・タイプを作成します。

DELETE_FACTOR_TYPE

DVSYS.DBMS_MACADM.DELETE_FACTOR_TYPEプロシージャを使用して、ファクタ・タイプを削除します。

UPDATE_FACTOR_TYPE

DVSYS.DBMS_MACADM.UPDATE_FACTOR_TYPEプロシージャを使用して、ファクタ・タイプを更新します。

RENAME_FACTOR_TYPE

DVSYS.DBMS_MACADM.RENAME_FACTOR_TYPEプロシージャを使用して、ファクタ・タイプの名前を変更します。

CREATE_FACTOR

DVSYS.DBMS_MACADM.CREATE_FACTORプロシージャを使用して、ファクタを作成します。

UPDATE_FACTOR

DVSYS.DBMS_MACADM.UPDATE_FACTORプロシージャを使用して、ファクタを更新します。

DELETE_FACTOR

DVSYS.DBMS_MACADM.DELETE_FACTORプロシージャを使用して、ファクタを削除します。

RENAME_FACTOR

DVSYS.DBMS_MACADM.RENAME_FACTORプロシージャを使用して、ファクタの名前を変更します。

ADD_FACTOR_LINK

DVSYS.DBMS_MACADM.ADD_FACTOR_LINKプロシージャを使用して、2つのファクタの親子関係を指定します。

DELETE_FACTOR_LINK

DVSYS.DBMS_MACADM.DELETE_FACTOR_LINKプロシージャを使用して、2つのファクタの親子関係を削除します。

ADD_POLICY_FACTOR

DVSYS.DBMS_MACADM.ADD_POLICY_FACTORプロシージャを使用して、ファクタのラベルをポリシーのOracle Label Securityラベルに含めることを指定します。

DELETE_POLICY_FACTOR

DBMS_MACADM.DELETE_POLICY_FACTORプロシージャを使用して、ポリシーのOracle Label Securityラベルとの関連付けからファクタ・ラベルを削除します。

CREATE_IDENTITY

DVSYS.DBMS_MACADM.CREATE_IDENTITYプロシージャを使用して、ファクタ・アイデンティティを作成します。

UPDATE_IDENTITY

DVSYS.DBMS_MACADM.UPDATE_IDENTITYプロシージャを使用して、ファクタ・アイデンティティを更新します。

CHANGE_IDENTITY_FACTOR

DVSYS.DBMS_MACADM.CHANGE_IDENTITY_FACTORプロシージャを使用して、アイデンティティを異なるファクタに関連付けます。

CHANGE_IDENTITY_VALUE

DVSYS.DBMS_MACADM.CHANGE_IDENTITY_VALUEプロシージャを使用して、アイデンティティの値を更新します。

DELETE_IDENTITY

DVSYS.DBMS_MACADM.DELETE_IDENTITYプロシージャを使用して、既存のファクタ・アイデンティティを削除します。

CREATE_IDENTITY_MAP

DVSYS.DBMS_MACADM.CREATE_IDENTITY_MAPプロシージャを使用して、ファクタ・アイデンティティ・マップを作成します。

DELETE_IDENTITY_MAP

DVSYS.DBMS_MACADM.DELETE_IDENTITY_MAPプロシージャを使用して、ファクタ・アイデンティティ・マップを削除します。

CREATE_DOMAIN_IDENTITY

DVSYS.DBMS_MACADM.CREATE_DOMAIN_IDENTITYプロシージャを使用して、Oracle Database Real Application Clustersデータベース・ノードをドメイン・ファクタ・アイデンティティに追加し、Oracle Label Securityポリシーに従ってラベルを付けます。

DROP_DOMAIN_IDENTITY

DVSYS.DBMS_MACADM.DROP_DOMAIN_IDENTITYプロシージャを使用して、ドメイン・ファクタ・アイデンティティからOracle RACノードを削除します。

Oracle Database Vaultのセキュア・アプリケーション・ロールの監査イベント

統合監査証跡では、Oracle Database Vaultのセキュア・アプリケーション・ロールの監査イベントを取得できます。

表22-13では、これらのイベントについて説明します。

表22-13 Oracle Database Vaultのセキュア・アプリケーション・ロールの監査イベント

監査イベント

説明

CREATE_ROLE

DVSYS.DBMS_MACADM.CREATE_ROLEプロシージャを使用して、Oracle Database Vaultのセキュア・アプリケーション・ロールを作成します。

DELETE_ROLE

DVSYS.DBMS_MACADM.DELETE_ROLEプロシージャを使用して、Oracle Database Vaultのセキュア・アプリケーション・ロールを削除します。

UPDATE_ROLE

DVSYS.DBMS_MACADM.UPDATE_ROLEプロシージャを使用して、Oracle Database Vaultのセキュア・アプリケーション・ロールを更新します。

RENAME_ROLE

DVSYS.DBMS_MACADM.RENAME_ROLEプロシージャを使用して、Oracle Database Vaultのセキュア・アプリケーション・ロールの名前を変更します。

Oracle Database Vault Oracle Label Securityの監査イベント

統合監査証跡では、Oracle Database Vault Oracle Label Securityの監査イベントを取得できます。

表22-14では、これらのイベントについて説明します。

表22-14 Oracle Database Vault Oracle Label Securityの監査イベント

監査イベント

説明

CREATE_POLICY_LABEL

DVSYS.DBMS_MACADM.CREATE_POLICY_LABELプロシージャを使用して、Oracle Label Securityのポリシー・ラベルを作成します。

DELETE_POLICY_LABEL

DVSYS.DBMS_MACADM.DELETE_POLICY_LABELプロシージャを使用して、Oracle Label Securityのポリシー・ラベルを削除します。

CREATE_MAC_POLICY

DVSYS.DBMS_MACADM.CREATE_MAC_POLICYを使用して、ファクタのラベルまたはOracle Label Securityセッション・ラベルを算出する際にラベルのマージに使用されるアルゴリズムを指定します。

UPDATE_MAC_POLICY

DVSYS.DBMS_MACADM.UPDATE_MAC_POLICYプロシージャを使用して、Oracle Label Securityのラベルのマージ・アルゴリズムを変更します。

DELETE_MAC_POLICY_CASCADE

DVSYS.DBMS_MACADM.DELETE_MAC_POLICY_CASCADEプロシージャを使用して、Oracle Label Securityポリシーに関連するOracle Database Vaultのすべてのオブジェクトを削除します。

Oracle Database Vault Oracle Data Pumpの監査イベント

統合監査証跡では、Oracle Database Vault Oracle Data Pumpの監査イベントを取得できます。

表22-15では、これらのイベントについて説明します。

表22-15 Oracle Database Vault Oracle Data Pumpの監査イベント

監査イベント

説明

AUTHORIZE_DATAPUMP_USER

DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャを使用して、Oracle Data Pumpユーザーに権限を付与します。

UNAUTHORIZE_DATAPUMP_USER

DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USERプロシージャを使用して、Oracle Data Pumpユーザーを認可から削除します。

Oracle Database Vaultの有効および無効な監査イベント

統合監査証跡では、Oracle Database Vaultの有効および無効な監査イベントを取得できます。

表22-16では、これらのイベントについて説明します。

表22-16 Oracle Database Vaultの有効および無効な監査イベント

イベント

説明

ENABLE_EVENT

DBMS_MACADM.ENABLE_EVENT

DISABLE_EVENT

DBMS_MACADM.DISABLE_EVENT

Oracle Database Vaultの統合監査ポリシーの構成

CREATE AUDIT POLICY文のACTIONSおよびACTIONS COMPONENT句で、Oracle Database Vaultイベントの統合監査ポリシーを作成できます。

- 次の構文を使用して、Oracle Database Vaultの統合監査ポリシーを作成します。

CREATE AUDIT POLICY policy_name
ACTIONS action1 [,action2 ]
ACTIONS COMPONENT= DV DV_action ON DV_object [,DV_action2 ON DV_object2]

次のように値を指定します。

- DV_actionは次のいずれかになります。

- Realm Violation、Realm Success、Realm Access

- Rule Set Failure、Rule Set Success、Rule Set Eval

- Factor Error、Factor Null、Factor Validate Error、Factor Validate False、Factor Trust Level Null、Factor Trust Level Neg、Factor All

- DV_objectsは次のいずれかになります。

- Realm_Name

- Rule_Set_Name

- Factor_Name

オブジェクトが小文字または大/小文字が混在して作成された場合は、DV_objectsを二重引用符で囲みます。オブジェクトをすべて大文字で作成した場合は、引用符を省略できます。

たとえば、Database Vaultアカウント管理レルムのレルム違反を監査するには、次のようにします。

CREATE AUDIT POLICY audit_dv
ACTIONS CREATE TABLE, SELECT
ACTIONS COMPONENT=DV Realm Violation ON "Database Vault Account Management";

条件を含む場合など、より複雑なポリシーを作成できます。ポリシーを作成したら、AUDIT文を使用して有効にする必要があります。

例: 2つのOracle Database Vaultイベントの監査

CREATE AUDIT POLICY文で、複数のOracle Database Vaultイベントを監査できます。

例22-21に、レルム違反およびルール・セット失敗の監査方法を示します。

例22-21 2つのOracle Database Vaultイベントの監査

CREATE AUDIT POLICY audit_dv
ACTIONS CREATE TABLE, SELECT
ACTIONS COMPONENT=DV REALM VIOLATION ON "Oracle Enterprise Manager", Rule Set
Failure ON "Allow Sessions";

AUDIT POLICY audit_dv EXCEPT psmith;

例: Oracle Database Vaultのファクタの監査

CREATE AUDIT POLICY文で、Oracle Database Vaultのファクタを監査できます。

例22-22に、1つのファクタで2つのタイプのエラーを監査する方法を示します。

例22-22 Oracle Database Vaultのファクタ設定の監査

CREATE AUDIT POLICY audit_dv_factor
ACTIONS COMPONENT=DV FACTOR ERROR ON "Database_Domain", Factor Validate Error ON "Client_IP";

AUDIT POLICY audit_dv_factor;

監査証跡でのOracle Database Vaultの監査イベントの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Database Vaultの監査イベントを表示します。

必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAILプロシージャを実行して、監査レコードをディスクに書き込みます。

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。

UNIFIED_AUDIT_TRAILビューのDV_*列は、Oracle Database Vault固有の監査データを示します。

例:

SELECT DV_RULE_SET_NAME FROM UNIFIED_AUDIT_TRAIL
WHERE ACTION_NAME = 'UPDATE';

DV_RULE_SET_NAME
-----------------------
Allow System Parameters

Oracle Label Securityイベントの監査

Oracle Label Securityが有効な場合、CREATE AUDIT POLICY文を使用してOracle Label Securityイベントを監査できます。

内容は次のとおりです。

- Oracle Label Securityイベントの監査について

- Oracle Label Securityの統合監査証跡イベント

- Oracle Label Securityの監査可能なユーザー・セッション・ラベル

- Oracle Label Securityの統合監査ポリシーの構成

- 例: Oracle Label Securityのセッション・ラベル属性の監査

- 例: Oracle Label Securityポリシーからのユーザーの除外

- 例: Oracle Label Securityのポリシー・アクションの監査

- 監査証跡でのOracle Label Securityの監査イベントの表示方法

- 例: 監査済のOLSセッション・ラベルの問合せ

関連項目:
Oracle Label Securityのデータ・ディクショナリ・ビューの詳細は、『Oracle Label Security管理者ガイド』を参照してください。

Oracle Label Securityイベントの監査について

Oracle Label Security (OLS)のイベントを監査するには、AUDIT_ADMINロールが必要です。

Oracle Label Securityの統合監査ポリシーを作成するには、CREATE AUDIT POLICY文のCOMPONENT句をOLSに設定する必要があります。

ユーザー・セッション情報を監査するには、AUDIT文を使用して、アプリケーション・コンテキスト値を監査します。

監査証跡にアクセスするには、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。このビューには、名前がOLS_で始まるOracle Label Security固有の列が含まれます。

Oracle Label Securityの統合監査証跡イベント

統合監査証跡では、Oracle Label Securityの監査イベントを取得できます。

監査可能なOracle Label Securityのイベントのリストを検索するには、次のように、AUDITABLE_SYSTEM_ACTIONSデータ・ディクショナリ・ビューのCOMPONENT列およびNAME列を問い合せます。

例:

SELECT NAME FROM AUDITABLE_SYSTEM_ACTIONS WHERE COMPONENT = 'Label Security';

NAME
-------------
CREATE POLICY
ALTER POLICY
DROP POLICY
...

表22-17に、Oracle Label Securityの監査イベントを示します。

表22-17 Oracle Label Securityの監査イベント

監査イベント

説明

CREATE POLICY

SA_SYSDBA.CREATE_POLICYプロシージャを使用して、Oracle Label Securityのポリシーを作成します。

ALTER POLICY

SA_SYSDBA.ALTER_POLICYプロシージャを使用して、Oracle Label Securityのポリシーを変更します。

DROP POLICY

SA_SYSDBA.DROP_POLICYプロシージャを使用して、Oracle Label Securityのポリシーを削除します。

APPLY POLICY

SA_POLICY_ADMIN.APPLY_TABLE_POLICYプロシージャを使用して表ポリシーを適用するか、SA_POLICY_ADMIN.APPLY_SCHEMA_POLICYプロシージャを使用してスキーマ・ポリシーを適用します。

REMOVE POLICY

SA_POLICY_ADMIN.REMOVE_TABLE_POLICYプロシージャを使用して表ポリシーを削除するか、SA_POLICY_ADMIN.REMOVE_SCHEMA_POLICYプロシージャを使用してスキーマ・ポリシーを削除します。

SET AUTHORIZATION

Oracle Label Securityの権限を含むOracle Label Securityのすべての認可を含み、ユーザーまたは信頼できるストアド・プロシージャのいずれかにラベルを使用します。SET AUTHORIZATIONイベントに対応するPL/SQLプロシージャは、SA_USER_ADMIN.SET_USER_LABELS、SA_USER_ADMIN.SET_USER_PRIVSおよびSA_USER_ADMIN.SET_PROG_PRIVSです。

PRIVILEGED ACTION

Oracle Label Securityの権限のユーザーを必要とするアクションを含みます。これらのアクションは、ログオン、SA_SESSION.SET_ACCESS_PROFILEの実行、および信頼できるストアド・プロシージャの起動です。

ENABLE POLICY

次のプロシージャを使用して、Oracle Label Securityのポリシーを有効にします。

- SA_SYSDBA.ENABLE_POLICY: ポリシーで保護されている表およびスキーマにアクセス制御を施行します。

- SA_POLICY_ADMIN.ENABLE_TABLE_POLICY: 指定した表でOracle Label Securityポリシーを有効にします。

- SA_POLICY_ADMIN.ENABLE_SCHEMA_POLICY: 指定したスキーマのすべての表でOracle Label Securityポリシーを有効にします。

DISABLE POLICY

次のプロシージャを使用して、Oracle Label Securityのポリシーを無効にします。

- SA_SYSDBA.DISABLE_POLICY: Oracle Label Securityポリシーの規定を無効にします。

- SA_POLICY_ADMIN.DISABLE_TABLE_POLICY: 指定した表でOracle Label Securityポリシーの規定を無効にします。

- SA_POLICY_ADMIN.DISABLE_SCHEMA_POLICY: 指定したスキーマのすべての表でOracle Label Securityポリシーの規定を無効にします。

SUBSCRIBE OID

SA_POLICY_ADMIN.POLICY_SUBSCRIBEプロシージャを使用して、Oracle Internet Directory対応のOracle Label Securityポリシーをサブスクライブします。

UNSUBSCRIBE OID

SA_POLICY_ADMIN.POLICY_UNSUBSCRIBEプロシージャを使用して、Oracle Internet Directory対応のOracle Label Securityポリシーのサブスクライブを取り消します。

CREATE DATA LABEL

SA_LABEL_ADMIN.CREATE_LABELプロシージャを使用して、Oracle Label Securityのデータ・ラベルを作成します。CREATE DATA LABELは、LBACSYS.TO_DATA_LABELファンクションにも対応します。

ALTER DATA LABEL

SA_LABEL_ADMIN.ALTER_LABELプロシージャを使用して、Oracle Label Securityのデータ・ラベルを変更します。

DROP DATA LABEL

SA_LABEL_ADMIN.DROP_LABELプロシージャを使用して、Oracle Label Securityのデータ・ラベルを削除します。

CREATE LABEL COMPONENT

次のプロシージャを使用して、Oracle Label Securityのコンポーネントを作成します。

- レベル: SA_COMPONENTS.CREATE_LEVEL

- 区分: SA_COMPONENTS.CREATE_COMPARTMENT

- グループ: SA_COMPONENTS.CREATE_GROUP

ALTER LABEL COMPONENTS

次のプロシージャを使用して、Oracle Label Securityのコンポーネントを変更します。

- レベル: SA_COMPONENTS.ALTER_LEVEL

- 区分: SA_COMPONENTS.ALTER_COMPARTMENT

- グループ: SA_COMPONENTS.ALTER_GROUPおよびSA_COMPONENTS.ALTER_GROUP_PARENT

DROP LABEL COMPONENTS

次のプロシージャを使用して、Oracle Label Securityのコンポーネントを削除します。

- レベル: SA_COMPONENTS.DROP_LEVEL

- 区分: SA_COMPONENTS.DROP_COMPARTMENT

- グループ: SA_COMPONENTS.DROP_GROUP

ALL

Oracle Label Securityのすべてのアクションの監査を有効にします。

Oracle Label Securityの監査可能なユーザー・セッション・ラベル

ORA_OLS_SESSION_LABELSアプリケーション・コンテキストで、各Oracle Databaseイベントのユーザー・セッション・ラベルの使用状況を取得できます。

このアプリケーション・コンテキストで使用される属性は、Oracle Label Securityのポリシーを示します。

構文は、アプリケーション・コンテキストの監査設定の構成で説明されているアプリケーション・コンテキストの監査に使用される構文と同じです。次に例を示します。

AUDIT CONTEXT NAMESPACE ORA_SESSION_LABELS ATTRIBUTES policy1, policy2;

セッション・ラベルの記録はユーザー・セッション固有ではないため、BY user_list句は、Oracle Label Securityのアプリケーション・コンテキストには不要です。

ユーザー・セッション・ラベル情報の監査を無効にするには、NOAUDIT文を使用します。たとえば、ポリシーpolicy1およびpolicy2の監査を停止するには、次の文を入力します。

NOAUDIT CONTEXT NAMESPACE ORA_SESSION_LABELS ATTRIBUTES policy1, policy2;

Oracle Label Securityの統合監査ポリシーの構成

CREATE AUDIT POLICY文のACTIONSおよびACTIONS COMPONENT句を使用して、Oracle Label Securityイベントの監査ポリシーを作成できます。

- 次の構文を使用して、Oracle Label Securityの統合監査ポリシーを作成します。

CREATE AUDIT POLICY policy_name
ACTIONS action1 [,action2 ]
ACTIONS COMPONENT=OLS component_action1 [, action2];

例:

CREATE AUDIT POLICY audit_ols
ACTIONS SELECT ON OE.ORDERS
ACTIONS COMPONENT=OLS ALL;

条件を含む場合など、より複雑なポリシーを作成できます。ポリシーを作成したら、AUDIT文を使用して有効にする必要があります。

関連項目:
統合監査ポリシーの作成の構文

例: Oracle Label Securityのセッション・ラベル属性の監査

AUDIT CONTEXT NAMESPACE文で、Oracle Label Securityのセッション・ラベル属性を監査できます。

例22-23に、Oracle Label Securityのポリシーusr_pol1およびusr_pol2のORA_OLS_SESSION_LABELSアプリケーション・コンテキスト属性を監査する方法を示します。

例22-23 Oracle Label Securityのセッション・ラベル属性の監査

AUDIT CONTEXT NAMESPACE ORA_SESSION_LABELS ATTRIBUTES usr_pol1, usr_pol2;

例: Oracle Label Securityポリシーからのユーザーの除外

CREATE AUDIT POLICY文で、ポリシーからユーザーを除外できます。

例22-24に、ユーザーols_mgrからアクションを除外する統合監査ポリシーを作成する方法を示します。

例22-24 Oracle Label Securityポリシーからのユーザーの除外

CREATE AUDIT POLICY auth_ols_audit_pol
ACTIONS SELECT ON HR.EMPLOYEES
ACTIONS COMPONENT=OLS DROP POLICY, DISABLE POLICY;

AUDIT POLICY auth_ols_audit_pol EXCEPT ols_mgr;

例: Oracle Label Securityのポリシー・アクションの監査

CREATE AUDIT POLICY文で、Oracle Label Securityのポリシー・アクションを監査できます。

例22-25に、DROP POLICY、DISABLE POLICY、UNSUBSCRIBE OIDイベント、およびHR.EMPLOYEES表のUPDATEおよびDELETE文を監査する方法を示します。次に、ポリシーがHRおよびLBACSYSユーザーに適用され、監査アクションが成功すると、監査レコードが統合監査証跡に書き込まれます。

例22-25 Oracle Label Securityのポリシー・アクションの監査

CREATE AUDIT POLICY generic_audit_pol
ACTIONS UPDATE ON HR.EMPLOYEES, DELETE ON HR.EMPLOYEES
ACTIONS COMPONENT=OLS DROP POLICY, DISABLE POLICY, UNSUBSCRIBE OID;

AUDIT POLICY generic_audit_pol BY HR, LBACSYS WHENEVER SUCCESSFUL;

例: 監査済のOLSセッション・ラベルの問合せ

UNIFIED_AUDIT_TRAIL問合せでLBACSYS.ORA_GET_AUDITED_LABEL関数を使用して、監査済Oracle Label Securityセッション・ラベルを確認できます。

例22-26に、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューの問合せでLBACSYS.ORA_GET_AUDITED_LABELファンクションを使用する方法を示します。

例22-26 監査対象のOracle Label Securityセッション・ラベルの問合せ

SELECT ENTRY_ID, SESSIONID,
LBACSYS.ORA_GET_AUDITED_LABEL( APPLICATION_CONTEXTS,'GENERIC_AUDIT_POL1') AS  SESSION_LABEL1,
LBACSYS.ORA_GET_AUDITED_LABEL( APPLICATION_CONTEXTS,'GENERIC_AUDIT_POL2') AS  SESSION_LABEL2
FROM UNIFIED_AUDIT_TRAIL;
/

ENTRY_ID  SESSIONID  SESSION_LABEL1  SESSION_LABEL2
--------  ---------  --------------  --------------
1       1023  SECRET          LEVEL_ALPHA
2       1024  TOP_SECRET      LEVEL_BETA

監査証跡でのOracle Label Securityの監査イベントの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Label Securityの監査イベントを表示します。

必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAILプロシージャを実行して、監査レコードをディスクに書き込みます。

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。

UNIFIED_AUDIT_TRAILビューのOLS_*列は、Oracle Label Security固有の監査データを示します。次に例を示します。

SELECT OLS_PRIVILEGES_USED FROM UNIFIED_AUDIT_TRAIL WHERE DBUSERNAME = 'psmith';

OLS_PRIVILEGES_USED
-------------------
READ
WRITEUP
WRITEACROSS

監査証跡で取得されるセッション・ラベルは、UNIFIED_AUDIT_TRAILビューのAPPLICATION_CONTEXTS列に格納されます。LBACSYS.ORA_GET_AUDITED_LABELファンクションを使用して、APPLICATION_CONTEXTS列に格納されているセッション・ラベルを取得できます。このファンクションは、UNIFIED_AUDIT_TRAIL.APPLICATION_CONTEXTS列値、およびOracle Label Securityポリシー名を引数として受け入れ、指定したポリシーの列に格納されているセッション・ラベルを返します。

関連項目:

ORA_GET_AUDITED_LABELファンクションの詳細は、『Oracle Label Security管理者ガイド』を参照してください。

Oracle Data Miningイベントの監査

CREATE AUDIT POLICY文を使用して、Oracle Data Miningイベントを監査できます。

内容は次のとおりです。

- Oracle Data Miningイベントの監査について

- Oracle Data Miningの統合監査証跡イベント

- Oracle Data Miningの統合監査ポリシーの構成

- 例: ユーザーによる複数のOracle Data Mining操作の監査

- 例: ユーザーによる失敗したすべてのOracle Data Mining操作の監査

- 監査証跡でのOracle Data Miningイベントの表示方法

Oracle Data Miningイベントの監査について

Oracle Data Miningイベントを監査するには、AUDIT_ADMINロールが必要です。

監査証跡にアクセスするには、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。

関連項目:

Oracle Data Miningの詳細は、『Oracle Data Mining概要』を参照してください。

Oracle Data Miningの統合監査証跡イベント

統合監査証跡では、Oracle Data Miningの監査イベントを取得できます。

表22-18では、これらのイベントについて説明します。

表22-18 Oracle Data Miningの監査イベント

監査イベント

説明

AUDIT

データ・マイニング・モデルの監査レコードを生成します。

COMMENT

データ・マイニング・モデルにコメントを追加します。

GRANT

データ・マイニング・モデルへのアクセス権をユーザーに付与します。

RENAME

データ・マイニング・モデルの名前を変更します。

SELECT

データ・マイニング・モデルを適用またはその署名を表示します。

Oracle Data Miningの統合監査ポリシーの構成

CREATE AUDIT POLICY文のACTIONSおよびON MINING MODEL句を使用して、Oracle Data Miningイベントの統合監査ポリシーを作成できます。

- 次の構文を使用して、Oracle Data Miningの統合監査ポリシーを作成します。

CREATE AUDIT POLICY policy_name
ACTIONS {operation | ALL}
ON MINING MODEL schema_name.model_name;

例:

CREATE AUDIT POLICY dm_ops ACTIONS RENAME ON MINING MODEL hr.dm_emp;

条件を含む場合など、より複雑なポリシーを作成できます。ポリシーを作成したら、AUDIT文を使用して有効にする必要があります。

関連トピック

- 統合監査ポリシーの作成の構文

例: ユーザーによる複数のOracle Data Mining操作の監査

CREATE AUDIT POLICY文で、複数のOracle Data Mining操作を監査できます。

例22-27に、ユーザーpsmithによる複数のOracle Data Mining操作を監査する方法を示します。イベントごとにON MINING MODEL schema_name.model_name句を含み、それぞれカンマで区切ります。この例では、両方のアクションで同じschema_name.model nameを指定しますが、スキーマおよびデータ・モデルごとに異なるschema_name.model_name設定を構文で指定できます。

例22-27 ユーザーによる複数のOracle Data Mining操作の監査

CREATE AUDIT POLICY dm_ops_pol
ACTIONS SELECT ON MINING MODEL dmuser1.nb_model, ALTER ON MINING MODEL dmuser1.nb_model;

AUDIT POLICY dm_ops_pol BY psmith;

例: ユーザーによる失敗したすべてのOracle Data Mining操作の監査

CREATE AUDIT POLICY文で、ユーザーによる失敗したOracle Data Miningの操作を監査できます。

例22-28に、ユーザーpsmithによる失敗したすべてのOracle Data Mining操作を監査する方法を示します。

例22-28 ユーザーによる失敗したすべてのOracle Data Mining操作の監査

CREATE AUDIT POLICY dm_all_ops_pol ACTIONS ALL ON MINING MODEL dmuser1.nb_model;

AUDIT POLICY dm_all_ops_pol BY psmith WHENEVER NOT SUCCESSFUL;

監査証跡でのOracle Data Miningイベントの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Data Miningの監査イベントを表示します。

必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAILプロシージャを実行して、監査レコードをディスクに書き込みます。

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。

次の例に、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せて、データ・マイニングの監査イベントを確認する方法を示します。

SELECT DBUSERNAME, ACTION_NAME, SYSTEM_PRIVILEGE_USED, RETURN_CODE,
OBJECT_SCHEMA, OBJECT_NAME, SQL_TEXT
FROM UNIFIED_AUDIT_TRAIL;

DBUSERNAME ACTION_NAME          SYSTEM_PRIVILEGE_USED     RETURN_CODE
---------- -------------------- ------------------------- -----------
OBJECT_SCHEMA        OBJECT_NAME
-------------------- --------------------
SQL_TEXT
--------------------------------------------------------------------------------
DMUSER1    CREATE MINING MODEL  CREATE MINING MODEL                 0
DMUSER1
BEGIN
dbms_data_mining.create_model(model_name => 'nb_model',
mining_function => dbms_data_mining.classification,
data_table_name => 'dm_data',
case_id_column_name => 'case_id',
target_column_name => 'target');
END;

DMUSER1    SELECT MINING MODEL                                      0
DMUSER1              NB_MODEL
select prediction(nb_model using *) from dual

DMUSER2    SELECT MINING MODEL                                  40284
DMUSER1              NB_MODEL
select prediction(dmuser1.nb_model using *) from dual

DMUSER1    ALTER MINING MODEL                                       0
DMUSER1              NB_MODEL
BEGIN dbms_data_mining.rename_model('nb_model', 'nb_model1'); END;

DMUSER2    ALTER MINING MODEL                                   40284
DMUSER1              NB_MODEL
BEGIN dbms_data_mining.rename_model('dmuser1.nb_model1', 'nb_model'); END;

DMUSER2    ALTER MINING MODEL                                   40284
DMUSER1              NB_MODEL
BEGIN dbms_data_mining.rename_model('dmuser1.nb_model1', 'nb_model'); END;

Oracle Data Pumpイベントの監査

CREATE AUDIT POLICY文を使用して、Oracle Data Pumpを監査できます。

内容は次のとおりです。

- Oracle Data Pumpイベントの監査について

- Oracle Data Pumpの統合監査証跡イベント

- Oracle Data Pumpの統合監査ポリシーの構成

- 例: Oracle Data Pumpのインポート操作の監査

- 例: Oracle Data Pumpのすべての操作の監査

- 監査証跡でのOracle Data Pumpの監査イベントの表示方法

Oracle Data Pumpイベントの監査について

Oracle Data Pumpの統合監査ポリシーを作成するには、CREATE AUDIT POLICY文のCOMPONENT句をDATAPUMPに設定する必要があります。

Data Pumpのエクスポート(expdp)およびインポート(impdp)操作を監査できます。

すべての統合監査と同様、Oracle Data Pumpのイベントを監査するには、AUDIT_ADMINロールが必要です。

監査証跡にアクセスするには、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。このビューのData Pump固有の列はDP_で始まります。

関連項目:

Oracle Data Pumpの詳細は、『Oracle Databaseユーティリティ』を参照してください。

Oracle Data Pumpの統合監査証跡イベント

統合監査証跡によってOracle Data Pumpのイベントを取得できます。

統合監査証跡では、エクスポート(expdp)およびインポート(impdp)の両方の操作に関する情報を取得します。

Oracle Data Pumpの統合監査ポリシーの構成

CREATE AUDIT POLICY文のACTIONS COMPONENT句を使用して、Oracle Data Pumpイベントの統合監査ポリシーを作成できます。

- 次の構文を使用して、Oracle Data Pumpの統合監査ポリシーを作成します。

CREATE AUDIT POLICY policy_name
ACTIONS COMPONENT=DATAPUMP { EXPORT | IMPORT | ALL };

例:

CREATE AUDIT POLICY audit_dp_export_pol
ACTIONS COMPONENT=DATAPUMP EXPORT;

条件を含む場合など、より複雑なポリシーを作成できます。ポリシーを作成したら、AUDIT文を使用して有効にする必要があります。

関連項目:
統合監査ポリシーの作成の構文

例: Oracle Data Pumpのインポート操作の監査

CREATE AUDIT POLICY文で、Oracle Data Pumpのインポート操作を監査できます。

例22-29に、Oracle Data Pumpのすべてのインポート操作を監査する方法を示します。

例22-29 Oracle Data Pumpのインポート操作の監査

CREATE AUDIT POLICY audit_dp_import_pol
ACTIONS COMPONENT=DATAPUMP IMPORT;

AUDIT POLICY audit_dp_import_pol;

例: Oracle Data Pumpのすべての操作の監査

CREATE AUDIT POLICY文で、Oracle Data Pumpのすべての操作を監査できます。

例22-30に、Oracle Database Pumpのエクスポートおよびインポートの両方の操作を監査する方法を示します。

例22-30 Oracle Data Pumpのすべての操作の監査

CREATE AUDIT POLICY audit_dp_all_pol
ACTIONS COMPONENT=DATAPUMP ALL;

AUDIT POLICY audit_dp_all_pol BY SYSTEM;

監査証跡でのOracle Data Pumpの監査イベントの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Data Pumpの監査イベントを表示します。

必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAILプロシージャを実行して、監査レコードをディスクに書き込みます。

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。

UNIFIED_AUDIT_TRAILビューのDP_*列は、Oracle Data Pump固有の監査データを示します。次に例を示します。

SELECT DP_TEXT_PARAMETERS1, DP_BOOLEAN_PARAMETERS1 FROM UNIFIED_AUDIT_TRAIL
WHERE AUDIT_TYPE = 'DATAPUMP';

DP_TEXT_PARAMETERS1                            DP_BOOLEAN_PARAMETERS1
---------------------------------------------- ----------------------------------

MASTER TABLE:  "SCOTT"."SYS_EXPORT_TABLE_01",  MASTER_ONLY: FALSE,
JOB_TYPE: EXPORT,                              DATA_ONLY: FALSE,
METADATA_JOB_MODE: TABLE_EXPORT,               METADATA_ONLY: FALSE,
JOB VERSION: 12.1.0.0,                         DUMPFILE_PRESENT: TRUE,
ACCESS METHOD: DIRECT_PATH,                    JOB_RESTARTED: FALSE
DATA OPTIONS: 0,
DUMPER DIRECTORY: NULL
REMOTE LINK: NULL,
TABLE EXISTS: NULL,
PARTITION OPTIONS: NONE

(この出力は、読みやすくするために変更が加えられています。)

Oracle SQL*Loaderダイレクト・ロード・パス・イベントの監査

CREATE AUDIT POLICY文を使用して、Oracle SQL*Loaderダイレクト・ロード・パス・イベントを監査できます。

内容は次のとおりです。

- Oracle SQL*Loaderダイレクト・パス・ロード・イベントの監査について

- Oracle SQL*Loaderダイレクト・ロード・パスの統合監査証跡イベント

- Oracle SQL*Loaderダイレクト・パス・イベントの統合監査証跡ポリシーの構成

- 例: Oracle SQL*Loaderダイレクト・パス・ロード操作の監査

- 監査証跡でのSQL*Loaderダイレクト・パス・ロードの監査イベントの表示方法

Oracle SQL*Loaderダイレクト・パス・ロード・イベントの監査について

Oracle SQL*Loaderダイレクト・パス・イベントを監査するには、AUDIT_ADMINロールが必要です。

SQL*Loaderの統合監査ポリシーを作成するには、CREATE AUDIT POLICY文のCOMPONENT句をDIRECT_LOADに設定する必要があります。監査できるのは、従来のパス・ロードなどの他のSQL*Loaderロードではなく、ダイレクト・パス・ロードのみです。

監査証跡にアクセスするには、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューのDIRECT_PATH_NUM_COLUMNS_LOADED列を問い合せます。

関連項目:

Oracle SQL*Loaderの詳細は、『Oracle Databaseユーティリティ』を参照してください。

Oracle SQL*Loaderダイレクト・ロード・パスの統合監査証跡イベント

統合監査証跡によってSQL*Loaderダイレクト・ロード・パスのイベントを取得できます。

統合監査証跡では、SQL*Loaderで実行されるダイレクト・パス・ロードに関する情報を取得します(SQL*LoaderのコマンドラインまたはSQL*Loaderの制御ファイルでdirect=trueに設定した場合)。

また、ダイレクト・パスAPIを使用するOracle Call Interface (OCI)プログラムも監査します。

関連項目:

Oracle SQL*Loaderのダイレクト・パス・ロードの詳細は、『Oracle Databaseユーティリティ』を参照してください。

Oracle SQL*Loaderダイレクト・パス・イベントの統合監査証跡ポリシーの構成

CREATE AUDIT POLICY文のACTIONS COMPONENT句では、Oracle SQL*Loaderダイレクト・パス・イベントの統合監査ポリシーを作成できます。

- 次の構文を使用して、Oracle SQL*Loaderの統合監査ポリシーを作成します。

CREATE AUDIT POLICY policy_name
ACTIONS COMPONENT=DIRECT_LOAD { LOAD };

例:

CREATE AUDIT POLICY audit_sqlldr_pol
ACTIONS COMPONENT=DIRECT_LOAD LOAD;

条件を含む場合など、より複雑なポリシーを作成できます。ポリシーを作成したら、AUDIT文を使用して有効にする必要があります。

関連項目:
統合監査ポリシーの作成の構文

例: Oracle SQL*Loaderダイレクト・パス・ロード操作の監査

CREATE AUDIT POLICY文で、Oracle SQL*Loaderダイレクト・パス・ロード操作を監査できます。

例22-29に、SQL*Loaderダイレクト・パス・ロード操作を監査する方法を示します。

例22-31 Oracle SQL*Loaderダイレクト・パス・ロード操作の監査

CREATE AUDIT POLICY audit_sqlldr_load_pol
ACTIONS COMPONENT=DIRECT_LOAD LOAD;

AUDIT POLICY audit_sqlldr_load_pol;

監査証跡でのSQL*Loaderダイレクト・パス・ロードの監査イベントの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはSQL*Loaderダイレクト・パス・ロードの監査イベントを表示します。

必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAILプロシージャを実行して、監査レコードをディスクに書き込みます

詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。

UNIFIED_AUDIT_TRAILビューのDIRECT_PATH_NUM_COLUMNS_LOADED 列は、SQL*Loaderダイレクト・パス・ロード・メソッドを使用してロードされた列の数を示します。次に例を示します。

SELECT DBUSERNAME, ACTION_NAME, OBJECT_SCHEMA, OBJECT_NAME, DIRECT_PATH_NUM_COLUMNS_LOADED FROM UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'DIRECT PATH API';

DBUSERNAME  ACTION_NAME OBJECT_SCHEMA OBJECT_NAME  DIRECT_PATH_NUM_COLUMNS_LOADED
----------- ----------- ------------- ------------ ------------------------------
RLAYTON     INSERT       HR            EMPLOYEES    4

マルチテナント環境での統合監査ポリシーまたはAUDIT設定の使用

マルチテナント環境では、ルートとPDBの両方に統合監査ポリシーを作成できます。

内容は次のとおりです。

- ローカルおよび共通監査ポリシーについて

- マルチテナント環境での従来の監査

- ローカル統合監査ポリシーまたは共通統合監査ポリシーの構成

- 例: ローカル統合監査ポリシー

- 例: 共通統合監査ポリシー

- 監査証跡でのローカルまたは共通監査ポリシーまたは設定の表示方法

関連項目:

マルチテナント環境での一般的な監査構成の詳細は、『Oracle Database概要』を参照してください。

ローカルおよび共通監査ポリシーについて

ローカル監査ポリシーまたはCDB共通監査ポリシーである監査ポリシー。

- ローカル監査ポリシー。このタイプのポリシーは、ルートまたはPDBに存在します。ルートに存在するローカル監査ポリシーには、ローカル・オブジェクトと共通オブジェクトの両方用のオブジェクト監査オプションを含めることができます。AUDIT_ADMINロールが付与されているローカル・ユーザーおよび共通ユーザーは、両方ともローカル・ポリシーを有効にできます(ローカル・ユーザーはPDBから、共通ユーザーは権限のあるルートまたはPDBから有効にできます)。ルートに接続している場合は、オブジェクト監査オプションを指定できますが、権限またはロールの監査オプションは指定できません。

- 共通監査ポリシー。このタイプのポリシーは、マルチテナント環境のすべてのPDBに使用できます。共通監査ポリシーを作成および保持できるのは、AUDIT_ADMINロールが付与されている共通ユーザーのみです。共通監査ポリシーは、共通ユーザーのみに対して有効にできます。共通監査ポリシーは、ルートにのみ作成する必要があります。このタイプのポリシーには、共通オブジェクトのみのオブジェクト監査オプションを含めることができ、共通ユーザーのみに対して有効にできます。

デフォルトでは、監査ポリシーは現在のPDBにローカルです。

マルチテナント環境での従来の監査

従来型の監査(統合監査ではない)では、AUDITおよびNOAUDIT文で、マルチテナント環境の文と権限を監査できます。

ローカル監査ポリシーまたは共通監査ポリシーになるように監査ポリシーを構成するには、作成または変更の他のSQL文に対して一般的に行うように、CONTAINER句を含める必要があります。監査レコードは、アクションを実行するコンテナに作成されることになります。

- AUDITまたはNOAUDIT文を現在のPDBに適用する場合は、PDBでCONTAINERをCURRENTに設定する必要があります。次に例を示します。

AUDIT DROP ANY TABLE BY SYSTEM BY ACCESS CONTAINER = CURRENT;

- AUDITまたはNOAUDIT文をマルチテナント環境全体に適用する場合は、ルートでCONTAINERをALLに設定する必要があります。次に例を示します。

AUDIT DROP ANY TABLE BY SYSTEM BY ACCESS CONTAINER = ALL;

関連項目:

従来のAUDITおよびNOAUDIT SQL文の詳細は、Oracle Database SQL言語リファレンスを参照してください

ローカル統合監査ポリシーまたは共通統合監査ポリシーの構成

CONTAINER句の使用はマルチテナント環境限定で、CREATE AUDIT POLICY文で使用します。

- 次の構文を使用して、ローカル統合監査ポリシーまたは共通統合監査ポリシーを作成します。

CREATE AUDIT POLICY policy_name
action1 [,action2 ]
[CONTAINER = {CURRENT | ALL}];

次のように値を指定します。

- CURRENTは、監査ポリシーを現在のPDBにローカルになるように設定します。

- ALLは、監査ポリシーを共通監査ポリシー(マルチテナント環境全体で使用可能にする)にします。

たとえば、共通統合監査ポリシーの場合は次のようになります。

CREATE AUDIT POLICY dict_updates
ACTIONS UPDATE ON SYS.USER$,
DELETE ON SYS.USER$,
UPDATE ON SYS.LINK$,
DELETE ON SYS.LINK$
CONTAINER = ALL;

次のことに注意してください。

- 統合監査ポリシーの場合は、ALTER AUDIT POLICYまたはDROP AUDIT POLICYではなく、CREATE AUDIT POLICY文にCONTAINER句を設定できます。この設定を使用するように既存の統合監査ポリシーの範囲を変更する場合は、ポリシーを削除してから再作成します。

- AUDIT文の場合は、リリース12.xの監査機能にまだ移行していないOracleデータベースがある場合など、監査設定のみにCONTAINER句を設定します。統合監査ポリシーを有効にするために使用するAUDIT文には、CONTAINER句を使用できません。

- PDBにいる場合、CONTAINER句に設定できるのはALLではなくCURRENTのみです。PDBにいる場合に設定を省略すると、デフォルトはCONTAINER = CURRENTになります。

- ルートにいる場合は、CONTAINER句を、ポリシーをルートのみに適用する場合はCURRENTに、ポリシーをCDB全体に適用する場合はALLに設定できます。CONTAINER句を省略すると、デフォルトはCONTAINER = COMMONになります。

- オブジェクトの場合:

- 共通監査ポリシーには共通オブジェクトのみ、ローカル監査ポリシーにはローカル・オブジェクトのみを含めることができます。

- 関係するオブジェクトがローカルの場合は、CONTAINERをALLに設定することはできません。共通オブジェクトにする必要があります。

- 権限の場合:

- 関係するユーザー・アカウントがローカル・アカウントと共通アカウントの混在の場合は、CONTAINERをCURRENTに設定(またはCONTAINER句を省略)できます。これにより、現在のPDBのみに適用されるローカル監査構成が作成されます。

- 関係するユーザーがローカル・ユーザーの場合は、CONTAINERをALLに設定することはできません。共通ユーザーにする必要があります。

- CONTAINERをALLに設定し、ユーザー・リストを指定しない場合(BY句をAUDIT文に使用)、構成が各PDBのすべての共通ユーザーに適用されます。

関連項目:

- 統合監査ポリシーの作成の構文

- 統合監査ポリシーの条件の作成

- ユーザーに対する統合監査ポリシーの有効化

- アプリケーション・コンテキスト値の監査

例: ローカル統合監査ポリシー

CREATE AUDIT POLICY文で、ルートまたはPDBにローカル統合監査ポリシーを作成できます。

ルートでローカル統合監査ポリシーを作成すると、マルチテナント環境全体ではなく、ルートにのみ適用されます。

例22-32に、共通ユーザーc##sec_adminによってPDBから作成され、共通ユーザーc##hr_adminに適用されているローカル統合監査ポリシーを示します。

例22-32 ローカル統合監査ポリシー

CONNECT c##sec_admin@hrpdb
Enter password: password
Connected.

CREATE AUDIT POLICY table_privs
PRIVILEGES CREATE ANY TABLE, DROP ANY TABLE
CONTAINER = CURRENT;

AUDIT POLICY table_privs BY c##hr_admin;

例: CDB共通統合監査ポリシー

CREATE AUDIT POLICY文で、CDB共通統合監査ポリシーを作成できます。

例22-33に、共通ユーザーc##sec_adminによってルートから作成され、共通ユーザーc##hr_adminに適用されている共通統合監査ポリシーを示します。

例22-33 共通統合監査ポリシー

CONNECT c##sec_admin
Enter password: password
Connected.

CREATE AUDIT POLICY admin_pol
ACTIONS CREATE TABLE, ALTER TABLE, DROP TABLE
ROLES c##hr_mgr, c##hr_sup
CONTAINER = ALL;

AUDIT POLICY admin_pol BY c##hr_admin;

監査証跡でのローカルまたは共通監査ポリシーまたは設定の表示方法

ルートまたはアクションが発生したPDBから、統合監査ポリシー・ビューを問い合せることができます。

次のタイプの問合せを実行できます。

- すべてのPDBからのレコードを監査する。監査証跡には、PDBで実行された監査アクションが反映されます。たとえば、PDB1のユーザーlbrownが、共通監査ポリシーまたはローカル監査ポリシーのいずれかによって監査されたアクションを実行すると、監査証跡によってこのアクションが取得されます。UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューのDBID列は、監査アクションが実行され、ポリシーが適用されるPDBを示します。すべてのPDBからの監査レコードを確認する場合は、ルートからCDB_UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せる必要があります。

- 共通監査ポリシーからのレコードを監査する。この場所は、共通監査ポリシーが監査レコードになる場所です。アクションが実際に発生した場所に応じて、マルチテナント環境(ルートまたはPDB)の任意の場所で監査レコードを生成できます。たとえば、共通監査ポリシーfga_polは、DBMS_FGA PL/SQLパッケージのEXECUTE権限を監査し、このアクションがPDB1で発生すると、監査レコードはルートではなく、PDB1に生成されます。このため、監査レコードはPDB1に表示できます。
PDBポリシー名にWHERE句を使用している場合は(例: WHERE UNIFIED_AUDIT_POLICIES = 'FGA_POL')、ポリシーについて、ルートまたはPDBのいずれかからUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることができます。

次の例は、共通統合監査ポリシーの結果を検索する方法を示します。

CONNECT c##sec_admin@root
Enter password: password
Connected.

SELECT DBID, ACTION_NAME, OBJECT_SCHEMA, OBJECT_NAME FROM CDB_UNIFIED_AUDIT_TRAIL WHERE DBUSERNAME = 'c##hr_admin';

DBID        ACTION_NAME  OBJECT_SCHEMA  OBJECT_NAME
----------- -----------  -------------  -----------
653916017   UPDATE       HR             EMPLOYEES
653916018   UPDATE       HR             JOB_HISTORY
653916017   UPDATE       HR             JOBS

注意:

監査証跡で最新の監査レコードを表示するには、必要に応じて次のプロシージャを実行して、レコードをディスクに書き込みます。

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。

統合監査ポリシーの変更

ALTER AUDIT POLICY文を使用して、統合監査ポリシーを変更できます。

内容は次のとおりです。

- 統合監査ポリシーの変更について

- 統合監査ポリシーの変更

- 例: 統合監査ポリシーの条件の変更

- 例: 統合監査ポリシーでのOracle Label Securityコンポーネントの変更

- 例: 統合監査ポリシーでのOracle Label Securityコンポーネントの変更

- 例: 統合監査ポリシーからの条件の削除

統合監査ポリシーの変更について

統合監査ポリシーでは、CONTAINER設定を除いたほとんどのプロパティを変更できます。

マルチテナント環境では統合監査ポリシーを変更できません。たとえば、共通統合監査ポリシーをローカル統合監査ポリシーにすることはできません。

既存の統合監査ポリシーを検索するには、AUDIT_UNIFIED_POLICIESデータ・ディクショナリ・ビューを問い合せます。有効な統合監査ポリシーのみを検索する場合は、AUDIT_UNIFIED_ENABLED_POLICIESビューを問い合せます。有効な監査ポリシーと無効な監査ポリシーの両方を変更できます。有効な監査ポリシーを変更する場合は、変更後も有効なままです。

オブジェクトの統合監査ポリシーを変更すると、アクティブおよび後続の両方のユーザー・セッションで新しい監査設定が即座に実行されます。システムの監査オプションを変更する場合やポリシーの条件を監査する場合は、現在のユーザー・セッションではなく、新しいユーザー・セッションに対してアクティブになります。

統合監査ポリシーの変更

ALTER AUDIT POLICY文で、統合監査ポリシーを変更できます。

- 統合監査ポリシーを変更するために次の構文を使用し、ALTER AUDIT POLICY文を使用します。

ALTER AUDIT POLICY  policy_name
[ADD [privilege_audit_clause][action_audit_clause]
[role_audit_clause]]
[DROP [privilege_audit_clause][action_audit_clause]
[role_audit_clause]]
[CONDITION {DROP | audit_condition EVALUATE PER {STATEMENT|SESSION|INSTANCE}}]

次のように値を指定します。

- ADDでは、次の設定を変更できます。

- privilege_audit_clauseは、権限に関連する監査オプションを記述します。詳細は、「システム権限の監査」を参照してください。権限の監査オプションを構成するための詳細な構文は、次のとおりです。

ADD privilege_audit_clause  :=  PRIVILEGES  privilege1 [, privilege2]

- action_audit_clauseおよびstandard_actionsは、オブジェクト・アクションに関連する監査オプションを記述します。詳細は、「オブジェクト・アクションの監査」を参照してください。構文は次のようになります。

ADD action_audit_clause := {standard_actions | component_actions}
[, component_actions ]
standard_actions :=
ACTIONS action1 [ ON {schema.obj_name
| DIRECTORY directory_name
| MINING MODEL schema.obj_name
}
]
[, action2 [ ON {schema.obj_name
| DIRECTORY directory_name
| MINING MODEL schema.obj_name
}
]

- role_audit_clauseでは、ロールのポリシーを追加または削除できます。「ロールの監査」を参照してください。構文は次のとおりです。

ADD role_audit_clause := ROLES role1 [, role2]

- DROPでは、ADD句で説明されているのと同じコンポーネントを削除できます。次に例を示します。

DROP role_audit_clause := ROLES role1 [, role2]

- CONDITION {DROP...では、ポリシーの条件を追加または削除できます。既存の条件を変更する場合は、EVALUATE PER句を条件に含める必要があります。「統合監査ポリシーの条件の作成」を参照してください構文は次のとおりです。

CONDITION 'audit_condition := function operation value_list'
EVALUATE PER {STATEMENT|SESSION|INSTANCE}

条件を削除する場合は、条件の定義およびEVALUATE PER句を省略します。次に例を示します。

CONDITION DROP

例: 統合監査ポリシーの条件の変更

ALTER AUDIT POLICY文で、統合監査ポリシーの条件を変更できます。

例22-34に、既存の統合監査ポリシーの条件を変更する方法を示します。

例22-34 統合監査ポリシーの条件の変更

ALTER AUDIT POLICY orders_unified_audpol
ADD ACTIONS INSERT ON SCOTT.EMP
CONDITION 'SYS_CONTEXT(''ENTERPRISE'', ''GROUP'') =  ''ACCESS_MANAGER'''
EVALUATE PER SESSION;

例: 統合監査ポリシーでのOracle Label Securityコンポーネントの変更

ALTER AUDIT POLICY文で、監査ポリシーのOracle Label Securityコンポーネントを変更できます。

例22-35に、監査ポリシーでOracle Label Securityコンポーネントを変更する方法を示します。

例22-35 統合監査ポリシーでのOracle Label Securityコンポーネントの変更

ALTER AUDIT POLICY audit_ols
ADD ACTIONS SELECT ON HR.EMPLOYEES
ACTIONS COMPONENT=OLS DROP POLICY, DISABLE POLICY, REMOVE POLICY;

例: 統合監査ポリシーのロールの変更

ALTER AUDIT POLICY文で、統合監査ポリシーのロールを変更できます。

例22-36に、共通統合監査ポリシーにロールを追加する方法を示します。

例22-36 統合監査ポリシーのロールの変更

CONNECT c##sec_admin
Enter password: password
Connected.

ALTER AUDIT POLICY RoleConnectAudit
ADD ROLES c##role1, c##role2;

例: 統合監査ポリシーからの条件の削除

ALTER AUDIT POLICY文で、統合監査ポリシーから条件を削除できます。

例22-37に、既存の統合監査ポリシーから条件を削除する方法を示します。

例22-37 統合監査ポリシーからの条件の削除

ALTER AUDIT POLICY orders_unified_audpol
CONDITION DROP;

ユーザーに対する統合監査ポリシーの有効化

AUDIT POLICY文を使用して、ユーザーに対する統合監査ポリシーを有効にして適用できます。

内容は次のとおりです。

- 統合監査ポリシーの有効化について

- 統合監査ポリシーの有効化

- 例: 統合監査ポリシーの有効化

統合監査ポリシーの有効化について

POLICY句を含むAUDIT文で、統合監査ポリシーを有効にして、オブジェクト・レベルのオプションを含むすべてのタイプの監査オプションに適用します。

監査ユーザーがデータベース・インスタンスにログインするまで、ポリシーは有効となりません。言い方を変えると、監査ユーザーのログイン中にポリシーを作成して有効化すると、ポリシーは監査データを収集できません。監査を開始する前に、ユーザーはログアウトしてから再ログインする必要があります。セッションが監査で設定されると、設定はユーザー・セッションの間継続し、セッションの終了時に終了します。

監査の結果を確認するには、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。既存の統合監査ポリシーのリストを検索するには、AUDIT_UNIFIED_POLICIESデータ・ディクショナリ・ビューを問い合せます。

AUDIT文では、次のオプションの追加設定を指定できます。

- 統合監査ポリシーを1人以上のユーザーに適用するかどうか。SYSDBA管理権限(SYSなど)でログインする管理ユーザーを含む、1人以上のユーザーにポリシーを適用するには、BY句を使用します。
次に例を示します。

AUDIT POLICY role_connect_audit_pol BY SYS, SYSTEM;

- 統合監査ポリシーからユーザーを除外するかどうか。監査ポリシーからユーザーを除外するには、EXCEPT句を含めます。
次に例を示します。

AUDIT POLICY role_connect_audit_pol EXCEPT rlee, jrandolph;

- アクティビティが成功または失敗した場合に、監査レコードを作成するかどうか。この監査方法は、監査証跡が減少するため、特定のアクションに重点を置きやすくなります。これにより、データベースの良好なパフォーマンスを維持できます。次のいずれかの句を入力します。

- WHENEVER SUCCESSFULは、ユーザーのアクティビティの実行が成功した場合のみ監査します。

- WHENEVER NOT SUCCESSFULは、ユーザーのアクティビティの実行が失敗した場合のみ監査します。異常終了したSQL文を監視することで、アクセス違反や不当な処理を行っているユーザーを判別できます。ただし、異常終了したSQL文の原因はそのどちらでもない場合がほとんどです。

次に例を示します。

AUDIT POLICY role_connect_audit_pol WHENEVER NOT SUCCESSFUL;

この句を省略すると、失敗および成功した両方のユーザー・アクティビティが監査証跡に書き込まれます。

次のことに注意してください。

- 統合監査ポリシーには、BY句またはEXCEPT句のみを含めることができますが、同じポリシーに両方を含めることはできません。

- 複数のAUDIT文を同じ統合監査ポリシーで実行し、異なるBYユーザーを指定すると、Oracle Databaseによってこれらのユーザーのすべてが監査されます。

- 複数のAUDIT文を同じ統合監査ポリシーで実行し、異なるEXCEPTユーザーを指定すると、Oracle Databaseによって、前述のリストのユーザーではなく、最新の例外ユーザー・リストが使用されます。つまり、前のAUDIT POLICY ... EXCEPT文の影響は最新のAUDIT POLICY ... EXCEPT文によってオーバーライドされます。

- 共通統合監査ポリシーは、共通ユーザーのみに対して有効にできます。

- マルチテナント環境では、共通監査ポリシーはルートからのみ、ローカル監査ポリシーは、ローカル監査ポリシーが適用されるPDBからのみ有効にできます。

統合監査ポリシーの有効化

AUDIT POLICY文で、統合監査ポリシーを有効にできます。

- 次の構文を使用して、統合監査ポリシーを有効にします。

AUDIT POLICY { policy_auditing }
[WHENEVER [NOT] SUCCESSFUL]

次のように値を指定します。

- policy_auditingは、次のコンポーネントを示します。

- 統合監査ポリシーの名前。既存のポリシーをすべて検索するには、AUDIT_UNIFIED_POLICIESデータ・ディクショナリ・ビューを問い合せます。現在有効なポリシーを検索するには、AUDIT_UNIFIED_ENABLED_POLICIESを問い合せます。

- 統合監査ポリシーが適用されるユーザー。ポリシーを1人以上のユーザー(ユーザーSYSを含む)に適用するには、BY句を入力します。次に例を示します。

BY psmith, rlee

- 統合監査ポリシーから除外するユーザー。ポリシーから1人以上のユーザーを除外するには、EXCEPT句を入力します。次に例を示します。

EXCEPT psmith, rlee

必須の監査レコードは、AUDIT POLICY SQL文でUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューに取得されます。除外されたユーザーを監査レコードで検索するには、UNIFIED_AUDIT_TRAILビューのEXCLUDED_USER列を問い合せることで、除外されたユーザーをリストできます。

同じ文のBY句、BY USERS WITH GRANTED ROLES句およびEXCEPT句で、同じ監査ポリシーを有効にすることはできません。このアクションにより、句が競合して、後続のAUDIT文でエラーがスローされます。

- WHENEVER [NOT] SUCCESSFULでは、ユーザーのアクションが成功したか失敗したかに基づいて、ポリシーで監査レコードを生成できます。詳細は、統合監査ポリシーの有効化についてを参照してください。

統合監査ポリシーを有効にして、ポリシーがレコードを生成している場合は、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることで、監査レコードを検索できます。

例: 統合監査ポリシーの有効化

AUDIT POLICY文で、WHENEVER NOT SUCCESSFULなどの条件を使用して統合監査ポリシーを有効にできます。

例22-38に、ユーザーdv_adminによる失敗したアクションのみを統合監査ポリシーで記録できるようにする方法を示します。

例22-38 統合監査ポリシーの有効化

AUDIT POLICY dv_admin_pol BY tjones
WHENEVER NOT SUCCESSFUL;

統合監査ポリシーの無効化

NOAUDIT POLICY文を使用して、統合監査ポリシーを無効にすることができます。

内容は次のとおりです。

- 統合監査ポリシーの無効化について

- 統合監査ポリシーの無効化

- 例: 統合監査ポリシーの無効化

統合監査ポリシーの無効化について

NOAUDIT文とPOLICY句を組み合せることにより、統合監査ポリシーを無効にできます。

NOAUDIT文では、EXCEPTユーザー・リストではなく、BYユーザー・リストを指定できます。統合監査ポリシーを無効にすると、後続のユーザー・セッションに反映されます。

既存の統合監査ポリシーのリストを検索するには、AUDIT_UNIFIED_POLICIESデータ・ディクショナリ・ビューを問い合せます。

マルチテナント環境では、共通監査ポリシーはルートからのみ、ローカル監査ポリシーは、ローカル監査ポリシーが適用されるPDBからのみ無効にできます。

統合監査ポリシーの無効化

NOAUDIT文により、統合監査ポリシーを無効にできます。

- 次の構文を使用して、統合監査ポリシーを無効にします。

NOAUDIT POLICY {policy_auditing | existing_audit_options};

次のように値を指定します。

- policy_auditingは、ポリシーの名前です。現在有効なポリシーをすべて検索するには、AUDIT_UNIFIED_ENABLED_POLICIESデータ・ディクショナリ・ビューを問い合せます。この指定の一部として、EXCEPT句ではなく、BY句をオプションで含めることができます。詳細は、統合監査ポリシーの有効化についてを参照してください。

- existing_audit_optionsは、次のようなOracle Database 12cリリース1 (12.1)より前のリリースで使用可能だったAUDITオプションを示します。

- SELECT ANY TABLE, UPDATE ANY TABLE BY SCOTT, HR

- UPDATE ON SCOTT.EMP

例: 統合監査ポリシーの無効化

NOAUDIT POLICY文で、ユーザー名などのフィルタを使用して統合監査ポリシーを無効にします。

例22-39に、ユーザーの統合監査ポリシーを無効にする方法を示します。

例22-39 統合監査ポリシーの無効化

NOAUDIT POLICY dv_admin_pol BY tjones;

統合監査ポリシーの削除

DROP AUDIT POLICY文を使用して、統合監査ポリシーを削除できます。

内容は次のとおりです。

- 統合監査ポリシーの削除について

- 統合監査ポリシーの削除

- 例: 統合監査ポリシーの無効化および削除

統合監査ポリシーの削除について

DROP AUDIT POLICY文を使用して、統合監査ポリシーを削除できます。

統合監査ポリシーがすでにセッションで有効な場合、ポリシーを削除しても、既存のこのセッションには影響しません。この時点まで、統合監査ポリシーの設定は有効のままです。ただし、オブジェクト関連の監査ポリシーの場合、影響は即座に反映されます。

既存の統合監査ポリシーのリストを検索するには、AUDIT_UNIFIED_POLICIESデータ・ディクショナリ・ビューを問い合せます。

監査ポリシーを削除する前に無効化する場合は、有効化に使用した設定と同じ設定を使用して無効化してください。たとえば、logon_polポリシーを次のように有効化したとします。

AUDIT POLICY logon_pol BY HR, OE;

このポリシーを削除する前に、次のようにNOAUDIT文にHRおよびOEユーザーが含まれている必要があります。

NOAUDIT POLICY logon_pol BY HR, OE;

マルチテナント環境では、共通監査ポリシーはルートからのみ、ローカル監査ポリシーは、ローカル監査ポリシーが適用されるPDBからのみ削除できます。

統合監査ポリシーの削除

統合監査ポリシーを削除するには、最初に無効にし、DROP AUDIT POLICY文を実行して削除します。

- 次の構文を使用して、統合監査ポリシーを削除します。

DROP AUDIT POLICY policy_name;

マルチテナント環境では、統合監査ポリシーの削除は現在のPDBに適用されます。統合監査ポリシーが共通統合監査ポリシーとして削除された場合は、ローカルのPDBから削除することはできません。共通統合監査ポリシーの詳細は、「マルチテナント環境での統合監査ポリシーまたはAUDIT設定の使用」を参照してください。

例: 統合監査ポリシーの無効化および削除

NOAUDIT POLICY文およびDROP AUDIT POLICY文では、統合監査ポリシーを無効化して削除できます。

例22-40に、共通統合監査ポリシーを無効化および削除する方法を示します。

例22-40 統合監査ポリシーの無効化および削除

CONNECT c##sec_admin
Enter password: password
Connected.

NOAUDIT POLICY dv_admin_pol;

DROP AUDIT POLICY dv_admin_pol

例: 非データベース・ユーザーの監査

このチュートリアルでは、クライアント識別子に設定された識別情報に基づいて、非データベース・ユーザーのアクションを監査する統合監査ポリシーを作成する方法を示します。

内容は次のとおりです。

- 手順1: ユーザー・アカウントの作成とユーザーOEがアクティブであることの確認

- 手順2: 統合監査ポリシーの作成

- 手順3: ポリシーのテスト

- 手順4: このチュートリアルのコンポーネントの削除

手順1: ユーザー・アカウントの作成とユーザーOEがアクティブであることの確認

ユーザーを作成し、ユーザーOEがアクティブであることを確認する必要があります。

1. SYSDBA管理権限を持つユーザーSYSとしてログインします。

sqlplus sys as sysdba
Enter password: password

2. マルチテナント環境で、適切なPDBに接続します。

次に例を示します。

CONNECT SYS@hrpdb AS SYSDBA
Enter password: password

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. ファイングレイン監査ポリシーを作成するローカル・ユーザーpolicy_adminを作成します。

CREATE USER policy_admin IDENTIFIED BY password;
GRANT CREATE SESSION, AUDIT_ADMIN TO policy_admin;

「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。

4. このポリシーの監査証跡をチェックするローカル・ユーザー・アカウントauditorを作成します。

CREATE USER policy_auditor IDENTIFIED BY password;
GRANT CREATE SESSION, AUDIT_VIEWER TO policy_auditor;

5. この例ではサンプル・ユーザーOEも使用するため、DBA_USERSデータ・ディクショナリ・ビューを問い合せて、OEがロックされていたり、期限切れになっていないことを確認します。

SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'OE';

このアカウント・ステータスは、OPENになっている必要があります。DBA_USERSビューに、ユーザーOEがロックされて期限切れになっていると表示された場合は、ユーザーSYSTEMでログインし、次の文を入力して、OEアカウントのロックを解除し、新しいパスワードを作成します。

ALTER USER OE ACCOUNT UNLOCK IDENTIFIED BY password;

「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。セキュリティを向上させるため、以前のリリースのOracle Databaseと同じパスワードをOEアカウントに指定しないでください。

手順2: 統合監査ポリシーの作成

ここでは、統合監査ポリシーを作成します。

1. ユーザーpolicy_adminでSQL*Plusに接続します。

CONNECT policy_admin -- Or, CONNECT policy_admin@hrpdb
Enter password: password

2. 次のポリシーを作成します。

CREATE AUDIT POLICY orders_unified_audpol
ACTIONS INSERT ON OE.ORDERS, UPDATE ON OE.ORDERS, DELETE ON OE.ORDERS, SELECT ON OE.ORDERS
WHEN 'SYS_CONTEXT(''USERENV'', ''CLIENT_IDENTIFIER'') = ''robert'''
EVALUATE PER STATEMENT;

AUDIT POLICY orders_unified_audpol;

この例では、AUDIT_CONDITIONパラメータで非データベース・ユーザーの名前がrobertであると想定しています。ポリシーでは、robertが実行するINSERT、UPDATE、DELETEおよびSELECT文を監視します。ポリシーに入力するユーザーのCLIENT_IDENTITIFER設定は、大文字と小文字を区別し、ここで指定する識別情報に使用される大/小文字のみがポリシーで認識されることに注意してください。つまり、後でユーザー・セッションがRobertまたはROBERTに設定されると、ポリシーの条件は満たされません。

手順3: ポリシーのテスト

ポリシーをテストするため、ユーザーOEはOE.ORDERS表から選択します。

統合監査ポリシーは、監査中のユーザーに対する次のユーザー・セッションで有効となります。したがって、監査記録を取得する前に、ユーザーはポリシーが作成されてからデータベースに接続する必要があります。

1. ユーザーOEで接続し、OE.ORDERS表から選択します。

CONNECT OE -- Or, CONNECT OE@hrpdb
Enter password: password

SELECT COUNT(*) FROM ORDERS;

次の出力が表示されます。

COUNT(*)
----------
105

2. 必要に応じて、ユーザーpolicy_adminで接続し、次のプロシージャを実行します。

CONNECT policy_admin -- Or, CONNECT policy_admin@hrpdb
Enter password: password

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

監査証跡モードがQUEUEDの場合、インメモリー・キューが一杯になるまで、監査レコードはディスクに書き込まれません。このコマンドによってキューをディスクに書き出すよう明示的に指示され、UNIFIED_AUDIT_TRAILビューで監査証跡レコードを確認できます。

3. ユーザーpolicy_auditorで接続し、監査レコードが生成されたかどうかを確認します。

CONNECT policy_auditor -- Or, CONNECT policy_auditor@hrpdb
Enter password: password

col dbusername format a10
col client_identifier format a20
col sql_text format a29

SELECT DBUSERNAME, CLIENT_IDENTIFIER, SQL_TEXT FROM UNIFIED_AUDIT_TRAIL
WHERE SQL_TEXT LIKE '%FROM ORDERS%';

次の出力が表示されます。

no rows selected

4. ユーザーOEで再接続し、クライアント識別子をrobertに設定し、OE.ORDERS表から再選択します。

CONNECT OE -- Or, CONNECT OE@hrpdb
Enter password: password

EXEC DBMS_SESSION.SET_IDENTIFIER('robert');

SELECT COUNT(*) FROM ORDERS;

次の出力が表示されます。

COUNT(*)
----------
105

5. ユーザーpolicy_adminで接続し、DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAILプロシージャを実行します。

CONNECT policy_admin -- Or, CONNECT policy_admin@hrpdb
Enter password: password

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

6. ユーザーauditorで再接続し、監査証跡を再び確認します。

CONNECT policy_auditor -- Or, CONNECT policy_auditor@hrpdb
Enter password: password

SELECT DBUSERNAME, CLIENT_IDENTIFIER, SQL_TEXT FROM UNIFIED_AUDIT_TRAIL
WHERE SQL_TEXT LIKE '%FROM ORDERS%';

今回は、robertが存在し、OE.ORDERS表を問い合せたため、監査証跡ではそのアクションが取得されます。

DBUSERNAME CLIENT_IDENTIFIER SQL_TEXT
---------- ----------------- ----------------------------
OE         robert            SELECT COUNT(*) FROM ORDERS;

手順4: このチュートリアルのコンポーネントの削除

このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。

1. ユーザーpolicy_adminでSQL*Plusに接続し、orders_unified_audpolポリシーを手動で無効にして削除します。

CONNECT policy_admin -- Or, CONNECT policy_admin@hrpdb
Enter password: password

NOAUDIT POLICY orders_unified_audpol;
DROP AUDIT policy orders_unified_audpol;

(統合監査ポリシーは、作成したユーザーのスキーマではなく、SYSスキーマに存在します。)

2. ユーザーSYSTEMとしてSQL*Plusに接続します。

CONNECT SYSTEM -- Or, CONNECT SYSTEM@hrpdb
Enter password: password

3. ユーザーpolicy_adminおよびpolicy_auditorを削除します。

DROP USER policy_admin;
DROP USER policy_auditor;

4. 他のユーザーがOEを使用しない場合、このアカウントはロックして期限切れにできます。

ALTER USER OE PASSWORD EXPIRE ACCOUNT LOCK;

事前定義の統合監査ポリシーを使用したアクティビティの監査

Oracle Databaseには、よく使用されるセキュリティ関連の監査設定を対象とする、事前定義の統合監査ポリシーが5つあります。

内容は次のとおりです。

- ログオン失敗の事前定義の統合監査ポリシー

- セキュア・オプションの事前定義の統合監査ポリシー

- Oracle Databaseパラメータ変更の事前定義の統合監査ポリシー

- ユーザー・アカウントおよび権限管理の事前定義の統合監査ポリシー

- Center for Internet Securityで推奨される事前定義の統合監査ポリシー

- Oracle Database Real Application Securityの事前定義の監査ポリシー

- Oracle Database Vaultの事前定義の統合監査ポリシー

関連項目:

このタイプの監査の実行に関する一般的な手順については、一般的に使用されるセキュリティ関連アクティビティの監査を参照してください

ログオン失敗の事前定義の統合監査ポリシー

ORA_LOGON_FAILURES統合監査ポリシーは、失敗したログオンのみを追跡し、その他のログオンは追跡しません。

新規データベースの場合、このポリシーは、完全な統合監査モードと混合モードの両方の監査環境で、デフォルトで有効です。デフォルトでは、このポリシーは有効になっていません。

次のCREATE AUDIT POLICY文は、ORA_LOGON_FAILURES統合監査ポリシー定義を示しています。

CREATE AUDIT POLICY ORA_LOGON_FAILURES ACTIONS LOGON;

ORA_LOGON_FAILURES統合監査ポリシーは、次のように有効にします。

AUDIT POLICY ORA_LOGON_FAILURES WHENEVER NOT SUCCESSFUL;

セキュア・オプションの事前定義の統合監査ポリシー

ORA_SECURECONFIG統合監査ポリシーには、セキュアな構成監査オプションがすべて用意されています。

新規データベースの場合、このポリシーは、完全な統合監査モードと混合モードの両方の監査環境で、デフォルトで有効です。デフォルトでは、このポリシーは有効になっていません。

次のCREATE AUDIT POLICY文は、ORA_SECURECONFIG統合監査ポリシー定義を示しています。

CREATE AUDIT POLICY ORA_SECURECONFIG
PRIVILEGES ALTER ANY TABLE, CREATE ANY TABLE, DROP ANY TABLE,
CREATE ANY PROCEDURE, DROP ANY PROCEDURE, ALTER ANY PROCEDURE,
GRANT ANY PRIVILEGE, GRANT ANY OBJECT PRIVILEGE, GRANT ANY ROLE,
AUDIT SYSTEM, CREATE EXTERNAL JOB, CREATE ANY JOB,
CREATE ANY LIBRARY,
EXEMPT ACCESS POLICY,
CREATE USER, DROP USER,
ALTER DATABASE, ALTER SYSTEM,
CREATE PUBLIC SYNONYM, DROP PUBLIC SYNONYM,
CREATE SQL TRANSLATION PROFILE, CREATE ANY SQL TRANSLATION PROFILE,
DROP ANY SQL TRANSLATION PROFILE, ALTER ANY SQL TRANSLATION PROFILE,
TRANSLATE ANY SQL,
EXEMPT REDACTION POLICY,
PURGE DBA_RECYCLEBIN, LOGMINING,
ADMINISTER KEY MANAGEMENT
ACTIONS    ALTER USER, CREATE ROLE, ALTER ROLE, DROP ROLE,
SET ROLE, CREATE PROFILE, ALTER PROFILE,
DROP PROFILE, CREATE DATABASE LINK,
ALTER DATABASE LINK, DROP DATABASE LINK,
CREATE DIRECTORY, DROP DIRECTORY,
CREATE PLUGGABLE DATABASE,
DROP PLUGGABLE DATABASE,
ALTER PLUGGABLE DATABASE,
EXECUTE ON DBMS_RLS;

関連項目:

この項で説明しているSQL文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

Oracle Databaseパラメータ変更の事前定義の統合監査ポリシー

ORA_DATABASE_PARAMETERポリシーでは、よく使用されるOracle Databaseのパラメータ設定を監査します。

次のCREATE AUDIT POLICY文は、ORA_DATABASE_PARAMETER統合監査ポリシー定義を示しています。デフォルトでは、このポリシーは有効になっていません。

CREATE AUDIT POLICY ORA_DATABASE_PARAMETER
ACTIONS ALTER DATABASE, ALTER SYSTEM, CREATE SPFILE;

ユーザー・アカウントおよび権限管理の事前定義の統合監査ポリシー

ORA_ACCOUNT_MGMTポリシーでは、よく使用されるユーザー・アカウントおよび権限の設定を監査します。

次のCREATE AUDIT POLICY文は、ORA_ACCOUNT_MGMT統合監査ポリシー定義を示しています。デフォルトでは、このポリシーは有効になっていません。

CREATE AUDIT POLICY ORA_ACCOUNT_MGMT
ACTIONS CREATE USER, ALTER USER, DROP USER, CREATE ROLE, DROP ROLE,
ALTER ROLE, SET ROLE, GRANT, REVOKE;

Center for Internet Securityで推奨される事前定義の統合監査ポリシー

ORA_CIS_RECOMMENDATIONSポリシーは、Center for Internet Security (CIS)で推奨される監査を実行します。

次のCREATE AUDIT POLICY文は、ORA_CIS_RECOMMENDATIONS統合監査ポリシー定義を示しています。デフォルトでは、このポリシーは有効になっていません。

CREATE AUDIT POLICY ORA_CIS_RECOMMENDATIONS
PRIVILEGES SELECT ANY DICTIONARY, CREATE ANY LIBRARY,
DROP ANY LIBRARY, CREATE ANY TRIGGER,
ALTER ANY TRIGGER, DROP ANY TRIGGER,
ALTER SYSTEM
ACTIONS CREATE USER, ALTER USER, DROP USER,
CREATE ROLE, DROP ROLE, ALTER ROLE,
GRANT, REVOKE, CREATE DATABASE LINK,
ALTER DATABASE LINK, DROP DATABASE LINK,
CREATE PROFILE, ALTER PROFILE, DROP PROFILE,
CREATE SYNONYM, DROP SYNONYM,
CREATE PROCEDURE, DROP PROCEDURE, ALTER PROCEDURE;

Oracle Database Real Application Securityの事前定義の監査ポリシー

事前定義の統合監査ポリシーをOracle Database Real Application Securityのイベントに使用できます。デフォルトでは、これらのポリシーは有効になっていません。

内容は次のとおりです。

- システム管理者操作の事前定義の統合監査ポリシー

- セッション操作の事前定義の統合監査ポリシー

関連項目:

Oracle Database Real Application Securityイベントの監査

システム管理者操作の事前定義の統合監査ポリシー

ORA_RAS_POLICY_MGMTの事前定義の統合監査ポリシーでは、アプリケーション・ユーザー、ロールおよびポリシーのOracle Real Application Securityのすべて管理アクションのポリシーを監査します。

次のCREATE AUDIT POLICY文は、ORA_RAS_POLICY_MGMT統合監査ポリシー定義を示しています。デフォルトでは、このポリシーは有効になっていません。

CREATE AUDIT POLICY ORA_RAS_POLICY_MGMT
ACTIONS COMPONENT=XS
CREATE USER, UPDATE USER, DELETE USER,
CREATE ROLE, UPDATE ROLE, DELETE ROLE, GRANT ROLE, REVOKE ROLE,
ADD PROXY, REMOVE PROXY,
SET USER PASSWORD, SET USER VERIFIER, SET USER PROFILE,
CREATE ROLESET, UPDATE ROLESET, DELETE ROLESET,
CREATE SECURITY CLASS, UPDATE SECURITY CLASS, DELETE SECURITY CLASS,
CREATE NAMESPACE TEMPLATE, UPDATE NAMESPACE TEMPLATE, DELETE NAMESPACE TEMPLATE,
CREATE ACL, UPDATE ACL, DELETE ACL,
CREATE DATA SECURITY, UPDATE DATA SECURITY, DELETE DATA SECURITY,
ENABLE DATA SECURITY, DISABLE DATA SECURITY,
ADD GLOBAL CALLBACK, DELETE GLOBAL CALLBACK, ENABLE GLOBAL CALLBACK;

セッション操作の事前定義の統合監査ポリシー

ORA_RAS_SESSION_MGMTの事前定義の統合監査ポリシーでは、Oracle Real Application Securityのすべてのランタイム・セッション・アクションおよびネームスペース・アクションのポリシーを監査します。

次のCREATE AUDIT POLICY文は、ORA_RAS_SESSION_MGMT統合監査ポリシー定義を示しています。デフォルトでは、このポリシーは有効になっていません。

CREATE AUDIT POLICY ORA_RAS_SESSION_MGMT
ACTIONS COMPONENT=XS
CREATE SESSION, DESTROY SESSION,
ENABLE ROLE, DISABLE ROLE,
SET COOKIE, SET INACTIVE TIMEOUT,
SWITCH USER, ASSIGN USER,
CREATE SESSION NAMESPACE, DELETE SESSION NAMESPACE,
CREATE NAMESPACE ATTRIBUTE, GET NAMESPACE ATTRIBUTE, SET NAMESPACE ATTRIBUTE,
DELETE NAMESPACE ATTRIBUTE;

Oracle Database Vaultの事前定義の統合監査ポリシー

事前定義のORA_DV_AUDPOL統合監査ポリシーはOracle Database Vaultのスキーマ・オブジェクトを監査します。

ORA_DV_AUDPOLポリシーは、Oracle Database VaultのDVSYSおよびDVFスキーマ・オブジェクトと、Oracle Label SecurityのLBACSYSスキーマ・オブジェクトに対して実行されるすべてのアクションを監査します。DVFスキーマのF$*ファクタ・ファンクションに関するアクションは取得しません。デフォルトでは、このポリシーは有効になっていません。

次のCREATE AUDIT POLICY文は、ORA_DV_AUDPOL統合監査ポリシー定義を示しています。

CREATE AUDIT POLICY ORA_DV_AUDPOL
ACTIONS AUDIT ON DVF.DBMS_MACSEC_FUNCTION;

関連項目:

Oracle Database Vaultイベントの監査

ファイングレイン監査を使用した特定のアクティビティの監査

ファイングレイン監査では、非常に詳細なレベルで監査ポリシーを作成できます。

内容は次のとおりです。

- ファイングレイン監査の概要

- ファイングレイン監査レコードが格納される場所

- ファイングレイン監査の実行者

- Oracle VPDポリシーがある表またはビューでのファイングレイン監査

- マルチテナント環境でのファイングレイン監査

- ファイングレイン監査ポリシーとエディション

- DBMS_FGA PL/SQLパッケージを使用したファイングレイン監査ポリシーの管理

- 例: ファイングレイン監査ポリシーへの電子メール・アラートの追加

関連項目:

このタイプの監査の実行に関する一般的な手順については、特定のファイングレイン・アクティビティの監査を参照してください

ファイングレイン監査の概要

ファイングレイン監査では、ポリシーを作成して、監査が実行される特定の条件を定義できます。

ファイングレイン監査を使用して統合監査ポリシーは作成できませんが、データのアクセス時間の監査など、詳細にカスタマイズされた監査設定はファイングレイン監査を使用して作成できます。

これにより、内容に基づいてデータ・アクセスを監視できるようになります。問合せと、INSERT、UPDATE、およびDELETE操作に対して詳細な監査を提供します。ファイングレイン監査を使用すると、次のタイプのアクションを監査できます。

- 午後9時から午前6時の間、または土曜日と日曜日に表にアクセスする場合

- 社内ネットワーク外部のIPアドレスを使用する場合

- 表の列を選択または更新する場合

- 表の列の値を変更する場合

通常、ファイングレイン監査ポリシーは、選択的監査の条件である、表オブジェクトに対する単純なユーザー定義SQL述語に基づいています。フェッチ中に行がポリシーの条件を満たすと、その問合せが監査対象となります。

統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査で説明されている監査ポリシーでは、次のアクションを除き、ファイングレイン監査ポリシーで実行可能な大部分の操作を実行できます。

- 特定の列の監査。給与や社会保障番号など、機密情報が格納されている特定の関連する列を監査できます。

- イベント・ハンドラの使用。たとえば、夜中に変更されないようにする必要がある監査対象の列が更新された場合に、セキュリティ管理者に電子メール・アラートを送信する関数を作成できます。

注意:

- ファイングレイン監査は、コストベースの最適化でのみサポートされています。ルールベースの最適化を使用する問合せでは、行フィルタを適用する前にファイングレイン監査が行われるため、不要な監査イベント・トリガーが発生します。

- フラッシュバック問合せに含まれるオブジェクトで現在有効なポリシーが、指定したフラッシュバック・スナップショット(時間またはシステム変更番号(SCN)に基づく)から戻されたデータに適用されます。

- ファイングレイン監査を使用して直接ロードされるデータを監査する場合(たとえばOracle Warehouse Builderを使用してDML文を実行する場合)、Oracle Databaseは透過的にデータベース・インスタンスで実行されているすべてのダイレクト・ロードを従来型ロードにします。データのダイレクト・ロードを保持する場合は、かわりに統合監査ポリシーの使用を検討してください。

ファイングレイン監査レコードが格納される場所

ファイングレイン監査のレコードは、AUDSYSスキーマに格納されます。

これらの監査レコードは、デフォルトでSYSAUX表領域に格納されます。DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATIONプロシージャを使用して、新しい表領域を指定できます。この表領域は暗号化された表領域にできます。有効な監査ポリシーに対して生成されたレコードを検索するには、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。

監査証跡では、SQL文内の表またはビューの参照ごとに監査レコードが取得されます。たとえば、HR.EMPLOYEES表を2回参照するUNION文を実行した場合、文の監査ポリシーによって2つ(HR.EMPLOYEES表へのアクセスごとに1つ)の監査レコードが生成されます。

関連項目:

- 強制的に監査されるアクティビティ

- DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATIONプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューの詳細は、Oracle Databaseリファレンスを参照

ファイングレイン監査の実行者

Oracleには、ファイングレイン監査ポリシーを作成したり、ファイングレイン監査ポリシーのデータを表示および分析するために必要な権限のロールが用意されています。

ファイングレイン監査には、次の権限があります。

- ファイングレイン監査ポリシーを作成するには、AUDIT_ADMINロールまたはDBMS_FGAパッケージに対するEXECUTE権限が付与されている必要があります。

- ファイングレイン監査データを表示および分析するには、AUDIT_VIEWERロールが付与されている必要があります。

PL/SQLパッケージにはAUDIT_ADMINロールがすでに付与されています。すべての権限と同様に、これらのロールは信頼できるユーザーにのみ付与してください。DBA_ROLE_PRIVSデータ・ディクショナリ・ビューを問い合せることで、ユーザーに付与されているロールを確認できます。

Oracle VPDポリシーがある表またはビューでのファイングレイン監査

この監査証跡は、Oracle VPDポリシーに含まれているファイングレイン監査表またはビューからVPD述語を取得します。

この動作は、統合監査証跡で統合監査ポリシーのVPD述語を取得する場合の動作に似ています。

述語情報は、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューのRLS_INFO列に格納されます。

同じ表またはビューに適用されるVPDポリシーが複数ある場合、これらのポリシーの述部は、デフォルトでRLS_INFO列に連結されます。各述語が各自の行内(対応するVPDポリシー名などの情報で特定)になるように出力を再フォーマットするには、ORA_GET_RLS_PREDICATEファンクションを使用します

マルチテナント環境でのファイングレイン監査

ファイングレイン監査ポリシーはルートまたはPDBに作成できます。

次のことに注意してください。

- SYSオブジェクトではポリシーを作成できません。

- ルートにポリシーを作成する場合、すべてのPDBにポリシーを適用することはできません。ポリシーはルート内のオブジェクトにのみ適用されます。(つまり、共通のファイングレイン監査ポリシーは存在しません。)すべてのPDBで共通オブジェクトのアクセスを監査するようにファイングレイン監査ポリシーを作成する場合は、監査ポリシーを各PDBで明示的に作成し、PDBでアクセス可能にする共通オブジェクトに対してそのポリシーを有効化する必要があります。

- PDBでポリシーを作成する場合、ポリシーはPDB内のオブジェクトにのみ適用されます。

ファイングレイン監査ポリシーとエディション

エディション・ベースの再定義のアプリケーションを作成し、アプリケーションが編集ビューで使用する各表を対象とすることができます。

これを行う場合、編集ビューに対してこれらの表を保護するファイングレイン監査ポリシーを移動する必要があります。DBA_EDITIONSデータ・ディクショナリ・ビューを問い合せることで、現在構成されているエディションについて情報を確認できます。ファイングレイン監査ポリシーに関する情報を確認するには、DBA_AUDIT_POLICIESを問い合せます。

DBMS_FGA PL/SQLパッケージを使用したファイングレイン監査ポリシーの管理

DBMS_FGA PL/SQLパッケージで、ファイングレイン監査ポリシーを管理します。

内容は次のとおりです。

- DBMS_FGA PL/SQL PL/SQLパッケージについて

- DBMS_FGA PL/SQLパッケージとエディション

- マルチテナント環境でのDBMS_FGA PL/SQLパッケージ

- ファイングレイン監査ポリシーの作成

- 例: DBMS_FGA.ADD_POLICYを使用してファイングレイン監査ポリシーを作成する方法

- ファイングレイン監査ポリシーを使用禁止にする方法

- ファイングレイン監査ポリシーの削除

DBMS_FGA PL/SQL PL/SQLパッケージについて

DBMS_FGA PL/SQLパッケージを使用して複数の文を1つのポリシーにまとめ、その他のファイングレイン監査管理タスクを実行できます。

ただし、列レベルの監査を実行しない場合や、イベント・ハンドラと監査ポリシーを使用しない場合は、統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査で説明されているように、監査ポリシーを作成する必要があります。

DBMS_FGA PL/SQLパッケージを使用すると、SELECT、INSERT、UPDATEおよびDELETE文のすべての組合せを1つのポリシーに追加できます。また、基礎となるアクションのINSERTおよびUPDATEを監査することによって、MERGE文も監査できます。MERGE文を監査するには、INSERTおよびUPDATE文に対するファイングレイン・アクセスを構成します。成功したMERGE操作についてポリシーごとにレコードが1つのみ生成されます。

ファイングレイン監査ポリシーを管理するには、AUDIT_ADMINロールを付与する必要があります。DBMS_FGAパッケージのEXECUTE権限は強制的に監査されることにも注意してください。

監査ポリシーは、監査ポリシーを作成した表にバインドされます。これにより、それぞれのアプリケーションではなく、データベースで一度だけポリシーを変更すればよいため、監査ポリシーの管理が容易です。また、データベースへの接続方法(接続元がアプリケーション、Webインタフェース、SQL*PlusやOracle SQL Developerのいずれであるか)に関係なく、ポリシーに影響を与えるアクションがすべて記録されます。

問合せから戻された行が定義した監査条件と一致すると、ファイングレイン監査証跡に監査エントリが挿入されます。このエントリでは、通常の監査証跡でレポートされるすべての情報が除外されます。つまり、TRUEと評価されたすべてのファイングレイン監査ポリシーに対して、1行の監査情報のみが監査証跡に挿入されます。

関連項目:
DBMS_FGAパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください

DBMS_FGA PL/SQLパッケージとエディション

エディション環境で使用するためのDBMS_FGAポリシーを作成できます。

DBMS_FGAパッケージ・ポリシーを異なる複数のエディションで使用する場合、ポリシーの結果を制御できます。つまり、結果をすべてのエディションで同一にするか、またはポリシーが使用されているエディションに固有にできます。

詳細は、エディションがグローバル・アプリケーション・コンテキストのPL/SQLパッケージの結果に与える影響を参照してください。

マルチテナント環境でのDBMS_FGA PL/SQLパッケージ

マルチテナント環境では、DBMS_FGA PL/SQLパッケージは現在のローカルPDBのみに適用されます。

マルチテナント環境全体に1つのポリシーを作成することはできません。PDB内でオブジェクトにポリシーを指定する必要があります。PDBを確認するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。

ファイングレイン監査ポリシーの作成

DBMS_FGA.ADD_POLICYプロシージャでは、ファイングレイン監査ポリシーを作成できます。

内容は次のとおりです。

- ファイングレイン監査ポリシーの作成について

- ファイングレイン監査ポリシーの作成の構文

- 特定の列および行の監査

ファイングレイン監査ポリシーの作成について

DBMS_FGA.ADD_POLICYプロシージャで、指定された述語を監査条件として使用し、監査ポリシーを作成します。

デフォルトでは、ポリシーを作成したユーザーの権限で、ポリシーの述語がOracle Databaseによって実行されます。表オブジェクトまたはビュー・オブジェクトに設定可能なファイングレイン・ポリシーの最大数は256です。Oracle Databaseでは、ポリシーはデータ・ディクショナリ表に格納されますが、SYSスキーマ内に存在しない表またはビューに関するポリシーを作成できます。マルチテナント環境では、ファイングレイン・ポリシーはローカルPDBでのみ作成されます。

ファイングレイン監査ポリシーを作成後に変更することはできません。ポリシーを変更する必要がある場合は、削除してから再作成します。

ファイングレイン監査ポリシーに関する情報を検索するには、ALL_AUDIT_POLICIES、DBA_AUDIT_POLICIESおよびALL_AUDIT_POLICIESビューを問い合せます。UNIFIED_AUDIT_TRAILビューには、FGA_POLICY_NAMEという名前の列が含まれ、この列を使用すると、特定のファイングレイン監査ポリシーを使用して生成された行をフィルタできます。

表の列にファイングレイン監査ポリシーが含まれている場合は、(UPDATE文を使用して)この列を暗号化することも復号化することもできないことに注意してください。実行した場合、ORA-28133「完全な表アクセスがファイングレイン・セキュリティによって制限されています」エラーが発生します。列を更新する場合は、まずファイングレイン監査ポリシーを一時的に無効にし、それから列を暗号化または復号化します。その後に、ファイングレイン監査ポリシーを再有効化します。詳細は、「ファイングレイン監査ポリシーの無効化」を参照してください。

ファイングレイン監査ポリシーの作成の構文

DBMS_FGA.ADD_POLICYプロシージャには、複雑な監査のハンドラを使用する機能など、様々な設定が含まれています。

DBMS_FGA.ADD_POLICYプロシージャの構文は次のとおりです。

DBMS_FGA.ADD_POLICY(
object_schema      IN  VARCHAR2 DEFAULT NULL
object_name        IN  VARCHAR2,
policy_name        IN  VARCHAR2,
audit_condition    IN  VARCHAR2 DEFAULT NULL,
audit_column       IN  VARCHAR2 DEFAULT NULL
handler_schema     IN  VARCHAR2 DEFAULT NULL,
handler_module     IN  VARCHAR2 DEFAULT NULL,
enable             IN  BOOLEAN DEFAULT TRUE,
statement_types    IN  VARCHAR2 DEFAULT SELECT,
audit_trail        IN  BINARY_INTEGER DEFAULT NULL,
audit_column_opts  IN  BINARY_INTEGER DEFAULT ANY_COLUMNS,
policy_owner       IN  VARCHAR2 DEFAULT NULL);

次のように値を指定します。

- 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のみです。MERGE操作を監査する場合は、statement_typesを'INSERT,UPDATE'に設定します。デフォルト値はSELECTです。

- audit_trail: 統合監査に移行している場合は、Oracle Databaseによってこのパラメータは無視され、監査レコードが統合監査証跡に即座に書き込まれます。統合監査に移行している場合は、このパラメータを省略します。
クレジット・カード情報などの機密データもクリアテキストで記録できることに注意してください。

- audit_column_opts: audit_columnパラメータで複数の列を指定した場合は、すべての列を監査するか特定の列を監査するかをこのパラメータで決定します。詳細は、特定の列および行の監査を参照してください。

- policy_ownerは、ファイングレイン監査ポリシーを所有するユーザーです。ただし、この設定はユーザー指定の引数ではありません。Oracle Data Pumpクライアントは、この設定を内部で使用して、ファイングレイン監査ポリシーを適宜再作成します。

関連項目:
DBMS_FGA.ADD_POLICYの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

特定の列および行の監査

条件が一致した場合の監査対象を関連列と呼ばれる特定の列にすることで、監査動作を細かく調節できます。

これを実行するには、audit_columnパラメータを使用して、機密情報が含まれた列を1つ以上指定します。また、audit_conditionパラメータを使用してブール条件を定義すると、特定の行のデータを監査できます。(ただし、ポリシーで条件の監査のみが必要な場合は、統合監査ポリシーの条件の作成で説明されている監査ポリシー条件の使用を検討してください。)

例22-41では、次の設定によって部門50(DEPARTMENT_ID = 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.ADD_POLICYを使用してファイングレイン監査ポリシーを作成する方法

DBMS_FGA.ADD_POLICYプロシージャで、複数の文タイプを使用してファイングレイン監査ポリシーを作成できます。

例22-41に、表HR.EMPLOYEESに対する文INSERT、UPDATE、DELETEおよびSELECTを監査する方法を示します。

この例では、audit_column_optsパラメータが必須パラメータではないため省略されていることに注意してください。

例22-41 DBMS_FGA.ADD_POLICYを使用してファイングレイン監査ポリシーを作成する方法

BEGIN
DBMS_FGA.ADD_POLICY(
object_schema      => 'HR',
object_name        => 'EMPLOYEES',
policy_name        => 'chk_hr_employees',
audit_column       => 'SALARY',
enable             =>  TRUE,
statement_types    => 'INSERT, UPDATE, SELECT, DELETE');
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;

ファイングレイン監査ポリシーを使用禁止にする方法

DBMS_FGA.DISABLE_POLICYプロシージャで、ファイングレイン監査ポリシーを無効にします。

- 次の構文を使用して、ファイングレイン監査ポリシーを無効にします。

DBMS_FGA.DISABLE_POLICY(
object_schema  VARCHAR2,
object_name    VARCHAR2,
policy_name    VARCHAR2);

たとえば、例22-41で作成されたファイングレイン監査ポリシーを無効にするには、次のようにします。

BEGIN
DBMS_FGA.DISABLE_POLICY(
object_schema        => 'HR',
object_name          => 'EMPLOYEES',
policy_name          => 'chk_hr_employees');
END;
/

関連項目:
DISABLE_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

ファイングレイン監査ポリシーを使用可能にする方法

DBMS_FGA.ENABLE_POLICYプロシージャで、ファイングレイン監査ポリシーを有効にします。

- 次の構文を使用して、ファイングレイン監査ポリシーを有効にします。

DBMS_FGA.ENABLE_POLICY(
object_schema  VARCHAR2,
object_name    VARCHAR2,
policy_name    VARCHAR2,
enable         BOOLEAN);

たとえば、DBMS_FGA.ENABLE_POLICYプロシージャを使用してchk_hr_empポリシーを再度使用可能にするとします。

BEGIN
DBMS_FGA.ENABLE_POLICY(
object_schema        => 'HR',
object_name          => 'EMPLOYEES',
policy_name          => 'chk_hr_employees',
enable               => TRUE);
END;
/

関連項目:
ENABLE_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

ファイングレイン監査ポリシーの削除

DBMS_FGA.DROP_POLICYプロシージャで、ファイングレイン監査ポリシーを削除します。

DBMS_FGA.ADD_POLICYプロシージャのobject_nameパラメータで指定されたオブジェクトを削除した場合、または監査ポリシーを作成したユーザーを削除した場合は、Oracle Databaseでは監査ポリシーが自動的に削除されます。

- 次の構文を使用して、ファイングレイン監査ポリシーを削除します。

DBMS_FGA.DROP_POLICY(
object_schema  VARCHAR2,
object_name    VARCHAR2,
policy_name    IVARCHAR2);

たとえば、DBMS_FGA.DROP_POLICYプロシージャを使用して、ファイングレイン監査ポリシーを手動で削除する方法を示します。

BEGIN
DBMS_FGA.DROP_POLICY(
object_schema      => 'HR',
object_name        => 'EMPLOYEES',
policy_name        => 'chk_hr_employees');
END;
/

関連項目:
DROP_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

例: ファイングレイン監査ポリシーへの電子メール・アラートの追加

このチュートリアルでは、ユーザーがポリシーに違反したときに電子メールのアラートを生成するファイングレイン監査ポリシーの作成方法を示します。

内容は次のとおりです。

- このチュートリアルの概要

- 手順1: UTL_MAIL PL/SQLパッケージのインストールおよび構成

- 手順2: ユーザー・アカウントの作成

- 手順3: ネットワーク・サービスに対するアクセス制御リスト・ファイルの構成

- 手順4: 電子メール・セキュリティ・アラートPL/SQLプロシージャの作成

- 手順5: ファイングレイン監査ポリシー設定の作成とテスト

- 手順6: アラートのテスト

- 手順7: このチュートリアルのコンポーネントの削除

このチュートリアルの概要

このチュートリアルでは、ユーザー(または侵入者)がポリシーに違反したときに実施される電子メールのアラートをファイングレイン監査ポリシーに追加する方法を示します。

注意:

- このチュートリアルを完了するには、SMTPサーバーが備わったデータベースを使用する必要があります。

- マルチテナント環境を使用している場合、このチュートリアルは現在のPDBのみに適用されます。

電子メール・アラートをファイングレイン監査ポリシーに追加するには、最初にアラートを生成するプロシージャを作成し、次に示すDBMS_FGA.ADD_POLICYパラメータを使用して、ユーザーがこのポリシーに違反した場合に、このファンクションをコールする必要があります。

- handler_schema: ハンドラ・イベントが格納されるスキーマ

- handler_module: イベント・ハンドラの名前

アラートは、電子メールまたはポケベルによる通知や、特定のファイルまたは表の更新など、環境に適した形式で生成できます。アラートを作成すると、California Senate Bill 1386などの特定のコンプライアンス規制を満たすことも可能です。この例では、電子メール・アラートを作成します。

この例では、セキュリティ管理者に対して、人事部門の担当者がHR.EMPLOYEES表内の給与情報を選択または変更しようとしていることを通知する電子メール・アラートを作成します。担当者はこの表を変更することを許可されていますが、コンプライアンス規制を満たすために、表内の給与情報に対するすべての選択および変更操作に関するレコードを作成できます。

手順1: UTL_MAIL PL/SQLパッケージのインストールおよび構成

UTL_MAIL PL/SQLで、添付ファイル、CCおよびBCCなど一般に使用される電子メール機能が組み込まれた電子メールを管理します。

このパッケージを使用するには、インストールして構成する必要があります。このコンポーネントは、デフォルトではインストールおよび構成されません。

1. SYSDBA管理権限を持つユーザーSYSとしてログインします。

sqlplus sys as sysdba
Enter password: password

2. マルチテナント環境で、適切なPDBに接続します。

次に例を示します。

CONNECT SYS@hrpdb AS SYSDBA
Enter password: password

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. 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サーバーはサポートされていないことに注意してください。

4. この例が終了した後に元に戻すことができるよう、SMTP_OUT_SERVER初期化パラメータの現行の値を調べて書き留めておきます。

次に例を示します。

SHOW PARAMETER SMTP_OUT_SERVER

SMTP_OUT_SERVERパラメータがすでに設定されている場合は、次のような出力が表示されます。

NAME                    TYPE              VALUE
----------------------- ----------------- ----------------------------------
SMTP_OUT_SERVER         string            some_imap_server.example.com

5. 次のALTER SYSTEM文を発行します。

ALTER SYSTEM SET SMTP_OUT_SERVER="imap_mail_server.example.com";

imap_mail_server.example.comを、電子メール・ツールのアカウント設定にあるSMTPサーバーの名前に置き換えます。これらの設定を引用符で囲んでください。次に例を示します。

ALTER SYSTEM SET SMTP_OUT_SERVER="my_imap_server.example.com";

6. SYSOPER権限を使用してSYSとして接続し、データベースを再起動します。

CONNECT SYS AS SYSOPER -- Or, CONNECT SYS@hrpdb AS SYSOPER
Enter password: password

SHUTDOWN IMMEDIATE
STARTUP

7. SMTP_OUT_SERVERパラメータの設定が正しいことを確認します。

CONNECT SYS AS SYSDBA -- Or, CONNECT SYS@hrpdb 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管理権限で接続していることを確認し、fga_adminユーザー(ファイングレイン監査ポリシーの作成者)を作成します。

次に例を示します。

CONNECT SYS AS SYSDBA -- Or, CONNECT SYS@hrpdb AS SYSDBA
Enter password: password

CREATE USER fga_admin IDENTIFIED BY password;
GRANT CREATE SESSION, CREATE PROCEDURE, AUDIT_ADMIN TO fga_admin;
GRANT EXECUTE ON UTL_TCP TO fga_admin;
GRANT EXECUTE ON UTL_SMTP TO fga_admin;
GRANT EXECUTE ON UTL_MAIL TO fga_admin;
GRANT EXECUTE ON DBMS_NETWORK_ACL_ADMIN TO fga_admin;

「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。

UTL_TCP、UTL_SMTP、UTL_MAILおよびDBMS_NETWORK_ACL_ADMIN PL/SQLパッケージは、作成する電子メール・セキュリティ・アラートで使用されます。

2. このポリシーの監査証跡をチェックする監査者ユーザーを作成します。

GRANT CREATE SESSION TO fga_auditor IDENTIFIED BY password;
GRANT AUDIT_VIEWER TO fga_auditor;

3. ユーザーSYSTEMで接続します。

CONNECT SYSTEM -- Or, CONNECT SYSTEM@hrpdb
Enter password: password

4. HRスキーマ・アカウントのロックが解除され、パスワードが付与されていることを確認します。必要に応じて、HRのロックを解除し、このユーザーにパスワードを付与します。

SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'HR';

このアカウント・ステータスは、OPENになっている必要があります。DBA_USERSビューに、ユーザーHRがロックされて期限切れになっていると表示された場合は、次の文を入力して、HRアカウントのロックを解除し、新しいパスワードを作成します。

ALTER USER HR ACCOUNT UNLOCK IDENTIFIED BY password;

「パスワードの最低要件」のガイドラインに従って、安全なパスワードを作成します。セキュリティを向上させるため、以前のリリースのOracle Databaseと同じパスワードをHRアカウントに指定しないでください。

5. 人事部門の担当者であるSusan Mavris(アクションの監査対象)用のユーザー・アカウントを作成し、このユーザーにHR.EMPLOYEES表へのアクセス権を付与します。

GRANT CREATE SESSION TO smavris IDENTIFIED BY password;
GRANT SELECT, INSERT, UPDATE, DELETE ON HR.EMPLOYEES TO SMAVRIS;

手順3: ネットワーク・サービス用のアクセス制御リストの構成

アクセス制御リスト(ACL)ファイルを使用して、外部ネットワーク・サービスへのファイングレイン・アクセスを有効にできます。

UTL_MAILなどのPL/SQLネットワーク・ユーティリティ・パッケージを使用するには、このタイプのアクセス制御リスト(ACL)ファイルを構成する必要があります。

1. ユーザーfga_adminでSQL*Plusに接続します。

CONNECT fga_admin -- Or, CONNECT fga_admin@hrpdb
Enter password: password

2. 次のアクセス制御設定とその権限定義を構成します。

BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host       => 'SMTP_OUT_SERVER_setting',
lower_port => 25,
ace        =>  xs$ace_type(privilege_list => xs$name_list('smtp'),
principal_name => 'FGA_ADMIN',
principal_type => xs_acl.ptype_db));
END;
/

この例の説明は、次のとおりです。

- SMTP_OUT_SERVER_setting: 「手順1: UTL_MAIL PL/SQLパッケージのインストールと構成」のSMTP_OUT_SERVERパラメータに設定したSMTP_OUT_SERVER設定を入力します。この設定は、電子メール・ツールで送信サーバーに指定されている設定と完全に一致させてください。

- lower_port: 電子メール・ツールで送信サーバーに指定されているポート番号を入力します。通常、この設定は25です。この値をlower_port設定に入力します。(現在、UTL_MAILパッケージではSSLをサポートしていません。電子メール・サーバーがSSLサーバーの場合、その電子メール・サーバーが別のポート番号を使用していても、ポート番号に25を入力します。)

- ace: ここで権限を定義します。

関連項目:
アクセス制御リスト(ACL)ファイルの構成の詳細は、「PL/SQLパッケージおよびタイプでのファイングレイン・アクセスの管理」を参照してください。

手順4: 電子メール・セキュリティ・アラートPL/SQLプロシージャの作成

電子メール・セキュリティ・アラートPL/SQLプロシージャは、違反について説明するメッセージを生成し、このメッセージを適切なユーザーに送信します。

- ユーザーfga_adminで、次のプロシージャを作成します。

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. ユーザーfga_adminで、chk_hr_empポリシーをファイングレイン監査ポリシーとして次のように作成します。

BEGIN
DBMS_FGA.ADD_POLICY (
object_schema      =>  'HR',
object_name        =>  'EMPLOYEES',
policy_name        =>  'CHK_HR_EMP',
audit_column       =>  'SALARY',
handler_schema     =>  'FGA_ADMIN',
handler_module     =>  'EMAIL_ALERT',
enable             =>   TRUE,
statement_types    =>  'SELECT, UPDATE');
END;
/

2. データベースに加えた変更をコミットします。

COMMIT;

3. これまでに作成した設定をテストします。

EXEC email_alert ('hr', 'employees', 'chk_hr_emp');

SQL*Plusに「PL/SQL procedure successfully completed」というメッセージが表示されます。まもなく、電子メール・サーバーの速度に応じて、電子メール・アラートを受信します。

ORA-24247「アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました」エラーの後にORA-06512「string行string」エラーが発生した場合は、アクセス制御リスト・ファイル内の設定を確認してください。

手順6: アラートのテスト

コンポーネントの準備ができたら、アラートをテストします。

1. ユーザーsmavrisでSQL*Plusに接続し、自分の給与を確認して金額を引き上げます。

CONNECT smavris -- Or, CONNECT smavris@hrpdb
Enter password: password

SELECT SALARY FROM HR.EMPLOYEES WHERE LAST_NAME = 'Mavris';

SALARY
-----------
6500

UPDATE HR.EMPLOYEES SET SALARY = 38000 WHERE LAST_NAME = 'Mavris';

ここまでの手順を実行すると、電子メール・サーバーの速度に応じて、自分自身(または通知の受信対象者)にTable modification on HR.EMPLOYEESという件名ヘッダーの電子メールが届き、HR.EMPLOYEES表の改ざんについて通知されます。違反者を検索するのに必要なのは、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せるのみです。

2. 必要に応じて、ユーザーfga_adminで接続し、次のプロシージャを実行して、監査レコードをディスクに書き込みます。

CONNECT fga_admin -- Or, CONNECT fga_admin@hrpdb
Enter password: password

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

3. 次のようにユーザーfga_auditorとして、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。

CONNECT fga_auditor -- Or, CONNECT fga_auditor@hrpdb
Enter password: password

col dbusername format a20
col sql_text format a66
col audit_type format a17

SELECT DBUSERNAME, SQL_TEXT, AUDIT_TYPE
FROM UNIFIED_AUDIT_TRAIL
WHERE OBJECT_SCHEMA = 'HR' AND OBJECT_NAME = 'EMPLOYEES';

次のような出力が表示されます。

DBUSERNAME  SQL_TEXT                                                          AUDIT_TYPE
----------  ----------------------------------------------------------------- ----------------
SMAVRIS     UPDATE HR.EMPLOYEES SET SALARY = 38000 WHERE LAST_NAME = 'Mavris' FineGrainedAudit

監査証跡では、Susan Mavrisが実行し、HR.EMPLOYEES表のSALARY列に影響を与えたSQL文が取得されます。彼女が実行した最初の文(現在の給与に関して尋ねた文)は、監査ポリシーの影響を受けなかったため、記録されませんでした。これは、Oracle Databaseでは、監査関数は自律型トランザクションとして実行され、handler_module設定のアクションのみをコミットし、ユーザー・トランザクションはコミットしないためです。この関数はユーザーのSQLトランザクションには影響を与えません。

手順7: このチュートリアルのコンポーネントの削除

このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。

1. SYSTEM権限を持つユーザーでSQL*Plusに接続し、ユーザーfga_admin (fga_adminスキーマ内のオブジェクトを含む)、fga_auditorおよびsmavrisを削除します。

CONNECT SYSTEM -- Or, CONNECT SYSTEM@hrpdb
Enter password: password

DROP USER fga_admin CASCADE;
DROP USER fga_auditor;
DROP USER smavris;

2. ユーザーHRで接続し、Susan Mavrisの引き上げた給与を元に戻します。

CONNECT HR -- Or, CONNECT HR@hrpdb
Enter password: password

UPDATE HR.EMPLOYEES SET SALARY = 6500 WHERE LAST_NAME = 'Mavris';

3. 他のユーザーがHRを使用しない場合、このアカウントはロックして期限切れにできます。

ALTER USER HR PASSWORD EXPIRE ACCOUNT LOCK;

4. 次のALTER SYSTEM文を発行して、手順1: UTL_MAIL PL/SQLパッケージのインストールおよび構成の手順5からSMTP_OUT_SERVERパラメータを前の値にリストアします。

ALTER SYSTEM SET SMTP_OUT_SERVER="previous_value";

この設定は引用符で囲みます。例:

ALTER SYSTEM SET SMTP_OUT_SERVER="some_imap_server.example.com"

5. データベース・インスタンスを再起動します。

監査ポリシーのデータ・ディクショナリ・ビュー

Oracle Databaseには、監査情報を提供するデータ・ディクショナリ・ビューおよび動的ビューが用意されています。

表22-19に、これらのビューを示します。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ヒント:

監査ポリシーに関するエラー情報を検索するには、トレース・ファイルを確認します。USER_DUMP_DEST初期化パラメータは、トレース・ファイルの位置を示します。

表22-19 監査アクティビティに関する情報を表示するビュー

ビュー

説明

ALL_AUDIT_POLICIES

すべてのファイングレイン監査ポリシーに関する情報が表示されます。

ALL_DEF_AUDIT_OPTS

オブジェクトの作成時に適用されるデフォルトのオブジェクト監査オプションがリストされます。

AUDIT_UNIFIED_CONTEXTS

監査証跡で取得されるように構成されているアプリケーション・コンテキスト値が表示されます。

AUDIT_UNIFIED_ENABLED_POLICIES

データベースで有効なすべての統合監査ポリシーが表示されます。

AUDIT_UNIFIED_POLICIES

データベースで作成されたすべての統合監査ポリシーが表示されます。

AUDIT_UNIFIED_POLICY_COMMENTS

COMMENT SQL文を使用して統合監査ポリシーに説明が入力された場合に、各統合監査ポリシーの説明が表示されます。

AUDITABLE_SYSTEM_ACTIONS

監査可能なシステム・アクション番号がアクション名にマップされます。

CDB_UNIFIED_AUDIT_TRAIL

UNIFIED_AUDIT_TRAILビューと同様、監査レコードを表示しますが、マルチテナント環境のすべてのPDBからの監査レコードを表示します。このビューは、ルートのみで使用可能で、そこから問い合せる必要があります。

DBA_AUDIT_POLICIES

ファイングレイン監査ポリシーに関する情報が表示されます。

DBA_SA_AUDIT_OPTIONS

ユーザーによって実行される監査対象のOracle Label Securityイベントが表示され、ユーザーのアクションが成功したか失敗したかが示されます。

DBA_XS_AUDIT_TRAIL

Oracle Database Real Application Securityに関連する監査証跡の情報が表示されます。

DV$CONFIGURATION_AUDIT

Oracle Database Vault管理者による構成変更が表示されます。

DV$ENFORCEMENT_AUDIT

Oracle Database Vaultポリシーによって影響を受けるユーザー・アクティビティが表示されます。

SYSTEM_PRIVILEGE_MAP (表)

権限(監査オプション)型コードが表示されます。この表を使用して、権限(監査オプション)の型番号を型名にマップできます。

USER_AUDIT_POLICIES

現行ユーザーによって所有される表およびビューのすべてのファイングレイン監査ポリシーに関する情報が表示されます。

UNIFIED_AUDIT_TRAIL

すべての監査レコードが表示されます。

V$OPTION

統合監査のPARAMETER列を問い合せて、統合監査が有効かどうかを確認できます。

V$XML_AUDIT_TRAIL

XML形式のファイルに書き込まれた標準監査、ファイングレイン監査、SYS監査および必須監査のレコードが表示されます。

23 監査証跡の管理

AUDIT_ADMINロールを付与されているユーザーとして、監査証跡の管理、監査証跡のアーカイブおよび監査証跡レコードの削除を実行できます。

内容は次のとおりです。

- 統合監査証跡の管理

- 監査証跡のアーカイブ

- 監査証跡レコードの削除

- 監査証跡管理のデータ・ディクショナリ・ビュー

統合監査証跡の管理

監査はデフォルトで有効ですが、監査レコードがディスクに書き込まれるタイミングを制御できます。

内容は次のとおりです。

- 監査レコードが作成される場合

- 強制的に監査されるアクティビティ

- カーソルが監査に与える影響

- AUDSYSスキーマへの統合監査証跡レコードの書込み

- 統合監査証跡へのオペレーティング・システムの監査レコードの移動

- 統合監査の無効化

関連項目:

監査証跡レコードの削除

監査レコードが作成される場合

監査は常に有効になっています。Oracle Databaseは、監査対象のSQL文の実行フェーズ中または実行フェーズ後に監査レコードを生成します。

PL/SQLプログラム・ユニット内のSQL文は、プログラム・ユニットの実行時に必要に応じて個別に監査されます。

監査証跡のレコードがディスクに書き込まれる頻度を制御できます。書込みモードがQUEUEDに設定されている場合、監査レコードはディスクに即座に書き込まれず、SGAに定期的に書き込まれます。監査レコードをディスクに即座に書き込む場合は、即時書込みモードに設定できます。そうでない場合は、キューが3秒前より前にフラッシュされたかどうか、それに従って監査レコードがSGAキューにフラッシュされるかどうかをデフォルトでチェックする、最小フラッシュしきい値が構成されています。ただし、データベース・アクティビティにより、フラッシュが3秒ごとに発生せず、長時間かかる場合があります。

監査証跡レコードの生成と挿入は、ユーザー・トランザクションのコミットからは独立して実行されます。つまり、ユーザー・トランザクションがロールバックされても、監査証跡レコードはコミットされたままになります。

データベース・ユーザーがデータベースに接続した時点で有効になる統合監査ポリシーの文監査オプションと権限監査オプションは、そのセッションの持続期間中は有効です。セッションがすでにアクティブになっている場合、文または権限の統合監査のオプションを設定または変更しても、そのセッション中は有効になりません。修正した文監査オプションまたは権限監査オプションは、カレント・セッションを終了し、新しいセッションを作成した時点で有効になります。

一方、オブジェクト監査オプションについて変更した内容は、カレント・セッションでただちに有効になります。

デフォルトでは、監査証跡レコードはSYSAUX表領域に書き込まれます。DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATIONプロシージャを使用して、暗号化されている表領域を含め、異なる表領域を指定できます。

関連項目:

- 即時書込みモードおよびキュー書込みモードの詳細は、AUDSYSスキーマへの統合監査証跡レコードの書込みを参照してください

- SQL文処理の様々なフェーズや共有SQLについては、『Oracle Database概要』を参照してください。

- DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATIONプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

強制的に監査されるアクティビティ

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューでは、SYSDBA、SYSBACKUP、SYSKMなどの管理ユーザーからのアクティビティを取得します。

統合監査証跡を監査する必要はありません。統合監査証跡は、AUDSYSスキーマ内の読取り専用表にあります。したがって、統合監査証跡ビューに対するDMLは許可されません。AUDSYSスキーマからの基礎となるディクショナリ表に対するDMLおよびDDL操作も許可されません。

SYSTEM_PRIVILEGE_USED列は、アクティビティに使用された管理権限のタイプを示します。

監査ポリシーの変更など、次の監査関連のアクティビティは強制的に監査されます。

- CREATE AUDIT POLICY

- ALTER AUDIT POLICY

- DROP AUDIT POLICY

- AUDIT

- NOAUDIT

- DBMS_FGA PL/SQLパッケージのEXECUTE

- DBMS_AUDIT_MGMT PL/SQLパッケージのEXECUTE

- AUDSYS監査証跡表でのALTER TABLEの試行(この表は監査できません)

- 管理ユーザーSYS、SYSDBA、SYSOPER、SYSASM、SYSBACKUP、SYSDGおよびSYSKMによるトップ・レベルの文(データベースがオープンするまで)。データベースがオープンされると、Oracle Databaseはシステムの監査構成(AUDIT文のBY句などを使用して適用された構成だけでなく、AUDIT文にBY句がない場合や、EXCEPT句が使用され、これらのユーザーが除外されなかった場合に、すべてのユーザーに対して適用された構成)を使用して、これらのユーザーを監査します。

- SYS.AUD$およびSYS.FGA_LOG$ディクショナリ表に対してユーザーが発行したすべてのDML文

- 統合監査内部表のデータまたはメタデータの変更。この表に対するSELECT文はデフォルトで、または強制的に監査されます。

- Oracle Database Vaultに対して行われるすべての構成変更

関連項目:

管理ユーザーの監査

カーソルが監査に与える影響

カーソル内で監査対象の操作が実行されるたびに、Oracle Databaseでは監査証跡に監査レコードが1つ挿入されます。

カーソルを再利用させるイベントは、次のとおりです。

- カーソルを再利用のためにオープン状態にしておく、Oracle Formsなどのアプリケーション

- 新しいバインド変数を使用したカーソルの継続実行

- 1つのカーソルを再利用するためにPL/SQLエンジンにより文が最適化される場合に、PL/SQLループ内で実行される文

監査は、カーソルが共有されているかどうかの影響を受けません。それぞれのユーザーは、カーソルの最初の実行時に自分の監査証跡レコードを作成します。

AUDSYSスキーマへの統合監査証跡レコードの書込み

Oracle Databaseは、監査レコードをAUDSYSスキーマに書き込みます。

内容は次のとおりです。

- AUDSYSへの統合監査証跡レコードの書込みについて

- 統合監査証跡レコードでの書込みモードの設定

- キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ

AUDSYSの統合監査証跡レコードの書込みについて

新規または移行直後のOracle Databaseインストールでは、統合監査が初期化されてレコードが生成されるまで、AUDSYSスキーマは空です。

注意:

Oracle Database 12cリリース12.2以降、監査レコードをフラッシュする機能は非推奨となりましたが、下位互換性のため維持されています。

この設計により、監査証跡プロセスとデータベースの全体のパフォーマンスが大幅に向上します。以前のリリースでは、インスタンスがクラッシュした場合、またはSHUTDOWN ABORT操作の実行中、一部の監査レコードが失われる可能性がありました。DBMS_AUDIT_MGMT.TRANSFER_UNIFIED_AUDIT_RECORDSプロシージャを使用して、監査レコードをAUDSYSスキーマの内部リレーショナル表に転送することで、監査レコードがAUDSYSスキーマの監査表に即座に書き込まれるように監査証跡を構成することをお薦めします。

以前のリリースからは、次のモード(非推奨となりましたが、下位互換性のため維持されています)を使用できます。ただし、かわりにDBMS_AUDIT_MGMT.TRANSFER_UNIFIED_AUDIT_RECORDSプロシージャを使用することをお薦めします(詳細は、Oracle Databaseアップグレード・ガイドを参照)。

- 即時書込みモード。この設定では、すべての監査レコードが監査証跡に即座に書き込まれます。ただし、データベースのパフォーマンスに影響する場合があります。

- キュー書込みモード。この設定は、デフォルトの書込みモードで、監査レコードをメモリーにキューして、AUDSYSスキーマ監査表に定期的に書き込みます。SGAのサイズを設定するには、UNIFIED_AUDIT_SGA_QUEUE_SIZE初期化パラメータを設定します。デフォルトのサイズは1MBで、1から30の範囲を入力できます。

注意:

UNIFIED_AUDIT_SGA_QUEUE_SIZE初期化パラメータは非推奨となりましたが、下位互換性のため現在も維持されています。

関連項目:

UNIFIED_AUDIT_SGA_QUEUE_SIZE初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

統合監査証跡レコードでの書込みモードの設定

マルチテナント環境では、DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTYプロシージャは現在のプラガブル・データベース(PDB)のみに適用されます。

データベースが読取り専用の場合、DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTYでSGAに値が直接設定されます。

1. AUDIT_ADMINロールを付与されているユーザーとしてSQL*Plusにログインします。

例:

sqlplus audit_admin
Enter password: password

2. マルチテナント環境で、適切なPDBに接続します。

例:

CONNECT audit_admin@hrpdb
Enter password: password

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. 次のように、DBMS_AUDIT_MGMTパッケージのAUDIT_TRAIL_MODEプロパティを設定します。

- 即時書込みモードを使用するには、次のプロシージャを実行します。

BEGIN
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
DBMS_AUDIT_MGMT.AUDIT_TRAIL_WRITE_MODE,
DBMS_AUDIT_MGMT.AUDIT_TRAIL_IMMEDIATE_WRITE);
END;
/

- キュー書込みモードを使用するには、次のプロシージャを実行します。

BEGIN
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
DBMS_AUDIT_MGMT.AUDIT_TRAIL_WRITE_MODE,
DBMS_AUDIT_MGMT.AUDIT_TRAIL_QUEUED_WRITE);
END;
/

この設定は、後続のデータベース・セッションに適用されます。

キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ

キュー書込みモードを使用する場合は、レコードを統合監査証跡に手動で書込みできます。

デフォルトで構成されている最小フラッシュしきい値があることに注意してください。これは、キューが3秒前より前にフラッシュされたかどうか、それに従って監査レコードがSGAキューにフラッシュされるかどうかをチェックします。ただし、データベース・アクティビティにより、フラッシュが3秒ごとに発生せず、長時間かかる場合があります。

- 現行データベース・インスタンスでのディスクへのレコードの書込み

- Oracle RAC環境間でのディスクへのレコードの書込み

- マルチテナント環境でのディスクへのレコードの書込み

現行データベース・インスタンスでのディスクへのレコードの書込み

現行のデータベース・インスタンスまたは現行のOracle Real Application Clusters (Oracle RAC)インスタンスのディスクにレコードを手動で書込みできます。

- レコードをディスクに手動で書き込むには、次のいずれかのプロシージャを実行します。

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL(DBMS_AUDIT_MGMT.FLUSH_CURRENT_INSTANCE);

Oracle RAC環境間でのディスクへのレコードの書込み

すべてのOracle Real Application Cluster (Oracle RAC)インスタンスの監査レコードをフラッシュできます。

- Oracle RACインスタンスで監査レコードをフラッシュするには、次のプロシージャを実行します。

EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL(DBMS_AUDIT_MGMT.FLUSH_ALL_INSTANCES);

マルチテナント環境でのディスクへのレコードの書込み

マルチテナント環境では、現在のPDBまたはマルチテナント環境のすべてのPDB間でディスクに監査証跡レコードを書き込むことができます。

- 監査証跡レコードをディスクに書き込むには、次のいずれかのプロシージャを使用します。

- 現在のPDBの場合:

BEGIN
DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL(
CONTAINER  => DBMS_AUDIT_MGMT.CONTAINER_CURRENT);
END;
/

- マルチテナント環境のすべてのPDBの場合:

BEGIN
DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL(
CONTAINER  => DBMS_AUDIT_MGMT.CONTAINER_ALL);
END;
/

統合監査証跡へのオペレーティング・システムの監査レコードの移動

監査レコードは$ORACLE_BASE/audit/$ORACLE_SIDディレクトリ内の外部ファイルに書き込むことができます。

データベースが書込み可能でない場合(データベースのマウント中など)、データベースがクローズされている場合、または読取り専用の場合は、Oracle Databaseによって、監査レコードがこれらの外部ファイルに書き込まれます。

DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILESプロシージャを実行して、データベースにファイルをロードできます。多くのオペレーティング・システム監査レコードを統合監査証跡に移動している場合は、パフォーマンスが影響を受ける場合があるので注意してください。

データベースが書込み可能な場合に、これらのファイルの監査レコードをAUDSYSスキーマ監査表に移動する手順:

1. AUDIT_ADMINロールを割り当てられているユーザーとして、データベース・インスタンスにログインします。

例:

CONNECT aud_admin
Enter password: password
Connected.

マルチテナント環境で、監査証跡レコードを統合監査証跡に移動するPDBにログインします。

例:

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

2. データベースがオープンで、書込み可能であることを確認します。

非CDBアーキテクチャの場合、開いていて書込み可能なデータベースを検索するには、V$DATABASEビューを問い合せます。

例:

SELECT NAME, OPEN_MODE FROM V$DATABASE;

NAME            OPEN_MODE
--------------- ----------
HRPDB           READ WRITE

マルチテナント環境では、V$PDBSビューを問い合せて、現在のインスタンスに関連付けられているPDBに関する情報を検索できます。

例:

SELECT NAME, OPEN_MODE FROM V$PDBS;

NAME            OPEN_MODE
--------------- ----------
HRPDB           READ WRITE

3. DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILESプロシージャを実行します。

EXEC DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILES;

監査レコードはAUDSYSスキーマ監査表に即座にロードされ、$ORACLE_BASE/audit/$ORACLE_SIDディレクトリから削除されます。

統合監査の無効化

統合監査を無効にすることができます。

1. 現在有効となっている統合監査ポリシーをすべて無効化します。
このステップは、このプロシージャが完了したときに、データベースが混合モード監査に入ることを防ぎます。混合モード監査の詳細は、混合モードの監査についてを参照してください。

a. AUDIT_ADMINロールを割り当てられているユーザーとして、データベース・インスタンスにログインします。

b. 有効な統合監査ポリシーを検索するには、AUDIT_UNIFIED_ENABLED_POLICIESデータ・ディクショナリ・ビューのPOLICY_NAME列およびENABLED_OPT列を問い合せます。

c. NOAUDIT POLICY文を実行して有効になっている各ポリシーを無効にします。
詳細は、統合監査ポリシーの無効化を参照してください。

2. SYSOPER権限を持つユーザーSYSとして接続します。

CONNECT sys as sysoper
Enter password: password

マルチテナント環境の場合は、このコマンドによりルートに接続されます。

3. データベースの停止
例:

SHUTDOWN IMMEDIATE

マルチテナント環境の場合は、このコマンドによりCDB内のすべてのPDBが終了します。

4. プラットフォームに応じて次のようにします。

- UNIXシステム: 次のコマンドを実行します。

cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk uniaud_off ioracle

- Windowsシステム: %ORACLE_HOME%/bin/orauniaud12.dllファイルの名前を%ORACLE_HOME%/bin/orauniaud12.dll.dblに変更します。

マルチテナント環境の場合は、これらのアクションによりCDB内のすべてのPDBの統合監査が無効化されます。

5. SQL*Plusで、データベースを再起動します。

STARTUP

マルチテナント環境の場合は、このコマンドによりCDB内のすべてのPDBが再起動します。

監査証跡のアーカイブ

従来のオペレーティング・システム、統合データベースおよび従来のデータベースの監査証跡をアーカイブできます。

内容は次のとおりです。

- 従来のオペレーティング・システム監査証跡のアーカイブ

- 統合監査証跡および従来のデータベースの監査証跡のアーカイブ

従来のオペレーティング・システム監査証跡のアーカイブ

Oracle Databaseをアップグレードした後に、従来のオペレーティング・システム監査ファイルのアーカイブを作成できます。

アップグレードしたデータベースから従来のオペレーティング・システムの監査証跡をアーカイブするには、プラットフォーム固有のオペレーティング・システム・ツールを使用して、従来のオペレーティング・システム監査ファイルのアーカイブを作成します。

- 従来のオペレーティング・システム監査ファイルをアーカイブするには、次の方法を使用します。

- Oracle Audit Vault and Database Firewallを使用します。Oracle Databaseとは別にOracle Audit Vault and Database Firewallをインストールします。

- テープまたはディスクにバックアップを作成します。監査ファイルの圧縮ファイルを作成し、それをテープまたはディスクに格納できます。詳細は、使用しているオペレーティング・システムのマニュアルを参照してください。

その後、監査証跡の領域を解放して監査証跡管理を容易にするために、従来のオペレーティング・システム監査レコードをパージ(削除)する必要があります。

関連項目:

- Oracle Audit Vault and Database Firewallの詳細は、『Oracle Audit Vault and Database Firewall管理者ガイド』を参照してください

- 統合監査証跡へのオペレーティング・システムの監査レコードの移動

- 監査証跡レコードの削除

統合監査証跡および従来のデータベースの監査証跡のアーカイブ

監査証跡は、大きくなりすぎないように定期的にアーカイブし、パージする必要があります。

アーカイブと削除により、監査証跡の領域が解放され、データベース監査証跡の削除が容易になります。

統合および従来のデータベースの監査証跡のアーカイブを作成するには、Oracle Audit Vault and Database Firewallを使用します。Oracle Databaseとは別にOracle Audit Vault and Database Firewallをインストールします。

アーカイブが完了したら、データベース監査証跡の内容を削除できます。

- 統合監査レコード、従来の標準監査レコードおよび従来のファイングレイン監査レコードをアーカイブするには、関連するレコードを通常のデータベース表にコピーします。
例:

INSERT INTO table SELECT ... FROM UNIFIED_AUDIT_TRAIL ...;
INSERT INTO table SELECT ... FROM SYS.AUD$ ...;
INSERT INTO table SELECT ... FROM SYS.FGA_LOG$ ...;

関連項目:

- Oracle Audit Vault and Database Firewallの詳細は、『Oracle Audit Vault and Database Firewall管理者ガイド』を参照してください

- 監査証跡レコードの削除

監査証跡レコードの削除

DBMS_AUDIT_MGMT PL/SQLパッケージを使用して、自動削除ジョブをスケジューリングして、監査レコードを手動で削除し、他の監査証跡操作を実行できます。

内容は次のとおりです。

- 監査証跡レコードの削除の概要

- 監査証跡の削除方法の選択

- 監査証跡の自動削除ジョブのスケジューリング

- 監査証跡の手動削除

- 他の監査証跡削除操作

- 例: 統合監査証跡の削除操作の直接コール

関連項目:

統合監査証跡の管理

監査証跡レコードの削除の概要

様々な方法を使用して、監査証跡レコードをパージできます。

監査証跡レコードは、定期的にアーカイブしてから削除するようにしてください。監査証跡レコードのサブセットを削除したり、指定した時間間隔で実行する削除ジョブを作成したりできます。Oracle Databaseでは、アーカイブ・タイムスタンプより前に作成された監査証跡レコードが削除されるか、すべての監査証跡レコードが削除されます。読取り/書込みデータベースおよび読取り専用データベースの両方で監査証跡レコードを削除できます。

削除プロセスでは、統合監査証跡だけでなく、前のリリースのOracle Databaseの監査証跡も考慮されます。たとえば、オペレーティング・システムまたはXMLの監査レコードが含まれるアップグレード済のデータベースを移行した場合は、この項のプロシージャを使用して、それらをアーカイブして削除できます。

監査証跡の削除タスクを実行するには、ほとんどの場合、DBMS_AUDIT_MGMT PL/SQLパッケージを使用します。DBMS_AUDIT_MGMTパッケージを使用するには、AUDIT_ADMINロールが必要です。Oracle Databaseでは、DBMS_AUDIT_MGMT PL/SQLパッケージ・プロシージャのすべての実行を強制的に監査します。

Oracle Audit Vault and Database Firewallをインストールしている場合は、監査証跡パージ・プロセスは、このマニュアルで説明している手順とは異なります。たとえば、Oracle Audit Vaultでは、監査証跡が自動的にアーカイブされます。

注意:

Oracle Databaseでは、監査証跡からのレコードの削除はすべて例外なく監査されます。

関連項目:

- Oracle Audit Vault and Database Firewallの詳細は、『Oracle Audit Vault and Database Firewall管理者ガイド』を参照してください。

- DBMS_AUDIT_MGMT PL/SQLパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください

- DBA_AUDIT_MGMT関連のビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

監査証跡の削除方法の選択

監査証跡パージ方法の選択は、パージがスケジュールに基づいて定期的に行われるか、指定時間に実行されるかに応じて決まります。

内容は次のとおりです。

- スケジュールに基づいた監査証跡の定期的なパージ

- 指定時間での監査証跡の手動パージ

スケジュールに基づいた監査証跡の定期的なパージ

すべての監査レコード、または指定したタイムスタンプより前に作成された監査レコードをスケジュールに基づいて定期的にパージできます。

たとえば、土曜日の午前2時に毎回パージを実行するようにスケジューリングできます。

1. 必要に応じて、監査表の削除プロセス中に追加生成されるレコードに対応するために、オンラインREDOログとアーカイブREDOログのサイズをチューニングします。

2. タイムスタンプおよびアーカイブ方針を計画します。

3. オプションで、監査レコードのアーカイブ・タイムスタンプを設定します。

4. 削除ジョブを作成してスケジューリングします。

詳細は、監査証跡の自動削除ジョブのスケジューリングを参照してください。

指定時間での監査証跡の手動パージ

削除スケジュールを作成するのではなく、1回の手動操作で監査レコードを即座に削除できます。

1. 必要に応じて、監査表の削除プロセス中に追加生成されるレコードに対応するために、オンラインREDOログとアーカイブREDOログのサイズをチューニングします。

2. タイムスタンプおよびアーカイブ方針を計画します。

3. オプションで、監査レコードのアーカイブ・タイムスタンプを設定します。

4. 削除操作を実行します。

詳細は、監査証跡の手動削除を参照してください。

監査証跡の自動削除ジョブのスケジューリング

自動パージ・ジョブをスケジューリングする場合、オンラインおよびアーカイブREDOログのサイズをチューニングして、タイムスタンプとアーカイブの戦略を計画し、アーカイブ・タイムスタンプをオプションで設定して、パージ・ジョブを作成およびスケジューリングする必要があります。

内容は次のとおりです。

- 自動削除ジョブのスケジューリングについて

- 手順1: オンラインREDOログとアーカイブREDOログのサイズのチューニング(必要に応じて)

- 手順2: タイムスタンプおよびアーカイブ方針の計画

- 手順3: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)

- 手順4: 削除ジョブの作成とスケジューリング

自動削除ジョブのスケジューリングについて

監査証跡全体を削除することも、タイムスタンプより前に作成された一部の監査証跡のみを削除することもできます。

タイムスタンプより前に作成された個々の監査レコードを削除できます。

監査証跡(特に、大きなもの)を削除する場合は、完了するまでに時間がかかることがあります。削除ジョブは、データベースの負荷が低い時間帯に実行するようにスケジューリングするのが賢明です。

競合しないかぎり、異なる監査証跡タイプに対する複数の削除ジョブを作成できます。たとえば、標準監査証跡表の削除ジョブを作成し、その後でファイングレイン監査証跡表の削除ジョブを作成できます。ただし、DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STDまたはDBMS_AUDIT_MGMT.AUDIT_TRAIL_ALLプロパティを使用して、両方のタイプまたはすべてのタイプをまとめて処理する削除ジョブを作成することはできません。また、DBMS_SCHEDULER PL/SQLパッケージで作成されるジョブは読取り専用データベースで実行されないことに注意してください。DBMS_AUDIT_MGMTで作成される自動削除ジョブではDBMS_SCHEDULERパッケージを使用してタスクをスケジューリングします。したがって、これらのジョブは読取り専用モードで開いているデータベースまたはPDBで実行できません。

手順1: オンラインREDOログとアーカイブREDOログのサイズのチューニング(必要に応じて)

削除プロセスでは、REDOログが追加生成される場合があります。

- 必要に応じて、監査表の削除プロセス中に追加生成されるレコードに対応するために、オンラインREDOログとアーカイブREDOログのサイズをチューニングします。

統合監査環境では、混合モードの監査環境と同じ数のREDOログは削除プロセスで生成されないため、統合監査に移行している場合は、この手順を省略できます。

関連項目:

ログ・ファイルのチューニングの詳細は、『Oracle Database管理者ガイド』を参照してください。

手順2: タイムスタンプおよびアーカイブ方針の計画

監査レコードをアーカイブするには、これらのレコードのタイムスタンプを記録する必要があります。

- タイムスタンプの日付を見つけるために、DBA_AUDIT_MGMT_LAST_ARCH_TSデータ・ディクショナリ・ビューを問い合せます。

その後、削除を実行すると、このタイムスタンプの日付より前に作成された監査証跡レコードのみが削除されます。手順3: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)を参照してください

レコードのタイムスタンプを設定したら、アーカイブを開始できます。詳細は、監査証跡のアーカイブを参照してください。

手順3: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)

すべての監査証跡を削除する場合は、この手順を省略できます。

最後に監査レコードがアーカイブされた日時のタイムスタンプを設定できます。アーカイブ・タイムスタンプを設定すると、削除インフラストラクチャのクリーン・アップ・ポイントが指定されます。読取り専用データベースにタイムスタンプを設定する場合、DBMS_AUDIT.MGMT.GET_LAST_ARCHIVE_TIMESTAMPファンクションを使用して、それが実行されたインスタンス用に構成された最後のアーカイブ・タイムスタンプを確認します。読取り/書込みデータベースの場合、DBA_AUDIT_MGMT_LAST_ARCH_TSデータ・ディクショナリ・ビューを問い合せます。

統合監査証跡の最終アーカイブ・タイムスタンプを調べるには、DBA_AUDIT_MGMT_LAST_ARCH_TSデータ・ディクショナリ・ビューを問い合せます。タイムスタンプを設定した後でDBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャを実行すると、そのタイムスタンプより前の時間を示すすべての監査レコードが監査証跡から削除されます。アーカイブ・タイムスタンプ設定を消去する場合は、アーカイブ・タイムスタンプ設定の消去を参照してください。

Oracle Database Real Application Clustersを使用している場合は、ネットワーク・タイム・プロトコル(NTP)を使用して、Oracle Databaseインスタンスをインストールしている各コンピュータ上の時間を同期化してください。たとえば、1つのOracle RACインスタンス・ノードの時間を午前11:00:00に設定し、次のOracle RACインスタンス・ノードの時間を11:00:05に設定するとします。その結果、2つのノードの時間に矛盾が生じます。ネットワーク・タイム・プロトコル(NTP)を使用して、これらのOracle RACインスタンス・ノードの時間を同期化できます。

削除ジョブのタイムスタンプを設定する手順:

1. AUDIT_ADMINロールを割り当てられているユーザーとして、データベース・インスタンスにログインします。

マルチテナント環境で、削除ジョブをスケジューリングするルートまたはPDBにログインします。ほとんどの場合、個々のPDBで削除ジョブをスケジューリングできます。

たとえば、hrpdbというPDBにログインするには、次のようにします。

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

2. 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_UNIFIED,
LAST_ARCHIVE_TIME    =>  '12-OCT-2013 06:30:00.00',
RAC_INSTANCE_NUMBER  =>  1,
CONTAINER            => DBMS_AUDIT_MGMT.CONTAINER_CURRENT);
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPEは、監査証跡タイプを指定します。DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIEDは、これを統合監査証跡に設定します。
前のリリースの従来の監査データがまだ存在するアップグレード済のデータベースの場合:

- 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_UNIFIED、AUDIT_TRAIL_AUD_STDおよびAUDIT_TRAIL_FGA_STDの場合は、YYYY-MM-DD HH:MI:SS.FF UTC (協定世界時)形式で指定し、AUDIT_TRAIL_OSおよびAUDIT_TRAIL_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つのみであるためです。デフォルトは、NULLです。現在のインスタンスのインスタンス番号を調べるには、SQL*PlusでSHOW PARAMETER INSTANCE_NUMBERコマンドを発行します。

- CONTAINERは、タイムスタンプをマルチテナント環境に適用します。DBMS_AUDIT_MGMT.CONTAINER_CURRENTは現在のPDBを指定し、DBMS_AUDIT_MGMT.CONTAINER_ALLはマルチテナント環境のすべてのPDBに適用されます。
CONTAINERをDBMS_MGMT.CONTAINER_ALLに設定できるのはルートからのみで、DBMS_MGMT.CONTAINER_CURRENTに設定できるのはPDBからのみです。

通常、タイムスタンプを設定したら、DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャを使用して、タイムスタンプの日付より前に作成された監査レコードを削除できます。

手順4: 削除ジョブの作成とスケジューリング

DBMS_AUDIT_MGMT PL/SQLパッケージを使用して、削除ジョブを作成およびスケジューリングできます。

- DBMS_AUDIT_MGMT.CREATE_PURGE_JOB PL/SQLプロシージャを実行して、削除ジョブを作成してスケジューリングします。
例:

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

BEGIN
DBMS_AUDIT_MGMT.CREATE_PURGE_JOB (
AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
AUDIT_TRAIL_PURGE_INTERVAL  => 12,
AUDIT_TRAIL_PURGE_NAME      => 'Audit_Trail_PJ',
USE_LAST_ARCH_TIMESTAMP     => TRUE,
CONTAINER                   => DBMS_AUDIT_MGMT.CONTAINER_CURRENT);
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: 監査証跡タイプを指定します。DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIEDは、これを統合監査証跡に設定します。
前のリリースの監査データがまだ存在するアップグレード済のデータベースの場合:

- 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列を問い合せ、読取り専用データベースの場合はDBMS_AUDIT_MGMT.GET_LAST_ARCHIVE_TIMESTAMPファンクションを使用します。デフォルト値はTRUEです。USE_LAST_ARCH_TIMESTAMPはTRUEに設定することをお薦めします。

- FALSEは、最終アーカイブ・タイムスタンプを考慮せずに、すべての監査レコードを削除します。削除されているはずの監査レコードを誤って削除しないように、この設定を使用する際には注意が必要です。

- CONTAINERは、マルチテナント環境で削除ジョブを作成する場所を定義するのに使用されます。CONTAINERをDBMS_AUDIT_MGMT.CONTAINER_CURRENTに設定すると、現在のPDBからのみ使用および表示可能になり、管理されます。DBMS_AUDIT_MGMT.CONTAINER_ALL設定では、ジョブがルートに作成されます。定義済のジョブ・スケジュールに従って実行されるグローバル・ジョブとしてジョブを定義します。ジョブが起動されると、マルチテナント環境のすべてのPDBの監査証跡がクリーンアップされます。ジョブをルートに作成した場合は、ルートからのみ表示可能です。したがって、有効化、無効化および削除はルートからのみ可能です。

監査証跡の手動削除

DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILプロシージャを使用して、監査証跡を手動でパージできます。

内容は次のとおりです。

- 監査証跡の手動削除について

- DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILを使用した監査証跡の手動パージ

監査証跡の手動削除について

監査証跡は、削除ジョブをスケジューリングしなくても、手動で即座に削除できます。

削除ジョブと同様に、アーカイブ・タイムスタンプの日付より前に作成された監査証跡レコード、または監査証跡内のすべてのレコードを削除できます。このプロシージャを実行した場合、現行の監査ディレクトリのみがクリーン・アップされます。

前のリリースの監査証跡がまだ存在しているアップグレード済のデータベースの場合は、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ファイルに書き込まれます。(syslogファイルを使用するよう構成すると、メッセージがsyslogデーモン・プロセスに送信されることに注意してください。syslogデーモン・プロセスは、syslogファイルへのコミットされた書込みを示す確認応答をOracle Databaseに返しません。)AUDIT_TRAIL_TYPEプロパティをDBMS_AUDIT_MGMT.AUDIT_TRAIL_OSに設定すると、監査ディレクトリ内の.audファイルのみが削除されます(このディレクトリは、AUDIT_FILE_DEST初期化パラメータで指定します)。

DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILを使用した監査証跡の手動パージ

準備手順の完了後、DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILプロシージャを使用して、監査証跡を手動で削除できます。

1. 監査証跡の自動削除ジョブのスケジューリングで説明した次の手順を実行します。

- 手順1: オンラインREDOログとアーカイブREDOログのサイズのチューニング(必要に応じて)

- 手順2: タイムスタンプおよびアーカイブ方針の計画

- 手順3: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)

2. マルチテナント環境を使用している場合は、削除ジョブを作成したデータベースに接続します。

削除ジョブをルートに作成した場合は、ルートにログインする必要があります。削除ジョブを特定のPDBに作成した場合は、そのPDBにログインします。

例:

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

3. DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャを実行して、監査証跡レコードを削除します。

例:

BEGIN
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
AUDIT_TRAIL_TYPE           =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
USE_LAST_ARCH_TIMESTAMP    =>  TRUE,
CONTAINER                  =>  DBMS_AUDIT_MGMT.CONTAINER_CURRENT );
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_TYPE: 監査証跡タイプを指定します。DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIEDは、これを統合監査証跡に設定します。
前のリリースの監査データがまだ存在するアップグレード済のデータベースの場合:

- 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: 最終アーカイブ・タイムスタンプより前に作成された監査レコードを削除します。アーカイブ・タイムスタンプを設定する方法は、手順3: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)を参照してください。デフォルト(推奨)値はTRUEです。USE_LAST_ARCH_TIMESTAMPはTRUEに設定することをお薦めします。

- FALSE: 最終アーカイブ・タイムスタンプを考慮せずに、すべての監査レコードを削除します。削除されているはずの監査レコードを誤って削除しないように、この設定を使用する際には注意が必要です。

- CONTAINER: マルチテナント環境にクレンジングを適用します。DBMS_AUDIT_MGMT.CONTAINER_CURRENTは、ローカルのPDBを指定し、DBMS_AUDIT_MGMT.CONTAINER_ALLは、すべてのデータベースに適用されます。

他の監査証跡削除操作

その他の監査証跡パージとして、監査証跡パージ・ジョブの有効化または無効化、監査証跡パージ・ジョブのデフォルト間隔の設定、監査証跡パージ・ジョブの削除、アーカイブ・タイムスタンプ設定の消去などがあります。

内容は次のとおりです。

- 監査証跡の削除ジョブを使用可能または使用禁止にする方法

- 指定した削除ジョブに対するデフォルトの監査証跡削除ジョブの間隔の設定

- 監査証跡の削除ジョブの削除

- アーカイブ・タイムスタンプ設定の消去

監査証跡の削除ジョブを使用可能または使用禁止にする方法

DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUSプロシージャで、監査証跡削除ジョブを有効または無効にします。

マルチテナント環境では、DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUSプロシージャの実行場所は、削除ジョブの場所(DBMS_MGMT.CREATE_PURGE_JOBプロシージャのCONTAINERパラメータによって決定)によって異なります。CONTAINERをCONTAINER_ALLに設定した場合(削除ジョブをルートに作成する場合)は、DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUSプロシージャをルートから実行する必要があります。CONTAINERをCONTAINER_CURRENTに設定した場合は、DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUSプロシージャが作成されたPDBから、このプロシージャを実行する必要があります。

- 監査証跡パージ・ジョブを有効または無効にするには、DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUSPL/SQLプロシージャを使用します。
たとえば、削除ジョブをhrpdb PDBに作成したとします。

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

BEGIN
DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUS(
AUDIT_TRAIL_PURGE_NAME      => 'Audit_Trail_PJ',
AUDIT_TRAIL_STATUS_VALUE    => DBMS_AUDIT_MGMT.PURGE_JOB_ENABLE);
END;
/

この例の説明は、次のとおりです。

- AUDIT_TRAIL_PURGE_NAMEは、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プロシージャで使用される間隔設定が、この設定よりも優先されます。

- 特定のパージ・ジョブの監査証跡パージ・ジョブのデフォルト間隔を設定するには、DBMS_AUDIT_MGMT.SET_PURGE_JOB_INTERVALプロシージャを実行します。
たとえば、削除ジョブをhrpdb PDBに作成したとします。

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

BEGIN
DBMS_AUDIT_MGMT.SET_PURGE_JOB_INTERVAL(
AUDIT_TRAIL_PURGE_NAME       => '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.SET_PURGE_JOB_INTERVALプロシージャの実行場所は、削除ジョブの場所(DBMS_MGMT.CREATE_PURGE_JOBプロシージャのCONTAINERパラメータによって決定)によって異なります。CONTAINERをCONTAINER_ALLに設定した場合、削除ジョブはルートに存在するため、DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUSプロシージャをルートから実行する必要があります。CONTAINERをCONTAINER_CURRENTに設定した場合は、DBMS_AUDIT_MGMT.SET_PURGE_JOB_INTERVALプロシージャが作成されたPDBから、このプロシージャを実行する必要があります。

監査証跡の削除ジョブの削除

既存の監査証跡パージ・ジョブを削除できます。

既存の削除ジョブを調べるには、DBA_AUDIT_MGMT_CLEANUP_JOBSデータ・ディクショナリ・ビューのJOB_NAMEおよびJOB_STATUS列を問い合せます。

- 監査証跡パージ・ジョブを削除するには、DBMS_AUDIT_MGMT.DROP_PURGE_JOB PL/SQLプロシージャを使用します。

たとえば、削除ジョブをhrpdb PDBに作成したとします。

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

BEGIN
DBMS_AUDIT_MGMT.DROP_PURGE_JOB(
AUDIT_TRAIL_PURGE_NAME  => 'Audit_Trail_PJ');
END;
/

マルチテナント環境では、DBMS_AUDIT_MGMT.DROP_PURGE_JOBプロシージャの実行場所は、削除ジョブの場所(DBMS_MGMT.CREATE_PURGE_JOBプロシージャのCONTAINERパラメータによって決定)によって異なります。CONTAINERをCONTAINER_ALLに設定した場合、削除ジョブはルートに存在するため、DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUSプロシージャをルートから実行する必要があります。CONTAINERをCONTAINER_CURRENTに設定した場合は、DBMS_AUDIT_MGMT.DROP_PURGE_JOB_INTERVALプロシージャが作成されたPDBから、このプロシージャを実行する必要があります。

アーカイブ・タイムスタンプ設定の消去

DBMS_AUDIT_MGMT.CLEAR_LAST_ARCHIVE_TIMESTAMPプロシージャで、アーカイブ・タイムスタンプの設定をクリアできます。

監査証跡ログのクリーン・アップの履歴を検索するには、OBJECT_NAMEがDBMS_AUDIT_MGMT、OBJECT_SCHEMAがSYSで、SQL_TEXTがLIKE %DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL%に設定されていることを条件として使用し、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。

- アーカイブ・タイムスタンプ設定を消去するには、DBMS_AUDIT_MGMT.CLEAR_LAST_ARCHIVE_TIMESTAMP PL/SQLプロシージャを使用して、監査証跡タイプと、マルチテナント環境の場合はコンテナ・タイプを指定します。
たとえば、削除ジョブをhrpdb PDBに作成したとします。

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

BEGIN
DBMS_AUDIT_MGMT.CLEAR_LAST_ARCHIVE_TIMESTAMP(
AUDIT_TRAIL_TYPE     =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
CONTAINER            =>  DBMS_AUDIT_MGMT.CONTAINER_CURRENT);
END;
/

この例の説明は、次のとおりです。

- 統合監査証跡の場合は、AUDIT_TRAIL_TYPEが設定されます。AUDIT_TRAIL_TYPEプロパティをDBMS_AUDIT_MGMT.AUDIT_TRAIL_OSまたはDBMS_AUDIT_MGMT.AUDIT_TRAIL_XMLに設定している場合、RAC_INSTANCE_NUMBERを0に設定することはできません。AUDIT_TRAIL_TYPEをDBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIEDに設定した場合は、RAC_INSTANCE_NUMBER設定を省略できます。

- CONTAINERは、タイムスタンプをマルチテナント環境に適用します。DBMS_AUDIT_MGMT.CONTAINER_CURRENTは、ローカルのPDBを指定し、DBMS_AUDIT_MGMT.CONTAINER_ALLは、すべてのデータベースに適用されます。

例: 統合監査証跡の削除操作の直接コール

カスタマイズされたアーカイブ・プロシージャを作成して、統合監査証跡の削除操作を直接コールできます。

例23-1の疑似コードはデータベース監査証跡削除操作を作成し、この操作は、ユーザーが統合監査証跡に対してDBMS_ADUIT.CLEAN_AUDIT_TRAILプロシージャを起動することでコールします。

この削除操作では、ループを使用することで、前回アーカイブされたタイムスタンプより前に作成されたレコードを削除します。ループは監査レコードをアーカイブし、どの監査レコードがアーカイブされたかを計算してSetCleanUpAuditTrailコールを使用して最終アーカイブ・タイムスタンプを設定し、それからCLEAN_AUDIT_TRAILプロシージャをコールします。この例では、重要な手順は太字で示しています。

例23-1 データベース監査証跡の削除操作の直接コール

-- 1. 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_UNIFIED,
LAST_ARCHIVE_TIME         => '23-AUG-2013 12:00:00',
CONTAINER                 => DBMS_AUDIT_MGMT.CONTAINER_CURRENT);
END;
/
-- 2. 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 DoUnifiedAuditRecordArchival();

CALL SetCleanUpAuditTrail();
IF(/* Clean up is needed immediately */)
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
AUDIT_TRAIL_TYPE        => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
USE_LAST_ARCH_TIMESTAMP => TRUE,
CONTAINER               => DBMS_AUDIT_MGMT.CONTAINER_CURRENT );
END IF
END LOOP /*LOOP*/
END; /* PROCEDURE */
/

他の監査証跡のタイプでこの例を変更する場合は、追加の手順が必要になる場合があります。詳細は、『Oracle Databaseセキュリティ・ガイド』のOracle Database 11gリリース2 (11.2)版(次のドキュメント・ライブラリから入手可能)を参照してください。

http://www.oracle.com/pls/db112/homepage

監査証跡管理のデータ・ディクショナリ・ビュー

Oracle Databaseには、監査証跡の管理設定に関する情報を表示するデータ・ディクショナリ・ビューが用意されています。

表23-1に、これらのビューを示します。

表23-1 監査証跡の管理設定に関する情報を表示するビュー

ビュー

説明

DBA_AUDIT_MGMT_CLEAN_EVENTS

従来(統合以外)の監査証跡の削除イベントの履歴が表示されます。定期的に、AUDIT_ADMINロールが付与されているユーザーで接続し、このビューが大きくなりすぎないように、内容を削除する必要があります。例:

DELETE FROM DBA_AUDIT_MGMT_CLEAN_EVENTS;

このビューは、読取り/書込みデータベースにのみ適用されます。読取り専用データベースの場合、削除イベントの履歴はアラート・ログにあります。

統合監査の場合、削除されたイベントの履歴を検索するには、OBJECT_NAMEがDBMS_AUDIT_MGMT、OBJECT_SCHEMAがSYSで、SQL_TEXTがLIKE %DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL%に設定されていることを条件として使用し、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。

DBA_AUDIT_MGMT_CLEANUP_JOBS

現在構成されている監査証跡の削除ジョブが表示されます。

DBA_AUDIT_MGMT_CONFIG_PARAMS

現在構成されている監査証跡プロパティが表示されます。これらのプロパティは、DBMS_AUDIT_MGMT PL/SQLパッケージで使用されます。

DBA_AUDIT_MGMT_LAST_ARCH_TS

監査証跡の削除用に設定された最後のアーカイブ・タイムスタンプが表示されます。

関連項目:
これらのビューの詳細は、Oracle Databaseリファレンスを参照してください。

付録

第VII部は、リファレンス用の一連の付録で構成されています。

- Oracle Databaseの安全性の維持

- データ暗号化および整合性パラメータ

- Kerberos、SSLおよびRADIUS認証パラメータ

- RADIUSを使用した認証デバイスの統合

- Oracle Database FIPS 140-2の設定

- orapkiユーティリティを使用したPKI要素の管理

- 統合監査の移行による各監査機能への影響

A Oracle Databaseの安全性の維持

Oracleには、ユーザー・アカウント、権限、ロール、パスワード、データなどの保護に関するアドバイスを含む、データベースの安全性を維持できる一連のガイドラインがあります。

内容は次のとおりです。

- 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に連絡してください。

内容は次のとおりです。

- セキュリティ・パッチと回避ソリューションのダウンロード

- Oracle Databaseの脆弱性に関するOracleのセキュリティ窓口への連絡

セキュリティ・パッチと回避ソリューションのダウンロード

セキュリティ・パッチは、Oracle Databaseを稼働しているオペレーティング・システムとOracle Database自体、およびインストール済のOracle Databaseのオプションとコンポーネントすべてに適用されます。

- セキュリティ・パッチおよび回避ソリューションをダウンロードする手順は、次のとおりです。

- セキュリティ・パッチについては、Oracle Technology Networkのセキュリティ・サイトで、Oracleによってリリースされたセキュリティ・アラートに関する詳細を定期的に確認してください: http://www.oracle.com/technetwork/topics/security/alerts-086861.html

- Oracleワールドワイド・サポート・サービスのサイト、My Oracle Supportで、セキュリティに関するパッチの入手可能性や予定などを確認してください:
https://support.oracle.com

Oracle Databaseの脆弱性に関するOracleのセキュリティ窓口への連絡

Oracle Databaseの脆弱性に関してOracleのセキュリティ窓口に連絡できます。

- Oracleのセキュリティ窓口への連絡には、次のいずれかの方法を使用します。

- OracleユーザーまたはOracleパートナであるユーザーがOracle製品の潜在的なセキュリティ上の脆弱性を発見した場合は、My Oracle Supportを使用してサービス・リクエストを発行してください。

- 製品のバージョンやプラットフォームも含めた問題の詳細を、スクリプトと例を添えて、電子メールでsecalert_us@oracle.comに送信してください。オラクル社にお問合せの際は、弊社の暗号鍵を使用して、電子メールを暗号化することをお薦めします。

ユーザー・アカウントと権限の保護に関するガイドライン

Oracleには、ユーザー・アカウントと権限を保護するガイドラインがあります。

1. 「最低限の権限」原則を実践する。
次のガイドラインに従うことをお薦めします。

a. 必要な権限のみを付与する。
データベース・ユーザーまたはロールに、必要以上の権限を付与しないでください。(可能な場合、ユーザーではなくロールに権限を付与してください。)つまり、最小権限の原則とは、ユーザーに、効率的かつ簡潔に作業を行うために実際に必要な権限のみを与えることです。

この原則を実装するには、次の項目について可能なかぎり制限します。

- データベース・ユーザーに付与するSYSTEMおよびOBJECT 権限の数。

- SYS権限によってデータベースに接続できるユーザーの数。

- DROP ANY TABLE権限などのANY権限を付与する対象のユーザー数。たとえば、通常、DBA権限のないユーザーにCREATE ANY TABLE権限を付与する必要はありません。

- データベース・オブジェクトを(TRUNCATE TABLE、DELETE TABLE、DROP TABLE文などで)作成、変更または削除を実行できるユーザーの数。

b. CREATE ANY EDITIONおよびDROP ANY EDITION権限の付与を制限する。
オブジェクトの追加バージョンを維持するために、エディションではデータベース内のリソースおよびディスク領域の使用量を増やすことができます。CREATE ANY EDITIONおよびDROP ANY EDITION権限は、アップグレードの実行を担当する信頼できるユーザーにのみ付与します。

c. ユーザーに付与したSELECTオブジェクト権限およびSELECT ANY TABLEシステム権限を再評価する。
ユーザーが表、ビュー、マテリアライズド・ビューおよびシノニムの問合せのみを行えるように制限する場合、READオブジェクト権限を付与し、信頼できるユーザーにのみREAD ANY TABLEシステム権限を付与します。問合せ操作の実行以外に、ユーザーが排他モードでの表のロックまたはSELECT ... FOR UPDATE文を実行できるようにする場合、ユーザーにSELECTオブジェクト権限を付与し、信頼できるユーザーにのみSELECT ANY TABLEシステム権限を付与します。

d. CREATE ANY JOB、BECOME USER、EXP_FULL_DATABASEおよびIMP_FULL_DATABASE権限を制限する。CREATE DIRECTORYおよびCREATE ANY DIRECTORY権限の付与も制限してください。
これらは強力なセキュリティ関連権限です。これらの権限は、必要とするユーザーにのみ付与してください。

e. ライブラリ関連の権限を信頼できるユーザーのみに制限する。
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ロールに対して付与しないでください。

f. 制限シノニム関連の権限を信頼できるユーザーのみに制限する。
CREATE PUBLIC SYNONYMおよびDROP PUBLIC SYNONYMシステム権限によって、これらのユーザーに大きい力が与えられます。信頼できないかぎり、これらの権限をユーザーに付与しないでください。

g. SYSスキーマが所有するオブジェクトに、管理者以外のユーザーがアクセスできないようにする。
ユーザーが表の行やSYSスキーマのスキーマ・オブジェクトを変更できないようにしてください。変更されると、データ整合性が損われる危険があります。DROP TABLE、TRUNCATE TABLE、DELETE、INSERTなどの文、または類似したオブジェクト変更文のSYSオブジェクトに対する使用を、強い権限を持つ管理ユーザーのみに制限してください。

SYSスキーマはデータ・ディクショナリを所有します。データ・ディクショナリは、O7_DICTIONARY_ACCESSIBILITYパラメータをFALSEに設定することで保護できます。詳細は、データの保護に関するガイドラインを参照してください。

h. DBMS_RANDOM PL/SQLパッケージに対するEXECUTE権限を、信頼できるユーザーにのみ付与する。
DBMS_RANDOMパッケージのEXECUTE権限は、通常は最低限のアクセス権しか持たないユーザーが、このパッケージに関連付けられたファンクションを実行するのを許可できます。

i. ランタイム機能の権限を制限する。
多くの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. 次のビューまたはロールからアクセス権を取り消す。

- SYSとDBAアカウント以外のすべてのユーザーからSYS.USER_HISTORY$表を取り消します。

- 通常のアプリケーション・アカウントからRESOURCEロールを取り消します。

- 通常のアプリケーション・アカウントからCONNECTロールを取り消します。

- DBAロールが不要なユーザーから、このロールを取り消します。

5. ロールに対してのみ権限を付与する。
個々のユーザーではなくロールに権限を付与すると、権限の管理および追跡が容易になります。

6. プロキシ・アカウント(プロキシ認可の場合)の権限をCREATE SESSIONのみに制限する。

7. セキュア・アプリケーション・ロールを使用して、アプリケーション・コードによって有効化するロールを保護する。
セキュア・アプリケーション・ロールでは、ユーザーがアプリケーションにログインできるかどうかを判断する一連の条件を、PL/SQLパッケージ内で定義できます。ユーザーはセキュア・アプリケーション・ロールではパスワードを使用する必要がありません。

ロールがアプリケーション内で使用可能または使用禁止になるのを防ぐ別の方法は、ロールのパスワードを使用することです。この方法では、ユーザーが、データベースにSQL(アプリケーションではなく)で直接アクセスして、ロールに関連付けられている権限を使用することを防ぎます。ただし、別の一連のパスワードを管理する必要がないように、セキュア・アプリケーション・ロールの使用をお薦めします。

8. ユーザーが、SQL文でNOLOGGING句を使用できないようにする。
いくつかのSQL文で、ユーザーはオプションとしてNOLOGGING句を指定できます。このオプションを指定すると、データベース操作がオンラインREDOログ・ファイルに記録されません。ユーザーがこの句を指定しても、REDOレコードがオンラインREDOログ・ファイルに書き込まれます。しかし、このレコードに関連付けられたデータはありません。このため、NOLOGGINGを使用すると、不正コードが入力されて、監査証跡に記録されずに実行される可能性があります。

9. 権限キャプチャを作成して、過度に付与されている権限を検索する。詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

10. 次の権限が、それらを必要としているユーザーとロールのみに付与されていることを監視する。
デフォルトでは、次の権限が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キーワード付きの権限

ロールの保護に関するガイドライン

Oracleには、ロール管理のガイドラインがあります。

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エンタープライズ・ユーザー・セキュリティ管理者ガイド

パスワードの保護に関するガイドライン

Oracleには、パスワードを保護するガイドラインがあります。

ユーザー・アカウントを作成すると、そのユーザーに対してデフォルトのパスワード・ポリシーが割り当てられます。このパスワード・ポリシーには、パスワードの作成方法(最小文字数や期限切れの時期など)についてのルールが定義されています。パスワードは、パスワード・ポリシーを使用することで強化できます。パスワードを保護するための別の方法については、「パスワード保護の構成」も参照してください。

パスワードをさらに強化するには、次のガイドラインに従います。

1. パスワードを慎重に選択する。

パスワードの最低要件については、「パスワードの最低要件」を参照してください。パスワードを作成または変更する際には、次の追加のガイドラインに従います。

- パスワードは12から30文字の英数字にします。

- パスワードには、数値、大文字および小文字を少なくとも1文字ずつ含めます。

- パスワードには、大/小文字と特殊文字を混在させて使用します。(「パスワードのセキュリティへの脅威からの12Cパスワード・バージョンによる保護」を参照してください。)

- パスワードには、マルチバイト・キャラクタを含めることができます。

- パスワードの文字にはデータベース・キャラクタ・セットを使用します。このセットには、アンダースコア(_)、ドル記号($)および番号記号(#)の各文字があります。

- 次のパスワードは二重引用符で囲む必要があります。

- マルチバイト・キャラクタを含むパスワード。

- 数値または特殊文字で始まり、アルファベットを含むパスワード。例:
"123abc"

"#abc"

"123dc$"

- アルファベット、数値および特殊文字以外の文字を含むパスワード。例:
"abc>"

"abc@"

" "

- 次のパスワードは二重引用符で囲む必要はありません。

- アルファベット(aからz、AからZ)で始まり、数字(0から9)または特殊文字($、#、_)を含むパスワード。次に例を示します。
abc123

ab23a

ab$#_

- 数値のみを含むパスワード。

- アルファベットのみを含むパスワード。

- パスワードには二重引用符を使用しないでください。

- 意味のある単語のみで構成されるパスワードを使用しないでください。

2. より長く複雑で覚えやすいパスワードを作成するには、次のテクニックを使用します。

- 覚えやすいセンテンスの各語の1文字目からパスワードを作成します。たとえば、"I usually work until 6:00 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では、デフォルトのアカウントはロックされ、パスワードは期限切れの状態でインストールされますが、以前のリリースからのアップグレードの場合は、デフォルトのパスワードを使用しているアカウントが存在している場合があります。

デフォルトのパスワードが設定されているユーザー・アカウントを検索するには、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厳密認証を、ネットワーク認証サービス(Kerberosなど)、トークン・カード、スマートカードまたはX.509証明書と一緒に使用することもお薦めします。これらのサービスを使用すると、ユーザーの厳密な認証が可能になるため、Oracle Databaseを不正なアクセスから保護できます。

8. Oracle表にはユーザー・パスワードをクリアテキストで格納しない。
セキュリティを強化するために、Oracle表には、ユーザー・パスワードをクリアテキスト(判読可能なテキスト)で格納しないでください。この問題は、安全性の高い外部パスワード・ストアを使用してパスワードが記載されている表の列を暗号化することで解決できます。詳細は、「パスワード資格証明用の安全性の高い外部パスワード・ストアの管理」を参照してください。

ユーザー・アカウントのパスワードを作成または変更すると、Oracle Databaseでは、そのパスワードの暗号化ハッシュまたはダイジェストが自動的に作成されます。DBA_USERSビューを問い合せてユーザー・アカウントの情報を検索する場合、PASSWORD列のデータはユーザー・パスワードがグローバル、外部またはNULLのいずれかであるかを示します。

データの保護に関するガイドライン

Oracleには、システムでデータを保護するためのガイドラインがあります。

1. データ・ディクショナリの保護を有効にする。
ANYシステム権限を持つユーザーがデータ・ディクショナリに対してそれぞれの権限を使用しないように、データ・ディクショナリを保護することをお薦めします。データ・ディクショナリ表のデータを変更または操作すると、データベースの操作に永続的に有害な影響を与える可能性があります。

データ・ディクショナリ保護を有効にするには、initsid.ora制御ファイルで、次の初期化パラメータをFALSE(デフォルト)に設定します。

O7_DICTIONARY_ACCESSIBILITY = FALSE

O7_DICTIONARY_ACCESSIBILITYパラメータは、サーバー・パラメータ・ファイルに設定できます。サーバー・パラメータ・ファイルの詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

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文では付与できませんが、ロールを介して付与できます。ロールの詳細は、「権限とロール認可の構成」を参照してください。

2. オペレーティング・システムのアクセスを制限する。
次のガイドラインに従ってください。

- オペレーティング・システムのユーザー数を制限します。

- Oracle Databaseが稼働しているホスト・コンピュータ上のオペレーティング・システム・アカウントの権限(管理、ルート権限またはデータベース管理)を、ユーザーによる業務の遂行に必要な最小限の権限に制限してください。

- 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管理者ガイド』を参照してください。複数のソフトウェア所有者に必要な様々な権限の詳細は、『Oracle Automatic Storage Management管理者ガイド』も参照してください。

ORACLE_LOADERアクセス・ドライバの保護に関するガイドライン

Oracleには、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には、データベースのインストールと構成を保護するガイドラインがあります。

安全性を高めるために、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)の使用方法の詳細は、Kerberos認証の構成を参照してください。

ネットワーク接続のセキュリティ

不適切なアクセスまたは変更からネットワークとその通信を保護することは、ネットワーク・セキュリティの最重要点です。

データが移動するすべてのパスを検討し、各パスおよびノードに対する脅威を評価してください。次に、脅威およびセキュリティが侵害された場合の結果を抑制または排除する手順を実行します。また、監視および監査を実施し、脅威レベルの増加または侵入試行を検出します。

ネットワーク接続の管理には、Oracle Net Managerを使用できます。Net Managerの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

次の手続きでネットワーク・セキュリティを改善します。

1. リスナーの管理にSecure Sockets Layer(SSL)を使用する。
詳細は、Secure Sockets Layer接続のセキュリティを参照してください。

2. リスナーのパスワードおよびサーバー上のlistener.oraファイルへの書込み権限は、管理者が保持するように規定することで、オンライン管理を回避する。

a. この行をlistener.oraファイルに追加するか、またはこの行を変更してください。

ADMIN_RESTRICTIONS_LISTENER=ON

b. RELOADを使用して構成を再ロードします。

c. 次のように、アドレス・リストで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リファレンスを参照してください。

3. リスナーのパスワードを設定しない。
listener.oraファイルにパスワードが設定されていないことを確認します。ローカルのオペレーティング・システム認証によって、リスナー管理が保護されます。パスワードが設定されていない場合、リモートのリスナー管理は使用禁止になります。このため、リスナーのパスワードの総当り攻撃が防止されます。

リスナーのパスワードは、このリリースでは非推奨となりました。次回のOracle Databaseリリースではサポートされなくなります。

4. ホスト・コンピュータに、複数のNetwork Interface Controller(NIC)カードに関連付けられている複数のIPアドレスがある場合は、特定のIPアドレスに対してリスナーを構成する。
これによって、リスナーはすべてのIPアドレスをリスニングできます。また、リスナーが特定のIPアドレスをリスニングするように制限できます。このタイプのコンピュータでは、リスナーですべてのIPアドレスをリスニングするのではなく、特定のIPアドレスを指定することをお薦めします。リスナーを特定のIPアドレスに限定することで、侵入者が、リスナー・プロセスからTCPエンド・ポイントを盗むのを防止できます。

5. リスナーの権限を制限して、データベースまたはOracleサーバーのアドレス空間にあるファイルを読取り/書込みできないようにする。
この制限によって、リスナー(またはエージェントが実行するプロシージャ)によって起動された外部プロシージャ・エージェントは、読取りまたは書込み操作の実行機能を継承しないようになります。この個別のリスナー・プロセスの所有者には、Oracle Databaseをインストールした所有者またはOracle Databaseインスタンスを実行する所有者(デフォルトの所有者であるORACLEなど)を指定しないでください。

リスナーにおける外部プロシージャの構成の詳細は、Oracle Database Net Services管理者ガイドを参照してください。

6. 暗号化を使用して、転送中のデータを保護する。
ネットワーク・データの暗号化の詳細は、Oracle Database 2日でセキュリティ・ガイドおよび厳密認証の概要を参照してください。

7. ファイアウォールを利用する。
ファイアウォールを適切に配置および構成することで、データベースへの外部からのアクセスを防止できます。

- データベース・サーバーはファイアウォールの内側に配置してください。Oracle Databaseのネットワーク・インフラストラクチャであるOracle Net Services (旧称SQL*Net)は、様々なベンダーの各種ファイアウォールに対するサポートを提供しています。プロキシ対応のファイアウォールでは、Network Associates社のGauntletとAxent社のRaptorをサポートしています。パケット・フィルタ型のファイアウォールではCisco社のPIX Firewall、ステートフル・インスペクション型のファイアウォール(より高機能のパケット・フィルタ型ファイアウォール)ではCheckPoint社のFirewall-1をサポートしています。

- ファイアウォールは、保護するネットワークの外側に配置されている必要があります。

- 安全性が確認されているプロトコル、アプリケーションまたはクライアント/サーバーのソースのみを受け入れるようにファイアウォールを構成します。

- Net8やOracle Connection Managerなどの製品を使用して、データベースへの単一のネットワーク接続を介した複数のクライアント・ネットワーク・セッションの多重化を管理します。これにより送信元、送信先およびホスト名でフィルタ処理できます。この製品を使用すると、物理的に保護された端末または既知のIPアドレスを備えたアプリケーションWebサーバーからの接続のみを受け入れるようにできます。(IPアドレスは偽造可能なため、IPアドレスのみでフィルタ処理した認証では不十分です。)

8. Oracleリスナーの不正な管理を防止する。
リスナーの詳細は、Oracle Database Net Services管理者ガイドを参照してください。

9. ネットワーク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管理者ガイドを参照してください。

10. ネットワーク・トラフィックを暗号化する。
可能な場合は、Oracleネットワーク・データ暗号化を使用して、クライアント、データベースおよびアプリケーション・サーバー間のネットワーク・トラフィックを暗号化します。ネットワーク暗号化の概要は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。ネットワーク暗号化の詳細は、「Oracle Databaseのネットワーク暗号化およびデータ整合性の構成」を参照してください。

11. ホスト・オペレーティング・システム(Oracle Databaseがインストールされているシステム)を保護する。
オペレーティング・システムの不要なサービスをすべて使用禁止にして、ホスト・オペレーティング・システムを保護します。UNIXおよびWindowsには様々なオペレーティング・システム・サービスが組み込まれていますが、それらの大部分は、一般的なデプロイメントには不要です。これらのサービスには、FTP、TFTP、TELNETなどがあります。使用を禁止している各サービスのUDPポートとTCPポートは、両方とも必ず閉じてください。一方のポートを使用禁止にしていても、他方のポートが使用可能であると、オペレーティング・システムの安全性が低下します。

Secure Sockets Layer接続のセキュリティ

Oracleには、Secure Sockets Layer (SSL)を保護するためのガイドラインがあります。

Secure Sockets Layer(SSL)は保護された通信のためのインターネット標準プロトコルで、データの整合性と暗号化のメカニズムを提供します。これらのメカニズムは、証明書(および必要な場合は暗号化)を使用して、安全性の高い認証、認可およびメッセージ機能をサポートし、ユーザーあるいはアプリケーションおよびサーバーが送受信するメッセージを保護できます。適切なセキュリティの実施により、保護が最大限に発揮され、セキュリティを脅かすギャップや露見が最小限に抑えられます。

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の一般的な情報は、Secure Sockets Layer認証の構成を参照してください

- sqlnet.oraのTCP関連パラメータの詳細は、Oracle Database Net Servicesリファレンスを参照してください。

外部プロシージャの保護に関するガイドライン

ENFORCE_CREDENTIAL環境変数では、extprocプロセスがどのようにユーザー資格証明およびコールアウト関数を認証するかを制御します。

この変数はextproc.oraファイルに指定できます。この変数を変更する前に、外部ライブラリの処理用にサイトのセキュリティ要件を確認します。セキュリティを最大にするために、ENFORCE_CREDENTIAL変数をTRUEに設定します。デフォルト設定はFALSEです。

関連項目:

外部プロシージャの保護

監査に関するガイドライン

Oracleには、監査用のガイドラインがあります。

監査情報の管理の容易性

監査は比較的低コストですが、監査するイベントの数はできるだけ制限してください。

この制限によって、監査対象の文を実行したときのパフォーマンスへの影響が最小限に抑えられ、監査証跡のサイズが最小限になるため、分析と理解が容易になります。

監査方針を企画する際は、次のガイドラインに従ってください。

1. 監査の目的を評価する。
監査の目的を明確にしておくと、適切な監査方針を企画でき、不要な監査を回避できます。

たとえば、不審なデータベース・アクティビティの調査のために監査すると仮定します。この情報のみでは不明確です。どのデータベース・アクティビティが疑わしい、または注意を要するといった具体的な情報が必要です。そのために、たとえば、データベース内の表から無許可にデータが削除されていないかを監査するというように、監査方針を絞り込みます。このような目的を設定すれば、監査の対象となるアクションの種類や、疑わしいアクティビティによって影響を受けるオブジェクトの種類を限定できます。

2. 監査について十分理解する。
目標とする情報の取得に必要な最小限の文、ユーザーまたはオブジェクトを監査します。これによって、不要な監査情報のために重要な情報の識別が困難になることや、SYSTEM表領域内の貴重な領域が無駄に使用されることがなくなります。収集が必要なセキュリティ情報の量と、その情報を格納して処理する能力とのバランスを保つ必要があります。

たとえば、データベース・アクティビティに関する情報を収集するために監査する場合は、追跡するアクティビティの種類を正確に判断した上で、必要な情報を収集するために必要な期間内で、目的のアクティビティのみを監査します。別の例として、各セッションの論理I/O情報のみを収集する場合は、オブジェクトを監査しないでください。

3. 監査方針を実施する前に法務部門と打ち合せる。
組織の法務部門に監査方針を検討するように依頼する必要があります。監査では組織の他のユーザーが監視されるため、サイトのコンプライアンス・ポリシーと会社の方針に適切に従っていることを確認する必要があります。

通常のデータベース・アクティビティの監査

Oracleには、特定のデータベース・アクティビティに関する履歴情報を収集する必要がある場合のガイドラインがあります。

1. 関連のあるアクションのみを監査する。
少なくとも、ユーザー・アクセス、システム権限の使用およびデータベース・スキーマ構造の変更を監査します。役に立たない監査レコードのために重要な情報が識別できない事態を避け、監査証跡管理の量を削減するために、目的のデータベース・アクティビティのみを監査してください。監査対象が多すぎるとデータベースのパフォーマンスに影響する可能性があることにも注意してください。

たとえば、データベースのすべての表に対する変更を監査すると、監査証跡レコードが多くなりすぎてデータベースのパフォーマンスが低下する可能性があります。ただし、Human Resources(人事管理)表内の給与のように、重要な表に対する変更を監査することは有益です。

ファイングレイン監査を使用することで、特定のアクションを監査できます。ファイングレイン監査については、ファイングレイン監査を使用した特定のアクティビティの監査を参照してください。

2. 監査レコードをアーカイブし、監査証跡を削除する。
必要な情報を収集した後は、目的の監査レコードをアーカイブし、この情報の監査証跡を削除します。次の各項を参照してください。

- 監査証跡のアーカイブ

- 監査証跡レコードの削除

3. 自社のプライバシに関する考慮事項を検討する。
プライバシに関する法規によって、追加のビジネス・プライバシ・ポリシーが必要となる場合があります。プライバシに関するほとんどの法規では、個人を特定できる情報(PII)へのアクセスをビジネスで監視する必要があり、このような監視は監査によって実施されます。ビジネス・レベルのプライバシ・ポリシーでは、技術的、法的および企業ポリシーの問題など、データ・アクセスおよびユーザー・アカウンタビリティに関するすべての事項を処理する必要があります。

4. その他の監査情報をOracle Databaseのログ・ファイルでチェックする。
Oracle Databaseによって生成されたログ・ファイルには、データベースの監査時に使用できる有益な情報が含まれています。たとえば、Oracle Databaseではアラート・ファイルが作成され、STARTUP操作、SHUTDOWN操作およびデータベースにデータ・ファイルを追加するなどの構造上の変更が記録されます。

たとえば、コミットまたはロールバックされたトランザクションを監査する場合は、REDOログ・ファイルを使用できます。

疑わしいデータベース・アクティビティの監査

Oracleには、不審なデータベース・アクティビティの監視を監査する場合のガイドラインがあります。

1. 最初に一般的な監査を行い、特定の対象を監査する。
疑わしいデータベース・アクティビティの監査を開始するとき、通常は対象のユーザーまたはスキーマ・オブジェクトの特定に使用できる情報がありません。したがって、まず、一般的な監査、つまり、統合監査ポリシーを使用した監査を行います。「監査ポリシーの構成」に、SQL文、スキーマ、オブジェクト、権限などを監査する方法が説明されています。

準備的な監査情報の記録と分析を終了した後は、監査ポリシーを変更して特定のアクションと権限を監査します。ポリシーに条件を追加して、不要な監査レコードを除外できます。AUDIT POLICY文でEXCEPT句を使用して、監査する必要のない特定のユーザーを除外することもできます。統合監査ポリシーの詳細は、統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査を参照してください。

ファイングレイン監査を使用した特定のアクティビティの監査で説明するように、ファイングレイン監査を使用して特定のアクションを監査できます。

この処理は、疑わしいデータベース・アクティビティの原因について結論が出せるだけの十分な裏付けが収集できるまで継続してください。

2. 一般的な疑わしいアクティビティを監査する。
一般的な疑わしいアクティビティは、次のとおりです。

- 通常以外の時間中にデータベースにアクセスするユーザー

- 複数回失敗したユーザー・ログイン試行

- 存在しないユーザーによるログイン試行

また、SQLテキストなど、SQL問合せで使用すると、クレジット・カード番号などの機密データが監査証跡の列に表示される可能性があることに注意してください。また、アカウントを共有しているユーザー、または同じIPアドレスからログインしている複数のユーザーを監視します。この種のアクティビティは、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることで検索できます。非常にきめ細かい方法では、ファイングレイン監査ポリシーを作成します。

3. AUD$およびFGA$監査証跡を保護する。
Oracle Database Vaultを有効にしていると、SYS.AUDIT$システム表、SYS.AUD$システム表、SYS.FGA$システム表、SYS.FGA_LOG$システム表、SYS.AUDIT_NG$システム表、SYS.AUD_POLICY$システム表、SYS.AUD_OBJECT_OPT$システム表、およびSYS.AUD_CONTEXT$システム表を、レルムに囲むことにより保護できます。詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

監査の推奨設定

Oracleには、ほとんどのサイトに適用される推奨の監査設定を含む事前定義ポリシーがあります。

例:

- ORA_SECURECONFIGは、Oracle Databaseリリース11gの同じデフォルト監査設定を監査します。これは、ALTER ANY TABLE、GRANT ANY PRIVILEGE、CREATE USERなどの複数の権限の使用を追跡します。追跡されるアクションには、ALTER USER、CREATE ROLE、LOGON、および一般に実行されるその他のアクティビティが含まれます。データベースがOracle Database 12cで生成された場合にかぎり、ポリシーはデフォルトで有効になります。

- ORA_DATABASE_PARAMETERは、一般的に使用されるOracle Databaseパラメータ設定のALTER DATABASE、ALTER SYSTEMおよびCREATE SPFILEを監査します。デフォルトでは、このポリシーは有効になっていません。

- ORA_ACCOUNT_MGMTは、一般的に使用されるユーザー・アカウントおよび権限の設定のCREATE USER、ALTER USER、DROP USER、CREATE ROLE、DROP ROLE、ALTER ROLE、SET ROLE、GRANTおよびREVOKEを監査します。デフォルトでは、このポリシーは有効になっていません。

関連項目:

これらの事前定義の監査ポリシーとその他の監査ポリシーの詳細は、事前定義の統合監査ポリシーを使用したアクティビティの監査を参照してください

CONNECTロール変更への対処

CONNECTロールはOracle Databaseリリース7で導入され、これにより、データベース・ロールに新しい堅牢なサポートが追加されました。

内容は次のとおりです。

- CONNECTロールが変更された理由

- CONNECTロール変更がアプリケーションに与える影響

- CONNECTロール変更がユーザーに与える影響

- CONNECTロール変更に対処する方法

CONNECTロールが変更された理由

CONNECTロールは、サンプル・コード、アプリケーション、ドキュメントおよび技術論文に使用されています。

Oracle Database 10gリリース2 (10.2)では、CONNECTロールは変更されました。Oracle Database 10.2より前のリリースから現行のリリースにアップグレードする場合は、最新のリリースでのCONNECTロールの変更に注意してください。

CONNECTロールは、当初、特殊な権限を伴って設定されていました。その権限とは、ALTER SESSION、CREATE CLUSTER、CREATE DATABASE LINK、CREATE SEQUENCE、CREATE SESSION、CREATE SYNONYM、CREATE TABLE、CREATE VIEWです。

Oracle Database 10g リリース2以降のCONNECTロールには、CREATE SESSION権限のみが含まれ、他の権限はすべて削除されています。Oracle Database 12cリリース1以降、CONNECTロールにCREATE SESSIONおよびSET CONTAINER権限が含まれました。

CONNECTロールは、Oracle Databaseでの新規アカウントのプロビジョニングで頻繁に使用されましたが、データベースへの接続に前述の権限がすべて必要なわけではありません。この変更によって、優れたセキュリティ手続きを簡単に規定できるようになります。

各ユーザーにはそれぞれのタスクに必要な権限のみを付与します。これが「最低限の権限」原則と呼ばれる考え方です。最低限の権限により権限を制限することでリスクが軽減されるため、必要なことはこれまでどおり簡単に実行できると同時に、不適切な行為を不注意に、あるいは意図的に実行される可能性が低くなります。

CONNECTロール変更がアプリケーションに与える影響

CONNECTロールへの変更は、データベース・アップグレード、アカウント・プロビジョニングおよび新しいデータベースを使用したアプリケーションのインストールに影響を与えています。

内容は次のとおりです。

- CONNECTロール変更がデータベース・アップグレードに与える影響

- CONNECTロール変更がアカウント・プロビジョニングに与える影響

- CONNECTロール変更が新規のデータベースを使用するアプリケーションに与える影響

CONNECTロール変更がデータベース・アップグレードに与える影響

CONNECTロールがデータベース・アップグレードに与える影響に注意してください。

既存のOracleデータベースをOracle Database 10gリリース2 (10.2)にアップグレードすると、CONNECTロールの権限はCREATE SESSION権限のみになるよう自動的に変更されます。

ほとんどのアプリケーションは、アプリケーション・オブジェクトがすでに存在するため、この影響を受けません。新たに表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成する必要はありません。

表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSIONコマンドを動的に使用するアプリケーションは、権限が不十分なために失敗する場合があります。

CONNECTロール変更がアカウント・プロビジョニングに与える影響

CONNECTロールがアカウント・プロビジョニングに与える影響に注意してください。

アプリケーションまたはDBAがアカウント・プロビジョニング・プロセスの一部としてCONNECTロールを付与する場合は、CREATE SESSION権限のみが含まれます。追加の権限は、直接または別のロールを介して付与する必要があります。

この問題は、カスタマイズされた新しいデータベース・ロールを作成することで対処できます。

関連項目:

CONNECTロール変更に対処する方法

CONNECTロール変更が新規のデータベースを使用するアプリケーションに与える影響

CONNECTロールが新規のデータベースを使用するアプリケーションに与える影響に注意してください。

Oracle Database 10g リリース2(10.2)のユーティリティ(DBCA)、またはDBCAから生成されたデータベース作成テンプレートを使用して作成された新しいデータベースでは、CREATE SESSION権限のみを伴ったCONNECTロールが定義されます。

新しいデータベースを使用するアプリケーションのインストールは、そのアプリケーションに使用されているデータベース・スキーマの権限がCONNECTロールのみを介して付与されている場合、失敗する可能性があります。

CONNECTロール変更がユーザーに与える影響

CONNECTロールへの変更による影響は、一般ユーザー、アプリケーション開発者およびクライアント/サーバー・アプリケーションの3つのクラスのユーザーではそれぞれ異なります。

内容は次のとおりです。

- CONNECTロール変更が一般ユーザーに与える影響

- CONNECTロール変更がアプリケーション開発者に与える影響

- CONNECTロール変更がクライアント・サーバー・アプリケーションに与える影響

CONNECTロール変更が一般ユーザーに与える影響

CONNECTロールが一般ユーザーに与える影響に注意してください。

新しいCONNECTロールは、CREATE SESSION権限のみを提供します。アプリケーションを使用するためにデータベースに接続するユーザーの場合、CONNECTロールにはまだCREATE SESSION権限があるため影響はありません。

ただし、CONNECTロールのみでプロビジョニングされた特定のユーザーの場合は、適切な権限がないことになります。表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSIONコマンドを使用するユーザーです。これらのユーザーに必要な権限は、CONNECT ロールでは提供されなくなりました。必要な追加権限を認可するには、データベース管理者が該当する権限用の追加ロールを作成および適用するか、その権限を必要としているユーザーに直接付与する必要があります。

ALTER SESSION権限は、イベントを設定するために必要です。ALTER SESSION権限が必要なデータベース・ユーザーはほとんどいません。

ALTER SESSION権限は、その他のALTER SESSIONコマンドには必要ありません。

CONNECTロール変更がアプリケーション開発者に与える影響

CONNECTロールがアプリケーション開発者に与える影響に注意してください。

CONNECTロールのみでプロビジョニングされたアプリケーション開発者には、表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSION文を使用するための適切な権限はありません。

該当する権限用の追加ロールを作成および適用するか、その権限を必要としているアプリケーション開発者に直接付与する必要があります。

CONNECTロール変更がクライアント・サーバー・アプリケーションに与える影響

CONNECTロールがクライアント・サーバー・アプリケーションに与える影響に注意してください。

専用のユーザー・アカウントを使用するほとんどのクライアント/サーバー・アプリケーションは、この変更の影響は受けません。

ただし、アカウント・プロビジョニングまたはランタイム操作時に、動的SQLを使用してユーザー・スキーマ内にプライベート・シノニムまたは一時表を作成するアプリケーションは影響を受けます。この場合は、その動作に適したシステム権限を取得するための追加ロールや権限付与が必要です。

CONNECTロール変更に対処する方法

CONNECTロールの変更の影響に対処するには、次の3つの方法をお薦めします。

内容は次のとおりです。

- 新しいデータベース・ロールの作成

- CONNECT権限のリストア

- CONNECT権限受領者を表示するデータ・ディクショナリ・ビュー

- 最低限の権限の分析調査

新しいデータベース・ロールの作成

CONNECTロールから削除された権限は、新しいデータベース・ロールを作成することで管理できます。

1. アップグレードされた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;

2. 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;

3. 権限分析ポリシーを作成することでユーザーが必要とする権限を決定します。

収集した情報を分析して、よりきめ細かい追加のデータベース・ロール作成に使用できます。特定のユーザーについて使用されていない権限は取り消すことができます。

次に例を示します。

BEGIN
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
name          => 'my_app_dev_role_pol',
description   => 'Captures my_app_developer role use',
type          => DBMS_PRIVILEGE_CAPTURE.G_ROLE,
roles         => role_name_list('my_app_developer');
END;
/
EXEC DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE ('my_app_dev_role_pol');

4. 一定期間後に、権限分析ポリシーを無効化して、レポートを生成します。

EXEC DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE ('my_app_dev_role_pol');

EXEC DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT ('my_app_dev_role_pol');

5. レポートを生成した後、権限分析データ・ディクショナリ・ビューを問い合せます。

次に例を示します。

SELECT USERNAME, SYS_PRIV, OBJECT_OWNER, OBJECT_NAME FROM DBA_USED_PRIVS;

関連項目:

権限分析の詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

CONNECT権限のリストア

Oracle Database 10gリリース2 (10.2)以降のOracleには、CONNECT権限をリストアするrstrconn.sqlと呼ばれるスクリプトが用意されています。

データベースのアップグレードまたは新しいデータベースの作成後は、このスクリプトを使用して、Oracle Database 10g リリース2(10.2)でCONNECTロールから削除された権限を付与できます。この方法を使用した場合、使用されていない権限は、必要としていないユーザーから取り消してください。

CONNECT権限をリストアする手順

1. $ORACLE_HOME/rdbms/adminディレクトリにあるrstrconn.sqlスクリプトを実行します。

@$ORACLE_HOME/rdbm_admin/rstrconn.sql

2. 使用される権限を監視します。

次に例を示します。

CREATE AUDIT POLICY connect_priv_pol
PRIVILEGES AUDIT CREATE TABLE, CREATE SEQUENCE, CREATE SYNONYM, CREATE DATABASE LINK, CREATE CLUSTER, CREATE VIEW, ALTER SESSION;

AUDIT POLICY connect_priv_pol BY psmith;

3. データベース権限の使用状況を定期的に監視します。

次に例を示します。

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権限受領者を表示するデータ・ディクショナリ・ビュー

DBA_CONNECT_ROLE_GRANTEESデータ・ディクショナリ・ビューを使用すると、古いCONNECTロールを継続して使用する管理者は、どのユーザーがそのロールを持っているかをすばやく確認できます。

表A-1に、DBA_CONNECT_ROLE_GRANTEESビューの列を示します。

表A-1 DBA_CONNECT_ROLE_GRANTEESの列と内容

列名

内容

Grantee

CONNECTロールを付与されたユーザー。

Path_of_connect_role_grant

ユーザーへのCONNECTの付与に使用されたロール(またはネストされたロール)。

Admin_opt

VARCHAR2(3)。ユーザーのCONNECTにADMINオプションがある場合はYES、ない場合はNO。

最低限の権限の分析調査

Oracleパートナおよびアプリケーション・プロバイダは、より安全性の高い製品をOracleの顧客ベースに供給できるように最低限の権限の分析を行う必要があります。「最低限の権限」原則は、所定の機能を実行するために必要な最低限のセットに権限を制限することでリスクを軽減します。

分析によって同一の権限セットが必要とされたユーザーのクラスごとに、その権限のみを持ったロールを作成します。他の権限はすべて該当するユーザーから取り消し、作成したロールを割り当てます。必要な権限が変化したときは、追加の権限を直接またはこれらの新しいロールを介して付与するか、新たに必要となった権限に応じた新しいロールを作成できます。この方法を使用すると、不適切な権限が制限され、不注意または意図的な被害が軽減されます。

データベース・ユーザーによる権限の使用状況を分析するポリシーを作成できます。ポリシーはこの情報を取得し、データ・ディクショナリ・ビューで使用できるようにします。これらのレポートに基づいて、だれにデータへのアクセス権限を持たせるかを決定できます。

関連項目:

権限分析の詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

B データ暗号化および整合性パラメータ

Oracleにはサンプルsqlnet.oraファイルが用意されており、ガイドラインとして使用できる設定が示されています。

このsqlnet.oraファイルは、「Oracle Databaseのネットワーク暗号化とデータ整合性の構成」および「Secure Sockets Layer認証の構成」で説明したネットワーク構成を実行することで生成されます。暗号化およびデータ整合性パラメータも用意されています。

内容は次のとおりです。

- サンプルsqlnet.oraファイル

- データ暗号化および整合性パラメータ

データ暗号化と整合性のためのsqlnet.oraの使用について

データ暗号化と整合性を構成するためのガイドラインとして、デフォルトのパラメータ設定を使用できます。

このsqlnet.oraファイルは、「Oracle Databaseのネットワーク暗号化とデータ整合性の構成」および「Secure Sockets Layer認証の構成」で説明したネットワーク構成を実行すると生成されます。暗号化およびデータ整合性パラメータも用意されています。

サンプルsqlnet.oraファイル

sqlnet.ora構成ファイルのサンプルは、似た特性を持つ一連のクライアントと似た特性を持つ一連のサーバーに基づいています。

このファイルには、Oracle Databaseの暗号化とデータ整合性のパラメータの例が含まれています。

デフォルトでは、sqlnet.oraファイルは、ORACLE_HOME/network/adminディレクトリ、またはTNS_ADMIN環境変数によって設定されている場所にあります。TNS_ADMIN変数が正しいsqlnet.oraファイルを指定するように適切に設定されていることを確認します。TNS_ADMIN変数の詳細および設定例は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

トレース・ファイルの設定

#Trace file setup
trace_level_server=16
trace_level_client=16
trace_directory_server=/orant/network/trace
trace_directory_client=/orant/network/trace
trace_file_client=cli
trace_file_server=srv
trace_unique_client=true

Oracle Databaseのネットワーク暗号化

sqlnet.encryption_server=accepted
sqlnet.encryption_client=requested
sqlnet.encryption_types_server=(RC4_40)
sqlnet.encryption_types_client=(RC4_40)

Oracle Databaseのネットワーク・データ整合性

#ASO Checksum
sqlnet.crypto_checksum_server=requested
sqlnet.crypto_checksum_client=requested
sqlnet.crypto_checksum_types_server = (SHA256)
sqlnet.crypto_checksum_types_client = (SHA256)

Secure Socket Layer

#SSL
WALLET_LOCATION = (SOURCE=
(METHOD = FILE)
(METHOD_DATA =
DIRECTORY=/wallet)

SSL_CIPHER_SUITES=(SSL_DH_anon_WITH_RC4_128_MD5)
SSL_VERSION= 3
SSL_CLIENT_AUTHENTICATION=FALSE

Common

#Common
automatic_ipc = off
sqlnet.authentication_services = (beq)
names.directory_path = (TNSNAMES)

Kerberos

#Kerberos
sqlnet.authentication_services = (beq, kerberos5)
sqlnet.authentication_kerberos5_service = oracle
sqlnet.kerberos5_conf= /krb5/krb.conf
sqlnet.kerberos5_keytab= /krb5/v5srvtab
sqlnet.kerberos5_realms= /krb5/krb.realm
sqlnet.kerberos5_cc_name = /krb5/krb5.cc
sqlnet.kerberos5_clockskew=900
sqlnet.kerberos5_conf_mit=false

RADIUS

#Radius
sqlnet.authentication_services = (beq, RADIUS )
sqlnet.radius_authentication_timeout = (10)
sqlnet.radius_authentication_retries = (2)
sqlnet.radius_authentication_port = (1645)
sqlnet.radius_send_accounting = OFF
sqlnet.radius_secret = /orant/network/admin/radius.key
sqlnet.radius_authentication = radius.us.example.com
sqlnet.radius_challenge_response = OFF
sqlnet.radius_challenge_keyword = challenge
sqlnet.radius_challenge_interface =
oracle/net/radius/DefaultRadiusInterface
sqlnet.radius_classpath = /jre1.1/

データ暗号化および整合性パラメータ

Oracleには、sqlnet.oraファイルで設定できるデータおよび整合性の一連のパラメータがあります。

内容は次のとおりです。

- データ暗号化および整合性パラメータについて

- SQLNET.ENCRYPTION_SERVER

- SQLNET.ENCRYPTION_CLIENT

- SQLNET.CRYPTO_CHECKSUM_SERVER

- SQLNET.CRYPTO_CHECKSUM_CLIENT

- SQLNET.ENCRYPTION_TYPES_SERVER

- SQLNET.ENCRYPTION_TYPES_CLIENT

- SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER

- SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT

データ暗号化および整合性パラメータについて

データ暗号化および整合性パラメータは、使用する暗号化アルゴリズムのタイプを制御します。

サーバー暗号化、クライアント暗号化、サーバー・チェックサムまたはクライアント・チェックサムの値を指定しない場合、対応する構成パラメータはsqlnet.oraファイルに含まれません。ただし、デフォルトはACCEPTEDです。

データ暗号化と整合性の両方のアルゴリズムでは、サーバーは、そのサーバーのsqlnet.oraファイル内のアルゴリズムのうち、クライアントのsqlnet.oraファイル、またはクライアントのsqlnet.oraファイルにアルゴリズムがリストされていない場合はクライアントのインストール済リストにリストされているアルゴリズムに、最初に一致するものを選択します。サーバーのsqlnet.oraファイルにエントリがない場合、サーバーはそのインストール済リストを順に検索して、クライアント側(クライアントのsqlnet.oraファイルまたはクライアントのインストール済リスト)の項目と照合します。一致するアルゴリズムが見つからず、接続の一方でアルゴリズムのタイプ(データ暗号化または整合性)がREQUIREDである場合、接続は失敗します。 それ以外の場合、接続はアルゴリズムのタイプinactiveで成功します。

データ暗号化と整合性のアルゴリズムは、互いに独立して選択されます。表B-1に示すように、暗号化は整合性なしでアクティブにでき、整合性は暗号化なしでアクティブにできます。

表B-1 アルゴリズムのタイプの選択

暗号化の選択

整合性の選択

選択

選択なし

選択

選択

選択なし

選択

選択なし

選択なし

関連項目:

- Oracle Databaseのネットワーク暗号化とデータ整合性の構成

- 暗号化および整合性のアクティブ化について

SQLNET.ENCRYPTION_SERVER

SQLNET.ENCRYPTION_SERVERパラメータでは、クライアントまたはクライアントとして機能しているサーバーがこのサーバーに接続する際の暗号化動作を指定します。

サーバーの動作は、接続の相手側のSQLNET.ENCRYPTION_CLIENTの設定に部分的に依存します。

表B-2では、SQLNET.ENCRYPTION_SERVERパラメータの属性について説明します。

表B-2 SQLNET.ENCRYPTION_SERVERパラメータの属性

属性

説明

構文

SQLNET.ENCRYPTION_SERVER = valid_value

有効な値

ACCEPTED、REJECTED、REQUESTED、REQUIRED

デフォルト設定

ACCEPTED

関連項目:

SQLNET.ENCRYPTION_SERVERパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

SQLNET.ENCRYPTION_CLIENT

SQLNET.ENCRYPTION_CLIENTパラメータでは、このクライアントまたはクライアントとして機能しているサーバーがサーバーに接続する際の暗号化動作を指定します。

クライアントの動作は、接続の相手側のSQLNET.ENCRYPTION_SERVERの設定値に部分的に依存します。

表B-3では、SQLNET.ENCRYPTION_CLIENTパラメータの属性について説明します。

表B-3 SQLNET.ENCRYPTION_CLIENTパラメータの属性

属性

説明

構文

SQLNET.ENCRYPTION_CLIENT = valid_value

有効な値

ACCEPTED、REJECTED、REQUESTED、REQUIRED

デフォルト設定

ACCEPTED

関連項目:

SQLNET.ENCRYPTION_CLIENTパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

SQLNET.CRYPTO_CHECKSUM_SERVER

SQLNET.CRYPTO_CHECKSUM_SERVERパラメータでは、クライアントまたはクライアントとして機能している別のサーバーがこのサーバーに接続する際のデータ整合性動作を指定します。

動作は、接続の相手側のSQLNET.CRYPTO_CHECKSUM_CLIENTの設定に部分的に依存します。

表B-4では、SQLNET.CRYPTO_CHECKSUM_SERVERパラメータの属性について説明します。

表B-4 SQLNET.CRYPTO_CHECKSUM_SERVERパラメータの属性

属性

説明

構文

SQLNET.CRYPTO_CHECKSUM_SERVER = valid_value

有効な値

ACCEPTED、REJECTED、REQUESTED、REQUIRED

デフォルト設定

ACCEPTED

関連項目:

SQLNET.CRYPTO_CHECKSUM_SERVERパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

SQLNET.CRYPTO_CHECKSUM_CLIENT

SQLNET.CRYPTO_CHECKSUM_CLIENTパラメータでは、このクライアントまたはクライアントとして機能しているサーバーがサーバーに接続する際のデータ整合性動作を指定します。

動作は、接続の相手側のSQLNET.CRYPTO_CHECKSUM_SERVERの設定に部分的に依存します。

表B-5では、SQLNET.CRYPTO_CHECKSUM_CLIENTパラメータの属性について説明します。

表B-5 SQLNET.CRYPTO_CHECKSUM_CLIENTパラメータの属性

属性

説明

構文

SQLNET.CRYPTO_CHECKSUM_CLIENT = valid_value

有効な値

ACCEPTED、REJECTED、REQUESTED、REQUIRED

デフォルト設定

ACCEPTED

SQLNET.ENCRYPTION_TYPES_SERVER

SQLNET.ENCRYPTION_TYPES_SERVERパラメータでは、このサーバーで使用する暗号化アルゴリズムを使用順に指定します。

このリストは、相互に使用可能なアルゴリズムを接続のクライアント側とネゴシエートする際に使用されます。各アルゴリズムは、一致するものが見つかるまで、使用可能なクライアント・アルゴリズムのタイプのリストに対してチェックされます。インストールされていないアルゴリズムをこの側で指定した場合、接続はエラー・メッセージORA-12650: 共通の暗号化またはデータ整合性アルゴリズムがありません。で終了します。

表B-6では、SQLNET.ENCRYPTION_TYPES_SERVERパラメータの属性について説明します。

表B-6 SQLNET.ENCRYPTION_TYPES_SERVERパラメータの属性

属性

説明

構文

SQLNET.ENCRYPTION_TYPES_SERVER = (valid_encryption_algorithm [,valid_encryption_algorithm])

有効な値

- AES256: AES (256ビット鍵サイズ)

- AES192: AES (192ビット鍵サイズ)

- AES128: AES (128ビット鍵サイズ)

デフォルト設定

ローカルのsqlnet.oraファイルでアルゴリズムが定義されていない場合、インストールされているすべてのアルゴリズムが前述の順でネゴシエーションに使用されます。

使用上の注意

複数の暗号化アルゴリズムを指定できます。単一値またはアルゴリズム名のリストを指定できます。たとえば、次の暗号化パラメータはいずれも使用できます。

SQLNET.ENCRYPTION_TYPES_SERVER=(AES256)

SQLNET.ENCRYPTION_TYPES_SERVER=(AES256,AES192,AES128)

関連項目:

SQLNET.ENCRYPTION_TYPES_SERVERパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

SQLNET.ENCRYPTION_TYPES_CLIENT

SQLNET.ENCRYPTION_TYPES_CLIENTパラメータでは、このクライアントまたはクライアントとして機能しているサーバーで使用する暗号化アルゴリズムを指定します。

このリストは、相互に使用可能なアルゴリズムを接続の相手側とネゴシエートする際に使用されます。インストールされていないアルゴリズムをこの側で指定した場合、接続はORA-12650: 共通の暗号化またはデータ整合性アルゴリズムがありません。のメッセージで終了します。

表B-7では、SQLNET.ENCRYPTION_TYPES_CLIENTパラメータの属性について説明します。

表B-7 SQLNET.ENCRYPTION_TYPES_CLIENTパラメータの属性

属性

説明

構文

SQLNET.ENCRYPTION_TYPES_CLIENT = (valid_encryption_algorithm [,valid_encryption_algorithm])

有効な値

- AES256: AES (256ビット鍵サイズ)

- AES192: AES (192ビット鍵サイズ)

- AES128: AES (128ビット鍵サイズ)

デフォルト設定

ローカルのsqlnet.oraファイルでアルゴリズムが定義されていない場合、インストールされているすべてのアルゴリズムがネゴシエーションに使用されます。

使用上の注意

各暗号化アルゴリズムをカンマで区切ることで、複数の暗号化アルゴリズムを指定できます。次に例を示します。

SQLNET.ENCRYPTION_TYPES_CLIENT=(AES256,AES192,AES128)

関連項目:

SQLNET.ENCRYPTION_TYPES_CLIENTパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER

SQLNET.CRYPTO_CHECKSUM_TYPES_SERVERパラメータでは、このサーバーまたは別のサーバーのクライアントで使用するデータ整合性アルゴリズムをアルゴリズムの使用順に指定します。

このリストは、相互に使用可能なアルゴリズムを接続の相手側とネゴシエートする際に使用されます。各アルゴリズムは、一致するものが見つかるまで、使用可能なクライアント・アルゴリズムのタイプのリストに対してチェックされます。インストールされていないアルゴリズムをこの側で指定した場合、接続はORA-12650: 共通の暗号化またはデータ整合性アルゴリズムがありません。のエラー・メッセージで終了します。

表B-8では、SQLNET.CRYPTO_CHECKSUM_TYPES_SERVERパラメータの属性について説明します。

表B-8 SQLNET.CRYPTO_CHECKSUM_TYPES_SERVERパラメータの属性

属性

説明

構文

SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (valid_crypto_checksum_algorithm [,valid_crypto_checksum_algorithm])

有効な値

- SHA512: SHA-2、512ビットのハッシュを生成します。

- SHA384: SHA-2、384ビットのハッシュを生成します。

- SHA256: SHA-2、256ビットのハッシュを生成します。これがデフォルト値です。

- SHA-1: Secure Hash Algorithm

- MD5: Message Digest 5

デフォルト設定

ローカルのsqlnet.oraファイルでアルゴリズムが定義されていない場合、インストールされているすべてのアルゴリズムがSHA256で始まるネゴシエーションに使用されます。

関連項目:

SQLNET.CRYPTO_CHECKSUM_TYPES_SERVERパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT

SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENTパラメータでは、このクライアントまたはクライアントとして機能しているサーバーで使用するデータ整合性アルゴリズムのリストを指定します。

このリストは、相互に使用可能なアルゴリズムを接続の相手側とネゴシエートする際に使用されます。インストールされていないアルゴリズムをこの側で指定した場合、接続はORA-12650: 共通の暗号化またはデータ整合性アルゴリズムがありません。のエラー・メッセージで終了します。

表B-9では、SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENTパラメータの属性について説明します。

表B-9 SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENTパラメータの属性

属性

説明

構文

SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (valid_crypto_checksum_algorithm [,valid_crypto_checksum_algorithm])

有効な値

- SHA512: SHA-2、512ビットのハッシュを生成します。

- SHA384: SHA-2、384ビットのハッシュを生成します。

- SHA256: SHA-2、256ビットのハッシュを生成します。これがデフォルト値です。

- SHA-1: Secure Hash Algorithm

- MD5: Message Digest 5

デフォルト設定

ローカルのsqlnet.oraファイルでアルゴリズムが定義されていない場合、インストールされているすべてのアルゴリズムがSHA256で始まるネゴシエーションに使用されます。

関連項目:

SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENTパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

C Kerberos、SSLおよびRADIUS認証パラメータ

Oracleには、Kerberos、RADIUSまたはSSL認証を使用する場合のプロファイル・ファイル(sqlnet.ora)とデータベース初期化ファイルの認証パラメータによるサンプル構成ファイルがあります。

内容は次のとおりです。

- Kerberos認証を使用するクライアントとサーバーのパラメータ

- Secure Sockets Layerを使用するクライアントとサーバーのパラメータ

- RADIUS認証を使用するクライアントとサーバーのパラメータ

Kerberos認証を使用するクライアントとサーバーのパラメータ

Oracle Databaseには、Kerberos認証を使用するためのクライアントとサーバーのパラメータが用意されています。

表C-1に、Kerberosを使用するクライアントとサーバーの構成ファイルに挿入するパラメータを示します。

表C-1 Kerberos認証パラメータ

ファイル名

構成パラメータ

sqlnet.ora

SQLNET.AUTHENTICATION_SERVICES=(KERBEROS5) SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=oracle SQLNET.KERBEROS5_CC_NAME=/usr/tmp/DCE-CC SQLNET.KERBEROS5_CLOCKSKEW=1200 SQLNET.KERBEROS5_CONF=/krb5/krb.conf SQLNET.KERBEROS5_CONF_MIT=(FALSE) SQLNET.KERBEROS5_REALMS=/krb5/krb.realms SQLNET.KERBEROS5_KEYTAB=/krb5/v5srvtabSQLNET.FALLBACK_AUTHENTICATION=FALSE

初期化パラメータ・ファイル

OS_AUTHENT_PREFIX=""

Secure Sockets Layerを使用するクライアントとサーバーのパラメータ

Secure Sockets Layer (SSL)のパラメータの構成方法は2つあります。

- 静的: sqlnet.oraファイルに存在するパラメータの名前。SSL_CIPHER_SUITESやSSL_VERSIONなどのパラメータは、listener.oraファイルを使用して構成することもできます。

- 動的: Oracle Netアドレスのセキュリティ・サブセクションで使用されるパラメータの名前。

クライアントとサーバーのSecure Sockets Layer認証パラメータ

Oracleには、静的と動的の両方のSecure Sockets Layer(SSL)認証パラメータが用意されています。

表C-2では、サーバーでSSLを構成するための静的パラメータと動的パラメータについて説明します。

表C-2 クライアントとサーバーのSSL認証パラメータ

属性

説明

パラメータ名(静的)

SQLNET.AUTHENTICATION_SERVICES

パラメータ名(動的)

AUTHENTICATION

パラメータ・タイプ

文字列LIST

パラメータ・クラス

静的

設定できる値

使用可能な認証サービスのリストにTCPSを追加します。

デフォルト値

デフォルト値はありません。

説明

ユーザーが使用する認証サービスを制御します。

注意: 動的バージョンでは、1つのタイプの設定のみがサポートされます。

既存/新規パラメータ

既存

構文(静的)

SQLNET.AUTHENTICATION_SERVICES = (TCPS, selected_method_1, selected_method_2)

例(静的)

SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)

構文(動的)

AUTHENTICATION = string

例(動的)

AUTHENTICATION = (TCPS)

Secure Sockets Layerの暗号スイート・パラメータ

Secure Sockets Layer (SSL)に対して暗号スイート・パラメータを構成できます。

表C-3では、暗号スイートを構成するための静的パラメータと動的パラメータについて説明します。

表C-3 Secure Sockets Layerの暗号スイート・パラメータ

属性

説明

パラメータ名(静的)

SSL_CIPHER_SUITES

パラメータ名(動的)

SSL_CIPHER_SUITES

パラメータ・タイプ

文字列LIST

パラメータ・クラス

静的

設定できる値

既知のSSL暗号スイート

デフォルト値

デフォルトなし

説明

SSLで使用する暗号化とデータ整合性の組合せを制御します。

既存/新規パラメータ

既存

構文(静的)

SSL_CIPHER_SUITES=(SSL_cipher_suite1[, SSL_cipher_suite2, ... SSL_cipher_suiteN])

例(静的)

SSL_CIPHER_SUITES=(SSL_DH_DSS_WITH_DES_CBC_SHA)

構文(動的)

SSL_CIPHER_SUITES=(SSL_cipher_suite1

[, SSL_cipher_suite2, ...SSL_cipher_suiteN])

例(動的)

SSL_CIPHER_SUITES=(SSL_DH_DSS_WITH_DES_CBC_SHA)

サポートされているSecure Sockets Layer暗号スイート

Oracle Databaseでは、Secure Sockets Layer (SSL)に対して数多くの暗号スイートをサポートしています。

暗号スイートを次に示します。

- SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

- SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

- SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

- SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

- SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

- SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

- SSL_RSA_WITH_AES_128_CBC_SHA256

- SSL_RSA_WITH_AES_128_GCM_SHA256

- SSL_RSA_WITH_AES_128_CBC_SHA

- SSL_RSA_WITH_AES_256_CBC_SHA

- SSL_RSA_WITH_AES_256_CBC_SHA256

関連項目:
SSL暗号スイートの認証、暗号化、整合性およびTLSバージョン

Secure Sockets Layerバージョン・パラメータ

使用するSSLのバージョンを構成するために、様々なSecure Sockets Layer (SSL)パラメータを設定できます。

表C-4では、使用するSSLのバージョンを構成するための静的および動的なSSL_VERSIONパラメータについて説明します。

表C-4 Secure Sockets Layerバージョン・パラメータ

属性

説明

パラメータ名(静的)

SSL_VERSION

パラメータ名(動的)

SSL_VERSION

パラメータ・タイプ

文字列

パラメータ・クラス

静的

設定できる値

SSLの有効なバージョン。値は次のとおりです。

undetermined | 1.0 | 1.1 | 1.2

あるバージョンまたは別のバージョンを指定する場合は、"or"を使用します。次の値を使用できます。

- 1.0

- 1.1

- 1.2

- 1.0または1.1

- 1.0または1.2

- 1.0または1.1または1.2

デフォルト値

1.2

説明

SSL接続のバージョンを強制します。

既存/新規パラメータ

新規

構文(静的)

SSL_VERSION=version

例(静的)

SSL_VERSION=1.1

構文(動的)

SSL_VERSION=version

例(動的)

SSL_VERSION=1.1または1.2

Secure Sockets Layerクライアント認証パラメータ

クライアントに対してSecure Sockes Layer (SSL)の静的および動的パラメータを構成できます。

表C-5では、SSL_CLIENT_AUTHENTICATIONパラメータについて説明します。

表C-5 Secure Sockets Layerクライアント認証パラメータ

属性

説明

パラメータ名(静的)

SSL_CLIENT_AUTHENTICATION

パラメータ名(動的)

SSL_CLIENT_AUTHENTICATION

パラメータ・タイプ

ブール

パラメータ・クラス

静的

設定できる値

TRUEまたはFALSE

デフォルト値

TRUE

説明

クライアント(サーバーに加えて)をSSLを使用して認証するかどうかを制御します。

既存/新規パラメータ

新規

構文(静的)

SSL_CLIENT_AUTHENTICATION={TRUE | FALSE}

例(静的)

SSL_CLIENT_AUTHENTICATION=FALSE

構文(動的)

SSL_CLIENT_AUTHENTICATION={TRUE | FALSE}

例(動的)

SSL_CLIENT_AUTHENTICATION=FALSE

Secure Sockets Layer X.509サーバー照合パラメータ

SSL_SERVER_DN_MATCHおよびSSL_SERVER_CERT_DNパラメータを使用して、クライアントが接続するサーバーの識別情報を検証できます。

内容は次のとおりです。

- SSL_SERVER_DN_MATCH

- SSL_SERVER_CERT_DN

SSL_SERVER_DN_MATCH

SSL_SERVER_DN_MATCHパラメータでは、サーバーの識別名(DN)がサービスの名前と一致することを強制します。

表C-6では、SSL_SERVER_DN_MATCHパラメータについて説明します。

表C-6 SSL_SERVER_DN_MATCHパラメータ

属性

説明

パラメータ名

SSL_SERVER_DN_MATCH

格納場所

sqlnet.ora

用途

このパラメータを使用して、サーバーの識別名(DN)とそのサービス名の一致を強制します。一致確認を強制する場合は、SSLによって証明書がサーバーからのものであることが保証されます。一致確認を強制しない場合、SSLによるチェックは実行されるものの、一致しているかどうかに関係なく接続は許可されます。 一致を強制しないと、サーバーの識別情報の偽装が可能になります。

値

yes|on|true。一致を強制します。DNとサービス名が一致した場合、接続は正しく行われ、それ以外の場合、接続は失敗します。

no|off|false。一致を強制しません。DNがサービス名と一致していない場合、接続は成功しますが、エラーがsqlnet.logファイルに記録されます。

デフォルト

Oracle8i以上: FALSE。SSLクライアントは(常に)サーバーDNをチェックします。サービス名と一致していない場合、接続は成功しますが、エラーがsqlnet.logファイルに記録されます。

使用上の注意

さらに、tnsnames.oraのパラメータSSL_SERVER_CERT_DNもサーバーDNの一致を有効にするように構成します。

SSL_SERVER_CERT_DN

SSL_SERVER_CERT_DNでは、サーバーの識別名(DN)を指定します。

表C-7では、SSL_SERVER_CERT_DNパラメータについて説明します。

表C-7 SSL_SERVER_CERT_DNパラメータ

属性

説明

パラメータ名

SSL_SERVER_CERT_DN

格納場所

tnsnames.ora。接続先のサーバーごとにクライアントに格納するか、接続先のサーバーごとにLDAPディレクトリに格納し、一元的に更新できます。

用途

このパラメータでは、サーバーの識別名(DN)を指定します。クライアントは、サーバーのDNとそのサービス名が確実に一致するように、この情報を使用して、各サーバーに予定しているDNのリストを取得します。

値

サーバーの識別名(DN)と等しい値を指定します。

デフォルト

N/A

使用上の注意

さらに、sqlnet.oraのパラメータSSL_SERVER_DN_MATCHもサーバーDNの一致を有効にするように構成します。

例

dbalias=(description=address_list=(address=(protocol=tcps)(host=hostname)(port=portnum)))(connect_data=(sid=Finance))(security=(SSL_SERVER_CERT_DN="CN=Finance,CN=OracleContext,C=US,O=Acme"))

Oracleウォレット・ロケーション

セキュリティ資格証明をプロセス領域にロードするためにOracleウォレットにアクセスする必要があるアプリケーションでは、ウォレット・ロケーション・パラメータを指定する必要があります。

表C-8に、ウォレット・ロケーションを指定する必要がある構成ファイルを示します。

- sqlnet.ora

- listener.ora

表C-8 ウォレット・ロケーション・パラメータ

静的構成

動的構成

WALLET_LOCATION =
(SOURCE=
(METHOD=File)
(METHOD_DATA=
(DIRECTORY=your_wallet_dir)
)

)

MY_WALLET_DIRECTORY
= your_wallet_dir

デフォルトのウォレット・ロケーションはORACLE_HOMEディレクトリです。

RADIUS認証を使用するクライアントとサーバーのパラメータ

Oracleには、RADIUS認証用のパラメータが用意されています。

- sqlnet.oraファイルのパラメータ

- 最小限のRADIUSパラメータ

- RADIUSの初期化ファイル・パラメータ

sqlnet.oraファイルのパラメータ

sqlnet.oraファイルを使用すると、RADIUS認証の指定に使用するパラメータを含めることができます。

内容は次のとおりです。

- SQLNET.AUTHENTICATION_SERVICES

- SQLNET.RADIUS_ALTERNATE

- SQLNET.RADIUS_ALTERNATE_PORT

- SQLNET.RADIUS_ALTERNATE_RETRIES

- SQLNET.RADIUS_ALTERNATE_TIMEOUT

- SQLNET.RADIUS_AUTHENTICATION

- SQLNET.RADIUS_AUTHENTICATION_PORT

- SQLNET.RADIUS_AUTHENTICATION_RETRIES

- SQLNET.RADIUS_AUTHENTICATION_TIMEOUT

- SQLNET.RADIUS_CHALLENGE_KEYWORD

- SQLNET.RADIUS_CHALLENGE_RESPONSE

- SQLNET.RADIUS_CLASSPATH

- SQLNET.RADIUS_SECRET

- SQLNET.RADIUS_SEND_ACCOUNTING

SQLNET.AUTHENTICATION_SERVICES

SQLNET.AUTHENTICATION_SERVICESパラメータでは、RADIUSアダプタを使用するようにクライアントまたはサーバーを構成します。

表C-9では、SQLNET.AUTHENTICATION_SERVICESパラメータの属性について説明します。

表C-9 SQLNET.AUTHENTICATION_SERVICESパラメータの属性

属性

説明

構文

SQLNET.AUTHENTICATION_SERVICES=(radius)

デフォルト設定

なし

SQLNET.RADIUS_AUTHENTICATION

SQLNET.RADIUS_AUTHENTICATIONパラメータでは、プライマリRADIUSサーバーの場所(ホスト名またはドット区切りの10進形式)を設定します。

RADIUSサーバーがOracleサーバーとは異なるコンピュータ上にある場合は、そのコンピュータのホスト名またはIPアドレスを指定する必要があります。

表C-10では、SQLNET.RADIUS_AUTHENTICATIONパラメータの属性について説明します。

表C-10 SQLNET.RADIUS_AUTHENTICATIONパラメータの属性

属性

説明

構文

SQLNET.RADIUS_AUTHENTICATION=RADIUS_server_IP_address

デフォルト設定

localhost

SQLNET.RADIUS_AUTHENTICATION_PORT

SQLNET.RADIUS_AUTHENTICATION_PORTパラメータでは、プライマリRADIUSサーバーのリスニング・ポートを設定します。

表C-11では、SQLNET.RADIUS_AUTHENTICATION_PORTパラメータの属性について説明します。

表C-11 SQLNET.RADIUS_AUTHENTICATION_PORTパラメータの属性

属性

説明

構文

SQLNET.RADIUS_AUTHENTICATION_PORT=port_number

デフォルト設定

1645

SQLNET.RADIUS_AUTHENTICATION_TIMEOUT

SQLNET.RADIUS_AUTHENTICATION_TIMEOUTパラメータでは、応答を待機する時間を設定します。

表C-12では、SQLNET.RADIUS_AUTHENTICATION_TIMEOUTパラメータの属性について説明します。

表C-12 SQLNET.RADIUS_AUTHENTICATION_TIMEOUTパラメータの属性

属性

説明

構文

SQLNET.RADIUS_AUTHENTICATION_TIMEOUT=time_in_seconds

デフォルト設定

5

SQLNET.RADIUS_AUTHENTICATION_RETRIES

SQLNET.RADIUS_AUTHENTICATION_RETRIESパラメータでは、認証情報を再送信する回数を設定します。

表C-13では、SQLNET.RADIUS_AUTHENTICATION_RETRIESパラメータの属性について説明します。

表C-13 SQLNET.RADIUS_AUTHENTICATION_RETRIESパラメータの属性

属性

説明

構文

SQLNET.RADIUS_AUTHENTICATION_RETRIES=n_times_to_resend

デフォルト設定

3

SQLNET.RADIUS_SEND_ACCOUNTING

SQLNET.RADIUS_SEND_ACCOUNTINGパラメータでは、アカウンティングのオンとオフを切り替えます。

アカウンティングを有効にした場合、パケットは、1を加えたリスニング・ポートでアクティブなRADIUSサーバーに送信されます。デフォルトでは、パケットはポート1646に送信されます。この機能は、RADIUSサーバーでアカウンティングがサポートされ、ユーザーがシステムにログオンする回数を追跡する場合にのみオンにする必要があります。

表C-14では、SQLNET.RADIUS_SEND_ACCOUNTINGパラメータの属性について説明します。

表C-14 SQLNET.RADIUS_SEND_ACCOUNTINGパラメータの属性

属性

説明

構文

SQLNET.RADIUS_SEND_ACCOUNTING=on

デフォルト設定

off

SQLNET.RADIUS_SECRET

SQLNET.RADIUS_SECRETパラメータでは、RADIUS秘密鍵のファイル名と場所を指定します。

表C-15では、SQLNET.RADIUS_SECRETパラメータの属性について説明します。

表C-15 SQLNET.RADIUS_SECRETパラメータの属性

属性

説明

構文

SQLNET.RADIUS_SECRET=path_to_RADIUS_secret_key

デフォルト設定

$ORACLE_HOME/network/security/radius.key

SQLNET.RADIUS_ALTERNATE

SQLNET.RADIUS_ALTERNATEパラメータでは、プライマリ・サーバーをフォルト・トレランスに使用できない場合に使用する代替RADIUSサーバーの場所を設定します。

表C-16では、SQLNET.RADIUS_ALTERNATEパラメータの属性について説明します。

表C-16 SQLNET.RADIUS_ALTERNATEパラメータの属性

属性

説明

構文

SQLNET.RADIUS_ALTERNATE=alternate_RADIUS_server_hostname_or_IP_address

デフォルト設定

off

SQLNET.RADIUS_ALTERNATE_PORT

SQLNET.RADIUS_ALTERNATE_PORTパラメータでは、代替RADIUSサーバーのリスニング・ポートを設定します。

表C-17では、SQLNET.RADIUS_ALTERNATE_PORTパラメータの属性について説明します。

表C-17 SQLNET.RADIUS_ALTERNATE_PORTパラメータの属性

属性

説明

構文

SQLNET.RADIUS_ALTERNATE_PORT=alternate_RADIUS_server_listening_port_number

デフォルト設定

1645

SQLNET.RADIUS_ALTERNATE_TIMEOUT

SQLNET.RADIUS_ALTERNATE_TIMEOUTパラメータは、代替RADIUSサーバーの応答を待機する時間を設定します。

表C-18では、SQLNET.RADIUS_ALTERNATE_TIMEOUTパラメータの属性について説明します。

表C-18 SQLNET.RADIUS_ALTERNATE_TIMEOUTパラメータの属性

属性

説明

構文

SQLNET.RADIUS_ALTERNATE_TIMEOUT=time_in_seconds

デフォルト設定

5

SQLNET.RADIUS_ALTERNATE_RETRIES

SQLNET.RADIUS_ALTERNATE_RETRIESパラメータでは、代替RADIUSサーバーでメッセージを再送信する回数を設定します。

表C-19では、SQLNET.RADIUS_ALTERNATE_RETRIESパラメータの属性について説明します。

表C-19 SQLNET.RADIUS_ALTERNATE_RETRIESパラメータの属性

属性

説明

構文

SQLNET.RADIUS_ALTERNATE_RETRIES=n_times_to_resend

デフォルト設定

3

SQLNET.RADIUS_CHALLENGE_RESPONSE

SQLNET.RADIUS_CHALLENGE_RESPONSEパラメータでは、チャレンジ・レスポンス(非同期)モードのオンとオフを切り替えます。

表C-20では、SQLNET.RADIUS_CHALLENGE_RESPONSEパラメータの属性について説明します。

表C-20 SQLNET.RADIUS_CHALLENGE_RESPONSEパラメータの属性

属性

説明

構文

SQLNET.RADIUS_CHALLENGE_RESPONSE=on

デフォルト設定

off

SQLNET.RADIUS_CHALLENGE_KEYWORD

SQLNET.RADIUS_CHALLENGE_KEYWORDパラメータでは、RADIUSサーバーからのチャレンジを要求するためのキーワードを設定します。

ユーザーはクライアントでパスワードを入力しません。

表C-21では、SQLNET.RADIUS_CHALLENGE_KEYWORDパラメータの属性について説明します。

表C-21 SQLNET.RADIUS_CHALLENGE_KEYWORDパラメータの属性

属性

説明

構文

SQLNET.RADIUS_CHALLENGE_KEYWORD=keyword

デフォルト設定

challenge

SQLNET.RADIUS_AUTHENTICATION_INTERFACE

SQLNET.RADIUS_AUTHENTICATION_INTERFACEパラメータでは、RADIUSがチャレンジ・レスポンス(非同期)モードの場合に、GUIを含むJavaクラスの名前を設定します。

表C-22では、SQLNET.RADIUS_AUTHENTICATION_INTERFACEパラメータの属性について説明します。

表C-22 SQLNET.RADIUS_AUTHENTICATION_INTERFACEパラメータの属性

属性

説明

構文

SQLNET.RADIUS_AUTHENTICATION_INTERFACE=Java_class_name

デフォルト設定

DefaultRadiusInterface (oracle/net/radius/DefaultRadiusInterface)

SQLNET.RADIUS_CLASSPATH

SQLNET.RADIUS_CLASSPATHパラメータでは、JavaクラスおよびJDK Javaライブラリのパスを指定します。

チャレンジ・レスポンス認証モードを使用する場合、最初にパスワード、続いて追加情報(トークン・カードから取得する動的パスワードなど)を要求するJavaベースのグラフィカル・インタフェースがユーザーに表示されます。

sqlnet.oraファイルにSQLNET.RADIUS_CLASSPATHパラメータを追加して、そのグラフィカル・インタフェースのJavaクラスを設定し、JDK Javaライブラリへのパスを設定します。

表C-23では、SQLNET.RADIUS_CLASSPATHパラメータの属性について説明します。

表C-23 SQLNET.RADIUS_CLASSPATHパラメータの属性

属性

説明

構文

SQLNET.RADIUS_CLASSPATH=path_to_GUI_Java_classes

デフォルト設定

$ORACLE_HOME/jlib/netradius.jar:$ORACLE_HOME/JRE/lib/sparc/native_threads

最小限のRADIUSパラメータ

少なくとも、SQLNET.AUTHENTICATION_SERVICESパラメータとSQLNET.RADIUS.AUTHENTICATIONパラメータを使用する必要があります。

次の設定を使用します。

sqlnet.authentication_services = (radius)
sqlnet.radius.authentication   = IP-address-of-RADIUS-server

RADIUSの初期化ファイル・パラメータ

RADIUSの場合、OS_AUTHENT_PREFIX初期化パラメータを設定します。

次に例を示します。

OS_AUTHENT_PREFIX=""

D RADIUSを使用した認証デバイスの統合

Oracleでは、RADIUSチャレンジ・レスポンス・ユーザー・インタフェースを使用して、RADIUS構成での認証をさらに強化できます。

内容は次のとおりです。

- RADIUSチャレンジ・レスポンス・ユーザー・インタフェースについて

- RADIUSチャレンジ・レスポンス・ユーザー・インタフェースのカスタマイズ

- 例: OracleRadiusInterfaceインタフェースの使用

関連項目:

RADIUS認証の構成

RADIUSチャレンジ・レスポンス・ユーザー・インタフェースについて

サード・パーティ認証ベンダーを使用して、RADIUSチャレンジ・レスポンス・ユーザー・インタフェースを特定のデバイスに合うようにカスタマイズできます。

RADIUS規格をサポートする任意の認証デバイスを、Oracleユーザーが認証されるように設定できます。認証デバイスでチャレンジ・レスポンス・モードを使用する場合、グラフィカル・インタフェースでエンド・ユーザーはまずパスワードの入力、次に追加情報の入力を求められます(たとえば、ユーザーがトークン・カードから取得する動的パスワードがあります)。このインタフェースはJavaベースで、最適なプラットフォーム独立性を提供します。

認証デバイスのサード・パーティ・ベンダーは、その独自のデバイスに合せてこのグラフィカル・ユーザー・インタフェースをカスタマイズする必要があります。たとえば、スマートカード・ベンダーは、チャレンジをスマートカード・リーダーに発行するようにOracleクライアントをカスタマイズします。スマートカードはチャレンジを受け取ると、ユーザーにPINなどの追加情報の入力を求めることで応答します。

関連項目:
RADIUS認証の構成

RADIUSチャレンジ・レスポンス・ユーザー・インタフェースのカスタマイズ

独自のクラスを作成して、OracleRadiusInterfaceインタフェースをカスタマイズできます。

1. sqlnet.oraファイルを開きます。

デフォルトでは、sqlnet.oraファイルは、ORACLE_HOME/network/adminディレクトリ、またはTNS_ADMIN環境変数によって設定されている場所にあります。TNS_ADMIN変数が正しいsqlnet.oraファイルを指定するように適切に設定されていることを確認します。

2. SQLNET.RADIUS_AUTHENTICATION_INTERFACEパラメータを探し、そこにリストされているクラスの名前(DefaultRadiusInterface)を作成した新しいクラスの名前に置き換えます。

この変更をsqlnet.oraファイルで行うと、クラスは認証プロセスを処理するためにOracleクライアントにロードされます。

3. sqlnet.oraファイルを保存して終了します

サード・パーティは、ORACLE.NET.RADIUSパッケージにあるOracleRadiusInterfaceインタフェースを実装する必要があります。

関連項目:
TNS_ADMIN変数の詳細および設定例は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください

例: OracleRadiusInterfaceインタフェースの使用

OracleRadiusInterfaceインタフェースを使用して、ユーザー名とパスワードを取得できます。

例D-1に、OracleRadiusInterfaceインタフェースの使用方法を示します。

例D-1 OracleRadiusInterfaceインタフェースの使用

public interface OracleRadiusInterface {
public void radiusRequest();
public void radiusChallenge(String challenge);
public String getUserName();
public String getPassword();
}

次のように値を指定します。

- radiusRequestは、エンド・ユーザーにユーザー名とパスワードの入力を求めます(これらは後でgetUserNameとgetPasswordを使用して取得されます)。

- getUserNameは、ユーザーが入力したユーザー名を抽出します。空の文字列が戻された場合、ユーザーが操作をキャンセルするとみなされます。その後、ユーザーは認証に失敗したことを示すメッセージを受信します。

- getPasswordは、ユーザーが入力したパスワードを抽出します。getUserNameが有効な文字列を戻し、getPasswordが空の文字列を戻した場合、データベースによってチャレンジ・キーワードがパスワードとして使用されます。ユーザーが有効なパスワードを入力した場合、チャレンジがRADIUSサーバーから戻される場合と戻されない場合がります。

- radiusChallengeは、ユーザーがサーバーのチャレンジに応答できるように、RADIUSサーバーから送信された要求を表示します。

- getResponseは、ユーザーが入力した応答を抽出します。有効な応答が戻された場合、その情報が新しいAccess-RequestパケットのUser-Password属性に移入されます。空の文字列が戻された場合、操作は対応する値を戻すことによって両側から中断されます。

E Oracle Database FIPS 140-2の設定

Oracleでは、米国連邦情報処理標準(FIPS)の標準である140-2にあわせてOracle Databaseを使用できます。

内容は次のとおりです。

- Oracle Database FIPS 140-2の設定について

- 透過的データ暗号化およびDBMS_CRYPTO用のFIPS 140-2の構成

- Secure Sockets Layerに対するFIPS 140-2の構成

- FIPS 140-2のインストール後のチェック

- FIPS 140-2接続の検証

Oracle Database FIPS 140-2の設定について

米国連邦情報処理標準(FIPS)の標準140-2は、暗号化モジュールのセキュリティ要件を定義する米国連邦政府の標準です。

FIPS 140-2暗号ライブラリは、静止中およびネットワーク上を伝送中のデータを保護する目的で設計されています。

Oracle Databaseでは、Secure Sockets Layer (SSL)、透過的データ暗号化(TDE)およびDBMS_CRYPTO PL/SQLパッケージ認証用の暗号ライブラリを使用します。

現在の動作保証のステータスの情報は、米国標準技術局(National Institute of Standards and Technology)のコンピュータ・セキュリティ・リソース・センター(Computer Security Resource Center: CSRC)のWebサイトの次のアドレスで確認できます。

http://csrc.nist.gov/groups/STM/cmvp/validation.html

FIPS固有の情報は、Validated FIPS 140 Cryptographic Modulesを検索してください。このサイトで証明書の検証に成功すると使用できるようになるセキュリティ・ポリシーには、ホスト・オペレーティング・システムのセキュアな構成に関する要件が含まれています。

透過的データ暗号化およびDBMS_CRYPTO用のFIPS 140-2の構成

DBFIPS_140初期化パラメータはFIPSモードを構成します。

1. 透過的データ暗号化およびDBMS_CRYPTO PL/SQLパッケージ・プログラム・ユニットをFIPSモードで実行するよう構成するには、DBFIPS_140初期化パラメータをTRUEに設定します。
このパラメータの効果は、プラットフォームによって異なります。

2. データベースを再起動します。

表E-1に、DBFIPS_140パラメータの各プラットフォームへの作用について説明します。

表E-1 DBFIPS_140初期化パラメータのプラットフォームへの作用

プラットフォーム

DBFIPS_140をTRUEまたはFALSEに設定した場合の効果

Intel x86_64上のLinuxまたはWindows

- TRUE: TDEおよびDBMS_CRYPTOプログラム・ユニットは、Micro Edition Suite (MES) 4.0.5.1 FIPSモードを使用します。

- FALSE: TDEおよびDBMS_CRYPTOプログラム・ユニットは、Intel Performance Primitives (IPP)を使用します。

SPARC TシリーズまたはIntel x86_64上のSolaris 11.1+

- TRUE: TDEおよびDBMS_CRYPTOプログラム・ユニットはMES 4.1.2 FIPSモードを使用します。

- FALSE: TDEおよびDBMS_CRYPTOプログラム・ユニットは、Solaris Cryptographic Framework (SCF)/UCrypto (FIPS 140に対して個別に検証される)を使用します。

他のオペレーティング・システムまたはハードウェア

- TRUE: TDEおよびDBMS_CRYPTOプログラム・ユニットはMES 4.1.2 FIPSモードを使用します。

- FALSE: TDEおよびDBMS_CRYPTOプログラム・ユニットはMES 4.1.2非FIPSモードを使用します。

DBFIPS_140をTRUEに設定し、基礎をなすライブラリをFIPSモードで使用する場合、ライブラリを初めてロードする際、一定のオーバーヘッドが生じることに注意してください。これは、署名の検証およびライブラリに対する自己テストの実行によるものです。ライブラリのロード後は、パフォーマンスへの影響はありません。

関連項目:

DBFIPS_140初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

Secure Sockets Layerに対するFIPS 140-2の構成

Secure Sockets Layerに対してSSLFIPS_140パラメータを構成できます。

内容は次のとおりです。

- Secure Sockets LayerのSSLFIPS_140パラメータの構成

- FIPS 140-2用に承認されているSSL暗号スイート

Secure Sockets LayerのSSLFIPS_140パラメータの構成

fips.oraファイルでSSLFIPS_140パラメータをTRUEに設定して、Secure Socket Layer (SSL)アダプタをFIPSモードで実行するように構成します。

1. fips.oraファイルが$ORACLE_HOME/ldap/adminディレクトリにあるか、またはFIPS_HOME環境変数で指定された場所にあることを確認します。

2. fips.oraファイルでSSLFIPS_140を設定します。

たとえば、SSLFIPS_140をTRUEに設定するには、次のようにします。

SSLFIPS_140=TRUE

このパラメータは、デフォルトでFALSEに設定されています。FIPSモードで操作するには、クライアントとサーバーの両方でTRUEに設定する必要があります。

3. 任意のデータベース・サーバーまたはクライアントの任意のOracle Databaseホームでこの手順を繰り返します。

SSLFIPS_140をTRUEに設定した場合、Secure Sockets Layer暗号操作はFIPSモードの埋込みRSA/Micro Edition Suite (MES)ライブラリで行われます。ハードウェア・アクセラレーションが使用可能でホスト・ハードウェアおよびソフトウェアで適切に構成されている場合、これらの暗号操作はCPUによって高速化されます。

SSLFIPS_140をFALSEに設定した場合、Secure Sockets Layer暗号操作は、非FIPSモードの埋込みRSA/Micro Edition Suite (MES)ライブラリで行われ、TRUEに設定した場合と同様に、可能な場合は操作が高速化されます。

本来の暗号化では、RSA/Micro Edition Suite (MES)でランディングして高速化される暗号操作の動作は、前述の場合と同様になりますが、(fips.oraのSSL_FIPS140設定ではなく)sqlnet.oraのFIPS_140設定で決まる点を除きます。

注意:

Oracle Database 10g リリース2 (10.2)で使用されたSQLNET.SSLFIPS_140パラメータは、SSLFIPS_140パラメータに置換されます。このパラメータは、sqlnet.oraファイルではなくfips.oraファイルで設定する必要があります。

FIPS 140-2用に承認されているSSL暗号スイート

暗号スイートは、ネットワーク・ノード間のメッセージを交換する認証、暗号化およびデータ整合性アルゴリズムのセットです。

たとえば、SSLハンドシェイク時に、メッセージを送受信するときに使用する暗号スイートを確認するために2つのノード間でネゴシエーションが行われます。

FIPS検証では、次の暗号スイートのみが承認されます。

- SSL_DH_anon_WITH_3DES_EDE_CBC_SHA

- SSL_RSA_WITH_AES_256_CBC_SHA

- SSL_RSA_WITH_AES_128_CBC_SHA

- SSL_RSA_WITH_AES_256_GCM_SHA384

- SSL_RSA_WITH_3DES_EDE_CBC_SHA

Oracle DatabaseのSSL暗号スイートは、FIPS認定の暗号スイートに自動的に設定されます。特定の暗号スイートを設定する場合は、sqlnet.oraまたはlistener.oraファイルでSSL_CIPHER_SUITESパラメータを編集します。

SSL_CIPHER_SUITES=(SSL_cipher_suite1[,SSL_cipher_suite2[,..]])

このパラメータは、Oracle Net Managerを使用してサーバーおよびクライアントで設定することもできます。

関連項目:

暗号スイートの設定の詳細は、手順1C: サーバーでのSecure Sockets Layer暗号スイートの設定(オプション)および手順2D: クライアントのSecure Sockets Layer暗号スイートの設定(オプション)を参照してください。

FIPS 140-2のインストール後のチェック

FIPS 140-2設定の構成後に、オペレーティング・システムで次の権限を確認する必要があります。

その権限を次に示します。

- システムのセキュリティ・ポリシーに従って、権限のないユーザーがOracle Cryptographic Librariesを実行できないようにするには、すべてのOracle実行可能ファイルに対して実行権限を設定する必要があります。

- ユーザーが誤ってまたは故意にOracle Cryptographic Librariesのファイルを読み取ったり変更しないようにするには、すべてのOracle実行可能ファイルに対して読取りおよび書込み権限を設定する必要があります。

FIPS 140-2 Level 2要件に準拠するには、権限のないユーザーが、オペレーティング・システムで使用しているOracle Cryptographic Librariesのプロセスおよびメモリーの読取り、変更または実行を行えないようにする手順をセキュリティ・ポリシーに含めます。

FIPS 140-2接続の検証

FIPSモードがSSLに対して有効かどうかを確認するには、sqlnet.oraファイルでトレースを有効にします。

FIPSの自己テスト・メッセージはトレース・ファイルにあります。

1. トレースを有効にするには、sqlnet.oraに次の行を追加します。

trace_directory_server=trace_dir
trace_file_server=trace_file
trace_level_server=trace_level

例:

trace_directory=/private/oracle/owm
trace_file_server=fips_trace.trc
trace_level_server=6

2. FIPSモードがTDEおよびDBMS_CRYPTOに対して有効かどうかを確認するには、SQL*Plusにログインし、次のコマンドを実行します。

SHOW PARAMETER DBFIPS_140

トレース・レベル6は、FIPSの自己テストの結果を確認するために必要な最低限のトレース・レベルです。

F orapkiユーティリティを使用したPKI要素の管理

orapkiコマンドライン・ユーティリティを使用して、署名付き証明書の作成、Oracleウォレットの管理、証明書失効リストの管理など、PKI要素を管理できます。

内容は次のとおりです。

- orapkiユーティリティの使用

- orapkiユーティリティの構文

- テスト用の署名付き証明書の作成

- 証明書の表示

- orapkiユーティリティを使用したOracleウォレットの管理

- orapkiユーティリティを使用した証明書失効リスト(CRL)の管理

- orapkiの使用方法

- orapkiユーティリティ・コマンドのサマリー

注意:

PKI暗号化と透過的データ暗号化を組み合せた使用は非推奨です。透過的データ暗号化を構成するには、ADMINISTER KEY MANAGEMENT SQL文を使用します。詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

orapkiユーティリティの使用

orapkiユーティリティでは、公開鍵インフラストラクチャ(PKI)要素(ウォレットや証明書失効リストなど)をコマンドラインから管理します。

これにより、スクリプトを使用してこれらのタスクを自動化できます。PKI要素の管理をスクリプトに組み込む方法を提供することにより、PKIを管理するための数多くのルーチン・タスクを自動化できるようになります。

orapkiコマンドライン・ユーティリティを使用して次のタスクを実行できます。

- テスト用の署名付き証明書の作成および表示

- Oracleウォレットの管理(透過的データ暗号化キーストアを除く):

- Oracleウォレットの作成および表示

- 証明書リクエストの追加および削除

- 証明書の追加および削除

- 信頼できる証明書の追加および削除

- 証明書失効リスト(CRL)の管理:

- 証明書検証用ハッシュ値によるCRLの名前変更

- Oracle Internet DirectoryでのCRLのアップロード、一覧表示、表示および削除

注意:

PKI暗号化と透過的データ暗号化を組み合せた使用は非推奨です。透過的データ暗号化を構成するには、ADMINISTER KEY MANAGEMENT SQL文を使用します。詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

orapkiユーティリティの構文

orapkiユーティリティの構文を使用して、Oracleウォレット、証明書失効リストまたはPKIデジタル証明書を指定できます。

orapkiコマンドライン・ユーティリティの構文を次に示します。

orapki module command -parameter value

ここで、moduleをwallet(Oracleウォレット)、crl(証明書失効リスト)またはcert(PKIデジタル証明書)にできます。使用可能なコマンドは、使用するmoduleによって異なります。

たとえば、walletを使用している場合、addコマンドを使用して証明書またはキーをウォレットに追加できます。次の例では、/private/lhale/cert.txtにあるユーザー証明書が、$ORACLE_HOME/wallet/ewallet.p12にあるウォレットに追加されます。

orapki wallet add -wallet $ORACLE_HOME/wallet/ewallet.p12 -user_cert -cert /private/lhale/cert.txt

テスト用の署名付き証明書の作成

orapkiユーティリティは、テスト用の署名付き証明書を作成する便利で手軽な方法を提供します。

- テスト用の署名付き証明書を作成するには、次のコマンドを使用します。

orapki cert create [-wallet wallet_location] -request certificate_request_location -cert certificate_location -validity number_of_days [-summary]

このコマンドにより、証明書リクエストから署名付き証明書が作成されます。-walletパラメータは、証明書リクエストへの署名に使用されるユーザー証明書と秘密鍵を含むウォレットを指定します。-validityパラメータは、現在の日付から数えてこの証明書が有効である日数を指定します。証明書と証明書リクエストの指定は、このコマンドでは必須です。

証明書の表示

証明書を作成した後は、orapkiユーティリティを使用してその証明書を表示できます。

- 証明書を表示するには、次のコマンドを使用します。

orapki cert display -cert certificate_location [-summary | -complete]

このコマンドを使用すると、orapkiを使用して作成したテスト証明書を表示できます。-summaryまたは-completeのいずれかを選択できます。これによりコマンドが表示するデータの詳細さが決まります。-summaryを選択すると、証明書とその有効期限が表示されます。-completeを選択すると、シリアル番号、公開鍵などの追加の証明書情報が表示されます。

orapkiユーティリティを使用したOracleウォレットの管理

orapkiユーティリティを使用して、Oracleウォレットを作成、表示および変更できます。orapkiを使用して、証明書を追加したり、証明書リクエストをエクスポートすることもできます。

内容は次のとおりです。

- orapkiを使用したウォレットの管理について

- orapkiを使用したウォレットの作成、表示および変更

- orapkiを使用した証明書と証明書リクエストのOracleウォレットへの追加

- orapkiを使用した証明書と証明書リクエストのOracleウォレットからのエクスポート

注意:

-walletパラメータは、すべてのwalletモジュール・コマンドで必須です。

orapkiを使用したウォレットの管理について

Oracleウォレットの作成および管理に使用するorapkiコマンドライン・ユーティリティを理解する必要があります。

orapkiユーティリティのwalletモジュール・コマンドをスクリプトで使用して、ウォレット作成プロセスを自動化できます。たとえば、PKCS#12ウォレットおよび自動ログイン・ウォレットを作成できます。PKCS#12ウォレットに関連付けられている自動ログイン・ウォレット、またはウォレットが作成されたコンピュータおよびウォレット作成ユーザーに対してローカルな自動ログイン・ウォレットを作成できます。ウォレットを表示したり、ウォレットのパスワードを変更したり、AES256アルゴリズムを使用するようにウォレットを変換できます。

注意:

-walletパラメータは、すべてのwalletモジュール・コマンドで必須です。

orapkiを使用したウォレットの作成、表示および変更

orapkiを使用して、Oracleウォレットでの様々な管理アクティビティを実行できます。

内容は次のとおりです。

- PKCS#12ウォレットの作成

- 自動ログイン・ウォレットの作成

- PKCS#12ウォレットに関連付けられた自動ログイン・ウォレットの作成

- コンピュータとウォレット作成ユーザーにローカルな自動ログイン・ウォレットの作成

- ウォレットの表示

- ウォレットのパスワードの変更

- AES256アルゴリズムの使用を目的としたOracleウォレットの変換

PKCS#12ウォレットの作成

orapkiユーティリティを使用して、PKCS#12のOracleウォレットを作成できます。

- Oracle PKCS#12ウォレット(ewallet.p12)を作成するには、orapki wallet createコマンドを使用します。

orapki wallet create -wallet wallet_location [-pwd password]

コマンドラインでパスワードを指定していない場合、このコマンドではウォレットのパスワードの入力と再入力を求められます。-walletで指定された場所にウォレットが作成されます。

注意:

セキュリティ上の理由から、コマンドラインにパスワードを指定しないことをお薦めします。パスワードの入力は、求められた場合にのみ行ってください。

自動ログイン・ウォレットの作成

orapkiユーティリティを使用して、自動ログイン・ウォレットを作成できます。

- ウォレットを開く際にパスワードを必要としない自動ログイン・ウォレット(cwallet.sso)を作成するには、orapki wallet createコマンドを使用します。

orapki wallet create -wallet wallet_location -auto_login_only

パスワードを使用しないでウォレットを変更または削除できます。ファイル・システム権限によって、このような自動ログイン・ウォレットに必要なセキュリティが提供されます。

ローカルの自動ログイン・ウォレットを別のコンピュータに移動することはできません。それらは作成されたホストで使用する必要があります。

ローカルの自動ログイン・ウォレットを開く際にパスワードが不要な場合でも、ウォレットを変更または削除するには、関連付けられたPKCS#12ウォレットのパスワードを入力する必要があります。PKCS#12ウォレットを更新した場合、関連付けられた自動ログイン・ウォレットも更新されます。

PKCS#12ウォレットに関連付けられた自動ログイン・ウォレットの作成

PKCS#12ウォレットに関連付けられた自動ログイン・ウォレットを作成できます。

自動ログイン・ウォレットを開くのにパスワードは必要ありません。

ただし、ウォレットを変更または削除するには、関連付けられたPKCS#12ウォレットのパスワードを入力する必要があります。PKCS#12ウォレットを更新した場合、関連付けられた自動ログイン・ウォレットも更新されます。

- PKCS#12ウォレット(ewallet.p12)に関連付けられた自動ログイン・ウォレット(cwallet.sso)を作成するには、次のコマンドを使用します。

orapki wallet create -wallet wallet_location -auto_login [-pwd password]

このコマンドでは、自動ログインが有効なウォレット(cwallet.sso)が作成され、PKCS#12ウォレット(ewallet.p12)に関連付けられます。コマンドラインでパスワードを指定していない場合、このコマンドではPKCS#12ウォレットのパスワードの入力を求められます。

wallet_locationがPKCS#12ウォレットにすでに含まれている場合は、その自動ログインが有効になります。既存のPKCS#12ウォレットの自動ログインを有効にするには、そのパスワードを入力する必要があります。

wallet_locationがPKCS#12ウォレットに含まれていない場合は、新しいPKCS#12ウォレットが作成されます。新しいPKCS#12ウォレットのパスワードを指定する必要があります。

PKCS#12ウォレットの自動ログイン機能をオフにする場合は、Oracle Wallet Managerを使用します。

関連項目:

詳細は、Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイドを参照してください

コンピュータとウォレット作成ユーザーにローカルな自動ログイン・ウォレットの作成

orapkiユーティリティは、ウォレットを作成したユーザーのコンピュータにローカルな自動ログイン・ウォレットを作成できます。

- 自動ログイン・ウォレットが作成されるコンピュータとそのウォレットを作成したユーザーの両方にローカルな自動ログイン・ウォレットを作成するには、次のコマンドを使用します。

orapki wallet create -wallet wallet_location -auto_login_local [-pwd password]

このコマンドにより、自動ログイン・ウォレット(cwallet.sso)が作成されます。これは、PKCS#12ウォレット(ewallet.p12)に関連付けられます。コマンドラインでパスワードを指定していない場合、このコマンドではPKCS#12ウォレットのパスワードの入力を求められます。

ウォレットの表示

orapkiユーティリティを使用して、ウォレットを表示できます。

- Oracleウォレットを表示するには、orapki wallet displayコマンドを使用します。

orapki wallet display -wallet wallet_location

このコマンドを使用すると、ウォレットに含まれている証明書リクエスト、ユーザー証明書および信頼できる証明書が表示されます(これらは拡張子.p12のバイナリPKCS12ファイルであることが必要です)。他のファイルでは失敗します。

ウォレットのパスワードの変更

orapkiユーティリティを使用して、ウォレットのパスワードを変更できます。

- ウォレットのパスワードを変更するには、次のコマンドを使用します。

orapki wallet change_pwd -wallet wallet_location [-oldpwd password ] [-newpwd password]

このコマンドでは、現在のウォレットのパスワードが新しいパスワードに変更されます。コマンドラインでパスワードを指定していない場合、このコマンドでは新旧のパスワードを求められます。

注意:

セキュリティ上の理由から、コマンドラインでパスワード・オプションを指定しないことをお薦めします。パスワードの入力は、求められたときに行ってください。

AES256アルゴリズムの使用を目的としたOracleウォレットの変換

デフォルトでは、ADMINISTER KEY MANAGEMENT文またはALTER SYSTEM文を使用したOracleウォレットは3DESで暗号化されます。

orapki convertコマンドを使用して、3DESアルゴリズムよりも強力なAES256アルゴリズムを使用するようにウォレットを変換できます。ADMINISTER KEY MANAGEMENT文やALTER SYSTEM文ではなくorapkiを使用してウォレットを作成した場合、そのウォレットはデフォルトでAES256アルゴリズムを使用します。

- ウォレットのアルゴリズムを3DESからAES256に変更する手順

orapki wallet convert -wallet wallet_location [-pwd password] [-compat_v12]

compat_v12設定は、3DESからAES256への変換を行います。

orapkiを使用した証明書と証明書リクエストのOracleウォレットへの追加

orapkiユーティリティを使用して、様々な証明書関連タスクを実行できます。

内容は次のとおりです。

- 証明書リクエストのOracleウォレットへの追加

- ルート証明書のOracleウォレットへの追加

- 信頼できる証明書のOracleウォレットへの追加

- ユーザー証明書のOracleウォレットへの追加

- PKCS#11情報のOracleウォレットへの追加

証明書リクエストのOracleウォレットへの追加

orapkiユーティリティを使用して、証明書および証明書リクエストをOracleウォレットに追加できます。

- Oracleウォレットに証明書リクエストを追加するには、orapki wallet addコマンドを使用します。

orapki wallet add -wallet wallet_location -dn user_dn -keySize 512|1024|2048

このコマンドを使用すると、指定した識別名(user_dn)を持つユーザーのウォレットに証明書リクエストが追加されます。このリクエストでは、リクエストされた証明書のキー・サイズ(512、1024または2048ビット)も指定します。リクエストに署名するには、エクスポート・オプションを使用してそのリクエストをエクスポートします。

関連項目:

詳細は、orapkiを使用した証明書と証明書リクエストのOracleウォレットからのエクスポートを参照してください

信頼できる証明書のOracleウォレットへの追加

orapkiユーティリティを使用して、信頼できる証明書をOracleウォレットに追加できます。

- Oracleウォレットに信頼できる証明書を追加するには、次のコマンドを使用します。

orapki wallet add -wallet wallet_location -trusted_cert -cert
certificate_location

このコマンドでは、指定した場所(-cert certificate_location)にある信頼できる証明書がウォレットに追加されます。ユーザー証明書を追加する前に、ユーザー証明書の証明連鎖にあるすべての信頼できる証明書を追加する必要があります。そうしないと、ユーザー証明書を追加するコマンドは失敗します。

ルート証明書のOracleウォレットへの追加

orapkiユーティリティを使用して、ルート証明書をOracleウォレットに追加できます。

- Oracleウォレットにルート証明書を追加するには、次のコマンドを使用します。

orapki wallet add -wallet wallet_location -dn certificate_dn -keySize 512|1024|2048 -self_signed -validity number_of_days

このコマンドを使用すると、新しい自己署名(ルート)証明書が作成され、ウォレットに追加されます。-validityパラメータ(必須)は、現在の日付から数えてこの証明書が有効である日数を指定します。このルート証明書の鍵サイズ(-keySize)は、512、1024または2048ビットに指定できます。

ユーザー証明書のOracleウォレットへの追加

orapkiユーティリティを使用して、ユーザー証明書をOracleウォレットに追加できます。

- Oracleウォレットにユーザー証明書を追加するには、次のコマンドを使用します。

orapki wallet add -wallet wallet_location -user_cert -cert certificate_location

このコマンドでは、-certパラメータで指定された場所にあるユーザー証明書が、wallet_locationにあるOracleウォレットに追加されます。ユーザー証明書をウォレットに追加する前に、証明連鎖を構成するすべての信頼できる証明書を追加する必要があります。ユーザー証明書を追加する前に、すべての信頼できる証明書がウォレットに追加されていない場合、ユーザー証明書の追加は失敗します。

注意:

セキュリティ上の理由から、コマンドラインにパスワードを指定しないことをお薦めします。パスワードの入力は、求められたときに行ってください。

PKCS#11ウォレットを使用したハードウェア・デバイス上の資格証明の検証

PKCS#11ウォレットを使用して、ハードウェア・デバイス上の資格証明を検証できます。

- 次のコマンドを使用して、資格証明の詳細を検証します。

orapki wallet p11_verify -wallet wallet_location [-pwd password]

PKCS#11情報のOracleウォレットへの追加

PKCS#11情報を含むウォレットは、Oracleウォレットのように使用できます。

秘密鍵はハードウェア・デバイスに格納されます。暗号化処理もデバイスで実行されます。

- ウォレットにPKCS#11情報を追加するには、次のコマンドを使用します。

orapki wallet p11_add -wallet wallet_location -p11_lib pkcs11Lib
[-p11_tokenlabel tokenLabel] [-p11_tokenpw tokenPassphrase]
[-p11_certlabel certLabel] [-pwd password]

次のように値を指定します。

- walletでは、ウォレット・ロケーションを指定します。

- p11_libでは、PKCS#11ライブラリへのパスを指定します。これにはライブラリのファイル名が含まれます。

- p11_tokenlabelでは、デバイスで使用されるトークンまたはスマートカードを指定します。これはデバイスに複数のトークンがある場合に使用します。トークンのラベルは、ベンダー・ツールを使用して設定します。

- p11_tokenpwでは、トークンへのアクセスに使用されるパスワードを指定します。トークンのパスワードは、ベンダー・ツールを使用して設定します。

- p11_certlabelは、トークン上の証明書ラベルを指定するために使用します。これはトークンに複数の証明書がある場合に使用します。証明書ラベルはベンダー・ツールを使用して設定します。

- pwdは、ウォレットのパスワードを指定するために使用します。

orapkiを使用した証明書と証明書リクエストのOracleウォレットからのエクスポート

orapkiユーティリティを使用して、Oracleウォレットから証明書および証明書リクエストをエクスポートできます。

- Oracleウォレットから証明書をエクスポートするには、次のコマンドを使用します。

orapki wallet export -wallet wallet_location -dn certificate_dn -cert certificate_filename

このコマンドを使用すると、サブジェクトの識別名(-dn)を持つ証明書が、ウォレットから-certで指定されたファイルにエクスポートされます。

Oracleウォレットから証明書リクエストをエクスポートするには、次のコマンドを使用します。

orapki wallet export -wallet wallet_location -dn certificate_request_dn -request certificate_request_filename

このコマンドを使用すると、サブジェクトの識別名(-dn)を持つ証明書リクエストが、ウォレットから-requestで指定されたファイルにエクスポートされます。

orapkiユーティリティを使用した証明書失効リスト(CRL)の管理

証明書失効リスト(CRL)は、orapkiユーティリティを使用して管理する必要があります。

このユーティリティは、CRL発行者名のハッシュ値を作成して、システム内でCRLの場所を特定します。orapkiを使用しないと、Oracleサーバーは、CRLを探してPKIデジタル証明書を検証することができません。

関連項目:
orapkiを使用したCRLの管理の詳細は、証明書失効リストの管理を参照してください

orapkiの使用方法

Oracleには、いくつかのorapkiコマンドの例が用意されています。

内容は次のとおりです。

- 例: ウォレットおよびユーザー証明書の作成

- 例: 自己署名証明書を含むウォレットおよび証明書のエクスポート

例: 自己署名証明書を含むウォレットおよび証明書のエクスポート

orapki wallet addコマンドは、自己署名証明書を含むウォレットを作成できます。orapki wallet exportは、証明書をエクスポートできます。

例F-1では、自己署名証明書を含むウォレットを作成し、そのウォレットを表示して証明書をファイルにエクスポートする手順を示します。

例F-1 自己署名証明書を含むウォレットの作成と証明書のエクスポート

1. ウォレットを作成します。
例:

c -wallet /private/user/orapki_use/root

ウォレットは、/private/user/orapki_use/rootに作成されます。

2. 自己署名証明書をウォレットに追加します。

orapki wallet add -wallet /private/user/orapki_use/root -dn
'CN=root_test,C=US' -keysize 2048 -self_signed -validity 3650

この結果、3650日の有効期限を持つ自己署名された証明書が作成されます。サブジェクトの識別名はCN=root_test,C=USです。証明書のキー・サイズは2048ビットです。

3. ウォレットを表示します。

orapki wallet display -wallet /private/user/orapki_use/root

これはウォレットに含まれる証明書を表示するために使用します。

4. 証明書をエクスポートします。

orapki wallet export -wallet /private/user/orapki_use/root -dn
'CN=root_test,C=US' -cert /private/user/orapki_use/root/b64certificate.txt

これにより、自己署名証明書がファイルb64certificate.txtにエクスポートされます。使用される識別名はステップ2と同じであることに注意してください。

例: ウォレットおよびユーザー証明書の作成

orapkiユーティリティは、ウォレットおよびユーザー証明書を作成できます。

例F-2では、ユーザー証明書の作成に関連する様々な作業について説明します。

次に、ウォレットの作成、証明書リクエストの作成、証明書リクエストのエクスポート、テスト用のリクエストからの署名付き証明書の作成、証明書の表示、ウォレットへの信頼できる証明書の追加、およびウォレットへのユーザー証明書の追加の手順を示します。

例F-2 ウォレットおよびユーザー証明書の作成

1. 自動ログインが有効なウォレットを作成します。
例:

orapki wallet create -wallet /private/user/orapki_use/server -auto_login

これにより、自動ログインを有効にしたウォレットが/private/user/orapki_use/serverに作成されます。

2. 証明書リクエストをウォレットに追加します。

orapki wallet add -wallet /private/user/orapki_use/server/ewallet.p12 -dn 'CN=server_test,C=US' -keysize 2048

これにより、作成されたウォレット(ewallet.p12)に証明書リクエストが追加されます。サブジェクトの識別名はCN=server_test,C=USです。指定された鍵サイズは2048ビットです。

3. 証明書リクエストをファイルにエクスポートします。

orapki wallet export -wallet /private/user/orapki_use/server -dn 'CN=server_test,C=US' -request /private/user/orapki_use/server/creq.txt

これにより、指定されたファイル(この場合はcreq.txt)に証明書リクエストがエクスポートされます。

4. テスト用のリクエストからの署名付き証明書を作成します。

orapki cert create -wallet /private/user/orapki_use/root -request /private/user/orapki_use/server/creq.txt -cert /private/user/orapki_use/server/cert.txt -validity 3650

これにより、3650日の有効期限を持つ証明書cert.txtが作成されます。証明書は前のステップで生成された証明書リクエストから作成されます。

5. 証明書を表示します。

orapki cert display -cert /private/user/orapki_use/server/cert.txt -complete

これにより、前の手順で生成された証明書が表示されます。-completeオプションでは、シリアル番号や公開鍵などの追加的な証明書情報を表示できます。

6. 信頼できる証明書をウォレットに追加します。

orapki wallet add -wallet /private/user/orapki_use/server/ewallet.p12 -trusted_cert -cert /private/user/orapki_use/root/b64certificate.txt

これにより、信頼できる証明書b64certificate.txtがewallet.p12ウォレットに追加されます。ユーザー証明書を追加する前に、ユーザー証明書の証明連鎖内のすべての信頼できる証明書を追加する必要があります。

7. ユーザー証明書をウォレットに追加します。

orapki wallet add -wallet /private/user/orapki_use/server/ewallet.p12 -user_cert -cert /private/user/orapki_use/server/cert.txt

このコマンドはユーザー証明書cert.txtをewallet.p12ウォレットに追加します。

orapkiユーティリティ・コマンドのサマリー

orapkiコマンドを使用して、多様なタスクを実行できます。

内容は次のとおりです。

- orapki cert create

- orapki cert display

- orapki crl deleteコマンド

- orapki crl display

- orapki crl hash

- orapki crl list

- orapki crl upload

- orapki wallet add

- orapki wallet convert

- orapki wallet create

- orapki wallet display

- orapki wallet export

orapki cert create

orapki cert createコマンドは、テスト用の署名付き証明書を作成します。

構文

orapki cert create [-wallet wallet_location] -request certificate_request_location -cert certificate_location -validity number_of_days [-summary]

- walletは、証明書リクエストへの署名に使用されるユーザー証明書と秘密鍵を含むウォレットを指定します。

- request (必須)は、作成する証明書の証明書リクエストの場所を指定します。

- cert (必須)は、ツールによって新しい署名付き証明書が配置されるディレクトリの場所を指定します。

- validity (必須)は、現在の日付から数えてこの証明書が有効である日数を指定します。

orapki cert display

orapki cert displayコマンドは、特定の証明書の詳細を表示します。

構文

orapki cert display -cert certificate_location [-summary|-complete]

- certは、表示する証明書の場所を指定します。

- -summaryパラメータまたは-completeパラメータのいずれかを使用して、次の情報を表示できます。

- summaryを使用すると、証明書およびその有効期限が表示されます。

- completeを使用すると、シリアル番号、公開鍵などの追加の証明書情報が表示されます。

orapki crl deleteコマンド

orapki crl delete コマンドは、Oracle Internet Directoryから証明書失効リスト(CRL)を削除します。

orapkiを使用してディレクトリからCRLを削除するユーザーは、CRLAdmins(cn=CRLAdmins,cn=groups,%s_OracleContextDN%)ディレクトリ・グループのメンバーである必要があります。

前提条件

なし

構文

orapki crl delete -issuer issuer_name -ldap hostname:ssl_port -user username [-wallet wallet_location] [-summary]

- issuerは、CRLを発行した認証局(CA)の名前を指定します。

- ldapは、CRLを削除するディレクトリのホスト名とSSLポートを指定します。このポートは、認証を使用しないディレクトリのSSLポートであることが必要です。
このポートの詳細は、Oracle Internet DirectoryへのCRLのアップロードも参照してください。

- userは、ディレクトリのCRLサブツリーからCRLを削除する権限のあるディレクトリ・ユーザーのユーザー名を指定します。

- wallet (オプション)は、CRLを発行した認証局(CA)の証明書を含むウォレットの場所を指定します。これを使用すると、CRLをディレクトリから削除する前に、ツールによってCAの証明書に対するCRLの有効性が検証されます。

- summaryはオプションです。削除されたCRL LDAPエントリが表示されます。

orapki crl display

orapki crl displayコマンドは、Oracle Internet Directoryに格納されている指定された証明書失効リスト(CRL)を表示します。

構文

orapki crl display -crl crl_location [-wallet wallet_location] [-summary|-complete]

- crlパラメータは、ディレクトリ内のCRLの場所を指定します。orapki crl listコマンドを使用すると表示されるリストからCRLの位置を貼り付けると便利です。orapki crl listを参照してください。

- wallet (オプション)は、CRLを発行した認証局(CA)の証明書を含むウォレットの場所を指定します。これを使用すると、CRLを表示する前に、ツールによってCAの証明書に対するCRLの有効性が確認されます。

- summaryおよびcompleteは、次の情報を表示します。

- summaryを選択すると、CRL発行者名およびCRLの有効期間を含むリストが表示されます。

- completeを選択すると、そのCRLに含まれるすべての失効した証明書のリストが表示されます。このオプションを選択すると、CRLのサイズによっては、表示に時間がかかる場合があることに注意してください。

orapki crl hash

orapki crl hashコマンドは、証明書失効リスト(CRL)発行者のハッシュ値を生成して、証明書検証用にCRLファイル・システムの場所を特定します。

構文

orapki crl hash -crl crl_filename|URL [-wallet wallet_location] [-symlink|-copy] crl_directory [-summary]

- crlは、CRLまたはCRLがあるURLを含むファイル名を指定します。

- wallet (オプション)は、CRLを発行した認証局(CA)の証明書を含むウォレットの場所を指定します。これを使用すると、CRLをディレクトリにアップロードする前に、ツールによってCAの証明書に対するCRLの有効性が確認されます。

- オペレーティング・システムに応じて、-symlinkパラメータまたは-copyパラメータのいずれかを使用します。

- (UNIX) symlinkは、crl_directoryの場所にCRLへのシンボリック・リンクを作成します。

- (Windows) copyは、crl_directoryの場所にCRLのコピーを作成します。

- summary (オプション)は、CRL発行者の名前を表示します。

orapki crl list

orapki crl listコマンドは、Oracle Internet Directoryに格納されている証明書失効リスト(CRL)のリストを表示します。

構文

特定のCRLを検出してローカル・システムで表示またはダウンロードする際に、このリストを参照すると便利です。

orapki crl list -ldap hostname:ssl_port

ldapは、CRLリストの作成対象のディレクトリ・サーバーのホスト名およびSSLポートを指定します。このポートは、認証を使用しないディレクトリのSSLポートであることが必要です。

関連項目:

このポートの詳細は、Oracle Internet DirectoryへのCRLのアップロードを参照してください

orapki crl upload

orapki crl uploadコマンドは、証明書失効リスト(CRL)をOracle Internet DirectoryのCRLサブツリーにアップロードします。

CRLをディレクトリにアップロードするには、ディレクトリ管理グループCRLAdmins(cn=CRLAdmins,cn=groups,%s_OracleContextDN%)のメンバーである必要があることに注意してください。

構文

orapki crl upload -crl crl_location -ldap hostname:ssl_port -user username [-wallet wallet_location] [-summary]

- crlは、ディレクトリの場所またはディレクトリにアップロードするCRLが配置されているURLを指定します。

- ldapは、CRLのアップロード先のディレクトリのホスト名およびSSLポートを指定します。このポートは、認証を使用しないディレクトリのSSLポートであることが必要です。
このポートの詳細は、Oracle Internet DirectoryへのCRLのアップロードも参照してください。

- userは、ディレクトリのCRLサブツリーにCRLを追加する権限のあるディレクトリ・ユーザーのユーザー名を指定します。

- walletは、CRLを発行した認証局(CA)の証明書を含むウォレットの場所を指定します。これは、オプションのパラメータです。これを使用すると、CRLをディレクトリにアップロードする前に、ツールによってCAの証明書に対するCRLの有効性が確認されます。

- summaryはオプションです。これを使用すると、CRL発行者名、およびCRLがディレクトリに格納されているLDAPエントリが表示されます。

orapki wallet add

orapki wallet addコマンドは、証明書リクエストおよび証明書をOracleウォレットに追加します。

構文

証明書リクエストを追加するには:

orapki wallet add -wallet wallet_location -dn user_dn -keySize 512|1024|2048

- walletは、証明書リクエストの追加先のウォレットの場所を指定します。

- dnは、証明書の所有者の識別名を指定します。

- keysizeは、証明書のキー・サイズを指定します。

- リクエストに署名するには、エクスポート・オプションを使用してそのリクエストをエクスポートします。orapki wallet exportを参照してください

信頼できる証明書を追加するには:

orapki wallet add -wallet wallet_location -trusted_cert -cert certificate_location

- trusted_certは、-certで指定された場所にある信頼できる証明書をウォレットに追加します。

ルート証明書を追加するには:

orapki wallet add -wallet wallet_location -dn certificate_dn -keySize 512|1024|2048 -self_signed -validity number_of_days

- self_signedは、ルート証明書を追加します。

- validityは必須です。これを使用して、現在の日付から数えてこのルート証明書が有効である日数を指定します。

ユーザー証明書を追加するには:

orapki wallet add -wallet wallet_location -user_cert -cert certificate_location

- user_certは、-certパラメータで指定された場所にあるユーザー証明書をウォレットに追加します。ユーザー証明書をウォレットに追加する前に、証明連鎖を構成するすべての信頼できる証明書を追加する必要があります。ユーザー証明書を追加する前に、すべての信頼できる証明書がウォレットに追加されていない場合、ユーザー証明書の追加は失敗します。

orapki wallet convert

orapki wallet convertコマンドは、Oracleウォレットで3DESアルゴリズムを変換して、AES256アルゴリズムを使用します。

構文

orapki wallet convert -wallet wallet_location [-pwd password] [-compat_v12]

- walletには、新しいウォレットの場所または自動ログインを有効にするウォレットの場所を指定します。

- pwdはウォレット・パスワードです。

- compat_v12は、3DESからAES256への変換を行います。

orapki wallet create

orapki wallet createコマンドは、Oracleウォレットを作成またはOracleウォレットの自動ログインを有効化します。

構文

orapki wallet create -wallet wallet_location [-auto_login|-auto_login_local]

- walletには、新しいウォレットの場所または自動ログインを有効にするウォレットの場所を指定します。

- auto_loginにより、自動ログイン・ウォレットが作成されるか、または、-walletオプションで指定されたウォレットの自動ログインが有効になります。
自動ログイン・ウォレットの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- auto_login_localにより、ローカル自動ログイン・ウォレットが作成されるか、または、-walletオプションで指定されたウォレットのローカル自動ログインが有効になります。

orapki wallet display

orapki wallet displayコマンドは、Oracleウォレット内の証明書リクエスト、ユーザー証明書および信頼できる証明書を表示します。

構文

orapki wallet display -wallet wallet_location

- walletは、開くウォレットの場所を指定します(そのウォレットが現在の作業ディレクトリにない場合)。

orapki wallet export

orapki wallet exportコマンドは、証明書リクエストおよび証明書をOracleウォレットからエクスポートします。

構文

証明書をOracleウォレットからエクスポートするには:

orapki wallet export -wallet wallet_location -dn certificate_dn -cert certificate_filename

- walletは、証明書のエクスポート元のウォレットの場所を指定します。

- dnは、証明書の識別名を指定します。

- certは、エクスポートされる証明書を含むファイルの名前を指定します。

証明書リクエストをOracleウォレットからエクスポートするには:

orapki wallet export -wallet wallet_location -dn certificate_request_dn -request certificate_request_filename

- requestは、エクスポートされる証明書リクエストを含むファイルの名前を指定します。

G 統合監査の移行による各監査機能への影響

統合監査を移行する前に、Oracle Database 12cリリース1(12.1)より前のほとんどの監査機能を使用できます。

表G-1では、移行によるOracle Database 12cより前の監査機能の変更内容について説明します。

表G-1 移行前後での統合監査機能の可用性

機能

移行前の環境での可用性

移行後の環境での可用性

一般的な監査機能

-

-

オペレーティング・システム監査証跡

○

×

XMLファイル監査証跡

○

×

ネットワーク監査

○

×

ユーザーが監査および監査を独自のスキーマ・オブジェクトから削除できるかどうか

○

×

監査の管理アクションの必須の監査

×

○

ロールの監査

AUDIT_ADMIN

○(ただし、自身のオブジェクトを監査するユーザー、またはALTER SYSTEM権限がすでにあり、監査初期化パラメータを変更するユーザーには不要)

○

AUDIT_VIEWER

○

○

システム表

-

-

SYS.AUD$

○

○(ただし、統合前の監査レコードのみを含む)

SYS.FGA_LOG$

○

○(ただし、統合前の監査レコードのみを含む)

初期化パラメータ

AUDIT_TRAIL

○

○(ただし、影響はない)

AUDIT_FILE_DEST

○

○(ただし、影響はない)

AUDIT_SYS_OPERATIONS

○

○(ただし、影響はない)

AUDIT_SYSLOG_LEVEL

○

○(ただし、影響はない)

UNIFIED_AUDIT_SGA_QUEUE_SIZE

○

○

データ・ディクショナリ・ビュー 脚注1

-

-

ALL_AUDIT_POLICIES

○

○(ただし、DBMS_FGA PL/SQLパッケージを使用してファイングレイン監査ポリシーが作成される場合のみ)

DBA_AUDIT_POLICIES

○

○(ただし、DBMS_FGA PL/SQLパッケージを使用してファイングレイン監査ポリシーが作成される場合のみ)

DBA_AUDIT_POLICY_COLUMNS

○

○(ただし、DBMS_FGA PL/SQLパッケージを使用してファイングレイン監査ポリシーが作成される場合のみ)

DBA_COMMON_AUDIT_TRAIL

○

○(ただし、統合前の監査レコードのみを含む)

DBA_AUDIT_EXISTS

○

○

DBA_AUDIT_OBJECT

○

○

DBA_AUDIT_POLICIES

○

○(ただし、DBMS_FGA PL/SQLパッケージを使用してファイングレイン監査ポリシーが作成される場合のみ)

DBA_AUDIT_POLICY_COLUMNS

○

○(ただし、DBMS_FGA PL/SQLパッケージを使用してファイングレイン監査ポリシーが作成される場合のみ)

DBA_AUDIT_SESSION

○

○(ただし、統合前の監査レコードのみを含む)

DBA_AUDIT_STATEMENT

○

○(ただし、統合前の監査レコードのみを含む)

DBA_AUDIT_TRAIL

○

○(ただし、統合前の監査レコードのみを含む)

DBA_FGA_AUDIT_TRAIL

○

○(ただし、統合前の監査レコードのみを含む)

DBA_OBJ_AUDIT_OPTS

○

○

DBA_PRIV_AUDIT_OPTS

○

○

DBA_STMT_AUDIT_OPTS

○

○

UNIFIED_AUDIT_TRAIL

○(ただし、監査レコードは収集しない)

○(監査レコードを収集する)

USER_AUDIT_OBJECT

○

○

USER_AUDIT_POLICY_COLUMN

○

○(ただし、DBMS_FGA PL/SQLパッケージを使用してファイングレイン監査ポリシーが作成される場合のみ)

USER_AUDIT_POLICIES

○

○(ただし、DBMS_FGA PL/SQLパッケージを使用してファイングレイン監査ポリシーが作成される場合のみ)

USER_AUDIT_SESSION

○

○

USER_AUDIT_STATEMENT

○

○

USER_AUDIT_TRAIL

○

○(ただし、統合前の監査レコードのみを含む)

USER_OBJ_AUDIT_OPTS

○

○

V$XML_AUDIT_TRAIL

○

○(ただし、統合前の監査レコードのみを含む)

CREATE AUDIT POLICY、ALTER AUDIT POLICYおよびDROP AUDIT POLICY文

文は使用できますが、監査ポリシーは古い監査証跡に書き込まれません。ポリシーが有効な場合、監査レコードは統合監査証跡に書き込まれます。

○(ただし、監査証跡を統合監査証跡のみに書き込む)

AUDIT文およびNOAUDIT文

-

-

AUDIT

○(マルチテナント環境で使用可能)

○(ただし、監査ポリシーを有効化、アプリケーション・コンテキスト監査設定を作成、成功または失敗(あるいは両方)時に監査レコードを作成、およびマルチテナント環境で使用できるように拡張)

NOAUDIT

○(マルチテナント環境で使用可能)

○(ただし、監査ポリシーを無効化、アプリケーション・コンテキスト監査設定を無効化、およびマルチテナント環境で使用できるように変更)

DBMS_FGA.ADD_POLICYプロシージャ・パラメータ

-

-

audit_trail

○(以前のリリースで使用)

○(ただし、すべてのレコードが統合監査証跡に書き込まれるため、統合監査が有効な場合は、このパラメータを省略可能)

DBMS_AUDIT_MGMTパッケージのAUDIT_TRAIL_TYPEプロパティ・オプション

-

-

DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD

○

○(ただし、統合前の監査レコードのみ)

DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD

○

○(ただし、統合前の監査レコードのみ)

DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD

○

○(ただし、統合前の監査レコードのみ)

DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS

○

○(ただし、統合前の監査レコードのみ)

DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML

○

○(ただし、統合前の監査レコードのみ)

DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES

○

○(ただし、統合前の監査レコードのみ)

DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL

○

○(ただし、統合前の監査レコードのみ)

Oracle Database Vault機能

-

-

DVSYS.AUDIT_TRAIL$システム表

○

名前をDVSYS.OLD_AUDIT_TRAIL$に変更し、古い監査レコードを保持しています。前のDVSYS.AUDIT_TRAIL$表はDVSYS.AUDIT_TRAIL$という名前のビューに変更されています。新しい監査レコードは追加されません。

Oracle Label Security機能

-

-

SA_AUDIT_ADMIN PL/SQLパッケージ

○

×

脚注1

これらのデータ・ディクショナリ・ビューには、SYS.AUD$システム表およびSYS.FGA_LOG$システム表に存在する監査レコードの監査データが引き続き表示されます。統合監査証跡レコードは、統合監査証跡固有のビューにのみ表示されます。先頭がUSER_でないビューを問い合せるには、AUDIT_ADMINまたはAUDIT_VIEWERロールを付与する必要があります。

用語集

アクセス制御

特定のクライアントまたはクライアント・グループに対して特定のデータへのアクセス権を付与または制限するシステム機能。

アクセス制御リスト(ACL)

管理者が定義するアクセス・ディレクティブのグループ。ディレクティブは、特定のクライアント、クライアント・グループまたはその両方に対して特定のデータへのアクセスのレベルを付与します。

Advanced Encryption Standard

Advanced Encryption Standard(AES)は、National Institute of Standards and TechnologyによってDESを置換するものとして承認された新しい暗号アルゴリズムです。AES標準は、Federal Information Processing Standards Publication 197で使用可能です。AESアルゴリズムは、128、192および256ビットの長さの暗号鍵を使用して、128ビットのデータ・ブロックを処理できる対称型ブロック暗号です。

AES

「Advanced Encryption Standard」を参照してください。

アプリケーション・コンテキスト

名前と値のペア。このペアによって、アプリケーションは、ユーザーに関するセッション情報(ユーザーIDや他のユーザー固有の情報など)にアクセスして、その情報をデータベースに安全に引き渡すことができます。

「グローバル・アプリケーション・コンテキスト」も参照してください。

属性

LDAPディレクトリ内のエントリの性質を説明する情報項目。1つのエントリは1組の属性から構成され、それぞれがオブジェクト・クラスに所属します。さらに、各属性にはタイプと値があり、タイプは属性の情報の種類を説明し、値には実際のデータが格納されています。

アプリケーション・ロール

アプリケーション・ユーザーに付与されるデータベース・ロール。アプリケーション内に埋め込まれているパスワードによって保護されています。

「セキュア・アプリケーション・ロール」も参照してください。

認証

コンピュータ・システムのユーザー、デバイスまたはその他のエンティティの識別情報を検証するプロセスであり、システムのリソースへのアクセス権を付与するための前提条件となることが多いです。認証されたメッセージの受信者は、そのメッセージの発信元(送信側)を確認できます。認証は、第三者が送信者を装っている可能性を排除するものとみなされます。

認証方式

分散環境のユーザー、クライアントまたはサーバーの識別情報を検証するセキュリティ方式。ネットワーク認証方式では、ユーザーにシングル・サイン・オン(SSO)の利点も提供できます。次の認証方式がサポートされています:

- Kerberos

- RADIUS

- Secure Socket Layer(SSL)

- Windowsネイティブ認証

認可

オブジェクトまたはオブジェクトのセットにアクセスするためにユーザー、プログラムまたはプロセスに付与される権限。Oracleでは、認可はロール・メカニズムを通じて行われます。1人のユーザーまたはユーザー・グループに対して、1つのロールまたは一連のロールを付与できます。また、ロールに他のロールを付与することもできます。認証されたエンティティが利用できる権限のセット。

自動ログイン・ウォレット

アクセス時に資格証明を発行しない、サービスへのパスワードベースのアクセスです。自動ログイン・アクセスは、自動ログイン機能がウォレットに対して無効になるまで有効です。ファイル・システム権限では、ウォレットの自動ログインに必要なセキュリティが提供されます。ウォレットに対して自動ログインが有効になっている場合は、そのウォレットを作成したオペレーティング・システム・ユーザーのみ、そのウォレットを使用できます。これらはシングル・サイン・オン機能を提供するため、SSOウォレットと呼ばれることもあります。

CDB

マルチテナント・コンテナ・データベース。1つのルートと0(ゼロ)個以上のプラガブル・データベース(PDB)を含むOracle Databaseインストール。すべてのOracle Databaseは、CDBか非CDBのいずれかです。

ベース

LDAP準拠ディレクトリでのサブツリー検索のルート。

CA

「認証局」を参照してください。

証明書

公開鍵に対して識別情報を安全にバインドするITUのx.509 v3標準データ構造。

証明書は、エンティティの公開鍵が、信頼されている機関(認証局)によって署名されたときに作成されます。この証明書は、そのエンティティの情報が正しいこと、および公開鍵がそのエンティティに属していることを保証します。

証明書にはエンティティの名前、認証情報および公開鍵が含まれます。また、証明書に関する権利、ユーザーおよび権限についてのシリアル番号、有効期限、その他の情報が含まれる場合もあります。さらに、発行元の認証局についての情報も含まれます。

認証局

他のエンティティ(ユーザー、データベース、管理者、クライアント、サーバー)が本物であることを証明する、信頼できる第三者。ユーザーを証明するとき、認証局は最初にそのユーザーが証明書失効リスト(CRL)に掲載されていないことを確認してからそのユーザーのアイデンティティを検証し、証明書を付与し、認証局の秘密鍵を使用してその証明書に署名します。認証局には自身の証明書と公開鍵があり、公開されています。サーバーおよびクライアントは、これらを使用して認証局の署名を検証します。認証局は、証明書サービスを提供する外部の会社の場合や、企業のMIS部門のような内部の組織の場合があります。

証明連鎖

エンド・ユーザーまたはサブスクライバの証明書とその認証局証明書を含む順序付きの証明書リスト。

証明書リクエスト

認証リクエスト情報、署名アルゴリズム識別子および認証リクエスト情報に対するデジタル署名の3つの部分から構成される証明書リクエスト。認証リクエスト情報は、対象の識別名、公開鍵およびオプションの属性セットから構成されます。属性では、対象の識別情報に関する郵便番号などの追加情報、または対象エンティティが後で証明書失効を要求するためのチャレンジ・パスワードを提供できます。「PKCS #10」を参照してください。

証明書失効リスト(CRL)

(CRL)失効した証明書 のリストを含む署名付きデータ構造。CRLの信頼性および整合性は、証明書に添付されているデジタル署名により提供されます。CRL署名者は通常、発行された証明書に署名したエンティティと同一です。

チェックサム

メッセージ・パケットに含まれているデータに基づいてメッセージ・パケットの値を計算し、その値をデータとともに渡して、データが書き換えられていないことを認証するメカニズム。データの受信者は暗号チェックサムを再計算して、それをデータとともに送られた暗号チェックサムと比較します。これらが一致している場合は、データが送信中に書き換えられなかったことの確率的な証明になります。

クリアテキスト

暗号化されていないプレーン・テキスト。

暗号ブロック連鎖(CBC)

暗号化メソッドの1つ。先行するすべてのブロックに従って暗号ブロックの暗号化を行い、ブロック再生攻撃からデータを保護します。無許可の復号化が段階的に困難になるように設計されています。Oracle Databaseでは、外部暗号ブロック連鎖が使用されています。これは、内部暗号ブロックよりも安全性が高く、実質的なパフォーマンスの低下を伴わないためです。

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までのサブネットを示します。

暗号スイート

ネットワーク・ノード間でメッセージを交換するために使用される認証、暗号化およびデータ整合性のアルゴリズムのセット。たとえば、SSLハンドシェイク中に2つのノードがネゴシエーションして、メッセージの送受信中に使用する暗号スイートを確認します。

暗号スイート名

暗号スイートは、特定のセッションで接続により使用される暗号保護の種類を示します。

暗号文

暗号化されたメッセージ・テキスト。

クラスレス・ドメイン間ルーティング

「CIDR」を参照してください。

クライアント

サービスを利用する側。クライアントはユーザーの場合や、データベース・リンク中にユーザーとして機能するプロセス(プロキシともいう)の場合があります。

共通権限付与

共通ユーザーが、他の共通ユーザーまたは共通ロールに付与する権限。共通権限付与は、システム権限またはオブジェクト権限のいずれかで、CDBのすべてのPDBに適用されます。

「ローカル権限付与」も参照。

共通ロール

CDB内のすべてのコンテナに存在するロール。

共通ユーザー

CDBで、既存および将来のすべてのPDBに同じIDで存在するデータベース・ユーザー。

機密保護

暗号化の機能。機密保護によって、メッセージを参照(暗号文を復号化する)できるのはメッセージの本来の受信者のみであることが保証されます。

接続記述子

特別にフォーマットされた、ネットワーク接続のための宛先の記述。接続記述子には、接続先のサービスおよびネットワーク・ルート情報が含まれます。接続先サービスは、Oracle9i またはOracle8i データベースのサービス名か、Oracleデータベース・リリース8.0のOracle システム識別子(SID)を使用して指定されます。ネットワーク・ルートは、少なくとも、ネットワーク・アドレスを使用してリスナーの場所を示します。「接続識別子」を参照。

接続識別子

接続記述子を解決する名前、ネット・サービス名またはサービス名。次のように、ユーザーは、接続するサービスに対して、接続文字列内の接続識別子とともにユーザー名とパスワードを渡して、接続要求を実行します。

例:

CONNECT username@connect_identifier
Enter password: password

接続文字列

ユーザー名、パスワード、ネット・サービス名など、ユーザーが接続先のサービスに渡す情報。例:

CONNECT username@net_service_name
Enter password: password

コンテナ

CDBで、ルートまたはPDB。

コンテナ・データ・オブジェクト

CDBでは、複数のコンテナと場合によってはCDB全体に関連するデータを、そのようなオブジェクトで特定の共通ユーザーに表示されるデータを1つ以上のコンテナに制限するメカニズムとともに格納する表またはビューです。コンテナ・データ・オブジェクトの例は、Oracle提供のビューで、その名前はV$およびCDB_で始まります。

資格証明

データベースにアクセスするために使用するユーザー名、パスワードまたは証明書。

CRL

「証明書失効リスト(CRL)」を参照。

CRL配布ポイント

(CRL DP) X.509バージョン3証明書標準で指定されるオプションの拡張子であり、証明書の失効情報が格納される区分CRLの位置を示します。通常、この拡張子の値はURLの形式です。CRL DPによって、1つの認証局ドメイン内の失効情報を複数のCRLにポストできます。CRL DPによって、失効情報はより管理しやすい部分に細分化され、CRLが膨大に増加するのが回避されるため、パフォーマンスが向上します。たとえば、CRL DPを証明書に指定し、その証明書の失効情報をダウンロードできる、Webサーバー上のファイルを指すようにできます。

CRL DP

「CRL配布ポイント」を参照してください。

暗号化

データのエンコーディングおよびデコーディング処理であり、メッセージを保全します。

データ・ディクショナリ

データベースに関する情報を提供する読取り専用の表のセット。

Data Encryption Standard (DES)

米国連邦情報処理標準の古い暗号化アルゴリズムであり、Advanced Encryption Standard (AES)に置き換えられました。

データベース管理者

(1)Oracleサーバーまたはデータベース・アプリケーションを操作および管理する個人。(2)DBA権限を付与され、データベース管理機能を実行できるOracleユーザー名。通常、これら2つを同時に意味します。多くのサイトでは複数のDBAが配置されます。

データベース別名

「ネット・サービス名」を参照してください。

データベース・インストール管理者

データベース作成者とも呼ばれます。この管理者は、新規データベースの作成を担当します。この作業には、Database Configuration Assistantを使用したディレクトリへの各データベースの登録が含まれます。この管理者は、データベース・サービス・オブジェクトおよび属性の作成および変更アクセス権を持ちます。この管理者は、デフォルトのドメインも変更できます。

データベース・リンク

ローカル・データベースまたはネットワーク定義に格納されるネットワーク・オブジェクトであり、リモート・データベース、そのデータベースへの通信パス、およびオプションでユーザー名とパスワードを識別します。定義された後、データベース・リンクはリモート・データベースへのアクセスに使用されます。

あるデータベースから別のデータベースへのパブリックまたはプライベート・データベース・リンクは、DBAまたはユーザーによってローカル・データベースに作成されます。

グローバル・データベース・リンクは、Oracle Namesで各データベースからネットワーク内の他のすべてのデータベースに自動的に作成されます。グローバル・データベース・リンクはネットワーク定義に格納されます。

データベース・パスワード・バージョン

ユーザーのデータベース・パスワードから導出された取消しできない値。パスワード・ベリファイアとも呼ばれます。この値は、データベースに対するパスワード認証時に、接続ユーザーの識別情報が正しいことを確認するために使用されます。

データベース・セキュリティ管理者

データベース・エンタープライズ・ユーザー・セキュリティの最上位レベルの管理者。この管理者は、すべてのエンタープライズ・ドメインに対する権限を持ち、次のことに責任を持ちます。

- Oracle DBSecurityAdminsおよびOracleDBCreatorsグループの管理

新規エンタープライズ・ドメインの作成。

- エンタープライズ内のあるドメインから別のドメインへのデータベースの移動

復号化

暗号化されたメッセージ(暗号文)の内容を元どおり読める形式(平文)に変換する処理です。

定義者権限プロシージャ

現行ユーザーではなく、所有者の権限で実行されるプロシージャ(プログラム・ユニット)。定義者権限サブプログラムは、これらのサブプログラムが格納されるスキーマにバインドされます。

たとえば、ユーザーblakeとユーザーscottのそれぞれがdeptという名前の表を、それぞれのユーザー・スキーマの中に持っています。ユーザーblakeがdept表を更新するためにユーザーscottが所有している定義者権限プロシージャをコールすると、このプロシージャはdept表をscottスキーマで更新します。これは、プロシージャはプロシージャを所有している(定義した)ユーザー(つまりscott)の権限で実行するためです。

「実行者権限プロシージャ」も参照してください。

DES

「Data Encryption Standard(DES)」を参照してください。

辞書攻撃

パスワードに対する一般的な攻撃。攻撃者は、多数の一般的なパスワードのリストを作成し、それらを暗号化します。次に、攻撃者は暗号化されたパスワードを含むファイルを盗み、暗号化した一般的なパスワードのリストと比較します。暗号化したパスワードの値(ベリファイアと呼ばれる)のいずれかが一致した場合、攻撃者は対応するパスワードを盗むことができます。辞書攻撃は、暗号化の前にパスワードにsaltを使用することで回避できます。「salt」を参照してください。

Diffie-Hellman鍵交換アルゴリズム

これは、安全でないチャネルを通じて通信する2つのパーティに、それらのパーティのみが知っているランダムな数字を合意させる方法です。Diffie-Hellman鍵交換アルゴリズムの実行中は、当事者は非保護チャネルで情報を交換しますが、攻撃者がネットワーク通信を分析し、当事者の間で取り決めた乱数を計算によって推定するのはほぼ不可能です。Oracle Databaseでは、セッション鍵の生成にDiffie-Hellman鍵交換アルゴリズムが使用されています。

デジタル署名

デジタル署名は、公開鍵アルゴリズムを使用して送信者の秘密鍵で送信者のメッセージに署名するために使用されます。このデジタル署名によって、文書が信頼できるものであること、別のエンティティで偽造されていないこと、変更されていないこと、送信者によって拒否されないことが保証されます。

ディレクトリ情報ツリー(DIT)

LDAPディレクトリ内のエントリのDNから構成される階層ツリー型構造。「識別名(DN)」を参照してください。

ディレクトリ・ネーミング

中央ディレクトリ・サーバーに格納されているデータベース・サービス、ネット・サービス名またはネット・サービス別名を接続記述子に解決するネーミング・メソッドです。A

ディレクトリ・ネーミング・コンテキスト

ディレクトリ・サーバー内で意味を持つサブツリー。通常は、組織サブツリーの最上位です。あるディレクトリでは、固定のこのようなコンテキストが1個のみ許可されますが、他のディレクトリでは、ディレクトリ管理者によって0個から多数までのコンテキストを構成できます。

識別名(DN)

ディレクトリ・エントリの一意の名前。親エントリからディレクトリ情報ツリーのルート・エントリまでのすべての個々の名前から構成されます。「ディレクトリ情報ツリー(DIT)」を参照してください。

ドメイン

ドメイン・ネーム・システム(DNS)ネームスペース内の任意のツリーまたはサブツリー。一般にドメインは、ホスト名が共通の接尾辞(ドメイン名)を共有するコンピュータのグループを表します。

ドメイン・ネーム・システム(DNS)

ドメインの階層に編成された、コンピュータおよびネットワーク・サービスのネーミングのためのシステム。DNSは、TCP/IPネットワークで使用され、ユーザー・フレンドリな名前でコンピュータの位置を識別します。DNSは、このわかりやすい名前を、コンピュータが理解できるIPアドレスに変換します。

Oracle Net Servicesでは、DNSはTCP/IPアドレスのホスト名をIPアドレスに変換します。

サービス拒否(DoS)攻撃

Webサイトをアクセス不能または使用不能にする攻撃。サービス拒否攻撃は様々な手法で行われますが、よく利用される攻撃手法としては、サイトをクラッシュさせるもの、サイトへの接続を拒否するもの、または低速化によりサイトを使用不能にするものがあります。DoS攻撃には、次の2つの形式があります。

- 基本サービス拒否攻撃(1台のみまたは数台のコンピュータが必要)

- 分散型DoS攻撃(多数のコンピュータの実行が必要)

直接付与されたロール

間接的に付与されたロールとは対照的に、ユーザーに直接付与されたロール。

暗号化テキスト

暗号化アルゴリズムを使用して暗号化されたテキスト。暗号化プロセスの出力ストリーム。最初に復号化の対象とならないかぎり、そのままでは読取りまたは解読できません。暗号文とも呼ばれます。暗号化テキストは、最終的には平文になります。

暗号化

メッセージを宛先の受信者以外の第三者が判読できない書式に変換すること。

エンタープライズ・ドメイン

データベースとエンタープライズ・ロールのグループで構成されたディレクトリ構造。1つのデータベースが同時に複数のエンタープライズ・ドメイン内に存在することはありません。エンタープライズ・ドメインは、共通ディレクトリ・データベースを共有するコンピュータの集合であるWindows 2000ドメインとは異なります。

エンタープライズ・ドメイン管理者

新規エンタープライズ・ドメイン管理者を追加する権限を含め、特定のエンタープライズ・ドメインの管理を認可されたユーザー。

エンタープライズ・ロール

エンタープライズ・ユーザーに割り当てられるアクセス権限。エンタープライズ・ドメイン内の1つ以上のデータベースに対する、一連のOracleロールに基づく認可。エンタープライズ・ロールは、ディレクトリに格納され、1つ以上のグローバル・ロールが含まれています。

エンタープライズ・ユーザー

ディレクトリで定義および管理されるユーザー。各エンタープライズ・ユーザーは、企業内で固有の識別情報を保持します。

エントリ

ディレクトリの基本要素であり、ディレクトリ・ユーザーに関係するオブジェクトに関する情報を含みます。

外部認証

KerberosやRADIUSなどのサード・パーティ認証サービスによるユーザー識別情報の検証。

米国連邦情報処理標準(FIPS)

暗号化モジュールのセキュリティ要件を定義する米国連邦政府の標準であり、コンピュータおよびテレコミュニケーション・システム内の非機密情報を保護するセキュリティ・システムで使用されます。米国商務省国立標準技術研究所(NIST)によって発行されます。

FIPS

「米国連邦情報処理標準(FIPS)」を参照してください。

強制クリーン・アップ

すべての監査レコードをデータベースから強制的にクリーン・アップ(つまり、削除)するための機能。この処理を行うには、DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILプロシージャのUSE_LAST_ARCH_TIMESTAMP引数をFALSEに設定します。

「削除ジョブ」も参照してください。

フォレスト

相互に信頼する1つ以上のActive Directoryツリーのグループ。フォレスト内のすべてのツリーは、共通のスキーマ、構成およびグローバル・カタログを共有します。フォレストに複数のツリーが含まれる場合、ツリーは連続したネームスペースを形成しません。指定フォレスト内のすべてのツリーは、推移的な双方向の信頼関係を介して相互に信頼します。

転送可能なチケット認可チケット

プロキシに転送できる特殊なKerberosチケット。プロキシ認証用に、プロキシはクライアントにかわって追加Kerberosチケットを取得することが許可されます。

「Kerberosチケット」も参照してください。

グローバル・ロール

ディレクトリで管理されるロールですが、その権限は単一のデータベースに含まれています。グローバル・ロールは、次の構文を使用してデータベースに作成されます。

CREATE ROLE role_name IDENTIFIED GLOBALLY;

グローバル・アプリケーション・コンテキスト

アプリケーション・コンテキスト値を複数のデータベース・セッションにわたってアクセス可能にする名前と値のペア。

「アプリケーション・コンテキスト」も参照してください。

グリッド・コンピューティング

多くのサーバーと記憶域を調整して単一の大容量コンピュータとして動作させるコンピューティング・アーキテクチャ。Oracle Grid Computingは、柔軟性のあるオンデマンド・コンピューティング・リソースをすべてのエンタープライズ・コンピューティング・ニーズに対して作成します。Oracle Databaseグリッド・コンピューティング・インフラストラクチャで稼働しているアプリケーションは、フェイルオーバー、ソフトウェア・プロビジョニングおよび管理のための共通インフラストラクチャ・サービスを利用できます。Oracle Grid Computingは、リソースの需要を分析し、それに応じて供給を調整します。

HTTP

Hypertext Transfer Protocol: World Wide Web上でのファイル(テキスト、グラフィック・イメージ、サウンド、ビデオおよびその他のマルチメディア・ファイル)の交換に関するルールのセット。TCP/IPプロトコル・スイート(インターネット上での情報交換の基礎)に関して、HTTPはアプリケーション・プロトコルです。

HTTPS

標準のHTTPアプリケーション・レイヤーのサブレイヤーとしてSSL(Secure Sockets Layer)を使用したプロトコル。

間接的に付与されたロール

ユーザーにすでに付与されている別のロールを通じてこのユーザーに付与されるロールのことです。その後、role2ロールとrole3ロールをrole1ロールに付与します。これで、role2とrole3の2つのロールは、role1に含まれることになります。つまり、psmithには、直接付与されたrole1に加え、role2ロールとrole3ロールが間接的に付与されたことになります。psmithに対して、直接付与されたロールrole1を使用可能にすると、間接的に付与されたロールrole2およびrole3も同様に使用可能になります。

識別情報

公開鍵と、エンティティに関するその他の任意のパブリック情報の組合せ。パブリック情報には、電子メール・アドレスなどのユーザー識別データを含めることができます。宣言どおりのエンティティとして証明されているユーザー。

ID管理

オンライン、すなわちデジタルなエンティティの作成、管理および使用。ID管理には、デジタル識別情報の作成(デジタル識別情報のプロビジョニング)から、メンテナンス(電子リソースへのアクセスに関する組織ポリシーの施行)、さらに最終的な終了までのライフ・サイクル全体の安全な管理が含まれます。

ID管理レルム

Oracle Internet Directoryのサブツリーであり、Oracleコンテキストのみでなく、それぞれアクセス制御リストで保護されているユーザーおよびグループの追加サブツリーも含みます。

初期チケット

Kerberos認証では、初期チケットまたはチケット認可チケット(TGT)によって、ユーザーが追加のサービス・チケットを要求する権利を持つものとして識別されます。初期チケットがないと、他のチケットは取得できません。初期チケットは、okinitプログラムを実行し、パスワードを提供することで取得されます。

インスタンス

稼働中のすべてのOracleデータベースは、Oracleインスタンスに関連付けられています。(コンピュータのタイプに関係なく)データベースがデータベース・サーバー上で起動すると、Oracleによってシステム・グローバル領域(SGA)というメモリー領域が割り当てられ、Oracleプロセスが起動します。このSGAとOracleプロセスの組合せをインスタンスと呼びます。インスタンスのメモリーおよびプロセスは、関連付けられているデータベースのデータを効率的に管理し、1人以上のデータベース・ユーザーを処理します。

整合性

受信したメッセージの内容が、送信された元のメッセージの内容から変更されていないという保証。

実行者権限プロシージャ

現行ユーザー、つまりプロシージャを起動するユーザーの権限で実行されるプロシージャ(プログラム・ユニット)。これらのプロシージャは、特定のスキーマにバインドされません。このプロシージャは様々なユーザーが実行でき、これによって、複数のユーザーが、集中化したアプリケーション・ロジックを使用してそれぞれのデータを管理できます。実行者権限プロシージャは、プロシージャ・コードの宣言セクションにあるAUTHID句を使用して作成されます。

たとえば、ユーザーblakeとユーザーscottのそれぞれがdeptという名前の表を、それぞれのユーザー・スキーマの中に持っています。ユーザーblakeがdept表を更新するためにユーザーscottが所有している実行者権限プロシージャをコールすると、このプロシージャはdept表をblakeスキーマで更新します。これは、プロシージャはプロシージャを起動したユーザー(つまりblake)の権限で実行するためです。

「定義者権限プロシージャ」も参照してください。

Javaコードの不明瞭化

Javaコードの不明瞭化は、Javaプログラムをリバース・エンジニアリングから保護するために使用されます。特別なプログラム(obfuscator)を使用して、コードに見つかったJavaシンボルをスクランブルします。プロセスは、元のプログラム構造をそのまま保持し、意図した動作を隠すためにクラス、メソッドおよび変数の名前を変更する一方でプログラムを正常に実行します。不明瞭化されていないJavaコードをデコンパイルして読み取ることは可能ですが、不明瞭化されたJavaコードのデコンパイルは、米国政府の輸出規制を満たすのに十分なほど困難になっています。

Java Database Connectivity(JDBC)

Javaプログラムからリレーショナル・データベースに接続するための業界標準のJavaインタフェース。Sun Microsystemsが定義しました。

JDBC

「Java Database Connectivity(JDBC)」を参照してください。

KDC

Key Distribution Center (KDC)を参照。

Kerberos

Massachusetts Institute of TechnologyのAthenaプロジェクトで開発されたネットワーク認証サービスであり、分散環境でのセキュリティを強化します。Kerberosは信頼できるサード・パーティ認証システムであり、共有秘密鍵に基づき、サード・パーティがセキュアであることを前提とします。シングル・サインオン機能とデータベース・リンク認証(MIT Kerberosのみ)があり、パスワードを一元的に保管してPCのセキュリティを強化します。

Kerberosチケット

特定サービスに関するクライアントの識別情報を検証する一時的な電子資格証明。サービス・チケットとも呼ばれます。

Key Distribution Center (KDC)

Kerberos認証では、KDCはユーザー・プリンシパルのリストを管理し、ユーザーの初期チケットに関してkinit(okinitはOracleバージョン)プログラムを通じてアクセスされます。KDCおよびチケット認可サービスが同じエンティティに結合されることが多いですが、その場合もKDCと呼ばれます。チケット認可サービスは、サービス・プリンシパルのリストを管理し、このようなサービスを提供するサーバーに対してユーザーの認証が必要な場合にアクセスされます。KDCは、セキュア・ホストで実行する必要のある信頼できるサード・パーティです。チケット認可チケットおよびサービス・チケットを作成します。

「Kerberosチケット」も参照してください。

鍵のペア

公開鍵とそれに対応する秘密鍵。「公開鍵と秘密鍵のペア」を参照。

keytabファイル

1つ以上のサービス・キーを含むKerberosキー表ファイル。キー表ファイルは、ユーザーが各自のパスワードを使用する場合と同様に、ホストまたはサービスで使用されます。

kinstance

Kerberos認証されたサービスのインスタンス化または場所。これは、任意の文字列ですが、通常はサービスのホスト・コンピュータ名を指定します。

kservice

Kerberosサービス・オブジェクトの任意の名前。

最終アーカイブ・タイムスタンプ

監査レコードが最後にアーカイブされた時間を示すタイムスタンプ。データベース監査証跡の場合、このタイムスタンプは、最後にアーカイブされた監査レコードを示します。オペレーティング・システム監査ファイルの場合、このタイムスタンプは、アーカイブされた監査ファイルの最終変更タイムスタンプ・プロパティを示します。このタイムスタンプを設定するには、DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP PL/SQLプロシージャを使用します。

「削除ジョブ」も参照してください。

LDAP

「Lightweight Directory Access Protocol(LDAP)」を参照してください。

ldap.oraファイル

次のディレクトリ・サーバー・アクセス情報を含むファイル。Oracle Net Configuration Assistantによって作成されます。

- ディレクトリ・サーバーのタイプ

- ディレクトリ・サーバーの場所

- クライアントまたはサーバーで使用するデフォルトのID管理レルムまたはOracleコンテキスト(ポートを含む)

Lightweight Directory Access Protocol (LDAP)

標準の拡張可能ディレクトリ・アクセス・プロトコル。LDAPクライアントおよびサーバーが通信に使用する共通言語です。Oracle Internet Directoryなど、業界標準のディレクトリ製品をサポートする設計規則のフレームワーク。

リスナー

サーバー上のプロセスであり、着信クライアント接続要求をリスニングし、サーバーへのトラフィックを管理する責任を持ちます。

クライアントがサーバーとのネットワーク・セッションを要求するたびに、リスナーが実際の要求を受信します。クライアント情報がリスナー情報と一致する場合、リスナーはサーバーへの接続を付与します。

listener.oraファイル

次のものを識別するリスナーの構成ファイル。

- リスナー名

- 接続要求を受け入れるプロトコル・アドレス

- リスニングするサービス

通常、listener.oraファイルは、UNIXプラットフォームでは$ORACLE_HOME/network/adminに、WindowsではORACLE_BASE\ORACLE_HOME\network\adminにあります。

軽量ユーザー・セッション

ユーザーがログインしているアプリケーションに関連した情報のみが含まれるユーザー・セッションです。軽量ユーザー・セッションには、このセッションのデータベース・リソース(トランザクションやカーソルなど)は入っていません。そのため「軽量」とみなされます。軽量ユーザー・セッションが消費するシステム・リソースは、従来のデータベース・セッションよりはるかに少ない量です。軽量ユーザー・セッションが消費するサーバー・リソースは非常に少ないものになるため、軽量ユーザー・セッションを各エンド・ユーザー専用にして、アプリケーションにより必要とみなされるかぎり持続させることができます。

ローカル権限付与

権限が付与されたPDBにのみ適用できる権限。

「共通権限付与」も参照。

ローカル・ロール

CDBで、非CDBのみに存在する非CDBのロールと同様に、単一のPDBのみに存在するロール。共通ロールと異なり、ローカル・ロールには、そのロールが存在するコンテナで適用されるロールおよび権限のみを含めることができます。

ローカル・ユーザー

CDBで、共通ユーザーではないユーザー。

介在者

第三者によるメッセージの不正傍受という特徴を持つセキュリティ攻撃。第三者(介在者)は、メッセージを復号化して再暗号化し(元のメッセージを変更する場合と変更しない場合があります)、元の宛先である受信者に転送します。これらの処理はすべて、正当な送受信者が気付かないうちに行われます。この種のセキュリティ攻撃は、認証が行われていない場合にのみ発生します。

必須監査

デフォルトで監査されるアクティビティ。管理ユーザーSYS、SYSDBA、SYSOPER、SYSASM、SYSBACKUP、SYSDGおよびSYSKMによる、統合監査証跡ポリシー(ALTER AUDIT POLICYなど)および最上位レベルの文への変更などがあります。詳細は、「強制的に監査されるアクティビティ」を参照してください。

MD5

与えられたデータから128ビットの暗号メッセージ・ダイジェスト値を生成することにより、データの整合性を保証するアルゴリズム。データの単一ビット値のみ変更された場合、MD5はデータ変更のチェックサムを計算します。MD5で元のデータと同じ結果が生成されるようにデータを偽造することは、計算上不可能と考えられます。

メッセージ認証コード

データ認証コード(DAC)とも呼ばれます。秘密鍵を追加したチェックサム。鍵を持つ人のみが暗号チェックサムを検証できます。

メッセージ・ダイジェスト

「チェックサム」を参照してください。

CDB

「CDB」を参照。

ネームスペース

Oracle Databaseのセキュリティにおけるアプリケーション・コンテキストの名前。CREATE CONTEXT文でこの名前を作成します。

ネーミング・メソッド

クライアント・アプリケーションがデータベース・サービスへの接続を試みるときに、接続識別子を接続記述子に変換するために使用する解決メソッド。

National Institute of Standards and Technology (NIST)

米国商務省の機関であり、コンピュータおよびテレコミュニケーション・システム内の暗号ベース・セキュリティ・システムの設計、取得および実装に関連するセキュリティ標準の開発に責任を持ちます。連邦機関、または連邦の役割を遂行するために連邦政府にかわって情報を処理する連邦機関の契約者やその他の組織によって運営されます。

ネット・サービス別名

ディレクトリ・サーバーのディレクトリ・ネーミング・オブジェクトの代替名。ディレクトリ・サーバーは、定義されたネット・サービス名またはデータベース・サービスのネット・サービス別名を格納します。ネット・サービス別名エントリには、接続記述子情報はありません。かわりに、別名の対象のオブジェクトの場所のみ参照します。クライアントがネット・サービス別名のディレクトリ検索を要求した場合、ディレクトリは、エントリがネット・サービス別名であることを判断し、そのネット・サービス別名が実際に参照しているエントリであるかのように検索を実行します。

ネット・サービス名

接続記述子に解決されるサービスの単純名。ユーザーは、接続するサービスに対する接続文字列内に、ネット・サービス名とともにユーザー名およびパスワードを渡すことで接続リクエストを開始します。

CONNECT username@net_service_name
Enter password: password

必要に応じて、ネット・サービス名は次のような様々な場所に格納できます。

- 各クライアントのローカル構成ファイル、tnsnames.ora

- ディレクトリ・サーバー

- NISなどの外部ネーミング・サービス

ネットワーク認証サービス

分散環境で、クライアントからサーバー、サーバー間およびユーザーからクライアントとサーバーの両方を認証する手段。ネットワーク認証サービスは、ユーザーに関する情報、ユーザーがアクセスする様々なサーバー上のサービスに関する情報、およびネットワーク上のクライアントとサーバーに関する情報を格納するためのリポジトリです。認証サーバーは、物理的に異なるコンピュータにすることも、システム内の別のサーバー上の共同の場所にある設備にすることもできます。可用性を保証するために、一部の認証サービスを複製してシングル・ポイント障害を回避できます。

ネットワーク・リスナー

1つ以上のプロトコルで1つ以上のデータベースへの接続要求をリスニングする、サーバー上のリスナー。「リスナー」を参照。

NIST

「米国商務省国立標準技術研究所(NIST)」を参照。

非CDB

CDBでないOracle Database。

否認防止

メッセージの発信元、配信、送信または伝送の明白な証明。

不明瞭化

スクランブルに使用されているアルゴリズムが不明な場合にスクランブル解除が非常に困難になるように、情報を判読不能な形式にスクランブルするプロセス。

不明瞭化プログラム

Javaソース・コードの不明瞭化に使用される特殊なプログラム。「不明瞭化」を参照。

オブジェクト・クラス

名前を持った属性のグループ。属性をエントリに割り当てるときは、その属性を保持しているオブジェクト・クラスをそのエントリに割り当てます。同じオブジェクト・クラスに関連するオブジェクトはすべて、同じ属性を共有します。

Oracleコンテキスト

1. LDAP準拠のインターネット・ディレクトリ内にあるcn=OracleContextというエントリ。このディレクトリには、Oracle Net Servicesディレクトリ・ネーミングおよびチェックサムのセキュリティのエントリなど、Oracleソフトウェア関連のすべての情報が格納されています。

1つのディレクトリに1つ以上のOracleコンテキストを設定できます。Oracleコンテキストは、通常はID管理レルムに位置します。

Oracle Virtual Private Database

行および列レベルでデータベース・アクセスを制御するセキュリティ・ポリシーを作成できる一連の機能。基本的には、Oracle Virtual Private Databaseのセキュリティ・ポリシーが適用された表、ビューまたはシノニムに対して発行されるSQL文に、動的なWHERE句が追加されます。

Oracle Net Services

OracleサーバーまたはDesigner/2000などのOracleツールを実行する2台以上のコンピュータがサード・パーティ・ネットワークを通じてデータを交換できるようにするOracle製品。Oracle Net Servicesは、分散処理および分散データベース機能をサポートします。Oracle Net Servicesは、通信プロトコルに依存しないためオープン・システムであり、ユーザーはOracle Netから多数のネットワーク環境へのインタフェースをとることができます。

Oracle PKI証明書使用

証明書 でサポートされるOracleアプリケーションのタイプを定義します。

パスワードアクセス可能なドメインのリスト

パスワード認証ユーザーからの接続を受け入れるために構成されたエンタープライズ・ドメインのグループ。

PCMCIAカード

Personal Computer Memory Card International Association(PCMCIA)標準に準拠する小さなクレジット・カード・サイズのコンピューティング・デバイス。これらのデバイスはPCカードとも呼ばれ、メモリー、モデムまたはハードウェア・セキュリティ・モジュールの追加に使用されます。PCMCIAカードは、ハードウェア・セキュリティ・モジュールが公開鍵と秘密鍵のペアの秘密鍵コンポーネントを安全に格納する際に使用され、暗号操作も実行するものもあります。

PDB

CDBの一部である、個別のデータベース。

「ルート」も参照。

ピア識別情報

SSL接続セッションは、特定のクライアントと特定のサーバー間のセッションです。接続先の識別情報は、セッションのセットアップ・プロセスの一部として設定される場合があります。接続先は、X.509証明連鎖によって識別されます。

PEM

インターネット上での安全な電子メールを提供するためにInternet Architecture Boardによって採用されたInternet Privacy-Enhanced Mailプロトコル標準。PEMプロトコルは、暗号化、認証、メッセージ整合性および鍵管理を提供します。PEMは、データ暗号化鍵を暗号化するための対称型スキームと公開鍵スキームの両方を含む様々な鍵管理アプローチと互換性を持つよう意図された包括的な標準です。PEMの仕様は、4つのInternet Engineering Task Force(IETF)ドキュメント、RFC 1421、1422、1423および1424に記載されています。

PKCS #10

認証リクエストの構文を記述するRSA Security, Inc.のPublic-Key Cryptography Standards(PKCS)仕様。認証リクエストは、識別名、公開鍵およびオプションの属性セットから構成され、証明書を要求するエンティティによって一括して署名されます。このマニュアルでは、認証リクエストを証明書リクエストと呼びます。「証明書リクエスト」を参照してください。

PKCS #11

暗号情報を保持するデバイスへのCryptokiと呼ばれるアプリケーション・プログラミング・インタフェース(API)を定義し、暗号操作を実行するRSA Security, Inc.のPublic-Key Cryptography Standards(PKCS)仕様。「PCMCIAカード」を参照してください。

PKCS #12

通常はウォレットと呼ばれる形式で個人認証資格証明を格納および転送するための転送構文を記述するRSA Security社のPublic-Key Cryptography Standards(PKCS)仕様。

PKI

「公開鍵インフラストラクチャ(PKI)」を参照してください。

平文

暗号化されていないメッセージ・テキスト。

プラガブル・データベース

「PDB」を参照。

プリンシパル

Kerberos資格証明のセットが割り当てられているクライアントまたはサーバーを一意に識別する文字列。通常、これにはkservice/kinstance@REALMという3つの部分が含まれます。ユーザーの場合、kserviceはユーザー名です。「kservice」、「kinstance」および「レルム」も参照してください。

秘密鍵

公開鍵暗号化では、この鍵が秘密鍵(secret key)です。主に復号化に使用されますが、デジタル署名とともに暗号化にも使用されます。「公開鍵と秘密鍵のペア」を参照。

プロキシ認証

ファイアウォールなどの中間層を伴う環境で一般に使用されるプロセス。エンド・ユーザーは中間層に対して認証を行い、中間層はエンド・ユーザーのプロキシとして、ユーザーのかわりにディレクトリに対して認証を実施します。中間層は、プロキシ・ユーザーとしてディレクトリにログインします。プロキシ・ユーザーは識別情報を切り替えることができ、ディレクトリにログインするとエンド・ユーザーの識別情報に切り替わります。プロキシ・ユーザーは、特定のエンド・ユーザーに適した認可を使用して、そのエンド・ユーザーにかわって操作を実行できます。

公開鍵

公開鍵暗号化では、この鍵がすべてに対して公開されます。主に暗号化に使用されますが、署名の検証にも使用できます。「公開鍵と秘密鍵のペア」を参照。

公開鍵と秘密鍵のペア

暗号化および復号化に使用される2つの数字のセットで、1つは秘密鍵、もう1つは公開鍵と呼ばれます。公開鍵は通常広く使用可能であるのに対して、秘密鍵はそれぞれの所有者によって保持されます。数学的に関連付けられてはいますが、計算によって公開鍵から秘密鍵を求めるのはほぼ不可能と考えられています。公開鍵と秘密鍵は、公開鍵暗号化アルゴリズムまたは公開鍵暗号化体系とも呼ばれる非対称型暗号化アルゴリズムでのみ使用されます。鍵のペアの公開鍵または秘密鍵で暗号化されたデータは、鍵のペアのうち関連付けられている鍵で復号化できます。ただし、公開鍵で暗号化されたデータを同じ公開鍵で復号化することはできず、秘密鍵で包まれたデータを同じ秘密鍵で複合化することはできません。

公開鍵インフラストラクチャ(PKI)

公開鍵暗号化の原理を利用した情報セキュリティ・テクノロジ。公開鍵暗号化には、共有の公開鍵と秘密鍵のペアを使用した情報の暗号化および復号化が含まれます。パブリック・ネットワーク内にセキュアでプライベートな通信を提供します。

PUBLICロール

すべてのデータベース・アカウントが自動的に保有する特殊なロール。デフォルトでは割り当てられている権限がありませんが、多くのJavaオブジェクトに対する付与があります。PUBLICロールは削除できません。また、ユーザー・アカウントは常にこのロールを前提とするため、このロールの手動の付与や取消しは意味がありません。PUBLICロールはすべてのデータベース・ユーザー・アカウントが前提とするため、DBA_ROLESおよびSESSION_ROLESデータ・ディクショナリ・ビューには表示されません。

削除ジョブ

DBMS_AUDIT_MGMT.CREATE_PURGE_JOBプロシージャにより作成されたデータベース・ジョブで、監査証跡の削除を管理します。データベース管理者が削除ジョブをスケジューリングおよび使用可能/使用禁止にします。削除ジョブはアクティブになると、監査レコードをデータベース監査表から削除したり、Oracle Databaseオペレーティング・システム監査ファイルを削除します。

「強制クリーン・アップ」、「最終アーカイブ・タイムスタンプ」も参照してください。

RADIUS

Remote Authentication Dial-In User Service(RADIUS)は、リモート・アクセス・サーバーが中央サーバーと通信してダイアルイン・ユーザーを認証し、リクエストされたシステムまたはサービスへのアクセスを認可できるようにするクライアント/サーバー・プロトコルおよびソフトウェアです。

レルム

1. ID管理レルムの省略形。2.Kerberosオブジェクト。単一の鍵配布センター/チケット認可サービス(KDC/TGS)の下で動作するクライアントとサーバーのセット。同じ名前を共有する異なるレルム内のサービス(kserviceを参照)は一意です。

レルムOracleコンテキスト

Oracle Internet DirectoryのID管理レルムの一部であるOracleコンテキスト。

レジストリ

コンピュータの構成情報を格納するWindowsリポジトリ。

リモート・コンピュータ

ネットワーク上にあるローカル・コンピュータ以外のコンピュータ。

ロール

関連する権限のグループに名前を付けたもの。ユーザーや他のロールに付与します。

「間接的に付与されたロール」も参照してください。

root

マルチテナント環境で、すべてのPDBが属している、オラクル社が提供およびユーザーが作成したスキーマのコレクション。コンテナ・データベースでは、ルートは1つのみです。各PDBは、このルートの子であるとみなされます。ルートは、データ・ディクショナリに各PDBの存在を示すエントリを持っています。

「コンテナ」、「CDB」、「PDB」も参照。

ルート鍵証明書

「信頼できる証明書」を参照してください。

salt

暗号化技術において、暗号化されたデータのセキュリティを強化する方法。データが暗号化される前に追加されるランダムな文字列で、攻撃者が暗号文のパターンを既知の暗号文サンプルに一致させてデータを盗むことを困難にします。saltは通常、辞書攻撃(悪意のあるハッカー(攻撃者)がパスワードを盗むために使用する方法)を防ぐために、暗号化される前のパスワードにも追加されます。暗号化されたsalt処理済の値により、暗号化されたパスワードのハッシュ値(ベリファイアとも呼ばれます)と、一般のパスワード・ハッシュ値の辞書リストとの照合が困難になります。

スキーマ

1. データベース・スキーマ。表、ビュー、クラスタ、プロシージャ、パッケージ、属性、オブジェクト・クラス、およびそれらに対応する一致規則など、名前が付いたオブジェクトの集合であり、特定のユーザーに関連付けられています。2.LDAPディレクトリ・スキーマ: 属性、オブジェクト・クラス、およびそれらに対応する一致ルールのコレクション。

スキーマ・マッピング

「ユーザー・スキーマ・マッピング」を参照してください。

セキュア・アプリケーション・ロール

アプリケーション・ユーザーに付与されるデータベース・ロール。ただし、実行者権限ストアド・プロシージャを使用して保護され、ロールのパスワードをデータベース表から取得します。セキュア・アプリケーション・ロールのパスワードは、アプリケーション内に埋め込まれていません。

「アプリケーション・ロール」も参照してください。

Secure Hash Algorithm (SHA)

与えられたデータから160ビットの暗号メッセージ・ダイジェスト値を生成することにより、データの整合性を保証するアルゴリズム。データの単一ビットのみ変更された場合、Secure Hash Algorithmはデータ変更のチェックサムを計算します。Secure Hash Algorithmで元のデータと同じ結果が生成されるように特定のデータ・セットを偽造することは、計算上不可能と考えられます。

264ビット未満の長さのメッセージを受け取ったアルゴリズムは、160ビットのメッセージ・ダイジェストを生成します。アルゴリズムはMD5よりもわずかに低速ですが、メッセージ・ダイジェストが大きいほど、総当たり攻撃と侵入攻撃に対する安全度が増します。

Secure Sockets Layer (SSL)

ネットワーク接続の保護のためにNetscape Communications社によって設計された業界標準プロトコル。SSLは、公開鍵インフラストラクチャ(PKI)を使用して、認証、暗号化およびデータ整合性を提供します。

Transport Layer Security (TLS)プロトコルは、SSLプロトコルの後継です。

業務分離

アクティビティを、それを実行する必要があるユーザーのみに制限すること。たとえば、SYSDBA管理権限は一般ユーザーには付与しないようにします。この権限は管理ユーザーにのみ付与します。業務分離は、多くのコンプライアンス・ポリシーで必要です。適切なユーザーへの権限付与に関するガイドラインは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください。

サーバー

サービスのプロバイダ。

サービス

1. Oracleデータベース・サーバーなど、クライアントによって使用されるネットワーク・リソース。

2. Windowsレジストリにインストールされ、Windowsによって管理される実行可能プロセス。サービスが作成され、開始された後は、コンピュータにログオンしているユーザーがいない場合でも実行できます。

サービス名

Kerberosベースの認証では、サービス・プリンシパルのkservice部分がサービス名です。

サービス・プリンシパル

「プリンシパル」を参照してください。

サービス・キー表

Kerberos認証では、サービス・キー表はkinstanceに存在するサービス・プリンシパルのリストです。KerberosをOracleで使用するには、その前にこの情報をKerberosから抽出し、Oracleサーバー・コンピュータにコピーする必要があります。

サービス・チケット

サービス・チケットは、事前定義された期間、特定のサービスまたはサーバーに対してクライアントを認証するために使用する信頼できる情報です。初期チケットを使用してKDCから取得されます。「Kerberosチケット」も参照してください。

セッション鍵

少なくとも二者(通常はクライアントとサーバー)によって共有される鍵であり、単一の通信セッション中のデータ暗号化に使用されます。セッション鍵は通常、ネットワーク・トラフィックを暗号化するために使用されます。クライアントとサーバーはセッションの開始時にセッション鍵をネゴシエーションすることができ、その鍵はそのセッションの関係者間のすべてのネットワーク・トラフィックを暗号化するために使用されます。クライアントとサーバーが新しいセッションで再び通信する場合は、新しいセッション鍵をネゴシエーションします。

セッション・レイヤー

プレゼンテーション・レイヤー・エンティティが必要とするサービスを提供するネットワーク・レイヤーであり、プレゼンテーション・レイヤー・エンティティがダイアログの編成と同期およびデータ交換の管理を行えるようにします。このレイヤーは、クライアントとサーバー間のネットワーク・セッションを確立、管理および終了します。セッション・レイヤーの例には、ネットワーク・セッションがあります。

SHA

「Secure Hash Algorithm (SHA)」を参照してください。

共有スキーマ

複数のエンタープライズ・ユーザーが使用できるデータベースまたはアプリケーション・スキーマ。Oracle Databaseでは、データベース上の同じ共有スキーマへの複数のエンタープライズ・ユーザーのマッピングがサポートされます。これにより、管理者はそれぞれのデータベースでユーザーごとにアカウントを作成する必要がなくなります。管理者は、ユーザーを1つの場所、つまり、エンタープライズ・ディレクトリに作成して、そのユーザーを共有スキーマにマップできます。この共有スキーマには他のエンタープライズ・ユーザーもマップできます。ユーザー/スキーマの分割とも呼ばれます。

単一鍵ペア・ウォレット

単一のユーザー証明書とその関連する秘密鍵が含まれるPKCS #12 形式のウォレット。公開鍵は証明書に埋め込まれています。

単一パスワード認証

単一パスワードを使用して複数のデータベースでユーザーを認証する機能。Oracle Databaseの実装では、パスワードはLDAP準拠ディレクトリに格納され、暗号化やアクセス制御リストで保護されます。

シングル・サインオン(SSO)

ユーザーが1度認証を受けると、その後の他のデータベースまたはアプリケーションへの接続に、厳密な認証が透過的に実施される機能。シングル・サインオンでは、ユーザーは1回の接続中に入力した単一のパスワードで複数のアカウントおよびアプリケーションにアクセスできます。単一のパスワードによる単一の認証です。Oracle Databaseは、KerberosおよびSSLベースのシングル・サインオンをサポートしています。

スマートカード

ユーザー名やパスワードなどの情報を格納するため、また認証交換に関連する計算を実行するための集積回路が埋め込まれた(クレジット・カードに似た)プラスチック・カード。スマートカードは、クライアントまたはサーバーでハードウェア・デバイスによって読み取られます。

スマートカードでは、1回かぎりのパスワードとして使用できるランダムな数値を生成できます。この場合、スマートカードはサーバー上のサービスと同期するため、サーバーはスマートカードによって同じパスワードが生成されると予想します。

Sniffer

ネットワークからのプライベート・データ・トラフィックを不正にリスニングまたは取得するために使用されるデバイス。

SSO

「シングル・サイン・オン(SSO)」を参照してください。

システム・グローバル領域(SGA)

Oracleインスタンスのデータおよび制御情報を含む共有メモリー構造のグループ。

システム識別子(SID)

Oracleインスタンスの一意の名前。Oracleデータベース間を切り替えるには、ユーザーが目的のSIDを指定する必要があります。SIDは、tnsnames.oraファイル内の接続記述子のCONNECT DATA部分と、listener.oraファイル内のネットワーク・リスナーの定義に含まれます。

チケット

所有者の識別に役立つ情報。「初期チケット」および「サービス・チケット」を参照。

tnsnames.ora

接続記述子が含まれているファイル。各接続記述子はネット・サービス名にマップされます。すべてのクライアントまたは各クライアントで使用するために、このファイルを集中して維持することも、ローカルで維持することもできます。このファイルは通常、プラットフォームに応じて次の場所にあります。

- (UNIXの場合)ORACLE_HOME/network/admin

- (Windowsの場合)ORACLE_BASE\ORACLE_HOME\network\admin

トークン・カード

ユーザーが容易に認証サービスを利用できるように、数種類のメカニズムを提供するデバイス。一部のトークン・カードは、認証サービスと同期された1回かぎりのパスワードを提供します。サーバーは、認証サービスにアクセスすることにより、トークン・カードによって提供されるパスワードを任意の時点で検証できます。その他のトークン・カードは、チャレンジ・レスポンス・ベースで動作します。その場合、サーバーはユーザーがトークン・カードに入力するチャレンジ(数字)を提供します。トークン・カードは、ユーザーがサーバーに提供する別の数字(チャレンジから暗号的に派生)を提供します。

トランスポート・レイヤー

データ・フロー制御とエラー・リカバリ方式を通じてエンドツーエンドの信頼性を維持するネットワーキング・レイヤー。Oracle Net Servicesは、トランスポート・レイヤーにOracleプロトコル・サポートを使用します。

Transport Layer Security (TLS)

ネットワーク接続を保護するための業界標準プロトコル。TLSプロトコルはSSLプロトコルの後継です。公開鍵インフラストラクチャ(PKI)を使用した認証、暗号化およびデータの整合性を提供します。TLSプロトコルは、Internet Engineering Task Force (IETF)によって開発されています。

信頼できる証明書

ルート鍵証明書とも呼ばれることのある信頼できる証明書は、信頼のレベルで修飾されたサード・パーティ識別情報です。信頼できる証明書は、識別情報がエンティティの主張どおりであるかどうかを検証する際に使用されます。通常は、信頼する認証局を信頼できる証明書と呼びます。信頼できる証明書に複数のレベルがある場合、証明連鎖の最下位レベルにある信頼できる証明書では、それより上位レベルのすべての証明書を再検証する必要はありません。

信頼できる認証局

「認証局」を参照してください。

トラスト・ポイント

「信頼できる証明書」を参照してください。

ユーザー名

データベース内のオブジェクトに接続およびアクセスするための名前。

ユーザー・スキーマ・マッピング

ユーザーが存在するディレクトリ内のベースおよびユーザーがマッピングされるデータベース・スキーマの名前という値のペアを含むLDAPディレクトリ・エントリ。マッピングで参照されるユーザーは、データベースへの接続時に指定されたスキーマに接続されます。ユーザー・スキーマ・マッピング・エントリは、1つのデータベースにのみ適用できるか、1つのドメイン内のすべてのデータベースに適用できます。「共有スキーマ」を参照してください。

ユーザー/スキーマの分割

「共有スキーマ」を参照してください。

ユーザー検索ベース

LDAPディレクトリ内のユーザーが存在するノード。

ビュー

1つ以上の表(またはその他のビュー)の選択的な表示で、構造とデータの両方を示します。

ウォレット

個々のエンティティのセキュリティ資格証明を格納したり、管理するために使用されるデータ構造。

Windowsネイティブ認証

Windowsサーバーおよびそのサーバー上で稼働しているデータベースへのクライアントのシングル・ログイン・アクセスを可能にする認証方式。

X.509

デジタル証明 の業界標準仕様。

索引

A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X

記号

- すべての権限 1

数字

- 12Cパスワード・ハッシュ・バージョン

- 概要 1

- 12Cパスワード・バージョン

- Oracleによる推奨 1

A

- アクセス制御

- 暗号化、解決しない問題 1

- 規定 1

- オブジェクト権限 1

- パスワード暗号化 1

- アクセス制御リスト(ACL)

- 例

- 電子メール・アラートのための外部ネットワーク接続 1

- 外部ネットワーク接続 1

- ウォレット・アクセス 1

- 外部ネットワーク・サービス

- 概要 1

- メリット 1

- 以前のリリースからのアップグレードの影響 1

- 監査違反の電子メール・アラートの例 1

- 情報の検索 1

- ネットワーク・ホスト、ワイルドカードを使用した指定 1

- ORA-06512エラー 1

- ORA-24247エラー 1

- ORA-24247エラー 1

- 優先順位、ホスト 1

- ポート範囲 1

- 権限割当て、概要 1

- 権限割当て、データベース管理者によるチェック 1

- 権限割当て、ユーザーによるチェック 1

- 権限の取消し 1

- ウォレット・アクセス

- 概要 1

- メリット 1

- クライアント証明書資格証明、使用 1

- 情報の検索 1

- 非共有ウォレット 1

- パスワード資格証明 1

- パスワード資格証明、使用 1

- 取消し 1

- アクセス権の取消し 1

- 共有データベース・セッション 1

- 機密情報を含まないウォレット 1

- 機密情報を含むウォレット 1

- アカウンティング、RADIUS 1

- アカウントのロック

- 例 1

- 明示的 1

- PASSWORD_LOCK_TIMEプロファイル・パラメータ 1

- パスワード管理 1

- チェックサムと暗号化の有効化 1

- アダプタ 1

- 非定型ツール

- データベース・アクセス、セキュリティの問題 1

- ADM_PARALLEL_EXECUTE_TASKロール

- 概要 1

- 管理権限

- 概要 1

- ユーザーへの付与 1

- SYSBACKUP権限 1

- SYSDBA権限 1

- SYSDG権限 1

- SYSKM権限 1

- SYSOPER権限 1

- 管理用ユーザーのパスワード

- デフォルト、変更の重要性 1

- 管理ユーザー

- 監査 1

- 強制的な監査 1

- 管理者権限

- アクセス 1

- オペレーティング・システム認証 1

- パスワード 1 , 2

- SYSDBAおよびSYSOPERのアクセス、集中管理 1

- 書込み、listener.oraファイル 1

- Admin Option

- 概要 1

- 権限の取消し 1

- ロールの取消し 1

- ロール 1

- システム権限 1

- AES256アルゴリズム

- Oracleウォレットでの変換 1

- アラート、ファイングレイン監査ポリシーで使用 1

- ALTER ANY LIBRARY文

- セキュリティ・ガイドライン 1

- ユーザーの変更 1

- ALTER PROCEDURE文

- プロシージャのコンパイルに使用 1

- ALTER PROFILE文

- パスワード管理 1

- ALTER RESOURCE COST文 1 , 2

- ALTER ROLE文

- 認可方式の変更 1

- ALTER SESSION文

- スキーマ、現在の設定 1

- ALTER USER権限 1

- ALTER USER文

- デフォルト・ロール 1

- 明示的なアカウントのロック解除 1

- プロファイル、変更 1

- REVOKE CONNECT THROUGH句 1

- 匿名 1

- ANSI操作

- Oracle Virtual Private Databaseの影響 1

- ANYシステム権限

- セキュリティに関するガイドライン 1

- アプリケーション・コンテキスト

- 概要 1

- 保護データ・キャッシュ 1

- 使用する利点 1

- バインド変数 1

- コンポーネント 1

- セッション・ベースの作成 1

- DBMS_SESSION.SET_CONTEXTプロシージャ 1

- 駆動コンテキスト 1

- エディション、影響 1

- トレース・ファイルの確認によるエラーの検索 1

- 情報の検索 1

- グローバル・アプリケーション・コンテキスト

- 複数のアプリケーションに対するユーザーの認証 1

- 作成 1

- ログイン・トリガー、作成 1

- Oracle Virtual Private Database、使用 1

- パフォーマンス 1

- ポリシー・グループ、使用 1

- 述語を戻す 1

- セッション情報、取得 1

- データベース・リンクのサポート 1

- タイプ 1

- ユーザー、非データベース接続 1 , 2

- 値の格納場所 1

- アプリケーション開発者

- CONNECTロール変更 1

- アプリケーション

- セキュリティ・ポリシーの概要 1

- データベース・ユーザー 1

- セキュリティの強化 1

- オブジェクト権限 1

- SQL文を許可するオブジェクト権限 1

- One Big Application Userの認証

- セキュリティに関する考慮事項 1

- セキュリティ上のリスク 1

- Oracle Virtual Private Database、仕組み 1

- パスワードの処理、ガイドライン 1

- パスワード保護戦略 1

- 権限、管理 1

- ロール

- 複数 1

- 権限、データベース・ロールとの関連付け 1

- セキュリティ 1 , 2

- セキュリティの使用に関する考慮事項 1

- セキュリティの制限 1

- セキュリティ・ポリシー 1

- セキュリティ・ポリシーでの検証 1

- アプリケーション・セキュリティ

- ウォレット・アクセスを現在のアプリケーションに制限 1

- Oracleウォレットからのアクセス制御権限の取消し 1

- 他のアプリケーションとのウォレットの共有 1

- 属性の指定 1

- データベース・ユーザーであるアプリケーション・ユーザー

- Oracle Virtual Private Database、仕組み 1

- アーカイブ

- オペレーティング・システム監査ファイル 1

- 標準監査証跡 1

- 監査証跡のタイムスタンプ設定 1

- RADIUSでの非同期認証モード 1

- 攻撃

- 「セキュリティ攻撃」を参照

- AUDIT_ADMINロール 1

- AUDIT_VIEWERロール 1

- 監査ファイル

- オペレーティング・システム監査証跡

- アーカイブ、タイムスタンプの設定 1

- オペレーティング・システム・ファイル

- アーカイブ 1

- 標準監査証跡

- アーカイブ、タイムスタンプの設定 1

- レコード、アーカイブ 1

- 監査

- 管理者、Database Vault 1

- 監査オプション 1

- 機密性の高いデータ、監査証跡内の 1

- CDB 1

- コミット済データ 1

- カーソル、監査に与える影響 1

- データベース、使用不可の場合 1

- データベース・ユーザー名 1

- Database Vault管理者 1

- 分散データベース 1

- DV_ADMINロールのユーザー 1

- DV_OWNERロールのユーザー 1

- 監査証跡に関する情報の検索 1

- 使用状況についての情報の検索 1

- ファイングレイン

- 「ファイングレイン監査」を参照 1

- ファンクション 1

- 関数、Oracle Virtual Private Database 1

- 一般的な手順

- 一般的に使用されるセキュリティ関連アクティビティ 1

- 特定のファイングレイン・アクティビティ 1

- SQL文および他の一般アクティビティ 1

- 一般手順 1

- セキュリティに関するガイドライン 1

- 履歴情報 1

- INHERIT PRIVILEGE権限 1

- 情報管理の容易性の維持 1

- 監査レコードの統合監査証跡へのロード 1

- 必須監査 1

- 複数層環境

- 「標準監査」を参照 1

- One Big Application Userの認証、制限 1

- オペレーティング・システム・ユーザー名 1

- Oracle Virtual Private Databaseポリシー関数 1

- パッケージ 1

- パフォーマンス 1

- PL/SQLパッケージ 1

- 事前定義済ポリシー

- 通常の使用手順 1

- 必要な権限 1

- プロシージャ 1

- レコードの削除

- 例 1

- 手動パージの一般的な手順 1

- スケジューリングされたパージの一般的な手順 1

- 対象範囲 1

- ポリシーにおけるREADオブジェクト権限 1

- READ権限

- 概要 1

- 監査証跡での記録方法 1

- 推奨設定 1

- 米国サーベンス・オクスリー法

- 監査、順守を満たす 1

- SELECT権限

- 概要 1

- 監査証跡での記録方法 1

- 疑わしいアクティビティ 1

- 従来 1

- トリガー 1

- 統合監査証跡

- 概要 1

- VPD述語

- ファイングレイン監査ポリシー 1

- 監査オプションが有効になる時点 1

- 監査レコードが作成される場合 1

- 監査、レコードの削除

- 概要 1

- アーカイブ・タイムスタンプの取消し 1

- 監査証跡の作成

- 削除ジョブ 1

- 削除ジョブの作成 1

- DBMS_SCHEDULERパッケージ 1

- 削除ジョブの削除 1

- 削除ジョブを使用禁止にする 1

- 削除ジョブを使用可能にする 1

- 一般手順 1

- 監査証跡の手動削除 1

- ロードマップ 1

- 削除ジョブのスケジューリング 1

- アーカイブ・タイムスタンプの設定 1

- 指定した削除ジョブの間隔 1

- 監査ポリシー 1

- 「統合監査ポリシー」も参照

- 監査ポリシー、アプリケーション・コンテキスト

- 概要 1

- 監査証跡での表示方法 1

- 構成 1

- 無効化 1

- 例 1

- 監査証跡

- アーカイブ 1

- 監査証跡に関する情報の検索 1

- 使用状況についての情報の検索 1

- 統合

- アーカイブ 1

- AUTHENTICATEDUSERロール 1

- 認証

- 概要 1

- 管理者

- オペレーティング・システム 1

- パスワード 1

- SYSDBAおよびSYSOPERのアクセス、集中管理 1

- データベースによる 1

- SSLによる 1

- クライアント 1

- クライアントから中間層を介したプロセス 1

- 複数の方式の構成 1

- データベース管理者 1

- データベース、使用

- 概要 1

- メリット 1

- 手順 1

- ディレクトリベース・サービス 1

- ディレクトリ・サービス 1

- 外部認証

- 概要 1

- メリット 1

- オペレーティング・システム認証 1

- ユーザーの作成 1

- グローバル認証

- 概要 1

- メリット 1

- プライベート・スキーマを持つユーザーの作成 1

- スキーマを共有するユーザーの作成 1

- 方式 1

- 中間層の認証

- プロキシ、例 1

- RADIUSでのモード 1

- 複数層 1

- ネットワーク認証

- Secure Sockets Layer 1

- サード・パーティ・サービス 1

- One Big Application User、制限 1

- オペレーティング・システム認証

- 概要 1

- メリット 1

- デメリット 1

- ORA-28040エラー 1

- プロキシ・ユーザー認証

- 概要 1

- 期限切れのパスワード 1

- 公開鍵インフラストラクチャ 1

- RADIUS 1

- リモート 1

- ユーザー作成時の指定 1

- 厳密 1

- WindowsシステムのSYSDBA 1

- Windowsネイティブ認証 1

- AUTHENTICATIONパラメータ 1

- AUTHID DEFINER句

- Oracle Virtual Private Database関数での使用 1

- 認可

- 概要 1

- ロールに対する変更 1

- グローバル

- 概要 1

- メリット 1

- 複数層 1

- ロールに対して省略 1

- オペレーティング・システム 1

- ロール、概要 1

- 自動再解析

- Oracle Virtual Private Database、仕組み 1

B

- バナー

- ユーザー・アクションの監査、構成 1

- 不正なアクセス、構成 1

- BFILE

- セキュリティに関するガイドライン 1

- バインド変数

- アプリケーション・コンテキスト、使用 1

- BLOB

- 暗号化 1

C

- CAPTURE_ADMINロール 1

- 取消しによる連鎖 1

- CDB_DBAロール 1

- CDB

- 監査、影響 1

- 監査、従来 1

- DELEGATEオプション付きCBACロール付与 1

- 共通権限付与 1

- 権限の付与 1

- ローカル権限付与 1

- オブジェクト権限 1

- 権限管理 1

- 権限の取消し 1

- ロール管理 1

- ロール

- 変更 1

- 共通の作成 1

- ローカルの作成 1

- 共通の付与 1

- 共通ロールの使用方法 1

- 管理に必要な権限 1

- 共通の作成規則 1

- システム権限 1

- 透過的機密データ保護 1

- ユーザー・アカウント

- 作成 1

- ローカル 1

- ユーザー権限、影響 1

- ユーザー

- 共通 1

- 情報の表示 1

- 仮想プライベート・データベース・ポリシー 1

- Center for Internet Security (CIS) 1

- 証明書 1

- 認証局 1

- 証明書の鍵のアルゴリズム

- Secure Sockets Layer 1

- 証明書失効リスト(CRL)

- 削除 1

- 表示 1

- リストの表示 1

- ハッシュ値の生成 1

- アップロード 1

- 証明書失効リスト

- orapkiツールによる操作 1

- LDAPディレクトリへのアップロード 1

- 格納場所 1

- 証明書失効ステータス・チェック

- サーバーでの無効化 1 , 2

- 証明書

- orapkiを使用した署名の作成 1

- 証明書の検証のエラー・メッセージ

- CRLが見つかりませんでした 1

- RSAステータスでCRLの日付検証に失敗しました 1

- RSAステータスでCRLの署名検証に失敗しました 1

- CRL DPからのCRLのフェッチ

- CRLが見つかりません 1

- OIDのホスト名またはポート番号が設定されていません 1

- RADIUSでのチャレンジ・レスポンス認証 1

- デフォルトのchange_on_installパスワード 1

- キャラクタ・セット

- ロール名、マルチバイト・キャラクタ 1

- ロール・パスワード、マルチバイト・キャラクタ 1

- 暗号スイート

- 概要 1

- 認証方式 1

- データ整合性 1

- 使用される暗号化アルゴリズム 1

- サーバーに指定する手順 1

- Secure Sockets Layer 1

- Secure Sockets Layer(SSL) 1

- TLSの互換性 1

- 暗号スイート

- FIPS 140-2用設定 1

- CLIENT_IDENTIFIER USERENV属性

- DBMS_SESSIONパッケージを使用した設定および消去 1

- OCIユーザー・セッション・ハンドル属性を使用した設定 1

- SSLでのクライアント認証 1

- クライアント接続

- セキュリティに関するガイドライン 1

- 安全性の高い外部パスワード・ストア 1

- 保護 1

- CLIENTID_OVERWRITEイベント 1

- クライアント識別子

- JDBCを使用するアプリケーションに対する設定 1

- クライアント識別子

- 概要 1

- ユーザーの監査 1

- DBMS_SESSION.SET_IDENTIFIERとDBMS_APPLICATION_INFO.SET_CLIENT_INFOの整合性 1

- グローバル・アプリケーション・コンテキスト、独立 1

- DBMS_SESSION.SET_IDENTIFIERプロシージャを使用した設定 1

- クライアント・セッション・ベースのアプリケーション・コンテキスト

- 概要 1

- CLIENTCONTEXTネームスペース、値の消去 1

- CLIENTCONTEXTネームスペース、値の設定 1

- CLIENTCONTEXTネームスペースの取得 1

- コード・ベース・アクセス制御(CBAC)

- 概要 1

- プログラム・ユニットへのロールの付与と取消し 1

- 定義者権限での使用方法 1

- 実行者権限での使用方法 1

- 権限 1

- チュートリアル 1

- 列のマスク動作

- 列の仕様 1

- 制限 1

- 列

- 選択した列に対する権限の付与 1

- 権限の付与 1

- INSERT権限 1

- 付与されているユーザーのリスト 1

- 権限 1

- 疑似列

- USER 1

- 権限の取消し 1

- コマンドラインのリコール攻撃 1 , 2

- コミット済データ

- 監査 1

- 共通権限付与

- 概要 1

- 付与 1

- 取消し 1

- オブジェクト権限の使用 1

- システム権限の使用 1

- 共通ロール

- 概要 1

- 監査 1

- 作成 1

- 付与 1

- 動作の概要 1

- 管理に必要な権限 1

- 作成のルール 1

- 共通ユーザー・アカウント

- 作成 1

- 他のPDBへのアクセスの有効化 1

- 権限の付与先 1

- 共通ユーザー

- 概要 1

- PDBのデータへのアクセス 1

- 変更 1

- 接続操作 1

- 構成

- セキュリティに関するガイドライン 1

- 構成ファイル

- Kerberos 1

- listener.ora 1

- サンプルlistener.oraファイル 1

- server.key暗号化ファイル 1

- tsnames.ora 1

- 標準的なディレクトリ 1

- 構成

- Kerberos認証サービス・パラメータ 1

- RADIUS認証 1

- SSL

- クライアントで 1

- サーバーで 1

- シンJDBCのサポート 1

- 接続

- ユーザー名とパスワードの使用 1

- 接続プーリング

- 概要 1

- グローバル・アプリケーション・コンテキスト 1

- 非データベース・ユーザー 1

- プロキシ認証 1

- CONNECTロール

- 概要 1

- アプリケーション

- アカウント・プロビジョニング 1

- 影響 1

- データベースのアップグレード 1

- インストール 1

- 作成するためのスクリプト 1

- ユーザー

- アプリケーション開発者、影響 1

- クライアント/サーバー・アプリケーション、影響 1

- 一般ユーザー、影響 1

- 影響 1

- 変更された理由 1

- CONTAINER_DATAオブジェクト

- 情報の表示 1

- コンテナ・データベース(CDB)

- 「CDB」を参照

- コンテナ・データ・オブジェクト

- 概要 1

- 制御されたステップイン・プロシージャ 1

- CPUタイムの制限 1

- CREATE ANY LIBRARY文

- セキュリティ・ガイドライン 1

- CREATE ANY PROCEDUREシステム権限 1

- CREATE CONTEXT文

- 例 1

- CREATE PROCEDUREシステム権限 1

- CREATE PROFILE文

- パスワード・エイジングおよび期限切れ 1

- パスワード管理 1

- パスワード、例 1

- CREATE ROLE文

- IDENTIFIED EXTERNALLYオプション 1

- CREATE SCHEMA文

- 保護 1

- CREATE SESSION文

- CONNECTロール権限 1

- 保護 1

- CREATE USER文

- 明示的なアカウントのロック 1

- IDENTIFIED BYオプション 1

- IDENTIFIED EXTERNALLYオプション 1

- CRL 1

- CRLAdminsディレクトリ管理グループ 1

- CRL

- サーバーでの無効化 1 , 2

- 格納場所 1

- 暗号化ハードウェア・デバイス 1

- 暗号ライブラリ

- FIPS 140-2 1

- CSW_USR_ROLEロール 1

- CTXAPPロール 1

- カーソル

- 監査に与える影響 1

- 再解析、アプリケーション・コンテキスト 1

- 共有、仮想プライベート・データベースで使用 1

- CWM_USERロール 1

D

- データベース管理者(DBA)

- アクセス、制御 1

- 認証 1

- 不正、暗号化では解決しない 1

- Database Configuration Assistant(DBCA)

- デフォルト・パスワード、変更 1

- ユーザー・アカウント、自動的にロックして期限切れにする 1

- データベース・リンク

- アプリケーション・コンテキスト 1

- アプリケーション・コンテキストのサポート 1

- Kerberosを使用した認証 1

- サード・パーティ・サービスを使用した認証 1

- グローバルなユーザー認証 1

- オブジェクト権限 1

- オペレーティング・システム・アカウント、注意が必要 1

- RADIUSはサポートされない 1

- セッション・ベースのアプリケーション・コンテキスト、アクセス 1

- データベース

- アクセス制御

- パスワード暗号化 1

- その他のセキュリティ・リソース 1

- 認証 1

- データベース・ユーザーとアプリケーション・ユーザー 1

- デフォルトのパスワード・セキュリティ設定

- DBCAを使用して作成されたデータベース 1

- 手動で作成したデータベース 1

- デフォルトのセキュリティ機能、要約 1

- 権限の付与 1

- ロールの付与 1

- 使用の制限 1

- セキュリティとスキーマ 1

- セキュリティの埋込み、利点 1

- 基づくセキュリティ・ポリシー 1

- データベース・セッション・ベースのアプリケーション・コンテキスト

- 概要 1

- ユーザー終了後のクリーン・アップ 1

- コンポーネント 1

- データベース・リンク 1

- 動的SQL 1

- 外部化、使用 1

- 使用方法 1

- 外部での初期化 1

- グローバルな初期化 1

- 所有権 1

- パラレル問合せ 1

- PL/SQLパッケージの作成 1

- セッション情報、設定 1

- SYS_CONTEXTファンクション 1

- トラステッド・プロシージャ 1

- チュートリアル 1

- データベース・アップグレードとCONNECTロール 1

- データ定義言語(DDL)

- ロールと権限 1

- データ・ディクショナリ

- 保護 1

- O7_DICTIONARY_ACCESSIBILITYによる保護 1

- データ・ディクショナリ・ビュー

- 「ビュー」を参照

- データ暗号化および整合性パラメータ

- 概要 1

- SQLNET.CRYPTO_CHECKSUM_CLIENT 1

- SQLNET.CRYPTO_CHECKSUM_SERVER 1

- SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT 1

- SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER 1

- SQLNET.ENCRYPTION_CLIENT 1

- SQLNET.ENCRYPTION_SERVER 1

- SQLNET.ENCRYPTION_TYPES_CLIENT 1

- SQLNET.ENCRYPTION_TYPES_SERVER 1

- データ・ファイル

- セキュリティに関するガイドライン 1

- データ操作言語(DML)

- 権限の制御 1

- DATAPUMP_EXP_FULL_DATABASEロール 1

- DATAPUMP_IMP_FULL_DATABASEロール 1

- データ・セキュリティ

- 暗号化、解決しない問題 1

- DBA_CONTAINER_DATAデータ・ディクショナリ・ビュー 1

- DBA_ROLE_PRIVSビュー

- アプリケーション権限、検索 1

- DBA_ROLESデータ・ディクショナリ・ビュー

- PUBLICロール 1

- DBAロール

- 概要 1

- DBFS_ROLEロール 1

- DBMS_CREDENTIAL.CREATE_CREDENTIALプロシージャ 1

- DBMS_CRYPTOパッケージ

- 例 1

- DBMS_CRYPTO PL/SQLパッケージ

- FIPS 140-2に対する有効化 1

- DBMS_FGAパッケージ

- 概要 1

- ADD_POLICYプロシージャ 1

- DISABLE_POLICYプロシージャ 1

- DROP_POLICYプロシージャ 1

- エディション 1

- ENABLE_POLICYプロシージャ 1

- PDB 1

- DBMS_NETWORK_ACL_ADMIN.REMOVE_HOST_ACEプロシージャ 1

- DBMS_RLS.ADD_POLICY

- sec_relevant_cols_optパラメータ 1

- sec_relevant_colsパラメータ 1

- DBMS_RLS.ADD_POLICYプロシージャ

- 透過的機密データ保護ポリシー 1

- DBMS_SESSION.SET_CONTEXTプロシージャ

- 概要 1

- 構文 1

- usernameおよびclient_idの設定 1

- DBMS_SESSION.SET_IDENTIFIERプロシージャ

- クライアント・セッションID、設定 1

- DBMS_APPLICATION.SET_CLIENT_INFOの値、上書き 1

- DBMS_SESSIONパッケージ

- クライアント識別子、使用 1

- グローバル・アプリケーション・コンテキスト、使用 1

- SET_CONTEXTプロシージャ

- 概要 1

- DBSNMPユーザー・アカウント

- パスワードの使用 1

- DDL

- 「データ定義言語」を参照

- デバッグ

- Javaストアド・プロシージャ 1

- PL/SQLストアド・プロシージャ 1

- デフォルト・パスワード

- change_on_installまたはmanagerパスワード 1

- 変更、重要性 1

- 検索 1

- デフォルトの権限 1

- デフォルト・プロファイル

- 概要 1

- デフォルト・ロール

- ユーザーに対する設定 1

- 指定 1

- デフォルト

- 表領域割当て制限 1

- ユーザー表領域 1

- デフォルトのユーザー

- アカウント 1

- Enterprise Managerアカウント 1

- パスワード 1

- 定義者権限

- 概要 1

- コード・ベース・アクセス制御

- 概要 1

- プログラム・ユニットへのロールの付与と取消し 1

- コード・ベース・アクセス制御の使用方法 1

- 実行者権限との比較 1

- 使用時の例 1

- プロシージャ権限、使用 1

- プロシージャのセキュリティ 1

- スキーマ権限 1

- セキュア・アプリケーション・ロール 1

- Oracle Virtual Private Database関数での使用 1

- ビュー 1

- DELETE_CATALOG_ROLEロール

- SYSスキーマ・オブジェクト、アクセスの許可 1

- サービス拒否(DoS)攻撃

- 概要 1

- サービス拒否(DoS)攻撃

- 不正なパケット、防止 1

- ネットワーク、保護 1

- 同時パスワード推測 1

- Department of Defense Database Security Technical Implementation Guide 1 , 2

- ディクショナリ保護メカニズム 1

- ディクショナリ表

- 監査 1

- Diffie-Hellman 1

- Diffie-Hellman鍵交換アルゴリズム 1

- ディレクトリ

- 監査 1

- ディレクトリ認証、SYSDBAまたはSYSOPERアクセスの構成 1

- ディレクトリベース・サービスでの認証 1

- ディレクトリ・オブジェクト

- EXECUTE権限の付与 1

- ダイレクト・パス・ロード

- ファイングレイン監査の影響 1

- 不要なサービスを使用禁止にする

- FTP、TFTP、TELNET 1

- ディスパッチャ・プロセス(Dnnn)

- セッション当たりのSGA領域の制限 1

- 分散データベース

- 監査 1

- DML

- 「データ操作言語」を参照

- 駆動コンテキスト 1

- DROP PROFILE文

- 例 1

- DROP ROLE文

- 例 1

- セキュリティ・ドメイン、関連 1

- DROP USER文

- 概要 1

- 削除したユーザーのスキーマ・オブジェクト 1

- DVFスキーマ

- ORA_DV_AUDPOLの事前定義の監査ポリシー 1

- Oracle Virtual Private Databaseの動的ポリシー・タイプ 1

- DYNAMICポリシー・タイプ 1

E

- ECB暗号文の暗号化モード 1

- エディション

- アプリケーション・コンテキスト、影響 1

- ファイングレイン監査パッケージ、結果 1

- グローバル・アプリケーション・コンテキスト、影響 1

- Oracle Virtual Private Databaseパッケージ、結果 1

- EJBCLIENTロール 1

- EM_EXPRESS_ALLロール 1

- EM_EXPRESS_BASICロール 1

- 電子メール・アラートの例 1

- 暗号化

- アクセス制御 1

- BLOB 1

- 課題 1

- データ・セキュリティ、解決しない問題 1

- データ転送 1

- 削除された暗号化データ 1

- 例 1

- 情報の検索 1

- 暗号化列のファイングレイン監査ポリシー 1

- 索引付けされたデータ 1

- 鍵の生成 1

- 鍵、変更 1

- 鍵の格納 1

- 鍵の転送 1

- 不正なデータベース管理者 1

- ネットワーク暗号化 1

- ネットワーク通信 1

- 解決しない問題 1

- 透過的データ暗号化 1

- 透過的表領域暗号化 1

- 暗号化とチェックサム

- アクティブ化 1

- ネゴシエーション 1

- パラメータ設定 1

- ENFORCE_CREDENTIAL構成パラメータ

- セキュリティ・ガイドライン 1

- エンタープライズ・ディレクトリ・サービス 1

- エンタープライズ・ロール 1 , 2

- エンタープライズ・ユーザー管理 1

- エンタープライズ・ユーザー

- 集中管理 1

- グローバル・ロール、作成 1

- One Big Application Userの認証、制限 1

- プロキシ認証 1

- 共有スキーマ、ユーザーの保護 1

- エンタープライズ・ユーザー・セキュリティ

- アプリケーション・コンテキスト、グローバルに初期化 1

- プロキシ認証

- Oracle Virtual Private Database、仕組み 1

- エラー・メッセージ

- ORA-12650 1 , 2 , 3 , 4 , 5 , 6

- エラー

- OPW-00005 1

- ORA-00036 1

- ORA-01720 1

- ORA-06512 1 , 2

- ORA-06598 1

- ORA-1000 1

- ORA-1536 1

- ORA-24247 1 , 2 , 3

- ORA-28009 1

- ORA-28017 1

- ORA-28040 1 , 3

- ORA-28046 1

- ORA-28133 1

- ORA-28144 1

- ORA-28575 1

- ORA-45622 1

- 例

- アクセス制御リスト

- 外部ネットワーク接続 1

- ウォレット・アクセス 1

- アカウントのロック 1

- ユーザーSYSの監査 1

- 監査証跡、統合証跡の削除 1

- データの暗号化

- BLOBデータの暗号化および復号化 1

- AES 256ビットを使用した暗号化および復号化プロシージャ 1

- ディレクトリ・オブジェクト、EXECUTE権限の付与 1

- 暗号化プロシージャ 1

- パスワードを読み取るためのJavaコード 1

- CREATE PROFILEを使用したアカウントのロック 1

- ログイン試行の猶予期間 1

- 非データベース・ユーザー認証 1

- O7_DICTIONARY_ACCESSIBILITY初期化パラメータ、設定 1

- パスワード

- エイジングおよび期限切れ 1

- 変更 1

- ユーザーへの作成 1

- 権限

- ADMIN OPTIONの付与 1

- ビュー 1

- プロシージャ権限がパッケージに与える影響 1 , 2

- プロファイル、ユーザーに対する割当て 1

- ロール

- 外部認可方式の変更 1

- アプリケーションによる認可の作成 1

- 外部による認可の作成 1

- パスワードによる認可の作成 1 , 2

- デフォルト、設定 1

- グローバル 1

- SET ROLEを使用したパスワード認証ロールの設定 1

- ビュー 1

- 安全性の高い外部パスワード・ストア 1

- ユーザーのセッションID

- 検索 1

- システム権限とロール、付与 1

- 表領域

- ユーザーに対するデフォルトの割当て 1

- 割当て制限、ユーザーに対する割当て 1

- 一時 1

- 型の作成 1

- ユーザー

- アカウントの作成 1

- GRANT文を使用した作成 1

- 削除 1

- クライアントのプロキシとなる中間層サーバー 1

- オブジェクト権限の付与 1

- プロキシ・ユーザー、接続 1

- 例外

- WHEN NO DATA FOUND、アプリケーション・コンテキスト・パッケージで使用 1

- WHEN OTHERS、トリガーで使用

- 開発環境(デバッグ)の例 1

- 本番環境の例 1

- 排他モード

- SHA-2パスワード・ハッシュ・アルゴリズム、使用可能 1

- EXECUTE_CATALOG_ROLEロール

- SYSスキーマ・オブジェクト、アクセスの許可 1

- EXECUTE ANY LIBRARY文

- セキュリティ・ガイドライン 1

- EXEMPT ACCESS POLICY権限

- Oracle Virtual Private Databaseの規定対象、除外 1

- EXP_FULL_DATABASEロール

- 概要 1

- パスワードを期限切れにする

- 明示的 1

- データのエクスポート

- Oracle Virtual Private Databaseへのダイレクト・パス・エクスポートの影響 1

- ポリシーの規定 1

- 外部認証

- 概要 1

- メリット 1

- ネットワーク 1

- オペレーティング・システム 1

- ユーザーの作成 1

- 外部ネットワーク・サービス、ファイングレイン・アクセス

- 「アクセス制御リスト(ACL)」を参照

- 外部ネットワーク・サービス、構文 1

- 外部プロシージャ

- extprocプロセスの構成 1

- 資格証明 1

- DBMS_CREDENTIAL.CREATE_CREDENTIALプロシージャ 1

- レガシー・アプリケーション 1

- セキュリティ・ガイドライン 1

- 外部表 1

- extprocプロセス

- 概要 1

- 資格証明の構成 1

- レガシー・アプリケーション 1

F

- ログインの失敗

- アカウントのロック 1

- パスワード管理 1

- 再設定 1

- 認証フォールバック、Kerberos 1

- 米国連邦情報処理標準(FIPS)

- DBMS_CRYPTOパッケージ 1

- FIPS 140-2

- 暗号スイート 1

- インストール後のチェック 1

- SSLFIPS_140 1

- 接続の検証 1

- FIPS 140-2 Level 2の証明書 1

- 透過的データ暗号化 1

- ファイル

- BFILE

- オペレーティング・システムのアクセス、制限 1

- BLOB 1

- 鍵 1

- listener.oraファイル

- セキュリティに関するガイドライン 1 , 2

- リスナー・アクセスの制限 1

- server.key暗号化ファイル 1

- シンボリック・リンク、制限 1

- tnsnames.ora 1

- ファイングレイン・アクセス・コントロール

- 「Oracle Virtual Private Database (VPD)」を参照

- ファイングレイン監査

- 概要 1

- アラート、ポリシーへの追加 1

- 監査証跡のアーカイブ 1

- 列、特定 1

- DBMS_FGAパッケージ 1

- データのダイレクト・ロード 1

- エディションベースの再定義 1

- エディション、結果 1

- トレース・ファイルの確認によるエラーの検索 1

- 監査レコードの生成方法 1

- 使用方法 1

- ポリシー

- 追加 1

- 無効化 1

- 削除 1

- 使用可能 1

- 変更 1

- ポリシー作成の構文 1

- 必要な権限 1

- レコード

- アーカイブ 1

- VPD述語 1

- fips.oraファイル 1

- FIPS 140-2暗号ライブラリ

- 概要 1

- FIPSパラメータ

- 構成 1

- ファイアウォール

- 使用に関するアドバイス 1

- データベース・サーバーの場所 1

- ポート 1

- サポートされているタイプ 1

- フラッシュバック問合せ

- Oracle Virtual Private Database、仕組み 1

- 外部キー

- 親キーを使用するための権限 1

- FTPサービス 1

- ファンクション

- 監査 1 , 2

- ロールの付与 1

- Oracle Virtual Private Database

- コンポーネント 1

- 実行に使用する権限 1

- 権限 1

- ロール 1

G

- GATHER_SYSTEM_STATISTICSロール 1

- GLOBAL_AQ_USER_ROLEロール 1

- GLOBAL_EXTPROC_CREDENTIAL構成パラメータ

- セキュリティ・ガイドライン 1

- グローバル・アプリケーション・コンテキスト

- 概要 1

- 非データベース・ユーザーの認証 1

- 全ユーザーにグローバルに設定された値をチェック 1

- 全ユーザーにグローバルに設定された値を消去 1

- コンポーネント 1

- エディション、影響 1

- 非データベース・ユーザーを認証する例 1

- 異なるアプリケーションに移動するユーザーを認証する例 1

- 全ユーザーに値を設定する例 1

- Oracle RAC環境 1

- Oracle RACインスタンス 1

- 所有権 1

- PL/SQLパッケージの作成 1

- プロセス、軽量ユーザー 1

- プロセス、標準 1

- 全ユーザーを対象として値をグローバルに共有 1

- システム・グローバル領域 1

- クライアント・セッションIDの例 1

- One Big Application Userシナリオの使用 1

- 使用 1

- グローバル認証

- 概要 1

- メリット 1

- プライベート・スキーマを持つユーザーの作成 1

- スキーマを共有するユーザーの作成 1

- グローバル認可

- 概要 1

- メリット 1

- ロールの作成 1

- ロール 1

- グローバル・ロール

- 概要 1

- グローバル・ユーザー 1

- ログイン試行の猶予期間

- 例 1

- パスワード期限切れの猶予期間 1

- GRANT ALL PRIVILEGES文

- SELECT ANY DICTIONARY権限、除外 1

- GRANT ANY PRIVILEGEシステム権限 1

- GRANT CONNECT THROUGH句

- FAILED_LOGIN_ATTEMPTSパラメータ設定時の考慮事項 1

- プロキシ認可 1

- 権限とロールの付与

- 概要 1

- 情報の検索 1

- ALLの指定 1

- GRANT文

- ADMIN OPTION 1

- 新規ユーザーの作成 1

- オブジェクト権限 1 , 2

- システム権限とロール 1

- 有効になるとき 1

- WITH GRANT OPTION 1

- セキュリティに関するガイドライン

- 監査 1

- カスタム・インストール 1

- データ・ファイルおよびディレクトリ 1

- 機密性の高いデータの暗号化 1

- セキュリティに関するガイドライン

- カスタム・インストール 1

- インストールと構成 1

- ネットワーク・セキュリティ 1

- オペレーティング・システム・アカウント、権限の制限 1

- オペレーティング・システム・ユーザー、数の制限 1

- ORACLE_DATAPUMPアクセス・ドライバ 1

- Oracleホームのデフォルト権限、変更禁止 1

- パスワード 1

- 製品およびオプション

- 必要な場合のみインストール 1

- サンプル・スキーマ 1

- サンプル・スキーマ

- 本番のために削除または再びロック 1

- テスト・データベース 1

- Secure Socket Layer

- モード 1

- TCPSプロトコル 1

- シンボリック・リンク、制限 1

- ユーザー・アカウントと権限 1

H

- ハッカー

- 「セキュリティ攻撃」を参照

- ハンドシェイク

- SSL 1

- HS_ADMIN_EXECUTE_ROLEロール

- 概要 1

- HS_ADMIN_ROLEロール

- 概要 1

- HS_ADMIN_SELECT_ROLEロール

- 概要 1

- HTTP認証

- 「アクセス制御リスト(ACL)」、「ウォレット・アクセス」を参照

- HTTPS

- ポート、正しい実行 1

I

- IMP_FULL_DATABASEロール

- 概要 1

- 索引付けされたデータ

- 暗号化 1

- 間接的に付与されたロール 1

- INHERIT ANY PRIVILEGES権限

- 概要 1

- 管理 1

- 強力なユーザーからの取消し 1

- 付与を必要とする場合 1

- INHERIT PRIVILEGES権限

- 概要 1

- 監査 1

- 管理 1

- 付与を必要とする場合 1

- 初期化パラメータ・ファイル

- Kerberosを使用するクライアントとサーバーのパラメータ 1

- RADIUSを使用するクライアントとサーバーのパラメータ 1

- SSLを使用するクライアントとサーバーのパラメータ 1

- 初期化パラメータ

- アプリケーションの保護 1

- MAX_ENABLED_ROLES 1

- O7_DICTIONARY_ACCESSIBILITY 1

- OS_AUTHENT_PREFIX 1

- OS_ROLES 1

- SEC_MAX_FAILED_LOGIN_ATTEMPTS 1

- SEC_RETURN_SERVER_RELEASE_BANNER 1

- SEC_USER_AUDIT_ACTION_BANNER 1

- SEC_USER_UNAUTHORIZED_ACCESS_BANNER 1

- INSERT権限

- 付与 1

- 取消し 1

- インストール

- セキュリティに関するガイドライン 1

- 侵入者

- 「セキュリティ攻撃」を参照

- 実行者権限

- 概要 1

- コード・ベース・アクセス制御

- 概要 1

- プログラム・ユニットへのロールの付与と取消し 1

- コード・ベース・アクセス制御の使用方法 1

- チュートリアル 1

- 定義者権限との比較 1

- 制御されたステップイン 1

- プロシージャ権限、使用 1

- プロシージャのセキュリティ 1

- セキュア・アプリケーション・ロール 1

- セキュア・アプリケーション・ロール、使用可能にするための要件 1

- セキュリティ上のリスク 1

- ビュー

- 概要 1

- 実行者権限ビューを実行したユーザーの確認 1

- IPアドレス

- 偽造 1

J

- JAVA_ADMINロール 1

- JAVA_DEPLOYロール 1

- Javaバイト・コードの不明瞭化 1

- Java Database connectivity (JDBC)

- Oracle Advanced Securityの実装 1

- Java Database Connectivity(JDBC)

- 構成パラメータ 1

- Oracleの拡張機能 1

- シン・ドライバの機能 1

- JAVADEBUGPRIVロール 1

- Java Debug Wire Protocol (JDWP)

- デバッグ操作のネットワーク・アクセス 1

- JAVAIDPRIVロール 1

- Javaスキーマ・オブジェクト

- 監査 1

- Javaストアド・プロシージャ

- デバッグ操作のネットワーク・アクセス 1

- JAVASYSPRIVロール 1

- JAVAUSERPRIVロール 1

- JDBC

- 「Java Database Connectivity」を参照

- JDBC接続

- JDBC/OCIプロキシ認証

- 複数のユーザー・セッション 1

- Oracle Virtual Private Database 1

- JDBCシン・ドライバ・プロキシ認証

- 構成 1

- 実際のユーザー 1

- JDeveloper

- Javaデバッグ・ワイヤ・プロトコルを使用したデバッグ 1

- JMXSERVERロール 1

K

- Kerberos

- 認証アダプタのユーティリティ 1

- 認証フォールバック動作 1

- 認証の構成 1 , 2

- データベース・サーバーの構成 1

- Windows 2008メイン・コントローラKDCの構成 1

- データベースへの接続 1

- kinstance 1

- kservice 1

- レルム 1

- sqlnet.oraファイルのサンプル 1

- システム要件 1

- Kerberos認証

- SYSDBAまたはSYSOPERアクセスの構成 1

- パスワード管理 1

- Kerberos Key Distribution Center (KDC) 1

- 鍵の生成

- 暗号化 1

- 鍵の格納

- 暗号化 1

- 鍵の転送

- 暗号化 1

- kinstance (Kerberos) 1

- kservice (Kerberos) 1

L

- LBAC_DBAロール 1

- LBACSYS.ORA_GET_AUDITED_LABELファンクション

- 概要 1

- LBACSYSスキーマ

- ORA_DV_AUDPOLの事前定義の監査ポリシー 1

- ldap.ora

- 認証なし用に使用するディレクトリのSSLポート 1

- 最低限の権限の原則

- 概要 1

- ユーザー権限の付与 1

- 中間層の権限 1

- ライブラリ

- 監査 1

- 軽量ユーザー

- グローバル・アプリケーション・コンテキストを使用した例 1

- Lightweight Directory Access Protocol(LDAP) 1

- リスナー

- エンドポイント

- SSL構成 1

- Oracle所有者以外 1

- オンライン管理の回避 1

- 権限の制限 1

- 安全性の高い管理 1

- listener.oraファイル

- リモート管理 1

- デフォルトの場所 1

- FIPS 140-2暗号スイートの設定 1

- オンライン管理、回避 1

- Oracleウォレットの設定 1

- TCPS、保護 1

- ローカル権限付与

- 概要 1

- 付与 1

- 取消し 1

- ローカル・ロール

- 概要 1

- 作成 1

- 作成のルール 1

- ローカル・ユーザー・アカウント

- 作成 1

- ローカル・ユーザー

- 概要 1

- ロックおよび期限切れ

- デフォルトのアカウント 1

- 事前定義のユーザー・アカウント 1

- ログ・ファイル

- 信頼できるユーザーが所有 1

- 論理読取りの制限 1

- ログイン・トリガー

- 外部で初期化されたアプリケーション・コンテキスト 1

- アプリケーション・コンテキスト・パッケージ 1

- データベース・セッションのアプリケーション・コンテキスト・パッケージの実行 1

- セキュア・アプリケーション・ロール 1

- LOGSTDBY_ADMINISTRATORロール 1

M

- 不正なデータベース管理者 1

- 「セキュリティ攻撃」も参照

- デフォルトのmanagerパスワード 1

- RADIUSサーバーによるロールの管理 1

- マテリアライズド・ビュー

- 監査 1

- MD5メッセージ・ダイジェストのアルゴリズム 1

- メモリー

- ユーザー、表示 1

- MERGE INTO文、DBMS_RLS.ADD_POLICY statement_typesパラメータの影響を受けた 1

- メソッド

- 権限 1

- Microsoft Windows

- Kerberos

- Windows 2008メイン・コントローラKDCの構成 1

- 中間層システム

- クライアント識別子 1

- エンタープライズ・ユーザーでの接続 1

- パスワード・ベースのプロキシ認証 1

- 権限、制限 1

- プロキシ認証ユーザー 1

- プロキシとして機能していても認証されないユーザー 1

- データベースへのユーザーの再認証 1

- USERENVネームスペース属性、アクセス 1

- マイニング・モデル

- 監査 1

- 混合モードの監査機能 1

- ユーザー・アクションの監視 1

- 「監査」、「標準監査」、「ファイングレイン監査」も参照

- 複数のクライアント・ネットワーク・セッションの多重化 1

- マルチテナント・コンテナ・データベース(CDB)

- 「CDB」を参照

- My Oracle Support

- セキュリティ・パッチ、ダウンロード 1

N

- nCipherハードウェア・セキュリティ・モジュール

- Oracle Netトレースを使用したトラブルシューティング 1

- Net8

- 「Oracle Net」を参照

- Netscape社 1

- ネットワーク認証

- 外部認証 1

- 保護に関するガイドライン 1

- ロール、使用した付与 1

- Secure Sockets Layer 1

- スマートカード 1

- サード・パーティ・サービス 1

- トークン・カード 1

- X.509証明書 1

- ネットワーク接続

- サービス拒否(DoS)攻撃、対処 1

- セキュリティに関するガイドライン 1 , 2 , 3

- 保護 1

- ネットワーク暗号化

- 概要 1

- 構成 1

- ネットワーク暗号化

- 無効化 1

- ネットワークIPアドレス

- セキュリティに関するガイドライン 1

- 非データベース・ユーザー

- 概要 1

- 監査 1

- セッション・データの消去 1

- クライアント・セッション・ベース・アプリケーション・コンテキストの作成 1

- グローバル・アプリケーション・コンテキスト

- パッケージの例 1

- 使用する理由 1

- 設定 1

- チュートリアル 1

- One Big Application Userの認証

- 概要 1

- 使用できない機能 1

- セキュリティ上のリスク 1

- Oracle Virtual Private Database

- 仕組み 1

- ポリシー・グループの作成の例 1

O

- O7_DICTIONARY_ACCESSIBILITY初期化パラメータ

- 概要 1

- データ・ディクショナリの保護 1

- デフォルト設定 1

- データ・ディクショナリの保護 1

- 不明瞭化 1

- オブジェクト権限

- 概要 1

- 所有者にかわる付与 1

- 管理 1

- 取消し 1

- 所有者にかわる取消し 1

- スキーマ・オブジェクト権限 1

- シノニム 1

- 共通権限付与 1

- オブジェクト

- アプリケーション、権限の管理 1

- 権限の付与 1

- 権限

- アプリケーション 1

- 管理 1

- 共有スキーマでの保護 1

- 一意スキーマでの保護 1

- SYSスキーマ、アクセス 1

- オブジェクト・タイプ

- 監査 1

- OEM_ADVISORロール 1

- OEM_MONITORロール 1

- OFB暗号文の暗号化モード 1

- okcreate

- Kerberosアダプタ・ユーティリティ 1

- okdstry

- Kerberosアダプタ・ユーティリティ 1

- okinit

- Kerberosアダプタ・ユーティリティ 1

- oklist

- Kerberosアダプタ・ユーティリティ 1

- OLAP_DBAロール 1

- OLAP_USERロール 1

- OLAP_XS_ADMINロール 1

- One Big Application Userの認証

- 「非データベース・ユーザー」を参照

- オペレーティング・システム

- アカウント 1

- 認証

- 概要 1

- メリット 1

- デメリット 1

- 外部 1

- ロール、使用 1

- デフォルトの権限 1

- ロールを使用可能および使用禁止にする方法 1

- オペレーティング・システム・アカウント権限、制限 1

- ロール識別機能 1

- ロール、使用した付与 1

- ロール 1

- ユーザー、数の制限 1

- OPTIMIZER_PROCESSING_RATEロール 1

- OPW-00005エラー 1

- ORA_ACCOUNT_MGMTの事前定義の統合監査ポリシー 1

- ORA_CIS_RECOMMENDATIONSの事前定義の統合監査ポリシー 1

- ORA_DATABASE_PARAMETERの事前定義の統合監査ポリシー 1

- ORA_DV_AUDPOLの事前定義の統合監査ポリシー 1

- ORA_LOGON_FAILURESの事前定義の統合監査ポリシー 1

- ORA_SECURECONFIG事前定義の統合監査ポリシー 1

- ORA-01720エラー 1

- ORA-06512エラー 1 , 2

- ORA-06598エラー 1

- ORA-12650エラー 1

- ORA-1536エラー 1

- ORA-24247エラー 1 , 2 , 3

- ORA-28009エラー 1

- ORA-28017エラー 1

- ORA-28040エラー 1 , 2

- ORA-28575エラー 1

- ORA-40300エラー 1

- ORA-40301エラー 1

- ORA-40302エラー 1

- ORA-45622エラー 1

- ORACLE_DATAPUMPアクセス・ドライバ

- セキュリティに関するガイドライン 1

- Oracle Advanced Security

- sqlnet.oraファイルのチェックサムのサンプル 1

- 構成パラメータ 1

- sqlnet.oraファイルの暗号化のサンプル 1

- Java実装、 1 , 2

- ネットワーク認証サービス 1

- ネットワーク・トラフィックの暗号化 1

- SSL機能 1

- アプリケーション・スキーマへのユーザー・アクセス 1

- Oracle Call Interface(OCI)

- アプリケーション・コンテキスト、クライアント・セッション・ベース 1

- プロキシ認証

- Oracle Virtual Private Database、仕組み 1

- 実際のユーザーによるプロキシ認証 1

- セキュリティに関する初期化パラメータ 1

- Oracle Connection Manager

- クライアント・ネットワークの保護 1

- Oracle Database Enterprise User Security

- パスワードのセキュリティ脅威 1

- Oracle Database Real Application Clusters

- 監査レコードのアーカイブ・タイムスタンプ 1

- グローバル・コンテキスト 1

- Oracle Database Real Application Security

- ALL監査イベント 1

- 監査 1

- セキュリティ・クラスおよびACLの監査イベント 1

- セッションの監査イベント 1

- Oracle Database Vault

- 監査 1

- コマンド・ルール、監査イベント 1

- Data Pump、監査イベント 1

- 有効化と無効化、監査イベント 1

- ファクタ、監査イベント 1

- OLS、監査イベント 1

- レルム、監査イベント 1

- ルール・セットおよびルール、監査イベント 1

- セキュア・アプリケーション・ロール、監査イベント 1

- Oracle Data Guard

- SYSDG管理権限 1

- Oracle Data Mining

- 監査イベント 1

- Oracle Data Pump

- 監査イベント 1

- VPDポリシーからのエクスポート・データ 1

- Oracle Developer Tools For Visual Studio (ODT)

- Javaデバッグ・ワイヤ・プロトコルを使用したデバッグ 1

- Oracle Enterprise Manager

- PDB 1

- 統計モニター 1

- Oracle Enterprise Security Manager

- ロール管理 1

- Oracleホーム

- デフォルトの権限、変更禁止 1

- Oracle Internet Directory

- Diffie-Hellman SSLポート 1

- Oracle Internet Directory(OID)

- ディレクトリベース・サービスを使用した認証 1

- SYSDBAおよびSYSOPERのアクセス、管理 1

- Oracle Java Virtual Machine(OJVM)

- 権限、制限 1

- Oracle Label Security

- 監査イベント 1

- 監査 1

- ユーザー・セッション・ラベルの監査イベント 1

- Oracle Label Security(OLS)

- Oracle Virtual Private Database、使用 1

- OracleMetaLink

- 「My Oracle Support」を参照

- Oracle Net

- ファイアウォールのサポート 1

- Oracleパラメータ

- 認証 1

- Oracle Password Protocol 1

- Oracle Real Application Clusters

- グローバル・アプリケーション・コンテキスト 1

- Oracle Recovery Manager

- 監査イベント 1

- 監査 1

- SYSBACKUP管理権限 1

- Oracle SQL*Loader

- ダイレクト・ロード・パスの監査イベント 1

- Oracle Technology Network

- セキュリティ・アラート 1

- Oracle Virtual Private Database

- データ・ポンプ・エクスポートを使用してデータをエクスポート 1

- Oracle Virtual Private Database(VPD)

- 概要 1

- ANSI操作 1

- アプリケーション・コンテキスト

- チュートリアル 1

- 使用 1

- アプリケーション

- 仕組み 1

- データベース・ユーザーであるユーザー、仕組み 1

- セキュリティのために使用するアプリケーション 1

- 自動再解析、仕組み 1

- メリット 1

- CDB 1

- 列レベル 1

- 列レベルの表示 1

- 列のマスク動作

- 使用可能 1

- 制限 1

- コンポーネント 1

- 構成 1

- カーソル、共有 1

- エディションベースの再定義 1

- エディション、結果 1

- エンタープライズ・ユーザー・セキュリティ・プロキシ認証、仕組み 1

- データのエクスポート 1

- 情報の検索 1

- フラッシュバック問合せ、仕組み 1

- 関数

- コンポーネント 1

- 実行方法 1

- JDBCプロキシ認証、仕組み 1

- 非データベース・ユーザー・アプリケーション、仕組み 1

- OCIプロキシ認証、仕組み 1

- Oracle Label Security

- 動作の例外 1

- 使用 1

- 外部結合操作 1

- パフォーマンスの利点 1

- ポリシー、Oracle Virtual Private Database

- 概要 1

- アプリケーション、検証 1

- データベース・オブジェクトへの付加 1

- 列の表示 1

- 列レベルの表示、デフォルト 1

- 動的 1

- 複数 1

- パフォーマンスの最適化 1

- 実行に使用する権限 1

- SQL文、指定 1

- ポリシー・グループ

- 概要 1

- メリット 1

- 作成 1

- デフォルト 1

- 例、実装 1

- ポリシー・タイプ

- 状況依存、概要 1

- 状況依存、既存のポリシーの変更 1

- 状況依存、監査対象 1

- 状況依存、作成 1

- 状況依存、リフレッシュ 1

- 状況依存、評価の制限 1

- 状況依存、使用する場合 1

- DYNAMIC 1

- 動的、監査対象 1

- 共有の状況依存、概要 1

- 共有の状況依存、使用する場合 1

- 共有の静的、概要 1

- 共有の静的、使用する場合 1

- 静的、概要 1

- 静的、監査対象 1

- 静的、使用する場合 1

- 機能の要約 1

- ポリシーの作成に必要な権限 1

- ポリシー内のSELECT FOR UPDATE文 1

- チュートリアル、単純 1

- ユーザー・モデル 1

- Webベースのアプリケーション、仕組み 1

- Oracle Virtual Private Datebase (VPD)

- 述語

- ファイングレイン監査ポリシーの監査対象 1

- Oracle Wallet Manager

- X.509v3証明書 1

- Oracleウォレット

- 認証方式 1

- 場所の設定 1

- sqlnet.listener.ora設定 1

- sqlnet.oraロケーションの設定 1

- orapkiユーティリティ

- 概要 1

- 証明書リクエストのウォレットへの追加 1

- ウォレットへのルート証明書の追加 1

- ウォレットへの信頼できる証明書の追加 1

- ウォレットへのユーザー証明書の追加 1

- cert createコマンド 1

- cert displayコマンド 1

- 証明書失効リスト 1

- ウォレット・パスワードの変更 1

- AES256アルゴリズムの使用を目的としたウォレットの変換 1

- ローカルの自動ログイン・ウォレットの作成 1

- 自動ログイン・ウォレットの作成 1 , 2

- ウォレットの作成 1

- テスト用の署名付き証明書の作成 1

- crl deleteコマンド 1

- crl displayコマンド 1

- crl hashコマンド 1

- crl listコマンド 1

- crl uploadコマンド 1

- 例 1

- ウォレットからの証明書のエクスポート 1

- ウォレットからの証明書リクエストのエクスポート 1

- 証明書失効リストの管理 1

- 構文 1

- テスト証明書の表示 1

- ウォレットの表示 1

- wallet addコマンド 1

- wallet convertコマンド 1

- wallet createコマンド 1

- wallet displayコマンド 1

- wallet exportコマンド 1

- ORAPWDユーティリティ

- パスワードの大/小文字の区別 1

- SYSパスワードの変更 1

- ORDADMINロール 1

- OS_AUTHENT_PREFIXパラメータ 1

- OS_ROLES初期化パラメータ

- オペレーティング・システムによる認可 1

- オペレーティング・システムによるロール付与 1

- REMOTE_OS_ROLES 1

- 使用 1

- OSS.SOURCE.MY_WALLETパラメータ 1 , 2

- 外部結合操作

- Oracle Virtual Private Databaseの影響 1

P

- パッケージ

- 監査 1 , 2

- 例 1

- 権限の使用例 1

- ロールの付与 1

- 権限

- 構成メンバーごとに分割 1

- 実行 1 , 2

- パラレル実行サーバー 1

- パラレル問合せ、SYS_CONTEXT 1

- パラメータ

- 認証

- Kerberos 1

- RADIUS 1

- Secure Sockets Layer(SSL) 1

- JDBC用の構成 1

- 暗号化とチェックサム 1

- パスフレーズ

- server.keyファイルの読取りと解析 1

- PASSWORD_LIFE_TIMEプロファイル・パラメータ 1

- PASSWORD_LOCK_TIMEプロファイル・パラメータ 1

- PASSWORD_REUSE_MAXプロファイル・パラメータ 1

- PASSWORD_REUSE_TIMEプロファイル・パラメータ 1

- PASSWORDコマンド

- 概要 1

- パスワード複雑度関数

- 概要 1

- ora12c_strong_verify_function 1

- ora12c_verify_function 1

- 必要な権限 1

- パスワード・ファイル

- 大/小文字の区別、SEC_CASE_SENSITIVE_LOGONパラメータへの影響 1

- 管理者を認証するための使用方法 1

- パスワード

- 10Gパスワード・バージョン、確認と再設定 1

- 管理の概要 1

- アカウントのロック 1

- 管理者

- 認証 1

- 保護に関するガイドライン 1

- エイジングおよび期限切れ 1

- 変更 1

- ALTER PROFILE文 1

- アプリケーション設計のガイドライン 1

- アプリケーション、パスワード保護の戦略 1

- 総当り攻撃 1

- 大/小文字の区別、構成 1

- ロールに対する変更 1

- 複雑度、規定に関するガイドライン 1

- 複雑度の検証

- 概要 1

- 指定しない接続 1

- CREATE PROFILE文 1

- クリアテキストで格納する危険性 1

- データベース・ユーザーの認証 1

- デフォルト、検索 1

- デフォルト・プロファイルの設定

- 概要 1

- デフォルトのユーザー・アカウント 1

- 誤ったパスワードに対する遅延 1

- 期間 1

- 暗号化 1 , 2

- 作成例 1

- 期限切れ

- 明示的 1

- 手順 1

- プロキシ・アカウントのパスワード 1

- 猶予期間 1

- ログインの失敗、リセット 1

- 猶予期間、例 1

- セキュリティに関するガイドライン 1

- 履歴 1 , 3

- パスワードを読み取るためのJavaコード例 1

- 長さ 1

- 存続期間 1

- 存続期間の設定が低すぎます 1

- ロック時間 1

- 管理ルール 1

- 管理 1

- 最大再利用回数 1

- ORAPWDユーティリティ 1

- PASSWORD_LOCK_TIMEプロファイル・パラメータ 1

- PASSWORD_REUSE_MAXプロファイル・パラメータ 1

- PASSWORD_REUSE_TIMEプロファイル・パラメータ 1

- パスワードの複雑度検証

- データベースによるチェック方法 1

- ora12c_verify_functionファンクション 1

- 必要な権限 1

- verify_function_11Gファンクション 1

- パスワード・ファイルのリスク 1

- ポリシー 1

- ロールに対して変更するための権限 1

- 変更するための権限 1

- 保護、組込み 1

- プロキシ認証 1

- 要件

- 追加 1

- 最低 1

- 再利用 1 , 2

- パスワードの再利用 1

- ロール・パスワードの大/小文字の区別 1

- パスワードによって認証されるロール 1

- SET ROLE文によって使用可能になるロール 1

- 安全性の高い外部パスワード・ストア 1

- セキュリティ上のリスク 1

- SYSアカウント 1

- SYSおよびSYSTEM 1

- ロールでの使用 1

- utlpwdmg.sqlパスワード・スクリプト

- パスワード管理 1

- SHA-512ハッシュ関数を使用した検証 1

- バージョン、管理 1

- PDB_DBAロール 1

- PDB

- 監査

- 許可された監査設定のタイプ 1

- 統合監査ポリシー構文 1

- 監査対象 1

- 共通ロール

- 概要 1

- 作成 1

- 付与 1

- 動作の概要 1

- 管理に必要な権限 1

- 取消し 1

- 作成のルール 1

- 共通ユーザー

- 概要 1

- PDBのデータへのアクセス 1

- 作成 1

- 権限情報の表示 1

- Enterprise Manager

- 概要 1

- 共通ロールの作成 1

- 共通ユーザーの作成 1

- ローカル・ロールの作成 1

- ローカル・ユーザーの作成 1

- 共通ロールの削除 1

- 共通ユーザーの削除 1

- ローカル・ロールの削除 1

- ローカル・ユーザーの削除 1

- 共通ロールの編集 1

- 共通ユーザーの編集 1

- ローカル・ロールの編集 1

- ローカル・ユーザーの編集 1

- ログイン 1

- 共通権限付与の取消し 1

- ローカル権限付与の取消し 1

- 別のコンテナへの切替え 1

- ファイングレイン監査ポリシー 1

- ローカル・ロール

- 概要 1

- 作成 1

- 作成のルール 1

- ローカル・ユーザー

- 概要 1

- 作成 1

- 権限

- 共通 1

- 付与 1

- 影響 1

- オブジェクト 1

- 取消し 1

- 情報の表示 1

- PUBLICロール 1

- sqlnet.ora設定 1

- 透過的機密データ保護 1

- 情報の表示 1

- 仮想プライベート・データベース・ポリシー 1

- パフォーマンス

- アプリケーション・コンテキスト 1

- 監査 1

- Oracle Virtual Private Databaseポリシー 1

- Oracle Virtual Private Databaseのポリシー・タイプ 1

- リソース制限 1

- 権限

- デフォルト 1

- ランタイム機能 1

- PKCS #11デバイス 1

- PKCS #11エラー

- ORA-40300 1

- ORA-40301 1

- ORA-40302 1

- PKI

- 「公開鍵インフラストラクチャ(PKI)」を参照

- PL/SQL

- プロシージャでのロール 1

- PL/SQLパッケージ

- 監査 1 , 2

- PL/SQLプロシージャ

- アプリケーション・コンテキストの設定 1

- PL/SQLストアド・プロシージャ

- デバッグ操作のネットワーク・アクセス 1

- PMONバックグラウンド・プロセス

- アプリケーション・コンテキスト、クリーン・アップ 1

- 位置パラメータ

- セキュリティ上のリスク 1

- 最小権限の原則

- 概要 1

- ユーザー権限の付与 1

- 中間層の権限 1

- 権限

- 概要 1

- アクセス制御リスト、外部ネットワーク・サービスのチェック 1

- 変更

- パスワード 1

- ユーザー 1

- ロールの認証方式の変更 1

- アプリケーション、管理 1

- 監査、推奨設定 1

- 使用の監査 1

- 取消しによる連鎖 1

- 列 1

- プロシージャのコンパイル 1

- プロシージャの作成または置換 1

- ユーザーの作成 1

- プロファイルの削除 1

- 情報の検索 1

- 付与

- 概要 1 , 2

- 例 1 , 2

- オブジェクト権限 1 , 2

- システム 1

- システム権限 1

- 権限付与、リスト 1

- ロールによるグループ化 1

- 管理 1

- 中間層 1

- オブジェクト

- 付与と取消し 1

- 選択した列 1

- プロシージャ

- 作成と置換 1

- 実行 1

- パッケージ内 1

- READ ANY TABLEシステム権限

- 概要 1

- 制限 1

- READオブジェクト権限 1

- 付与する理由 1

- 権限の取消し

- 概要 1

- オブジェクト 1

- オブジェクト権限、連鎖的な影響 1

- オブジェクト権限、要件 1

- スキーマ・オブジェクト 1

- システム権限の取消し 1

- ロール

- 作成 1

- 削除 1

- 制限 1

- ロール、付与が推奨される理由 1

- スキーマ・オブジェクト

- DML操作とDDL操作 1

- パッケージ 1

- プロシージャ 1

- SELECTシステム権限 1

- 許可されるSQL文 1

- シノニムと基礎オブジェクト 1

- システム

- 付与と取消し 1

- SELECT ANY DICTIONARY 1

- SYSTEMおよびOBJECT 1

- システム権限

- 概要 1

- トリガー権限 1

- Oracle Virtual Private Databaseポリシー関数での使用 1

- ビューに対する権限

- ビューの作成 1

- ビューの使用 1

- ビュー 1

- プロシージャ

- 監査 1 , 2

- コンパイル 1

- 定義者権限

- 概要 1

- ロールの使用禁止 1

- 例 1

- 権限の使用例 1

- ロールの付与 1

- 実行者権限

- 概要 1

- 使用されるロール 1

- プロシージャに対する権限

- 作成または置換 1

- 実行 1

- パッケージ内での実行 1

- 必要な権限 1

- セキュリティの強化 1

- プロセス・モニター(PMON)・プロセス

- タイムアウト・セッションのクリーン・アップ 1

- PRODUCT_USER_PROFILE表

- SQLコマンド、使用禁止 1

- プロファイル・パラメータ

- FAILED_LOGIN_ATTEMPTS 1

- PASSWORD_GRACE_TIME 1 , 2

- PASSWORD_LIFE_TIME 1 , 2 , 3

- PASSWORD_LOCK_TIME 1 , 2

- PASSWORD_REUSE_MAX 1 , 2

- PASSWORD_REUSE_TIME 1 , 2

- プロファイル

- 概要 1

- ユーザーへの割当て 1

- 作成 1

- 削除 1

- 情報の検索 1

- デフォルト・プロファイルの設定の検索 1

- 管理 1

- 削除するための権限 1

- ユーザーに対する指定 1

- 表示 1

- プログラム・ユニット

- ロールの付与 1

- PROVISIONERロール 1

- PROXY_USERSビュー 1

- プロキシ認証

- 概要 1

- メリット 1

- 監査対象の操作 1

- ユーザーの監査 1

- クライアントから中間層を介した順序 1

- プロキシ・ユーザー・アカウントの作成 1

- 中間層

- 認証されないユーザーの認可 1

- ユーザーのプロキシとしての機能とユーザーの認証の認可 1

- 権限の制限 1

- ユーザーの再認証 1

- パスワード、期限切れ 1

- ユーザーの作成に必要な権限 1

- 安全性の高い外部パスワード・ストア、使用 1

- セキュリティ上のメリット 1

- ユーザー、実際の識別情報の引渡し 1

- プロキシ・ユーザー・アカウント

- 作成に必要な権限 1

- 疑似列

- USER 1

- PUBLIC_DEFAULTプロファイル

- プロファイル、削除 1

- 公開鍵インフラストラクチャ(PKI)

- 概要 1

- 公開鍵インフラストラクチャ(PKI)

- 証明書 1

- 認証局 1

- 証明書失効リスト 1

- PKCS #11ハードウェア・デバイス 1

- ウォレット 1

- PUBLICロール

- 概要 1

- CDB

- PUBLICロール 1

- 権限の付与および取消し 1

- プロシージャ 1

- ユーザーのセキュリティ・ドメイン 1

Q

- 割当て制限

- 表領域 1

- 一時セグメント 1

- 無制限 1

- 表示 1

R

- RADIUS

- アカウンティング 1

- 非同期認証モード 1

- 認証モード 1

- 認証パラメータ 1

- チャレンジ・レスポンス

- 認証 1

- ユーザー・インタフェース 1 , 2

- 構成 1

- データベース・リンクはサポートされない 1

- 初期化パラメータ・ファイルの設定 1

- 秘密鍵の場所 1

- 設定する最低限のパラメータ 1

- スマートカード 1 , 2 , 3 , 4

- SQLNET.AUTHENTICATION_SERVICESパラメータ 1

- sqlnet.oraファイルのサンプル 1

- SQLNET.RADIUS_ALTERNATE_PORTパラメータ 1

- SQLNET.RADIUS_ALTERNATE_RETRIESパラメータ 1

- SQLNET.RADIUS_ALTERNATE_TIMEOUTパラメータ 1

- SQLNET.RADIUS_ALTERNATEパラメータ 1

- SQLNET.RADIUS_AUTHENTICATION_INTERFACEパラメータ 1

- SQLNET.RADIUS_AUTHENTICATION_PORTパラメータ 1

- SQLNET.RADIUS_AUTHENTICATION_RETRIESパラメータ 1

- SQLNET.RADIUS_AUTHENTICATIONパラメータ 1

- SQLNET.RADIUS_CHALLENGE_KEYWORDパラメータ 1

- SQLNET.RADIUS_CHALLENGE_RESPONSEパラメータ 1

- SQLNET.RADIUS_CLASSPATHパラメータ 1

- SQLNET.RADIUS_SECRETパラメータ 1

- SQLNET.RADIUS_SEND_ACCOUNTINGパラメータ 1

- 同期認証モード 1

- システム要件 1

- RADIUS認証 1

- READ ANY TABLEシステム権限

- 概要 1

- 制限 1

- READオブジェクト権限

- 概要 1

- 使用のガイドライン 1

- SQL92_SECURITY初期化パラメータ 1

- 読取り

- データ・ブロックの制限 1

- レルム(Kerberos) 1

- REDACT_AUDIT透過的機密データ保護のデフォルトのポリシー 1

- ログ・ファイル

- コミットおよびロールバックされたトランザクションの監査 1

- REFERENCES権限

- CASCADE CONSTRAINTSオプション 1

- 取消し 1 , 2

- REMOTE_OS_AUTHENT初期化パラメータ

- 保護に関するガイドライン 1

- 設定 1

- REMOTE_OS_ROLES初期化パラメータ

- ネットワークでのOSロール管理のリスク 1

- 設定 1

- リモート認証 1

- リモート・デバッグ

- ネットワーク・アクセスの構成 1

- リソース制限

- 概要 1

- 管理ログイン 1

- コール・レベル、制限 1

- セッション当たりの接続時間 1

- CPUタイム、制限 1

- 値の決定 1

- セッション当たりのアイドル時間 1

- 論理読取り、制限 1

- セッション当たりのプライベートSGA領域 1

- プロファイル 1

- セッション・レベル、制限 1

- セッション

- ユーザー当たりの同時数 1

- 経過接続時間 1

- アイドル時間 1

- SGA領域 1

- タイプ 1

- RESOURCE権限

- CREATE SCHEMA文、必要 1

- RESOURCEロール

- 概要 1

- 制限 1

- REVOKE CONNECT THROUGH句

- プロキシ認可の取消し 1

- REVOKE文

- システム権限とロール 1

- 有効になるとき 1

- 権限とロールの取消し

- 連鎖的な影響 1

- 選択した列 1

- REVOKE文 1

- ALLの指定 1

- オペレーティング・システム・ロールを使用した場合 1

- ROLE_SYS_PRIVSビュー

- アプリケーション権限 1

- ROLE_TAB_PRIVSビュー

- アプリケーション権限、検索 1

- ロール識別機能

- オペレーティング・システム・アカウント 1

- ロール

- 概要 1 , 2

- ADM_PARALLEL_EXECUTE_TASKロール 1

- ADMIN OPTION 1

- アプリケーションに使用する利点 1

- アプリケーション 1 , 2 , 3 , 5

- アプリケーション権限 1

- アプリケーション、ユーザー 1

- AUDIT_ADMINロール 1

- AUDIT_VIEWERロール 1

- AUTHENTICATEDUSERロール 1

- 認可 1

- エンタープライズ・ディレクトリ・サービスによる認可 1

- CAPTURE_ADMINロール 1

- CDB_DBAロール 1

- 認可の変更 1

- パスワードの変更 1

- 共通、監査 1

- 共通、付与 1

- CONNECTロール

- 概要 1

- 独自の作成 1

- CSW_USR_ROLEロール 1

- CTXAPPロール 1

- CWM_USERロール 1

- データベース・ロール、ユーザー 1

- DATAPUMP_EXP_FULL_DATABASEロール 1

- DATAPUMP_IMP_FULL_DATABASEロール 1

- DBAロール 1

- DBFS_ROLEロール 1

- DDL文 1

- デフォルト 1

- デフォルト、ユーザーに対する設定 1

- 定義者権限プロシージャでは使用禁止 1

- 依存性管理 1

- 無効化 1

- 削除 1

- EJBCLIENTロール 1

- EM_EXPRESS_ALLロール 1

- EM_EXPRESS_BASICロール 1

- 使用可能または使用禁止 1 , 2

- 使用可能 1 , 2

- エンタープライズ 1 , 2

- EXP_FULL_DATABASEロール 1

- 情報の検索 1

- 機能 1 , 2

- 機能 1

- GATHER_SYSTEM_STATISTICSロール 1

- GLOBAL_AQ_USER_ROLEロール 1

- グローバル認可

- 概要 1

- グローバル・ロール

- 概要 1

- 作成 1

- 外部ソース 1

- 別のロールへの付与 1

- プログラム・ユニットへの付与と取消し 1

- ロールの付与

- 概要 1

- 方法 1

- システム 1

- システム権限 1

- プログラム・ユニットへの付与 1

- GRANT文 1

- セキュリティに関するガイドライン 1

- HS_ADMIN_EXECUTE_ROLEロール 1

- HS_ADMIN_ROLEロール 1

- HS_ADMIN_SELECT_ROLEロール 1

- IMP_FULL_DATABASEロール 1

- アプリケーション 1

- 間接的に付与された 1

- 実行者権限プロシージャの使用 1

- JAVA_ADMINロール 1

- JAVA_DEPLOYロール 1

- JAVADEBUGPRIVロール 1

- JAVAIDPRIVロール 1

- JAVASYSPRIVロール 1

- JAVAUSERPRIVロール 1

- JMXSERVERロール 1

- 担当業務の権限のみ 1

- LBAC_DBAロール 1

- 権限付与のリスト 1

- 権限とロールのリスト 1

- ロールのリスト 1

- LOGSTDBY_ADMINISTRATORロール 1

- オペレーティング・システムを使用した管理 1

- ロールの管理

- 概要 1

- ユーザーの分類 1

- オペレーティング・システムを介した管理 1

- RADIUSサーバーによる管理 1

- 1ユーザーが使用可能にできる最大数 1

- 名前に含まれているマルチバイト・キャラクタ 1

- パスワードに含まれているマルチバイト・キャラクタ 1

- ネーミング 1

- ネットワーク認可 1

- ネットワーク・クライアントによる認可 1

- OEM_ADVISORロール 1

- OEM_MONITORロール 1

- OLAP_DBAロール 1

- OLAP_USERロール 1

- OLAP_XS_ADMINロール 1

- One Big Application User、制限 1

- オペレーティング・システム 1

- オペレーティング・システムによる認可 1

- オペレーティング・システムによる認可 1

- オペレーティング・システムによる付与 1

- オペレーティング・システムによる識別 1

- オペレーティング・システムによる管理 1 , 2

- オペレーティング・システム管理と共有サーバー 1

- OPTIMIZER_PROCESSING_RATEロール 1

- ORDADMINロール 1

- パスワードでの大/小文字の区別 1

- PDB_DBAロール 1

- 事前定義 1

- 権限、認可方式の変更 1

- 権限、パスワードの変更 1

- 作成するための権限 1

- 削除するための権限 1

- PROVISIONERロール 1

- RESOURCEロール 1

- ツール・ユーザーからの制限 1

- 権限に関する制限 1

- REVOKE文 1

- 取消し 1 , 2

- SCHEDULER_ADMINロール 1

- スキーマには含まれない 1

- セキュリティ・ドメイン 1

- SET ROLE文

- 概要 1

- 例 1

- OS_ROLESパラメータ 1

- PL/SQLブロック内で設定 1

- SPATIAL_CSW_ADMINロール 1

- SPATIAL_WFS_ADMINロール 1

- 一意の名前 1

- パスワードの使用 1

- ユーザー 1 , 2

- 付与できるユーザー 1

- 使用 1 , 2

- WFS_USR_ROLEロール 1

- WITH GRANT OPTION 1

- 認可なし 1

- WM_ADMIN_ROLEロール 1

- XDB_SET_INVOKERロール 1

- XDB_WEBSERVICES_OVER_HTTPロール 1

- XDB_WEBSERVICES_WITH_PUBLICロール 1

- XDB_WEBSERVICESロール 1

- XDBADMINロール 1

- XS_CACHE_ADMINロール 1

- XS_NSATTR_ADMINロール 1

- XS_RESOURCEロール 1

- root

- 情報の表示 1

- ルート・ファイル・パス

- データベース外部のファイルおよびパッケージ 1

- 行レベルのセキュリティ

- 「ファイングレイン・アクセス・コントロール」、「Oracle Virtual Private Database (VPD)」を参照

- RSA秘密鍵 1

- ランタイム機能

- 権限の制限 1

S

- 米国サーベンス・オクスリー法

- 順守を満たすための監査 1

- SCHEDULER_ADMINロール

- 概要 1

- スキーマに依存しないユーザー 1

- スキーマ・オブジェクト権限 1

- スキーマ・オブジェクト

- 取消しの連鎖的影響 1

- デフォルト表領域 1

- 削除したユーザー、所有 1

- 権限の付与 1

- 権限

- DML操作とDDL操作 1

- 付与と取消し 1

- ビューに対する権限 1

- 権限 1

- アクセスするための権限 1

- 権限 1

- 権限の取消し 1

- スキーマ

- 監査、推奨設定 1

- プライベート 1

- 共有、オブジェクトの保護 1

- エンタープライズ・ユーザーで共有 1

- 一意 1

- 一意、オブジェクトの保護 1

- SCOTTユーザー・アカウント

- 権限の制限 1

- SEC_CASE_SENSITIVE_LOGON初期化パラメータ

- 非推奨 1

- SEC_CASE_SENSITIVE_LOGONパラメータ

- SQLNET.ALLOWED_LOGON_VERSION_SERVER設定と競合 1

- SEC_MAX_FAILED_LOGIN_ATTEMPTS初期化パラメータ 1

- SEC_PROTOCOL_ERROR_FURTHER_ACTION初期化パラメータ 1

- sec_relevant_cols_optパラメータ 1

- SEC_RETURN_SERVER_RELEASE_BANNER初期化パラメータ 1

- SEC_USER_AUDIT_ACTION_BANNER初期化パラメータ 1

- SEC_USER_UNAUTHORIZED_ACCESS_BANNER初期化パラメータ 1

- secconf.sqlスクリプト

- パスワード設定 1

- 秘密鍵

- RADIUSでの場所 1

- セキュア・アプリケーション・ロール

- 概要 1

- 作成 1

- PL/SQLパッケージの作成 1

- DBA_ROLESビューを使用した検索 1

- 実行者権限 1

- 実行者権限の要件 1

- パッケージ 1

- SYS_CONTEXT SQLファンクションからのユーザー環境情報 1

- データベース接続を保証するための使用 1

- 安全性の高い外部パスワード・ストア

- 概要 1

- クライアントの構成 1

- 例 1

- 機能 1

- プロキシ認証、使用 1

- Secure Sockets Layer(SSL)

- 概要 1

- アーキテクチャ 1

- AUTHENTICATIONパラメータ 1

- 認証パラメータ 1

- Oracle環境における認証プロセス 1

- 証明書の鍵のアルゴリズム 1

- 暗号スイート 1 , 2

- クライアントとサーバーのパラメータ 1

- クライアント認証パラメータ 1

- クライアントの構成 1

- 他の認証方式の併用 1

- 構成ファイル、保護 1

- 構成のトラブルシューティング 1

- 構成 1

- SYSDBAまたはSYSOPERアクセスの構成 1

- 使用可能 1

- 証明書のフィルタリング 1

- FIPSモードの設定(SSLFIPS_140) 1

- プライベート・スキーマを持つグローバル・ユーザー 1

- セキュリティに関するガイドライン 1

- ハンドシェイク 1

- 業界標準プロトコル 1

- リスナー、管理 1

- モード 1

- 複数の証明書、フィルタリング 1

- パスフレーズ 1

- クライアント認証の要求 1

- RSA秘密鍵 1

- Secure Sockets Layer(SSL)

- SSL_CLIENT_AUTHENTICATION 1

- SSL接続の保護 1

- server.keyファイル 1

- サーバー構成 1

- SQLNET.AUTHENTICATION_SERVICESパラメータ 1

- sqlnet.oraファイルのサンプル 1

- SSL_CIPHER_SUITESパラメータ 1

- SSL_CLIENT_AUTHENTICATIONパラメータ 1

- SSL_SERVER_CERT_DN 1

- SSL_SERVER_DN_MATCH 1

- SSL_VERSIONパラメータ 1

- システム要件 1

- TCPS 1

- バージョン・パラメータ 1

- ウォレット・ロケーション、パラメータ 1

- パラメータの構成方法 1

- SecurID

- トークン・カード 1

- セキュリティ

- アプリケーションを使用して規定 1

- デフォルトのユーザー・アカウント

- 自動的にロックして期限切れにする 1

- ロックして期限切れにする 1

- ドメイン、使用可能なロール 1

- アプリケーション内の規定 1

- データベース内の規定 1

- ロール名に含まれているマルチバイト・キャラクタ 1

- ロールのパスワードに含まれているマルチバイト・キャラクタ 1

- パスワード 1

- ポリシー

- アプリケーション 1

- SQL*Plusユーザー、制限 1

- 表またはビュー 1

- プロシージャによる強化 1

- リソース、その他 1

- ロール、アプリケーションに使用する利点 1

- セキュリティ・アラート 1

- セキュリティ攻撃

- プロトコル・エラー後のサーバーへのアクセス、防止 1

- アプリケーション・コンテキスト値、変更の試み 1

- 攻撃を防ぐために設計されたアプリケーション 1

- コマンドラインのリコール攻撃 1 , 2

- サービス拒否 1

- サービス拒否

- 不正なパケット、対処 1

- リスナーを介したサービス拒否攻撃 1

- ディスクあふれ、防止 1

- 傍受 1

- 暗号化、解決しない問題 1

- 偽造されたIPアドレス 1

- 偽造または盗用されたクライアント・システムID 1

- ハッキングされたオペレーティング・システムまたはアプリケーション 1

- 侵入者 1

- パスワードのクラッキング 1

- パスワード保護 1

- クライアントからの悪意のある攻撃の防止 1

- プロキシ認証と安全性の高い外部パスワード・ストアによるパスワードの盗難防止 1

- セッションID、暗号化の必要性 1

- ショルダー・サーフィン 1

- SQLインジェクション攻撃 1

- 無制限の認証リクエスト、防止 1

- ユーザー・セッションの出力、侵入者から隠す 1

- セキュリティ・ドメイン

- 使用可能にするロール 1

- セキュリティ・パッチ

- 概要 1

- ダウンロード 1

- セキュリティ・ポリシー

- 「Oracle Virtual Private Database、ポリシー」を参照

- セキュリティ上のリスク

- 非定型ツール 1

- データベース内ではなくアプリケーション内で規定 1

- データベース・ユーザーではないアプリケーション・ユーザー 1

- サーバーへの不正なパケット 1

- データベース・バージョンの表示 1

- 暗号化鍵、ユーザーによる管理 1

- 実行者権限プロシージャ 1

- パスワード・ファイル 1

- パスワード、プログラムまたはスクリプトでの公開 1

- 大規模な配置でさらされるパスワード 1

- SQLスクリプトの位置パラメータ 1

- 軽率に付与された権限 1

- 別のユーザーになりすますリモート・ユーザー 1

- 監査証跡内の機密性の高いデータ 1

- 識別情報を偽造するサーバー 1

- 複数のロールがあるユーザー 1

- セキュリティ設定スクリプト

- パスワード設定

- secconf.sql 1

- Secure Sockets Layer (SSL)

- TLSを含めた用語の使用 1

- SELECT_CATALOG_ROLEロール

- SYSスキーマ・オブジェクト、アクセスの許可 1

- SELECT ANY DICTIONARY権限

- データ・ディクショナリ、アクセス 1

- GRANT ALL PRIVILEGES権限から除外 1

- Virtual Private Databaseポリシー内のSELECT FOR UPDATE文 1

- SELECTオブジェクト権限

- 使用のガイドライン 1

- 有効な権限 1

- 職務分離の概念 1

- 順序

- 監査 1

- server.keyファイル

- 読取りおよび解析するパスフレーズ 1

- SESSION_ROLESデータ・ディクショナリ・ビュー

- PUBLICロール 1

- SESSION_ROLESビュー

- PL/SQLブロックからの問合せ 1

- セッション

- 権限ドメインのリスト 1

- メモリー使用、表示 1

- 時間制限 1

- 監査オプションが有効になる時点 1

- SET ROLE文

- アプリケーション・コード、挿入 1

- 権限とロールの関連付け 1

- ロールを使用禁止にする 1

- ロールを使用可能にする 1

- オペレーティング・システム・ロールを使用した場合 1

- SGA

- 「システム・グローバル領域(SGA)」を参照

- SHA-512暗号ハッシュ関数

- 排他モードを有効にする 1

- 共有グローバル領域(SGA)

- 「システム・グローバル領域(SGA)」を参照

- 共有サーバー

- プライベートSQL領域の制限 1

- オペレーティング・システムによるロール管理の制限 1

- ショルダー・サーフィン 1

- スマートカード

- RADIUS 1 , 2 , 3 , 4

- スマートカード

- セキュリティに関するガイドライン 1

- SPATIAL_CSW_ADMINロール 1

- SPATIAL_WFS_ADMINロール 1

- SQL*Net

- 「Oracle Net Services」を参照

- SQL*Plus

- 接続 1

- 非定型の使用を制限 1

- 統計モニター 1

- SQL92_SECURITY初期化パラメータ

- READオブジェクト権限の影響 1

- SQL Developer

- Javaデバッグ・ワイヤ・プロトコルを使用したデバッグ 1

- SQLインジェクション攻撃 1

- SQLNET.ALLOWED_LOGON_VERSION

- 「SQLNET.ALLOWED_LOGON_VERSION_CLIENT」、「SQLNET.ALLOWED_LOGON_VERSION_SERVER」を参照

- SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータ

- SEC_CASE_SENSITIVE_LOGON FALSE設定と競合 1

- ロール・パスワードへの影響 1

- SQLNET.AUTHENTICATION_KERBEROS5_SERVICEパラメータ 1

- SQLNET.AUTHENTICATION_SERVICESパラメータ 1 , 2 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11

- SQLNET.CRYPTO_CHECKSUM_CLIENTパラメータ 1 , 2

- SQLNET.CRYPTO_CHECKSUM_SERVERパラメータ 1 , 2

- SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENTパラメータ 1 , 2

- SQLNET.CRYPTO_CHECKSUM_TYPES_SERVERパラメータ 1 , 2

- SQLNET.ENCRYPTION_CLIENTパラメータ 1 , 2 , 3

- SQLNET.ENCRYPTION_SERVERパラメータ 1 , 2 , 3

- SQLNET.ENCRYPTION_TYPES_CLIENTパラメータ 1 , 2

- SQLNET.ENCRYPTION_TYPES_SERVERパラメータ 1 , 2

- SQLNET.KERBEROS5_CC_NAMEパラメータ 1

- SQLNET.KERBEROS5_CLOCKSKEWパラメータ 1

- SQLNET.KERBEROS5_CONFパラメータ 1

- SQLNET.KERBEROS5_REALMSパラメータ 1

- sqlnet.oraファイル

- 一般的なサンプル 1

- FIPS 140-2

- 暗号スイートの設定 1

- トレースを有効にする 1

- Kerberosのサンプル 1

- Oracle Advanced Securityのチェックサムのサンプル 1

- Oracle Advanced Securityの暗号化のサンプル 1

- Oracleウォレットの設定 1

- OSS.SOURCE.MY_WALLETパラメータ 1 , 2

- Kerberosを使用するクライアントとサーバーのパラメータ 1

- RADIUSを使用するクライアントとサーバーのパラメータ 1

- SSLを使用するクライアントとサーバーのパラメータ 1

- PDB 1

- RADIUSのサンプル 1

- サンプル 1

- SQLNET.AUTHENTICATION_KERBEROS5_SERVICEパラメータ 1

- SQLNET.AUTHENTICATION_SERVICESパラメータ 1 , 2 , 4 , 5 , 6 , 7 , 8

- SQLNET.CRYPTO_CHECKSUM_CLIENTパラメータ 1

- SQLNET.CRYPTO_CHECKSUM_SERVERパラメータ 1

- SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENTパラメータ 1 , 2

- SQLNET.CRYPTO_CHECKSUM_TYPES_SERVERパラメータ 1 , 2

- SQLNET.ENCRYPTION_CLIENパラメータ 1

- SQLNET.ENCRYPTION_CLIENTパラメータ 1

- SQLNET.ENCRYPTION_SERVERパラメータ 1 , 2 , 3

- SQLNET.ENCRYPTION_TYPES_CLIENTパラメータ 1

- SQLNET.ENCRYPTION_TYPES_SERVERパラメータ 1

- SQLNET.KERBEROS5_CC_NAMEパラメータ 1

- SQLNET.KERBEROS5_CLOCKSKEWパラメータ 1

- SQLNET.KERBEROS5_CONFパラメータ 1

- SQLNET.KERBEROS5_REALMSパラメータ 1

- SQLNET.SSL_EXTENDED_KEY_USAGE 1

- SSL_CLIENT_AUTHENTICATIONパラメータ 1

- SSL_CLIENT_AUTHETNICATIONパラメータ 1

- SSL_VERSIONパラメータ 1 , 2

- SSLのサンプル 1

- トレース・ファイルの設定のサンプル 1

- SQLNET.RADIUS_ALTERNATE_PORTパラメータ 1 , 2

- SQLNET.RADIUS_ALTERNATE_RETRIESパラメータ 1 , 2

- SQLNET.RADIUS_ALTERNATE_TIMEOUTパラメータ 1 , 2

- SQLNET.RADIUS_ALTERNATEパラメータ 1 , 2

- SQLNET.RADIUS_AUTHENTICATION_INTERFACEパラメータ 1

- SQLNET.RADIUS_AUTHENTICATION_PORTパラメータ 1

- SQLNET.RADIUS_AUTHENTICATION_RETRIESパラメータ 1

- SQLNET.RADIUS_AUTHENTICATION_TIMEOUTパラメータ 1

- SQLNET.RADIUS_AUTHENTICATIONパラメータ 1

- SQLNET.RADIUS_CHALLENGE_KEYWORDパラメータ 1

- SQLNET.RADIUS_CHALLENGE_RESPONSEパラメータ 1

- SQLNET.RADIUS_CLASSPATHパラメータ 1

- SQLNET.RADIUS_SECRETパラメータ 1

- SQLNET.RADIUS_SEND_ACCOUNTINGパラメータ 1 , 2

- SQLNET.SSL_EXTENDED_KEY_USAGEパラメータ 1

- SQL文

- 動的 1

- アプリケーションで許可するオブジェクト権限 1

- 必要な権限 1 , 2

- リソース制限 1

- 非定型の使用を制限 1

- SSL

- 「Secure Sockets Layer (SSL)」を参照

- SSL_CIPHER_SUITESパラメータ 1

- SSL_CLIENT_AUTHENTICATIONパラメータ 1 , 2

- SSL_SERVER_CERT_DNパラメータ 1

- SSL_SERVER_DN_MATCHパラメータ 1

- SSL_VERSIONパラメータ 1 , 2 , 3

- 標準監査

- エディションによる影響 1

- 監査証跡のアーカイブ 1

- 権限監査

- 概要 1

- 複数層環境 1

- レコード

- アーカイブ 1

- 文監査

- 複数層環境 1

- 標準監査証跡

- レコード、削除 1

- DBMS_RLS.ADD_POLICYプロシージャのstatement_typesパラメータ 1

- 記憶域

- 割当て制限 1

- 無制限の割当て 1

- ストアド・プロシージャ

- PUBLICロールに付与された権限の使用 1

- 厳密認証

- 複数のデータベースへのSYSDBAおよびSYSOPERのアクセスの集中管理 1

- 無効化 1

- ガイドライン 1

- シンボリック・リンク

- 制限 1

- 同期認証モード、RADIUS 1

- シノニム

- オブジェクト権限 1

- 権限、ガイドライン 1

- SYS_CONTEXT関数

- 概要 1

- 非データベース・ユーザーの監査 1

- データベース・リンク 1

- 動的SQL文 1

- 例 1

- パラレル問合せ 1

- 構文 1

- 統合監査ポリシー 1

- ビューでの使用 1

- ユーザーの検証 1

- SYS_DEFAULT Oracle Virtual Private Databaseポリシー・グループ 1

- SYS_SESSION_ROLESネームスペース 1

- SYS.AUD$表

- アーカイブ 1

- SYS.FGA_LOG$表

- アーカイブ 1

- SYSアカウント

- 監査 1

- パスワードの変更 1

- ポリシーの規定 1

- SYSとSYSTEM

- パスワード 1

- SYSおよびSYSTEMアカウント

- 監査 1

- SYSASM権限

- パスワード・ファイル 1

- SYSBACKUP権限

- サポートされる操作 1

- パスワード・ファイル 1

- SYSDBA権限

- ディレクトリ認証 1

- Kerberos認証 1

- パスワード・ファイル 1

- SSL認証 1

- SYSDG権限

- サポートされる操作 1

- パスワード・ファイル 1

- SYSKM権限

- サポートされる操作 1

- パスワード・ファイル 1

- SYSMANユーザー・アカウント 1

- SYSオブジェクト

- 監査 1

- SYSOPER権限

- ディレクトリ認証 1

- パスワード・ファイル 1

- SYSスキーマ

- オブジェクト、アクセス 1

- システム・グローバル領域(SGA)

- アプリケーション・コンテキスト、格納 1

- グローバル・アプリケーション・コンテキスト情報の場所 1

- プライベートSQL領域の制限 1

- システム権限

- 概要 1

- ADMIN OPTION 1

- ANY

- セキュリティに関するガイドライン 1

- CDB 1

- GRANT ANY PRIVILEGE 1

- 付与 1

- 付与と取消し 1

- 効力 1

- 制限の必要性 1

- 取消し、連鎖的な影響 1

- SELECT ANY DICTIONARY 1

- 共通権限付与 1

- システム要件

- Kerberos 1

- RADIUS 1

- SSL 1

- 厳密認証 1

- SYSユーザー

- 監査の例 1

T

- 表

- 監査 1

- 権限 1

- 表領域

- ユーザーに対するデフォルトの割当て 1

- デフォルトの割当て制限 1

- 割当て制限、表示 1

- ユーザーに対する割当て制限 1

- 一時

- ユーザーに対する割当て 1

- 無制限の割当て 1

- TCPSプロトコル

- Secure Sockets Layer、使用 1

- tnsnames.oraファイル、使用 1

- TELNETサービス 1

- TFTPサービス 1

- シンJDBCのサポート 1

- TLS,「Secure Sockets Layer (SSL)」を参照 1

- トークン・カード 1 , 2

- トレース・ファイル

- sqlnet.oraファイルの設定のサンプル 1

- トレース・ファイル

- アクセス、制限の重要性 1

- 不正なパケット 1

- FIPS 140-2 1

- 位置、検索 1

- 透過的データ暗号化

- 概要 1

- FIPS 140-2に対する有効化 1

- SYSKM管理権限 1

- 透過的機密データ保護(TSDP)

- 概要 1

- ポリシーの変更 1

- メリット 1

- バインド変数

- 概要 1

- 条件式 1

- ポリシーの作成 1

- ポリシーの無効化 1

- REDACT_AUDITポリシーの無効化 1

- ポリシーの削除 1

- REDACT_AUDITポリシーの有効化 1

- 情報の検索 1

- 一般的な手順 1

- PDB 1

- 必要な権限 1

- REDACT_AUDITポリシー 1

- INSERTまたはUPDATE操作の機密列 1

- 同じSELECT問合せの機密列 1

- ビューの機密列 1

- ユースケース 1

- 仮想プライベート・データベース

- DBMS_RLS.ADD_POLICYパラメータ 1

- 一般的な手順 1

- チュートリアル 1

- 透過的表領域暗号化

- 概要 1

- Transport Layer Security (SSL)

- SSLとの比較 1

- トリガー

- 監査 1 , 2

- CREATE TRIGGER ON 1

- ログイン

- 例 1

- 外部で初期化されたアプリケーション・コンテキスト 1

- 実行の権限

- ロール 1

- WHEN OTHERS例外 1

- トラブルシューティング

- トレース・ファイルの確認によるエラーの検索 1

- トラステッド・プロシージャ

- データベース・セッション・ベースのアプリケーション・コンテキスト 1

- tsnames.ora構成ファイル 1

- 例

- アプリケーション・コンテキスト、データベース・セッション・ベース 1

- 監査

- 非データベース・ユーザーを監査するポリシーの作成 1

- 電子メール・アラートを使用するポリシーの作成 1

- 外部ネットワーク・サービス、電子メール・アラートの使用 1

- クライアント・セッションIDを使用するグローバル・アプリケーション・コンテキスト 1

- CBACを使用した実行者権限プロシージャ 1

- 非データベース・ユーザー

- Oracle Virtual Private Databaseポリシー・グループの作成 1

- グローバル・アプリケーション・コンテキスト 1

- Oracle Virtual Private Database

- ポリシー・グループ 1

- ポリシーの実装 1

- 単純な例 1

- TSDPとVPD 1

- 型

- 作成 1

- 権限 1

- ユーザー定義

- 作成要件 1

U

- UDPおよびTCPポート

- 使用禁止の全サービスに対して閉じる 1

- UGA

- 「ユーザー・グローバル領域(UGA)」を参照

- 統合監査

- メリット 1

- 混合モードの監査との比較 1

- データベースの作成 1

- 無効化 1

- 移行しているかどうかの確認 1

- 混合モードの監査

- 概要 1

- 機能 1

- レコードの削除

- 例 1

- 手動パージの一般的な手順 1

- スケジューリングされたパージの一般的な手順 1

- チュートリアル 1

- 統合監査ポリシー

- 概要 1

- 作成に関するベスト・プラクティス 1

- 削除

- 概要 1

- 手順 1

- 場所 1

- 事前定義済

- ORA_ACCOUNT_MGMT 1

- ORA_CIS_RECOMMENDATIONS 1

- ORA_DATABASE_PARAMETER 1

- ORA_DV_AUDPOL 1

- ORA_LOGON_FAILURES 1

- ORA_SECURECONFIG 1

- 作成の構文 1

- ユーザー、適用 1

- ユーザー、除外 1

- ユーザー、成功または失敗 1

- 統合監査ポリシー, 管理ユーザー

- 構成 1

- 例 1

- 監査可能なユーザー 1

- 統合監査ポリシー、変更

- 概要 1

- 構成 1

- 例 1

- 統合監査ポリシー、CDB

- 概要 1

- 監査証跡での表示方法 1

- 構成 1

- 例 1 , 2

- 統合監査ポリシー、条件

- 概要 1

- 構成 1

- 例 1

- 統合監査ポリシー、無効化

- 概要 1 , 2

- 構成 1

- 統合監査ポリシー、有効化

- 概要 1

- 構成 1

- ロールを介したユーザーのグループ 1

- 統合監査ポリシー、オブジェクト・アクション

- 概要 1

- 監査できるアクション 1

- 監査証跡での表示方法 1

- 構成 1

- ディクショナリ表

- 監査 1

- 例 1

- SYSオブジェクト 1

- 統合監査ポリシー、Oracle Database Real Application Security

- 概要 1

- 構成 1

- 監査するイベント 1

- 例 1

- 監査証跡でのイベントの表示方法 1

- 事前定義済

- 概要 1

- ORA_RAS_POLICY_MGMT 1

- ORA_RAS_SESSION_MGMT 1

- 統合監査ポリシー、Oracle Database Vault

- 概要 1

- 監査証跡での表示方法 1

- 監査する属性 1

- 構成 1

- データ・ディクショナリ・ビュー 1

- ファクタの監査例 1

- 2つのイベントの監査例 1

- 監査証跡でのイベントの表示方法 1

- 統合監査ポリシー、Oracle Data Miner

- 概要 1

- 統合監査ポリシー、Oracle Data Mining

- 構成 1

- 監査証跡でのイベントの表示方法 1

- 統合監査ポリシー、Oracle Data Pump

- 概要 1

- 監査証跡での表示方法 1 , 2

- 構成 1

- 例 1

- 監査証跡でのイベントの表示方法 1

- 統合監査ポリシー、Oracle Label Security

- 概要 1

- 監査証跡での表示方法 1

- 構成 1

- 例 1

- 監査証跡でのイベントの表示方法 1

- LBACSYS.ORA_GET_AUDITED_LABELファンクション 1

- 統合監査ポリシー、Oracle Recovery Manager

- 概要 1

- 監査証跡でのイベントの表示方法 1

- 統合監査ポリシー、Oracle SQL*Loader

- 概要 1

- 構成 1

- 例 1

- 監査証跡でのイベントの表示方法 1

- 統合監査ポリシー、権限

- 概要 1

- 監査証跡での表示方法 1

- 構成 1

- 例 1

- 監査できる権限 1

- 監査できない権限 1

- 統合監査ポリシー、ロール

- 概要 1

- 構成 1

- 例 1

- 統合監査セッションID、確認 1

- 統合監査証跡

- 概要 1

- アーカイブ 1

- 監査レコードのロード先 1

- 監査レコードが作成される場合 1

- AUDSYSの監査証跡レコードの書込み

- 概要 1

- モードの構成 1

- 即時書込みモード 1

- AUDSYSへのレコードの手動フラッシュ 1

- キューの最小フラッシュしきい値 1

- キュー書込みモード 1

- 統合監査証跡、オブジェクト・アクション

- READオブジェクト・アクション 1

- SELECTオブジェクト・アクション 1

- 統合監査証跡、Oracle Data Mining

- 例 1

- 統合監査証跡

- Oracle Database Real Application SecurityのALL監査イベント 1

- Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベント 1

- Oracle Database Real Application Securityのセッションの監査イベント 1

- Oracle Database Vaultのコマンド・ルールのイベント 1

- Oracle Database Vault Data Pumpのイベント 1

- Oracle Database Vaultによるイベントの有効化と無効化 1

- Oracle Database Vaultのファクタの監査イベント 1

- Oracle Database Vault OLSのイベント 1

- Oracle Database Vaultのレルムのイベント 1

- Oracle Database Vaultのルール・セットおよびルールのイベント 1

- Oracle Database Vaultのセキュア・アプリケーション・ロールのイベント 1

- Oracle Data Miningの監査イベント 1

- Oracle Data Pumpの監査イベント 1

- Oracle Label Securityの監査イベント 1

- Oracle Label Securityのユーザー・セッション・ラベルのイベント 1

- Oracle Recovery Managerの監査イベント 1

- Oracle SQL*Loaderダイレクト・ロード・パスの監査イベント 1

- UNLIMITED TABLESPACE権限 1

- UPDATE権限

- 取消し 1

- ユーザー・アカウント

- 管理用ユーザーのパスワード 1

- 共通

- 作成 1

- 共通ユーザー

- 概要 1

- デフォルトのユーザー・アカウント 1

- ローカル

- 作成 1

- ローカル・ユーザー

- 概要 1

- パスワードのガイドライン 1

- パスワード、暗号化 1

- 作成に必要な権限 1

- プロキシ・ユーザー 1

- USERENVファンクション

- ビューでの使用 1

- USERENVネームスペース

- 概要 1

- ユーザー・グローバル領域(UGA)

- アプリケーション・コンテキスト、格納 1

- ユーザー名

- スキーマ 1

- ユーザー権限

- CDB 1

- USER疑似列 1

- ユーザー

- 管理オプション(ADMIN OPTION) 1

- 変更 1

- 共通ユーザーの変更 1

- ローカル・ユーザーの変更 1

- データベースに認識されないアプリケーション・ユーザー 1

- 割当て制限のない割当て 1

- 監査 1

- データベース・ロール、現在 1

- デフォルト・ロール、変更 1

- デフォルト表領域 1

- 削除 1 , 2

- プロファイルの削除 1

- ロールの削除 1

- ロールを使用可能にする 1

- エンタープライズ 1 , 2

- エンタープライズ、共有スキーマによる保護 1

- 外部認証

- 概要 1

- メリット 1

- プロファイルの割当て 1

- オペレーティング・システム 1

- ユーザーの作成 1

- 情報の検索 1

- 認証に関する情報の検索 1

- グローバル

- プロファイルの割当て 1

- ホスト、複数への接続

- 「外部ネットワーク・サービス, ファイングレイン・アクセス」を参照 1

- 情報、表示 1

- 付与されているロールのリスト 1

- メモリー使用、表示 1

- 名前

- 大/小文字の区別 1

- データベースでの格納方法 1

- ネットワーク認証、外部 1

- 非データベース 1 , 2

- 削除後のオブジェクト 1

- オペレーティング・システム外部認証 1

- パスワード暗号化 1

- 権限

- パスワードの変更 1

- 作成 1

- 権限付与、リスト 1

- 現在のデータベース・ロール 1

- プロファイル

- 割当て 1

- 作成 1

- 指定 1

- プロキシ認証 1

- プロキシ・ユーザー、接続 1

- PUBLICロール 1 , 2

- 表領域の割当て制限 1

- アプリケーション・ロールの制限 1

- ユーザー名に関する制限 1

- ロール

- ユーザーのタイプ 1

- スキーマに依存しない 1

- スキーマ、プライベート 1

- セキュリティ、概要 1

- セキュリティ・ドメイン 1

- 表領域割当て制限 1

- 表領域割当て制限、表示 1

- ユーザー・アカウント、作成 1

- ユーザー・モデルとOracle Virtual Private Database 1

- ユーザー名、CREATE USER文での指定 1

- 情報の検索に使用できるビュー 1

- ユーザー・セッション、単一のデータベース接続内に複数 1

- utlpwdmg.sql

- 概要 1

V

- 有効なノードの確認 1

- ビュー

- 概要 1

- アクセス制御リストのデータ

- 外部ネットワーク・サービス 1

- ウォレット・アクセス 1

- アプリケーション・コンテキスト 1

- 監査アクティビティ 1

- 監査 1

- 監査の管理設定 1

- 監査証跡の使用状況 1

- 認証 1

- TSDP機密列のバインド変数 1

- DBA_COL_PRIVS 1

- DBA_HOST_ACES 1

- DBA_HOST_ACLS 1

- DBA_ROLE_PRIVS 1

- DBA_ROLES 1

- DBA_SYS_PRIVS 1

- DBA_TAB_PRIVS 1

- DBA_USERS_WITH_DEFPWD 1

- DBA_WALLET_ACES 1

- DBA_WALLET_ACLS 1

- 定義者権限 1

- 暗号化データ 1

- 実行者権限 1

- Oracle Virtual Private Databaseポリシー 1

- 権限 1 , 2

- プロファイル 1

- ROLE_SYS_PRIVS 1

- ROLE_TAB_PRIVS 1

- ロール 1

- セキュリティ・アプリケーション 1

- SESSION_PRIVS 1

- SESSION_ROLES 1

- 透過的機密データ保護 1

- USER_HOST_ACES 1

- USER_WALLET_ACES 1

- ユーザー 1

- 仮想プライベート・データベース

- 「Oracle Virtual Private Database」を参照

- VPD

- 「Oracle Virtual Private Database」を参照

- 無防備なランタイム・コール

- 安全性の改善 1

W

- Wallet Manager

- 「Oracle Wallet Manager」を参照

- ウォレット

- 認証方式 1

- Webアプリケーション

- ユーザー接続 1 , 2

- Webベースのアプリケーション

- Oracle Virtual Private Database、仕組み 1

- WFS_USR_ROLEロール 1

- WHEN OTHERS例外

- ログイン・トリガー、使用 1

- Windowsネイティブ認証 1

- With Grant Option句

- 概要 1

- ユーザーとロールへの付与 1

- WM_ADMIN_ROLEロール 1

X

- X.509証明書

- セキュリティに関するガイドライン 1

- XDB_SET_INVOKERロール 1

- XDB_WEBSERVICES_OVER_HTTPロール

- 概要 1

- XDB_WEBSERVICES_WITH_PUBLICロール 1

- XDB_WEBSERVICESロール 1

- XDBADMINロール 1

- XS_CACHE_ADMINロール 1

- XS_NSATTR_ADMINロール 1

- XS_RESOURCEロール 1

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)を参照してください。