筆者

角色分工課題提示K⁺oji Na⁺kamura原案撰寫Claude Fable 5,GPT-5.6 Sol出典確認支援・加筆GPT-5.6 Sol技術面檢查K⁺oji Na⁺kamura---

TL;DR

• 2015年日本年金機構事件所引發的地方自治體「三層對策（三層分離）」制度化已約10年
• 針對從 LGWAN 連線環境安全瀏覽 Web 的「網際網路分離」實作方式，可按執行位置 × 分離粒度 × 傳輸方式三軸整理為 4 種類型（本文作者自訂的便宜整理）
• 分離成敗在實務上分出高下的，與其說是方式本身，不如說是與檔案無害化的整合（含廢止 PPAP 後增加的 Web 下載/交換流程）、都道府縣資安雲的 SSL 解密、Web 會議與雲端服務的連線設計等摩擦點
• 在資安面，LGWAN 連線環境原則上不保留直接通往網際網路的路徑，使得直接通訊型 C&C 與對外資料外傳在結構上更難成立。這可作為不依賴偵測的防禦來正面評價，但不能說成「即使感染也無法發動攻擊」
• 政策上，已朝向減少依賴多台終端與 USB 交付的三層分離，並逐步導入零信任概念的國地共通網路（目標約 2030 年前後）。在指南層面，將本地突破式連線制度化的「α' 模型」已於 2024 年 10 月正式新增，制度已開始追認現實。2026 年的驗證結果也顯示，移行並非全面拆除既有分離，而是會依機密性採用論理分離與邊界防禦並用的混合式解法
• 補講部分將從教育領域先行「停止分離」、醫療 DX 的「閉域線路並行」，以及從分離外側逼近的供應鏈風險（Iseto 事件・《資安應對能力強化法》）等比較，思考下一個 10 年的設計條件。補講 2 將探討「搬運檔案的行政」轉向「由 API 驅動的行政」（公共服務 Mesh）後，信任邊界會移到哪裡；補講 3 則討論 AI 的進展與普及對攻擊、利用、防禦帶來的變化，以及「無害化」「分離」概念的延伸

本文的方式分類（4 類型）是為了讓調達與運用上的差異更易理解而做的便宜整理，並非公部門或業界標準分類。實際產品可能同時具備多種類型的功能，並非互斥分類。此外，本文依據截至 2026 年 7 月公開資料撰寫。產品名稱僅作為說明技術方式的代表例，並非特定產品推薦或功能全收錄。由於規格與授權體系可能變動，導入時建議以最新資料與 PoC 確認。

本文的閱讀方式

• 第 1 章到第 6 章是「網際網路分離 10 年」的正文
• 補講 1 是教育、醫療與供應鏈的比較
• 補講 2 處理公共服務 Mesh 與 API 的信任邊界
• 補講 3 處理 AI 時代的無害化、分離與權限管理

若只想確認技術方式與運用論點，可獨立閱讀第 1 章到第 4 章。

1. 前提：三層對策與網際網路分離

2015 年日本年金機構資訊外洩事件後，總務省的自治體資訊安全對策檢討團隊於同年 11 月 24 日彙整報告〈朝向新型自治體資訊安全對策的徹底強化〉1。以此為基礎，並於同年 12 月 25 日的總務大臣通知（總行情第 77 號）中明示徹底強化對策，經平成 27 年度補正預算設立補助金後推展至全國的，便是將庁內網路分成 3 部分的「三層對策」2。各自治體被要求於 2017 年 7 月前完成對應，以配合 My Number 資訊連結開始，之後全國各地逐步導入三層對策與自治體資訊安全雲。

同時，也建立了以都道府縣為單位集中網際網路出口的「自治體資訊安全雲」。

此處的核心問題是，要如何讓 LGWAN 連線環境的終端安全地瀏覽 Web。若以實體方式分開終端，執行環境與通訊路徑的邊界會很明確，但成本與便利性的代價很高，USB 等資料移轉路徑也必須另外管制。總務省透過 VDI、SBC、虛擬瀏覽器等虛擬化技術，提出將在網際網路連線環境端執行的桌面或瀏覽器之顯示結果，只轉送到 LGWAN 連線環境終端的「論理分離」3。起初以這種畫面轉送型的論理分離為主，之後又發展出 DOM 鏡像型雲端 RBI，以及在終端內隔離區域執行的方式等多種實作。本文將這些統稱為「網際網路分離」。

2. 技術類型 —— 4 種方式

網際網路分離的實作方式，在產品型錄上常混用「虛擬瀏覽器」「安全瀏覽器」等稱呼，但若從下列 3 軸整理，便能更清楚地理解。

軸選項分離執行環境的位置庁內/DC 的伺服器／公有雲／終端內的隔離區域分離粒度整個桌面／僅瀏覽器端點轉送方式畫面（像素・影格）轉送／繪製資訊（DOM）轉送／不轉送（於終端內執行）沿著這 3 軸可將代表性產品整理為 4 類型（① 若為 DaaS 形態，則是在公有雲上執行）。

類型① 虛擬桌面方式（VDI／DaaS）

代表產品：Citrix DaaS、Citrix Virtual Apps and Desktops、Omnissa Horizon（前 VMware Horizon）、Azure Virtual Desktop

在網際網路連線環境（或公有雲上）以虛擬機器形式建置整個桌面 OS，僅將畫面轉送到 LGWAN 端終端。不只瀏覽器，郵件與各類應用程式也能在分離環境側執行。

• 優點：業務自由度最高。導入實績與經驗累積豐富，容易與既有瘦客戶端基礎整合
• 缺點：每台虛擬機器的授權費與 Windows 環境的雙重管理（修補程式、更新）會形成持續負擔。衍生型的 SBC/RDS 方式雖然整合性較佳，但仍有 RDS CAL 成本與伺服器故障時影響所有使用者的另一種取捨

注意產品名稱的變遷。Citrix DaaS 是舊「Citrix Virtual Apps and Desktops service」的現行名稱，而地端產品 Citrix Virtual Apps and Desktops 至今仍是另一個獨立產品。另一方面，「Citrix Workspace app」則是連線至這些虛擬應用與虛擬桌面的客戶端（舊 Citrix Receiver 的後繼者）4。另外，VMware Horizon 在 Broadcom 收購 VMware 後、因 EUC 部門分拆而成為 Omnissa Horizon。對照過往採購規格書與現行產品名稱時，容易混淆。

類型② 伺服器型虛擬瀏覽器方式（容器＋畫面轉送）

代表產品：RevoWorks SCVX、SKYDIV Desktop Client（虛擬瀏覽器方式）

不是整個桌面，而是僅把瀏覽器在伺服器端分離執行。RevoWorks SCVX 是在 Linux 上以 Docker 容器執行瀏覽器並僅轉送畫面的架構，瀏覽器啟動時會建立容器，結束時則銷毀。即使容器內不慎感染，也能抑制波及其他工作階段與主機環境，並透過工作階段結束時銷毀環境來防止殘留。由於是 Linux 基礎，因此在 VDI/RDS 架構中常成為重大成本因素的 RDS CAL 可免除，這在採購上是一大優勢5。

• 優點：限定於瀏覽器用途，因此集約效率高於 VDI。每次建立與銷毀容器可構成感染重置。擺脫 Windows 授權體系
• 缺點：無法用於瀏覽器以外的業務。由於採畫面轉送，媒體處理會集中在分離環境側。伺服器容量規劃與障礙應對責任仍留在導入方

SKYDIV Desktop Client 在產品上同時具備 VDI 方式、SBC（RDS）方式與虛擬瀏覽器方式三種，是套件型產品6，因此將其一概稱為「容器化產品」並不精確。較妥當的做法，是將其整理為跨越類型①與②的產品。

類型③ 雲端型遠端瀏覽器分離（RBI）

代表產品：Menlo Security、Ericom Shield

與類型②相同，都是「遠端執行瀏覽器」，但不同之處在於執行位置是廠商的雲端（SaaS）（Ericom 等也有地端提供形式的產品）。轉送方式會依產品與設定不同而異，因此在此再作副分類。

• DOM 鏡像型：Menlo Security 透過 Adaptive Clientless Rendering，將在雲端瀏覽器中執行的結果，以基於 DOM 的無害化內容而非像素，繪製到終端側既有瀏覽器（Chrome/Edge 等）7

• 像素／影格轉送型・混合型：Ericom Shield 會依政策區分使用 Frame（影像影格轉送）、Stream（媒體採串流）、Crystal（將判定為安全的 DOM 等內容轉送）8。「繪製資訊轉送型」不能一概而論

• 優點：可直接使用終端側平常使用的瀏覽器，操作體驗佳（廠商訴求為「接近本機的體驗」7）。免去伺服器基礎架構的建置、維護與容量規劃。與無害化及 SWG 功能的整合愈趨成熟

• 缺點：持續性的月費成本。LGWAN 連線環境需與雲端服務之間設計路徑，思維與傳統閉域前提不同。依賴海外 SaaS 帶來資料治理說明責任

類型④ 本地沙箱方式（終端內分離）

代表產品：RevoWorks Browser、Soliton SecureBrowser（＋ Soliton SecureGateway）

在終端內部建立分離執行環境的方式。RevoWorks Browser 會在本機 PC 內建立容器，容器經由 VPN 透過閘道／代理伺服器連接網際網路。下載檔案會留在容器內，經無害化後再轉送至本機9。Soliton SecureBrowser 則是在終端內的隔離區域執行瀏覽器，因此不需要用於瀏覽器執行的大規模 VDI/SBC 基礎架構。不過，為了認證與存取路徑控制，會搭配 Soliton SecureGateway（實體／虛擬設備或雲端服務）使用10。

• 優點：不需要瀏覽器執行伺服器，成本結構較輕。不透過畫面轉送，影片等操作體驗佳。適合小型組織
• 缺點：分離邊界不是「網路之間」，而是「同一終端內的論理邊界」。仍需部署與更新管理每一台終端

就威脅模型評估而言：終端內分離的分離強度，取決於沙箱實作與主機 OS 的健康狀態。沙箱逃逸或主機 OS 漏洞的影響，與將執行環境放在跨網路位置的類型①～③不同，信任邊界的性質也不一樣。不過這並非一律孰優孰劣，而是會隨產品的隔離實作、終端管理狀態與 EDR 等配套而改變實際風險。

類型比較表

① VDI/DaaS② 伺服器型虛擬瀏覽器③ 雲端 RBI④ 本地沙箱執行位置庁內/DC 或公有雲庁內/DC 伺服器（容器）廠商雲端終端內的隔離區域分離粒度整個桌面僅瀏覽器僅瀏覽器僅瀏覽器轉送方式畫面轉送畫面轉送DOM 鏡像／影格轉送／混合型不轉送（終端內執行）主要信任邊界虛擬化基礎架構・連線代理・管理平面容器／工作階段・主機 OS・傳輸路徑RBI 業者的雲端・租戶隔離・繪製轉換主機 OS・隔離引擎・終端管理初期／運用成本高／高（Win+CAL）中／中（部分產品免 CAL）低／持續月費低／中操作性・影片中中（持續改善）高高主要課題雙重管理・授權瀏覽器限定・體感品質雲端依賴・路徑設計終端內邊界的評估・終端負荷成本與操作性的行列是一般傾向，會因同時連線數、授權體系、終端效能、是否具備媒體最佳化等配置而改變。

3. 運用的現實 —— 10 年間浮現的摩擦點

比起方式選定，甚至更讓前線困擾的，是分離環境與業務接點所產生的摩擦。本文特別挑出 4 個影響較大的部分。

3.1 與檔案無害化的整合

從網際網路取得的檔案要帶入 LGWAN 連線環境時，必須進行無害化。無害化實作除了 CDR（Content Disarm and Reconstruction：移除可能成為威脅的元素並重新組成檔案的方式）之外，還包括格式轉換、移除巨集、轉為文字／影像，以及與防毒掃描的組合等，而 CDR 是其中最具代表性的方式。與分離解決方案的整合模式可整理為 4 種。

模式概要典型例子(a) 分離瀏覽器內建型將下載檔留在容器內，透過選單操作無害化 → 轉送至本機RevoWorks SCVX / Browser59(b) 檔案交付系統中繼型分離環境與 LGWAN 之間的中繼系統呼叫 CDR 引擎各檔案交付產品＋各種引擎11(c) 分離解決方案整合型將檔案・郵件無害化整合到 Web 分離產品中Menlo、Ericom Shield(d) 郵件無害化連動型在郵件閘道上對附件進行無害化處理各郵件產品＋各種引擎11代表性的 CDR 引擎包括 Votiro Disarmer、OPSWAT MetaDefender、國產品（川口弘行合同会社 Sanitizer、プロット Fast Sanitizer 等）11。就導入規模而言，各公司公開數據顯示，Votiro 為「46 個都道府縣、超過 750 個自治體」（2019 年 1 月時由銷售方公開的數值）12，OPSWAT 則為「保護日本地方公共團體的 70% 以上」（2026 年自家公開）13。然而兩者的指標、時間點與對象範圍不同，且互不排斥，因此不能據此推導市場排序。※若要記載市占率，需確認 ITR 等調查原典（調查對象、指標、年度）。

運用上的重點有 3 個。第一是步驟數。中繼型的典型流程是「在網際網路連線環境下載 → 上傳至無害化系統 → 處理 → 在 LGWAN 端再次下載」這種多段人工作業11，這條動線本身就象徵著三層分離 10 年來的業務效率下降。

第二是加密檔案。有密碼保護的壓縮檔若不先取得密碼並解壓，CDR 引擎無法檢查與重建其內容。現在雖有把密碼輸入或另開畫面解壓納入流程的產品與整合方式14，但其運用仍比一般檔案複雜。第三是功能受損。因移除巨集與內嵌物件，導致「無害化之後檔案無法用於業務」的問題，始終是前線最常見的不滿。

3.2 廢止 PPAP 的副作用 —— 「從 Web 接收、帶入 LGWAN」的手續放大

PPAP 是將附有密碼的 ZIP 檔以郵件寄送，再以另一封郵件傳送密碼的俗稱。由於 ZIP 與密碼經由相同郵件路徑，對竊聽防護效果有限；而加密附件也會妨礙郵件配送路徑上的病毒掃描與無害化。換言之，3.1 所述「加密檔案無法透過 CDR 處理」這個問題，若從寄送端的慣行來看，便是 PPAP 的具體表現。內閣府、內閣官房自 2020 年 11 月 26 日起廢止自動加密 ZIP 檔的寄送15，IPA 也在同年 9 月提醒：惡意程式 Emotet 會濫用有密碼 ZIP，使其較容易在郵件路徑上繞過偵測與檢疫16。因此，廢止 PPAP 本身就是合理的資安改善。

問題在於，替代方式如何在三層分離下對收件者產生何種業務動線。廢止 PPAP 後廣泛普及的是：寄件者先將檔案存入雲端儲存或檔案傳送服務，再用郵件通知收件者下載 URL。HENNGE 2023 年調查顯示，在已導入 PPAP 替代方案的 110 人中，52.7% 提到「附件下載服務」17（這是單一業者調查，並非市場整體統計），同公司使用者的彙整也顯示，附檔郵件中的 PPAP 比例已從 2021 年 10 月的 29.4% 降至 2026 年 6 月的 6.2%18。從郵件附件轉向以 Web 方式交付，方向相當明確。

在一般企業網路中，這樣的轉換可避免附件容量限制，並可額外加入 URL 到期、下載次數限制、收件者認證、操作紀錄等控制。然而在主力業務終端放置於 LGWAN 連線環境的 α 模型中，接收郵件通知的位置與實際檔案所在地，分屬不同的信任領域。

收件者的操作也會因服務而增加。因為要加入電子郵件地址驗證、一次性密碼、短效期、JavaScript 與 Cookie 要求與虛擬瀏覽器的相容性、下載次數限制等。若無害化後巨集或內嵌物件消失，還可能需要向寄件者要求原始檔或重新以其他格式寄送。

受遞方式收件端的安全化 α 模型中易出現的操作一般郵件附件若郵件閘道與 CDR 能自動連動，可能自動處理後在 LGWAN 端開啟附件PPAP加密狀態下無法檢查／無害化取得密碼、解壓、重新檢查、人工搬入下載 URL・雲端分享實際檔案不經郵件路徑透過分離瀏覽器認證與取得，重新登錄至交付基礎設施，處理後再於 LGWAN 端重新取得此處出現的是，寄件端郵件安全提升與分離收件端業務效率下降之間的不對稱。原本在一般附件下可由郵件閘道自動無害化的檔案，當改為 Web 接收後，就會在 3.1 中繼型 5 步驟的前段再加上「透過分離瀏覽器認證／下載」，使手動「從網際網路端搬入 LGWAN 端」的對象整體增加。對寄件者而言，只是附件換成 URL，但對收件自治體職員而言，每一個檔案都多了一道跨越信任邊界的作業。

解方不是回到 PPAP，而是將廢止 PPAP 的接收路徑與無害化、跨系統轉送整合為一體。

• 讓外部寄件者直接上傳到自治體指定的收件入口，並將病毒掃描、CDR、核准與 LGWAN 端配送串成一條流程
• 將郵件連動型下載服務、檔案交付基礎設施與 CDR 透過 API 等方式串接，消除職員「下載後再上傳」的動作
• 不要讓使用者任意挑選外部服務，而是標準化收件路徑、保存期限、認證方式、紀錄與支援格式
• 在調達評估中，除產品功能外，也納入每個檔案的操作次數、等待時間、逾期復原、重送率、無害化造成的功能毀損率等運用 KPI
• 針對 α' 模型等允許使用的雲端服務，結合租戶控制、終端管制與下載時檢查，不要讓低風險資訊也一律歷經多段搬入

廢止 PPAP 改善了郵件問題；但在三層分離的自治體裡，這個改善不會自動變成全域最佳化。若只思考「如何安全送出」，而不連同「分離的對方能否安全且少手續地接收」一起設計，資安措施就可能產生另一種資安運維負債。

3.3 都道府縣資安雲的 SSL 解密代理所造成的限制

都道府縣資安雲通常會集約市區町村的網際網路出口，並透過代理伺服器進行 SSL 解密（SSL inspection）來檢查通訊內容。此處產生的限制具有結構性。

1. 與憑證釘選衝突：SSL 解密本質上是中間人架構，前提是將代理的替代憑證配發到終端。採用憑證釘選的通訊在解密下無法成立。Microsoft 本身也說明，Delivery Optimization 因採用憑證釘選，因此必須排除於 TLS 檢查之外19
2. 客戶端憑證認證：TLS 解密代理無法持有客戶端私鑰，因此在解密狀態下原理上無法成立客戶端憑證認證。該網站必須另行設定為解密排除或直通
3. 處理負荷：解密全縣所有流量的負荷會造成延遲與頻寬壅塞
4. 新協定支援：QUIC／HTTP3 在傳統解密代理下不易處理，過去常採封鎖 UDP/443 使其降級至 HTTP/2 以下。目前已有可直接檢查 HTTP/3 的產品世代20，因此仍需確認產品與檢查方式

將限制與對策對應整理如下。

限制典型影響實務對策與憑證釘選衝突Web 會議原生客戶端、M365 部分通訊連線中斷或功能失常19解密排除（decode bypass）清單客戶端憑證認證該網站在解密下無法使用依目的地個別排除／直通解密處理負荷全縣流量延遲、頻寬壅塞設備增強、本地突破式連線QUIC／HTTP3傳統代理無法檢查、行為不穩定封鎖 UDP/443 促使降級，或更新至支援 HTTP/3 檢查的產品世代20首要對策是解密排除（decode bypass）清單的整備；廠商設定指南也示範了依目的地區分政策，停用特定目的地的 SSL inspection，以在資安與效能間取得平衡21。然而，管理排除清單等同於擴大「不檢查的通訊」，如何與資安雲的監控前提（日志蒐集、分析）一致說明，正是都道府縣最頭痛之處。更進一步的對策就是下一節的本地突破式連線（LBO），其思維是把「排除」轉換成「改變路徑」。

另一個實務上很重要的點，是排除清單的管理方式。排除會隨連線問題不斷增加，卻幾乎沒有刪除契機。它不能只當作連線對照表，而必須把每一筆都管理成「資安例外台帳」，具備 擁有者・排除依據・期限・替代對策（如日志取得），以便能盤點。否則，越是提高可視性，例外就越會悄悄堆積。

專欄：PQC 對應

在解密與憑證這個議題之後，還有另一個「下一個 10 年」的功課：後量子密碼（PQC）遷移。2026 年 7 月的重點計畫明確寫入將推動電子簽章等活用與 PQC 遷移相關工作，同年 6 月 G7 資安工作小組也發布了關於 PQC 遷移準備的共同聲明22。自治體網路裡，VPN、TLS、SSL 解密設備、客戶端憑證、LGWAN 與行政服務間的認證、電子簽章、HSM 與憑證機構、SASE/SSE 連線、長期運作的設備等，各層都埋有公開金鑰密碼學。重要的不是立刻購買支援 PQC 的產品，而是盤點目前使用的密碼演算法與憑證，並把可在不整體更換系統的情況下替換演算法的密碼敏捷性（cryptographic agility）納入下一次採購需求。NIST 也要求，應藉由 PQC 遷移，建立可在不中斷營運的情況下替換密碼的能力23。

3.4 與 Web 會議的相容問題與本地突破式連線（LBO）

Web 會議對三層分離＋都道府縣資安雲架構而言，是負載特性相當嚴苛的工作負載。若使用畫面轉送型的 VDI／虛擬瀏覽器，又未導入媒體最佳化，影音處理會集中在分離環境側，容易出現「接收媒體重新編碼＋畫面轉送」的雙重處理，造成延遲與品質下降。雖然現今已普及可將 Teams 等音訊／視訊處理卸載到終端的 VDI 媒體最佳化24，但最佳化的前提是終端可直接與媒體服務通訊；若 LGWAN 端終端不能直接上網，便無法原封不動套用。要套用就得開放終端的直接路徑，而這其實已是對分離的部分緩和。從路徑面來看，Web 會議與雲端儲存類流量也會壓迫集約閘道或代理，導致壅塞與延遲25。COVID-19 疫情期間 Web 會議與遠距辦公的大規模普及，廣泛暴露了這一弱點。

因此逐漸定著的是：只有 Web 會議與 Microsoft 365 類流量不經由都道府縣資安雲，而是從據點直接出網的本地突破式連線（LBO）。Microsoft 本身就針對 M365 的網路連線原則，建議應從接近使用者的位置本地出網，避免髮夾路徑與不必要的代理／封包檢查26，地方政府也長期援引這項理由來正當化 LBO。

實作上的重點有兩個。

• 與代理設定衝突：只要終端上有代理設定，即使在路徑中加入 LBO 設定，流量仍會走代理。基本手段是用 PAC 檔將該 SaaS 目的地設為代理排除27，但為了跟上目的 IP／網域頻繁變動，維運負擔很重。因 PAC 維運的極限，有些自治體已轉向可自動更新目的地清單的專用設備或雲端代理28
• 與模型論的關係：LBO 是對 α 模型邊界的局部放寬；事實上，在 2024 年 10 月 2 日的指南修訂（令和 6 年 10 月版）中，已正式規定 LGWAN 連線環境端終端可透過 LBO 直接使用特定雲端服務的網路架構，並命名為「α' 模型」29。α' 比 α 需要更高階的資安措施（服務範圍限定、存取控制、終端對策、日志、外部確認等），並已示範各案例的對策例。修訂檢討過程中，也提出若實施 α' 模型的技術性對策，其風險值與既有指南允許、在自治體資訊安全雲側進行 LBO 的情況沒有差異的風險評估結果30。可說是制度在事後為現場的 LBO 實態定義了框架。（此評價為筆者分析）

4. 10 年的評價

4.1 成果 —— 不依賴偵測的結構性防禦

總務省的檢討相關資料整理指出，三層對策在自治體中減少了惡意程式感染等資安事件31。

這項成果的結構性原因在於，切斷對外通訊路徑。三層對策透過原則上不讓 LGWAN 連線環境直接擁有通往網際網路的路徑，使得：

• 直接通訊型 C&C（攻擊者伺服器的 beacon 與遠端操控）
• 對外資料外傳（exfiltration）

都受到大幅限制。這可評價為一種不同於逐一偵測惡意程式的方法、屬於結構性防禦。更精確地說，這不是「不偵測」的防禦，而是不只依賴偵測，而是結合預防與封鎖：不追求把入侵歸零，而是限制攻擊者可使用的通訊路徑與執行環境。在過去 10 年中，當模式比對式偵測的侷限持續被指出時，這項價值應被正當承認。類型②的容器揮發性——即使感染也會因瀏覽器結束而連同容器一併銷毀——可視為把這種思想更進一步套用到分離環境內部。

另一方面，不能說成「即使感染也無法攻擊成立」。使用代理的惡意程式、濫用已允許的雲端服務、在內部網路中橫向移動、設定不當，以及 USB 等其他路徑，都必須另外考量。此外，勒索軟體的加密處理有時可在不需與外部交換金鑰的情況下執行。實際上已解析出把攻擊者公鑰內嵌在可執行檔中、無需 C&C 通訊即可對各檔案進行加密的勒索軟體32，而所謂雙重勒索中的資料竊取與加密也屬於不同工程33。因此，三層分離的效果不在於全面防止感染或加密，而在於限制攻擊者與外部通訊及資料外流的路徑。

若按攻擊類型整理其影響範圍，可如下所示。

攻擊・流程網際網路分離的效果補充直接通訊型 C2・遠端操控◯ 結構上較難成立作為出口對策有效對外資料外流◯ 大幅限制路徑但對已允許的雲端服務濫用仍會留下空間勒索軟體加密✕ 內嵌金鑰型不需外部通訊32資料竊取與加密是不同工程33可應對代理的惡意程式△ 必須配合有限監控與偵測 USB・維護線路・委外廠商經由的入侵✕ 不在防守範圍內詳見補講 B、C內部不當行為・內部橫向移動✕ 不在防守範圍內零信任與最小權限領域※ 另外，關於「與同期民間企業、醫療機構相比，自治體本體網路的受害是否相對較少」，目前尚未確認到可證明因果的全國橫斷公開統計，本文先將此保留為待驗證課題。

4.2 代價 —— 便利性、運用手續與持續費用

另一方面，自治體在約 10 年間持續支付下列代價。

• 業務效率：無害化的多段人工作業、畫面轉送的體感、Web 會議品質、每開一個 URL 都得經過分離環境的動線
• 運用負擔：VDI 基礎架構・虛擬瀏覽器伺服器的建置與維運、Windows 環境的雙重修補程式管理、PAC 檔與解密排除清單的維護
• 持續費用：虛擬化授權・RDS CAL・無害化引擎授權・資安雲負擔金持續累積。多數機關每約 5 年一輪更換週期就得重新投資
• 雲端適應延遲：雲端優先原則與遠距辦公的需求，始終與閉域前提的架構相衝突

為求公平，需保留以下前提：4.1 的防禦效果必須與下列限度一併評價：(1) 若在 β／β' 模型下將業務終端放在網際網路連線環境，前提即不同；(2) 如上所述，並非所有攻擊路徑都有效；(3) 在「守住了」的背後，仍持續支付適應成本。

5. 今後 —— 三層對策的檢討與零信任

政策方向是減少對實體三層分離、多台終端與 USB 交付的依賴，並逐步移行到導入零信任概念的國地共通網路。這並不表示要一律廢除邊界防禦或網路分離。先將模型譜系與未來樣貌的關係圖示如下。

其經緯可按時間序整理如下。

• 令和 2 年（2020 年）：總務省公布〈關於檢討自治體資訊安全對策〉。在維持三層基本架構的同時，提出將業務終端與系統配置於網際網路連線環境的 β 模型等34。同年 12 月的指南修訂中，實施了導入零信任概念的三層對策檢討2
• 2024 年 5 月：數位廳〈國・地方網路未來樣貌及實現情境檢討會〉報告書，作為 2030 年前後的未來樣貌，提出「靈活、安全、穩定提供行政服務」「國與地方共用網路基礎架構」「一人一台 PC 即可高效率工作，並能遠距辦公等彈性工作方式」三點35
• 2024 年 5 月 31 日：時任數位大臣河野在記者會上提及要停止三層對策，導入零信任架構概念的方針36。但重點放在解消伴隨「一人多台 PC」「以 USB 交付」的三層分離，並不意味著全面廢除邊界防禦。檢討會也整理出零信任與邊界型防禦並非必然矛盾，兩者可以併用37
• 2024 年 10 月 2 日：於指南修訂（令和 6 年 10 月版）中正式新增 α' 模型29。之後於令和 7 年 3 月及令和 8 年 3 月 27 日也持續修訂，並納入資安基本方針的制定與公告義務化（至 2026 年 4 月 1 日）等38
• 2026 年 3 月 31 日：公布「令和 7 年度 國・地方網路未來樣貌實現驗證事業」最終報告書。內容包括由自治體試用國側 GSS 的 GSS 試用型驗證（宮城縣・福井縣・山口縣） 與自治體提案型驗證（北海道、岐阜縣坂祝町、福岡縣北九州市、鹿兒島縣肝付町）結果35
• 2026 年 7 月 21 日：新的〈實現數位社會的重點計畫〉經閣議決定。明確寫入 2026 年度將由國主體驗證整備中的網路基礎共享之技術可行性，並自 2027 年度起逐步整備運作體制與移行環境。也納入了針對自治體導入零信任的指南修訂、參考手冊草案製作，以及高效率共同運作的檢討22

作為先行案例，三重縣從 α 模型變更為 β' 模型，並新增通訊工具的外部雲端化與零信任型資安對策的作法廣為人知39。此外，實務界也有報告指出，自 2025 年左右起，對三層分離檢討與諮詢的需求增加40。另有觀點指出，α'、β' 的移行應視為未來轉向零信任的過渡期對策，需預先擬定後續步驟的移行計畫41。

驗證事業所顯示的效果與遺留課題

2026 年 3 月 31 日公布的最終報告書（概要）顯示，不論是 GSS 試用型或自治體提案型，皆驗證了導入零信任概念的環境，並具體呈現其效果與課題35。

確認到的主要效果主要遺留課題可從一人一台 PC 直接存取先前實體分離的業務環境機敏資訊防外洩功能（DLP）的偵測準確度可減少 VDI 連線、多次登入、裝置切換、檔案轉送的麻煩能夠運作 ID 管理、資產管理、日誌監控的專業人力確保提升庁舍外或災害時的業務持續性既有應用、地端系統、專用終端的處理ID、終端、存取較容易一體化管理共用基礎與自治體的角色分工、故障時的切割——授權費、匯率、物價上升等持續成本值得注意的是，這項驗證並非「全面拆除分離」。在同一台終端上可使用多個環境，同時確認了將 My Number 使用事務系統、LGWAN 連線環境與網際網路連線環境以論理方式分離的架構，而北九州市等驗證則是在建構零信任環境的同時，於 My Number 使用事務系統保留既有的邊界型防禦35。移行期的真實樣貌不是「拋棄邊界防禦、全面換成零信任」，而是強化以 ID・終端為中心的控制，同時依資訊資產的機密性並用論理分離與邊界防禦的混合架構。

即使邊界設備消失，單一故障點也不會消失 —— 集中化的可用性風險

另一個應從驗證結果讀出的，就是可用性議題。傳統三層分離的主要故障點是代理、VDI、虛擬瀏覽器、檔案交付基礎設施。零信任型架構雖然讓其中一部分不再必要，但 IdP 與多因素驗證、終端管理與終端健全性判定、政策引擎、SSE/SASE 與存取代理、憑證／金鑰管理、DNS、日誌／風險判定基礎架構，以及雲端業者的管理平面，會成為所有業務共同依賴的對象。最終報告書概要也指出，由於運作一元化，自治體側可掌握的資訊變少，故障原因切分與復原變得複雜，並有必要明確化共用基礎的運作主體與自治體之角色分工35。

也就是說，零信任不是消除單一故障點，而是改變單一故障點的位置。從過去邊界設備故障就能阻斷通訊路徑的時代，轉向認證、終端判定與政策發佈故障，可能同時讓多個業務停擺的時代。下一期設計應明文化的，不是產品名稱，而是：IdP／政策基礎停擺時仍需維持的最低限度業務、緊急帳號與平時封印／稽核方法、與一般認證基礎分離的管理路徑、自治體側也要取得與保留的日誌與組態資訊、國家／共同運作主體／自治體／SaaS 業者的故障應對分工、假設 SaaS 停止、租戶設定錯誤、憑證到期、ID 同步失敗的演練，以及應以業務單位而非資安功能的稼動率來定義 RTO／RPO 與縮退運轉。NIST 於 2025 年正式化的實作指南（SP 1800-35）也以將零信任視為整合 ID、終端、SASE、微分段等的系統為前提42。

「國・地方網路未來樣貌實現驗證事業」也已利用補正預算延續至令和 8 年度。

2030 年不是「完成期限」，而是移行開始的目安

概要也提出分階段推進的路線：自 2026 年度起進行追加分析與參考手冊草案製作，自 2027 年度起具體化未來樣貌與整備環境，並於 2030 年度以後開始移行至未來樣貌35。這條路線已在 2026 年 7 月 21 日的重點計畫中納入政府年度計畫，從「構想」進一步走到「2026 年度的具體作業」22。因此，將 2030 年解讀為「全國同步完成的期限」並不恰當；較合理的理解是，待制度、共用基礎與移行模型都就緒後，才進入正式移行的起點。反過來說，對多數機關而言，下一到兩次的設備與授權更換，正好都會設計在這個移行期中。

就本文脈絡而言，值得關注的論點有 3 項。

1. 作為參考實作的 GSS：GSS 試用型驗證已在 3 縣實施並完成最終報告，代表「國家在共用基礎側會如何實作」已進入可讀的具體資料階段。作為推估未來「網路基礎共用化」「一人一台 PC」實現樣貌的一手資料，前一節已整理其概要中的效果與課題；接下來的分析對象將是本體資料（含自治體詳細意見與各縣專案資料）
2. 分離基礎的沉沒成本問題：本文所整理的分離基礎（VDI 基礎、虛擬瀏覽器伺服器、無害化授權）都是持續成本型資產。往 ZTA 方向移行時，與各機關更換週期的不一致，會直接把「三層分離的沉沒成本」攤在各機關面前。如何避免重演標準化、政府雲遷移時常見的「期限先行、現場追趕」結構，將是焦點（此評價為筆者分析）
3. 現實先行與制度追認：LBO 這類現場實態先行，並於 2024 年 10 月修訂時由 α' 模型後追式框住的經緯，暗示下一階段——β' 或零信任移行——也可能沿用同樣順序。模型正史與路徑實態之間的落差與收斂，應可透過比對各都道府縣資安雲第 3 期的採購規格書來驗證（此評價為筆者分析）

下一期更換時應先問的事

移行期的更換設計，已不再是從產品名稱決定架構的階段。至少在撰寫採購規格之前，應先把下列 8 個問題明文化（1～6 為驗證事業與本文摩擦點的反向整理，7～8 為筆者補充）。

1. 要保護的是哪些資訊資產 —— My Number、住民資訊、內部文件、公開資訊，不需要用相同控制方式對待
2. 哪裡是信任邊界 —— 要圖示出在網路、ID、終端、應用、資料、管理平面中，究竟以哪個層次作為控制點
3. 要阻止攻擊的哪個階段 —— 初始入侵、執行、權限提升、橫向移動、C2、資料外傳、加密、復原妨礙，需分別配置對策（4.1 的效果整理表可作為配置起點）
4. 職員的一次操作要變成幾個步驟 —— URL 瀏覽、檔案交付、Web 會議、遠距辦公的操作次數與等待時間應列為 KPI（3.2 的廢止 PPAP 動線是典型例子）
5. 例外由誰維護 —— PAC、解密排除、SaaS 目的地、租戶控制、非無害化對象格式，能否做成具所有者、依據與期限的例外台帳並自動更新／盤點（3.3）
6. 能否退場與移行 —— 多年度契約、資料外帶、設定移轉、日誌保全、授權終止時的替代方案都應設計進去
7. 能否把信任延伸到委外廠商 —— 包含要移轉資料的最小化、委外與維護路徑的可稽核性、再委託的掌握，應寫進規格（補講 C）
8. 能否持續量測 —— 第 4 點的 KPI 與第 5 點的台帳，不能只是更換時做一次的文件，而必須是每月更新的活文件；否則下一個 10 年仍會再度出現前線體感與表單脫節。國家的政府資訊系統自 2026 年 7 月起已開始導入統一指標來衡量使用者滿意度與便利性43，地方政府網路也需要建立持續衡量操作時間、等待時間、重處理率與滿意度的機制，而非只看導入了多少資安功能

這 8 個問題全都是在選產品之前就該先定義的需求問題。沒有答案的項目，才更應該成為下一次更換的 RFI 與廠商對話議題。

數位廳、總務省希望能給出松竹梅的基本模式

6. 總結

約 10 年的網際網路分離顯示：不依賴偵測的結構性防禦，對限制直接通訊型 C&C 與外部傳送確實有價值，但也伴隨便利性、運用手續與持續費用的負擔。真正影響實際使用體驗的，不只是方式差異，而是無害化與檔案交付（含廢止 PPAP 後的下載 URL 動線）、SSL 解密與例外管理、Web 會議與雲端服務的連線設計等。

今後，不會是一律廢除既有分離技術，而是在承接其防禦效果的同時，逐步改為結合零信任概念、終端管理、以 ID 為中心的存取控制，以及對雲端的直接連線。下一個 10 年的設計，重點是不要重演這 10 年為了資安而把業務動線複雜化過度的教訓。正如廢止 PPAP 所示，某一層的安全化若不連同寄件端、收件端與分離邊界一併觀察，就可能轉化成另一層的運維負債。而未來的信任邊界，將從網路與檔案轉向 API、服務 ID、資料欄位、事件，以及 AI Agent（補講 2、3）。下一個 10 年的問題，不再是「要不要分離」，而是 「要用哪些技術與運作方式，在何處、以多大程度自動化地保護哪一道信任邊界」。

補講1 —— 透過與鄰接領域比較來看網際網路分離

為了相對化三層分離的設計思想，以下比較同樣約 10 年內採用不同解法的兩個鄰接領域（教育、醫療），以及從分離「外側」逼近的新型風險（供應鏈）。

補講 A GIGA 校園構想 —— 先實行「停止分離」的鄰人

自治體之中，除了行政網路之外還有另一個大型網路：教育委員會、學校的網路。文部科學省〈教育資訊安全政策指南〉在 2017 年制定時，是以校務系與學習系網路分離為核心，可說是教育版的三層分離。其後修訂歷程十分有啟發性。2019 年修訂因應 GIGA 校園構想（1 人 1 台終端），2021 年修訂因應雲端優先原則並檢討學習系／校務系的分離原則，2022 年修訂則因應零信任模型趨勢，轉而建議以存取控制作為對策44。令和 6 年版更明確化了面向次世代校務 DX、以不需要網路分離的認證型存取控制為前提的理想架構45，並於 2025 年 3 月再次修訂以對應 Next GIGA46。

教育資訊安全政策指南主要重點2017 年 制定以校務系・學習系網路分離為核心（教育版三層分離）2019 年 修訂因應 GIGA 校園構想・1 人 1 台終端2021 年 修訂因應雲端優先原則，檢討學習系・校務系分離原則2022 年 修訂因應零信任趨勢，建議以存取控制作為對策令和 6 年版 明確化以不需要網路分離的認證型存取控制為前提的架構2025 年 3 月 修訂因應 Next GIGA教育領域能先行「解除分離」的背景，在於若要對數百萬台學生終端套用 VDI 型分離並不實際；再加上雲端前提的學習工具（Google Workspace / Microsoft 365 Education）已是既定條件，以及資訊性質的差異。然而不能簡單將其歸結為「因為機密性低所以可行」。校務系中包含成績、健康、家庭環境等敏感資訊，實際上即使是原本已分離的校務系，也曾出現不當存取或勒索軟體事件47。教育領域的轉向，並不是因為不存在機密資訊，而是在分離之外，選擇把資源投向多因素驗證、終端管制與監控，這是一種風險接受的設計判斷。

行政領域（三層對策）教育領域（GIGA 之後）基本方針維持網路分離轉向解除分離・存取控制終端規模員工數十～數千台／機關學生 1 人 1 台（全國數百萬台規模）前提工具從閉域・地端為出發點雲端服務是既定條件防禦重心路徑（邊界・出口）ID・終端・監控主要敏感資訊住民資訊・My Number成績・健康・家庭環境等考察：同一個自治體中，行政網路持續維持分離，而教育網路先行解除分離，構成一個約 10 年並行的「自然實驗」。對行政領域的零信任移行而言，教育領域是寶貴的前導案例，但其教訓不是「停止分離會更輕鬆」，而是「停止分離並不等於停止防護，而是把防護換成另一組投資，會重新拉起 ID 基礎架構、終端管理與監控」。行政領域的移行成本試算，理應可從教育領域的實績反推。

補講 B 醫療 DX（線上資格確認等）——「線的閉域」與「面的分離」

醫療領域是另一個與行政並行採閉域網路路線的領域。線上資格確認（2021 年開始運作、2023 年 4 月起原則義務化）透過厚生勞動省通知，將醫療機構與支援基金、國保中央會之間的路線限定為使用閉域 IP 網路的 IP-VPN 連線、ISDN 撥接，或結合 IPsec＋IKE 的網際網路連線，並以電子憑證做相互認證與加密保護48。電子處方箋等後續醫療 DX 施策，也建立在這套網路基礎之上。醫療機構端的規範由厚勞省〈醫療資訊系統安全管理指南〉第 6.0 版（令和 5 年 5 月）負責；其背景之一就是線上資格確認義務化後，許多醫療機構開始與外部保持常態連線，因此明示了邊界型防禦與零信任式思維的組合，以及即使在閉域網路中系統仍可能遭受入侵的前提49。

與自治體相比，結構上的差異在於統制的「面」與「線」。自治體的三層對策透過模型與指南規定庁內網路整體架構（面），並藉資安雲將出口集中化。醫療方面，國家所規定的是資格確認與申報請求這些連線（線）的閉域性；院內網路的面雖由指南提示概念，但並未以實際機制強制某一種架構模型。

自治體（三層對策）醫療（線上資格確認等）統制對象庁內網路整體（面）資格確認・請求的連線（線）規定手段強韌性提升模型＋指南厚勞省通知（線路種類）＋安全管理指南出口集中都道府縣資安雲支援基金・國保中央會的閉域網路組織內的架構模型實際上被規定各機關裁量（指南僅提示概念）實際被突破的地方委託業者等庁外（補講 C）維護用 VPN、委託業者這類「橫向」這項差異的結果，就是廣為報導的醫療機構勒索軟體事件。德島縣町立醫院（2021 年）、大阪的大型公立醫院（2022 年）等事件，侵入點都不是閉域連線的「線」，而是其旁邊——遠端維護用 VPN 裝置的漏洞，或餐食委託業者的連線——（※詳細請參照各醫院公開的調查報告書作為第一手資料）。有關醫療機構遭受資安攻擊時，VPN 裝置等外部連線設備的漏洞成為攻擊目標的案例眾多，這點在《指南 6.0 版》解說中也特別強調49。

考察：三層分離長期被批評為「對面的過度統制」，反過來說也意味著橫向漏洞較少。若從醫療的教訓回看行政，則在零信任移行中若要放鬆「面的統制」，就必須先把維護線路、委外廠商連線等橫向路徑管理做好，否則就會重蹈醫療的覆轍。另一方面，醫療 DX 只要愈來愈走向電子病歷資料共享服務等雲端化，也會面臨從閉域前提轉向以認證與資料保護為中心的壓力，這與行政是同型的課題。兩者不是相差 10 年的平行類似，而是從不同初始條件對同一問題的收斂。

補講 C 供應鏈風險對策強化 —— 從分離「外側」而來的風險

最後來看網際網路分離原本就未涵蓋的風險。政策上，令和 6 年 10 月的指南修訂將強化業務委外業者管理列為 4 大支柱之一29。全國層面也在推進：2025 年 5 月通過的《資安應對能力強化法》（正式名稱《關於防止對重要電子計算機之不正當行為造成損害之法律》，令和 7 年法律第 42 號，俗稱主動式資安防禦法）自 2026 年起分階段施行，對基礎設施業者的資產申報與事件通報義務，也會間接延伸到其供應鏈企業與 IT 委外廠商50。同時，新的資安戰略於 2025 年 12 月 23 日經閣議決定51，經濟產業省的 3 階段「資安對策評價制度（SCS 評價制度）」則於 2026 年 3 月 27 日確定制度建構方針，並進入以 2026 年度末左右開始受理申請（★3・★4）為目標的階段52，提升整體供應鏈對策水準已從討論轉入實作53。

施策・制度時期要點指南修訂（令和 6 年 10 月版）2024 年 10 月 4 大支柱之一為強化業務委外業者管理29《資安應對能力強化法》（令和 7 年法律第 42 號）2025 年 5 月成立・2026 年分階段施行基礎設施業者的資產申報・事件通報義務，並波及 IT 委外業者50新資安戰略2025 年 12 月 23 日經閣議決定脅威防止・抑止、提升社會整體韌性等5351資安對策評價制度（SCS 評價制度）2026 年 3 月 27 日確定制度建構方針。★3・★4 預定於 2026 年度末左右開始受理申請，★5 持續研議中。評價指南預定於 2026 年秋季公布以 3 階段評等提升供應鏈整體對策水準52資安基礎設施業者指南2026 年 3 月 31 日正式制定整理軟體開發、供應、運用業者與客戶的責任，以及採購時的確認項目在自治體層面最鮮明證實這項方針轉變的，就是 2024 年 5 月的 Iseto 事件。從事表單印刷與寄送等工作的單一受託業者遭受勒索軟體攻擊（8Base）55，最終導致約 307 萬人的個資外洩——其中僅行政機關等委託分就約 56.6 萬人——並波及德島縣、豐田市等多個自治體與金融機構56。三層分離與都道府縣資安雲，對於送到庁外的資料完全不具保護能力。這顯示，如果委外廠商本身的安全失守，自治體網路側的防護再堅固也會失效。結果很明確：今後調達與委外管理不能只管自己內部的分離設計，還必須把委外廠商的安全性、供應鏈可視性與再委託管理納入。

原文出處：https://qiita.com/k2_naka/items/0eceb428cb3f45bb7cfb