千萬級資料並行如何處理?進入學習
長期以來,資料庫一直是你的平衡架構的重要組成部分,並且可以說是最重要的部分。如今,壓力已經朝向你的大部分一次性和無狀態的基礎設施,這給你的資料庫帶來了更大的負擔,既要可靠又安全,因為所有其他伺服器不可避免地會連同其餘資料一起在資料庫中儲存有狀態資訊。
你的資料庫是每個攻擊者想要獲取的大獎。隨著攻擊變得更加複雜和網路變得更加敵對,採取額外步驟來強化資料庫比以往任何時候都更加重要。
MySQL 因其速度和整體易用性而成為開發人員和管理員最受歡迎和喜愛的資料庫。不幸的是,這種易用性是以犧牲安全為代價的。即使 MySQL 可以設定有嚴格的安全控制,你的普通預設 MySQL 設定可能不會使用它們。在本文中,我將介紹強化 MySQL 資料庫應採取的五個重要步驟。
對於所有資料庫使用者來說,使用強密碼很重要。鑑於大多數人不會經常手動登入資料庫,請使用密碼管理器或命令列工具 pwgen 為你的資料庫帳戶建立一個隨機的 20 個字元的密碼。即使你使用額外的 MySQL 存取控制來限制特定帳戶可以登入的位置(例如將帳戶嚴格限制為 localhost),這依然很重要。
設定密碼的最重要的 MySQL 帳戶是 root 使用者。預設情況下,在許多系統中,該使用者沒有密碼。特別是,基於 Red Hat 的系統在安裝 MySQL 時不會設定密碼;雖然基於 Debian 的系統會在互動式安裝期間提示您輸入密碼,但非互動式安裝(就像您可能使用設定管理器執行的那樣)會跳過它。此外,你仍然可以在互動式安裝期間跳過設定密碼。
你可能認為讓 root 使用者不輸入密碼並不是什麼大的安全風險。畢竟,使用者設定為 「root@localhost」,你可能認為這意味著你必須先 root 計算機,然後才能成為該使用者。不幸的是,這意味著任何可以從 localhost 觸發 MySQL 使用者端的使用者都可以使用以下命令以 MySQL root 使用者身份登入:
*$ mysql — user root*
因此,如果你不為 root 使用者設定密碼,那麼任何能夠在您的 MySQL 機器上獲得本地 shell 的人現在都可以完全控制你的資料庫。
要修復此漏洞,請使用 mysqladmin 命令為 root 使用者設定密碼:
$ sudo mysqladmin password
不幸的是,MySQL 以 root 使用者身份執行後臺任務。一旦你設定了密碼,這些任務就會中斷,除非採取額外的步驟將密碼寫死到 /root/.my.cnf 檔案中:
[mysqladmin] user = rootpassword = yourpassword
但是,這意味著你必須將密碼以純文字形式儲存在主機上。但是你至少可以使用 Unix 檔案許可權將對該檔案的存取限制為僅 root 使用者:
sudo chown root:root /root/.my.cnf sudo chmod 0600 /root/.my.cnf
匿名帳戶是既沒有使用者名稱也沒有密碼的 MySQL 帳戶。你不希望攻擊者在沒有密碼的情況下對你的資料庫進行任何形式的存取,因此請在此命令的輸出中查詢使用空白使用者名稱記錄的任何 MySQL 使用者:
> SELECT Host, User FROM mysql.user; + — — — — — — — — — — — — + — — — -+ | Host | User | + — — — — — — — — — — — — + — — — -+ | 127.0.0.1 | root | | ::1 | root | | localhost | | | localhost | root | + — — — — — — — — — — — — + — — — -+ 4 rows in set (0.00 sec)
在這些根使用者中間有一個匿名使用者( localhost ),它在 User 列中為空。你可以使用下面命令清除特定的匿名使用者:
> drop user ""@"localhost"; > flush privileges;
如果你發現任何其他匿名使用者,請確保將其刪除。
最小特權原則是一項安全原則,可以總結如下:
只為賬戶提供執行作業所需的存取許可權,而不提供更多許可權。
此原則可以通過多種方式應用於 MySQL。首先當使用 GRANT 命令向特定使用者新增資料庫許可權時,請確保僅限制該使用者需要存取資料庫的許可權:
> grant all privileges on mydb.* to someuser@"localhost" identified by 'astrongpassword'; > flush privileges;
如果該使用者只需要存取一個特定的表(例如,users 表),用mydb.users
或者任何你的表的名字替換 mydb.*
(授予對所有表的許可權)。
許多人會授予使用者對資料庫的完全存取許可權;但是如果你的資料庫使用者僅僅只需要讀取資料而不需要更改資料,則需要額外的步驟授予對資料庫的唯讀存取許可權:
> grant select privileges on mydb.* to someuser@"localhost" identified by 'astrongpassword'; > flush privileges;
最後,許多資料庫使用者不會從 localhost 存取資料庫,通常管理員會建立他們,像這樣:
> grant all privileges on mydb.* to someuser@"%" identified by 'astrongpassword'; > flush privileges;
這將允許 「someuser」從任何網路存取資料庫。但是,如果你有一組定義明確的內部 IP,或者 - 甚至更好 - 已經設定了 VLANS ,以便你所有應用程式伺服器與其它主機位於不同的子網中,那麼就可以利用這個優勢來限制 「someuser」,使得該賬戶只能從特定網路存取資料庫:
> grant all privileges on mydb.* to [email protected]/255.255.255.0 identified by 'astrongpassword'; > flush privileges;
設定強密碼僅只有攻擊者可以在網路上讀取你的密碼或者其他敏感資料的情況下才能達到此目的。因此,使用 TLS 保護你的所有網路流量比以往任何時候都更加重要。
MySQL 也不例外。
幸運的是,在 MySQL 中啟用 TLS 比較簡單。一旦你有了你的主機的有效證書,只需要在你的主 my.cnf 檔案的 [mysqld]
部分新增以下幾行 :
[mysqld] ssl-ca=/path/to/ca.crt ssl-cert=/path/to/server.crt ssl-key=/path/to/server.key
為了額外的安全性,還可以新增 ssl-cipher
設定選項,其中包含一個被認可的密碼列表,而不是隻接受預設的密碼列表,這可能包括較弱的 TLS 密碼。我推薦使用 Mozilla Security/Server Side TLS page 所推薦的現代或者中級密碼套件。
一旦伺服器端設定了 TLS ,你可以限制使用者端必須採用 TLS 進行連線,通過在 GRANT 語句中新增 REQUIRE SSL
:
> grant all privileges on mydb.* to [email protected]/255.255.255.0 identified by 'astrongpassword' REQUIRE SSL; > flush privileges;
雖然現在很多人都知道使用單向雜湊(理想情況下是像 bcrypt 這樣慢速雜湊 ),保護使用者資料庫儲存的密碼有多重要,但通常沒過多考慮使用加密來保護資料庫上其他的敏感資料。事實上,許多管理員會告訴你他們的資料庫是加密的,因為磁碟本身是加密的。這實際上會影響你的資料庫加固,不是因為磁碟加固有缺陷或糟糕的做法,而是因為它會給你一種錯誤的信任感。
磁碟加密保護你的資料庫資料,以防止有人從你的伺服器竊取磁碟(或者你買了二手磁碟後忘記擦除磁碟),但是磁碟加密並不能在資料庫本身執行時保護你,因為驅動器需要處於解密狀態才能被讀取。
要保護資料庫中的資料,你需要採取額外的措施,在儲存敏感欄位之前對它們進行加密。這樣如果攻擊者找到了某種方法來轉存完整的資料庫,你的敏感欄位仍然會受到保護。
有許多加密資料庫中欄位的方法,而且 MySQL 支援本地加密命令。無論你採取哪種加密方法,我都建議避免你需要將解密金鑰儲存在資料庫本身的加密方法。
理想情況下,你會把解密的金鑰儲存在應用伺服器上,作為本地GPG金鑰(如果你使用GPG進行加密)或者將其儲存為應用程式伺服器上的環境變數。這樣即使攻擊者可能找到一種方法來破壞應用程式伺服器的伺服器,他也必須將攻擊轉換為本地shell存取,以此來獲取你的解密金鑰。
有很多方法來鎖定你的MySQL伺服器。確切地說,你如何實施這些步驟取決於你如何設定自己的資料庫,以及它在網路中的位置。
雖然前面的五個步驟將有助於保護你的資料庫,但我認為更需要掌握的最重要的整體步驟是最小許可權原則。你的資料庫可能儲存來一些非常有用的資料,如果你確保使用者和應用程式只具有執行其工作的所需的最小存取許可權,那麼你將限制攻擊者能夠做什麼,如果駭客找到來危害該使用者或者應用程式的方法。
【相關推薦:】
以上就是【必知必會】強化MySQL應採取的五個重要安全技巧的詳細內容,更多請關注TW511.COM其它相關文章!