「入社時に管理者権限を付与したまま、3年が経過している」「退職した社員のアカウントがSaaSに残っている」——情報システム部門が管理するSaaS環境では、こうした状況が静かに積み重なっています。

SaaS利用が広がるほど、各ツールに設定された権限の数は増え、個別に見直す機会は減ります。部門からの「早く使えるようにしてほしい」という声に応えた結果、とりあえず広めの権限を付与し、後で絞るつもりが絞れないまま運用が続く。これは多くの情シス担当者が経験している現実です。

こうした権限の肥大化を防ぐための設計思想が、最小権限の原則（Principle of Least Privilege）です。ゼロトラストセキュリティの文脈でも中核的な概念として位置づけられており、SaaSの増加とリモートワークの定着によって、その重要性はかつてないほど高まっています。

最小権限の原則の定義から、SaaS環境での実装方法、継続的な運用を支える自動化の考え方まで、情シス部門の実務視点で解説します。

最小権限の原則とは何か

最小権限の原則とは、ユーザー・システム・プロセスが、業務の遂行に必要な最低限の権限のみを持つべきという情報セキュリティの基本原則です。英語では「Principle of Least Privilege（PoLP）」と呼ばれ、1970年代にコンピュータサイエンティストのジェローム・ソルツァー（Jerome Saltzer）とマイケル・シュローダー（Michael Schroeder）が提唱した概念にさかのぼります。

セキュリティ3原則との関係

情報セキュリティの基本は、機密性（Confidentiality）・完全性（Integrity）・可用性（Availability）の3つで構成されます。最小権限の原則は、このうち機密性と完全性の保護に直接寄与します。

必要のない情報へのアクセスを制限することで、意図しないデータ漏えいや改ざんのリスクを低減できます。業務上アクセスする理由がないデータを参照できなければ、たとえアカウントが侵害されても被害範囲は限定的になります。可用性への影響については、適切な権限設計と申請フローを整備することで、業務を止めずに権限を絞ることが可能です。

最小権限が特に重要になった背景

オンプレミス中心の時代には、アクセス権の管理はActive DirectoryやLDAPに集約されており、一元的な管理が比較的容易でした。しかしSaaSの普及により、社員一人あたりが利用するサービスの数は増加し、各SaaS上の権限は個別に管理される状態になっています。

IPAが公表した「企業における情報セキュリティ実態調査」でも、クラウドサービス利用に伴うアクセス権管理の複雑化が課題として上位に挙がっています。リモートワークの定着により、オフィス内ネットワークという物理的な境界が曖昧になった今、「誰が・何に・どの権限でアクセスできるか」を正確に把握し制御することは、セキュリティの根幹となっています。

SaaSの普及に伴い、権限管理の難しさは量と分散の両面で増しています。ひとつの企業が利用するSaaSが50〜100種類に達するケースも珍しくなく、それぞれの管理画面で権限を個別に設定・管理するのは、もはや人の手では追いきれません。これが、ツールによる自動化と最小権限の原則の組み合わせが注目される背景です。

参考： IPA「企業における情報セキュリティ実態調査 2023」

最小権限の原則が守られないと何が起きるか

権限管理の運用が形骸化すると、セキュリティリスク・コンプライアンスリスク・運用コストの3つの側面で問題が生じます。それぞれを具体的に見ていきます。

内部不正と意図しない情報漏えい

過剰な権限を持つ社員は、業務上必要のない情報にアクセスできる状態にあります。悪意のある行為だけでなく、「参考までに見てみた」という軽い動機でも、アクセスした事実がコンプライアンス上の問題になることがあります。

人事情報・顧客データ・財務情報といった機密性の高いデータに、必要のない部門の社員がアクセスできている状態は、内部統制の観点からも問題です。権限の付与履歴が残っていない場合、後から監査で指摘されても経緯を説明できません。

外部攻撃による被害拡大

フィッシングメールや認証情報の漏えいによってアカウントが乗っ取られた場合、そのアカウントに付与されている権限の範囲が、被害の上限を決めます。管理者権限を持つアカウントが侵害されれば、攻撃者はシステム全体にアクセスできることになります。最小権限の原則が徹底されていれば、1つのアカウントが侵害されても被害は限定的なスコープにとどまります。

J-SOX・ISMSでのコンプライアンス要件

J-SOX対応では、財務報告に影響するシステムを中心に、IT全般統制の一環としてアクセス管理が確認されます。具体的には、業務上の必要性に基づいた権限付与、職務分離の徹底、定期的なアクセス権のレビューが監査対象となります。

ISMS（ISO 27001）においても、「アクセス制御」は主要な管理策の一つであり、最小権限の原則はその中核をなす考え方です。認証取得を目指す企業はもちろん、取得済みの企業でも更新審査でアクセス権管理の実態が確認されます。

退職者アカウント経由のリスク

退職や転職の際に、SaaSの権限削除が漏れるケースは珍しくありません。IDaaSとSaaSの連携が不十分な場合、人事システム上は退職済みでも、各SaaS上ではアカウントが有効なまま残ることがあります。在職中に管理者権限を持っていた元社員のアカウントが残存していれば、退職後もアクセスが可能な状態が続きます。

米国の調査では、退職後も旧職場のクラウドサービスに不正アクセスした事例が複数報告されており、日本でも同様のインシデントが発生しています。退職者アカウントはパスワードを知られており、多要素認証のリセットが未実施の場合は侵入の難易度が低いという特徴があります。こうした「孤立アカウント」は、最小権限の原則が守られている組織でも、デプロビジョニングが徹底されていなければ深刻なリスクとなります。

参考： NISC「クラウドサービスの安全・信頼性に係る情報開示指針」

SaaS環境で最小権限を実装する方法

最小権限の原則を実際のSaaS環境に適用するには、権限の設計・申請フロー・自動化・定期レビューの4つを組み合わせたアプローチが必要です。

ロールベースアクセス制御（RBAC）の設計

RBAC（Role-Based Access Control）は、個人ではなく「役割（ロール）」に対して権限を紐付ける設計手法です。個人ごとに権限を設定すると、社員数が増えるほど管理が複雑になりますが、ロール単位で管理することで標準化と効率化が実現できます。

導入時のステップは次のとおりです。まず、職種・部門・職位の組み合わせでロールを定義します。たとえば「営業部 一般社員」「IT部門 管理者」「経理部門 閲覧のみ」といった粒度でロールを設計します。次に、各ロールに対してアクセスできるSaaSと権限レベル（閲覧・編集・管理者等）をマッピングします。

ロール設計で重要なのは、例外を極力作らないことです。例外が増えると管理の複雑度が増し、最小権限の原則から外れた権限が常態化します。業務上本当に必要な場合のみ、個別申請で一時的な権限を付与する設計が望ましいです。

ロールは最低でも年1回、組織改編のタイミングで必ず見直します。組織構造や業務内容が変わっても権限の定義が更新されないと、ロールの意味が形骸化します。

権限付与・変更の申請フロー整備

「管理者に直接Slackで連絡して権限を付与してもらう」という運用は、速度の面では便利ですが、証跡が残らず、承認プロセスが不透明になります。ワークフローを通じた申請・承認・付与のプロセスを整備することで、権限変更の根拠と経緯を記録できます。

申請フローに含めるべき要素は以下のとおりです。

• 申請者・申請日・対象SaaS・要求する権限レベルの記録
• 申請理由（業務上の必要性）の明示
• 承認者（申請者の上長またはシステム管理者）による承認
• 承認後の権限付与完了通知
• 権限の有効期間（期限付き権限の設定）

権限昇格（一般権限から管理者権限への変更等）については、通常の申請よりも承認者を増やすか、情シスによる二次確認を必須とする設計が推奨されます。

フローの設計で見落とされがちなのが「期限付き権限」の考え方です。プロジェクト参加を理由に一時的に付与した権限が、プロジェクト終了後も残り続けるケースは多くあります。権限付与の時点で有効期間を設定し、期限到来後は自動的に剥奪されるか、延長申請を求める仕組みを組み込むことで、意図しない権限の長期残存を防ぐことができます。

入退社・異動時の自動デプロビジョニング

入退社・異動は、権限管理上もっとも重要なタイミングです。退職時には全SaaSの権限を漏れなく削除し、異動時には旧部門の権限を剥奪したうえで新部門に適した権限を付与する必要があります。

手動で対応する場合、情シス担当者は退職処理のたびに利用中のSaaSをリストアップし、一件ずつ権限削除の作業を行います。SaaSが10種類あれば10件、30種類あれば30件の手作業が発生します。この作業に漏れが生じると、退職者アカウントが残存するリスクが生まれます。

理想的なのは、人事システムやIDaaSの退職処理と連動して、全SaaSのアカウント削除が自動実行される仕組みです。異動については、旧ロールの権限剥奪と新ロールの権限付与を同時に処理できる自動化が必要です。

定期的なアクセス権レビュー（アクセスレビュー）

日々の運用で権限を適切に管理していても、時間の経過とともにズレが生じます。業務の変化・プロジェクト単位での一時権限・申請フローを経ずに付与された権限など、気づかないうちに権限が肥大化するケースがあります。これを防ぐのがアクセスレビュー（Access Review）です。

アクセスレビューとは、定期的に全ユーザーの権限を棚卸しし、業務上の必要性があるかを確認・承認するプロセスです。一般的には四半期ごとの実施が推奨されますが、セキュリティ要件の高い組織では月次で実施するケースもあります。

運用の流れとしては、まず各部門のマネージャーに自部門のメンバーが持つ権限リストを提示します。マネージャーは各権限が業務上必要かを確認し、不要なものに対して削除を指示します。情シスは承認結果をもとに権限変更を実施し、記録を残します。

アクセスレビューを手動で実施する場合、権限リストの作成・各マネージャーへの通知・回答の収集・結果の反映という工程が情シス担当者の工数を大きく消費します。100名規模の企業でも、四半期ごとの全社アクセスレビューは数日間の作業となり、担当者が1名や2名しかいない情シス部門では大きな負担です。この点は、後述するJosysのAccess Reviews機能が解決するポイントでもあります。

参考： ISACA「アクセス制御の設計原則」

最小権限の原則とゼロトラストセキュリティ

ゼロトラストセキュリティと最小権限の原則は、セキュリティ設計の文脈で切り離せない関係にあります。両者の接点を理解することで、なぜ今この原則が重視されるのかが明確になります。

ゼロトラストの基本思想は「何も信頼せず、常に確認する（Never Trust, Always Verify）」というものです。従来の境界型セキュリティが「社内ネットワーク内は安全」という前提に立っていたのに対し、ゼロトラストは場所や端末を問わず、セッションごと、またはリクエスト単位で認証・認可を行います。

この「セッションごとに認可を行う」という思想を実現するためには、そもそも「その人物がアクセスできる範囲はどこまでか」を正確に定義しなければなりません。最小権限の原則は、この認可の範囲を必要最小限に絞るための設計思想であり、ゼロトラストアーキテクチャの基盤として機能します。

SaaS中心の分散IT環境では、認証はIDaaS（Identity as a Service）、権限管理はSMP（SaaS Management Platform）、エンドポイントセキュリティはEDR/MDMと、複数のレイヤーが組み合わさります。最小権限の原則を機能させるには、これらのツールが連携し、権限の付与・変更・削除が一貫して管理される仕組みが必要です。

ゼロトラストとの関係で注目されるもう一つの概念が「ジャスト・イン・タイム（JIT）アクセス」です。JITアクセスは、必要なときに必要な期間だけ権限を付与し、用が済んだら即時剥奪するという考え方です。常時付与ではなく動的な権限管理を志向するJITアクセスは、最小権限の原則のより厳格な実践形態といえます。すべての権限をJITで管理するのは現実的ではありませんが、特に機密性の高いシステムへのアクセスや管理者権限については、JITアクセスの適用を検討する価値があります。

最小権限の原則実装時の注意点

最小権限の原則を導入するうえで、セキュリティを強化しながら業務を止めない設計が必要です。実装時に陥りやすい課題と対策を整理します。

過度な制限による業務停止リスク

権限を絞りすぎると、社員が業務を遂行できなくなるケースがあります。「最小権限の原則を適用したら、資料作成に必要なツールが使えなくなった」という状況は、セキュリティ強化の目的とは逆行します。

実装時は、現行の権限利用状況を把握してから段階的に絞っていくアプローチが現実的です。いきなり最小権限の状態に移行するのではなく、まず利用実態のないアカウントや明らかに不要な管理者権限から対処し、段階的に標準ロールに収束させます。

ユーザー体験（申請フローの使いやすさ）

申請フローが複雑すぎると、社員は「申請するより管理者に直接頼む方が早い」という行動を取るようになります。これは管理の抜け穴となり、権限管理の透明性を損ないます。申請・承認のUIはシンプルであることが重要で、社員が迷わず操作できる設計が求められます。

具体的には、申請に必要な項目を最小限にすること、申請状況がリアルタイムで確認できること、承認者への通知が自動化されていることの3点が、利用者満足度を左右します。申請から承認まで数日かかるフローは、業務の緊急性に対応できず、「次回から直接頼もう」という行動変容を招きます。

例外管理と緊急アクセスの設計

業務上、通常の権限では対応できない緊急事態が発生することがあります。この場合に備えて「緊急アクセス（Break Glass Access）」の手順を事前に定義しておくことが推奨されます。緊急アクセスは通常の申請フローをバイパスしますが、使用した場合は必ず記録し、事後に承認者へ報告する設計にします。

例外を完全に排除しようとすると、緊急時に業務が止まります。例外の存在を認めつつ、例外は必ず記録・報告されるプロセスを設けることが、最小権限の原則を現実の運用に落とし込むための鍵です。

参考： NIST SP 800-207「ゼロトラスト・アーキテクチャ」

JosysによるSaaSの最小権限管理

最小権限の原則を適切に運用するには、権限の棚卸し・自動化・継続的なモニタリングを組み合わせた仕組みが必要です。Josysは、SaaS管理プラットフォームとして、これらを一元的に実現します。

Access Reviewsによる定期的なアクセス権棚卸し

JosysのAccess Reviews機能は、全社員が持つSaaSの権限を一覧化し、マネージャーが自部門の権限を確認・承認するワークフローを提供します。従来、Excelで管理していた権限台帳を手動で更新し、メールでマネージャーに確認依頼を送るというプロセスを、Josysは自動化します。

レビュー対象のリスト作成・マネージャーへの通知・承認結果の記録・不要権限の削除指示まで、一連のプロセスがプラットフォーム上で完結します。J-SOX・ISMSの監査に対応した証跡も自動で取得できるため、監査対応のための事後作業を大幅に削減できます。

Access Automationによる入退社・異動の自動化

Access Automationは、人事システムの異動・退職データと連動し、対象のSaaSアカウントの権限変更・削除を自動実行します。連携可能な350以上のSaaSアプリのうち、対応アプリではデプロビジョニングや権限変更を自動化できます。退職処理が人事システム上で完了した時点で、対象アプリへの自動処理が実行されます。

異動の場合は、旧部門に紐づいた権限の剥奪と、新部門のロールに対応した権限付与が同時に処理されます。手作業に依存していた権限変更を自動化することで、人為的なミスや処理漏れをゼロに近づけられます。

SaaS Insightsによる過剰権限の可視化

SaaS InsightsはJosys全体の利用状況を分析し、長期間ログインのないアカウントや、実際の業務利用に対して権限レベルが過剰なアカウントを検出します。「管理者権限を付与しているが、実際には閲覧しかしていない」といったケースを自動的にアラートし、権限の見直しを促します。

SaaSの数が多くなるほど、担当者の目では追えない過剰権限が増えていきます。Josysはデータをもとに過剰権限の候補を提示することで、情シス担当者がより優先度の高い業務に集中できる環境をつくります。

まとめ

最小権限の原則は、一度設定して終わりではなく、継続的に運用し続けることで初めて機能します。権限は時間とともに肥大化する性質を持ち、定期的な棚卸しをしなければ、気づかないうちに過剰権限の状態に戻ります。

本記事で解説した内容を整理します。

• 最小権限の原則（PoLP）とは、業務に必要な最低限の権限のみを付与するセキュリティ設計の基本原則
• 過剰権限は内部不正・外部攻撃の被害拡大・コンプライアンス違反の3つのリスクを高める
• SaaS環境での実装には、RBAC設計・申請フロー・自動デプロビジョニング・定期レビューの4つが必要
• ゼロトラストセキュリティの基盤概念として、今後さらに重要性が増す
• 実装時は業務停止リスクを考慮し、段階的に権限を絞るアプローチが現実的

自動化ツールの導入は、これらの取り組みを持続可能にするための現実的な手段です。Josysは350以上のSaaSアプリに対応した権限管理の自動化を提供しており、最小権限の原則を「理想」から「日常の運用」に落とし込む支援をします。

よくある質問

Q1. 最小権限の原則はどこから着手すればよいですか？

まず「現状の権限棚卸し」から始めるのが現実的です。全社員が現在どのSaaSにどの権限でアクセスできるかを一覧化し、明らかに不要な管理者権限や退職者アカウントを優先的に対処します。いきなり全体を最小権限に移行しようとすると業務停止リスクがあるため、段階的なアプローチが推奨されます。

Q2. RBACを導入するとき、ロールはどのくらいの粒度で設計すればよいですか？

部門×職種×職位の3軸で設計するのが一般的です。ただし、ロールの数が多くなりすぎると管理が複雑になるため、例外を極力作らずに標準ロールに集約する意識が重要です。業務上必要な場合のみ、個別申請で期限付きの権限を付与する設計にすると、ロールの肥大化を防げます。

Q3. 定期アクセスレビューはどのくらいの頻度で実施すべきですか？

一般的には四半期ごとが推奨されます。ただし、取り扱うデータの機密性が高い場合や、J-SOXやISMSの要件が厳しい場合は月次での実施も検討されます。手動運用では担当者の工数が大きいため、アクセスレビューを自動化するツールの活用が現実的です。

Q4. 退職者アカウントの削除漏れを防ぐにはどうすればよいですか？

人事システムやIDaaSと各SaaSの連携を自動化するのが根本的な解決策です。退職処理が完了した時点で、連携する全SaaSのアカウントが自動的に無効化・削除される仕組みを構築することで、人為的な削除漏れをゼロに近づけられます。手動対応が避けられない場合は、退職チェックリストに全SaaSを明記し、複数人で確認するプロセスを設けます。

Q5. 最小権限の原則とゼロトラストセキュリティはどう違いますか？

最小権限の原則は「付与する権限の範囲を必要最小限にする」という設計思想です。ゼロトラストは「場所や端末を問わず、セッションごと、またはリクエスト単位で認証・認可を行う」という包括的なセキュリティアーキテクチャです。最小権限の原則はゼロトラストを実現するための基盤の一つであり、「認可の範囲をどう定義するか」という問いに答える考え方です。両者は相互補完的な関係にあります。

Josysで最小権限の原則を実装する

事例によってはIT工数を最大50%・ITコストを最大75%削減したケースがあります。（効果は個社の状況により異なります）

資料ダウンロード（無料）

無料デモを申し込む