等保測評2.0：SQLServer身份鑒別
- 2020 年 2 月 20 日
- 筆記
一、前言
本篇文章主要說一說SQLServer資料庫中身份鑒別控制點的中c、d測評項相關內容和理解。
二、測評項
c)當進行遠程管理時，應採取必要措施防止鑒別資訊在網路傳輸過程中被竊聽； d)應採用口令、密碼技術、生物技術等兩種或兩種以上組合的鑒別技術對用戶進行身份鑒別，且其中一種鑒別技術至少應使用密碼技術來實現。
三、測評項c
c)當進行遠程管理時，應採取必要措施防止鑒別資訊在網路傳輸過程中被竊聽；
3.1. 默認加密
以前我一直以為SQLServer的鑒別資訊（資料庫連接字元串）如果不經過特殊處理在網路傳輸過程中是明文傳輸的。
後來上網查了下，網上提到說：聯機從書上提到過從SQL Server 2005開始，SQL Server和客戶端的連接是自動加密的
我去翻了下SQLServer 2008 R2的聯機叢書，上面確實提到，SQL Server 始終對與登錄關聯的網路數據包加密：
那麼以網上的那篇文章內容來說的話，SQLServer 2005開始，SQLServer默認會對與登錄關聯的網路數據包加密，具體網址如下：SQL Server 連接加密 (1) — SQL Server connection encyption
但是，要注意：SQLServer自動生成的證書是一種自簽名的證書，而通過自簽名證書實現的SSL並不能提供很強的安全性。
同時，雖然默認會對與登錄關聯的網路數據包加密，但是對與登錄無關的網路數據包是默認不加密的：SQL Server 連接加密 (2) — SQL Server connection encyption。
不過該測評項也僅僅只是要求防止鑒別資訊在網路傳輸過程中被竊聽，所以與登錄無關的網路數據包是否加密，不在這裡考慮。
3.2. 強制加密
那麼，原初級教程里提到的強制加密是用來幹什麼的呢？
這個強制加密在SQL Server Configuration Manager中有兩個地方，一個是SHTECSQLEXPRESS的協議的屬性中進行設置：
一個在SQL Native Client配置的屬性中進行設置：
這兩個有什麼不同呢？
SHTECSQLEXPRESS的協議屬性中的強制加密，默認為否：
當把該選項設置為是之後，SQL Server就會要求對所有它和客戶端之間的數據包傳送進行加密，無論客戶端是否配置為要求加密。此時用來加密的密鑰仍舊是之前在建立連接階段使用的證書。
如果SHTECSQLEXPRESS的協議屬性中的強制加密未設置為是：
那麼是否對某客戶端的所有傳輸過來的數據進行加密就完全取決於客戶端的配置，也就是客戶端的資料庫連接驅動的配置。在Configuration Manager中，可以設置SQL Native Client配置。當SQL Native Client配置屬性中的強制加密為是的話，就表明客戶端要求加密數據包。此時客戶一定要信任SQL Server端的證書（也就是信任伺服器證書為是），否則連接無法建立。另外，需要注意的是，此處的配置只對使用Native Client的客戶端程式有效果。其他驅動程式也會有相應的方法分別作配置。如ODBC驅動就可以通過Cliconfg控制台來配置，等等
具體的原文在這：SQL Server 連接加密 (2) — SQL Server connection encyption。
SQLServer 2008 R2的聯機叢書中也有說到這部分的內容：
所以強制加密的第一個作用是可以使用自己配置的證書，第二個作用就對多所有的網路傳輸數據進行加密。
對於這個測評項而言，第二個作用沒有意義，而手動配置證書有意義，因為它可以提高安全性：
使用自簽名證書加密的 SSL 連接不提供強安全性。它們容易在傳輸中途受到攻擊。在生產環境中或在連接到 Internet 的伺服器上，不應依賴使用自簽名證書的 SSL。
3.3. 手動配置證書
如果要判定為符合，應該不使用自簽名證書（也即SQLServer自動生成的證書）。
手動 配置SQLServer的過程如下：
3.4. ipsec
使用IPSec也可以實現傳輸數據的加密：
3.5. 測評項c總結一
該測評項對於默認狀態下的SQLServer應該屬於部分符合，因為默認情況下SQLServer對於網路傳輸過程中的鑒別資訊是加密的，只不過安全性不高。
如果要判定為符合，應該使用手動配置的證書或者使用IPSec。
3.6. 測評項c總結二
對於這個測評項也要從該資料庫的使用模式來進行判斷（以下是個人理解）。
比如中間件和資料庫處於同一台伺服器A上，客戶端或者瀏覽器不會直連數據，而是發送請求到http介面到A，A再連接處於本地的資料庫獲取數據，未發生過資料庫鑒別資訊的網路傳輸，那麼這個測評項應判定為不適用或者符合。
又或者中間件所在伺服器A和資料庫所在伺服器B處於同一內網中，伺服器A接收到請求後，發送資料庫的鑒別資訊到伺服器B，外網的設備比較難獲取到鑒別資訊（更別說鑒別資訊也不是明文傳輸的），應該判定為部分符合或者符合。
又或者，雖然資料庫本身沒有進行什麼配置，但是客戶端是直連資料庫的（某一些C/S架構的軟體確實會這樣），但是客戶端使用了SSL等協議進行了網路傳輸數據的加密，那麼也應該是部分符合或者符合。
好吧，由於等級保護2.0去掉了0-5分的分數制，所以雖然有很多種情況，但是判定結果只有符合、部分符合、不符合、不適用，所以區分得這麼細在判定結果處差別不大。
但是，在結果記錄處還是有區別的，要根據實際情況進行記錄嘛。
哦，對了，最後說一句，要記得查看SQLServer的版本，默認加密是從2005版開始的。
四、測評項d
d)應採用口令、密碼技術、生物技術等兩種或兩種以上組合的鑒別技術對用戶進行身份鑒別，且其中一種鑒別技術至少應使用密碼技術來實現。
好吧，直接實現SQLServer資料庫雙因素認證的方法我沒找到，頂多也就是可以使用證書對存儲過程進行訪問控制：使用證書為存儲過程簽名。
絕大部分的被測評單位在SQLServer資料庫的這一個測評項處，只能得0分，不過也不用過於在意。
該測評項屬於安全計算環境這個安全類，其測評對象包括了資料庫、伺服器和終端的作業系統、應用系統、安全設備、網路設備等等，按照等級保護2.0的標準，對於3級和以上的系統，只要其中一個設備在該測評項處得0分，那麼就可能屬於高風險項，測評結論瞬間就變成差了。
從現實的角度而言，這麼多設備統統都要實現雙因素認證，既無可能，也沒必要。
所以制定等級保護標準的專家們考慮到這一點，在網路安全等級保護測評高風險判定指引（2019定稿）中留下了很多的口子（個人理解）。
舉個例子，對於該測評項而言：
滿足條件中指明，屬於3級和3級以上系統，且被測評對象屬於重要核心設備等通過不可控網路環境遠程進行管理，然後同時未實現雙因素認證的，可判定為高風險項。
分析一下，3級和3級以上系統這個條件不用多說，3級以下系統不存在這個測評項。
被測評項對象屬於重要核心設備，這個也不用多說，被抽選出來的測評項對象，其重要性一般都不低（否則你選它幹嘛）。
通過不可控網路環境遠程進行管理，這個有些用，對於資料庫，不一定存在遠程連接的行為，這一點我上面的文章有說。就算存在遠程連接的行為，是否就處於不可控網路環境呢？也不一定的。
注意，不可控網路在判定指引中有明確定義：
到這裡，就算條件都滿足了，屬於高風險項，也存在很多的補償措施，對該高風險項目進行修正，這些補償措施都是現實可行的，絕不是無法實行的，這裡就不具體的分析了。
總而言之，雖然高風險項存在著一票否決的特性，但需要滿足特定條件且不能被修正。
在實際工作中，給測評師們降低了實施的難度，也減少了和被測評單位扯皮的概率，也算是等級保護2.0的一種進步吧。
*本文原創作者：起於凡而非於凡，本文屬於FreeBuf原創獎勵計劃，未經許可禁止轉載
