معرفی
این راهنما بر پایه مستندات رسمی پروژه نوشته شده و هدف آن ساختن یک مدل ذهنی دقیق برای طراحی، عملیات و عیب‌یابی است.
نکته 1
Set برای نگهداری مجموعه address، port یا tuple مفید است و ruleهای تکراری را کم می‌کند.
نکته 2
Map می‌تواند key را مستقیماً به value یا verdict وصل کند.
نکته 3
timeout و dynamic set برای بعضی workflowها مفیدند اما state و memory usage باید پایش شوند.
برداشت عملیاتی IROSG
قبل از هر تغییر Production، نسخه، وابستگی، سطح دسترسی، rollback و observability را بررسی کنید. منبع رسمی همین صفحه مرجع اصلی جزئیات است.
چرا فهرست داده را از منطق تصمیم جدا کنیم؟
فرض کنید ده‌ها نشانی مجاز برای دسترسی به یک سرویس مدیریتی دارید. نوشتن یک قاعده جدا برای هر نشانی، بازبینی و تغییر را دشوار می‌کند. مجموعه می‌تواند نشانی‌ها را به عنوان داده نگه دارد و یک قاعده عضویت در آن را بررسی کند. در این مدل، منطق «عضو مجموعه اجازه دارد» از فهرست اعضا جدا می‌شود. این جداسازی باعث می‌شود تغییر یک نشانی نیازمند بازنویسی مجموعه بزرگی از قواعد مشابه نباشد و تفاوت نسخه‌ها نیز خواناتر شود.
با این حال، کوتاه شدن فایل به خودی خود به معنای درست شدن سیاست نیست. اگر قاعده در زنجیره یا نقطه نامناسب قرار گیرد، مجموعه کاملاً درست هم اثر مورد انتظار ندارد. پیش از تبدیل قواعد، مسیر بسته، خانواده آدرس، جهت ارتباط و ترتیب تصمیم‌ها را مشخص کنید. هدف نخست حفظ معنای سیاست موجود است. پس از اثبات برابری رفتار، می‌توان درباره نگهداری آسان‌تر یا عملکرد در بار واقعی قضاوت کرد؛ عنوان «سریع‌تر» را نباید به تضمین عددی برای هر محیط تبدیل کرد.
مجموعه بی‌نام و مجموعه نام‌دار
مجموعه بی‌نام به قاعده‌ای که در آن نوشته شده وابسته است و برای فهرست کوچک و ثابت کاربرد ساده‌ای دارد. مجموعه نام‌دار یک شیء قابل ارجاع است و می‌توان اعضای آن را در چارچوب امکانات مربوط مدیریت کرد. اگر فهرست از یک فرایند بیرونی به‌روز می‌شود، نام‌دار بودن معمولاً ساختار روشن‌تری ایجاد می‌کند. انتخاب میان این دو را بر اساس چرخه تغییر انجام دهید، نه صرفاً کوتاه‌تر بودن نحو یکی از آنها.
برای مثال، دو پورت ثابت یک سرویس می‌توانند در یک مجموعه کوچک داخل قاعده قرار گیرند، در حالی که فهرست نشانی‌های موقت مجاز بهتر است مالکیت و روش به‌روزرسانی مستقلی داشته باشد. نام مجموعه باید هدف آن را بیان کند؛ نامی مانند «نشانی‌های مدیریت» از نام مبهم «فهرست یک» قابل فهم‌تر است. همچنین در مستند مشخص کنید چه سامانه‌ای حق تغییر اعضا را دارد. جدا شدن داده از منطق، نیاز به کنترل تغییر داده را از بین نمی‌برد.
نوع داده و خانواده آدرس
مجموعه نوع دارد و این نوع باید با عبارتی که در قاعده بررسی می‌شود سازگار باشد. نشانی IPv4، نشانی IPv6 و شماره پورت داده یکسانی نیستند. اگر سیاست هر دو خانواده آدرس را پوشش می‌دهد، آنها را صریح طراحی و آزمایش کنید. اعمال محدودیت برای IPv4 و فراموش کردن IPv6 می‌تواند رفتار متفاوتی ایجاد کند که در آزمون معمول دیده نشود. وجود جدول مشترک به تنهایی به معنای پوشش خودکار همه حالت‌ها نیست.
در ورود داده از منبع بیرونی، هر عضو را پیش از اعمال اعتبارسنجی کنید. یک رشته نامعتبر، بازه اشتباه یا مقدار خارج از نوع می‌تواند به شکست به‌روزرسانی منجر شود. تصمیم بگیرید هنگام خطای منبع، مجموعه قبلی حفظ شود یا سیاست دیگری اجرا شود. خالی کردن فهرست و سپس تلاش برای پر کردن آن، اگر مرحله دوم شکست بخورد، ممکن است وضعیت ناخواسته بسازد. این رفتار باید در طراحی فرایند به‌روزرسانی دیده شود، نه اینکه پس از حادثه کشف شود.
بازه‌ها و معنای پوشش
برای نگهداری زیرشبکه یا بازه، امکانات مربوط به interval می‌توانند مناسب باشند، اما باید مرزها دقیق بررسی شوند. یک زیرشبکه بزرگ‌تر از نیاز ممکن است میزبان‌های ناخواسته را نیز شامل کند. هنگام بازبینی، فقط تعداد اعضا را نبینید؛ گستره واقعی نشانی‌های پوشش‌داده‌شده مهم است. یک عضو به شکل زیرشبکه می‌تواند بسیار بیشتر از چند نشانی منفرد را مجاز یا مسدود کند. بنابراین خلاصه‌سازی داده باید معنای امنیتی را حفظ کند.
برای آزمون، نشانی داخل بازه، نخستین و آخرین مرز و یک نشانی بیرون آن را بررسی کنید. اگر چند بازه هم‌پوشان دارید، نتیجه را با هدف اصلی مقایسه کنید و از اتکا به ظاهر فایل پرهیز کنید. تولید خودکار فهرست باید همراه با آزمون باشد، زیرا خطای تبدیل پیشوند یا ماسک می‌تواند دامنه زیادی را تحت تأثیر قرار دهد. خروجی بازبینی بهتر است تغییر پوشش را نیز نشان دهد، نه فقط تعداد خط‌های اضافه و حذف‌شده را.
Map و Verdict Map چه تفاوتی با Set دارند؟
مجموعه به پرسش عضویت پاسخ می‌دهد، در حالی که نگاشت یک کلید را به مقدار مرتبط وصل می‌کند. در کاربرد مناسب، این ساختار می‌تواند چند قاعده مشابه را به یک رابطه داده‌ای تبدیل کند. نگاشت تصمیم نیز می‌تواند نتیجه‌ای مانند انتقال به زنجیره مناسب را بر اساس کلید انتخاب کند. این قدرت زمانی مفید است که رابطه ساده و قابل توضیح بماند. تبدیل همه منطق به یک نگاشت بزرگ و مبهم، الزاماً نگهداری را آسان‌تر نمی‌کند.
مثلاً اگر چند دسته ورودی باید به زنجیره‌های جدا بروند، نگاشت می‌تواند انتخاب را بیان کند. اما مسئولیت زنجیره مقصد و رفتار کلید ناموجود باید روشن باشد. نبود تطبیق را با رد خودکار اشتباه نگیرید؛ ادامه مسیر بسته به ساختار قواعد وابسته است. در آزمون، هم کلید موجود و هم کلید ناموجود را بررسی کنید. این حالت دوم اغلب فراموش می‌شود و می‌تواند تفاوت مهمی میان انتظار نویسنده و رفتار واقعی فایروال نشان دهد.
tuple برای ترکیب چند شرط
گاهی مجوز به ترکیب مبدأ و پورت وابسته است، نه به هر کدام به صورت مستقل. اگر دو مجموعه جدا داشته باشید، ممکن است ناخواسته همه ترکیب‌های اعضای آنها مجاز شوند. ساختار ترکیبی می‌تواند رابطه دقیق میان چند فیلد را بیان کند. پیش از استفاده، جدول کوچکی از ترکیب‌های مجاز و غیرمجاز بنویسید. این جدول کمک می‌کند مشخص شود هدف ضرب همه گزینه‌هاست یا فقط جفت‌های مشخص باید پذیرفته شوند.
برای نمونه آموزشی، یک میزبان فقط به سرویس اول و میزبان دیگر فقط به سرویس دوم دسترسی داشته باشد. چهار ترکیب را آزمایش کنید و انتظار هر کدام را از قبل بنویسید. اگر فقط دو مسیر مجاز را امتحان کنید، ممکن است دو ترکیب ناخواسته باز باقی بمانند. این روش آزمون برای سیاست‌های ترکیبی بسیار مهم است، زیرا کوتاهی نحو می‌تواند پوشش واقعی را از دید بازبین پنهان کند. خوانایی باید با توضیح رابطه داده‌ها تقویت شود.
زمان انقضا و اعضای پویا
عضو دارای زمان انقضا برای دسترسی یا وضعیت موقت مفید است، اما باید بدانید ساعت شروع و تمدید آن چگونه تعیین می‌شود. افزودن دوباره عضو و به‌روزرسانی آن ممکن است در سناریوی مورد نظر معنای متفاوت داشته باشند و جزئیات باید با مستندات نسخه تطبیق داده شوند. اگر هدف دسترسی موقت مدیر است، پایان زمان باید واقعاً مسیر تازه را محدود کند. همچنین ارتباط‌های موجود ممکن است تحت تأثیر قواعد وضعیت اتصال قرار گیرند و لازم است جدا بررسی شوند.
مجموعه‌ای که از مسیر بسته‌ها رشد می‌کند باید حد و چرخه پاک‌سازی روشن داشته باشد. بدون محدودیت مناسب، حجم وضعیت می‌تواند افزایش یابد و مصرف حافظه مهم شود. تعیین اندازه، زمان انقضا و رفتار هنگام پر شدن، بخشی از طراحی است. برای آزمایش، تعداد محدودی ورودی مصنوعی در محیط جدا ایجاد کنید و رشد و حذف آنها را مشاهده کنید. از این تمرین نتیجه بگیرید چه شاخصی برای هشدار لازم است و چه کسی در صورت پر شدن مجموعه اقدام می‌کند.
Conntrack و ترتیب قواعد
اگر قاعده پذیرش ارتباط‌های برقرار در ابتدای زنجیره قرار دارد، حذف نشانی از مجموعه ممکن است اتصال موجود را مانند اتصال تازه ارزیابی نکند. این تفاوت باید در انتظار عملیات دیده شود. آزمون با یک نشست قدیمی و یک اتصال تازه را جدا انجام دهید. اگر هدف قطع فوری همه ارتباط‌هاست، طراحی پیچیده‌تر از حذف یک عضو خواهد بود و باید اثر بر وضعیت اتصال و سرویس‌های دیگر بررسی شود. تغییر عجولانه وضعیت همه اتصال‌ها می‌تواند اختلال گسترده ایجاد کند.
همچنین مسیر ورودی به میزبان با عبور بسته از میزبان مسیریاب یکی نیست. قاعده درست در زنجیره نامناسب ممکن است هیچ بسته مرتبطی نبیند. شمارنده‌ها و رهگیری محدود می‌توانند نشان دهند بسته واقعاً از کجا عبور می‌کند. پیش از افزودن استثنای تازه، همین مسیر را ثابت کنید. اگر شمارنده قاعده صفر است، ممکن است مشکل از مجموعه نباشد؛ بسته اصلاً به آن قاعده نرسیده یا پیش از آن تصمیم دیگری گرفته شده است.
اعمال تغییر به صورت قابل بازگشت
برای مدیریت دوردست، مسیر بازیابی مستقل داشته باشید و نشست موجود را تنها تضمین دسترسی ندانید. پیکربندی پیشنهادی را از نظر نحو بررسی کنید و در محیط آزمایشی با همان خانواده جدول و نسخه امتحان کنید. قابلیت بررسی بدون اعمال برای کشف خطای نحوی مفید است، اما صحت معنای سیاست را ثابت نمی‌کند. آزمون واقعی باید دسترسی مجاز و غیرمجاز را از مبدأهای مناسب بررسی کند. یک فایل پذیرفته‌شده می‌تواند از نظر امنیتی یا عملیاتی همچنان اشتباه باشد.
به‌روزرسانی گروهی را طوری طراحی کنید که حالت میانی ناخواسته ایجاد نشود. نسخه قبلی داده و منطق را نگه دارید و نقطه بازگشت مشخص داشته باشید. پس از اعمال، پیکربندی فعال را بخوانید و با انتظار مقایسه کنید؛ موفقیت ابزار مدیریت پیکربندی به تنهایی کافی نیست. برای مجموعه‌های تولیدشده از خوراک بیرونی، زمان آخرین دریافت موفق و تعداد اعضا را پایش کنید تا کهنه شدن یا خالی شدن ناگهانی فهرست دیده شود.
سنجش عملکرد بدون ادعای کلی
اگر هدف کاهش هزینه پردازش است، بار و مجموعه داده واقعی را در محیط مناسب بازسازی کنید. تعداد قواعد، تعداد اعضا، الگوی تطبیق و نوع بسته‌ها را ثابت نگه دارید و فقط ساختار مورد بررسی را تغییر دهید. علاوه بر نرخ عبور، مصرف پردازنده و تأخیر را بسنجید. نتیجه یک اندازه‌گیری محلی را به همه هسته‌ها، نسخه‌ها یا شبکه‌ها تعمیم ندهید. ساختار داده مناسب می‌تواند کمک کند، اما اندازه سود به زمینه وابسته است.
در گزارش نهایی، خوانایی و صحت سیاست را کنار عملکرد بیاورید. اگر فایل کوتاه‌تر شده ولی تیم دیگر نمی‌تواند رفتار کلید ناموجود یا زمان انقضا را توضیح دهد، بخشی از هزینه به عیب‌یابی آینده منتقل شده است. مثال‌های مجاز و غیرمجاز را کنار تنظیمات نگه دارید و پس از هر تغییر مهم دوباره اجرا کنید. مجموعه و نگاشت زمانی ارزشمندند که هم مسیر تصمیم روشن‌تر شود و هم داده تغییرپذیر با کنترل و شواهد مناسب مدیریت شود.
