| Oracle® Label Security管理者ガイド 12cリリース1 (12.1) E56367-02 |
|
 前 |
 次 |
Oracle Label Security ポリシーの強制をカスタマイズし、ラベル付けファンクションを実装できます。
内容は次のとおりです。
Oracle Label Securityでは、一連のポリシー強制オプションを提供します。
内容は次のとおりです。
管理者は、Oracle Label Securityで使用可能なすべての施行制御オプションから、特定のアプリケーションのニーズを満たすオプションを選択する必要があります。
これは、公開、変更または誤用に対するデータの機密性レベルを識別することの他、この種のデータへのアクセスや変更が必要なユーザー、またはその権限を持つユーザーを識別することを意味します。ポリシー施行オプションを使用すると、管理者はユーザーがデータまたはラベルの読取りや書込みができるかどうかを詳細にチューニングできます。
ポリシー、スキーマおよび表のポリシー強制のレベルを設定できます。
表8-1に、ポリシー強制オプションが機能できるレベルを示します。
表8-1 ポリシー施行オプションが有効な場合
| オプションの設定レベル | このレベルで設定されたオプションがユーザー操作に影響する場合 |
|---|---|
ポリシー・レベル |
... ポリシーが表またはスキーマに適用されている場合のみ |
スキーマ・レベル |
... ユーザーがこのスキーマで操作する場合 |
表レベル |
... ユーザーがこの表で操作する場合 |
表またはスキーマにポリシーを適用する場合は、その表またはスキーマの使用を制限する施行オプションを指定できます。適用時に施行オプションを指定しなければ、そのポリシーの作成時に指定したデフォルトの施行オプションが自動的に使用されます。
これらのオプションにより、ポリシーの強制はREADアクセス、WRITEアクセスおよびラベル変更に関するセキュリティ要件に合せてカスタマイズされます。また、ラベル列を表示するか非表示にするかも指定できます。保護されている表については、必要なポリシー・オプションのみを指定して一部またはすべてを施行するように選択できます。
オプションで、各表にラベル付けファンクションを割り当てることができます。これにより、その表で挿入または更新される行のラベルが決まります。オプションで、表のSQL述語を指定して、ラベルに基づいてユーザーがアクセス可能な行を制御できます。
関連項目:
Oracle Label Securityのポリシー施行オプションを適用すると、表示、挿入、更新または削除のためにアクセスできる行が制御されます。
Oracle Label Securityでは、3つのカテゴリ(ラベル管理オプション、アクセス制御オプションおよびオーバーライド・オプション)を使用して、ポリシーを強制します。
表8-2に、ポリシー強制オプションのカテゴリを示します。
ラベル管理オプションは、挿入または更新される行に書き込まれるデータ・ラベルが、そのラベルに対して設定されているポリシーに違反しないことを保証します
アクセス制御オプションは、SELECT、UPDATE、INSERTまたはDELETE操作で、ラベルが設定済ポリシーを満たしている行のみにアクセスできることを保証します。
オーバーライド・オプションは、他のすべての強制オプションを一時停止または適用できます。
表8-2 ポリシー施行オプション
| 施行のタイプ | オプション | 説明 |
|---|---|---|
|
ユーザーが |
|
- |
|
ポリシーの強制は、行に連結されたラベルの値を設定または変更する |
- |
|
新規の行ラベルが読取りアクセス可能になるように、 |
|
すべての問合せにポリシーの施行を適用します。 |
|
- |
|
行のデータを |
- |
|
「Oracle Label Securityの読取りアクセス・アルゴリズムの動作」の図に示した書込みアクセスのアルゴリズムに従って、 |
- |
|
「Oracle Label Securityの読取りアクセス・アルゴリズムの動作」の図に示した書込みアクセスのアルゴリズムに従って、 |
- |
|
「Oracle Label Securityの読取りアクセス・アルゴリズムの動作」の図に示した書込みアクセスのアルゴリズムに従って、行内のデータ列に対する |
|
すべての施行オプションを適用します。 |
|
- |
|
施行オプションを適用しません。ただし、ラベル付けファンクションやSQL述語は適用できます。 |
Oracle Label Securityが表に適用される場合でも、一部のDML操作は適用されるポリシーの対象ではない場合があることに注意してください。管理者が設定するポリシー強制オプションにより、SQL処理動作と、保護された表に対する問合せに対して認可済ユーザーが実際に参照できる内容の両方が決まります。特に注記がないかぎり、この章ではALL_CONTROLがアクティブであり、すべての強制オプションが有効であることを想定します。ユーザーが認可されていない操作を実行しようとすると、エラー・メッセージが表示され、SQL文が失敗します。
Oracle Label Securityのポリシーの設計と実装で有効に使用するには、これらのポリシー施行オプションの相互関係と各オプションで制御されるSQL文を理解しておくことが重要です。
Oracle Label Securityには、一連のポリシー強制オプションがあります。
表8-3で、ポリシー強制オプション間の関係を説明します。
表8-3 ポリシー施行オプションの制御対象
| ポリシーで指定するオプション | 制御されるSQL操作 | 使用する条件とその効果 |
|---|---|---|
|
|
認可された行(*)にのみアクセスできます。 |
|
|
(a) 認可された行(**)にのみアクセスできます。 (b) |
|
- |
- |
|
|
- |
|
|
- |
|
|
- |
|
- |
新規の行ラベルが読取りアクセス可能になるように、 |
- |
すべての問合せにポリシーの施行を適用します。操作のためにアクセスできるのは、認可された行のみになります。 |
|
|
|
「Oracle Label Security監査の有効化または無効化方法」の図に示した書込みアクセスのアルゴリズムに従って、 |
|
|
「Oracle Label Security監査の有効化または無効化方法」の図に示した書込みアクセスのアルゴリズムに従って、 |
|
|
「Oracle Label Security監査の有効化または無効化方法」の図に示した書込みアクセスのアルゴリズムに従って、行内のデータ列に対する |
|
すべての施行オプションを適用します。 |
|
|
|
施行オプションを適用しません。ただし、ラベル付けファンクションやSQL述語は適用できます。 |
(*) 次の3つの条件がすべて満たされている場合は、行に対するREADアクセスが認可されます(ユーザーの最小レベル) < = (データ行のレベル) < = (セッション・レベル)であること。(いずれかのデータ・グループ)が(いずれかのユーザー・グループまたは子グループ)の子であること。(すべてのデータ区分)が(ユーザーのデータ区分)にも含まれていること。「Oracle Label Securityの読取りアクセス・アルゴリズムの動作」の図を参照してください
(**) 次の3つの条件がすべて満たされている場合は、行に対するREADアクセスが認可されます(ユーザーの最小レベル) < = (データ行のレベル) < = (セッション・レベル)であること。(いずれかのデータ・グループ)が(いずれかのユーザー・グループまたは子グループ)の子であること。(すべてのデータ区分)が(ユーザーのデータ区分)にも含まれていること。「Oracle Label Securityの読取りアクセス・アルゴリズムの動作」の図を参照してください。
Oracle Label Securityポリシー列を表に追加する際に、HIDEポリシー構成オプションを指定できます。
このようにすると、ポリシーのラベルを含む列は表示されません。
ポリシーを適用した後は、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により、SELECT、UPDATEおよびDELETE操作のためにセッションでアクセスできるレコードのセットが制限されます。
READ_CONTROLがアクティブでない場合は、ポリシーで保護されている表の行にもすべてのユーザーがアクセスできます。
READ_CONTROLでは、図3-6のように、Oracleの仮想プライベート・データベース(VPD)テクノロジを使用して、読取りアクセス調整アルゴリズムが強制されます。
WRITE_CONTROLオプションを指定してOracle Label Securityのポリシーを表に適用すると、トリガーが生成されてアルゴリズムが強制されます。
WRITE_CONTROLでは、図3-7のように、OracleのAFTER行トリガーを使用して、書込みアクセス調整アルゴリズムが強制されます。
注意:
WRITE_CONTROLの保護の実装は、どの書込み操作の場合も同じですが、すべての書込みオプションを全体に適用する必要はありません。WRITE_CONTROLのかわりに対応するポリシー強制オプション(INSERT_CONTROL、UPDATE_CONTROLおよびDELETE_CONTROL)を使用すると、WRITE_CONTROLをINSERT、UPDATEおよびDELETE操作に選択的に適用できます。
WRITE_CONTROLをオンにしても、LABEL_UPDATEを指定しなければ、ユーザーはデータとラベルの両方を変更できます。行ラベルの更新を制御する必要がある場合は、ポリシーの作成時にWRITE_CONTROLのみでなくLABEL_UPDATEオプションも指定してください。
INSERT_CONTROL、UPDATE_CONTROLおよびDELETE_CONTROLオプションは、行内のデータ列での対応する操作中にポリシー強制を制御します。
これらのオプションは、図3-7に示した書込みアクセスのアルゴリズムに従って適用されます。
WRITE_CONTROLを指定すると、すべてのINSERT、UPDATEおよびDELETE操作が制限されます。ただし、次の例外があります。
INSERT_CONTROLを指定すると、INSERTは制限されますが、UPDATEやDELETEは制限されません。
UPDATE_CONTROLを指定すると、UPDATEは制限されますが、INSERTやDELETEは制限されません。
DELETE_CONTROLを指定すると、DELETEは制限されますが、INSERTやUPDATEは制限されません。
関連項目:
挿入については、「ポリシー・オプションとラベル付けファンクションを使用したラベル付きデータの挿入」を参照してください
更新については、「ポリシー・オプションとラベル付けファンクションを使用したラベル付きデータの更新」を参照してください
削除については、「ポリシー・オプションとラベル付けファンクションを使用したラベル付きデータの削除」を参照してください
ALL_CONTROLではすべてのラベル管理およびアクセス制御強制オプションが適用されますが、NO_CONTROLではどちらも適用されません。
どちらの場合も、ラベル付けファンクションとSQL述語は適用できます。ALL_CONTROLオプションはコマンドラインでのみ使用できることに注意してください。NO_CONTROLを指定してポリシーを適用すると、表にポリシーのラベル列が追加されますが、ラベル値はNULLになります。アクセス制御は表には機能しないため、必要に応じてラベルの入力に進むことができます。その後、必要なポリシー強制オプションを設定できます。NO_CONTROLオプションは、データに適切にラベル付けするラベル付けファンクションが有効になっているが、ユーザー全員がすべてのデータにアクセスできるようにする必要がある場合に役立ちます。
Oracle Enterprise Managerによって、スキーマまたは表のポリシー強制をカスタマイズできます。
この機能は、「Oracle Label Securityポリシーの作成」で説明されています。また、「SA_POLICY_ADMINポリシー管理PL/SQLパッケージ」で説明されているSA_POLICY_ADMINパッケージを使用することもできます。
この項では、サポートされるキーワードについて説明します。
ポリシーの作成時にデフォルト・オプションの文字列を指定すると、スキーマまたは表オプションが指定されていないポリシーの適用時に使用できることに注意してください。
表にポリシーを適用してから、その表を含むスキーマに適用しても、表に対するオプションはスキーマ・ポリシーの影響を受けません。表に最初に適用されたポリシーのオプションが引き続き有効となります。
一般に、管理者はLABEL_DEFAULTポリシー・オプションを使用します。これにより、ユーザーによって書き込まれたデータは、そのユーザーの行ラベルでラベル付けされます。または、ラベル付けファンクションを使用してデータにラベル付けできます。この2つの選択肢のいずれも使用されていない場合、ラベルをすべてのINSERT文で指定する必要があります。(更新では行の元のラベルが保持されます。)
次の表に、Oracle Label Securityのポリシーを実装する場合に役立つポリシー施行オプションの組合せを示します。この表のように、通常はREAD_CONTROLおよびWRITE_CONTROLを強制し、複数の可能な組合せの中から選択して書込み時のデータ・ラベルを設定します。
表8-4 ポリシー施行オプションの組合せ案
| オプション | アクセス施行 |
|---|---|
|
セッション・ラベルに基づく読取りアクセスと書込みアクセス。デフォルト・ラベルを指定すると、ユーザーはデータとラベルの両方を挿入/更新できます。 |
|
セッション・ラベルに基づく読取りアクセスと書込みアクセス。ユーザーは、行データのみ設定/変更できます。すべての行ラベルは、ラベル付けファンクションによって明示的に設定されます。 新規ラベル(挿入または更新時)を参照可能なラベルの範囲に限定するには、 |
|
セッション・ラベルに基づく読取りアクセスと書込みアクセス。ユーザーは権限が付与されていないラベルは変更できません。 新規ラベル(挿入または更新時)を参照可能な範囲に限定するには、 |
Oracle Label Securityには、OLSポリシー強制の例外がいくつかあります。
これらの除外は次のとおりです。
Oracle Label Securityは、DIRECTパス・エクスポート中には強制されません。
設計上、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ポリシーの強制制御から除外されます。「ポリシー強制オプションのカテゴリ」を参照してください。次のポリシー強制オプションは、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権限が付与されている場合も強制されます。
関連項目:
その他のDBA関連のファンクションについては、「Oracle Label SecurityでのDBAファンクションの実行」を参照してください
ラベル付けファンクションでは、コンテキスト変数(日付やユーザー名)およびデータ値などのリソースを使用し、ラベルを計算して戻すことができます。
内容は次のとおりです。
挿入または更新対象のデータにラベルを付けるには、次の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) ラベル付けファンクションを指定しない場合は、LABEL_DEFAULTオプションを指定します。そうでない場合は、各INSERT文またはUPDATE文でラベルを明示的に指定する必要があります。
ラベル付けファンクションを使用すると、アプリケーション・コンテキストから得られる情報をラベル割当てルールで考慮できます。
たとえば、ユーザーが連結されているIPアドレスをラベル付けの考慮点として使用できます。この方法では、様々な場合にSYS_CONTEXTを使用できます。
注意:
SQL文が無効な場合は、表またはポリシーにラベル付けファンクションを適用するとエラーが発生します。表に使用する前に、ラベル付けファンクションを詳細にテストする必要があります。
ラベル付けファンクションにより、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に不透明型を提供する一意のスキーマです。詳細は、「Oracle Label SecurityでのDBAファンクションの実行」を参照してください。
CREATE OR REPLACE FUNCTION SQL文を使用して、ラベル付けファンクションを作成できます。
CREATE OR REPLACE FUNCTION文を使用してポリシーのラベル付けファンクションを作成するには、戻り値をLBACSYS.LBAC_LABELに設定します。
次に例を示します。
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コマンドを使用して集中管理されるため、動的ラベル生成は無効になります。「Oracle Internet Directoryを使用したLabel Security用コマンドライン・ツール」を参照してください。このため、ラベル・ファンクションがOracle Internet Directoryでまだ設定されていない文字列値を使用してデータ・ラベルを生成する場合は、エラー・メッセージが表示されます。
SA_POLICY_ADMINパッケージを使用して、ラベル付けファンクションを指定できます。
SA_POLICY_ADMIN.REMOVE_TABLE_POLICYおよびSA_POLICY_ADMIN.APPLY_TABLE_POLICYを使用して、ラベル付けファンクションを指定します。
次に例を示します。
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 SQL文を使用します。
次に例を示します。
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がアクティブな場合、書き込めるのは、読取り認可を受けているラベルのみです。
次の図に、LABEL_UPDATEのラベル評価プロセスを示します。
ラベル付けファンクションは、ユーザーが入力するラベルより優先されます。
管理者が自動ラベル付けファンクションを設定している場合、ユーザーが入力したラベルは無効です(ラベル付けファンクション自体でユーザーが提案したラベルを使用する以外)。新規の行ラベルは、常にアクティブなラベル付けファンクション(存在する場合)により決定されます。
セキュリティ管理者は、更新する行のラベルをユーザーが表示できる範囲外の値に設定するように、ラベル付けファンクションを設定できることに注意してください。この場合、ユーザーは行を更新できますが、その行の表示を認可されません。CHECK_CONTROLオプションがオンに設定されている場合、このような更新は実行できません。CHECK_CONTROLオプションでは、新規ラベルに対する読取り認可が検証されます。
参照整合性制約が有効になっている表に子行がある場合、更新を成功させるには、親行を表示可能にする必要があります。
つまり、このユーザーは親行を参照できる必要があります。
親表のREAD_CONTROLがオンになっている場合、ユーザーは、親行に対するSELECTが認可されるだけの読取り認可を持っている必要があります。
たとえば、親表の部門20を読み取ることができないユーザーは、従業員の部門を子表で部門20に更新することはできません。(ユーザーがFULLまたはREAD権限を持っている場合は、すべてのレコードが参照可能です。)
関連項目:
Oracle Database開発ガイド
ラベル付きデータは削除できます。
次の点に注意してください。
DELETE_CONTROLがアクティブな場合、削除できるのは書込み認可の範囲内の行のみです。
DELETE_CONTROLがアクティブでない場合、削除できるのは読取り可能な行のみです。
DELETE_CONTROLがアクティブで、宣言参照整合性がカスケード削除で定義されている場合は、削除するすべての行に対する書込み認可が必要で、認可がない場合は文が失敗します。
子行が連結されている親行は、書込み認可に関係なく削除できません。この種の親行を削除するには、先に子行をそれぞれ削除する必要があります。DELETE_CONTROLがアクティブになっている子行が1つでもある場合、子行を削除するには書込み認可が必要です。
たとえば、ユーザーがUNCLASSIFIEDで、次の3行がある場合を考えます。
| 行 | 表 | 機密性 |
|---|---|---|
親行: |
|
|
子行: |
|
|
子行: |
|
|
この場合、UNCLASSIFIEDユーザーは親行を削除できません。
DELETERESTRICTがアクティブな場合、DELETE_CONTROLは無効です。DELETERESTRICTは常に強制されます。ユーザーの認証とデータのラベルによっては、行に子行がないように見えるのに、実際には子行があり、ユーザーはそれを参照できない場合があります。子行を参照できなくても、そのユーザーは親行を削除できません。
SQL述語を使用すると拡張性が得られ、データ・アクセス・ルールを選択的に施行できます。
内容は次のとおりです。
SQL述語は、オプションのANDまたはORで始まる条件です。
SQL述語は、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 Label Securityポリシー、あるいはOracle Databaseファイングレイン・アクセス・コントロールまたはOracle Virtual Private Databaseポリシーにより適用される他の述語に追加されます。各述語は、まとめて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
