فایروال ابری چیست؟ طراحی Rule های ورودی و خروجی برای سرورهای Cloud

باز گذاشتن یک Port روی سرور ابری فقط یک تنظیم شبکه نیست؛ در عمل تعیین می‌کند چه سیستمی، از چه مبدأیی و با چه پروتکلی اجازه ارتباط با سرور را داشته باشد. بسیاری از خطاهای امنیتی زمانی ایجاد می‌شوند که Ruleهای فایروال بیش از حد عمومی تعریف شده‌اند؛ مثلاً SSH ،RDP یا Database از تمام اینترنت قابل دسترسی است. فایروال ابری این سطح دسترسی را در لایه شبکه کنترل می‌کند، اما امنیت واقعی زمانی شکل می‌گیرد که Inbound و Outbound Rule ها بر اساس نیاز واقعی هر سرویس طراحی شوند.

فایروال ابری چیست؟

فایروال ابری یک کنترل امنیتی شبکه است که مشخص می‌کند چه ترافیکی اجازه ورود به منابع Cloud یا خروج از آن‌ها را دارد. Ruleها معمولا براساس Direction ،Protocol ،Port ،Source و Destination تعریف می‌شوند. طراحی امن به‌جای بازکردن عمومی پورت‌ها از اصل Least Privilege استفاده می‌کند؛ یعنی فقط ارتباطی مجاز است که واقعاً برای سرویس لازم باشد. برای مثال HTTPS می‌تواند عمومی باشد، اما SSH ،Database و Redis بهتر است فقط از IPهای مدیریتی یا شبکه خصوصی قابل دسترسی باشند.

فایروال ابری چگونه کار می‌کند؟

فایروال ترافیک شبکه را با Ruleهایی مقایسه می‌کند که برای هر مسیر تعریف شده‌اند. یک Rule معمولا به چند سوال پاسخ می‌دهد:

• ترافیک ورودی است یا خروجی؟
• پروتکل TCP ،UDP ،ICMP یا نوع دیگری است؟
• کدام Port یا Port Range مجاز است؟
• Source چه IP یا Subnetی است؟
• Destination کدام سرور یا شبکه است؟
• Rule چه Priority دارد؟

در فایروال شبکه ویراک نیز Ruleهای Inbound و Outbound با مؤلفه‌هایی مانند نوع ترافیک، پروتکل، پورت‌های باز، Source Address و Destination Address تعریف می‌شوند و Priority Ruleها در پردازش اهمیت دارد. مستندات ویراک همچنین از ایجاد Ruleهای هم‌پوشان جلوگیری می‌کند.

این قابلیت بخشی از شبکه ابری ویراک است که در آن Virtual Router، شبکه خصوصی، VLAN و فایروال مجازی برای کنترل ترافیک منابع Cloud در کنار یکدیگر قرار می‌گیرند.

تفاوت Inbound Rule و Outbound Rule چیست؟

Inbound یا Ingress ترافیکی است که به سمت سرور یا شبکه شما وارد می‌شود. برای مثال اتصال کاربر به پورت 443 وب‌سرور یا اتصال مدیر سیستم به SSH ترافیک ورودی محسوب می‌شود.

Outbound یا Egress ارتباطی است که از سرور به مقصد دیگری آغاز می‌شود؛ مانند اتصال سرور به یک API خارجی، Repository نرم افزار یا DNS Resolver.

NIST توصیه می‌کند سیاست فایروال هر دو جهت ورودی و خروجی را پوشش دهد و ترافیکی که صراحتاً موردنیاز نیست، مجاز نشود.

Rule های ورودی را چگونه طراحی کنیم؟

اصل پایه این است:

سرویس را باز کنید، نه کل سرور را.

برای یک Web Server عمومی معمولا پورت‌های 80 و 443 باید از اینترنت در دسترس باشند. اما همین منطق برای Port مدیریتی قابل دفاع نیست.

SSH و RDP را برای همه اینترنت باز نکنید

Ruleهایی مانند:

0.0.0.0/0 → TCP 22

یا:

0.0.0.0/0 → TCP 3389

سطح حمله را بدون دلیل افزایش می‌دهند.

بهتر است SSH یا RDP فقط از IP ثابت مدیر، Bastion Host یا VPN سازمانی مجاز باشد. اگر مدیریت از چند موقعیت انجام می‌شود، ایجاد ارتباط امن از طریق VPN یا تونل زنی در سرور معمولا از بازکردن عمومی Port مدیریت قابل‌کنترل‌تر است.

دیتابیس را Public نکنید مگر واقعاً لازم باشد

در معماری سه‌لایه معمول، Database مستقیماً به اینترنت نیاز ندارد.

ساختار مطلوب‌تر:

Internet → Load Balancer/Web → App → Database

در این حالت PostgreSQL روی 5432 یا MySQL روی 3306 فقط باید Sourceهای Application را بپذیرد.

شبکه خصوصی در Cloud برای همین جداسازی مهم است. ویراک امکان ایجاد شبکه‌های خصوصی Layer 2 و Layer 2+3 را برای ارتباط داخلی Instanceها فراهم می‌کند.

Outbound Rule را هم جدی بگیرید

یکی از اشتباهات رایج این است که Inbound به‌دقت محدود شود ولی تمام Outbound Traffic آزاد باقی بماند.

محدود کردن Egress می‌تواند جلوی بعضی ارتباطات ناخواسته را بگیرد؛ اما طراحی بیش از حد سخت‌گیرانه بدون شناخت Dependencies نیز ممکن است Update سیستم عامل، DNS، APIهای خارجی، Monitoring یا Backup را مختل کند.

بنابراین قبل از محدود کردن Outbound باید مشخص شود Application واقعاً با چه مقصدهایی ارتباط دارد.

برای مثال ممکن است سرور فقط به این موارد نیاز داشته باشد:

• DNS Resolver
• Repositoryهای سیستم عامل
• سرویس Monitoring
• Object Storage
• APIهای مشخص
• Database داخلی

هدف این نیست که تمام Outbound را کورکورانه ببندیم؛ هدف شناخت و کنترل ارتباطات ضروری است.

Stateful و Stateless Firewall چه تفاوتی دارند؟

این موضوع هنگام طراحی Return Traffic مهم است.

فایروال Stateful وضعیت Connection را دنبال می‌کند و معمولا پاسخ مربوط به یک Connection مجاز را به‌عنوان بخشی از همان Session تشخیص می‌دهد. AWS Security Group برای نمونه Stateful است؛ پاسخ ترافیک مجاز را بدون نیاز به Rule جداگانه برای مسیر برگشت مدیریت می‌کند.

در Firewall یا ACLهای Stateless، مسیر رفت و برگشت مستقل بررسی می‌شود و ممکن است برای Return Traffic نیز Rule لازم باشد.

بنابراین رفتار Stateful را برای هر Cloud Provider فرض نکنید. قبل از طراحی Rule باید مستندات همان سرویس بررسی شود. مستندات فعلی فایروال ویراک Direction، Priority، Source، Destination، Protocol و Port را مشخص می‌کند، اما از این اطلاعات به‌تنهایی نباید نتیجه گرفت که رفتار Connection Tracking دقیقاً مشابه AWS است.

Priority Rule چرا اهمیت دارد؟

وقتی چند Rule به یک جریان ترافیک مربوط باشند، ترتیب ارزیابی می‌تواند نتیجه نهایی را تغییر دهد.

به همین دلیل بهتر است ساختار Priority از ابتدا منظم باشد و بین اعداد فاصله باقی بماند؛ مثلاً 100، 200 و 300 تا بتوان بعداً Rule جدیدی میان آن‌ها قرار داد.

همچنین Ruleها باید نام و توضیح مشخص داشته باشند:

allow-web-https-public

بهتر از:

rule-7

است.

این موضوع در محیط Production که چند مدیر یا تیم DevOps روی شبکه کار می‌کنند اهمیت بیشتری پیدا می‌کند.

فایروال ابری با فایروال سیستم‌عامل و WAF چه تفاوتی دارد؟

این سه ابزار جایگزین یکدیگر نیستند.

Cloud Firewall در سطح شبکه Cloud ترافیک منابع را کنترل می‌کند.

Host Firewall مانند nftables، iptables یا Windows Firewall داخل خود سیستم‌عامل قرار دارد.

WAF روی Application Layer تمرکز می‌کند و برای تحلیل HTTP/HTTPS و حملاتی مانند بعضی الگوهای SQL Injection یا XSS طراحی شده است.

در نتیجه باز بودن TCP 443 در Cloud Firewall به این معنا نیست که Application از نظر امنیت وب محافظت شده است.

همین موضوع درباره DDoS نیز صدق می‌کند؛ فایروال عادی به‌تنهایی جایگزین معماری یا سرویس تخصصی DDoS Protection نیست.

NAT و Port Forwarding چه ارتباطی با فایروال دارند؟

NAT، Port Forwarding و Firewall سه مفهوم متفاوت اما مرتبط‌اند.

Port Forwarding مشخص می‌کند ترافیک یک Public IP و Port به کدام Instance و Private Port منتقل شود. مستندات ویراک نیز Port Forwarding را بر اساس Protocol، Public IP، Public Port، Instance مقصد و Private Port تعریف می‌کند.

اما اینکه ترافیک اجازه عبور داشته باشد، مسئله Firewall است.

پس:

Port Forwarding = ترافیک به کجا برود؟
Firewall = آیا اجازه عبور دارد؟

اشتباه در تفکیک این دو می‌تواند باعث شود Port Forward تعریف شده باشد اما سرویس قابل دسترسی نباشد، یا برعکس دسترسی گسترده‌تر از نیاز ایجاد شود.

نمونه Rule برای یک معماری واقعی

فرض کنید سه سرور دارید:

• Web Server
• Application Server
• Database Server

طراحی پایه می‌تواند چنین باشد:

مزیت این مدل این است که Compromise شدن یک لایه به‌معنای دسترسی آزاد به تمام زیرساخت نیست.

اشتباهات رایج در تنظیم فایروال سرور ابری

مواردی که در بازبینی Ruleها باید جدی گرفته شوند:

• بازکردن SSH یا RDP برای 0.0.0.0/0
• Public کردن PostgreSQL، MySQL یا Redis بدون نیاز
• استفاده از Any Protocol / Any Port
• فراموش کردن IPv6 در حالی که فقط IPv4 محدود شده
• اشتباه گرفتن Source و Destination
• Ruleهای قدیمی که سرویس مربوط به آن‌ها حذف شده
• نادیده گرفتن Outbound Traffic
• استفاده دائمی از Rule موقت Troubleshooting
• بی‌توجهی به Firewall داخل سیستم‌عامل
• تغییر Rule بدون تست ارتباط وابسته به آن

وجود Rule زیاد نیز لزوماً امنیت بیشتر ایجاد نمی‌کند؛ Policy پیچیده و بدون مستندات معمولاً احتمال خطای انسانی را افزایش می‌دهد.

چه زمانی فایروال ابری کافی نیست؟

Cloud Firewall برای Segmentation و کنترل دسترسی شبکه ضروری است، اما کل معماری امنیتی نیست.

برای Serverهای Production همچنان به Patch Management، SSH Key، IAM، Backup، Logging، Monitoring، Encryption و در بعضی سناریوها WAF یا DDoS Protection نیاز دارید.

همچنین ارتباط داخلی چند سرور بهتر است بدون دلیل از اینترنت عمومی عبور نکند. در شبکه ابری ویراک می‌توان Private Network، VLAN و Virtual Firewall را برای جداسازی و مدیریت ترافیک منابع ابری در یک معماری واحد به کار گرفت.

فایروال ابری زمانی مؤثر است که به‌جای مجموعه‌ای از Portهای باز، به‌عنوان Policy دسترسی شبکه طراحی شود. Rule باید مشخص کند چه Sourceی، روی چه Protocol و Portی و به چه Destinationی واقعاً نیاز دارد.

برای سرویس عمومی، دسترسی لازم را باز کنید؛ برای SSH، Database، Redis و سرویس‌های مدیریتی تا حد امکان از IP محدود یا شبکه خصوصی استفاده کنید. Outbound Rule، IPv6، Priority، NAT و Firewall سیستم‌عامل را نیز در طراحی نادیده نگیرید.

هدف نهایی یک اصل ساده است: هر ارتباطی که برای عملکرد سرویس لازم نیست، نباید صرفاً برای راحتی باز باقی بماند.

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

سوالات متداول

1. فایروال ابری چیست؟

فایروال ابری ترافیک ورودی و خروجی منابع Cloud را براساس Ruleهایی مانند Source ،Destination ،Protocol و Port کنترل می‌کند و برای محدودکردن دسترسی شبکه استفاده می‌شود.

2. Inbound Rule در فایروال چیست؟

Inbound Rule مشخص می‌کند چه ترافیکی از بیرون یا سایر شبکه‌ها اجازه ورود به سرور یا سرویس را دارد؛ مانند اجازه HTTPS روی پورت 443.

3. Outbound Rule چیست؟

Outbound Rule مشخص می‌کند سرور اجازه برقراری ارتباط با چه مقصدها، Protocolها یا Portهایی را دارد.

4. آیا باز کردن پورت 22 برای همه IPها امن است؟

برای سرور Production معمولا خیر. بهتر است SSH فقط از IPهای مدیریتی مشخص، VPN یا Bastion Host در دسترس باشد.

5. آیا Database باید از اینترنت قابل دسترسی باشد؟

در بیشتر معماری‌های Web خیر. Database بهتر است در Private Network قرار گیرد و فقط Application Serverهای مجاز به پورت آن دسترسی داشته باشند.

6. تفاوت Cloud Firewall و WAF چیست؟

Cloud Firewall عمدتاً ترافیک شبکه و Portها را کنترل می‌کند، در حالی که WAF درخواست‌های HTTP/HTTPS را در Application Layer بررسی می‌کند.

7. تفاوت Firewall و Port Forwarding چیست؟

Port Forwarding مشخص می‌کند ترافیک Public Port به کدام سرور یا Private Port منتقل شود؛ Firewall تعیین می‌کند آیا آن ترافیک اجازه عبور دارد یا خیر.

8. آیا باید Outbound Traffic سرور را محدود کنیم؟

برای محیط‌های حساس می‌تواند مفید باشد، اما باید ابتدا وابستگی‌هایی مانند DNS ،Repository ،API ،Backup و Monitoring شناسایی شوند تا سرویس ناخواسته مختل نشود.

9. آیا فایروال ابری جایگزین فایروال لینوکس است؟

خیر. Cloud Firewall و Host Firewall در لایه‌های متفاوتی کنترل ایجاد می‌کنند و در زیرساخت حساس می‌توانند به‌صورت مکمل استفاده شوند.