安全なデータベース運用のキモ、ユーザーのアクセス制御をどう設定すべきか：今さら？ 今こそ！ データベースセキュリティ（10）（1/3 ページ）

連載バックナンバー

　連載第4回「データベースセキュリティに求められる『3つの軸』とコストの最小化」では、安全にデータベースを運用するための軸の1つとして「構成管理」を挙げました。

データベースセキュリティの構成要素

　そして、連載第9回「安全なデータベース運用、設定は具体的にどうすればいいのか（セキュリティ関連の初期化パラメーター一覧付き） 」では、このうち「構成管理」における「安全な設定」について説明しました。今回は、同じく「構成管理」の中から、「機密情報の把握」と「最小権限の原則」について紹介します。

機密情報の把握

　前述の「データベースセキュリティに求められる『3つの軸』とコストの最小化」では、「セキュリティ対策のコスト効果を上げるために、データベースの中身、格納されている情報の重要性を判断することが大切」だと説明しました。

　実際に、安全なデータベース運用のためのセキュリティ設定を行うには、「このデータベースには重要な情報がある」というレベルではなく、「このデータベースのどの表のどの列に守るべき重要な情報が入っているのか」といったより細かな精度で、重要な情報が入っている場所を把握しておく必要があります。また、セキュリティ対策を緩めているデータベースについては、どの表にも個人情報など重要な情報が入っていないことを把握しておく必要があります。

忘れてはいけないアカウント管理

　さて、「構成管理」の最後の要素である「最小権限の原則」は、連載第1回「なぜ、今『データベースセキュリティ』なのか──安全なデータベースに必要な『5つ』の基本」でも紹介している「最小権限の原則に沿ったアクセス制御を強制する」ということなのですが、アクセス制御の基本は、「誰が（Subject）」「何に（Object）」「どうする（Operation）」かを、許可あるいは拒否するものです。

　「何に」の部分は、前述の「機密情報の把握」で「データベース内のどの表のどの列」まで確認する必要があることを説明しましたが、「誰が」の部分はデータベースでは基本的にデータベースユーザーとなります。

　もし、システムにデータベースユーザーが1人しかいない場合、全ての利用者、運用担当者などが同じデータベースユーザーを利用することになり、必要なデータのみにアクセスできるような「最小権限の原則に沿ったアクセス制御を強制する」ことはできません。5つの基本で紹介した「共有ユーザー利用などの匿名性を排除する」というポイントに従って、個人用のデータベースアカウントを作成しておく必要があります。

　コネクションプールを利用しているアプリケーションが利用するデータベースユーザーは、どうしても代表ユーザーになってしまうことがあります。そのような場合でも、アプリケーション経由のアクセスはアプリケーション側で認証やアクセス制御がきちんとできている前提で、その代表ユーザーを他の人が利用できないようにすることが重要です。

　「アプリケーション用の代表ユーザーは一般的に強力な権限を持っており、またアカウント情報が流出してしまった場合でもパスワードを変更することは難しい」と、さまざまなお客さまから聞いています。しかし、運用担当者が異動、退職した後でも、昔使っていたパスワードでシステムにアクセスできてしまうかもしれません。データベースに直接アクセスするアプリケーションおよびデータベースの管理運用担当者用には、匿名性を排除して厳密なアクセス制御を行うために、個人アカウントを作成してください。

　Oracle Databaseの場合、ユーザー一覧はDBA_USERSビューから簡単に確認できます。このビューを検索するだけでも、アプリケーションやデータベースの管理運用担当者用の個人アカウントが作成されているかどうかが、すぐに分かります。

SQL> select username from dba_users
  2  where oracle_maintained != 'Y';
USERNAME
--------------------------------------------------------------------------------
OPS$PUKU
APP
PDBADMIN