從日本接連發生的入侵事件學到的事（上）｜AI加速的攻擊與身分證明文件的保管

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

光是2026年9月的最後一週，日本的Times Car、京王電鐵集團、Nippon Rent-A-Car、東京地下鐵、eplus、Seicomart就接連公告遭到未經授權存取或網路攻擊。往前推到6月，還有KDDI、日本Aflac人壽、Nichirei、Murauchi.com、日本數位廳和Gyazo。鐵路、保險、電信、食品、零售、政府機關，產業和規模各不相同。看到這份名單，還能斷言「我們公司不會有事」的企業，老實說應該不多。

先說清楚我的立場。這篇文章不是要責怪受害的組織。在調查途中就把已知與未知分開公告、逐一通知當事人、設立諮詢窗口，每一件都費工夫，也可能傷及商譽。即使如此，各家還是選擇公開。正因為他們沒有隱瞞，其他組織才有東西可以學。這樣的態度，我是肯定的。

本文重點（截至2026年9月30日）

• 把2026年6月到9月在日本公告的12起事件，只依官方公告的範圍整理成表。9月下旬公告的案件，多數還沒公開入侵途徑與手法
• 公部門統計顯示，主要入侵口集中在VPN設備、遠端桌面、已公開卻未修補的漏洞，以及容易被猜到的密碼
• AI與其說讓攻擊變成別的東西，不如說讓攻擊變快、變多。AI的API金鑰與AI代理的權限，正在成為新的攻擊目標
• 身分證明文件可以用「不保存」到「到期刪除」五個層級來思考。加密要等到金鑰與資料分開管理，才真正發揮作用

個人電腦與端點的防護，以及中小企業該從哪裡開始，留到下篇。

依官方公告整理2026年的12起事件

下表只依各公司、各機關官方公告寫到的範圍整理（截至2026年9月30日，依首次公告日排序）。原因一欄盡量貼近官方的說法，官方寫「調查中」的就維持調查中。媒體的推測與攻擊者名稱一律不列入。

首次公告日	組織與系統	資料種類與筆數	官方說明的原因	主要因應
6月23日	KDDI（提供給網路服務業者的郵件系統）	電子郵件地址12,231,954人，其中含密碼7,616,173人	系統中採用的第三方軟體漏洞（KDDI發現時，軟體廠商也尚未掌握）	修改系統、導入EDR（端點監控與偵測）、數位鑑識、強制變更密碼1
6月30日	日本Aflac人壽（保險代理商使用的線上諮詢工具與保戶專屬網站）	約440萬人（其中約22萬人含帳戶資料）、約4萬家保險代理商	對攻擊所用的存取與查詢手法控管不足，也缺乏對短時間大量查詢的監控與限制	停止系統、向日本金融廳報告、以書面逐一通知、與金融機構合作2
7月13日	Nichirei（集團伺服器）	配送收件人、往來廠商人員、員工等三類共53,866筆（筆者加總）	網路攻擊（為防止損害擴大，不公開細節）	隔離系統、成立緊急應變小組、向個人資料保護委員會報告、7月24日所有據點恢復正常營運34
7月24日	Murauchi.com（從部分網站系統擴及多個系統）	7,716,811筆（姓名、地址、電話、電子郵件等）	以網站系統部分漏洞為起點，進而存取多個系統	切斷外部連線、向個人資料保護委員會報告、向警方諮詢、逐一寄信通知5
9月11日	日本數位廳（政府共用辦公環境GSS）	職員等約24.6萬筆（不含一般民眾資料）	攻擊前已公開的VPN設備漏洞，在修補程式套用前遭利用	停用帳號、切斷連線、套用修補、向個人資料保護委員會報告、逐一通知6
9月16日	Helpfeel（圖片分享服務Gyazo）	使用者相關資料約2,362萬筆，另有圖片中繼資料	利用圖片上傳伺服器的漏洞執行任意指令	阻斷並修補、向個人資料保護委員會與總務省報告、暫停服務後於9月27日恢復78
9月25日	Times Mobility（汽車共享服務Times Car的網站系統）	約660萬個帳號，其中約160萬個帳號的身分證明文件影像外洩	調查中（由外部專業機構進行數位鑑識）	阻斷入侵途徑、向個人資料保護委員會與警方報告、逐一通知、24小時窗口91011
9月26日	京王電鐵集團（集團伺服器）	截至9月26日尚未確認資料外洩	勒索軟體攻擊，入侵途徑調查中	隔離網路、報警、與外部專家共同調查12
9月26日	Nippon Rent-A-Car Service（租車應用程式）	41人；登錄駕照的會員，駕照號碼、地址、出生日期也可能被瀏覽	未說明（持續調查）	逐一通知並請會員重設密碼、向個人資料保護委員會報告、向警方諮詢13
9月27日	東京地下鐵（Metpo會員服務的伺服器）	已停止寄送的電子郵件地址約59,000筆（可能遭瀏覽或取得）	調查中	找出受害位置並採取對策、寄信通知當事人、專用窗口14
9月29日	eplus（管理電子票券退款資料的系統）	1,463筆（其中751筆含退款匯入帳戶資料）	研判為第三者的未經授權存取（未說明手法）	調整設定阻斷存取、全面重新檢查系統、向個人資料保護委員會報告、準備向警方報案15
9月29日	Seicomart（經由應用程式伺服器進入會員資料伺服器）	約57萬個帳號（可能遭瀏覽）	調查中	切斷與該伺服器的連線、暫停加入會員與登入等功能16

最醒目的是「調查中」的比例。9月下旬公告的6起事件，沒有一起說明到入侵途徑或手法。數位鑑識（從紀錄還原入侵痕跡的調查）本來就需要時間。與其等到原因全部查清才開口，不如先把已知的部分說出來，當事人也能早一步提高警覺。

Times Car在9月25日上午9點07分偵測到入侵，當天就發出第一則公告⁹。28日公布帳號數與外洩項目，29日公布身分證明文件影像的件數與種類¹⁰¹¹。4天發了3則。日本Aflac人壽在7月31日的報告中，連「攻擊的存取形式與一般使用相同，因此未能立即偵測」「雖然做過設計審查與上線前的滲透測試，卻沒有預想到這次的手法」都寫了出來²。把自己的弱點白紙黑字寫下來，並不容易。

各家對使用者的呼籲幾乎一樣：小心冒充本公司的電子郵件、簡訊與電話，本公司不會詢問您的密碼。這不是制式的提醒。外洩的姓名與電子郵件地址，正是下一波釣魚的材料。

看數字，入侵口其實大同小異

個別事件或許還在調查，統計的趨勢卻很清楚。日本個人資料保護委員會（負責個資保護的主管機關）的2025會計年度（2025年4月至2026年3月）年報指出，業者提出的個資外洩等通報共17,139件，其中屬於「可能出於不正當目的」類型、也就是未經授權存取等攻擊造成的，有3,822件¹⁷。委員會從指導過的案件歸納出三個常見原因：VPN設備或電商網站用程式的漏洞已經公開、修補方式也已釋出，卻被擱置；帳號密碼容易被猜到；設定錯誤導致資料庫的存取控制不當。三者都被歸為安全管理措施的缺失。

日本警察廳的2026年上半年網路威脅報告顯示，2026年1月到6月通報的勒索軟體受害有123件，是2020年下半年開始統計以來單一半年的最高紀錄¹⁸。依規模區分，中小企業有79件，換算約64.2%（筆者計算）。在回答入侵途徑的36個受害組織中，VPN設備18件（50%）、遠端桌面9件（25%）。36件的樣本偏少，要打點折扣來看，但2025年全年也有92件中的61件來自VPN設備。

日本資訊處理推進機構（IPA）的「資訊安全十大威脅2026」組織篇，第1名是勒索軟體攻擊造成的損害，第2名是鎖定供應鏈或委外廠商的攻擊，第3名則首度出現「AI使用相關的網路風險」¹⁹。第4名是利用系統漏洞的攻擊。

為了避免誤解，補充一句：個人資料保護委員會列出的原因，是全日本通報案件的整體趨勢，不代表表中各家都是如此。KDDI遇到的是連軟體廠商都不知道的漏洞；日本數位廳也說明，漏洞是在他們以比一般標準更快的速度處理時遭到利用的⁶。數位廳的案例，我在從日本數位廳GSS遭入侵學到的事一文有詳細整理。不過，在已說明原因的案件中，KDDI、Murauchi.com、日本數位廳、Gyazo這4起都指向漏洞是起點，與「入口多半是能從外部觸及的設備或伺服器弱點」的統計趨勢一致。

AI代理演進後升高的風險

攻擊的手工作業開始交給AI

AI業者會以當事者身分，公開自家AI遭濫用的案例。

Anthropic在2025年11月公布，一個被該公司評估為受國家支持的集團，利用其AI程式開發工具嘗試入侵約30個組織，並在少數組織得手²⁰。攻擊的80%到90%由AI執行，人類只在每次行動中約4到6個關鍵節點做判斷。同一份報告也提到AI的侷限，例如偶爾會捏造根本不存在的帳密。2025年8月的報告則描述一起針對至少17個組織的資料勒索，偵察、蒐集帳密、入侵網路都由AI自動化，勒索金額有時超過50萬美元²¹。

2026年9月的報告裡，有一句話我希望每個IT部門都讀到：以遭竊的API金鑰、工作階段權杖（維持登入狀態的資訊）和裝置為形式的「AI存取權本身」，正逐漸成為多個犯罪集團的唯一目的²²。報告建議，AI金鑰與代理的串接，應該用和正式環境帳密同等的嚴肅態度看待，因為攻擊者就是這樣看待的。員工在工作中越常用AI，這些帳號與金鑰就越像公司的萬用鑰匙。

但它不是魔法新武器

只讀這些報告，可能會以為AI把攻擊變成了完全不同的東西。不過，公部門和其他AI業者的評估冷靜得多。Google Threat Intelligence Group在2026年2月寫道，至今尚未觀察到國家支持的攻擊者等取得「從根本改變威脅態勢的突破性能力」²³。OpenAI在2025年10月的報告中也分析，攻擊者是把AI嵌入既有的工作流程，而不是圍繞AI打造新流程，並表示沒有發現新戰術，也沒有證據顯示模型帶給攻擊者新的攻擊能力²⁴。IPA的十大威脅2026解說書指出，除了鎖定AI特有弱點的間接提示詞注入之外，大部分案例只是傳統的網路攻擊被AI半自動化、加速而已，因此傳統的資安對策仍然有效²⁵。

我認為這兩種看法並不矛盾。攻擊的內容還是老樣子：利用漏洞、拿偷來的帳密登入、騙人點擊。改變的是速度、數量，以及一個攻擊者能完成的工作範圍。既然如此，防守方的答案就不是「買AI來對抗AI」。把更新、驗證、權限、備份這些基本功，做到跟得上對方速度的程度，效果大得多。

AI代理本身成為目標

另一個變化是，企業導入的AI代理（AI agent）本身也成了攻擊目標與跳板。既然它會自己讀信、登入內部系統、修改資料，就會像擁有同樣權限的員工一樣被盯上。

日本經濟產業省在2026年9月18日，召開了「企業安全運用AI代理」小組的第一次會議²⁶。會議的說明資料把間接提示詞注入、竊取AI帳號與API金鑰列為針對AI的攻擊，並把AI代理的風險因素整理成12項。其中包括：被惡意指令或外部資料誘導的「指令與輸入遭汙染」、工具或權限給得太大的「工具與權限的缺陷或濫用」、錯誤或攻擊在人類反應之前就被大量高速執行的「高速大量執行導致損害擴大」，以及確認流於形式的「人工監督與核准形同虛設」。成果預定在日本2026會計年度內公布，目前的資料仍是討論中的整理。

國際上的框架也指向同一方向。OWASP把「過度代理（Excessive Agency）」列為LLM應用程式的風險之一，根本原因是功能、權限、自主性給得太多²⁷。2025年12月發表的AI代理十大風險中，目標劫持、工具濫用、身分與權限濫用名列前茅²⁸。

你的AI代理被允許做什麼？用誰的權限在跑？按下「核准」的人，真的有看內容嗎？如果公司裡沒有人能立刻回答這三個問題，那就是第一個要處理的地方。

「冒充本公司的訊息」越來越難分辨

最後回到表中各家都呼籲過的網路釣魚。日本反網路釣魚協議會的資料顯示，2025年的釣魚通報達2,454,297件，創歷史新高，約為前一年的1.43倍²⁹。該協議會的指引指出，生成式AI能寫出自然的日文，已經很難靠不自然的用字來辨識，單靠提醒已不足以防止受害³⁰。從2024年秋天起，冒充銀行打電話給企業的「語音釣魚」也在增加。

IPA在2026年8月發布的資料，說明了兩種不必偷密碼也能進得去的手法³¹。一種是假網站在使用者與真網站之間轉送通訊，讓使用者完成多因素驗證後，再竊取代表已登入狀態的工作階段Cookie。另一種是資訊竊取惡意程式把瀏覽器等處儲存的帳號密碼偷走，這些帳密在攻擊者之間買賣，進而引發勒索軟體或其他入侵。

外洩的姓名與電子郵件地址，再搭配生成式AI潤飾過的自然文字，「冒充本公司的訊息」就更難分辨了。

身分證明文件該怎麼保管：以Times Car的公告為起點

已公告的事實

根據Times Car的第三則公告，身分證明文件影像外洩的帳號約有160萬個¹¹。已確認的有四種：駕照影像、現居地址證明影像（例如水電瓦斯帳單）、學生證影像（學生方案）、家屬證明影像（家庭方案）。第二則公告把「駕照資訊」列為外洩項目，但截至9月30日，內容（例如駕照號碼、有效期限）尚未公開¹⁰。該公司表示約兩週後會再個別說明細節，原因仍在調查中。

另一方面，密碼是以「無法還原的形式」保存，公司表示並未發現密碼本身以可讀狀態外洩¹⁰。這是設計降低了損害的例子，值得記下來。

以下並不是在討論Times Car實際上怎麼保管。保管方式沒有公開，也不該用猜的。請把它當成「如果自家公司處理身分證明文件，要做到哪裡」的一般性思考。台灣也有不少服務會請使用者上傳證件照片，道理相同。涉及日本法令的部分同樣是一般說明，個別情況請與專業人士確認。

法令要求的紀錄，與業者蒐集的影像

在日本，汽車共享是以租車的形式取得許可。業者記錄駕駛人駕照的依據之一，是日本國土交通省關於租車的行政通知³²。這份通知要求業者以書面或電子紀錄備置出租登記簿，記載駕駛人的姓名、地址、駕照種類與駕照號碼等，並自出租結束日起保存2年。租車型的汽車共享也在這個框架內。另一方面，就通知本文來看，找不到要求保存駕照影像或影本的文字。

Times Car的出租條款規定，申請入會時要出示駕照等證件（網路申請包含以電子方式傳送），並同意業者複製³³。駕照更新時，也要提交新駕照的影本或影像資料等。換句話說，保存影像與其說是法令直接要求，不如說是業者在出租條款中訂定的作法。

我並不是說蒐集影像是錯的。把無人看管的車借給會員的業務，確實需要確認申請人是不是本人、駕照有沒有偽造、有沒有過期，影像是很實際的手段。只是，法令要求記錄的內容和實際留在手上的資料之間若有落差，這段落差為什麼要留、要留多久，最好能說得清楚。日本《個人資料保護法》第22條要求業者在不再需要個人資料時，盡力及時刪除（屬於盡力義務而非強制規定；其他法令另訂保存期間時除外）³⁴。

用五個層級思考保管方式

身分證明文件的保管，不是「加密或不加密」的二選一。我認為用下面五個層級來思考，比較貼近實務。層級越上面，外洩時失去的越少；越往下，越需要靠營運紀律來補。

層級	保管方式	外洩時會流出的東西
1	不保存。讀取證件的IC晶片，只留下「已確認」的結果與時間	確認紀錄
2	只保存法令要求的號碼與確認結果，確認完成後刪除影像	號碼與確認結果
3	若必須保存影像，就與會員資料分開存放，並限縮能看的人與路徑	連分開的儲存區也被攻破時的影像
4	由應用程式逐欄加密，金鑰存放在與資料不同的地方	除非金鑰也被偷，否則是讀不懂的資料
5	訂出保存期限，到期就刪除	只有期限內的部分

實務上應該是以層級1或2為目標，只有真的需要影像的流程才組合層級3和4，而層級5套用到所有資料。OWASP關於加密儲存的指引也說，保護敏感資訊最好的方法，就是一開始就不要儲存³⁵。層級3的「分開」，是指不要把影像放在會員資料庫的同一處，避免一台伺服器被攻破，顧客資料和證件影像就一起被拿走。

層級4的金鑰管理，常見的作法是「信封加密」：用資料加密金鑰（DEK）加密資料，再用金鑰加密金鑰（KEK）加密DEK，而KEK放在雲端的金鑰管理服務或硬體安全模組（HSM）。OWASP要求金鑰盡可能與加密資料分開存放，KEK也必須與DEK分開保管³⁵。日本IPA也公開了密碼金鑰管理系統的設計指引³⁶。

只靠「靜態加密」守不住的情況

「我們的資料庫有加密」這句話很常聽到。多半指的是磁碟或資料庫層的靜態加密，但它有效的情境其實有限。

OWASP指出，要在哪一層加密取決於威脅模型，並舉例說硬體層的加密能防範伺服器實體遭竊，但如果攻擊者能從遠端入侵伺服器，就起不了保護作用³⁵。NIST的SP 800-111說明，全磁碟加密在開機前的驗證通過後，就會視需要透明地解密與加密資料³⁷。兩者合起來看，磁碟或資料庫的加密，是防止被偷走的設備或媒體遭讀取的對策。一旦有人進入運作中的伺服器，經由正常路徑取出資料，資料就會以解密後的狀態流出。這是我的理解。

所以層級4的意義，在於由應用程式逐欄加密，並嚴格限縮誰、經由哪條路徑可以解密。例如只有身分確認的專用畫面能打開影像、每次解密都留下紀錄、短時間內大量解密就自動擋下。日本Aflac人壽把「強化對大量存取的監控與控制」列入防止再次發生的措施，也是同樣的思路²。

日本法令中「高度加密」的條件

在日本，加密也有法律上的意義。依日本《個人資料保護法》，可能出於未經授權存取等不正當目的的外洩，或當事人超過1,000人的外洩等，必須向個人資料保護委員會通報。不過，若外洩的資料已採取「高度加密等保護個人權益所需的措施」，就不需要通報³⁴。

條件寫在委員會的Q&A（Q6-19）³⁸。一是依外洩當時的技術水準，第三者難以讀取；二是使用日本電子政府推薦密碼清單或ISO/IEC 18033等所列的密碼技術，並正確實作；三是讓資料恢復可讀的手段，也就是金鑰，受到妥善管理。金鑰管理至少要符合以下之一：把加密資料與解密金鑰分開並防止金鑰本身外洩、能以遠端操作刪除加密資料或金鑰、或設計成第三者無法使用金鑰。

也就是說，光是「有加密」還不夠，要設計到金鑰放在哪裡、誰能使用，外洩才有可能不必通報。如果金鑰和應用程式在同一台伺服器上、由應用程式自動解密，而應用程式整個被接管，這時還能不能主張「第三者無法讀取」，我認為要非常謹慎。這是我們的解讀，個別案件請向專業人士或委員會確認。

走向不必傳送影像的身分確認

日本政府的方向，也正在離開蒐集影像的身分確認。規範金融等領域身分確認方式的日本《犯罪收益移轉防止法》施行規則已經修正，從2027年4月1日起，線上請客戶傳送身分證明文件影像或影本的方式原則上廢止，改以傳送IC晶片資料為基本作法³⁹。臨櫃時，附照片的身分證明文件也限於有IC晶片者，並必須讀取晶片。日本警察廳說明，背景是以偽造或變造證件開立的帳戶被用於詐騙等犯罪³⁹；另一份報告也提到，已確認有濫用生成式AI製作身分證明文件的案例⁴⁰。以影像確認身分，正同時從兩端變得脆弱：影像可以偽造，蒐集來的影像也可能外洩。

至於要留下什麼，也有可以參考的範例。日本數位廳的「個人編號卡（My Number Card）臨櫃確認App」，為了防範卡面偽造而讀取IC晶片，在業者手機上只留下「確認的日期時間」和扣除6位數出生日期後的8位數核對號碼⁴¹。資料中明確寫著「不保存個人資訊」。

汽車共享或租車是否屬於這次修正的適用對象，我還無法確認。不過，不保存影像也能確認本人的方法逐漸成為國家的制度，對任何產業來說，都是重新檢視身分確認方式的好時機。

如果貴公司有處理身分證明文件，不妨確認能不能回答以下問題：法令要求留下的是什麼，公司實際持有的又是什麼？落差的部分是為了什麼而留？存放在哪裡、誰看得到、要留幾年？萬一外洩，能不能說它「讀不懂」？答不出來的那一題，就是該先動手的地方。

上篇小結與下篇預告

上篇談的是攻擊者從哪裡進來，以及進來之後還剩下什麼能拿。AI讓攻擊變快、變多，AI代理和它的金鑰本身也成了目標。而蒐集來的資料，若沒有分開存放、把金鑰另外管理、到期刪除，一旦被入侵就會整批流出。

下篇會依據公部門的資料，整理員工的電腦與端點該怎麼保護，以及沒有專職資安人員的中小企業該從哪裡開始。

關於TIMEWELL

TIMEWELL提供協助企業把AI導入業務的支援與培訓。公司內部越廣泛使用AI，AI帳號與API金鑰的管理、給AI代理多少權限、讓員工不容易受騙的機制，就越是導入時無法切割的課題。TIMEWELL已取得ISO/IEC 27001（資訊安全管理系統）驗證，驗證範圍為運用AI技術的SaaS產品之企劃、開發與提供。

我們的AI資安培訓WARP SECURITY，比起解說攻擊手法，更把時間花在平時就該決定好的事：AI代理可以做到哪裡、核准流程怎麼設計、包含是否公告在內的事件應變判斷。想依自家狀況一起討論，歡迎參考WARP，或從個別諮詢聯絡我們。

結語

• 2026年6月到9月公告的12起事件中，各家在調查途中就公開已知範圍，並安排逐一通知與諮詢窗口。9月下旬公告的案件，多數還沒公開入侵途徑與手法
• 2026年上半年的勒索軟體通報達單一半年最高的123件，超過六成是中小企業；主要入侵口是VPN設備與遠端桌面
• AI讓攻擊變快、變多。公部門評估傳統防護仍然有效，但AI的API金鑰、AI代理的權限，以及被生成式AI潤飾得更自然的釣魚，都需要新的準備
• 身分證明文件依「不保存」「只留號碼」「分開存放」「金鑰分開管理並加密」「到期刪除」的順序思考。只靠磁碟或資料庫加密，擋不住已經進入運作中伺服器的攻擊者

蒐集來的資料，總有一天可能外洩。這樣一想，比起「怎麼保護」，更先該問的是「真的需要留著嗎」。下篇會接著談入口該怎麼守。

參考資料

本文的事實依據為下列公開資料（截至2026年9月30日）。各家的原因只記載官方已說明的範圍。標示（日文）的資料為日文原文，標題為筆者翻譯。

Footnotes

1. 關於提供給網路服務業者的郵件系統遭未經授權存取的致歉與報告（日文） — KDDI — 2026年7月6日（7月21日更正） ↩

2. 關於本公司系統遭未經授權存取及資料外洩的調查結果與防止再次發生的措施（日文） — 日本Aflac人壽 — 2026年7月31日 ↩ ↩² ↩³

3. 關於本集團發生系統故障（第2報）（日文） — Nichirei — 2026年7月15日 ↩

4. 關於本集團發生系統故障（第7報）（日文） — Nichirei — 2026年9月18日 ↩

5. 關於本公司遭未經授權存取導致顧客資料外洩的致歉與報告（第一報、第二報）（日文） — Murauchi.com — 2026年7月24日刊登，9月15日更新 ↩

6. 「關於Government Solution Service遭未經授權存取導致職員等個人資料可能外洩」Q&A（日文） — 日本數位廳 — 2026年9月11日 ↩ ↩²

7. 關於Gyazo遭未經授權存取導致資料外洩的說明與致歉（日文） — Helpfeel — 2026年9月16日 ↩

8. 關於Gyazo遭未經授權存取導致資料外洩的說明與致歉（第二報）（日文） — Helpfeel — 2026年9月25日（9月27日追記） ↩

9. 關於Times Car網站遭未經授權存取、個人資料可能外洩（第1報）（日文） — Times Mobility — 2026年9月25日（9月26日追記） ↩ ↩²

10. 關於Times Car網站遭未經授權存取的調查結果與後續因應（第2報）（日文） — Times Mobility — 2026年9月28日 ↩ ↩² ↩³ ↩⁴

11. 關於Times Car網站遭未經授權存取的調查結果與後續因應（第3報）（日文） — Times Mobility — 2026年9月29日 ↩ ↩² ↩³

12. 關於勒索軟體攻擊造成系統故障的說明與致歉（日文） — 京王電鐵 — 2026年9月26日 ↩

13. 關於租車應用程式遭未經授權存取導致會員資料外洩的致歉與說明（日文） — Nippon Rent-A-Car Service — 2026年9月26日 ↩

14. 關於Metpo會員服務發生未經授權存取事件（致歉）（日文） — 東京地下鐵 — 2026年9月27日 ↩

15. 關於本公司系統遭未經授權存取及個人資料外洩的致歉與說明（日文） — eplus — 2026年9月29日 ↩

16. 關於Seicomart應用程式遭未經授權存取、個人資料可能外流的致歉與說明（日文） — Seicomart — 2026年9月29日 ↩

17. 2025會計年度年報（日文） — 日本個人資料保護委員會 — 2026年7月 ↩

18. 2026年上半年網路空間威脅情勢（日文） — 日本警察廳 — 2026年9月 ↩

19. 資訊安全十大威脅2026（日文） — 日本資訊處理推進機構（IPA） — 2026年1月29日 ↩

20. Disrupting the first reported AI-orchestrated cyber espionage campaign — Anthropic — 2025年11月 ↩

21. Detecting and countering misuse of AI: August 2025 — Anthropic — 2025年8月 ↩

22. Detecting and countering misuse of AI: September 2026 — Anthropic — 2026年9月 ↩

23. GTIG AI Threat Tracker: Distillation, Experimentation, and (Continued) Integration of AI for Adversarial Use — Google Threat Intelligence Group — 2026年2月13日 ↩

24. Disrupting malicious uses of AI: October 2025 — OpenAI — 2025年10月 ↩

25. 資訊安全十大威脅2026解說書（組織篇）（日文） — 日本資訊處理推進機構（IPA） ↩

26. 產業網路安全研究會第1工作小組「企業安全運用AI代理」小組第1次會議資料（日文） — 日本經濟產業省 — 2026年9月18日 ↩

27. LLM06:2025 Excessive Agency — OWASP GenAI Security Project ↩

28. OWASP Top 10 for Agentic Applications — OWASP GenAI Security Project — 2025年12月9日 ↩

29. 網路釣魚報告2026（日文） — 日本反網路釣魚協議會 — 2026年5月 ↩

30. 網路釣魚防範指引2026年度版（日文） — 日本反網路釣魚協議會 — 2026年5月 ↩

31. 鎖定企業組織的攻擊郵件手法與對策（日文） — 日本資訊處理推進機構（IPA）資安中心 — 2026年8月3日 ↩

32. 關於出租人以車輛使用者身分出租自用車（租車）的處理（最終修正2022年5月31日）（日文） — 日本國土交通省 ↩

33. Times Car出租條款（日文） — Times Mobility（2026年9月30日瀏覽） ↩

34. 個人資料保護法指引（通則篇），2026年4月部分修正（日文） — 日本個人資料保護委員會 ↩ ↩²

35. Cryptographic Storage Cheat Sheet — OWASP Cheat Sheet Series ↩ ↩² ↩³

36. 密碼金鑰管理指引（含密碼金鑰管理系統設計指針基本篇）（日文） — 日本資訊處理推進機構（IPA） — 2026年4月24日更新 ↩

37. SP 800-111: Guide to Storage Encryption Technologies for End User Devices — NIST — 2007年11月 ↩

38. Q&A Q6-19：何謂「外洩的個人資料已採取高度加密等隱匿措施」的情形（日文） — 日本個人資料保護委員會 ↩

39. 防止犯罪收益移轉年度報告（2025年）特輯2：施行規則修正與身分確認方式的調整（日文） — 日本警察廳 ↩ ↩²

40. 2025年網路空間威脅情勢（日文） — 日本警察廳 — 2026年3月 ↩

41. 關於個人編號卡臨櫃確認App（日文） — 日本數位廳 — 2024年7月 ↩