「管理者権限でログインしたまま作業している」「部署異動後も古い権限がそのまま残っている」——こうした状況が積み重なると、サイバー攻撃者に侵入された際に被害が一気に広がります。
セキュリティの世界では、こうしたリスクを根本から抑える考え方として「最小権限の原則」（PoLP: Principle of Least Privilege）が長年にわたって重視されています。
この記事では、最小権限の原則の概念から、Linux・Windows・クラウド環境での具体的な実装方法、そして情シス1人体制でもすぐ使える実践チェックリストまでをまとめて解説します。
最小権限の原則とは？
最小権限の原則とは、「ユーザー・プロセス・システムに対して、業務に必要な最低限の権限しか与えない」という情報セキュリティの基本原則です。
英語では “Principle of Least Privilege”（略称：PoLP または POLP）と呼ばれ、1970年代にコンピュータサイエンスの研究者 Jerome Saltzer と Michael Schroeder によって体系化されました。現在では、NIST（米国国立標準技術研究所）や CIS Controls などの主要なセキュリティフレームワークにも中核原則として組み込まれています。
1. 最小権限の原則が守る3つのこと
・被害の局所化: 攻撃者がアカウントを乗っ取っても、そのアカウントで操作できる範囲が限定されます。ランサムウェアが特定ユーザーに感染しても、ファイルサーバー全体を暗号化できません。
・内部不正の抑止: 退職者・異動者の不必要な権限が制限されるため、意図的な情報持ち出しが起きにくくなります。
・誤操作のリスク低減: 必要以上の権限がなければ、うっかり重要データを削除したり、設定を壊したりする事故も防げます。
なぜ今「最小権限」が重要なのか
近年のサイバー攻撃は、最初の侵入口から水平方向に広がる「ラテラルムーブメント（横移動）」が主流になっています。
たとえば、フィッシングメールで一般社員のPCに侵入した攻撃者は、そのPC上の認証情報を使って社内ネットワークを調べ、より権限の高いアカウントを探します。ここで管理者権限が必要以上に多くのユーザーに配られていると、攻撃者はすぐにドメイン管理者権限まで到達できてしまいます。
IPA（独立行政法人情報処理推進機構）が公表したランサムウェア被害事例の調査では、被害が広範囲に及んだケースの多くで「過剰な管理者権限の付与」が被害拡大の一因として繰り返し指摘されています。
最小権限の原則は「攻撃を防ぐ」というより「攻撃が成功しても被害を最小化する」考え方です。完璧な防御が存在しない以上、被害の封じ込めは現代のセキュリティにおいて欠かせないアプローチです。
最小権限を実装する3つのステップ
1. 現状の権限棚卸し（インベントリ作成）
まず「誰が何の権限を持っているか」を把握しないことには始まりません。多くの企業でこの棚卸しを実施すると「なぜこのアカウントが管理者権限を持っているのか誰もわからない」という状況が発覚します。
Linuxサーバーであれば、以下のコマンドで特権ユーザーや sudo 権限を持つアカウントを確認できます。
# rootグループに属するユーザーを確認 getent group root # sudo権限を持つグループのメンバーを確認 getent group sudo wheel # sudoersファイルの確認（root権限が必要） sudo cat /etc/sudoers | grep -v "^#" | grep -v "^$" # パスワードなしsudoを許可している設定を探す（危険な設定の洗い出し） sudo grep -r "NOPASSWD" /etc/sudoers /etc/sudoers.d/
Windowsドメイン環境では、Active Directory（AD）の「Domain Admins」「Enterprise Admins」グループのメンバーを定期的に確認することが最初の一歩です。PowerShellを使えば一括で棚卸しできます。
# Domain Adminsグループのメンバーを一覧表示 Get-ADGroupMember -Identity "Domain Admins" | Select-Object Name, SamAccountName # 過去90日以上ログインがないアカウントを確認 $cutoff = (Get-Date).AddDays(-90) Get-ADUser -Filter {LastLogonDate -lt $cutoff -and Enabled -eq $true} ` -Properties LastLogonDate | Select-Object Name, LastLogonDate
2. 業務に必要な権限の最小化
棚卸しが終わったら、各アカウント・ロールに「本当に必要な権限」だけを残します。
Linuxサーバーの場合
日常業務では root アカウントを直接使わず、作業に必要なコマンドだけを sudo で実行できるよう設定します。
# visudo で特定コマンドのみ許可する例 # ユーザー "webdev" はサービス再起動のみ許可 webdev ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx, /bin/systemctl restart php-fpm # ユーザー "backup" はバックアップスクリプトのみ許可 backup ALL=(ALL) NOPASSWD: /usr/local/bin/backup.sh
この設定では、`webdev` アカウントが侵害されても、攻撃者は nginx と php-fpm の再起動しかできません。サーバーの設定ファイルを書き換えたり、新規ユーザーを作成したりする操作はできません。
ファイルサーバーの場合
部署ごとにフォルダを分け、「自分の部署フォルダだけ読み書きできる」という権限設計が基本です。経営層だけが参照できる財務フォルダ、人事部だけが編集できる人事フォルダなど、情報の機密レベルに合わせた階層設計が重要です。
アクセス制御モデルとしては以下の3種類が代表的です。
| モデル | 概要 | 適した場面 |
|---|---|---|
| DAC（任意アクセス制御） | 所有者が自分でアクセス権を設定できる。Linuxのchmodが代表例 | 小規模・柔軟性重視の環境 |
| MAC（強制アクセス制御） | システムがポリシーを強制。所有者でも変更できない。SELinuxが代表例 | 高セキュリティ要件（政府・金融など） |
| RBAC（ロールベースアクセス制御） | ロール（役割）に権限を付与し、ユーザーはロールに紐づく。Active DirectoryのGroupが代表例 | 中・大規模組織の権限管理 |
中小企業の情シスには、個人単位の権限管理よりRBACが特に有効です。「営業スタッフ」「経理担当」「IT管理者」のようなロールを定義しておけば、採用・異動のたびに個別設定する手間が省けます。
クラウド（AWS）の場合
IAM（Identity and Access Management）ポリシーでは、必要なサービスと操作だけを明示的に許可します。日常的な運用作業に「AdministratorAccess」のような広すぎるポリシーを使い続けることは避けましょう。
# 悪い例：広すぎる権限（何でもできてしまう） { "Effect": "Allow", "Action": "*", "Resource": "*" } # 良い例：S3の特定バケットへの読み取りだけ許可 { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::my-app-bucket", "arn:aws:s3:::my-app-bucket/*" ] }
AWS環境では「IAM Access Analyzer」を活用すると、実際には使われていない権限を自動検出できます。定期的に実行して、不要な権限を削っていく運用が推奨されます。
3. 定期的な見直しとアクセスレビュー
権限は一度設定して終わりではありません。人事異動・退職・プロジェクト終了のたびに権限を見直す「アクセスレビュー」を定期実施することが重要です。
少なくとも以下のタイミングで見直しを行いましょう。
・月次: システム管理者・特権アカウントの棚卸し
・四半期: 全ユーザーの権限棚卸し、不要アカウントの無効化
・都度: 退職・異動・プロジェクト終了時の即日権限削除
特に退職者のアカウント無効化は「翌月まとめて処理」ではなく、退職日当日に実施することをルール化してください。内部不正リスクの観点からも、人事・IT担当間で「退職情報の即日共有フロー」を整備することが重要です。
中小企業でも今日からできること
「大企業向けの話では？」と感じた方もいるかもしれませんが、最小権限の原則は規模に関係なく適用できます。特にリソースが限られた中小企業の情シスにとって、被害の封じ込めはコストをかけずにセキュリティレベルを引き上げる最も効果的なアプローチの一つです。
まず1週間以内にできることから始めましょう。
・管理者権限アカウントの棚卸し: Administrator・root などの特権アカウントが何人に付与されているか確認する。日常業務に管理者権限が不要なユーザーはすぐに削除する。
・退職者アカウントの確認: 直近1年以内に退職・異動したメンバーのアカウントが残っていないか確認し、存在するものは即日無効化する。
・共有アカウントの廃止: 複数人が「admin/admin123」のような共有アカウントで作業している場合は、個人ごとのアカウントに移行する。誰が何をしたかのログが残らないため、インシデント時の原因特定が不可能になります。
・SSHのrootログイン禁止: Linuxサーバーの sshd_config で `PermitRootLogin no` を設定する。rootへの直接ログインを禁止するだけでも、侵害リスクは大きく下がります。
これらは特別なツールなしに実施できる、最もコスパの高い対策です。
よくある誤解と注意点
【誤解1】管理者に管理者権限は常に必要
インフラ担当者でも、日常のファイル作業・メール・Web閲覧は一般ユーザー権限で行い、サーバー操作が必要なときだけ sudo や管理者権限を使う運用が推奨されます。「管理者だから常に管理者権限でログインしている」という状態は避けましょう。万が一フィッシングでアカウントが侵害されたとき、攻撃者が管理者権限を即座に手に入れてしまいます。
【誤解2】最小権限にすると業務が不便になる
業務フローを整理せずに権限を削りすぎると確かに不便になります。重要なのは「業務に必要な権限を漏らさず与え、それ以外を削る」ことです。業務フローを事前に整理し、必要な権限を明確にした上で設計することで、利便性を損なわずに実現できます。導入時は現場担当者と丁寧にヒアリングし、「困ったらすぐ相談」できる窓口を設けておくとスムーズに移行できます。
【誤解3】権限を絞れば監視は不要
最小権限はあくまでも「被害の最小化」であり、攻撃の検知・対応は別レイヤーで実施する必要があります。権限を絞った上で、アクセスログの監視・異常検知（IDS/IPS・EDRなど）を組み合わせることで多層防御が完成します。「最小権限を設定したから安心」という油断がむしろリスクになります。
実践チェックリスト
以下のチェックリストを自社環境に照らし合わせてみてください。
| カテゴリ | チェック項目 | 優先度 |
|---|---|---|
| アカウント管理 | 特権アカウント（管理者・root）の棚卸しを実施済み | 高 |
| アカウント管理 | 退職者・異動者のアカウントが即日無効化される運用フローがある | 高 |
| アカウント管理 | 共有アカウント（admin/adminなど）が廃止されている | 高 |
| Linux | rootへの直接SSH接続を禁止している（PermitRootLogin no） | 高 |
| Linux | sudoersで必要なコマンドのみ許可している（全権委任のNOPASSWD ALLは不使用） | 中 |
| Windows/AD | Domain Adminsグループのメンバーが最小限に絞られている | 高 |
| クラウド | IAMユーザー・ロールに必要最小限のポリシーだけが付与されている | 中 |
| クラウド | IAM Access Analyzerなどで未使用権限を定期的にチェックしている | 中 |
| 運用 | アクセスレビュー（権限棚卸し）を四半期ごとに実施している | 中 |
| 運用 | 権限付与・変更の申請・承認プロセスが文書化されている | 低 |
「優先度：高」の4項目から着手するだけでも、セキュリティレベルは大きく向上します。
本記事のまとめ
最小権限の原則（PoLP）は、複雑なツール導入なしに今日から取り組める、最もコスパの高いセキュリティ対策の一つです。
・最小権限の原則（PoLP）: 業務に必要な最低限の権限しか与えない考え方。ラテラルムーブメントによる被害拡大を封じ込める基本原則
・実装3ステップ: ①棚卸し（現状把握）→ ②最小化（不要権限の削除）→ ③定期レビュー（維持運用）
・アクセス制御モデル: 中小企業にはRBAC（ロールベース）が特に有効。ロール設計で採用・異動のたびの個別設定を不要にできる
・今日からできること: 特権アカウント棚卸し・退職者アカウント確認・共有アカウント廃止・SSHのrootログイン禁止
Linuxのファイルパーミッション設定や sudo の細かい設定については、姉妹サイトLinuxMaster.JPでも実践的な解説を公開しています。Linuxサーバーの権限管理を深く学びたい方はあわせてご参照ください。
権限管理、本当にこれで大丈夫ですか？
最小権限の原則は「基本中の基本」ですが、実際に現場で徹底できている企業はそう多くありません。
正しいセキュリティ知識を体系的に身につけたい方へ、メルマガで実践的なセキュリティ対策ノウハウをお届けしています。
コメント