Sanallaştırma, "her makine kendi kutusunda" hissini verir ve bu his büyük ölçüde doğrudur — ama tamamen değil. Sanal makine güvenliği, işlemcinin donanımsal ayırma mekanizmalarından başlayıp ağ yapılandırmasına, depolama düzenine, anlık görüntülere ve yönetim düzlemine kadar uzanan bir zincirdir. Zincirin herhangi bir halkası gevşediğinde, aynı ana makinedeki iki sanal makine birbirinin verisine ulaşabilecek hale gelir.
Bu yazıda izolasyonun gerçekte hangi katmanlarda sağlandığını, hipervizör tarafında saldırı yüzeyini nasıl küçülteceğinizi, ağ ve depolama izolasyonunun somut kurallarını, anlık görüntü ve şablonların yarattığı az bilinen riskleri, gürültülü komşu sorununu ve sonunda uygulanabilir bir sertleştirme kontrol listesini bulacaksınız. Hipervizörün kendisinin hedef alındığı senaryoları ise ayrı bir yazıda ele aldım; oraya da yeri geldikçe bağlantı vereceğim.
İzolasyon Aslında Hangi Katmanlarda Sağlanır#
Sanal makinelerin birbirinden ayrılması tek bir mekanizmanın işi değildir. Üst üste binmiş dört katman vardır ve her biri farklı bir riski kapatır:
| Katman | Ne sağlar | Zayıfladığında ne olur |
|---|---|---|
| İşlemci (VT-x/AMD-V, EPT/NPT) | Bellek adres alanlarının donanımsal ayrımı | Bir VM başka bir VM'in belleğini okuyabilir |
| IOMMU | Aktarılan cihazların bellek erişiminin sınırlanması | Cihaz üzerinden ana makine belleğine erişim |
| Hipervizör | Cihaz emülasyonu, zamanlama, kaynak paylaşımı | VM kaçışı, ana makine ele geçirilmesi |
| Ağ ve depolama | Trafiğin ve disk imajlarının ayrılması | Komşu trafiğini dinleme, veri sızıntısı |
En alttaki iki katman donanım tarafından sağlanır ve genelde sağlamdır; sizin doğrudan yapılandıracağınız şey değildir, ama BIOS'ta açık olduklarını doğrulamanız gerekir. Asıl operasyonel risk üstteki iki katmandadır — yani hipervizör yapılandırması ile ağ/depolama düzeninde. Gerçek hayatta gördüğüm veri sızıntılarının neredeyse tamamı, işlemci izolasyonunun kırılmasından değil, yanlış yapılandırılmış bir sanal anahtar ya da paylaşılan bir disk imajından kaynaklandı.
Bu, iyi haberdir: bu iki katman tamamen sizin kontrolünüzdedir ve doğru yapılandırıldığında riskin büyük kısmını ortadan kaldırır.
Hipervizör Katmanı: Saldırı Yüzeyini Küçültmek#
Hipervizörün konuk sisteme sunduğu her sanal cihaz, potansiyel bir saldırı yüzeyidir. Ses kartı, seri port, disket denetleyicisi, USB denetleyicisi, CD-ROM — konuk sistemin bunlarla konuştuğu her arayüz, hipervizör tarafında işlenen bir koddur ve o kodda bir hata varsa sömürülebilir. Kural basittir: kullanmadığınız her sanal cihazı kaldırın.
libvirt/KVM tabanlı bir ortamda bir makinenin gerçekte hangi cihazlara sahip olduğunu şöyle görürsünüz:
# Sanal makinenin tanımlı tüm cihazlarını listele
virsh dumpxml web01 | grep -E "<disk|<interface|<controller|<channel|<sound|<serial|<video"
# Çalışan makinelerin listesi ve kaynakları
virsh list --all
virsh dominfo web01
Çıktıda ihtiyaç duymadığınız bir <sound> ya da <serial> girdisi varsa, makineyi kapatıp tanımdan çıkarın. Aynı mantık ticari hipervizörlerde de geçerlidir: sanal makine ayarlarındaki kullanılmayan denetleyicileri kaldırmak, hem güvenlik hem de başlangıç performansı açısından doğrudur.
İkinci başlık konuk araçlarıdır (guest tools/agent). Bunlar kullanışlıdır — düzgün kapatma, saat senkronizasyonu, IP raporlama — ama bazı özellikleri ana makine ile konuk arasında doğrudan kanal açar: pano paylaşımı, dosya sürükle-bırak, paylaşılan klasör. Sunucu ortamında bu özelliklerin hiçbirine ihtiyacınız yoktur; kapatın. Ajanın kendisini kurulu tutmak sorun değildir, açık bıraktığınız kanallar sorundur.
Üçüncü başlık iç içe sanallaştırmadır (nested virtualization). Konuk sistemin kendi içinde sanallaştırma çalıştırabilmesi, hipervizörün ek kod yollarını açması demektir. Buna gerçekten ihtiyacınız yoksa kapalı tutun:
# KVM'de iç içe sanallaştırma açık mı? (Y = açık)
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null || \
cat /sys/module/kvm_amd/parameters/nested 2>/dev/null
Son olarak yamaları takip edin. Hipervizör güncellemeleri, işletim sistemi güncellemeleriyle aynı takvimde gelmez ve gecikmesi en pahalıya mal olan yamalar bunlardır. Yama yönetimini elle yapmak yerine otomatikleştirmek için Ansible ile sunucu otomasyonu yaklaşımı iyi bir başlangıçtır.
Ağ İzolasyonu: VLAN, Güvenlik Duvarı ve Yönetim Düzlemi#
Sanal makinelerin en sık gözden kaçan zayıf noktası ağdır, çünkü varsayılan yapılandırmalar kolaylık için gevşektir.
Birinci kural: üç trafik türünü fiziksel ya da mantıksal olarak ayırın. Yönetim trafiği (hipervizör arayüzü, BMC), depolama trafiği ve sanal makine trafiği ayrı VLAN'larda olmalıdır. Yönetim düzleminin üretim ağıyla aynı yerde bulunması, tek bir ele geçirilmiş web sunucusunun tüm sanallaştırma altyapısına ulaşabilmesi demektir. Aynı gerekçe donanım yönetim kartları için de geçerlidir; ayrıntısı IPMI, iDRAC ve iLO rehberi yazısında.
İkinci kural: sanal anahtar üzerindeki üç tehlikeli ayarı kapatın. Hemen tüm hipervizörlerde karşılığı olan bu ayarlar varsayılan olarak kapalı gelmelidir, ama devralınan ortamlarda açık bulmak şaşırtıcı derecede yaygındır:
| Ayar | Açık olursa risk |
|---|---|
| Karışık mod (promiscuous mode) | Bir VM aynı segmentteki tüm trafiği dinleyebilir |
| MAC adresi değişikliği | VM kendi MAC'ini değiştirip başka bir makineyi taklit edebilir |
| Sahte iletim (forged transmits) | VM, başkasının kaynak MAC'iyle paket üretebilir |
Üçüncü kural: güvenlik duvarını konuk sisteme bırakmayın. Konuk içindeki ufw ya da firewalld yararlıdır ama makine ele geçirildiğinde saldırganın kapatabileceği bir katmandır. Asıl filtreleme, hipervizör ya da ağ katmanında — yani konuğun erişemediği bir yerde — yapılmalıdır. Uygulama katmanı saldırıları içinse ayrı bir katman gerekir; WAF ve hacimsel saldırılar için DDoS koruma bu boşluğu doldurur.
Dördüncü kural: aynı segmentteki makineler birbirini görmesin. Farklı müşterilere ya da farklı güvenlik seviyelerine ait makineler aynı L2 segmentinde duruyorsa, aralarındaki trafiği özel VLAN ya da port izolasyonu ile kesin. Ağ planınızı çıkarırken subnet hesaplayıcı segment boyutlarını doğru belirlemenize yardımcı olur.
Depolama İzolasyonu ve Şifreleme#
Depolama tarafında üç somut risk vardır.
Paylaşılan disk imajı. İki sanal makineye aynı sanal diski bağlamak, kümeleme senaryoları dışında yapılmaması gereken bir şeydir; dosya sistemi seviyesinde eşzamanlı erişim korunmadığı için hem veri bozulması hem de izolasyon kaybı doğurur. Her makineye kendi birimini verin.
Veri kalıntısı (data remanence). Bir sanal makineyi sildiğinizde, altındaki blokların gerçekten temizlendiğinden emin olun. Aksi halde aynı bloklar başka bir müşterinin makinesine tahsis edildiğinde eski veri okunabilir hale gelebilir. Sağlayıcı tarafında bu genelde ince tahsisli (thin) birimlerde TRIM/discard ya da silme sonrası sıfırlama ile çözülür; kendi ortamınızı yönetiyorsanız bu davranışı doğrulamanız gerekir.
Şifresiz veri. Diskteki verinin şifrelenmesi, ana makineye fiziksel ya da yönetimsel erişimi olan birine karşı bir katman ekler. Konuk içinde LUKS ile şifreleme, en taşınabilir yöntemdir:
# Veri diskini şifrele ve aç
sudo cryptsetup luksFormat /dev/vdb
sudo cryptsetup open /dev/vdb veri
sudo mkfs.ext4 /dev/mapper/veri
sudo mount /dev/mapper/veri /srv/veri
# Şifrelenmiş birimin durumunu gör
sudo cryptsetup status veri
Kalıcı bağlama ve açılışta otomatik çözme yapılandırması için disk bağlama, mount ve fstab yazısına bakabilirsiniz. Şifreleme anahtarlarını makinenin kendi diskinde saklamanın koruma sağlamadığını unutmayın; anahtar yönetimi ayrı bir tasarım kararıdır. Güçlü parola üretmek için şifre üretici, yedeklerin bütünlüğünü doğrulamak için hash üretici araçlarını kullanabilirsiniz.
Anlık Görüntüler, Şablonlar ve Klonlama Riskleri#
Bu bölüm, deneyimli yöneticilerin bile atladığı risklerin toplandığı yerdir.
Anlık görüntüler RAM içeriğini de saklayabilir. Çalışan bir makinenin anlık görüntüsünü bellek dahil aldığınızda, o anda bellekte bulunan her şey — çözülmüş disk şifreleme anahtarları, veritabanı parolaları, oturum belirteçleri — diske yazılır. Bu dosya genelde şifresizdir ve depolama alanına erişebilen herkes tarafından okunabilir. Anlık görüntü dosyalarını üretim verisi kadar hassas kabul edin.
Geri alma, güvenlik yamalarını da geri alır. Bir haftalık bir anlık görüntüye dönmek, o hafta uygulanmış tüm güvenlik güncellemelerini geri almak demektir. Ayrıca iptal edilmiş bir kullanıcı hesabı ya da değiştirilmiş bir parola yeniden geçerli hale gelebilir. Geri alma sonrası ilk iş, güncellemeleri yeniden uygulamak ve kimlik bilgilerini kontrol etmek olmalıdır.
Anlık görüntü yedek değildir. Aynı depolama altyapısında duran bir anlık görüntü, o altyapı bozulduğunda birlikte gider. Gerçek yedek, ayrı bir sistemde ve tercihen ayrı bir lokasyonda tutulur; Borg ile sunucu yedekleme yazısı pratik bir kurulum sunar, hazır çözüm için yedekleme hizmetimiz devreye girer.
Şablonlardan klonlama kimlik çakışması yaratır. Hazır bir imajdan onlarca makine türetirken üç değer mutlaka yenilenmelidir: SSH ana makine anahtarları, machine-id ve varsa sabit kimlik bilgileri. Aynı SSH ana makine anahtarını taşıyan iki sunucu, ortadaki adam saldırısına karşı doğrulamayı anlamsız kılar. Şablonu kapatmadan önce temizleyin:
# Şablon imajı hazırlarken (makineyi kapatmadan hemen önce)
sudo rm -f /etc/ssh/ssh_host_*
sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id
sudo cloud-init clean --logs # cloud-init kullanılıyorsa
history -c
# Klondan açılan makinede doğrula (boş olmamalı, benzersiz olmalı)
cat /etc/machine-id
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
Kaynak İzolasyonu: Gürültülü Komşu Sorunu#
Güvenlik yalnızca gizlilik değildir; erişilebilirlik de güvenliğin parçasıdır. Aynı ana makinedeki bir sanal makine tüm CPU'yu ya da tüm disk IOPS'unu tüketirse, komşularının hizmeti fiilen kesilir. Bu, kötü niyetli olmak zorunda da değildir — kaçak bir süreç ya da yanlış zamanlanmış bir yedekleme işi aynı etkiyi yaratır.
CPU tarafında bunun ölçüsü steal time'dır: konuk sistemin çalışmak istediği ama hipervizörün ona sıra vermediği zaman.
# 'st' sütunu steal time yüzdesidir
vmstat 1 5
# Sürekli izleme (top içinde %st alanı)
top -bn1 | head -3
Sürekli %5'in üzerinde bir steal time, ana makinenin aşırı tahsis edildiğini gösterir. Kendi hipervizörünüzü yönetiyorsanız çözüm, kritik makinelere CPU rezervasyonu tanımlamak ve aşırı tahsis oranını düşürmektir. Disk tarafında ise makine başına IOPS ve bant genişliği sınırı tanımlamak, tek bir makinenin depolamayı kilitlemesini engeller.
Paylaşımlı kaynak modelleri arasındaki farkı ve ne zaman ayrılmış kaynağa geçmek gerektiğini bulut sunucu mu VDS mi yazısında karşılaştırdım. GPU gibi özel kaynakları paylaştırırken de aynı sorun geçerlidir; kontrollü bölme yöntemleri için vGPU ile GPU paylaşımı yazısına bakabilirsiniz.
Pratik Sertleştirme Kontrol Listesi#
Bu listeyi yeni kurulan her ortamda baştan sona uygulayın:
- BIOS'ta sanallaştırma ve IOMMU desteğini açık, iç içe sanallaştırmayı ihtiyaç yoksa kapalı tutun.
- Hipervizör yamalarını ayrı bir takvimle takip edin; işletim sistemi güncellemeleriyle aynı akışta gelmez.
- Kullanılmayan sanal cihazları (ses, seri port, USB, CD-ROM) her makine tanımından kaldırın.
- Konuk aracının pano, sürükle-bırak ve paylaşılan klasör özelliklerini kapatın.
- Yönetim, depolama ve üretim ağlarını ayrı VLAN'lara alın; yönetim düzlemine yalnızca VPN üzerinden erişilsin.
- Sanal anahtarda karışık mod, MAC değişikliği ve sahte iletim ayarlarının kapalı olduğunu doğrulayın.
- Her makineye kendi disk birimini verin; kümeleme dışında disk paylaştırmayın.
- Hassas veri birimlerini şifreleyin ve anahtarı aynı makinede saklamayın.
- Anlık görüntüleri yedek yerine koymayın; ömürlerini sınırlayın ve düzenli temizleyin.
- Şablonları temizleyin: SSH ana makine anahtarları,
machine-idve sabit kimlik bilgileri klonlamadan önce sıfırlansın. - Kaynak sınırları tanımlayın: CPU rezervasyonu ve disk IOPS sınırı ile gürültülü komşuyu engelleyin.
- Merkezi günlük toplama kurun: bir makine ele geçirildiğinde günlükleri silmek saldırganın ilk işidir; günlükler makinenin dışına akmalıdır.
Bu listenin sonuna bir madde daha ekleyebilirsiniz: düzenli olarak doğrulayın. Kurulum günü doğru olan bir ayar, altı ay sonra bir sorun giderme sırasında geçici olarak açılıp unutulmuş olabilir. Yapılandırma denetimini otomatikleştirmek, tek seferlik sertleştirmeden çok daha değerlidir.
Sıkça Sorulan Sorular#
Sanal makineler gerçekten birbirinden yalıtılmış mıdır#
Donanım seviyesinde evet: işlemcinin sanallaştırma uzantıları ve ikinci seviye adres çevirisi, bir sanal makinenin başka bir makinenin belleğine doğrudan erişmesini engeller. Ancak pratikte izolasyon yalnızca bu katmandan ibaret değildir; yanlış yapılandırılmış bir sanal anahtar, paylaşılan bir disk imajı ya da açık bırakılmış bir yönetim arayüzü aynı sonucu doğurabilir. İzolasyon bir zincirdir ve en zayıf halkası kadar güçlüdür.
Aynı fiziksel sunucudaki komşum verimi görebilir mi#
Doğru yapılandırılmış bir ortamda göremez. Bunu sağlayan şey donanımsal bellek ayrımı, her makineye ayrı disk birimi verilmesi ve ağ segmentlerinin ayrılmasıdır. Görebildiği senaryolar yapılandırma hatalarından doğar: sanal anahtarda karışık modun açık olması, iki makineye aynı diskin bağlanması ya da silinen birimlerin temizlenmeden yeniden tahsis edilmesi.
Anlık görüntü almak güvenlik riski oluşturur mu#
Evet, iki açıdan. Bellek dahil alınan bir anlık görüntü, o anda RAM'de bulunan şifreleme anahtarlarını ve parolaları diske yazar ve bu dosya genellikle şifresizdir. Ayrıca eski bir anlık görüntüye dönmek, o tarihten sonra uygulanmış güvenlik yamalarını ve iptal edilmiş kimlik bilgilerini geri getirir. Anlık görüntüleri hassas veri gibi koruyun ve ömürlerini kısa tutun.
Sanal makine güvenliği için hangi ayarlar ilk kapatılmalı#
Öncelik sırası şudur: sanal anahtardaki karışık mod, MAC adresi değişikliği ve sahte iletim ayarları; konuk aracındaki pano paylaşımı, sürükle-bırak ve paylaşılan klasör özellikleri; kullanılmayan sanal cihazlar (ses, seri port, USB, CD-ROM); ve ihtiyaç yoksa iç içe sanallaştırma. Bu dört grup, saldırı yüzeyinin büyük kısmını hiçbir işlevi bozmadan ortadan kaldırır.
Konuk sistemdeki güvenlik duvarı yeterli mi#
Tek başına yeterli değildir. Konuk içindeki güvenlik duvarı yararlı bir katmandır ama makine ele geçirildiğinde saldırganın kapatabileceği bir yerdedir. Asıl filtrelemenin hipervizör ya da ağ katmanında, yani konuğun erişemediği bir düzlemde yapılması gerekir. İki katmanı birlikte kullanmak doğru yaklaşımdır; birini diğerinin yerine koymak değil.
Steal time yüksekse ne yapmalıyım#
Sürekli %5'in üzerinde bir steal time, ana makinenin aşırı tahsis edildiğini ve sizin sanal makinenizin CPU sırası beklediğini gösterir. Kendi hipervizörünüzü yönetiyorsanız aşırı tahsis oranını düşürün ve kritik makinelere CPU rezervasyonu tanımlayın. Hizmet aldığınız bir ortamdaysanız sağlayıcıya bildirin; kalıcı bir sorunsa ayrılmış kaynak sunan bir pakete geçmek doğru çözümdür.
Kapanış#
Sanal makine izolasyonunun donanımsal temeli sağlamdır; kırılganlık neredeyse her zaman yapılandırmadadır. Aklınızda kalması gereken dört alışkanlık şunlar: kullanmadığınız her sanal cihazı ve her konuk aracı özelliğini kapatın; yönetim düzlemini üretim ağından kesin biçimde ayırın; anlık görüntüleri hassas veri gibi koruyup yedek yerine koymayın; ve şablondan klonlamadan önce SSH ana makine anahtarlarıyla machine-id değerini mutlaka sıfırlayın.
Hipervizörün kendisinin hedef alındığı, yani izolasyon sınırının doğrudan aşılmaya çalışıldığı senaryolar ayrı bir konu; onu VM kaçışı ve hipervizör güvenliği yazısında ele aldım. Bu katmanı kendiniz yönetmek istemiyorsanız Clou.TR tarafında izolasyonu hazır kurulmuş seçenekler var: ayrılmış kaynaklı VDS ve sanal sunucu paketleri, tam donanım izolasyonu için dedicated sunucu, sertleştirme ve yama takibini devretmek içinse sunucu yönetimi hizmetimiz bu işi üstlenir.