[第15回] 最小権限の原則の実現のための考え方 ～ アクセスマトリックスとロール

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

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

ここで、ユーザーと表の間に中間に「業務」という概念を入れてみます。
たとえばそれぞれのユーザーが以下のような業務を担当しているとします。

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

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

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

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

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

ロール管理に関しては日本ネットワークセキュリティ協会(JNSA)の「エンタープライズロール管理解説書」が参考になるのでこちらもぜひ参照ください。

このエントリはそれぞれのユーザーがどの表にアクセスできるか、という観点で最小権限の原則の実現のためには、アクセスマトリックスの作成をおこなうべきで、アクセスマトリックスを作成する際にはロールという概念をとりいれるとアクセスマトリックスをまとめやすい事を紹介しました。しかし、実際のアプリケーションではアプリケーション用の代表ユーザーが接続しているコネクションプールを使用することが多く、ユーザーが直接データベースにログインして表にアクセスすることは少ないです。また、データベースに直接ユーザーがアクセスするのは表へのアクセスというよりは、データベース管理操作をおこなうためであることも多いです。アプリケーションが利用するアカウントや、データベース管理操作をおこなうためのアカウントでどのように最小権限の原則を実現していくかは別のエントリで紹介します。