こんにちは、ネクストモード株式会社のSaaSおじさん久住です。
「Keeperを導入したけれど、最初にどこまで設定すれば使い始められるの？」
このように感じている情報システム部門の方も多いのではないでしょうか。
Keeperは、パスワードやパスキーなどの認証情報を安全に保管し、ブラウザやアプリへの入力を効率化できるパスワードマネージャーです。一方、管理コンソールにはユーザー、ロール、チーム、SSO、プロビジョニングなど多くの設定項目があり、初回は「何から手を付ければよいのか」が分かりにくいかもしれません。
そこで本記事では、Keeperを組織で安全に使い始めるために、まず実施したい5つの設定を紹介します。
📝 本記事はKeeper Password ManagerのBusiness／Enterprise環境を想定しています。利用できる機能は契約プランやアドオンによって異なります。また、画面名やメニューはアップデートで変わる場合があります。
設定手順に入る前に、管理コンソールでよく使う4つの要素を押さえておきます。
📝 小規模な導入であれば、最初から複雑なノード構成を作る必要はありません。まずはルートノードを使い、ロールとチームをシンプルに設計するところから始めれば十分です。
Keeperを利用開始するために、まず実施したい5つのステップを順番に見ていきます。
各ステップでは、設定の目的と最低限確認しておきたいポイントを紹介します。
最初に守るべきなのは、利用者のアカウントよりも先に管理者アカウントです。管理者はユーザー、ロール、チーム、プロビジョニングなどを変更できるため、侵害された場合の影響が大きくなります。
まず、次の項目を確認します。
Keeper公式の推奨設定では、管理者がSSOでログインする場合でも、Keeper側のMFAを追加することが推奨されています。IdPの障害やアカウント侵害に備えるためです。
⚠️ 全管理者をSSOログインのみにすると、IdP障害やデバイス承認の問題が発生した際に管理できなくなる可能性があります。緊急時に使えるローカル管理者を準備し、その認証情報は厳格に管理しましょう。
次に、利用者へ適用するロールを確認します。ロールには「誰を所属させるか」だけでなく、Keeperの使い方を制御する強制適用ポリシー（Enforcement Policies）を設定できます。
最初から細かく制限しすぎると、想定外にKeeperFillや共有が使えず、利用開始時のトラブルにつながります。最初は次の項目を中心に、必要最低限のポリシーから始めるのがおすすめです。
設定は管理コンソールの 管理者 > ロール から対象ロールを選択し、強制適用ポリシー で行います。
新しく追加するユーザーへ同じロールを適用したい場合は、対象ロールをノードのデフォルトロールとして設定しておくと、割り当て漏れを防ぎやすくなります。
💡 最初の段階では、MFAとマスターパスワード強度をしっかり設定し、共有やエクスポートはパイロット利用で影響を確認してから段階的に制限するのがおすすめです。
基本ポリシーを決めたら、いきなり全社員を招待するのではなく、まずは情報システム部門など少人数のパイロットユーザーを追加します。
小規模な検証であれば、管理コンソールの 管理者 > ユーザー > ユーザーを追加 から手動で招待できます。利用者が多い場合はCSVインポートも利用できますが、利用者が増えてきたら、SSOやSCIMによるユーザー管理の自動化も検討しましょう。
ユーザーを追加したら、次の点を確認します。
最初は2〜5名程度で、管理者、一般利用者、共有フォルダを管理する利用者など、異なる使い方を試せるメンバーを選ぶと確認しやすくなります。
ユーザーがアカウントを有効化したら、実際にパスワードを保存・入力できる状態を作ります。
利用者側では、主に次の準備を行います。
ここで大切なのは、「アカウントを作ったら完了」ではなく、実際にレコードを保存し、KeeperFillでログインできるところまで確認することです。
また、利用者がブラウザ標準のパスワード保存機能を併用すると、保存先が分散してしまいます。Keeperへ移行する範囲と、ブラウザ側の保存機能をどう扱うかも社内ルールとして決めておきましょう。
📝 関連記事：【実体験】パスワードを手入力しない贅沢。営業事務の私がKeeperなしの生活に戻れない理由
📝 関連記事：【実録】Netflixが勝手に最上級プランに!? パスワード使い回しの恐怖と、私がKeeperに救われた理由
✅ ここまでで、利用者が「Keeperに認証情報を保存し、必要なときに呼び出してログインする」という基本操作を始められます。
個人のパスワード管理だけでなく、業務では複数人で同じ認証情報を使う場面があります。その場合、ユーザーへ個別に共有するのではなく、チームと共有フォルダを利用すると管理しやすくなります。
はじめに検証用のチームを1つ作り、共有フォルダを使ってみましょう。
管理者 > チーム でチームを作成するチームを使うと、異動や退職のたびに共有先を一件ずつ変更する必要がなくなります。
利用者はチームへ追加・削除し、認証情報は共有フォルダ単位で管理する、という役割分担にすると運用がシンプルです。
⚠️ 共有フォルダの管理権限や再共有権限を広く付けすぎると、意図しない共有につながります。最初は「誰がレコードを追加・編集できるか」「誰が共有先を変更できるか」を明確にしましょう。
📖 参考：Keeper公式 - チーム（日本語）
次の項目をすべて確認できれば、Keeperを小さく使い始められる状態です。
ここまで確認できていれば、パイロット運用としては十分です。
以降は、利用人数や運用負荷に合わせて設定を追加していきます。
Keeperを使い始める際は、最初からすべての機能を設定しようとせず、管理者の保護、基本ポリシー、少人数のユーザー追加、KeeperFill、チーム共有までを最初のゴールにするのがおすすめです。
ここまで確認できれば、Keeperを安全に使い始めるための土台はできています。
その後、アカウント移管、SSO、SCIM、セキュリティ監査、レポートとアラートへと段階的に広げることで、利用者の利便性を損なわずに、運用負荷の軽減とセキュリティ強化を進められます。
情報システム部門などの小さなチームで、実際にレコードを保存し、KeeperFillでログインし、共有フォルダを使うところから始めましょう。