處理需要數據庫（MySQL）密碼的腳本的安全方法是什麼？

Question

顯然，我們不想在每個腳本中對明文密碼進行硬編碼。這將使循環密碼變得困難，因爲除了密碼是以明文形式出現之外，還需要改變大量的腳本。

如果腳本將密碼作爲參數，那麼我們需要擔心修改'ps'輸出而不顯示密碼參數的值。我們也不得不擔心在shell歷史中記錄的命令。這可以通過bash上的HISTIGNORE/HISTCONTROL進行潛在的處理，但是還有其他的shell使用不同的靈活的歷史控制（例如：zsh）。 我們也可以使用命令行特定的環境變量（FOO = bar ./script），雖然'FOO = bar'不會顯示在'ps'中，但默認情況下仍然會記錄到shell歷史記錄中。此外，無論如何，一些系統會暴露其他用戶的進程環境（通過'ps'）。

可以使用一個密碼（配置）文件來存儲明文密碼。這個文件可以擁有/許可，以加強其訪問。但是，在一天結束時，您仍然擁有明文密碼。

提示也是一種選擇，但這往往不太方便（例如，儘管如此，仍然可以通過預期），並且如果腳本需要這樣的話，非交互性會變得複雜。

可以使用一些風味的加密，但是我們仍然有類似的問題來解決解密密鑰。

我應該只是去上面的一個嗎？其他選擇可能會更好嗎？人們如何處理這種情況是一種安全的方式？

這裏的一般目標是，如果攻擊者以某種方式進入使用數據庫服務器的系統，攻擊者不應該能夠組成數據庫服務器。例如，攻擊不應該能夠找到位於某處的密碼，不應該能夠觀察系統（'ps'）發現它，並且不應該能夠「及時回顧」 （shell歷史）來找到它。

我完善的意識到，有數百萬的場景（kmem，交換頁面等..等），並且大多數投注如果攻擊者得到根或物理訪問，並且沒有什麼會是100％安全。我只是真的想在之內尋找最好的方法。 :-)

Answer 1

如果腳本不使用提示，並以某種方式知道數據庫密碼，那麼攻擊者可以執行任何腳本並執行相同的操作。

如果您要求輸入密碼，您必須將其提供給某些人員，他們會將其放入腳本中，或爲每個用戶設置一個密碼，以提供多個猜測密碼（並且他們仍然會它在腳本中）。

也許有一件事需要考慮的是讓一個沒有密碼的用戶只能在適當的表上執行SELECT操作，並且只能從特定主機登錄，並要求密碼和其他用戶使用更敏感的功能？

如果你想隱藏密碼，你總是可以有一個2部分的系統。儘管你可以做非常複雜的事情，XOR（按位排他或者，在perl和大多數其他語言中）也可以成爲你的朋友。管理員和攻擊者很簡單，沒有一件是有用的。自動攻擊者可能會轉向更加肥沃的土地。您甚至可以將其中一個部件保留在另一個主機上，並使用wget或nfs或其他方法獲取它。這樣它可以作爲絆網系統的一部分被關閉。

同時，也許你需要一些tripwires或honeypots的種類，所以如果壞人來電，你可以給他們造假或甚至關閉更快。我喜歡用fail2ban進行主動防火牆。它可以根據日誌中顯示的任何內容掃描日誌文件並阻止發送給您的不想要的IP地址。它使用regexp和任何日誌文件來定義事件並在規則引擎中具有一定的靈活性。

Answer 2

我不是unix管理員，但是......如何讓腳本在無登錄帳戶下運行，並將腳本（和密碼文件）的權限設置爲500.這會限制對根目錄的訪問和腳本用戶。

Answer 3

你可能喜歡探索TPM（http://en.wikipedia.org/wiki/Trusted_Platform_Module）

很多安全產品都使用TPM存儲的關鍵安全相關的密鑰。其他想法可以使用存儲在智能卡中的證書來加密密碼。

乾杯， GK

Answer 4

你可以把用戶的主目錄（S）一個.my.cnf文件，可以訪問該腳本，與他們的信息和MySQL可以進行閱讀，而不是命令線。你還必須設置一個環境變量來指向〜/ .my.cnf，但是......我不確定它是MYSQL_HOME還是SYSCONFDIR或其他*。它仍然是一個純文本文件，但如果你限制該文件爲所有者，它應該沒問題？它至少會保留密碼ps。

MySQL: Option Files and MySQL: Password Security doc頁面都暗示了這一點。

（*免責聲明：我對任何定義沒有管理，就足以惹上麻煩）

Answer 5

根據數據的重要程度，您可以實現各種措施。

將密碼存儲在只能由root用戶讀取的文件中。讀取密鑰的腳本應以root身份啓動，讀取密碼，使用所需的最低權限的數據庫帳戶建立數據庫連接，從內存中擦除密碼，然後將下拉（How can I drop privileges in Perl?可能有所幫助）到非特權系統帳戶。

有簡單的腳本/觸發器來監控數據庫會話（會話起始和結束時間，用戶，IP地址，執行命令）在數據庫服務器上，監視系統上使用sudo的的等