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