適用于：Azure SQL數(shù)據(jù)庫、Azure SQL托管實例
本文提供了有關如何解決常見安全要求的最佳做法。并非所有要求都適用于所有環(huán)境，你應該向數(shù)據(jù)庫和安全團隊咨詢要實現(xiàn)哪些功能。
解決常見的安全要求
本文檔提供有關如何解決使用Azure SQL數(shù)據(jù)庫和Azure SQL托管實例的新應用程序或現(xiàn)有應用程序的常見安全要求的指導。本文檔的內(nèi)容已從較高層面按照安全考慮因素進行組織。若要解決特定的威脅，請參閱常見安全威脅和潛在緩解措施部分。提供的某些建議在將應用程序從本地遷移到Azure時適用，不過，本文檔不會重點說明遷移方案。
本指南涉及的Azure SQL數(shù)據(jù)庫部署產(chǎn)品/服務
Azure SQL數(shù)據(jù)庫：服務器中的單一數(shù)據(jù)庫和彈性池
Azure SQL托管實例
本指南不涉及的部署產(chǎn)品/服務
Azure Synapse Analytics
Azure SQL VM(IaaS)
SQL Server
目標受眾
本文檔旨在用作現(xiàn)有Azure SQL數(shù)據(jù)庫安全性文檔的配套資源。
除非另有說明，否則我們建議遵循每個部分中列出的所有最佳做法，以實現(xiàn)相關的目標或要求。為了幫助客戶滿足特定的安全合規(guī)標準或最佳做法，在適用的情況下，“要求或目標”部分下面會列出重要的法規(guī)控制措施。本文參考了以下安全標準和法規(guī)：
FedRAMP：AC-04、AC-06
SOC：CM-3、SDL-3
ISO/IEC 27001：訪問控制、加密
Microsoft操作安全保障(OSA)做法：做法#1-6和#9
NIST?？?00-53安全控制：AC-5、AC-6
PCI DSS：6.3.2、6.4.2
我們計劃持續(xù)更新本文列出的建議和最佳做法。使用本文底部的"反饋"鏈接提供對此文檔的輸入或任何更正。
身份驗證
身份驗證是證明用戶所聲明身份的過程。Azure SQL數(shù)據(jù)庫和SQL托管實例支持兩種類型的身份驗證：
SQL身份驗證
Azure Active Directory身份驗證
備注
并非所有工具和第三方應用程序都支持Azure Active Directory身份驗證。
標識的集中管理
集中式標識管理提供以下優(yōu)勢：
管理組帳戶并控制用戶權限，而無需跨服務器、數(shù)據(jù)庫和托管實例重復登錄。
簡化且靈活的權限管理。
應用程序的大規(guī)模管理。
如何實現(xiàn)：
使用Azure Active Directory(Azure AD)身份驗證實現(xiàn)集中式標識管理。
最佳做法：
創(chuàng)建Azure AD租戶，創(chuàng)建用戶來表示人類用戶，并創(chuàng)建服務主體來表示應用、服務和自動化工具。服務主體相當于Windows和Linux中的服務帳戶。
通過組分配向Azure AD主體分配資源訪問權限：創(chuàng)建Azure AD組，向組授予訪問權限，并將各個成員添加到組中。在數(shù)據(jù)庫中，創(chuàng)建包含的數(shù)據(jù)庫用戶用于映射Azure AD組。若要在數(shù)據(jù)庫中分配權限，請將與Azure AD組關聯(lián)的用戶置于具有適當權限的數(shù)據(jù)庫角色中。
備注
在SQL托管實例中，還可以創(chuàng)建映射到master數(shù)據(jù)庫中的Azure AD主體的登錄名。請參閱CREATE LOGIN(Transact-SQL)。
使用Azure AD組可以簡化權限管理，組所有者和資源所有者都可以在組中添加/刪除成員。
為每個服務器或托管實例創(chuàng)建單獨的Azure AD管理員組。
請參閱為服務器預配Azure Active Directory管理員一文。
使用Azure AD審核活動報告監(jiān)視Azure AD組成員身份的更改。
對于托管實例，需要執(zhí)行一個單獨的步驟來創(chuàng)建Azure AD管理員。
請參閱為托管實例預配Azure Active Directory管理員一文。
備注
Azure AD身份驗證記錄在Azure SQL審核日志中，而不是記錄在Azure AD登錄日志中。
Azure中授予的azure RBAC權限不適用于Azure SQL數(shù)據(jù)庫或SQL托管實例權限。必須使用現(xiàn)有的SQL權限手動創(chuàng)建/映射此類權限。
在客戶端上，Azure AD身份驗證需要訪問Internet，或通過用戶定義的路由(UDR)訪問虛擬網(wǎng)絡。
Azure AD訪問令牌緩存在客戶端，其生存期取決于令牌配置。請參閱Azure Active Directory中可配置的令牌生存期一文
Azure AD多重身份驗證
內(nèi)容來源：OSA做法#2，ISO訪問控制(AC)
Azure AD多重身份驗證通過要求多種形式的身份驗證提供額外的安全性。
如何實現(xiàn)：
使用條件訪問在Azure AD中啟用多重身份驗證，并使用交互式身份驗證。
或者，為整個Azure AD或AD域啟用多重身份驗證。
最佳做法：
Azure AD(需要高級訂閱)中激活條件性訪問。
創(chuàng)建Azure AD組，并使用Azure AD條件訪問為選定的組啟用多重身份驗證策略。
可為整個Azure AD或者與Azure AD聯(lián)合的整個Active Directory啟用多重身份驗證。
對以交互方式請求密碼的Azure SQL數(shù)據(jù)庫和Azure SQL托管實例使用Azure AD交互式身份驗證模式，然后啟用多重身份驗證：
在SSMS中使用通用身份驗證。請參閱在Azure SQL數(shù)據(jù)庫、SQL托管實例和Azure Synapse Analytics中使用多重Azure AD身份驗證（SSMS對多重身份驗證的支持）一文。
使用SQL Server Data Tools(SSDT)中支持的交互式身份驗證。請參閱SQL Server Data Tools(SSDT)中的Azure Active Directory支持。
使用其他支持多重身份驗證的SQL工具。
SSMS向?qū)С?提取/部署數(shù)據(jù)庫操作的支持
sqlpackage.exe：選項“/ua”
sqlcmd實用工具：選項-G（交互式）
bcp實用工具：選項-G（交互式）
實現(xiàn)你的應用程序，以使用支持多重身份驗證的交互式身份驗證連接到Azure SQL數(shù)據(jù)庫或Azure SQL托管實例。
備注
此身份驗證模式需要使用基于用戶的標識。如果使用的受信任標識模型會繞過個體Azure AD用戶身份驗證（例如，使用Azure資源的托管標識），則不會應用多重身份驗證。
盡量減少對用戶使用基于密碼的身份驗證
內(nèi)容來源：OSA做法#4，ISO訪問控制(AC)
基于密碼的身份驗證方法是較弱的身份驗證形式。憑據(jù)可能會透露或者被錯誤地丟棄。
如何實現(xiàn)：
使用Azure AD集成身份驗證，此方法可消除密碼的使用。
最佳做法：
使用Windows憑據(jù)進行單一登錄身份驗證。將本地AD域與Azure AD相聯(lián)合，并使用Windows集成身份驗證（適用于Azure AD中已加入域的計算機）。
盡量減少對應用程序使用基于密碼的身份驗證
內(nèi)容來源：OSA做法#4，ISO訪問控制(AC)
如何實現(xiàn)：
啟用Azure托管標識。還可以使用集成式或基于證書的身份驗證。
最佳做法：
使用Azure資源的托管標識。
系統(tǒng)分配的托管標識
用戶分配的托管標識
從具有托管標識的Azure應用服務使用Azure SQL數(shù)據(jù)庫（無需更改代碼）
對應用程序使用基于證書的身份驗證。
請參閱此代碼示例。
對集成的聯(lián)合域和已加入域的計算機使用Azure AD身份驗證（參閱上一部分）。
請參閱集成身份驗證的示例應用程序。
保護密碼和機密
如果不可避免地需要使用密碼，請確保密碼受到保護。
如何實現(xiàn)：
使用Azure Key Vault存儲密碼和機密。在適用的情況下，請對Azure AD用戶使用Azure SQL數(shù)據(jù)庫的多重身份驗證。
最佳做法：
如果無法避免密碼或機密的使用，請在Azure Key Vault中存儲用戶密碼和應用程序機密，并通過Key Vault訪問策略管理訪問權限。
各種應用開發(fā)框架還可能提供框架特定的機制來保護應用中的機密。例如：ASP.NET Core應用。
對舊式應用程序使用SQL身份驗證
SQL身份驗證是指使用用戶名和密碼連接到Azure SQL數(shù)據(jù)庫或SQL托管實例時對用戶進行身份驗證。需要在每個服務器或托管實例中創(chuàng)建一個登錄名，并在每個數(shù)據(jù)庫中創(chuàng)建一個用戶。
如何實現(xiàn)：
使用SQL身份驗證。
最佳做法：
以服務器或?qū)嵗芾韱T的身份創(chuàng)建登錄名和用戶。除非將包含的數(shù)據(jù)庫用戶與密碼配合使用，否則所有密碼將存儲在master數(shù)據(jù)庫中。
請參閱控制和授予對SQL數(shù)據(jù)庫、SQL托管實例和Azure Synapse Analytics的數(shù)據(jù)庫訪問權限一文。
訪問管理
訪問管理（也稱為授權）是控制和管理已授權用戶對Azure SQL數(shù)據(jù)庫或SQL托管實例的訪問權限與特權的過程。
實施最低特權原則
內(nèi)容來源：FedRamp控制措施AC-06，NIST：AC-6，OSA做法#3
最低特權原則指出，用戶擁有的特權不應超過他們完成任務所需的特權。有關詳細信息，請參閱Just Enough Administration一文。
如何實現(xiàn)：
僅分配完成所需任務而需要的權限：
在SQL數(shù)據(jù)庫中：
使用粒度權限和用戶定義的數(shù)據(jù)庫角色（或托管實例中的服務器角色）：
創(chuàng)建所需的角色
CREATE ROLE
CREATE SERVER ROLE
創(chuàng)建所需的用戶
CREATE USER
將用戶作為成員添加到角色
ALTER ROLE
ALTER SERVER ROLE
然后將權限分配給角色。
GRANT
確保不要將用戶分配到不必要的角色。
在Azure資源管理器中：
使用內(nèi)置角色（如果可用）或Azure自定義角色，并分配所需的權限。
Azure內(nèi)置角色
Azure自定義角色
最佳做法：
以下最佳做法是可選的，但可以改善安全策略的易管理性和支持性：
如果可能，請從盡可能低的權限集開始，并在有實際需要（和理由）時逐個添加權限-而不要采用相反的方法：逐步去除權限。
避免將權限分配給單個用戶。改為以一致的方式使用角色（數(shù)據(jù)庫角色或服務器角色）。角色能夠為報告權限和排查權限問題提供很大的幫助。（Azure RBAC僅支持通過角色分配權限。）
創(chuàng)建和使用具有所需確切權限的自定義角色。實踐中使用的典型角色：
安全部署
管理員
開發(fā)人員
支持人員
審核員
自動化過程
最終用戶
只有當角色的權限與用戶所需的權限完全匹配時，才使用內(nèi)置角色?？蓪⒂脩舴峙涞蕉鄠€角色。
請記住，數(shù)據(jù)庫引擎中的權限可以在以下范圍內(nèi)應用（范圍越小，授予的權限的影響越?。?/span>
Azure中的服務器（master數(shù)據(jù)庫中的特殊角色）
數(shù)據(jù)庫
架構(gòu)
最佳做法是使用架構(gòu)在數(shù)據(jù)庫中授予權限。（另請參閱：架構(gòu)設計：有關架構(gòu)設計的建議和安全注意事項）
對象（表、視圖、過程等）
備注
不建議在對象級別應用權限，因為此級別會給整個實現(xiàn)帶來不必要的復雜性。如果決定使用對象級權限，應明確闡述這些權限。這同樣適用于列級權限，出于相同的原因，我們更不建議應用此類權限另請注意，默認情況下，表級DENY不會覆蓋列級授權。這需要激活通用標準合規(guī)性服務器配置。
使用漏洞評估(VA)執(zhí)行定期檢查，以測試權限是否過多。
實現(xiàn)職責分離
內(nèi)容來源：FedRamp：AC-04，NIST：AC-5，ISO：6.1.2、PCI 6.4.2，SOC：CM-3、SDL-3
“職責分離”描述將敏感任務拆分為要分配給不同用戶的多個任務的要求。職責分離有助于防止數(shù)據(jù)違規(guī)。
如何實現(xiàn)：
識別所需的職責分離級別。示例:
在開發(fā)/測試環(huán)境與生產(chǎn)環(huán)境之間
安全相關的任務、數(shù)據(jù)庫管理員(DBA)管理級別任務與開發(fā)人員任務。
示例:審核員為角色級安全性(RLS)創(chuàng)建安全策略，并使用DDL權限實現(xiàn)SQL數(shù)據(jù)庫對象。
識別有權訪問系統(tǒng)的用戶（和自動化過程）的綜合層次結(jié)構(gòu)。
根據(jù)所需的用戶組創(chuàng)建角色，并將權限分配給角色。
對于通過Azure門戶或PowerShell自動化完成的管理級任務，請使用Azure角色。查找符合要求的內(nèi)置角色，或者使用可用權限創(chuàng)建Azure自定義角色
在托管實例中為服務器范圍的任務（創(chuàng)建新的登錄名和數(shù)據(jù)庫）創(chuàng)建服務器角色。
為數(shù)據(jù)庫級任務創(chuàng)建數(shù)據(jù)庫角色。
對于某些敏感任務，考慮創(chuàng)建由證書簽名的特殊存儲過程，以代表用戶執(zhí)行這些任務。數(shù)字簽名存儲過程的一個重要優(yōu)點是，如果更改了該過程，則會立即刪除授予該過程的舊版本的權限。
示例：教程：使用證書為存儲過程簽名
使用Azure Key Vault中客戶管理的密鑰實現(xiàn)透明數(shù)據(jù)加密(TDE)，以便在數(shù)據(jù)所有者與安全所有者之間實現(xiàn)職責分離。
為了確保DBA無法看到高度敏感的數(shù)據(jù)但仍可執(zhí)行DBA任務，可將Always Encrypted與角色分離配合使用。
如果使用Always Encrypted不可行（最起碼在不付出極大成本和工作量的情況下做不到這一點，但如果付出，甚至可能會導致系統(tǒng)幾乎不可用），可以通過補償性的控制措施來采取折衷辦法，例如：
在過程中進行人工干預。
審核線索–有關審核的詳細信息，請參閱審核關鍵安全事件。
最佳做法：
確保將不同的帳戶用于開發(fā)/測試環(huán)境和生產(chǎn)環(huán)境。不同的帳戶有助于滿足測試和生產(chǎn)系統(tǒng)分離的原則。
避免將權限分配給單個用戶。改為以一致的方式使用角色（數(shù)據(jù)庫角色或服務器角色）。使用角色能夠為報告權限和排查權限問題提供很大的幫助。
當權限與所需權限完全匹配時使用內(nèi)置角色–如果多個內(nèi)置角色的所有權限的聯(lián)合導致100%匹配，則還可以同時分配多個角色。
當內(nèi)置角色授予的權限過多或不足時，創(chuàng)建并使用用戶定義的角色。
還可以通過T-SQL的SQL代理作業(yè)步驟或適用于Azure角色的Azure PIM暫時執(zhí)行角色分配（也稱為動態(tài)職責分離(DSD)）。
確保DBA無權訪問加密密鑰或密鑰存儲，而有權訪問密鑰的安全管理員無權訪問數(shù)據(jù)庫。(EKM)使用可擴展的密鑰管理可以使此分離更容易實現(xiàn)。Azure Key Vault可用于實現(xiàn)EKM。
始終確保針對安全相關的操作提供審核線索。
可以檢索Azure內(nèi)置角色的定義以查看所用的權限，并通過PowerShell根據(jù)這些信息的摘錄和累積創(chuàng)建自定義角色。
由于db_owner數(shù)據(jù)庫角色的任何成員都可以更改透明數(shù)據(jù)加密(TDE)等安全設置或更改SLO，因此，應謹慎地授予此成員身份。但是，許多任務要求使用db_owner特權。例如，更改數(shù)據(jù)庫選項等任何數(shù)據(jù)庫設置的任務。在任何解決方案中，審核都發(fā)揮著關鍵的作用。
無法限制db_owner的權限，因此應阻止管理帳戶查看用戶數(shù)據(jù)。如果數(shù)據(jù)庫中包含高度敏感的數(shù)據(jù)，可以使用Always Encrypted來安全阻止db_owners或任何其他DBA查看這些數(shù)據(jù)。
備注
對安全相關的任務或故障排除任務實現(xiàn)職責分離(SoD)會有難度。其他方面（例如開發(fā)和最終用戶角色）更易于分離。當其他解決方案不可行時，大多數(shù)合規(guī)性相關的控制措施允許使用替代的控制功能，例如審核。
執(zhí)行定期代碼評審
內(nèi)容來源：PCI：6.3.2，SOC：SDL-3
職責分離不局限于數(shù)據(jù)庫中的數(shù)據(jù)，它還包括應用程序代碼。惡意代碼可能會繞過安全控制。在將自定義代碼部署到生產(chǎn)環(huán)境之前，必須評審要部署的內(nèi)容，這一點至關重要。
如何實現(xiàn)：
使用支持源代碼管理的數(shù)據(jù)庫工具，例如Azure Data Studio。
實現(xiàn)分離的代碼部署過程。
在提交到主分支之前，必須由某個人員（代碼本身的作者除外）檢查代碼是否存在提升特權的風險，以及是否存在惡意的數(shù)據(jù)修改，以防止出現(xiàn)欺詐和惡意訪問。可以使用源代碼管理機制實現(xiàn)此目的。
最佳做法：
標準化：實現(xiàn)每次更新代碼時都要遵循的標準過程會很有幫助。
漏洞評估中的規(guī)則可以檢查是否存在過多的權限、是否使用了舊加密算法，以及數(shù)據(jù)庫架構(gòu)中是否存在其他安全問題。
可以在QA或測試環(huán)境中使用高級威脅防護來執(zhí)行更多的檢查，此技術將掃描容易受到SQL注入攻擊的代碼。
要注意的方面的示例：
從自動化SQL代碼更新部署內(nèi)部創(chuàng)建用戶或更改安全設置。
某個存儲過程根據(jù)提供的參數(shù)以不一致的方式更新單元格中的貨幣值。
確保執(zhí)行評審的人員是除原始代碼作者以外的個人，且熟悉代碼評審和安全編碼。
確保知道所有代碼更改來源。代碼可能位于T-SQL腳本中。它可能是要以視圖、函數(shù)、觸發(fā)器和存儲過程形式執(zhí)行或部署的臨時命令。它可能是SQL代理作業(yè)定義（步驟）的一部分。它還可能從SSIS包、Azure數(shù)據(jù)工廠和其他服務的內(nèi)部執(zhí)行。
數(shù)據(jù)保護
數(shù)據(jù)保護是通過加密或模糊處理來防止重要信息遭到透露的一組功能。
備注
Microsoft的Azure SQL數(shù)據(jù)庫和SQL托管實例已通過FIPS 140-2級別1合規(guī)認證。認證過程中已確認它嚴格使用FIPS 140-2級別1可接受的算法，以及這些算法的、經(jīng)FIPS 140-2級別1驗證的實例，包括符合所需密鑰長度、密鑰管理、密鑰生成和密鑰存儲的要求。此項認證意味著，我們的客戶在處理數(shù)據(jù)或者交付系統(tǒng)或應用程序的過程中，可以滿足使用FIPS 140-2級別1驗證實例的需求或要求。我們定義了上述語句中使用的術語"FIPS 140-2 Level 1相容"和"FIPS 140-2 Level 1相容性"，以演示其對美國和加拿大政府使用不同術語"FIPS 140-2 Level 1驗證"的預期適用性。
加密傳輸中的數(shù)據(jù)
內(nèi)容來源：OSA做法#6，ISO控制系列：Cryptography
當數(shù)據(jù)在客戶端與服務器之間移動時為其提供保護。請參閱網(wǎng)絡安全性。
靜態(tài)數(shù)據(jù)加密
內(nèi)容來源：OSA做法#6，ISO控制系列：Cryptography
靜態(tài)加密是指對數(shù)據(jù)庫、日志和備份文件中保存的數(shù)據(jù)進行加密保護。
如何實現(xiàn)：
對于2017年后在Azure SQL數(shù)據(jù)庫和SQL托管實例中創(chuàng)建的任何數(shù)據(jù)庫，默認將啟用通過服務托管的密鑰進行透明數(shù)據(jù)庫加密(TDE)。
在托管實例中，如果數(shù)據(jù)庫是使用本地服務器從還原操作創(chuàng)建的，則會遵循原始數(shù)據(jù)庫的TDE設置。如果未為原始數(shù)據(jù)庫啟用TDE，則我們建議手動為托管實例啟用TDE。
最佳做法：
不要將需要靜態(tài)加密的數(shù)據(jù)存儲在master數(shù)據(jù)庫中。無法使用TDE加密master數(shù)據(jù)庫。
如果需要提高透明度并精細控制TDE保護，請使用Azure Key Vault中客戶管理的密鑰。Azure Key Vault允許隨時撤銷權限，使數(shù)據(jù)庫不可訪問?？梢约泄芾鞹DE保護器及其他密鑰，或使用Azure Key Vault按自己的計劃輪換TDE保護器。
如果使用Azure Key Vault中客戶管理的密鑰，請參閱文章有關使用Azure Key Vault配置TDE的指導原則和如何使用Azure Key Vault配置異地災難恢復。
防止未經(jīng)授權的高特權用戶查看使用中的敏感數(shù)據(jù)
使用中的數(shù)據(jù)是指在執(zhí)行SQL查詢期間存儲在數(shù)據(jù)庫系統(tǒng)內(nèi)存中的數(shù)據(jù)。如果數(shù)據(jù)庫存儲敏感數(shù)據(jù)，則組織可能需要確保防止高特權用戶查看數(shù)據(jù)庫中的敏感數(shù)據(jù)。高特權用戶（例如組織中的Microsoft操作員或DBA）應該能夠管理數(shù)據(jù)庫，但不能通過查詢數(shù)據(jù)庫來查看并潛在地透露SQL進程內(nèi)存中的敏感數(shù)據(jù)。
需要確定哪些數(shù)據(jù)是敏感的，以及敏感數(shù)據(jù)是否必須在內(nèi)存中加密并且不可供管理員以明文形式訪問，用于確定這些事項的策略特定于你的組織以及你需要遵守的合規(guī)性規(guī)定。請參閱相關要求：識別并標記敏感數(shù)據(jù)。
如何實現(xiàn)：
使用Always Encrypted來確保不會以純文本形式公開Azure SQL數(shù)據(jù)庫或SQL托管實例中的敏感數(shù)據(jù)，即使是內(nèi)存中/使用中的數(shù)據(jù)。Always Encrypted可以防止數(shù)據(jù)庫管理員(DBA)和云管理員（或者可以仿冒未經(jīng)授權的高特權用戶的惡意行動者）查看數(shù)據(jù)，并使你能夠以更高的力度控制誰可以訪問數(shù)據(jù)。
最佳做法：
Always Encrypted不能取代靜態(tài)數(shù)據(jù)加密(TDE)或傳輸中數(shù)據(jù)加密(SSL/TLS)。為了盡量減輕對性能和功能的影響，請不要將Always Encrypted用于非敏感數(shù)據(jù)。建議將Always Encrypted與TDE和傳輸層安全性(TLS)結(jié)合使用，以全面保護靜態(tài)數(shù)據(jù)、傳輸中的數(shù)據(jù)和使用中的數(shù)據(jù)。
在生產(chǎn)數(shù)據(jù)庫中部署Always Encrypted之前，請先評估對所識別出的敏感數(shù)據(jù)列進行加密會帶來的影響。通常情況下，Always Encrypted會降低對加密列的查詢功能，并具有其他限制，如Always Encrypted-功能詳細信息中所列。因此，你可能需要在客戶端重構(gòu)你的應用程序來重新實現(xiàn)查詢不支持的功能，或者/并且重構(gòu)你的數(shù)據(jù)庫架構(gòu)，包括存儲過程、函數(shù)、視圖和觸發(fā)器的定義。如果現(xiàn)有應用程序未遵守Always Encrypted的限制，則可能無法使用加密列。雖然支持Always Encrypted的Microsoft工具、產(chǎn)品和服務的生態(tài)系統(tǒng)在不斷增長，但它們中還是有許多不能使用加密列。加密列還可能會影響查詢性能，具體取決于工作負荷的特征。
如果使用Always Encrypted來防止惡意DBA查看數(shù)據(jù)，請通過角色分離來管理Always Encrypted密鑰。安全管理員可以使用角色分離來創(chuàng)建物理密鑰。DBA在數(shù)據(jù)庫中創(chuàng)建用于描述物理密鑰的列主密鑰和列加密密鑰元數(shù)據(jù)對象。在此過程中，安全管理員不需要訪問數(shù)據(jù)庫，且DBA不需要訪問純文本形式的物理密鑰。
將列主密鑰存儲在Azure Key Vault中，以方便管理。避免使用會使密鑰管理變得困難的Windows證書存儲（以及一般的分布式密鑰存儲解決方案，而不是集中式密鑰管理解決方案）。
仔細考慮使用多個密鑰（列主密鑰或列加密密鑰）的利弊。保留少量的密鑰以減小密鑰管理成本。在穩(wěn)定態(tài)的環(huán)境中（而不是在密鑰輪換的中途），為每個數(shù)據(jù)庫準備一個列主密鑰和一個列加密密鑰通常已足夠。如果有不同的用戶組，而每個組使用不同的密鑰并訪問不同的數(shù)據(jù)，則可能需要更多的密鑰。
根據(jù)合規(guī)要求輪換列主密鑰。如果還需要輪換列加密密鑰，請考慮使用在線加密來盡量減少應用程序停機時間。
如果需要支持數(shù)據(jù)計算（相等性），請使用確定性加密。否則請使用隨機加密。避免將確定性加密用于低熵數(shù)據(jù)集或采用眾所周知分布形式的數(shù)據(jù)集。
如果你擔心第三方在合法的情況下訪問你的數(shù)據(jù)，請確保能夠以純文本形式訪問密鑰和數(shù)據(jù)的所有應用程序和工具在Microsoft Azure云的外部運行。如果第三方無權訪問密鑰，則除非繞過加密，否則他們無法解密數(shù)據(jù)。
Always Encrypted無法輕松支持授予對密鑰（和受保護數(shù)據(jù)）的臨時訪問權限。例如，如果需要與DBA共享密鑰，使DBA能夠?qū)γ舾袛?shù)據(jù)和加密的數(shù)據(jù)執(zhí)行一些清理操作?？煽砍蜂NDBA的數(shù)據(jù)訪問權限的唯一方法是，同時輪換用于保護數(shù)據(jù)的列加密密鑰和列主密鑰，而這是一項開銷較高的操作。
若要訪問已加密列中的純文本值，用戶需要有權訪問用于保護列的列主密鑰(CMK)（在保存CMK的密鑰存儲中進行配置）。用戶還需要擁有“查看任何列主密鑰定義”和“查看任何列加密密鑰定義”數(shù)據(jù)庫權限。
通過加密控制應用程序用戶對敏感數(shù)據(jù)的訪問
可以使用加密來確保只有有權訪問加密密鑰的特定應用程序用戶才能查看或更新數(shù)據(jù)。
如何實現(xiàn)：
使用單元級加密(CLE)。有關詳細信息，請參閱加密數(shù)據(jù)列一文。
使用Always Encrypted，但要注意其限制。下面列出了限制。
最佳實踐
使用CLE時：
通過SQL權限和角色控制對密鑰的訪問。
使用AES(推薦AES 256)進行數(shù)據(jù)加密。由于存在已知漏洞，RC4、DES和TripleDES等算法已遭棄用，請不要使用它們。
使用非對稱密鑰/證書（而不是密碼）來保護對稱密鑰，以避免使用3DES。
通過導出/導入（bacpac文件）使用單元級加密遷移數(shù)據(jù)庫時請小心。
有關在遷移數(shù)據(jù)時如何防止丟失密鑰以及其他最佳做法指導，請參閱有關在Azure SQL數(shù)據(jù)庫中使用單元級加密的建議。
請記住，Always Encrypted主要用于防止Azure SQL數(shù)據(jù)庫的高特權用戶（云操作員、DBA）查看使用中的敏感數(shù)據(jù)-請參閱防止防止未經(jīng)授權的高特權用戶查看使用中的敏感數(shù)據(jù)。使用Always Encrypted防止應用程序用戶查看數(shù)據(jù)時，請注意以下難點：
默認情況下，支持Always Encrypted的所有Microsoft客戶端驅(qū)動程序都會維護列加密密鑰的全局緩存（每個應用程序一個緩存）。在客戶端驅(qū)動程序通過聯(lián)系保存列主密鑰的密鑰存儲獲取純文本列加密密鑰后，將會緩存純文本列加密密鑰。這使得將數(shù)據(jù)與多用戶應用程序的用戶相隔離變得困難。如果應用程序在與密鑰存儲交互（例如Azure Key Vault）時模擬最終用戶，則在用戶的查詢使用列加密密鑰填充緩存之后，需要同一個密鑰但由其他用戶觸發(fā)的后續(xù)查詢將使用緩存的密鑰。驅(qū)動程序不會調(diào)用密鑰存儲，也不會檢查第二個用戶是否有權訪問列加密密鑰。因此，即使用戶無權訪問密鑰，也可以查看加密的數(shù)據(jù)。若要在多用戶應用程序中實現(xiàn)用戶隔離，可以禁用列加密密鑰緩存。禁用緩存會導致性能開銷增大，因為驅(qū)動程序需要聯(lián)系密鑰存儲來完成每個數(shù)據(jù)加密或解密操作。
在保留數(shù)據(jù)格式的同時防止應用程序用戶在未經(jīng)授權的情況下查看數(shù)據(jù)
防止未經(jīng)授權的用戶查看數(shù)據(jù)的另一種方法是對數(shù)據(jù)進行模糊處理或掩碼，同時保留數(shù)據(jù)類型和格式，以確保用戶應用程序可以繼續(xù)處理和顯示數(shù)據(jù)。
如何實現(xiàn)：
使用動態(tài)數(shù)據(jù)掩碼來模糊處理表列。
備注
Always Encrypted不能與動態(tài)數(shù)據(jù)掩碼配合工作。無法加密和掩碼同一個列，這意味著，需確定是要優(yōu)先保護使用中的數(shù)據(jù)，還是通過動態(tài)數(shù)據(jù)掩碼來對應用用戶掩碼數(shù)據(jù)。
最佳做法：
備注
動態(tài)數(shù)據(jù)掩碼不可用于防止高特權用戶查看數(shù)據(jù)。掩碼策略不適用于擁有管理訪問權限的用戶，例如db_owner。
不要允許應用用戶運行臨時查詢（因為他們也許可以克服動態(tài)數(shù)據(jù)掩碼）。
有關詳細信息，請參閱使用推理或暴力破解技術繞過掩碼一文。
使用適當?shù)脑L問控制策略（通過SQL權限、角色、RLS）來限制用戶在掩碼列中進行更新的權限。對列進行掩碼不會阻止對該列進行更新。如果查詢掩碼列時收到掩碼數(shù)據(jù)的用戶擁有寫入權限，則他們可以更新這些數(shù)據(jù)。
動態(tài)數(shù)據(jù)掩碼不會保留掩碼值的統(tǒng)計屬性。這可能會影響查詢結(jié)果（例如，包含篩選謂詞的查詢或者對掩碼數(shù)據(jù)的聯(lián)接）。
網(wǎng)絡安全性
網(wǎng)絡安全性是指用于保護傳輸?shù)紸zure SQL數(shù)據(jù)庫的數(shù)據(jù)的訪問控制和最佳做法。
配置客戶端以安全連接到SQL數(shù)據(jù)庫/SQL托管實例
有關如何防范存在已知漏洞（例如，使用早期TLS協(xié)議和密碼套件）的客戶端計算機和應用程序連接到Azure SQL數(shù)據(jù)庫和SQL托管實例的最佳做法。
如何實現(xiàn)：
確保連接到Azure SQL數(shù)據(jù)庫和SQL托管實例的客戶端計算機使用傳輸層安全性(TLS)。
最佳做法：
配置所有應用和工具以連接到啟用了加密的SQL數(shù)據(jù)庫
Encrypt=On，TrustServerCertificate=Off（或者在非Microsoft驅(qū)動程序中配置相應的設置）。
如果應用使用的驅(qū)動程序不支持TLS或者支持早期版本的TLS，請盡可能地更換驅(qū)動程序。如果無法做到這一點，請認真評估安全風險。
減少通過SSL 2.0、SSL 3.0、TLS 1.0和TLS 1.1中的漏洞發(fā)起的攻擊途徑：根據(jù)傳輸層安全性(TLS)注冊表設置，在連接到Azure SQL數(shù)據(jù)庫的客戶端計算機上禁用相關的途徑。
檢查客戶端上的密碼套件：TLS/SSL(Schannel SSP)中的密碼套件。具體而言，根據(jù)配置TLS密碼套件順序禁用3DES。
對于Azure SQL數(shù)據(jù)庫和SQL托管實例，將對“代理”和“重定向”連接類型強制加密。對于Azure SQL托管實例，請使用“代理”連接類型（默認設置），因為這可以強制在服務器端加密?！爸囟ㄏ颉边B接類型目前不支持加密強制，僅在專用IP連接上可用。
盡量減少受攻擊面
盡量減少惡意用戶可以攻擊的特征數(shù)。對Azure SQL數(shù)據(jù)庫實現(xiàn)網(wǎng)絡訪問控制。
內(nèi)容來源：OSA做法#5
如何實現(xiàn)：
在SQL數(shù)據(jù)庫中：
在服務器級別將“允許訪問Azure服務”設置為“關閉”
使用VNet服務終結(jié)點和VNet防火墻規(guī)則。
使用專用鏈接（預覽）。
在SQL托管實例中：
遵循網(wǎng)絡要求中的指導原則。
最佳做法：
通過連接到專用終結(jié)點（例如，使用專用數(shù)據(jù)路徑）來限制對Azure SQL數(shù)據(jù)庫和SQL托管實例的訪問：
可將托管實例隔離在虛擬網(wǎng)絡內(nèi)，防止外部訪問。位于同一區(qū)域的相同或?qū)Φ忍摂M網(wǎng)絡中的應用程序和工具可以直接訪問它。位于不同區(qū)域的應用程序和工具可使用虛擬網(wǎng)絡到虛擬網(wǎng)絡連接，或使用ExpressRoute線路對等互連來建立連接。客戶應使用網(wǎng)絡安全組(NSG)來僅限通過端口1433訪問需要訪問托管實例的資源。
對于SQL數(shù)據(jù)庫，請使用專用鏈接功能，該功能為虛擬網(wǎng)絡中的服務器提供專用專用IP。還可使用配置了虛擬網(wǎng)絡防火墻規(guī)則的虛擬網(wǎng)絡服務終結(jié)點來限制對服務器的訪問。
移動用戶應使用點到站點VPN連接，通過數(shù)據(jù)路徑進行連接。
連接到本地網(wǎng)絡的用戶應使用站點到站點VPN連接或ExpressRoute，通過數(shù)據(jù)路徑進行連接。
可以通過連接到公共終結(jié)點（例如，使用公共數(shù)據(jù)路徑）來訪問Azure SQL數(shù)據(jù)庫和SQL托管實例。應考慮以下最佳做法：
對于SQL數(shù)據(jù)庫中的服務器，請使用IP防火墻規(guī)則，僅限訪問已授權的IP地址。
對于SQL托管實例，請使用網(wǎng)絡安全組(NSG)，僅限通過端口3342訪問所需的資源。有關詳細信息，請參閱在公共終結(jié)點中安全使用托管實例。
備注
SQL托管實例公共終結(jié)點默認未啟用，必須顯式啟用它。如果公司政策禁止使用公共終結(jié)點，請首先使用Azure Policy來防止啟用公共終結(jié)點。
設置Azure網(wǎng)絡組件：
按照Azure網(wǎng)絡安全最佳做法進行操作。
根據(jù)Azure虛擬網(wǎng)絡常見問題解答(FAQ)和計劃中所述的最佳做法規(guī)劃虛擬網(wǎng)絡配置。
將虛擬網(wǎng)絡劃分為多個子網(wǎng)，并將類似角色的資源（例如，前端與后端資源）分配到同一子網(wǎng)。
使用網(wǎng)絡安全組(NSG)來控制Azure虛擬網(wǎng)絡邊界范圍內(nèi)子網(wǎng)之間的流量。
為訂閱啟用Azure網(wǎng)絡觀察程序，以監(jiān)視入站和出站網(wǎng)絡流量。
配置Power BI以安全連接到SQL數(shù)據(jù)庫/SQL托管實例
最佳做法：
對于Power BI Desktop，請盡可能地使用專用數(shù)據(jù)路徑。
根據(jù)傳輸層安全性(TLS)注冊表設置在客戶端計算機上設置注冊表項，確保Power BI Desktop使用TLS1.2進行連接。
通過Power BI行級安全性(RLS)限制特定用戶的數(shù)據(jù)訪問權限。
對于Power BI服務，請使用本地數(shù)據(jù)網(wǎng)關，同時請記住限制和注意事項。
配置應用服務以安全連接到SQL數(shù)據(jù)庫/SQL托管實例
最佳做法：
對于簡單的Web應用，通過公共終結(jié)點進行連接需要將“允許Azure服務”設置為“打開”。
將應用與Azure虛擬網(wǎng)絡集成，以通過專用數(shù)據(jù)路徑連接到托管實例。（可選）還可以部署采用應用服務環(huán)境(ASE)的Web應用。
對于連接到SQL數(shù)據(jù)庫中的數(shù)據(jù)庫的、采用ASE的Web應用或者與虛擬網(wǎng)絡集成的Web應用，可以使用虛擬網(wǎng)絡服務終結(jié)點和虛擬網(wǎng)絡防火墻規(guī)則來限制從特定虛擬網(wǎng)絡和子網(wǎng)的訪問。然后，將“允許Azure服務”設置為“關閉”。還可以通過專用數(shù)據(jù)路徑將ASE連接到SQL托管實例中的托管實例。
確保Web應用按照使用Azure應用服務保護平臺即服務(PaaS)Web和移動應用程序的最佳做法一文進行了配置。
安裝Web應用程序防火墻(WAF)，以防止Web應用遭到常見的惡意利用和出現(xiàn)漏洞。
配置Azure虛擬機以安全連接到SQL數(shù)據(jù)庫/SQL托管實例
最佳做法：
在Azure虛擬機的NSG中結(jié)合使用“允許”和“拒絕”規(guī)則，以控制可從VM訪問哪些區(qū)域。
確保VM根據(jù)Azure中IaaS工作負載的安全性最佳做法一文進行了配置。
確保所有VM與特定的虛擬網(wǎng)絡和子網(wǎng)相關聯(lián)。
根據(jù)關于強制隧道中的指導，評估是否需要默認路由0.0.0.0/Internet。
如果需要（例如在前端子網(wǎng)中），請保留默認路由。
如果不需要（例如在中間層或后端子網(wǎng)中），請啟用強制隧道，使流量不會通過Internet抵達本地（即跨界）。
如果使用對等互連或者連接到本地，請實現(xiàn)可選默認路由。
如果需要將虛擬網(wǎng)絡中的所有流量發(fā)送到網(wǎng)絡虛擬設備進行數(shù)據(jù)包檢查，請實現(xiàn)用戶定義的路由。
使用虛擬網(wǎng)絡服務終結(jié)點通過Azure主干網(wǎng)絡安全訪問Azure存儲等PaaS服務。
防范分布式拒絕服務(DDoS)攻擊
分布式拒絕服務(DDoS)攻擊由惡意用戶嘗試向Azure SQL數(shù)據(jù)庫發(fā)送大量網(wǎng)絡流量，目的是使Azure基礎結(jié)構(gòu)成為驚人，并導致其拒絕有效登錄和工作負荷。
中提到的：OSA實踐#9
如何實現(xiàn)：
在Azure平臺中，會自動啟用DDoS保護。它包括always on流量監(jiān)視和對公共終結(jié)點上網(wǎng)絡級別攻擊的實時緩解。
使用Azure DDoS防護來監(jiān)視與虛擬網(wǎng)絡中部署的資源關聯(lián)的公共IP地址。
使用AZURE SQL數(shù)據(jù)庫的高級威脅防護來檢測對數(shù)據(jù)庫的拒絕服務(DoS)攻擊。
最佳做法：
遵循最小化攻擊面中所述的做法有助于最大程度地減少DDoS攻擊威脅。
高級威脅防護強力強制SQL憑據(jù)警報有助于檢測暴力破解攻擊。在某些情況下，警報甚至可以區(qū)分滲透測試工作負荷。
對于托管連接到SQL數(shù)據(jù)庫的應用程序的Azure VM：
遵循建議，在Azure安全中心中通過面向Internet的終結(jié)點限制訪問。
使用虛擬機規(guī)模集在Azure Vm上運行應用程序的多個實例。
禁用來自Internet的RDP和SSH，以防止強力攻擊。
監(jiān)視、日志記錄和審核
本部分所述的功能可幫助你檢測異?；顒?，這些活動指示非同尋?；蛘邼撛谟泻Φ脑L問或惡意利用數(shù)據(jù)庫的企圖。本部分還將提供有關配置數(shù)據(jù)庫審核來跟蹤和捕獲數(shù)據(jù)庫事件的最佳做法。
防范數(shù)據(jù)庫遭到攻擊
高級威脅防護可在發(fā)生異常活動時提供安全警報，讓我們檢測潛在威脅并做出響應。
如何實現(xiàn)：
使用適用于SQL的高級威脅防護來檢測非同尋?；蛘邼撛谟泻Φ脑L問或惡意利用數(shù)據(jù)庫的企圖，包括：
SQL注入攻擊。
憑據(jù)盜竊/泄露。
特權濫用。
數(shù)據(jù)透露。
最佳做法：
為特定服務器或托管實例配置Azure Defender for SQL。還可以通過切換到Azure安全中心標準層，為訂閱中的所有服務器和托管實例配置Azure Defender for SQL。
若要獲得完整的調(diào)查體驗，建議啟用SQL數(shù)據(jù)庫審核。使用審核可以跟蹤數(shù)據(jù)庫事件，并將這些事件寫入到Azure存儲帳戶或Azure Log Analytics工作區(qū)中的審核日志。
審核關鍵安全事件
跟蹤數(shù)據(jù)庫事件有助于了解數(shù)據(jù)庫活動?？梢远床炜赡苤甘緲I(yè)務關注點或可疑安全違規(guī)的差異與異常。此措施還有助于遵守法規(guī)標準。
如何實現(xiàn)：
啟用SQL數(shù)據(jù)庫審核或托管實例審核以跟蹤數(shù)據(jù)庫事件，并將這些事件寫入到Azure存儲帳戶、Log Analytics工作區(qū)（預覽版）或事件中心（預覽版）中的審核日志。
可將審核日志寫入Azure存儲帳戶、寫入Log Analytics工作區(qū)（供Azure Monitor日志使用），或?qū)懭胧录行模ü┦录行氖褂茫？梢詫⑦@些選項隨意組合起來進行配置，審核日志會寫入到每一個之中。
最佳做法：
在服務器上配置SQL數(shù)據(jù)庫審核或配置托管實例審核以審核事件后，該服務器上所有現(xiàn)有的和新建的數(shù)據(jù)庫都會被審核。
審核策略默認包括對數(shù)據(jù)庫執(zhí)行的所有操作（查詢、存儲過程，以及成功和失敗的登錄），這可能會導致生成大量的審核日志。建議客戶使用PowerShell對不同類型的操作和操作組配置審核。此項配置有助于控制審核的操作數(shù)量，并將事件丟失的風險降到最低。自定義審核配置可讓客戶僅捕獲所需的審核數(shù)據(jù)。
可以在Azure門戶中直接使用審核日志，或者從配置的存儲位置使用。
備注
啟用在Log Analytics中進行審核會根據(jù)引入速率產(chǎn)生成本。請注意，使用此選項會產(chǎn)生相關的成本；或者，可以考慮將審核日志存儲在Azure存儲帳戶中。
其他資源：
SQL數(shù)據(jù)庫審核
SQL Server審核
保護審核日志
限制對存儲帳戶的訪問，以支持職責分離，并將DBA與審核員區(qū)分開來。
如何實現(xiàn)：
將審核日志保存到Azure存儲時，請確保按照最低安全原則來限制對存儲帳戶的訪問?？刂普l有權訪問存儲帳戶。
有關詳細信息，請參閱授權訪問Azure存儲。
最佳做法：
控制對審核目標的訪問是將DBA與審核員相區(qū)分時使用的重要概念。
審核對敏感數(shù)據(jù)的訪問時，請考慮使用數(shù)據(jù)加密來保護數(shù)據(jù)，以免向?qū)徍藛T透露信息。有關詳細信息，請參閱防止未經(jīng)授權的高特權用戶查看使用中的敏感數(shù)據(jù)部分。
安全管理
本部分介紹有關管理數(shù)據(jù)庫安全態(tài)勢的各個方面和最佳做法。其中提供了有關確保根據(jù)安全標準配置數(shù)據(jù)庫、發(fā)現(xiàn)漏洞，以及分類和跟蹤對數(shù)據(jù)庫中潛在敏感數(shù)據(jù)的訪問的最佳做法。
確保根據(jù)安全最佳做法配置數(shù)據(jù)庫
通過發(fā)現(xiàn)并修正潛在數(shù)據(jù)庫漏洞來主動改善數(shù)據(jù)庫的安全性。
如何實現(xiàn)：
啟用SQL漏洞評估(VA)來掃描數(shù)據(jù)庫的安全問題，并使其定期對數(shù)據(jù)庫自動運行。
最佳做法：
對數(shù)據(jù)庫運行首次VA，在補救不符合安全最佳做法的失敗檢查后反復運行VA。設置可接受配置的基線，直到掃描結(jié)果全部正常，或所有檢查均已通過。
將定期的重復掃描配置為每周運行一次，并配置相關人員來接收摘要電子郵件。
完成每周掃描后查看VA摘要。對于發(fā)現(xiàn)的任何漏洞，評估與前一次掃描結(jié)果的偏差，并確定是否應解決本次檢查發(fā)現(xiàn)的問題。查看配置發(fā)生更改是否有合理的原因。
解決檢查發(fā)現(xiàn)的問題并更新相關的基線。為解決措施創(chuàng)建票證項，并在解決問題之前跟蹤這些項。
其他資源：
SQL漏洞評估
SQL漏洞評估服務有助于識別數(shù)據(jù)庫漏洞
識別并標記敏感數(shù)據(jù)
發(fā)現(xiàn)可能包含敏感數(shù)據(jù)的列。什么數(shù)據(jù)是敏感數(shù)據(jù)在很大程度上取決于客戶、合規(guī)性規(guī)定等，并且需要由負責該數(shù)據(jù)的用戶進行評估。將列分類以使用基于敏感性的高級審核和保護方案。
如何實現(xiàn)：
使用SQL數(shù)據(jù)發(fā)現(xiàn)和分類來發(fā)現(xiàn)、分類、標記和保護數(shù)據(jù)庫中的敏感數(shù)據(jù)。
在SQL數(shù)據(jù)發(fā)現(xiàn)和分類儀表板中查看自動發(fā)現(xiàn)創(chuàng)建的分類建議。接受相關的分類，以使用分類標簽來持久標記敏感數(shù)據(jù)。
對于未被自動機制發(fā)現(xiàn)的任何其他敏感數(shù)據(jù)字段，請手動添加分類。
有關詳細信息，請參與SQL數(shù)據(jù)發(fā)現(xiàn)和分類。
最佳做法：
定期監(jiān)視分類儀表板，準確評估數(shù)據(jù)庫的分類狀態(tài)?？梢詫С龌虼蛴∮嘘P數(shù)據(jù)庫分類狀態(tài)的報告，以使在合規(guī)與審核措施中共享。
持續(xù)監(jiān)視SQL漏洞評估中建議的敏感數(shù)據(jù)的狀態(tài)。跟蹤敏感數(shù)據(jù)發(fā)現(xiàn)規(guī)則，識別建議列中的任何分類偏差。
使用根據(jù)你的組織的特定需求定制的方式使用分類。在Azure安全中心的SQL信息保護策略中，自定義信息保護策略(敏感度標簽、信息類型、發(fā)現(xiàn)邏輯)。
跟蹤對敏感數(shù)據(jù)的訪問
在審核日志中監(jiān)視誰訪問了敏感數(shù)據(jù)，并捕獲對敏感數(shù)據(jù)運行的查詢。
如何實現(xiàn)：
結(jié)合使用SQL審核和數(shù)據(jù)分類。
在SQL數(shù)據(jù)庫審核日志中，可以專門跟蹤對敏感數(shù)據(jù)的訪問。還可以查看訪問的數(shù)據(jù)及其敏感性標簽等信息。有關詳細信息，請參閱數(shù)據(jù)發(fā)現(xiàn)和分類和審核對敏感數(shù)據(jù)的訪問。
最佳做法：
參閱有關審核和數(shù)據(jù)分類的最佳做法部分：
審核關鍵安全事件
識別并標記敏感數(shù)據(jù)
可視化安全性與合規(guī)性狀態(tài)
使用統(tǒng)一的基礎結(jié)構(gòu)安全管理系統(tǒng)來增強數(shù)據(jù)中心（包括SQL數(shù)據(jù)庫中的數(shù)據(jù)庫）的安全態(tài)勢。查看有關數(shù)據(jù)庫安全性與合規(guī)性狀態(tài)的建議列表。
如何實現(xiàn)：
在Azure安全中心監(jiān)視SQL相關的安全建議與正在進行的威脅。
常見安全威脅和潛在緩解措施
本部分幫助你找到用于防范特定攻擊途徑的安全措施。遵循上述一條或多條安全指導原則預期可以實現(xiàn)大部分緩解措施。
安全威脅：數(shù)據(jù)透露
Data透露是指在未經(jīng)授權的情況下，從計算機或服務器復制、傳輸或檢索數(shù)據(jù)。查看維基百科中的數(shù)據(jù)透露定義。
通過公共終結(jié)點連接到服務器會帶來數(shù)據(jù)透露的風險，因為這需要客戶向公共IP打開其防火墻。
場景1：Azure VM上的某個應用程序連接到Azure SQL數(shù)據(jù)庫中的某個數(shù)據(jù)庫。惡意行動者獲取VM的訪問權限并入侵到其中。在此場景中，數(shù)據(jù)透露表示使用惡意VM的外部實體連接到數(shù)據(jù)庫，復制個人數(shù)據(jù)，并將這些數(shù)據(jù)存儲在Blob存儲中或者不同訂閱內(nèi)的不同SQL數(shù)據(jù)庫中。
場景2：惡意DBA。這種場景通常出現(xiàn)在受管制行業(yè)的安全敏感型客戶那里。在此場景中，高特權用戶可將Azure SQL數(shù)據(jù)庫中的數(shù)據(jù)復制到不受數(shù)據(jù)所有者控制的其他訂閱。
潛在緩解措施：
Azure SQL數(shù)據(jù)庫和SQL托管實例目前提供以下技術來緩解數(shù)據(jù)透露威脅：
在Azure VM的NSG中結(jié)合使用“允許”和“拒絕”規(guī)則，以控制可從VM訪問哪些區(qū)域。
如果在SQL數(shù)據(jù)庫中使用服務器，請設置以下選項：
將“允許Azure服務”設置為“關閉”。
設置VNet防火墻規(guī)則，僅允許來自包含你的Azure VM的子網(wǎng)的流量。
使用專用鏈接
對于SQL托管實例，使用專用IP訪問默認可以解決惡意VM的首要數(shù)據(jù)透露隱患。在子網(wǎng)中啟用子網(wǎng)委托功能，以在SQL托管實例子網(wǎng)中自動設置最嚴格的策略。
惡意DBA隱患主要出現(xiàn)在SQL托管實例上，因為SQL托管實例的受攻擊面較大，而網(wǎng)絡要求對客戶是可見的。此問題的最佳緩解措施是首先應用本安全指南中的所有做法，以防止出現(xiàn)惡意DBA的情景（不僅可以解決數(shù)據(jù)透露）。Always Encrypted是保護敏感數(shù)據(jù)的一種方法，它可以加密敏感數(shù)據(jù)，并使DBA無法訪問密鑰。
業(yè)務連續(xù)性和可用性的安全性方面
大多數(shù)安全標準在操作連續(xù)性方面解決數(shù)據(jù)可用性問題，實現(xiàn)此效果的方式是實施冗余和故障轉(zhuǎn)移功能來避免單一故障點。對于災難恢復方案，常見的做法是保留數(shù)據(jù)和日志文件的備份。以下部分概述了Azure中內(nèi)置的功能。此外，提供了可根據(jù)具體需求進行配置的其他選項：
Azure提供內(nèi)置的高可用性：SQL數(shù)據(jù)庫和SQL托管實例的高可用性
“業(yè)務關鍵”層包括故障轉(zhuǎn)移組、完整和差異日志備份，以及默認已啟用的時間點還原備份：
自動備份
使用自動數(shù)據(jù)庫備份恢復數(shù)據(jù)庫-時間點還原
可以配置其他業(yè)務連續(xù)性功能，如跨不同Azure地域的區(qū)域冗余配置和自動故障轉(zhuǎn)移組：
高級&業(yè)務關鍵服務層的高可用性區(qū)域冗余配置
常規(guī)用途服務層的高可用性區(qū)域冗余配置
業(yè)務連續(xù)性概述
閩公網(wǎng)安備 35010202001226號
