Microsoft Edge: v.148 – Password affiliation serviceは、Edgeのパスワード自動入力候補を「同じ上位ドメインかどうか」だけで判断するのではなく、関連するドメイン群にも広げる変更です。たとえば、同じサービス群に属する複数ドメインで、保存済み資格情報をより適切に候補表示できるようになります。
管理者が最初に確認すべき結論は明確です。Edgeのパスワードマネージャーを利用する組織は、関連ドメイン間でどの資格情報が候補表示されるかを検証してください。一方、組織としてEdgeのパスワード保存や自動入力を使わせない方針なら、PasswordManagerEnabledだけでなくPrimaryPasswordSettingも併用して制御する必要があります。Microsoftのv148 Stableリリースノートでは、両方のポリシーを構成することで、パスワード保存、自動入力検索、affiliation endpointへの問い合わせを抑止できると説明されています。(Microsoft Learn)
Microsoft Edge v148のPassword affiliation serviceで何が変わるのか
Password affiliation serviceは、Microsoft Edgeのパスワード自動入力候補に関する機能です。従来のEdgeでは、保存済みパスワードの候補表示が主にトップレベルドメインの一致に基づいていました。v148では、Edgeが関連ドメインのグループを取得し、そのグループ内で関連する資格情報を候補として表示できるようになります。(Microsoft Learn)
公式説明では、ユーザーがURLにアクセスすると、Edgeクライアントがaffiliations backendへ問い合わせ、訪問先URLのハッシュを送信します。サービス側は関連URLのリストを返し、Edgeはその結果をもとに、関連ドメインで適切な保存済み資格情報を表示します。説明されている送信対象はURLハッシュであり、パスワード本文を送信する機能としては説明されていません。(Microsoft Learn)
| 観点 | 従来の挙動 | v148のPassword affiliation service |
|---|---|---|
| 候補表示の判断 | 主にトップレベルドメインの一致 | 関連ドメインのグループも考慮 |
| 代表例 | account.microsoft.comとoffice.microsoft.comのような近いドメインで候補が出る | デスクトップやモバイルの複数プロパティをまたぐ関連付けを利用 |
| 外部サービスへの問い合わせ | 機能説明上、affiliation backendの利用は前提ではない | 訪問URLのハッシュをもとに関連グループを問い合わせる |
| 管理上の要点 | パスワード保存の可否が主な確認点 | 保存、自動入力、問い合わせ抑止を分けて確認する必要がある |
影響を受ける対象者
この変更は、単なるUI変更ではありません。ユーザー体験、セキュリティ運用、プロキシや監査ログ、社内アプリのログイン設計に関係します。
| 対象者 | 想定される影響 | 確認すべきこと |
|---|---|---|
| 一般ユーザー | 関連サイト間でログイン候補が出やすくなる | 誤ったアカウントを選ばないよう、候補のドメインとユーザー名を確認する |
| IT管理者 | ポリシー設定次第でaffiliation endpointへの問い合わせ有無が変わる | PasswordManagerEnabledとPrimaryPasswordSettingの組み合わせを確認する |
| セキュリティ担当者 | URLハッシュ送信や自動入力候補の範囲を評価する必要がある | プライバシー影響、監査要件、外部パスワードマネージャー方針との整合性を確認する |
| Webアプリ開発者 | ログインフォームの自動入力挙動が変わる可能性がある | 本番、検証、管理画面、SSO連携画面で候補表示をテストする |
特に注意したいのは、Edgeのパスワードマネージャーを「保存だけ禁止している」組織です。PasswordManagerEnabledを無効化すると新しいパスワードの保存や追加はできなくなりますが、Microsoftのポリシー説明では、以前に保存済みのパスワードは引き続き使用できるとされています。(Microsoft Learn)
つまり、「新規保存を禁止したから自動入力も完全に止まっている」と考えるのは危険です。自動入力候補やバックエンド問い合わせまで止めたい場合は、PrimaryPasswordSetting側の制御も確認してください。
管理者が確認すべき2つのポリシー
Password affiliation serviceの管理では、次の2つのポリシーが重要です。
PasswordManagerEnabled
PasswordManagerEnabledは、Edgeにユーザーのパスワード保存を許可するかどうかを制御するポリシーです。Windows、macOS、Android、iOSでサポートされ、Windowsではグループポリシーの「Administrative Templates/Microsoft Edge/Password manager and protection」配下にあります。レジストリではSOFTWARE\Policies\Microsoft\EdgeのPasswordManagerEnabledを使用します。(Microsoft Learn)
| 設定 | 挙動 |
|---|---|
| 有効、または未構成 | ユーザーはEdgeにパスワードを保存・追加できる |
| 無効 | 新しいパスワードの保存・追加はできない。ただし、以前保存したパスワードは引き続き使用できる |
管理者が失敗しやすいのは、ここで設定を止めてしまうことです。外部の企業向けパスワードマネージャーに統一する場合や、共有端末でブラウザー保存を禁止する場合は、保存禁止だけでは不十分なケースがあります。
PrimaryPasswordSetting
PrimaryPasswordSettingは、保存済みパスワードを自動入力する際に、デバイス認証などを求めるかどうかを制御するポリシーです。WindowsとmacOSでサポートされ、AutofillOffを設定すると保存済みパスワードは自動入力候補として表示されなくなります。(Microsoft Learn)
| 値 | 設定名 | 実務上の使いどころ |
|---|---|---|
0 | Automatically | 認証フローなしで自動入力を許可する。利便性重視だが、管理端末では慎重に扱う |
1 | WithDevicePassword | Windows Hello、PIN、顔認証、指紋などのデバイス認証を求める |
2 | WithCustomPrimaryPassword | カスタムプライマリパスワード。廃止予定のため、新規設計では使わない |
3 | AutofillOff | 保存済みパスワードを自動入力候補に表示しない |
デバイス認証は、離席中の端末で第三者が保存済みパスワードを使うリスクを下げるには有効です。ただし、Microsoftの説明ではローカルで動作するマルウェアに対する保護ではないと明記されています。過信せず、EDR、端末管理、最小権限、MFAと組み合わせて考えるべきです。(Microsoft Learn)
組織方針別のおすすめ設定
Password affiliation serviceをどう扱うべきかは、組織がEdgeのパスワードマネージャーを正式に利用するかどうかで変わります。
| 組織方針 | 推奨設定 | 判断基準 |
|---|---|---|
| Edgeのパスワードマネージャーを許可する | PasswordManagerEnabled=Enabled、PrimaryPasswordSetting=WithDevicePasswordを検討 | 利便性を維持しつつ、端末認証で不用意な自動入力を抑える |
| 企業指定の外部パスワードマネージャーに統一する | PasswordManagerEnabled=Disabled、PrimaryPasswordSetting=AutofillOff | Edge保存を避け、候補表示や問い合わせも抑えたい場合 |
| 移行期間だけ既存保存パスワードを使わせる | PasswordManagerEnabled=Disabled、PrimaryPasswordSetting=WithDevicePasswordなどを限定適用 | 新規保存を止めつつ、既存ユーザーの移行負荷を下げる |
| 共有PC、受付端末、検証用端末 | PasswordManagerEnabled=Disabled、PrimaryPasswordSetting=AutofillOff | 端末利用者が固定されないため、ブラウザー保存自体を避ける |
| 高セキュリティ部門 | 原則としてAutofillOffを検討 | 認証情報の候補表示範囲よりも統制を優先する |
Microsoft Edge v148のリリースノートでは、Password affiliation serviceのアクセス制御にはPasswordManagerEnabledとPrimaryPasswordSettingを併用する必要があると説明されています。特に「affiliation endpointへ問い合わせさせたくない」ことが要件なら、両方の設定を確認してください。(Microsoft Learn)
展開前に確認するチェックリスト
Edge Stableの更新は、環境によって反映タイミングが異なります。MicrosoftはStableチャネルのメジャーアップデートを数日かけて段階的に展開すると説明しており、Intuneの自動更新では段階的ロールアウトの影響を受けます。一方、WSUSやConfiguration Managerで配布を管理している企業では、管理者が適用タイミングを制御します。(Microsoft Learn)
| 確認項目 | 具体的な作業 |
|---|---|
| Edgeのバージョン | 対象端末がv148系に更新されているか確認する |
| ポリシー適用状況 | edge://policyでPasswordManagerEnabledとPrimaryPasswordSettingの値、適用元、エラー有無を確認する |
| プロファイル単位の差 | 業務プロファイル、個人プロファイル、ゲスト利用で挙動が異ならないか確認する |
| 保存済みパスワード | 既存の保存済みパスワードが残っている端末で候補表示を検証する |
| ネットワーク制御 | プロキシ、ファイアウォール、SSLインスペクション環境でEdgeのサインインやパスワード機能に副作用がないか確認する |
| ユーザー周知 | 候補に複数アカウントが出る場合の選び方、業務パスワードを保存してよい範囲を周知する |
| ロールバック方針 | 問題発生時にAutofillOffへ切り替える対象グループと手順を事前に決める |
展開の順序は、まず情報システム部門とセキュリティ部門の少人数で検証し、次にMicrosoft 365を頻繁に使う部門へ広げるのが現実的です。account.microsoft.com、office.microsoft.com、社内SSO、外部SaaS、管理者ポータルなど、利用頻度が高く認証情報の影響が大きいサイトを優先して確認してください。
開発者とサイト運営者が見るべきポイント
Password affiliation serviceは、主にブラウザー側の資格情報候補表示に関する機能です。ただし、Webアプリ側のログインフォームがあいまいだと、ユーザーが意図しない候補を選びやすくなります。
ログインフォームでは、ブラウザーが入力欄の意味を判断しやすいように、autocomplete属性を適切に指定してください。MDNはautocomplete属性を、フォームコントロールへどのように事前入力するかをユーザーエージェントに伝えるヒントとして説明しており、ユーザー名にはusername、現在のパスワードにはcurrent-password、新しいパスワードにはnew-passwordが使えます。(MDNウェブドキュメント)
<form method="post" action="/login">
<label for="email">メールアドレス</label>
<input id="email" name="email" type="email" autocomplete="username">
<label for="password">パスワード</label>
<input id="password" name="password" type="password" autocomplete="current-password">
<button type="submit">ログイン</button>
</form>新規登録やパスワード変更画面では、既存パスワードを入力する欄と新しいパスワードを設定する欄を明確に分けてください。web.devのログインフォームのベストプラクティスでも、ログイン時はautocomplete="current-password"、登録やパスワードリセットではautocomplete="new-password"を使うことが推奨されています。(web.dev)
また、次のような設計はトラブルの原因になります。
| 問題になりやすい設計 | 起こり得る問題 | 対策 |
|---|---|---|
| 本番環境と検証環境で同じログイン画面名・同じ見た目を使う | ユーザーが誤って本番用資格情報を検証環境で選ぶ | 検証環境のドメイン、画面表示、フォーム属性を明確に分ける |
| 管理者ログインと一般ユーザーログインが同一フォーム | 権限の違うアカウント候補を選び間違える | 管理者画面のURL、ラベル、認証方式を分ける |
パスワード変更画面でcurrent-passwordとnew-passwordを区別しない | ブラウザーが既存パスワード入力と新規パスワード設定を誤認しやすい | 現在のパスワード欄と新しいパスワード欄に適切なautocompleteを設定する |
autocomplete="off"に頼りすぎる | パスワードマネージャーの利便性と安全なパスワード利用を妨げる | 無効化ではなく、正しい属性指定で誘導する |
よくある誤解と注意点
PasswordManagerEnabledを無効にすれば完全に止まるわけではない
PasswordManagerEnabledを無効にすると、新しいパスワードの保存や追加はできません。しかし、以前に保存されたパスワードは引き続き使用できるとMicrosoftのポリシー説明にあります。自動入力候補も止めたい場合は、PrimaryPasswordSetting=AutofillOffを含めて設計してください。(Microsoft Learn)
URLハッシュ送信だからプライバシー影響がゼロとは限らない
公式説明では、affiliation backendへの問い合わせで訪問URLのハッシュを送信するとされています。ハッシュ化されているとはいえ、業務上センシティブなURL体系を扱う企業では、セキュリティレビューやプライバシー評価の対象に含めるのが安全です。(Microsoft Learn)
すべての関連ドメインを管理者が自由に定義できる機能ではない
この機能は、Edgeがaffiliations backendから関連グループを取得して候補表示に使う仕組みです。現時点の公開説明では、管理者が任意の社内ドメインを登録して独自の関連グループを作る機能としては説明されていません。社内アプリのログイン統合をしたい場合は、Password affiliation serviceに期待するのではなく、SSO、Microsoft Entra ID、SAML、OIDCなどの認証基盤側で設計するのが本筋です。(Microsoft Learn)
Microsoft 365 Roadmapの時期情報は変更される可能性がある
Microsoft 365 Roadmapは、商用機能の予定や説明を掲載するページですが、Microsoftは掲載情報が変更される可能性があると明記しています。展開時期を社内告知や運用手順に反映する場合は、ロードマップだけでなく、Microsoft EdgeのStableリリースノートと管理ポリシードキュメントもあわせて確認してください。(Microsoft)
管理者が次に取るべき行動
Microsoft Edge: v.148 – Password affiliation serviceへの対応は、難しい移行作業というよりも「パスワード自動入力を組織としてどう扱うか」を明確にする作業です。
まず、Edgeのパスワードマネージャーを許可するか、外部の企業向けパスワードマネージャーに統一するかを決めてください。次に、PasswordManagerEnabledとPrimaryPasswordSettingの現在値を確認し、少人数のv148環境で保存済みパスワード、関連ドメイン、SSO、管理者画面の挙動をテストします。
Edgeのパスワード自動入力を利用するなら、端末認証を組み合わせて誤利用を減らす。利用しないなら、保存禁止だけでなく自動入力候補とバックエンド問い合わせまで止める。この2点を押さえれば、Password affiliation serviceの展開後も、利便性と統制のバランスを取りやすくなります。
コメント