保護 SQL Server 2005 Express Edition Server

保護 SQL Server 2005 Express Edition Server 作者:佚名 時間:2005-11-28 12:08 出處:互連網 責編:chinaitpower 摘要：探索 SQL Server Express 與其他 SQL Server 版本之間的差異，也就是它易于使用并易于保護的原因，并且探索如何将現有的 JET 應用程式遷移到更安全穩定的 SQL Server Express 什麼是 SQL Server Express？ SQL Server 2005 Express Edition 是 Microsoft SQL Server 的 Microsoft 桌面引擎 (MSDE) 版本的替代産品。它的體系結構完全重新設計，您可以像使用 Microsoft Access/JET 資料庫那樣安裝和使用它，但是不會出現與該方法相關聯的問題。SQL Server 2005 Express Edition 為滿足下列應用程式的需要而建構更好的解決方案，這經曆了很長的曆程： • 替代 JET 資料庫。也就是說，如果需要，可以由 IT 部門代替 DBMS，這一方面可以滿足 HIPA 安全性的需要，一方面可以使用所有 SQL Server 保護資料和參照安全性的功能，并且無需考慮使用者采取的手段。（HIPPA 或 HIPAA（通常簡略為 HIPA）指聯邦立法部門，該部門要求将可靠的安全性和通路保護用于存儲個人醫療衛生資訊的資料庫中。） • 無需更新到 SQL Server Standard Edition，DBMS 即可從單個使用者擴充到很多使用者，并且 DBMS 無需擔心在最需要調控器時，調控器的性能降低。 • 可以輕松地在小型網站上和用戶端/伺服器配置中工作的 DBMS。 • 當 Service Pack 可用時，可以輕松地安裝并就地更新的 DBMS 引擎。這意味着安裝例程可以輕松地內建到應用程式的部署腳本中。 • 通過簡單地指向安裝或傳遞到應用程式中的 DBMS 檔案，就可以對其進行通路的 DBMS。因為 SQL Server Express 旨在允許資料庫随時連接配接，它可以比以前更加簡單地使用“松散”的 SQL Server MDF 資料庫檔案并利用應用程式對它們進行部署。這使得部署獨立的 SQL Server Express 資料庫 .MDF 檔案非常簡單，就像利用 JET 資料庫完成那樣。 • 引用 SQL Server 的共享執行個體的标準方法。當安裝 SSE 時，預設情況下安裝為具有相同的執行個體名稱 SQLEXPRESS。這意味着如果假設應用程式安裝例程利用了該功能，無論應用程式的連接配接字元串是安裝在本地系統上還是安裝在區域網路上，它都可以更簡單地針對 SQL Server Express。我會在稍後談論執行個體問題。 我的新書，Hitchhiker's Guide to Visual Studio and SQL Server 2005 (Addison Wesley)，将會用一整節來讨論 SQL Server 2005 Express Edition，但對于本文，我将重點限制在使用 SQL Server 2005 Express Edition Beta 2 的托管安全性上。随後我将會讨論下列内容： • 什麼是“安全”的系統？對于小型系統而言，安全性意味着什麼呢？ • MSDE 開發人員面臨着什麼問題？ • SQL Server Express 如何解決這些問題？ • 應用程式如何獲得對 SQL Server Express 資料庫的通路？ • 如何保護 SQL Server Express 資料庫？ 注 在撰寫本文時，SQL Server 2005 Express Beta 2 不應該用于産品系統中，不應該公開在 Web 上或在 EULA 限制外使用。 什麼是“安全”的系統？在我們深入讨論 SQL Server 2005 Express Edition 的技術優點以及如何配置其安全功能之前，我認為有必要定義安全性的實際含義。當然，對于小型企業或部門系統來說，當資料伺服器受到安全威脅或其資料丢失或損壞時，該公司與大型公司一樣容易面臨失敗。SQL Server Express 可以駐留在 Web 伺服器上，為 ASP 應用程式提供 SQL Server 服務。是以，正常運作時間、可靠性和安全性也意味着對 Web 伺服器應用程式公開資訊的能力，但同時還不易受到來自 Web 的攻擊。對于将編寫代碼和建構應用程式作為兼職的“經驗不足的開發人員”來說，SQL Server Express 也是非常理想的。這些醫生、律師、接待員和計程車司機都需要一個用于存儲和檢索資料的簡單、安全、穩定的方式，而不必考慮在背景正在為他們所做的操作。 安全性還包括應用程式設計程式和開發人員要防止資料丢失而采取的這些步驟，無論丢失是由于意外、疏漏或是惡意攻擊所緻。安全性意味着将那些不應該通路資料的人員拒之門外，并保護實體檔案和系統本身。它意味着制作備份并能夠無縫地執行還原。利用 SQL Server Express 系統，尤其具有挑戰性，因為與通常不同，沒有專職系統管理者或 IT 部門介入并執行周期性的備份，或者當系統發生故障時從各個部分中進行還原整個系統。具有安全的系統意味着當發生問題時保持您的工作（并且可能會有提升），然後可以快速、安靜、高效地恢複應用程式。我将會指出很多事項，您可以完成它們使應用程式更持久、更不容易受到攻擊并且更易于維護。 問題是什麼？相當長時間以來，我一直都在贊美 SQL Server 的 MSDE 版本。這是因為我确信對于需要“少量使用者”資料存儲區的應用程式，或應用程式不需要對遠端 DBMS 引擎進行通路的情況下，MSDE 是非常好的解決方案。盡管 MSDE 已經廣泛地被大量關鍵業務采用，它們通常必須依賴自己來處理很多問題 — 實作非标準解決方案，該解決方案有時與解決相同或不同問題的其他公司的嘗試相沖突。這些沖突包括： 部署：如果将 SQL Server 與應用程式一起安裝将會怎樣？下面就是對相關問題的闡述。例如，如果 SQL Server 已經安裝，又該如何呢？如果執行個體名與其他現有執行個體沖突，又該如何呢？應用程式應該共享一個現有的 SQL Server 執行個體還是建立一個獨特的執行個體呢？當解除安裝安裝有共享 SQL Server 執行個體的應用程式行時會發生什麼情況？它還會解除安裝 SQL Server 執行個體嗎？如果會，那麼該執行個體宿主的其他資料庫會發生什麼情況呢？ 安全性：如果選擇共享一個 SQL Server 執行個體，應該為 SA 使用什麼密碼呢？如何設定使用者帳戶？應用程式是否應該隻是使用由域控制器管理的內建安全性呢？如果沒有 Active Directory，又該如何呢？如何将資料庫安裝在目标 MSDE 伺服器上？安裝後，資料庫是否對伺服器上的其他應用程式可見呢？應用程式如何隐藏專用資料呢？ 性能： MSDE 使用限制伺服器上并發操作數量的調控器。如果單個使用者應用程式需要同時執行幾個操作，但是調控器不發揮作用并使其速度下降，又該如何呢？坦白地說，我不确認這個問題是十分普遍的。我曾經聽到非常少的人抱怨調控器終止，并且使他們的應用程式運作得非常慢。的确，我曾聽說應用程式運作得不是特别快，但是這（通常）是由于野蠻強制查詢或“置疑的”資料庫實作導緻的結果。 可伸縮性： MSDE 資料庫限制在 2GB。如果您需要比這更多的資料，又該如何呢？這是否意味着您必須更新目标系統以使用 SQL Server Standard Edition，而這可能比期望使用它的系統花費更多？另外，我所聽到的最多的抱怨就是人們存儲二進制大對象 (BLOB)（例如資料庫中的文檔或圖檔）時涉及的問題。一旦它們将 BLOB 替換為一個到 BLOB 檔案的路徑，它們的資料庫就縮小到非常合理的大小了。 工具： SQL Server 的 MSDE 版本是“部署”配置。同樣，它并不包括管理伺服器或它所管理的資料庫所需要的任何工具。我通常會推薦開發人員購買 49 美元的 (SRP) Developer Edition，它包括用于管理其 MSDE 資料庫的整套工具。但是，由于許可限制，這些工具無法利用應用程式進行部署。這意味着開發人員必須建構他們自己的用戶端工具或簡單地将需要的功能建構到他們已部署的應用程式中。 管理： 無論它是如何完成的，應用程式必須要承擔很多管理性責任。對于沒有“SA”（系統管理者）值守的 SQL Server Express 系統而言，這一點尤為重要。這些管理責任包括管理登入帳戶、權限、備份、還原和日志維護。最終使用者通常不具有執行這些操作的能力并且不應該被信任來執行這些操作 — 這取決于應用程式。因為 JET 資料庫需要周期性的壓縮或修複，MSDE（和任意 SQL Server 資料庫）需要周期性地備份（和轉儲）日志和資料庫。當資料庫沒有進行集中管理時（集中管理可以更簡單地管理管理性和維護任務），這個問題就變得相當重要。同樣，這取決于應用程式。 Service Pack： 由于 MSDE 通常嵌入到應用程式中，使用者可能不知道他們已經安裝了一個 SQL Server 執行個體。同樣，他們也沒有注意到他們可能需要應用 SQL Server Service Pack 來保護他們的資料和系統以免受攻擊，即使他們在 5 點鐘新聞時看到它時，還在正常運轉。為了防止由蠕蟲和其他攻擊病毒引起的某些問題，MSDE SP3(a) 禁用了網絡連接配接，是以應用程式無法通過 Intranet（或 Internet）連接配接到伺服器。問題在于 Service Pack 未能應用到很多系統中，因為使用者不知道它是必要的，或者不知道如何應用修補程式。将 SQL Server 更新應用到 MSDE 安裝這個問題仍然難以解決，因為 Microsoft 更新不是始終可以與用于部署 MSDE 應用程式和資料庫的自定義安裝腳本一起使用的。 SQL Server Express 如何解決這些問題？近年來，世界範圍的開發人員、架構師和 IT 經理一直對上述問題進行着讨論。盡管沒有對所有這些問題的解決方案，但是通過一些相當基本的改動，SQL Server Express 已經解決了其中的很多問題。在了解差異之前，知道什麼内容沒有變化非常重要。SQL Server 2005 Express Edition 仍然是免費的（具有慣例的 licensing and use restrictions），它仍然支援訂閱者複制以及實際上與 MSDE 相同的所有功能。新的 SQL Server Express 版本無法宿主報告服務，但它可以作為宿主在 SQL Server 2000 Standard Edition 上的伺服器的資料源。（有關 SQL Server 報告服務的詳細資訊，請參閱 Boost.net 網站。）預設情況下，安裝程式仍然禁用将 SQL Server Express 執行個體公開到網絡的能力（首次在 MSDE SP3 中實作）。讓我們更仔細地考察一下 SQL Server Express 是如何解決每個問題的。 部署 SQL Server Express 設計為可以通過 Web 下載下傳，并可以像任何其他系統軟體那樣安裝在使用者系統上。（這假設系統管理者安裝了 SQL Server Express。）您可以使用互動式安裝程式（我将在稍後進行說明），或運作指令行安裝可執行檔案。利用“安靜”模式，使用者根本不需看到任何 SQL Server Express 安裝對話框。 當安裝 SQL Server Express 時，預設情況下安裝程式會嘗試建立一個公用的 SQLEXPRESS 執行個體。如果它已經準備就緒，将提示您選擇放棄安裝或是選擇另一個執行個體名。此處的思想在于讓使用 SQL Server Express 的應用程式共享一個公用執行個體，而不是建立它們自己的執行個體。這使得應用程式配置更加簡單，同時還可以降低使用者系統上的記憶體和磁盤占用空間。 如果解除安裝應用程式，最好還是解除安裝您所安裝的任意唯一的 SQL Server Express 執行個體。但是，Microsoft 建議保留所有就緒的 SQLEXPRESS 執行個體，除非您确認系統沒有任何其他使用該執行個體的相關應用程式。确定這一點的一種方法是搜尋其他應用程式可能連接配接或建立的其他資料庫的 Master 資料庫。 安全性預設情況下，SQL Server Express 配置為保護您的資料。在安裝時，您會有機會根據要求進一步加強安全性或放松安全性。您必須首先做出的決定就是選擇安裝實用工具配置 SQL Server Express 執行個體的方式。執行個體就是程式的一個副本。從 SQL Server 2000 版本開始，SQL Server 允許您安裝伺服器的幾個獨立的執行個體。每個執行個體都被視為獨立的實體：每個執行個體具有其自己的 Master 資料庫、其自己的安全性配置以及其自己的磁盤和記憶體中的位置。安裝 SQL Server Express 後，每個應用程式（或您）必須決定它是否與使用該伺服器的共享執行個體的其他應用程式共存，或者它是否要求其自己的獨立執行個體。有幾個與每個配置相關聯的安全性問題，我将在下面進行闡述。請注意，SQL Server Express 允許您安裝多達 15 個執行個體，但是我希望人們不要安裝多個執行個體，除非在非常特殊的情況下。 安裝公用執行個體預設情況下，SQL Server Express 假設您要建立（或使用）一個名為“SQLEXPRESS”的公用執行個體。還可以命名一個“公用”執行個體，但是這假設您所安裝的所有程式都可以分辯出這個獨特的名稱。如果保留預設名稱 (SQLEXPRESS)，其他應用程式可以自動共享這個公用執行個體。利用這種方法，所有資料庫都可以由一個單個的、共享 Master 資料庫管理，并且有一個永遠不需要顯示的 SA 密碼。當使用公用執行個體時，您有可能看到其他安裝的資料庫，而其他應用程式也可能會看到您的資料庫 — 除非您確定應用了适當的權限。一般而言，對于家庭、個人或小型辦公室實作，您通常不必擔心一個應用程式會擾亂另一個資料庫中的資料。如果您安裝一個單獨的公用執行個體，那麼隻有一組 SQL Server DLL、緩存和其他駐留記憶體的結構會加載到記憶體中。這意味着隻有一個 SQL Server 執行個體占用 CPU 資源。 安裝獨立的執行個體在安裝過程中，如果您将執行個體名設定為自己的值，那麼安裝程式會建立一個完全獨立的 SQL Server Express 版本。該執行個體具有其自己的 Master 資料庫、其自己的檔案、DLL、記憶體占有空間以及其自己的 SA 密碼。除了可能已安裝的任意其他執行個體外，每個獨立的執行個體都會啟動占用 CPU 周期的單獨的 SQL Server 服務（程式）。盡管該方法在某種意義上增加了安全性，隻有那些被授予對該執行個體通路權限的程式才能看到它所管理的資料庫，但是實作和維護卻增加了很多成本。這是因為每個執行個體都要複制 DLL、緩存和其他記憶體中的結構。 安裝預設執行個體另一種方法就是在安裝過程中删除執行個體名。在這種情況下，SQL Server Express 作為預設執行個體安裝，假設沒有已安裝的預設執行個體。在這種方式中，隻可以安裝一個伺服器執行個體。同樣，如果這是安裝到系統上的唯一的執行個體，那麼在其他配置之間差異就會非常小，除非當它連接配接 SQL Server Express 時，我将在稍後對此進行讨論。 選擇系統管理者的密碼 SA 密碼是解開整個資料庫的密鑰。系統管理者獲準對資料庫或資料庫中的資訊進行任何操作。SA 可以添加、更改或删除資料庫，所有操作都可以在任何人不知道所做更改的情況下進行。正确設定這個密碼并對其進行保護是至關重要的。 當您使用公用執行個體安裝 SQL Server Express 時，隻有一個 SA 密碼需要關注。由于隻有在您選擇使用 Windows 身份驗證進行安裝時，SA 帳戶才可以通路，是以 SA 密碼永遠不需要顯示。在任何情況下，當安裝 SQL Server Express 時，都要求您提供 SA 密碼，但是在已釋出的版本中，可以設定為随機（隐藏）的值。 Microsoft 建議您配置 SQL Server Express 執行個體以使用 Windows 內建安全性身份驗證。這意味着計算機和 Windows 域系統管理者帳戶都被授予對 SQL Server Express 執行個體的完全 SA 通路權限。當然，您需要成為計算機或域管理者才能執行維護、安裝資料庫以及執行像更改資料庫表值這樣的簡單操作。這并不意味着使用 SQL Server Express 的每個人都應該成為管理者。它真正的意義在于，作為安裝制度的組成部分，您需要建立“使用者”或應用程式登入，并在應用程式需要的表格、視圖、函數以及存儲過程上設定适當的權限。我将會在稍後對此進行更詳細的讨論。 性能 SQL Server Express 已經摒棄了“調控器”的概念。坦白地講，我以前幾乎沒有看到調控器降低任何 MSDE 系統的情況，但是通過放棄調控器，Microsoft 消除了有關 SQL Server 引擎可伸縮性的混淆。SQL Server Express 有很多方法來限制可伸縮性。正如在測試版中所配置的那樣，SQL Server Express 隻能處理緩沖池中 1GB 的系統 RAM。這限制了 RAM 緩存中資料頁面和過程的數量。任何 SQL Server 專業人士都可以告訴您改進性能的最簡單方法就是向緩存中增加記憶體。将可見 RAM 限制在 1GB 意味着在您向 SQL Server Express 執行個體中增加負載時，您将（最終）耗盡性能。這是否意味着 SQL Server Express 可以支援 1000 個使用者呢？當然，如果将負載放在 SQL Server Express 執行個體上并不會那麼完美。在相同的情況下，10 個使用者就可以将 SQL Server Express 陷入困境，尤其是如果應用程式編寫得并不是非常有效時。 SQL Server Express 也限制到一個單個的處理器，而不可以在附加處理器（最多兩個）上運作線程（如果系統支援）。這種限制也壓縮了您期望從 SQL Server Express 獲得的性能上限。 當使用 SQL Server Express 的應用程式結束時，SQL Server 并不會關閉。在 SQL Server Express 版本中并沒有自動關閉選項。是以，即使在您的應用程式結束後，SQL Server 引擎也會保留在記憶體中，并繼續占用系統 RAM 和 CPU 資源。可以編寫 SQL 管理對象 (SMO) 例程來關閉 SQL Server Express 執行個體，但隻有在您确認該執行個體沒有被其他應用程式共享時，才可以完成該操作。 可伸縮性盡管 MSDE 資料庫限制在 2GB，SQL Server Express 資料庫檔案卻限制在 4GB。這意味着可以比以前多存儲一倍的資料。坦白地講，這使我很困惑。我曾經在大型機上使用過大型的公司資料庫，它在單個 40MB 磁盤包上非常适合。我猜想人們喜歡使用資料庫來存儲其寵物的大量文檔和圖檔。對于 MSDE 而言，日志檔案大小并不受限制 — 至少表面上看是這樣。您仍然需要周期性地備份或截斷日志，我将在稍後進行讨論。 工具 Microsoft 同時還更改了其對工具的通路方法。即使您不将新的 GUI 安裝程式計算在内，當您下載下傳 SQL Server Express Beta 2 時，新的 OSQL 版本、SQL 計算機管理器（MMC 管理單元）以及 SQLCMD 指令行工具都包括在其中，以協助管理 SQL Server Express 執行個體。此外，Microsoft 計劃設計一個新的 GUI 工具（暫時命名為 SQL Express Manager），以執行 SQL Server 資料庫的初始配置和周期性維護。這個工具很快可用于獨立下載下傳，基本上可以說，它是不同于 SQL 查詢分析器的工具，可以執行使用者帳戶設定和維護以及協助編寫、測試和調試 SQL 查詢。您不能使用其他任何工具連接配接到 SQL Server Express，包括 Management Studio 或 SQL 企業管理器。但是，我希望在它釋出前，目前的任何工具都可以通路 SQL Server Express。 管理要管理 MSDE，您隻須對 SQL Server Express 進行操作，這與對 SQL Server 的其他版本所做操作相同。我希望看到一個可以周期性地轉儲資料庫和日志然後截斷日志的自動日志備份腳本。或許，這就是企業第三方需要建立的腳本。到那時，我建議開發人員将這些管理任務建構到他們的應用程式中，然後使用 SMO 來執行這些需要的維護功能，并且使用 Windows 計劃程式來進行協助。 Service Pack SQL Server Express 隻能使用 Windows Installer (MSI) 安裝軟體封包件進行安裝。與 MSDE 不同，您将無法建立自定義的 MSM 安裝腳本。在其他方面中，它與 MSDE 相同，是以您仍然需要準備通過傳統的 Service Pack 方式來更新 SQL Server 引擎。在 Microsoft 工作的人都敏銳地意識到與此相關的問題，并且仍然在規劃着更好的政策。 安裝 SQL Server Express Edition 與 MSDE 不同，MSDE 不支援任何形式的 GUI 安裝實用工具，而 SQL Server Express 允許指令行安裝和 GUI 版本。對于使用标準版版本或更高版本的開發人員來說，這個安裝版本是非常熟悉的。但是，在該過程的早期，SQL Server Express GUI 安裝程式出現對話框（如圖 1 所示），詢問使用者是否要設定 Advanced Configuration 選項。預設情況下，安裝程式會配置正在進行安裝的 SQL Server Express 執行個體來使用內建安全性，同時禁用對 TCP 端口和外部協定的所有通路。這意味着您将無法從其他系統或使用 SQL Server 憑據來通路 SQL Server Express 執行個體，除非更改進階配置選項。 圖 1. 捕獲 SQL Server Express GUI 安裝實用工具的注冊資訊 選擇安全性模式 SQL Server Express 安裝實用工具允許您在身份驗證模式對話框（如圖 2 所示）中設定伺服器所使用的安全性類型。正如我将在稍後讨論的那樣，預設模式是 Windows Authentication，它會根據域 Active Directory 資料庫來驗證使用者憑據。在了解切換到 SQL Server Mixed Mode 安全性的安全意義之前，最好保留為預設模式。例如，混合模式 (SQL Server) 安全性強制開發人員指出隐藏由其應用程式所使用的 SQL Server 憑據的方法，以防止肆無忌憚的黑客的使用。盡管如此，最好還是堅持使用預設設定，除非您的設計使該配置無法使用。 興趣使然 黑客從何處來？在倫敦舉行的 Diligence Information Security 研讨會上，一項調查表明大多數“黑客”（那些試圖獲得對受保護的資料進行未經授權通路的人）是公司防火牆内部的個人 — 并且大多數（到目前為止）都是公司的正式員工。 不管您選擇的安全性類型如何，安裝實用工具都将要求您提供 SA 密碼。盡管它要求您需要提供“強”密碼，這實際上是域密碼強度設定的功能。我提倡您使用格式規範的強密碼，但是如果使用 Windows 身份驗證模式，這一點就并不那麼重要了。實用工具不會讓您将其保留為空。 圖 2. 設定由 SQL Server Express 執行個體使用的身份驗證模式 安裝 SQL Server 計算機管理器擴充與 SQL Server Express 安裝的一個也是唯一一個工具就是 SQL Server 計算機管理器 MMC 管理單元。該工具可用于管理 SQL Server 服務并且使得可以在網絡上檢視 SQL Server。要安裝該元件，請在安裝 SQL Server Express 執行個體過程中使用 Features Selection 對話框（如圖 3 所示）選擇它即可。 圖 3. 安裝 SQL Server 計算機管理器擴充。 在安裝 SQL Server Express 執行個體後，通過導航到“Protocols for SQLEXPRESS”節點，右鍵單擊然後選擇 Enable（如圖 4 所示），SQL Server 計算機管理器可以啟用 TCP 端口或适當的網絡協定。在此例中，我啟用了 Named Pipes (Np) 協定。您還必須啟動 SQL Brower 服務來提供伺服器名稱解析。 注 請注意，“Slammer”蠕蟲利用這樣一個事實，大多數 SQL 伺服器在 UDP 端口 1434 公開。這意味着 SQL Server Express 不會受到這種類型的攻擊，除非您啟用 SQL Browser 服務。 圖 4. 使用計算機管理器 MMC 管理單元元件來啟用網絡可視性 在安裝完成後，安裝檔案（可以包含純文字或弱加密憑據以及其他敏感配置資訊 — 基本上是指伺服器的密鑰）應該被删除或進行保護。 連接配接到 SQL Server Express（獲得對 SQL Server Express 的通路） Microsoft 和我希望您使用托管代碼來打破對 COM 和 OLE DB 提供程式的依賴性 — 即，SQL Server 提供程式。SqlClient .NET 資料提供程式仍然是最好的選擇。如果必須使用 MDAC 和 OLE DB 從基于 COM 的應用程式連接配接到 SQL Server Express，您可以這麼做，但是您無法通過共享的記憶體提供程式進行連接配接，并且您将需要確定啟動了 SQL Browser 服務。 由于預設安全性設定是內建安全性，您将需要在連接配接字元串中使用 Integrated Security=SSPI，除非更改為混合模式安全性。您仍然需要在連接配接字元串中指定初始目錄或 Database，以指向 SQL 所針對的特定資料庫。當使用 SQL 分析器來監視代碼所執行的操作時，我還建議您使用 Application Name 連接配接字元串參數來唯一地辨別您的操作。 使用 AttachDBFilename 進行連接配接 SQL Server 團隊所推薦的新方法是将關鍵字 AttachDBFilename 添加到連接配接字元串。如果一直用于 Web 應用程式，對于典型 SQL Server 用戶端/伺服器前端應用程式而言，這是不常用而且是極少使用的方法。對于說明 SQL Sever 執行個體的任意連接配接字元串，您必須按名稱（或 IP 位址）指向伺服器并提供一個執行個體名。此外，當使用 AttachDBFilename 關鍵字指向連接配接字元串中的檔案名時，ADO.NET（或 ADO）會通知目标 SQL Server 執行個體，您希望将引用的檔案“附加”到伺服器 — 這樣，在打開連接配接的過程中會将該資料庫注冊在 SQL Server Master 資料庫中。 在附加資料庫後，當您引用資料庫時，從此時起，該伺服器通路引用的檔案 (.MDF) 及其附帶日志檔案 (.LDF)。因為此處有一個 catch 語句，請務必小心。您必須 在連接配接字元串中指定 Database 關鍵字。如果不指定，該伺服器則無法确定這個新附加的資料庫。代碼清單 1 顯示了被配置為附加并打開一個 .MDF 檔案的 ADO.NET Sqlclient.SqlConnection 對象的示例。 代碼清單 1. 使用 AttachDBFilename 關鍵字連接配接到 SQL Server .MDF 檔案。 Try cn = New SqlConnection("Data Source=./SQLExpress;" _ & "Integrated Security=True;Database=Biblio;" _ & "Timeout=60;" _ & "Application Name=SQLExpress Test;" _ & "AttachDBFilename=" & strFn) da = New SqlDataAdapter("SELECT AU_ID, Author, Year_Born from authors", cn) ds = New DataSet da.Fill(ds) DataGridView1.DataSource = ds.Tables(0) Catch ex As Exception MsgBox(ex.ToString) End Try 提示 将新資料庫附加到 Master 的過程比簡單地打開它要花費更多的時間。確定設定連接配接字元串 Timeout 關鍵字，以考慮該增加的時間。 管理附加的 .MDF 資料庫檔案盡管打開連接配接的過程會附加一個資料庫，但是當應用程式關閉該連接配接時，資料庫并沒有分離。一旦附加，它會永久性地安裝在 SQL Server 執行個體中。這意味着在應用程式結束後，資料庫本身對任何應用程式都是可視的，且帶有足夠的權限。它還表示您需要負責在帶有其他應用程式檔案的相同目錄中維護資料庫檔案。由于在 SQL Server 運作時，檔案受到 Windows 的保護，是以在沒有首先從資料庫分離時，它不應該被“更新的”版本所覆寫。當然，分離并不困難。您可以從 SQLCMD 中使用以下指令，或使用 SQL Server 2005 GUI 管理工具。另一種方法是使用當使用該資料庫的所有應用程式結束時自動關閉資料庫檔案的 AutoClose 選項。 EXEC sp_detach_db 'MyDb' GO 請記住要将資料庫檔案儲存在本地硬碟上，而不是儲存在共享的網絡伺服器上。強制 SQL Server 執行通過線纜的實體 I/O（即使它支援該操作）是非常危險的，并且它确實會降低您的性能。 與 JET 資料庫不同，備份 SQL Server 資料庫檔案（可能有若幹個檔案）非常簡單，但是備份過程還涉及了通過 OSQL（其中一個工具）或 SMO 向 SQL Server 發送 T-SQL 指令。資料庫可以在任何時間進行備份，可以帶有任何數量的登入（和活動）使用者。 直接連接配接到名為 SQL Server Express 的資料庫連接配接到名為 SQL Server Express 執行個體（或任意 SQL Server 執行個體）上的命名資料庫的更典型方法是，簡單地在執行個體名後寫出計算機名，如代碼清單 2 所示。這種方法假設作為目标的 Database 已經注冊了 SQL Server Master 資料庫。 代碼清單 2. 使用對已注冊的 SQL Server 資料庫的“直接”通路。 cn = New SqlConnection("Data Source=./SQLExpress;" _ & "Integrated Security=True;Database=Biblio;" _ & "Timeout=60;" _ & "Application Name=SQLExpress Test;" _ & "AttachDBFilename=" & strFn) 注 SQL Server Express 仍然支援連接配接字元串的“(local)”或“.”表示法來指代 SQL Server 的“預設”執行個體，但前提是隻有您按照我前面所述安裝了“預設”執行個體。我并不建議使用這種方法，因為 SQL Server Express 伺服器可能不是伺服器上的原始“預設”執行個體。 使用備用的執行個體名您不必使用預設的“SQLEXPRESS”執行個體名來安裝 SQL Server Express。我可以想象出幾種情況來說明使用預設執行個體名并不是很好的解決方案。在這種情況下，您需要使用安裝過程中的“進階配置”選項，以選擇另一個執行個體名并在連接配接字元串中使用這個執行個體名。這種方法的問題在于，如果應用程式安裝實用工具不知道安裝在目标伺服器上的資料庫名稱，您的名稱可能會與現有名稱發生沖突 — 正像在使用者系統上安裝 SQL Server 的某個其他應用程式可能會與您選擇的名稱發生沖突一樣。這就解釋了為什麼 SQLEXPRESS 的公用執行個體名是如此重要的一項創新。 使用别名從應用程式連接配接到“公用”伺服器名的另一種方法是使用别名。也就是說，您可以使用 SQL 計算機管理器來為 SQL Server 執行個體指定一個别名（如圖 5 所示）。在此例中，我建立了别名“George”，我可以将其用于我的連接配接字元串中。如果基本伺服器發生變化（例如，當我從測試伺服器更改為生産伺服器時），我隻要更改别名，該應用程式就會重定向到正确的伺服器。 圖 5. 使用計算機管理實用工具來建立執行個體别名。 利用 Windows 身份驗證模式管理內建安全性當您的連接配接字元串包含關鍵字 Integrated Security=SSPI 時，ADO.NET（或您所使用的資料通路接口）則使用 Windows 身份驗證模式。在幕後，這種模式使用 NTLM (NT LAN Man) Windows NT 質詢/響應身份驗證協定來驗證使用加密的帳戶憑據，以便保護傳輸過程中的密碼以防止“刺探者”以離線狀态攫取您的憑據。每次打開（或重新打開）連接配接時，使用者憑據會根據域控制器 (Active Directory) 資料庫重新進行驗證。Microsoft 建議對大多數應用程式使用 Windows 身份驗證模式。 注有關安全性支援提供程式 (SSP) 軟體包（如 NTLM 和 Kerberos）的詳細資訊，請參閱 Platform SDK 中的 SSP Packages Provided by Microsoft。 當然，我所編寫的用于驗證這段代碼的測試應用程式可以正常工作（該代碼顯示在代碼清單 1 中）。因為我是以管理者身份登入的，是以我的 Windows 帳戶被授予了 SQL Server 上的系統管理者權限。這就是當使用 SQL Server Express 時，為什麼不需要使用 SA 帳戶或者不需要知道 SA 密碼的原因所在。然而，我的确希望最終使用者不被授予管理者帳戶。當任何人登入到 Windows 域時，域管理者會确定授予他們的權限。該資訊存儲在 Active Directory 中。這些權限不會傳遞到 SQL Server，除非您特别地授予這些權限。這意味着（預設情況下）不會 為非管理者授予到伺服器或其内容的權限，并且您将需要設定使用者、組和角色以管理資料庫及其内容。執行該操作的機制在一段時間以來都沒有改變，在 SQL Server Books Online 中有對它們的詳細說明。有關 SQL Server 安全性最佳操作的詳細資訊，請通路 TechNet。 從基本上講，您需要建立并配置四層安全性。 1. Windows 域帳戶：系統管理者需要建立域帳戶，包括登入名和（強）密碼 — 使用者“憑據”。該帳戶（預設情況下）是“Domain Users”組的成員。管理者可以建立其他組并根據需要将使用者配置設定到這些組。我通常建立使用者的“類”，它按照使用者在辦公室中被配置設定的工作角色的類型對其進行分類。例如，我将建立“Accounting Admin1”和“Accounting Admin Lead”組，并将特定的 Windows 域帳戶添加到這些組。可以配置設定給單個 Windows 使用者多個角色。 2. 工作站和使用者的實體安全性。如果在使用者離開時，工作站保留為登入狀态，或者使用者允許其他人使用他們的 Windows 帳戶憑據，那麼您的安全性已經被洞穿。這一層通常被忽略。這就解釋了為什麼當使用者沒有實際出現時 Microsoft 使用密鑰通路系統來防止對系統的通路。 3. SQL Server 登入：這是在 SQL Server 上建立的帳戶，用于屏蔽連接配接到 SQL Server 的嘗試。您向該清單中添加的每個帳戶，都會減弱保護資料的伺服器能力，因為它允許額外的 Windows 使用者獲得對該伺服器的通路。當使用內建安全性（我們建議這麼做）時，您仍然需要在 SQL Server 上建立一個登入帳戶，以允許特定使用者或 Windows 域組（例如 Domain Users）對目标資料庫進行通路。授予每個登入帳戶對一個或多個資料庫的通路權限，并且如果初始目錄 (Database) 關鍵字沒有在連接配接字元串中使用，則配置設定一個所引用的預設資料庫。 4. 資料庫使用者：保護的最後一層是在資料庫本身中進行管理的。在這種情況下，您需要建立一個或多個資料庫使用者，為這些使用者授予對特定表格、視圖、函數和存儲過程的通路權限。如果需要，您甚至可以授予對特定列的通路權限。 在任何 SQL Server 資料庫上管理安全性帳戶的一個方法就是使用 SQLCMD。但是，除非您是資料庫管理者 (DBA) 并且具有 T-SQL 的豐富經驗，否則這可能有一點令人畏縮。幸運的是，您可以使用 SQL Server 2005 Management Studio（與 SQL 企業管理器等價）來建立資料庫使用者、組或角色。該工具沒有包括在 SQL Server Express 中，是以您需要使用 Microsoft 提供的标準版或開發人員版的工具或使用第三方的一個工具。在建立這些角色後，您可以使用 SQL 工具将這些 T-SQL 指令導出到一個腳本檔案。 使用混合模式的安全性混合模式身份驗證是使用 Windows 內建安全性的一個備選方法。在這種情況下，連接配接字元串 UID 和 PWD 關鍵字會根據 SQL Server 登入名和密碼進行驗證。由于這種技術繞過了 Windows 身份驗證，它被認為是不太安全的。要使用這種安全性模式（并忽略我們的建議），您需要在安裝過程中啟用這種混合模式安全性。為此，當使用安裝批處理檔案時，您可以将 SECURITYMODE 指令參數設定為“SQL”。該選項還可用于 SQL Server Express 互動式安裝程式和 SQL Server Express Manager (XM)，其預覽版本應該很快就可用了。 SQL Server 安全性正常指南無論它是每小時百萬次點選量的企業伺服器還是每千年百萬次點選量的小型辦公系統，在任意系統上違反安全，都可能意味着公司的崩潰 — 或者丢掉您的工作。由于 SQL Server Express 系統假設應用程式扮演很多安全性角色，需要對其進行準備才能管理 SQL Server 登入、執行周期性維護（例如資料和日志備份）、将備份存儲移動到系統外（最好是現場外）以及适于資料庫使用的其他維護任務。應用程式還需要采取措施來監視伺服器日志的運作狀況，并且在遇到問題時對其進報告。 不熟悉 SQL Server 的開發人員通常會忽略一個維護安全性的更基本的方法，例如 SQL Server 具有将對象保護到列的能力。在大多數關鍵的辦公系統中，DBA（如果有）會直接将通路權限限制到基表。此後，DBA 為重點通路資料庫的人建立特定的使用者和角色帳戶，根據專用視圖、存儲過程和函數啟用适當的權限。這樣，如果使用者憑據被盜，可以通路資料的唯一方法就是通過這些非常簡單地限制的機制。 小結本文介紹了 SQL Server 2005 的新改進的版本，也稱為 Express Edition。我讨論了使 SQL Server Express 易于使用并易于保護的差異，并讨論了幾個安全性問題，涉及了保護資料、保護伺服器以及保護實體系統。我希望這篇概述能夠促使您将現有的 JET 應用程式遷移到更安全穩定的 SQL Server 2005 Express Edition 中。