با دسترسی تأییدشده و یک مسیر بازیابی شروع کنید، سپس مدیریت فردی، کلیدهای SSH آزمایش‌شده، یک فایروال محدودکننده، نرم‌افزار نگهداری‌شده و پشتیبان‌های مستقل را پیکربندی کنید. تغییرات را تدریجی اعمال کنید و یک نشست جدید را پیش از بستن نشست قدیمی تأیید کنید.
یک نقطه شروع قابل اعتماد ایجاد کنید
پیش از تغییر ماشین، سیستم‌عامل مورد انتظار، روش دسترسی و مسیر بازیابی را تأیید کنید. هویت میزبان SSH را از طریق اطلاعات تأییدشده اپراتور بررسی کنید، نه اینکه یک کلید غیرمنتظره را بدون بررسی بپذیرید. اعتبارنامه‌های موقت را خصوصی نگه دارید و آن‌ها را از طریق فرآیند مورد نظر جایگزین کنید. ثبت کنید که کدام شخص مسئول نگهداری است و کدام گزینه‌های بازیابی واقعاً برای این سرویس در دسترس هستند.
هنگام ایجاد تغییرات دسترسی، یک نشست مدیریتی فعال را باز نگه دارید. یک دستور سخت‌سازی کپی‌شده می‌تواند تنها ورود قابل استفاده را حذف کند وقتی که توزیع یا چیدمان حساب متفاوتی را فرض می‌کند. هر بار یک تغییر انجام دهید، نتیجه مؤثر آن را بررسی کنید و یک مسیر بازگشت را حفظ کنید. هدف سیستمی است که می‌توانید با خیال راحت نگهداری کنید، نه پیکربندی‌ای که سختگیرانه به نظر می‌رسد اما قابل مدیریت نیست.
دسترسی به SSH را آگاهانه کنید
دسترسی مدیریتی فردی با امتیاز مناسب ایجاد کنید، نه اشتراک‌گذاری یک ورود ریشه دائمی. کلید عمومی مورد نظر را نصب و آزمایش کنید و کلید خصوصی را روی نقطه پایانی مجاز نگه دارید. مستندات OpenSSH Ubuntu پیکربندی سرور و گزینه‌های احراز هویت را توضیح می‌دهد. پیش از فرض اینکه ویرایش یک تنظیم کل سرویس را تغییر داده است، پیکربندی مؤثر توزیع خود را، شامل فایل‌های گنجانده‌شده، بخوانید.
دسترسی کلید را از طریق یک نشست دوم پیش از تغییر احراز هویت با رمز عبور یا قواعد ورود ممتاز آزمایش کنید. اطمینان حاصل کنید که حساب جدید می‌تواند مدیریت مورد نیاز خود را انجام دهد. هر خودکارسازی‌ای که به روش قبلی وابسته است را بررسی کنید و دسترسی آن را آگاهانه جایگزین کنید. یک کلید یک اعتبارنامه دسترسی است، بنابراین از یک محل ذخیره‌سازی خصوصی و یک فرآیند چرخش استفاده کنید، نه اینکه نسخه‌هایی را در پوشه‌های برنامه رها کنید.
برنامه را در معرض دید قرار دهید، نه کل ماشین را
سرویس‌های در حال شنود را فهرست کنید و مشخص کنید کدام‌یک باید عمومی باشد. یک برنامه وب ممکن است به HTTP و HTTPS نیاز داشته باشد، در حالی که پایگاه داده آن می‌تواند فقط از طریق مسیر داخلی مورد نظر قابل دسترسی باقی بماند. Ubuntu، UFW را به عنوان یک ابزار پیکربندی فایروال مستند می‌کند، اما سیاست مفید مستقل از ابزار است: ترافیک مورد نیاز را مجاز کنید و در جایی که عملی است، مدیریت را به منابع تأییدشده محدود کنید.
اگر سرویس شامل کنترل‌های سطح میزبان و سطح ارائه‌دهنده است، هر دو را بررسی کنید. پیش از فعال‌سازی یک مجموعه قواعد محدودکننده، مسیر مدیریتی آزمایش‌شده را مجاز کنید و دسترسی را از یک نشست دیگر تأیید کنید. فرض نکنید که انتقال SSH به یک پورت متفاوت جایگزین احراز هویت یا وصله‌گذاری می‌شود. قواعد فایروال را قابل فهم نگه دارید تا عیب‌یابی آینده منجر به باز کردن همه پورت‌ها به عنوان راه‌حل موقت نشود.
| تغییر | پیش از اعمال بررسی کنید | پس از اعمال بررسی کنید |
|---|---|---|
| کلید جدید SSH | حساب و کلید عمومی صحیح | نشست دوم احراز هویت‌شده با کلید کار می‌کند |
| فایروال محدودشده | مسیرهای سرویس و بازیابی مورد نیاز | برنامه عمومی کار می‌کند؛ پورت‌های ناخواسته بسته هستند |
| به‌روزرسانی نرم‌افزار | پیامدهای پشتیبان‌گیری و راه‌اندازی مجدد | سرویس‌ها راه‌اندازی مجدد می‌شوند و آزمون‌های برنامه قبول می‌شوند |
| تغییر مجوز سرویس | مسیرهای خواندن و نوشتن مورد نیاز | برنامه بدون دسترسی گسترده‌تر به سیستم کار می‌کند |
به‌روزرسانی‌ها را به عنوان یک فرآیند عملیاتی برنامه‌ریزی کنید
سیستم و وابستگی‌های برنامه را نگهداری‌شده نگه دارید. راهنمای به‌روزرسانی خودکار Ubuntu ارتقاهای بدون نظارت، مبدأهای مجاز و رفتار راه‌اندازی مجدد را توصیف می‌کند. یک مخزن شخص ثالث فقط به این دلیل که به ماشین اضافه شده است، به طور خودکار پوشش داده نمی‌شود. بررسی کنید که فرآیند به‌روزرسانی پیکربندی‌شده واقعاً چه چیزی را شامل می‌شود و به برنامه‌های جداگانه نصب‌شده مسیر نگهداری خودشان را بدهید.
تصمیم بگیرید که راه‌اندازی مجدد سرویس‌ها و بوت مجدد چگونه مدیریت خواهند شد. اعمال یک به‌روزرسانی بسته همیشه به این معنا نیست که هر فرآیند در حال اجرا از کد جدید استفاده می‌کند. در جایی که بار کاری نیاز دارد از یک پنجره نگهداری استفاده کنید و پس از آن یک بررسی ساده برنامه انجام دهید. اگر یک بسته به گام‌های مهاجرت دستی نیاز دارد، آن‌ها را مستند کنید، نه اینکه همه به‌روزرسانی‌ها را به طور نامحدود غیرفعال کنید و مواجهه حاصل را فراموش کنید.
دسترسی برنامه را محدود کنید و بازیابی را محافظت کنید
سرویس‌ها را با مجوزهایی که نیاز دارند اجرا کنید و محتوای عمومی را از اسرار و فراداده استقرار جدا کنید. یک فرآیند وب نباید بتواند هر تنظیم سیستمی را بازنویسی کند. اسرار محیطی را خارج از پوشه‌های عمومی سرویس‌دهی نگه دارید و از گنجاندن آن‌ها در گزارش‌ها، خروجی‌های پشتیبانی یا پشتیبان‌های عمومی بدون یک سیاست حفاظتی آگاهانه خودداری کنید. بسته‌ها و سرویس‌های بی‌استفاده را وقتی هدف عملیاتی ندارند حذف کنید.
یک پشتیبان مستقل نگه دارید و بازیابی برنامه را در یک محیط جداگانه آزمایش کنید. اعتبارنامه‌های پشتیبان‌گیری را محدود کنید تا یک برنامه به خطر افتاده نتواند به طور خودکار هر نسخه بازیابی را حذف کند. ظرفیت دیسک، قدمت پشتیبان و خرابی‌های سرویس را پایش کنید. گزارش‌گیری باید به پرسش‌های عملیاتی تعریف‌شده پاسخ دهد، با دسترسی و نگهداری کنترل‌شده؛ نباید به یک کپی نامحدود از درخواست‌های حساس تبدیل شود.
یک توالی استقرار اولیه که قابل بازبینی باقی می‌ماند
برای یک VPS جدید، ابتدا دسترسی و بازیابی را تأیید کنید، سپس حساب مدیریتی و کلید آزمایش‌شده را ایجاد کنید. فایروال را پیکربندی کنید، به‌روزرسانی‌ها را اعمال کنید و برنامه را تحت حساب سرویس مورد نظر خود مستقر کنید. رفتار عمومی را از یک محیط دیگر تأیید کنید، بررسی کنید که فایل‌های خصوصی قابل بازیابی نیستند و یک بازیابی پشتیبان انجام دهید. یادداشت‌هایی درباره هر تصمیم و مسیر معکوس کردن یک تغییر دسترسی نگه دارید.
Vector VPS، Pulse NVMe و طرح‌های اختصاصی انتخاب‌شده، گزینه‌های Linux را در کاتالوگ SwissOctet ارائه می‌دهند. پیش از سفارش، تصویر انتخاب‌شده و تقسیم کار نگهداری را تأیید کنید. هیچ نام تصویر Linux ثابت نمی‌کند که سخت‌سازی، به‌روزرسانی‌ها یا پشتیبان‌ها قبلاً مدیریت می‌شوند. خط پایه مجموعه کنترل‌هایی است که شما پیکربندی، تأیید و با تغییر پروژه به نگهداری آن ادامه می‌دهید.
چک‌لیست عملی شما.
- هویت میزبان SSH و مسیر بازیابی را تأیید کنید.
- دسترسی کلید فردی را در یک نشست دوم آزمایش کنید.
- سرویس‌های در حال شنود و قواعد فایروال را محدود کنید.
- پوشش به‌روزرسانی و رفتار راه‌اندازی مجدد را بررسی کنید.
- اسرار را از فایل‌های عمومی و مجوزهای سرویس جدا کنید.
- یک نسخه بازیابی مستقل را آزمایش کنید.
جزئیاتی که اهمیت دارند.
آیا باید ورود با رمز عبور را فوراً غیرفعال کنم؟+
ابتدا دسترسی کلید جایگزین و مسیر بازیابی را ایجاد و آزمایش کنید. سپس احراز هویت را مطابق پیکربندی پشتیبانی‌شده خود تغییر دهید.
آیا تغییر پورت SSH جایگزین سخت‌سازی می‌شود؟+
خیر. جایگزین احراز هویت قوی، دسترسی محدود، به‌روزرسانی‌ها یا امتیاز حساب مناسب نمی‌شود.
آیا به‌روزرسانی‌های خودکار برای هر برنامه کافی است؟+
خیر. مخازن مجاز، الزامات راه‌اندازی مجدد و نرم‌افزار نصب‌شده خارج از فرآیند به‌روزرسانی سیستم را بررسی کنید.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- سرور Ubuntu: سرور OpenSSH ubuntu.com
- سرور Ubuntu: فایروال‌ها ubuntu.com
- سرور Ubuntu: به‌روزرسانی‌های خودکار ubuntu.com
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.