در بسیاری از سازمان‌ها دسترسی SSH به سرورهای Linux برای ادمین‌ها، تیم DevOps و پیمانکاران ضروری است. مسئله این نیست که دسترسی را به‌طور کامل ببندیم؛ مسئله این است که یک کاربر دارای مجوز SSH همچنان می‌تواند فرمانی اجرا کند که باعث توقف سرویس، حذف فایل، تغییر Firewall یا پاک‌کردن Log شود.

SSH Command Control در PAM360 برای همین سناریو اهمیت دارد: دسترسی ممتاز برقرار می‌ماند، اما اجرای فرمان‌های مشخص می‌تواند بر اساس Policy محدود، Block یا Audit شود و Session نیز قابل ثبت و بررسی باشد.

چرا Session Recording به‌تنهایی کافی نیست؟

Recording برای Forensics و Audit مهم است، اما ماهیت آن عمدتاً پس از وقوع است. Command Control یک لایه Preventive اضافه می‌کند؛ یعنی بعضی دستورهای پرریسک قبل از اجرا متوقف می‌شوند.

چه فرمان‌هایی معمولاً پرریسک‌اند؟

• فرمان‌های حذف Recursive؛
• Stop کردن سرویس‌های حیاتی؛
• خاموش یا Reboot کردن سرور؛
• تغییر Firewall Rule؛
• تغییر User/Group ممتاز؛
• پاک‌کردن Log؛
• دانلود یا اجرای Binary ناشناخته؛
• ویرایش فایل‌های حساس Configuration.

Policy نباید صرفاً Keyword خام باشد؛ Context، Role و Target Server اهمیت دارد.

Policy بر اساس Role بسازید

Database Admin، Linux Admin و Vendor نباید Command Scope یکسان داشته باشند. مدل مناسب این است:

سناریو: پیمانکار باید Troubleshooting کند اما نباید Service را Stop کند

فرض کنید Vendor برای بررسی Application به SSH نیاز دارد. Session باید برقرار شود، اما Policy می‌تواند فرمان‌هایی مثل توقف سرویس یا حذف فایل را محدود کند. این رویکرد از مدل «همه‌چیز یا هیچ‌چیز» بهتر است.

برای کنترل زمان‌دار و Approval دسترسی نیز مقاله Break-Glass Access در PAM360 و مقاله JIT Privileged Access با PAM360 را ببینید.

Command Control را با Session Recording ترکیب کنید

بهترین طراحی این است که سه لایه هم‌زمان وجود داشته باشد:

1. Authentication و Authorization قبل از Session؛
2. Command Policy حین Session؛
3. Recording و Audit پس از Session.

این ترکیب امکان پاسخ به سه سؤال را می‌دهد: چه کسی وارد شد؟ چه چیزی اجازه اجرا داشت؟ واقعاً چه کاری انجام شد؟

False Positive در Command Filtering

اگر Patternها بیش از حد کلی باشند، عملیات Legitimate Block می‌شود. مثلاً Block کردن واژه rm بدون Context می‌تواند Script یا مسیرهای بی‌خطر را هم متوقف کند. قبل از Enforcement عمومی، Policy باید روی Pilot Group تست شود.

Emergency Access را فراموش نکنید

در Incident واقعی ممکن است نیاز باشد فرمانی که معمولاً Block است اجرا شود. برای این حالت باید مسیر Exception با Approval، Time Limit و Logging وجود داشته باشد.

Live Session Monitoring چه کمکی می‌کند؟

در Sessionهای حساس، Security Admin می‌تواند Session را Live مشاهده کند و در صورت رفتار مشکوک آن را Terminate کند. Command Control پیشگیری می‌کند و Live Monitoring امکان واکنش انسانی را حفظ می‌کند.

Audit Trail برای تیم امنیت و Compliance

Command History و Session Recording باید با User، Account، Target، زمان Session و Ticket مرتبط شوند. این Traceability برای Investigation و Audit بسیار ارزشمند است.

KPIهای مفید

• تعداد Command Block شده؛
• Top User بر اساس Violation؛
• تعداد Exception؛
• Sessionهای Terminate شده؛
• درصد Sessionهای Vendor دارای Approval؛
• تعداد Policy False Positive.

Runbook پیشنهادی

1. Serverهای Critical شناسایی شوند.
2. Roleها و Command Scope تعریف شوند.
3. Policy در Audit/Pilot اجرا شود.
4. Block Ruleها مرحله‌ای فعال شوند.
5. Emergency Override تعریف شود.
6. Session Recording و Alert فعال شود.
7. Violationها دوره‌ای Review شوند.

نکات کلیدی

• SSH Access به معنی مجوز اجرای هر فرمان نیست.
• Recording و Command Control مکمل هم هستند.
• Policy باید Role-aware و Target-aware باشد.
• Vendor Access نیاز به محدودیت شدیدتر دارد.
• Exception باید ثبت و زمان‌دار باشد.

منابع

• ManageEngine PAM360
• PAM360 Help Documentation

سخن پایانی

کنترل واقعی دسترسی ممتاز فقط به Login ختم نمی‌شود. اگر کاربر بعد از SSH بتواند هر فرمانی اجرا کند، Least Privilege هنوز کامل نشده است. PAM360 با ترکیب Approval، Session Control، Recording و Command Policy می‌تواند این فاصله را کاهش دهد.

مدانت خدمات استعلام و خرید لایسنس PAM360، طراحی Privileged Access Policy، Session Management، SSH/RDP Control، JIT Access، استقرار و پشتیبانی ارائه می‌کند. برای اطلاعات محصول به صفحه PAM360 مدانت و برای مشاوره به تماس با مدانت مراجعه کنید.