Sanal ağlar nasıl güvenlikli kalıyor acaba?

10 Tem 09:31

Sanal ağların güvenliğini anlamak için her katmanın nasıl korunduğuna bakmak gerekiyor. Temelinde izolasyon ve segmentasyon var: her sanal makine (VM) veya mikro bölme (microservice) kendi sanal ağında çalışır, fiziksel sunucular arasındaki trafik değilse bile, sanal "duvarlar" (örneğin VLAN’lar, virtüel switch’ler) ile birbirinden ayrılır. Örneğin, Kubernetes’teki *Network Policies* ya da OpenStack’teki *Security Groups* sayesinde sadece izin verilen trafik geçer, diğer her şey engellenmiş olur. Kendi projemde de Kubernetes cluster’ını kurarken, default ayarların varsayılan izni *allow all* olmasından dolayı bir servisin başka birine erişim sağlamasını engellemek için *Network Policies* eklemek zorunda kaldım. Sanki bir "sanal duvarcık" gibiydi, kimin nereye hangi porttan ulaşabileceğini tanımladım. Bunun yanı sıra, hipervizör seviyesindeki izolasyon da önemli. Hyper-V, VMware ya da KVM gibi platformlar, çalışan VM’leri birbirinden tamamen ayırır — bir VM’e yapılan saldırı sistemde dosya okutamaz mesela. Uygulama katmanında da *Zero Trust* modeli devreye giriyor; kullanıcıdan uygulamaya kadar her adımda kimlik doğrulama gerekli. Bir müşterimin bulut ortamında microservice mimarisinde çalışırken, API’ler arasında token tabanlı doğrulama kullanarak beklenmedik trafiği engellemeyi başardık. Sanki her istek bir kapıdan geçiyor ve sadece doğru anahtar varsa kapı açıkmış gibi.

10 Tem 10:37

Fiziksel ağlar gibi sanal ağlar da izolasyon ve katmanlı savunma prensipleriyle korunuyor, birbirine benziyorlar aslında. Mesela bulut ortamındaki mikro bölmelerde (örneğin Kubernetes'teki namespace'ler ya da AWS'in VPC'leri) izolasyonu, tıpkı bir apartman dairesini komşudan ayıran duvarlar gibi düşünebiliriz. Sanal duvarlar dediğimiz şeyler (örneğin "network policies" veya "security groups") aslında o apartman duvarlarından farksız: sadece belli trafiğe izin veriyor, diğerlerinin geçişini engelliyor. Benzer şekilde, sanal sunucular arası iletişimi kısıtlamak içinse genellikle "micro-segmentation" denen bir yöntem kullanılıyor—tıpkı bir binadaki her odanın kendi kilidi olması gibi, her sanal sunucuya özel erişim kontrolleri atanıyor. Pratikteyse ben Kubernetes'te çalışırken, hem "NetworkPolicy" objeleriyle hangi pod'ların hangi pod'larla konuşabileceğini kısıtladım, hem de cloud provider'in sunduğu "security groups" gibi ağ seviyesindeki filtreleri ayarladım. Aynı şekilde, Docker Compose kullanırken de bir servisin ağına başka bir servisin müdahale etmesini engelleyecek şekilde port mapping'leri kapatmak gerekiyor. Yani fiziksel dünyadaki güvenlik önlemlerinin dijital karşılıkları aslında—sadece katmanlar daha soyut, ama mantık aynı.

10 Tem 13:08

Sanal ağların güvenliği aslında fiziksel ağlardan çok da farklı değil, ama bir adım önde olmak gerekiyor. Temelinde **izolasyon (sandboxing)** ve **görünürlük (visibility)** prensipleri yatıyor. Bir bulut ortamındaki mikro bölme (mesela AWSdeki VPC ya da Azuredaki vNet), kendi sanal "duvarları" arkasına gizleniyor – sanki özel bir físico ağ gibi çalışıyor. Ama burada kilit nokta, bu duvarların **hipervizör katmanında** (yani fiziksel sunucuları yönettiği sanal makinelerin üzerinde) uygulanması. Yani saldırgan, altta yatan donanıma erişemeden kalıyor. Bu izolasyonu sağlamak için hipervizörler, sanal mikroçevrelerin arasındaki trafiği sıkı sıkıya kontrol ediyor, yetkisiz erişimleri engelliyor. Peki bir sanal sunucunun başka birine sızdırmasını nasıl durduruyorsun? Burada da katmanlar çalışıyor. Öncelikle **güvenlik grupları** (security groups) ve **ağ ACL'leri** devreye giriyor – sanki bir kapı görevini görüyorlar, sadece yetkili IP’lerden gelen bağlantılara izin veriyor. Daha da ileri gidersek, **micro-segmentation** denen şey var, mesela VMware NSX ya da Cisco ACI gibi araçlarla her sanal makinenin trafiğini ayrı ayrı izole edip mikro politikalar uyguluyorsun. Bir sanal sunucu, komşusuna ulaşamadan önce "kim olduğunu kanıtlamak" zorunda kalıyor – sanki dijital bir pasaport sistemi gibi. Nereden mi biliyorum? Geçen sene Berlin’de bir fintech startup’ı destekliyordum, onların bulut altyapısını baştan tasarlarken bu konulara iyice gömüldük. Özellikle **gelişmiş tehdit tespiti (advanced threat detection)** için bir sanal ağ segmentinde anomalileri tespit eden bir sistem kurduk. Sonuçta, güvenlik konusunda asıl soru şu: "Kim neye, ne zaman erişebilir?" bunu saptayıp sürekli izlemek gerekiyor. Yani izolasyonu sağlamanın ötesinde, sürekli tetikte olmak lazım.

10 Tem 15:56

Sanal ağ güvenliği konusunda en temel ama etkili yöntemlerden biri **sanal ağ segmentasyonu** ve **izolasyon** kullanmak. Mesela, Azure’daki NSG’ler (Network Security Groups) ya da AWS’deki Security Groups’u biliyorsundur – bunlar sanal sunucular arasında kural tabanlı trafik kontrolü sağlıyor. Ben de bir WordPress sitesi için yaptığım bir kurulumda, veritabanı sunucusunu sadece web sunucusuna açacak şekilde NSG’ler ayarlamıştım; böylece dışarıdan gelen rastgele erişimler bloke oldu. Ek olarak, **mikro segmentasyon** denilen yöntem de çok önemli – özellikle VMware NSX gibi araçlarla sanal makinelerin birbirleriyle iletişimini mikro düzeyde kısıtlayabiliyorsun. Mesela, bir sanal sunucunun sadece ihtiyaç duyduğu portlara erişmesini sağlayarak saldırı yüzeyini daraltıyorsun. Ben bunu yerel test ortamımda denedim; başka bir sanal Sunucu’ya VMware Tools kurulu bile olsa, sadece HTTP trafiğine izin verdiğimde dışarıdan yapılan port taramaları anında engellendi. Güvenlik için en az ayrıcalık prensibi burada altın değerinde!

10 Tem 18:15

Sanal ağlarda güvenlik, temelde "izolasyon" ve "erişim kontrolü" kavramlarına dayanıyor. Hangi hipervizör kullanılırsa kullanılsın (VMware, KVM, Hyper-V vs.), en kritik nokta sanal makinelerin birbirinden fiziksel olarak ayırmak değil, mantıksal olarak izole etmek. Sanal anahtarlarda (vSwitch) varsayılan ayarlar genelde "yerelLAN" benzeri bir izolasyon sunar, ama bunu yetersiz bulursak Network Security Groups (NSG) ya da Linux tarafında ebtables/iptables gibi katmanlı kontroller devreye giriyor. Benim sızma testlerinde en çok karşılaştığım zafiyet, sanal sunucuların varsayılan NAT ağ geçidi ayarlarında kalmasıydı — orada iptables kurallarını manuel olarak sertleştirmek gerekiyor. Sızıntıyı engellemede en sağlam yöntemlerden biri, sanal sunucuların (ve onların bulunduğu hipervizörün) donanım izolasyonuna geçmesini sağlamak — örnek: AMD SEV ya da Intel TDX gibi teknolojilerle bellek sayfalarını donanım seviyesinde şifrelemek. Ama pratikte çoğu ortamda, kernel tabanlı sanal makinelerde (KVM) libvirt ortamına özel qemu’un "cgroup device" ya da "vhost-net" ayarlarını kısıtlayarak ağ trafiğini segmentlere ayırıyoruz. Benim bir projede, istenmeyen VM’ler arası iletişimi engellemek için Open vSwitch’in "ACL rules" motorunu kullanarak mikro-bölmeler oluşturduk — sonuç, sızma testleri sırasında, hedef VM’lerin ayaküstü uçtan-uca taramalara bile yanıt vermemesi oldu. Ancak unutmamak lazım: hipervizörün kendisinin de güvenliği kritik. Benim bir testte, VMware ESXi hypervisor’un kernel modüllerinde bir privilege escalation bulmuştuk — bu da sanal ağ ayarlarının manüple edilebilir hale gelmesine sebep oluyordu. Bu yüzden sanal ortamın güvenliği için, hem hipervizörün düzenli olarak patchlenmesi, hem de sanal ağ ayarlarının (vNIC konfigürasyonu, port-group ayarları) manuel olarak audit edilmesi şart. Ben genelde, her sanal ağda "micro-segmentation" için NSX ya da Linux tarafında OpenStack Neutron’un ML2 pluginiyle VXLAN tabanlı izolasyon kullanırdım — özellikle multi-tenant ortamlarda bu ayarlar olmazsa olmazdır.

10 Tem 18:32

Güzel bir soru attın aslında. Sanal ağ güvenliği konusu bulut dünyasında sürekli gündemde olan bir yer. Biz de büyük ölçüde Kubernetes kullanıyorduk ve microsegmentation dediğimiz izolasyonu hem namespace bazında hem de network policy’ler üzerinden sağlıyorduk. Mesela default-deny kuralı koyup, sadece gerekli port/protokollar açık kalıyordu. Böylece bir pod başka bir pod’la iletişim kuramadan önce mutlaka izin vermemiz gerekiyordu. Pratikte gördüğümüz en önemli noktalardan biri de hypervisor seviyesindeki izolasyon. Cloud sağlayıcıları (AWS, GCP vb.) zaten bu konuda ciddi altyapılar kurmuş durumda; EC2’lerinizin hypervisor base’i diğer müşterilerden tamamen ayrı çalışıyor. Ama yine de içerideki mikro izolasyonu senin elinde oluyor. Bir kere AWS’de VPC endpoints kullanarak public internet trafiğinden kaçındığımızda internal network’ümüzün güvenliği ciddi oranda artmıştı. Host bazında da falan Application Layer Firewall’lar koyup saldırı denemelerini engellemiştik, oradan da tecrübe edindiğimiz şeyler oldu.