最小特権の原則

読み：さいしょうとっけんのげんそく　／　英語表記：Principle of Least Privilege

• セキュリティ

利用者やプログラムには、与えられた業務を行うのに必要最小限の権限だけを与えるという情報セキュリティの設計原則である。権限の範囲だけでなく、権限を持つ期間も必要な間に限ることで、誤操作や不正利用による被害を小さくする。

イマシルちゃんの解説

会社のシステムでは、社員ごとに使える機能や見られるデータが決められているよ。
もし全員に何でもできる管理者の権限を配ったら、操作ミスひとつで大事なデータが消えてしまうかもしれないんだ。
アカウントが乗っ取られたときも、攻撃者はその広い権限をそのまま使えちゃう。
そこで、仕事に要る分の権限だけを渡すという設計の原則が生まれたの。
これを最小特権の原則というよ。
経理担当なら会計システムへの入力だけ、サーバの設定変更は管理者だけ、という具合に分けるんだ。
権限を絞っておけば、ミスや乗っ取りが起きても被害の広がりを抑えられるよ。

より深い解説

定義と位置付け

最小特権の原則（Principle of Least Privilege）は、システムの利用者やプロセスに、業務の遂行に必要な権限だけを与えるという原則である。1975年にSaltzerとSchroederが示した情報保護の設計原則の一つとして知られる。原論文は「すべてのプログラムと利用者は、仕事を終えるのに必要な最小の特権で動作すべきだ」と述べている（The Protection of Information in Computer Systems）。

この原則は特定の製品や技術の名前ではない。アクセス制御、アカウント管理、ネットワーク設計、ソフトウェアの実行環境など、あらゆる場面で権限を設計するときの判断基準である。NISTのセキュリティ管理策カタログでは、アクセス制御の管理策AC-6として位置付けられている（NIST SP 800-53 Rev. 5）。

ここでいう特権（権限）は、システム上で特定の操作を行う資格を指す。ファイルの読取りや書込み、設定の変更、アカウントの作成、他の利用者のデータへのアクセスなどが含まれる。日本語では「最小権限の原則」とも呼ばれる。

なぜ権限を絞るのか

権限を広く与えても、普段の業務が正しく行われている間は問題が表に出ない。問題になるのは、想定外の事態が起きたときである。

いずれの場合も、最小特権の原則は事故や攻撃の発生そのものを防ぐわけではない。発生したときの被害範囲を限定するための原則である。この考え方は、被害の及ぶ範囲を表す「爆発半径（blast radius）」を小さくする、と表現されることもある。

権限を設計する手順

最小特権を実際のシステムに反映するには、業務から権限を逆算する。権限を先に配ってから不要なものを削るのではなく、何も許可しない状態から必要なものを足していく。

1. 業務を洗い出し、各担当者がどのシステムで何をするかを整理する。
2. 業務ごとに必要な操作（参照・登録・更新・削除・設定変更など）と、対象のデータを特定する。
3. 同じ業務を行う人の権限をまとめてロールを定義し、利用者をロールに割り当てる。
4. 付与する権限を、申請と承認の手続きを経て設定する。
5. 定期的に権限の棚卸しを行い、現在の業務に合わない権限を削除する。
6. 異動・退職・委託契約の終了時には、すぐに権限を見直す。

3.のように、利用者個人ではなく役割に権限を割り当てる方式をロールベースアクセス制御（RBAC）と呼ぶ。個人ごとに権限を設定するより管理しやすく、異動時もロールを付け替えるだけで済む。

次は販売管理システムの権限を設計した独自の例である。

システム管理者に業務データへのアクセス権を与えていない点に注意する。システムを管理する人が、必ずしも業務データを見る必要はないからである。

権限が時間とともに膨らむ問題

最初に適切な権限を設定しても、運用を続けるうちに権限は増えていきやすい。異動のたびに新しい権限が追加され、古い権限が削除されないまま残ることが原因である。この現象を権限の肥大化（privilege creep）と呼ぶ。

例えば、営業部から経理部へ異動した社員に経理のロールを追加し、営業のロールを外し忘れたとする。この社員は二つの部署の権限を併せ持つことになり、どちらの業務にも不要な組合せが生まれる。定期的な棚卸しと、人事情報と連動したアカウント管理によって、こうした残存権限を減らす。

退職者のアカウントが残る問題も同じ構造である。使われていないアカウントは利用者自身が異常に気付かないため、乗っ取られても発見が遅れやすい。

管理者アカウントの扱い

システムの設定変更やアカウント管理ができる管理者用のアカウントを特権IDと呼ぶ。Linuxのroot、Windowsの管理者アカウント、ネットワーク機器の管理者アカウント、データベースの管理者アカウントなどが該当する。特権IDは影響範囲が大きいため、最小特権の原則を特に厳しく適用する。

日常用と管理用の分離については、NIST SP 800-53のAC-6の強化策AC-6(2)も、セキュリティ以外の機能を使うときは特権のないアカウントを使うよう求めている。管理者権限のアカウントでメールを開けば、添付ファイルのマルウェアも管理者権限で動くおそれがあるためである。

必要なときだけ権限を与える考え方は、ジャストインタイム（JIT）アクセスとも呼ばれる。権限を時間の面でも絞る具体的な実装である。

Linuxでは、一般の利用者がsudoを使い、許可されたコマンドだけを管理者権限で実行できるように設定できる。次は、ネットワーク担当者のグループにネットワーク設定の再読込みだけを許可する独自の設定例である。

%netops ALL=(root) /usr/bin/systemctl restart systemd-networkd

この設定では、netopsグループの利用者はネットワーク関連のサービスを再起動できるが、それ以外のコマンドをroot権限で実行することはできない。rootのパスワードを共有して全員に渡すのに比べ、許可する操作と操作者を限定できる。

プログラムとサービスへの適用

最小特権の原則は、人が使うアカウントだけでなく、プログラムやサービスにも適用する。

Webサーバのプロセスを管理者権限で動かすと、Webアプリケーションの脆弱性を突かれたときにOS全体を操作されるおそれがある。そのため、Webサーバは特権のない専用のアカウントで動かす。80番などのポートを開くために起動時だけ特権を使い、その後は一般権限に切り替える実装もある。

データベースに接続するアプリケーションには、必要な表への必要な操作だけを許可した専用アカウントを使う。参照しかしない画面のためのアカウントに削除の権限を与えない。こうしておけば、SQLインジェクションの脆弱性があっても、攻撃者が実行できる操作は限られる。

クラウドサービスでも同じである。サーバやプログラムに与えるアクセスキーやロールには、利用するサービスと操作だけを許可する。すべての操作を許可したキーが漏えいすると、クラウド環境全体を操作されるおそれがある。

ネットワーク設計への適用

ネットワークでは、通信の許可を必要な範囲に限ることが最小特権の原則の適用にあたる。

• ファイアウォールでは、必要な通信だけを許可し、それ以外を拒否するデフォルト拒否でルールを組み立てる。
• 機器の管理画面やSSHへの接続は、管理用のセグメントにある端末からだけ許可する。
• SNMPで監視だけを行うなら、設定を変更できる書込み権限を与えず、読取り専用のアクセスにする。
• サーバ同士の通信も、必要な組合せとポートだけを許可する。DMZの公開サーバから内部ネットワーク全体への通信を許可しない。
• ネットワークをVLANなどで細かく区切り、侵害された端末から到達できる範囲を限る。

このようにネットワークを細かく分割して通信を制御する設計は、マイクロセグメンテーションとも呼ばれる。端末やサーバの単位まで許可範囲を絞る考え方であり、侵入後に攻撃者が隣のシステムへ移る横展開（ラテラルムーブメント）を難しくする。

関連する原則との区別

最小特権の原則と並んで、権限設計にかかわる原則がいくつかある。何を制限するかで区別する。

need-to-knowの原則は、情報へのアクセスについて「知る必要があるか」で判断する考え方であり、最小特権の原則と重なる部分が大きい。最小特権が操作全般の権限を対象にするのに対し、need-to-knowは情報の開示範囲に焦点を当てる。

一人に権限を集中させないこの原則は、例えば支払データの登録と承認を別の人が行うようにする原則である。一人ひとりの権限が最小でも、一人が登録と承認の両方を持てば不正が可能になる。そのため、権限の大きさだけでなく組合せも確認する。

運用上の課題と例外への備え

権限を絞りすぎると、業務が止まる。必要な作業のたびに申請と承認を待つ運用では、利用者が不便を避けるために共有アカウントを使い回すなど、かえって危険な回避策が生まれることがある。権限の申請から付与までの手続きを短くし、実際の業務と合った権限設計を保つことが大切である。

障害対応などの緊急時に備えて、通常は使わない強い権限のアカウントを用意する場合がある。このような緊急用アカウントは、パスワードを封印して保管し、使用したら必ず記録を確認して、使用後にパスワードを変更する。緊急用だからといって常時使える状態にしてはならない。

午後での問われ方

• 運用管理者や委託先に与える権限の構成を示し、最小特権の原則に反している点と、その改善策を答えさせる。
• 管理用アカウントを共有している運用の問題点や、日常用と管理用のアカウントを分ける理由を説明させる。
• ネットワーク機器の管理アクセスやSNMPの設定で、許可する送信元や権限を絞る設定を選ばせる。
• サーバ間のファイアウォールルールを設計させ、侵害時の被害拡大を防ぐ観点から許可する通信を答えさせる。
• 異動・退職時のアカウント管理や、定期的な権限見直しの必要性を記述させる。

この用語が出てくる記事

• アクセス制御
• need-to-knowの原則