あなたのMFAは、思っているMFAではない

この10年近く、多要素認証（MFA）は、アカウント乗っ取りのリスクをどう下げたかと問われたとき、セキュリティリーダーが真っ先に挙げる対策でした。コンプライアンスのチェックリストのほぼすべてに載り、サイバー保険の質問票にもほぼ必ず登場します。それには十分な理由があります。パスワードログインに第2の要素を加えたことで、認証情報を狙う攻撃の大部分を封じることができ、早期に導入した組織は、侵害されるアカウントの減少という成果を得てきました。

しかし、こうした信頼はすでに時代遅れになっています。多くのセキュリティチームは、その変化を十分に認識できていません。取締役会や監査人に報告されるMFAの導入率は、どの方式で要件を満たしたのかをほとんど区別していません。プッシュ通知もハードウェアセキュリティキーも、同じコンプライアンスレポートでは「MFA有効」に数えられます。SMSで送られるワンタイムコードも同様です。ところが、攻撃者に破られやすいかどうかという尺度で見ると、これらは大きく離れた位置にあります。2022年のUberの侵害、MGM Resortsのインシデント、そしてヘルプデスクの侵害が起点となった企業への侵入事例が増え続けていますが、いずれも根本原因は共通しています。MFAは導入されていたにもかかわらず破られました。導入されていた方式が、標的型の攻撃者に耐えられるようには作られていなかったからです。

プッシュ認証とOTPが破られる場面

多くの組織で最初に導入されたのはプッシュ通知型MFAでした。最大の理由は手間が最も少ないことです。ユーザーが覚えるものも入力するものもなく、IT部門は午後のうちに全社で有効化できました。ところが、その導入しやすさこそが、破られやすさの原因になりました。攻撃者は、高度な手口で何かを盗む必要がないことに気づいたのです。必要なのは盗んだパスワードだけです。あとは同じ承認リクエストを相手のスマートフォンに何度も送り続けます。ときには数時間に及び、ユーザーがうんざりするか、疲れるか、混乱して承認をタップするまで続けます。セキュリティチームは、これをプッシュ疲れ（MFA爆撃）と呼んでいます。この手口は成功することが多く、技術的には「有効」なMFAを攻撃者が突破する最も一般的な手段の一つになっています。

OTPの問題は、プッシュ疲れよりも単純で、たちが悪いものです。OTPは単なるコードであり、コードは手に入れられてしまいます。攻撃者が携帯電話会社を説得し、被害者の電話番号を自分の管理するSIMに移させることがあります。この詐欺は、暗号資産ウォレットや企業のメールアカウントから、長年ひそかに資産を奪ってきました。しかも最近では、そこまでの手間さえ必要なくなっています。リバースプロキシ型のツールを使ったフィッシングキットは、OTPをリアルタイムで横取りできます。被害者は、一見普通のログインページにパスワードとコードを入力します。しかしそのページは、入力内容をセッションごと、攻撃者に代わって本物のサイトへ密かに転送しているのです。

この2つの失敗パターンには、共通する設計上の欠陥があります。ログインを承認する人と、ログインを要求するシステムが、同一の正規の接続先と通信していることを、認証方式が確認していないのです。攻撃者が突いているのはまさにこの性質であり、新しい標準規格が塞ぐために作られたのも、この点です。

Ashish Mishra

欠陥を塞ぐ性質

FIDO2やパスキーに対して、フィッシングサイトがなぜ通用しないのか。その答えは巧妙さではなく、数学にあります。パスキーには、そもそも盗めるコードがありません。登録時に作られるのは、特定のウェブサイトに恒久的に紐づけられた暗号鍵のペアです。見た目がどれほど本物らしくても、そっくりのドメインはそのウェブサイトではありません。ブラウザは何よりも先にオリジン（接続先）を確認し、一致しないと判断した時点でログインの試行は終わります。ユーザーがだまされて、承認すべきでないものを承認してしまうことはありません。

このオリジン束縛こそが要点です。その意味は正確に理解しておく必要があります。ベンダーは多様な製品を「フィッシング耐性あり」として売り出していますが、そのすべてが基準を満たしているわけではないからです。フォールバックとしてOTPを許可したままのハードウェアキーは、そのフォールバックが利用できる限り、耐性があるとは言えません。共有端末や管理されていない端末に安全でない形で保存されたパスキーは、欠陥を狭めはしても、完全には塞げません。対策の強度は、最も強い部分ではなく、認証経路の全体で決まります。

誰も認めたがらない、移行の難しさ

フィッシング耐性のあるMFAの技術的根拠がこれほど強いのなら、なぜ多くの組織がいまだにプッシュ認証とOTPを使い続けているのか。自然な疑問です。正直に言えば、理由は無知ではありません。現場の負担です。そこから目をそらしても、移行計画には役立ちません。

古いオンプレミスのシステムは、WebAuthnを想定して作られていません。いまも広く使われている一部のSaaSも同様です。そのため、誰かが補完的な統制を後付けしたり、回避策を探したりすることになります。多くの場合、短期間で全面的に置き換えるのは現実的ではないからです。ハードウェアキーも無償ではありません。ユーザーあたりの費用は控えめでも、大規模な従業員数に掛ければ、すぐに大きな金額になります。しかもプッシュ通知と違い、キーを紛失したり破損したりすれば、実際のサポート対応が発生します。そして、誰もが口に出したがらない点があります。スマートフォンで2秒で承認をタップすることに慣れた従業員は、新しい手順でかばんから物理キーを取り出して差し込むことになれば、気づいて不満を言うでしょう。だからといって、移行する価値がないわけではありません。金曜日までに切り替えるよう求めるメモではなく、展開計画が必要だということです。

あえて小さく始める

この分野で実際に成果を上げている組織は、全従業員を一夜にして切り替えてはいません。リスクが集中していて、変更への抵抗が最も小さい領域から始めています。管理者アカウント、IDプロバイダーへのアクセス、他のユーザーの認証情報をリセットできる権限を持つ人々です。こうしたアカウントは、一つ侵害すれば下流のすべてが開くため、攻撃者が真っ先に狙います。同時に、技術に明るい少数のユーザーなら、大きな混乱なく新しいワークフローに対応できるアカウントでもあります。

次に続くのは、財務部門とエンジニアリング部門、そして機密性の高いシステムに近いその他のグループです。新しい標準にまだ対応できないレガシーアプリケーションには、恒久的な例外を認めません。当面は条件付きアクセスポリシーを適用し、例外を終了する期限を明確に設定します。SMSベースのOTPにも同じ扱いが必要ですが、こちらはより早い対応が求められます。現在も一般的に使われている方式のなかで、弱点が最もよく知られ、最も積極的に悪用されているのがSMS OTPです。だからこそ、フォールバックとして無期限に残すのではなく、廃止期限を設けるべきです。

攻撃者は、多くの組織が何年も前に導入したMFAを前提に、すでに手口を作り替えています。移行を正当化するために、さらに大きなインシデントが起きるのを待つのは戦略ではありません。自社は次の標的にならないという賭けです。まずは率直な監査から始めてください。どのアカウントでMFAが有効かではなく、それぞれのアカウントをどの方式が守っているかを確認することです。