Bir saha cihazı internete açık değil. Merkezle özel APN üzerinden haberleşiyor. Peki aynı bağlantı hizmetini kullanan başka bir tesisteki cihaz ele geçirilirse, bizim tesise ulaşılabilir mi?
Bu sorunun cevabı, internetten yaptığımız kontrolde görünmeyebilir. Dışarıya kapalı bir bağlantının içinde, tesisler arasında beklemediğimiz bir yol bulunabilir. Üstelik o yol yalnız ölçüm verisini taşımayabilir; haberleşme cihazının yönetim arayüzüne de çıkabilir.
CERT Polska’nın 2026’da yayımladığı inceleme, bu erişim yolunu gösteriyor.
APN nedir, sahada ne işe yarar?
Merkez → saha telekontrolü / Tesis A → Tesis B yönetimi
Merkezin saha uçlarıyla telekontrol bağlantısı görünür.
APN, Access Point Name: mobil veri bağlantısında kullanılacak ağı tanımlayan ad. SIM’li bir router bağlanırken operatör, aboneliğin izinlerini ve seçilen APN’yi dikkate alarak veri oturumunu ilgili ağa yönlendirir. Telefonda internet için kullandığımız APN de bu fikrin günlük örneği. APN adını bilmek, özel ağa kabul edilmek için tek başına yeterli değildir. Hologram, APN’nin çalışma biçimi
Özel APN hizmetinde operatör, belirlenmiş SIM grubunun trafiğini ayrı bir ağ düzeninde taşıyabilir. Saha router’ları merkeze bu yolla bağlanır. Operatörün SIM kabul kontrolü burada devrededir; bu kontrol, sahadaki uygulamaların kullanıcı yetkilerini denetlemez. Deutsche Telekom, IoT Connectivity Guide, s. 30
Dağınık pompa istasyonlarını, trafo merkezlerini veya enerji üretim sahalarını düşünelim. Her noktaya ayrı sabit hat götürmek yerine, RTU ya da PLC’nin haberleşmesi SIM’li bir router üzerinden taşınabilir. Mobil bağlantı ana hat veya yedek hat olarak tasarlanabilir. Merkez, izin verilen adres ve servisler üzerinden sahayla konuşur.
Şemadaki APN, sahaya yerleştirilmiş bir güvenlik cihazı değil; operatör tarafında tanımlanan bağlantı ve yönlendirme düzenidir. İnternet çıkışı, IP adreslemesi ve uçların birbirine erişimi hizmetin yapılandırmasına bağlıdır. Özel APN kullanılması, bütün saha uçlarının birbirinden yalıtıldığını göstermez. Hologram, özel APN ve bağlantı politikaları
Bu bağlantı şifreli mi?
“Özel APN var” bilgisiyle bu soruyu cevaplayamayız. Hangi bölümün, hangi uçlar arasında korunduğuna bakmalıyız:
| Koruma | Nerede geçerli? | Neyi varsayamayız? |
|---|---|---|
| Mobil radyo şifrelemesi | Etkinse, modem ile baz istasyonu arasındaki hava arayüzünde. | RTU’dan SCADA’ya kadar bütün yolun şifreli olduğunu. |
| Özel APN | Operatörün tanımladığı ağ ayrımı ve yönlendirme kapsamında. | APN’nin kendisinin uçtan uca şifreleme sağladığını. |
| IPsec VPN | Yapılandırılan tünelin iki ucu arasında. | Tünelin dışında kalan saha bağlantılarının da korunduğunu. |
| TLS | TLS kullanan uygulamanın bağlantı uçları arasında. | Aradaki gateway’de sonlanan TLS’nin sonraki bağlantıyı da şifrelediğini. |
Mobil şebekedeki şifrelemenin kapsamı ile uygulamanın kapsamı farklıdır; şebeke nesli, güvenlik ayarları ve tünelin nerede sonlandığı önemlidir. GSMA bu ayrımı hava arayüzü, operatör ağı ve uygulama bağlantısı için ayrı ayrı ele alır. GSMA, IoT bağlantısındaki kriptografi, §4.2
Operatör bu trafiği görebilir mi?
Özel APN’nin taşıma altyapısı operatörün kontrolündedir. Hizmet destekliyorsa, kurumumuzun RADIUS sunucusuyla hangi aboneliklerin APN’ye kabul edileceğine ilişkin karar verebiliriz. RADIUS burada erişim kararının parçasıdır; RTU’nun taşıdığı veriyi şifrelemez. SIM’in mobil şebekede doğrulanmasıyla, kurumsal APN’ye erişim izni de ayrı kontrollerdir. Cisco, kurumsal AAA ve APN eşleştirmesi, s. 9-35–9-36
RTU’dan merkeze giden içerik ayrıca şifrelenmiyorsa, operatör altyapısında trafiğe erişilebilen bir noktada okunabilir. Radyo bağlantısındaki şifreleme, bu içeriği operatörün kendisinden gizlemez. Böyle bir noktadaki ihlal, verinin gizliliğini; ayrıca korunmuyorsa bütünlüğünü de etkileyebilir. Bu yüzden operatörün taşıma ağı da OT güvenlik değerlendirmesindeki güven sınırlarına dahildir.
Operatörden de gizlemek istediğimiz veri, onun ağına girmeden önce şifrelenmeli. Örneğin saha router’ı ile kurumun merkez güvenlik duvarı arasında, uçları ve anahtarları kurumun kontrolünde olan bir IPsec tüneli kurulabilir. Şifreleme, eş kimliğinin doğrulanması ve bütünlük koruması birlikte yapılandırılmalı. Yalnız operatörün gateway’i ile merkez arasında kurulan bir tünel ise, gateway’e kadar gelen içeriği operatörden gizlemez. IETF, IPsec ESP’nin koruma kapsamı, §1 ve §3.1.2
Uygulamanın iki ucunda doğru yapılandırılmış TLS de içerik koruması sağlayabilir. Dolayısıyla gerekli olan, kurumun kontrolündeki uçlar arasında kriptografik korumadır; IPsec bunun bir yoludur. Operatör yine tünel uçlarını, zamanlamayı ve trafik hacmini görebilir. Şifreleme, operatör kaynaklı bağlantı kesintisini de önlemez.
Şifreli bağlantının karşı ucundaki cihaz ele geçirilmişse, hangi cihazlara ve yönetim işlevlerine erişebilir? Tünel, karşı uçtan gelen trafiği güvenle taşıyabilir. O trafiğin başka bir tesisin yönetim arayüzüne gitmesine izin verilip verilmeyeceği ayrıca belirlenir.
Bir rüzgâr sahasından başka bir tesise
CERT Polska’nın 8 Ağustos 2026 tarihli takip raporu, 29 Aralık 2025’te bir kojenerasyon tesisini etkileyen olayı inceliyor. Bulgular, ele geçirilmiş bir rüzgâr sahasındaki erişimin, dağıtım işletmecisinin özel APN’si üzerinden diğer tesise uzandığını gösteriyor.
Rüzgâr sahasında mobil router, RTU’yla seri DNP3 bağlantısı kuruyordu. Buna rağmen router’ın Ethernet yönetim arayüzüne de yerel ağdan erişilebiliyordu. Başka tesisteki WAGO PFC200 kontrolörünün web yönetimi APN tarafından ulaşılabilirdi ve varsayılan yönetici kimlik bilgileri kullanılıyordu. Raporda APN uçları arasında iletişime izin verildiği belirtiliyor. Kayıtlar, yerel OT ağına geçişte büyük olasılıkla SSH tünelleri kullanıldığına işaret ediyor; ilk mobil router’a erişimin nasıl elde edildiği kesinleşmemiş.
Tesis personelinin aktarımına göre PLC’ler STOP durumuna getirildi; buhar türbini ve proses suyu sistemi durdu, kojenerasyon kesildi. Raporun anlattığı şey bir APN şifresinin kırılması değil: erişilmiş bir saha ucundan, diğer ucun yönetimine uzanan bağlantı. CERT Polska, takip raporu, s. 7–11
Mavi bağlantılar merkezin saha uçlarıyla konuşmasını gösteriyor. Kırmızı bağlantı ise bir saha ucundan diğerinin yönetimine uzanıyor. Bunun için APN tarafında ulaşılabilirlik ve hedefte kabul edilen bir yönetim bağlantısı gerekir. Hedefin arkasındaki ağa devam edebilmek de o cihazın bağlantılarına ve tünel, proxy veya yönlendirme yeteneklerine bağlıdır. Aynı APN’de olmak, tek başına her PLC’ye erişim sağlamaz.
Seri telekontrol bağlantısı, Ethernet yönetimini kapatmaz
Otomasyon tarafından baktığımızda “RTU bu hatla seri haberleşiyor” diyebiliriz. Siber güvenlik tarafından sormamız gereken soru başka: Bu haberleşmeyi taşıyan cihaz, Ethernet tarafında hangi işlemleri kabul ediyor?
Bir router’dan geçen trafikle, router’ın kendisine gelen trafik farklı kontrol noktalarına uğrar. Teltonika’nın RUTX50 dokümanı bunu açıkça ayırır: INPUT cihazın kendisine gelen paketler içindir; FORWARD cihazın başka ağa ilettiği paketler içindir. Transit trafiği kısıtlayan bir kuralın, router’ın web veya SSH yönetimini de kısıtladığını varsayamayız. Ürün ve firmware’de bu ayrımın nasıl uygulandığı ayrıca incelenmeli. Teltonika, RUTX50 Firewall
Bu nedenle yalnız telekontrol servislerinin listesini çıkarmak eksik kalır. Yönetim arayüzü, bakım erişimi ve cihazın başlatabildiği bağlantılar da mimarinin parçasıdır. Merkezle haberleşme izni, diğer tesislere yönetim iznine dönüşmemeli. Gerekli iş akışını tanımlayıp sınır kontrollerini buna göre kurmak, NIST’in OT ağ bölümleme yaklaşımıyla da uyumludur. NIST SP 800-82 Rev. 3, §5.2
Trafikte neye bakarız?
Normalde merkezin sahayı sorguladığı bir yapıda, başka bir saha ucunun yönetim arayüzüne bağlantı başlatması farklı bir anlam taşır. Yalnız “APN’den geliyor” diyerek bu akışı beklenen trafik saymamalıyız.
| Görülen bağlantı | Sorulacak soru |
|---|---|
| Merkez → saha telekontrol servisi | Kaynak, hedef ve servis tanımlı iş akışıyla eşleşiyor mu? |
| Saha A → Saha B yönetim arayüzü | İki tesis arasında böyle bir bakım ihtiyacı gerçekten var mı? |
| Gateway → yerel OT cihazı | Bu bağlantıyı cihazın kendi uygulaması mı, başka bir oturum mu başlattı? |
Bu tablo bir paket yakalamasının çıktısı değil, kayıtları okurken kullanabileceğimiz ayrım. Bir bağlantı kaydı, cihazda hangi işlemin yapıldığını tek başına söylemez. Tünelin dışını izleyen sensör de içerideki hedefi göremeyebilir. NAT veya proxy varsa yerel OT kaydında kaynak olarak gateway görünebilir; önceki bağlantıyı bulmak için operatör ve gateway kayıtlarını zaman bilgisiyle eşleştirmek gerekir.
Şifreli trafikte de kaynak, hedef, yön, servis ve zaman incelemeye katkı sağlar. Ancak gözlem noktasının hangi bilgiyi sakladığını bilmeden, gördüğümüz IP’yi ilk kaynak kabul etmek de yanlış olur.
Sahadaki SIM’in hangi APN’ye bağlandığını biliyoruz. Bir de o bağlantının diğer ucuna kimin gelebileceğini öğrenmeliyiz:
Bu hatta bağlı başka bir tesis ele geçirilirse, bizim hangi cihazlarımıza ve hangi yönetim işlevlerine ulaşılabilir?