Sağlayıcınızdan bir bilgilendirme maili gelir: "Sunucunuzda barınan bir hesapta zararlı yazılım tespit edilmiştir, ilgili hesap askıya alınmıştır." Ya da daha sinsi bir biçimde fark edersiniz; sitenizde hiçbir şey değişmemişken müşterilere gönderdiğiniz sipariş onayları birdenbire geri dönmeye başlar ve geri dönen mesajın içinde tanımadığınız bir kara liste adı vardır. Kodunuza dokunmadınız, eklenti güncellemediniz, parolanızı kimseye vermediniz. Yine de bir şey oldu.
Bu noktada sorulan soru genellikle şudur: "Paylaşımlı hosting güvenli mi?" Bu soru cevaplanamaz, çünkü fazla geniştir ve satış konuşmasıyla da korku pazarlamasıyla da aynı kolaylıkla cevaplanabilir. Doğru soru şu: aynı fiziksel sunucuda benimle birlikte duran bir hesap ele geçirildiğinde, bu bana hangi somut yollardan ulaşabilir ve bu yolların kaçını sağlayıcımın izolasyon katmanı gerçekten kapatıyor?
Bu yazı tam olarak o soruyu cevaplıyor. Önce "etkilenmek" kelimesini dört farklı senaryoya ayırıyoruz, çünkü bunların bazıları modern bir sunucuda pratikte imkânsızken bazıları izolasyondan tamamen bağımsız olarak sizi vurur. Sonra her yol için kendi hesabınızda çalıştırabileceğiniz doğrulama komutlarını, kendi tarafınızda alabileceğiniz gerçek önlemleri ve hangi eşikten sonra sanal sunucuya geçmenin gerçek bir güvenlik kazancı sağladığını ele alıyoruz.
Soruyu Doğru Kurmak: Etkilenmek Tam Olarak Ne Demek#
"Komşum hacklendi, ben de hacklendim mi" cümlesinde iç içe geçmiş dört ayrı iddia vardır ve bunların riski birbirinden çok farklıdır.
Birincisi doğrudan bulaşma: saldırganın komşu hesaptan sizin dosyalarınıza geçmesi, kodunuza zararlı ekleme yapması veya veritabanınızı okuması. Bu, korkulan senaryodur ve modern bir yapılandırmada en zor olanıdır.
İkincisi itibar bulaşması: dosyalarınıza kimse dokunmaz ama paylaştığınız IP adresi kirlenir, e-postalarınız gitmez, bazı ağlar sunucuyu engeller. Burada teknik bir ihlal yaşamazsınız, sonuçlarını yaşarsınız.
Üçüncüsü kaynak bulaşması: ele geçirilen hesap madencilik yazılımı çalıştırır ya da spam kuyruğu üretir, sunucunun CPU ve disk kapasitesini tüketir, siteniz yavaşlar veya hata verir.
Dördüncüsü idari bulaşma: tek bir şikâyet üzerine sağlayıcı veya üst ağ, hesap bazında değil sunucu veya IP bazında bir önlem alır; siz o önlemin kapsamına dahil olursunuz.
Bu dördünü ayırmadan yapılan her tartışma yanlış yere varır. İzolasyon teknolojileri birinci ve üçüncü maddeye karşı çok etkilidir; ikinci ve dördüncü maddeye karşı ise neredeyse hiçbir şey yapmaz. Aşağıda her birini ayrı ayrı açıyoruz.
Bulaşma Yolu 1: Symlink ile Komşunun wp-config.php Dosyasını Okumak#
Klasik paylaşımlı hosting saldırısının adımları şudur. Saldırgan önce zayıf bir hesabı ele geçirir; genellikle güncellenmemiş bir eklenti üzerinden dosya yükleyip bir web shell çalıştırır. Artık o hesabın kullanıcısı olarak komut çalıştırabilmektedir. Amacı sizin sitenizi bozmak değildir; amacı sunucudaki diğer hesapların veritabanı parolalarını toplamaktır.
Bunun için doğrudan dosya okumaya çalışmaz, çünkü dosya izinleri buna izin vermez. Bunun yerine kendi dizininde, sizin yapılandırma dosyanızı işaret eden bir sembolik bağ oluşturur ve o bağı web sunucusu üzerinden okumaya çalışır:
# Saldırganın kendi hesabında yaptığı şey — aynısını kendi hesabınızda test edebilirsiniz
cd ~/public_html
ln -s /home/baskahesap/public_html/wp-config.php gizli.txt
curl -s https://kendi-siteniz.com/gizli.txt | head -5
rm gizli.txt
Buradaki püf nokta şudur: dosyayı okuyan saldırganın kullanıcısı değil, web sunucusu sürecidir. İzolasyonsuz eski kurulumlarda Apache tek bir nobody kullanıcısı olarak çalışır ve sunucudaki her hesabın dosyasını okuyabilir; sembolik bağ, saldırganın kendi yetkisiz kullanıcısı yerine web sunucusunun geniş yetkisini kullanmasının yoludur. wp-config.php ele geçtiğinde saldırgan veritabanı kullanıcı adı ve parolasına sahiptir; MySQL uzaktan erişime kapalı olsa bile aynı sunucudan localhost üzerinden bağlanabilir ve sizin veritabanınızı okuyup değiştirebilir.
Modern sunucularda bu zincir üç ayrı noktadan kırılır. Birincisi hesap başına ayrı PHP kullanıcısıdır: PHP-FPM veya suEXEC ile her hesabın kodu kendi kullanıcısı olarak çalışır, dolayısıyla web sunucusunun geniş yetkisi diye bir şey kalmaz. İkincisi dosya sistemi izolasyonudur; kafeslenmiş bir hesap /home/ altındaki diğer dizinleri hiç göremediği için sembolik bağın hedefi bile oluşturulamaz. Bu katmanın nasıl çalıştığını CageFS ve hesap izolasyonu yazısında ayrıntılı anlatıyoruz. Üçüncüsü ise Apache seviyesindeki sembolik bağ kısıtıdır.
Kendi hesabınızın hangi durumda olduğunu otuz saniyede görebilirsiniz:
# 1) Başka hesapların ev dizinlerini görebiliyor musunuz?
ls -1 /home/ | head
# 2) Sunucudaki tüm hesapları listeleyebiliyor musunuz?
wc -l < /etc/passwd
# 3) Başka kullanıcıların süreçlerini görebiliyor musunuz?
ps aux | awk 'NR>1 {print $1}' | sort -u
İzolasyonlu bir sunucuda birinci komut yalnızca kendi kullanıcınızı, ikincisi onlu sayılarda bir satır sayısı, üçüncüsü ise yalnızca kendi kullanıcınız ve birkaç sistem hesabını döndürür. Yüzlerce kullanıcı adı görüyorsanız bu sunucuda dosya sistemi izolasyonu yoktur ve sağlayıcınıza bunu sormanız gerekir.
PHP'nin hangi kimlikle çalıştığını da doğrudan test edin. Aşağıdaki dosyayı geçici olarak yükleyip tarayıcıdan açın, sonra mutlaka silin:
<?php
// gecici-kontrol.php — kontrolden hemen sonra silin
echo 'PHP kullanıcısı: ' . (function_exists('posix_geteuid')
? posix_getpwuid(posix_geteuid())['name']
: get_current_user()) . "\n";
echo "Okunabilen ev dizinleri:\n";
print_r(glob('/home/*'));
echo 'Oturum dizini: ' . ini_get('session.save_path') . "\n";
echo 'open_basedir: ' . (ini_get('open_basedir') ?: 'tanımsız') . "\n";
Çıktıda kendi kullanıcı adınız yerine nobody, apache ya da www-data görüyorsanız hesap başına ayrılmış bir PHP kullanıcısı yok demektir. open_basedir tanımsızsa ve oturum dizini paylaşılan /tmp ise, kendi tarafınızda hemen kapatabileceğiniz iki açık var demektir.
Kendi hesabınızda alabileceğiniz önlemler şunlar:
# ~/public_html/.htaccess
Options -Indexes +SymLinksIfOwnerMatch
# Yapılandırma dosyalarını doğrudan istekten koruyun
<FilesMatch "^(wp-config\.php|\.env|composer\.(json|lock))$">
Require all denied
</FilesMatch>
; cPanel > MultiPHP INI Editor > Editor Mode — yalnızca kendi hesabınızı etkiler
open_basedir = "/home/kullaniciadi/:/tmp/"
session.save_path = "/home/kullaniciadi/tmp"
disable_functions = exec,passthru,shell_exec,system,proc_open,popen
allow_url_fopen = Off
session.save_path satırı çoğu zaman atlanır ama önemlidir: varsayılan yapılandırmada PHP oturum dosyaları ortak /tmp dizinine yazılır ve izolasyonsuz bir sunucuda başka bir hesap bu dosyaları okuyup oturum kimliği çalabilir. Oturum dizinini kendi ev dizininize almak, tek satırlık ve bedelsiz bir kazançtır.
Bulaşma Yolu 2: Paylaşılan IP'nin Kara Listeye Düşmesi#
Bu, izolasyonun kesmediği yollardan birincisidir ve pratikte en sık yaşananıdır. Ele geçirilen komşu hesap bir spam betiği çalıştırır, sunucu birkaç saat içinde on binlerce mesaj gönderir, alıcı tarafındaki tuzak adreslere düşen mesajlar sunucunun çıkış IP'sini kara listeye sokar. Sizin hesabınıza hiç kimse dokunmamıştır; ama sipariş onaylarınız, parola sıfırlama mailleriniz ve fatura bildirimleriniz artık ya spam klasörüne düşer ya da doğrudan reddedilir.
Buradaki teknik gerçek şudur: dosya sistemi izolasyonu, kaynak sınırı ve hesap başına PHP kullanıcısı, hepsi sunucunun içindeki sınırları çizer. IP adresi ise sunucunun dışarıya görünen tek kimliğidir ve alıcı posta sunucuları o IP'nin arkasında kaç hesap olduğunu bilmez, bilmek de zorunda değildir. Yani izolasyon bu yola karşı tasarım gereği etkisizdir.
Durumunuzu doğrudan sorgulayabilirsiniz:
# Sitenizin oturduğu IP
IP=$(dig +short kendi-siteniz.com A | tail -1); echo "$IP"
# IP'yi ters çevirip kara liste sorgusu yapın; cevap dönerse listelisiniz
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')
dig +short "$REV.zen.spamhaus.org"
dig +short "$REV.zen.spamhaus.org" TXT
# Gönderim IP'niz web IP'nizden farklı olabilir; SPF kaydınız gerçeği söyler
dig +short kendi-siteniz.com TXT | grep -i 'v=spf1'
Son komut önemlidir, çünkü birçok sağlayıcıda giden posta ayrı bir çıkış IP'sinden geçer; web sunucunuzun IP'sini sorgulayıp "temiz" sonucu almak yanıltıcı olabilir. Listede olduğunuzu tespit ederseniz, çıkış başvurusunu kendi başınıza yapmadan önce sebebin sizde olup olmadığını netleştirmeniz gerekir; sürecin tamamını mail sunucum kara listede yazısında adım adım ele alıyoruz.
Bu yola karşı gerçek çözümler izolasyonda değil, mimaridedir. Kritik işlem maillerini paylaşılan sunucunun kendi posta servisiyle değil, ayrı bir gönderim servisi üzerinden kimlik doğrulamalı SMTP ile göndermek, sorunu tamamen ortadan kaldırır: artık teslimat sizin alan adınızın itibarına bağlıdır, komşunuzun davranışına değil. Özel IP de bir seçenektir ama her senaryoda gerekli değildir; hangi durumda gerçekten fark yarattığını özel IP mi paylaşımlı IP mi yazısında karşılaştırıyoruz.
Bulaşma Yolu 3: Komşunun Kaynak Tüketimi ve 508 Hataları#
Ele geçirilen bir hesap genellikle sessiz kalmaz. Kripto madenciliği yazılımı CPU'yu doldurur, spam kuyruğu disk giriş-çıkışını kilitler, botnet trafiği ağ kartını meşgul eder. Eski nesil paylaşımlı sunucularda bu doğrudan sizi vururdu: sunucu geneli yük artar, sizin siteniz de yavaşlardı.
Modern kurulumlarda bu yolun büyük kısmı kapalıdır. LVE tipi hesap başına kaynak sınırlaması, her hesabı kendi CPU, bellek, süreç sayısı ve IO tavanına hapseder; komşu hesap tavanına çarptığında yalnızca o hesap bekletilir. Bu yüzden ele geçirilmiş bir komşunun sizi doğrudan yavaşlatması artık istisnadır.
Ancak "büyük kısmı" ve "tamamen" farklı şeylerdir. Sınırlamanın kapsamına girmeyen paylaşılan bileşenler hâlâ vardır: ortak MySQL sunucusu, disk dizisinin toplam IOPS kapasitesi, ağ arayüzü ve sunucunun toplam bellek basıncı. Çok agresif bir kötüye kullanım bu ortak katmanlarda yine de hissedilir.
Asıl kafa karışıklığı ise teşhis tarafında yaşanır. Sitenizde "508 Resource Limit Is Reached" gördüğünüzde ilk düşünülen şey komşudur, oysa 508 tanımı gereği sizin hesabınızın kendi tavanına dayandığını söyler. Yani 508, komşu sorununun değil kendi kaynak kullanımınızın işaretidir; grafiği okuma ve limitleri ayırt etme yöntemini paylaşımlı hosting kaynak limitleri yazısında bulabilirsiniz. Komşu kaynaklı bir yavaşlamanın imzası farklıdır: sizin kaynak grafiğiniz düz seyrederken yanıt sürelerinin genel olarak artması, veritabanı sorgularının uzaması ve bunun sunucudaki tüm sitelerde aynı anda görülmesi.
Bulaşma Yolu 4: Tek Şikâyetle Sunucu Geneline Alınan Önlemler#
İzolasyonun kesmediği ikinci yol budur ve tartışmalarda neredeyse hiç konuşulmaz. Bir kötüye kullanım bildirimi sağlayıcıya ya da üst ağ operatörüne ulaştığında, alınan önlem her zaman hesap seviyesinde olmaz.
Somut örnekler: yoğun bir DDoS saldırısının hedefi olan komşu site yüzünden sunucunun IP'si üst ağ tarafından geçici olarak karadeliğe alınabilir (null route); bu süre boyunca o IP'deki tüm siteler erişilemez olur. Bir güvenlik olayından sonra sağlayıcı sunucu genelinde daha katı bir uygulama güvenlik duvarı kural seti devreye alabilir ve sizin tamamen meşru bir formunuz "yanlış pozitif" olarak engellenmeye başlayabilir. Ciddi hukuki vakalarda donanıma bütünüyle el konulması gibi uç senaryolar da vardır.
Bu yolun ortak özelliği şudur: sizin hesabınız hiçbir kurala aykırı davranmamıştır, teknik olarak da izole edilmiştir, ama alınan önlem hesap seviyesinin üstünde uygulanmıştır. Bu riske karşı yapılabilecek tek anlamlı hazırlık, tam ve bağımsız bir yedeğinizin sunucunun dışında durmasıdır. Sunucuya erişemediğiniz bir günde, sunucudaki yedeğin hiçbir değeri yoktur.
Hangi Yolu İzolasyon Gerçekten Kesiyor#
Aşağıdaki tablo yazının özeti niteliğinde; sağlayıcınıza soru sorarken de bu satırları kullanabilirsiniz.
| Bulaşma yolu | İzolasyon kesiyor mu | Neden | Sizin elinizdeki önlem |
|---|---|---|---|
| Symlink ile dosya okuma | Evet, büyük ölçüde | Kafeslenmiş hesap hedefi göremez, PHP kendi kullanıcısı olarak çalışır | SymLinksIfOwnerMatch, open_basedir, sınırlı yetkili DB kullanıcısı |
Ortak /tmp üzerinden oturum çalma | Evet | Sanal /tmp her hesaba ayrıdır | session.save_path kendi dizininize |
Ortak MySQL'e localhost erişimi | Kısmen | Parola sızarsa izolasyon devreye girmez | Güçlü ve hesaba özel DB parolası, minimum yetki |
| Paylaşılan IP'nin kara listeye düşmesi | Hayır | IP sunucunun dışa dönük tek kimliğidir | Harici SMTP servisi, SPF/DKIM/DMARC, özel IP |
| Komşunun CPU/IO tüketimi | Evet, büyük ölçüde | Hesap başına kaynak tavanı | Önbellekleme, sorgu optimizasyonu, doğru paket |
| Sunucu geneli WAF/güvenlik duvarı kuralı | Hayır | Önlem hesap seviyesinin üstünde | Sağlayıcıyla iletişim, yanlış pozitif bildirimi |
| IP'nin null-route edilmesi / el konulması | Hayır | Ağ ve donanım seviyesi | Sunucu dışında bağımsız yedek, DNS TTL'i düşük tutmak |
Tablodan çıkan sonuç net: modern bir paylaşımlı sunucuda doğrudan dosya bulaşması artık ana risk değildir; ana risk paylaşılan dışa dönük kimliktir. Sağlayıcı seçerken sorulacak doğru sorular da bu yüzden "CageFS var mı" ile bitmez; giden postanın nasıl ayrıştırıldığı, kötüye kullanım vakalarında hangi seviyede önlem alındığı ve yedeklerin sunucunun dışında tutulup tutulmadığı en az onun kadar belirleyicidir.
Kendi Tarafınızda Alabileceğiniz Önlemler#
Komşunuzu yönetemezsiniz, ama saldırı yüzeyinizin büyük kısmını yönetebilirsiniz. Aşağıdaki liste etki sırasına göre dizilmiştir:
- Veritabanı kullanıcısını daraltın. WordPress'in
ALL PRIVILEGESile çalışması zorunlu değildir; günlük çalışma içinSELECT, INSERT, UPDATE, DELETEyeterlidir.wp-config.phpsızsa bile saldırganın tabloyu düşürme veya dosya yazma imkânı kalmaz. open_basedirvesession.save_pathayarlarını kendi hesabınıza kilitleyin. İkisi de panelden, tek seferde, geri dönüşsüz bir risk almadan yapılır.- Yapılandırma dosyalarına doğrudan erişimi kapatın ve dizin listelemesini kapalı tutun.
- Yedeğinizi sunucunun dışına alın. Aynı diskteki yedek, idari bulaşma senaryolarında ve disk arızasında değersizdir.
- Kritik postaları harici bir SMTP servisine taşıyın. Paylaşılan IP itibarına bağımlılığı bitiren tek adım budur.
- Kullanmadığınız her şeyi silin. Devre dışı bıraktığınız eklenti ve tema dosyaları diskte durduğu sürece saldırı yüzeyidir; deaktif olmaları çalıştırılamayacakları anlamına gelmez.
- Dosya bütünlüğünü düzenli kontrol edin. Kendi hesabınızda değişen dosyaları hızlıca görmek çoğu zaman bir tarayıcıdan daha erken uyarır:
# Son 48 saatte değişen PHP dosyaları — beklenmedik bir isim varsa incelenmelidir
find ~/public_html -name '*.php' -mtime -2 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Yükleme dizininde hiç olmaması gereken çalıştırılabilir dosyalar
find ~/public_html/wp-content/uploads -name '*.php' -o -name '*.phtml'
İkinci komutun çıktısı boş olmalıdır. Bir sonuç dönüyorsa bu neredeyse kesinlikle bir web shell'dir ve doğrudan temizliğe değil, önce kapsam tespitine geçmeniz gerekir; sırayı hacklenmiş site kurtarma yazısında ele alıyoruz.
Hangi Eşikten Sonra Sanal Sunucu Gerçek Bir Kazanç#
Sanal sunucuya geçmek her sorunu çözmez ve güvenlik gerekçesiyle yapılan geçişlerin bir kısmı aslında güvenliği düşürür: paylaşımlı hostingde işletim sistemi güncellemeleri, çekirdek yamaları ve sunucu seviyesindeki güvenlik yazılımı sağlayıcının sorumluluğundadır. Kendi sunucunuzda bunların hepsi sizin sorumluluğunuzdur ve yamalanmamış bir sanal sunucu, yönetilen bir paylaşımlı hesaptan çok daha risklidir.
Geçişin gerçek bir güvenlik kazancı sağladığı durumlar spesifiktir:
| Durum | Paylaşımlı yeterli mi | Gerekçe |
|---|---|---|
| Kurumsal blog, tanıtım sitesi | Evet | Paylaşılan IP itibarı ve izolasyon bu profil için yeterli |
| Düzenli işlem maili gönderen e-ticaret | Evet, harici SMTP ile | Asıl risk teslimat; bu SMTP servisiyle çözülür |
| Sözleşmede "veriler ayrılmış ortamda tutulur" taahhüdü | Hayır | Ortak veritabanı sunucusu bu taahhüdü karşılamaz |
| Özel güvenlik yazılımı, ModSecurity kural seti isteyen kurulum | Hayır | Paylaşımlı ortamda sunucu geneli kurallar değiştirilemez |
| Kendi güvenlik duvarı, fail2ban, VPN gerektiren yapı | Hayır | Bu bileşenler kök yetkisi ister |
| Sunucu geneli önlemlerden etkilenme toleransı düşük | Hayır | Tek kiracı olmak idari bulaşmayı ortadan kaldırır |
| Sistem yöneticisi olmayan, güncellemeyi takip edemeyecek ekip | Evet | Yönetim yükü riskten büyüktür |
Kısaca: geçiş kararınızı "komşum hacklenirse" korkusuyla değil, tek kiracı olmanın gerçekten gerektiği bir yükümlülüğünüz veya bir yapılandırma ihtiyacınız olup olmadığıyla verin. İki modelin kaynak, maliyet ve yönetim tarafındaki farklarını paylaşımlı hosting ile VPS karşılaştırması yazısında sayısal olarak ele alıyoruz. Geçiş yapıyorsanız ilk gün yapılacak işler listesini hazırlayın: güncellemeleri otomatikleştirin, SSH'i anahtarla sınırlayın, güvenlik duvarını kapalıdan açığa doğru kurun. Aksi hâlde komşusuz bir sunucuda tek başınıza daha savunmasız olursunuz.
Sıkça Sorulan Sorular#
Aynı sunucudaki bir site hacklenirse benim sitem otomatik olarak virüs kapar mı?#
Hayır, otomatik bir bulaşma yoktur. Modern bir sunucuda her hesap kendi dosya sistemi kafesinde ve kendi PHP kullanıcısıyla çalışır; komşu hesaptaki bir web shell sizin dizininize yazamaz. Gerçekte olan şey genellikle dolaylıdır: paylaşılan IP'nin kara listeye düşmesi, sunucu geneli bir önlemden etkilenmeniz ya da sızan bir veritabanı parolasının kullanılması.
Hosting sağlayıcım komşumun hacklendiğini bana bildirmek zorunda mı?#
Sizin verileriniz etkilenmediyse doğrudan bir bildirim yükümlülüğü doğmaz; olay komşu hesabın veri sorumlusunu ilgilendirir. Ancak sunucu genelinde bir kesinti, IP değişikliği veya kural değişikliği gerekiyorsa sağlayıcı hizmet sözleşmesi gereği sizi bilgilendirir. Kendi hesabınızdan veri sızdığına dair bir şüphe varsa sağlayıcıdan olayın kapsamını yazılı olarak istemeniz gerekir.
CageFS varsa symlink saldırısından tamamen korunmuş olur muyum?#
Bu vektöre karşı korunma çok yüksektir, çünkü kafeslenmiş bir hesap başka bir hesabın dizinini hiç göremez, dolayısıyla hedef yolu oluşturulamaz. Fakat izolasyon parola sızıntısını, zayıf bir eklenti açığını ya da sizin kendi hesabınızda çalışan zararlı bir dosyayı engellemez. İzolasyon komşudan gelen riski kapatır, kendi hesabınızdan gelen riski kapatmaz.
Komşum yüzünden IP'm kara listeye düşerse ne yapmalıyım?#
Önce gerçekten kaynağın siz olmadığını doğrulayın: giden posta kuyruğunuzu ve yükleme dizininizdeki şüpheli dosyaları kontrol edin. Sebep sizde değilse çıkış başvurusunu kendiniz değil sağlayıcınız yapmalıdır, çünkü IP sağlayıcıya aittir ve listeler genellikle IP sahibinin başvurusunu ister. Kalıcı çözüm, işlem maillerini harici bir SMTP servisine taşımaktır.
Özel IP almak komşu riskini ortadan kaldırır mı?#
Yalnızca itibar tarafını çözer, dosya ve kaynak tarafını çözmez. Özel IP ile e-posta teslimatınız ve IP tabanlı engellemeler komşudan bağımsız hâle gelir. Ancak hâlâ aynı fiziksel sunucuda, aynı diskte ve aynı veritabanı sunucusunda durursunuz; sunucu geneli bir güvenlik önlemi veya donanım arızası sizi yine etkiler.
Sanal sunucuya geçersem bu risklerin hepsi biter mi?#
Komşu kaynaklı risklerin büyük kısmı biter, ama yerine yeni bir sorumluluk gelir. Tek kiracı olduğunuzda dosya, kaynak ve idari bulaşma yolları kapanır; buna karşılık çekirdek güncellemeleri, güvenlik duvarı, SSH sertleştirmesi ve yedekleme tümüyle size geçer. Bu işleri düzenli yapacak bir ekibiniz yoksa net güvenlik durumunuz geçişten sonra kötüleşebilir.