主要閱讀了谷歌云平臺的一篇文章匙监，大概梳理翻譯了一下：https://cloudplatform.googleblog.com/2018/04/best-practices-for-securing-your-Google-Cloud-databases.html
Security is a journey, not a destination
1. First Considerations
首先要明確目標(biāo)，是自己部署一個DB server魔熏？ 或者是使用cloud provider的數(shù)據(jù)庫服務(wù)恒序？
2. Access Controls
盡可能的縮小數(shù)據(jù)庫訪問的權(quán)限瘦麸。
- 防火墻。VPC Firewalls Rules, 只允許固定幾個已知的host訪問歧胁。
- 防火墻監(jiān)控滋饲。對于防火墻的變化，有日志以及alert報警喊巍⊥犁裕可以使用工具：Forseti Security，有些云平臺本身也具備這些功能
3. Data Security
- data retention policy（數(shù)據(jù)保留策略）崭参。不需要的敏感數(shù)據(jù)可以被存檔或者刪除勿她。有許多法規(guī)(HIPAA, PCI, GDPR, SOX)來保護(hù)敏感數(shù)據(jù)。
- 監(jiān)控報警： 如果發(fā)生一些威脅到數(shù)據(jù)庫的情況阵翎，應(yīng)當(dāng)收到報警逢并，比如過高的流量負(fù)載。
- 金絲雀數(shù)據(jù)：數(shù)據(jù)庫中有一些正常時候永遠(yuǎn)也訪問不到的數(shù)據(jù)郭卫。如果這些數(shù)據(jù)出現(xiàn)在log或者網(wǎng)絡(luò)傳輸中砍聊，應(yīng)當(dāng)立即報警并自動采取一些強制措施。
- 容災(zāi)恢復(fù)計劃：制定與測試容災(zāi)恢復(fù)計劃贰军。比如備份數(shù)據(jù)庫玻蝌。好的容災(zāi)計劃應(yīng)當(dāng)考慮到盡可能多的情況：數(shù)據(jù)丟失、硬件損壞词疼、網(wǎng)絡(luò)問題等等俯树。并且經(jīng)常的測試backup system可以正常work
4. Configuration
登錄：
- 如果你的DB使用了默認(rèn)賬戶，你首先就應(yīng)該change || disable掉它贰盗。
- 如果DB使用密碼登錄许饿，確保密碼夠長夠復(fù)雜
- 此外，確保定期更換credential舵盈，制定一個更換時間表陋率；并制定一個周期外更新credentials的規(guī)則，比如密碼錯誤push到代碼庫上了秽晚，肯定要更新一次瓦糟。
- 有些Cloud Service本身提供的一些服務(wù)，比如 Google Key Managed System
權(quán)限
- read, write, admin不同的權(quán)限應(yīng)當(dāng)有不同的credentials赴蝇，盡管一個應(yīng)用既有read, 又有write的權(quán)限菩浙。可以減少bad code或者其他的風(fēng)險
- 不同的人應(yīng)當(dāng)有自己訪問數(shù)據(jù)庫的賬號，并且給予賬號所需的最小權(quán)限
日志與記錄
- 日志劲蜻。尤其是對于登錄嘗試陆淀、admin操作，要有記錄斋竞。此外日志權(quán)限與數(shù)據(jù)庫權(quán)限分開管理。
- 對于暴力強制的登錄方式秃殉，需要有monitoring & alert
- OS中為DB創(chuàng)建一個專門的用戶坝初，而不是使用root或者admin用戶。host上的文件應(yīng)當(dāng)被賦予合適的權(quán)限钾军，來阻止其他用戶對文件的修改鳄袍。
image.png
5. Application Consideration
-
連接。設(shè)計app時候吏恭，app與db的連接使用加密連接拗小。防止通過網(wǎng)絡(luò)嗅探導(dǎo)致泄密
image.png - 數(shù)據(jù)保留。如果app本身保留了一些敏感數(shù)據(jù)樱哼，確認(rèn)你需要保留他們哀九，并且采取一些額外的措施來保證他們的安全，以避免相應(yīng)的法律風(fēng)險搅幅。比如用戶你如果只想知道他們是否是同一個阅束，你可以把他們的身份id替換成hash值
- 發(fā)送的數(shù)據(jù)：所有發(fā)送到數(shù)據(jù)庫的輸入，都必須設(shè)置如sanified這樣的安全措施茄唐。應(yīng)用代碼需經(jīng)過同行評審息裸，對常見的安全漏洞，如SQL注入和XSS沪编，需要有頻繁的自動化安全掃描
- 硬件任何有權(quán)訪問數(shù)據(jù)庫的人和計算機都應(yīng)遵守組織安全策略
- 多環(huán)境呼盆，任何情況下不要在開發(fā)或者測試環(huán)境使用unsanitized的生產(chǎn)環(huán)境的數(shù)據(jù)∫侠可以增加數(shù)據(jù)庫安全性访圃，也避免一些對生產(chǎn)環(huán)境的誤操作，比如不小心給用戶發(fā)郵件相嵌，賬戶充值挽荠，等。
6. Self-Host DB concerns
通常云提供商都有很多數(shù)據(jù)庫的保護(hù)措施平绩，而自己host的話需要管理員確保每種攻擊方式都被secured.
- 數(shù)據(jù)庫擁有一個獨立的host圈匆，而不與其他service共享，并且確保最小訪問權(quán)限捏雌。
- self-host常見混合云的情況跃赚，通常在云上有一個master節(jié)點以及多個replicas節(jié)點，甚至本地也有一個副本。確保不要把數(shù)據(jù)庫連到公司局域網(wǎng)纬傲，或其他公開網(wǎng)絡(luò)满败。同時本地物理機器也應(yīng)當(dāng)physically secure，防止被盜
- Regular Attention, 確保數(shù)據(jù)庫版本更新叹括。
- IDS 入侵檢測系統(tǒng)
- 閱讀數(shù)據(jù)庫本身的文檔算墨，很多數(shù)據(jù)庫都有特別的權(quán)限控制以及安全建議, Hardening Guid.
- 本身底層的操作系統(tǒng)也應(yīng)當(dāng)盡量保證安全。并且與DB不相關(guān)的服務(wù)都應(yīng)該被停掉汁雷【秽郑可以通過sandbox或者container進(jìn)行進(jìn)一步隔離。
- 閱讀OS maker的文章侠讯，來harden os
7. Organizational Security
這個話題可就大了挖藏。。厢漩。但是有些與DB相關(guān)的膜眠。
- 所有能接觸到敏感數(shù)據(jù)的人，都應(yīng)該考慮背景溜嗜、尤其是犯罪背景調(diào)查宵膨。
- 人員下項目時候，立刻取消或鎖定用戶賬戶
- 用戶賬戶密碼遵守 2017 NIST Digital Identity Guidelines,
- 執(zhí)行social engineering penetration tests 以及培訓(xùn)炸宵，來減少員工無意中導(dǎo)致attack的風(fēng)險柄驻。
其他閱讀資料：
OS-specific hardening guides
DB-specific hardening guides
