در بسیاری از سازمانها، کنترل دسترسی به شبکه هنوز در نقطه ورود کاربر متوقف میشود. کاربر احراز هویت میکند، وارد VLAN مشخصی میشود و از آن لحظه به بعد، فایروال فقط بر اساس IP و Port تصمیمگیری میکند. اما در معماریهای مدرن، این مدل دیگر پاسخگو نیست. نیاز به کنترل دسترسی مبتنی بر هویت، وضعیت امنیتی دستگاه و نقش سازمانی باعث شده NAC به یک جزء کلیدی در طراحی امنیت تبدیل شود.
ادغام فایروال سیسکو با Cisco Identity Services Engine این امکان را فراهم میکند که تصمیمگیری امنیتی از لایه شبکه فراتر رود و به لایه هویت و Posture گسترش یابد. وقتی این اطلاعات در اختیار Cisco Secure Firewall قرار گیرد، میتوان Policyهایی تعریف کرد که نه فقط بر اساس IP، بلکه بر اساس User، Device Type، Compliance Status و حتی موقعیت اتصال اعمال شوند.
در این مقاله، بهصورت مهندسی بررسی میکنیم چگونه فایروال سیسکو در کنار Cisco ISE برای پیادهسازی NAC سازمانی استفاده میشود، چه معماریای توصیه میشود، چه سناریوهای عملی رایج هستند و چه چالشهایی در پروژههای واقعی وجود دارد.
برای درک درست معماری یکپارچه NAC با فایروال سیسکو، باید نقش هر جزء را بهصورت دقیق تفکیک کنیم. در این معماری، Cisco Identity Services Engine مسئول تشخیص «چه کسی» و «با چه دستگاهی» وارد شبکه شده است، و فایروال مانند Cisco Secure Firewall مسئول تصمیمگیری درباره «به چه چیزی» و «چگونه» دسترسی داشته باشد. این تفکیک مسئولیت، پایه طراحی معماری پایدار و مقیاسپذیر است.
در سطح دسترسی شبکه، ISE معمولاً با سوئیچها و Wireless Controllerها از طریق 802.1X یا MAB تعامل دارد. کاربر یا دستگاه پس از احراز هویت، یک Policy دریافت میکند که میتواند شامل VLAN Assignment، Downloadable ACL یا Security Group Tag باشد. اما این فقط لایه اول کنترل است. اگر همینجا متوقف شویم، همچنان کنترل در سطح سگمنت انجام شده و فایروال اطلاعات هویتی عمیقی از کاربر نخواهد داشت.
در معماری یکپارچه پیشرفته، ISE از طریق pxGrid اطلاعات Context را به فایروال منتقل میکند. این Context شامل Username، IP Address، گروه کاربری، نوع دستگاه، وضعیت Posture و حتی محل اتصال است. فایروال این اطلاعات را در موتور تصمیمگیری خود وارد میکند. یعنی وقتی یک Session جدید شکل میگیرد، علاوه بر بررسی IP و Port، فایروال میداند این IP متعلق به چه کاربری است و وضعیت امنیتی دستگاه او چیست.
در یکی از پروژههای سازمانی، کاربران از طریق وایرلس به شبکه متصل میشدند. پیش از یکپارچهسازی، همه کاربران وایرلس در یک VLAN مشترک بودند و فایروال فقط بر اساس Subnet تصمیم میگرفت. پس از اتصال ISE و فایروال، همان کاربران بر اساس گروه سازمانی تفکیک شدند؛ کاربر مالی به سامانه مالی دسترسی داشت اما کاربر منابع انسانی حتی اگر در همان VLAN بود، اجازه دسترسی نداشت. این تغییر بدون تغییر ساختار IP انجام شد و صرفاً بر پایه Context هویتی بود.
نکته مهم دیگر در این معماری، پویایی تصمیمگیری است. اگر وضعیت دستگاه تغییر کند، مثلاً آنتیویروس غیرفعال شود یا Patch امنیتی بهروز نباشد، ISE وضعیت Posture را تغییر میدهد و این تغییر به فایروال منتقل میشود. فایروال میتواند Sessionهای جدید را با محدودیت اعمال کند یا حتی دسترسی را به شبکه Remediation هدایت کند. این یعنی Policy دیگر ثابت و ایستا نیست، بلکه بر اساس وضعیت لحظهای دستگاه تغییر میکند.
در محیطهای بزرگ، استفاده از Security Group Tag بهجای VLANهای متعدد یک مزیت معماری مهم است. بهجای تعریف دهها VLAN برای نقشهای مختلف، میتوان کاربران را با SGT برچسبگذاری کرد و فایروال بر اساس این برچسبها تصمیم بگیرد. این مدل باعث کاهش پیچیدگی لایه دو و سه شبکه و انتقال منطق کنترل به لایه Policy میشود.
از منظر عملیاتی، باید توجه داشت که ارتباط پایدار بین ISE و فایروال حیاتی است. اگر pxGrid قطع شود، فایروال ممکن است کاربران جدید را بهعنوان Unknown ببیند و Policy پیشفرض اعمال کند. در طراحی حرفهای، معمولاً چند Node برای ISE و مسیرهای ارتباطی افزونه در نظر گرفته میشود تا این وابستگی به نقطه شکست واحد تبدیل نشود.
در معماری یکپارچه NAC، نقطه کلیدی که فایروال را از یک دستگاه مبتنی بر IP به یک Enforcement Point مبتنی بر هویت تبدیل میکند، مکانیزم pxGrid است. در این مدل، Cisco Identity Services Engine فقط یک سرور احراز هویت نیست، بلکه به یک Provider اطلاعات Context در سطح سازمان تبدیل میشود. این Context از طریق pxGrid به مصرفکنندههایی مانند Cisco Secure Firewall یا مدیریت مرکزی آن یعنی Cisco Firepower Management Center منتقل میشود.
pxGrid در واقع یک بستر Publish/Subscribe است. ISE اطلاعاتی مانند Username، IP Address، گروه کاربری، Security Group Tag، وضعیت Posture، نوع دستگاه و حتی محل اتصال را منتشر میکند. فایروال بهعنوان Subscriber این اطلاعات را دریافت کرده و در موتور تصمیمگیری خود استفاده میکند. این ارتباط Real-Time است و برخلاف روشهای قدیمی مبتنی بر Agent ویندوزی، وابسته به Logon ویندوز نیست.
در معماریهای قدیمیتر، Identity Mapping معمولاً با استفاده از یک User Agent انجام میشد که Eventهای لاگین Domain Controller را مانیتور میکرد. این روش برای کاربران Domain مناسب بود، اما در محیطهای Wireless، BYOD یا دستگاههای غیر ویندوزی دقت و پوشش کافی نداشت. با استفاده از pxGrid، هر کاربری که از طریق 802.1X یا حتی MAB احراز هویت شود، بهصورت هویتی در فایروال قابل شناسایی خواهد بود.
از منظر فنی، راهاندازی pxGrid شامل ایجاد Trust بین ISE و FMC است. گواهینامهها، احراز هویت دوطرفه و تعریف Client در ISE باید بهدرستی انجام شود. اگر این مرحله با دقت انجام نشود، ممکن است اتصال برقرار شود اما تبادل داده واقعی انجام نشود. در یکی از پروژههای Enterprise، اتصال pxGrid در ظاهر Up بود اما به دلیل اشتباه در Certificate Trust، هیچ User Mappingای به FMC ارسال نمیشد.
پس از برقراری ارتباط، اطلاعات هویتی در FMC بهصورت Mapping Table قابل مشاهده است. زمانی که یک Session جدید از سمت کلاینت شکل میگیرد، فایروال IP مبدأ را با این جدول تطبیق میدهد و هویت کاربر را استخراج میکند. از این لحظه، Ruleهای Access Control میتوانند بر اساس User یا Group اجرا شوند.
نکته مهم این است که اطلاعات pxGrid پویا هستند. اگر وضعیت Posture کاربر تغییر کند، مثلاً دستگاه از حالت Compliant به Non-Compliant برود، ISE این تغییر را منتشر میکند و فایروال میتواند تصمیم متفاوتی برای Sessionهای جدید بگیرد. این قابلیت در سناریوهایی که کنترل دسترسی مشروط اهمیت دارد، حیاتی است. در یک پروژه حوزه سلامت، دستگاههایی که Patch امنیتی آنها بهروز نبود، بلافاصله پس از تغییر وضعیت، دسترسیشان به سامانههای حساس محدود شد.
از نظر عملیاتی، پایداری ارتباط pxGrid اهمیت زیادی دارد. اگر ارتباط بین ISE و FMC قطع شود، فایروال ممکن است کاربران جدید را بهعنوان Unknown شناسایی کند. بنابراین طراحی High Availability برای ISE Nodeها و مسیر ارتباطی مطمئن بین آنها و FMC بخشی از معماری حرفهای است.
همچنین باید توجه داشت که حجم Context در سازمانهای بزرگ میتواند بالا باشد. هزاران کاربر، دستگاه و تغییر وضعیت در طول روز تولید Event میکند. بنابراین ظرفیت FMC و بهینهسازی Subscriptionها باید متناسب با مقیاس سازمان تنظیم شود تا تأخیر در Mapping ایجاد نشود.
زمانی که یکپارچهسازی بین Cisco Identity Services Engine و Cisco Secure Firewall از طریق pxGrid برقرار شد، مهمترین مرحله شروع میشود: تبدیل اطلاعات هویتی و Posture به Policy اجرایی. این مرحله جایی است که طراحی ضعیف میتواند کل پروژه NAC را به یک منبع پیچیدگی عملیاتی تبدیل کند.
اولین نکته مهندسی این است که Policy مبتنی بر هویت نباید صرفاً جایگزین ACL مبتنی بر IP شود، بلکه باید منطق دسترسی سازمان را بازتاب دهد. به بیان ساده، باید مشخص باشد چه نقشهایی در سازمان وجود دارد، هر نقش به چه سرویسهایی نیاز دارد و چه سطحی از وضعیت امنیتی دستگاه برای دسترسی قابل قبول است. اگر این تحلیل پیش از تعریف Rule انجام نشود، نتیجه مجموعهای از Ruleهای پراکنده و همپوشان خواهد بود که در زمان عیبیابی مشکلساز میشوند.
در Cisco Firepower Management Center میتوان Access Control Ruleهایی تعریف کرد که شرط آنها شامل User، Group، Security Group Tag و حتی وضعیت Posture باشد. برای مثال، یک Rule میتواند چنین منطقی داشته باشد: کاربران عضو گروه Finance با دستگاه Compliant اجازه دسترسی به Application مالی داخلی را دارند. همان کاربران اگر دستگاهشان Non-Compliant باشد، فقط به سرور Remediation هدایت شوند و دسترسی به سایر منابع Block شود.
در یکی از پروژههای سازمانی، پیش از پیادهسازی NAC، همه کاربران داخلی به سامانه منابع انسانی دسترسی داشتند چون در یک Subnet مشترک بودند. پس از اعمال Policy مبتنی بر هویت، تنها گروه HR به این سامانه دسترسی داشتند و سایر کاربران حتی در همان VLAN، توسط فایروال Block میشدند. این تغییر بدون بازطراحی آدرسدهی انجام شد و صرفاً بر پایه Context هویتی بود.
موضوع Posture نیز باید با دقت طراحی شود. Posture فقط یک وضعیت Binary مانند Compliant یا Non-Compliant نیست. ممکن است سطوح مختلفی تعریف شود، مانند عدم وجود آنتیویروس، قدیمی بودن Patchها یا فعال نبودن Firewall محلی. اگر این سطوح بهدرستی در ISE تعریف شوند، فایروال میتواند بر اساس شدت ریسک تصمیم بگیرد. برای مثال، دستگاهی که تنها یک Patch جزئی را ندارد ممکن است دسترسی محدود داشته باشد، اما دستگاهی که آنتیویروس غیرفعال دارد کاملاً ایزوله شود.
یکی از چالشهای رایج در این مرحله، ترتیب Ruleها در Access Control است. چون Ruleهای مبتنی بر هویت معمولاً خاصتر از Ruleهای عمومی هستند، باید در بالای Policy قرار گیرند. در غیر این صورت، یک Rule عمومی Allow ممکن است پیش از Rule مبتنی بر هویت Match شود و منطق NAC عملاً بیاثر گردد. این اشتباه در یکی از پروژههای Enterprise رخ داد و باعث شد برخی کاربران بدون بررسی Posture به سرویسهای حساس دسترسی پیدا کنند.
همچنین باید به رفتار Sessionهای موجود توجه کرد. اگر وضعیت Posture کاربر تغییر کند، مثلاً دستگاه از Compliant به Non-Compliant تبدیل شود، Policy جدید روی Sessionهای جدید اعمال میشود. در برخی سناریوها ممکن است نیاز باشد Sessionهای فعال قطع شوند تا Policy سختگیرانه فوراً اجرا شود. این تصمیم باید بر اساس حساسیت سرویسها گرفته شود.
از منظر عملیاتی، توصیه میشود Policy مبتنی بر هویت ابتدا در حالت Monitor اجرا شود. یعنی Log فعال باشد اما Block انجام نشود. این کار اجازه میدهد رفتار واقعی کاربران تحلیل شود و Ruleها پیش از Enforcement کامل اصلاح شوند. اجرای ناگهانی Policy سختگیرانه بدون تحلیل اولیه میتواند باعث قطع سرویسهای حیاتی شود.
یکی از رایجترین سناریوها، جداسازی دسترسی کارمندان، پیمانکاران و مهمانان است. ISE نقش کاربر را مشخص میکند و فایروال دسترسی به Applicationهای داخلی را محدود میسازد.
سناریوی دیگر، کنترل دسترسی بر اساس نوع دستگاه است. برای مثال، دستگاههای Corporate Laptop اجازه دسترسی کامل دارند، اما دستگاههای شخصی تنها به سرویسهای محدود دسترسی خواهند داشت.
در محیطهای صنعتی، حتی دستگاههای IoT یا تجهیزات خاص میتوانند بر اساس Profiling در ISE شناسایی شوند و فایروال تنها ارتباطات مشخصی را برای آنها Allow کند.
یکی از چالشهای رایج، تأخیر در دریافت اطلاعات هویتی است. اگر ارتباط pxGrid ناپایدار باشد، فایروال ممکن است کاربر را بهعنوان Unknown شناسایی کند و Policy اشتباه اعمال شود.
چالش دیگر، طراحی بیشازحد پیچیده Policy است. اگر Ruleهای مبتنی بر User، Application و Posture بدون مستندسازی دقیق تعریف شوند، عیبیابی بسیار دشوار خواهد شد.
همچنین باید به ظرفیت پردازشی فایروال توجه شود. اعمال Policy مبتنی بر هویت و Inspection عمیق همزمان میتواند بار پردازشی قابل توجهی ایجاد کند.
یک پیادهسازی موفق شامل این مراحل است: طراحی معماری Identity، تست ارتباط pxGrid، تعریف Policy مرحلهای، مانیتورینگ اولیه و در نهایت گسترش تدریجی به کل سازمان.
توصیه میشود ابتدا Policy در حالت Monitor اجرا شود تا رفتار واقعی کاربران مشاهده شود و سپس Enforcement کامل فعال گردد. مهاجرت ناگهانی به NAC سختگیرانه میتواند باعث اختلال در کسبوکار شود.
استفاده از فایروال سیسکو در کنار Cisco Identity Services Engine امکان حرکت از امنیت مبتنی بر IP به امنیت مبتنی بر هویت و وضعیت دستگاه را فراهم میکند. این همگرایی نهتنها کنترل دسترسی دقیقتری ایجاد میکند، بلکه دید تحلیلی عمیقتری نسبت به رفتار کاربران در شبکه ارائه میدهد.
اما این پیادهسازی نیازمند طراحی دقیق معماری، تست مرحلهای و هماهنگی کامل بین تیمهای شبکه و امنیت است. اگر این فرآیند بهدرستی انجام شود، نتیجه آن یک زیرساخت NAC یکپارچه و پایدار خواهد بود که امنیت سازمان را در سطحی بالاتر قرار میدهد.
پیادهسازی NAC در مقیاس سازمانی پروژهای پیچیده است که نیازمند تجربه عملی در طراحی Identity، Integration و Enforcement است. بسیاری از چالشها تنها در محیط واقعی خود را نشان میدهند.
وینو سرور با تجربه عملی در طراحی و اجرای پروژههای یکپارچه ISE و Cisco Secure Firewall، میتواند معماری NAC سازمان شما را بهصورت مهندسی، مقیاسپذیر و پایدار طراحی و پیادهسازی کند. اگر هدف شما کنترل دسترسی دقیق و مبتنی بر هویت در سطح Enterprise است، وینو سرور میتواند بهعنوان مرجع تخصصی در کنار تیم فنی شما قرار گیرد و راهکاری عملی و تستشده ارائه دهد.
وینو سرور، اولین استارتاپ ارائه تجهیزات و سیستم های سخت افزاری، به صورت مستقیم از تولید کننده به مصرف کننده است. همواره تلاش مجموعه بر این اصل استوار بوده است تا مشتریان بتوانند بهترین سیستم را برای پروژه خود انتخاب کرده و با مناسبترین قیمت، آن را تهیه کنند. تیم وینو سرور، همواره سعی میکند تا جامعترین خدمات را به مشتریان ارائه دهد تا خرید را برای شما به کاری لذتبخش و آسان تبدیل کند.
مطلع شدن از پست های جدید
میخواهم اولین نفری باشم که از مقالههایی که در وینو سرور منتشر میشود، آگاه شوم.
