最小権限の原則、解説

最小権限の原則は声に出して言うと明らかに思える：アカウント、プロセス、ユーザーに仕事をするために必要なアクセスだけを与える。それ以上は与えない。それを言うことと実際にシステムをそのように運用することの間には、ブリーチが軽微なインシデントから完全なドメイン侵害に変わる大きなギャップがある。

実際の意味

最小権限の原則（PoLP）は、システム内のあらゆる対象者（ユーザー、サービスアカウント、アプリケーション、コンテナ）が、その機能を実行するために必要な最小限の権限セットで動作すべきだと述べている。便利な権限ではなく。3年前に誰かが与えて取り消すのを忘れた権限でもなく。最小限だ。

これはすべてのレイヤーに適用される：ファイルシステムの権限、データベースロール、API スコープ、クラウド IAM ポリシー、ファイアウォールルール、sudo アクセス。静的ファイルを読むウェブサーバープロセスは /etc への書き込みアクセスが必要ない。SELECT クエリだけを実行するレポートスクリプトは DROP TABLE 権限のあるデータベースロールが必要ない。マーケティングのインターンが正しいグループを把握するより簡単だからとドメイン管理者権限が必要なわけではない。

なぜそれが聞こえるより重要なのか

攻撃者がアカウントやプロセスを侵害すると、そのアカウントができることすべてを引き継ぐ。フィッシングされた従業員のラップトップが自分のチームに関連するファイル共有へのアクセスだけを持っていれば、そのフィッシングの被害範囲は限定される。同じアカウントがトラブルシューティングのために IT が設定し、ロールバックしなかったドメイン管理者権限を持っていたら、攻撃者はネットワークを支配している。

これがほとんどのブリーチ後の法医学調査レポートの背景にある論理だ：初期アクセスは低い価値だったが、権限が多すぎるアカウント経由のラテラルムーブメントが、環境全体へのランサムウェアに変えた。過剰な権限は初期の侵害を引き起こさないが、侵害を高額にするほぼすべての要因だ。

実践での現れ方

クラウド IAM。 AWS、Azure、GCP はすべて、注意を払わないと許容的な動作がデフォルトだ。"Action": "*" と "Resource": "*" を持つ IAM ポリシーは検証を通り、完全に機能する。リークされたアクセスキーが攻撃者に完全なアカウント制御を与えるまでは。ワイルドカードに手を出さず、特定のアクションとリソース ARN へのポリシーのスコープを定める。

サービスアカウント。 人間のアカウントを確認する方法で誰も確認しないため、これらはしばしば最も悪い違反者だ。1つの S3 バケットにデプロイする CI/CD パイプラインが、アカウント内のすべてのバケットを読み取りできる認証情報を保持するべきではない。

データベースロール。 読み取り専用のレポートロールをアプリケーションロール（INSERT/UPDATE が必要）から分離し、それらをスキーマを変更できる DBA ロールから分離する。PostgreSQL と MySQL はどちらも細かい粒度の GRANT ステートメントをサポートしている。すべてのアプリ接続にルート相当のものを与える代わりに、それを使用する。

Sudo とローカル管理者。 ジャストインタイムエレベーション（アクセスをリクエスト、限定された時間枠でそれを取得、自動的にそれを失う）は常時管理者権限より常に優れている。時間制限ルール付きの sudo などのツール、またはエンタープライズ環境での PAM ソリューションは、まさにこのために存在する。

次の矛盾