এখানে আপনার বেশ কয়েকটি ভিন্ন প্রশ্ন রয়েছে, তাই আমি স্বতন্ত্রভাবে তাদের ছিটকে যাব:
"আমি পড়েছি যে উইন্ডোজ প্রমাণীকরণ ব্যবহার করে ব্যবহারকারীদের সরাসরি সা লগইন ব্যবহার না করা একটি সেরা অনুশীলন"
আপনি এখানে দুটি জিনিস মিশ্রণ করছেন: এসএ ধারণা এবং এসকিউএল প্রমাণীকরণ এবং উইন্ডোজ প্রমাণীকরণের ধারণা।
এসকিউএল প্রমাণীকরণ হ'ল ব্যবহারকারীর নাম এবং পাসওয়ার্ডগুলির একটি তালিকা যা প্রতিটি এসকিউএল সার্ভারে সঞ্চিত থাকে। এটি এসকিউএল-এ সংরক্ষিত হওয়া প্রথম সমস্যা। আপনার যদি কোনও লগইনের পাসওয়ার্ড পরিবর্তন করতে হয় তবে আপনাকে এটি প্রতিটি সার্ভারে পরিবর্তন করতে হবে (বা বিভিন্ন সার্ভারে বিভিন্ন পাসওয়ার্ড বজায় রাখতে হবে)। উইন্ডোজ প্রমাণীকরণের সাহায্যে আপনি কেন্দ্রীয়ভাবে লগইন অক্ষম করতে পারেন, পাসওয়ার্ড পরিবর্তন করতে পারেন, নীতি সেট করতে পারেন ইত্যাদি etc.
আপনি যদি এসকিউএল প্রমাণীকরণ ব্যবহার করতে চান, তবে এসএ হ'ল একটি এসকিউএল প্রমাণীকরণ লগইন। এটি ডিফল্ট প্রশাসক ব্যবহারকারীর নাম, ঠিক যেমন প্রশাসক উইন্ডোজ প্রমাণীকরণে রয়েছে। এর এক উদাহরণে স্থানীয় পরাশক্তি রয়েছে, তবে সমস্ত দৃষ্টিতে বৈশ্বিক পরাশক্তি নয়।
"... এবং সেই অ্যাকাউন্টগুলিকে (বা অ্যাকাউন্ট গোষ্ঠীগুলি) সিসাদমিন সুবিধার অনুমতি দেওয়া হচ্ছে।"
প্রমাণীকরণের যে কোনও পদ্ধতি আপনি চয়ন করুন না কেন, আদর্শভাবে আপনি ন্যূনতম সুযোগ-সুবিধার নীতিটি অনুসরণ করতে চান: লোকদের তাদের কাজটি করার জন্য ন্যূনতম ন্যূনতম অধিকার প্রদান করা এবং আরও কিছু নয়।
এগুলিকে কেবল লগইন হিসাবে ভাবেন না - তারা এমন লোক যারা আপনাকে বহিষ্কার করতে পারে। যদি তারা ডেটাবেসটি ফেলে দেয় বা আপনার ব্যাকআপ কাজগুলি দুর্ঘটনাক্রমে অক্ষম করে, তবে তারা বরখাস্ত হবে না, কারণ ডিফল্টরূপে এসকিউএল কে করেছে কী তা ট্র্যাক করে না। আপনিই সেই ব্যক্তি যাকে বরখাস্ত করা হবে কারণ এটি ঘটতে চলেছে, এবং কোন ব্যক্তি এটি করেছে তা আপনি বলতে সক্ষম হবেন না।
"সেরা অনুশীলনটি কীভাবে আমার এসকিউএল সার্ভারের উদাহরণগুলির সুরক্ষা বাড়ায়?"
আপনি দুটি জিনিস করতে চান:
- সার্ভার ভাঙ্গা থেকে লোকদের থামান
- যখন তারা সার্ভারটি ভেঙে দেয়, তখন কে এটি করেছে তা সঠিকভাবে সনাক্ত করতে সক্ষম হন
প্রথমটি ন্যূনতম সুযোগ-সুবিধার নীতির সাথে সম্পন্ন হয়: লোকেরা কেবল তাদের প্রয়োজনীয় অনুমতি দেয়, এবং আরও কিছু না।
দ্বিতীয়টি প্রতিটি ব্যক্তিকে তাদের নিজস্ব লগইন দিয়ে ভাগ করে নেওয়া লগইন না দেওয়ার (যেমন সবাইকে একই ব্যবহারকারীর নাম / পাসওয়ার্ড ব্যবহার করতে দেওয়া) এবং আদর্শভাবে লগইনগুলি নিরীক্ষণের মাধ্যমে সম্পন্ন হয়। আপনি সম্ভবত এখনই শেষ অংশটি করবেন না, কারণ এটি একধরনের বেদনাদায়ক, তবে আসুন প্রথমে টুকরোগুলি রেখে দিন যাতে আপনি পরে অডিটিং যুক্ত করতে পারেন কেউ কোনও ডাটাবেস ড্রপ করার পরে এবং আপনার বস কেন এটি জানতে চান।
আপনি কী ভাবছেন তা আমি জানি: "তবে আমরা অ্যাপ্লিকেশনগুলি কোডিং করছি এবং অ্যাপটির জন্য একটি লগইন প্রয়োজন।" হ্যাঁ, অ্যাপ্লিকেশনটিকে তার নিজস্ব লগইন দিন, এবং বিকাশকারীদের সেই পাসওয়ার্ডটি জানা উচিত, তবে সেই লগইনটিকে অনুমতিগুলি এমনভাবে ছিনিয়ে নেওয়া উচিত যাতে তাদের সঠিক মনে কেউই এটি ব্যবহার করতে চায় না। উদাহরণস্বরূপ, এটি db_datareader এবং db_datawriter ভূমিকা একা থাকতে পারে, অন্য কিছুই। এইভাবে এটি ডেটা inোকাতে, আপডেট করতে, মুছতে এবং নির্বাচন করতে পারে তবে স্কিমার পরিবর্তন, সূচিপত্র যুক্ত করা, সঞ্চিত পদ্ধতি পরিবর্তন করা ইত্যাদি প্রয়োজনীয় নয় not
"এটি কি কেবলমাত্র উত্পাদন দৃষ্টান্তগুলিতে বা আমাদের অভ্যন্তরীণ বিকাশের উদাহরণগুলিতে প্রযোজ্য?"
আমি মনে করি এটি বিকাশের উদাহরণগুলিতে ঠিক তেমন প্রযোজ্য কারণ আমি সাধারণত মানুষকে জিনিস ভাঙার বিষয়ে চিন্তিত। লোকেরা কেবল উন্নয়নে সার্ভার ভাঙতে পছন্দ করে। এবং অবশ্যই, যখন উত্পাদনে স্থানান্তরিত হওয়ার পরিবর্তনের তালিকাগুলি বান্ডিল করার সময় হয়েছে তখন আমার জানতে হবে যে কোনও নির্দিষ্ট সূচকটি অ্যাপ্লিকেশনটির পক্ষে সত্যই গুরুত্বপূর্ণ কিনা বা কোনও হোনহেড কেবল ডেটাবেস টিউনিং অ্যাডভাইজারকে চালিত করে এবং সমস্ত পরিবর্তন প্রয়োগ করতে বলেছিল । যথাযথ অনুমতিগুলি এই ব্যথা হ্রাস করতে সহায়তা করে।