VPC ریموٹ رسائی قبول کرنے کے لیے انکار کے ٹیسٹ ضروری ہیں

ریموٹ رسائی کی قبولیت متوقع نتائج کی جدول ہے، کام کرنے والے صفحے کا اسکرین شاٹ نہیں۔ ہر گروہ کے لیے لکھیں کہ کیا کامیاب ہونا چاہیے اور کیا ناکام، پھر کنٹرول شدہ وقت میں مخصوص ٹیسٹ شناختوں کے ساتھ دونوں چلائیں۔ حد کو ثابت کرنے والا حصہ انکار ہیں؛ کامیاب لاگ اِن صرف یہ ثابت کرتا ہے کہ ٹنل موجود ہے۔ یہ سب پہلے سے منتخب VPN مصنوع کے ساتھ کام کرتا ہے۔

ٹیسٹوں کے لیے الگ اکاؤنٹس استعمال کریں اور اُنہیں اس طرح لیبل کریں کہ کوئی ٹیسٹ شناخت کو حقیقی استثنا نہ سمجھے۔

حد کو متوقع نتائج کے طور پر لکھیں

اجزا سے نہیں، کرداروں سے شروع کریں: کس کو کون سی خدمت چاہیے، کہاں سے اور کس شناخت کے ساتھ۔ ایک مثال VPC لیں: ایک گروہ کو HTTPS کے ذریعے اسٹیجنگ چاہیے، دوسرے کو پروڈکشن ڈیٹا بیس چاہیے، اور تیسرا چھوٹا گروہ خود گیٹ وے کا انتظام کرتا ہے۔ ہر سطر کو متوقع اجازت اور متوقع انکار ملتا ہے، بشمول ہمسایہ خدمت اور ہمسایہ اکاؤنٹ جو کام نہیں کرنا چاہیے۔ وہی جدول قبولیت کا معیار ہے، اور جو لوگ ٹیسٹ نہیں چلاتے وہ بھی اُس کا جائزہ لے سکتے ہیں۔

ڈیٹا بیس لاگ اِن کی جانچ نیٹ ورک راستے سے الگ کریں۔ قابلِ رسائی TCP پورٹ کو غیر منظور شدہ ڈیٹا بیس اکاؤنٹ کامیاب نہیں بنانا چاہیے، اور VPN رکنیت کو کلاؤڈ IAM کردار نہیں بنانا چاہیے یا انتظامی API رسائی نہیں دینی چاہیے۔ یہ تین خودمختار کنٹرول ہیں، اور وہ خودمختار طور پر ناکام ہوتے ہیں۔

راستہ اجازت نہیں ہے

راستہ ایک راہ ممکن بناتا ہے؛ یہ اجازت نہیں دیتا۔ راستہ روکنا منزل پر نافذ پابندی کا کمزور متبادل ہے، کیونکہ کلائنٹ ہمیشہ اپنا راستہ شامل کر سکتا ہے۔ سیکیورٹی گروپ، ڈیٹا بیس کی اجازت اور خود ایپلیکیشن کی اجازت ہی فیصلہ کرنے والے کنٹرول رہتے ہیں۔ جب کوئی ٹیسٹ غیر متوقع طور پر کامیاب ہو، پہلے منزل کی پالیسی دیکھیں، وہ روٹنگ جدول نہیں جو آپ کلائنٹ کے پاس چاہتے تھے۔

اسی لیے انکار کے ٹیسٹ سرور کی طرف متوجہ ہیں: وہ نتائج کلائنٹ میں ترمیم کر کے تبدیل نہیں کیے جا سکتے۔

کنٹرول درحقیقت کون سا ذریعہ دیکھتا ہے؟

کنٹرول جو ماخذ پتہ جانچتا ہے وہ گیٹ وے کے ڈھانچے پر منحصر ہے۔ EC2 پر میزبان گیٹ وے روٹ شدہ پول آگے بھیج سکتا ہے، اُسے اپنے پتے میں ترجمہ کر سکتا ہے، یا NAT کے بعد مختلف پتہ پیش کر سکتا ہے؛ منظم Client VPN کسی سب نیٹ سے جڑتا ہے اور اپنا ماڈل اپناتا ہے۔ سیکیورٹی گروپ اور نیٹ ورک ACL اُس پروسیسنگ کے بعد آنے والی چیز دیکھتے ہیں۔ غلط ماخذ مفروضے کے سامنے اصول جانچنا ایسی حد بنانے کا عام طریقہ ہے جو درست دکھتی ہے اور غلط ٹریفک قبول کرتی ہے۔

ہر نتیجے کو سب سے چھوٹے مفید واقعے سے جوڑیں: شناخت اور سیشن، وسیلہ، عمل، وقت اور فیصلہ۔ CloudTrail میں API کال، VPC فلو ریکارڈ اور VPN سیشن لاگ مختلف سوالات کا جواب دیتے ہیں، اور اِن میں سے کوئی اکیلا ایپلیکیشن کا آڈٹ نہیں۔

شناخت واپس لیں اور دوبارہ جانچ کریں

واپس لینے کو بھی اُسی جدول میں شامل کریں۔ ٹیسٹ شناخت ہٹائیں، تصدیق کریں کہ نیا سیشن مسترد ہوتا ہے، پھر الگ سے تصدیق کریں کہ موجودہ سیشنوں کے ساتھ کیسا سلوک ہوتا ہے، کیونکہ یہ مختلف مالکان کے مختلف رویے ہیں۔ دیکھیں کہ گیٹ وے کی دوبارہ شروعات یا تبدیلی کے بعد کیا ہوتا ہے، تاکہ ہاتھ سے شامل کردہ استثنا خاموشی سے غائب نہ ہو یا زیادہ وسیع ہو کر واپس نہ آئے۔ جو حد صرف اگلی تعیناتی تک رہے وہ حد نہیں ہے۔

اِن میں سے کوئی بھی پیچنگ، بحالی یا اسناد کے زندگی چکر کے کام کی جگہ نہیں لیتا۔ یہ ایک تنگ وعدے کو قابلِ پیمائش بناتا ہے: صحیح لوگ صحیح خدمات تک پہنچتے ہیں، جبکہ قریبی راستے، اکاؤنٹس اور انتظامی سطحیں اجازت سے باہر رہتی ہیں۔

جدول کو تعیناتی کے ساتھ رکھیں اور گیٹ وے بدلنے پر دوبارہ چلائیں۔ ٹیسٹ سستے ہیں؛ اُن کے پیچھے کے مفروضے نہیں۔