阿里云數據庫RDS MySQL的數據安全預防與恢復,rds數據庫阿里云阿里云數據庫RDS MySQL的數據安全預防與恢復前言數據庫往往是企業最為核心的數據保護對象,對數據庫系統安全的保護,對數據庫服務器和數據庫中的數據、應用、存儲的安全保護對企業來說至關重要,盡管我們用了很多技術手段,也很可能因為管理上的失誤導致嚴重后......
數據庫往往是企業最為核心的數據保護對象,對數據庫系統安全的保護,對數據庫服務器和數據庫中的數據、應用、存儲的安全保護對企業來說至關重要,盡管我們用了很多技術手段,也很可能因為管理上的失誤導致嚴重后果,我們需要用技術和管理組合手段,在數據庫進行使用之前,就需要對敏感權限進行管控,確定使用環境的安全,并做好全面的預防措施;在數據庫的使用過程中,更是需要謹慎操作,假設真的出了問題,還可以進行數據的恢復,以防止數據庫系統及其數據遭到泄露、篡改或破壞。
事前預防大于事后處理,對數據庫的管理來說,更是要防患于未然。您可以通過以下方式進行數據安全的事前預防: 權限隔離 環境隔離 內核回收站 設置實例備份規則 使用數據庫管理DMS 使用備份服務DBS
您可以通過設置高權限賬號和普通賬號進行數據權限隔離。包括讀寫權限,DML權限,DDL權限,創建表,修改表,等,除了只讀權限之外都需要進行管理和關注。權限說明見下圖:
可在數據庫管理界面配置不同的權限。
更多信息請參見創建數據庫賬號和授權服務賬號幫助文檔:https://help.aliyun.com/documentdetail/87038.html
對環境的隔離也是同樣重要,測試環境、開發環境、生產環境要分開,不要共用一套數據庫。
第三個預防的重點是內核上面的回收站,當執行drop時,與表無關的對象會做保留,防止誤刪。
MySQL 8.0的回收機制執行DROP TABLE/DATABASE語句時,只保留相關的表對象,并移動到專門的recycle bin目錄中。其它對象的刪除策略如下:
如果是與表無關的對象,根據操作語句決定是否保留,不做回收。
如果是表的附屬對象,可能會修改表數據的,做刪除處理,例如Trigger和Foreign key。但Column statistics不做清理,隨表進入回收站。
MySQL 8.0的清理機制回收站會啟動一個后臺線程,來異步清理超過recyclebinretention時間的表對象。在清理回收站表的時候,如果遇到大表,會再啟動一個后臺線程異步刪除大表。
還可以對數據進行備份來預防潛在的風險。實例備份規則為默認按照整實例進行備份和可以按照表進行備份。如下圖所示:
具體操作,參見幫助文檔:https://help.aliyun.com/documentdetail/130152.html
在事前預防中,阿里云提供強大的數據庫管理DMS服務和備份恢復DBS服務。DMS是一款強大的數據庫管理和設計工具,直觀的GUI開發環境讓用戶簡單管理多達25種數據庫,包括表結構設計、數據操作、數據開發及性能診斷優化等操作。DMS通過研發規范、研發流程、權限控制(可控制到列級別、行級別)、操作攔截、數據脫敏、流程審批、安全審計及變更回滾等功能有效保障數據安全。
DMS是一種新的工作模式: 多種角色參與整個研發流程,包括管理員、DBA、安全管理員及開發、測試、產品、運營、財務等。 可消除集中管控的人員瓶頸、減少溝通成本、規范化管理減少故障誤操作、變更周期可控、業務迭代速度快、提升研發效率。
對接企業賬號系統,數據安全解決方案從“審計”到“攔截”。
可控的SQL操作包含:全局權限管控、風險識別、數據脫敏、操作審計、安全規則引擎。
可進行靈活的安全規則設置:
變更穩定覆蓋數據變更、結構變更、代碼發布的全流程把控。尤其是對于大批量的數據變更,大表結構變更等,會有針對性的流程把控和精細化的管理,在不影響業務的情況下,提升整體的安全性。
備份服務DBS為數據庫提供連續數據保護、低成本的備份服務。它可以為多種環境的數據提供強有力的保護,包括企業數據中心、其他云廠商、混合云及公共云。RDS備份的數據是可見的,如果有數據分析的需求還可以用云原生數據湖進行支持,整個產品生態是打通和健全的。
產品功能: 可恢復任1秒數據實例、單庫、多表、單表,備份及恢復粒度自由選擇,RTO大幅降低,備份有效性實時驗證。 安全加密無論傳輸,還是存儲使用最嚴苛的加密技術,保護用戶數據安全。 低成本,免運維低成本異地備份,讓企業快速滿足三級等保要求,無需為災備提供前期成本,配置到運行只需幾分鐘。 多環境支持支持自建IDC、云上自建數據庫、其他云環境的數據庫備份。
備份服務DBS與RDS自帶備份的區別: 針對RDS數據庫,DBS提供轉儲備份和邏輯備份,滿足RDS客戶的異地備份和靈活備份訴求。 針對RDS數據庫,RDS提供物理備份,滿足RDS客戶的本地備份和快速恢復訴求。
DBS控制臺入口:
詳細內容請參見幫助文檔:https://www.aliyun.com/product/dbs和用戶指南:https://help.aliyun.com/documentdetail/69077.html
即使非常謹慎,數據庫在現場運行時是不可能不對數據進行查詢、修改和刪除的,我們不能因噎廢食,仍然要進行這些看似有風險的操作,但是我們可以采取以下措施,讓整個數據庫的使用過程更加安全。 使用內核回收站 操作隔離 操作備份
如果要使用DROP語句,可以在操作之前可以先打開回收站,回收站是可以進行清理和查詢的。回收站會有id與原表相對應,并會對過程進行記錄。以下示例是操作以MySQL 8.0為例進行說明:SET SESSION RECYCLEBIN=ON;打開會話級回收站CALL DBMSRECYCLE.SHOWTABLES();看回收站里的表DROP TABLE tablename;刪除表CALL DBMSRECYCLE.PURGETABLE (‘TABLE’);清理回收站里的表表示例:mysql call dbmsrecycle.showtables();+++++++ SCHEMA TABLE ORIGINSCHEMA ORIGINTABLE RECYCLEDTIME PURGETIME +++++++ recyclebin innodb1063 productdb t1 20190808 11:01:46 2019085 11:01:46 recyclebin innodb1064 productdb t2 20190808 11:01:46 2019085 11:01:46 recyclebin innodb1065 productdb parent 20190808 11:01:46 2019085 11:01:46 recyclebin innodb1066 productdb child 20190808 11:01:46 2019085 11:01:46 +++++++4 rows in set (0.00 sec)
更多信息請參見幫助文檔:https://help.aliyun.com/documentdetail/130152.html
如果我們要執行DML類的操作,在執行變更的時候最好走一下變更的流程。如果缺少這樣流程,大批量的操作語句最好有多人review。
注意:1、業務相關的操作:一定帶WHERE條件語句,把執行變更的范圍變到最小。2、運維/后臺相關操作 注意讀寫分離針對數據統計分析類/定時任務類/大批量操作類 盡量避免業務高峰 多人Review保證正確性
最好在每次操作執行之前,都把數據備份一遍,這樣即使真正出現問題,也可以執行回滾。
備份方法每次執行DML/DDL之前,導出執行前的SQL,作為回滾腳本。
運維/后臺相關操作 立即執行默認開啟為“是”,提交即刻執行;可按需指定在業務特定時間執行。 事務控制默認不開啟為“否”,逐條提交,遇到失敗則終止但不回滾;開啟該功能遇到失敗則全部回滾(僅限DML,DDL不在此范圍內)。 備份數據默認開啟為“是”,針對update、delete操作進行將要影響數據的全記錄行,insert腳本生成附件。
幫助文檔:https://help.aliyun.com/documentdetail/98818.html
即使我們非常謹慎,也不能百分百避免問題的發生,如果真的發生問題了,我們可以通過以下操作來進行事后恢復。 DMS工單操作歷史。 DMS數據追蹤。 內核回收站。 RDS克隆實例。 RDS庫/表恢復。 DBS恢復。
如果您使用了阿里云數據管理DMS平臺,可以使用DMS查看工單操作歷史。
使用場景
MySQL 5.5/5.6/5.7/8.0 DELETE/UPDATE/INSERT 需要管控的數據庫實例開通了DMS安全協同管控模式
恢復方法
對于變更執行后出現異常不符合訴求需要回滾的,可以直接在工單頁面內,選擇右側工單操作歷史查看備份,找到備份文件。 下載備份腳本下載,做相應處理。 確認數據滿足需求后,重新提交變更工單。更多內容請參見幫助文檔:https://help.aliyun.com/documentdetail/63780.html
如果您不是通過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)。
操作示例如下圖所示:
示例—少量數據追蹤
操作示例如下圖所示:
更多內容請參見幫助文檔:https://help.aliyun.com/documentdetail/126449.html
內核支持從回收站進行恢復,我們只需要確認回收站中有我們想要的表。
使用場景
MySQL 8.0 DROP TABLE/SCHEMA 其它對象的刪除策略是:
與表無關的對象,比如 procedure,根據操作語句決定是否保留,不做回收。
表的附屬對象,比如 trigger,Foreign key,column statistics等,只要存在可能修改表數據的,做刪除,比如 trigger,Foreign key。但columns statistics不做清理,隨表進入回收站。
找回方法
查看回收站表
CALL DBMSRECYCLE.SHOWTABLES();看回收站里的表。
找回
CREATE TABLE SRCSCHEMA.SRCTABLE LIKE SCHEMA.TABLE; 加粗部分是要替換的內容。INSERT INTO SRCSCHEMA.SRCTABLE SELECT * FROM SCHEMA.TABLE; 加粗部分是要替換的內容。
示例—從回收站恢復T1的數據
mysql call dbmsrecycle.showtables();+++++++ SCHEMA TABLE ORIGINSCHEMA ORIGINTABLE RECYCLEDTIME PURGETIME +++++++ recyclebin innodb1063 productdb t1 20190808 11:01:46 2019085 11:01:46 recyclebin innodb1064 productdb t2 20190808 11:01:46 2019085 11:01:46 recyclebin innodb1065 productdb parent 20190808 11:01:46 2019085 11:01:46 recyclebin innodb1066 productdb child 20190808 11:01:46 2019085 11:01:46 +++++++4 rows in set (0.00 sec)mysqlcreate table productdb.t1 like recyclebin. innodb1063;mysqlinsert into productdb.t1 select * from recyclebin. innodb1063;
如果您還沒有使用DMS,也可以用控制臺上實例的備份來恢復,克隆示例支持按照時間點或備份集恢復,最安全的方式建議恢復到一個新實例,不在原實例原地恢復。
使用場景
通過備份克隆出整個實例。
所有誤操作(DDL/DML)。
還原方式
指定時間點。
指定備份集。
操作步驟
恢復到一個新實例。
驗證數據準確性。
將數據遷回原實例。
操作示例如下圖所示:
更多內容請參見幫助文檔:https://help.aliyun.com/documentdetail/96147.html
如果您之前設置了庫/表級別備份的話,您的誤操作如果只是一個庫或者表,那么您可以進行庫/表級別恢復,但是庫/表級別恢復有很多限制。
使用場景
通過備份指定恢復誤刪的數據庫或表。
所有誤操作(DDL/DML)。
操作示例如下圖所示:
限制事項
必須打開庫/表級別備份。
每次最多選擇50個庫/表。
運行中且沒有被鎖定。
如果要按時間點進行恢復,需要確保日志備份已開啟。
若要按備份集恢復,則原實例必須至少有一個備份集。
更多內容請參見幫助文檔:https://help.aliyun.com/documentdetail/103175.html
如果您之前選擇了DBS備份,您就可以通過DBS進行事后恢復。
使用場景
支持整個實例、多個數據庫、單個數據庫、多張表或一張表恢復。
支持秒級任意時間點恢復,并且用戶可以靈活選擇恢復對象。
操作示例如下圖所示:
可以進行選擇恢復操作的時間點等操作配置,操作示例如下圖所示:
特別聲明:以上文章內容僅代表作者本人觀點,不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。
二維碼加載中...
使用微信掃一掃登錄
使用賬號密碼登錄
平臺顧問
微信掃一掃
馬上聯系在線顧問
小程序
ESG跨境小程序
手機入駐更便捷
返回頂部