TLS, নেটওয়ার্ক প্রবেশ ও SQL অনুমতিগুলো ভিন্ন প্রশ্নের উত্তর দেয়
সংযোগ সাঁজোয়া করা, একটি উৎসকে অনুমতি দেওয়া এবং একটি টেবিল দেওয়া তিনটি সিদ্ধান্ত। TLS একটি VPN-এর বিকল্প হতে পারে কি না জিজ্ঞাসা করার আগে সেগুলো ক্রমে দেখুন।
কেউ একজন গ্রাহককে PostgreSQL লগইন দেওয়ার প্রস্তাব দেয় যাতে একটি ব্যয়ের দাবি শুরু থেকে শেষ পর্যন্ত সাঁজোয়া অবস্থায় যায়। ডেটাবেস প্রশাসকের সত্যিকারের SQL সেশন প্রয়োজন, আর অন্য কেউ বদলে একটি ওয়েব ফর্মের প্রস্তাব দেয়। দুটি প্রস্তাবই ভুল সমস্যার সমাধান করে, কারণ কোনোটিই গ্রাহক আসলে যে কাজটি করে তা থেকে শুরু করেনি। তিনটি সিদ্ধান্ত ক্রমে দেখুন, আর TLS একটি VPN-এর বিকল্প হতে পারে কি না সেই প্রশ্ন নিজেই উত্তর দেবে।
গ্রাহকের প্রয়োজনীয় কাজটি থেকে শুরু করুন
গ্রাহককে কী অর্জন করতে হবে তা লিখে রাখুন। একটি দাবি জমা দেওয়া, রিপোর্টের একটি সারি পড়া এবং তাৎক্ষণিক কোয়েরি চালানো তিনটি ভিন্ন কাজ, যার তিনটি ভিন্ন ঝুঁকির ধরন।
তারপর লিখুন কে অনুরোধ করছে। একজন গ্রাহক, একজন সহায়তা এজেন্ট ও একজন প্রশাসক একই টেবিল স্পর্শ করলেও বিনিময়যোগ্য নয়। এই পার্থক্যই ঠিক করে গ্রাহক কোয়েরি ভাষার কতটা দেখা উচিত।
উত্তরের জোড়া ইন্টারফেস ঠিক করে। এর পরে সবকিছুই বাস্তবায়ন, আর সাঁজোয়া নিয়ে বেশিরভাগ বাদানুবাদ আসলে কোন ইন্টারফেস বাছা হয়েছে তা নিয়ে বাদানুবাদ।
তিনটি নিয়ন্ত্রণ, তিনটি সিদ্ধান্ত
প্রমাণিত TLS সংযোগ রক্ষা করে এবং কোন TLS পরিচয় গ্রহণযোগ্য তা ঠিক করে। নেটওয়ার্ক প্রবেশ ঠিক করে কোন উৎসগুলো শ্রোতার কাছে পৌঁছাতে পারে। ডেটাবেস অনুমোদন ঠিক করে একটি ভূমিকা কোন বস্তু ও কাজ ব্যবহার করতে পারে।
তিনটির কোনোটিই অন্যগুলোর বিকল্প নয়, যা টেবিলটি স্পষ্ট করে।
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
অন্য একটি সারি সরানোর আগে যে সারির উপর আপনি নির্ভর করছেন তা পড়ুন। এ ধরনের বেশিরভাগ নকশা ব্যর্থ হয় কারণ একটি নিয়ন্ত্রণ কনফিগার না করে ধরে নেওয়া হয়েছিল।
সরাসরি SQL ডেটাবেস নীতিকে দায়িত্বে রাখে
অনুমোদিত সরাসরি সংযোগের ক্ষেত্রে সেবা পরিচয় যাচাই ও ইচ্ছাকৃত প্রবেশ নীতি দুটোই রাখুন। TLS চালু করা সাঁজোয়া সংযোগ উপলব্ধ করে; প্রবেশ কনফিগারেশন hostssl এন্ট্রির মাধ্যমে না বললে এটি অসাঁজোয়া সংযোগ প্রত্যাখ্যান করে না।
এই পার্থক্যটি টেমপ্লেটে নয়, চলমান কনফিগারেশনে যাচাই করা উচিত। যে সার্ভার TLS দেয় ও সাধারণ টেক্সট গ্রহণ করে, সেটি সেই নকশা নয় যা বেশিরভাগ মানুষ ভাবে তারা স্থাপন করেছে। প্রবেশ নিয়ম পড়ুন এবং দেখুন কোন এন্ট্রিগুলো সত্যিই এটি দাবি করে। এই একটি যাচাই সাঁজোয়া-সক্ষম সার্ভারকে শুধু-সাঁজোয়া সার্ভার থেকে আলাদা করে।
শুধু কাজের প্রয়োজনীয় বিশেষাধিকারসহ ভূমিকা ব্যবহার করুন, এবং মালিকানা, উত্তরাধিকারসূত্রে পাওয়া সদস্যপদ ও ব্যাপকভাবে দেওয়া অনুমতি পর্যালোচনা করুন। PostgreSQL বিশেষাধিকার মডেল ডেটাবেস বস্তুর কর্তৃত্বের সীমা।
একটি VPN ডেটাবেস প্রমাণীকরণের আগেই কোন ডিভাইস সেবায় পৌঁছাবে তা সীমিত করতে পারে, আর একটি প্রবেশ গেটওয়ে অনুরূপ কিছু করতে পারে। কোনোটিই উন্মোচিত উপাদান রক্ষণাবেক্ষণ, প্রমাণপত্র ব্যবস্থাপনা ও সম্পদ ব্যবহার সীমিত করার প্রয়োজন মেটায় না।
ক্লায়েন্ট সার্টিফিকেট একটি প্রমাণপত্র, ACL নয়
একটি ক্লায়েন্ট সার্টিফিকেট সংযোগের সময় একটি শর্ত যোগ করতে পারে। clientcert সেটিং একটি বিশ্বস্ত সার্টিফিকেট এবং আরও কঠোর মোডে সার্টিফিকেটের নাম ও ডেটাবেস ব্যবহারকারীর মধ্যে সম্পর্ক দাবি করতে পারে।
এটি আরও শক্তিশালী প্রমাণপত্র। এটি অনুমোদনের তালিকা নয়, আর এটি সার্ভারকে অদৃশ্য করে না, কারণ সংযোগ গ্রহণকারী উপাদান এখনও নেটওয়ার্ক ট্রাফিক ও একটি হ্যান্ডশেক প্রক্রিয়া করে। সার্টিফিকেটকে প্রবেশ তালিকা হিসেবে দেখা প্রকৃত অনুমতিগুলোকে অপরিবর্তিত রাখে। এটি সার্টিফিকেট বিতরণ প্রসারিত করার প্রবণতাও রাখে, যা পরবর্তী সমস্যা তৈরি করে।
অতিরিক্ত বিশেষাধিকারপ্রাপ্ত ভূমিকায় যুক্ত একটি শক্তিশালী সার্টিফিকেট ভালোভাবে প্রমাণিত একজন প্রশাসক তৈরি করে। সার্টিফিকেট উদযাপন করার আগে ভূমিকাটি দেখুন।
যখন উপযুক্ত, সংকীর্ণ ইন্টারফেস বেছে নিন
একটি ব্যয়ের দাবির জন্য যে অ্যাপ্লিকেশন এন্ডপয়েন্ট দাবিটি গ্রহণ করে, ব্যবসায়িক নিয়ম প্রয়োগ করে এবং সেই ব্যবহারকারীর অনুমোদিত ফলাফল ফেরত দেয়, তা সাধারণ SQL অ্যাকাউন্টের চেয়ে কাজটিকে ভালোভাবে উপস্থাপন করে।
তারপর অ্যাপ্লিকেশনটি নিজের সীমিত ডেটাবেস পরিচয় ব্যবহার করে, আর গ্রাহক কখনও বৈশিষ্ট্য হিসেবে কোনো কোয়েরি ভাষা পান না। এটি ছোট পৃষ্ঠতল, ভুল হওয়ার কম উপায়।
এটি একটি নকশা বিকল্প, অ্যাপ্লিকেশন কোড স্বয়ংক্রিয়ভাবে নিরাপদ এই দাবি নয়। সেই কোডকে তার আহ্বানকারীদের প্রমাণ করতে, প্রতিটি কাজ অনুমোদন করতে ও তার ইনপুট যাচাই করতে হয়, আর তার নিজের ডেটাবেস অনুমতিগুলো এখনও গুরুত্বপূর্ণ।
সরাসরি SQL তাদের জন্য সঠিক থাকে যাদের অনুমোদিত কাজ এটি দাবি করে। সেই নকশাকে ভূমিকা, নেটওয়ার্ক পরিধি ও পরিচালনাগত সীমা দিয়ে নির্ধারিত করুন, আর অন্য ক্লায়েন্টরা সংকীর্ণ ইন্টারফেস রাখুক। দুই জনগোষ্ঠীকে এক ভূমিকায় মেশানোই যেখানে বাদানুবাদ শুরু হয়।