為什麼 BULK INSERT 被認為是危險的?
我想了解為什麼一般的網路安全團隊(我處理過的不止一個組織)堅決反對授予
BULK INSERT
應用程序和數據庫程序員(例如 TSQL)權限?我無法相信“填補磁碟濫用”的藉口,除非我遺漏了什麼,因為最終結果與執行以下操作的應用程序沒有什麼不同:for (long i = 0; i < LONG_MAX; ++i) executeSQL("INSERT INTO table VALUES(...)");
並且
INSERT
是一個普通的 DML 命令,任何具有基本寫入權限的人都可以執行。對於應用程序的好處,
BULK INSERT
它更高效、更快,並且使程序員無需在 SQL 之外解析文件。編輯:我最初在資訊安全網站上問這個問題是有原因的 - 不是 DBA 反對使用 BULK INSERT,而是“資訊保證”(簡稱 IA - 網路安全人員)迫使這個問題。我會讓這個問題再討論一兩天,但如果批量操作確實繞過了約束或觸發器,我可以看到這是一個問題。
鑑於可能存在與未知風險一樣多的毫無根據的恐懼,我認為很難在不詢問制定政策的人為什麼擔心的情況下真正說出為什麼制定政策。
但是,我猜這可能與// BCP /
BULK INSERT
允許某人SqlBulkCopy
做的事情有關,即:OPENROWSET(BULK ...)
- 禁用約束(
CHECK
,DEFAULT
,FOREIGN KEY
我相信)- 禁用觸發器(如果有審計觸發器,繞過它們可能會被認為是不可取的;有關此特定問題的更多解釋,請參閱@DVKs answer)
以下文件中描述了各種選項:
我沒有提到@RDFozz 指出的表鎖定問題,因為這不是特定於
BULK INSERT
:任何人都可以表 TABLOCK / XLOCK 或設置TRANSACTION ISOLATION LEVEL
為SERIALIZABLE
.更新
我發現了另外兩條可能有助於縮小範圍的資訊:
- 能夠禁用觸發器、禁用約束和設置的問題
IDENTITY_INSERT ON
可能不是將伺服器角色視為威脅的壓倒性理由ADMINISTER BULK OPERATIONS
(ADMINISTER DATABASE BULK OPERATIONS
從 SQL Server 2017 開始) 。bulkadmin
原因是為了執行剛才提到的這三件事,使用者需要ALTER TABLE
對該表或該表所在的模式具有權限。所有權連結不包括 DDL 修改。所以,如果使用者沒有ALTER TABLE
,那麼做這三件事的能力就不是問題。- 到目前為止尚未討論的以及最終可能成為安全問題的是兩者都
BULK INSERT
可以OPENROWSET(BULK...
訪問 SQL Server 之外的外部資源。通過 Windows 登錄訪問 SQL Server 時,將模擬該 Windows 帳戶(即使您使用 切換安全上下文EXECUTE AS LOGIN='...'
)來進行文件系統訪問。這意味著您只能讀取您已被授予讀取權限的文件。沒有錯。***但是,***當通過 SQL Server 登錄訪問 SQL Server 時,外部訪問是在 SQL Server 服務帳戶的上下文中完成的。這意味著擁有此權限的人可以讀取他們本應無法讀取的文件,以及他們不應訪問的文件夾中的文件。
至少,如果 SQL Server 設置為作為僅為 SQL Server 創建的帳戶執行(首選方法),則此類使用者只能讀取“SQL Server”帳戶有權訪問的那些文件。雖然這是一個有限的問題,但它仍然允許讀取諸如 SQL Server 日誌文件之類的文件(我確實測試了以下範例並且它確實有效):
SELECT tmp.[Col1] FROM OPENROWSET(BULK N'C:\Program Files\Microsoft SQL Server\MSSQLxx.InstanceName\MSSQL\Log\ERRORLOG.1', SINGLE_NCLOB) tmp([Col1]);
大多數人無法訪問MSSQL\Log文件夾,因此這是一種規避現有安全限制的方法。
而且,如果 SQL Server 作為
Local System
帳戶執行,那麼我懷疑問題的範圍只會增加,並且具有此權限的使用者將能夠讀取範圍廣泛的系統相關文件。而且,這可能是其他批量導入方法(BCP和
SqlBulkCopy
)不需要bulkadmin
權限/角色的原因:它們是在 SQL Server 之外啟動的,並且會自行處理文件系統權限。在這些情況下,SQL Server 永遠不會讀取文件(或到達 SQL Server 之外),它只是接收要從外部程序正在讀取的文件中導入的數據。除了可能的影響之外,問題中還提到:
對於應用程序的好處,BULK INSERT 效率更高、速度更快、…
好吧,繼續……
並減輕了程序員在 SQL 之外解析文件的需要。
哇,耐莉。讓我們在這裡停下來。T-SQL 通常不是解析語言的最佳選擇。通常最好在將內容插入數據庫之前進行解析。一種方法是使用表值參數 (TVP)。請參閱我對另一個問題的回答(在 DBA.StackExchange 上),該問題涉及預解析和驗證以及有效批量導入所述數據的主題: