金鑰管理
該標籤下有 8 篇文章
用 gitleaks 在提交前攔下金鑰：在 push 之前堵住 API 金鑰洩漏
金鑰『洩漏後再刪』就晚了。一旦被提交，金鑰就會留在 Git 歷史裡，被 push 後就要按已洩漏處理、撤銷並輪換金鑰。gitleaks 是一款免費工具，用正規表示式/熵對整個儲存庫和提交歷史進行掃描，檢出 API 金鑰、私鑰、token。防守的關鍵是兩道攔截點＝①用 pre-commit 掛鉤在本地 push 前攔住②用 CI/cron 定期抓住漏網之魚。.gitignore 只能阻止新的追蹤、無法檢出＝還需要單獨的檢測器。
密碼管理器安全嗎？運作原理與雲端、本機的區別，以及如何選擇
密碼管理器比重複使用、明文保存更確實地安全。關鍵在於零知識加密＝憑主密碼只有端側能解密，提供方只持有密文，所以提供方被攻破內容也不會外洩。真正的單點故障是主密碼和保險庫的 MFA。雲端型(Bitwarden/1Password)與本機型(KeePass)按用途選擇。
個人開發 / 小規模維運的安全底線：把業界標準的對策一次配齊
最低限度的對策並非『全都一樣重』。本站的優先順序 ＝ ①王國之鑰（多因素驗證 / 網域 / 郵件）②金鑰與程式碼 ③應用程式本體 ④修補 / 偵測 / 還原。資源有限的個人，按這個順序從上往下填才是正解。多數事故並非新型攻擊，而是這塊地基的缺口造成的。
安全資產盤點 —— 個人維運多台伺服器時最易忽略的 7 項檢查
個人維運多台伺服器的事故，往往源於「沒掌握的狀態」而非「缺少防護」。要守的邊界是放置金鑰的電腦。2FA 按信任鏈分級，SSH 金鑰矩陣化以清除重複・未使用・孤兒，明文密碼從雲端清除，整改要可逆且逐項進行，台帳裡不寫機密。比起花俏的新工具，盤點更優先。
把密碼存到 Google Drive 安全嗎？正確的保管方法
把密碼以明文形式集中保存在 Google 文件/試算表裡很危險。原因＝一個 Google 帳號會成為全部密碼的單點故障，帳號被盜、惡意關聯應用程式、釣魚都能讓全部密碼一次性外洩。正確答案是專用密碼管理器（即使在裝置間同步，內容也保持加密）。如果非要用 Drive，那只能放加密過的管理檔案＋為帳號開啟抗釣魚的 MFA。
是否把金鑰檔案遺忘在了公開目錄裡：webroot 盤點
放進 webroot（公開目錄）的檔案，只要存取 URL 任何人都能取走。權杖或驗證憑證的 JSON、.env、備份一旦遺忘在那裡，立刻造成實害。再加上若源自共用範本，同一個洞會橫向擴散到所有站點。對策＝公開目錄只放可以公開的東西，金鑰放在 webroot 之外＋權限 600，並且盤點自己的伺服器、一處發現就全機排查。
自建 Git 伺服器和 GitHub，從安全角度看哪個更安全
自建 Git 不是『變安全』，而是『轉移風險』。誤公開這一類事故確實會消失，但伺服器修補、備份、提交前金鑰偵測的責任會轉移到你身上。滿足條件就是好選擇，放任不管則比 GitHub 更危險。本站視角＝自建維運必須連同代價一起，否則無法成立。
Codecov 竄改事件（2021）——CI 中『被信任的工具』被劫持導致機密資訊外洩的原因與防禦
根源在於『在 CI 中信任並執行的工具（curl|bash 的 Bash Uploader）在上游被竄改』。由於自己的程式碼毫髮無損，約兩個月都沒能察覺，CI 的機密資訊因此外洩。偵測靠的是總和檢查碼比對。在你的 CI 中，可用取得物的完整性檢核、機密的最小權限、輪替、egress 監控來防止重演。