تصور کنید یک مدیر لینوکس شش ماه پیش برای اتصال به چند سرور Production یک SSH Key ساخته است. همان کلید بعداً برای دو سرور دیگر هم استفاده شده، نسخه‌ای از Private Key روی لپ‌تاپ او باقی مانده و Public Key نیز در چند فایل authorized_keys قرار گرفته است. حالا آن کارشناس تیم را ترک کرده، اما هیچ‌کس با اطمینان نمی‌داند این کلید دقیقاً روی چند سیستم فعال است.

این سناریو در محیط‌های بزرگ عجیب نیست. مشکل SSH Key معمولاً از خود رمزنگاری شروع نمی‌شود؛ از نبود Inventory، مالکیت، Rotation و حذف کنترل‌شده شروع می‌شود. کلیدی که زمانی کاملاً معتبر بوده، اگر بدون مالک، بدون تاریخچه و بدون چرخه عمر باقی بماند، می‌تواند به یک مسیر دسترسی ممتاز ناشناخته تبدیل شود.

ManageEngine PAM360 برای مدیریت همین چرخه طراحی شده است: کشف SSH Resourceها و Keyها، ساخت Inventory متمرکز، Associate کردن Key به Account، ایجاد و Deploy کلید جدید، Rotation زمان‌بندی‌شده، حذف Trustهای قدیمی و Audit تغییرات. در این راهنما تمرکز ما فقط روی یک قابلیت مشخص است: مدیریت SSH Key در PAM360 و اینکه چگونه می‌توان از پراکندگی کلیدها به یک مدل قابل‌کنترل برای دسترسی ممتاز رسید.

اگر ابتدا می‌خواهید تصویر کلی محصول را ببینید، صفحه PAM360 مدانت نقطه شروع مناسبی است. این مقاله به‌عنوان یک راهنمای اجرایی، بخش SSH Key Management همان Pillar را عمیق‌تر می‌کند.

چرا SSH Key می‌تواند به Shadow Privilege تبدیل شود؟

SSH Key برای Authentication بسیار قدرتمند است. در بسیاری از محیط‌های Linux و Unix، Automation، Backup، انتقال فایل، مدیریت زیرساخت و ارتباط Service-to-Service بدون آن عملاً دشوار است. اما همین مزیت باعث می‌شود Keyها خیلی سریع تکثیر شوند.

یک Administrator ممکن است یک Key Pair بسازد و Public Key را روی چند Server قرار دهد. یک اسکریپت ممکن است همان Private Key را برای Automation استفاده کند. یک Vendor ممکن است برای Maintenance دسترسی موقت بگیرد و بعد Public Key او در authorized_keys باقی بماند. مدتی بعد دیگر مشخص نیست کدام Key برای چه Use Caseای ساخته شده است.

در این شرایط چند سؤال ساده پاسخ روشنی ندارند:

• این Private Key متعلق به چه کسی است؟
• روی چند Account یا Server Deploy شده است؟
• آخرین Rotation آن چه زمانی بوده؟
• آیا Owner هنوز در سازمان است؟
• اگر کلید Compromise شود، Blast Radius آن چقدر است؟
• آیا کلید دیگری همان دسترسی را دارد؟
• آیا Key بلااستفاده یا Orphan در محیط باقی مانده است؟

از اینجا SSH Key از یک Credential امن به یک Shadow Privilege تبدیل می‌شود؛ دسترسی‌ای که وجود دارد اما Governance آن ضعیف است.

PAM360 در چرخه عمر SSH Key چه نقشی دارد؟

مستندات رسمی ManageEngine، PAM360 را برای مدیریت چرخه کامل SSH Key معرفی می‌کنند: Discovery، Inventory، Generation، Deployment، Association، Rotation، Dissociation و Audit. هدف این است که Keyها به‌جای پراکندگی در فایل‌ها و Scriptها، در یک مدل مرکزی و قابل ردیابی مدیریت شوند.

مرحله اول: قبل از Rotation، Inventory بسازید

یکی از اشتباهات رایج این است که پروژه SSH Security را مستقیماً با Rotation شروع کنیم. اگر ندانیم چه Keyهایی وجود دارند و کجا استفاده می‌شوند، Rotation می‌تواند دسترسی‌های عملیاتی را مختل کند.

در PAM360، مدیریت SSH Key از اضافه کردن SSH Resourceها به Repository شروع می‌شود. Resourceها را می‌توان دستی یا از طریق Discovery وارد کرد. پس از آن، PAM360 می‌تواند Keyهای موجود روی Accountهای انتخاب‌شده را Discover کند و آن‌ها را همراه با اطلاعات Audit وارد Inventory کند.

طبق مستند رسمی، برای Discovery و عملیات مدیریت Key روی SSH Resource، PAM360 به یک Remote Login Method و در بسیاری از سناریوها به Privilege Elevation مناسب نیاز دارد. اگر قرار است Keyهای Accountهای مختلف یک Linux Resource کشف یا Rotate شوند، Account مورد استفاده برای مدیریت باید Permission کافی، مانند sudo یا دسترسی معادل، داشته باشد.

Inventory خوب باید چه چیزهایی را نشان دهد؟

حداقل این اطلاعات باید برای Keyهای مهم قابل پاسخ باشد:

• نام و Fingerprint کلید
• Owner یا Account مرتبط
• Resourceهایی که Key روی آن‌ها Deploy شده
• تاریخ ایجاد
• آخرین Rotation
• Accountهای مرتبط
• وضعیت Keyهای قدیمی یا بدون استفاده
• تاریخچه تغییرات

هدف Inventory این نیست که فقط تعداد Keyها را بدانیم؛ باید بتوانیم Trust Relationship را ببینیم. یعنی اگر Key شماره 27 Compromise شد، دقیقاً بدانیم چه Accountها و چه Serverهایی تحت تأثیر قرار می‌گیرند.

مرحله دوم: رابطه Key با User و Resource را شفاف کنید

PAM360 اجازه می‌دهد SSH Key با User Account یا Resourceهای مرتبط Associate شود. این Mapping یکی از مهم‌ترین قسمت‌های پروژه است، چون Rotation بدون Association درست معنی ندارد.

فرض کنید Private Key با نام prod-ops-key به سه Account متصل است:

• opsadmin@app01
• opsadmin@app02
• deploy@app03

اگر Key Compromise شود، Scope دسترسی دیگر یک Server نیست. Inventory PAM باید این ارتباط را شفاف نشان دهد تا Incident Response و Rotation هدفمند انجام شود.

ManageEngine در راهنمای Remote Connection مبتنی بر SSH Key توصیه می‌کند برای حفظ امنیت بهتر، تا حد امکان یک SSH Key به یک Account اختصاص داده شود؛ هرچند PAM360 از Association یک Key با چند Account هم پشتیبانی می‌کند. این Best Practice باعث می‌شود Blast Radius یک کلید محدودتر باشد و Revocation دقیق‌تری انجام شود.

یک Key برای ده Server؛ چرا Convenience می‌تواند ریسک بسازد؟

استفاده از یک Key مشترک برای تعداد زیادی Server در ابتدا بسیار ساده به نظر می‌رسد. Automation راحت‌تر است و مدیریت فایل کمتر می‌شود. اما در زمان Compromise، همین ساده‌سازی تبدیل به نقطه ضعف می‌شود.

اگر یک Private Key مشترک به ۳۰ Account متصل باشد، افشای همان یک Key ممکن است مسیر دسترسی به ۳۰ مقصد را باز کند. این مسئله به‌خصوص درباره Automation Accountها و Service Accountها مهم است؛ چون Keyهای آن‌ها ممکن است سال‌ها بدون تغییر باقی بمانند.

مدل بهتر این است که Scope Keyها را محدود کنیم، Owner روشن داشته باشیم و Rotation را در چرخه عملیاتی قرار دهیم.

مرحله سوم: Key جدید را از داخل PAM360 بسازید و Deploy کنید

PAM360 فقط Inventory Keyهای موجود نیست. می‌توان Key Pair جدید ایجاد کرد و آن را روی Accountهای هدف Deploy کرد.

این رویکرد برای سازمانی مفید است که می‌خواهد از یک محیط قدیمی و نامنظم به یک Framework مدیریت‌شده مهاجرت کند. به‌جای اینکه تیم‌ها جداگانه Key بسازند، Key Generation و Deployment می‌تواند از یک کنترل مرکزی انجام شود.

در یک Rollout مرحله‌ای، بهتر است ابتدا Keyهای مربوط به Resourceهای Critical را وارد Scope کنید:

1. Production Linux Serverها
2. Database Serverها
3. Jump Serverها
4. Automation Accountهای حساس
5. Backup و Recovery Serverها
6. Network Applianceهایی که SSH Access دارند

سپس Accountهای کم‌ریسک‌تر را اضافه کنید.

مرحله چهارم: Rotation را از یک پروژه دستی به Schedule تبدیل کنید

یکی از قابلیت‌های اصلی SSH Key Management در PAM360، Rotation خودکار و زمان‌بندی‌شده است. طبق مستند فعلی ManageEngine، Keyهایی که به Accountهای Resource Associate شده‌اند می‌توانند On-demand یا براساس Schedule Rotate شوند.

در Rotation، PAM360 Key Pair تازه تولید می‌کند و بسته به Configuration می‌تواند Public Key یا Private/Public Key را برای User Accountهای مرتبط Push کند. نتیجه Rotation نیز در Key Rotation Audit ثبت می‌شود.

Rotation Schedule را چطور طراحی کنیم؟

یک Interval ثابت برای همه Keyها معمولاً منطقی نیست. Frequency باید بر اساس Risk تعیین شود.

این بازه‌ها باید با Policy امنیتی، Availability Requirement و Automation واقعی سازمان هماهنگ شوند. هدف Rotation این نیست که سرویس را ناپایدار کنیم؛ هدف کاهش عمر Credential بدون شکستن Dependencyهاست.

Rotation بدون Dependency Mapping می‌تواند سرویس را قطع کند

اگر یک Key فقط برای Login انسانی استفاده شود، Rotation نسبتاً ساده است. اما اگر همان Key در Script، Cron Job، CI/CD Pipeline یا Backup Tool استفاده شده باشد، تغییر Key بدون Update Consumer باعث Failure می‌شود.

پیش از Rotation یک Key حساس، این موارد را بررسی کنید:

• آیا Key توسط Script استفاده می‌شود؟
• آیا Automation Tool به Private Key وابسته است؟
• آیا Service Account از آن استفاده می‌کند؟
• آیا Jump Server یا Landing Server در مسیر است؟
• آیا Failback Plan تعریف شده است؟
• آیا تست پس از Rotation وجود دارد؟

Rotation خوب باید Security + Reliability را هم‌زمان ببیند.

مرحله پنجم: Keyهای رهاشده را Dissociate کنید

وقتی یک User سازمان را ترک می‌کند یا دسترسی موقت او تمام می‌شود، فقط Disable کردن Account مرکزی کافی نیست؛ اگر SSH Trust مستقل روی Serverها باقی مانده باشد باید حذف شود.

PAM360 امکان Dissociate کردن SSH Key از User Account را فراهم می‌کند. در مستندات رسمی ManageEngine نیز این سناریو صریحاً برای Userی که سازمان را ترک کرده یا Temporary Privileged Access داشته مطرح شده است.

این قابلیت برای Offboarding اهمیت زیادی دارد، چون SSH Key می‌تواند خارج از چرخه Password قرار داشته باشد. اگر Offboarding فقط روی Password Reset و Disable AD Account تمرکز کند، بعضی Trustهای SSH ممکن است باقی بمانند.

برای طراحی کامل‌تر Offboarding، مقاله دسترسی JIT در PAM360 و Zero Standing Privileges را هم ببینید؛ JIT و SSH Key Lifecycle دو لایه متفاوت اما مکمل برای کاهش Standing Privilege هستند.

Append یا Overwrite در authorized_keys؟

PAM360 برای SSH Policy دو رویکرد اصلی ارائه می‌کند:

• Append: Key جدید اضافه می‌شود و Mappingهای قبلی حفظ می‌شوند.
• Overwrite: Keyهای موجود حذف می‌شوند و فقط Keyهای مدیریت‌شده جدید باقی می‌مانند.

Append برای Migration تدریجی امن‌تر است، چون احتمال قطع دسترسی کمتر می‌شود. اما اگر محیط پر از Keyهای قدیمی و ناشناخته باشد، Append ممکن است همان Shadow Privilegeهای قبلی را حفظ کند.

Overwrite کنترل قوی‌تری ایجاد می‌کند، اما باید با دقت و Pilot اجرا شود؛ چون حذف ناگهانی Public Keyهای موجود می‌تواند Automation یا Access مشروع را قطع کند.

چه زمانی Overwrite منطقی است؟

وقتی سازمان Inventory قابل اعتماد دارد، Consumerهای Key مشخص‌اند، Rollback Plan وجود دارد و می‌خواهد Trust Model را از نو استاندارد کند. اجرای یک‌باره Overwrite در محیط ناشناخته توصیه عملی مناسبی نیست.

Key Group چه کمکی می‌کند؟

در محیط بزرگ ممکن است صدها یا هزاران SSH Key داشته باشید. مدیریت تک‌به‌تک آن‌ها مقیاس‌پذیر نیست.

PAM360 از Key Group برای مدیریت گروهی Keyها استفاده می‌کند. Key Group می‌تواند برای Scheduleهای Rotation و عملیات دسته‌ای مفید باشد.

مثلاً می‌توانید Groupهای زیر را تعریف کنید:

• Production-Linux-Root
• Database-SSH-Keys
• DevOps-Automation
• Vendor-Temporary
• Network-Devices

گروه‌بندی باید براساس Risk و Ownership باشد، نه صرفاً Location. این کار باعث می‌شود Rotation Schedule و Policy دقیق‌تری تعریف کنید.

Audit؛ چه کسی Key را ساخت، Rotate کرد یا حذف کرد؟

یکی از مزیت‌های اصلی مدیریت مرکزی، Audit Trail است. PAM360 تاریخچه ایجاد، Association، Rotation و عملیات Key را ثبت می‌کند و Key Rotation Audit برای بررسی نتیجه Rotation در دسترس است.

برای تیم Security و Audit، این سؤال‌ها اهمیت دارند:

• چه کسی Key را ایجاد کرده است؟
• چه زمانی Rotate شده؟
• Rotation موفق بوده یا Failure داشته؟
• Key به چه Accountهایی متصل بوده؟
• چه کسی Mapping را تغییر داده؟
• آیا Key از زمان Policy بیشتر عمر کرده است؟

مستندات PAM360 همچنین امکان Notification و Dashboard برای Keyهایی که مدت تعیین‌شده Rotate نشده‌اند را توضیح می‌دهد. این یعنی Policy می‌تواند از یک دستورالعمل دستی به یک کنترل قابل پایش تبدیل شود.

Remote Session با SSH Key؛ Private Key را بین کاربران پخش نکنید

در معماری سنتی، برای اینکه Administrator به Server وصل شود، Private Key در اختیار او قرار می‌گیرد. هر نسخه‌ای که از Private Key روی Endpointهای مختلف ذخیره شود، Scope حفاظت از Credential را بزرگ‌تر می‌کند.

PAM360 امکان Remote Connection به SSH-based Device با SSH Key را از طریق Interface خود ارائه می‌کند. Key باید ابتدا با Account مربوط Associate شده باشد و سپس Session می‌تواند با همان Credential مدیریت‌شده ایجاد شود.

در طراحی PAM هدف بهتر این است که تا حد امکان User به Access برسد، نه اینکه الزاماً Raw Credential را دریافت کند. این منطق با Session Governance، Approval و Audit سازگارتر است.

SSH Key Management را با JIT ترکیب کنید

مدیریت Key و JIT دو مسئله جدا هستند.

Key Management می‌پرسد:

Credential چگونه ساخته، نگهداری، Rotate و حذف می‌شود؟

JIT می‌پرسد:

User چه زمانی و برای چه مدت مجاز است از Privilege استفاده کند؟

اگر فقط Key را Rotate کنیم ولی User دائماً مجاز به استفاده از آن باشد، Standing Access همچنان وجود دارد. اگر فقط JIT داشته باشیم ولی Keyهای قدیمی و Orphan در Serverها باقی بمانند، Credential Hygiene ناقص است.

ترکیب این دو مدل معماری قوی‌تری می‌سازد:

1. Key در PAM360 Inventory می‌شود.
2. Key به Account مشخص Associate می‌شود.
3. Rotation دوره‌ای اجرا می‌شود.
4. User Access پشت Workflow قرار می‌گیرد.
5. دسترسی در Window مشخص فعال می‌شود.
6. Session Audit می‌شود.
7. در پایان نیاز، Access و Mappingهای غیرضروری حذف می‌شوند.

برای درک عمیق‌تر JIT، راهنمای Zero Standing Privileges در PAM360 مکمل همین مقاله است.

SSH Keyهای Automation و DevOps را جداگانه ببینید

Human Admin Account و Automation Account یک Risk Profile ندارند.

یک Key انسانی ممکن است روزی چند بار استفاده شود، اما Automation Key می‌تواند هر دقیقه توسط Pipeline، Ansible Job یا Backup Process فراخوانی شود. Rotation چنین Keyهایی باید با Dependency و Secret Consumer هماهنگ باشد.

PAM360 در معماری کلی خود قابلیت‌های Application Credential Security و DevOps Protection هم دارد. بنابراین اگر Key بخشی از CI/CD یا Automation است، پروژه را فقط در سطح Linux Admin نبینید؛ Ownerهای DevOps و Application هم باید در Rotation Plan مشارکت داشته باشند.

سناریو: خروج یک Linux Administrator

فرض کنید کارشناس ارشد Linux از سازمان جدا می‌شود. او به ۴۰ Server دسترسی داشته و چند SSH Key در طول سال‌ها ساخته است.

یک Offboarding ضعیف:

1. Account ایمیل Disable می‌شود.
2. AD Account Disable می‌شود.
3. Passwordهای شناخته‌شده تغییر می‌کنند.
4. SSH Keyها بررسی نمی‌شوند.

یک Offboarding مبتنی بر PAM:

1. Keyهای متعلق یا مرتبط با User از Inventory استخراج می‌شوند.
2. Association هر Key با Resource بررسی می‌شود.
3. Keyهای اختصاصی User Dissociate یا Revoke می‌شوند.
4. Keyهای Shared از نظر Owner و Consumer بازبینی می‌شوند.
5. در صورت نیاز Rotation انجام می‌شود.
6. Trustهای باقی‌مانده Verify می‌شوند.
7. Audit Evidence نگهداری می‌شود.

تفاوت اصلی این دو مدل در «دید» است. بدون Inventory، Offboarding به حدس متکی است.

سناریو: یک Private Key احتمالاً افشا شده است

فرض کنید تیم SOC اعلام می‌کند Laptop یکی از Adminها compromise شده و احتمال می‌رود Private Key روی دستگاه در معرض دسترسی مهاجم قرار گرفته باشد.

اولین سؤال Incident Commander باید این باشد:

این Key کجا Trust شده است؟

اگر Inventory مرکزی وجود داشته باشد، می‌توان Key-to-User و Key-to-Resource Relationship را سریع‌تر بررسی کرد. سپس Rotation یا Dissociation هدفمند انجام داد.

در محیط بدون Inventory، تیم باید Server به Server بگردد و authorized_keys را بررسی کند؛ در Incident واقعی، همین تأخیر می‌تواند مهم باشد.

یک Rollout شش‌مرحله‌ای برای سازمان

فاز ۱: Discovery بدون تغییر

ابتدا فقط Visibility بسازید. Resourceها و Keyها را Discover کنید و چیزی را حذف نکنید.

فاز ۲: Classification

Keyها را بر اساس Criticality، Owner، Human/Automation و Environment طبقه‌بندی کنید.

فاز ۳: Orphan Cleanup

Keyهای بدون Owner یا بدون Use Case روشن را بررسی و پس از تأیید حذف کنید.

فاز ۴: Controlled Rotation

Rotation را روی Scope محدود Pilot کنید و Dependencyها را Verify کنید.

فاز ۵: Scheduling

Keyهای Production و Automation را در Scheduleهای متناسب قرار دهید.

فاز ۶: Governance

Policy، Audit، Notification، Offboarding و Incident Response را به چرخه SSH Key متصل کنید.

KPIهای مفید برای SSH Key Governance

بهتر است KPI فقط «تعداد Keyهای مدیریت‌شده» نباشد. ۵۰۰۰ Key در Vault اگر Owner و Rotation نداشته باشند، Governance واقعی ایجاد نکرده‌اند.

Checklist پیشنهادی قبل از Production Rollout

• Resourceهای SSH حیاتی شناسایی شده‌اند.
• Account مدیریتی با Privilege لازم برای Discovery مشخص است.
• Inventory Keyها قبل از تغییر تهیه شده است.
• Owner هر Key حساس مشخص است.
• Automation Consumerها شناسایی شده‌اند.
• Shared Keyها علامت‌گذاری شده‌اند.
• Rotation ابتدا روی Scope محدود تست شده است.
• Rollback Plan برای Failure وجود دارد.
• Keyهای Userهای خارج‌شده Dissociate شده‌اند.
• Append/Overwrite Policy آگاهانه انتخاب شده است.
• Key Groupها بر اساس Risk طراحی شده‌اند.
• Notification برای Keyهای Rotateنشده فعال است.
• Audit Rotation دوره‌ای بازبینی می‌شود.
• Offboarding شامل SSH Key Review است.
• Incident Response برای Compromised Key تعریف شده است.

نکته‌های کلیدی

• SSH Key امن است، اما Key بدون Owner و Lifecycle امن نیست.
• پیش از Rotation، Inventory و Dependency Mapping انجام دهید.
• PAM360 می‌تواند SSH Keyها را Discover، Associate، Generate، Deploy، Rotate و Audit کند.
• Rotation را براساس Risk و Use Case زمان‌بندی کنید، نه یک Interval یکسان برای همه.
• Shared Keyهای گسترده Blast Radius را افزایش می‌دهند.
• Offboarding باید SSH Trust را هم پوشش دهد، نه فقط Password و AD Account.
• JIT Access و SSH Key Lifecycle مکمل یکدیگرند.
• برای Automation Keyها، تیم DevOps و Owner سرویس را وارد Rotation Plan کنید.

سخن پایانی

بزرگ‌ترین مشکل SSH Key معمولاً این نیست که رمزنگاری آن ضعیف است؛ مشکل این است که بعد از چند سال، سازمان دیگر نمی‌داند چه Keyی کجا قرار دارد، چه کسی Owner آن است و اگر Compromise شود چه چیزی باید فوراً تغییر کند.

PAM360 این مسئله را از یک مجموعه فایل پراکنده به یک چرخه قابل مدیریت تبدیل می‌کند: Discovery، Inventory، Association، Rotation، Revocation و Audit. ارزش واقعی وقتی ایجاد می‌شود که این قابلیت‌ها به Offboarding، JIT Access، Incident Response و DevOps Workflow متصل شوند.

اگر می‌خواهید وضعیت SSH Keyهای سازمان، Privileged Accountها و مدل دسترسی فعلی را ارزیابی کنید، صفحه PAM360 مدانت برای بررسی قابلیت‌های محصول در دسترس است. برای آموزش عملی نیز برنامه آموزشی PAM360 مدانت را ببینید. برای برآورد لایسنس، Edition و تعداد Resource/Administrator می‌توانید از استعلام لایسنس محصولات ManageEngine استفاده کنید یا از طریق درخواست دمو و مشاوره تخصصی سناریوی پیاده‌سازی سازمانتان را بررسی کنید.

برای مطالعه مفاهیم پایه مدیریت دسترسی ممتاز نیز راهنمای Privileged Access Management در ServiceDeskPlus.ir می‌تواند مکمل این مسیر باشد.

منابع

• ManageEngine PAM360 – SSH Keys Discovery and Creation
• ManageEngine PAM360 – Managing SSH Keys and Key Groups
• ManageEngine PAM360 – SSH Key Management
• ManageEngine PAM360 – Remote Connection Using SSH Keys
• ManageEngine PAM360 – SSH Policy Configuration