BULK INSERT Neden Tehlikeli Olarak Kabul Edilmektedir?

Genel olarak siber güvenlik ekiplerinin (uğraştığım birden fazla organizasyon BULK INSERT) neden uygulamalara ve veritabanı programcılarına (örneğin TSQL) haklar verilmesine karşı koyulduğunu anlamak isterim ? "Diski kötüye kullanımı doldurma" bahanesine inanamıyorum, bir şey eksik olmadıkça, sonuç şöyle bir uygulamadan farklı olmadığından:

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

ve INSERTtemel yazma iznine sahip herkesin uygulayabileceği ortak bir DML komutudur.

Bir uygulamanın yararı için, BULK INSERTçok daha verimli, daha hızlı ve programlayıcıyı SQL dışındaki dosyaları ayrıştırma ihtiyacını giderir.

Düzenleme: Asıl olarak bu soruyu bilgi güvenliği sitesinde bir nedenden dolayı sordum - BULK INSERT'in kullanılmasına karşı olan DBA'lar değil, konuyu zorlayan "Bilgi Güvencesi" (kısaca IA - Siber Güvenlik çalışanları). Bu sorunun bir iki gün daha bekletilmesine izin vereceğim, ancak toplu işlem gerçekten kısıtlamaları veya tetikleyicileri atlarsa, bunun bir sorun olduğunu görebilirim.

Muhtemelen, bilinmeyen risklerin olduğu kadar çok temelsiz korku olduğu göz önüne alındığında, neden bir politika oluşturduklarını sormaksızın neden bir politika oluşturduklarını sormanın zor olduğunu düşünüyorum.

Ancak, bunun muhtemelen BULK INSERT/ SqlBulkCopy/ BCP / OPENROWSET(BULK ...)birisinin yapmasına izin verenle bir ilgisi olduğunu tahmin ediyorum :

1. kısıtlamaları devre dışı bırak ( CHECK, DEFAULTve FOREIGN KEYinanıyorum)
2. Tetikleyicileri devre dışı bırak (yerinde denetim tetikleyicileri varsa, bunları atlamak muhtemelen istenmeyen sayılır; bu belirli konuda daha fazla açıklama için lütfen @DVK’nın yanıtına bakın )

Çeşitli seçenekler aşağıdaki belgelerde açıklanmıştır:

• SqlBulkCopyOptions Enum
• Toplu iç

O belirli değildir çünkü @RDFozz tarafından da belirtildiği tablo kilitleme sorunu söz etmedi BULK INSERTkimse kutu tablasının bir tablock / xlock'a veya set: TRANSACTION ISOLATION LEVELiçin SERIALIZABLE.

GÜNCELLEŞTİRME

Bunu daraltmak için iki ek bilgi parçasıyla karşılaştım:

1. Devre dışı Tetikleyiciler, devre dışı Sınırlamalar ve setteki edememek konularının IDENTITY_INSERT ONolabilir değil görmek için ezici bir nedeni ADMINISTER BULK OPERATIONS, ADMINISTER DATABASE BULK OPERATIONSya (SQL Server 2017 ile başlayan) bulkadminbir tehdit olarak sunucu rolü. Bunun nedeni, az önce bahsedilen bu üç şeyden herhangi birini yapmak için, Kullanıcı'nın ALTER TABLEbu Tabloda veya Tablonun içinde bulunduğu Şema üzerinde izinlerinin olması gerekir . Mülkiyet zincirlemesi DDL değişikliklerini kapsamaz. Yani, eğer Kullanıcı sahip değilse ALTER TABLE, bu üç şeyi yapma yeteneği sorun değildir.

2. Ne kadar ele ve ne sonuçta olabilir edilmemiştir güvenlik sorunu olduğunu hem ve erişim dış kaynaklar, SQL Server dışında. Windows Oturum Açma aracılığıyla SQL Server'a erişirken , dosya sistemi erişimini yapmak için bu Windows hesabının kimliğine bürünülecek (güvenlik bağlamını kullanarak değiştirseniz bile ). Bu, yalnızca okuma izniniz olan dosyaları okuyabileceğiniz anlamına gelir. Bunda yanlış bir şey yok.BULK INSERTOPENROWSET(BULK...EXECUTE AS LOGIN='...'

   AMA, SQL Server'a bir SQL Server Girişi ile erişirken, harici erişim SQL Server hizmet hesabı bağlamında yapılır. Bu, bu izne sahip bir kişinin, başka türlü okuyamayacağı ve erişemeyeceği klasörlerde okuyabileceği dosyaları okuyabileceği anlamına gelir.

   En azından, SQL Server yalnızca SQL Server için oluşturulan bir hesap olarak çalışacak şekilde ayarlandıysa (tercih edilen yöntem), böyle bir Kullanıcı yalnızca "SQL Server" hesabının erişebildiği dosyaları okuyabilirdi. Bu sınırlı bir sorun olsa da, SQL Server günlük dosyaları gibi dosyaları okumayı sağlar (ve aşağıdaki örneği test ettim ve çalışıyor):

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

   Çoğu kişi MSSQL \ Log klasörüne erişemez , bu nedenle mevcut güvenlik kısıtlamalarını aşmanın bir yolu olur.

   Ve eğer SQL Server Local Systemhesap olarak çalışıyorsa , o zaman sorunun kapsamının artacağını ve bu izne sahip bir kullanıcının sistemle ilgili çok çeşitli dosyaları okuyabileceğinden şüpheleniyorum.

   VE, bunun nedeni, diğer toplu ithalat işlemlerinin - BCP ve SqlBulkCopy- bulkadminizin / rol gerektirmemesidir : SQL Server'ın dışında başlatılırlar ve dosya sistemi izinlerini kendi başlarına ele alırlar. Bu durumlarda, SQL Server hiçbir zaman dosyayı okumaz (veya SQL Server'ın dışına ulaşmaz), yalnızca harici işlem tarafından okunan dosyadan alınacak verileri alır.

Olası imalar bir yana, soruda şöyle söylendi:

Bir uygulamanın yararı için, BULK INSERT çok daha verimli, daha hızlı ..

Tamam devam et...

ve programcıyı SQL dışındaki dosyaları ayrıştırma ihtiyacını giderir.

Nelly. Tam burada duralım. T-SQL genellikle ayrıştırma için en iyi dil seçeneği değildir. DB'ye bir şeyler yerleştirmeden önce ayrıştırmayı yapmak en iyisidir. Bunu yapmanın bir yolu, Tablo-Değerli Parametreleri (TVP'ler) kullanmaktır. Lütfen, söz konusu verilerin verimli bir şekilde toplu olarak içe aktarılmasıyla birlikte ön ayrıştırma ve doğrulama konusu ile ilgilenen başka bir soruya verilen cevaba bakın (burada DBA.StackExchange'te):

T-SQL: Özel ayrıştırılmış sayısal verilere sahip CSV-> tablo boru hattı, arama değerleri

Bu, daha önceki bir cevaba değindi ("... tetikleyicileri devre dışı bırak "), ancak devre dışı bırakmanın neden iş açısından istenmeyeceğini açıklamıyordu .

Birçok işletmede, ana masada bulunan tetikleyiciler şunları yapmak için kullanılır:

1. Bütünlük kısıtlamalarını doğrulayın (iş mantığına sahip olanlar, genellikle DB kısıtlamalarında kullanılanlardan daha karmaşık)

2. Daha da önemlisi, verileri denetlemek, özellikle ilgili denetim masasına veri eklemek için (veya ana tablodaki denetim alanlarını güncellemek).

Eski ile ilgili sorunların ne olduğu oldukça açıktır (başvurunuz işlem sonrası işleme üzerinde olumsuz etkileri olan kötü veriler eklemekle yükümlüdür). İkincisi, eğer bir tetikleyici devre dışı bırakılmışsa, iki açıdan denetim perspektifini ortaya koyan hiçbir denetim bilgisine sahip değilsiniz:

• Her şeyden önce, bir grup olarak denetim artık veri değişikliklerini denetleyemez ve bu nedenle birincil işlevlerini İç Denetim olarak gerçekleştiremez.

• İkincisi, denetim kayıtlarının eksikliği, bir şirketin yönettiği denetim gereksinimlerinin ihlali olabilir (örneğin, SAS 70) - bu da şirketinizi sözleşmeleri ihlal etmekten sorumlu kılabilir.

Diğer bir olasılık, bir BULK INSERTişlem yapmanın etkisidir .

Normal olarak, bu tür bir şey normal aktiviteye müdahale etmemek için mümkün olduğunda mesai saatleri dışında çalıştırılır. Bir toplu ekleme, tabloyu saatlerce kilitleyebilir, diğer kesici uçların ortaya çıkmasını önleyebilir (ayrıca seçme, güncelleme veya silme).

Veya güvenlik açısından bir DoS saldırısına çok benzer sonuçlar üretebilir.

Kuşkusuz, bir kişi bunu yanlışlıkla veya kasıtlı olarak işlemler ve basit INSERTifadelerle yapabilir. Ancak, amaçlandığı gibi bir toplu ekleme işlemi kullanmak bu etkiye neden olabilir.

Genel olarak, bir DBA'nın çalışma saatleri dışında kalan etkinlikleri düzenlemeye katılmasını beklerim, çünkü ayrıca yedeklemelerin ve diğer zamanlanmış işlerin tamamlandığından emin olmaları gerekir. İnsanlar bu tür bir şeyi bu tür aktiviteler için yeterli bir değerlendirme yapmadan planlayacak olsaydı, yedeklerin başarısız olduğunu görebiliyordunuz - bu bir takım sebeplerden dolayı sorun olabilir.

Bunun bir nedeni eylemlerin günlüğe kaydedilmesini netleştirmek olabilir. Her eylem bir günlük dosyasındaki bir girişe karşılık gelirse, herhangi bir ek referans olmadan soruna neden olan bir şeyi görmek oldukça önemsizdir. Günlük dosyanız "external.file INSERT FROM" diyorsa, external.file olmadan, daha fazla bir şey söyleyemezsiniz.

Elbette, günlüğe kaydetmenin nasıl çalıştığını değiştirebilirsiniz, ancak başlangıç ​​noktası olarak her eylemi günlüğe kaydetme sırasında bile atomik olarak zorlamak korkunç bir fikir değil.