802.1X Projeleri: Kimliği Ağa Taşıyan Mimariyi Sahada Kurmak

802.1X projeleri dışarıdan bakınca network işi gibi görünür; çünkü dokunulan yer switch portlarıdır, SSID’lerdir, RADIUS’tur. Ama gerçek hayatta 802.1X’in başarısı çoğu zaman network cihazlarının üzerinde değil; Active Directory düzeninde, sertifika altyapısında (PKI) ve uç cihaz yönetiminde belirlenir. Bunun nedeni basit: 802.1X, portun VLAN’ını değil, kurumun “kimlik modelini” konuşmaya zorlar. Yani “hangi port hangi VLAN”dan, “hangi kimlik hangi yetkiyle ağa girer” düzenine geçersin.

Bu geçiş, bir kurumun alışkanlıklarını değiştirir. Çünkü 802.1X devreye girdiğinde network, artık “kablo takınca çalışan” bir şey olmaktan çıkar; doğrulama geçemeyen cihaz için karantina, misafir için portal, yanlış OU’da duran bilgisayar için yanlış VLAN gibi sonuçlar üretir. Bu yüzden ben 802.1X’i bir özellik olarak değil, kurumsal bir yetkinlik olarak görüyorum: kimlik, envanter, politika ve operasyonun aynı masaya oturduğu bir yetkinlik.

Özet (sadece kilit):

• 802.1X port güvenliği değil, kimlik mimarisidir.
• Başarı network’ten çok AD/PKI/endpoint disiplinine bağlıdır.

1) Planlama: VLAN planı yoksa 802.1X “kural motoru” değil “kaos motoru” olur

802.1X’e geçerken herkesin ilk refleksi şudur: “RADIUS kurarız, switch’e yazarız, biter.” Sahada bunun bittiği yer genelde ilk pilot kullanıcıdır. Çünkü pilot kullanıcı bağlanır ve bir anda şu soru çıkar: “Bu kullanıcı hangi VLAN’a gidecek?” İşte 802.1X’in seni zorladığı yer burasıdır.

Eğer kurumda anlamlı bir VLAN/segmentasyon planı yoksa, 802.1X devreye alındığında bütün eksikler görünür hale gelir. Muhasebe ile üretim aynı segmentteyse, kamera ile kullanıcı laptop’u aynı ağdaysa, printer VLAN’ı diye bir kavram hiç yoksa; 802.1X bu yapıyı “otomatikleştiremez”, sadece “otomatik şekilde yanlış” yapar.

Bu yüzden proje başlamadan önce kullanıcı ve cihazları “sınıflara” ayırmak gerekir: departmanlar (muhasebe, finans, HR…), cihaz tipleri (printer, IP phone, camera, badge reader…), sunucu segmentleri (AD/DC, file, mail, web/DMZ), misafir segmenti, karantina segmenti. Bu segmentler yalnızca IP planı değildir; aynı zamanda erişim politikasının zeminidir. Örneğin muhasebe VLAN’ındaki kullanıcı sadece muhasebe uygulamalarına ve ilgili dosya alanlarına erişmeli; internet erişimi bile şirket politikasına göre ayrışmalıdır. HR sosyal medyaya erişebilirken finans erişmeyebilir. Bunlar 802.1X’ten sonra “sonradan düşünülürse”, proje bitmez.

Özet:

• VLAN planı = politika planı.
• 802.1X, segmentasyon kararını “ertelenemez” hale getirir.

2) Network hazırlığı: 802.1X devreye girmeden önce her VLAN manuel çalışmalı

802.1X’e geçmeden önce VLAN’ların switch ve firewall üzerinde tanımlı olması yetmez; manual test edilmesi gerekir. Çünkü 802.1X devreye girdiğinde sorun çıktığında kök nedeni ayırmak zorlaşır: VLAN mı yanlış, firewall kuralı mı eksik, RADIUS mu yanlış, sertifika mı bozuk?

Benim sahada en çok önerdiğim akış şu: VLAN’ları oluştur, routing ve firewall kurallarını oturt, sonra bir test portunu statik VLAN’a al ve bir kullanıcıyla “olması gereken erişim” testlerini yap. Muhasebe VLAN’ı oluşturduysan, muhasebe uygulamasına erişim var mı? File share yetkileri doğru mu? İnternet kuralı doğru mu? Bu manuel test geçmeden 802.1X’e geçmek, gözü kapalı araç kullanmak gibi.

Bu aşamada ayrıca management network konusu kritik. Switch’lerin, WLC’nin, AP’lerin yönetim IP’leri ayrı bir management VLAN’da olmalı. 802.1X yanlış VLAN atarsa bile, senin cihazlara erişimin kesilmemeli. “Management VLAN” yoksa, 802.1X pilotu sırasında bile cihaz yönetim erişimini kaybedip çok gereksiz kriz yaşanıyor.

Özet:

• 802.1X’ten önce VLAN + FW kuralları manuel test edilmeden ilerlenmez.
• Management network ayrı değilse, proje gereksiz risk taşır.

3) AD tarafı: OU düzeni olmayan yerde 802.1X hep “istisna yönetimi”ne döner

Şimdi gelelim senin özellikle işaret ettiğin yere: Active Directory OU yapısı. 802.1X projelerinde en kritik noktalardan biri, kullanıcıyı ve bilgisayarı sınıflandırma işinin “nerede” yapıldığıdır. Çoğu kurumda kullanıcılar Users altında, bilgisayarlar Computers altında durur; departman ayrımı ya hiç yoktur ya da “görsel düzen” seviyesindedir. 802.1X devreye girdiğinde bu yapı yetmez. Çünkü sen VLAN atamasını departmana göre yapmak istiyorsan, departman bilgisinin tek bir doğruluk kaynağı olması gerekir.

Benim sahada “best practice” diye gördüğüm yapı şudur: her departman için bir OU yapısı oluşturmak ve kullanıcıyı da bilgisayarı da o OU’nun altında tutmak. Çünkü senin hedefin sadece “kullanıcı kimliği” değil; çoğu zaman “kurumsal cihaz” güveni ve departman segmentasyonu birlikte gelir. Kullanıcı OU=Finance altında ama bilgisayar dağınıksa, GPO dağıtımı bozulur, sertifika auto-enrollment bozulur, 802.1X policy eşleştirme bozulur.

Ama burada kritik bir risk var: OU taşımak “sadece sürükle bırak” değildir. Bir kullanıcıyı OU ağacında başka yere taşımak, o kullanıcıya uygulanan GPO’ları değiştirebilir; login script’leri, drive mapping, uygulama dağıtımı, hatta bazı uygulamaların erişim modeli etkilenebilir. Bu yüzden OU düzeni değişikliği kontrollü yapılmalı.

Benim önerdiğim yöntem: önce tek bir departmandan tek bir pilot kullanıcı ve pilot cihaz seç. OU taşımayı yap. 1 hafta–10 gün gözlemle. Çünkü bazı erişimler günlük işte her gün tetiklenmez; haftalık süreçte görülür. Örneğin ay sonu finans raporları, dönemsel muhasebe işlemleri, özel bir dosya paylaşımı… Bunlar pilot sürede ortaya çıkar. Sorun çıkarsa OU/GPO düzeltmelerini yaparsın, sonra genişlersin.

Özet:

• OU düzeni, 802.1X’in görünmeyen omurgasıdır.
• OU taşıma kontrollü yapılmazsa GPO/erişim yan etkileri doğar.

4) Group Policy: 802.1X projelerinde “tek tek elle ayar” ölçeklenmez

802.1X’i pilotta elle kurarsın; üretime geçince GPO’suz yürüyemezsin. Çünkü işin uç noktası binlerce cihaz olabilir. Wired AutoConfig, WLAN AutoConfig, EAP ayarları, sertifika seçimi, authentication öncelikleri, kullanıcı/cihaz davranışı… Bunları tek tek elle yönetmek hem hataya açık hem sürdürülemez.

Bu yüzden GPO tarafında genelde üç şey yapılır: Birincisi, kablolu 802.1X profillerinin dağıtımıdır. Windows tarafında “Wired Network (IEEE 802.3) Policies” ile EAP türü, auth modu, sertifika seçimi ve doğrulama davranışı merkezi dağıtılır. İkincisi, kablosuz 802.1X profilleridir. “Wireless Network (IEEE 802.11) Policies” ile SSID, güvenlik modu, EAP türü, sertifika gereksinimleri, roaming davranışı gibi ayarlar dağıtılır. Üçüncüsü, sertifika auto-enrollment’ıdır (aşağıda PKI’da daha derin anlatacağım). Sertifika dağıtımını GPO olmadan ölçeklemek gerçekçi değil. Kullanıcı sertifikası, bilgisayar sertifikası, gerektiğinde RADIUS server sertifikası zinciri… hepsi otomatik yönetilmeli.

Burada küçük ama çok kritik bir detay var: “kullanıcı bazlı 802.1X” ile “bilgisayar bazlı 802.1X” aynı anda devredeyken Windows’un hangi sırayla deneyeceği önemlidir. Çoğu tasarımda “önce bilgisayar auth, sonra kullanıcı auth” gibi bir model istenir. Çünkü cihaz domain’e üye ise önce cihaz doğrulansın, login ekranı gelsin, sonra kullanıcı login olunca yetkiler genişlesin. Bu model hem güvenlik hem operasyon açısından iyi çalışır—ama GPO’da yanlış ayarlanırsa tam tersini yapıp çok tuhaf sorunlar üretir.

Özet:

• GPO olmadan 802.1X üretime taşınmaz.
• Auth sırası (machine vs user) sahada fark yaratır.

5) RADIUS / NPS / NAC: “konuşuyor” yetmez; hangi cevabı verdiği önemlidir

RADIUS tarafı çoğu ekipte “Switch’i tanıttık, secret verdik, oldu” gibi görülür. Bu sadece iletişimin başladığı yerdir. Asıl konu şudur: RADIUS, switch’e hangi VLAN / hangi ACL / hangi policy cevabını veriyor?

Burada iki dünya var:

• Basit dünyada RADIUS sadece “accept/reject” döner, VLAN statik kalır.
• Olgun dünyada RADIUS “accept” ile birlikte dinamik VLAN atar, dACL/ACL iter, hatta bazı vendor özellikleriyle port davranışını değiştirir.

NPS ile de dinamik VLAN yapılır; Cisco ISE/ClearPass gibi sistemlerde ise çok daha esnek politika motoru kurarsın. Ama prensip aynı: Kimlik ve cihaz bilgisi → politika → switch’e geri dönen enforcement.

Bu aşamada sahada sık yapılan bir hata: network cihazlarını RADIUS client olarak tanımlarken management IP yerine farklı IP’ler kullanmak, yanlış VRF/route yüzünden RADIUS’a erişememek, source-interface yanlışlığı… Sonra “802.1X çalışmıyor” deniyor; halbuki RADIUS’a paket gitmiyor. Bu yüzden ben her projede önce en basit testle başlarım: switch’ten RADIUS’a reachability, RADIUS’ta log, sonra bir test port.

Bir de şu kritik ayrım var (sen de değinmiştin): RADIUS sadece uç kullanıcı doğrulamak için kullanılmaz; network cihazlarına admin login için de kullanılabilir (TACACS+ daha uygundur ama bazı yapılarda RADIUS da görülür). Bu iki use-case karışırsa yanlış policy’ler yanlış yere uygulanır. Bu yazının odağı uç erişim olduğu için, “device admin AAA” konusunu ayrı tutmak gerekir.

Özet:

• RADIUS “iletişim kurdu” diye proje bitmez; “hangi policy cevabı dönüyor” önemlidir.
• Reachability/source-interface/VRF hataları en klasik kök nedendir.

6) EAP yöntemleri: PEAP mi, EAP-TLS mi, Computer mı User mı?

Şimdi senin ham metnindeki en kritik teknik parçaya geliyorum: “Hangi doğrulama modeli?”

PEAP (kullanıcı adı/şifre) neden pratik ama riskli PEAP kolaydır: kullanıcı domain hesabıyla bağlanır. Ancak sahada ciddi bir açık üretir: kullanıcı kendi kişisel laptop’undan veya telefonundan da aynı kullanıcı adı/şifreyle ağa girebilir. “Ben zaten kullanıcıyı tanıyorum” düşüncesi bu noktada yetersiz kalır; çünkü Zero Trust mantığında hedef, sadece kullanıcıyı değil cihazı da doğrulamaktır. Bu yüzden PEAP ile başlayan projeler genelde “güvenlik hedefi yüksekse” bir süre sonra TLS’e evrilir.

Computer authentication neden iyi ama bazı organizasyonlarda can yakar Bilgisayar doğrulaması, cihazı domain’e bağlamayı şart koşar. Bu, kişisel cihazları doğal olarak engeller. Ancak ortak bilgisayar kullanılan yerlerde (güvenlik birimi, sevkiyat, kiosk cihazları vb.) kullanıcı bazlı segmentasyon istiyorsan tek başına yeterli olmaz. Çünkü aynı cihaz farklı kullanıcılarla aynı segmentte kalır.

EAP-TLS (sertifika) neden “en doğru” ama neden disiplin ister EAP-TLS’de kimlik, sertifikayla gelir. Bu hem kullanıcı bazlı hem bilgisayar bazlı yapılabilir. Güçlü tarafı şudur: şifre sızsa bile sertifika yoksa erişim yoktur. Zayıf tarafı ise disiplin gerektirmesidir: PKI’nın ayakta durması, template’lerin doğru olması, auto-enrollment’ın doğru işlemesi, CRL/OCSP erişiminin sağlıklı olması gibi konular devreye girer.

Senin ham metnindeki önemli bir tavsiye vardı: sertifikanın içinde departman/OU gibi anlamlı bilgi olsun. Bu gerçekten sahada fark yaratır. Çünkü politika motorunda “Finance OU → Finance VLAN” gibi eşleştirmeler yapmak istediğinde sertifika içeriği işini kolaylaştırır. Yanlış içerik, seni tekrar “manuel mapping” dünyasına iter.

Özet:

• PEAP pratik ama “kurumsal cihaz” güveni zayıf kalır.
• Computer auth güçlü ama ortak PC senaryolarında sınırlıdır.
• EAP-TLS en güvenlisi; PKI disiplini şarttır.

7) PKI ve Certificate Template’ler: 802.1X’in sessiz kırılma noktası

Şimdi senin özellikle “baya eksik” dediğin yere giriyorum: Certificate Template, sertifikanın dağıtımı ve RADIUS’un sertifika doğrulaması.

EAP-TLS tasarlıyorsan, Windows Certificate Services (AD CS) üzerinde en az iki şey düşünmek zorundasın:

1. İstemci sertifikaları: (User certificate, Computer certificate)
2. RADIUS server’ın (NPS/ISE/ClearPass) sunacağı server certificate

İstemci sertifikalarının dağıtımı çoğu yapıda auto-enrollment ile yapılır. Bunun için AD CS’de uygun template hazırlanır, ilgili template “Enroll/Autoenroll” yetkileri doğru gruplara verilir, sonra GPO ile auto-enrollment aktif edilir. Burada sahada en sık görülen hata: template hazırlanır ama güvenlik izinleri yanlış olduğu için kullanıcı/cihaz sertifika alamaz; ya da alır ama yanlış EKU/KeyUsage yüzünden EAP-TLS’de kullanılamaz.

Template tarafında dikkat edilmesi gerekenlerden bazıları şunlar:

• Sertifikanın “Client Authentication” amaçlı kullanılabilmesi
• Anahtarın export edilebilir olup olmaması (genelde istenmez)
• Subject/SAN alanının nasıl üretileceği
• Kullanıcı mı cihaz mı için üretildiği
• Geçerlilik süresi ve yenileme davranışı
• CRL erişimi (offline kalırsa doğrulama patlar)

Senin ham metninde çok doğru bir parça vardı: sertifikaya departman/organizasyon bilgisi koymak. Bu, doğrudan OU’yu sertifikaya gömmek demek değil; ama subject/SAN içinde anlamlı bir naming standardı taşımak, NAC tarafında mapping’i güçlendirir. Birçok kurum bunu yapmadığı için sonra “bu sertifika kimindi?” sorusuna loglardan cevap arar.

RADIUS tarafına gelirsek: NPS (veya NAC) istemciye bir server certificate sunar. İstemci bu sertifikaya güvenmezse “man-in-the-middle” gibi algılar ve bağlanmaz. Bu yüzden RADIUS server sertifikasının zinciri (CA) istemciye güvenilir olarak dağıtılmalıdır. Bunun pratik yolu yine AD/GPO’dur: Root CA ve intermediate CA’ları GPO ile “Trusted Root Certification Authorities” alanına basarsın.

Bir de ters yön var: NPS, istemcinin sunduğu sertifikayı doğrularırken CRL kontrolü yapmak isteyebilir. CRL erişimi bozuksa, sertifika doğru olsa bile doğrulama gecikir veya fail olur. Bu detay sahada “arada bağlanmıyor” gibi sinir bozucu problemlerin klasik sebebidir.

Özet:

• Template izinleri/amaçları yanlışsa TLS biter.
• Auto-enrollment + CA trust dağıtimi GPO ile standardize edilmelidir.
• CRL erişimi bir gün patlayınca herkes “802.1X bozuldu” sanır.

8) Switch portunda Dot1X ve MAB birlikte: sıranın doğru yazılması gerçek hayatı kurtarır

Senin ham metnindeki bir başka kritik detay: switch üzerinde genelde iki temel yöntem vardır: dot1x ve MAB (MAC Authentication Bypass). Sahada en yaygın ve en mantıklı model şudur: önce dot1x dene; dot1x fail olursa MAB’a düş. Çünkü laptop gibi akıllı uçlar 802.1X yapabilsin; printer/kamera gibi akıllı olmayanlar MAB ile yürüsün.

Burada küçük bir konfigürasyon tercihi bile sahada büyük fark yaratır: MAB’ı yanlış önceliklendirdiğinde, domain’e bağlı laptop bile MAB ile bağlanıp yanlış VLAN’a düşebilir; ya da tam tersi, printer dot1x denediği için uzun süre bekleyip kullanıcıya “network yok” hissi verebilir. Bu yüzden port konfigürasyonunda authentication order ve event davranışları (fail-open/fail-close) bilinçli seçilmelidir.

Ayrıca “tek tek port bazlı ilerlemek” yaklaşımını tekrar vurguluyorum: 20 switch, yüzlerce port olan yerde, her portu bir günde 802.1X’e almak çok cazip gelir ama projeyi çökertebilir. Benim sahada gördüğüm en iyi yöntem: departman departman ilerlemek; her departmanda önce 1–2 pilot kullanıcı, 1 hafta gözlem, sonra genişleme.

Özet:

• Dot1X → fail olursa MAB sırası çoğu ortam için en sağlıklısıdır.
• Port bazlı kontrollü rollout, “bir günde geçiş”ten daha hızlı bitirir.

9) Profiling: “sadece MAC” dönemi bitti

MAC authentication, tek başına artık yeterli güvenlik değildir. Çünkü modern cihazlar MAC randomization yapabiliyor; bir MAC adresini kopyalamak kolay. Bu yüzden gelişmiş NAC çözümleri profiling yapar. Senin ham metnindeki örnekler doğru: OUI kontrolü, DHCP fingerprint, CDP/LLDP, cihaz açıklaması, hatta bazı ortamlarda HTTP User-Agent gibi ipuçları birlikte değerlendirilir.

Örneğin bir IP telefonu doğrularken sadece MAC’in ilk 6 hanesine bakmak yerine; CDP’de “Cisco Phone” ibaresi var mı, LLDP’de model bilgisi geliyor mu, DHCP fingerprint telefona benziyor mu… Bu sinyalleri birleştirince “bu gerçekten telefon mu?” sorusuna daha güvenilir cevap verirsin. Aynı mantık printer için de geçerlidir. Böylece sahte cihazın “ben printerım” diyerek MAB üzerinden VLAN alması zorlaşır.

Özet:

• MAC tek başına kimlik değildir; profiling kimliğe yaklaşır.
• Birden fazla sinyal kullanmak sahadaki suistimali azaltır.

10) Quarantine VLAN ve Guest VLAN: ikisi aynı şey değil

Bu ayrımı sahada çok az ekip doğru kuruyor.

Quarantine: şirketin cihazı/hesabı var ama doğrulamadan geçemiyor. Şifre expire olmuş olabilir, sertifika süresi dolmuş olabilir, cihaz domain’e bağlı ama policy dışı kalmış olabilir. Karantina VLAN’ın amacı, cihazı “tamamen kesmek” değil; problemi çözebileceği minimum erişimi vermektir. Örneğin AD’ye/CA’ya erişsin, şifre değiştirsin, belki güncelleme alsın.

Guest: şirketin cihazı değil. Domain ile ilgisi yok. Burada genelde sadece internete izin verirsin; AD/kerberos/LDAP gibi iç kaynaklara erişim hiç gereksizdir. Guest’in doğası gereği politika daha “kısıtlı ama kullanıcı dostu” olmalıdır.

Senin ham metnindeki kablolu/kablosuz farkı da önemli: kablolu tarafta karantina VLAN mantığı rahat uygulanır (port VLAN değiştirir). Kablosuz tarafta bazı tasarımlarda karantina VLAN yerine “bağlanmayı reddetme” daha sık görülür; çünkü WLAN policy modeli farklıdır. Ama ben yine de mümkünse kablosuzda da “remediation” yaklaşımı olan tasarımları severim—kullanıcıyı tamamen duvara çarptırmak yerine, sorunu çözebileceği kontrollü bir ağa almak operasyonu hızlandırır.

Özet:

• Quarantine “bizim ama sorunlu”; Guest “bizden değil”.
• İkisini aynı VLAN’a koymak pratikte güvenlik ve operasyonu bozar.

11) Guest portal: sponsor login, SMS, sosyal login ve MAC randomization gerçeği

Guest portal’lar pratikte üç işe yarar: misafiri tanımak, süre vermek, kayıt tutmak. Sponsor login yaklaşımı özellikle kurumsal yapılarda çok işe yarar: misafir “kimi ziyaret ediyorum” der; sistem AD’den o kişiyi bulur; onay maili/push gider; onaylanınca misafir internete çıkar. Bu hem iz bırakır hem de “açık Wi-Fi” hissini ortadan kaldırır.

Ama burada senin ham metnindeki çok önemli bir saha gerçeği var: guest portal’lar çoğu zaman cihazı MAC adresi ile tanır. Modern telefonlar Wi-Fi’de MAC randomization yaptığında, kullanıcı Wi-Fi’yi kapatıp açınca cihaz “yeni cihaz” gibi görünebilir ve tekrar doğrulama ister. Bu kullanıcı deneyimini bozar. Bu yüzden guest tasarımında süreler, portal davranışı ve kullanıcı bilgilendirmesi iyi planlanmalıdır. Aksi halde helpdesk’e “internet gitti” çağrısı yağar.

Özet:

• Portal modeli güvenlik kadar UX tasarımıdır.
• MAC randomization misafir akışını bozabilir; buna göre tasarlanmalıdır.

12) Posture: 802.1X’in “son kalesi” ama yanlış kurarsan operasyonu yorar

Şimdi özellikle istediğin o “Posture için ayrı paragraf” meselesini derin anlatıyorum.

Posture, basitçe şudur: kullanıcı/cihaz kimliği doğru olsa bile, cihazın güvenlik durumu uygun değilse erişimi sınırlamak. Yani “kimsin?” sorusunun yanına “sağlıklı mısın?” sorusunu eklemek. Bu yaklaşım özellikle uzaktan gelen cihazlarda, uzun süre güncelleme almamış laptop’larda, AV kapalı cihazlarda çok değerlidir.

Posture kontrolünde tipik olarak şunlar sorgulanır: OS versiyonu, patch seviyesi, disk encryption durumu, AV var mı ve güncel mi, EDR agent çalışıyor mu, belirli servisler açık mı, registry’de belirli değerler var mı, belirli dosya/klasör mevcut mu. Bu kontrollerin sahada değerli olmasının sebebi, kurumsal cihazların “zamanla drift etmesi”dir. İnsanlar güncellemeyi kapatır, ajanı durdurur, AV lisansı bozulur, cihaz haftalarca VPN görmez. Bu drift’i yakalamazsan, kimliği doğru olan ama güvenliği zayıf cihazları içeri alırsın.

Ama posture’un bir bedeli var: çoğu zaman endpoint üzerinde bir agent gerekir. Yeni agent demek; performans yükü, uyumluluk riski, kullanıcı şikayeti, deployment operasyonu demektir. Bu yüzden ben senin ham metnindeki yaklaşımı doğru buluyorum: mümkünse “yeni agent” eklemek yerine, zaten kurulu olan ajanları reuse etmek.

Örnekler sahada çok net: Cisco ortamında AnyConnect (Secure Client) zaten VPN için kuruluysa, posture modülüyle NAC entegrasyonu yapılabilir. Fortinet tarafında FortiClient benzer şekilde hem VPN hem posture bileşeni olarak kullanılabilir. Bazı yapılarda Trellix gibi EDR/AV ajanları zaten her cihazda vardır; NAC çözümü bunlarla entegre olup posture sinyalini buradan çekebilir. Ama burada kritik nokta şu: entegrasyon “var” diye posture otomatik “doğru” olmaz. Hangi sinyalin güvenilir olduğu, neyin “compliant” sayılacağı, hangi durumda quarantine’e düşeceği net tanımlanmalıdır. Aksi halde posture, güvenliği artırmak yerine operasyonu boğar: yanlış pozitifler, gereksiz karantinalar, sürekli ticket.

Posture tasarımında benim en çok önerdiğim pratik yaklaşım şudur: posture’u ilk aşamada “deny” mekanizması olarak değil, “gözlem ve raporlama” mekanizması olarak başlat. Yani önce posture verisini topla, kaç cihaz non-compliant çıkıyor gör, sonra kuralları kademeli sıkılaştır. İlk günden “AV güncel değilse deny” dersen, özellikle büyük yapılarda sabah herkesin işini durdurabilirsin. Posture, bir günde değil, bir süreçte olgunlaşır.

Özet:

• Posture “kimlik + sağlık” kontrolüdür; drift’i yakalar.
• Yeni agent maliyetlidir; mevcut agent’ları reuse etmek akıllıcadır.
• İlk gün deny değil; önce ölç, sonra sıkılaştır.

13) Temel 802.1X → Profiling/Portal → Posture: olgunluk seviyeleri

Sen ham metinde bunu sınıflandırmıştın; ben de aynı mantığı koruyorum ama anlatımlı şekilde:

Bazı kurumlar için hedef sadece **“802.1X çalışsın”**dır. Basit dot1x/MAB ile başlarlar; Windows NPS yeter. Bu model düşük maliyetli ama yetenekleri sınırlıdır. Bir üst seviyede, profiling ve guest portal gibi ihtiyaçlar gelir. Burada artık NPS tek başına yetmez; Cisco ISE, Aruba ClearPass gibi çözümler devreye girer. Bu seviyede iş sadece auth değil, **“cihazı tanıma ve misafiri yönetme”**ye döner. Daha üst seviyede posture gelir. Bu seviye, en çok güvenlik getirisi olan ama operasyonel maliyeti de en yüksek seviyedir. Bu yüzden posture’u seçerken organizasyonun endpoint yönetim kabiliyeti, agent stratejisi ve helpdesk kapasitesi gerçekçi değerlendirilmelidir.

Özet:

• Seviye 1: Dot1X + MAB (NPS ile olur)
• Seviye 2: Profiling + Guest (NAC şart)
• Seviye 3: Posture (agent/entegrasyon + olgun operasyon şart)

Kapanış: 802.1X “kurulum” değil, kurum içi sözleşmedir

802.1X projeleri teknik olarak switch’te birkaç komut, RADIUS’ta birkaç policy gibi görünebilir. Ama gerçekte 802.1X, kurum içinde şu sözleşmeyi zorunlu kılar: “Kimlik nasıl taşınır, cihaz nasıl tanınır, misafir nasıl yönetilir, sorunlu cihaz nereye düşer, güvenlik hangi noktada başlar?” Bu sözleşme yoksa, proje bir noktada istisnalarla delinir ve sonunda herkes 802.1X’i suçlar.

Benim sahada gördüğüm iyi projeler, en baştan şunu kabul eden projelerdir: 802.1X’in başarısı cihazların gücünden çok, AD düzeninin, GPO disiplininin, PKI yönetiminin ve kademeli rollout kültürünün toplamıdır. 802.1X’i böyle ele aldığında, sadece güvenliği artırmazsın; operasyonu da merkezileştirirsin. Ve asıl kazanç burada başlar.