Palo Alto Güvenlik Duvarı ile NAC Çalıştırmak: Üretim Ortamında Gerçekte Neler Oluyor?
Palo Alto Güvenlik Duvarı ile NAC Çalıştırmak: Üretim Ortamında Gerçekte Neler Oluyor?
Bir NAC projesini bitirip Palo Alto güvenlik duvarı entegrasyonunu tamamladığınızda, ilk başta her şey yolunda görünür. Ancak birkaç ay sonra, işler sessizce bozulmaya başlar.
“DHCP yenilendi, ancak güvenlik duvarı hala eski Kullanıcı Kimliğine dayalı politikayı uyguluyor.”
“ISE, uç noktayı karantinaya alınmış olarak gösteriyor, ancak trafik hala güvenlik duvarından geçiyor. Bağlantı kopukluğu nerede?”
“XSOAR playbook’unu düzeltmem gerekiyor, ancak önce bunun bir NAC sorunu mu yoksa bir PANW sorunu mu olduğunu anlamam lazım.”
Eğer bunların herhangi biri size tanıdık geliyorsa, bu yazı o deneyimle ilgili. Herhangi bir ürünün bozulmasıyla ilgili değil. Farklı amaçlar için tasarlanmış iki sistemin tek bir sistem gibi çalışması istendiğinde ortaya çıkan yapısal gerçeklik ve işletme maliyetleriyle ilgili.
Palo Alto Networks, güvenlik alanındaki tüm önemli kategorileri (Güvenlik Duvarı, SASE, XDR, SOAR, IoT Güvenliği) kapsıyor, ancak kendi NAC’ını hiç kurmadı. Bunun yerine, Cisco ISE, Aruba ClearPass, Forescout ve Extreme Networks için entegrasyon kılavuzları sağlıyor. Bunun nedeni yapısal: NAC, PANW’nin sahip olmadığı switch, AP ve RADIUS altyapısına derinden bağlı. Cisco, ISE’yi switch’leriyle birlikte geliştiriyor. Aruba, ClearPass’ı AP’leriyle birlikte geliştiriyor. PANW’nin stratejisi, NAC sistemlerinin ürettiği kimlik ve bağlamı kullanmak, yani altyapı katmanını kendisi kurmamaktı. Bu strateji mantıklı. Sorun şu ki, bu entegrasyonun belgelerde hiç bahsedilmeyen maliyetleri var.
Kimlik Eşleme Kayması, Politika Modeli Uyumsuzluğu ve XSOAR Bağımlılığı
Palo Alto TechDocs’un resmi entegrasyon kılavuzları oldukça iyi yazılmış. Yapay zeka destekli IoT cihaz profillemesinin NAC’ye veri sağlaması, NAC’nin VLAN segmentasyonunu ve karantinasını uygulaması şeklindeki mimari, kağıt üzerinde oldukça etkileyici.
Dokümanlarda yer almayan konu ise devreye alma işleminden sonra neler olduğudur. Bu entegrasyonları fi fiilen çalıştıran mühendisler sürekli olarak aynı tür sorunlarla karşılaşıyorlar. Bunlar teknoloji spesifikasyon hataları değil, operasyonel yapı hatalarıdır; yani farklı iç modellere sahip iki sistemin senkronize kalması beklendiğinde ortaya çıkan türden hatalar.
Veri doğruluğu sorunu
Dokümanlarda yer almayan konu ise devreye alma işleminden sonra neler olduğudur. Bu entegrasyonları fi fiilen çalıştıran mühendisler sürekli olarak aynı tür sorunlarla karşılaşıyorlar. Bunlar teknoloji spesifikasyon hataları değil, operasyonel yapı hatalarıdır; yani farklı iç modellere sahip iki sistemin senkronize kalması beklendiğinde ortaya çıkan türden hatalar.
NAC-Güvenlik Duvarı entegrasyonunun temel varsayımı, güvenlik duvarının NAC’nin oluşturduğu eşleştirmeye güvenmesidir: bu IP adresi bu cihazdaki bu kullanıcıya aittir. Gerçek ağlarda ise bu eşleştirme sürekli değişim halindedir.
- DHCP yenileme: Bir IP adresi değiştiğinde, NAC oturum durumu ve güvenlik duvarının Kullanıcı Kimliği tablosu senkronizasyon dışı kalabilir. Otomatik kurtarma genellikle işe yarar, ancak zamanlama yanlış olduğunda, hatalı bir politika bir süre boyunca devam edebilir.
- Wi-Fi dolaşımı: Erişim noktaları arasında geçiş yapmak, NAC oturum yenilemesini ve güvenlik duvarı oturum senkronizasyonunu farklı zamanlarda tetikler. Bir şey bozulduğunda, hatanın NAC’den mi yoksa güvenlik duvarından mı kaynaklandığını belirlemek yapısal olarak zordur.
- IP yeniden kullanımı: Yeni bir kullanıcıya başka bir kullanıcı tarafından yakın zamanda serbest bırakılan bir IP adresi atandığında, güvenlik duvarı bir güncelleme alana kadar önceki kullanıcının politikasını uygulayabilir. Bu senaryo, küresel operatör topluluklarında tekrar tekrar rapor edilmektedir.
Bunlar satıcı kaynaklı hatalar değil. İki sistemin oturum durumunu bağımsız olarak yönetmesinden kaynaklanan yapısal sorunlar. Bu da NAC-Güvenlik Duvarı entegrasyonunu göründüğünden daha zor hale getiriyor.
Politika dili uyumsuzluğu
NAC, uç nokta profilleme, cihaz duruşu ve VLAN ataması etrafında politika oluşturur. Güvenlik duvarı ise kullanıcı, uygulama, bölge ve adres bazında çalışır. Bu iki politika modeli arasında otomatik çeviri sağlayan resmi bir mekanizma bulunmamaktadır.
Pratikte, NAC rolü her değiştiğinde, güvenlik duvarı politikası ayrı olarak güncellenmelidir. İki bağımsız politika setinin sürdürülmesinin operasyonel yükü zamanla artmaktadır.
Kimsenin bütçesine dahil etmediği XSOAR bağımlılığı
Entegrasyon mimarisi belgeleri faydaları açıklıyor. Ancak operasyonel yükü açıklamıyorlar. Dört resmi iş ortağından herhangi biriyle eksiksiz bir otomatik tehdit yanıtı iş akışı oluşturmak için Cortex XSOAR On-prem Engine gereklidir. Temel özellik aktarımı onsuz da çalışabilir, ancak bu tek başına güvenlik ekiplerinin beklediği otomasyon seviyesini sağlamaz. Ve XSOAR sadece bir lisans kalemi değil.
| Gizli Maliyet | Gerçekte Ne Anlama Geliyor? |
|---|---|
| Altyapı | XSOAR On-prem Engine’i çalıştırmak için özel bir Linux sunucusunun sağlanması ve bakımının yapılması gerekmektedir. |
| Lisanslama | Gelişmiş abonelik seviyesi gereklidir — temel abonelikler tam entegrasyonu desteklemez. |
| Operasyonel personel temini | XSOAR playbook’unun bakımından birinin sorumlu olması ve her sürüm yükseltmesinden sonra yeniden doğrulamasının yapılması gerekiyor. |
| Olay müdahalesi | Bir sorun oluştuğunda, hata ayıklama işlemi aynı anda üç sistemi kapsar: NAC, PANW ve XSOAR. |
Bu maliyetlerin hiçbiri proje bütçesinde kalem olarak yer almaz. Sistem ömrü boyunca operasyonel karmaşıklık olarak sessizce birikirler.
Identity Mapping Drift, Policy Model Mismatch, and the XSOAR Dependency
Section 1 describes the structural problems common to all four integrations. On top of that shared baseline, each vendor adds its own operational weight. The following is based on Palo Alto’s official TechDocs integration documentation and reports from global practitioner communities.
Cisco ISE — Yetenekli, en karmaşık
PANW–ISE entegrasyonu, dört entegrasyon arasında en kapsamlı özelliğe sahip olanıdır. ACL uygulamasını, pxGrid entegrasyonunu ve Birincil/İkincil Yüksek Erişilebilirlik özelliğini destekler. Bu gelişmişlik bir maliyetle birlikte gelir.
- Uygulayıcılar, dağıtım sırasında kimlik doğrulama yapılandırma sürecinin, sistemler arası entegrasyon ayarlarının karmaşıklığı nedeniyle beklenenden önemli ölçüde daha uzun sürebileceğini bildiriyor.
- PANW entegrasyonu bir HA yapılandırmasına katmanlandığında, arızaların temel nedenini belirlemek önemli ölçüde zorlaşıyor.
- ISE’nin özellik başına lisanslama yapısı, entegrasyon sırasında beklenmedik maliyet artışlarına neden olabilir.
Aruba ClearPass — Varsayılan yapılandırmada tek yönlü bilgi akışı
PANW IoT Güvenlik verilerinden ClearPass’te otomatik olarak özel uç nokta öznitelikleri oluşturan entegrasyon iyi tasarlanmış. Sınırlama ise varsayılan entegrasyonun tek yönlü olmasıdır.
- Varsayılan yapılandırmada, veriler PANW’den ClearPass’e akar. ClearPass tarafından tutulan anahtar bağlantı noktası ayrıntıları, fiziksel konum ve RADIUS kimlik doğrulama durumu PANW’ye geri bildirilmez; bu da her iki sistemde ayrı envanter yönetimi gerektirir.
Forescout — Otomasyon seviyesini kontrol edin
Forescout, ajansız cihaz keşfiyle yaygın olarak bilinir. PANW entegrasyonu açısından otomasyon seviyesi dikkatli bir incelemeyi gerektirir.
- Resmi PANW entegrasyon kılavuzuna göre: cihaz özniteliklerinin dışa aktarılması manuel bir dışa aktarma işlemi olarak belgelenmiştir. Bu, tehdit tespitinden yaptırıma kadar olan otomatik zinciri bozabilir.
- ‘Ajan gerektirmeyen’ konumlandırmaya rağmen, Windows dışı ortamlarda çözülebilir ajanlara ihtiyaç duyulabilir.
Extreme Networks ExtremeCloud IQ — Çift yönlü, ancak yalnızca yerel kurulum için
ExtremeCloud IQ Site Engine, Palo Alto TechDocs’ta çift yönlü varlık bilgi alışverişinin açıkça belgelendiği dört iş ortağından tekidir. PANW’ye fiziksel konum verisi sağlama yeteneği, envanter uyumsuzluğu sorununu kısmen çözmektedir.
- Bulut bağlantısı bulunmamaktadır. Entegrasyon, yalnızca şirket içi ortamlara sınırlıdır; bu da hibrit altyapılardaki uygulanabilirliğini kısıtlamaktadır.
Bu noktada, CISO’ların aklına gelen soru genellikle şu oluyor: Entegrasyonumuz gerçekten işe yarıyor mu, yoksa sadece işe yarıyor gibi mi görünüyor? Kaç kuruluş bu soruya güvenle cevap verebilir?
Daha Az Hareketli Parça: NAC-Güvenlik Duvarı Entegrasyonuna Daha Yalın Bir Yaklaşım
Alternatif bir çözüme bakmadan önce, bu entegrasyonun neden hala önemli olduğunu sormakta fayda var. Forrester araştırmasına göre, NAC kullanım oranları 2018’de %59’dan 2022’de %44’e düştü. Gartner’ın 2024 kılavuzu, yeni NAC yatırımlarının taktiksel bir seviyeyle sınırlandırılmasını öneriyor. İlk bakışta, NAC gerileyen bir kategori gibi görünüyor.
Bu düşüş, altta yatan sorunun ortadan kalktığı anlamına gelmiyor, güvenlik bütçelerinin nereye kaydığını yansıtıyor. Ağ ortamı son on yılda temelden değişti; şirket içi sistemlerden buluta, kampüs ortamından uzaktan çalışmaya, yönetilen cihazlardan IoT ve OT’ye geçiş yaşandı. Her değişim yeni bir güvenlik kategorisi ortaya çıkardı. Bulut veri koruması için CASB, uzaktan uygulama erişim kontrolü için ZTNA, OT ve IoT cihaz görünürlüğü için IoT Güvenlik platformları. Her biri kendi katmanında sorununu iyi bir şekilde çözüyor.
Bu çözümlerin hepsinin ortak bir ön koşulu vardır: bir yazılım aracısı, bulut proxy’si veya kullanıcı kimlik doğrulaması mevcut olmalıdır. Bu ön koşul, yazılım aracısı çalıştıramayan IoT, OT, tıbbi cihazlar ve eski ekipmanların bulunduğu ortamlarda veya kullanıcı kimlik doğrulamasının bir kavram olmadığı M2M ortamlarında veya uygulama işlemlerinin kesintiye uğratılamayacağı üretim, hastane ve altyapı ortamlarında geçerli değildir.
Ağa bağlanan her cihazı – aracı yazılımlar veya sertifikalar olmadan, doğrudan Katman 2’de – tanımlamak ve kontrol etmek, NAC’nin çözmek için tasarlandığı sorundur. 2026’da başka hiçbir çözüm kategorisi bunu yapmıyor. Güvenlik yatırımları arttıkça ve yapay zeka destekli araçlar çoğaldıkça, uygulama katmanının gerçekten çalışıp çalışmadığı sorusu daha da önem kazanıyor, önemini yitirmiyor.
Bölüm 1 ve 2’deki yapısal sorunların ortak bir kökeni vardır: NAC ve güvenlik duvarı politikası arasında çok fazla hareketli parça bulunması. Bir aracı sistem, ayrı bir sunucu, sürdürülmesi gereken bir kılavuz, sapma gösterebilen bir senkronizasyon döngüsü. Genian NAC, zincirdeki bileşen sayısını azaltarak bu sorunu çözüyor. Palo Alto’nun resmi iş ortağı listesinde yer almıyor, ancak entegrasyon mimarisi temelde daha yalın.
Doğrudan PAN-OS entegrasyonu — XSOAR gerekmez
Genian NAC, XML API (HTTPS port 8443) veya Syslog (TLS port 6514) aracılığıyla doğrudan PAN-OS ile entegre olur. Kullanıcı kimlik doğrulaması tamamlanır tamamlanmaz, IP-Kullanıcı Kimliği eşleştirmesi gerçek zamanlı olarak PAN-OS’a gönderilir ve Kullanıcı Kimliği tablosu otomatik olarak güncellenir. XSOAR On-prem Engine kullanılmaz.
- Özel bir Linux sunucusuna, gelişmiş abonelik katmanına veya temel entegrasyonun çalışması için gerekli olan kılavuz personele gerek yok.
- Bir kullanıcı departmanını, konumunu veya IP adresini değiştirdiğinde, güvenlik duvarı kuralları otomatik olarak güncellenir. Manuel müdahale gerekmez.
- XSOAR’a sahip kuruluşlar için, Genian NAC Adaptörü (XSOAR v6.0 ve üzeri sürümlere entegre edilmiştir) bunu tehdit tespitinden Katman 2 uygulamasına kadar tam otomatik bir zincire genişletir.
ARP tabanlı Katman 2 uygulama — 802.1X EAP-TLS olmadan çalışır
Birçok NAC çözümü, birincil kimlik doğrulama yöntemi olarak 802.1X EAP-TLS etrafında kurulmuştur. Bu, tam bir PKI altyapısı gerektirir: bir Sertifika Otoritesi, cihaz başına sertifika düzenleme ve sürekli yenileme döngüleri. Bir sertifikanın süresi dolarsa, cihaz ağ erişimini kaybeder.
Genian NAC’ın birincil uygulama yöntemi, ARP tabanlı Katman 2 algılama ve engellemedir. Gerektiğinde 802.1X EAP-TLS desteklenir, ancak ARP tabanlı yaklaşım, sistemin sertifika altyapısına bağımlılık olmadan çalışabileceği anlamına gelir.
- Sertifika süresinin dolmasından kaynaklanan ağ genelindeki kesinti riski yapısal olarak azaltılmıştır.
- 802.1X’in pratik olmadığı OT cihazları, IoT ve eski ekipmanlar aynı politika çerçevesi altında yönetilebilir.
- Ajan kurulumunun mümkün olmadığı tıbbi cihazlar, PLC’ler ve SCADA sistemleri ARP aracılığıyla tespit edilip izole edilebilir.
Ağ Sensörü, kimlik eşleme sorununu yapısal olarak ele alıyor.
Bölüm 1’de açıklanan Kullanıcı Kimliği eşleme kayması (DHCP yenilemesi, dolaşım ve IP yeniden kullanımı nedeniyle tetiklenir), iki sistemin oturum durumunu bağımsız olarak izlemesinden kaynaklanır. Genian NAC, ağ genelinde durum değişikliklerini sürekli olarak izleyen ve eşleme güncellemelerini otomatikleştiren Ağ Sensörleri konuşlandırır.
- DHCP yenilemeleri ve dolaşım olayları gerçek zamanlı olarak algılanır ve otomatik kimlik eşleme yenilemesi tetiklenir.
- Görünürlük, yalnızca anahtar bağlantı noktası düzeyinde değil, ağ segmenti düzeyinde de korunur. Yönetilmeyen cihazlar, aracı yazılımlara gerek kalmadan algılanabilir.
- Sensör mimarisi, ağ topolojisi değişikliklerinin mümkün olmadığı eski altyapı ve OT ortamlarına müdahale etmeden entegre edilir.
Ağ Sensörü mimarisi hakkında detaylı bir yazı daha sonra yayınlanacaktır.
| Yapısal Sorun | Resmi 4 Ortak | Genian NAC Yaklaşımı |
|---|---|---|
| XSOAR bağımlılığı | Otomatikleştirilmiş iş akışları için gereklidir. | Gerekli değil — doğrudan PAN-OS entegrasyonu |
| 802.1X EAP-TLS bağımlılığı | Zorunlu — sertifika süresinin dolması riski mevcuttur. | ARP tabanlı birincil bağlantı — EAP-TLS isteğe bağlı olarak desteklenir |
| Bilgi akışı yönü | PANW → NAC tek yönlü (Extreme hariç) | NAC → PAN-OS gerçek zamanlı teslimat |
| Otomasyon seviyesi | Forescout: manuel dışa aktarma belgelendi | REST API aracılığıyla tam otomasyon |
| Yönetilmeyen cihaz kapsamı | 802.1X desteği olmayan cihazlar istisna işleme gerektirir. | ARP tabanlı tespit yoluyla tam kapsamlı koruma |
| PANW resmi ortağı | Resmi olarak tanınmış | Resmi değil — bağımsız entegrasyon mimarisi |
Operasyonel Kontrol Listesi: NAC-Güvenlik Duvarı Entegrasyonu İçin Kritik Hususlar
NAC-Güvenlik Duvarı entegrasyonlarını değerlendiren veya yürüten kuruluşlar için
Hangi NAC çözümü kullanılırsa kullanılsın, üretim ortamında aynı sorular tekrar tekrar ortaya çıkar. Bu soruların net cevapları yoksa, entegrasyonun güvenlik duruşunu güçlendirmekten ziyade operasyonel karmaşıklığı artırma olasılığı daha yüksektir.
Kimlik Kaynağı — Yetkili kaynak kimdir?
- Kullanıcı kimliği nerede belirlenir? Hangi sistem yetkili kaynaktır — AD, NAC veya VPN?
- Güvenlik duvarının Kullanıcı Kimliği eşleştirmesini hangi sistemin verileri yönlendirir?
- İki sistem çelişkili kimlik verileri bildirdiğinde, hangisi öncelik kazanır?
IP Yaşam Döngüsü — Eşleme ne zaman bozulur?
- DHCP yenilendiğinde ve bir IP adresi değiştiğinde, Kullanıcı Kimliği eşlemesi otomatik olarak güncellenir mi yoksa manuel düzeltme mi gerekir?
- Wi-Fi dolaşımı sırasında, NAC oturumu yenilemesi ile güvenlik duvarı oturumu güncellemesi arasındaki senkronizasyon zamanlaması garanti edilir mi?
- Bir IP adresi yeniden kullanıldığında, önceki kullanıcının politikasının yeni kullanıcıya uygulanması riski var mıdır?
Politika Modeli — İki sistem farklı diller konuşuyor.
- NAC rolü değiştiğinde güvenlik duvarı politikası otomatik olarak güncellenir mi, yoksa manuel güncelleme mi gerekir?
- NAC VLAN atamaları ve güvenlik duvarı bölge politikaları uyumlu mu?
İstisna Yönetimi — İstisnalar birikir ve politikayı aşındırır.
- NAC istisna politikaları ne sıklıkla uygulanır? İstisna sayısı ne kadar fazla olursa, etkili politika kapsamı o kadar zayıflar.
- İstisna politikaları güvenlik duvarı politikasıyla çelişir mi?
Olay Müdahalesi — Uygulama yetkisi nerede bulunur?
- Bir uç nokta karantinaya alındığında, yetkili kontrol hangi sistemdedir: NAC mi yoksa güvenlik duvarı mı?
- NAC karantina ve güvenlik duvarı engelleme politikası aynı anda etkinleştiğinde, çakışma riski var mıdır?
Bunlar teknoloji soruları değil, operasyonel yapı sorularıdır. Ve bunların çoğu tek bir konuda birleşiyor: Kimlik kaynağı nerede bulunuyor ve her iki sistem de bu bilgiyi gerçek zamanlı olarak nasıl paylaşıyor?
SONUÇ
Palo Alto’nun kendi NAC’sini kurmama kararı, alanların rasyonel bir şekilde bölünmesini yansıtıyor. Dört iş ortağı için resmi TechDocs entegrasyon kılavuzları teknik olarak iyi yapılandırılmış. Ancak üretimde biriken XSOAR bağımlılığı, kimlik eşleme kayması, politika modeli uyumsuzluğu ve satıcı başına operasyonel ek yük bu belgelerde görünmüyor. Bu sorunlar herhangi bir ürünün yetersizliğinden kaynaklanmıyor. İki sistemin farklı veri modelleri üzerinde çalışması ve oturum durumunu bağımsız olarak yönetmesi ve entegrasyon zincirinin çok fazla hareketli parçaya sahip olması nedeniyle ortaya çıkıyorlar.
Ve NAC’nin amacı -ağa bağlanan her cihazda politikayı belirlemek ve uygulamak – ortamda ajan çalıştıramayan cihazlar olduğu sürece 2026’da da geçerliliğini koruyacaktır.
Asıl soru hangi NAC’yi seçeceğimiz değil. Asıl soru, Kimlik, Politika ve Yürütmeyi üretim ortamında gerçekten işe yarayacak ve operasyon ekibinin her gün çalıştığını doğrulayabileceği şekilde nasıl bağlayacağımızdır.
Genian NAC’ın yaklaşımı her ortam için doğru çözüm değildir. Ancak yukarıda açıklanan yapısal sorunlar entegrasyonunuzda tekrar ediyorsa, daha az hareketli parçayla bu sorunları ele alan ve XSOAR’ı aracı olarak gerektirmeden PANW güvenlik duvarı politika uygulamasını güçlendirebilen bir mimari mevcuttur.