دسترسی همکار به هاست؛ چه چیزی بدهیم و چه چیزی را نه

مدیر سایت هستید و باید به توسعه‌دهنده یا همکارتان دسترسی بدهید؟ این راهنما می‌گوید کدام دسترسی لازم است، کدام را نباید بدهید و چطور پس بگیرید.

۸ دقیقه به‌روزرسانی ۱۶ شهریور ۱۴۰۵

دسترسی همکار؛ جایی که امنیت سایت با سرعت کار تیم گره می‌خورد

توسعه‌دهنده‌ای که استخدام کرده‌اید می‌گوید «یوزر و پسورد cPanel را بده تا کار را شروع کنم». مدیر قبلی سایت هم رفته و فقط یک ایمیل خوش‌آمد از هاستینگ برایتان مانده که داخلش پسورد root یا دسترسی کامل به کنترل‌پنل است. شما مانده‌اید و یک تصمیم: کلید اصلی را بدهید یا نه؟

جواب کوتاه: نه. هرگز. اما این به آن معنا نیست که کارِ تیم متوقف شود. تقریباً هر کاری که یک توسعه‌دهنده یا همکار بخواهد انجام دهد، با یک دسترسی محدود و قابل پس‌گرفتن شدنی است. فقط باید بدانید کدام دسترسی برای کدام کار است و هزینهٔ هر انتخاب چیست.

این مقاله برای مدیری است که همین حالا پشت صفحه‌نشسته و باید تا یک ساعت دیگر دسترسی بدهد. نه برای کسی که می‌خواهد «مبانی امنیت» بخواند.

اول بفهمید طرف مقابل دقیقاً چه کاری باید بکند

دسترسی دادن بدون تعریفِ کار، مثل دادن کلید گاوصندوق به کسی است که فقط باید یک نامه از داخلش بردارد. قبل از هر اقدامی، بپرسید: این شخص قرار است چه چیزی را تغییر دهد؟ سه حالت رایج است:

  • تغییر محتوای سایت — نوشتن مقاله، آپلود عکس، ویرایش صفحه‌ها. این کار به دسترسی مدیریت محتوا نیاز دارد، نه دسترسی به سرور.
  • تغییر کد یا قالب — ویرایش فایل‌های PHP، CSS، جاوااسکریپت. این کار به دسترسی فایل نیاز دارد (FTP یا فایل‌منیجر).
  • تغییر تنظیمات سرور — نصب افزونهٔ سیستمی، تغییر PHP version، ری‌استارت سرویس. این کار به دسترسی کنترل‌پنل یا SSH نیاز دارد.

بیشتر درخواست‌هایی که با عنوان «دسترسی کامل» می‌آیند، در واقع از نوع اول یا دوم هستند. اگر طرف مقابل نتواند بگوید دقیقاً کدام فایل یا کدام تنظیم را می‌خواهد تغییر دهد، این خودش یک علامت هشدار است.

یک قانون سرانگشتی: هرچه دسترسی بالاتر باشد، آسیب‌پذیری در برابر اشتباه سهوی هم بالاتر می‌رود. یک rm -rf اشتباه از طرف کسی که دسترسی SSH دارد، سایت شما را بدون هیچ هشداری خالی می‌کند. همان کار را با FTP نمی‌شود به این راحتی کرد.

دسترسی FTP یا File Manager؛ رایج‌ترین حالتی که واقعاً به آن نیاز دارید

اگر توسعه‌دهنده باید قالب وردپرس را ویرایش کند یا فایل‌های سایت را جابه‌جا کند، دسترسی FTP کافی است. در cPanel یا دایرکت‌ادمین، یک حساب FTP جدا بسازید که فقط به پوشهٔ public_html دسترسی داشته باشد. این کار در cPanel از مسیر FTP Accounts انجام می‌شود.

نکتهٔ مهم: برای حساب FTP جدید، یک یوزرنیم جدا بسازید. از دادن یوزرنیم اصلی cPanel به عنوان یوزر FTP خودداری کنید. حساب FTP جدید را محدود به همان پوشهٔ اصلی سایت کنید و به آن اجازهٔ دسترسی به پوشه‌های etc یا logs ندهید.

حجم آپلود را هم محدود کنید. اگر قرار است فقط قالب عوض شود، سقف ۵۰ مگابایت بگذارید. این کار جلوی آپلود یک فایل ۲ گیگابایتی را می‌گیرد که دیسک شما را پر کند.

چه زمانی FTP جواب نمی‌دهد

FTP برای ویرایش فایل‌های تکی عالی است، اما برای کار با دیتابیس یا تغییر تنظیمات PHP بی‌فایده است. اگر توسعه‌دهنده می‌گوید «باید php.ini را عوض کنم» یا «یک افزونهٔ سیستمی نصب کنم»، FTP کمکی نمی‌کند. در این حالت یا باید از کنترل‌پنل یک دسترسی محدود بدهید یا از SSH با کلید عمومی.

این‌جا اشتباه می‌کنند: خیلی‌ها برای راحتی، پسورد اصلی cPanel را در اختیار توسعه‌دهنده می‌گذارند تا «همه‌کار را خودش انجام دهد». چند هفته بعد که همکاری تمام می‌شود، پسورد عوض می‌شود اما توسعه‌دهنده قبلی هنوز از طریق FTP به سایت دسترسی دارد، چون حساب FTP جداگانه‌ای ساخته نشده بود و او با همان یوزر اصلی وارد می‌شد. نتیجه: یک دسترسی باز که هیچ‌کس از وجودش خبر ندارد.

دسترسی SSH؛ فقط با کلید عمومی، فقط برای کار مشخص

اگر توسعه‌دهنده باید کامپوزر اجرا کند، کد را با Git دیپلوی کند یا اسکریپت‌های طولانی اجرا کند، FTP کافی نیست. دسترسی SSH لازم است. اما راه درست آن، دادن پسورد root نیست.

یک کاربر سیستمی جدا با دسترسی محدود بسازید. در هاست لینوکس مبتنی بر cPanel، از SSH Access در بخش امنیت، یک کلید عمومی برای کاربر جدید ثبت کنید. سپس در فایل /home/username/.ssh/authorized_keys گزینه‌های محدودکننده را اضافه کنید:

command="/usr/local/bin/deploy-script.sh",no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2E...

با این کار، آن کلید فقط می‌تواند یک دستور خاص را اجرا کند. نه rm، نه cat /etc/passwd، نه هیچ چیز دیگر. اگر توسعه‌دهنده بخواهد کار دیگری بکند، باید درخواست بدهد و شما اسکریپت را توسعه دهید.

این سخت‌گیرانه به نظر می‌رسد و هست. اما هزینهٔ این سخت‌گیری در مقایسه با یک نشتی دیتابیس ناچیز است. اگر تیم شما کوچک است و اعتماد کامل دارید، می‌توانید این محدودیت را بردارید و فقط به یک کاربر سیستمی با دسترسی به پوشهٔ سایت بسنده کنید. اما هرگز root ندهید.

دسترسی به دیتابیس؛ پرریسک‌ترین دسترسی بعد از root

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

اگر توسعه‌دهنده فقط باید ساختار دیتابیس را ببیند یا یک کوئری بنویسد، یک یوزر MySQL جدا با دسترسی فقط‌خواندنی بسازید. در cPanel از MySQL Databases یک کاربر جدید با دسترسی SELECT بسازید و آن را به دیتابیس موردنظر وصل کنید. این کاربر نمی‌تواند INSERT یا DELETE کند، فقط می‌خواند.

اگر واقعاً به دسترسی نوشتن نیاز دارد، یک دیتابیس جدا برای محیط تست بسازید و اجازهٔ کار روی دیتابیس اصلی را ندهید. توسعه‌دهنده روی کپی کار کند و بعد از تأیید، تغییرات را خودتان روی دیتابیس اصلی اعمال کنید.

پس‌گرفتن دسترسی؛ بخشی که همه فراموش می‌کنند

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

  1. پسورد اصلی cPanel یا کنترل‌پنل را عوض کنید.
  2. همهٔ حساب‌های FTP ساخته‌شده برای آن شخص را حذف کنید.
  3. کلیدهای SSH او را از authorized_keys پاک کنید.
  4. یوزرهای MySQL ساخته‌شده برای او را حذف کنید.
  5. اگر به او دسترسی به سرویس ایمیل داده بودید، پسورد ایمیل را هم عوض کنید.

این کار ۱۵ دقیقه وقت می‌گیرد. اما اگر انجام نشود، یک دسترسی باز می‌ماند که هیچ‌کس از آن خبر ندارد. بدترین سناریو این است که یک سال بعد، وقتی سایت هک می‌شود، در لاگ‌ها ببینید ورود از IPای بوده که متعلق به توسعه‌دهندهٔ سابق است.

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

دسترسی به کنترل‌پنل؛ فقط در حد نیاز، فقط برای مدت محدود

بعضی کارها مثل تغییر PHP version یا نصب افزونهٔ سیستمی فقط از کنترل‌پنل شدنی است. در این حالت، به جای دادن دسترسی اصلی، یک حساب زیرمجموعه (subaccount) بسازید که فقط به همان بخش دسترسی داشته باشد. cPanel این امکان را با Sub Accounts می‌دهد.

اگر هاست شما از این قابلیت پشتیبانی نمی‌کند و چاره‌ای جز دادن دسترسی موقت نیست، پسورد را بعد از اتمام کار عوض کنید. این کار را به «بعداً» موکول نکنید. همان لحظه که کار تمام شد، عوض کنید.

انتخاب بین سرویس‌های مختلف هاستینگ هم می‌تواند روی این موضوع اثر بگذارد. اگر بین هاست لینوکس و یک سرور مجازی مردد هستید، مقایسهٔ سرویس‌های هاست لینوکس، سرور ابری و اختصاصی را ببینید. در هاست اشتراکی، ابزارهای مدیریت دسترسی از پیش آماده هستند؛ در سرور مجازی، شما باید خودتان کاربر بسازید و محدود کنید.

دسترسی همکار در عمل؛ سناریوی پیشنهادی من

برای یک تیم دو تا پنج نفره که روی یک سایت وردپرسی کار می‌کنند، این چیزی است که من انجام می‌دهم:

  • یک حساب FTP جدا برای هر نفر، محدود به public_html، با سقف حجم آپلود.
  • یک یوزر MySQL فقط‌خواندنی برای هر کسی که باید دیتابیس را ببیند.
  • دسترسی SSH فقط برای یک نفر (نفر ارشد تیم) و فقط با کلید عمومی.
  • دسترسی کنترل‌پنل فقط برای مدیر سایت، نه برای هیچ‌کس دیگر.

اگر تیم بزرگ‌تر است یا پروژه حساس‌تر، به سراغ ابزارهای مدیریت کد مثل Git با دیپلوی خودکار بروید. در این حالت توسعه‌دهنده هیچ دسترسی مستقیمی به سرور ندارد؛ فقط کد را push می‌کند و یک اسکریپت در سرور آن را deploy می‌کند. این تمیزترین حالت است اما راه‌اندازی اولیه‌اش وقت می‌گیرد.

اگر تیم کوچک است و همه با هم‌دیگر در یک دفتر می‌نشینید، شاید FTP برای هر نفر زیادی باشد. یک حساب FTP مشترک برای تیم کافی است و فقط مدیر، پسورد آن را می‌داند. هزینهٔ این کار این است که نمی‌شود فهمید چه کسی چه فایلی را تغییر داده است. اگر این برایتان مهم است، حساب جدا بسازید.

برای انتخاب بین هاست اشتراکی و سرور مجازی از نظر انعطاف در مدیریت دسترسی، راهنمای انتخاب بین هاست، سرور مجازی یا اختصاصی را بخوانید. اگر به تازگی سرویس خریده‌اید و هنوز ایمیل خوش‌آمد را کامل نخوانده‌اید، راهنمای خواندن ایمیل خوش‌آمد هاستینگ به شما می‌گوید کدام تنظیمات را همان‌جا باید عوض کنید.

پرسش‌های پرتکرار

به توسعه‌دهنده چه دسترسی‌ای بدهم که امن باشد؟

یک حساب FTP جدا با دسترسی محدود به پوشهٔ public_html و یک یوزر MySQL فقط‌خواندنی اگر به دیتابیس نیاز دارد. دسترسی SSH فقط با کلید عمومی و در صورت نیاز واقعی. دسترسی root یا پسورد اصلی کنترل‌پنل را هرگز به کسی ندهید.

چطور دسترسی FTP را برای همکار بسازم؟

در cPanel به بخش FTP Accounts بروید، یک یوزرنیم جدید بسازید و در قسمت Directory آن را به public_html محدود کنید. یک پسورد قوی انتخاب کنید و حجم آپلود را محدود کنید. این حساب هیچ دسترسی به تنظیمات سرور ندارد.

بعد از اتمام کار توسعه‌دهنده چکار کنم؟

پسورد اصلی کنترل‌پنل را عوض کنید، حساب FTP او را حذف کنید، کلید SSH او را از authorized_keys پاک کنید و یوزرهای MySQL ساخته‌شده برایش را حذف کنید. این کار را همان روز اتمام همکاری انجام دهید، نه هفتهٔ بعد.

دسترسی SSH بهتر است یا FTP؟

برای کار با فایل‌ها و آپلود محتوا، FTP ساده‌تر و امن‌تر است. برای اجرای کامپوزر، دیپلوی با Git یا اسکریپت‌های طولانی، SSH لازم است. اگر نمی‌دانید SSH برای چه کاری می‌خواهید، احتمالاً به آن نیاز ندارید.

آیا این مطلب برایتان مفید بود؟