〈 トピックス 〉
「異動した社員に、前の部署のアクセス権限が残ったままになっている」
「権限設定のルールを理解しているのは、特定の担当者だけ」
情シス部門の担当者や管理職であれば、こうした状況に心当たりがあるのではないでしょうか。
アクセス権限は、一度設定すれば終わりというものではありません。組織変更、退職、新システム導入のたびに権限を追加・削除していくと、いつの間にか必要以上のアクセス権が付与されたり、退職者のアカウントの削除忘れがあったりして、誰が何を見られるのか把握できない状態に陥ります。この状態でアカウントが不正利用されれば被害は大きく広がり、悪意がなくても誤った閲覧や誤送信による情報漏洩が起きやすくなります。
権限の見える化と定期的な見直しは、最新のセキュリティツールを導入する前に整えておきたい基本です。
本記事では、権限が肥大化・属人化する原因から、最小権限の原則と役割ベースの設計、具体的な棚卸しの手順、退職・異動時の運用までを、実務目線で解説します。
01
アクセス権限管理でまず押さえておきたいのは、次の3点です。
以下では、これらの背景と、具体的な設計・棚卸しの手順を解説します。
02
社内のアクセス権限は、ある日突然複雑になるわけではありません。日々の運用の中で少しずつ積み重なり、いつの間にか誰も全体像を把握できない状態に陥ります。
ユーザーが持つ権限が本来必要な範囲を超えて少しずつ膨張していく現象を権限クリープと呼びます。次のような運用が積み重なると、権限クリープが起こりやすくなります。
こうした運用を続けると、次の状態が生まれます。
これらを放置すると内部不正の温床になるだけでなく、フィッシングやマルウェア感染でアカウントが侵害された際に、攻撃者がアクセスできる範囲まで広がってしまいます。独立行政法人情報処理推進機構（IPA）が毎年公表する情報セキュリティ10大脅威 2026では、「内部不正による情報漏えい等」が組織向け脅威の第7位に選ばれています。アクセス権限や認証の適正化は、こうした脅威への共通する基本対策として位置づけられています（出典：独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026」2026年1月29日公開）。
権限が把握しづらくなる背景には、情シス部門が後追いになりやすい事情もあります。人事異動や現場からのアクセス権限の依頼は、チャットやメールで個別に届くことも多くあります。情シス部門は目の前の権限付与作業に追われ、権限を記録しておくファイルの更新や不要な権限の削除は後回しになりがちです。
加えて、シャドーIT（情シス部門が把握・許可していないSaaSやクラウドサービスを、現場が独自に契約して使う状態）が広がると、情シス部門が把握できていない権限そのものが生まれます。部門ごとに情シス部門を通さない契約が増えるほど、情シス部門が知らないうちにアカウントや権限が積み上がっていくということです。
当社が実施した調査では、情報システム部門の管理職221人に尋ねたところ、無許可のSaaSが社内に存在すると回答した企業が86.4%にのぼりました（出典：【2026年調査】シャドーITの実態調査｜86.4%の企業で無許可SaaSが存在、情シス221人に聞いた)。
権限の棚卸しは、情シス部門が把握しているシステムだけを対象にしても終わらない、といえます。
03
アクセス権限管理とは、誰が・どのリソースに・どのような操作を許可されるかを制御する仕組みです。操作には、閲覧・作成・編集・削除・出力などが含まれます。ここで混同しやすいのが、認証と認可の違いです。
認証は本人確認のプロセスで、IDとパスワードや多要素認証がこれに当たります。一方、認可はその人に何を許可するかを判断するプロセスであり、アクセス権限管理は、この認可を業務の実態に合わせて設計・運用することです。認証の仕組みが整っていても、認可の範囲が広すぎれば情報漏洩は防げません。
■認証
本人確認を行うプロセス。IDとパスワードや多要素認証などが該当する
■認可
認証された本人に、何を許可するかを決めるプロセスでアクセス権限管理の中核にあたる
そこで権限設計の出発点となるのが、最小権限の原則です。業務に必要な最低限の権限のみを付与し、それ以外は許可しないという考え方です。
実務上、権限は後から広げることは容易ですが、一度広げた権限を後から絞るのは難しいという側面があります。設定の手間を避けて全員にアクセスを開放してしまうと、誤操作によるデータ消失や情報漏洩のリスクが高まります。必要になった時点で追加する運用のほうが、最初から広く付与するよりも安全で管理がしやすいという考え方です。
個人単位で一つひとつ権限を設定・管理していると、管理負荷が膨大になりミスも起きやすくなります。そこで有効なのが、役割ベースのアクセス制御（RBAC、個人ではなく「経理担当」のような役割の単位で権限をまとめて管理する方式）です。権限をロール・スコープ・例外の3つに分けて設計します。
| 分類 | 概要 | 具体例 |
|---|---|---|
| ロール | その役割が何をできるかを定義する操作権限の集合 | 経理担当者ロールは請求書の作成や経費申請の承認状況閲覧ができる |
| スコープ | ロールが適用される範囲 | 同じ営業担当者ロールでも、担当エリアのみか全社データを対象とするのかを分ける |
| 例外承認 | 通常のロールでは対応できない業務に対して、期限つきで付与する一時的な権限 | 特定のプロジェクトに社員へ3か月限定で他部署データの閲覧を許可する |
高額な決済やシステム設定の変更などの重要な操作では、申請する部門と承認する管理者を分ける「職務分離」の考え方を取り入れると、不正やミスの防止につながります。
内部統制（不正やミスを防ぎ、会社を適正に運営するための社内の仕組み全般）の観点からも、職務分離は重要です。
企業会計審議会が令和5年4月7日に公表した意見書は、統制活動に権限や職責の付与、職務の分掌などの手続きが含まれると述べています（出典：企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」令和5年4月7日 ）。
同意見書は財務報告についての内部統制を対象にした資料です。
つまり、誰か1人だけで申請から承認まで完結させない仕組みが、内部統制の土台になります。この考え方は業務システムの権限設計にも当てはめられ、ロール単位で管理すると異動時の変更も容易になります。
04
肥大化した権限を適正な状態に戻すには、場当たり的に削るのではなく、段階を踏んだ設計が欠かせません。ここでは実務で使える6つのステップと、優先すべきチェック項目を紹介します。
実務では、次の順番で進めると整理しやすくなります。
| ステップ | 内容 |
|---|---|
| ①対象の洗い出し | 基幹となる業務システム、ファイルサーバや共有ドライブ、各種SaaS、管理者権限を持つアカウント、業務委託先のアカウントまで漏れなくリストアップする |
| ②現状の棚卸し | ユーザー・リソース・操作の組み合わせを一覧化し、休眠アカウント、過剰な権限、退職者の残存アカウントを特定する |
| ③業務ロールの定義 | 部署名ではなく、見積書の作成や月次決算の確定など、実際の業務に必要な操作の集合としてのロールを定義する |
| ④ロール×権限マトリクスの作成 | 定義したロールを軸に、最小権限の原則に沿って不要な権限を削除する |
| ⑤ツールへの反映と例外ルールの明文化 | マトリクスを実際のシステムに反映し、一時的な権限付与が必要な場合の申請・承認フローと有効期限を明文化する |
| ⑥定期レビューの設計 | 四半期から半期に一度の見直しを、運用フローの一部として組み込む |
中堅・中小企業の情シス部門がこれらを一度に進めるのは現実的ではありません。まずは売上や顧客情報、受発注や在庫データなど、漏洩や改ざんが起きた際の影響が大きい業務システムから優先して着手するのが現実的です。
弊社のノーコード・クラウドデータベース「Slopebase」のようなデータ連携機能を持つ業務システムを活用している場合、顧客・受発注・在庫などの重要データをロール単位で揃えやすいため、誰が何を見られる状態なのかを、常に明確に把握できるようになります。
Slopebaseの認証やアクセス制御の詳細は、セキュリティ・認証・動作環境ページで確認できます。
ロール別の権限設定例を示すと、次のようになります。
| ロール | 顧客データ | 受発注システム | 管理者権限 |
|---|---|---|---|
| 営業一般 | 閲覧のみ | 閲覧のみ | なし |
| 営業マネージャー | 閲覧・編集 | 閲覧・編集 | なし |
| 情シス部門 | 閲覧・編集 | 閲覧・編集 | 権限付与 |
棚卸しの際は、特に次の項目を重点的に確認します。
確認項目をチェックリストの形でまとめると、次のとおりです。
| チェック項目 | 確認内容 |
|---|---|
| 退職者・異動者・業務委託先の残存権限 | 契約終了後や異動後もアカウントや権限が残っていないか |
| 管理者権限の人数 | 業務上必要な最小限のメンバーに絞られているか |
| 外部共有・全社公開の設定 | 社外への共有リンクや全員公開の設定が残っていないか |
| 一時的な例外権限の期限切れ | 期限が過ぎた例外権限が放置されていないか |
| 90日以上ログイン実績のない未使用アカウント | 長期間利用されていないアカウントが残っていないか |
05
権限を役割ベースで整理しても、日々の運用ルールが伴わなければすぐに元の状態に戻ってしまいます。ここでは、入社・異動・退職という従業員のライフサイクルに沿った運用ルールの作り方を解説します。
異動時に起きやすいのは、新しい部署の権限だけを追加していってしまうことです。これを防ぐには、旧ロールの削除と新ロールの付与を必ずセットで行うワークフローを徹底します。異動にともなう業務全体の引き継ぎの進め方は、異動・組織変更でも業務を止めない｜引き継ぎを最小化するプロセスの仕組み化で詳しく解説しています。
退職時は対応の速さが重要です。次のような段階を決めておくと運用しやすくなります。
これらの運用を止めずに回すには、人事・現場の管理職・情シス部門の間で、誰が申請し誰が承認し誰が実行するかという役割分担を明確にすることが欠かせません。高度な自動化ツールが未整備でも、人事からの通知を起点にしたチェックリストとワークフローによる運用から始めるのが現実的な第一歩です。
退職にともなう業務の引き継ぎ全体については、退職リスクに備える！失敗しない業務引き継ぎとマニュアル化を超えた「仕組み化」で詳しく解説しています。
異動や退職といったイベント駆動の対応に加えて、四半期から半期に一度の定期レビューを組み合わせることで、権限管理はより強固になります。定期棚卸しでは、次のような指標を継続的に確認すると改善状況を把握しやすくなります。
これらを情シス部門管理職が定期的にモニタリングすることで、運用の形骸化を防ぐことができます。
06
従業員100〜200名規模の企業では、次のような状況がよく見られます。販売管理システムやMicrosoft 365、クラウドストレージを部門ごとに運用しており、現場からの要望に応じて社員個人へ権限を付与する運用が続いてきました。その結果、異動した社員が以前の部署の顧客情報をそのまま閲覧できる状態になっている、というケースです。権限の全体像を把握しているのが勤続の長い情シス部門担当者一人だけで、その担当者が不在の間は権限変更すら止まってしまう、という声も珍しくありません。
こうした状況で危機感を持った情シス部門が権限棚卸しに着手する場合、まずは販売管理システムと顧客情報を扱う共有フォルダから始めるのが典型的な進め方です。売上や顧客データへの影響が大きく、優先順位をつけやすいためです。
棚卸しを進めると、現場の管理職から、今まで見えていた情報が見られなくなると困るという反発が出ることもあります。これに対しては、必要になれば当日中に権限を追加できること、目的は情報漏洩リスクを減らすことであると説明し、理解を得ていく進め方が有効です。基本ロールで対応できない業務については、最長でも数か月の期限付きで例外権限を付与し、期限が来たら必ず見直すルールを設けると運用しやすくなります。
ロールマトリクスによる管理へ移行し、異動時は旧ロールの削除を必須とすることが基本です。半期ごとの棚卸しでは、管理者権限の数と外部共有の状況を重点的に確認します。この2点を徹底すると、担当者個人の記憶に頼っていた運用から脱却し、誰が何にアクセスできる状態なのかを会社として把握できるようになります。
あわせて、未使用アカウントの洗い出しが、ライセンスコストの見直しにつながることもあります。
自社の権限設定が今どうなっているか、棚卸しの前に可視化したい方もいるでしょう。Slopebaseでロール単位の権限管理をどこまで設計できるかは、資料請求ページからご確認いただけます 。
07
A.システムやデータに対して、誰がどのような操作ができるかを制御する仕組みです。権限が必要以上に広く付与されていると、サイバー攻撃を受けた際の被害範囲が広がったり、意図しない誤った操作や情報の持ち出しが起きやすくなったりするため、情報漏洩対策の土台として欠かせません。
A.個人ごとの設定は一人ひとりに直接権限を割り当てるため、異動のたびに複雑化し管理が追いつかなくなります。ロールベースは営業担当者や経理担当者といった役割に対して権限をまとめて割り当て、利用者をその役割に紐づける方式です。異動時も役割の付け替えだけで済むため、管理の手間と設定漏れを抑えられます。
A.異動や退職が発生した都度の対応に加えて、四半期から半期に一度の全社的なレビューを組み合わせるのが有効です。整備の第一歩としては、退職者のアカウントを即日無効化するプロセスの確立を優先し、その後、異動時に新部署への権限付与だけでなく旧部署の権限削除もセットでチェックする運用へと広げていくとよいでしょう。
08
アクセス権限の肥大化や属人化は、個人への例外的な権限付与の積み重ねと、退職・異動時の見直し漏れから生まれます。これを防ぐには、誰が・どのデータに・どのような操作ができるかを棚卸しで可視化し、役割ベースで最小権限に再設計することが欠かせません。異動・退職時の運用ルールと定期的なレビューを組み合わせ、継続的に見直せる仕組みを整えることが情報漏洩対策の土台になります。まずは重要データを扱うシステムから、棚卸しに着手してみてはいかがでしょうか。
棚卸しの進め方や役割ベースの権限設計を、自社の業務システムで実際にどこまで形にできるのか、具体的なイメージを事前に持ちたい方に向けた内容です。詳しくは資料請求ページからご請求ください。
09
バックオフィス業務の
支出管理を支援する、
ノーコード・クラウドデータベース
※バックオフィス業務とは経理や総務、人事、法務、財務などといった直接顧客と対峙することの無い社内向け業務全般を行う職種や業務のこと
この記事を書いた人
ソフトウェアメーカー取締役、IT上場企業の取締役を経て、現在、合同会社アンプラグド代表。これまでに、Webサイト制作、大規模システム開発、ECサイト構築、SEM、CRM等のWebマーケティングなど、IT戦略全般のコンサルティングを30年以上実施。現在は、大手上場企業から中小企業まで、IT全般のコンサルティングを行っているかたわらWebマーケティングに関するeラーニングの講師、コラム執筆なども実施。
