در شبکهای که چندین سوئیچ، روتر یا فایروال Juniper دارد، نگه داشتن کاربر محلی روی تکتک دستگاهها هم خستهکننده است و هم ریسک عملیاتی دارد. روش تمیزتر این است که ورود مدیریتی دستگاههای Junos از طریق RADIUS انجام شود و Cisco ISE، به عنوان سرور AAA، تصمیم بگیرد چه کسی فقط دسترسی خواندنی داشته باشد و چه کسی مجاز به تغییر کانفیگ باشد.
در این یادداشت سناریوی اتصال Cisco ISE به دستگاههای Juniper Junos را از زاویه شبکه واقعی میبینم: دسترسی مدیریتی متمرکز، تفکیک سطح دسترسی ادمینها، لاگ قابل پیگیری و کم کردن وابستگی به Userهای محلی پراکنده روی دستگاهها. هدف این نیست که فقط چند دستور RADIUS را کنار هم بگذاریم؛ هدف این است که AAA برای مدیریت تجهیزات Juniper قابل دفاع، قابل Audit و قابل نگهداری باشد.
ایده اصلی چیست؟
به جای اینکه برای هر دستگاه Juniper چند User محلی بسازیم، روی خود Junos فقط Template یا کلاس دسترسی را آماده میکنیم و احراز هویت واقعی را به RADIUS میسپاریم. اگر RADIUS پشت صحنه به Active Directory یا منبع هویتی سازمان وصل باشد، کاربر با همان نام کاربری سازمانی وارد دستگاه میشود. بعد Cisco ISE با Attribute مناسب به Junos میگوید کاربر باید به کدام سطح دسترسی محلی نگاشت شود.
در Junos برای این کار Attribute مهمی وجود دارد: Juniper-Local-User-Name. طبق مستندات Juniper، این Vendor-Specific Attribute با Vendor ID عدد 2636 و Type عدد 1 به نام یک User Template روی دستگاه اشاره میکند. یعنی اگر ISE مقدار aa-readonly را برگرداند، Junos آن را با Template همنام روی خود دستگاه تطبیق میدهد.
کانفیگ پایه روی Junos
در سناریوی خودمان، دستگاه اول دیتابیس محلی Junos را چک میکند و اگر کاربر محلی پیدا نشد، سراغ RADIUS سرور داخلی با IP 10.20.30.15 میرود. در محیط واقعی، برای دسترسی اضطراری معمولا یک کاربر محلی امن و محدود نگه میداریم، ولی استفاده روزمره باید از مسیر AAA انجام شود.
set system authentication-order [ password radius ]
set system radius-server 10.20.30.15 secret <ISE_SHARED_SECRET>بعد باید Templateهای محلی بسازید. این Templateها نقش کاربر را روی دستگاه مشخص میکنند. مثلا یک Template فقط خواندنی و یک Template با دسترسی کامل:
set system login user aa-readonly class read-only
set system login user aa-netadmin class super-userنکته امنیتی روشن است: Secret نمونه بالا فقط برای لابراتوار است. در شبکه واقعی باید Shared Secret قوی، مدیریتشده و متفاوت برای هر گروه دستگاه داشته باشید. اگر چندین SRX و EX دارید، Secret مشترک و ساده یکی از اولین چیزهایی است که بعدا دردسر درست میکند.
اضافه کردن Juniper Dictionary در Cisco ISE
برای اینکه ISE بتواند Attribute مخصوص Juniper را برگرداند، باید Dictionary مربوط به Juniper را بشناسد. در بعضی نسخهها یا نصبها ممکن است لازم باشد Dictionary جونیپر را دستی اضافه کنید؛ چیزی که مهم است این است که ISE Attribute مخصوص Juniper را بشناسد و بتواند آن را در Access-Accept برگرداند. مسیر کلی در ISE این است:
Policy > Policy Elements > Dictionaries > System > RADIUS > RADIUS Vendors
بعد از Import شدن Dictionary، Attributeهای Juniper در Authorization Policy و Authorization Profile قابل استفاده میشوند. چیزی که حداقل لازم داریم این است که ISE بعد از موفقیت Authentication، دو مقدار کلیدی را در Access-Accept برگرداند:
Service-Type = Login-User
Juniper-Local-User-Name = "<class_name>"در اینجا <class_name> همان Template یا کاربر محلیای است که روی Junos ساختیم؛ مثلا aa-readonly یا aa-netadmin. اگر نامی که ISE برمیگرداند با Template روی Junos همخوان نباشد، Authentication ممکن است موفق شود اما سطح دسترسی درست اعمال نشود.
ساخت Authorization Profile
در Cisco ISE خروجیهایی که باید به دستگاه برگردند، معمولا در Authorization Profile تعریف میشوند:
Policy > Policy Elements > Results > Authorization > Authorization Profiles
برای تیم عملیات، بهتر است Profileها با نامهای روشن ساخته شوند؛ مثلا ARABIYAN-JUNIPER-RO برای دسترسی خواندنی و ARABIYAN-JUNIPER-ADMIN برای دسترسی کامل. این نامگذاری ساده بعدا هنگام بررسی لاگ، Troubleshooting یا Audit خیلی کمک میکند.
گروهبندی دستگاههای Juniper در ISE
قدم بعدی این است که دستگاههای Juniper را به عنوان Network Access Device در ISE اضافه کنیم. برای مدیریت بهتر، دستگاهها را داخل Device Groupهای معنادار بگذارید. در این سناریو یک شاخه Juniper داریم و زیر آن دستگاههای ARABIYAN-SRX-Edge و ARABIYAN-EX-Access را جدا میکنیم.
این کار فقط مرتبسازی ظاهری نیست. سوئیچ EX، فایروال SRX و یک روتر Cisco لزوما Attributeهای یکسانی نمیفرستند و برای Authorization هم خروجی یکسان نمیخواهند. وقتی Device Group درست باشد، Ruleهای ISE تمیزتر میشوند و احتمال اینکه Profile اشتباه برای Vendor اشتباه اعمال شود پایین میآید.
Authentication Policy برای Junos
در سناریوی مقاله، Authentication Policy بر اساس منبع درخواست، یعنی دستگاه Juniper، و نوع درخواست، یعنی PAP/ASCII، تصمیم میگیرد که کاربر از دیتابیس داخلی ISE احراز هویت شود. در محیط سازمانی، این بخش ممکن است به Active Directory وصل باشد، اما منطق اصلی همان است: درخواست Login مدیریتی از دستگاه Juniper را از سایر درخواستها جدا کنید.
اینجا یک تفاوت مهم با Cisco IOS دیده میشود. در برخی سناریوهای Cisco IOS، Attributeهای بیشتری برای تشخیص نوع Login به سمت RADIUS ارسال میشود؛ برای مثال Service مربوط به Login. Junos در Capture نمونه چنین دادهای را مثل IOS نمیفرستد، بنابراین طراحی Rule در ISE باید بیشتر به Device Group، نوع پروتکل و گروه کاربری تکیه کند.
Authorization Policy و نگاشت گروه کاربر به سطح دسترسی
بعد از Authentication نوبت Authorization است. در این مرحله ISE بررسی میکند درخواست از چه نوع دستگاهی آمده، کاربر عضو کدام گروه است و باید کدام Authorization Profile برگردد. یک طراحی ساده میتواند اینطور باشد:
- کاربران گروه
NetOps-ReadOnlyروی دستگاههای Juniper مقدارJuniper-Local-User-Name = aa-readonlyبگیرند. - کاربران گروه
NetOps-Adminsروی دستگاههای Juniper مقدارJuniper-Local-User-Name = aa-netadminبگیرند. - برای دستگاههایی که در Device Group جونیپر نیستند، این Profileها اصلا قابل انتخاب نباشند.
اگر همهچیز درست باشد، کاربر با دسترسی مناسب وارد Junos میشود. در ISE هم باید بتوانید ببینید کدام Policy match شده، کدام Profile برگشته و چه Attributeهایی در پاسخ نهایی ارسال شدهاند.
سمت Junos یا Syslog Collector هم باید لاگ ورود موفق را ببینید. اگر Authentication موفق است ولی سطح دسترسی درست نیست، معمولا باید سه مورد را چک کنید: نام Template روی Junos، مقدار Juniper-Local-User-Name در ISE، و اینکه Dictionary Juniper درست Import شده باشد.
نکات عملی قبل از Production
قبل از اینکه این سناریو را روی شبکه واقعی پیاده کنید، چند کنترل ساده جلوی دردسرهای بعدی را میگیرد:
- حتما یک Local Emergency Account امن داشته باشید تا اگر ISE یا مسیر RADIUS قطع شد، دسترسی مدیریتی کامل از بین نرود.
- دسترسی کامل را فقط به گروههای کوچک و قابل Audit بدهید؛ همه اعضای تیم شبکه لازم نیست
super-userباشند. - برای SRX و EX، Ruleهای جدا در ISE بسازید تا بعدا سیاستها با هم قاطی نشوند.
- RADIUS Secret را برای هر Site یا گروه دستگاه کنترل کنید و آن را در مستندات عمومی یا Ticketهای باز ننویسید.
- لاگ ISE و Syslog دستگاهها را نگه دارید؛ در Audit امنیتی، همین لاگها نشان میدهند چه کسی، چه زمانی و با چه سطحی وارد دستگاه شده است.
جمعبندی
استفاده از Cisco ISE برای Login مدیریتی دستگاههای Juniper Junos راهحل پیچیدهای نیست، اما چند جزئیات مهم دارد: Junos باید Template محلی درست داشته باشد، ISE باید Juniper Dictionary و Attribute مناسب را بشناسد، دستگاهها باید در Device Group درست قرار بگیرند و Authorization Profile باید مقدار دقیق Juniper-Local-User-Name را برگرداند.
برای شاخه جونیپر عربیان، این مطلب در کنار راهنماهای Juniper، طراحی Policy در SRX و چکلیست HA قرار میگیرد. اگر قرار است این سناریو در محیط واقعی اجرا شود، بهتر است آن را فقط به عنوان یک تنظیم AAA نبینیم؛ این بخش مستقیما به کنترل دسترسی ادمینها، لاگ امنیتی و مدیریت ریسک عملیاتی وصل است.
یادداشت فنی: در این سناریو دو بخش را باید با دقت کنار هم دید: سمت Junos که Template و کلاس دسترسی را اعمال میکند، و سمت Cisco ISE که بعد از Authentication، Attribute درست را در Authorization برمیگرداند. اگر یکی از این دو سمت دقیق نباشد، Login ممکن است موفق شود اما سطح دسترسی درست اعمال نشود.
