Security
允許自動顛覆檢查是一個壞主意嗎？
我是一名支持開發團隊的系統管理員，我們的 subversion 儲存庫受到與單點登錄解決方案相關的 HTTP 基本身份驗證的保護。我們還與其他一些團隊和潛艇共享我們的基礎設施。開發人員想要一個可以用來自動寫入 SVN 的帳戶（例如，自動簽入一些生成的腳本，或自動將整個版本發佈到一個目錄），方法是在腳本中儲存帳戶密碼或使用 SSH 進行無密碼登錄。
我在 IT 部門的一位同事認為這將是一個非常糟糕的主意，我傾向於同意，這似乎存在非常高的安全風險，無論是出於惡意意圖還是只是一個寫得不好的腳本失控並造成嚴重破壞儲存庫。然而，越來越多的人和其他團隊和潛艇不斷要求它，當我嘗試做一些自己的研究時，我無法找到任何支持材料來幫助我說服他們，這讓我想知道我是否’我錯了，它並不像我想的那麼糟糕。
我對這些自動化腳本對我們的儲存庫構成的潛在安全威脅是否正確？我是否缺少任何替代方案或保護措施？如果沒有，任何人都可以向我指出可能有助於我理解這一點的任何支持材料的方向嗎？
$$ Edit $$我忘了提到我們還使用 Jenkins 進行持續集成：http ://en.wikipedia.org/wiki/Jenkins_%28software%29
好吧，允許此類送出的安全風險完全取決於儲存庫的敏感度級別。
由於您正在進行持續集成，因此錯誤的送出肯定會燒毀您..儘管顯然有機制可以回滾錯誤的更改，但可以手動回滾錯誤的送出。最終，接受這種風險是一項商業決策。
這取決於腳本在做什麼，但您肯定可以做一些風險緩解措施；
- 確保所有自動送出都不是使用開發人員的正常帳戶完成的。您不希望保存這些密碼。
- 如果可能，您能否限制自動送出使用者僅送出特定文件或目錄樹？
- 同樣，如果可能，請考慮一個預送出鉤子，它對來自自動化任務的送出進行一些完整性檢查（如果發生任何刪除操作，或者如果超過 50 行程式碼更改，則阻止送出？） - 這可能擷取並防止讓您關注的破壞性送出進入。
另一方面，如果您的開發人員只是試圖這樣做，他們不需要鍵入
svn commit並實際輸入一個體面的送出消息，那麼絕對將他們擊落。