شبکه ابری (Cloud Networking) به مجموعه‌ای از قابلیت‌ها و سرویس‌های شبکه گفته می‌شود که برای اتصال، جداسازی، مسیریابی و محافظت از منابع مستقر در محیط ابری به کار می‌روند. این شبکه می‌تواند ارتباط بین ماشین‌های مجازی، پایگاه‌های داده، برنامه‌های کاربردی، کاربران راه دور و شبکه داخلی سازمان را مدیریت کند؛ بدون آنکه لازم باشد همه تجهیزات شبکه به شکل سخت‌افزار فیزیکی در محل سازمان نصب شوند.

برای درک بهتر تفاوت موضوع‌ها، رایانش ابری را به‌عنوان مدل ارائه منابعی مانند پردازش، ذخیره‌سازی و نرم‌افزار در نظر بگیرید و شبکه ابری را بخشی بدانید که ارتباط این منابع را طراحی و کنترل می‌کند. این مقاله روی معماری و پیاده‌سازی شبکه متمرکز است؛ نه روی همه انواع خدمات ابری.

خلاصه کاربردی: در یک شبکه ابری معمولاً محدوده آدرس IP، شبکه خصوصی مجازی، زیرشبکه‌ها، جدول‌های مسیریابی، قواعد امنیتی، مسیر اتصال به اینترنت یا دفتر مرکزی، DNS، توازن بار و پایش ترافیک تعریف می‌شوند. نام و جزئیات هر قابلیت با ارائه‌دهنده فرق دارد، اما اصول طراحی شبکه در همه محیط‌ها مشابه است.

شبکه ابری چیست؟

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

در سرویس‌هایی مانند Amazon VPC و Microsoft Azure Virtual Network، شبکه خصوصی منطقی ایجاد می‌شود و سپس محدوده آدرس، زیرشبکه، مسیرها و قواعد امنیتی به آن افزوده می‌شوند. راهنمای رسمی Amazon VPC و مستندات Microsoft Azure Virtual Network و Subnet نمونه‌هایی از این مدل را شرح می‌دهند.

تفاوت شبکه ابری با اینترنت و رایانش ابری

  • اینترنت: شبکه عمومی گسترده‌ای است که بسیاری از سرویس‌ها از طریق آن قابل دسترسی‌اند. شبکه ابری لزوماً عمومی نیست و می‌تواند ارتباط خصوصی و کنترل‌شده داشته باشد.
  • رایانش ابری: مدلی برای دسترسی به منابع قابل پیکربندی مانند سرور، ذخیره‌سازی، شبکه و نرم‌افزار است. تعریف NIST بر دسترسی درخواستی و فراهم‌سازی سریع منابع تأکید دارد.
  • شبکه ابری: بر اتصال و جداسازی منابع، آدرس‌دهی، مسیریابی، دسترسی، امنیت و مشاهده‌پذیری ارتباطات تمرکز دارد.

مدل‌های استقرار و معماری شبکه ابری

ابر عمومی (Public Cloud)

زیرساخت ابری توسط ارائه‌دهنده اداره می‌شود و سازمان منابع مورد نیازش را در آن ایجاد می‌کند. شبکه مجازی، زیرشبکه و سیاست‌های دسترسی در محدوده امکانات همان ارائه‌دهنده تنظیم می‌شوند. اشتراکی بودن زیرساخت فیزیکی به معنی عمومی بودن خود شبکه مجازی نیست؛ شبکه مجازی با کنترل‌های منطقی از منابع دیگر جدا می‌شود.

ابر خصوصی (Private Cloud)

محیط ابری برای یک سازمان اختصاص داده می‌شود و می‌تواند در مرکز داده داخلی یا نزد ارائه‌دهنده میزبانی شود. این مدل معمولاً کنترل بیشتری بر محیط می‌دهد، اما میزان هزینه و مسئولیت نگهداری به نحوه پیاده‌سازی بستگی دارد.

ابر ترکیبی (Hybrid Cloud)

در معماری ترکیبی، بخشی از سامانه‌ها در مرکز داده سازمان و بخشی دیگر در ابر قرار دارند. اتصال معمولاً از طریق VPN سایت‌به‌سایت یا ارتباط اختصاصی برقرار می‌شود. در این طراحی باید محدوده‌های IP، مسیر برگشت، DNS، قواعد دیواره آتش و روش مدیریت هویت هماهنگ باشند.

چندابری (Multi-Cloud)

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

اجزای اصلی شبکه ابری

۱. شبکه خصوصی مجازی؛ VPC یا VNet

VPC در AWS و VNet در Azure دو نمونه از شبکه‌های خصوصی منطقی در ابر هستند. در ابتدای طراحی، محدوده آدرس شبکه مشخص می‌شود. منابعی که در شبکه‌ها یا محدوده‌های جدا قرار دارند، صرفاً به دلیل حضور در یک ارائه‌دهنده به هم دسترسی خودکار ندارند؛ برای ارتباط باید مسیر و مجوز مناسب تعریف شده باشد.

۲. آدرس‌دهی IP و زیرشبکه‌ها (Subnets)

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

مثال صرفاً آموزشی: می‌توان محدوده‌ای مانند 10.20.0.0/16 را برای شبکه اصلی در نظر گرفت و چند محدوده کوچک‌تر مانند 10.20.1.0/24 و 10.20.2.0/24 را به زیرشبکه‌های مجزا اختصاص داد. اندازه و تعداد واقعی زیرشبکه‌ها باید بر اساس تعداد منابع، رشد مورد انتظار، الزامات ارائه‌دهنده و طرح آدرس سازمان تعیین شود؛ اعداد بالا نسخه آماده برای همه محیط‌ها نیستند.

۳. جدول مسیریابی (Route Table)

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

۴. قواعد امنیت شبکه

گروه‌های امنیتی، فهرست‌های کنترل دسترسی شبکه (مانند NSG در Azure یا Network ACL در برخی محیط‌ها) و دیواره آتش ابری برای محدود کردن ترافیک استفاده می‌شوند. محدوده اثر و ترتیب پردازش این قواعد در سرویس‌های مختلف یکسان نیست؛ بنابراین باید مستندات همان ارائه‌دهنده بررسی شود. اصل عملی این است که دسترسی‌ها فقط به مبدأ، مقصد، پورت و پروتکل موردنیاز محدود شوند.

۵. دروازه‌ها، VPN و ارتباط اختصاصی

دروازه اینترنت، NAT، دروازه VPN، نقاط اتصال خصوصی به سرویس‌ها و لینک اختصاصی می‌توانند نقش‌های متفاوتی داشته باشند. VPN سایت‌به‌سایت برای اتصال رمزگذاری‌شده دو شبکه استفاده می‌شود؛ گزینه‌های اختصاصی مانند AWS Direct Connect یا Azure ExpressRoute برای سناریوهایی مطرح‌اند که به اتصال خصوصی و ویژگی‌های مشخص عملکردی یا عملیاتی نیاز دارند. انتخاب بین این روش‌ها به نیازمندی‌ها، هزینه، دسترس‌پذیری و امکانات ارائه‌دهنده وابسته است.

۶. DNS، توازن بار و نقاط پایانی خصوصی

DNS نام سرویس‌ها را به مقصدهای شبکه تبدیل می‌کند؛ توازن بار درخواست‌ها را بین منابع مناسب توزیع می‌کند؛ و نقطه پایانی خصوصی می‌تواند در سناریوهای پشتیبانی‌شده دسترسی به یک سرویس را از مسیر خصوصی فراهم کند. تنظیم نادرست DNS یا تفاوت نام‌های داخلی و عمومی ممکن است باعث شود برنامه از مسیر مورد انتظار استفاده نکند.

۷. ثبت رخدادها و پایش

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

ترافیک چگونه در شبکه ابری حرکت می‌کند؟

  1. ارتباط داخلی: برنامه برای دسترسی به سرویس یا پایگاه داده، از آدرس مقصد و مسیرهای تعریف‌شده استفاده می‌کند. قواعد امنیتی باید ارتباط موردنیاز را مجاز و دسترسی‌های غیرضروری را مسدود کنند.
  2. خروج به اینترنت: مسیر خروجی، دروازه مناسب و تنظیمات لازم برای دسترسی عمومی یا NAT تعیین می‌شوند. منابعی که نیاز ندارند مستقیماً از اینترنت قابل دسترس باشند نباید بی‌دلیل آدرس عمومی دریافت کنند.
  3. ارتباط با دفتر سازمان: ترافیک از VPN یا لینک اختصاصی عبور می‌کند. برای نتیجه درست باید مسیر دوطرفه، محدوده IP غیرهم‌پوشان، DNS و قواعد هر دو سمت هماهنگ شوند.

الگوهای متداول طراحی

معماری چندلایه

در یک نمونه رایج، لایه ورودی یا وب از لایه برنامه و پایگاه داده جدا می‌شود. تنها اجزای لازم از لایه ورودی در دسترس قرار می‌گیرند؛ پایگاه داده معمولاً به ورودی مستقیم از اینترنت نیاز ندارد و فقط از مسیرهای مشخص برنامه یا مدیریت مجاز می‌شود. جزئیات باید با نوع برنامه و الزامات عملیاتی تطبیق داده شوند.

معماری Hub-and-Spoke

در این الگو یک شبکه مرکزی (Hub) می‌تواند محل مشترک سرویس‌هایی مانند اتصال به شبکه سازمان، دیواره آتش یا مدیریت مسیر باشد و شبکه‌های کاری (Spoke) برای سامانه‌ها یا محیط‌های مجزا ساخته شوند. باید از ابتدا مشخص شود کدام ارتباط‌ها مجازند؛ اتصال شبکه‌ها به‌صورت خودکار نباید به معنای دسترسی کامل میان همه سامانه‌ها تلقی شود.

شبکه نرم‌افزارمحور و SD-WAN

شبکه نرم‌افزارمحور (SDN) جداسازی منطق کنترل از تجهیزات انتقال و مدیریت برنامه‌پذیر شبکه را دنبال می‌کند. SD-WAN نیز برای مدیریت ارتباطات گسترده و انتخاب مسیرها بر اساس سیاست‌ها استفاده می‌شود. هیچ‌یک از این دو را نباید صرفاً یک پروتکل ارتباطی هم‌ردیف HTTP یا BGP معرفی کرد. برای آشنایی بیشتر می‌توانید مقاله شبکه‌های تعریف‌شده توسط نرم‌افزار (SDN) را بخوانید.

پروتکل‌ها و فناوری‌های مرتبط

  • BGP: پروتکل مسیریابی برای تبادل اطلاعات مسیر میان سامانه‌های مستقل؛ ممکن است در ارتباطات بین شبکه‌ها و سرویس‌های اتصال ابری استفاده شود.
  • IPsec: مجموعه‌ای از فناوری‌ها برای حفاظت از ترافیک IP که در بسیاری از پیاده‌سازی‌های VPN کاربرد دارد.
  • TLS: برای محافظت از ارتباط در لایه انتقال کاربردی، مانند ارتباطات HTTPS، استفاده می‌شود؛ جایگزین طراحی صحیح مسیر شبکه یا قواعد فایروال نیست.
  • VXLAN و Geneve: فناوری‌های کپسوله‌سازی برای ساخت شبکه‌های Overlay روی زیرساخت IP هستند؛ استفاده از آنها وابسته به معماری و پشتیبانی پلتفرم است.
  • DNS و DHCP: به‌ترتیب در نام‌یابی سرویس‌ها و تنظیم پارامترهای آدرس‌دهی نقش دارند؛ روش مدیریت آنها در محیط‌های ابری می‌تواند با شبکه سنتی تفاوت داشته باشد.

اصول امنیت در شبکه ابری

  • حداقل دسترسی: پورت‌ها و مبدأهای مجاز را به نیاز واقعی محدود کنید و قواعد عمومی و بدون دلیل مانند باز بودن همه پورت‌ها را به کار نبرید.
  • تفکیک شبکه: محیط توسعه، آزمایش و تولید و همچنین اجزای وب، برنامه و داده را متناسب با ریسک جدا کنید.
  • کاهش سطح در معرض اینترنت: آدرس عمومی را فقط برای اجزایی در نظر بگیرید که واقعاً به ورودی عمومی نیاز دارند؛ روش دسترسی مدیران را نیز محدود و قابل پایش کنید.
  • هویت و دسترسی مدیریتی: دسترسی پنل‌ها و APIها را با نقش‌های مشخص، احراز هویت چندمرحله‌ای در صورت پشتیبانی و بازبینی دوره‌ای مجوزها کنترل کنید.
  • رمزنگاری و مدیریت کلید: برای انتقال داده و ارتباط شبکه‌ای متناسب با سناریو از روش امن استفاده کنید و کلیدها و اسرار را در فایل‌های عمومی یا مخازن کد قرار ندهید.
  • پایش و پاسخ به رخداد: لاگ‌ها را نگهداری کنید، هشدارهای مهم را آزمایش کنید و روند مشخصی برای بررسی و مهار رخداد داشته باشید.
  • مسئولیت مشترک: ارائه‌دهنده بخشی از زیرساخت را تأمین و محافظت می‌کند؛ پیکربندی شبکه، مجوزها، داده‌ها و بسیاری از تنظیمات سرویس همچنان به مسئولیت مشتری وابسته‌اند.

مراحل عملی پیاده‌سازی شبکه ابری

  1. نیازمندی را ثبت کنید: برنامه‌ها، تعداد کاربران، مسیرهای ارتباطی، نیاز به دسترسی عمومی، حساسیت داده، الزامات قانونی و روش پشتیبانی را مشخص کنید.
  2. ارائه‌دهنده و منطقه را انتخاب کنید: امکانات شبکه، هزینه انتقال داده، محدودیت سرویس‌ها، محل داده و نیازهای سازمان را مقایسه کنید. راهنمای معرفی مایکروسافت آژور و قابلیت‌های آن برای بررسی یکی از پلتفرم‌ها نقطه شروع مناسبی است.
  3. طرح IP بنویسید: محدوده VPC/VNet و زیرشبکه‌ها را با شبکه داخلی و اتصال‌های موجود تطبیق دهید و برای رشد آینده فضای کافی کنار بگذارید.
  4. نقشه جریان ترافیک رسم کنید: مسیر ارتباط کاربر تا برنامه و پایگاه داده، خروج به اینترنت، دسترسی مدیر و اتصال با محیط داخلی را مشخص کنید.
  5. زیرشبکه و مسیرها را بسازید: نقش هر زیرشبکه، جدول مسیر مرتبط و دروازه‌های لازم را طبق طراحی تعریف کنید. از باز کردن مسیرهایی که نیاز مشخص ندارند خودداری کنید.
  6. قواعد امنیتی را تنظیم کنید: دسترسی‌های ورودی و خروجی، سیاست‌های دیواره آتش، دسترسی مدیریتی و جداسازی داده را قبل از انتقال بار کاری آزمایش کنید.
  7. ارتباط سازمانی را برقرار کنید: در صورت نیاز VPN یا اتصال اختصاصی را راه‌اندازی و مسیرهای هر دو سمت، DNS و قواعد امنیتی را هماهنگ کنید.
  8. پایداری را طراحی کنید: نقاط شکست، وابستگی به یک دروازه یا یک نمونه، بازیابی پس از قطعی و گزینه‌های چند ناحیه‌ای را متناسب با هدف دسترس‌پذیری بررسی کنید. چند ناحیه‌ای بودن به‌تنهایی تضمین پایداری نیست؛ باید رفتار برنامه و مسیرهای وابسته نیز آزموده شود.
  9. آزمایش کنید: اتصال مجاز و غیرمجاز، مسیر برگشت، حل نام DNS، خروجی اینترنت، ثبت لاگ و سناریوهای قطعی را آزمایش و مستند کنید.
  10. هزینه و تغییرات را کنترل کنید: ترافیک خروجی، لینک اختصاصی، دروازه‌های NAT، توازن بار، لاگ‌ها و منابع بلااستفاده را دوره‌ای بررسی کنید و تغییرات را قابل بازبینی نگه دارید.

خطاهای رایج در طراحی شبکه ابری

  • انتخاب محدوده IP بدون بررسی شبکه دفترها، VPN و ابرهای دیگر؛ نتیجه می‌تواند هم‌پوشانی و شکست مسیریابی باشد.
  • قرار دادن پایگاه داده یا پنل مدیریتی در معرض اینترنت، در حالی که دسترسی خصوصی کافی است.
  • ساختن قواعد امنیتی گسترده برای رفع سریع مشکل و فراموش کردن محدودسازی آنها پس از عیب‌یابی.
  • بررسی فقط مسیر رفت و بی‌توجهی به مسیر برگشت، ترجمه آدرس یا قواعد سمت مقابل.
  • نادیده گرفتن DNS خصوصی، کش نام‌ها و تفاوت تنظیمات محیط آزمایش با تولید.
  • فرض اینکه ایجاد VPN به‌تنهایی همه ارتباط‌ها را برقرار می‌کند؛ آدرس‌دهی، مسیریابی، قواعد امنیتی و مجوزهای مقصد همچنان ضروری‌اند.
  • نبود لاگ و مستندات، یا نداشتن مسئول مشخص برای پاسخ به هشدارها.
  • اعلام درصد ثابت صرفه‌جویی یا آپ‌تایم بدون تعریف بار کاری، معماری، تعهد سرویس و داده اندازه‌گیری‌شده. هزینه و دسترس‌پذیری باید بر اساس شرایط واقعی هر پروژه سنجیده شود.

شبکه ابری، دیتاسنتر و سرور VPS چه تفاوتی دارند؟

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

پرسش‌های متداول

آیا شبکه ابری حتماً از اینترنت عمومی استفاده می‌کند؟

خیر. برخی ارتباطات از اینترنت عبور می‌کنند، اما می‌توان با توجه به قابلیت‌های ارائه‌دهنده از اتصال‌های خصوصی، VPN یا لینک اختصاصی نیز استفاده کرد. انتخاب مسیر باید بر اساس نیاز امنیتی، عملکرد، هزینه و دسترس‌پذیری انجام شود.

آیا ساخت VPC یا VNet به‌تنهایی شبکه را امن می‌کند؟

خیر. شبکه خصوصی یک مرز منطقی فراهم می‌کند، اما امنیت نهایی به قواعد دسترسی، مسیرها، مدیریت هویت، تنظیم سرویس‌ها، پایش و به‌روزرسانی مستمر وابسته است.

برای سازمان کوچک هم طراحی شبکه ابری لازم است؟

بله، اما میزان پیچیدگی باید متناسب باشد. حتی در یک پروژه کوچک نیز طرح IP، حداقل دسترسی، جداسازی داده حساس، روش پشتیبان‌گیری و راه بازیابی باید روشن باشند. از طراحی پیچیده‌ای که نیازی به آن وجود ندارد نیز باید پرهیز کرد.

برای انتخاب بین VPN و اتصال اختصاصی چه باید کرد؟

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

جمع‌بندی

شبکه ابری صرفاً انتقال سرورها به یک ارائه‌دهنده نیست؛ باید آدرس‌دهی، تفکیک منابع، مسیرهای ترافیک، قواعد امنیت، اتصال به شبکه سازمان، DNS و پایش به‌صورت هماهنگ طراحی شوند. شروع از نیازمندی‌های واقعی، مستندسازی جریان ترافیک و آزمایش مسیرهای مجاز و غیرمجاز، احتمال بروز خطاهای پرهزینه را کاهش می‌دهد. برای پایداری نیز معماری، وابستگی‌های برنامه و روش بازیابی باید با هم بررسی شوند؛ هیچ عدد ثابتی بدون توجه به طراحی و سطح سرویس، هزینه یا آپ‌تایم یکسانی را تضمین نمی‌کند.

منابع فنی برای مطالعه بیشتر

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