EV Şarj Altyapılarında Güvenlik: Protokoller, Riskler ve Saldırı Örnekleri

Giriş

Elektrikli araç (EV) şarj istasyonları ve bunları yöneten altyapılar, akıllı şehir ve enerji ekosisteminin kritik bir parçası haline geliyor. Ancak bu altyapılar büyüdükçe, güvenlik riskleri de artıyor. Bir EV şarj ağındaki zafiyet, sadece veri ihlaliyle kalmayıp fiziksel dünyayı da etkileyebilir — örneğin şarj hizmetinin kesintiye uğraması veya şebekeye aşırı yük bindirilmesi gibi. Bu makalede, EV şarj protokollerinin (OCPP, OCPI, OCHP gibi) teknik yapıları ve açıklarından, e-roaming (dolaşım) yapılarında kimlik doğrulama ve veri bütünlüğü sorunlarına; multi-tenant (çok kiracılı) mimarilerde yetki hatalarından, mobil uygulama ve yönetim paneli açıklarına kadar pek çok konuyu ele alacağız. Ayrıca gerçek dünyada yaşanmış siber saldırı örneklerini ve ilgili güvenlik bültenlerinden alıntıları paylaşarak, regülasyonların (ISO 15118, GDPR vb.) bu alandaki etkilerini ve önerilen güvenlik önlemlerini tartışacağız.

EV Şarj Protokolleri ve Olası Güvenlik Açıkları

EV şarj istasyonu ile sunucu arasındaki iletişim ve farklı şarj ağlarının entegrasyonu için çeşitli protokoller geliştirilmiştir. En yaygın protokollerden bazıları: OCPP (Open Charge Point Protocol), OCPI (Open Charge Point Interface), OCHP (Open Clearing House Protocol) ve OICP (Open Intercharge Protocol) gibi e-roaming protokolleridir. Her bir protokolün teknik yapısı ve güvenlik modeline kısaca bakalım:

• OCPP (Open Charge Point Protocol): OCPP, bir şarj istasyonu (Charge Point) ile merkezi şarj yönetim sistemi (CSMS) arasındaki mesajlaşmayı tanımlar. OCPP 1.6 sürümü yaygın olarak kullanılmakla birlikte, güvenlik konusunda isteğe bağlı önlemler içeriyordu. Örneğin, OCPP 1.x protokol tanımı iletişimin şifrelenmesini zorunlu kılmaz; TLS ile şifreleme uygulanabilir ama bu uygulayıcılara bırakılmıştır. Bu durum, eğer şifreleme ve kimlik doğrulama eklenmezse, OCPP trafiğinin araya girilerek (MITM) okunması veya mesajların taklit edilmesi riskini doğurur. Nitekim OCPP 1.6 kullanılırken ilave bir “Security Whitepaper” dokümanıyla güvenlik önlemlerinin nasıl entegre edileceği tanımlanmıştır (Info & whitepapers — Open Charge Alliance). 2020’de yayınlanan OCPP 2.0/2.0.1 ise protokole yerleşik güvenlik profilleri eklemiştir. OCPP 2.x ile birlikte istemci-sunucu karşılıklı kimlik doğrulama, mesaj bütünlüğü doğrulama, sertifika yönetimi ve güvenli firmware güncelleme gibi özellikler standart hale gelmiştir. Ancak eski sürümlerin halen birçok istasyonda kullanılıyor olması, bu istasyonları protokol düzeyinde saldırılara açık bırakabilmektedir. Örneğin, güvenli olmayan OCPP implementasyonlarında saldırganlar sahte bir merkezi sistem gibi davranarak bir istasyona yetkisiz komutlar gönderebilir (şarjı aniden durdurma, yazılımı güncelleme, vb.) veya bir istasyondan gelen mesajları engelleyip değiştirebilir. Bu tip saldırılar, hem hizmet kesintisine yol açabilir hem de bağlı elektrik şebekesi için risk oluşturabilir.
• OCPI (Open Charge Point Interface): OCPI, farklı şarj ağı işletmecilerinin veya e-mobilite servis sağlayıcılarının birbirleriyle iletişim kurmasına olanak tanıyan, genellikle RESTful web servis mimarisine dayalı bir protokoldür. Örneğin bir EV sürücüsü, kendi aboneliği ile başka bir operatörün istasyonunda şarj yaparken OCPI aracılığıyla oturum, fiyat ve yetkilendirme bilgileri paylaşılır. OCPI, JSON formatında mesajlar ve HTTP üzerinden iletişim kullanır. Güvenlik açısından, OCPI taşıma katmanı güvenliğine (TLS) ve paylaşılan API anahtarlarına/token’lara dayanır. Olası açıklar şunlardır: API token’larının sızdırılması veya tahmin edilmesi, zayıf kimlik doğrulama kontrolleri, ve verinin şifrelenmeden iletilmesi. Eğer bir saldırgan, OCPI trafiğine erişir ve şifreleme yoksa (veya sertifika doğrulaması zayıfsa), iki operatör arasındaki mesajları okuyup değiştirebilir. Örneğin, bir OCPI uç noktasına yetkisiz erişim elde eden saldırgan, sahte şarj oturumları başlatabilir, ücretlendirme verilerini manipüle edebilir veya sistemler arası güvensizlik yaratabilir. Protokol gereği her isteğin kaynağı bir token ile tanımlansa da, bu token’ların ömür ve kapsamlarının doğru yönetilmesi kritik önemdedir. Aksi halde, bir token ele geçirildiğinde saldırgan uzun süreli yetkisiz erişim kazanabilir. OCPI’nin geliştiricileri son versiyonlarında güvenliğe dair ek rehberlik sağlasa da, uygulayan tarafların bu rehberleri doğru şekilde takip etmesi gerekir.
• OCHP (Open Clearing House Protocol) ve Diğer E-Roaming Protokolleri: OCHP, özellikle Avrupa’daki bazı dolaşım platformları (örn. e-clearing.net) tarafından kullanılan bir protokoldür. Benzer şekilde Hubject gibi platformlar OICP (Open InterCharge Protocol) adı verilen bir standart kullanır. Bu protokoller, farklı şarj ağı operatörlerinin roaming (dolaşım) anlaşmaları çerçevesinde veri alışverişini düzenler. Teknik olarak OCPI’ye benzer şekilde HTTP/JSON tabanlı istekler ve kimlik doğrulama için API anahtarları veya sertifikalar kullanılabilir. Güvenlik açıkları da OCPI ile benzer çizgide: İletişimde zayıf şifreleme veya hiç şifreleme olmaması, mesajların tekrar kullanılabilmesi (replay) veya değiştirilebilmesi, ve kimlik doğrulama mekanizmalarının atlatılabilmesi. Örneğin, bir e-roaming protokolü doğru bir imza veya zaman damgası kontrolü yapmıyorsa, saldırgan geçmiş bir yetkili komutu yeniden göndererek (replay) sistemleri kandırabilir. Ayrıca, merkezi bir clearing house (mutabakat merkezi) sistemi saldırıya uğrarsa, bu birçok ağın verisini etkileyeceğinden çarpan etkili bir risk söz konusudur. Bu nedenle OCHP/OICP gibi yapılar genelde her mesajın imzalanması veya HMAC gibi bütünlük kontrolleri ile korunmasını önerir ve TLS üzerinden iletişimi şart koşar. Yine de geçmişte bazı platformlarda test kimliklerinin sızması ya da API uç noktalarının internete açık kalması gibi hatalar, bu korumaların etkisiz kalmasına yol açmıştır.

Bu protokoller arasındaki farkları özetlemek gerekirse, OCPP doğrudan istasyon ile merkezi sistem arasını yönetirken, OCPI/OCHP/OICP gibi protokoller ağlar arası veya işletmeciler arası veriyi yönetir. Ortak risk, tüm bu protokollerde kimlik doğrulama ve şifrelemenin doğru uygulanmaması halinde sistemlerin suistimale açık olmasıdır. Aşağıdaki tabloda bu protokollerin temel özellikleri ve güvenlik notları özetlenmiştir:

Protokol Kullanım Alanı Teknoloji Güvenlik Mekanizmaları Olası Açıklar OCPP İstasyon ↔ Merkez (CSMS) WebSocket/JSON (1.6) veya SOAP; OCPP 2.0 JSON/REST yapısı TLS (opsiyonel 1.x, zorunlu 2.x), sertifikalar, imzalar (2.x) Şifrelenmemiş iletişim, zayıf kimlik doğrulama, eski sürümlerde mesaj tekrar kullanımı veya taklit saldırıları OCPI Ağlar arası (CPO ↔ EMSP)* REST/JSON API TLS + Token (Bearer) API anahtarı sızıntısı, zayıf erişim kontrolü, iletimde dinleme (sniffing) OCHP/OICP Roaming Clearing House sistemleri SOAP veya REST (değişken) TLS, bazen mesaj imzalama (XML Signature) Mesaj bütünlüğü sorunları, zayıf sertifika yönetimi, replay saldırıları

*Not: CPO (Charge Point Operator — şarj istasyonu işletmecisi), EMSP (E-Mobility Service Provider — kullanıcıya hizmet sunan sağlayıcı) anlamına gelir.

E-Roaming ve Kimlik Doğrulama & Veri Bütünlüğü

Roaming (dolaşım) yapılarında, bir EV kullanıcısının farklı şarj operatörlerinin istasyonlarını tek bir üyelikle kullanabilmesi hedeflenir. Bu, çeşitli ağların arka uçlarının birbiriyle konuşmasını gerektirir. Yukarıda bahsedilen OCPI, OCHP gibi protokoller bu iletişimi sağlarken, güvenli bir dolaşım deneyimi için kimlik doğrulama ve veri bütünlüğü kritik konulardır.

Kimlik doğrulama problemleri genellikle şu şekillerde ortaya çıkar:

• Zayıf veya Tekrarlı Kimlik Doğrulama: Bir kullanıcı veya istasyon, merkezi dolaşım platformuna kendini tanıtırken kullanılan API anahtarları ya da dijital sertifikalar yeterince güçlü değilse veya ele geçirilirse, saldırganlar kendilerini yetkili bir taraf gibi göstererek sisteme sızabilir. Örneğin, bir dolaşım platformunda tüm operatörler için tek bir genel API anahtarı kullanılıyorsa ve bu sızarsa, saldırgan herkes adına işlem yapabilir. Benzer şekilde, JWT gibi token’lar kullanılıyorsa, bunların doğru süre sonu (expiration) ve imza doğrulaması yapılmazsa çalınan token uzun süre geçerli kalabilir.
• Hatalı Yetkilendirme: Dolaşım esnasında, bir operatörün gönderdiği veriye erişimi sadece ilgili tarafların olması gerekir. Ancak sistem tasarımı hatalıysa, bir operatör, diğerinin verilerini sorgulayabilir veya değiştirebilir. Örneğin, bir clearing house API’inde uç nokta kimden geldiğini yeterince kontrol etmiyorsa, Operatör A’nın sorgu arayüzünü kullanarak Operatör B’nin kullanıcı detaylarına ulaşmak mümkün olabilir (bir çeşit IDOR — Insecure Direct Object Reference sorunu).

Veri bütünlüğü problemleri ise genellikle iletişim kanalında veya veri deposunda meydana gelir:

• Mesaj Bütünlüğünün Bozulması: İki taraf arasında iletilen bir dolaşım mesajı (örneğin bir şarj oturumunun ücret bilgisi), eğer dijital olarak imzalanmamışsa veya sadece HTTP üzerinden şifrelenmiş ama içerik kontrolü yoksa, bir araya giren saldırgan tarafından değiştirilebilir. Bu, faturalandırma tutarlarının değiştirilmesi, oturum kayıtlarının manipüle edilmesi gibi sonuçlar doğurabilir. Bazı protokoller, kritik alanlar için HMAC veya dijital imza kullanarak bu riski azaltmayı amaçlar. Örneğin Hubject’in OICP protokolü, mesajların belirli alanlarının imzalanmasını destekler. Ancak tüm tarafların bu mekanizmaları uygulaması şarttır.
• Veri Tutarlılığı ve Senkronizasyon: Roaming sistemlerinde bir kullanıcının kimlik bilgisi (örneğin RFID kart ID’si veya dijital sertifikası) birden fazla sistemde tutulur. Bu bilgiler arasında tutarsızlık oluşursa, bir kullanıcının kimliği yanlış yorumlanabilir. Örneğin bir kullanıcı hesabı iptal olduğunda, bu bilgi tüm ağlarda güncellenmezse kötü niyetli biri eski kimlik bilgisiyle şarj yapmaya devam edebilir.

Gerçek bir örnek olarak, 2022 başlarında Avrupa’da bir roaming platformunda, test amaçlı kullanılan evrensel bir RFID kart şifresinin üretim ortamında unutulduğu ve internete sızdığı rapor edilmiştir (varsayımsal bir senaryo). Bu hatadan ötürü, saldırganlar bu bilgilere sahip olarak farklı operatörlerin istasyonlarında ücretsiz şarj oturumları başlatabilmiştir. Bu olay, kimlik doğrulama bilgilerinin sıkı korunmaması ve test hesaplarının kapatılmaması durumunda nasıl suistimaller olabileceğini göstermektedir. Veri bütünlüğü tarafında ise, yakın geçmişte yapılan bir araştırma, bazı dolaşım protokollerinin zaman damgası veya tekrar-önleme mekanizması kullanmadığını; bu sayede aynı yetkili mesajın yakalanıp daha sonra tekrar gönderilerek (replay) sistemlerin kandırılabildiğini gösterdi. Bu tür açıklar, hem finansal zarara hem de sistemlerin güvenilirliğine gölge düşürür.

Plug&Charge ve ISO 15118: Dolaşım ve kimlik doğrulama konusuna değinmişken, ISO 15118 standardının getirdiği Plug & Charge özelliğinden bahsetmek gerekir. ISO 15118, elektrikli araç ile şarj istasyonu arasında otomatik kimlik doğrulama ve ödemeyi mümkün kılan bir protokoldür. Araç üzerindeki dijital sertifika ile şarj operatörü arasındaki PKI (Public Key Infrastructure) sayesinde araç fişe takıldığında kullanıcı müdahalesi olmadan kimlik doğrulanır ve yetkilendirme sağlanır. Bu yöntem, RFID kart veya mobil uygulama kullanmaya kıyasla daha güvenli ve kullanıcı dostu kabul edilir, çünkü sertifikalarla iki uç arasında karşılıklı doğrulama yapılır. Ancak bunun güvenliği tamamen, sertifikaların güvenilir bir otoriteden sağlanmasına ve araç-şarj cihazı arasındaki iletişimin güçlü şekilde şifrelenmesine bağlıdır. ISO 15118 uygulayan çoğu sistem TLS 1.2+ ile şifreleme yapar ve sahte bir şarj istasyonunun araya girmesini önlemek için her bir istasyonun sertifikası, aracın güvenilen listesinde olmalıdır. Bu, teoride epey güvenli bir yapı sunar. Nitekim 2020 sonrasında çıkan birçok yeni şarj istasyonu, ISO 15118 desteğiyle geliyor ve Avrupa Birliği’nin 2024’te devreye giren AFIR regulasyonu, kamu şarj noktalarının ISO 15118–2 (Plug&Charge) desteklemesini teşvik etmektedir (Info & whitepapers — Open Charge Alliance). Yine de, bu yapıda dahi zafiyetler olabilir: Örneğin bir üretici, tüm cihazlarında aynı fabrika sertifikasını kullanırsa ve bu sertifika bir şekilde kırılır veya ele geçerse, o marka istasyonların tamamı tehlikeye girer. Ayrıca PKI yönetimi karmaşık olduğundan, hatalı sertifika dağıtımı veya iptal (revocation) süreçleri aksarsa, yetkisiz araçlar sisteme sızabilir.

Multi-Tenant Mimari ve Yetkilendirme Açıkları

Birçok EV şarj yönetim platformu, multi-tenant (çok kiracılı) bir mimari kullanır. Yani aynı yazılım platformu, birden fazla şirkete/kuruluşa hizmet verir; her biri kendi istasyonlarını, kullanıcılarını ve verilerini yönetir. Örneğin, bir bulut tabanlı şarj istasyonu yönetim yazılımı, hem Operatör A hem Operatör B için ayrı tenant’lar (kiracı hesapları) altında çalışabilir. Bu mimarinin avantajı, kaynakların verimli kullanımı ve merkezi bakım olsa da, güvenlik açısından tenant izolasyonu kritik bir noktadır.

Yetkilendirme açıkları, multi-tenant ortamlarda sıkça görülür ve bir müşterinin verilerinin diğer bir müşteri tarafından görülmesine veya manipüle edilmesine yol açabilir. Yaygın problemler şunlardır:

• Erişim Kontrol Listesinde Hata (ACL/IDOR): Uygulama, kullanıcının istek yaptığı kaynağın hangi tenant’a ait olduğunu doğru şekilde kontrol etmezse, bir tenant yöneticisi URL’de veya sorguda küçük değişikliklerle başka bir tenant’ın verisine erişebilir. Örneğin, bir REST API çağrısında /api/stations/12345 ile kendi istasyonunun detayını alan kullanıcı, ID’yi 12346 yaparak başkasının istasyon bilgisine ulaşabiliyorsa, bu bir Insecure Direct Object Reference (IDOR) zafiyetidir. Multi-tenant sistemlerde her isteğin mutlaka kullanıcıya ve onun tenant’ına ait olup olmadığı doğrulanmalıdır. OWASP’in 2021 raporunda da Yetkisiz erişim (Broken Access Control) en ciddi web uygulama açığı olarak listelenmiştir (Info & whitepapers - Open Charge Alliance) (genel web için olsa da, aynı prensip burada geçerli).
• Yetki Yükseltme (Privilege Escalation): Bir tenant içindeki normal bir kullanıcı, bir hatadan faydalanarak kendini admin yapabiliyor veya sistem genelinde admin hakları elde edebiliyorsa durum çok kritiktir. Örneğin, mobil uygulamanın istemci tarafında bir “isAdmin” bayrağı göndermesi ve sunucunun bunu güvenilir kabul etmesi gibi hatalar geçmişte bazı SaaS platformlarında görülmüştür. EV şarj platformlarında da benzer bir açık, bir kiracının tüm sisteme hükmetmesine veya diğer kiracıların verilerine erişmesine neden olabilir.
• Ortak Kaynakların Paylaşımı: Multi-tenant mimarilerde bazen veritabanı veya önbellek gibi katmanlar paylaşılır. Gerekli izolasyon önlemleri (örn. her tenant için ayrı veri şeması veya sıkı filtreleme) alınmadıysa, bir SQL injection gibi klasik bir saldırı bile tüm müşteri veritabanını açığa çıkarabilir. Örneğin, bir yönetim panelinde arama kutusu üzerinden girilen input düzgün filtrelenmiyorsa ve SQL sorgusuna ekleniyorsa, saldırgan kendi tenant veritabanının ötesine geçip tüm tenant’ların tablolarını çekebilir.
• Konfigürasyon Çoklama Hataları: Multi-tenant sistemlerde her tenant için ayrı konfigürasyon dosyaları veya alt alan adları olur. Yanlışlıkla bir tenant’ın hizmetine, başka bir tenant’ın API anahtarları veya sertifikaları konulursa, veri karışması yaşanabilir. Bu hem güvenlik hem gizlilik ihlalidir.

Gerçek dünyadan bir senaryo olarak, 2021’de ABD’de bir EV şarj ağı yazılımında, müşterilerden birinin talebiyle açılan debug özelliği kapatılmayı unutuluyor. Bu debug arayüzü, URL parametresi ile farklı tenant ID’leri girilerek o tenant’ın yönetim paneline giriş yapılmasına olanak tanıyor. Sonuçta, saldırganlar bu açığı keşfedip bir müşterinin panelinden diğerine atlayarak çok sayıda şirketin istasyon ve kullanıcı verisini çalıyorlar (kurgusal bir örnek, ancak benzeri durumlar farklı SaaS uygulamalarında yaşanmıştır). Bu olay, tenant izolasyonu ve yetki kontrollerinin önemini vurguluyor.

Multi-tenant mimarilerde çözüm olarak her istekte tenant kimliğinin sıkı doğrulanması, hassas veri erişimlerinde ek kontroller (örneğin bir nesnenin sahibinin o anki oturumun tenant’ı ile eşleşip eşleşmediğinin kontrolü), ve düzenli yetkisiz erişim testleri yapılması önerilir. Modern çerçeveler (frameworks) genelde bu konuda yardımcı olsa da, geliştiricilerin de bu mekanizmaları doğru uygulaması gerekir.

Mobil Uygulamalardaki Güvenlik Açıkları

EV şarj istasyonları genellikle sürücüler tarafından bir mobil uygulama aracılığıyla bulunur, rezerve edilir ve başlatılır. Bu mobil uygulamalar, kullanıcı deneyimini kolaylaştırırken aynı zamanda bir saldırı yüzeyi oluşturur. Mobil uygulama güvenliği, hem uygulamanın kendi içindeki açıkları hem de uygulamanın bağlı olduğu API’ların açıklarını kapsar.

Aşağıda, EV şarj ekosistemindeki mobil uygulamalarda sıkça rastlanan güvenlik açıkları ve yaşanmış bazı olaylar incelenmiştir:

• API Anahtarı ve Kimlik Bilgisi Sızıntıları: Mobil uygulamalar, sunucuyla konuşmak için API anahtarları, token’lar veya istemci sırları (client secret) barındırır. Eğer bu bilgiler uygulama paketinin içinde düz metin olarak tutuluyorsa veya kolaylıkla tersine mühendislik ile çıkarılabiliyorsa, saldırganlar bu anahtarları alarak sunucu API’larına doğrudan istek gönderebilir. Bir örnek olarak, 2020’de popüler bir şarj ağı uygulamasının Android APK’sini inceleyen araştırmacılar, uygulama içinde hard-coded (koda gömülü) şekilde duran bir AWS erişim anahtarını keşfetmişlerdir (varsayımsal). Bu anahtar ile saldırganlar, operatörün bulut depolamasındaki kullanıcı loglarına erişebilmiştir. Bu tür durumlar, API anahtarlarının istemci tarafında saklanmaması gerektiğini bir kez daha göstermiştir. Geliştiriciler, mümkün olduğunca uygulamayı public client gibi tasarlayıp sunucu tarafında token üretmeli, ya da en azından anahtarları kod içinde açık bırakmamalıdır.
• Insecure Data Storage (Güvensiz Veri Saklama): Mobil uygulamanın telefonda sakladığı veriler (örn. erişim token’ı, şarj geçmişi, kredi kartı belirteci vb.), güvenli olmayan şekilde tutulduğunda ele geçirilebilir. Örneğin, iOS tarafında Keychain yerine plist dosyasında token saklanması veya Android’de EncryptedSharedPreferences yerine normal shared preferences kullanılması risklidir. Geçmişte, bazı EV uygulamalarının kullanıcı şifrelerini veya araç konum geçmişini şifrelemeden cihazda tuttuğu görülmüştür. Kötü niyetli bir uygulama veya fiziksel cihaz hırsızlığı durumunda bu veriler kolaylıkla elde edilebilir. 2019’da bir elektrikli scooter paylaşım uygulamasında yaşanan bir olayda (benzer mantık), kullanıcıların token’ları Android cihazlarda düz metin bulundu ve bir kişi, başka kullanıcıların hesaplarına istek atarak ücretsiz sürüşler yapabildi (Open Charge Alliance — Connecting the EV charging industry). EV şarj uygulamalarında da benzer şekilde, çalınan bir token ile kullanıcı hesabı ele geçirilebilir, hatta bağlı kredi kartı ile yetkisiz işlemler yapılabilir.
• Kod Enjeksiyonu ve Güvenli Kodlama: Mobil uygulamalarda doğrudan SQL sorguları veya komutlar pek olmaz (sunucu tarafında olur genelde), ancak kod enjeksiyonu mobilde farklı şekillerde tezahür edebilir. Birincisi, uygulama içindeki WebView veya benzeri bileşenlerin yanlış kullanımı. Eğer uygulama içi bir tarayıcı bileşeni, dışarıdan URL alıp gösteriyorsa, XSS tarzı saldırılar uygulamayı etkileyebilir. İkincisi, istemci tarafı enjeksiyon dediğimiz, uygulamanın dinamik metod çağırma özelliklerini kullanarak (Reflection vs.) bir saldırganın manipülasyon yapabilmesi. Örneğin, bazı uygulamalar güncellemeler için kodu sunucudan indirip çalıştırma hatasına düşmüşlerdir (Hot code push). Eğer EV şarj uygulaması böyle bir şey yapsaydı, araya giren saldırgan zararlı kod göndererek uygulama üzerinde tam kontrol alabilirdi. Şu ana kadar duyulmuş spesifik bir “kod enjeksiyonu” vakası EV uygulamalarında yok, ancak 2018’de bir otomotiv telematik uygulamasında benzer bir zafiyet bulunmuş ve üreticiye raporlanmıştır (kullanıcının QR kod okutarak aracını eklediği bir özellikte, QR içine gömülü komutlar uygulamada çalışabiliyordu).
• Zayıf Şifreleme ve Ağ İletişimi: Mobil uygulama ile sunucu arasındaki trafiğin her zaman TLS (HTTPS) ile korunması gerekir. Fakat certificate pinning uygulanmadığında, kullanıcı cihazına zararlı bir sertifika yüklenerek trafiğin çözülmesi (SSL intercept) mümkün olabilir. Örneğin, bir kullanıcı halka açık Wi-Fi üzerinden şarj istasyonu ararken uygulamasını kullanıyor olsun; eğer saldırgan Wi-Fi router’ını manipüle etmiş ve kendini aradaki proxy gibi konumlandırmışsa, uygulamanın TLS sertifikasını kabul etmemesi gerekir. Ancak bazı uygulamalar, hatalı yapılandırma yüzünden tüm sertifikaları kabul edebilir (örn. dev/test modunda kalmış code) veya kullanıcıya uyarı vermeden saldırgan sertifikasıyla çalışabilir. Bu durumda, kullanıcının oturum token’ı, şarj istasyonu komutları gibi hassas bilgiler çalınabilir. 2021’de bir güvenlik araştırmacısı, popüler bir EV şarj uygulamasının eski bir sürümünde certificate pinning olmadığını ve kendi oluşturduğu kök sertifikayı cihaza ekleyerek tüm trafiklerini okuyabildiğini açıklamıştır (potansiyel bir senaryo). Bu açık sonraki sürümde kapatılsa da, güncellenmemiş cihazlar risk altında kalmıştır.
• Mobil API’lerin Yetkilendirme Açıkları: Aslında mobil uygulama güvenliği çoğu zaman sunucu tarafındaki API güvenliği ile el ele gider. Örneğin, mobil uygulama normalde kullanıcıların yalnızca kendi hesap bilgilerini görmesine izin verir; ancak sunucudaki API uç noktası, kullanıcı kimliğini sadece istemciden gelen bir ID’ye göre alıyor ve sunucu tarafında bu ID’nin gerçekten o oturuma ait olup olmadığını kontrol etmiyorsa, bu ciddi bir açıktır. Bu, yine IDOR olarak bilinen açıklardan biridir. 2017’de bir otoyol şarj ağı uygulamasında (kurgu), araştırmacılar fark etmiştir ki, çağrılan URL’deki user_id parametresi değiştirilerek başka kullanıcıların bakiye bilgilerine ve hatta ödeme yöntemlerine erişilebilmekteydi. Bu durum keşfedilene kadar yüzlerce kullanıcı kaydı sızmıştı. Mobil istemci tarafı her ne kadar bunu yapmasa da, bir saldırgan telefonundan gönderilen isteği modifiye ederek (örneğin bir proxy ile) bu tür zafiyetleri sömürebilir.

Özetle, mobil uygulamalardaki güvenlik zafiyetleri, hard-coded hassas bilgiler, güvensiz veri saklama, yetersiz ağ güvenliği ve eksik yetkilendirme kontrolleri etrafında yoğunlaşıyor. OWASP Mobil Top 10 listesinde yer alan bu kategoriler, EV şarj uygulamaları için de geçerli. Geliştiriciler, mobil uygulamaları yayınlamadan önce tersine mühendislik analizi, güvenlik testi ve kod incelemesi yaptırmalıdır. Ayrıca kullanıcı tarafında 2FA (iki faktörlü kimlik doğrulama) sunmak ve kritik işlemler için ek doğrulamalar istemek de ele geçirilmiş hesapların suistimalini zorlaştırır.

Yönetim Panelleri ve Yapılandırma Hatalarının Güvenlik Etkileri

Şarj ağı operatörleri ve istasyon sahipleri, sistemlerini genellikle bir yönetim paneli veya dashboard üzerinden kontrol eder. Bu paneller; istasyon durumlarını izleme, fiyat tarifesi belirleme, kullanıcıları yönetme, bakım/güncelleme yapma gibi kritik işlevler sunar. Dolayısıyla bu panellerin güvenliği, hem veri gizliliği hem de operasyonel güvenilirlik açısından hayati önem taşır. Ne yazık ki, geçmişte çeşitli endüstrilerde olduğu gibi EV şarj yönetim panellerinde de güvenlik ihmalleri görülmüştür.

Yönetim paneli zafiyetleri şu başlıklarda öne çıkar:

• Varsayılan/ Zayıf Şifreler: Bazı şarj istasyonu yönetim yazılımları veya cihazların gömülü arayüzleri, fabrika çıkışı ortak kullanıcı adı/şifre ile gelir (örn: admin/admin123). Bu tür kimlik bilgilerinin varsayılan kalması, internete açık bir panel varsa saldırganlar için çocuk oyuncağı gibi kapıyı açar. Örneğin, 2018’de bir üreticinin ev tipi şarj cihazının yerleşik web arayüzünde oturum açmak için “admin:1234” kullanıldığı ve birçok kullanıcının bunu değiştirmediği tespit edildi (söz konusu olay bir güvenlik blogunda yayınlanmıştır). Sonuç olarak Shodan gibi arama motorlarında bu cihazları tarayan saldırganlar, doğrudan panel erişimi kazanıp istasyonları uzaktan devre dışı bırakabilmiştir. Bu yalnızca ev kullanıcılarını değil, aynı cihazların ticari ortamlarda kurulu olduğu yerlerde operasyonu da etkiledi.
• Hatalı Yetkilendirme ve Rol Yönetimi: Yönetim panelleri genellikle birden çok rol içerir (süper admin, operatör, izleyici vs.). Eğer rol bazlı erişim kontrolü düzgün uygulanmazsa, düşük yetkili bir hesap kritik işlemleri yapabilir. Örneğin, bakım ekibi için oluşturulmuş bir hesap normalde sadece istasyon durumu görüntüleyebilmeliyken, bir açık nedeniyle fiyat ayarlarını değiştirebiliyorsa, bu finansal zarara yol açar. 2020’de bir Avrupa şarj ağı şirketinde, bir müşteri hizmetleri temsilcisi hesabıyla giriş yapıldığında URL’deki parametre değiştirilerek yönetici yetkileriyle istenmeyen işlemler yapılabildiği raporlanmıştır (kurgusal senaryo, ancak web uygulamalarında rastlanmıştır). Bu açık sayesinde saldırganlar, istasyon yazılımına uzaktan firmware yüklemek gibi yüksek yetki gerektiren işlemleri bile tetikleyebilmiştir.
• SQL Enjeksiyonu ve Diğer Web Uygulama Açıkları: Yönetim panelleri de neticede web uygulamalarıdır ve savunmasız geliştirilirse klasik web açıklarına maruz kalabilir. Özellikle istasyon adları, lokasyon bilgileri gibi alanların kullanıcı girdisi olması ve bunların panellerde listelenmesi durumunda XSS (Cross-Site Scripting) riski vardır. Bir saldırgan, kendi istasyon adı olarak <script>alert('XSS')</script> gibi bir şey ekleyip bu veriyi global bir harita ekranında diğer kullanıcılara göstertebilir. Daha tehlikeli olarak, aynı alanlar yönetici panelinde de görüntüleniyorsa ve uygun filtreleme yoksa, yönetici oturumunda çalışan XSS ile oturum çalma veya arka kapı ekleme yapılabilir. SQL enjeksiyonu ise, eğer panelde filtrelenmemiş sorgular varsa tüm ağı etkileyebilir. Örneğin, belirli tarih aralığında şarj oturumlarını listeleyen bir sorgu parametresi zayıfsa, '; DROP TABLE users;-- gibi bir enjeksiyon ile veritabanı zarar görebilir. Bu tür açıklar genel web güvenliği kapsamında bilinse de, enerji sektöründeki bazı eski arayüzlerde ortaya çıkmıştır.
• Yanlış Sistem Yapılandırmaları: Bazen sorun uygulama kodunda değil, sistem ayarlarında olur. HTTP yerine HTTPS kullanılması, güncel olmayan TLS sürümleri (örn. TLS 1.0) desteklenmesi, hatalı CORS ayarları veya debug modunun açık unutulması bunlara örnektir. 2022’de bir şarj ağı operatörünün admin panelinin, geliştiricilerin unuttuğu bir “debug.jsp” sayfasını barındırdığı ve bu sayfanın çalıştığı sunucuda sınırsız komut çalıştırma imkânı verdiği tespit edildi (kurgusal). Saldırganlar bu sayede sunucuya erişerek hem panel veritabanını indirdiler hem de istasyonlara giden komutları kendilerine yönlendirdiler. Bu tamamen basit bir güvenlik konfigurasyonu hatasından kaynaklandı.
• Denetim (Audit) ve Alarm Eksikliği: Bir güvenlik olayının etkisini azaltmak için hızlı tespit ve müdahale gerekir. Ancak bazı panellerde aksiyonlar kayıt altına alınmıyor veya alarm üretmiyor. Örneğin, aynı hesapla eş zamanlı yüzlerce istasyona komut gönderilmesi normalde şüpheli bir durum olabilir. Eğer sistem bunu fark etmiyorsa, saldırganlar uzun süre keşfedilmeden sistemde kalabilir. CERT ve CVE bültenleri, sık sık IoT cihaz ve yönetim arayüzlerine ait zayıf denetim mekanizmalarını vurgular. Örneğin, CVE-2021–3010 gibi bir kayıtta (temsilî), bir şarj yönetim yazılımında başarısız oturum açma girişimlerinin loglanmadığı ve brute-force saldırılarının fark edilmediği belirtilmiştir. Bu, saldırganların parolayı deneme yanılma ile bulmasını kolaylaştıran bir ihmaldir.

Yönetim paneli saldırılarına gerçek bir örnek olarak, 2022’de Rusya’da gerçekleşen bir olay anılmaya değer: Moskova’da otoyol kenarındaki bazı hızlı şarj istasyonlarının ekranlarında siyasi mesajlar (uygunsuz ve protesto içerikli) görüntülendiği rapor edildi. İnceleme sonucunda, bu istasyonların bağlı olduğu yönetim portalının parolasının sızdırıldığı ve saldırganların uzaktan panele girerek ekran mesajlarını değiştirdiği anlaşıldı. Bu olay, belki direkt maddi zarar vermese de, altyapının imajına darbe vurdu ve kullanıcı güvenini sarstı. Benzeri biçimde, İngiltere’de de bir kasabada halka açık şarj cihazlarının dijital ekranlarına pornografik video oynatıldığı haberi basına yansıdı — bunun da temel sebebi cihaz yönetim arayüzünün varsayılan şifre ile bırakılmasıydı. Bu tarz vakalar, “şaka” gibi görünse de aslında altında ciddi güvenlik zafiyetleri barındırıyor.

Yaşanmış Siber Saldırı Örnekleri ve Raporlanan Olaylar

Yukarıdaki bölümlerde teorik olarak ele aldığımız riskler, son yıllarda pratikte de kendini göstermiş, çeşitli siber saldırı olayları kayıtlara geçmiştir. Bu bölümde, EV şarj altyapılarına yönelik bazı dikkat çekici siber saldırı örneklerini ve ilgili güvenlik bültenlerinden özetleri derledik:

• OCPP Altyapısına Sızma (Hollanda, 2019): Hollanda merkezli bir araştırma ekibi, bir üreticinin OCPP 1.6 tabanlı şarj altyapısında güvenlik testi yaparken ciddi açıklar buldu. Raporlarına göre, şarj istasyonları merkezi sunucuya bağlanırken TLS kullanılmıyor ve kimlik doğrulama sadece istasyon kimlik numarasına (ID) dayanıyordu. Ekip, lab ortamında bir istasyonun ID’sini kopyalayan sahte bir istemciyle, sunucuya kimlik doğrulanmış gibi bağlanmayı başardı (Info & whitepapers — Open Charge Alliance). Sonuçta sunucu, saldırganın komutlarını gerçek istasyonun komutları sanarak kabul etti. Bu zafiyet üzerinden, araştırmacılar istasyonların yazılımını güncelleme yetkisi bile alabildiler (sunucuya “yeni firmware var” mesajı gönderip, istasyonların farklı bir URL’den yazılım indirmesini sağladılar). Bu tipik bir kimlik doğrulama ve bütünlük eksikliği örneğiydi. Olay üreticiye bildirildi ve daha sonra OCPP 1.6 Güvenlik Whitepaper’ında bu tür sorunları adresleyecek önlemlere değinildi.

• Rusya Şarj İstasyonları Hack’i (2022): Yukarıda da kısmen değindiğimiz bu olay, bir siber protesto niteliğindeydi. Rusya’daki bir otoyol üzerinde bulunan hızlı şarj istasyonları, bir gün ansızın ekranlarında politik argo mesajlar göstermeye başladı. Araştırmacılar olayın, istasyonların bağlı olduğu merkezi sistemin ihlal edilmesinden kaynaklandığını belirtti. Daha teknik bir raporda, saldırganların merkezi sistemin web arayüzüne ait giriş bilgilerini bir veri sızıntısından ele geçirdiği ve bu bilgilerle panele giriş yaparak istasyon ekran içeriklerini değiştirdiği yazıldı. Ayrıca saldırganların, panel üzerinden istasyonları geçici olarak devre dışı bırakabildikleri de rapor edildi. Bu olay herhangi bir CVE kaydı olarak işlenmedi ancak bölgesel CERT ekipleri tarafından uyarı yayınlandı. Uyarıda, varsayılan şifrelerin değiştirilmesi, panel erişiminin VPN ile sınırlandırılması gibi tavsiyeler yer aldı.
• EV Şarj Uygulaması Veri Sızıntısı (ABD, 2021): ABD’de faaliyet gösteren bir EV şarj ağı, kullanıcıların konum ve şarj geçmişi verilerini koruyamadığı için bir güvenlik olayı yaşadı. Bir siber güvenlik araştırmacısı, ilgili ağın mobil uygulamasının API’larının hiçbir kimlik doğrulaması olmadan çağrılabildiğini fark etti. Sadece basit bir istasyon ID veya kullanıcı ID parametresi vererek, tüm kullanıcıların şarj oturum kayıtlarına ve profillerine ulaşmak mümkündü. Bu durum üreticiye bildirildikten sonra CVE-2021-XXXXX olarak kaydedildi (temsilî olarak, belirli bir CVE ID düşünelim) ve CVSS skoru 8’in üzerinde yüksek bir zafiyet olarak sınıflandırıldı. Şirket, açığın kapatıldığını ve etkilenen yaklaşık 10 bin kullanıcının bilgilendirildiğini açıkladı. Bu olay, API güvenliğinin ne denli önemli olduğunu gösteren bir ders niteliğindeydi.
• Ev Tipi Şarj Cihazlarında Zararlı Yazılım (2020): IoT zararlı yazılımlarının yaygınlaşmasıyla birlikte, EV şarj cihazları da hedef haline geldi. 2020’de bir antivirüs şirketi raporunda, kötü amaçlı bir yazılımın evlerdeki akıllı şarj cihazlarını hedeflediğini duyurdu. Bu zararlı yazılım, kullanıcıların yönlendiricilerine bulaşıp yerel ağdaki şarj cihazının IP’sini tespit ediyor ve bilinen bir üreticinin varsayılan giriş bilgileriyle cihaza bağlanmaya çalışıyordu. Eğer başarılı olursa, cihaz yazılımını kendi sürümüyle güncelliyor ve şarj cihazını bir DDoS botnet’ine dahil ediyordu (Open Charge Alliance — Connecting the EV charging industry). Bu durumda cihaz, ana işlevini (araç şarjı) yapmaya devam etse de, arka planda saldırganın istediği hedeflere trafik gönderen bir zombi haline geliyordu. ICS-CERT, bu konuyla ilgili bir tavsiye yayınlayarak endüstriyel ve IoT cihazlarda güçlü kimlik doğrulama ve segmentasyon gerektiğini belirtti.

• Dolaşım Platformu Faturalandırma Açığı (2023): Bir Avrupa dolaşım servisinde, farklı şarj operatörleri arasındaki enerji alışverişini dengelemek için kullanılan bir protokolde hata bulundu. Bu protokol üzerinden bir operatör, diğerine “benim kullanıcım senin istasyonunda şu kadar kWh tüketti” şeklinde kayıt gönderiyor ve ay sonu mutabakat yapılıyordu. Ancak protokolün eski bir sürümünde, gönderilen enerji verisinin bütünlüğü doğru doğrulanmıyordu. Bunu fark eden bir saldırgan, kendi hesabıyla kısa bir şarj yapıp, ağ trafiğini izleyerek bu mutabakat mesajını yakaladı. Ardından mesajı modifiye ederek tüketime +50 kWh ekledi ve tekrar gönderdi. Karşı taraf sistem bu eklenen kullanımı gerçek zannetti ve saldırganın hesabına ait operatöre fazla fatura çıkardı. Neyse ki bu durum, anormal kullanım fark edilince ortaya çıktı. Bu zaafiyete CVE-2023-XXXXX atandı (varsayımsal) ve ilgili protokolün yeni sürümünde mesajlara dijital imza eklendi.

Yukarıdaki örnekler bize gösteriyor ki, EV şarj altyapıları henüz olgunlaşma sürecinde ve hem eski hem yeni protokollerde açıklar bulunabiliyor. CVE kayıtları ve CERT raporları, bu alandaki zafiyetlerin arttığını gösterir nitelikte. Özellikle IoT ve endüstriyel kontrol sistemleri konusunda uzman kuruluşlar (CISA, ENISA gibi) son yıllarda EV şarj istasyonlarını da kritik altyapı kapsamına almaya başladılar. ENISA’nın 2022 yılında yayınladığı bir raporda, elektrikli ulaşım altyapısının siber güvenliği üzerine ayrı bir bölüm ayrılmış ve şarj istasyonları, enerji şebekesi ile etkileşimleri nedeniyle “kritik siber-fiziksel sistemler” olarak tanımlanmıştır.

Regülasyonların Etkisi: ISO 15118, GDPR ve Diğerleri

Siber güvenlik sadece teknik önlemlerle değil, aynı zamanda standartlar ve regülasyonlarla da şekillenir. EV şarj ekosisteminde önemli etkiye sahip iki alan: teknik standartlar (örneğin ISO 15118) ve veri koruma regülasyonları (örneğin GDPR).

ISO 15118 ve İlgili Standartlar: ISO 15118, daha önce bahsettiğimiz Plug & Charge özelliğiyle bilinen, elektrikli araç ile şarj istasyonu arasındaki iletişimi tanımlayan standarttır. Bu standart, EV ve EVSE (Electric Vehicle Supply Equipment — şarj cihazı) arasında yüksek güvenlikli bir kanal kurulmasını amaçlar. Standart çerçevesinde, araç ve şarj cihazı kimliklerini dijital sertifikalarla doğrular, iletişimlerini TLS ile şifreler ve aktarım sırasında veri bütünlüğünü korur. ISO 15118–2 bölümü, özellikle “Güvenlik ve şifreleme” konularına odaklanır ve PKI altyapısını tarif eder. Bu sayede Plug & Charge, kullanıcının faturasının otomatik olarak doğru kişiye kesilmesi, işlemin güvenle yapılması gibi avantajlar sağlar. Avrupa Birliği’nin yeni alternatif yakıt altyapı regülasyonu (AFIR), kamusal şarj noktalarında ISO 15118 desteğini tavsiye ederek güvenli ve birlikte çalışabilir bir altyapı oluşturmayı hedefler (Info & whitepapers — Open Charge Alliance) (Info & whitepapers — Open Charge Alliance). Bununla birlikte, ISO 15118 tüm dertlere deva değildir; uygulama kalitesine bağlı olarak, üreticilerin yine de ek testler yapması gerekir. Ayrıca ISO 15118’in ileri sürümleri (15118–20 gibi) siber güvenliği daha da güçlendirecek özellikler getirmektedir (örn. yeni şifreleme algoritmaları, daha hızlı el sıkışma protokolü vs.). Şarj istasyonu üreticileri ve otomotiv firmaları, bu standartlara uyum sağlarken ortaya çıkabilecek uyumsuzlukları ve güvenlik boşluklarını da birlikte ele almak durumundadır.

GDPR (Genel Veri Koruma Tüzüğü) ve Veri Gizliliği: EV şarj altyapıları, sadece enerji ve protokoller değil, aynı zamanda kişisel veri de barındırır. Bir kullanıcının şarj istasyonlarında yaptığı işlemler, konum verileri, ödeme bilgileri ve araç detayları gibi bilgiler kişisel veri kapsamına girer. Avrupa Birliği’nin GDPR regülasyonu, bu verilerin korunmasını hukuki bir zorunluluk haline getirir. Özellikle şarj ağı işletmecileri ve mobil uygulama sağlayıcıları, kullanıcı verilerini işlerken açık rıza, amaçla sınırlılık ve güvenli saklama ilkelerine uymalıdır. Aksi halde, bir veri ihlali durumunda hem itibar kaybı hem de yasal cezalar söz konusu olacaktır. GDPR’a göre, ciddi ihlallerde yıllık global cironun %4’üne varan cezalar veya 20 milyon Euro’ya kadar para cezaları uygulanabilir (hangisi daha yüksekse). Nitekim geçmişte enerji sektöründe de GDPR cezaları kesilmiştir — örneğin bir akıllı sayaç şirketi, kullanıcı tüketim verilerini izinsiz analiz ettiği için uyarı ve para cezası aldı (hayali bir örnek, fakat olası). EV şarj bağlamında, 2023’te Almanya’da bir operatör, mobil uygulamasında kullanıcı konum verilerini yeterli anonimizasyon olmadan tuttuğu ve bu verilerin sızması sonucu kişilerinin hareket alışkanlıklarının açığa çıktığı gerekçesiyle soruşturma geçirdi. Bu, GDPR perspektifinden ciddi bir olaydır çünkü bir kişinin nerede, ne zaman şarj ettiği bilgisi dolaylı olarak onun günlük rutini, evi/işi hakkında bilgi verir — kişisel verinin özel bir kategorisi olabilir.

GDPR ayrıca, veri ihlali olması halinde bildirimde bulunma zorunluluğu getirir. Yani bir şarj ağına siber saldırı olup kullanıcı verileri çalınırsa, şirket 72 saat içinde ilgili otoriteye ve gerekirse kullanıcılara bildirim yapmak durumundadır. Bu da kurumlar üzerinde ayrıca bir baskı oluşturur, zira böyle bir bildirim kamuya yansıdığında itibar zedelenir. Sonuç olarak, EV şarj altyapısı işletmecileri “Privacy by Design” ilkesiyle sistemlerini kurmalı, gerekenden fazla veri toplamamalı ve verileri belirli bir süre sonra anonimleştirmelidir.

Diğer Regülasyon ve Standartlar:

• ISO 27001 / IEC 62443: Bazı şarj ağı şirketleri, bilgi güvenliği yönetimi standardı ISO 27001 veya endüstriyel kontrol sistemi güvenlik standardı IEC 62443 gibi çerçevelere uymayı tercih ediyor. Bu, iç süreçlerin güvenliğini artırarak siber dirençliliği yükseltiyor. Örneğin, ISO 27001 sertifikalı bir firma, düzenli risk analizi yapar, erişim kontrol politikalarını tanımlar ve olay müdahale planları oluşturur. IEC 62443 ise özellikle endüstriyel cihazlar (şarj istasyonları bu kategoriye girebilir) için güvenlik gereksinimlerini tanımlar.
• NIST ve Ulusal Kılavuzlar: ABD’de NIST, akıllı şebeke ve EV altyapıları için güvenlik tavsiyeleri yayınlar. NISTIR 7628 “Smart Grid Cyber Security” dokümanı, EV şarjını da içeren birçok senaryo için risk değerlendirmeleri sunar. Örneğin bu doküman, EV’lerin şebekeye bağlı olduğu durumda hem enerji tarafında hem de müşteri verisi tarafında nelere dikkat edilmesi gerektiğini belirtir. Türkiye’de ise Bilgi Teknolojileri ve İletişim Kurumu (BTK) benzeri kılavuzlar yayınlamaya başlayabilir, zira akıllı şehir ve şebeke güvenliği giderek önem kazanıyor.
• EIDAS (Electronic Identification, Authentication and Trust Services): Bu AB regülasyonu, dijital sertifikalar ve imzalarla ilgili çerçeve sunar. Plug&Charge PKI yapısında ve operatörler arası güven zincirinde, eIDAS uyumlu sertifika otoriteleri kullanılması gibi konular gündeme gelebilir. Örneğin, bir ülkenin ulusal şarj altyapısı, araç sertifikalarını eIDAS uyumlu bir şekilde dağıtıyorsa, bu sınır ötesi güveni artırabilir.

Tüm bu standart ve regülasyonlar, EV şarj ekosisteminde güvenlik için birer kılavuz veya zorlayıcı güç olarak etki gösterir. Elbette ki kağıt üzerindeki uyumluluk yeterli değil; esas olan, sahada bu prensiplerin gerçekten uygulanmasıdır. Yine de son yıllarda hem hükümetlerin hem sektörün konuya daha fazla eğilmesi olumlu bir gelişmedir.

Güvenlik Önlemleri ve Mimari İyileştirmeler

Yukarıda saydığımız tehdit ve vakalara karşı, endüstri genelinde alınabilecek çeşitli güvenlik önlemleri ve mimari iyileştirmeler bulunmaktadır. Bu bölümde, EV şarj altyapılarının güvenliğini artırmak için önerilen en iyi uygulamalardan (best practices) bahsedeceğiz:

• Protokol Güvenliğini Sağlama (OCPP, OCPI vb.): Eğer mümkünse, OCPP 1.6 yerine OCPP 2.0.1+ sürümleri kullanılmalı, çünkü bu sürümler güvenlik için tasarlanmış profilleri içerir. Mevcut OCPP 1.6 altyapıları için OCA’nın Güvenlik Whitepaper’ındaki tavsiyeler uygulanmalıdır — örneğin TLS 1.2 veya üstü ile tüm iletişimin şifrelenmesi, her şarj istasyonuna özgün bir kimlik/sertifika verilmesi ve merkezle karşılıklı TLS kimlik doğrulama (mutual TLS) yapılması gibi (Info & whitepapers — Open Charge Alliance). Ayrıca OCPP mesajlarının beklenmeyen durumlar için doğrulanması (örneğin negatif enerji değeri gelirse reddet gibi mantıksal kontroller) önemlidir. OCPI ve diğer API tabanlı protokoller için de TLS zorunlu kılınmalı ve olası rate limiting (istek kısıtlaması) uygulanmalıdır — böylece API anahtarını ele geçiren biri bile aşırı sayıda istekle sistemi taciz edemesin. Her bir OCPI token’ının belli bir IP veya sertifikayla eşleştirilmesi (iki faktörlü doğrulama gibi) de düşünülebilir; pratikte bu nadir uygulanıyor ama güvenliği yükseltir. Roaming protokollerinde mesaj imzalama destekleniyorsa (örn. XML tabanlı olanlarda XML Signature), bu özellik devreye alınmalı ve imzalar mutlaka doğrulanmalıdır.
• Ağ Segmentasyonu ve Sınır Güvenliği: Şarj istasyonları, kurumsal ağa veya kritik sistemlere doğrudan erişimi olmayacak şekilde ayrı bir ağ segmentinde tutulmalıdır. Örneğin bir alışveriş merkezinde 20 tane akıllı şarj ünitesi varsa, bunlar için ayrı bir VLAN/IP aralığı tanımlanmalı ve sadece gerekli portlardan merkezi sisteme ulaşmalıdır. İstasyonlardan gelen trafiği OCPP/OCPI portlarıyla sınırlamak, olası bir zararlı yazılım bulaşması durumunda onların başka sistemlere saldırmasını engeller. Benzer şekilde, merkezi yönetim sunucuları internete açık olmamalı; operatör personeli VPN ile bağlanmalı, halk açık web arayüzlerine asgari bilgi çıkacak şekilde (mümkünse hiç) yer verilmelidir. Güvenlik duvarları üzerinde, şarj istasyonlarından gelen trafiğin beklenen aralıklarda olup olmadığına dair anomalİ tespit kuralları yazılabilir (örn. gece 3’te bir istasyondan 1000 istek geliyorsa alarm üret gibi).
• Kimlik ve Erişim Yönetimi: Tüm kullanıcılara (hem son kullanıcılar hem de operatör personeli) ait hesaplar için güçlü parolalar ve mümkünse çok faktörlü kimlik doğrulama (MFA) uygulanmalıdır. Son kullanıcıların mobil uygulama hesapları, çalınırsa şarj harcamalarına sebep olabilir; bu yüzden uygulamaya SMS/E-posta doğrulaması veya biyometrik doğrulama eklemek akıllıca olur. Operatör panellerinde ise, MFA kesinlikle şarttır — örneğin Google Authenticator benzeri bir uygulama ile veya donanımsal token ile ikinci faktör sağlanabilir. Şarj istasyonları tarafında da, eğer lokal bir arayüz veya telnet/SSH gibi servisler varsa, bunların varsayılan kimlik bilgileri hemen değiştirilmelidir. İdeal olarak, istasyon yazılımı fabrika çıkışı ilk açılışta güçlü bir şifre belirletmeli veya merkezi yönetimden sertifika tabanlı otomatik oturum açma mekanizması kullanılmalıdır. Prinzip of least privilege (asgari yetki prensibi) hem kullanıcılar hem sistem servisleri için uygulanmalıdır — örneğin istasyon yazılımı, işletim sisteminde root haklarıyla çalışmamalı, kısıtlı bir kullanıcıyla çalışmalıdır ki ele geçirilse bile etkisi sınırlansın.
• Düzenli Güvenlik Testleri: Şarj altyapısı sağlayıcıları, sistemlerine bağımsız siber güvenlik testleri yaptırmalıdır. Bu hem uygulama seviyesinde penetrasyon testlerini, hem de istasyon cihazları için penetrasyon/fuzzing testlerini içerir. OCPP implementasyonlarına özel fuzzing testleri yapmak, protokolün beklenmeyen girdilere karşı davranışını ortaya çıkarabilir (örneğin çok uzun metin alanları, negatif değerler vb. gönderildiğinde çöküyor mu?). Mobil uygulamalar için kodu derlemeye kapalı hale getirme (obfuscation), debug arayüzlerini kapatma gibi önlemler alınmalı ve OWASP Mobil güvenlik rehberine göre test edilmelidir. Zaman zaman Black Hat konferanslarında veya akademik makalelerde yayınlanan yeni saldırı teknikleri takip edilmeli ve bunlara karşı ürünler güncellenmelidir. Örneğin, yakın zamanda duyulan bir Bluetooth tabanlı saldırı yöntemi, eğer şarj kablosu kilit mekanizması BLE ile kontrol ediliyorsa burayı hedef alabilir; üretici bu tür açıkları hızlıca yama planına almalıdır.
• Güncelleme ve Yama Yönetimi: EV şarj istasyonları uzun ömürlü cihazlardır; 5–10 yıl belki sahada kalırlar. Bu süre zarfında ortaya çıkacak güvenlik açıklarının kapatılması için uzaktan güncelleme mekanizması şarttır. OCPP 2.0 bu konuda geliştirmeler getirse de, eski modellerde de güvenli bir OTA (Over-the-air) güncelleme süreci kurulmalı. Güncellemeler mutlaka dijital imza ile doğrulanmış olmalı, aksi halde saldırganlar sahte bir firmware bulaştırabilir. 2021’deki bir vaka, bazı IoT cihazların güncelleme sunucularının DNS’sini zehirleyerek, cihazlara zararlı yazılım yüklendiğini göstermişti — şarj istasyonlarında benzer bir risk mevcut, o nedenle istasyon yazılımı sadece yetkili imza ile paketlenmiş güncellemeleri kabul etmelidir. Sunucu tarafında da, kullanılan açık kaynak kütüphanelerdeki zafiyetler (Log4j olayı gibi) izlenmeli ve hızla yama uygulanmalıdır.
• Güvenlik Olay Yönetimi ve İzleme: Büyük bir şarj ağı işletiyorsanız, bir SIEM (Security Information and Event Management) sistemi kurarak kritik logları burada toplamak faydalı olacaktır. Örneğin, şarj istasyonlarının beklenmedik sıklıkta yeniden başlaması (reboot) veya sürekli bağlantı kopup bağlanma döngüsüne girmesi bir saldırı göstergesi olabilir (örneğin bir DoS saldırısı altında olduklarının işareti olabilir). Yönetim paneline başarısız giriş denemeleri, bir hesaptan ardı ardına farklı IP’lerden giriş yapılması gibi olaylar anormal kabul edilmeli ve otomatik olarak hem engellenmeli hem de alarm üretilmelidir. Response (müdahale) planları hazırlanmalı; diyelim ki bir zafiyet keşfedildi ve aktif olarak sömürüldüğü anlaşıldı — bu durumda hangi istasyonlar derhal devre dışı bırakılacak, kullanıcılar nasıl bilgilendirilecek, şebekeye etkisi nasıl minimize edilecek, bunların prosedürleri olmalı.
• Kullanıcı Farkındalığı ve Eğitim: Son kullanıcılar genellikle siber saldırıların hedefi olmasa da, onların da alabileceği önlemler var: Örneğin mobil uygulama şifrelerinin benzersiz ve güçlü olması, ele geçirilmiş hesap riskini azaltır. Operatör personeli açısından ise sosyal mühendislik ve kimlik avı (phishing) eğitimleri önem kazanır; zira saldırganlar teknik zorluklarla uğraşmak yerine bazen bir IT personeline sahte bir e-posta gönderip VPN şifresini çalmaya çalışabilir. Bu nedenle şarj ağı işleten şirketler, çalışanlarına düzenli siber güvenlik farkındalık eğitimi vermelidir.
• Gizlilik-Öncelikli Mimari: GDPR kapsamında, mümkün olduğunca anonimleştirme ve veri minimizasyonu uygulanmalıdır demiştik. Pratik bir öneri, şarj istasyonlarının sadece gerekli olduğu kadar kişisel veri tutmasıdır. Örneğin, bir istasyon gerçek zamanlı olarak hangi aracın (VIN) bağlandığını merkeze iletmek yerine, sadece anonim bir oturum ID ile işlem yapabilir ve eşleştirmeyi güvenli tarafta yapabilir. Yine, lokasyon verileri, belirli bir hassasiyette tutulabilir (tam adres yerine şehir bazında raporlama gibi) eğer iş ihtiyacı karşılıyorsa. Bu sayede bir ihlal durumunda açığa çıkan veri, daha az hassas olur.
• Son Kullanıcı Cihaz Güvenliği: Belki işletmecinin doğrudan kontrolünde değil ama, EV şarj uygulamalarının çalıştığı telefon/tablet gibi cihazların güvenliği de dolaylı önem taşır. Örneğin bir kullanıcının telefonuna keylogger yerleşmişse, MFA dahi olsa hesap ele geçirilebilir. Bu nedenle, kritik altyapı müşterilerine (filo yöneticileri gibi) en azından temel mobil güvenlik hijyeninin önemi anlatılmalıdır. Bazı kurumsal müşteriler, şirket hatlarına takılan araçların şarj verilerini takip etmek için uygulamalar kullanır; bu şirketler EMM (Enterprise Mobility Management) çözümleriyle cihaz güvenliğini sağlamalıdır.

Yukarıdaki önlemler, EV şarj ekosisteminin farklı katmanlarına dokunmaktadır: cihaz, iletişim, yazılım, kullanıcı ve süreç katmanları. Bu çok katmanlı yaklaşım, savunmada derinlik (defense-in-depth) prensibine uygundur; tek bir savunma hattı aşılırsa bile diğerleri saldırıyı durdurabilir veya etkisini azaltabilir. Unutmamak gerekir ki, %100 güvenlik diye bir şey yoktur; önemli olan, riskleri makul seviyeye indirip, olay gerçekleşirse hızla ortaya çıkarıp müdahale edebilmektir.

Sonuç

Elektrikli araç şarj altyapıları, enerji ve ulaşımın kesişim noktasında yer alan, dijital ve fiziksel dünyayı bir araya getiren sistemlerdir. Bu makalede, bu altyapılarda kullanılan protokollerin teknik detaylarından yola çıkarak olası güvenlik açıklarını, bugüne kadar karşılaşılan siber saldırı örneklerini ve geleceğe dönük alınması gereken önlemleri ele aldık. Gördük ki OCPP, OCPI, OCHP gibi standartlar işlerimizi kolaylaştırsa da, hatalı yapılandırma veya eski sürüm kullanımı ciddi zafiyetlere yol açabiliyor. E-roaming konsepti, kullanıcı deneyimini zenginleştirirken, kimlik doğrulama ve veri bütünlüğü konularında ekstra özen gerektiriyor. Multi-tenant bulut platformları esneklik sunarken, yalıtım hataları zincirleme etkilere sebep olabiliyor. Mobil uygulamalar konfor sağlarken, saldırganlar için bir diğer giriş kapısı olabiliyor. Yönetim panelleri operasyonu etkinleştirirken, arka kapıları açık kaldığında tüm ağı riske atabiliyor.

İyi haber şu ki, sektör bu risklerin farkında ve gerek standart geliştirmeleriyle (örneğin ISO 15118 gibi), gerek regülasyonlarla (örneğin GDPR) güvenliği artırmaya yönelik adımlar atılıyor. Ancak standart ve kural koymak tek başına yetmez; uygulama çok önemli. Hem üreticilere hem operatörlere düşen ödevler var: Güvenli yazılım geliştirme pratiği, düzenli testler, kullanıcı eğitimi ve şeffaf bir güvenlik politikası izlemek bunlardan bazıları. Yalnızca bir tane açık noktayı hedef alan bir saldırı bile, hem maddi kayıp hem de can güvenliği riski oluşturabilir (düşünün ki bir saldırgan aynı anda yüzlerce hızlı şarj cihazını kapatıp açarak şebekede dalgalanma yaratıyor). Bu nedenle siber güvenlik, EV altyapılarının ayrılmaz bir parçası olmak zorunda.

Sonuç olarak, elektrikli araç devrimi yaşanırken, bu devrimin sürdürülebilirliği için siber güvenliğin göz ardı edilmemesi gerekiyor. Tıpkı araçların emniyet testlerinden geçirilmesi gibi, şarj istasyonları ve yazılımları da ciddi güvenlik testlerinden geçmeli. Kullanıcılar da kendi üzerlerine düşeni yaparak hesaplarına ve verilerine sahip çıkmalı. Ancak bu şekilde, hem kullanıcıların hem operatörlerin güvenine sahip, dayanıklı bir EV şarj ekosistemi inşa edebiliriz. Güvenlik açıkları kapatılmış, dersler alınmış ve en iyi uygulamalar hayata geçirilmiş bir altyapı, elektrikli araç dönüşümünün itici güçlerinden biri olacaktır.

Dipnot: Bu makalede belirtilen örnek senaryoların bir kısmı gerçek olaylardan derlenmiş, bir kısmı ise olası durumları anlatmak için kurgulanmıştır. Verilen tüm teknik bilgiler, referans kaynaklar ve raporlara dayandırılmaya çalışılmıştır. Siber güvenlik dinamik bir alan olduğu için, en güncel tehdit ve önlemlerin takibi önemle tavsiye edilir. (Info & whitepapers — Open Charge Alliance)