| Oracle® Databaseセキュリティ・ガイド 12c リリース1 (12.1) B71285-10 |
|
 前 |
 次 |
Oracleには、ユーザー・アカウント、権限、ロール、パスワード、データなどの保護に関するアドバイスを含む、データベースの安全性を維持できる一連のガイドラインがあります。
内容は次のとおりです。
情報のセキュリティとプライバシ、および企業の資産とデータの保護は、どのようなビジネスにおいても非常に重要です。
Oracle Databaseは、厳重なデータ保護、監査、スケーラブルなセキュリティ、安全なホスティング、データ交換などの最先端のセキュリティ機能を提供することによって、情報セキュリティに対するニーズに幅広く対応します。
Oracle Databaseは、セキュリティ機能において業界をリードしています。Oracle Databaseが提供するセキュリティ機能をすべてのビジネス環境で最大限に活用するには、データベース自体の保護が万全であることが必須条件です。
セキュリティ・ガイドラインは、運用データベースのデプロイメントに関する業界標準として推奨されるセキュリティ・プラクティスに準拠し、それを推奨することによって、Oracle Databaseを安全に構成する方法を示しています。この項で説明するガイドラインの多くは、米国サーベンス・オクスリー法(Sarbanes-Oxley Act)で規定されているような一般的な規制要件に対応しています。法令順守、個人を特定できる情報の保護、および内部の脅威に対するOracle Databaseの対処方法の詳細は、次の場所を参照してください。
http://www.oracle.com/technetwork/topics/security/whatsnew/index.html
セキュリティ・パッチが入手可能になったら、必ずすぐに適用する必要があります。問題が発生した場合、脆弱性についてOracleに連絡してください。
内容は次のとおりです。
セキュリティ・パッチは、Oracle Databaseを稼働しているオペレーティング・システムとOracle Database自体、およびインストール済のOracle Databaseのオプションとコンポーネントすべてに適用されます。
セキュリティ・パッチおよび回避ソリューションをダウンロードする手順は、次のとおりです。
セキュリティ・パッチについては、Oracle Technology Networkのセキュリティ・サイトで、Oracleによってリリースされたセキュリティ・アラートに関する詳細を定期的に確認してください: http://www.oracle.com/technetwork/topics/security/alerts-086861.html
Oracleワールドワイド・サポート・サービスのサイト、My Oracle Supportで、セキュリティに関するパッチの入手可能性や予定などを確認してください:
Oracle Databaseの脆弱性に関してOracleのセキュリティ窓口に連絡できます。
Oracleのセキュリティ窓口への連絡には、次のいずれかの方法を使用します。
OracleユーザーまたはOracleパートナであるユーザーがOracle製品の潜在的なセキュリティ上の脆弱性を発見した場合は、My Oracle Supportを使用してサービス・リクエストを発行してください。
製品のバージョンやプラットフォームも含めた問題の詳細を、スクリプトと例を添えて、電子メールでsecalert_us@oracle.comに送信してください。オラクル社にお問合せの際は、弊社の暗号鍵を使用して、電子メールを暗号化することをお薦めします。
Oracleには、ユーザー・アカウントと権限を保護するガイドラインがあります。
「最低限の権限」原則を実践する。
次のガイドラインに従うことをお薦めします。
必要な権限のみを付与する。
データベース・ユーザーまたはロールに、必要以上の権限を付与しないでください。(可能な場合、ユーザーではなくロールに権限を付与してください。)つまり、最小権限の原則とは、ユーザーに、効率的かつ簡潔に作業を行うために実際に必要な権限のみを与えることです。
この原則を実装するには、次の項目について可能なかぎり制限します。
データベース・ユーザーに付与するSYSTEMおよびOBJECT 権限の数。
SYS権限によってデータベースに接続できるユーザーの数。
DROP ANY TABLE権限などのANY権限を付与する対象のユーザー数。たとえば、通常、DBA権限のないユーザーにCREATE ANY TABLE権限を付与する必要はありません。
データベース・オブジェクトを(TRUNCATE TABLE、DELETE TABLE、DROP TABLE文などで)作成、変更または削除を実行できるユーザーの数。
CREATE ANY EDITIONおよびDROP ANY EDITION権限の付与を制限する。
オブジェクトの追加バージョンを維持するために、エディションではデータベース内のリソースおよびディスク領域の使用量を増やすことができます。CREATE ANY EDITIONおよびDROP ANY EDITION権限は、アップグレードの実行を担当する信頼できるユーザーにのみ付与します。
ユーザーに付与したSELECTオブジェクト権限およびSELECT ANY TABLEシステム権限を再評価する。
ユーザーが表、ビュー、マテリアライズド・ビューおよびシノニムの問合せのみを行えるように制限する場合、READオブジェクト権限を付与し、信頼できるユーザーにのみREAD ANY TABLEシステム権限を付与します。問合せ操作の実行以外に、ユーザーが排他モードでの表のロックまたはSELECT ... FOR UPDATE文を実行できるようにする場合、ユーザーにSELECTオブジェクト権限を付与し、信頼できるユーザーにのみSELECT ANY TABLEシステム権限を付与します。
CREATE ANY JOB、BECOME USER、EXP_FULL_DATABASEおよびIMP_FULL_DATABASE権限を制限する。CREATE DIRECTORYおよびCREATE ANY DIRECTORY権限の付与も制限してください。
これらは強力なセキュリティ関連権限です。これらの権限は、必要とするユーザーにのみ付与してください。
ライブラリ関連の権限を信頼できるユーザーのみに制限する。
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ロールに対して付与しないでください。
制限シノニム関連の権限を信頼できるユーザーのみに制限する。
CREATE PUBLIC SYNONYMおよびDROP PUBLIC SYNONYMシステム権限によって、これらのユーザーに大きい力が与えられます。信頼できないかぎり、これらの権限をユーザーに付与しないでください。
SYSスキーマが所有するオブジェクトに、管理者以外のユーザーがアクセスできないようにする。
ユーザーが表の行やSYSスキーマのスキーマ・オブジェクトを変更できないようにしてください。変更されると、データ整合性が損われる危険があります。DROP TABLE、TRUNCATE TABLE、DELETE、INSERTなどの文、または類似したオブジェクト変更文のSYSオブジェクトに対する使用を、強い権限を持つ管理ユーザーのみに制限してください。
SYSスキーマはデータ・ディクショナリを所有します。データ・ディクショナリは、O7_DICTIONARY_ACCESSIBILITYパラメータをFALSEに設定することで保護できます。詳細は、データの保護に関するガイドラインを参照してください。
DBMS_RANDOM PL/SQLパッケージに対するEXECUTE権限を、信頼できるユーザーにのみ付与する。
DBMS_RANDOMパッケージのEXECUTE権限は、通常は最低限のアクセス権しか持たないユーザーが、このパッケージに関連付けられたファンクションを実行するのを許可できます。
ランタイム機能の権限を制限する。
多くの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');
デフォルト(事前定義)のユーザー・アカウントをロックし、期限切れにする。
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を含む)をロックし、期限切れにします。
次のデータ・ディクショナリ・ビューを使用して、データベースへのユーザー・アクセスに関する情報を検索する。
DBA_*
DBA_ROLES
DBA_SYS_PRIVS
DBA_ROLE_PRIVS
DBA_TAB_PRIVS
DBA_AUDIT_TRAIL(標準監査が使用可能な場合)
DBA_FGA_AUDIT_TRAIL(ファイングレイン監査が使用可能な場合)
次のビューまたはロールからアクセス権を取り消す。
SYSとDBAアカウント以外のすべてのユーザーからSYS.USER_HISTORY$表を取り消します。
通常のアプリケーション・アカウントからRESOURCEロールを取り消します。
通常のアプリケーション・アカウントからCONNECTロールを取り消します。
DBAロールが不要なユーザーから、このロールを取り消します。
ロールに対してのみ権限を付与する。
個々のユーザーではなくロールに権限を付与すると、権限の管理および追跡が容易になります。
プロキシ・アカウント(プロキシ認可の場合)の権限をCREATE SESSIONのみに制限する。
セキュア・アプリケーション・ロールを使用して、アプリケーション・コードによって有効化するロールを保護する。
セキュア・アプリケーション・ロールでは、ユーザーがアプリケーションにログインできるかどうかを判断する一連の条件を、PL/SQLパッケージ内で定義できます。ユーザーはセキュア・アプリケーション・ロールではパスワードを使用する必要がありません。
ロールがアプリケーション内で使用可能または使用禁止になるのを防ぐ別の方法は、ロールのパスワードを使用することです。この方法では、ユーザーが、データベースにSQL(アプリケーションではなく)で直接アクセスして、ロールに関連付けられている権限を使用することを防ぎます。ただし、別の一連のパスワードを管理する必要がないように、セキュア・アプリケーション・ロールの使用をお薦めします。
ユーザーが、SQL文でNOLOGGING句を使用できないようにする。
いくつかのSQL文で、ユーザーはオプションとしてNOLOGGING句を指定できます。このオプションを指定すると、データベース操作がオンラインREDOログ・ファイルに記録されません。ユーザーがこの句を指定しても、REDOレコードがオンラインREDOログ・ファイルに書き込まれます。しかし、このレコードに関連付けられたデータはありません。このため、NOLOGGINGを使用すると、不正コードが入力されて、監査証跡に記録されずに実行される可能性があります。
権限キャプチャを作成して、過度に付与されている権限を検索する。詳細は、『Oracle Database Vault管理者ガイド』を参照してください。
次の権限が、それらを必要としているユーザーとロールのみに付与されていることを監視する。
デフォルトでは、次の権限が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には、ロール管理のガイドラインがあります。
ロールは、そのロールの権限すべてを必要とするユーザーにのみ付与する。
ロール(権限のグループ)は、ユーザーに許可を素早く簡単に付与する場合に便利です。Oracleで定義されているロールを使用することもできますが、必要な権限のみを含む独自のロールを作成すると、より継続的な制御が可能になります。Oracle Database定義ロールの権限は変更または削除される場合があります。たとえばCONNECTロールの場合、現在持っている権限はCREATE SESSION権限のみです。以前は他に8個の権限がありました。
定義したロールには担当業務を反映する権限のみが含まれていることを確認してください。アプリケーション・ユーザーが既存のロールに組み込まれている権限のすべては必要としていない場合は、適切な権限のみを含む異なるロールのセットを適用してください。または、さらに権限が制限されているロールを作成して割り当てます。
たとえば、ユーザーSCOTTはよく知られているアカウントで、侵入されやすい可能性があるため、このユーザーの権限を厳密に制限する必要があります。CREATE DBLINK権限ではあるデータベースから別のデータベースへのアクセスが許可されるため、SCOTTに対するこの権限を削除します。次に、このユーザーのロール全体を削除します。これは、ロールによって付与される権限は、個別に削除できないためです。必要な権限のみを含む独自のロールを再作成し、新しいロールをユーザーに付与します。同様に、セキュリティを高めるために、CREATE DBLINK権限を必要としないすべてのユーザーからこの権限を削除します。
アプリケーション開発者にはユーザー・ロールを付与しない。
ストアド・プログラム構文内のスキーマ・オブジェクトにアクセスする権限は直接付与される必要があるため、ロールはアプリケーション開発者の使用を目的としていません。実行者権限プロシージャを除くストアド・プロシージャ内ではロールが有効でないことに注意してください。詳細は、PL/SQLブロックでのロールの機能を参照してください。
Oracle Databaseのインストールごとに固有のロールを作成して割り当てる。
これにより、組織でロールおよび権限を詳細に制御できます。また、現在はCREATE SESSION権限のみとなっているCONNECTなどのOracle Database定義のロールを、Oracle Databaseで変更または削除した場合の調整が不要となります。以前は他にも8つの権限がありました。
エンタープライズ・ユーザーに対してグローバル・ロールを作成する。
グローバル・ロールは、Oracle Internet Directoryなどのエンタープライズ・ディレクトリ・サービスで管理されます。グローバル・ロールの詳細は次の各項を参照してください。
Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド
Oracleには、パスワードを保護するガイドラインがあります。
ユーザー・アカウントを作成すると、そのユーザーに対してデフォルトのパスワード・ポリシーが割り当てられます。このパスワード・ポリシーには、パスワードの作成方法(最小文字数や期限切れの時期など)についてのルールが定義されています。パスワードは、パスワード・ポリシーを使用することで強化できます。パスワードを保護するための別の方法については、「パスワード保護の構成」も参照してください。
パスワードをさらに強化するには、次のガイドラインに従います。
パスワードを慎重に選択する。
パスワードの最低要件については、「パスワードの最低要件」を参照してください。パスワードを作成または変更する際には、次の追加のガイドラインに従います。
パスワードは12から30文字の英数字にします。
パスワードには、数値、大文字および小文字を少なくとも1文字ずつ含めます。
パスワードには、大/小文字と特殊文字を混在させて使用します。(「パスワードのセキュリティへの脅威からの12Cパスワード・バージョンによる保護」を参照してください。)
パスワードには、マルチバイト・キャラクタを含めることができます。
パスワードの文字にはデータベース・キャラクタ・セットを使用します。このセットには、アンダースコア(_)、ドル記号($)および番号記号(#)の各文字があります。
次のパスワードは二重引用符で囲む必要があります。
マルチバイト・キャラクタを含むパスワード。
数値または特殊文字で始まり、アルファベットを含むパスワード。例:
"123abc"
"#abc"
"123dc$"
アルファベット、数値および特殊文字以外の文字を含むパスワード。例:
"abc>"
"abc@"
" "
次のパスワードは二重引用符で囲む必要はありません。
アルファベット(aからz、AからZ)で始まり、数字(0から9)または特殊文字($、#、_)を含むパスワード。次に例を示します。
abc123
ab23a
ab$#_
数値のみを含むパスワード。
アルファベットのみを含むパスワード。
パスワードには二重引用符を使用しないでください。
意味のある単語のみで構成されるパスワードを使用しないでください。
より長く複雑で覚えやすいパスワードを作成するには、次のテクニックを使用します。
覚えやすいセンテンスの各語の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とすることができます。
十分複雑なパスワードを使用するようにする。
Oracle Databaseには、パスワードの複雑度が十分であるかどうかをチェックするためのパスワード複雑度検証ルーチン(PL/SQLスクリプトutlpwdmg.sql)が用意されています。理想的には、utlpwdmg.sqlスクリプトを編集して、パスワードの安全性を高めます。パスワードのチェックに使用できるサンプル・ルーチンについては、「パスワードの複雑度検証の概要」も参照してください。
ユーザー・プロファイルまたはデフォルト・プロファイルに対してパスワード複雑度ファンクションを関連付けます。
CREATE PROFILE文とALTER PROFILE文のPASSWORD_VERIFY_FUNCTION句により、ユーザー・プロファイルまたはデフォルト・プロファイルにパスワード複雑度ファンクションが関連付けられます。パスワード複雑度ファンクションでは、ユーザーがそのサイトに固有のガイドラインを使用して強力なパスワードを作成しているかどうかを確認します。また、パスワード複雑度ファンクションでは、(ALTER USERシステム権限を使用せずに)ユーザーが各自のパスワードを変更して、古いパスワードと新しいパスワードの両方を指定する必要があります。独自のパスワード複雑度ファンクションを作成したり、Oracle Databaseが提供するパスワード複雑度ファンクションを使用できます。
詳細は、「パスワードの複雑度の管理」を参照してください。
デフォルトのユーザー・パスワードを変更する。
Oracle Databaseは、事前定義のデフォルト・ユーザー・アカウントのセットとともにインストールされます。セキュリティは、デフォルトのデータベース・ユーザー・アカウントがインストール後もデフォルト・パスワードを使用している場合に最も崩壊しやすくなります。ユーザー・アカウントSCOTTはよく知られているアカウントで侵入されやすい可能性があるため、これが特に当てはまります。Oracle Databaseでは、デフォルトのアカウントはロックされ、パスワードは期限切れの状態でインストールされますが、以前のリリースからのアップグレードの場合は、デフォルトのパスワードを使用しているアカウントが存在している場合があります。
デフォルトのパスワードが設定されているユーザー・アカウントを検索するには、DBA_USERS_WITH_DEFPWDデータ・ディクショナリ・ビューを問い合せます。詳細は、「デフォルト・パスワードが設定されているユーザー・アカウントの検索」を参照してください。
管理ユーザーのデフォルト・パスワードを変更する。
SYS、SYSTEM、SYSMANおよびDBSNMPの管理アカウントには、同じパスワードまたは異なるパスワードを使用できます。それぞれに対して異なるパスワードを使用することをお薦めします。つまり、すべてのOracle環境(本番またはテスト)において、これらの管理アカウントに強固で安全性の高い、個別のパスワードを割り当てます。Database Configuration Assistantを使用して新規データベースを作成する場合は、SYSおよびSYSTEMアカウントにパスワードを入力して、デフォルトのパスワードCHANGE_ON_INSTALLおよびMANAGERを使用できないようにします
同様に、本番環境では、SYSMANおよびDBSNMPも含めて、管理アカウントにはデフォルトのパスワードを使用しないでください。
デフォルト・パスワードの変更の詳細は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。
パスワード管理を徹底する。
基本的なパスワード管理ルール(パスワードの長さ、履歴および複雑度など)をすべてのユーザー・パスワードに適用します。Oracle Databaseには、デフォルト・プロファイルで使用可能なパスワード・ポリシーがあります。この項のガイドライン1には、これらのパスワード・ポリシーがリストされています。ユーザー・パスワードの安全性をさらに高めるために使用できる初期化パラメータついては、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。
ユーザー・アカウントの情報を検索するには、DBA_USERSビューを問い合せます。DBA_USERSビューのPASSWORD列は、パスワードがグローバル、外部またはNULLのいずれであるかを示します。DBA_USERSビューには、ユーザー・アカウントの状態、アカウントがロックされているかどうか、パスワードのバージョンなどの有用な情報が表示されます。
また、可能な場合は、Oracle厳密認証を、ネットワーク認証サービス(Kerberosなど)、トークン・カード、スマートカードまたはX.509証明書と一緒に使用することもお薦めします。これらのサービスを使用すると、ユーザーの厳密な認証が可能になるため、Oracle Databaseを不正なアクセスから保護できます。
Oracle表にはユーザー・パスワードをクリアテキストで格納しない。
セキュリティを強化するために、Oracle表には、ユーザー・パスワードをクリアテキスト(判読可能なテキスト)で格納しないでください。この問題は、安全性の高い外部パスワード・ストアを使用してパスワードが記載されている表の列を暗号化することで解決できます。詳細は、「パスワード資格証明用の安全性の高い外部パスワード・ストアの管理」を参照してください。
ユーザー・アカウントのパスワードを作成または変更すると、Oracle Databaseでは、そのパスワードの暗号化ハッシュまたはダイジェストが自動的に作成されます。DBA_USERSビューを問い合せてユーザー・アカウントの情報を検索する場合、PASSWORD列のデータはユーザー・パスワードがグローバル、外部またはNULLのいずれかであるかを示します。
Oracleには、システムでデータを保護するためのガイドラインがあります。
データ・ディクショナリの保護を有効にする。
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文では付与できませんが、ロールを介して付与できます。ロールの詳細は、「権限とロール認可の構成」を参照してください。
オペレーティング・システムのアクセスを制限する。
次のガイドラインに従ってください。
オペレーティング・システムのユーザー数を制限します。
Oracle Databaseが稼働しているホスト・コンピュータ上のオペレーティング・システム・アカウントの権限(管理、ルート権限またはデータベース管理)を、ユーザーによる業務の遂行に必要な最小限の権限に制限してください。
Oracle Databaseホーム(インストール)ディレクトリやその内容について、デフォルトのファイルやディレクトリのアクセス権を変更できる権限を制限します。オラクル社から特に指示がないかぎり、権限を持つオペレーティング・システム・ユーザーとOracle所有者は、これらのアクセス権を変更しないでください。
シンボリック・リンクを制限します。データベースへのパスやファイルを指定する場合は、そのファイルやパスのどの部分も、信頼のおけないユーザーによる変更が不可能であることを確認します。ファイル、およびパスのすべての構成要素は、データベース管理者、またはrootなどの信頼できるアカウントが所有する必要があります。
この推奨事項は、ログ・ファイル、トレース・ファイル、外部表、BFILEデータ型など、あらゆるタイプのファイルに適用されます。
機密性の高いデータと、データベース・ファイルが格納された全バックアップ・メディアを暗号化する。
一般的な法令順守要件に従って、クレジット・カード番号とパスワードなどの機密性の高いデータを暗号化する必要があります。データベースから機密性の高いデータを削除した場合、暗号化されたデータはデータ・ブロック、オペレーティング・システム・ファイルまたはディスク上のセクターに残りません。
多くの場合、透過的データ暗号化を使用して機密性の高いデータを暗号化する必要があります。詳細は、Oracle Database Advanced Securityガイドを参照してください。また、データを暗号化すべきでない場合は、暗号化で解決しないセキュリティの問題を参照してください。
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には、ORACLE_LOADERアクセス・ドライバを保護するためのガイドラインがあります。
アクセス・ドライバ・プリプロセッサを格納する、別個のオペレーティング・システム・ディレクトリを作成します。Oracle Databaseの各ユーザーが異なるプリプロセッサを実行する場合、オペレーティング・システム・マネージャは複数のディレクトリを作成する必要がある場合があります。特定のユーザーに対して、別のプリプロセッサへのアクセスを許可しながら、あるプリプロセッサの使用を禁止するには、そのプリプロセッサを別個のディレクトリに配置します。すべてのユーザーに同等のアクセス権を付与する必要がある場合は、プリプロセッサをまとめて1つのディレクトリに配置できます。これらのオペレーティング・システム・ディレクトリを作成した後、SQL*Plusで各ディレクトリのディレクトリ・オブジェクトを作成できます。
オペレーティング・システム・ユーザーORACLEに、アクセス・ドライバ・プリプロセッサを実行するための適切なオペレーティング・システム権限を付与します。また、プリプロセッサ・プログラムを、プリプロセッサ・プログラムの管理担当ユーザー以外のオペレーティング・システム・ユーザーによるWRITEアクセスから保護します。
ディレクトリ・オブジェクト内のプリプロセッサ・プログラムを実行する各ユーザーに、EXECUTE権限を付与します。このユーザーには、ディレクトリ・オブジェクトに対するWRITE権限を付与しないでください。ユーザーにディレクトリ・オブジェクトに対するEXECUTE権限とWRITE権限の両方を付与することはできません。
プリプロセッサを含むディレクトリ・オブジェクトを管理するユーザーに、慎重にWRITE権限を付与します。これにより、データベース・ユーザーが誤ってまたは意図的にプリプロセッサ・プログラムを上書きするのを防ぐことができます。
外部表に必要なすべてのデータ・ファイルに対して、別個のオペレーティング・システム・ディレクトリおよびディレクトリ・オブジェクトを作成します。これらのディレクトリおよびディレクトリ・オブジェクトは、アクセス・ディレクトリ・プリプロセッサが使用するディレクトリおよびディレクトリ・オブジェクトとは別個であることが必要です。
オペレーティング・システム・マネージャとともに作業して、このディレクトリへのアクセス権が適切なオペレーティング・システム・ユーザーのみに付与されていることを確認します。ORACLEオペレーティング・システム・ユーザーに、データベース・ユーザーに付与されたREAD権限を持つディレクトリ・オブジェクトを含むすべてのディレクトリへのREADアクセス権を付与します。同様に、ORACLEオペレーティング・システム・ユーザーに、データベース・ユーザーに付与されたWRITE権限を持つすべてのディレクトリへのWRITEアクセス権を付与します。
アクセス・ドライバが生成するあらゆるファイルに対して、別々のオペレーティング・システム・ディレクトリおよびディレクトリ・オブジェクトを作成します。これには、ログ・ファイル、不良ファイル、および廃棄ファイルが含まれます。オペレーティング・システム・マネージャとともに、このディレクトリとディレクトリ・オブジェクトが、ガイドライン5で説明されているように適切な保護を受けていることを確認してください。データ・ファイル内の問題を解決するとき、データベース・ユーザーはこれらのファイルへのアクセスが必要になる場合があるため、このユーザーがこれらのファイルを読み取る方法をオペレーティング・システム・マネージャとともに決める必要があります。
CREATE ANY DIRECTORY権限とDROP ANY DIRECTORY権限を慎重に付与します。これらの権限を付与されたユーザーおよびDBAロールを付与されたユーザーは、すべてのディレクトリ・オブジェクトへの完全なアクセス権を持ちます。
DROP ANY DIRECTORY権限の監査を検討します。権限の監査の詳細は、システム権限の監査を参照してください。
ディレクトリ・オブジェクトの監査を検討します。詳細は、オブジェクト・アクションの監査を参照してください。
関連項目:
ORACLE_DATAPUMPアクセス・ドライバの詳細は、Oracle Databaseユーティリティを参照してください
Oracleには、データベースのインストールと構成を保護するガイドラインがあります。
安全性を高めるために、Oracle Databaseのデフォルト構成が変更されました。この項の推奨事項には、この新規のデフォルト構成が追加されています。
UNIXシステムの場合は、Oracle Databaseのインストールを開始する前に、Oracle所有者アカウントのumask値が022であることを確認する。
LinuxおよびUNIXシステム上のOracle Databaseを管理する方法の詳細は、『Oracle Database管理者リファレンス for Linux and UNIX-Based Operating Systems』を参照してください。
必要なもののみをインストールする。
オプションと製品: Oracle DatabaseのCDパックには、データベース・サーバーだけでなく、製品およびオプションが含まれています。必要な場合にかぎり、製品およびオプションを追加してインストールします。カスタム・インストール機能を使用して必要のない製品のインストールを防止するか、もしくは通常のインストールを実行してから不要な製品およびオプションを削除してください。使用していない製品およびオプションは、維持する必要はありません。製品およびオプションは、必要に応じて簡単にインストールできます。
サンプル・スキーマ: Oracle Databaseには、例を示すための共通のプラットフォームを提供するサンプル・スキーマが用意されています。このサンプル・スキーマは、データベースを本番環境で使用する場合はインストールしないでください。サンプル・スキーマをテスト・データベースにインストールした場合は、本番に移行する前に、そのサンプル・スキーマのアカウントを削除または再びロックしてください。サンプル・スキーマの詳細は、『Oracle Databaseサンプル・スキーマ』を参照してください。
インストール時に、パスワードの入力を求めるプロンプトが表示された場合は、安全性の高いパスワードを作成する。
パスワードの保護に関するガイドラインのガイドライン1、5および6に従います。
インストール直後に、デフォルトのユーザー・アカウントをロックし、期限切れにする。
ユーザー・アカウントと権限の保護に関するガイドラインのガイドライン2を参照してください。
ネットワーク通信のセキュリティは、クライアント、リスナー、および完全な保護を確保するためのネットワーク・ガイドラインを使用することで改善されます。SSLの使用はこれらのリストにおける必須要素であり、SSLを使用することで認証および通信に関してトップ・レベルのセキュリティが可能になります。
内容は次のとおりです。
クライアントを厳密に認証し、接続に対する暗号化を構成して、厳密認証を使用して、クライアント接続を強化します。
クライアント・コンピュータの認証には問題が多いため、通常は、かわりにユーザー認証が実施されます。このアプローチは、クライアント・システムで、偽造されたIPアドレス、ハッキングされたオペレーティング・システムまたはアプリケーション、および偽造または盗用されたクライアント・システムIDが使用される問題を回避します。
また、次のガイドラインによって、クライアント接続のセキュリティが向上します。
不適切なアクセスまたは変更からネットワークとその通信を保護することは、ネットワーク・セキュリティの最重要点です。
データが移動するすべてのパスを検討し、各パスおよびノードに対する脅威を評価してください。次に、脅威およびセキュリティが侵害された場合の結果を抑制または排除する手順を実行します。また、監視および監査を実施し、脅威レベルの増加または侵入試行を検出します。
ネットワーク接続の管理には、Oracle Net Managerを使用できます。Net Managerの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
次の手続きでネットワーク・セキュリティを改善します。
リスナーの管理にSecure Sockets Layer(SSL)を使用する。
詳細は、Secure Sockets Layer接続のセキュリティを参照してください。
リスナーのパスワードおよびサーバー上のlistener.oraファイルへの書込み権限は、管理者が保持するように規定することで、オンライン管理を回避する。
この行をlistener.oraファイルに追加するか、またはこの行を変更してください。
ADMIN_RESTRICTIONS_LISTENER=ON
RELOADを使用して構成を再ロードします。
次のように、アドレス・リストで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リファレンスを参照してください。
リスナーのパスワードを設定しない。
listener.oraファイルにパスワードが設定されていないことを確認します。ローカルのオペレーティング・システム認証によって、リスナー管理が保護されます。パスワードが設定されていない場合、リモートのリスナー管理は使用禁止になります。このため、リスナーのパスワードの総当り攻撃が防止されます。
リスナーのパスワードは、このリリースでは非推奨となりました。次回のOracle Databaseリリースではサポートされなくなります。
ホスト・コンピュータに、複数のNetwork Interface Controller(NIC)カードに関連付けられている複数のIPアドレスがある場合は、特定のIPアドレスに対してリスナーを構成する。
これによって、リスナーはすべてのIPアドレスをリスニングできます。また、リスナーが特定のIPアドレスをリスニングするように制限できます。このタイプのコンピュータでは、リスナーですべてのIPアドレスをリスニングするのではなく、特定のIPアドレスを指定することをお薦めします。リスナーを特定のIPアドレスに限定することで、侵入者が、リスナー・プロセスからTCPエンド・ポイントを盗むのを防止できます。
リスナーの権限を制限して、データベースまたはOracleサーバーのアドレス空間にあるファイルを読取り/書込みできないようにする。
この制限によって、リスナー(またはエージェントが実行するプロシージャ)によって起動された外部プロシージャ・エージェントは、読取りまたは書込み操作の実行機能を継承しないようになります。この個別のリスナー・プロセスの所有者には、Oracle Databaseをインストールした所有者またはOracle Databaseインスタンスを実行する所有者(デフォルトの所有者であるORACLEなど)を指定しないでください。
リスナーにおける外部プロシージャの構成の詳細は、Oracle Database Net Services管理者ガイドを参照してください。
暗号化を使用して、転送中のデータを保護する。
ネットワーク・データの暗号化の詳細は、Oracle Database 2日でセキュリティ・ガイドおよび厳密認証の概要を参照してください。
ファイアウォールを利用する。
ファイアウォールを適切に配置および構成することで、データベースへの外部からのアクセスを防止できます。
データベース・サーバーはファイアウォールの内側に配置してください。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アドレスのみでフィルタ処理した認証では不十分です。)
Oracleリスナーの不正な管理を防止する。
リスナーの詳細は、Oracle Database Net Services管理者ガイドを参照してください。
ネットワーク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管理者ガイドを参照してください。
ネットワーク・トラフィックを暗号化する。
可能な場合は、Oracleネットワーク・データ暗号化を使用して、クライアント、データベースおよびアプリケーション・サーバー間のネットワーク・トラフィックを暗号化します。ネットワーク暗号化の概要は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。ネットワーク暗号化の詳細は、「Oracle Databaseのネットワーク暗号化およびデータ整合性の構成」を参照してください。
ホスト・オペレーティング・システム(Oracle Databaseがインストールされているシステム)を保護する。
オペレーティング・システムの不要なサービスをすべて使用禁止にして、ホスト・オペレーティング・システムを保護します。UNIXおよびWindowsには様々なオペレーティング・システム・サービスが組み込まれていますが、それらの大部分は、一般的なデプロイメントには不要です。これらのサービスには、FTP、TFTP、TELNETなどがあります。使用を禁止している各サービスのUDPポートとTCPポートは、両方とも必ず閉じてください。一方のポートを使用禁止にしていても、他方のポートが使用可能であると、オペレーティング・システムの安全性が低下します。
Oracleには、Secure Sockets Layer (SSL)を保護するためのガイドラインがあります。
Secure Sockets Layer(SSL)は保護された通信のためのインターネット標準プロトコルで、データの整合性と暗号化のメカニズムを提供します。これらのメカニズムは、証明書(および必要な場合は暗号化)を使用して、安全性の高い認証、認可およびメッセージ機能をサポートし、ユーザーあるいはアプリケーションおよびサーバーが送受信するメッセージを保護できます。適切なセキュリティの実施により、保護が最大限に発揮され、セキュリティを脅かすギャップや露見が最小限に抑えられます。
構成ファイル(クライアントおよびリスナー用など)では、インストール時に構成された正しいポートをSSLに対して使用する。
HTTPSは任意のポートで実行できますが、標準的には、すべてのHTTPS準拠のブラウザがデフォルトで確認できるポート443を指定します。たとえば、次のようにポートをURLに指定することもできます。
https://secure.example.com:4445/
ファイアウォールを使用している場合は、保護された(SSL)通信のために同じポートを使用する必要もあります。
tnsnames.oraファイル(通常はクライアント上またはLDAPディレクトリ内)のADDRESSパラメータに、PROTOCOLとしてTCPSが指定されていることを確認する。
同一の仕様が、(通常は$ORACLE_HOME/network/adminディレクトリ内の)listener.oraファイルに指定されている必要もあります。
各通信の両サイドでSSLモードが一致していることを確認する。たとえば、データベース(一方)とユーザーまたはアプリケーション(もう一方)が同じSSLモードである必要があります。
クライアントまたはサーバー認証(一方向)、クライアントおよびサーバー認証(双方向)、または認証なしのモードを指定できます。
サーバーがクライアントの暗号スイートをサポートしていること、および証明書の鍵のアルゴリズムが使用されていることを確認する。
サーバーとクライアントの両方でDN一致を使用可能にし、接続時にサーバーがクライアントに対してその識別情報を偽造するのを防ぐ。
この設定では、サーバーの識別情報のグローバル・データベース名をサーバー証明書のDNと照合することで、その情報が正しいことが確認されます。
DN一致は、tnsnames.oraファイルで使用可能にできます。次に例を示します。
set:SSL_SERVER_CERT_DN="cn=finance,cn=OracleContext,c=us,o=example"
この設定を使用可能にしない場合、クライアント・アプリケーションはサーバー証明書をチェックできず、サーバーによる識別情報の偽造が可能となります。
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には、監査用のガイドラインがあります。
監査は比較的低コストですが、監査するイベントの数はできるだけ制限してください。
この制限によって、監査対象の文を実行したときのパフォーマンスへの影響が最小限に抑えられ、監査証跡のサイズが最小限になるため、分析と理解が容易になります。
監査方針を企画する際は、次のガイドラインに従ってください。
監査の目的を評価する。
監査の目的を明確にしておくと、適切な監査方針を企画でき、不要な監査を回避できます。
たとえば、不審なデータベース・アクティビティの調査のために監査すると仮定します。この情報のみでは不明確です。どのデータベース・アクティビティが疑わしい、または注意を要するといった具体的な情報が必要です。そのために、たとえば、データベース内の表から無許可にデータが削除されていないかを監査するというように、監査方針を絞り込みます。このような目的を設定すれば、監査の対象となるアクションの種類や、疑わしいアクティビティによって影響を受けるオブジェクトの種類を限定できます。
監査について十分理解する。
目標とする情報の取得に必要な最小限の文、ユーザーまたはオブジェクトを監査します。これによって、不要な監査情報のために重要な情報の識別が困難になることや、SYSTEM表領域内の貴重な領域が無駄に使用されることがなくなります。収集が必要なセキュリティ情報の量と、その情報を格納して処理する能力とのバランスを保つ必要があります。
たとえば、データベース・アクティビティに関する情報を収集するために監査する場合は、追跡するアクティビティの種類を正確に判断した上で、必要な情報を収集するために必要な期間内で、目的のアクティビティのみを監査します。別の例として、各セッションの論理I/O情報のみを収集する場合は、オブジェクトを監査しないでください。
監査方針を実施する前に法務部門と打ち合せる。
組織の法務部門に監査方針を検討するように依頼する必要があります。監査では組織の他のユーザーが監視されるため、サイトのコンプライアンス・ポリシーと会社の方針に適切に従っていることを確認する必要があります。
Oracleには、特定のデータベース・アクティビティに関する履歴情報を収集する必要がある場合のガイドラインがあります。
関連のあるアクションのみを監査する。
少なくとも、ユーザー・アクセス、システム権限の使用およびデータベース・スキーマ構造の変更を監査します。役に立たない監査レコードのために重要な情報が識別できない事態を避け、監査証跡管理の量を削減するために、目的のデータベース・アクティビティのみを監査してください。監査対象が多すぎるとデータベースのパフォーマンスに影響する可能性があることにも注意してください。
たとえば、データベースのすべての表に対する変更を監査すると、監査証跡レコードが多くなりすぎてデータベースのパフォーマンスが低下する可能性があります。ただし、Human Resources(人事管理)表内の給与のように、重要な表に対する変更を監査することは有益です。
ファイングレイン監査を使用することで、特定のアクションを監査できます。ファイングレイン監査については、ファイングレイン監査を使用した特定のアクティビティの監査を参照してください。
監査レコードをアーカイブし、監査証跡を削除する。
必要な情報を収集した後は、目的の監査レコードをアーカイブし、この情報の監査証跡を削除します。次の各項を参照してください。
自社のプライバシに関する考慮事項を検討する。
プライバシに関する法規によって、追加のビジネス・プライバシ・ポリシーが必要となる場合があります。プライバシに関するほとんどの法規では、個人を特定できる情報(PII)へのアクセスをビジネスで監視する必要があり、このような監視は監査によって実施されます。ビジネス・レベルのプライバシ・ポリシーでは、技術的、法的および企業ポリシーの問題など、データ・アクセスおよびユーザー・アカウンタビリティに関するすべての事項を処理する必要があります。
その他の監査情報をOracle Databaseのログ・ファイルでチェックする。
Oracle Databaseによって生成されたログ・ファイルには、データベースの監査時に使用できる有益な情報が含まれています。たとえば、Oracle Databaseではアラート・ファイルが作成され、STARTUP操作、SHUTDOWN操作およびデータベースにデータ・ファイルを追加するなどの構造上の変更が記録されます。
たとえば、コミットまたはロールバックされたトランザクションを監査する場合は、REDOログ・ファイルを使用できます。
Oracleには、不審なデータベース・アクティビティの監視を監査する場合のガイドラインがあります。
最初に一般的な監査を行い、特定の対象を監査する。
疑わしいデータベース・アクティビティの監査を開始するとき、通常は対象のユーザーまたはスキーマ・オブジェクトの特定に使用できる情報がありません。したがって、まず、一般的な監査、つまり、統合監査ポリシーを使用した監査を行います。「監査ポリシーの構成」に、SQL文、スキーマ、オブジェクト、権限などを監査する方法が説明されています。
準備的な監査情報の記録と分析を終了した後は、監査ポリシーを変更して特定のアクションと権限を監査します。ポリシーに条件を追加して、不要な監査レコードを除外できます。AUDIT POLICY文でEXCEPT句を使用して、監査する必要のない特定のユーザーを除外することもできます。統合監査ポリシーの詳細は、統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査を参照してください。
ファイングレイン監査を使用した特定のアクティビティの監査で説明するように、ファイングレイン監査を使用して特定のアクションを監査できます。
この処理は、疑わしいデータベース・アクティビティの原因について結論が出せるだけの十分な裏付けが収集できるまで継続してください。
一般的な疑わしいアクティビティを監査する。
一般的な疑わしいアクティビティは、次のとおりです。
通常以外の時間中にデータベースにアクセスするユーザー
複数回失敗したユーザー・ログイン試行
存在しないユーザーによるログイン試行
また、SQLテキストなど、SQL問合せで使用すると、クレジット・カード番号などの機密データが監査証跡の列に表示される可能性があることに注意してください。また、アカウントを共有しているユーザー、または同じIPアドレスからログインしている複数のユーザーを監視します。この種のアクティビティは、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることで検索できます。非常にきめ細かい方法では、ファイングレイン監査ポリシーを作成します。
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ロールはOracle Databaseリリース7で導入され、これにより、データベース・ロールに新しい堅牢なサポートが追加されました。
内容は次のとおりです。
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ロールがデータベース・アップグレードに与える影響に注意してください。
既存のOracleデータベースをOracle Database 10gリリース2 (10.2)にアップグレードすると、CONNECTロールの権限はCREATE SESSION権限のみになるよう自動的に変更されます。
ほとんどのアプリケーションは、アプリケーション・オブジェクトがすでに存在するため、この影響を受けません。新たに表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成する必要はありません。
表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSIONコマンドを動的に使用するアプリケーションは、権限が不十分なために失敗する場合があります。
CONNECTロールがアカウント・プロビジョニングに与える影響に注意してください。
アプリケーションまたはDBAがアカウント・プロビジョニング・プロセスの一部としてCONNECTロールを付与する場合は、CREATE SESSION権限のみが含まれます。追加の権限は、直接または別のロールを介して付与する必要があります。
この問題は、カスタマイズされた新しいデータベース・ロールを作成することで対処できます。
関連項目:
CONNECTロールが新規のデータベースを使用するアプリケーションに与える影響に注意してください。
Oracle Database 10g リリース2(10.2)のユーティリティ(DBCA)、またはDBCAから生成されたデータベース作成テンプレートを使用して作成された新しいデータベースでは、CREATE SESSION権限のみを伴ったCONNECTロールが定義されます。
新しいデータベースを使用するアプリケーションのインストールは、そのアプリケーションに使用されているデータベース・スキーマの権限がCONNECTロールのみを介して付与されている場合、失敗する可能性があります。
CONNECTロールへの変更による影響は、一般ユーザー、アプリケーション開発者およびクライアント/サーバー・アプリケーションの3つのクラスのユーザーではそれぞれ異なります。
内容は次のとおりです。
CONNECTロールが一般ユーザーに与える影響に注意してください。
新しいCONNECTロールは、CREATE SESSION権限のみを提供します。アプリケーションを使用するためにデータベースに接続するユーザーの場合、CONNECTロールにはまだCREATE SESSION権限があるため影響はありません。
ただし、CONNECTロールのみでプロビジョニングされた特定のユーザーの場合は、適切な権限がないことになります。表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSIONコマンドを使用するユーザーです。これらのユーザーに必要な権限は、CONNECT ロールでは提供されなくなりました。必要な追加権限を認可するには、データベース管理者が該当する権限用の追加ロールを作成および適用するか、その権限を必要としているユーザーに直接付与する必要があります。
ALTER SESSION権限は、イベントを設定するために必要です。ALTER SESSION権限が必要なデータベース・ユーザーはほとんどいません。
ALTER SESSION権限は、その他のALTER SESSIONコマンドには必要ありません。
CONNECTロールがアプリケーション開発者に与える影響に注意してください。
CONNECTロールのみでプロビジョニングされたアプリケーション開発者には、表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSION文を使用するための適切な権限はありません。
該当する権限用の追加ロールを作成および適用するか、その権限を必要としているアプリケーション開発者に直接付与する必要があります。
CONNECTロールの変更の影響に対処するには、次の3つの方法をお薦めします。
内容は次のとおりです。
CONNECTロールから削除された権限は、新しいデータベース・ロールを作成することで管理できます。
関連項目:
権限分析の詳細は、『Oracle Database Vault管理者ガイド』を参照してください。
Oracle Database 10gリリース2 (10.2)以降のOracleには、CONNECT権限をリストアするrstrconn.sqlと呼ばれるスクリプトが用意されています。
データベースのアップグレードまたは新しいデータベースの作成後は、このスクリプトを使用して、Oracle Database 10g リリース2(10.2)でCONNECTロールから削除された権限を付与できます。この方法を使用した場合、使用されていない権限は、必要としていないユーザーから取り消してください。
CONNECT権限をリストアする手順
DBA_CONNECT_ROLE_GRANTEESデータ・ディクショナリ・ビューを使用すると、古いCONNECTロールを継続して使用する管理者は、どのユーザーがそのロールを持っているかをすばやく確認できます。
表A-1に、DBA_CONNECT_ROLE_GRANTEESビューの列を示します。
表A-1 DBA_CONNECT_ROLE_GRANTEESの列と内容
| 列名 | 内容 |
|---|---|
Grantee |
|
Path_of_connect_role_grant |
ユーザーへの |
Admin_opt |
|
Oracleパートナおよびアプリケーション・プロバイダは、より安全性の高い製品をOracleの顧客ベースに供給できるように最低限の権限の分析を行う必要があります。「最低限の権限」原則は、所定の機能を実行するために必要な最低限のセットに権限を制限することでリスクを軽減します。
分析によって同一の権限セットが必要とされたユーザーのクラスごとに、その権限のみを持ったロールを作成します。他の権限はすべて該当するユーザーから取り消し、作成したロールを割り当てます。必要な権限が変化したときは、追加の権限を直接またはこれらの新しいロールを介して付与するか、新たに必要となった権限に応じた新しいロールを作成できます。この方法を使用すると、不適切な権限が制限され、不注意または意図的な被害が軽減されます。
データベース・ユーザーによる権限の使用状況を分析するポリシーを作成できます。ポリシーはこの情報を取得し、データ・ディクショナリ・ビューで使用できるようにします。これらのレポートに基づいて、だれにデータへのアクセス権限を持たせるかを決定できます。
関連項目:
権限分析の詳細は、『Oracle Database Vault管理者ガイド』を参照してください。
