パスワードを社員同士で共有していない？権限管理を見直す5つの手順

「受注システムのログイン情報は、担当者全員が知っています」「社内の共有フォルダは、誰でも編集できます」。小規模な会社では、業務を止めないために、こうした運用が続いていることがあります。

問題は、パスワードを何人が知っているかだけではありません。誰が、どの情報を、どこまで操作できるかを会社が把握できていないことです。この記事では、少人数の会社でも始められる権限管理の見直し方と、仕組みづくりを外部へ相談すべき境界を整理します。

パスワード共有で困るのは「操作した人」がわからなくなること

例えば、営業担当者5人が同じ管理者IDで販売管理システムへログインしているとします。誤って請求データが削除されたとき、操作ログに残るのは共通IDだけかもしれません。その場合、誰が実際に操作したのか、システムのログだけでは判別できません。

また、退職者に共通パスワードが知られたままなら、その人の利用を止めるために、残る社員も含めて認証情報の変更が必要になります。外注先に一度渡したIDも同様です。共有IDに広い管理者権限まで付いていると、本来不要な設定変更や情報閲覧も可能になります。

IPAの「中小企業の情報セキュリティ対策ガイドライン 第4.0版」は、共有IDをなるべく使わず、やむを得ない場合も利用者を特定できる仕組みを整えること、異動・退職時の権限変更や削除を管理することを示しています。

最初に区別したい「認証」と「権限」

認証は「誰がログインしているか」を確認する仕組みです。個人ごとのID、パスワード、多要素認証（MFA）などが関係します。一方、権限は「ログイン後に何ができるか」を決めます。閲覧だけなのか、編集・削除まで許すのか、システム設定を変更できるのかという違いです。

社員ごとのIDを作っても、全員が管理者権限なら見直しは不十分です。反対に、権限が細かく分かれていても、全員が同じIDを使えば操作履歴の追跡が難しくなります。個人を識別することと、必要最小限の操作だけ許可することはセットで考えます。

権限管理を見直す5つの手順

1．使っているサービスとIDを洗い出す

会計・販売管理・顧客管理・メール・クラウドストレージ・SNS・Webサイト管理など、業務に使うシステムを一覧にします。各サービスについて、管理責任者、利用者、共有IDの有無、管理者権限を持つ人、外部委託先、最終確認日を記録します。

ここで重要なのは、パスワードそのものを一覧表に書かないことです。アカウント台帳は「誰が使えるか」を管理する資料にし、認証情報は適切な認証基盤やパスワード管理ツールなどで別管理します。

2．業務の役割から権限を決める

「正社員だから全部見られる」「ベテランだから管理者」という決め方は避けます。営業なら案件の更新、経理なら請求書の作成、システム管理者なら設定変更というように、業務に必要な操作から権限を逆算します。

図1は、営業・経理・管理者・外部委託という役割に分けた設計イメージです。実際に使える権限の細かさは、利用中のサービスによって異なります。

3．個人IDと多要素認証へ移行する

利用者ごとにIDを発行できるサービスなら、共通IDから個人IDへの移行を優先します。多要素認証を有効にできる場合は、特に管理者・外部アクセス用のアカウントから適用します。管理者権限を通常業務のIDと分けられる場合は、分離も検討します。

一部の機器や古いサービスでは共有IDしか用意できないこともあります。その際は、利用者の限定、利用申請、個人単位の記録、認証情報の安全な保管、担当交代時の更新を組み合わせます。ただし、共有IDそのものの操作ログだけで個人を完全に特定できるとは限りません。

4．入社・異動・退職で変更する項目を決める

権限管理で見落とされやすいのは、導入時より人が動いたときです。入社時は必要な権限だけ付ける。異動時は新しい権限を追加するだけでなく、旧部署の権限を外す。退職・契約終了時は、停止日時と担当者を決め、アカウントの無効化や共有グループからの除外を確認します。

必要に応じて、ログイン中のセッション、連携アプリ、APIキー、保存済み認証情報も点検します。アカウントを削除すると業務データが失われるサービスもあるため、先にデータの引き継ぎと管理者アクセスを確認することが大切です。

5．定期的に「今も必要か」を確認する

一度設計しても、役職や担当業務は変わります。例えば四半期ごとに、管理者ID、退職者ID、長期間使われていないID、外部委託先の期限付き権限を見直す運用を決めます。これは実施頻度の一例であり、重要システムではもっと短い間隔が適切な場合もあります。

確認記録は「対象・判定・変更内容・承認者・確認日」を残します。自動化する場合も、権限を削除する前の承認や業務影響の確認まで省略しない設計が必要です。

Excelの台帳で十分な会社と、仕組み化した方がよい会社

利用サービスが少なく、変更頻度も低いなら、最初はExcelやスプレッドシートの台帳と退職時チェックリストで始められます。ただし、閲覧できる人を限定し、機密情報やパスワードを保存しないことが前提です。

一方、複数のSaaSに同じ社員が登録されている、異動が多い、外部委託先が頻繁に入れ替わる、権限の変更履歴を残したい場合は、アカウント一覧の自動照合、期限通知、承認フローなどの小さな仕組みが役立つ可能性があります。

ただし、台帳を作っただけで各サービスのログイン権限が自動的に変わるわけではありません。実際の停止・更新まで自動化するには、対象サービスがAPIや管理機能を提供しているか、必要な権限で連携できるかを事前に確認します。

依頼するなら、何を整理しておけばよい？

相談前に、使用サービス名、利用人数、役割の種類、困っている場面（共有ID・退職時の停止漏れなど）、希望する対応範囲がわかれば、方式を検討しやすくなります。パスワード・認証コード・個人情報の実データを送る必要はありません。画面例や一覧表は、匿名化したものでも構いません。

私が業務ツールの設計を考える際にも、最初から大きな管理システムを作るのではなく、台帳で解決できる部分と、連携や自動化が必要な部分を分けます。権限設計や連携の可否を整理したい場合は、ココナラ内のプロフィールや関連サービスから、現状と希望する完成形をお知らせください。

最初の一歩は、全サービスを一度に入れ替えることではありません。「共通の管理者IDを何人が使っているか」から確認するだけでも、見直すべき範囲が具体的になります。