この章では、Oracle Label Securityのポリシーの施行をカスタマイズする方法と、ラベル付けファンクションを実装する方法について説明します。この章の内容は、次のとおりです。
この項では、ポリシー・オプションの概要と使用方法について説明します。
管理者は、Oracle Label Securityで使用可能なすべての施行制御オプションから、特定のアプリケーションのニーズを満たすオプションを選択する必要があります。これは、公開、変更または誤用に対するデータの機密性レベルを識別することの他、この種のデータへのアクセスや変更が必要なユーザー、またはその権限を持つユーザーを識別することを意味します。ポリシー施行オプションを使用すると、管理者はユーザーがデータまたはラベルの読取りや書込みができるかどうかを詳細にチューニングできます。
これらのオプションは、次のように3つのレベルで機能します。
表9-1 ポリシー施行オプションが有効な場合
オプションの設定レベル | このレベルで設定されたオプションがユーザー操作に影響する場合 |
---|---|
ポリシー・レベル |
... ポリシーが表またはスキーマに適用されている場合のみ |
スキーマ・レベル |
... ユーザーがこのスキーマで操作する場合 |
表レベル |
... ユーザーがこの表で操作する場合 |
表またはスキーマにポリシーを適用する場合は、その表またはスキーマの使用を制限する施行オプションを指定できます。適用時に施行オプションを指定しなければ、そのポリシーの作成時に指定したデフォルトの施行オプションが自動的に使用されます。
これらのオプションにより、ポリシーの施行はREADアクセス、WRITEアクセスおよびラベル変更に関するセキュリティ要件にあわせてカスタマイズされます。また、ラベル列を表示するか非表示にするかも指定できます。保護されている表については、必要なポリシー・オプションのみを指定して一部またはすべてを施行するように選択できます。
オプションで、各表にラベル付けファンクションを割り当てることができます。これにより、その表で挿入または更新される行のラベルが決まります。オプションで、表のSQL述語を指定して、ラベルに基づいてユーザーがアクセス可能な行を制御できます。
Oracle Label Securityのポリシー施行オプションを適用すると、表示、挿入、更新または削除のためにアクセスできる行が制御されます。
表9-2「ポリシー施行オプション」に、次の3つのカテゴリのオプションを示します。
ラベル管理オプション。挿入または更新される行に書き込まれるデータ・ラベルが、そのラベルに対して設定されているポリシーに違反しないことを保証します。
アクセス制御オプション。SELECT、UPDATE、INSERTまたはDELETE操作で、ラベルが設定済ポリシーを満たしている行のみにアクセスできることを保証します。
オーバーライド・オプション。他のすべての施行オプションを一時停止または適用できます。
表9-2 ポリシー施行オプション
施行のタイプ | オプション | 説明 |
---|---|---|
|
INSERT時にラベルを明示的に指定しないかぎり、セッションのデフォルトの行ラベル値が使用されます。 |
|
ポリシーの施行は、行に連結されたラベルの値を設定または変更するUPDATE操作に適用されます。WRITEUP、WRITEDOWNおよびWRITEACROSS権限は、LABEL_UPDATE操作がアクティブな場合にのみ施行されます。 |
||
新規の行ラベルが読取りアクセス可能になるように、INSERTおよびUPDATE文にREAD_CONTROLポリシーの施行を適用します。 |
||
|
すべての問合せにポリシーの施行を適用します。SELECT、UPDATEおよびDELETE操作のためにアクセスできるのは、認可された行のみになります。 |
|
行のデータをINSERT、UPDATEおよびDELETEできるかどうかを決定します。このオプションがアクティブな場合は、INSERT_CONTROL、UPDATE_CONTROLおよびDELETE_CONTROLが施行されます。 |
||
図3-8「書込みアクセス権のラベル評価プロセス」に示した書込みアクセスのアルゴリズムに従って、INSERT操作にポリシーの施行を適用します。 |
||
図3-8「書込みアクセス権のラベル評価プロセス」に示した書込みアクセスのアルゴリズムに従って、DELETE操作にポリシーの施行を適用します。 |
||
図3-8「書込みアクセス権のラベル評価プロセス」に示した書込みアクセスのアルゴリズムに従って、行内のデータ列に対するUPDATE操作にポリシーの施行を適用します。 |
||
|
すべての施行オプションを適用します。 |
|
施行オプションを適用しません。ただし、ラベル付けファンクションやSQL述語は適用できます。 |
Oracle Label Securityが表に適用される場合でも、一部のDML操作は適用されるポリシーの対象ではない場合があることに注意してください。管理者が設定するポリシー強制オプションにより、SQL処理動作と、保護された表に対する問合せに対して認可済ユーザーが実際に参照できる内容の両方が決まります。特に注記がないかぎり、この章ではALL_CONTROLがアクティブであり、すべての強制オプションが有効であることを想定します。ユーザーが認可されていない操作を実行しようとすると、エラー・メッセージが表示され、SQL文が失敗します。
Oracle Label Securityのポリシーの設計と実装で有効に使用するには、これらのポリシー施行オプションの相互関係と各オプションで制御されるSQL文を理解しておくことが重要です。
表9-2「ポリシー施行オプション」に、これらの相互関係を示します。
表9-3 ポリシー施行オプションの制御対象
ポリシーで指定するオプション | 制御されるSQL操作 | 使用する条件とその効果 |
---|---|---|
SELECT、UPDATEおよびDELETE |
認可された行(*)にのみアクセスできます。 |
|
WRITE_CONTROL |
(a) 認可された行(**)にのみアクセスできます。 (b) LABEL_UPDATEがアクティブでないかぎり、データ・ラベルは書込み可能です。 |
|
次の3つのオプションにWRITE_CONTROLが必要 |
||
INSERT_CONTROL |
INSERT |
|
UPDATE_CONTROL |
UPDATE |
|
DELETE_CONTROL |
DELETE |
|
CHECK_CONTROL |
新規の行ラベルが読取りアクセス可能になるように、INSERTおよびUPDATE文にREAD_CONTROLポリシーの施行を適用します。 |
|
|
すべての問合せにポリシーの施行を適用します。操作のためにアクセスできるのは、認可された行のみになります。 |
|
行のデータを操作できるかどうかを決定します。このオプションがアクティブな場合に施行されます。 |
||
図3-8「書込みアクセス権のラベル評価プロセス」に示した書込みアクセスのアルゴリズムに従って、INSERT操作にポリシーの施行を適用します。 |
||
図3-8「書込みアクセス権のラベル評価プロセス」に示した書込みアクセスのアルゴリズムに従って、DELETE操作にポリシーの施行を適用します。 |
||
図3-8「書込みアクセス権のラベル評価プロセス」に示した書込みアクセスのアルゴリズムに従って、行内のデータ列に対するUPDATE操作にポリシーの施行を適用します。 |
||
|
すべての施行オプションを適用します。 |
|
施行オプションを適用しません。ただし、ラベル付けファンクションやSQL述語は適用できます。 |
(*) 次の3つの条件がすべて満たされている場合は、行に対するREADアクセスが認可されます(ユーザーの最小レベル) < = (データ行のレベル) < = (セッション・レベル)であること。(いずれかのデータ・グループ)が(いずれかのユーザー・グループまたは子グループ)の子であること。(すべてのデータ区分)が(ユーザーのデータ区分)にも含まれていること。図3-7「読取りアクセス権のラベル評価プロセス」を参照してください。
(**) 次の3つの条件がすべて満たされている場合は、行に対するREADアクセスが認可されます(ユーザーの最小レベル) < = (データ行のレベル) < = (セッション・レベル)であること。(いずれかのデータ・グループ)が(いずれかのユーザー・グループまたは子グループ)の子であること。(すべてのデータ区分)が(ユーザーのデータ区分)にも含まれていること。図3-7「読取りアクセス権のラベル評価プロセス」を参照してください。
HIDEポリシー構成オプションを指定できるのは、表にOracle Label Securityのポリシーを初めて適用するとき(つまり、表にポリシー列を追加するとき)です。このようにすると、ポリシーのラベルを含む列は表示されません。
ポリシーを適用した後は、DROP_COLUMNパラメータをTRUEに設定してそのポリシーを削除しないかぎり、列の非表示(または表示)ステータスは変更できません。その後は、ポリシーを新規の非表示ステータスで再適用できます。
INSERT文の場合、非表示のラベル列の値は、全列挿入には不要です。
SELECT文では、非表示のラベル列の値が自動的に戻されることはありません。この種の値は明示的に取得する必要があります。
表に対するDESCRIBEでは、ラベル列を表示できる場合と表示できない場合があります。管理者がHIDEオプションを設定すると、ラベル列は表示されなくなります。ポリシーにHIDEが指定されていない場合は、SELECTへの応答時にラベル列が表示されます。
行の挿入または更新時に書き込まれるデータ・ラベルは、3つのラベル施行オプションにより制御されます。表またはスキーマに適用されるポリシーでこれらのオプションが指定されていると、各オプションはこの項で説明される場合に適用されます。
行を挿入するユーザーは、各自のラベル認可の範囲内で任意のデータ・ラベルを指定できます。ユーザーが書き込む行のラベルを指定しない場合、LABEL_DEFAULTにより指定されます。更新はLABEL_UPDATEにより制限できます。ラベル付けファンクションを使用する挿入または更新では、データ・ラベルがユーザーの認証の範囲外に割り当てられるのを防止するため、CHECK-CONTROLが必要な場合があります。この種のラベルがあると、書き込んだ行にアクセスするのを防ぎ、データを不適切に使用可能にしてしまう可能性があります。
これらのオプションは、表に対して有効になっているラベル付けファンクションによりオーバーライドされます。ファンクション名は、表にポリシーを適用するコールで指定できます。管理者がポリシーの適用時にラベル付けファンクションに名前を指定しても、そのポリシーを無効化または削除すると、ファンクションは適用されなくなります。
更新後の行には元のラベルが使用されるため、ラベル値を指定せずに行を更新できます。ただし、ラベル付けファンクションが有効であるか、表にLABEL_DEFAULTが適用されていないかぎり、新規の行を挿入するには有効なラベルを指定する必要があります。LABEL_DEFAULTが設定されている場合は、ユーザーのセッションのデフォルト行ラベルが新規行ラベルとして使用されます。
LABEL_DEFAULTもラベル付けファンクションも有効でない場合に行のINSERTを試みると、エラーが発生します。
ラベル付けファンクションが表に対して有効になっている場合は、LABEL_DEFAULTオプションがオーバーライドされることに注意してください。
行を更新するユーザーは、通常、そのラベルを各自が認可されているラベル範囲内で変更できます。ただし、LABEL_UPDATEが適用されている場合にラベルを変更するには、WRITEUP、WRITEDOWNおよびWRITEACROSSのうち1つ以上の権限が必要です。
LABEL_UPDATEオプションでは、ラベルに影響する更新操作でのみ呼び出されるOracle AFTER行トリガーを使用します。ラベル付けファンクションが表に対して有効になっている場合は、LABEL_UPDATEオプションがオーバーライドされることに注意してください。
挿入または更新される行がラベル付けファンクションからラベルを取得する場合、そのラベルはユーザーの認証の範囲外になり、以降、そのユーザーがアクセスできなくなる可能性があります。
CHECK_CONTROLが設定されている場合は、新規ラベルにREAD_CONTROLが適用され、このユーザーが操作後も挿入または更新された行の読取りを認可されることが保証されます。設定されていない場合は、INSERTまたはUPDATE操作が取り消され、無効になります。
つまり、行に施行されているポリシーにオプションとしてCHECK_CONTROLが含まれている場合、その行を変更するユーザーは操作後も引き続き行にアクセスできる必要があります。CHECK_CONTROLがあると、ユーザーまたはラベル付けファンクションは、アクセスを禁止されているレベル、グループまたは区分を含めるために行ラベルを変更できなくなります。
CHECK_CONTROLにより、表に対して有効になっているラベル付けファンクションがオーバーライドされることに注意してください。
アクセス制御オプションは、SELECT、UPDATE、INSERTまたはDELETE操作のためにアクセスできる行を、ラベルが設定済のポリシーを満たしている行のみに制限します。
READ_CONTROLでは、図3-7「読取りアクセス権のラベル評価プロセス」のように、Oracleの仮想プライベート・データベース(VPD)テクノロジを使用して、読取りアクセス調整アルゴリズムが施行されます。
READ_CONTROLにより、SELECT、UPDATEおよびDELETE操作のためにセッションでアクセスできるレコードのセットが制限されます。READ_CONTROLがアクティブでない場合は、ポリシーで保護されている表の行にもすべてのユーザーがアクセスできます。
WRITE_CONTROLでは、図3-8「書込みアクセス権のラベル評価プロセス」のように、OracleのAFTER行トリガーを使用して、書込みアクセス調整アルゴリズムが施行されます。WRITE_CONTROLオプションを指定してOracle Label Securityのポリシーを表に適用すると、トリガーが生成されてアルゴリズムが施行されます。
WRITE_CONTROLをオンにしても、LABEL_UPDATEを指定しなければ、ユーザーはデータとラベルの両方を変更できます。行ラベルの更新を制御する必要がある場合は、ポリシーの作成時にWRITE_CONTROLのみでなくLABEL_UPDATEオプションも指定してください。
この3つのオプションでは、図3-8「書込みアクセス権のラベル評価プロセス」に示した書込みアクセスのアルゴリズムに従って、行内のデータ列に対する対応する操作にポリシーの施行を適用します。
WRITE_CONTROLを指定すると、すべてのINSERT、UPDATEおよびDELETE操作が制限されます。ただし、次の例外があります。
INSERT_CONTROLを指定すると、INSERTは制限されますが、UPDATEやDELETEは制限されません。
UPDATE_CONTROLを指定すると、UPDATEは制限されますが、INSERTやDELETEは制限されません。
DELETE_CONTROLを指定すると、DELETEは制限されますが、INSERTやUPDATEは制限されません。
関連項目: INSERTについては、「ポリシー・オプションとラベル付けファンクションを使用したラベル付きデータの挿入」を参照してください。UPDATEについては、「ポリシー・オプションとラベル付けファンクションを使用したラベル付きデータの更新」を参照してください。 DELETEについては、「ポリシー・オプションとラベル付けファンクションを使用したラベル付きデータの削除」を参照してください。 |
ALL_CONTROLではすべてのラベル管理およびアクセス制御施行オプションが適用されますが、NO_CONTROLではどちらも適用されません。どちらの場合も、ラベル付けファンクションとSQL述語は適用できます。ALL_CONTROLオプションはコマンドラインでのみ使用できることに注意してください。
NO_CONTROLを指定してポリシーを適用すると、表にポリシーのラベル列が追加されますが、ラベル値はNULLになります。アクセス制御は表には機能しないため、必要に応じてラベルの入力に進むことができます。その後、必要なポリシー施行オプションを設定できます。
NO_CONTROLオプションは、データに適切にラベル付けするラベル付けファンクションが有効になっているが、ユーザー全員がすべてのデータにアクセスできるようにする必要がある場合に役立ちます。
スキーマまたは表に対するポリシーの施行をカスタマイズするには、Oracle Enterprise Managerを使用する方法(第4章および第7章を参照)とSA_POLICY_ADMINパッケージを使用する方法(第8章を参照)があります。
この項では、サポートされるキーワードについて説明します。
ポリシーの作成時にデフォルト・オプションの文字列を指定すると、スキーマまたは表オプションが指定されていないポリシーの適用時に使用できることに注意してください。
表にポリシーを適用してから、その表を含むスキーマに適用しても、表に対するオプションはスキーマ・ポリシーの影響を受けません。表に最初に適用されたポリシーのオプションが引き続き有効となります。
一般に、管理者はLABEL_DEFAULTポリシー・オプションを使用します。これにより、ユーザーによって書き込まれたデータは、そのユーザーの行ラベルでラベル付けされます。または、ラベル付けファンクションを使用してデータにラベル付けできます。この2つの選択肢のいずれも使用されていない場合、ラベルをすべてのINSERT文で指定する必要があります。(更新では行の元のラベルが保持されます。)
次の表に、Oracle Label Securityのポリシーを実装する場合に役立つポリシー施行オプションの組合せを示します。この表のように、通常はREAD_CONTROLおよびWRITE_CONTROLを施行し、複数の可能な組合せの中から選択して書込み時のデータ・ラベルを設定します。
表9-4 ポリシー施行オプションの組合せ案
Oracle Label Securityは、ダイレクト・パス・エクスポート中には施行されません。
設計上、Oracle Label SecurityのポリシーはスキーマSYS内のオブジェクトには適用できません。したがって、SYSユーザーとDBA権限でデータベースに接続するユーザー(CONNECT AS SYSDBA
など)によるアクションには、Oracle Label Securityのポリシーは適用されません。DBAは、データベースを管理できる必要があります。Oracle Label Securityのポリシーが適用されているため、表の一部のエクスポートなどを行っても意味がありません。そのため、データベース・ユーザーSYSは、エクスポート・モード、つまりデータベースからのデータ抽出にアプリケーションを使用するかユーティリティを使用するかに関係なく、Oracle Label Securityの施行から常に除外されます。
同様に、直接またはデータベース・ロールを通じてEXEMPT ACCESS POLICY権限を付与されたデータベース・ユーザーは、データベースへのアクセスやそのデータの更新に使用されるエクスポート・モード、アプリケーションまたはユーティリティにかかわらず、READ_CONTROLやCHECK_CONTROLなどの一部のOracle Label Securityポリシーの強制制御から除外されます。表9-2「ポリシー強制オプション」を参照してください。次のポリシー強制オプションは、EXEMPT ACCESS POLICYが付与されている場合も有効です。
INSERT_CONTROL、UPDATE_CONTROL、DELETE_CONTROL、WRITE_CONTROL、LABEL_UPDATEおよびLABEL_DEFAULT。
Oracle Label SecurityのポリシーでALL_CONTROLオプションが指定されている場合は、READ_CONTROLとCHECK_CONTROLを除くすべての施行制御が適用されます。
EXEMPT ACCESS POLICYはきわめて強力な権限であり、慎重に管理する必要があります。
この権限は、SELECT、INSERT、UPDATE、DELETEなどの標準のOracle Databaseオブジェクト権限の強制に影響しません。これらの権限は、ユーザーがEXEMPT ACCESS POLICY権限を付与されている場合にも施行されます。
アプリケーション開発者は、ラベル付けファンクションを作成できます。この種のプログラムでは、コンテキスト変数(日付やユーザー名)およびデータ値など、リソースの様々な配列を使用し、ラベルを計算して戻すことができます。
次の各項では、ラベル付けファンクションの使用方法について説明します。
挿入または更新対象のデータにラベルを付けるには、次の3つの方法があります。
表へのINSERTまたはUPDATEごとにラベルを明示的に指定します。
LABEL_DEFAULTオプションを設定します。これにより、INSERT文またはUPDATE文に明示的な行ラベルが含まれていない場合は、セッションの行ラベルが使用されます。
ラベル付けファンクションを作成します。これは、INSERT文またはUPDATE文ごとに、ユーザーの認証から独立して自動的にコールされます。
データのラベル付けルールを実装できるように、ラベル付けファンクションを作成するアプローチをお薦めします。ラベル付けファンクションを指定すると、Oracle Label Securityでは、ラベルが計算されるように、そのファンクションのコールがINSERTおよびUPDATEトリガーに埋め込まれます。
たとえば、ラベル付けファンクションmy_label
を作成し、新規行のうちCOL1およびCOL2の内容を使用し、行に該当するラベルを計算して戻します。これにより、INSERT文またはUPDATE文に次の参照を挿入できます。
my_label(:new.col1,:new.col2)
J
ラベル付けファンクションを指定しない場合は、LABEL_DEFAULTオプションを指定します。どちらも使用しない場合は、各INSERT文またはUPDATE文でラベルを明示的に指定する必要があります。
ラベル付けファンクションを使用すると、アプリケーション・コンテキストから得られる情報をラベル割当てルールで考慮できます。たとえば、ユーザーが連結されているIPアドレスをラベル付けの考慮点として使用できます。この方法では、様々な場合にSYS_CONTEXTを使用できます。
ラベル付けファンクションにより、LABEL_DEFAULTおよびLABEL_UPDATEオプションがオーバーライドされます。
ラベル付けファンクションは、BEFORE行トリガーのコンテキスト内でコールされます。これにより、データ・レコードの新旧の値と新旧のラベルを渡すことができます。
ラベル付けファンクションは、ユーザーが明示的なラベルを渡すことができるように構成できます。
すべてのラベル付けファンクションは、戻り値の型をLBACSYS.LBAC_LABELデータ型にする必要があります。TO_LBAC_DATA_LABELファンクションを使用すると、ラベルを文字列書式からLBACSYS.LBAC_LABEL型に変換できます。LBACSYSには、ラベル付けファンクションに対するEXECUTE権限が必要であることに注意してください。ラベル付けファンクションの所有者は、GRANTオプションでTO_LBAC_DATA_LABELファンクションに対するEXECUTE権限を付与されている必要があります。
注意: LBACSYSは、Oracle Label Securityに不透明型を提供する一意のスキーマです。詳細は、第14章「Oracle Label SecurityでのDBAファンクションの実行」を参照してください。 |
SQL> CREATE OR REPLACE FUNCTION sa_demo.gen_emp_label (Job varchar2, Deptno number, Total_sal number) Return LBACSYS.LBAC_LABEL as i_label varchar2(80); Begin /************* Determine Class Level *************/ if total_sal > 2000 then i_label := 'L3:'; elsif total_sal > 1000 then i_label := 'L2:'; else i_label := 'L1:'; end if; /************* Determine Compartment *************/ IF Job in ('MANAGER','PRESIDENT') then i_label := i_label||'M:'; else i_label := i_label||'E:'; end if; /************* Determine Groups *************/ i_label := i_label||'D'||to_char(deptno); return TO_LBAC_DATA_LABEL('human_resources',i_label); End; /
注意: Oracle Label SecurityがOracle Internet Directoryで直接動作するように構成されている場合、ラベルはOracle Internet Directoryでolsadmintoolコマンドを使用して集中管理されるため、動的ラベル生成は無効になります。付録B「Oracle Internet Directoryを使用したLabel Security用コマンドライン・ツール」を参照してください。このため、ラベル・ファンクションがOracle Internet Directoryでまだ設定されていない文字列値を使用してデータ・ラベルを生成する場合は、エラー・メッセージが表示されます。 |
次の例では、前項の例のsa_demo.gen_emp_labelを使用してラベル付けファンクションの指定方法を示します。
sa_policy_admin.remove_table_policy('human_resources','sa_demo','emp'); sa_policy_admin.apply_table_policy (
POLICY_NAME => 'human_resources', SCHEMA_NAME => 'sa_demo', TABLE_NAME => 'emp', TABLE_OPTIONS => 'READ_CONTROL,WRITE_CONTROL,CHECK_CONTROL', LABEL_FUNCTION => 'sa_demo.gen_emp_label(:new.job,:new.deptno,:new.sal)', PREDICATE => NULL);
この項では、施行オプションとラベル付けファンクションがラベル付きデータの挿入に与える影響について説明します。
認可に基づいてデータの挿入または更新を試みた場合、その結果はアクティブになっているポリシー施行制御に応じて異なります。
INSERT_CONTROLがアクティブな場合、挿入できるのは書込み認可の範囲内でラベルが付いている行のみです。読み取れるが書込み認可が与えられていないデータの更新を試みると、エラーが発生します。たとえば、区分AおよびBを読み取ることができても、書き込めるのが区分Aのみであれば、区分Bを指定してデータの挿入を試みると文は失敗します。
INSERT_CONTROLがアクティブでない場合は、挿入する行で任意の有効なラベルを使用できます。
CHECK_CONTROLオプションがアクティブな場合は、ラベルがラベル付けファンクションにより生成される場合も、挿入できるのは読取りが認可されているラベル付きの行のみです。
ラベル付けファンクションは、ユーザーが入力するラベルより優先されます。管理者が自動ラベル付けファンクションを設定している場合、ユーザーが入力したデータ・ラベルは無効です(ラベル付けファンクション自体でユーザーが提案したラベルを使用する以外)。新規の行ラベルは、常にアクティブなラベル付けファンクション(存在する場合)により決定されます。
ラベル付けファンクションでは、挿入する行のラベルを、その行を書き込むユーザーが表示できる範囲外の値に設定できることに注意してください。このようなファンクションが使用されている場合、ユーザーは行を挿入できますが、その行の表示は認可されません。この状況は、ポリシーにCHECK_CONTROLオプションを指定することで防止できます。このオプションがアクティブな場合、新規のデータ・ラベルはユーザーの読取り認可と比較チェックされ、読取り認可がなければユーザーは挿入を実行できません。
親表が宣言参照整合性によって保護されている場合、子行の挿入は、親行が表示可能であるという要件によって制約されます。ユーザーは、挿入操作を成功させるには親行を参照できる必要があります。つまり、ユーザーには親行に対する読取りアクセス権が必要です。
親表に対するREAD_CONTROLがアクティブになっている場合、ユーザーには親行に対するSELECT操作を認可できるだけの読取り認可が必要です。たとえば、部門20を読み取ることができないユーザーは、部門20の子行を挿入できません。ユーザーが表またはスキーマに対するFULLまたはREAD権限を持っている場合は、すべてのレコードが参照可能になることに注意してください。
Oracle Label Securityでの更新ルールは、ユーザーがその行を変更する認可を受けているかぎり、挿入の場合とほとんど同じです。この項には、次の項目が含まれます。
行のラベルをSENSITIVEからCONFIDENTIALに変更する必要がある場合は、次のようにCHAR_TO_LABELファンクションを使用できます。
UPDATE emp SET hr_label = char_to_label ('HR', 'CONFIDENTIAL') WHERE ename = 'ESTANTON';
認可に基づいてデータの更新を試みた場合、その結果はアクティブになっている施行制御に応じて異なります。
UPDATE_CONTROLがアクティブな場合、更新できるのは書込み認可の範囲内のラベルが付いている行のみです。読取りはできても書込みの認可が与えられていないデータを更新しようとすると、エラーが発生します。たとえば、区分AおよびBを読み取ることができても、書き込めるのは区分Aのみであるとします。この場合、区分Bを指定してデータの更新を試みると、文は失敗します。
UPDATE_CONTROLがアクティブでない場合は、読取りアクセス権を持っているすべての行を更新できます。
LABEL_UPDATEがアクティブな場合、ラベルを、機密性レベルの上げ下げ、あるいはグループまたは区分の変更によって変更するには、適切な権限(WRITEUP、WRITEDOWNまたはWRITEACROSS)が必要です。
LABEL_UPDATEがアクティブでなく、UPDATE_CONTROLがアクティブである場合は、書込み認可の範囲内の新しいラベル値にラベルを更新できます。
ラベル付けファンクションは、ユーザーが入力するラベルより優先されます。管理者が自動ラベル付けファンクションを設定している場合、ユーザーが入力したラベルは無効です(ラベル付けファンクション自体でユーザーが提案したラベルを使用する以外)。新規の行ラベルは、常にアクティブなラベル付けファンクション(存在する場合)により決定されます。
セキュリティ管理者は、更新する行のラベルをユーザーが表示できる範囲外の値に設定するように、ラベル付けファンクションを設定できることに注意してください。この場合、ユーザーは行を更新できますが、その行の表示を認可されません。CHECK_CONTROLオプションがオンに設定されている場合、このような更新は実行できません。CHECK_CONTROLオプションでは、新規ラベルに対する読取り認可が検証されます。
参照整合性制約を持つ表に子行がある場合、正常に更新するには、親行が表示可能である(つまり、ユーザーが親行を参照できる)必要があります。親表のREAD_CONTROLがオンになっている場合、ユーザーは、親行に対するSELECTが認可されるだけの読取り認可を持っている必要があります。
たとえば、親表の部門20を読み取ることができないユーザーは、従業員の部門を子表で部門20に更新することはできません。(ユーザーがFULLまたはREAD権限を持っている場合は、すべてのレコードが参照可能です。)
関連項目: 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』 |
DELETE_CONTROLがアクティブでない場合、削除できるのは読取り可能な行のみです。
DELETE_CONTROLがアクティブで、宣言参照整合性がカスケード削除で定義されている場合は、削除するすべての行に対する書込み認可が必要で、認可がない場合は文が失敗します。
子行が連結されている親行は、書込み認可に関係なく削除できません。この種の親行を削除するには、先に子行をそれぞれ削除する必要があります。DELETE_CONTROLがアクティブになっている子行が1つでもある場合、子行を削除するには書込み権限が必要です。
たとえば、ユーザーがUNCLASSIFIEDで、次の3行がある場合を考えます。
行 | 表 | 機密性 |
---|---|---|
親行: | DEPT | UNCLASSIFIED |
子行: | EMP | UNCLASSIFIED |
子行: | EMP | UNCLASSIFIED |
この場合、UNCLASSIFIEDユーザーは親行を削除できません。
DELETE_RESTRICTがアクティブな場合、DELETE_CONTROLは無効です。DELETE_RESTRICTは常に施行されます。ユーザーの認証とデータのラベルによっては、行に子行がないように見えるのに、実際には子行があり、ユーザーはそれを参照できない場合があります。子行を参照できなくても、そのユーザーは親行を削除できません。
関連項目: 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』 |
SQL述語を使用すると拡張性が得られ、データ・アクセス・ルールを選択的に施行できます。
この項には、次の項目が含まれます。
SQL述語は、オプションのANDまたはORで始まる条件です。READ_CONTROLアクセス調整用に追加できます。たとえば、次の述語は、COL1に基づくアプリケーション固有のテストを追加して、セッションにその行へのアクセス権があるかどうかを判断します。
AND my_function(col1)=1
ポリシーとユーザー指定の述語を組み合せた結果により、ユーザーが読み取れるラベルが制限されます。したがって、この組合せはCHECK_CONTROLによりユーザーが変更を許可されるラベルとデータに影響することになります。たとえば、OR句を使用すると、ユーザーが読み取れる行数が増えます。
SQL述語が役立つのは、ラベルベースのフィルタリングの実行を回避する必要がある場合です。ある種の状況では、SQL述語を使用すると表に行レベルのセキュリティを簡単に実装できます。SQL述語をREAD_CONTROLのかわりに使用すると、SELECT、UPDATEおよびDELETE操作の対象データにフィルタが適用されます。
同様に、通常、Web対応の人事管理アプリケーションでは、従業員表の行にアクセスするユーザーはマネージャであることが必要です。このような場合、ユーザー・ラベルは従業員の行のラベルを支配する必要があります。次のようなSQL述語を追加すると、従業員は従業員表内で各自のレコードを表示する必要がある場合に、ラベルベースのフィルタリングをバイパスできます。(OR
は、ラベル・ポリシーが適用されるか、またはこの文が適用されるようにするために使用されます。)
OR SYS_CONTEXT ('USERENV', 'SESSION_USER') = employee_name
この述語により、各従業員が自分のレコードにアクセスできるように、アクセス制御を追加できます。
この種の述語をREAD_CONTROLと併用するか、READ_CONTROLが実装されていない場合にもスタンドアロン述語として使用できます。
Oracle Label Securityのポリシーを使用して表に適用された述語は、他のOracle Label SecurityのポリシーまたはOracleのファイングレイン・アクセス・コントロール/VPDポリシーにより適用できる他の述語に追加されます。各述語は、まとめてANDされます。
SCOTTスキーマにあるEMP表に次の述語が適用されているとします。
deptno=10
など、Oracle VPDポリシーにより生成された述語
label=100
など、次のようなユーザー指定述語とともにOracle Label Securityのポリシーにより生成されたラベルベースの述語
OR SYS_CONTEXT ('USERENV', 'SESSION_USER') = ename
正: これらの述語は、次のようにまとめてANDされます。
WHERE deptno=10 AND (label=100 OR SYS_CONTEXT ('USERENV', 'SESSION_USER') = ename)
誤: 述語は次の方法では結合されません。
WHERE deptno=10 AND label=100 OR SYS_CONTEXT ('USERENV', 'SESSION_USER') = ename