Firewall tek başına yeterli mi?

İnternet sınırındaki güvenlik duvarı doğru yapılandırılmış olabilir; buna rağmen çalınmış bir kullanıcı hesabı, zararlı bir e-posta eki veya güvenlik açığı bulunan bir iç uygulama işletmeyi etkileyebilir. Bunun nedeni güvenlik duvarının gereksiz olması değil, her kontrolün belirli bir trafik ve davranış alanını görmesidir.

Güvenlik tasarımında soru “hangi cihaz en güçlü?” ile sınırlı kalmamalıdır. Hangi riski nerede önlüyoruz, önleyemediğimizi nasıl fark ediyoruz ve olay olduğunda kim müdahale ediyor? Ağ geçidi, uç nokta, kimlik, e-posta, uygulama ve yedekleme kontrolleri bu sorular üzerinden birlikte ele alınır.

1. Güvenlik duvarının koruduğu alanı doğru tanımlayın

Bir güvenlik duvarı, üzerinden geçen trafiği tanımlanan politika ve desteklediği inceleme özelliklerine göre değerlendirir. Kaynak, hedef, port, uygulama veya kullanıcı bilgisi gibi unsurlar ürüne ve yapılandırmaya bağlı olarak kullanılabilir. Paket filtreleme, durum takibi, uygulama kontrolü ve saldırı önleme aynı işlev değildir. NIST’in güvenlik duvarı politikası rehberi bu nedenle cihazla birlikte politika tasarımını da ele alır.

Ofisten doğrudan bir bulut hizmetine bağlanan yönetilmeyen cihazın davranışı ya da iki iç sunucu arasındaki trafik her zaman internet sınırındaki cihazdan geçmez. Trafiğin nerede sonlandığını ve hangi kontrol noktasından geçtiğini topoloji üzerinde göstermek gerekir. Koruma değerlendirmesi, satın alınan özellik listesinden önce gerçek trafik yoluyla başlar.

2. İç ağdaki yayılımı segmentasyonla sınırlayın

Kullanıcı bilgisayarları, sunucular, misafir ağı, yönetim arayüzleri ve üretim sistemleri aynı erişim alanındaysa bir uç noktadaki olay çok sayıda hedefe ulaşabilir. VLAN kullanmak mantıksal ayrım sağlar; fakat ağlar arasındaki yönlendirme her erişime izin veriyorsa güvenlik sınırı oluşmuş sayılmaz. Bölgeler arasındaki erişim kuralları da tanımlanmalıdır.

Örnek bir politika, kullanıcıların uygulama sunucusuna gereken servis üzerinden ulaşmasına izin verirken veritabanına doğrudan erişimini sınırlar. Yönetim işlemleri ayrı bir yönetim yolu üzerinden yürütülür. Uygulama sunucusundan veritabanına gereken erişim ayrıca tanımlanır. Bu tasarımın çalışabilmesi için mevcut bağımlılıklar öğrenilmeli; kurallar önce kontrollü biçimde test edilmelidir.

Tablonun tamamı için yana kaydırabilirsiniz.

3. Kimlik ve uç nokta, ağ kontrolünün tamamlayıcısıdır

Geçerli bir hesaptan yapılan oturum, ağ seviyesinde izin verilen bir bağlantı olarak görünebilir. Bu nedenle çok faktörlü doğrulama, gereksiz ayrıcalıkların kaldırılması ve oturum davranışının incelenmesi gerekir. Kullanıcının cihazı ve hesabı farklı olaylardan etkilenebilir; erişim kararı bu iki durumu birlikte değerlendirmelidir.

NIST SP 800-207, bir kaynağın yalnız iç ağda bulunmasına dayanarak güven verilmemesini temel alır. Bu yaklaşım tek bir ürün satın almakla uygulanmış olmaz; kimlik, cihaz ve kaynak erişimi için politika gerektirir. Zero Trust mimarisi.

Uç noktada ise süreç ağacı, şüpheli dosya davranışı ve hesap kullanımı gibi sinyaller incelenebilir. EDR, bu davranışları araştırmayı ve desteklenen durumlarda yanıt vermeyi kolaylaştırır. Ancak ajan kurulu olmayan veya desteklenmeyen cihazlar ayrı ele alınmalıdır. Bir lisansın varlığıyla bütün varlıkların görünür olması aynı şey değildir.

4. Şifreli trafik incelemesini kapsamıyla değerlendirin

TLS ile şifrelenen bir bağlantıda görülebilen bilgiler, kullanılan inceleme yöntemine göre değişir. İçeriğin çözümlenmediği bir bağlantıda güvenlik ürünü bütün uygulama içeriğini okuyamaz. Öte yandan TLS incelemesi etkinleştirmek de tek başına bütün trafiğin çözüleceği anlamına gelmez; sertifika sabitleme, uygulama uyumluluğu ve istisnalar devreye girebilir.

Bir tasarımda sertifika dağıtımı, kapsam dışında tutulacak uygulamalar, performans ve mahremiyet gereksinimleri birlikte değerlendirilir. Değişiklik pilot cihazlarda sınanır. Güvenlik özellikleri açıkken oluşan işlem yükü ölçülmeden yalnız katalogdaki ham trafik değeri üzerinden kapasite seçmek yanıltıcı olabilir. İşletmenin aynı anda kullandığı bağlantı ve uygulama profili önemlidir.

5. Kuralların yaşam döngüsü ve cihazın kendi devamlılığı

Bir kuralın neden açıldığı, sahibi ve gözden geçirme tarihi bilinmiyorsa yıllar içinde gereksiz erişimler birikir. Geçici destek erişimleri, artık kullanılmayan NAT kayıtları ve geniş kaynak aralıkları düzenli incelenmelidir. Değişiklik öncesi yapılandırma sürümü ile sonrasındaki doğrulama sonucu birlikte tutulur.

Güvenlik duvarı işletmenin bağlantı noktasıysa kendi arızası da iş sürekliliğini etkiler. Yedekli cihaz tasarımında yalnız ikinci donanım değil, bağlantılar, güç beslemesi, durum eşitleme ve yönlendirme davranışı kontrol edilir. Devralma sırasında bütün oturumların korunacağı varsayılmamalıdır; kullanılan protokoller ve platformun yetenekleri test edilir. Koruma ve erişilebilirlik aynı mimarinin iki gereksinimidir.

6. Alarmdan müdahaleye uzanan zinciri kurun

Günlüklerin merkezi bir noktaya gönderilmesi, analiz yapılacağı anlamına gelmez. Zaman senkronizasyonu, doğru ayrıştırma, veri kaynağı kesintisinin takibi ve anlamlı tespit kuralları gerekir. Bir hesabın beklenmeyen yerden giriş yapmasıyla aynı cihazdaki şüpheli davranışın ilişkilendirilmesi, ayrı konsollarda görülen iki sinyalden daha açıklayıcı olabilir.

Olay oluştuğunda kimin inceleme yapacağı, hesabın veya cihazın hangi koşulda sınırlandırılacağı ve iş birimine nasıl haber verileceği önceden belirlenir. NIST’in olay müdahalesi rehberi, hazırlık ile tespit ve yanıt işlerinin risk yönetimi içinde yürütülmesini ele alır. Teknik ürünlerin çıktısı bu operasyon düzenine bağlanmalıdır.

Son değerlendirmede firewall, uç nokta, kimlik, e-posta, uygulama, yedekleme ve operasyon için ayrı kapsam soruları sorun. Eksik bir katmanı tamamlamak, aynı katmana bir ürün daha eklemekten daha yararlı olabilir. İhtiyaç, ürün sayısını artırmak değil; kritik iş süreçleri boyunca koruma, görünürlük ve müdahale boşluklarını azaltmaktır.

Sık sorulan sorular

İlgili hizmetler ve rehberler