1. セキュリティ・ガイド
  2. 付録
  3. Oracle Databaseの安全性の維持

A Oracle Databaseの安全性の維持

Oracleには、ユーザー・アカウント、権限、ロール、パスワードおよびデータの保護に関するアドバイスなど、データベースの安全性を維持するためのガイドラインがあります。

親トピック: 付録

A.1 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 Databaseの安全性の維持

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

セキュリティ・パッチが入手可能になったら、必ずすぐに適用する必要があります。問題が発生した場合、脆弱性についてOracleに連絡してください。

親トピック: Oracle Databaseの安全性の維持

A.2.1 セキュリティ・パッチと回避ソリューションのダウンロード

セキュリティ・パッチは、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への連絡

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

Oracle Databaseの脆弱性に関してOracleのセキュリティ窓口に連絡できます。

  • Oracleのセキュリティ窓口への連絡には、次のいずれかの方法を使用します。

    • OracleユーザーまたはOracleパートナであるユーザーがOracle製品の潜在的なセキュリティ上の脆弱性を発見した場合は、My Oracle Supportを使用してサービス・リクエストを発行してください。

    • 製品のバージョンやプラットフォームも含めた問題の詳細を、スクリプトと例を添えて、電子メールでsecalert_us@oracle.comに送信してください。オラクル社にお問合せの際は、弊社の暗号キーを使用して、電子メールを暗号化することをお薦めします。

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

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

Oracleには、ユーザー・アカウントと権限を保護するためのガイドラインがあります。

  1. デフォルト(事前定義)のユーザー・アカウントをロックし、期限切れにする。

    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)は、そのアカウントのロックを解除し、安全性の高い新しいパスワードを設定してアクティブにする必要があります。

    なんらかの理由で、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を含む)をロックし、期限切れにします。

  2. ユーザーが、SQL文でNOLOGGING句を使用できないようにする。

    いくつかのSQL文で、ユーザーはオプションとしてNOLOGGING句を指定できます。このオプションを指定すると、データベース操作がオンラインREDOログ・ファイルに記録されません。ユーザーがこの句を指定しても、REDOはオンラインREDOログ・ファイルに書き込まれます。ただし、このレコードにはデータが関連付けられていません。このため、NOLOGGINGを使用すると、不正コードが入力されて、監査証跡に記録されずに実行される可能性があります。

  3. 「最低限の権限」原則を実践する。

    次のガイドラインに従うことをお薦めします。

    1. 必要な権限のみを付与する。

      データベース・ユーザーまたはロールに、必要以上の権限を付与しないでください。(可能な場合、ユーザーではなくロールに権限を付与してください。)つまり、最小権限の原則とは、ユーザーに、効率的かつ簡潔に作業を行うために実際に必要な権限のみを与えることです。

      この原則を実装するには、次の項目について可能なかぎり制限します。

      • データベース・ユーザーに付与するSYSTEMおよびOBJECT 権限の数。

      • SYS権限によってデータベースに接続できるユーザーの数。

      • DROP ANY TABLE権限などのANY権限を付与する対象のユーザー数。たとえば、通常、DBA権限のないユーザーにCREATE ANY TABLE権限を付与する必要はありません。

      • データベース・オブジェクトを(TRUNCATE TABLE、DELETE TABLE、DROP TABLE文などで)作成、変更または削除を実行できるユーザーの数。

    2. CREATE ANY EDITIONおよびDROP ANY EDITION権限の付与を制限する。

      オブジェクトの追加バージョンを維持するために、エディションではデータベース内のリソースおよびディスク領域の使用量を増やすことができます。CREATE ANY EDITIONおよびDROP ANY EDITION権限は、アップグレードの実行を担当する信頼できるユーザーにのみ付与します。

    3. ユーザーに付与したSELECTオブジェクト権限およびSELECT ANY TABLEシステム権限を再評価する。

      ユーザーが表、ビュー、マテリアライズド・ビューおよびシノニムの問合せのみを行えるように制限する場合、READオブジェクト権限を付与し、信頼できるユーザーにのみREAD ANY TABLEシステム権限を付与します。問合せ操作の実行以外に、ユーザーが排他モードでの表のロックまたはSELECT ... FOR UPDATE文を実行できるようにする場合、ユーザーにSELECTオブジェクト権限を付与し、信頼できるユーザーにのみSELECT ANY TABLEシステム権限を付与します。

    4. CREATE ANY JOB、BECOME USER、EXP_FULL_DATABASEおよびIMP_FULL_DATABASE権限を制限する。CREATE DIRECTORYおよびCREATE ANY DIRECTORY権限の付与も制限してください。

      これらは強力なセキュリティ関連権限です。これらの権限は、必要とするユーザーにのみ付与してください。

    5. Oracle Data Pump、Oracle StreamsおよびDBMS_WORKLOAD_CAPTUREとDBMS_WORKLOAD_REPLAYパッケージのユーザーに対してはBECOME USER権限を制限します。

      BECOME USER権限は次のサブシステムに対してのみ使用します。

      • Oracle Data Pump Importユーティリティimpdpおよびimpで、第三者が直接実行できない操作(オブジェクト権限を付与するようなオブジェクトのロード)を実行する場合に別のユーザーIDを利用できます。Oracle Database Vault環境では、BECOME USERの権限付与に影響する複数レベルの必須認可がDatabase Vaultに設定されています。『Oracle Database Vault管理者ガイド』を参照してください。

      • Oracle Streamsで、取得ユーザーおよび適用ユーザーの作成または変更を1つのStreams環境で行うことができます。デフォルトでは、BECOME USERはDBAロールに含まれています。ただし、Database Vaultが有効になっていると、BECOME USER権限がDBAロールから削除されます。したがって、StreamsでBECOME USERが必要とされるのはDatabase Vaultが使用可能な環境の場合のみです。

      • DBMS_WORKLOAD_CAPTUREおよびDBMS_WORKLOAD_REPLAYのPL/SQLパッケージ。これらのパッケージを使用する必要があるユーザーにはこの権限を付与する必要があります。

      これらのいずれかのサブシステム(たとえば、PL/SQLコードの静的参照)を呼び出す際にAUTHID CURRENT_USER句を使用する場合は、CURRENT_USERにBECOME USER権限が直接付与されているか、ロールを介して付与されていることを確認してください。

    6. ライブラリ関連の権限を信頼できるユーザーのみに制限する。

      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ロールに対して付与しないでください。

    7. 制限シノニム関連の権限を信頼できるユーザーのみに制限する。

      CREATE PUBLIC SYNONYMおよびDROP PUBLIC SYNONYMシステム権限によって、これらのユーザーに大きい力が与えられます。信頼できないかぎり、これらの権限をユーザーに付与しないでください。

    8. SYSスキーマが所有するオブジェクトに、管理者以外のユーザーがアクセスできないようにする。

      ユーザーが表の行やSYSスキーマのスキーマ・オブジェクトを変更できないようにしてください。変更されると、データ整合性が損われる危険があります。DROP TABLE、TRUNCATE TABLE、DELETE、INSERTなどの文、または類似したオブジェクト変更文のSYSオブジェクトに対する使用を、強い権限を持つ管理ユーザーのみに制限してください。

      SYSスキーマはデータ・ディクショナリを所有します。データ・ディクショナリは、O7_DICTIONARY_ACCESSIBILITYパラメータをFALSEに設定することで保護できます。詳細は、データの保護に関するガイドラインを参照してください。

    9. ランタイム機能の権限を制限する。

      多くの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');

  4. 次のビューまたはロールからアクセス権を取り消す。

    • SYSとDBAアカウント以外のすべてのユーザーからSYS.USER_HISTORY$表を取り消します。

    • 通常のアプリケーション・アカウントからRESOURCEロールを取り消します。

    • 通常のアプリケーション・アカウントからCONNECTロールを取り消します。

    • DBAロールが不要なユーザーから、このロールを取り消します。

  5. ロールに対してのみ権限を付与する。

    個々のユーザーではなくロールに権限を付与すると、権限の管理および追跡が容易になります。

  6. プロキシ・アカウント(プロキシ認可の場合)の権限をCREATE SESSIONのみに制限する。

  7. セキュア・アプリケーション・ロールを使用して、アプリケーション・コードによって有効化するロールを保護する。

    セキュア・アプリケーション・ロールでは、ユーザーがアプリケーションにログインできるかどうかを判断する一連の条件を、PL/SQLパッケージ内で定義できます。ユーザーはセキュア・アプリケーション・ロールではパスワードを使用する必要がありません。

    ロールがアプリケーション内で使用可能または使用禁止になるのを防ぐ別の方法は、ロールのパスワードを使用することです。この方法では、ユーザーが、データベースにSQL(アプリケーションではなく)で直接アクセスして、ロールに関連付けられている権限を使用することを防ぎます。ただし、別の一連のパスワードを管理する必要がないように、セキュア・アプリケーション・ロールの使用をお薦めします。

  8. 権限キャプチャを作成して、過度に付与されている権限を検索する。詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

  9. 次の権限が、それらを必要としているユーザーとロールのみに付与されていることを監視する。

    デフォルトでは、次の権限が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キーワード付きの権限

  10. 次のデータ・ディクショナリ・ビューを使用して、データベースへのユーザー・アクセスに関する情報を検索する。

    • DBA_*

    • DBA_ROLES

    • DBA_SYS_PRIVS

    • DBA_ROLE_PRIVS

    • DBA_TAB_PRIVS

    • DBA_AUDIT_TRAIL(標準監査が使用可能な場合)

    • DBA_FGA_AUDIT_TRAIL(ファイングレイン監査が使用可能な場合)

親トピック: Oracle Databaseの安全性の維持

A.4 ロールの保護に関するガイドライン

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の安全性の維持

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

オラクル社では、様々な状況でのパスワードの保護についてガイドラインを提供しています。

ユーザー・アカウントを作成すると、そのユーザーに対してデフォルトのパスワード・ポリシーが割り当てられます。このパスワード・ポリシーには、パスワードの作成方法(最小文字数や期限切れの時期など)についてのルールが定義されています。パスワードは、パスワード・ポリシーを使用することで強化できます。パスワードを保護するための別の方法については、「パスワード保護の構成」も参照してください。

パスワードをさらに強化するには、次のガイドラインに従います。

  1. パスワードを慎重に選択する。

    パスワードの最低要件については、「パスワードの最低要件」を参照してください。パスワードを作成または変更する際には、次の追加のガイドラインに従います。

    • パスワードは、長さを12から30バイトまでにし、英字と数字の両方を含むようにします。

    • パスワードには、数値、大文字および小文字を少なくとも1文字ずつ含めます。

    • パスワードには、大/小文字と特殊文字を混在させて使用します。(「パスワードのセキュリティへの脅威からの12Cパスワード・バージョンによる保護」を参照してください。)

    • パスワードにはマルチバイト・キャラクタを含めることができますが、共通ユーザーまたは共通ロールのパスワードに含めることはできません。

    • パスワードの文字にはデータベース文字セットを使用します。このセットには、アンダースコア(_)、ドル記号($)および番号記号(#)の各文字があります。

    • 次のパスワードは二重引用符で囲む必要があります。

      • マルチバイト・キャラクタを含むパスワード

      • 数字または特殊文字で始まり、アルファベットを含むパスワード。たとえば:

        "123abc"

        "#abc"

        "123dc$"

      • アルファベット、数字および特殊文字以外の文字を含むパスワード。たとえば:

        "abc>"

        "abc@",

        " "

    • 次のパスワードは二重引用符で囲む必要はありません。

      • アルファベット(aからz、AからZ)で始まり、数字(0から9)または特殊文字($、#、_)を含むパスワード。たとえば:

        abc123

        ab23a

        ab$#_

      • 数値のみを含むパスワード

      • アルファベット(aからz、AからZ)のみを含むパスワード。

    • パスワードには二重引用符を使用しないでください。

    • 意味のある単語のみで構成されるパスワードを使用しないでください。

  2. 短い覚えやすいパスワードをより長く複雑なパスワードにするには、覚えやすい文の単語の先頭文字を使用してパスワードを作成します。

    たとえば、"I usually work until 6:00 almost every day of the week"であれば、Iuwu6aedotwとなります。

  3. 十分複雑なパスワードを使用するようにする。

    Oracle Databaseには、パスワードの複雑度が十分であるかどうかをチェックするためのパスワード複雑度検証ルーチン(PL/SQLスクリプトutlpwdmg.sql)が用意されています。理想的には、utlpwdmg.sqlスクリプトを編集して、パスワードの安全性を高めます。パスワードのチェックに使用できるサンプル・ルーチンの概要については、「パスワードの複雑度検証について」も参照してください。

  4. 非マルチテナント環境またはPDBでは、パスワードにマルチバイト文字を使用する必要がある場合は、認証が正しく機能するように、データベース文字セットがマルチバイト文字セットとして構成されていることを確認してください。

    マルチバイト・キャラクタはシングルバイト・キャラクタよりも多くのバイトを使用するため1バイト当たりの不規則性がより低くなりやすいということに注意してください。パスワードにおいては、現在は最大長が30バイトに決められているため、不規則性が高まるよう、マルチバイト・キャラクタを使用している場合でもシングルバイト・キャラクタをいくつか含めることをお薦めします。

    共通ユーザーおよび共通ロールのパスワードにはマルチバイト・パスワードは使用できません。

  5. ユーザー・プロファイルまたはデフォルト・プロファイルに対してパスワード複雑度ファンクションを関連付けます。

    CREATE PROFILEおよびALTER PROFILE文のPASSWORD_VERIFY_FUNCTION句は、パスワードの複雑度検証関数をユーザー・プロファイルまたはデフォルト・プロファイルと関連付けます。パスワード複雑度ファンクションでは、ユーザーがそのサイトに固有のガイドラインを使用して強力なパスワードを作成しているかどうかを確認します。また、パスワードの複雑度検証関数を設定するには、ユーザーが(ALTER USERシステム権限を使用せずに)自分のパスワードを変更して、古いパスワードと新しいパスワードの両方を指定する必要があります。独自のパスワード複雑度ファンクションを作成したり、Oracle Databaseが提供するパスワード複雑度ファンクションを使用できます。

    詳細は、「パスワードの複雑度の管理」を参照してください。

  6. デフォルトのユーザー・パスワードを変更する。

    Oracle Databaseは、事前定義のデフォルト・ユーザー・アカウントのセットとともにインストールされます。セキュリティは、デフォルトのデータベース・ユーザー・アカウントがインストール後もデフォルト・パスワードを使用している場合に最も崩壊しやすくなります。ユーザー・アカウントSCOTTはよく知られているアカウントで侵入されやすい可能性があるため、これが特に当てはまります。Oracle Databaseでは、デフォルトのアカウントはロックされ、パスワードは期限切れの状態でインストールされますが、以前のリリースからのアップグレードの場合は、デフォルトのパスワードを使用しているアカウントが存在している場合があります。

    デフォルトのパスワードが設定されているユーザー・アカウントを検索するには、DBA_USERS_WITH_DEFPWDデータ・ディクショナリ・ビューを問い合せます。詳細は、「デフォルト・パスワードが設定されているユーザー・アカウントの検索」を参照してください。

  7. 管理ユーザーのデフォルト・パスワードを変更する。

    SYS、SYSTEM、SYSMANおよびDBSNMPの管理アカウントには、同じパスワードまたは異なるパスワードを使用できます。それぞれに対して異なるパスワードを使用することをお薦めします。つまり、すべてのOracle環境(本番またはテスト)において、これらの管理アカウントに強固で安全性の高い、個別のパスワードを割り当てます。Database Configuration Assistantを使用して新規データベースを作成する場合は、SYSおよびSYSTEMアカウントにパスワードを入力して、デフォルトのパスワードCHANGE_ON_INSTALLおよびMANAGERを使用できないようにします

    同様に、本番環境では、SYSMANおよびDBSNMPも含めて、管理アカウントにはデフォルトのパスワードを使用しないでください。

  8. パスワード管理を徹底する。

    基本的なパスワード管理ルール(パスワードの長さ、履歴および複雑度など)をすべてのユーザー・パスワードに適用します。Oracle Databaseには、デフォルト・プロファイルで使用可能なパスワード・ポリシーがあります。この項のガイドライン1には、これらのパスワード・ポリシーがリストされています。

    ユーザー・アカウントの情報を検索するには、DBA_USERSビューを問い合せます。DBA_USERSビューのPASSWORD列は、パスワードがグローバル、外部またはNULLのいずれであるかを示します。DBA_USERSビューには、ユーザー・アカウントの状態、アカウントがロックされているかどうか、パスワードのバージョンなどの有用な情報が表示されます。

    また、可能な場合は、Oracle厳密認証を、ネットワーク認証サービス(Kerberosなど)、トークン・カード、スマートカードまたはX.509証明書と一緒に使用することもお薦めします。これらのサービスを使用すると、ユーザーの厳密な認証が可能になるため、Oracle Databaseを不正なアクセスから保護できます。

  9. Oracle表にはユーザー・パスワードをクリアテキストで格納しない。

    セキュリティを強化するために、Oracle表には、ユーザー・パスワードをクリアテキスト(判読可能なテキスト)で格納しないでください。この問題は、安全性の高い外部パスワード・ストアを使用してOracleウォレット内のパスワードを暗号化することで解決できます。(Oracleウォレットは、認証および署名用資格証明を格納する安全性の高いソフトウェア・コンテナです。)詳細は、「パスワード資格証明用の安全性の高い外部パスワード・ストアの管理」を参照してください。

    ユーザー・アカウントのパスワードを作成または変更すると、Oracle Databaseでは、そのパスワードの暗号化ハッシュまたはダイジェストが自動的に作成されます。DBA_USERSビューを問い合せてユーザー・アカウントの情報を検索する場合、PASSWORD列のデータはユーザー・パスワードがグローバル、外部またはNULLのいずれかであるかを示します。DBA_USERSビューにはPASSWORD_VERSIONSという列もあり、この列には、そのユーザーのパスワードのために存在する暗号化ハッシュのタイプ(11Gまたは12C)が一覧表示されます。これらの略称が対応している暗号化アルゴリズムについては、Oracle DatabaseリファレンスのDBA_USERSに関する項を参照してください。

  10. ユーザーがXDB認証もHTTPダイジェスト認証も使用しない場合は、HTTPベリファイアを無効にします。

    HTTPベリファイアは、XDB認証およびHTTPダイジェスト認証にのみ使用されます。ユーザーがXDB認証もHTTPダイジェスト認証も使用しない場合は、ユーザーのベリファイア・リストからHTTPベリファイアを安全に削除できます。ユーザーのHTTPベリファイアを削除するには、次の文を実行します。

    ALTER USER username DIGEST DISABLE;

親トピック: Oracle Databaseの安全性の維持

A.6 データの保護に関するガイドライン

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 Databaseの安全性の維持

A.7 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 Databaseの安全性の維持

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

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、6および7に従います。

  4. インストール直後に、デフォルトのユーザー・アカウントをロックし、期限切れにする。

    ユーザー・アカウントと権限の保護に関するガイドラインのガイドライン1を参照してください。

親トピック: Oracle Databaseの安全性の維持

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

ネットワーク通信のセキュリティは、クライアント、リスナー、および完全な保護を確保するためのネットワーク・ガイドラインを使用することで改善されます。

親トピック: Oracle Databaseの安全性の維持

A.9.1 クライアント接続のセキュリティ

クライアントを厳密に認証し、接続に対する暗号化を構成して、厳密認証を使用すると、クライアント接続が強化されます。

クライアント・コンピュータの認証には問題が多いため、通常は、かわりにユーザー認証が実施されます。このアプローチは、クライアント・システムで、偽造された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ネイティブ・ネットワーク暗号化を使用すると、傍受が困難となります。

  3. 強力な認証を設定する。

    Kerberosおよび公開キー・インフラストラクチャ(PKI)の使用方法の詳細は、Kerberos認証の構成を参照してください。

  4. Oracle Data Guard環境で、ADG_ACCOUNT_INFO_TRACKING初期化パラメータを設定します。

    ADG_ACCOUNT_INFO_TRACKINGパラメータは、Oracle Active Data Guardスタンバイ・データベースでのログイン試行を制御します。これにより、Oracle Databaseの本番環境とすべてのActive Data Guardスタンバイ・データベースにおいてログイン侵入攻撃に対するセキュリティが強化されます。次のいずれかの設定を使用します。

    • LOCAL(デフォルト)では、既存の動作(スタンバイ・データベースのインメモリー・ビューでユーザー・アカウント情報のローカル・コピーを保持)が適用されます。この設定では、データベース単位でローカルのログイン失敗のみが追跡されます。ログイン失敗の最大回数に達すると、ログインが拒否されます。

    • GLOBALでは、すべてのData Guardプライマリ・データベースおよびスタンバイ・データベースにおいてユーザー・アカウント情報の単一グローバル・コピーを維持することで、ログインのセキュリティが強化されます。Data Guard環境のすべてのデータベースでのログイン失敗回数が、最大回数の対象としてカウントされます。この数に達すると、どこでもログインがアクセス拒否されます。

    ADG_ACCOUNT_INFO_TRACKINGパラメータについてさらに学習するには、Oracle Databaseリファレンスを参照してください。

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

A.9.2 ネットワーク接続のセキュリティ

不適切なアクセスまたは変更からネットワークとその通信を保護することは、ネットワーク・セキュリティの最重要点です。

データが移動するすべてのパスを検討し、各パスおよびノードに対する脅威を評価してください。次に、脅威およびセキュリティが侵害された場合の結果を抑制または排除するステップを実行します。また、監視および監査を実施し、脅威レベルの増加または侵入試行を検出します。

ネットワーク接続の管理には、Oracle Net Managerを使用できます。Net Managerの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

次の手続きでネットワーク・セキュリティを改善します。

  1. リスナーの管理にSecure Sockets Layer(SSL)を使用する。

    詳細は、Secure Sockets Layer接続のセキュリティを参照してください。

  2. リスナーのパスワードおよびサーバー上のlistener.oraファイルへの書込み権限は、管理者が保持するように規定することで、オンライン管理を回避する。

    1. この行をlistener.oraファイルに追加するか、またはこの行を変更してください。 

      ADMIN_RESTRICTIONS_LISTENER=ON

    2. RELOADを使用して構成を再ロードします。

    3. 次のように、アドレス・リストでTCPSプロトコルを最初のエントリにすることで、リスナーの管理にSSLを使用します。

      LISTENER=
  (DESCRIPTION=
    (ADDRESS_LIST=
      (ADDRESS=
        (PROTOCOL=tcps)
        (HOST = sales.us.example.com)
        (PORT = 8281)))

      リスナーをリモート管理するために、クライアント・コンピュータのlistener.oraファイルにリスナーを定義します。たとえば、リスナーUSER281にリモートでアクセスするには、次の構成を使用します。 

      user281 =
  (DESCRIPTION =
    (ADDRESS =
      (PROTOCOL = tcps)
      (HOST = sales.us.example.com)
      (PORT = 8281))
    )
  )

    listener.oraのパラメータの詳細は、Oracle Database Net Servicesリファレンスを参照してください。

  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. 暗号化を使用して、転送中のデータを保護する。

    ネットワーク・データの暗号化の詳細は、「厳密認証の概要」を参照してください。

  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のネイティブ・ネットワーク暗号化とデータ整合性の構成を参照してください。

  11. ホスト・オペレーティング・システム(Oracle Databaseがインストールされているシステム)を保護する。

    オペレーティング・システムの不要なサービスをすべて使用禁止にして、ホスト・オペレーティング・システムを保護します。UNIXおよびWindowsには様々なオペレーティング・システム・サービスが組み込まれていますが、それらの大部分は、一般的なデプロイメントには不要です。これらのサービスには、FTP、TFTP、TELNETなどがあります。使用を禁止している各サービスのUDPポートとTCPポートは、両方とも必ず閉じてください。一方のポートを使用禁止にしていても、他方のポートが使用可能であると、オペレーティング・システムの安全性が低下します。

  12. データベース・リンクの通信プロトコルを構成する。

    データベース・リンクの通信で使用するプロトコルを指定するには、OUTBOUND_DBLINK_PROTOCOLS初期化パラメータを次の設定のいずれかに設定します。

    • ALL (デフォルト)は、データベース・リンクですべてのネット・プロトコルを使用できます。

    • comma-separated_list_of_protocolsには、TPC、TCPSまたはIPCを設定できます。たとえば、1つのプロトコルの場合は、次のようになります。 

      ALTER SYSTEM SET OUTBOUND_DBLINK_PROTOCOLS=TCPS;

      複数のプロトコルの場合は、次のようになります。

      ALTER SYSTEM SET OUTBOUND_DBLINK_PROTOCOLS=TCP,TCPS,IPC;

    • NONEは、データベース・リンクの通信を無効にします。

  13. 必要な場合、グローバル・データベース・リンクのLDAPルックアップを無効にする。

    ALLOW_GLOBAL_DBLINKS初期化パラメータを設定して、グローバル・データベース・リンクのLDAPルックアップを有効または無効にします。次の設定があります。

    • ONは、グローバル・データベース・リンクのLDAPルックアップを有効にします。

    • OFF (デフォルト)は、グローバル・データベース・リンクのLDAPルックアップを無効にします。

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

A.9.3 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として起動し、別のユーザーとしてログインします。そうしないと、このキーを取得しただれもがネット上でルート・ユーザーになりすましたり、サーバーに送信されたデータを復号化する可能性があります。

    関連項目:

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

A.10 外部プロシージャの保護に関するガイドライン

ENFORCE_CREDENTIAL環境変数では、extprocプロセスがどのようにユーザー資格証明およびコールアウト関数を認証するかを制御します。

この変数はextproc.oraファイルに指定できます。この変数を変更する前に、外部ライブラリの処理用にサイトのセキュリティ要件を確認します。セキュリティを最大にするために、ENFORCE_CREDENTIAL変数をTRUEに設定します。デフォルト設定はFALSEです。

関連項目:

外部プロシージャの保護

親トピック: Oracle Databaseの安全性の維持

A.11 監査に関するガイドライン

Oracleには、監査のためのガイドラインがあります。

親トピック: Oracle Databaseの安全性の維持

A.11.1 監査情報の管理の容易性

監査は比較的低コストですが、監査するイベントの数はできるだけ制限してください。

この制限によって、監査対象の文を実行したときのパフォーマンスへの影響が最小限に抑えられ、監査証跡のサイズが最小限になるため、分析と理解が容易になります。

監査方針を企画する際は、次のガイドラインに従ってください。

  1. 監査の目的を評価する。

    監査の目的を明確にしておくと、適切な監査方針を企画でき、不要な監査を回避できます。

    たとえば、不審なデータベース・アクティビティの調査のために監査すると仮定します。この情報のみでは不明確です。どのデータベース・アクティビティが疑わしい、または注意を要するといった具体的な情報が必要です。そのために、たとえば、データベース内の表から無許可にデータが削除されていないかを監査するというように、監査方針を絞り込みます。このような目的を設定すれば、監査の対象となるアクションの種類や、疑わしいアクティビティによって影響を受けるオブジェクトの種類を限定できます。

  2. 監査について十分理解する。

    目標とする情報の取得に必要な最小限の文、ユーザーまたはオブジェクトを監査します。これによって、不要な監査情報のために重要な情報の識別が困難になることや、SYSTEM表領域内の貴重な領域が無駄に使用されることがなくなります。収集が必要なセキュリティ情報の量と、その情報を格納して処理する能力とのバランスを保つ必要があります。

    たとえば、データベース・アクティビティに関する情報を収集するために監査する場合は、追跡するアクティビティの種類を正確に判断した上で、必要な情報を収集するために必要な期間内で、目的のアクティビティのみを監査します。別の例として、各セッションの論理I/O情報のみを収集する場合は、オブジェクトを監査しないでください。

  3. 監査方針を実施する前に法務部門と打ち合せる。

    組織の法務部門に監査方針を検討するように依頼する必要があります。監査では組織の他のユーザーが監視されるため、サイトのコンプライアンス・ポリシーと会社の方針に適切に従っていることを確認する必要があります。

親トピック: 監査のガイドライン

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

Oracleには、特定のデータベース・アクティビティに関する履歴情報を収集する必要がある場合のガイドラインがあります。

  1. 関連のあるアクションのみを監査する。

    少なくとも、ユーザー・アクセス、システム権限の使用およびデータベース・スキーマ構造の変更を監査します。役に立たない監査レコードのために重要な情報が識別できない事態を避け、監査証跡管理の量を削減するために、目的のデータベース・アクティビティのみを監査してください。監査対象が多すぎるとデータベースのパフォーマンスに影響する可能性があることにも注意してください。

    たとえば、データベースのすべての表に対する変更を監査すると、監査証跡レコードが多くなりすぎてデータベースのパフォーマンスが低下する可能性があります。ただし、Human Resources(人事管理)表内の給与のように、重要な表に対する変更を監査することは有益です。

    ファイングレイン監査を使用することで、特定のアクションを監査できます。ファイングレイン監査については、ファイングレイン監査を使用した特定のアクティビティの監査を参照してください。

  2. 監査レコードをアーカイブし、監査証跡を削除する。

    必要な情報を収集した後は、目的の監査レコードをアーカイブし、この情報の監査証跡を削除します。次の項を参照してください。

  3. 自社のプライバシに関する考慮事項を検討する。

    プライバシに関する法規によって、追加のビジネス・プライバシ・ポリシーが必要となる場合があります。プライバシに関するほとんどの法規では、個人を特定できる情報(PII)へのアクセスをビジネスで監視する必要があり、このような監視は監査によって実施されます。ビジネス・レベルのプライバシ・ポリシーでは、技術的、法的および企業ポリシーの問題など、データ・アクセスおよびユーザー・アカウンタビリティに関するすべての事項を処理する必要があります。

  4. その他の監査情報をOracle Databaseのログ・ファイルでチェックする。

    Oracle Databaseによって生成されたログ・ファイルには、データベースの監査時に使用できる有益な情報が含まれています。たとえば、Oracle Databaseではアラート・ファイルが作成され、STARTUP操作、SHUTDOWN操作およびデータベースにデータ・ファイルを追加するなどの構造上の変更が記録されます。

    たとえば、コミットまたはロールバックされたトランザクションを監査する場合は、REDOログ・ファイルを使用できます。

  5. 監査証跡および再帰的SQL文のサイズを減らすには、トップレベルの文のみを監査します。

    作成する統合監査ポリシーによって非常に多数のレコードが生成されることが懸念される場合は、CREATE AUDIT POLICY文にONLY TOPLEVEL句を含めます。たとえば、DBMS_STATS.GATHER_DATABASE_STATS SQL文の監査では、何千もの監査レコードが生成されます。ユーザーSYSを含むすべてのユーザーからトップレベルの文を監査できます。

親トピック: 監査のガイドライン

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

Oracleには、不審なデータベース・アクティビティの監視を監査する場合のガイドラインがあります。

  1. 最初に一般的な監査を行い、特定の対象を監査する。

    疑わしいデータベース・アクティビティの監査を開始するとき、通常は対象のユーザーまたはスキーマ・オブジェクトの特定に使用できる情報がありません。したがって、まず、一般的な監査、つまり、統合監査ポリシーを使用した監査を行います。「監査ポリシーの構成」に、SQL文、スキーマ、オブジェクト、権限などを監査する方法が説明されています。

    準備的な監査情報の記録と分析を終了した後は、監査ポリシーを変更して特定のアクションと権限を監査します。ポリシーに条件を追加して、不要な監査レコードを除外できます。AUDIT POLICY文でEXCEPT句を使用して、監査する必要のない特定のユーザーを除外することもできます。統合監査ポリシーの詳細は、統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査を参照してください。

    ファイングレイン監査を使用した特定のアクティビティの監査で説明するように、ファイングレイン監査を使用して特定のアクションを監査できます。

    この処理は、疑わしいデータベース・アクティビティの原因について結論が出せるだけの十分な裏付けが収集できるまで継続してください。

  2. 一般的な疑わしいアクティビティを監査する。

    一般的な疑わしいアクティビティは、次のとおりです。

    • 通常以外の時間中にデータベースにアクセスするユーザー

    • 複数回失敗したユーザー・ログイン試行

    • 存在しないユーザーによるログイン試行

    また、SQLテキストなど、SQL問合せで使用すると、クレジット・カード番号などの機密データが監査証跡の列に表示される可能性があることに注意してください。アカウントを共有しているユーザー、または同じIPアドレスからログインしている複数のユーザーを監視する必要もあります。この種のアクティビティは、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることで検索できます。非常にきめ細かい方法では、ファイングレイン監査ポリシーを作成します。

親トピック: 監査のガイドライン

A.11.4 機密データの監査

機密オブジェクトに対して統合監査ポリシーを作成する場合は、ACTIONS ALL句を含めることをお薦めします。

この句を含めると、これらの機密オブジェクトへの直接アクセスと間接アクセスの両方に対する監査レコードが確実に生成されます。ACTIONS ALLは、機密オブジェクトの監査にのみ使用してください。

関連トピック

親トピック: 監査のガイドライン

A.11.5 監査の推奨設定

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を監査します。デフォルトでは、このポリシーは有効になっていません。

関連項目:

これらの事前定義の監査ポリシーとその他の監査ポリシーの詳細は、事前定義の統合監査ポリシーを使用したアクティビティの監査を参照してください

親トピック: 監査のガイドライン

A.11.6 UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューのためのベスト・プラクティス

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューの問合せから最良の結果を得るには、次のガイドラインに従う必要があります。

  1. 統合監査内部表の統計が最新であることを確認してください。

    UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せる前に、AUDSYSスキーマのAUD$UNIFIED表でDBMS_STATS.GATHER_TABLE_STATSプロシージャを実行して、統合監査表の統計が更新されるようにします。

  2. オペレーティング・システムの過剰ファイルに書き込まれた統合監査レコードをロードします。

    これは、明示的に実行するか、DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILESプロシージャを使用してOracle Schedulerジョブを構成することによって実行できます。

  3. 統合監査証跡内のレコード数が非常に大きい数(100万など)に達したら、適切なアーカイブおよびパージ・メカニズムを開始します。

    統合監査証跡をアーカイブおよび削除すると、そうしない場合は量が増大して読取りパフォーマンスの問題が発生する可能性があるデータの量が減少します。標準の削除ポリシーを構成することをお薦めします。作成する削除ポリシーは、システムで生成される監査レコードの率によって異なります。監査レコード生成率が高い場合は、頻繁な削除が必要です。

  4. 統合監査証跡をカスタム表領域に移動します。

    カスタム表領域を使用すると、監査データをより適切に管理でき、SYSAUX表領域の他のオブジェクトへの影響が軽減されます。デフォルトでは、統合監査証跡レコードはSYSAUX表領域に書き込まれます。別の表領域を使用するには、DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATIONプロシージャを実行します。

  5. UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せる場合は、EVENT_TIMESTAMP_UTC列をWHERE句に含めます。

    EVENT_TIMESTAMP_UTC列は、UTCタイムゾーン内の監査イベントのタイムスタンプを記録します。この列を問合せに含めるとパーティション・プルーニングが達成されるため、UNIFIED_AUDIT_TRAILビューの読取りパフォーマンスの向上に役立ちます。

関連トピック

親トピック: 監査のガイドライン

A.12 CONNECTロール変更への対処

CONNECTロールはOracle Databaseリリース7で導入され、データベース・ロールに新しい堅牢なサポートが追加されました。

親トピック: Oracle Databaseの安全性の維持

A.12.1 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ロール変更への対処

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

CONNECTロールの変更は、データベース・アップグレード、アカウント・プロビジョニングおよび新しいデータベースを使用したアプリケーションのインストールにおいて確認できます。

親トピック: CONNECTロール変更への対処

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

CONNECTロールがデータベース・アップグレードに与える影響に注意してください。

既存のOracleデータベースをOracle Database 10gリリース2 (10.2)にアップグレードすると、CONNECTロールの権限はCREATE SESSION権限のみになるよう自動的に変更されます。

ほとんどのアプリケーションは、アプリケーション・オブジェクトがすでに存在するため、この影響を受けません。新たに表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成する必要はありません。

表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSIONコマンドを動的に使用するアプリケーションは、権限が不十分なために失敗する場合があります。

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

CONNECTロールがアカウント・プロビジョニングに与える影響に注意してください。

アプリケーションまたはDBAがアカウント・プロビジョニング・プロセスの一部としてCONNECTロールを付与する場合は、CREATE SESSION権限のみが含まれます。追加の権限は、直接または別のロールを介して付与する必要があります。

この問題は、カスタマイズされた新しいデータベース・ロールを作成することで対処できます。

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

CONNECTロールが新規のデータベースを使用するアプリケーションに与える影響に注意してください。

Oracle Database 10g リリース2(10.2)のユーティリティ(DBCA)、またはDBCAから生成されたデータベース作成テンプレートを使用して作成された新しいデータベースでは、CREATE SESSION権限のみを伴ったCONNECTロールが定義されます。

新しいデータベースを使用するアプリケーションのインストールは、そのアプリケーションに使用されているデータベース・スキーマの権限がCONNECTロールのみを介して付与されている場合、失敗する可能性があります。

A.12.3 CONNECTロール変更がユーザーに与える影響

CONNECTロールへの変更による影響は、一般ユーザー、アプリケーション開発者およびクライアント/サーバー・アプリケーションでそれぞれ異なります。

親トピック: CONNECTロール変更への対処

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

CONNECTロールが一般ユーザーに与える影響に注意してください。

新しいCONNECTロールは、CREATE SESSION権限のみを提供します。アプリケーションを使用するためにデータベースに接続するユーザーの場合、CONNECTロールにはまだCREATE SESSION権限があるため影響はありません。

ただし、CONNECTロールのみでプロビジョニングされた特定のユーザーの場合は、適切な権限がないことになります。表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSIONコマンドを使用するユーザーです。これらのユーザーに必要な権限は、CONNECT ロールでは提供されなくなりました。必要な追加権限を認可するには、データベース管理者が該当する権限用の追加ロールを作成および適用するか、その権限を必要としているユーザーに直接付与する必要があります。

ALTER SESSION権限は、イベントを設定するために必要です。ALTER SESSION権限が必要なデータベース・ユーザーはほとんどいません。

ALTER SESSION権限は、他のALTER SESSIONコマンドには必要ありません。

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

CONNECTロールがアプリケーション開発者に与える影響に注意してください。

CONNECTロールのみでプロビジョニングされたアプリケーション開発者には、表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSION文を使用するための適切な権限はありません。

該当する権限用の追加ロールを作成および適用するか、その権限を必要としているアプリケーション開発者に直接付与する必要があります。

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

CONNECTロールがクライアント・サーバー・アプリケーションに与える影響に注意してください。

専用のユーザー・アカウントを使用するほとんどのクライアント/サーバー・アプリケーションは、この変更の影響は受けません。

ただし、アカウント・プロビジョニングまたはランタイム操作時に、動的SQLを使用してユーザー・スキーマ内にプライベート・シノニムまたは一時表を作成するアプリケーションは影響を受けます。この場合は、その動作に適したシステム権限を取得するための追加ロールや権限付与が必要です。

A.12.4 CONNECTロール変更に対処する方法

CONNECTロールの変更の影響に対処するには、次の3つの方法をお薦めします。

親トピック: CONNECTロール変更への対処

A.12.4.1 新しいデータベース・ロールの作成

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ロール変更に対処する方法

A.12.4.2 CONNECT権限のリストア

rstrconn.sqlスクリプトはCONNECT権限をリストアします。

データベースのアップグレードまたは新しいデータベースの作成後は、このスクリプトを使用して、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.
A.12.4.3 CONNECT権限受領者を表示するデータ・ディクショナリ・ビュー

DBA_CONNECT_ROLE_GRANTEESデータ・ディクショナリ・ビューを使用すると、古いCONNECTロールを継続して使用する管理者は、どのユーザーがそのロールを持っているかを確認できます。

表A-1に、DBA_CONNECT_ROLE_GRANTEESビューの列を示します。

表A-1 DBA_CONNECT_ROLE_GRANTEESの列と内容

列 データ型 NULL 説明

GRANTEE

VARCHAR2(128)

NULL

CONNECTロールを付与されたユーザー。

PATH_OF_CONNECT_ROLE_GRANT

VARCHAR2(4000)

NULL

ユーザーへのCONNECTの付与に使用されたロール(またはネストされたロール)。

ADMIN_OPT

VARCHAR2(3)

NULL

ユーザーのCONNECTにADMINオプションがある場合はYES、ない場合はNO。
A.12.4.4 最低限の権限の分析調査

Oracleパートナおよびアプリケーション・プロバイダは、より安全性の高い製品をOracleの顧客に供給できるように最低限の権限の分析を行う必要があります。

「最低限の権限」原則は、所定の機能を実行するために必要な最低限のセットに権限を制限することでリスクを軽減します。

分析によって同一の権限セットが必要とされたユーザーのクラスごとに、その権限のみを持ったロールを作成します。他の権限はすべて該当するユーザーから取り消し、作成したロールを割り当てます。必要な権限が変化したときは、追加の権限を直接またはこれらの新しいロールを介して付与するか、新たに必要となった権限に応じた新しいロールを作成できます。この方法を使用すると、不適切な権限が制限され、不注意または意図的な被害が軽減されます。

データベース・ユーザーによる権限の使用状況を分析するポリシーを作成できます。ポリシーはこの情報を取得し、データ・ディクショナリ・ビューで使用できるようにします。これらのレポートに基づいて、だれにデータへのアクセス権限を持たせるかを決定できます。

関連項目:

権限分析の詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

親トピック: CONNECTロール変更に対処する方法