كل منصة تقول إنها تأخذ الأمان على محمل الجد. لا أحد يقولها في تقرير ما بعد الاختراق أيضًا — فهذا هو الوقت الذي تصف فيه أخيرًا البنية بدلاً من الصفات. لذا دعنا ننتقل مباشرة إلى البنية. أسهل طريقة لشرح عزل المستأجرين هي استعراض الطرق الثلاث التي عادةً ما تُخطئ بها الفرق، وما الذي ينكسر عندما تفعل ذلك.
الخطأ الأول: التصفية حسب معرّف المستأجر في كود التطبيق
هذا هو الخيار الافتراضي لأنه الشيء الواضح الذي يُكتب: كل استعلام يحصل على شرط WHERE user_id = ? ، وطالما تذكّره كل مطوّر، يبقى كل طلب داخل حدوده الخاصة. تظهر الأضرار لاحقًا، عندما يحتوي الكود على أربعمائة نقطة نهاية بدلًا من أربع. يضيف أحدهم استعلام تقارير يربط بين جدولين وينسى الفلترة على الجدول الثاني. يبني شخص آخر أداة إدارية "للاستخدام الداخلي فقط" تستعلم دون أي تقييد على مستوى المستأجر، لأن ذلك بدا آمنًا في حينه. لا يكتشف أي اختبار هذين الخطأين، لأن الاستعلام لا يزال يُعيد صفوفًا صحيحة — لكنها صفوف مستأجر آخر.
نحن لا نعتمد على تذكّر كل استعلام السؤال بأدب. أمان مستوى الصفوف مُطبّق في طبقة قاعدة البيانات، بحيث ترفض قاعدة البيانات نفسها إعادة صفوف مستأجر آخر بغض النظر عما طلبه الكود المستدعي. لا يوجد أيضًا أي تجاوز مميز كامن في مسار الطلب — تُطبّق السياسة دائمًا، بما في ذلك المسارات التي قد نميل إلى معاملتها كموثوقة.
الخطأ الثاني: التعامل مع البيئة المعزولة كتحسين، لا كحد فاصل
تُنفّذ الوكلاء هنا كودًا حقيقيًا — وهذا بيت القصيد في المنتج — والحل السريع المُغري هو تشغيل ذلك الكود في مكان مناسب وتقييده "عندما نصل إلى ذلك". يبدو الحطام في هذه النسخة كتبعية مخترقة تم سحبها أثناء عملية بناء تتواصل مع الإنترنت المفتوح، أو تشغيل عملية وكيل تابع لمستأجر يقرأ ملفات تخص مساحة عمل لم يكن مفترضًا أن يراها أبدًا، لأن نظام الملفات كان مشتركًا افتراضيًا ومقيّدًا استثناءً.
بدلاً من ذلك، تعمل أعباء عمل الوكلاء في بيئات معزولة:
- أنظمة ملفات مقفلة.
- خروج شبكي عبر قائمة سماح بدلاً من باب مفتوح.
الوكيل الذي يعمل على بنائك يرى مساحة عملك، ولا شيء غيرها. الكود غير الموثوق — بما في ذلك عمليات بناء تطبيقك الخاص — يُجمَّع داخل حاويات حيث العزل بنيوي، وليس إعدادًا يتذكر أحدهم تفعيله.
الخطأ الثالث: تسليم بيانات الاعتماد إلى الوكيل
هذا هو الأدق، والذي أخمّن أنه يوقع أكبر عدد من الفرق في الفخ. إذا احتاج الوكيل إلى النشر على مضيفك أو النشر في متجرك، فالطريق الأقصر هو وضع رمز OAuth أو مفتاح SSH في سياقه والسماح له باستخدامهما. إنه أيضًا الطريق الأقصر إلى كارثة: تعليمات مُحقنة عبر موجّه نصي، إجراء متوهَّم، بيانات اعتماد تنتهي بها في سجل محادثة في مكان لا ينبغي أن تكون فيه. لا يحتاج الوكيل إلى أن يكون خبيثًا كي يحدث خطأ ما — يكفي أن يخطئ مرة واحدة، وبيده مفاتيح حقيقية.
لذا لا يحتفظ الوكيل بالمفاتيح أبدًا. يتم تخزين بيانات الاعتماد المتصلة بشكل مخصص لمستأجرك (tenant) وتُستخدم فقط للإجراء الذي رُبطت به:
- حسابات المتاجر
- رموز OAuth الاجتماعية
- مفاتيح النشر
- حسابات خدمة Google
عندما يحتاج الوكيل إلى النشر أو الرفع، يطلب من المنصة تنفيذ ذلك؛ فالمنصة هي من تحتفظ ببيانات الاعتماد وتنفذ الإجراء. الوكيل لا يرى أبدًا السر الذي يطلب استخدامه. أما على صعيد التحليلات، حيث تكون خصائص Google أحيانًا مشتركة بين مواقع متعددة، فإن كل سحب لبيانات GA4 يُصفّى حسب اسم النطاق (hostname) بحيث لا تُظهر لوحتك بيانات موقع آخر عن طريق الخطأ، حتى لو كانت الخاصية الأساسية تجمع بيانات لعدة نطاقات.
ما الذي يُتحقق منه فعليًا قبل نشر أي شيء
توجد قاعدتان تنطبقان في كل مكان على هذه المنصة، وهما الأهم هنا تحديدًا:
- لا يمكن للوكلاء إنفاق أموالك.
- لا يمكن للوكلاء النشر نيابةً عنك.
كلا الأمرين يتطلب نقرة منك. هذا يعني أن أسوأ يوم قد يمر به أي مكوّن آلي لا يمكن أن يمس محفظتك أو سمعتك — نطاق الضرر محدود بالتصميم، وليس بحسن تقدير الوكيل. التفاصيل الكاملة حول الاحتفاظ بالبيانات وحذفها موجودة في سياسة الخصوصية؛ تسري طلبات الحذف خلال 30 يومًا.
