場景一：核心資產數據庫表的異常訪問、告警
示例：某電商網站后臺分為多個微服務，分別為訂單管理服務、用戶管理服務、商品搜索服務等，各服務部署在不同的服務節點上，有不同IP地址，如圖所示。
服務器部署拓撲圖
綠色箭頭為正常訪問路徑，如果訂單管理服務或商品搜索服務兩個節點被攻陷，攻擊者會從這兩個節點去訪問數據庫的用戶信息表，意圖竊取用戶信息，就屬于數據庫的異常訪問。
在DBSS中可通過如下規則設置來檢測數據庫異常訪問情況：
添加數據庫異常訪問
如圖所示填寫的規則表示從192.168.1.1或192.168.3.3上發起的所有針對user_info表的操作都是“高風險”。
設置該規則后，所有異常訪問或竊取表user_info的行為都會被審計，并且觸發風險告警。
添加“操作對象”時，單擊“添加操作對象”，填寫“目標數據庫”和“目標表”，單擊“確認”，完成添加。
場景二：利用DBSS進行應用程序的SQL語句性能優化
示例：某應用上線之后發現當用戶執行某些操作時總會出現界面長時間卡頓。經定位，發現后臺應用訪問數據庫時出現好幾秒的時延，但未定位到具體是哪些語句導致。
此時可利用DBSS的“數據庫慢SQL檢測”規則進行輔助定位，幫助開發人員進行性能優化。
操作步驟如下：
- 登入DBSS控制臺，進入風險操作頁面。進入風險操作頁面
- 單擊“數據庫慢SQL檢測”項“操作”列的“編輯”，在編輯頁面的底部設置執行時長規則設置為大于1000毫秒。設置執行時長
- 單擊“確認”，完成設置。
- 設置完成后，待運行一段時間，在語句頁面下的規則名稱搜索框中填入“數據庫慢SQL檢測”對檢測情況進行檢索。
說明
您可對檢索的結果進行分析，對可進行優化的SQL進行優化。
若需要進行多輪優化，您可對規則中的“執行時長”字段進行修改，逐步縮小時間，直到達成性能提升的目標。
場景三：解決SQL注入風險的告警誤報
DBSS提供SQL注入檢測功能，并內置了一些SQL注入檢測規則。您也可以自行添加SQL注入檢測規則。
示例：若某些語句命中了SQL注入規則，但是經分析發現該語句并不是一條攻擊語句，是自己程序生成的合法語句，如圖所示。
SQL注入誤報
為了避免DBSS對誤報SQL的持續告警，您可以通過設置白名單來解決該誤報問題。
風險規則的優先級高于SQL注入規則。
如圖所示，執行的SQL語句如下：
SELECT COUNT( *) FROM
information_schema.TABLES WHERE TABLE_SCHEMA = 'adventureworks' UNION SELECT
COUNT(* ) FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'adventureworks'
UNION SELECT COUNT(*) FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA =
'adventureworks'
分析語句關鍵信息：該語句用SELECT語句訪問information_schema庫的TABLES表。
配置操作如下：
- 進入風險操作頁面進行險操作
- 單擊添加風險操作，填寫規則信息。
填寫規則信息
如圖所示，填寫的規則表示：在information_schema庫的TABLES表執行的SELECT語句為無風險。
添加“操作對象”時，單擊“添加操作對象”，填寫“目標數據庫”和“目標表”，單擊“確認”，完成添加。
添加SQL注入白名單操作對象
- 單擊下方“確認”，添加規則成功。設置完成后，再次檢測到該語句時，優先命中該條規則，識別為無風險將不再告警。
