| Oracle Databaseセキュリティ・ガイド 11g リリース1（11.1） E05730-05 |
|
 戻る |
 次へ |
この章の内容は、次のとおりです。
この章では、Oracle Databaseの安全性を維持するための一連のガイドラインを示します。情報のセキュリティとプライバシ、および企業の資産とデータの保護は、どのようなビジネスにおいても非常に重要です。Oracle Databaseは、厳重なデータ保護、監査、スケーラブルなセキュリティ、安全なホスティング、データ交換などの最先端のセキュリティ機能を提供することによって、情報セキュリティに対するニーズに幅広く対応します。
Oracle Databaseは、セキュリティ機能において業界をリードしています。Oracle Databaseが提供するセキュリティ機能をすべてのビジネス環境で最大限に活用するには、データベース自体の保護が万全であることが必須条件です。
セキュリティ・ガイドラインは、運用データベースのデプロイメントに関する業界標準として推奨されるセキュリティ・プラクティスに準拠し、それを推奨することによって、Oracle Databaseを安全に構成する方法を示しています。この項で説明するガイドラインの多くは、米国サーベンス・オクスリー法（Sarbanes-Oxley Act）で規定されているような一般的な規制要件に対応しています。法令順守、個人を特定できる情報の保護、および内部の脅威に対するOracle Databaseの対処方法の詳細は、次のWebサイトを参照してください。
http://www.oracle.com/technology/deploy/security/db_security/index.html
この項の内容は、次のとおりです。
Oracle Databaseを稼働しているオペレーティング・システムとOracle Database自体、およびインストール済のOracle Databaseのオプションとコンポーネントすべてについて、関連するセキュリティ・パッチはすべて適用してください。
次のOracle Technology Networkのセキュリティ・サイトを定期的にチェックし、オラクル社からリリースされるセキュリティ・アラートの詳細を確認してください。
http://www.oracle.com/technology/deploy/security/alerts.htm
また、Oracleワールドワイド・サポート・サービスWebサイト、OracleMetaLinkもチェックして、セキュリティに関するパッチの入手可能性や予定などを確認してください。
OracleユーザーまたはOracleパートナであるユーザーがOracle製品の潜在的なセキュリティ上の脆弱性を発見した場合は、OracleMetaLinkを使用してサービス・リクエストを発行してください。もしくは、製品のバージョンやプラットフォームも含めた問題の詳細を、スクリプトと例を添えて、電子メールでsecalert_us@oracle.comに送信してださい。Oracleのセキュリティ窓口への連絡では、当社の暗号化鍵を使用した電子メール暗号化の利用をお薦めします。
ユーザー・アカウントと権限を保護するには、次のガイドラインに従います。
次のガイドラインに従うことをお薦めします。
必要な権限のみを付与する。
データベース・ユーザーまたはロールに必要以上の権限を付与しないでください（可能な場合は、ユーザーではなくロールに権限を付与してください）。「最低限の権限」原則とは、つまり、ユーザーに付与する権限を、各ユーザーが業務を効率よく遂行するために実際に必要となる権限のみに限定するということです。
SYSスキーマが所有するオブジェクトに、管理者以外のユーザーがアクセスできないようにする。
SYSスキーマ内の表の行またはスキーマ・オブジェクトをユーザーが変更できないようにします。これは、データの整合性を維持できなくなる可能性があるためです。SYSオブジェクトに対するDROP TABLE、TRUNCATE TABLE、DELETE、INSERTまたは類似のオブジェクト変更文の使用は、高い権限を持つ管理ユーザーのみに制限してください。
SYSスキーマはデータ・ディクショナリを所有します。データ・ディクショナリは、O7_DICTIONARY_ACCESSIBILITYパラメータをFALSEに設定することで保護できます。詳細は、「データの保護に関するガイドライン」の下にあるガイドライン1を参照してください。
PUBLICユーザー・グループから不要な権限を取り消す。
PUBLICユーザー・グループは、データベース内のすべてのユーザーを表します。データベース・サーバーのユーザー・グループPUBLICから不要な権限およびロールをすべて削除してください。PUBLICは、Oracleデータベース内のすべてのユーザーに付与されるデフォルト・ロールです。PUBLICに付与されている権限は、すべてのデータベース・ユーザーが行使できます。これらの権限には、たとえば、各種PL/SQLパッケージの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日でセキュリティ・ガイド』を参照してください。
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
SYS.AUD$（監査が使用可能な場合）
SYS.FGA_LOG$
次の権限が、それらを必要としているユーザーとロールのみに付与されていることを監視する。
デフォルトでは、次の権限が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.USER$に対する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ロールもその1つで、現在はCREATE SESSION権限のみが含まれています。以前は、このロールには他にも8つの権限がありました。CONNECTおよびRESOURCEの各ロールはともに、Oracleの将来のリリースでは使用不可になる予定です。
定義したロールには担当業務を反映する権限のみが含まれていることを確認してください。アプリケーション・ユーザーが既存のロールに組み込まれている権限のすべては必要としていない場合は、適切な権限のみを含む異なるロールのセットを適用してください。または、さらに権限が制限されているロールを作成して割り当てます。
たとえば、ユーザーSCOTTは侵入者から被害を受ける可能性がある既知のアカウントであるため、その権限については厳密な制限が必要不可欠です。CREATE DBLINK権限を使用すると、1つのデータベースから別のデータベースにアクセスできるため、SCOTTについては、この権限を削除します。次に、そのユーザーに割り当てられているロール全体を削除します。これは、ロールによって獲得した権限は個別には削除できないためです。必要な権限のみを付与した独自のロールを再作成し、該当するユーザーに付与します。同様に、セキュリティを改善するには、CREATE DBLINK権限を必要としていないすべてのユーザーからこの権限を削除します。
アプリケーション開発者にはユーザー・ロールを付与しない。
ストアド・プログラム構成メンバーの中からスキーマ・オブジェクトにアクセスする権限は、直接付与する必要があるため、ロールは、アプリケーション開発者が使用することを目的としていません。ロールは、ストアド・プロシージャ内では使用できないことに留意してください。ただし、実行者権限プロシージャの場合を除きます。詳細は、「PL/SQLブロックでのロールの機能」を参照してください。
Oracle Databaseのインストールごとに固有のロールを作成して割り当てる。
これにより、組織でロールおよび権限を詳細に制御できます。 また、現在はCREATE SESSION権限のみとなっているCONNECTなどのOracle Database定義のロールを、Oracle Databaseで変更または削除した場合の調整が不要となります。以前は他にも8つの権限がありました。CONNECTおよびRESOURCEの各ロールはともに、Oracle Databaseの将来のバージョンでは使用不可になる予定です。
エンタープライズ・ユーザーに対してグローバル・ロールを作成する。
グローバル・ロールは、Oracle Internet Directoryなどのエンタープライズ・ディレクトリ・サービスで管理されます。グローバル・ロールの詳細は次の各項を参照してください。
ユーザー・アカウントを作成すると、そのユーザーに対してデフォルトのパスワード・ポリシーが割り当てられます。このパスワード・ポリシーには、パスワードの作成方法（最小文字数や期限切れの時期など）についてのルールが定義されています。パスワードは、パスワード・ポリシーを使用することで強化できます。パスワードを保護するための別の方法については、「パスワード保護の構成」も参照してください。
パスワードをさらに強化するには、次のガイドラインに従います。
パスワードを慎重に選択する。
パスワードの最低要件については、「パスワードの最低要件」を参照してください。パスワードを作成または変更する際には、次の追加のガイドラインに従います。
パスワードは10文字から30文字の英数字にします。
パスワードには、大/小文字と特殊文字を混在させて使用します。（詳細は、「パスワードのセキュリティへの脅威からのSHA-1ハッシュ・アルゴリズムによる保護」を参照してください。）
パスワードの文字にはデータベース・キャラクタ・セットを使用します。このセットには、アンダースコア（_）、ドル記号（$）および番号記号（#）の各文字があります。
意味のある単語のみで構成されるパスワードを使用しないでください。
前述のガイドラインに従うのみでなく、Oracle Databaseでは数字または記号で始まるパスワードを作成できないことに注意してください。
より長く複雑で覚えやすいパスワードを作成するには、次のテクニックを使用します。
覚えやすいセンテンスの各語の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スクリプトを編集して、パスワードの安全性を高めます。パスワードのチェックに使用できるサンプル・ルーチンについては、「パスワードの複雑度検証の規定」も参照してください。
Oracle Databaseをインストールすると、事前定義された一連のデフォルト・ユーザー・アカウントがインストールされます。インストール完了後もデフォルトのデータベース・ユーザー・アカウントにデフォルトのパスワードを使用している場合、セキュリティは最も簡単に崩壊します。これは、ユーザー・アカウントSCOTTの場合に特に問題になります。このアカウントは、侵入者から被害を受ける可能性がある既知のアカウントです。Oracle Database 11g リリース1（11.1）では、デフォルトのアカウントはロックされ、パスワードは期限切れの状態でインストールされますが、以前のリリースからのアップグレードの場合は、デフォルトのパスワードを使用しているアカウントが存在している場合があります。
デフォルトのパスワードが設定されているユーザー・アカウントを検索するには、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ビューには、ユーザー・アカウントの状態、アカウントがロックされているかどうか、パスワードのバージョンなどの有用な情報が表示されます。DBA_USERSは、次のように問い合せできます。
sqlplus SYSTEM
Enter password: password
Connected.
SQL> SELECT * FROM DBA_USERS;
また、可能な場合は、Oracle Advanced Security（Oracle Database Enterprise Editionのオプション）を、ネットワーク認証サービス（Kerberosなど）、トークン・カード、スマート・カードまたはX.509証明書と一緒に使用することもお薦めします。これらのサービスを使用すると、ユーザーの厳密な認証が可能になるため、Oracle Databaseを不正なアクセスから保護できます。
Oracle表にはユーザー・パスワードをクリアテキストで格納しない。
セキュリティを強化するために、Oracle表には、ユーザー・パスワードをクリアテキスト（判読可能なテキスト）で格納しないでください。この問題は、パスワードが記載されている表の列を暗号化することで解決できます。透過的データ暗号化を使用して表の列を暗号化する方法については、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。
ユーザー・アカウントのパスワードを作成または変更すると、そのパスワードは自動的に暗号化されます。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管理者ガイド』を参照してください。また、データを暗号化してはならないケースについては、「暗号化で解決しないセキュリティの問題」を参照してください。
このリリースでは、安全性を高めるために、Oracle Databaseのデフォルト構成に変更が加わりました。この項の推奨事項には、この新規のデフォルト構成が追加されています。
データベースのインストールと構成を保護するには、次のガイドラインに従います。
UNIXシステムの場合は、Oracle Databaseのインストールを開始する前に、Oracle所有者アカウントのumask値が022であることを確認する。
LinuxおよびUNIXシステム上のOracle Databaseを管理する方法の詳細は、『Oracle Database管理者リファレンス for Linux and UNIX-Based Operating Systems』を参照してください。
オプションおよび製品: Oracle Databaseのインストール・メディア・パックには、データベースの他に、製品とオプションが収録されています。追加の製品やオプションは必要な場合のみインストールしてください。カスタム・インストール機能を使用して、不要な製品をインストールしないようにします。あるいは、標準的なインストールの完了後に不要なオプションや製品を削除してください。追加の製品やオプションを使用しない場合、それらをメンテナンスする必要はありません。追加の製品やオプションは、必要に応じていつでも適切にインストールできます。
サンプル・スキーマ: Oracle Databaseには、例を示すための共通のプラットフォームを提供するサンプル・スキーマが用意されています。このサンプル・スキーマは、データベースを本番環境で使用する場合はインストールしないでください。サンプル・スキーマをテスト・データベースにインストールした場合は、本番に移行する前に、そのサンプル・スキーマのアカウントを削除または再びロックしてください。サンプル・スキーマの詳細は、『Oracle Databaseサンプル・スキーマ』を参照してください。
インストール時に、パスワードの入力を求めるプロンプトが表示された場合は、安全性の高いパスワードを作成する。
「パスワードの保護に関するガイドライン」のガイドライン1、2および3に従います。
インストール直後に、デフォルトのユーザー・アカウントをロックし、期限切れにする。
「ユーザー・アカウントと権限の保護に関するガイドライン」のガイドライン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設定は、ユーザーがリモートで接続できないことを意味するものではありません。この設定は、データベースではクライアントがすでに認証された事実を信用せず、ユーザーに標準的な認証プロセスを適用することを意味します。
Secure Sockets Layer（SSL）を使用するように接続を構成する。
SSL通信を使用すると傍受が困難となり、ユーザーとサーバーの認証に証明書を使用できるようになります。SSLの構成方法の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
クライアントおよびサーバーの証明書認証を設定する。
認証の管理方法の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
システムにアクセスするユーザーを監視する。
インターネットを介したクライアント・コンピュータの認証には問題があります。インターネットを介した認証ではなく、ユーザー認証を使用してください。この認証方式は、クライアント・システムで、偽造されたIPアドレス、ハッキングされたオペレーティング・システムまたはアプリケーション、および偽造または盗用されたクライアント・システムIDが使用される問題を回避します。次の手順で、クライアント・コンピュータのセキュリティを改善します。
Secure Sockets Layer（SSL）を使用するように接続を構成します。SSL通信を使用すると傍受が無益となり、ユーザーとサーバーの認証に証明書を使用できるようになります。SSLの構成方法の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
たとえば、次のようにクライアントおよびサーバーの証明書認証を設定します。
組織は組織単位と証明書発行者によって識別され、ユーザーは識別名と証明書発行者によって識別されます。
アプリケーションで、証明書の期限が切れていないかどうかが確認されます。
証明書失効リストが監査されます。
認証の管理方法の詳細は、『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ファイルにパスワードが設定されていないことを確認します。ローカルのオペレーティング・システム認証によって、リスナー管理が保護されます。パスワードが設定されていない場合、リモートのリスナー管理は使用禁止になります。
ホスト・コンピュータに、複数の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 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文と権限の監査をオプションで使用可能にできます。デフォルト監査を使用可能にすることをお薦めします。監査は、強固な内部制御を規定する有効な方法であるため、サイトでは米国サーベンス・オクスリー法（Sarbanes-Oxley Act）に定義されている法令順守要件を満たすことができます。
監査は比較的低コストですが、監査するイベントの数はできるだけ制限してください。この制限によって、監査対象の文を実行したときのパフォーマンスへの影響が最小限に抑えられ、監査証跡のサイズが最小限になるため、分析と理解が容易になります。
監査方針を企画する際は、次のガイドラインに従ってください。
監査の目的を評価する。
監査の目的を明確にしておくと、適切な監査方針を企画でき、不要な監査を回避できます。
たとえば、不審なデータベース・アクティビティの調査のために監査すると仮定します。この情報のみでは不明確です。どのデータベース・アクティビティが疑わしい、または注意を要するといった具体的な情報が必要です。そのために、たとえば、データベース内の表から無許可にデータが削除されていないかを監査するというように、監査方針を絞り込みます。このような目的を設定すれば、監査の対象となるアクションの種類や、疑わしいアクティビティによって影響を受けるオブジェクトの種類を限定できます。
監査について十分理解する。
目標とする情報の取得に必要な最小限の文、ユーザーまたはオブジェクトを監査します。これによって、不要な監査情報のために重要な情報の識別が困難になることや、SYSTEM表領域内の貴重な領域が無駄に使用されることがなくなります。収集が必要なセキュリティ情報の量と、その情報を格納して処理する能力とのバランスを保つ必要があります。
たとえば、データベース・アクティビティに関する情報を収集するために監査する場合は、追跡するアクティビティの種類を正確に判断した上で、必要な情報を収集するために必要な期間内で、目的のアクティビティのみを監査します。別の例として、各セッションの論理I/O情報にのみ関心がある場合は、オブジェクトを監査しないでください。
監査方針を実施する前に法務部門と打ち合わせる。
組織の法務部門に監査方針を検討するように依頼する必要があります。 監査では組織の他のユーザーが監視されるため、サイトのコンプライアンス・ポリシーと会社の方針に適切に従っていることを確認する必要があります。
監査目的が特定のデータベース・アクティビティに関する履歴情報を収集することにある場合は、次のガイドラインに従ってください。
関連のあるアクションのみを監査する。
少なくとも、ユーザー・アクセス、システム権限の使用およびデータベース・スキーマ構造の変更を監査します。役に立たない監査レコードのために重要な情報が識別できない事態を避け、監査証跡管理の量を削減するために、目的のデータベース・アクティビティのみを監査してください。監査対象が多すぎるとデータベースのパフォーマンスに影響する可能性があることにも注意してください。
たとえば、データベースのすべての表に対する変更を監査すると、監査証跡レコードが多くなりすぎてデータベースのパフォーマンスが低下する可能性があります。ただし、Human Resources（人事管理）表内の給与のように、重要な表に対する変更を監査することは有益です。
ファイングレイン監査を使用することで、特定のアクションを監査できます。ファイングレイン監査については、「ファイングレイン監査を使用した特定のアクティビティの監査」を参照してください。
監査レコードをアーカイブし、監査証跡を削除する。
必要な情報を収集した後は、目的の監査レコードをアーカイブし、この情報の監査証跡を削除します。手順は、「データベース監査証跡のアーカイブおよび削除」を参照してください。
監査レコードを消去する場合、標準の監査レコードはSYS.AUD$表から、ファイングレイン監査レコードはSYS.FGA_LOG$表から削除できます。たとえば、標準の監査証跡からすべての監査レコードを削除するには、次の文を入力します。
DELETE FROM SYS.AUD$;
また、emp表の監査の結果として生成されたすべての監査レコードを監査証跡から削除するには、次の文を実行します。
DELETE FROM SYS.AUD$
WHERE obj$name='EMP';
標準監査証跡の管理の詳細は、「データベース監査証跡のサイズの制御」を参照してください。
自社のプライバシに関する考慮事項を検討する。
プライバシに関する法規によって、追加のビジネス・プライバシ・ポリシーが必要となる場合があります。プライバシに関するほとんどの法規では、個人を特定できる情報（PII）へのアクセスをビジネスで監視する必要があり、このような監視は監査によって実施されます。ビジネス・レベルのプライバシ・ポリシーでは、技術的、法的および企業ポリシーの問題など、データ・アクセスおよびユーザー・アカウンタビリティに関するすべての事項を処理する必要があります。
その他の監査情報をOracle Databaseのログ・ファイルでチェックする。
Oracle Databaseによって生成されたログ・ファイルには、データベースの監査時に使用できる有益な情報が含まれています。たとえば、Oracle Databaseではアラート・ファイルが作成され、STARTUP操作、SHUTDOWN操作およびデータベースにデータ・ファイルを追加するなどの構造上の変更が記録されます。
監査の目的が疑わしいデータベース・アクティビティを監視することにある場合は、次のガイドラインに従ってください。
最初に一般的な監査を行い、特定の対象を監査する。
疑わしいデータベース・アクティビティの監査を開始する時点では、多くの場合、対象のユーザーまたはスキーマ・オブジェクトの特定に使用できる情報はありません。このため、最初は一般的な監査オプションを設定します。つまり、第9章「監査を使用したセキュリティ・アクセスの検証」で説明した標準監査のオプションを使用します。この章では、一般的な監査オプションを使用したSQL文、スキーマ・オブジェクト、権限などの監査方法について説明しています。
準備的な監査情報の記録と分析を終了した後は、一般的な監査を使用禁止にして特定のアクションを監査します。「ファイングレイン監査を使用した特定のアクティビティの監査」で説明するように、ファイングレイン監査を使用して特定のアクションを監査できます。この処理は、疑わしいデータベース・アクティビティの原因について結論が出せるだけの十分な裏付けが収集できるまで継続してください。
一般的な疑わしいアクティビティを監査する。
一般的な疑わしいアクティビティは、次のとおりです。
通常以外の時間中にデータベースにアクセスするユーザー
複数回失敗したユーザー・ログイン試行
存在しないユーザーによるログイン試行
さらに、アカウントを共有しているユーザー、または同じIPアドレスからログインしている複数のユーザーを監視します。この種のアクティビティは、DBA_AUDIT_SESSIONデータ・ディクショナリ・ビューを問い合せることで検索できます。非常にきめ細かい方法では、ファイングレイン監査ポリシーを作成します。
監査証跡を保護する。
疑わしいデータベース・アクティビティを監査する場合は、監査と無関係に監査情報が追加、変更または削除されないように、監査証跡を保護します。標準の監査証跡を監査するには、AUDIT SQL文を使用します。
次に例を示します。
sqlplus "SYS/AS SYSDBA"
Enter password: password
SQL> AUDIT SELECT ON SYS.AUD$ BY ACCESS;
「データベース監査証跡の監査」も参照してください。
ファイングレイン監査証跡を監査するには、ユーザーSYSで、次の文を入力します。
AUDIT SELECT ON SYS.FGA$ BY ACCESS;
Oracle Database Vaultが使用可能になっている場合は、レルムに入れることでSYS.AUD$、SYS.FGA$およびSYS.FGA_LOG$表をさらに保護できます。詳細は、『Oracle Database Vault管理者ガイド』を参照してください。
データベース・スキーマまたは構造の変更。次のAUDIT文の設定を使用します。
AUDIT ALTER ANY TABLE BY ACCESS;
AUDIT CREATE ANY TABLE BY ACCESS;
AUDIT DROP ANY TABLE BY ACCESS;
AUDIT CREATE ANY PROCEDURE BY ACCESS;
AUDIT DROP ANY PROCEDURE BY ACCESS;
AUDIT ALTER ANY PROCEDURE BY ACCESS;
AUDIT CREATE EXTERNAL JOB BY ACCESS;
AUDIT CREATE ANY JOB BY ACCESS;
AUDIT CREATE ANY LIBRARY BY ACCESS;
AUDIT ALTER DATABASE BY ACCESS;
AUDIT ALTER SYSTEM BY ACCESS;
データベースへのアクセスと権限。次のAUDIT文の設定を使用します。
AUDIT AUDIT SYSTEM BY ACCESS;
AUDIT CREATE PUBLIC DATABASE LINK BY ACCESS;
AUDIT EXEMPT ACCESS POLICY BY ACCESS;
AUDIT ALTER USER BY ACCESS;
AUDIT CREATE USER BY ACCESS;
AUDIT ROLE BY ACCESS;
AUDIT CREATE SESSION BY ACCESS;
AUDIT DROP USER BY ACCESS;
AUDIT GRANT ANY PRIVILEGE BY ACCESS;
AUDIT GRANT ANY OBJECT PRIVILEGE BY ACCESS;
AUDIT GRANT ANY ROLE BY ACCESS;
AUDIT ALTER PROFILE BY ACCESS;
AUDIT DROP PROFILE BY ACCESS;
CONNECTロールはOracle Databaseリリース7で導入され、これにより、データベース・ロールに新しい堅牢なサポートが追加されました。CONNECTロールは、サンプル・コード、アプリケーション、ドキュメントおよび技術論文に使用されています。Oracle Database 10g リリース2（10.2）では、このロールが変更されました。Oracle Database 10.2より前のリリースから現行のリリースにアップグレードする場合は、この項を参照してください。
この項の内容は、次のとおりです。
CONNECTロールは、最初、次の権限を伴って設定されていました。
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権限が必要なデータベース・ユーザーはほとんどいません。
SQL> ALTER SESSION SET EVENTS ........
ALTER SESSION権限は、他のALTER SESSIONコマンドに対しては必要ありません。
SQL> ALTER SESSION SET NLS_TERRITORY = FRANCE;
CONNECTロールのみでプロビジョニングされたアプリケーション開発者には、表、ビュー、順序、シノニム、クラスタまたはデータベース・リンクを作成したり、ALTER SESSION文を使用するための適切な権限はありません。データベース管理者が、該当する権限用の追加ロールを作成および適用するか、その権限を必要としているアプリケーション開発者に直接付与する必要があります。
この変更の影響に対処するために次の3つの方法をお薦めします。
CONNECTロールから削除された権限は、新しいデータベース・ロールを作成することで管理できます。
まず、アップグレードされたOracleデータベースに接続して新しいデータベース・ロールを作成します。次の例では、my_app_developerというロールを使用しています。
SQL> CREATE ROLE my_app_developer; SQL> GRANT CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE SYNONYM, CREATE CLUSTER, CREATE DATABASE LINK, ALTER SESSION TO my_app_developer;
次に、CONNECTロールを持っているユーザーまたはデータベース・ロールを判別し、そのユーザーまたはロールに新しいロールを付与します。
SQL> 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
SQL> GRANT my_app_developer TO R1 WITH ADMIN OPTION;
SQL> GRANT my_app_developer TO R2;
ユーザーが必要としている権限は、Oracle Auditingを使用することで判別できます。この監査情報を分析して、よりきめ細かい追加のデータベース・ロール作成に使用できます。
特定のユーザーについて使用されていない権限は取り消すことができます。監査の前に、データベース初期化パラメータAUDIT_TRAILを初期化してデータベースを再起動する必要があることに注意してください。
SQL> AUDIT CREATE TABLE, CREATE SEQUENCE, CREATE SYNONYM, CREATE DATABASE LINK, CREATE CLUSTER, CREATE VIEW, ALTER SESSION;
これでデータベース権限の使用状況を定期的に監視できます。
SQL> 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 11g リリース1（11.1）以降、Oracleでは$ORACLE_HOME/rdbms/adminディレクトリにrstrconn.sqlというスクリプトを提供しています。データベースのアップグレードまたは新しいデータベースの作成した後は、このスクリプトを使用して、Oracle Database 11g リリース1（11.1）でCONNECTロールから削除された権限を付与できます。
この方法を使用した場合、使用されていない権限は必要としていないユーザーから取り消してください。そのような権限およびユーザーを識別するには、データベース初期化パラメータAUDIT_TRAILを、たとえばAUDIT_TRAIL=DBと初期化してデータベースを再起動する必要があります。その後、使用されている権限を監視するには、次のようにOracle Databaseの監査をオンにしてください。
SQL> AUDIT CREATE TABLE, CREATE SEQUENCE, CREATE SYNONYM, CREATE DATABASE LINK, CREATE CLUSTER, CREATE VIEW, ALTER SESSION;
データベース権限の使用状況も定期的に監視できます。
SQL> 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. SQL>
新しいビューを使用すると、古いCONNECTロールを継続して使用する管理者は、どのユーザーがそのロールを持っているかをすばやく確認できます。
表10-1に、新しいDBA_CONNECT_ROLE_GRANTEESビューの各列を示します。
Oracleパートナおよびアプリケーション・プロバイダは、この方法を使用して、より安全性の高い製品をOracleの顧客ベースに供給する必要があります。「最低限の権限」原則は、所定の機能を実行するために必要な最低限のセットに権限を制限することでリスクを軽減します。
分析によって同一の権限セットが必要とされたユーザーのクラスごとに、その権限のみを持ったロールを作成します。他の権限はすべて該当するユーザーから取り消し、作成したロールを割り当てます。必要な権限が変化したときは、追加の権限を直接またはこれらの新しいロールを介して付与するか、新たに必要となった権限に応じた新しいロールを作成できます。この方法を使用すると、不適切な権限が制限され、不注意または意図的な被害が軽減されます。
