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

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

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

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

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

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

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

هذه الفجوة بنيوية لا تقصير فيها. فوحدة الحوكمة في دليل البيانات هي الجدول والعمود، ووحدة الإدارة في البوابة هي مسار الطلب (Route) والمستهلك. وبينهما تقع طبقة الخدمات، حيث يكتب المهندس استعلامًا، ويحوّل النتيجة إلى كائن 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 — مع مشاركة البيانات وتصنيف البيانات بوصفهما مجالين محكومين. فضوابط المشاركة تتوقع أن تعرف المنشأة ما البيانات التي تشاركها خارجيًا، ومع من، وبموجب أي اتفاقية؛ وضوابط التصنيف تتوقع أن تُطبَّق الوسوم وتُنفَّذ أينما استقرت البيانات أو تحركت. وواجهة برمجة تطبيقات عامة هي مشاركة بيانات بسرعة الآلة. ونقطة نهاية مجهولةُ تصنيفِ محتواها تُخفق في التوقعين معًا — وسيطرح المقيّم يومًا السؤال الذي لا تستطيع لوحاتك الإجابة عنه.

من أين تبدأ؟

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

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

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

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