“這是一場可預見的噩夢！”
近期，黑客通過攻擊亞洲最大兩家資料中心—萬國資料和新科電信媒體，獲取國際巨頭企業的登錄憑證，引發了2000多家企業史詩級資料泄露，中國作為全球第二大托管服務市場，尤其應當警惕威脅，即刻做出預控措施，應對風險！
資料安全問題的重要性不言而喻，特別是對于企業團隊來說，保護公司資料安全更是首要任務，虹科提供的Redis企業版資料庫正在不斷努力升級產品的安全性！在虹科提供的Redis企業版資料庫6.4.2中，對其現有的安全功能進行了強化：新增客戶端證書和發布/訂閱訪問管理兩大功能！使其在符合法規和行業要求的前提下，成為企業的最強助攻擔當，為企業提供更多的便利和服務，
那么問題來了：“虹科提供的Redis企業版資料庫這次為何著重突出這兩項功能的升級，它又憑什么能為企業實作資料安全疊加最強Buff？”別著急，虹科來為你一一解答！
一. 帶有subject驗證的雙向TLS身份驗證
1. 傳輸層安全性（TLS）
傳輸層安全性( TLS )是一種加密協議，TLS被互聯網工程任務組(Internet Engineering Task Force, IETF)描述為“互聯網的核心安全協議”，目的是為互聯網通信提供安全及資料完整性保障，具體表現為：
(1) TLS協議采用主從式架構模型，該模型被廣泛應用于保護計算機應用程式間的通信：在兩個應用程式間透過網路創建安全的連線，來防止資料在交換時受到竊聽和篡改，
(2) TLS使用一種叫做公鑰加密的技術運作，它依賴于一對密鑰（公鑰和私鑰），任何用公鑰加密的內容，都只能用私鑰來解密，如果服務器解密了用公鑰加密的資訊，就證明它擁有私鑰，公鑰可以讓任何人通過域或服務器的TLS證書來查看，
2. Mutual TLS (mTLS)
Mutual TLS (mTLS)，是一種用于雙向驗證身份的方法：
(1) mTLS是在會話開始，TSL進行握手時，服務器與客戶端互相提供交換證 書，通過證書頒發機構來彼此驗證身份，認證通過方可進行通信的程序，
(2) 使用mTLS的必要性：
首先，它為登錄到團隊網路或應用程式的用戶提供了一層額外的安全保護，其次，它還可以驗證與不遵循登錄程序的客戶端之間的鏈接，最重要的是，它可以防止：在途攻擊、欺騙攻擊、憑證填充、暴力攻擊、網路釣魚攻擊、惡意API請求等各型別攻擊，
另外，對于日常用途，單向身份驗證提供了足夠的保護，但在單個或較小的團隊規模上，mTLS還是非常實用的，尤其是為在保持API的安全上，mTLS通常被用于零信任安全框架，由于零信任方法默認不信任任何用戶、設備或請求，因此團隊必須能夠在每次嘗試訪問網路中的任何時間對每個用戶、設備和請求進行身份驗證，mTLS剛好能夠通過驗證用戶和驗證設備來實作這一點，
(3) 在虹科Redis企業版資料庫中，可以將其配置為使用mTLS，此時，如果客戶端試圖連接到資料庫，Redis企業版資料庫就會在TLS握手期間驗證客戶端的證書之后，再允許它連接到資料庫，
但如果多個客戶端都獲得了有效的客戶端證書，而您只想允許他們中的部分人訪問某個資料庫時，就是我們虹科Redis企業版資料庫6.4.2新功能（額外的證書驗證）上場的時刻啦！從6.4.2版開始，虹科Redis企業版資料庫是允許您對經過身份驗證的客戶端證書執行其他驗證的：
（1）使用公鑰證書的subject欄位，其中包含了有關證書所屬客戶端身份的附加資訊，基于此，在允許客戶端連接到資料庫之前，虹科Redis企業版資料庫會執行兩個步驟：
1) 該證書以加密方式進行身份驗證，
2）將證書的subject資訊與資料庫配置的允許subject串列進行比較，僅當找到匹配項時才允許連接，
例如，一個使用Redis企業版資料庫的國家大型金融機構，希望根據客戶端證書來控制客戶可以訪問的特定資料庫，他們的客戶都使用有效的客戶證書，但具有不同的subject值，一旦為資料庫開啟“附加證書驗證”選項，并正確配置允許的subject串列后，該機構現在就可以控制特定客戶端證書子集來訪問對應資料庫，
（2）在虹科Redis企業版資料庫中使用mTLS涉及幾個步驟：
1）為資料庫開啟TLS和mTLS選項；
2）加載資料庫的相關證書頒發機構(CA)根證書或中間證書；
3）添加允許的subject行串列；
4）選擇“按完整subject進行的其他證書驗證”選項，
編輯搜圖
請點擊輸入圖片描述（最多18字）
二．強化Redis ACL發布/訂閱的訪問管理功能
發布/訂閱（pub/sub）是一種允許間接通信的訊息傳遞方法，客戶端或應用程式可以向共享資源端發布訊息，其他客戶端或應用程式也可以訂閱該資源來接收這些訊息，
在虹科Redis企業版資料庫中，我們把這種資源稱為通道，它提供了一種快速、輕量和可擴展的解決方案，發布/訂閱頻道和廣播電臺的運作模式相似，企業需要連接之后才能接收訊息，發布/訂閱頻道的同步性使得實時通知、在微服務之間發送訊息、在應用程式的不同部分之間進行通信成為可能，
值得注意的是，這些資源顯然是需要得到軟體保護的：
（1）訪問控制串列（ACL）一個規則串列，其中的每條規則都對資源或操作的訪問權限授予或拒絕，ACL是團隊限制未授權用戶訪問敏感業務資訊，或執行未授權操作的強大工具，
為滿足用戶的需求，Redis企業版資料庫正在不斷增強其ACL功能和覆寫范圍，隨著Redis企業版資料庫6.4.2的發布，ACL現在可以允許和禁止訪問發布/訂閱頻道，
（2）送到頻道的無效訊息會破壞應用程式，它可能會導致資料損壞、資料丟失甚至中斷，通過限制所有訪問權限，并僅允許相關用戶訪問特定頻道，這樣可以減少無論是出于惡意還是無意，被限制訪問或發送訊息這兩種情況被執行的機會，
（3）資源保護的方法主要有兩種：
1) 是隱式訪問：客戶可以訪問所有內容，并設定權限以限制訪問，就好像：任何人都可以進入一家餐館，除非被餐館老板列入了黑名單禁止入內，
2）顯式授予：除非客戶被顯式授予權限，否則無權訪問，就比如：如果沒有通過安檢和機場作業人員驗證機票，一般無法登上飛機，當然，這種資產保護的方法更安全，
(4）虹科提供的Redis企業版資料庫所采用的方法：除了允許使用ACL的渠道，選擇限制所有發布/訂閱渠道，目前，在虹科提供的Redis企業版資料庫 6.4.2中，可以通過配置適用于所有資料庫通道的集群范圍默認選項，來達到這個目的，
為了避免更改過于極端及符合以前的版本，虹科提供的Redis企業版資料庫6.4.2安裝提供的 acl-pubsub-default 值也是被所有頻道允許的，一旦集群中的所有資料庫都處于Redis版本6.4.2（或未來版本中的更高版本）中，我們建議將此值設定為“restrictive”（resetchannels），
另外，如果是正在使用ACL和發布/訂閱渠道，建議檢查資料庫和ACL設定并切換到受限模式，因為這將是未來虹科Redis企業版資料庫中 acl-pubsub-default 的新默認值，
三. 更多功能優勢：節省時間和資源
盡管虹科提供的Redis企業版資料庫6.4.2的突出重點是上述安全功能，但新添功能絕不止于此！
1.生成自簽名證書
虹科Redis企業版資料庫提供自簽名TLS證書，從而允許不使用受信任的CA簽名證書的客戶也可以安全使用，但注意，自簽名證書默認有效期為一年，所以建議客戶在其過期前及時更新這些證書，
另外，虹科Redis企業版資料庫現在還提供了一個用戶友好的腳本，客戶不需要事先了解這些，也能快速輕松地創建新的一次性自簽名證書，在此之后也只需通過幾個簡單的步驟就能將這些證書加載到Redis企業版資料庫中，
2.服務靈活選擇
眾所周知，Redis企業版資料庫提供的服務豐富多樣，但有時它們也不是全部被需要的，虹科Redis企業版資料庫提供了洗掉服務工具，借此可以節省記憶體資源，并為更有價值的服務騰出空間，
虹科Redis企業版資料庫還添加了禁用警報管理器的功能，用以發送電子郵件警報：rladmin cluster config alert_mgr [<enabled | disabled>
但如果擁有替代警報系統，則也許此服務會被禁用，建議謹慎使用此功能，
借助虹科提供的Redis企業版資料庫6.4.2，可以更快、更高效、更靈活的創建應用程式，最重要的是，對用戶的整個創建程序都是安全的，這也是Redis企業版資料庫6.4.2誕生的意義所在！
虹科Redis企業版軟體（Redis Enterprise）是企業級的資料庫軟體，也是一款實時資料平臺，為全球超過8500家知名企業提供實時資料服務，具有線性可擴展性、高可用性、持久性、備份和恢復、地理分布、分層記憶體訪問、多租戶、安全性等8大核心功能、擁有RediSearch、RedisJSON等7大【Redis企業版特有模塊】，可以任何規模在云、本地和混合部署中運行現代應用程式，提供無服務器、多模型的資料庫解決方案，Redis企業版的核心優勢是采用Redis on flash分層存盤技術即【記憶體+閃存+磁盤】的存盤方式，其Active-Active地理分布式架構允許跨地理位置同時進行資料讀寫操作、擁有亞毫秒延遲和極高吞吐量，
提問：
1.“你的企業在資料安全保護方面最大的難題是什么？
2.“你對本次黑客攻擊，兩大亞洲資料中心大規模泄露有什么理解和想法呢？”
虹科是Redis企業版資料庫的中國區戰略合作伙伴，虹科持續關注各行業當下急切需求，專注于為企業解答疑問，制定專屬服務，提供一站式解決方案，虹科提供的Redis企業版資料庫是無數企業資料安全保護路上的最佳合作選擇！為企業的資料安全保駕護航！
點贊收藏轉發~關注我們！關于企業如何更好地實作資料安全保護有任何其他疑問，歡迎在評論區進行交流或者聯系我們！
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/547042.html
標籤：其它
上一篇：資料庫轉換日記---從MSSQL Server導資料到MySQL
下一篇：分布式資料庫架構路線大揭秘