構建安全的資料訪問 設計注意事項(二)

2022-07-13 23:54:21 字數 2548 閱讀 6379

在開始編寫**之前,需要在設計時考慮許多重要的問題。主要的注意事項包括:

•使用 windows 身份驗證。

•使用最小特權帳戶。

•使用儲存過程。

•保護所儲存的敏感資料。

•使用單獨的資料訪問程式集。

使用 windows 身份驗證

理想情況下,在設計中應該使用 windows 身份驗證,以增加安全性好處。使用 windows 身份驗證,您不必儲存具有嵌入憑據的資料庫連線字串,憑據不通過網路傳遞,而且您可以受益於安全帳戶和密碼管理策略。但是,您需要認真考慮在使用 windows 身份驗證時,將使用哪個帳戶連線到 sql server。

使用最小特權帳戶

您的應用程式應該使用在資料庫中具有有限許可權的最小特權帳戶。請確保對應用程式的資料庫登入進行了適當的授權和限制。

使用最小特權帳戶可以降低風險,並在您的帳戶發生洩漏或者注入了惡意**時限制潛在的損害。對於 sql 注入,該命令將在由應用程式登入定義的安全上下文中執行,並遵守該登入在資料庫中擁有的相關許可權。如果您使用特權過高的帳戶(例如,作為 sql serversysadmin角色的成員)進行連線,攻擊者能夠在伺服器上的任何資料庫中執行任意操作。這包括插入、更新和刪除資料;刪除表;執行作業系統命令。

要點不要使用sa帳戶或者 sql serversysadmindb_owner角色的任何成員帳戶連線到 sql server。

使用儲存過程

儲存過程提供效能、維護和安全性好處。應盡可能使用引數化儲存過程進行資料訪問。安全性好處包括:

•可以限制應用程式資料庫登入,以便它只具有執行指定儲存過程的許可權。沒有必要授予直接的**訪問許可權。這有助於降低由 sql 注入攻擊造成的風險。

•針對傳遞到儲存過程的所有輸入資料首席執行官度和型別檢查。同樣,不能將引數視為可執行**。這也會降低 sql 注入風險。

如果由於某種原因,您無法使用引數化儲存過程,但是您需要動態構造 sql 語句,請使用型別化引數和引數佔位符來構造這樣的語句,以確保檢查輸入資料的長度和型別。

保護所儲存的敏感資料

標識需要保證私密性和完整性的儲存資料。如果您只是為了驗證而將密碼儲存到資料庫中,請考慮使用單向雜湊。如果密碼表發生洩漏,則不能使用雜湊來獲取明文密碼。

如果您儲存使用者提供的敏感資料(如信用卡號),請使用強對稱加密演算法(如三重 des (3des))來加密資料。使用 win32 資料保護 api (dpapi) 加密 3des 金鑰,然後將已加密的金鑰儲存在具有受限 acl 的登錄檔項中,只有管理員和應用程式程序帳戶才能使用該登錄檔項。

為什麼不使用 dpapi?

儘管建議使用 dpapi 來加密連線字串和其他可在計算機出現故障時手動恢復和重新構造的機密(如帳戶憑據),但仍不太適合儲存信用卡號之類的資料。這是由於可恢復性問題(如果金鑰丟失,則無法恢復加密資料)和 web 場問題。相反,應該使用對稱加密演算法(如 3des)並使用 dpapi 加密金鑰。

下面概述了造成 dpapi 不太適合在資料庫中儲存敏感資料的主要問題:

•如果 dpapi 與計算機金鑰一起使用,而且您將cryptprotect_local_machine傳遞到cryptprotectdatacryptunprotectdata函式,則計算機帳戶會生成加密金鑰。這意味著 web 場中的每台伺服器都有乙個不同的金鑰,這會禁止一台伺服器訪問由另一台伺服器加密的資料。同樣,如果該 web 伺服器計算機被破壞,則金鑰會丟失,而且加密的資料無法從資料庫進行恢復。

•如果使用計算機金鑰方法,則該計算機上的任何使用者都可以對資料進行解密(除非您使用其他加密機制)。

•如果您將 dpapi 與使用者金鑰一起使用,而且您使用的是本地使用者帳戶,就會為每台 web 伺服器上的每個本地帳戶生成乙個不同的安全識別符號 (sid) 和乙個不同的金鑰,這會禁止一台伺服器訪問由另一台伺服器加密的資料。

•如果您將 dpapi 與使用者金鑰一起使用,而且您在 web 場中的計算機之間使用漫遊使用者配置檔案,則所有資料都將共享相同的加密/解密金鑰。但是,如果負責漫遊使用者配置檔案帳戶的域控制器被損害或被破壞,則無法重新建立具有相同 sid 的使用者帳戶,而且不能從資料庫中恢復加密的資料。

另外,對於漫遊使用者配置檔案,如果某人設法檢索該資料,則只要攻擊者能夠在特定的使用者帳戶下執行**,就可以在網路中的任何計算機上解密該資料。這會增加潛在攻擊的範圍,因此不建議這樣做。

使用單獨的資料訪問程式集

如果您可以進行選擇,請避免將資料訪問邏輯直接放在 asp.net 頁或**隱藏檔案中。如果將資料訪問邏輯放在乙個單獨的程式集中,並實現乙個與應用程式的業務和表示邏輯分開的邏輯資料訪問層,就會帶來安全性、重複使用和維護好處。

從安全的角度看,您可以:

對程式集使用強名稱以提供可防篡改功能。

使用沙盒技術來隔離資料訪問**,如果您的**需要支援部分信任呼叫方(例如,部分信任 web 應用程式),這一點十分重要。

使用那些按照**標識許可權需求向呼叫**授權的資料訪問方法和類。

對於深層防禦,請按照業務元件中的主體許可權需求來執行基於主體的授權,並按照**標識許可權需求來為呼叫資料訪問邏輯的**授權,如圖 14.2 所示。

圖 14.2

表示層、業務層和資料訪問層的分離

構建安全的資料訪問 異常管理(八)

異常條件可能會由配置錯誤 中的錯誤或惡意輸入引起。如果沒有正確的異常管理,這些條件可能會透露有關資料來源位置和特性的敏感資訊,以及有價值的連線詳細資訊。下面的建議適用於資料訪問 捕獲和記錄 ado.net 異常。確保資料庫連線總是處於斷開狀態。在 asp.net 應用程式中使用一般錯誤頁面。捕獲和記...

資料庫設計注意事項

關係型資料庫還能盛行多久?針對表的描述中,要重點說明設計這張表的原因 理由或目的,以及與其他表的關係,尤其是與業務邏輯緊密相關的表。指令碼中,每個字段新增必要的注釋,例如 comment on table sys users t is 系統使用者的相關資訊 comment on column sys...

資料庫設計注意事項

dbms資料庫管理系統 資料庫設計 1 有效儲存 2 高效訪問目的 1 減少資料冗餘 2 避免資料維護異常 3 節約儲存空間 4 高效的訪問資料庫設計過程 1 需求分析 分析需要儲存的資料是哪些,這些資料有哪些屬性,這些屬性各自的特點是什麼 2 邏輯設計 使用er圖對資料庫進行邏輯建模,3 物理設計...