ラベル・ベースのアクセス制御 (LBAC) の概要

LBAC の動作

LBAC 機能は非常に構成しやすく、特定の安全保護環境と一致するように調整することができます。 すべての LBAC 構成はセキュリティー管理者 により実行されます。セキュリティー管理者は、SECADM 権限が付与されているユーザーです。

セキュリティー管理者は、セキュリティー・ラベル・コンポーネントを作成して LBAC システムを構成します。 セキュリティー・ラベル・コンポーネント は、ユーザーがデータの一部にアクセスするかどうかを判別するのに使用する基準を表すデータベース・オブジェクトです。 例えば、その基準はユーザーが特定の部門に所属しているかどうか、または特定のプロジェクトで作業しているかどうかになります。 セキュリティー・ポリシー では、どのデータに誰がアクセスできるかを判断するために使用される基準を記述します。 セキュリティー・ポリシーには、1 つ以上のセキュリティー・ラベル・コンポーネントが含まれています。 任意の 1 つの表を保護するために 1 つのセキュリティー・ポリシーしか使用できませんが、複数のセキュリティー・ポリシーを使用して複数の表を保護することができます。

セキュリティー・ポリシーを作成した後、セキュリティー管理者は、そのポリシーの一部であるセキュリティー・ラベル というオブジェクトを作成します。 セキュリティー・ラベルには、セキュリティー・ラベル・コンポーネントが含まれています。 セキュリティー・ラベルに厳密に何が含まれるかはセキュリティー・ポリシーにより決定され、特定のデータ項目にアクセスできるユーザーを決定するために組織が使用する基準を示すように構成することができます。 例えば、ある人の会社内での立場とその人がどのプロジェクトに参加しているかを参照して、その人が表示することができるデータを判断する場合には、各ラベルにその情報が含まれるようにセキュリティー・ラベルを構成することができます。 LBAC は柔軟であるため、非常に複雑な基準だけでなく、各ラベルが "high" または "low" のいずれかの信頼レベルを示すだけであるような非常に単純なシステムに至るまで、自由にセットアップできます。

作成が完了すると、セキュリティー・ラベルを表の個々の列と行に関連付けてそこに保持されているデータを保護することができます。 セキュリティー・ラベルにより保護されるデータは、保護データ と呼ばれます。 セキュリティー管理者は、ユーザーにセキュリティー・ラベルを付与することにより、保護データへのアクセスを許可します。 ユーザーが保護データへのアクセスを試行すると、そのユーザーのセキュリティー・ラベルが、データを保護しているセキュリティー・ラベルと比較されます。 セキュリティー・ラベルには、保護ラベルによってブロックされるものと、そうでないものがあります。

ユーザー、ロール、またはグループは、複数のセキュリティー・ポリシーに対する (複数の) セキュリティー・ラベルを同時に保持することが許可されています。 ただし、どのセキュリティー・ポリシーに対しても、ユーザー、ロール、またはグループは読み取りアクセス用に最大 1 つのラベル、書き込みアクセス用に最大 1 つのラベルしか保持することができません。

セキュリティー管理者はユーザーに免除を付与することもできます。 免除 があれば、本来はセキュリティー・ラベルによってアクセスできない保護データにアクセスすることができます。 セキュリティー・ラベルと免除をまとめて、LBAC 信用証明情報 といいます。

LBAC 信用証明情報がアクセスを許可しない保護列にアクセスしようとすると、アクセスは失敗し、エラー・メッセージを受け取ります。

LBAC 信用証明情報で読み取りが許可されていない保護された行を読み取ろうとすると、 Db2® はそれらの行が存在しないかのように動作します。 それらの行は、実行するすべての SQL ステートメント (SELECT、UPDATE、DELETE を含む) において、その一部として選択することはできません。 集約関数であっても、LBAC 信用証明情報が読み取りを許可しない行は無視します。 例えば、COUNT(*) 関数は、読み取りアクセスを持つ行のみのカウントを戻します。

ビューと LBAC

ビューを、無保護の表にビューを定義する際と同様に、保護された表に定義することができます。 そのようなビューにアクセスする際には、基礎表に対する LBAC 保護が施行されます。 使用される LBAC 信用証明情報は、セッション許可 ID の LBAC 信用証明情報となります。 同じビューに 2 人のユーザーがアクセスすると、それぞれの LBAC 信用証明情報により異なる行が表示される可能性があります。

参照保全制約と LBAC

LBAC を使用したストレージ・オーバーヘッド

LBAC を使用して表を行レベルで保護する場合、追加のストレージ・コストは行セキュリティー・ラベル列のコストです。 このコストは、選択したセキュリティー・ラベルのタイプによって異なります。 例えば、表を保護するために 2 つのコンポーネントを持つセキュリティー・ポリシーを作成する場合、そのセキュリティー・ポリシーからのセキュリティー・ラベルは 16 バイト (コンポーネントごとに 8 バイト) になります。 行セキュリティー・ラベル列は NULL 不可 VARCHAR 列として扱われるため、この場合の合計コストは行ごとに 20 バイトになります。 通常、行ごとの合計コストは (N*8 + 4) バイトです。ここで、N はセキュリティー・ポリシーの表を保護するコンポーネントの数です。

LBAC を使用して表を列レベルで保護する場合、列セキュリティー・ラベルはメタデータです (つまり、列のメタデータとともに SYSCOLUMNS カタログ表に格納されます)。 このメタデータは、列を保護するセキュリティー・ラベルの ID に過ぎません。 この場合、ユーザー表はストレージ・オーバーヘッドの影響を受けません。

LBAC が行わない動作

• LBAC は、任意アクセス制御により禁止されているデータへのアクセスは、決して許可しません。
  例: 表からの読み取り許可がない場合、その表からのデータの読み取りは許可されません。これは、LBAC がアクセスを許可する行および列であっても許可されます。
• LBAC 信用証明情報は、保護データへのアクセスのみを制限します。 無保護のデータへのアクセスには影響がありません。
• 表またはデータベースをドロップする場合、その表またはデータベースに保護データが含まれている場合であっても、LBAC 信用証明情報はチェックされません。
• データをバックアップする際には LBAC 信用証明情報はチェックされません。 表のバックアップを実行できる場合、どの行がバックアップされるかについて、データの LBAC 保護により制限されることはまったくありません。 また、バックアップ・メディア上のデータは LBAC により保護されません。 データベース上のデータのみが保護されます。
• LBAC は、次のタイプの表を保護するために使用することはできません。
  • ステージング表
  • ステージング表が依存する表
  • 型付き表
• LBAC 保護はニックネームには適用できません。