認証情報を狙う被害が続く中で、業務システムのログインを見直す

認証情報を狙う被害の現状

フィッシングの報告件数は過去最多、証券口座への不正アクセスも確認されている

フィッシング対策協議会が2025年1月から12月に受領したフィッシング報告件数は2,454,297件で、過去最多となりました。2024年と比べて約1.43倍です（「フィッシングレポート2026」）。警察庁の「令和7年におけるサイバー空間をめぐる脅威の情勢等について」では、インターネットバンキングに係る不正送金事犯が4,747件、被害総額が約103億9,700万円で、フィッシングがその手口の約9割を占めたとされています。

金融庁の公表データでは、証券会社のインターネット取引サービスにおける不正アクセスは、2025年1月から2026年8月までの累計で19,207件、そのうち不正取引が行われたものは10,639件でした（いずれも暫定値）。不正取引における売却金額は約4,368億円、買付金額は約3,837億円とされています。なお、これらは不正取引で行われた売却・買付の累計金額であり、顧客に生じた損失額と一致するものではありません。手口は、実在する証券会社を装った偽サイトなどで窃取したログインIDやパスワードを使った不正アクセスです。

これらは個人の口座に関する統計ですが、「偽サイトに入力した認証情報が、そのまま正規のログインに使われる」という構造は、パスワードで認証するクラウド型の業務システムにも共通します。

企業を狙う手口も巧妙化している

企業が標的となる事例も報告されています。警察庁は、犯罪グループが企業に電話をかけてメールアドレスを聞き出し、フィッシングメールを送る「ボイスフィッシング」による法人口座の不正送金被害が、2024年秋から2025年4月にかけて、また2025年11月にも急増したと述べています。

業務システムの認証情報が不正に使われると、そのアカウントの権限の範囲で、データの閲覧や操作が行われるおそれがあります。管理者権限のアカウントでは、影響がさらに広がる可能性があります。

パスワードやワンタイムパスワードだけでは防ぎにくいケースがある

パスワードにワンタイムパスワードを組み合わせる2要素認証は、パスワードだけの場合より安全性を高められる対策で、金融庁も多要素認証を有効にするよう案内しています。一方で、警察庁は「令和元年頃からリアルタイム型フィッシングにより二段階認証を突破する手口が横行するなど、手口の巧妙化が見られる」としています。偽サイトでIDとパスワード、ワンタイムパスワードまで入力させ、攻撃者がその場で本物のサイトに入力する手口です。

こうした背景から、人が偽サイトを見抜くことに頼らず、仕組みの側でフィッシングを防ぐ「フィッシング耐性のある認証」が、金融分野を中心に求められるようになっています。

パスキー認証の基礎知識

仕組み ― 秘密の値を入力させない認証

パスキーは、FIDOの標準仕様（FIDO2／WebAuthn）に基づく認証方式です。FIDO Allianceは、パスキーを、端末のロックを解除するときと同じ操作でアプリやWebサイトにサインインできる認証情報と説明しています。

仕組みは、公開鍵暗号方式にもとづいています。登録時に、利用者側の認証環境で「秘密鍵」と「公開鍵」のペアが作られ、公開鍵だけがサービス側に登録されます。秘密鍵は、端末やパスキーの認証情報プロバイダーによって保護され、サービス側には送信されません。サインインの際は、サービスから送られる使い捨ての確認用データに対して、端末が秘密鍵で署名を返し、サービスが公開鍵で検証します。秘密鍵を使うには、指紋・顔認証や端末のPINなどによる本人確認が必要です。パスワードのように、利用者が秘密の文字列を入力してサービスへ送ることはありません。

フィッシングに強いとされる理由

パスキーがフィッシングに強いとされるのは、認証に使う鍵が、登録したサービスのドメインにひも付くためです。W3Cが標準化しているWeb Authentication（WebAuthn）の仕様では、公開鍵の資格情報は、そのサービス（Relying Party）に属するオリジンからのみ利用できるとされています。利用者が偽サイトに誘導されても、ドメインが異なるため、端末は偽サイトに対して認証の応答を返しません。認証に使える秘密の値が偽サイトに渡ることもありません。

米国NIST（国立標準技術研究所）のデジタルアイデンティティ・ガイドライン「SP 800-63B-4」（2025年7月公表）は、フィッシング耐性を「利用者の注意力に頼ることなく、なりすましの検証者（偽サイトなど）に、認証の秘密や有効な認証出力が開示されることを防ぐ能力」と定義しています。米国の政府機関向けの内容ですが、認証保証レベル2（AAL2）では、多要素認証を求めるとともに、利用者が選択できるフィッシング耐性のある認証オプションを少なくとも1つ提供することを求めています。AAL2のすべての認証方式に、常にフィッシング耐性を必須とするという意味ではありません。

国内では、金融庁と警察庁が2025年7月、日本証券業協会を含む金融関係協会に対し、パスキーの導入促進などを要請しました。日本証券業協会は、2025年10月15日に施行したガイドラインで、ログイン時や出金時などの重要な操作について、フィッシングに耐性のある多要素認証（例：パスキーによる認証、PKI（公開鍵基盤）をベースとした認証）の実装と必須化を求めています。これらは金融機関向けの要請・ガイドラインであり、一般の業務システムに直接適用されるものではありませんが、認証方式を見直す際の参考になります。

使い勝手の面では、FIDO Allianceが2025年10月に公表した「Passkey Index」が参考になります。会員企業9社の報告では、パスキーによるサインインの成功率は93%（その他の方法は63%）、所要時間は平均8.5秒（従来の方法は平均31.2秒）でした。また、事業者によっては、ログイン関連のヘルプデスク問い合わせが最大81%減少したと報告されています。いずれも消費者向けの大規模サービスの数値で、業務システムにそのまま当てはまるとは限りませんが、一つの目安といえます。

導入前に知っておきたい留意点

パスキーは有効な選択肢の一つですが、万能ではありません。導入前に、次の点を確認しておくと安心です。

• 認証だけで、侵入経路のすべてを防げるわけではありません。Verizonの「2026 Data Breach Investigations Report」では、脆弱性の悪用から始まる侵害が、盗まれたパスワードを上回って最多の侵入経路になったと報告されています。認証の強化とあわせて、ソフトウェアの更新、アクセス権限の見直し、ログの確認といった基本的な対策も欠かせません。
• 端末の紛失・故障に備えます。パスキーには、利用者の端末間で同期できるものと、特定の端末に紐づくもの（デバイス固定型）があり（FIDO Alliance）、同期の可否や範囲は、OSやブラウザなどの環境によって異なります。重要なアカウントでは、複数の端末を登録しておくと安心です。
• 利用環境を確認します。端末に本人確認手段（指紋・顔認証やPINなど）が設定され、OS・ブラウザがパスキーに対応していることが必要です。

RapidTableのパスキー認証でできること

ここからは、パスキー認証をRapidTableでどのように利用できるかをご紹介します。

RapidTableは、エクセルやスプレッドシートを扱う感覚でデータベースを設計できる、SaaS型のノーコード・ローコードデータベースです。画像・動画・資料までを一元管理する業務データの基盤であるため、認証まわりの機能にも力を入れており、メールアドレスとパスワード、外部認証サービスとの連携、2要素認証（TOTP）、パスキー（FIDO2／WebAuthn）による認証に対応しています。パスキーの利用時には、端末の指紋・顔認証やPINなどで本人確認を行います。パスキーは、利用者自身が自分のアカウントの「セキュリティ設定」画面から設定できます。

「セキュリティ設定」から端末を登録する

パスキーの登録は、アカウントメニューの［セキュリティ］から開く「セキュリティ設定」画面で行います。

1. 「パスキー (生体認証)」欄の［端末を登録する］を選択します。
2. 画面の案内に従い、端末の生体認証（指紋・顔認証）やPINで本人確認を行います。
3. 登録が完了すると、「登録済み端末一覧」に端末が追加されます。

画面上の名称は「パスキー (生体認証)」ですが、本人確認は生体認証に限られず、端末のPINなどでも行えます。この設定項目は、ご利用の端末・ブラウザがパスキーに対応している場合に表示されます。登録時には、端末の情報をもとにした名称が「ラベル」として設定され、あとから分かりやすい名称に変更できます。

サインイン画面から、パスキーでサインインする

1. サインイン画面で［生体認証に切り替え］を選択します。
2. メールアドレスを入力し、［次へ］を選択します。
3. 端末の認証画面が表示されたら、指紋・顔認証やPINで本人確認を行います。完了すると、サインインできます。

パスワードの入力は不要です。前回利用した認証方式は、同じブラウザの次回サインイン画面の初期表示に反映されます。

登録済み端末の管理と、パスワードレス設定

「登録済み端末一覧」では、ラベル、作成日時、更新日時を確認でき、ラベルの変更や端末の削除ができます。端末の買い替えや紛失の際には、この画面から不要になった端末を削除します。

パスキーを1台以上登録すると、「パスワードの無効化」欄に［パスワードレス設定］が表示されます。実行すると、パスワードによるサインインが無効になります。設定後は、画面に「安全性の高い設定です」と表示されます。

パスキーを登録しても、パスワードでのサインインが有効なままだと、パスワードを狙う攻撃の余地は残ります。パスワードレス設定は、パスワードによるサインインという経路そのものをなくせる点に意味があります。一方で、設定の前に、パスキーで確実にサインインできることを確認し、複数の端末を登録しておくことが重要です。パスワードレス設定後は、サインイン画面の「パスワードを忘れた場合」からの再設定を利用できず、サポートへの依頼が必要になるため、事前に対応手順をご確認ください。

設計面で配慮している点

RapidTableのパスキー認証は、FIDO2（WebAuthn）の標準仕様に基づき、ブラウザ標準のWeb Authentication APIを利用しています。

• 公開鍵のみを登録：RapidTableに登録するのは、公開鍵などの検証用情報です。秘密鍵や生体情報は、RapidTableには送信されません。
• 本人確認を必須化：登録時、サインイン時のいずれも、端末での本人確認（生体認証やPINなど）を必須としています。
• サービスのドメインにひも付け：パスキーはRapidTableのドメインに対して登録されるため、前述のとおり、異なるドメインの偽サイトには端末が署名を返しません。

無理なく導入するための進め方

パスキーの導入は、利用者の環境や運用に合わせて段階的に進めると、混乱を抑えやすくなります。次の3つのステップが、進め方の一例です。

ステップ1：管理者など、権限の大きいアカウントから始める

RapidTableの製品マニュアルでは、管理者アカウントには2要素認証またはパスキーを必須とするよう案内しています。影響範囲の大きいアカウントから始めると、効果を得やすくなります。

ステップ2：複数の端末を登録し、サインインを確認する

普段使うパソコンに加えて、スマートフォンなど、もう1台の端末も登録します。登録後はいったんサインアウトし、実際にパスキーでサインインできることを確認します。

ステップ3：運用が安定したら、パスワードレス設定を検討する

パスキーでのサインインに問題がないことを確認できたら、パスワードレス設定を検討します。あわせて、端末の紛失・故障時の連絡先と手順、登録端末の定期的な見直しを、運用ルールとして定めておくと安心です。

他の認証まわりの機能と組み合わせる

パスキーのほかにも、次の認証まわりの機能を組み合わせて、多層的な対策を講じられます。

まとめ

フィッシングの報告件数は過去最多となり、手口もワンタイムパスワードを突破するリアルタイム型へと巧妙化しています。こうした状況を受けて、金融分野を中心に、パスキーのような「フィッシング耐性のある認証」を求める動きが広がっています。

パスキーは万能ではなく、脆弱性対応や権限管理といった基本的な対策と組み合わせて考える必要があります。それでも、利用者が秘密の値を入力しない仕組みは、パスワードを前提とした認証の弱点を補う有力な選択肢の一つです。

RapidTableでは、「セキュリティ設定」画面から、利用者自身がパスキーを登録し、必要に応じてパスワードレス設定まで進められます。管理者アカウントから段階的に始め、複数の端末を登録して運用ルールを整えることで、サインイン時の負担を抑えながら、認証まわりの安全性を高めることが期待できます。

設定方法や運用についてのご相談は、RapidTable公式サイトからお問い合わせください。

※ 記載の内容は、本記事公開時点の製品仕様に基づいています。利用可能な認証方式は、提供形態（SaaS／専有環境）およびご契約の内容によって異なります。機能の詳細は製品マニュアルをご確認ください。