مشكلة المراكز الوسيطة
عندما تحتاج عدة مؤسسات إلى تبادل البيانات، يكون التصميم البديهي مركز تكامل وسيطًا. يتصل به الجميع، فيحوّل الرسائل ويوجّهها، ويصبح المكان الذي تمر عبره جميع البيانات. وهذا مريح في البداية. لكنه يصبح مع الوقت نقطة إخفاق واحدة، ونقطة اختراق واحدة، ومكانًا واحدًا يستطيع فيه شخص ما، من حيث المبدأ، قراءة كل شيء.
وهناك أيضًا مشكلة في الحوكمة. إذ ينتهي الأمر بمشغّل المركز إلى اتخاذ قرارات تعود إلى مالكي البيانات: من يحق له استدعاء أي خدمة، ومدة الاحتفاظ بالسجلات، والإصدارات المدعومة. فتنتقل المسؤولية إلى الوسط، حيث تكون المساءلة في أدنى مستوياتها.
فكرة X-Road
يتبع X-Road، وهو طبقة تبادل البيانات مفتوحة المصدر التي تقوم عليها الخدمات الرقمية الإستونية منذ سنوات عديدة، نهجًا مختلفًا. فالبيانات تنتقل مباشرةً من عضو إلى عضو. وتشغّل كل مؤسسة مشاركة خادم أمان خاصًا بها، ويمر كل طلب من خادم أمان المستهلك إلى خادم أمان المزوّد، موقّعًا ومشفّرًا ومختومًا زمنيًا على طول الطريق.
يوجد مكوّن مركزي، لكن دوره محدود. فهو يحتفظ بسجل الأعضاء وأنظمتهم الفرعية وإعدادات الثقة: أي جهات إصدار الشهادات وخدمات الختم الزمني معترف بها، ومن ينتمي إلى المنظومة. ولا يطّلع على محتوى الرسائل. وهذا الفصل بين حوكمة الثقة ونقل البيانات هو جوهر النموذج.
اللبنات الأساسية
بالنسبة إلى فريق تقني يخطط لتبادل قائم على هذا النموذج، تستحق المكوّنات الرئيسية أن تُسمّى بوضوح:
- خدمة حوكمة مركزية تحتفظ بسجل الأعضاء والإعدادات العامة.
- خادم أمان لدى كل عضو، يُنهي اتصالات TLS ذات المصادقة المتبادلة ويتولى التوقيع والتسجيل.
- أعضاء وأنظمة فرعية بمعرّفات واضحة، بحيث يُمنح الوصول لنظام محدد لا لمؤسسة بأكملها.
- خدمات الثقة: جهة إصدار شهادات، والتحقق من حالة الشهادات، والختم الزمني.
- سجلات رسائل لدى كل طرف، بحيث يحتفظ الطرفان بسجل موقّع لكل عملية تبادل.
السيادة على أرض الواقع
السيادة كلمة مُفرط في استخدامها، لكن لها هنا معنى ملموسًا. فكل مزوّد يقرر أي المستهلكين يحق لهم استدعاء كل خدمة من خدماته، ويُطبَّق هذا القرار على خادم الأمان الخاص بالمزوّد نفسه. ويحتفظ كل عضو بسجلاته. ولا يستطيع أي طرف ثالث أن يقرأ أو ينسخ أو يغيّر خلسةً ما يمر بين عضوين، لأنه لا يوجد طرف ثالث على المسار.
وهذا مهم في أوروبا والخليج على حد سواء، حيث تكون التوقعات عالية بشأن موطن البيانات والمساءلة. ويمكن لتبادل مبني بهذه الطريقة أن يعمل بالكامل داخل الحدود الوطنية أو المؤسسية، باستخدام برمجيات مفتوحة المصدر يستطيع المشغّل فحصها وتشغيلها وتغييرها دون طلب إذن من أي مورّد.
ما ينبغي إحكامه
البرمجيات هي الجزء السهل. أما النجاح فيعتمد على القرارات المحيطة بها. ينبغي حسم أعراف تسمية الأعضاء والأنظمة الفرعية قبل الاتصال الأول، لأن تغييرها يصبح صعبًا لاحقًا. وينبغي أن يكون انضمام الأعضاء عملية موثقة وقابلة للتكرار لا سلسلة من المجاملات. كما ينبغي أن تستخدم أوصاف الخدمات معايير مفتوحة مثل OpenAPI حتى يتمكن المستهلكون من البناء عليها دون اجتماعات.
لا تزال لإدارة واجهات API دورها. إذ يمكن لبوابة مثل WSO2 أن تعمل خلف خادم الأمان لدى العضو لتتولى إدارة الإصدارات وتحديد معدل الطلبات ووثائق المطورين لخدمات ذلك العضو. وتتكامل الطبقتان: فالتبادل يحكم الثقة بين المؤسسات، والبوابة تحكم دورة حياة كل واجهة API.
وأخيرًا، خطط للتشغيل منذ البداية. فتجديد الشهادات، وتوافر خدمة الختم الزمني، والاحتفاظ بالسجلات هي ما يسبب الأعطال في السنة الثانية. اكتب أدلة التشغيل والتصميم لا يزال حاضرًا في الأذهان، وسلّمها إلى الفريق الذي سيشغّل التبادل.
البدء على نطاق صغير
لا يحتاج التبادل إلى الانطلاق بجميع المؤسسات دفعة واحدة. فالتجربة الأولية مع عضوين أو ثلاثة وعدد قليل من الخدمات تثبت سلسلة الثقة وعملية الانضمام ونموذج التشغيل. ومن ثمّ يصبح التوسع في معظمه عملًا إداريًا، وهذا تحديدًا ما تريده من البنية التحتية.