Blogs

OPC Sistemlerinde Güvenlik Gerekliliği

OPC Klasik  uygulamalarının güvenli ve güvenilir çalışması için verilen yoğun çaba artarak devam ediyor ve işin doğrusu daha da  hızlı artmalı.

Farklı endüstrilerdeki farklı ekipman üreticilerinin kabulunu alarak bu kadar yaygın bir kabul elde eden başka bir endüstriyel haberleşme yapısı şimdiye kadar olmadı.

Proses Kontrol için OLE ( object linking and embedding)  olarak bilinirken günümüzde artık OPC Klasik olarak tanımlanmaktadır. Bu standard, endüstriden kurumsal işletmelere kadar değişen çeşitlilikteki sistemi birbirine bağlamaktadır. Insan-makine arabirimi iş istasyonlarından , acil durdurma güvenlik sistemlerine, DCS kontrol sistemlerinden kurumsal veritabanı sistemlerine ( ERP) kadar geniş bir yelpazede sistem için kullanılmaktadır.

OPC ’nin bu kadar  yaygın ve popüler olmasının sebebi ise çok basit;

Üreticisi, yazılımı ve haberleşme protokolü ne olursa olsun farklı endüstriyel cihaz ve uygulamayı gerçek anlamda birbirine bağlayan evrensel bir arabirim olması.

OPC ’den önce , geliştiriciler bağlantı yapılması gerekecek yüzlerce cihaz ve kontrol sisteminin herbiri için haberleşme sürücü yazılımı yazmak ve bunları güncel tutmak zorunda kalıyorlardı.

OPC ile, sadece tek bir OPC sürücüsü yazmaya ve bunu güncel tutmaya odaklanabildiler. Bu aynı zamanda son kullanıcının haberleşme gerçekleştireceği cihazın içi yapısını bilme zorunluluğunu da ortadan kaldırdı. Entegrasyon ekipleri , veri tipleri, ham register numaraları yerine adlandırılmış objeler ile çalışabilir hale geldiler. Bu ise eski geleneksel protokollerden ethernet tabanlı bir protokole geçiş imkanı sağlayarak kontrol sistemlerinin değiştirilmesi ve geliştirilmesi basitleşti.

OPC yapılandırmasını kolaylaştıran sebepler;

  • OPC  , korunması ve oluşturulması gereken bir arabirim eşleştirilmesine gerek duymaz.
  • OPC  , kendine özgü bir biçem ve sözdizimi sunar.
  • OPC  , konfigurasyonu kolaylaştırmak için evrensel bir tarayıcı sunar.
  • Adlandırılmış öğeler ( 40020 veya N7:2 gibi üreticiye bağlı adreslemeler yerine) tasarım sırasında insan hatası olasılığını azaltır.

Geleneksel  haberleşme teknolojileri ile karşılaştırıldığında , pek çok mühendis OPC kullanımının belirgin bir zaman kazandırdığını görmüştür.

Günümüzde küçük de olsa herhangi bir ünitesinde OPC kullanmayan endüstriyel tesis yok gibidir.

Bütün bu yoğun kullanım ve popülaritesine rağmen OPC’nin de yumuşak karnı var.

Kontrol Sistemi üreticileri, entegratörleri ve son kullanıcılar mutlu bir şekilde tesis ve fabrikalarında OPC uygulamaları yaparken , güvenlik araştırmacıları ve hacker’lar bu cennet bahçesindeki yılan hakkında uyarılara başladılar.

Popüler basındaki ilk ve en sık alıntı OPC Klasik’in temel protokolleri olan DCOM ve RPC1’in viruslere karşı savunmasız olabileceği idi. Bazı raporlar ise tehditlerin gerçek olduğunu göstermekte.

“Gectiğimiz bir kaç ay içinde gördüğümüz iki vektor saldırısı RPC ( remote procedure calls) servisi arabiriminin Windows DCOM ’una yapılmıştı.  Bu virüs ve solucanların favorisi gibi görüldüğünü ve bu trendin devam etmesini bekliyoruz.”

Daha ciddi bir sorun ise , RPC ve DCOM protokolleri  güvenlik konularının  yaygın olmasından önce tasarlanmasıdır.  Sonuç olarak geleneksel BT tarzı güvenlik duvarları ile OPC ‘yi güvenli hale getirmek hemen hemen imkansızdır.  Diğer ağ uygulamalarından farklı olarak , OPC sunucular objeleri istemcilere sunan çalıştırılabilir prosesleri dinamik olarak TCP bağlantı noktalarına atar.

OPC istemcileri, belirli bir obje ile ilişkilendirilmiş bağlantı noktasını , sunucuya bağlanarak ve kullanabileceği TCP bağlantı noktasını sorarak karar verir/bulur. OPC sunucuları 1024-65535 arasında herhangibir bağlantı noktası atayabilir ki bu da OPC ‘yi güvenlik duvarları için çok güvensiz hale getirir. Bu genişlikte bir bağlantı noktasını açık bırakacak bir BT güvenlik duvarı konfigurasyonu yapmak  ciddi bir güvenlik açığına sebep olabilir ve genel olarak kabul edilemez bir uygulama olarak görülür.

İlk OPC güvenlik çözümleri Microsoft Windows XP/SP2 ve Windows Server 2003/SP1 de kullanılan DCOM hizmet geliştirmeleri etrafında yapıldı ancak kısa sürede bunun yetersiz olduğu ortaya çıktı.

2006’da Kraft Foods tarafından kurulan bir araştırma grubu , bu geliştirmeleri küçük bir mühendislik grubunun dağıtabileceğini kanıtladı.

Bu araştırmalar yapılırken bazı 3rd party ürünler çoklu bağlantı noktası problemini , OPC/DCOM trafiğini pazarda görülmeye başlayan tek bir bağlantı noktası üzerinden geçirerek çözdü.

Bu BT yöneticilerinin hayatını kolaylaştırmasına rağmen gerçek anlamı ile güvenlik problemini çözemedi.  Çünkü bu tasarımlar tüneli yönetmek için araya yerleştirilecek bir PC’ye ihtiyaç duyar.

Bu ise uzun vadede maliyet artışına sebep oldu, çünkü PC’ler sürekli yama ve anti-virüs güncellemelerine ihtiyaç duyuyordu.

2008 yılına ait bir uygulama notunda , Byres Security Inc. OPC için alternatif bir güvenlik çözümü önerdi. Bu çözüm OPC güvenlik duvarını,  OPC Sunucu Windows Registry ayarlarını değitirmeyi baz alarak yönetmeyi öneriyordu. Bu çözüm genel olarak etkin bir yöntemdi  fakat sistem yöneticileri için ilave bir konfigurasyon karmaşası getirdi ve bazı OPC sunucu ürünlerinde işe yaramadı.

Tüneller ve kural odaklı çözümler kesinlikle bir yere sahip olsa da günümüzün kritik uygulamaları için yeterli olmadı.

OPC kullanıcıları daha basit ve daha güçlü güvenlik araçlarına ihtiyaç duyar.  2008 yılında Triconex Emniyet Sistemlerinde daha fazla yetkinlik sunmak için OPC sunucularını doğrudan TCM modulünün içine gömdü ve aracı PC’ye olan ihtiyacı kaldırdı.

Bu, ayrıca OPC sistemlerde normalde mümkün olmayan salt-okunur erişimi kontrolüne olanak sağladı. 2009’da bu gömülü OPC sunuculara maksimum güvenliği sağlamak için kullanımı basit ve kanıtlanmış güvenliği ile bir güvenlik duvarı oluşturdu.

Triconex TCM ve Trofino Güvenlik duvarının kombinasyonu olan OPC güvenlik sorunlarını,  farklı savunma katmanları sunarak otomatik olarak giderir ;

  • Bu sıkı güvenlik duvarı OPC DA ve A&E sunucu bağlantıları tarafından atanan TCP bağlantı noktalarını otomatik olarak izler ve güvenlik duvarını sadece ihtiyaç olduğunda ve sadece uygun sunucu ve istemci arasında açar.
  • Dahili OPC kontrolleri DCE/RPC standardına uymayan OPC oturum isteklerini bloklar.
  • TCM içindeki okuma /yazma erişim kontrol özellikleri cihazların emniyet sisteminde okuma ve yazma denetimleri yapar.

Ağ güvenliği konusunda eğitimi ve deneyimi olmayan son kullanıcı personeli tarafından kolayca uygulanabilir. Çoğu Triconex uygulamasında herhangi bir konfigurasyon değişikliğine gerek duymaksızın fabrika ayarlarında çalışabilir. Kullanıcı bu güvenlik duvarını basit bir şekilde haberleşme cihazı ile ethernet bağlantı noktası arasına yerleştirebilir.

Güvenlik duvarı bütün ağ duvarını izler ve sistemi etkileyebilecek trafiği bloklar;

  • Trafik aşırı yük şartlarından kurtarmak için artış oranı limitleme özelliğini kullanır.
  • Bütün OPC bağlantı istekleri RPC protokol özellikleri ile uyumlu olabilmesi için, “kontrol edildi” statüsünde olmalıdır, aksi durumda olanlar bloklanır.
  • Bütün beklenmedik durumlar analiz için kaydedilir.

Tabiki güvenlik duvarına ihtiyacı olan protokol sadece OPC Klasik değil, Modbus  ve diğer TCP protokollerinin de güvenlik kaygısı vardır, aynı yöntem kullanılarak çözülebilir.

Kaynak :

  • Invensys – white paper ; triconex high security integration using opc.
  • Application NoteAN105: Securing OPC Traffic with a Tofino Security Appliance”; Byres Security Inc, December 2008
  • Eric Byres, Matthew Franz, Dale Peterson, and Joel Carter; OPC Security Whitepaper #1 - Understanding OPC and How it is Deployed
  • Bruce Schneier, “Attack Trends” QUEUE Magazine, Association of Computing Machinery, June 2005.

Bir sonraki konu başlığı : Arıza Bulma ve Giderme Taktikleri

Yorum Yapın

İletişim Bilgilerimiz