數據安全架構
責編：admin ｜2015-02-09 17:54:43今年WebSense安全實驗室的調查顯示：39%的Web 攻擊目的是進行數據竊取，更有20%直接被人刷了庫；
年初，烏云平臺報告了某上市公司客戶資料數據庫被竊取，數據庫資料包含了用戶的手機、密碼、郵箱、身份證、住址、家庭成員信息、消費記錄(這個比較敏感)，他們感到鴨梨很大，所以得此機會，為他們的幾千萬用戶設計數據安全方案；
了解駭客
Web 漏洞 -> Web Shell -> 讀配置文件想找到數據庫配置連接 -> 找到可以連接到數據庫的信任服務器 -> 連上數據庫拖庫、刷庫；
1.進谷歌 找注入
2.沒注入 就旁注
3.沒旁注 用Oday
4.沒Oday 猜目錄
5.沒目錄 就嗅探
6.爆賬戶 找后臺
7.傳小馬 放大馬
8.拿權限 拖數據
針對駭客防御
Web漏洞
涵蓋方向太廣，想真正解決問題，找專業的代碼審計、風險評估專家，推薦 80vul.com、80sec.com (因為專注，所以靠譜！)
Web Shell
對程序員進行專業的安全培訓，千萬不要相信偽專家，找專注的、靠譜的！
讀取配置文件
來到了代碼級，你們程序員基本能玩死那些小癟三駭客了，配置信息加密或者藏起來，自己想辦法。大一點的企業，都是直接SOAP了，寫WebService取數據的。。。
數據庫服務器ACL
嚴格的訪問控制，粒度切記細化(數據庫用戶權限)，只允許來自WebService宿主服務器，訪問數據庫。端口級+靜態IP策略。
數據主動防御
既然駭客的最終目的是竊取數據、篡改數據，那就把數據加密，解密密匙藏起來。
現在的架構是.NET做WebServic為前端多個業務系統提供數據回調，數據庫使用的MSSQL，整個數據操作流程如下：
1.取數據：Web 前端 -> 連接配置數據庫取對應的WebService -> WebService取數據 -> DB
2.提交數據：Web前端 -> 連接配置數據庫取對應的WebService -> WebService提交數據庫 -> DB
我的建議：
一些關鍵字段在入庫時，先通過AES加密，再將加密后的內容存儲進數據庫。
AES密匙，寫死在WebService端的某個文件內，寫好后，用VS自帶的DotFuscator將.NET的WEB源代碼混淆，PHP可以采用Zend的源代碼保護方案。(至少現在還很少有人能夠將源代碼混淆后的密文完完整整的還原出來。)；WEB前端，用密匙解密給客戶端。
他們還有一個數據審計部門需要針對用戶數據進行數據挖掘：
我的建議：
劃分一個數據審計安全VLAN，不允來自任何網絡的訪問，通過你的密匙還原一份原始數據用來做審計，安全域一定要劃分隔離。
##財務保護：(今天給他們講的一個例子，當時想用3DES的，后來想想沒那個必要了。)
采用 AES 算法，每個用戶設置一個獨立的FACEID，作為加密、解密的密匙；
uid = 1063200； FACEID = 8baceca0-15e7-11e1-be50-0800200c9a66；
建立一個 dencode 和 ddecode 函數，用來針對用戶的賬戶余額(CARD_BALANCE)在SQL中進行計算。
更改用戶余額為：1000
update CARD_MEMCARD set CARD_BALANCE=d_encode('1000'，'8baceca0-15e7-11e1-be50-0800200c9a66') where CARD_UID_CD='1063200'；
查詢用戶的手機號和余額：
select MEM_MOBIL_PHONE， d_decode(CARD_BALANCE，'8baceca0-15e7-11e1-be50-0800200c9a66') where CARD_UID_CD='1063200'；
我當時還想到的一個猥瑣方法就是：數據庫的表名、字段名進行混淆，不要讓駭客一眼就看出CARD_BALANCE是用戶余額的字段。