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 تصدیق اور ڈیٹا بیس تصدیق ختم نہیں ہوتی، اور منظور شدہ سیشن اس بارے میں کچھ نہیں کہتا کہ صارف کون سے جدول پڑھ سکتا ہے۔
دائرے اور زندگی کے چکر کی بنیاد پر چنیں: ٹنل جب بہت سے صارفین کو بہت سی منزلیں درکار ہوں اور آپ سرٹیفکیٹ یا ڈائریکٹری کا زندگی کا چکر چلا سکیں؛ فارورڈنگ سیشن جب چند لوگوں کو ایک سروس درکار ہو اور آپ نیٹ ورک پتے تقسیم نہ کرنا چاہیں۔ کسی بھی صورت میں، تصدیق کا طریقہ، اجازت کا قاعدہ اور ڈیٹا بیس لاگ اِن تین الگ حقائق کے طور پر درج کریں، کیونکہ وہ الگ الگ ناکام ہوتے ہیں۔