はじめに
こんにちは、IdentityチームのTamaduです。
パスワードマネージャーのご相談にのっていると、ツールの設定そのものよりも「管理者アカウントの運用設計」を決めずに運用し、運用する中で後から困ってしまうというケースをよく目にします。そこで本記事では、Keeperを導入・運用するときに決めておきたい管理者アカウントの運用設計を、4つの観点で整理しました。
3行まとめ
- これからKeeperを導入する、もしくは既に運用中の情シス・セキュリティ担当者向けです。
- ツールの設定より先に決めておきたい「管理者アカウントの運用設計」をまとめています。
- 誰も管理コンソールに入れない、といった復旧不能リスクを避けるための具体策が分かります。
1. 管理者は最低2名以上にする
Keeperは暗号化・復号をすべて利用者の端末側で行い、ベンダーが復号鍵を持たないというZero-Knowledge設計なので、ベンダー側が管理者アカウントのマスターパスワードをリセットすることはできません。組織内の誰か1人だけが知るパスワードが失われると、そのアカウントは事実上復旧できなくなります。
やってしまいがちなパターンは以下の通りです。
- 管理者が1人だけ、かつその個人アカウントにフル管理権限を付与
- パスワードは本人しか知らず、記録もない
この状態で退職・長期休職・パスワード紛失が起きると、ユーザー管理もポリシー変更もできなくなります。サポートに依頼しても解決しないので、設計段階で対策しておくしかありません。
ただしKeeperには、退職者などのボルトを別の管理者が引き継ぐためのアカウント移管ポリシー(Account Transfer Policy)があります。Zero-Knowledgeを保ったまま暗号鍵を受け渡す仕組みで、移管が必要になる前にロール側で有効化しておく必要があります。暗号鍵の交換は、有効化後にユーザーがログインして移管に同意したときに行われます。そのため移管できないのは、有効化後に一度もログイン・同意をしていないユーザー(すでに退職して再ログインしない人など)のボルトです。なお、このポリシーはデフォルトで有効になっています(All Usersロールに対してポリシーが有効化され、Keeper Administratorロールに移管の管理権限が付与された状態)。ただし設定変更の有無によって状態は異なるため、自組織の設定を一度確認しておくのが確実です。裏を返すと、移管にはもう1人の管理者と事前設定が前提になるため、管理者を1人に集約していると、この仕組みも機能しません。
出典：https://docs.keeper.io/enterprise-guide/account-transfer-policy
こうした事情から、まず徹底したいのが、管理者を最低2名以上にすることです。複数の管理者が常に管理コンソールへ入れる状態を保ち、特定の1人の認証情報に運用全体が依存しないようにします。先ほどのアカウント移管ポリシーも、もう1人の管理者がいてはじめて機能します。
あわせて、複数の管理者を安全に運用するために、以下も決めておきます。
- 職務ベースでロールを設計する。「情報システム部のKeeper管理者」「セキュリティ運用の監査ロール」のように職務とKeeperロールを対応させ、人の出入りがあってもロールから外すだけで権限を剥奪できるようにしておく。
- 退職・異動時のハンドリングを事前に定義する。ディレクトリ連携が前提なら、「このIdPグループから外れたら管理ロールも自動で外れる」形にしておきます。人手運用だと、退職済みなのに管理コンソールへ入り続けられる状態が残りやすいです。
管理者を増やし、職務ベースのロールと連携で権限を管理する。ここまでをセットにしておくと、特定の個人が抜けても運用が止まりません。
2. SSOに依存しないBreak Glass管理者を用意する
Keeperのログイン経路は大きく2つあります。
- Keeperのマスターパスワードによるネイティブログイン
- IdP(Okta / Entra ID など)経由のSSOログイン
Keeperでは、SSOを有効化したノードのユーザーはマスターパスワードでログインできなくなります。IdPを迂回した認証を防ぐためで、マスターパスワードを残す・捨てる以前に、SSO配下のアカウントはそもそもマスターパスワードでは入れません。
なので、管理者を全員SSO配下に置くのはおすすめしません。SSOが止まると、管理者自身がKeeperに入れなくなる可能性があるためです。
想定しておきたいケースは以下の通りです。
- IdP障害でSSO全体が利用不可になる
- SAML証明書の期限切れや設定ミスで、KeeperだけSSOが失敗する
- Keeper SSO設定の変更ミスで、誰もログインできなくなる
管理者がSSO前提のアカウントしか持っていないと、SSO設定を直すための管理コンソールに誰も入れません。これを避けるために用意するのが、IdPと連携しないBreak Glass管理者アカウントです。
アカウントは、用途に応じて次の2種類に分けます。
通常の管理者アカウント
- IdP連携されたアカウント
- SSOとIdP側MFAを前提に運用
- 日々のユーザー管理やポリシー変更はこれで実施
Break Glass管理者アカウント
- IdPと連携しないKeeperアカウント
- 強力なマスターパスワードとKeeper側MFAで保護
- 普段は使わず、SSOが使えないときだけ使う
このように分けておくと、SSO障害時に何もできない事態を避けられます。Break Glassアカウント自体のリスクは大きいので、パスワード保管とMFAは厳重に設計します。IP制限をかけられる環境なら、ログインできるIPも絞っておくとより安全です。
なお、独立したアカウントを用意するかわりに、SSO配下のユーザーにロールポリシーで代替マスターパスワード(Alternate Master Password)を許可し、SSO障害時はマスターパスワードで入れるようにする方法もあります。ただし運用をシンプルに保つなら、SSO配下に置かないBreak Glass管理者を別に持っておくほうが確実です。
一般ユーザーは、利用体験を優先してIdPのSSOとMFAに寄せて構いません。管理者だけ経路を分けて守る、という方針を徹底するのがよいと思います。
出典：https://www.keepersecurity.com/ja_JP/features/break-glass-account/
3. IdP連携(Okta / Entra ID など)時の注意点
OktaやEntra IDなどとKeeperを連携するとき、SAML / SSOとSCIMをセットで使うケースが増えています。連携をIdP任せにしすぎると、意図しない権限付与やSSO障害時の締め出しが起きやすくなります。製品によらない共通する注意点を挙げます。
管理者と一般ユーザーの経路を分ける
IdPとKeeperの連携では、多くの環境が次の構造を取ります。
- IdPのグループを、Keeperのチームへ同期する(SCIMの既定動作)
- そのチームにロールを割り当て、ロールの強制ポリシー(Enforcement Policy)で要件を適用する
現時点(本記事執筆時点)のKeeperの仕様は、管理者ロールをチーム経由で割り当てられない仕様です。公式ドキュメントには以下のように書かれています。
Currently Keeper does not allow mapping of administrative roles to teams, in order to prevent an admin from inadvertently elevating permissions of a user. This feature is being considered for a future release.
出典：https://docs.keeper.io/enterprise-guide/roles
チームへの追加によって意図せず管理権限が昇格するのを防ぐための仕様で、管理者ロールは個々のユーザーに直接、明示的に付与します。つまり現時点では「一般ユーザー用グループに誤って追加した瞬間にKeeper管理者になる」ことは、管理者ロールに関しては起こりません。
ただし上記引用の末尾のとおり、Keeperはこの制約を将来のリリースで緩和することを検討しています。これが実現すると、管理者向けグループへの誤った追加がそのまま管理権限の昇格につながり得ます。つまりこの仕様は将来変わり得る前提で考え、「管理者向けの導線を分ける」設計をあらかじめ徹底しておくことをおすすめします。
一方で、SCIMのロールマッピング(Role Mapping Prefix)やチームへのロール割り当てを使えば、管理者ではない強い権限ロールはグループ追加で付与され得ます。ここには事故の余地が残るので、最初から次の方針を取るのがおすすめです。
- 「Keeper-Admin」「Keeper-Security-Admin」のように管理者向けグループを明確に分ける
- 強い権限ロールはそのグループにだけ対応づける
- 一般ユーザー向けグループからは強い権限が付かないようにする
グループの粒度を細かくするというより、管理者向けの導線そのものを分けるイメージで設計すると事故が減ります。
プロビジョニングとロール付与の条件を明文化する
SCIMやJITプロビジョニングを使うと、IdP側のユーザー作成やグループ操作が、そのままKeeperのアカウント作成やロール付与につながります。どの条件で強い権限が付くのかが曖昧だと、想定外のユーザーにまで権限が広がります。最低限、以下は文書化しておくのがおすすめです。
- 強い権限ロールに対応するグループ名・属性値を一覧化する
- そのグループにユーザーを追加・削除できるのは誰か(どのロールか)を決める
- 管理者ロールや特権ロールのメンバーを四半期などで棚卸しする
IdPグループのメンバーが、そのまま特権ID候補になります。アイデンティティ基盤側の権限設計が、そのまま特権ID管理に直結します。
Break Glassの確認を、IdP連携の運用フローに組み込む
第2節で用意したBreak Glass管理者が非常時に使えるよう、IdP連携の運用手順の中に動作確認のタイミングを決めて組み込んでおきます。証明書更新やSSO設定変更など、ログインに影響しうる作業の手順に、以下のチェックを入れます。
- 変更前に、Break Glass管理者でログインできることを確認する
- SSO設定を変更したら、SSOとBreak Glassの両方でログインできるかを確認する
- SSOが失敗したら、Break Glassで入って直前の設定にロールバックする
こうしておくと、「SSOが止まったとき誰がどう管理コンソールに入るか」が手順として残り、属人的な対応に頼らずにすみます。
IdP側でも特権アカウントとして扱う
Keeperの管理者は、ユーザーやロール、ポリシー、さらには特権アクセス管理(KeeperPAM)で扱うサーバーやデータベースなどのリソースまで広く触れる特権アカウントです。Keeper側だけでなく、IdP側でも特権として扱います。
- 管理者向けグループには、より強いMFA(FIDO2セキュリティキーなど)を必須にする
- 管理操作は、会社が許可した端末やネットワークからだけに絞る
- 普段と違う場所や端末からのサインインには、追加認証を求めるかブロックする
これらはKeeper側のロールポリシーだけで完結しないので、IdP側のアクセス制御とあわせて設定します。
4. 特権アカウントを専用ポリシーで分離する
Keeperの管理者権限は、ユーザー管理だけでなく、PAMでのサーバーやデータベースへのアクセス、共有クレデンシャルの管理にもおよびます。影響範囲が広いので、特権アカウントは一般ユーザーと同じロールや同じ保管場所にまとめません。
専用ロールとポリシーを設計する
「管理者」を1つの強いロールにまとめず、やることに応じて分けます。例えば、以下の3つです。
- Admin-Global：全体管理者。ユーザーやロール、ポリシーを変更できる。MFAとパスワードポリシーは最も厳しくする。
- Admin-Security：監査ログやポリシーの参照が中心。設定変更の権限は持たせない。
- PAM-Operator：特権アカウントのローテーションやチェックアウトを担当。Admin-Globalに準じたMFAをかける。
ロールを分けておくと、「監査だけ任せたい人にユーザー削除権限まで渡してしまう」といった付けすぎを防げます。これらのロールは、第3節のとおりIdP側でも特権として扱います。
特権IDは専用フォルダに分けて入れる
サーバーのrootやクラウドの管理者アカウントなど、漏れたときの被害が大きい資格情報は、一般ユーザーと同じフォルダには入れません。
- 特権ID専用のフォルダ(共有スペース)を作り、入れる場所を分ける
- そのフォルダを開けるロールを限定する
- 開いた・使ったという操作のログを残す
- 可能ならPAMで中継し、パスワードを画面に出さずにサーバーへ接続する
分けておくと、棚卸しや監査のときに「どの特権IDに誰が触れるか」をそのまま示せます。
おわりに
Keeperの管理者アカウント運用を、4つの観点で整理しました。
- 管理者を最低2名以上にし、ロールとプロセスで守る
- Break Glassアカウントを用意する
- IdP連携では管理者の導線を分け、付与条件を明文化する
- 特権アカウントは専用ロールと専用フォルダで分離する
管理者アカウントの設計は、普段はあまり意識しませんが、SSO障害や退職といったトラブル時に差が出ます。導入のタイミングでロールとプロセスを決めておくと、後の運用がだいぶ楽になると思います。Keeperを利用している組織の参考になればうれしいです。
