شما چه چیزی را در یک زیر شبکه عمومی قرار می دهید‽

مردم با دید عالی برای راه حل های مدرن و به خصوص بدون سرور طراحی می کنند. آنچه چشمگیرتر است این است که در جایی که سرویس های VPC استفاده می شوند، آنها را به لایه ها و زیرشبکه های جداگانه تقسیم می کنند.

😕 اما چرا بسیاری از مردم چیزهایی را در زیرشبکه های عمومی قرار می دهند که لازم نیست؟

در این مقاله به آنچه فکر می‌کنم باید در زیرشبکه‌های عمومی باشد و اینکه چرا سعی می‌کنید چیزی را در یک زیرشبکه عمومی قرار ندهید که به آن نیاز ندارید، می‌پردازم.

زیرشبکه عمومی چیست؟

بنابراین ابتدا اجازه می‌دهیم ببینیم که یک زیرشبکه عمومی چیست.
اسناد AWS VPC، یک زیر شبکه عمومی به صورت “تعریف می شود.[having] یک مسیر مستقیم به یک دروازه اینترنتی. منابع موجود در یک زیرشبکه عمومی می توانند به اینترنت عمومی دسترسی داشته باشند.”

برعکس، این بدان معناست که یک منبع در یک زیرشبکه عمومی نیز از طریق اینترنت عمومی قابل دسترسی است. و برای من این یک ریسک بزرگ است.

پس چرا این بهترین کار نیست؟

دو دلیل وجود دارد که فکر می کنم این بهترین کار نیست.

اولا امنیت است.
اگر چیزی را در یک زیرشبکه عمومی قرار دهید، خطر امنیتی قابل توجهی را افزایش می دهد. به طور کلی منابع جدید در کمتر از 5 دقیقه پس از در دسترس بودن در اینترنت شناسایی و اسکن می شوند. این یک خطر بزرگ برای خدمات و داده های شما است و اگر مجبور نباشید چیزی را در زیرشبکه عمومی قرار دهید، من این کار را نمی کنم.

دوم عملکرد است.
در حالی که می‌توانید دستگاه‌های روبه‌روی خارجی خود را ایمن کنید، با انجام این کار برای تمام ترافیک، خطر افزایش تأخیر برای سرویس‌های داخلی یا در شرایط بار اضافی را دارید. من معتقدم که خدمات لایه‌بندی راه‌حل بهینه را بدون تلاش برای وادار کردن یک لایه به انجام تمام کارهای سخت می‌دهد. این همچنین به این معنی است که می‌توانید لایه‌هایی مانند خروجی خارجی برای سرویس‌های داخلی یا آن‌هایی که روی اتصالات قابل اعتماد مانند اتصال مستقیم وجود دارد را دور بزنید.

بنابراین چه چیزی می توانم در یک زیر شبکه عمومی قرار دهم؟

تنها دو سرویس وجود دارد که من می‌توانم آنها را در یک زیرشبکه عمومی مستقر کنم.

اولا دروازه ها هستند.
خواه این دروازه‌های NAT، دروازه‌های IPv6 فقط خروجی یا دروازه‌های اینترنتی باشند، اگر می‌خواهید به اینترنت خروجی دسترسی داشته باشید، باید در زیرشبکه عمومی باشند. در حالت ایده‌آل، من به دنبال راه‌حل‌هایی برای ساختن هستم که نیازی به دسترسی به اینترنت از VPC‌های برنامه/راه‌حل ندارند و نیاز به دروازه‌ها را به‌طور کلی کاهش می‌دهند.

دومی لایه های 3/4 بار متعادل کننده هستند.
خواه متعادل کننده بار دروازه (GWLB)، یا متعادل کننده بار شبکه (NLB) اینها به عنوان دروازه ورودی برای ترافیک به VPC شما عمل می کنند. از آنها برای هدایت ترافیک به خدمات داخلی استفاده کنید. قرار دادن آنها در مقابل Application Load Balancers (ALB) به شما این امکان را می دهد که ترافیک را به بار متعادل کننده های مختلف هدایت کنید و یک محیط خارجی امنیتی مانند اجرای TLS1.3 داشته باشید. در حالی که بسیاری استدلال می کنند که ALB می تواند این کار را نیز انجام دهد، با تفکیک نقش NLB و ALB، عملکرد ALB افزایش می یابد و ترافیک داخلی تحت تأثیر بار ترافیک خارجی قرار نمی گیرد.

اما در مورد …؟

بنابراین احتمالاً اکنون یک مؤلفه “What about” را در ذهن دارید که فکر می کنید باید آن را در یک زیر شبکه عمومی قرار دهید. من به موارد رایجی که می بینم نگاه می کنم و به این موضوع می پردازم که چرا فکر می کنم ایده خوبی نیست و در عوض شما باید چه کاری انجام دهید.

باستیون / جعبه های پرش
چرا این ایده خوبی نیست:
این سیستم ها اغلب برای همه جا باز هستند یا کنترل ضعیفی برای حذف مجوزهای IP دارند. مسئله در اینجا این است که اگر کسی این جعبه ها را نقض کند، معمولاً یک مسیر مستقیم به بسیاری از سیستم های دیگر دارد. آنها همچنین اغلب با ابزارها و اعتبار برای دسترسی به داده هایی مانند ذخیره سازی و پایگاه داده پیکربندی می شوند. این امر خطر زیادی برای قرار گرفتن در معرض داده ها ایجاد می کند.

به جای آن چه باید کرد:
اگر نیاز به دسترسی به نمونه EC2 دارید، توصیه می‌کنم از استحکامات به SSM Sessions مهاجرت کنید. این به شما امکان می‌دهد در سطح کاربر کنترل کنید که به چه سیستم‌هایی می‌توانند متصل شوند و نیاز به زیرساخت اضافی را از بین می‌برد. همچنین می توان از نظر اتصالات و در صورت نیاز، دستورات انجام شده را ثبت کرد. اگر باید جعبه‌ای برای اجرای ابزارها در محیط داشته باشید، یا اتصال به سرویس‌های AWS را ایجاد کنید، جعبه را به یک زیرشبکه خصوصی منتقل کنید و از Session Manager برای دسترسی از طریق SSH یا تونل برای دسترسی به مواردی مانند RDS استفاده کنید.

Application Load Balancers (ALB)
چرا این ایده خوبی نیست:
بسیاری از طرح ها و اسناد می گویند فقط ALB را در زیر شبکه عمومی قرار دهید. اگرچه این کار خواهد کرد و می توان آن را ایمن کرد، به نظر من بهترین راه برای انجام کارها نیست. این امر به ویژه در مواردی که شما به طور مستقیم از طریق اینترنت و به صورت داخلی در سیستم AWS یا On-Premise خود به خدمات دسترسی دارید صادق است. با جدا کردن منطق و اعمال کنترل های مختلف بر روی هر کدام، می توانید بهتر از خدمات خود محافظت کنید.

به جای آن چه باید کرد:
ALB خود را در زیر شبکه های مشابه برنامه خود قرار دهید و به سرویس های داخلی اجازه دهید مستقیماً با ALB صحبت کنند. سپس یک NLB در زیر شبکه عمومی برای ترافیک خارجی داشته باشید. در حالت ایده آل NLB پشت CloudFront قرار دارد. هر دو ELB می توانند توسط AWS WAF محافظت شوند. این بدان معنی است که محافظت از لایه 4 می تواند به سرعت توسط دستگاه هایی که فقط در معرض اینترنت هستند اتفاق بیفتد و بار و تأثیر بر دستگاه های لایه 4 را کاهش می دهد که توسط ترافیک داخلی نیز استفاده می شود.

نمونه های EC2 که به عنوان یک فایروال / IDS / دستگاه IPS عمل می کنند
چرا این ایده خوبی نیست:
در حالی که ممکن است این عملکرد را در محیط بخواهید، قرار دادن نمونه های EC2 خود مستقیماً در مسیر، آنها را برای حمله باز می کند. همانند Bastions، یک نمونه با IP عمومی دائماً اسکن و بررسی می شود. ساده ترین راه برای کاهش این امر، افشا نکردن سرور است.

به جای آن چه باید کرد:
یک Gateway Load Balancer (GWLB) را در زیر شبکه عمومی قرار دهید و از آن برای هدایت ترافیک به دستگاه امنیتی استفاده کنید. این نه تنها بار روی دستگاه را کاهش می دهد، بلکه به این معنی است که دستگاه های امنیتی می توانند به صورت مرکزی مستقر شوند و مدیریت شوند اما چندین VPC را سرویس دهند. نگاهی به این وبلاگ از AWS در مورد نحوه پیاده سازی GWLB بیندازید.

مثل همیشه، اینها فقط دیدگاه من بر اساس استفاده از سرویس‌های AWS برای بیش از یک دهه و مقابله با سقوط سیستم‌هایی است که در معرض دید قرار گرفته و نقض شده‌اند و همچنین عیب‌یابی عملکرد عملیاتی و قابلیت اطمینان.

مایلم نظرات شما را در مورد این مقاله یا پیشنهادی در مورد آنچه که در یک زیرشبکه عمومی قرار می دهید، ارائه دهید.