انتشار HTTP را از اجرای برنامه و داده‌های پایدار جدا کنید. یک پروکسی معکوس می‌تواند مسیریابی و محدودیت‌ها را سازمان‌دهی کند، اما دسترسی به مبدأ، مجوزدهی برنامه، ظرفیت بالادست و بازیابی هر یک به کنترل‌های خود نیاز دارند.
یک درخواست وب از چندین مسئولیت عبور می‌کند
یک وب‌سرور درخواست‌های HTTP را دریافت می‌کند و می‌تواند فایل‌های ایستا را ارائه دهد. یک فرایند برنامه رفتار پویای پروژه را اجرا می‌کند، مانند بررسی یک حساب یا پرس‌وجو از پایگاه داده. یک پروکسی معکوس درخواست‌ها را به نمایندگی از آن فرایند دریافت و به یک بالادست ارسال می‌کند. یک برنامه ممکن است چندین نقش را ایفا کند، اما جدا کردن مسئولیت‌ها استدلال درباره پیکربندی و بازیابی را آسان‌تر می‌کند.
یک درخواست را از مرحله حل نام میزبان تا پاسخ ردیابی کنید. ثبت کنید که TLS کجا پایان می‌یابد، کدام فرایند مسیر را انتخاب می‌کند و کدام مؤلفه می‌تواند داده‌های برنامه را بخواند. همین کار را برای یک درخواست مدیریتی انجام دهید. این تمرین اغلب یک شنونده یا نام میزبان را آشکار می‌کند که برای آزمایش ایجاد شده و به‌طور تصادفی قابل دسترسی باقی مانده است. نمودار باید مسیر مستقرشده را توصیف کند، نه معماری‌ای که امید داشتید بسازید.
از لبه برای سازمان‌دهی رفتار HTTP استفاده کنید
NGINX هم ارائه محتوای ایستا و هم ارسال درخواست‌ها به یک بالادست را مستند کرده است. معماری worker و ماژول‌های HTTP آن مکانیزم‌های پیکربندی فراهم می‌کنند، اما یک پیکربندی خاص همچنان رفتار را تعیین می‌کند. نام‌های میزبان، بالادست‌ها و ریشه‌های فایل‌سیستم را آگاهانه تعریف کنید. فایل‌هایی را که می‌توانند ارائه شوند محدود کنید تا پیکربندی، اعتبارنامه‌ها و فراداده مخزن هرگز به این دلیل که تصادفاً نزدیک برنامه قرار دارند قابل دانلود نشوند.
محدودیت‌های مناسب برای بدنه درخواست، مهلت‌های زمانی و اتصالات را مطابق برنامه تنظیم کنید. با حافظه‌های نهان به‌عنوان یک تصمیم داده‌ای رفتار کنید: محتوای مرتبط با یک کاربر یا مجوز نمی‌تواند بدون بازبینی به‌طور ایمن یک قاعده نهان‌سازی مشترک را به ارث ببرد. احراز هویت و رفتار حافظه نهان را با هم آزمایش کنید. یک پیکربندی قابل بازتولید نگه دارید و تغییرات را قبل از بارگذاری مجدد سرویس اعتبارسنجی کنید، با یک مسیر شناخته‌شده بازگشت به نسخه کاری قبلی.
| لایه | مسئولیت مفید | قبل از راه‌اندازی بررسی کنید |
|---|---|---|
| لبه وب عمومی | TLS، مسیریابی نام میزبان و محدودیت‌های HTTP | گواهی‌ها، ریشه‌ها و نام‌های میزبان مورد نظر |
| فرایند برنامه | منطق کسب‌وکار و مجوزدهی | احراز هویت، بررسی ورودی و شکست وابستگی |
| سرویس داده داخلی | وضعیت پایدار برنامه | دسترسی محدود و بازیابی آزمایش‌شده |
| شبکه ارائه‌دهنده بالادست | سرویس شبکه قراردادی | دامنه حفاظت و مسیر تشدید |
پروکسی معکوس قرار گرفتن مبدأ در معرض را از بین نمی‌برد
اگر مبدأ همچنان به‌طور عمومی قابل دسترسی باشد، یک کلاینت ممکن است بدون استفاده از مسیر پروکسی مورد نظر به آن برسد. زمانی که استقرار به این مرز نیاز دارد، دسترسی به مبدأ را از طریق طراحی شبکه و پیکربندی برنامه محدود کنید. روی یک ماشین، یک بک‌اند اغلب می‌تواند روی loopback یا یک سوکت محلی گوش دهد. در میان ماشین‌ها، از مسیرهای محدود صریح و حفاظت مناسب برای اتصال بالادست استفاده کنید.
هدرهای ارسال‌شده نیز به یک قاعده اعتماد نیاز دارند. اطلاعات مربوط به کلاینت اصلی را فقط از واسطه‌های مورد اعتماد بپذیرید و از تأمین مقادیر دلخواه توسط فراخوان‌ها که برنامه آن‌ها را معتبر می‌داند جلوگیری کنید. تصمیم بگیرید چه چیزی در گزارش‌های دسترسی و خطا ظاهر شود. یک پروکسی می‌تواند اطلاعات موجود در هر لایه را تغییر دهد؛ اما شناسه‌های حساب را پاک نمی‌کند یا برنامه را برای اپراتور خود ناشناس نمی‌سازد.
تصمیم‌های دسترسی را درون برنامه اعمال کنید
معماری Zero Trust مؤسسه NIST بر تصمیم‌های دسترسی برای منابع تمرکز دارد، نه اعتماد ضمنی صرفاً بر اساس موقعیت شبکه. این اصل را به‌طور مشخص اعمال کنید: فراخوان را احراز هویت کنید، عملیات درخواستی را مجوزدهی کنید و به حساب‌های سرویس فقط دامنه مورد نیازشان را بدهید. درخواستی که از یک زیرشبکه داخلی می‌رسد نباید به‌طور خودکار به یک درخواست مدیر تبدیل شود.
در جایی که عملی امکان‌پذیر است، عملکردهای عمومی و مدیریتی را جدا کنید. زمانی که کاربر به یک رکورد دسترسی پیدا می‌کند، مجوز را دوباره بررسی کنید، نه اینکه فقط به ورود اولیه تکیه کنید. اعتبارنامه‌های پروکسی، برنامه و پایگاه داده را متمایز نگه دارید. تغییرات را در مراحلی که قابل آزمایش هستند معرفی کنید، با شروع از یک مسیر حساس باریک. نامیدن یک استقرار به‌عنوان Zero Trust کمتر از نشان دادن این که یک اقدام ممنوع واقعاً در مؤلفه مسئول آن رد می‌شود مفید است.
مقابله با انکار سرویس را در بیش از یک لایه برنامه‌ریزی کنید
یک پیوند شبکه اشباع‌شده و یک درخواست پرهزینه برنامه در مکان‌های متفاوتی شکست می‌خورند. محدودسازی نرخ در لبه وب ممکن است به محدود کردن الگوهای درخواست کمک کند، در حالی که محدودیت‌های برنامه می‌توانند کارهایی مانند جست‌وجو، بارگذاری یا خروجی گرفتن را محدود کنند. ماژول محدودسازی درخواست NGINX یک مکانیزم فراهم می‌کند؛ کلید و آستانه‌ها باید با کاربران واقعی سازگار باشند و آزمایش شوند تا از رد ترافیک مشروع جلوگیری شود.
راهنمای انکار سرویس OWASP نیز به تخلیه منابع در رفتار برنامه می‌پردازد. محدودیت‌های زمانی و اندازه را حول کارهای پرهزینه قرار دهید، از صف‌های محدود استفاده کنید و سیگنال‌های شکست را پایش کنید. کنترل‌های محلی نمی‌توانند در یک پیوند بالادست که قبلاً اشباع شده ظرفیت ایجاد کنند. حفاظت شبکه خاص موجود در پیشنهاد انتخاب‌شده را تأیید کنید و یک مسیر تشدید آماده کنید. هرگز فرض نکنید که حفاظت لایه 3–4 یک فهرست، حفاظت برای هر بار کاری HTTP را نیز اثبات می‌کند.
بازیابی را بخشی از انتشار کنید
سایت را از یک کلاینت خارجی با استفاده از نام میزبان مورد نظر آن بررسی کنید. HTTPS، تغییرمسیرها، منابع ایستا، ورودها و یک تراکنش نمونه برنامه را تأیید کنید. تأیید کنید که شنوندگان مدیریتی و فایل‌های خصوصی غیرقابل دسترسی باقی می‌مانند. یک بالادست متوقف‌شده را شبیه‌سازی کنید و بررسی کنید که لبه یک شکست کنترل‌شده برمی‌گرداند، نه اینکه جزئیات داخلی را افشا کند یا بدون محدودیت منتظر بماند.
برای Canvas، کنترل‌های موجود در حساب میزبانی را بخوانید. برای یک VPS، لبه وب و برنامه را به‌عنوان بخشی از برنامه عملیاتی خود نگه دارید. یک پورت شبکه بزرگ یک مشخصات ظرفیت است، نه اثبات اینکه برنامه می‌تواند آن توان عبوری را تحمل کند. پایش، بازیابی و مخاطبین ارائه‌دهنده را در دفترچه اجرا نگه دارید. فقط پس از تأیید مسیر واقعی درخواست و یک مسیر بازیابی عملی منتشر کنید.
چک‌لیست عملی شما.
- یک درخواست عمومی و یک درخواست مدیریتی را ردیابی کنید.
- ریشه‌های ارائه‌شده و شنوندگان بالادست را تعریف کنید.
- هدرهای ارسال‌شده را فقط از واسطه‌های تأییدشده بپذیرید.
- مجوزدهی و مرزهای حافظه نهان را آزمایش کنید.
- محدودیت‌ها و تشدید را برای شکست‌های شبکه و برنامه آماده کنید.
جزئیاتی که اهمیت دارند.
آیا یک وب‌سرور می‌تواند همزمان به‌عنوان پروکسی معکوس نیز عمل کند؟+
بله. NGINX یک نمونه مستند است. نقش‌های آن به پیکربندی بستگی دارد و برنامه همچنان به مجوزدهی و نگهداری خود نیاز دارد.
آیا یک پروکسی معکوس به‌طور خودکار مبدأ را پنهان می‌کند؟+
خیر. مبدأ ممکن است قابل دسترسی باقی بماند مگر اینکه تنظیمات مسیریابی، فایروال و شنونده مرز مورد نظر را اعمال کنند.
آیا محدودسازی درخواست هر حمله DDoS را متوقف می‌کند؟+
خیر. این کار الگوهای درخواست HTTP انتخاب‌شده را برطرف می‌کند. اشباع شبکه و سایر شکست‌های منابع به کنترل‌های مناسب بالادست و برنامه نیاز دارند.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- NGINX: راهنمای مبتدیان nginx.org
- NGINX: محدودسازی درخواست HTTP nginx.org
- NIST SP 800-207: معماری Zero Trust nvlpubs.nist.gov
- OWASP: پیشگیری از انکار سرویس cheatsheetseries.owasp.org
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.