Mengapa BULK INSERT Dianggap Berbahaya?

Saya ingin memahami mengapa tim keamanan dunia maya secara umum (lebih dari satu organisasi yang pernah saya tangani) sangat menentang pemberian BULK INSERT(misalnya TSQL) hak untuk aplikasi dan pemrogram basis data? Saya tidak dapat mempercayai alasan "mengisi penyalahgunaan disk", kecuali saya melewatkan sesuatu, karena hasil akhirnya tidak berbeda dengan aplikasi yang melakukan sesuatu seperti:

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

dan INSERTmerupakan perintah DML umum yang dapat dijalankan oleh siapa pun dengan izin menulis dasar.

Untuk manfaat aplikasi, BULK INSERTjauh lebih efisien, lebih cepat, dan mengurangi kebutuhan programmer untuk mem-parsing file di luar SQL.

Sunting: Saya awalnya mengajukan pertanyaan ini di situs keamanan informasi karena suatu alasan - bukan DBA yang menentang penggunaan BULK INSERT, itu adalah "Jaminan Informasi" (IA singkatnya - orang-orang Cybersecurity) yang memaksa masalah ini. Saya akan membiarkan pertanyaan ini direbus selama satu atau dua hari lagi, tetapi jika operasi massal memang melewati batasan atau pemicu, saya bisa melihat itu menjadi masalah.

Mengingat bahwa mungkin ada ketakutan yang tidak berdasar sama seperti risiko yang tidak diketahui, saya akan berpikir bahwa sulit untuk benar-benar mengatakan mengapa suatu kebijakan ada tanpa meminta kepada siapa pun yang membuat kebijakan mengapa mereka khawatir.

Namun, saya kira itu mungkin ada hubungannya dengan apa yang BULK INSERT/ SqlBulkCopy/ BCP / OPENROWSET(BULK ...)izinkan seseorang lakukan, yaitu:

1. kendala menonaktifkan ( CHECK, DEFAULT, dan FOREIGN KEYsaya percaya)
2. nonaktifkan pemicu (jika ada pemicu audit di tempat, dengan memintaskannya mungkin akan dianggap tidak diinginkan; untuk penjelasan lebih lanjut tentang masalah khusus ini, silakan lihat jawaban @VK )

Berbagai opsi dijelaskan dalam dokumentasi berikut:

• SqlBulkCopyOptions Enum
• BULK INSERT

Saya tidak menyebutkan masalah penguncian tabel yang dicatat oleh @RDFozz karena itu tidak spesifik untuk BULK INSERT: siapa pun dapat membuat tabel TABLOCK / XLOCK atau mengatur TRANSACTION ISOLATION LEVELke SERIALIZABLE.

MEMPERBARUI

Saya menemukan dua informasi tambahan yang mungkin membantu mempersempit ini:

1. Masalah-masalah untuk dapat menonaktifkan Pemicu, menonaktifkan Kendala, dan mengatur IDENTITY_INSERT ONmungkin bukan alasan besar untuk melihat ADMINISTER BULK OPERATIONS, ADMINISTER DATABASE BULK OPERATIONS(dimulai dengan SQL Server 2017), atau bulkadminperan server sebagai ancaman. Alasannya adalah bahwa untuk melakukan salah satu dari tiga hal yang baru saja disebutkan, Pengguna perlu memiliki ALTER TABLEizin pada Tabel itu, atau pada Skema tempat Tabel itu berada. Rantai kepemilikan tidak mencakup modifikasi DDL. Jadi, jika Pengguna tidak memiliki ALTER TABLE, maka kemampuan untuk melakukan tiga hal ini bukan masalah.

2. Apa yang belum dibahas sejauh ini, dan apa yang akhirnya mungkin menjadi yang masalah keamanan adalah bahwa kedua BULK INSERTdan OPENROWSET(BULK...akses sumber daya eksternal, di luar SQL Server. Ketika mengakses SQL Server melalui Windows Login, akun Windows itu akan ditiru (bahkan jika Anda mengganti konteks keamanan menggunakan EXECUTE AS LOGIN='...') untuk melakukan akses sistem file. Ini berarti bahwa Anda hanya dapat membaca file yang telah diberikan izin untuk Anda baca. Tidak ada yang salah dengan itu.

   NAMUN, ketika mengakses SQL Server melalui SQL Server Login, maka akses eksternal dilakukan dalam konteks akun layanan SQL Server. Ini berarti bahwa seseorang dengan izin ini dapat membaca file yang seharusnya tidak dapat mereka baca, dan dalam folder yang seharusnya tidak dapat mereka akses.

   Paling tidak, jika SQL Server dibuat untuk dijalankan sebagai akun yang dibuat hanya untuk SQL Server (metode yang disukai), maka Pengguna tersebut hanya dapat membaca file-file yang dapat diakses oleh akun "SQL Server". Meskipun ini adalah masalah terbatas, masih memungkinkan untuk membaca file seperti file log SQL Server (dan saya memang menguji contoh berikut dan itu berhasil):

   SELECT tmp.[Col1]
   FROM   OPENROWSET(BULK
      N'C:\Program Files\Microsoft SQL Server\MSSQLxx.InstanceName\MSSQL\Log\ERRORLOG.1',
                     SINGLE_NCLOB) tmp([Col1]);

   Kebanyakan orang tidak akan memiliki akses ke folder MSSQL \ Log , jadi ini akan menjadi cara untuk menghindari batasan keamanan yang ada.

   Dan, jika SQL Server berjalan sebagai Local Systemakun, maka saya menduga bahwa ruang lingkup masalah hanya meningkat, dan bahwa Pengguna dengan izin ini akan dapat membaca berbagai file terkait sistem.

   DAN, ini mungkin mengapa metode lain untuk melakukan impor massal - BCP dan SqlBulkCopy- tidak memerlukan bulkadminizin / peran: mereka diinisiasi di luar SQL Server dan akan menangani izin sistem file sendiri. Dalam kasus tersebut, SQL Server tidak pernah membaca file (atau menjangkau di luar SQL Server), ia hanya menerima data untuk diimpor dari file yang sedang dibaca oleh proses eksternal.

Kemungkinan implikasinya, dikatakan dalam pertanyaan:

Untuk keuntungan aplikasi, BULK INSERT jauh lebih efisien, lebih cepat, ..

Ok, lanjutkan ...

dan meringankan programmer dari kebutuhan untuk mem-parsing file di luar SQL.

Whoa Nelly. Mari berhenti di sini. T-SQL biasanya bukan pilihan bahasa terbaik untuk parsing. Seringkali yang terbaik adalah melakukan parsing sebelum memasukkan barang ke dalam DB. Salah satu cara untuk melakukan ini adalah dengan menggunakan Table-Valued Parameters (TVPs). Silakan lihat jawaban saya untuk pertanyaan lain (di sini di DBA.StackExchange) yang berkaitan dengan topik pra-penguraian dan validasi bersama dengan impor massal efisien data yang disebutkan:

T-SQL: CSV-> pipeline tabel dengan data numerik parsing khusus, nilai pencarian

Ini agak disinggung dalam jawaban sebelumnya ("... nonaktifkan pemicu "), tetapi tidak menjelaskan mengapa penonaktifan tidak diinginkan dari sudut pandang bisnis.

Di banyak bisnis, pemicu pada tabel utama digunakan untuk:

1. Validasi integritas integritas (yang memiliki logika bisnis lebih rumit daripada yang biasanya digunakan dalam kendala DB)

2. Lebih penting lagi, untuk mengaudit data, khususnya untuk memasukkan data ke dalam tabel audit yang sesuai (atau memperbarui bidang audit di tabel utama).

Agak jelas apa masalah dengan yang pertama (aplikasi Anda bertanggung jawab untuk memasukkan data buruk yang memiliki efek negatif pada pemrosesan hilir). Sejauh yang terakhir, jika pemicu dinonaktifkan, Anda tidak memiliki informasi audit, yang menimbulkan dua masalah dari perspektif audit:

• Pertama-tama, audit sebagai suatu kelompok tidak dapat lagi mengaudit perubahan data dan dengan demikian tidak dapat menjalankan fungsi utamanya sebagai Audit Internal.

• Kedua, kurangnya catatan audit mungkin merupakan pelanggaran persyaratan audit yang diatur oleh perusahaan (misalnya SAS 70) - yang dapat membuat perusahaan Anda bertanggung jawab atas pelanggaran kontrak.

Kemungkinan lain adalah dampak dari menjalankan BULK INSERToperasi.

Biasanya, hal semacam ini akan berjalan di luar jam kerja jika memungkinkan, agar tidak mengganggu aktivitas normal. Sisipan massal dapat mengunci tabel selama berjam-jam, mencegah terjadinya insert lainnya (serta memilih, memperbarui, atau menghapus).

Atau, dari perspektif keamanan, itu dapat menghasilkan hasil yang sangat mirip dengan serangan DoS.

Harus diakui, seseorang dapat melakukan ini baik secara tidak sengaja atau sengaja dengan transaksi dan INSERTpernyataan sederhana . Namun, menggunakan proses penyisipan massal sebagaimana dimaksud dapat menyebabkan efek ini.

Secara umum, saya berharap DBA akan terlibat dalam mengorganisir kegiatan di luar jam kerja, karena mereka juga perlu memastikan backup dan pekerjaan terjadwal lainnya selesai. Jika orang menjadwalkan hal semacam ini tanpa pertimbangan yang memadai untuk kegiatan seperti itu, Anda dapat melihat cadangan gagal - yang dapat menjadi masalah karena sejumlah alasan.

Salah satu alasan untuk ini bisa menjadi membuat penebangan tindakan jelas. Jika setiap tindakan sesuai dengan satu entri dalam file log, cukup sepele untuk melihat sesuatu yang menyebabkan masalah tanpa referensi tambahan. Jika file log Anda mengatakan "INSERT FROM external.file", tanpa external.file, Anda tidak dapat mengatakan apa-apa lagi.

Tentu saja, Anda bisa memodifikasi cara kerja logging, tetapi sebagai titik awal, menegakkan setiap tindakan untuk menjadi atom bahkan dalam logging bukanlah ide yang buruk.