11gリリース1（11.1）
E05765-03
 目次 |
 索引 |
| Oracle Database 概要 11gリリース1（11.1） E05765-03 |
|
この章では、Oracle Databaseのデータベース・セキュリティの概要について説明します。
この章の内容は、次のとおりです。
データベース・セキュリティには、データベースとデータベースに格納されたオブジェクトに対するユーザー・アクションを許可または禁止する機能が関係しています。Oracle Databaseでは、スキーマとセキュリティ・ドメインを使用して、データへのアクセスを制御し、様々なデータベース・リソースの使用を制限します。
Oracle Databaseは、包括的な任意アクセス制御を提供します。任意アクセス制御では、権限を使用して、特定のオブジェクトに対するすべてのユーザー・アクセスを制御します。権限とは、特定のオブジェクトに規定の方法でアクセスするための許可です。たとえば、表への問合せを実行する許可はその一例です。権限は、他のユーザーの裁量で任意に付与されます。
この項の内容は、次のとおりです。
それぞれのOracleデータベースは、ユーザー名のリストを持っています。データベースにアクセスするには、ユーザーはデータベース・アプリケーションを使用してデータベースの有効なユーザー名で接続する必要があります。無許可での使用を防止するために、各ユーザー名にはパスワードが対応付けられます。
各ユーザーはセキュリティ・ドメイン、つまり、次のようなことを決定する一連のプロパティを持っています。
ユーザーのセキュリティ・ドメインに寄与する各プロパティについては、この後の項で説明します。
権限は、特定のタイプのSQL文を実行するための権利です。たとえば、次のことをする権利が権限です。
Oracle Databaseでは、ロールを使用して、簡単かつ制御された権限管理を提供します。ロールは、関連する権限のグループに名前を付けたもので、ユーザーまたは他のロールに付与します。
データベースに割り当てられる各ユーザーのディスク領域の使用を管理および制御できます。これには、デフォルト表領域、一時表領域および表領域の割当てなどの方法があります。
この項の内容は、次のとおりです。
各ユーザーには、デフォルト表領域が対応付けられます。ユーザーがスキーマ・オブジェクトを作成する権限と、指定されたデフォルト表領域に対する割当て制限を持っている場合、表、索引またはクラスタの作成時にそのスキーマ・オブジェクトを物理的に格納する表領域を指定しないと、そのユーザーのデフォルト表領域が使用されます。スキーマ・オブジェクトの位置が指定されていない場合、デフォルトの表領域は、Oracle Databaseに領域使用を指定する情報を提供します。
各ユーザーは、一時表領域を持っています。ユーザーが一時セグメントの作成を必要とするSQL文（索引の作成など）を実行するときには、そのユーザーの一時表領域が使用されます。すべてのユーザーの一時セグメントを別の表領域に割り当てることによって、一時表領域は一時セグメントと他のタイプのセグメントとの間のI/O競合を低減します。
Oracle Databaseでは、スキーマ内のオブジェクトに対して使用できるディスク領域の総量を制限できます。割当て制限（領域制限）は、ユーザーが使用可能な表領域ごとに設定できます。これによって、特定のスキーマのオブジェクトが使用するディスク領域の容量を選択的に制御できます。
各ユーザーには、そのユーザーが使用可能な複数のシステム・リソースに関する制限を指定したプロファイルが割り当てられます。プロファイルには次のような制限が指定されます。
Oracle Databaseは、認証、認可および監査形式でセキュリティを提供します。認証では、正当なユーザーのみがシステムにアクセスできることが保証されます。認可では、ユーザーがアクセスを許可されているリソースにのみアクセスできることが保証されます。監査では、ユーザーが保護されたリソースにアクセスした場合のアカウンタビリティが保証されます。これらのセキュリティ・メカニズムによりデータベース内のデータが効率的に保護されますが、ただし、データが格納されているオペレーティング・システム・ファイルへのアクセスは防止されません。
透過的データ暗号化を使用すると、オペレーティング・システム・ファイルに格納されているデータベース列内の機密データを暗号化できます。さらに、データベース外部のセキュリティ・モジュールにおける、暗号化キーのセキュアな格納および管理が提供されます。
外部のセキュリティ・モジュールを使用すると、通常のプログラム機能が、暗号化などのセキュリティ関連機能から分離されます。したがって、DBAとセキュリティ管理者との間の管理業務を分割できます。この方法では、管理者にデータへの包括的なアクセス権限が付与されないため、セキュリティが強化されます。外部セキュリティ・モジュールでは、暗号化キーの生成、暗号化と復号化の実行およびデータベース外部へのキーの安全な格納が実行されます。
透過的データ暗号化は、機密扱いのキーによりデータを暗号化して認可を規定する、キーベースのアクセス制御システムです。指定された表内の暗号化された列の数に関係なく、暗号化された列が含まれるデータベース表ごとにキーを1つのみ使用できます。次に、各表の列の暗号化キーが、データベース・サーバーのマスター・キーにより暗号化されます。データベースにはキーは格納されません。そのかわり、外部セキュリティ・モジュールの一部であるOracle Walletに格納されます。
データベース列を暗号化する前に、マスター・キーを生成または設定する必要があります。このマスター・キーは、データベース列についてENCRYPT句を含むSQLコマンドを発行したときに自動的に生成された、列の暗号化キーの暗号化に使用されます。
表領域の暗号化は、このリリースで導入された新機能です。表領域の暗号化を使用すると、表領域全体を暗号化できます。これにより、表領域に格納されているすべてのデータが保護されます。認可されたユーザーが表領域のデータにアクセスすると、データはそのユーザーに対して透過的に復号化されます。
表領域の暗号化により、暗号化する列を決定するためにアプリケーションを細かく分析する必要がなくなります。表領域の暗号化を使用して、機密データが含まれている可能性のある表全体を暗号化できます。
透過的暗号化/復号化は、データへの論理アクセスごとではなく、ディスクI/Oの際に行われます。このため、パフォーマンスが向上します。
認証とは、データ、リソースまたはアプリケーションの使用を希望するエンティティ（ユーザーやデバイスなど）の識別を検証することです。識別を検証することで、その後の対話に関する信頼関係が確立されます。また、認証により、アクセスとアクションを特定の識別にリンクでき、アカウンタビリティが有効化されます。認証後は、認可プロセスでそのエンティティが実行できるアクセスと処理のレベルを許可または制限できます。
通常は、簡素化のためにデータベース・ユーザー全員に同じ認証方式が使用されますが、Oracle Databaseでは1つのデータベース・インスタンスで一部またはすべての方式を使用できます。Oracle Databaseでは、データベース管理者は特別なデータベース操作を実行するため、データベース管理者に対しては特別な認証手順が必要になります。さらに、Oracle Databaseでは、ネットワーク認証のセキュリティを確実にするため、送信時にパスワードが暗号化されます。
データベース・ユーザーの識別を検証し、データベース・ユーザー名の無許可使用を防止するために、ここで説明する認証方式を任意に組み合せて使用できます。
一部のオペレーティング・システムでは、オペレーティング・システムがユーザー認証のために管理している情報を、Oracle Databaseで使用することができます。この方式には、次の利点があります。
SQLPLUS /
データベース・ユーザーの認証にオペレーティング・システムを使用する場合は、分散データベース環境とデータベース・リンクの管理に特別な注意が必要です。
Oracle Databaseは、後述のようにネットワークによる複数の認証方法をサポートしています。
ネットワーク認証サービス（DCE、KerberosまたはSESAMEなど）を使用できる場合、Oracle Databaseでは、これらのネットワーク・サービスによる認証を使用できます。ネットワーク認証サービスを使用する場合は、ネットワーク・ロールとデータベース・リンクについて特別な考慮事項があります。
公開鍵暗号化に基づく認証システムは、ユーザー・クライアントにデジタル証明書を発行します。ユーザー・クライアントはそれを使用し、認証サーバーを直接関与させないで、社内のサーバーを直接認証します。Oracle Databaseは、公開鍵と証明書を使用するための公開鍵インフラストラクチャ（PKI）を提供します。PKIのコンポーネントは、次のとおりです。
Oracle Databaseは、Remote Authentication Dial-In User Service（RADIUS）を介したユーザーのリモート認証をサポートしています。RADIUSは、ユーザー認証、許可およびアカウント処理に使用される標準軽量プロトコルです。
Oracle Databaseでは、データベースに格納されている情報を使用して、データベースに接続しようとするユーザーを認証できます。
データベース認証を使用するようにOracle Databaseを設定するには、対応するパスワードを指定して各ユーザーを作成します。ユーザーは、接続の確立時にそのパスワードを入力する必要があります。ユーザーが正しいパスワードを入力しない場合は接続が拒否されるため、データベースの無許可での使用が防止されます。Oracle Databaseでは、ユーザーのパスワードは、暗号化された形式でデータ・ディクショナリに格納され、無許可での変更が防止されます。ただし、ユーザーはいつでも自分のパスワードを変更できます。
データベース認証の機能は、次のとおりです。
パスワードの機密性を保護するために、Oracle Databaseでは常に、ネットワークを介してパスワードが送信される前に暗号化されます。Oracle Databaseでは、変更されたAES（Advanced Encryption Standard）アルゴリズムによってパスワードが暗号化されます。
指定した連続試行回数の範囲内でログインできない場合、Oracle Databaseではユーザーのアカウントがロックされることがあります。一定の時間の後に自動的にロックが解除されるか、またはデータベース管理者によるロックの解除が必要になるように、アカウントを構成できます。データベース管理者が手動でアカウントをロックすることもできるため、その場合はデータベース管理者による明示的なロック解除が必要です。
データベース管理者は、パスワードの存続期間を指定できます。その期間をすぎるとパスワードは期限切れになり、アカウントへのログインが再度許可されるには、パスワードを変更する必要があります。猶予期間を設定できます。この期間中は、データベース・アカウントへのログインを試行するたびに、パスワードの変更を求める警告メッセージが発行されます。その期間内にパスワードを変更しないと、アカウントはロックされます。それ以降、そのアカウントには、データベース管理者の介入がなければログインできなくなります。
また、データベース管理者がパスワードの状態を期限切れに設定することもできます。この場合は、ユーザーのアカウントの状態が期限切れに変更されます。そのユーザーがデータベースにログインするには、自分で、またはデータベース管理者に依頼してパスワードを変更する必要があります。
パスワード履歴オプションは、新しく指定される各パスワードを調べて、指定された期間内に、または指定されたパスワード変更回数の間に、同じパスワードが再利用されないようにするためのものです。
複雑度の検証は、パスワードを推定してシステムに入ろうとする侵入者に対して、各パスワードが十分保護可能な複雑なものであることをチェックすることです。
Oracle Databaseでは、デフォルトのパスワード複雑度検証ルーチンにより、各パスワードが次の要件を満たしているかどうかがチェックされます。
welcome1、oracle1、user1234、数字付きのアルファベット順の文字列、またはchange_on_installのように、単純なパスワードでないこと
複数層環境では、Oracle Databaseは権限を制限し、すべての層を通じてクライアント識別を保持し、クライアントのために実行されるアクションを監査することによって、中間層アプリケーションのセキュリティを制御します。トランザクション処理モニターなど、大規模な中間層を使用するアプリケーションでは、中間層に接続するクライアントの識別性を維持する必要があります。ただし、中間層が持つ利点の1つに接続プーリングがあります。これにより、複数のユーザーが個別に接続しなくても1つのデータ・サーバーにアクセスできます。この種の環境では、接続を迅速に確立および切断できる機能が必要です。
この種の環境では、Oracleデータベース管理者はOracle Call Interface（OCI）を使用して、各ユーザーのデータベース・パスワード認証を可能にする軽量セッションを作成できます。これにより、中間層を介して実際のユーザーの識別性が保たれ、個別のデータベース接続によるオーバーヘッドは生じません。
パスワードあり、またはパスワードなしで軽量セッションを作成できます。ただし、中間層が外部またはファイアウォールにある場合は、軽量セッションごとに専用パスワードを設定する方がセキュリティが向上します。内部アプリケーション・サーバーの場合は、パスワードなしの軽量セッションの方が適している場合があります。
Oracle Database 11gでは、サーバー側接続プールを実装できます。これにより、様々なアプリケーションおよびアプリケーション・プロセスで、データベース接続を共有できます。サーバー側接続プールでサポートされているのは、パスワードベースの認証です。アドバンスト・セキュリティ・オプション（ASO）およびエンタープライズ・ユーザーは、現在はサポートされていません。
Secure Socket Layer（SSL）プロトコルは、アプリケーション・レイヤー・プロトコルです。外部的またはグローバルに識別されたユーザー（外部ユーザーまたはグローバル・ユーザー）は、SSLを使用してデータベースを認証できます。
データベース管理者は、通常のデータベース・ユーザーが実行できない特別な操作（データベースの停止や起動など）を実行します。Oracle Databaseでは、データベース管理者のユーザー名に対して、さらに安全性の高い認証方式を使用します。
データベース管理者の認証方式として、厳密認証、オペレーティング・システムによる認証、またはパスワード・ファイルによる認証のいずれかを選択できます。データベースをローカルに（データベースが格納されているコンピュータ上で）管理する場合と、1つのリモート・クライアントから多数の異なるデータベース・コンピュータを管理する場合では、異なる選択肢が適用されます。
厳密認証では、複数のデータベースに対するSYSDBAおよびSYSOPERのアクセスを集中管理できます。データベース管理においてこの種の認証を検討する必要があるのは、パスワード・ファイルのセキュリティに不安がある場合、サイトにきわめて厳格なセキュリティ要件が存在する場合、またはデータベースから識別管理を分離する場合です。
通常、データベース管理者のオペレーティング・システム認証には、データベース管理者のオペレーティング・システム・ユーザー名を特別なグループに入れること、または特別な処理を実行する権利を付与することが含まれます。（UNIXシステムでは、これはdbaグループです。）
データベースは、パスワード・ファイルを使用することによって、次の操作を実行できるSYSDBAまたはSYSOPER権限を付与されたデータベース・ユーザー名を追跡します。
SYSOPERは、データベース管理者がSTARTUP、SHUTDOWN、ALTER DATABASE OPEN/MOUNT、ALTER DATABASE BACKUP、ARCHIVE LOGおよびRECOVERを実行できるようにします。また、RESTRICTED SESSION権限が含まれます。
SYSDBA権限には、ADMIN OPTIONおよびSYSOPER権限とともに、すべてのシステム権限が含まれます。CREATE DATABASEと時間ベースのリカバリを許可します。認可は、主に次の2つのプロセスに分かれています。
ここでは、この種の制限を個々のユーザーまたはユーザー・グループに対して適用または除外するための基本概念とメカニズムについて説明します。
この項の内容は、次のとおりです。
ユーザーのセキュリティ・ドメインの一部として、各ユーザーが使用できる各種のシステム・リソースの容量に制限を設定できます。これにより、CPUタイムなどの貴重なシステム・リソースが無制限に浪費されるのを防止できます。
システム・リソースに費用がかかる大規模なマルチ・ユーザー・システムにおいて、このリソース制限機能はたいへん有効です。1人以上のユーザーが過度にリソースを使用すると、データベースの他のユーザーに有害な影響を及ぼす可能性があります。
ユーザーのリソース制限とパスワード管理の作業環境は、そのユーザーのプロファイルを使用して管理します。プロファイルとは、そのユーザーに割り当てることができる一連のリソース制限に名前を付けたものです。それぞれのデータベースに指定できるプロファイルの数に、制限はありません。セキュリティ管理者は、プロファイルによるリソース制限の規定を全体的に使用可能または使用禁止に設定できます。
リソース制限を設定した場合、ユーザーがセッションを作成すると、パフォーマンスがわずかに低下します。これは、ユーザーがOracle Databaseに接続した時点で、そのユーザーのすべてのリソース制限データがロードされるためです。
この項の内容は、次のとおりです。
Oracle Databaseでは、CPUタイムと論理読取りを含め、いくつかのタイプのシステム・リソースの使用を制限できます。一般に、それぞれのリソースは、セッション・レベル、コール・レベル、またはその両方で制御できます。
この項の内容は、次のとおりです。
ユーザーがデータベースに接続するたびに、セッションが作成されます。各セッションは、Oracle Databaseを実行するコンピュータのCPUタイムとメモリーを消費します。複数のリソース制限をセッション・レベルで設定できます。
Oracle Databaseでは、ユーザーがセッション・レベルのリソース制限を超えると、現行の文が終了（ロールバック）し、セッションの制限に達したことを示すメッセージが戻されます。この時点では、現行トランザクション内のそれ以前のすべての文の結果はそのまま残っています。ユーザーが実行できる操作は、COMMIT、ROLLBACKまたは接続の切断（この場合、現行トランザクションはコミットされます）のみです。それ以外の操作を実行すると、エラーが発生します。トランザクションがコミットまたはロールバックされた後も、カレント・セッションではユーザーはどんな作業も完了できません。
SQL文が実行されるたびに、いくつかのステップが実行され文が処理されます。この処理では、データベースに対して複数のコールが異なる実行フェーズの一部として発行されます。1回のコールで過度にシステムが使用されないように、Oracle Databaseでは複数のリソース制限をコール・レベルで設定できます。
ユーザーがコール・レベルのリソース制限を超えると、Oracle Databaseは文の処理を停止してその文をロールバックし、エラーを戻します。ただし、カレント・トランザクションのそれ以前の文の結果はそのまま残り、そのユーザーのセッションは接続されたままになります。
SQL文やその他のタイプのコールがOracle Databaseに発行されると、そのコールを処理するために一定量のCPUタイムが必要になります。平均的なコールであれば、わずかなCPUタイムですみます。ただし、大量のデータや冗長な問合せを伴うSQL文はCPUタイムを大量にコンシュームすることがあるため、他の処理に使用できるCPUタイムが少なくなります。
CPUタイムが無制限に消費されないようにするため、1回のコール当たりのCPUタイムと、1つのセッション中にOracle Databaseコールに使用されるCPUタイムの合計を制限します。これらの制限は、コールやセッションに使用される1/100秒（0.01秒）単位のCPUタイムで設定し、測定されます。
入出力（I/O）は、データベース・システムで最もリソースの使用量が多い操作の1つです。I/Oを集中的に実行するSQL文は、メモリーとディスクの使用を独占することがあるため、他のデータベース操作がこれらのリソースをめぐって競合する原因になる可能性があります。
単一の原因による過度のI/Oが発生しないようにするため、Oracle Databaseでは、1コール当たり、および1セッション当たりの論理データ・ブロック読取り数を制限できます。論理データ・ブロック読取りには、メモリーとディスクの両方からの論理データ・ブロック読取りが含まれます。これらの制限は、1コールまたは1セッション中に実行されるブロック読取りの数として設定し、測定されます。
Oracle Databaseでは、さらに、その他のいくつかのセッション・レベルのリソース制限が提供されています。
セッションがアイドル時間の制限を超えたために異常終了すると、その少し後に、異常終了したセッションの後処理としてプロセス・モニター（PMON）・バックグラウンド・プロセスがクリーン・アップを実行します。PMONがこのプロセスを完了するまでは、異常終了したセッションも、セッションまたはユーザー・レベルのリソース制限に加算されます。
Oracle Databaseは、経過アイドル時間や経過接続時間を絶えず監視しているわけではありません。絶えず監視した場合、システム・パフォーマンスが低下します。そのかわり数分ごとにチェックします。このため、Oracle Databaseがこの制限を実施してセッションを異常終了させるまでに、セッションはこの制限をわずかに（5分程度）超える可能性があります。
システム・リソースのコンテキストにおけるプロファイルとは、Oracle Databaseの有効なユーザー名に対して割り当てることができるリソース制限に名前を付けた集合です。プロファイルを使用すると、リソース制限を簡単に管理できます。また、パスワード方針を管理する手段としても使用できます。
データベースの各ユーザーに対して、個別に異なるプロファイルを作成し、割り当てることができます。明示的にプロファイルを割り当てられていないすべてのユーザーには、デフォルト・プロファイルが提供されます。リソース制限機能は、グローバルなデータベース・システム・リソースが過度に使用されることを防ぎます。
この項の内容は、次のとおりです。
ユーザー・プロファイルを作成して管理する必要があるのは、リソース制限がデータベース・セキュリティ・ポリシーの要件になっている場合のみです。プロファイルを使用するには、まずデータベース内の関連のあるユーザーを、いくつかのタイプに分類します。関連するユーザーの権限を管理するためにロールを使用するのと同様に、関連するユーザーのリソース制限を管理するためにプロファイルを使用します。データベースのすべてのタイプのユーザーを網羅するのに必要なプロファイルの数を決定し、それぞれのプロファイルに適切なリソース制限を決定します。
プロファイルを作成し、そのプロファイルに含めるリソース制限を決定する前に、各リソース制限について適切な値を決定します。これらの値は、典型的なユーザーが実行する操作のタイプを基準として決定できます。通常、ユーザー・プロファイルの適切なリソース制限値を決定するには、それぞれのタイプのリソースの使用状況について履歴情報を収集するのが最善です。
その他の制限値の統計情報は、Oracle Enterprise Manager（またはSQL*Plus）のモニター機能、特に統計モニターを使用して収集できます。
権限は、特定のタイプのSQL文を実行するため、または別のユーザーのオブジェクトにアクセスするための権利です。
権限をユーザーに付与すると、それらのユーザーが業務で必要な作業を実行できるようになります。権限は、その権限を本当に必要としているユーザーにのみ付与します。必要でない権限まで付与すると、セキュリティを維持できなくなる可能性があります。ユーザーは次の2つの方法で権限を受け取ることができます。
employees表にレコードを挿入する権限を、ユーザーSCOTTに明示的に付与できます。
employees表からレコードを選択、挿入、更新および削除する権限を、clerkという名前のロールに付与し、このロールCLERKをユーザーscottやbrianに付与できます。
ロールを使用することによって権限の管理が容易になり、改善されるため、通常、権限は個々のユーザーではなくロールに付与する必要があります。
権限は次の2つに分類できます。
システム権限とは、特定のアクションを実行する権限、または特定のタイプのスキーマ・オブジェクトに対してアクションを実行する権限のことです。たとえば、表領域を作成する権限や、データベース内の任意の表から行を削除する権限などがシステム権限です。システム権限には100以上の種類があります。
スキーマ・オブジェクト権限とは、次のように特定のスキーマ・オブジェクトに対して特定のアクションを実行する権限です。
各タイプのスキーマ・オブジェクトごとに、異なるオブジェクト権限があります。たとえば、departments表から行を削除する権限は、1つのオブジェクト権限です。
クラスタ、索引、トリガーおよびデータベース・リンクなど、一部のスキーマ・オブジェクトには、対応付けられたオブジェクト権限はありません。これらのオブジェクトの使用は、システム権限によって決定されます。たとえば、クラスタを変更するには、ユーザーはそのクラスタを所有しているか、またはALTER ANY CLUSTERシステム権限が必要です。
スキーマ・オブジェクトとそのシノニムは、権限に関しては等価です。つまり、表、ビュー、順序、プロシージャ、ファンクションまたはパッケージについて付与されるオブジェクト権限は、その基礎となるオブジェクトを名前で参照するかシノニムを使用するかにかかわらず、適用されます。
表、ビュー、順序、プロシージャ、ファンクションまたはパッケージに対するオブジェクト権限を、そのオブジェクトのシノニムに付与すると、シノニムを使用しない場合と同じ結果になります。シノニムが削除された場合、そのシノニムを指定して権限が付与されていた場合でも、基礎になるスキーマ・オブジェクトに対して付与された権限はすべて有効なままです。
ロールを使用することで、権限の管理および制御が容易になります。ロールは、関連する権限のグループに名前を付けたもので、ユーザーや他のロールに付与します。各ロール名はデータベース内で一意にする必要があり、どのユーザー名または他のどのロール名とも同一にすることはできません。スキーマ・オブジェクトとは異なり、ロールはスキーマに含まれているわけではありません。そのため、ロールを作成したユーザーを削除しても、そのロールに影響はありません。
ロールを使用すると、エンド・ユーザーのシステム権限とスキーマ・オブジェクト権限を容易に管理できます。ただし、ストアド・プログラム構成メンバーの中からスキーマ・オブジェクトにアクセスする権限は、直接付与する必要があるため、ロールは、アプリケーション開発者が使用することを目的としていません。
表20-1に、データベース内の権限管理を簡易化するロール・プロパティを示します。
データベース・アプリケーションについてのロールは、通常、データベース管理者が作成します。DBAは、アプリケーションの実行に必要なすべての権限を保護アプリケーション・ロールに付与します。その後、DBAは、保護アプリケーション・ロールを別のロールや特定のユーザーに付与できます。アプリケーションは複数の異なるロールを持つことができます。各ロールには、アプリケーションの使用時におけるデータ・アクセスの量を考慮して、異なる権限の集合を付与します。
DBAはパスワード付きのロールを作成し、そのロールに付与された権限が無許可で使用されるのを防止できます。通常、アプリケーションは起動時に適切なロールが使用可能になるように設計されます。そのため、アプリケーション・ユーザーは、アプリケーション・ロールのパスワードを知る必要がありません。
この項の内容は、次のとおりです。
通常は、次のどちらかの目的でロールを作成します。
図20-1とその後の項で、ロールの2通りの使用方法について説明します。
この項の内容は、次のとおりです。
アプリケーション・ロールには、特定のデータベース・アプリケーションを実行するために必要な権限をすべて付与します。そして、その保護アプリケーション・ロールを、他のロールや特定のユーザーに対して付与します。1つのアプリケーションに対して複数の異なるロールを設定し、アプリケーション使用時のデータ・アクセスの量や範囲にあわせて異なる権限セットを各ロールに割り当てることができます。
ユーザー・ロールは、共通の権限要件を持つデータベース・ユーザーのグループのために作成されるロールです。ユーザーの権限は、保護アプリケーション・ロールと権限をユーザー・ロールに付与し、そのユーザー・ロールを適切なユーザーに付与することによって管理します。
データベース・ロールには次の機能があります。
BがあらかじめロールAに付与されている場合、ロールAをロールBには付与できません。
環境によっては、オペレーティング・システムでデータベース・セキュリティを管理できる場合もあります。オペレーティング・システムを使用して、データベース・ロールの付与と取消しや、パスワードの認証を管理できます。この機能は、すべてのオペレーティング・システムで利用できるとはかぎりません。
Oracle Databaseでは、保護アプリケーション・ロールが用意されています。このロールは、認可されたPL/SQLパッケージでのみ有効にできます。このメカニズムは、アプリケーションを起動するロールの有効化を制限します。
パスワードが、アプリケーションのソース・コードに埋め込まれていない場合、または表に格納されていない場合、セキュリティは強化されます。そのかわりに、ロールの有効化を認可するPL/SQLパッケージを指定して、保護アプリケーション・ロールを作成できます。パッケージの識別は、ロールを有効化するのに十分な権限があるかどうかの決定に使用します。ロールの有効化の前に、アプリケーションはユーザーがプロキシを介して接続しているかどうかをチェックするなど、認証およびカスタマイズ認可を実行できます。
ユーザーが定義者権限プロシージャ内のセキュリティ・ドメインを変更できないという制限により、保護アプリケーション・ロールは実行者権限プロシージャ内でのみ有効化できます。
この項では、ユーザーではなくオブジェクトに関連する制限について説明します。制限により、それらはアクセスまたは変更を試みるエンティティにかかわらず保護されます。
このような保護を提供するには、特定の表、ビュー、シノニムまたは行へのアクセスを制限するためのポリシーを設計して使用します。これらのポリシーにより、制限を確立する動的な述語を指定するように設計されたファンクションが起動されます。また、確立されたポリシーをグループ化し、そのポリシー・グループを特定のアプリケーションに適用することもできます。
このように確立された保護に対する脅威や侵害が発生する場合には、通知を受け取る必要があります。通知を受け取ると、防御を強化するか、不適切なアクションとそれを実行したエンティティに対処できます。
この項の内容は、次のとおりです。
ファイングレイン・アクセス・コントロールにより、ファンクションを使用してセキュリティ・ポリシーを実装し、セキュリティ・ポリシーを表、ビューまたはシノニムに対応付けることができます。これらのセキュリティ・ポリシーは、データがアクセスされるかどうか（非定型問合せなど）に関係なく、データベース・サーバーによって自動的に規定されます。
次のことができます。
SELECT、INSERT、UPDATEおよびDELETE（および、行レベルのセキュリティ・ポリシーの場合はINDEX）に異なるポリシーを使用します。
PL/SQLパッケージDBMS_RLSを使用すると、セキュリティ・ポリシーを管理できます。このパッケージを使用して、作成したポリシー（またはポリシー・グループ）の追加、削除、使用可能と使用禁止の切替えおよびリフレッシュを行います。
ビューにセキュリティ・ルールが埋め込まれている場合ではなく、実表またはビューがDML文で参照される場合、動的な述語は文の解析時に取得されます。
作成したセキュリティ・ポリシーを実現するファンクションまたはパッケージは、述語（WHERE条件）を戻します。この述語により、ポリシーの指定に従ってアクセスが制御されます。再書込みされた問合せは、完全に最適化され、共有可能になります。
表、ビューまたはシノニムに対する動的な述語は、PL/SQLインタフェースを介してセキュリティ・ポリシーに対応付けられたPL/SQLファンクションにより生成されます。
アプリケーション・コンテキストを使用すると、アプリケーションにファンクション・ベースのセキュリティ・ポリシーを対応付けることができるため、ファイングレイン・アクセス・コントロールの適用が容易になります。
各アプリケーションには固有のコンテキストがあり、ユーザーが任意に（SQL*Plusなどを介して）変更することはできません。コンテキスト属性には、セキュリティ・ポリシーを実装するファンクションからアクセスできます。たとえば、人事管理アプリケーションのコンテキスト属性には「職位」、「部門」および「国」などを含め、受注管理アプリケーションの属性には「顧客番号」や「営業地区」などを含めることができます。
そのため、アプリケーション・コンテキストにより、アプリケーションに関係する属性を使用した、パラメータベースの柔軟なアクセス制御が可能になります。
次のことができます。
ポリシーでは、それが静的、共有、状況依存、動的のいずれであるかを指定することでランタイム効率を識別できます。
静的ポリシーの場合は、オブジェクトにアクセスするエンティティに関して同じ条件文字列を生成すると、それが1度実行されてSGAにキャッシュされます。同じオブジェクトにアクセスする文に対するポリシーの場合、ポリシー関数は再実行されず、かわりにキャッシュされた条件が使用されます。
これは共有の静的ポリシーの場合も同様で、サーバーは最初に、同じポリシー・タイプの同じポリシー関数によって生成されキャッシュに置かれた条件を検索します。共有の静的ポリシーは、ほぼすべてのオブジェクトが同じ関数を共有し、ポリシーが静的であるため、ホスト上のデータ・パーティションに最適です。
ポリシーに状況依存のラベルを付けると、サーバーは常に文の解析時にポリシー関数を実行し、戻り値をキャッシュしません。カーソルが最後に使用された後にサーバーがコンテキストの変化を検出しないかぎり、文の実行時にポリシー関数が再評価されることはありません。（複数のクライアントが1つのデータベース・セッションを共有するセッション・プーリングの場合は、クライアント切替え時に中間層でコンテキストをリセットする必要があります）。
状況依存ポリシーが共有される場合、サーバーは最初に、同じデータベース・セッションで同じポリシー・タイプの同じポリシー関数によって生成されキャッシュに置かれた述語を検索します。セッション・メモリー内で述語が検出されると、ポリシー関数は再実行されず、セッションのプライベート・アプリケーション・コンテキストが変化するまでは、キャッシュに置かれた値が有効になっています。
動的ポリシーの場合、サーバーでは述語が常にシステムまたはセッション環境の影響を受けるとみなされ、文の解析または実行するたびにポリシー関数を再実行します。
ファイングレイン監査を行うと、データ・アクセスを内容に基づいて監視できます。INSERT、UPDATEおよびDELETE操作と問合せをきめ細かく監査できます。たとえば、中央の税務当局は、職員によるアクセス違反から保護するために、アクセスされたデータの判別に十分な詳細を使用して所得申告情報へのアクセスを追跡する必要があります。特定のユーザーが特定の表に対してSELECT権限を使用したということがわかるだけでは十分ではありません。ファイングレイン監査は、このより詳細な機能を提供します。
通常、ファイングレイン監査方針は、選択的監査の条件として表オブジェクトに対する単純なユーザー定義SQL条件に基づいています。フェッチ中に戻される行が方針の条件を満たすと、その問合せが監査対象となります。後でOracle Databaseは自律型トランザクションを使用してユーザー定義の監査イベント・ハンドラを実行し、イベントを処理します。
ファイングレイン監査をユーザー・アプリケーションに実装するには、DBMS_FGAパッケージを使用する方法と、データベース・トリガーを使用する方法があります。
この項の内容は、次のとおりです。
各データベースでは、セキュリティ管理者と呼ばれる1人以上の管理者が、セキュリティ・ポリシーのあらゆる側面の保守を担当します。データベース・システムが小規模な場合は、データベース管理者がセキュリティ管理者を兼務する場合もあります。ただし、データベース・システムが大規模な場合は、特定の管理者または管理者グループが専任でセキュリティ管理者を務める場合があります。
すべてのデータベースについて、セキュリティ・ポリシーを開発する必要があります。また、セキュリティ・ポリシーには後述する複数のサブポリシーを組み込む必要があります。
この項の内容は、次のとおりです。
データベース・システムの規模と、データベース・ユーザーの管理に必要な作業量によっては、データベース・ユーザーの作成、変更または削除に必要な権限をセキュリティ管理者にのみ付与できます。また、データベース・ユーザーを管理するための権限を複数の管理者に付与することもできます。どちらの場合にも、データベース・ユーザーを管理するための強力な権限は、信頼できるユーザーにのみ付与する必要があります。
データベース・ユーザーは、データベース・パスワード、ホスト・オペレーティング・システム、ネットワーク・サービスまたはSecure Sockets Layer（SSL）を使用して、Oracle Databaseで認証を受ける（正しいユーザーとして検証される）ことができます。
該当する場合は、Oracle Databaseおよび他のデータベース・アプリケーションを実行するオペレーティング・システム環境について、次のセキュリティ上の問題も考慮する必要があります。
データ・セキュリティには、オブジェクト・レベルにおけるデータベースのアクセスと使用を制御するメカニズムが含まれています。データ・セキュリティ・ポリシーにより、特定のスキーマ・オブジェクトにアクセスするユーザーと、各ユーザーがオブジェクトに対して許可されるアクションのタイプが決定されます。たとえば、ユーザーscottがemployees表を使用する場合、SELECTおよびINSERT文は発行できますが、DELETE文は発行できません。データ・セキュリティ・ポリシーでは、スキーマ・オブジェクトごとに監査対象となるアクションがある場合は、そのアクションも定義する必要があります。
データ・セキュリティ・ポリシーは、主にデータベース内のデータに必要なセキュリティのレベルによって決定されます。たとえば、ユーザーにスキーマ・オブジェクトの作成を許可する場合や、ユーザーのオブジェクトへのアクセス権限をシステムの他のユーザーに付与することを許可する場合、データベース内のデータ・セキュリティはほとんど必要ありません。また、オブジェクトを作成するための権限と、ロールおよびユーザーに対するオブジェクトへのアクセス権限を付与するための権限を、データベース管理者またはセキュリティ管理者のみに限定する必要がある場合は、データ・セキュリティの厳密な制御が必要になります。
データ・セキュリティ全体は、データの機密性をベースとする必要があります。情報に機密性がない場合は、データ・セキュリティ・ポリシーを緩和できます。ただし、データの機密性が高い場合は、オブジェクトへのアクセスを常に厳密に制御するように、セキュリティ・ポリシーを開発する必要があります。
データ・セキュリティの実装手段には、システム権限、オブジェクト権限およびロールなどがあります。ロールとは、ユーザーにまとめて付与できるようにグループ化された権限の集合です。ビュー定義で表データへのアクセスを制限できるため、ビューでデータ・セキュリティを実現することもできます。これにより、機密データを含む列を除外できます。
データ・セキュリティのもう1つの実装手段は、ファイングレイン・アクセス・コントロールを介して、関連するアプリケーション・コンテキストを使用することです。ファイングレイン・アクセス・コントロールにより、ファンクションにセキュリティ・ポリシーを適用し、セキュリティ・ポリシーを表またはビューに対応付けることができます。実際には、セキュリティ・ポリシー関数によりSQL文に追加するWHERE条件が生成され、表またはビューのデータ行に対するユーザー・アクセスが制限されます。アプリケーション・コンテキストは、アクセス制御の決定に使用される情報を格納するための保護データ・キャッシュです。
この項では、ユーザー・セキュリティ・ポリシーの様々な側面について説明します。この項の内容は、次のとおりです。
すべてのタイプのデータベース・ユーザーについて、パスワード・セキュリティと権限管理を考慮してください。
ユーザー認証をデータベースで管理する場合、セキュリティ管理者は、データベース・アクセス・セキュリティを維持するためにパスワード・セキュリティ・ポリシーを開発する必要があります。たとえば、データベース・ユーザーは各自のパスワードを定期的に変更する必要があります。ユーザーにパスワードの変更を強制することで、無許可のデータベース・アクセスを減らすことができます。
また、あらゆるタイプのユーザーについて、権限管理に関連する問題を考慮する必要があります。たとえば、多数のユーザー、アプリケーションまたはオブジェクトを伴うデータベースの場合は、ロールを活用してユーザーが使用可能な権限を管理できます。また、データベースで使用されるユーザー名が少数の場合には、ロールを使用せずに、ユーザーに対して権限を明示的に付与する方が容易な場合があります。
セキュリティ管理者は、エンド・ユーザー・セキュリティのポリシーを定義する必要があります。データベースに多数のユーザーがいる場合、セキュリティ管理者はどのユーザーをまとめて各ユーザー・グループに分類するかを決定し、各グループのユーザー・ロールを作成できます。また、必要な権限またはアプリケーション・ロールを各ユーザー・ロールに付与し、そのユーザー・ロールを各ユーザーに付与できます。例外を考慮して、どの権限を個々のユーザーに明示的に付与する必要があるかについても決定する必要があります。
様々なデータベース・ユーザー・グループが必要とする共通の権限を付与して管理するには、ロールを使用するのが最も簡単な方法です。また、Oracle Advanced Securityのエンタープライズ・ユーザーおよびエンタープライズ・ロール機能を介して、ユーザーとその認可をディレクトリ・サービスで集中管理することもできます。
セキュリティ管理者には、データベース管理者セキュリティに対処するポリシーが必要です。たとえば、データベースが大規模で数タイプのデータベース管理者が存在する場合、セキュリティ管理者が関連する管理権限を複数の管理ロールにグループ化するように決定できます。これにより、管理ロールを適切な管理者ユーザーに付与できます。また、データベースが小規模で管理者が少人数であれば、管理ロールを1つ作成して管理者全員に付与する方が便利な場合があります。
SYSおよびSYSTEMにデフォルトのパスワードを使用した場合は、データベースを作成した直後にSYSおよびSYSTEM管理ユーザー名のパスワードを変更してください。SYSまたはSYSTEMとして接続すると、ユーザーにはデータベースを変更するための強力な権限が付与されます。
他の管理ユーザー名を作成させるオプションをインストールしている場合、そのユーザー名のアカウントは最初はロック状態で作成されます。
管理権限を使用してデータベースに接続できるユーザーは、データベース管理者のみに限定する必要があります。次に例を示します。
CONNECT SYS/AS SYSOPER|SYSDBA Enter password: enter the password
SYSOPERとして接続するユーザーには、基本的な運用タスク（STARTUP、SHUTDOWNおよびリカバリ操作など）を実行するための権限が付与されます。SYSDBAとして接続するユーザーには、これらの権限に加えて、データベースまたはデータベース内のオブジェクトに対してあらゆる操作（CREATE、DROPおよびDELETEなど）を実行するための無制限の権限が付与されます。SYSDBAを使用すると、ユーザーはSYSスキーマに置かれるため、データ・ディクショナリ表を変更できます。
セキュリティ管理者は、データベースを使用するアプリケーション開発者について、特別なセキュリティ・ポリシーを定義する必要があります。アプリケーション開発者には、必要なオブジェクトを作成するための権限を付与できます。または、オブジェクトの作成権限を、開発者からオブジェクト作成要求を受け取るデータベース管理者にのみ付与する方法もあります。
データベース・アプリケーション開発者は、担当のジョブを達成するために特別な権限グループを必要とする一意のデータベース・ユーザーです。エンド・ユーザーとは異なり、開発者には、CREATE TABLE、CREATE PROCEDUREなどのシステム権限が必要です。ただし、開発者には特定のシステム権限のみを付与し、データベース内で実行可能な操作全体を制限する必要があります。
多くの場合、アプリケーション開発者が実行できる操作はデータベースのテストに限定され、本番データベースで実行することは許可されません。この制限により、アプリケーション開発者がエンド・ユーザーとの間でデータベース・リソースをめぐって競合しないことと、本番データベースに有害な影響を及ぼさないことが保証されます。アプリケーションが細部に至るまで開発されテストされた後は、本番データベースへのアクセスが許可され、本番データベースの適切なエンド・ユーザーが使用可能になります。
セキュリティ管理者はロールを作成して、典型的なアプリケーション開発者に必要な権限を管理できます。
通常、アプリケーション開発者には開発プロセスの一部としてオブジェクトを作成するための権限が付与されますが、セキュリティ管理者は各アプリケーション開発者が使用できるデータベース領域とそのサイズに対する制限を維持する必要があります。たとえば、セキュリティ管理者はアプリケーション開発者ごとに次の制限を特別に設定または制限します。
どちらの制限も、開発者のセキュリティ・ドメインを変更することで設定できます。
多数のデータベース・アプリケーションが関連する大規模データベース・システムの場合は、次のタイプのタスクを担当するアプリケーション管理者を割り当てることを考慮してください。
通常、アプリケーション管理者は、アプリケーションを設計したアプリケーション開発者です。ただし、アプリケーション管理者には、データベース・アプリケーションをよく理解している他のユーザーを指定する場合もあります。
パスワードに依存するデータベース・セキュリティ・システムでは、常にパスワードの機密を保つ必要があります。ただし、パスワードは盗まれたり忘れたり誤用する可能性があります。データベース・セキュリティを厳密に管理できるように、Oracle Databaseのパスワード管理ポリシーはDBAとセキュリティ管理者によりユーザー・プロファイルを介して制御されます。
セキュリティ管理者は、各データベースの監査手順に関する方針を定義する必要があります。問題のあるアクティビティが疑われる場合を除き、データベース監査は使用禁止にするように決定できます。監査が必要な場合は、データベース監査の詳細レベルを決定します。通常、システム監査の後は、疑わしいアクティビティの発生源が判別された後で、さらに限定的なタイプの監査を実行します。次の項では、監査について説明します。
監査とは、選択したユーザー・データベース・アクションを監視して記録する処理のことです。実行されたSQL文のタイプなどの個々のアクション、または名前、アプリケーション、時間などの様々な要因の組合せをベースとして使用できます。Oracle Databaseの指定の要素がアクセスされたり、その内容などに変更があった場合に、セキュリティ・ポリシーに基づいて監査を実行できます。
監査は、通常次のような目的で使用されます。
Enterprise Managerを使用して、監査関連の初期化パラメータを表示および構成し、文監査およびスキーマ・オブジェクト監査の監査オブジェクトを管理できます。たとえば、Enterprise Managerでは、現行の監査対象の文、権限およびオブジェクトのプロパティが示されます。各オブジェクトのプロパティを参照でき、プロパティを基準にして監査オブジェクトを検索できます。また、オブジェクト、文および権限に対する監査をオンまたはオフにできます。
Oracle Databaseでは、監査オプションの対象範囲を広くしたり狭くできます。次の監査ができます。
Oracle Databaseの監査機能では、表20-2のように複数の異なるメカニズムを使用できます。
監査レコードには、監査された操作、操作を実行したユーザーおよび操作の日時などの情報が記録されます。監査レコードは、データベース監査証跡と呼ばれるデータ・ディクショナリ表か、オペレーティング・システム監査証跡と呼ばれるオペレーティング・システム・ファイルのどちらかに格納できます。
この項の内容は、次のとおりです。
データベース監査証跡は、各Oracleデータベースのデータ・ディクショナリのSYSスキーマにあるSYS.AUD$という名前の単一の表です。この表の情報を使用しやすくするため、複数の事前定義済のビューが提供されています。
監査対象のイベントと設定されている監査オプションに応じて、監査証跡には様々な種類の情報が記録されます。ただし、次の情報は、特定の監査アクションにとって意味がある場合、それぞれの監査証跡レコードに常に記録されます。
監査機能には、サイト自律性があります。インスタンスは、直接接続しているユーザーが発行する文のみを対象に監査します。ローカルOracle Databaseノードは、リモート・データベースで発生するアクションを監査できません。リモート接続はデータベース・リンクのユーザー・アカウントを介して確立されるため、リモートOracle Databaseノードはデータベース・リンクの接続を介して発行された文を監査します。
オペレーティング・システムの監査証跡が使用可能になっている場合に、Oracle Databaseは監査証跡レコードをオペレーティング・システムの監査証跡に送ることができます。それ以外の場合は、監査レコードは、他のOracle Databaseトレース・ファイルに類似した形式のデータベース外のファイルに書き込まれます。
Oracle Databaseでは、オペレーティング・システムの監査証跡（または監査レコードを含むオペレーティング・システム・ファイル）に監査レコードを記録できない場合にも、常に特定のアクションの監査を続行できます。オペレーティング・システムの監査証跡に記録できないのは、多くの場合、オペレーティング・システムの監査証跡またはファイル・システムがいっぱいになっており、新しいレコードが入らないことが原因です。
オペレーティング・システム監査を構成するシステム管理者は、監査証跡またはファイル・システムがいっぱいにならないようにしてください。ほとんどのオペレーティング・システムでは、このような状況を回避できるように十分な情報と警告が管理者に提供されます。ただし、データベースの監査証跡を使用するように監査を構成すれば、その危険性を回避できることに注意してください。監査証跡が文に関するデータベース監査レコードを受け入れられない場合には、監査されているイベントの発生がOracle Databaseによって防止されるためです。
オペレーティング・システム監査証跡はエンコードされていますが、データ・ディクショナリ・ファイルとエラー・メッセージにデコードできます。
AUDIT_ACTIONSデータ・ディクショナリ表に記述されます。
SYSTEM_PRIVILEGE_MAP表に記述されます。
データベース監査が使用可能であるかどうかに関係なく、ある種のデータベース関連アクションは常にオペレーティング・システム監査証跡に記録されます。
Oracle Databaseから監査証跡にアクセスできないように設定されたオペレーティング・システムの場合、これらの監査証跡レコードは、バックグラウンド・プロセスのトレース・ファイルと同じディレクトリにあるOracle Database監査証跡ファイルに格納されます。
許可されたデータベース・ユーザーは独自の監査オプションをいつでも設定できますが、監査情報の記録を使用可能または使用禁止にするのはセキュリティ管理者です。
データベースの監査機能が使用可能になっている場合、監査レコードは文実行の実行フェーズで生成されます。
PL/SQLプログラム・ユニット内のSQL文は、プログラム・ユニットの実行時に必要に応じて監査されます。
監査証跡レコードの生成と挿入は、ユーザーのトランザクションのコミットからは独立して実行されます。つまり、ユーザーのトランザクションがロールバックされても、監査証跡レコードはコミットされたままになります。
データベース・ユーザーがデータベースに接続した時点で有効になっていた文監査オプションと権限監査オプションは、そのセッションの持続期間中は有効です。セッション中に文監査または権限監査のオプションを設定または変更しても、そのセッション中は有効になりません。修正した文監査オプションまたは権限監査オプションは、カレント・セッションを終了し、新しいセッションを作成する時点で有効になります。一方、オブジェクト監査オプションについて変更した内容は、カレント・セッションでただちに有効になります。
SYSユーザーや、SYSDBAまたはSYSOPERを介して接続したユーザーによる操作は、AUDIT_SYS_OPERATIONS初期化パラメータを使用して完全に監査できます。SYSにより実行され、正常終了したSQL文は、常に監査対象となります。ユーザーSYSによって確立されたセッションや管理者権限での接続の場合、生成された監査レコードはオペレーティング・システムの位置に送られます。SYSスキーマ内の通常のデータベース監査証跡とは別の場所に送信すると、監査のセキュリティが向上します。
|
関連項目
|
|
 Copyright © 1993, 2008 Oracle Corporation. All Rights Reserved. |
|