DB2のセキュリティー: 第1回 認証・権限・特権・ROLEの概念と役割

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 中級

Hitomi Horibe (HITOMIH@jp.ibm.com), IT Specialist, 日本アイ・ビー・エム システムズ・エンジニアリング株式会社

2009年 2月 19日

この記事では、DB2のセキュリティーに関して、認証・権限・特権・ROLEについて、ご紹介します。

はじめに

昨今、新聞やテレビにおいてさまざまな情報セキュリティー関連のニュースが報道されています。なりすましによる不正アクセスや、アクセス権限の不適切な付与による情報漏洩、データ改竄など、データベースを取り巻く脅威には多様なものがあります。データベースにアクセスするユーザーに対して本人確認をすること、さらに、データや各オブジェクトに対する適切なアクセス権限、実行権限を付与することは、大切なデータやシステムを守る第一歩となります。

そこで、この記事では、DB2におけるセキュリティーに関して、認証・権限・特権・ROLEについて、ご紹介したいと思います。

上に戻る

1．認証

認証とは、ユーザーが本人かどうかを確かめることです。DB2では、DB2自身は認証機能を持っておらず、OSかサード・パーティーの認証システムにユーザー認証機能を委任します。認証の実施は、サーバー側で行うか、クライアント側で行うか選択することができます。

また、OSによってクライアントを「信頼されないクライアント」と「信頼されるクライアント」の2種類に定義しています。前者はセキュリティー・ファシリティーを組み込んでいないWindows 98やMeのクライアントを指し、後者はセキュリティー・ファシリティーを組み込んでいるWindows NT/200/XP/Vista、AIX、Solaris、LinuxといったOSで動くクライアントを指します。

DB2サーバー側での認証タイプは、UPDATEコマンドにより、データベース・マネージャー構成パラメーターAUTHENTICATIONで設定します。基本的にはクライアントとサーバーで認証タイプを一緒にします。以下、DB2サーバー側での認証タイプを表1に、クライアント側での認証対応を表2に示します。

上に戻る

TRUST_ALLCLNTSとTRUST_CLNTAUTHパラメーター

上記表1と表2でも注意書きがありますが、サーバー側／クライアント側で認証方法がCLIENTに設定されている場合でも、サーバー側のある2つのデータベース・マネージャー構成パラメーターの設定値によっては、サーバー側で認証が行われることがあります。それが、TRUST_ALLCLNTSとTRUST_CLNTAUTHパラメーターです。この2つのパラメーターについて、少しご紹介します。

TRUST_ALLCLNTSは、どのクライアントがユーザーを認識できるようにするかを設定するパラメーターです。このパラメーターの値がYESの場合、信頼されているかいないかに関わらず、すべてクライアント側で認証されますが、NOの場合は、信頼されているクライアントのみがクライアント側で認証され、信頼されていないクライアントはすべてサーバー側で認証されます。DRDAONLYの場合は、ホストのクライアントだけがクライアント側で認証されます。

TRUST_CLNTAUTHは、接続時にユーザーIDとパスワードを指定した場合に、認証実行場所を指定するパラメーターです。このパラメーターの値がCLIENTの場合、ユーザーID／パスワードに関係なくクライアント側で認証されますが、SERVERの場合は、CONNECT、ATTACHコマンド実行時にユーザーID／パスワードが指定されるとサーバー側で認証されます。

図1では、クライアント／サーバー共にAUTHENTICATION=CLIENTと設定されており、TRUST_ALLCLNTS=NOなので、信頼されないクライアントはユーザーID／パスワードなしではサーバーに接続することができません。ユーザーID／パスワードを指定した場合には、サーバー側で認証されることになります。

上に戻る

2．権限

「ユーザーが本人かどうか確かめる」、というのが認証でしたが、次にDB2の権限についてご紹介します。権限とは、データベース・オブジェクトへのアクセスを制御する特権の集合です。特権については、この後の項目でお話ししますが、ユーザー認証が成功した後に、そのユーザーにどこまでアクセスを許可するかというのが特権ということになります。ユーザー認証はDB2の外で行われるとお話ししましたが、これからお話しする権限、特権はDB2自身のメカニズムによってアクセス制御されます。

権限はインスタンスとデータベースの管理を行う権限で、6つの権限があります。

インスタンス・レベルではSYSADM、SYSCTRL、SYSMAINT、SYSMONの4つ、データベース・レベルではDBADM、SECADMの2つです。これらは階層構造になっており、まずSYSADMが一番高いレベルで次にSYSCTRL、SYSMAINTの順に、できる操作が制限されていきます。SECADMは、主にラベル・ベースのアクセス制御(LBAC)を使用する場合に、必要な権限です。DBADMはデータベース、データベース・オブジェクトの操作に関する権限で、インスタンス・レベルの操作はできません。

SYSADM、SYSCTRL、SYSMAINT、SYSMONに関しては、それぞれデータベース・マネージャー構成パラメーターのSYSADM_GROUP、SYSCTRL_GROUP、SYSMAINT_GROUP、SYSMON_GROUPにグループ名を設定します。DBADM、SECADMに関してはGRANT/REVOKEステートメントで権限の付与／取り消しを行いますが、これにはSYSADM権限が必要となります。

では、各権限について、詳しく見ていきましょう。

• SYSADM：システム管理権限
  最高位の権限で、DB2インスタンスの構成（データベース・マネージャー構成パラメーターの設定）を行うことができます。すべての下位権限を持ち、システム管理やデータベース・オブジェクトへのアクセスが可能です。また、他ユーザーやグループへの権限付与／取り消しを行うことができます。
• SYSCTRL：システム制御権限
  システムの制御について操作が行える権限で、下位のSYSMAINTができる操作に加えて、データベースや表スペースを作成／削除することが可能です。インスタンス・レベルなのでデータベース内のデータへ直接アクセスできません。
• SYSMAINT：システム保守権限
  保守に関わるバックアップ／リカバリーといった操作を行える権限です。データベースや表スペースのバックアップ／リストアのほか、インスタンスの開始／停止、データベースの構成（データベース構成パラメーターの設定）を行うことができます。インスタンス・レベルの保守に関する権限なので、SYSCTRLと同じく、データベースや表スペース作成／削除はできず、データへの直接アクセスもできません。
• SYSMON：システム･モニター権限
  インスタンスやデータベースのモニター・データを取得するための権限です。スナップショットを取得するために必要です。モニター･スイッチを設定でき、アクティブなデータベースやアプリケーションの情報を取得することができます。SYSADM、SYSCTRL、または SYSMAINT 権限レベルを持つユーザーには、SYSMON 権限もまた与えられます。
• DBADM：データベース管理権限
  特定のデータベースについてのオブジェクトの管理権限です。データベース・レベルなので、データベースや表スペース内へのオブジェクト作成／更新／削除や、アクセス特権の付与／取り消しを行うことはできますが、データベースや表スペース自体の作成／削除、バックアップ／リストアなどを行うことはできません。
  DBADMの中には、以下表3．の権限が含まれます。

• SECADM：セキュリティー管理者権限
  DB2 V9.1より登場した権限で、主にラベル・ベースのアクセス制御(LBAC)を使用する場合に必要な権限です。LBACに属しているさまざまなオブジェクトの作成、ドロップ、アクセス許可の付与、または取り消しができます。また、自分が所有していないオブジェクトへのTRANSFER OWNERSHIPステートメントを使用でき、SETSESSIONUSER特権の付与または取り消しもできます。
  SYSADMは他のユーザーにSECADM権限を付与することができますが、SYSADMは自らにSECADM権限を付与することはできません。SYSADM_GROUPのメンバーであればSYSADM権限があり、ユーザーに SECADM 権限を付与することができます。

上に戻る

3．特権

インスタンス、データベース・レベルの権限をお話しした後に、続いてデータベース内の個々のオブジェクトに対する操作を行うための権限を規定した「特権」についてご紹介します。各オブジェクトに対する特権について、表またはビューに対する特権を下記表4．に、その他のオブジェクトに対する特権を表5．に示します。

表とビューに関する特権ですが、2番目のALL PRIVILEGESを与えられたユーザーは、ALTERからUPDATEまでのすべての操作を行うことができます。CONTROLはALL PLIVILEGESに可能な操作に加えて、表をDROPする権限やRUNSTATS、REORGを行うことができます。REFERENCEは表を参照保全の親表として指定する特権で、SELECTは表からデータを読むことができる特権です。なお、REFERENCESとUPDATE特権は特定の列に対して与えることも可能です。

続いて、パッケージを作成したり操作したりする特権、索引を削除するためのCONTROL特権、表スペースに表を作るためのUSE特権などがあります。索引を削除するための特権はありますが、索引を使うために特別な特権は必要ありません。また、スキーマに関しても同様に、スキーマ内にオブジェクトを作成する特権などがあります。

これらすべての特権の付与／取り消しは、GRANT/REVOKEステートメントで行います。

例えば、group1に対してEMPLOYEE表に対するCONTROL特権を付与する場合、以下のようなステートメントになります。

GRANT CONTROL ON TABLE employee TO group1

他のユーザーに特権を与える場合にはWITH　GRANT　OPTIONでGRANT文を実行します。

GRANT ALL ON TABLE employee TO user1 WITH GRANT OPTION

user1はemployee表に対するすべての特権を、他のユーザーに付与することができます。

また、すべてのユーザーに特権を付与したい場合に用いる別名としてPUBLICがあります。以下のように用います。

GRANT CONTROL ON TABLE employee TO public

CONTROL特権は先ほどの表4．や表5．でも出てきましたが、この特権を与えられると、オブジェクトに対するすべての権限を保持するだけでなく、それらの特権を他のユーザーに付与することもできます。CONTROL特権を付与できるのはSYSADM権限、DBADM権限、CONTROL特権を持つユーザーに限られますが、オブジェクトの作成者には暗黙的にCONTROL特権が与えられます。

注意すべき点としては、CONTROL特権を取り消しても、暗黙的に与えられた特権は残るということです。これは例えばEMPLOYEE表に対するCONTROL特権をuser1からREVOKEしても、その下位のSELECTやDELETE特権は残る、ということです。それらについても個別に、明示的に特権を取り消すことが必要です。

上に戻る

4．ROLE

権限、特権とお話ししてきましたが、最後にROLEについてお話ししたいと思います。ROLEとは、DB2 V9.5より登場したオブジェクトで、一言で言うと「権限や特権をグループ化したもの」です。例えば、あるデータベースのLOAD権限やCONNECT権限、その中の特定の表のSELECT特権などをROLEとしてひとかたまりにしておき、それらをまとめてユーザーやグループなどに付与／取り消しすることができます。ROLEで付与できる権限は、SECADMやインスタンス・レベルの権限（SYSADMなど）以外のすべての権限です。ひとつひとつの権限や特権を付与／取り消しするよりも簡単ですし、Roleを更新することで、そのROLEを付与されたユーザーの持つ権限や特権が更新されますので、各ユーザーに対する更新が必要ありません。また、部署ごとにROLEを定義しておけば、組織に関連したアクセス制御が可能になります。

しかし、これまでROLEというオブジェクトがなかったときでも、グループを作成してユーザーをひとまとめにし、グループに対して権限を付与することで、各ユーザーに対して権限を付与する手間は省けていました。では、ROLEにはグループと異なる、どのようなメリットがあるのでしょうか。

実はグループに対して付与された権限は、View、トリガー、MQT、静的SQL、SQLルーチン作成時には、DB2によりチェックされません。これは、グループの管理がDB2外で行われるからであり（例えば、OSやLDAPディレクトリなど）、グループのメンバーが変更されたことにDB2は気づくことができないためです。そのため、グループに権限が付与されても即時有効ではなく、データベースへの再接続が必要になります。

一方、ROLEはデータベース・オブジェクトのため、前述の各オブジェクトの作成時にも、DB2により権限がチェックされます。ROLEの付与は即時有効となり、データベースへの再接続は不要です。（ただし前述のとおり、グループのメンバーに対する変更には気づくことができないため、ROLEがグループに対して許可されている場合は、再接続が必要となります。）

ROLEの作成・付与・取り消しはそれぞれ、CREATE、GRANT、REVOKEステートメントで行います（ROLEの作成にはSECADM権限が必要です）。ROLEを付与できる対象としては、ユーザー、グループ、PUBLIC、Trusted Context、ROLEがあります。ROLEにROLEを付与することが可能なので、階層構造を持たせることもでき、例えば上位階層のManagerROLEが下位階層のEmployeeROLEを含む、という定義も可能です。

では、以下のような例を考えてみましょう。BOB と ALICE は、DEV部のメンバーのため、SERVER、CLIENT、TOOLS表に対してSELECT権限を持っています。ところがある日、彼らはQA部に異動となりました。そのため、SERVER、CLIENT、TOOLS表から、二人が持つSELECT権限を消去しないといけません。また、BOBとALICEの代わりに、TOMがDEV部に配属になりました。今度はTOMに対して、SERVER、CLIENT、TOOLS表に対してSELECT権限を付与しないといけません。

このとき、もしROLEの概念がなければ、以下のステートメントの実行が必要になります。

• 初期状態（BOBとALICEがDEV部の表のSELECT権限を持っている状態）作成

  – GRANT SELECT ON TABLE SERVER TO USER BOB, USER ALICE

  – GRANT SELECT ON TABLE CLIENT TO USER BOB, USER ALICE

  – GRANT SELECT ON TABLE TOOLS TO USER BOB, USER ALICE

• 権限の変更

  – REVOKE SELECT ON TABLE SERVER FROM USER BOB, USER ALICE

  – REVOKE SELECT ON TABLE CLIENT FROM USER BOB, USER ALICE

  – REVOKE SELECT ON TABLE TOOLS FROM USER BOB, USER ALICE

  – GRANT SELECT ON TABLE SERVER TO USER TOM

  – GRANT SELECT ON TABLE CLIENT TO USER TOM

  – GRANT SELECT ON TABLE TOOLS TO USER TOM

しかし、ROLEを使用すれば、以下のステートメント実行で済みます。

• 初期状態（BOBとALICEがDEV部の表のSELECT権限を持っている状態）作成

  – CREATE ROLE developer

  – GRANT SELECT ON TABLE SERVER TO ROLE developer

  – GRANT SELECT ON TABLE CLIENT TO ROLE developer

  – GRANT SELECT ON TABLE TOOLS TO ROLE developer

  – GRANT ROLE developer TO USER BOB, USER ALICE

• 権限の変更

  – REVOKE ROLE developer FROM USER BOB, USER ALICE

  – GRANT ROLE developer TO USER TOM

どうでしょう。ROLEを定義することで、まとめて付与／取り消しができるので、権限の変更がとても簡単になりますね。その他、ROLEは監査対象にすることも可能ですし、LBACセキュリティー・ラベルを認可することもできますので、DB2の他のセキュリティー機能と組み合わせることで、より強固なセキュリティー対策を講じることも可能です。

上に戻る

おわりに

この文書では、DB2のセキュリティーに関して、認証・権限・特権・ROLEについてお話ししてきました。基本的な内容については、ここで触れた内容でカバーできていると思いますが、さらに詳細な情報を参考文献に挙げたDB2 V9.5 セキュリティー･デザイン･ガイドに載せていますので、こちらにも目を通してみてください。DB2の他のセキュリティー機能（監査機能やLBAC）についての説明もありますので、総合的なDB2のセキュリティー･デザインの助けになれば幸いです。

参考文献

• DB2 9.5技術資料 DB2 V9.5 セキュリティー・デザイン・ガイド
  
  
• (オンライン・マニュアル)DB2 Information Center

著者について

		堀部　ひとみは日本アイ・ビー・エム システムズ・エンジニアリング株式会社のエンジニアで、現在はDB2 for LUW分野におけるフィールドへのテクニカル・サポートを行っています。 仕事では最新技術を追いかける一方、アンティークや古いものには目がなく、週末はアンティークショップ巡りで心を潤しています。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る