Tại sao BULK INSERT được coi là nguy hiểm?

21

Tôi muốn hiểu tại sao các nhóm an ninh mạng nói chung (nhiều hơn một tổ chức mà tôi đã xử lý) bị đặt ra chống lại việc cấp quyền BULK INSERT(ví dụ TSQL) cho các ứng dụng và lập trình viên cơ sở dữ liệu? Tôi không thể tin vào lý do "lấp đầy đĩa lạm dụng", trừ khi tôi thiếu một cái gì đó, vì kết quả cuối cùng không khác gì một ứng dụng làm điều gì đó như:

for (long i = 0; i < LONG_MAX; ++i)
    executeSQL("INSERT INTO table VALUES(...)");

và INSERTlà một lệnh DML phổ biến mà bất kỳ ai có quyền ghi cơ bản đều có thể thực thi.

Vì lợi ích của ứng dụng, BULK INSERThiệu quả hơn, nhanh hơn và giải phóng người lập trình về nhu cầu phân tích các tệp bên ngoài SQL.

Chỉnh sửa: Ban đầu tôi đã hỏi câu hỏi này trên trang web bảo mật thông tin vì một lý do - đó không phải là DBA chống lại việc sử dụng BULK INSERT, đó là "Đảm bảo thông tin" (gọi tắt là IA - những người bảo mật không gian mạng) đang buộc vấn đề này. Tôi sẽ để câu hỏi này hầm trong một hoặc hai ngày nữa, nhưng nếu hoạt động hàng loạt thực sự bỏ qua các ràng buộc hoặc kích hoạt, tôi có thể thấy đó là một vấn đề.

— JackLThornton
nguồn

19

Cho rằng có lẽ cũng có nhiều nỗi sợ hãi vô căn cứ như có những rủi ro chưa biết, tôi sẽ nghĩ rằng thật khó để nói tại sao một chính sách được đưa ra mà không hỏi bất kỳ ai tạo ra chính sách tại sao họ quan tâm.

Tuy nhiên, tôi đoán rằng nó có thể có liên quan đến những gì BULK INSERT/ SqlBulkCopy/ BCP / OPENROWSET(BULK ...)cho phép ai đó làm, cụ thể là:

những hạn chế khuyết tật ( CHECK, DEFAULTvà FOREIGN KEYtôi tin)
vô hiệu hóa các kích hoạt (nếu có các kích hoạt kiểm toán tại chỗ, việc bỏ qua chúng có thể được coi là không mong muốn; để giải thích thêm về vấn đề cụ thể này, vui lòng xem câu trả lời của @DVKs )

Các tùy chọn khác nhau được mô tả trong tài liệu sau:

Tôi không đề cập đến vấn đề bảng khóa ghi nhận của @RDFozz vì đó không phải là đặc trưng cho BULK INSERT: ai cũng có thể bàn một TABLOCK / XLOCK hoặc thiết lập TRANSACTION ISOLATION LEVELđể SERIALIZABLE.

CẬP NHẬT

Tôi đã bắt gặp hai mẩu thông tin bổ sung có thể giúp thu hẹp điều này:

Các vấn đề về khả năng vô hiệu hóa Triggers, vô hiệu hóa các ràng buộc và thiết lập IDENTITY_INSERT ONcó thể không phải là lý do quá đáng để xem ADMINISTER BULK OPERATIONS, ADMINISTER DATABASE BULK OPERATIONS(bắt đầu với SQL Server 2017) hoặc bulkadminvai trò máy chủ là mối đe dọa. Lý do là để thực hiện bất kỳ điều nào trong ba điều vừa nêu, Người dùng cần phải có ALTER TABLEquyền trên Bảng đó hoặc trên Lược đồ mà Bảng tồn tại. Chuỗi quyền sở hữu không bao gồm các sửa đổi DDL. Vì vậy, nếu Người dùng không có ALTER TABLE, thì khả năng thực hiện ba điều này là không thành vấn đề.
Điều gì đã không được thảo luận cho đến nay, và những gì cuối cùng có thể là các vấn đề an ninh là cả hai BULK INSERTvà OPENROWSET(BULK...truy cập nguồn lực bên ngoài, bên ngoài của SQL Server. Khi truy cập SQL Server thông qua Đăng nhập Windows, tài khoản Windows đó sẽ bị mạo danh (ngay cả khi bạn chuyển đổi bối cảnh bảo mật bằng cách sử dụng EXECUTE AS LOGIN='...') để thực hiện truy cập hệ thống tệp. Điều này có nghĩa là bạn chỉ có thể đọc các tệp mà bạn đã được phép đọc. Không có gì sai với điều đó.

NHƯNG, khi truy cập SQL Server thông qua Đăng nhập máy chủ SQL, thì việc truy cập bên ngoài được thực hiện trong ngữ cảnh của tài khoản dịch vụ SQL Server. Điều này có nghĩa là ai đó có quyền này có thể đọc các tệp mà họ không thể đọc được và trong các thư mục mà họ không có quyền truy cập.

Tối thiểu, nếu SQL Server được thiết lập để chạy như một tài khoản được tạo chỉ dành cho SQL Server (phương thức ưa thích), thì Người dùng đó chỉ có thể đọc những tệp mà tài khoản "SQL Server" có quyền truy cập. Mặc dù đây là một vấn đề hạn chế, nó vẫn cho phép đọc các tệp như tệp nhật ký SQL Server (và tôi đã kiểm tra ví dụ sau và nó vẫn hoạt động):
```
SELECT tmp.[Col1]
FROM   OPENROWSET(BULK
   N'C:\Program Files\Microsoft SQL Server\MSSQLxx.InstanceName\MSSQL\Log\ERRORLOG.1',
                  SINGLE_NCLOB) tmp([Col1]);
```
Hầu hết mọi người sẽ không có quyền truy cập vào thư mục MSSQL \ Log , vì vậy đây sẽ là một cách để tránh các hạn chế bảo mật hiện có.

Và, nếu SQL Server đang chạy như một Local Systemtài khoản, thì tôi nghi ngờ rằng phạm vi của vấn đề chỉ tăng lên và Người dùng có quyền này sẽ có thể đọc một loạt các tệp liên quan đến hệ thống.

VÀ, đây có thể là lý do tại sao các phương thức nhập hàng loạt khác - BCP và SqlBulkCopy- không yêu cầu bulkadminquyền / vai trò: chúng được khởi tạo bên ngoài SQL Server và sẽ tự xử lý các quyền của hệ thống tệp. Trong những trường hợp đó, SQL Server không bao giờ đọc tệp (hoặc vươn ra ngoài SQL Server), nó chỉ nhận dữ liệu để nhập từ tệp đang được đọc bởi quy trình bên ngoài.

Gợi ý có thể sang một bên, nó đã được nói trong câu hỏi:

Vì lợi ích của ứng dụng, BULK INSERT hiệu quả hơn, nhanh hơn, ..

Được, tiếp tục đi...

và giải phóng lập trình viên về nhu cầu phân tích các tệp bên ngoài SQL.

Whoa Nelly. Hãy dừng lại ở đây. T-SQL thường không phải là lựa chọn ngôn ngữ tốt nhất để phân tích cú pháp. Thường là tốt nhất để thực hiện phân tích cú pháp trước khi chèn công cụ vào DB. Một cách để làm điều này là sử dụng các tham số có giá trị bảng (TVP). Vui lòng xem câu trả lời của tôi cho một câu hỏi khác (ở đây trên DBA.StackExchange) liên quan đến chủ đề phân tích trước và xác thực cùng với nhập dữ liệu hàng loạt hiệu quả:

T-SQL: CSV-> đường dẫn bảng với dữ liệu số được phân tích cú pháp tùy chỉnh, giá trị tra cứu

— Solomon Rutzky
nguồn

Với sự nhân rộng tại chỗ, có những cân nhắc bổ sung được thực hiện để chèn số lượng lớn.

— mustaccio

6

Đây là loại được ám chỉ trong một câu trả lời trước đó ("... vô hiệu hóa kích hoạt "), nhưng không giải thích tại sao việc vô hiệu hóa sẽ không được mong muốn từ quan điểm kinh doanh.

Trong nhiều doanh nghiệp, các kích hoạt trên bảng chính được sử dụng để:

Xác thực các ràng buộc toàn vẹn (những ràng buộc logic kinh doanh phức tạp hơn thường được sử dụng trong các ràng buộc DB)
Quan trọng hơn, để kiểm toán dữ liệu, cụ thể là chèn dữ liệu vào bảng kiểm toán tương ứng (hoặc cập nhật các trường kiểm toán trong bảng chính).

Rõ ràng vấn đề trước đây là gì (ứng dụng của bạn có khả năng chèn dữ liệu xấu có ảnh hưởng tiêu cực đến xử lý hạ nguồn). Theo như sau này, nếu một trình kích hoạt bị vô hiệu hóa, bạn không có bất kỳ thông tin kiểm toán nào, điều này đặt ra hai vấn đề từ góc độ kiểm toán:

Trước hết, kiểm toán như một nhóm không còn có thể kiểm toán các thay đổi dữ liệu và do đó không thể thực hiện chức năng chính của họ là Kiểm toán nội bộ.
Thứ hai, thiếu hồ sơ kiểm toán có thể vi phạm các yêu cầu kiểm toán mà công ty chịu sự điều chỉnh của (ví dụ: SAS 70) - điều này có thể khiến công ty bạn chịu trách nhiệm về việc vi phạm hợp đồng.

— DVK
nguồn

Chào bạn Tôi không đồng ý với mô tả của bạn về những gì không mong muốn ở đây và tôi đánh giá cao chi tiết này, nhưng chỉ để ghi lại, tôi đã nói trong câu trả lời của mình rằng việc vô hiệu hóa kích hoạt sẽ là không mong muốn nếu có kích hoạt kiểm toán. Đúng, đó không phải là một lời giải thích chi tiết, nhưng không chính xác để nói rằng đó là "không được giải thích". Có thể tốt hơn để nói rằng nó quá đơn giản hoặc không cung cấp đủ lời giải thích liên quan đến kích hoạt kiểm toán và không đề cập đến xác nhận (và +1 để đề cập đến điều đó và cho chi tiết bổ sung tổng thể). Chỉ là một ý nghĩ.

— Solomon Rutzky

@SolomonRutzky - Tôi đặc biệt chỉ ra rằng câu trả lời "không giải thích tại sao " đó là một vấn đề :) Nếu bạn không thể xác định một vấn đề kinh doanh; chi tiết kỹ thuật thường không liên quan, đặc biệt là với OP, những người có cuộc thảo luận dựa trên kinh doanh với IA. Nói cách khác, nếu họ nói "oh, kích hoạt kiểm toán có thể bị vô hiệu hóa", IA sẽ hỏi " tat có nghĩa gì với chúng ta ?" - thông thường họ không phải là DBA hoặc nhà phát triển.

— DVK

được. Tôi đoán tôi chỉ đọc câu đầu tiên nói rằng "câu trả lời khác đề cập đến việc vô hiệu hóa kích hoạt là không mong muốn, nhưng không giải thích tại sao". và vâng, tôi thường đồng ý với bạn về sự cần thiết phải xác định đúng vấn đề, tôi đã giả định (có thể không phải lúc nào cũng là chính sách tốt nhất ;-) rằng OP hiểu được ý nghĩa của việc vô hiệu hóa cơ chế kiểm toán. Nếu tôi không chính xác, thì rất may bạn đã cung cấp thông tin đó ở đây. Và vì vậy tôi vừa cập nhật câu trả lời của mình để liên kết đến mục đích này :)

— Solomon Rutzky

6

Một khả năng khác là tác động của việc chạy một BULK INSERThoạt động.

Thông thường, loại điều này sẽ được chạy ngoài giờ khi có thể, để không can thiệp vào hoạt động bình thường. Một số lượng lớn chèn có thể khóa một bảng trong nhiều giờ, ngăn chặn các chèn khác xảy ra (cũng như chọn, cập nhật hoặc xóa).

Hoặc, từ góc độ bảo mật, nó có thể tạo ra kết quả rất giống với một cuộc tấn công DoS.

Phải thừa nhận rằng, người ta có thể làm điều này một cách vô tình hoặc cố ý với các giao dịch và các INSERTtuyên bố đơn giản . Tuy nhiên, sử dụng quy trình chèn số lượng lớn như dự định có thể gây ra hiệu ứng này.

Nói chung, tôi mong muốn một DBA tham gia vào việc tổ chức hoạt động ngoài giờ, vì họ cũng cần đảm bảo sao lưu và các công việc được lên lịch khác hoàn tất. Nếu mọi người lên lịch cho loại điều này mà không xem xét đầy đủ cho các hoạt động đó, bạn có thể thấy các bản sao lưu thất bại - đó có thể là một vấn đề vì một số lý do.

— RDFozz
nguồn

2

Một lý do cho điều này có thể được thực hiện để làm cho đăng nhập hành động rõ ràng. Nếu mọi hành động tương ứng với một mục trong tệp nhật ký, thì thật là tầm thường khi thấy điều gì đó gây ra sự cố mà không có bất kỳ tham chiếu bổ sung nào. Nếu tệp nhật ký của bạn nói "CHERTN TỪ bên ngoài.file", không có bên ngoài.file, bạn không thể nói gì thêm.

Tất nhiên, bạn có thể sửa đổi cách hoạt động của việc ghi nhật ký, nhưng như một điểm khởi đầu, việc thực thi mọi hành động trở thành nguyên tử ngay cả khi đăng nhập không phải là một ý tưởng tồi.