OPC UA Güvenlik Ayarları: Sertifika, Security Policy ve Kullanıcı

Sahada açtığımız OPC UA sunucularının önemli bir kısmında aynı tablo çıkıyor: endpoint None modunda, oturum anonim, sunucuda “tüm sertifikalara güven” işaretli. Devreye almada “şimdilik çalışsın” denmiş, sonra kimse geri dönmemiş. Sebep çoğu zaman güvenliğin zorluğu değil; sertifika ve trust list mantığının ekipte netleşmemiş olması. Aşağıda üç güvenlik katmanını, security mode ve policy seçimini, kullanıcı doğrulamayı, sertifika yenilemeyi ve konsolda en sık karşılaşılan hata kodlarını sırayla ele alıyoruz.

Güvenlik mimarisinin üç katmanı

OPC UA’da güvenlik birbirinden bağımsız üç katmanda kurulur ve her biri farklı bir soruya cevap verir:

Katman	Soru	Mekanizma
Uygulama doğrulama	Bu yazılıma güveniyor muyum?	Uygulama örnek sertifikası, trust list
İletişim kanalı	Mesajlar değiştirilmeden ve gizli mi iletiliyor?	Security mode ve security policy (SecureChannel)
Kullanıcı doğrulama	Bu oturumu kim açıyor, neye yetkili?	Anonim, kullanıcı/parola, kullanıcı sertifikası, token

Katmanlar birbirinin yerini tutmaz. Kanal şifreli olsa bile anonim oturum açılabiliyorsa, sertifikası güvenilen herhangi bir uygulama yazılabilir tüm değişkenlere erişir. Tersi de aynı derecede kötü: kullanıcı/parola zorunlu ama kanal None ise parola ağda açık metin taşınabilir. Üç katman birlikte tasarlanır. Biri eksikse zincir kopar.

Protokol içindeki güvenlik, endüstriyel ağ altyapısındaki kontrollerin yerine geçmez. OPC UA trafiği hangi zonlar arasında akıyorsa o kanal firewall’da da tanımlı olmalı; zon ve kanal kavramı için IEC 62443’te zon ve kanal yaklaşımı yazısı iyi bir çerçeve verir.

Uygulama sertifikaları ve trust list

Sunucu da istemci de her OPC UA uygulaması kendine ait bir X.509 v3 uygulama örnek sertifikasına (Application Instance Certificate) sahiptir. Bağlantı kurulurken iki taraf sertifikalarını değiş tokuş eder, her biri karşı tarafınkini kendi trust list’inde arar. Sertifikada doğru olması gereken alanlar:

• Subject Alternative Name içinde URI: Uygulamanın ApplicationUri değeriyle birebir aynı olmalı. Sahada gördüğümüz bağlantı hatalarının başında bu uyuşmazlık geliyor; büyük/küçük harf farkı bile yeter.
• SAN içinde DNS adı ve/veya IP adresi: Sunucu sertifikasında, istemcinin bağlandığı endpoint URL’sindeki ana bilgisayar adı bulunmalı.
• Anahtar kullanımı: Dijital imza, anahtar şifreleme ve veri şifreleme; genişletilmiş anahtar kullanımında serverAuth ve clientAuth.
• Geçerlilik süresi: Başlangıç ve bitiş tarihleri. Cihaz saati yanlışsa geçerli sertifika da reddedilir.

Çoğu OPC UA yığını sertifikaları dosya tabanlı bir PKI dizininde tutar: kendi sertifikası (own), güvenilenler (trusted), CA sertifikaları ve iptal listeleri (issuers), reddedilenler (rejected). İlk bağlantıda reddedilen karşı taraf sertifikası rejected klasörüne düşer. Yönetici parmak izini doğrular, sertifikayı trusted’a taşır. Bağlantı “hiç denememiş gibi” davranıyorsa konsolda ilk bakılacak yer bu klasördür. Tek tek onay modeli küçük kurulumlarda yeterlidir.

Uygulama sayısı arttıkça kurum içi CA işinizi kolaylaştırır: trust list’e yalnız CA sertifikası ve CRL girer, CA’nın imzaladığı tüm uygulama sertifikaları otomatik güvenilir olur. Bedeli CRL disiplinidir. CRL’si bulunamayan bir CA zinciri birçok yığında BadCertificateRevocationUnknown hatasıyla sonuçlanır. Daha büyük kurulumlarda OPC UA Part 12’deki Global Discovery Server (GDS) sertifika dağıtımını ve trust list güncellemesini merkezileştirir.

İstemci yazılımınız sertifika üretmiyorsa, doğru alanlara sahip bir sertifikayı OpenSSL 1.1.1 veya üstüyle aşağıdaki gibi oluşturabilirsiniz; CA’nız varsa aynı alanlarla CSR üretip imzalatmak daha doğrudur. Kendinden imzalı uygulama sertifikalarında birçok yığın keyCertSign bitini de bekler. Zorunlu uzantılar yığına göre küçük farklar gösterdiği için kullandığınız SDK’nın veya ürünün dokümantasyonunu kontrol edin.

openssl req -x509 -newkey rsa:2048 -nodes -days 730 \
  -keyout historian-client.key -out historian-client.pem \
  -subj "/CN=HistorianClient/O=Fabrika" \
  -addext "subjectAltName=URI:urn:historian01:Fabrika:HistorianClient,DNS:historian01" \
  -addext "keyUsage=critical,digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment,keyCertSign" \
  -addext "extendedKeyUsage=serverAuth,clientAuth"

# Birçok yığın DER biçimini bekler
openssl x509 -in historian-client.pem -outform der -out historian-client.der

# Alanları doğrulama
openssl x509 -in historian-client.der -inform der -noout -text

Security mode ve security policy seçimi

Her endpoint bir security mode ve bir security policy çiftiyle yayınlanır. Mode mesajlara ne yapılacağını belirler: None (koruma yok), Sign (bütünlük ve kaynak doğrulama) veya SignAndEncrypt (bütünlüğe ek olarak gizlilik). Policy hangi algoritmaların kullanılacağını tanımlar.

Security policy	Durum	Öneri
None	Koruma yok	Yalnız izole test ortamı
Basic128Rsa15	Kullanımdan kaldırıldı (SHA-1)	Kapatın
Basic256	Kullanımdan kaldırıldı (SHA-1)	Kapatın; yalnız eski cihaz zorunluysa geçici
Basic256Sha256	Yaygın destekleniyor	Asgari kabul edilebilir seviye
Aes128_Sha256_RsaOaep	Güncel	Destekleniyorsa tercih edin
Aes256_Sha256_RsaPss	Güncel	Destekleniyorsa tercih edin

Spesifikasyonun yeni sürümleri eliptik eğri tabanlı policy’ler de tanımlar; saha cihazlarındaki desteği ise henüz sınırlı. Pratik kuralımız şu: sunucuda SignAndEncrypt ile en az Basic256Sha256 ve desteklenen güncel policy’leri açın; None endpoint’ini ve SHA-1 tabanlı policy’leri kapatın. Hiçbir istemcinin kullanmadığı endpoint’i yayında bırakmak, saldırgana zayıf bir kapı açık bırakmaktır. Kullanılmayan endpoint kapatılır.

Sign modu, verinin gizli olmadığı ama değiştirilmemesinin önemli olduğu ve şifreleme yükünün düşük güçlü cihazı zorladığı durumlarda düşünülebilir. Kullanıcı/parola doğrulaması varsa SignAndEncrypt tercih edin.

Kullanıcı doğrulama yöntemleri

Uygulama doğrulanıp kanal kurulduktan sonra oturum (session) açılır. Endpoint’in UserTokenPolicy listesi hangi kimlik tiplerinin kabul edildiğini söyler:

• Anonymous: Kimlik yok. Yalnız okuma yetkili, sınırlı bir görünüm için kabul edilebilir; yazma veya metot çağrısı yetkisiyle asla birlikte kullanılmamalı.
• UserName: Kullanıcı adı ve parola. Parola token policy’nin güvenlik politikasıyla şifrelenir; endpoint ve token policy None ise açık metin gider. Bazı sunucular dizin hizmetiyle (LDAP/AD) entegre çalışır.
• Certificate (X509): Kullanıcıya veya servis hesabına ait ayrı sertifika. Parola yönetimi gerektirmediği için makineler arası servis hesaplarında uygundur.
• IssuedToken: Harici bir yetkilendirme sunucusundan alınan token. Destek ürüne göre değişir.

Yetkiyle eşleşmeyen kimlik bir işe yaramaz. Sunucu rol tabanlı erişimi destekliyorsa en az üç rol ayırın: yalnız okuyan veri toplayıcılar (historian, dashboard), belirli değişkenlere yazan sistemler (MES’in iş emri ve reçete alanları) ve yapılandırma yetkili mühendislik hesabı. Her tüketici sisteme ayrı hesap açın. Tek ortak hesapla çalışan bir tesiste, bir reçete değeri yanlış yazıldığında kimin yazdığını günlükten bulamazsınız.

Sertifika yaşam döngüsü ve yenileme

Süresi dolan sertifika alarm üretmez; veri akışı sessizce durur ve fark edildiğinde historian’da saatlerce boşluk vardır. Yenilemeyi devreye almadan planlayın:

1. Envanter çıkarın: Her OPC UA uygulaması için sertifika parmak izi, son geçerlilik tarihi ve hangi trust list’lerde bulunduğu kayıtlı olsun.
2. İzleme kurun: Son geçerlilik tarihi yaklaşan sertifikalar için önceden uyarı üretin. Sunucu sertifikası çoğu zaman OPC UA üzerinden, uygulama sertifika dosyaları dosya sistemi üzerinden okunabilir.
3. Örtüşen geçiş yapın: Yeni sertifikayı önce karşı tarafların trust list’ine ekleyin, sonra uygulamada yeni sertifikaya geçin, en son eskisini listeden çıkarın.
4. Saat senkronizasyonunu doğrulayın: PLC, gateway ve sunucular NTP ile senkron olsun; “henüz geçerli değil” ve “süresi dolmuş” yanlış alarmları çoğunlukla saat kaymasından gelir.
5. İptal sürecini tanımlayın: Hizmetten çıkan veya ele geçirildiğinden şüphelenilen uygulamanın sertifikası trust list’ten kalksın; CA modelinde CRL’ye eklensin.

CA kullanılan kurulumlarda sertifika ömrü kısa tutulup yenileme otomatikleştirilebilir. Manuel trust list modelinde ise denge farklı: ömür uzadıkça risk, kısaldıkça operasyon yükü artar. Bu dengeyi tesisteki uygulama sayısına göre kurun.

Bağlantı hatalarında kontrol sırası

Hata kodu	Olası neden	Kontrol
BadCertificateUntrusted	Karşı tarafın sertifikası trust list’te yok	rejected klasörünü inceleyin, doğrulayıp trusted’a taşıyın
BadSecurityChecksFailed	Genel güvenlik hatası; çoğu zaman güven veya imza sorunu	Her iki taraftaki güven durumunu ve sunucu günlüğündeki ayrıntılı nedeni kontrol edin
BadCertificateUriInvalid	SAN URI ile ApplicationUri farklı	openssl x509 -text çıktısını uygulama yapılandırmasıyla karşılaştırın
BadCertificateHostNameInvalid	Endpoint URL’deki ad sertifikada yok	Bağlantıyı sertifikadaki DNS adı/IP ile kurun veya sertifikayı yenileyin
BadCertificateTimeInvalid	Sertifika süresi dolmuş veya cihaz saati yanlış	Tarihleri ve NTP durumunu kontrol edin
BadCertificateRevocationUnknown	CA için CRL bulunamadı	issuers altına güncel CRL ekleyin
BadSecurityPolicyRejected	İstemcinin seçtiği policy sunucuda kapalı	Endpoint listesini (GetEndpoints) inceleyin
BadIdentityTokenRejected / BadUserAccessDenied	Kimlik tipi kabul edilmiyor veya kullanıcı yetkisiz	UserTokenPolicy ve rol eşlemelerini kontrol edin

Hata kodları yığına göre farklı ayrıntıda raporlanır. İstemcinin gördüğü genel kod çoğu zaman yetmez; sunucu günlüğü asıl nedeni söyler. Bağlantı “bazen” kuruluyorsa aynı uygulamanın birden fazla kopyasının farklı sertifikalarla çalışıp çalışmadığına bakın; yedek bir sunucuya kopyalanan istemci kurulumunun kendi sertifikasını üretmesi tipik bir sebeptir. Güncel hata kodu tanımları OPC Foundation Online Reference üzerindeki spesifikasyon bölümlerindedir.

Güvenli yapılandırma kontrol listesi

• None endpoint’i ve SHA-1 tabanlı policy’ler kapalı; en az Basic256Sha256 ile SignAndEncrypt açık.
• Otomatik sertifika kabulü kapalı; trust list içeriği belgelenmiş.
• Uygulama sertifikalarında SAN URI, ApplicationUri ile aynı; sunucu sertifikasında doğru DNS adı/IP var.
• Anonim erişim kapalı veya yalnız okuma yetkili bir görünümle sınırlı.
• Her tüketici sistem için ayrı hesap ve rol; yazma yetkisi yalnız gereken düğümlerde.
• Tüm cihazlar NTP ile senkron; sertifika son geçerlilik tarihleri izleniyor.
• OPC UA portu (varsayılan TCP 4840 veya ürünün kullandığı port) firewall’da yalnız tanımlı istemcilere açık.
• Sunucu güvenlik olaylarını (reddedilen bağlantı, başarısız oturum) merkezi günlük sistemine gönderiyor.

Modbus ve S7 gibi güvenlik mekanizması olmayan protokollerde ağ katmanında neler yapılabileceğini endüstriyel firewall DPI kuralları yazısında anlattık. OPC UA altyapınızın güvenlik değerlendirmesi ve zon tasarımı için OT siber güvenlik ve segmentasyon, entegrasyon tarafı için OPC UA, MQTT ve veri entegrasyonu sayfalarına bakabilirsiniz.

Sık sorulan sorular

Şifreleme açıkken ayrıca firewall kuralı gerekir mi?

Evet. OPC UA güvenliği bağlantının bütünlüğünü, gizliliğini ve tarafların kimliğini korur; hangi sistemlerin sunucuya ulaşabileceğini sınırlamaz. Firewall kuralı saldırı yüzeyini daraltır ve protokol düzeyindeki bir zafiyete karşı ikinci katman olur.

Self-signed sertifika mı, kurum içi CA mı kullanmalıyız?

Birkaç istemci ve sunucu varsa self-signed sertifikalarla tek tek güven modeli yönetilebilir. Uygulama sayısı arttıkça kurum içi CA trust list yönetimini sadeleştirir; bu durumda CRL’yi güncel tutmak ve dağıtmak zorunlu hale gelir.

Eski bir cihaz yalnız Basic256 destekliyorsa ne yapmalı?

Önce üreticide güncel policy desteği getiren bir yazılım güncellemesi olup olmadığına bakın. Yoksa cihazı izole bir zonda tutun, eski policy’yi yalnız o cihaza özel bir endpoint veya ara sunucu üzerinden kullanın ve bu istisnayı risk kaydına yazın.

Sertifika yenilendikten sonra bağlantı neden koptu?

Yeni sertifika karşı tarafın trust list’ine eklenmeden devreye alınırsa bağlantı reddedilir. Doğru sıra: yeni sertifikayı önce tüm karşı tarafların listesine ekleyin, sonra uygulamada yeni sertifikaya geçin, en son eskisini listeden kaldırın.