سیاست‌های امنیتی Plesk

تعاریف کلیدی مقاله

1. Disk Security (امنیت دیسک):
   سیاست امنیتی Plesk که روی همه دیسک‌های سرور (به جز محتوای هاست) اعمال می‌شود و توسط فایل متادیتای امنیت دیسک تعریف می‌شود.
2. Hosting Security (امنیت هاستینگ):
   سیاست امنیتی مختص دایرکتوری‌های هاست (%plesk_vhosts%) که توسط فایل‌های متادیتای هاستینگ کنترل می‌شود.
3. Security Metadata File (فایل متادیتای امنیتی):
   فایل‌هایی که قوانین امنیتی را مشخص می‌کنند و مبنای اعمال سیاست‌های امنیتی در Plesk هستند.
4. psaadm (کاربر psaadm):
   حساب سیستمی که Plesk از آن برای ورود به سیستم و دسترسی به فایل‌ها و پوشه‌ها استفاده می‌کند.
5. psacln (گروه psacln):
   گروهی که تمام کاربران ساخته‌شده توسط Plesk عضو آن هستند.
6. psaserv (گروه psaserv):
   گروهی که برخی کاربران اینترنتی اضافه در آن عضو هستند.
7. Default User Permissions (مجوزهای پیش‌فرض کاربر):
   سطح دسترسی‌های تعیین‌شده برای کاربران مختلف (psaadm، psacln، psaserv و غیره) روی مسیرهای اصلی ویندوز و پوشه‌های Plesk.

Plesk دو سیاست امنیتی مختلف را نسبت به اشیای ویندوز اعمال می‌کند:

امنیت دیسک (Disk Security) و امنیت هاستینگ (Hosting Security). تفاوت این سیاست‌ها ناشی از نیازهای امنیتی متفاوت برای محتوای میزبانی‌شده در مقایسه با سایر دیسک‌های سرور است.

هر دو سیاست توسط قوانین امنیتی تعریف می‌شوند که در فایل‌های متادیتای امنیتی Plesk مشخص شده‌اند.

• سیاست امنیت دیسک در فایل متادیتای امنیت دیسک تعریف شده و روی تمام دیسک‌های سرور اعمال می‌شود، به جز دایرکتوری %plesk_vhosts% که محتوای هاستینگ در آن قرار دارد.
• تمام دایرکتوری‌های هاستینگ تحت سیاست‌های امنیتی تعریف‌شده در فایل‌های متادیتای هاستینگ قرار دارند. این فایل‌ها به صورت خودکار از روی قالب‌های متادیتای امنیت هاستینگ تولید می‌شوند.

حساب‌های ویندوزی که توسط Plesk برای مدیریت اشیای ویندوز استفاده می‌شوند

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

مجوزهای پیش‌فرض کاربران برای دیسک‌ها

Plesk برای مسیرها و پوشه‌های مختلف در ویندوز مجوزهای پیش‌فرضی تنظیم می‌کند. برخی مثال‌ها:

• ریشه دیسک (Disk root):
  • Everyone → فقط “Read & Execute” برای همین شیء.
  • psaadm → Deny Full Control.
  • psacln → [هیچ دسترسی خاصی]
• Program Files (x86):
  • psacln → Deny Full Control به جز “Read Attributes”.
• Program Files (x86)\Common Files:
  • psaadm، psacln، psaserv، NETWORK SERVICE → Read & Execute.
• Windows, Documents and Settings, Application Data (ProgramData):
  • psaadm، psacln، psaserv، NETWORK SERVICE → دسترسی ممنوع (Access is not allowed).
• %SystemDrive%\inetpub\temp:
  • users → مشاهده، ایجاد پوشه و خواندن/نوشتن/اجرا.
  • psaadm → مشاهده محتوا و اجرای فایل‌ها.
• Windows\Temp:
  • psaadm، psacln، psaserv، NETWORK SERVICE → مشاهده محتوا و اجرای فایل‌ها.
• %plesk_dir% (دایرکتوری نصب Plesk):
  • psaadm → Read & Execute.
  • psacln → Deny Full Control.
  • psaserv و NETWORK SERVICE → دسترسی پایه.
• %plesk_bin% (دایرکتوری ابزارهای داخلی Plesk):
  • psaadm → Read & Execute.
  • psacln → Read Attributes برای خود شیء و Read & Execute برای فایل‌ها.
• %plesk_vhosts% (دایرکتوری هاست‌های مجازی):
  • psacln → Deny Full Control به جز Read Attributes (برای خود شیء فقط).
  • psaadm → Deny Full Control (برای خود شیء فقط).
  • psaserv و NETWORK SERVICE → دسترسی پایه.

⚠️ توجه:

مجوزهای واقعی که روی اشیای ویندوز اعمال می‌شوند ممکن است با مجوزهای پیش‌فرض فهرست‌شده تفاوت داشته باشند، زیرا برخی از آن‌ها نتیجه ترکیب چندین قانون امنیتی هستند.

📝 توضیحات بیشتر

1. چرا دو سیاست امنیتی وجود دارد؟
   • امنیت دیسک برای محافظت از کل سیستم و جلوگیری از دسترسی غیرمجاز به فایل‌های سیستمی.
   • امنیت هاستینگ برای ایزوله‌سازی کاربران و وب‌سایت‌ها از یکدیگر.
2. نقش حساب‌های psaadm، psacln و psaserv:
   • psaadm: دسترسی مدیریتی برای Plesk.
   • psacln: کاربران ساخته‌شده توسط Plesk، اما محدودشده در دسترسی.
   • psaserv: کاربران اینترنتی خاص، معمولاً برای سرویس‌های اضافی.
3. چرا مجوزها به‌صورت Deny تنظیم شده‌اند؟
   سیاست Plesk همیشه اصل «کمترین دسترسی لازم» (Least Privilege) را دنبال می‌کند. یعنی دسترسی به صورت پیش‌فرض ممنوع است مگر در مواردی که نیاز باشد.
4. کاربرد عملی برای مدیران سرور:
   • اگر در وب‌سایت‌ها خطای “Permission Denied” رخ دهد، باید بررسی شود که آیا مجوزها مطابق سیاست Plesk هستند یا خیر.
   • برای امنیت بیشتر، مدیران می‌توانند فایل‌های متادیتای امنیتی را ویرایش و دوباره اعمال کنند.
5. خطر تغییر دستی بدون دانش:
   تغییر نادرست مجوزها می‌تواند باعث از کار افتادن سرویس‌ها یا حتی دسترسی کامل هکرها به سیستم شود.

کیان پور