الاستفادة من API Gateway لسيادة البيانات والامتثال للبيانات

الخلفية والتحديات

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

أصبحت الهيئات التشريعية في المزيد من الدول تدرك خطورة وإلحاحية هذه المشكلة. وقد قامت بإصدار العديد من القوانين واللوائح لتنظيم جمع البيانات ونقلها عبر الحدود. يعتبر اللائحة العامة لحماية البيانات (GDPR) في أوروبا وقانون قابلية نقل التأمين الصحي والمساءلة (HIPAA) في الولايات المتحدة من الرواد في هذا المجال. كما أن العديد من الدول النامية تسرع الخطى:

• ماليزيا: قانون حماية البيانات الشخصية 2010 (PDPA)، ساري المفعول منذ نوفمبر 2013.
• الصين: تم إصدار قانون الأمن السيبراني لجمهورية الصين الشعبية، قانون أمن البيانات لجمهورية الصين الشعبية، وقانون حماية المعلومات الشخصية لجمهورية الصين الشعبية تباعًا من 2017 إلى 2021.
• البرازيل: القانون العام لحماية البيانات البرازيلي (BGDP)، ساري المفعول منذ سبتمبر 2020.
• تايلاند: قانون حماية البيانات الشخصية التايلاندي (PDPA)، ساري المفعول منذ يونيو 2022.

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

- ما هي البيانات التي يمكن جمعها؟ وما هي التي لا يمكن جمعها؟

- كيف وأين يتم تخزين البيانات؟

- هل يمكن نقل البيانات عبر الحدود؟

سيكون مشروعًا ضخمًا لفرز ووضع حلول لجميع هذه المشكلات. هنا سنركز بشكل رئيسي على قضية واحدة:

بالنسبة لبيانات العملاء التي يتم نقلها عبر واجهة برمجة التطبيقات (API)، كيف يمكن تحديد سيادة البيانات على مستوى بوابة API لضمان معالجة البيانات وتخزينها بشكل قانوني؟

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

في النصف الثاني من هذه المقالة، سنقدم حلاً تقنيًا محددًا لهذا المثال. قبل ذلك، دعونا نلقي نظرة أولاً على سيادة البيانات والامتثال.

ما هي سيادة البيانات والامتثال للبيانات؟

سيادة البيانات

لا تتمتع الدولة بالسيادة على الفضاء المادي فقط، مثل الأراضي والمجال الجوي والمياه الإقليمية، بل تتمتع أيضًا بالسيادة على بياناتها والفضاء السيبراني الوطني.

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

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

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

لقد جلبت سيادة البيانات بالفعل تحديات كبيرة للأعمال العالمية للشركات، وأصبح التعامل الصحيح مع قضية سيادة البيانات في الشركات أمرًا بالغ الأهمية.

الامتثال للبيانات

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

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

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

إذن، ما الذي يجب فعله تقنيًا إذا أراد مستخدم في المملكة المتحدة الوصول إلى أمازون المملكة المتحدة باستخدام حساب أمريكي؟ دعونا نلقي نظرة على الرسم البياني الهيكلي أدناه. معظم منتجات بوابات API الحالية تقدم حلولًا مشابهة.

حلول بوابة API الحالية لمستوى الامتثال للبيانات

يمكننا تلخيص جوهر هذا الحل في جملة واحدة:

تحدد بوابة API في المملكة المتحدة المستخدم. إذا اكتشفت بوابة API أن المستخدم مسجل في الولايات المتحدة، سيتم توجيه الطلب إلى الخوادم الأمريكية للمعالجة.

ومع ذلك، هناك أيضًا بعض التحديات التقنية الكامنة وراء هذا، بالإضافة إلى مخاطر الامتثال:

1. تحتاج بوابة API إلى قدرات جدولة طرق دقيقة، والحصول على البيانات من رأس HTTP، ووسائط الطلب، ونص الطلب، والتعاون مع استعلامات قاعدة البيانات الخارجية لتحديد الخادم الذي سيتعامل مع المستخدم.

2. يجب أن تكون الشبكة بين المناطق متصلة لإعادة توجيه الطلب. يجب أن تكون غرفة الخوادم في المملكة المتحدة وغرفة الخوادم في الولايات المتحدة متصلة.

3. قد تكون بوابة API في غرفة الخوادم في المملكة المتحدة قد قامت بالفعل بإزالة شهادة SSL، وقراءة محتوى API، وتسجيل البيانات على القرص المحلي أو الخدمات الأخرى من خلال سجلات الوصول، وسجلات التدقيق، وأنظمة المراقبة، إلخ.

هل هناك طريقة لحل هذه المشكلات؟

الشبكة متعددة الطبقات: حل Apache APISIX لضمان امتثال نقل بيانات API

هنا نقدم مفهوم "الشبكة متعددة الطبقات" في APISIX لضمان الامتثال والأمان للبيانات المنقولة عبر API على مستوى بوابة API. الشبكة متعددة الطبقات، كما يوحي الاسم، تقسم بوابة API إلى طبقتين، الطبقة الأولى والطبقة الثانية، كما هو موضح في الشكل التالي:

• بوابة API من الطبقة الأولى: مسؤولة عن إزالة شهادة SSL، وجدولة الطرق الدقيقة، وتحديد بوابة API من الطبقة الثانية التي يجب أن تتعامل مع طلبات API.
• بوابة API من الطبقة الثانية: هذه هي بوابة API الأصلية، والتي لا تحتاج إلى القلق بشأن امتثال البيانات.

بالعودة إلى السؤال في بداية المقال: كيف يمكن لمستخدم مسجل في الولايات المتحدة ضمان امتثال بيانات API بغض النظر عن موقع معاملته؟

أولاً، سيتم إرسال طلب API إلى بوابة API من الطبقة الأولى، وهي في الأساس Apache APISIX ولكن مع إضافة كائن multi-layer network، والذي يمكن ربط البرامج الإضافية المخصصة عليه:

1. تحدد بوابة API من الطبقة الأولى العنوان، الوزن، ومعلومات أخرى عن مجموعات بوابة API من الطبقة الثانية. هنا نقوم بإعداد مجموعة الولايات المتحدة ومجموعة المملكة المتحدة:

http://Layer-1-API-Gateway-IP/apisix/admin/multilayer_network/clusters/cluster-US
{
  "desc": "description",
  "http_port": 80,
  "https_port": 443,
  "gateways": [
    {"host": "IP1", "weight": 1},
    {"host": "IP2", "weight": 2}
  ]
}

http://Layer-1-API-Gateway-IP/apisix/admin/multilayer_network/clusters/cluster-UK
{
  "desc": "description",
  "http_port": 80,
  "https_port": 443,
  "gateways": [
    {"host": "IP1", "weight": 1},
    {"host": "IP2", "weight": 2}
  ]
}

2. تحديد قواعد التوجيه على الشبكة متعددة الطبقات، وربطها بالبرنامج الإضافي bar:

http://Layer-1-API-Gateway-IP/apisix/admin/multilayer_network/routes/bank-foo
{
  "desc": "bank API",
  "hosts": ["foo.com"],
  "uris": ["/*"],
  "plugin_id": "bar"
}

3. تحديد البرامج الإضافية المخصصة:

http://***/apisix/admin/multilayer_network/plugins/bar
{
  "desc": "plugin",
  "plugins": {
    "jwt-auth": {
      ... ...
    },
    "foo-upstream-selector": {
      "scheme": "HTTPS"
      ... ...
    },
    ... ...
  }
}

هنا قمنا بربط برنامجين إضافيين. يتم استخدام برنامج jwt-auth لإكمال مصادقة هوية الطلب. يتم استخدام foo-upstream-selector لقراءة معلومات مثل معرف المستخدم، الدولة/المنطقة، والمجموعة التي ينتمي إليها المستخدم من قاعدة البيانات وتحديد مجموعة بوابة API من الطبقة الثانية التي سيتم توجيهها.

هذا الهيكل متعدد الطبقات يضمن امتثال البيانات عبر الدول المختلفة.

الخلاصة

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