[安全設計] 001 威脅建模入門：用 STRIDE 找出系統弱點｜DFD 資料流程圖與信任邊界實戰教學

「好的建築師不只想像住戶怎麼生活，也會想像小偷怎麼闖入。」— SSDLC by 飛飛

在 SSDLC 的旅程中，我們已經走過了「階段一：安全需求定義」，學會了怎麼用 Abuse Case 和安全驗收標準來定義「系統該防什麼」。現在，我們要進入階段二：安全設計——在畫建築藍圖的時候，就把消防通道、監視器位置、保全系統標清楚。

而安全設計的第一步，就是威脅建模（Threat Modeling）。

威脅建模是什麼？簡單說，就是在系統還沒蓋好之前，先用攻擊者的眼光把整個設計看一遍，找出哪裡可能被攻擊、哪裡最脆弱、哪裡需要加強防護。

今天要介紹的 STRIDE，是微軟在 1999 年提出的威脅分類模型，也是目前業界最廣泛使用的威脅建模方法之一。它用六個英文字母，幫你系統化地思考所有可能的威脅類型。

為什麼需要威脅建模？不做會怎樣？

先說一個真實場景。

假設你正在開發一個台灣的線上訂餐平台。功能需求很清楚：使用者可以瀏覽餐廳、下訂單、線上付款、追蹤外送進度。你的團隊很認真地寫了使用者故事、做了 UI 設計、選好了技術架構。

然後上線了。

三個月後，有人發現：

改一下 URL 裡的訂單編號，就能看到別人的訂單明細（包含地址和電話）
外送員的 API 沒有做權限檢查，任何人都能呼叫「標記已送達」
付款完成的通知用 HTTP 而不是 HTTPS，中間人可以攔截並偽造付款結果

這些問題，不是「程式寫錯」，而是設計階段就沒想到。

飛飛觀點：
威脅建模不是在找 bug，而是在找「設計盲點」。Bug 是寫錯了，盲點是根本沒想到。修 bug 改幾行程式碼就好，修盲點可能要改整個架構。這就是為什麼威脅建模要在設計階段做——越早發現，修復成本越低。

如果用蓋房子的比喻：功能設計是決定「房間怎麼隔」，威脅建模是檢查「小偷從哪裡進來」。你不會等房子蓋好才想「咦，一樓窗戶是不是該裝鐵窗」，對吧？

STRIDE 是什麼？六個字母，六種威脅

STRIDE 是六種威脅類型的首字母縮寫，每一個字母代表攻擊者可能做的一類壞事：

字母	威脅類型	英文全名	一句話解釋	生活比喻
S	身分冒用	Spoofing	假裝是別人	有人拿假身分證冒充你去銀行領錢
T	資料竄改	Tampering	偷偷修改資料	有人改了你的考卷答案
R	否認行為	Repudiation	做了壞事卻說「不是我」	鄰居偷倒垃圾卻說「我沒有」，而且沒監視器能證明
I	資訊洩露	Information Disclosure	看到不該看的資料	有人翻了你的日記
D	阻斷服務	Denial of Service	讓系統無法正常運作	有人故意堵住餐廳門口，讓客人進不來
E	權限提升	Elevation of Privilege	用低權限做高權限的事	實習生拿到總經理的辦公室鑰匙

這六種威脅基本上涵蓋了大部分的攻擊模式。讓我們用前面的訂餐平台，逐一看看每種威脅長什麼樣子。

S — Spoofing 身分冒用：「你確定他是他嗎？」

攻擊情境：攻擊者偽造或竊取使用者的身分，以該使用者的名義進行操作。

訂餐平台範例：

攻擊者取得某使用者的 JWT Token，冒充該使用者下訂單並用其儲存的信用卡付款
攻擊者架設一個假的「訂餐平台登入頁」（釣魚網站），騙使用者輸入帳號密碼
外送員用別人的帳號登入，領取不屬於自己的配送任務

對應的安全屬性：認證（Authentication）

防禦方向：多因素驗證（MFA）、Token 過期與刷新機制、防止 Session Fixation

T — Tampering 資料竄改：「資料還是原本的嗎？」

攻擊情境：攻擊者在傳輸途中或儲存端修改資料。

訂餐平台範例：

攻擊者攔截訂單請求，將金額從 NT$350 改成 NT$1
攻擊者修改外送地址，把餐點送到自己家
攻擊者竄改資料庫中的評價紀錄，將一星評價改成五星

對應的安全屬性：完整性（Integrity）

防禦方向：HTTPS 傳輸加密、數位簽章、資料庫寫入稽核、請求參數伺服器端驗證

R — Repudiation 否認行為：「你能證明是他做的嗎？」

攻擊情境：使用者或攻擊者否認自己曾經執行過某項操作，而系統無法提供證據。

訂餐平台範例：

消費者下了訂單又退貨，聲稱「我從來沒下過這筆訂單」
餐廳老闆收到客訴，卻說「我們沒有收到那張訂單」
外送員宣稱已送達，但消費者說沒收到，而系統沒有送達時的 GPS 紀錄或照片

對應的安全屬性：不可否認性（Non-repudiation）

防禦方向：完整的操作日誌（Audit Log）、時間戳記、數位簽章、關鍵操作需要二次確認

I — Information Disclosure 資訊洩露：「這些資料你該看嗎？」

攻擊情境：未經授權的人取得敏感資訊。

訂餐平台範例：

改 URL 中的訂單 ID 就能看到別人的訂單，包含姓名、電話、地址
API 錯誤回應中洩漏資料庫結構（如：<code>ERROR: column "user_password" does not exist</code>）
外送員的 API 回傳了消費者的完整信用卡號碼（應該只顯示後四碼）

對應的安全屬性：機密性（Confidentiality）

防禦方向：存取控制（確認資料所有權）、敏感資料遮罩、錯誤訊息統一化、最小化 API 回應欄位

D — Denial of Service 阻斷服務：「系統還活著嗎？」

攻擊情境：攻擊者讓系統無法正常服務合法使用者。

訂餐平台範例：

攻擊者用自動化腳本在用餐尖峰時段發送數萬筆假訂單，癱瘓訂單處理系統
攻擊者對搜尋功能發送超複雜的查詢條件，拖慢資料庫回應時間
攻擊者反覆呼叫「忘記密碼」功能，導致簡訊服務費用暴增（經濟型 DoS）

對應的安全屬性：可用性（Availability）

防禦方向：Rate Limiting、Request 大小限制、佇列機制、CDN 與 DDoS 防護、費用告警

E — Elevation of Privilege 權限提升：「你有權限做這件事嗎？」

攻擊情境：攻擊者從低權限角色獲取高權限操作能力。

訂餐平台範例：

一般使用者透過修改 API 請求參數，將自己的角色從 <code>customer</code> 改為 <code>admin</code>
外送員帳號透過 API 直接存取後台管理介面，修改餐廳資訊
攻擊者利用 Node.js 的 Prototype Pollution 漏洞，注入 <code>isAdmin: true</code> 屬性

對應的安全屬性：授權（Authorization）

防禦方向：伺服器端權限檢查（不信任前端傳來的角色）、RBAC 權限模型、輸入物件白名單驗證

飛飛觀點：
STRIDE 不是要你記住六個英文單字，而是給你一個「思考的框架」。下次設計功能時，不用再對著空白頁面想「會有什麼攻擊？」，而是可以按照 S-T-R-I-D-E 的順序逐一檢查。有框架比沒框架好，不完美的威脅建模也遠勝過完全不做。

威脅建模的核心工具：資料流程圖（DFD）

知道了六種威脅類型之後，下一個問題是：「我該對『什麼東西』做 STRIDE 分析？」

答案是：資料流程圖（Data Flow Diagram，DFD）。

DFD 不是那種複雜到讓人想睡覺的 UML 圖。它只有四種元素，畫起來非常直覺：

元素	符號	說明	範例
外部實體（External Entity）	矩形	系統之外的人或系統	使用者、第三方支付閘道、外送員 App
處理程序（Process）	圓形	系統內處理資料的元件	訂單服務、認證服務、通知服務
資料儲存（Data Store）	兩條平行線	資料存放的地方	使用者資料庫、訂單資料庫、Redis 快取
資料流（Data Flow）	箭頭	資料的流動方向	登入請求、訂單資料、付款結果通知

實戰：畫出訂餐平台的 DFD

以訂餐平台的「下訂單」功能為例，DFD 大概長這樣：

                        ┌─────────────┐
                        │  信任邊界    │
┌──────────┐           │┌───────────┐│         ┌──────────────┐
│          │  訂單請求  ││           ││ 查詢菜單 │              │
│  使用者   │──────────→││  訂單服務  ││────────→│  餐廳資料庫   │
│ (瀏覽器)  │           ││           ││         │              │
│          │←──────────││           ││←────────│              │
└──────────┘  訂單確認  ││           ││ 菜單資料 └──────────────┘
                       ││           ││
                       ││           ││ 建立訂單  ┌──────────────┐
                       ││           ││────────→│  訂單資料庫   │
                       ││           ││         │              │
                       │└─────┬─────┘│         └──────────────┘
                       │      │      │
                       │      │付款請求
                       │      ↓      │
                       │┌───────────┐│
                       ││  付款服務  ││
                       │└─────┬─────┘│
                       └──────│──────┘
                              │ API 呼叫
                              ↓
                       ┌─────────────┐
                       │ 第三方支付閘道│
                       │ (綠界/藍新)  │
                       └─────────────┘

畫 DFD 的時候，有幾個原則要注意：

原則一：從使用者的角度出發
先想使用者會做什麼操作，資料從哪裡進來、經過哪些處理、最後存到哪裡。

原則二：一次只畫一個功能流程
不要試圖把整個系統畫在一張圖上。登入是一張、下訂單是一張、退款是一張。這樣才能聚焦分析。

原則三：標示清楚每條資料流的內容
不要只畫箭頭，要寫上「這條線上跑的是什麼資料」。例如：「JWT Token」、「訂單明細（含地址、電話）」、「信用卡 Token」。這會幫助你判斷哪條資料流最敏感。

信任邊界：威脅建模最關鍵的一條線

如果 DFD 是威脅建模的地圖，那信任邊界（Trust Boundary）就是地圖上最重要的那條線。

信任邊界是什麼？就是不同信任等級之間的分界線。

用一個更直覺的比喻：想像你家的大門。門外是公共空間，什麼人都可能經過；門內是你的私人空間，只有你信任的人才能進來。那道門，就是信任邊界。

在軟體系統中，常見的信任邊界包括：

信任邊界	低信任側	高信任側	跨越邊界的資料
瀏覽器 ↔ 後端 API	使用者的瀏覽器（不可信）	你的伺服器	HTTP 請求、Cookie、JWT
後端 ↔ 資料庫	應用程式層	資料層	SQL 查詢、資料回傳
內部服務 ↔ 外部 API	你的系統	第三方服務（部分信任）	API 呼叫、Webhook 回調
使用者角色之間	一般使用者	管理員	權限檢查、操作授權
容器 ↔ 主機	容器內的應用	主機作業系統	系統呼叫、檔案存取

為什麼信任邊界這麼重要？

因為大部分的攻擊都發生在信任邊界上。

攻擊者的目標，就是找到那條線，然後想辦法跨越它：從不被信任的一側，滲透到被信任的一側。

回到訂餐平台的例子：

瀏覽器 → API：攻擊者可以自由修改瀏覽器送出的請求（竄改訂單金額、偽造身分）
API → 資料庫：如果 API 沒有做好輸入驗證，攻擊者的惡意輸入會直接到達資料庫（SQL Injection）
API → 第三方支付：如果回調通知沒有驗證簽章，攻擊者可以偽造「付款成功」的通知

飛飛觀點：
在 DFD 上標示信任邊界後，把注意力集中在每一條「穿越信任邊界的資料流」上——這些就是你最需要做 STRIDE 分析的地方。不需要對圖上的每一條線都做完整分析，先守住邊界，就能防住大部分攻擊。

實戰演練：對訂餐平台做完整的 STRIDE 分析

理論講完了，我們來實際操作一次。以下用台灣訂餐平台的「使用者下訂單」功能，走一遍完整的 STRIDE 分析流程。

步驟一：畫出 DFD（上面已經畫好了）

步驟二：標示信任邊界

在我們的 DFD 中，主要的信任邊界有三條：

使用者瀏覽器 ↔ 後端 API（最外層邊界）
訂單服務 ↔ 付款服務（內部服務間）
付款服務 ↔ 第三方支付閘道（系統 ↔ 外部系統）

步驟三：對每條跨邊界的資料流做 STRIDE 分析

以下是分析結果，整理成一張威脅清單表格：

編號	資料流	STRIDE	威脅描述	風險等級	緩解措施
T-01	使用者 → 訂單服務	S 身分冒用	攻擊者竊取 JWT 冒充使用者下單	高	Token 短效期 + Refresh Token + 裝置綁定
T-02	使用者 → 訂單服務	T 資料竄改	攻擊者竄改請求中的商品價格或數量	高	伺服器端重新查詢價格，不信任前端傳值
T-03	使用者 → 訂單服務	I 資訊洩露	透過遍歷訂單 ID 取得他人訂單資訊	高	使用 UUID 取代流水號 + 所有權驗證
T-04	使用者 → 訂單服務	D 阻斷服務	大量送出假訂單癱瘓系統	中	Rate Limiting + CAPTCHA + 訂單佇列
T-05	使用者 → 訂單服務	E 權限提升	修改請求將自己角色改為管理員	高	伺服器端從 Token 解析角色，不接受前端傳值
T-06	訂單服務 → 訂單 DB	T 資料竄改	SQL Injection 修改訂單資料	高	參數化查詢（ORM）
T-07	訂單服務 → 訂單 DB	I 資訊洩露	錯誤訊息洩漏資料庫結構	中	統一錯誤回應格式
T-08	付款服務 → 金流閘道	S 身分冒用	攻擊者偽造回調通知假裝付款成功	高	驗證回調簽章 + 白名單 IP
T-09	訂單服務	R 否認行為	使用者聲稱未下過訂單	中	完整 Audit Log + 操作前確認頁面
T-10	付款服務 → 金流閘道	T 資料竄改	中間人竄改付款金額	高	HTTPS + 金額簽章驗證

步驟四：排定優先順序

不需要一次解決所有威脅。根據「風險等級」和「修復難度」來排序：

第一優先（高風險 + 容易修）：T-02（價格驗證）、T-06（SQL Injection）、T-07（錯誤訊息）
第二優先（高風險 + 需要設計）：T-01（Token 安全）、T-03（訂單隔離）、T-08（回調驗證）
第三優先（中風險 + 持續改善）：T-04（DoS 防護）、T-09（Audit Log）

把威脅轉化為安全驗收標準

威脅建模的產出不應該只是一份文件——它應該變成可測試的安全驗收標準。這就是跟上一篇「安全需求規格書」的銜接點。

以 T-02（價格竄改）和 T-03（訂單資訊洩露）為例：

# T-02 對應的安全驗收標準
Feature: 訂單金額完整性保護

  Scenario: 前端傳送的商品價格不被信任
    Given 商品 A 在資料庫中的價格為 NT$350
    When 使用者送出訂單且請求中的商品價格被竄改為 NT$1
    Then 系統應以資料庫中的價格 NT$350 計算訂單金額
    And 不應採用前端傳送的價格

  Scenario: 訂單金額與商品價格一致
    Given 使用者將 2 份商品 A（NT$350）和 1 份商品 B（NT$200）加入購物車
    When 送出訂單
    Then 訂單金額應為 NT$900
    And 各品項金額應與資料庫即時價格一致

# T-03 對應的安全驗收標準
Feature: 訂單資料存取隔離

  Scenario: 使用者只能存取自己的訂單
    Given 使用者 A 有一筆訂單 ID 為 "order-uuid-123"
    And 使用者 B 已登入系統
    When 使用者 B 嘗試存取 GET /api/orders/order-uuid-123
    Then 系統應回傳 403 Forbidden
    And 回應中不應包含任何訂單資料

  Scenario: 訂單 ID 不可被遍歷
    Given 系統中存在多筆訂單
    When 攻擊者嘗試遍歷 GET /api/orders/1, /api/orders/2, /api/orders/3
    Then 系統應回傳 404 Not Found（不洩漏訂單是否存在）

對應的自動化測試範例：

// T-02: 價格竄改防護測試
describe('T-02: 訂單金額完整性', () => {
  it('應忽略前端傳送的價格，使用資料庫價格計算', async () => {
    const token = await loginAs('customer@example.com');

    // When: 送出訂單，但商品價格被竄改
    const response = await request(app)
      .post('/api/orders')
      .set('Authorization', <code class="kb-btn">Bearer ${token}</code>)
      .send({
        items: [
          { product_id: 'prod-001', quantity: 2, price: 1 }  // 竄改價格為 NT$1
        ]
      });

    // Then: 訂單金額應以資料庫價格計算
    expect(response.status).toBe(201);
    expect(response.body.total_amount).toBe(700); // 資料庫價格 NT$350 × 2
    expect(response.body.total_amount).not.toBe(2); // 不是竄改後的 NT$1 × 2
  });
});

// T-03: 訂單存取隔離測試
describe('T-03: 訂單資料隔離', () => {
  it('不應存取其他使用者的訂單', async () => {
    const tokenA = await loginAs('customer_a@example.com');
    const tokenB = await loginAs('customer_b@example.com');

    // Given: 使用者 A 建立一筆訂單
    const orderResponse = await request(app)
      .post('/api/orders')
      .set('Authorization', <code class="kb-btn">Bearer ${tokenA}</code>)
      .send({ items: [{ product_id: 'prod-001', quantity: 1 }] });

    const orderId = orderResponse.body.id;

    // When: 使用者 B 嘗試存取使用者 A 的訂單
    const accessResponse = await request(app)
      .get(<code class="kb-btn">/api/orders/${orderId}</code>)
      .set('Authorization', <code class="kb-btn">Bearer ${tokenB}</code>);

    // Then: 應被拒絕
    expect(accessResponse.status).toBe(403);
    expect(accessResponse.body).not.toHaveProperty('items');
    expect(accessResponse.body).not.toHaveProperty('delivery_address');
  });
});

威脅建模 Checklist：你的團隊可以直接用

以下是一份精簡的威脅建模 Checklist，適合在設計審查會議中使用：

前置準備

□ 已確定要分析的功能範圍（一次一個功能）
□ 已繪製 DFD（包含外部實體、處理程序、資料儲存、資料流）
□ 已標示所有信任邊界
□ 已標註每條資料流上傳輸的資料類型

STRIDE 逐項檢查

## S — Spoofing 身分冒用
□ 每個跨信任邊界的請求是否都有身分驗證？
□ Token / Session 的產生、傳輸、儲存是否安全？
□ 是否有防止 Session Fixation 和 Replay Attack 的機制？

## T — Tampering 資料竄改
□ 傳輸中的資料是否使用 HTTPS / TLS？
□ 伺服器是否獨立驗證所有關鍵資料（價格、數量、權限）？
□ 資料庫操作是否使用參數化查詢？

## R — Repudiation 否認行為
□ 關鍵操作（下單、付款、退款、修改權限）是否有 Audit Log？
□ Log 是否包含 who、what、when、where、result？
□ Log 儲存是否防竄改（不可被使用者或一般管理員刪除）？

## I — Information Disclosure 資訊洩露
□ API 回應是否只包含必要欄位（最小化原則）？
□ 錯誤訊息是否統一格式，不洩漏實作細節？
□ 敏感資料（密碼、Token、個資）是否有適當遮罩或加密？

## D — Denial of Service 阻斷服務
□ 對外 API 是否有 Rate Limiting？
□ 上傳功能是否有檔案大小限制？
□ 資料庫查詢是否有分頁和效能考量？

## E — Elevation of Privilege 權限提升
□ 權限檢查是否在伺服器端執行（不信任前端）？
□ 使用者角色是否從 Token / Session 取得（不接受 request body）？
□ 是否有防止 Mass Assignment / Prototype Pollution 的措施？

收尾

□ 每個識別出的威脅是否有對應的緩解措施？
□ 威脅是否已按風險等級排定優先順序？
□ 高風險威脅是否已轉化為安全驗收標準（Gherkin 格式）？
□ 威脅清單是否已記錄在專案文件中（版本化管理）？

在團隊中落地威脅建模：務實的建議

建議一：從「輕量版」開始，不要追求完美

很多團隊聽到「威脅建模」就覺得很重、很花時間。但威脅建模不需要一次就做到完美。

輕量版做法：在每次 Sprint Planning 或 Design Review 時，花 30 分鐘做以下動作：

畫一張簡單的 DFD（白板就好，不需要專業工具）
標出信任邊界
對每條跨邊界的資料流，快速過一遍 STRIDE
把識別出的威脅記錄在 Issue Tracker（如 Jira、GitHub Issues）

30 分鐘的威脅建模，遠勝過 0 分鐘。

建議二：指定一位「威脅建模引導者」

這個角色不需要是資安專家。他的工作是：

確保每次設計新功能時，都有人問：「我們做過 STRIDE 分析嗎？」
引導團隊在白板前畫 DFD、標信任邊界
把討論結果記錄下來

這跟上一篇提到的 Security Champion 是同一個角色——在團隊中推動安全思維的人。

建議三：把威脅建模的產出與程式碼綁在一起

威脅清單不要只放在 Confluence 上吃灰塵。建議在專案目錄中建立 <code>threats/</code> 資料夾：

/project
  /src
  /tests
  /specs
  /threats
    login-flow.md       ← 登入功能的威脅分析
    order-flow.md       ← 下單功能的威脅分析
    payment-flow.md     ← 付款功能的威脅分析

每份威脅分析文件包含：DFD 圖（可以用 ASCII art 或 Mermaid）、STRIDE 分析表格、對應的緩解措施、連結到相關的安全驗收標準。

這樣做的好處是：威脅分析會跟著程式碼一起被版本控制，團隊成員可以在 Code Review 時交叉參考。

建議四：善用工具，但不依賴工具

以下是一些免費的威脅建模工具：

工具	特點	適合
OWASP Threat Dragon	開源、支援 DFD 繪製、自動產生 STRIDE 威脅	想要圖形化介面的團隊
Microsoft Threat Modeling Tool	微軟出品、功能完整、有威脅知識庫	Windows 環境的團隊
draw.io / Excalidraw	通用繪圖工具，彈性大	喜歡自由繪製的團隊
Mermaid	純文字語法、可版本控制	開發者友善、CI 整合

飛飛觀點：
工具只是輔助。一塊白板加六支彩色筆，就能做出很棒的威脅建模。重點不是圖畫得多漂亮，而是團隊有沒有一起思考過「攻擊者會怎麼做」。

常見問題 FAQ

Q1：威脅建模跟上一篇的 Abuse Case 有什麼不同？

它們是互補的，但切入角度不同：

面向	Abuse Case	威脅建模（STRIDE）
切入角度	從單一功能出發，思考攻擊者怎麼濫用	從系統架構出發，系統化盤點所有威脅
適合時機	撰寫安全需求規格時	系統設計或架構審查時
產出格式	Abuse Case 表格 + 安全驗收標準	DFD + STRIDE 威脅清單 + 緩解措施
關注層面	業務邏輯層面的攻擊	技術架構層面的威脅

最佳實踐是兩者搭配使用：先用 STRIDE 找出系統層面的威脅，再對高風險的功能用 Abuse Case 深入分析。

Q2：我們的系統很小，也需要做威脅建模嗎？

系統越小，威脅建模越快。一個三頁功能的小系統，30 分鐘就能做完基本的 STRIDE 分析。而且小系統一旦出事，影響可能比你想的大——因為小團隊通常也沒有專職資安人員來善後。

建議至少對以下功能做威脅建模：處理金流的功能、處理個資的功能、對外暴露的 API、認證與授權相關的功能。

Q3：STRIDE 以外還有其他威脅建模方法嗎？

有的。STRIDE 是最入門也最通用的，但如果你想更進一步：

PASTA（Process for Attack Simulation and Threat Analysis）：以風險為中心的七步驟框架，更適合企業級的完整評估
LINDDUN：專門針對隱私威脅的建模方法，適合處理大量個資的系統
Attack Tree：用樹狀結構列出達成某個攻擊目標的所有可能路徑

對初學者來說，先掌握 STRIDE 就足以涵蓋大部分常見威脅。

Q4：威脅建模的結果多久要更新一次？

建議在以下情境時更新：

系統架構有重大變更（如新增微服務、更換資料庫）
新增涉及敏感資料的功能
發生資安事件後的根因分析
每年至少全面 Review 一次

不需要每次小改動都重做，但重大變更一定要重新評估。

結語：威脅建模是一種思維方式，不是一份文件

很多人把威脅建模想成「交差用的文件」——做完往 Wiki 一放，就再也沒人看。

但威脅建模的真正價值，不在那張 DFD 或那份威脅清單，而在於團隊養成了「用攻擊者視角看系統」的思維習慣。

當你畫 DFD 時，你會自然地思考：「這條資料流上跑的是什麼？」
當你標信任邊界時，你會自然地問：「這裡的驗證夠嗎？」
當你做 STRIDE 分析時，你會自然地想：「如果我是攻擊者，我會怎麼做？」

這些思考習慣一旦內化，你設計出來的系統自然就會更安全。

就像前面說的：好的建築師不只想像住戶怎麼生活，也會想像小偷怎麼闖入。而好的開發者不只想像使用者怎麼操作，也會想像攻擊者怎麼破壞。

下一篇，我們會繼續探索安全設計階段的其他主題——安全設計原則：最小權限、縱深防禦、預設安全。在你知道威脅從哪來之後，我們來看看怎麼用設計原則把它們擋在門外。

[安全設計] 001 威脅建模入門：用 STRIDE 找出系統弱點｜DFD 資料流程圖與信任邊界實戰教學

為什麼需要威脅建模？不做會怎樣？

STRIDE 是什麼？六個字母，六種威脅

S — Spoofing 身分冒用：「你確定他是他嗎？」

T — Tampering 資料竄改：「資料還是原本的嗎？」

R — Repudiation 否認行為：「你能證明是他做的嗎？」

I — Information Disclosure 資訊洩露：「這些資料你該看嗎？」

D — Denial of Service 阻斷服務：「系統還活著嗎？」

E — Elevation of Privilege 權限提升：「你有權限做這件事嗎？」

威脅建模的核心工具：資料流程圖（DFD）

實戰：畫出訂餐平台的 DFD

信任邊界：威脅建模最關鍵的一條線

為什麼信任邊界這麼重要？

實戰演練：對訂餐平台做完整的 STRIDE 分析

步驟一：畫出 DFD（上面已經畫好了）

步驟二：標示信任邊界

步驟三：對每條跨邊界的資料流做 STRIDE 分析

步驟四：排定優先順序

把威脅轉化為安全驗收標準

威脅建模 Checklist：你的團隊可以直接用

前置準備

STRIDE 逐項檢查

收尾

在團隊中落地威脅建模：務實的建議

建議一：從「輕量版」開始，不要追求完美

建議二：指定一位「威脅建模引導者」

建議三：把威脅建模的產出與程式碼綁在一起

建議四：善用工具，但不依賴工具

常見問題 FAQ

Q1：威脅建模跟上一篇的 Abuse Case 有什麼不同？

Q2：我們的系統很小，也需要做威脅建模嗎？

Q3：STRIDE 以外還有其他威脅建模方法嗎？

Q4：威脅建模的結果多久要更新一次？

結語：威脅建模是一種思維方式，不是一份文件

延伸閱讀