MYSQL安全性原則→▉收集整理▋

標籤：mysql   安全性原則   

MySQL安全性原則

導讀

資料庫安全營運是企業業務正常運轉的基石，容不得馬虎

除了MySQL自身的帳號密碼安全管理，系統層面、應用程式層面的安全性原則你注意到了嗎？
資料是企業核心資產，資料對企業而言是最重要的工作之一。稍有不慎，極有可能發生資料無意泄露，甚至被駭客惡意竊取的風險。每年業界都會傳出幾起大事件，某知名或不知名的公司被脫褲（拖庫的諧音，意思是整個資料庫被駭客盜取）之類的。
從資料安全上也可以分為外網安全及內部操作安全，下面分別討論一下。

內部操作安全性原則
1. 是否回收DBA全部許可權

    試想，如果DBA沒許可權了，日常DB營運的活，以及緊急故障處理，該怎麼實施呢？因此，

    建議在沒有成熟的自動化運 維平台前，不應該粗暴的回收DBA的太多許可權，否則可能會導致工作效率降低的，

    甚至  DBA有一種不被信任的負面情緒。

2、MySQL層安全性原則
     業務帳號最多隻可以通過內網遠程登入，而不能通過公網遠端連線。
     增加營運平台帳號，該帳號允許從專用的管理平台伺服器遠端連線。當然了，要對管理平台部署所在伺服器做好安全措施以及必要的

     安全審計策略。
     建議啟用Database Audit功能。這需要使用MySQL企業版，或者Percona/MariaDB分支版本，MySQL社區版本不支援該功能。
     啟用 safe-update 選項，避免沒有 WHERE 條件的全表資料被修改；
     在應用中盡量不直接DELETE刪除資料，而是設定一個標誌位就好了。需要真正刪除時，交由DBA先備份後再物理刪除，避免誤操作

     刪除全部資料。還可以採用觸發器來做一些協助工具功能，比如防止駭客惡意篡改資料。

3、MySQL帳號許可權規則
      業務帳號，許可權最小化，堅決不允許DROP、TRUNCATE許可權。
      業務帳號預設只授予普通的DML要求的權限，也就是select、update、insert、delete、execute等幾個許可權，其餘不給。
      MySQL初始化後，先行刪除無用帳號，刪除匿名test資料庫
      mysql> delete from mysql.user where user!=‘root‘ or host!=‘localhost‘; flush privileges;
      mysql> drop database test;
      建立備份專用帳號，只有SELECT許可權，且只允許本機可登入。
      設定MySQL帳號的密碼安全性原則，包括長度、複雜性。
    
4、關於資料備份
       記住，做好資料全量備份是系統崩潰無法修複時的最後一概救命稻草。
       備份資料還可以用來做資料審計或是用於資料倉儲的資料來源拉取之用。
       一般來說，備份策略是這樣的：每天一次全備，並且定期對binlog做增備，或者直接利用binlog server機制將binlog傳輸到其他遠程

      主機上。有了全備+binlog，就可以按需恢複到任何時間點。
      特別提醒：當採用xtrabackup的流式備份時，考慮採用加密傳輸，避免備份資料被惡意截取。

外網安全性原則
事實上，作業系統安及應用安全要比資料庫自身的安全性原則更重要。同理，應用程式及其所在的伺服器端的系統安全也很重要，

很多資料安全事件，都是通過代碼漏洞入侵到應用伺服器，再去探測資料庫，最後成功拖庫。

1、 作業系統安全建議
        運行MySQL的Linux必須只運行在內部網路，不允許直接對公網暴露，實在有需要從公網串連的話，再通過跳板機做連接埠轉寄，

        並且如上面所述，要嚴格限制資料庫帳號權限等級。
        系統帳號都改成基於ssh key認證，不允許遠程密碼登入，且ssh key的演算法、長度有要求以確保相對安全。

        這樣就沒有密碼丟失的風險， 除非個人的私密金鑰被盜。
        進一步的話，甚至可以對全部伺服器啟用PAM認證，做到帳號的統一管理，也更方便、安全。
        關閉不必要的系統服務，只開必須的進程，例如 mysqld、sshd、networking、crond、syslogd 等服務，其它的都關閉。
        禁止root帳號遠程登入。
        禁止用root帳號啟動mysqld等普通商務服務進程。
        sshd服務的連接埠號碼建議修改成10000以上。
       在不影響效能的前提下，儘可能啟用對MySQL服務連接埠的防火牆策略（高並發時，採用iptables可能影響效能，

        建議改用ip route策略）。
       GRUB必須設定密碼，物理伺服器的Idrac/imm/ilo等帳號預設密碼也要修改。
       每個需要登入系統的員工，都使用每個人私人帳號，而不是使用公用帳號。
       應該啟用系統層的Action Trail，記錄所有ssh日誌，或利bash記錄相應的操作命令並發送到遠程伺服器，然後進行相應的安全審計，

       及時發現不安全操作。
       正確設定MySQL及其他資料庫服務相關目錄許可權，不要全是755，一般750就夠了。
       可以考慮部署Bastion Host，所有串連遠程伺服器都需要先通過Bastion Host，Bastion Host上就可以實現所有操作記錄以及審計功能了。
       指令碼加密對安全性提升其實沒太大協助。對有經驗的駭客來說，只要有系統登入許可權，就可以通過提權等方式輕鬆獲得root。

2、應用安全建議
      禁用web server的autoindex配置。
      從制度層面，杜絕員工將代碼上傳到外部github上，可能存在內部IP、帳號密碼泄露的風險，真的要上傳必須先經過安全性稽核。
      盡量不要在公網上使用開源的cms、blog、論壇等系統，除非做過代碼安全審計，或者事先做好安全性原則。這類系統一般都是駭客

      重點研究對象，很容易被搞；
      在web server層，可以用一些安全模組，比如nginx的WAF模組；
      在應用程式層，可以做好代碼安全審計、安全掃描，防止XSS攻擊、CSRF攻擊、SQL注入、檔案上傳攻擊、繞過cookie檢測等安全性漏洞；
      應用程式中涉及帳號密碼的地方例如JDBC串連串配置，盡量把純文字密碼採用加密方式儲存，再利用內部私人的解密工具進行

      反解密後再使用。或者可以讓應用程式先用中間帳號串連proxy層，再由proxy串連MySQL，避免應用程式層直連MySQL；
 

總結：

1、任何高明的安全性原則，都不如內部員工的安全意識來的重要。

2、安全無小事，每個人都應銘記於心。在資料安全面前，可以適當犧牲一些便利性，當然也不能太過，否則可能得不償失。

本文出自 “boyhack” 部落格，請務必保留此出處http://461205160.blog.51cto.com/274918/1956127

MYSQL安全性原則→▉收集整理▋