前言

2026 年 9 月下旬以降，國內也陸續報導了因網路攻擊而造成的損害。

其入侵途徑包含利用網路設備漏洞、釣魚郵件等，種類相當多樣。
此外，未來不僅要考慮使用者本身，還必須留意 AI 代理程式存取外部內容與服務時所產生的新型攻擊途徑。

資安對策不是一次建置就結束。
必須因應攻擊手法與服務的變化，持續檢視與更新。

我自己也從去年開始，一邊持續進行與發表關於 Passkey 與零信任的驗證，一邊將其導入自己的環境。

我也有一些過去在讀書會中使用過的教材與部落格文章，因此藉此機會整理它們，按步驟介紹現在就應該著手的資安對策。

本文介紹的內容，都是我實際驗證過，並且將營運面也納入考量後採用的做法。

若本文能成為各位組織或個人重新檢視資訊資產保護措施的契機，我將不勝榮幸。

通知
我們已於 2026/9/26 舉辦了實際導入 Passkey、Break Glass 與 PIM 的讀書會。

本次讀書會使用的講義僅提供給參加者。

未來也考慮舉辦類似的讀書會。
若有興趣，歡迎與我聯繫討論。

Microsoft Entra ID 實作資安工作坊 in Tokyo
https://yonayona.connpass.com/event/396158/

自我介紹

若您不認識我，請參考以下投影片。
如果已經認識我，或對個人資訊沒有興趣，請直接跳到下一章！

Azure Travelers in 廣島之旅：不是計畫好的。回頭看才發現是一條路 by @carol0226

我在 2025 年度與資安相關的活動內容整理如下。

FY25 Microsoft Security 登壇與技術分享整理
https://qiita.com/carol0226/items/a1297091c0635f86d1ca

本文概要

我首先建議從導入具備抗釣魚能力的認證方式——Passkey 開始。
接著，再依序推進存取控制、特權管理、郵件、網路，以及偵測與應對等資安措施，以下將依我建議的順序逐一介紹。

• 1．具備抗釣魚能力的認證（Passkey）
• 2．存取控制（Conditional Access）
• 3．緊急存取（Break Glass）
• 4．最小權限（PIM）
• 5．認證流程保護（Device Code Flow）
• 6．郵件與協作保護（Safe Links / Safe Attachments）
• 7．網路零信任化（Global Secure Access）
• 8．偵測、調查與應對（Microsoft Defender）

上述項目中，第一章的 Passkey 不只推薦給組織管理者，也推薦給個人使用者。
請將所有認證逐步移轉為不使用密碼的方式（Passwordless），以提升安全性。

其他章節主要是針對組織管理者的內容，但即使不是管理者，也能從中加深資安知識。資安初學者也可以參考本文，利用測試用的 Microsoft Entra 環境來學習。

1. 具備抗釣魚能力的認證（Passkey）

首先最優先要做的，就是讓認證本身具備更強的抗釣魚能力。

密碼、SMS、一次性驗證碼等，都可能成為釣魚攻擊的目標；攻擊者會誘導使用者進入偽造的登入畫面，輸入認證資訊。

因此，我們要使用 Passkey。

Passkey 基於 FIDO 標準，使用公開金鑰密碼學進行認證。認證資訊會與已註冊的網站或應用程式綁定，因此即使攻擊者做出假網站，也無法像傳統釣魚那樣輕易騙取認證資訊，這正是它的優勢。

在 Microsoft Entra ID 中，Passkey（FIDO2）被定位為「抗釣魚認證」，而 FIDO2 安全金鑰則是滿足「具抗釣魚能力 MFA 強度」的其中一種認證方式。

因此本文將 Passkey 作為資安對策的第一步，從這裡開始。

不過，雖然大家常聽到「Passkey 很強」，但實際要導入時，往往會有這些疑問：

• 先要準備什麼
• 應該先從哪個帳號開始移轉到 Passkey
• 裝置綁定 Passkey 與同步 Passkey 要如何分工
• 不支援 Passkey 的服務該怎麼處理

……實務導入與移轉時，常會遇到這些問題。

本章將依據我自己協助企業導入 Passkey 的經驗，以及持續追蹤 Microsoft 活動與最新資訊的心得，依序介紹我推薦的 Passkey 導入方式。 ``

1-1. 取得 FIDO2 安全金鑰（實體 Passkey）

請準備符合 FIDO2 規範的安全金鑰。
最穩妥、最推薦的是 YubiKey。其他廠牌的 FIDO2 安全金鑰也可以，但不同產品支援的連接方式與功能不盡相同。若您不確定該選哪一款，而且是第一次導入，我會推薦 YubiKey。

YubiKey 也有多種型號，請參考我以下的文章來決定要選哪一款。

我最推薦的是 YubiKey Bio（指紋辨識型）。

YubiKey 上雖然有可觸碰的區域，但一般 YubiKey 的觸碰區並不是指紋感測器。FIDO2 的使用者驗證是透過 PIN 來完成。

相對地，YubiKey Bio 配備指紋感測器，可以用指紋進行使用者驗證。

YubiKey 彙整（含可用性驗證）
https://qiita.com/carol0226/items/1e28bdc3acc4c7814da2

如果要在 Apple Account 啟用實體安全金鑰保護
需要兩支 FIDO 安全金鑰。
由於 YubiKey Bio 價格較高，我認為採用「YubiKey Bio × 1、YubiKey 5C × 1」這類組合，成本較平衡。

除了 Apple Account 之外，也請確認各服務的需求，至少先準備一支實體 Passkey 會比較好。

關於裝置綁定 Passkey（Device-bound）與同步 Passkey（Synced）的差異，請參考以下文章。

Passkey 認證的現況－Microsoft Ignite 2025 解說
https://qiita.com/carol0226/items/bbd4db426d1145684550

1-2. 以四個優先順序導入 Passkey

接著，這裡說明 Passkey 的導入策略，分成 ①～④ 四個觀點。

① 認證基礎要以裝置綁定 Passkey 為主
② 將 Windows OS 與 Microsoft 服務改為無密碼
③ 也將 SaaS 服務改為 Passkey
④ 處理不支援 Passkey 的服務

① 認證基礎要以裝置綁定 Passkey 為主

與認證核心相關的 Microsoft Entra ID、Microsoft 帳號、Apple Account、Google 帳號，本文章建議使用 FIDO2 安全金鑰加以保護。

同步 Passkey 也是具備抗釣魚能力的強力認證方式，但對於作為認證基礎的帳號，我的做法是不只依賴同步 Passkey，也要準備像 FIDO2 安全金鑰這樣的裝置綁定 Passkey。

重點
同步 Passkey 也是具備抗釣魚能力的強力認證方式。

但對於作為認證基礎的帳號，不應只依賴會在裝置間同步的認證資訊，也建議同時準備像 FIDO2 安全金鑰這樣、與裝置綁定的認證方式。

特別是 Apple Account 與 Google Account，也可能被用來管理同步 Passkey 的基礎。

因此本文採取的做法是，先用 FIDO2 安全金鑰將這些「認證大本營」的帳號本身強力保護起來，再進一步享受同步 Passkey 的便利性。

以下 SBI 證券的文章，也提醒了保護 Apple 與 Google 帳號的重要性。

SBI 證券：請注意竊取 Google、Apple 等帳號資訊的釣魚詐騙
https://site1.sbisec.co.jp/ETGate/?_ControlID=WPLETmgR001Control&_PageID=WPLETmgR001Mdtl30&_ActionID=DefaultAID&_DataStoreID=DSWPLETmgR001Control&OutSide=on&getFlg=on&burl=search_home&cat1=home&cat2=info&dir=info&file=home_info261002_phishing.html

各認證基礎的保護方式

• 以 Passkey 保護 Microsoft Entra ID
  https://qiita.com/carol0226/items/8586291079d941f62f7b
• 以 Passkey 保護 Microsoft Account
  https://support.microsoft.com/ja-jp/security/sign-in-to-your-account-with-a-security-key?wt.mc_id=MVP_407731
• 以安全金鑰保護 Apple Account
  https://support.apple.com/ja-jp/guide/iphone/iph5acc5b28c/ios
  ※ Apple Account 的安全金鑰不是用來取代密碼，而是用於強化兩步驟驗證。
• 以 Passkey 保護 Google Account
  https://www.google.com/account/about/passkeys/

總結：① 認證基礎要以裝置綁定 Passkey 為主
在善用同步 Passkey 便利性的同時，也要用 FIDO2 安全金鑰把最核心的帳號保護好。

先守住「大本營」，再便利地使用同步 Passkey，這就是我的想法。

② 將 Windows OS 與 Microsoft 服務改為無密碼

在確實保護好認證基礎之後，接著也把日常使用的 Windows OS 與 Microsoft 服務改為 Passkey 化吧。

依照 Windows 的組態不同，可用的方法也不同，但可以透過下圖中的組合來將認證改為 Passkey 化。

重點
即使導入了 Passkey，也可能還殘留傳統密碼認證。

既然都導入 Passkey 了，就應該進一步思考如何避免回到較弱的認證方式。也就是說，不只是「新增 Passkey」，而是要朝向完全無密碼邁進。

Windows 的登入也能依照組態實現無密碼化。

• 非網域環境時（例如個人使用）
  使用前一章已改為 Passkey 的 Microsoft 帳號，搭配 Windows Hello 實現無密碼登入。
  Microsoft Support: Go passwordless in Windows
  https://support.microsoft.com/en-us/windows/security/go-passwordless-in-windows?wt.mc_id=MVP_407731
• Active Directory 網域環境時
  請參考以下我的文章。
  從網域內首次登入到完全無密碼營運（支援實體 PC 版）
  https://qiita.com/carol0226/items/bb985634fde0a5445310

參考
即使是未與 Entra ID 連線的 Windows 裝置，例如「非網域、個人裝置、Active Directory」等情境，也可以透過以下方式將 Entra ID 的認證做成接近 Passkey 的形式。

讓 Windows 裝置成為 Entra Passkey 的方法
https://qiita.com/carol0226/items/394d6a795be116853771

• Microsoft Entra Join 環境時
  請參考以下我的文章。
  使用 FIDO2 安全金鑰登入 Windows（Entra Join 篇）
  https://qiita.com/carol0226/items/3933199bfd512e31f060

另外，在 Microsoft Entra Join 環境中，也可以使用 Web Sign-in。

使用 Web Sign-in 後，可以將 Web 型認證方式用於 Windows 登入。例如也支援透過 Microsoft Authenticator 進行無密碼登入。

※ Web Sign-in 需要符合 Windows 版本、Microsoft Entra Join、網際網路連線等條件。此外，Microsoft Entra hybrid join / Active Directory 網域無法使用。詳細請參考以下官方資訊。

官方資訊：Windows Web 登入
https://learn.microsoft.com/ja-jp/windows/security/identity-protection/web-sign-in?wt.mc_id=MVP_407731

總結：② 將 Windows OS 與 Microsoft 服務改為無密碼
不要只做到新增 Passkey 就結束，而是從能做的地方開始，把環境逐步變成不使用密碼。

既然要導入 Passkey，我最推薦的方向就是朝向完全無密碼邁進。

③ 也將 SaaS 服務改為 Passkey

當 Microsoft 服務完成 Passkey 化後，下一步就是把平常使用的 SaaS 服務也改成 Passkey。

支援 Passkey 的服務已經越來越多了。如果您常用的服務支援 Passkey，建議從可行之處開始逐步切換。

注意
Microsoft Authenticator 的 Passkey，是用於 Microsoft Entra ID 的認證。

請注意，Microsoft Authenticator 並不能當作一般 SaaS 服務的「通用 Passkey 提供者」來儲存那些服務的 Passkey。

若要將 SaaS 服務改為 Passkey，請先確認該服務支援哪一種 Passkey 提供者。

Passkey 不僅受服務本身影響，也會因為你把 Passkey 存在哪個驗證器（Passkey 提供者）而改變使用體驗。

以下我的文章，實機驗證了「驗證器 × 裝置 × 服務」的各種組合。若您正在決定要把 Passkey 存到哪裡，可以參考這篇。

以實機驗證 Passkey 認證行為——驗證器 × 裝置 × 服務的組合實例集
https://qiita.com/carol0226/items/0367bb7b1bb9fd2413b8

總結：③ 也將 SaaS 服務改為 Passkey
不要只把 Microsoft 改成 Passkey，平常使用的 SaaS 服務也應該從支援者開始逐步切換成 Passkey。

同時也要確認服務與 Passkey 提供者之間的組合，這是重點。

④ 處理不支援 Passkey 的服務

很遺憾，並不是所有服務都支援 Passkey。

對於不支援 Passkey 的服務，可以善用 iCloud 鑰匙圈、Google Password Manager、Microsoft Password Manager 等密碼管理工具。

我建議不要自己想密碼並重複使用，而是使用密碼管理器替每個服務產生並管理不同、夠長且隨機的密碼。

另外，也可以使用第三方密碼管理器，例如：

• 1Password
• Bitwarden
• Keeper
• RoboForm
• PassLogic

重點
密碼管理器會集中管理大量認證資訊，因此密碼管理器本身的帳號也一定要妥善保護。

如果您使用的密碼管理器支援 Passkey，請務必也用 Passkey 好好保護該帳號本身。

企業也可以在組織內導入密碼管理器，來管理那些不支援 Passkey 服務的密碼。

以下我的文章介紹了將 RoboForm Business 與 Microsoft Entra ID 整合，並在組織中使用的架構。

RoboForm x Entra ID 建立 SSO 的筆記
https://qiita.com/carol0226/items/1aca8db77f1a22523134

即使是以無密碼化為目標的組織，剩下的密碼要如何管理，仍然是一項課題。

以下文章介紹了企業導入密碼管理器的思考方式。我也認同這樣的觀點。

以無密碼化為目標的組織，為何導入密碼管理器？🤔
https://qiita.com/akihiro_suto/items/386444bc6b67ec96c62b

需要密碼管理器嗎？以及為什麼是 Keeper？
https://qiita.com/ishiayaya/items/24f5f9d8fed28339671f

第一章：Passkey 的總結
大家覺得如何呢？

對於組織管理者而言，應該積極減少使用者使用密碼的情境，並盡可能讓服務移轉到具抗釣魚能力的認證方式。

而對於怎樣都會殘留密碼的服務，則應善用密碼管理器進行安全管理。

減少依賴密碼的場景，能有效降低釣魚與非預期操作所導致的認證資訊外洩風險。

2. 存取控制（Conditional Access）

在第一章中，我們已透過 Passkey 強化了認證本身的抗釣魚能力。

但只強化認證還不夠。即使成功認證為正確使用者，仍需要根據「從哪一台裝置」、「從哪個地點／網路」、「在什麼條件下」來決定是否允許存取。

因此，要使用 Microsoft Entra 的條件式存取（Conditional Access）。

重點
透過 Passkey 強力確認「這是本人」，再透過 Conditional Access 控制「在什麼條件下允許存取」。

不只是把認證變強，也要控制存取時的條件，這很重要。

我自己的環境中，也不只是用 Passkey，還搭配條件式存取一起使用。

若您是第一次設定條件式存取，可參考以下文章了解觀念與設定。

安全性預設值群組與條件式存取的首次使用
https://qiita.com/carol0226/items/51a70a561b78af567972

另外，也不必勉強一定要移轉到條件式存取。

使用安全性預設值群組，也能套用 Microsoft 提供的基本資安保護。

條件式存取雖然能提供更靈活、更細緻的存取控制，但也需要適當設計與營運。

若從安全性預設值群組移轉到條件式存取時，未能正確重建原本有效的保護，反而可能降低整體安全等級。

如果您對條件式存取的設計與營運沒有把握，也可以不勉強移轉，繼續使用安全性預設值群組。

接著，我們可以透過使用認證強度來要求具抗釣魚能力的認證，讓條件式存取進一步升級。

FIDO2 與 Entra 完全無密碼的條件式存取
https://qiita.com/carol0226/items/a3e914b3968cb7c38a63

此外，也可以限制組織中可使用的 FIDO2 安全金鑰。

企業有時會希望只讓員工使用經過公司驗證與核准的安全金鑰。Microsoft Entra 可利用 AAGUID 限制只能註冊特定的 FIDO2 安全金鑰。

以下文章介紹了設定方式。

在 Microsoft Entra 中只允許特定產品的 FIDO2 安全金鑰
https://qiita.com/carol0226/items/4d26717594c2b11126b4

第二章：存取控制的總結
大家覺得如何呢？

即使已透過 Passkey 強化認證本身，也不代表所有存取都會自動安全。

請善用條件式存取，根據所使用的裝置、地點、認證方式等條件，適切控制存取。

同時，也要依據組織需求，適當管理可使用的認證方式與 FIDO2 安全金鑰。

不要把導入 Passkey 當作結束；應該與條件式存取結合，逐步強化可存取的條件。

3. 緊急存取（Break Glass）

在透過條件式存取等方式強化存取控制的同時，也必須預先防範因設定錯誤或故障，導致無法用一般管理員帳號登入的情況。

因此，需要準備緊急存取帳號（Break Glass）。

這類帳號不會用於日常管理，而是作為一般管理員帳號無法處理緊急狀況時的備援管理管道。

重點
資安越強化，越不只是要「守得更牢」，也要「在萬一發生時，不會失去管理管道」。

雖然本文是這樣的介紹順序，但實際設定時，我建議在啟用條件式存取原則或導入下一章會介紹的 PIM 之前，先把 Break Glass 建立好。

關於 Break Glass 的概念與具體架構方式，請參考以下文章。

緊急存取管理帳號（Break Glass）入門：從基本架構到非典型額外架構完整解說
https://qiita.com/carol0226/items/bbd69bdc907a48f0e67f

第三章：緊急存取的總結
在強力保護平常使用的管理員帳號的同時，也要準備在萬一時可以回頭使用的管理管道。

Break Glass 不只是建立帳號就好。必須定期確認它在緊急時真的能用，並做好監控，確保一旦被使用就能立即察覺。

我的建議是，先準備好「可回復的手段」，再往前推進存取控制與管理員權限限制。

4. 最小權限（PIM）

透過 PIM（Privileged Identity Management），可以不讓一般管理員帳號長期持有特權，而是在需要時才把需要的權限啟用一段必要時間。

如此一來，即使管理員帳號遭到入侵，相較於永遠持有特權的情況，也能降低擴大損害的風險。

我自己在測試租戶中，也會在需要進行管理操作時透過 PIM 啟用權限。

另外，為了避免 PIM 發生問題時失去管理管道，我建議先建立前一章的 Break Glass，再導入 PIM。

情資人員都已經是全域管理員了嗎？～從 Microsoft Entra PIM 開始的特權管理
https://qiita.com/carol0226/items/5b42b547f102fa8a17a4

本文是依照先確保緊急時的管理管道，再推進特權管理的思路，因此以「Break Glass → PIM」的順序介紹。

關於最小權限、PIM 與緊急存取帳號，請參考 Microsoft 的官方建議。

Microsoft 官方最佳做法
Microsoft 建議在管理 Microsoft Entra 角色時，應套用最小權限原則，並使用 PIM 在需要的時間內啟用所需權限，採取 Just-In-Time 存取。

此外，也建議將全域管理員數量維持在最少，同時為緊急狀況預先準備僅雲端使用的緊急存取帳號。

官方資訊：Microsoft Entra 角色最佳做法
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/best-practices?wt.mc_id=MVP_407731

第四章：最小權限的總結
即使要做管理操作，也不需要一直持有高權限。

我的建議是，只在需要時，啟用所需的權限，並且只在必要時間內使用。

先用 Break Glass 確保緊急時的管理管道，再把日常管理工作切換到 PIM。

5．認證流程保護（Device Code Flow）

第一章已介紹 Passkey 的導入。
然而，即使導入了 Passkey，也不代表就萬無一失。

本章將以認證流程遭濫用為例，介紹濫用裝置代碼流程（Device Code Flow）的攻擊，以及其對策。

這裡最重要的是，並不是 Passkey 本身被破解了。

即使使用者在正規登入畫面以 Passkey 完成認證，若又不慎完成了攻擊者所發起的認證流程，仍可能導致受害。

作法上，首先要在登入記錄中確認裝置代碼流程的使用狀況。

若沒有使用，則可透過條件式存取加以封鎖；若有必要使用，也應限制允許使用的對象。重點是先確認對業務的影響，再決定套用方式。

關於攻擊原理、具體對策與驗證方法，請參考以下文章。

什麼是連 Passkey 也可能受害的裝置代碼流程攻擊？～解說 Entra ID 的防禦與驗證方法
https://qiita.com/carol0226/items/c9cccdd64e71a731a58d

該文章也包含我在 LT 說明時的影片，歡迎參考。

第五章：認證流程保護的總結
導入 Passkey 並不代表就能防住所有攻擊。

除了使用強認證方式，也應確認該認證是透過什麼流程被使用，並限制不必要的認證流程。

這次介紹的攻擊只是其中一例。不要只停留在導入 Passkey，還要因應攻擊手法的變化，持續檢討與更新防禦措施。

6．郵件與協作保護（Safe Links / Safe Attachments）

到目前為止，我們介紹了如何保護認證、存取與管理員權限。接下來，也要保護作為攻擊入口的電子郵件與協作工具。

自 2026 年 7 月 1 日起，Microsoft Defender for Office 365 Plan 1 已包含於 Office 365 E3 / Microsoft 365 E3 中。不過，各租戶的功能佈署是逐步進行的，請同時確認您環境中的提供狀況。

Safe Links 是保護電子郵件與 Microsoft Teams 等內容中 URL 的功能。當使用者點擊連結時，系統會檢查 URL；若判定為惡意 URL，便會透過警告畫面等方式阻止使用者造訪危險網站。

此外，也建議一併使用 Safe Attachments。它會在安全的檢查環境中分析附件，保護使用者免受惡意檔案影響。

即使導入了 Passkey，也無法直接阻止使用者點開惡意連結或接收危險檔案這類行為本身。

將 Safe Links / Safe Attachments 組合使用，可以在認證保護之外，額外增加一層來自連結與附件的防禦。

其中一種設定方式，是使用 Microsoft 所整理的建議設定，也就是「預先設定的安全性原則」。Standard / Strict 原則包含 Safe Links / Safe Attachments 等保護。

官方資訊：雲端組織的預先設定安全性原則
https://learn.microsoft.com/ja-jp/defender-office-365/preset-security-policies?wt.mc_id=MVP_407731#use-the-microsoft-defender-portal-to-assign-standard-and-strict-preset-security-policies-to-users

Safe Links 的運作範例
以下郵件中，內文顯示的 URL 仍維持原樣。

另一方面，若複製超連結來查看連結目的地，就會發現它已被改寫為 Safe Links 的 URL。

點擊這種改寫後的連結時，會先經過 Safe Links 的點擊檢查；若未偵測到問題，才會導向原始網站。若判定為惡意 URL，則會顯示警告畫面等。

連結會被轉換成 safelinks

https://<區域>.safelinks.protection.outlook.com/?url=<原始URL>&data=<略>&sdata=<略>

※這是 URL 會被改寫時的動作範例。根據設定與使用的應用程式，也可能是以不改寫 URL 的方式來保護。

第六章：郵件與協作保護的總結
不只是要強化認證，也要保護使用者接觸攻擊的入口，也就是連結與附件。

透過 Safe Links / Safe Attachments 的組合，降低使用者造訪危險網站或遭惡意檔案波及的風險。

7．網路零信任化（Global Secure Access）

前面已介紹認證、存取控制與郵件保護。接下來，讓我們把零信任的概念延伸到網路存取。

以下 Qiita 收藏清單，整理了我針對 Global Secure Access（GSA）所做的驗證與投稿文章。

Microsoft Entra Global Secure Access (GSA) 收藏清單
https://qiita.com/carol0226/stocks/878e7bbc57b301e0deac

Microsoft Entra Private Access 是用來保護存取公司內部系統等私有資源的功能。

它不同於將 VPN 裝置公開到網際網路的架構，而是透過來自私有網路內連接器的出站連線來提供存取。搭配條件式存取後，可以轉為以 ZTNA 為基礎、依應用程式別控制存取的架構。

另一方面，Microsoft Entra Internet Access 是用來保護網際網路存取的安全 Web 閘道（SWG）。

除了依 Web 類別或目的地進行存取控制之外，還能使用多種功能，例如保護送往生成式 AI 的提示內容。

我也將 Microsoft 365 的存取改為經由 Global Secure Access，再搭配條件式存取中的「相容網路」。

如此一來，不僅 ID 與裝置正確，還能要求必須經由我方組織的 Global Secure Access 才能存取。

對我來說，這等於在 Microsoft 365 租戶前方又多了一層網路防護牆，確實更有安心感。

只允許透過 GSA 存取 Microsoft 365 / SaaS 的設計與其優點
https://qiita.com/carol0226/items/d19375d8666b5d0b3862

關於 Global Secure Access 的授權
所需授權會依功能與目前合約內容而不同。

關於所需授權的詳細資訊，請參考我以下文章中的「2. 使用 GSA 所需的授權」。

Microsoft Entra Global Secure Access 全貌（第 2 章：2. 使用 GSA 所需的授權）
https://qiita.com/carol0226/items/29cba6c32a22893a1349#2-gsa-の利用に必要なライセンス

第七章：網路零信任化的總結
不只是認證與裝置，「從哪條路徑存取」也應納入保護範圍。

結合 Global Secure Access 與條件式存取，可以把由本組織管理的通訊路徑加入存取條件。

不建議一次全部替換，而是依組織需求，針對 Microsoft 365、網際網路、私有資源等分階段導入。

8. 偵測、調查與應對（Microsoft Defender）

到目前為止，我們主要介紹的是讓攻擊更難成功的對策。

但無論做了多少防護，都無法保證能 100% 阻擋所有攻擊或入侵。
因此接下來要考慮的是「假設已遭入侵」時的偵測、調查與應對。

Microsoft 提供了一系列名為 Microsoft Defender 的資安產品。

Microsoft Defender XDR 可以整合端點、ID、郵件、雲端應用程式等多個領域的資訊來偵測威脅，並進一步協助調查與應對。

除了前面介紹的「防止入侵」措施之外，也應該考慮「就算真的發生威脅，也能及早偵測並抑制損害擴大」的防禦方式。

關於 Microsoft Defender 的各項服務，已整理在以下文章中。

整理 Microsoft Defender 相關服務
https://qiita.com/carol0226/items/8b13a5c4ac3267fa45c4

※可使用的功能與整合範圍會依授權與組態而不同

第八章：偵測、調查與應對的總結
除了預防攻擊之外，也要做好一旦發生入侵時能及早察覺、並抑制損害擴大的準備。

建議一併建立 Microsoft Defender 的運用體制，包含警示確認、調查與應對流程。

總結

到這裡，我介紹了自己實際驗證與導入過的資安對策。

重點不是只要導入某一項產品或功能就會安全。

用 Passkey 讓認證本身具備抗釣魚能力。
用條件式存取控制認證後的存取。
用 Break Glass 確保緊急時不會失去管理管道。
用 PIM 只在需要時使用特權。
針對 Device Code Flow 等可能被濫用的認證流程採取對策。
用 Safe Links / Safe Attachments 降低使用者接觸威脅的機會。
用 Global Secure Access 把零信任概念延伸到網路。
用 Microsoft Defender 偵測、調查並應對仍可能發生的威脅。

我認為，這種一層一層疊加防禦的做法非常重要。

即便如此，也不會是「完美」的。

攻擊手法未來仍會持續演變。
所以資安對策也不該是一建好就結束，而是要持續檢視與更新。

若本文能成為您重新檢視環境的契機，我將非常開心。

附錄：該從 Microsoft 365 E5 移轉到 E7 嗎？

導入本文介紹的對策時，請依照目前契約與想使用的功能來評估授權。

我也寫過比較 Microsoft 365 E5 加購功能與移轉到 E7 的文章，供您參考。

該從 Microsoft 365 E5 移轉到 E7 嗎？～從與 Copilot 的價差思考授權選擇
https://qiita.com/carol0226/items/525ec37aea28cb4420f0

參考資訊：Microsoft 官方最佳做法

本文主要介紹的是我自己實際驗證與導入的架構。

若您想進一步深入思考 Microsoft Entra ID 的安全設計，也可參考 Microsoft 公開的以下最佳做法。

官方資訊：Microsoft Entra 角色最佳做法
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/best-practices?wt.mc_id=MVP_407731

官方資訊：所有隔離架構的最佳做法
https://learn.microsoft.com/ja-jp/entra/architecture/secure-best-practices?wt.mc_id=MVP_407731

原文出處：https://qiita.com/carol0226/items/bdb16dbd5c16a2c43ad5