[security] 資訊安全基礎概念：建立安全思維的起點

cover

資訊安全基礎概念：建立安全思維的起點

安全的第一步不是學工具，而是學會用攻擊者的眼光看自己的系統。

為什麼開發者需要懂資安

常見的誤解：「我們有資安團隊，安全是他們的事。」

現實是：

80% 的安全漏洞來自程式碼層面（OWASP 統計），不是基礎設施
資安團隊做的是審查和監控，漏洞是開發者寫出來的
等資安團隊在 code review 時才發現問題，修復成本已經是開發階段的 10 倍以上

你不需要成為資安專家，但你需要在寫每一行 code 時都帶著一個背景問題：「這個東西可以被怎麼濫用？」

CIA Triad — 安全的三根柱子

所有安全問題都可以歸類到這三個面向：

graph TD
    A[CIA Triad] --> C[Confidentiality<br/>機密性]
    A --> I[Integrity<br/>完整性]
    A --> AV[Availability<br/>可用性]

    C --> C1[「只有該看到的人能看到」]
    I --> I1[「資料沒有被偷改」]
    AV --> AV1[「需要用的時候用得到」]

    style C fill:#E91E63,color:#fff
    style I fill:#2196F3,color:#fff
    style AV fill:#4CAF50,color:#fff

面向	被破壞時的例子	開發者常犯的錯
機密性	使用者密碼外洩、API key 被看到	密碼明文儲存、log 裡印出敏感資訊、.env 推上 GitHub
完整性	訂單金額被竄改、資料庫被注入	沒有做 input validation、SQL 用字串拼接
可用性	網站被 DDoS 打掛、服務 OOM crash	沒有 rate limiting、沒有 graceful degradation

思維方式： 每次設計一個功能，用這三個面向掃一遍。「這個資料的機密性夠嗎？完整性有保護嗎？可用性考慮了嗎？」

OWASP Top 10 — 最常見的安全風險

OWASP（Open Web Application Security Project）每隔幾年會更新一次「最常見的 Web 安全風險」清單。你不需要背這個清單，但需要理解每一項背後的思維模式。

#	風險類型	一句話理解	開發者該想的
1	Broken Access Control	使用者能做他不該做的事	「這個 API 有檢查權限嗎？」
2	Cryptographic Failures	敏感資料沒加密或加密方式太弱	「密碼有 hash 嗎？用的是 bcrypt 還是 MD5？」
3	Injection	使用者輸入被當成程式碼執行	「這個 input 有經過 sanitize 嗎？」
4	Insecure Design	設計階段就有安全缺陷	「我有想過這個功能可以被怎麼濫用嗎？」
5	Security Misconfiguration	設定不當（預設密碼、debug mode 開著）	「production 環境的設定跟 dev 一樣嗎？」
6	Vulnerable Components	用了有漏洞的第三方套件	「npm audit 上次跑是什麼時候？」
7	Authentication Failures	身份驗證機制有漏洞	「session 有設過期嗎？token 有驗簽嗎？」
8	Data Integrity Failures	沒有驗證資料和軟體的完整性	「CI/CD pipeline 有檢查 dependency 的 hash 嗎？」
9	Logging Failures	安全事件沒有被記錄	「登入失敗有 log 嗎？誰在看這些 log？」
10	SSRF	伺服器端被騙去請求內部資源	「這個 URL 是使用者給的嗎？我有限制它能連到哪嗎？」

威脅模型 — 系統化地思考「誰會攻擊我」

威脅模型（Threat Modeling）是一個思考框架，幫你系統化地回答四個問題：

1. 我在做什麼？         → 系統架構、資料流
2. 什麼東西可能出錯？    → 威脅識別
3. 我要怎麼應對？       → 對策與優先順序
4. 我做得夠好嗎？       → 驗證

STRIDE 模型 是最常用的威脅分類法：

威脅	意思	對應的 CIA
Spoofing	偽裝身份	機密性
Tampering	竄改資料	完整性
Repudiation	否認行為	完整性
Information Disclosure	資訊洩漏	機密性
Denial of Service	阻斷服務	可用性
Elevation of Privilege	提權	機密性 + 完整性

實際做法： 拿出你的系統架構圖，在每個元件和每條資料流上套用 STRIDE，問：「這裡可能被 Spoofing 嗎？Tampering 呢？」

縱深防禦 — 不要只靠一道牆

     外部使用者
         │
    ┌────▼────┐
    │  WAF     │  ← 第一層：過濾明顯的惡意請求
    └────┬────┘
    ┌────▼────┐
    │ API GW   │  ← 第二層：認證、Rate Limiting
    └────┬────┘
    ┌────▼────┐
    │ App Code │  ← 第三層：Input Validation、權限檢查
    └────┬────┘
    ┌────▼────┐
    │ Database │  ← 第四層：Parameterized Query、最小權限
    └─────────┘

每一層都假設前一層已經被突破了。 這就是縱深防禦的核心思想。

不要想「我有 WAF 所以不用管 SQL injection」，而是「即使 WAF 被繞過，我的 code 也不會讓注入得逞」。

最小權限原則

系統中的每個元件，都只應該擁有「完成它的工作所需的最小權限」：

場景	錯誤做法	正確做法
API 服務連資料庫	用 root 帳號連	建專用帳號，只給需要的表的 SELECT/INSERT
前端呼叫 API	每個 API 都不檢查權限	每個 endpoint 明確檢查 user role
CI/CD deploy	用 admin token	建 deploy-only 的 service account
Docker 容器	以 root 跑	指定 non-root user

這個原則的價值： 即使某個元件被攻破，攻擊者也只能在有限的範圍內造成損害。

安全不是 0 或 1

一個常見的心態陷阱：「反正沒有 100% 安全，所以做了也沒用。」

正確的思維是：安全是風險管理。

風險 = 威脅 × 漏洞 × 影響

你的目標不是「零風險」，而是：

識別最大的風險在哪裡
降低最可能被利用的漏洞
限制被攻擊時的影響範圍
偵測攻擊正在發生
恢復到正常狀態的能力

反思問題

你的系統裡，密碼是怎麼存的？ 如果答不上來或答案是「MD5」，這是最該立即修的。
你上次做 npm audit（或等效工具）是什麼時候？ 你知道你的 dependency 有多少已知漏洞嗎？
如果有人拿到你的 .env 檔，能造成多大的損害？ 這個檔案裡有多少 secret？它們的權限有多大？
你的 API 有哪些 endpoint 是「只檢查有沒有登入，但沒檢查是不是該使用者」的？ 這是 Broken Access Control 最常見的形式。
你能畫出你系統的「信任邊界」嗎？ 哪裡是外部輸入進來的地方？那就是最需要防守的地方。

Terry Yao's Blog

分類

目錄