Cisco Duoの認証機能を試してみた① 〜Duo Mobile編〜

こんにちは。こにしです。 今回から新たに「Cisco Duoの認証方式」をテーマとした、全4回の連載シリーズをスタートします。本連載では、日々進化するサイバー攻撃からシステムとデータを守るために、これからの時代に求められる最新の認証技術を実際のデモを交えてご紹介していきます。

連載の全体像は以下の通りです。

  • 第一回:Duo Mobileを利用したスマートフォンベースの認証方式について(本記事)
  • 第二回: パスキーを利用した認証方式について
  • 第三回: リスクベース認証について
  • 第四回: パスワードレス認証について

第一回のテーマは、「Duo Mobileを利用したスマートフォンベースの認証方式」です。Cisco Duoが提供する認証方式の中から、スマートフォン(Duo Mobileアプリ)を利用した代表的な3つの方式を取り上げます。

  • Duo Push: ワンタップで承認できる、利便性に優れた認証方式
  • Verified Duo Push(確認コード方式): 確認コードの目視と手動入力によって、MFA疲労攻撃への耐性を強化した認証方式
  • Duo Proximity Verification(近接認証方式): 利便性は保ちつつ、Bluetoothを活用してAiTM攻撃に対する強固なフィッシング耐性を実現する認証方式

本記事では、まず多要素認証(MFA)の基礎と、MFAを狙う代表的な攻撃手法である「MFA疲労攻撃」や「AiTM攻撃」について解説します。そのうえで、それぞれの認証方式の仕組みや特長を比較し、どのような環境や用途に適しているのかをご紹介します。

※なお、Cisco Duoの全体的な概要や、サポートされている多様な認証方式の一覧については、過去のブログ記事にて紹介していますので、基礎的な内容を振り返りたい方はぜひそちらも併せてご参照ください。

※本記事で紹介する検証環境やCisco Duoの仕様、設定画面のUI等の情報は執筆時点(2026年7月)のものであり、今後の製品アップデートによって変更される可能性がありますので、あらかじめご了承ください。

それでは、さっそく認証の基礎から見ていきましょう。

 

なぜ今、「多要素認証(MFA)」が必要なのか?

日々の業務において、私たちは当たり前のように「ID」と「パスワード」を入力してシステムを利用しています。しかし、この従来のパスワード認証だけでは、現代のサイバー攻撃から組織を守り切ることは困難になっています。ここでは、その背景と多要素認証(MFA)の基本について解説します。

パスワード認証の限界とシングルサインオン(SSO)の落とし穴

現在、多くの企業がクラウドサービスやシングルサインオン(SSO)技術を導入しています。SSOは、異なる複数のアプリケーションに対するログインを統合し、ユーザーが覚えるべき認証情報の数を減らすことで「パスワード疲労(Password fatigue)」を軽減するテクノロジーです。

しかし、SSOはユーザーにとって非常に便利である反面、新たなセキュリティ上の課題も生み出しています。それは、「ユーザーのプライマリパスワードが万が一侵害された場合、攻撃者は複数のリソースへ一気にアクセスできてしまう」 というリスクです。機密情報がクラウド上のサービスに移行していく中で、単一のパスワードに依存する環境は、セキュリティ上の大きなリスクを抱えていると言わざるを得ません。

多要素認証(MFA)とは何か?

こうしたパスワード認証の限界を克服し、アクセスを保護するために不可欠なのが 「多要素認証(MFA:Multi-Factor Authentication)」 です。

MFAとは、本人確認を行う際に、性質の異なる以下の3つの要素のうち2つ以上を組み合わせて認証を行う仕組みです。

  1. 知っていること(知識要素) ユーザー本人だけが知っている情報です。従来の「パスワード」や「PINコード」がこれに該当します。
  2. 持っているもの(所有要素) ユーザー本人が物理的に所持しているデバイスです。Cisco Duoを利用する場合、リクエストを受信する「Duo Mobileスマートフォンアプリ」、専用の「ハードウェアトークン」、WebAuthnに準拠した「FIDO2セキュリティキー」、あるいは「SMS/電話の受信端末」などがこれに該当します。
  3. 備わっているもの(生体要素) ユーザー自身の身体的な特徴そのものです。認証に用いられる「指紋」や「顔(容貌)」がこれに該当します。Cisco Duoを利用する場合、デバイスに内蔵されたTouch ID、Face ID、Windows Hello、Android Biometricsといった生体認証機能(プラットフォーム認証器)を介して、これらを安全に検証します。
MFAの基礎
 

MFA導入がもたらす「最初の防御壁」

Cisco DuoのようなMFAプラットフォームを導入すると、任意のIDストア(Cisco DuoやMicrosoft Entra ID、Active Directoryなど)に対するプライマリ認証(パスワード入力)が成功した後に、セカンダリ認証(スマートフォン等での承認)が要求されます。

これにより、ユーザーはTouch IDやWindows Hello、あるいはDuo Mobileアプリに届いたプッシュ通知を承認するといったシンプルな操作(ジェスチャー)だけで、2つの認証要素を用いたセキュアなログインを完了させることができます。

つまり、MFAを導入する最大の理由は 「たとえパスワードがフィッシングや使い回しによって攻撃者に漏洩したとしても、手元にあるスマートフォン(持っているもの)や指紋(備わっているもの)による承認がなければ、アカウントの乗っ取りを容易には許さない」 という強固な防御壁を築くことができる点にあります。

しかし、MFAを導入しさえすれば、どのような方式であっても安全が確保できるというわけではありません。認証方式ごとの技術的な仕組みやセキュリティ強度を考慮せずに導入してしまうと、MFAの仕様や人間の心理的な隙を突くサイバー攻撃によって、その効果が十分に得られなくなる可能性があります。次項では、標準的なMFAの運用において直面しやすい、具体的な2つの脅威(サイバー攻撃手法)について解説します。

 

MFAも進化を迫られる:現代の高度なサイバー攻撃とは?

前項で述べたように、MFAを導入することでセキュリティは飛躍的に向上します。しかし、それで完璧というわけではありません。防御壁が高くなれば、攻撃者もそれを乗り越えるために手口を巧妙化させます。

単に「スマートフォンに届いた通知を承認するだけ」という標準的なMFAの弱点を突く、現代の2つの高度な脅威を見ていきましょう。

脅威1:MFA疲労攻撃(Push Fatigue)

MFA疲労攻撃(Push Fatigue) は、リアルタイムで通知を承認するというMFAの便利な仕組みを逆手に取った攻撃です。

攻撃者は何らかの手段(フィッシングや使い回されたパスワードのリストなど)でユーザーのパスワードを入手すると、システムに対して連続してログインを試みます。このとき、正規ユーザーのスマートフォンには、ログイン承認のプッシュ通知が繰り返し届くことになります。

この攻撃の狙いは、ユーザー側の不注意による誤操作、あるいは確認漏れや状況の誤認などを誘発することです。実務においては、例えば以下の2つのパターンが警戒すべき隙として挙げられます。

  • 不注意による誤操作: 業務中や移動中に突然鳴り止まない通知が届き、スマホを操作しようとした瞬間にうっかり「承認」ボタンをタップしてしまう不意のミス。
  • 確認漏れや状況の誤認: 1台の認証用デバイスをチーム内で共有している環境において、「自分自身のログイン操作ではないが、同じデバイスを共有している他のメンバーが今ログイン操作を行っているのだろう」と誤認し、接続元IPやログイン対象アプリケーションといったリクエストの詳細を確認しないまま承認ボタンをタップしてしまうケース。

結果として、システム側は「正しいパスワード」と「正規デバイスからの承認」が揃ったと判断するため、攻撃者によるなりすましアクセスを許してしまうことになります。

 
MFA疲労攻撃
 

脅威2:AiTM攻撃(中間者/フィッシング攻撃)

MFA疲労攻撃よりも技術的に複雑で対策が困難な脅威が、AiTM(Adversary-in-the-Middle:中間者)攻撃と呼ばれる手口です。

この攻撃では、攻撃者は本物そっくりに偽造したログイン画面(プロキシサイト)を用意し、巧妙なメールなどでユーザーをそこへ誘導します。ユーザーが偽サイトだと気づかずにIDとパスワードを入力すると、攻撃者のシステムは裏側でリアルタイムに本物のシステムへとその情報を中継してログインを試みます。

本物のシステムからユーザーのスマートフォンにMFAの認証が求められ、ユーザーがそれに答えて承認してしまうと、本物のシステムは「ログイン成功」とみなし、アクセス権(セッション)を発行します。攻撃者はこのセッションを奪取し、正規ユーザーになりすましてシステムへアクセスしてしまいます。

通信の途中に攻撃者が入り込んで中継しているため、標準的なプッシュ通知のMFAでは、ユーザー自身が「自分が今ログインしようとしているのは偽サイトである」と気づかない限り、このクラスの攻撃を防ぐことはできません。

AiTM攻撃
 

それでは、私たちはどのようにして利便性を保ちながら、これらの脅威に対抗していけばよいのでしょうか。次項では、Cisco Duoの機能を使って、システムに合わせて段階的に防御力を高めていく「解決策」を、実際のデモを交えてご紹介します。

 

Duo Mobileを利用した認証方式

多要素認証(MFA)を導入する際によく採用されるのが、スマートフォンを利用した認証方式です。ユーザーがログインを試みると、スマートフォンへ通知や確認コードが送信され、本人による承認を行うことで認証を完了します。

Cisco Duoでは、スマートフォン向けアプリ「Duo Mobile」を活用したさまざまな認証方式を提供しています。本記事では、その中から以下の3つの認証方式を取り上げます。

  • Duo Push: プッシュ通知を利用したシンプルな認証方式
  • Verified Duo Push(確認コード方式): 確認コードの入力により、MFA疲労攻撃への耐性を強化した認証方式
  • Duo Proximity Verification(近接認証方式): BluetoothとOrigin Bindingを活用し、高いフィッシング耐性を実現する認証方式

それでは、これら3つの認証方式について「Duo Push」、「Verified Duo Push」、「Duo Proximity Verification」の順に見ていきましょう。

Duo Push:利便性と基本セキュリティを兼ね備えた「Push通知方式」

まずは、Duo Mobileを利用した最も基本的な認証方式である 「Duo Push」 です。

  • 概要: この方式では、ユーザーがログインを試みると、リアルタイムにDuo Mobileアプリへプッシュ通知が送られます。非常に手軽でユーザー負担が少ない方式です。
  • 特長:
    • 暗号化されたセキュアな通信経路: 携帯キャリアの回線網(公衆電話網)を経由するSMSや電話(コールバック)は、経路上の盗聴や、電話番号を乗っ取る「SIMスワップ」といった特有の脆弱性を抱えています。 これに対し、「Duo Push」は公衆電話網に依存せず、インターネット回線(IPネットワーク)とアプリによるエンドツーエンドの暗号化通信を採用しています。通知の送信先も電話番号ではなく、事前に登録された特定の物理デバイス(Duo Mobileアプリ)に直接紐づいているため、通信の傍受やSIMスワップによる横取りを防ぐことができます。
    • リアルタイムな動的認証(再利用の防止): ハードウェアトークンなどで生成した静的なパスコード(OTP)をユーザーが入力する方式とは異なり、ログインのたびに一度きりの動的なリクエストが生成されます。入力したコードを盗み見られたり、過去の認証情報を後から再利用されたりするリスクを低減できます。
    • 不正報告機能: また、万が一、身に覚えのないログイン通知が届いた場合は、ユーザーがアプリ上から「不正(Fraud)」として報告し、管理者に即座にアラートを上げる機能も備わっています。
  • 課題: 前項で触れた通り、ユーザーが画面を見ずにうっかり承認してしまう「MFA疲労攻撃」や、偽サイトがリアルタイムに認証を中継する「AiTM(フィッシングプロキシ)攻撃」に対しては、ユーザー自身の注意に依存してしまうという限界があります。

Duo Pushの説明

 

Verified Duo Push:MFA疲労攻撃を防ぐ「確認コード方式」

「Duo Push」の手軽さは魅力ですが、「ユーザーがうっかりミスで承認してしまう」という脆弱性を克服するために設計されたのが 「Verified Duo Push(確認コード方式)」 です。

  • 概要: この方式では、PCのログイン画面上に3桁〜6桁の確認コードが表示されます。ユーザーは、スマートフォンのDuo Mobileアプリにそのコードを手動で入力して初めて、承認を完了させることができます。
  • 特長: ユーザーは「PCのログイン画面」と「スマートフォン」の両方を同時に目視し、能動的なアクションを取る必要があります。そのため、攻撃者が遠隔から大量のプッシュ通知を送りつけるMFA疲労攻撃を行っても、ユーザーは「攻撃者のPCログイン画面上の確認コード」を知らないため、決して承認を通過させることができません。
  • 課題: もしユーザー自身が「AiTM攻撃者が用意した偽のログイン画面」にアクセスしており、そこに表示されたコードをスマホに入力してしまった場合、認証を突破される恐れがあります。

検証済みDuoPushの説明

 

Duo Proximity Verification:強固なフィッシング耐性を備えた「近接認証方式」

MFA疲労攻撃に加え、AiTM攻撃によるリアルタイムのセッション乗っ取りすらも防ぎたい。その優れたセキュリティ強度と、コード入力の手間を省く利便性を融合させたのが 「Duo Proximity Verification(近接認証方式)」 です。

  • 概要: スマートフォンへの「プッシュ通知」を利用した承認プロセスをベースとしつつ、PC側にインストールした「Duo Desktop」アプリと、スマートフォンの「Duo Mobile」の間でBluetooth Low Energy(BLE)通信を行い、プッシュ通知を承認する前に「アクセスしているPCとスマートフォンが物理的に近くにあること」を自動で検証する、より厳密な方式です。
  • 特長(MFA疲労とAiTM攻撃への対策):
    • 遠隔からのMFA疲労攻撃の無効化: 「アクセスしているPC」と「認証用のスマートフォン」がBluetoothの圏内にない限りプッシュ通知を承認できないため、遠隔からのMFA疲労攻撃を物理的に防止(または遮断)します。
    • Origin Binding(Verifier name binding)によるプロキシサイトのブロック: Duo Desktopを通じて「今ログインが行われているサイトが正規のものか」を暗号学的に紐付けて検証(Origin Binding)します。これにより、ユーザーがAiTM攻撃の偽サイトでログインを試みても、裏側の検証が失敗し認証自体が自動的にブロックされます。
    • より高度なAiTM攻撃の阻止: 万が一、攻撃者が自身の環境にDuo Desktopをインストールし、正規のサイトに直接アクセスすることで前述のOrigin Bindingをクリアしようとした場合でも、攻撃者のPCとユーザーの手元にあるスマートフォン(Duo Mobile)は物理的に近接していなければBluetoothの検証が失敗し、認証を完全に阻止します。この二段構えの検証により、強固な「フィッシング耐性」を実現しています。
近接認証の説明
 

Duo Mobileを利用した認証方式の設定と検証

ここからは、実際にCisco Duoを利用して前述の3つの認証方式をどのように設定し、ユーザー体験がどう変わるのかをご紹介します。

前提条件

今回の検証環境では、以下の前提条件が満たされているものとします。

  • 管理者側: Duo Admin Panel(管理画面)にて、対象となるアプリケーションの保護設定やユーザー登録が完了していること。
  • 利用者側: スマートフォンにDuo Mobileアプリがインストールされ、デバイスのエンロール(登録)が完了していること。また、システムへのログイン用パスワード設定が済んでいること。
  • 近接認証の要件: 「Duo Proximity Verification」のテストを行う場合、PC側にDuo Desktopアプリがインストールされており、PCとスマートフォンの両方でBluetoothが有効化されていること。
  • 端末OS・アプリの要件: 「Duo Push」や「Duo Proximity Verification」を利用するには、PC側のOS(Windows/macOS)および「Duo Desktop」アプリ、スマートフォン側のOS(iOS/Android)および「Duo Mobile」アプリが、それぞれ指定のバージョン要件を満たしていること。 ※最新のサポート要件や詳細については、以下の公式ドキュメントをご参照ください。

管理画面での認証方式の設定方法

Cisco Duoの認証方式は、Duo Admin Panel(管理画面)の「Policies(ポリシー)」メニューから柔軟に設定・変更することが可能です。それぞれの方式を有効にするための基本的な設定手順は以下の通りです。

  1. Duo Pushの設定: 「Authentication methods」ポリシー内の「Second-factor authentication (2FA)」セクションで、「Duo Mobile Push」を有効にします。標準のプッシュ通知のみを利用するため、「Require a Verified Duo Push」のチェックは外しておきます。
  2. Verified Duo Pushの設定: 上記の設定で「Duo Mobile Push」を有効にした上で、「Require a Verified Duo Push」のチェックを入れます。展開されたメニューから「Require users to enter a verification code」を選択します。確認コードの長さは3〜6桁の間で指定可能です。
  3. Duo Proximity Verificationの設定: 「Duo Desktop & device health」ポリシーを開き、WindowsおよびmacOSに対して「Require Duo Desktop」を選択して、PC側でのDuo Desktopアプリの稼働を必須とします。その後、「Authentication methods」ポリシー内の「Require a Verified Duo Push」オプションにて、「Require proximity verification with Bluetooth」を選択します。

Duo Policy画面

 

検証シナリオ:ユーザーのログイン体験

設定したポリシーが実際のログイン画面でどのように動作するか、順を見ていきましょう。

(1) Duo Pushの検証

STEP1:PCのブラウザで保護対象のアプリケーションにアクセスすると、Cisco DuoのSSO画面に遷移するためIDとパスワードを入力します。

Duo Push画面1

Duo Push画面2

 

STEP2:認証方式を選択する画面が表示されますので、「Duo Push」を選択します。

Duo Push画面3

 

STEP3:PC画面上には「スマートフォンにPush通知が送信された」旨、表示されます。

Duo Push画面4

 

STEP4:その後、すぐに事前登録済みの手元のスマートフォン(Duo Mobile)にプッシュ通知が届くため、「承認」ボタンを押下します。

Duo Push画面5

 

STEP5:スマートフォン側に「承認済み」画面が表示されます。

Duo Push画像14

 

STEP6:PC画面にも「成功です!」画面が表示されログインが完了します。ブラウザは自動的に対象のアプリケーションの画面に遷移します。

Duo Push画面7

 

(2) Verified Duo Pushの検証

STEP1からSTEP2は通常の「Duo Push」と同じ手順となります。

STEP3:PC画面上には「817 326」のような確認コードが表示されます。

Duo Push画面8

 

STEP4:その後、すぐに事前登録済みの手元のスマートフォン(Duo Mobile)にコード入力を求める通知が届くため、PC画面に表示されている確認コード(数字)を入力します。

Duo Push画面9

 

STEP5:スマートフォンに入力した確認コードがPC側に表示された数値と一致している場合、スマートフォン側に「承認済み」画面が表示されます。

Duo Push画像14

 

STEP6:PC画面にも「成功です!」画面が表示されログインが完了します。ブラウザは自動的に対象のアプリケーションの画面に遷移します。

Duo Push画面7

 

(3) Duo Proximity Verificationの検証

STEP1からSTEP2は通常の「Duo Push」と基本的には同じ手順となります。ただし、STEP1実施のタイミングでブラウザから「このデバイス上の他のアプリとサービスにアクセスする」ことを求める通知が表示されるため、「許可」を押下します。

Duo Push画面16

 

STEP3:PC画面上には「スマートフォンにPush通知が送信された」旨、表示されます。

Duo Push画面10

 

STEP4:その後、すぐに事前登録済みの手元のスマートフォン(Duo Mobile)にプッシュ通知が届きます。このタイミングでPC側のDuo Desktopとスマートフォン側のDuo MobileがBluetoothで自動的に通信し、物理的な近接を検証します。

Duo Push画面11

 

STEP5:本人が正規のPCの前にいること(PCとスマートフォンの物理的な近接)が確認されると、「承認」ボタンが選択できるようになるため、ボタンを押下します。

Duo Push画面12

 

STEP6:スマートフォン側に「承認済み」画面が表示されます。

Duo Push画像14

 

STEP7:PC画面にも「成功です!」画面が表示されログインが完了します。ブラウザは自動的に対象のアプリケーションの画面に遷移します。

Duo Push画面7

 

Duo Mobileを利用した3つの認証方式の利用パターンを考える

ここまでに、Duo Mobileを利用した3つの認証方式をご紹介してきました。シンプルなプッシュ通知から始まり、確認コードを用いたMFA疲労攻撃の防御、さらにはBluetoothを活用して高度なフィッシング(AiTM攻撃)までブロックする防御など、脅威の進化に合わせた選択肢が用意されています。

では、実際の組織においては、どの方式を選択するのが現実的なのでしょうか。

セキュリティ強度、特に高いフィッシング耐性を最優先に評価すれば、「Duo Proximity Verification」を全面的に採用するのが合理的なアプローチに見えます。しかし、日々の業務やインフラ運用という実務的な側面を考慮すると、すべてをこの方式に一本化するのは少し慎重になったほうがよいかもしれません。

「Duo Proximity Verification」は確認コードの手動入力を省くことができるため、ユーザーのログインの摩擦を増やすことはありません。しかし、アクセス元PCへのDuo Desktopアプリの導入や、双方のデバイスにおけるBluetoothの有効化といった、技術的な前提条件が必要になります。これを組織内のあらゆるシステム、特に従業員の私物デバイス(BYOD)や未管理端末、あるいは一時的なゲストアクセスにまで一律に義務付けてしまうと、ログインできないユーザーの業務を阻害したり、ITヘルプデスクのサポート負荷や運用コストが跳ね上がったりする懸念があるからです。

そこで、セキュリティの理想論だけを追うのではなく、現実の運用バランスを考慮した使い分けを、考えてみましょう。

組織全体に一律のルールを押し付けるのではなく、システムの重要度や直面するリスク、そしてユーザーの環境に合わせて適材適所で使い分ける。ここでは、Cisco Duoのポリシーエンジンを活かした、ハイブリッドな設計パターンを一例としてご紹介します。

認証方式の比較

まずは今回ご紹介した3つの方式について、防御できる脅威、ユーザー体験、前提条件、導入のしやすさ、運用のしやすさ(ヘルプデスク業務)の観点から整理してみましょう。

比較項目 Duo Push Verified Duo Push Duo Proximity Verification 
防御できる脅威 パスワード漏洩による不正アクセス パスワード漏洩による不正アクセス、MFA疲労攻撃 パスワード漏洩による不正アクセス、MFA疲労攻撃、AiTM攻撃(フィッシング耐性)
ユーザー体験 (利便性) 手軽(ワンタップ承認) やや手間がかかる(コードの目視と手動入力) 手軽(Bluetoothによる検証後、ワンタップ承認)
前提条件
  • スマホ:Duo Mobile
  • スマホ:Duo Mobile
  • スマホ:Duo Mobile
  • PC:Duo Desktop
  • 両デバイスのBluetooth有効化
導入のしやすさ 容易(スマホアプリのみで完結) 比較的容易(要件を満たせばポリシー変更のみ) ややハードルが高い(PCへのアプリ配布が必要)
運用のしやすさ 容易 容易 中程度(Bluetooth接続やPC環境起因のヘルプデスク対応が想定される)

3つの方式を組み合わせたハイブリッド運用の例

単一の認証方式を組織全体に一律で適用するのではなく、状況や要件に応じて複数の方式を使い分けるポリシー設計が、現実的なセキュリティ運用において効果的です。Cisco Duoのポリシーエンジンを活用すれば、アプリケーションやユーザーグループごとに異なる認証要件を柔軟に設定することができます。ここでは、対象システムが保有する資産の価値や、ユーザーがログインするアクセス環境、そして管理者側の運用リソースに応じた使い分けの設計パターンを一例としてご紹介します。

  1. 低リスク環境における日常業務の保護:組織内ネットワークからのアクセスに限定されているシステムや、会社が支給・管理する専用端末からのアクセスに限定されているシステムなど、すでにベースラインとなる安全対策が機能している環境では、利便性を最優先にします。全社ポータルやスケジュール管理といった一般的な業務システムへのログインにおいて、ユーザーに負担をかけない「Duo Push」を適用します。これにより、日々の業務効率を落とすことなく、基本的な多要素認証の要件をクリアします。
  2. 高リスク資産へのアクセスおよび特権アカウントの保護:インフラ全体を制御する特権アカウント(ネットワーク管理者やクラウドアドミン)や、最高機密データを扱うシステムやアカウントに対しては、AiTM攻撃を防ぐための強力な対策が必要です。このような高リスクな対象へのアクセスに対しては、「Duo Proximity Verification」を適用します。Bluetooth通信を用いた物理的な近接検証と、Origin Bindingによる正規ドメインの検証を必須とすることで、人間の判断に頼らない強固な防御壁を構成します。
  3. デバイス制限や運用リソースの制約に対する補完:本来は組織全体に「Duo Proximity Verification」を適用してフィッシング対策を施したいものの、一部のクライアント端末(LinuxやChromeOS、あるいはBYOD端末など)でBluetoothが利用できない、またはエージェントを導入できないといった「デバイス側の前提条件」の課題が生じる場合があります。また、Bluetoothの接続トラブルやエージェント展開に伴う「ITヘルプデスクの運用サポート負荷」に十分な人員を割けない、といった管理者側の制約がある組織も存在します。 このような前提条件や運用リソースの課題がある環境に対しては、セカンドベストの強固な代替ポリシーとして「Verified Duo Push」を割り当てます。PC側への追加ソフトの配布や設定変更をすることなく、すでに導入済みのスマートフォンアプリのみで完結するため、導入・サポートコストを抑えられます。さらに、ログイン画面のコードを能動的に手動入力させることで、MFA疲労攻撃を確実に防止します。

一律の厳しいルールを組織全体に押し付けるのではなく、リスクの大きさと現場の制約(デバイス要件や管理部門のサポート体制)に応じて、複数の認証方式を使い分ける。このハイブリッドなアプローチこそが、ユーザーの生産性を維持しながら組織の資産を現実的に保護するための重要なポイントとなります。

【コラム:Duo Push の戦略的活用】
単体ではフィッシング耐性を持たない「Duo Push」ですが、以下の運用アプローチと組み合わせることで効果的に機能します。          

  • リスクベース認証との連携: 普段のログインには「Duo Push」を許容し、異常(リスク)を検知したときだけ、自動で「Verified Duo Push」や「Duo Proximity Verification」へ動的にステップアップさせる設計です。
  • 段階的な移行プロセス(ユーザーの操作習熟): 将来的な「Duo Proximity Verification」への移行を見据え、まずは最もシンプルな「Duo Push」を展開してスマートフォンでの承認操作に慣れてもらう、移行期のファーストステップとしての活用です。

 

まとめと次回予告

最後に本記事のまとめと次回予告です。

まとめ

本記事では、単純なパスワード認証の限界から出発し、多要素認証(MFA)を導入する重要性と、さらにそれを突破しようとする高度なサイバー攻撃(MFA疲労攻撃やAiTM攻撃など)の脅威について解説しました。

そして、それらの脅威に対抗するための具体的な解決策として、スマートフォンベースで利用できる3つの認証方式をご紹介しました。

  • 基本となる防御壁を築き、ユーザーの利便性を高める 「Duo Push」
  • 確認コードの目視と手動入力によってMFA疲労攻撃を防ぐ 「Verified Duo Push(確認コード方式)」
  • 利便性を保ちつつ、Bluetooth近接確認等を活用しAiTM攻撃をブロックする強固なフィッシング耐性を備えた 「Duo Proximity Verification(近接認証方式)」

セキュリティ対策は、強固にすればするほど利便性が損なわれ、ユーザーの不満や運用コストの増加を招くというジレンマを抱えがちです。しかし、システムの重要度やユーザーの環境、そして管理者側の運用体制に合わせてこれらの方式を「適材適所」で使い分けることで、強固なセキュリティとユーザーの業務生産性を維持しながら、導入コストや日々の運用負荷とのバランスを両立させることが可能になります。

次回予告:パスキーを利用した認証方式について

さて、第一回ではスマートフォン(Duo Mobileアプリ)をベースとした認証方式の進化に焦点を当ててきました。しかし、ここまで読んでいただいた方の中には、以下のような疑問を持たれた方もいらっしゃるのではないでしょうか。

  • 「そもそもスマートフォンを業務で使えない、あるいは使いたくないユーザーには、どうやって強固なMFAを提供すればいいのか?」
  • 「PCに備わっている生体認証(指紋や顔)や、専用のセキュリティキーを使って、フィッシング耐性のある認証を実現できないか?」

そこで次回、第二回のテーマは 「パスキーを利用した認証方式について」 です。

PCなどのデバイス自体に組み込まれたプラットフォームオーセンティケーター(AppleのTouch IDやFace ID、Windows Helloなど)や、USB等で接続する専用のFIDO2セキュリティキー(ローミングオーセンティケーター)を活用する強固な認証の仕組みについて解説します。さらに、スマートフォンをパスキーとしてPCのログインに活用する「クロスデバイス認証」についてもご紹介します。

いかにして強固なフィッシング耐性認証を、よりスムーズなユーザー体験で実現するのか。次回の記事もぜひご期待ください!

(※なお、本連載の第三回および第四回では、ユーザーの状況に応じて認証の壁を動的に変える「リスクベース認証」と、パスワード入力そのものをなくす「パスワードレス認証」へとステップアップしていく予定です。第三回のリスクベース認証では、今回ご紹介した「Duo Push」と「Duo Proximity Verification」を状況に応じて自動で使い分ける適応型ポリシー制御の仕組みをご紹介します。また、第四回のパスワードレス認証は、次回紹介するパスキーだけでなく、今回ご紹介した「Verified Duo Push」や「Duo Proximity Verification(近接認証)」でも利用可能です。そちらもどうぞお楽しみに!)

×
タイトルとURLをコピーしました