密鑰、密碼提交到 Git 了怎麼辦提示詞（先吊銷輪換，再評估影響、清理歷史、加防護）
發現 API 密鑰、數據庫密碼、訪問令牌被提交進 Git 倉庫（甚至已經推送到公開倉庫）時用：AI 按「止損 → 評估 → 清理 → 預防」的順序給出應急清單，強調第一步是立即吊銷並更換密鑰，而不是先忙着改寫 Git 歷史。
通用大模型 對話模型通用
我不小心把密鑰提交到了 Git 倉庫，請你作為安全應急負責人，帶我按正確順序處理。 - 泄露的是什麼：[泄露內容]（例：雲服務訪問密鑰、數據庫密碼、支付平台密鑰） - 倉庫可見性：[倉庫可見性]（可選：公開/私有/不確定） - 是否已推送到遠程：[是否已推送] - 提交後經過了多久：[經過時間] - 這個倉庫有哪些人和系統能訪問：[訪問範圍]（例：團隊 10 人、CI 系統、已被他人復刻） 請按以下順序給出清單，每一步說明為什麼要先做它： 1. 立即止損（最先做，不要等清理完 Git 歷史）： - 到對應平台吊銷或停用泄露的密鑰，生成新的密鑰； - 更新所有使用這個密鑰的地方（伺服器配置、CI 密鑰、團隊成員本地環境），確認業務恢復正常； - 說明為什麼「刪掉文件再提交一次」或「改寫歷史」都不能代替吊銷：公開倉庫可能已被自動化程序掃描抓取，復刻和本地副本也保留着歷史。 2. 評估影響： - 到對應平台查看這個密鑰在泄露時間段內的使用記錄與帳單，是否有異常調用； - 這個密鑰的權限範圍有多大，能訪問哪些數據； - 如果涉及用戶數據可能被訪問，提醒我按公司流程上報安全與法務團隊。 3. 清理倉庫： - 在當前代碼中改為從環境變量或密鑰管理服務讀取； - 是否需要改寫歷史：權衡利弊（改寫歷史需要所有協作者重新同步）；需要時推薦的工具和步驟； - 代碼託管平台上可能還需要的額外處理（例如緩存的視圖、已有的拉取請求）。 4. 預防： - 在 .gitignore 中忽略本地配置文件，提供不含真實值的示例配置文件； - 提交前的密鑰掃描鉤子、代碼託管平台的密鑰掃描與推送保護； - 使用權限更小、可以設定有效期的密鑰。 輸出成可以逐項勾選的清單，並給出相關命令。各平台吊銷密鑰的具體入口以平台官方文檔為準。
高亮處換成你自己的內容：[泄露內容]、[倉庫可見性]、[是否已推送]、[經過時間]、[訪問範圍]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[倉庫可見性] 和 [經過時間] 決定緊急程度：公開倉庫中的密鑰可能在幾分鐘內被自動化程序掃描到，必須馬上吊銷。[訪問範圍] 如果包括「已被他人復刻」，改寫歷史的意義就更小了，吊銷是唯一可靠的辦法。
常見坑：
- 第一反應是刪除文件、強制推送改寫歷史，花了半天，卻沒有吊銷密鑰。密鑰一旦公開過，就應該視為已經泄露。
- 只在代碼裏換了新密鑰，又直接寫死在代碼中提交，問題原樣重現。改為從環境變量或密鑰管理服務讀取。
- 吊銷後忘記更新 CI 或其他伺服器上的配置，導致線上服務中斷。吊銷前先列出所有使用這個密鑰的地方。
追問技巧：追問「幫我寫一個提交前掃描密鑰的配置」，或「把項目裏所有寫死的配置項整理出來，改造成環境變量並生成示例配置文件」。
示例輸出
示例，僅供參考（節選）
第 1 步：立即止損
- 在雲平台控制台停用泄露的訪問密鑰，創建新的密鑰，權限只保留實際需要的範圍；
- 更新：生產伺服器環境變量、CI 中的倉庫密鑰、本地開發配置；
- 驗證：業務接口正常、舊密鑰調用返回鑑權失敗。
第 3 步：清理倉庫
bash
# 當前代碼改為讀取環境變量後，忽略本地配置文件
echo ".env" >> .gitignore
git rm --cached .env
git commit -m "chore: 移除本地配置文件，改為環境變量"是否改寫歷史：私有倉庫、協作者少時可以考慮；公開倉庫即使改寫了歷史，也必須以吊銷密鑰為準。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～