資安指南
密碼、MFA、裝置、公共 Wi-Fi、伺服器、相依套件、Git、暴露在外的環境——以目標為導向的實用指南，教你今天就能套用的防禦措施。
如何安全儲存密碼 —— 雜湊與加鹽的正確做法
面向伺服器端的密碼安全儲存實戰指南。先理解明文、加密、裸雜湊為什麼都不行，再收斂到『為每個使用者加鹽＋故意放慢的專用雜湊（首選 Argon2id，其次 bcrypt/scrypt）』。不要自己造輪子，直接用標準函式；成本參數要定期複核；既有的弱雜湊在使用者登入時重新雜湊以完成遷移。
AI 時代的安全防護｜個人開發者現在就該夯實的基本功（按優先級排序的清單）
AI 強化的不是『新弱點』，而是『自動、大規模地利用既有弱點』那一側。所以比起特別的新對策，按正確的順序夯實基本功才是最好的準備。CVE 立即打修補程式＋相依套件監控、杜絕重複使用＋MFA、清除暴露的機密、最小權限、收縮公開面、記錄/IOC 的準備、備份——全都用一份按優先級排序的清單講清楚。
AI 時代真正有效的安全對策與「無效」的那些｜小站為何也會被盯上
糾正 AI 時代的 4 個迷思。①太小不會被盯上→自動化抹掉了『人來挑目標』這一步②需要特別的新對策→基本功才最強③裝個產品就安心→比起偵測，先做到『不讓它發生』的設計④AI 生成程式碼又快又安全→連漏洞一起出貨、上線前必須複查。真正有效的，是按正確順序把不起眼的基本功做紮實。
收到了『冒充自己網域』的郵件——它和被入侵的區別，以及如何止住
即使收到自稱來自自己網域的可疑郵件，多數也不是『伺服器被入侵』，而是『寄件人(From)被偽造』。因為 SMTP 允許任意填寫 From。讀懂郵件標頭裡的 Authentication-Results、Received、Reply-To，就能分辨是入侵還是冒充。它能進到收件匣的主因是沒有設定 DMARC。用 SPF→DKIM→DMARC(p=none→reject) 的分階段引入來止住它。
備份基礎：3-2-1 原則與抵禦 ransomware 的還原計畫
備份只是「有做」還不夠，只有「已確認可以還原」才算數。基礎＝3-2-1 原則（3 份副本、2 種媒介、1 份異地）。要防 ransomware，還需要至少 1 份不是長期連接的「離線/不可變（immutable）」副本——長期連著的備份會連同本體一起被加密。雲端同步不是備份（誤刪和加密也會被同步）。多版本管理和定期還原測試才算完整的維運。
用 gitleaks 在提交前攔下金鑰：在 push 之前堵住 API 金鑰洩漏
金鑰『洩漏後再刪』就晚了。一旦被提交，金鑰就會留在 Git 歷史裡，被 push 後就要按已洩漏處理、撤銷並輪換金鑰。gitleaks 是一款免費工具，用正規表示式/熵對整個儲存庫和提交歷史進行掃描，檢出 API 金鑰、私鑰、token。防守的關鍵是兩道攔截點＝①用 pre-commit 掛鉤在本地 push 前攔住②用 CI/cron 定期抓住漏網之魚。.gitignore 只能阻止新的追蹤、無法檢出＝還需要單獨的檢測器。
雙因素認證(MFA)如何正確選擇：比 SMS 更強的「抗釣魚」是什麼
MFA 是『即使密碼洩漏也進不來』的雙重鎖，但你配了什麼會讓強度差三檔。SMS／郵件會被釣魚中繼、SIM 交換攻破，屬於弱方式；驗證器 App(TOTP)居中；passkey／實體金鑰(FIDO2)因為『無法對假站點出示』的抗釣魚特性而屬另一檔。最優先的是給王國之鑰（信箱、網域、支付）配上抗釣魚 MFA。再加上妥善保管復原碼、準備好備用手段，才算正確的維運。
還在用 Windows 10 的人請注意：支援終止後的安全風險
Windows 10 已於 2025 年 10 月 14 日終止支援。繼續使用的最大風險是『被發現卻永遠不再修復的漏洞（forever-day）』不斷堆積，從而更容易被攻擊者盯上。面向個人的 ESU 延長只到 2026 年 10 月 13 日的一年、且只有安全修復的拖延手段（有免費的登記途徑，但 EEA 首年免費不包含日本）。正路是遷移到 Windows 11 或更新裝置，ESU 只作為完成遷移之前的『橋』來用。
BitLocker 與「裝置加密」的區別 —— 同一技術的完整版與自動·簡易版
BitLocker 和裝置加密用的是同一套加密引擎。裝置加密＝Home 也能用的自動·簡易版（用 Microsoft 帳戶自動開啟、還原金鑰也自動備份、設定項極少）。BitLocker＝Pro 及以上的完整版（啟動 PIN、外接加密(To Go)、精細管理）。對個人而言，做到自動加密＋知道還原金鑰在哪，往往就夠了。比起產品名，『處於已加密狀態』才是本質。
漏洞（CVE）處置實務：徹底修復，並持續監控復發
漏洞處置不是『修了』就完事。完成＝①掃描②修復③隔離/移交④監控四點齊備才算數。尤其在加上監控（每日變化偵測）之前都算未完成——因為相依套件明天又可能變得脆弱。修復內容哪怕100分，只要下一次部署就被覆蓋，也等於0分。越是小團隊，越能靠自動變化偵測和『local→push→deploy』的紀律守得出奇地穩。
攜帶筆記型電腦外出時的安全防護 — 應對失竊、遺失與偷窺螢幕
攜帶筆電外出的前提是『總有一天會丟、會被偷』。重點在於「即使丟了內容也不洩漏」的設計＝①磁碟加密(BitLocker/FileVault) ②強登入+短自動鎖定 ③遠端清除/位置追蹤。隨著HTTPS普及，公共Wi-Fi被竊聽的風險下降，真正的威脅是偽AP、偷窺螢幕、離座。不要過度依賴VPN，優先做好加密與鎖定。
osv-scanner 的安裝與使用：用機器找出相依套件裡的 CVE
osv-scanner 是一款免費工具，掃描鎖定檔或容器以排查相依套件中的 CVE。本文把安裝、執行、CI 整合做成步驟，並理清它與 npm/pnpm audit、Dependabot 的取捨。本站的觀點＝選工具的正確答案由『你的架構』決定。多語言混用或不依賴 GitHub 就用 osv-scanner，單一 npm 用內建的 pnpm audit 就夠了。
密碼管理器安全嗎？運作原理與雲端、本機的區別，以及如何選擇
密碼管理器比重複使用、明文保存更確實地安全。關鍵在於零知識加密＝憑主密碼只有端側能解密，提供方只持有密文，所以提供方被攻破內容也不會外洩。真正的單點故障是主密碼和保險庫的 MFA。雲端型(Bitwarden/1Password)與本機型(KeePass)按用途選擇。
公共Wi-Fi的危險 — 真正可怕的不是『竊聽』，而是連上假AP和無視憑證警告
公共Wi-Fi的『竊聽』在HTTPS普及後大多已被加密，優先順序下降。真正的風險是：①自己主動連上假AP（evil twin）②無視憑證警告③把裝置暴露在同一網路裡。最強的對策出乎意料地簡單＝用手機熱點、相信HTTPS和憑證警告、不自動連線陌生SSID。VPN是其次的追加手段。
是否把金鑰檔案遺忘在了公開目錄裡：webroot 盤點
放進 webroot（公開目錄）的檔案，只要存取 URL 任何人都能取走。權杖或驗證憑證的 JSON、.env、備份一旦遺忘在那裡，立刻造成實害。再加上若源自共用範本，同一個洞會橫向擴散到所有站點。對策＝公開目錄只放可以公開的東西，金鑰放在 webroot 之外＋權限 600，並且盤點自己的伺服器、一處發現就全機排查。
個人開發 / 小規模維運的安全底線：把業界標準的對策一次配齊
最低限度的對策並非『全都一樣重』。本站的優先順序 ＝ ①王國之鑰（多因素驗證 / 網域 / 郵件）②金鑰與程式碼 ③應用程式本體 ④修補 / 偵測 / 還原。資源有限的個人，按這個順序從上往下填才是正解。多數事故並非新型攻擊，而是這塊地基的缺口造成的。
中型到大型組織的安全底線：團隊共同守護的標準基礎
規模上來後，底線會從『檢查清單』變成『有負責人的專案』。優先順序與個人版一致＝①身分②機密與供應鏈③應用程式與基礎設施④偵測與回應＋貫穿全局的人與治理。最大的變化是：事故主因從『一時疏忽』轉向『人、流程、離職者權限、第三方』。
安全資產盤點 —— 個人維運多台伺服器時最易忽略的 7 項檢查
個人維運多台伺服器的事故，往往源於「沒掌握的狀態」而非「缺少防護」。要守的邊界是放置金鑰的電腦。2FA 按信任鏈分級，SSH 金鑰矩陣化以清除重複・未使用・孤兒，明文密碼從雲端清除，整改要可逆且逐項進行，台帳裡不寫機密。比起花俏的新工具，盤點更優先。
自建 Git 伺服器和 GitHub，從安全角度看哪個更安全
自建 Git 不是『變安全』，而是『轉移風險』。誤公開這一類事故確實會消失，但伺服器修補、備份、提交前金鑰偵測的責任會轉移到你身上。滿足條件就是好選擇，放任不管則比 GitHub 更危險。本站視角＝自建維運必須連同代價一起，否則無法成立。
安全使用手機的基礎 —— 要守護的是把『鑰匙串、保險箱、身分證』裝進一台裝置的終端
手機是把二要素、郵件、銀行、身分證集中到一台裝置上的單點故障。防守的重點不是安全 app，而是①強鎖定畫面＋短自動鎖定（密碼就是加密的鑰匙）②OS／app 自動更新 ③官方商店＋權限複查 ④事先設好遺失時的遠端鎖定／清除 ⑤二要素的「備份」（紙本備份碼）。OS 預設已做加密與沙箱隔離。
不要把 root 金鑰交給可能被入侵的環境：SSH 金鑰的最小權限
從臨時且可能被入侵的環境（GPU pod、CI runner、一次性 VM）向生產登記 root 金鑰，那個環境一旦被入侵，生產就會連帶被人以 root 權限抽走。對策＝不在臨時環境放 root 金鑰／不用了就刪掉／再次需要時用非 root 使用者＋command 限制金鑰（command=「...」 restrict）把操作限定為一個。重複使用金鑰是最重要資產，別搭出『漏一把就全完』的結構。
把密碼存到 Google Drive 安全嗎？正確的保管方法
把密碼以明文形式集中保存在 Google 文件/試算表裡很危險。原因＝一個 Google 帳號會成為全部密碼的單點故障，帳號被盜、惡意關聯應用程式、釣魚都能讓全部密碼一次性外洩。正確答案是專用密碼管理器（即使在裝置間同步，內容也保持加密）。如果非要用 Drive，那只能放加密過的管理檔案＋為帳號開啟抗釣魚的 MFA。
OpenAI 帳號被封的原因與因應——被盜的 API key 為何會被判定為「蒸餾」違規
被盜的 API key 一旦被用於『蒸餾』濫用，連受害者的帳號都可能被自動凍結。本文隱去具體個案資訊，梳理其機制、預防與申訴路徑。
X-Forwarded-For（XFF）偽造是什麼 — 信任代理設定的陷阱與防禦
XFF 是用戶端可以偽造的標頭。在偽造 XFF 裡夾帶注入探測的無差別掃描是典型手法，而『信任全部代理（萬用字元）』很危險。對症處理＝對 IP 標頭做淨化，根本＝把信任代理收斂到合適範圍。即便沒有實際損害，也有該修復的設定。
用 AI 寫的程式碼洩漏了 API key，被人盜刷——真正的禍根是放著不管的 CVSS 10.0
帳單暴漲只是冰山一角。真正的禍根是放任不管、公開已久的 CVSS 10.0 RCE。本文從隱去專有名詞的案例中，提煉出防禦的教訓。
安全超入門：.env 和 API key 到底危險在哪、又該怎麼守
第一步。先理解 .env 和 API key 洩漏後會發生什麼（配出來的鑰匙→冒名頂替→被盜刷），再從今天起做好這 4 件事：『不公開、不提交、洩漏就全部更換、定期自查』。
Laravel 應用程式的 .env 被暴露給全世界——共享虛擬主機上最常見的部署錯誤
根本原因是『把應用程式本體放到了 public_html 目錄正下方』。本該只暴露 public/。按緊急處置→金鑰輪換→結構改造三個階段修復，並用機制防止再次發生。
安全維運 Next.js：建立不在已公開CVE上掉隊的機制
框架的最大風險是放任已公開的CVE。以正式環境實際版本判定，用 Dependabot/osv-scanner 做機器監控，迅速更新，並以最小權限防守，構成四根支柱。本站的視角＝個人開發者輸掉的不是知識，而是『維運的可持續性』。靠不漏看的機制取勝，而非速度。
在虛擬主機上避免 .env 被公開的目錄配置與設定
核心是『把應用程式主體放在 docroot 之外，只公開 public/』。先用 .htaccess 止血，再做結構改造實現長期防護，最後自我檢查。本站的視角＝這不是個人的疏忽，而是業界層面把『壞做法標準化』了。所以要靠機制而不是靠注意力來防禦。bootstrap-redirect 比 symlink 更牢靠。