とことこロゴス
メニュー

アクセス制御

読み：あくせすせいぎょ　／　英語表記：Access Control

利用者やプロセスなどの主体が、ファイルや機器などの客体に対して行う操作を、あらかじめ定めた規則に従って許可・拒否するセキュリティの仕組みである。相手が誰かを確かめたうえで、その相手に認める操作の範囲を判断して実施する。

イマシルちゃんの解説

会社のファイルサーバには、だれでも見てよい資料と、人事部だけが見てよい資料が一緒に入っているよ。
全員に同じ扱いをしたら、給与の情報までみんなに見られちゃうね。
そこで「この人がこのファイルに何をしてよいか」を決めて、それ以外の操作を止めるのがアクセス制御というセキュリティの仕組みなんだ。
まずIDとパスワードなどで相手がだれかを確かめて、そのあと決めた規則と照らし合わせるよ。
規則は持ち主が自由に決める方式もあれば、役割ごとにまとめる方式もあるの。
見る・書き換えるといった操作ごとに許可を分けられるから、必要な人に必要な分だけ使わせられるんだ。

より深い解説

定義と位置付け

アクセス制御（Access Control）は、システムの資源を誰がどのように使えるかを制限するセキュリティ機能である。情報を許可された人だけが読めるようにする機密性と、許可された人だけが変更できるようにする完全性を支える。

アクセス制御は三つの要素で考える。操作を求める側を主体（サブジェクト）、操作される資源を客体（オブジェクト）、行おうとする読取りや書込みなどを操作と呼ぶ。NISTのSP 800-162も、主体には人間の利用者だけでなく、人以外の機器やプロセスも含まれると説明している。

対象はファイルに限らない。OSのファイル、データベースの表、Webアプリケーションの画面、ネットワーク機器への通信、クラウドの管理操作など、あらゆる層でアクセス制御が行われる。建物の入退室管理も、物理的なアクセス制御にあたる。

確かめる・判断する・記録するの流れ

アクセス制御は、一つの処理ではなく段階を追って行われる。どの段階の問題かを区別できないと、対策を取り違える。

段階行うこと例
識別利用者が自分は誰かを名乗るユーザーIDを入力する
認証名乗った本人であることを確かめるパスワード、証明書、多要素認証
認可確かめた相手に許す操作を判断するこのユーザーは人事フォルダを読めるか判定する
記録誰が何をしたかを残すアクセスログ、監査ログ

認証が成功しても、何でも操作できるわけではない。例えばKerberosやRADIUSで本人確認に成功した利用者でも、どのファイルを更新できるかは別の規則で決まる。認証・判断・記録の三つをまとめた考え方はAAAと呼ばれ、RADIUSなどのプロトコルで実現される。

逆に、規則が正しくても認証が弱ければ、他人になりすまされて規則の範囲内で不正な操作をされる。アクセス制御は、相手を正しく確かめることと、確かめた相手に正しく権限を与えることの両方がそろって初めて機能する。

許可をどう表すか

誰が何にどの操作をできるかは、主体を行、客体を列に並べた表で表せる。この表をアクセス制御マトリクスと呼ぶ。次は独自の例である。

主体給与ファイル規程集プリンタ
佐藤（人事）読取り・書込み読取り印刷
鈴木（営業）なし読取り印刷
バックアップ用プロセス読取り読取りなし

実際のシステムでは、この表をそのまま持つと空欄が多く無駄になる。そこで、表を列ごとに切り出して各客体に持たせるか、行ごとに切り出して各主体に持たせる。

客体ごとに「誰が何をできるか」の一覧を持たせたものをアクセス制御リスト（ACL）と呼ぶ。給与ファイルに「佐藤は読取り・書込み、バックアップ用プロセスは読取り」と付ける形である。ファイルシステムの多くはこの形を使う。

主体ごとに「何に何ができるか」を持たせたものをケイパビリティと呼ぶ。主体が持つ許可証を提示して操作する形である。前者の一覧は「この資源を誰が使えるか」を調べやすく、後者は「この主体が何を使えるか」を調べやすい。

規則を決める方式

アクセス制御の方式は、規則を誰がどのような情報で決めるかによって分けられる。

方式規則を決める主体・情報特徴
任意アクセス制御（DAC）客体の所有者持ち主が他者への権限を自由に設定できる。柔軟だが設定は持ち主任せになる
強制アクセス制御（MAC）システム全体の方針と、主体・客体に付けた機密区分利用者が自分で権限を変更できない
ロールベースアクセス制御（RBAC）職務に対応するロール利用者をロールに割り当て、ロールに権限を与える
属性ベースアクセス制御（ABAC）主体・客体・操作・環境の属性部署、データの分類、時刻、接続元などを組み合わせて判断する

任意アクセス制御は、NISTの用語集では、客体の持ち主が誰にどのような権利を与えるかを決める方式と説明されている（NIST用語集：DAC）。一般的なOSのファイル権限がこれにあたる。持ち主の判断ミスで情報が広く共有される危険がある。

強制アクセス制御では、中央の管理者が定めた方針に従い、持ち主でも権限を変えられない（NIST用語集：MAC）。情報の機密度と利用者の資格を比べて判断する。軍事・政府機関の情報管理が典型例であり、詳しくは強制アクセス制御の記事で扱う。

ロールベースアクセス制御は、NISTのモデルが2004年にANSI/INCITS 359-2004として標準化され、2012年にINCITS 359-2012として改訂された（NIST：RBACプロジェクト）。利用者ごとに権限を設定せず、「経理担当」「システム管理者」といった職務に権限を結び付ける。異動時はロールの割当てを変えるだけで済む。最小特権の原則に沿った権限設計の手段として広く使われる。

属性ベースアクセス制御は、NIST SP 800-162が定義を示している。「勤務時間内に社内ネットワークから接続した人事部の社員だけが、人事区分のデータを読める」のように、複数の属性を組み合わせた細かい規則を書ける。ロールの数を増やさずに条件を表現できる一方、規則の正しさを確かめる手間が増える。

OSのファイル権限で見る例

LinuxなどのUNIX系OSでは、ファイルごとに所有者・グループ・その他の三者に、読取り（r）・書込み（w）・実行（x）の許可を付ける。それぞれを数値の4・2・1で表し、合計で権限を示す。

次は独自の例である。所有者は読み書きでき、グループは読取りだけでき、その他は何もできないファイルの権限を数値で求める。

所有者 ＝ 読取り4 ＋ 書込み2 ＝ 6
グループ ＝ 読取り4 ＝ 4
その他 ＝ 0
権限 ＝ 640

この権限は所有者がchmodコマンドで変更できる。所有者が判断して許可を与えるため、任意アクセス制御の典型例である。三者の区別だけで表せない細かい許可が必要な場合は、個別の利用者を指定できるACLの機能を使う。

ルータやスイッチでの通信の制限

ルータやレイヤ3スイッチでは、通過するパケットを許可・拒否する規則の一覧もACL（アクセスリスト）と呼ぶ。こちらは送信元・宛先のIPアドレス、プロトコル、ポート番号を条件に、通信そのものを制御する。

次は、192.168.10.0/24の端末からサーバ10.0.0.5のTCP 443番への通信だけを許可する独自の設定例である。Cisco IOSの拡張ACLの書式を使っている。

access-list 110 permit tcp 192.168.10.0 0.0.0.255 host 10.0.0.5 eq 443
interface GigabitEthernet0/1
 ip access-group 110 in

0.0.0.255はサブネットマスクの0と1を反転させたワイルドカードマスクである。ACLは上から順に照合され、最初に一致した行の動作が適用される。どの行にも一致しなかった通信は、末尾にある暗黙の拒否によって破棄される（Cisco：Configure Commonly Used IP ACLs）。

この例ではACLを一つしか書いていないため、許可した通信以外はこのインタフェースで受信時に拒否される。例えばDNSによる名前解決が必要なら、その許可も明示的に書かなければならない。どのインタフェースに、受信（in）と送信（out）のどちらの向きで適用するかも結果を左右する。状態を追跡しない機器では戻りの通信の扱いにも注意が必要であり、その点はファイアウォールの記事で詳しく扱う。

判断する場所と実施する場所

大きなシステムでは、規則に基づいて許可・拒否を判断する機能と、実際に通信や操作を止める機能を分けて考える。NIST SP 800-162は、判断を行うPDP（Policy Decision Point）と、判断に従って制御を実施するPEP（Policy Enforcement Point）を区別している。判断に使う属性を提供するPIP、規則を管理するPAPもある。

機能役割
PDP規則を評価して、許可か拒否かを決める
PEP主体の要求を受け止め、判断結果に従って通す・止める
PIP判断に必要な属性情報を提供する
PAP規則を作成・管理する

IEEE 802.1Xによるネットワークの接続制御も、この分担で整理できる。LANスイッチや無線LANのアクセスポイントが接続を受け止めてポートの通信を制御し、RADIUSサーバが認証結果に基づいて接続の可否を返す。どの機器が判断し、どの機器が止めるのかを分けて読むと、構成図の役割を説明しやすい。

拒否を基本にする

規則に一致しなかった要求をどう扱うかは、安全性を大きく左右する。許可したものだけを通し、それ以外を拒否する既定拒否が基本である。上のCisco機器で末尾の行が通信を捨てるのも、この考え方による。

クラウドの権限管理も同じ考え方を採る。AWSのIAMでは、すべての要求は既定で拒否され、ポリシーで明示的に許可されたものだけが通る。さらに、適用されるポリシーに明示的な拒否が一つでもあれば、ほかに許可があっても最終的に拒否される（AWS IAM：ポリシー評価ロジック）。広い許可を与えたうえで、特定の操作だけを確実に禁止したい場合に使う。

権限設計の原則との関係

アクセス制御は仕組みであり、どれだけの権限を与えるべきかは別の原則で決める。業務に必要な分だけを与える最小特権の原則、知る必要がある人だけに情報を開示するneed-to-knowの原則、一人に不正が可能な権限の組合せを持たせない職務分離がその代表である。これらの原則の詳細は最小特権の原則の記事で扱う。

設定した権限は、運用とともに実態とずれていく。異動者の古い権限や退職者のアカウントが残ると、規則が正しく動いていても不要なアクセスが可能になる。定期的な権限の棚卸しと、アクセスログの確認を運用に組み込む。

実装で起きやすい不備

Webアプリケーションでは、画面にボタンを表示しないだけで操作を制限したつもりになる誤りが起きやすい。利用者がURLやパラメータを書き換えて直接要求すれば、表示されていない操作も実行できてしまう。権限の判断は、要求を受け付けるサーバ側で毎回行う必要がある。

ネットワークでも、ACLの順序を誤ると意図しない通信が通る。広い範囲を許可する行を先に書くと、後ろに書いた拒否の行が評価されない。変更時には、許可すべき通信と拒否すべき通信の両方を試験する。

午後での問われ方

参考資料

この用語が出てくる記事

↑