BULK INSERT क्यों खतरनाक माना जाता है?

21

मैं यह समझना चाहूंगा कि साइबर-सुरक्षा टीमों को सामान्य रूप से (एक से अधिक संगठन जो मैंने निपटाया है) BULK INSERTअनुप्रयोगों और डेटाबेस प्रोग्रामर को अधिकार देने (जैसे टीएसक्यूएल) के अधिकार के खिलाफ निर्धारित है ? जब तक मैं कुछ याद नहीं कर रहा हूँ, तब तक मैं "डिस्क दुरुपयोग को भरने" बहाने पर विश्वास नहीं कर सकता, क्योंकि अंतिम परिणाम कुछ के साथ एक आवेदन से अलग नहीं है:

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

और INSERTएक सामान्य डीएमएल कमांड है जिसे कोई भी व्यक्ति बेसिक राइट की अनुमति दे सकता है।

एक आवेदन के लाभ के लिए, BULK INSERTकहीं अधिक कुशल, तेज है, और SQL के बाहर फ़ाइलों को पार्स करने की आवश्यकता के प्रोग्रामर को राहत देता है।

संपादित करें: मैंने मूल रूप से एक कारण के लिए सूचना सुरक्षा साइट पर यह सवाल पूछा था - यह डीबीए नहीं है जो कि बल्क इंसर्ट का उपयोग करने के खिलाफ हैं, यह "सूचना आश्वासन" (संक्षेप में - साइबरस्पेस लोगों के लिए आईए) है जो इस मुद्दे को मजबूर कर रहा है। मैं इस प्रश्न को एक या दो दिन के लिए स्टू होने दूंगा, लेकिन अगर बल्क ऑपरेशन वास्तव में बाधाओं या ट्रिगर को बाईपास करता है, तो मैं देख सकता हूं कि एक मुद्दा है।

— JackLThornton
स्रोत

19

यह देखते हुए कि अज्ञात जोखिम के रूप में संभवतः कई निराधार आशंकाएं हैं, मुझे लगता है कि यह वास्तव में कहना मुश्किल है कि नीति किस कारण से है, जिससे वे चिंतित हैं कि नीति क्यों बनाई गई है।

हालांकि, मुझे लगता है कि होगा यह शायद के साथ क्या करना है कि कुछ क्या BULK INSERT/ SqlBulkCopy/ बीसीपी / OPENROWSET(BULK ...)कोई ऐसा करने के लिए, अर्थात् अनुमति देते हैं:

अक्षम की कमी ( CHECK, DEFAULT, और FOREIGN KEYमेरा मानना है कि)
अक्षम ट्रिगर्स (यदि जगह में ऑडिट ट्रिगर्स हैं, तो उन्हें पास करना संभवत: अवांछनीय माना जाएगा; इस विशेष मुद्दे पर अधिक स्पष्टीकरण के लिए, कृपया @DVKs उत्तर देखें )

निम्नलिखित दस्तावेज में विभिन्न विकल्पों का वर्णन किया गया है:

मैंने @RDFozz द्वारा नोट किए गए टेबल लॉकिंग मुद्दे का उल्लेख नहीं किया है क्योंकि यह विशिष्ट नहीं है BULK INSERT: कोई भी टैबलॉक / एक्सएलएक्स को टेबल कर सकता है या सेट कर सकता TRANSACTION ISOLATION LEVELहै SERIALIZABLE।

अद्यतन करें

मुझे जानकारी के दो अतिरिक्त टुकड़े मिले जो इसे कम करने में मदद कर सकते हैं:

अक्षम ट्रिगर, अक्षम प्रतिबन्ध, और सेट करने में सक्षम होने के मुद्दों IDENTITY_INSERT ONहो सकता है नहीं यह देखने के लिए एक भारी कारण हो ADMINISTER BULK OPERATIONS, ADMINISTER DATABASE BULK OPERATIONSया (SQL सर्वर 2017 के साथ शुरू) bulkadminएक खतरे के रूप सर्वर भूमिका। कारण यह है कि उन तीन चीजों में से किसी को भी करने के लिए, उपयोगकर्ता ALTER TABLEको उस तालिका पर, या स्कीमा पर तालिका के मौजूद होने पर अनुमतियों की आवश्यकता होती है । स्वामित्व जंजीरों में डीडीएल संशोधनों को शामिल नहीं किया गया है। इसलिए, यदि उपयोगकर्ता के पास नहीं है ALTER TABLE, तो इन तीन चीजों को करने की क्षमता एक गैर-मुद्दा है।
क्या अब तक चर्चा नहीं की गई है, और क्या हो सकता है अंत में सुरक्षा मुद्दा है कि दोनों और पहुँच बाह्य संसाधनों, एसक्यूएल सर्वर के बाहर। जब एक Windows लॉगिन के माध्यम से SQL सर्वर तक पहुँच प्राप्त होती है, तो फ़ाइल सिस्टम का उपयोग करने के लिए Windows खाता प्रतिरूपण किया जाएगा (भले ही आप सुरक्षा संदर्भ का उपयोग कर रहे हों)। इसका मतलब है कि आप केवल उन फ़ाइलों को पढ़ सकते हैं जिन्हें आपको पढ़ने की अनुमति दी गई है। कुछ गलत नहीं है उसके साथ।BULK INSERTOPENROWSET(BULK...EXECUTE AS LOGIN='...'

लेकिन, जब SQL सर्वर लॉगिन के माध्यम से SQL सर्वर का उपयोग करते हैं, तो बाहरी एक्सेस SQL सर्वर सेवा खाते के संदर्भ में किया जाता है। इसका मतलब यह है कि इस अनुमति वाला कोई व्यक्ति उन फ़ाइलों को पढ़ सकता है जिन्हें उन्हें अन्यथा पढ़ने में सक्षम नहीं होना चाहिए, और उन फ़ोल्डरों में जिनकी उन्हें पहुंच नहीं होनी चाहिए।

कम से कम, यदि SQL सर्वर को केवल SQL सर्वर (पसंदीदा विधि) के लिए बनाए गए खाते के रूप में चलाने के लिए सेट किया गया था, तो ऐसा उपयोगकर्ता केवल उन फ़ाइलों को पढ़ सकता है जिनके पास "SQL सर्वर" खाते की पहुंच है। हालांकि यह एक सीमित समस्या है, यह अभी भी SQL सर्वर लॉग फ़ाइलों के रूप में फ़ाइलों को पढ़ने की अनुमति देता है (और मैंने निम्न उदाहरण का परीक्षण किया और यह काम नहीं करता है:
```
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 सर्वर Local Systemखाते के रूप में चल रहा है, तो मुझे संदेह है कि समस्या का दायरा केवल बढ़ता है, और यह कि इस अनुमति वाला उपयोगकर्ता सिस्टम से संबंधित फ़ाइलों की एक विस्तृत श्रृंखला को पढ़ सकेगा।

और, यह संभावना है कि थोक आयात करने के अन्य तरीकों - बीसीपी और SqlBulkCopy- को bulkadminअनुमति / भूमिका की आवश्यकता नहीं है : वे SQL सर्वर के बाहर शुरू किए जाते हैं और अपने आप फ़ाइल सिस्टम अनुमतियों को संभाल लेंगे। उन मामलों में, SQL सर्वर फ़ाइल को कभी नहीं पढ़ता है (या SQL सर्वर के बाहर पहुंचता है), यह सिर्फ बाहरी प्रक्रिया द्वारा पढ़ी जा रही फ़ाइल से आयात करने के लिए डेटा प्राप्त करता है।

एक तरफ संभावित निहितार्थ, यह सवाल में कहा गया था:

एक आवेदन के लाभ के लिए, बुल INSERT कहीं अधिक कुशल, तेज, है ..

ठीक है आगे बढ़ो...

और SQL के बाहर फ़ाइलों को पार्स करने की आवश्यकता के प्रोग्रामर को राहत देता है।

वाह नेली। चलो यहीं रुक जाते हैं। टी-एसक्यूएल आमतौर पर पार्सिंग के लिए भाषाओं का सबसे अच्छा विकल्प नहीं है। डीबी में सामान डालने से पहले पार्सिंग करना अक्सर सबसे अच्छा होता है। ऐसा करने का एक तरीका टेबल-वैलिड पैरामीटर्स (टीवीपी) का उपयोग करना है। कृपया एक अन्य प्रश्न (DBA.StackExchange पर यहां) का मेरा उत्तर देखें जो कि पूर्व-पार्सिंग और मान्यता के विषय के साथ-साथ उक्त डेटा के कुशल थोक आयात से संबंधित है:

T-SQL: CSV-> कस्टम पार्स किए गए संख्यात्मक डेटा, लुकअप मानों के साथ टेबल पाइपलाइन

— सोलोमन रुट्ज़की
स्रोत

जगह में प्रतिकृति के साथ थोक डालने के लिए अतिरिक्त विचार किए जाने हैं।

— 17:43 पर मस्टीको

6

यह पहले के उत्तर ("... अक्षम ट्रिगर्स ") के लिए अनुमत था , लेकिन यह स्पष्ट नहीं करता है कि अक्षम करना व्यावसायिक दृष्टिकोण से क्यों वांछनीय होगा।

कई व्यवसायों में, मुख्य टेबल पर ट्रिगर का उपयोग किया जाता है:

वैध अखंडता की कमी (व्यावसायिक तर्क से अधिक जटिल है जो आमतौर पर DB बाधाओं में उपयोग की जाती है)
अधिक महत्वपूर्ण बात, डेटा को ऑडिट करने के लिए, विशेष रूप से संबंधित ऑडिट टेबल (या मेन टेबल में ऑडिट फील्ड्स को अपडेट करना) में डेटा डालना।

यह बल्कि यह स्पष्ट है कि पूर्व की समस्याएं क्या हैं (आपका आवेदन खराब डेटा डालने के लिए उत्तरदायी है जिसका डाउनस्ट्रीम प्रसंस्करण पर नकारात्मक प्रभाव पड़ता है)। जहां तक बाद की बात है, अगर कोई ट्रिगर अक्षम है, तो आपके पास ऑडिटिंग की कोई जानकारी नहीं है, जो ऑडिट के नजरिए से दो समस्याएं पैदा करती है:

सबसे पहले, एक समूह के रूप में ऑडिट अब डेटा परिवर्तनों का ऑडिट नहीं कर सकता है और इस प्रकार आंतरिक ऑडिट के रूप में अपने प्राथमिक कार्य करने में असमर्थ हैं।
दूसरा, ऑडिट रिकॉर्ड की कमी ऑडिटिंग आवश्यकताओं का उल्लंघन हो सकती है जो एक कंपनी द्वारा शासित है (जैसे एसएएस 70) - जो आपकी कंपनी को अनुबंधों का उल्लंघन करने के लिए उत्तरदायी बना सकता है।

— DVK
स्रोत

नमस्ते। मैं यहाँ क्या अवांछनीय है, आपके विवरण से असहमत नहीं हूँ, और मैं विस्तार की सराहना करता हूँ, लेकिन सिर्फ रिकॉर्ड के लिए, मैंने अपने जवाब में कहा कि ट्रिगर को अक्षम करना ऑडिट ट्रिगर होने पर अवांछनीय होगा। सच है, यह एक विस्तृत विवरण नहीं है, लेकिन यह कहने के लिए बिल्कुल सटीक नहीं है कि यह "समझाया नहीं" गया था। शायद यह कहना बेहतर होगा कि यह बहुत सरल था, या ऑडिट ट्रिगर के बारे में पर्याप्त स्पष्टीकरण नहीं दिया था, और सत्यापन का उल्लेख नहीं किया था (और उल्लेख करने के लिए +1, और अतिरिक्त विस्तार के लिए)। सिर्फ एक विचार।

— सोलोमन रटज़की

@SolomonRutzky - मैंने विशेष रूप से संकेत दिया कि उत्तर "यह क्यों नहीं समझाता है " कि एक समस्या है :) यदि आप किसी व्यावसायिक समस्या को परिभाषित नहीं कर सकते हैं; तकनीकी विवरण अक्सर अप्रासंगिक होते हैं, खासकर ओपी के लिए जो आईए के साथ व्यापार-आधारित चर्चा कर रहे हैं। दूसरे शब्दों में, यदि वे कहते हैं "ओह, ऑडिट ट्रिगर्स को अक्षम किया जा सकता है", आईए पूछेंगे " हमारे लिए क्या मतलब है ?" - वे डीबीए या डेवलपर्स नहीं हैं, आमतौर पर।

— DVK

ठीक है। मुझे लगता है कि मैंने सिर्फ उस वाक्य को यह कहते हुए पढ़ा कि "ट्रिगर को अक्षम करने का उल्लेख किया गया दूसरा उत्तर अवांछनीय है, लेकिन यह नहीं बताया कि क्यों"। और हां, मैं आम तौर पर इस मुद्दे को ठीक से परिभाषित करने की आवश्यकता के बारे में आपसे सहमत हूं, मैं मान रहा था (शायद हमेशा सबसे अच्छी नीति नहीं; ;-) कि ओपी ने एक ऑडिट तंत्र को अक्षम करने के निहितार्थ को समझा। अगर मैं गलत हूं, तो शुक्र है कि आपने वह जानकारी यहां उपलब्ध कराई है। और इसलिए मैंने उस उद्देश्य के लिए इस से लिंक करने के लिए सिर्फ अपना जवाब अपडेट किया :)

— सोलोमन रटज़की

6

एक और संभावना एक BULK INSERTऑपरेशन चलाने का प्रभाव है ।

आम तौर पर, इस तरह की चीज को संभव होने पर ऑफ-टाइम चलाया जाएगा, ताकि सामान्य गतिविधि में हस्तक्षेप न हो। एक बल्क इंसर्ट अन्य आवेषणों को होने से रोकता है (साथ ही साथ चयन, अद्यतन, या हटाता है) को एक तालिका को घंटों के लिए लॉक कर सकता है।

या, सुरक्षा दृष्टिकोण से, यह DoS हमले के समान परिणाम उत्पन्न कर सकता है।

माना जाता है कि कोई भी ऐसा गलती से या जानबूझकर लेनदेन और सरल INSERTबयानों के साथ कर सकता है। हालांकि, एक थोक सम्मिलित प्रक्रिया का उपयोग करना, जैसा कि इस आशय का कारण हो सकता है।

आम तौर पर, मुझे उम्मीद है कि एक डीबीए ऑफ-टाइम गतिविधि को आयोजित करने में शामिल होगा, क्योंकि उन्हें भी निश्चित बैकअप और अन्य अनुसूचित नौकरियों को पूरा करने की आवश्यकता है। अगर लोगों को इस तरह की गतिविधियों के लिए पर्याप्त विचार के बिना इस तरह का समय निर्धारित करना था, तो आप बैकअप को विफल देख सकते हैं - जो कई कारणों से एक समस्या हो सकती है।

— RDFozz
स्रोत

2

इसका एक कारण कार्यों की लॉगिंग को स्पष्ट करना हो सकता है। यदि हर क्रिया लॉग फ़ाइल में एक प्रविष्टि से मेल खाती है, तो यह देखने के लिए काफी तुच्छ है जो बिना किसी अतिरिक्त संदर्भ के समस्या का कारण बना। यदि आपकी लॉग फ़ाइल "INSERT FROM external.file" कहती है, तो external.file के बिना, आप कुछ और नहीं बता सकते।

बेशक, आप संशोधित कर सकते हैं कि लॉगिंग कैसे काम करती है, लेकिन एक प्रारंभिक बिंदु के रूप में, लॉगिंग के भीतर भी हर क्रिया को परमाणु के रूप में लागू करना एक भयानक विचार नहीं है।