滲透測試是什麼？種類、流程、與弱點掃描差異一次看懂
滲透測試（Penetration Testing，簡稱 Pentest）是由資安專家在企業書面授權的範圍內，模擬真實攻擊者的手法攻擊系統，驗證弱點能不能被利用、可以串成什麼攻擊路徑，以及最終會造成多大影響。它和弱點掃描最大的差別，是不只列出「可能有問題」，而是實際證明「真的打得進去」。
對 SaaS、電商與軟體公司來說，這常是客戶資安問卷、ISO 27001 稽核或《資通安全管理法》要求的項目，但真正難的是決定測什麼、用哪種方法、報告要長什麼樣。這篇整理黑箱、白箱、灰箱的選法、測試範圍與流程、與弱點掃描和紅隊演練的差異，以及合格報告的內容。想直接規劃測試範圍，可以參考我們的 滲透測試服務。
重點整理 – 滲透測試是在授權範圍內模擬真實攻擊，驗證弱點的可利用性與實際影響，NIST SP 800-115 將流程分為規劃、探索、攻擊、報告四個階段。 – 黑箱、灰箱、白箱的差別在於測試人員事先取得多少資訊，沒有哪一種永遠最好。 – 弱點掃描找出大範圍的已知弱點，滲透測試驗證能否被利用，紅隊演練則檢驗整個組織的偵測與應變。 – 《資通安全管理法》的特定非公務機關，A 級每年一次、B 級與 C 級每 2 年一次滲透測試。
滲透測試是什麼？
滲透測試是一種資安測試，由評估人員模擬真實攻擊，找出繞過應用程式、系統或網路安全機制的方法。這是美國國家標準與技術研究院（NIST）SP 800-115《資訊安全測試與評估技術指南》的定義，它也指出，多數滲透測試會尋找可以串連的多個弱點，以取得比單一弱點更高的存取權限。
英文是 Penetration Testing，業界常簡稱 Pentest；執行測試的人稱為 Penetration Tester。測試會使用攻擊者常用的工具，例如網路掃描器、攔截代理與漏洞利用框架，但工具只負責輔助；權限控管缺陷與業務邏輯漏洞，多半要靠人工分析才找得到。
| 問題 | 滲透測試的回答 |
|---|---|
| 這個弱點真的能被利用嗎？ | 在授權範圍內實際驗證，附上證據 |
| 攻擊者能走多遠？ | 分析多個弱點串成的攻擊路徑 |
| 影響有多大？ | 說明可存取的資料、可取得的權限 |
| 修好了沒有？ | 修補後複測，確認狀態 |
滲透測試工具有哪些？
常見的工具大致分成幾類：網路與服務探測（例如 Nmap）、Web 攔截代理（例如 Burp Suite、OWASP ZAP）、漏洞利用框架（例如 Metasploit），以及針對特定弱點的工具（例如檢測 SQL 注入的 sqlmap）。這些工具多數攻擊者也拿得到，所以「有沒有用工具」不是重點；同一套工具，換不同經驗的人操作，找到的東西可能差很多。
滲透測試工程師做什麼？
這個職位負責規劃測試、實際攻擊、判斷影響並撰寫報告。除了熟悉網路、作業系統與程式開發，還要能從業務流程找出邏輯漏洞，例如跳過付款步驟直接完成訂單。業界常見的個人證照包括 OffSec 的 OSCP 與 EC-Council 的 CEH；企業在選廠商時，比證照更該看的是過往報告的品質。
黑箱、白箱、灰箱測試怎麼選？
黑箱、白箱、灰箱的差別，在於測試人員事先取得多少系統資訊與權限。黑箱模擬一無所知的外部攻擊者，灰箱模擬已登入的使用者或合作夥伴，白箱則在掌握架構甚至原始碼的情況下深入評估。沒有哪一種永遠最好，要看想回答的問題。
| 方法 | 測試人員取得的資訊 | 模擬的情境 | 適合 |
|---|---|---|---|
| 黑箱（Black-box） | 只有網址或 IP | 外部攻擊者 | 想知道對外暴露面有多大 |
| 灰箱（Gray-box） | 測試帳號、部分文件 | 一般使用者、合作夥伴或帳號遭盜用 | 會員系統、SaaS、B2B 平台 |
| 白箱（White-box） | 架構圖、原始碼、管理權限 | 內部人員或完整審查 | 核心系統、上線前深度驗證 |
實務上，有登入功能的 Web 與 App 多半選灰箱：黑箱可能花大量時間在登入頁外面，碰不到會員資料的權限問題；而帳號被盜後能做什麼，正是 撞庫攻擊 這類攻擊最常造成的風險。
滲透測試範圍：Web、App、API、內網、雲端
測試範圍依系統類型區分，常見的有 Web 應用程式、行動 App、API、外部與內部網路，以及雲端環境。不同範圍的測試重點不同，報價與時程也主要由範圍決定，所以簽約前要先列清楚。
| 範圍 | 測試重點 | 常參考的方法 |
|---|---|---|
| Web 應用程式 | 身分驗證、權限控管、業務邏輯、注入 | OWASP Top 10:2025 |
| API | 物件與功能層級的權限、速率限制 | OWASP API Security Top 10 |
| 行動 App | 本機資料儲存、網路通訊、與後端 API 的互動 | OWASP MASVS |
| 外部網路 | 對外服務、遠端連線入口、組態弱點 | NIST SP 800-115 |
| 內部網路 | 權限提升、橫向移動、網域服務 | NIST SP 800-115 |
| 雲端環境 | 身分與存取權限、儲存空間設定、網路規則 | 依雲端服務商的測試政策 |
OWASP Top 10:2025 排名第一的仍是「權限控管失效」（Broken Access Control），例如改一下網址裡的訂單編號就看到別人的訂單。這類問題掃描工具很難判斷，因為工具不知道「這筆訂單不該被這個帳號看到」，要靠人工依角色逐一測試。
雲端環境要特別注意測試邊界：企業只能測試自己租用、管理的資源，不能測試雲端服務商本身的基礎設施。各家雲端服務商對可測試的服務與事先通知的規定不同，簽約前要先確認，並把雲端帳號的權限設定一併納入範圍。
滲透測試流程與時程
NIST SP 800-115 把滲透測試分成規劃、探索、攻擊、報告四個階段：規劃階段確認規則、取得管理階層核准並設定目標，這個階段不做任何實際測試。實務上，再加上修補後的複測，一個完整的滲透測試專案大致分成 6 個步驟。
| 步驟 | 內容 | 企業要配合 |
|---|---|---|
| 1. 界定範圍與測試規範 | 確認目標系統、環境、黑灰白箱方法，簽訂測試規範（Rules of Engagement） | 提供系統清單，書面核准測試規範 |
| 2. 資訊蒐集 | 在授權範圍內蒐集資訊，建立攻擊面 | 灰箱或白箱需提供測試帳號 |
| 3. 弱點探測與分析 | 工具輔助加人工檢測，分析組態、權限與業務邏輯 | 安排技術窗口待命 |
| 4. 受控利用 | 在約定範圍內驗證可利用性並蒐集證據 | 確認可利用的時段與停止門檻 |
| 5. 風險分析與報告 | 評估嚴重程度、整理攻擊鏈，撰寫報告 | 確認系統重要程度 |
| 6. 修補支援與複測 | 說明結果、協助修補、複測並更新報告 | 完成修補後通知複測 |
時程主要取決於範圍：系統數量、功能與角色數量、API 端點數，以及要不要測內網。範圍越清楚，報價與時程越準確。
測試前準備檢查清單
測試前準備得越完整，越不容易影響營運，報告也越有參考價值。以下 8 項建議在簽約後、開始測試前逐一確認：
| # | 準備項目 | 已確認 |
|---|---|---|
| 1 | 測試範圍清單：網址、IP、API 端點、App 版本，並列出排除項目 | ☐ |
| 2 | 測試環境：正式環境或測試環境，兩者資料與設定是否一致 | ☐ |
| 3 | 測試帳號：每種角色各一組，含不同權限的帳號 | ☐ |
| 4 | 測試時段與停止門檻：哪些時段不能測、出現什麼狀況立即停止 | ☐ |
| 5 | 緊急聯絡窗口：雙方技術與管理窗口的電話 | ☐ |
| 6 | 書面授權：由系統所有者簽署；系統在雲端或代管時，確認服務商的測試政策 | ☐ |
| 7 | 備份與監控：確認備份可用，決定是否通知監控中心與防火牆管理者 | ☐ |
| 8 | 保密協議：約定測試證據與報告的保存、傳遞方式 | ☐ |
滲透測試、弱點掃描、紅隊演練有什麼差異？
弱點掃描用自動化工具大範圍找出已知弱點，滲透測試由專家驗證弱點能否被利用與影響程度，紅隊演練則模擬真實對手、以達成特定目標為導向，檢驗整個組織的偵測與應變能力。三者回答的是不同問題，通常依序搭配使用。
| 項目 | 弱點掃描 | 滲透測試 | 紅隊演練 |
|---|---|---|---|
| 目的 | 找出已知弱點 | 驗證可利用性與影響 | 檢驗組織的偵測與應變 |
| 方式 | 自動化工具為主 | 工具輔助加人工 | 模擬真實對手，可含社交工程 |
| 範圍 | 廣，大量主機與網站 | 約定的系統 | 以目標為導向，範圍較彈性 |
| 是否通知防守方 | 通常會 | 通常會 | 多數防守人員事先不知情 |
| 產出 | 弱點清單與風險等級 | 攻擊路徑、證據、修補建議 | 攻擊時間軸、偵測缺口 |
| 適合頻率 | 較頻繁，例如每季 | 每年或重大變更後 | 防禦成熟後再做 |
NIST 對紅隊演練的定義，是反映真實情境、以模擬對手的方式嘗試危害組織的任務或業務流程，以評估整體資安能力。紅隊常會結合 社交工程 手法，所以適合已經有監控與應變機制的企業。若連基本的修補與帳號管理都還沒做到，先做 資安健診 與弱點掃描會更有效率。
一份合格的滲透測試報告要有什麼？
合格的測試報告，要讓管理階層看得懂風險，也讓工程師能照著重現與修補。至少要包括管理摘要、範圍與方法、每項發現的證據與影響、修補建議，以及複測結果；只附掃描工具輸出的報告，無法證明弱點真的可被利用。
| 報告段落 | 應該包含 |
|---|---|
| 管理摘要 | 整體風險、最重要的發現、建議的處理優先順序 |
| 範圍與方法 | 測試對象、期間、黑灰白箱方法、參考的方法論、排除項目 |
| 發現清單 | 每項的嚴重程度（例如 CVSS 評分）、受影響的系統 |
| 證據與重現步驟 | 截圖、請求與回應、可重現的操作步驟 |
| 影響說明 | 可存取的資料與權限，與其他弱點的串連 |
| 修補建議 | 具體到設定或程式層級的建議 |
| 複測結果 | 每項狀態：已修復、部分修復或尚存 |
報告最常被忽略的是「攻擊鏈」：單看評分偏低的弱點，串在一起可能就能取得管理權限。客戶或稽核要求佐證時，附上複測結果的最終報告，比只有第一次的發現清單更有說服力。
拿到報告後，修補順序不要只看評分，還要看系統是否對外、是否接觸客戶資料。實務上會先處理可直接從外部利用、影響個資或管理權限的項目，再處理需要內部存取才能利用的項目；修補完成後集中一次複測，比零散複測更省時間。
滲透測試費用受哪些因素影響？
測試費用主要由範圍與深度決定：要測幾個系統、每個系統有多少功能與角色、用黑箱還是灰箱或白箱，以及是否包含複測。因為每家廠商計算範圍的方式不同，比價前要先確認報價涵蓋的範圍是否一致。
| 因素 | 為什麼會影響費用 |
|---|---|
| 系統數量與類型 | Web、App、API、內網各自需要不同的測試工作 |
| 功能與角色數 | 角色越多，權限組合越多，權限控管測試的工作量越大 |
| 測試方法 | 白箱需要閱讀架構與程式，灰箱需要逐一測試各角色 |
| 測試環境 | 正式環境需要更嚴格的時段與停止門檻安排 |
| 是否含複測 | 修補後複測確認狀態，是報告能否作為佐證的關鍵 |
| 報告要求 | 是否需要英文報告或對應特定客戶、稽核的格式 |
比較報價時，與其只看總價，不如確認三件事：是否有人工測試而不只是掃描、是否包含複測，以及報告是否附證據與重現步驟。
法規與客戶要求多久做一次滲透測試？
台灣《資通安全管理法》的特定非公務機關，依《資通安全責任等級分級辦法》附表，A 級每年一次、B 級與 C 級每 2 年一次滲透測試。一般企業雖然沒有法定頻率，但客戶、ISO 27001 稽核或 PCI DSS 等支付產業標準，通常也會要求定期測試。
| 對象 | 滲透測試頻率 | 依據 |
|---|---|---|
| 特定非公務機關 A 級 | 每年 1 次 | 資通安全責任等級分級辦法附表 |
| 特定非公務機關 B 級 | 每 2 年 1 次 | 同上 |
| 特定非公務機關 C 級 | 每 2 年 1 次 | 同上 |
| 一般企業 | 依客戶與稽核要求，實務上重要系統每年 1 次 | 合約、ISO 27001、產業標準 |
| 所有企業 | 系統上線前、重大架構變更後 | 風險管理實務 |
第一次做滲透測試，範圍該怎麼切？
第一次做，建議先挑「對外、有登入、存放客戶資料」的系統，通常是會員網站、App 後端 API 或 SaaS 主系統，用灰箱方式測試並包含複測。內網與雲端可以等第一輪修補完成後再擴大，避免一次範圍太大而預算與修補人力都跟不上。
想確認哪些系統該優先測、用哪種方法，可以參考我們的 滲透測試服務，或 從一場 30 分鐘的諮詢開始。
滲透測試常見問題
滲透測試多久做一次？
重要系統一般每年至少一次，並在上線前與重大架構變更後加做。適用《資通安全管理法》的特定非公務機關，A 級每年一次，B 級與 C 級每 2 年一次。若客戶合約或產業標準有更嚴格的要求，以較嚴格者為準。
滲透測試會影響正式系統嗎？
有可能，風險可以降低但無法完全消除。NIST SP 800-115 指出，滲透測試期間系統可能受損或無法運作，所以應在審慎規劃與通知後進行。實務上會事先約定測試時段、停止門檻與緊急窗口，避開高峰時段，並在測試前確認備份可用。
滲透測試合法嗎？需要什麼授權？
取得系統所有者書面授權、在約定範圍內進行的滲透測試是合法的資安評估。未經授權就測試別人的系統，可能觸犯《刑法》第 358 條「無故」入侵電腦罪，可處 3 年以下有期徒刑、拘役或科或併科新臺幣 30 萬元以下罰金；擅自取得或變更資料、干擾系統，另涉及第 359 條與第 360 條。授權書應寫明範圍、期間、方法與雙方窗口。
參考資料
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment – 滲透測試定義與四階段流程。NIST · 2008 年 9 月
- 資通安全責任等級分級辦法 – 各等級應辦事項，含滲透測試頻率。全國法規資料庫
- 中華民國刑法第 358 條 – 無故入侵電腦罪。全國法規資料庫
- OWASP Top 10:2025 – Web 應用程式十大風險。OWASP
