این مقاله سومین مقاله از مجموعه مقالات «چگونه کنترل زیرساخت شبکه خود را در دست بگیرید» است. محتویات تمام مقالات این مجموعه و پیوندها را می توان یافت اینجا.

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

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

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

وظیفه ما اکنون شناسایی خطرات مرتبط با امنیت در سطح شبکه و کاهش آنها به سطح معقول است.

ممیزی امنیت شبکه

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

من چندین ممیزی امنیتی شبکه ممکن را برجسته می کنم:

• ممیزی پیکربندی تجهیزات (سخت کردن)
• ممیزی طراحی امنیتی
• حسابرسی دسترسی
• ممیزی فرآیند

ممیزی پیکربندی تجهیزات (سخت کردن)

به نظر می رسد در بیشتر موارد این بهترین نقطه شروع برای ممیزی و بهبود امنیت شبکه شما باشد. IMHO، این یک نمایش خوب از قانون پارتو است (20٪ تلاش 80٪ نتیجه را ایجاد می کند و 80٪ باقی مانده تلاش فقط 20٪ نتیجه را ایجاد می کند).

نکته اصلی این است که ما معمولاً توصیه هایی از فروشندگان در مورد "بهترین شیوه ها" برای امنیت هنگام پیکربندی تجهیزات داریم. به این "سخت شدن" می گویند.

همچنین اغلب می‌توانید بر اساس این توصیه‌ها پرسشنامه‌ای پیدا کنید (یا خودتان آن را ایجاد کنید)، که به شما کمک می‌کند تا تعیین کنید پیکربندی تجهیزات شما تا چه حد با این «بهترین شیوه‌ها» مطابقت دارد و مطابق با نتیجه، تغییراتی در شبکه خود ایجاد کنید. . این به شما این امکان را می دهد که به راحتی و تقریباً بدون هیچ هزینه ای خطرات امنیتی را به میزان قابل توجهی کاهش دهید.

چندین مثال برای برخی از سیستم عامل های سیسکو.

سخت شدن پیکربندی سیسکو IOS
سخت شدن پیکربندی سیسکو IOS-XR
سخت شدن پیکربندی Cisco NX-OS
لیست چک امنیتی خط پایه Cisco

بر اساس این اسناد، لیستی از الزامات پیکربندی برای هر نوع تجهیزات می تواند ایجاد شود. به عنوان مثال، برای یک Cisco N7K VDC این الزامات ممکن است به نظر برسد پس.

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

ممیزی طراحی امنیتی

به طور معمول، یک شبکه سازمانی شامل بخش های زیر به یک شکل یا شکل دیگر است:

• DC (خدمات عمومی DMZ و مرکز داده اینترانت)
• دسترسی به اینترنت
• VPN دسترسی از راه دور
• لبه WAN
• شاخه
• پردیس (دفتر)
• هسته

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

برای هر یک از این بخش ها، الزامات امنیتی، خطرات و بر این اساس، راه حل ها متفاوت خواهد بود.

برای مشکلاتی که ممکن است از نظر طراحی امنیتی با آنها مواجه شوید، به هر یک از آنها به طور جداگانه نگاه می کنیم. البته باز هم تکرار می کنم که این مقاله به هیچ وجه تظاهر به کامل بودن نمی کند که دستیابی به آن در این موضوع واقعاً عمیق و چند وجهی آسان (اگر نه غیرممکن) نیست، اما نشان دهنده تجربه شخصی من است.

هیچ راه حل کاملی وجود ندارد (حداقل هنوز). این همیشه یک سازش است. اما مهم این است که تصمیم برای استفاده از یک رویکرد یا روش دیگر آگاهانه و با درک هر دو مزایا و معایب آن گرفته شود.

مرکز داده

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

آیا فایروال لازم است یا خیر؟

به نظر می رسد که پاسخ واضح است، اما همه چیز آنقدر که ممکن است به نظر می رسد واضح نیست. و انتخاب شما نه تنها می تواند تحت تأثیر قرار گیرد قیمت.

به عنوان مثال 1. تاخیرها

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

به عنوان مثال 2. کارایی.

توان عملیاتی سوئیچ های L3 بالا معمولاً مرتبه ای بالاتر از توان عملیاتی قوی ترین فایروال ها است. بنابراین، در مورد ترافیک با شدت بالا، به احتمال زیاد باید به این ترافیک اجازه دهید فایروال ها را دور بزند.

به عنوان مثال 3. قابلیت اطمینان.

فایروال ها، به ویژه NGFW مدرن (نسل بعدی FW) دستگاه های پیچیده ای هستند. آنها بسیار پیچیده تر از سوئیچ های L3/L2 هستند. آنها تعداد زیادی خدمات و گزینه های پیکربندی را ارائه می دهند، بنابراین جای تعجب نیست که قابلیت اطمینان آنها بسیار کمتر است. اگر تداوم سرویس برای شبکه حیاتی است، ممکن است مجبور شوید آنچه را که منجر به دسترسی بهتر می‌شود انتخاب کنید - امنیت با فایروال یا سادگی شبکه‌ای که روی سوئیچ‌ها (یا انواع مختلف پارچه) با استفاده از ACLهای معمولی ساخته شده است.

در مورد مثال های بالا، به احتمال زیاد (طبق معمول) باید مصالحه ای پیدا کنید. به راه حل های زیر نگاه کنید:

• اگر تصمیم دارید از فایروال در داخل مرکز داده استفاده نکنید، باید به این فکر کنید که چگونه دسترسی به اطراف محیط را تا حد امکان محدود کنید. به عنوان مثال، شما می توانید فقط پورت های لازم را از اینترنت (برای ترافیک مشتری) و دسترسی اداری به مرکز داده را فقط از میزبان های پرش باز کنید. در هاست های پرش، تمام بررسی های لازم را انجام دهید (تأیید هویت / مجوز، آنتی ویروس، ورود به سیستم، ...)
• می توانید از یک پارتیشن منطقی از شبکه مرکز داده به بخش هایی استفاده کنید، مشابه طرحی که در PSEFABRIC توضیح داده شده است. مثال p002. در این مورد، مسیریابی باید به گونه ای پیکربندی شود که ترافیک حساس به تاخیر یا با شدت بالا "در" یک بخش (در مورد p002، VRF) رفته و از فایروال عبور نکند. ترافیک بین بخش های مختلف از طریق فایروال ادامه خواهد داشت. همچنین می توانید از نشت مسیر بین VRF ها برای جلوگیری از هدایت ترافیک از طریق فایروال استفاده کنید
• همچنین می توانید از فایروال در حالت شفاف و فقط برای VLAN هایی استفاده کنید که این فاکتورها (تأخیر/عملکرد) قابل توجه نیستند. اما باید محدودیت های مربوط به استفاده از این مد را برای هر فروشنده به دقت مطالعه کنید
• ممکن است بخواهید از معماری زنجیره خدمات استفاده کنید. این فقط به ترافیک ضروری اجازه می دهد تا از فایروال عبور کند. از نظر تئوری خوب به نظر می رسد، اما من هرگز این راه حل را در تولید ندیده ام. ما زنجیره خدمات را برای Cisco ACI/Juniper SRX/F5 LTM حدود 3 سال پیش آزمایش کردیم، اما در آن زمان این راه حل برای ما "خام" به نظر می رسید.

سطح حفاظت

اکنون باید به این سوال پاسخ دهید که از چه ابزارهایی می خواهید برای فیلتر کردن ترافیک استفاده کنید. در اینجا برخی از ویژگی هایی که معمولاً در NGFW وجود دارد (به عنوان مثال، اینجا):

• فایروال حالتی (پیش فرض)
• فایروال برنامه
• پیشگیری از تهدید (آنتی ویروس، ضد جاسوس افزار و آسیب پذیری)
• فیلتر کردن URL
• فیلتر کردن داده ها (فیلتر محتوا)
• مسدود کردن فایل (انواع فایل مسدود شده)
• حفاظت از dos

و همه چیز هم روشن نیست. به نظر می رسد که هر چه سطح حفاظت بالاتر باشد، بهتر است. اما شما همچنین باید آن را در نظر بگیرید

• هرچه بیشتر از عملکردهای فایروال بالا استفاده کنید، طبیعتاً گرانتر خواهد بود (مجوزها، ماژول های اضافی)
• استفاده از برخی از الگوریتم ها می تواند به طور قابل توجهی توان عملیاتی فایروال را کاهش دهد و همچنین تاخیرها را افزایش دهد. اینجا
• مانند هر راه حل پیچیده، استفاده از روش های حفاظتی پیچیده می تواند قابلیت اطمینان راه حل شما را کاهش دهد، به عنوان مثال، هنگام استفاده از فایروال برنامه، با مسدود شدن برخی از برنامه های کاربردی کاملاً استاندارد (dns، smb) مواجه شدم.

مثل همیشه، باید بهترین راه حل را برای شبکه خود پیدا کنید.

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

بنابراین، در بخش های حساس، یک راه حل خوب ممکن است استفاده از پیشنهادات شرکت های مختلف باشد. به عنوان مثال، می توانید آنتی ویروس را روی فایروال فعال کنید، اما همچنین از محافظت آنتی ویروس (از سازنده دیگری) به صورت محلی در هاست استفاده کنید.

تقسیم بندی

ما در مورد تقسیم بندی منطقی شبکه مرکز داده صحبت می کنیم. به عنوان مثال، پارتیشن بندی به VLAN و زیر شبکه نیز یک تقسیم بندی منطقی است، اما به دلیل واضح بودن آن را در نظر نخواهیم گرفت. تقسیم بندی جالب با در نظر گرفتن نهادهایی مانند مناطق امنیتی FW، VRF ها (و آنالوگ های آنها در رابطه با فروشندگان مختلف)، دستگاه های منطقی (PA VSYS، Cisco N7K VDC، Cisco ACI Tenant، ...)، ...

نمونه ای از چنین تقسیم بندی منطقی و طراحی مرکز داده در حال حاضر مورد تقاضا در اینجا آورده شده است p002 پروژه PSEFABRIC.

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

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

اغلب تقسیم بندی فقط بر اساس مناطق امنیتی FW است. سپس باید به سوالات زیر پاسخ دهید:

• به چه مناطق امنیتی نیاز دارید
• چه سطح حفاظتی را می خواهید برای هر یک از این مناطق اعمال کنید
• آیا ترافیک درون منطقه ای به طور پیش فرض مجاز است؟
• اگر نه، چه سیاست های فیلترینگ ترافیک در هر منطقه اعمال خواهد شد
• چه سیاست های فیلترینگ ترافیک برای هر جفت منطقه (منبع/مقصد) اعمال خواهد شد

TCAM

یک مشکل رایج، ناکافی بودن TCAM (حافظه آدرس پذیر محتوای سه تایی) است، هم برای مسیریابی و هم برای دسترسی ها. IMHO، این یکی از مهمترین مسائل در هنگام انتخاب تجهیزات است، بنابراین باید با دقت مناسب به این موضوع رسیدگی کنید.

مثال 1. جدول ارسال TCAM.

بیایید در نظر بگیریم پالو آلتو 7k دیواره آتش
می بینیم که اندازه جدول ارسال IPv4* = 32K
علاوه بر این، این تعداد مسیر برای همه VSYS ها مشترک است.

بیایید فرض کنیم با توجه به طراحی خود تصمیم به استفاده از 4 VSYS دارید.
هر یک از این VSYS ها از طریق BGP به دو MPLS PE ابری که شما به عنوان BB استفاده می کنید، متصل می شوند. بنابراین، 4 VSYS همه مسیرهای خاص را با یکدیگر مبادله می کنند و یک جدول حمل و نقل با مجموعه مسیرهای تقریباً یکسان (اما NH های مختلف) دارند. زیرا هر VSYS دارای 2 جلسه BGP (با همان تنظیمات) است، سپس هر مسیر دریافت شده از طریق MPLS دارای 2 NH و بر این اساس، 2 ورودی FIB در جدول Forwarding است. اگر فرض کنیم که این تنها فایروال در مرکز داده است و باید از همه مسیرها اطلاع داشته باشد، به این معنی است که تعداد کل مسیرها در مرکز داده ما نمی تواند بیش از 32K/(4*2) = 4K باشد.

حال اگر فرض کنیم 2 مرکز داده داریم (با همان طراحی) و بخواهیم از VLAN های "کشیده" بین مراکز داده استفاده کنیم (مثلاً برای vMotion)، برای حل مشکل مسیریابی باید از مسیرهای میزبان استفاده کنیم. . اما این بدان معناست که برای 2 مرکز داده ما بیش از 4096 هاست احتمالی نخواهیم داشت و البته ممکن است این کافی نباشد.

مثال 2. ACL TCAM.

اگر قصد دارید ترافیک سوئیچ های L3 را فیلتر کنید (یا راه حل های دیگری که از سوئیچ های L3 استفاده می کنند، به عنوان مثال، Cisco ACI)، پس هنگام انتخاب تجهیزات باید به TCAM ACL توجه کنید.

فرض کنید می‌خواهید دسترسی به رابط‌های SVI سیسکو Catalyst 4500 را کنترل کنید. سپس، همانطور که می‌توانید از از این مقاله، برای کنترل ترافیک خروجی (و همچنین ورودی) در رابط ها، می توانید فقط از 4096 خط TCAM استفاده کنید. که هنگام استفاده از TCAM3 حدود 4000 هزار ACE (خطوط ACL) به شما می دهد.

اگر با مشکل TCAM ناکافی مواجه هستید، البته قبل از هر چیز باید امکان بهینه سازی را در نظر بگیرید. بنابراین، در صورت مشکل در اندازه جدول Forwarding، باید امکان تجمیع مسیرها را در نظر بگیرید. در صورت بروز مشکل در اندازه TCAM برای دسترسی‌ها، دسترسی‌های ممیزی، حذف سوابق قدیمی و دارای تداخل، و احتمالاً تجدیدنظر در روش باز کردن دسترسی‌ها (به تفصیل در فصل دسترسی‌های ممیزی مورد بحث قرار خواهد گرفت).

در دسترس بودن بالا

سوال این است: آیا باید از HA برای فایروال ها استفاده کنم یا دو باکس مستقل به صورت موازی نصب کنم و اگر یکی از آنها خراب شد، ترافیک را از طریق دومی هدایت کنم؟

به نظر می رسد که پاسخ واضح است - از HA استفاده کنید. دلیل اینکه هنوز این سوال مطرح می شود این است که متأسفانه درصدهای تئوری و تبلیغاتی 99 و چندین درصد اعشاری دسترسی در عمل به دور از حدقه است. HA از نظر منطقی یک چیز کاملاً پیچیده است، و در تجهیزات مختلف، و با فروشندگان مختلف (هیچ استثنایی وجود نداشت)، ما به مشکلات و اشکالات و توقف های سرویس پی بردیم.

اگر از HA استفاده می کنید، این فرصت را خواهید داشت که گره های جداگانه را خاموش کنید، بدون توقف سرویس بین آنها سوئیچ کنید، که برای مثال در هنگام ارتقاء مهم است، اما در عین حال احتمال اینکه هر دو گره در همان زمان خراب می شود، و همچنین ارتقاء بعدی آنطور که فروشنده وعده می دهد بدون مشکل پیش نمی رود (اگر فرصتی برای آزمایش ارتقاء روی تجهیزات آزمایشگاهی داشته باشید، می توان از این مشکل جلوگیری کرد).

اگر از HA استفاده نمی کنید، از نقطه نظر شکست مضاعف، خطرات شما بسیار کمتر است (چون 2 فایروال مستقل دارید)، اما از آنجایی که ... جلسات هماهنگ نیستند، پس هر بار که بین این فایروال ها جابجا شوید، ترافیک را از دست خواهید داد. مطمئناً می توانید از فایروال بدون حالت استفاده کنید، اما در این صورت استفاده از فایروال تا حد زیادی از بین می رود.

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

قابلیت مدیریت

در اصل، HA نیز در مورد کنترل پذیری است. به جای پیکربندی 2 جعبه به طور جداگانه و مقابله با مشکل همگام نگه داشتن پیکربندی ها، آنها را طوری مدیریت می کنید که گویی یک دستگاه دارید.

اما شاید شما مراکز داده و فایروال های زیادی دارید، پس این سوال در سطح جدیدی مطرح می شود. و سوال فقط در مورد پیکربندی نیست، بلکه در مورد آن نیز هست

• تنظیمات پشتیبان
• به روز رسانی ها
• ارتقاء می دهد
• نظارت بر
• چوب بری

و همه اینها را می توان با سیستم های مدیریت متمرکز حل کرد.

بنابراین، برای مثال، اگر از فایروال های Palo Alto استفاده می کنید، پس چشم انداز چنین راه حلی است

ادامه دارد

منبع: www.habr.com