اقدامات امنیتی توصیه‌شده برای محافظت از سرورهای شما

مقدمه

راه‌اندازی و اجرای اپلیکیشن‌های‌تان اغلب تمرکز اصلی هنگام ساخت زیرساخت است؛ اما شIPPING بدون امن‌سازی اول می‌تواند عواقب جدی داشته باشد. یک پیکربندی پایه امن، سطح حمله (Attack Surface) شما را از روز اول کاهش می‌دهد و از تعمیرهای واکنشی بعد از زنده شدن سرویس‌ها جلوگیری می‌کند.

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

نکات کلیدی

• کلیدهای SSH ریسک به‌خطرافتادن حساب را کاهش می‌دهند: از احراز هویت مبتنی بر کلید استفاده و دسترسی SSH با رمز عبور و root را غیرفعال کنید تا از حملات brute-force جلوگیری و ممیزی دسترسی بهبود یابد.
• فایروال‌ها به‌طور پیش‌فرض حداقل-افشا را الزامی می‌کنند: سیاست پیش‌فرض-رد (Default-Deny) را اعمال و فقط پورت‌های موردنیاز (مانند SSH و HTTPS) را صریحاً مجاز کنید تا سطح حمله عمومی کمینه شود.
• شبکه خصوصی دسترسی خارجی را محدود می‌کند: از VPC و VPN استفاده کنید تا ترافیک سرویس‌های داخلی از اینترنت عمومی دور بماند و اجزای بک‌اند از دسترسی مستقیم ایزوله شوند.
• ممیزی سرویس ریسک‌های پنهان را آشکار می‌کند: به‌طور منظم پورت‌های در حال شنود و سرویس‌های در حال اجرا را بازرسی کنید تا افشاهای غیرضروری و انحراف پیکربندی تشخیص شوند.
• وصله‌کردن خودکار آسیب‌پذیری‌های شناخته‌شده را سریع‌تر می‌بندد: به‌روزرسانی‌های امنیتی بدون نظارت را فعال کنید تا بازه بین افشای آسیب‌پذیری و رفعش کوتاه شود.
• TLS و PKI داده در حال انتقال را محافظت می‌کنند: ترافیک خارجی و داخلی را رمزنگاری کنید تا از حملات شنود، دستکاری و جعل هویت جلوگیری شود.
• مانیتورینگ و هشدار، تشخیص زودهنگام تهدید را ممکن می‌کنند: لاگ‌های احراز هویت، ارتقای دسترسی و شنونده‌های شبکه جدید را ردیابی کنید تا رفتار مشکوک سریع شناسایی شود.
• بکاپ وضعیت بازیابی را تقویت می‌کند: بکاپ‌های خارج از سایت نگه دارید، اهداف RPO و RTO تعریف کنید و بازیابی‌ها را تست کنید تا از باج‌افزار، از دست رفتن داده یا به‌خطرافتادن سیستم بازیابی شوید.

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

کلیدهای SSH

SSH (شل امن) یک پروتکل رمزنگاری‌شده برای مدیریت و ارتباط با سرورهاست. کلیدهای SSH یک جفت‌کلید (خصوصی + عمومی) هستند که به‌جای رمز عبور برای احراز هویت استفاده می‌شوند: کلید خصوصی روی ماشین شما می‌ماند؛ کلید عمومی روی سرور قرار می‌گیرد. این رمزنگاری نامتقارن است و روش توصیه‌شده برای ورود به سرورهای لینوکسی است.

احراز هویت کلید SSH را با قرار دادن کلید عمومی‌تان در فایل ~/.ssh/authorized_keys سرور پیکربندی می‌کنید. برای نگاه عمیق‌تر به نحوه کار رمزنگاری و اتصالات SSH، راهنمای «درک فرایند رمزنگاری و اتصال SSH» را در پارمین کلود ببینید.

چرا کلید SSH به‌جای رمز عبور؟

SSH همه احراز هویت را—including رمزهای عبور—رمزنگاری می‌کند. مشکل ورودهای رمز عبور این است که می‌توان با حمله brute-force شکسته شوند: بات‌های خودکار می‌توانند رمزهای زیادی را در برابر یک IP عمومی امتحان کنند. محدود کردن نرخ (Rate Limiting) و قفل‌ها کمک می‌کنند اما ریسک را حذف نمی‌کنند. سوییچ به کلیدهای SSH به شما اجازه می‌دهد احراز هویت رمز عبور را کاملاً خاموش کنید. کلیدها آنتروپی (Entropy) بسیار بیشتری از رمزهای عبور معمولی دارند (مثلاً کلید ۱۲۸ کاراکتری در مقابل رمز کوتاه)؛ که شکستن با brute-force را غیرعملی می‌کند. کلیدهای Ed25519 درست تولیدشده (و کلیدهای RSA با اندازه مناسب) با قابلیت‌های عملی فعلی، از نظر محاسباتی غیرقابل شکستن‌اند.

نحوه پیاده‌سازی کلیدهای SSH

قبل از بستن نشست SSH فعلی‌تان، فرایند ورودتان را با راه‌اندازی احراز هویت کلید SSH امن کنید. روند کار ساده‌شده این است:

۱. روی ماشین محلی‌تان یک کلید SSH بسازید: ssh-keygen -t ed25519 -C "you@example.com" را اجرا و برای پذیرش پیش‌فرض‌ها Enter را بزنید. این جفت‌کلید SSH شما را می‌سازد: ~/.ssh/id_ed25519 (خصوصی) و ~/.ssh/id_ed25519.pub (عمومی).

۲. کلید عمومی‌تان را روی سرور آپلود کنید:
از ssh-copy-id user@your-server استفاده کنید (user و your-server را با نام کاربری و آدرس سرور واقعی‌تان جایگزین کنید). اگر ssh-copy-id در دسترس نیست، محتوای ~/.ssh/id_ed25519.pub را کپی و دستی به فایل ~/.ssh/authorized_keys روی سرورتان اضافه کنید.

۳. پیکربندی SSH روی سرور را امن‌سازی کنید: /etc/ssh/sshd_config را در ویرایشگر مورد علاقه‌تان باز کنید. PasswordAuthentication no را برای خاموش کردن ورودهای رمز عبور و PermitRootLogin no را برای بلاک کردن دسترسی مستقیم root تنظیم کنید. فایل را ذخیره و ببندید.

۴. سرویس SSH را برای اعمال تغییرات ری‌استارت کنید: روی دبیان/اوبونتو، ssh را ری‌استارت کنید. روی توزیع‌های خانواده RHEL (Rocky، AlmaLinux، CentOS)، sshd را ری‌استارت کنید. نشست فعلی‌تان را تا موفقیت گام ۵ باز نگه دارید تا از قفل شدن جلوگیری شود.

• دبیان/اوبونتو: sudo systemctl restart ssh
• خانواده RHEL: sudo systemctl restart sshd

۵. دسترسی جدید را در یک ترمینال جداگانه تست کنید (هنوز نشست اصلی‌تان را نبندید): سعی کنید با کلید خصوصی‌تان و کاربر خودتان به سرور SSH بزنید. اگر موفق بود، ورود به‌عنوان root را هم امتحان کنید (ssh root@your-server)؛ باید رد شوید. اگر احراز هویت کلید شکست خورد، مجوزها را چک کنید (~/.ssh باید 700 و authorized_keys باید 600 باشد) و قبل از قطع اتصال از نشست اصلی‌تان اصلاح کنید.

آیا برای دلایل قدیمی یا محیط‌های مشترک لازم است دسترسی رمز عبور را حفظ کنید؟ سرورتان را با fail2ban محافظت کنید تا ورودهای ناموفق مکرر بلاک شوند. به کاربران دسترسی sudo بدهید به‌جای اجازه root SSH تا اصل حداقل دسترسی را رعایت کنید. برای آموزش عملی، «راه‌اندازی کلیدهای SSH» در پارمین کلود را با جزئیات پوشش اوبونتو، دبیان و CentOS ببینید.

فایروال‌ها

فایروال (نرم‌افزاری یا سخت‌افزاری) کنترل می‌کند کدام سرویس‌ها افشا و چه ترافیکی اجازه ورود و خروج دارد. یک فایروال خوش‌پیکربندی تضمین می‌کند فقط سرویس‌های موردنظر از بیرون قابل دسترس باشند.

ترافیک به سرور شما عموماً در سه دسته جای می‌گیرد:

• عمومی: برای هر کسی روی اینترنت (مثلاً وب‌سرور شما).
• خصوصی: فقط برای کاربران یا مکان‌های مجاز (مثلاً پنل مدیریت دیتابیس مثل phpMyAdmin).
• داخلی: فقط از همان هاست (مثلاً دیتابیسی که فقط اتصالات محلی را می‌پذیرد).

فایروال‌ها این مرزها را الزامی می‌کنند: پورت‌های عمومی باز می‌مانند، پورت‌های خصوصی محدود (مثلاً با IP یا VPN) و داخلی‌ها افشا نمی‌شوند. پورت‌های بلااستفاده در یک راه‌اندازی منطقی، به‌طور پیش‌فرض بلاک‌اند.

فایروال‌ها چگونه امنیت را افزایش می‌دهند؟

حتی اگر سرویسی فقط به اینترفیس‌های خاصی bind شود، فایروال لایه جدایی اضافه می‌کند: ترافیک را قبل از رسیدن به اپلیکیشن رد یا مجاز می‌کند. این تأثیر پیکربندی اشتباه یا سرویس آسیب‌پذیر را کاهش می‌دهد. در عمل فقط پورت‌هایی را باز می‌کنید که نیاز دارید؛ معمولاً SSH (۲۲)، HTTP (۸۰) و HTTPS (۴۴۳)؛ که سطح حمله‌تان را کوچک می‌کند.

نحوه پیاده‌سازی فایروال‌ها

روی اوبونتو با UFW، توالی مینیمال (قبل از فعال کردن UFW اجازه SSH بدهید یا می‌توانید خودتان را قفل کنید):

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

پروفایل اپلیکیشن OpenSSH پورت درست SSH (پیش‌فرض ۲۲) را باز می‌کند و distro-aware است. اگر از پورت SSH سفارشی استفاده می‌کنید، قبل از فعال کردن UFW صریحاً اجازه‌اش بدهید (مثلاً sudo ufw allow 2222/tcp). باید پورت‌های مجاز و ردِ پیش‌فرضِ ورودی را ببینید. از ماشین دیگری تست کنید: پورتی که باز نکرده‌اید (مثلاً 3306) باید رد شود.

هر بار که سرویس اضافه یا حذف می‌کنید، قوانین فایروال را تغییر دهید. گزینه‌های رایج:

• UFW (فایروال بدون پیچیدگی): پیش‌فرض روی اوبونتو. برای راه‌اندازی، «راه‌اندازی فایروال با UFW روی اوبونتو» در پارمین کلود را ببینید. با اوبونتو 22.04 و 24.04 سازگار است.
• firewalld: پیش‌فرض روی Red Hat، Rocky و فدورا. «راه‌اندازی فایروال با firewalld» را ببینید.
• iptables: UFW و firewalld قوانین را به iptables می‌نویسند. برای کنترل مستقیم یا دیباگ، «اصول iptables: قوانین و دستورات رایج فایروال» را ببینید. داکر و ابزارهای مشابه هم قوانین iptables درج می‌کنند و می‌توانند از UFW عبور کنند؛ اگر از هر دو استفاده می‌کنید، یا یک فایروال ابری جلوی هاست بگذارید یا پورت‌های کانتینر را به IPهای خاص bind و آن‌ها را در UFW محدود کنید.

نکته: فایروال ابری در لبه شبکه، قبل از UFW هاست اعمال می‌شود و از قوانین iptables داکر تأثیر نمی‌گیرد. وقتی به قوانین سازگار بین هاست‌های اجراکننده کانتینر نیاز دارید از آن استفاده کنید.

بهترین روش: به‌طور پیش‌فرض ترافیک ناشناخته را رد کنید. سرویس‌های جدید تا وقتی صریحاً مجازشان نکنید غیرقابل دسترس می‌مانند؛ که شما را مجبور می‌کند تصمیم بگیرید هر سرویس چگونه باید دسترسی داشته باشد.

شبکه‌های VPC

ابر خصوصی مجازی (VPC) یک شبکه خصوصی برای منابع ارائه‌دهنده شماست. اینترفیس‌های VPC از اینترنت عمومی قابل دسترس نیستند؛ پس ترافیک بین منابع‌تان روی شبکه داخلی ارائه‌دهنده می‌ماند.

شبکه‌های VPC چگونه امنیت را افزایش می‌دهند؟

بسیاری از ارائه‌دهندگان به هر سرور یک اینترفیس عمومی و خصوصی می‌دهند. اگر روی نودهای بک‌اند اینترفیس عمومی را غیرفعال یا بلااستفاده کنید، فقط روی شبکه خصوصی صحبت می‌کنند. ترافیک بین آن سیستم‌ها هرگز از اینترنت عمومی عبور نمی‌کند؛ که افشا و ریسک شنود را کاهش می‌دهد. سپس فقط مجموعه کوچکی از نقاط ورود (مثلاً لود بالانسرها یا دروازه‌ها) را به اینترنت افشا می‌کنید؛ که کنترل و دید شفاف‌تری می‌دهد. کوبرنتیز و پلتفرم‌های مشابه این را با کنترلرهای Ingress و شبکه‌های پاد خصوصی رسمیت می‌بخشند.

نحوه پیاده‌سازی شبکه‌های VPC

بیشتر ارائه‌دهندگان ابری اجازه می‌دهند VPC بسازید و منابع را به آن متصل کنید. زیرشبکه‌ها و دروازه‌های‌تان را هنگام provision طراحی کنید؛ جابه‌جایی سرورهای موجود به VPC جدید می‌تواند نیازمند تغییرات IP یا مسیریابی باشد. روی پارمین کلود می‌توانید از راهنمای «پیکربندی سرور به‌عنوان دروازه VPC روی دبیان، اوبونتو و سرورهای مبتنی بر CentOS» استفاده کنید.

برای بارهای کاری ابری تک-منطقه‌ای، اول VPC ارائه‌دهنده را استفاده کنید؛ فقط وقتی به رمزنگاری بین مناطق، بین ابرها یا برای کاربران ریموت نیاز دارید، VPN اضافه کنید.

VPNها و شبکه خصوصی

VPN (شبکه خصوصی مجازی) تونل‌های رمزنگاری‌شده بین ماشین‌ها می‌سازد و آن‌ها را به‌عنوان یک شبکه منطقی منفرد ارائه می‌دهد؛ می‌توانید سرویس‌ها را طوری اجرا کنید که انگار روی یک LAN خصوصی‌اند؛ در حالی که ترافیک به‌شکل امن روی اینترنت حمل می‌شود.

شبکه‌های خصوصی ارائه‌دهنده (مثلاً شبکه خصوصی پارمین کلود) امکان ارتباط ایزوله بین سرورها در همان حساب یا تیم در یک منطقه را—بدون نرم‌افزار VPN—فراهم می‌کنند. VPN رمزنگاری اضافه می‌کند و بین شبکه‌ها و ارائه‌دهندگان کار می‌کند.

VPNها چگونه امنیت را افزایش می‌دهند؟

VPN یک شبکه Overlay خصوصی تعریف می‌کند که فقط Peerهای پیکربندی‌شده شما می‌توانند استفاده کنند. سپس ترافیک اپلیکیشن را روی اینترفیس VPN مسیریابی می‌کنید تا فقط سرویس‌هایی که برای اینترنت عمومی در نظر گرفته شده‌اند، روی اینترفیس عمومی گوش بدهند. این ترافیک دیتابیس، مدیریت و APIهای داخلی را از اینترنت باز دور نگه می‌دارد.

نحوه پیاده‌سازی VPNها

شبکه‌های خصوصی معمولاً نیازمند انتخاب اینترفیس‌ها و مسیریابی در زمان دیپلویند. VPNها نیازمند نصب و پیکربندی نرم‌افزار VPN روی هر هاست و سپس اشاره‌کردن اپلیکیشن‌ها به اینترفیس VPN هستند. وقتی تونل بالا آمد، هر سرور باید کلیدها و کانفیگ درست برای پیوستن به VPN را داشته باشد.

• OpenVPN: «راه‌اندازی و پیکربندی سرور OpenVPN روی اوبونتو» در پارمین کلود (سازگار با اوبونتو 22.04 و 24.04).
• WireGuard: مدرن، با کانفیگ مینیمال: «راه‌اندازی WireGuard روی اوبونتو» در پارمین کلود.

وقتی همه سرورها در یک ابر و منطقه‌اند از شبکه خصوصی ارائه‌دهنده استفاده کنید؛ وقتی به لینک‌های رمزنگاری‌شده بین مناطق، بین ابرها یا برای کاربران ریموت نیاز دارید VPN اضافه کنید.

ممیزی سرویس‌ها

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

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

ممیزی سرویس چگونه امنیت را افزایش می‌دهد؟

نمی‌توانید چیزی را که نمی‌شناسید امن‌سازی کنید. وقتی فهرست شنونده‌ها را دارید، می‌توانید سرویس‌های غیرضروری را خاموش، بقیه را فقط به localhost یا IP خصوصی bind و قوانین فایروال را با استفاده واقعی هم‌راستا کنید. وقتی نرم‌افزار جدید نصب یا نقش‌ها را تغییر می‌دهید، ممیزی‌ها را دوباره اجرا کنید؛ ممیزی‌های دوره‌ای انحراف پیکربندی را می‌گیرند.

نحوه پیاده‌سازی ممیزی سرویس

از ss برای فهرست شنونده‌های TCP و UDP با پروسه و PID استفاده کنید:

sudo ss -plunt

• p: پروسه استفاده‌کننده از سوکت
• l: فقط شنونده‌ها
• u: UDP
• n: آدرس‌ها/پورت‌های عددی
• t: TCP

خروجی نمونه:

Netid  State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
tcp    LISTEN  0       128     0.0.0.0:22          0.0.0.0:*          users:(("sshd",pid=812,fd=3))
tcp    LISTEN  0       511     0.0.0.0:80          0.0.0.0:*          users:(("nginx",pid=69226,fd=6),("nginx",pid=69225,fd=6))
tcp    LISTEN  0       128     [::]:22             [::]:*            users:(("sshd",pid=812,fd=4))
tcp    LISTEN  0       511     [::]:80             [::]:*            users:(("nginx",pid=69226,fd=7),("nginx",pid=69225,fd=7))

روی Netid، Local Address:Port و Process تمرکز کنید. 0.0.0.0 یعنی «همه اینترفیس‌های IPv4»؛ [::] یعنی «همه IPv6». در مثال، SSH و Nginx روی همه اینترفیس‌ها گوش می‌دهند؛ برای یک هاست وب/SSH قابل قبول؛ اما برای دیتابیس چیزی مثل 127.0.0.1:3306 یا فقط IP خصوصی می‌خواهید. سرویس‌هایی که نیازی به دسترسی شبکه‌ای ندارند را غیرفعال یا محدود کنید.

مانیتورینگ، لاگینگ و هشدار

لاگینگ و هشدار به شما اجازه می‌دهند سوءاستفاده و انحراف پیکربندی را قبل از تبدیل شدن به حادثه تشخیص دهید. بدون آن‌ها، به‌خطرافتادن یا پیکربندی اشتباه می‌تواند تا وقتی آسیب وارد شده، unnoticed بماند.

چه چیزهایی را لاگ کنید و کجا:

• احراز هویت: فعالیت SSH و sudo. روی لینوکس، رویدادهای auth معمولاً به auth.log می‌روند (دبیان/اوبونتو: /var/log/auth.log) یا secure (RHEL: /var/log/secure). ورودهای ناموفق، موفق و ارتقای دسترسی اینجا ظاهر می‌شوند.
• ارتقای دسترسی: استفاده sudo را ردیابی کنید. لاگ‌ها را متمرکز کنید تا بتوانید ممیزی کنید چه کسی چه زمانی چه چیزی را اجرا کرده.
• پورت‌های شنونده: ss -plunt را (یا معادلش) به‌صورت دوره‌ای اجرا و با خط پایه diff کنید؛ شنونده‌های جدید می‌توانند نشانه سرویس جدید یا بک‌دور باشند.

چه چیزهایی را هشدار بدهید:

• جهش در تلاش‌های ناموفق SSH (brute-force یا credential stuffing).
• شنونده‌های TCP/UDP جدید که در خط پایه‌تان نبودند (مثلاً پروسه جدیدِ bindشده به 0.0.0.0).
• استفاده sudo غیرمعمول (کاربران اول‌بار، دستورات حساس یا خارج از ساعت کاری).

مثال: tail لاگ auth برای خطاهای اخیر SSH:

grep -Ei "failed|invalid" /var/log/auth.log | tail -20

روی سیستم‌های خانواده RHEL، /var/log/auth.log را با /var/log/secure جایگزین کنید.

خط پایه‌ای از شنونده‌های مورد انتظار تعریف و هنگام تغییر هشدار بدهید. برای پروداکشن با تشخیص نفوذ (مثلاً fail2ban، OSSEC) یا SIEM ترکیب کنید.

به‌روزرسانی‌های بدون نظارت

به‌روزرسانی‌های امنیتی خودکار را فعال کنید تا وصله‌های حیاتی به‌زودی بعد از انتشار اعمال شوند. ارتقاهای بدون نظارت، بازه بین افشای آسیب‌پذیری و رفعش را کوتاه و بار عملیاتی وصله‌کردن دستی را کاهش می‌دهند.

به‌روزرسانی‌های بدون نظارت چگونه امنیت را افزایش می‌دهند؟

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

نحوه پیاده‌سازی به‌روزرسانی‌های بدون نظارت

روی اوبونتو، unattended-upgrades را نصب و فعال کنید. کانفیگ اصلی در /etc/apt/apt.conf.d/50unattended-upgrades است: مطمئن شوید منبع امنیتی مجاز است (مثلاً Unattended-Upgrade::Allowed-Origins شامل "${distro_id}:${distro_codename}-security" باشد). بعد از به‌روزرسانی‌های کرنل یا کتابخانه‌های حیاتی، ریبوت یا ری‌استارت سرویس‌ها کنید؛ برای پروداکشن، بسیاری از تیم‌ها از پنجره‌های نگهداری یا رول‌اوت مرحله‌ای استفاده می‌کنند. راه‌اندازی کامل: «نگه‌داشتن سرورهای اوبونتو به‌روز» در پارمین کلود.

نکته پروداکشن: ارتقاهای بدون نظارت را در استیجینگ تست کنید. برای سیستم‌های حیاتی، برخی تیم‌ها ترجیح می‌دهند وصله‌ها را مرحله‌ای کرده و در پنجره‌های تغییر اعمال کنند؛ نه ریبوت‌های کاملاً خودکار.

زیرساخت کلید عمومی و SSL/TLS

زیرساخت کلید عمومی (PKI) سیستم مراجع صدور گواهی (CA)، گواهی‌ها و اعتبارسنجی برای شناسایی طرف‌ها و رمزنگاری ارتباط است؛ گواهی‌های SSL/TLS سرورها را (و در صورت تمایل کلاینت‌ها را) احراز هویت و ترافیک در حال انتقال را رمزنگاری می‌کنند.

PKI چگونه امنیت را افزایش می‌دهد؟

گواهی‌های امضاشده توسط CA مورد اعتماد به جلوگیری از حملات مرد میانی (Man-in-the-Middle) کمک می‌کنند؛ جایی که مهاجم خودش را به‌جای سرور جا می‌زند. CAهای داخلی به شما اجازه می‌دهند فقط به زیرساخت خودتان اعتماد کنید. TLS محرمانگی و یکپارچگی ترافیک بین کلاینت‌ها و سرورها و بین سرویس‌ها را تضمین می‌کند.

نحوه پیاده‌سازی PKI

برای HTTPS عمومی، از Let’s Encrypt (مثلاً با certbot) یا ارائه TLS ارائه‌دهنده‌تان استفاده کنید. برای احراز هویت سرویس-به-سرویس داخلی، CA خصوصی و گواهی‌های داخلی‌امضا گزینه‌ای هستند. راه‌اندازی و نگهداری CA و چرخه حیات گواهی زحمت دارد؛ «راه‌اندازی و پیکربندی مرجع صدور گواهی (CA) برای لینوکس» در پارمین کلود را ببینید. تا وقتی به PKI کامل نیاز ندارید، امن‌سازی ترافیک با TLS (مثلاً از طریق ریورس‌پروکسی با گواهی‌ها) یا VPN اغلب کافی است.

بکاپ و بازیابی به‌عنوان کنترل امنیتی

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

استراتژی اسنپ‌شات و بکاپ:

• اسنپ‌شات‌ها یا بکاپ‌های ایمیج-محورِ منظم را با آهنگی متناسب با نرخ تغییرتان بگیرید. برای سرویس‌های Stateful، دامپ‌های فایل‌سیستم یا دیتابیس را با اسنپ‌شات‌ها ترکیب کنید تا بازیابی‌ها سازگار باشند.
• حداقل یک نسخه را خارج از سایت (منطقه یا ارائه‌دهنده متفاوت) ذخیره کنید. بکاپ‌های On-Prem در همان ساختمان پروداکشن، از فاجعه فیزیکی یا تصاحب سایت جان سالم به در نمی‌برند.
• بازیابی‌ها را دوره‌ای تست کنید. بکاپ‌هایی که هرگز بازیابی نشده‌اند اغلب هنگام نیاز شکست می‌خورند؛ RPO (هدف نقطه بازیابی) و RTO (هدف زمان بازیابی) را مستند و تأیید کنید که رویه‌های‌تان آن‌ها را برآورده می‌کنند.

RPO میزان از دست رفتن داده‌ای است که می‌پذیرید (مثلاً آخرین ۲۴ ساعت). RTO مدت‌زمانی است که می‌پذیرید پایین باشید. فرکانس و نگهداری بکاپ را با RPO هم‌راستا کنید و تمرین‌های بازیابی را برای برآوردن RTO اجرا نمایید. برای اطلاعات بیشتر «ساخت استراتژی بازیابی از فاجعه چندمنطقه‌ای» در پارمین کلود را ببینید.

چک‌لیست امنیت سرور

از این به‌عنوان عبور سریع هنگام آوردن سرور جدید به پروداکشن یا بازبینی سرور موجود استفاده کنید:

حوزه	اقدام
دسترسی	فقط کلید SSH؛ احراز هویت رمز عبور غیرفعال؛ ورود root غیرفعال؛ کاربر sudo تأییدشده
فایروال	پیش‌فرض رد؛ فقط پورت‌های موردنیاز باز (مثلاً ۲۲، ۸۰، ۴۴۳)؛ قوانین بازبینی‌شده
سرویس‌ها	ss -plunt بازبینی‌شده؛ سرویس‌های غیرضروری متوقف/غیرفعال؛ bindingها درست
به‌روزرسانی‌ها	به‌روزرسانی‌های امنیتی بدون نظارت فعال؛ فرایند ریبوت/نگهداری تعریف‌شده
اسرار	بدون اسرار در مخازن کانفیگ؛ متغیرهای محیطی یا مدیر راز؛ مجوزهای مینیمال
ابر	VPC/شبکه خصوصی در حد امکان استفاده‌شده؛ دسترسی سرویس متادیتا در صورت لزوم محدود
مانیتورینگ	لاگینگ و هشدارها در جای خود؛ خط پایه خوب-شناخته برای تشخیص انحراف

مخصوص ابر: روی instanceهای ابری، دسترسی به سرویس متادیتای instance ارائه‌دهنده ابر (مثلاً سرویس متادیتای سرور پارمین کلود) را در حد امکان محدود کنید تا تأثیر حملات SSRF یا بارهای کاری به‌خطرافتاده کاهش یابد. IAM یا دسترسی مبتنی بر نقش با حداقل دسترسی را اعمال کنید تا اعتبارنامه‌ها و مجوزها محدود باشند.

اشتباهات رایج امنیت سرور

این پیکربندی‌های اشتباه زیاد در ممیزی‌ها و بازبینی‌های پس از حادثه دیده می‌شوند. از آن‌ها اجتناب کنید.

• دیتابیس یا سرویس داخلی به 0.0.0.0 bind شده: MySQL، PostgreSQL، Redis یا UIهای مدیریتی که روی همه اینترفیس‌ها گوش می‌دهند، به اینترنت افشا می‌شوند. به 127.0.0.1 یا IP خصوصی bind و با فایروال محدود کنید.
• احراز هویت رمز عبور برای SSH روشن مانده: brute-force را ممکن می‌کند. بعد از تأیید احراز هویت کلیدی از یک نشست دوم، غیرفعالش کنید.
• SSH روت مجاز: نقطه شکست منفرد؛ بدون رد ممیزی به ازای هر کاربر. از کاربر دارای sudo استفاده و PermitRootLogin no تنظیم کنید.
• فایروال قبل از اجازه SSH فعال شده: مدیران با اجرای ufw enable قبل از ufw allow OpenSSH خودشان را قفل می‌کنند. همیشه اول SSH را مجاز کنید.
• بدون هشدار روی auth یا تغییر پورت: به‌خطرافتادن یا پیکربندی اشتباه می‌تواند unnoticed بماند. حداقل روی جهش‌های SSH ناموفق و پورت‌های شنونده جدید هشدار بدهید.
• سرویس متادیتای instance کاملاً باز: روی VMهای ابری، endpoint متادیتا می‌تواند اعتبارنامه‌ها را لو بدهد. برای بارهای کاری که نیازی ندارند محدود یا غیرفعالش کنید (مثلاً از IMDSv2 استفاده یا متادیتا را برای نودهای worker بلاک کنید).
• اسرار در فایل‌های محیطی یا مخازن کانفیگ: فایل‌های env کامیت‌شده به git یا روی دیسک رهاشده، نشت رایجی هستند. از مدیر راز یا ذخیره‌سازی رمزنگاری‌شده استفاده و دسترسی خواندن را محدود کنید.
• Egress بدون محدودیت: سرورهایی که می‌توانند به همه‌جا برسند، افشای داده و C2 را آسان می‌کنند. ترافیک خروجی را در حد امکان محدود کنید (مثلاً فقط APIها و میرورهای به‌روزرسانی موردنیاز را مجاز کنید).
• ارتقاهای بدون نظارت پیکربندی یا تست نشده: به‌روزرسانی‌های امنیتی انباشته می‌شوند؛ یک وصله به‌تأخیرافتاده می‌تواند برای به‌خطرافتادن کافی باشد. به‌روزرسانی‌های امنیتی بدون نظارت را فعال و در استیجینگ تست کنید.
• بکاپ‌های تست‌نشده: بکاپ‌هایی که هرگز بازیابی نشده‌اند اغلب شکست می‌خورند. تست‌های بازیابی را زمان‌بندی و RPO/RTO را مستند کنید.

عیب‌یابی مشکلات رایج

• بعد از غیرفعال کردن احراز هویت رمز عبور یا root قفل شدید: علت معمول، بستن نشست اول قبل از تأیید ورود کلیدی از ترمینال دوم است. همیشه قبل از قطع اتصال، ورود کلید و sudo را از نشست دوم تست کنید. اگر قفل شدید، از کنسول ارائه‌دهنده (مثلاً کنسول سرور پارمین کلود) یا حالت بازیابی برای اصلاح /etc/ssh/sshd_config یا بازیابی ~/.ssh/authorized_keys استفاده کنید. مدیران اغلب فراموش می‌کنند قبل از غیرفعال کردن root، تأیید کنند که کاربر sudo می‌تواند وارد شود.
• فایروال SSH شما را بلاک می‌کند: قبل از فعال کردن UFW اجازه SSH بدهید یا خودتان را قفل می‌کنید. sudo ufw allow OpenSSH را اجرا (یا sudo ufw allow 22 اگر پورت سفارشی دارید)، سپس sudo ufw enable. اگر از محدودیت مبدأ استفاده می‌کنید، تأیید کنید از IP مجاز تست می‌کنید.
• داکر و UFW: داکر قوانین iptables درج می‌کند که می‌توانند از UFW عبور کنند. با لایه‌گذاری فایروال ابری جلوی هاست (قوانین قبل از داکر اعمال می‌شوند) یا bind کردن پورت‌های کانتینر به IPهای خاص و محدود کردن آن‌ها در UFW مهارش کنید. مستندات داکر درباره iptables را ببینید.
• ارتقاهای بدون نظارت و ریبوت‌ها: اگر سرور حین کار حیاتی ریبوت می‌شود، Unattended-Upgrade::Automatic-Reboot و زمان‌بندی را در /etc/apt/apt.conf.d/50unattended-upgrades (اوبونتو) تنظیم یا از پنجره نگهداری استفاده کنید.
• سرویسی ناخواسته روی 0.0.0.0 گوش می‌دهد: از ss -plunt برای پیدا کردن پروسه استفاده کنید؛ سپس کانفیگ سرویس را به bind به 127.0.0.1 یا IP خاص تغییر و ری‌استارت کنید. با فایروال به‌عنوان لایه دوم محدودش کنید.

سوالات متداول

مهم‌ترین اقدامات امنیتی سرور کدام‌اند؟

اولویت‌بندی کنید: (۱) کلیدهای SSH و بدون SSH روت، (۲) فایروال پیش‌فرض-رد با فقط پورت‌های موردنیاز باز، (۳) وصله‌کردن منظم (مثلاً به‌روزرسانی‌های امنیتی بدون نظارت)، (۴) دانستن اینکه چه چیزی در حال شنود است (ممیزی سرویس) و (۵) TLS برای ترافیک عمومی و حساس. سپس با رشد محیط‌تان VPC/VPN و PKI اضافه کنید.

مهاجمان معمولاً چطور سرورها را به خطر می‌اندازند؟

مسیرهای رایج شامل آسیب‌پذیری‌های وصله‌نشده، اعتبارنامه‌های ضعیف یا لو‌رفته، سرویس‌های پیکربندی‌اشتباه یا بیش‌ازحد افشاشده (مثلاً پورت‌های دیتابیس باز) و مسائل فیشینگ یا زنجیره تأمین‌کالا هستند. امن‌سازی (فایروال، کلیدهای SSH، وصله‌کردن، حداقل دسترسی) بسیاری از این‌ها را رفع می‌کند.

سرورها هر چند وقت باید وصله شوند؟

حداقل به‌محض موجود شدن به‌روزرسانی‌های امنیتی برای سیستم‌عامل و پکیج‌های حیاتی. به‌روزرسانی‌های امنیتی بدون نظارت در بسیاری از راه‌اندازی‌ها این کار را روزانه انجام می‌دهند؛ برای سیستم‌های حیاتی از رول‌اوت مرحله‌ای و پنجره‌های تغییر استفاده کنید. مسائل با شدت بالا می‌توانند وصله‌های خارج از برنامه داشته باشند.

آیا سرورهای ابری از On-Prem امن‌ترند؟

می‌توانند باشند؛ چون ارائه‌دهندگان امنیت فیزیکی، هایپروایزر و اغلب امن‌سازی پایه را مدیریت می‌کنند. همچنان باید سیستم‌عامل، اپ‌ها، فایروال و دسترسی (SSH، IAM، اسرار) را امن کنید. ابر ملاحظاتی مثل سرویس متادیتا و سوءاستفاده IAM اضافه می‌کند؛ پس حداقل دسترسی را اعمال و در حد امکان دسترسی متادیتا را محدود کنید.

کدام پورت‌ها هرگز نباید عمومی افشا شوند؟

پورت‌های دیتابیس (مثلاً MySQL 3306، PostgreSQL 5432، Redis 6379)، پنل‌های مدیریتی یا APIهای داخلی را به 0.0.0.0 افشا نکنید؛ مگر اینکه صریحاً برایش طراحی شده و محافظت‌شده باشند. آن‌ها را به localhost یا شبکه خصوصی محدود و از طریق تونل SSH، VPN یا Bastion به آن‌ها دسترسی پیدا کنید.

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

از ترکیبی استفاده کنید: لاگینگ OS و اپ (مثلاً syslog، لاگ‌های auth، لاگ‌های دسترسی)، تجمیع و هشدار متمرکز لاگ، تشخیص نفوذ (مثلاً fail2ban، OSSEC یا IDS ابری) و اسکن آسیب‌پذیری. تعریف کنید «طبیعی» چه شکلی است و روی ناهنجاری‌ها و الگوهای شناخته‌شده-بد هشدار بدهید.

نتیجه‌گیری

این اقدامات خط پایه قوی برای بیشتر سرورهای لینوکسی فراهم می‌کنند: کلیدهای SSH بدون ورود روت، فایروال پیش‌فرض-رد، شبکه خصوصی در جای مناسب، ممیزی منظم سرویس، مانیتورینگ و هشدار، به‌روزرسانی‌های امنیتی بدون نظارت، TLS برای ترافیک حساس و بکاپ‌های تست‌شده.

هر بار که سرویس جدید دیپلوی یا معماری را تغییر می‌دهید، این خط پایه را دوباره اعتبارسنجی کنید. ss -plunt را دوباره اجرا، قوانین فایروال را بازبینی، تأیید کنید به‌روزرسانی‌های بدون نظارت فعال‌اند و لاگ‌های احراز هویت را در برابر خط پایه معمولتان چک کنید. امنیت را بخشی از عملیات روتین بدانید؛ نه گام راه‌اندازی یک‌باره.