سلام و خوش آمدید مهندسان شبکه
در این پست وبلاگ، من امیدوارم که عملکرد اصلی گروه های امنیتی AWS، نحوه استفاده از آنها در تولید را توضیح دهم و برخی از مقایسه ها را با ویژگی های شبکه که ما به عنوان مهندسان شبکه قبلاً درک کرده ایم، انجام دهم.
گروه های امنیتی (SG) در AWS چیست؟
SG ها مانند یک فایروال یا یک ACL هستند، اگر ممکن است، که مستقیماً به یک رابط شبکه اعمال می شود. در AWS، این رابط‌های شبکه «ENI» نامیده می‌شوند، بنابراین من به آنها با نامگذاری مناسب آنها اشاره خواهم کرد. SGها، مانند بسیاری از ساختارهای فیلتر شبکه، به شما اجازه می دهند تا ترافیک مجاز ورودی یا خروجی را تعریف کنید (هر چیزی که به طور صریح اجازه داده نشده است، یک رد ضمنی وجود دارد). آنها همچنین حالتی هستند، به این معنی که وقتی یک کلاینت مکالمه را در پورتی که ما اجازه ورود به آن را داده‌ایم، اجازه نمی‌دهیم صراحتاً درگاه‌های زودگذر (خروجی) را مجاز کنیم. به عبارت ساده تر، این بدان معناست که اگر به یک کلاینت اجازه داده باشیم تا مکالمه ای را در پورت 443 آغاز کند، سرور می تواند در یک پورت زودگذر پاسخ دهد. ما نیازی به پیکربندی آن عملکرد نداریم.
کجا می توانیم از SG استفاده کنیم؟
در AWS، سرویس‌های زیادی وجود دارند که مستقیماً یک ENI را در VPC (ابر خصوصی مجازی) ما قرار می‌دهند. برای نام بردن از چند سرویس که احتمالاً بر اساس قرارداد نامگذاری آنها متوجه خواهید شد:
- نمونه‌های آمازون EC2 (ابر محاسباتی الاستیک).
- نمونه های آمازون RDS (سرویس پایگاه داده رابطه ای).
- متعادل کننده بار الاستیک آمازون (ELB)
- سیستم فایل الاستیک آمازون (EFS)
- Amazon EKS (سرویس Kubernetes Elastic)
بسیاری دیگر وجود دارد، اما اینها تنها چند سرویس هستند که در نهایت یک رابط شبکه در VPC ایجاد می کنند که شما به عنوان یک مصرف کننده، مستقیماً با آن تعامل خواهید داشت.
SG ها چگونه کار می کنند؟
SG ها به روشی از بالا به پایین ارزیابی می شوند و به منبع، مقصد و پورت نگاه می کنند تا مشخص شود که آیا یک مجوز باید رخ دهد یا نه. SG ها مانند اکثر مکانیسم های فیلترینگ ترافیک مبتنی بر قوانین عمل می کنند. چیزی برای توضیح بیشتر از این باقی نمانده است.
تنها نکته ای که باید در رابطه با نحوه کار SG ها ذکر شود زیرا منحصر به فرد آنها این است که SG ها می توانند به عنوان یک منبع یا مقصد برای سایر SG ها برای ارجاع عمل کنند. این ویژگی جالب به این معنی است که می‌توانید فیلتر ترافیک مبتنی بر «نیت» بیشتری انجام دهید و فیلتر را صرفاً بر اساس IP متوقف کنید. به عنوان مثال، ناوگانی از نمونه های EC2 (محاسبه) را در نظر بگیرید که به عنوان سرورهای وب عمل می کنند، همه از SG یکسان با قانونی استفاده می کنند که اجازه ورود به پورت 443 را می دهد. بیایید همچنین بگوییم گروهی از سرورهای پایگاه داده وجود دارند که فقط باید به سرورهای وب اجازه دهند تا در برابر آنها پرس و جوهای SQL ایجاد کنند (گروه امنیتی پایگاه داده را “databaseSecurityGroup-456” بنامیم). به جای ایجاد SG های منحصر به فرد که دارای IP های صریح تعریف شده هستند، می توانیم به سادگی به هر دو در اعلامیه مبدا و مقصد خود مراجعه کنیم.
در جدول ASCII زیر، توجه داشته باشید که گروه امنیتی وب سرور اجازه ترافیک ورودی را در پورت 443 می دهد. در خروجی، تنها مکالمه ای که وب سرور می تواند راه اندازی کند، با میزبان است که گروه امنیتی پایگاه داده روی آن و فقط در پورت 3306 اعمال می شود. در گروه امنیتی پایگاه داده، ما فقط به ترافیک از یک منبع در پورت 3306 اجازه می دهیم، و آن هم از هر میزبانی که گروه امنیتی وب سرور روی آن اعمال می شود.
+--------------------------------------------------------------------------------------------+
| webServerSecurityGroup-123 |
|--------------------------------------------------------------------------------------------|
| Inbound Rules |
|--------------------------------------------------------------------------------------------|
| Rule # | Type | Protocol | Port Range | Source |
|--------------------------------------------------------------------------------------------|
| 100 | HTTPS (443) | TCP | 443 | 0.0.0.0/0 |
|--------------------------------------------------------------------------------------------|
| Outbound Rules |
|--------------------------------------------------------------------------------------------|
| Rule # | Type | Protocol | Port Range | Destination |
|--------------------------------------------------------------------------------------------|
| 100 | MySQL/Aurora | TCP | 3306 | databaseSecurityGroup-456 |
+--------------------------------------------------------------------------------------------+
+--------------------------------------------------------------------------------------------+
| databaseSecurityGroup-456 |
|--------------------------------------------------------------------------------------------|
| Inbound Rules |
|--------------------------------------------------------------------------------------------|
| Rule # | Type | Protocol | Port Range | Source |
|--------------------------------------------------------------------------------------------|
| 100 | MySQL/Aurora | TCP | 3306 | webServerSecurityGroup-123 |
+--------------------------------------------------------------------------------------------+
ترسیم مقایسه بین شبکه های ACL و SG
به عنوان مهندس شبکه، به احتمال زیاد، شما با ACL سروکار داشته اید. من قصد دارم مقایسه‌هایی را انجام دهم و به تفاوت آنها اشاره کنم زیرا با هم تفاوت دارند، با این حال، امیدوارم که اگر هنوز نحوه عملکرد SGها را روشن نکرده‌اید، این موضوع به نتیجه برسد.
همانطور که قبلاً بیان کردم، SGها برای رابط های شبکه اعمال می شوند. به طور مشابه، ACL های سنتی را می توان به یک رابط فیزیکی یا مجازی برای محافظت/فیلتر کردن ترافیک اعمال کرد. در هر دو مورد، آنها در یک رویکرد از بالا به پایین ارزیابی می‌شوند و به هر ورودی در فهرست به دنبال منبع/مقصد/پورت منطبق و اقدامی که باید انجام شود نگاه می‌کنند. یکی از تفاوت‌های اصلی، رفتار حالتی یک ACL سنتی در مقابل یک SG است که از نظر طراحی حالتی است.
اگر کنجکاو هستید که چگونه عملکرد آنها را بیشتر بررسی کنید، لطفاً مخزن GitHub من را برای چند نمونه بررسی کنید. می‌توانید کد را پایین بکشید و این نمونه‌ها را در محیط خود مستقر کنید تا با آنها کار کنید.
