管理Azure SQL數(shù)據(jù)庫的授權(quán)安全性
在規(guī)劃微軟Azure SQL Database部署時，一定要考慮所有需要在深度防御策略中實現(xiàn)的安全措施。我們已經(jīng)在前面一篇文章中詳細介紹了實現(xiàn)基于防火墻的保護措施的一個方面。此外，我們還概括介紹了這個平臺即服務（PaaS）產(chǎn)品中內(nèi)置的驗證、授權(quán)與加密特性。現(xiàn)在是時候更深入了解一些支持細粒度控制數(shù)據(jù)訪問的授權(quán)方法了，它們最多可以深入到控制各個數(shù)據(jù)庫對象和語句類型。
在很大程度上，Azure SQLDatabase集成的驗證與授權(quán)機制基于成熟SQL Server實例所使用的相同原則，它既可以部署在內(nèi)部網(wǎng)絡，也可以部署在Azure IaaS虛擬機上。然而，它們之間有一些值得注意的重要區(qū)別。在驗證方面，最重要的一點是缺少Windows集成身份驗證的支持。實際上，在每次建立SQL Database連接時，用戶都必須明確指定他們的登錄身份。這種方式與傳統(tǒng)SQL Server身份驗證方式相同，即便如此，還有一個重要的小問題。具體地說就是密碼重置，它會在本地使用場景中觸發(fā)自動重新驗證，從而導致會話中斷，即要求中斷當前會話，并且在重新連接之后才能繼續(xù)使用Azure SQL Database。（選擇采用這種方式的原因是為了消除自動重新連接可能對性能造成的負面影響，這對于基于云的服務而言尤為重要。）
從授權(quán)角度看，Azure SQLDatabase實現(xiàn)了方法更適合用在服務器層次上。最明顯的原因是，現(xiàn)在不能使用權(quán)限最高的sa登錄帳號和相應的sysadmin SQL服務器角色（以及所有其他固定的服務器角色）。相反，在管理一個托管各個SQL Database的邏輯SQL Server（包括表示一個數(shù)據(jù)庫管理單元的Azure平臺結(jié)構(gòu)）時，必須用到主數(shù)據(jù)庫中預定義的兩個角色，其中包括：
- loginmanager -分配了足夠創(chuàng)建和管理登錄帳號的權(quán)限（而不是securityadmin固定服務器角色）
- dbmanager -分配了創(chuàng)建和管理數(shù)據(jù)庫的權(quán)限（而不是dbcreator固定服務角色）
這個區(qū)別體現(xiàn)在服務級安全性的管理方式上，它可以避免管理員過分依賴于Object Explorer of the SQL Server Management Studio中Security文件夾的圖形界面，迫使他們在連接主數(shù)據(jù)庫時執(zhí)行相應的T-SQL語句。（雖然SQL ServerManagement Studio會通過將連接自動重定向主數(shù)據(jù)庫并在查詢窗口自動生成SQL登錄模板來實現(xiàn)透明的登錄過程）。
用戶數(shù)據(jù)庫角色與傳統(tǒng)SQL Server實現(xiàn)的已有角色相對應，并且包含以下角色：
- db_accessadmin分配了用于創(chuàng)建和管理數(shù)據(jù)庫用戶的權(quán)限。
- db_backupoperator分配了用于備份數(shù)據(jù)庫的權(quán)限。
- db_datareader分配了用于從所有數(shù)據(jù)庫表和視圖讀取數(shù)據(jù)的權(quán)限。
- db_datawriter分配了用于向所有數(shù)據(jù)庫表和視圖寫入數(shù)據(jù)的權(quán)限。
- db_ddladmin分配了用于在數(shù)據(jù)庫創(chuàng)建和管理對象的權(quán)限。
- db_denydatareader拒絕從數(shù)據(jù)庫任何一個表和視圖讀取數(shù)據(jù)的權(quán)限。
- db_denydatawriter拒絕向數(shù)據(jù)庫任何一個表和視圖寫入數(shù)據(jù)的權(quán)限。
- db_owner分配了用于執(zhí)行所有數(shù)據(jù)庫配置和管理的權(quán)限。
- db_securityadmin分配了用于管理數(shù)據(jù)庫角色成員和權(quán)限的權(quán)限。
如果想要進一步細分訪問權(quán)限，那么可以選擇使用模式級和對象級安全性，這就像數(shù)據(jù)庫角色一樣，與管理員熟悉的本地數(shù)據(jù)庫管理完全相同。具體地，你可以使用GRANT、REVOKE和DENY T-SQL語句控制每一個模式、對象實例或語句層次的權(quán)限。一定要記住，DENY優(yōu)先級高于顯式分配或基于角色的權(quán)限。
要創(chuàng)建登錄帳號，你需要創(chuàng)建一個主數(shù)據(jù)庫連接會話，而創(chuàng)建用戶帳號需要直接連接目標數(shù)據(jù)庫。這一點非常重要，因為同一個會話無法切換數(shù)據(jù)庫上下文（原來通常可以通過執(zhí)行語句USEdatabase T-SQL語句）——相反，你必須為每一個需要管理的數(shù)據(jù)庫建立獨立的會話。初始登錄帳號（也就是服務器級主登錄帳號）和主數(shù)據(jù)庫中相同名稱的用戶都是初始化SQL Server實例時自動創(chuàng)建的，無論是使用AzureManagement Portal、Azure PowerShell模塊還是執(zhí)行相應的REST API初始化都是這樣。從授權(quán)角度看，這個登錄帳號是唯一的，因為它隱含就分配了loginmanager和dbmanager角色所關聯(lián)的權(quán)限（即便它實際上不是這些角色的成員）。此外，你可以用它連接同一個邏輯服務器的任何一個數(shù)據(jù)庫。
因此，你可以使用CREATE LOGIN T-SQL語句創(chuàng)建更多的登錄帳號（查詢主數(shù)據(jù)庫的sys.sql_logins視圖就可以列舉所有的登錄帳號）。要想使用這些帳號信息連接任何一個數(shù)據(jù)庫（包括主數(shù)據(jù)庫），必須先在該數(shù)據(jù)庫上創(chuàng)建一個相對應的用戶帳號。實際上，如果想要指定一個loginmanager或dbmanager角色的新成員，則需要先使用服務器級主登錄帳號登錄主數(shù)據(jù)庫，創(chuàng)建一個新的登錄帳號，然后再創(chuàng)建一個與此登錄帳號相關聯(lián)的用戶（使用CREATEUSER (...) FROM LOGIN T-SQL語句），最后再執(zhí)行sp_addrolemember存儲過程。類似地，如果想讓這些登錄帳號可用于連接或管理任何一個用戶數(shù)據(jù)庫，則需要先連接該數(shù)據(jù)庫，在該數(shù)據(jù)庫上創(chuàng)建一個關聯(lián)的用戶帳號（同樣是使用 T-SQL語句），最后再執(zhí)行sp_addrolemember存儲過程將新創(chuàng)建的用戶分配給一個或多個數(shù)據(jù)庫級角色。然而，如果dbmanager的成員需要連接他們自己創(chuàng)建的數(shù)據(jù)，則不受這個要求的限制，因為他們隱含已經(jīng)關聯(lián)到dbo用戶帳號（這意味著它已經(jīng)是db_owner角色的成員）。
這就是我們總結(jié)的Azure SQLDatabase數(shù)據(jù)保護管理方法，其重點是使用權(quán)限作為防御未授權(quán)訪問的額外措施。在后續(xù)文章中，我們將繼續(xù)介紹在云和混合環(huán)境中運行SQL Server的相關問題。
