経営と仕事のこれから / 第一稿
パスワードを共有する会社から、権限を引き継げる会社へ
1Passwordを例に考える、中小企業のアクセス管理
1Passwordを例に、共有IDの整理、パスキーの効用と限界、端末対策、権限の取消しと復旧を考察します。担当者の記憶や善意に依存せず、会社がアクセスを管理し引き継ぐための順序を整理します。
担当者が休むとログインできない。確認コードが、退職した人の携帯電話に届く。会社のアカウントなのに、誰がパスワードを知っているのか分からない。
こうした問題は、パスワードを長くするだけでは解決しません。誰が何を使え、その権限を誰が止め、困ったときに誰が復旧できるのか。それが会社の手順になっていないからです。
パスワード管理ツールの導入は、この状態を変える機会になります。ただし、Excelやチャットに散らばったパスワードを保管庫へ移すだけでは、共有の仕組みは変わりません。
目指すのは、必要な人が仕事を続けられ、役割を終えた人の権限を取り消せる状態です。そのために、個人別のアカウントへ移せるものは移し、残る共有を管理し、認証と復旧の仕組みを整えます。
本稿では、主に10〜100人規模の中小企業を想定し、1Passwordを例に、その順序を考えます。特定製品の優劣を比較する記事ではありません。機能の説明は公式資料に基づき、実機での検証は行っていません。利用できる設定や契約条件は、導入時に確認してください。
1.仕事を分かち合うことと、同じ秘密を知ることを分ける
共有パスワードの問題は、一度渡した情報を回収できないことです。
保管庫からメンバーを外しても、その人が以前に控えたパスワードは消えません。共有リンクの有効期限が切れても、受け取った側に保存された情報まで消えるわけではありません。
そこで、保管庫を作る前に、会社で使うアカウントを棚卸しします。
まず確認するのは、「このサービスは、一人ひとりにアカウントを作り、必要な権限を与えられるか」です。メンバー追加や権限委任の仕組みがあれば、サービスの条件や費用を確認したうえで、個人別の利用へ移します。
ここでいう個人別アカウントは、社員の私物アカウントに会社の資産を預けるという意味ではありません。可能な限り、会社が管理するメールアドレスや認証基盤に結び付け、人ごとに権限を付与する形です。
この形なら、担当者が替わったときに、その人の権限を外せます。サービスが適切な操作ログを備えていれば、どのアカウントが操作したかも追いやすくなります。ただし、その記録だけで、実際に操作した人や判断の正しさまで証明できるわけではありません。
個人別に移すと、アカウントや資格情報の件数は増えるかもしれません。それでも改善です。減らしたいのは保管件数ではなく、誰が使えるか分からず、後から止められないアクセスです。
2.残る共有を、管理できる場所へ移す
すべての共有をすぐにやめられるとは限りません。個人別アカウントに対応しない取引先ポータルや、複数人で扱わざるを得ない業務もあります。
その残る共有を、パスワード管理ツールへ移します。
1Passwordでは、パスワードなどの情報を保管庫に整理し、利用する人やグループへアクセスを付与できます。保管庫は、部署名だけで機械的に分けるより、「同じ情報を必要とする人」と「求める管理水準」で分ける方が実務に合います。
例えば、広報の日常業務、経理の取引先対応、ドメインやクラウドの管理では、利用者も、侵害された場合の影響も異なります。それらを一つの保管庫にまとめないことが、権限を絞る第一歩です。
ただし、「表示やコピーを禁止する設定があるから、秘密は持ち出せない」と考えてはいけません。公式資料も、閲覧権限と一部の操作制限では保護の性質が異なることを説明しています。共有する相手は、その情報を取得し得る人として扱う必要があります。[1]
各アカウントには、少なくとも次の項目を記録します。
- 業務上の用途と管理責任者
- 利用を認める人やグループ
- 認証方法と復旧手段
- 担当者変更時に必要な作業
- 次に見直す時期
パスワードの置き場所が決まるだけでなく、管理する責任と手順が決まることが重要です。
3.認証を強くする。その守備範囲も理解する
パスワード管理ツールの基本的な効果は、サービスごとに異なる長いパスワードを使い、人が覚える負担を減らすことです。
しかし、保管庫へ集約すれば、それを開くアカウントと端末の重要性も高まります。認証は、保管庫の入口と、その中に保存する各サービスの両方で整えます。
1Passwordアカウントには、利用形態に応じて多要素認証を設定します。ただし、多要素認証は、保管庫の暗号化や端末の保護と同じものではありません。新しい端末からのサインインを守る仕組みを、既に開かれた保管庫や盗まれたローカルデータを万能に守る仕組みとして扱わないことが必要です。[2]
各サービスについても、対応している認証方式を確認します。特定の担当者の携帯電話だけに確認コードが届く状態は、その人が不在になったときの業務停止につながります。
認証アプリのコードを1Passwordに保存する運用は便利ですが、パスワードとコード生成用の秘密を同じ保管庫に置くことになります。その保管庫が侵害された場合には、両方が同時に漏れる可能性があります。二段階認証の効果がすべて失われるわけではありませんが、保護の独立性は弱まります。
重要なアカウントでは、サービスが対応するセキュリティキーなども検討します。重要度は「SNSだから中程度」「管理画面だから高い」と名前だけで決めません。企業の公式SNSも、乗っ取られれば顧客への詐欺や信用毀損に使われる可能性があります。
また、1Password自身へ入るための認証コードを、その1Passwordの中だけに保存してはいけません。復旧に必要なものまで同じ入口の内側へ集めると、入れなくなったときに循環してしまいます。[3]
4.パスキーは、共有IDの問題まで解決するわけではない
パスキーは、フィッシングに強い認証へ移るための有力な選択肢です。
パスワードのように、人が秘密の文字列をサイトへ入力する方式とは異なり、公開鍵と秘密鍵を使って認証します。認証先との結び付きがあるため、偽サイトに同じ秘密を入力させる攻撃に強いことが特徴です。[4]
ただし、「盗まれて困るものがなくなる」わけではありません。秘密鍵を扱う端末や保管先、アカウントの復旧経路は、引き続き守る必要があります。
1Passwordは、パスキーの保存や共有にも対応しています。したがって、パスワードからパスキーへ移しても、保管庫の件数が減るとは限りません。変わるのは主に認証の方式です。
同じパスキーを複数人で共有するなら、共有IDの問題も残ります。フィッシング耐性は改善しても、サービス側で利用者を一人ひとり区別できるようになるとは限りません。
さらに、読んで暗記できないことと、複製・移行できないことは別です。1Passwordでは、対応する環境でパスキーを他の管理アプリへ移行できます。保管庫のメンバーから外しただけで、過去に共有したパスキーが確実に使えなくなるとは考えない方がよいでしょう。[5]
失効させるときは、対象サービス側の登録を確認します。1Password内でパスキーを削除しても、サービス側の登録は削除されません。[6]
導入時には、パスキーを追加できるかだけでなく、従来のパスワードやSMSによるログイン・復旧経路がどう残るかも調べます。不要な経路を閉じることと、会社が復旧できる経路を確保することを、セットで判断します。
5.ログインの後と、端末の側を守る
認証を強くしても、端末が侵害されれば被害は起こり得ます。
パスワードを入力する瞬間だけでなく、ログイン後の状態を保つセッション情報も保護の対象です。パスキーや多要素認証を導入したことを理由に、端末対策を後回しにはできません。
業務端末の更新、不要なソフトウェアや拡張機能の整理、端末の保護・監視、管理作業と日常利用の環境分離を検討します。保管庫の自動ロックも、業務に合った時間へ設定します。
ブラウザに保存したパスワードを移行する場合は、新しい保存先で利用できることを確認し、不要になった保存データを整理します。ただし、保存先を1Passwordへ変えただけで、端末侵害に耐えられるようになるわけではありません。
また、管理者用の情報をブラウザ拡張機能から使えなくし、同じ端末の別アプリからコピーするだけでは、端末を分離したことにはなりません。アクセス経路の制限は、その目的と、代わりに生じる操作を確かめて採用します。
端末感染が疑われる場合には、通常の退職手順とは別の対応が必要です。疑わしい端末を隔離し、信頼できる別端末から、影響するアカウントの停止、資格情報の変更、セッションの失効を進めます。被害の範囲が分からない場合に相談できる窓口も、平時に決めておきます。
6.権限を止める手順と、会社を止めない手順を作る
アクセス管理には、二つの方向があります。
一つは、役割を終えた人のアクセスを止めること。もう一つは、担当者が不在でも会社が必要なアクセスを取り戻せることです。
通常の退職や異動では、業務情報の引継ぎを確認し、不要になる権限を外します。1Passwordの公式手順も、業務情報の移動、アクセス停止、共有していたパスワードなどの変更、アカウント削除という流れを示しています。利用状況レポートは、変更の優先順位を考える材料になります。[7]
ただし、保管庫へのアクセス記録だけでは、外部サービスで実際に誰が何をしたかまでは分かりません。記録がないことを、情報を持っていない証明として扱わないことも必要です。
対象サービス側では、個人別権限の解除に加え、必要に応じて共有パスワードの変更、共有パスキーやトークンの失効、既存セッションの終了を行います。不正利用が疑われる場合は、引継ぎ完了を待たずに停止を優先するなど、通常の退職と緊急時で順序を分けます。
一方、復旧については、担当者を複数決めるだけでは不十分です。
予備のセキュリティキーはどこにあるか。緊急キットには誰がアクセスできるか。認証基盤や保管庫が使えないとき、最重要のサービスへどう入るか。その経路を悪用されないよう、誰が使用を承認し、何を記録するか。
これらを決め、小さな範囲で復旧できることを確かめます。復旧手順は、存在するだけでなく、必要なときに実行できなければ役に立ちません。
7.導入の成果は、保管した件数で測らない
導入は、重要なアカウントから小さく始めます。次の順序を基本に、会社の状況に合わせて進めます。
| 段階 | 主な作業 | 確かめること |
|---|---|---|
| 棚卸し | 用途、責任者、利用者、認証・復旧方法を整理する | 管理者不明のアカウントが残っていないか |
| 重要箇所の保護 | メール、認証基盤、ドメインなど影響の大きい箇所を優先する | 認証を強めても復旧できるか |
| 共有の整理 | 個人別の権限へ移し、残る共有を保管庫へ集める | 必要な人だけが利用できるか |
| 認証の改善 | パスキーなどへ移行し、従来の経路も見直す | 弱い入口が意図せず残っていないか |
| 継続運用 | 異動・退職・紛失時の手順と定期点検を実施する | 権限の取消しと復旧を実行できるか |
費用を比較するときも、人数と月額だけで選ばない方がよいでしょう。必要な権限設定、レポート、認証基盤との連携が、検討中のプランで利用できるかを確認します。1Passwordでも、Teams Starter PackとBusinessでは管理・連携機能の範囲が異なります。[8]
成果として見るべきなのは、何件のパスワードを登録したかではありません。
管理責任者が不明なアカウントを解消できたか。共有IDを個人別の権限へ移せたか。退職した人のアクセスを止められるか。担当者が突然不在になっても、会社が復旧できるか。
パスワード管理を整えるとは、こうした問いに答えられるようにすることです。
1Passwordのような道具は、その作業を支えます。そして会社に残すべきものは、保管庫の中の秘密だけではありません。誰に何を任せ、いつ見直し、どう引き継ぐかという、実行できる手順です。
出典と確認範囲
主要な製品仕様の確認日:2026年9月25日。公式資料に基づく説明であり、実機検証や個別企業のセキュリティ評価を行ったものではありません。機能、対応環境、プラン、設定名は変更されるため、導入時に再確認してください。
- 1Password Support:Create, share, and manage vaults in your organization
- 1Password Support:Authentication and encryption in the 1Password security model
- 1Password Support:Turn on two-factor authentication for your 1Password account
- FIDO Alliance:Passkeys
- 1Password Support:How to export your data from the 1Password apps
- 1Password Support:Save and sign in with passkeys in your browser
- 1Password Support:Offboard a team member
- 1Password:Business & Teams Pricing & Plans
関連するエッセイ
- 経営上の問題から考える:会社のパスワードを、担当者任せにしない
- 架空事例と管理表で進め方を確かめる:会社のアカウント管理を整える実務ガイド
会員ログイン