learn

ایمن‌سازی Redis در اوبونتو؛ شبکه محلی و دسترسی ACL

بخش دوم راهنمای Redis: تفکیک حساب مدیریت و برنامه و بررسی دسترسی مجاز و غیرمجاز.

ایمن‌سازی Redis در اوبونتو به محدودیت شبکه و دسترسی متناسب برنامه نیاز دارد. این راهنما برای نمونهٔ تازهٔ محلی با Redis 6 یا جدیدتر است. روی سرویس فعال، ابتدا کلاینت‌ها و روش احراز هویت موجود را بشناسید؛ تغییر حساب پیش‌فرض بدون هماهنگی می‌تواند اتصال برنامه را قطع کند.

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

در فایل تنظیم مؤثر، برای برنامه‌ای روی همان سرور از اتصال loopback و protected mode استفاده کنید:

bind 127.0.0.1
protected-mode yes

پس از اعمال تغییر و راه‌اندازی مجدد، با sudo ss -ltnp 'sport = :6379' نشانی شنونده را ببینید. راهنمای امنیت Redis دسترسی مستقیم کاربران نامطمئن به درگاه Redis را مناسب نمی‌داند. وجود رمز جای محدودیت شبکه را نمی‌گیرد.

ایمن‌سازی Redis با محدود کردن شبکه و مجوز کاربران

ACL به‌جای تغییر نام دستورها

روش rename-command منسوخ شده است. برای محدود کردن عملیات، از حساب‌های ACL استفاده کنید. یک حساب برنامه نباید صرفاً برای کار با کش، مجوز تغییر تنظیمات یا پاک‌کردن همهٔ دیتابیس‌ها را داشته باشد.

برای این نمونهٔ تازه، کاربران را مستقیماً در redis.conf تعریف می‌کنیم. اگر تنظیم aclfile فعال است، این دو روش را ترکیب نکنید؛ همان فایل ACL موجود را طبق ساختار سرویس مدیریت کنید. requirepass قدیمی و تعریف‌های قبلی کاربران نیز باید پیش از انتخاب روش بررسی شوند.

تعریف حساب مدیر و حساب محدود

دو رمز یکتای تصادفی تولید و محرمانه نگهداری کنید. مقدارهای جایگزین زیر رمز واقعی نیستند. خطوط زیر داخل فایل تنظیم هستند، نه دستور shell:

user default off
user hn-admin on >REPLACE_ADMIN_SECRET ~* +@all
user app-cache on >REPLACE_APP_SECRET ~myapp:* -@all +ping +get +set +del +expire +ttl

حساب hn-admin فقط برای مدیریت است و نباید در تنظیمات برنامه قرار گیرد. حساب app-cache در این مثال فقط به چند دستور و کلیدهای با پیشوند myapp: دسترسی دارد. نیاز واقعی کلاینت، مانند انتخاب دیتابیس یا دستورهای دیگر، باید جدا بررسی شود؛ این فهرست نسخهٔ آماده برای همهٔ افزونه‌های وردپرس نیست.

فایل دارای رمز باید فقط برای مدیر و حساب سرویس قابل خواندن باشد. پیش از restart، روش دسترسی مدیر و تنظیم کلاینت جدید را آماده کنید. سپس sudo systemctl restart redis-server و وضعیت سرویس را بررسی کنید.

آزمون ورود و مرز دسترسی

اتصال بدون رمز نباید عملیات داده را انجام دهد. برای آزمون حساب برنامه، ورود تعاملی رمز را به نوشتن آن در آرگومان دستور ترجیح دهید:

redis-cli -h 127.0.0.1 --user app-cache --askpass

بعد از ورود اجرا کنید:

PING
SET myapp:install-check "ok" NX EX 300
GET myapp:install-check
GET outside:permission-check
QUIT

عملیات روی کلید تازهٔ مجاز باید موفق و GET آخر باید با NOPERM رد شود. نیازی به آزمایش دستور مخرب FLUSHALL نیست. اگر کلید نمونه از قبل موجود است، نام تازه انتخاب کنید. حساب مدیر را نیز جدا با –user hn-admin و –askpass آزمایش کنید تا مسیر نگهداری در دسترس باشد.

اتصال شبکه‌ای و نگهداری

اگر برنامه روی سرور دیگری است، نشانی خصوصی، محدودیت مبدأ و TLS معتبر را متناسب با کلاینت تنظیم کنید. AUTH به‌تنهایی دادهٔ شبکه را رمز نمی‌کند. باز کردن عمومی 6379 یا غیرفعال کردن protected mode راه‌حل عمومی خطا نیست.

بعد از restart دوباره آزمون حساب‌ها را انجام دهید تا ماندگاری تنظیم تأیید شود. رمز را در تصویر آموزشی، خروجی گزارش یا دستور CONFIG GET requirepass نمایش ندهید. اصلاحات امنیتی بسته، پایش اتصال‌های ناموفق و آزمون بازیابی نیز بخشی از نگهداری سرویس‌اند.

مطالعهٔ مرتبط

بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.

مطالب مرتبط

ارسال نظر

فهرست مطالب