Kurumsal Ağlarda 802.1X (NAC) Pilotundan Üretime Geçiş

802.1X (NAC) çoğu kurumda “güvenlik projesi” diye başlar, ilk gerçek bakımda “operasyon krizi”ne dönüşür. Bunun sebebi teknoloji değil; kimlik ve istisnaları yönetme biçimidir. Üretimde NAC; bir “port kontrolü” değil, ağa girişin kimlik bazlı sözleşmesidir.

NAC’i doğru çerçevele: hedef “%100 bloke” değil, “kanıtlı erişim”

İyi bir NAC programının ilk çıktısı şudur: “Bu porta bağlı cihaz kim?” sorusuna kanıtlı cevap. İkinci çıktı ise: “Bu cihazın erişmesi gereken yerler neresi?” sorusuna politikayla cevap.

Bu yüzden hedefi şöyle koymak daha doğru:

• İlk 2–4 hafta: görünürlük (kim, nereden, neyle bağlandı?)
• Sonra: aşamalı yetkilendirme (rol/VLAN/ACL)
• En son: kapatma (uygunsuz erişimi gerçek anlamda durdurma)

Minimum mimari: dört parça ve bir operasyon sözleşmesi

802.1X’i üretime taşımak için en az şu parçaları netleştir:

1. Supplicant: İstemci tarafı (Windows/macOS/Linux, MDM ile yönetim)
2. Authenticator: Switch/AP (port davranışı, fallback, zaman aşımı)
3. AAA: RADIUS (authN) + politika (authZ)
4. Identity kaynakları: AD/Entra, cihaz sertifikası, MDM envanteri

Beşinci ve en kritik parça ise teknik değil:

• İstisna sözleşmesi: Kim ister, kim onaylar, ne kadar süreyle, hangi kanıtla?

Pilot tasarımı: “kolay segment” seçmek yerine “en çok öğrenilen segment” seç

Pilot için en iyi alan genelde “az riskli” değil, hata sınıflarını erken yakalayan alandır. Ben pratikte şu sırayı öneriyorum:

1. Kurumsal kullanıcı VLAN’ı (managed device yoğun)
2. Ofis Wi‑Fi (misafir/IoT istisnaları daha görünür)
3. Yönetim ağı (en kritik, en son)

Pilot başlamadan önce yazılı hale getir:

• Başarı kriteri: ör. “%95 managed cihaz EAP‑TLS ile”
• İstisna sınıfları: yazıcı/IoT/konuk/legacy
• Geri dönüş: “tek komutla açık moda dönüş” ve süre hedefi (örn. 5 dk)

Kimlik stratejisi: EAP‑TLS mümkünse standardın olsun

Şu üç model sahada görülür:

• EAP‑TLS (sertifika): en güçlü, ama PKI/MDM disiplini ister
• PEAP/MSCHAPv2 (kullanıcı şifresi): hızlı başlar, kimlik hırsızlığı riski daha yüksektir
• MAB (MAC bypass): “legacy kaçış” olarak sınırlı tutulmalı

Eğer MDM’in varsa, orta vadede EAP‑TLS’e dönmek en az sürtünmeli yoldur. Çünkü parola değişimi veya kullanıcı davranışı, NAC’i sürekli sarsar; sertifika ise cihaz yaşam döngüsüyle daha iyi eşleşir.

Politika modeli: VLAN’la başla, rol/ACL’e doğru evril

İlk üretim dalgasında her şeyi “mikro-segmente” etmeye çalışmak, politikayı yönetilemez hale getirir. Başlangıç için iki güvenli kalıp:

• Managed → Kurumsal erişim VLAN’ı + temel ACL
• Unknown/Guest → Karantina VLAN’ı + captive portal/limitli çıkış

Sonra adım adım:

• Cihaz sınıfına göre rol (laptop, BYOD, printer, IoT)
• Uygulama/servis bazlı kısıt (DNS/NTP/Proxy zorunluluğu gibi)

En kritik operasyon senaryosu: RADIUS/politika kesintisi

802.1X’in “en pahalı incident” sınıfı, yanlış politika değil; AAA tarafının erişilememesidir. Bu yüzden switch port davranışını tasarımın parçası yap:

• Fail-open: erişim sürer, denetim düşer (bazı alanlar için kabul edilebilir)
• Fail-closed: erişim kesilir, güvenlik artar (kritik olmayan alanlarda felaket)

Benim önerim: üretimde tek karar verme.

• Kullanıcı VLAN’larında kontrollü fail-open + güçlü loglama
• Yönetim/crit segmentlerde fail-closed + ayrı out-of-band erişim

İzleme ve ölçüm: NAC’i SIEM’e değil, önce operasyon paneline bağla

Minimum metrik seti:

• Auth başarı/ret oranı (site, switch, port bazlı)
• Ret nedenleri dağılımı (sertifika, EAP, timeout, policy)
• RADIUS latency ve timeout oranı
• İstisna sayısı + yaşlanma (30/60/90 gün)

Bu metrikleri “güvenlik raporu” değil, NetOps/IT Ops paneli olarak kurgularsan, olay anında teşhis süresi dramatik düşer.

Runbook: iki kısa karar ağacı yaz

1) “Toplu bağlantı kesildi” alarmı

1. Aynı anda kaç port etkilenmiş? (tek switch mi, çoklu site mı)
2. RADIUS erişilebilir mi? (healthcheck + latency)
3. Politika değişikliği var mı? (son 30 dk değişiklik günlüğü)
4. Geri dönüş: ilgili template’de NAC’i geçici bypass et (süreli)

2) “Bazı cihazlar bağlanamıyor”

1. Cihaz managed mı? sertifika var mı?
2. Saat drift var mı? (NTP)
3. Supplicant profili doğru mu? (MDM policy)
4. İstisna mı? (IoT/wireless printer)

Sonuç

802.1X/NAC; “ağa kim giriyor?” sorusunu kanıtlı hale getirir, ama yalnızca pilot → politika → istisna → runbook zinciri birlikte tasarlanırsa. Benim sahada gördüğüm en sağlam yaklaşım, önce görünürlük ve istisna disiplini kurmak; sonra kademeli olarak rol/ACL sıkılaştırmak. Böylece NAC, bir gün açılıp unutulan bir özellik değil; operasyonel gerçekliğe uyumlu yaşayan bir kontrol düzlemi olur.