第3回 データベースアプリケーションのセキュリティ　

星野 真理
株式会社システム・テクノロジー・アイ
2005/4/5

---

インターネットアプリケーションで使うDBユーザー

　通常、DB側のユーザーと認証ユーザーを１対１にはしません。セキュリティ的な観点でいえば、使用するDBログイン名は１つでも構いません。つまり、アプリケーションサーバから接続してくる一般ユーザーは全員が1つのDBユーザーを利用しているという形です。

　「なぜ分けないの？」と疑問に思うかもしれませんが、それはセキュリティ的に必要性がないからです。DBユーザーを分けても、結局はその接続認証はプログラム内でのハードコードになります（DBの認証情報を、一般ユーザーが知らせてあげるなんてしませんね。危ないだけです）。

　ユーザーを分けても認証チェックに使わないのであれば、セキュリティ以外の都合となるので、この連載では触れません。ただし、アプリケーションサーバのアーキテクチャから考えれば、ユーザーの切り替えはDBに余計なオーバーヘッドをかけるともいえます。上記の図で示した接続プールはあらかじめ決められたDBユーザーで接続が完了しているのです。

イントラネットシステムで使うDBユーザー

　イントラネットにおいては、利用者の所属部門によってアクセスできるデータの種類が異なります。そのため、部門ごと、もしくはアプリケーションごとに必要な権限をセットしたロールを複数作成します。

　この後の実装は2つのパターンに分かれます。

パターン1：

　部門ごと、もしくはアプリケーションごとにDBユーザーを数パターン作成します。これらのユーザーに先ほどのロールを必要なだけ付与します。アプリケーションコードの中でLDAPサ−バでの認証情報（グループ、ロール）を取り出し、どのDBユーザーに接続させるかを判断して接続します。

パターン2：

　イントラネット用のDBユーザーを1人作成し、このユーザーに上記で作成したロールをすべて与えます。しかし、デフォルトではこれらのロールはすべて動かないようにしておきます。アプリケーションコードの中でLDAPサ−バでの認証情報（グループ、ロール）を取り出し、どの権限が必要かを判断してロールを起動していきます。

　上記の方法であれば、人事部以外の社員が人事部で使っているシステムのURLを知ったところで、そのシステムを使うことはできず、データは守られます。

パターン2の実装例（Oracleの場合） ●DB側での権限設定 イントラネット用のユーザーを作成 create user intrauser identified by xxxx; 各アプリケーションで使用する権限セットを格納するロールを作成 create role gyoumu_role; create role keiri_role; create role suppor_rolet; 表への権限をロールにセット grant select,update,insert on customer to gyoumu_role,support_role; grant select on customer to keiri_role; 　アプリケーションで使用する対象の表をgrantしていく インターネット用ユーザーに全ての権限を与える grant gyoumu_role,keiri_role,support_role,connect to intrauser; デフォルトロールは、DB接続権限だけ alter user intrauser default role connect; ●アプリケーション側でのロールの起動（javaの場合） CallableStatement stmt=connection.prepareCal("{call dbms_session.set_role('ロール名')}"); 　ロールの起動にチェックロジックを設定したい場合は、 　DB側でアプリケーションロールを作成してください

3/4

Index
データベースアプリケーションのセキュリティ
	Page1 今回の設定 アプリケーション構築の着目点
	Page2 アプリケーション使用における認証の仕組み DBユーザーの分類とその権限設定
	Page3 インターネットアプリケーションで使うDBユーザー イントラネットシステムで使うDBユーザー
	Page4 EUCアプリケーションで使うDBユーザー

関連記事

データベースセキュリティの基礎のキソ

Database Expertフォーラム

Security&Trust記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）