بناء منصة SaaS: تعدد المستأجرين والفوترة وأمان بيانات العملاء

اختر نموذج تعدد المستأجرين أولًا

المقصود بتعدد المستأجرين أن يتشارك عملاؤك، ويسمَّون مستأجرين، بنيتك التحتية. وهذا القرار يحدد الكلفة والأمان ومدى صعوبة تغيير المنتج لاحقًا، فاحسمه قبل إنشاء أول جدول.

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

المصادقة والأدوار والصلاحيات

• البريد وكلمة المرور مع تجزئة قوية، إضافة إلى المصادقة متعددة العوامل للمسؤولين على الأقل.
• تسجيل الدخول الموحد عبر SAML أو OpenID Connect طلب شائع من المؤسسات الكبيرة. خطط لنموذج البيانات بحيث يدعمه، وابنِه حين يحتاجه عميل فعلًا.
• الأدوار: ابدأ بمجموعة صغيرة ثابتة مثل المالك والمسؤول والعضو، وتحقق منها على الخادم عند كل إجراء. أما الأدوار المخصصة فتنتظر.
• الدعوات، وانتهاء الجلسات، وإمكانية إزالة مستخدم وإنهاء جميع جلساته دفعة واحدة.

الصلاحيات هي المكان الذي تختبئ فيه أغلب أخطاء SaaS. تحقق من المستخدم والمستأجر والعنصر المطلوب في كل طلب، ولا تكتفِ بالتأكد من أن أحدًا سجّل دخوله.

فوترة الاشتراكات عبر مزوّد دفع

لا تبنِ الفوترة من الصفر ولا تخزّن أرقام البطاقات. يتولى مزوّد الدفع البطاقات والفواتير وبوابة العميل، ويحتفظ منتجك بسجل لما يحق لكل مستأجر استخدامه.

• استخدم صفحة الدفع وبوابة العميل المستضافتين لدى المزوّد، فلا تصل بيانات البطاقة إلى خوادمك.
• حدّد حالات الاشتراك التي ستواجهها: تجربة، ونشط، ومتأخر السداد، وملغى. وقرر ما تعنيه كل حالة للوصول إلى المنتج.
• اعتبر إشعارات webhook من المزوّد مصدر الحقيقة. تحقق من التوقيع، وعالج كل حدث بحيث لا يضر تكراره، وتوقع أن تصل الأحداث متأخرة أو مرتين.
• احتفظ بحدود الباقات وميزاتها في بياناتك أنت على شكل استحقاقات، فيتغير الوصول عند تغيير الباقة دون إصدار جديد من الشيفرة.

تختلف الضرائب وقواعد الفوترة وتوفر طرق الدفع من بلد إلى آخر. تأكد منها مع مزوّد الدفع ومحاسب قبل أن تحدد الأسعار.

عزل بيانات المستأجرين: أكبر خطر أمني

أسوأ خطأ في المنتج متعدد المستأجرين أن يرى عميل بيانات عميل آخر. وهو نادرًا ما يكون غريبًا: مرشّح مفقود، أو معرّف يسهل تخمينه، أو مورد مشترك لم يربطه أحد بمستأجر.

اربط كل ما يلي بالمستأجر، وافرض ذلك في موضع مركزي واحد بدل تكراره في كل استعلام:

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

اختبر ذلك مباشرة. أنشئ مستأجرين، وسجّل الدخول بأحدهما، وحاول الوصول إلى سجلات الآخر بتغيير المعرّفات في الطلبات. وكسر التحكم في الوصول فئة مسمّاة في OWASP Top 10، وتطرح نمذجة التهديدات للمسارات الأساسية السؤال في البداية: ما أسوأ ما يستطيع مستأجر فعله بمستأجر آخر؟

الإعداد الأول وأدوات الإدارة والدعم

المستأجر الذي لا يصل إلى أول نتيجة مفيدة في جلسته الأولى كثيرًا ما لا يعود. ينبغي أن يوصل الإعداد الأول المؤسسة الجديدة إلى هناك بسرعة:

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

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

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

سجل التدقيق والمراقبة

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

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

حدّد نطاق MVP وأجّل الباقي

الغرض من النسخة الأولى أن تثبت أن المستأجرين سيستخدمون المنتج ويدفعون مقابله. وبعض الأسس مؤلم إضافتها لاحقًا فابنِها الآن، والباقي ينتظر طلبًا حقيقيًا من عميل. هذه فكرة المنتج الأدنى القابل للتطبيق.

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

واجهة ثنائية اللغة من أول شاشة

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

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

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