LBAC 保護データの更新

LBAC 信用証明情報が、データへの書き込みアクセスを許可していなければ、データを更新することはできません。 保護された行を更新する場合、LBAC 信用証明情報が行への読み取りアクセスも許可していなければなりません。

保護された列の更新

保護された列にあるデータの更新を試行する際、LBAC 信用証明情報はその列を保護するセキュリティー・ラベルと比較されます。 行われる比較は書き込みアクセスに対するものです。 書き込みアクセスがブロックされる場合にはエラーが戻され、ステートメントは失敗します。ブロックされない場合、更新は継続します。

LBAC 信用証明情報がセキュリティー・ラベルと比較される方法の詳細は、LBAC セキュリティー・ラベルの比較方法に関するトピックで説明されています。

例:

列 DEPTNO がセキュリティー・ラベル L2 により保護され、列 PAYSCALE がセキュリティー・ラベル L3 により保護される表 T1 があると想定します。 T1 (そのデータを含む) は次のようになります。

表 1. 表 T1
EMPNO LASTNAME
DEPTNO

L2
PAYSCALE

L3 によって保護されている
1 Rjaibi 11 4
2 Miller 11 7
3 Bird 11 9
ユーザー Lhakpa には LBAC 信用証明情報がありません。 Lhakpa は次の SQL ステートメントを発行します。
UPDATE T1 SET EMPNO = 4 
   WHERE LASTNAME = "Bird"

このステートメントは、保護された列を更新しないため、エラーなく実行されます。 T1 は次のようになります。

表 2. 更新後の表 T1
EMPNO LASTNAME
DEPTNO

L2
PAYSCALE

L3 によって保護されている
1 Rjaibi 11 4
2 Miller 11 7
4 Bird 11 9
Lhakpa は今度は次の SQL ステートメントを発行します。
UPDATE T1 SET DEPTNO = 55 
   WHERE LASTNAME = "Miller"

DEPTNO は保護されていて Lhakpa には LBAC 信用証明情報がないため、このステートメントは失敗し、エラーが戻されます。

Lhakpa に LBAC 信用証明情報が付与されていて、それが以下の表で要約されているアクセスを許可すると想定します。 それらの信用証明情報がどんなもので、セキュリティー・ラベルにどんなエレメントが入っているかは、この例では重要ではありません。

データを保護しているセキュリティー・ラベル 読み取りの可否 書き込みの可否
L2 いいえ はい
L3 いいえ いいえ
Lhakpa は次の SQL ステートメントを再度発行します。
UPDATE T1 SET DEPTNO = 55 
   WHERE LASTNAME = "Miller"

今度は、Lhakpa の LBAC 信用証明情報が、列 DEPTNO を保護しているセキュリティー・ラベルにより保護されるデータへの書き込みを許可しているため、ステートメントはエラーなく実行されます。 その同じ列から読み取りができないことは関係ありません。 T1 のデータは次のようになります。

表 3. 2 回目の更新後の表 T1
EMPNO LASTNAME
DEPTNO

L2
PAYSCALE

L3 によって保護されている
1 Rjaibi 11 4
2 Miller 55 7
4 Bird 11 9
今度は Lhakpa は次の SQL ステートメントを発行します。
UPDATE T1 SET DEPTNO = 55, PAYSCALE = 4 
   WHERE LASTNAME = "Bird"

列 PAYSCALE はセキュリティー・ラベル L3 により保護され、Lhakpa の LBAC 信用証明情報は Lhakpa がその列に書き込むことを許可しません。 Lhakpa はその列に書き込むことができないため、更新は失敗し、データは変更されません。

保護された行の更新

ユーザーの LBAC 信用証明情報が、ある行の読み取りを許可していない場合には、そのユーザーにとってはその行は存在していないかのようになるため、そのユーザーがその行を更新する方法はありません。 読み取ることができる行においては、その更新を行うためには、行への書き込みもできなければなりません。

行の更新を試行する際、書き込み用の LBAC 信用証明情報はその行を保護するセキュリティー・ラベルと比較されます。 書き込みアクセスがブロックされる場合、更新は失敗し、エラーが戻されます。 書き込みアクセスがブロックされない場合には、更新は継続します。

実行される更新は、Db2SECURITYLABEL のデータ・タイプを持つ列の処理を除き、無保護の行への更新と同様に行われます。 その列の値を明示的に設定しない場合、そこには書き込みアクセス用に保持しているセキュリティー・ラベルが自動的に設定されます。 書き込みアクセス用のセキュリティー・ラベルを持っていない場合、エラーが戻され、ステートメントは失敗します。

更新で Db2SECURITYLABEL のデータ・タイプを持つ列を明示的に設定した場合には、LBAC 信用証明情報は再度チェックされます。 実行しようとしている更新で、現行の LBAC 信用証明情報では書き込みが許可されない行が作成されることになる場合の処理は、表を保護しているセキュリティー・ポリシーによって異なります。 セキュリティー・ポリシーに RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL オプションがある場合は、更新が失敗し、エラーが戻されます。 セキュリティー・ポリシーに RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL オプションがない場合や、代わりに OVERRIDE NOT AUTHORIZED WRITE SECURITY LABEL オプションがある場合は、指定したセキュリティー・ラベルが無視され、書き込みアクセス用に保持しているセキュリティー・ラベルがあれば、そのセキュリティー・ラベルが代わりに使用されます。 書き込みアクセス用のセキュリティー・ラベルを保持していない場合は、エラーが戻されます。

例:

表 T1 が、P1 という名前のセキュリティー・ポリシーにより保護され、データ・タイプが Db2SECURITYLABEL である LABEL という名前の列を持つと想定します。

T1 (そのデータを含む) は次のようになります。
表 4. 表 T1
EMPNO LASTNAME DEPTNO ラベル
1 Rjaibi 11 L1
2 Miller 11 L2
3 Bird 11 L3

ユーザー Jenni は、セキュリティー・ラベル L0 および L1 により保護されるデータへの読み取りおよび書き込みを許可するものの、他のセキュリティー・ラベルにより保護されるデータに対する読み取りおよび書き込みは許可しない LBAC 信用証明情報を持っていると想定します。 Jenni が読み取りおよび書き込み両方のために保持しているセキュリティー・ラベルは L0 です。 Jenni の信用証明情報全体の詳細、およびラベルにどんなエレメントが入っているかは、この例では重要ではありません。

Jenni は次の SQL ステートメントを発行します。
SELECT * FROM T1
Jenni の表には 1 行だけ表示されます。
表 5. Jenni の SELECT 照会の結果
EMPNO LASTNAME DEPTNO ラベル
1 Rjaibi 11 L1

ラベル L2 および L3 により保護される行は結果セットには組み込まれません。なぜなら Jenni の LBAC 信用証明情報は、これらの行の読み取りを Jenni に許可しないからです。 Jenni にとっては、これらの行は存在していないかのようになります。

Jenni は以下の SQL ステートメントを発行します。
UPDATE T1 SET DEPTNO = 44 WHERE DEPTNO = 11;
SELECT * FROM T1;
照会により戻される結果セットは、以下のようになります。
表 6. Jenni の UPDATE & SELECT 照会の結果
EMPNO LASTNAME DEPTNO ラベル
1 Rjaibi 44 L0
表の実際のデータは次のようになります。
表 7. 表 T1
EMPNO LASTNAME DEPTNO ラベル
1 Rjaibi 44 L0
2 Miller 11 L2
3 Bird 11 L3

ステートメントはエラーなく実行されましたが、最初の行のみが影響を受けました。 2 番目および 3 番目の行を Jenni は読み取ることができないため、それらの行が WHERE 節の条件を満たす場合であっても、それらはステートメントによる更新で選択されません。

LABEL 列が UPDATE ステートメントで明示的に設定されていなかったにもかかわらず、更新された行のその列の値が変更されたことに注目してください。 その列には、Jenni が書き込み用に保持しているセキュリティー・ラベルが設定されます。

今度は Jenni は、どのセキュリティー・ラベルによって保護されるデータへの読み取りをも許可する LBAC 信用証明情報が付与されます。 Jenni の書き込み用 LBAC 信用証明情報は変更されません。 依然として、Jenni は L0 および L1 により保護されるデータのみに書き込むことができます。

Jenni は再度次の SQL ステートメントを発行します。
UPDATE T1 SET DEPTNO = 44 WHERE DEPTNO = 11

今度は、2 番目と 3 番目の行のために更新は失敗します。 Jenni はそれらの行の読み取りができるため、それらはステートメントによる更新で選択されます。 しかし、それらはセキュリティー・ラベル L2 および L3 により保護されているため、Jenni はそれらに書き込むことはできません。 更新は行われず、エラーが戻されます。

Jenni はここで次の SQL ステートメントを発行します。

UPDATE T1 
 SET DEPTNO = 55, LABEL = SECLABEL_BY_NAME( 'P1', 'L2' ) 
 WHERE LASTNAME = "Rjaibi"

ステートメント内の SECLABEL_BY_NAME 関数は、L2 という名前のセキュリティー・ラベルを戻します。 Jenni は、最初の行を保護するセキュリティー・ラベルの明示的設定を試行します。 Jenni の LBAC 信用証明情報は、最初の行の読み取りを許可するため、その行は更新のために選択されます。 Jenni の LBAC 信用証明情報は、セキュリティー・ラベル L0 により保護されている行への書き込みを許可するため、Jenni はその行を更新することが許可されます。 しかし、Jenni の LBAC 信用証明情報は、セキュリティー・ラベル L2 により保護されている行への書き込みを許可しないため、Jenni は列 LABEL にその値を設定することは許可されません。 ステートメントは失敗し、エラーが戻されます。 その行内の列は更新されません。

Jenni はここで次の SQL ステートメントを発行します。

UPDATE T1 SET LABEL = SECLABEL_BY_NAME( 'P1', 'L1' ) WHERE LASTNAME = "Rjaibi"

Jenni はセキュリティー・ラベル L1 により保護されている行への書き込みができるため、ステートメントは成功します。

T1 は次のようになります。
表 8. 表 T1
EMPNO LASTNAME DEPTNO ラベル
1 Rjaibi 44 L1
2 Miller 11 L2
3 Bird 11 L3

保護された列を含む保護された行の更新

保護された行を持つ表内の保護された列の更新を試行する場合には、LBAC 信用証明情報は、更新による影響を受けるすべての保護された列の書き込みを許可していなければなりません。それ以外の場合、更新は失敗し、エラーが戻されます。 これは、保護された列の更新に関する前のセクションで説明されているとおりです。 更新による影響を受けるすべての保護された列の更新が許可されている場合でも、LBAC 信用証明情報が読み取りおよび書き込みの両方を許可する行しか更新できません。 これは、保護された行の更新に関する前のセクションで説明されているとおりです。 Db2SECURITYLABEL のデータ・タイプを持つ列の処理は、保護された列が更新による影響を受けるかどうかに関わりなく同じです。

Db2SECURITYLABEL のデータ・タイプを持つ列がそれ自体保護された列である場合には、LBAC 信用証明情報は、その列への書き込みを許可しなければなりません。そうでない場合、その表のどの行も更新できません。