Entra ID の SSO で使うパスワード管理：2026年版ガイド

SSO を後付けにしない方がよい理由

多くの保管庫は、パスワードを前提としたアカウントの仕組みの上に、SSO を上位プランの追加機能として後から載せています。その順序は表に出ます。結局は保管庫用のパスワードが残り、管理者から見た利用者のライフサイクルは後回しになり、SSO の階層には追加費用がかかります。SSO を前提とした設計はディレクトリから始まります。新しいアカウントを作る必要も、パスワードを配る必要もなく、入社した人は自動的に認識され、退職した人は Entra ID ですでに行っている停止操作だけで遮断されます。サインインがディレクトリそのものである以上、条件付きアクセスと MFA のポリシーはそのまま適用されます。

一つの厳しい問い：暗号鍵はどこにあるのか

SSO はあなたが誰かに答えるものです。何を復号できるかに答えてはいけません。Entra ID でサインインしただけで保管庫の中身が読めるなら、ID 基盤を握る者、あるいはそれを侵害した者にも読めるということであり、そのベンダーのゼロ知識という主張は静かに死んでいます。誠実なアーキテクチャは二つの仕組みを分けます。ID はディレクトリから、復号鍵はメンバー自身の端末上でマスターパスワードから導出し、決して送信しません。Keyvaci はそのように動いており、この分離はセキュリティ設計のページに余さず記載しています。どの製品を評価する場合でも、この問いを最初に、そして書面で確認してください。

設定はこうあるべきです

1. 管理者が Microsoft でサインインします。 組織の作成は、Microsoft が署名したトークンで検証された本物のテナント全体管理者に限るべきです。勤務先のメールアドレスがあるだけで、誰かが自社の名前を登録できてはいけません。
2. 復旧キットはクライアント側で生成されます。 あなたのブラウザが組織の署名鍵と復旧鍵を作り、一度だけ表示します。ベンダーがそれを見ることはありません。だからこそ復旧はお客様の手の内にとどまり、ベンダーの側には渡りません。
3. メンバーは既存のアカウントでサインインします。 各自がマスターパスワードを設定し、管理者に鍵を副署してもらい、保管庫を受け取り始めます。エージェントの導入もディレクトリのスキーマ変更も不要で、PKCE を用いた標準的な OIDC です。

管理者の検証の詳細や、テナント外のゲストで何が起きるのかを含む全体の流れは、Entra ID 連携のページにあります。

実際の導入から得た進め方のこつ

• テナント全体の管理者同意を一度与えておくと、メンバーに同意画面が表示されません。
• 誰かを招待する前に、最初の三つの保管庫を用意しておいてください。銀行、クラウドのアカウント、共有の SaaS です。必要なものがすでに入っている保管庫は、自然に使われます。
• 復旧キットは印刷し、その名のとおり最重要の鍵として保管してください。ベンダーが何も再設定できないことは、注意書きではなく機能です。
• Google Workspace をお使いですか。メールアカウントでの利用は今日から可能で、Google のネイティブ SSO はロードマップ上にあります。