レベル: 中級 曽田 俊明, IT Specialist, 日本アイ・ビー・エム システムズ・エンジニアリング株式会社
2009年 02月 19日 この記事では、LBACの概要についてご紹介いたします。
はじめに
この記事では、データベースの表の行レベル、列レベルでのアクセス制御を可能にするDB2のLBAC（Label Base Access Control）機能についてご紹介いたします。この機能が有効な例を考えてみると、社員情報の入った社員表を一般社員にまで公開したいが、他の部門の社員情報まで見せる必要はない、また一般社員にまで給与情報の列をアクセスさせたくないといった要件がある場合に、行レベル、列レベルでのアクセス制御を使用して、1つの表の中でアクセスできる行や列を限定して社員情報を公開することができます。
LBAC（Label Base Access Control）とは？
これまでDB2では、表オブジェクトに対するSELECT特権やINSERT、UPDATE、DELETE特権といったオブジェクトに対する特権を使用して表単位での読み取りや書き込みの制御を行うことができました。LBACは、DB2 9からの新機能で、ラベルを使用したアクセス制御を行い、表単位よりも細かい、行レベル、列レベルでのアクセス制御を実施できます。
ラベルを使用したアクセス制御とは、図1のように、行レベルのアクセス制御の場合には、行に与えられたラベル、列レベルのアクセス制御の場合には列に与えられたラベルとユーザーに与えられたラベルを比較することで、そのユーザーがその行または列へのアクセスが可能であるかが判断されます。
図1．ラベルを使用したアクセス制御
行レベルのアクセス制御の場合には、ラベルの比較の結果アクセスできない行は存在しない行として扱われます。例えばSELECT文の条件に合致していてもその行は選択されません。
列レベルのアクセス制御の場合には、ラベルの比較の結果アクセスできない列にアクセスを試みた場合には、エラーが返されます。例えば、SELECT文の列リストにアクセスできない列を入れているとそのSQLがエラーで実行できません。
アプリケーションによるアクセス制御との違い
行レベル、列レベルのアクセス制御は、アプリケーション・ロジックで実装することでも実現可能です。例えばユーザーごとに特定の行や列をフィルタリングするようなビューを作成し、アプリケーションでユーザーを識別して特定のビューにアクセスするような仕組みを組み込みます。
このような制御をアプリケーション・ロジックで行う場合と、LBACを使用する場合の違いを考えてみます。アプリケーション・ロジックで実装した場合には、アプリケーションごとでのアクセス制御ロジックの実装が必要になります。新しいアプリケーションを使用する場合や制御ポリシーに変更があった場合には、アプリケーションごとに修正が必要になります。その他、アクセス制御を実装したアプリケーション以外のアクセスでは、アクセス制御できません。
それに対しLBACでの制御では、データベースに対して新たな制御を適用すれば、そのデータベースを利用するすべてのアプリケーションがその制御の対象となります。よって、制御ポリシーに変更があった場合でもデータベースでの変更のみでアプリケーションの修正をすることなく対応ができます。そして、いかなる経路のアクセスに対しても、アクセス制御を適用することができます。
このようにLBACを使用した方がアプリケーションでの実装に比べ実装や管理コストが少なく、堅牢なアクセス制御が実現できます。
LBACによるアクセス制御
ここでは、行レベルのアクセス制御を行う例を通して、LBACでどのようなアクセス制御が行えるかを具体的に見てみます。LBACを構成するには以下のようなステップを実行します。
そして、この例では、図2にあるような行単位でのアクセス制御を行います。TOKYO、OSAKA、CHIBAのそれぞれのデータにアクセスできるL_TOKYO、L_OSAKA、L_CHIBAラベルと全てのデータにアクセスできるL_ALLラベルの4つのラベルを作成し、行レベルでのアクセス制御を確認します。
図2．アクセス制御概要
①SECADM権限ユーザーの登録
LBACを構成するオブジェクト（セキュリティー・ラベル・コンポーネント、セキュリティー・ポリシー、セキュリティー・ラベル）の定義、セキュリティー・ラベルの付与といった作業は、SECADM権限を持つユーザーしか実施できません。最初に、SECADM権限を持つユーザーを作成します。
SYSADM権限を持つユーザーでデータベースに接続し、SECADM権限を付与します。以下の例では、インスタンスオーナーでデータベースに接続し、lbacadmユーザーにSECADM権限を付与しています。
②セキュリティー・ラベル・コンポーネントの定義
SECADM権限ユーザーでアクセス制御の動作を決めるためのオブジェクトであるセキュリティー・ラベル・コンポーネントとその要素を定義します。セキュリティー・ラベル・コンポーネントは、SET/ARRY/TREEの3つの種類が存在します。その種類により、要素間の依存関係が異なります。実現したいアクセス制御に応じた種類を選択します。
SET ：権限の重み付けがなく要素間での依存関係を持たないコンポーネント
ARRAY：要素間で権限の強弱の順番があるコンポーネント
TREE：要素間で階層的に権限の強弱があるコンポーネント
この例では、3つの要素（TOKYO、OSAKA、CHIBA）を持ち、それぞれの要素間で依存関係のないSETのセキュリティー・ラベル・コンポーネントを作成しています。
③セキュリティー・ポリシーの定義
SECADM権限ユーザーでセキュリティー・ポリシーを定義します。セキュリティー・ポリシーは1つ以上のセキュリティー・ラベル・コンポーネントを指定して作成します。1つのセキュリティー･ポリシーに対して、複数のセキュリティー・ラベル・コンポーネントを指定することも可能です。
この例では、上で作成したセキュリティー・ラベル・コンポーネントLOCATIONSの1つのみを指定してP1というセキュリティー・ポリシーを作成しています。
セキュリティー・ポリシーの定義時に指定しているDB2LBACRULEは、ラベル・コンポーネントの要素がどのような規則に基づきアクセスをブロックするかを決めた規則になります。DB2 V9.5時点では、DB2LBACRULEしかありませんのでこの規則を使用してセキュリティー・ポリシーを作成することになります。
DB2LBACRULEの詳細は図3のようになります。
図3． DB2LBACRULES 規則のサマリー
④セキュリティー・ラベルの定義
SECADM権限ユーザーでセキュリティー・ラベルを定義します。セキュリティー・ラベルはセキュリティー・ラベル・コンポーネントの1つ以上の要素を指定して作成します。
この例では、TOKYO、OSAKA、CHIBAの各要素を1つずつ持つラベル（P1.L_TOKYO、P1.L_OSAKA、P1.L_CHIBA）とTOKYO、OSAKA、CHIBAの全ての要素を持つラベル（P1.L_ALL）を作成しています。
⑤セキュリティー・ラベルの付与
SECADM権限ユーザーでセキュリティー・ラベルをユーザーに付与します。以下の例では、ユーザー：user1にラベル：P1.L_TOKYO、ユーザー：user2にラベル：P1.L_OSAKA、ユーザー：user3にラベル：P1.L_CHIBA、ユーザー：db2inst1にラベル：P1.L_ALLを付与しています。
ここまで作成した各オブジェクトの関連を図にしてみると図4のようなイメージになります。
図4．LBACオブジェクト関係図
⑥セキュリティー・ポリシーが適用された表を作成
行レベルのアクセス制御を行うため、DB2SECURITYLABELデータタイプの列を持つ表を作成します。表の作成はSECADM権限ユーザー以外でも実施できます。以下の例では、label列をDB2SECURITYLABELデータタイプ列にしています。また、他のユーザーからも表へのアクセスが可能になるようにdb2inst1.tab1表のすべての特権をpublicに付与しています。
データの登録
以下のように作成した表にデータを登録します。INSERT文の中ではuser特殊レジスターを使用してデータを登録したユーザーがわかるようにしています。DB2SECURITYLABELが入るlabel列を指定していません。デフォルトでは、登録したユーザーが付与されているセキュリティー・ラベルの要素が登録されます。例えば、L_TOKYOラベルが付与されたuser1でデータを登録するとlabel列にはL_TOKYOラベルが登録されます。
データのSELECT
登録したデータを確認してみます。すべての要素を持つラベル（P1.L_ALL）が付与されたユーザー（db2inst1）でdb2inst1.tab1表のデータをSELECTします。全ての要素を持つラベルを持っているため、すべてのデータを参照することができます。次にuser2で接続して、同じSELECT文を実行していますが、OSAKA要素を持つ行しか表示されず、LBACによる行レベルのアクセス制御が有効であることがわかります。
SECLABEL_TO_CHAR関数は、引数にセキュリティー・ポリシー名とセキュリティー・ラベルを渡すと、それを構成するセキュリティー・ラベル・コンポーネントの要素を返します。この関数を利用することで行に付けられたラベル（正確には、その行の持つセキュリティー・ラベル・コンポーネントの要素）を確認することができます。以下の例でもこの関数を使用してlabel列に入っている要素を確認しています。
おわりに
この記事では、LBACの概要について、簡単なサンプルを通してご紹介してきました。LBACの基本的な動作については理解していただけたと思います。しかし、今回は1つのセキュリティー・ラベル・コンポーネントのみを使用した構成で、非常にシンプルなものですので、それぞれのオブジェクトの働きについての理解までは難しかったと思います。複数のセキュリティー・ラベル・コンポーネントを使用したさらに複雑な例は参考文献に挙げたDB2 V9.5 セキュリティー･デザイン･ガイドに載せていますので、ご興味があればこちらにも目を通してみてください。
参考文献
著者について  | | | 曽田 俊明は日本アイ・ビー・エム システムズ・エンジニアリング株式会社のエンジニアです。 |
記事の評価
| 
