العزل والثقة
ما هو
لكل بيئة قاعدة بياناتها وحسابات دخول خدماتها ومفاتيحها، فلا يصل مستخدمو تطبيق ورموزهم إلى بيئة أخرى. بعض الأجزاء مشتركة عمدًا: محرك PostgreSQL وStorage والبوابة والخادم نفسه. وكل جزء مشترك موضع يستطيع فيه عطل بيئة واحدة أن يصيب غيرها.
لماذا
الخيار: المشغّلون موثوقون، وزوار التطبيقات ليسوا كذلك. من يدير الخادم ويكتب SQL لبيئاته موثوق. أما زوار التطبيقات، برموزهم المجهولة أو رموز الدخول، فغير موثوقين. يناسب ذلك المستخدم الأساسي، وهو مطوّر واحد أو وكالة تشغّل تطبيقات لعملائها، ويُبقي التصميم صادقًا فيما يحمي منه فعلًا.
البديل المرفوض: استضافة مشتركة لعملاء لا يثق بعضهم ببعض. بيع المساحة لهم يتطلب عزلًا عن المشغّل نفسه وعن أي SQL يُكتب، ولا يقدر محرك PostgreSQL مشترك على ذلك. من يحتاج هذا المستوى فليشغّل نسخًا مستقلة كاملة.
الخيار: بيانات اعتماد منفصلة، لا مخططات منفصلة فقط. الفصل بالمخططات داخل قاعدة واحدة يترك كل البيئات خلف Auth واحد وأدوار API واحدة. أما قاعدة لكل بيئة، بحسابات دخولها وقواعد اتصال لا تسمح إلا لحساب واحد بالوصول إلى قاعدة واحدة، فتُبقي أي سر خدمة مسرّب داخل بيئته.
كيف بنيناه
وكيل TLS وحده يواجه الشبكة، والمحرك وStorage حدود فشل مشتركة.
لا خلط للبيانات: مفتاح البيئة أ ورموزها وحساباتها لا تفتح إلا قاعدتها.
البيئة المزدحمة تستفيد من الخادم الفارغ، لكنها لا تأخذ أبدًا الحصة التي تحتاجها جاراتها. هذه الحدود غير معايرة تحت حمل مستمر.
ما يخص كل بيئة وحدها:
- قاعدة بيانات لا تمنح صلاحية
CONNECTإلا لحسابات دخولها، وقواعد اتصال تسمّي أزواجًا دقيقة من الحساب والقاعدة. هذه القواعد في ملف المصادقة حسب المضيف في PostgreSQL، أي HBA. - ثلاثة حسابات دخول محصورة لخدمات Auth وREST وStorage، بكلمات مرور مولّدة.
- حساب مطوّر للترحيلات والوكلاء وStudio. ليس مستخدمًا خارقًا، ولا يستطيع استعمال أسماء مخططات المنصة، ولا إنشاء إضافات تصل إلى شبكة الخادم أو ترى كل البيئات، مثل
httpوpg_netوdblink(الوصول إلى قاعدة البيانات). - سر توقيع Auth خاص بها، ومفاتيح API عامة وسرية خاصة بها لا يُحفظ من السرية إلا بصماتها، ومستأجر Storage ومفاتيح توقيع خاصة بها.
- حاويات Realtime وEdge Functions وStudio الخاصة بها حين تعمل. لا تصل حاوية الدوال إلا إلى Auth وREST ومستأجر Storage الخاصة ببيئتها، ولكل جلسة Studio شبكة خاصة.
- سجل توجيه يستطيع وضع البيئة في الصيانة دون المساس بغيرها.
ما هو مشترك، ولذلك حدّ فشل مشترك:
- محرك PostgreSQL. انهياره أو امتلاء قرصه أو قفل طويل فيه يصيب كل البيئات عليه. أدوار API القياسية (
anonوauthenticatedوservice_role) موجودة مرة واحدة في كل محرك، لأن أدوار PostgreSQL تشمل العنقود كله. - عملية Storage. تحمل إعدادات كل المستأجرين، واختراقها اختراق لملفات المستأجرين جميعًا.
- البوابة وفهرس التحكم. إذا توقفا، توقفت كل البيئات عن الرد.
- المفتاح الجذري لـVault. أسرار Vault في كل البيئات مشفّرة بمفتاح واحد يخص الخادم. وتبقى منفصلة لأن كل بيئة لا تصل إلا إلى قاعدة بياناتها.
- الخادم. المعالج والذاكرة والقرص والإدخال والإخراج مشتركة. كل حاوية تعمل ضمن فئة موارد لها وزن معالج وحدود إدخال وإخراج لكل جهاز، وتُرفض البيئات الجديدة إذا نقصت الذاكرة أو القرص، أو ارتفع ضغط cgroup، أو ضاقت ميزانية الاتصالات.
الكود: lab/resource_policy.py (الفئات)، وlab/resource_admission.py وlab/pressure_admission.py وlab/connection_budget.py (القبول)، وlab/hba_authority.py (قواعد الاتصال)، وsrc/gateway/handler.ts (فحص المفاتيح).
الحدود
- لا يوفّر صباربيز عزلًا عن مشغّل خادم معادٍ، ولا عن SQL عشوائي يشغّله كاتب موثوق.
- فئات الموارد مضبوطة في الإعدادات، لكنها لم تُعايَر تحت حمل متواصل؛ ما زال الجار المزعج قادرًا على إبطاء غيره.
- إعادة تحميل قواعد الاتصال لا تُنهي الجلسات المفتوحة من قبل.
- استرشد التصميم بعدة مراجعات هجومية، وهي ليست شهادة أمان.
للتعمق
- نموذج التهديد: الأصول والأطراف وحدود الثقة، والأدلة وراء كل إجراء حماية، والثغرات المعروفة.
- مراجعة الأمان والتشغيل.
- سياسة الموارد، وقبول الموارد، وقبول الضغط، وميزانية الاتصالات، والجار المزعج.
- مراجعة Storage المشترك والاستبدال الذري لملف HBA.