第3章 計画されたセキュリティ機能
アクセス制御: #2 アクセス認可
アクセス制御は、本人認証とアクセス認可の2段階からなる。ここではアクセス認可について述べている。

アクセス認可
アクセス認可は、認証済みのユーザに対しデータやプログラム機能等のコンピュータ・リソースの利用を許す・許さないを具体的に制御する手順である。アクセス認可を実現する際には留意すべき点がある。
(1) 認証にもとづいて行う
アクセス認可は、あらかじめ本人認証を行っておき、その結果にもとづいて行う必要がある。
クライアントの接続IPアドレスや、パスワードの提示を受けずに受け入れたユーザ識別番号等を用いてアクセス認可を行う方法は、他人によるなりすましを見過ごすおそれがある。ユーザを特定することが重要でないシステムを除き、これらの方法は避けた方がよい。
(2) ユーザの全アクセスをインターセプトする
ユーザから対象のリソースへのアクセスがおこる際、アクセス認可のためのロジックを迂回できては具合が悪い。例えば、選択できる項目の表示をメニュー画面上で隠しただけでは、URLを用いて直接リソースが呼び出せるといった問題があり得る。
ユーザがリソースにアクセスする経路に立ちふさがる形で仕組みを設け、ユーザがアクセスを試みたときには必ず認可の判定ロジックがはたらくようにする。
許可パラメータ
アクセス認可処理においてユーザにアクセスさせる・させないの制御は、あらかじめ用意した許可パラメータ(パーミッション)にもとづいて行う。
利用できる機能がユーザごとに異なるシステムでは、例えば、次のような表に相当する許可パラメータをもつことになる。
| 機能1 | 機能2 | 機能3 | |
|---|---|---|---|
| ユーザ1 | ○ | ○ | − |
| ユーザ2 | ○ | − | − |
| ユーザ3 | ○ | − | ○ |
また、ファイルに対するアクセス認可の場面では、多くのオペレーティングシステムが実装しているように、「読み出し」「書き込み」「実行」の3つのオペレーションのうちどれを許すかといった、細分化された許可パラメータを使う。
| ファイル1 | ファイル2 | ファイル3 | |
|---|---|---|---|
| ユーザ1 | RW− | R−X | −−− |
| ユーザ2 | RW− | −−− | −−− |
| ユーザ3 | RW− | −−− | RWX |
※ R:読み込み許可、W:書き込み許可、X:実行許可、−:不許可
ロール
数千、数万といった多数のユーザを扱うシステムの場合、ユーザ一人一人に許可パラメータを設定することはシステム運用が煩雑であり得策でない。同様な許可が与えられるユーザの集団に一つの名前を与え、その名前に対して許可パラメータを定義する方法がある。
複数のユーザに適用すべく許可パラメータが記述される集団は「ロール」(役割)あるいは「グループ」等と呼ばれる。
| 掲載記事の閲覧 | 原稿の投稿 | 掲載の許可 | |
|---|---|---|---|
| ロールA「読者」 | ○ | − | − |
| ロールB「記者」 | ○ | ○ | − |
| ロールC「編集長」 | ○ | − | ○ |
ロールA={ユーザA1、ユーザA2、...}
ロールB={ユーザB1、ユーザB2、...}
ロールC={ユーザC1、ユーザC2、...}
プログラム・モジュール単位のアクセス認可
オペレーティングシステムがもつ従来型のアクセス認可の機構においては、ユーザが起動したプログラムの中で呼び出されるライブラリや別のプログラムにもユーザが得ているのと同じ許可が与えられる。
そのような場面に悪意のモジュールが紛れ込むと、その悪意のソフトウェアはユーザが得ている許可を最大限に悪用し、深刻な侵害をおこしかねない。
処理系によっては、プログラムの個々のモジュール、あるいはモジュールが置かれているディレクトリといった単位で、プログラムに対する許可パラメータを記述する能力をもつものもある。このような処理系の場合、特定のシステム機能の利用を許可パラメータが与えられているモジュールのみに限定するといったアクセス認可の運用が可能である。Javaや.Netがその例である。
外部から頻繁にプログラムのモジュールを取り込むことが必要な場面においては、モジュール単位のアクセス認可の仕組みをもつ処理系の利用、あるいはそうした仕組みそのものの実装を考慮する。