共有IDから個別IDへ

この状態なら読む

次のような会社を対象にします。

• 数人から十数人程度で、クラウドストレージや業務SaaSの1つのIDを全員で使っている
• サービス自体は利用者別IDを発行できる
• 共有IDのパスワードやMFAを複数人で知っている
• 退職・異動した人だけを個別に利用停止できない
• 個別IDへ分けたいが、料金、データ移行、設定変更が不安で手を付けられていない

ここでは、一斉に高度な管理環境へ移すことを前提にしません。共有IDを消す前に、そのIDが何を所有し、何を管理し、どこから復旧できるかを確認してから、利用者別IDへ段階的に移します。

最初に共有IDを削除しない

共有IDを見つけたとき、最初の作業を「パスワードを変える」「アカウントを削除する」にすると、業務を止めることがあります。

そのIDが次のどれを持っているかを先に確認します。

• ファイル、フォルダ、写真、帳票等の所有者になっている
• 他の利用者へ共有しているデータがある
• 管理者や契約管理者になっている
• 請求先やライセンス管理に使われている
• 復旧用メールアドレスや電話番号を持っている
• MFAの認証アプリやセキュリティキーが紐づいている
• 他のSaaSへログインするための連携元になっている
• API、外部アプリ、同期ソフト等の接続元になっている

共有IDは、単なるログイン名ではなく、データ所有者や復旧経路になっている場合があります。先に依存関係を見つけます。

目標は「会社が管理できる利用者別ID」

個別IDへ分ける目的は、人数分のメールアドレスを増やすことではありません。

目標は次の状態です。

• 誰が利用者なのか説明できる
• 退職・異動した人だけを停止できる
• 必要な人だけに必要な権限を付けられる
• 管理者権限を日常利用者全員へ配らない
• MFAと復旧先の管理主体が分かる
• 共有すべき業務データは、資格情報ではなくサービスの共有機能で共有する
• 会社として管理者と復旧経路を確保する

「全員が同じ情報を見る必要がある」ことと、「全員が同じ資格情報を使う」ことは別です。

移行前に一枚の表を作る

最初は次の項目だけで構いません。

この表で「共有IDを止めると何が止まるか」を先に見つけます。

個別IDへ移る順序

1. 会社側の管理者を先に確保する

共有IDだけが唯一の管理者なら、利用者分離より先に管理経路を整理します。

管理者は、日常業務に使う共有IDとは分けます。可能なら、特定の一人の個人メールや個人電話だけを唯一の復旧経路にしないようにします。

ここで確認するのは「管理者パスワードを何人にも教えること」ではなく、会社として管理者の所在と復旧方法を説明できることです。

2. 利用者別IDを発行する

次に、実際にサービスを使う人へ個別IDを発行します。

一斉移行が難しい場合は、次の順で優先できます。

1. 管理者権限を持つ人
2. 個人データや重要データを扱う人
3. 退職・異動時に個別停止できる必要が高い人
4. 日常的に更新・削除・承認を行う人
5. 閲覧中心の人

費用が増える場合も、全員を同時に移せないことと、共有IDを恒久運用することを同じにしません。優先順位を決めて移行期限を持ちます。

3. 業務データを「共有IDの所有物」から移す

利用者別IDを作っても、重要データが共有IDの個人領域に残ったままだと移行は終わりません。

サービスが提供する範囲で、次を確認します。

• 共有フォルダやチーム領域へ移せるか
• 所有者を変更できるか
• 新しい管理者へ共有設定を引き継げるか
• 外部共有リンクがどのIDに依存しているか
• 共有IDを停止した後も必要なファイルへアクセスできるか

単に全員へファイルをコピーすると、最新版がどれか分からなくなることがあります。正本を一つに決めてから移します。

4. MFAと復旧先を利用者別に整理する

共有IDで使っていたMFAや復旧先を、そのまま全利用者へ使い回さないようにします。

利用者別IDでは、誰の認証要素なのか、退職時に何を失効するのか、本人が端末を失ったときにどう戻すのかを確認します。

管理者用IDについては、利用者本人だけに依存しない復旧経路が必要かも別に判断します。

5. 権限を必要な範囲へ戻す

共有IDを全員で使っていると、利用者ごとの権限差が見えなくなりやすくなります。

個別IDを作ったら、全員へ旧共有IDと同じ強い権限を複製するのではなく、実際の業務に必要な範囲を確認します。

管理者設定を変える人、データを編集する人、閲覧だけする人が同じである必要はありません。

6. 共有IDへの新規作業を止める

個別IDで業務できることを確認したら、共有IDへ新しいファイルや新しい共有設定を追加しない期間へ移します。

この期間に、残っている依存を確認します。

• 共有IDへしか届かない通知がないか
• 共有ID所有のファイルが残っていないか
• 外部共有の所有者になっていないか
• 自動連携が共有IDで動いていないか
• 管理者・請求・復旧先として残っていないか

7. 最後に共有IDを停止する

依存がなくなったことを確認してから、共有IDを停止・削除・保管のどれにするかをサービス仕様と業務上の必要性に応じて決めます。

削除前に必要な記録やデータを失わないこと、停止後に復旧経路が共有IDへ戻っていないことを確認します。

一斉移行できない場合は「混在期間」を管理する

小規模事業者では、ライセンス費用や作業時間の都合で数週間から数か月かけて移すことがあります。

混在期間そのものを失敗とは扱いません。ただし、次を決めます。

• 誰が個別IDへ移行済みか
• 共有IDをまだ使ってよい業務は何か
• 共有IDで新しいデータを作ってよいか
• 共有IDのパスワードを知る人は誰か
• 移行期限はいつか
• 共有IDを停止する条件は何か

「順番に移している途中」と「期限なく共有し続けている状態」を区別します。

個人データを扱う場合は利用者を区別できる状態へ近づける

個人情報保護委員会の通則編では、個人データを情報システムで取り扱う場合の技術的安全管理措置として、アクセス制御、アクセス者の識別と認証などが示されています。

顧客情報や従業員情報を扱うクラウドサービスで1つのIDを全員が共有している場合、サービス上のIDだけを見て「誰がアクセスしたか」を区別することは難しくなります。

利用者別IDへ分けることは、それだけで法令上十分という意味ではありませんが、誰にアクセスを許可し、誰を停止するかを管理するための基礎になります。

共通メールアドレスは別に考える

info@ や sales@ のように、1つの窓口を複数人で扱う業務要件があります。

この場合も「共通のメールアドレスが必要」と「同じID・パスワードでログインする必要がある」は同じではありません。利用サービスに共有メールボックス、グループ、委任等の機能がある場合は、利用者別認証のまま共通窓口を維持できるか確認します。

この解説が断定しないこと

• 共有IDを使っている会社が直ちに特定の法令へ違反しているとは断定しません。
• すべてのSaaSで同じ移行機能が使えるとは扱いません。
• 個別IDへ分ければ、それだけで十分なセキュリティになるとは扱いません。
• 利用者数分の有料ライセンスを無条件に購入すべきだとは決めません。
• 個別IDを発行できない製品へ、存在しない機能を要求しません。

重要なのは、共有IDを止めること自体ではなく、会社が管理者・データ・利用者・復旧経路を把握した上で、一人ずつ停止できる状態へ移ることです。