1、所有的SQL exception 資訊都不能直接返回給客戶端。

2、在任何情況下使用完Connection後都要釋放連線，特別是在丟擲異常的時候也要釋放Connection。

3、表中的使用者敏感資訊要加密儲存，最好在加密的時候加入幾位隨機數。

4、所有的資料庫訪問都用preparestatement的方式或者封裝為儲存過程。

5、配置檔案中的資料庫訪問使用者名稱和密碼都加密並編碼存放。

6、系統上線執行時，僅給資料庫使用者必要的許可權。

資料庫安全一方面是系統執行安全系統執行安全通常收到的威脅如：一些網路不法分子透過網路，區域網等途徑透過入侵電腦使系統無法正常啟動，或超負荷讓計算機執行大量演算法，並關閉cpu風扇，使cpu過熱燒壞等破壞性活動。

另一方面是系統資訊保安，系統安全通常收到的威脅是駭客對資料庫入侵，並盜取想要的資料。資料庫的安全員主要是針對資料而言，包括資料獨立性，資料安全性，資料完整性，併發控制，故障恢復等幾個方面。網路的開放性給資料庫系統安全帶來了嚴重的安全隱患。

嗨，老鐵，先說說資料庫設計的注意事項，最近一個專案中，資料庫表結構的設計都是由我來設計，在設計的過程中，並沒有考慮到效能的因素，所以在規定欄位型別的時候，為了省事把許多欄位一律設定成varchar型別，varchar型別即為字串型別，因為varchar型別確實很強大，什麼東西都可以存，如果不考慮效能的話，這一個型別基本就可以滿足日常的需求了，但是如果考慮到效能，那肯定不能全部用varchar！

那麼就要提到資料型別了，在java中有以下幾種基本型別：

float 4 位元組 32位IEEE 754單精度

double 8 位元組 64位IEEE 754雙精度

byte 1位元組 -128到127

short 2 位元組 -32,768到32,767

int 4 位元組 -2,147,483,648到2,147,483,647

long 8 位元組 -9,223,372,036,854,775,808到9,223,372,036, 854,775,807

char 2 位元組

boolean 1 位元組 True或者false

String 不屬於基本型別，這是以前考試會經常考的！

這些都只是基礎知識，似乎在開發中無關緊要，毫無意義！ 錯了， 看到後面的位元組數了嗎？ 意義來了， 當我們把資料存在資料庫中的時候，這些位元組數就顯得非常重要，因為要影響到效能了，我們來看看用varchar存放的時候是什麼情況：

java程式碼：

String chinese1 = "你好";

String chinese2 = "你喝水嗎";

String chinese3 = "12233444";

String chinese4 = "fuck you man";

System.out.println("chinese1佔的位元組"+chinese1.getBytes().length);

System.out.println("chinese2佔的位元組"+chinese2.getBytes().length);

System.out.println("chinese3佔的位元組"+chinese3.getBytes().length);

System.out.println("chinese4佔的位元組"+chinese4.getBytes().length);

控制檯輸出：

chinese1佔的位元組6

chinese2佔的位元組12

chinese3佔的位元組8

chinese4佔的位元組12

存在資料庫中的時候字串所佔的位元組數是根據實際內容的長度來確定的,也就是說，如果你存放的是數字，12233444如果用int型存放的話只需要4個位元組，用字串存放需要的就是8個位元組，長度越長位元組越高！ 如果資料庫存的資料量不大，那當然沒有區別，如果存放的資料量巨大的話，效能的差異就會體現出來了！

所以說，剛剛畢業的時候一直搞不清楚為什麼老是問這些簡單的問題，原來還是有用的啊！ 所以，資料庫設計的時候不要把型別都定義成varchar ，時間型別如20200326，這種的也可以用int來存放，這樣就又節省了一些空間了！ 資料型別設計注意要設計的合適這個欄位才是最恰當的！

接下來說說java資料傳輸的安全性：

程式分成前臺和後臺，前臺呼叫後臺的時候，透過http請求到後臺的servlet中，攜帶一些引數，然後後臺透過解析這些引數去操作資料庫。 所以這些引數中很可能帶有資料庫中非常重要的欄位,例如主鍵id，或者你的賬號名稱，密碼之類的。現在壞人很多，而且壞人也很厲害，他們能擷取你的通訊資料，如果獲得到這些重要的欄位他們也許可以做一些壞事，去破壞你的資料庫！ 所以前臺和後臺之間的資料互動安全性很重要， 所以很多介面的使用都使用到了token， token是一串毫無意義的字串，被壞人知道了，他也很無奈，沒有用！ 但是這個token卻是後臺和前臺通訊的密碼。

原理是這樣的， 後臺把ID存在記憶體中，java中其實就是 定義一個static型別的 Map , key 就是token，value就是資料中的id欄位，或者別的不願意透露給前臺的欄位，tocken是隨機字串！把token告訴前臺，以後前臺要取資料，直接把token傳回來，然後去用token取出這個存放的ID，token一般是在登入後返回的，如果token不正確，那就要讓它重新登入了！這樣就可以防止資料洩露！ 這種方法比直接傳ID要安全的多！

　1、資料庫設計最起碼要佔用整個專案開發的40%以上的時間

　　資料庫是需求的直觀反應和表現，因此設計時必須要切實符合使用者的需求，要多次與使用者溝通交流來細化需求，將需求中的要求和每一次的變化都要一一體現在資料庫的設計當中。如果需求不明確，就要分析不確定的因素，設計表時就要事先預留出可變通的欄位，正所謂“有備無患”。

　　2、資料庫設計不僅僅停留於頁面demo的表面

　　頁面內容所需要的欄位，在資料庫設計中只是一部分，還有系統運轉、模組互動、中轉資料、表之間的聯絡等等所需要的欄位，因此資料庫設計絕對不是簡單的基本資料儲存，還有邏輯資料儲存。

　　3、資料庫設計完成後，專案80%的設計開發在你腦海中就已經完成了

　　每個欄位的設計都是有他必要的意義的，你在設計每一個欄位的同時，就應該已經想清楚程式中如何去運用這些欄位，多張表的聯絡在程式中是如何體現的。換句話說，你完成資料庫設計後，程式中所有的實現思路和實現方式在你的腦海中就已經考慮過了。如果達不到這種程度，那當進入編碼階段後，才發現要運用的技術或實現的方式資料庫無法支援，這時再改動資料庫就會很麻煩，會造成一系列不可預測的問題。

　　4、資料庫設計時就要考慮到效率和最佳化問題

　　一開始就要分析哪些表會儲存較多的資料量，對於資料量較大的表的設計往往是粗粒度的，也會冗餘一些必要的欄位，已達到儘量用最少的表、最弱的表關係去儲存海量的資料。並且在設計表時，一般都會對主鍵建立聚集索引，含有大資料量的表更是要建立索引以提供查詢效能。對於含有計算、資料互動、統計這類需求時，還要考慮是否有必要採用儲存過程。

　　5、新增必要的（冗餘）欄位

　　像“建立時間”、“修改時間”、“備註”、“操作使用者IP”和一些用於其他需求（如統計）的欄位等，在每張表中必須都要有，不是說只有系統中用到的資料才會存到資料庫中，一些冗餘欄位是為了便於日後維護、分析、拓展而新增的，這點是非常重要的，比如駭客攻擊，篡改了資料，我們便就可以根據修改時間和操作使用者IP來查詢定位。

　　6、設計合理的表關聯

　　若多張表之間的關係複雜，建議採用第三張對映表來關聯維護兩張表之間的關係，以降低表之間的直接耦合度。若多張表涉及到大資料量的問題，表結構儘量簡單，關聯也要儘可能避免。

　　7、設計表時不加主外來鍵等約束性關聯，系統編碼階段完成後再新增約束性關聯

　　這樣做的目的是有利於團隊並行開發，減少編碼時所遇到的問題，表之間的關係靠程式來控制。編碼完成後再加關聯並進行測試。不過也有一些公司的做法是乾脆就不加表關聯。

　　8、選擇合適的主鍵生成策略

這個問題說大其實可以很大，說小就看個人的理解力了。

資料庫設計的安全性：

其實這個提法很奇怪，一般在資料庫設計的時候多考慮的是系統功能的實現、彈性和耦合性，一般的安全不在資料庫設計階段，在程式碼開發和系統資料庫漏洞方面，如果非要說設計階段的安全性，我的理解：

採用的資料庫選型：如果你的選型是比較老的資料庫，已經很久沒有更新了，一些漏洞沒有及時修補，那就會出現資料庫的安全性，但是嚴格來說，不是設計的安全性

欄位設計的不合理：比如一個姓名欄位，你只設計成varchar(10)，那就很容易在應用過程中出現錯誤，直接丟擲資料庫的錯誤，讓別有用心的人獲取到你資料庫的型別及其他一些資訊

編碼和字符集問題：主要儲存非中文字符集的時候

應用開發的安全性，這個方面可以說的就太多了，一般出問題，絕大多數都是在應用系統級別出現的問題

防注入：這個是最基本的，對一些常規的注入手段的遮蔽是必須的

介面安全性：目前系統不可能不適用介面，介面token的失效、加密措施等都需要設計，在系統適用和安全性之間做好平衡

異常容錯性：錯誤資訊的丟擲規則需要設計好，debug資訊千萬不能為了圖除錯方便在生產系統中使用

OS的安全性，包含OS補丁、元件補丁、開源元件bug修復、js控制元件漏洞修復等

網際網路時代，人與人、人與社會互動過程中產生的行為資料、畫像資料、資訊資料等正在呈指數級增長，同時資料的價值和重要性不言而喻。資料庫作為資料的載體，產品和技術也越來越成熟。近幾年，不論是商業資料庫帝國的蓬勃發展，還是開源資料技術的不斷推陳出新，資料庫技術的焦點似乎都集中在高效能、低延遲、多場景化應用方面，卻很少去關注資料庫安全。

今天我們來好好聊一聊資料庫安全。

資料庫的安全性是指保護資料庫以防止不合法使用所造成的資料洩露、更改或損壞。安全保護措施是否有效是資料庫系統的主要技術指標，而資料安全如同一個木桶，整個防護體系是否堅固完全取決於短板。因此即使網路層、作業系統的安全防護已相對完善，如果存放核心資訊的資料庫得不到應有的保護，同樣會造成較為嚴重的資料安全危機。

這樣的資料安全事故正在給高速發展的網際網路服務發出一個“資料安全危機”的紅色預警。接下來我們一起盤點“資料安全”的幾大重災區——“天災”（自然災害、IDC故障）和“人禍”（駭客攻擊、資料資訊洩露、人為操作失誤）。

天災和人禍

一、“天災”

火災、地震、雷擊等自然災害對資料中心造成的物理傷害會導致資料安全危機。比如雷擊，輕微情況可引起裝置短路故障，嚴重則會引發火災。同時IDC也存在著斷電、網路故障、裝置老化等一系列影響資料安全的因素。

某商業銀行核心系統資料庫中心出現故障，導致存取款、網銀、ATM等多項業務中斷長達30多個小時，異地分支機構完全依靠手工辦理業務。

二、“人禍”

人為導致的資料安全危機佔資料安全故障總數的的70%。怎麼樣，這個資料是不是觸目驚心。

其中也可以分為有意操作和誤操作。有意操作是指明知道一些操作會造成資料中心故障，仍執意去做的，這些人往往希望透過造成資料庫系統執行癱瘓，而達到不可告人的目的。常見的有駭客、情報人員、商業機密小偷等等，他們攻擊的物件往往是資料庫裡的資料。

國內知名資訊保安團隊“雨襲團”釋出報告稱，在一年半的時間內，高達8.6億條個人資訊資料被明碼標價售賣，個人資訊洩露造成的總體經濟損失達915億元，在鉅額損失背後是隱藏極深卻又龐大的黑色產業鏈，即資料黑產。

誤操作是指本意並不想破壞資料庫系統，但是由於技術積累經驗不夠或疏忽引發了資料安全故障。這種故障佔到了人為故障的80%以上。網上一直以來都個膾炙人口的段子“從刪庫到跑路”來調侃這一現象。

印度McDelivery（麥樂送）應用洩露了220多萬麥當勞使用者的個人資料。此次使用者資料洩露的根源在於McDelivery公開可訪問的API端點（用於獲取使用者詳細資訊）未受保護。駭客利用該問題列舉該應用的所有使用者，併成功竊取了使用者的資料。

某物流公司工程師在操作刪庫過程中，錯選了RUSS資料庫，打算刪除執行的SQL。在選定刪除時，因其操作不嚴謹，游標回跳到RUSS庫的例項，在未看清所選內容的情況下，便透過執行刪除，RUSS庫被刪去，導致物流系統故障，無法使用並持續約590分鐘。該程式設計師也因為操作問題被“跑路”了。

關於資料庫安全危機的預防與應對，資料君也走訪了諸多初高階DBA。

初級策略：

重啟系統，重啟系統，重啟系統，重要的事情說三遍；

先冷備恢復，然後從增量log裡面恢復實時資料；

先策劃好方案，沒有出來方案之前，先按兵不動，防止二次事故發生；

磁碟資料恢復；

別自建資料庫系統了，用雲資料庫。

高階觀點：

資料庫系統的監控手段和歷史資訊記錄為系統的穩定執行提供了保障，透過對這些資料分析，不僅可以找到故障原因，還可以根據進行最佳化，避免發生二次故障；

從初期的資料中心規劃設計，到機房建成的驗收測試，再到機房運營過程中對於機房的定期檢測和對於突發狀況的預案等，每一項都需要經過嚴格的審查；

禁止使用儲存程序，儲存程序難以除錯和擴充套件，更沒有移植性；

資料訂正時，要先select，避免誤刪去，確認無誤才能更新句子；

重要資料永遠不要直接刪去，標記為“刪去”狀態。不能給程式的使用者all privileges、delete、drop等高危命令的許可權；

應用的網路進行分層規劃（接入層、應用層、資料層）。資料層只對固定的應用伺服器開放，資料庫儘量只放在內網；

周密的備份，即使管理員跑路也不怕。