cihaz sertifikası X.509 - Ödev Yaptırma & Danışmanlık Merkezi

Elektrik Elektronik Mühendisliği Ödev Yaptırma: IoT Güvenlik Protokollerinde TLS Uygulamaları

İçerik Üreticisi — Wed, 17 Sep 2025 07:00:05 +0000

IoT ekosisteminde cihazlar; sensörler, aktüatörler, geçitler (gateway), bulut/edge hizmetleri ve yönetim platformlarından oluşan parçalı bir mimari içinde konuşur. Bu konuşmanın dili çoğu zaman MQTT, CoAP, HTTP/REST, OPC UA, AMQP gibi protokollerdir. Ancak hangi uygulama protokolünü seçerseniz seçin, transport katmanında TLS/DTLS(Transport Layer Security / Datagram TLS) doğru kurgulanmadıkça verinin gizliliği, bütünlüğü ve uçların kimliği garanti altına alınamaz. IoT’de TLS sadece “şifreli kanal açma” değildir; kök güven (root of trust), PKI ve sertifika yaşam döngüsü, karşılıklı kimlik doğrulama (mTLS), oturum sürdürme (resumption), 0-RTT riskleri, cipher suite seçimi, donanım güven öğeleri (SE/TPM), otonom sertifika yenileme, performans–enerji dengesi, edge–bulut arası güven zinciri, OTA ve cihaz devreye alma (onboarding) gibi uçtan uca süreçlerin göbeğinde durur.

1) TLS/DTLS Temelleri: Neyi, Neden ve Nasıl Koruyoruz?

TLS, TCP tabanlı akışlar için uçtan uca gizlilik (confidentiality), bütünlük (integrity) ve kimlik doğrulama (authentication) sağlar. DTLS, UDP için TLS’in uyarlanmış halidir; CoAP gibi hafif, mesaj temelli protokoller için vazgeçilmezdir.

Gizlilik: Simetrik şifreleme (AES-GCM/ChaCha20-Poly1305).
Bütünlük: AEAD ile şifre-mak (GCM/Poly1305) veya HMAC.
Kimlik: Sertifika (X.509) ile sunucu/müşteri doğrulaması veya PSK.
Anahtar değişimi: ECDHE (kısmi ileri gizlilik), PSK-DHE, vb.
IoT’de ihtiyaç: Kamu interneti, saha–edge, edge–bulut bağlantılarında dinlemeye ve sahte uçlara karşı güven; komut/telemetri manipülasyonlarını engelleme; cihaz filosunda otomatik, güvenli devreye alma ve kimlik döndürme.

2) TLS 1.2 vs TLS 1.3: IoT İçin Neden 1.3?

Daha hızlı el sıkışma: 1-RTT; 0-RTT (isteğe bağlı) ile daha az gecikme (fakat yeniden oynatma riski—bkz. §13).
Basitleştirilmiş şifre kümesi: RSA key exchange ve zayıf kümeler (CBC, RC4) elendi.
Zorunlu ileri gizlilik: ECDHE dayalı.
Şema: Early Data, HelloRetryRequest, EncryptedExtensions.
IoT tavsiyesi: Yeni projelerde TLS 1.3 hedefleyin; 1.2 sadece geriye uyumluluk gerekiyorsa açık kalsın. DTLS 1.3tarafında da benzer kazanımlar mevcut.

3) MQTT Üzerinde TLS (MQTTS) — Broker Merkezli Güven

MQTT, pub/sub yapısı ve hafifliğiyle IoT’nin yıldızı. Güven katmanı:

mTLS: Cihaz–broker karşılıklı sertifikayla doğrulanır. Konu (topic) tabanlı yetki (ACL) cihazın sadece kendi topic’lerine erişmesini sağlar.
ALPN: Aynı TCP/443 üzerinde h2, mqtt seçimi; bulut tarafında ters vekil (reverse proxy) ile ortak port kullanımı.
SNI: Sanal çoklu barındırma; cihaz doğru broker’a yönelir.
Oturum/resumption: El sıkışmayı hızlandırır; pil ömrünü korur.
Uygulama tüyosu: Cihaz kimlikleri CN/SAN içinde cihaz seri-ID veya kayıt ID ile bağlanmalı; broker tarafında Sertifika–Topic eşleme kullanın (örn. “CN=device-123 → allow ‘/site/123/#’ ”). mTLS başarısızlığında default deny.

4) CoAP Üzerinde DTLS ve OSCORE Karşılaştırması

CoAP+DTLS, UDP üzerinde uçtan uca şifreli kanaldır. OSCORE ise nesne katmanında uçtan uca koruma sunar (proxy’lerden geçerken de korur).

DTLS 1.2/1.3: El sıkışma maliyeti daha yüksek; CID (Connection ID) ile NAT & sleep dostu.
OSCORE: Grup/çoknokta için iyi; ama anahtar yönetimi ayrı.
Karar: Proxy-ağ geçitli yapılarda uçtan uca koruma gerekiyorsa OSCORE düşünebilirsiniz; ancak cihaz–broker/benek ilişkisinde DTLS yaygın ve kütüphane desteği güçlüdür.

5) HTTP/REST ve AMQP Üzerinde TLS: Bulut API Güvenliği

Cihazlar doğrudan HTTPS ile bulut API’larına veri atabilir. TLS 1.3 + mTLS ile istemci sertifikası kontrolü; JWTsadece ek yetkilendirme katmanı olmalı (kimlik için sertifika kaynağını gizlemeyin). AMQP 1.0 tarafında da TLS aynen geçerli; kuyruğa bağlanma öncesi mTLS.

6) OPC UA Security ve TLS

OPC UA uygulama/beklenti düzleminde güvenlik içerir; ancak TCP taşıma katmanında da TLS/SecureChannel yapı taşlarını kullanır.

Sertifika güveni: Uygulama sertifikaları, güvenli uç (trust list) yönetimi.
Rol tabanlı yetki: UA sunucu içinde ilave güvenlik.
Endüstriyel ipucu: Saha–IT arasında DMZ ve TLS sonlandırma yapmayın; mümkünse uçtan uca UA güvenliğini ve mTLS’i koruyun.

7) Kimlik ve Yetkilendirme: PSK mı mTLS mi?

PSK (Önceden paylaşılan anahtar): Mikro denetleyicilerde hızlı ve hafif; filo ölçeğinde anahtar yönetimi zor(kopyalanma/dağıtım riski).
mTLS (Karşılıklı TLS): Cihaz başına sertifika → güçlü kimlik; PKI gerektirir.
Öneri: Üretimde mTLS standardınız olsun; PSK sadece geçici bootstrap veya çok sınırlı, kapalı sahalarda.

8) PKI Tasarımı ve Sertifika Yaşam Döngüsü

Cihaz kimliği X.509 sertifikaları ile sağlanır.

Kök/ara CA (offline/online); kayıt otoritesi (RA), CRL/OCSP.
Bootstrap sertifikası: Kayıt esnasında en az yetkili kimlik; mTLS ile kayıt/belgelendirme hizmetine bağlanıp kısa ömürlü üretim sertifikası alınır.
Yenileme ve iptal: Near-expiry telemetri; OCSP stapling ile iptal durumunu hızlı kontrol.
Süreler: Sunucu 1–2 yıl; cihaz sertifikası 90 gün–1 yıl; kısa ömür saldırı penceresini daraltır.

9) Cihaz Üretim Hattında Anahtar Enjeksiyonu ve Donanımsal Güven

Güvenin kökü, özel anahtarın çip dışına hiç çıkmamasıdır.

SE/TPM/HSM: Özel anahtar donanım güven öğesinde üretilir ve saklanır.
Secure Boot & Measured Boot: Sadece imzalı firmware; uzaktan doğrulama (attestation).
Sertifika kişiselleştirme: Üretim hattında CSR donanım içinden; CA sertifika imzalar; cihaz kutudan güvenli çıkar.

10) Kütüphaneler ve Yığınlar: Mbed TLS, wolfSSL, TinyDTLS, OpenSSL

Mbed TLS/wolfSSL: Gömülü hedefler için hafif; TLS 1.3 desteği; mTLS, PSK, ECDHE, ChaCha20-Poly1305.
TinyDTLS: DTLS için minimal ayak izi; CoAP yığınlarıyla birlikte.
OpenSSL/BoringSSL/wolfSSL (linux side): Edge/gateway üzerinde güçlü hızlandırma, AES-NI/ARMv8 Crypto.
Pratik: MCU’nun kripto hızlandırıcısı varsa (AES-GCM, SHA), donanımı kullanın; yoksa ChaCha20-Poly1305CPU-dostu olabilir.

11) Şifre Kümeleri (Cipher Suites) ve Eğriler

TLS 1.3: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256 yaygın ve yeterli.
KNC: ECDHE için X25519 veya P-256; sertifika imzasında Ed25519/ECDSA P-256.
RSA’dan kaçış: RSA-2048 imzalar sunucu sertifikasında kalabilir; key exchange asla RSA olmasın.
İpucu: Düşük güçlü MCU’da ChaCha20-Poly1305 + X25519 + Ed25519 iyi denge sağlar.

12) El Sıkışma Optimizasyonu: Resumption, Tickets, PSK + DHE

Session Resumption (PSK tickets): Daha az CPU ve RTT; cihaz uykudan uyanınca hızlı bağlanır.
DTLS CID: Adres/NAT değişse de oturum sürer.
Sınır: Ticket sızıntısı riskine karşı kısa ömürlü ve ciddi entropi şart; oturum anahtarlarını düzenli döndürün.

13) 0-RTT (Early Data) — Ne Zaman Kullanmalı?

0-RTT el sıkışmayı beklemeden veri gönderir → gecikme düşer. Ancak yeniden oynatma (replay) riskini getirir.

MQTT publish gibi idempotent olmayan işlemlerde 0-RTT kapalı olmalı.
CoAP GET gibi idempotent isteklerde bile zaman/açık pencere sınırlamaları koyun.
Kural: IoT’de 0-RTT çoğunlukla devre dışı; hız kazanımı yerine bütünlük/tekrar engeli daha kıymetli.

14) Kimlik Sağlayıcı ve Yetki: mTLS + RBAC/ABAC

TLS kimliği “kimsin?” sorusunu çözer, “ne yapabilirsin?” sorusunu RBAC/ABAC ile cevaplayın.

MQTT ACL: Sertifika CN/SAN → topic izinleri.
CoAP/HTTP: TLS sonrası token (kısa ömürlü) ile ilave kapsam.
OPC UA: Dahili role-policy haritaları.
Not: Kimlik ve yetki log’larını imzalı tutun; denetimde kanıt verin.

15) Ağ ve Dağıtım Mimarileri: Sidecar, Termination, Passthrough

Uçtan uca mTLS: En güvenlisi; broker/uygulama uçlarında sonlandırılır.
Sidecar TLS: Zayıf cihazlar için TLS’yi yakın gateway veya sidecar mikroservis üstlenir; cihaz–sidecar arası kısa ve korumalı ağ olmalı.
Terminatör (reverse proxy): L7 politikalar; iç bacakta da mTLS’yi korumaya çalışın (aksi takdirde kör nokta oluşturur).

16) Wi-Fi Enterprise ve EAP-TLS

Sahada IoT cihazlarının Wi-Fi’a güvenli katılımı için WPA2/WPA3-Enterprise + EAP-TLS altını çizin.

Cihaz sertifikası ile WLAN kimliği; PSK yerine bireysel kimlik.
RADIUS/IdP ile sertifika denetimi ve erişim politikası.
Fayda: Wi-Fi katmanı daha güvenli; uygulama TLS’i ile çift katman.

17) BLE/Thread/6LoWPAN: TLS’in Yeri

BLE bağlantılarında L2CAP üstünde GATT; LE Secure Connections ECDH ile eşleşir. Uygulama verisini yine TLS üzerinden geçirmek masraflıdır; çoğunlukla link-layer güvenliği + uygulama imzası yeterlidir. Thread/6LoWPAN IPv6 taşıdığı için DTLS/TLS üstte çalışabilir; CoAP+DTLS yaygındır.

18) OTA ve TLS: İmzalı Paket + Güvenli Kanal

Güvenli kanal: TLS ile OTA sunucusuna.
İmzalı paket: OTA binası ayrı imzalı olmalı; TLS kanalı ihlal edilse bile imza doğrulanmadan yazılım kabul edilmesin.
A/B bölüm + rollback: Başarısızlıkta güvenli geri dönüş; ölçümlü başlatma ile atestasyon.

19) Günlükleme ve Görünürlük: mTLS Hataları, İptaller

Hata sınıflandırma: Sertifika süresi doldu, zincir eksik, OCSP başarısız, handshake timeout, cipher mismatch.
Saha gözlemi: Cihaz log’ları özetlenip edge’e; edge → SIEM.
Gizlilik: Kimlikleri hashed/anonymized; ancak kanıta elverişli koruyun.

20) Performans Ölçütleri: El Sıkışma, CPU, Enerji

Metrikler: El sıkışma süresi (p50/p95), ilk publish gecikmesi, TLS CPU zamanı, batarya tüketimi, başarısız handshake oranı.
Optimizasyon: Donanım hızlandırma, ChaCha20-Poly1305, resumption, keep-alive tuning (MQTT), sertifika boyutu (Ed25519).
Kompromis: Uzun oturumlar → düşük el sıkışma maliyeti / anahtar döndürme planı ile denge.

21) Saha Vaka I — MQTT + mTLS ile Sahte Cihaz Engeli

Durum: Üretimde açık TCP ile çalışan 600 sensör; sahte cihazlar broker’a publish ediyordu.
Çözüm: mTLS’e geçiş; CA/RA; cihaz başına sertifika; broker’da CN→topic bağlama; deny-by-default.
Sonuç: Sahte publish denemeleri el sıkışmada kesildi; ACL ihlali 0; el sıkışma gecikmesi resumption ile %65 azaldı.

22) Saha Vaka II — CoAP + DTLS ve Uykudan Uyanma

Durum: Pil ile çalışan vana aktüatörleri; uzun uyku sonrası NAT değişiyor, oturum düşüyordu.
Çözüm: DTLS CID etkin; resumption; mesaj yeniden deneme + idempotent tasarım.
Sonuç: Uyan-gönder-uyu süresi %30 kısaldı; paket kayıplarında bile oturum bozulmadı.

23) Saha Vaka III — EAP-TLS ile Fabrika Wi-Fi Güvencesi

Durum: Paylaşımlı PSK sızmış; cihazlar spoof AP’lere düşüyordu.
Çözüm: WPA2-Enterprise + EAP-TLS; cihaz sertifikaları; RADIUS politikaları.
Sonuç: Ağ katmanında kimlik güvenceye alındı; uygulama TLS’iyle çift katmanlı güven.

24) Sık Hatalar ve Çareleri

RSA key exchange kullanımı: 1.3’e geçin; ECDHE zorunlu.
Uzun/kadük sertifikalar: Kısa ömür + otomatik yenileme.
Self-signed dağınıklığı: Merkezi trust store ve CA hiyerarşisi.
0-RTT yanlış kullanımı: Yalnız idempotent, o da sınırlı; çoğunlukla kapalı.
Broker TLS sonlandırıp iç ağda düz metin: İç bacakta da mTLS veya segmentasyon.
PSK kopyala-yapıştır: Filoda ölçeklenmez; PSK’yi yalnızca bootstrap’te, kısa ömürle.
OCSP/CRL ihmal: İptal kontrolü yoksa sızan anahtar aylarca geçerli kalır.

25) Ödev Raporu Şablonu (Puan Kazandıran)

Tehdit modeli: Aktörler, varlıklar, saldırı yüzeyi.
Protokol seçimi: MQTT/CoAP/HTTP/OPC UA + (D)TLS seçimi ve gerekçe.
TLS sürümü ve cipher politikası: TLS 1.3; AES_128_GCM / CHACHA20_POLY1305; ECDHE X25519; imza Ed25519/ECDSA-P256.
Kimlik mimarisi: mTLS vs PSK; cihaz sertifika ömrü; CN/SAN şeması.
PKI ve operasyon: CA/RA, bootstrap, yenileme, OCSP/CRL, trust store.
Cihaz güven kökü: SE/TPM, secure boot, measured boot.
Performans: El sıkışma süresi, CPU/pil, resumption; p95 metrikleri.
Ağ mimarisi: DMZ, sidecar/termination, iç bacak güvenliği.
Yetkilendirme: ACL/RBAC/ABAC; topic/payload kapsamı.
Gözlemlenebilirlik: TLS olay telemetrisi; SIEM entegrasyonu.
OTA güvenliği: İmzalı paket + TLS; A/B + rollback.
Test planı: Pen-test, fuzzing (ClientHello/Record), masaüstü tatbikatı.
Mevzuat ve standart eşlemesi: IEC 62443, ISO 27001, NIS2 (varsa).
Sonuç ve yol haritası: Kalan riskler, dönemsellik, anahtar döndürme.

26) 10 Günlük Uygulanabilir Proje Planı

Gün 1: Tehdit modeli ve protokol haritası (MQTT/CoAP/HTTP/OPC UA).
Gün 2: TLS 1.3 şifre politikası; kitaplık seçimi (Mbed TLS/wolfSSL).
Gün 3: PKI taslağı; CA/RA; bootstrap akışı; CN/SAN şeması.
Gün 4: Cihazda mTLS PoC; broker/CoAP sunucu konfigürasyonları; ALPN/SNI.
Gün 5: Donanım güven öğesi (SE/TPM) entegrasyonu; CSR cihaz içi.
Gün 6: Resumption/DTLS-CID; 0-RTT kapatma; keep-alive/timeout ayarları.
Gün 7: ACL/RBAC politikaları; yetki ve log şeması.
Gün 8: OTA imzalama zinciri; A/B + rollback; güvenli kanal testi.
Gün 9: Performans ölçümleri (p50/p95 handshake, CPU, pil); fuzz/pen-test basamakları.
Gün 10: Dökümantasyon, IRP (olay müdahalesi), sertifika yenileme otomasyonu.

27) Konfigürasyon Örnekleri (Uygulama Notları)

Broker tarafı (konsept):
- require_client_cert = true
- tls_version = TLSv1.3
- cipher_suites = TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256
- alpn_protocols = mqtt
- acl: CN=device-(\d+) → allow /site/\1/#
Cihaz tarafı:
- Sertifika/özel anahtar SE içinde; kütüphane SE API’si ile imzalama.
- verify_server_cert = true, check_ocsp = stapled_required.
- session_resumption = enabled, 0rtt = disabled.

28) Gecikme–Enerji İyileştirme İpuçları

Keep-alive tuning: MQTT’de çok kısa keep-alive pil tüketir, çok uzun network NAT zaman aşımına takılır; 5–15 dk bandında deney.
ALPN & 443 paylaşımı: Güvenlik duvarlarından kolay geçiş; port kısıtları olan sahalarda başarı.
ChaCha20-Poly1305: Donanım AES’siz MCU’larda enerji tasarrufu.

29) Emniyet–Güvenlik Etkileşimi

Güvenlik kontrolleri safety işlevlerini gölgelememeli. E-Stop gibi güvenlik kritik komutlar lokal donanım üzerinden çalışırken, uzaktan komutların TLS + çift onay ve rate-limit ile korunması gerekir.

30) Denetim (Audit) ve Kanıtlanabilirlik

Sertifika yaşam döngüsü, politika değişiklikleri, OTA imza anahtarları, ACL güncellemeleri denetlenebilir olmalı. İmzalı günlükler ve zaman damgası ile kanıt zinciri oluşturun; chain-of-custody’yi koruyun.

Sonuç

IoT’de TLS/DTLS uygulaması, yalnızca “şifreleme açık” kutucuğunu işaretlemek değildir; cihaz kimliğinin doğduğu üretim hattından sahadaki el sıkışma gecikmesine, broker yetkisinden OTA imza zincirine, session resumptionoptimizasyonlarından OCSP/CRL iptal yönetimine kadar uçtan uca bir mimari ve operasyon meselesidir. Başarılı bir ödev/bitirme projesi; TLS 1.3’ün hız ve güvenlik kazanımlarını, mTLS ile güçlü cihaz kimliğini, PKI ve donanım güven öğeleri ile kök güveni tesis edip otomatik sertifika yenileme ve kısa ömürlü kimlik politikalarıyla sürdürülebilir kılar.

Bu yazıda; MQTT/CoAP/HTTP/OPC UA üzerinde TLS’in nasıl doğru konumlandırılacağını, PSK’nin neden yalnızca çok sınırlı senaryolara uygun olduğunu, ALPN/SNI gibi küçük ama kritik detayların operasyonel faydasını, 0-RTT’nin IoT’de neden çoğu kez kapalı olması gerektiğini, resumption/DTLS-CID ile uykudan uyanma ve NAT sorunlarının nasıl aşıldığını gösterdik. Ayrıca WPA2-Enterprise + EAP-TLS ile ağ katmanında kimliği güçlendirerek uygulama katmanındaki TLS’e “ikinci bir zırh” sunduk; OTA’da sadece kanalın değil paketin de imza ile güvenceye alınması gerektiğini vurguladık.

Ödev raporunuzu tehdit modeli → protokol seçimi → TLS politikası → PKI ve cihaz kimliği → performans → izleme → test/tatbikat → mevzuat akışında kurgulayın. El sıkışma p95, başarısız handshake oranı, CPU/pil etkisi, yeniden oynatma simülasyonları, ACL ihlali metrikleri ve OTA imza doğrulama kayıtları ile kanıt üretin. Unutmayın: IoT’de güvenlik bir ürün değil, süreçtir. Anahtarlar döner, sertifikalar yenilenir, protokoller evrilir; TLS mimariniz de ölçeklenebilir, gözlemlenebilir ve geri döndürülebilir olmalıdır.

Öğrencilerin akademik başarılarını desteklemek ve yoğun tempoda geçen okul yaşamlarında yardımcı olmak amacıyla kurulan “Ödev Yaptırma” platformu, özgün ve kaliteli ödev çözümleri sunmaktadır. Öğrencilerin farklı branşlardan ödevlerini, projelerini ve makalelerini profesyonel ve deneyimli ekip üyelerimiz aracılığıyla titizlikle hazırlıyoruz. Her bir ödevi, konunun gerektirdiği derinlemesine araştırmalar ve analizler doğrultusunda çözümleyerek, öğrencilerimizin özgün düşünce yapısını ön plana çıkarmasını sağlıyoruz.

“Ödev Yaptırma” olarak, müşteri memnuniyetini ve güvenilirliği en üst düzeyde tutmaktayız. Öğrencilerin bize teslim ettikleri ödevlerin tümü, gizlilik ve güvenlik ilkelerine sıkı sıkıya bağlı kalınarak işlenir. Her ödev, öğrencinin taleplerine ve öğretmenin yönergelerine uygun olarak özelleştirilir ve her zaman orijinal içerik üretmeye özen gösteririz. Öğrencilerin akademik itibarını korumak ve güvenilir bir öğrenme deneyimi sunmak için elinizdeyiz.

“Ödev Yaptırma” platformu, kullanıcı dostu arayüzü sayesinde öğrencilere kolayca ulaşılabilir bir hizmet sunmaktadır. Kullanıcılar, web sitemiz üzerinden basit adımlarla ödevlerini yaptırma taleplerini iletebilir ve ihtiyaç duydukları konuda uzmanlaşmış ekip üyelerimizle iletişime geçebilirler. Hızlı yanıt verme ve esneklik, öğrencilerin zaman baskısı altında olan durumlarında da yanlarında olduğumuzu hissettirir. “Ödev Yaptırma” olarak, öğrencilerin başarısını desteklemek ve onlara daha fazla öğrenme fırsatı sunmak için buradayız

The post Elektrik Elektronik Mühendisliği Ödev Yaptırma: IoT Güvenlik Protokollerinde TLS Uygulamaları first appeared on Ödev Yaptırma & Danışmanlık Merkezi.

Elektrik Elektronik Mühendisliği Ödev Yaptırma: Endüstride IoT Uygulamaları için Güvenlik Katmanı

İçerik Üreticisi — Thu, 11 Sep 2025 09:00:53 +0000

Endüstriyel Nesnelerin İnterneti (IIoT), sahadaki sensörler, aktüatörler, PLC/RTU’lar, ağ geçitleri ve bulut/edge analitik platformlarını tek bir sinir sistemine dönüştürür. Bu sinir sistemi üretim verimliliği, kestirimci bakım, enerji optimizasyonu ve esnek otomasyon gibi görkemli vaatler sunarken; aynı zamanda saldırı yüzeyini de geometrik olarak büyütür: sahadaki çıplak seri hatlardan zayıf parolalı MQTT broker’lara, güvenliği yanlış yapılandırılmış OPC UA uçlarından imzasız OTA paketlerine kadar pek çok kırılgan dikiş vardır. Bir Elektrik–Elektronik Mühendisliği ödevinde veya bitirme projesinde “IIoT güvenlik katmanı”, yalnızca TLS açmak ya da bir güvenlik duvarı koymak değildir; kimlik ve yetkilendirme, güvenli önyükleme ve imzalı yazılım, ağ segmentasyonu ve sıfır güven (Zero Trust), sertifika/anahtar yaşam döngüsü, günlükleme ve olay müdahalesi, emniyet (safety) ile güvenliğin (security) etkileşimi, tedarik zinciri ve saha gerçeklerinin tamamını kapsayan bir mimari problemdir.

1) Tehdit Modeli ve Güvenlik Hedefleri: “Kime karşı, neyi koruyoruz?”

Bir güvenlik mimarisinin başlangıç noktası tehdit modelidir. Aktörleri (iç tehdit, dış saldırgan, tedarikçi, meraklı çalışan), varlıkları (cihaz kimliği, firmware, ölçüm verisi, kontrol komutu, sertifikalar, anahtarlar), saldırı yüzeylerini (radyo, Ethernet, seri hat, fiziksel portlar, tedarik kanalı) ve etkileri (durma, kalite kaybı, güvenlik ihlali, veri sızıntısı) tanımlayın. Güvenlik hedefleri: gizlilik, bütünlük, erişilebilirlik, inkâr edilemezlik, güvenli güncelleme ve gözlemlenebilirlik.
Ödev tüyosu: STRIDE/PASTA gibi metodolojilerden biriyle tablo oluşturun; her saldırı vektörü için karşı önlem ve kalan risk sütunları ekleyin.

2) Cihaz Kimliği ve Kök Güven (Root of Trust)

Bir cihaz güvenilir kimliğe sahip değilse tüm üzerindeki TLS bile “maskeli balo”dur. Donanımsal Güven Kökü (HRoT): güvenli önyükleme (secure boot), ROM içi kök anahtar, güvenli anahtar depolama (TPM/ATECC/SE), fiziksel anti-tamper önlemleri. Cihaz sertifikası (X.509) üretim hattında kişiselleştirme sırasında enjekte edilir; özel anahtar hiçbir zaman çip dışına çıkmaz.
Mini vaka: Saha güncellemesinde çalınmış bir imza anahtarıyla dağıtılan zararlı firmware, HRoT ile engellendi; boot ROM yalnızca üretici kök sertifikası ile imzalanmış imajları kabul etti.

3) Güvenli Önyükleme (Secure Boot) ve Ölçülü Başlatma (Measured Boot)

Secure boot, önyükleme zincirinin her halkasında kriptografik doğrulama yapar (bootloader → işletim sistemi → uygulama). Measured boot ile ölçümler TPM’e yazılır; uzaktaki sunucu uzaktan doğrulama (remote attestation)yapabilir.
Uygulama notu: Çift imaj (A/B) + rollback koruması; başarısız güncellemede güvenli olarak önceki imaja dönüş.

4) Anahtar ve Sertifika Yaşam Döngüsü (PKI)

Cihaz sayısı yüzleri–binleri buldukça PKI yönetimi (CA, ara CA, CRL/OCSP, yenileme, anahtar döndürme/kompromizasyon) operasyonun kalbidir. Kısa ömürlü istemci sertifikaları (örn. 90 gün) saldırı penceresini daraltır. Cihaz ilk kurulumda bootstrap sertifikası ile kayıt otoritesine bağlanır, mTLS için kişisel sertifika alır.
Taktik: Sertifika “near-expiry” için telemetri alarmı ve otomatik yenileme; tedarikçi test sertifikalarıyla üretim sertifikalarını asla karıştırmayın.

5) Protokoller ve Güvenlik: MQTT, CoAP, OPC UA

MQTT: Yayınla-abone (pub/sub), hafif; TLS/mTLS ile güvence; konu (topic) bazlı yetkilendirme; persistent session ve idempotency key ile güvenilirlik.
CoAP: UDP tabanlı; DTLS ile güvence; kaynak kısıtlı cihazlarda iyi.
OPC UA: Endüstriyel veri modeli + yerleşik güvenlik (sertifika, imza/şifreleme, kullanıcı/rol).
Seçim kuralı: Varlık modellemesi ve endüstriyel birlikte çalışabilirlik OPC UA; hafif izleme/telemetri MQTT; enerji/RT kısıtı CoAP. Tümü için mTLS/DTLS, modern TLS sürümleri, güçlü şifre kümeleri şart.

6) Sıfır Güven (Zero Trust) ve Ağ Segmentasyonu

Fabrika LAN’ı “güvenilir” değildir. Mikro-segmentasyon (VLAN/VRF), en az ayrıcalık (least privilege), SDN tabanlıpolitika zorlaması, east–west trafiğin denetimi. Cihazlar yalnızca yetkilendirilmiş broker/OPC UA sunucuları ile konuşur; default deny politika, izin listesi (allowlist) ile açılır.
Pratik: “IoT→IT” yönünde tek yönlü geçit (data diode) veya sıkı API geçidi kullanın; üretim SCADA ile kurumsal bulut arasına DMZ koyun.

7) Kimlik ve Erişim Yönetimi (IAM): İnsan ve Makine

Makine kimlikleri (mTLS sertifikaları) yanında operatör/servis kimlikleri de yönetilmelidir. RBAC/ABAC, kimlik sağlayıcı (IdP), çok faktörlü kimlik doğrulama (MFA), fiziksel erişim (kapı/raf) ve komut yetkilendirme (ör. “acil durdurma” komutu için iki operatör onayı).
Ödev tüyosu: “Komut–kaynak–rol–kısıt” çizelgesi çıkarın; kim hangi cihaz üzerinde hangi koşulda hangi API’yiçağırabilir?

8) Güvenli OTA ve Konfigürasyon Yönetimi

OTA paketleri imzalanmalı, tercihen şifrelenmeli; dağıtım kademeli (canary) yapılmalı; cihaz farklı üretici imzasınıkabul etmemeli. Konfigürasyon değişiklikleri imzalı, versiyonlu ve audit log’lu olmalı.
Mini vaka: Sahada bin cihazlık filoda bir pilot gruba OTA gönderildi; telemetri–sağlık sinyali izlenip sorun görülmeyince kademeli olarak tüm filoya yayıldı; iki cihazda “bozuk imza” tespit edilince otomatik rollback ve olay bildirimi çalıştı.

9) Güvenlik ve Emniyetin Kesişimi: SIL ile Security’nin Diyaloğu

Endüstride safety (SIL/PL) hedefleri kadar security de kritiktir. Güvenlik önlemleri emniyet işlevini geciktirmemeli/engellememeli: örneğin, acil durdurma (E-Stop) hattı güvenlik protokolü doğrulamasını beklemeden lokal donanım üzerinden çalışmalı; fakat E-Stop komutunun uzaktan taklit edilmesini önlemek için fiziksel sinyal + kimlikli komut ikili koşulu gerekir.
Kural: “Güvenli varsayılan” (fail-safe) davranış; güvenlik bileşeni arızasında sistem emniyetli moda düşer.

10) Güvenlik Gözlemlenebilirliği: Günlükleme, Metrikler ve SIEM

İmzalı log, zaman damgası senkronu (NTP/PTP), tekilleştirilmiş cihaz kimliği ve olay şeması (login başarısız, sertifika yenilendi, OTA denendi, policy reddi) olmadan olay incelemesi kördür. Log’lar edge’de özetlenip merkezi SIEM’e akmalı; anomali tespiti (alışılmadık topic, olağandışı veri hızı) uygulanmalı.
Metrikler: Fail auth oranı, expired cert sayısı, mTLS başarısızlığı, OTA başarısız p99, broker deny sayısı, DoS throttling olayları.

11) Zafiyet Yönetimi: SBOM, Tarama, Patch

Cihaz yazılımı için SBOM (Software Bill of Materials) çıkarın; bilinen zafiyetler (CVE) için sürekli tarama yapın. Kernel/OS ve kütüphaneler için yama yönetimi; kırılgan bağımlılıkları (eski OpenSSL, zayıf TLS) tespit ederek sürüm yükseltme.
Tedarik zinciri: Üçüncü taraf bileşenleri (sürücü, kitaplık) için imza ve kaynak bütünlüğü doğrulaması.

12) Fiziksel Güvenlik: Portlar, Kasa, Anti-Tamper

Seri konsol (UART), JTAG/SWD, USB servis portları çoğu saldırının giriş kapısıdır. Port devre dışı, şifreli debug, mühür ve açılma sensörü (tamper switch), pigtail kabloların kelepçelenmesi; kilitli kabin/raf; kamera+lokal alarm.
Uygulama: Bakım için gereken SWD portu kasa içinde bırakıldı; erişim yalnızca mülkiyetli adaptör + OTP token ile ve zaman sınırlı.

13) Saha Haberleşmesi: Seri Hatlar, Fieldbus ve Dönüştürücü Güvenliği

Modbus RTU/ASCII, CANopen, Profibus gibi miras protokoller kimlik doğrulama içermez. Dönüştürücü/gateway katmanında mTLS terminate edip sahaya kural tabanlı proxy uygulayın: “Sadece şu registre, şu aralıkta yazma; oransal hız limiti; komut beyaz liste”. Replay ve flood korumaları ekleyin.
Vaka: Eski bir kazan sistemi Modbus üzerinden “setpoint” yazmayı sınırlayan rate-limit ve değişiklik onayı kuralıyla güvene alındı.

14) Edge Bilişim ile Güvenli Veri Yolculuğu

Edge üzerinde veri temizliği (PII/PHI/iş sırrı çıkarma), hash/pseudonymization, sıkıştırma, imzalama ve şifreleme; buluta yalnızca gerekli özet gider. Gizlilik+performans dengesi için sezgisel kurallar: “Ham veri sadece hata ve kalibrasyon modunda tutulur”, “Anomali bayrağı varsa pencereyi ham olarak gönder”.
Not: Edge cihaz diskleri tam disk şifreleme ile korunmalı; çalınan cihaz veri sızıntısı üretmesin.

15) Performans–Güvenlik Dengesi: TLS Ayarı, Donanım Hızlandırma

Güvenlik “kabul edilemez gecikme” üretmemeli. TLS için oturum yenileme (session resumption), donanımsal kripto hızlandırıcı, mTLS el sıkışma sayısının azaltılması (uzun oturum, kısa sertifika ömrü) ve sıkı ama ekonomik şifre kümeleri.
Ölçüm: El sıkışma süresi, CPU kullanımı, paket başına gecikme, broker throughput; p95/p99 hedefleri dokümante edin.

16) Test, Red Team ve Masaüstü Tatbikatlar

Penetrasyon testi, fuzzing (ör. MQTT topic fuzz), konfig yanlış yapılandırma avı, kırmızı takım tatbikatı. Operasyon ekipleriyle masaüstü tatbikat: “Sertifika yetkilisi çöktü, OTA anahtarı sızdı, broker DoS altında; ilk 60 dakikada ne yaparız?”
Çıktı: Olay müdahale planı (IRP), iletişim ağacı, kanıt toplama ve hukuki zincir.

17) Uyuşum ve Mevzuat: IEC 62443, ISO 27001, NIS2 vb.

Endüstriyel siber güvenlikte IEC 62443 referanstır (bileşen, sistem, süreç gereklilikleri). Kurumsal bilgi güvenliği için ISO/IEC 27001; elektrik/enerji gibi sektörlerde ek regülasyonlar (ör. NIS2).
Ödev tüyosu: Projenizde “standart–gereklilik–kanıt” matrisi hazırlayın: ör. “IEC 62443-4-2 CR 1.4 → mTLS + CA yönetimi → sertifika logları”.

18) Gizlilik (Privacy) ve Üretim Verisi

Her üretim verisi kritik ticari bilgi olabilir. Veri sınıflandırma; erişim politikası (en az ayrıcalık); veri maskeleme ve agregasyon; saklama süreleri ve imha.
Pratik: Telemetride cihaz seri numarasını göndermek yerine anonim cihaz kimliği (hash) yayınlayın; eşlemeyi yalnızca PKI altyapınız bilsin.

19) Saha Dağıtımı: Sürüm, Konfig ve Envanter Yönetimi

Binlerce cihazda kim hangi sürümde sorusu yanıtlanmadan güvenlik yönetilemez. CI/CD boru hattı, imzalı artefakt deposu, envanter (donanım revizyonu, OS, uygulama, sertifika bitiş tarihi), politika uyumu panoları.
Not: “Cihaz–policy drift” uyarıları; ihlal eden cihaz için ağ erişimi kısıtlama (NAC).

20) Enerji, Güvenlik ve Uzun Ömür

Güvenlik özellikleri (mTLS, imzalı OTA, SIEM agent) enerji/CPU tüketir. Donanımsal hızlandırıcılar ve etkinlik temelli telemetri ile pil/UPS ömrünü koruyun. Uzun yaşam döngüsü için anahtar döndürme planı, kök sertifika yenileme prosedürü ve EOL stratejisi şart.

21) Örnek Olay I — Akıllı Fabrika Basınç Sensör Ağı (MQTT + mTLS)

Durum: 1200 sensör, broker’a açık şifreli bağlanıyordu; sahte sensör eklendi.
Çözüm: Her sensöre donanım güven öğesi (SE) + cihaz sertifikası; broker’da topic tabanlı ACL; QoS1 + idempotency; rate limit.
Sonuç: Sahte sensör denemesi mTLS’de elendi; veri bütünlüğü sağlandı, CPU yükü %18→%9 (oturum yenileme).

22) Örnek Olay II — OPC UA ile Enerji Yönetimi

Sorun: Eski OPC DA köprüleri üzerinden açık metin; müdahaleye açık.
Çözüm: OPC UA end-point; rol tabanlı yetki; imza+şifreleme açık; gateway’de protocol break.
Sonuç: Yetkisiz yazmalar sıfırlandı; sistem gecikmesi < 30 ms.

23) Örnek Olay III — Güvenli OTA ve A/B Slotları

Sorun: OTA sırasında cihazlar brick oluyor, geri dönüş yok.
Çözüm: İmzalı OTA, A/B bölmeli, “health-check” başarısızsa rollback; dağıtım kademeli.
Sonuç: OTA başarısızlık oranı %7→%0.6; sahada downtime görülmedi.

24) Ödev Raporu Şablonu (Puan Kazandıran)

Tehdit modeli ve güvenlik hedefleri
Cihaz kimliği ve HRoT (secure boot, anahtar depolama)
Protokol seçimi ve güvenlik ayarları (MQTT/CoAP/OPC UA + mTLS/DTLS)
Ağ mimarisi (segmentasyon, DMZ, ZTNA)
PKI ve sertifika yaşam döngüsü (bootstrap, yenileme, iptal)
OTA ve konfig yönetimi (imza, A/B, rollback)
IAM ve rol/ilke matrisi (RBAC/ABAC)
Gözlemlenebilirlik (log şeması, SIEM panoları, metrikler)
Zafiyet ve SBOM (CVE takibi, yama süreci)
Emniyet–güvenlik etkileşimi (E-Stop, fail-safe)
Fiziksel güvenlik (portlar, anti-tamper)
Test/tatbikat (fuzz, pen-test, masaüstü tatbikat)
Mevzuat/standart eşlemesi (IEC 62443, ISO 27001)
Sonuç ve yol haritası

25) 10 Günlük Uygulanabilir Proje Planı

Gün 1: Tehdit modeli + güvenlik hedefleri
Gün 2: Cihaz kimliği/HRoT seçimi; PKI mimarisi taslağı
Gün 3: Protokol ve broker/sunucu seçimi; mTLS/DTLS demo
Gün 4: Ağ topolojisi (VLAN/DMZ/SDN) ve politika
Gün 5: OTA ve konfig imza zinciri; A/B bootloader prototipi
Gün 6: IAM (RBAC/ABAC) ve API kapısı; rate limit ve ACL
Gün 7: Log şeması + SIEM entegrasyonu; metrik panolar
Gün 8: SBOM üretimi, otomatik zafiyet taraması
Gün 9: Pen-test/fuzz ve masaüstü tatbikat; IRP taslağı
Gün 10: Mevzuat matrisi + final rapor + risk/kalan iş listesi

Sonuç

Endüstriyel IoT güvenliği; tek bir araç, tek bir kütüphane veya tek bir “kutucuk” değildir. Cihaz kimliğinden başlayan bir zincir, güvenli önyükleme ile donatılmış yazılımı, mTLS/DTLS ile güvence altına alınmış protokolleri, mikro-segmentasyon ve sıfır güven yaklaşımıyla çerçevelenmiş ağı, PKI ile güvenceye alınmış makine kimlikleri ve imzalı OTA/konfig süreçlerini, gözlemlenebilirlik ve olay müdahalesi mekanizmalarıyla tamamlar. Bu zincirde emniyet (safety) ile güvenlik (security) birbiriyle yarışmaz; fail-safe kuralları güvenlik kısıtlarına baskın gelerek insan ve tesis güvenliğini önceleyen bir denge kurar.

Bir ödev/bitirme projesinde başarı, bu kavramları ölçülebilir ve doğrulanabilir şekilde uygulamakla gelir: mTLS el sıkışma gecikmesi ve CPU yükü, sertifika yenileme başarısı, OTA rollback oranı, broker ACL ihlali, SIEM alarmları ve pen-test bulguları; hepsi metriklere dökülmeli ve jüride “hissiyat” değil kanıt konuşmalıdır. Bu metindeki çerçeve ve kontrol listeleri ile projeniz; güzel bir demo’dan öte, sahaya çıkmaya hazır bir güvenlik katmanına dönüşecektir. Unutmayın: IIoT güvenliği bir ürün değil, sürekli yaşayan bir süreçtir—anahtarlar döner, yazılımlar güncellenir, tehditler evrilir; sizin mimariniz de buna ölçeklenebilir, ölçülebilir ve geri döndürülebilir şekilde cevap vermelidir.

The post Elektrik Elektronik Mühendisliği Ödev Yaptırma: Endüstride IoT Uygulamaları için Güvenlik Katmanı first appeared on Ödev Yaptırma & Danışmanlık Merkezi.