M01-03 · 倫理駭客、授權與交戰規則

CEH M01-03｜道德駭客、合法授權與 ROE

Module 01：Introduction to Ethical Hacking（道德駭客入門）

難度：★☆☆☆☆（初學者）

建議學習時間：8～10 分鐘

核心觀念：Authorization、Scope、Rules of Engagement（ROE）

一、先理解：為什麼駭客需要授權？

今天最重要的一句話：你有能力進入某個系統，不代表你有權利進入；你被允許檢查某個系統，也不代表你可以任意操作。

我們先把前面三堂課串起來：

1. 用生活中的例子理解

假設你住在公寓，最近擔心家中的門鎖不安全。

於是，你找來一位鎖匠。

你告訴他：

「我想知道家裡的大門會不會被人輕易打開，麻煩你幫我檢查。」

鎖匠接受委託，開始檢查。

這時候有三個問題：

問題 A：鎖匠可以檢查你的大門嗎？

可以，因為你已經授權他檢查。

問題 B：鎖匠可以順便檢查隔壁鄰居家的門嗎？

不可以。

即使隔壁的門鎖跟你家一模一樣，他仍然沒有得到鄰居的允許。

問題 C：鎖匠可以直接把你的門破壞掉嗎？

不一定。

你授權的是「檢查門鎖安全性」，不是「破壞大門」。

除非你事先同意使用可能破壞門鎖的測試方式，否則他不能擅自這麼做。

這就是道德駭客最重要的觀念：

善意只是動機，合法授權與遵守約定才是執行測試的基本條件。

二、什麼是 Ethical Hacking（道德駭客）？

Ethical Hacking 可以翻成「道德駭客」或「倫理駭客」。

它指的是：

在取得適當授權的前提下，使用資安技術檢查系統的弱點，協助組織改善資訊安全。

1. 道德駭客和惡意駭客有什麼不同？

假設有一間學校提供線上成績查詢系統。

正常情況下，學生只能查看自己的成績。

某天，有人發現修改網址中的學生編號，可能就能看到其他人的成績。

這時候可能出現三種情況：

注意：這是資安教育常見的簡化分類，不是法律上的正式身分認定。

駭客是不是「好人」，不能只看他聲稱想做什麼，還要看他的授權與實際行為。

2. 臺灣法律怎麼看？

編輯補充：以下為已核對法務部條文的入門摘要，不是個案法律意見，也不表示取得一份文件即可排除所有法律責任。

以臺灣《刑法》第 358 條為例，條文涉及無故輸入他人帳號密碼、破解保護措施，或利用系統漏洞入侵他人電腦等行為。

另外，第 359 條涉及無故取得、刪除或變更電磁紀錄並致生損害；第 360 條則涉及無故干擾電腦系統並致生損害。

這些條文提醒我們：資安測試不是只要自認動機良善就沒有法律風險。實際上是否構成犯罪，仍須依具體行為、法律要件及個案情況判斷。Mojlaw

因此，實務上應該：

在開始測試前，取得有權者的明確授權，並保存可核對的書面紀錄。

三、最重要的三個概念：Authorization、Scope、ROE

這是今天最值得記住的部分。

我們可以把三個概念想像成你參加一場正式考試。

我們逐一理解。

3.1 Authorization（授權）

Authorization 要回答的是：誰有權允許你做這件事？

例如，你在公司擔任工程師。

公司提供一個內部系統：

https://internal.example.test

你擁有自己的員工帳號，也可以正常登入。

這是否表示你可以使用 Nmap 掃描伺服器，或自行嘗試破解其他人的密碼？

答案是：不代表可以。

因為這涉及兩種不同的權限。

第一種：使用權限（Access Permission）

你被允許使用公司的某項服務。

例如登入請假系統、上傳文件、下載自己有權存取的報表。

第二種：安全測試授權（Security Testing Authorization）

你被允許針對特定系統執行安全性檢查。

例如掃描特定測試伺服器的開放連接埠，或檢查指定功能是否存在存取控制弱點。

這兩種權限不能混為一談。

而且，授權者必須有相應的權限。

例如，公司資訊部門主管未必能授權你測試外部雲端供應商的整個基礎設施。

CEH 必記

Authorization = 是否得到適當授權。

但是，得到授權不等於取得無限制的操作權限。

3.2 Scope（測試範圍）

Scope 要回答的是：你可以測試哪些東西？

假設 Northstar 公司有三個系統：

即使這三個系統彼此連線，也不代表測試權限可以跟著擴張。

生活中的比喻

假設你是一名消防安全檢查員。

今天受委託檢查 A 棟大樓。

當你走到二樓時，發現有一條通道連接 B 棟大樓。

你可以直接進去檢查 B 棟嗎？

不可以。

因為：

系統之間存在連線，不代表你取得了另一個系統的測試授權。

Scope 除了列出允許測試的目標，也應該列出明確排除的目標。

在實務上，可以具體到 IP 位址、網域、服務、功能、測試帳號，以及環境類型。

3.3 Rules of Engagement（ROE）

ROE 通常翻成「交戰規則」。

但為了便於理解，我建議你先把它想成：

資安測試的行動規則。

假設公司已經同意你測試教學網站。

但還有很多問題沒有解決。

例如：

你可以測試到幾點？

可以用自動化工具嗎？

可以進行密碼暴力破解嗎？

可以執行會造成伺服器當機的壓力測試嗎？

如果意外發現真實使用者的個資，應該怎麼處理？

這些問題，就是 ROE 要解決的事情。

ROE 一定要事先確認的六件事

1. 測試人員與負責窗口：誰執行測試？誰有權批准、變更或停止測試？

2. 測試目標：哪些 IP、網域、功能與帳號可以測試？哪些明確排除？

3. 測試時間：哪一天、幾點開始、幾點結束？使用哪個時區？

4. 允許的方法：可以使用什麼工具與技術？哪些高風險測試被禁止？

5. 停止條件：發現個資、服務異常或超出範圍時，應停止哪些活動？如何通報與恢復？

6. 資料與報告處理：證據如何保存？誰能查看？如何交付報告與處理測試資料？

這並不是我自行發明的原則。

美國國家標準暨技術研究院（NIST）的 SP 800-115 指引，在第 6 章說明安全評估計畫的制定，第 7 章討論測試執行與協調，附錄 B 則提供 ROE 的參考架構。NIST

它是一份測試管理指引，不是法律授權書。

四、實際案例：Northstar 學生成績系統

現在我們把前面的概念整合起來。

假設 Northstar 是一間提供線上教學服務的公司。

系統裡面有兩名測試學生：

Alice（學生 A）

Bob（學生 B）

原則上：

Alice 只能查看自己的作答資料。

Bob 只能查看自己的作答資料。

公司擔心系統可能存在權限控管問題，因此委託你進行安全測試。

步驟一：測試前建立 ROE

下面是一份教學用的簡化 ROE。

假設這份文件已經由具有適當權限的人員正式核准。

那麼你就知道哪些事情可以做，哪些不行。

步驟二：開始測試

14:00，開始測試。

你使用 Alice 的帳號登入測試網站。

接著查看 Alice 自己的作答。

系統正常顯示：

學生：Alice

作答：A、B、C

目前沒有發現異常。

接著，你依照 ROE 許可的方法，使用 Alice 的身分檢查能否讀取事先準備的 Bob 測試資料。

結果：

系統居然回傳 Bob 的作答內容！

這代表什麼？

技術上的意義

正常的權限控管應該是：

Alice 的帳號 → Alice 的資料：允許。

Alice 的帳號 → Bob 的私人資料：拒絕。

但是實際結果卻是：

Alice 的帳號 → Bob 的私人資料：允許。

這就可能是 Broken Access Control（存取控制失效）。

如果問題是系統沒有針對所指定的資料物件正確檢查存取權限，後續還可能涉及 IDOR 或 BOLA 等概念。

不需要在今天深入這些漏洞分類；先理解「系統沒有正確限制使用者能讀取哪些資料」就好。

回到 M01-01 的 CIA

這個問題主要影響哪項安全目標？

答案是 Confidentiality（機密性）。

因為不應該被 Alice 看見的資訊，卻被 Alice 讀取了。

這也說明 M01-01、M01-02 和 M01-03 並不是獨立的知識。

它們可以串成一個完整的安全管理流程。

步驟三：發現弱點後，應該怎麼做？

這時你很興奮。

因為你真的找到一個安全問題。

你可能會想：

「既然可以讀取 Bob 的資料，那我是不是應該再試試看其他 100 個學生的資料？」

不應該自行擴大測試。

因為你的授權是驗證指定測試帳號之間的讀取權限。

不是把所有學生資料都下載下來。

正確做法是依照 ROE，保存足以證明問題的最小必要證據。

例如：

之後依照約定方式通知負責人。

這種做法也符合許多正式漏洞揭露政策採用的原則：僅在必要程度內確認漏洞，避免不必要的資料取得與系統干擾。U.S. Consumer Product Safety Commission

五、三種容易越界的情況

我們繼續使用 Northstar 的案例。

情況一：網站連到另一個伺服器

14:40，你發現測試網站連到：

payment.example.test

你懷疑這個網站也有同樣的問題。

可以順便檢查嗎？

不能直接測試。

因為這個網站不在原本的 Scope 裡。

你可以記錄發現的線索，向負責人確認是否需要另外授權。

重點：發現新目標，不代表取得新授權。

情況二：已經超過測試時間

14:59，你正要進行最後一項檢查。

但還沒完成，時間就已經來到 15:00。

可以說「我只差一分鐘」就繼續嗎？

不應自行繼續。

測試時間本身也是 ROE 的一部分。

應停止尚未完成的測試，確認是否取得有效的延長授權。

情況三：AI 建議使用新工具

假設你詢問 ChatGPT：

「我要怎麼找出這個網站的安全漏洞？」

AI 建議你執行某個資安工具。

你可以直接照做嗎？

不能因為是 AI 建議就直接執行。

你仍然需要確認工具的目標、參數、可能影響，以及 ROE 是否允許這項行為。

例如，Nmap 雖然是常見的網路掃描工具，但工具本身並不會替使用者判斷測試是否合法。

工具的功能，與你擁有的權限，是兩回事。

六、實務補充：公開網站是不是任何人都可以測？

這是一個很容易產生誤會的問題。

例如，你在網路上發現一間公司的網站。

網站可以公開瀏覽，也沒有要求你先註冊。

是否代表你可以進行漏洞掃描？

公開提供服務，不等於公開授權資安測試。

不過，有些企業會設立：

Vulnerability Disclosure Policy（VDP，漏洞揭露政策）

或 Bug Bounty Program（漏洞懸賞計畫）。

這些政策可能明確說明哪些系統開放安全研究、允許哪些方法、禁止哪些行為，以及如何通報。

但即使企業有公布 VDP，也不能認為該企業的所有資產都可以測試。

例如，美國商務部的漏洞揭露政策，就明確排除不在範圍內的系統、第三方服務，以及若干高風險測試方法。U.S. Department of Commerce

查證註（2026-10-27）：本段保留原文。商務部政策網址本次回傳403，無法核實當前逐項限制；不能據此推定測試許可。另已讀取的CPSC官方政策明確排除未列明及第三方系統，並禁止阻斷服務等測試，可供理解同類原則。

另外，NDA（Non-Disclosure Agreement，保密協議）與測試授權不同。

NDA 主要約定資訊保密義務；它本身不代表你已經取得安全測試許可。

七、把今天的知識整理成一套決策流程

這是你日後進行任何資安測試前，都可以使用的判斷架構。

安全測試決策流程

想對某個系統進行資安測試
           │
           ▼
    是否取得適當授權？
           │
      ┌────┴────┐
      │         │
     沒有      有
      │         │
      ▼         ▼
   不得測試   是否在 Scope 內？
                │
           ┌────┴────┐
           │         │
          否        是
           │         │
           ▼         ▼
       停止確認   方法及時間符合 ROE？
                     │
                ┌────┴────┐
                │         │
               否        是
                │         │
                ▼         ▼
             停止確認   執行測試
                          │
                          ▼
                出現停止條件了嗎？
                          │
                     ┌────┴────┐
                     │         │
                    是        否
                     │         │
                     ▼         ▼
                  停止通報   依規則繼續
                     │
                     ▼
               等待適當核准

補充圖解｜原文決策樹的簡化閱讀提示；不取代上方完整流程。

這個流程有兩個值得注意的地方。

第一，授權不是只在開始測試時確認一次。當測試目標、時間或方法改變時，就必須重新確認原有授權是否仍然涵蓋這些活動。

第二，停止相關測試不一定代表整個專案永久取消。是否可以繼續其他測試、何時可以恢復，應依事先約定的應變與核准程序辦理。

八、CEH 考試與實務必記重點

這堂課不需要背誦大量工具或指令。

最重要的是能夠區分以下概念。

特別注意：

Authorization、Scope 和 ROE 是不同的管理概念，但實際文件可以整合在同一份測試計畫中。

而且，無論是執行滲透測試、弱點掃描，或其他安全評估活動，都應先確認相應授權與測試規則。

九、本堂課理解測驗

請先不要查答案，試著用自己的話回答。

題目一：觀念題

一名工程師擁有公司內部系統的管理員帳號。

他認為自己既然是管理員，應該就可以對該系統進行任何安全測試。

請問他的觀念有什麼問題？

題目二：CEH 情境題

你獲得正式授權，可以在今天 14:00～15:00 之間，測試 A 網站的帳號權限。

14:50，你發現 A 網站會連到 B 伺服器。

B 不在原本核准的測試清單上。

你認為 B 可能存在嚴重弱點。

下列哪個做法最合適？

A. 因為 A 可以連到 B，所以 B 自動包含在授權範圍內，可以測試。

B. 只要不造成系統損壞，就可以先測試 B，之後再通報。

C. 不對 B 進行進一步測試，先記錄線索並向授權窗口確認，必要時取得新增授權。

D. 先使用 AI 推薦的工具掃描 B，確認有沒有弱點，再決定是否申請授權。

題目三：實務判斷題

假設你已經在 Northstar 的測試環境中，發現 Alice 可以讀取 Bob 的虛構作答。

你認為怎樣的證據才足以證明問題？

是否需要進一步取得其他 100 名學生的資料？

請說明你的判斷理由。

十、今日學習總結

今天只需要牢記三句話：

Authorization：誰有權批准？

Scope：批准測試哪些東西？

ROE：批准怎麼測，以及什麼時候必須停止？

這些觀念是後續學習 CEH M02（Footprinting）、M03（Scanning Networks）、M04（Enumeration）乃至 M06（System Hacking）之前的重要基礎。

因為無論是蒐集資訊、掃描網路、列舉帳號，還是驗證漏洞，技術上可以做到的事，都不會因此自動成為被允許的事。

參考資料：NIST SP 800-115《Technical Guide to Information Security Testing and Assessment》，第 6～8 章及附錄 B。

下一步：請先回答上述三題。我會依照你的答案，判斷你是否已經掌握今天的核心概念，並針對尚未理解的部分補強，而不是直接進入下一堂課。

編輯補充：本頁以提供的十節教材為主，保留原文的先作答提示；參考解答已依教學格式置於下方收合區。答案已公布不代表讀者已理解，也不會因此變更系列既有排程或新增一次概念交付。

展開題目1參考解答｜管理員就能任意測試嗎？

不行。管理員帳號代表技術上能做的事比較多，不代表組織已授權你做所有安全測試。要另外確認有權批准的人、指定目標、可用方法及時間。

最容易混淆的地方是「我能操作」和「我獲准操作」。即使沒有造成損壞，越過約定範圍仍然可能有問題。

展開題目2參考解答｜A連到B，可以直接測B嗎？

選C。先不對B進行進一步測試，記錄已看到的線索，向授權窗口確認；需要時取得涵蓋B的新授權及更新規則。

A能連到B、不會造成損壞、AI推薦某工具，這三件事都不是B的測試授權。原先A的測試時間仍到15:00，不能自行延長。

展開題目3參考解答｜證據需要多少才夠？

在已核准的虛構測試資料範圍內，記錄測試時間、環境、使用Alice身分、指定Bob作答、預期應拒絕與實際卻允許，並保留最小必要的可重現證據。

不需要自行取得其他100名學生的資料。這會擴大資料取得與測試範圍，不是證明已觀察到問題的必要步驟。若需確認其他範圍，先取得適當批准。

這些證據支持「指定情境下發生未正確限制的讀取」，不代表所有資料都已外洩，也不代表你已確認寫入權限或其他帳號的情況。