امنیت صفر اعتماد در سرورهای بره متال

چرا امنیت محیطی سنتی در زیرساخت های اختصاصی شکست می خورد؟

یک سرور اختصاصی معمولی پشت یک فایروال قرار می گیرد که به ترافیک از پورت های خاصی اجازه می دهد. هنگامی که ترافیک به سرور می رسد، سرویس های داخلی اغلب بدون احراز هویت اضافی با یکدیگر ارتباط برقرار می کنند. MySQL به 3306 گوش می دهد و اتصالات را از شبکه محلی می پذیرد. Redis برای هر فرآیندی که روی سرور اجرا می شود در دسترس است. کد برنامه با مجوزهای گسترده سیستم فایل اجرا می شود.

این کار تا زمانی که چیزی در داخل محیط به خطر بیفتد خوب عمل می کند. پوسته وب آپلود شده از طریق یک افزونه آسیب پذیر وردپرس اکنون می تواند مستقیماً به MySQL دسترسی داشته باشد. یک فرآیند برنامه به خطر افتاده می تواند فایل های متعلق به برنامه های دیگر را بخواند. محیط برقرار است؛ داخلی نداشت.

Zero Trust با حذف کامل مفهوم “خودی قابل اعتماد” به این موضوع می پردازد. هر درخواست دسترسی – چه از یک کاربر خارجی یا یک سرویس داخلی – احراز هویت، مجاز و ثبت شده است.

کنترل دسترسی مبتنی بر هویت برای خدمات

اساس اعتماد صفر در سطح خدمات این است که اطمینان حاصل شود که خدمات برای یکدیگر، نه فقط برای کاربران خارجی، تأیید اعتبار می شوند.

دسترسی به پایگاه داده: MySQL نباید اتصالات از 127.0.0.1 را بدون مجوزهای محدود به حداقل مجوزهای لازم بپذیرد. به جای استفاده از روت، کاربران پایگاه داده خاص برنامه را ایجاد کنید:

– یک کاربر برای برنامه تنها با امتیازات لازم ایجاد کنید

ایجاد کاربر ‘appname’@’127.0.0.1’ شناسایی شده توسط ‘strong_random_password’;

GRANT SELECT, INSERT, UPDATE, DELETE ON appname_db.* TO ‘appname’@’127.0.0.1’;

امتیازات فلاشینگ؛

– امتیازات را بررسی کنید

نشان دادن کمک های مالی در ‘appname’@’127.0.0.1’;

برنامه وب به عنوان نام برنامه متصل می شود و فقط به appname_db دسترسی دارد. حتی اگر این گواهی فاش شود، شعاع انفجار به یک پایگاه داده محدود می شود.

دسترسی Redis: Redis به طور پیش فرض تمام اتصالات تایید نشده در لوکال هاست را می پذیرد. احراز هویت را در /etc/redis/redis.conf فعال کنید:

به شما_strong_redis_password نیاز دارید

اتصال 127.0.0.1

تنها با یک رمز عبور قوی و اتصال حلقه بک، اتصالات Redis به نزدیکی شبکه و اعتبارنامه مناسب نیاز دارند.

تقسیم بندی شبکه با فضاهای نام و VLAN

برای محیط‌هایی با چندین برنامه در یک سرور اختصاصی، فضاهای نام شبکه لینوکس بدون نیاز به سخت‌افزار جداگانه، جداسازی شبکه در سطح برنامه را ارائه می‌کنند:

# Create an isolated network namespace for an application

ip netns add appname_ns

# Create a veth pair (virtual ethernet cable)

ip link add veth0 type veth peer name veth1

# Move one end into the namespace

ip link set veth1 netns appname_ns

# Configure addressing

ip addr add 192.168.100.1/30 dev veth0

ip netns exec appname_ns ip addr add 192.168.100.2/30 dev veth1

# Bring interfaces up

ip link set veth0 up

ip netns exec appname_ns ip link set veth1 up

فرآیندهایی که در فضای نام اجرا می شوند فقط می توانند به آدرس های شبکه که به صراحت برای آنها پیکربندی شده است دسترسی پیدا کنند. آنها نمی توانند مستقیماً به پایگاه های داده یا خدمات متصل به شبکه میزبان بدون عبور از یک دروازه کنترل شده دسترسی داشته باشند.

برای ایزوله سازی چند مستاجر ساده تر، قوانین nftables می توانند سیاست های ارتباطی بین برنامه های کاربردی را در همان سرور اعمال کنند:

# Only allow MySQL connections from the application's specific process user (via UID match)

nft add rule inet filter output skuid 1001 tcp dport 3306 accept

nft add rule inet filter output tcp dport 3306 drop

این فقط به فرآیندهایی که به عنوان UID 1001 (کاربر برنامه) در حال اجرا هستند اجازه می دهد تا به MySQL متصل شوند – همه فرآیندهای دیگر در سطح هسته مسدود می شوند.

تقسیم بندی میکرو برای ترافیک درون سرور

AppArmor (اوبونتو/دبیان) و SELinux (RHEL/AlmaLinux/Rocky Linux) کنترل دسترسی اجباری را در سطح هسته ارائه می‌کند، و محدودیت‌هایی را که یک فرآیند می‌تواند به فایل‌ها، منابع شبکه و فراخوانی‌های سیستم دسترسی داشته باشد، بدون توجه به مجوزهای یونیکس، می‌دهد.

یک نمایه AppArmor برای Nginx که آن را فقط به منابع مورد نیازش محدود می کند:

/etc/apparmor.d/usr.sbin.nginx:

#include 

/usr/sbin/nginx {

  #include 

  #include 

  capability net_bind_service,

  capability setuid,

  capability setgid,

  /var/www/** r,

  /etc/nginx/** r,

  /var/log/nginx/** w,

  /run/nginx.pid rw,

  # Deny everything else

  deny /home/** rwx,

  deny /root/** rwx,

  deny /etc/shadow r,

}

با اعمال این نمایه، حتی اگر یک مهاجم به اجرای کد در فرآیند Nginx دست یابد، نمی‌تواند /etc/shadow را بخواند، به فهرست‌های اصلی کاربر دسترسی داشته باشد یا خارج از /var/log/nginx/ بنویسد. هسته این محدودیت ها را بدون توجه به آنچه کد مهاجم امتحان می کند، اعمال می کند.

اسناد AppArmor حالت های توسعه و پیاده سازی پروفایل ها را پوشش می دهد. در حالت شکایت (نقض ورود بدون ممنوعیت) شروع کنید تا نمایه خود را قبل از اقدام به اجرا تأیید کنید.

دسترسی بدون اعتماد برای دسترسی اداری

اعمال اعتماد صفر به دسترسی SSH به معنای جایگزینی اعتبارنامه های ایستا با گواهی های کوتاه مدت و تأیید شده هویت است.

مرجع صدور گواهی HashiCorp Vault SSH گواهینامه های SSH را صادر می کند که پس از مدت زمان قابل تنظیم – 30 دقیقه، 1 ساعت، 8 ساعت منقضی می شود. یک مهندس با اعتبار خود در Vault احراز هویت می کند، یک گواهی SSH کوتاه مدت دریافت می کند و از آن برای اتصال به سرور استفاده می کند. اگر گواهی به سرقت رفته باشد، به زودی منقضی می شود. اگر یک مهندس سازمان را ترک کند، لغو دسترسی Vault آنها فوراً به توانایی آنها برای دریافت گواهینامه های جدید پایان می دهد.

مستندات Vault SSH Secrets Engine راه‌اندازی تأیید سمت سرور و صدور گواهی مشتری را پوشش می‌دهد.

برای تیم هایی که آماده استقرار Vault نیستند، اعتماد صفر به SSH یک ارتقا ساده تر است لیست آدرس IP مجاز ترکیب شده با چرخش گواهینامه ها:

# In /etc/ssh/sshd_config

# Match only connections from corporate VPN or jump host IP

Match Address 10.0.0.0/8

  PasswordAuthentication no

  PubkeyAuthentication yes

Match Address *

  DenyUsers *

ثبت نام و بررسی مستمر

اعتماد صفر بدون ورود به سیستم فقط امید است. هر راه حل دسترسی به یک مسیر حسابرسی نیاز دارد. برای سرور اختصاصی:

ورود به سیستم دسترسی SSH: گزارش های sshd را در /var/log/auth.log (Debian) یا /var/log/secure (RHEL) تأیید کنید. هر تلاش برای ورود، موفق یا ناموفق، با IP منبع و نام کاربری.

ثبت حسابرسی در سطح برنامه: مطمئن شوید که برنامه شما اقدامات تأیید شده کاربر را ثبت می کند، نه فقط درخواست ها. هویت انجام دهنده هر عملیات را یادداشت کنید، نه اینکه آن عمل فقط انجام شده باشد.

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

بررسی دسترسی دوره ای: بررسی ماهانه همه کلیدهای SSH فعال در /root/.ssh/authorized_keys و ~/.ssh/authorized_keys هر کاربر. کلیدهای متعلق به کارمندان سابق، پیمانکاران سابق یا سیستم هایی که دیگر نیازی به دسترسی ندارند را بردارید.

Zero Trust یک فرآیند مداوم است، نه یک اجرا

سازمان‌هایی که دارای قوی‌ترین وضعیت امنیتی زیرساخت اختصاصی بودند، در آخر هفته اعتماد صفر را به کار نگرفتند. آنها با خطرناک ترین مسیرهای دسترسی – SSH، اتصالات پایگاه داده – شروع کردند و ابتدا تأیید هویت و ورود به سیستم را اضافه کردند. سپس آنها به سمت داخل حرکت کردند و ارتباط بین سرویس و کنترل دسترسی در سطح فرآیند را سخت تر کردند.

خدمات مدیریت شده InMotion’s Premier Care شامل پیکربندی امنیتی اولیه مناسب برای سرور اختصاصی تولیدی است. تیم‌هایی که تحت الزامات انطباق دقیق یا مدل‌های تهدید کار می‌کنند – خدمات مالی، مراقبت‌های بهداشتی، داده‌های تنظیم‌شده – معمولاً کنترل‌های بدون اعتماد اضافی را در بالای آن خط پایه قرار می‌دهند.

خواندن مرتبط: بهترین روش ها برای امنیت سرور | استراتژی های حفاظت از DDoS برای زیرساخت های اختصاصی