分享方式：

安全存取資料

  • 文章

若要撰寫安全的 ADO.NET 程式碼，您必須了解基礎資料存放區或資料庫中可用的安全性機制。 您也需要考量您的應用程式所可能包含的其他功能或元件的安全性隱含。

驗證、授權和權限

在連接 Microsoft SQL Server 時，您也可以選擇使用「Windows 驗證」(也稱為「整合式安全性」)，它使用目前使用中的 Windows 使用者識別，而非傳遞使用者 ID 和密碼。 建議對內部部署資料庫使用 Windows 驗證，因為使用者認證並不會在連接字串中公開 (Expose)。 如果無法使用「Windows 驗證」連接到 SQL Server，則請考慮使用 SqlConnectionStringBuilder 在執行階段建立連接字串。

重要

Microsoft建議您使用可用的最安全驗證流程。 如果您要連接到 Azure SQL，Azure 資源受控識別是建議的驗證方法。

根據應用程式類型，需要以不同方式處理驗證所使用的認證。 例如，在 Windows Forms 應用程式中，系統會提示使用者提供驗證資訊，或可使用使用者的 Windows 認證。 不過，Web 應用程式通常使用應用程式本身 (而非使用者) 提供的認證來存取資料。

使用者一旦經過驗證，其動作範圍就會根據所授與的權限而定。 請務必遵守最小權限的原則，並僅授與絕對必要的權限。

如需詳細資訊，請參閱下列資源。

資源 描述
保護連接資訊 描述保護連接資訊的安全性最佳作法和技術，例如使用受保護的組態來加密連接字串。
連接字串產生器 說明如何在執行階段從使用者輸入建立連接字串。
SQL Server 資料庫引擎和 Azure SQL 資料庫的安全性 提供連結以協助您找到有關 SQL Server 資料庫引擎和 Azure SQL Database 中安全性和保護的資訊。

參數型命令和 SQL 插入

使用參數型命令 (Parameterized Command) 有助於防衛 SQL 插入式攻擊，在此類攻擊中，攻擊者會將命令「插入」至 SQL 陳述式而危及伺服器的安全。 參數型命令可確保自外部來源所接收的值僅會以值的形式傳遞，而不會當做 Transact-SQL 陳述式，藉此防衛 SQL 插入式攻擊。 因此，已插入值的 Transact-SQL 命令不會在資料來源執行， 而是將其做為參數值單獨評估。 除了安全性優點外，參數型命令也提供方便的方法，可您安排以 Transact-SQL 陳述式傳遞的值或傳遞到預存程序 (Stored Procedure) 的值。

如需有關使用參數型命令的詳細資訊，請參閱下列資源。

資源 描述
DataAdapter 參數 說明如何將參數搭配 DataAdapter 使用。
使用預存程序修改資料 說明如何指定參數並取得傳回值。
預存程序 (資料庫引擎) 描述使用預存程序的優點和不同類型的預存程序。

探查攻擊

攻擊者通常利用例外狀況的資訊，例如伺服器、資料庫或資料表名稱，來對系統設置攻擊。 由於例外狀況可能包含有關應用程式或資料來源的特定資訊，所以您可以只將必要的資訊公開給用戶端，使應用程式和資料來源有更嚴密的保護。

如需詳細資訊，請參閱下列資源。

資源 描述
在 .NET 中處理和擲回例外狀況 說明 try/catch/finally 結構化例外狀況處理 (Structured Exception Handling) 的基本形式。
例外狀況的最佳做法 說明處理例外狀況的最佳做法。

保護 Microsoft Access 和 Excel 資料來源

當安全性需求為最低或不存在時，可將 Microsoft Access 和 Microsoft Excel 當做 ADO.NET 應用程式的資料存放區。 其安全性功能可有效遏止侵擾，但僅止於阻擋狀況外使用者的干擾。 Access 和 Excel 的實體資料檔存在於檔案系統中，而且必須讓所有的使用者都可以存取。 這使得這些檔案易遭受因竊取或資料遺失而導致的攻擊，因為檔案可以輕易地複製或變更。 在需要強固安全性時，請使用 SQL Server 或其他伺服器架構的資料庫，因為其中的實體資料檔是無法從檔案系統讀取的。

企業服務

COM+ 本身包含根據 Windows 帳戶和處理序/執行緒模擬而定的安全性模型。 System.EnterpriseServices 命名空間提供包裝函式，這些包裝函式允許 .NET 應用程式透過 ServicedComponent 類別來整合 Managed 程式碼與 COM+ 安全性服務。

與非受控的程式碼交互操作

.NET Framework 可用於與 Unmanaged 程式碼互動，這包括 COM 元件、COM+ 服務、外部型別程式庫以及許多作業系統服務。 使用 Unmanaged 程式碼時需要越過 Managed 程式碼的安全性範疇。 您的程式碼以及它所呼叫的任何程式碼，都必須具備 Unmanaged 程式碼權限 (指定了 SecurityPermission 旗標的 UnmanagedCode)。 Unmanaged 程式碼可能會在應用程式中引入非預期的安全性漏洞； 因此，除非絕對必要，否則應該避免與 Unmanaged 程式碼互通。

如需詳細資訊，請參閱與 Unmanaged 程式碼互通。

另請參閱