Kurumsal ağ ekipleri BGP konuştuğunda çoğu zaman kapasite, failover ve segmentasyon üzerinde durur. Oysa internet kenarı, partner bağlantıları veya çoklu transit senaryolarında başka bir konu daha belirleyicidir: yönlendirme bilgisinin güvenilirliği. Route leak, hatalı origin ilanı veya yanlış prefix kabulü yalnızca operatör problemi değildir; kurumların dış dünya ile kurduğu rota sınırını doğrudan etkiler. Bu yüzden RPKI, sadece servis sağlayıcıların değil, kurumsal mimarilerin de gündemine girmelidir.
RPKI neden kurumsal tarafta önem kazandı?
Çünkü kurumlar artık yalnızca tek uplink kullanan kapalı yapılar değil. SD-WAN çıkışları, bulut direct connect bağlantıları, DDoS temizleme sağlayıcıları, edge servisleri ve partner omurgaları aynı yönlendirme alanına temas ediyor. Bu topolojide bir prefix’in yanlış origin ile kabul edilmesi şu sonuçları doğurabilir:
- Trafiğin istemeden üçüncü tarafa gitmesi
- Dış erişimde kısmi kesinti
- DDoS yönlendirme politikasının bozulması
- Kök neden analizinde saatler süren belirsizlik
RPKI bu problemi tamamen ortadan kaldırmaz; fakat “hangi ASN bu prefix’i ilan etmeye yetkili” sorusunu daha güçlü biçimde cevaplar.
Güven zinciri nasıl işler?
RPKI modelinde prefix sahibi, belirli ASN’lerin o prefix’i origin olarak duyurabileceğini ROA kaydıyla ilan eder. Route validator bu bilgiyi çeker ve yönlendiricilere üç temel sonuç üretir:
- Valid: Prefix ve ASN eşleşmesi doğru
- Invalid: Prefix ilanı ROA ile çelişiyor
- NotFound: Bu prefix için doğrulanabilir kayıt yok
Kurumsal mimaride amaç, özellikle internet kenarında ve kritik partner eBGP oturumlarında bu sonucu politika motoruna bağlamaktır.
Her invalid rota otomatik düşürülmeli mi?
Hayır, özellikle geçiş döneminde dikkat gerekir. Kurumun kendi prefix’leri, bulut sağlayıcı anonsları ve DDoS scrubbing akışları birlikte düşünülmelidir. Ben üç aşamalı modeli daha sağlıklı buluyorum:
- Önce sadece görünürlük: invalid prefix sayısını izle
- Sonra düşük riskli kenarlarda tercih azalt
- En sonunda kritik internet kenarında reddet
Bu geçiş olmadan yapılan sert politika değişikliği, meşru ama eksik ROA tanımı olan yönleri gereksiz yere kesebilir.
Kurumsal topolojide validator nereye konur?
Validator’ı sadece tek bir ağ cihazına yakın düşünmek eksik kalır. Daha iyi model şudur:
- Çift örnekli validator servisi
- Ayrı yönetim segmentinde çalışma
- Router’lara RTR veya eşdeğer protokolle veri sağlama
- Metrik ve alarm entegrasyonu ile görünürlük üretme
Böylece RPKI, tek seferlik güvenlik projesi değil yaşayan bir yönlendirme kontrol katmanına dönüşür. Özellikle farklı veri merkezleri veya hibrit edge yapıları varsa validator erişilebilirliği de tasarımın parçası olmalıdır.
Hangi kurumlar daha hızlı değer görür?
Şu ortamlarda RPKI yatırımının geri dönüşü daha hızlı olur:
- Kendi public ASN ve prefix alanı olan kurumlar
- Birden fazla transit veya upstream kullanan yapılar
- DDoS temizleme servisleriyle trafik yönlendiren ekipler
- Partner, MPLS ve internet kenarını birlikte yöneten ağ organizasyonları
Bu yapılarda route leak kaynaklı belirsizlik operasyonel maliyeti ciddi biçimde artırır. RPKI en azından “yanlış origin” sınıfındaki sorunları daraltır.
Operasyon modeli nasıl olmalı?
Ben bu konuyu ağ, güvenlik ve platform operasyonunun ortak alanı olarak görüyorum. Sağlam bir modelde şunlar net olmalı:
- ROA kayıtlarını kim oluşturur ve kim onaylar?
- Yeni prefix tahsisinde güven zinciri checklist’e dahil mi?
- Invalid rota görüldüğünde olay kime düşer?
- Partner bağlantılarında istisna süreci nasıl yürür?
Bu sorular cevaplanmadan RPKI yalnızca “aktif” görünen ama kimsenin sahiplenmediği bir katman olarak kalır.
Sonuç
Kurumsal ağlarda RPKI ile BGP güven zinciri kurmak, yönlendirmeyi tamamen güvenli hâle getirmez; fakat kritik bir doğrulama katmanı ekler. Route leak, yanlış origin ve hatalı prefix kabulü gibi sorunlar büyümeden görünür olur. Çoklu edge, hibrit bulut ve partner bağlantıları bulunan yapılarda bu görünürlük doğrudan operasyon kalitesi üretir. Modern ağ mimarisinde güven yalnızca ACL ve firewall ile değil, rotanın kendisini doğrulama disipliniyle de kurulur.