VPC রিমোট অ্যাক্সেস গ্রহণে প্রত্যাখ্যান পরীক্ষা দরকার

রিমোট অ্যাক্সেসের গ্রহণ হলো প্রত্যাশিত ফলাফলের একটি সারণি, কোনো কর্মক্ষম পৃষ্ঠার স্ক্রিনশট নয়। প্রতিটি গ্রুপের জন্য লিখুন কী সফল হওয়া উচিত এবং কী ব্যর্থ হওয়া উচিত, তারপর নিয়ন্ত্রিত সময়সীমার মধ্যে নিবেদিত পরীক্ষা পরিচয় ব্যবহার করে দুটোই চালান। প্রত্যাখ্যানগুলোই সেই অংশ যা সীমানা প্রমাণ করে; সফল লগইন কেবল টানেলের অস্তিত্ব প্রমাণ করে। এই সবই ইতিমধ্যে নির্বাচিত VPN পণ্যের সঙ্গে কাজ করে।

পরীক্ষার জন্য আলাদা অ্যাকাউন্ট ব্যবহার করুন এবং সেগুলো এমনভাবে লেবেল করুন যাতে কেউ পরীক্ষা পরিচয়কে প্রকৃত ব্যতিক্রম ভুল না করে।

সীমানা প্রত্যাশিত ফলাফল হিসেবে লিখুন

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

নেটওয়ার্ক পথ থেকে আলাদাভাবে ডেটাবেস লগইন পরীক্ষা করুন। একটি পৌঁছানোযোগ্য TCP পোর্ট অননুমোদিত ডেটাবেস অ্যাকাউন্টকে সফল করানো উচিত নয়, এবং VPN সদস্যপদ কোনো ক্লাউড IAM ভূমিকা তৈরি বা প্রশাসনিক API অ্যাক্সেস দেওয়া উচিত নয়। এগুলো তিনটি স্বাধীন নিয়ন্ত্রণ, এবং তারা স্বাধীনভাবেই ব্যর্থ হয়।

রুট মানে অনুমোদন নয়

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

এই কারণেই প্রত্যাখ্যান পরীক্ষাগুলো সার্ভার দিককে লক্ষ্য করে: ওই ফলাফল ক্লায়েন্ট সম্পাদনা করে বদলানো যায় না।

নিয়ন্ত্রণ আসলে কোন উৎস দেখে?

নিয়ন্ত্রণ যে উৎস ঠিকানা মূল্যায়ন করে তা গেটওয়ে স্থাপত্যের উপর নির্ভর করে। EC2-হোস্টেড গেটওয়ে রাউটেড পুল ফরওয়ার্ড করতে পারে, নিজের ঠিকানায় রূপান্তর করতে পারে, অথবা NAT-এর পরে ভিন্ন ঠিকানা উপস্থাপন করতে পারে; ম্যানেজড Client VPN একটি সাবনেটের সঙ্গে সংযুক্ত হয় এবং নিজস্ব মডেল অনুসরণ করে। সিকিউরিটি গ্রুপ ও নেটওয়ার্ক ACL সেই প্রক্রিয়ার পরে যা আসে তা দেখে। ভুল উৎস অনুমানের বিরুদ্ধে নিয়ম যাচাই করা এমন সীমানা তৈরির একটি সাধারণ উপায় যা সঠিক দেখায় কিন্তু ভুল ট্রাফিক প্রবেশ করায়।

প্রতিটি ফলাফলকে সবচেয়ে ছোট উপযোগী ঘটনার সঙ্গে সম্পর্কিত করুন: পরিচয় ও সেশন, সম্পদ, ক্রিয়া, সময় এবং সিদ্ধান্ত। CloudTrail API কল, VPC ফ্লো রেকর্ড এবং VPN সেশন লগ ভিন্ন প্রশ্নের উত্তর দেয়, এবং এর কোনোটিই একা কোনো অ্যাপ্লিকেশন অডিট নয়।

পরিচয় প্রত্যাহার করুন এবং আবার পরীক্ষা করুন

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

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

সারণিটি ডিপ্লয়মেন্টের সঙ্গে রাখুন এবং গেটওয়ে বদলালে আবার চালান। পরীক্ষাগুলো সস্তা; তাদের পেছনের অনুমানগুলো নয়।