跳至主要內容
>_ITDITD網站資安平台

資安指南

#安全基礎#MFA#金鑰管理#備份#AI 時代的防備

個人開發 / 小規模維運的安全底線：把業界標準的對策一次配齊

把個人開發者、小規模維運者最低限度該做的安全對策——只選業界標準的——濃縮到一頁裡。多因素驗證、金鑰管理、相依套件的 CVE 監控、備份等，按『王國之鑰 → 金鑰與程式碼 → 應用程式本體 → 偵測與還原』的優先順序，從本站的維運視角講清楚先填哪一格。

發布於 2026-06-11 更新於 2026-06-11 閱讀時間 4 分鐘

適用對象：個人開發者、小規模維運者中，「安全對策到底做到哪一步才算"最低限度"都搞不清」的人。這裡完全不講攻擊手法，只把被視為業界標準的地基，按優先順序濃縮到一頁裡。每一項都連結到深入文章，所以可以以此為起點，只讀自己需要的部分。

本站的視角：不是『全都做』而是『按這個順序填』

個人或小規模維運，沒有把能做的事一口氣全做完的餘力。正因如此順序至關重要。最上面的「王國之鑰」一旦被奪走，下面的任何對策都會失去意義（攻擊者能以你的身分把一切重置）。反過來，從地基開始逐層填，就能在有限的時間裡把受害機率壓到最低。這篇文章不追求知識的面面俱到，而是寫成一張能讓你立刻決定『下一格填哪裡』的地圖。

Tier 0 — 王國之鑰

多因素驗證 / 網域 / DNS / 郵件 / 支付

Tier 1 — 金鑰與程式碼

金鑰不進 git / 提交前偵測 / 金鑰的隔離與撤銷

Tier 2 — 應用程式本體

輸入驗證 / 驗證與工作階段 / TLS 與回應標頭 / 郵件驗證

Tier 3 — 修補 / 偵測 / 還原

相依套件 CVE 監控 / OS 更新 / SSH 與防火牆 / 記錄 / 備份

本站的優先順序地圖。越靠上『一旦被奪走整體就崩塌』。從上往下逐項填。
幾分鐘
公開的金鑰被濫用所需時間
已知缺口
嚴重事故的大半原因
1 處
王國之鑰一旦失守就全盤崩塌
順序
有限資源下的取勝之道

Tier 0 — 守住王國之鑰（最高優先）

這裡是一切的前提。一旦網域、郵件、伺服器管理面板被奪走，其他任何對策都會失效。攻擊者能以你的身分重設密碼、改寫 DNS、登進伺服器。所以最先要加固的就是這裡。

1

加上抗釣魚的多因素驗證

給網域註冊商、DNS、伺服器管理面板、郵件、支付都強制啟用多因素驗證。強度上 passkey / 實體金鑰（FIDO2）＞ 驗證器應用程式（TOTP）＞ 簡訊。簡訊會被 SIM 交換攻破，是最後的手段。
2

把郵件信箱當作「鑰匙的父級」最嚴密地守護

幾乎所有服務的密碼重設都會發到郵件信箱。郵件一旦失守，就會連鎖性地全部失守。唯獨郵件值得強制啟用實體金鑰。
3

安全保管還原手段與備份碼

把多因素驗證的還原碼放進密碼管理器或實體上安全的地方。一旦遺失，你自己也會被拒之門外。
4

區分使用帳號以減少單點故障

重要帳號要避免重複使用密碼，用密碼管理器讓每個都唯一。這樣某一個服務的外洩就不會橫向蔓延。

Tier 1 — 別外洩金鑰與程式碼

本站的起因，以及世上的許多事故，都源自這一塊的缺口。也就是 .env 或 API key 這類金鑰，混進程式碼或公開儲存庫而外洩的模式。

1

金鑰既不寫進原始碼也不寫進文件

把 API key、密碼、連線資訊分離到 .env 等檔案裡，並從 git 排除（.gitignore）。壓根不寫，才是最強的對策。
2

提交前用機器攔下金鑰

用 gitleaks 等 pre-commit 掛鉤，從物理上攔下含金鑰的提交。自己張起一張相當於 GitHub push protection 的網（→ 自建 Git vs GitHub）。
3

一旦外洩就以『全都外洩了』為前提全量輪換

只要有一絲懷疑，就立刻撤銷並重新簽發相關的金鑰、權杖。別用「大概沒事」放任不管。這是實際事故處置中最有效的思路（→ 金鑰外洩被惡意刷費的經歷）。
4

權杖要限定作用域、短命化

不要造一把全權限的萬能權杖。按最小必要權限、短有效期、按服務區分。這樣漏掉一把也能把損失封死。

自建 Git 尤其要當心

就算因為怕 GitHub 上「誤公開」而改成自建維運，誤提交也不會消失。反而因為沒有 GitHub 標配的金鑰攔截，提交前的金鑰偵測掛鉤在自建維運裡是必備的。詳情整理在 自建 Git 伺服器與 GitHub，哪個更安全。

Tier 2 — 把應用程式本體做硬

這是對外公開的 Web 應用程式本身的最低限度。與其防新型攻擊，本質更在於堵住常見的老缺口。本站把每個老缺口都在術語頁裡翻譯成了防禦視角。

1

不信任輸入（堵住老缺口）

來自使用者輸入的 SQL 注入、XSS、SSRF、路徑遍歷，要用跳脫 / 參數化 / 白名單來堵住。
2

把驗證、工作階段、權限做對

CSRF 對策、能看到他人資料的 IDOR 的權限驗證、防 點擊劫持 的框架控制。
3

讓 TLS 與安全回應標頭生效

強制 HTTPS、設定 HSTS、CSP 等。自己的站點可以用 安全回應標頭診斷 來打分（CSP 可用 CSP 建構器 來拼裝）。
4

防止郵件被冒充

如果用自有網域發郵件，就設定 SPF/DKIM/DMARC。可用 郵件驗證檢查器 來確認缺口。

Tier 3 — 修補 / 偵測 / 還原

這是「即便被入侵，也能把損失壓小、快速重建」的地基。像 osv-scanner 這樣的相依套件監控也歸在這裡。

1

用機器持續監控相依套件的 CVE

放任已公開的已知漏洞（CVE）不管，是最多的事故原因。把 osv-scanner 或 pnpm audit 放進 CI / cron 持續執行（→ 不在 CVE 上落後的機制）。
2

自動更新 OS 與伺服器

用 unattended-upgrades 等把 OS 的安全更新自動化。Git 伺服器和各中介軟體的修補也別放任不管。
3

加固 SSH 與防火牆

SSH 只用金鑰（關閉密碼驗證、禁止 root 直接登入），用防火牆只開放必要連接埠，用 fail2ban 拖慢暴力破解。
4

用最小權限縮小爆炸半徑

服務以非 root 執行，DB / 內部服務不對外公開。每台主機用不同的 SSH 金鑰。設計成單點被攻破不會波及整體。
5

3-2-1 備份 ＋ 還原測試

資料要 3 份副本、2 種媒介、1 份在異地。必須加密。而且不只是「有備份」，還要實際能否還原，親自試一次。
6

留下記錄以便察覺異常

留下存取、驗證、錯誤的記錄，讓自己處在能察覺異常苗頭的狀態。察覺越晚，損失越大。

從哪裡下手

「全部立刻做完」並不現實。下面把容易踩的順序，和本站建議的順序作個對比。

容易踩的順序（低效）

  • 一上來就從花俏的應用程式漏洞對策開始
  • 多因素驗證一直「以後再說」地拖著
  • 備份有在做，但從沒試過還原
  • 金鑰先丟進了 .env，但沒有偵測掛鉤

本站建議的順序

  • Tier 0：先加固王國之鑰（多因素驗證 / 郵件 / 網域）
  • Tier 1：從結構上堵住金鑰外洩（提交前偵測 ＋ 全量輪換方針）
  • Tier 2：堵住應用程式的老缺口
  • Tier 3：用相依套件監控 / 更新 / 備份還原，達到"能重建"的狀態

本站自己也按這個順序在守護

本站把這裡寫的地基應用在了自己身上。用專用伺服器不與其他服務混在一起（受害範圍的隔離）／ 每台主機用不同的金鑰 ／ 金鑰既不寫進 git 也不寫進文件 ／ 相依套件的 CVE 監控在每次部署前 ＋ 每日自動執行 ／ 向另一台伺服器做異地備份 ／ 對外請求都走安全邊界。一個教安全的站點，自己絕不能帶著缺口——所以這套優先順序，我們首先在自己身上執行。作為起因的那次事故，也並非新型攻擊，而是這塊地基的某一個缺口造成的。正因如此，我們才反覆強調：比起花俏的對策，先打好地基。

接下來讀

FAQ

Q個人開發最先該做的安全對策是什麼？
A

守住『王國之鑰』。具體來說，就是給網域註冊商、DNS、伺服器管理面板、郵件、支付帳號都加上抗釣魚的多因素驗證（passkey / 實體金鑰）。這裡一旦被奪走，其他所有對策都會失效，所以是最高優先順序。

Q最低限度的對策是不是都一樣重要？
A

不是。重要程度有明確的次序。本站建議按『①王國之鑰 → ②金鑰與程式碼 → ③應用程式本體 → ④修補 / 偵測 / 還原』的順序去填。資源有限的個人，從上往下逐項填，最能減少事故。

Q相依套件的 CVE 監控也算最低限度嗎？
A

算。用 osv-scanner 或 pnpm audit 機械地持續檢查相依套件的已知漏洞，如今已是業界標準。多數嚴重事故並非新型攻擊，而是已知缺口（CVE）被放任不管造成的。