Azure Local projelerinde güvenlik tarafında karşılaştığımız önemli konulardan biri, mevcut Windows Server ve Hyper-V güvenlik alışkanlıklarının yeni platforma doğrudan uygulanmaya çalışılması.
Örneğin bir kurumun yıllardır kullandığı Windows Server hardening politikaları olduğunu düşünelim. Sunucular domaine alınıyor, ilgili OU altına taşınıyor, Group Policy uygulanıyor, güvenlik yazılımları yükleniyor ve kurumun standart güvenlik konfigürasyonu devreye giriyor.
Bu yaklaşım klasik Windows Server ortamlarında oldukça doğal.
Ancak Azure Local tarafında durum biraz farklı.
Çünkü Azure Local, üzerine işletim sistemi kurduğumuz ve istediğimiz güvenlik politikalarını uyguladığımız standart bir Hyper-V cluster değil. Microsoft, Azure Local’ın güvenlik konfigürasyonunu ürünün kendisinin bir parçası olarak tasarlıyor.
Dolayısıyla burada önemli bir değişiklik var.
Azure Local’da güvenlik, kurulum sonrasında eklediğimiz bir özellik değil, platformun varsayılan çalışma modelinin bir parçası.
Microsoft bu yaklaşımı Secure-by-Default olarak tanımlıyor. Azure Local, 300’den fazla güvenlik ayarı etkin şekilde kuruluyor ve bu ayarlar belirli bir security baseline oluşturuyor.
Ancak bence burada asıl önemli konu güvenlik ayarlarının varsayılan olarak açık olması değil.
Bu ayarların zaman içerisinde nasıl korunduğu.
Çünkü güvenli bir sunucu kurmak ile o sunucunun üç yıl boyunca aynı güvenlik seviyesinde kalmasını sağlamak birbirinden farklı işler.
Özellikle Azure Local gibi sürekli güncellenen, farklı node’ların beraber çalıştığı ve altyapı yönetiminin Azure üzerinden gerçekleştirildiği sistemlerde security configuration drift önemli bir operasyonel risk.
Bu makalede Azure Local’ın Secure-by-Default yaklaşımını, security baseline ve drift control mekanizmalarını, Application Control, BitLocker, VBS ve Trusted Launch özelliklerini gerçek operasyonel karşılıklarıyla inceleyelim.
Secure-by-Default tam olarak ne anlama geliyor?
Klasik bir Windows Server kurulumunda işletim sistemi kurulduktan sonra genellikle ayrı bir hardening süreci çalıştırıyoruz.
Gereksiz servisleri kapatıyoruz.
Eski protokolleri devre dışı bırakıyoruz.
Güvenlik politikalarını uyguluyoruz.
Credential Guard, BitLocker veya diğer koruma mekanizmalarını ihtiyaca göre etkinleştiriyoruz.
Azure Local tarafında ise Microsoft bu işlemlerin önemli bir bölümünü ürünün başlangıç konfigürasyonuna dahil etmiş durumda.
Platformun güvenlik yaklaşımı birkaç temel katmandan oluşuyor.
İlk katman security baseline.
İkinci katman bu ayarların korunmasını sağlayan drift control.
Üçüncü katman işletim sistemi ve donanım seviyesinde çalışan VBS, Credential Guard, HVCI ve diğer Secured-core özellikleri.
Dördüncü katman Application Control.
Beşinci katman ise BitLocker, SMB signing ve SMB encryption gibi veri koruma mekanizmaları.
Bunların üzerinde Azure Policy, Microsoft Defender for Cloud ve merkezi monitoring gibi yönetim ve görünürlük servisleri bulunuyor.
Burada önemli olan bütün bu özelliklerin tek başına çalışması değil, birbirini tamamlaması.
Örneğin BitLocker veriyi disk üzerinde koruyor.
Application Control yetkisiz kodların çalıştırılmasını sınırlandırıyor.
Credential Guard kimlik bilgilerinin korunmasına yardımcı oluyor.
Drift control ise belirli güvenlik ayarlarının zaman içerisinde değiştirilmesini engellemeye çalışıyor.
Ancak bunların hiçbiri tek başına bütün güvenlik problemlerini çözmüyor.
Özellikle Azure Local host güvenliği ile üzerinde çalışan VM’lerin güvenliğini birbirinden ayırmak gerekiyor.
Azure Local’ın security baseline’ı fiziksel node’ların ve platformun güvenlik konfigürasyonunu koruyor.
VM içerisindeki işletim sistemi, uygulama, kullanıcı hesapları ve veritabanı güvenliği ise ayrıca yönetilmeli.
Bence bu ayrım production projelerinde özellikle önemli.
Çünkü Azure Local güvenli kuruldu diye üzerinde çalışan 100 sanal makinenin de otomatik olarak güvenli olduğunu söyleyemeyiz.
Security Baseline ve Drift Control
Azure Local güvenlik mimarisinin bence en önemli özelliklerinden biri drift control.
Configuration drift aslında yeni bir kavram değil.
Özellikle büyük Windows Server ortamlarında yıllardır karşılaştığımız bir problem.
Bir sunucunun güvenlik ayarlarını belirli bir standarda göre yapılandırıyorsunuz.
Aradan birkaç ay geçiyor.
Bir uygulama çalışmadığı için administrator bir ayarı değiştiriyor.
Başka bir administrator troubleshooting sırasında farklı bir güvenlik özelliğini kapatıyor.
Üçüncü bir ekip kendi güvenlik politikasını uyguluyor.
Sonuçta başlangıçta aynı şekilde kurulmuş sunucuların konfigürasyonları zaman içerisinde birbirinden farklı hale geliyor.
Azure Local bu problemi drift control mekanizmasıyla azaltmaya çalışıyor.
Microsoft’un güncel dokümantasyonuna göre drift control etkin olduğunda koruma altındaki güvenlik ayarları 90 dakikalık aralıklarla yeniden değerlendiriliyor ve gerekli durumlarda başlangıçta tanımlanan güvenli duruma getiriliyor.
Bu oldukça önemli.
Örneğin dört node’lu bir Azure Local ortamınız olduğunu düşünelim.
Bir administrator troubleshooting amacıyla Node02 üzerinde baseline tarafından korunan bir güvenlik ayarını değiştirdi.
Değişiklik o anda uygulanmış olabilir.
Ancak drift control etkinse ilgili ayar sonraki değerlendirme döngüsünde tekrar beklenen güvenlik konfigürasyonuna dönebilir.
Bu davranışın iki farklı sonucu var.
Birincisi güvenlik açısından olumlu.
Çünkü yetkisiz veya yanlışlıkla yapılan değişikliklerin kalıcı hale gelmesini zorlaştırıyor.
İkincisi operasyon açısından dikkat edilmesi gereken bir durum.
Çünkü administrator yaptığı değişikliğin neden tekrar eski haline döndüğünü anlamayabilir.
Bence Azure Local troubleshooting sırasında özellikle bilinmesi gereken konulardan biri bu.
Drift control tarafından korunan bir ayarı manuel değiştirmek, kalıcı bir konfigürasyon değişikliği yapmak anlamına gelmiyor.
Burada başka bir ayrıntı daha var.
Drift control bütün Windows ayarlarını korumuyor.
Microsoft tarafından tanımlanan security baseline içerisindeki belirli korumalı ayarları yönetiyor. Kuruma bırakılmış bazı ayarlar ise bu mekanizmanın dışında bulunabiliyor.
Örneğin minimum password length bunlardan biri.
Microsoft’un güncel Azure Local security baseline dokümantasyonunda minimum password length için 14 karakter beklentisi bulunuyor. Ancak ilgili ayarın kurum politikalarına göre belirlenebilmesi için drift control tarafından korunmadığı belirtiliyor.
Dolayısıyla sistemde drift control açık olması bütün güvenlik ayarlarının otomatik olarak doğru olduğu anlamına gelmiyor.
Bu ayrım önemli.
Drift Control nasıl yönetiliyor?
Azure Local üzerinde security baseline ve drift control işlemleri için Microsoft’un AzureStackOSConfigAgent bileşeni kullanılıyor.
Bu bileşenle gelen PowerShell komutları sayesinde mevcut güvenlik durumunu görüntüleyebiliyor ve desteklenen özelliklerde değişiklik yapabiliyoruz.
Örneğin Get-AzsSecurity komutu ile ilgili güvenlik özelliğinin durumunu kontrol edebiliyoruz.
Enable-AzsSecurity ve Disable-AzsSecurity komutları ise desteklenen güvenlik özelliklerini etkinleştirmek veya devre dışı bırakmak için kullanılıyor.
Burada Local ve Cluster kapsamları bulunuyor.
Local seçeneği sadece ilgili node üzerinde işlem gerçekleştirirken Cluster seçeneği orchestrator üzerinden cluster genelinde işlem yapılmasını sağlıyor.
Bu ayrım özellikle production ortamında önemli.
Dört node’lu bir Azure Local cluster’ında sadece bir node üzerinde güvenlik ayarını değiştirmek ile bütün cluster üzerinde değiştirmek aynı şey değil.
Örneğin drift control’u kapatmak için desteklenen komutlardan biri:
Disable-AzsSecurity -FeatureName DriftControl -Cluster
Ancak bu komutu burada özellikle dikkat çekmek için paylaşıyorum.
Production ortamında sadece bir ayarı değiştirmek amacıyla cluster genelinde drift control’u kapatmak benim önereceğim bir yaklaşım değil.
Çünkü drift control kapatıldığında koruma altındaki güvenlik ayarları değiştirilebilir hale geliyor.
Daha önemlisi, drift control tekrar etkinleştirildiğinde korumalı ayarlarda yaptığınız değişiklikler security baseline tarafından yeniden uygulanabiliyor.
Dolayısıyla geçici olarak drift control’u kapatmak gerekiyorsa bunun kontrollü bir change management süreci içerisinde yapılması gerekiyor.
Hangi ayar değiştirilecek?
Bu değişiklik neden gerekli?
Microsoft tarafından destekleniyor mu?
Cluster genelinde mi yoksa tek node üzerinde mi uygulanacak?
İşlem sonrasında drift control tekrar etkinleştirilecek mi?
Bunları önceden belirlemek gerekiyor.
Ayrıca bazı güvenlik özelliklerinin etkinleştirilmesi veya devre dışı bırakılması reboot gerektirebiliyor.
Bu nedenle security configuration değişikliklerini sıradan bir registry değişikliği gibi değerlendirmemek gerekiyor.
Group Policy tarafında dikkat edilmesi gerekenler
Bence Azure Local kurulumlarında güvenlik ekipleriyle en fazla koordinasyon gerektiren konulardan biri Active Directory ve Group Policy tasarımı.
Bir kurumun bütün Windows Server sistemlerine uyguladığı standart GPO’lar olabilir.
Ancak bu politikaların Azure Local fiziksel node’larına kontrolsüz şekilde uygulanması doğru değil.
Çünkü Azure Local’ın kendi security baseline’ı, lifecycle management mekanizması ve platform konfigürasyonu bulunuyor.
Kurumsal GPO ile Azure Local’ın beklediği güvenlik konfigürasyonu arasında çakışma oluşabilir.
Örneğin bir GPO belirli bir güvenlik ayarını zorunlu hale getirirken Azure Local baseline farklı bir değer bekliyor olabilir.
Bu durumda Group Policy ile drift control aynı ayarı farklı değerlere getirmeye çalışabilir.
Sonuçta sadece compliance problemi değil, platform operasyonlarını etkileyebilecek bir konfigürasyon problemi de yaşayabilirsiniz.
Microsoft’un Azure Local mimari önerilerinde Active Directory tabanlı deployment için dedicated OU kullanılması ve Group Policy inheritance’ın engellenmesi özellikle belirtiliyor.
Bunun amacı Azure Local node’larını güvenlik politikalarından tamamen muaf tutmak değil.
Platformun kendi güvenlik modelini koruyarak kurumsal gereksinimleri desteklenen yöntemlerle uygulamak.
Bence burada yapılması gereken şey güvenlik ekibinin hazırladığı mevcut Windows Server GPO’larını doğrudan Azure Local’a uygulamak yerine ilgili politikaları Azure Local security baseline ile karşılaştırmak.
Hangi ayarlar zaten platform tarafından korunuyor?
Hangi ayarlar kurumun sorumluluğunda?
Hangi ayarlar Microsoft tarafından değiştirilmemesi gereken platform konfigürasyonları?
Bu ayrımı deployment öncesinde yapmak gerekiyor.
Özellikle domain hardening konusunda Azure Local node’larını sıradan member server olarak değerlendirmemek önemli.
Application Control neden önemli?
Azure Local güvenlik mimarisinin diğer önemli bileşeni Application Control.
Microsoft burada Windows Defender Application Control, yani WDAC teknolojisini kullanıyor.
Application Control’un amacı fiziksel Azure Local node’ları üzerinde hangi uygulamaların ve sürücülerin çalıştırılabileceğini kontrol etmek.
Bu özellik Azure Local üzerinde varsayılan olarak etkin.
Application Control iki temel çalışma moduna sahip.
Audit Mode ve Enforcement Mode.
Audit Mode kullanıldığında güvenilmeyen uygulama veya kod çalıştırılabiliyor ancak ilgili olaylar loglanıyor.
Enforcement Mode kullanıldığında ise güvenlik politikasına uygun olmayan kodların çalıştırılması engelleniyor.
Microsoft production ortamlarında Enforcement Mode kullanılmasını öneriyor.
Bence bu özellik özellikle Azure Local’ın klasik Windows Server’dan ayrıldığı önemli noktalardan biri.
Çünkü Azure Local host’ları genel amaçlı uygulama sunucuları değil.
Üzerlerine her türlü üçüncü parti yazılımın kurulması beklenmiyor.
Örneğin bir monitoring veya backup ürünü kurmak istediğinizi düşünelim.
Ürün Azure Local üzerinde destekleniyor olabilir.
Ancak bu, ilgili yazılımın Application Control politikaları tarafından otomatik olarak çalıştırılmasına izin verileceği anlamına gelmiyor.
Microsoft bu tür durumlar için supplemental policy oluşturulmasını destekliyor.
Yani güvenlik mekanizmasını tamamen kapatmak yerine ihtiyaç duyulan yazılım için kontrollü izin tanımlanabiliyor.
Bu bence doğru yaklaşım.
Çünkü bir yazılım çalışmıyor diye bütün Application Control mekanizmasını Audit Mode’a geçirmek veya devre dışı bırakmak gereksiz risk oluşturabilir.
Özellikle production Azure Local ortamlarında üçüncü parti yazılım uyumluluğunu kurulumdan önce kontrol etmek gerekiyor.
Burada benim yaklaşımım şu olurdu:
Önce yazılım üreticisinin Azure Local desteğini doğrularım.
Ardından Microsoft’un Application Control uyumluluğunu kontrol ederim.
Gerekliyse test ortamında Audit Mode ile uygulamanın davranışını incelerim.
Supplemental policy oluşturur ve test ederim.
Sonrasında Enforcement Mode’a geri dönerim.
Böylece platformun güvenlik modelini bozmadan gerekli yazılımı çalıştırabiliriz.
Burada önemli olan Application Control’un troubleshooting sırasında geçici olarak gevşetilebilmesi değil, production ortamının kalıcı olarak hangi modda çalıştığı.
BitLocker ve veri koruma
Azure Local üzerinde veri güvenliğinin diğer önemli katmanı BitLocker.
Storage Spaces Direct makalesinde verinin farklı node’lara nasıl dağıtıldığını, mirror ve parity modellerini ve disk arızalarında sistemin nasıl davrandığını incelemiştik.
Ancak Storage Spaces Direct resiliency ile BitLocker farklı problemleri çözüyor.
Storage Spaces Direct verinin fiziksel altyapı arızalarına karşı erişilebilir kalmasını sağlamaya çalışıyor.
BitLocker ise verinin disk üzerinde şifreli tutulmasını sağlıyor.
Azure Local’ın varsayılan güvenlik konfigürasyonunda işletim sistemi ve deployment sırasında oluşturulan veri volume’ları için BitLocker koruması bulunuyor.
Özellikle Cluster Shared Volume üzerinde tutulan VM dosyalarının şifrelenmesi önemli.
Ancak burada dikkat edilmesi gereken bir konu var.
BitLocker’ın etkin olması recovery key yönetiminin önemini ortadan kaldırmıyor.
Tam tersine recovery key’lerin doğru şekilde saklanması kritik hale geliyor.
Microsoft, Azure Local BitLocker recovery key’lerinin sistemin dışında güvenli bir lokasyonda saklanmasını öneriyor.
Çünkü bütün cluster’a erişimi kaybettiğiniz bir senaryoda recovery key’lerin de aynı cluster içerisinde tutulması size yardımcı olmayabilir.
Örneğin storage veya cluster seviyesinde ciddi bir arıza yaşadınız.
Diskler fiziksel olarak sağlam.
Ancak BitLocker recovery key’lerine erişemiyorsunuz.
Bu durumda verinin fiziksel olarak mevcut olması tek başına yeterli değil.
Şifreli veriye erişebilmek için recovery material gerekiyor.
Bence Azure Local disaster recovery planında recovery key yönetimi mutlaka ayrı bir başlık olmalı.
Bir diğer önemli konu da mevcut bir CSV üzerinde BitLocker’ı sonradan etkinleştirmek.
Microsoft’un güncel BitLocker yönetim dokümantasyonuna göre bu işlem sırasında ilgili CSV geçici olarak maintenance moduna alınabiliyor ve üzerinde çalışan VM’ler pause durumuna geçebiliyor.
Şifreleme başlatıldıktan sonra volume tekrar erişilebilir hale geliyor ancak şifreleme tamamlanana kadar redirected I/O nedeniyle performans etkisi oluşabiliyor.
Dolayısıyla production ortamında BitLocker’ı sonradan etkinleştirmek sıradan bir checkbox değişikliği değil.
Planlı maintenance gerektirebilen bir storage operasyonu.
Bu nedenle mümkün olduğunca deployment sırasında varsayılan şifreleme ayarlarının korunmasını daha doğru buluyorum.
SMB Signing ve SMB Encryption aynı şey değil
Azure Local storage network güvenliğinde dikkat edilmesi gereken başka bir konu da SMB trafiği.
Önceki network makalesinde SMB Direct, RDMA ve SMB Multichannel özelliklerini performans açısından incelemiştik.
Ancak SMB trafiğinin güvenlik tarafı da var.
Burada iki kavramı birbirinden ayırmak gerekiyor.
SMB Signing ve SMB Encryption.
SMB Signing, SMB iletişiminin bütünlüğünü ve kimliğini doğrulamaya yardımcı oluyor.
SMB Encryption ise iletilen verinin gizliliğini koruyor.
Yani SMB Signing etkin olması trafiğin şifrelendiği anlamına gelmiyor.
Microsoft Azure Local güvenlik ayarlarında external SMB signing ve cluster içerisindeki SMB encryption özelliklerini ayrı güvenlik kontrolleri olarak tanımlıyor.
Burada özellikle RDMA kullanılan ortamlarda performans ve güvenlik etkilerini beraber değerlendirmek gerekiyor.
SMB encryption etkinleştirmek veri güvenliği açısından önemli olabilir ancak kullanılan donanım, network adapter özellikleri ve SMB sürümüne bağlı olarak performans üzerindeki etkisinin doğrulanması gerekiyor.
Ben production ortamında bu ayarları sadece güvenlik kontrol listesindeki bir maddeyi karşılamak için değiştirmeyi doğru bulmuyorum.
Önce kullanılan Azure Local sürümünün desteklediği güvenlik konfigürasyonunu kontrol etmek gerekiyor.
Ardından network ve storage performansının etkilenip etkilenmediği ölçülmeli.
Çünkü Azure Local’da storage network yalnızca iki sunucu arasındaki sıradan dosya paylaşım trafiği değil.
VM’lerin storage erişimini doğrudan etkileyen kritik bir altyapı bileşeni.
Trusted Launch ile VM güvenliği
Şimdiye kadar daha çok Azure Local fiziksel node’larının güvenliğini konuştuk.
Ancak Azure Local üzerinde çalışan VM’lerin de güvenlik mimarisinin önemli bir parçası olması gerekiyor.
Microsoft bu noktada Trusted Launch özelliğini sunuyor.
Trusted Launch, Azure Local VM enabled by Azure Arc modeliyle oluşturulan desteklenen sanal makinelerde kullanılabilen bir güvenlik tipi.
Temelinde Secure Boot ve virtual Trusted Platform Module, yani vTPM bulunuyor.
Secure Boot, sanal makinenin açılış sürecinde kullanılan bileşenlerin güvenilir imzalarla doğrulanmasına yardımcı oluyor.
Bu sayede bootkit ve rootkit gibi işletim sistemi başlamadan önce devreye girmeye çalışan zararlı yazılımlara karşı ek koruma sağlanıyor.
vTPM ise sanal makineye sanallaştırılmış TPM yeteneği kazandırıyor.
Bu bileşen anahtarların, sertifikaların ve açılış sürecine ilişkin güvenlik ölçümlerinin korunmasında kullanılabiliyor.
Burada dikkat edilmesi gereken nokta Trusted Launch’ın sadece Secure Boot özelliğini açmak anlamına gelmemesi.
Secure Boot ve vTPM beraber çalışarak VM’nin açılış bütünlüğünü daha güvenilir hale getiriyor.
Ayrıca guest işletim sisteminde Virtualization-Based Security, yani VBS özelliklerinin kullanılabilmesi için gerekli altyapıyı sağlayabiliyor.
Örneğin Windows Server üzerinde Credential Guard veya HVCI gibi özelliklerden faydalanmak istediğinizde bu güvenlik mekanizmalarının ihtiyaç duyduğu sanallaştırma yetenekleri önemli hale geliyor.
Ancak Trusted Launch etkinleştirildi diye guest işletim sistemindeki bütün VBS özelliklerinin otomatik olarak yapılandırıldığını düşünmemek gerekiyor.
Guest tarafındaki güvenlik konfigürasyonu ayrıca doğrulanmalı.
Microsoft’un güncel Azure Local dokümantasyonunda Trusted Launch için Secure Boot, vTPM, vTPM state transfer ve VBS desteği tanımlanıyor.
Boot integrity verification özelliği ise Preview olarak belirtiliyor.
Bu ayrım önemli.
Çünkü Trusted Launch’ın temel koruma mekanizmaları ile bunların üzerinde çalışan guest attestation özellikleri aynı olgunluk seviyesinde olmayabilir.
Production ortamında hangi özelliğin GA, hangisinin Preview olduğunu ayrı ayrı kontrol etmek gerekiyor.
Trusted Launch ve Live Migration
Trusted Launch konusunda bence en önemli teknik ayrıntılardan biri vTPM state transfer.
Klasik bir Hyper-V VM’yi düşünelim.
VM bir node üzerinde çalışıyor.
Cluster maintenance nedeniyle VM’yi başka bir node’a taşıyoruz.
VM’nin memory ve execution state bilgileri yeni node’a aktarılıyor.
Ancak Trusted Launch kullanılan VM’de buna ek olarak vTPM state’in de korunması gerekiyor.
Çünkü vTPM içerisindeki güvenlik bilgileri VM’nin çalışmasının bir parçası.
Microsoft, Azure Local Trusted Launch mimarisinde VM migration veya failover sırasında vTPM state’in otomatik olarak taşınmasını destekliyor.
Bu özellik önemli.
Çünkü Trusted Launch kullanıyoruz diye cluster’ın yüksek erişilebilirlik özelliklerinden vazgeçmek istemiyoruz.
Ancak burada başka bir güvenlik ayrıntısı bulunuyor.
Microsoft’un güncel Trusted Launch dokümantasyonu, VM Live Migration network trafiğinin bu özellik tarafından otomatik olarak şifrelenmediğini belirtiyor.
Bu nedenle Live Migration trafiğinin korunması için IPsec gibi network seviyesinde şifreleme yöntemleri öneriliyor.
Bence bu çok önemli bir ayrım.
Bir VM’nin Secure Boot ve vTPM kullanması, o VM ile ilgili bütün yönetim ve migration trafiğinin otomatik olarak şifrelendiği anlamına gelmiyor.
Güvenlik mimarisinde her katmanın hangi riski çözdüğünü ayrı ayrı değerlendirmek gerekiyor.
Trusted Launch kullanırken backup tarafını unutmayın
Trusted Launch ile ilgili production ortamında özellikle dikkat edilmesi gereken konulardan biri de backup ve recovery.
Çünkü Trusted Launch kullanılan Azure Local VM’lerde standart VM backup yaklaşımına ek bir gereksinim bulunuyor.
VM Guest State Protection Key.
Microsoft’un güncel dokümantasyonuna göre Trusted Launch VM’lerde guest state ve vTPM state bilgilerini korumak için özel bir protection key kullanılıyor.
Bu anahtar Azure Local instance içerisindeki local key vault üzerinde tutuluyor.
Burada kritik bir problem var.
VM dosyalarını yedeklemiş olmanız, ilgili protection key’e de sahip olduğunuz anlamına gelmiyor.
Microsoft açık şekilde bu anahtar olmadan VM’nin başlatılamayacağını belirtiyor.
Örneğin bir Trusted Launch VM’nin bütün VHDX ve konfigürasyon dosyalarını yedeklediğinizi düşünelim.
Cluster tamamen kaybedildi.
Yeni Azure Local ortamı kurdunuz.
VM dosyalarını geri yüklediniz.
Ancak VM Guest State Protection Key elinizde yok.
Bu durumda disklerin ve VM dosyalarının sağlam olması tek başına yeterli değil.
VM’yi başlatamayabilirsiniz.
Bu nedenle Trusted Launch kullanılan ortamlarda backup tasarımına mutlaka key recovery sürecini de dahil etmek gerekiyor.
Microsoft manuel key backup ve recovery yöntemlerini destekliyor. Ayrıca belirli deployment senaryolarında Azure Key Vault üzerinden otomatik key backup özelliği de bulunuyor ancak bu özellik güncel dokümantasyonda Preview olarak belirtiliyor.
Dolayısıyla sadece otomatik key backup özelliğinin mevcut olduğunu görmek yeterli değil.
Kullanılan sürümde destek durumunu kontrol etmek ve recovery sürecini gerçekten test etmek gerekiyor.
Burada başka bir önemli sınırlama daha var.
Microsoft’un Eylül 2026 tarihli Trusted Launch dokümantasyonunda, farklı bir Azure Local instance üzerine restore edilen Trusted Launch VM’nin Azure Arc control plane üzerinden yönetiminin korunmadığı belirtiliyor. Böyle bir durumda VM lokal yönetim araçlarıyla yönetilebiliyor.
Aynı dokümantasyonda Trusted Launch VM’lerin Azure Site Recovery ile Azure’a replikasyonunun desteklenmediği de belirtiliyor.
Bu nedenle Trusted Launch kararını sadece VM güvenlik özelliklerine bakarak vermemek gerekiyor.
Backup, restore ve disaster recovery gereksinimleriyle beraber değerlendirmek lazım.
Bence production ortamında Trusted Launch kullanmanın en önemli operasyonel şartlarından biri de bu.
Güvenlik özelliğini etkinleştirmek kadar, o güvenlik özelliğiyle korunan sistemi felaket sonrasında geri döndürebilmek de önemli.
Azure Policy ile Security Baseline aynı şey değil
Azure Local güvenliğinde sık karıştırılabilecek başka bir konu Azure Policy ve platform security baseline ilişkisi.
Azure Local’ın kendi security baseline ve drift control mekanizması bulunuyor.
Bunun yanında Azure Policy üzerinden compliance değerlendirmeleri de yapabiliyoruz.
Örneğin AzureWindowsBaseline Machine Configuration policy assignment ile Azure Local fiziksel node’larının belirli güvenlik gereksinimlerine uygunluğu raporlanabiliyor.
Ancak burada çok önemli bir ayrım var.
Compliance raporlamak ile güvenlik ayarını zorunlu olarak uygulamak aynı şey değil.
Microsoft’un Azure Local Well-Architected Framework dokümantasyonu da bu ayrımı özellikle vurguluyor.
AzureWindowsBaseline policy assignment Audit modunda çalışıyor.
Yani ilgili güvenlik ayarlarının durumunu değerlendiriyor ve uyumluluk raporu oluşturuyor.
Ancak bu policy assignment tek başına bütün ayarları otomatik olarak düzeltmiyor.
Drift control ise koruma kapsamındaki platform güvenlik ayarlarının beklenen konfigürasyona dönmesini sağlıyor.
Dolayısıyla iki farklı mekanizmadan bahsediyoruz.
Birisi compliance görünürlüğü sağlıyor.
Diğeri belirli platform ayarlarının korunmasına yardımcı oluyor.
Üstelik Microsoft’un güncel dokümantasyonunda bütün donanım gereksinimlerini karşılayan Secured-core Azure Local host’larında beklenen compliance seviyesinin yüzde 99 olabileceği belirtiliyor.
Bu durum her zaman bir problem olduğu anlamına gelmiyor.
Örneğin bazı ayarlar kurumun kendi güvenlik politikalarına bırakılmış olabilir.
Bu nedenle compliance raporunda yüzde 100 görmüyoruz diye doğrudan bütün ayarları değiştirmek doğru değil.
Önce hangi kontrolün neden uyumsuz göründüğünü anlamak gerekiyor.
Özellikle Azure Local 2604 ve sonrasında Interactive Logon mesaj başlığı ve metni gibi bazı baseline ayarlarının davranışı da değişti.
Bu nedenle compliance değerlendirmesini kullanılan Azure Local sürümüne göre yapmak önemli.
Bence burada asıl hedef yüzde 100 compliance skoruna ulaşmak değil.
Hangi güvenlik kontrolünün kim tarafından yönetildiğini bilmek ve gerçek riskleri ortadan kaldırmak.
Microsoft Defender ve merkezi güvenlik görünürlüğü
Azure Local güvenlik mimarisinin bir diğer parçası monitoring ve threat detection.
Microsoft Defender Antivirus, Azure Local üzerinde varsayılan olarak etkin gelen güvenlik bileşenlerinden biri.
Ancak Azure Local host’ları üzerinde kullanılan güvenlik yazılımlarının platformla uyumlu olması gerekiyor.
Özellikle üçüncü parti endpoint security ürünleri kullanılıyorsa ilgili üreticinin Azure Local desteğinin doğrulanması önemli.
Bunun nedeni sadece Application Control değil.
Storage Spaces Direct, cluster servisleri ve platform management bileşenlerinin çalışma şekli klasik Windows Server ortamlarından farklı olabiliyor.
Bu nedenle rastgele antivirus exclusion tanımlamak veya güvenlik yazılımını zorla kurmak doğru yaklaşım değil.
Microsoft’un desteklediği konfigürasyonların kullanılması gerekiyor.
Azure Local ayrıca security event’lerin merkezi SIEM sistemlerine gönderilmesi için syslog forwarding mekanizması sunuyor.
Bu mekanizma RFC3164 formatındaki syslog mesajlarını CEF payload ile iletebiliyor.
Böylece fiziksel Azure Local node’larından gelen güvenlik olaylarını kurumun merkezi SIEM sistemine aktarabiliyoruz.
Bence özellikle büyük Azure Local ortamlarında bu özellik önemli.
Çünkü 20 farklı Azure Local cluster’ınız varsa güvenlik ekibinin her node’a ayrı ayrı bağlanıp event log incelemesi gerçekçi değil.
Merkezi monitoring gerekiyor.
Ancak syslog forwarding etkinleştirmek tek başına yeterli değil.
Logların gerçekten SIEM’e ulaştığını doğrulamak gerekiyor.
Hangi olayların toplandığı belirlenmeli.
Log retention politikası hazırlanmalı.
Alarm üretilecek olaylar tanımlanmalı.
Ayrıca log trafiğinin kendisinin de güvenli olması gerekiyor.
Microsoft’un güncel mimari önerilerinde authenticated TLS üzerinden merkezi SIEM’e log aktarılması tavsiye ediliyor.
Bu nedenle sadece syslog portunu açıp log göndermek yerine güvenli iletişim ve sertifika doğrulama mekanizmalarını da tasarlamak gerekiyor.
Özellikle disconnected Azure Local ortamlarında lokal SIEM entegrasyonu daha da önemli hale geliyor.
Çünkü public Azure servislerine bağımlı olmayan bir operasyon modelinde güvenlik olaylarının da lokal olarak izlenebilmesi gerekiyor.
Platform güvenliği ile workload güvenliğini ayırmak gerekiyor
Bence Azure Local güvenlik tasarımının en önemli prensibi bu.
Azure Local platformu Secure-by-Default olabilir.
Drift control etkin olabilir.
BitLocker açık olabilir.
Application Control Enforcement Mode’da çalışıyor olabilir.
Fiziksel node’lar Secured-core gereksinimlerini karşılıyor olabilir.
Ancak bütün bunlar üzerinde çalışan VM’lerin güvenlik yönetimini ortadan kaldırmıyor.
Örneğin bir Windows Server VM üzerinde güncel olmayan bir uygulama bulunuyorsa Azure Local security baseline bu uygulamanın güvenlik açığını kapatmıyor.
Bir VM içerisinde local administrator parolası zayıfsa host seviyesindeki Credential Guard bunu otomatik olarak düzeltmiyor.
Bir uygulama sunucusu internete gereksiz portlar açıyorsa BitLocker bu problemi çözmüyor.
Dolayısıyla Azure Local güvenlik mimarisini iki ayrı katmanda değerlendirmek gerekiyor.
İlk katman platform güvenliği.
Fiziksel node’lar, cluster, storage, management plane ve platform servisleri.
İkinci katman workload güvenliği.
VM işletim sistemleri, uygulamalar, kullanıcı hesapları, network erişimleri ve veriler.
Bu iki katmanın beraber çalışması gerekiyor.
Örneğin Trusted Launch VM’nin boot güvenliğini artırabilir.
Ancak VM içerisindeki Windows Update yönetimi, endpoint protection ve application security yine ayrıca yapılmalı.
Azure RBAC, Azure üzerinden gerçekleştirilen VM yönetim operasyonlarını sınırlandırabilir.
Ancak fiziksel host üzerindeki lokal administrator yetkilerini otomatik olarak ortadan kaldırmaz.
Benzer şekilde BitLocker veriyi disk üzerinde korur.
Ancak çalışan VM içerisindeki verilere erişim yetkilerini yönetmez.
Bu nedenle Azure Local security tasarımını sadece ürün özelliklerinin açık olup olmadığını kontrol ederek tamamlanmış kabul etmemek gerekiyor.
Production Azure Local ortamında güvenliği nasıl yönetirdim?
Ben bir Azure Local projesinde güvenlik tasarımına deployment tamamlandıktan sonra başlamazdım.
Önce kurumun mevcut security baseline’ını incelerdim.
Hangi gereksinimler Azure Local tarafından zaten karşılanıyor?
Hangi gereksinimler kurumun sorumluluğunda?
Hangi mevcut GPO’lar platformla çakışabilir?
Bunları belirlerdim.
Ardından Azure Local’ın kendi security baseline ve drift control mekanizmasını mümkün olduğunca varsayılan konfigürasyonuyla korurdum.
Özellikle Microsoft tarafından korunan güvenlik ayarlarını değiştirmek yerine gerekli istisnaları değerlendirirdim.
Application Control tarafında Enforcement Mode kullanırdım.
Üçüncü parti yazılımlar için supplemental policy sürecini önceden hazırlardım.
BitLocker recovery key’lerini cluster dışında güvenli bir lokasyonda saklardım.
Trusted Launch kullanacağım VM’lerde guest state protection key backup sürecini oluştururdum.
Sadece backup aldığımı değil, gerçekten restore yapabildiğimi doğrulardım.
Security event’leri merkezi SIEM sistemine aktarırdım.
Azure Policy ile compliance durumunu takip ederdim.
Ancak policy compliance raporunu tek güvenlik göstergesi olarak kullanmazdım.
Özellikle firmware ve driver güncellemelerini de güvenlik operasyonunun bir parçası olarak değerlendirirdim.
Çünkü Azure Local güvenliği sadece işletim sistemi ayarlarından oluşmuyor.
Fiziksel donanımın firmware seviyesi, TPM, Secure Boot ve donanım üreticisinin yayınladığı güvenlik güncellemeleri de önemli.
Bu nedenle Microsoft’un desteklediği Azure Local Solution Update ve OEM Solution Builder Extension süreçlerini takip etmek gerekiyor.
Ayrıca bütün bu işlemleri tek seferlik deployment checklist olarak değil, sürekli işletilen bir güvenlik süreci olarak değerlendirirdim.
Çünkü güvenlik ayarlarının bugün doğru olması altı ay sonra da doğru olacağı anlamına gelmiyor.
Microsoft’un Azure Local üzerinde drift control mekanizmasına bu kadar önem vermesinin nedeni de bu.
Bir altyapıyı güvenli kurmak önemli.
Ancak o altyapının güvenli kalmasını sağlamak çok daha önemli.
Azure Local’ın Secure-by-Default yaklaşımı bize güçlü bir başlangıç noktası sunuyor.
Security baseline başlangıç konfigürasyonunu oluşturuyor.
Drift control koruma altındaki ayarların değiştirilmesini zorlaştırıyor.
Application Control yetkisiz kodların çalışmasını sınırlandırıyor.
BitLocker veriyi disk üzerinde koruyor.
Trusted Launch ise desteklenen VM’lerin açılış güvenliğini güçlendiriyor.
Ancak bütün bu özelliklerin beraber çalışması için doğru operasyon modeli gerekiyor.
Bence Azure Local güvenliğinde asıl fark da burada.
Güvenlik sadece hangi özelliklerin açık olduğu değil, bu özelliklerin kim tarafından, hangi süreçle ve ne kadar süre boyunca doğru şekilde yönetildiğiyle ilgili.
Bir sonraki makalede güvenliğin network tarafına geçeceğim. Azure Local SDN, NSG ve Mikro Segmentasyon başlığı altında Azure Local üzerinde Software Defined Networking mimarisini, Network Security Group kullanımını, workload network segmentasyonunu ve özellikle east-west trafiğin nasıl kontrol edilebileceğini inceleyeceğiz.
Çünkü güvenli bir platform kurmak kadar, platform üzerinde çalışan workload’ların birbirleriyle nasıl iletişim kurduğunu kontrol etmek de önemli.
