從Sakura Internet的入侵公告學到的事｜以「雲端業者被攻破」為前提來設計

大家好，我是株式會社TIMEWELL的濱本。2026年8月19日，日本的Sakura Internet公布了未經授權存取事件的第二報¹，同日也做了上市公司的重大訊息揭露。8月17日的第一報講的還是虛擬主機部分環境的事，到了第二報，範圍擴大到管理客戶契約資料與帳單資料的銷售管理系統，可能被波及的會員資料最多為1,360,563個帳號¹。

這篇文章不是要挑該公司的毛病。8月9日偵測到異常，8天後就發出第一報，調查還在進行中就再發續報、主動把影響範圍往上修正，這樣的處理方式，我認為值得肯定。把對自己不利的數字照實公布，對經營層來說從來都不是輕鬆的決定。所以這篇的題目不是「Sakura Internet哪裡做錯了」，而是「從已公布的事實裡，所有租用雲端的企業能帶走什麼」。

先劃一條線：入侵路徑、攻擊者、被利用的漏洞，目前都沒有公布。我不會用推測去填那塊空白。

先把兩起事件放在時間軸上分開看

先依照官方公告整理事實。以下寫的全部是已公布的內容，沒公布的地方我會明講「尚未公布」。

起點是2026年8月9日。該公司在自己管理的伺服器環境偵測到異常並展開調查，結果確認有第三方經由該公司的管理環境，存取了虛擬主機服務Sakura Rental Server部分用戶的環境²。到8月17日第一報的時間點，確認被非法登入的是583個帳號³⁴。此外也確認部分伺服器被攻擊者植入惡意程式，而且攻擊者處於可以存取用戶資料以及屬於通訊秘密之資訊（存放在伺服器區域內的資料與使用者識別碼）的狀態²。另一方面，Sakura Cloud、Sakura VPS、Sakura Dedicated Server PHY、高火力 PHY則未確認受到影響²。

接著8月19日的第二報，整件事的輪廓變了。管理契約者資料與帳單資料的銷售管理系統，被確認有遭到未經授權存取的可能，可能成為對象的會員資料總數為1,360,563個帳號¹。依媒體整理，對象欄位包含會員ID、公司名稱、部門名稱、地址、姓名、電話號碼、電子郵件、出生年月日、性別、傳真號碼、契約服務、契約期間、請款金額等⁵。部分客戶還確認有存取到經雜湊處理之密碼資料的可能。該公司不保存信用卡資料，且目前尚未確認資料被帶出外部¹。

我覺得最不該滑過去的，是時間軸上的那個扭曲。銷售管理系統遭到未經授權存取，是發生在偵測到虛擬主機入侵的8月9日「之前」，兩者是否相關仍在調查中¹。最先被發現的洞，不一定是最先被打開的洞。做過事件應變的人，大概能體會這句話背後的工作量。只處理偵測到的那一件就收工，很可能把更早開著的另一扇門留在原地。

該公司表示，已進行驗證資訊失效、惡意程式清除、系統監控強化、委外專業機構的數位鑑識調查、對受影響用戶個別通知，以及向相關機關報告與資訊共享²¹。同日的重大訊息揭露則指出，對2027年3月期合併業績的影響仍在確認中。把「已經確定的」與「還沒確定的」分開講，我認為是正確的順序。

想從供應鏈的角度多看一個案例的話，開發工具鏈遭汙染的GlassWorm那一篇也可以一起讀。

為什麼會發生：「管理面」是結構上的要害

以下是一般論。不是在說這次的入侵就是這樣，因為那並沒有公布。

雲端與共用主機，是由「用戶看得到的一面」與「只有業者碰得到的一面」兩層構成的。前者是資料面，後者是管理面。管理面集中了很強的權限：建立與停止客戶的伺服器、重新發送密碼、把備份取出來。這對攻擊者有多大吸引力，稍微想一下就知道。與其一台一台攻破用戶的伺服器，不如直接摸到把它們全部綁在一起的那一層，效率高得多。「集中起來成本就會下降」是雲端的原理，而「被攻破時損害也會集中」是同一個原理的另一面。

而當客戶環境是經由業者的管理面被抵達時，用戶自己把伺服器加固到什麼程度，那些努力都會被繞過。密碼設得再長沒有用，WordPress維持在最新版也沒有用，從管理面來的對手不吃這一套。這不是用戶的疏失，而是共同責任模型的結構本身。責任分界線另一側發生的事，這一側擋不住。這個道理多數人講得出來，但很少有公司把它反映在設計上。

這類攻擊也不是罕見情境。日本IPA的《資訊安全10大威脅 2026》組織篇裡，「鎖定供應鏈與委外對象的攻擊」連續4年排在第2名，第1名則是連續4年的勒索攻擊⁶。與其正面攻打防守嚴密的組織，不如從它已經信任的業者或委外廠商進去，這在攻擊方早已是標準做法。停在原地的，是我們這一側那個「業者不會被攻破」的設計前提。

還有一點我一直在意，是偵測的不對稱。發生在業者平台上的入侵，從用戶這邊幾乎看不到。盯著自家的存取日誌看，也照不出管理面上的可疑操作。正因如此，租用方能做的準備，重心必須從「擋下來」移到「被捲進去之後能不能靠自己站起來」。

租用方的法律義務，不會因為業者公告而消失

實務上最常被誤解的就是這一段。業者都公告外洩了，自己在旁邊看著就好——會這樣想很自然，但法律不是這樣寫的。

依日本個人資料保護法（個人情報保護法），當個人資料發生外洩等情形、且有損害個人權利利益之虞時，必須向個人資料保護委員會申報並通知當事人。申報分成速報與確報兩段：速報要在知悉後儘速提出，實務上大致在3至5天內；確報為30日內，若屬可能出於不正目的所為的外洩，則為60日內⁷。因未經授權存取而發生的外洩，不論筆數多寡都可能成為申報對象。

那麼，把自家客戶名單放在虛擬主機上的企業會怎樣？關鍵在於與該業者的關係是否構成「委託」。若屬於把個人資料處理委外的關係，受託方只要儘速通知委託方，自己的申報義務與當事人通知義務就免除⁸。反過來說，申報義務留在委託方，也就是留在自己身上。業者對外公告，跟自己向委員會申報，是兩件完全不同的事。

另一種情況是，契約上明定業者不處理所存放的個人資料，且有適當的存取控制，這時會被歸為所謂的雲端例外，既不算提供也不算委託。即使如此，租用方仍須以自身安全管理措施義務的一環，持續適當管理包含業者側在內的處理狀況⁹。個人資料保護委員會也在2024年3月，就雲端服務業者構成個人資料處理業者時的注意事項發出提醒⁹。「不是委託」不等於「不用負責」。

再補一條線。第一報裡出現了「屬於通訊秘密之資訊」這個說法²。依日本電信事業法，電信事業者在發生通訊秘密外洩時有向總務大臣報告的義務，發覺後應儘速提出第一報，並自知悉之日起30日內提出詳報¹⁰。如果自家公司有申報電信事業，這條線上的義務也可能落到自己身上。有在營運郵件發送或訊息功能的公司，建議找個時間確認一次自家的申報狀態。

這一段我只想講一件事：「租用」不等於「交出去」。作為資料主體責任方的義務，不會在資料寄放的那一刻跟著搬家。

以「業者會被攻破」為前提，這週就能重做的事

那具體要做什麼？不是防守的話題，而是被捲進別人的事件之後、能靠自己站起來的設計。以下是我排出的優先順序。

優先度	要做的事	具體確認方式
高	驗證資訊分離	服務管理後台的密碼有沒有跟其他服務共用？管理者帳號的多因素驗證是否全員都開了？離職者與前委外廠商的帳號是否還留著？
高	備份分離	備份是不是只放在同一家業者、同一個帳號底下？有沒有至少一份放在別家業者或離線的世代？
高	盤點寄放的資料	把各服務裡分別存有個人資料、驗證資訊、機密資訊的哪一種列成清單，讓申報義務能在平時就判斷得出來
中	金鑰分離	重要資料的加密金鑰是不是只在業者的管理之下？該服務是否支援客戶自管金鑰？
中	日誌的外部保全	稽核要用的日誌是不是只存在業者那一側？保存期間多長，事故當下自己取得出來嗎？
中	契約條款檢視	契約裡有沒有寫明事件發生時的通知期限、原因資訊的揭露範圍、稽核受理、再委外的可否？
低	可撤出性	資料能不能用可移轉的格式匯出？過去一年有沒有真的匯出來試過一次？
低	業者選擇基準書面化	選擇基準是不是只看「有沒有證書」，還是也看登錄範圍、準據法與管轄法院？

這8項，可以理解成把日本經濟產業省與IPA的《網路安全經營指引 Ver3.0》裡「含委外對象在內的對策」與「為事件發生預作的體制」，翻譯成雲端使用情境的版本¹¹。補充一下用法。

前3項這週就能開始動，而且是這次事件裡直接會生效的部分。驗證資訊分離常被當成雜務，但既然已公布可能存取到經雜湊處理的密碼資料¹，在其他服務重複使用同一組密碼的企業，今天就應該全部換掉。有雜湊代表攻擊者需要時間，而「需要時間」跟「安全」不是同義詞。

中段3項屬於設計，需要時間取得共識。其中我認為最常被漏掉的是日誌的外部保全。能不能確定被侵害的範圍，直接牽動申報義務的履行與對客戶的說明。偏偏在多數公司裡，能回答這些問題的日誌只存在於業者那一側。業者在調查期間，自己這邊什麼都說不出口。以我的經驗，真正讓客戶失去信任的是那段沉默，而不是事故本身。

契約條款的檢視，則是只有平時才做得到的工作。沒有寫通知期限的契約並不少見，沒寫的話，什麼時候被告知就取決於對方的判斷。既然自己可能得在3到5天內提出速報⁷，一份讓通知在兩週後才到的契約，本身就在危及自家的法遵。這一塊在資安教育裡幾乎沒人講，也是我們的WARP SECURITY課程把時間花在平時的設計與契約、而不是攻擊手法上的原因。

需要高資安水準時，優先選ISMAP登錄的服務，但一定要讀「範圍」

這是我最想傳達的部分。

替處理敏感資訊的系統挑選業者時，我會強烈建議優先考慮登錄於ISMAP的服務。ISMAP的正式名稱是「政府資訊系統資安評估制度」，會事先評估符合日本政府資安要求的雲端服務並登錄在清單上，由NISC、數位廳、總務省、經濟產業省4個單位共管，IPA負責營運支援¹²。依2020年1月網路安全戰略本部的決定，政府機關採購雲端時，原則上從登錄清單中採購¹²。

民間企業把它拿來當選擇基準，我認為價值有三點。

第一是更新的頻率。ISMAP雲端服務清單的登錄期間，是自作為登錄依據之稽核對象期間末日的次日起1年4個月¹²。換句話說，每年都得重做內部稽核與外部稽核，否則就會從清單上掉下來。比起拿過一次就能放著的證書，這個設計在實務上的意義大得多。

第二是把事件通報寫進了制度裡。登錄業者必須宣示：登錄期間內若發生可能對使用者造成重大影響的資安事件，將立即向ISMAP營運委員會報告¹²。外界會不會知道，不是只由業者自己判斷。

第三是制度已經替我們把該問的問題寫下來了。申請登錄時，業者必須提供資本關係與董監事等資訊、關於所處理資訊可能適用日本以外法令而被存取的風險資訊、契約所定的準據法與管轄法院，以及滲透測試與弱點檢測等第三方檢查的實施狀況¹²。這四項不管對方有沒有登錄ISMAP，都可以原封不動拿來當自家的業者問卷。登錄搬不過來，基準可以。

接著是兩個一定要加上的但書。

第一，ISMAP登錄不是安全保證。這不是我的意見，制度的官方說明就寫著：本制度的稽核作業「不提供結論的報告、也不提供保證」，並「與保證業務性質不同」¹²。沒有人在替這個服務蓋「安全」的章。被確認的是：針對業者自己聲明的控制措施，既定的程序確實被執行過。忽略這個差別，清單就會變成心理上的安慰毯。

第二，登錄是以服務為單位，而且會載明登錄範圍。這一點在這次可以看得很具體。以Sakura Internet來說，登錄ISMAP的是雲端服務Sakura Cloud，而該公司自家的手冊把登錄範圍寫到區域層級：東京區域第1、第2區與石狩區域第1、第2區，以及涵蓋的功能¹³。虛擬主機不在這個登錄範圍內。這裡要講清楚，這完全不是在批評該公司。共用的虛擬主機與為政府採購設計的IaaS，本來用途與價位就不同，登錄範圍不一樣是理所當然的。

要說的是讀法的問題。「那家公司有ISMAP登錄，所以沒問題」是一句關於公司的話，但只有關於服務的話才有意義。同一家業者裡，有的服務在範圍內、有的不在；同一個服務裡，有的區域在範圍內、有的不在。自己實際要部署的組態有沒有落在登錄範圍內，請用ISMAP官方的雲端服務清單，以及業者公開的登錄範圍去核對。

至於用在風險較小業務的SaaS，還有把外部稽核範圍縮減的ISMAP-LIU這個框架¹⁴。

結語：從「防止事故」的設計，走向「撐得住事故」的設計

再確認一次已公布的骨架。虛擬主機部分用戶環境遭到未經授權存取、583個帳號被非法登入、部分伺服器被植入惡意程式²；銷售管理系統可能遭到未經授權存取，可能成為對象的會員資料最多1,360,563個帳號¹。目前尚未確認資料被帶出外部，且不保存信用卡資料¹。入侵路徑與攻擊者尚未公布，本文寫到的攻擊結構全部是一般論。

我從這件事收到的訊息是：重心該從「防止事故」的設計，移到「撐得住事故」的設計了。挑業者的眼光當然要練，而在門檻夠高的場合，ISMAP是有效的尺。只是要記得，那是篩選，不是保證。再怎麼謹慎挑選，寄放的那一端被攻破的機率都不會歸零，而那一天要向自家客戶說明的責任，仍然留在自己身上。備份放在哪、日誌保全在哪、金鑰握在誰手上、契約寫的通知期限是幾天。四件很不起眼的事，卻是事發當天唯一有價值的四件事。

先從其中兩件開始：這週把備份與日誌保存期間確認一次。想討論業者選擇基準，或是把經營層一起拉進來的資安培訓要怎麼設計，歡迎從個別諮詢聯絡我們，我們會先聽狀況，再一起想。

參考資料

本文的事實依據以Sakura Internet的官方公告，以及ISMAP與日本各主管機關的一手資料為主，媒體報導僅作為輔助確認。

Footnotes

1. 關於本公司系統遭到未經授權存取的通知（第二報） — Sakura Internet Inc. — 2026年8月19日（日文） ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

2. 關於本公司虛擬主機服務部分環境遭到未經授權存取 — Sakura Internet Inc. — 2026年8月17日（日文） ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. Sakura Rental Server遭未經授權存取、確認583個帳號被非法登入（媒體、輔助參照） — INTERNET Watch — 2026年8月17日（日文） ↩

4. Sakura Rental Server遭未經授權存取、有個人資料外洩之虞（媒體、輔助參照） — ITmedia NEWS — 2026年8月17日（日文） ↩

5. Sakura Internet最多136萬個帳號可能受影響（媒體、輔助參照） — ASCII.jp — 2026年8月19日（日文） ↩

6. 資訊安全10大威脅 2026 — 日本獨立行政法人資訊處理推進機構（IPA）（日文） ↩

7. 外洩等申報與當事人通知的義務化 — 日本個人資料保護委員會（日文） ↩ ↩²

8. 受託方發生個人資料外洩時應如何因應 — 日本個人資料保護委員會（日文） ↩

9. 雲端服務業者構成個人資料處理業者時的注意事項（提醒） — 日本個人資料保護委員會 — 2024年3月25日（日文PDF） ↩ ↩²

10. 電信事業之通訊秘密外洩案件的報告 — 日本總務省（日文） ↩

11. 網路安全經營指引與支援工具 — 日本經濟產業省（日文） ↩

12. 政府資訊系統資安評估制度（ISMAP）概要 — NISC、數位廳、總務省、經濟產業省 — 2023年11月（日文PDF） ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

13. 政府資訊系統資安評估制度（ISMAP） — Sakura Cloud 操作手冊（日文） ↩

14. 關於ISMAP-LIU — NISC、數位廳、總務省、經濟產業省 — 2025年4月1日（日文PDF） ↩