M365アカウントに対するAiTM攻撃

「5月の主な攻撃キャンペーン」でも触れておりますが、M365アカウント乗っ取りに関する調査依頼が急増しております。そこで、CSIRTがM365/Entra IDアカウント侵害対応・予防設計に利用することを想定した、AiTM攻撃の技術説明と具体的対策を説明します。

1. AiTM攻撃とは

AiTMはAdversary-in-the-Middle phishingの略で、攻撃者がユーザーとMicrosoft認証基盤の間にリバースプロキシ型の中継基盤（攻撃Webサイト）を置き、認証情報・MFA応答・認証済みセッションを奪取する攻撃のことです。

2. AiTM攻撃の本質

M365アカウントに対するAiTM攻撃の本質は、パスワードだけでなく、MFA完了後に発行される認証済みセッションを奪うことです。

従来型フィッシングでは、攻撃者はユーザーIDとパスワードを窃取し、その後に自分でログインを試みます。従来型フィッシングではMFAが有効であれば攻撃被害を食い止めることができます。一方、AiTMでは、ユーザーが実際にMicrosoftの正規認証基盤に対してMFAを完了する過程を、攻撃者がリアルタイムで中継するため、攻撃者はMFA済みのセッションCookieやトークンを取得しすることができます。攻撃者はこれらを利用することで、MFAを再実施せずにExchange Online、SharePoint、OneDrive、Teams等へアクセスできます。

Microsoftは、AiTMフィッシング攻撃では攻撃者がユーザーと認証サービスの間に入り、認証プロセスを中継することで、MFAを満たしたセッションを悪用できると説明しています。また、Microsoft Entra IDのトークン保護関連ドキュメントでは、Defender XDRやEntra ID Protectionで観測される代表的な検知として、Stolen session cookie was used、Possible AiTM phishing attempt、Anomalous Token、Attacker in the Middle、Unfamiliar sign-in properties が挙げられています。

3. 技術的な攻撃フロー

3.1 攻撃全体像

典型的なM365 AiTM攻撃は、以下の流れで進行します。

攻撃者がM365ログイン画面を模倣したフィッシングURLを送付する。この時、別に侵害済みのM365アカウントを利用して作成したフィッシングURLを含んだOneNoteメモを攻撃者が作成し、それをM365の共有機能でメールアドレスに対して共有するケースが見られる。M365の共有招待メールは正式のものである。
被害者がM365の共有招待メール経由でフィッシングURLにアクセスする。被害者は不審なメールとは気がつかない。
フィッシングサイトはMicrosoftの正規ログイン画面を背後で開き、被害者の入力をリアルタイム中継する
被害者がID、パスワード、MFAを入力・承認する
Microsoft側では正規ユーザーがMFAを完了したように見える
攻撃者のプロキシが、MFA後に発行されたセッションCookieや認証トークンを取得する
攻撃者は取得済みCookie/トークンを自分のブラウザや自動化ツールに注入し、M365へアクセスする
メール探索、転送ルール作成、OAuthアプリ同意、SharePoint/OneDriveデータ取得、BEC準備などを行う

重要なのは、被害者は本物のMicrosoft認証基盤に対してログインしている場合があるという点です。単なる偽ログイン画面ではなく、攻撃者が中継者として存在するため、ユーザー体験上は「普通にログインできた」ように見えます。

Proofpointは、Microsoft 365を狙うAiTM攻撃の典型的流れとして、フィッシング誘導、認証情報の取得、セッションCookie窃取、MFAバイパスを挙げています。

3.2 リバースプロキシ型AiTMの仕組み

攻撃者は、たとえば以下のような構成を用います。

被害者のブラウザは攻撃者のフィッシングドメインに接続します。攻撃者のサーバは、裏側で login.microsoftonline.com や関連するMicrosoft認証エンドポイントに接続します。被害者が入力したID、パスワード、MFA情報、MFA承認後のレスポンスは、攻撃者のプロキシを経由します。

このとき攻撃者は、以下を取得できます。

窃取対象	説明	攻撃上の価値
ユーザーID	UPN、メールアドレス	再攻撃、横展開、BEC標的選定
パスワード	ユーザが入力した資格情報	他サービスへの使い回し確認
MFA応答	OTP、プッシュ承認、番号一致等の一部	リアルタイム中継によるMFA突破
セッションCookie	承認済みWebセッション	MFA再要求なしのM365アクセス
アクセストークン	APIやサービスアクセス利用	Graph API、Exchante、SharePoint等へのアクセス
リフレッシュトークン	アクセストークン再発行に利用	長期的なアクセス維持

MFAを突破しているように見えますが、厳密には「MFAを破った」のではなく、被害者本人にMFAを完了させ、その結果として発行された認証済み状態を盗んでいるという理解が正確です。

3.3 なぜMFAが効かないのか

通常のMFAは、次のような前提に依存します。

　１　ユーザが正規サイトにログインする
　２　↓
　３　ID・パスワードを入力する
　４　↓
　５　MFAを完了する
　６　↓
　７　ユーザーのブラウザに認証済みセッションが付与される

AiTMでは、この「ユーザーのブラウザに認証済みセッションが付与される」前後を攻撃者が中継・観測しています。したがって、MFAが正常に完了した直後のCookieやトークンが攻撃者に渡ります。

特に問題となるのは、以下のMFA方式です。

MFA方式	AiTM耐性	理由
SMS OTP	低い	OTPをリアルタイム中継可能
音声通話	低い	承認・コードを中継可能
TOTP	低い〜中	有効時間内に中継可能
Push通知	低い〜中	ユーザーが承認すれば突破可能
Number matching	中	疲労攻撃には強いが、AiTM中継には完全ではない
FIDO2 / Passkey	高い	オリジンバインディングにより偽ドメインでは認証困難
Windows Hello for Business	高い	デバイス・鍵ベースの認証
証明書ベース認証	高い	秘密鍵・証明書とデバイスに依存

CSIRTとして重要なのは、MFA有効＝AiTM耐性あり、ではないという点です。AiTM対策では、「MFAを有効化しているか」ではなく、フィッシング耐性のある認証方式か、セッションやトークンがデバイスに束縛されているか、条件付きアクセスで異常な再利用を止められるかを見る必要があります。

4. OAuth Device Code Phishingとの関係

近年、M365アカウントに対する攻撃では、リバースプロキシ型AiTMに加えて、OAuth Device Code Flowの悪用も増えています。これは厳密には典型的なリバースプロキシ型AiTMとは異なりますが、結果としてMFAを迂回したように見えるアカウント侵害につながります。

Device Code Flowは、本来、キーボード入力が難しいデバイスでMicrosoftログインを行うための正規OAuthフローです。攻撃者はユーザーに「Microsoftの正規ページにアクセスして、このコードを入力してください」と誘導します。ユーザーは正規Microsoftページで認証・MFAを完了しますが、その認可対象は攻撃者が開始したデバイスセッションです。その結果、攻撃者側にOAuthトークンが渡ります。

2026年には、Kali365のようなMicrosoft 365を狙うフィッシング・サービスが、OAuth Device Code Flowを悪用し、ユーザーにMicrosoftの正規認証ページでコードを入力させることでOAuthトークンを取得する手法が報じられています。また、ProofpointもMicrosoft 365アカウント乗っ取りにおけるOAuth device code authorization processの悪用増加を報告しています。

CSIRT観点では、以下の2系統を分けて扱うべきです。

種別	代表的手口	侵害されるもの	主な対策
リバースプロキシ型AiTM	偽ログインURLでMicrosoft認証を中継	Cookie、トークン、認証情報	フィッシング耐性MFA、Token Protection、条件付きアクセス
Device Code Phishing	正規Microsoft device loginページでコード入力を誘導	OAuthトークン	Device code flow制限、OAuth監査、アプリ同意制御

5. 攻撃後に発生しやすい行動

M365アカウントをAiTMで奪取された後、攻撃者は単にメールを読むだけではありません。典型的には以下のような行動を取ります。

5.1 Exchange Online上の行動

攻撃行動	目的
メールボックス検索	請求書、送金、取引先、認証情報、VPN情報の探索
Inbox rule作成	警告メールや返信を隠蔽
メール転送設定	外部メールボックスへの継続的情報流出
既存スレッドへの返信	BEC、送金先変更依頼、取引先詐欺
OAuthアプリ同意	Graph API経由の永続アクセス
eDiscovery的な大量検索	組織内情報の効率的収集

5.2 SharePoint / OneDrive上の行動

攻撃行動	目的
最近使ったファイルの閲覧	機密文書探索
共有リンク作成	外部持ち出し
大量ダウンロード	情報窃取
Teams添付ファイルアクセス	プロジェクト情報や顧客情報の取得

5.3 Entra ID / OAuth上の行動

攻撃行動	目的
不審なEnterprise Application追加	永続アクセス
Delegated permission取得	Mail.Read、Files.Read.All等の悪用
MFA登録情報変更	アカウント奪取の維持
パスワード変更	正規ユーザー排除
追加認証方法登録	再侵入経路確保

6. ログ上の観測ポイント

CSIRTが調査する場合、主に以下のログを確認します。

6.1 Entra ID Sign-in Logs

確認すべき主な項目です。

項目	見るべき点
UserPrincipalName	侵害疑いユーザー
IPAddress	普段と異なる国・ASN・VPN・ホスティング事業者
Location	ユーザー業務地域との乖離
UserAgent	不自然なブラウザ、通常端末との差異
ClientAppUsed	Office 365 Exchange Online、Microsoft Graph、SharePoint Online等
AppDisplayName	Office 365 Exchange Online、Microsoft Graph、SharePoint Online等
ResourceDisplayName	アクセス先リソース
AuthenticationRequirement	singleFactor / multiFactor
ConditionalAccessStatus	success / failure / notApplied
DeviceDetail	managed/compliant/registeredの有無
RiskDetail / RiskLevel	Entra ID Protectionのリスク
Status	成功・失敗・追加認証要求

AiTMで特に重要なのは、MFA成功済みのサインインが、通常とは異なるIP・国・デバイス・User-Agentから発生しているケースです。攻撃者はセッションCookieを使うため、ログ上は失敗ログが少なく、成功ログ中心になることがあります。

6.2 Entra ID Protection

Entra ID Protectionでは、以下の検知が重要です。

検知名	意味
Attacker in the Middle	AiTMの疑い
Anomalous Token	トークン利用の異常
Unfamiliar sign-in properties	普段と異なるサインイン特性
Atypical travel	不自然な地理的移動
Anonymous IP address	Tor/VPN/匿名化基盤
Malicious IP address	既知悪性IP
Suspicious inbox manipulation rules	メールボックス操作の疑い

Microsoftのドキュメントでも、Entra ID Protectionの関連リスク検知として Anomalous Token、Attacker in the Middle、Unfamiliar sign-in properties が挙げられています。

6.3 Microsoft Defender XDR / Defender for Cloud Apps

Defender XDRやDefender for Cloud Appsがある場合、以下のアラートが重要です。

アラート	見るべき意味
Stolen session cookie was used	セッションCookie再利用の疑い
Possible AiTM phishing attempt	AiTMフィッシングの疑い
Suspicious inbox rule	不審なメールルール
Impossible travel activity	不自然な移動
Activity from anonymous proxy	匿名化基盤からの活動
Mass download by a single user	大量ダウンロード
Unusual file access	通常と異なるファイルアクセス

Microsoftは、Defender XDRにおける関連アラートとして Stolen session cookie was used と Possible AiTM phishing attempt を明記しています。

6.4 Unified Audit Log

M365 Unified Audit Logでは、以下を重点確認します。

Exchange Online

Operation	調査観点
MailItemsAccessed	攻撃者によるメール閲覧
Send	不正送信
New-InboxRule	隠蔽・転送ルール
Set-InboxRule	既存ルール改変
Set-Mailbox	転送設定、監査設定変更
UpdateInboxRules	ルール変更
SoftDelete / HardDelete / MoveToDeletedItems	証跡隠蔽、メール削除
Add-MailboxPermission	権限追加
Add-RecipientPermission	送信権限追加

SharePoint / OneDrive

Operation	調査観点
FileAccessed	ファイル閲覧
FileDownloaded	ファイルダウンロード
SharingSet	共有設定
AnonymousLinkCreated	匿名リンク作成
SecureLinkCreated	共有リンク作成
AddedToSecureLink	共有先追加
FileSyncDownloadedFull	同期クライアント経由の取得

Entra ID / OAuth

Operation	調査観点
Consent to application	不審アプリ同意
Add service principal	サービスプリンシパル追加
Add app role assignment to service principal	権限付与
Update application	アプリ設定変更
Add registered owner to application	アプリ所有者追加
User registered security info	認証方法登録
User changed default security info	既定MFA変更

7. 検知ロジック例

7.1 AiTM疑いの基本相関

CSIRT/SOCで検知する場合、単一ログではなく相関が重要です。

　１　条件A：ユーザが普段使わない国・ASN・IPからMFA成功
　２　AND
　３　条件B：DeviceDetailがunmanageまたはunkown
　４　AND
　５　条件C：直後にExchange Online / SharePoint / Microsoft Graphへアクセス
　６　AND
　７　Inbox rule作成、外部転送、ファイル大量ダウンロード、OAuth同意のいずれか

この組み合わせは、AiTM後のアカウント悪用として優先度高で扱うべきです。

7.2 KQL例：普段と異なる国からのMFA成功

これは初期スクリーニング用です。実運用ではユーザーの出張・VPN・VDI・プロキシを考慮して除外条件を入れます。

7.3 KQL例：管理外デバイスからのMFA成功後のExchangeアクセス

7.4 KQL例：不審Inbox Rule作成

攻撃者は、セキュリティ通知、取引先返信、MFA通知、送金確認メールを隠すためにルールを作成することがあります。

7.5 KQL例：OAuthアプリ同意の確認

特に Mail.Read、Mail.ReadWrite、Files.Read.All、offline_access、User.Read、Calendars.Read などが付与されていないか確認します。

8. 初動対応手順

AiTM疑いを検知した場合、CSIRTはパスワードリセットだけで終わらせてはいけません。盗まれたセッションCookieやリフレッシュトークンが残っている可能性があるためです。

8.1 優先対応

優先度	対応	目的
1	ユーザーのサインインリスク確認	侵害範囲の把握
2	対象ユーザーのセッション失効	盗難トークン無効化
3	パスワードリセット	資格情報悪用停止
4	MFA登録情報の確認・削除	攻撃者登録MFAの排除
5	Inbox rule / forwarding確認	メール隠蔽・流出停止
6	OAuth同意アプリ確認	永続アクセス排除
7	Unified Audit Log調査	被害範囲確定
8	取引先送信・BEC確認	二次被害防止

8.2 セッション・トークン失効

Entra ID / Microsoft Graph / PowerShell等で以下を実施します。

または、管理ポータルから対象ユーザーの「Revoke sessions」を実行します。

注意点として、パスワード変更だけでは既存セッション・トークンが即時にすべて無効化されるとは限りません。AiTM疑いでは、セッション失効を明示的に行うべきです。

8.3 Exchange Onlineの確認

確認すべき不審点は以下です。
　１　外部ドメインへのForwardingSmtpAddress
　２　RedirectTo / /ForwardToを含むInbox rule
　３　件名に”invoice"、"payment"、"MFA"、"security"、"Teams"、"Microsoft"等を含むメールを隠すルール
　４　DeleteMessage=True
　５　MarkAsRead=True
　６　RSS Subscriptions、Archive等への移動
　７　不審な代理アクセう権限

8.4 OAuthアプリ同意の確認

Entra管理センターで以下を確認します。

または、Graph PowerShellでサービスプリンシパル・アプリロール割当を確認します。

見るべきポイントは以下です。

項目	不審判断
Publisher verified	未確認Publisherは高リスク
Consent type	ユーザー同意か管理者同意か
Permissions	Mail.Read、Files.Read.All、offline_access等
Created date	侵害時刻付近
Sign-in activity	侵害ユーザー・不審IPとの関連
App name	Adobe、DocuSign、SharePoint等を装った名称

不審アプリがあれば、同意取り消し、サービスプリンシパル削除、関連トークン失効を実施します。

9. 恒久対策

9.1 フィッシング耐性MFAの導入

最も重要な対策は、フィッシング耐性のある認証方式を特権ユーザーから段階導入することです。

優先順位は以下です。

優先度	対象	推奨方式
1	Global Admin、Privileged Role Admin、Exchange Admin等	FIDO2 / Passkey、Windows Hello for Business、証明書ベース認証
2	経理、役員秘書、購買、営業管理	FIDO2 / Passkey、WHfB
3	全ユーザー	Number matching + 条件付きアクセス + リスクベース制御
4	外部委託・共有端末利用者	デバイス準拠条件、セッション制御

Microsoft Entra IDでは、Authentication Strengthを使って、フィッシング耐性MFAを条件付きアクセスで要求できます。MicrosoftのToken Protectionドキュメントでも、トークン窃取対策は防御多層化の一部として利用すべきとされています。

9.2 Conditional Accessの具体設計

管理者向け
- 対象
  ・Global Administrator
  ・Privileged Role Administrator
  ・Exhange Administrator
  ・Security Administrator
  ・Conditional Access Administrator
- 条件
  ・全てのクラウドアプリ
  ・全ての場所
  ・レガシー認証はブロック
  ・管理外デバイスからのアクセスはブロックまたは強力なMFA要求
- 制御
  ・Phising-resistant MFAを要求
  ・Compliant deviceを要求
  ・Sign-in risk medium以上はブロックまたはパスワード変更
  ・User risk highはブロック　
一般ユーザー向け
- 対象
  ・全ユーザー
- 条件
  ・Exchange Online
  ・SharePoint Online
  ・Microsoft Teams
  ・Microdoft Graph
- 制御
  ・MFAを要求
  ・Compliant deviceを要求
  ・管理外デバイスではセッション制限
  ・高リスク国、匿名IP、不審ASNをブロックまたは追加認証
  ・サインイン頻度を適切に制御
例外管理
・Break-glass accountは除外。ただし、強固な監視を付与
・レガシーアプリ例外は期限付きで承認制
・例外ユーザーは定期レビュー対象

9.3 Token Protectionの利用

Token Protectionは、トークンをデバイスに暗号学的に結び付けることで、盗まれたトークンの再利用を困難にする考え方です。Microsoftは、Token Protectionをトークン窃取に対する防御多層化の一部として位置付けています。

導入時の考慮点は以下です。

項目	注意点
対象ユーザー	まず管理者・高リスク部門から
対象端末	Entra参加済み、Hybrid Join、Intune管理端末を優先
対象アプリ	対応状況を確認
例外	非対応OS、VDI、モバイル、外部委託端末
運用	レポートモードで影響確認後に強制

Token Protectionは単独で全てのAiTMを防ぐものではありませんが、盗まれたトークンを攻撃者端末で再利用する攻撃パスを弱体化できます。

9.4 レガシー認証の完全ブロック

Basic認証、古いIMAP/POP/SMTP AUTH、古いOfficeクライアントなどは、MFAや条件付きアクセスの制御が効きにくい場合があります。

対応方針：
　１　Exhange OnlineのBasic Authenticationを無効化
　２　POP/IMAP/AMTP AUTHの利用棚卸し
　３　SMTO AUTHは必要なメールボックスのみに限定
　４　レガシー認証仕様ログを定期確認
　５　条件付きアクセスでOther Client / legacy authenticationをブロック

9.5 OAuthアプリ同意の制御

AiTM後の永続化としてOAuthアプリ同意が悪用されるため、以下を推奨します。
　１　一般ユーザーによるアプリ同意を禁止または制限
　２　Admin Consent workflowを有効化
　３　Publisher verifiedでないアプリを制限
　４　高権限Permissionの承認をセキュリティレビュー対象化
　５　Enterprise Applicationsの定期棚卸し
　６　Mail.Reas / File.Read.All / Offline_accessの付与を重点監査

9.6 Device Code Flowの制御

Device Code Phishing対策として、Device Code Flowの利用を制限・監査します。
　１　Device code flowを利用する正規業務、端末を棚卸し
　２　条件付きアクセスで認証フローを制限
　３　不要なdevice code authenticationをブロック
　４　device loginページへの誘導をユーザー教育に含める
　５　「Microsoftの正規ページだから安全」という誤解を排除

Kali365のようなPhaaSでは、Microsoftの正規OAuth 2.0 device code loginを悪用し、ユーザーにコード入力を促すことでトークンを得る手口が報告されています。

9.7 メールセキュリティ対策

M365 Defender for Office 365等で以下を実施します。
　１　Safe Linksの有効化
　２　Safe Attachmentの有効化
　３　URLクリック時の再評価
　４　QRコードフィッシング対策
　５　外部送信者バナー
　６　DMARK/DKIM/SPF整備
　７　なりすまし検知
　８　ブランド偽装検知
　９　高リスクURLクリックのアラート化

AiTMではURLが短時間で変化したり、正規サービス経由のリダイレクトが使われたりします。そのため、受信時判定だけではなく、クリック時判定が重要です。

10. CSIRT向け調査チェックリスト

10.1 初動確認
　　１　対象ユーザー
　　２　初回不審サインイン時刻
　　３　不審IP / 国 / ASN
　　４　使用アプリ
　　５　MFA成功の有無
　　６　条件付きアクセス適用結果
　　７　デバイス管理状態
　　８　User-Agent
　　９　Entra ID Protectionリスク
　１０　Defender XDRアラート

10.2 メールボックス調査
　　１　Inbox rule作成・変更
　　２　外部転送設定
　　３　代理権限
　　４　SendAs / SendOnBehalf
　　５　不審送信
　　６　削除済みメール
　　７　MailItemsAccessed
　　８　取引先との既存スレッド悪用

10.3 データアクセス調査
　　１　SharePoint FileAccessed
　　２　OneDrive FileDownloaded
　　３　Teams添付ファイルアクセス
　　４　匿名リンク作成
　　５　共有リンク作成
　　６　大量ダウンロード

10.4 永続化確認
　　１　MFA登録情報の追加・変更
　　２　不審OAuthアプリ
　　３　Enterprise Application追加
　　４　App role assignment
　　５　Service principal追加
　　６　管理ロール付与
　　７　メール転送・ルール

10.5 封じ込め
　　１　Revoke sessions実施
　　２　パスワードリセット
　　３　MFA再登録
　　４　不審Inbox rule削除
　　５　外部転送解除
　　６　不審OAuth同意取り消し
　　７　不審アプリ削除
　　８　条件付きアクセス強化
　　９　取引先への注意喚起判断

11. CSIRTとしての判断ポイント

AiTM疑いでは、以下のように判断するのが実務的です。

高リスクとして即時封じ込めすべき条件
１　MFA成功後、通常と異なる国・ASNからExchange Onlineへアクセス
２　管理外デバイスからのMFA成功
３　Defender XDRで Stolen session cookie was used
４　Entra ID Protectionで Attacker in the Middle / Anomalous Token
５　直後にInbox ruleや外部転送が作成
６　OAuthアプリ同意が侵害時刻付近に発生
７　SharePoint/OneDriveで大量ダウンロード
８　経理・役員・管理者アカウントで発生
パスワードリセットだけでは不十分な理由
１　既存セッションCookieが残る可能性がある
２　リフレッシュトークンが有効な可能性がある
３　OAuthアプリ同意によりパスワード非依存のアクセスが残る可能性がある
４　Inbox ruleや外部転送により情報流出が継続する可能性がある
５　攻撃者がMFA方式を追加している可能性があ

したがって、AiTM対応では必ず以下をセットで実施します。
　Revoke sessions
　　+ Password reset
　　+ MFA method review
　　+ Inbox rule / forwarding review
　　+ OAuth consent review
　　+ Unified Audit Log investigation

12. 推奨する優先順位

実装優先度は以下です。

優先度	対策	理由
1	管理者・高リスク部門にフィッシング耐性MFA	最も実効性が高い
2	セッション失効手順の標準化	侵害時対応で必須
3	Inbox rule / forwarding / OAuth同意の監視	AiTM後の典型行動を捕捉
4	条件付きアクセスで管理外デバイス制限	トークン再利用リスク低減
5	Token Protectionの段階導入	盗難トークン再利用対策
6	Device Code Flow制限	新しいPhaaS系手口への対策
7	Safe Links / URLクリック時判定	フィッシング入口対策
8	ユーザー教育	正規Microsoftページ悪用型への注意喚起

13.まとめ

M365アカウントに対するAiTM攻撃は、単なるパスワード窃取ではなく、MFA完了後の認証済み状態を盗む攻撃です。そのため、「MFAを導入しているから安全」とは判断できません。

CSIRTとしては、次の観点で対応する必要があります。

1. AiTMはMFA済みセッションを奪う攻撃である
2. 侵害ログは失敗ログではなく成功ログとして現れることが多い
3. 調査ではSign-in Logs、Entra ID Protection、Defender XDR、Unified Audit Logを相関する
4. 初動ではパスワード変更だけでなく、セッション失効とOAuth同意確認が必須
5. 恒久対策はフィッシング耐性MFA、条件付きアクセス、Token Protection、OAuth制御、Device Code Flow制限を組み合わせる

最も重要な設計原則は、「ユーザーがMFAを完了しても、攻撃者がその結果を再利用できない状態を作る」ことです。これには、FIDO2/PasskeyやWindows Hello for Businessなどのフィッシング耐性認証、管理端末・準拠端末の強制、Token Protection、セッション制御、OAuth同意制御を組み合わせた多層防御が必要です。

ISSコラム

column by iss