什麼是網路安全中的微分段？

什麼是微分段？

微分段實作工作負載層級的存取控制，可防止未經授權的橫向移動發生於現代基礎架構中。不同於依據實體拓撲將網路劃分為大型區域的傳統網路分段，微分段會在個別工作負載之間強制執行以身分為基礎的原則，而不受網路位置影響。微分段的定義已演變為涵蓋以身分為基礎、以工作負載為中心的安全控制，並具備應用程式層級可視性，可跨多個基礎架構層運作。

微分段已成為 Zero Trust 架構的基礎支柱。此架構基於三項核心原則運作：

1. 以工作負載為中心的原則強制執行 取代以網路為中心的控制。原則會附加至應用程式身分與使用者憑證，而非 IP 位址。當您將資料庫遷移至 AWS，或在 Kubernetes 中重新部署微服務時，安全原則會自動隨工作負載移動。
2. 第 7 層應用程式感知可對通訊模式提供細緻的控制。您無須允許子網路之間的所有流量，而是可定義某個微服務可在另一個微服務上呼叫哪些特定 API。這種應用程式層級的可視性可揭露網路層防火牆完全無法發現的攻擊行為。根據 NIST Special Publication 800-207，這種對應用程式層的關注，代表安全控制已從靜態、以網路為基礎的邊界，轉向以資產和工作負載為中心。第 7 層控制會與傳統的第 2/3 層網路控制並行運作，以強制執行以身分為基礎的政策，並偵測第 2 層 VLAN 和網路防火牆無法識別的橫向移動嘗試。
3. 預設拒絕態勢 消除網路邊界內的隱含信任。每個通訊請求都需要根據身分、情境與即時風險評估進行明確授權。遭入侵的憑證可能會成功通過驗證，但當該帳戶嘗試存取其正常模式之外的工作負載時，行為分析會阻止橫向移動嘗試。

勒索軟體傳播 依賴橫向移動。攻擊者必須從初始存取擴散至高價值目標。微分段會在您的環境中建立勒索軟體無法繞過的強制執行檢查點。

為什麼微分段在網路安全中很重要？

微分段解決了以邊界為基礎的安全防護之根本失敗，也就是攻擊者可使用有效憑證在您的網路內部活動。傳統安全模型假設網路邊界內的一切都值得信任。一旦攻擊者突破此邊界，他們便可在系統間橫向移動，而不會遇到額外控制。研究顯示，攻擊者可在 橫向移動 於初始入侵後 48 分鐘內達成。

微分段透過要求工作負載之間的每個連線都必須明確授權，來消除此隱含信任。入侵 Web 伺服器的攻擊者無法連線至後端資料庫，因為原則會同時驗證身分與行為模式。了解微分段與傳統網路分段的差異，可揭示為何這種架構轉變對於 Zero Trust 安全 很重要。

微分段與網路分段有何不同

傳統網路分段在第 2 層與第 3 層運作，並根據實體或虛擬網路拓撲提供粗略粒度。VLAN 會依位置或功能將裝置分組，並對該分段內的所有項目套用相同的安全原則。當您將開發伺服器放在一個 VLAN，並將正式環境系統放在另一個 VLAN 時，每台開發伺服器都可以與其他每台開發伺服器自由通訊。

微分段可跨多個層級運作，並具備第 7 層應用程式層級控制。原則以工作負載為中心並以身分為基礎，而非以網路為中心。您定義的是這個特定 API 閘道可以存取這個特定資料庫功能，而不是子網路 A 可以到達子網路 B。

• 靜態與動態強制執行揭示了根本差異。VLAN 將安全性原則綁定至實體基礎架構，在第 2 層運作，並根據網路拓撲提供較粗略的粒度。當您部署新的雲端工作負載或擴展容器部署時，您必須手動更新 VLAN 組態和防火牆規則。網路微分段原則會自動跟隨工作負載，因為它們是根據身分屬性和應用程式內容，而非網路位址，從而實現可因應工作負載在基礎架構間移動而調整的動態原則強制執行。
• 南北向與東西向流量控制 暴露了傳統分段的盲點。網路 防火牆 擅長控制進入與離開您環境的流量（南北向）。它們難以處理內部系統之間的橫向流量（東西向），而大多數攻擊移動都發生於此。微分段特別著重於抑制對手在組織網路內的橫向移動，以存取敏感資料與關鍵系統。

微分段的核心元件

微分段架構需要四個整合元件共同運作，以強制執行基於身分的存取控制。 

1. 原則控制器 作為中央管理平面，維護安全原則儲存庫，並根據工作負載屬性、使用者情境與行為訊號計算存取決策。此控制器會將高層級安全需求轉換為部署自動化可使用的可強制執行規則。
2. 強制執行代理程式 部署於整個基礎架構中，以攔截並評估連線請求。這些代理程式可作為虛擬機器上的核心模組、Kubernetes pod 中的 sidecar 容器，或雲端安全群組的整合點來運作。每個代理程式都會在本機強制執行決策，而無需持續連線至原則控制器，因此即使在網路分割期間也能維持防護。
3. 身分提供者 透過憑證、API 金鑰或同盟身分識別通訊協定來驗證工作負載與使用者。微分段系統會查詢這些提供者，以驗證請求實體在評估授權原則之前是否具備有效憑證。
4. 遙測收集器 彙總來自強制執行代理程式的網路流量資料、原則違規與行為異常。這種持續回饋使原則控制器能夠偵測攻擊模式、建議原則調整，並對可疑活動觸發自動化回應。遙測收集可提供有效 威脅狩獵 與合規報告所需的可視性。

這些元件會依據您的基礎架構架構與營運需求，透過不同的技術方法進行部署。

微分段技術的類型

組織透過五種主要技術實作微分段，每種技術都適用於不同的基礎架構類型與營運需求。

1. 基於網路的微分段 使用軟體定義網路（SDN）控制器與分散式虛擬交換器，在網路層強制執行原則。此方法非常適合虛擬化資料中心，因為集中式 SDN 控制器可根據工作負載身分動態設定虛擬交換器流量表。
2. 基於主機的微分段 直接在作業系統上部署強制執行代理程式，透過主機防火牆或核心層級封包篩選器控制流量。此技術可為實體伺服器、舊版系統，以及無法進行網路層級控制的環境提供防護。
3. 雲端原生微分段 利用 AWS security groups、Azure network security groups 或 GCP firewall rules 等平台特定機制。雲端供應商負責管理強制執行基礎架構，而集中式原則引擎則透過 API 自動化，將工作負載身分轉換為雲端特定設定。
4. 容器原生微分段 可與 Istio 或 Linkerd 等服務網格架構整合。服務網格會攔截所有 Pod 之間的通訊，並在應用程式層強制執行原則，且在 微服務 之間使用雙向 TLS 驗證。
5. 應用程式層微分段 在第 7 層運作，控制特定 API 呼叫、資料庫查詢或應用程式功能，而不只是允許或封鎖連線。此技術需要與應用程式框架深度整合，但可對工作負載行為提供最細緻的控制。

了解這些實作方法後，就能明白為何組織即使面臨營運複雜性，仍會採用微分段。

微分段如何運作

微分段透過在工作負載層級進行身分驗證與原則強制執行來落實存取控制。此架構需要三個核心元件協同運作：計算並發出存取決策的原則決策點 (PDP)、透過啟用、監控或終止連線來強制執行這些決策的原則強制執行點 (PEP)，以及可提供網路流量與安全態勢可視性的持續監控系統。

1. 原則決策點 會使用工作負載身分、應用程式內容、使用者認證與行為屬性來評估存取要求。當容器化應用程式嘗試與資料庫通訊時，原則引擎會驗證：此工作負載身分是否具有授權？要求的操作是否在正常行為模式內？使用者工作階段是否顯示遭入侵的跡象？
2. 原則強制執行點 位於工作負載之間，並透過允許、封鎖或監控連線來強制執行決策。這些強制執行點可在多個層級運作，包括網路介面、主機防火牆、服務網格或 雲端安全性 群組。與傳統防火牆的關鍵差異在於：強制執行點接收的是動態、以身分為基礎的決策，而非靜態、以 IP 為基礎的規則。網路微分段強制執行點作為原則強制執行點 (PEP) 運作，使用納入身分、應用程式狀態、資產特性與行為屬性的動態原則，來強制執行由原則決策點 (PDP) 計算出的決策。
3. 持續監控 會將遙測資料回饋至原則引擎，以進行行為分析與威脅偵測。每個被允許的連線都會產生有關通訊模式、資料量與存取時間的資料。異常行為，例如 Web 伺服器突然啟動對外的資料庫連線，會觸發原則重新評估或自動封鎖。這種持續驗證可防止傳統網路控制遺漏的 防止橫向移動 嘗試。

根據 NIST Special Publication 800-207，此架構將網路安全防禦從靜態網路邊界轉移為聚焦於資產、資源與使用者。存取決策會在每個工作階段中持續驗證，而不是只在網路邊界進行一次。

傳統分段與微分段如何互補

您不會以微分段取代網路分段。您會將微分段疊加在現有的網路邊界之上，以建立縱深防禦。

網路分段可在主要安全區域之間提供巨觀層級的隔離。然而，根據比較網路分段與微分段的研究，傳統網路分段是在第 2 層運作，並以網路拓撲為基礎採用較粗略的粒度，在此情況下，區段內的所有裝置共用相同的安全性原則。您的 DMZ、企業網路與營運技術環境可透過 VLAN 或子網路在網路層進行分隔，但僅靠這些邊界，對於防範橫向移動所能提供的保護仍然有限。

現代 零信任架構 需要微分段、以身分為基礎、工作負載層級的 存取控制，並在多個層級運作且具備第 7 層應用程式層級控制，才能有效防止橫向移動。 

雖然傳統網路分段可防範錯誤設定，並在攻擊者突破周邊防禦時提供粗略的遏制，但面對平均橫向移動時間僅 48 分鐘的對手，這仍然不足。微分段超越巨觀層級的隔離，無論網路位置為何，都能在個別工作負載之間強制執行細粒度、以身分為中心的原則，提供現代基礎架構中有效遏制所需的明確授權要求與預設拒絕態勢。

微分段會在這些區域內加入細緻的控制。在您的企業網路區段內，微分段可防止遭入侵的筆記型電腦存取每一部伺服器。在您的 Kubernetes 叢集中，它可確保容器僅與明確授權的服務通訊。對於無法支援以身分為基礎控制的基礎架構，您仍保留傳統分段，同時逐步將微分段涵蓋範圍擴展至關鍵資產。

微分段的主要優勢

微分段可帶來可衡量的安全性改善，直接解決以邊界為基礎的防禦限制。優勢包括：

• 橫向移動 遏制可阻止攻擊者在初始入侵後於系統之間橫向移動。研究顯示，攻擊者在取得存取權後 48 分鐘內就會進行橫向移動。微分段會建立強制執行檢查點，無論攻擊者是否持有有效認證，都能封鎖此類移動。
• 降低爆炸半徑 可限制成功攻擊的影響範圍。當勒索軟體加密某個工作負載時，微分段原則可防止其擴散至相鄰系統。組織可將遏制時間從數小時縮短至數秒。
• 簡化合規 可因應資料隔離與存取控制的稽核要求。PCI DSS、HIPAA 和 SOC 2 都要求限制對敏感系統的存取。微分段可提供原則強制執行的可稽核證明，並附上完整流量記錄，精確顯示哪些工作負載曾進行通訊。
• 攻擊面可視性 可揭露工作負載之間的所有通訊路徑，暴露出不應存在的未授權連線。這種可視性可識別組態漂移、影子 IT，以及傳統網路監控遺漏的遭遺忘服務。
• 原則可攜性 可在工作負載於資料中心與雲端之間移轉時維持一致的安全性。以身分為基礎的原則會自動跟隨應用程式，無需因每次基礎架構變更而手動更新防火牆規則。

這些優勢伴隨著實作挑戰，組織必須透過審慎規劃與資源配置來因應。

跨現代化基礎架構的實作

微分段必須在異質基礎架構中強制執行一致的原則，而不需要您為每個平台重寫安全控制。您的基礎架構涵蓋內部部署資料中心、多個公有雲、容器化應用程式，以及無伺服器函數。

• 雲端原生環境帶來獨特的挑戰。工作負載會動態擴展，IP 位址持續變更，而傳統的網路邊界並不存在。根據 CISA 的指引，微分段必須明確涵蓋橫跨 IaaS、PaaS、SaaS 與混合式架構的「公有與私有雲端環境」。您可透過雲端原生機制來實作這一點，包括 AWS 中的安全群組、Azure 中的網路安全性群組，以及 GCP 中的防火牆規則，並由集中式原則引擎進行管理，將工作負載身分轉換為特定平台的強制執行。全面性雲端工作負載保護 需要可自動適應動態雲端基礎架構的微分段原則。
• 容器協調平台 等平台需要服務網格整合。服務網格位於微服務之間，攔截所有通訊，以在 pod 層級強制執行微分段政策。當開發人員透過 CI/CD 管線部署新的容器版本時，安全政策會根據工作負載標籤和服務身分自動部署。實作 Kubernetes security 的組織必須確保微分段政策可與容器協調流程無縫整合。
• 傳統基礎架構 無法立即支援以身分為基礎的控制。您應逐步實作微分段，從足以證明整合投入合理性的關鍵資產開始。對於無法參與具身分感知架構的系統，其強制執行點包括主機型防火牆、網路 tap-and-forward 機制，或可在多個層級運作以提供分段邊界的防火牆解決方案。

常見的微分段錯誤

當組織將微分段視為網路工程專案，而非安全架構轉型時，就會失敗。若將其視為全面性的安全架構工作，而非純技術性的網路計畫，這些失敗是可預測且可避免的。

• 在缺乏可視性的情況下開始 在強制執行開始之前就注定了實作失敗。當您不知道哪些工作負載會進行合法通訊時，就無法定義最小權限政策。組織會立即部署強制執行、阻擋合法的業務流量，然後退回到不具任何安全價值的寬鬆政策。在進入政策強制執行之前，您需要先透過探索與叢集分析掌握網路資產與流量模式的可視性，因此在移轉至強制執行前需要先進行初始規劃與分析階段。
• 將微分段視為產品而非計畫 會忽略所需的營運轉型。您不是在購買防火牆並設定規則，而是在改變安全政策與應用程式部署、基礎架構佈建及 incident response 的整合方式。
• 根據 IP 位址實作政策會違背其目的。 如果您的微分段政策參照特定 IP 位址或子網路，您建立的只是更細緻版本的傳統分段。其價值來自可隨基礎架構變更而跟隨工作負載的身分型政策。當以 IP 為基礎的政策在雲端遷移期間失效時，組織往往會完全放棄微分段，進而失去定義現代 Zero Trust 架構的工作負載中心安全模型。
• 忽略應用程式相依性 會造成中斷，侵蝕利害關係人的信任。現代應用程式涉及數十個微服務、外部 API 和資料相依性。在您的政策定義中遺漏任何一項相依性，都會阻斷關鍵業務功能。您必須在定義強制執行政策之前，記錄完整的應用程式交易流程，以確保微分段政策能促進而非妨礙合法的業務運作。
• 設定不切實際的涵蓋範圍期望 即使在實作成功時，也會導致被認為失敗。您不是要立即保護所有內容，而是從關鍵資產開始逐步向外擴展涵蓋範圍。將成功定義為「6 個月內達到 100% 涵蓋率」只會保證失望。

微分段的挑戰與限制

微分段會帶來營運複雜性，組織必須透過流程變更與技能發展來因應。

• 營運負擔 會增加，因為安全團隊管理的是數千條細緻政策，而非數十條防火牆規則。每次應用程式部署都需要政策定義、測試與驗證。組織往往低估政策生命週期管理所需的人力，導致過時規則累積的速度快於團隊稽核速度，形成政策蔓延。
• 應用程式相依性對應 會成為阻礙性的必要條件。當政策未涵蓋完整的應用程式交易流程時，微分段就會失敗。在具有數百個微服務和第三方整合的環境中，對應這些相依性需要自動化探索工具和延長的觀察期間，因而延後實作。
• 效能影響 會因強制執行技術與實作品質而異。主機型代理程式會因封包檢查而增加 CPU 負擔。網路型解決方案會因額外躍點而引入延遲。雲端原生微分段在動態更新安全群組時會面臨 API 速率限制。組織必須在部署前，於正式環境負載下對強制執行點進行效能測試。
• 技能落差 會限制採用速度。安全團隊了解網路防火牆，但缺乏身分型政策、API 驅動自動化及容器網路方面的經驗。當團隊在不了解應用程式架構的情況下實作政策時，這種知識落差會帶來部署風險。
• 傳統系統限制 會阻礙全面涵蓋。大型主機、工業控制系統和專有應用程式無法參與具身分感知的架構，迫使組織必須對這些資產維持傳統分段。

儘管存在這些挑戰，各產業的組織在理解真實世界的實作模式後，仍能成功部署微分段。

微分段最佳實務

透過遵循結構化、分階段的方法論，優先處理可視性與資產探索、建立細緻的分段政策，並在維持全面監控與合規驗證的同時逐步擴展，您可以提高實作成功率。

1. 在強制執行政策之前先對應流量模式。在整個環境中以觀察模式部署監控 30-90 天。擷取哪些工作負載彼此通訊、它們使用哪些通訊協定、資料量模式以及連線時序。此基準可識別您必須保留的合法相依性，以及在開始強制執行前應調查的異常行為。
2. 從高價值、低複雜度的資產開始。 您的首次微分段部署應鎖定相依性明確的關鍵工作負載，例如正式環境資料庫、付款處理系統，或 privileged access management 基礎架構。這些資產足以證明整合投入的合理性，並展現可衡量的風險降低成效。
3. 分階段實作預設拒絕。 先從僅監控模式開始，在此模式下政策會產生警示但不會封鎖流量。接著進展到依警示封鎖，由安全團隊審查並核准例外。最後轉向具備例外工作流程的自主強制執行。這種分階段方法可在政策缺口造成中斷之前先行識別。
4. 針對 DevOps 環境與 CI/CD 管線整合。 當開發人員交付新程式碼時，安全政策必須自動部署。API 驅動的政策管理可讓您將安全需求定義為程式碼、在 pull request 中審查，並與應用程式組態一同進行版本管理。這會將安全政策視為應用程式定義的一部分，而非獨立的網路組態。
5. 定義清楚的例外工作流程。 您將需要政策例外，例如第三方整合、傳統應用程式、緊急變更流程。若沒有文件化的例外工作流程，組織就會建立臨時性的「暫時」例外，最終成為永久性的安全漏洞。您的流程應要求業務理由、具時限的核准，以及自動到期。
6. 衡量涵蓋率與強制執行率。 追蹤您的環境中有多少百分比已部署微分段政策，以及這些政策主動強制執行了多少百分比的流量。這些指標可量化進度並識別缺口。根據 NIST Special Publication 800-207，企業應蒐集有關資產、網路與通訊狀態的資訊，並利用這些資訊持續改善 security posture。

作為 Zero Trust 基礎的微分段

微分段強制執行 Zero Trust Architecture 的「永不信任，一律驗證」原則，藉由消除網路邊界內的隱含信任來達成。三大安全框架皆將微分段視為實作 Zero Trust 的基礎架構，並在架構原則、成熟度演進與營運防護措施方面提供互補性的指引。

• 根據 NIST SP 800-207，Zero Trust Architecture 要求從以網路為基礎的邊界防護，轉向聚焦於資產、資源與使用者，並持續進行驗證。微分段與零信任之間的關係已成為基礎，其中微分段作為 Zero Trust 網路安全政策的主要強制執行機制。
• 此架構直接連結到 Zero Trust 的身分支柱。當攻擊者竊取認證資料時，他們會取得驗證存取權限，但微分段可防止他們利用該存取權限進行橫向移動。遭入侵的認證資料可能成功通過驗證，但對未授權工作負載的連線嘗試會觸發封鎖與警示。
• CISA's Zero Trust Maturity Model Version 2.0 提供涵蓋五大支柱的路線圖：身分、裝置、網路、應用程式與工作負載，以及資料。微分段主要位於網路支柱中，但也依賴身分支柱進行驗證，以及應用程式與工作負載支柱來進行行為分析與工作負載層級可視性。組織可藉由將微分段與 identity segmentation 結合，在其基礎架構中強制執行細緻、以身分為基礎的存取控制，從而強化其安全態勢。
• CISA 的模型定義了演進階段：Traditional → Initial → Advanced → Optimal。目前大多數組織仍處於 Traditional 或 Initial 成熟度。實作微分段零信任架構的組織必須採取分階段方法，而非「一次到位」的轉型，優先處理風險最高的資產，並逐步擴大涵蓋範圍。
• The CIS Controls Version 8 也提供支援微分段的防護措施，涵蓋五項控制措施：Control 9（網路連接埠、通訊協定與服務管理）、Control 11（企業資產與軟體的安全組態）、Control 12（網路基礎架構管理）、Control 13（網路監控與防禦），以及 Control 14（安全意識與技能訓練）。這些控制措施提供了與 Zero Trust 成熟度演進一致的營運實作框架。 

這些框架說明了為何微分段對 Zero Trust 架構至關重要。它是防止遭入侵認證資料促成橫向移動的強制執行機制。透過微分段，您可在整個基礎架構中建立驗證檢查點，無論驗證是否成功，都能阻止攻擊者。實作需要將這些架構原則轉化為可在異質基礎架構中強制執行的政策。

真實世界範例與使用案例

微分段可藉由強制執行傳統網路分段無法提供的身分型政策，來阻止勒索軟體擴散、防止資料外洩，並保護營運技術。以下是幾個其在真實世界中可能適用的情境：

1. 醫療服務提供者隔離病患資料系統。 某個多醫院網路利用微分段政策，將電子健康紀錄、醫療裝置與行政工作負載分隔開來。當勒索軟體透過 phishing 感染計費部門時，政策阻止了其橫向移動至病患資料庫。該醫院將事件控制在 12 台工作站內，同時維持病患照護。傳統 VLAN 分段原本會讓勒索軟體擴散至整個醫院網路。
2. 金融服務公司保護付款處理。 某信用卡處理商將資料庫存取限制為特定 API 功能，而非允許廣泛連線。在 penetration testing 期間，入侵網頁應用程式的攻擊者無法執行超出正常交易模式的查詢。這防止了 data exfiltration，而這原本是網路防火牆會允許的。
3. 製造公司保護營運技術。 某汽車製造商允許工程工作站將組態更新傳送至組裝控制器，但封鎖反向連線。當惡意軟體感染企業網路時，儘管共用基礎架構，微分段仍阻止其觸及生產系統。

這些實作之所以成功，是因為組織遵循了經驗證的部署方法，而非試圖立即達成全面涵蓋。

使用 SentinelOne 部署微分段

SentinelOne 使用網路隔離原則，可協助您立即回應並在威脅源頭加以遏制。它可防止橫向移動，且您可以使用 SentinelOne 的行為式 AI 引擎來偵測各種惡意威脅。您可以將其代理程式設定為自動中斷裝置與網路的連線，並且即使端點已被隔離，仍可持續進行管理存取。裝置可設定細緻化原則；您也可以使用 SentinelOne 的整合式防火牆控制功能，協助您將網路安全原則延伸至其他裝置，而不受其所在位置影響。

您可以從用於其他端點安全功能的同一個 Singularity 主控台設定 SentinelOne 的防火牆規則。您將可完整掌握網路流量的可視性。SentinelOne 的 Singularity™ Network Discovery (Ranger) 也是一項實用功能，可協助您自動探索並建立網路上所有支援 IP 裝置的指紋。它可提供受管理與未受管理資產的可視性。結合上述所有功能後，您便能自主偵測並化解威脅。

我們還想強調 SentinelOne 的條件式存取功能，您可以透過 Singularity™ Identity Solution 試用。它可直接與領先的身分提供者整合，例如 Microsoft Entra ID (Azure AD)、Okta 和 Ping Identity。

SentinelOne 的條件式存取功能可協助您落實零信任模型，並根據端點即時健康狀態與安全態勢，動態調整使用者對企業資源的存取權限。它可評估您所有端點的健康與合規狀態，並強制執行預先定義的條件式存取原則。其強制執行或允許的存取並非二元式，這表示它具備情境感知能力且可自適應。SentinelOne 的原則將具備情境感知能力，並會針對已遭入侵的裝置自動提高強制執行層級，並在威脅獲得修復後降低層級。

SentinelOne 也將協助您在其 IdP 解決方案中強制執行多重要素驗證，並動態加入高風險使用者群組。您也可以將其設定為針對您的 security operations centers 產生詳細警示，以協助後續進行人工調查。

Singularity™ Platform

Elevate your security posture with real-time detection, machine-speed response, and total visibility of your entire digital environment.

Get a Demo

結論

微分段藉由在個別工作負載之間強制執行以身分為基礎的政策，消除攻擊者在橫向移動期間所 利用的 隱含信任。不同於傳統網路分段中廣泛的 IP 型區域，微分段提供第 7 層應用程式感知能力，以及以工作負載為中心、可隨基礎架構變更而跟隨應用程式的控制。此架構作為 Zero Trust 的基礎支柱，要求透過政策決策點、強制執行點，以及持續的 behavioral monitoring，對每一個連線進行明確授權。 

實作需要有結構化的演進方式，從流量可視性與相依性對應開始，優先聚焦高價值資產，並透過與 CI/CD 管線及應用程式工作流程整合的分階段部署來擴大涵蓋範圍。