در MySQL، نام کاربری به‌تنهایی حساب را مشخص نمی‌کند؛ ترکیب نام کاربر و میزبان، مانند app_user@localhost، هویت حساب را می‌سازد. برای مدیریت امن، ابتدا حساب واقعیِ متصل و مجوزهای آن را بشناسید، سپس فقط دسترسی موردنیاز را تغییر دهید. برنامه وب نباید صرفاً برای رفع یک خطای اتصال، با حساب root یا مجوز کامل روی همه دیتابیس‌ها اجرا شود.
دامنه این راهنما و ورود مدیریتی
نمونه‌ها برای MySQL 8.4 نوشته شده‌اند. در MariaDB یا نسخه‌های دیگر، روش احراز هویت و برخی جزئیات فرق دارد. حساب اجراکننده باید مجوز لازم برای مدیریت همان حساب‌ها را داشته باشد. رمز را بعد از -p در خط فرمان ننویسید تا در تاریخچه یا فهرست پردازش‌ها آشکار نشود.
mysql -u root -pدر بعضی نصب‌های لینوکسی، مدیر محلی از احراز هویت socket استفاده می‌کند و ورود مجاز با sudo mysql انجام می‌شود؛ این موضوع به بسته و تنظیم نصب وابسته است.
حساب و مجوز فعلی را ببینید
SELECT USER(), CURRENT_USER();
SHOW GRANTS FOR CURRENT_USER;
SHOW GRANTS FOR 'app_user'@'localhost';USER نشان می‌دهد اتصال با چه اطلاعاتی آمده و CURRENT_USER حسابی را نشان می‌دهد که سرور برای احراز هویت و مجوزها به کار گرفته است. اگر این دو غیرمنتظره‌اند، پیش از افزودن دسترسی بیشتر، منبع اتصال و تعریف حساب را بررسی کنید.
تغییر رمز و هماهنگی با برنامه
ALTER USER 'app_user'@'localhost' IDENTIFIED BY 'REPLACE_WITH_A_UNIQUE_SECRET';عبارت نمونه را با یک رمز طولانی و یکتا جایگزین کنید؛ آن را در گزارش پشتیبانی منتشر نکنید. تغییر رمز در دیتابیس بدون تغییر امن تنظیمات برنامه، اتصال سایت را قطع می‌کند. برای سرویس حساس، زمان‌بندی و روش چرخش رمز را با تیم برنامه هماهنگ کنید.
مجوز غیرضروری را محدود کنید
ابتدا خروجی SHOW GRANTS را ثبت کنید. به جای تغییر مستقیم جدول‌های داخلی mysql، از دستورهای مدیریت حساب استفاده کنید. مثال زیر فقط مجوزهای تغییر ساختار را از حساب مشخص روی دیتابیس مشخص می‌گیرد؛ نام‌ها و نیاز واقعی برنامه باید پیش از اجرا کنترل شوند.
REVOKE CREATE, ALTER, DROP ON site_db.* FROM 'app_user'@'localhost';
SHOW GRANTS FOR 'app_user'@'localhost';برخی نصب‌کننده‌ها و به‌روزرسانی‌های CMS برای مهاجرت schema به مجوز تغییر ساختار نیاز دارند. حداقل دسترسی را بر اساس عملیات واقعی تعیین کنید، نه با حذف کور همه مجوزها.
حذف حساب با حذف داده متفاوت است
قبل از DROP USER، اتصال‌های فعال، تنظیمات برنامه، jobها و اشیایی که DEFINER آن حساب است بررسی شوند. حذف کاربر، طرح پاکسازی خودکار داده‌ها نیست و نباید جایگزین بکاپ باشد. اگر هنوز وابستگی نامشخص دارید، ابتدا استفاده از حساب را بررسی و برای توقف آن برنامه‌ریزی کنید.
خطاهای رایج و کنترل نهایی
- Access denied الزاماً با اعطای ALL PRIVILEGES حل نمی‌شود؛ رمز، host، افزونه احراز هویت و TLS را بررسی کنید.
- برای مدیریت حساب از CREATE USER، ALTER USER، GRANT و REVOKE استفاده کنید؛ پس از این دستورها معمولاً نیازی به FLUSH PRIVILEGES نیست.
- در پایان، اتصال برنامه را با همان user و همان مسیر شبکه آزمایش کنید؛ موفقیت ورود root، سلامت حساب برنامه را ثابت نمی‌کند.
مطالعه مرتبط
منابع و مستندات
بازبینی محتوا و منابع: ۲۶ مهر ۱۴۰۵. دستورهای نمونه برای محیط مشخص‌شده‌اند؛ پیش از استفاده روی سرویس عملیاتی، سازگاری محیط و نسخه پشتیبان را بررسی کنید.
