開發與維運

阿里雲數據庫RDS MySQL的數據安全預防與恢復

2020-11-10

事前預防

事前預防大於事後處理，對數據庫的管理來說，更是要防患於未然。您可以通過以下方式進行數據安全的事前預防：

  • 權限隔離
  • 環境隔離
  • 內核回收站
  • 設置實例備份規則
  • 使用數據庫管理DMS
  • 使用備份服務DBS

權限隔離

您可以通過設置高權限賬號和普通賬號進行數據權限隔離。包括讀寫權限，DML權限，DDL權限，創建表，修改表，等，除了只讀權限之外都需要進行管理和關注。
權限說明見下圖：
image.png

可在數據庫管理界面配置不同的權限。
image.png

更多信息請參見創建數據庫賬號和授權服務賬號幫助文檔。

環境隔離

對環境的隔離也是同樣重要，測試環境、開發環境、生產環境要分開，不要共用一套數據庫。
image.png

內核回收站

第三個預防的重點是內核上面的回收站，當執行drop時，與表無關的對象會做保留，防止誤刪。
MySQL 8.0的回收機制
執行DROP TABLE/DATABASE語句時，只保留相關的表對象，並移動到專門的recycle bin目錄中。其它對象的刪除策略如下：

  • 如果是與表無關的對象，根據操作語句決定是否保留，不做回收。
  • 如果是表的附屬對象，可能會修改表數據的，做刪除處理，例如Trigger和Foreign key。 但Column statistics不做清理，隨表進入回收站。

MySQL 8.0的清理機制
回收站會啟動一個後臺線程，來異步清理超過recycle_bin_retention時間的表對象。在清理回收站表的時候，如果遇到大表，會再啟動一個後臺線程異步刪除大表。
具體請參考幫助文檔。

設置實例備份規則

還可以對數據進行備份來預防潛在的風險。實例備份規則為默認按照整實例進行備份和可以按照表進行備份。如下圖所示：
image.png
具體操作，參見幫助文檔。

使用數據庫管理DMS進行安全預防

在事前預防中，阿里雲提供強大的數據庫管理DMS服務和備份恢復DBS服務。DMS是一款強大的數據庫管理和設計工具，直觀的GUI開發環境讓用戶簡單管理多達25種數據庫，包括表結構設計、數據操作、數據開發及性能診斷優化等操作。DMS通過研發規範、研發流程、權限控制（可控制到列級別、行級別）、操作攔截、數據脫敏、流程審批、安全審計及變更回滾等功能有效保障數據安全。
image.png

DMS是一種新的工作模式：

  • 多種角色參與整個研發流程，包括管理員、DBA、安全管理員及開發、測試、產品、運營、財務等。
  • 可消除集中管控的人員瓶頸、減少溝通成本、規範化管理減少故障誤操作、變更周 期可控、業務迭代速度快、提升研發效率。
    image.png

對接企業賬號系統，數據安全解決方案-從“審計”到“攔截”。
image.png
image.png
可控的SQL操作包含：全局權限管控、風險識別、數據脫敏、操作審計、安全規則引擎。
image.png
可進行靈活的安全規則設置：
image.png
變更穩定-覆蓋數據變更、結構變更、代碼發佈的全流程把控。尤其是對於大批量的數據變更，大表結構變更等，會有針對性的流程把控和精細化的管理，在不影響業務的情況下，提升整體的安全性。
image.png

使用阿里雲備份服務DBS

備份服務DBS為數據庫提供連續數據保護、低成本的備份服務。它可以為多種環境的數據提供強有力的保護，包括企業數據中心、其他雲廠商、混合雲及公共雲。RDS備份的數據是可見的，如果有數據分析的需求還可以用雲原生數據湖進行支持，整個產品生態是打通和健全的。
產品功能：

  • 可恢復任1秒數據
    實例、單庫、多表、單表，備份及恢復粒度自由選擇，RTO大幅降低，備份有效性實時驗證。
  • 安全加密
    無論傳輸，還是存儲使用最嚴苛的加密技術，保護用戶數據安全。
  • 低成本，免運維
    低成本異地備份，讓企業快速滿足三級等保要求，無需為災備提供前期成本，配置到運行只需幾分鐘。
  • 多環境支持
    支持自建IDC、雲上自建數據庫、其他雲環境的數據庫備份。

備份服務DBS與RDS自帶備份的區別：

    • 針對RDS數據庫，DBS提供轉儲備份和邏輯備份，滿足RDS客戶的異地備份和靈活備份訴求。
    • 針對RDS數據庫，RDS提供物理備份，滿足RDS客戶的本地備份和快速恢復訴求。

image.png

DBS控制檯入口：
image.png
詳細內容請參見幫助文檔。

事中謹慎

即使非常謹慎，數據庫在現場運行時是不可能不對數據進行查詢、修改和刪除的，我們不能因噎廢食，仍然要進行這些看似有風險的操作，但是我們可以採取以下措施，讓整個數據庫的使用過程更加安全。

  • 使用內核回收站
  • 操作隔離
  • 操作備份

使用內核回收站

如果要使用DROP語句，可以在操作之前可以先打開回收站，回收站是可以進行清理和查詢的。回收站會有id與原表相對應，並會對過程進行記錄。
以下示例是操作以MySQL 8.0為例進行說明：

SET SESSION RECYCLE_BIN=ON;--------------------打開會話級回收站
CALL DBMS_RECYCLE.SHOW_TABLES();--------------看回收站裡的表
DROP TABLE tablename;--------------------------------------------------刪除表
CALL DBMS_RECYCLE.PURGE_TABLE (‘<TABLE>’);-----清理回收站裡的表

表示例：

mysql> call dbms_recycle.show_tables(); 
+-----------------+---------------+---------------+--------------+---------------------+---------------------+ 
| SCHEMA | TABLE | ORIGIN_SCHEMA | ORIGIN_TABLE | RECYCLED_TIME | PURGE_TIME | 
+-----------------+---------------+---------------+--------------+---------------------+---------------------+ 
| __recycle_bin__ | __innodb_1063 | product_db | t1 | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 | 
| __recycle_bin__ | __innodb_1064 | product_db | t2 | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 | 
| __recycle_bin__ | __innodb_1065 | product_db | parent | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 | 
| __recycle_bin__ | __innodb_1066 | product_db | child | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 | 
+-----------------+---------------+---------------+--------------+---------------------+---------------------+ 
4 rows in set (0.00 sec)

更多信息請參見幫助文檔。

操作隔離

如果我們要執行DML類的操作，在執行變更的時候最好走一下變更的流程。如果缺少這樣流程，大批量的操作語句最好有多人review。
image.png
注意：
1、業務相關的操作：
一定帶WHERE條件語句，把執行變更的範圍變到最小。
2、運維/後臺相關操作

  • 注意讀寫分離
  • 針對數據統計分析類/定時任務類/大批量操作類
  • 儘量避免業務高峰
  • 多人Review保證正確性

操作備份

最好在每次操作執行之前，都把數據備份一遍，這樣即使真正出現問題，也可以執行回滾。
備份方法
每次執行DML/DDL之前，導出執行前的SQL，作為回滾腳本。
運維/後臺相關操作

  • 立即執行
    默認開啟為“是”，提交即刻執行；可按需指定在業務特定時間執行。
  • 事務控制
    默認不開啟為“否”，逐條提交，遇到失敗則終止但不回滾；開啟該功能遇到失敗則全部回滾（僅限DML，DDL不在此範圍內）。
  • 備份數據
    默認開啟為“是”，針對update、delete操作進行將要影響數據的全記錄行，insert腳本生成附件。

幫助文檔

事後恢復

及時我們非常謹慎，也不能百分百避免問題的發生，如果真的發生問題了，我們可以通過以下操作來進行事後恢復。

  • DMS工單操作歷史。
  • DMS數據追蹤。
  • 內核回收站。
  • RDS克隆實例。
  • RDS庫/表恢復。
  • DBS恢復。

DMS工單操作歷史

如果您使用了阿里雲數據管理DMS平臺，可以使用DMS查看工單操作歷史。

使用場景

MySQL 5.5/5.6/5.7/8.0
DELETE/UPDATE/INSERT
需要管控的數據庫實例開通了DMS安全協同管控模式

恢復方法

  • 對於變更執行後出現異常不符合訴求需要回滾的，可以直接在工單頁面內，選擇右側>工單操作歷史>查看備份，找到備份文件。
  • 下載備份腳本下載，做相應處理。
  • 確認數據滿足需求後，重新提交變更工單。

更多內容請參見幫助文檔。

DMS數據追蹤

如果您不是通過DMS進行的變更，也可以通過DMS進行數據的追蹤，逆向解析Binlog，本地Binlog和本地清理後到OSS上的Binlog都可以追蹤。（前提在binlog仍然存在，一般雲數據庫Binlog保留週期為7天，如需更長時間可在RDS控制檯按需調整）

使用場景

  • MySQL 5.5/5.6/5.7/8.0
  • DELETE/UPDATE/INSERT
  • 少量

功能

  • 在線搜索日誌內容，無需手工下載Binlog。
  • 支持數據的插入/更新/刪除日誌搜索，無需手工解析Binlog。
  • 支持逐條數據恢復，無需手工生成回滾語句。

支持的Binlog

  • OSS Binlog（RDS會定時將Binlog備份到OSS上）。
  • 本地熱Binlog（數據庫服務器上Binlog）。

操作示例如下圖所示：
image.png

更多內容請參見幫助文檔。
示例—少量數據追蹤
操作示例如下圖所示：
image.png

更多內容請參見幫助文檔。

從回收站恢復

內核支持從回收站進行恢復，我們只需要確認回收站中有我們想要的表。

使用場景

  • MySQL 8.0
  • DROP TABLE/SCHEMA
  • 其它對象的刪除策略是：
  1. 與表無關的對象，比如 procedure，根據操作語句決定是否保留，不做回收。
  2. 表的附屬對象，比如 trigger，Foreign key，column statistics等，只要存在可能修改表數據的，做刪除，比如 trigger，Foreign key。 但columns statistics不做清理，隨表進入回收站。

找回方法

  • 查看回收站表
CALL DBMS_RECYCLE.SHOW_TABLES();--------------看回收站裡的表。
  • 找回方法
CREATE TABLE SRC_SCHEMA.SRC_TABLE LIKE SCHEMA.TABLE;-------------------- 加粗部分是要替換的內容。
INSERT INTO SRC_SCHEMA.SRC_TABLE SELECT * FROM SCHEMA.TABLE; ----- 加粗部分是要替換的內容。

示例—從回收站恢復T1的數據

mysql> call dbms_recycle.show_tables(); 
+-----------------+---------------+---------------+--------------+---------------------+---------------------+ 
| SCHEMA | TABLE | ORIGIN_SCHEMA | ORIGIN_TABLE | RECYCLED_TIME | PURGE_TIME | 
+-----------------+---------------+---------------+--------------+---------------------+---------------------+ 
| __recycle_bin__ | __innodb_1063 | product_db | t1 | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 | 
| __recycle_bin__ | __innodb_1064 | product_db | t2 | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 | 
| __recycle_bin__ | __innodb_1065 | product_db | parent | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 | 
| __recycle_bin__ | __innodb_1066 | product_db | child | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 | 
+-----------------+---------------+---------------+--------------+---------------------+---------------------+ 
4 rows in set (0.00 sec)
mysql>create table product_db.t1 like __recycle_bin__. __innodb_1063;
mysql>insert into product_db.t1 select * from __recycle_bin__. __innodb_1063;

克隆實例

如果您還沒有使用DMS，也可以用控制檯上實例的備份來恢復，克隆示例支持按照時間點或備份集恢復，最安全的方式建議恢復到一個新實例，不在原實例原地恢復。

使用場景

  • 通過備份克隆出整個實例。
  • 所有誤操作(DDL/DML)。

還原方式

  • 指定時間點。
  • 指定備份集。

操作步驟

  1. 恢復到一個新實例。
  2. 驗證數據準確性。
  3. 將數據遷回原實例。

操作示例如下圖所示：
image.png

更多內容請參見幫助文檔。

庫/表級別恢復

如果您之前設置了庫/表級別備份的話，您的誤操作如果只是一個庫或者表，那麼您可以進行庫/表級別恢復，但是庫/表級別恢復有很多限制。

使用場景

  • 通過備份指定恢復誤刪的數據庫或表。
  • 所有誤操作(DDL/DML)。
    操作示例如下圖所示：

image.png

限制事項

  • 必須打開庫/表級別備份。
  • 每次最多選擇50個庫/表。
  • 運行中且沒有被鎖定。
  • 如果要按時間點進行恢復，需要確保日誌備份已開啟。
  • 若要按備份集恢復，則原實例必須至少有一個備份集。
    image.png

更多內容請參見幫助文檔。

從DBS恢復

如果您之前選擇了DBS備份，您就可以通過DBS進行事後恢復。

使用場景

  • 支持整個實例、多個數據庫、單個數據庫、多張表或一張表恢復。
  • 支持秒級任意時間點恢復，並且用戶可以靈活選擇恢復對象。

操作示例如下圖所示：
image.png
image.png

可以進行選擇恢復操作的時間點等操作配置，操作示例如下圖所示：
image.png

Leave a Reply

Your email address will not be published. Required fields are marked *