434
防範攻擊 加強管控 - 數據庫安全的16條軍規
近日的數據安全事故，引發了很多企業的普遍關注，而不少用戶從徹查中確實發現自己的數據庫已經被注入，這為大家上了數據安全的重要一課。
甚至有的企業要求停用PL/SQL Developer這一工具，雖然這從製度上關上了一個門，但是我們知道數據庫類似的門如此之多，如何能夠從根本上提升數據庫管理的安全，減少數據運維風險呢？
我曾經在《數據安全警示錄》一書中總結了種種數據安全風險，提出了很多預防措施和手段，在此整理其中的一些建議供大家參考，當然大家也可以從雲和恩墨的安全服務中獲得幫助。
我在書中提出了數據安全的五個緯度，可以基於這五個緯度來梳理企業的數據安全，並據此建立相應的安全防護措施。
在數據安全的範疇內，我們將安全劃分為五大方麵，分別是：
軟件安全、備份安全、訪問安全、防護安全、管理安全
在企業數據安全中，這五大方麵是相輔相成、互有交叉、共同存在的，下圖是關於安全的一張思維導圖：
在這五大安全方向中，可能出現兩種性質的安全問題，第一，由於內部管理不善而導致的數據安全問題；第二，由於外部惡意攻擊入侵所帶來的安全安問題。通常我們把安全問題狹義化為後者，這實際上是片麵的，在數據安全問題上，前者造成的數據損失、數據損毀，其發生率和影響度都遠遠超過後者。
下麵我們對數據安全的五大方麵做一下簡要的分析和探討：
１.軟件安全是指我們選擇的數據庫產品、版本是否穩定安全；廠商所能提供的補丁集和BUG修正是否及時、基礎硬件與操作係統是否經過認證。很多用戶在部署數據庫軟件時，僅僅選擇了最容易獲得的初始發布版本，遺漏了可能已經存在的補丁修正，並且在運行維護中並不能夠及時跟蹤軟件更新，也無法獲得BUG信息、補丁修正和安全告警，這就使得軟件本身的很多風險隱患得不到修正。如果軟件安全無法保證，數據庫安全的基礎也就喪失了。
２.備份安全是指用戶數據能否得到及時有效的備份保全，能否在故障災難之後獲得及時的恢複和挽救。在數據庫運行期，最為重要的就是備份安全，如果沒有可靠的備份，將數據集中起來就隻能是等待數據災難，所以我們將備份安全提升到核心地位，備份以及隨之衍生的容災安全等，都是企業整體數據架構應該考慮的因素。很多企業在數據災難之後因為缺乏有效備份而一蹶不振，根據Gartner 2007年的一份調查報告顯示,在經曆了數據完全丟失而導致係統停運的企業中，有2/5再也沒能恢複運營，餘下的企業也有1/3在兩年內宣告破產,由此可見，由於備份安全問題導致的企業傷害可能遠遠大於黑客攻擊。
３.訪問安全是指用戶數據庫的訪問來源和訪問方式是否安全可控。通常數據庫係統處於IT係統的核心，其安全架構涉及主機、係統、存儲、網絡等諸多方麵，如果沒有明確的訪問控製，缺乏足夠的訪問分析與管理，那麼數據庫的安全將是混亂和無法控製的。在應用軟件使用和訪問數據庫時，要正確設置權限，控製可靠的訪問來源，保證數據庫的訪問安全，唯有保證訪問安全才能夠確保數據不被越權使用、不被誤操作所損害，通常最基本的訪問安全要實現程序控製、網絡隔離、來源約束等。
４.安全防範是指通過主動的安全手段對數據庫通訊、傳輸等進行增強、監控、防護、屏蔽或阻斷，諸如數據加密、審計、數據防火牆等技術都在這一範疇之內。我們必須認識到，在IT技術高度發展的今天，風險是無處不在、層出不窮的，可能我們從未思考過的安全問題，每天都在不斷湧現，所以在數據庫環境中采取主動式防護，可以幫助我們監控分析和屏蔽很多未知風險，已經有很多成熟的產品和技術可以用於安全防範。
５.管理安全是指在企業數據的日常管理維護範疇內，能否充分保證數據安全以及服務的高可用連續提供。諸如DBA的維護、文件的管理、參數或數據結構的變更等等都可能引入數據風險，管理安全要求我們通過規範、製度以及技術手段去確保維護管理安全；另外，基於硬件、電力等基礎平台的故障都可能影響數據庫服務的高可用性，在管理中要通過監控手段及時預警，通過集群、備庫等切換與服務分擔保障服務的連續性。
針對最近爆發的安全事故，我抽取書中的觀點，總結提升數據庫安全的"16條軍規"供大家參考，很多朋友也向我們詢問，如何做才能夠徹底防範這類風險，我想你可以從以下16條建議中找到答案：
備份重於一切
我曾經在總結的DBA四大守則的第一條就指出，『備份重於一切』，有了有效的備份，即使遭遇災難，也可以從容應對，對於重要的生產環境，適當建立備庫進行數據保護，查詢分擔，也會減少生產庫的風險；
唯一會讓DBA們從夢中驚醒的就是:沒有備份! 所以對於數據庫運維來說，第一重要的是做好備份!有備方能無患!
嚴格管控權限
過度授權即是為數據庫埋下安全隱患，在進行用戶授權時一定要遵循最小權限授予原則，避免因為過度授權而帶來的安全風險。本次安全風險，如果用戶隻具備最低權限，如不具備DDL權限，那麼也不會遭到風險；
明確用戶職責
應當明確不同的數據庫用戶能夠用於的工作範圍，應當使用普通用戶身份的，就絕對不應該使用DBA的用戶身份，隻有職權相稱，才能夠避免錯誤，降低風險。 即便是擁有管理員職責的用戶，也應當遵循以不同身份執行不同任務的習慣，比如SYS和SYSTEM用戶的使用就應當進行區分和界定；
密碼策略強化
毫無疑問，數據庫用戶應當使用強化的密碼規則，確保弱口令帶來的安全風險，很多數據泄露問題來自弱口令攻擊和提權；
限製登錄工具
明確限製不同工具的使用場景，明確規定工具的準確來源，或者通過堡壘機等來限製數據庫訪問。對於工具也可以做出明確規則和限製，如限製僅能通過SQL Developer訪問生產，PL/SQL Developer工具僅能訪問測試環境，以減少安全風險甚至誤操作風險；
禁止遠程DDL
可以限製DDL操作僅能在數據庫服務器本地進行，禁止遠程連接執行DDL操作，這一手段在很多公司被嚴格執行，如果具備這一規則，此次的事故可以被直接屏蔽掉；
使用綁定變量
在開發過程中，嚴格使用綁定變量，綁定變量可以防範SQL注入攻擊，減少數據庫安全風險；這次安全事故，很多用戶開始猜測是SQL注入，走了很多分析上的彎路；
監控監聽日誌
監聽日誌記錄了數據庫訪問的來源、程序等信息，包括惡意掃描，密碼嚐試等，一定要重視監聽日誌的作用，並對其進行分析和監控，以清楚的匯製數據庫訪問圖譜；雲和恩墨一直幫助用戶通過監聽日誌分析來揭示風險，白求恩平台（ https://bethune.enmotech.com ）為用戶免費提供這一分析緯度的預警；
數據網絡隔離
數據庫的網絡環境應該一直隱藏在最後端，避免將數據庫置於直接的訪問連接之下，由此可以減少數據庫的訪問風險；
測試和生產隔離
互通就意味著同時可以訪問，也就可能帶來很多意想不到的安全風險，企業應當將測試環境和生產環境部署於不可互通，或者不可同時訪問的網絡環境中，避免因為錯誤連接而發生的數據庫災難。 分離部署一方麵可以降低誤操作的可能性，也可以屏蔽一些無關的訪問可能，從而從網絡鏈路上保證數據安全；
密碼差異設置
有些測試環境或者非產品環境是利用產品環境恢複得到的，DBA在建立了測試環境後，就沒有修改數據庫用戶的登錄密碼;經常性的，DBA也習慣在所有環境中設置通用的密碼;這些習慣為係統帶來了很多風險和不確定性。 我們建議用戶在不同環境中采用不同的密碼設置，這是因為一方麵產品環境和測試環境麵對的訪問用戶不同，密碼設置相同則意味著產品環境的安全性完全得不到保障;另一方麵，DBA登錄到不同的數據庫需要使用不同的密碼，這進一步減低了DBA在錯誤的環境下執行命令的可能性。
重要數據加密
很多重要的數據，需要加密存儲，最典型的就是用戶和密碼信息，大量的泄密事件本質上是因為缺乏最基本的加密防範，對重要數據實施一定的安全防護加密，是應當予以適時考慮的安全方麵之一；
適時的軟件升級
這裏的軟件指數據庫軟件，尤其是當Oracle已經發布了安全補丁，已知的安全漏洞被黑客利用，則更可能對數據庫產生致命的傷害；
防範內部風險
不可否認，絕大部分安全問題都來自於企業內部，來自最緊密、最輕易的接觸和訪問，企業的人員變動，崗位變更，都可能導致數據安全問題的出現，單存依靠對管理員的信任不足以保障數據安全，必須通過規章、製度與規 範的約束才能夠規避安全風險。
很多企業為了便利而舍棄規範、規章或者安全限製是得不償失的做法。安全防範應當從內部做起，從限製約束自我做起，當最緊密相關的訪問都遵從守則，那麼係統的安全性就能夠獲得大幅度的提升。
樹立安全意識
安全問題最大的敵人是僥幸，很多企業認為安全問題概率極低，不會落到自己的環境中，所以對於安全不做必要的投入，造成了安全疏忽。所以安全問題最大的敵人是我們自己，安全需要一點一滴的加強，逐步完善，雲和恩墨一直幫助核心客戶進行全麵的安全評估，製定安全方案，守護數據安全。
開始安全審計
以Oracle數據庫為例，數據庫已經提供了很多安全防範的手段和方法，我們建議用戶適當展開安全防範措施，開啟部分任務審計，定期分析數據庫風險，由此逐步完善數據庫安全。
關注安全，努力請從今日始。
文章轉自數據和雲公眾號，原文鏈接
最後更新：2017-07-17 17:33:07