女性向けエンジニアスクール
3秒でわかる
必要な権限だけを必要な期間だけ与える設計原則。事故や乗っ取りが起きたときに、被害が広がる範囲を先に狭めておくための考え方です。
もう少し詳しく
どういうものか
最小権限は、人にもプログラムにも、仕事を終えるのに必要な最小限の権限だけを与えるという原則です。OSのファイル権限、クラウドのIAMロール、データベースのアカウント、APIトークンの適用範囲まで、あらゆる層に当てはまります。判断の順序が要点で、便利だから全部許可して問題が出たら絞るのではなく、何も許可しない状態から必要なものだけを足していきます。
なぜ必要か
侵入や事故は起きる前提で考えます。そのときに何が起きるかを決めるのが権限の広さです。管理者権限のトークンが漏れれば全データが読まれ消されますが、特定バケットの読み取りだけのトークンなら被害はそこで止まります。人為的なミスにも同じ効き目があります。本番のDBへ削除権限が無ければ、誤ったコマンドは実行できずに終わります。攻撃を防ぐのではなく、防げなかったときの範囲を先に区切っておくための原則です。
具体例
# アプリ用のDBユーザーに読み書きだけを許し、削除系は与えない
CREATE USER 'app'@'10.0.%' IDENTIFIED BY '...';
GRANT SELECT, INSERT, UPDATE ON shop.* TO 'app'@'10.0.%';
# DROP, ALTER, GRANT は付けない
# ファイルはまず全部閉じてから、必要な人だけ開ける
chmod 600 /etc/app/secrets.env
chown app:app /etc/app/secrets.env
# 実行はサービス専用ユーザーで行い、root で起動しない
sudo -u app /usr/local/bin/app-serverクラウドでは、関数ごとに専用のロールを作り、扱うリソースを名前で限定します。全リソースを対象にした許可を1つ置くと、他の資源まで巻き込まれます。
つまずきやすいところ
動かないときにとりあえず広い権限を付けて解決し、そのまま戻し忘れるのが最も多い経路です。検証のために広げたら、動いた後に必要な範囲まで削るところまでを1つの作業にします。もうひとつは、権限を絞りすぎて運用が回らなくなり、結局全員が管理者権限を共有する状態へ揺り戻す失敗です。申請すれば短時間だけ昇格できる仕組みを併せて用意すると、この揺り戻しが起きません。読み取りだけなら安全という思い込みも危険で、個人情報や鍵を含むテーブルは読めるだけで重大な漏洩になります。
似た用語との違い
| 語 | 意味 |
|---|---|
| 最小権限 | 必要な権限だけを与える |
| 職務分掌 | 一人が全工程を完結できないよう役割を分ける |
| 多層防御 | 対策を重ねて1つ破られても止まるようにする |
この3つは競合せず、組み合わせて使う前提の考え方です。
