نحوه اتصال فایروال سیسکو به Active Directory برای احراز هویت کاربران

در بسیاری از سازمان‌ها، تصمیم‌گیری امنیتی فقط بر اساس IP آدرس کافی نیست. وقتی چند کاربر از یک شبکه مشترک استفاده می‌کنند یا DHCP فعال است، شناسایی دقیق هویت کاربر اهمیت پیدا می‌کند. اتصال فایروال سیسکو به Active Directory این امکان را فراهم می‌کند که Policyها بر اساس Username یا گروه کاربری تعریف شوند، نه صرفاً بر اساس IP. این قابلیت در Cisco Firepower Threat Defense که هسته اصلی Cisco Secure Firewall است، از طریق یکپارچه‌سازی با Microsoft Active Directory و مدیریت آن در Cisco Firepower Management Center انجام می‌شود.

در این مقاله، فرآیند اتصال Secure Firewall به Active Directory، از مرحله پیش‌نیاز تا تست و عیب‌یابی را با رویکرد پروژه‌ای بررسی می‌کنیم.

چرا احراز هویت مبتنی بر Active Directory اهمیت دارد

در بسیاری از شبکه‌های سازمانی، چندین کاربر پشت یک Subnet مشترک یا حتی پشت یک IP عمومی NAT شده قرار دارند. اگر Policyهای امنیتی فقط بر اساس IP نوشته شوند، عملاً نمی‌توانید تشخیص دهید کدام کاربر دقیقاً چه ترافیکی تولید کرده است. در چنین شرایطی، لاگ‌ها ارزش تحلیلی کمی دارند و اعمال کنترل‌های دقیق تقریباً غیرممکن می‌شود. اتصال فایروال به Microsoft Active Directory این مشکل را حل می‌کند، چون هویت کاربر را به تصمیم‌گیری امنیتی وارد می‌کند.

اولین مزیت مهم، دقت در اعمال Policy است. وقتی فایروال بداند کاربر عضو چه گروهی است، می‌تواند Ruleهایی مبتنی بر Role تعریف کند. برای مثال، اعضای گروه IT می‌توانند به سرورهای مدیریتی دسترسی داشته باشند، در حالی که سایر کاربران حتی اگر در همان VLAN باشند، اجازه دسترسی ندارند. این رویکرد مبتنی بر Role یا RBAC باعث می‌شود Policyها ساده‌تر، شفاف‌تر و قابل نگهداری‌تر شوند.

دومین مزیت، بهبود تحلیل رویدادهای امنیتی است. فرض کنید یک اتصال مشکوک به یک دامنه مخرب ثبت شده است. اگر فقط IP در لاگ وجود داشته باشد، باید بررسی کنید آن IP در آن زمان متعلق به کدام کاربر بوده است، مخصوصاً اگر DHCP فعال باشد. اما اگر فایروال به AD متصل باشد، Username مستقیماً در Event ثبت می‌شود. این موضوع زمان پاسخ‌گویی به حادثه را به شدت کاهش می‌دهد.

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

چهارمین مزیت، افزایش امنیت در سناریوهای VPN و دسترسی راه‌دور است. وقتی فایروال بتواند کاربران را مستقیماً در برابر Domain احراز هویت کند، می‌توانید MFA، محدودیت دسترسی مبتنی بر گروه و حتی Dynamic Access Policy تعریف کنید. این موضوع به‌ویژه در سناریوهای دورکاری اهمیت بالایی دارد.

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

مدل‌های یکپارچه‌سازی با Active Directory

برای اتصال Cisco Firepower Threat Defense به Microsoft Active Directory چند مدل مختلف وجود دارد و انتخاب هر کدام به نیاز امنیتی، تجربه کاربری و معماری شبکه سازمان بستگی دارد. درک تفاوت این مدل‌ها بسیار مهم است، چون هر کدام مزایا، محدودیت‌ها و پیچیدگی‌های خاص خود را دارند.

اولین مدل، احراز هویت مستقیم از طریق LDAP یا LDAPS است. در این روش، فایروال یا Cisco Firepower Management Center مستقیماً به Domain Controller متصل می‌شود و هنگام نیاز به احراز هویت، Username و Password کاربر را در برابر AD بررسی می‌کند. این مدل معمولاً در سناریوهای VPN یا Captive Portal استفاده می‌شود، یعنی زمانی که کاربر به صورت فعال اطلاعات کاربری خود را وارد می‌کند. مزیت این روش سادگی و امنیت بالاست، به‌ویژه اگر از LDAPS استفاده شود، اما برای ترافیک عادی کاربران داخل شبکه که لاگین مجدد انجام نمی‌دهند کافی نیست.

مدل دوم، Passive Authentication است. در این روش، فایروال بدون اینکه کاربر دوباره Login کند، از طریق دریافت Eventهای Logon از Domain Controller، IP کاربر را به Username او نگاشت می‌کند. معمولاً یک Agent روی Domain Controller نصب می‌شود که Logon Eventها را مانیتور کرده و آن‌ها را به FMC ارسال می‌کند. به این ترتیب، وقتی کاربر وارد ویندوز می‌شود، فایروال از همان لحظه هویت او را می‌شناسد. این مدل برای محیط‌های سازمانی بزرگ بسیار کاربردی است چون تجربه کاربری بدون اختلال حفظ می‌شود.

مدل سوم، ترکیب LDAP و Passive Authentication است. در این سناریو، کاربران داخلی از طریق Passive Authentication شناسایی می‌شوند، اما برای دسترسی‌های خاص مانند VPN یا دسترسی به بخش‌های حساس شبکه، احراز هویت فعال از طریق LDAP انجام می‌شود. این مدل ترکیبی، تعادل خوبی بین راحتی کاربر و کنترل امنیتی ایجاد می‌کند.

مدل چهارم، استفاده از Single Sign-On مبتنی بر Identity Providerهای پیشرفته‌تر است. در برخی سازمان‌ها که از زیرساخت‌های پیشرفته‌تری استفاده می‌کنند، ممکن است Firepower با سیستم‌های SSO یا حتی Azure AD یکپارچه شود. در این حالت، هویت کاربر از طریق Tokenهای احراز هویت منتقل می‌شود. این مدل بیشتر در سناریوهای Hybrid یا Cloud کاربرد دارد.

از نظر امنیتی، استفاده از LDAPS به جای LDAP توصیه می‌شود چون اطلاعات احراز هویت به صورت رمزنگاری‌شده منتقل می‌شود. همچنین باید Service Account مورد استفاده کمترین سطح دسترسی ممکن را داشته باشد تا در صورت افشای اطلاعات، ریسک امنیتی کاهش یابد.

در پروژه‌های واقعی، انتخاب مدل یکپارچه‌سازی باید بر اساس این سؤال‌ها انجام شود: آیا نیاز به احراز هویت تعاملی وجود دارد یا فقط شناسایی کاربر کافی است؟ آیا شبکه بزرگ و چندشعبه‌ای است؟ آیا زیرساخت AD پایدار و در دسترس است؟ آیا کاربران مهمان یا دستگاه‌های غیر Domain-Joined نیز وجود دارند؟

پیش‌نیازهای فنی قبل از اتصال

قبل از اینکه Cisco Firepower Threat Defense را به Microsoft Active Directory متصل کنید، باید چند پیش‌نیاز فنی را با دقت بررسی کنید. بخش زیادی از خطاهای احراز هویت در پروژه‌های واقعی نه به دلیل تنظیمات اشتباه LDAP، بلکه به دلیل نادیده گرفتن همین الزامات پایه رخ می‌دهد.

اولین پیش‌نیاز، ارتباط شبکه‌ای پایدار بین Cisco Firepower Management Center و Domain Controller است. باید اطمینان حاصل کنید که FMC می‌تواند IP یا FQDN مربوط به DC را Resolve و Ping کند. همچنین پورت‌های مورد نیاز مانند 389 برای LDAP، پورت 636 برای LDAPS و در صورت استفاده از Global Catalog پورت‌های 3268 یا 3269 باید در مسیر باز باشند. اگر بین این دو نقطه فایروال یا ACL وجود دارد، لازم است Ruleهای لازم از قبل تعریف شوند.

دومین موضوع، همگام‌سازی زمان سیستم‌هاست. احراز هویت مبتنی بر Kerberos و حتی ارتباطات امن TLS نسبت به اختلاف زمان حساس هستند. اگر ساعت FMC یا FTD با Domain Controller اختلاف داشته باشد، ممکن است فرآیند Bind یا Authentication با خطا مواجه شود. بنابراین تنظیم NTP یکسان روی همه سیستم‌ها ضروری است.

سومین پیش‌نیاز، ایجاد یک Service Account اختصاصی در Active Directory است. این حساب باید فقط دسترسی Read به ساختار کاربران و گروه‌ها داشته باشد. استفاده از Domain Admin برای اتصال توصیه نمی‌شود، چون ریسک امنیتی بالایی دارد. همچنین بهتر است Password این حساب به صورت دوره‌ای تغییر داده شود و مستندسازی دقیق انجام شود.

چهارمین نکته، تعیین صحیح Base DN و ساختار OU در AD است. اگر سازمان ساختار پیچیده‌ای با چندین OU دارد، باید مشخص کنید کدام بخش‌ها نیاز به Sync دارند. همگام‌سازی کل دامین در سازمان‌های بزرگ می‌تواند بار اضافی روی FMC ایجاد کند. محدود کردن Scope به OUهای موردنیاز، عملکرد و سرعت Sync را بهبود می‌دهد.

پنجمین موضوع، بررسی و آماده‌سازی گواهی‌ها در صورت استفاده از LDAPS است. اگر قصد دارید ارتباط رمزنگاری‌شده برقرار کنید، Domain Controller باید گواهی معتبر داشته باشد و FMC باید آن را Trust کند. در غیر این صورت، اتصال با خطای Certificate مواجه خواهد شد. در محیط‌های حساس، استفاده از LDAPS به جای LDAP ساده یک Best Practice محسوب می‌شود.

ششمین پیش‌نیاز، بررسی سیاست‌های امنیتی داخلی سازمان است. باید مشخص شود آیا فایروال مجاز به Query گرفتن از AD است یا خیر. در برخی سازمان‌ها دسترسی به Domain Controller محدود است و نیاز به هماهنگی با تیم زیرساخت دارد.

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

مرحله اول: اضافه کردن LDAP Server در FMC

در FMC وارد بخش System و سپس Integration شوید. در قسمت Realms یا LDAP Server می‌توانید یک Server جدید تعریف کنید.

در این مرحله اطلاعات زیر وارد می‌شود:
IP یا FQDN Domain Controller
Base DN
Bind DN و Password مربوط به Service Account
پورت 389 برای LDAP یا 636 برای LDAPS

پس از وارد کردن اطلاعات، گزینه Test Connection را اجرا کنید تا مطمئن شوید ارتباط برقرار است.

مرحله دوم: تعریف Realm و همگام‌سازی کاربران

پس از اضافه کردن LDAP Server، باید یک Realm تعریف شود. Realm در واقع نماینده Domain شما در FMC است.

پس از تعریف Realm، فرآیند Download User and Group Information اجرا می‌شود. در این مرحله کاربران و گروه‌های AD به FMC شناسانده می‌شوند. بسته به تعداد کاربران، این فرآیند ممکن است چند دقیقه طول بکشد.

در پروژه‌های بزرگ، توصیه می‌شود فقط OUهای موردنیاز Sync شوند تا بار اضافی روی FMC ایجاد نشود.

مرحله سوم: فعال‌سازی User Identity در Access Control Policy

پس از همگام‌سازی کاربران، می‌توانید در Access Control Policy از شرط User استفاده کنید. یک Rule جدید ایجاد کنید و در قسمت Users، گروه موردنظر از Active Directory را انتخاب نمایید.

برای مثال می‌توانید Rule تعریف کنید که فقط گروه IT اجازه دسترسی به سرور مدیریتی داشته باشد یا گروه Finance به سایت خاصی دسترسی داشته باشد.

پس از ذخیره تغییرات، Deploy انجام دهید.

مرحله چهارم: پیاده‌سازی Passive Authentication

اگر بخواهید بدون نیاز به ورود مجدد کاربر، IP او به Username نگاشت شود، باید User Identity Agent یا روش Passive Authentication فعال شود. این Agent روی Domain Controller نصب می‌شود و Logon Eventها را به FMC ارسال می‌کند.

در این حالت، زمانی که کاربر وارد ویندوز می‌شود، FMC IP او را با Username تطبیق می‌دهد و Ruleهای مبتنی بر کاربر اعمال می‌شوند.

تست و عیب‌یابی

پس از پیاده‌سازی، ابتدا با یک کاربر تست کنید. وارد سیستم شوید و سپس در FMC بخش Analysis را بررسی کنید تا ببینید Username در Eventها ثبت شده است یا خیر.

اگر Rule مبتنی بر کاربر کار نمی‌کند، موارد زیر را بررسی کنید:
ارتباط LDAP
درست بودن Base DN
فعال بودن User Identity
همگام بودن زمان سیستم‌ها

در صورت استفاده از LDAPS، بررسی Trust بودن Certificate نیز ضروری است.

سناریوی عملی در یک سازمان متوسط

فرض کنید سازمانی می‌خواهد دسترسی به شبکه‌های اجتماعی فقط برای تیم بازاریابی فعال باشد. با اتصال Secure Firewall به Active Directory، می‌توان یک Rule تعریف کرد که Category Social Media فقط برای گروه Marketing Allow باشد و برای سایر کاربران Block شود.

در این حالت مدیریت Policy بسیار ساده‌تر از تعریف IPهای جداگانه برای هر کاربر خواهد بود.

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

اتصال Cisco Secure Firewall به Active Directory، فایروال را از یک سیستم مبتنی بر IP به یک پلتفرم مبتنی بر هویت تبدیل می‌کند. این تغییر، سطح کنترل و دقت Policyها را به شکل چشمگیری افزایش می‌دهد.

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

وینو سرور؛ مرجع تخصصی یکپارچه‌سازی امنیت و هویت

یکپارچه‌سازی فایروال سیسکو با Active Directory فقط یک تنظیم LDAP ساده نیست. طراحی امن ارتباط، پیاده‌سازی Passive Authentication، تعریف Policyهای کاربرمحور و عیب‌یابی مشکلات هویتی نیازمند تجربه عملی در پروژه‌های واقعی است.

وینو سرور به عنوان یک مرجع تخصصی در حوزه Cisco Secure Firewall و یکپارچه‌سازی با Active Directory، با رویکردی مبتنی بر تجربه پروژه‌های سازمانی، به شما کمک می‌کند معماری امنیتی مبتنی بر هویت را به‌صورت پایدار و قابل مدیریت پیاده‌سازی کنید. اگر هدف شما افزایش دقت کنترل دسترسی و تحلیل امنیتی مبتنی بر کاربر است، وینو سرور می‌تواند نقطه اتکای تخصصی شما در این مسیر باشد.