IoT güvenliğinde 2026'nın en önemli değişikliği teknik değil, hukuki. Avrupa Birliği Cyber Resilience Act (Regulation (EU) 2024/2847) yürürlükte ve takvimi işliyor: Madde 71'e göre düzenleme genel olarak 11 Aralık 2027'de uygulanmaya başlıyor, ancak Madde 14 (üreticilerin bildirim yükümlülükleri) 11 Eylül 2026'dan, Bölüm IV (Madde 35-51) ise 11 Haziran 2026'dan beri uygulanıyor. AB pazarına dijital unsur taşıyan ürün satan bir Türk üretici için bu, ürün geliştirme planına giren bir kısıt. Bu yazı, o kısıtın teknik karşılığını ve sahada gerçekten kırılan noktaları anlatıyor.
ETSI EN 303 645: kontrol listesi olarak kullanılabilecek tek standart
Tüketici IoT güvenliğinde temel referans ETSI EN 303 645 V3.1.3 (Eylül 2024), tam adıyla "CYBER; Cyber Security for Consumer Internet of Things: Baseline Requirements". Yapısı kontrol listesi olarak kullanmaya elverişli: 5. maddede 63 provizyon, 6. maddede (veri koruma) 8 provizyon. Uyum değerlendirmesi için ayrı bir belge var: ETSI TS 103 701.
5. maddenin başlıkları, bir IoT ürününün güvenlik gereksinim listesi olarak doğrudan kopyalanabilir:
| Madde | Başlık |
|---|---|
| 5.1 | No universal default passwords |
| 5.2 | Implement a means to manage reports of vulnerabilities |
| 5.3 | Keep software updated |
| 5.4 | Securely store sensitive security parameters |
| 5.5 | Communicate securely |
| 5.6 | Minimize exposed attack surfaces |
| 5.7 | Ensure software integrity |
| 5.9 | Make systems resilient to outages |
| 5.11 | Make it easy for users to delete user data |
| 5.13 | Validate input data |
Provizyon 5.1-1'in metni, "varsayılan şifreyi değiştirin" tavsiyesinden çok daha bağlayıcı: parolalar kullanıcı doğrulaması veya makineden makineye kimlik doğrulama için kullanılıyorsa ve fabrika varsayılanı dışındaki herhangi bir durumda, tüm tüketici IoT cihaz parolaları cihaz başına benzersiz olmalı veya kullanıcı tarafından tanımlanmalı (bkz. ETSI EN 303 645 V3.1.3, madde 5.1-1). 5.1-2 ise önceden yüklenmiş cihaz başına benzersiz parolaların, bir cihaz sınıfına veya tipine karşı otomatik saldırı riskini azaltan bir mekanizmayla üretilmesini istiyor.
İkinci cümle, seri numarasından türetilen parolaları doğrudan dışarıda bırakıyor. Seri numarası tahmin edilebilir; dolayısıyla ondan türetilen parola da tahmin edilebilir.
Mirai neden hâlâ ders: 62 satırlık bir sözlük
CISA'nın 14 Ekim 2016 tarihli TA16-288A uyarısı, Mirai'nin çalışma biçimini tek cümleyle anlatıyor: bot, savunmasız cihazları taramak için 62 yaygın varsayılan kullanıcı adı ve parolanın kısa bir listesini kullanıyor. Aynı uyarı, bu kısa sözlüğün yüz binlerce cihaza erişim sağladığını belirtiyor.
Buradaki ders ölçek değil oran: 62 satırlık bir liste, yüz binlerce cihazı ele geçirmeye yetti. Bu, IoT güvenliğinde saldırganın karmaşık araçlara ihtiyacı olmadığını gösteriyor. Cihazınız internete açık bir yönetim arayüzü ve ortak bir varsayılan parola taşıyorsa, sizi hedef alan bir saldırgana gerek yok; arka planda çalışan bir tarayıcı bulacak.
Uyarının yayın tarihi dikkate değer: 14 Ekim 2016, yani sıklıkla anılan büyük DNS kesintisinden bir hafta önce. Yani problem bilinir hâldeydi ve yine de gerçekleşti. Bilinen bir zafiyetin varlığı, onun kapatılacağı anlamına gelmiyor.
Sahada gerçekten kırılan beş nokta
Standart listesi bir kontrol aracı; aşağıdakiler ise uygulamada tekrar eden somut hatalar.
1. Güncelleme mekanizması olmayan cihaz. ETSI 5.3'ün konusu bu ve en pahalıya patlayanı. Uzaktan bellenim güncellemesi yoksa, keşfedilen her zafiyet saha ziyareti demek.
Güncelleme mekanizmasını ilk sürüme koyun, ilk güncellemeyi göndermeye gerek olmasa bile. Sonradan eklenemiyor, çünkü eklemek için güncelleme göndermeniz gerekiyor.
2. İmzasız bellenim. ETSI 5.7 "yazılım bütünlüğünü sağlayın" diyor. Pratikte bu, cihazın yalnızca sizin özel anahtarınızla imzalanmış bellenimi kabul etmesi demek. İmza doğrulaması yoksa güncelleme mekanizmanız bir saldırı yüzeyine dönüşüyor: saldırgan kendi bellenimini yükleyebiliyor.
3. Filo geneli paylaşılan sır. Tek bir istemci sertifikası veya tek bir MQTT parolası tüm cihazlarda. Bir cihaz sökülüp belleği okunduğunda tüm filo açılıyor ve tek bir cihazı iptal edemiyorsunuz.
Doğrusu cihaz başına X.509 sertifikası ve karşılıklı TLS. Bulut tarafında model bu yönde: AWS IoT Core'un dokümanı üç kimlik türü sayıyor (X.509 istemci sertifikaları, IAM kimlikleri, Cognito kimlikleri) ve tipik olarak cihazların X.509 kullandığını belirtiyor; Azure IoT Hub tarafında SAS yolu seçildiğinde cihaz kaydında iki simetrik anahtar üretiliyor ve MQTT CONNECT paketinde Username {iothubhostname}/{deviceId}, Password SAS token oluyor (bkz. AWS IoT Core, Client authentication ve Microsoft Learn, Azure IoT Hub SAS).
4. TLS var ama sertifika doğrulaması kapalı. Gömülü istemcilerde en sık görülen kısayol: kök sertifika deposu yönetmemek için doğrulama devre dışı bırakılıyor. Şifreleme çalışıyor, kimlik doğrulama çalışmıyor; ortadaki adam saldırısına tamamen açıksınız. Kök sertifikayı cihaza gömün ve süresinin dolacağı tarihi ürün yol haritanıza yazın.
5. Üretim ve geliştirme aynı kimlik alanında. Test cihazlarının üretim brokerına bağlanabilmesi, güvenlik sınırını siliyor. Ayrı sertifika otoritesi, ayrı broker, ayrı konu ağacı.
Cyber Resilience Act: takvim ve somut yükümlülükler
Regulation (EU) 2024/2847, 23 Ekim 2024 tarihli ve Avrupa Birliği Resmî Gazetesi'nde 20 Kasım 2024'te yayımlandı. Tam adı "dijital unsur taşıyan ürünler için yatay siber güvenlik gereksinimlerine ilişkin" düzenleme (bkz. Regulation (EU) 2024/2847). Madde 71'deki takvim:
- Düzenleme, yayımını izleyen yirminci günde yürürlüğe girdi.
- Bölüm IV (Madde 35-51): 11 Haziran 2026'dan itibaren uygulanıyor.
- Madde 14: 11 Eylül 2026'dan itibaren uygulanıyor.
- Düzenlemenin geneli: 11 Aralık 2027 (bkz. Regulation (EU) 2024/2847, md. 71).
Türkiye'de üretip AB'ye satan bir donanım veya bağlantılı ürün üreticisi için bunun anlamı, ürün belgelendirme sürecine siber güvenlik gereksinimlerinin eklenmesi. Bunu bir uyum projesi olarak 2027'ye bırakmak, o tarihte ürün tasarımını değiştirmek demek. ETSI EN 303 645'e göre bugün tasarlamak, o dönüşümün büyük kısmını halletmiş oluyor.
Ağ tarafı: cihazı ağa değil, ağı cihaza kapatın
IoT cihazları genellikle en zayıf halka ve kurumsal ağda diğer sistemlerle aynı segmentte duruyorlar. Üç somut kural:
- Ayrı VLAN ve giden trafik beyaz listesi. Cihazın internete erişmesi gerekiyorsa yalnızca kendi bulut uç noktasına erişsin. IoT segmentinden kurumsal dosya sunucusuna giden trafik olmamalı.
- Gelen bağlantı yok. Cihaz dışarıdan bağlantı kabul etmesin; bağlantıyı her zaman cihaz kursun. Bu, port yönlendirme ihtiyacını ve dolayısıyla internete açık yönetim arayüzlerini ortadan kaldırıyor.
- Anomali eşiği. Bir sıcaklık sensörünün günlük veri hacmi öngörülebilir. Beklenenden on kat fazla veri gönderen bir cihaz, ya bozulmuş ya ele geçirilmiş. Bu eşiği tanımlamak ucuz ve erken uyarı veriyor.
MQTT kullanıyorsanız yetkilendirmeyi konu ağacına bağlayın: cihaz yalnızca kendi kimliğini içeren dala yazabilsin, yalnızca kendi komut dalını okuyabilsin. Konu tasarımının bunu mümkün kılacak şekilde kurulması gerekiyor; ayrıntısı MQTT 5.0 yazısında.
Kabul kriterine çevirin
Yukarıdakileri bir tedarik şartnamesine veya kendi ürün kabul kriterinize dönüştürmek, bu yazının asıl çıktısı. Sekiz maddelik hâli:
- Cihaz başına benzersiz kimlik bilgisi; seri numarasından türetilmiş olmayacak (ETSI 5.1).
- Uzaktan bellenim güncellemesi ilk sürümde çalışır durumda (ETSI 5.3).
- Bellenim imzalı; cihaz imzasız yüklemeyi reddediyor (ETSI 5.7).
- Tüm iletişim TLS üzerinden ve sunucu sertifikası doğrulanıyor (ETSI 5.5).
- Hassas parametreler güvenli depoda; bellek dökümünde düz metin anahtar çıkmıyor (ETSI 5.4).
- İnternete açık yönetim arayüzü veya açık port yok (ETSI 5.6).
- Zafiyet bildirimi için tanımlı bir iletişim kanalı ve yanıt süresi var (ETSI 5.2).
- Kullanıcı verisini silme yolu belgelenmiş ve çalışıyor (ETSI 5.11).
Sırada ne var
Elinizdeki cihazı alın ve iki testi yapın. Birincisi: aynı modelden iki cihazın kimlik bilgileri farklı mı? İkincisi: sunucu sertifikasını geçersiz bir sertifikayla değiştirdiğinizde cihaz bağlantıyı reddediyor mu? İki testin de cevabı hayırsa, diğer her şeyden önce bunları düzeltin; geri kalan önlemler bu ikisi olmadan anlamsız.
IoT projelerinde çalışma biçimimizi IoT ve akıllı sistemler sayfasında, güvenlik başlıklarını güvenlik merkezi sayfasında bulabilirsiniz. Sızma testi bulgularını önceliklendirme yaklaşımı pentest raporundaki açıklar yazısında; kapsam görüşmesi için iletişim sayfası uygun yer.
Standart ve mevzuat atıfları 25 Eylül 2026 tarihinde doğrulanmıştır: ETSI EN 303 645 V3.1.3 (2024-09) metni ve provizyon 5.1-1, 5.1-2; CISA uyarısı TA16-288A (14.10.2016); Regulation (EU) 2024/2847 md. 71 (OJ 20.11.2024); AWS IoT Core istemci kimlik doğrulama dokümanı; Azure IoT Hub SAS kimlik doğrulama dokümanı. Mevzuat takvimleri değişebilir; uyum planı yapmadan önce güncel metni teyit edin.
