كيفية إضافة نطاقك الخاص في منصات SaaS؟

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

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

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

تحليل المشكلة

قد تتساءل: ألا يمكن للمستخدمين تحقيق هذه الوظيفة ببساطة عن طريق توجيه سجل DNS CNAME للنطاق إلى النطاق العشوائي الذي توفره المنصة؟ في الواقع، المشكلة أكثر تعقيدًا، وتركز بشكل أساسي على الجوانب التالية:

1. تستخدم جميع خدمات الإنترنت الحديثة بروتوكول HTTPS لضمان أمان الاتصال. عندما يحاول المستخدمون النهائيون الوصول إلى الموقع الذي توفره منصة SaaS، فإن استخدام النطاق الفرعي العشوائي الذي توفره المنصة كنقطة دخول يسمح باستخدام شهادة TLS بدلًا من شهادة معينة، مما يضمن عدم وجود مشاكل في إدارة الشهادات. في هذه المرحلة، تكون المصافحة بين المستخدمين وخدمة HTTPS الخاصة بمنصة SaaS موثوقة. ومع ذلك، عند استخدام نطاق مخصص للمستخدم، يجب أن تمتلك منصة SaaS شهادة موثوقة لهذا النطاق حتى يتمكن متصفح المستخدم النهائي من إنشاء اتصال صحيح، مما يتطلب من المنصة قبول الشهادات التي يرفعها المستخدم أو توفير خدمات إدارة الشهادات المستضافة.

2. بعد إنشاء اتصال آمن، تحتاج منصة SaaS أيضًا إلى تحديد أي مستأجر يحاول المستخدم النهائي الوصول إليه على المنصة. وهذا يتطلب من المنصة الحفاظ على جدول تعيين للنطاقات ومعرفات المستأجرين، واستخراج معلومات مستأجر معينة من الطلبات الواردة، مثل رأس طلب Host، والاستعلام في جدول التعيين للعثور على معرف المستأجر لإرجاع البيانات اللازمة إلى الطالب.

إدارة شهادات TLS

خدمات السحابة الرائدة

توفر مزودو خدمات السحابة الرئيسيون مثل AWS (Amazon Web Services) وGCP (Google Cloud Platform) خدمات إدارة شهادات شاملة وواجهات برمجة تطبيقات (API) مقابلة، حيث أطلقت Cloudflare حتى حلًا مخصصًا، Cloudflare for SaaS، مصمم خصيصًا لخدمات SaaS.

على سبيل المثال، تتيح خدمة AWS Certificate Manager في AWS لمنصات SaaS إصدار شهادات موثوقة للنطاقات المخصصة التي يضبطها المستخدمون بسهولة من خلال واجهة برمجة التطبيقات الخاصة بها. كخدمة ضمن نظام AWS البيئي، فإنها تدمج بسلاسة مع الوظائف الأساسية الأخرى مثل Elastic Load Balancer وCloudFront، مما يسمح باستخدام الشهادات الصادرة من ACM مباشرة لإنهاء TLS.

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

على سبيل المثال، يتطلب AWS Certificate Manager التحقق من ملكية النطاق عند إصدار الشهادات. تتطلب هذه العملية من مالكي النطاقات تعيين سجلات CNAME محددة في سجلات DNS الخاصة بهم تشير إلى عنوان acm-validations.aws. علاوة على ذلك، يجب الحفاظ على هذا السجل لفترة طويلة لعمليات تجديد الشهادات اللاحقة. وهذا يعني أن منصات SaaS يجب أن تعرض تفاصيل تنفيذية محددة خاصة بمنصة السحابة للمستخدمين. بالإضافة إلى ذلك، لا تلتزم هذه الآلية بأي معايير شائعة لأتمتة الشهادات مثل بروتوكول ACME. لذلك، قد تصبح منصات SaaS مرتبطة بشكل وثيق بخدمات سحابة AWS. عندما يكون لدى منصة SaaS عدد كبير من المستخدمين، يصبح الانتقال (الذي يتطلب من كل مستخدم إعادة ضبط سجلات DNS) مهمة شبه مستحيلة.

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

إدارة الشهادات الأوتوماتيكية

مع Let's Encrypt وغيرها من سلطات الشهادات (CAs) التي تعتمد على بيئة إدارة الشهادات الأوتوماتيكية (ACME، RFC8555) التي أصبحت تدريجيًا سائدة، لم تعد إدارة الشهادات الأوتوماتيكية حصرية لخدمات السحابة. في الوقت الحاضر، يمكن لأي مطور تنفيذ إصدار وتجديد الشهادات تلقائيًا بسهولة، مما يعزز بشكل كبير قابلية استخدام الخدمة وأمانها.

تحدد مواصفات ACME آليات مختلفة للتحقق من ملكية النطاق، بما في ذلك ولكن لا يقتصر على DNS TXT، HTTP، TLS ALPN، وما إلى ذلك، مما يوفر لمقدمي طلبات الشهادات خيارات مرنة ومتنوعة. في سيناريو SaaS، تكون طريقة التحقق عبر HTTP مناسبة بشكل خاص. يحتاج المستخدمون فقط إلى تكوين سجلات DNS CNAME لنطاقاتهم المخصصة، وتوجيهها إلى النطاق العشوائي المخصص من قبل المنصة أو نقطة وصول CNAME موحدة. على سبيل المثال، قد تتطلب المنصة من المستخدمين حل example.com إلى cname.contoso.com، وتشير نقطة وصول CNAME هذه إلى خدمة HTTP التي يتم نشرها ذاتيًا من قبل المنصة. يبسط هذا التصميم عملية إصدار الشهادات، مما يجعلها أكثر إيجازًا وفعالية.

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

لا تبسط هذه الآلية عملية التكوين للمستخدم فحسب، بل تتجنب أيضًا عناء تعديل سجلات DNS بشكل متكرر. والأهم من ذلك، أنها تحرر المنصة من قيود مزودي خدمات سحابة معينين، مما يمكن منصات SaaS من توفير تجربة مستخدم أكثر ودية ومتسقة.

بالإضافة إلى ذلك، لا يعني استخدام هذه الآلية أنه لا يمكن استخدام خدمات CDN أو موازنة الحمل لإنهاء TLS في السحابة. في الواقع، تدعم خدمات إدارة الشهادات التي تقدمها مزودو خدمات سحابة مثل AWS المطورين في استيراد الشهادات المدارة ذاتيًا عبر واجهات برمجة التطبيقات للوصول إلى حركة المرور. يحتاج المطورون فقط إلى إكمال إصدار الشهادات في برامجهم الخاصة ثم استيراد الشهادة إلى خدمة إدارة الشهادات الخاصة بمزود خدمة السحابة، وبالتالي تحقيق التكامل السلس والاستخدام الفعال لموارد السحابة.

أنظمة متعددة المستأجرين

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

تطبيق آليات تحديد المستأجرين أمر بسيط نسبيًا. نظرًا لأن التحقق من ملكية النطاق وإدارة الشهادات مطلوبان، يجب على المستخدمين تكوين النطاقات المخصصة في وحدة تحكم منصة SaaS واتباع تعليمات النظام لإعداد حل DNS. بمجرد أن يكمل النظام تكوين الشهادة، يتم تخزين سجلات النطاقات المخصصة في النظام وربطها بالمستأجر الحالي. لذلك، كلما تلقى النظام طلبًا، يحتاج فقط إلى استخراج حقل Host من رأس طلب HTTP لتحديد نطاق الوصول المستخدم من قبل متصفح العميل. بعد ذلك، من خلال الاستعلام في سجل المستأجر المقابل لهذا النطاق، يمكن للنظام تحديد معرف المستأجر بسرعة. بمجرد الحصول على معرف المستأجر، يمكن للنظام الاستعلام والوصول إلى بيانات المستأجر المقابل بدقة.

الخلاصة

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

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