Ağ Güvenlik Duvarı Kuralları ve Erişim Denetimi

Ağ güvenliğinde küçük görünen bir kural, bazen bütün kurumun erişim modelini değiştirebilir. On yıllık ağ ve güvenlik çalışmaları boyunca en sık karşılaştığım sorun, firewall cihazının yetersiz olması değil, kuralların neden var olduğunun zamanla unutulması oldu. Kaynağı, hedefi, portu, kullanıcıyı ve erişim süresini doğru tanımlamadığınızda güçlü bir güvenlik duvarı bile beklediğiniz korumayı sağlayamaz. Bu nedenle Ağ Güvenlik Duvarı Kuralları ve Erişim Denetimi yalnızca birkaç portu açıp kapatma işi olarak görülmemelidir. Bu rehberde firewall mantığını, ACL yapılandırmasını, ağ segmentasyonunu, NAC yaklaşımını, Zero Trust modelini, günlük kayıtlarını, değişiklik yönetimini ve otomasyonu pratik örneklerle ele alacağız.

Özellikle ağ güvenlik duvarı kuralları nasıl oluşturulur ve yönetilir, firewall erişim kontrol listesi ACL nasıl yapılandırılır ve kurumsal ağlarda firewall rule base least privilege ve erişim politikası yönetimi nasıl uygulanır gibi sorular üzerinde duracağız. Firewall kurallarında port IP VLAN VPN ve kullanıcı bazlı erişim denetimi konularını tek başına değil, birbiriyle ilişkili güvenlik katmanları olarak değerlendireceğiz. Amacımız yalnızca bir bağlantının çalışmasını sağlamak değil, neden çalıştığını ve hangi koşullarda engellenmesi gerektiğini de anlayabilmektir. Gerçek ağlarda erişim kuralları zamanla büyür, bu nedenle başlangıçtan itibaren düzenli ve ölçülebilir bir yapı kurmak önemlidir. Rehberin sonunda kendi ortamınız için uygulanabilir bir firewall ve erişim denetimi yaklaşımı oluşturabilecek temel çerçeveye sahip olacaksınız.

Ağ Güvenlik Duvarı Nedir?

Ağ güvenlik duvarı, farklı ağlar veya güven seviyeleri arasındaki trafiğin belirli kurallara göre geçmesine ya da engellenmesine karar veren güvenlik bileşenidir. Basit bir ev ağında internet ile yerel cihazlar arasında konumlanabilirken kurumsal ortamlarda kullanıcı, sunucu, misafir, üretim, geliştirme ve yönetim ağları arasında birden fazla noktada görev yapabilir. Firewall tasarımında temel soru, hangi cihazın internete çıkacağı değil, hangi kaynağın hangi hedefe hangi amaçla ulaşması gerektiğidir. Bu yaklaşım erişim politikasını teknik kurallardan önce düşünmenizi sağlar. İyi tasarlanmış bir güvenlik duvarı, ağ trafiğini kontrol ederken aynı zamanda olay inceleme ve erişim denetimi için değerli kayıtlar üretir.

Firewall Ne İşe Yarar?

Firewall, izin verilen ve izin verilmeyen ağ iletişimini tanımlayan politikaları uygular. Örneğin muhasebe kullanıcılarının yalnızca belirli uygulama sunucularına ulaşmasına izin verirken aynı kullanıcıların yönetim ağındaki cihazlara erişmesini engelleyebilirsiniz. Bunun yanında internetten yayımlanan bir web servisinin sadece HTTPS bağlantılarını kabul etmesini sağlayabilirsiniz. Benim uygulamalarda öncelik verdiğim nokta, her izin kuralının açık bir iş gerekçesine bağlanmasıdır. Böylece aylar sonra bir kural incelendiğinde neden açıldığı ve hâlâ gerekli olup olmadığı kolayca anlaşılır.

Firewall Hangi Trafiği Kontrol Eder?

Firewall IP adresi, ağ bloğu, port, protokol, uygulama, kullanıcı, cihaz kimliği ve güvenlik bölgesi gibi birçok bilgiyi değerlendirebilir. Eski sistemlerde kontrol çoğunlukla IP ve port seviyesinde yapılırken yeni nesil güvenlik duvarları uygulama ve kullanıcı bağlamını da kullanabilir. Örneğin TCP 443 portunun açık olması, bu porttan geçen her uygulamaya izin verilmesi gerektiği anlamına gelmez. Aynı port üzerinden web taraması, farklı tünel türleri veya çeşitli bulut servisleri kullanılabilir. Bu nedenle erişim kontrolü yapılırken yalnızca port numarasına bakmak yerine trafik bağlamını anlamak daha güvenli sonuç verir.

Inbound ve Outbound Trafik

Inbound trafik bir güvenlik sınırının dışından içine doğru gelen bağlantıları, outbound trafik ise içeriden dışarı doğru başlatılan iletişimi ifade eder. Birçok kurum internetten gelen trafiği sıkı şekilde filtrelerken dışarı çıkan trafiği gereğinden fazla serbest bırakır. Bu yaklaşım zararlı yazılımların komuta sunucularına bağlanmasına veya hassas verilerin dışarı aktarılmasına zemin hazırlayabilir. Sağlıklı bir firewall politikası her iki yönü de kontrol eder ve her bağlantının gerçek ihtiyacını sorgular. Özellikle sunucu ağlarında yalnızca gerekli DNS, güncelleme, API ve servis hedeflerine izin verilmesi etkili bir egress kontrolü sağlar.

North-South ve East-West Trafik

North-South trafik genellikle kurum ağı ile internet veya başka harici ağlar arasındaki iletişimi ifade eder. East-West trafik ise kurum içindeki kullanıcılar, sunucular, sanal makineler, konteynerler ve diğer sistemler arasındaki bağlantıları kapsar. Geleneksel güvenlik tasarımlarında yoğunluk dış sınırda olurken birçok olayda saldırganın asıl hareket alanı iç ağ trafiğidir. Bir uç nokta ele geçirildiğinde sınırsız East-West erişim, başka sistemlere geçişi kolaylaştırabilir. Bu nedenle modern tasarımda iç ağ segmentasyonu ve bölgeler arası firewall kontrolü en az internet sınırı kadar önemlidir.

Firewall ile Router Arasındaki Fark

Router temel olarak paketlerin hangi ağ yolundan gönderileceğine karar verir, firewall ise bu iletişimin güvenlik politikasına uygun olup olmadığını değerlendirir. Bazı ağ cihazları hem routing hem firewall işlevlerini aynı platformda sunabilir, ancak bu iki görevin amacı farklıdır. Routing tablosu genellikle hedef ağa ulaşılabilirliği belirlerken firewall policy o hedefe erişim iznini belirler. Bir ağın route tablosunda bulunması, kullanıcıların o ağa otomatik olarak erişebilmesi gerektiği anlamına gelmez. Tasarım yaparken ulaşılabilirlik ve yetkilendirme kavramlarını ayrı değerlendirmek daha güvenli bir mimari sağlar.

Firewall ile IDS/IPS Arasındaki Fark

Firewall öncelikle erişim politikasını uygular, IDS ve IPS sistemleri ise trafiğin içinde saldırı göstergeleri veya şüpheli davranışlar arar. IDS çoğu durumda bir tehdidi tespit edip uyarı üretirken IPS trafiği aktif olarak durdurabilir. Yeni nesil firewall ürünlerinde IPS özellikleri firewall motoruyla aynı platform içinde çalışabilir. Buna rağmen bir bağlantının izinli olması, içeriğinin güvenli olduğu anlamına gelmez. Bu nedenle erişim denetimi ile tehdit incelemesini birbirini tamamlayan iki güvenlik kontrolü olarak ele almak gerekir.

Firewall Türleri Nelerdir?

Firewall teknolojileri zaman içinde paket başlıklarını kontrol eden basit filtrelerden uygulama ve kullanıcı bağlamını değerlendiren platformlara doğru gelişmiştir. Her firewall türü farklı kullanım alanına, performans beklentisine ve güvenlik ihtiyacına hitap eder. Bir veri merkezinde kullanılan yaklaşım ile küçük bir şube ofisinde veya bulut ortamında kullanılan yaklaşım aynı olmayabilir. Ürün seçiminden önce korunacak veri akışlarını, bağlantı yoğunluğunu, şifreli trafik oranını ve yönetim gereksinimlerini belirlemek gerekir. Teknoloji adı tek başına güvenlik sağlamaz, asıl fark doğru politika ve düzenli yönetimle oluşur.

Packet Filtering Firewall

Packet filtering firewall, paketlerin kaynak ve hedef IP adresi, port numarası ve protokol gibi temel başlık bilgilerini kontrol eder. Bu yöntem hızlıdır ve birçok router ACL uygulamasının temelini oluşturur. Ancak tek tek paketlere bakılması bağlantının genel durumunu anlamayı zorlaştırabilir. Örneğin bir paketin mevcut bir oturuma mı yoksa yeni bir bağlantı girişimine mi ait olduğunu her zaman değerlendiremez. Basit segmentasyon veya belirli yönetim erişimlerini sınırlamak için yararlı olsa da daha kapsamlı koruma için ek kontroller gerekebilir.

Stateless Firewall

Stateless firewall her paketi diğer paketlerden bağımsız olarak değerlendirir. Sistem önceki trafiği veya aktif oturum durumunu hatırlamadığı için dönüş trafiği için ayrıca izin kuralı gerekebilir. Bu yapı yüksek performans sağlayabilir ve basit ağ politikalarında işe yarayabilir. Ancak çok sayıda bağlantının bulunduğu kurumsal ortamlarda kuralların yönetimini zorlaştırabilir. Özellikle dinamik port kullanan protokollerde state bilgisi olmaması ek planlama gerektirir.

Stateful Firewall

Stateful firewall aktif bağlantıları bir state tablosunda takip eder ve paketleri oturum bağlamıyla birlikte değerlendirir. İç ağdan izin verilen bir bağlantı başlatıldığında ilgili dönüş trafiğinin otomatik şekilde eşleştirilmesi mümkün olur. Bu yaklaşım hem kural sayısını azaltabilir hem de beklenmeyen bağlantı girişimlerini daha iyi sınırlayabilir. Kurumsal ağlarda stateful kontrol uzun yıllardır temel güvenlik bileşenlerinden biridir. Yine de state takibi uygulama seviyesindeki riskleri tek başına çözmediği için gerektiğinde ek inceleme özellikleri kullanılmalıdır.

Proxy Firewall

Proxy firewall istemci ile hedef servis arasında doğrudan bağlantı kurmak yerine iletişimi kendi üzerinden sonlandırır ve yeniden başlatır. Bu sayede protokol davranışı ve uygulama içeriği hakkında daha fazla kontrol sağlayabilir. İstemci gerçek hedefle doğrudan oturum oluşturmadığı için belirli güvenlik avantajları elde edilir. Buna karşılık ek işlem yükü performans ve gecikme üzerinde etkili olabilir. Proxy mimarisi özellikle belirli uygulama protokollerinde detaylı denetim gerektiğinde tercih edilebilir.

Next-Generation Firewall (NGFW)

Next-Generation Firewall, klasik IP ve port kontrolünü uygulama tanıma, kullanıcı kimliği, IPS, URL filtreleme ve çeşitli tehdit kontrolleriyle birleştirir. Bu yaklaşım özellikle aynı portu kullanan farklı uygulamaların birbirinden ayrılmasını kolaylaştırır. Örneğin TCP 443 üzerinden çalışan trafiğin yalnızca izin verilen iş uygulamalarına ait olması şartı getirilebilir. Kullanıcı gruplarıyla entegrasyon sayesinde kurallar yalnızca IP adreslerine bağlı kalmaz. Kurumsal firewall yapılandırma ve ağ erişim güvenliği hizmeti tasarlanırken NGFW özelliklerinin iş gereksinimleriyle birlikte değerlendirilmesi yararlı olur.

Web Application Firewall (WAF)

Web Application Firewall, web uygulamalarına yönelen HTTP ve HTTPS trafiğini uygulama katmanında kontrol etmeye odaklanır. Ağ firewall'ı IP ve bağlantı seviyesinde güçlü kontrol sağlarken WAF web isteklerindeki belirli saldırı kalıplarını inceleyebilir. SQL injection veya belirli kötü amaçlı istek örüntüleri bu kapsamda değerlendirilebilir. WAF kullanılması web uygulamasındaki güvenli kodlama ihtiyacını ortadan kaldırmaz. En iyi sonuç, ağ firewall'ı, WAF, güvenli geliştirme ve log izleme birlikte uygulandığında alınır.

Cloud Firewall

Cloud firewall, bulut ortamındaki sanal ağlar, iş yükleri ve servisler arasındaki trafiği kontrol etmek için kullanılan güvenlik bileşenidir. Klasik fiziksel cihazlardan farklı olarak hizmet modeli veya sanal güvenlik bileşeni şeklinde sunulabilir. Bulut altyapısında hesap, proje, VPC, sanal ağ ve subnet sayısı arttıkça merkezi politika yönetimi daha önemli hâle gelir. Otomasyon kullanılmadan yapılan manuel değişiklikler konfigürasyon farklarına yol açabilir. Bu nedenle cloud firewall politikalarını kod tabanlı ve denetlenebilir süreçlerle yönetmek uzun vadede ciddi avantaj sağlar.

Firewall as a Service (FWaaS)

Firewall as a Service, güvenlik duvarı yeteneklerinin bulut üzerinden hizmet olarak sunulduğu yaklaşımdır. Kullanıcıların farklı lokasyonlardan internete ve uygulamalara eriştiği yapılarda güvenlik politikasını merkezi hâle getirebilir. Şube ofisleri, uzaktan çalışanlar ve bulut uygulamaları için ortak erişim politikaları uygulanması kolaylaşabilir. FWaaS seçerken gecikme, bağlantı yönlendirmesi, log erişimi, kimlik entegrasyonu ve hizmet sürekliliği değerlendirilmelidir. Bu model geleneksel firewall ihtiyacını her senaryoda ortadan kaldırmaz, ancak dağıtık yapılarda önemli bir seçenek oluşturur.

Firewall Rule Nedir?

Firewall rule, belirli bir ağ trafiğiyle karşılaşıldığında güvenlik duvarının ne yapacağını tanımlayan politika satırıdır. Bir kural çoğunlukla kaynak, hedef, servis, uygulama, kullanıcı ve action alanlarından oluşur. Etkili kurallar mümkün olduğu kadar belirli olmalı ve yalnızca gerçek iş ihtiyacını karşılamalıdır. Kural oluştururken önce bağlantının neden gerekli olduğunu, ardından teknik parametrelerini belirlemek daha sağlıklı sonuç verir. Firewall erişim kontrol listesi ACL nasıl yapılandırılır sorusunun cevabı da aynı temel prensiple başlar: erişimi varsayılan olarak sınırlı tutmak ve yalnızca doğrulanmış ihtiyaca izin vermek.

Source

Source alanı bağlantıyı başlatan IP adresini, ağı, güvenlik bölgesini veya kimlik grubunu ifade eder. Kaynağın çok geniş seçilmesi gereksiz sistemlerin aynı erişim hakkına sahip olmasına neden olabilir. Örneğin tek bir uygulama sunucusunun veri tabanına bağlanması gerekiyorsa tüm sunucu VLAN'ını kaynak olarak tanımlamak çoğu durumda doğru değildir. Mümkün olduğunda kaynak nesnesi gerçek ihtiyacı temsil edecek kadar dar tutulmalıdır. Bu yaklaşım olası bir cihaz ihlalinde saldırganın kullanabileceği erişim yollarını da azaltır.

Destination

Destination alanı trafiğin ulaşacağı hedef sistemi veya ağı tanımlar. Tek bir sunucuya erişim gerekiyorsa geniş bir subnet tanımlamak yerine o sunucunun adresini veya uygun bir object grubunu kullanmak daha doğrudur. Bulut ortamlarında hedefler IP yerine servis etiketi, uygulama veya güvenlik grubu gibi kavramlarla da temsil edilebilir. Hedefin net tanımlanması log analizini ve olay incelemesini kolaylaştırır. Ayrıca daha sonra gerçekleştirilecek rule recertification çalışmalarında erişimin gerçek kapsamını hızlı şekilde görmeyi sağlar.

Source Port

Source port çoğu istemci bağlantısında işletim sistemi tarafından dinamik olarak seçilir ve bu nedenle birçok kuralda geniş bırakılır. Ancak belirli protokoller veya özel mimariler source port kontrolü gerektirebilir. Source port ile destination port kavramlarının karıştırılması firewall değişikliklerinde sık görülen hatalardan biridir. Örneğin bir HTTPS bağlantısında hedef port 443 olurken kaynak port genellikle geçici bir yüksek porttur. Kural tasarımında uygulamanın gerçek bağlantı davranışını paket yakalama veya dokümantasyonla doğrulamak faydalıdır.

Destination Port

Destination port hedef servisin dinlediği portu belirtir ve erişim kontrolünün en önemli bileşenlerinden biridir. HTTP için 80, HTTPS için 443 veya SSH için 22 gibi yaygın örnekler bulunur, ancak uygulamalar farklı portlarda da çalışabilir. Tüm TCP veya UDP portlarını açmak yerine yalnızca kullanılan servislerin tanımlanması gerekir. Özellikle veri tabanı ve yönetim portları yalnızca gerekli kaynaklara açık tutulmalıdır. Firewall kurallarında port IP VLAN VPN ve kullanıcı bazlı erişim denetimi uygulanırken port bilgisi diğer bağlamlarla birlikte değerlendirilmelidir.

Protocol

Protocol alanı TCP, UDP, ICMP veya başka bir ağ protokolünü tanımlar. Aynı port numarası TCP ve UDP için farklı servisleri ifade edebileceği için protokolün açık biçimde belirtilmesi önemlidir. Gereksiz şekilde IP any gibi geniş protokol tanımları kullanmak kontrol kapsamını büyütebilir. IPv6 ortamlarında ICMPv6 gibi temel protokollerin ağ çalışması açısından özel rolü vardır. Bu nedenle protokol kısıtlaması yapılırken güvenlik kadar ağ işleyişi de dikkate alınmalıdır.

Application

Application alanı yeni nesil firewall sistemlerinde trafiğin gerçek uygulamasını tanımlamak için kullanılır. Port bazlı kontrol bazı uygulamaların farklı portlara geçebilmesi nedeniyle her zaman yeterli değildir. Uygulama tanıma kullanıldığında örneğin belirli bir iş uygulamasına izin verilirken aynı portu kullanan başka trafik sınırlandırılabilir. Bu kontrol özellikle SaaS ve web tabanlı servislerde daha anlamlı hâle gelir. Ancak doğru uygulama tanımlaması için firewall imza verilerinin güncel olması ve logların düzenli incelenmesi gerekir.

User ve Identity

User ve Identity alanı firewall politikasını yalnızca IP adresine bağlı olmaktan çıkarır. Bir kullanıcı farklı cihazlardan veya farklı IP adreslerinden bağlandığında kimlik tabanlı politika daha tutarlı erişim kontrolü sağlayabilir. Active Directory, LDAP, RADIUS veya modern kimlik protokolleri bu amaçla entegre edilebilir. Kullanıcı gruplarıyla erişim tanımlamak, çalışan rolü değiştiğinde yetkilerin merkezi şekilde güncellenmesini kolaylaştırır. Ben özellikle yönetim erişimlerinde IP ve kullanıcı kimliğini birlikte doğrulayan kuralları tercih ederim.

Action

Action, bir kural eşleştiğinde firewall'ın trafiğe nasıl davranacağını belirleyen alandır. En yaygın seçenekler allow, deny, reject ve inspect gibi eylemlerdir. Uygun action seçimi yalnızca erişim kararını değil, istemcinin aldığı yanıtı ve logların yorumlanmasını da etkileyebilir. Güvenlik politikası oluştururken her action'ın cihaz üzerindeki gerçek davranışı doğrulanmalıdır. Farklı platformlar aynı terime küçük davranış farkları yükleyebildiği için üretici dokümantasyonu dikkate alınmalıdır.

Allow

Allow eylemi, kural koşullarına uyan trafiğin geçmesine izin verir. İzin verilmesi trafiğin otomatik olarak güvenli olduğu anlamına gelmediği için gerekiyorsa IPS veya uygulama incelemesi de devreye alınmalıdır. Allow kuralları mümkün olduğunca açık iş gerekçelerine dayanmalıdır. Kaynak, hedef ve servis kapsamı gereğinden geniş bırakılmamalıdır. Ayrıca kritik izin kurallarının loglanması olay incelemelerinde büyük kolaylık sağlar.

Deny

Deny eylemi eşleşen trafiği sessiz biçimde engeller ve çoğu durumda karşı tarafa bağlantının neden başarısız olduğuna dair açık bir mesaj göndermez. Bu davranış internetten gelen istenmeyen bağlantılarda tercih edilebilir. Ancak operasyon ekipleri açısından sorun giderme sırasında log kaydı büyük önem taşır. Deny kuralları özellikle hassas segmentler arasında açık güvenlik sınırları oluşturmak için kullanılabilir. Gereksiz log yükünü önlemek amacıyla yoğun ve beklenen blok trafiğinde oran sınırlaması değerlendirilebilir.

Reject

Reject eylemi bağlantıyı engellerken istemciye belirli bir hata yanıtı gönderebilir. TCP bağlantılarında reset paketi veya bazı senaryolarda ICMP hata mesajı buna örnek verilebilir. Bu davranış istemcinin zaman aşımını beklemeden bağlantının reddedildiğini anlamasını sağlar. İç ağ uygulamalarında sorun giderme açısından faydalı olabilir. İnternet sınırında ise hangi yanıtın verileceği güvenlik politikası ve görünürlük hedeflerine göre seçilmelidir.

Inspect

Inspect eylemi trafiğin yalnızca geçmesine izin vermek yerine ek güvenlik kontrollerinden geçirilmesini ifade edebilir. Bu kontroller uygulama tanıma, IPS, kötü amaçlı içerik analizi veya URL kategorisi değerlendirmesi olabilir. Her trafik için en ağır incelemeyi kullanmak performans sorunlarına yol açabileceği için risk bazlı seçim yapmak gerekir. Kritik internet trafiğinde daha ayrıntılı kontrol uygulanırken güvenilir iç servisler farklı profile bağlanabilir. Kapasite planlamasında inspect özelliklerinin cihaz kaynak tüketimi mutlaka hesaba katılmalıdır.

Logging

Logging alanı kural eşleşmelerinin kaydedilip kaydedilmeyeceğini belirler. Bir firewall kuralının çalışıp çalışmadığını anlamanın en pratik yolu log ve hit count verilerini incelemektir. Özellikle yönetim, veri tabanı, internet çıkışı ve kritik uygulama erişimleri için loglama büyük değer sağlar. Buna karşılık çok yoğun trafik üreten kurallar kontrolsüz loglandığında depolama ve SIEM maliyeti artabilir. Bu nedenle log kapsamı risk, olay inceleme ihtiyacı ve operasyonel kapasite birlikte değerlendirilerek belirlenmelidir.

Schedule

Schedule alanı bir firewall kuralının yalnızca belirli günlerde veya saatlerde çalışmasını sağlar. Bakım çalışması, geçici tedarikçi erişimi veya dönemsel uygulama bağlantıları için oldukça kullanışlıdır. Sürekli açık tutulması gerekmeyen erişimler zaman tabanlı kurallarla sınırlandırılabilir. Bu yöntem unutulan geçici izinlerin kalıcı güvenlik açığına dönüşme riskini azaltır. İşlem tamamlandığında schedule süresinin yanı sıra kuralın tamamen kaldırılması veya yeniden doğrulanması da planlanmalıdır.

Description ve Metadata

Description ve metadata alanları kuralın neden oluşturulduğunu ve kimin sorumlu olduğunu anlamayı sağlar. İyi bir açıklamada iş amacı, talep numarası, sahip bilgisi ve gerekiyorsa son kullanma tarihi bulunmalıdır. Yüzlerce veya binlerce rule içeren ortamlarda açıklamasız kurallar büyük operasyon yükü oluşturur. Ben yeni bir kural açılırken teknik alanlardan önce anlamlı açıklama eklenmesini süreç şartı hâline getirmeyi faydalı buluyorum. Bu yaklaşım denetim, incident response ve periyodik rule temizliği sırasında ciddi zaman kazandırır.

Firewall Kuralları Nasıl Çalışır?

Firewall kuralları, gelen bir paketin veya oturumun tanımlanmış politika satırlarıyla karşılaştırılması üzerinden çalışır. Kural değerlendirme yöntemi platforma göre değişebilse de sıra, eşleşme kapsamı ve varsayılan davranış temel kavramlardır. Bir rule base teknik olarak doğru kurallardan oluşsa bile yanlış sıralama nedeniyle beklenmeyen sonuç üretebilir. Bu nedenle değişiklik yapılırken yalnızca yeni kuralın içeriğine değil, mevcut politikalarla ilişkisine de bakmak gerekir. Test ortamı, policy simulation ve hit count analizi bu noktada değerli araçlardır.

Packet Matching

Packet matching sürecinde firewall paketin kaynak, hedef, port, protokol ve diğer özelliklerini politika kriterleriyle karşılaştırır. Yeni nesil sistemler buna kullanıcı, uygulama, URL kategorisi ve cihaz durumu gibi ek bilgiler ekleyebilir. Gerekli tüm kriterler eşleştiğinde ilgili kuralın action değeri uygulanır. Bir kriter bile uyuşmazsa değerlendirme sonraki kurala geçebilir. Sorun giderirken loglarda hangi kuralın eşleştiğini görmek, beklenmeyen erişim problemlerini anlamanın en hızlı yollarından biridir.

First-Match-Wins Mantığı

First-Match-Wins yaklaşımında trafik yukarıdan aşağı doğru değerlendirilir ve ilk eşleşen kural uygulanır. Bu nedenle geniş kapsamlı bir allow kuralı daha özel deny kuralının üzerinde bulunursa özel engelleme hiç çalışmayabilir. Aynı durum geniş bir deny kuralının altında kalan gerekli izin için de geçerlidir. Kural sırası değiştirildiğinde işlevsel sonuç tamamen değişebilir. Policy review sırasında yalnızca rule içeriğinin değil konumunun da değerlendirilmesi bu yüzden gereklidir.

Rule Priority

Rule priority, bazı platformlarda kuralların değerlendirme önceliğini belirlemek için sıra numarası veya özel öncelik mekanizması kullanılmasıdır. Merkezi yönetim sistemlerinde global ve lokal politikaların farklı öncelik seviyeleri olabilir. Bu yapı doğru kullanılmadığında bir şube kuralı merkezi güvenlik politikasını beklenmedik biçimde etkileyebilir. Değişiklikten önce gerçek değerlendirme sırası mutlaka doğrulanmalıdır. Özellikle çoklu firewall veya multi-cloud yönetiminde priority mantığının dokümante edilmesi önemlidir.

Rule Order Neden Kritiktir?

Rule order kritik bir konudur çünkü aynı trafik birden fazla kuralla eşleşebilecek özelliklere sahip olabilir. Daha genel bir kural üstte yer aldığında alttaki özel kurallar hiçbir zaman kullanılmayabilir. Bu durum shadowed rule oluşmasına ve güvenlik politikasının beklenenden farklı çalışmasına neden olur. Sıralama aynı zamanda performansı da etkileyebilir, çünkü çok sık kullanılan kuralların değerlendirme yeri bazı sistemlerde işlem yükünü değiştirebilir. Değişiklik sonrasında hit count ve log kontrolü yapmak bu nedenle iyi bir operasyon alışkanlığıdır.

Implicit Rule Nedir?

Implicit rule, yönetici tarafından doğrudan yazılmasa da firewall sisteminin varsayılan davranışının parçası olan kuraldır. En yaygın örnek, hiçbir explicit kuralla eşleşmeyen trafiğin otomatik olarak engellenmesidir. Bazı platformlarda yönetim servisleri veya belirli sistem trafiği için başka implicit davranışlar da bulunabilir. Bu kurallar arayüzde her zaman normal policy satırı gibi görünmeyebilir. Cihaz devreye alınmadan önce implicit policy davranışını bilmek sürpriz erişim sonuçlarını önler.

Explicit Rule Nedir?

Explicit rule, yönetici tarafından açıkça tanımlanan ve rule base içinde görülebilen politika satırıdır. Kaynak, hedef, servis ve action gibi alanları belirli olduğu için denetim açısından daha anlaşılırdır. Özellikle deny-all gibi kritik davranışların explicit olarak yazılması bazı ekiplerde görünürlük amacıyla tercih edilir. Böylece firewall arayüzüne bakan kişi son kuralın tüm diğer trafiği engellediğini doğrudan görebilir. Yine de explicit veya implicit seçimi yapılırken platform özellikleri ve loglama davranışı dikkate alınmalıdır.

Default Deny Nedir?

Default deny, açıkça izin verilmemiş tüm erişimin engellenmesi prensibidir. Güvenlik tasarımında en güçlü temel yaklaşımlardan biridir çünkü ağın zamanla farkında olmadan geniş izinlerle dolmasını önler. İş ihtiyacı olan bağlantılar tek tek tanımlanır, geri kalan trafik izin verilmediği için geçemez. Bu model başlangıçta daha fazla analiz ve test gerektirebilir, ancak uzun vadede kontrol edilebilir bir erişim yapısı oluşturur. Özellikle yeni ağ segmentleri ve bulut projeleri devreye alınırken default deny yaklaşımını baştan uygulamak sonradan geçiş yapmaktan daha kolaydır.

Deny by Default, Allow by Exception

Deny by Default, Allow by Exception yaklaşımı tüm bağlantıları başlangıçta kapalı kabul eder. Bir trafik ihtiyacı doğrulandığında gerekli kaynak, hedef ve servis için istisna oluşturulur. Böylece erişim hakkı teknik kolaylığa göre değil, iş gerekçesine göre verilir. Kurumsal ağlarda firewall rule base least privilege ve erişim politikası yönetimi için bu yaklaşım güçlü bir temel sağlar. Erişim ihtiyacı sona erdiğinde ilgili istisnanın kaldırılması da aynı sürecin parçası olmalıdır.

Default Allow Neden Risklidir?

Default allow modelinde engellenmeyen her trafik otomatik olarak geçebilir. Bu durum yeni eklenen sistemlerin veya servislerin fark edilmeden geniş erişime sahip olmasına yol açabilir. Bir güvenlik açığı bulunan cihaz ele geçirildiğinde saldırgan daha geniş ağ alanına ulaşabilir. Ayrıca kurum içinde hangi bağlantıların gerçekten gerekli olduğunu anlamak zorlaşır. Bu nedenle üretim ortamlarında varsayılan izin yerine kontrollü istisna yaklaşımı genellikle daha güvenli kabul edilir.

Explicit Deny-All

Explicit deny-all, rule base'in sonunda her türlü eşleşmemiş trafiği engelleyen açık bir kural tanımlanmasıdır. Bu yöntemin avantajı varsayılan davranışın yönetim arayüzünde doğrudan görünmesidir. Kural açıklamasına güvenlik politikası veya denetim gereksinimi de eklenebilir. Deny-all kuralının loglanması hangi yeni trafik ihtiyaçlarının ortaya çıktığını anlamaya yardımcı olabilir. Ancak yoğun blok trafiği log sistemini doldurabileceği için log hacminin dikkatle yönetilmesi gerekir.

Implicit Deny

Implicit deny, kural listesinin sonunda cihazın otomatik olarak uyguladığı engelleme davranışıdır. Yönetici ayrı deny-all satırı yazmasa bile eşleşmeyen paketler reddedilir. Bu yöntem rule base'i daha kısa tutabilir, ancak yeni ekip üyelerinin davranışı bilmesi gerekir. Loglama özellikleri bazı platformlarda explicit deny kuralından farklı çalışabilir. Operasyon dokümantasyonunda implicit deny davranışının açık şekilde belirtilmesi bu nedenle faydalıdır.

Deny Rule'larda Logging

Deny rule logging, engellenen bağlantıların kayda alınmasını sağlar ve güvenlik izleme açısından değerli bilgiler üretir. Aynı kaynaktan art arda farklı portlara gelen bağlantılar port taraması göstergesi olabilir. İç ağdan beklenmeyen internet hedeflerine yapılan başarısız bağlantılar ise kötü amaçlı yazılım araştırmasını tetikleyebilir. Bununla birlikte saniyede binlerce tekrarlanan paket gereksiz log yükü oluşturabilir. Rate limiting, aggregation veya seçici loglama yöntemleriyle güvenlik görünürlüğü ve kapasite arasında denge kurulmalıdır.

Least Privilege Firewall Politikası Nasıl Tasarlanır?

Least privilege yaklaşımı bir kullanıcıya, cihaza veya uygulamaya yalnızca görevini yerine getirmesi için gerekli en düşük erişimin verilmesini amaçlar. Firewall tarafında bu, kaynağın, hedefin, portun, protokolün, uygulamanın, zaman aralığının ve kimliğin mümkün olduğunca sınırlı tutulması anlamına gelir. Kuralların geniş tutulması kısa vadede operasyonu kolay gösterebilir, ancak ileride erişim alanını kontrol etmeyi zorlaştırır. Ben yeni firewall taleplerinde “Bu bağlantı neden gerekiyor?” sorusundan sonra “Daha dar tanımlanabilir mi?” sorusunu mutlaka sorarım. Bu iki soru tek başına birçok gereksiz izni daha oluşturulmadan önleyebilir.

Minimum Source

Minimum source prensibi erişime yalnızca gerçekten ihtiyaç duyan kaynakların eklenmesini ifade eder. Bir uygulama sunucusunun veri tabanına erişmesi gerekiyorsa tüm veri merkezi ağı kaynak olarak kullanılmamalıdır. Kaynak adresler yönetilebilir object veya group yapılarıyla tanımlanabilir. Dinamik ortamlarda kimlik veya uygulama etiketleri IP adresinden daha anlamlı olabilir. Kaynak kapsamı daraldıkça ele geçirilmiş başka sistemlerin aynı bağlantıyı kullanma ihtimali azalır.

Minimum Destination

Minimum destination prensibi hedef kapsamını gerçek servis ihtiyacıyla sınırlar. Kullanıcının tek bir uygulama sunucusuna erişmesi gerekiyorsa tüm sunucu segmentine erişim verilmesi gereksizdir. DNS adı veya servis discovery kullanan ortamlarda uygun FQDN object veya dinamik nesneler tercih edilebilir. Hedef grupları düzenli tutulduğunda sistem değişiklikleri de daha kolay yönetilir. Fazla geniş destination tanımları özellikle lateral movement riskini artırdığı için periyodik olarak gözden geçirilmelidir.

Minimum Port

Minimum port prensibi yalnızca uygulamanın kullandığı portların açılmasını gerektirir. “Sorun çıkmasın” düşüncesiyle geniş port aralıkları açmak güvenlik açısından doğru değildir. Bir servis birden fazla port kullanıyorsa bunlar application owner ile doğrulanmalı ve dokümante edilmelidir. Geçici sorun giderme sırasında açılan geniş portlar işlem tamamlandığında kapatılmalıdır. Port listesi değiştiğinde ilgili firewall rule ve uygulama dokümanı birlikte güncellenmelidir.

Minimum Protocol

Minimum protocol yaklaşımı yalnızca gerçek iletişim için gerekli protokollere izin verir. Bir uygulama yalnızca TCP kullanıyorsa TCP ve UDP birlikte açılmamalıdır. ICMP gibi destek protokollerinde ise tamamen engelleme yerine ihtiyaç duyulan message type'ları değerlendirmek daha sağlıklı olabilir. IPv6 ortamlarında Neighbor Discovery ve Path MTU gibi işlevler protokol kısıtlamalarında dikkate alınmalıdır. Protokol bazlı sınırlandırma diğer least privilege kontrolleriyle birlikte kullanıldığında anlamlı hâle gelir.

Minimum Uygulama

Minimum uygulama yaklaşımı, yalnızca iş ihtiyacı olan uygulama trafiğine izin verilmesini hedefler. NGFW platformlarında port 443 açık olsa bile izin verilen uygulama ailesi ayrıca tanımlanabilir. Örneğin bir kullanıcı grubuna belirli SaaS hizmetlerine erişim verilirken bilinmeyen tünel uygulamaları engellenebilir. Bu yöntem port bazlı kontrolün kapsayamadığı bazı kullanım örneklerini yönetir. Uygulama tanıma özelliklerinin doğru çalışması için cihaz güncellemeleri ve trafik logları düzenli izlenmelidir.

Minimum Süre

Minimum süre prensibi erişimin yalnızca ihtiyaç devam ettiği kadar açık tutulmasını amaçlar. Proje, bakım veya tedarikçi erişimleri için başlangıç ve bitiş zamanı tanımlamak etkili bir yöntemdir. Kalıcı kural yerine otomatik sona eren geçici izinler tercih edilebilir. Süre dolduğunda erişimin otomatik kapatılması insan hatası riskini azaltır. Özellikle yönetim ve privileged erişimlerde time-bounded authorization önemli bir güvenlik kontrolüdür.

Minimum Kullanıcı ve Cihaz Grubu

Minimum kullanıcı ve cihaz grubu yaklaşımı erişimi yalnızca yetkili kişilere ve uygun cihazlara sınırlar. Aynı departmandaki tüm çalışanlara aynı ağ yetkisinin verilmesi her zaman gerekli değildir. İş rolü, cihaz sahipliği, endpoint posture ve kimlik doğrulama sonucu birlikte değerlendirilebilir. Örneğin kritik yönetim uygulamasına yalnızca belirli admin grubundan ve kurumsal olarak yönetilen cihazlardan erişim verilebilir. Bu yaklaşım firewall, NAC ve Zero Trust kontrollerini ortak bir politika altında birleştirir.

“Any Any Allow” Kuralı Neden Tehlikelidir?

“Any Any Allow” kuralı, kaynak ve hedef ayrımı yapmadan çok geniş bir trafik alanına izin verir. Bu tür kurallar genellikle sorun giderme sırasında hızlı çözüm amacıyla eklenir, ancak kaldırılması unutulduğunda uzun süreli güvenlik riski oluşturur. Ağın farklı bölümleri arasındaki güvenlik sınırlarını etkisiz hâle getirebilir ve saldırganın ele geçirdiği bir sistemden başka hedeflere ulaşmasını kolaylaştırabilir. Özellikle kritik sunucu segmentlerinde permit-all yaklaşımı kullanılmamalıdır. Gerekli trafik bilinmiyorsa geniş izin vermek yerine log ve paket analiziyle gerçek bağlantı ihtiyacını belirlemek daha doğru yöntemdir.

Attack Surface

Attack surface, saldırganın erişebileceği sistem, servis ve bağlantı yollarının toplamını ifade eder. Any Any Allow kuralı birçok sistemi birbirine görünür hâle getirerek bu alanı büyütür. Normalde erişilememesi gereken yönetim portları veya uygulama servisleri ulaşılabilir duruma gelebilir. Güvenlik açığı bulunan tek bir servis bile zincirleme risk oluşturabilir. Kaynak, hedef ve port kapsamını daraltmak attack surface azaltmanın en temel yollarından biridir.

Lateral Movement

Lateral movement saldırganın ilk ele geçirdiği cihazdan başka sistemlere geçmesini ifade eder. Ağ segmentleri arasında geniş erişim varsa bu hareket daha kolay gerçekleşebilir. Özellikle kullanıcı cihazlarının sunucu veya yönetim VLAN'larına doğrudan erişebilmesi ciddi risk oluşturur. Firewall segmentasyonu ve least privilege kuralları olası hareket yollarını sınırlar. Bir güvenlik olayında erişim yollarının dar olması olayın etkisini de azaltabilir.

Unintended Exposure

Unintended exposure, planlanmayan bir servisin veya sistemin erişilebilir hâle gelmesidir. Geniş firewall kuralları yeni devreye alınan cihazları otomatik olarak daha fazla ağa açık hâle getirebilir. Örneğin aynı subnet içinde sonradan eklenen bir yönetim arayüzü mevcut geniş allow kuralından faydalanabilir. Bu durum değişiklik ekipleri tarafından fark edilmeyebilir. Dar object ve zone tanımları yeni sistemlerin otomatik olarak erişim hakkı kazanmasını önlemeye yardımcı olur.

Troubleshooting İçin Eklenen Geçici Kurallar

Sorun giderme sırasında geniş kural eklemek hızlı teşhis için cazip görünebilir. Ancak böyle bir değişiklik mutlaka sınırlı süre, açık owner ve ticket bilgisiyle yapılmalıdır. Mümkünse yalnızca ilgili kaynak ve hedef arasında geçici izin tanımlanmalıdır. İşlem tamamlanınca rule hit ve log verileri incelenerek gerçek gerekli portlar çıkarılabilir. Ardından geniş geçici kural kaldırılıp kalıcı least privilege kuralı oluşturulmalıdır.

Permit-All Kuralını Güvenli Şekilde Kaldırma

Permit-all kuralını doğrudan silmek üretim bağlantılarında beklenmeyen kesintilere yol açabilir. Önce kuralın logları ve hit count verileri belirli bir süre analiz edilmelidir. Gerekli akışlar ayrı ve daha dar allow kurallarına dönüştürülmelidir. Yeni kurallar test edildikten sonra permit-all kuralı önce devre dışı bırakılarak etkisi gözlemlenebilir. Her şey beklendiği gibi çalışıyorsa değişiklik kaydı tamamlanarak kural kalıcı olarak kaldırılabilir.

ACL Nedir?

ACL, yani Access Control List, ağ cihazında hangi trafiğe izin verileceğini veya hangi trafiğin engelleneceğini belirleyen kurallar listesidir. Router, switch, firewall ve çeşitli sanal ağ bileşenlerinde ACL benzeri mekanizmalar bulunabilir. ACL'ler özellikle IP, subnet, protokol ve port temelli kontrol için yaygın olarak kullanılır. Firewall erişim kontrol listesi ACL nasıl yapılandırılır sorusuna verilecek ilk cevap, ACL'nin uygulanacağı yönü ve gerçek trafik akışını doğru anlamaktır. Yanlış interface veya yanlış direction üzerinde kullanılan doğru bir ACL bile beklenen sonucu vermeyebilir.

Access Control List Nasıl Çalışır?

Access Control List, gelen veya giden paketi tanımlanan koşullarla karşılaştırır. Kural eşleştiğinde permit veya deny gibi tanımlanmış eylem uygulanır. Birçok ACL sisteminde ilk eşleşen kuralın sonucu geçerli olur ve değerlendirme devam etmez. Liste sonunda explicit veya implicit deny bulunabilir. Bu nedenle ACL yazılırken hem kural içeriği hem de sırası birlikte planlanmalıdır.

Standard ACL

Standard ACL genellikle yalnızca kaynak IP adresine göre karar veren daha basit erişim listesi türüdür. Kaynak bazlı geniş filtreleme için kullanılabilir, ancak hedef ve servis ayrıntısını sınırlı biçimde kontrol eder. Bu nedenle hassas uygulama erişimlerinde yeterli olmayabilir. Standard ACL yerleştirilirken istemeden başka hedefleri de etkilememek için konumu dikkatle seçilmelidir. Daha ayrıntılı kontrol gereken senaryolarda extended ACL daha uygun olabilir.

Extended ACL

Extended ACL kaynak, hedef, protokol ve port gibi daha fazla kriter üzerinden kontrol sağlar. Bu sayede belirli bir kullanıcı subnet'inin yalnızca belirli sunucu ve servislere erişmesine izin verilebilir. Kurumsal ağ segmentasyonunda sık kullanılan yaklaşımlardan biridir. Rule kapsamı genişledikçe dokümantasyon ve object standardı daha önemli olur. Extended ACL doğru tasarlandığında router veya Layer 3 switch üzerinde etkili temel erişim kontrolü sağlayabilir.

Inbound ACL

Inbound ACL bir interface'e gelen paketler routing işlemine devam etmeden önce uygulanabilir. Trafiğin kaynağa yakın noktada engellenmesi gereksiz ağ kullanımını azaltabilir. Ancak hangi interface'in inbound yönünün hangi trafik akışını temsil ettiğini doğru anlamak gerekir. Yanlış yön seçimi kuralın hiç çalışmamasına veya beklenmedik trafiği engellemesine neden olabilir. Değişiklik sonrası packet counter veya ACL hit verileri mutlaka kontrol edilmelidir.

Outbound ACL

Outbound ACL bir paketin interface üzerinden dışarı gönderilmesinden önce uygulanır. Hedef ağa giden trafiğin son çıkış noktasında filtrelenmesi gereken durumlarda kullanılabilir. Bazı tasarımlarda aynı güvenlik amacı inbound veya outbound ACL ile gerçekleştirilebilir, ancak operasyonel görünürlük farklı olabilir. Ağ topolojisi ve troubleshooting yöntemi seçimde etkili olur. Kuralların hangi yönde uygulandığı dokümantasyonda açıkça belirtilmelidir.

Named ACL

Named ACL, sayısal tanımlama yerine anlamlı isim kullanılarak oluşturulan erişim listesidir. Örneğin FINANCE_TO_ERP gibi bir ad ACL'nin amacını ilk bakışta anlatabilir. Bu yöntem büyük ağlarda yönetilebilirliği artırır ve değişiklik kayıtlarının okunmasını kolaylaştırır. İsimlendirme standardının kurum genelinde tutarlı olması gerekir. ACL adı tek başına yeterli olmadığı için açıklama ve ticket bilgisinin de dokümantasyonda tutulması faydalıdır.

ACL Rule Ordering

ACL rule ordering ilk eşleşme mantığı kullanılan sistemlerde doğrudan erişim sonucunu belirler. Özel izin veya engelleme kuralları genel kuralların altında kalırsa hiçbir zaman çalışmayabilir. Bu nedenle dar kapsamlı kurallar genellikle geniş kurallardan önce değerlendirilir. ACL değişikliğinde mevcut listenin tamamı incelenmeden araya yeni satır eklemek risklidir. Simulation veya lab testi mümkünse production değişikliğinden önce yapılmalıdır.

ACL ile Firewall Arasındaki Fark

ACL ve firewall aynı amaca hizmet eden bazı ortak özelliklere sahip olsa da kontrol derinlikleri farklı olabilir. ACL çoğunlukla Layer 3 ve Layer 4 seviyesinde kaynak, hedef, protokol ve port üzerinden karar verir. Stateful veya yeni nesil firewall sistemleri oturum durumu, kullanıcı kimliği, uygulama türü ve tehdit verileri gibi ek bilgileri değerlendirebilir. Bu nedenle ACL her zaman firewall'ın yerini almaz, firewall da her küçük segmentasyon ihtiyacında tek seçenek değildir. Hangi kontrolün kullanılacağı ağın risk seviyesine, trafik yapısına ve operasyon gereksinimine göre belirlenmelidir.

Stateless vs Stateful Kontrol

Birçok klasik ACL stateless çalışırken firewall sistemleri çoğunlukla stateful bağlantı takibi yapar. Stateless kontrolde dönüş trafiği için ayrı izin koşulları gerekebilir. Stateful sistem bağlantının başlangıcını ve mevcut oturum durumunu hatırlayabilir. Bu sayede yalnızca geçerli bir bağlantıya ait dönüş paketlerinin kabul edilmesi mümkün olur. İnternet ve kritik segment erişimlerinde state takibi önemli bir güvenlik avantajı sağlar.

Layer 3/4 Kontrolü

Layer 3 ve Layer 4 kontrolü IP adresleri, protokoller ve TCP veya UDP portları üzerine kuruludur. ACL bu seviyede oldukça etkili ve hızlı bir araç olabilir. Basit ağ segmentasyonu, yönetim erişimi veya belirli servis yolları için yeterli sonuç verebilir. Ancak aynı port üzerinden farklı uygulamalar çalıştığında kontrol granülerliği azalır. Uygulama veya kullanıcı bağlamı gereken senaryolarda gelişmiş firewall özellikleri tercih edilmelidir.

Application Awareness

Application awareness, trafiği yalnızca port numarasına göre değil gerçek uygulama davranışına göre tanımlamayı sağlar. Bu özellik çoğu klasik ACL yapısında bulunmaz. Yeni nesil firewall, web tabanlı farklı servisleri aynı port kullanılsa bile ayırt edebilir. Böylece politika “TCP 443'e izin ver” yerine “belirli uygulamaya izin ver” şeklinde oluşturulabilir. Bu yaklaşım özellikle bulut ve SaaS kullanımının yoğun olduğu ağlarda daha anlamlı erişim kontrolü sağlar.

Session Tracking

Session tracking aktif bağlantıların başlangıç, yön, süre ve durum bilgilerinin firewall tarafından takip edilmesidir. Bu özellik dönüş trafiğini mevcut oturumla ilişkilendirmeyi mümkün kılar. Stateless ACL sistemlerinde aynı bağlam bulunmadığı için kurallar daha fazla manuel tanım gerektirebilir. Session tablosu ayrıca sorun giderme ve performans analizinde de değerlidir. Çok yoğun ağlarda state table kapasitesi firewall boyutlandırmasının önemli parçalarından biridir.

Threat Inspection

Threat inspection, izin verilen trafiğin bilinen saldırı yöntemleri veya zararlı içerik açısından incelenmesini sağlar. Basit ACL yalnızca bağlantıya izin verip vermeme kararı verir ve içerik analizi yapmaz. NGFW üzerinde IPS, malware analizi veya URL kontrolü gibi katmanlar kullanılabilir. Bununla birlikte tehdit inceleme özellikleri işlemci ve gecikme maliyeti oluşturabilir. Bu nedenle riskli trafik alanlarında uygun profiller seçilerek performans dengesi kurulmalıdır.

Hangi Durumda ACL Yeterlidir?

ACL basit ve iyi tanımlanmış Layer 3 veya Layer 4 erişim kontrolü gereken durumlarda yeterli olabilir. Örneğin yönetim subnet'inin yalnızca belirli router ve switch arayüzlerine ulaşmasını sınırlamak için kullanılabilir. İç segmentlerde temel port ve ağ bazlı ayrım da ACL ile yapılabilir. Ancak internet sınırı, kritik uygulamalar, kullanıcı kimliği veya threat inspection ihtiyacı olduğunda firewall daha uygun seçimdir. Tasarım kararı verirken yalnızca lisans veya cihaz maliyetine değil, ihtiyaç duyulan güvenlik bağlamına bakılmalıdır.

Stateful Firewall Nasıl Çalışır?

Stateful firewall, ağ bağlantılarını tek paketler olarak değil devam eden oturumlar olarak değerlendirir. Bir TCP bağlantısının nasıl kurulduğunu, hangi yönde başlatıldığını ve hâlâ geçerli olup olmadığını takip eder. Bu bilgi connection state table üzerinde tutulur. Böylece içeriden başlatılan izinli bir bağlantının dönüş paketlerine ayrıca geniş bir inbound kural yazılması gerekmez. Bu mekanizma doğru rule base ile birleştiğinde hem yönetimi kolaylaştırır hem de beklenmeyen bağlantı girişimlerini sınırlar.

Connection State Table

Connection state table aktif bağlantılar hakkında kaynak, hedef, port, protokol ve durum gibi bilgileri saklar. Firewall yeni paket geldiğinde bunun mevcut bir oturuma ait olup olmadığını bu tablodan kontrol eder. Yoğun ağlarda milyonlarca eşzamanlı bağlantı bulunabileceği için state kapasitesi önemlidir. Tablo dolduğunda yeni bağlantılar etkilenebilir veya performans sorunu yaşanabilir. Kapasite planlamasında yalnızca throughput değil concurrent session ve new session per second değerleri de incelenmelidir.

NEW

NEW durumu yeni başlatılan bir bağlantıyı ifade eder. Firewall bu aşamada trafik için uygun allow kuralı olup olmadığını değerlendirir. İzin verilirse bağlantı state tablosuna eklenir ve sonraki paketler mevcut oturumla eşleştirilir. Yeni bağlantıların yoğunluğu saldırı veya kapasite problemi göstergesi olabilir. Özellikle internet servislerinde new session rate değerleri performans izleme açısından önemlidir.

ESTABLISHED

ESTABLISHED durumu bağlantının başarıyla kurulduğunu ve iki yönlü iletişimin başladığını gösterir. Stateful firewall bu oturuma ait paketleri state tablosuyla eşleştirerek işleyebilir. Böylece her dönüş paketi için yeni bir access rule değerlendirmesi yapılması gerekmez. Bununla birlikte güvenlik profilleri aktifse trafik oturum boyunca incelenmeye devam edebilir. Uzun süreli veya olağan dışı established bağlantılar güvenlik analizi için ayrıca değerlendirilebilir.

RELATED

RELATED durumu mevcut bir bağlantıyla ilişkili yeni trafik akışlarını ifade eder. Bazı protokoller ana bağlantının yanında ek veri kanalları oluşturabilir. Stateful firewall protokol yardımcıları veya bağlantı bilgileri aracılığıyla bu ilişkiyi anlayabilir. Bu özellik stateless ACL üzerinde yönetimi zor olan dinamik bağlantıları kolaylaştırabilir. Ancak gereksiz protokol helper özelliklerinin açık bırakılması yerine gerçek ihtiyaca göre yapılandırılması daha güvenlidir.

Return Traffic

Return traffic, daha önce izin verilmiş bir oturuma karşılık gelen dönüş paketleridir. Stateful firewall bu paketleri mevcut state kaydıyla ilişkilendirdiği için ayrı geniş izin kurallarına ihtiyaç duymaz. Örneğin kullanıcı HTTPS bağlantısı başlattığında web sunucusundan gelen yanıtlar aynı oturumun parçası olarak kabul edilir. Bu mekanizma inbound rule sayısını azaltırken bağlantı yönünü daha net kontrol eder. Beklenmeyen dönüş trafiği state kaydıyla eşleşmiyorsa varsayılan politika kapsamında engellenebilir.

Stateless ACL'den Farkı

Stateless ACL her paketi bağımsız değerlendirirken stateful firewall bağlantının geçmişini ve durumunu takip eder. Bu fark özellikle dönüş trafiği kurallarında belirginleşir. ACL ile benzer sonuç elde etmek mümkün olsa da daha fazla kural ve doğru port yönü bilgisi gerekebilir. Stateful kontrol uygulama trafiğinin yönetimini kolaylaştırırken connection table kapasitesi gibi yeni operasyon gereksinimleri getirir. Ağ tasarımında hangi yöntemin kullanılacağı trafik hacmi ve güvenlik ihtiyacına göre belirlenmelidir.

Firewall Rule Order Nasıl Tasarlanmalıdır?

Firewall rule order, politikanın fiilen nasıl çalışacağını belirleyen temel unsurlardan biridir. İyi tasarlanmış bir sıra genellikle önce özel engellemeleri ve çok belirli izinleri, ardından daha genel erişim politikalarını içerir. Son bölümde ise eşleşmeyen trafiği engelleyen final deny yaklaşımı bulunur. Her platform aynı değerlendirme modelini kullanmadığı için gerçek çalışma biçimi doğrulanmalıdır. Rule sayısı büyüdükçe otomatik shadow, duplicate ve overlap analizi kullanmak insan hatasını azaltabilir.

Specific Rule Before General Rule

Specific rule before general rule prensibi daha dar kapsamlı kuralların daha geniş politikalardan önce değerlendirilmesini önerir. Örneğin belirli bir sunucuya erişimi engellemek istiyorsanız bu deny kuralı tüm sunucu ağına izin veren genel kuralın üstünde olmalıdır. Aksi durumda ilk eşleşme genel allow üzerinde gerçekleşebilir. Bu prensip yalnızca deny değil özel allow kuralları için de geçerlidir. Her değişiklikte yeni rule'un üst ve alt komşuları kontrol edilmelidir.

Explicit Block Rules

Explicit block rules belirli riskli trafik türlerini açık biçimde engellemek için kullanılır. Örneğin kullanıcı ağından firewall yönetim arayüzlerine erişim doğrudan deny kuralıyla sınırlandırılabilir. Böyle bir kural genel allow kurallarının üstünde yer almalıdır. Explicit bloklar güvenlik niyetini policy üzerinde görünür hâle getirir. Loglama etkinleştirildiğinde yetkisiz erişim denemelerinin izlenmesine de yardımcı olur.

Specific Allow Rules

Specific allow rules belirli iş akışlarına minimum gerekli kapsamda izin verir. Kaynak, hedef, port, uygulama ve kullanıcı bilgileri mümkün olduğunca açık tanımlanır. Aynı işlevi geniş ağ erişimiyle çözmek yerine her kritik akışın ayrı policy olarak yönetilmesi daha güvenlidir. Bu yapı log inceleme sırasında hangi iş sürecinin trafiği ürettiğini anlamayı kolaylaştırır. Kuralların owner ve review tarihiyle birlikte tutulması yaşam döngüsü yönetimini destekler.

General Rules

General rules daha geniş fakat yine de kontrollü erişim ihtiyaçlarını kapsar. Örneğin tüm kurumsal kullanıcıların belirlenmiş web proxy sunucularına erişimi tek genel policy altında tutulabilir. Bu kurallar specific rule'lardan sonra yer aldığında özel istisnaların çalışması sağlanır. General rule kapsamı düzenli olarak incelenmeli ve zaman içinde gereksiz büyümesi önlenmelidir. Object group kullanımı yönetimi kolaylaştırabilir, ancak grup içeriği değişiklikleri de aynı kontrol sürecine tabi olmalıdır.

Final Deny Rule

Final deny rule, diğer kurallarla eşleşmeyen tüm trafiği engelleyen son politika satırıdır. Bu yaklaşım default deny modelini policy üzerinde görünür biçimde uygular. Loglama açık olduğunda beklenmeyen bağlantı girişimleri analiz edilebilir ve gerçekten yeni bir erişim ihtiyacı olup olmadığı anlaşılabilir. Ancak yoğun internet veya broadcast benzeri trafik log hacmini artırabilir. Bu nedenle final deny logları SIEM üzerinde filtreleme ve rate limit politikalarıyla yönetilebilir.

Performans ve Rule Order İlişkisi

Firewall performansı rule evaluation yöntemine ve cihaz mimarisine bağlı olarak kural sırasından etkilenebilir. Bazı sistemlerde sık kullanılan kuralların daha erken eşleşmesi işlem yükünü azaltabilir. Başka platformlar politika derleme veya optimize edilmiş lookup yöntemleri kullandığı için fiziksel sıra performansı daha az etkileyebilir. Bu nedenle yalnızca genel varsayımlarla rule sırası değiştirilmemelidir. Öncelik her zaman güvenlik davranışı olmalı, performans optimizasyonu cihaz ölçümleriyle doğrulanmalıdır.

Shadowed Firewall Rule Nedir?

Shadowed firewall rule, üstte bulunan daha geniş veya çakışan bir kural nedeniyle hiçbir zaman eşleşmeyen politika satırıdır. Bu durum rule base büyüdükçe sık görülür ve gerçek güvenlik davranışı ile dokümante edilen niyet arasında fark oluşturabilir. Shadowed rule yalnızca gereksiz satır değildir, bazen önemli bir engelleme veya izin politikasının aslında çalışmadığını gösterebilir. Bu nedenle otomatik policy analyzer araçları veya düzenli manuel inceleme kullanılmalıdır. Özellikle büyük kurumsal ortamlarda her değişiklik öncesi shadow analizi yapmak güvenli bir alışkanlıktır.

Shadow Rule Nasıl Oluşur?

Shadow rule genellikle genel kapsamlı bir policy daha özel kuralın üzerinde bulunduğunda oluşur. Örneğin üstte tüm kullanıcı ağının tüm sunuculara erişmesine izin veren bir rule varsa alttaki belirli sunucu deny kuralı etkisiz kalabilir. Benzer durum geniş deny kuralının altında bulunan özel allow için de geçerlidir. Object group değişiklikleri de daha önce çalışmayan overlap durumları oluşturabilir. Bu nedenle yalnızca rule ekleme değil object değişiklikleri de policy impact analizi gerektirir.

Shadow Rule Örneği

Birinci kuralın 10.10.0.0/16 ağından 172.16.0.0/16 ağına TCP erişimine izin verdiğini düşünelim. İkinci kural ise 10.10.20.0/24 kaynağından 172.16.10.50 hedefinin TCP 22 portunu engelliyor olsun. İlk kural ikinci kuralın tüm trafik alanını kapsıyorsa SSH deny policy hiçbir zaman çalışmaz. Bu durumda güvenlik niyeti mevcut olsa da fiili kontrol uygulanmıyordur. Çözüm, daha özel deny kuralını uygun sıraya taşımak veya genel allow kapsamını daraltmaktır.

Shadow Rule Nasıl Tespit Edilir?

Shadow rule tespiti manuel policy karşılaştırması, hit count analizi veya otomatik firewall analysis araçlarıyla yapılabilir. Uzun süredir sıfır hit alan kural ilk işaret olabilir, ancak sıfır hit tek başına shadow anlamına gelmez. Üst kuralların kaynak, hedef ve servis kümeleri karşılaştırılmalıdır. Bazı merkezi firewall yönetim platformları shadow ve overlap uyarılarını değişiklik aşamasında gösterebilir. CI/CD tabanlı firewall-as-code süreçlerinde de bu kontrol otomatik test olarak eklenebilir.

Güvenlik Üzerindeki Etkisi

Shadow rule güvenlik politikası ile gerçek ağ davranışı arasında fark oluşturabilir. Çalıştığı sanılan bir deny kuralı etkisizse hassas sistemler beklenenden daha açık kalabilir. Çalıştığı sanılan bir allow policy shadow altında kalıyorsa ekipler sorunu çözmek için gereğinden geniş yeni kurallar ekleyebilir. Bu durum rule base'in daha da zor yönetilmesine yol açar. Düzenli anomaly analysis bu nedenle hem güvenlik hem operasyon kalitesi açısından önemlidir.

Firewall Rule Anomaly Türleri

Firewall rule anomaly, policy set içinde gereksiz, çakışan veya beklenmedik davranış oluşturan kural ilişkilerini ifade eder. Shadowed, redundant, duplicate, overlapping, conflicting, stale, orphaned ve zero-hit rule en yaygın örnekler arasındadır. Bu sorunların bazıları güvenlik açığı oluştururken bazıları operasyonu ve denetimi zorlaştırır. Rule sayısı arttıkça manuel kontrolün hata payı yükselir. Bu nedenle firewall yönetiminde düzenli otomatik analiz ve owner tabanlı recertification süreçleri kullanmak faydalıdır.

Shadowed Rule

Shadowed rule üstteki başka bir kural nedeniyle hiçbir trafikle eşleşmeyen rule'dur. Bu durum özel kuralın genel policy altında kalmasıyla ortaya çıkabilir. Hit count uzun süre sıfır olabilir, ancak bunun nedeni kesin olarak shadow olmayabilir. Kural ilişkileri karşılaştırılarak gerçek neden belirlenmelidir. Gereksiz shadow policy kaldırılmalı veya doğru sıraya taşınmalıdır.

Redundant Rule

Redundant rule kaldırıldığında firewall davranışını değiştirmeyen gereksiz politika satırıdır. Aynı erişim başka bir mevcut rule tarafından zaten sağlanıyor olabilir. Gereksiz kurallar policy set'i büyütür ve inceleme süresini uzatır. Büyük rule base üzerinde değişiklik yaparken hata ihtimalini de artırabilir. Redundant rule'lar analiz edilip owner onayı alındıktan sonra kontrollü şekilde temizlenmelidir.

Duplicate Rule

Duplicate rule aynı veya neredeyse aynı koşulları ve action değerini taşıyan birden fazla kuraldır. Genellikle farklı ekiplerin aynı ihtiyacı ayrı taleplerle açması veya geçmiş değişikliklerin yeterince kontrol edilmemesi nedeniyle oluşur. Duplicate policy teknik olarak bağlantıyı bozmayabilir, ancak yönetimi gereksiz yere zorlaştırır. Rule request aşamasında otomatik duplicate detection kullanmak bu sorunu azaltabilir. Mevcut duplicate kurallar birleştirilirken log, owner ve ticket bilgileri korunmalıdır.

Overlapping Rule

Overlapping rule iki veya daha fazla politikanın trafik alanının kısmen kesişmesidir. Örneğin biri /24 ağını, diğeri aynı alan içindeki /25 ağı kapsayabilir. Action değerleri aynıysa gereksiz yönetim yükü, farklıysa beklenmeyen güvenlik davranışı oluşabilir. Object group kullanımı overlap tespitini daha zor hâle getirebilir. Policy analyzer araçları bu nedenle özellikle büyük yapılarda önemli fayda sağlar.

Conflicting Rule

Conflicting rule benzer veya örtüşen trafik alanına farklı action uygulayan kurallardır. Biri allow, diğeri deny olabilir ve gerçek sonuç evaluation order'a bağlıdır. Bu durum çoğu zaman politika sahiplerinin farklı güvenlik beklentilerine sahip olduğunu gösterir. Teknik düzeltme yapmadan önce iş amacı ve güvenlik gereksinimi doğrulanmalıdır. Ardından tek ve anlaşılır politika oluşturularak gereksiz çatışma kaldırılmalıdır.

Stale Rule

Stale rule geçmişte gerekli olduğu hâlde artık kullanılmayan veya iş ihtiyacı sona ermiş kuraldır. Eski proje, kapatılmış uygulama veya tamamlanmış tedarikçi erişimi buna örnek olabilir. Kuralın hit alması bile hâlâ meşru olduğunu kanıtlamaz, çünkü beklenmeyen trafik kullanıyor olabilir. Owner doğrulaması ve uygulama envanteri birlikte değerlendirilmelidir. Stale erişimlerin kaldırılması saldırı alanını azaltmanın etkili yollarından biridir.

Orphaned Rule

Orphaned rule artık geçerli bir iş sahibi veya uygulama sahibi bulunmayan politikadır. Organizasyon değişiklikleri ve çalışan ayrılıkları bu durumu sık oluşturur. Owner bilinmediğinde kuralın hâlâ gerekli olup olmadığını doğrulamak zorlaşır. Firewall governance sürecinde her kuralın aktif owner bilgisi bulunmalıdır. Sahipsiz rule'lar risk değerlendirmesine alınmalı ve gerekli doğrulamalar yapıldıktan sonra temizlenmelidir.

Zero-Hit Rule

Zero-hit rule belirli izleme süresi boyunca hiçbir trafikle eşleşmemiş kuraldır. Bu bilgi gereksiz policy tespiti için değerli olsa da tek başına silme kararı vermek için yeterli değildir. Yıllık çalışan bir uygulama veya felaket kurtarma bağlantısı uzun süre hit üretmeyebilir. Owner ve uygulama takvimi doğrulanmalıdır. Güvenli yaklaşım kuralı önce disable etmek, gözlemlemek ve ardından silmektir.

Firewall Kurallarında Object ve Object Group Kullanımı

Object ve object group kullanımı firewall politikasının okunabilir ve yönetilebilir kalmasına yardımcı olur. IP adreslerini ve portları her rule içinde tekrar yazmak yerine anlamlı isimlerle tanımlanmış nesneler kullanılabilir. Örneğin ERP_DB_SERVERS veya DNS_SERVICES gibi nesneler rule'un amacını hızlı biçimde anlatır. Ancak object değişiklikleri aynı nesneyi kullanan birçok kuralı etkileyebildiği için impact analysis yapılmalıdır. İyi bir naming standardı ve change control süreci object tabanlı yönetimin temelidir.

Network Object

Network object tek bir IP adresini, subnet'i veya belirli ağ varlığını temsil eder. İyi isimlendirilmiş object rule okunabilirliğini artırır ve adres değişikliklerini merkezi şekilde yönetmeyi sağlar. Bir sunucunun IP adresi değiştiğinde tüm kuralları tek tek düzenlemek yerine object güncellenebilir. Bununla birlikte object'in kullanım yerleri değişiklikten önce kontrol edilmelidir. Yanlış network object değişikliği beklenenden çok daha fazla policy üzerinde etkili olabilir.

Service Object

Service object TCP veya UDP portu gibi servis tanımlarını merkezi hâle getirir. Örneğin özel bir uygulamanın kullandığı portlar tek bir service object altında tutulabilir. Bu yöntem aynı port setinin farklı kurallarda tekrar yazılmasını engeller. Uygulama portu değiştiğinde merkezi güncelleme yapılabilir. Ancak service object'e yeni port eklemek onu kullanan bütün kuralların erişim kapsamını genişletebileceği için change review yapılmalıdır.

Address Group

Address group birden fazla network object'i tek mantıksal grup altında toplar. Aynı role sahip sunucuların tek policy üzerinden yönetilmesini kolaylaştırır. Örneğin web sunucuları veya domain controller sistemleri ayrı gruplar hâlinde tutulabilir. Grup üyeliği değiştiğinde firewall policy otomatik olarak yeni üyeyi kapsayabilir. Bu nedenle address group yönetimi asset lifecycle süreçleriyle uyumlu olmalıdır.

Service Group

Service group birden fazla servis veya port tanımını tek grup altında toplar. Uygulamanın kullandığı TCP ve UDP servisleri ortak bir policy nesnesiyle temsil edilebilir. Bu yapı rule sayısını azaltabilir ve policy okunabilirliğini artırır. Ancak gruba gereksiz port eklemek onu kullanan tüm kuralların kapsamını genişletir. Service group değişikliklerinin de firewall rule change kadar kontrollü yürütülmesi gerekir.

FQDN Object

FQDN object IP adresi yerine alan adı temelinde hedef veya kaynak tanımlamak için kullanılabilir. IP adresi sık değişen SaaS veya internet servislerinde yönetim kolaylığı sağlayabilir. Firewall alan adını DNS üzerinden çözerek ilgili IP kayıtlarını policy için kullanabilir. DNS çözüm süresi, TTL davranışı ve çoklu IP cevapları cihazdan cihaza farklılık gösterebilir. Kritik erişimlerde FQDN object davranışı test edilmeden production kullanımına alınmamalıdır.

Object Kullanmanın Avantajları

Object kullanımı firewall policy'lerini daha anlaşılır ve sürdürülebilir hâle getirir. Teknik IP listeleri yerine işlevi anlatan isimler kullanıldığında hem güvenlik hem ağ ekipleri rule amacını daha hızlı anlayabilir. Merkezi değişiklik imkânı bakım süresini azaltır. Aynı zamanda standartlaşmış object yapısı otomasyon ve policy-as-code çalışmalarını kolaylaştırır. Bununla birlikte object yönetimi de erişim politikasının parçası olduğu için değişiklik kontrolünden bağımsız düşünülmemelidir.

Daha az rule

Object group kullanımı aynı erişim ihtiyacını ayrı ayrı rule yazmak yerine tek policy altında toplamayı sağlar. Bu sayede rule count azalabilir ve politika görünümü sadeleşir. Daha az kural inceleme ve recertification sürecini de kolaylaştırır. Ancak çok geniş object grupları least privilege ilkesini zayıflatmamalıdır. Gruplar teknik kolaylıktan önce ortak güvenlik gereksinimine göre oluşturulmalıdır.

Daha kolay bakım

Merkezi object yönetimi IP veya servis değişikliğinin tek noktadan yapılmasını sağlar. Özellikle çok sayıda rule içinde kullanılan uygulama sunucularında bu ciddi zaman kazandırabilir. Manuel olarak birçok kuralı düzenleme ihtiyacı azaldığı için hata ihtimali de düşer. Değişiklik öncesi object kullanım raporu alınması faydalıdır. Böylece tek object değişikliğinin hangi policy'leri etkileyeceği önceden görülebilir.

Daha okunabilir policy

Anlamlı object isimleri firewall rule'u teknik sayı dizilerinden daha anlaşılır hâle getirir. FINANCE_USERS_TO_ERP gibi isimler erişimin bağlamını hızlı şekilde gösterebilir. Bu durum audit ve troubleshooting sırasında büyük kolaylık sağlar. Naming convention ekipler arasında ortak kullanıldığında farklı firewall sistemlerinde bile tutarlılık oluşur. İsimler kısa, açık ve işlevi anlatacak biçimde seçilmelidir.

Daha güvenli değişiklik

Object tabanlı yapı doğru change control ile birlikte daha güvenli değişiklik yapılmasına yardımcı olur. Aynı servis setinin farklı kurallarda birbirinden farklı tanımlanması önlenebilir. Merkezi object üzerinden yapılan kontrollü güncelleme tutarsız policy riskini azaltır. Ancak yanlış grup üyeliği geniş etki oluşturabileceği için peer review uygulanmalıdır. Değişiklikten sonra ilgili rule hit ve bağlantı testleri mutlaka gerçekleştirilmelidir.

Zone-Based Firewall Tasarımı

Zone-based firewall tasarımı ağları güven seviyelerine ve işlevlerine göre güvenlik bölgelerine ayırır. Inside, Outside, DMZ, Management, Guest, Server, Production ve Development gibi zone'lar yaygın örneklerdir. Trafik politikası tek tek interface isimlerinden çok zone'lar arasındaki güven ilişkisine göre oluşturulur. Bu yöntem ağ büyüdükçe politika yönetimini kolaylaştırabilir. Zone tasarımına başlamadan önce veri akışlarını ve hangi sistemlerin birbirine gerçekten erişmesi gerektiğini çıkarmak önemlidir.

Security Zone Nedir?

Security zone benzer güven seviyesine ve erişim politikasına sahip sistemlerin mantıksal olarak gruplandığı alandır. Aynı zone içindeki trafik ve zone'lar arası trafik farklı kurallara tabi tutulabilir. Zone oluştururken yalnızca fiziksel ağ topolojisine bakmak yeterli değildir. Veri hassasiyeti, kullanıcı tipi ve uygulama rolü de dikkate alınmalıdır. İyi tanımlanmış zone sınırları firewall policy tasarımını daha anlaşılır hâle getirir.

Inside

Inside zone genellikle kurumsal iç kullanıcı veya güvenilir istemci ağlarını temsil eder. Ancak “inside” etiketi bu ağdaki her cihazın sınırsız güvenilir olduğu anlamına gelmemelidir. Kullanıcı cihazları ele geçirilebilir ve başka sistemlere saldırı kaynağı hâline gelebilir. Bu nedenle inside zone'dan server veya management zone'a erişim minimum gereksinimlerle sınırlandırılmalıdır. İnternet çıkışında da egress filtering ve uygulama politikaları uygulanabilir.

Outside

Outside zone çoğu tasarımda internet veya güvenilmeyen dış ağları temsil eder. Bu bölgeden iç sistemlere varsayılan olarak erişim verilmemelidir. Yayımlanması gereken servisler mümkünse DMZ gibi ayrı güvenlik bölgesinde tutulmalıdır. Management arayüzleri doğrudan outside zone'a açılmamalıdır. Gereken uzaktan yönetim erişimi VPN veya ZTNA gibi kontrollü mekanizmalar üzerinden sağlanmalıdır.

DMZ

DMZ internetten erişilmesi gereken servislerin iç ağdan ayrıldığı güvenlik bölgesidir. Web veya belirli gateway sistemleri burada konumlandırılabilir. İnternetten DMZ'ye yalnızca gerekli servis portları açılırken DMZ'den internal ağa erişim çok daha dar tutulmalıdır. Bir DMZ sunucusu ele geçirildiğinde saldırganın iç ağa geçememesi temel tasarım hedefidir. Yönetim trafiği de normal kullanıcı erişiminden ayrı bir yol üzerinden sağlanmalıdır.

Management

Management zone firewall, switch, hypervisor ve diğer kritik altyapı sistemlerinin yönetim arayüzlerini barındırır. Bu bölge normal kullanıcı ağlarından doğrudan erişilebilir olmamalıdır. Yalnızca yetkili administrator grupları, jump host veya güvenli erişim platformları üzerinden bağlantı kurabilmelidir. MFA ve admin session logging burada özellikle önemlidir. Management segmentinin internet çıkışı da yalnızca gerekli güncelleme ve yönetim servisleriyle sınırlandırılmalıdır.

Guest

Guest zone misafir kullanıcıların kurumsal sistemlerden ayrılması için kullanılır. Temel hedef internet erişimi sağlarken internal ağlara ulaşımı engellemektir. Client isolation kullanılarak misafir cihazların birbirine erişmesi de sınırlandırılabilir. Captive portal veya zaman sınırlı erişim politikaları ek kontrol sağlayabilir. Guest ağı kurumsal DNS, yönetim arayüzleri veya hassas uygulamalara doğrudan erişmemelidir.

Server

Server zone kurumsal uygulama ve servis sunucularının kullanıcı ağlarından ayrıldığı bölgedir. Kullanıcılar yalnızca gerekli uygulama portları üzerinden belirli sunuculara erişmelidir. Sunucuların birbirleriyle iletişimi de otomatik olarak güvenilir kabul edilmemelidir. Uygulama katmanları web, application ve database gibi ek zone'lara ayrılabilir. Bu ayrım olası bir sunucu ihlalinde diğer sistemlere geçişi sınırlar.

Production

Production zone canlı iş süreçlerini çalıştıran sistemleri içerir ve yüksek güvenlik kontrolü gerektirir. Development veya test sistemlerinden production'a geniş ağ erişimi verilmemelidir. Deployment, monitoring ve management bağlantıları açıkça tanımlanmış kanallardan geçmelidir. Production verisinin hassasiyetine göre ek mikro segmentasyon uygulanabilir. Değişiklikler maintenance window ve rollback planıyla yönetilmelidir.

Development

Development zone yazılım geliştirme ve test faaliyetleri için kullanılan sistemleri barındırır. Bu ortamlarda sık değişiklik yapıldığı için erişim ihtiyacı production'a kıyasla daha dinamik olabilir. Buna rağmen geniş internet ve internal erişim verilmesi doğru değildir. Geliştiricilerin ihtiyaç duyduğu repository, package source ve test servisleri açık biçimde tanımlanabilir. Production erişimi ise ayrı kimlik, approval ve time-bounded yöntemlerle kontrol edilmelidir.

Network Segmentation Nedir?

Network segmentation büyük bir ağı daha küçük ve güvenlik açısından anlamlı bölümlere ayırma yaklaşımıdır. Amaç yalnızca broadcast alanlarını küçültmek değil, farklı güven seviyeleri arasında kontrollü sınırlar oluşturmaktır. Kullanıcı, sunucu, IoT, misafir, yönetim ve kritik uygulama ağları birbirinden ayrılarak güvenlik politikaları uygulanabilir. Segmentasyon firewall, ACL, VRF, microsegmentation ve NAC gibi farklı teknolojilerle desteklenebilir. Doğru segmentasyon olası bir ihlalin tüm ağa yayılmasını zorlaştırır.

Segmentasyon Neden Gereklidir?

Tek ve geniş bir ağ yapısında cihazlar birbirine gereğinden fazla erişebilir. Bu durum güvenlik ihlalinde saldırganın yeni hedefler bulmasını kolaylaştırır. Segmentasyon her sistem grubuna farklı güvenlik politikası uygulanmasını sağlar. Ayrıca trafik akışları daha görünür hâle gelir ve hangi bağlantıların gerçekten gerekli olduğu anlaşılır. Kritik sistemleri sıradan kullanıcı cihazlarından ayırmak temel segmentasyon kullanım örneklerinden biridir.

Attack Surface Reduction

Segmentasyon erişilebilen servis sayısını azaltarak attack surface'i küçültür. Kullanıcı cihazları yalnızca ihtiyaç duydukları uygulamalara erişebiliyorsa geri kalan sunucu servisleri doğrudan görünmez. Bu durum zafiyet bulunan servislerin rastgele keşfedilmesini zorlaştırır. Firewall deny logları yetkisiz segment geçişlerini izlemek için kullanılabilir. Segment sınırları düzenli test edilerek beklenmeyen erişim yolları tespit edilmelidir.

Lateral Movement'ın Sınırlandırılması

Lateral movement'ın sınırlandırılması segmentasyonun en önemli güvenlik faydalarından biridir. Bir uç nokta ele geçirildiğinde saldırganın tüm sunucu ağına erişememesi hedeflenir. Zone ve firewall kuralları her geçişte yeniden erişim kontrolü uygular. Kritik sistemler için kullanıcı kimliği ve cihaz posture bilgisi de policy'ye eklenebilir. Bu yapı Zero Trust yaklaşımıyla birlikte kullanıldığında iç ağdaki varsayılan güveni önemli ölçüde azaltır.

Business-Critical Sistemlerin Ayrılması

Business-critical sistemlerin ayrı segmentlerde tutulması erişim kontrolünü daha net hâle getirir. Finans, insan kaynakları veya üretim gibi kritik uygulamalar genel kullanıcı ağından doğrudan erişilebilir olmamalıdır. Yalnızca gerekli kullanıcı grupları ve uygulama akışları tanımlanmalıdır. Yönetim erişimi normal kullanıcı bağlantısından ayrı tutulabilir. Bu ayrım hem güvenlik hem denetim süreçlerinde güçlü kanıt üretir.

Trust Boundary Oluşturma

Trust boundary farklı güven seviyelerine sahip sistemlerin birbirinden ayrıldığı mantıksal veya fiziksel sınırdır. Firewall bu sınırda erişim politikasını uygular ve log üretir. Bir boundary oluşturulurken hangi yönlerin güvenilir kabul edildiği açıkça tanımlanmalıdır. Modern yaklaşımda iç ağ otomatik olarak güvenilir sayılmaz. Her önemli zone geçişi doğrulanabilir bir güvenlik kararı olarak ele alınmalıdır.

VLAN Güvenlik Segmentasyonu İçin Yeterli midir?

VLAN ağları Layer 2 seviyesinde ayırmak için çok yararlı olsa da tek başına tam bir güvenlik kontrolü değildir. VLAN'lar arası trafik routing yapıldığında uygun firewall veya ACL politikası yoksa segmentler yine birbirine geniş biçimde erişebilir. Bu nedenle VLAN ile güvenlik segmentasyonu kavramlarını aynı şey olarak değerlendirmemek gerekir. VLAN ağ sınırını oluşturabilir, ancak bu sınırdaki erişim kararını ayrı bir güvenlik mekanizması vermelidir. Özellikle kritik sistemlerde inter-VLAN firewall kontrolü daha güçlü görünürlük sağlar.

VLAN'ın Görevi

VLAN fiziksel switch altyapısı üzerinde mantıksal Layer 2 ağlar oluşturur. Cihazların broadcast alanlarını ayırır ve ağ organizasyonunu kolaylaştırır. Kullanıcı, sunucu ve misafir cihazları farklı VLAN'larda tutulabilir. Ancak VLAN ID tek başına kimlik doğrulama veya servis bazlı erişim kontrolü sağlamaz. Güvenlik için routing noktalarında ek policy uygulanması gerekir.

Inter-VLAN Routing

Farklı VLAN'ların birbiriyle iletişim kurması için Layer 3 routing gerekir. Bu görev router, Layer 3 switch veya firewall tarafından gerçekleştirilebilir. Routing açık olduğunda uygun güvenlik kuralı yoksa VLAN'lar arasında geniş erişim oluşabilir. Bu nedenle inter-VLAN gateway noktasında ACL veya firewall politikası uygulanmalıdır. Kritik segmentler için stateful firewall kontrolü daha ayrıntılı log ve güvenlik bağlamı sunabilir.

VLAN'lar Arası Firewall

VLAN'lar arası firewall kullanımı her segment geçişini açık erişim politikasına bağlar. Kullanıcı VLAN'ından sunucu VLAN'ına yalnızca gerekli uygulama portları açılabilir. Management VLAN'ına ise daha sınırlı administrator erişimi verilebilir. Bu yapı lateral movement riskini azaltır ve trafik görünürlüğünü artırır. Firewall kapasitesi planlanırken iç ağdaki East-West trafik miktarı da hesaba katılmalıdır.

ACL ile VLAN İzolasyonu

ACL ile VLAN izolasyonu temel Layer 3 ve Layer 4 filtreleme gereken ortamlarda etkili olabilir. Örneğin guest VLAN'ın internal subnet'lere erişimi router ACL üzerinden engellenebilir. Bu yaklaşım düşük gecikme ve basit politika avantajı sağlayabilir. Ancak kullanıcı kimliği, application awareness veya threat inspection gerektiğinde ACL tek başına yeterli olmayabilir. Kritik segmentler için kontrol seviyesi risk değerlendirmesiyle belirlenmelidir.

Layer 2 Güvenlik Riskleri

VLAN kullanılması Layer 2 seviyesindeki bütün riskleri otomatik olarak ortadan kaldırmaz. Yanlış trunk konfigürasyonu, rogue switch, ARP spoofing veya DHCP kaynaklı sorunlar ayrı güvenlik kontrolleri gerektirir. Switch port security, DHCP snooping ve Dynamic ARP Inspection gibi özellikler değerlendirilebilir. 802.1X ile cihaz ve kullanıcı kimliği doğrulanabilir. Güvenli segmentasyon Layer 2 ve Layer 3 kontrollerinin birlikte planlanmasıyla sağlanır.

Macrosegmentation ve Microsegmentation

Macrosegmentation ağı büyük güvenlik bölgelerine ayırırken microsegmentation daha küçük iş yükleri ve uygulama bileşenleri arasında kontrol uygular. Her iki yaklaşım birbirinin alternatifi olmak zorunda değildir. Kullanıcı, sunucu ve misafir ağlarını macro düzeyde ayırıp kritik sunucular arasında microsegmentation uygulamak oldukça yaygın bir modeldir. Bulut ve konteyner ortamları microsegmentation için esnek politika mekanizmaları sunar. Hedef, ihtiyaç duyulmayan her East-West bağlantıyı varsayılan olarak sınırlandırmaktır.

Macrosegmentation Nedir?

Macrosegmentation büyük ağ gruplarının birbirinden ayrılmasıdır. Kullanıcı, veri merkezi, DMZ, IoT ve guest gibi zone'lar buna örnektir. Firewall veya router bu zone'lar arasındaki erişimi kontrol eder. Başlangıç için etkili ve yönetilebilir bir güvenlik modeli sağlar. Ancak aynı zone içinde çok sayıda kritik sistem bulunuyorsa ek mikro kontroller gerekebilir.

Microsegmentation Nedir?

Microsegmentation güvenlik politikasını tek tek workload, uygulama, pod veya servis seviyesine kadar daraltabilir. Aynı subnet içinde bulunan iki sunucu arasında bile erişim kuralı uygulanabilir. Bu yaklaşım özellikle veri merkezi ve bulut ortamlarında lateral movement'ı sınırlar. IP adresi yerine workload etiketi veya uygulama kimliği kullanılabilir. Politika sayısı hızla artabileceği için otomasyon ve merkezi yönetim önemlidir.

Workload-Based Policy

Workload-based policy erişim kararını fiziksel ağ konumundan çok iş yükünün kimliğine göre verir. Bir uygulama sunucusu farklı host veya subnet'e taşındığında security policy aynı rol etiketi üzerinden devam edebilir. Bu yapı dinamik bulut ortamlarında IP tabanlı kurallara göre daha esnektir. Workload etiketlerinin güvenilir kaynaktan gelmesi gerekir. Yanlış veya kötü yönetilen etiketler policy kapsamını beklenmedik biçimde değiştirebilir.

Application-Based Segmentation

Application-based segmentation bir uygulamanın web, API, worker ve database gibi bileşenlerini ayrı güvenlik alanlarında kontrol eder. Her bileşen yalnızca ihtiyaç duyduğu diğer servislerle konuşabilir. Örneğin web katmanı doğrudan tüm veri tabanı ağlarına değil yalnızca ilgili application service'e erişebilir. Bu yapı saldırganın tek bir bileşenden tüm uygulamaya yayılmasını zorlaştırır. Uygulama veri akışı dokümanı bu politikaların doğru oluşturulması için temel kaynaktır.

Zero Trust ile Microsegmentation

Zero Trust ve microsegmentation birbirini güçlü şekilde tamamlayan yaklaşımlardır. Zero Trust her erişim talebini kimlik, cihaz ve bağlam üzerinden doğrulamayı hedefler. Microsegmentation ise ağ tarafında bu erişimin yalnızca gerekli hedefe ulaşmasını sağlar. Kullanıcı doğrulanmış olsa bile tüm veri merkezi ağına erişim verilmez. Böylece kimlik tabanlı kontrol ile network enforcement birlikte çalışır.

DMZ Firewall Kuralları Nasıl Tasarlanmalıdır?

DMZ firewall kuralları internetten erişilmesi gereken servislerle internal ağ arasındaki güvenlik sınırını korumalıdır. Temel yaklaşım internetten yalnızca yayımlanan servislere izin vermek, DMZ'den internal ağa ise son derece dar erişim tanımlamaktır. DMZ sistemlerinin yönetim trafiği normal uygulama akışından ayrılmalıdır. Sunucu ele geçirilmesi ihtimali düşünülerek outbound bağlantılar da kontrol edilmelidir. DMZ tasarımında “hangi bağlantılar gerekir?” kadar “hangi bağlantılar kesinlikle olmamalıdır?” sorusu da önemlidir.

Internet → DMZ

Internet → DMZ kuralları yalnızca yayımlanan servislerin gerekli portlarını açmalıdır. Bir web sunucusu için örneğin HTTPS erişimi gerekli olabilir, ancak SSH veya yönetim arayüzü internete açılmamalıdır. Kaynak ülke, IP veya threat intelligence gibi ek kontroller ihtiyaç varsa değerlendirilebilir. WAF veya IPS katmanı uygulama riskini azaltmak için kullanılabilir. Her public servis düzenli vulnerability assessment ve log izleme sürecine dahil edilmelidir.

DMZ → Internal

DMZ → Internal erişim en dar kapsamda tutulması gereken trafik yönlerinden biridir. Bir web sunucusunun uygulama sunucusuna bağlanması gerekiyorsa yalnızca belirli hedef ve port açılmalıdır. DMZ cihazının tüm internal subnet'e erişmesi doğru değildir. Veri tabanı bağlantısı gerekiyorsa ilgili database server ve servis dışında başka hedeflere izin verilmemelidir. Bu kurallar loglanmalı ve owner bilgisiyle düzenli olarak gözden geçirilmelidir.

Internal → DMZ

Internal → DMZ erişim normal kullanıcılar ve administratorlar için ayrı politikalarla yönetilebilir. Kullanıcıların public web servislerine internal adres üzerinden erişmesi gerekiyorsa yalnızca uygulama portları açılır. Yönetim bağlantıları ise jump host veya management zone üzerinden yapılmalıdır. Böylece administrator erişimi normal kullanıcı trafiğinden ayrılır. Kimlik tabanlı policy kullanılması yönetim yetkilerinin daha kontrollü uygulanmasını sağlar.

DMZ → Internet

DMZ → Internet trafiğinin tamamen açık bırakılması ciddi egress riskleri doğurabilir. DMZ sunucuları yalnızca gerekli DNS resolver, update repository veya dış API servislerine erişmelidir. Bir sunucu ele geçirildiğinde geniş internet çıkışı saldırganın komuta altyapısıyla iletişim kurmasını kolaylaştırabilir. Proxy veya belirli FQDN object'ler kontrollü çıkış için kullanılabilir. Deny logları beklenmeyen outbound bağlantıları tespit etmek için SIEM'e gönderilebilir.

Database Erişiminin Sınırlandırılması

Database erişimi DMZ tasarımında en hassas bağlantılardan biridir. Mümkün olduğunda internet-facing web sistemi doğrudan database'e değil application katmanına bağlanmalıdır. Doğrudan bağlantı gerekiyorsa yalnızca belirli source host, destination database ve port tanımlanmalıdır. Database yönetim portları DMZ'den erişilebilir olmamalıdır. SQL bağlantıları ve failed connection kayıtları güvenlik izlemesinde ayrıca takip edilmelidir.

Management Trafiğinin Ayrılması

Management trafiğinin uygulama trafiğinden ayrılması DMZ güvenliğini önemli ölçüde artırır. Administrator erişimi ayrı management zone, jump host ve MFA üzerinden sağlanabilir. SSH, RDP veya web management arayüzleri public network'e açılmamalıdır. Management session kayıtları merkezi log sisteminde tutulmalıdır. Acil durum erişimleri de break-glass süreci ve süre sınırıyla yönetilmelidir.

Egress Filtering Nedir?

Egress filtering kurum içinden internete veya başka dış ağlara giden trafiğin güvenlik kurallarıyla kontrol edilmesidir. Birçok ekip inbound korumaya yoğunlaşırken outbound iletişimi ikinci plana atar. Oysa kötü amaçlı yazılımlar komuta sunucularına ulaşmak, veri aktarmak veya başka altyapılarla iletişim kurmak için dış bağlantıya ihtiyaç duyar. Bu nedenle server ve kullanıcı ağları için farklı egress politikaları oluşturulmalıdır. Uygun proxy, DNS ve firewall logları birlikte değerlendirildiğinde dış trafik görünürlüğü belirgin şekilde artar.

Outbound Trafik Neden Kontrol Edilmelidir?

Outbound trafiğin kontrol edilmesi içerideki her cihazın internete sınırsız erişimini engeller. Kullanıcı bilgisayarlarının erişim ihtiyacı ile sunucuların erişim ihtiyacı aynı değildir. Bir database sunucusunun internette rastgele hedeflere doğrudan bağlantı kurması çoğu ortamda gereksizdir. Gerekli repository, DNS ve API hedefleri açıkça tanımlanabilir. Bu yaklaşım hem malware communication hem de yanlış yapılandırılmış uygulamaların tespitini kolaylaştırır.

Malware Command-and-Control

Malware command-and-control bağlantıları ele geçirilmiş cihazın saldırgan altyapısıyla iletişim kurmasını sağlar. Geniş outbound erişim bu bağlantının kurulmasını kolaylaştırabilir. Firewall application control, threat intelligence ve DNS logları C2 davranışlarını tespit etmek için kullanılabilir. Bilinen malicious IP veya domain listeleri dinamik blok politikalarına eklenebilir. False positive riskini azaltmak için otomatik blokların süre ve doğrulama mekanizması bulunmalıdır.

Data Exfiltration

Data exfiltration kurum verisinin yetkisiz biçimde dışarı aktarılmasıdır. Kontrolsüz internet çıkışı saldırganın veya kötü niyetli kullanıcının çok sayıda dış hedefe veri göndermesine imkân verebilir. Proxy, firewall ve DLP kontrolleri birlikte kullanıldığında görünürlük artar. Beklenmeyen yüksek hacimli outbound bağlantılar SIEM üzerinde alarm üretebilir. Kritik sunucuların internet erişimini allowlist modeliyle sınırlandırmak etkili bir savunma yöntemidir.

DNS Egress

DNS egress politikası iç cihazların hangi DNS resolver'lara sorgu gönderebileceğini belirler. Kullanıcı ve sunucuların yalnızca kurumsal DNS resolver sistemlerini kullanması tercih edilebilir. Doğrudan harici DNS bağlantıları firewall üzerinden engellenebilir. Bu sayede DNS logları merkezi hâle gelir ve şüpheli domain sorguları daha kolay izlenir. DoH ve DoT gibi şifreli DNS yöntemleri için ayrıca uygulama ve egress politikası oluşturulmalıdır.

SMTP Egress

SMTP egress kontrolü istemci ve sunucuların doğrudan internet üzerindeki mail sunucularına bağlantısını sınırlar. Normal kullanıcı cihazlarının doğrudan TCP 25 üzerinden e-posta göndermesi çoğu kurumsal ortamda gerekli değildir. Yalnızca yetkili mail relay veya gateway sistemlerine outbound SMTP izni verilebilir. Bu yaklaşım ele geçirilmiş cihazların spam göndermesini zorlaştırır. Firewall deny logları beklenmeyen SMTP davranışlarını tespit etmek için kullanılabilir.

Direct Internet Access

Direct internet access cihazın arada proxy veya ek güvenlik kontrolü olmadan internete bağlanmasıdır. Kullanıcı ağlarında bazı servisler için gerekli olabilir, ancak server zone için kapsamı daha dar tutulabilir. Doğrudan bağlantı gerektiğinde destination, application veya FQDN kriterleri kullanılabilir. Çok geniş internet erişimi verilmesi yerine iş ihtiyacı olan servisler tanımlanmalıdır. TLS inspection veya application control ihtiyacı risk değerlendirmesine göre ayrıca ele alınabilir.

Proxy Üzerinden Çıkış

Proxy üzerinden internet çıkışı web trafiğini merkezi noktada kontrol etmeyi ve loglamayı kolaylaştırır. Firewall yalnızca proxy sunucularının internete doğrudan erişmesine izin verebilir. Kullanıcı veya sunucu ağlarının TCP 80 ve 443 ile doğrudan dış bağlantıları engellenebilir. Böylece URL filtreleme ve kullanıcı bazlı kayıtlar daha merkezi şekilde yönetilebilir. Proxy yüksek erişilebilirlik ve kapasite açısından kritik altyapı bileşeni olarak tasarlanmalıdır.

DNS Trafiği İçin Firewall Kuralları

DNS küçük paketlerle çalışan basit bir servis gibi görünse de ağ güvenliğinde önemli bir kontrol noktasıdır. Kötü amaçlı yazılımlar domain çözümleme için DNS kullanabildiği gibi DNS tunneling üzerinden veri aktarımı da yapabilir. Bu nedenle kurum içindeki istemcilerin yalnızca belirlenmiş DNS resolver'lara erişmesi güçlü bir temel politikadır. Resolver sistemlerinin internette hangi DNS servisleriyle iletişim kuracağı ayrıca tanımlanmalıdır. DNS sorgu loglarının merkezi olarak izlenmesi tehdit tespiti ve olay inceleme açısından büyük değer sağlar.

Internal DNS Resolver

Internal DNS resolver istemci ve sunucuların domain sorgularını merkezi olarak çözer. Firewall politikası istemcilerin yalnızca bu resolver IP'lerine TCP ve UDP 53 üzerinden ulaşmasına izin verebilir. Bu yapı doğrudan dış DNS kullanımını azaltır ve sorgu loglarını merkezi hâle getirir. Resolver üzerinde zararlı domain filtreleme uygulanabilir. Yüksek erişilebilirlik için birden fazla DNS resolver kullanılması ve firewall object group içinde yönetilmesi faydalıdır.

Direct External DNS'i Engellemek

Direct external DNS'i engellemek iç cihazların internet üzerindeki rastgele DNS sunucularına sorgu göndermesini önler. Bu sayede güvenlik filtrelerinin atlatılması zorlaşır. Firewall yalnızca kurumun yetkili resolver sistemlerinin dış DNS hizmetlerine erişmesine izin verebilir. Engellenen TCP veya UDP 53 bağlantıları loglanarak yanlış yapılandırılmış cihazlar bulunabilir. IoT cihazlarının sabit dış DNS kullanmaya çalışması gibi durumlar ayrıca değerlendirilmelidir.

DNS over HTTPS

DNS over HTTPS, DNS sorgularını HTTPS trafiği içinde taşır ve klasik port 53 filtresini aşabilir. Kullanıcıların tarayıcı üzerinden kendi DoH servislerini seçmesi merkezi DNS görünürlüğünü azaltabilir. NGFW application identification veya DNS policy özellikleri bu trafiği tanımaya yardımcı olabilir. Kurumun kendi güvenilir DoH resolver'ı varsa yalnızca bu hedefe erişim verilebilir. Politika oluştururken kullanıcı gizliliği, güvenlik görünürlüğü ve uygulama uyumluluğu birlikte değerlendirilmelidir.

DNS over TLS

DNS over TLS genellikle TCP 853 üzerinden şifreli DNS iletişimi sağlar. Kurumsal cihazların doğrudan harici DoT sunucularına bağlanması merkezi resolver politikasını aşabilir. Firewall üzerinden TCP 853 erişimi yalnızca yetkili resolver veya servisler için açılabilir. Ancak uygulamaların farklı tünel yöntemleri kullanabileceği unutulmamalıdır. DNS güvenliği yalnızca port engellemeye değil endpoint ve application policy kontrollerine de dayanmalıdır.

DNS Tunneling

DNS tunneling DNS sorgu ve yanıtlarını veri taşıma kanalı olarak kullanır. Uzun, alışılmadık veya yüksek frekanslı domain sorguları bu davranışın göstergelerinden biri olabilir. Firewall tek başına tüm tunneling türlerini tespit edemeyebilir. DNS analytics ve SIEM correlation bu nedenle önemli destek sağlar. İç cihazların yalnızca kontrollü resolver'lara erişmesi analiz için gereken merkezi görünürlüğü oluşturur.

DNS Logging

DNS logging sorgulanan domain, kaynak IP, zaman ve sonuç gibi bilgilerin kaydedilmesini sağlar. Bu veriler firewall loglarıyla birleştirildiğinde şüpheli bağlantının hangi domain çözümlemesinden başladığı görülebilir. Incident response sırasında geçmiş DNS kayıtları çok değerli olabilir. Log saklama süresi kurumun risk ve mevzuat ihtiyaçlarına göre belirlenmelidir. Hassasiyet nedeniyle DNS loglarına erişim de ayrı yetki kontrolleriyle korunmalıdır.

ICMP Firewall Kuralları Nasıl Olmalıdır?

ICMP tamamen kapatılması gereken gereksiz bir protokol değildir. Ağ teşhisi, hata bildirimleri ve Path MTU Discovery gibi önemli görevleri vardır. IPv6 ise bazı temel ağ işlevleri için ICMPv6'ya daha fazla bağımlıdır. Bu nedenle güvenli politika, tüm ICMP'yi kör biçimde engellemek yerine gerekli message type'ları ve yönleri kontrollü şekilde tanımlamaktır. İnternetten gelen yoğun veya kötüye kullanılan ICMP trafiği için rate limiting uygulanabilir.

ICMP'yi Tamamen Engellemek Neden Sorun Yaratabilir?

ICMP'nin tamamını engellemek troubleshooting ve ağ protokollerinin doğru çalışması açısından sorun oluşturabilir. Path MTU Discovery belirli ICMP mesajlarına ihtiyaç duyabilir. Bu mesajlar engellendiğinde bazı bağlantılar kısmen çalışıyor gibi görünürken büyük paketlerde başarısız olabilir. IPv6 ortamında ICMPv6'nın temel işlevleri daha da önemlidir. Bu nedenle hangi ICMP türlerinin gerekli olduğu ağ mimarisine göre belirlenmelidir.

Ping

Ping ICMP Echo Request ve Echo Reply mesajlarını kullanarak temel erişilebilirlik testi yapar. Her sisteme internetten ping izni verilmesi şart değildir. Yönetim veya monitoring subnet'lerinden belirli sunuculara ping erişimi yararlı olabilir. ICMP yanıt vermemesi sistemin kapalı olduğu anlamına gelmediği için güvenlik değeri abartılmamalıdır. Rate limit ve kaynak sınırlaması ile kontrollü ping politikası oluşturulabilir.

Path MTU Discovery

Path MTU Discovery bağlantı yolundaki maksimum paket boyutunu belirlemek için ICMP hata mesajlarından yararlanabilir. Gerekli mesajların engellenmesi bazı uygulamalarda garip bağlantı problemleri oluşturabilir. Özellikle VPN ve tünel kullanılan ağlarda MTU konusu daha sık ortaya çıkar. Firewall politikası ilgili ICMP mesajlarına kontrollü şekilde izin vermelidir. Sorun giderirken sadece TCP portlarına değil ICMP loglarına da bakmak önemlidir.

IPv6 ve ICMPv6

IPv6 ağlarında ICMPv6 Neighbor Discovery ve çeşitli temel protokol işlevleri için gereklidir. Bu nedenle IPv4'te uygulanan “ICMP'yi tamamen kapat” yaklaşımının IPv6'ya doğrudan taşınması doğru değildir. Router Advertisement, Neighbor Solicitation ve gerekli hata mesajları anlaşılmalıdır. Güvenlik duvarı type ve code bazında uygun kontrol sağlayabilir. IPv6 policy tasarımı ayrı test ve dokümantasyon gerektirir.

Rate Limiting

Rate limiting belirli ICMP trafik türlerinin saniyedeki miktarını sınırlar. Bu yöntem gerekli ağ işlevlerini tamamen engellemeden kötüye kullanım riskini azaltabilir. Özellikle public servislerde yoğun ping veya hata mesajı trafiği kaynak tüketebilir. Eşik değerleri normal trafik ölçümlerine göre belirlenmelidir. Çok düşük limitler gerçek ağ sorunlarının görünürlüğünü veya protokol işleyişini etkileyebilir.

IPv6 Firewall Politikaları

IPv6 aktif olan bir ağda yalnızca IPv4 firewall kurallarına güvenmek ciddi bir görünürlük boşluğu oluşturabilir. İşletim sistemleri ve uygulamalar IPv6 bağlantısını otomatik olarak tercih edebilir. Dual-stack ortamlarında aynı güvenlik hedefleri hem IPv4 hem IPv6 için açık biçimde uygulanmalıdır. ICMPv6 ve Neighbor Discovery gibi IPv6'ya özgü davranışlar ayrıca değerlendirilmelidir. Kullanılmayan IPv6'nın kontrolsüz şekilde açık kalması yerine ya güvenli politika ile yönetilmesi ya da gerçekten ihtiyaç yoksa planlı biçimde devre dışı bırakılması gerekir.

IPv4 Rule'ları IPv6'yı Korur mu?

IPv4 için yazılmış firewall rule'lar çoğu platformda IPv6 trafiğini otomatik olarak kapsamaz. Aynı servis IPv6 adresi üzerinden erişilebilir durumda olabilir. Bu nedenle policy audit sırasında hem IPv4 hem IPv6 kural tabanları incelenmelidir. Public DNS kayıtlarında AAAA kaydı bulunan servisler özellikle kontrol edilmelidir. Güvenlik testi yalnızca IPv4 adreslerine yapılırsa önemli açıklar gözden kaçabilir.

IPv6 Default Deny

IPv6 için de default deny yaklaşımı uygulanmalıdır. Gerekli bağlantılar açıkça tanımlanmalı, diğer trafik varsayılan olarak engellenmelidir. IPv4 tarafında sıkı politika varken IPv6'nın geniş izinli bırakılması saldırgan için alternatif yol oluşturabilir. Network object ve zone yapılarına IPv6 adresleri dahil edilmelidir. Değişiklik ve recertification süreçleri IPv6 policy'lerini de kapsamalıdır.

ICMPv6

ICMPv6 IPv6'nın temel çalışma mekanizmalarının önemli parçasıdır. Neighbor Discovery, router discovery ve Path MTU gibi işlevlerde kullanılır. Tüm ICMPv6 trafiğini engellemek bağlantı sorunlarına yol açabilir. Gerekli type'lar resmi protokol gereksinimlerine göre kontrollü şekilde izinli tutulmalıdır. Şüpheli veya gereksiz ICMPv6 türleri loglanıp sınırlandırılabilir.

Neighbor Discovery

Neighbor Discovery IPv6 ağında komşu cihaz ve router bilgisinin bulunmasını sağlar. IPv4 ARP işlevine benzer bazı görevleri ICMPv6 mesajları üzerinden gerçekleştirir. Güvenlik politikası bu trafiği tamamen kesmemelidir. Layer 2 güvenlik özellikleri rogue advertisement risklerine karşı ayrıca kullanılabilir. Özellikle kurumsal access network tasarımında IPv6 first-hop security özellikleri değerlendirilmelidir.

Dual-Stack Network Riskleri

Dual-stack ağlarda cihazlar hem IPv4 hem IPv6 kullanabilir ve iki ayrı saldırı yüzeyi oluşur. Güvenlik kontrolleri yalnızca bir protokol ailesine odaklanırsa diğeri atlama yolu hâline gelebilir. Asset inventory her iki adres türünü de içermelidir. SIEM ve monitoring sistemleri IPv6 loglarını doğru parse edebilmelidir. Vulnerability scanning ve penetration testing süreçlerine de IPv6 hedefleri eklenmelidir.

Unmonitored IPv6 Problemi

Unmonitored IPv6, ağda IPv6 trafiği mevcut olduğu hâlde güvenlik ve monitoring araçlarının bunu izlememesi durumudur. Modern işletim sistemleri varsayılan olarak IPv6'yı etkinleştirebilir. Kullanıcılar farkında olmadan IPv6 üzerinden dış bağlantı kurabilir. Firewall ve packet capture araçlarının IPv6 görünürlüğü kontrol edilmelidir. Ağ ekibi IPv6 kullanılmıyor varsayımı yerine gerçek trafik ölçümüne göre karar vermelidir.

NAT ile Firewall Rule Arasındaki İlişki

NAT ve firewall sıkça aynı cihaz üzerinde çalıştığı için bazen aynı güvenlik işlevi olarak düşünülür. NAT adres veya port bilgisini dönüştürür, firewall ise bağlantıya izin verilip verilmeyeceğini belirler. Bir servisin NAT ile public IP'ye çevrilmesi o servisin otomatik olarak güvenli olduğu anlamına gelmez. DNAT ve port forwarding kuralları mutlaka uygun access policy ile birlikte değerlendirilmelidir. Ayrıca farklı firewall platformlarının policy matching işlemini NAT öncesi veya sonrası adreslere göre yapması değişikliklerde dikkat gerektirir.

NAT Güvenlik Kontrolü müdür?

NAT temel amacı adres dönüştürme olan bir ağ fonksiyonudur ve tek başına erişim güvenlik politikası olarak görülmemelidir. İç IP adreslerinin internette doğrudan görünmemesi bazı dolaylı faydalar sağlayabilir. Ancak yanlış port forwarding tüm servisi internetten erişilebilir hâle getirebilir. Gerçek erişim kontrolü firewall rule ile sağlanmalıdır. NAT policy ve security policy birlikte incelenmeden public exposure değerlendirmesi tamamlanmış sayılmaz.

SNAT

SNAT kaynak IP adresinin bağlantı çıkışında farklı bir adrese çevrilmesidir. İnternet çıkışında private adreslerin public IP ile değiştirilmesi yaygın örnektir. Firewall loglarında pre-NAT ve post-NAT source bilgisinin bulunması olay inceleme açısından önemlidir. Çok sayıda kullanıcı aynı public IP'yi kullanıyorsa kaynak cihazı bulmak için port ve zaman bilgisine ihtiyaç duyulabilir. SIEM entegrasyonunda NAT loglarının doğru korelasyonu sağlanmalıdır.

DNAT

DNAT hedef IP adresini bağlantı sırasında farklı bir iç adrese çevirir. Public servis yayımlama senaryolarında yaygın kullanılır. Örneğin internet üzerindeki public IP 443 portu DMZ web sunucusuna yönlendirilebilir. Bunun yanında security policy yalnızca gerçekten gerekli trafik için izin vermelidir. DNAT rule oluşturulduğunda otomatik olarak hangi firewall policy'nin etkilendiği doğrulanmalıdır.

Port Forwarding

Port forwarding dışarıdaki belirli IP ve portu iç ağdaki servisle eşleştirir. Yönetim servislerini doğrudan port forwarding ile internete açmak ciddi risk oluşturabilir. Public web servisi gibi zorunlu durumlarda kaynak, destination ve güvenlik profilleri sınırlandırılmalıdır. Mümkün olduğunda yönetim erişimi VPN veya ZTNA üzerinden sağlanmalıdır. Eski veya unutulmuş port forwarding rule'lar düzenli olarak denetlenmelidir.

NAT Öncesi ve Sonrası Rule Matching

Firewall platformları security policy eşleşmesini pre-NAT veya post-NAT adreslere göre yapabilir. Bu davranış üretici ve mimariye göre değiştiği için yeni rule yazmadan önce doğrulanmalıdır. Yanlış adres kullanımı kuralın hiç eşleşmemesine veya gereğinden geniş erişime yol açabilir. Loglarda original ve translated adres alanlarının bulunması troubleshooting'i kolaylaştırır. NAT ve security policy değişiklikleri birlikte test edilmelidir.

Public Service Exposure

Public service exposure internetten erişilen her servisin risk seviyesini artırır. Bu nedenle yalnızca iş için gerekli servisler public hâle getirilmelidir. Yönetim portları, database servisleri ve iç API'ler mümkün olduğunda doğrudan internetten erişilmemelidir. WAF, IPS, rate limiting ve güçlü authentication ek güvenlik katmanları sağlayabilir. Public servis envanteri düzenli tarama ve vulnerability management sürecine bağlanmalıdır.

Application-Aware Firewall Politikaları

Application-aware firewall politikaları ağ trafiğini yalnızca IP ve portla değil gerçek uygulama kimliğiyle kontrol eder. Bu özellik web tabanlı uygulamaların aynı portu paylaşması nedeniyle giderek daha önemli hâle gelmiştir. Kullanıcıların genel HTTPS erişimine ihtiyacı olabilir, ancak bu durum tüm uygulama kategorilerinin serbest bırakılması gerektiği anlamına gelmez. Firewall uygulama imzaları ve trafik davranışını kullanarak daha ayrıntılı karar verebilir. Politika tasarımında uygulama erişimi iş rolü ve kullanıcı gruplarıyla birlikte değerlendirildiğinde daha etkili sonuç alınır.

Port Tabanlı Kontrol Neden Yetersiz Kalabilir?

Birçok modern uygulama TCP 443 üzerinden çalıştığı için yalnızca port bazlı kural çok geniş erişim oluşturabilir. Aynı porttan iş uygulaması, dosya paylaşımı, tünel veya başka servisler geçebilir. Port açık olduğunda firewall klasik Layer 4 yaklaşımında bu uygulamaları ayırt edemez. Application identification kullanılması daha dar politika oluşturmayı sağlar. Bununla birlikte şifreli trafik görünürlüğü ve privacy gereksinimleri de tasarımın parçası olmalıdır.

Layer 7 Application Identification

Layer 7 application identification trafik içeriği ve davranış özelliklerini kullanarak uygulamayı tanımaya çalışır. Port bilgisi tek başına karar vermek için kullanılmaz. Bu sayede standart dışı portta çalışan uygulamalar da belirli ölçüde tespit edilebilir. Uygulama tanıma sonucu policy ve log alanlarında kullanılabilir. İmzaların güncelliği ve unknown application oranı düzenli olarak izlenmelidir.

Application Default Port

Application default port, bir uygulamanın normalde kullanması beklenen servis portudur. Bazı firewall sistemleri uygulamaya yalnızca varsayılan portunda izin verme seçeneği sunar. Bu yöntem aynı uygulamanın beklenmeyen portlarda çalışmasını sınırlar. Ancak özel kurulumlarda farklı port kullanılması gerekiyorsa gerçek ihtiyaç doğrulanmalıdır. Kullanılmayan geniş service tanımları bu sayede azaltılabilir.

Port Hopping

Port hopping bir uygulamanın bağlantı engellerini aşmak için farklı portlara geçebilmesini ifade eder. Klasik port bazlı policy bu trafiği tanımakta zorlanabilir. Application-aware firewall protokol özelliklerine bakarak uygulamayı farklı portta da tespit edebilir. Bu tür davranış özellikle yetkisiz tünel veya P2P trafiğinde önemli olabilir. Erişim politikası iş ihtiyacı ve risk seviyesine göre uygulanmalıdır.

SaaS Application Control

SaaS application control kurumun hangi bulut tabanlı uygulamalara erişileceğini yönetmesini sağlar. Kullanıcılar tarayıcı üzerinden çok sayıda SaaS servisine ulaşabildiği için yalnızca URL bazlı kontrol her zaman yeterli olmayabilir. Firewall uygulama, domain ve kullanıcı bilgisini birlikte değerlendirebilir. Hassas veri paylaşım riski bulunan servisler ek kontrol gerektirebilir. SaaS politikası güvenlik, iş birimi ve veri koruma ekiplerinin ortak kararıyla oluşturulmalıdır.

Riskli Uygulamaların Engellenmesi

Riskli uygulamalar tünel, anonymizer, yetkisiz dosya paylaşımı veya bilinmeyen uzak erişim araçlarını içerebilir. Firewall application control bu uygulamaları kategorilere göre engelleyebilir veya yalnızca belirli kullanıcı gruplarına açabilir. Blind block yaklaşımı yerine iş ihtiyacını anlamak önemlidir. Gerekli uygulama için güvenli alternatif veya kontrollü kullanım politikası oluşturulabilir. Engelleme logları kullanıcı eğitimleri ve güvenlik farkındalığı için de yararlı veri sağlar.

Identity-Aware Firewall Nedir?

Identity-aware firewall erişim kararını yalnızca IP adresine değil kullanıcı veya cihaz kimliğine göre verebilir. DHCP ve mobil çalışma ortamlarında IP adresleri sık değiştiği için kimlik tabanlı politika daha anlamlı olabilir. Kullanıcı grubu, rol ve authentication sonucu access rule içinde kullanılabilir. Yönetim uygulamaları veya hassas sistemler için kimlik ve ağ bilgisini birlikte kontrol etmek güçlü bir yöntemdir. Bu yaklaşım NAC ve Zero Trust modelleriyle de doğal biçimde bütünleşir.

IP Adresi Yerine Kullanıcı Kimliği

IP adresi ağdaki konumu gösterir, ancak her zaman gerçek kullanıcıyı güvenilir şekilde ifade etmez. Aynı cihaz farklı kişiler tarafından kullanılabilir veya kullanıcı farklı IP'lerle bağlanabilir. Identity mapping sayesinde firewall aktif kullanıcı ile IP adresini ilişkilendirebilir. Policy daha sonra “finans grubu” gibi kullanıcı bağlamıyla oluşturulabilir. Kimlik verisinin güncel ve doğru olması policy güvenliği açısından temel gereksinimdir.

Active Directory

Active Directory kurumsal Windows ortamlarında kullanıcı ve grup bilgilerinin merkezi kaynağı olarak firewall ile entegre edilebilir. Firewall grup üyeliğini kullanarak erişim politikası uygulayabilir. Örneğin yalnızca Network-Admins grubuna management zone erişimi verilebilir. Grup değişiklikleri merkezi dizinden yönetildiği için firewall policy'nin yeniden yazılması gerekmez. Ayrıcalıklı gruplar için MFA ve düzenli membership review eklenmelidir.

LDAP

LDAP dizin servislerinden kullanıcı ve grup bilgisi almak için kullanılan yaygın protokollerden biridir. Firewall LDAP üzerinden kimlik doğrulama veya grup sorgulaması yapabilir. Bağlantının TLS ile korunması ve servis hesabının minimum yetkiye sahip olması önemlidir. LDAP entegrasyonu kesildiğinde firewall'ın nasıl davranacağı önceden belirlenmelidir. Fail-open yaklaşımı kritik sistemlerde istenmeyen erişim oluşturabileceği için dikkatle değerlendirilmelidir.

RADIUS

RADIUS ağ erişimi ve administrator authentication senaryolarında yaygın kullanılan AAA protokolüdür. Firewall yöneticilerinin merkezi kimlik doğrulaması RADIUS üzerinden yapılabilir. NAC ve 802.1X altyapılarında da önemli rol oynar. Kullanıcı rolü veya grup bilgisi RADIUS attribute'larıyla taşınabilir. RADIUS sunucularının yüksek erişilebilirliği ve loglarının SIEM'e gönderilmesi operasyon açısından önemlidir.

SAML/OIDC

SAML ve OIDC modern web tabanlı kimlik federasyonu için kullanılan yaklaşımlardır. Firewall yönetim portalı, VPN veya ZTNA servisleri kurumsal identity provider ile entegre olabilir. Bu sayede merkezi MFA ve conditional access politikaları uygulanabilir. Kullanıcı hesapları tek noktadan yönetildiği için ayrılan çalışanların erişimi daha hızlı kapatılabilir. Kimlik token'larının süreleri ve claim yapıları erişim politikasına uygun biçimde tasarlanmalıdır.

User-to-IP Mapping

User-to-IP mapping aktif kullanıcının hangi IP adresini kullandığını firewall'a bildirir. Bu bilgi login event, endpoint agent, directory integration veya başka kaynaklardan alınabilir. Mapping yanlış veya eski olduğunda policy yanlış kullanıcıya uygulanabilir. DHCP değişiklikleri ve shared workstation kullanımı bu nedenle dikkate alınmalıdır. Mapping doğruluğu izlenmeli ve stale kayıtlar otomatik olarak temizlenmelidir.

Identity-Based Rule

Identity-based rule erişim kararına kullanıcı veya grup bilgisini ekler. Örneğin sadece belirli teknik ekip üyelerine SSH erişimi verilebilir. Aynı subnet'te bulunan diğer kullanıcılar aynı IP aralığında olsalar bile policy'den yararlanamaz. Cihaz posture ve MFA gibi ek koşullar erişim güvenliğini daha da güçlendirebilir. Kimlik temelli policy'ler düzenli RBAC incelemesiyle desteklenmelidir.

Erişim Denetimi Nedir?

Erişim denetimi bir kullanıcı, cihaz veya uygulamanın hangi kaynağa hangi koşullarda ulaşabileceğini belirleyen süreçlerin bütünüdür. Authentication kim olduğunu, authorization ne yapabileceğini, accounting ise yapılan işlemlerin kaydını ele alır. Network access control bu kavramları ağ bağlantısına uygular. Firewall ise verilen ağ yetkisini trafik seviyesinde enforce eden önemli bileşenlerden biridir. İyi erişim denetimi yalnızca bağlantı anında değil erişimin tüm yaşam döngüsü boyunca uygulanır.

Authentication

Authentication kullanıcının veya cihazın iddia ettiği kimliği doğrulama işlemidir. Parola, sertifika, güvenlik anahtarı veya MFA gibi yöntemler kullanılabilir. Ağ erişiminde yalnızca parola yerine güçlü çok faktörlü doğrulama tercih edilmelidir. Cihaz authentication için certificate tabanlı 802.1X kullanılabilir. Doğrulama başarılı olsa bile bu aşama kullanıcıya otomatik olarak tüm kaynaklara erişim hakkı vermemelidir.

Authorization

Authorization doğrulanmış kimliğin hangi kaynaklara erişebileceğini belirler. Kullanıcı rolü, cihaz tipi, lokasyon, risk seviyesi ve iş ihtiyacı kararın parçası olabilir. RBAC en yaygın yetkilendirme modellerinden biridir. Firewall veya ZTNA sistemi bu kararları ağ ve uygulama seviyesinde uygulayabilir. Yetkiler düzenli recertification süreçleriyle tekrar doğrulanmalıdır.

Accounting

Accounting erişim ve kullanım olaylarının kaydedilmesini ifade eder. Kullanıcının ne zaman bağlandığı, hangi kaynağa eriştiği ve oturum süresi gibi bilgiler tutulabilir. Bu kayıtlar audit ve incident investigation için değer taşır. Administrator erişimlerinde command logging veya session recording ek olarak kullanılabilir. Logların değiştirilmesini önleyen merkezi saklama yapısı kurulmalıdır.

AAA Modeli

AAA modeli Authentication, Authorization ve Accounting kavramlarını tek çerçevede ele alır. Ağ cihazı yönetimi, VPN ve NAC gibi birçok sistem bu modele dayanır. Kullanıcı önce doğrulanır, ardından rolüne göre yetkilendirilir ve yapılan işlemler kaydedilir. Merkezi AAA altyapısı erişim politikalarını standardize etmeyi kolaylaştırır. Yüksek erişilebilirlik ve güvenli protokol kullanımı AAA tasarımının önemli parçalarıdır.

Network Access Control ile İlişkisi

Network Access Control kullanıcının veya cihazın ağa bağlanmadan önce ve bağlandıktan sonra belirli koşulları karşılamasını sağlar. Kimlik doğrulama, cihaz profili ve endpoint posture bilgisi üzerinden erişim seviyesi belirlenebilir. Firewall ise NAC tarafından belirlenen segment veya policy sonucunu ağ trafiğinde uygulayabilir. Dynamic VLAN veya dynamic ACL entegrasyonu bu iş birliğine örnektir. Böylece erişim kararı kullanıcı ve cihaz bağlamına göre dinamikleşir.

Role-Based Access Control (RBAC)

RBAC erişim haklarını tek tek kullanıcılara vermek yerine iş rollerine bağlar. Bu yaklaşım personel sayısı arttıkça yetki yönetimini kolaylaştırır. Kullanıcının görevi değiştiğinde rol üyeliği güncellenerek ilgili network ve uygulama erişimleri birlikte değiştirilebilir. Firewall administrator yetkileri için de read-only, policy editor ve approver gibi ayrı roller kullanılabilir. RBAC düzenli role review ve separation of duties uygulamalarıyla daha güçlü hâle gelir.

Role Nedir?

Role belirli iş görevini veya sorumluluk setini temsil eden yetki grubudur. Finans analisti, network operator veya security reviewer gibi roller oluşturulabilir. Her role yalnızca görev için gereken izinler atanmalıdır. Kullanıcılar ihtiyaçlarına göre bir veya daha fazla role dahil edilebilir. Rol tanımları çok geniş olmamalı ve düzenli olarak iş gereksinimleriyle karşılaştırılmalıdır.

Kullanıcı Grupları

Kullanıcı grupları benzer erişim ihtiyacına sahip hesapları merkezi şekilde yönetmeyi sağlar. Active Directory veya başka identity provider sistemlerinde oluşturulan gruplar firewall policy ile eşleştirilebilir. Grup üyeliği değiştiğinde erişim hakkı otomatik güncellenebilir. Kritik gruplar için approval ve periyodik membership review uygulanmalıdır. Shared account kullanmak yerine kişisel kullanıcı hesaplarının gruplara eklenmesi audit kalitesini artırır.

İş Rolüne Göre Network Access

İş rolüne göre network access her çalışanın yalnızca görevinde kullandığı ağ kaynaklarına erişmesini amaçlar. İnsan kaynakları çalışanının üretim yönetim ağına erişmesi gerekmiyorsa policy bunu engellemelidir. Rol bazlı firewall veya NAC kuralları bu ayrımı otomatik uygulayabilir. Departman değişikliği sırasında eski roller kaldırılmalıdır. Joiner, mover ve leaver süreçlerinin identity sistemiyle entegre olması stale access riskini azaltır.

Least Privilege ile RBAC

RBAC tek başına geniş roller oluşturulduğunda least privilege sağlamaz. Her rolün içindeki izinler minimum iş ihtiyacına göre tasarlanmalıdır. “IT” gibi çok geniş rol yerine network operator, server admin ve security analyst gibi ayrımlar yapılabilir. Kritik erişimler ayrıca time-bounded veya approval tabanlı olabilir. Rol analizi kullanıcı sayısından çok erişim ihtiyacının niteliğine odaklanmalıdır.

Firewall Administrator RBAC

Firewall administrator RBAC yönetim yetkilerini ekip içinde görev bazında ayırır. Bir kullanıcı yalnızca logları görüntüleyebilirken başka kullanıcı policy taslağı oluşturabilir. Approval yetkisi farklı bir rolde tutularak separation of duties uygulanabilir. Super admin hesabı yalnızca zorunlu durumlarda kullanılmalıdır. Tüm administrator oturumları kişisel hesaplarla ve merkezi loglama üzerinden takip edilmelidir.

Network Access Control (NAC) Nedir?

NAC ağa bağlanan kullanıcı ve cihazların kimliğini, türünü ve güvenlik durumunu değerlendirerek erişim seviyesi belirleyen kontrol sistemidir. Firewall genellikle trafik akışına karar verirken NAC bağlantı yapan endpoint'in ağa hangi şartlarla katılacağını yönetir. 802.1X, RADIUS, cihaz profiling ve posture check sık kullanılan NAC bileşenleridir. Uygun olmayan cihazlar quarantine ağına alınabilir veya yalnızca remediation servislerine erişebilir. NAC özellikle BYOD ve IoT yoğun kurumsal ağlarda erişim görünürlüğünü artırır.

NAC'ın Firewall'dan Farkı

NAC ve firewall farklı noktalarda güvenlik kararı verir. NAC cihazın ağa girişini ve hangi segmente yerleşeceğini kontrol ederken firewall segmentler arası trafik izinlerini uygular. NAC cihaz kimliği, kullanıcı ve posture bilgisine daha yakın çalışır. Firewall ise uygulama, port ve hedef bazlı bağlantı kontrolünde güçlüdür. İki sistem entegre edildiğinde identity ve network enforcement aynı politika zincirinin parçaları hâline gelir.

Kullanıcı Kimliği

NAC kullanıcı kimliğini 802.1X, captive portal veya identity provider entegrasyonu üzerinden doğrulayabilir. Kullanıcının grup üyeliği hangi VLAN veya ACL'nin atanacağını belirleyebilir. Misafir, çalışan ve administrator kullanıcıları farklı erişim seviyelerine yönlendirilebilir. Shared cihazlarda kullanıcı değişimi policy'nin de güncellenmesini gerektirebilir. Authentication kayıtları merkezi log sistemine gönderilmelidir.

Device Identity

Device identity ağa bağlanan endpoint'in hangi cihaz olduğunu belirlemeyi amaçlar. Sertifika, MAC adresi, endpoint agent veya MDM bilgisi kullanılabilir. MAC adresi tek başına kolay değiştirilebildiği için güçlü kimlik olarak görülmemelidir. Kurumsal cihazlarda certificate tabanlı authentication daha güvenilir seçenek sunar. Cihaz kimliği kullanıcı kimliğiyle birlikte değerlendirildiğinde erişim kontrolü daha güçlü hâle gelir.

Device Profiling

Device profiling ağa bağlanan cihazın türünü trafik ve protokol özelliklerinden tahmin etmeye çalışır. Printer, IP phone, kamera veya IoT cihazları bu yöntemle farklı sınıflara ayrılabilir. Profil sonucu uygun VLAN ve firewall policy ile eşleştirilebilir. Profiling yüzde yüz güvenilir olmadığı için kritik cihazlarda ek doğrulama kullanılmalıdır. Yeni veya bilinmeyen cihazlar sınırlı erişim bölgesine alınabilir.

Endpoint Posture

Endpoint posture cihazın güvenlik durumunu değerlendiren kontroller bütünüdür. İşletim sistemi sürümü, disk şifreleme, EDR durumu ve yönetim kaydı incelenebilir. Policy gereksinimlerini karşılamayan cihazın erişimi azaltılabilir. Kullanıcıya remediation adımları gösterilerek cihaz tekrar uyumlu hâle getirilebilir. Posture politikalarının iş süreçlerini gereksiz yere engellememesi için aşamalı uygulanması faydalıdır.

Policy Enforcement

Policy enforcement NAC kararının ağ altyapısında uygulanmasını ifade eder. Dynamic VLAN, downloadable ACL, switch port policy veya firewall entegrasyonu kullanılabilir. Kullanıcı rolü değiştiğinde yeni policy otomatik olarak uygulanabilir. Enforcement başarısız olduğunda sistemin fail-open veya fail-close davranışı önceden belirlenmelidir. Kritik ağlarda yüksek erişilebilir NAC altyapısı büyük önem taşır.

Quarantine

Quarantine güvenlik koşullarını karşılamayan cihazın sınırlı erişim alanına alınmasıdır. Cihaz yalnızca update server, antivirus veya remediation portal gibi gerekli sistemlere ulaşabilir. Internal uygulamalara ve internete erişim tamamen veya kısmen sınırlandırılabilir. Kullanıcı gerekli düzeltmeleri yaptıktan sonra posture tekrar kontrol edilir. Quarantine süreci açık kullanıcı mesajlarıyla desteklenirse help desk yükü azalabilir.

802.1X ile Ağ Erişim Kontrolü

802.1X kablolu veya kablosuz ağ bağlantısında kullanıcı ve cihaz kimliğini doğrulamak için kullanılan standart tabanlı erişim kontrolü yaklaşımıdır. Supplicant, authenticator ve authentication server temel bileşenleridir. Başarılı authentication sonrasında kullanıcıya dinamik VLAN veya ACL atanabilir. Sertifika tabanlı yöntemler parola tabanlı doğrulamaya göre güçlü cihaz kimliği sağlayabilir. Kurumsal NAC tasarımlarında 802.1X ağ giriş kontrolünün önemli parçalarından biridir.

Supplicant

Supplicant 802.1X authentication sürecini istemci tarafında yürüten yazılım veya işletim sistemi bileşenidir. Laptop, telefon veya başka endpoint üzerinde çalışabilir. Kullanıcı bilgisi veya cihaz sertifikasını authenticator'a iletir. Kurumsal cihazlarda supplicant ayarları MDM veya merkezi policy ile dağıtılabilir. Yanlış profil veya sertifika süresi dolması bağlantı sorunlarının yaygın nedenlerindendir.

Authenticator

Authenticator genellikle switch veya wireless access point olarak görev yapar. Supplicant ile authentication server arasında 802.1X mesajlarını taşır. Kullanıcı doğrulanana kadar portu sınırlı durumda tutabilir. Başarılı sonuç sonrasında VLAN veya ACL gibi authorization bilgilerini uygular. Switch ve access point konfigürasyonlarının NAC politikasıyla tutarlı olması gerekir.

Authentication Server

Authentication server çoğunlukla RADIUS sunucusu olarak görev yapar. Kullanıcı veya cihaz kimliğini directory, certificate authority veya başka identity kaynaklarıyla doğrular. Sonuca göre access-accept veya access-reject cevabı döner. Grup ve policy bilgileri ek RADIUS attribute'larıyla gönderilebilir. Yüksek erişilebilirlik için birden fazla authentication server kullanılması önerilir.

RADIUS

RADIUS 802.1X ortamında authentication ve authorization mesajlarının taşınmasında merkezi rol oynar. Switch veya access point RADIUS client olarak NAC sunucusuyla iletişim kurar. Accounting bilgileri de RADIUS üzerinden kaydedilebilir. Shared secret ve ağ erişimi güvenli biçimde yönetilmelidir. Mümkün olan ortamlarda daha güçlü koruma seçenekleri ve güvenli transport yöntemleri değerlendirilmelidir.

Certificate-Based Authentication

Certificate-based authentication cihaz veya kullanıcı kimliğini dijital sertifika üzerinden doğrular. Parola saldırılarına karşı daha güçlü bir seçenek olabilir. Kurumsal PKI, certificate enrollment ve renewal süreçleri bu yapının temelidir. Süresi dolmuş veya iptal edilmiş sertifikalar otomatik erişim reddine yol açmalıdır. Certificate lifecycle yönetimi 802.1X projesinin başından itibaren planlanmalıdır.

Dynamic VLAN

Dynamic VLAN authentication sonucuna göre istemcinin otomatik olarak belirli VLAN'a atanmasını sağlar. Çalışan, misafir, IoT veya karantina cihazları farklı segmentlere yerleştirilebilir. Fiziksel switch portunun sabit VLAN'a bağlı olması gerekmez. Bu yöntem kullanıcı hareketliliğinde esneklik sağlar. VLAN ataması firewall policy ve IP address management süreciyle uyumlu olmalıdır.

Dynamic ACL

Dynamic ACL kullanıcı veya cihaz kimliğine göre switch üzerinde geçici erişim listesi uygulanmasını sağlar. Aynı fiziksel VLAN içindeki istemcilere farklı network access seviyeleri verilebilir. NAC sunucusu authorization sonucunda ilgili ACL bilgisini cihaza iletebilir. ACL yaşam döngüsü kullanıcı oturumuyla birlikte yönetilebilir. Bu yaklaşım çok sayıda statik ACL yazma ihtiyacını azaltabilir.

Device Posture Check Nedir?

Device posture check ağa erişmek isteyen cihazın güvenlik gereksinimlerini karşılayıp karşılamadığını kontrol eder. İşletim sistemi güncelliği, disk şifreleme, EDR durumu, host firewall ve kurumsal yönetim kaydı yaygın kontrol alanlarıdır. Amaç yalnızca kullanıcı kimliğini doğrulamak değil, bağlantıyı yapan cihazın kabul edilebilir güvenlik seviyesinde olmasını sağlamaktır. Uyumlu olmayan cihazlar sınırlı erişime veya quarantine ağına yönlendirilebilir. Posture kuralları kullanıcı deneyimini bozmadan risk bazlı uygulanmalıdır.

İşletim Sistemi Güncel mi?

Güncel olmayan işletim sistemleri bilinen güvenlik açıklarına karşı savunmasız olabilir. NAC veya endpoint management sistemi işletim sistemi sürümünü ve patch seviyesini kontrol edebilir. Kritik güncellemesi eksik cihazın hassas ağlara erişimi sınırlanabilir. Kullanıcıya güncelleme yapabileceği remediation kaynağı sağlanmalıdır. Politika belirlenirken farklı işletim sistemi sürümleri ve business continuity ihtiyacı dikkate alınmalıdır.

Disk Encryption Açık mı?

Disk encryption cihaz kaybolduğunda veya çalındığında verinin korunmasına yardımcı olur. Posture check cihazda kurumun onayladığı disk şifreleme mekanizmasının aktif olup olmadığını kontrol edebilir. Özellikle dizüstü bilgisayarlar için bu önemli bir uyumluluk kriteridir. Şifreleme anahtarlarının merkezi recovery süreciyle yönetilmesi gerekir. Uyumlu olmayan cihazlara hassas uygulama erişimi verilmemesi değerlendirilebilir.

EDR Çalışıyor mu?

EDR endpoint üzerindeki tehditleri tespit etmek ve müdahale etmek için kullanılan önemli güvenlik kontrolüdür. NAC cihazın EDR agent durumunu, son check-in zamanını veya policy uyumluluğunu sorgulayabilir. Agent devre dışı veya uzun süredir bağlantısızsa erişim seviyesi düşürülebilir. Kritik administrator cihazlarında bu kontrol daha sıkı uygulanabilir. EDR ve NAC entegrasyonu incident durumunda otomatik network isolation için de kullanılabilir.

Firewall Aktif mi?

Host firewall cihazın kendi üzerindeki inbound ve outbound bağlantıları kontrol eder. Kurumsal posture policy host firewall'ın aktif ve doğru profile bağlı olmasını şart koşabilir. Network firewall bulunması endpoint firewall ihtiyacını ortadan kaldırmaz. Özellikle aynı kullanıcı VLAN'ındaki cihazlar arasında ek koruma sağlar. Policy kullanıcı tarafından kolayca kapatılamayacak biçimde merkezi yönetilmelidir.

Cihaz Kurumsal Olarak Yönetiliyor mu?

Kurumsal yönetim kaydı cihazın MDM, UEM veya endpoint management platformuna bağlı olduğunu gösterir. Managed cihazlara daha geniş iş uygulaması erişimi verilirken unmanaged cihazlar sınırlı tutulabilir. Certificate veya device compliance bilgisi kimlik doğrulama sırasında kullanılabilir. BYOD senaryolarında kişisel cihazlara yalnızca web tabanlı veya düşük riskli servisler açılabilir. Cihaz sahipliği access policy'nin açık parametrelerinden biri olmalıdır.

Non-Compliant Device Quarantine

Non-compliant cihazların doğrudan ağdan tamamen çıkarılması her zaman en kullanışlı çözüm değildir. Quarantine ağı cihazın update ve remediation servislerine erişmesini sağlayabilir. Kullanıcı gerekli düzeltmeyi yaptıktan sonra posture tekrar değerlendirilir. Kritik ihlal veya malware tespitinde ise erişim tamamen kesilebilir. Quarantine politikalarının help desk ve incident response süreçleriyle uyumlu olması gerekir.

BYOD Erişim Politikaları

BYOD çalışanların kişisel cihazlarını kurumsal kaynaklara erişmek için kullanmasıdır. Kişisel cihaz ile kurumun tam yönettiği endpoint aynı güven seviyesinde değerlendirilmemelidir. BYOD policy hangi uygulamaların açılacağını, hangi verinin indirilebileceğini ve hangi network segmentinin kullanılacağını açık biçimde tanımlamalıdır. NAC, MDM veya ZTNA bu erişimi kontrol etmek için kullanılabilir. Kullanıcı gizliliği ve kurum güvenliği arasında dengeli politika oluşturmak önemlidir.

Corporate Device vs Personal Device

Corporate device kurumun güvenlik ayarlarını ve yazılımlarını doğrudan yönetebildiği cihazdır. Personal device üzerinde aynı seviyede kontrol veya görünürlük bulunmayabilir. Bu nedenle iki cihaz türüne aynı network access hakları verilmemelidir. Kurumsal cihaz kritik uygulamalara erişebilirken kişisel cihaz yalnızca belirli web servislerine yönlendirilebilir. Device identity policy kararında açık biçimde kullanılmalıdır.

BYOD Network Segment

BYOD cihazları ayrı network segmentinde tutmak internal sistemlere doğrudan erişimi sınırlar. Bu segment internet ve gerekli uygulama gateway'lerine erişebilir. Yönetim, server ve üretim ağlarına doğrudan routing veya firewall izni verilmemelidir. NAC cihaz tipini tespit ederek dinamik VLAN atayabilir. BYOD segmentinin DNS ve web trafiği de merkezi güvenlik kontrollerinden geçirilebilir.

MDM/UEM Entegrasyonu

MDM veya UEM entegrasyonu cihazın kayıtlı, şifreli ve policy uyumlu olup olmadığını doğrulamaya yardımcı olur. NAC veya ZTNA sistemi bu uyumluluk bilgisini access decision içinde kullanabilir. Kayıttan çıkarılan cihazın erişimi otomatik olarak azaltılabilir. Kurumsal veri için container veya uygulama bazlı kontrol uygulanabilir. Kişisel cihazlarda hangi bilgilerin toplandığı kullanıcıya açık şekilde anlatılmalıdır.

Limited Access

Limited access kişisel veya düşük güven seviyesindeki cihazlara yalnızca gerekli kaynakların açılmasıdır. Örneğin e-posta ve belirli SaaS uygulamalarına web üzerinden erişim verilebilir. Internal SMB, RDP veya yönetim protokolleri kapalı tutulabilir. Download veya copy gibi uygulama kontrolleri gerekiyorsa ek güvenlik mekanizmaları kullanılabilir. Erişim seviyesi kullanıcının rolü ve cihaz posture bilgisine göre dinamikleşebilir.

Guest Internet Access

BYOD kullanım amacı yalnızca internet erişimiyse guest ağı uygun bir seçenek olabilir. Bu durumda cihazın internal DNS ve kurumsal uygulamalara erişimi engellenir. Client isolation ile cihazların birbirine bağlantısı sınırlandırılabilir. Captive portal kullanım şartlarını göstermek için kullanılabilir. Guest internet trafiği kapasite ve güvenlik açısından ayrı politika altında izlenmelidir.

IoT Cihazları İçin Network Access Control

IoT cihazları genellikle klasik kullanıcı bilgisayarlarından farklı işletim sistemleri ve yönetim yöntemleri kullandığı için ayrı güvenlik yaklaşımı gerektirir. Kamera, sensör, yazıcı veya akıllı cihazların yalnızca görevleri için gerekli sistemlerle iletişim kurması hedeflenmelidir. NAC device profiling yoluyla cihaz türünü belirleyebilir ve uygun segmente atayabilir. Firewall ise internet ve East-West trafik erişimini sınırlar. IoT güvenliğinde en etkili yöntemlerden biri cihazları varsayılan olarak ayrı ve kısıtlı zone içinde tutmaktır.

IoT Device Profiling

IoT device profiling cihazın DHCP, DNS, MAC vendor ve trafik davranışı gibi özelliklerinden türünü belirlemeye çalışır. Bu bilgi cihazın doğru VLAN'a veya güvenlik politikasına atanmasını sağlayabilir. Profil sonucu kesin kimlik doğrulama yerine destekleyici sinyal olarak kullanılmalıdır. Tanınmayan cihazlar restricted zone'a alınabilir. Envanter ve profiling sonuçları düzenli olarak karşılaştırılmalıdır.

Default Credentials Riski

IoT cihazlarında varsayılan kullanıcı adı ve parola kullanımı önemli bir güvenlik riskidir. Cihaz devreye alınırken default credentials mutlaka değiştirilmelidir. Mümkünse merkezi authentication veya sertifika desteği kullanılmalıdır. Yönetim arayüzü yalnızca management zone'dan erişilebilir olmalıdır. Firewall segmentasyonu yanlış parola riskinin ağ çapındaki etkisini azaltmaya yardımcı olur.

IoT Segmentasyonu

IoT cihazları kullanıcı ve sunucu ağlarından ayrı segmentte tutulmalıdır. Kamera sistemlerinin veri tabanı veya domain controller gibi servislere genel erişime ihtiyacı yoktur. Her cihaz sınıfı için gerekli DNS, NTP ve application server akışları tanımlanabilir. Aynı segment içindeki cihazlar arasında client isolation veya microsegmentation uygulanabilir. Bu yapı ele geçirilmiş IoT cihazının başka sistemlere erişmesini zorlaştırır.

Internet Erişiminin Sınırlandırılması

Birçok IoT cihazına tamamen açık internet erişimi vermek gereksizdir. Firmware update veya cloud service ihtiyacı varsa yalnızca gerekli hedeflere izin verilebilir. FQDN veya proxy tabanlı egress kontrolü kullanılabilir. Beklenmeyen outbound bağlantılar loglanmalı ve güvenlik analizi yapılmalıdır. Cihaz üretici servislerinin değişmesi durumunda policy güncelleme süreci planlanmalıdır.

East-West Trafiğin Engellenmesi

IoT cihazlarının birbirine doğrudan erişmesi çoğu kullanım senaryosunda gerekli değildir. Bir kameranın başka bir kameraya SSH veya web bağlantısı başlatması şüpheli olabilir. Client isolation veya firewall microsegmentation ile East-West iletişim engellenebilir. Yalnızca merkezi controller veya management server bağlantıları izinli tutulabilir. Bu yaklaşım IoT tabanlı lateral movement riskini önemli ölçüde azaltır.

Anormal Davranış Tespiti

IoT cihazlarının trafik profili genellikle kullanıcı bilgisayarlarına göre daha öngörülebilirdir. Bu nedenle normal davranıştan sapmalar güvenlik sinyali olarak kullanılabilir. Yeni ülkelere bağlantı, farklı portlar veya yoğun outbound trafik alarm üretebilir. Firewall ve NAC logları SIEM üzerinde korele edilebilir. Tespit edilen cihaz otomatik veya onaylı süreçle quarantine ağına alınabilir.

Guest Network Güvenliği

Guest network ziyaretçilere internet erişimi sağlarken kurumsal sistemleri koruyan ayrı ağ alanıdır. Bu ağ internal route ve servislerden mümkün olduğunca izole edilmelidir. Kullanıcılar yalnızca internet çıkışı almalı ve diğer misafir cihazlarla doğrudan iletişimleri sınırlanmalıdır. Captive portal, time limit ve bandwidth control gibi özellikler işletim kolaylığı sağlar. Guest firewall policy düzenli olarak test edilerek internal network erişiminin gerçekten engellendiği doğrulanmalıdır.

Internal Network İzolasyonu

Guest network'ün temel güvenlik kuralı internal network erişimini engellemektir. RFC1918 adresleri ve kurumun public veya private internal subnet'leri deny listesinde tutulabilir. Yalnızca gerekli DNS veya captive portal servisleri istisna olarak tanımlanmalıdır. Firewall deny logları yanlış routing veya policy sorunlarını ortaya çıkarabilir. Guest ve corporate wireless altyapısının VLAN ve authentication seviyesinde ayrılması gerekir.

Internet-Only Access

Internet-only access misafir cihazlarına yalnızca dış internet servislerine erişim verir. Kurumsal uygulamalar, printer, file server ve yönetim sistemleri kapalı tutulur. DNS hizmeti güvenli resolver üzerinden sağlanabilir. Abuse riskini azaltmak için web security veya rate limit politikaları uygulanabilir. İnternet çıkışı ayrı public IP üzerinden sağlanırsa log ve olay inceleme daha anlaşılır olabilir.

Client Isolation

Client isolation aynı guest ağına bağlı cihazların birbirleriyle doğrudan iletişim kurmasını engeller. Bu özellik ortak Wi-Fi ortamlarında cihazlar arası saldırı riskini azaltır. Wireless access point veya switch seviyesinde uygulanabilir. Bazı servislerin cihazlar arası iletişim ihtiyacı varsa istisnalar dikkatle tasarlanmalıdır. Guest kullanımında varsayılan olarak isolation açık tutulması genellikle uygun yaklaşımdır.

Captive Portal

Captive portal kullanıcı internete çıkmadan önce bir web sayfası üzerinden giriş veya kullanım şartı onayı sağlar. Misafir hesapları süreli olarak oluşturulabilir. Portal kimlik doğrulaması güçlü network security yerine ek erişim kontrolü olarak görülmelidir. HTTPS ve güvenilir sertifika kullanımı önemlidir. Portal logları kullanıcı gizliliği ve kurum politikalarıyla uyumlu saklanmalıdır.

Time-Limited Access

Time-limited access misafir hesabının veya cihaz erişiminin belirli süre sonunda otomatik kapanmasını sağlar. Günlük ziyaretçiler veya etkinlik katılımcıları için kullanışlıdır. Süresiz guest account birikmesini önler. Sponsor onayı veya otomatik self-service kayıt kullanılabilir. Süre dolduğunda aktif session ve ilgili authorization kaydı da sonlandırılmalıdır.

Bandwidth Control

Bandwidth control guest kullanıcıların kurumsal internet kapasitesini aşırı tüketmesini engeller. Kullanıcı veya cihaz başına hız limiti uygulanabilir. Kritik kurumsal trafiğe QoS ile öncelik verilebilir. Çok düşük limit kullanıcı deneyimini gereksiz yere bozabileceği için gerçek kullanım ölçülmelidir. Guest trafik hacmi capacity planning verisi olarak düzenli izlenebilir.

Zero Trust Network Access Nedir?

Zero Trust Network Access, kullanıcının ağa bağlanmış olmasını otomatik güven göstergesi kabul etmeyen erişim yaklaşımıdır. Kullanıcı kimliği, cihaz durumu, hedef uygulama ve bağlantı bağlamı her erişim kararında değerlendirilir. Amaç kullanıcıya tüm network segmentini açmak yerine yalnızca ihtiyaç duyduğu uygulamaya erişim vermektir. Bu model özellikle remote access senaryolarında klasik geniş VPN erişimini daraltabilir. Zero Trust tek ürün değil, kimlik, cihaz, ağ ve uygulama kontrollerinin birlikte çalıştığı bir güvenlik modelidir.

Never Trust, Always Verify

Never Trust, Always Verify yaklaşımı iç ağda olmak gibi tek bir özelliği güven için yeterli kabul etmez. Her bağlantı talebi kimlik ve bağlam üzerinden doğrulanır. Daha önce doğrulanmış kullanıcı bile yeni risk sinyalleri oluştuğunda tekrar kontrol edilebilir. Bu yaklaşım ele geçirilmiş hesapların uzun süre sınırsız erişim kullanmasını zorlaştırır. Ağ policy'si güven varsayımı yerine açık doğrulamaya dayanır.

Explicit Verification

Explicit verification erişim kararının belirli ve ölçülebilir sinyallere dayanmasıdır. Kullanıcı kimliği, MFA sonucu, cihaz uyumluluğu, lokasyon ve risk seviyesi bu sinyaller arasında olabilir. Tek bir faktör yerine birden fazla bağlam birlikte değerlendirilir. Kritik uygulamalar daha güçlü doğrulama şartı gerektirebilir. Policy kararları loglanarak daha sonra audit edilebilir.

Least Privilege

Zero Trust içinde least privilege kullanıcının yalnızca ihtiyaç duyduğu uygulama ve işlem alanına erişmesini hedefler. Network-level broad access yerine application-level access tercih edilir. Administrator yetkileri sürekli açık tutulmak yerine gerektiğinde verilebilir. Kullanıcı rolü değiştiğinde eski erişimler otomatik kaldırılmalıdır. Firewall ve ZTNA policy'leri ortak erişim modeline göre tasarlanmalıdır.

Assume Breach

Assume breach yaklaşımı ağ içindeki bir cihazın veya hesabın ele geçirilmiş olabileceğini varsayar. Bu nedenle iç network sınırsız güvenilir bölge olarak tasarlanmaz. Segmentasyon ve continuous verification olası saldırgan hareketini sınırlar. Log ve detection sistemleri iç ağ trafiğini de izler. Böylece güvenlik yalnızca dış saldırıları engellemeye değil ihlal sonrası etkiyi azaltmaya da odaklanır.

Continuous Verification

Continuous verification erişimin yalnızca login anında değil oturum boyunca değerlendirilmesini ifade eder. Cihaz posture bozulursa veya risk seviyesi yükselirse aktif erişim yeniden kısıtlanabilir. Identity provider, EDR ve ZTNA sistemi bu sinyalleri paylaşabilir. Uzun süreli session'larda tekrar authentication istenebilir. Bu yaklaşım kalıcı ve değişmeyen güven varsayımını azaltır.

Application-Level Access

Application-level access kullanıcıya bütün subnet yerine belirli uygulamaya erişim verir. Kullanıcı uygulamanın arkasındaki network adreslerini veya diğer servisleri doğrudan göremeyebilir. Bu yapı remote access saldırı alanını azaltabilir. Uygulama kimliği, kullanıcı rolü ve cihaz güvenliği aynı policy içinde değerlendirilebilir. Ancak network firewall ve segmentasyon yine altyapı seviyesinde koruma sağlamaya devam eder.

Zero Trust Firewall'ın Yerini Alır mı?

Zero Trust yaklaşımı firewall'ın yerini doğrudan alan tek bir teknoloji değildir. Kimlik ve uygulama seviyesinde erişimi güçlendirirken network enforcement ve segmentasyon ihtiyacı devam eder. Firewall veri merkezleri, bulut ağları, internet sınırı ve East-West trafik için önemli kontrol noktasıdır. ZTNA özellikle kullanıcıdan uygulamaya erişimde daha dar bağlantı modeli sağlayabilir. En güçlü sonuç kimlik, firewall, NAC, segmentation ve monitoring kontrollerinin birlikte uygulandığı defense in depth yaklaşımıyla elde edilir.

Identity Access ve Network Enforcement Farkı

Identity access kullanıcının kim olduğunu ve hangi uygulamaya erişme hakkı bulunduğunu değerlendirir. Network enforcement ise bu kararın trafik seviyesinde uygulanmasını sağlar. ZTNA identity-aware erişim sağlar, firewall ağlar ve servisler arasındaki bağlantıyı kontrol eder. Bu iki katman aynı güvenlik hedefini farklı noktalarda destekler. Entegrasyon yapıldığında kullanıcı rolü firewall policy içinde de kullanılabilir.

ZTNA'nın Rolü

ZTNA kullanıcıyı doğrudan geniş internal network'e bağlamak yerine belirli uygulamalara kontrollü erişim sağlar. Remote çalışanlar için VPN'e göre daha dar erişim modeli sunabilir. Kullanıcı ve cihaz bağlamı her bağlantıda değerlendirilebilir. Uygulama discovery ve identity integration doğru yapılmalıdır. ZTNA kullanılması veri merkezi içindeki segmentasyon veya server-to-server firewall ihtiyacını ortadan kaldırmaz.

Firewall'ın Rolü

Firewall internet, zone, subnet ve workload arasındaki trafik kontrolünü sağlar. Public servis exposure, egress filtering ve application inspection gibi görevlerde kritik rol oynar. ZTNA olmayan machine-to-machine bağlantılar için de access policy uygular. Firewall logları threat detection ve incident response süreçlerine veri sağlar. Zero Trust mimarisinde firewall daha bağlamlı ve daha dar policy uygulayan enforcement noktalarından biri olur.

Segmentation'ın Rolü

Segmentation bir ihlal durumunda saldırganın ulaşabileceği sistem alanını sınırlar. ZTNA kullanıcı erişimini daraltsa bile sunucular ve uygulama bileşenleri arasında network segmentation gerekir. Microsegmentation bu kontrolü workload seviyesine kadar indirebilir. Firewall veya software-defined policy araçları segmentler arasındaki bağlantıyı enforce eder. Segment sınırları data flow analiziyle düzenli olarak doğrulanmalıdır.

Defense in Depth

Defense in depth güvenliği tek bir kontrolün başarısına bırakmama yaklaşımıdır. Identity, MFA, firewall, NAC, EDR, segmentation ve logging birlikte çalışır. Bir kontrol geçilse bile diğer katmanların saldırının ilerlemesini sınırlandırması hedeflenir. Katmanların birbirine bağımlılığı ve entegrasyonu test edilmelidir. Gereğinden fazla araç yerine net sorumlulukları olan ve düzgün yönetilen kontroller tercih edilmelidir.

VPN ile ZTNA Arasındaki Fark

VPN çoğunlukla kullanıcı cihazını kurumsal ağa şifreli tünelle bağlar, ZTNA ise kullanıcıyı belirli uygulamalara kimlik ve cihaz bağlamıyla bağlamaya odaklanır. Klasik VPN yanlış tasarlandığında kullanıcının geniş internal subnet'lere erişmesine neden olabilir. ZTNA uygulama seviyesinde daha dar erişim modeli sunabilir. Buna rağmen bazı legacy protokoller veya network administration görevleri için VPN hâlâ gerekli olabilir. Hangi yöntemin kullanılacağı kullanım senaryosu ve uygulama uyumluluğuna göre belirlenmelidir.

Network-Level Access

VPN kullanıcıya çoğu zaman route edilen belirli network segmentlerine erişim sağlar. Split tunnel veya full tunnel yapılandırmasıyla internet trafiğinin yönü belirlenebilir. Firewall policy kullanılarak VPN kullanıcı gruplarının erişimi daraltılmalıdır. VPN kuruldu diye bütün internal network'e izin verilmemelidir. Kullanıcı kimliği ve cihaz posture bilgisi access policy içinde değerlendirilmelidir.

Application-Level Access

ZTNA kullanıcıyı belirli uygulamaya veya servise bağlayabilir. Kullanıcı altyapının geri kalanını doğrudan erişilebilir network olarak görmez. Bu yaklaşım remote access için least privilege uygulamasını kolaylaştırır. Her uygulama için kimlik ve cihaz koşulları farklı belirlenebilir. Legacy uygulamalar için ZTNA uyumluluğu proje öncesinde test edilmelidir.

Broad Network Access Riski

Broad network access kullanıcının ihtiyacından daha fazla subnet ve servise erişmesini ifade eder. VPN kullanıcıları varsayılan olarak geniş internal route alıyorsa ele geçirilmiş hesap veya cihaz büyük risk oluşturabilir. Firewall rule'ları VPN source zone için ayrı hazırlanmalıdır. Yalnızca gerekli uygulama hedefleri ve portları açılmalıdır. Eski geniş VPN policy'leri düzenli erişim review sürecine alınmalıdır.

Identity ve Device Context

ZTNA erişim kararında kullanıcı kimliği ve cihaz durumunu merkezi biçimde değerlendirebilir. VPN sistemleri de modern identity ve posture entegrasyonlarıyla benzer kontroller uygulayabilir. Önemli olan bağlantı protokolünün adı değil, access decision içinde hangi bağlamların kullanıldığıdır. MFA, managed device ve risk bilgisi kritik erişimlerde şart hâline getirilebilir. Policy logları SIEM'e aktarılarak anormal davranışlar izlenebilir.

Remote Access İçin Least Privilege

Remote access kullanıcıları yalnızca görevleri için gereken kaynaklara erişebilmelidir. Her kullanıcıya aynı VPN subnet policy'si vermek yerine grup ve uygulama bazlı kontrol uygulanabilir. Administrator erişimleri normal kullanıcı bağlantılarından ayrılmalıdır. JIT veya approval tabanlı erişim privileged sistemler için kullanılabilir. Uzaktan bağlantı politikaları çalışan rolü değiştiğinde otomatik olarak güncellenmelidir.

Geçici Firewall Kuralları Nasıl Yönetilmelidir?

Geçici firewall kuralları bakım, migration, troubleshooting veya sınırlı süreli üçüncü taraf erişimi için gerekli olabilir. En büyük risk, geçici olarak açılan erişimin işlem bittikten sonra unutulmasıdır. Bu nedenle her temporary rule başlangıç tarihi, bitiş tarihi, owner ve business justification bilgisi taşımalıdır. Mümkünse firewall sistemi rule'u süre sonunda otomatik olarak disable veya delete etmelidir. Expiry notification kural sahibi ve güvenlik ekibine zamanında gönderilmelidir.

Temporary Access

Temporary access kalıcı iş ihtiyacı bulunmayan bağlantılar için kullanılır. İzin kapsamı yine source, destination ve port açısından minimum tutulmalıdır. “Geçici olduğu için geniş olabilir” yaklaşımı doğru değildir. Kural ticket numarası ve owner bilgisiyle oluşturulmalıdır. İş tamamlandığında erişim süresi dolmadan da manuel olarak kapatılabilir.

Start Date

Start date kuralın hangi tarihten itibaren aktif olması gerektiğini belirler. Bakım çalışması gelecekte başlayacaksa erişimi günler öncesinden açmak gerekmez. Planlanan zaman geldiğinde rule otomatik etkinleşebilir. Bu yöntem gereksiz açık erişim süresini azaltır. Değişiklik takvimi ve timezone bilgisi doğru yapılandırılmalıdır.

Expiration Date

Expiration date kuralın erişim hakkının sona ereceği zamanı tanımlar. Geçici rule için son kullanma tarihi zorunlu alan yapılması iyi bir governance uygulamasıdır. İş ihtiyacı devam ediyorsa süre dolmadan yeniden approval alınabilir. Otomatik süresiz uzatma yapılmamalıdır. Expired rule raporları düzenli olarak security review toplantılarında incelenmelidir.

Business Owner

Business owner erişimin neden gerekli olduğunu doğrulayabilecek iş sorumlusudur. Firewall ekibi teknik kuralı yönetirken erişim ihtiyacının devam edip etmediğini her zaman bilemeyebilir. Owner bilgisi recertification ve expiry süreçlerinde kritik rol oynar. Çalışan ayrıldığında veya organizasyon değiştiğinde owner güncellenmelidir. Owner bulunamayan kurallar riskli orphaned rule olarak değerlendirilmelidir.

Auto-Disable

Auto-disable rule'un belirlenen sürenin sonunda otomatik devre dışı bırakılmasını sağlar. Bu yöntem erişimi durdururken kuralı hemen silmediği için troubleshooting açısından güvenli bir ara adım sunar. Gerekirse kısa süre içinde yeniden etkinleştirilebilir. Disable tarihi log ve change record içinde tutulmalıdır. Belirli bekleme süresinden sonra rule kalıcı olarak silinebilir.

Auto-Delete

Auto-delete süre sonunda kuralın otomatik olarak kaldırılmasını sağlar. Kısa ömürlü ve düşük riskli temporary access için kullanışlı olabilir. Ancak silme öncesinde log ve metadata bilgilerinin audit sisteminde saklanması önemlidir. Kritik production ortamlarında önce auto-disable tercih edilebilir. Silinen rule gerektiğinde version control veya configuration backup üzerinden izlenebilmelidir.

Expiry Notification

Expiry notification kuralın sona erme tarihi yaklaşırken owner ve ilgili ekiplere uyarı gönderir. Böylece ihtiyaç devam ediyorsa yeni approval süreci zamanında başlatılabilir. Bildirim birkaç gün önceden ve gerekirse tekrar gönderilebilir. Owner yanıt vermezse varsayılan davranış erişimin sona ermesi olmalıdır. Bu yaklaşım kalıcı hâle dönüşen geçici rule sayısını önemli ölçüde azaltır.

Just-in-Time Network Access

Just-in-Time Network Access kalıcı erişim yerine yalnızca ihtiyaç duyulan anda ve sınırlı süre için network yetkisi vermeyi amaçlar. Özellikle administrator ve privileged system bağlantılarında önemli güvenlik avantajı sağlar. Kullanıcı erişim istediğinde approval veya otomatik risk değerlendirmesi çalışabilir. Yetki belirlenen süre sonunda otomatik olarak kaldırılır. Böylece saldırgan ele geçirilmiş bir admin hesabını kullansa bile sürekli açık yönetim erişimi bulamayabilir.

Permanent Access Yerine Geçici Yetki

Permanent admin access kullanıcı hesabının sürekli olarak kritik sisteme ulaşabilmesi anlamına gelir. JIT yaklaşımı bu erişimi yalnızca gerekli işlem zamanı için açar. İşlem bittikten sonra firewall veya ZTNA policy otomatik kapanır. Bu yöntem exposed privileged path süresini azaltır. Özellikle production ve management zone erişimleri için güçlü bir kontrol oluşturur.

Approval

JIT access isteği bazı durumlarda yönetici veya system owner onayı gerektirebilir. Talepte hedef sistem, amaç ve istenen süre açıkça belirtilmelidir. Düşük riskli standart işlemler otomatik policy ile onaylanabilir. Kritik sistemler için iki kişilik approval uygulanabilir. Tüm kararlar audit trail içinde saklanmalıdır.

Time-Bounded Access

Time-bounded access yetkinin başlangıç ve bitiş zamanını net biçimde sınırlar. Örneğin administrator iki saat boyunca belirli sunucuya SSH erişimi alabilir. Süre sonunda active rule otomatik kaldırılır. Kullanıcı daha fazla zamana ihtiyaç duyarsa yeni talep oluşturur. Bu yaklaşım unutulan açık erişim riskini azaltır.

Automatic Revocation

Automatic revocation süre dolduğunda erişimin insan müdahalesi olmadan kaldırılmasıdır. Firewall rule, identity group membership veya ZTNA entitlement otomatik güncellenebilir. Mevcut session'ların da sonlandırılıp sonlandırılmayacağı policy'de açıkça tanımlanmalıdır. Revocation başarısız olursa güvenlik ekibine alarm gönderilmelidir. Sistem otomasyonunun düzenli olarak test edilmesi gerekir.

Privileged System Access

Privileged system access domain controller, firewall, database veya production platformları gibi yüksek etkili sistemlere erişimi kapsar. Bu bağlantılar normal kullanıcı trafiğinden ayrılmalıdır. JIT, MFA, jump host ve session logging birlikte kullanılabilir. Kullanıcının kişisel admin hesabı tercih edilmeli, shared account'lardan kaçınılmalıdır. Erişim sonrası yapılan işlemler audit ve gerekirse post-change review kapsamında incelenmelidir.

Break-Glass Access Nedir?

Break-glass access normal erişim mekanizmalarının kullanılamadığı acil durumlar için önceden hazırlanmış istisnai yetkidir. Bu erişim sık kullanılmamalı ve güçlü şekilde korunmalıdır. Kimlerin kullanabileceği, hangi şartlarda devreye alınacağı ve işlem sonrası hangi incelemenin yapılacağı açık biçimde tanımlanmalıdır. MFA, session logging ve kısa süreli yetki gibi kontroller uygulanmalıdır. Her kullanım sonrasında neden ihtiyaç duyulduğu ve normal erişim mekanizmasının neden yetersiz kaldığı değerlendirilmelidir.

Acil Durum Erişimi

Acil durum erişimi üretim kesintisi veya identity sisteminin erişilemediği senaryolarda kullanılabilir. Normal approval zincirinin çalışmadığı durumlar için önceden planlanmalıdır. Break-glass hesabı günlük operasyonlarda kullanılmamalıdır. Erişim açıldığında güvenlik ekibine anlık bildirim gönderilebilir. Olay sonrasında hesap credential'ları gerekiyorsa değiştirilmelidir.

Kim Kullanabilir?

Break-glass access yalnızca önceden belirlenmiş az sayıda yetkili kişi tarafından kullanılmalıdır. Bu kullanıcıların görevleri ve sorumlulukları açıkça tanımlanmalıdır. Personel değişikliklerinde liste hemen güncellenmelidir. Shared ve kaynağı belirsiz hesap kullanımı mümkün olduğunca önlenmelidir. Kullanıcı kimliği ve kullanım nedeni audit kaydına eklenmelidir.

MFA

Break-glass hesabı yüksek ayrıcalığa sahip olduğu için mümkünse MFA ile korunmalıdır. Normal identity provider tamamen erişilemez durumda olabileceği için bağımsız ikinci faktör yöntemi değerlendirilebilir. Recovery mekanizması güvenli fiziksel veya dijital kasada saklanabilir. MFA bypass seçenekleri ayrı approval gerektirmelidir. Test sırasında emergency authentication yönteminin gerçekten çalıştığı doğrulanmalıdır.

Session Logging

Break-glass kullanımındaki bütün oturumlar ayrıntılı biçimde loglanmalıdır. Login zamanı, kullanıcı, hedef sistem ve yapılan işlemler mümkün olduğunda kaydedilir. Privileged access platformu session recording sağlayabilir. Logların aynı sistem üzerinde tutulması yerine merkezi ve değiştirilemez depoya gönderilmesi tercih edilir. Olay sonrası review sırasında bu kayıtlar temel kanıt olarak kullanılır.

Time Limit

Emergency access süresiz açık tutulmamalıdır. Erişim başlangıç anından itibaren belirli zaman penceresiyle sınırlandırılabilir. Süre dolduğunda yetki otomatik kapatılmalıdır. İhtiyaç devam ediyorsa yeni onay alınabilir. Bu yapı emergency durumun normal çalışma biçimine dönüşmesini önler.

Post-Incident Review

Break-glass kullanımı sonrasında post-incident review yapılmalıdır. Neden emergency erişime ihtiyaç duyulduğu ve hangi işlemlerin gerçekleştirildiği incelenir. Normal access sürecinde bir eksiklik varsa düzeltici aksiyon belirlenir. Kullanılan hesap ve anahtarlar gerekiyorsa yenilenir. Review sonucu audit kayıtlarıyla birlikte saklanmalıdır.

Firewall Rule Request Süreci Nasıl Olmalıdır?

Firewall rule request süreci yeni erişim ihtiyacının standart ve doğrulanabilir şekilde tanımlanmasını sağlar. Talepte business justification, source, destination, service, owner, duration ve risk bilgileri yer almalıdır. Eksik bilgilerle firewall ekibinin varsayım yapması geniş veya yanlış kural oluşturabilir. Approval akışı erişimin kritik seviyesine göre farklılaştırılabilir. Standart form ve otomatik validation kullanımı hem hız hem güvenlik açısından önemli fayda sağlar.

Business Justification

Business justification kuralın neden gerekli olduğunu açık ve anlaşılır biçimde açıklamalıdır. “Uygulama çalışmıyor” tek başına yeterli gerekçe değildir. Hangi iş sürecinin hangi bağlantıya ihtiyaç duyduğu belirtilmelidir. Bu bilgi daha sonraki recertification çalışmalarında erişimin devam edip etmediğini değerlendirmek için kullanılır. İş gerekçesi kalmamış rule kaldırılmalıdır.

Source

Rule request içinde source IP, subnet, zone veya kullanıcı grubu açıkça belirtilmelidir. “Tüm ofis” gibi belirsiz tanımlar teknik olarak doğrulanmalıdır. Dinamik sistemler için object veya identity group kullanılabilir. Kaynak kapsamı minimum gereksinimle sınırlandırılmalıdır. Talep sahibi source bilgisini bilmiyorsa network ekibi flow analiziyle destek sağlayabilir.

Destination

Destination hedef sunucu, servis veya uygulamayı açık biçimde tanımlar. Tek IP, network object veya FQDN bilgisi kullanılabilir. Tüm veri merkezi gibi geniş hedefler özel gerekçe olmadan kabul edilmemelidir. Hedefin owner bilgisi approval sürecine dahil edilebilir. Public destination taleplerinde internet risk değerlendirmesi de yapılmalıdır.

Service ve Port

Service ve port alanı bağlantının hangi protokolle çalışacağını belirtir. TCP veya UDP bilgisi açıkça yazılmalıdır. Port bilinmiyorsa application owner veya vendor dokümanı üzerinden doğrulama yapılmalıdır. “Any service” talebi istisnai durum dışında reddedilmelidir. Dinamik port kullanan uygulamalarda stateful inspection veya application-aware policy değerlendirilebilir.

Application Owner

Application owner hedef veya kaynak uygulamanın işlevinden sorumlu kişidir. Firewall ekibinin teknik olarak doğru görünen talebin gerçekten gerekli olup olmadığını tek başına belirlemesi mümkün olmayabilir. Owner erişim ihtiyacını ve servis portlarını doğrular. Uygulama decommission olduğunda ilgili rule'ların kaldırılmasını tetikleyebilir. Owner bilgisinin CMDB veya service catalog ile entegrasyonu faydalıdır.

Duration

Duration erişimin kalıcı mı yoksa geçici mi olması gerektiğini belirtir. Proje ve bakım erişimleri mümkün olduğunda expiration date ile açılmalıdır. Kalıcı erişimler bile periyodik review tarihine sahip olmalıdır. Temporary access için auto-disable kullanılabilir. Süre bilgisi eksik talepler otomatik olarak belirli maksimum erişim süresiyle sınırlandırılabilir.

Risk Assessment

Risk assessment erişimin hangi güvenlik etkilerine sahip olabileceğini değerlendirir. Internet exposure, management port, sensitive data ve privileged destination gibi faktörler risk seviyesini yükseltebilir. Yüksek riskli rule için ek review veya kontrol gerekebilir. WAF, IPS, MFA veya jump host gibi compensating control seçenekleri değerlendirilebilir. Risk değerlendirmesi yalnızca formalite değil, policy tasarımını doğrudan etkileyen adım olmalıdır.

Approval

Approval yeni erişimin teknik ve iş açısından yetkili kişiler tarafından onaylanmasını sağlar. Düşük riskli standart kurallar otomatik workflow ile hızlı ilerleyebilir. Kritik production erişimleri security ve application owner onayı gerektirebilir. Talep eden kişi kendi kuralını tek başına onaylamamalıdır. Approval kayıtları audit trail olarak saklanmalıdır.

Firewall Rule Change Management

Firewall rule change management her politika değişikliğinin planlı, gözden geçirilmiş ve geri alınabilir biçimde uygulanmasını sağlar. Firewall değişiklikleri küçük görünse de yanlış rule order veya geniş object kullanımı büyük erişim etkisi oluşturabilir. Bu nedenle request, peer review, security review, impact analysis, implementation ve validation adımları standart süreç içinde yürütülmelidir. Kritik değişiklikler maintenance window içinde yapılmalıdır. Her değişiklik için uygulanabilir rollback planı bulunması operasyon riskini önemli ölçüde azaltır.

Change Request

Change request uygulanacak teknik değişikliği ve iş gerekçesini kayıt altına alır. Etkilenecek firewall, zone, rule ve object bilgileri belirtilmelidir. Uygulama adımları ve test planı request içinde bulunmalıdır. Emergency değişiklikler için ayrı ama kayıtlı süreç kullanılabilir. Değişiklik tamamlandıktan sonra gerçek sonuç request kaydına eklenmelidir.

Peer Review

Peer review değişikliği hazırlayan kişi dışında başka bir teknik uzmanın rule'u incelemesini sağlar. Yanlış subnet maskesi, ters source-destination veya gereksiz port gibi hatalar bu aşamada fark edilebilir. Reviewer mevcut rule base ile overlap ve shadow riskini de kontrol eder. Büyük değişikliklerde iki ayrı uzman review yapabilir. Review sonucu change kaydında görülebilir olmalıdır.

Security Review

Security review erişimin kurum güvenlik politikalarına uyumunu değerlendirir. Any Any Allow, public management exposure veya default allow gibi yüksek riskli talepler özellikle kontrol edilir. Least privilege uygulanıp uygulanmadığı incelenir. Gerekli durumlarda ek compensating control talep edilir. Security review teknik operasyonu gereksiz yavaşlatmamak için risk bazlı tasarlanmalıdır.

Impact Analysis

Impact analysis önerilen rule veya object değişikliğinin hangi sistemleri etkileyebileceğini değerlendirir. Shared object üzerinde yapılan küçük değişiklik birçok policy'yi genişletebilir. Routing, NAT, VPN ve application dependency bilgileri birlikte incelenmelidir. Mevcut hit count ve trafik logları tahmini etkiyi anlamaya yardımcı olur. Yüksek etkili değişiklikler için staging veya simulation yapılmalıdır.

Maintenance Window

Maintenance window riskli değişikliklerin iş etkisinin düşük olduğu planlı zaman aralığında uygulanmasını sağlar. Her firewall değişikliği bakım penceresi gerektirmeyebilir. Kritik production rule veya routing etkisi bulunan değişiklikler için ise uygun zaman seçmek önemlidir. İlgili uygulama ekipleri önceden bilgilendirilmelidir. Rollback için yeterli zaman bakım penceresi içinde bırakılmalıdır.

Implementation

Implementation onaylanmış firewall değişikliğinin production ortamına uygulanmasıdır. Uygulama sırasında change request'te belirtilen adımlar izlenmelidir. Son dakika farklılıkları ortaya çıkarsa plansız ek kural açmak yerine değişiklik tekrar değerlendirilmelidir. Otomasyon kullanılıyorsa deploy çıktıları kaydedilmelidir. Kritik değişiklik boyunca monitoring ekipleri hazır bulunabilir.

Validation

Validation yeni kuralın amaçlanan trafiği çalıştırdığını ve istenmeyen erişimi açmadığını doğrular. Expected allow ve expected deny testleri birlikte yapılmalıdır. Firewall log ve rule hit count incelenir. Uygulama ekibinin sadece “çalışıyor” demesi güvenlik doğrulaması için yeterli değildir. Negatif test yapılmadan policy'nin sınırları tam olarak doğrulanmış olmaz.

Closure

Closure değişiklik işleminin teknik ve idari olarak tamamlandığı aşamadır. Test sonuçları, log örnekleri ve varsa sorunlar change kaydına eklenir. Geçici debug kuralı veya ekstra erişim oluşturulduysa kaldırıldığı doğrulanır. Rollback gerekmemişse bu durum da belirtilir. Sonraki review veya expiration tarihi gerekiyorsa closure sırasında planlanır.

Firewall Değişikliğinden Önce Nasıl Test Yapılır?

Firewall değişikliğini production ortamında ilk kez denemek gereksiz risk oluşturur. Policy simulation, packet simulation, reachability analysis ve staging testleri değişiklikten önce davranışı doğrulamaya yardımcı olur. Yalnızca izin verilmesi beklenen trafik değil, özellikle engellenmesi gereken trafik de test edilmelidir. Mevcut uygulamaların etkilenmediğinden emin olmak için regression test kullanılabilir. Test sonucu change request'e eklenerek karar süreci ölçülebilir hâle getirilmelidir.

Policy Simulation

Policy simulation belirli source, destination ve service kombinasyonunun hangi firewall rule ile eşleşeceğini önceden gösterir. Shadow veya yanlış rule order sorunlarını yakalamak için çok değerlidir. Bazı merkezi yönetim sistemleri production policy üzerinde simulation yapabilir. Sonuç gerçek trafik loglarıyla karşılaştırılabilir. Simulation özelliği bulunmuyorsa lab veya konfigürasyon analiz aracı kullanılabilir.

Packet Simulation

Packet simulation tek bir paketin firewall ve routing aşamalarından nasıl geçeceğini modellemeye çalışır. NAT, ACL ve security policy sırası görülebilir. Özellikle karmaşık route ve VPN senaryolarında troubleshooting için faydalıdır. Simülasyon sonucu gerçek packet capture ile doğrulanabilir. Cihazın simulation komutlarının production performansına etkisi olup olmadığı dokümantasyondan kontrol edilmelidir.

Reachability Test

Reachability test source sistemin hedefe gerçekten ulaşabilip ulaşamadığını kontrol eder. Ping tek başına yeterli değildir, uygulamanın kullandığı gerçek port test edilmelidir. TCP connection test, curl veya uygulama health check kullanılabilir. Kaynak sistemden test yapılamıyorsa benzer network location kullanılmalıdır. Sonuç firewall loglarıyla birlikte değerlendirilmelidir.

Staging

Staging production'a benzer ortamda firewall değişikliğini önceden test etmeyi sağlar. Özellikle uygulama migration ve büyük segmentasyon projelerinde değerlidir. Staging ortamının network policy açısından production ile yeterince benzer olması gerekir. Test edilen rule set version control altında tutulabilir. Production deployment aynı onaylı konfigürasyondan yapılmalıdır.

Expected-Allow Test

Expected-Allow test erişim verilmesi gereken bağlantıların başarıyla çalıştığını doğrular. Kullanıcı veya uygulama gerçek servis seviyesinde bağlantı kurmalıdır. Firewall hit logunda doğru rule ID görülmelidir. Yanlış daha genel kural üzerinden çalışıyorsa erişim teknik olarak başarılı olsa bile policy tasarımı hatalı olabilir. Bu nedenle yalnızca uygulama sonucuna değil eşleşen rule'a da bakılmalıdır.

Expected-Deny Test

Expected-Deny test erişim verilmemesi gereken kaynakların gerçekten engellendiğini doğrular. Bu test security policy'nin sınırlarını kanıtlamak açısından en az allow testi kadar önemlidir. Farklı kullanıcı grubu veya subnet'ten aynı hedefe bağlantı denenebilir. Deny logunda beklenen rule görülmelidir. Negatif test yapılmayan policy'lerde gereğinden geniş erişim uzun süre fark edilmeyebilir.

Regression Test

Regression test yeni firewall değişikliğinin mevcut çalışan bağlantıları bozmadığını kontrol eder. Kural sırası değişikliği veya object güncellemesi geniş etkiye sahip olabilir. Kritik application flow listesi otomatik test senaryolarına dönüştürülebilir. CI/CD ile firewall policy yönetiminde bu testler deployment öncesi çalıştırılabilir. Başarısız test change'in production'a gitmesini engellemelidir.

Firewall Değişikliğinden Sonra Ne Kontrol Edilmelidir?

Firewall değişikliği uygulanınca işlem tamamlanmış sayılmaz. Intended traffic'in çalışması, istenmeyen trafiğin engellenmesi, logların oluşması ve performansın normal kalması kontrol edilmelidir. Rule hit count yeni policy'nin gerçekten kullanıldığını doğrular. Beklenmeyen error veya session drop artışı monitoring sistemlerinde izlenmelidir. Sorun varsa önceden hazırlanmış rollback planı gecikmeden uygulanmalıdır.

Intended Traffic Çalışıyor mu?

İlk kontrol hedeflenen uygulama veya servis bağlantısının başarıyla çalışmasıdır. Test gerçek source sistemden yapılmalıdır. Firewall logunda doğru source, destination ve rule ID görülmelidir. Uygulama yalnızca başka geniş bir policy sayesinde çalışıyorsa yeni rule'un işlevi doğrulanmış sayılmaz. Application owner ile sonuç birlikte kontrol edilmelidir.

İstenmeyen Trafik Engelleniyor mu?

Yeni rule'un gereğinden geniş olmadığını anlamak için beklenmeyen kaynak ve portlardan bağlantı denenmelidir. Negatif test erişim sınırının gerçekten çalıştığını gösterir. Özellikle object group değişikliklerinde bu kontrol önemlidir. Deny logları uygun rule'a eşleşmelidir. Geniş access tespit edilirse policy production'da bırakılmadan düzeltilmelidir.

Loglar Oluşuyor mu?

Rule logging etkinse expected traffic için kayıt oluştuğu doğrulanmalıdır. Timestamp, source, destination, action ve rule ID alanlarının doğru gelmesi gerekir. Loglar merkezi SIEM'e de ulaşıyor olmalıdır. Parser problemi varsa firewall üzerinde log oluşsa bile güvenlik monitoring kaybı yaşanabilir. Kritik policy değişikliklerinde log pipeline kontrolü validation adımına dahil edilmelidir.

Performance Etkilendi mi?

DPI, TLS inspection veya çok geniş policy değişiklikleri firewall kaynak kullanımını etkileyebilir. CPU, memory, session count, throughput ve latency değerleri change öncesi baseline ile karşılaştırılmalıdır. Küçük ofis rule'larında etki ihmal edilebilirken yüksek trafik alanlarında önemli olabilir. HA cluster üyeleri birlikte izlenmelidir. Performans sorunu varsa inspection profile veya kapasite yeniden değerlendirilmelidir.

Rule Hit Count

Rule hit count belirli kuralın kaç kez eşleştiğini gösterir. Yeni rule beklenen test sırasında hit almıyorsa trafik başka policy üzerinden geçiyor olabilir. Çok beklenmedik yüksek hit ise kapsamın geniş olduğunu gösterebilir. Hit count tek başına güvenlik kararı için yeterli değildir, log bağlamıyla birlikte değerlendirilmelidir. Review sürecinde son hit zamanı da önemli veri sağlar.

Rollback Gerekli mi?

Beklenmeyen erişim, uygulama kesintısı veya performans problemi oluşursa rollback değerlendirilmelidir. Sorunu production üzerinde plansız yeni kurallarla düzeltmeye çalışmak riski büyütebilir. Last-known-good policy geri yüklenerek hizmet stabilize edilebilir. Ardından hata test ortamında analiz edilir. Rollback kararı başarısızlık olarak değil kontrollü change management sürecinin doğal parçası olarak görülmelidir.

Firewall Configuration Rollback

Firewall configuration rollback başarısız veya istenmeyen değişiklik sonrasında bilinen güvenli yapılandırmaya geri dönmeyi sağlar. Her kritik değişiklikten önce mevcut configuration backup alınmalıdır. Bazı platformlar belirli süre içinde administrator onayı gelmezse otomatik rollback yapabilir. Bu özellik özellikle remote firewall değişikliklerinde yönetim bağlantısının kaybolması riskine karşı değerlidir. Rollback prosedürü yalnızca dokümante edilmemeli, düzenli testlerle çalıştığı doğrulanmalıdır.

Last-Known-Good Configuration

Last-known-good configuration doğrulanmış ve sorunsuz çalıştığı bilinen firewall konfigürasyonudur. Değişiklik öncesinde bu sürüm açık biçimde işaretlenmelidir. Rollback gerektiğinde hangi dosyanın kullanılacağı konusunda tereddüt oluşmaz. Version control veya merkezi backup sistemi bu süreci destekleyebilir. Konfigürasyonla birlikte ilgili object ve certificate bağımlılıkları da saklanmalıdır.

Pre-Change Backup

Pre-change backup değişiklik uygulanmadan hemen önce mevcut firewall yapılandırmasının yedeğini alır. Bu işlem otomatik change workflow parçası hâline getirilebilir. Backup dosyasının gerçekten geri yüklenebilir olduğu zaman zaman test edilmelidir. Yedek güvenli ve erişimi sınırlı depoda tutulmalıdır. Secret veya private key içeren dosyalar ayrıca korunmalıdır.

Automatic Rollback

Automatic rollback belirli koşullar sağlanmadığında firewall'ın önceki yapılandırmaya otomatik dönmesini sağlar. Remote management erişimi kaybolduğunda özellikle faydalıdır. Administrator change'i belirli süre içinde confirm etmezse sistem eski configuration'a dönebilir. Otomatik mekanizma yanlış kullanılırsa geçerli değişikliği de geri alabileceği için süreç net olmalıdır. Kritik cihazlarda lab ortamında test edilmesi önerilir.

Failed Change Recovery

Failed change recovery yalnızca configuration restore işlemi değil hizmeti güvenli şekilde yeniden çalıştırma sürecidir. Routing, VPN veya HA state gibi ek bileşenler de kontrol edilmelidir. Rollback sonrası intended application flow testleri tekrar yapılır. Olayın nedeni root cause analysis ile belirlenir. Aynı hata tekrar yaşanmasın diye test veya review süreci güncellenir.

Disaster Recovery

Firewall disaster recovery cihaz veya site kaybında güvenlik hizmetinin yeniden kurulmasını kapsar. Güncel configuration backup, lisans bilgileri ve gerekli sertifikalar güvenli lokasyonda tutulmalıdır. Yedek cihaz veya sanal firewall planı bulunabilir. DR testleri sırasında firewall policy'nin doğru restore edildiği doğrulanmalıdır. Recovery sırasında geçici geniş güvenlik kuralı kullanılmaması için önceden hazırlanmış prosedürler önemlidir.

Firewall Rule Documentation Standardı

Firewall rule documentation standardı kuralın teknik ve iş bağlamını kaybetmemesini sağlar. Yıllar sonra bir policy satırına bakıldığında neden oluşturulduğu, kimin istediği, kimin onayladığı ve ne zaman tekrar gözden geçirileceği görülebilmelidir. Bu bilgiler rule description, ticketing system veya merkezi policy repository içinde tutulabilir. Dokümantasyon olmadan recertification süreçleri gereksiz yere uzar. Standart metadata alanları otomasyon ve audit evidence üretimini de kolaylaştırır.

Rule Name

Rule name kuralın amacını kısa ve anlaşılır biçimde ifade etmelidir. Rastgele sayı veya “test-rule-2” gibi adlar uzun vadede yeterli değildir. Kaynak rolü, hedef uygulama veya iş fonksiyonu isimde yer alabilir. Kurum genelinde ortak naming convention kullanılmalıdır. Çok uzun isim yerine detaylar description alanına bırakılabilir.

Business Purpose

Business purpose erişimin hangi iş sürecini desteklediğini açıklar. Teknik port bilgisi tek başına gerekçe değildir. Örneğin “ERP uygulama sunucularının finans veri tabanına erişimi” gibi açıklama daha anlamlıdır. Bu bilgi owner değişse bile kuralın amacının anlaşılmasını sağlar. İş süreci sona erdiğinde ilgili rule kolayca belirlenebilir.

Requestor

Requestor firewall erişimini ilk talep eden kişi veya ekip bilgisidir. Bu alan daha sonra soru oluştuğunda başvuru noktası sağlayabilir. Ancak requestor her zaman uzun vadeli owner değildir. Personel değişikliği nedeniyle aktif sorumluluk ayrıca owner alanında tutulmalıdır. Ticket sistemi requestor bilgisini otomatik kaydedebilir.

Owner

Owner kuralın iş ihtiyacının devam ettiğini doğrulayan sorumlu kişidir. Recertification talepleri bu kişiye gönderilebilir. Owner ayrıldığında kural sahipsiz bırakılmamalıdır. CMDB veya service ownership sistemiyle otomatik güncelleme değerlendirilebilir. Owner yanıt vermeyen kritik kurallar risk review sürecine alınmalıdır.

Approver

Approver erişim talebini yetkili olarak onaylayan kişidir. Bu kişi requestor ile aynı olmamalıdır. Yüksek riskli erişimlerde security ve application owner gibi birden fazla approver gerekebilir. Approval tarihi ve kararı audit trail içinde saklanmalıdır. Otomatik approval yalnızca önceden tanımlanmış düşük riskli standartlar için kullanılmalıdır.

Ticket Number

Ticket number firewall rule ile change veya access request kaydını ilişkilendirir. Rule description içinde ticket referansı bulunması geçmiş bilgisine hızlı erişim sağlar. Aynı ticket birden fazla rule oluşturuyorsa ilişki açık tutulmalıdır. Ticket kapanınca firewall rule otomatik silinmemelidir, çünkü erişim kalıcı olabilir. Ancak review ve owner bilgisi ticket verisinden alınabilir.

Creation Date

Creation date kuralın ne zaman devreye alındığını gösterir. Çok eski rule'lar düzenli review için önceliklendirilebilir. Tarih bilgisi firewall üzerinden veya merkezi policy inventory sisteminden otomatik alınabilir. Migration sırasında eski kurallar yeni tarihle görünmemeli, mümkünse orijinal tarih korunmalıdır. Rule age metriği stale policy analizi için yararlıdır.

Review Date

Review date kuralın ne zaman tekrar doğrulanması gerektiğini belirtir. Kritik erişimler daha kısa aralıklarla incelenebilir. Otomatik bildirim sistemi owner'a review tarihi yaklaşırken görev gönderebilir. Review yapılmadığında policy'nin nasıl ele alınacağı önceden tanımlanmalıdır. Kanıt olarak approval veya recertification kaydı saklanmalıdır.

Expiration Date

Expiration date geçici erişimin otomatik sona ereceği tarihtir. Permanent rule için boş bırakılabilir, ancak review date yine bulunmalıdır. Temporary access süresiz uzatılmamalıdır. Süre dolmadan owner'a bildirim gönderilebilir. Expired erişim otomatik disable edilerek risk azaltılabilir.

Firewall Kuralları Ne Sıklıkla Gözden Geçirilmelidir?

Firewall review sıklığı tüm kurallar için tek bir takvime bağlı olmak zorunda değildir. Kritik internet erişimleri ve privileged rule'lar daha sık, düşük riskli stabil akışlar daha uzun aralıklarla incelenebilir. Continuous monitoring, aylık operasyon review ve üç aylık rule review birlikte uygulanabilir. Ayrıca decommission, büyük network change veya security incident sonrasında hedefli review yapılmalıdır. Risk bazlı yaklaşım ekiplerin enerjisini en önemli erişimlere yönlendirmeyi sağlar.

Continuous Monitoring

Continuous monitoring rule davranışını günlük trafik ve güvenlik verileri üzerinden sürekli izler. Zero-hit, unusual hit veya beklenmeyen destination değişimleri otomatik alarm üretebilir. SIEM ve firewall analyzer araçları bu süreci destekler. Continuous monitoring formal recertification'ın yerini tamamen almaz. Ancak sorunları üç aylık review tarihini beklemeden fark etmeye yardımcı olur.

Monthly Operational Review

Aylık operasyon review son dönemde eklenen, değiştirilen veya expired olan kuralları inceler. Change failure, temporary rule ve zero-hit bilgileri raporlanabilir. Ekipler tekrar eden sorunları bu toplantıda görebilir. Yeni object ve policy standardı gerektiğinde belirlenebilir. Kısa ama düzenli review büyük temizlik projelerine olan ihtiyacı azaltır.

Quarterly Rule Review

Quarterly rule review birçok kurum için erişim politikalarını yeniden doğrulamakta kullanılabilir. Rule owner'lara mevcut erişim listeleri gönderilir. Gerekli olmayan veya sahipsiz rule'lar işaretlenir. Kritik policy'lerde port, source ve destination kapsamı tekrar değerlendirilir. Review sonucunun audit evidence olarak saklanması faydalıdır.

Risk-Based Review

Risk-based review tüm rule'lara aynı önceliği vermek yerine yüksek etkili erişimleri daha sık inceler. Internet-facing, database, management ve privileged policy'ler öncelikli olabilir. Any veya geniş subnet içeren rule'lar risk skoru alabilir. Otomatik risk scoring büyük rule base'lerde işe yarar. Düşük riskli ve değişmeyen servisler daha uzun review periyoduna alınabilir.

Decommission Sonrası Review

Bir uygulama veya sunucu decommission edildiğinde ilgili firewall kuralları otomatik olarak ortadan kalkmaz. CMDB ve firewall inventory arasında ilişki kurulmadıysa stale rule birikimi oluşabilir. Decommission checklist içinde network access review bulunmalıdır. İlgili object ve NAT rule'lar da kontrol edilmelidir. Kullanılmayan erişimler sistem kapanışıyla birlikte kaldırılmalıdır.

Major Network Change Sonrası Review

Subnet migration, data center taşıması veya cloud migration gibi büyük network değişiklikleri mevcut firewall policy anlamını değiştirebilir. Eski IP object'leri gereksiz hâle gelebilir. Geçiş sırasında açılan temporary rule'lar kalıcı bırakılabilir. Proje kapanışında kapsamlı policy review yapılmalıdır. Yeni mimariye uygun zone ve least privilege tasarımı tekrar doğrulanmalıdır.

Zero-Hit Firewall Rule Nasıl Yönetilir?

Zero-hit firewall rule belirli süre boyunca trafikle eşleşmeyen kuraldır ve rule cleanup için değerli adaydır. Ancak doğrudan silme kararı verilmemelidir. Sezonluk uygulamalar, disaster recovery bağlantıları veya yılda birkaç kez kullanılan yönetim servisleri uzun süre hit üretmeyebilir. Rule owner ve uygulama takvimi mutlaka kontrol edilmelidir. Güvenli yöntem önce disable etmek, belirli süre gözlemlemek ve ardından gereksiz olduğu doğrulanırsa silmektir.

Hit Count Nedir?

Hit count kuralın kaç kez trafikle eşleştiğini gösteren sayaçtır. Son hit zamanı bilgisi rule kullanımını anlamak için daha da değerlidir. Counter reset tarihi bilinmeden sayı yanlış yorumlanabilir. Firewall reboot veya policy install sonrası sayaç davranışı platforma göre değişebilir. Bu nedenle hit count diğer log ve owner bilgileriyle birlikte değerlendirilmelidir.

Sıfır Hit Her Zaman Gereksiz Rule Anlamına Gelir mi?

Sıfır hit tek başına kuralın gereksiz olduğunu kanıtlamaz. Yıllık raporlama sistemi veya acil durum bağlantısı uzun süre kullanılmayabilir. İzleme süresi uygulamanın gerçek çalışma periyodunu kapsamalıdır. Owner ve business purpose doğrulanmadan delete yapılmamalıdır. Buna rağmen owner bulunamıyor ve uzun süre trafik yoksa rule disable adayı olabilir.

Seasonal Application

Seasonal application yalnızca belirli aylarda veya dönemlerde çalışan sistemdir. Vergi, raporlama veya kampanya dönemleri buna örnek olabilir. Yılın geri kalanında firewall rule sıfır hit gösterebilir. Review takvimi uygulama dönemine göre ayarlanmalıdır. Mümkünse rule schedule ile yalnızca ihtiyaç döneminde aktif tutulabilir.

Disaster Recovery Rule

Disaster recovery rule normal işletimde hit almaması beklenen bağlantılardan biri olabilir. DR site yalnızca test veya gerçek felaket durumunda kullanılabilir. Sıfır hit bu nedenle normal davranış olabilir. Bunun yerine yıllık DR testinde kuralın doğru çalıştığı doğrulanmalıdır. Owner ve test tarihi metadata içinde tutulmalıdır.

Rule Owner Confirmation

Rule owner confirmation erişimin hâlâ iş ihtiyacı olup olmadığını doğrudan sorumlu kişiden doğrular. Owner yalnızca “gerekiyor” demek yerine kullanım gerekçesini açıklamalıdır. Uygulama kapanmışsa firewall rule kaldırılabilir. Yanıt alınamıyorsa escalation süreci çalıştırılmalıdır. Confirmation kaydı audit trail içinde saklanmalıdır.

Disable-before-Delete Yaklaşımı

Disable-before-delete gereksiz olduğu düşünülen rule'u önce pasif hâle getirir. Böylece beklenmeyen uygulama etkisi ortaya çıkarsa hızlıca geri açılabilir. Belirlenen gözlem süresinde incident veya erişim talebi oluşmazsa kural silinebilir. Bu yöntem özellikle eski ve owner bilgisi zayıf rule base'lerde güvenli temizlik sağlar. Disable ve delete tarihleri change record içinde tutulmalıdır.

Firewall Rule Recertification Nedir?

Firewall rule recertification mevcut erişim kurallarının belirli aralıklarla iş ihtiyacı ve güvenlik açısından yeniden onaylanmasıdır. Rule oluşturulduğu gün doğru olan erişim aylar sonra gereksiz hâle gelebilir. Owner erişimin devam edip etmediğini, kapsamının hâlâ minimum olup olmadığını ve expiration ihtiyacını değerlendirir. Otomatik workflow binlerce rule içeren ortamlarda süreci hızlandırır. Recertification kayıtları compliance ve internal audit için güçlü kanıt oluşturur.

Rule Owner Onayı

Rule owner belirli policy'nin hâlâ gerekli olduğunu yeniden doğrular. Onay yalnızca otomatik “yes” tıklamasına dönüşmemelidir. Source, destination, service ve son kullanım tarihi owner'a görünür şekilde sunulmalıdır. Gereksiz access owner tarafından kaldırma adayı olarak işaretlenebilir. Cevap vermeyen owner'lar için escalation ve default action belirlenmelidir.

Business Need'in Yeniden Doğrulanması

Business need zaman içinde proje, organizasyon veya uygulama mimarisi değiştikçe farklılaşabilir. Eskiden gerekli olan doğrudan database erişimi artık API üzerinden sağlanıyor olabilir. Recertification bu eski yolları bulmak için iyi fırsattır. Application owner ve network logları birlikte değerlendirilmelidir. Gerekçesi kalmayan erişim kapatılmalıdır.

Expired Access

Expiration tarihi geçmiş erişim mümkün olduğunda otomatik olarak disable edilmelidir. Manuel takip geçici rule'ların gözden kaçmasına neden olabilir. Owner erişimin devam etmesini istiyorsa yeni approval süreci başlatmalıdır. Expired rule'ların sadece arayüzde pasif kalması da zamanla yönetim yükü oluşturur. Uygun retention süresinden sonra temizlenmelidir.

Automated Recertification

Automated recertification rule envanterini owner'lara otomatik görev olarak gönderir. Kullanım verisi, hit count ve risk skoru ekranda gösterilebilir. Owner belirli süre içinde approve, modify veya remove seçimi yapabilir. Sonuç firewall automation sistemiyle uygulanabilir. Yüksek riskli remove işlemlerinde ek security review eklenebilir.

Evidence ve Audit Trail

Recertification sürecinin ne zaman ve kim tarafından yapıldığı kayıt altına alınmalıdır. Approval sonucu, yorum ve ilgili ticket numarası audit trail oluşturur. Bu kayıtlar compliance denetimlerinde erişim kontrolünün sadece kağıt üzerinde olmadığını gösterebilir. Logların değiştirilemez merkezi sistemde saklanması tercih edilir. Retention süresi kurum politikası ve ilgili yükümlülüklere göre belirlenmelidir.

Firewall Logging Nasıl Yapılmalıdır?

Firewall logging güvenlik görünürlüğünün temel kaynaklarından biridir. Allow ve deny trafiğinin tamamını aynı yoğunlukta kaydetmek her zaman gerekli veya verimli değildir. Kritik erişimler, public servisler, yönetim bağlantıları ve güvenlik olayları için ayrıntılı loglama tercih edilebilir. Session start ve session end bilgileri kullanım senaryosuna göre seçilmelidir. Loglar merkezi sisteme aktarılmalı ve sadece depolanmak yerine alarm, korelasyon ve inceleme için kullanılmalıdır.

Allow Log

Allow log izin verilen trafiğin hangi rule üzerinden geçtiğini gösterir. Kritik erişimlerde kullanıcı, uygulama ve byte bilgisiyle birlikte kaydedilmesi faydalıdır. Çok yüksek hacimli güvenilir trafik için log seviyesi optimize edilebilir. Hiç allow log tutmamak olay incelemesini ciddi şekilde zorlaştırır. Rule riskine göre seçici loglama politikası oluşturulmalıdır.

Deny Log

Deny log engellenen bağlantıları gösterir ve güvenlik scanning veya yanlış konfigürasyon tespitinde değerlidir. Aynı source'dan farklı destination portlarına gelen talepler tarama göstergesi olabilir. İç ağdaki sürekli deny trafiği yanlış uygulama configuration'ına da işaret edebilir. Çok yoğun tekrarlanan bloklarda rate limiting kullanılabilir. Kritik deny event'leri SIEM üzerinde alarm kurallarına bağlanmalıdır.

Session Start

Session start log bağlantı başladığı anda kayıt üretir. Gerçek zamanlı monitoring gereken kritik servislerde faydalı olabilir. Ancak çok kısa ve yoğun bağlantılarda log hacmini ciddi şekilde artırabilir. Bazı kullanım senaryolarında session end log tek başına yeterli bilgi verebilir. Hangi policy için start log gerektiği risk ve operasyon ihtiyacına göre belirlenmelidir.

Session End

Session end log bağlantı tamamlandığında süre ve transferred bytes gibi ek bilgiler sağlayabilir. Bu nedenle network forensic ve kullanım analizi için oldukça değerlidir. Bağlantının neden sona erdiği de bazı platformlarda kaydedilir. Uzun süreli session'larda logun geç oluşacağı unutulmamalıdır. Kritik real-time detection için start ve end log birlikte kullanılabilir.

Log Volume Yönetimi

Log volume yönetimi SIEM maliyeti ve performans açısından önemli konudur. Her health check paketini ayrı kaydetmek yüksek veri hacmi oluşturabilir. Güvenlik değeri düşük tekrar eden event'ler aggregate veya filter edilebilir. Ancak filtering yapılırken olay inceleme için gerekli alanların kaybolmaması gerekir. Periyodik log source review ile hangi kuralın ne kadar veri ürettiği ölçülmelidir.

Rate Limiting

Log rate limiting aynı tür olayın çok yüksek frekansta log sistemini doldurmasını önler. DDoS veya scanning sırasında milyonlarca deny event oluşabilir. Rate limit kullanıldığında gerçek toplam event sayısını gösteren counter bilgisi korunmalıdır. Çok agresif limit önemli saldırı detaylarını gizleyebilir. Eşikler normal trafik ve incident response ihtiyacına göre ayarlanmalıdır.

Central Log Collection

Central log collection birden fazla firewall ve network cihazının kayıtlarını ortak platformda toplar. SIEM bu verileri identity, endpoint ve application loglarıyla ilişkilendirebilir. Merkezi saklama saldırganın tek firewall üzerindeki logları silmesi riskine karşı da avantaj sağlar. Time synchronization bütün sistemlerde tutarlı olmalıdır. Log transport mümkün olduğunda güvenli protokoller üzerinden gerçekleştirilmelidir.

Firewall Loglarında Hangi Alanlar Bulunmalıdır?

Firewall loglarının olay incelemede işe yaraması için yalnızca “izin verildi” veya “engellendi” bilgisi yeterli değildir. Zaman, kaynak, hedef, port, kullanıcı, rule ID, uygulama ve action gibi alanlar birlikte tutulmalıdır. NAT kullanılan ortamlarda original ve translated adres bilgileri ayrıca önemlidir. Bytes transferred gibi ölçüler veri aktarımı ve anormal trafik analizinde kullanılabilir. Log schema'nın SIEM parser ile uyumlu ve standardize olması güvenlik operasyonunu kolaylaştırır.

Timestamp

Timestamp olayın ne zaman gerçekleştiğini gösterir ve farklı log kaynaklarını korele etmek için temel alandır. Firewall ve SIEM sistemleri doğru NTP kaynağına senkronize edilmelidir. Timezone farkları açık biçimde yönetilmelidir. Milisaniye hassasiyeti yüksek hacimli olaylarda faydalı olabilir. Yanlış saat ayarı incident timeline oluşturmayı ciddi şekilde zorlaştırır.

Source IP

Source IP bağlantıyı başlatan ağ adresini gösterir. NAT veya proxy kullanılan ortamda gerçek kullanıcıyı bulmak için ek log kaynakları gerekebilir. DHCP lease geçmişi source IP ile cihazı ilişkilendirmeye yardımcı olur. IPv6 adresleri de parser tarafından doğru desteklenmelidir. Source IP tek başına kullanıcı kimliği olarak kabul edilmemelidir.

Destination IP

Destination IP bağlantının hedef adresini gösterir. Public internet bağlantılarında threat intelligence ile korelasyon yapılabilir. Internal trafik için CMDB veya asset inventory üzerinden hedef sistem adı bulunabilir. DNAT varsa original ve translated destination bilgileri birlikte tutulmalıdır. Kritik hedeflere yönelik başarısız bağlantılar ayrı alarm konusu olabilir.

Source Port

Source port özellikle NAT korelasyonu ve session takibi açısından önemlidir. İstemci bağlantılarında çoğunlukla dinamik yüksek port kullanılır. Aynı public IP'yi paylaşan birçok kullanıcı arasında bağlantıyı ayırmak için source port gerekir. Incident investigation sırasında timestamp ile birlikte değerlendirilmelidir. Log parser bu alanı sayısal formatta doğru saklamalıdır.

Destination Port

Destination port hedef servis hakkında temel bilgi verir. Beklenmeyen yönetim portlarına yapılan bağlantılar alarm üretebilir. Port bilgisi application identification sonucu ile birlikte analiz edilmelidir. Aynı port farklı uygulamalar tarafından kullanılabilir. Firewall rule review sırasında en çok kullanılan servisler destination port istatistiklerinden görülebilir.

Protocol

Protocol alanı TCP, UDP, ICMP veya başka protokol türünü gösterir. Aynı port numarasının farklı protokollerde farklı anlamı olabileceği için bu alan gereklidir. ICMP loglarında type ve code bilgileri de faydalı olabilir. IPv6 trafiği ayrıca network protocol alanıyla ayrıştırılabilir. SIEM rule'ları protocol bağlamını hesaba katmalıdır.

User

User alanı identity-aware firewall kullanıldığında bağlantıyı gerçekleştiren kullanıcı bilgisini gösterir. IP değişse bile erişim olayını kişiye bağlamayı kolaylaştırır. Shared account kullanımı bu görünürlüğü azaltır. User-to-IP mapping hataları için identity source bilgisi de loglanabilir. Hassas kullanıcı loglarına erişim veri koruma politikalarıyla sınırlandırılmalıdır.

Rule ID

Rule ID trafiğin hangi firewall policy ile eşleştiğini gösterir. Rule adı zaman içinde değişse bile sabit ID audit açısından avantaj sağlayabilir. Policy review sırasında yüksek hit alan rule'lar kolayca bulunabilir. Shadow veya general allow sorunları troubleshooting sırasında rule ID üzerinden tespit edilir. SIEM dashboard'larında rule ID ve name birlikte gösterilebilir.

Action

Action firewall'ın bağlantıya allow, deny, reset veya başka hangi kararı verdiğini gösterir. Aynı source ve destination trafiği farklı zamanlarda farklı action alıyorsa policy değişikliği veya identity farkı olabilir. Deny oranı monitoring için faydalı metriktir. Action alanının cihazlar arasında standardize edilmesi SIEM korelasyonunu kolaylaştırır. Vendor-specific değerler ortak şemaya dönüştürülebilir.

Application

Application alanı NGFW tarafından tanımlanan uygulama adını gösterir. Unknown veya incomplete application oranının artması visibility sorununa işaret edebilir. Riskli uygulamalar SIEM üzerinde ayrı kategoriye alınabilir. Port ve application bilgisi birlikte analiz edildiğinde standart dışı kullanım görülebilir. Uygulama imzaları güncel tutulmalıdır.

Bytes Transferred

Bytes transferred oturum boyunca gönderilen ve alınan veri miktarını gösterir. Beklenmeyen yüksek outbound veri hacmi data exfiltration araştırmasını tetikleyebilir. Normal uygulama baseline'ı çıkarılarak anormal session'lar belirlenebilir. Kısa süreli ama yüksek hacimli bağlantılar ayrıca incelenebilir. Byte bilgisi session end loglarında genellikle daha anlamlıdır.

SIEM ile Firewall Entegrasyonu

SIEM ile firewall entegrasyonu ağ güvenliği loglarını diğer sistem kayıtlarıyla merkezi olarak ilişkilendirmeyi sağlar. Firewall tek başına bir bağlantının riskli olduğunu her zaman anlayamaz, ancak endpoint alarmı veya identity olayıyla birleştiğinde daha güçlü sinyal oluşabilir. Port scan, brute force, suspicious egress ve lateral movement gibi davranışlar korelasyon kurallarıyla tespit edilebilir. Log source health düzenli olarak izlenmelidir. SIEM'e veri gitmemesi sessiz güvenlik körlüğü oluşturabileceği için alarm üretilmelidir.

Merkezi Loglama

Merkezi loglama farklı firewall, VPN ve network cihazlarının kayıtlarını tek platformda toplar. Analyst aynı incident içinde birden fazla kaynağı karşılaştırabilir. Logların cihaz üzerinde kısa süre tutulması storage sınırlaması oluşturabileceği için merkezi retention faydalıdır. Yetkisiz log değişikliğine karşı erişim kontrolleri uygulanmalıdır. NTP senkronizasyonu tüm kaynaklarda ortak zaman çizgisi oluşturur.

Port Scan Detection

Port scan detection aynı source'un kısa sürede çok sayıda destination portuna bağlantı denemesi yapmasını izler. Firewall deny logları bu davranış için iyi veri kaynağıdır. Internal scan ile internet kaynaklı scan ayrı eşiklere sahip olabilir. Yetkili vulnerability scanner IP'leri allowlist veya özel suppression kuralıyla yönetilebilir. Bilinmeyen internal scanner aktivitesi daha yüksek öncelik alabilir.

Brute Force Detection

Brute force detection aynı kullanıcı veya IP'nin kısa sürede çok sayıda başarısız authentication denemesi yapmasını izler. Firewall VPN ve management login logları SIEM'e gönderilebilir. Identity provider ve endpoint loglarıyla korelasyon yapılırsa doğruluk artar. Eşikler normal kullanıcı hatalarını alarm yağmuruna dönüştürmeyecek biçimde ayarlanmalıdır. Yüksek riskli olaylarda account lock veya source block gibi response adımları tetiklenebilir.

Suspicious Egress

Suspicious egress beklenmeyen dış bağlantı hedeflerini veya trafik miktarlarını ifade eder. Sunucu ağından bilinmeyen ülkelere bağlantı örnek bir sinyal olabilir. Firewall application ve DNS logları birlikte analiz edildiğinde daha fazla bağlam elde edilir. Threat intelligence malicious destination bilgisini zenginleştirebilir. Otomatik block öncesinde false positive riski ve business impact değerlendirilmelidir.

Threat Intelligence Correlation

Threat intelligence correlation firewall loglarındaki IP veya domain değerlerini bilinen tehdit göstergeleriyle karşılaştırır. Eşleşme bulunması olay önceliğini artırabilir. Her IOC aynı güven seviyesinde olmadığı için source reputation ve freshness değerlendirilmelidir. Çok eski indikatorlerin otomatik block listesinde sonsuza kadar tutulması false positive üretebilir. IOC expiration politikası bu nedenle önemlidir.

Lateral Movement Detection

Lateral movement detection iç ağdaki beklenmeyen erişim denemelerini izler. Kullanıcı cihazından çok sayıda server management portuna bağlantı önemli sinyal olabilir. Firewall East-West logları, authentication event'leri ve EDR uyarıları birlikte değerlendirilmelidir. Segmentasyon ne kadar güçlü olursa başarısız hareket denemeleri o kadar görünür hâle gelir. Kritik zone deny event'leri yüksek öncelikli alarm olarak ele alınabilir.

Incident Investigation

Incident investigation sırasında firewall logları saldırganın hangi sistemlerle iletişim kurduğunu anlamaya yardımcı olur. Source, destination, timestamp, application ve byte bilgileri olay timeline'ına eklenir. NAT ve VPN logları gerçek kullanıcı veya cihazı belirlemek için korele edilir. Geçmiş rule değişiklikleri olayın hangi policy üzerinden gerçekleştiğini açıklayabilir. Yeterli retention süresi bulunması geriye dönük investigation için önemlidir.

SOAR ile Firewall Otomasyonu

SOAR güvenlik olaylarına verilen yanıt adımlarını otomatik veya yarı otomatik hâle getirebilir. Malicious IOC tespit edildiğinde temporary deny rule oluşturmak, endpoint'i izole etmek ve incident ticket açmak gibi işlemler workflow içinde birleştirilebilir. Otomasyon hız kazandırır, ancak yanlış tespit sonucunda kritik trafiği kesme riski de vardır. Bu nedenle action süreleri, human approval ve rollback mekanizmaları açıkça tanımlanmalıdır. Yüksek etkili firewall değişikliklerinde kontrollü otomasyon tercih edilmelidir.

IOC Tespitinden Sonra Otomatik Block

SIEM güvenilir threat intelligence kaynağıyla malicious IP eşleşmesi bulduğunda SOAR firewall API üzerinden block işlemi başlatabilir. Kural mümkün olduğunda dynamic block list veya kısa süreli object yapısında uygulanmalıdır. IOC confidence seviyesi düşükse human approval eklenebilir. Her otomatik action ticket ve audit log oluşturmalıdır. Block süresi dolduğunda indikator tekrar değerlendirilmelidir.

Temporary Deny Rule

Temporary deny rule incident response sırasında şüpheli IP veya network'ü hızlıca engellemek için kullanılabilir. Rule expiration zamanı otomatik belirlenmelidir. Kalıcı deny listelerin yıllar içinde gereksiz büyümesi önlenmelidir. Geçici kural normal business trafiğini etkilerse hızlı rollback yapılabilmelidir. Rule name içinde incident ID veya automation reference bulunması faydalıdır.

Endpoint Isolation

Endpoint isolation ele geçirilmiş cihazın ağ erişimini ciddi şekilde sınırlar. EDR sistemi SOAR üzerinden NAC veya firewall'a izolasyon talebi gönderebilir. Cihaz yalnızca remediation ve forensic servislerine erişebilir. Automation yanlış cihazı izole ederse iş etkisi yüksek olabileceği için kimlik doğruluğu önemlidir. Kritik sunucularda automatic isolation yerine analyst approval tercih edilebilir.

Rule Expiration

Otomatik incident rule'larının expiration alanına sahip olması gereksiz kalıcı policy oluşmasını önler. IOC birkaç saat veya gün sonra geçerliliğini kaybedebilir. Süre dolmadan önce tehdit verisi yeniden kontrol edilebilir. Hâlâ aktif risk varsa kural yeni süreyle uzatılabilir. Expire olan object ve rule'lar otomatik cleanup süreciyle kaldırılmalıdır.

Human Approval

Human approval yüksek etkili otomasyon adımlarında güvenli karar noktası sağlar. Analyst SOAR tarafından hazırlanan source, destination ve threat context bilgisini görerek block kararı verebilir. Düşük riskli ve yüksek güvenilirlikli olaylar tam otomatik ilerleyebilir. Kritik production servislerini etkileyen işlemler manuel onay gerektirebilir. Approval gecikmesini azaltmak için mobil veya nöbetçi workflow kullanılabilir.

Automated Rollback

Automated rollback belirli koşullar oluştuğunda SOAR tarafından yapılan firewall değişikliğini geri alır. Örneğin kritik servis health check başarısız olursa temporary block kaldırılabilir. Rollback action da aynı incident kaydına işlenmelidir. Hangi koşulların geri alma tetikleyeceği önceden tanımlanmalıdır. Otomatik rollback düzenli testlerle doğrulanmalıdır.

Threat Intelligence Firewall Kurallarında Nasıl Kullanılır?

Threat intelligence bilinen malicious IP, domain ve saldırı altyapısı bilgilerini firewall kontrollerine taşımaya yardımcı olabilir. Bu veriler manuel static rule yerine dinamik listelerle yönetildiğinde daha güncel kalır. Her indicator aynı güvenilirlik seviyesinde olmadığı için confidence ve age bilgileri değerlendirilmelidir. Süresi dolmuş IOC'leri kalıcı engel olarak tutmak false positive riskini artırır. Threat intelligence her zaman kendi ağ logları ve iş bağlamıyla birlikte kullanılmalıdır.

Malicious IP

Malicious IP bilinen saldırı, botnet veya kötü amaçlı altyapıyla ilişkilendirilmiş adres olabilir. Firewall bu IP'ye gelen veya giden bağlantıları engelleyebilir. Ancak shared hosting ve cloud altyapılarında aynı IP birden fazla meşru servisi barındırabilir. Bu nedenle kaynak güvenilirliği ve indicator freshness önemlidir. Otomatik block sonrası business impact monitoring yapılmalıdır.

Malicious Domain

Malicious domain phishing, malware veya C2 faaliyetleriyle ilişkili alan adıdır. DNS security ve firewall URL filtering bu domain'lere erişimi engelleyebilir. Domain'in IP adresi sık değişebildiği için sadece IP tabanlı block yeterli olmayabilir. DNS logları hangi internal cihazın domain'i sorguladığını gösterebilir. Domain IOC süresi dolduğunda listeden çıkarılmalıdır.

C2 Infrastructure

C2 infrastructure ele geçirilmiş cihazların saldırgan komutlarını aldığı dış altyapıyı ifade eder. Firewall ve DNS loglarında bu hedeflere bağlantı kritik security event olarak değerlendirilmelidir. Threat intelligence bilinen C2 IP ve domain listesini sağlayabilir. Sadece block yapmak yerine bağlantıyı başlatan endpoint üzerinde incident investigation yapılmalıdır. Kaynak cihaz gerekirse NAC veya EDR üzerinden izole edilmelidir.

Dynamic Block List

Dynamic block list IOC'lerin firewall policy'ye otomatik ve sürekli güncellenen liste olarak aktarılmasını sağlar. Bu yaklaşım binlerce static rule oluşturmaktan daha yönetilebilir olabilir. Liste kaynağı doğrulanmalı ve TLS üzerinden güvenli biçimde çekilmelidir. Güncelleme başarısız olduğunda monitoring alarmı üretmelidir. Liste boyutu ve firewall kapasitesi de kontrol edilmelidir.

IOC Expiration

IOC expiration threat indicator'in belirli süre sonunda geçerliliğini yeniden değerlendirmeyi sağlar. Bir IP geçmişte malicious olsa bile aylar sonra farklı kullanıcıya atanmış olabilir. Kalıcı engel false positive üretebilir. Indicator type ve confidence seviyesine göre farklı expiration süreleri kullanılabilir. Süresi dolan IOC tekrar doğrulanmadan block listede tutulmamalıdır.

False Positive Yönetimi

False positive meşru trafiğin yanlışlıkla malicious olarak işaretlenmesidir. Firewall otomatik block sistemlerinde bu durum kritik uygulama kesintisine yol açabilir. Allow exception süreci hızlı ama kontrollü olmalıdır. Exception oluşturulurken indicator ve business impact analiz edilmelidir. Tek bir olay nedeniyle tüm threat feed'in devre dışı bırakılması yerine kaynağın kalitesi ayrıca değerlendirilmelidir.

Cloud Ortamlarında Firewall ve Erişim Denetimi

Cloud ortamlarında firewall ve erişim denetimi fiziksel network cihazından daha fazla bileşene dağılabilir. Security Group, Network ACL, virtual firewall ve cloud-native policy servisleri birlikte kullanılabilir. Infrastructure as Code yaklaşımı policy değişikliklerinin Git üzerinden review edilmesini kolaylaştırır. Çoklu account veya project yapılarında merkezi governance olmadan configuration drift hızlı şekilde büyüyebilir. Cloud güvenliğinde network policy ile identity policy'nin birlikte değerlendirilmesi önemlidir.

Virtual Firewall

Virtual firewall klasik firewall özelliklerini sanal appliance olarak cloud veya virtualized data center üzerinde sunar. Routing, NAT, VPN, IPS ve application control gibi yetenekleri olabilir. Scale ve HA tasarımı fiziksel cihazlardan farklı yöntemler gerektirebilir. Cloud route table'larının trafiği gerçekten firewall üzerinden geçirdiği doğrulanmalıdır. Bypass route veya doğrudan internet gateway bağlantıları kontrol edilmelidir.

Security Group

Security Group cloud iş yükünün interface veya instance seviyesinde erişim kontrolü sağlayabilir. Birçok platformda stateful davranır. Workload etiketi veya başka security group referansı policy içinde kullanılabilir. Bu yapı IP değişikliklerine daha dayanıklı olabilir. Default security group'ların gereğinden geniş bırakılmaması gerekir.

Network ACL

Network ACL çoğu cloud tasarımında subnet seviyesinde stateless filtreleme sağlar. Inbound ve outbound kurallar ayrı değerlendirilir. Return traffic için gerekli ephemeral port aralıkları hesaba katılmalıdır. Security Group ile birlikte defense in depth oluşturabilir. Çok karmaşık NACL rule set'leri troubleshooting'i zorlaştırabileceği için kullanım amacı net olmalıdır.

Cloud NGFW

Cloud NGFW managed service veya virtual appliance şeklinde application-aware firewall özellikleri sağlayabilir. Merkezi internet egress, inter-VPC veya inter-VNet kontrolünde kullanılabilir. TLS inspection, IPS ve URL filtering gibi özellikler servis kapasitesine göre değerlendirilebilir. Traffic steering cloud routing tasarımının önemli parçasıdır. Loglar merkezi SIEM ve cloud logging sistemlerine gönderilmelidir.

Centralized Policy

Centralized policy birden fazla cloud account, region veya project için ortak güvenlik standartları uygular. Her ekip kendi firewall kuralını bağımsız oluşturduğunda tutarsızlık oluşabilir. Merkezi policy framework minimum baseline sağlayabilir. Uygulama ekiplerine kontrollü self-service alanı bırakmak operasyon hızını korur. Policy exception süreçleri zaman sınırlı ve owner bilgili olmalıdır.

Multi-Account ve Multi-Project Yönetimi

Büyük cloud ortamlarında yüzlerce account veya project bulunabilir. Manuel firewall inventory bu ölçekte sürdürülebilir değildir. Merkezi asset discovery ve policy scanner araçları gereklidir. Public exposure, overly permissive security group ve unused rule otomatik raporlanabilir. Organization-level policy ile kritik ağ erişimleri merkezi olarak sınırlandırılabilir.

Security Group ile Network ACL Arasındaki Fark

Security Group ve Network ACL cloud ortamlarında farklı seviyelerde network access kontrolü sağlar. Security Group çoğunlukla instance veya interface seviyesinde ve stateful çalışırken Network ACL subnet seviyesinde ve stateless olabilir. Platform ayrıntıları değişebileceği için kullanılan cloud servisinin resmi dokümantasyonu doğrulanmalıdır. İki kontrol birbirinin birebir alternatifi değildir. Uygun tasarımda farklı riskleri sınırlayan iki ayrı defense in depth katmanı olarak kullanılabilir.

Stateful vs Stateless

Security Group stateful olduğunda izin verilen bağlantının return traffic'i otomatik olarak kabul edilir. Network ACL stateless ise dönüş yönü için ayrıca uygun izin tanımlanması gerekir. Bu fark özellikle ephemeral port yönetiminde önemlidir. Yanlış NACL kuralı tek yönlü bağlantı problemlerine yol açabilir. Troubleshooting sırasında flow log kullanmak yararlıdır.

Instance/Interface vs Subnet

Security Group genellikle belirli instance veya network interface ile ilişkilidir. Network ACL ise tüm subnet'e uygulanabilir. Bu nedenle SG workload seviyesinde daha ayrıntılı kontrol sağlar. NACL subnet için geniş güvenlik sınırı oluşturabilir. Hangi katmanın neyi kontrol ettiği cloud architecture dokümanında açıkça belirtilmelidir.

Allow vs Allow/Deny

Bazı cloud Security Group modelleri yalnızca allow rule destekler ve eşleşmeyen trafik varsayılan olarak engellenir. Network ACL ise allow ve explicit deny rule destekleyebilir. Bu davranış kullanılan cloud platformuna bağlıdır. Deny rule ihtiyacı varsa doğru kontrol katmanı seçilmelidir. Politika tasarımında vendor davranışı varsayılmadan doğrulanmalıdır.

Rule Evaluation

Security Group ve Network ACL rule evaluation yöntemleri farklı olabilir. Birinde rule sırası önemsizken diğerinde numaralı sıraya göre ilk eşleşme uygulanabilir. Yanlış varsayım access problemine veya güvenlik açığına yol açabilir. Policy-as-code testleri evaluation mantığını doğrulamak için kullanılabilir. Değişiklik sonrası flow log ve connectivity test yapılmalıdır.

Defense in Depth

Security Group workload'a yakın kontrol sağlarken Network ACL subnet sınırında ek filtreleme yapabilir. İkisini birlikte kullanmak tek bir yanlış konfigürasyonun etkisini azaltabilir. Ancak gereksiz duplicate rule yönetim yükünü artırmamalıdır. Her kontrol katmanının net sorumluluğu belirlenmelidir. Baseline policy ve uygulama özel policy ayrımı bu yapıyı daha anlaşılır kılar.

Multi-Cloud Firewall Politikaları

Multi-cloud ortamında farklı sağlayıcıların network policy modelleri ve terminology'si birbirinden farklı olabilir. Buna rağmen kurumun temel güvenlik prensipleri tutarlı kalmalıdır. Default deny, least privilege, logging, owner ve expiration gibi standartlar bütün platformlara uygulanabilir. Policy-as-code ve merkezi inventory bu tutarlılığı sağlamaya yardımcı olur. Configuration drift düzenli taranarak beklenmeyen public exposure veya overly permissive rule'lar tespit edilmelidir.

AWS

AWS ortamında Security Group, Network ACL, route table ve çeşitli firewall servisleri birlikte kullanılabilir. VPC'ler arası ve internet egress mimarisi merkezi veya dağıtık tasarlanabilir. Flow Logs erişim analizi için önemli veri kaynağıdır. Security Group reference kullanımı IP bağımlılığını azaltabilir. Organization seviyesinde guardrail ve otomatik policy kontrolü değerlendirilmelidir.

Azure

Azure ortamında NSG, route table ve firewall servisleri network access control için kullanılabilir. VNet peering ve hub-spoke mimarilerinde trafik yolunun doğru güvenlik noktasından geçtiği doğrulanmalıdır. NSG flow log benzeri görünürlük kaynakları izleme için değerlidir. Merkezi firewall policy farklı subscription'larda standart oluşturabilir. Identity ve network erişimi birlikte ele alınmalıdır.

Google Cloud

Google Cloud ortamında VPC firewall rule ve hierarchical firewall policy gibi kontroller kullanılabilir. Project ve organization yapısı policy governance açısından önemlidir. Service account gibi kimlik kavramları network policy bağlamında değerlendirilebilir. VPC Flow Logs trafik görünürlüğü sağlar. Shared VPC tasarımında merkezi ve uygulama ekiplerinin sorumlulukları açıkça ayrılmalıdır.

On-Prem

On-prem ağlar multi-cloud yapının hâlâ önemli parçasıdır. Data center firewall, WAN ve VPN bağlantıları cloud policy ile uyumlu olmalıdır. Aynı IP aralıklarının farklı ortamlarda tekrar kullanılması routing ve policy sorunlarına yol açabilir. Hybrid network data flow haritası düzenli güncellenmelidir. On-prem ile cloud arasındaki bağlantı da ayrı trust boundary olarak değerlendirilmelidir.

Policy Consistency

Policy consistency aynı güvenlik prensiplerinin farklı platformlarda benzer biçimde uygulanmasını sağlar. Teknik syntax farklı olsa bile public database erişiminin engellenmesi gibi hedef değişmez. High-level security policy bu nedenle vendor bağımsız tanımlanabilir. Otomasyon bu politikayı platforma özgü kurallara çevirebilir. Exception'lar merkezi kayıt altında tutulmalıdır.

Configuration Drift

Configuration drift başlangıçta aynı standarda sahip ortamların zaman içinde birbirinden farklılaşmasıdır. Manuel değişiklikler ve acil operasyonlar bu durumu hızlandırabilir. Otomatik cloud scanner beklenen policy ile gerçek configuration'ı karşılaştırabilir. Drift tespit edildiğinde neden ve owner belirlenmelidir. Yetkisiz değişiklikler otomatik rollback veya security alert tetikleyebilir.

Central Governance

Central governance bütün cloud platformlarında minimum network security standardı belirler. Uygulama ekipleri tamamen merkezi ekibe bağımlı olmadan güvenli self-service kullanabilir. Policy templates, approval workflow ve automated checks ortak servis olarak sunulabilir. İstisna erişimler owner ve expiration ile yönetilmelidir. Merkezi governance hız ile güvenlik arasında dengeli tasarlanmalıdır.

Kubernetes Network Security

Kubernetes ağ güvenliği pod'lar, namespace'ler ve dış servisler arasındaki trafiğin kontrollü yönetilmesini gerektirir. Varsayılan olarak bazı cluster ağlarında pod'lar birbirine geniş erişime sahip olabilir. NetworkPolicy kullanılarak ingress ve egress bağlantıları sınırlandırılabilir. Default-deny yaklaşımı yeni namespace'lerde güvenli başlangıç sağlar. Cilium ve eBPF tabanlı çözümler daha ayrıntılı visibility ve enforcement özellikleri sunabilir.

Kubernetes NetworkPolicy

Kubernetes NetworkPolicy pod grupları arasındaki trafiği label seçicileri ve port tanımlarıyla sınırlar. Policy'nin gerçekten uygulanması için kullanılan CNI plugin'in NetworkPolicy desteği bulunmalıdır. Yalnızca YAML oluşturmak enforcement garantisi değildir. Ingress ve egress kuralları ayrı tanımlanabilir. Policy testleri deployment pipeline içinde otomatik çalıştırılabilir.

Pod-to-Pod Trafik

Pod-to-Pod trafik microservice mimarisinin temel iletişim modelidir. Her pod'un bütün cluster ile konuşması çoğu uygulamada gerekli değildir. Web service yalnızca API pod'una, API ise belirli database servisine erişebilir. NetworkPolicy bu akışı label bazında sınırlandırabilir. Service mesh kullanılsa bile network-level policy ek defense in depth sağlar.

Namespace Segmentation

Namespace segmentation farklı ekip veya uygulama ortamlarını mantıksal olarak ayırır. Ancak namespace tek başına network isolation sağlamaz. NetworkPolicy ile cross-namespace traffic açık biçimde kontrol edilmelidir. Production ve development namespace'leri arasında default deny uygulanabilir. Cluster-wide shared servisler için açık istisnalar tanımlanmalıdır.

Ingress

Kubernetes ingress dış veya başka segmentlerden pod'lara gelen trafiği kapsar. Ingress controller public service exposure için merkezi nokta olabilir. NetworkPolicy yalnızca ingress controller pod'larından application pod'una erişime izin verebilir. Backend servislerin doğrudan internetten erişilebilir olmaması gerekir. TLS termination ve WAF ihtiyacı mimariye göre değerlendirilmelidir.

Egress

Pod egress kontrolü container iş yüklerinin internete veya başka internal servislere yaptığı bağlantıları sınırlar. Default olarak geniş egress bırakmak ele geçirilmiş pod'un C2 iletişimini kolaylaştırabilir. DNS ve gerekli API hedefleri açıkça tanımlanabilir. FQDN tabanlı policy için kullanılan network plugin özellikleri değerlendirilmelidir. Egress logları SIEM ve runtime security sistemleriyle ilişkilendirilebilir.

Default-Deny NetworkPolicy

Default-Deny NetworkPolicy namespace içindeki pod'ların açık izin olmadan iletişim kurmasını engeller. Yeni uygulamalar için güvenli başlangıç noktası oluşturur. Daha sonra gerekli application flow'lar ayrı allow policy olarak eklenir. Geçiş mevcut cluster'da yapılacaksa önce gözlem ve trafik analizi gerekir. Doğrudan default deny uygulamak üretim kesintisine yol açabileceği için aşamalı deployment tercih edilmelidir.

Cilium ve eBPF

Cilium eBPF teknolojisini kullanarak Kubernetes ve cloud-native ortamlarda network security ve observability sağlayan açık kaynaklı bir projedir. Layer 3, Layer 4 ve bazı senaryolarda Layer 7 policy uygulayabilir. Identity tabanlı network enforcement dinamik pod adreslerinde avantaj sağlar. Hubble gibi observability özellikleri flow görünürlüğünü artırabilir. Üretim kullanımı öncesinde cluster sürümü, CNI mimarisi, operasyon deneyimi ve performans ihtiyacı değerlendirilmelidir.

Firewall as Code Nedir?

Firewall as Code güvenlik politikalarının yalnızca grafik arayüz üzerinden manuel girilmesi yerine kod veya deklaratif dosyalar olarak yönetilmesini ifade eder. Policy dosyaları Git üzerinde version control altında tutulabilir. Her değişiklik pull request, peer review ve otomatik test sürecinden geçirilebilir. Bu yaklaşım kim, ne zaman ve neden değişiklik yaptı sorularına daha açık cevap verir. Büyük ve çoklu ortamların yönetiminde otomasyon, consistency ve rollback açısından önemli avantaj sağlar.

Manuel GUI Yönetiminin Sorunları

Manuel GUI değişiklikleri küçük ortamlarda hızlı olabilir, ancak büyük yapılarda tekrar edilebilirlik problemi oluşturur. Aynı kural farklı firewall'larda küçük farklarla uygulanabilir. Değişiklik geçmişi eksik veya cihaz arayüzüne bağımlı kalabilir. Peer review production değişikliğinden önce yapılamayabilir. Firewall as Code bu süreçleri merkezi ve denetlenebilir hâle getirmeyi amaçlar.

Declarative Policy

Declarative policy istenen son durumu tanımlar. Kullanıcı tek tek CLI adımlarından çok hangi kaynakların hangi hedeflere erişmesi gerektiğini belirtir. Otomasyon sistemi mevcut durumla istenen yapı arasındaki farkı hesaplayabilir. Bu yaklaşım idempotent deployment için avantaj sağlar. Policy schema iyi tasarlanmazsa karmaşık ihtiyaçları ifade etmek zorlaşabileceği için standart model önemlidir.

Infrastructure as Code

Infrastructure as Code network ve security altyapısının kodla tanımlanmasını sağlar. Firewall object, cloud security group ve route policy aynı repository içinde veya ilişkili modüllerde tutulabilir. Version control geçmişi değişiklikleri görünür hâle getirir. Automated plan çıktısı production öncesi impact review sağlar. Secret değerler repository içinde düz metin olarak saklanmamalıdır.

Terraform

Terraform çok sayıda cloud ve network platformu için deklaratif altyapı yönetimi sağlayan yaygın araçlardan biridir. Firewall veya security group policy provider desteğine bağlı olarak kodla oluşturulabilir. Plan çıktısı yapılacak değişiklikleri deployment öncesi gösterir. State dosyası hassas bilgi içerebileceği için güvenli backend kullanılmalıdır. Terraform modülleri kurumun standard firewall rule yapısını tekrar kullanılabilir hâle getirebilir.

Git Versioning

Git versioning firewall policy değişikliklerinin tarihsel kaydını tutar. Hangi satırın kim tarafından değiştirildiği görülebilir. Branch ve pull request modeli production policy'ye doğrudan kontrolsüz değişiklik yapılmasını önler. Commit mesajında ticket veya change ID bulunabilir. Gerekirse önceki güvenli sürüme dönüş kolaylaşır.

Pull Request Review

Pull request review firewall değişikliğinin production'a gitmeden başka uzmanlar tarafından incelenmesini sağlar. Reviewer source, destination, port ve risk kapsamını kontrol edebilir. Otomatik linter ve policy test sonuçları aynı ekranda gösterilebilir. Approval olmadan merge engellenebilir. Yüksek riskli değişiklikler security team review gerektirebilir.

Automated Deployment

Automated deployment onaylanmış policy'nin firewall API veya management platform üzerinden tutarlı şekilde uygulanmasını sağlar. Manuel copy-paste hataları azalır. Deployment logları audit evidence olarak saklanabilir. Health check başarısız olursa pipeline durabilir veya rollback çalışabilir. Production erişim credential'ları güvenli secret management sisteminde tutulmalıdır.

Firewall Kuralları Git ile Nasıl Yönetilir?

Git firewall policy'leri için versioning, review ve audit altyapısı sağlayabilir. Policy repository içinde network object, service definition ve high-level erişim kuralları tutulabilir. Branch ve pull request süreçleri değişikliklerin production'dan önce incelenmesini sağlar. Her merge ticket veya change request ile ilişkilendirilebilir. Bu model özellikle çoklu firewall ve cloud ortamlarında configuration consistency sağlamak için güçlü bir temel oluşturur.

Policy Repository

Policy repository firewall konfigürasyonu veya deklaratif güvenlik kurallarının merkezi kod deposudur. Ortamlar klasör, branch veya modül yapısıyla ayrılabilir. README ve contribution yönergeleri ekip standardını açıklar. Sensitive credential repository içinde tutulmamalıdır. Repository erişimi RBAC ve MFA ile korunmalıdır.

Branch

Branch yeni firewall değişikliğinin ana production policy'den ayrı geliştirilmesini sağlar. Engineer değişikliğini test edip review'a hazır hâle getirebilir. Branch naming standardı ticket numarası içerebilir. Uzun süre açık kalan branch'ler main policy'den uzaklaşabileceği için düzenli güncellenmelidir. Merge sonrası gereksiz branch'ler temizlenebilir.

Pull Request

Pull request proposed firewall değişikliğini ekip review'una açar. Diff görünümü hangi source, destination veya service alanının değiştiğini gösterir. Otomatik CI test sonuçları aynı PR içinde görülebilir. Reviewer yorumları ve approval kararı audit kaydı oluşturur. Merge yetkisi risk seviyesine göre sınırlanmalıdır.

Peer Review

Git tabanlı peer review değişikliğin henüz production'a uygulanmadan incelenmesini sağlar. Reviewer yalnızca syntax değil security intent açısından da değerlendirme yapmalıdır. Any, broad subnet ve missing expiration gibi riskler kontrol edilir. Otomatik botlar standart hataları işaretleyebilir. İnsan reviewer iş bağlamı ve istisna gerekçesini değerlendirmeye devam eder.

Change History

Git change history geçmiş firewall policy sürümlerine erişim sağlar. Commit tarihleri, author ve message bilgileri değişiklik bağlamı oluşturur. Incident investigation sırasında belirli tarihte hangi rule'un aktif olduğu bulunabilir. Force push ve history rewrite production repository'de sınırlandırılmalıdır. Audit gereksinimleri için repository logları ayrıca saklanabilir.

Rollback

Git rollback önceki policy sürümüne geri dönmeyi kolaylaştırır. Ancak kodun geri alınması tek başına firewall cihazında otomatik rollback anlamına gelmez. Deployment pipeline revert edilen sürümü tekrar production'a uygulamalıdır. State değişiklikleri ve dış bağımlılıklar kontrol edilmelidir. Rollback de ayrı change record ve validation sürecinden geçmelidir.

Audit Evidence

Pull request, approval, commit ve deployment kayıtları güçlü audit evidence oluşturabilir. Kim hangi rule'u neden değiştirdi sorusu tek zincir içinde cevaplanabilir. Ticket bağlantısı business justification bilgisini sağlar. CI test sonuçları security validation kanıtı olabilir. Repository retention ve access control politikaları denetim ihtiyacına göre belirlenmelidir.

CI/CD ile Firewall Policy Değişikliği

CI/CD firewall policy değişikliklerini otomatik syntax kontrolünden security policy testlerine kadar bir dizi aşamadan geçirebilir. Amaç kontrolü azaltmak değil, tekrar eden kontrolleri standart ve hızlı hâle getirmektir. Duplicate, shadow ve overly permissive rule gibi sorunlar merge öncesinde otomatik tespit edilebilir. Approval gate yüksek riskli değişikliklerde insan kararını korur. Deployment sonrası validation başarısız olduğunda pipeline otomatik rollback veya manuel müdahale tetikleyebilir.

Syntax Validation

Syntax validation policy dosyasının teknik olarak geçerli formatta olup olmadığını kontrol eder. Yanlış CIDR, eksik alan veya unsupported action gibi hatalar daha production'a gitmeden tespit edilir. Schema validation bu süreci otomatikleştirebilir. Vendor API tarafından kabul edilmeyen değerler pipeline'ı durdurmalıdır. Bu kontrol güvenlik tasarımını doğrulamaz, ancak temel configuration hatalarını azaltır.

Security Policy Check

Security policy check kurumun yazılı güvenlik standartlarını otomatik test eder. Örneğin internetten management portuna Any source erişimi yasaklanabilir. Temporary rule için expiration zorunlu tutulabilir. Policy-as-code motoru pull request aşamasında ihlali gösterebilir. Exception gerekiyorsa açık approval ve süre sınırı uygulanmalıdır.

Duplicate Detection

Duplicate detection mevcut policy set içinde aynı access rule'un zaten bulunup bulunmadığını kontrol eder. Yeni gereksiz rule eklenmesini önler. Aynı source ve destination farklı object isimleri altında saklanmışsa semantic comparison gerekebilir. Otomatik araç object expansion yaparak eşdeğerliği analiz edebilir. Duplicate tespit edildiğinde mevcut rule owner bilgisi talep sahibine gösterilebilir.

Shadow Rule Detection

Shadow rule detection yeni policy'nin üstteki başka rule nedeniyle hiç çalışmayacağını belirlemeye çalışır. Aynı zamanda yeni geniş kuralın alttaki mevcut policy'leri shadow edip etmeyeceği kontrol edilmelidir. Bu ikinci durum güvenlik açısından daha kritik olabilir. Pipeline simulation ile rule evaluation sonucu hesaplanabilir. Riskli shadow tespitinde merge otomatik olarak durdurulabilir.

Connectivity Test

Connectivity test beklenen source ve destination akışlarının policy sonucunu kontrol eder. Lab veya simulation ortamında expected allow ve expected deny senaryoları çalıştırılabilir. Gerçek production bağlantısına gerek olmadan policy logic doğrulanabilir. Infrastructure test framework'leri bu senaryoları kod olarak saklayabilir. Her önemli uygulama için regression bağlantı testi oluşturmak faydalıdır.

Approval Gate

Approval gate otomatik testler başarılı olsa bile belirli riskli değişiklikler için insan onayı ister. Security reviewer veya system owner pull request içindeki değişikliği değerlendirebilir. Düşük riskli standard rule otomatik geçiş alabilir. Risk scoring approval seviyesini belirleyebilir. Böylece operasyon hızı korunurken kritik kararlar kontrol altında tutulur.

Deployment

Deployment onaylanmış policy'nin API veya merkezi management sistemi üzerinden hedef firewall'a uygulanmasıdır. Pipeline önce plan veya diff çıktısını son kez gösterebilir. Device health ve configuration lock durumu kontrol edilir. Başarılı deploy sonrası commit ID ile cihaz policy revision ilişkilendirilebilir. Hata oluşursa deployment durdurulmalı ve kısmi değişiklik etkisi kontrol edilmelidir.

Post-Deployment Validation

Post-deployment validation yeni policy'nin gerçek ortamda beklendiği gibi çalıştığını doğrular. Rule hit, connectivity ve deny testleri otomatik çalıştırılabilir. Firewall loglarında doğru policy ID kontrol edilir. Critical health check başarısız olursa rollback tetiklenebilir. Validation sonucu deployment kaydına eklenerek audit trail tamamlanır.

Policy as Code Nedir?

Policy as Code güvenlik gereksinimlerinin insan tarafından okunabilir olduğu kadar makine tarafından da değerlendirilebilir kurallar şeklinde tanımlanmasıdır. “Public database erişimi yasaktır” veya “temporary admin access expiration içermelidir” gibi yüksek seviyeli prensipler kodlaştırılabilir. CI/CD bu kuralları her değişiklikte otomatik test eder. Multi-vendor ortamında ortak policy farklı platform konfigürasyonlarına dönüştürülebilir. Bu yaklaşım güvenlik standardının dokümanda kalmak yerine delivery sürecinde uygulanmasını sağlar.

High-Level Security Policy

High-level security policy teknik syntax'tan bağımsız güvenlik hedefini tanımlar. Örneğin management interface yalnızca trusted admin network'ten erişilebilir olabilir. Bu kural farklı firewall platformlarında farklı komutlarla uygulanabilir. Merkezi policy business ve security ekiplerinin ortak dilini oluşturur. Teknik implementation değişse bile güvenlik hedefi aynı kalır.

Machine-Readable Policy

Machine-readable policy güvenlik kuralının yazılım tarafından otomatik değerlendirilebileceği formatta tutulmasıdır. JSON, YAML veya policy language kullanılabilir. CI sistemi proposed change'i bu kurallara göre kontrol eder. Manual checklist ihtiyacı tamamen ortadan kalkmasa da standart kontroller otomatikleşir. Policy repository değişiklikleri de review ve version control altında tutulmalıdır.

Automated Compliance

Automated compliance firewall ve cloud policy'lerinin kurum standardına uygunluğunu sürekli kontrol eder. Any Any Allow, missing owner veya expired rule otomatik raporlanabilir. Deviation bulunduğunda ticket açılabilir veya düşük riskli durumlarda auto-remediation uygulanabilir. Compliance sonucu dashboard üzerinden takip edilebilir. İnsan review özellikle exception ve business context için gerekli olmaya devam eder.

Policy Drift Detection

Policy drift detection Git veya merkezi kaynakta tanımlanan beklenen policy ile gerçek firewall konfigürasyonunu karşılaştırır. Emergency veya manuel GUI değişikliği drift oluşturabilir. Sistem farkı tespit ettiğinde alert üretebilir. Yetkili emergency change sonradan repository'ye geri işlenmelidir. Yetkisiz değişiklik gerekirse otomatik geri alınabilir.

Multi-Vendor Policy Generation

Multi-vendor policy generation ortak güvenlik modelini farklı firewall syntax'larına dönüştürmeyi amaçlar. Böylece aynı business rule için her platformda manuel kural yazma ihtiyacı azalır. Vendor özellikleri birebir aynı olmadığı için translation katmanı dikkatle tasarlanmalıdır. Desteklenmeyen özellikler pipeline'da açık hata üretmelidir. Generated policy production öncesinde platform özel testlerden geçirilmelidir.

Firewall Yönetim Arayüzü Nasıl Korunmalıdır?

Firewall yönetim arayüzü ağın en kritik yönetim noktalarından biridir ve normal kullanıcı veya internet ağlarından doğrudan erişilebilir olmamalıdır. Ayrı management network, trusted admin subnet ve jump host kullanımı güçlü temel oluşturur. VPN veya ZTNA üzerinden kontrollü uzaktan erişim sağlanabilir. MFA, güçlü TLS veya SSH ayarları ve kişisel admin hesapları zorunlu hâle getirilmelidir. Yönetim oturumları merkezi log sisteminde kaydedilmeli ve beklenmeyen login denemeleri alarm üretmelidir.

Management Network

Management network yalnızca altyapı cihazlarının yönetim trafiği için ayrılmış segmenttir. Kullanıcı endpoint'leri bu ağa doğrudan erişmemelidir. Firewall, switch ve hypervisor management interface'leri bu zone içinde tutulabilir. İnternet erişimi yalnızca gerekli update veya management servisleriyle sınırlanmalıdır. Management network'e erişim ayrı administrator policy üzerinden sağlanmalıdır.

Trusted Admin Subnet

Trusted admin subnet yalnızca yönetim görevleri için kullanılan kontrollü cihazların bulunduğu ağdır. Normal kullanıcı laptop'ları bu subnet'e dahil edilmemelidir. Firewall management arayüzü sadece bu kaynaklardan bağlantı kabul edebilir. Admin workstation'larda EDR, disk encryption ve MFA gibi ek kontroller bulunmalıdır. Trusted subnet tek başına kimlik doğrulama yerine ek güvenlik sinyali olarak kullanılmalıdır.

Jump Host

Jump host administratorların kritik sistemlere tek kontrollü noktadan bağlanmasını sağlar. Management zone'a doğrudan bireysel cihaz erişimini azaltır. Jump host üzerinde MFA, session logging ve sıkı endpoint security uygulanabilir. Internet browsing veya normal ofis işleri için kullanılmamalıdır. High availability ve backup erişim yöntemi planlanmalıdır.

VPN/ZTNA

Uzaktan firewall yönetimi gerekiyorsa management interface'i doğrudan internete açmak yerine VPN veya ZTNA kullanılmalıdır. Kullanıcı güçlü authentication sonrası yalnızca gerekli yönetim servisine erişebilir. Source IP ve device posture ek policy kriteri olabilir. Admin access normal remote user policy'sinden ayrılmalıdır. Session süreleri kısa tutulabilir ve idle timeout uygulanabilir.

MFA

MFA administrator hesabı ele geçirilse bile ek doğrulama katmanı sağlar. Firewall GUI, SSH gateway veya central manager login'i MFA ile korunabilir. Phishing-resistant yöntemler mümkün olduğunda tercih edilmelidir. Emergency break-glass erişim için ayrı güvenli MFA yöntemi bulunabilir. MFA failure ve bypass event'leri SIEM'e gönderilmelidir.

SSH/TLS

Firewall yönetim bağlantıları şifreli SSH ve TLS protokolleri üzerinden yapılmalıdır. Zayıf cipher ve eski protokol sürümleri devre dışı bırakılmalıdır. Yönetim sertifikaları güvenilir internal PKI ile yönetilebilir. Self-signed sertifika kullanımı gerekiyorsa fingerprint doğrulama süreçleri oluşturulmalıdır. SSH key ve certificate yaşam döngüsü düzenli olarak yönetilmelidir.

Legacy Protocol'leri Kapatmak

Telnet, HTTP veya eski TLS sürümleri gibi legacy yönetim protokolleri kullanılmıyorsa kapatılmalıdır. Bu servisler hem şifreleme hem güvenlik açığı açısından risk oluşturabilir. Device hardening checklist içinde aktif management service review bulunmalıdır. Firmware upgrade sonrası yeni veya eski servislerin varsayılan durumu tekrar kontrol edilmelidir. Kullanılmayan servislerin kapalı olması attack surface'i azaltır.

Admin Session Logging

Admin session logging yöneticilerin firewall üzerinde yaptığı değişiklikleri kayıt altına alır. Login, policy change, commit ve configuration export gibi işlemler izlenmelidir. Mümkünse komut veya change diff bilgisi de saklanır. Loglar firewall dışında merkezi sistemde tutulmalıdır. Yetkisiz veya olağan dışı değişiklikler SIEM alarmı tetikleyebilir.

Firewall Administrator Yetkileri

Firewall administrator hesapları yüksek ayrıcalığa sahip olduğu için minimum gerekli yetki prensibiyle yönetilmelidir. Her kullanıcıya super admin vermek operasyonu kolaylaştırsa da hata ve kötüye kullanım riskini artırır. Read-only, policy editor ve approver gibi roller görev ayrımı sağlar. Shared admin account kullanımı audit görünürlüğünü zayıflatır. Ayrıcalıklı hesaplar düzenli review ve MFA politikası altında tutulmalıdır.

RBAC

RBAC firewall yönetim yetkilerini kullanıcı rolüne göre sınırlar. Network operator yalnızca interface ve routing bilgilerini yönetebilirken security engineer policy üzerinde çalışabilir. Auditor sadece read-only erişime sahip olabilir. Rol tasarımı gerçek iş görevlerine göre yapılmalıdır. Çok geniş custom role'lar belirli aralıklarla yeniden incelenmelidir.

Read-Only

Read-only rol configuration ve log bilgilerini görüntüler ancak değişiklik yapamaz. Audit, monitoring ve troubleshooting ekipleri için uygundur. Kullanıcı production policy'yi yanlışlıkla değiştiremez. Hassas configuration export yetkisi gerekirse ayrıca sınırlandırılabilir. Read-only hesaplar da MFA ve kişisel kimlik ile kullanılmalıdır.

Policy Editor

Policy editor firewall rule taslağı oluşturabilir veya belirli policy alanlarını değiştirebilir. Ancak production commit veya approval yetkisi ayrı tutulabilir. Bu ayrım peer review sürecini destekler. Editor değişiklikleri kullanıcı hesabıyla loglanmalıdır. Yetki yalnızca gerekli firewall grupları veya zone'larla sınırlandırılabilir.

Approver

Approver hazırlanmış firewall değişikliğini güvenlik ve iş etkisi açısından onaylayan roldür. Kendi oluşturduğu değişikliği tek başına approve etmemesi tercih edilir. High-risk policy için birden fazla approver gerekebilir. Approval sonucu merkezi change record içinde tutulmalıdır. Approver'ların güncel güvenlik standardı konusunda eğitimli olması önemlidir.

Super Admin

Super admin tüm firewall configuration üzerinde geniş yetkiye sahiptir. Bu hesap sayısı minimum tutulmalıdır. Günlük operasyonlar için daha dar roller kullanılabilir. Super admin kullanımı özel alert ve session logging ile izlenebilir. Emergency account credential'ları güvenli kasa ve erişim prosedürüyle korunmalıdır.

Separation of Duties

Separation of duties kritik değişikliklerde tek kişinin request, implementation ve approval adımlarının tamamını kontrol etmesini önler. Bu yaklaşım hem kasıtlı kötüye kullanım hem de insan hatası riskini azaltır. Küçük ekiplerde tam ayrım zor olabilir, ancak en azından peer review uygulanabilir. Emergency change sonradan bağımsız review'a tabi tutulmalıdır. Süreç çok ağırlaştırılmadan risk seviyesine göre tasarlanmalıdır.

Shared Admin Account'lardan Kaçınmak

Shared admin account birden fazla kişinin aynı kullanıcı adıyla firewall yönetmesi durumudur. Bu yapı kimin hangi değişikliği yaptığını belirlemeyi zorlaştırır. Kişisel admin hesapları ve merkezi authentication tercih edilmelidir. Emergency shared account gerekiyorsa password vault üzerinden kontrollü checkout ve session recording kullanılabilir. Her kullanım sonrasında credential rotation yapılması değerlendirilebilir.

Firewall High Availability

Firewall kritik ağ geçiş noktası olduğu için tek cihaz arızası büyük hizmet kesintisine yol açabilir. High Availability iki veya daha fazla firewall'ın failover veya load sharing modeliyle çalışmasını sağlar. Configuration ve session synchronization tasarımın önemli parçalarıdır. HA kurulmuş olması otomatik olarak kesintisiz hizmet garantisi vermez. Failover ve split-brain senaryoları düzenli test edilmelidir.

Active-Passive

Active-Passive yapıda bir firewall aktif trafik işlerken ikinci cihaz yedek olarak bekler. Aktif cihaz arızalandığında passive üye görevi devralır. Configuration synchronization iki cihazın aynı policy'ye sahip olmasını sağlar. Session sync varsa mevcut bağlantıların bir kısmı kesintisiz devam edebilir. Failover süresi ve routing convergence uygulama gereksinimleriyle test edilmelidir.

Active-Active

Active-Active yapıda birden fazla firewall aynı anda trafik işleyebilir. Bu model kapasite avantajı sağlayabilir, ancak state ve routing tasarımı daha karmaşık olabilir. Asymmetric routing bazı firewall özelliklerini etkileyebilir. Session ownership ve synchronization davranışı platforma göre doğrulanmalıdır. Active-Active yalnızca daha fazla performans için seçilmemeli, operasyon ekibi tarafından yönetilebilir olmalıdır.

Configuration Synchronization

Configuration synchronization HA üyelerinin aynı security policy ve object bilgisine sahip olmasını sağlar. Sync hatası failover sonrasında beklenmeyen erişim davranışı oluşturabilir. Her policy değişikliğinden sonra sync status kontrol edilmelidir. Certificate ve bazı local ayarlar otomatik senkronize olmayabilir. HA runbook bu istisnaları açıkça içermelidir.

Session Synchronization

Session synchronization aktif bağlantı state'lerinin HA üyeleri arasında paylaşılmasını sağlar. Failover sırasında kullanıcı session'larının devam etmesine yardımcı olabilir. VPN veya bazı inspection session türleri farklı davranabilir. Sync link kapasitesi yoğun ortamlar için önemlidir. Failover testi gerçek uzun süreli application session'larla yapılmalıdır.

Failover

Failover aktif firewall'ın hizmet verememesi durumunda yedek cihazın görevi devralmasıdır. Interface, heartbeat veya system health kriterleri failover tetikleyebilir. Çok hassas eşikler gereksiz failover oluşturabilir. Çok gevşek eşikler ise gerçek arızayı geç fark edebilir. Planned failover testleri operasyon ekibinin prosedürü gerçekten uygulayabildiğini doğrular.

Split-Brain Riski

Split-brain iki HA üyesinin aynı anda kendisini aktif sanması durumudur. Duplicate IP, routing veya session sorunları oluşturabilir. Reliable heartbeat ve arbitration mekanizmaları bu riski azaltır. HA bağlantıları fiziksel olarak ayrılmış yollarla tasarlanabilir. Test sırasında heartbeat kaybı senaryosu özellikle kontrol edilmelidir.

HA Testleri

HA sistemi yalnızca dashboard üzerinde “green” görünmesiyle doğrulanmış sayılmaz. Planlı failover testleri gerçek trafik altında yapılmalıdır. Interface failure, power loss ve management failure gibi farklı senaryolar denenebilir. Application owner'lar session etkisini doğrulamalıdır. Test sonuçları DR ve business continuity kayıtlarına eklenmelidir.

Firewall Performansı Nasıl Optimize Edilir?

Firewall performansı yalnızca cihazın üzerinde yazan maksimum throughput değerine bağlı değildir. Rule complexity, session sayısı, DPI, TLS inspection, logging ve threat prevention özellikleri gerçek kapasiteyi etkiler. Tasarım sırasında normal ve peak trafik değerleri ölçülmelidir. Güvenlik özelliklerini kapatmak yerine doğru policy scope ve uygun donanım kapasitesi seçilmelidir. Performans değişiklikleri güvenlik etkisiyle birlikte değerlendirilmelidir.

Rule Count

Rule count çok yüksek olduğunda policy yönetimi ve bazı platformlarda evaluation maliyeti artabilir. Ancak az rule her zaman daha hızlı firewall anlamına gelmez. Cihazın policy compilation yöntemi önemlidir. Asıl hedef gereksiz duplicate ve stale rule'ları temizlemektir. Rule count KPI olarak izlenmeli, ancak tek başına performans kararı için kullanılmamalıdır.

Rule Complexity

Çok geniş object group, application filter ve karmaşık policy koşulları evaluation maliyetini etkileyebilir. Dynamic list ve user identity lookup da ek işlem gerektirebilir. Platform telemetry hangi policy'nin kaynak tükettiğini gösterebilir. Security requirement korunarak gereksiz koşullar sadeleştirilebilir. Değişiklik öncesi ve sonrası latency ölçümü yapılmalıdır.

Object Grouping

Object grouping rule sayısını azaltabilir ve policy yönetimini kolaylaştırabilir. Ancak binlerce öğe içeren dev gruplar değişiklik etkisini ve troubleshooting'i zorlaştırır. Gruplar işlevsel ve güvenlik açısından anlamlı boyutta tutulmalıdır. Kullanılmayan object'ler düzenli temizlenebilir. Group nesting derinliği mümkün olduğunca anlaşılır seviyede kalmalıdır.

DPI Cost

Deep Packet Inspection trafiği daha ayrıntılı analiz ettiği için firewall kaynak kullanımını artırabilir. IPS, application identification ve malware inspection profilleri farklı işlem maliyetlerine sahiptir. Kritik internet trafiğinde bu maliyet güvenlik açısından kabul edilebilir olabilir. Internal yüksek hacimli backup akışlarında farklı profile ihtiyaç duyulabilir. Inspection policy risk bazlı seçilmeli ve performans ölçümleriyle doğrulanmalıdır.

TLS Inspection

TLS inspection şifreli trafiğin güvenlik analizi için açılıp yeniden şifrelenmesini sağlayabilir. Bu işlem CPU ve latency üzerinde önemli etki oluşturabilir. Certificate trust ve privacy gereksinimleri de ayrıca yönetilmelidir. Hassas sağlık veya finans gibi kategoriler kurum politikasına göre inspection dışında tutulabilir. Kapasite planı gerçek şifreli trafik oranına göre yapılmalıdır.

Throughput

Throughput firewall'ın belirli sürede işleyebildiği veri miktarını ifade eder. Vendor datasheet üzerindeki değerler farklı test koşullarında ölçülmüş olabilir. Tüm security profile'lar açıkken gerçek kapasite daha düşük olabilir. Production trafik karışımıyla benzer test sonuçları tercih edilmelidir. Peak değer üzerine büyüme ve failover senaryosu için kapasite payı bırakılmalıdır.

Latency

Latency firewall'ın trafik yoluna eklediği gecikmedir. Normal packet filtering gecikmesi düşük olabilirken TLS inspection ve proxy özellikleri ek süre oluşturabilir. Gerçek zamanlı uygulamalar küçük gecikme değişimlerine hassas olabilir. Network monitoring change öncesi ve sonrası latency değerlerini karşılaştırmalıdır. Sorun kaynağını belirlemek için firewall, WAN ve application latency ayrı ölçülmelidir.

Capacity Planning

Capacity planning mevcut trafik ve gelecek büyüme beklentisine göre firewall kaynak ihtiyacını belirler. Throughput yanında concurrent session, new session rate, VPN kullanıcı sayısı ve logging kapasitesi dikkate alınmalıdır. HA durumunda tek cihazın tüm trafiği taşıyıp taşıyamayacağı kontrol edilmelidir. Cloud firewall servislerinde autoscaling ve maliyet modeli ayrıca değerlendirilir. Kapasite planı yılda en az birkaç kez gerçek ölçümlerle güncellenebilir.

Firewall Güvenliği İçin İzlenmesi Gereken KPI'lar

Firewall KPI'ları güvenlik politikasının ne kadar iyi yönetildiğini ölçmek için kullanılabilir. Total rule count tek başına yeterli değildir. Unused rule rate, expired access, overly permissive policy, unauthorized change ve access removal süresi gibi göstergeler daha anlamlıdır. KPI'lar yalnızca dashboard için değil iyileştirme hedefleri için seçilmelidir. Trend analizi ekiplerin rule base'in zamanla daha iyi mi yoksa daha kontrolsüz mü hâle geldiğini görmesini sağlar.

Total Rule Count

Total rule count firewall policy büyüklüğünü gösteren temel metriktir. Hızlı artış tekrar eden duplicate access veya zayıf object kullanımı göstergesi olabilir. Ancak büyük kurumda yüksek rule sayısı doğal olabilir. Trend ve business growth birlikte değerlendirilmelidir. Rule count azaltma hedefi gereksiz erişimleri temizlemeye odaklanmalıdır.

Unused Rule Rate

Unused rule rate belirli sürede kullanılmayan policy oranını gösterir. Yüksek oran stale veya gereksiz rule birikimine işaret edebilir. Seasonal ve DR rule'lar istatistikte ayrıca sınıflandırılmalıdır. Owner confirmation ile gerçek unused erişimler belirlenebilir. Hedef yalnızca sayıyı düşürmek değil güvenlik alanını daraltmaktır.

Zero-Hit Rules

Zero-hit rule sayısı düzenli cleanup programı için iyi başlangıç metriğidir. Son hit tarihi ve counter reset zamanı dikkate alınmalıdır. Kritik emergency rule'lar ayrı etiketlenebilir. Belirli süreyi aşan sıfır hit policy'ler otomatik recertification'a gönderilebilir. Disable-before-delete yöntemi güvenli temizlik sağlar.

Expired Rules

Expired rule sayısı temporary access yönetiminin kalitesini gösterir. Süresi geçmiş ama hâlâ aktif policy ciddi process problemi oluşturur. Hedef aktif expired rule sayısını sıfıra yaklaştırmak olmalıdır. Automation bu kuralları süre sonunda otomatik disable edebilir. Dashboard owner ve gecikme gününü birlikte gösterebilir.

Overly Permissive Rules

Overly permissive rule Any source, Any destination, geniş port aralığı veya gereksiz kullanıcı grubu içerebilir. Otomatik risk scoring bu policy'leri önceliklendirebilir. Her geniş rule hatalı olmayabilir, ancak güçlü business justification ve ek kontroller gerektirir. High-risk list düzenli security review'a alınmalıdır. Azalan trend least privilege programının başarı göstergesi olabilir.

Change Failure Rate

Change failure rate firewall değişikliklerinin ne kadarının rollback, incident veya beklenmeyen problem oluşturduğunu gösterir. Yüksek oran test ve peer review süreçlerinde eksiklik olduğunu gösterebilir. Hataların türü ayrıca sınıflandırılmalıdır. Syntax, rule order ve missing dependency gibi tekrar eden nedenler otomasyona dönüştürülebilir. Amaç ekipleri cezalandırmak değil süreci iyileştirmektir.

Unauthorized Change

Unauthorized change onaylı süreç dışında yapılan firewall konfigürasyon değişikliğidir. Central manager, Git drift detection veya admin audit logları bu olayı tespit edebilir. Emergency change yetkili prosedürle yapıldıysa sonradan normal kayda alınmalıdır. Gerçek yetkisiz değişiklik güvenlik incident'i olarak değerlendirilmelidir. Admin account ve credential güvenliği ayrıca incelenmelidir.

Mean Time to Approve

Mean Time to Approve access request'in oluşturulmasından onaylanmasına kadar geçen ortalama süredir. Çok uzun süre business ekiplerini bypass yollarına yönlendirebilir. Çok hızlı ama kontrolsüz approval ise güvenlik riskini artırır. Risk bazlı otomasyon standart erişimleri hızlandırabilir. KPI security quality metric'leriyle birlikte değerlendirilmelidir.

Mean Time to Remove Access

Mean Time to Remove Access artık gerekmeyen yetkinin ne kadar hızlı kapatıldığını gösterir. Çalışan rol değişikliği, proje bitişi veya incident sonrasında bu süre kritik olabilir. Automation ve identity integration erişim kaldırmayı hızlandırır. Çok uzun süre stale privilege oluşturur. KPI özellikle privileged ve temporary access için ayrı izlenebilir.

Compliance ve Firewall Kuralları

Firewall kuralları birçok bilgi güvenliği ve veri koruma çerçevesinde erişim kontrolü, network segmentation, change management ve logging gereksinimleriyle ilişkilidir. ISO 27001, PCI DSS ve KVKK kapsamında doğrudan veya dolaylı teknik ve idari kontroller bulunabilir. Compliance hedefi yalnızca denetim tarihinden önce rule temizliği yapmak olmamalıdır. Sürekli owner, review, approval ve log kayıtları tutulduğunda audit hazırlığı doğal süreç hâline gelir. Kurumun hangi yükümlülüğe tabi olduğu hukuk ve compliance ekipleriyle birlikte değerlendirilmelidir.

ISO 27001

ISO 27001 bilgi güvenliği yönetim sistemi kapsamında erişim kontrolü, network security ve değişiklik yönetimiyle ilişkili kontroller içerir. Firewall policy bu kontrollerin teknik uygulamalarından biri olabilir. Rule owner, approval ve periodic review kayıtları yönetim sistemine kanıt sağlar. Risk değerlendirmesi hangi network kontrollerinin gerekli olduğunu belirlemelidir. Sertifika almak tek başına güvenli firewall tasarımı anlamına gelmez.

PCI DSS

PCI DSS kart verisi ortamlarında network security control ve segmentasyon konularına güçlü vurgu yapar. Kart verisi kapsamını azaltmak için network segmentation kullanılabilir. Firewall ve benzeri security control'ların düzenli review edilmesi gerekir. Erişim yalnızca business need temelinde sınırlandırılmalıdır. Uygulanacak spesifik gereksinimler kullanılan PCI DSS sürümüne göre resmi standart üzerinden doğrulanmalıdır.

KVKK

KVKK kişisel verilerin korunması için gerekli teknik ve idari tedbirlerin alınmasını gerektiren bir yasal çerçevedir. Firewall ve erişim kontrolü kişisel veriye erişen sistemlerin korunmasına katkı sağlayabilir. Hassas veri işleyen ağların segmentasyonu yetkisiz erişim riskini azaltır. Loglama yapılırken kişisel veri içeren kayıtların erişim ve retention politikası ayrıca değerlendirilmelidir. Hukuki yorum ve yükümlülükler kurumun hukuk uzmanlarıyla doğrulanmalıdır.

Audit Trail

Audit trail firewall rule'un oluşturulmasından kaldırılmasına kadar değişiklik geçmişini gösterir. Requestor, approver, implementation ve review bilgileri kaydedilebilir. Git ve ticket sistemi birlikte kullanıldığında güçlü izlenebilirlik sağlar. Admin action logları da bu zincirin parçasıdır. Kayıtların yetkisiz değişiklikten korunması gerekir.

Periodic Access Review

Periodic access review mevcut firewall erişimlerinin hâlâ gerekli olup olmadığını düzenli olarak doğrular. Kritik policy'ler daha sık incelenebilir. Owner onayı ve hit count verisi birlikte kullanılabilir. Gereksiz rule'lar kontrollü şekilde kaldırılır. Review sonucu denetim kanıtı olarak saklanmalıdır.

Change Control

Change control firewall değişikliklerinin onay, test, uygulama ve doğrulama adımlarını standardize eder. Yetkisiz hızlı değişikliklerin önüne geçer. Emergency süreç de ayrı kayıt ve post-review içermelidir. Her değişiklik geri alma planına sahip olmalıdır. Change kontrolünün amacı operasyonu yavaşlatmak değil riski görünür ve yönetilebilir hâle getirmektir.

Evidence Collection

Evidence collection audit sırasında gerekli policy, approval, log ve review kayıtlarının düzenli toplanmasını sağlar. Manuel ekran görüntüsü yerine sistemlerden otomatik rapor almak daha sürdürülebilir olabilir. Git commit, pull request ve deployment logları teknik kanıt sunar. Evidence erişimi sadece yetkili kişilerle sınırlandırılmalıdır. Saklama süresi compliance gereksinimine göre belirlenmelidir.

OT ve Endüstriyel Ağlarda Firewall Kuralları

OT ve endüstriyel ağlarda firewall tasarımı üretim sürekliliği, safety ve legacy sistem kısıtları nedeniyle standart IT ağlarından farklı önceliklere sahip olabilir. IT ve OT segmentasyonu temel güvenlik kontrolüdür. Endüstriyel protokoller mümkün olduğunda allowlist yaklaşımıyla sınırlandırılmalıdır. Vendor remote access sürekli açık VPN yerine onaylı ve süreli erişim üzerinden sağlanabilir. Her değişiklik üretim etkisi açısından OT mühendisleriyle birlikte planlanmalıdır.

IT/OT Segmentation

IT ve OT ağlarının doğrudan ve geniş erişimle bağlı olması risklidir. Araya firewall ve uygun DMZ katmanı yerleştirilebilir. Yalnızca gerekli data historian, management veya update akışları açılır. Kullanıcı ofis ağından PLC veya controller sistemlerine doğrudan erişim verilmemelidir. Segment sınırları düzenli olarak network flow analiziyle doğrulanmalıdır.

Purdue Model

Purdue Model endüstriyel ağları fonksiyonel seviyelere ayırmak için kullanılan yaygın referans modellerden biridir. Enterprise, site operations ve control seviyeleri arasında güvenlik sınırları oluşturulabilir. Model birebir uygulanmak zorunda değildir, ancak zone ve conduit tasarımına yardımcı olur. Firewall rule'ları seviyeler arası izinli protokolleri açıkça tanımlar. Gerçek mimari ve üretim ihtiyaçları her tesis için ayrıca değerlendirilmelidir.

Legacy Protocols

OT ortamlarında eski ve kimlik doğrulaması zayıf protokoller bulunabilir. Bu protokolleri hemen değiştirmek üretim sistemi nedeniyle mümkün olmayabilir. Network segmentation ve source allowlisting ek koruma sağlar. Protocol-aware firewall veya IDS görünürlüğü artırabilir. Legacy sistem modernize edilene kadar compensating control ve monitoring uygulanmalıdır.

Industrial Protocol Allowlisting

Industrial protocol allowlisting yalnızca gerekli controller, engineering workstation ve server arasındaki belirli protokollere izin verir. Tüm OT subnet'ler arasında geniş erişim verilmez. Modbus veya başka endüstriyel protokollerin hangi direction ve function kullanımına ihtiyaç duyduğu incelenebilir. Protocol inspection destekleniyorsa uygun profile uygulanabilir. Policy change mutlaka production engineering ekibiyle test edilmelidir.

Vendor Remote Access

Vendor remote access bakım ve destek için gerekli olabilir, ancak sürekli açık bırakılmamalıdır. Kullanıcı kimliği, MFA, approval ve time limit uygulanabilir. Vendor yalnızca destek verdiği belirli sisteme erişebilmelidir. Session recording kritik işlemlerde değerlidir. İş tamamlandığında erişim otomatik olarak kaldırılmalıdır.

Jump Server

OT jump server vendor veya internal administrator erişimini kontrollü noktadan geçirir. Doğrudan laptop'tan PLC network'üne bağlantı azaltılır. Jump server hardened ve düzenli patch yönetimi altında tutulmalıdır. Dosya transferi ve clipboard kullanımı gerekiyorsa ayrıca kontrol edilebilir. Session logları OT incident response için merkezi olarak saklanmalıdır.

Emergency Access

Üretim kesintisinde emergency access gerekebilir. Ancak bu erişim bile kimlik, log ve süre sınırı olmadan verilmemelidir. Break-glass mekanizması önceden test edilmelidir. Emergency rule normal operasyon sonunda derhal kapatılmalıdır. Post-incident review sırasında açılan tüm geçici firewall erişimleri tek tek kontrol edilmelidir.

Firewall Kurallarında En Sık Yapılan Hatalar

Firewall sorunlarının büyük bölümü teknoloji eksikliğinden değil süreç ve politika yönetimindeki hatalardan kaynaklanır. Any-to-Any Allow, default allow, yanlış rule order, unutulan temporary rule ve eksik logging en sık gördüğüm örnekler arasındadır. IPv6'yı veya egress trafiğini hiç değerlendirmemek de önemli görünürlük boşluğu oluşturur. Rule owner ve ticket bilgisinin bulunmaması ileride erişimin neden gerekli olduğunu anlamayı zorlaştırır. Düzenli review, otomatik analiz ve iyi change management bu hataların çoğunu ciddi ölçüde azaltabilir.

Any-to-Any Allow Kullanmak

Any-to-Any Allow source, destination ve çoğu zaman service kapsamını gereğinden fazla genişletir. Sorun giderme için kullanılmış olsa bile süre sonunda kaldırılmalıdır. Gerçek gerekli bağlantılar log üzerinden çıkarılabilir. Ardından minimum source ve port içeren ayrı rule'lar oluşturulur. Permit-all policy kalıcı çözüm olarak kabul edilmemelidir.

Default Allow Kullanmak

Default allow açıkça engellenmeyen her bağlantının geçmesine neden olabilir. Yeni sistemler farkında olmadan geniş erişim kazanır. Güvenli yaklaşım default deny ve explicit exception modelidir. Mevcut default allow ortamdan geçiş önce trafik analizi gerektirir. Aşamalı migration production kesintisi riskini azaltır.

Rule Order'ı Yanlış Tasarlamak

Yanlış rule order gerekli deny veya allow policy'nin çalışmamasına neden olabilir. Genel rule özel rule'un üstünde bulunuyorsa shadow oluşabilir. Değişiklik öncesi policy simulation yapılmalıdır. Reviewer yeni kuralın üst ve alt komşularını kontrol etmelidir. Hit count değişiklik sonrası doğrulama için kullanılabilir.

Shadow Rule'ları Görmezden Gelmek

Shadow rule policy set içinde gerçek davranış ile tasarım niyeti arasındaki farkı gösterir. Sıfır hit alan deny rule kritik güvenlik kontrolünün aslında çalışmadığı anlamına gelebilir. Otomatik analyzer düzenli rapor üretebilir. Her shadow sonucu owner ve business purpose ile değerlendirilmelidir. Gereksiz policy kaldırılmalı veya doğru sıraya taşınmalıdır.

Geçici Rule'ları Kalıcı Bırakmak

Temporary rule'lar expiration olmadan oluşturulduğunda kalıcı hâle gelme eğilimindedir. Bakım tamamlandıktan sonra kimse erişimi kapatmayı hatırlamayabilir. Start, expiry ve owner alanları zorunlu tutulmalıdır. Auto-disable insan hatasını azaltır. Aylık review'da aktif temporary access listesi incelenmelidir.

Egress Trafiğini Kontrol Etmemek

İç cihazların internete sınırsız çıkabilmesi malware ve data exfiltration riskini artırır. Özellikle server zone için outbound allowlist uygulanabilir. DNS ve SMTP çıkışları merkezi servislerle sınırlandırılabilir. Proxy kullanımı web erişimini kontrol etmeyi kolaylaştırır. Deny logları beklenmeyen uygulama davranışlarını bulmaya yardımcı olur.

IPv6'yı Unutmak

IPv4 policy'si düzgün olsa bile IPv6 kontrol edilmezse alternatif erişim yolu oluşabilir. Dual-stack cihazlar otomatik IPv6 bağlantısı kullanabilir. Firewall, SIEM ve vulnerability scanner IPv6'yı desteklemelidir. ICMPv6 doğru şekilde izinli ve kontrollü olmalıdır. Kullanılmayan IPv6 bile gerçek trafik ölçülmeden “yok” kabul edilmemelidir.

Rule Owner Belirlememek

Owner bilgisi olmayan firewall rule zamanla orphaned policy hâline gelir. Güvenlik ekibi kuralın hâlâ gerekli olup olmadığını doğrulayamaz. Her yeni rule bir business veya application owner'a bağlanmalıdır. Organizasyon değişikliklerinde owner güncellenmelidir. Sahipsiz erişimler risk bazlı temizlik sürecine alınmalıdır.

Açıklama ve Ticket Eklememek

Rule description ve ticket olmadan geçmiş değişikliğin neden yapıldığını anlamak zorlaşır. IP ve port bilgisi business purpose'ü açıklamaz. Her policy isim, açıklama ve change reference taşımalıdır. Bu metadata audit ve troubleshooting süresini azaltır. Otomasyon eksik description içeren yeni rule'u reddedebilir.

Loglama Yapmamak

Logging olmayan policy incident response ve kullanım analizi açısından kör nokta oluşturur. En azından kritik allow ve deny rule'larda kayıt tutulmalıdır. Log hacmi nedeniyle tüm traffic ayrıntılı kaydedilemiyorsa risk bazlı seçim yapılabilir. Central log collection tercih edilmelidir. Rule hit count tek başına user ve application bağlamı sağlamaz.

Kullanılmayan Rule'ları Silmemek

Unused rule'lar rule base'i büyütür ve gereksiz erişim alanı oluşturabilir. Zero-hit ve last-hit raporları düzenli review için kullanılabilir. Owner confirmation olmadan doğrudan silme yapılmamalıdır. Disable-before-delete daha güvenli yöntemdir. Cleanup süreci sürekli yapılırsa büyük yıllık temizlik projelerine ihtiyaç azalır.

Firewall Yönetim Arayüzünü Internet'e Açmak

Firewall management interface'i doğrudan internete açmak yüksek riskli bir uygulamadır. Yönetim erişimi VPN, ZTNA veya trusted jump host üzerinden sağlanmalıdır. MFA ve source restriction kullanılmalıdır. Public exposure zorunlu istisna ise çok dar source allowlist ve monitoring gerektirir. Login failure ve admin action event'leri SIEM'e aktarılmalıdır.

VLAN'ı Güvenlik Kontrolü Sanmak

VLAN Layer 2 segmentasyon sağlar, ancak inter-VLAN routing açıldığında güvenlik policy'si ayrıca gerekir. Tüm VLAN'lar birbirine route ediliyorsa gerçek isolation yoktur. ACL veya firewall kontrolü kullanılarak erişim sınırlandırılmalıdır. Kritik segmentler için stateful ve logged policy tercih edilebilir. VLAN güvenlik mimarisinin yalnızca yapı taşıdır.

IP Adresine Körü Körüne Güvenmek

IP adresi tek başına kullanıcı veya cihaz kimliğini güvenilir biçimde kanıtlamaz. DHCP, NAT ve shared systems bu ilişkiyi değiştirebilir. Identity-aware firewall ve NAC ek bağlam sağlar. Kritik erişimlerde kullanıcı, cihaz posture ve source network birlikte değerlendirilmelidir. IP allowlist yararlı kontrol olabilir, ancak tek güvenlik faktörü olmamalıdır.

Firewall Rule Tasarım Checklist'i

Firewall rule tasarım checklist'i değişiklik uygulanmadan önce temel güvenlik sorularının unutulmamasını sağlar. Source ve destination kapsamı, minimum port, application, user, logging, owner ve expiration mutlaka değerlendirilmelidir. Test ve rollback planı olmadan kritik production rule uygulanmamalıdır. Checklist manuel form, ticket template veya CI/CD policy check olarak kullanılabilir. En iyi sonuç, kontrol listesinin yalnızca doldurulan belge değil gerçek approval kriteri olarak uygulanmasıyla elde edilir.

Source Gerekli Kadar Dar mı?

Kaynağın bütün subnet yerine belirli host veya grup olarak tanımlanıp tanımlanamayacağı kontrol edilmelidir. Dinamik user access için identity group daha uygun olabilir. Any source kullanımı güçlü business justification gerektirir. Source object owner ve kapsam bilgisi anlaşılır olmalıdır. Gereksiz kaynaklar policy'den çıkarılmalıdır.

Destination Gerekli Kadar Dar mı?

Hedef yalnızca gerçek uygulama sunucularını kapsamalıdır. Tüm data center subnet'ini açmak yerine belirli service object kullanılabilir. FQDN veya cloud tag dinamik hedefler için değerlendirilebilir. Hedef grup değişiklikleri impact review gerektirir. Kullanılmayan server object'leri periyodik temizlenmelidir.

Portlar Minimum mu?

Yalnızca uygulamanın gerçek kullandığı portlara izin verilmelidir. Geniş port aralığı vendor önerisi olsa bile doğrulanmalıdır. TCP ve UDP gereksinimi ayrı kontrol edilmelidir. Troubleshooting sırasında açılan ekstra portlar kapanmalıdır. Application owner port listesini onaylamalıdır.

Application Belirlenmiş mi?

NGFW kullanılıyorsa portun yanında gerçek uygulama kimliği tanımlanabilir. Unknown application ile çalışan kritik bağlantılar incelenmelidir. Uygulama default port seçeneği gerekiyorsa kullanılabilir. SaaS erişimleri user group ile sınırlandırılabilir. Application signature değişiklikleri monitoring kapsamında izlenmelidir.

User/Group Belirlenmiş mi?

Kullanıcı erişiminde sadece source IP yerine user veya group kullanılabiliyorsa tercih edilmelidir. Rol değişiklikleri merkezi identity sistemi üzerinden policy'ye yansıyabilir. Administrator grupları normal kullanıcı gruplarından ayrılmalıdır. Shared account'lar policy visibility'yi azaltır. Group membership düzenli access review kapsamında kontrol edilmelidir.

Default Deny Var mı?

Policy segmentinde eşleşmeyen trafiğin varsayılan olarak engellendiği doğrulanmalıdır. Implicit deny cihaz davranışı dokümante edilmelidir. Explicit final deny kullanılıyorsa doğru log politikası uygulanmalıdır. Yeni zone oluşturulduğunda default allow oluşmadığı kontrol edilmelidir. Testte beklenmeyen source ve portların gerçekten engellendiği görülmelidir.

Logging Aktif mi?

Kritik allow ve deny rule'larda logging bulunmalıdır. Logun yalnızca firewall üzerinde değil merkezi SIEM'de oluştuğu doğrulanmalıdır. Rule ID ve user bilgisi gibi gerekli alanlar kayıtta bulunmalıdır. Çok yüksek volume için rate limiting değerlendirilebilir. Logging kararı security monitoring ihtiyacına göre verilmelidir.

Rule Owner Var mı?

Her rule'un iş ihtiyacını doğrulayacak bir owner'ı olmalıdır. Sadece network engineer owner olarak görünmemelidir. Application veya business sorumlusu tercih edilir. Owner ayrıldığında yeni sorumlu atanmalıdır. Orphaned rule'lar otomatik raporlanabilir.

Business Justification Var mı?

Business justification erişimin neden gerekli olduğunu açıkça anlatmalıdır. “Uygulama için” gibi genel ifadeler yeterli değildir. Hangi iş akışının hangi bağlantıyı kullandığı belirtilmelidir. Bu açıklama recertification sırasında erişim kararını kolaylaştırır. Gerekçesi doğrulanamayan rule oluşturulmamalıdır.

Expiration Date Gerekli mi?

Bakım, proje veya vendor erişimi için expiration date kullanılmalıdır. Kalıcı yetki gerçekten gerekli mi ayrıca sorgulanmalıdır. Temporary rule otomatik disable olabilir. Süre uzatımı yeni approval gerektirebilir. Expiration olmayan privileged access daha sık review edilmelidir.

Test Edildi mi?

Policy simulation veya lab testi mümkünse production öncesinde yapılmalıdır. Expected allow ve deny senaryoları hazırlanmalıdır. Rule order ve NAT etkisi kontrol edilmelidir. Deployment sonrası gerçek trafik testi de gereklidir. Test sonuçları change record'a eklenmelidir.

Rollback Planı Var mı?

Kritik değişiklik uygulanmadan önce geri alma adımları bilinmelidir. Pre-change backup alınmalıdır. Hangi durumda rollback tetikleneceği açıkça belirlenmelidir. Geri dönüş sonrası hangi servislerin test edileceği planlanmalıdır. Otomatik deployment kullanılıyorsa revert süreci düzenli olarak test edilmelidir.

Uçtan Uca Güvenli Firewall ve Erişim Denetimi Nasıl Kurulur?

Uçtan uca güvenli firewall ve erişim denetimi yalnızca cihaz üzerinde rule yazmakla kurulmaz. Network ve asset inventory, data flow, trust zone, least privilege, identity, NAC, egress filtering, logging ve change management birlikte tasarlanmalıdır. Ardından otomasyon ve policy-as-code yaklaşımları tekrar eden kontrolleri standartlaştırabilir. Ağ Güvenlik Duvarı Kuralları ve Erişim Denetimi sürecinin başarısı teknik ekiplerin iş birimleriyle aynı erişim amacını paylaşmasına bağlıdır. Aşağıdaki adımlar küçük ağlardan geniş kurumsal yapılara kadar uygulanabilecek pratik bir yol haritası sunar.

1. Network ve Asset Envanteri Çıkarın

İlk adım hangi network, subnet, server, cloud workload ve cihazların bulunduğunu bilmektir. Envanter eksikse hangi sistemi koruduğunuzu tam olarak göremezsiniz. IP address management ve CMDB verileri birleştirilebilir. Sahipsiz asset'ler ayrıca işaretlenmelidir. Firewall object'leri gerçek asset envanteriyle düzenli olarak karşılaştırılmalıdır.

2. Data Flow Haritası Oluşturun

Uygulamaların hangi kaynaklardan hangi hedeflere hangi portlarla bağlandığını çıkarın. Network log ve packet capture mevcut akışları görmeye yardımcı olur. Ancak sadece gözlenen trafik otomatik olarak meşru kabul edilmemelidir. Application owner business gereksinimini doğrulamalıdır. Data flow haritası firewall rule tasarımının temel girdisi olmalıdır.

3. Trust Zone'ları Belirleyin

Kullanıcı, server, management, guest, IoT ve production gibi güvenlik zone'larını tanımlayın. Her zone'un güven seviyesi ve erişim politikası farklı olabilir. Aynı zone içinde bulunan sistemlerin gerçekten benzer risk profiline sahip olduğundan emin olun. Kritik uygulamalar için ayrı segment gerekebilir. Zone matrisi hangi alanların birbirine erişebileceğini yüksek seviyede göstermelidir.

4. Default-Deny Politikasını Tanımlayın

Yeni zone ve firewall policy'lerinde varsayılan olarak erişimi kapalı tutun. Sadece doğrulanmış bağlantıları allow exception olarak ekleyin. Mevcut açık ağda geçiş yapılıyorsa önce trafik analizi ve staged enforcement kullanın. Deny loglarını izleyerek eksik business flow'ları belirleyin. Default deny politikasını organizasyon standardı hâline getirin.

5. Gerekli Trafikleri Belirleyin

Her application owner ile gerekli source, destination, protocol ve port listesini doğrulayın. Vendor dokümanını tek kaynak olarak kabul etmek yerine gerçek trafikle karşılaştırın. Kullanılmayan geniş port önerilerini daraltın. DNS, NTP ve update gibi bağımlılıkları unutmayın. Her akış business purpose ve owner bilgisiyle kaydedilmelidir.

6. Least-Privilege Rules Oluşturun

Source, destination, service, application ve user alanlarını minimum kapsamda tanımlayın. Any kullanımı istisna olmalıdır. Temporary access için expiration ekleyin. Rule name ve description standardını uygulayın. Yeni policy'yi mevcut rule base ile overlap ve shadow açısından kontrol edin.

7. Kullanıcı ve Device Identity Entegrasyonu Yapın

IP tabanlı policy'nin yeterli olmadığı erişimlerde identity integration kullanın. Active Directory, LDAP, RADIUS veya modern identity provider sistemleri firewall ve NAC ile entegre edilebilir. Managed device ve posture bilgisi riskli erişimlerde ek koşul olabilir. MFA özellikle administrator ve remote access için zorunlu tutulabilir. Identity mapping doğruluğu sürekli izlenmelidir.

8. Network Segmentation Kurun

Kullanıcı, server, management, IoT ve guest ağlarını birbirinden ayırın. VLAN oluşturmakla yetinmeyip segmentler arasında firewall veya ACL kontrolü uygulayın. Kritik application flow'ları ayrıca microsegmentation ile sınırlayabilirsiniz. East-West traffic logging etkinleştirin. Segment izolasyonunu negatif testlerle doğrulayın.

9. NAC/ZTNA Gereksinimini Belirleyin

Kullanıcı ve cihazların ağa nasıl bağlandığını analiz edin. BYOD, IoT ve remote workforce yoğun ise NAC ve ZTNA önemli avantaj sağlayabilir. 802.1X ile device authentication, ZTNA ile application-level remote access uygulanabilir. Her teknoloji gerçek kullanım senaryosuna göre seçilmelidir. Firewall ile integration noktaları proje başında planlanmalıdır.

10. Egress Filtering Uygulayın

Server ve kullanıcı network'lerinin internet çıkışını aynı policy ile yönetmeyin. Server'lar yalnızca gerekli DNS, update ve API hedeflerine erişebilmelidir. Direct DNS ve SMTP çıkışlarını kontrol edin. Proxy veya application-aware firewall kullanın. Beklenmeyen outbound deny event'lerini SIEM üzerinde izleyin.

11. Logging ve SIEM Entegrasyonu Kurun

Firewall allow, deny, admin action ve threat loglarını merkezi sisteme gönderin. Timestamp ve user mapping kalitesini doğrulayın. SIEM üzerinde port scan, suspicious egress ve lateral movement use case'leri oluşturun. Log source health alarmı kullanın. Retention süresini incident response ve compliance ihtiyacına göre belirleyin.

12. Rule Request ve Approval Workflow Oluşturun

Yeni rule taleplerini standart form üzerinden toplayın. Business justification, source, destination, port, owner ve duration alanlarını zorunlu hâle getirin. Risk seviyesine göre approval akışı belirleyin. Self-service süreçlerde bile policy validation kullanın. Tüm approval kayıtlarını audit trail olarak saklayın.

13. Pre-Deployment Test Yapın

Policy simulation ve shadow analysis çalıştırın. Expected allow ve expected deny testlerini hazırlayın. NAT ve routing etkisini kontrol edin. Kritik değişikliği staging veya lab ortamında deneyin. Test başarısızsa production deployment yapılmamalıdır.

14. Production'a Deploy Edin

Onaylı değişikliği planlı change süreciyle production'a uygulayın. Mümkünse otomasyon veya merkezi manager kullanın. Uygulama sırasında plansız ek rule eklemeyin. Configuration backup hazır olmalıdır. Deployment logunu ticket ve Git revision ile ilişkilendirin.

15. Post-Deployment Verification Yapın

Gerçek uygulama trafiğinin doğru çalıştığını test edin. Negatif erişim senaryolarını da kontrol edin. Firewall logunda doğru rule ID eşleşmesini doğrulayın. Performance ve error değerlerini izleyin. Sorun varsa belirlenmiş rollback prosedürünü uygulayın.

16. Rule Hit Count'ları İzleyin

Yeni ve mevcut rule'ların kullanımını hit count ve last-hit verileriyle takip edin. Beklenmeyen yüksek hit geniş kapsam göstergesi olabilir. Uzun süre sıfır hit alan rule'ları review listesine alın. Counter reset tarihini dikkate alın. Kullanım verisini owner recertification ekranına ekleyin.

17. Expiration ve Recertification Uygulayın

Temporary rule'ları expiration ile otomatik yönetin. Permanent rule'ları belirli aralıklarla owner onayına gönderin. Expired veya orphaned erişimleri otomatik raporlayın. Disable-before-delete kullanın. Audit evidence olarak review sonuçlarını saklayın.

18. Otomasyon ve Policy-as-Code'a Geçin

Tekrarlayan firewall değişikliklerini Git ve CI/CD sürecine taşıyın. Syntax, duplicate, shadow ve security standard testlerini otomatikleştirin. Pull request review ile production öncesi görünürlük sağlayın. Automated deployment ve rollback oluşturun. Küçük ve kontrollü use case ile başlayıp kapsamı aşamalı büyütün.

19. Düzenli Audit Yapın

Rule owner, broad access, public exposure ve administrator yetkilerini düzenli inceleyin. IPv6 ve cloud policy'leri audit kapsamına ekleyin. Configuration drift ve unauthorized change kontrolleri yapın. Findings için owner ve due date belirleyin. Audit sonucunu yalnızca raporlamak yerine cleanup ve policy improvement sürecine bağlayın.

20. Sürekli Optimize Edin

Firewall policy hiçbir zaman tamamen bitmiş bir çalışma değildir. Uygulamalar, kullanıcılar ve network mimarisi değiştikçe erişim ihtiyacı da değişir. KPI ve incident verilerinden hangi süreçlerin iyileştirilebileceğini belirleyin. Gereksiz rule'ları temizleyin ve otomasyon kapsamını artırın. Güvenliği ve operasyon hızını birlikte geliştiren sürdürülebilir süreç hedefleyin.

Ağ Güvenliği İçin En İyi Programlama Dili Hangisidir?

Ağ güvenliği için tek bir “en iyi” programlama dili yoktur. Kullanacağınız dil hedeflediğiniz işe göre değişir. Network automation ve log analizi için Python oldukça güçlü başlangıç noktasıdır, yüksek performanslı network servislerinde Go değerlidir, Windows otomasyonunda PowerShell sık kullanılır. Infrastructure as Code için Terraform ve HCL bilgisi doğrudan işin parçası hâline gelebilir. Programlama bilgisinden önce TCP/IP, routing, DNS, firewall ve Linux temellerini güçlü şekilde öğrenmek uzun vadede daha fazla fayda sağlar.

Python

Python okunabilir syntax'ı ve geniş kütüphane ekosistemi nedeniyle network automation çalışmalarında sık tercih edilir. Firewall API'lerine bağlanmak, rule inventory çıkarmak veya log analizi yapmak için uygundur. Küçük script'lerden büyük otomasyon platformlarına kadar farklı ölçekte kullanılabilir. JSON ve YAML veri işlemleri kolaydır. Ağ güvenliği alanına yeni başlayan yazılımcılar için pratik öğrenme yolu sunar.

Network automation

Python network cihazlarından konfigürasyon toplamak ve değişiklik uygulamak için kullanılabilir. API veya SSH tabanlı otomasyon yapılabilir. Çok sayıda firewall object'ini tek tek GUI üzerinden yönetme ihtiyacı azalır. Script'in idempotent ve hata durumunda güvenli davranması önemlidir. Production otomasyonu mutlaka test ve version control sürecine bağlanmalıdır.

API integration

Modern firewall platformları REST API üzerinden policy ve log bilgisi sunabilir. Python requests benzeri kütüphanelerle bu servislerle iletişim kurulabilir. Kimlik bilgileri kod içinde düz metin tutulmamalıdır. Secret management için güvenli sistemler kullanılabilir. Bu konuda ayrı secret management yaklaşımını incelemek isterseniz https://www.diyarbakiryazilim.com.tr/posts/gizli-veri-secret-yonetimi-hashicorp-vault-ve-aws-secrets adresindeki içeriğe de göz atabilirsiniz.

Firewall rule analysis

Python firewall rule export dosyalarını analiz etmek için kullanılabilir. Duplicate, zero-hit veya geniş network object'lerini otomatik tespit eden araçlar geliştirilebilir. IP subnet karşılaştırması için standart ve üçüncü taraf kütüphaneler kullanılabilir. Sonuçlar HTML veya CSV raporuna dönüştürülebilir. Böyle bir proje hem network hem yazılım bilgisini geliştirmek için iyi bir çalışma alanıdır.

Log analysis

Firewall logları Python ile parse edilip belirli pattern'ler için analiz edilebilir. En çok deny alan source IP veya sıra dışı destination port gibi raporlar üretilebilir. Büyük veri hacminde streaming veya data processing araçları gerekebilir. Timestamp ve timezone işlemleri doğru yapılmalıdır. Küçük lab loglarıyla başlamak analiz mantığını öğrenmek için yeterlidir.

Go

Go network servisleri, CLI araçları ve yüksek eşzamanlılık gerektiren uygulamalar için güçlü seçenektir. Tek binary üretmesi deployment açısından kolaylık sağlar. Cloud-native ve Kubernetes ekosisteminde yaygın kullanılır. Network security agent veya hızlı log processor geliştirmek isteyenler için değerlidir. İlk dil olarak zorunlu değildir, ancak Python sonrası iyi tamamlayıcı olabilir.

Bash

Bash Linux sistemlerde hızlı otomasyon ve komut zincirleri için kullanışlıdır. nftables veya iptables çıktısını işlemek, dosya ve log görevleri yapmak için yeterli olabilir. Büyük programlarda hata yönetimi ve bakım zorlaşabilir. Karmaşık logic büyüdüğünde Python gibi daha yapılandırılmış bir dil tercih edilebilir. Yine de ağ güvenliği çalışan herkesin temel shell bilgisine sahip olması faydalıdır.

PowerShell

PowerShell Windows ve Microsoft tabanlı altyapılarda güçlü otomasyon yetenekleri sunar. Active Directory, Windows Firewall ve sistem yönetim görevleri için yaygın kullanılır. Object-based pipeline veri işlemeyi kolaylaştırır. API çağrıları ve JSON işlemleri de yapılabilir. Windows ağı yoğun kurumlarda PowerShell bilgisi doğrudan operasyon avantajı sağlar.

Terraform/HCL

Terraform ve HCL özellikle cloud firewall, security group ve network policy yönetiminde önemli araçlardır. Security configuration kod olarak tutulabilir ve pull request üzerinden incelenebilir. Plan çıktısı production öncesi değişiklik etkisini gösterir. Reusable module kullanımı ortak güvenlik standardı oluşturur. State ve secret yönetimi güvenli biçimde tasarlanmalıdır.

Programlama Dilinden Daha Önemli Olan Ağ ve Güvenlik Temelleri

Programlama dili öğrenmek ağ güvenliğinde büyük avantaj sağlar, ancak temel network bilgisinin yerini tutmaz. TCP handshake, routing, subnetting, DNS, NAT, VLAN ve firewall state mantığını anlamadan yazılan otomasyon yanlış policy'yi daha hızlı uygulayabilir. Önce küçük lab kurup trafiği packet capture üzerinden izlemek çok öğreticidir. Ardından aynı işlemleri Python veya Terraform ile otomatikleştirmek öğrenmeyi pekiştirir. Kodlama ve network bilgisini birlikte geliştiren yaklaşım uzun vadede daha güçlü uzmanlık oluşturur.

Open Source Firewall ve Erişim Denetimi Araçları

Açık kaynak firewall ve erişim kontrolü araçları öğrenme, laboratuvar ve bazı production senaryolarında güçlü seçenekler sunar. nftables, iptables, OPNsense, pfSense Community Edition, IPFire, Cilium, PacketFence ve Suricata farklı ihtiyaçlara hitap eder. Araç seçerken yalnızca özellik listesine değil aktif bakım, dokümantasyon, güncelleme süreci ve ekibin operasyon deneyimine bakılmalıdır. Production güvenliği sürdürülebilir yönetim ve hızlı security update gerektirir. Topluluk içinde lab projeleri geliştirerek bu araçları gerçek trafik senaryolarında test etmek oldukça faydalıdır.

nftables

nftables modern Linux sistemlerde packet filtering ve firewall policy için kullanılan çekirdek tabanlı framework'tür. IPv4, IPv6 ve farklı protokol ailelerini daha birleşik syntax ile yönetebilir. Table, chain, set ve rule kavramlarını anlamak Linux network security için güçlü temel sağlar. Set kullanımı çok sayıda IP veya portu verimli biçimde yönetmeye yardımcı olur. Lab ortamında default deny ve stateful filtering örnekleriyle başlamak iyi öğrenme yöntemidir.

iptables

iptables uzun yıllar Linux firewall yönetiminde temel araçlardan biri olmuştur. Birçok mevcut sunucu ve eski script hâlâ iptables kullanabilir. Chain, table, connection state ve NAT mantığını öğrenmek network firewall kavramlarını anlamaya yardımcı olur. Yeni Linux sistemlerde nftables daha modern seçenek olabilir. Legacy ortamlarda ise iptables bilgisinin troubleshooting açısından değeri devam eder.

OPNsense

OPNsense açık kaynak tabanlı firewall ve routing platformudur. Web arayüzü üzerinden firewall, NAT, VPN ve çeşitli network servisleri yönetilebilir. Lab ortamında zone, VLAN ve site-to-site VPN senaryoları çalışmak için kullanılabilir. Eklenti kullanırken security update ve maintenance durumuna dikkat edilmelidir. Production kullanımı öncesinde donanım kapasitesi, HA ihtiyacı ve destek modeli değerlendirilmelidir.

pfSense Community Edition

pfSense Community Edition açık kaynak tabanlı firewall ve routing öğrenmek için kullanılabilecek seçeneklerden biridir. NAT, VLAN, VPN ve firewall rule kavramlarını pratik ortamda denemeyi sağlar. Sanal makine üzerinde küçük lab kurulabilir. Rule order ve state table davranışını gerçek trafikle görmek teorik bilgiyi güçlendirir. Production kullanımı için sürüm, donanım ve operasyon gereksinimleri ayrıca değerlendirilmelidir.

IPFire

IPFire ağ firewall ve routing işlevlerini sunan açık kaynaklı bir platformdur. Ev, lab veya belirli küçük ağ senaryolarında değerlendirilebilir. Zone mantığı üzerinden farklı network segmentleri ayrılabilir. Eklenti ve update mekanizmaları kullanımdan önce incelenmelidir. Her açık kaynak firewall gibi production öncesinde backup, restore ve monitoring süreçleri test edilmelidir.

Cilium

Cilium Kubernetes ve cloud-native ağlarda eBPF tabanlı network security sağlar. Pod identity ve label bilgisi üzerinden policy oluşturulabilir. Hubble ile flow visibility elde edilebilir. Microsegmentation ve default deny senaryoları için güçlü bir öğrenme alanıdır. Kubernetes temeli olmadan yalnızca policy syntax öğrenmek yerine cluster networking mantığını da birlikte çalışmak gerekir.

PacketFence

PacketFence açık kaynak Network Access Control projesidir. 802.1X, device registration, guest access ve isolation gibi NAC kullanım senaryolarında değerlendirilebilir. Switch ve wireless controller entegrasyonu proje başarısı için önemlidir. Lab ortamında RADIUS ve dynamic VLAN mantığını öğrenmek için yararlı olabilir. Production kullanımı öncesinde desteklenen cihazlar ve operasyon kapasitesi kontrol edilmelidir.

Suricata

Suricata açık kaynak network threat detection ve IDS/IPS özellikleri sunar. Firewall ile aynı işlevi yapmaz, ancak izin verilen trafiğin tehdit göstergeleri açısından izlenmesine yardımcı olabilir. Signature ve protocol logging özellikleri SOC çalışmalarında değerlidir. Yüksek trafik ortamında tuning ve performans planı gerekir. Firewall deny ve Suricata alert loglarını SIEM üzerinde birlikte analiz etmek güçlü use case'ler oluşturabilir.

Open Source Araç Seçerken Nelere Dikkat Edilmeli?

Açık kaynak araç seçerken güncelleme sıklığı, security advisory süreci, dokümantasyon ve aktif topluluk kontrol edilmelidir. Kullanım senaryosu aracın gerçek yetenekleriyle eşleştirilmelidir. Küçük lab için uygun çözüm yüksek erişilebilir production ortamı için yeterli olmayabilir. Backup, monitoring ve upgrade süreci test edilmelidir. Ekibin aracı anlayıp uzun vadede yönetebilmesi özellik sayısından daha önemli olabilir.

Open Source ve İşbirliği ile Ağ Güvenliği

Ağ güvenliğini öğrenmenin etkili yollarından biri gerçek projeler üzerinde ekip olarak çalışmaktır. Firewall rule template, lab ortamı, NetworkPolicy veya log analiz aracı gibi çalışmalar hem yazılım hem network becerisini geliştirir. GitHub üzerinden issue, pull request ve code review süreçleri teknik iletişimi de güçlendirir. Açık kaynak projelerin contribution guide dokümanlarını izlemek profesyonel geliştirme alışkanlığı kazandırır. Diyarbakır Yazılım Topluluğu içindeki proje ve etkinlik fikirlerini görmek için https://www.diyarbakiryazilim.com.tr/projects adresini inceleyebilirsiniz.

Firewall Rule Template Paylaşımı

Ortak firewall rule template oluşturmak ekiplerin aynı güvenlik alanlarını düşünmesini sağlar. Source, destination, owner, expiration ve test alanları standart hâle getirilebilir. Template vendor bağımsız yüksek seviyeli formatta hazırlanabilir. Pull request ile topluluk üyeleri geliştirme önerebilir. Gerçek kurum IP veya hassas configuration bilgileri açık repository'ye eklenmemelidir.

GitHub ile Network Policy Yönetimi

GitHub network policy dosyalarının version control ve review sürecini göstermek için iyi öğrenme ortamıdır. Örnek firewall-as-code repository oluşturulabilir. Branch, pull request ve automated test akışı pratik edilebilir. Policy linter geliştirmek yazılım ve güvenlik bilgisini bir araya getirir. Lab amaçlı örnekler gerçek production secret veya IP bilgisi içermemelidir.

Community Security Review

Community security review farklı deneyime sahip kişilerin aynı policy'yi birlikte incelemesini sağlar. Bir kişi network akışına, başka biri automation veya identity tarafına odaklanabilir. Review sırasında neden bu erişim gerekli sorusu teknik tartışmayı daha değerli hâle getirir. Eleştiri kişiye değil configuration ve risk modeline yönelmelidir. Böyle çalışmalar gerçek iş ortamındaki peer review kültürüne hazırlık sağlar.

Cilium ve Kubernetes NetworkPolicy Katkıları

Kubernetes NetworkPolicy örnekleri yazmak cloud-native security öğrenmek için pratik projedir. Default deny, namespace isolation ve egress control senaryoları oluşturulabilir. Cilium kullanılarak identity-aware policy ve flow visibility test edilebilir. Dokümantasyon iyileştirmeleri de değerli açık kaynak katkısıdır. Küçük issue çözmek büyük özellik geliştirmek kadar öğretici olabilir.

Açık Kaynak Firewall Projelerine Katkı

Açık kaynak firewall projelerine katkı yalnızca kod yazmakla sınırlı değildir. Dokümantasyon, test, bug report ve çeviri çalışmaları da değerlidir. Önce contribution guide ve issue listesini okumak gerekir. Küçük ve net bir problem seçmek başlangıç için daha kolaydır. Güvenlik projesinde sorumlu disclosure ve test etik kurallarına dikkat edilmelidir.

Lab Ortamlarının Paylaşılması

Network lab senaryolarını repository üzerinden paylaşmak başkalarının aynı çalışmayı tekrar etmesini sağlar. Terraform, Vagrant veya container tabanlı lab tanımları kullanılabilir. README dosyasında topoloji, amaç ve test senaryoları açıkça yazılmalıdır. Hassas credential kullanılmamalıdır. Tekrarlanabilir lab ortamları topluluk eğitimlerinin kalitesini ciddi ölçüde artırır.

Ağ Güvenliği Alanında Yazılımcı Olmak İçin Ne Yapmalı?

Ağ güvenliği ile yazılım geliştirmeyi birleştirmek isteyen biri için en iyi başlangıç, önce network'ün gerçekten nasıl çalıştığını anlamaktır. TCP/IP, routing, switching, Linux, DNS, firewall ve VPN temelini kurduktan sonra Python ile otomasyon projeleri geliştirmek çok daha anlamlı hâle gelir. Cloud networking, Zero Trust ve SIEM bilgisi ilerleyen aşamada eklenebilir. Küçük lab projeleri yalnızca kurs izlemekten daha kalıcı öğrenme sağlar. Toplulukla birlikte çalışmak, kod review almak ve proje yayınlamak öğrenme hızını artırabilir.

TCP/IP Öğrenmek

TCP/IP ağ güvenliğinin temel dilidir. TCP handshake, UDP davranışı, IP addressing ve subnetting anlaşılmadan firewall rule tasarımı zorlaşır. Wireshark gibi packet capture araçları protokolleri gerçek paketlerde görmenizi sağlar. Küçük client-server uygulaması yazarak bağlantı davranışını gözlemlemek oldukça öğreticidir. Port numarasını ezberlemek yerine protokolün nasıl çalıştığını anlamaya odaklanın.

Routing ve Switching

Routing farklı ağlar arasındaki yolu, switching ise Layer 2 iletişimi anlamanızı sağlar. VLAN, trunk, default gateway ve route table kavramları firewall tasarımıyla doğrudan ilişkilidir. Bir paket neden belirli firewall'dan geçmiyor sorusunun cevabı çoğu zaman routing'dedir. Lab ortamında birkaç VLAN ve router oluşturarak temel senaryolar çalışılabilir. ACL ve inter-VLAN policy eklemek öğrenmeyi güvenlik boyutuna taşır.

Linux

Linux ağ güvenliği çalışan yazılımcılar için güçlü çalışma ortamıdır. ip, ss, tcpdump, nftables ve systemd gibi araçlar günlük troubleshooting'de sık kullanılır. Basit server ve client servisleri kurmak network akışını anlamayı kolaylaştırır. Permission ve process yönetimi güvenlik temellerini de geliştirir. Bash ve Python otomasyonu Linux bilgisiyle birleştiğinde çok daha kullanışlı hâle gelir.

Firewall ve ACL

Firewall ve ACL konularında yalnızca GUI üzerinden rule eklemeyi öğrenmek yeterli değildir. Stateful, stateless, rule order, default deny ve NAT ilişkisini anlamak gerekir. Küçük lab'da önce trafiği tamamen engelleyip gerekli bağlantıları tek tek açmak iyi egzersizdir. Log ve packet capture ile kuralın neden eşleştiği görülmelidir. Aynı policy'yi ACL ve stateful firewall ile uygulayarak farkları gözlemlemek faydalıdır.

VPN

VPN uzak ağ veya kullanıcı bağlantılarında şifreli tünel sağlar. Site-to-site ve remote access modellerini öğrenmek gerekir. Routing, encryption domain ve firewall rule ilişkisi birlikte değerlendirilmelidir. VPN kurulduktan sonra kullanıcıya hangi internal network'lerin açıldığı ayrıca önemlidir. Lab ortamında iki sanal firewall arasında tünel kurmak güçlü pratik sağlar.

DNS

DNS uygulamaların büyük bölümünde görünmez ama kritik bağımlılıktır. Recursive resolver, authoritative server, record type ve caching mantığını öğrenmek gerekir. Firewall egress policy DNS trafiğini merkezi resolver üzerinden kontrol edebilir. DoH ve DNS tunneling gibi güvenlik konuları daha ileri aşamada çalışılabilir. DNS log analizi güvenlik otomasyonu için iyi proje alanıdır.

Network Automation

Network automation tekrar eden configuration ve monitoring görevlerini kodla yönetmeyi sağlar. API, data model ve idempotency kavramlarını öğrenmek önemlidir. Önce read-only inventory script yazarak başlamak güvenlidir. Daha sonra lab ortamında configuration deployment denenebilir. Production otomasyonunda approval, logging ve rollback mutlaka bulunmalıdır.

Python

Python API integration, log parsing ve network automation için güçlü başlangıç dilidir. requests, ipaddress ve JSON işlemleri günlük projelerde sık kullanılabilir. Firewall configuration export dosyasını okuyup overly permissive rule bulan script iyi başlangıç projesidir. Kod Git üzerinden version control altında tutulmalıdır. Unit test ve error handling eklemek projeyi gerçek iş kalitesine yaklaştırır.

Cloud Networking

Cloud networking VPC, VNet, subnet, route table, Security Group ve load balancer kavramlarını içerir. Fiziksel switch yerine software-defined kontrol kullanılsa da temel IP ve routing bilgisi değişmez. Infrastructure as Code cloud network deployment için önemli beceridir. Public exposure ve default security group'lar özellikle incelenmelidir. Küçük ücretsiz veya lab ortamlarında güvenli örnekler geliştirilebilir.

Zero Trust

Zero Trust tek ürün ezberlemek yerine erişim kararının kimlik, cihaz ve uygulama bağlamına göre nasıl verildiğini anlamayı gerektirir. Never Trust, Always Verify ve least privilege temel prensiplerdir. VPN, ZTNA, NAC ve firewall rollerini birlikte değerlendirmek gerekir. Basit lab'da farklı kullanıcı gruplarına farklı uygulama erişimi verilebilir. Policy kararlarını loglamak ve negatif test yapmak öğrenmeyi güçlendirir.

SIEM ve SOC Temelleri

SIEM firewall loglarının gerçek güvenlik olayına nasıl dönüştüğünü anlamanıza yardımcı olur. Log parsing, correlation, alert triage ve incident timeline temel konulardır. Basit port scan veya suspicious egress use case'i oluşturabilirsiniz. False positive tuning önemli beceridir. Network bilgisi olan yazılımcılar SOC otomasyonu alanında güçlü projeler geliştirebilir.

Diyarbakır Yazılım Topluluğu İçin Ağ Güvenliği Proje Fikirleri

Ağ güvenliği teorisini en iyi pekiştiren yöntemlerden biri birlikte çalışan bir lab ve proje ortamı oluşturmaktır. Diyarbakır Yazılım Topluluğu içinde Linux firewall, segmentasyon, Zero Trust, Kubernetes NetworkPolicy ve firewall-as-code gibi konular etrafında farklı seviyelerde projeler geliştirilebilir. Yeni başlayanlar trafik akışını gözlemlerken daha deneyimli katılımcılar otomasyon ve policy analizi üzerine çalışabilir. Ortak Git repository ve code review süreci teknik öğrenmenin yanında ekip çalışmasını da geliştirir. Topluluk hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresini ziyaret edebilirsiniz.

Açık Kaynak Firewall Lab

Birden fazla sanal network ve firewall içeren ortak lab kurulabilir. Kullanıcı, server, DMZ ve guest zone senaryoları oluşturulabilir. Katılımcılar default deny ile başlayıp ihtiyaç duyulan rule'ları ekleyebilir. Packet capture ve firewall logları üzerinden troubleshooting yapılabilir. Lab dosyaları Git repository üzerinde paylaşılabilir.

Linux nftables Atölyesi

nftables atölyesinde önce Linux network namespace ile küçük ağ topolojisi kurulabilir. Ardından stateful allow, default deny ve logging rule'ları yazılabilir. Set kullanımıyla IP ve port grupları yönetilebilir. IPv4 ve IPv6 davranışı birlikte test edilebilir. Katılımcılar en sonunda kendi firewall script'ini Git üzerinden paylaşabilir.

OPNsense/pfSense Test Ortamı

Sanal firewall ortamı kullanarak VLAN, NAT, VPN ve rule order senaryoları test edilebilir. Aynı trafik için yanlış ve doğru rule sırası karşılaştırılabilir. Guest ve DMZ segmentation uygulaması yapılabilir. Logların merkezi syslog sunucusuna gönderilmesi ayrıca çalışılabilir. Proje sonunda ortak network diagram ve configuration checklist hazırlanabilir.

Network Segmentation Workshop

Workshop için örnek şirket ağı tasarlanabilir. Kullanıcı, finans, server, IoT ve management segmentleri oluşturulur. Katılımcılardan önce data flow matrisi hazırlamaları istenir. Ardından least privilege firewall rule'ları tasarlanır. Son aşamada lateral movement senaryosu üzerinden segmentasyonun etkisi test edilir.

Zero Trust ve NAC Demo

Basit NAC veya identity-aware lab ile kullanıcı ve cihaz tabanlı erişim gösterilebilir. Managed cihaz belirli uygulamaya erişirken unmanaged cihaz restricted zone'a yönlendirilebilir. RADIUS ve dynamic VLAN davranışı test edilebilir. MFA veya kullanıcı grubu firewall policy ile ilişkilendirilebilir. Demo, Zero Trust kavramını sadece sunum değil çalışan örnek üzerinden anlatır.

Kubernetes NetworkPolicy Projesi

Minik bir Kubernetes cluster üzerinde web, API ve database pod'ları kurulabilir. Başlangıçta tüm pod trafiği açık bırakılır ve akış gözlemlenir. Ardından default deny ve gerekli allow NetworkPolicy'leri eklenir. Cilium kullanılıyorsa flow visibility de incelenebilir. Policy dosyaları Git pull request ile yönetilebilir.

Firewall-as-Code GitHub Projesi

Vendor bağımsız YAML formatında firewall rule tanımı oluşturulabilir. Python script bu dosyaları okuyarak duplicate, Any ve missing owner kontrolü yapabilir. GitHub Actions benzeri CI mekanizması pull request sırasında test çalıştırabilir. Başarısız policy merge edilmez. Proje büyüdükçe farklı firewall formatlarına output üretme özelliği eklenebilir.

Ortak Network Security CTF

Network Security CTF katılımcılara troubleshooting ve savunma odaklı görevler sunabilir. Yanlış firewall rule order, açık management port veya DNS egress gibi hatalar senaryoya eklenebilir. Katılımcılar log ve packet capture üzerinden problemi bulur. Çözüm sonrasında neden riskli olduğu birlikte tartışılır. Gerçek kurum sistemleri yerine tamamen izole lab kullanılmalıdır.

Sık Sorulan Sorular

Firewall ve ağ erişim güvenliği konularında aynı sorular farklı kurumlarda tekrar tekrar karşımıza çıkar. Bunun nedeni firewall'ın yalnızca teknik bir cihaz değil, kullanıcı, uygulama, network ve iş süreçlerini bir araya getiren enforcement noktası olmasıdır. Aşağıdaki cevaplar en temel kavramları kısa ama uygulanabilir şekilde özetler. Gerçek ortamda kullanılacak policy her zaman kurumun network mimarisi ve risk seviyesine göre uyarlanmalıdır. Özellikle üretim değişiklikleri test, approval ve rollback süreciyle uygulanmalıdır.

Firewall kuralı nedir?

Firewall kuralı belirli bir trafiğin izinli mi yoksa engelli mi olacağını tanımlayan policy satırıdır. Kaynak, hedef, port, protokol, uygulama, kullanıcı ve action bilgileri içerebilir. İyi rule yalnızca gerekli erişimi açar. Owner ve business justification ile belgelenmelidir. Kullanım ihtiyacı sona erdiğinde kaldırılmalıdır.

Firewall kuralları hangi sırayla çalışır?

Birçok firewall rule base'i yukarıdan aşağı ve ilk eşleşme mantığıyla çalışır. İlk eşleşen policy'nin action değeri uygulanır. Bu nedenle özel kurallar genel kurallardan önce yer almalıdır. Ancak platformun evaluation davranışı resmi dokümantasyondan doğrulanmalıdır. Rule order değişikliği öncesinde simulation yapmak faydalıdır.

Default deny nedir?

Default deny açıkça izin verilmemiş tüm trafiğin engellenmesi yaklaşımıdır. Bu model erişimi varsayılan olarak güvenli ve kapalı başlatır. Gerekli bağlantılar exception olarak eklenir. Yeni sistemler otomatik olarak geniş access kazanmaz. Least privilege firewall tasarımının en önemli temellerinden biridir.

ACL ile firewall arasındaki fark nedir?

ACL çoğunlukla IP, protokol ve port gibi Layer 3 veya Layer 4 bilgilerini kontrol eder. Modern firewall buna state tracking, application identification ve user identity gibi ek bağlamlar ekleyebilir. ACL basit segmentasyon için yeterli olabilir. Kritik internet ve application access için stateful firewall daha ayrıntılı kontrol sunar. Hangi aracın kullanılacağı risk ve trafik yapısına göre belirlenir.

Stateful ve stateless firewall arasındaki fark nedir?

Stateless firewall her paketi bağımsız değerlendirir. Stateful firewall ise connection table üzerinden oturum durumunu takip eder. İzinli bağlantının dönüş trafiği state ile otomatik eşleştirilebilir. Stateless yapıda return traffic için daha fazla rule gerekebilir. Her iki model farklı performans ve kullanım senaryolarına sahiptir.

Any Any Allow neden tehlikelidir?

Any Any Allow birçok kaynağın çok geniş hedef ve servis alanına erişmesine izin verir. Segmentasyon sınırlarını zayıflatır. Ele geçirilmiş cihazın lateral movement yapmasını kolaylaştırabilir. Troubleshooting için geçici kullanılmışsa süre sonunda kaldırılmalıdır. Kalıcı erişim minimum source, destination ve portlarla yeniden tasarlanmalıdır.

Firewall kuralları ne sıklıkla kontrol edilmelidir?

Review sıklığı risk seviyesine göre belirlenmelidir. Kritik management ve internet rule'ları daha sık incelenebilir. Aylık operasyon kontrolü ve üç aylık recertification birçok ortam için başlangıç modeli olabilir. Decommission veya büyük network değişikliği sonrasında ek review yapılmalıdır. Continuous monitoring formal review sürecini destekler.

Shadowed firewall rule nedir?

Shadowed rule üstteki başka bir policy nedeniyle hiçbir zaman eşleşmeyen kuraldır. Genellikle geniş allow veya deny kuralının altında kalan daha özel policy'lerde görülür. Çalıştığı sanılan güvenlik kontrolü gerçekte etkisiz olabilir. Otomatik analyzer veya policy simulation ile tespit edilebilir. Doğru sıraya taşınmalı veya gereksizse kaldırılmalıdır.

Kullanılmayan firewall rule nasıl tespit edilir?

Hit count ve last-hit bilgisi ilk veri kaynağıdır. Uzun süre sıfır hit alan policy'ler cleanup adayı olabilir. Ancak seasonal veya disaster recovery rule'lar unutulmamalıdır. Owner confirmation ve application inventory ile ihtiyaç doğrulanmalıdır. Önce disable edip gözlemlemek güvenli silme yöntemidir.

Network Access Control (NAC) nedir?

NAC ağa bağlanan kullanıcı ve cihazın kimliğini ve güvenlik durumunu değerlendirir. 802.1X, RADIUS, device profiling ve posture check kullanabilir. Sonuca göre VLAN, ACL veya access policy atayabilir. Uyumlu olmayan cihaz quarantine alanına alınabilir. Firewall ile birlikte kullanıldığında identity-aware network access sağlanabilir.

NAC ile firewall arasındaki fark nedir?

NAC öncelikle cihazın ağa girişini ve hangi erişim seviyesini alacağını belirler. Firewall ise zone veya network'ler arasındaki trafik akışını kontrol eder. NAC cihaz identity ve posture bilgisine yakın çalışır. Firewall port, application ve destination policy'sinde güçlüdür. Birlikte kullanıldığında daha kapsamlı erişim denetimi oluşur.

Zero Trust firewall'ın yerini alır mı?

Zero Trust firewall'ın doğrudan alternatifi değildir. Zero Trust kimlik, cihaz ve uygulama bağlamına göre erişimi doğrular. Firewall network ve workload seviyesinde enforcement sağlamaya devam eder. ZTNA kullanıcıdan uygulamaya erişimi daraltabilir. En iyi sonuç identity, segmentation ve firewall kontrolleri birlikte kullanıldığında elde edilir.

Security Group ile Network ACL arasındaki fark nedir?

Cloud platformlarında Security Group genellikle workload veya interface seviyesinde çalışır. Network ACL çoğu modelde subnet seviyesinde ek kontrol sağlar. Stateful ve stateless davranışları platforma göre farklı olabilir. Rule evaluation yöntemi de ayrı olabilir. Kullanılan cloud sağlayıcısının güncel dokümantasyonu üzerinden özellikler doğrulanmalıdır.

Firewall as Code nedir?

Firewall as Code policy'nin GUI yerine deklaratif kod veya yapılandırma dosyaları üzerinden yönetilmesidir. Git versioning ve pull request review kullanılabilir. CI/CD syntax ve security testlerini otomatik çalıştırabilir. Deployment API üzerinden tekrarlanabilir hâle gelir. Change history ve rollback daha görünür olur.

Firewall logları SIEM'e nasıl gönderilir?

Firewall syslog, API veya vendor connector üzerinden merkezi SIEM'e log gönderebilir. Transport mümkün olduğunda güvenli ve güvenilir şekilde yapılandırılmalıdır. SIEM parser timestamp, source, destination, user ve rule ID alanlarını doğru çıkarmalıdır. Log source health ayrıca izlenmelidir. Firewall üzerinde log oluşup SIEM'e ulaşmaması güvenlik görünürlüğünü azaltır.

Ağ güvenliği için hangi programlama dili öğrenilmelidir?

Python network automation ve log analizi için güçlü başlangıç seçeneğidir. Linux tarafında Bash, Windows ortamında PowerShell faydalıdır. Cloud altyapısı için Terraform ve HCL bilgisi değerlidir. Go daha yüksek performanslı network ve cloud-native uygulamalarda güçlü seçenektir. Ancak programlama dilinden önce TCP/IP, routing, firewall ve DNS temelleri öğrenilmelidir.

Ağ Güvenlik Duvarı ve Erişim Denetimi Hakkında Sık Sorulan Sorular

Uygulama aşamasına gelindiğinde teknik ekiplerin en çok sorduğu sorular genellikle kural oluşturma, inbound ve outbound erişim, least privilege, periyodik denetim ve uzman desteği etrafında toplanır. Aşağıdaki cevaplar özellikle kurumsal firewall yapılandırma ve ağ erişim güvenliği hizmeti arayan ekiplerin başlangıçta netleştirmesi gereken konuları özetler. Her ortamın IP planı, uygulama yapısı ve kullanıcı rolleri farklıdır. Bu nedenle aynı firewall şablonunu doğrudan başka bir şirkete uygulamak yerine erişim akışlarını yeniden analiz etmek gerekir. Firewall ve ağ güvenliği danışmanlığı yakınımda şeklinde araştırma yapan kullanıcılar için de yerel topluluklar ve uygulamalı eğitimler iyi bir başlangıç noktası olabilir.

Ağ güvenlik duvarı (Firewall) kuralları nasıl oluşturulur ve yönetilir?

Ağ güvenlik duvarı kuralları nasıl oluşturulur ve yönetilir sorusunun temel cevabı, önce data flow ve business justification belirlemektir. Kaynak, hedef, port, protokol, uygulama ve kullanıcı kapsamı minimum gereksinimle tanımlanmalıdır. Yeni kural peer review ve security review sürecinden geçirilmelidir. Deployment sonrası expected allow ve expected deny testleri yapılmalıdır. Kuralın owner, review date ve gerekiyorsa expiration date bilgisi daha ilk günden oluşturulmalıdır.

Güvenlik duvarında gelen ve giden trafik için erişim denetimi kuralları nasıl yapılandırılmalıdır?

Inbound trafik için internetten veya düşük güven seviyeli zone'lardan gelen erişimler default deny ile başlamalıdır. Yalnızca yayımlanan servislerin gerekli portları açılmalıdır. Outbound trafik de serbest bırakılmamalı, özellikle sunucular için DNS, update ve API hedefleri sınırlandırılmalıdır. Proxy ve egress firewall policy birlikte kullanılabilir. Her iki yöndeki kritik bağlantılar SIEM'e aktarılacak şekilde loglanmalıdır.

Firewall kurallarında least privilege, IP, port ve protokol bazlı erişim kontrolü nasıl uygulanır?

Least privilege uygulamak için source ve destination alanlarını mümkün olduğunca dar tutun. Yalnızca gerçek uygulama portlarını ve gerekli TCP veya UDP protokolünü tanımlayın. Kullanıcı erişiminde identity group, yönetilen cihaz ve MFA gibi ek bağlamlardan yararlanın. Temporary erişimlere süre sınırı koyun. Rule kapsamını düzenli hit count ve owner recertification süreciyle yeniden doğrulayın.

Ağ güvenlik duvarı kuralları nasıl düzenli olarak denetlenir ve gereksiz erişim izinleri nasıl tespit edilir?

Firewall audit sürecinde zero-hit, stale, duplicate, shadowed ve overly permissive rule raporları çıkarılmalıdır. Son hit zamanı ve traffic logları uygulama envanteriyle karşılaştırılmalıdır. Rule owner mevcut business need'i yeniden doğrulamalıdır. Gereksiz olduğu düşünülen erişim önce disable edilip belirli süre gözlemlenebilir. Ardından change record ve audit evidence korunarak kalıcı cleanup yapılabilir.

Ağ güvenlik duvarı ve erişim denetimi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Firewall ve ağ güvenliği danışmanlığı yakınımda şeklinde araştırma yapıyorsanız yalnızca ürün kurulumu sunan hizmetlere değil, erişim politikası, segmentasyon, loglama ve operasyon sürecini birlikte ele alan çalışmalara odaklanmanız yararlı olur. Diyarbakır'da yazılım, ağ güvenliği, açık kaynak ve proje çalışmalarına ilgi duyuyorsanız Diyarbakır Yazılım Topluluğu üzerinden içerik ve topluluk çalışmalarını takip edebilirsiniz. Topluluk hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz. Proje çalışmalarına ulaşmak için https://www.diyarbakiryazilim.com.tr/projects adresini kullanabilirsiniz. Öğrenmeye lab, açık kaynak proje ve güvenlik otomasyonu gibi uygulamalı çalışmalarla devam etmek teorik bilgiyi gerçek problem çözme becerisine dönüştürür.

Sonuç

Ağ Güvenlik Duvarı Kuralları ve Erişim Denetimi yalnızca firewall üzerinde birkaç IP ve port tanımlamaktan çok daha kapsamlı bir güvenlik disiplinidir. Default deny, least privilege, doğru rule order, network segmentation, identity-aware access, NAC, Zero Trust, logging ve change management aynı güvenlik zincirinin parçalarıdır. En güçlü firewall bile owner bilgisi olmayan, hiç gözden geçirilmeyen ve temporary access'lerin kalıcı bırakıldığı bir ortamda beklenen korumayı sağlayamaz. Buna karşılık düzenli review, iyi dokümantasyon ve otomasyon ile daha küçük ekipler bile yönetilebilir ve güvenli bir erişim modeli kurabilir. Buradaki yaklaşımı kendi lab ortamınızda adım adım uygulayarak network trafiğinin nasıl değiştiğini gözlemlemek, teorik bilgiyi gerçek beceriye dönüştürmenin en etkili yollarından biridir.

Ağ güvenliği, firewall automation, açık kaynak projeler veya topluluk çalışmalarıyla devam etmek isterseniz Diyarbakır Yazılım Topluluğu içeriklerini ve projelerini takip edebilirsiniz. Farklı seviyelerde yazılımcıların birlikte üretebileceği firewall lab, Kubernetes NetworkPolicy, Python log analizi ve firewall-as-code projeleri bu alanda güçlü bir öğrenme zemini oluşturur. Topluluk hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr/about adresini, proje çalışmalarını görmek için https://www.diyarbakiryazilim.com.tr/projects adresini kullanabilirsiniz. Güvenli erişim politikası bir kez yazılıp unutulan belge değildir, uygulamalar ve ağlar değiştikçe yeniden doğrulanması gereken yaşayan bir süreçtir. Kendi firewall rule base'inizi bugün source, destination, port, owner, hit count ve expiration açısından gözden geçirmek bu sürecin en iyi başlangıç adımlarından biridir.