كيف تعمل اتصالات HTTPS و API عبر صمام ثنائي أحادي الاتجاه للبيانات

تزداد الحاجة في بيئات تكنولوجيا العمليات (OT) الحديثة إلى إرسال البيانات إلى أقسام تكنولوجيا المعلومات في المؤسسات، والمنصات السحابية، وأنظمة مراقبة الأمن، وتطبيقات التحليلات. وقد تشمل هذه البيانات قراءات القياس عن بُعد، والسجلات، والتنبيهات، والقياسات التشغيلية، وبيانات التطبيقات التي يتم توصيلها عبر بروتوكولات HTTP أو HTTPS أو واجهات برمجة التطبيقات (APIs).

ولكن هناك تحدٍّ جوهري في مجال الشبكات: فقد صُممت بروتوكولات HTTP وHTTPS تقليديًّا للاتصال ثنائي الاتجاه، في حين أن «ديود البيانات» مصمم للسماح بتدفق البيانات في اتجاه واحد فقط.

إذن، كيف يمكن للمؤسسات استخدام بروتوكول HTTPS وعمليات التكامل القائمة على API بأمان دون إنشاء مسار عودة إلى شبكة OT المحمية؟

يكمن الجواب في فهم الفرق بين نقل البيانات على مستوى التطبيق والاتصال على مستوى الشبكة.

يستخدم كل من MetaDefender™ Optical Diode وMetaDefender™ Optical Diode Fend تدفق البيانات أحادي الاتجاه المدعوم بالأجهزة وآليات النقل المراعية للبروتوكولات، مما يسمح بنقل البيانات عبر الحدود الأمنية دون إنشاء اتصال شبكي ثنائي الاتجاه تقليدي.

HTTPS هو بروتوكول HTTP الذي يعمل عبر بروتوكول TLS. في اتصال HTTPS التقليدي، يرسل العميل طلبًا إلى الخادم، فيرد الخادم عليه.

على مستوى الشبكة، يتطلب ذلك اتصالاً ثنائي الاتجاه. فبروتوكول TCP نفسه يتطلب عملية مصافحة وحركة مرور تحكم مستمرة في كلا الاتجاهين. ولذلك، لا يمكن ببساطة توجيه جلسة HTTPS تقليدية عبر صمام ثنائي للبيانات أحادي الاتجاه ماديًّا، كما لو كان هذا الصمام جدار حماية أو جهاز توجيه تقليديًّا.

وهذا يخلق تمييزًا مهمًا:

لا يحول الصمام الثنائي للبيانات اتصال HTTPS «ثنائي الاتجاه» عاديًّا إلى اتصال «أحادي الاتجاه». بل إنه يتيح نقل البيانات عبر بروتوكول HTTPS من خلال كسر نموذج الاتصال التقليدي من طرف إلى طرف.

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

لنتأمل حالة استخدام بسيطة لنقل البيانات من تكنولوجيا التشغيل (OT) إلى تكنولوجيا المعلومات (IT).

يقوم أحد التطبيقات الصناعية بتسجيل قراءة درجة الحرارة ويحتاج إلى إرسالها إلى منصة تحليلات سحابية باستخدام بروتوكول HTTPS API: تطبيق OT → HTTPS/API → منصة سحابية

في الشبكة التقليدية، يقوم تطبيق OT بإنشاء اتصال شبكي بالوجهة المقصودة، وإرسال طلب HTTP، واستلام استجابة HTTP.

أما في حالة استخدام الصمام الثنائي للبيانات، فإن البنية تختلف.

يمكن النظر إلى التنفيذ النموذجي أحادي الاتجاه من الناحية النظرية على النحو التالي: تطبيق OT → موصل/وكيل من جانب المصدر → نقل بصري أحادي الاتجاه → موصل من جانب الوجهة → تطبيق تكنولوجيا المعلومات/السحابة

النقطة الأساسية هي أن الشبكتين لا تربطهما صلة ثنائية الاتجاه تقليدية.

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

يتيح هذا النهج للمؤسسات الحفاظ على الدلالات الخاصة بنقل بيانات التطبيق مع التخلص من مسار الشبكة العائد.

على سبيل المثال:

1. يقوم نظام OT بتوليد بيانات القياس عن بُعد.
2. تتلقى خدمة من جانب المصدر بيانات القياس عن بُعد.
3. يتم إعداد حمولة البيانات ذات الصلة للنقل في اتجاه واحد.
4. تتجاوز الحمولة حدود العزل البصري.
5. تتلقى الخدمة الموجودة في جانب الوجهة البيانات المنقولة.
6. يقوم الجانب المستهدف بتسليم البيانات إلى المؤسسة أو إلى تطبيق المراقبة أو التحليلات أو التطبيق السحابي.

تظل الشبكات منفصلة عن بعضها البعض على الرغم من إمكانية تبادل المعلومات المفيدة بينها.

وهذا يختلف اختلافًا جوهريًّا عن تكوين قاعدة في جدار الحماية تسمح بحركة مرور HTTPS بين شبكتين. يمكن لجدار الحماية أن يسمح بالاتصال ثنائي الاتجاه عبر بروتوكول TCP عندما تسمح السياسة بذلك. أما «ديود البيانات» فقد صُمم خصيصًا لمنع مسار العودة هذا على مستوى الأجهزة.

نعم، تدعم طرازات MetaDefender وOptical Diode وFend من السلسلة 50 بروتوكولي HTTP وHTTPS إلى جانب البروتوكولات الصناعية وبروتوكولات تكنولوجيا المعلومات.

ولتحقيق ذلك، يجب تزويد كل جانب من جانبي الصمام الثنائي بالشهادات والمفاتيح اللازمة لإنهاء وبدء اتصال TLS مستقل مع المصدر والوجهة على التوالي.

يتم عادةً تنفيذ واجهات برمجة التطبيقات (API) من نوع REST عبر بروتوكول HTTP أو HTTPS، ويزداد استخدامها بشكل متزايد لدمج بيانات التكنولوجيا التشغيلية (OT) مع:

• Cloud منصات التحليلات
• منصات SIEM ومنصات مراقبة الأمن
• لوحات معلومات المؤسسات
• مؤرخو البيانات
• تطبيقات الصيانة التنبؤية
• أنظمة التسجيل المركزية
• أنظمة إصدار التذاكر وسير العمل

عادةً ما يكون شكل التفاعل التقليدي عبر REST API كما يلي: العميل → HTTP/S POST أو PUT → خادم API → استجابة HTTP

في هذه الحالات، تُعد الاستجابة على مستوى طبقة التطبيق جزءًا من التبادل العادي بين التطبيقات. ويتوقع العميل الحصول على رمز حالة HTTP 200، وربما رسالة مخصصة في نص الاستجابة.

في بنية أحادية الاتجاه، يمكن لجانب الإدخال في الصمام الثنائي أن يعمل كوكيل لهذه الاستجابة، كما لو كانت قادمة من الوجهة النهائية. وإذا كان نص الاستجابة المخصص لعملية PUT/POST الناجحة معروفًا وقابلًا للتكرار، فيمكن أيضًا أن يعمل كوكيل له.

على سبيل المثال، قد يحتاج نظام مراقبة OT إلى إرسال:

POST /api/v1/telemetry

مع حمولة تتضمن:

{"temperature":72,"pressure":101.3,"status":"normal"}

لا يتمثل الهدف المعماري في إنشاء جلسة اتصال ثنائية الاتجاه دائمة عبر بروتوكول API بين شبكة OT وشبكة IT. بل يتم نقل البيانات إلى الخارج عبر الصمام الثنائي وتسليمها إلى التطبيق الموجود على جانب الوجهة.

يقوم جانب الإدخال في الصمام الثنائي، عند استلام طلب POST، بإرجاع حالة 200 OK إلى العميل قبل إعادة توجيه الحمولة عبر العازل البصري، ثم الاتصال بالخادم الوجهة لتسليم الرسالة باستخدام طلب POST آخر إلى /api/v1/telemetry،

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

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

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

يعمل «ديود البيانات» المُنفَّذ على مستوى الأجهزة على إزالة مسار العودة هذا. وبالتالي، يمكن لبيانات OT مغادرة الشبكة المحمية دون إنشاء مسار قابل للتوجيه يسمح للأنظمة الخارجية بإعادة إرسال حركة المرور إليها.

بالنسبة للبنية التحتية الحيوية، قد يكون هذا التمييز ذا أهمية كبيرة. تُستخدم الثنائيات البياناتية لنقل المعلومات التشغيلية إلى أنظمة المراقبة وأنظمة المؤسسة مع الحفاظ على الفصل المادي بين الشبكات.

هل ترغب في تعزيز أمن شبكة OT الخاصة بك؟

اكتشف كيف تتيح حلول « OPSWAT» — MetaDefender وOptical Diode وFend حلول — نقلًا آمنًا للبيانات في اتجاه واحد، مع فرض الأمان على مستوى الأجهزة، عبر حدود الشبكات الحيوية. تواصل مع خبرائنا لمناقشة بنية تكنولوجيا التشغيل (OT) الخاصة بك ومتطلبات نقل البيانات.

عند تصميم بنية تربط تقنية التشغيل (OT) بتقنية المعلومات (IT)، من المهم البدء بمتطلبات الاتصال الفعلية بدلاً من بروتوكول التطبيق.

اطرح ثلاثة أسئلة:

1. ما هي البيانات التي يجب أن تخرج من بيئة OT؟

حدد بيانات القياس عن بُعد، والسجلات، والتنبيهات، والملفات، وبيانات العمليات، أو أي معلومات أخرى يجب أن تصل إلى أنظمة تكنولوجيا المعلومات أو السحابة أو أنظمة المراقبة.

2. هل تحتاج الوجهة فعلاً إلى إرسال البيانات مرة أخرى؟

يُوصف العديد من عمليات التكامل بأنها تتطلب «الاتصال»، في حين أن المطلب التجاري الأساسي هو مجرد نشر المعلومات إلى الخارج. وإذا كانت البيانات المرتجعة مجرد إقرار بالاستلام أو نجاح العملية، فيمكن للبنية أحادية الاتجاه أن تتولى توزيع هذه الاستجابات وتستبعد مسارًا شبكيًّا غير ضروري.

3. أين ينبغي أن يكون حد البروتوكول؟

تفترض البروتوكولات مثل TCP وHTTPS وواجهات برمجة التطبيقات REST (REST APIs) سلوكيات ثنائية الاتجاه معينة. ولذلك، يتعين على بنية «ديود البيانات» أن تحدد أين تنتهي الجلسات، وكيف يتم نقل البيانات عبر الحدود، وكيف يستقبلها التطبيق على جانب الوجهة.

يساعد هذا النهج الذي يراعي احتياجات التطبيقات المؤسسات على تحديث اتصالات تكنولوجيا التشغيل (OT) دون اعتبار عزل الشبكة وتكامل التطبيقات متطلبين متعارضين.

1. هل يمكن لـ«ديود البيانات» نقل حركة مرور HTTPS؟
   نعم. MetaDefender Optical Diode و MetaDefender تدعم أجهزة Fend نقل البيانات القائم على بروتوكولي HTTP/HTTPS، لكن بروتوكول HTTPS لا يمكنه العمل كجلسة تقليدية ثنائية الاتجاه من طرف إلى طرف عبر حدود مادية أحادية الاتجاه. يقوم «ديود البيانات» بإنهاء الجلسة ثم بدء جلسة مشفرة منفصلة على كل جانب من جانبي «ديود البيانات»، ولذلك يجب تزويده بالمفاتيح والشهادات اللازمة للتعامل مع تلك الجلسات.
2. هل يمكن لواجهات برمجة التطبيقات (APIs) أن تعمل عبر «ديود البيانات»؟
   نعم. يمكن لنقل البيانات القائم على بروتوكول « API » أن يعمل عبر «ديود البيانات» عندما تكون البنية مصممة على أساس الاتصال أحادي الاتجاه عبر طلبات PUT/POST. ويكمن السر في تجنب الحاجة إلى جلسة ثنائية الاتجاه عبر بروتوكول « API » عبر «ديود البيانات»، واستخدام آليات من جانب المصدر والوجهة بدلاً من ذلك لنقل بيانات التطبيق المطلوبة.
3. هل يحل «ديود البيانات» محل تشفير HTTPS؟
   لا. فكل منهما يعالج مشكلات أمنية مختلفة. يوفر HTTPS التشفير والمصادقة لحركة مرور التطبيقات، بينما يوفر «ديود البيانات» تحكمًا مفروضًا عبر الأجهزة في اتجاه الاتصالات الشبكية.
4. ما الفرق بين جدار الحماية و«ديود البيانات»؟
   يتحكم جدار الحماية في حركة المرور باستخدام قواعد أمان محددة برمجيًا، ويمكنه السماح بالاتصال ثنائي الاتجاه. أما «ديود البيانات» فيفرض فعليًّا الاتصال أحادي الاتجاه، حيث يمنع تصميمه وجود مسار شبكة عائد.
5. لماذا يُستخدم الصمام الثنائي للبيانات في الاتصال بين شبكات التشغيل (OT) وشبكات تكنولوجيا المعلومات (IT)؟
   يتيح الصمام الثنائي للبيانات للمؤسسات مشاركة البيانات التشغيلية وبيانات القياس عن بُعد والسجلات والمعلومات الأخرى مع أنظمة المؤسسة أو الأنظمة السحابية، مع الحفاظ في الوقت نفسه على الفصل المادي عن تلك الشبكات. وهذا يقلل من مساحة التعرض للهجمات المرتبطة بالاتصال ثنائي الاتجاه.
6. ما هو MetaDefender Optical Diode ؟
   MetaDefender Optical Diode هو صمام ثنائي للبيانات بصري يتم تنفيذه عبر الأجهزة، مصمم لتوفير نقل آمن للبيانات في اتجاه واحد بين الشبكات. ويمكنه دعم بروتوكولات تكنولوجيا المعلومات مثل HTTP وHTTPS إلى جانب البروتوكولات الأخرى المدعومة وحالات الاستخدام المختلفة.
7. ما هو MetaDefender Optical Diode Fend؟
   MetaDefender Optical Diode Fend هو حل «ديود البيانات» المصمم لنقل البيانات بشكل آمن في اتجاه واحد عبر بيئات تكنولوجيا المعلومات (IT) والتكنولوجيا التشغيلية (OT). وبحسب الطراز وطريقة النشر، يدعم هذا الحل بروتوكولات تكنولوجيا المعلومات والبروتوكولات الصناعية، ويمكنه المساعدة في ربط شبكات التكنولوجيا التشغيلية المعزولة بالأنظمة التي تتطلب الوصول إلى البيانات التشغيلية.