アクセス制御のケーススタディ

アクセス制御機構の概念モデルが実際にアクセス制御機構をきちんと説明できるか、いくつかケーススタディを行い実証してみます。

まずは、基本の3タイプです。

(1) Subjectによるアクセス制御

ログインユーザーだけがアクセスでき、未ログインユーザーはアクセスできない機能、あるいは、特権ユーザーだけがアクセスでき、一般ユーザーはアクセスできない機能がこのパターンに当たります。

例を出すまでもなく、ログインを行うWebアプリケーションの多くの機能がこのパターンのアクセス制御を行っています。

ロールベースのアクセス制御(RBAC)はこのパターンの典型的な実装と見ることができます。

ロールやパーミッションといった情報がアクセス制御ポリシーを構成する要素になります。

(2) Objectによるアクセス制御

対象データの属性によってアクセスできる機能がこのパターンです。

例えば、削除済みデータは表示されませんが、多くのWebアプリケーションではデータを物理的に削除するのではなく、削除フラグや状態区分など削除状態を示す属性情報を管理しており、この属性情報を判定してアクセスを制御します。

アクセス制御ポリシーは外部パラメータで持つのではなくハードコーディングされる場合が多いのではないかと考えられます。

(3)Elseによるアクセス制御

アクセス日時やアクセス経路など、その他の要因が合致したときだけアクセスできる機能がこのパターンです。

例えば、社内端末からアクセスしたときだけアクセスできる、業務時間外はアクセスできないなどです。

そもそも別々のサイトとして構築するとか業務時間外はサービスを停止するというのが典型的な実装になります。

アクセス制御ポリシーは外部パラメータで持つのではなくハードコーディングされる場合が多いのではないかと考えられます。

ここからは上記の3タイプを組み合わせた複合タイプです。

(4)SubjectとObjectによるアクセス制御

対象データが属性として持つユーザー情報に合致するユーザーだけがアクセスできる機能がこのパターンです。

例えば、掲示板に投稿した記事は投稿した本人だけが編集・削除できますが、実装上は記事データの属性情報として投稿したユーザーを管理しており、この属性情報とアクセスユーザーが合致するかどうかを判定してアクセスを制御します。

アクセス制御ポリシーは外部パラメータで持つのではなくハードコーディングされる場合が多いのではないかと考えられます。

(5)SubjectとElseによるアクセス制御

特定の条件で特定のユーザーだけがアクセスできる機能がこのパターンです。

例えば、未成年のユーザーは20時以降は使用できないといったアクセス制御です。

ロールベースアクセス制御において、パーミッションの属性に時間帯やアクセス経路を制限する属性情報を管理するなどの実装が考えられます。

(6)ObjectとElseによるアクセス制御

対象データの属性によってアクセスできる機能がこのパターンです。

例えば、掲示期間前のお知らせは表示されません、あるいは、掲示期間を過ぎたお知らせは表示されませんといったアクセス制御です。

お知らせの属性情報として掲示期間を管理しており、システム日時と掲示期間を比較してアクセスを制御します。

アクセス制御ポリシーは外部パラメータで持つのではなくハードコーディングされる場合が多いのではないかと考えられます。

最後に全部を組み合わせたタイプです。

(7)SubjectとObjectとElseによるアクセス制御

特定のユーザーが対象データの特定の属性においてその他の条件を満たす場合にアクセスできる機能がこのパターンになります。

例えば、課長承認済みの稟議書は部長が社内にてアクセスしたときだけ決済することができるというアクセス制御は、

• 特定のユーザー = 部長ロールを属性に持つユーザー
• 対象データの特定の属性 = 課長承認済み状態
• その他の条件 = 社内

のすべての条件を判定しています。

実際のシステム概念設計においては、以下のようなシートを使って実現すべきアクセス制御を整理できると思われます。