AWS Client VPN-এর নিয়মগুলো রিসোর্সে থাকে, সাবনেটে নয়
দ্বিতীয় সাবনেট কোনো পোর্ট সীমিত করে না। নিয়মটি রিসোর্সের নিরাপত্তা গ্রুপে রাখুন এবং endpoint-এর সংযুক্তি গ্রুপকে উৎস হিসেবে ব্যবহার করুন।
কর্মীদের VPC-তে একটি অ্যাপ্লিকেশনে পৌঁছাতে হবে এবং একই ইনস্ট্যান্সের ডেটাবেস লিসেনারে পৌঁছানো যাবে না, তাই কেউ VPN endpoint-এর জন্য দ্বিতীয় একটি পাবলিক সাবনেট যোগ করে প্রয়োজন পূরণ হয়েছে বলে ঘোষণা করে। সাবনেটের অবস্থান রাউটিং ও প্রাপ্যতা বদলায়। এটি একটি পোর্টও দেয় না বা আটকায় না। প্রয়োজন প্রকাশকারী অনুমতিটি গন্তব্যে, রিসোর্সের নিরাপত্তা গ্রুপে থাকে, এবং VPN সীমা সেই হ্যান্ডেল দেয় যেটি ওই নিয়ম উল্লেখ করে।
সাবনেটের অবস্থান রাউটিং, অনুমোদন নয়
endpoint-এর নেটওয়ার্ক সংযুক্তি কোথায় আছে তা নির্ধারণ করে কোন রুট টেবিল ক্লায়েন্ট ট্রাফিক বহন করে এবং কোন প্রাপ্যতা অঞ্চল ব্যর্থতা সহ্য করে। কোন ইনস্ট্যান্সের কোন পোর্টে ওই ট্রাফিক পৌঁছাতে পারে তা এটি কিছুই বলে না। একই সাবনেটে সংযুক্ত দুই ক্লায়েন্ট এখনও একই উৎস পরিচয় নিয়ে আসে, এবং রিসোর্স সাবনেটের নাম দিয়ে তাদের আলাদা করতে পারে না।
বরং প্রয়োজন থেকে শুরু করুন: কে কল করে, কোন রিসোর্স, কোন পরিষেবা পোর্ট এবং কোন দিক। তারপর এমন নিয়ম মডেল বাছুন যা ওই চারটি বিষয় গন্তব্যে প্রকাশ করতে পারে। এই কাঠামো সাধারণত অতিরিক্ত সাবনেটকে ডিজাইন থেকে সম্পূর্ণ সরিয়ে দেয়।
Client VPN সংযুক্তি গ্রুপই সেই হ্যান্ডেল
সাবনেট-সংযুক্ত AWS Client VPN endpoint-এর জন্য নথিভুক্ত ব্যবস্থা নির্দিষ্ট। উদ্দিষ্ট নিরাপত্তা গ্রুপ endpoint-এর লক্ষ্য নেটওয়ার্ক সংযুক্তিতে প্রয়োগ করুন, তারপর সেই Client VPN গ্রুপকে উৎস হিসেবে ব্যবহার করে রিসোর্সের নিরাপত্তা গ্রুপে প্রয়োজনীয় ট্রাফিক অনুমোদন করুন।
সুনির্দিষ্টভাবে, অ্যাপ্লিকেশন ইনস্ট্যান্সের গ্রুপ সংযুক্তি গ্রুপ থেকে অ্যাপ্লিকেশন পোর্টকেই অনুমোদন করে, আর কিছু নয়। AWS-এর রিসোর্স অ্যাক্সেস পদ্ধতি এই সম্পর্ক বর্ণনা করে, এবং endpoint যে প্রতিটি সাবনেটে সংযুক্ত হয় সেখানে একই গ্রুপ নীতি রাখা উচিত, কারণ ভিন্ন গ্রুপের সাথে পুরনো সংযুক্তি সীমাটি নিঃশব্দে প্রশস্ত করে।
ওই নিয়ম কাউকে প্রমাণায়ন করে না। লগইন একটি পৃথক নিয়ন্ত্রণ, এবং রিসোর্সের পথ তৃতীয়টি। অনুরোধ আসার আগে তিনটিই সত্য হতে হবে। কোনটি ব্যর্থ হয় তা নির্ধারণ করে কোন সংশোধন সঠিক, এবং নিয়ম পরিবর্তন কেবল প্রথমটির জন্য সঠিক উত্তর।
একটি সংযুক্তি গ্রুপ যা আলাদা করতে পারে না
একই সংযুক্তি গ্রুপের পেছনের প্রতিটি ক্লায়েন্ট একই নিরাপত্তা গ্রুপ উৎস হিসেবে রিসোর্সে পৌঁছায়। ভিন্ন ভূমিকার দুই ব্যবহারকারী ওই স্তরে আলাদা করা যায় না, গ্রুপের নাম বা ট্যাগ যা-ই হোক। Client VPN-এর বাহ্যিক গ্রুপ অনুমোদন ডিরেক্টরি বা SAML গ্রুপের জন্য গন্তব্য উপসর্গ অনুযায়ী অ্যাক্সেস সীমিত করে, যা রিসোর্স ভূমিকার চেয়ে মোটা এবং পরিচয় ব্যবস্থা নয়, নেটওয়ার্ক সীমা হিসেবে বিবেচনা করা উচিত।
সূক্ষ্ম পার্থক্য অ্যাপ্লিকেশনের। বেশিরভাগ কর্মীর কাছে বন্ধ থাকা উচিত এমন ডেটাবেস লিসেনারকে গ্রুপ সদস্যপদ পরিপাটি থাকবে বলে আশা করার চেয়ে অনুমোদিত উপসর্গে একেবারেই পৌঁছানো না যাওয়ার মাধ্যমে ভালোভাবে সুরক্ষিত করা যায়।
গ্রুপের নাম বদলালে পরিচয় তৈরি হয় না, এবং প্রতিটি দলের জন্য এটি নকল করলে কেবল নিরীক্ষণযোগ্য সংযুক্তি বাড়ে।
ওই নিয়ম প্রতিটি VPN ডিজাইনে কপি করবেন না
স্ব-ব্যবস্থাপিত EC2 VPN গেটওয়ে, রাউট করা পরিদর্শন যন্ত্র এবং ব্যবস্থাপিত Client VPN তিনটি ভিন্ন প্যাকেট পথ। কোন উৎস ঠিকানাটি সত্যিই রিসোর্সে পৌঁছায়, মাঝপথে অনুবাদ হয় কি না এবং ওই পথে সেবাটি কোন রেফারেন্স পদ্ধতি সমর্থন করে তা নির্ধারণ করুন।
মধ্যবর্তী যন্ত্রের মধ্য দিয়ে ট্রাফিক পাঠানো সরাসরি ইনস্ট্যান্স-থেকে-ইনস্ট্যান্স ট্রাফিকের মতো উৎস নিরাপত্তা গ্রুপ রেফারেন্স রক্ষা করে না। AWS নথিভুক্ত করে যে এমন ডিজাইনে গ্রুপ রেফারেন্সের বদলে উপযুক্ত ব্যক্তিগত উৎস ঠিকানা বা CIDR প্রয়োজন হতে পারে। ব্যবস্থাপিত Client VPN পদ্ধতি এই প্রমাণ নয় যে প্রতিটি গেটওয়ের সংযুক্ত গ্রুপ পাঠানো প্যাকেটের জন্য সর্বজনীন পরিচয় টোকেন হিসেবে কাজ করে।
পথে একটি NAT হপই অনুমান ভাঙতে যথেষ্ট, এবং ব্যর্থতা এমন নিয়মের মতো দেখায় যা আছে কিন্তু কখনও মেলে না।
কার্যকর সীমা পর্যালোচনা করুন
রিসোর্সের সাথে সংযুক্ত প্রতিটি নিরাপত্তা গ্রুপ পড়ুন, কারণ অনুমোদন নিয়ম একত্র হয় এবং সংকীর্ণ নিয়ম অন্য গ্রুপের প্রশস্ত নিয়ম বাতিল করে না। তারপর নেটওয়ার্ক ACL, হোস্ট ফায়ারওয়াল এবং অ্যাপ্লিকেশনের নিজস্ব অনুমোদন যাচাই করুন, যেগুলো পৃথক ভুলযুক্ত পৃথক স্তর।
একই রিসোর্সের বিরুদ্ধে একটি অনুমোদিত ও একটি সচেতনভাবে বাদ দেওয়া অনুরোধ দিয়ে শেষ করুন। ওই জোড়া সীমা প্রমাণ করে, অন্যদিকে একটি সফল সংযোগ কেবল কিছু খোলা আছে তা প্রমাণ করে। endpoint ধারণ করা সাবনেটের বদলে পথ, কার্যকর উৎস এবং উদ্দিষ্ট পরিষেবা পোর্ট নিশ্চিত করুন।
কর্মের ক্রম: চার-ভাগের প্রয়োজন লিখুন, গ্রুপটি সংযুক্তিগুলোতে যুক্ত করুন, রিসোর্স নিয়মটি পোর্টে সীমাবদ্ধ করুন, একটি অনুমোদন ও একটি অস্বীকৃতি যাচাই করুন, এবং তারপরেই রাউটিং কারণে সাবনেট ভাগ করার কথা ভাবুন।