第2回 データベースの認証を総点検

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

---

認証を見直してセキュリティ強度を向上しよう

　では、現行のインフラを変更せず安全な運用を目指す最低限のルールを検討していきます。

　接続時のユーザー名は共有しない。これはOS管理者としての認証、データベース管理者としての認証のどちらについても同じです。OS側の管理者もデータベース管理者のユーザー名も作業者である人間ごとに作成します。管理者の中のリーダー的存在の人が各ユーザーの作成を行い、パスワードは各ユーザー名だけを設定します。各ユーザーのパスワードは個人が管理し、ほかの者にはもらさないことを義務付けます。ユーザーの異動や退職があった場合は即座にユーザーを削除します。

　次にクライアント／サーバシステムの認証におけるチェック項目を確認しておきましょう。

チェック項目1：
クライアントマシンへのログインをチェックしているか

実装のヒント：

LDAPサーバの導入

チェック項目2：
クライアントアプリケーションが稼働するマシンをチェックしているか

実装のヒント：

データベース接続部分に仕掛けを作ります（Oracleならログオントリガー）。 その仕掛けの中で以下の情報をデータベースのセッション情報（Oracleなら V$SESSION）を使用して確認します

OSユーザー／DBユーザー／使用できるアプリケーション名

上記検索結果と、事前に作成しておいた「許可ユーザーが登録してある表」との合致行 があるかを確認します

OSユーザー	DBユーザー	使用できるアプリケーション名
otanaka	dtanaka	アプリ名_A
osatou	dsatou	アプリ名_B
・	・	・
・	・	・
・	・	・

チェック項目3：
実際に作業をするユーザーごとに対応したDBユーザー設定になっているか

チェック項目4：
実際に作業をするユーザーごとに対応した細やかなデータベース権限設定が行われているか

実装のヒント：

DBユーザーをクライアントシステムに接続する人数分登録します。そしてユーザーの権限設定の種類（部署ごとやアプリケーションごと）に対応したロールを作成します。このようにしてユーザーにロールを与えます

チェック項目5：
パスワードの有効期限を決め、期限切れの前にユーザー本人に変更させる仕組みを持っているか

チェック項目6：
DBユーザーに対するパスワードの複雑さや再利用についてのチェックロジックは入っているか

実装のヒント：

データベース側の機能を使用して、パスワードの複雑度や再利用のチェックを行うことが可能です。ただし、パスワードを強制的に変更させるアプリケーションを作成する必要があります。また、パスワード変更期間に猶予期間を持たせないと数日出張しただけでパスワードが無効になってしまうこともあります。長い休みの前などはユーザーへの早めのパスワード変更をお願いするようにしましょう

チェック項目7：
不要なユーザーの削除ルールが策定済みか

実装のヒント：

社員やスタッフの異動は、その部署の所属長が把握しています。社員やスタッフの作業内容が変更になったらすぐにシステム部に伝える仕組みが必要です（その伝達経路をチェックし、処理のし忘れが発生しないように工夫しましょう）

チェック項目8：
OS認証から独立したデータベース認証を使っているか

実装のヒント：

これは、一般的には使ってはいけないといわれる技術です。データベースには、OS認証という考え方があり、OS側で認証を受けたユーザーであればデータベース認証を省略し、OSユーザーにバインドしたユーザーが接続できます。しかし、OSのログインが破られればデータベースに入られてしまうという意味で危険視されています

チェック項目9：
データベースにログインできる時間帯を制限しているか

実装のヒント：

データベースへのログイン時に時間のチェックを行うロジック（Oracleであればログオントリガー）を作成し、そのロジックに書いてある時間帯以外はすぐにログオフさせます

チェック項目10：
データベース管理ユーザー（DBAユーザー）についてのポリシーを持っているか

実装のヒント：

DBAユーザーの作成をためらわないこと。決してデフォルトの管理ユーザーのパスワードを複数の管理者で共有しないこと管理者と一言でいっても、データベースの起動・停止・バックアップなどシステム側からのメンテナンスを行うためのDBAユーザーとデータベース内のデータを自由に見ることができる権利は分けてください。誰にどこまでの権限を与えるかはじっくりと検討してください

チェック項目11：
誰も覚えられないようなパスワードの採用は、その管理を十分に検討する

実装のヒント：

パスワードの強度を上げるために、パスワードを乱数を発生させる関数から作成する手法はかなりポピュラーです。最も破られにくいパスワードとして好まれています。しかし、私は乱数のパスワードを好みません。人間が乱数を覚えられるまでにはかなりの繰り返しの入力を必要とします。パスワードには「期限を付けて変更しなさい」というお達しがあります。定期的に変更されるパスワードをすぐに暗記できない人間は、必ず、どこかにメモを書いてしまいます。しかも使いやすいようにデスクトップなどにこっそり置いていたり……

これでは、安全性の向上というより低下につながります。作業者ごとのユーザーを作成し、パスワードに使ってはいけない用語などを規定したルールを作っておくだけなら、必ずしも書き留める必要はないと思います

実際に運用していくのは優秀なコンピュータではなく生身の人間なのですから、そのあたりも考慮にいれて実装の形を決めていくことが好ましいでしょう

◆ ◇ ◆

　さて、データベースセキュリティにおける認証チェックを行ってきました。ここに書き連ねたチェック項目は、目新しいものではないでしょう。しかし、実際にチェックしてみると、「あれ？危険だ！」と感じる部分もあるはずです。そのような項目が1つでもあるようならば、今日から改善していきましょう。

　危険を回避するためには、決して新しいソフトウェア開発やサーバが必要になるとは限りません。現在運用中のシステムでも採用できる技術もあります。セキュリティはできるところから実装していく姿勢が必要です。現在のシステムを客観的に、できれば悪意を持ったユーザーの観点で見直して、実装できる技術を採用していけば、トラブルが発生してから後悔する可能性をかなり減らせることでしょう。

　次回は、アプリケーションに関するチェック項目と実装のヒントについて見ていきます。

3/3

Index
データベースの認証を総点検
	Page1 データセキュリティはデータの重要性確認から 認証の重要性
	Page2 クイズ：ここが危険だ！ 認証編
	Page3 認証を見直してセキュリティ強度を向上しよう

関連記事

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

Database Expertフォーラム

Security&Trust記事一覧

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