ডোমেইন ট্রাস্ট ছাড়াই Excel থেকে অংশীদারের SQL Server-এ

অন্য একটি প্রতিষ্ঠানের SQL Server-এ টেবিল খোলা একটি Excel ওয়ার্কবুকে তিনটি জিনিস লাগে, যেগুলো সাধারণত একটিই হিসেবে আলোচিত হয়: সার্ভার যে পরিচয় গ্রহণ করে, ক্লায়েন্ট যে পরিবহন যাচাই করে, এবং উভয় পক্ষ যে নেটওয়ার্ক পথ অনুমোদন করে। ডোমেইন ট্রাস্ট প্রথমটি পূরণের একটি উপায় এবং সবচেয়ে বিস্তৃত। TLS দ্বিতীয়টি পূরণ করে এবং প্রথমটি সম্পর্কে কিছুই বলে না। পথ তৃতীয়টি পূরণ করে এবং নিজে থেকে কিছুই রক্ষা করে না।

তিনটিকে আলাদা করলে স্প্রেডশিটটি প্রশাসনিক সম্পর্কের বদলে একটি ছোট, পর্যালোচনাযোগ্য অনুরোধে পরিণত হয়।

প্রশ্নটি যে তিনটি সিদ্ধান্ত লুকায়

পরিচয় হলো ডেটাবেস মনে করে আপনি কে: বিশ্বস্ত ডোমেইনের একটি Windows অ্যাকাউন্ট, নিজস্ব পাসওয়ার্ডসহ একটি SQL লগইন, বা সার্টিফিকেটভিত্তিক পরিচয়। পরিবহন হলো সেশনটি এনক্রিপ্টেড কি না এবং ক্লায়েন্ট সার্ভারের সার্টিফিকেট চেইন যাচাই করে কি না। পথ হলো প্যাকেট কীভাবে লিসেনারে পৌঁছায়, যা VPN, একটি প্রাইভেট লিংক বা ফায়ারওয়াল নিয়মসহ একটি পাবলিক এন্ডপয়েন্ট হতে পারে। প্রত্যেকটি আলাদা জায়গায় বাস করে এবং প্রত্যেকটি নিজে নিজেই ব্যর্থ হতে পারে।

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

ফরেস্ট ট্রাস্ট ছাড়া পরিচয়

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

কারও ব্যক্তিগত লগইনের বদলে একটি নিবেদিত অ্যাকাউন্ট পছন্দ করুন। স্প্রেডশিটে ভাগ করা শংসাপত্র হলো ঘটার অপেক্ষায় থাকা একটি সহায়তা সমস্যা, আর নামযুক্ত অ্যাকাউন্ট প্রকল্প শেষ হলে প্রত্যাহার সম্ভব করে।

এনক্রিপশন হ্যাঁ, তবুও সার্টিফিকেটে ভরসা?

ODBC Driver 18-এর সাথে Encrypt=Yes;TrustServerCertificate=No এমন একটি এনক্রিপ্টেড সেশন চায় যার সার্টিফিকেট সত্যিই যাচাই করা হয়। তখন সংযোগ স্ট্রিংকে অবশ্যই সেই সার্ভারের নাম দিতে হবে যা সার্টিফিকেটটি কভার করে, এবং ক্লায়েন্টকে তার চেইনে ভরসা করতে হবে। Driver 18 আগের সংস্করণের বিপরীতে ডিফল্টভাবেও এনক্রিপশন ব্যবহার করে, তাই একটি পুরোনো সংযোগ স্ট্রিং এখন না বলেই TLS-এ সমঝোতা করতে পারে। স্পষ্ট সেটিংস অভিপ্রেত নীতিকে সব মেশিনে দৃশ্যমান করে, যা গুরুত্বপূর্ণ যখন একাধিক ব্যক্তি একই ওয়ার্কবুক রক্ষণাবেক্ষণ করে।

TrustServerCertificate=Yes এনক্রিপ্ট করে এবং যাচাই এড়িয়ে যায়, যা নামের অমিল বা অবিশ্বস্ত চেইনের সমতুল্য প্রতিকার নয়। এটি সেই সংকেত সরিয়ে দেয় যা আপনাকে বলত ক্লায়েন্ট ভুল এন্ডপয়েন্টে পৌঁছেছে, তাই সার্টিফিকেট বা নামটি ঠিক করুন।

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

নেটওয়ার্ক পথই সুরক্ষা নয়

VPN-এর মাধ্যমে পৌঁছানো একটি প্রাইভেট লিসেনার এক্সপোজার কমায়, এবং এটি কাজ করতে VPN-কে সঠিক গন্তব্য ও ফেরতের রুট বহন করতে হবে। কাজ করা টানেল প্রমাণীকরণের প্রয়োজন বা সার্টিফিকেট যাচাই দূর করে না, আর TLS সীমাবদ্ধ করে না কোন দূরবর্তী সিস্টেম সংযোগের চেষ্টা করতে পারে। এগুলো তিনটি আলাদা পর্যবেক্ষণ: একটি TLS হ্যান্ডশেক, একটি VPN লগইন এবং একটি অনুমোদিত কোয়েরি। কেবল তৃতীয়টিই প্রমাণ করে ওয়ার্কবুকটি যে ডেটা পড়ার অনুমতি পেয়েছিল তা পড়েছে।

তাই ট্রাস্টের প্রশ্নের উত্তর ডেটাবেসকে ইন্টারনেটে উন্মুক্ত করে দেওয়ার শর্টকাট প্রতিরোধ করুন। সংকীর্ণ উত্তর সাধারণত একটি নিবেদিত অ্যাকাউন্ট, যাচাই করা এনক্রিপশন এবং একটি অনুমোদিত পথ, এই ক্রমে।

সাধারণ Excel কর্মপ্রবাহ দিয়ে যাচাই করুন: স্বীকৃত পরিচয়, কার্যকর অনুমতি এবং সমঝোতাকৃত এনক্রিপশন, প্রত্যেকটি সার্ভারের নিজস্ব সেশন ভিউ দিয়ে।