情報漏えいの報道の後に見直すログイン：流出したメールアドレスが招く不正ログインと、パスキーで塞げること

パスキーは、サーバーへの侵入や情報漏えいそのものを防ぐ仕組みではありません。防げるのは、漏れたメールアドレスや氏名を足がかりにした「その後」の不正ログインです。偽サイトに誘導するフィッシングと、他のサービスで漏れたパスワードを試すパスワードリスト攻撃に対して、パスキーは仕組みとして強く、サービス側のデータベースが漏れてもログインに使える情報が出ません。この記事では、漏えいの報道が続いた後にログインの運用者が確かめておくことと、パスキーを既存のログインに足す進め方をまとめます。

国家サイバー統括室の注意喚起

2026 年 10 月 9 日、内閣官房国家サイバー統括室は「不正アクセスによる漏えい等の事案を踏まえた対応について」を公表しました。ウェブシステムの脆弱性の悪用、サプライチェーンを通じた侵害、堅牢さを欠くデータ管理などにより、大量の個人情報を取り扱う事業者の情報システムに侵入され、個人情報を含むデータが窃取される事案を複数確認しているとしています。

文書は、インターネットに公開されているシステムについて「いつ攻撃を受けてもおかしくない」という前提で対策を講じることが重要だとし、主な対策のポイントを挙げています。ログインに関わるものを抜き出すと、次のとおりです。

• 多要素認証 (MFA) を導入する
• 推測されやすいパスワードの使用を禁止する
• 外部からの異常な認証試行を把握する
• パスワードや認証情報を平文で保存しない
• 利用目的を終えた情報は速やかに削除する (保有情報の最小化)

文書の多くは、侵入そのものを防ぐ対策 (脆弱性の修正、委託先の管理、データの暗号化とアクセス制御) に充てられています。ここから先は、その中でも「利用者のアカウント」に関わる部分を扱います。

漏えいの後に来るもの

漏えいの可能性がある情報がメールアドレスや氏名だけでも、それで終わりとは限りません。攻撃する側にとって、正しいメールアドレスの一覧は次の 2 つの手口の材料になります。

• フィッシング。 漏えいを知らせるお詫びや本人確認を装ったメールを送り、偽のログイン画面に誘導して、パスワードやワンタイムパスワードを入力させます。実在の会員のアドレスに、実在のサービスの名前で届くので、見分けにくくなります。
• パスワードリスト攻撃 (クレデンシャルスタッフィング)。 他のサービスで漏れたメールアドレスとパスワードの組を、別のサービスのログインに次々に試します。利用者が同じパスワードを使い回していれば、自社のシステムに何の問題が無くても入られます。

どちらも、行き着く先はアカウントの乗っ取りです。漏えいを起こしたのが自社でなくても、自社の会員のアドレスが含まれていれば、自社のログインが狙われます。

パスキーで塞げること、塞げないこと

パスキーは、FIDO アライアンスと W3C が定めた WebAuthn の仕組みによるログインです。登録のときに利用者の端末の中で鍵の組を作り、サービス側には公開鍵だけを渡します。ログインのときは、サービスが送った challenge に端末が秘密鍵で署名し、サービスは公開鍵で確かめます。鍵はサービスのドメイン (RP ID) ごとに作られ、ブラウザは開いているページのドメインに合う鍵でしか署名しません。

最後の 2 つが、導入の進め方で差が出るところです。パスキーを足しても、パスワードと弱い復旧の流れがそのまま残っていれば、攻撃はそちらへ回ります。

報道の後に、自社のログインで確かめること

パスキーを入れるかどうかに関わらず、まず今のログインで次を確かめます。

試行回数の制限と監視

パスワードリスト攻撃は、少数のパスワードを多数のアカウントに試すので、アカウントごとのロックだけでは捉えきれません。IP アドレスごと、アカウントごと、サービス全体の 3 つの単位で失敗の数を見て、急に増えたら気付けるようにします。国家サイバー統括室の文書にある「外部からの異常な認証試行を把握する」にあたる部分です。アカウントをすぐにロックする設定は、攻撃者が利用者を締め出す手段にもなるので、一定時間の待ちや追加の確認と組み合わせます。

新しい端末でのログインの通知

見覚えのないログインに利用者が気付けるよう、新しい端末やブラウザからのログイン、メールアドレスやパスワードの変更、認証方法の追加をメールで知らせます。乗っ取りに早く気付くための、手間の少ない対策です。

ワンタイムパスワードの弱点

SMS やアプリのワンタイムパスワードは、パスワードだけの場合より強い一方で、偽サイトに入力させて本物のサイトへすぐ中継する手口には耐えられません。利用者が偽サイトに数字を打ち込めば、その数字はそのまま使えてしまうからです。多要素認証を入れていることと、フィッシングに強いことは別だと考えます。

復旧の流れ

パスワードの再設定、メールアドレスの変更、サポート窓口での本人確認は、ログインの「裏口」です。メールアドレスだけで再設定できる流れは、メールのアカウントが乗っ取られていればそのまま突破されます。再設定の後に利用者へ通知する、重要な変更の前にもう一度確認する、窓口の本人確認で何を見るかを決めておく、といった点を見直します。

保存している認証情報

パスワードを平文や可逆な形で保存していないか、ハッシュの方式が今の水準か、使わなくなった認証情報やアカウントが残っていないかを確かめます。持っていない情報は漏れません。

パスキーを既存のログインに足す進め方

パスキーは、今のログインを置き換えるのではなく、並べて足すのが現実的です。利用者の端末やブラウザはさまざまで、全員が初日から使えるわけではないからです。

1. ログインの画面にパスキーを並べる。 今のメールアドレスとパスワードの入力欄はそのままに、「パスキーでログイン」を足します。ユーザー名の入力欄の自動入力にパスキーを出す方法 (conditional UI) を使うと、画面をほとんど変えずに済みます。
2. ログインの後に登録を促す。 パスワードでログインした直後は、本人であることを確かめた直後でもあります。そこで「次からは指紋や顔認証でログインできます」と案内し、その場で登録してもらいます。
3. 代わりの手段を残す。 パスキーを使えない端末や、端末をなくした人のために、パスワードやメールでの手段をしばらく残します。そのうえで、パスキーを登録した人から順にパスワードを使わない形へ移る期限を決めます。
4. 復旧を先に決める。 端末をなくした人をどう本人と確かめて再登録させるかを、公開の前に決めます。ここを決めずに始めると、問い合わせが「ログインできない」で埋まります。

段階の考え方は 既存のログインにパスキーを足す手順 と パスキーの復旧の設計 でも詳しく扱っています。

SealGate で足す場合

SealGate は、既存のログインにパスキーを後付けするための API とブラウザ SDK です。上の進め方に沿うと、次のように使います。

• 登録とログイン。 ブラウザでは SDK の sg.register() と sg.login() を呼び、開発者のサーバーは SDK から届いた JSON に API キーを付けて SealGate に中継します。ログインが通ったら、セッションは開発者側で発行します。ログインの後の追加登録は、サーバーのセッションで本人を確かめたうえで signed_in: true を付けます。
• 入力欄の自動入力。 sg.login({}, { mediation: 'conditional' }) で、ユーザー名の入力欄の候補にパスキーを出せます。
• 保存するデータ。 SealGate が持つのは、開発者が付けた利用者 ID (external_id) と表示名、パスキーの公開鍵、認証の記録です。利用者の氏名やパスワードは持ちません。external_id にはメールアドレスではなく、個人を表さない ID を使うことを勧めています。
• 復旧。 端末をなくした利用者の本人確認は開発者側で行い、その後に POST /v1/recovery/start で 15 分有効の復旧トークンを発行して再登録してもらいます。SealGate は本人確認をしません。
• 乗っ取りが疑われたとき。 POST /v1/users/{external_id}/revoke で、その利用者のパスキーをすべて失効できます。
• 監視と通知。 登録とログインの成否は監査ログに残り、Webhook (register.completed・login.failed など) でも受け取れます。パスキーが追加されたことを利用者に知らせる、失敗の急な増加に気付く、といった使い方ができます。
• パスワードとの併存期限。 アプリの設定で併存期限を決めると、期限を過ぎた後のログインの応答で password_allowed が false になります。パスキーを登録した人から順にパスワードを止める判断に使えます。

API とコードの例は ドキュメント にあります。料金は LP の料金表 をご覧ください。

よくある質問

パスキーを入れれば、情報漏えいは防げますか。

防げません。パスキーはログインの仕組みで、サーバーへの侵入やデータの窃取は、脆弱性の修正やアクセス制御で防ぐものです。パスキーが効くのは、漏れた情報を使ったその後の不正ログインです。

メールアドレスだけが漏れた場合も、対策は必要ですか。

必要です。正しいメールアドレスの一覧は、フィッシングメールの送り先と、パスワードリスト攻撃で試すアカウントの一覧になります。試行回数の制限と監視、新しい端末でのログインの通知を確かめておきます。

多要素認証を入れていれば十分ですか。

SMS やアプリのワンタイムパスワードは、偽サイトに入力させて中継する手口には耐えられません。フィッシングへの強さを求めるなら、署名がドメインに結び付くパスキーを足すことを検討します。

関連

• パスキーとは何か｜急に広がった理由と、自社サービスへの入れ方 (シャノン)
• パスキー認証の導入費用と比較 (シャノン)
• 情報漏えいとアカウントの乗っ取り (シャノン)

出典

• 不正アクセスによる漏えい等の事案を踏まえた対応について (内閣官房国家サイバー統括室、2026 年 10 月 9 日)
• Web Authentication: An API for accessing Public Key Credentials Level 3 (W3C)
• Passkeys (FIDO Alliance)