我們有我們的數據庫的登錄憑據存儲在一些配置文件中,該文件簽入代碼庫存儲庫。通常我們會在開發環境中獲得開發憑證,並且將簽入該憑證。在生產中進行部署時,可以手動將其替換爲生產登錄憑證。Maitaining生產登錄憑據安全
我想知道什麼是保持安全的最佳實踐。我們做對了嗎?
我們有我們的數據庫的登錄憑據存儲在一些配置文件中,該文件簽入代碼庫存儲庫。通常我們會在開發環境中獲得開發憑證,並且將簽入該憑證。在生產中進行部署時,可以手動將其替換爲生產登錄憑證。Maitaining生產登錄憑據安全
我想知道什麼是保持安全的最佳實踐。我們做對了嗎?
而不是讓應用程序創建自己的數據庫連接考慮使用DataSource
使用JNDI訪問。這將徹底刪除應用程序中的證書,並將問題轉移到如何在JNDI中保護DataSource
?這通常會使問題更容易解決。例如,如果在應用程序所在的應用程序服務器上配置了DataSource
,則其安全性已由用於保護應用程序服務器的身份驗證系統保護。
是的,絕對保持您的生產憑據不受源代碼管理。
鎖定生產用戶帳戶,以便只有該用戶才能看到/更改配置文件,例如, UNIX上的權限應爲
-rw -------
即使它在目錄應該是禁地未經授權的用戶。
限制對生產服務器:儘可能少的用戶帳戶越好,審計,物理訪問限制,如鎖定的服務器機房等
編輯:爲了澄清,我的建議保持憑證出源代碼控制的基本原理通常情況下,特別是在大公司中,開發團隊不允許生產憑證被認知/使用。在某些地方,開發人員甚至登錄到生產數據庫可能會被解僱。特別是如果他們再破壞一些東西
此外,其他團隊/部門的開發人員可能擁有源代碼管理權限,這可能會嚴重影響生產數據庫。當然,如果你是一個3人開發組織,這不是一個問題。
如果您的存儲庫是內部存儲並且不與任何不應訪問這些憑據的人共享,那麼您的方法就沒有問題。
但是,事情可能會改變,在這些事情上它是偏執狂。我通常做的是在源代碼控制中保留一個空的框架配置文件(使用不同的擴展名或其他),然後讓源代碼控制忽略正確的配置文件。這種方式在從源代碼控制部署新版本時不會被覆蓋。
Brians建議保持儘可能限制的東西是好建議!