راه‌اندازی Identity Policy در Cisco Firepower برای اعمال Rule مبتنی بر کاربر

در بسیاری از سازمان‌ها هنوز هم Policyهای فایروال بر اساس IP نوشته می‌شوند. این مدل تا زمانی که ساختار شبکه ساده و ایستا باشد قابل مدیریت است، اما در محیط‌های امروزی که کاربران از طریق VPN، وایرلس، VDI و حتی BYOD به شبکه متصل می‌شوند، IP دیگر شاخص قابل اعتمادی برای شناسایی هویت نیست. اگر هدف کنترل دقیق دسترسی باشد، باید Ruleها بر اساس کاربر یا گروه کاربری تعریف شوند، نه صرفاً آدرس شبکه.

در معماری مبتنی بر Cisco Firepower Management Center، قابلیت Identity Policy این امکان را فراهم می‌کند که فایروال بتواند Session را به یک کاربر واقعی در Active Directory نسبت دهد و سپس Ruleهای Access Control را بر اساس User یا Group اعمال کند. این قابلیت زمانی ارزش واقعی خود را نشان می‌دهد که بخواهید سیاست‌های دسترسی مبتنی بر نقش سازمانی پیاده‌سازی کنید، نه ساختار شبکه.

در این مقاله به‌صورت فنی و سناریو محور بررسی می‌کنیم چگونه Identity Policy را در Firepower راه‌اندازی کنیم، چه پیش‌نیازهایی دارد، چه چالش‌هایی در پروژه‌های واقعی وجود دارد و چگونه می‌توان Rule مبتنی بر کاربر را به‌صورت پایدار پیاده‌سازی کرد.

درک معماری Identity در Firepower

برای اینکه Identity Policy در Cisco Firepower Management Center به‌درستی و پایدار کار کند، باید معماری Identity را در سطح جریان داده و منطق پردازش درک کنید، نه صرفاً در حد فعال‌سازی یک گزینه در FMC. فایروال به‌صورت ذاتی مفهوم «کاربر» را نمی‌شناسد؛ آنچه در لایه شبکه دیده می‌شود IP، Port و Session است. بنابراین معماری Identity در واقع مکانیزمی است برای نگاشت بین IP و User در یک بازه زمانی مشخص.

این نگاشت بر پایه یک جدول Identity Mapping شکل می‌گیرد که در FMC نگهداری می‌شود. هر Entry در این جدول معمولاً شامل Username، آدرس IP کلاینت، Domain، گروه‌های کاربری و Timestamp است. زمانی که یک Session از سمت کلاینت به فایروال می‌رسد، Firepower ابتدا بررسی می‌کند آیا برای IP مبدأ، Mapping معتبر وجود دارد یا خیر. اگر Mapping موجود باشد، Ruleهای مبتنی بر کاربر قابل اعمال خواهند بود. اگر Mapping وجود نداشته باشد، بسته به Identity Policy تعریف‌شده، ممکن است فایروال اقدام به احراز هویت کند یا ترافیک را به‌عنوان کاربر ناشناس پردازش کند.

در معماری‌های رایج، اطلاعات هویتی از طریق یکی از سه روش اصلی به FMC منتقل می‌شود: Passive Authentication با استفاده از User Agent، Integration با Cisco Identity Services Engine، یا روش‌های Captive Portal و Active Authentication. در محیط‌های Domain-محور، رایج‌ترین روش استفاده از User Agent است که روی یک سرور ویندوزی نصب می‌شود و Eventهای Logon و Logoff در Domain Controller را مانیتور می‌کند. زمانی که کاربر روی سیستم لاگین می‌کند، Event مربوطه در DC ثبت می‌شود، User Agent آن را دریافت می‌کند و اطلاعات را به FMC ارسال می‌کند. FMC سپس IP کلاینت را به Username مرتبط می‌کند.

نکته مهم این است که این فرآیند وابسته به صحت Logon Event در Active Directory است. اگر کاربر با حساب لوکال لاگین کند یا سیستم عضو Domain نباشد، هیچ Mappingی تولید نخواهد شد. در یکی از پروژه‌های سازمانی، بخشی از سیستم‌ها خارج از Domain بودند و تیم امنیتی متوجه شده بود که Rule مبتنی بر کاربر برای آن‌ها اعمال نمی‌شود. مشکل از Firepower نبود، بلکه آن سیستم‌ها اساساً در معماری Identity قرار نمی‌گرفتند.

عامل زمان در معماری Identity بسیار مهم است. Mappingها دائمی نیستند و دارای Timeout هستند. اگر کاربر سیستم را Lock کند یا Logoff انجام دهد، باید Mapping به‌روزرسانی شود. اگر این اتفاق نیفتد، ممکن است کاربر جدیدی که پشت همان IP قرار می‌گیرد، همچنان با هویت قبلی شناخته شود. در محیط‌هایی با DHCP کوتاه‌مدت یا VDI، این موضوع اهمیت دوچندان دارد. در یک پروژه مبتنی بر VDI، به دلیل تخصیص سریع IP بین کاربران مختلف، Identity Mapping دچار تداخل شد و دسترسی‌ها اشتباه اعمال می‌شدند تا زمانی که Timeoutها بازطراحی شدند.

در سناریوهای VPN نیز معماری Identity کمی متفاوت عمل می‌کند. زمانی که کاربر از طریق VPN به ASA یا FTD متصل می‌شود، اطلاعات هویتی معمولاً در همان فرآیند احراز هویت VPN در دسترس است و نیازی به User Agent نیست. اما باید اطمینان حاصل شود که این اطلاعات به‌درستی به FMC منتقل می‌شود تا Ruleهای مبتنی بر کاربر روی Sessionهای VPN نیز اعمال شوند. در یکی از پروژه‌ها، VPN به‌درستی برقرار می‌شد اما چون Integration با FMC کامل نبود، ترافیک کاربران VPN به‌عنوان Unknown User دیده می‌شد و Ruleهای مبتنی بر گروه برای آن‌ها اجرا نمی‌شد.

پیش‌نیازهای فنی برای پیاده‌سازی Identity Policy

پیاده‌سازی Identity Policy در Cisco Firepower Management Center چیزی نیست که فقط با ساختن یک Realm و انتخاب یک گروه کاربری تمام شود. اگر پیش‌نیازهای فنی به‌درستی فراهم نشده باشند، نتیجه یا Mapping ناپایدار خواهد بود یا Ruleهای مبتنی بر کاربر به‌صورت تصادفی عمل می‌کنند. تجربه پروژه‌های واقعی نشان می‌دهد بیشترین خطاها دقیقاً در همین مرحله رخ می‌دهد.

اولین پیش‌نیاز، یک زیرساخت Active Directory سالم و قابل دسترس است. FMC باید بتواند از طریق LDAP یا ترجیحاً LDAPS به Domain Controller متصل شود. استفاده از LDAPS صرفاً یک توصیه امنیتی نیست؛ در بسیاری از سازمان‌ها به دلیل Policyهای امنیتی، اتصال LDAP ساده مسدود است و همین موضوع باعث Failure در اتصال Realm می‌شود. علاوه بر دسترسی شبکه، باید حساب Service Account با حداقل سطح دسترسی لازم برای Query کاربران و گروه‌ها تعریف شود. در یکی از پروژه‌ها، استفاده از حساب Domain Admin برای Bind به AD در ابتدا ساده به نظر می‌رسید، اما بعدها به دلیل تغییر Policyهای امنیتی، اتصال Realm قطع شد. تعریف یک حساب اختصاصی پایدارتر و حرفه‌ای‌تر است.

همگام‌سازی زمانی یکی از مهم‌ترین اما نادیده‌گرفته‌شده‌ترین پیش‌نیازهاست. Identity Mapping بر اساس Timestamp کار می‌کند. اگر ساعت FMC، FTD و Domain Controller حتی چند دقیقه اختلاف داشته باشند، Mapping ممکن است منقضی یا نامعتبر تشخیص داده شود. در یک محیط Enterprise، اختلاف چهار دقیقه‌ای بین DC و FMC باعث شد Logon Eventها ثبت شوند اما Mapping معتبر ساخته نشود. تنها پس از یکپارچه‌سازی NTP در کل زیرساخت، مشکل برطرف شد.

پیش‌نیاز بعدی، انتخاب و پیاده‌سازی مکانیزم دریافت اطلاعات هویتی است. در بسیاری از سازمان‌ها از User Agent استفاده می‌شود که روی یک سرور ویندوزی نصب می‌شود و Eventهای Logon و Logoff را از Domain Controller دریافت می‌کند. این سرور باید از نظر منابع و دسترسی شبکه پایدار باشد، زیرا اگر سرویس آن متوقف شود، Identity Mapping جدید ایجاد نخواهد شد. در سازمان‌هایی با چندین Domain Controller، باید بررسی شود User Agent به کدام DC متصل می‌شود و آیا Failover برای آن در نظر گرفته شده است یا خیر.

در محیط‌هایی که از NAC پیشرفته استفاده می‌شود، Integration با Cisco Identity Services Engine از طریق pxGrid گزینه‌ای پایدارتر است. در این مدل، اطلاعات هویتی مستقیماً از ISE دریافت می‌شود که معمولاً دقت بالاتری در محیط‌های وایرلس و BYOD دارد. اما این سناریو نیازمند طراحی گواهی‌نامه، اعتماد متقابل و تنظیمات امنیتی دقیق است. در یکی از پروژه‌ها، عدم تنظیم صحیح Trust بین FMC و ISE باعث شد اطلاعات کاربر دریافت نشود، در حالی که ظاهراً اتصال برقرار بود.

موضوع دیگر، ساختار شبکه و نحوه تخصیص IP است. اگر کاربران از DHCP با Lease کوتاه‌مدت استفاده می‌کنند یا در محیط VDI کار می‌کنند که IPها سریع جابه‌جا می‌شوند، باید Timeoutهای Identity Mapping متناسب با این رفتار تنظیم شود. در غیر این صورت ممکن است IP یک کاربر به اشتباه به کاربر قبلی نسبت داده شود. این مسئله در محیط‌هایی که کاربران شیفتی دارند بیشتر دیده می‌شود.

تعریف Realm و اتصال به Active Directory

در FMC ابتدا باید یک Realm تعریف شود که نمایانگر Active Directory است. در این مرحله پارامترهایی مانند Base DN، Bind DN و Server Address مشخص می‌شود. اتصال باید تست شود تا اطمینان حاصل شود که FMC قادر به Query گروه‌ها و کاربران است.

در پروژه‌ای که در یک سازمان آموزشی اجرا شد، اشتباه در تعریف Base DN باعث شد فقط بخشی از OUها قابل مشاهده باشند. نتیجه این شد که برخی گروه‌ها در Access Control قابل انتخاب نبودند و تیم امنیتی تصور می‌کرد مشکل از Identity Policy است، در حالی که پیکربندی Realm ناقص بود.

طراحی Identity Policy

پس از تعریف Realm و Identity Source، باید Identity Policy ساخته شود. این Policy تعیین می‌کند در چه شرایطی فایروال تلاش کند کاربر را شناسایی کند. معمولاً Identity Policy به Interface داخلی یا Zone خاصی اعمال می‌شود.

برای مثال می‌توان تعریف کرد که هر ترافیکی که از Zone داخلی به اینترنت می‌رود، ابتدا باید هویت آن مشخص شود. در صورت عدم شناسایی کاربر، می‌توان رفتار پیش‌فرض مانند Block یا Redirect تعریف کرد.

در محیط‌هایی با تعداد زیاد کاربران، باید Timeout و Refresh Mapping به‌درستی تنظیم شود. اگر زمان اعتبار کوتاه باشد، FMC دائماً درخواست احراز هویت می‌دهد. اگر بیش از حد طولانی باشد، تغییر کاربر روی یک سیستم ممکن است دیر تشخیص داده شود.

اعمال Rule مبتنی بر کاربر در Access Control Policy

پس از فعال شدن Identity Mapping، می‌توان در Access Control Policy به‌جای استفاده از Network Object از User یا User Group استفاده کرد. برای مثال می‌توان Ruleای تعریف کرد که فقط گروه Finance اجازه دسترسی به سرویس بانکی خاص را داشته باشند یا گروه IT بتوانند به SSH سرورها متصل شوند.

در یکی از پروژه‌های Enterprise، پیش از استفاده از Identity Policy، دسترسی به یک سرور حیاتی فقط بر اساس IP محدود شده بود. اما چون کاربران از DHCP استفاده می‌کردند، مدیریت IPها دشوار بود. با فعال‌سازی Rule مبتنی بر گروه AD، دسترسی دقیقاً بر اساس نقش کاربری اعمال شد و مدیریت ساده‌تر گردید.

همچنین می‌توان ترکیبی از User، Application و URL Category را در یک Rule استفاده کرد. برای مثال گروه Marketing می‌تواند به شبکه‌های اجتماعی دسترسی داشته باشد اما گروه Finance نه. این سطح از کنترل بدون Identity Policy عملاً غیرممکن یا بسیار پیچیده خواهد بود.

چالش‌های رایج در پروژه‌های واقعی

یکی از چالش‌های رایج، کاربران مشترک روی یک سیستم است. اگر چند کاربر با حساب‌های مختلف روی یک کامپیوتر لاگین کنند، Mapping باید به‌روزرسانی شود. در صورت تأخیر در دریافت Logon Event، ممکن است Rule اشتباه اعمال شود.

چالش دیگر، استفاده از Proxy یا NAT داخلی است. اگر چندین کاربر پشت یک IP دیده شوند، Identity Mapping پیچیده می‌شود. در چنین سناریوهایی Integration با ISE معمولاً نتیجه بهتری می‌دهد.

همچنین باید به عملکرد سیستم توجه کرد. فعال کردن Identity Policy روی تمام ترافیک می‌تواند بار پردازشی ایجاد کند. بهتر است Identity فقط روی Zoneهایی که نیاز واقعی دارند اعمال شود.

تست و اعتبارسنجی سناریو

پس از پیاده‌سازی، باید با حساب‌های مختلف تست انجام شود. کاربر عضو گروه مجاز باید به سرویس دسترسی داشته باشد و کاربر خارج از گروه باید Block شود. همچنین باید بررسی شود در صورت Logoff و Login با حساب دیگر، Mapping به‌درستی به‌روزرسانی می‌شود.

در یکی از پروژه‌ها، به دلیل کش شدن Mapping در FMC، پس از تغییر عضویت گروه کاربر در AD، دسترسی تا چند ساعت تغییر نکرد. با تنظیم Refresh Interval مناسب این مشکل برطرف شد.

جمع‌بندی مهندسی

راه‌اندازی Identity Policy در Cisco Firepower Management Center یک گام مهم در حرکت از امنیت مبتنی بر IP به امنیت مبتنی بر هویت است. این قابلیت امکان اعمال سیاست‌های دقیق، مبتنی بر نقش سازمانی و منطبق با ساختار واقعی کسب‌وکار را فراهم می‌کند.

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

وینو سرور؛ مرجع تخصصی پیاده‌سازی Identity Policy در Firepower

پیاده‌سازی Identity-Based Access Control در محیط‌های واقعی معمولاً پیچیده‌تر از آن چیزی است که در مستندات رسمی دیده می‌شود. هماهنگی با Active Directory، مدیریت Mapping، تنظیم Timeoutها و رفع خطاهای عملیاتی نیازمند تجربه پروژه‌ای است.

وینو سرور با تجربه عملی در پیاده‌سازی و بهینه‌سازی زیرساخت‌های مبتنی بر Firepower در سازمان‌های Enterprise، می‌تواند Identity Policy شما را به‌صورت مهندسی، پایدار و تست‌شده طراحی کند. اگر هدف شما اعمال Ruleهای دقیق مبتنی بر کاربر و نقش سازمانی است، وینو سرور می‌تواند به‌عنوان یک مرجع تخصصی در کنار تیم فنی شما قرار گیرد و راهکاری مبتنی بر تجربه واقعی پروژه ارائه دهد.