ISO 27001 認証とは？PHP の脆弱性から見る企業の AI 導入における情報セキュリティ

ISO/IEC 27001 是國際通用的資訊安全管理系統（ISMS）標準，協助企業以風險為基礎，建立、執行及持續改善資訊安全制度。企業可透過獨立第三方驗證，證明特定範圍內的管理系統符合標準要求；ISO 本身不直接核發企業證書。

2026 年 10 月的 PHP2Shell 漏洞事件，提醒企業持續檢查底層元件安全，也凸顯建立資安管理制度的重要性。當 AI 客服開始處理訂單、會員資料與顧客對話，企業需要同時評估服務功能及資料保護。以下將從 ISO 27001 的核心觀念出發，透過 PHP 漏洞案例說明 AI 導入風險，並整理廠商評估方式，以及與 ISO 42001 的差異。

全文重點

• ISO 27001 管的是資訊安全制度，核心目標是維護資訊的機密性、完整性與可用性。
• PHP2Shell 揭示底層元件與上層服務的資安連動關係；實際利用條件取決於版本、部署及程式碼路徑。
• 導入 AI 應檢查個資、權限、第三方供應商與提示注入風險，並建立持續監測與修補流程。
• 評估 AI 廠商時，除了驗證證書，也要確認驗證範圍、資料流向、保存政策及模型訓練條款。
• ISO 27001 側重資訊安全管理，ISO 42001 側重 AI 治理；兩者可互補，均不代表零風險。

ISO 27001 是什麼？資訊安全管理系統（ISMS）一次看懂

ISO 27001 的定義與核心精神：機密性、完整性、可用性

ISMS 是 Information Security Management System 的縮寫，中文為資訊安全管理系統。依 ISO 官方說明，ISO/IEC 27001 適用於不同規模與產業的組織，讓企業能有系統地辨識風險、採取措施並檢查成效。它涵蓋人員、流程與技術，也包含紙本文件、雲端服務及委外作業等資訊處理情境。

機密性是讓獲得授權的人才能接觸資料，例如只有負責該案件的客服能查閱顧客資訊。完整性是維護資料正確與完整，例如訂單金額與退貨紀錄不被未授權修改。可用性則是讓授權人員在需要時能取得資訊與服務，例如系統故障後能依規劃恢復客服作業。

這三個目標需要一起管理。以 AI 訂單查詢為例，回答速度再快，若會顯示其他人的訂單，就沒有做好機密性；如果資料來源過期、訂單狀態錯誤，也會影響資訊完整性與顧客判斷。

ISO/IEC 27001:2022 新版重點：控制項整併與新增

ISO/IEC 27001:2022 將附錄 A 的控制措施由 2013 版的 114 項重整為 93 項，歸入組織、人員、實體與技術四大主題。數量減少是因為相關項目被整併，管理範圍並沒有縮小，企業仍須依實際風險涵蓋所有必要措施。

新版另外新增 11 項控制措施：威脅情資、雲端服務使用的資訊安全、營運持續的 ICT 就緒準備、實體安全監控、組態管理、資訊刪除、資料遮罩、資料外洩防護、監控活動、網頁過濾及安全程式設計。整體方向是把雲端使用、資料流動與持續監控納入更明確的要求，這些項目在 AI 客服情境中如何落實，會在後文的資安風險與管理面向段落說明。企業選用哪些控制措施及排除理由，則記錄在適用性聲明（SoA）中。

ISO 27001 認證怎麼取得？第三方稽核與每年追蹤稽核

一般導入流程是先界定驗證範圍，盤點資訊資產、法律與客戶要求，進行風險評估與處理，再建立政策、作業流程及執行紀錄。制度運作後，透過內部稽核與管理審查找出缺口，完成改善後再接受第三方驗證。

初次驗證包含第一階段的文件與準備程度審查，以及第二階段的實際運作稽核。通過後仍須按驗證機構安排接受追蹤稽核，通過後每年接受追蹤稽核，三年後再驗證；一般驗證週期為三年，期滿前須再驗證。取得證書是持續管理的一個節點，後續仍要保留制度運作與改善的證據。

從 PHP 漏洞事件看 AI 時代的資安風險

PHP2Shell 漏洞事件：發生什麼事？影響哪些網站？

PHP2Shell 是 PHP 核心記憶體安全漏洞的通稱，主要涉及 CVE-2026-109618 與 CVE-2026-109619。PHP Foundation 於 2026 年 10 月 21 日公告安全更新，說明在符合利用條件時，未經身分驗證的攻擊者即可在伺服器執行程式碼。研究團隊也展示了敏感程序記憶體外洩風險。

問題位於 PHP 執行環境，影響範圍不只限於特定網站或外掛。WordPress、Drupal、Joomla 等常見內容管理系統皆以 PHP 為基礎，因此使用這些系統的企業也應確認底層 PHP 是否受影響。研究團隊已在這三種系統上展示漏洞利用，但不代表所有使用者都已遭入侵；其他 PHP 應用也應依實際執行版本、部署方式、供應商修補情況與對外暴露程度評估風險。

AI 讓多年舊漏洞變成重大威脅：攻擊門檻正在降低

PHP Foundation 的說明指出，OOM 記憶體問題的早期跡象於 2024 年已被發現，當時尚未找到具體利用途徑，修補也面臨相容性與資源取捨。後續 Calif、OpenAI 與 Wiz 等團隊的研究讓影響更明確，推動修補成為優先事項。

在這次事件中，AI 輔助程式分析與驗證，協助研究團隊釐清漏洞的可利用性。企業應據此檢查風險評估與反應速度，並依各系統的版本、部署及程式碼路徑判斷影響。防守團隊也能運用 AI 驗證通報、整理線索及加速修補。

企業的啟示：資安不是一次性設定，而是持續管理

企業應能回答三個問題：

• 我們用了哪些受影響元件？
• 誰負責判斷與修補？
• 如何確認修補確實生效？

完整的資產清單、責任分工與委外聯絡窗口，能讓團隊在公告發布後迅速定位受影響系統與負責人。

建議把資產盤點、漏洞情報接收、影響評估、修補測試、變更核准及修補驗證串成固定流程，並保留紀錄。這正是資訊安全管理制度能提供的價值：讓每次新威脅都能進入有人負責、可以追蹤的處理機制。

為什麼 AI 系統更需要資安管理？導入 AI 的 4 大資安風險

談 AI 客服資安，不能只看模型本身。AI 客服的資料流會依串接架構，經過聊天通路、應用平台、模型 API、知識庫與 CRM，任何一個環節出問題都可能影響顧客資料。因此導入 AI 的資安風險，需要沿著完整資料流逐一檢查，不能只看模型品牌或單一平台的安全承諾。以下整理企業最常遇到的 4 大風險，情境為評估示例，不代表特定廠商已發生事故。

客戶個資與對話紀錄外洩

顧客在對話中提供的姓名、電話、地址、訂單編號，以及健康或付款相關資訊，都屬於需要妥善管理的資料。如果整段對話無差別送往外部模型，或測試紀錄與客服匯出檔沒有妥善管理，就會擴大資料接觸範圍。

導入前應確認每一步需要哪些資料，優先減少不必要欄位，必要時遮罩或去識別化，並釐清傳輸、儲存、日誌及匯出的保護方式。特別是測試與除錯環境，不應因方便而直接複製全部正式客戶資料。

權限設定不當，內部資料被不當存取

當 AI 串接訂單與會員系統，風險不只在後台帳號。若顧客只輸入一個訂單編號就能取得完整收件資訊，或 AI 工具使用權限過大的 API 金鑰，就會形成越權存取風險。

身分驗證與授權判斷應由後端系統執行，確認目前使用者有權查詢該筆資料。知識檢索也應依使用者、部門或租戶範圍限制，不應只靠一句「不要透露其他客戶資料」的提示詞維持隔離。

串接第三方模型、套件與平台的供應商風險

AI 服務往往依賴第三方模型 API、雲端主機、CRM、資料庫與軟體套件。各環節的漏洞、服務中斷與條款變動，都可能影響資料安全及服務穩定性。企業應盤點主要供應商與次處理者，確認各項服務會接收哪些資料、資料是否跨境，以及安全責任、變更通知與事件通報的分工。供應商取得驗證，也不代表整套 AI 系統都在相同驗證範圍內。

資料交給第三方前，應依使用情境遮蔽電話、地址等敏感欄位，並約定資料用途、保存期限與刪除方式。針對敏感資料的傳送、下載與匯出，也要建立外洩防護與權限限制；檢查範圍應涵蓋對話紀錄、測試資料與備份，避免正式資料直接流入測試環境。導入前也須規劃退出安排，確認停止使用服務時，資料如何匯出、帳戶與串接權限如何停用，以及供應商端的資料如何刪除。

供應商與底層元件的安全狀態也需要持續追蹤。以 PHP2Shell 為例，收到漏洞公告後，團隊應比對實際使用的元件、版本與部署方式，評估影響並安排修補，同時檢查相關日誌；發現異常查詢或大量匯出時，須有明確的負責人接手調查。系統設定與程式變更應納入組態管理，避免測試設定沿用到正式環境，並在開發與串接時落實輸入驗證、授權檢查等安全要求。

除了預防風險，也要預先約定服務中斷時的責任與替代方案。例如模型 API 無法使用時，可依既定流程切換真人客服或保留待處理案件，並規劃技術復原與演練，降低單一供應商或元件故障對顧客服務的影響。

提示注入等 AI 特有攻擊手法

提示注入是攻擊者透過輸入內容，或讓模型讀取含有惡意指令的外部資料，影響原本任務與行為。例如客服 AI 讀到一份文件，其中夾帶要求它忽略規則、揭露資料的指令。OWASP 將提示注入列為大型語言模型應用的重要風險，並指出 RAG 與微調無法完全消除這類問題。

實作上應把外部內容視為資料，限制工具與資料庫權限，驗證工具輸入及輸出，並對退款、資料匯出等敏感操作加入適當的人工作業或核准。測試也要涵蓋跨客戶查詢、惡意文件與要求繞過規則的情境。

ISO 27001 如何保障 AI 系統安全？5 個關鍵管理面向

ISO 27001 能提供管理 AI 資安風險的制度基礎，實際防護仍取決於驗證範圍、風險處理與技術落實。以下是把管理要求用在 AI 客服情境的五個方向，不代表標準直接為每一個模型回答或操作背書。

資安治理：明確的資安政策與權責分工

先明確指定資料、系統、模型串接與事件處理的負責人，讓資料新增、權限申請與上線變更有審核依據。例如行銷希望把客服對話加入知識庫時，需先確認資料用途、敏感資訊與可讀取對象，再安排更新。

資料管理：客戶資料的分類、加密與保存

先把公開商品資訊、內部營運文件與客戶個資分開管理，再依風險決定傳輸及儲存保護、加密金鑰管理、遮罩與備份方式。每一類資料都應有明確用途、保存期限與刪除規則，也要確認備份和模型供應商端的保留安排。

存取權限控管：誰能看到什麼資料

依職務與任務授予必要權限，定期檢視管理員、客服及 API 帳號。人員離職、職務變動或串接停用時，應同步撤銷權限與更新憑證。對 AI 而言，查閱資訊與執行交易的權限也應分開，避免一個工具同時擁有不必要的讀寫能力。

弱點管理與修補流程：像 PHP 這類漏洞公告時，能多快評估與修補

弱點管理應能把公告對應到實際資產，依影響、暴露程度與利用跡象安排優先順序。像 PHP2Shell 公告出現時，團隊應查明受影響版本與服務，安排測試、更新及必要的程序重啟，再檢查執行中的版本與服務是否正常。

企業可設定符合自身風險的評估與修補時限，追蹤例外核准、暫時緩解措施及逾期原因。ISO 27001 並未對所有漏洞一律規定相同的修補小時數，不能只用一句「符合 ISO」代替可檢查的處理承諾。

風險管理與事件應變：持續監測與改善

建立異常登入、越權查詢、資料大量匯出與服務中斷等監測方式，並規劃通報、隔離、調查、復原與事後改善。除了演練流程，也應保留可以追溯的日誌與決策紀錄，讓事件發生後能確認影響範圍並修正根本原因。

企業選擇 AI 客服廠商時，該怎麼評估資安？

AI 客服廠商評估應同時看文件證據與實際運作。建議把以下問題納入採購、資安審查與合約討論，要求廠商說明適用服務、責任分工及可提供的佐證。

確認是否通過 ISO 27001 等國際資安驗證

請廠商提供有效證書，核對受驗證法人、標準版本、驗證範圍、發證機構與有效期限。最關鍵的是確認正在採購的 AI 服務與相關作業，是否落在證書描述的範圍內；不能只看網站上的 ISO 標章。必要時可透過發證機構或其公開管道確認證書狀態。

詢問重大漏洞發生時的應變與修補機制

可直接問：「若明天底層套件出現重大漏洞，誰會接收通知？多久完成初步影響評估？如何安排修補、驗證與通知客戶？」請廠商說明風險分級、例外處理及緊急聯絡窗口，並以去識別化範例或流程紀錄佐證。

了解資料存放位置與保存政策

確認正式資料、備份、日誌與模型 API 處理位置，以及有哪些次處理者會接觸資料。也要問清楚合約終止後如何匯出與刪除、備份多久輪替，以及刪除請求如何被確認。資料存放在某一地區，不代表整段處理流程都不會跨境。

確認是否會將客戶資料用於模型訓練

把廠商自身的資料使用方式，與第三方模型供應商的條款分開確認。除了詢問「會不會訓練」，還要了解是否有人工作業審閱、濫用監控保留、產品改善或其他再利用，並確認企業方案、帳戶設定與合約是否一致。

建議將用途限制、保存期限、次處理者變更通知與事件通報責任寫入合約或資料處理協議。口頭承諾及單一設定畫面，不足以說明整個資料生命週期。

ISO 27001 vs ISO 42001：AI 時代的兩張認證有什麼不同？

企業導入 AI，除了保護客戶資料與系統安全，也需要管理 AI 的使用目的、決策責任與對使用者的影響。ISO 27001 與 ISO 42001 分別從資訊安全與 AI 治理切入，協助企業建立這兩個層面的管理制度。

ISO 27001 的核心是確保資訊的機密性、完整性與可用性；ISO 42001 則聚焦 AI 系統的負責任開發、提供與使用，涵蓋透明度、風險評估及生命週期管理。以 AI 客服為例，顧客對話如何保存、誰能查閱，屬於資訊安全管理；AI 的使用範圍如何界定、回答與操作由誰負責，以及何時交由真人接手，則涉及 AI 治理。兩項標準相互補足，企業可依服務情境與既有制度整合規劃。

ISO 27001：保護資訊資產的資安基礎

ISO/IEC 27001 建立資訊安全管理系統，關注資訊的機密性、完整性與可用性。它適用於各類資訊處理活動，不限於 AI；在 AI 導入中，可作為資料、權限、供應商及事件管理的共同基礎。

ISO 42001：針對 AI 系統治理的管理標準

ISO/IEC 42001:2023 是 AI 管理系統（AIMS）標準，適用於開發、提供或使用 AI 產品及服務的組織。依 ISO 官方說明，它針對 AI 帶來的治理議題，例如負責任的使用、透明度與持續學習，建立風險及機會管理架構。

因此，ISO 42001 的重點會延伸到 AI 系統的用途、影響、責任與生命週期管理。通過這項管理系統驗證，也不等於每個 AI 輸出都正確、公平，或每項應用自動符合所有法規。

兩者如何互補？企業該先從哪一張開始

兩者可共用部分政策、風險評估、稽核與持續改善流程，但評估焦點不同，不能互相替代。已有成熟 ISMS 的企業，可在既有基礎上擴充 AI 治理；缺乏基本資安制度的企業，應先補齊資料、權限與事件管理，並依 AI 用途建立治理措施。

先取得哪一張證書，應依客戶要求、產業規範、目前制度與 AI 風險決定，沒有適用所有企業的固定順序。若應用涉及高影響決策，AI 治理也不應等到資訊安全驗證完成後才開始。

ISO 27001 常見問題 FAQ

ISO 27001 認證有效期多久？

一般驗證週期為三年，期間須依驗證機構安排接受追蹤稽核，通過後每年接受追蹤稽核，三年後再驗證證書是否持續有效，仍取決於制度維持、缺失改善及驗證機構決定；應以證書與發證機構查驗結果為準，不能只看最初取得日期。

ISO 27001 和個資法有什麼關係？

ISO 27001 是資訊安全管理標準，台灣《個人資料保護法》則是法律要求。ISMS 可以協助企業落實與留存資料保護措施，但取得驗證不等於已符合所有個資法義務。企業仍須依實際蒐集及利用情境，確認合法依據、告知、目的限制、當事人權利及委外管理等事項，並依適用法規與施行狀態檢視。

中小企業需要 ISO 27001 嗎？

中小企業同樣需要管理資安風險，取得證書的時程則應依業務需求與資源規劃。評估重點包括個資處理規模、客戶驗證要求、委外與跨境資料流，以及持續維護制度的能力。資源有限時，先建立核心管理流程，再依業務與採購需求安排驗證，讓制度落實於日常作業。

有 ISO 27001，就不會遇到 PHP 這類漏洞嗎？

通過 ISO 27001 驗證的企業，同樣需要處理 PHP 這類軟體漏洞。驗證確認的是特定範圍內的管理系統符合標準要求，核心價值在於建立辨識、評估、處理與改善風險的能力。企業評估廠商時，應搭配檢查實際漏洞處理、權限管理與事件應變紀錄，確認制度持續運作。

Raccoon AI 通過 ISO 27001:2022 驗證，讓企業安心導入 AI

Raccoon AI 已通過 TQCSI（TQCS International Pty Ltd）第三方驗證，符合 ISO/IEC 27001:2022 資訊安全管理系統要求，官網公開證書編號為 TA3286-YC。這項驗證代表在證書所界定的範圍內，資訊安全管理系統符合標準要求，為資安治理、資料管理、存取權限與風險管理提供制度基礎。

企業導入 AI 客服、AI 導購時，可把這個制度基礎與自身需求一起檢視：哪些資料會進入服務、如何完成訂單與會員查詢的授權、誰能管理知識庫，以及異常發生時如何轉交真人與通報。實際驗證範圍、服務設定與串接責任，可在導入評估時進一步確認。

想讓 AI 協助處理顧客詢問與購買需求，也讓每次資料交換有清楚的管理依據？預約 Raccoon AI Demo／顧問諮詢，從使用情境、資料流向與權限需求開始，討論適合企業的導入方案。

延伸閱讀

AI 智能客服是什麼？核心原理、優缺點、導入挑選與案例完整介紹

AI 導購是什麼？站內 AI 購物助理 × 站外 AI 搜尋，電商提升轉換的完整指南