網站與App的未經授權存取對策｜為經營者白話解讀政府13頁文件

大家好，我是TIMEWELL的濱本隆太。

昨天，也就是2026年11月5日，日本內閣官房的國家網路統括室公布了一份寫給業者的文件。標題是「關於可能導致個人資料外洩等的未經授權存取之對策」，副標題是「徹底落實網站與行動App的基本對策」。全文13頁，最後2頁是參考資料清單，所以正文是11頁¹。

我讀完的感想是，內容非常到位，但第一次讀的經營者，大概會覺得像一份密碼。光是1頁裡，就接連出現「SBOM」「攻擊面」「BOLA」「SSRF」「SOAR」這些英文縮寫。對專職人員來說，這是「該寫的都寫了」的資料，對其他人來說，卻看不出自己該做什麼。

所以這篇文章會依序讀完這13頁，盡量把專業術語換成日常的比喻。我會寫給經營者看，說明每項對策是為了什麼，以及該向承辦人員和委外廠商問什麼。文章很長，但涵蓋了這份資料的全部頁面。

本文重點

• 政府確認的原因不是新手法，而是基本對策不足。文件列出的包括：開發App時的對策不足、網站的設定疏失，以及繼續使用已停止支援或沒有修補的軟體。
• 文件的對策有三大支柱。營運管理（掌握自己擁有什麼、減少入口）、設計開發（從製作階段就做得安全）、供應鏈（不放著委外廠商和外部元件不管）。
• 資料的結尾，要求經營高層親自主導，依系統的特性與持有的資訊來做風險評估。不要全丟給承辦人員，這是對經營者最重要的訊息。
• 文件不是「待辦清單」而是在談「想法」的部分，就是經營者要決定的範圍。修補期限、可以公開的標準、對委外廠商的要求水準，都不是技術問題，而是經營判斷。
• 不必一次全做。盤點自家入口、關閉不需要的入口、為管理功能加上多因素驗證。這3件事，從這週就能開始。

先掌握的詞彙

為了讀懂這份資料，先用表格整理出發點的幾個詞。其他縮寫，會在出現的地方隨時說明。

詞彙	用日常比喻來說
漏洞（脆弱性）	像門鎖的設計失誤，是軟體的弱點。被發現後，軟體的開發者會發布修好的版本（修補程式）
攻擊面	建築物的出入口和窗戶的數量。沒在使用的後門和窗戶越多，能被闖入的地方就越多
OSS、函式庫	借用別人做好的元件來組裝軟體的作法。就像做菜時用現成的醬料和調味料
API	連接App與後端伺服器的窗口，像餐廳的點餐櫃台。App送出訂單，伺服器負責回應
後端伺服器	網站或App背後的廚房與倉庫，負責確認登入、保管會員資料
供應鏈	不只自家公司，還包含受託開發、維護系統的委外廠商，以及所用元件在內的整條關係鏈

政府要求了什麼，又是對誰要求

第1頁寫了什麼

第1頁是整份文件的前言，政府的問題意識都在這裡。

政府說，在近來接連發生的未經授權存取導致資料外洩的案件中，確認有多起疑似出於下列原因：製作行動App時的資安對策不足、網站的設定疏失、繼續使用已停止支援的軟體，或是明知有已知弱點卻沒有處理的軟體。而且這些情況，不只發生在自家公司，也發生在受託開發、營運系統的委外廠商¹。

每一項聽起來都理所當然。不是被新的攻擊手法突破，而是基本功沒有做到。這是政府的看法，也是副標題寫「徹底落實基本對策」的原因。

文件也寫了攻擊者的行動方式。攻擊者針對公開在網際網路上的日本網站等，進行大規模的探查，再闖進查到有入侵方法的網站，竊取個人資料，說明是這樣。打個比方，就像一個小偷在整個城鎮的人家門上一個個轉門把，只闖進沒上鎖的那幾戶。

文件接著指出，攻擊者在調查目標與入侵時，使用AI的可能性也很高。另外還提到，有些案例中，過去的漏洞檢測評為「相對較低」的風險，組合起來卻可能成為入侵的原因。單獨看每個都是小洞，三個疊在一起，人就能走過去。

還有一句很重要的話。由於攻擊的規模化變得容易，不論事業規模大小，廣泛的業者都可能成為攻擊對象。「我們是小公司，不會被盯上」這句話，在這份文件裡是行不通的。

這份文件的定位

在這份文件之前，10月是警示接連發出的一個月。個人資料保護委員會在10月7日，JPCERT協調中心在10月8日，國家網路統括室與總務省都在10月9日，分別就未經授權存取發出警示。10月13日，日本情報通信研究機構（NICT）的威脅情資分析團隊，又發出詳細解說攻擊手法的警示²。

我認為這次的文件，是在這個脈絡上，把對象縮小到經營網站與行動App、處理個人資料的業者，並且提出具體的對策範例。

文件本身並不是新設法律義務，形式上是「請徹底落實對策」的呼籲。不過，文件在後半自己寫了：委託他人處理個人資料時，依個人資料保護法第25條，必須對委外廠商進行必要且適當的監督¹。呼籲的部分，和法律義務的部分，需要分開來理解。

給經營層看的部分，和給承辦人員看的部分

第1頁的最後有閱讀說明。給經營層在內的組織內廣泛讀者，以正文的「柱書」整理了對策的基本想法與背景。給IT系統與資安的承辦人員，則用方框圈出具體的對策範例。

也就是說，各項目開頭的文字是經營者讀的，方框裡是承辦人員的作業清單。本文也照同樣的分工來寫。先寫經營者該掌握的想法，再把方框裡的對策範例，換成能看出目的的說法。

13頁的地圖

先標示每一頁對應本文的哪一節。

頁數	內容	本文的章節
1	前言（背景與閱讀方式）	政府要求了什麼，又是對誰要求
2〜3	1的(1) 掌握數位資產並消除漏洞	支柱1的(1)
3〜4	1的(2) 盤點並縮減攻擊面	支柱1的(2)
4〜6	1的(3) 運用AI持續檢測與監控	支柱1的(3)
6〜7	2的(1) 資安設計（Security by Design）	支柱2的(1)
7〜8	2的(2) 所使用API的對策	支柱2的(2)
8〜9	2的(3) 公開前的漏洞檢測	支柱2的(3)
9〜10	3的(1) 管控委外廠商與連線路徑	支柱3的(1)
10〜11	3的(2) OSS與外部函式庫的管理	支柱3的(2)
11	結語的要求（經營高層的判斷）	經營者該決定什麼，又該問什麼
12〜13	參考資料與基準清單	參考

支柱1　在營運管理階段，持續減少入口

第一個支柱，談的是系統開始運作之後的事。不是做完就結束，而是在運作期間要持續進行的3項對策。

(1) 掌握自己擁有什麼，並補好漏洞（第2〜3頁）

文件首先指出，在未經授權存取導致外洩的案件中，網頁應用程式所用的函式庫與框架裡的漏洞被人利用。文件還說，特別是能透過網際網路從遠端利用的漏洞，可能成為入侵公司內部的跳板¹。

這裡我想讓經營者知道的是，軟體的漏洞，不是在「購買的那天」就決定的。導入時沒人注意到的漏洞，可能在開始運作之後才被發現並公布。而且，不只是自己直接買的產品，嵌在產品裡的開源元件也會出現漏洞。

舉個例子，市售零食用的某一種原料發生了回收。如果廠商無法馬上查出哪些產品用了這種原料，就沒辦法開始回收。軟體也一樣，必須處於能立刻回答「我們的系統裡有沒有那個有問題的元件」的狀態。文件要求「持續掌握，同時蒐集新公布的資訊，建立能迅速判斷對自家組織的影響並處理的體制」，原因就在這裡。

還有優先順序。文件寫到，從網際網路任何人都能連線的伺服器與網路設備，被利用的風險高，要優先處理。

給承辦人員的對策範例有4項。依序說明各自的目的。

對策範例1：掌握並管理軟體的組成資訊。 針對所用的OS、中介軟體、框架、函式庫，記錄產品名稱、版本，以及用在哪裡。文件列出能自動產生這份紀錄的工具，是「SBOM（軟體物料清單）」與「SCA（軟體組成分析）」。SBOM就像零食原料標示的軟體版，是列出哪些元件以哪個版本放在裡面的清單，日本經濟產業省已公布導入手冊³。SCA則是自動產生那份清單，並與已知漏洞比對的工具。文件特別提醒，SBOM不是做完就好，必須把與漏洞資訊的比對、影響範圍的確認、修補或暫行對策，當成一連串的營運來確保。

對策範例2：持續蒐集漏洞資訊，並確認影響。 文件也具體寫出資訊要從哪裡取得。美國CISA公開的「KEV」，是已確認被實際利用的漏洞清單⁴。漏洞有好幾萬件，但現在真正被拿來用的是這些，是這樣一份名冊，所以用法是先確認上面列的漏洞，會不會對應到自家的軟體。此外，各產品開發者的公告、美國的NVD，以及日本的JVN（由JPCERT協調中心與IPA共同營運的漏洞資料庫），也列為資訊來源⁵。光靠人工追不完，所以文件也寫到，必要時可使用自動偵測漏洞的管理工具。

對策範例3：事先決定處理的優先順序與期限。 每次公布漏洞才討論「先修哪個」，是來不及的。文件要求事先訂好評估標準，看這4點：漏洞的嚴重程度、是否正被實際利用、是否能透過網際網路利用，以及該系統的重要性和對事業的影響。

這個對策範例3，我認為是經營者自己該決定的部分。例如「已確認被實際利用的，要在幾天內修好」這種期限，和「要不要停掉系統也得修」的事業判斷是一體的。如果由承辦人員一個人決定，容易被「不想停機」的現場狀況牽著走。

對策範例4：緩解措施，以及修好之後的確認。 也有無法馬上套用修補程式的情況。這時就看產品開發者發出的注意資訊，採取暫行措施，例如停掉受影響的功能、限縮能存取的人。套用之後，也要確認是否真的有效，並持續管理剩下的漏洞。尤其是已經確認被利用的漏洞，文件寫到，要查閱相關日誌（log），連是不是已經被入侵過都要調查。

最後這句話容易被忽略。重點不是「修好了就安心」，而是確認「修好之前有沒有被入侵」。從漏洞被公布到修補完成的這段時間，攻擊者可能已經進來了。

(2) 數清楚從外部看得到的入口，並減少它們（第3〜4頁）

第二個項目，談的是攻擊面，也就是從外部看得到的入口。

文件指出，在未經授權存取導致外洩的案件中，有些原因是不必要的功能或服務暴露在外部。具體來說，有的案例是公開在網際網路上的系統管理畫面，被人利用容易猜到的密碼、暴力破解、繞過驗證弱點等方式入侵。另外也確認到，原本不打算對外公開的除錯功能和系統管理窗口，從網際網路就能連到¹。

除錯功能，是開發期間為了找出問題而做的、可以窺看內部的後門。開發時很方便，但公開時忘了關，就會直接變成一扇外人能進來的便門。

文件在這裡強調的是，「不需要的入口，會給攻擊者新的入侵路徑和竊取資料的機會」。多一扇後門，要守的地方就多一處。入口越少越好守。這在建築物和系統上都一樣。

給承辦人員的對策範例有3項。

對策範例1：盤點入口。 從網路的組態資訊、雲端設定、資產清冊中，找出對網際網路公開的IP位址、網域名稱、服務、通訊埠、網頁應用程式與API。再用「ASM（攻擊面管理）」這種工具，從公司外部找出能觀測到的資產，與公司內部的管理表比對。ASM可以想成是從外面看自己的公司，數出「原來有這種後門」的作業。經濟產業省已發布導入指引⁶。比對之後，會發現管理表漏掉的資產，或是非刻意公開的項目。對找到的項目，要確認管理負責人、用途、是否有公開的必要，並持續管理。

對策範例2：停用不需要對外公開的功能。 在應用程式這一側，檢查管理畫面、除錯用窗口、開發與測試環境、資料庫管理功能，是否能從外部連到。尤其要確認，流量分流的設定對於沒設想到的路徑會怎麼回應。目的是驗證本來不該公開的功能，外部連不到。不需要的功能就停用或關閉，管理上必要的功能，則用存取來源限制加上多因素驗證來保護。

多因素驗證，是在「密碼」之外，再要求另一種證明，例如手機的確認碼。就像除了鑰匙還要輸入密碼，即使密碼外洩，也不會馬上被進入。

在網路與雲端這一側，檢查對網際網路的公開範圍與存取限制的設定。例如雲端儲存空間（資料存放處）的公開設定、防火牆是否放行了不必要的通訊、網頁伺服器是否在非刻意的情況下公開了檔案。發現設定疏失，就用取消公開、重新檢視權限等方式修正，修正後再從外部確認存取，驗證是否真的關上了。

對策範例3：持續監控從外部看得到的狀態。 在建立新系統、變更系統、更改設定時，都可能產生新的入口或非刻意的公開。所以檢查不是做一次就結束，而是要持續進行。與過去的檢查結果和清冊比對，偵測沒掌握到的資產和公開狀態的變化，發現後要迅速修正。

(3) 也運用AI，持續檢查與監看（第4〜6頁）

第三個項目，是建置並公開之後的「監看」。

文件確認，不只是建置時的對策，開始營運後也要持續檢測與檢查，找出漏洞與設定疏失，並透過監控日誌察覺可疑的動作，及早發現入侵的徵兆並處理，這些一直被視為重要。在這個基礎上，文件擔心攻擊會運用AI而更高度化、更有效率。

這是這份文件最新的論點。除了持續強化既有的對策，文件指出，既然攻擊方使用AI，防禦方也應積極考慮運用AI。不過附有條件，必須充分驗證有效性、適用範圍與營運上的風險，才能導入。

關於檢測的頻率，還有一個指摘。不只是網站或行動App公開前，在涉及驗證、授權、API、個人資料處理等重要變更時，以及開始營運之後，也要依風險持續進行檢測、檢查與稽核，修補找到的漏洞並確認結果。這是對「公開前檢測一次就結束」這種營運方式的警告。

給承辦人員的對策範例有3項。

對策範例1：持續檢測與檢查。 針對網頁應用程式、API、網路設備、雲端環境，定期進行漏洞檢測與滲透測試（像真正的攻擊者一樣嘗試入侵的測試），重要變更時也要檢測。另外也考慮運用AI檢測工具。據說在探索攻擊路徑、製作測試、確認漏洞、分析影響、協助排定處理優先順序方面，可以提升效率。不過文件明確寫了，AI的評估結果要確認依據與合理性，最終的處理判斷由人來做。

對策範例2：持續監控日誌與動作。 建立取得並監控網頁伺服器、API入口、驗證基礎設施、雲端服務等日誌的體制。這裡出現3個縮寫。SOC（資安維運中心）相當於警衛室，是監控的據點與體制。SIEM是把各處日誌蒐集起來互相比對的機制，像是把監視器畫面集中起來看的警衛螢幕。EDR是監看電腦與伺服器內部可疑動作的軟體。用這些持續監控可疑的驗證、權限的不當使用、大量資料的取得。文件也寫到，要積極考慮運用AI，橫向分析大量的日誌與警報，偵測異常徵兆、將多個事件串聯起來，並排定調查順序。

對策範例3：加快調查與初步應變。 發現可疑動作或入侵徵兆時，要能迅速調查相關日誌與系統狀態，確認有沒有被未經授權存取以及影響範圍，並建立這樣的體制。SOAR是把調查與應對步驟自動化的機制，就像讓系統記住警衛的初步應對手冊。以AI彙整警報、蒐集與分析相關資訊、提出應對步驟，也列為考慮對象。這部分同樣寫到，要考慮誤判對事業的影響，在適當驗證與人員監督下進行。

3項共通的態度是，AI會協助承辦人員，但不會把最後的判斷交給它。我也覺得這很合理。如果完全交給AI，發生誤判而停掉了不能停的系統，就會變成經營上的損失。

支柱2　在設計開發階段，從一開始就做得安全

第二個支柱，談的是製作系統的階段。文件指出，從近來網路攻擊的趨勢來看，行動App、網頁的前端，以及背後的伺服器，多半不一定是以安全為前提的想法來設計的。

(1) 資安設計（Security by Design）（第6〜7頁）

「資安設計」是指，不是事後再來守，而是從一開始就做得安全的想法。拿建築物來比喻，就是不等蓋好再補逃生門和防火牆，而是在設計圖階段就放進去。

文件寫到，如果在發布後才發現漏洞或設定疏失，事後修正的費用，會比在設計階段預防大幅增加。此外也指出，可能導致重大事故或資料外洩。所以文件要求，從需求定義階段到營運的全部工序，都要把資安放進去⁷。

給承辦人員的對策範例有3項。

對策範例1：在需求定義與設計階段，思考安全的作法。 文件列出「威脅建模」這項作業。就是在設計階段，找出這個系統可能被誰、怎麼攻擊，哪些入口會被盯上。在這個基礎上，決定驗證與授權、加密、日誌紀錄、存取控制等安全相關的需求。文件也寫到，要從設計開始考慮：把管理與維運功能，設計成不會不小心暴露在網際網路上的網路架構，以及依據「零信任」想法的存取控制。零信任，是不再因為「在公司內部就信任」，而是無論誰要存取什麼，每次都確認的想法。

另外也提到，除了在網路上區隔應用程式、資料庫與維運管理功能，還要依系統的重要性與風險，考慮連雲端帳號等管理邊界一併分開。想法是，即使一處被突破，也不會波及全部。

設計基準中，還要放進「非功能需求」。這是指不會出現在畫面和功能規格中的驗證、可用性（不會停擺）、日誌、監控、故障時的應對、備份、資料保護等需求。委託方與承製方之間，如果對這些的認知有落差，就容易變成「功能能跑，但防護是空的」，所以文件要求，從需求定義階段起，明確各個採購、開發、驗收、營運階段要確認的項目。

對策範例2：製作階段的自動檢查（SAST、SCA）。 SAST是不執行程式、直接讀原始碼，找出危險寫法的自動檢查。文件說，可以持續掌握危險函式的使用、違反安全編碼的情形，以及所用OSS與函式庫中的已知漏洞。SCA是前面出現過的、檢查元件漏洞的工具。必要時也使用SBOM。拿料理來比喻，就像烹調途中確認「這個食材有沒有壞」的驗貨。

對策範例3：測試階段的自動檢查（DAST、IAST）。 DAST是對實際運作的應用程式，像攻擊者一樣從外部送出請求，找出漏洞的檢查。IAST是在應用程式運作中，從內部一邊互動一邊檢查的方式。針對授權疏失、輸入值檢查不足、登入狀態管理缺失等，用自動分析找出來，必要時也用人工確認，在發布前修好。必要時，可以把這類檢查納入「CI/CD」（把製作並發布軟體的流程自動化的機制），在整個開發期間持續確認安全。

(2) 加固所使用的API（第7〜8頁）

這裡可說是這份文件的核心。文件指出，在未經授權存取導致外洩的案件中，確認有些原因是經由網頁應用程式或行動App所用API的不當操作，並舉出NICT提出警示的「A2B攻擊」為例¹。

A2B是「App-to-Backend」，也就是從App攻擊背後的伺服器。依NICT威脅情資分析團隊的警示，攻擊者會先取得已公開的App並加以分析，調查App所連線的後端伺服器的連線目標、API的組成、通訊用的參數等。接著依據蒐集到的資訊，配合每台伺服器的組態和API的規格，組合出攻擊，鎖定漏洞。已確認的手法，是取得並分析在Google Play日本地區公開的Android App²。

用餐廳來比喻吧。客人使用的是菜單（App）。但小偷把菜單仔細讀透，查出「這家店把點餐送進廚房的櫃台（API）在這裡，點餐的寫法是這樣」。然後不用菜單，直接對櫃台送出動過手腳的訂單，想把廚房和倉庫裡的東西（個人資料）拿出來。

NICT的警示中，重要的是下面這段話。在這種攻擊中，即使App本身沒有漏洞，只要後端的API在驗證、授權、輸入值檢查等方面有缺失，就可能導致個人資料外洩或未經授權存取。而且，要完全防止已公開的App被分析，是很困難的。重要的是，即使App的內容和API的規格被攻擊者知道了，也要做出並營運能維持後端伺服器安全的系統²。

NICT列出主要被鎖定的4種漏洞。SSRF（讓伺服器做出本來不打算做的通訊的漏洞）、RCE（從外部送來的指令，會在伺服器上被執行的漏洞）、SQL注入（透過輸入，讓資料庫執行不當指令的漏洞）、IDOR（只要改掉使用者的識別編號，就能看到別人資料的漏洞）。IDOR比喻起來，就像飯店的房卡，只改一個號碼就能打開隔壁房間的狀態。這4種，在下一節的「公開前的檢測」也會再出現。

順帶一提，這類案件我們已經看過了。2026年10月15日，Sourcenext公布，因取得會員資料的API遭到未經授權存取，最多可能有2,251萬9,960筆資訊外流。我們的文章，把已公布的事實和仍不清楚的部分分開，整理了API的防護方式。這起事件的原因是否與這次NICT警示的手法相同，目前還無法確認。也請一併閱讀從Sourcenext事件學到的，會員資料API的防護方式。

文件在API的防護上，指出落實穩固的驗證與授權、嚴格的輸入值檢查、安全地管理驗證資訊、偵測並控制異常存取，是很重要的。給承辦人員的對策範例有3項。

對策範例1：消除授權疏失。 授權是確認「那個人能不能做那項操作」。這和驗證（確認本人）是兩回事，也是最容易被漏看的地方。即使是登入的本人，也不能讓他看到別人的資訊。文件要求，API的請求所要求的功能與資料，要在伺服器端確認使用者是否具有正當的權限，並實作依據「最小權限原則」的存取控制。最小權限原則，是只給工作所需最低限度權限的想法。授權疏失有「BOLA（物件層級的授權疏失）」與「BFLA（功能層級的授權疏失）」2種。BOLA與前面說的IDOR是同一類，是能碰到別人資料的缺失。BFLA則是一般使用者能使用管理者功能的缺失。這兩種，都被OWASP這個全球性的非營利組織，整理為API的重大漏洞⁸。

對策範例2：安全地管理驗證資訊。 API金鑰、存取權杖、私密金鑰、資料庫的連線資訊，等於是備用鑰匙。如果直接寫進原始碼或App裡，原始碼外洩或App被分析時，就會被偷走。就像把密碼寫在招牌上貼出來。文件要求，備用鑰匙不寫進原始碼，伺服器端用叫做「密鑰管理器（Secret Manager）」的鑰匙保管庫機制管理。備用鑰匙只給必要的最小權限，訂出有效期限，並定期更換。開發流程中，在提交到原始碼管理處時，以及CI/CD的流程中，也要建立機制，以機器檢查（密鑰掃描）有沒有不小心混進備用鑰匙。

對策範例3：以API的次數限制，防止濫用。 API會成為自動化工具的目標，用來逐一嘗試密碼的暴力破解，或蒐集資訊。所以在短時間內送來大量請求時，要限制受理。就像櫃台的號碼牌，規定「1分鐘受理幾人」。特別是登入與重設密碼，是容易被盯上的功能。文件寫到，不只是來自同一個IP位址或同一個帳號的，也包含來自多個IP位址的分散式存取，要建立機制，依成功與失敗的狀況、存取頻率來偵測異常⁹。

(3) 公開之前，先檢測漏洞（第8〜9頁）

第三項，像是開店前的預覽會。文件指出，利用SQL注入、OS指令注入、遠端程式碼執行（RCE）、伺服器端請求偽造（SSRF）、目錄遍歷等漏洞的攻擊，已經造成資料外洩。名稱雖然艱澀，但全都是「從外部送來的輸入或請求動手腳，讓伺服器做出預期之外的事」這一類的漏洞。

因此，處理個人資料的網頁應用程式與網頁系統，在發布前要進行漏洞檢測與滲透測試，事先找出潛在的漏洞並修好，這很重要。文件寫到，要先明確檢測的目的與範圍，適當修補找到的漏洞，確認結果之後，才公開到正式環境。

有2點不能忽略。第一點是檢測的對象。不只是產品與平台上已知的漏洞，自家公司或委外廠商所開發的、網頁App與行動App背後功能所特有的設計與實作上的漏洞，也必須列為檢測與修正的對象。只檢查市售軟體，找不到自家特有開發內容的漏洞。第二點是，網頁應用程式的技術驗證項目，依對象系統的特性與風險來決定範圍很重要。不是一律全部項目都做，而是配合自家系統來決定。決定範圍的國際基準，參考資料中列了OWASP的ASVS¹⁰。

給承辦人員的對策範例有2項。

對策範例1：決定資安的基準。 做檢測時，事先決定「風險到什麼程度可以接受」的水準，並建立依此判斷能不能發布的營運方式。例如，看漏洞的嚴重程度、被利用的難易度、系統的重要性來訂基準，並決定只要還留有一定以上的風險，就不公開到正式環境。對於檢測結果，明確修補的負責人與期限，建立不讓修補遺漏的機制。

這也和經營者有關。遇到「發布日快到了，但漏洞還沒修完」時，由誰來決定公開或延期。沒有那個標準，每次現場都會夾在交期和資安之間。我認為，決定這個標準是經營的工作，不是技術的工作。

對策範例2：適當選擇第三方檢測業者。 把檢測委外時，要考量對象系統的特性與使用的技術，選擇有充分技術能力與實績的業者。尤其要確認在網頁應用程式、API、行動App檢測上的實績、手法與體制。此外，文件也提到要選擇提供符合「資訊安全服務基準」之服務的業者。被認定符合這個基準的業者，會登錄在審查登錄制度的「資訊安全服務名冊」。再來，不只是自動檢測，還要確認是否有人工驗證，以及是否考慮業務流程（商業邏輯）進行檢測，這點很重要。例如「能不當增加點數」這種該公司業務特有的破口，自動檢查不容易發現。

支柱3　防範經由供應鏈的入侵

第三個支柱，談的是自家公司之外的事。對於把網站與App的開發、維護委外的公司，這是特別重要的部分。

(1) 管控委外廠商，並加固連線路徑（第9〜10頁）

文件指出，已確認有以業務委外廠商或維護業者的環境為跳板，入侵委託方系統的案件。特別是委外廠商所用的遠端連線環境，對攻擊者來說，可能成為「使用正當驗證資訊的入侵口」。

文件在這裡放了很重的一句話。即使是這種情況，服務中斷或資料外洩造成的影響，仍由身為委託方的業者自己承擔。就算委外廠商成了未經授權存取的入口，從客戶的角度看，造成損害的是委託方的公司。這不是把責任推給委外廠商就能了結的事。

在法律上，委託他人處理個人資料時，依個人資料保護法第25條，要求對委外廠商進行必要且適當的監督¹¹。文件要求，把包含委外廠商在內的整條供應鏈，都列為管理、管控的對象，以對委外廠商的治理（governance），以及連線路徑的多層防禦兩個面向來考慮對策。

同時，文件也提醒委託方。向委外廠商要求對策時，要就費用的負擔與實施方式充分協商，並留意不要利用交易上的強勢地位，單方面把負擔硬塞給對方¹²。只喊「去做」，委外廠商籌不出費用，對策就會流於形式。連誰出錢都談清楚，是對策能發揮效果的條件。

給承辦人員的對策範例有3項。

對策範例1：保護來自委外廠商的連線路徑與帳號。 找出委外廠商所用的VPN、遠端桌面、維護用線路等連線路徑，並套用多因素驗證。文件很務實地寫到：從重要度高的路徑開始，有計畫地切換；難以套用多因素驗證的路徑，則採取限制連線來源的IP位址、只在作業時才開通連線、取得作業紀錄等替代手段。然後，盤點作業已結束的委外廠商帳號，以及一直被給予的管理者權限，予以停用或縮減。

對策範例2：在合約與採購中，明確資安需求。 在採購的規格書或業務委外合約中，除了保密義務，也寫入再委託的程序、發生事件時的通報義務與聯絡窗口、合約結束時的資料刪除等需求。選擇委外廠商時，要運用第三方認證，或經濟產業省的「強化供應鏈資安措施評價制度（SCS評價制度）」等客觀評價。

SCS評價制度，是用統一的「★（星）」來表示交易對象資安對策水準的制度。依IPA的說明，★3是依自我評估、由專家確認的方式，有效期間為1年；★4是由評價機構進行實地審查與技術驗證的第三方評價，有效期間為3年。★5仍在研議中。登錄申請預定在2027年3月開始受理。取得星級是自願的，是否作為交易條件，由雙方決定¹³。由於制度尚未開始，不是現在就能用，但有可能成為挑選交易對象時的共通標準。

對策範例3：以零信任的想法控制存取。 擺脫只靠邊界型VPN、「一旦連上，就能進入公司內部網路的大範圍」的狀態。針對每位委外廠商的作業人員，限定只能從被允許的裝置，連到必要的伺服器或功能。就像拿員工證能進建築物，但進每個房間還要另外的許可。IPA已公開零信任的導入指南¹⁴。

(2) 不要在不知道內容的情況下使用開源與外部函式庫（第10〜11頁）

開發系統時，無法避免使用OSS和外部函式庫。另一方面，文件指出，嚴重的漏洞一公布，攻擊者可能在短時間內找出並加以利用。因此，必須避免在不知道內容的情況下，繼續使用外部元件。這個項目的要求是，讓元件看得見，並建立能迅速處理的體制。

給承辦人員的對策範例有2項。

對策範例1：事先訂好公布嚴重漏洞時的初步應變步驟。 文件設想的，是針對尚未提供修補的漏洞（零時差漏洞）發出警示，或公布嚴重漏洞，需要緊急應對的場面。因此，不要全交給維護業者，而是要求事先決定能迅速判斷的步驟。

具體來說，針對委外開發、維護的自家主要系統，平時就掌握所嵌入OSS的版本和停止支援（EOL）的狀況。依公開資訊，與委外廠商合作，迅速比對對自家系統有沒有影響。決定負責調查影響的人、與委外廠商的分工，以及向經營層報告的標準。然後，也事先訂好判斷暫行對策的步驟，例如套用修補程式，或是用WAF（網頁應用程式防火牆，擋下對網站不當通訊的防護牆）等進行防禦，或停用相關功能。

這個「向經營層報告的標準」，是我希望經營者務必親自重新檢視的項目。漏洞被公布的那天，發生什麼事情時，才會有報告送到社長手上。標準模糊，就會讓現場判斷為「沒什麼大不了」的資訊，一直停在原地。

對策範例2：要求委外開發提交SBOM，並加以確認。 委外開發或改版時，在合約或規格中規定，要明列所用的軟體元件並提交SBOM。驗收時，把提交的SBOM與設計書比對，確認有沒有已知漏洞或授權違規。交付之後，也要用SCA等工具，建立持續監控新公布漏洞的體制。重點在於，不是交貨就結束，而是連交貨之後才出現的漏洞，也要看著。

第11頁的結語，以及第12〜13頁的參考資料

第11頁的最後，有一段相當於整份文件總結的文字。先聲明到這裡的對策，是聚焦在近來一連串攻擊手法上，接著說明對於鎖定VPN等暴露在網際網路上的網路設備漏洞的攻擊、針對性的電子郵件攻擊、DDoS攻擊（用大量存取讓服務停擺的攻擊）等手法，甚至AI的濫用可能更加高度化、巧妙化，都需要設想並採取對策。

最後，文件這樣作結。考量網路攻擊的影響，可能發展成經營上的風險，請在經營高層的判斷下，依所營運系統的特性與持有的資訊內容，進行風險評估之後，強化必要的資安對策¹。

這個結語，是整份文件的關鍵。就算給承辦人員的對策範例有幾十項，也不是要求全部都做。依自家系統與持有資訊來評估風險、排定優先順序，是經營高層的工作，文件是這樣說的。

第12〜13頁是參考資料清單。包括經濟產業省的SBOM導入手冊、ASM導入指引，IPA的「安全的網站營運管理20條」與「電商網站建置、營運資安指引」、「資安設計導入指南」，數位廳的指引，NICT的警示，OWASP的API資安十大風險，個人資料保護委員會的指引，IPA的中小企業指引中的規範範本等。卷末還附上針對政府機關與關鍵基礎設施的資安對策統一基準，作為「關於基本對策的基準」。經營者不必全部讀完，但向承辦人員和委外廠商詢問「有沒有參考這份資料」時，它是共通的語言。特別是中小企業的朋友如果要先翻一份，IPA的「安全的網站營運管理20條」當作入口會比較好用¹⁵。

經營者該決定什麼，又該問什麼

從這裡開始，是依據文件內容所做的我個人的整理。先聲明，這不是政府文件本身。

經營者要自己決定的3件事

不該全交給承辦人員的，不是技術細節，而是下面3項判斷。

第一是修補的期限。已確認被實際利用的漏洞，要在幾天內修好。無法停機的時段，系統怎麼辦。由承辦人員一個人決定，會被現場的狀況牽著走。

第二是可以公開與否的標準。檢測發現漏洞時，到什麼水準就延後公開。發布日和安全哪個優先，要事先決定好。

第三是報告的標準。公布嚴重漏洞時，發生什麼事就要向經營層報告。報告送上來之後，幾小時內要召開判斷的會議。

該向承辦人員與委外廠商問的10個問題

請把下面的問題，丟給承辦人員和委外廠商。答不出來的地方，就是自家公司比較弱的地方。

問題	對應的文件項目
有沒有一份對網際網路公開的服務與管理畫面清單	支柱1的(2)
沒在使用的功能、開發環境、測試環境，是否處於外部連得到的狀態	支柱1的(2)
漏洞被公布時，對自家系統有沒有影響，幾小時內答得出來嗎	支柱1的(1)
是否還在使用已停止支援的軟體	支柱1的(1)
管理畫面與雲端的管理功能，有沒有加上多因素驗證	支柱1的(2)、支柱3的(1)
有保存日誌嗎？可疑的動作由誰察覺	支柱1的(3)
對App背後的API，有沒有確認過碰不到別人的資料	支柱2的(2)
公開前的檢測，有沒有檢查到自家特有的開發內容	支柱2的(3)
委外廠商的連線路徑有多因素驗證嗎？作業結束的帳號有刪除嗎	支柱3的(1)
委外開發時，有要求交付所用元件的清單（SBOM）嗎	支柱3的(2)

規模小的公司，從哪裡開始

文件要求依風險排定優先順序。在這個前提下，我要寫的是，對人力與預算有限的中小企業，我建議的順序。這不是文件所列的順序，而是我的想法。

最先做的是數入口。把自家對外的網站、App、管理畫面、雲端存放處，都寫出來。不花錢，而且問委外廠商常常就能知道。數過之後，才會發現「原來公開了這種東西」。

接著關掉不需要的入口。沒在使用的管理畫面、舊的測試環境、以前活動用的頁面，找到當天就可以停掉。如果覺得停掉可能會造成困擾，光是先讓外部看不到，也有效果。

第三是為管理功能加上多因素驗證。管理畫面、雲端的管理者帳號、委外廠商的遠端連線是優先項目。這裡被突破，災情會一口氣擴大。

之後，決定修補的期限，並請委外廠商就連線路徑與API的授權，以書面回答。檢測與監控這類要花錢的對策，看過這次盤點的結果，再決定用在哪裡，就不會浪費。

不確定自家公司現況的時候，也可以從衡量公司內部理解程度的入口開始，例如日本的AI素養診斷工具。另外，實際發生事故時怎麼行動，我整理在網路事件初步應變的文章；電腦與端點這一側的準備，則在給中小企業的檢查清單。此外，漏洞被公布時該如何營運，我在PHP重大漏洞的文章中，有具體整理。

結語

讀完這份文件，我最強烈的感受，不是內容有多新，而是「把理所當然的事持續做下去，有多難」。數清楚自己擁有什麼。關掉不需要的入口。該修的就修。不要全丟給委外廠商。每一項，說出來都沒人會反對。

即使如此事故仍然不斷，我想是因為這些事不是「做一次就結束」，而是系統每次變動、人員每次異動，都得重做的工作。加了新功能，入口就增加；元件更新，漏洞就增加；換了委外廠商，連線路徑就改變。而且承辦人員越忙，這類事越容易被往後放。

正因如此，才需要經營者參與，我想這就是文件最後一句話的意義。修補的期限、公開的標準、報告的規則，如果由承辦人員一個人來定，會被現場的忙碌推著走。決定的是經營者，動手的是現場。請在這週內，確認一下這樣的分工。

如果還有時間，請和承辦人員一起，花1個小時數一數自家公司的入口。應該會找到意想不到的東西。

如果對公司內部的營運規則怎麼整備，或與委外廠商如何溝通有疑問，我們的WARP SECURITY也可以列入考慮。比起解說攻擊手法，這套訓練把時間花在平時的準備上，例如公司內部的核准，以及事件被發現時的判斷。歡迎從個別諮詢與我們聯絡。

參考

Footnotes

1. 日本內閣官房國家網路統括室「關於可能導致個人資料外洩等的未經授權存取之對策 ～徹底落實網站與行動App的基本對策～」2026年11月5日（給業者的文件，共13頁）。本文的事實敘述，除非另有註明，皆依據這份文件。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. 日本國立研究開發法人情報通信研究機構（NICT）威脅情資分析團隊LETTICE「【警示】接連發生的資料外洩，原因之一是『從App分析發動的伺服器攻擊』」2026年10月13日。參考文獻欄列有個人資料保護委員會（10月7日）、JPCERT/CC（10月8日）、國家網路統括室（10月9日）、總務省（10月9日）的警示。PDF ↩ ↩² ↩³

3. 日本經濟產業省「軟體管理用 SBOM（Software Bill of Materials）導入手冊 ver2.0」2024年8月。經濟產業省 ↩

4. 美國CISA「Known Exploited Vulnerabilities Catalog（已知被利用漏洞目錄）」。CISA ↩

5. 由JPCERT協調中心與IPA共同營運的漏洞對策資訊資料庫「JVN」。JVN ↩

6. 日本經濟產業省「ASM（Attack Surface Management）導入指引 ～運用外部可掌握的資訊，發現並管理自家組織的IT資產～」2023年5月。經濟產業省 ↩

7. IPA「資安設計（Security by Design）導入指南」。IPA ↩

8. OWASP「API Security Top 10 2023 API1 Broken Object Level Authorization」。OWASP ↩

9. OWASP「API Security Top 10 2023 API4 Unrestricted Resource Consumption」。OWASP ↩

10. OWASP「Application Security Verification Standard（ASVS）」。OWASP ↩

11. 日本個人資料保護委員會「關於個人資料保護法的指引（通則篇）」（委外廠商的監督）。個人資料保護委員會 ↩

12. 日本經濟產業省、公平交易委員會「為提升整體供應鏈的網路安全，建立與交易對象的夥伴關係」。經濟產業省 ↩

13. IPA「SCS評價制度 常見問題」。★3、★4的方式與有效期間、登錄申請的受理開始時期（預定2027年3月）、★5仍在研議中，皆依該頁面的記載。IPA ↩

14. IPA「零信任導入指南～對資訊系統與控制系統導入零信任～」。IPA ↩

15. IPA「安全的網站營運管理20條」。IPA ↩