IT用語集 2023/10/07

リスクベース認証とは？わかりやすく10分で解説

リスクベース認証（RBA：Risk-Based Authentication）は、ログイン時の状況を評価し、リスクが高い場面だけ追加認証や遮断を行う認証制御です。普段どおりの端末・場所・時間帯なら手間を増やさず、普段と異なる端末や不自然なアクセスなら認証を一段強めます。固定の認証手順を毎回求める方式より、ユーザーエクスペリエンスと不正ログイン対策を両立しやすい一方、誤判定、救済手順、説明責任まで含めて設計しないと運用が不安定になります。

リスクベース認証とは

リスクベース認証は、IDとパスワードだけでログイン可否を決めるのではなく、端末、IPアドレス、推定位置、時間帯、アクセス頻度、失敗回数、過去の利用傾向などの状況情報を使ってリスクを見積もり、認証の要求水準を変える考え方です。低リスクなら追加操作なしで通し、中リスクなら追加認証を求め、高リスクなら拒否や管理者確認へ切り替えます。

位置付けとしては、多要素認証の代替ではありません。むしろ、どの場面でMFAやFIDO2、ワンタイムパスワードを要求するかを決める制御として使う方が実務に合います。

一般的な認証との違い

一般的な認証	ID・パスワードや固定の追加認証を毎回同じ条件で求めます。手順が明確な反面、利用状況の違いを反映しにくくなります。
リスクベース認証	ログイン時の状況を見て、追加認証の有無や強度を出し分けます。普段どおりの利用では負荷を抑え、不自然なアクセスでは確認を厚くできます。

固定ルールだけの認証では、認証情報が漏えいした後の見分けが付きにくくなります。リスクベース認証は、認証情報そのものに加えて「そのログインが普段どおりか」を見るため、フィッシング詐欺や認証情報の使い回しによる不正ログインに対して一段深い判定を入れやすくなります。

仕組み

1. ログイン要求を受け付ける

利用者がID・パスワードを入力する、あるいは既存セッションから再認証を行うと、まずログイン要求が発生します。

2. 状況情報を収集する

収集対象は製品や実装で異なりますが、代表例は次のとおりです。

IPアドレスやASの属性
推定位置と移動の不自然さ
端末情報、ブラウザ、OS、登録済み端末かどうか
時間帯、失敗回数、普段の利用傾向とのずれ
自動化された操作を疑う兆候

3. リスクを評価する

単一要素だけで断定すると誤判定が増えます。たとえば、IPアドレスだけではモバイル回線やVPNで変動しやすく、位置情報だけでは出張や拠点移動を区別しきれません。実運用では、複数の要素を重ねて総合評価し、閾値を超えたときに追加認証へ進めます。

4. 対応を出し分ける

低リスク	追加認証なしで許可する、または最小限の確認で通します。
中リスク	MFA、プッシュ承認、ワンタイムパスワード、FIDO2などを追加で求めます。
高リスク	アクセス拒否、管理者確認、パスワード変更要求、セッション遮断などへ進めます。

MFAとの関係

リスクベース認証とMFAは競合する考え方ではありません。MFAは「複数の要素で本人確認する方式」、リスクベース認証は「どの場面で追加確認を要求するかを決める制御」です。実務では、リスクベース認証が判断を行い、その結果としてMFAやFIDO2を要求する構成が一般的です。

また、すべての利用者へ毎回同じ強度のMFAを求める構成では、利用負荷が高くなり、例外運用や回避行動が増えることがあります。リスクベース認証を組み合わせると、毎回同じ負荷を課すのではなく、不自然な場面へ認証強化を集中させやすくなります。

向くケースと向かないケース

向くケース

社外からのアクセスが多く、利用場所や端末が固定されにくい
クラウドサービスやSaaSの利用が多く、認証が業務の起点になっている
重要操作だけ認証を一段強めたい
毎回固定の追加認証では利用負荷が高すぎる

向かないケース

利用パターンが安定せず、正常利用と異常利用の差が付きにくい
収集できるシグナルが少なく、評価精度を上げにくい
救済手順や問い合わせ窓口を用意できず、誤判定時の復旧が難しい
厳格な固定ルールで毎回同じ認証手順を求める方が適している

向くかどうかは、製品の有無だけで決まりません。利用環境、収集できる情報、ヘルプデスク体制、規程整備まで含めて判断します。

メリット

不正ログインへの対応力を上げやすい

普段と異なる端末や不自然な移動を伴うログインのように、認証情報だけでは見抜きにくい兆候を追加判断に使えます。認証情報が漏えいした後の対処としても有効です。

利用負荷を抑えやすい

低リスクの利用者へ毎回追加操作を求めないため、定常利用での負担を抑えやすくなります。ログイン頻度が高い業務では、この差が定着率に影響します。

重要操作へ段階的な制御を掛けやすい

ログインだけでなく、送金、管理者権限の変更、機密データのダウンロードなど、影響が大きい操作に限定して追加認証を掛ける設計も取りやすくなります。

注意点

誤判定は避け切れない

新しい端末への切り替え、出張、VPN利用、通信環境の変化で正当な利用者が高リスク判定されることがあります。例外時の救済手順を持たないと、利用者を止めるだけの仕組みになりやすくなります。

運用コストがかかる

シグナルの収集、ルール設計、ログ確認、問い合わせ対応、閾値の調整が発生します。導入だけで終わる方式ではなく、継続的に調整する前提で扱います。

プライバシーと説明責任の整理が要る

位置や行動に関わる情報を扱う場合は、取得目的、保存期間、利用範囲、社内規程、利用者への説明を整理しておきます。どこまで取得し、何に使うのかが曖昧なままでは運用しづらくなります。

導入時に決めておく項目

評価シグナル	IP、推定位置、端末、時間帯、失敗回数など、何を使ってリスクを判定するかを定義します。
閾値	低・中・高をどう分けるか、どの条件で追加認証や拒否へ進めるかを決めます。
追加認証手段	MFA、FIDO2、ワンタイムパスワードなど、リスクレベルごとの本人確認方法を決めます。
救済手順	端末変更、出張、紛失時にどう本人確認し、どう復旧させるかを用意します。
監査と見直し	誤判定率、追加認証率、拒否率、問い合わせ件数を見て、閾値やルールを調整します。

まとめ

リスクベース認証は、ログイン時の状況を評価し、必要な場面だけ追加認証や遮断を行う認証制御です。MFAの代替ではなく、MFAやFIDO2をどの場面で要求するかを決める制御として捉えると位置付けがはっきりします。導入では、評価シグナル、閾値、追加認証の手段、救済手順、監査項目まで含めて設計し、運用しながら調整していく形が実務に合います。