HTTP کی اشاعت کو ایپلیکیشن کے نفاذ اور مستقل ڈیٹا سے الگ کریں۔ ریورس پراکسی روٹنگ اور حدود کو منظم کر سکتی ہے، لیکن اوریجن تک رسائی، ایپلیکیشن کی اجازت، اپ اسٹریم کی گنجائش اور بحالی میں سے ہر ایک کے لیے اپنے کنٹرول درکار ہیں۔
ایک ویب درخواست کئی ذمہ داریوں سے گزرتی ہے
ایک ویب سرور HTTP درخواستیں وصول کرتا ہے اور جامد فائلیں پیش کر سکتا ہے۔ ایپلیکیشن پروسیس پروجیکٹ کا متحرک رویہ انجام دیتا ہے، جیسے اکاؤنٹ کی جانچ یا ڈیٹا بیس سے استفسار۔ ریورس پراکسی اس پروسیس کی جانب سے درخواستیں وصول کرتی ہے اور انہیں اپ اسٹریم کو بھیجتی ہے۔ ایک پروگرام کئی کردار ادا کر سکتا ہے، لیکن ذمہ داریوں کو الگ کرنے سے ترتیب اور بحالی پر غور کرنا آسان ہو جاتا ہے۔
ہوسٹ نام کے حل سے جواب تک ایک درخواست کا سراغ لگائیں۔ ریکارڈ کریں کہ TLS کہاں ختم ہوتا ہے، کون سا پروسیس راستہ منتخب کرتا ہے اور کون سا جزو ایپلیکیشن ڈیٹا پڑھ سکتا ہے۔ انتظامی درخواست کے لیے بھی ایسا ہی کریں۔ یہ مشق اکثر ایسے لسنر یا ہوسٹ نام کو بے نقاب کرتی ہے جو جانچ کے لیے بنایا گیا تھا اور اتفاقاً قابلِ رسائی رہ گیا۔ خاکہ اس تعینات شدہ راستے کو بیان کرنا چاہیے، نہ کہ اس معماری کو جسے آپ بنانے کی امید رکھتے تھے۔
HTTP رویے کو منظم کرنے کے لیے ایج استعمال کریں
NGINX جامد مواد پیش کرنے اور درخواستیں اپ اسٹریم کو بھیجنے، دونوں کی دستاویز کرتا ہے۔ اس کی ورکر معماری اور HTTP ماڈیولز ترتیب کے طریقے فراہم کرتے ہیں، لیکن مخصوص ترتیب ہی رویہ طے کرتی ہے۔ ہوسٹ نام، اپ اسٹریم اور فائل سسٹم روٹس دانستہ طور پر متعین کریں۔ پیش کی جانے والی فائلوں کو محدود کریں تاکہ ترتیب، اسناد اور ریپوزٹری میٹا ڈیٹا کبھی ڈاؤن لوڈ کے قابل نہ ہوں کیونکہ وہ اتفاقاً ایپلیکیشن کے قریب موجود ہیں۔
ایپلیکیشن کے مطابق درخواست باڈیز، ٹائم آؤٹ اور کنکشنز کے لیے مناسب حدود مقرر کریں۔ کیش کو ڈیٹا کا فیصلہ سمجھیں: صارف یا اجازت سے منسلک مواد بغیر جائزے کے مشترکہ کیشنگ اصول وراثت میں نہیں لے سکتا۔ توثیق اور کیش کے رویے کی ایک ساتھ جانچ کریں۔ دوبارہ قابلِ پیداوار ترتیب رکھیں اور سروس دوبارہ لوڈ کرنے سے پہلے تبدیلیوں کی توثیق کریں، پچھلے فعال ورژن تک واپسی کے معلوم راستے کے ساتھ۔
| تہہ | مفید ذمہ داری | لانچ سے پہلے جانچیں |
|---|---|---|
| عوامی ویب ایج | TLS، ہوسٹ نام روٹنگ اور HTTP حدود | سرٹیفکیٹ، روٹس اور مطلوبہ ہوسٹ نام |
| ایپلیکیشن پروسیس | کاروباری منطق اور اجازت | توثیق، ان پٹ جانچ اور انحصار کی ناکامی |
| اندرونی ڈیٹا سروس | مستقل ایپلیکیشن حالت | محدود رسائی اور آزمودہ بحالی |
| اپ اسٹریم فراہم کنندہ نیٹ ورک | معاہدہ شدہ نیٹ ورک سروس | تحفظ کا دائرہ اور اضافے کا راستہ |
ریورس پراکسی اوریجن کی نمائش ختم نہیں کرتی
اگر اوریجن عوامی طور پر قابلِ رسائی رہے تو کلائنٹ مطلوبہ پراکسی راستہ استعمال کیے بغیر اس تک پہنچ سکتا ہے۔ جب تعیناتی اس حد کا تقاضا کرے تو نیٹ ورک ڈیزائن اور ایپلیکیشن ترتیب کے ذریعے اوریجن تک رسائی محدود کریں۔ ایک مشین پر، بیک اینڈ اکثر لوپ بیک یا مقامی ساکٹ پر سن سکتا ہے۔ مشینوں کے درمیان، واضح محدود راستے اور اپ اسٹریم کنکشن کے لیے مناسب تحفظ استعمال کریں۔
فارورڈ شدہ ہیڈرز کے لیے بھی اعتماد کا اصول درکار ہے۔ اصل کلائنٹ کے بارے میں معلومات صرف قابلِ اعتماد intermediaries سے قبول کریں، اور صوابدیدی کالرز کو ایسی اقدار فراہم کرنے سے روکیں جنہیں ایپلیکیشن مستند سمجھتی ہے۔ فیصلہ کریں کہ رسائی لاگز اور ایرر رپورٹس میں کیا ظاہر ہوگا۔ پراکسی ہر سطح پر دستیاب معلومات بدل سکتی ہے؛ یہ اکاؤنٹ شناخت کنندگان کو مٹاتی نہیں اور ایپلیکیشن کو اس کے اپنے آپریٹر سے گمنام نہیں بناتی۔
رسائی کے فیصلے ایپلیکیشن کے اندر لاگو کریں
NIST کی Zero Trust معماری صرف نیٹ ورک مقام کی بنیاد پر مضمر اعتماد کے بجائے وسائل کے لیے رسائی کے فیصلوں پر مرکوز ہے۔ اس اصول کو ٹھوس طور پر لاگو کریں: کالر کی توثیق کریں، مطلوبہ عمل کی اجازت دیں اور سروس اکاؤنٹس کو صرف ان کا مطلوبہ دائرہ دیں۔ اندرونی سب نیٹ سے آنے والی درخواست خود بخود منتظم کی درخواست نہیں بننی چاہیے۔
جہاں عملی ہو عوامی اور انتظامی افعال الگ کریں۔ جب صارف کسی ریکارڈ تک رسائی کرے تو صرف ابتدائی لاگ ان پر انحصار کے بجائے اجازت دوبارہ جانچیں۔ پراکسی، ایپلیکیشن اور ڈیٹا بیس کی اسناد الگ رکھیں۔ تبدیلیاں مرحلوں میں متعارف کریں جن کی جانچ ہو سکے، ایک تنگ حساس راستے سے آغاز کرتے ہوئے۔ تعیناتی کو Zero Trust کہنا اس بات کے مظاہرے سے کم مفید ہے کہ ممنوع عمل واقعی اس جزو پر مسترد ہوتا ہے جو اس کا ذمہ دار ہے۔
سروس سے انکار کی منصوبہ بندی ایک سے زیادہ سطحوں پر کریں
سیر شدہ نیٹ ورک لنک اور مہنگی ایپلیکیشن درخواست مختلف مقامات پر ناکام ہوتے ہیں۔ ویب ایج پر ریٹ لِمٹنگ درخواست کے نمونوں کو محدود کرنے میں مدد کر سکتی ہے، جبکہ ایپلیکیشن کی حدود تلاش، اپ لوڈ یا ایکسپورٹ جیسے کام کو محدود کر سکتی ہیں۔ NGINX کا request-limit ماڈیول ایک طریقہ فراہم کرتا ہے؛ کلید اور حدیں حقیقی صارفین کے مطابق ہونی چاہئیں اور جائز ٹریفک مسترد نہ ہو، اس کے لیے جانچ ضروری ہے۔
OWASP کی سروس سے انکار کی رہنمائی ایپلیکیشن رویے میں وسائل کی کمی کو بھی حل کرتی ہے۔ مہنگے کام کے گرد وقت اور حجم کی حدیں رکھیں، محدود قطاریں استعمال کریں اور ناکامی کے اشاروں کی نگرانی کریں۔ مقامی کنٹرول پہلے سے سیر شدہ اپ اسٹریم لنک میں گنجائش پیدا نہیں کر سکتے۔ منتخب کردہ پیشکش میں شامل مخصوص نیٹ ورک تحفظ کی تصدیق کریں اور اضافے کا راستہ تیار رکھیں۔ کبھی یہ فرض نہ کریں کہ کسی کیٹلاگ کا Layer 3–4 تحفظ ہر HTTP ورک لوڈ کے لیے بھی تحفظ ثابت کرتا ہے۔
بحالی کو اشاعت کا حصہ بنائیں
سائٹ کو بیرونی کلائنٹ سے اس کے مطلوبہ ہوسٹ نام کے ذریعے جانچیں۔ HTTPS، ری ڈائریکٹس، جامد وسائل، لاگ ان اور ایک نمائندہ ایپلیکیشن لین دین کی تصدیق کریں۔ تصدیق کریں کہ انتظامی لسنر اور نجی فائلیں ناقابلِ رسائی رہیں۔ رکے ہوئے اپ اسٹریم کی نقل کریں اور جانچیں کہ ایج اندرونی تفصیلات بے نقاب کیے یا بغیر حد انتظار کیے بجائے کنٹرول شدہ ناکامی واپس کرتا ہے۔
Canvas کے لیے، ہوسٹنگ اکاؤنٹ میں دستیاب کنٹرول پڑھیں۔ VPS کے لیے، ویب ایج اور ایپلیکیشن کو اپنے آپریٹنگ پلان کے حصے کے طور پر برقرار رکھیں۔ بڑا نیٹ ورک پورٹ گنجائش کی تفصیل ہے، اس بات کا ثبوت نہیں کہ ایپلیکیشن اس تھرو پٹ کو برقرار رکھ سکتی ہے۔ نگرانی، بحالی اور فراہم کنندہ کے روابط رن بک میں رکھیں۔ صرف اس وقت شائع کریں جب حقیقی درخواست راستے اور عملی بحالی راستے کی تصدیق ہو جائے۔
آپ کی عملی چیک لسٹ۔
- ایک عوامی اور ایک انتظامی درخواست کا سراغ لگائیں۔
- پیش کیے جانے والے روٹس اور اپ اسٹریم لسنر متعین کریں۔
- فارورڈ شدہ ہیڈرز پر صرف منظور شدہ intermediaries سے اعتماد کریں۔
- اجازت اور کیش کی حدود کی جانچ کریں۔
- نیٹ ورک اور ایپلیکیشن کی ناکامیوں کے لیے حدود اور اضافے کا راستہ تیار کریں۔
وہ تفصیلات جو اہم ہیں۔
کیا ویب سرور ریورس پراکسی کا کردار بھی ادا کر سکتا ہے؟+
ہاں۔ NGINX ایک دستاویزی مثال ہے۔ اس کے کردار ترتیب پر منحصر ہیں، اور ایپلیکیشن کو پھر بھی اپنی اجازت اور دیکھ بھال درکار ہے۔
کیا ریورس پراکسی خود بخود اوریجن چھپا دیتی ہے؟+
نہیں۔ اوریجن قابلِ رسائی رہ سکتا ہے جب تک روٹنگ، فائر وال اور لسنر کی ترتیبات مطلوبہ حد نافذ نہ کریں۔
کیا درخواست کی حد بندی ہر DDoS حملہ روک دے گی؟+
نہیں۔ یہ منتخب HTTP درخواست نمونوں کو حل کرتی ہے۔ نیٹ ورک کی سیر اور دیگر وسائل کی ناکامیوں کے لیے مناسب اپ اسٹریم اور ایپلیکیشن کنٹرول درکار ہیں۔
ماخذ پر جائیں۔
یہ حوالہ جات اس گائیڈ میں تکنیکی تصورات کی حمایت کرتے ہیں۔ پروڈکشن سسٹم تبدیل کرنے سے پہلے موجودہ دستاویزات کی پیروی کریں۔
- NGINX: ابتدائی رہنما nginx.org
- NGINX: HTTP درخواست کی حد بندی nginx.org
- NIST SP 800-207: Zero Trust معماری nvlpubs.nist.gov
- OWASP: سروس سے انکار کی روک تھام cheatsheetseries.owasp.org
SwissOctet کی طرف سے ادارتی رہنمائی۔ مثالیں مثالی ہیں۔ سروس کی تفصیلات، دستیاب اختیارات اور معاہدے کی شرائط الگ سے تصدیق شدہ ہونی چاہئیں۔