OPC UA güvenlik temelleri: modlar, ilkeler ve sertifika güveni

Üç katman, üç soru

OPC UA güvenliğini, katmanlarını ayırdığınızda anlamak daha kolaydır. Her katman farklı bir soruyu yanıtlar:

• Güvenli kanal: bu iki uygulama arasındaki bağlantı doğrulanıyor ve gerekirse şifreleniyor mu? Bunu mesaj güvenlik modu ve güvenlik ilkesi belirler.
• Oturum kimlik doğrulaması: oturumun arkasındaki kullanıcı veya uygulama kim? Bu kullanıcı kimlik belirtecidir.
• Yetkilendirme: bu kimlik hangi düğümleri okuyabilir, yazabilir veya çağırabilir? Bu, sunucuda yapılandırılır.

Mesaj güvenlik modları

Birçok sunucu kolaylık için None etkin olarak gelir. Gerçek ekipman taşıyan her ağda bunu devre dışı bırakın.

Güvenlik ilkeleri

Güvenlik ilkesi, kriptografik algoritmaları belirler. SHA-1 tabanlı eski ilkeler, yani Basic128Rsa15 ve Basic256, güncel OPC UA belirtimlerinde kullanımdan kaldırılmıştır ve yeni çalışmalarda kullanılmamalıdır. Basic256Sha256 geniş destek görür ve yaygın bir taban olmayı sürdürür; Aes128_Sha256_RsaOaep ve Aes256_Sha256_RsaPss gibi yeni ilkeler ise iki uç da destekliyorsa tercih edilir. Sistemdeki her istemci ve sunucunun işleyebildiği en güçlü ilkeyi seçin ve seçimi yazın.

Uygulama örneği sertifikaları

Her OPC UA istemci ve sunucu uygulamasının bir X.509 uygulama örneği sertifikası vardır. Güvenli bir kanal açıldığında her taraf, diğerinin sertifikasını kendi güven listesine karşı denetler. Bu yüzden ilk bağlantıda tipik deneyim bir reddedilmedir: sunucu bilinmeyen istemci sertifikasını reddedilenler deposuna koyar; yönetici, sertifikanın beklenen istemciye ait olduğunu doğruladıktan sonra onu güvenilenler deposuna taşır. İstemci de sunucunun sertifikası için aynısını yapar.

Sertifika, temsil ettiği uygulamayla uyumlu olmalıdır:

• Sertifikadaki uygulama URI’si uygulamanın uygulama URI’sine eşit olmalıdır.
• Sertifikadaki ana makine adı veya IP adresi sunucuya erişim biçimiyle eşleşmelidir.
• Geçerlilik süresi mevcut zamanı kapsamalıdır; bu da doğru saatleri bir güvenlik gereksinimi yapar (bkz. zaman senkronizasyonu).

Bunlardan biri başarısız olduğunda istemciler BadCertificateUntrusted, BadCertificateUriInvalid, BadCertificateHostNameInvalid veya BadCertificateTimeInvalid gibi durum kodları bildirir. Adlar genellikle doğrudan nedeni işaret eder. Çok sayıda tekil kendinden imzalı sertifikaya güvenmek yerine, kontrol ettiğiniz bir sertifika otoritesinin verdiği sertifikaları tercih edin ve süresi dolmadan yenilemeyi planlayın; çünkü süresi dolan bir sertifika iletişimi ani biçimde durdurur.

Kullanıcı kimlik doğrulaması

OPC UA dört tür kullanıcı kimlik belirtecini destekler: anonim, kullanıcı adı ve parola, X.509 kullanıcı sertifikası ve verilmiş belirteç. Pratik öneriler:

• Yazma yapılabilen yerlerde anonim erişimi açık bırakmayın.
• Parolaları yalnızca güncel bir ilkeyle SignAndEncrypt kanalı üzerinden gönderin.
• Günlüklerde kimin ne yaptığının görülebilmesi için gereken en az yetkiyle adlandırılmış hesaplar kullanın.

Pratik bir kontrol listesi

1. Her sunucuda None güvenlik modunu ve kullanımdan kaldırılmış ilkeleri devre dışı bırakın.
2. Her uygulamaya doğru uygulama URI’si ve ana makine adıyla kendi sertifikasını verin.
3. Bir güven listesi süreci tutun: sertifikayı kim onaylar, nasıl kaydedilir, nasıl iptal edilir.
4. Sunucu portunu (opc.tcp için varsayılan 4840), güvenlik duvarı kurallarıyla ihtiyacı olan istemcilerle sınırlayın.
5. Her katılımcıda saatleri senkronize edin.
6. Düğümlerde en az yetki erişimi uygulayın ve roller değiştiğinde gözden geçirin.
7. Bağlantı denemelerini ve sertifika reddedilmelerini kaydedin ve izleyin.

OPC UA’nın diğer protokoller karşısındaki yeri için OPC UA ve MQTT ile eşlik eden belirtimler rehberini (İngilizce) okuyun. Daha geniş güvenlik çerçevesi için IEC 62443’e pratik giriş yazısına (İngilizce) bakın.