想必大家一定很喜歡這個主題吧？因為現在資料庫的使用隨著數據科學大量增加，有分散式的，也有集中式的，資料庫安全也就越來越重要了。在未來犯罪技術也進步的情況下，我們身為開發者該怎麼來保證自己的資料安全呢？一起來研究看看吧！

傳統數據庫專家之人格特質 (Personality)

安總在寫這篇時遇到極大的困難，原因之一是因為傳統數據庫專家之典型人格特質，通常不是擁抱變化、享受變化的，他們通常是依據條文的 (Rule-based)；如果跟一開始的計畫不一樣，安總很容易挨罵。這跟傳統資料庫的性質很像，我們先定義好 Schema 來實作，而且部署後 CRUD 速度太頻繁會出現負載問題。

所以安總想了一陣子導入的可行性與步驟，然後佐以商業的應用價值，訂出了下列循序漸進的十大原則，為了資料庫的開發安全，希望這可以讓「數據庫人才」也能夠接受這樣轉變，學習像呼吸一樣自然。

原則1：保護連接字串 (Connection String)

為保護連接字串，我們不寫在源代碼中，而將其連線字串寫在組態檔案中 (亦可發揮組態管理、動態抽換的好處)，但密碼透過解密方式取得，步驟如下：

1. 撰寫 AES256 加密程式
2. 輸入 DB 連線的密碼，執行加密
3. 將密文貼到組態檔案中
4. 撰寫 AES256 解密程式
5. 執行讀取 DB 程式，進行解密

原則2：儲存敏感資料 (Sensitive Data)

• 敏感資料若有儲存的需求，須以加密 (Encryption)、遮罩 (Masking) 或雜湊 (Hashing) 等方式處理。
• 可運用資料字典 (Data Dictionary) 來將「敏感資料」做標記，設計資料表時參考資料字典，很快能將「敏感資料」盤點出來。
  • The Data Dictionary is a central collection of data element definitions, schema objects, and reference keys.
  • The Schema Objects can contain tables, views, indexes, procedures, functions, and triggers.
• 若是需要資料不可讀性 (unreadable) 及不可逆性 (not reversible)，則使用雜湊演算法 (Hash)，否則考慮加解密演算法。

原則3：動態資料遮罩 (Data Masking)

• 傳輸敏感資料一律使用 動態資料遮罩
  • 信用卡型：XXXX-XXXX-XXXX-1234
  • 電子郵件型：以 XXX.com 取代網域，abc@XXX.com
  • 隨機數字型：產生一個隨機數字進行資料遮罩。
  • 自訂文字型：prefix[padding]suffix，[padding] 為自訂遮罩文字

原則4：單一資料存取介面 (One Facade Interface)

• 單一資料存取介面：
  使用者只通過一個間接的用戶端介面來訪問資料庫，訪問行為也被嚴格控制，以保證資料庫和資料庫自身結構資料之機密性和完整性。
• 資料庫之前需部署一個防火牆：
  若將處於封閉或半封閉環境中之資訊系統連上網路，則其網路安全邊界需要保護。

原則5：區分使用者權限級別 (Privilege)

• 只限制允許的角色 (Role) 訪問資料庫：
  • 資料庫管理員可以指定特定的角色，只允許他們訪問資料庫。
  • 每一個角色將被分配一定的權力和許可權，客戶和公司的員工將被賦予不同的角色。
  • 任何不屬於這些角色的使用者將被拒絕訪問資料庫。
• 使用者存取級別不夠，則不回應該資料列
  (參 SQL Server 2016 之 Row Level Security 特性)。
• 多實例 (Poly-instantiation)：
  • 通過建立另一組資料迷惑「低級別使用者」，使其認為所得到之資訊為真實，而不是僅僅限制其資訊的訪問。
  • 多實例為同一客體創建了兩種不同的視圖 (View)，因此低級別的使用者無從知道真正的資訊，同時也阻止了他試圖進一步以其它途徑獲得真正的資訊。
  • 多實例是一種為沒有相應安全級別的使用者，提供替代資訊的方法。

原則6：備份檔加密 (BAK)

• 為了備援需要，我們會規劃將資料庫備份檔案 (.bak) 放置到其他媒體上，作週期性或永久的保留。
• 利用金鑰加密生成 BAK 檔，只有具備此憑證或密碼之備援資料庫，才能還原此 BAK 檔。

原則7：儲存至第三方之資料一律加密 (Always Encrypted)

• 一律加密法 (Always Encrypted) 使用時機：
  • 當機密資料存放在我們無法直接控制的位置時 (例如 Azure 等雲端儲存位置)
  • 資料庫管理委派給第三方時
  • 無法滿足 DBA 人員的安全性許可需求時
• 資料加解密會在 AP 端就開始執行，資料庫只負責接收或儲存 AP 端加密後的資料。
• 原理流程：
  • 加密金鑰在執行前會從資料庫端提供
  • 在AP端實施加密
  • 儲存在資料庫之加密金鑰也是密文，只有在 AP 端能夠解密並使用
  • 資料讀取後解密，也是在 AP 端完成
    
    資料來源：
    https://www.mssqltips.com/sqlservertip/4011/sql-server-2016-always-encrypted/

原則8：資料倉庫 (Data Warehousing)

• 資料倉庫 (Data Warehousing) 指的是為了資訊檢索和資料分析，將多個資料庫「聯合」成一個大的資料庫。
• 資料倉庫讓使用者可以不用查詢多個資料庫，而只查詢一個實體 (Entity)。
• 資料倉庫並不只是一個將各個資料庫資料鏡像到某個存儲區的過程，它是一種選擇有用資訊，然後通過處理將資料以一種更易接受的方式 (View) 表達出來的方法。展示給使用者之前，相關資料被總結和關聯，用戶得到的是經過精簡的、更適合使用者需求的資料。

原則9：資料採擷 (Data Mining)

後面這兩項原則，是結合了資料庫技術的進步，安總想要先介紹一下背景知識，方便大家導入：

• 資料採擷 (Data Mining) 是對資料倉庫中的資料，進行進一步處理以得到更有用資訊的過程。
• 資料採擷工具被用來發現資料的聯合和相關性來生成中繼資料 (Metadata)。
• 中繼資料可以用來發現單個資訊子集中隱含的相關性。它可以用來發現不明顯的異常模式，例如：
  • 如果一個資料庫中存儲了幾百萬使用者的資訊、需求、特定愛好等資料，資料採擷工具發現需求中的某種模式：每次 John Smith 搬遷二到三個月後他就會有購買保險需求。
  • 1967 年搬家後兩個月，發生了一次火災
  • 1973 年搬家後三個月，他丟失了一輛摩托車
  • 1984 年搬家後三個月，他家被強盜洗劫
  • 這樣就形成了一個異常模式。由於他多年來是幾家不同的保險公司的客戶，且數據龐雜，人工很難發現這樣的異常模式。
• 資料採擷技術可用來檢查複雜的資料，通過模糊邏輯 (Fuzzy Logic)、集合理論 (Set Theory)、神經網路 (Neural Network) 來簡化查詢，執行數學函數，查找到資料中的隱含模式。
• 中繼資料之商業價值比它的原始資料來源更高，故應受到較高度之保護。

原則10：多資料庫集群 (Database Clustering)

• 如果是單一資料庫之負載問題，則可考慮使用 Transaction 功能。
• 連線交易處理 (Online Transaction Processing, OLTP)
• OLTP 用於多資料庫集群，以提供容錯和高性能的情況。
• OLTP 可提供一種監測問題的機制，並在問題發生時立即進行適當處理，例如：
  • 如果一個進程 (Process) 由於某種原因停止處理，OLTP 中的監視機制探測到這個問題並試圖重新啟動進程。
  • 如果進程不能被重啟，正在進行的交易處理將會執行回滾 (Rollback) 操作，保證資料不會被破壞和交易 (Transaction) 處理的完整性。
  • 任何被刪除的錯誤或者非法交易處理，將會被記錄到事務日誌中，以便日後審查。
• OLTP 可以對入站請求做負載均衡
  • 如果資料庫更新請求增多，使一個系統由於負載增大而性能下降，則 OLTP 可將其中的一部分請求轉移到另一資料庫系統上。
  • 這將保證使用者或者任何發出請求之進程能被及時處理，而不必長時間地等待一個交易處理完成。

以上內容雖都是現成的技術，但摻雜了很多本人之心得感想和經驗論述，請各位務必小心服用。撰文目的僅僅是為了自我研究如何應用，並分享給 iT 邦幫忙之技術同好，非營利用途。

最近有個感想，無論做什麼事情都要先問問自己是否「動機至善、私心了無」。日本古早的工匠職人精神，工作是為了追求藝術、美的境界。對於他們來說，工作就是美的體現，美的修練。每當安總感悟於現實與理想的差異時，我總會黯自神傷，心中流淚不已，恨不得能找到一位也好，與我心深處深深嚮往的工作之美，相互共鳴。(感傷了，看書吧)

《TensorFlow + Keras 深度學習人工智慧實務應用》
《Data Science from Scratch》
其實技術或是創新性不是我們考量是否接下一件工作的重點，而是這件事情背後的價值與意涵；如果它能夠有大義名份，即便無名、無利、無人認同，我們依然自豪地說著自己的故事，做個寂寞卻快樂的說書人。