從歷史上看，對于在云端運行關(guān)鍵性應(yīng)用的安全性一直存有許多憂慮，特別是基礎(chǔ)系統(tǒng)。有些想成為微軟SQL Azure云數(shù)據(jù)庫服務(wù)用戶的人仍然猶豫不決，但這并不是SQL Azure安全性所導致的。而是因為他們擔心失去數(shù)據(jù)庫環(huán)境的控制權(quán)。

　　SQL Server數(shù)據(jù)庫咨詢顧問Denny Cherry 說：“很多問題都源于一個事實，他們擔心喪失控制權(quán)。” 微軟關(guān)注數(shù)據(jù)中心的物理安全性而不是Windows的安全性。這讓用戶持懷疑態(tài)度，沒有辦法使他們可以得到一份過去30天中系統(tǒng)登錄情況的統(tǒng)計報告，微軟不打算這樣做。

　　許多SQL Azure的愛好者和嘗鮮者就云版本的安全問題展開辯論，特別是SQL Azure的強制安全性功能，包括一個服務(wù)器端的防火墻，它可以讓DBA管理和控制從不同來源對特定IP地址或地址段的訪問連接。此外，基于云的產(chǎn)品還支持SQL身份驗證，同時保持一個基于SQL Server自定義加密協(xié)議的安全的數(shù)據(jù)庫連接。

　　Cherry自己總結(jié)出新的SQL Azure世界和大多數(shù)DBA使用的傳統(tǒng)SQL Server環(huán)境之間的安全性最佳實踐的小差異。“SQL Server本身是一個安全平臺，SQL Azure是另一種SQL Server實例。并沒有一大堆與平臺本身相關(guān)的安全性問題。”

　　通常情況下，問題都可以追溯到一個特定的用戶或開發(fā)人員，他們不知道如何正確地限制訪問權(quán)限。“我們談?wù)摰膯栴}與你在傳統(tǒng)數(shù)據(jù)庫上看到的問題是相同的，”Cherry說。

　　標準安全性指導

　　根據(jù)咨詢專家Herve Roggero的說法，這些遺留的空白或共同失誤不會破壞SQL Azure環(huán)境的安全性。例如，SQL Azure有一些有限制的審計工具，所以一些企業(yè)在SQL Server環(huán)境中使用這些工具來驗證受信任用戶。

　　“使用內(nèi)部部署的SQL Server數(shù)據(jù)庫，可以運行審計工具，如果發(fā)現(xiàn)不應(yīng)該發(fā)生的事情，就會發(fā)出警告;然而在云端卻沒有這樣的審計能力，”Roggero解釋說：“這是一個重大的問題，因為它影響遵從性計劃，遵從性計劃要求你擁有完整的數(shù)據(jù)審計，知道它何時被改變，是誰改變的。在SQL Azure中你不知道這些信息。”

　　圍繞SQL Azure安全性的另一個問題是：如果你認為云不是符合你環(huán)境的正確道路，那么如何輕松獲得數(shù)據(jù)。“如果你斷定這不是適合你的解決方案，你想改變供應(yīng)商嗎?”K. Brian Kelley說，他某銀行的數(shù)據(jù)庫管理員和架構(gòu)師。“現(xiàn)在有很多解決方案不是無縫的，而這顯然是一個問題。”

　　Cherry說，如果DBA遵循他們的標準安全性最佳實踐，他們就無須擔心大多數(shù)這些揮之不去的安全性憂慮。例如，SQL Azure防火墻默認是只訪問微軟內(nèi)部的Azure服務(wù)器。Cherry說用戶要小心地“盡可能少的在防火墻上戳幾個洞”以確保最佳安全性。

　　他們也應(yīng)該使用強密碼保護，并最小化應(yīng)用程序運行所需的權(quán)限。此外，DBA應(yīng)該強制執(zhí)行最起碼的安全準則，授予用戶履行其工作的最小權(quán)限。

　　“當可用性是非常重要的時候，請應(yīng)用標準的安全性實踐，”Roggero說：“數(shù)據(jù)庫帳戶使用強密碼是關(guān)鍵，因為數(shù)據(jù)庫架構(gòu)的使用有助于保護特定的表。在這些所有的可用之前添加安全層。”