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

本連載では、データベースセキュリティの「考え方」と「必要な対策」をおさらいし、Oracle Databaseを軸にした「具体的な実装方法」や「Tips」を紹介していきます。今回は安全なデータベース運用のためのアクセス制御の考え方について紹介します。

[福田知彦，日本オラクル株式会社]

「最小権限の原則」の徹底

　「最小権限の原則」はアクセス制御で実現しますが、「アクセス制御の基本は『誰が（Subject）』『何に（Object）』『どうする（Operation）』かを許可／拒否するもの」だと前述しました。Oracle Databaseでアクセス制御を実現するための機能は権限ですが、「何に」「どうする」という部分では「何に」対する権限かによって大きく2つに分かれます。1つが「データベースに」で、これはシステム権限で制御します。もう1つが「データに」で、主にオブジェクト権限で制御します。

　例えば、「データベースに」「接続する」ためにはCREATE SESSION権限（システム権限）が必要です。CREATE USER文でユーザーを作成しただけでは、データベースに接続できません。データベースに接続するためには必ずこの権限が必要です。

　同様に、「APPスキーマのCUSTOMERS表に」「参照する」ためにはAPP.CUSTOMERS表へのSELECT権限（オブジェクト権限）が必要です。

　参照系のアプリケーションが利用するアカウントでは、一般的にはこのCREATE SESSION権限とアプリケーションが利用する表へのSELECT権限だけで十分なはずです。オブジェクトの所有者であるAPPユーザーは、自分が持っているオブジェクトに対して、参照・更新ともに可能ですので、オブジェクトの所有者のアカウントを参照系アプリケーションが利用すると、必要以上の権限があり、最小権限の原則が守られていないことになります。

　では、更新系のアプリケーションではどうでしょう。

　更新系のアプリケーションでも、オブジェクトの所有者のアカウントは利用すべきではありません。オブジェクトの所有者は自分が持っているオブジェクトに対して、参照・更新だけではなく、そのオブジェクトのオブジェクト権限を割り当てることが可能です。

　例えば、アプリケーションの不具合からSQLインジェクション攻撃を受けて、APP.CUSTOMER表に対するフルアクセス権限がPUBLICに割り振られてしまう可能性があります。アプリケーションが利用するアカウントは、オブジェクトの所有者とは別にすべきです。

　アプリケーションのデータが複数のスキーマに分散している場合、権限管理を簡単にするために、「SELECT ANY TABLE」など他のスキーマのオブジェクトを操作できるANYシステム権限を、アプリケーションのユーザーやアプリケーションのデータを管理するユーザーに割り当てることがあります。しかし、このシステム権限では、業務上必要のないデータにまでアクセスできるようになってしまいます。特にデータベース統合などを将来的に行うなどして、複数のアプリケーションで1つのデータベースを共有する場合、他のアプリケーションのデータにもアクセスできるようになってしまうため、ANYシステム権限の割り当ては基本的に実行しないことを推奨します。

　つまり、面倒であっても、それぞれの表に対して個別にアクセス権限を設定していく必要があります。

　そのためにはまず、そもそもどのユーザーが業務上どんな操作をする必要があるのかをまとめることが重要になります。誰がどのような権限を持つかをまとめるための方法の1つに、「アクセスマトリックス」の作成があります。

　簡単なアクセスマトリックスの例は以下の通りです。「それぞれのユーザーがそれぞれの表に対してどのような操作をする必要があるか」をまとめています。

　このようにまとめられると、どのユーザーにどの権限を付与すればよいのか、一目瞭然なのですが、どのユーザーがどの表にアクセスする必要があるのかをいきなりまとめるのは難しいかもしれません。

　ここで、ユーザーと表の間に中間に「業務」という概念を入れてみます。

　例えば、それぞれのユーザーが以下のような業務を担当しているとします。

　それぞれの業務で必要な表へのアクセス権限をまとめます。

　ユーザーと表への間に1つの概念を加えることで、どのユーザーにどの表へのアクセス権限を付与すればよいのかが分かりやすくなりました。また、同じ業務を担当している人には同じ権限を付与すればよいので、これらの表へのアクセス権限はまとめて名前を付けておくと便利です。このように権限をまとめたものが「ロール」です。今回は「業務」ごとに必要な要件をまとめたロールを作成しています。

　では、どのユーザーがどの業務を担当しているのか、というマッピングを自動化することはできないでしょうか？

　ユーザーと業務のマッピングは、そのユーザーの「所属」や「役職」などによってある程度は自動化できるかもしれません。例えば、Aさんは「アプリケーション管理部門」の「責任者」なので、「アプリケーションデータ全体の管理」を担当している、といったように決められることもあるでしょう。

　このようにロールを多段に構成することで、権限の管理を簡単にすることができます。ロールが多段になった場合には、「所属」や「役職」などに対応するロールを「ビジネスロール」、「業務」ごとに権限をまとめたロールを「ITロール」や「アプリケーションロール」と呼び分けることもあります（ロールの呼び方や定義に関しては、さまざまな考え方があるので、その1つとして参考にしてください）。

　ロールを多段で管理する場合、ビジネスロールとITロールを両方ともデータベース内で管理することもできますが、もし外部にID管理の仕組みがある場合、ITロールはOracle Database内のロールとして実装し、ビジネスロールはID管理製品で管理するというように、分けることもできます。