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