Türkçe
English
"Verimizi buluta atalım" derken çoğu zaman tek soru sorulur: "Güvenli mi?" Cevap mimariye bağlı. Yanlış kurulmuş bir bulut bağlantısı tesisin kontrol katmanını dünyaya açar — Stuxnet'ten Triton'a saldırılar tam bu zayıf noktayı hedefler. Doğru kurulmuş bir mimari ise lokal SCADA'dan daha güvenli olabilir.
Bu yazıda saha verisini buluta taşırken standart siber güvenlik pratiğini ve IEC 62443 prensiplerini özetliyoruz.
1. OT-IT ayrımı (Purdue Modeli)
Endüstriyel ağ Purdue Modeli'ne göre 5 seviyeye ayrılır:
- Seviye 0-1: Saha cihazları, PLC — kesinlikle internete açık değil
- Seviye 2: SCADA, HMI — internete açık değil, sadece üst seviyeye veri verir
- Seviye 3: Site yönetim sistemi (MES) — DMZ üzerinden internete bakar
- Seviye 3.5 (DMZ): Bulut köprüsü, MQTT broker, jump server burada durur
- Seviye 4-5: Kurumsal ağ, internet
Bulut bağlantısı SADECE DMZ (Seviye 3.5) üzerinden kurulmalı. PLC ve SCADA doğrudan dış internete açılmaz.
2. MQTT broker — neden tercih ediliyor?
HTTPS REST yerine MQTT'nin endüstriyel kullanımda yaygın olmasının nedenleri:
- Düşük bant genişliği: minimal frame, binary payload
- Pub/sub: bulut tarafı sahaya istek göndermez (saldırı yüzeyi azalır)
- Last Will: bağlantı koparsa otomatik "offline" bildirimi
- QoS: kritik veri için garantili teslim
- Persistent session: kısa ağ kesintilerinde veri kaybı yok
Broker seçimi
| Broker | Özellik | Yorum |
|---|---|---|
| Mosquitto | Açık kaynak, hafif | Edge taraf için ideal, küçük ölçek |
| EMQX | Yüksek throughput, cluster | Çok-saha senaryolar için |
| HiveMQ | Ticari, enterprise destek | Regülatif sahalar (banka, ilaç) |
| AWS IoT Core / Azure IoT Hub | Bulut yerleşik | AWS/Azure'da varsa hazır seçim |
3. TLS 1.3 — şart, opsiyonel değil
MQTT trafiği TLS 1.3 üzerinden şifrelenmeli. Pratikte:
- Port: 8883 (mqtts), 1883 (düz mqtt) asla internet üzerinde kullanılmamalı
- Sertifika: X.509, her edge cihaz için ayrı client cert
- Mutual TLS (mTLS): hem sunucu hem client doğrulanır
- Cipher suite: AEAD (AES-GCM, ChaCha20-Poly1305) — eski RC4, MD5 yasak
Sertifika yönetimi
- Kendi Private CA'nızı kurun (cfssl, smallstep, HashiCorp Vault)
- Her saha için ayrı client cert
- Sertifika geçerlilik: 1 yıl, otomatik yenileme cron'u
- Sızma şüphesinde cert revoke + yeniden dağıt
4. VPN tüneli — ne zaman gerekir?
MQTT TLS yeterliyse VPN gereksizdir. Ama bazı senaryolarda VPN ek katman olur:
- Saha tarafına bakım için uzak masaüstü bağlantısı gerekiyor
- Sertifika yönetimi çok zor (küçük tesis, IT ekibi yok)
- Statik IP yok, NAT arkasında saha
- Multi-protocol trafiği var (Modbus + MQTT + SQL)
WireGuard veya OpenVPN tercih edilir. IPSec donanım tabanlı senaryolarda (Fortinet, Cisco ASA) yaygındır.
5. Network segmentation pratiği
- Firewall: DMZ ile OT ağı arasında stateful firewall
- Tek yön akış: Edge → Cloud TX izinli, Cloud → Edge RX kısıtlı
- Data diode: Çok kritik tesislerde (nükleer, savunma) tek-yönlü fiber kullanılır
- Logging: tüm bulut bağlantıları SIEM'e (Splunk, Wazuh) yazılır
6. Kimlik yönetimi ve yetkilendirme
- Bulut tarafında OAuth2 + RBAC: kullanıcı rolüne göre okuma/yazma yetkisi
- MFA (çift faktör) — operatör girişi için zorunlu
- API tokenları kısa süreli (1 saat), refresh token sistemi
- Audit log: kim, ne zaman, neyi okudu/yazdı — KVKK ve regülatif uyum için
7. IEC 62443 uyumluluğu
Endüstriyel siber güvenlik standardı IEC 62443 bulut entegrasyonunda da uygulanır. Anahtar prensipler:
- Defense in depth — birden fazla güvenlik katmanı
- Zone & conduit modeli — OT ağı bölgelere ayrılır, aralarındaki "conduit"ler firewall'lu
- Risk assessment — her bulut entegrasyonu için ayrı analiz
- Security level (SL-1 ile SL-4) — tesis kritikliğine göre hedef seviye
Bulut entegrasyon planınız varsa, mevcut ağ topolojisini paylaşın — mimari + güvenlik prensipleri raporu çıkartabiliriz.