| Oracle® Databaseセキュリティ・ガイド 11gリリース2 (11.2) B56285-13 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
この章では、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を稼働しているオペレーティング・システムとOracle Database自体、およびインストール済のOracle Databaseのオプションとコンポーネントすべてについて、関連するセキュリティ・パッチはすべて適用してください。
次のOracle Technology Networkのセキュリティ・サイトを定期的にチェックし、オラクル社からリリースされるセキュリティ・アラートの詳細を確認してください。
また、Oracleワールドワイド・サポート・サービスのサイト、My Oracle Supportもチェックして、セキュリティに関するパッチの入手可能性や予定などを確認してください。
OracleユーザーまたはOracleパートナであるユーザーがOracle製品の潜在的なセキュリティ上の脆弱性を発見した場合は、My Oracle Supportを使用してサービス・リクエストを発行してください。もしくは、製品のバージョンやプラットフォームも含めた問題の詳細を、スクリプトと例を添えて、電子メールでsecalert_us@oracle.comに送信してください。オラクル社にお問合せの際は、弊社の暗号鍵を使用して、電子メールを暗号化することをお薦めします。
ユーザー・アカウントと権限を保護するには、次のガイドラインに従います。
次のガイドラインに従うことをお薦めします。
必要な権限のみを付与する。
データベース・ユーザーまたはロールに、必要以上の権限を付与しないでください。(可能な場合、ユーザーではなくロールに権限を付与してください。)つまり、最小権限の原則とは、ユーザーに、効率的かつ簡潔に作業を行うために実際に必要な権限のみを与えることです。
CREATE ANY EDITIONおよびDROP ANY EDITION権限の付与を制限する。
オブジェクトの追加バージョンを維持するために、エディションではデータベース内のリソースおよびディスク領域の使用量を増やすことができます。CREATE ANY EDITIONおよびDROP ANY EDITION権限は、アップグレードの実行を担当する信頼できるユーザーにのみ付与します。
CREATE ANY JOB、BECOME USER、EXP_FULL_DATABASEおよびIMP_FULL_DATABASE権限を制限する。
これらは強力なセキュリティ関連権限です。これらの権限は、必要とするユーザーにのみ付与してください。
ライブラリ関連の権限を信頼できるユーザーのみに制限する。
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に設定することで保護できます。詳細は、「データの保護に関するガイドライン」の下にあるガイドライン1を参照してください。
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(ファイングレイン監査が使用可能な場合)
次の権限が、それらを必要としているユーザーとロールのみに付与されていることを監視する。
デフォルトでは、次の権限が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キーワード付きの権限
次のビューまたはロールからアクセス権を取り消す。
SYSとDBAアカウント以外のすべてのユーザーからSYS.USER_HISTORY$表を取り消します。
通常のアプリケーション・アカウントからRESOURCEロールを取り消します。
通常のアプリケーション・アカウントからCONNECTロールを取り消します。
DBAロールが不要なユーザーから、このロールを取り消します。
ロールに対してのみ権限を付与する。
個々のユーザーではなくロールに権限を付与すると、権限の管理および追跡が容易になります。
プロキシ・アカウント(プロキシ認可の場合)の権限をCREATE SESSIONのみに制限する。
セキュア・アプリケーション・ロールを使用して、アプリケーション・コードによって有効化するロールを保護する。
セキュア・アプリケーション・ロールでは、ユーザーがアプリケーションにログインできるかどうかを判断する一連の条件を、PL/SQLパッケージ内で定義できます。ユーザーはセキュア・アプリケーション・ロールではパスワードを使用する必要がありません。
ロールがアプリケーション内で使用可能または使用禁止になるのを防ぐ別の方法は、ロールのパスワードを使用することです。この方法では、ユーザーが、データベースにSQL(アプリケーションではなく)で直接アクセスして、ロールに関連付けられている権限を使用することを防ぎます。ただし、別の一連のパスワードを管理する必要がないように、セキュア・アプリケーション・ロールの使用をお薦めします。
ユーザーが、SQL文でNOLOGGING句を使用できないようにする。
いくつかのSQL文で、ユーザーはオプションとしてNOLOGGING句を指定できます。このオプションを指定すると、データベース操作がオンラインREDOログ・ファイルに記録されません。ユーザーがこの句を指定しても、REDOレコードがオンラインREDOログ・ファイルに書き込まれます。しかし、このレコードに関連付けられたデータはありません。このため、NOLOGGINGを使用すると、不正コードが入力されて、監査証跡に記録されずに実行される可能性があります。
ロールは、そのロールの権限すべてを必要とするユーザーにのみ付与する。
ロール(権限のグループ)は、ユーザーに許可を素早く簡単に付与する場合に便利です。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エンタープライズ・ユーザー・セキュリティ管理者ガイド』
ユーザー・アカウントを作成すると、そのユーザーに対してデフォルトのパスワード・ポリシーが割り当てられます。このパスワード・ポリシーには、パスワードの作成方法(最小文字数や期限切れの時期など)についてのルールが定義されています。パスワードは、パスワード・ポリシーを使用することで強化できます。パスワードを保護するための別の方法については、「パスワード保護の構成」も参照してください。
パスワードをさらに強化するには、次のガイドラインに従います。
パスワードを慎重に選択する。
パスワードの最低要件については、「パスワードの最低要件」を参照してください。パスワードを作成または変更する際には、次の追加のガイドラインに従います。
パスワードには、数値、大文字および小文字を少なくとも1文字ずつ含めます。
パスワードには、大/小文字と特殊文字を混在させて使用します。(詳細は、「パスワードのセキュリティへの脅威からのSHA-1ハッシュ・アルゴリズムによる保護」を参照してください。)
パスワードには、マルチバイト・キャラクタを含めることができます。
パスワードの文字にはデータベース・キャラクタ・セットを使用します。このセットには、アンダースコア(_)、ドル記号($)および番号記号(#)の各文字があります。
次のパスワードは二重引用符で囲む必要があります。
マルチバイト・キャラクタを含むパスワード。
数値または特殊文字で始まり、アルファベットを含むパスワード。例:
"123abc"
"#abc"
"123dc$"
アルファベット、数値および特殊文字以外の文字を含むパスワード。例:
"abc>"
"abc@"
" "
次のパスワードは二重引用符で囲む必要はありません。
アルファベット(aからz、AからZ)で始まり、数字(0から9)または特殊文字($、#、_)を含むパスワード。次に例を示します。
abc123
ab23a
ab$#_
数値のみを含むパスワード。
アルファベットのみを含むパスワード。
意味のある単語のみで構成されるパスワードを使用しないでください。
より長く複雑で覚えやすいパスワードを作成するには、次のテクニックを使用します。
覚えやすいセンテンスの各語の1文字目からパスワードを作成します。たとえば、"I usually work until 6 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 11gリリース2 (11.2)では、デフォルトのアカウントはロックされ、パスワードは期限切れの状態でインストールされますが、以前のリリースからのアップグレードの場合は、デフォルトのパスワードを使用しているアカウントが存在している場合があります。
デフォルトのパスワードが設定されているユーザー・アカウントを検索するには、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 Advanced Security(Oracle Database Enterprise Editionのオプション)を、ネットワーク認証サービス(Kerberosなど)、トークン・カード、スマート・カードまたはX.509証明書と一緒に使用することもお薦めします。これらのサービスを使用すると、ユーザーの厳密な認証が可能になるため、Oracle Databaseを不正なアクセスから保護できます。
Oracle表にはユーザー・パスワードをクリアテキストで格納しない。
セキュリティを強化するために、Oracle表には、ユーザー・パスワードをクリアテキスト(判読可能なテキスト)で格納しないでください。この問題は、安全性の高い外部パスワード・ストアを使用してパスワードが記載されている表の列を暗号化することで解決できます。詳細は、「パスワード資格証明用の安全性の高い外部パスワード・ストアの管理」を参照してください。
ユーザー・アカウントのパスワードを作成または変更すると、Oracle Databaseでは、そのパスワードの暗号化ハッシュまたはダイジェストが自動的に作成されます。DBA_USERSビューを問い合せてユーザー・アカウントの情報を検索する場合、PASSWORD列のデータはユーザー・パスワードがグローバル、外部またはNULLのいずれかであるかを示します。
システムのデータを保護するには、次のガイドラインに従います。
ANYシステム権限を持つユーザーがデータ・ディクショナリに対してそれぞれの権限を使用しないように、データ・ディクショナリを保護することをお薦めします。データ・ディクショナリ表のデータを変更または操作すると、データベースの操作に永続的に有害な影響を与える可能性があります。
データ・ディクショナリ保護を有効にするには、initsid.ora制御ファイルで、次の初期化パラメータをFALSE(デフォルト)に設定します。
O7_DICTIONARY_ACCESSIBILITY = FALSE
O7_DICTIONARY_ACCESSIBILITYパラメータは、サーバー・パラメータ・ファイルに設定できます。サーバー・パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。
O7_DICTIONARY_ACCESSIBILTYをFALSEに設定した後は、SELECT ANY DICTIONARY権限を持つユーザーと、DBA権限での接続(たとえば、CONNECT / AS SYSDBA)を許可されたユーザーのみがデータ・ディクショナリに対してANYシステム権限を使用できます。O7_DICTIONARY_ACCESSIBILITYパラメータがFALSEに設定されていない場合は、たとえば、DROP ANY TABLEシステム権限を持つユーザーであればだれでも、データ・ディクショナリの一部を削除できます。ただし、データ・ディクショナリへの参照アクセスが必要なユーザーには、SELECT ANY DICTIONARYシステム権限を付与できます。
|
注意:
|
オペレーティング・システムのアクセスを制限する。
次のガイドラインに従ってください。
Oracle Databaseが稼働しているホスト・コンピュータ上のオペレーティング・システム・アカウントの権限(管理、ルート権限またはDBA)を、ユーザーによる業務の遂行に必要な最小限の権限に制限してください。
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管理者ガイド』を参照してください。Linuxシステムでの複数のソフトウェア所有者に必要な様々な権限の詳細は、『Oracle Automatic Storage Management管理者ガイド』も参照してください。
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のデフォルト構成に変更が加わりました。この項の推奨事項には、この新規のデフォルト構成が追加されています。
データベースのインストールと構成を保護するには、次のガイドラインに従います。
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で許可されるオペレーティング・システム認証ログインは、保護された接続のみを介したログインであるため、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)では非推奨となっており、下位互換性のためにのみ保持されている点に注意してください。
暗号化を使用するように接続を構成する。
Oracleネットワークの暗号化を使用すると、傍受が困難となります。暗号化の構成方法の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
強力な認証を設定する。
Kerberosおよび公開鍵インフラストラクチャ(PKI)の使用方法の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
不適切なアクセスまたは変更からネットワークとその通信を保護することは、ネットワーク・セキュリティの最重要点です。データが移動するすべてのパスを検討し、各パスおよびノードに対する脅威を評価してください。次に、脅威およびセキュリティが侵害された場合の結果を抑制または排除する手順を実行します。また、監視および監査を実施し、脅威レベルの増加または侵入試行を検出します。
ネットワーク接続の管理には、Oracle Net Managerを使用できます。Oracle Net Managerの使用方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。『Oracle Database Net Services管理者ガイド』も参照してください。
次の手続きでネットワーク・セキュリティを改善します。
リスナーの管理にSecure Sockets Layer(SSL)を使用する。
詳細は、「Secure Sockets Layer接続の保護」を参照してください。
リスナーのアクティビティを監視する。
リスナーのアクティビティは、Enterprise Manager Database Controlを使用して監視できます。Database Controlホームページの「一般」の下で、使用しているリスナーのリンクをクリックします。「リスナー」ページが表示されます。このページには、生成された警告のカテゴリ、警告メッセージ、警告がトリガーされた時期などの詳細が表示されます。このページには、リスナーのパフォーマンス統計などの他の情報も表示されます。
リスナーのパスワードおよびサーバー上の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 Advanced Security管理者ガイド』を参照してください。
ファイアウォールを利用する。
ファイアウォールを適切に配置および構成することで、データベースへの外部からのアクセスを防止できます。
データベース・サーバーはファイアウォールの内側に配置してください。Oracle Databaseのネットワーク・インフラストラクチャであるOracle Net(旧称Net8およびSQL*Net)は、様々なベンダーの各種ファイアウォールに対するサポートを提供しています。プロキシ対応のファイアウォールでは、Network Associates社のGauntletとAxent社のRaptorをサポートしています。パケット・フィルタ型のファイアウォールではCisco社のPIX Firewall、ステートフル・インスペクション型のファイアウォール(より高機能のパケット・フィルタ型ファイアウォール)ではCheckPoint社のFirewall-1をサポートしています。
ファイアウォールは、保護するネットワークの外側に配置されている必要があります。
安全性が確認されているプロトコル、アプリケーションまたはクライアント/サーバーのソースのみを受け入れるようにファイアウォールを構成します。
Oracle Connection Managerなどの製品を使用して、データベースへの単一のネットワーク接続を介した複数のクライアント・ネットワーク・セッションの多重化を管理します。これにより送信元、送信先およびホスト名でフィルタ処理できます。この製品を使用すると、物理的に保護された端末または既知のIPアドレスを備えたアプリケーションWebサーバーからの接続のみを受け入れるようにできます 。(IPアドレスは偽造可能なため、IPアドレスのみでフィルタ処理した認証では不十分です。)
リスナーの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
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 Advanced Securityを使用して、クライアント、データベースおよびアプリケーション・サーバー間のネットワーク通信を暗号化します。ネットワーク暗号化の概要は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。ネットワーク暗号化の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
ホスト・オペレーティング・システム(Oracle Databaseがインストールされているシステム)を保護する。
オペレーティング・システムの不要なサービスをすべて使用禁止にして、ホスト・オペレーティング・システムを保護します。UNIXおよびWindowsには様々なオペレーティング・システム・サービスが組み込まれていますが、それらの大部分は、一般的なデプロイメントには不要です。これらのサービスには、FTP、TFTP、TELNETなどがあります。使用を禁止している各サービスのUDPポートとTCPポートは、両方とも必ず閉じてください。一方のポートを使用禁止にしていても、他方のポートが使用可能であると、オペレーティング・システムの安全性が低下します。
Secure Sockets Layer (SSL)は保護された通信のためのインターネット標準プロトコルで、データの整合性と暗号化のメカニズムを提供します。これらのメカニズムは、証明書(および必要な場合は暗号化)を使用して、安全性の高い認証、認可およびメッセージ機能をサポートし、ユーザーあるいはアプリケーションおよびサーバーが送受信するメッセージを保護できます。適切なセキュリティの実施により、保護が最大限に発揮され、セキュリティを脅かすギャップや露見が最小限に抑えられます。次の各ガイドラインでは、SSLを正しく使用する方法についての注意を詳細に説明します。Oracle SSL構成の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
構成ファイル(クライアントおよびリスナー用など)では、インストール時に構成された正しいポートをSSLに対して使用する。
HTTPSは任意のポートで実行できますが、標準的には、すべてのHTTPS準拠のブラウザがデフォルトで確認できるポート443を指定します。たとえば、次のようにポートをURLに指定することもできます。
https://secure.example.com:4445/
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として起動し、別のユーザーとしてログインします。そうしないと、この鍵を取得しただれもがネット上でルート・ユーザーになりすましたり、サーバーに送信されたデータを復号化する可能性があります。
|
関連項目:
|
SQLテキストを収集すると、クレジット・カード番号などの機密データがファイングレイン監査証跡に表示されることに注意してください。標準監査の場合は、AUDIT_TRAIL初期化パラメータをDB, EXTENDEDまたはXML, EXTENDEDに設定すると、SQLテキストの収集が有効になります。ファイングレイン監査の場合は、DBMS_FGA PL/SQLパッケージのaudit_trailパラメータをDBMS_FGA.DB + DBMS_FGA.EXTENDEDまたはDBMS_FGA.XML + DBMS_FGA.EXTENDEDに設定します。
監査の対象に機密データが含まれている場合は、次のソリューションのいずれかを使用することを検討してください。
監査証跡をSYSTEM表領域からSYSAUXまたは別の表領域に移動します。「データベース監査証跡の別の表領域への移動」を参照してください。その後、この表領域を暗号化します。表領域の暗号化の詳細は『Oracle Database Advanced Security管理者ガイド』を参照してください。
監査証跡でのSQLテキストの収集は有効にしないようにします。かわりに、次の設定を使用します。
標準監査の場合: AUDIT_TRAIL初期化パラメータをDB、OSまたはXMLに設定します。「AUDIT_TRAIL初期化パラメータを使用した標準監査の構成」を参照してください。
ファイングレイン監査の場合: DBMS_FGA.ADD_POLICY audit_trailパラメータをDBMS_FGA.DBまたはDBMS_FGA.XMLを設定します。「ファイングレイン監査ポリシーの作成」を参照してください。
監査は比較的低コストですが、監査するイベントの数はできるだけ制限してください。この制限によって、監査対象の文を実行したときのパフォーマンスへの影響が最小限に抑えられ、監査証跡のサイズが最小限になるため、分析と理解が容易になります。
監査方針を企画する際は、次のガイドラインに従ってください。
監査の目的を評価する。
監査の目的を明確にしておくと、適切な監査方針を企画でき、不要な監査を回避できます。
たとえば、不審なデータベース・アクティビティの調査のために監査すると仮定します。この情報のみでは不明確です。どのデータベース・アクティビティが疑わしい、または注意を要するといった具体的な情報が必要です。そのために、たとえば、データベース内の表から無許可にデータが削除されていないかを監査するというように、監査方針を絞り込みます。このような目的を設定すれば、監査の対象となるアクションの種類や、疑わしいアクティビティによって影響を受けるオブジェクトの種類を限定できます。
監査について十分理解する。
目標とする情報の取得に必要な最小限の文、ユーザーまたはオブジェクトを監査します。これによって、不要な監査情報のために重要な情報の識別が困難になることや、SYSTEM表領域内の貴重な領域が無駄に使用されることがなくなります。収集が必要なセキュリティ情報の量と、その情報を格納して処理する能力とのバランスを保つ必要があります。
たとえば、データベース・アクティビティに関する情報を収集するために監査する場合は、追跡するアクティビティの種類を正確に判断した上で、必要な情報を収集するために必要な期間内で、目的のアクティビティのみを監査します。別の例として、各セッションの論理I/O情報のみを収集する場合は、オブジェクトを監査しないでください。
監査方針を実施する前に法務部門と打ち合せる。
組織の法務部門に監査方針を検討するように依頼する必要があります。監査では組織の他のユーザーが監視されるため、サイトのコンプライアンス・ポリシーと会社の方針に適切に従っていることを確認する必要があります。
監査目的が特定のデータベース・アクティビティに関する履歴情報を収集することにある場合は、次のガイドラインに従ってください。
関連のあるアクションのみを監査する。
少なくとも、ユーザー・アクセス、システム権限の使用およびデータベース・スキーマ構造の変更を監査します。役に立たない監査レコードのために重要な情報が識別できない事態を避け、監査証跡管理の量を削減するために、目的のデータベース・アクティビティのみを監査してください。監査対象が多すぎるとデータベースのパフォーマンスに影響する可能性があることにも注意してください。
たとえば、データベースのすべての表に対する変更を監査すると、監査証跡レコードが多くなりすぎてデータベースのパフォーマンスが低下する可能性があります。ただし、Human Resources(人事管理)表内の給与のように、重要な表に対する変更を監査することは有益です。
ファイングレイン監査を使用することで、特定のアクションを監査できます。ファイングレイン監査については、「ファイングレイン監査を使用した特定のアクティビティの監査」を参照してください。
監査レコードをアーカイブし、監査証跡を削除する。
必要な情報を収集した後は、目的の監査レコードをアーカイブし、この情報の監査証跡を削除します。次の各項を参照してください。
自社のプライバシに関する考慮事項を検討する。
プライバシに関する法規によって、追加のビジネス・プライバシ・ポリシーが必要となる場合があります。プライバシに関するほとんどの法規では、個人を特定できる情報(PII)へのアクセスをビジネスで監視する必要があり、このような監視は監査によって実施されます。ビジネス・レベルのプライバシ・ポリシーでは、技術的、法的および企業ポリシーの問題など、データ・アクセスおよびユーザー・アカウンタビリティに関するすべての事項を処理する必要があります。
その他の監査情報をOracle Databaseのログ・ファイルでチェックする。
Oracle Databaseによって生成されたログ・ファイルには、データベースの監査時に使用できる有益な情報が含まれています。たとえば、Oracle Databaseではアラート・ファイルが作成され、STARTUP操作、SHUTDOWN操作およびデータベースにデータ・ファイルを追加するなどの構造上の変更が記録されます。
監査の目的が疑わしいデータベース・アクティビティを監視することにある場合は、次のガイドラインに従ってください。
最初に一般的な監査を行い、特定の対象を監査する。
疑わしいデータベース・アクティビティの監査を開始するとき、通常は対象のユーザーまたはスキーマ・オブジェクトの特定に使用できる情報がありません。そのため、監査オプションを最初はより一般的に、つまり第9章「監査を使用したセキュリティ・アクセスの検証」で説明している標準監査オプションを使用して設定してください。この章では、標準監査オプションを使用してSQL文、スキーマ・オブジェクト、権限などを監査する方法を説明しています。
準備的な監査情報の記録と分析を終了した後は、一般的な監査を使用禁止にして特定のアクションを監査します。「ファイングレイン監査を使用した特定のアクティビティの監査」で説明するように、ファイングレイン監査を使用して特定のアクションを監査できます。この処理は、疑わしいデータベース・アクティビティの原因について結論が出せるだけの十分な裏付けが収集できるまで継続してください。
一般的な疑わしいアクティビティを監査する。
一般的な疑わしいアクティビティは、次のとおりです。
通常以外の時間中にデータベースにアクセスするユーザー
複数回失敗したユーザー・ログイン試行
存在しないユーザーによるログイン試行
さらに、アカウントを共有しているユーザー、または同じIPアドレスからログインしている複数のユーザーを監視します。この種のアクティビティは、DBA_AUDIT_SESSIONデータ・ディクショナリ・ビューを問い合せることで検索できます。非常にきめ細かい方法では、ファイングレイン監査ポリシーを作成します。
監査証跡を保護する。
疑わしいデータベース・アクティビティを監査する場合は、監査と無関係に監査情報が追加、変更または削除されないように、監査証跡を保護します。標準の監査証跡を監査するには、AUDIT SQL文を使用します。
例:
AUDIT SELECT ON SYS.AUD$ BY ACCESS;
「データベース監査証跡の監査」も参照してください。
ファイングレイン監査証跡を監査するには、ユーザーSYSで、次の文を入力します。
AUDIT SELECT ON SYS.FGA$ BY ACCESS;
Oracle Database Vaultを有効にしていると、SYS.AUDIT$表、SYSTEM.AUD$表、SYS.FGA$表、およびSYS.FGA_LOG$表を、レルムに囲むことによりさらに保護できます。(Oracle Database Vault環境では、Oracle Label Securityが使用可能になっている場合、AUD$表はSYSTEMスキーマに移動されます。SYS.AUD$がSYSTEM.AUD$表のシノニムになります。)詳細は、『Oracle Database Vault管理者ガイド』を参照してください。
データベース・スキーマまたは構造の変更。次のAUDIT文の設定を使用します。
AUDIT ALTER ANY PROCEDURE BY ACCESS;
AUDIT ALTER ANY TABLE BY ACCESS;
AUDIT ALTER DATABASE BY ACCESS;
AUDIT ALTER SYSTEM BY ACCESS;
AUDIT CREATE ANY EDITION;
AUDIT CREATE ANY JOB BY ACCESS;
AUDIT CREATE ANY LIBRARY BY ACCESS;
AUDIT CREATE ANY PROCEDURE BY ACCESS;
AUDIT CREATE ANY TABLE BY ACCESS;
AUDIT CREATE EXTERNAL JOB BY ACCESS;
AUDIT DROP ANY EDITION;
AUDIT DROP ANY PROCEDURE BY ACCESS;
AUDIT DROP ANY TABLE BY ACCESS;
データベースへのアクセスと権限。次のAUDIT文の設定を使用します。
AUDIT ALTER PROFILE BY ACCESS;
AUDIT ALTER USER BY ACCESS;
AUDIT AUDIT SYSTEM BY ACCESS;
AUDIT CREATE PUBLIC DATABASE LINK BY ACCESS;
AUDIT CREATE SESSION BY ACCESS;
AUDIT CREATE USER BY ACCESS;
AUDIT DROP PROFILE BY ACCESS;
AUDIT DROP USER BY ACCESS;
AUDIT EXEMPT ACCESS POLICY BY ACCESS;
AUDIT GRANT ANY OBJECT PRIVILEGE BY ACCESS;
AUDIT GRANT ANY PRIVILEGE BY ACCESS;
AUDIT GRANT ANY ROLE BY ACCESS;
AUDIT ROLE BY ACCESS;
CONNECTロールはOracle Databaseリリース7で導入され、これにより、データベース・ロールに新しい堅牢なサポートが追加されました。CONNECTロールは、サンプル・コード、アプリケーション、ドキュメントおよび技術論文に使用されています。Oracle Database 10gリリース2 (10.2)では、CONNECTロールは変更されました。Oracle Database 10.2より前のリリースから現行のリリースにアップグレードする場合は、この項を参照してください。
この項の内容は、次のとおりです。
CONNECTロールは、当初、次の権限を伴って設定されていました。
| 権限A-C | 権限C |
|---|---|
ALTER SESSION |
CREATE SESSION |
CREATE CLUSTER |
CREATE SYNONYM |
CREATE DATABASE LINK |
CREATE TABLE |
CREATE SEQUENCE |
CREATE VIEW |
Oracle Database 10g リリース2以降のCONNECTロールには、CREATE SESSION権限のみが含まれ、他の権限はすべて削除されています。
CONNECTロールは、Oracle Databaseでの新規アカウントのプロビジョニングで頻繁に使用されましたが、データベースへの接続に前述の権限がすべて必要なわけではありません。この変更によって、優れたセキュリティ手続きを簡単に規定できるようになります。
各ユーザーにはそれぞれのタスクに必要な権限のみを付与します。これが「最低限の権限」原則と呼ばれる考え方です。最低限の権限により権限を制限することでリスクが軽減されるため、必要なことはこれまでどおり簡単に実行できると同時に、不適切な行為を不注意に、あるいは意図的に実行される可能性が低くなります。
CONNECTロールへの変更は、データベース・アップグレード、アカウント・プロビジョニングおよび新しいデータベースを使用したアプリケーションのインストールに影響を与えています。
既存のOracleデータベースをOracle Database 10gリリース2 (10.2)にアップグレードすると、CONNECTロールの権限はCREATE SESSION権限のみになるよう自動的に変更されます。ほとんどのアプリケーションは、アプリケーション・オブジェクトがすでに存在するため、この影響を受けません。新たに表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成する必要はありません。
表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSIONコマンドを動的に使用するアプリケーションは、権限が不十分なために失敗する場合があります。
アプリケーションまたはDBAがアカウント・プロビジョニング・プロセスの一部としてCONNECTロールを付与する場合は、CREATE SESSION権限のみが含まれます。追加の権限は、直接または別のロールを介して付与する必要があります。
この問題は、カスタマイズされた新しいデータベース・ロールを作成することで対処できます。
CONNECTロールへの変更による影響は、一般ユーザー、アプリケーション開発者およびクライアント/サーバー・アプリケーションの3つのクラスのユーザーではそれぞれ異なります。
新しいCONNECTロールは、CREATE SESSION権限のみを提供します。アプリケーションを使用するためにデータベースに接続するユーザーの場合、CONNECTロールにはまだCREATE SESSION権限があるため影響はありません。
ただし、CONNECTロールのみでプロビジョニングされた特定のユーザーの場合は、適切な権限がないことになります。表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSIONコマンドを使用するユーザーです。これらのユーザーに必要な権限は、CONNECT ロールでは提供されなくなりました。必要な追加権限を認可するには、データベース管理者が該当する権限用の追加ロールを作成および適用するか、その権限を必要としているユーザーに直接付与する必要があります。
ALTER SESSION権限は、イベントを設定するために必要です。ALTER SESSION権限が必要なデータベース・ユーザーはほとんどいません。
ALTER SESSION SET EVENTS ........
ALTER SESSION権限は、他のALTER SESSIONコマンドには必要ありません。
ALTER SESSION SET NLS_TERRITORY = FRANCE;
CONNECTロールのみでプロビジョニングされたアプリケーション開発者には、表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSION文を使用するための適切な権限はありません。データベース管理者が、該当する権限用の追加ロールを作成および適用するか、その権限を必要としているアプリケーション開発者に直接付与する必要があります。
この変更の影響に対処するために次の3つの方法をお薦めします。
CONNECTロールから削除された権限は、新しいデータベース・ロールを作成することで管理できます。
まず、アップグレードされたOracleデータベースに接続して新しいデータベース・ロールを作成します。次の例では、my_app_developerというロールを使用しています。
CREATE ROLE my_app_developer; GRANT CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE SYNONYM, CREATE CLUSTER, CREATE DATABASE LINK, ALTER SESSION TO my_app_developer;
次に、CONNECTロールを持っているユーザーまたはデータベース・ロールを判別し、そのユーザーまたはロールに新しいロールを付与します。
SELECT USER$.NAME, ADMIN_OPTION, DEFAULT_ROLE FROM USER$, SYSAUTH$, DBA_ROLE_PRIVS WHERE PRIVILEGE# = (SELECT USER# FROM USER$ WHERE NAME = 'CONNECT') AND USER$.USER# = GRANTEE# AND GRANTEE = USER$.NAME AND GRANTED_ROLE = 'CONNECT'; NAME ADMIN_OPTI DEF ------------------------------ ---------- --- R1 YES YES R2 NO YES GRANT my_app_developer TO R1 WITH ADMIN OPTION; GRANT my_app_developer TO R2;
ユーザーが必要としている権限は、Oracle Auditingを使用することで判別できます。この監査情報を分析して、よりきめ細かい追加のデータベース・ロール作成に使用できます。
特定のユーザーについて使用されていない権限は取り消すことができます。監査の前に、データベース初期化パラメータAUDIT_TRAILを初期化してデータベースを再起動する必要があることに注意してください。
AUDIT CREATE TABLE, CREATE SEQUENCE, CREATE SYNONYM, CREATE DATABASE LINK, CREATE CLUSTER, CREATE VIEW, ALTER SESSION;
これでデータベース権限の使用状況を定期的に監視できます。
SELECT USERID, NAME FROM AUD$, SYSTEM_PRIVILEGE_MAP WHERE - PRIV$USED = PRIVILEGE; USERID NAME ------------------------------ ---------------- ACME CREATE TABLE ACME CREATE SEQUENCE ACME CREATE TABLE ACME ALTER SESSION APPS CREATE TABLE APPS CREATE TABLE APPS CREATE TABLE APPS CREATE TABLE 8 rows selected.
Oracle Database 10g リリース2(10.2)以降、オラクル社では$ORACLE_HOME/rdbms/adminディレクトリにrstrconn.sqlというスクリプトを提供してきました。データベースのアップグレードまたは新しいデータベースの作成後は、このスクリプトを使用して、Oracle Database 10g リリース2(10.2)でCONNECTロールから削除された権限を付与できます。
この方法を使用した場合、使用されていない権限は必要としていないユーザーから取り消してください。そのような権限およびユーザーを識別するには、データベース初期化パラメータAUDIT_TRAILを、たとえばAUDIT_TRAIL=DBと初期化してデータベースを再起動する必要があります。その後、使用されている権限を監視するには、次のようにOracle Databaseの監査をオンにしてください。
AUDIT CREATE TABLE, CREATE SEQUENCE, CREATE SYNONYM, CREATE DATABASE LINK, CREATE CLUSTER, CREATE VIEW, ALTER SESSION;
データベース権限の使用状況も定期的に監視できます。
SELECT USERID, NAME FROM AUD$, SYSTEM_PRIVILEGE_MAP WHERE - PRIV$USED = PRIVILEGE; USERID NAME ------------------------------ ---------------- ACME CREATE TABLE ACME CREATE SEQUENCE ACME CREATE TABLE ACME ALTER SESSION APPS CREATE TABLE APPS CREATE TABLE APPS CREATE TABLE APPS CREATE TABLE 8 rows selected.
新しいビューを使用すると、古いCONNECTロールを継続して使用する管理者は、どのユーザーがそのロールを持っているかをすばやく確認できます。
表10-1に、新しいDBA_CONNECT_ROLE_GRANTEESビューの各列を示します。
Oracleパートナおよびアプリケーション・プロバイダは、この方法を使用して、より安全性の高い製品をOracleの顧客ベースに供給する必要があります。「最低限の権限」原則は、所定の機能を実行するために必要な最低限のセットに権限を制限することでリスクを軽減します。
分析によって同一の権限セットが必要とされたユーザーのクラスごとに、その権限のみを持ったロールを作成します。他の権限はすべて該当するユーザーから取り消し、作成したロールを割り当てます。必要な権限が変化したときは、追加の権限を直接またはこれらの新しいロールを介して付与するか、新たに必要となった権限に応じた新しいロールを作成できます。この方法を使用すると、不適切な権限が制限され、不注意または意図的な被害が軽減されます。
