বাল্ক ইনসার্টকে কেন বিপজ্জনক বলে বিবেচনা করা হয়?

21

আমি বুঝতে চাই যে সাধারণভাবে সাইবার-সুরক্ষা দলগুলি (আমি যে একাধিক সংস্থার সাথে ডিল করেছি BULK INSERT) অ্যাপ্লিকেশন এবং ডাটাবেস প্রোগ্রামারদের অধিকার দেওয়ার (যেমন, টিএসকিউএল) অধিকার দেওয়ার বিরুদ্ধে কেন নির্ধারিত ? আমি "ডিস্কের অপব্যবহার পূরণ" অজুহাত বিশ্বাস করতে পারি না, যদি না আমি কিছু অনুপস্থিত থাকি, কারণ ফলাফলটি কোনও অ্যাপ্লিকেশন যেমন কিছু করার চেয়ে আলাদা নয়:

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

এবং INSERTএকটি সাধারণ ডিএমএল কমান্ড যা বেসিক লেখার অনুমতি সহ যে কেউ কার্যকর করতে পারে।

কোনও অ্যাপ্লিকেশনটির সুবিধার জন্য, BULK INSERTঅনেক বেশি কার্যকর, দ্রুত এবং প্রোগ্রামারকে এসকিউএল এর বাইরে ফাইলগুলি বিশ্লেষণের প্রয়োজন থেকে মুক্তি দেয়।

সম্পাদনা: আমি মূলত তথ্য সুরক্ষা সাইটে এই কারণটি একটি কারণের জন্য জিজ্ঞাসা করেছি - এটি ডিবিএর পক্ষ থেকে বাল্ক ইনসার্ট ব্যবহারের বিরোধী নয়, এটি "তথ্য আশ্বাস" (সংক্ষেপে আইএএ - সাইবার সিকিউরিটি ভাবেন) যে বিষয়টি জোর করছে। আমি এই প্রশ্নটি আরও দু'দিনের জন্য ছেড়ে দেব, তবে যদি বাল্ক অপারেশন সত্যই সীমাবদ্ধতা বা ট্রিগারগুলি বাইপাস করে তবে আমি দেখতে পাচ্ছি যে এটি একটি সমস্যা being

— JackLThornton
সূত্র

19

অজানা ঝুঁকির কারণেই সম্ভবত অনেকগুলি ভিত্তিহীন আশঙ্কা রয়েছে বলে আমি মনে করব যে, কেন কেউ নীতি তৈরি করেছে তা জিজ্ঞাসা না করেই কোনও নীতি কেন সেখানে রয়েছে তা সত্যিই বলা মুশকিল।

তবে আমি অনুমান করব যে এটির BULK INSERT/ SqlBulkCopy/ বিসিপি / OPENROWSET(BULK ...)কাউকে কিছু করার অনুমতি দেওয়ার সাথে সম্ভবত কিছু করার আছে :

নিষ্ক্রিয় সীমাবদ্ধতার ( CHECK, DEFAULT, এবং FOREIGN KEYআমি বিশ্বাস করি)
ট্রিগারগুলি অক্ষম করুন (যদি সেখানে অডিট ট্রিগারগুলি থাকে তবে তাদের পাশ দিয়ে সম্ভবত অনাকাঙ্ক্ষিত হিসাবে বিবেচিত হবে; এই বিশেষ বিষয়ে আরও ব্যাখ্যা করার জন্য দয়া করে @ ডিভিকে উত্তর দেখুন )

নিম্নলিখিত ডকুমেন্টেশনে বিভিন্ন অপশন বর্ণিত হয়েছে:

@RDFozz দ্বারা উল্লিখিত টেবিল লকিংয়ের বিষয়টি আমি উল্লেখ করি নি যেহেতু এটি নির্দিষ্ট নয় BULK INSERT: যে কেউ একটি ট্যাবলেট / এক্সলোক টেবিল করতে পারেন বা এতে সেট করতে TRANSACTION ISOLATION LEVELপারেন SERIALIZABLE।

হালনাগাদ

আমি অতিরিক্ত দুটি টুকরো তথ্য পেয়েছি যা এটিকে সংকীর্ণ করতে সহায়তা করতে পারে:

নিষ্ক্রিয় ট্রিগারসমূহ, নিষ্ক্রিয় সীমাবদ্ধতাসমূহ, এবং সেট করতে সক্ষম হচ্ছে সমস্যা IDENTITY_INSERT ONপারে না দেখতে একটি অপ্রতিরোধ্য কারণ হতে ADMINISTER BULK OPERATIONS, ADMINISTER DATABASE BULK OPERATIONSঅথবা (SQL সার্ভার 2017 দিয়ে শুরু) bulkadminএকটি হুমকি হিসেবে সার্ভার ভূমিকা। কারণটি হ'ল সবে উল্লিখিত এই তিনটি জিনিসের যে কোনও একটি করতে ব্যবহারকারীর ALTER TABLEসেই টেবিলটিতে বা সারণীতে যে স্কিম রয়েছে তার উপর অনুমতি থাকা দরকার Ow মালিকানা শৃঙ্খলাবদ্ধকরণ ডিডিএল সংশোধন করে না। সুতরাং, যদি ব্যবহারকারী না থাকে ALTER TABLEতবে এই তিনটি জিনিস করার ক্ষমতাটি একটি নন-ইস্যু।
কি এতদূর আলোচনা করা যাবে না, এবং কি শেষ পর্যন্ত হতে পারে নিরাপত্তা ইস্যু উভয় এবং এক্সেস বৈদেশিক সম্পদ, এসকিউএল সার্ভার বাইরে। উইন্ডোজ লগইনের মাধ্যমে এসকিউএল সার্ভার অ্যাক্সেস করার সময়, ফাইল সিস্টেম অ্যাক্সেস করার জন্য উইন্ডোজ অ্যাকাউন্টটি ছদ্মবেশ ধারণ করা হবে (এমনকি আপনি যদি সুরক্ষা প্রসঙ্গটি ব্যবহার করেও ব্যবহার করেন )। এর অর্থ হল যে আপনি কেবল সেই ফাইলগুলি পড়তে পারবেন যা আপনাকে পড়ার অনুমতি দেওয়া হয়েছে। কিছুতেই ভুল নেই।BULK INSERTOPENROWSET(BULK...EXECUTE AS LOGIN='...'

কিন্তু, যখন কোনও এসকিউএল সার্ভার লগইনের মাধ্যমে এসকিউএল সার্ভারটি অ্যাক্সেস করেন তখন বাহ্যিক অ্যাক্সেসটি এসকিউএল সার্ভার পরিষেবা অ্যাকাউন্টের প্রসঙ্গে করা হয়। এর অর্থ হ'ল এই অনুমতি সহ কেউ এমন ফাইলগুলি পড়তে পারেন যা তাদের অন্যথায় পড়তে না পারা উচিত এবং ফোল্ডারে যাতে তাদের অ্যাক্সেস না করা উচিত।

সর্বনিম্ন, যদি এসকিউএল সার্ভারটি কেবল এসকিউএল সার্ভারের জন্য তৈরি অ্যাকাউন্ট হিসাবে চালিত করার জন্য সেট আপ করা হত (পছন্দসই পদ্ধতি), তবে এই জাতীয় ব্যবহারকারীর কেবল "এসকিউএল সার্ভার" অ্যাকাউন্টটিতে অ্যাক্সেস থাকা ফাইলগুলি পড়তে পারত। যদিও এটি একটি সীমাবদ্ধ সমস্যা, তবুও এটি এসকিউএল সার্ভার লগ ফাইলগুলির মতো ফাইলগুলি পড়ার অনুমতি দেয় (এবং আমি নিম্নলিখিত উদাহরণটি পরীক্ষা করেছিলাম এবং এটি কাজ করে):
```
SELECT tmp.[Col1]
FROM   OPENROWSET(BULK
   N'C:\Program Files\Microsoft SQL Server\MSSQLxx.InstanceName\MSSQL\Log\ERRORLOG.1',
                  SINGLE_NCLOB) tmp([Col1]);
```
বেশিরভাগ লোকের এমএসএসকিউএল \ লগ ফোল্ডারে অ্যাক্সেস থাকবে না , সুতরাং এটি বিদ্যমান সুরক্ষা নিষেধাজ্ঞাগুলি রোধ করার উপায়।

এবং, যদি এসকিউএল সার্ভার Local Systemঅ্যাকাউন্ট হিসাবে চলমান থাকে তবে আমি সন্দেহ করি যে সমস্যার ব্যাপ্তি কেবলমাত্র বৃদ্ধি পেয়েছে এবং এই অনুমতি থাকা কোনও ব্যবহারকারী সিস্টেম-সম্পর্কিত ফাইলগুলির বিস্তৃত পাঠ করতে সক্ষম হবেন।

এবং, সম্ভবত এই কারণেই বাল্ক আমদানি করার অন্যান্য পদ্ধতিগুলি - বিসিপি এবং SqlBulkCopy- এর bulkadminঅনুমতি / ভূমিকা প্রয়োজন হয় না : এগুলি এসকিউএল সার্ভারের বাইরে শুরু করা হয়েছিল এবং তারা নিজেরাই ফাইল সিস্টেমের অনুমতিগুলি পরিচালনা করবে। এই ক্ষেত্রে, এসকিউএল সার্ভার কখনই ফাইলটি পড়ে না (বা এসকিউএল সার্ভারের বাইরে পৌঁছায়), এটি কেবলমাত্র বাহ্যিক প্রক্রিয়া দ্বারা পঠিত ফাইলটি থেকে আমদানির জন্য ডেটা গ্রহণ করে।

সম্ভাব্য প্রভাবগুলি একদিকে রেখে, প্রশ্নটিতে বলা হয়েছিল:

কোনও অ্যাপ্লিকেশনটির সুবিধার জন্য, বাল্ক ইনসার্ট অনেক বেশি দক্ষ, দ্রুত, ..

আচ্ছা, তারপর...

এবং প্রোগ্রামারকে এসকিউএল এর বাইরে ফাইলগুলি বিশ্লেষণের প্রয়োজন থেকে মুক্তি দেয়।

ওহ নেলি। আসুন এখানেই থামি। পার্স করার জন্য টি-এসকিউএল সাধারণত ভাষার সেরা পছন্দ নয়। ডিবিতে জিনিস .োকানোর আগে পার্সিং করা ভাল। এটি করার একটি উপায় হ'ল টেবিল-মূল্যবান প্যারামিটার (টিভিপি) ব্যবহার করা। দয়া করে অন্য একটি প্রশ্নের আমার উত্তরটি দেখুন (এখানে ডিবিএ.স্ট্যাকএক্সচেঞ্জে) বলা হয়েছে যে প্রাক-পার্সিং এবং বৈধকরণের বিষয়টির সাথে দক্ষ তথ্য বাল্ক আমদানির দক্ষতার সাথে আলোচনা করে:

টি-এসকিউএল: সিএসভি-> কাস্টম পার্সড সংখ্যাসূচক ডেটা, দেখার মান সহ টেবিল পাইপলাইন

— সলোমন রুটজকি
সূত্র

জায়গায় প্রতিলিপি সঙ্গে বাল্ক সন্নিবেশ জন্য অতিরিক্ত বিবেচনা করা হবে।

— mustaccio

6

এটি পূর্ববর্তী উত্তরে ("... ট্রিগারগুলি অক্ষম করুন ") এ জাতীয় ধরণের ইঙ্গিত দেওয়া হয়েছিল , তবে কেন অক্ষম করা ব্যবসায়ের দিক থেকে অপ্রয়োজনীয় হবে তা ব্যাখ্যা করে না ।

অনেক ব্যবসায়, প্রধান টেবিলের উপর ট্রিগার ব্যবহার করা হয়:

অখণ্ডতার সীমাবদ্ধতাগুলি বৈধ করুন (ব্যবসায়িক যুক্তিযুক্ত ব্যক্তিরা সাধারণত ডিবি সীমাবদ্ধতায় ব্যবহৃত হয় তার চেয়ে বেশি জটিল)
আরও গুরুত্বপূর্ণ, ডেটা নিরীক্ষণের জন্য, বিশেষত সংশ্লিষ্ট নিরীক্ষণ সারণিতে ডেটা toোকাতে (বা প্রধান সারণীতে অডিট ক্ষেত্রগুলি আপডেট করতে হবে)।

প্রাক্তনদের সমস্যাগুলি কী তা বরং এটি সুস্পষ্ট (আপনার অ্যাপ্লিকেশনটি খারাপ ডেটা sertোকাতে দায়বদ্ধ যার প্রবাহ প্রক্রিয়াজাতকরণে নেতিবাচক প্রভাব ফেলে। যতক্ষণ পরের দিকে, যদি কোনও ট্রিগার অক্ষম থাকে তবে আপনার কাছে অডিটিং সম্পর্কিত কোনও তথ্য নেই যা নিরীক্ষার দৃষ্টিকোণ থেকে দুটি সমস্যা সৃষ্টি করে:

প্রথমত, গোষ্ঠী হিসাবে নিরীক্ষণ আর ডেটা পরিবর্তনগুলি নিরীক্ষণ করতে পারে না এবং এইভাবে অভ্যন্তরীণ নিরীক্ষা হিসাবে তাদের প্রাথমিক কার্য সম্পাদন করতে অক্ষম।
দ্বিতীয়ত, নিরীক্ষণের রেকর্ডের অভাব অডিটিং প্রয়োজনীয়তার লঙ্ঘন হতে পারে যে কোনও সংস্থা পরিচালিত হয় (যেমন এসএএস 70) - যা আপনার সংস্থাটিকে চুক্তি লঙ্ঘনের জন্য দায়বদ্ধ করে তুলতে পারে।

— DVK
সূত্র

হাই! আমি এখানে কী অনাকাঙ্ক্ষিত তা আপনার বর্ণনার সাথে একমত নই, এবং আমি বিশদটির প্রশংসা করি, তবে কেবল রেকর্ডের জন্য, আমি আমার উত্তরে বলেছি যে অডিট ট্রিগারগুলি থাকলে অকার্যকর ট্রিগারগুলি অনাকাঙ্ক্ষিত হবে। সত্য, এটি কোনও বিশদ ব্যাখ্যা নয়, তবে এটি সঠিকভাবে বলা যায় না যে এটি "ব্যাখ্যা করা হয়নি"। সম্ভবত এটি আরও সরল ছিল, বা নিরীক্ষার ট্রিগারগুলির বিষয়ে যথেষ্ট ব্যাখ্যা সরবরাহ করেনি, এবং বৈধতা (এবং এটির উল্লেখ করার জন্য এবং +1 সামগ্রিকভাবে অতিরিক্ত বিশদ জন্য) উল্লেখ করেনি better শুধু একটি ভাবনা.

— সলোমন রুটজকি

@ সলোমনরুতজকি - আমি বিশেষভাবে ইঙ্গিত দিয়েছি যে উত্তরটি " কারণ ব্যাখ্যা করে না " কেন এটি একটি সমস্যা :) যদি আপনি কোনও ব্যবসায়ের সমস্যার সংজ্ঞা দিতে না পারেন; প্রযুক্তিগত বিবরণগুলি প্রায়শই অপ্রাসঙ্গিক হয়, বিশেষত ওপি-র যারা আইএর সাথে ব্যবসা-ভিত্তিক আলোচনা করছেন to অন্য কথায়, যদি তারা বলে "ওহ, নিরীক্ষণ ট্রিগারগুলি অক্ষম হতে পারে", আইএ জিজ্ঞাসা করবে " তাত আমাদের জন্য কী বোঝায় ?" - তারা সাধারণত ডিবিএ বা বিকাশকারী হয় না।

— ডিভিকে

ঠিক আছে. আমি অনুমান করি যে আমি কেবল প্রথম বাক্যটি এই বলে পড়েছি যে "অন্যান্য উত্তরগুলি ট্রিগারগুলি অক্ষম করার বিষয়ে উল্লেখ করা হয়েছে তবে এটি কেন ব্যাখ্যা করা হয়নি"। এবং হ্যাঁ, আমি সাধারণত আপনার সাথে এই সমস্যাটিকে সঠিকভাবে সংজ্ঞায়িত করার প্রয়োজনীয়তার সাথে একমত হই, আমি ধরে নিচ্ছিলাম (সম্ভবত সর্বদা সেরা নীতি নয় ;-) যে ওপি একটি অডিট প্রক্রিয়াটি নিষ্ক্রিয় করার অর্থ বোঝে। আমি যদি ভুল হয়, তবে ধন্যবাদ যে আপনি এখানে তথ্য সরবরাহ করেছেন। এবং তাই আমি এই উদ্দেশ্যে এর সাথে লিঙ্ক করার জন্য আমার উত্তরটি আপডেট করেছি :)

— সলোমন রুটজকি

6

অপর সম্ভাবনা হ'ল BULK INSERTঅপারেশন চালানোর প্রভাব ।

সাধারণত, এই ধরণের জিনিসটি যখন সম্ভব হয় তখন ঘন্টাখানেক চালানো হত, যাতে স্বাভাবিক ক্রিয়াকলাপে হস্তক্ষেপ না হয়। একটি বাল্ক সন্নিবেশ অন্য সন্নিবেশগুলি ঘটতে বাধা দেয় (সেইসাথে নির্বাচন করুন, আপডেট করুন বা মুছুন) কয়েক ঘন্টা ধরে কোনও টেবিল লক করতে পারে।

বা, সুরক্ষার দৃষ্টিকোণ থেকে, এটি কোনও ডস আক্রমণের মতোই একই রকম ফলাফল তৈরি করতে পারে।

স্বীকারোক্তিহীনভাবে, কোনও এটি ঘটনাক্রমে বা ইচ্ছাকৃতভাবে লেনদেন এবং সাধারণ INSERTবিবৃতি দিয়ে এটি করতে পারে। তবে উদ্দেশ্যে হিসাবে একটি বাল্ক সন্নিবেশ প্রক্রিয়া ব্যবহার এই প্রভাবের কারণ হতে পারে।

সাধারণত, আমি প্রত্যাশা করতাম যে কোনও ডিবিএ অফ-ঘন্টা কার্যক্রম পরিচালনা করার সাথে জড়িত থাকবে, কারণ তাদের ব্যাকআপ এবং অন্যান্য নির্ধারিত কাজগুলি সম্পূর্ণরূপে নিশ্চিত করা দরকার complete লোকেরা যদি এই জাতীয় ক্রিয়াকলাপের জন্য পর্যাপ্ত বিবেচনা না করে এই ধরণের জিনিসটি নির্ধারণ করে, আপনি ব্যাকআপগুলি ব্যর্থ দেখতে পেয়েছিলেন - এটি বেশ কয়েকটি কারণে সমস্যা হতে পারে।

— RDFozz
সূত্র

2

এর একটি কারণ লগিং অ্যাকশনগুলি পরিষ্কার করে দেওয়া হতে পারে। যদি প্রতিটি ক্রিয়া লগ ফাইলে একটি প্রবেশের সাথে সঙ্গতিপূর্ণ হয়, তবে কোনও অতিরিক্ত রেফারেন্স ছাড়াই কোনও সমস্যার কারণ দেখা দেওয়ার পক্ষে এটি মোটামুটি তুচ্ছ। যদি আপনার লগ ফাইলটি বহিরাগত.ফায়াল ছাড়াই "ইনসার্ট থেকে বাহ্যিক। ফাইল" বলে, আপনি আরও কিছু বলতে পারবেন না।

অবশ্যই, আপনি লগিং কীভাবে কাজ করে তা সংশোধন করতে পারেন, তবে একটি সূচনা পয়েন্ট হিসাবে, লগিংয়ের মধ্যেও প্রতিটি ক্রিয়াকে পারমাণবিক হতে বাধ্য করা কোনও ভয়ানক ধারণা নয়।