نادراً ما يفشل بروتوكول OPC UA بسبب آليات التشفير الخاصة به، بل يفشل لأن شخصاً ما ترك قائمة الثقة مفتوحة، أو أبقى على تسجيل الدخول المجهول قيد التشغيل "فقط من أجل مرحلة التشغيل التجريبي"، أو قام بتوريد خادم مبني على مكتبة برمجية لم يقم أحد بتحديثها. إذا كنت تبحث عن أفضل ممارسات أمان OPC UA القابلة للتطبيق بفعالية داخل المنشآت الحقيقية، فابدأ من هنا: البروتوكول سليم وقوي، لكن عمليات النشر والتطبيق هي نقطة الضعف. 

هذا ليس رأينا وحدنا؛ فقد راجع المكتب الاتحادي لأمان تكنولوجيا المعلومات في ألمانيا (BSI) المواصفات القياسية في عام 2016 ومرة أخرى في عام 2022 (وشمل التحديث الإصدار 1.04 وتطبيق open62541) ولم يجد أي عيوب تصميمية منهجية. ومع ذلك، أحصى فريق TRACE التابع لشركة Bitsight ما يصل إلى 14,220 خادم OPC UA مكشوفاً على الإنترنت خلال فترة الاثني عشر شهراً حتى يونيو 2025، وكان 51.74% منها يقبل الاتصالات المجهولة. ومن بين الأجهزة التي أفصحت عن أوضاع الأمان الخاصة بها، كان ما يقارب 80% لا يزال يوفر وضع None غير المشفّر. البروتوكول هو نفسه، لكن النتائج تختلف كلياً. 

كُتبت هذه المدونة لمديري أمن المعلومات (CISOs)، وقادة أمن التكنولوجيا التشغيلية (OT Security Leads)، ومهندسي معماريات المنشآت الصناعية الذين لديهم معرفة مسبقة ببروتوكول OPC UA. وتغطي كيفية عمل الشهادات الرقمية وقوائم الثقة فعلياً في البيئات الميدانية، والسياسات الأمنية التي ينبغي تفعيلها وتلك التي يجب إيقافها، والأخطاء الأكثر شيوعاً في التهيئة، والتحذيرات الأمنية الصادرة في عام 2026 والتي تغيّر من أولويات الفحص والمراجعة لديك خلال هذا الربع من العام. 

النقاط الرئيسية 

• تعامل مع مصادقة التطبيقات (الشهادات الرقمية وقوائم الثقة) باعتبارها ضابط الأمان الأكثر أهمية؛ فالمستخدمون المجهولون يمكن التسامح معهم خلف هذا الضابط، لكنهم يشكلون خطراً داهماً في غيابه. 

• قم بتعطيل سياسة None والسياسات المهملة مثل Basic128Rsa15 وBasic256 ما لم تكن هناك أجهزة قديمة موثقة تجبرك على الاحتفاظ بها. 

• استخدم وضع SignAndEncrypt في جميع نقاط النهاية، وتأكد من تشفير رموز أسماء المستخدمين (Username Tokens) أيضاً باستخدام سياسة أمنية حديثة. 

• قم بإجراء حصر دقيق لمكتبات OPC UA البرمجية المستخدمة في أجهزتك ومنتجاتك. ويعد التحذير الأمني الخاص بـ Eclipse Milo الصادر في أكتوبر تذكيراً مهماً بأن إصدار حزمة البروتوكول (Stack) له نفس أهمية تهيئة الخادم. 

• لا تعرض نقطة نهاية OPC UA للإنترنت بشكل مباشر أبداً، واحرص على تدقيق الاتصالات بين الأجهزة التي يمكنها الوصول لبعضها داخل بيئة المنشأة. 

أمان OPC UA في عام 2026: ما الذي تغيّر ولماذا يهمك؟ 

توالت التحذيرات الأمنية الخاصة بـ OPC UA منذ الصيف الماضي، وتشير جميعها إلى اتجاه واحد: نقاط الضعف تكمن في الحزم البرمجية، ومراجع الثقة، وخوارزميات التشفير القديمة بدلاً من أن تكون في صلب البروتوكول نفسه. إليك التسلسل الزمني لأحدث التطورات أولاً. لا يمثل أي من البنود الواردة أدناه حادثاً أمنياً مؤكداً؛ فالتحذيرات تصف السيناريوهات المحتملة، ولم تسجل الشركات المصنعة أي استغلال معروف لمعظمها حتى الآن. 

ثلاثة أنماط تستحق اهتمامك 

1. فشل منطق التفويض حتى عند صحة التهيئة. تكمن العديد من عيوب Milo في التحكم بالوصول بدلاً من التشفير. وتتعلق إحدى الثغرات بنسخة من تهيئة الخادم تتجاهل بصمت مخطط الأدوار (Role Mapper) المحدد، مما قد يترك الدوال والعقد المحمية بأدوار معينة مكشوفة، خاصة إذا كان الخادم يسمح بالجلسات المجهولة. وتتيح ثغرة أخرى استدعاء دالة محمية عبر تمريرها مع استدعاءات مسموحة ضمن دفعة واحدة. وهناك ثغرة ثالثة تجعل عقد التشخيص قابلة للقراءة دون تفويض، مما يكشف تفاصيل أمان الجلسة بما في ذلك السياسات المستخدمة والشهادات العامة للعملاء. يمكنك تهيئة كل شيء بشكل صحيح ومع ذلك تظل عرضة للخطر؛ لذا فإن جرد المكتبات البرمجية يعد خطوة جوهرية ضمن برنامج أمان OPC UA لديك. 

2. التشفير القديم ما زال يشكل خطراً حقيقياً. أخطر مشكلة في Milo هي CVE-2026-60007 (بتقييم CVSS v4.0 9.1)، وهي ثغرة Padding Oracle أثناء معالجة رموز اسم المستخدم. يمكن للمهاجم الموجود في مسار الاتصال الذي يلتقط رمز اسم مستخدم مشفراً بـ Basic128Rsa15 إرسال طلبات ActivateSession متكررة غير مصادق عليها واستعادة كلمة المرور. الجلسات التي تتجنب تلك السياسة لا تتأثر بهذا الأسلوب تحديداً، لذا فإن إيقاف السياسات المهملة هو إجراء علاجي فعلي وليس مجرد تنظيم إداري. يُلاحظ اختلاف التقييمات باختلاف المصادر؛ حيث يذكر التحذير تقييماً إجمالياً CVSS v3 8.2، بينما تستخدم الثغرات المنفردة معايير v4.0. 

3. مراجع الثقة والعملاء يمثلون مساحة هجوم غير مرئية. ينطلق كل من تحذير Prosys وثغرة عميل open62541 من سياقين مختلفين، لكنهما يوصلان درساً واحداً: ما يثق به عميل OPC UA أو اتصال الوسيط (Broker) لديك لا يقل أهمية عما يقبله الخادم. أفادت شركة Prosys بأن اتصالات عملاء وخوادم OPC UA لم تتأثر لأنها تستخدم مخزن شهادات التطبيق بدلاً من قائمة CA الخاصة بـ Java؛ وهنا يظهر نموذج البنية التحتية للمفاتيح العامة (PKI) الخاص بـ OPC UA وهو يؤدي دوره بكفاءة، بينما كان الخلل يكمن في اتصالات MQTT وHTTPS وLDAP المحيطة. 

تحديثات المواصفات القياسية وحزم البروتوكول 

على صعيد المعايير، أضاف الإصدار 1.05.07 من مواصفات OPC UA تغييرات جوهرية على سياسات أمان تشفير المنحنيات الإهليلجية (ECC). وقد قام الإصدار الصيانتي 1.5.5 من open62541 بتطبيق هذه التغييرات، بما في ذلك مصادقة الجلسات القائمة على ECC، وأصبح خادمه يرفض الآن استخدام سياسات ECC للمصادقة عبر قناة غير آمنة (None). كما تعمل مؤسسة OPC Foundation ضمن الإصدار 1.05.07 على نقل سياسة nistP256 الخاصة بـ ECC من خوارزمية AES-128-CBC إلى AES-128-GCM. وسنستعرض تالياً ما يعنيه ذلك لخياراتك الأمنية. 

مستويات أمان OPC UA (وأين تقع الأخطاء) 

يتألف أمان OPC UA من ثلاثة ضوابط مستقلة غالباً ما يعاملها الناس كضابط واحد. وتصفها إرشادات مؤسسة OPC Foundation بأنها أمان المستخدم، وأمان التطبيق، وأمان النقل، ويمكن تهيئة أو إساءة تهيئة كل منها على حدة. 

تكمن النتيجة العملية في أن الخادم قد يروّج لاعتماده على "أمان قائم على الشهادات الرقمية" ولكنه يظل مفتوحاً للاختراق. وتعد مصادقة التطبيق هي المستوى الأول الذي يفحصه المهاجمون؛ فعند عدم فرضها، يمكن لعميل غير مصرح به فتح قناة آمنة وطلب قائمة نقاط النهاية واختيار الخيار الأضعف الذي يوفره الخادم. العميل يختار نقطة النهاية، والخادم يقرر قبولها أو رفضها. وإذا تركت تهيئتك نقطة نهاية بوضع None بجانب خيار آمن، فسيختار المهاجم ببساطة وضع None. 

هناك نقطة فاصلة يجب أخذها في الاعتبار: توضح مؤسسة OPC Foundation صراحةً أن بروتوكول OPC UA لا يحل محل نظام إدارة أمن المعلومات مثل ISO 27001؛ فالبروتوكول يوفر الآليات التقنية، بينما تظل السياسات والتدريب والأمن المادي وتصميم الشبكة من صميم مسؤوليتك. 

شهادات OPC UA: قوائم الثقة، وخادم GDS، وإدارة دورة الحياة 

تعد إدارة الشهادات الرقمية النقطة التي تتعثر عندها معظم برامج أمان OPC UA بهدوء. آليات التشفير تعمل بكفاءة، إلا أن العبء التشغيلي لتوزيع واعتماد وتجديد الشهادات عبر مئات الأجهزة هو ما يدفع الفرق الهندسية لإيقاف إجراءات التحقق. 

كيف تعمل آلية الثقة في الواقع 

يحمل كل تطبيق OPC UA شهادة خاصة بنسخته. وتحتفظ الخوادم والعملاء بقائمة ثقة تتضمن الشهادات (الموقعة ذاتياً أو الصادرة عن مراجع مصدقة) المسموح بالاتصال بها. وأي شهادة خارج هذه القائمة يجب أن تُنقل إلى مخزن الشهادات المرفوضة حتى يعتمدها مسؤول النظام يدوياً. هذا الإجراء اليدوي هو الضابط الأمني بحد ذاته، وهو السبب الرئيسي أيضاً في محاولة تجاوزه. 

ولقد لخصت أبحاث أكاديمية شملت 48 منتجاً صناعياً تدعم بروتوكول OPC UA مشكلات الشهادات في ثلاث فئات: غياب دعم قوائم الثقة تماماً (11 منتجاً، أي 22.9%)، وتعطيل قوائم الثقة افتراضياً، والتهيئة غير الآمنة لقوائم الثقة. وبحسب تحليلهم، فإن 14.6% من المنتجات روّجت لتصميم آمن ولكنها لم تكن تتحقق من ثقة الشهادات بالشكل الصحيح. الميزات متوفرة بالفعل، لكن الإعدادات الافتراضية والوثائق الفنية تدفع المستخدمين لتجاهلها في كثير من الأحيان. 

ثلاثة أسئلة كفيلة بكشف أغلب المخاطر في بيئتك التشغيلية: 

1. هل يرفض كل خادم شهادات العملاء غير المعروفة افتراضياً، أم يقبلها تلقائياً؟ 

2. من يملك صلاحية نقل الشهادة إلى المخزن الموثوق، وهل يتم تسجيل هذا الإجراء في سجلات التدقيق؟ 

3. عند انتهاء صلاحية الشهادة أو إخراج جهاز من الخدمة، ما الآلية المتبعة لحذفها من جميع قوائم الثقة المرتبطة بها؟ 

استخدام خادم الاكتشاف العام (GDS) أو مرجع مصدق للتقنيات التشغيلية على نطاق واسع 

إن إدارة الثقة لكل جهاز على حدة تنجح مع عشرة خوادم، لكنها تستحيل مع ألف جهاز. يتيح نموذج خادم الاكتشاف العام (GDS) في OPC UA لمدير شهادات مركزي توقيع شهادات التطبيقات وإرسال قوائم الثقة للخوادم، بحيث يكتفي كل خادم بالوثوق في GDS بدلاً من كل جهاز نظير. وعند إضافة شهادة CA جديدة إلى GDS، يُعمم التحديث على جميع الخوادم المدارة. 

إليك بعض النقاط التشغيلية المستخلصة من وثائق الموردين والممارسات الميدانية: 

• يجب أن يثق الخادم في وكيل GDS أولاً. والخطأ الشائع عند الإرسال التلقائي هو عدم الوثوق في GDS بعد، والحل يكمن في التجهيز الخاص بالشركة المصنعة أو نقل شهادة GDS للمخزن الموثوق. 

• يحتاج الحساب المستخدم للدفع التلقائي لصلاحيات إدارة الشهادات على الخادم (مثل الانتماء لدور SecurityAdmin). يجب التعامل مع هذا الحساب كحساب مسؤول نطاق (Domain Admin). 

• تعيد بعض الخوادم التشغيل بعد دفع الشهادات إليها. لذا احرص على جدولة عمليات التدوير خلال فترات الصيانة وتحقق من إعادة اتصال العملاء. 

• حافظ على خصوصية هذا المرجع المصدق (CA). يوضح تحذير Prosys المذكور سابقاً ما يحدث حين يرث عميل TLS الثقة بصمت من مخزن جذور عام. يضمن تخصيص مرجع مصدق للتقنيات التشغيلية، أو مرجع فرعي محدد النطاق بدقة، حصر الجهات القادرة على إثبات هوية التطبيقات. 

قائمة فحص سلامة الشهادات الرقمية 

هناك خطر برمجي آخر يستحق الذكر؛ فقد اكتشف فريق Team82 التابع لشركة Claroty أن بعض الخوادم التي تدير فحوصات سلاسل الشهادات داخلياً لم تكن محمية ضد سلاسل الشهادات الدائرية (الشهادة A موقعة من B، وB موقعة من A)، مما يتسبب في هجمات حجب الخدمة. وإذا كنت تبني أو تدمج مكونات OPC UA بنفسك، فتحقق من صحة التحقق من السلاسل بذات الدقة التي تختبر بها التشفير. 

سياسات وأوضاع أمان OPC UA: ما يجب تفعيله وما يجب إيقافه 

السياسة الأمنية هي حزمة مسمّاة من الخوارزميات (التوقيع، التشفير غير المتماثل، التشفير المتماثل، واشتقاق المفاتيح) محددة في الجزء 7 من المعيار. ويحدد الوضع (None أو Sign أو SignAndEncrypt) ما إذا كانت هذه الخوارزميات ستُطبق فعلياً أم لا. يجب أن يكون كلاهما صحيحاً؛ فوجود سياسة قوية على نقطة نهاية تعمل بوضع None لا يوفر أي حماية. 

ملاحظة حول تشفير المنحنيات الإهليلجية (ECC): تمنح سياسات المنحنيات الإهليلجية مستوى أمان مكافئاً أو أقوى بمفاتيح أقصر حجماً، وهو ما يناسب الأجهزة ذات الموارد المحدودة، وتدعم مكتبة open62541 بالفعل ستة منحنيات. غير أن المعايير الخاصة بها لا تزال قيد الاستقرار؛ فقد غيّر التحديث 1.05.07 آلية عمل قنوات ECC الآمنة ومصادقة الجلسات، ويجري العمل على نقل nistP256 من AES-CBC إلى AES-GCM، كما قامت إحدى حزم .NET SDK الكبرى بتصنيف معرفات سياسات Curve25519 وCurve448 الأصلية كمهملة لصالح متغيرات ChaCha20-Poly1305. بالإضافة إلى ذلك، يتطلب كل منحنى ECC شهادة وزوج مفاتيح خاصاً به، مع إمكانية تجاور سياسات RSA وECC على نفس الخادم. نصيحتنا: طبق ECC تجريبياً في البيئات التي تتحكم في طرفيها بالكامل، ولا تجعلها متطلباً إلزامياً عبر منشأة تضم موردين متعددين في الوقت الحالي. 

الأوضاع ورموز المستخدمين 

• اعتمد SignAndEncrypt كوضع افتراضي. تسمح إرشادات OPC Foundation باستخدام Sign فقط عندما يكون استهلاك التشفير للموارد مشكلة حقيقية، ولكن بالنسبة لحركة بيانات التحكم وأي بيانات تحمل بيانات اعتماد، لا يوجد مبرر لعدم التشفير. 

• ابحث عن إعداد الحد الأدنى للسياسة الأمنية (Minimum Security Policy). تتيح لك بعض المنتجات تحديد حد أدنى يرفض الخادم دونه السياسات الأضعف تماماً، ومن أمثلة ذلك FactoryTalk Optix من Rockwell. إذا كانت أجهزتك تتضمن هذا الإعداد فاستخدمه، لأنه يحول التوصيات إلى قاعدة مفروضة تقنياً. 

• قم بحماية رمز المستخدم بشكل منفصل. تنتقل بيانات اسم المستخدم وكلمة المرور ضمن رسائل تفعيل الجلسة، مشفرة وفقاً لسياسة رمز المستخدم. وإذا كانت تلك السياسة هي Basic128Rsa15 أو سياسة ضعيفة أخرى، فلن تحميك سياسة القناة القوية. يفضل استخدام رموز المستخدمين المستندة إلى X.509 للاتصالات بين الآلات (M2M)، وقصر كلمات المرور على المستخدمين البشريين مع تطبيق المصادقة متعددة العوامل (MFA) على مستوى طبقة الوصول. 

• لا تغفل بروتوكول PubSub. يستخدم OPC UA PubSub عبر MQTT أو UDP سياسات أمان رسائل خاصة به (تعتمد على AES-CTR)، مع استخدام TLS للاتصال بالوسيط في حالة MQTT. احرص على تطبيق نفس تدابير المرجع المصدق الخاص (Private-CA) هناك. 

عشرة أخطاء شائعة في تهيئة OPC UA وكيفية معالجتها 

تعود معظم النتائج السلبية في تدقيق OPC UA إلى قائمة قصيرة من الأخطاء المتكررة. استخدم هذا الجدول كقائمة تدقيق للمراجعة، حيث تتسبب الأخطاء الأربعة الأولى في الجزء الأكبر من الثغرات الميدانية الحقيقية. 

فحص سريع يمكنك إجراؤه في 15 دقيقة هذا الأسبوع 

وجّه عميل OPC UA مجانياً، مثل UaExpert، نحو خادم واحد في كل موقع واقرأ قائمة نقاط النهاية الخاصة به؛ يجب أن يُظهر كل سطر وضع SignAndEncrypt مع سياسة Basic256Sha256 أو أفضل. بعد ذلك، حاول الاتصال باستخدام شهادة تم إنشاؤها حديثاً وغير موجودة في قائمة الثقة؛ يجب أن يرفض الخادم الاتصال. إذا فشل أي من الاختبارين، فقد اكتشفت المشكلات من 1 إلى 4 في شبكتك قبل أن يستغلها المهاجمون. 

يتطابق هذا النمط مع ما ذكرته شركة Trout Software في أبحاثها حول هذا الموضوع: معظم الثغرات الميدانية ناتجة عن أخطاء في التهيئة وليست عيوباً في البروتوكول ذاته. وهذا أمر إيجابي، نظراً لإمكانية إصلاح التهيئة دون انتظار التحديثات البرمجية من أي جهة. 

مخاطر سلاسل التوريد والعملاء في OPC UA 

يتحدد تعرضك لمخاطر OPC UA جزئياً بشفرات برمجية لم تكتبها ولا يمكنك الاطلاع عليها. وقد رصد فريق Team82 التابع لـ Claroty نحو 50 ثغرة أمنية عبر ما يقارب 15 حزمة لبروتوكول OPC UA أثرت على مئات المنتجات، واستنتج أن الحزم البرمجية هي الحلقة الأضعف في سلاسل التوريد نظراً لإعادة استخدامها من قبل شركات عديدة بأدنى تعديل، مما يجعل ثغرة في مكتبة واحدة تظهر في أجهزة PLC، والبوابات، وأنظمة Historian في آن واحد. 

تساعدك ممارستان على إدارة هذه المخاطر بفعالية: 

معرفة المكونات الداخلية بدقة. يؤكد تحليل شركة Viakoo لتحذير Milo نقطة تستحق التكرار: يمكن دمج Milo في الخوادم وغيرها من المنتجات، وبالتالي فإن إصدار المكتبة وحده لا يوضح إن كان نظام معين مكشوفاً للخطر أم لا. اطلب من الموردين تحديد حزمة بروتوكول OPC UA وإصدارها في كل منتج، وسجل ذلك بجانب الأصل في قاعدة البيانات. وعند صدور أي تحذير، ستتمكن من الإجابة عن سؤال "هل نحن متأثرون؟" في غضون ساعات، بدلاً من استغراق شهر كامل. 

التعامل مع الخوادم كجهات غير موثوقة من منظور العميل. تركز نقاشات أمان OPC UA على حماية الخوادم، لكن تطبيقات العملاء تُستهدف وتُخترق أيضاً. وقد نجح فريق Team82 في الربط بين ثغرات في تطبيقين واسعي الانتشار للعملاء، هما Inductive Automation Ignition وSofting edgeAggregator، عبر تزويدهما بمحتوى خبيث من خادم OPC UA، مما مكنهم من تنفيذ التعليمات البرمجية عن بُعد. وتتبع ثغرة عميل open62541 لعام 2026 نفس المنطق: يزود الخادم المعادي تعريفات بيانات يتعامل معها العميل بشكل خاطئ. وبالتالي، فإن المهاجم الذي يستطيع تشغيل خادم خبيث وإقناع عميل واحد بالاتصال به يمتلك مدخلاً مباشراً إلى شبكتك. 

الضوابط العملية والتنفيذية: 

• زود تطبيقات العملاء بقائمة حصرية ومعتمدة للخوادم المسموح بالاتصال بها، بالاعتماد على قوائم الثقة بدلاً من القبول التلقائي. 

• اعزل مجمعات البيانات والبوابات وخوادم التكامل شبكياً؛ حيث تشكل جسوراً بين الأنظمة تجعلها نقاط ارتكاز مثالية للمهاجمين للتحرك جانبياً داخل الشبكة. 

• تعامل مع أي نصوص، أو أسماء عقد، أو هياكل ترسلها الخوادم كمدخلات غير موثوقة في تطبيقاتك ولوحات التحكم الخاصة بك. 

• أدرج هذه الأسئلة الخمسة ضمن استبيانات التقييم الأمني للموردين: 

1. ما هي حزمة بروتوكول OPC UA وإصدارها المستخدم في هذا المنتج؟ 

2. هل تنشرون قائمة مكونات البرمجيات (SBOM)، وما مدى سرعتكم في توفير التحديثات لثغرات الحزم البرمجية؟ 

3. هل يرفض الخادم شهادات العملاء غير المعروفة افتراضياً؟ 

4. هل يمكننا تحديد حد أدنى للسياسة الأمنية وتعطيل سياسة None تماماً؟ 

5. ما هي ضوابط التحكم بالوصول القائم على الأدوار التي يفرضها الخادم، وكيف يتم اختبار فاعليتها؟ 

قائمة التحصين الأمني لـ OPC UA في الشبكات الصناعية 

تعتبر الشهادات والسياسات الأمنية ضرورية ولكنها غير كافية وحدها. إليك الضوابط الأمنية المحيطة التي نتوقع وجودها في أي بيئة تشغيلية ناضجة تطبق OPC UA. 

الشبكة والمعمارية التقنية 

• قسّم خوادم OPC UA إلى مناطق أمنية محددة وضع مسارات توجيه بينها، تماشياً مع معيار IEC 62443. يجب أن تمر حركة مرور بيانات OPC UA بين المناطق عبر نقطة تحكم وتدقيق، وليس عبر شبكات مسطحة. 

• حدد عناوين العملاء المسموح بها عبر جدار الحماية. المنفذ الافتراضي 4840 معروف جيداً (96.81% من الخوادم المكشوفة التي رصدتها Bitsight كانت تستخدمه)، فلا تعتمد على التخفي كإجراء أمني. 

• عندما تدعم المنتجات ميزة الاتصال العكسي (Reverse Connect)، اجعل الخادم يتصل خارجياً باتجاه جانب العميل لتجنب فتح منافذ واردة نحو منطقة التحكم الحساسة. 

• وجّه حركة الوصول عن بُعد عبر شبكة VPN أو وسيط وصول آمن مع تفعيل MFA. إياك ونشر نقطة نهاية OPC UA مباشرة على الإنترنت. 

الهوية والتحكم بالوصول 

• خصّص لكل مستخدم بشري ولكل خدمة حساباً مستقلاً؛ فالحسابات المشتركة تجعل عمليات التدقيق والمحاسبة عديمة الفائدة. 

• استخدم رموز المستخدمين المبنية على شهادات X.509 للجلسات بين الآلات، واقصر كلمات المرور على العنصر البشري. 

• امنح صلاحيات القراءة على نطاق واسع، بينما تقيد صلاحيات الكتابة أو استدعاء الدوال بشكل صارم، ثم أعد اختبار فرض الأدوار بعد كل ترقية أو نسخ للتهيئة. وتعد ثغرة مخطط الأدوار في Milo مثالاً كلاسيكياً على التراجع الأمني الصامت الذي تكشفه اختبارات ما بعد التغيير. 

المراقبة والاكتشاف 

• فعّل ميزة تدقيق الخادم وقم بتمرير الأحداث إلى منصة مراقبة التكنولوجيا التشغيلية (OT) أو نظام SIEM. 

• أطلق تنبيهات فورية عند فتح جلسات عبر وضع None، أو ظهور شهادات عملاء جديدة في المخازن المرفوضة أو الموثوقة، أو عند رصد محاولات متتالية فاشلة لطلبات ActivateSession (وهي السمة المميزة لهجمات Oracle)، أو عند استخدام خدمات Write وCall من أجهزة لم يسبق لها استخدامها. 

• راقب طلبات اكتشاف نقاط النهاية الصادرة من مصادر غير متوقعة؛ حيث تبدأ عمليات الاستطلاع والمسح من هناك عادةً. 

إدارة التحديثات والمرونة التشغيلية 

• حافظ على تحديث سجل حصر مكونات OPC UA، وثبّت التحديثات عبر المسارات المعتمدة من الموردين، وتجنب استبدال أي مكتبة داخل أجهزة الموردين بنفسك. 

• أثناء انتظار التحديثات الرسمية، قم بتقييد مسارات OPC UA وحصرها بالعملاء الأساسيين عبر جدران الحماية الحالية والوصول المعتمد عن بُعد، وهو الإجراء المؤقت الموصى به في التغطيات الفنية لثغرات Milo. 

• اضبط حدود الاتصالات، والجلسات، وحجم الرسائل حيثما يدعم المنتج ذلك؛ حيث تمثل العديد من ثغرات OPC UA المنشورة، ومنها مشكلة B&R PPT30، أعطالاً ناتجة عن استنزاف الموارد يمكن أن يستغلها طرف غير مصرح له. 

• اختبر الخوادم الحساسة في بيئة معملية باستخدام أدوات فحص البروتوكولات (Fuzzers) قبل التشغيل الفعلي في بيئة الإنتاج، وكرر ذلك بعد الترقيات الكبرى. 

خطة أمنية لـ OPC UA مدتها 90 يوماً لمديري أمن المعلومات (CISOs) 

إذا كنت تتولى مسؤولية إدارة المخاطر ولكنك لا تدير أرضية المنشأة التشغيلية بشكل مباشر، فإن هذا التسلسل ينقلك من مرحلة "نعتقد أننا بأمان" إلى مرحلة امتلاك الأدلة القاطعة خلال ربع سنوي واحد. 

نصيحتان عمليتان: أولاً، توقع وجود أجهزة قديمة تعجز عن تلبية المعايير الأساسية؛ وثّق كل استثناء مع تحديد المسؤول وضابط الحماية التعويضي (مثل العزل، وقوائم السماح، والمراقبة) مع تاريخ للمراجعة. ثانياً، نسّق واشرح الخطة لمهندسي المنشأة قبل تنفيذ أي تغيير؛ فتشديد قوائم الثقة على خط إنتاج يعمل دون تنسيق مسبق هو أقصر طريق لخسارة تعاون الفريق الهندسي وتأييده للبرامج الأمنية. 

كيف تساعد Shieldworkz في تأمين OPC UA بالبنى التحتية الحيوية 

Shieldworkz هي شركة متخصصة وشاملة في الأمن السيبراني للتكنولوجيا التشغيلية الصناعية (OT). نعمل على حماية بيئات SCADA وOT وإنترنت الأشياء الصناعي (IoT) في البنى التحتية الحيوية، ونجمع بين المنتجات والخدمات والحلول المتكاملة ضمن منظومة واحدة، مما يضمن تحويل نتائج التقييم الأمني إلى حلول عملية ومعالجات فعلية دون تعقيدات تعدد الموردين. 

وفيما يتعلق ببروتوكول OPC UA تحديداً، يشمل عملنا عادة ما يلي: 

• الرؤية الشاملة: اكتشاف خوادم وعملاء وبوابات OPC UA عبر المنشآت الصناعية، ورسم خرائط للأنظمة التي يمكنها الاتصال بها والوصول إليها. 

• التقييم الأمني: مراجعة نقاط النهاية، والسياسات، والشهادات، ورموز المستخدمين، وسلوك قوائم الثقة ومطابقتها مع المعايير الأساسية الموضحة في هذا الدليل، مع ترتيب أولويات المعالجة والإصلاح. 

• دعم المعالجة والتحصين: المساعدة في تصميم إجراءات الشهادات وخوادم GDS، وعزل الشبكات، وتطبيق الضوابط الأمنية التعويضية للأجهزة القديمة غير القادرة على استيفاء المعايير الحديثة. 

• إدارة الثغرات والتحديثات: مطابقة التحذيرات الأمنية، مثل ثغرات Eclipse Milo وopen62541، مع سجل الأصول الفعلي لديك، وتخطيط عمليات التحديث بما يتوافق مع فترات الصيانة المجدولة في بيئات التكنولوجيا التشغيلية. 

إذا كنت ترغب في مراجعة أمنية متخصصة ومستقلة لأصول OPC UA في منشآتك، تواصل مع فريق Shieldworkz لإجراء تقييم أمني شامل لـ OPC UA. 

الأسئلة الشائعة حول أمان OPC UA 

ما هي أهم الممارسات المتبعة لتأمين OPC UA؟ 

فرض قوائم الثقة للشهادات، وتطبيق وضع SignAndEncrypt مع سياسة Basic256Sha256 أو أقوى، وتعطيل وضع None والسياسات القديمة المهملة، وإيقاف الوصول المجهول، وعزل الخوادم عن الإنترنت، وتفعيل ميزات التدقيق، وتحديث حزم OPC UA البرمجية المدمجة في كافة المنتجات. 

هل بروتوكول OPC UA آمن بطبيعته وافتراضياً؟ 

المواصفات القياسية آمنة وفقاً لمراجعات المكتب الاتحادي لأمان تكنولوجيا المعلومات (BSI). لكن المنتجات الفردية غالباً ما تفتقر للأمان الافتراضي، نظراً لأن قوائم الثقة والوصول المجهول والسياسات القديمة خاضعة لخيارات التهيئة، ويأتي بعضها بإعدادات سماحية غير مقيدة؛ لذا يجب التحقق من كل منتج على حدة وتجنب الافتراضات المسبقة. 

ما هي سياسة أمان OPC UA التي ينبغي عليّ استخدامها؟ 

يُوصى باستخدام Aes256_Sha256_RsaPss أو Aes128_Sha256_RsaOaep عندما تدعمها كافة المكونات، مع اعتماد Basic256Sha256 كحد أدنى لا يمكن النزول عنه. يجب إيقاف السياسات القديمة Basic128Rsa15 وBasic256، والبدء في اختبار سياسات ECC تجريبياً في البيئات الخاضعة للرقابة ريثما يستوعب الموردون تغييرات المواصفة 1.05.07. 

هل يمكن قبول الوصول المجهول (Anonymous) في أي حال من الأحوال؟ 

يُقبل فقط عند فرض مصادقة التطبيق عبر الثقة بالشهادات، وقصر الوصول على بيانات القراءة غير الحساسة، وتفعيل سجلات التدقيق. أما تفعيل الوصول المجهول على خادم مكشوف دون فرض التحقق من الثقة، فهو بمثابة فتح أبواب المنشأة بالكامل للمهاجمين. 

هل أحتاج إلى خادم اكتشاف عام (GDS)؟ 

نعم، إذا كنت تدير أكثر من بضعة تطبيقات OPC UA، أو ما يعادلها من آليات إدارة الشهادات الموثوقة؛ حيث يتيح ذلك لكل خادم الوثوق بمدير شهادات مركزي واحد بدلاً من الوثوق بكل الأجهزة النظيرة، مما يجعل إدارة دورة حياة الشهادات وتدويرها عملية قابلة للتكرار بسلاسة. 

هل تستدعي ثغرات Eclipse Milo المكتشفة في أكتوبر 2026 التخلي عن OPC UA؟ 

كلا؛ المطلوب هو تحديد المنتجات التي تدمج مكتبة Milo، وطلب مسارات الترقية الرسمية من الموردين، وتقييد الوصول الشبكي في هذه الأثناء، وإيقاف سياسة Basic128Rsa15 لقطع أخطر مسارات الهجوم المتاحة. 

هل يمكن كشف خوادم OPC UA على الإنترنت بصورة آمنة؟ 

لا تنصح كبرى الشركات المصنعة لأنظمة التكنولوجيا التشغيلية بالكشف المباشر على الإنترنت إطلاقاً. وإذا دعت الحاجة للوصول عن بُعد، فاستخدم شبكة VPN أو خدمة وصول عن بُعد مدارة عبر وسيط مع تفعيل MFA، مع إبقاء نقطة النهاية نفسها داخل منطقة شبكية محمية ومحصنة.