Mikrosegmentasyon Nedir? Zero Trust ve İş Yükü Güvenliği Rehberi

Mikrosegmentasyon, uygulama ve iş yükleri arasındaki ağ erişimini yalnızca gerekli iletişim ilişkileriyle sınırlandıran bir güvenlik yaklaşımıdır. İngilizcede microsegmentation olarak adlandırılan bu yaklaşımın amacı, bir sistem ele geçirildiğinde saldırganın başka sistemlere geçebileceği yolları daraltmaktır. Mikrosegmentasyon, Zero Trust mimarisini destekler; ancak kimlik güvenliği, uygulama yetkilendirmesi, yama yönetimi ve veri korumanın yerine geçmez.

Bir internet uygulamasının güvenlik açığı üzerinden ele geçirildiğini düşünün. Kritik soru yalnızca saldırganın bu sunucuya nasıl girdiği değildir. Aynı sunucudan veri tabanlarına, yönetim arayüzlerine, yedekleme altyapısına ve başka iş uygulamalarına hangi bağlantıların kurulabildiği de önemlidir. Dış güvenlik duvarının varlığı, kurum içindeki bütün erişim ilişkilerinin doğru sınırlandığını kanıtlamaz.

Bu rehber; BT yöneticileri, altyapı ve ağ ekipleri, güvenlik uzmanları ve kurumsal mimarlar için mikrosegmentasyonu politika tasarımı, bağımlılık keşfi ve günlük işletim üzerinden ele alır. Buradaki iş yükü ifadesi bir uygulama bileşenini, fiziksel veya sanal sunucuyu ya da konteyner üzerinde çalışan servisi kapsayabilir.

Mikrosegmentasyon nedir, neyi değiştirir?

Mikrosegmentasyonun temel değişikliği, geniş ağ üyeliğinden gerekli iş yükü iletişimine geçiştir. “Üretim ağında olduğu için erişebilir” yerine, “bu uygulama bileşeni bu kaynağa bu görev için erişebilir” sorusu sorulur. Uygulama noktası ve kural ayrıntısı kullanılan teknolojiye göre değişebilir.

Bu yaklaşım ilk sızmayı mutlaka önlemez. İzin verilen bir bağlantı üzerinden uygulama açığının kullanılmasını veya ele geçirilmiş bir hesabın mevcut yetkilerini kötüye kullanmasını da tek başına engellemez. Bu nedenle tasarım, ağ erişimini kimlik doğrulama, yetkilendirme, güvenli yapılandırma ve tehdit izleme ile birlikte ele almalıdır.

Zero Trust mimarisi rehberi, daha geniş güvenlik modelini açıklar. Mikrosegmentasyon o modelin tamamı değil, kaynaklar arasındaki erişim ilişkilerini daraltmaya yardımcı olan bir kontrol alanıdır. NIST, Zero Trust yaklaşımında güveni yalnızca ağ konumu veya varlık sahipliğine dayandırmamayı vurgular.

Başarıyı güvenlik bölgesi sayısıyla ölçmeyin. Daha fazla bölge, gerekçesiz ve geniş izinlerle birbirine bağlanmışsa önemli erişim yolları değişmemiş olabilir. Değerlendirmenin birimi, korunacak kaynak ve doğrulanmış iletişim ihtiyacı olmalıdır.

Yatay hareket ve saldırının etki alanı neden önemlidir?

Yatay hareket - lateral movement, saldırganın erişim kazandığı bir sistemden diğer kaynaklara ilerlemesidir. Bir web sunucusunun ele geçirilmesiyle bütün veri merkezinin ele geçirilmesi aynı olay değildir. İkisi arasındaki farkı, erişilebilen sistemler ve kullanılabilen kimlikler belirler. Mikrosegmentasyon, bu ilerlemenin ağ üzerinden gerçekleşebileceği gereksiz bağlantıları daraltmaya odaklanır.

Saldırının etki alanı için kullanılan blast radius kavramı da bu ayrımı anlatır. Web katmanının ödeme altyapısı, insan kaynakları sistemi ve yedekleme yönetimine doğrudan ulaşması gerekmiyorsa, bu erişimlerin açık kalması iş ihtiyacından kaynaklanmayan bir risk oluşturur.

Bununla birlikte erişim yolu azaltımı ile toplam risk azalması aynı ölçüm değildir. İzin verilen bir uygulama bağlantısı üzerinden kötüye kullanım devam edebilir. Bu nedenle mikrosegmentasyonun başarısı, başka güvenlik katmanlarını gereksiz hale getirdiği iddiasıyla değil, belirli erişim ilişkilerini gerçekten daralttığı kanıtıyla değerlendirilmelidir.

North-south ve east-west trafik neden ayrı değerlendirilir?

North-south trafik, seçilen ortam sınırına giriş ve çıkışları; east-west trafik ise o ortam içindeki bileşenler arasındaki iletişimi ifade etmek için kullanılır. Bu terimlerin anlamı mimaride hangi sınırın esas alındığına bağlıdır. Bir ortamın dış bağlantısı, daha büyük hibrit mimarinin iç bağımlılığı olabilir.

Bir müşteri isteğinin web katmanına gelmesi ile web katmanının veri tabanına bağlanması aynı güvenlik ilişkisi değildir. Benzer şekilde yedekleme yöneticisinin korunan sisteme erişimi ile çalışanların yedekleme konsoluna erişimi ayrı tasarlanmalıdır.

Müşterinin web katmanına erişimi, web katmanının uygulama servisini çağırması ve uygulamanın veri tabanına bağlanması farklı kontrol soruları doğurur. İlkinde yayımlanmış giriş noktasına erişim, ikincisinde gerekli servis bağlantısı, üçüncüsünde ise ağ izniyle birlikte veri tabanı yetkisi değerlendirilir. Yönetici erişimi bunların dışında, ayrıcalıklı bir yönetim yolu olarak tasarlanmalıdır.

Bir güvenlik duvarının üzerinden geçmeyen trafik, o cihazın kurallarıyla denetlenmez. Aynı fiziksel sunucudaki sanal makinelerin veya farklı konteynerlerin gerçek trafik yolunu doğrulayın. Mimari çizimde bir güvenlik cihazının bulunması, her bağımlılık için etkin bir kontrol noktası bulunduğunu göstermeyebilir.

VLAN, klasik segmentasyon ve mikrosegmentasyon arasındaki fark nedir?

VLAN, ağın mantıksal bölümlere ayrılmasında kullanılabilir; ancak hangi kaynağın hangi uygulamaya erişeceği ayrıca politika gerektirir. Klasik segmentasyon ve mikrosegmentasyon birbirini dışlamaz. Geniş güvenlik bölgeleri ile daha ayrıntılı iş yükü kontrolleri aynı mimaride birlikte kullanılabilir.

“VLAN gereksizdir” veya “ajan kurulmadan mikrosegmentasyon yapılamaz” gibi kesin yargılar doğru bir seçim çerçevesi oluşturmaz. Kontrolün nerede uygulandığı, ne kadar ayrıntılı olduğu ve hangi trafik yollarını kapsadığı belirleyicidir. Teknoloji seçmeden önce korunacak iletişim ilişkilerini tanımlayın.

Zero Trust, iş yükü kimliği ve en az yetki nasıl birleşir?

İnsan kullanıcı kimliği ile uygulama veya servis kimliği aynı şey değildir. Bir yöneticinin çok faktörlü kimlik doğrulama kullanması, iki sunucu arasındaki servis hesabının yetkilerini kendiliğinden daraltmaz. Ağ politikası, kimlik doğrulama ve uygulama yetkilendirmesi birlikte fakat ayrı kontrol katmanları olarak tasarlanmalıdır.

İş yükü kimliği, değişen IP adreslerinden bağımsız bir kimlik modeli kurmaya yardımcı olabilir. SPIFFE gibi yaklaşımlar, yazılım sistemleri arasında doğrulanabilir kimliklerin oluşturulması için bir çerçeve sunar. Bunun uygulanması; kimliğin nasıl verildiği, yenilendiği ve güven alanlarının nasıl yönetildiği gibi ek kararlar gerektirir.

Bir bağlantının kurulabilmesi, bağlantı üzerinden her işlemin yapılabileceği anlamına gelmemelidir. Sipariş servisinin veri tabanına erişimi gerekli olabilir; ancak aynı servis hesabının bütün tabloları değiştirmesi veya yönetici işlemi yapması gerekli olmayabilir. Mikrosegmentasyon ağ yolunu sınırlar; veri ve uygulama yetkileri kendi katmanında daraltılır.

Politika kararlarını üreten yönetim bileşenleri ile trafiğe fiilen izin veren veya engelleyen uygulama noktalarını da ayırın. Kontrol panelindeki istenen politika ile iş yükünde etkin politika aynı olmayabilir. Dağıtım başarısı, sürüm uyumu ve politika güncelliği ölçülmelidir.

Etiket ile doğrulanmış iş yükü kimliği aynı şey değildir

Etiketler, IP adresi değişen iş yüklerini uygulama, ortam veya görev gibi anlamlı gruplarda toplamak için kullanılabilir. Ancak role=database-client etiketinin bulunması, iş yükünün kriptografik olarak doğrulanmış bir kimliğe sahip olduğu anlamına gelmez. Etiketi hangi sistemin ürettiği ve kimin değiştirebildiği güvenlik tasarımının parçasıdır.

Bir kullanıcı kendi iş yüküne daha geniş erişim sağlayan etiketi atayabiliyorsa, etiket tabanlı politika beklenen sınırı korumayabilir. Bu nedenle etiket ve politika değişiklikleri için yetkilendirme, onay ve kayıt mekanizmaları tanımlanmalıdır. Yeni veya sınıflandırılamayan iş yüklerinin nasıl ele alınacağı da başlangıçta belirlenmelidir.

Mikrosegmentasyon hangi katmanlarda uygulanabilir?

Tek bir uygulama modeli bütün ortamlar için uygun değildir. Aşağıdaki seçenekler birlikte de kullanılabilir. Tablo, ürün yeteneklerini garanti etmez; pilot sırasında doğrulanması gereken değerlendirme sorularını gösterir.

AWS security group kuralları ilişkili kaynakların izin verilen giriş ve çıkış trafiğini kontrol eder. Azure NSG kuralları ise öncelik sırasıyla değerlendirilen izin ve engelleme kuralları kullanır. Aynı görünen bir politika niyetini, farklı ürünlere kopyalarken değerlendirme sırası ve varsayılan davranışın eşdeğer olduğunu varsaymayın.

Seçim için yalnızca normal trafik performansını ölçmek yeterli değildir. Kural dağıtım süresi, bağlantı sayısı, değişiklik sıklığı, desteklenen protokoller ve yönetim bileşeni kesildiğinde davranış da test planına eklenmelidir.

Default deny ve izin listesi nasıl uygulanır?

Default deny, açıkça izin verilmeyen iletişimin reddedilmesi yaklaşımıdır. Mikrosegmentasyonda hedef, her kaynağın her yere ulaşabildiği bir yapı yerine, doğrulanmış iş ihtiyaçlarının izin listesiyle tanımlanmasıdır. Ancak bu hedefe ulaşmak ile üretim ortamındaki bütün bağlantıları bir anda kapatmak aynı şey değildir.

Önce gerekli bağımlılıklar doğrulanmalı, yönetim yolu korunmalı ve pilotun geri dönüş yöntemi hazırlanmalıdır. Ürün bir izleme veya simülasyon modu sunuyorsa, bu modun hangi kuralları değerlendirdiği ve hangi davranışları temsil etmediği anlaşılmalıdır. Gözlemde sorun görünmemesi, henüz çalıştırılmamış bir dönemsel işin sorunsuz kalacağını kanıtlamaz.

İzinler değerlendirilirken hem kaynağın çıkışı hem hedefin girişi düşünülmelidir. Durum bilgili - stateful kontrollerde izin verilmiş bir bağlantının yanıt trafiği ayrıca geniş bir ters yön kuralı gerektirmeyebilir. Buna karşılık hedefin bağımsız olarak başlattığı yeni bağlantı farklı bir ilişkidir. Bu ayrımı kullanılan kontrolün gerçek davranışı üzerinden doğrulayın.

Dışa giden trafik - egress neden gözden kaçırılmamalıdır?

Yalnızca gelen bağlantıları sınırlamak, iş yükünün hangi dış servislere ulaşabildiği sorusunu açık bırakabilir. Uygulama güncellemeleri, dış API'ler, DNS, sertifika doğrulama ve telemetri aktarımı gibi gerekli çıkışlar belirlenmeli; iş ihtiyacı bulunmayan erişimler ayrıca değerlendirilmelidir. Ağ çıkışı kontrolü veri sızıntısı riskini azaltmaya katkı sağlayabilir, ancak izinli bir hedef üzerinden uygunsuz veri kullanımını tek başına önlemez.

Platform servislerinin istisnaları da önemlidir. Örneğin AWS security group kontrolleri sağlayıcının DNS ve instance metadata trafiği dahil belirli platform bağlantılarını filtrelemez. Bu nedenle "egress kuralı yazdık, bütün çıkışlar kontrol altında" sonucu çıkarılmamalıdır. Gerekli ek kontroller sağlayıcı dokümantasyonu ve uygulama bağımlılıkları üzerinden belirlenmelidir.

Politika yazmadan önce bağımlılık haritası nasıl çıkarılır?

Gözlemlenen trafik, gerekli trafikle aynı şey değildir. Akış kayıtları mevcut davranışı gösterir; eski entegrasyon, yanlış yapılandırma veya şüpheli iletişim de bu davranışın parçası olabilir. Keşif sonucunu doğrudan izin listesine çevirmek mevcut riskleri kalıcılaştırabilir.

Bağımlılık haritası; uygulama sahibi, işlev, ortam, veri kritiklik düzeyi, kaynak ve hedef, iletişim yönü, protokol, servis hesabı ve erişim gerekçesini içermelidir. Aktif sistem envanteri, uygulama dokümantasyonu, akış gözlemleri ve sahip onayı birlikte kullanılmalıdır.

Özellikle DNS, saat senkronizasyonu, kimlik servisleri, sertifika doğrulama, yedekleme, izleme, lisans ve güncelleme bağlantılarını inceleyin. Günlük iş akışı çalışırken aylık kapanış, dönemsel raporlama veya kurtarma süreci başarısız olabilir. Tek bir kısa gözlem dönemi bütün gereksinimleri temsil etmeyebilir.

Loglama altyapısı, olayların ve bağlantı ihtiyaçlarının incelenmesini destekler. Ancak her reddedilen bağlantıyı otomatik olarak açmak da her görülen bağlantıyı kalıcı izin kabul etmek de doğru yaklaşım değildir. Sahibi veya gerekçesi bulunamayan ilişkileri ayrı değerlendirme kuyruğuna alın.

Haritayı tek seferlik proje çıktısı olarak bırakmayın. Uygulama devreye alma, taşınma, ölçekleme ve kapatma süreçlerinde güncellenecek bir operasyon kaydı haline getirin. Yeni iş yükünün etiketsiz gelmesi veya eski kaynağın adının yeniden kullanılması gibi durumlar için kabul kuralları tanımlayın.

İyi bir erişim politikası hangi bilgileri içermeli?

İyi politika; kimin, nereye, hangi iş için, hangi koşulla ve ne kadar süreyle erişebileceğini açıklayabilmelidir. Ağ seviyesinde “kim” bilgisi kaynak grubu veya güvenilir iş yükü bağlamıyla temsil edilebilir. Uygulama ve kimlik seviyesindeki kontroller ayrıca korunmalıdır.

Bu matris bir üretim kural seti değildir. Gerçek portlar, akış yönleri, dönüş trafiği, servis keşfi ve ürün gereksinimleri ortamınıza göre belirlenmelidir. Ayrıca her politika için sahip, onaylayan, değişiklik kaydı, test sonucu ve yeniden değerlendirme tarihi bulunmalıdır.

“Geçici” istisnanın yalnızca açıklamasına bu kelimeyi yazmak yeterli değildir. Süre bitiminde nasıl kaldırılacağı, iş etkisini kimin kontrol edeceği ve uzatmanın nasıl onaylanacağı belli olmalıdır. Politika borcu, süresi dolmuş ama yaşamaya devam eden izinlerde birikir.

Politikalar nasıl sürdürülebilir hale getirilir?

Uygun araçlarda politika tanımlarını sürüm kontrolünde tutmak, değişiklikleri gözden geçirmek ve izinli/izinsiz bağlantı testlerini dağıtım sürecine eklemek yararlıdır. Bu yaklaşım, kimin hangi erişimi neden açtığının izlenmesini kolaylaştırır. DevSecOps çerçevesinde ağ politikaları da uygulama değişiklikleriyle birlikte test edilebilir.

Otomasyonun varlığı doğru politika anlamına gelmez. Üretimde yapılan acil değişikliğin daha sonra otomasyon tarafından eski haline döndürülmesi veya aynı erişimin iki farklı sistemde çelişkili yönetilmesi mümkündür. Bu nedenle tek bir onaylı politika kaynağı, kontrollü acil müdahale süreci ve sonradan kayıtların uzlaştırılması gerekir.

Kubernetes NetworkPolicy ne sağlar, ne sağlamaz?

NetworkPolicy, destekleyen bir ağ uygulamasıyla Pod iletişimini sınırlamak için kullanılan Kubernetes kaynağıdır. Kaynağın oluşturulması tek başına yeterli değildir; seçilen ağ eklentisinin politikayı uygulaması gerekir. Standart politikalar izinleri birleşim halinde toplar. Daha dar yeni bir politika, başka politikadaki geniş izni otomatik olarak geçersiz kılmaz.

Namespace oluşturmak da kendi başına ağ izolasyonu sağlamaz. Çok kiracılı ortamda ağ politikalarının yanında RBAC, iş yükü güvenliği ve kaynak ayrımları değerlendirilmelidir. Bir namespace'in varlığını tamamlanmış güvenlik sınırı olarak sunmayın.

Aşağıdaki YAML yalnızca laboratuvar örneğidir; doğrudan üretime uygulanmamalıdır. Önceden oluşturulmuş lab-data namespace'indeki app: orders-db etiketli Pod'lara, lab-apps namespace'indeki app: orders-api etiketli Pod'lardan TCP 5432 erişimi için bir ingress izni tanımlar. Ağ eklentisinin NetworkPolicy desteği ve örnekteki etiketler önceden doğrulanmalıdır.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-orders-api-to-db
  namespace: lab-data
spec:
  podSelector:
    matchLabels:
      app: orders-db
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: lab-apps
          podSelector:
            matchLabels:
              app: orders-api
      ports:
        - protocol: TCP
          port: 5432

Bu politika seçtiği hedef Pod'larda ingress izolasyonu başlatır. Dolayısıyla bu Pod'lara başka kaynaklardan gereken iletişimler de etkilenebilir. Kümenin tamamını izole etmez; hedef Pod'ların dışa giden trafiğini sınırlamaz. NetworkPolicy modelinin node ve hostNetwork gibi özel trafik durumları ayrıca değerlendirilmelidir.

Aynı from öğesindeki namespace ve Pod seçicileri birlikte eşleşmelidir. Bu örnek küme genelinde bir engelleme politikası değildir; egress'i sınırlamaz, şifreleme sağlamaz ve uygulama kimliğini doğrulamaz. Başka bir izin politikası erişimi genişletebilir. Kaynak Pod'un egress'i ayrıca sınırlandırılmışsa o tarafta da uygun izin gerekir.

Uygulamadan önce namespace ve etiketleri doğrulayın; değişiklik yetkilerini sınırlayın. İzinli ve izinsiz kaynaklardan yeni bağlantıları ayrı test edin. Daha sonra DNS, izleme ve diğer bağımlılıkların etkisini inceleyin. Kubernetes'in politika tanımlama rehberi, değişikliğin bağlantı davranışıyla doğrulanmasını örnekler.

Pod ve Service ilişkisini daha geniş çerçevede incelemek için Kubernetes mimarisi rehberine bakabilirsiniz. Standart NetworkPolicy, HTTP yolu veya veri tabanı sorgu yetkisi gibi uygulama işlemlerini tek başına belirlemez; bu ihtiyaçlar uygun uygulama ve yetkilendirme kontrolleriyle ele alınmalıdır.

mTLS, service mesh, NGFW, VDOM ve WAF nasıl konumlanır?

mTLS, iki taraflı kimlik doğrulama ve şifreli iletişim için kullanılabilir. Ancak şifreli bir bağlantı, her isteğin yetkili olduğu anlamına gelmez. Service mesh içindeki kimlik doğrulama ve yetkilendirme politikalarının ayrı değerlendirilmesi gerekir. Istio'nun güvenlik modeli bu ayrımı açık biçimde ele alır.

Güvenlik duvarı ve uygulama giriş katmanı

Yeni nesil güvenlik duvarı - NGFW, üzerinden geçen akışlar üzerinde ağ ve desteklediği uygulama kontrollerini uygular. WAF ise web uygulamasına gelen isteklerin güvenlik değerlendirmesine odaklanır. Her iki bileşen yararlı olabilir; ancak iç veri tabanı, yönetim veya yedekleme erişimlerinin otomatik olarak sınırlandığı varsayılmamalıdır.

API Gateway, API trafiğinde yönlendirme ve ortak politikaların uygulanmasını sağlar. Bir isteğin gateway'den geçmiş olması, arka plandaki her servisin diğer bütün kaynaklara erişmesini gerektirmez. Giriş katmanındaki kontroller ile servisler arasındaki erişim politikaları birlikte tasarlanmalıdır.

Service mesh ve VDOM

Service mesh, kapsama alınan servislerde kimlik ve istek düzeyindeki yetkilendirmeyi destekleyebilir. Ancak ağa veya mesh kapsamına alınmamış bileşenlere ilişkin güvenlik sonucunu kendiliğinden belirlemez. Kullanılan modelin hangi trafiği gerçekten denetlediği açıkça gösterilmelidir.

Fortinet VDOM, bir FortiGate üzerinde ayrı güvenlik politikalarıyla çalışan sanal güvenlik alanları oluşturma yaklaşımıdır. İlgili çalışma modunda yönlendirme ve VPN yapılandırmaları da ayrılabilir. Bu yetenek belirli bir segmentasyon tasarımını destekler; fakat bir VDOM oluşturmakla bütün uygulama ilişkilerinin iş yükü düzeyinde sınırlandığı söylenemez.

Ürün adından değil, test edilmiş iletişim ilişkisinden hareket edin. “Bu erişim engelleniyor” iddiası için ilgili kaynak, hedef, protokol, politika noktası ve test sonucu gösterilebilmelidir.

Hibrit bulut ve üçüncü taraf erişimleri nasıl yönetilir?

Hibrit bulut ortamlarında aynı politika niyeti farklı teknolojilerle uygulanabilir. Şirket içindeki bir kaynak grubu, özel bulutta etiketle, başka ortamda güvenlik grubu veya ağ politikasıyla temsil edilebilir. Önemli olan aynı kural metnini kopyalamak değil, aynı izin ve engelleme sonuçlarını doğrulamaktır.

Adres çakışmaları, NAT, yük dengeleyiciler ve ara bağlantılar nedeniyle uygulama noktasında görülen kaynak, çizimdeki kaynaktan farklı olabilir. Kuralları yalnızca teorik adres planına göre yazmayın. Gerçek akışın giriş ve çıkış noktalarını, dönüş yolunu ve yönetim erişimini test edin.

Üçüncü taraf destek ekibine geniş ağ erişimi vermek yerine görev, hedef, onaylı zaman aralığı ve kimlik koşullarını belirleyin. Destek oturumu bittikten sonra yetkinin nasıl kaldırılacağını açıklayın. Acil durum erişimi için de ayrı bir süreç, kayıt ve sonradan inceleme gerekir.

Özel bulut hizmetleri değerlendirilirken yalnızca ayrılmış kaynaklara değil, yönetim erişimlerine ve sorumluluk sınırlarına bakılmalıdır. Ağın özel olması, içindeki her bağlantının gerekli ve güvenli olduğu anlamına gelmez.

Yedekleme ve felaket kurtarma için hangi erişimler korunmalı?

Üretim, yedekleme yönetimi ve kurtarma ortamı aynı erişim alanı olarak değerlendirilmemelidir. Tasarımın amacı gerekli veri koruma işlemlerini sürdürürken gereksiz yönetim yollarını azaltmaktır. Yedekleme yazılımının bağlantı yönleri ve bağımlılıkları ürüne göre değişebilir; varsayılan bir port listesi evrensel değildir.

Yedekleme başarılıyken geri dönüş başarısız olabilir. Kurtarma ortamı DNS, kimlik, sertifika, lisans, ağ yönlendirmesi veya yönetim bileşenine ihtiyaç duyabilir. Bu ilişkileri yalnızca normal çalışma döneminde gözlemleyerek tamamlanmış kabul etmeyin.

DRaaS ve felaket kurtarma rehberi, iş yükünün yeniden çalışır hale getirilmesi perspektifini tamamlar. RPO ve RTO hedefleri belirlenirken güvenlik politikalarının kurtarma sırasına etkisi de test edilmelidir. Bir erişimi daraltmak kurtarma adımını uzatıyorsa bu etki ölçülmeli ve tasarım kararı olarak değerlendirilmelidir.

İzole kurtarma alanı kullanılıyorsa doğrulama tamamlanmadan üretimle geniş bağlantı açmayın. Politika yedekleri, erişim yetkileri ve yeniden kurulum bağımlılıkları da kurtarma planına dahil edilmelidir. Veri kopyasının varlığı ile çalışır ve güvenli bir kurtarma süreci aynı şey değildir.

Immutable backup ile mikrosegmentasyon da farklı sorunları ele alır. İlki uygun saklama ve kilit politikalarıyla yedek kopyasının değiştirilmesini sınırlar; ikincisi bu veriye ve yönetim katmanına ulaşabilen ağ yollarını daraltır. İkisi birlikte kullanılabilir, ancak hiçbiri temiz ve çalışır bir geri dönüşü test etme ihtiyacını ortadan kaldırmaz.

Görünürlük ve alarm yönetimi mikrosegmentasyonu nasıl tamamlar?

Politika yalnızca izin ve engelleme üretmemeli; değişikliklerin iş etkisi de izlenebilmelidir. Gerekli veriler arasında uygulanan kural sürümü, kaynak ve hedef bağlamı, bağlantı sonucu, uygulama hata oranı ve politika değişiklik kaydı bulunabilir.

Reddedilen bağlantı her zaman saldırı değildir. Eski bir servis adresi, yanlış DNS cevabı, unutulmuş izleme kontrolü veya uygulama güncellemesi aynı belirtiyi oluşturabilir. Buna karşılık bağlantının izinli olması, üzerindeki davranışın meşru olduğunu da kanıtlamaz. Akış sonucu ile uygulama ve kimlik kayıtları birlikte değerlendirilmelidir.

Politika değişikliği sonrası oluşan hataları uygulama sürümleriyle aynı zaman çizgisinde inceleyin. Ajanın çalışmaması, etkin politikanın eskimesi veya log akışının kesilmesi ayrı uyarılar üretmelidir. Kontrol sistemi veri gönderemediği için “hiç ihlal yok” sonucu çıkarılmamalıdır.

Günlük sorumluluklar, yönetilen altyapı ve izleme hizmetleri görüşmesinde açıkça tanımlanmalıdır. Kural öneren, onaylayan, uygulayan ve olay sırasında geri alan tarafların kim olduğu önceden bilinmelidir.

Örnek senaryo: Bir web sunucusu ele geçirilirse ne değişir?

Bu senaryo kurgusaldır ve bir güvenlik sonucu garantisi değildir. Bir sipariş uygulamasında web katmanı, sipariş API'si, veri tabanı ve yedekleme yönetimi bulunduğunu düşünelim. Başlangıçta aynı üretim ortamındaki kaynaklar arasında geniş ağ erişimi vardır. Web katmanının yalnızca sipariş API'sini çağırması gerekirken veri tabanı yönetimine ve yedekleme konsoluna da bağlantı kurulabilmektedir.

Bağımlılık incelemesinden sonra web katmanının uygulama API'sine, API'nin ilgili veri tabanına ve onaylı yönetim noktasının gerekli yönetim arayüzlerine erişmesi yeterli bulunur. Yedekleme ve izleme bağlantıları ayrıca tanımlanır. Politikalar sınırlı bir pilotta uygulandığında web katmanından veri tabanına doğrudan başlatılan yeni bağlantının reddedildiği, normal sipariş işleminin ise çalışmaya devam ettiği doğrulanır.

Bu değişiklik, ele geçirilmiş web sunucusunun izin verilmeyen hedeflere ağ üzerinden doğrudan ulaşmasını zorlaştırır. Buna rağmen web katmanının erişmesine izin verilen sipariş API'sindeki bir açık veya aşırı yetkili servis hesabı risk oluşturmaya devam edebilir. Bu nedenle ağ politikasıyla birlikte API yetkilendirmesi, servis hesabı hakları, yama yönetimi ve olay izleme korunmalıdır.

Aynı pilotta aylık raporlama ve geri yükleme gibi daha seyrek işlemler de denenmelidir. Günlük sipariş akışının çalışması, uygulamanın bütün işletim senaryolarının tamamlandığı anlamına gelmez. İyi bir mikrosegmentasyon projesi hem gereksiz erişimin kapandığını hem gerekli işin sürdüğünü kanıtlar.

İş kesintisi riskini azaltan geçiş planı nasıl hazırlanır?

Bir bütün olarak “her şeyi engelle” yaklaşımı yerine gözlem, politika modelleme, kontrollü pilot ve kademeli yaygınlaştırma sırası önerilir. Gözlem veya simülasyon modunun varlığı ve neyi gerçekten simüle ettiği ürüne göre doğrulanmalıdır.

Keşif ve politika modelleme

Önce pilot uygulama, sahipler ve bağımlılıklar belirlenir. Gözlemlenen iletişim, uygulama sahibinin onayıyla gerekli erişim matrisine dönüştürülür. Bu aşamanın çıktısı çok sayıda otomatik kural değil; gerekçesi, istisnası, test yöntemi ve geri dönüş planı bulunan bir politika tasarımıdır.

Sınırlı uygulama ve kabul testi

Politika önce kontrollü iş yüklerinde uygulanır. Gerekli işlemlerin çalışması kadar, engellenmesi hedeflenen yeni bağlantıların gerçekten reddedilmesi de test edilir. Sağlık kontrolleri, yeni oturum açma, yeniden başlatma, dönemsel işler ve yedekten dönüş gibi senaryolar birlikte ele alınır.

Kademeli yaygınlaştırma ve sürekli işletim

Kapsam uygulama grupları halinde genişletilir. Her grup için etkin politika, izleme ve sorumluluk kabulü tamamlanmadan sonraki aşamaya geçilmez. Üretimdeki işletim; süresi geçen istisnaların, kullanılmayan kuralların, etiketsiz iş yüklerinin ve beklenen sürümden sapmış uygulama noktalarının düzenli incelenmesini kapsar.

İlk pilot için kurumun en kritik ve en bilinmeyen uygulamasını seçmek zorunlu değildir. İş değeri olan, bağımlılıkları anlaşılabilir ve geri dönüşü yönetilebilir bir alan daha iyi öğrenme sağlayabilir. Takvimi standart bir süreye zorlamak yerine aşama çıkış ölçütlerini esas alın.

Geri dönüş planı yalnızca eski kural dosyasını saklamak değildir. Kural dağıtımı başarısız olursa hangi erişim yolundan müdahale edileceği, kimlik servisleri etkilenirse nasıl yönetileceği ve otomasyonun acil değişikliği geri yazıp yazmayacağı da önceden belirlenmelidir.

Kontrol bileşeni veya ajan arızalanırsa ne olur?

Yönetim katmanının kesilmesi, uygulama noktasının kesilmesi ve politika güncelliğinin kaybolması farklı arıza durumlarıdır. Bir çözüm mevcut kuralla çalışmaya devam edebilir; başka bir durumda bağlantı kabulü veya reddi farklılaşabilir. Davranışı ürüne, sürüme ve yapılandırmaya göre test edin.

Yönetim bağlantısı kesildiğinde son geçerli politikanın çalışmaya devam edip etmediği ve yeni oluşturulan iş yüklerinin nasıl ele alındığı araştırılmalıdır. Ajan veya trafik uygulama noktası durduğunda ise bağlantıların açık mı kapalı mı kaldığı ayrıca doğrulanmalıdır. Yönetim ekranına erişememek ile trafiği kontrol edememek aynı arıza değildir.

Yanlış etiket veya kaynak grubu, teknik olarak başarıyla dağıtılmış bir politikanın yanlış kapsamda uygulanmasına yol açabilir. Geri dönüş testinde de yalnızca eski kuralın yüklendiğini görmek yeterli değildir; yeni bağlantılar, mevcut oturumlar ve yönetim erişimi ayrı kontrol edilmelidir.

Örneğin Azure NSG belgeleri, mevcut bağlantıların kural değişikliğinden sonra devam edebileceğini ve yeni bağlantıların yeni kuralla değerlendirildiğini açıklar. Bu nedenle mevcut bir oturumu kullanarak “engel çalışmıyor” veya “politika başarılı” sonucuna varmayın; ilgili teknolojinin oturum davranışını doğrulayın.

“Arızada açık kalmak” ile “arızada kapalı kalmak” seçeneklerini yalnızca güvenlik sloganıyla seçmeyin. İş etkisi, kontrolün rolü, yönetim erişimi ve kurtarma kapasitesi birlikte değerlendirilmelidir. Son geçerli kuralla çalışma da ayrıca politika eskimesi riski taşır.

Mikrosegmentasyonun başarısı nasıl ölçülür?

Kural sayısı, güvenlik etkinliğinin doğrudan ölçüsü değildir. Çok kural, daha iyi koruma kadar karmaşıklık da anlamına gelebilir. Ölçüm için önceden tanımlı kapsam, test edilmiş erişim ilişkileri ve operasyonel sonuçlar gerekir.

Örnek olarak, aynı test kümesinde gereksiz olduğu belirlenmiş 100 erişim ilişkisinin 80'i artık yeni bağlantı kuramıyorsa, test edilen ilişkilerde yüzde 80 azalma raporlanabilir. Bu, kurumun saldırı riskinin yüzde 80 düştüğü anlamına gelmez. Risk; kimlikler, açıklıklar, veri değeri ve test edilmeyen yollar dahil daha geniş etkenlere bağlıdır.

Çözüm ve hizmet sağlayıcı seçiminde ne sorulmalı?

Teklifleri sadece korunan sunucu başına fiyatla karşılaştırmayın. Keşif, ajan yaşam döngüsü, entegrasyon, log hacmi, politika yönetimi, test ve sürekli operasyon maliyetini birlikte değerlendirin. Gereksiz karmaşıklık, güvenlik ekibinin günlük değişikliklere yetişmesini zorlaştırabilir.

İlk olarak desteklenen işletim sistemi, sanallaştırma ve konteyner ortamları gerçek pilotla doğrulanmalıdır. Çözümün politikayı nerede uyguladığı, hangi trafiği göremediği ve platform güncellemesinden sonra nasıl desteklendiği açıkça gösterilmelidir. Ürün sunumundaki genel uyumluluk ifadesi, kendi uygulamanızın çalışacağını tek başına kanıtlamaz.

Ardından günlük işletim soruları gelir: Bağımlılığı kim onaylıyor, değişikliği kim dağıtıyor, gece oluşan uygulama hatasını kim araştırıyor ve acil geri dönüş yetkisi kimde? Sağlayıcıdan bu işlerin örnek süreç ve test kayıtları istenmelidir. Kural yazma hizmeti ile sürekli uygulama güvenliği yönetiminin aynı kapsam olduğu varsayılmamalıdır.

Çıkış planı da satın alma değerlendirmesine dahil edilmelidir. Politikaların, bağımlılık haritasının ve değişiklik geçmişinin dışa aktarılabilmesi önemlidir; fakat bir üründeki kuralın diğerinde aynı sonucu vereceği ayrıca test edilir. Tedarikçi bağımlılığı yalnızca lisans değil, yıllar içinde oluşan politika bilgisinin taşınabilirliğiyle de ilgilidir.

NIST'in uygulama çalışmaları da Zero Trust'ı birden fazla bileşenin birlikte çalıştığı mimari olarak ele alır. Bu nedenle tek ürünün bütün kontrol alanlarını kapsadığı varsayımı yerine entegrasyon ve test kanıtı aranmalıdır.

Performans ve toplam maliyet nasıl değerlendirilmelidir?

Bir çözümün performansını yalnızca paket aktarım hızıyla değerlendirmeyin. Normal ve tepe yükte uygulama gecikmesi, eşzamanlı bağlantı sayısı, CPU ve bellek kullanımı, yeni politika dağıtım süresi ve log hacmi birlikte ölçülmelidir. Aynı kural setinin eski bir sanal makineyle yoğun konteyner ortamında aynı operasyon sonucunu vereceği varsayılmamalıdır.

Toplam maliyete lisansın yanında keşif, entegrasyon, eğitim, değişiklik onayı, test ve devam eden politika temizliği de dahildir. Evrensel bir tasarruf veya performans etkisi yüzdesi yerine, pilot öncesi ve sonrasında aynı iş yükünü karşılaştırın. İşletim kapasitesinin üzerinde ayrıntı üretmek, korumanın sürdürülebilirliğini zayıflatabilir.

Her ortamda aynı mikrosegmentasyon yaklaşımı uygulanmalı mı?

Hayır. Az sayıda, iyi ayrılmış ve değişimi düşük bir sistem için mevcut kontrolleri iyileştirmek yeterli olabilir. Büyük ve dinamik bir ortamda ise yalnızca elle yönetilen adres listeleri sürdürülemez hale gelebilir. Doğru ayrıntı düzeyi, risk ve işletim kapasitesiyle birlikte belirlenmelidir.

Eski veya hassas sistemlerde ajan uyumluluğu, performans etkisi ve destek koşulları doğrulanmalıdır. Üretim teknolojisi veya güvenlik açısından kritik fiziksel süreçlere bağlı sistemlerde ağ değişikliğinin etkisini ilgili mühendislik ve üretici ekipleriyle değerlendirin. Kurum genelinde tek bir araç zorunluluğu, her iş yükünün teknik gerçekliğine uygun olmayabilir.

Temel envanteri olmayan bir ortamda doğrudan ayrıntılı engelleme başlatmak yerine keşif ve sahiplik sorununu çözün. Hazırlık ihtiyacı mikrosegmentasyondan vazgeçmek değil, uygulama sırasını doğru seçmek için bir işarettir.

Ixpanse ile erişim yollarını ve güvenlik kapsamını değerlendirin

Ixpanse'in Veri Koruma hizmet sayfasında yönetilen güvenlik duvarı ve kimlik doğrulama gibi güvenlik bileşenleri yer alır. Yönetilen Hizmetler ve Özel Bulut sayfaları ise altyapı işletimi ve ayrılmış kaynak ihtiyaçlarının değerlendirilmesi için ilgili hizmet bağlantılarıdır.

İş yükü bazlı politika, desteklenen uygulama noktaları, Kubernetes ağ politikası, uygulama bağımlılığı keşfi ve değişiklik yönetimi kapsamı proje özelinde doğrulanmalıdır. Yönetilen güvenlik duvarı bulunması, bütün ortamlarda hazır bir mikrosegmentasyon platformu sunulduğu anlamına gelmez.

Başlangıç sorusu “kaç güvenlik kuralımız var?” değil, “kritik sistemimize gerçekten kimler ulaşabiliyor?” olmalıdır. Kritik sistemleriniz arasındaki erişim yollarını, güvenlik duvarı politikalarını ve hibrit altyapınızın segmentasyon ihtiyaçlarını Ixpanse ekibiyle değerlendirin.

Sonuç: Daha fazla kural değil, gerekçesi olan erişim

Mikrosegmentasyonun değeri, bir iş yükünün yalnızca görevini yerine getirmek için ihtiyaç duyduğu kaynaklara erişebilmesidir. VLAN, güvenlik duvarı, kimlik doğrulama ve uygulama yetkilendirmesiyle birlikte çalışır; bunların yerine geçen tek bir ürün değildir.

Doğru başlangıç, bağlantıları rastgele kapatmak değil, hangi iletişimin neden gerekli olduğunu ortaya koymaktır. Bu bilgi doğrulanmış politikaya, kontrollü uygulamaya ve düzenli testlere dönüştüğünde hem güvenlik hem işletim ekipleri aynı erişim modelini yönetebilir. Kurumun sorması gereken soru yalnızca "hangi yolları kapattık?" değil, "gereksiz erişimi azaltırken gerekli işin sürdüğünü nasıl kanıtlıyoruz?" olmalıdır.