İçeriğe Atla
Teknoloji · 11 dk okuma · görüntülenme
100%

Kurumsal Ağlarda MACsec ile L2 Şifreleme

MACsec (802.1AE) ile L2 bağlantıları şifreleyerek kampüs ve veri merkezi omurgasında güvenliği artırmak: tasarım kararları, riskler ve işletim.

Switch bağlantıları üzerinde MACsec şifreleme ve kilit simgesini gösteren kapak görseli

Kampüs omurgasında, veri merkezi leaf–spine uplink’lerinde veya DCI hatlarında güvenlik konuşulduğunda refleks genelde “IPsec yapalım” olur. IPsec çok güçlüdür; ama her zaman doğru katman değildir. Bazı senaryolarda en doğru hamle, trafiği routed katmana taşımadan önce, L2 link’i güvence altına almaktır.

Bu yazıda MACsec’i (IEEE 802.1AE) “broşür özelliği” gibi değil, operasyonel olarak işletilebilir bir mimari bileşen gibi ele alıyorum.

Switch bağlantıları üzerinde MACsec şifreleme ve kilit simgesini gösteren kapak görseli
MACsec link şifrelemesidir: uçtan uca değil, hop-by-hop güvence sağlar.

MACsec neyi çözer, neyi çözmez?

Çözdüğü:

  • Aynı L2 link üzerinde dinleme (sniffing) ve “tapped fiber” riskine karşı şifreleme
  • Link üzerindeki frame’lerin bütünlüğü (integrity) ve kimlik doğrulama (auth) ihtiyacı
  • Bazı compliance senaryolarında “in-flight encryption” gereksinimi

Çözmediği:

  • Uçtan uca uygulama güvenliği (TLS gibi) yerine geçmez
  • “Bir switch’ten diğerine kadar” korur; network’teki her hop için ayrıca plan gerekir
  • Yanlış topolojide, yanlış yerde açılırsa daha çok karmaşa üretir (özellikle VLAN trunk ve LACP tarafında)

Nerede en çok değer üretir?

Ben sahada MACsec’i en çok şu üç yerde görüyorum:

  1. Kampüs backbone / bina arası uplink’ler
    Fiziksel erişim riski yüksektir. “Birileri patch panel’e dokunabilir mi?” sorusu önemlidir.

  2. Veri merkezi içinde kritik uplink’ler
    Özellikle ortak servislerin geçtiği leaf–spine uplink’leri veya kritik L2 interconnect.

  3. DCI / Metro-Ethernet gibi L2 taşıyıcı hatlar
    Taşıyıcı “şifreli” diyebilir; ama operasyonel güven, ölçülebilir ve denetlenebilir olmalıdır.

MACsec mi IPsec mi? Kısa karar tablosu

  • Trafik L3 üstünden gidiyor, overlay/tunnel dünyasındasınız → IPsec daha doğal
  • L2/ethernet taşıyorsunuz, “link’i korumak” istiyorsunuz → MACsec
  • Çok hop var, uçtan uca kriptografi istiyorsunuz → MACsec tek başına yetmez (TLS/IPsec/overlay)
  • Donanım offload ve düşük gecikme kritik → MACsec genelde daha “hat üzeri” çalışır (platforma göre değişir)

Tasarım: “hangi link’ler, hangi etki alanı?”

MACsec’i yaygınlaştırırken ilk karar kapsamdır:

  • Sadece uplink’ler mi?
  • Access port’larda istemci–switch link’i mi?
  • DCI gibi “kurum dışı” görünen link’ler mi?

Pratikte başlangıç için en güvenli sıralama:

  1. Omurga uplink’leri (az sayıda, yüksek değer)
  2. DCI gibi hassas link’ler (yüksek risk)
  3. Erişim katmanı (en çok port, en çok operasyon maliyeti)

Anahtar yönetimi: MKA ve operasyon gerçekliği

MACsec şifrelemenin kendisi kadar, anahtarın nasıl yönetileceği de kritiktir.

Genel olarak iki yaklaşım görürsünüz:

  • 802.1X/MKA (MACsec Key Agreement) ile dinamik anahtar yönetimi
    Kurumsal disiplin için iyi; ama RADIUS/AAA bağımlılığı ve tasarım gerektirir.
  • Statik PSK (platforma göre isim değişebilir)
    Hızlı başlatılır; ama ölçek büyüdükçe “anahtar borcu” üretir.

MTU ve performans: görünmez ama can yakan detay

MACsec frame’e ek overhead getirir. Bunun pratik etkileri:

  • Bazı link’lerde efektif MTU düşer → jumbo frame kullanan sistemlerde “gizemli fragmentation” başlar
  • Platforma göre kripto offload var/yok → CPU/ASIC yükü değişir
  • LACP/VLAN trunk üzerinde “bir link şifreli, diğeri değil” gibi yarım durumlar → düzensiz paket kaybı

Başlangıç testleri (laboratuvar veya dar kapsam pilot) şunları içermeli:

  • p95 latency (MACsec açık/kapalı)
  • paket kaybı (özellikle microburst anları)
  • MTU/jumbo akışı (iSCSI/VMotion/backup gibi ağır işler)

Gözlemlenebilirlik: MACsec’i ölçmeden işletmeyin

Minimum izleme seti:

  • MACsec “up/down” ve session state
  • Encrypt/decrypt packet counters
  • ICV (integrity check) failures
  • Replay/packet number hataları
  • Port error/CRC artışı (şifreleme sonrası “maskelenmiş” gibi görünen sorunlar)

Alarm örnekleri:

  • Link up ama MACsec session down (traffic blackhole riski)
  • ICV failure artışı (yanlış anahtar / saldırı / uyumsuzluk)
  • Tek taraf MACsec open, diğer taraf closed (mismatch)

Runbook: “MACsec sonrası trafik gitti” triage

  1. L1/L2: link fiziksel olarak up mı? LACP durumu?
  2. MACsec state: her iki uçta da session up mı?
  3. MTU: jumbo kullanan akışlarda drop artmış mı?
  4. Counters: ICV/replay/PN hataları var mı?
  5. Rollback: Değişiklik penceresinde geri dönüş tek komut mu, yoksa “port reset + config cleanup” mı?

Kapanış

MACsec, doğru yerde kullanıldığında kampüs ve veri merkezi omurgasında “görünmez” bir güvenlik katmanı ekler: link dinleme riskini azaltır, denetlenebilirliği artırır. Yanlış yerde ve plansız açıldığında ise; MTU, key yönetimi ve rollback maliyeti nedeniyle operasyonu zora sokar.

Benim kuralım net: MACsec’i açmadan önce, kapatmayı ve ölçmeyi tasarla.

Paylaş:

Bu yazı faydalı oldu mu?

Yükleniyor...

Bu yazı nasıldı?

ME

Mustafa Erbay

Sistem Mimarisi · Network Uzmanı · Altyapı, Güvenlik ve Yazılım

2006'dan bu yana sistem mimarisi, network, sunucu altyapıları, büyük yapıların kurulumu, yazılım ve sistem güvenliği ekseninde çalışıyorum. Bu blogda sahada karşılığı olan teknik deneyimlerimi paylaşıyorum.

Kişisel Notlar

Bu notlar sadece sizde saklanır. Tarayıcınızda yerel olarak tutulur.

Hazır 0 karakter

Yorumlar

Sunucu Taraflı AI Moderasyon

Yorumlar sunucuda yapay zeka ile denetlenir ve kalıcı olarak saklanır.

?
0/2000

Sunucu taraflı AI denetim

Yeni yazılardan haberdar olun

Haftada bir yeni içerikler ve kaynaklar doğrudan e-postanıza gelsin.

Spam yok. Yalnızca yeni ve önemli içerikler için e-posta gönderilir.

Okuma İstatistikleriniz

0

Yazı Okundu

0dk

Okuma Süresi

0

Gün Serisi

-

Favori Kategori

İlgili Yazılar