قانون EC2 فقط برای VPN: هر گروه امنیتی متصل باید هم‌نظر باشد
گروه‌های امنیتی فقط اجازه می‌دهند و هر گروه متصل اجازه خودش را اضافه می‌کند. پیش از افزودن یک قانون تنگ VPN، منبعی را که نمونه واقعاً می‌بیند مشخص کنید.
یک قانون ورودی برای استخر کلاینت‌های VPN اضافه می‌کنید، چیزی حذف نمی‌کنید و سرویس همچنان از اینترنت قابل دسترسی است. هیچ چیز خراب نیست. یک گروه امنیتی هیچ بازنویسی، اولویت یا رد نهایی ندارد که قانون تنگ بتواند بر آن پیروز شود. هر گروهی که به نمونه متصل است اجازه‌های خودش را به یک مجموعه ترکیبی می‌افزاید و قانون گسترده‌ای که فراموش کرده‌اید هنوز در همان مجموعه است. فقط-VPN کردن نمونه یعنی بازرسی همه آن‌ها، نه افزودن یک قانون خوش‌صداتر به یکی از آن‌ها.
پیش از نوشتن قانون، سرویس را بنویسید
با مقصد، پروتکل و پورت دقیق و همچنین رابط شبکه‌ای که سرویس واقعاً روی آن گوش می‌دهد شروع کنید. نمونه‌ای با چند رابط یا چند سرویس روی یک پورت نیازمند اجرای بازرسی برای هر رابط است، چون گروه‌های متصل می‌توانند متفاوت باشند. سپس مشخص کنید آن رابط واقعاً کدام نشانی مبدأ را برای کاربر VPN دریافت می‌کند، نه نشانی‌ای که کلاینت در پنجره اتصال خودش نشان می‌دهد.
این دو نشانی وقتی ترجمه و مسیریابی وارد ماجرا می‌شوند، بیش از آنچه مردم انتظار دارند از هم فاصله می‌گیرند.
سه مدل منبع، سه قانون متفاوت
با دسترسی مسیریابی‌شده خصوصی، نمونه استخر کلاینت یا محدوده شرکت را دریافت می‌کند، بسته به اینکه مسیر چگونه مسیریابی و ترجمه شود. با یک نقطه پایانی عمومی که از طریق خروجی شرکت به آن می‌رسند، نمونه به جای آن نشانی NAT شرکت را می‌بیند و فقط اگر آن مقصد واقعاً از مسیر VPN استفاده کند، چون تونل تقسیم‌شده می‌تواند آن را روی یک اتصال خانگی بگذارد. با نقطه پایانی مدیریت‌شده Client VPN، مدل مستندشده پیوند و شبکه هدف اعمال می‌شود و نشانی کلاینت از CIDR کلاینت پیکربندی‌شده می‌آید.
چیزی که کار نمی‌کند، ارجاع دادن به دروازه VPN به‌عنوان منبع گروه امنیتی است. ارجاع‌های گروهی با رابط‌های شبکه الاستیک داخل VPC یا یک شبکه همتا مطابقت دارند و دروازه‌ای که بسته‌ها را هدایت می‌کند یکی از آن‌ها نیست.
اجتماع را در همه گروه‌های متصل بخوانید
نمونه را باز کنید، رابط شبکه آن را پیدا کنید و هر گروه امنیتی متصل به آن را فهرست کنید. برای هر یک، هر قانونی را که پروتکل و پورت شما را پوشش می‌دهد بررسی کنید، از جمله محدوده‌های پورت گسترده و هر دو خانواده نشانی. یک قانون IPv4 از 0.0.0.0/0 شما را از بررسی ::/0 معاف نمی‌کند و قانونی که همه ترافیک را مجاز می‌کند مسئله پورت را کاملاً پنهان می‌کند. تنها پس از این فهرست می‌توانید بگویید اجازه مؤثر برای سرویس چیست.
مرجع قوانین AWS گروه‌های امنیتی را فقط-مجاز توصیف می‌کند و می‌گوید قوانین همه گروه‌های متصل تجمیع می‌شوند، که همان کل سازوکار پشت این شکست است.
ACLهای شبکه یک سیاست جداگانه و بی‌حالت با ورودی‌های مرتب مجاز و رد هستند و روی زیرشبکه ارزیابی می‌شوند، نه روی نمونه.
با دیوار رد پاسخ ندهید
افزودن یک رد NACL در سطح زیرشبکه برای تقلید از فایروالی که به آن عادت دارید ابزار اشتباه و پرخطری است. ورودی‌های NACL مرتب و بی‌حالت هستند، پس ردی که بالای یک مجوز موجود قرار بگیرد بی‌صدا ترافیک نامرتبط را می‌شکند، از جمله مسیر بازگشت نشست‌هایی که می‌خواستید نگه دارید. مجوز گسترده گروه امنیتی را در همان گروهی که مالک آن است درست کنید و سپس ACL را رها کنید مگر اینکه واقعاً بخشی از طراحی باشد.
حذف یک نشانی عمومی از نمونه تضمین قوی‌تری است و همچنین تغییری معماری با پیامدهای مدیریتی و کاربردی است، نه یک تیک در فهرست مجاز.
با نشستی تازه آزمایش کنید و راهی برای ورود نگه دارید
پیش از کنار گذاشتن هر مجوز موجود، یک مسیر مدیریتی مستقل و تأییدشده را تأیید کنید، چون قانونی که می‌خواهید حذف کنید ممکن است همان باشد که بازیابی نشست شما به آن وابسته است. سپس یک اتصال مجاز تازه از VPN و یک اتصال ردشده تازه از یک مسیر آزمایشی مجاز و غیر VPN را امتحان کنید. نشست‌های ردیابی‌شده موجود به گونه‌ای از تغییر قوانین جان سالم به در می‌برند که پوسته‌های باز قدیمی را به‌عنوان شاهد پذیرش بی‌فایده می‌کند.
در پایان، مجوز خود برنامه را سر جایش نگه دارید. یک خروجی شرکتی ترجمه‌شده می‌تواند نماینده صدها نفر باشد و پذیرش شبکه هرگز کاربری فردی یا دستگاه او را شناسایی نکرده است.