النقطة العمياء في الامتثال: واجهات برمجة التطبيقات التي تكشف البيانات الشخصية

تدير معظم المنشآت الكبرى في المملكة اليوم مستويين ناضجين من التحكم. يشغّل فريق البيانات كتالوج البيانات: الجداول مجرودة، والأعمدة تحمل وسوم تصنيف، والملّاك محددون بالاسم، وسياسات الوصول تُراجع دوريًا. ويشغّل فريق المنصات بوابة واجهات برمجة التطبيقات (API Gateway): الحركة موثّقة الهوية، ومقيّدة المعدل، ومضبوطة الإصدارات، ومسجّلة.

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

تخصصان لا يلتقيان

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

• يجيب الكتالوج عن: ما البيانات التي نملكها؟ وما درجة حساسيتها؟ ومن يملكها؟ ومن يحق له الوصول إليها؟
• وتجيب البوابة عن: ما نقاط النهاية المنشورة؟ ومن يستدعيها؟ وهل هي موثّقة الهوية ومقيّدة المعدل ومتاحة؟

أما السؤال الذي لا يجيب عنه أي منهما فهو: أيٌّ من نقاط النهاية العامة لدينا تُعيد بيانات شخصية، وهل لكل منها أساس نظامي يبرر ذلك؟

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

تشريح النقطة العمياء

تتبّع قيمة واحدة عبر بنية تقنية نموذجية:

1. عمود national_id في قاعدة بيانات إدارة علاقات العملاء. صنّفه مكتب إدارة البيانات «مقيّدًا»، ويعرض الكتالوج الوسم والمالك وسياسة الوصول. حتى الآن، كل شيء محكوم.
2. خدمة خلفية تستعلم عن العمود لبناء كائن «ملف العميل». من هذه اللحظة فصاعدًا، لا يوجد التصنيف إلا في الكتالوج؛ فشيفرة الخدمة لا تحمل أي أثر له.
3. يُحوَّل الكائن إلى استجابة JSON على المسار GET /v1/customers/{id}.
4. تُسجَّل نقطة النهاية في البوابة بوصفها داخلية. وبعد ستة أشهر، يحوّل مشروعُ تكاملٍ مع شريك ظهورَها إلى «عام». يذكر طلب التغيير «نقطة نهاية ملف العميل» — لا الحقول الأحد عشر من البيانات الشخصية داخل الاستجابة.
5. تبقى لوحات المتابعة خضراء. الكتالوج لا يزال يعرض عمودًا مقيّدًا تحت ضبط وصول صارم، والبوابة تعرض حركة سليمة موثّقة الهوية. البيانات الشخصية تخرج من الباب الأمامي، وكل شاشات المراقبة تقول إن الأمور على ما يرام.

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

لماذا لا تكتشفها أنظمة DLP وجدران حماية تطبيقات الويب؟

الاعتراض البديهي من فريق الأمن: «لدينا WAF ومنظومة DLP». كلاهما قيّم، لكن أيًا منهما لم يُبنَ لهذه المشكلة.

• جدار حماية تطبيقات الويب (WAF) يفحص الحركة الواردة بحثًا عن بصمات الهجوم: الحقن، والكشط، والطلبات المشوهة. أما عميل موثّق الهوية يتلقى استجابة 200 سليمة البنية، فهو من منظور الـ WAF نظام يعمل كما صُمم. لا هجوم هنا يُكتشف؛ لأن كشف الحقل هو التصميم نفسه.
• أنظمة منع تسرب البيانات (DLP) تطابق الأنماط على قنوات الخروج كالبريد الإلكتروني ونقل الملفات. أما استجابات الواجهات فمنظّمة البنية، ومشفّرة عبر TLS، وعالية الحجم، ومشروعة المظهر. تستطيع مطابقة الأنماط أن تلتقط سلسلة من عشرة أرقام، لكنها لا تستطيع أن تحكم هل هذا الحقل مسموح به في هذه النقطة لـهذا المستهلك. إنها تعرف كيف تبدو البيانات الشخصية، لكنها لا تعرف ما هي البيانات، ولا من يملكها، ولا ماذا يقول تصنيفها. والنتيجة ضجيج بلا حُكم.
• تحليلات البوابة تعرف المسار والمستهلك ورموز الحالة وزمن الاستجابة — ولا تعرف شيئًا عن دلالة محتوى الاستجابة.
• الكتالوج يعرف بدقة ما هي البيانات — ولا يعرف شيئًا عن نقاط النهاية التي تتدفق عبرها.

النقطة العمياء ليست أداة ناقصة، بل وصلة مفقودة بين أدوات يؤدي كل منها عمله على نحو صحيح.

ما الذي تعنيه حوكمة واجهات برمجة التطبيقات فعلًا؟

يتطلب سد هذه الفجوة أربع قدرات متتابعة:

1. الاكتشاف من البوابات

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

2. سلسلة النسب من نقطة النهاية إلى الجدول

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

3. وراثة التصنيف

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

4. تقييم درجة الانكشاف

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

زاوية نظام حماية البيانات الشخصية ومشاركة البيانات في إطار المكتب الوطني

بالنسبة للمنشآت السعودية، ليست هذه المسألة تمرينًا نظريًا في النظافة التقنية.

فنظام حماية البيانات الشخصية مطبَّق بالكامل منذ سبتمبر 2024، وسدايا هي جهة الإنفاذ. وينظّم النظام الإفصاح عن البيانات الشخصية — واستجابة JSON إفصاحٌ بالمعنى نفسه تمامًا الذي يكونه ملف يُسلَّم إلى طرف ثالث. والإفصاح عن بيانات شخصية دون أساس نظامي تصل عقوبته إلى 5 ملايين ريال، وتتضاعف إلى 10 ملايين ريال عند التكرار. والنتيجة المحرجة: لا يمكنك إثبات مشروعية كل إفصاح إذا كنت عاجزًا عن حصر نقاط النهاية التي تؤدي الإفصاحات أصلًا.

ويتعامل إطار المكتب الوطني لإدارة البيانات — بمجالاته الخمسة عشر وضوابطه السبعة والسبعين ومواصفاته الـ 191 — مع مشاركة البيانات وتصنيف البيانات بوصفهما مجالين محكومين. فضوابط المشاركة تتوقع أن تعرف المنشأة ما البيانات التي تشاركها خارجيًا، ومع من، وبموجب أي اتفاقية؛ وضوابط التصنيف تتوقع أن تُطبَّق الوسوم وتُنفَّذ أينما استقرت البيانات أو تحركت. وواجهة برمجة تطبيقات عامة هي مشاركة بيانات بسرعة الآلة. ونقطة نهاية مجهولةُ تصنيفِ محتواها تُخفق في التوقعين معًا — وسيطرح المقيّم يومًا السؤال الذي لا تستطيع لوحاتك الإجابة عنه.

من أين تبدأ؟

تسلسل عملي للربع الأول:

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

المبدأ الذي يستحق الترسيخ: احكم البيانات والقنوات التي تغادر عبرها كنظام واحد، لا نظامين.

وقد بُنيت Goava حول هذه الوصلة تحديدًا — فقدرة حوكمة واجهات برمجة التطبيقات فيها تكتشف نقاط النهاية من بواباتك، وتربطها بالجداول المفهرسة عبر سلسلة النسب، وتقيّم الانكشاف في ضوء التزامات نظام حماية البيانات الشخصية وإطار المكتب الوطني، لتصبح الفجوة بين مستويي التحكم لديك مرئية أخيرًا.