AWS Client VPN প্রমাণীকরণ: IAM অনুমতিগুলো লগইন পদ্ধতি নয়
কনসোলের অনুমতি কোনো টানেল প্রমাণীকরণ করে না। সার্টিফিকেট, AD ও SAML পদ্ধতি তুলনা করুন, তারপর দেখুন কখন SSM পোর্ট ফরওয়ার্ডিং একটি প্রাইভেট ডেটাবেসের জন্য উপযুক্ত।
একজন ব্যবহারকারীকে AWS Client VPN এন্ডপয়েন্ট তৈরি বা বর্ণনা করার অনুমতি দিলে সেই ব্যবহারকারী এর সাথে সংযোগ করতে পারেন না। এগুলো দুটি ভিন্ন ধরনের পরিচয়: IAM AWS API কল নিয়ন্ত্রণ করে, আর এন্ডপয়েন্ট কেবল তার উপর কনফিগার করা ক্লায়েন্ট-প্রমাণীকরণ পদ্ধতিগুলো গ্রহণ করে। তাই একজন ব্যবহারকারীর বিস্তৃত কনসোল অধিকার থাকতে পারে, তবুও VPN ক্লায়েন্টের কাছে উপস্থাপন করার মতো কিছু থাকে না। এন্ডপয়েন্ট কোন পদ্ধতিতে আস্থা রাখে তা নির্ধারণ করুন, তারপর আপনি যে অ্যাক্সেস দিচ্ছেন তার জন্য পূর্ণ টানেল সঠিক আকৃতি কি না তা ঠিক করুন।
API পরিচয় কোনো টানেল পরিচয় নয়
কেউ যখন বলেন «IAM রোল সংযুক্ত আছে, তবুও VPN কেন ব্যর্থ হচ্ছে», উত্তর সাধারণত এই যে সংযোগ প্রবাহের কোনো ধাপই সেই রোল পড়ে না। ক্লায়েন্ট একটি সার্টিফিকেট, একটি AD ব্যবহারকারীনাম ও পাসওয়ার্ড, বা একটি SAML দাবি উপস্থাপন করে। এন্ডপয়েন্ট এর একটি যাচাই করে তারপর একটি ঠিকানা বরাদ্দ করে।
IAM এখনও গুরুত্বপূর্ণ, কেবল পরে এবং অন্য জায়গায়: এন্ডপয়েন্ট তৈরি করা, সাবনেট সংযুক্ত করা, রুট প্রকাশ করা এবং অনুমোদন নিয়ম লেখা API কাজ। সেই অনুমতিগুলো যেসব অপারেটরের প্রয়োজন তাদের মধ্যেই সীমিত রাখুন, প্রত্যেক ব্যবহারকারীকে এন্ডপয়েন্টের অ্যাক্সেস নিয়ম পুনর্লিখনের ক্ষমতা দেওয়ার বদলে।
এন্ডপয়েন্ট যে পদ্ধতিগুলো সমর্থন করে তা থেকে বেছে নিন
AWS Client VPN সার্টিফিকেট-ভিত্তিক পারস্পরিক প্রমাণীকরণ, Active Directory প্রমাণীকরণ এবং SAML-ভিত্তিক ফেডারেটেড প্রমাণীকরণ গ্রহণ করে। আপনি যে ক্লায়েন্ট পদ্ধতিই বেছে নিন, একটি সার্ভার সার্টিফিকেট প্রয়োজন, আর যে কনফিগারেশন পদ্ধতি একত্র করে তার জন্য দুটোই সফল হতে হবে, একটি নয়।
| Client method | What the user presents | Where the work sits |
|---|---|---|
| Mutual certificate | A client certificate the endpoint trusts | Certificate authority, issuing and revoking per user |
| Active Directory | Domain credentials | Directory reachable from the endpoint's VPC |
| SAML federation | An assertion from an identity provider | IdP application, attribute mapping, client support |
সার্টিফিকেট স্থাপন করা সবচেয়ে সস্তা এবং বড় পরিসরে ভুল হওয়ার সম্ভাবনা সবচেয়ে বেশি, কারণ প্রত্যেক ব্যবহারকারীর একটি ক্রেডেনশিয়াল দরকার এবং প্রত্যেকের প্রস্থানের জন্য একটি প্রত্যাহার দরকার। ডিরেক্টরি প্রমাণীকরণ সেই জীবনচক্রকে একটি বিদ্যমান সিস্টেমে সরিয়ে দেয়। ফেডারেশন তা একটি পরিচয় প্রদানকারীর কাছে সরায় এবং ক্লায়েন্টে একটি ব্রাউজার ধাপ যোগ করে।
ক্লায়েন্ট ডিবাগ করার আগে এন্ডপয়েন্টের নিজের কনফিগারেশন পড়ুন। যদি পারস্পরিক প্রমাণীকরণ ব্যবহারকারী-ভিত্তিক পদ্ধতির পাশাপাশি সক্রিয় থাকে, একটি বৈধ সার্টিফিকেট আছে কিন্তু ডিরেক্টরি অ্যাকাউন্ট নেই এমন ক্লায়েন্টও ব্যর্থ হবে, এবং ত্রুটিটি সাধারণত সাধারণ হ্যান্ডশেক সমস্যার মতো দেখায়।
ফেডারেশন মানে অ্যাক্সেস কী হস্তান্তর নয়
একটি SAML সেটআপ IAM অ্যাক্সেস কী বা একটি অনুমিত-রোল টোকেন টানেলে দেয় না। পরিচয় প্রদানকারী ব্যক্তিকে প্রমাণীকরণ করে, একটি দাবি ফিরিয়ে দেয়, এবং এন্ডপয়েন্ট আপনার কনফিগার করা আস্থার অধীনে তা গ্রহণ করে। যে সেশন তৈরি হয় তা একটি VPN সেশন, AWS API সেশন নয়।
এই পার্থক্যই ঠিক করে কে কী সমস্যা সমাধান করতে পারে। IdP সমস্যা কোনো টানেল থাকার আগেই ব্রাউজার বা ক্লায়েন্ট ত্রুটি হিসেবে দেখা যায়, আর টানেল সমস্যা সফল দাবির পরে দেখা যায়। যেকোনো কনসোল খোলার আগে জিজ্ঞাসা করুন আপনি এই দুটির কোনটি দেখছেন।
লগইনের পরে রুট ও অনুমোদনই ঠিক করে
প্রমাণীকরণ সেশনকে একটি ঠিকানা দেয়; এটি সেশনকে গন্তব্য দেয় না। এন্ডপয়েন্ট রুট ক্লায়েন্টকে বলে কোন সাবনেটে পাঠাতে হবে, অনুমোদন নিয়ম ঠিক করে কোন ব্যবহারকারী সেই সাবনেটগুলোর কোনটিতে পৌঁছাতে পারে, আর নিরাপত্তা গোষ্ঠী ও লক্ষ্যের নিজস্ব অনুমতি বাকিটা ঠিক করে।
এই কারণেই সফলভাবে প্রমাণীকৃত একজন ব্যবহারকারী তবুও একটি ডেটাবেসে পৌঁছাতে ব্যর্থ হতে পারেন। সাবনেটের রুট টেবিল সংযুক্তি, ব্যবহারকারীর গোষ্ঠীর অনুমোদন নিয়ম এবং লক্ষ্যের নিরাপত্তা গোষ্ঠী এই ক্রমে পরীক্ষা করুন, কারণ প্রত্যেকটি ভিন্ন ধরনের সময়সীমা তৈরি করে।
একটি প্রাইভেট ডেটাবেসের জন্য পোর্ট ফরওয়ার্ডিংয়ের সাথে তুলনা করুন
যদি আসল কাজ একটি প্রাইভেট ডেটাবেসে একটি অনুমোদিত সংযোগ হয়, তবে পূর্ণ নেটওয়ার্ক টানেল একটি বাধ্যবাধকতা নয়, একটি পছন্দ। AWS Systems Manager Session Manager IAM-এর মাধ্যমে একটি পরিচালিত নোডে পোর্ট-ফরওয়ার্ডিং সেশন খুলতে পারে, এবং সেই নোড প্রাইভেট নেটওয়ার্কে ডেটাবেসে পৌঁছায়। ব্যবহারকারী কখনো VPC ঠিকানা পান না। পরিচালিত নোডটিই একমাত্র হোস্ট যা ডেটাবেস পোর্টে পৌঁছাতে পারে, এবং নিরাপত্তা পর্যালোচনা সাধারণত এটাই চেয়েছিল। তখন ব্যবহারকারীদের VPN প্রোফাইলের বদলে একটি স্থানীয় ক্লায়েন্ট ও একটি সেশন কমান্ড দরকার।
বিনিময়টি পরিধি বনাম পূর্বশর্ত। পোর্ট ফরওয়ার্ডিংয়ের জন্য পরিচালিত নোডে SSM এজেন্ট, সেই নোড থেকে ডেটাবেসে নেটওয়ার্ক পৌঁছানোযোগ্যতা, ব্যবহারকারীর মেশিনে Session Manager প্লাগইন এবং সেই নির্দিষ্ট সেশন শুরু করার অনুমতি দরকার। এটি প্রতিটি সাবনেটে প্রবেশের রুট নয়, এবং টানেলের মতো ইচ্ছামতো প্রোটোকল বহন করবে না।
যেভাবেই হোক ডেটাবেসের নিজস্ব পরিচয় অক্ষত রাখুন। পথটি IAM দ্বারা অনুমোদিত হয়েছে বলে TLS যাচাই ও ডেটাবেস প্রমাণীকরণ হারিয়ে যায় না, এবং একটি অনুমোদিত সেশন ব্যবহারকারী কোন টেবিল পড়তে পারবেন সে সম্পর্কে কিছুই বলে না।
পরিধি ও জীবনচক্রের ভিত্তিতে বেছে নিন: অনেক ব্যবহারকারীর অনেক গন্তব্য দরকার এবং আপনি সার্টিফিকেট বা ডিরেক্টরি জীবনচক্র চালাতে পারেন তখন টানেল; অল্প কয়েকজনের একটি সেবা দরকার এবং আপনি নেটওয়ার্ক ঠিকানা বিতরণ না করতে চাইলে ফরওয়ার্ডিং সেশন। যেভাবেই হোক, প্রমাণীকরণ পদ্ধতি, অনুমোদন নিয়ম এবং ডেটাবেস লগইন তিনটি আলাদা তথ্য হিসেবে লিখে রাখুন, কারণ তারা আলাদাভাবে ব্যর্থ হয়।