منصة مفتوحة المصدر لإدارة الهوية والوصول على Cloudflare Workers، حاصلة على اعتماد OpenID Certified™. توفر المصادقة والتفويض واتحاد الهوية ضمن بنية مصممة للعمل على حافة الشبكة.
بدأ هذا التصميم من موقف مزعج يتكرر أثناء التشغيل: التحقيق في فشل تسجيل الدخول ورؤية معلومات لم تكن بحاجة إلى الاطلاع عليها.
حين يكشف التحقيق معلومات لا تحتاج إليها
عند تشغيل منصة للهوية، يتكرر طلب مثل: «أحد المستخدمين لا يستطيع تسجيل الدخول». ولتشخيص المشكلة، تدخل إلى بيئة العميل وتبحث عن الحساب.
ما تحتاج إلى معرفته محدد: هل الحساب مقفل؟ متى فشلت المحاولة الأخيرة وفي أي خطوة؟ ما مسار تسجيل الدخول المستخدم؟ وهل ما زال مفتاح المرور مسجلاً وصالحاً؟
لا يتطلب أي من ذلك معرفة هوية الشخص. ومع ذلك، يظهر الاسم والبريد الإلكتروني ورقم الهاتف والحسابات المرتبطة فور فتح الحساب. كنت تبحث عن حالة تقنية، فوجدت معلومات عن الشخص أيضاً.
«يرجى عدم النظر» ليست وسيلة حماية إذا كانت المعلومة معروضة بالفعل.
لم يخالف أحد الإجراءات. طلب العميل التحقيق، واتبع الموظف الخطوات الصحيحة، ومع ذلك ظهرت البيانات. بنية النظام هي التي وضعتها أمامه.
الاعتماد على التعليمات والتدريب وحدهما يجعل الحماية رهينة ذاكرة الموظف وانتباهه. فصل البيانات الشخصية في Authrim بدأ بمحاولة حل هذه المشكلة في بنية النظام نفسها.
قاعدتان منذ بداية التصميم
تُحفظ المعلومات التي تحدد الشخص مباشرة في قاعدة بيانات منفصلة فعلياً. الفصل موجود منذ طبقة الوصول إلى البيانات، وليس إضافة لاحقة.
لاحظ آخر بندين على اليسار: سجلات الحذف وسجلات قراءة البيانات الشخصية محفوظة بصورة مستقلة في جانب PII. يُتابَع التعامل مع البيانات الشخصية بمعزل عن سجلات التدقيق الاعتيادية.
بهذا الفصل يمكن حل المشكلة الأولى. حالة القفل ومحاولات الدخول الفاشلة ومعلومات الأجهزة متاحة في جانب Core DB. يمكن منح صلاحيات التحقيق دون إتاحة جانب PII DB، فلا يحتاج الموظف إلى تجنب النظر عمداً.
وتساعد البنية نفسها في الإجابة عن أسئلة التدقيق: أين تُحفظ الأسماء وعناوين البريد؟ وما نطاق الحذف؟ حل المشكلة التشغيلية جعل التصميم أسهل في الشرح أيضاً.
ليست PII DB المكان الوحيد الذي يحتوي على بيانات شخصية
هذه نقطة أساسية: الفصل ليس حداً قانونياً بين البيانات الشخصية وغير الشخصية.
تحتوي Core DB أيضاً على عناوين IP ومعلومات الأجهزة وتاريخ الجلسات وأحداث المصادقة والبيانات الوصفية لبيانات الاعتماد ومعرّفات المستخدمين الداخلية المستقرة. وقد تُعد هذه بيانات شخصية بحسب السياق. فالجمع بينها وبين معلومات أخرى قد يحدد شخصاً.
يفصل Authrim بين البيانات التي تحدد الشخص مباشرة وبيانات الهوية اللازمة للتشغيل. الهدف هو إجراء التحقيق باستخدام الثانية دون الوصول إلى الأولى، وليس إعفاء الثانية من الحماية.
لذلك لا يصح القول إن البيانات الشخصية لا توجد إلا في PII DB. الأدق أن الأسماء والبريد الإلكتروني وغيرها من المعرّفات المباشرة معزولة فيها، بحيث يمكن منح وصول للتحقيق دون فتح ذلك التخزين.
الحذف هو الخطوة الأولى فقط
تنفيذ طلب حذف حساب أمر مباشر. الأصعب هو تلبية الطلبين اللذين قد يأتيان بعده.
الأول هو إثبات الحذف: متى جرى، ومن نفذه، ولماذا. والثاني هو منع إعادة التسجيل خلال فترة محددة.
كلا الطلبين يحتاج إلى التعرف على شخص حُذفت بياناته. لكن إبقاء المعلومات التي تحدده مباشرة يتعارض مع غرض الحذف.
يتيح فهرس معمى باستخدام HMAC-SHA256 المطابقة دون تخزين القيمة الأصلية. يمكن التحقق مما إذا كان عنوان ما قد حُذف، لكن جدول السجلات وحده لا يكشف العنوان الأصلي.
هذا هو مبدأ التنفيذ: الاحتفاظ بالبصمة اللازمة لمنع التكرار فقط، وحذفها بعد انتهاء المدة، مع تسجيل وقت الحذف ومن نفذه وسببه.
متى يصح القول إن القيمة غير قابلة للاسترجاع؟
توضيح تقني: عناوين البريد الإلكتروني منخفضة الإنتروبيا. إذا استُخدمت تجزئة عادية فقط، فقد يكشف هجوم بالقاموس العنوان الأصلي. عدم الاسترجاع ليس ضماناً بلا شروط.
يستخدم Authrim فهرساً معمى بـHMAC-SHA256 ومفتاح سري، مع رقم جيل للمفتاح يسمح بتدويره. دون المفتاح، لا يمكن اختبار العناوين المحتملة بإعادة حساب بصماتها.
إذن عزل المفتاح شرط لهذه الحماية. تخزينه مع البصمات يُفقد هذا الضمان.
إتاحة ما يحتاج إليه التحقيق فقط
لنعد إلى بلاغ تعذر تسجيل الدخول. يحتاج المحقق إلى تحديد موضع توقف المصادقة، ولا يحتاج عادة إلى فتح الاسم أو رقم الهاتف.
يفصل Authrim معلومات التعريف المباشر كي تُمنح صلاحيات التشخيص دون الوصول إلى مخزنها. وإذا احتاج التحقيق فعلاً إلى بيانات شخصية، يتولاها شخص يملك الصلاحيات الإضافية المناسبة.
يحمي التشفير والتحكم في الوصول البيانات، وتسجل سجلات التدقيق استخدامها. وإلى جانب ذلك، ينبغي أن يتمكن الموظف من إنهاء التحقيق المعتاد دون فتح بيانات شخصية لا يحتاج إليها. يجعل فصل التخزين هذه الحالة نقطة انطلاق العمل اليومي.
التنفيذ: فصل التخزين وحدود الوصول مطبّق.
التحقق: تغطيه الاختبارات الآلية في المستودع.
النضج التشغيلي: أعمال التعزيز مستمرة. Authrim ما زال في مرحلة ما قبل 1.0.
يسهّل هذا التصميم إجراءات الحذف، لكنه لا يشكل بحد ذاته ضماناً للامتثال القانوني. يتوقف ذلك أيضاً على إجراءات المؤسسة وعقودها.
يسجّل الشخص دخوله مرة واحدة، لكن تُنشأ عدة جلسات في الطريق. يتطلب تسجيل الخروج تحديد الجلسات التي ينبغي إنهاؤها ومدى امتداد ذلك عبر المسار.
دخول واحد، وثلاثة مفاتيح
لنفترض أنك أضفت «تسجيل الدخول باستخدام Google» إلى خدمتك. بالنسبة إلى المستخدم، هي ضغطة زر واحدة.
لكن كل نظام في المسار ينشئ جلسته الخاصة ويحتفظ بها: جلسة لدى Google وأخرى لدى Authrim وثالثة في تطبيقك.
قد تسمح جلسة باقية للمستخدم بمواصلة العمل أو بالدخول مجدداً دون إعادة إدخال كلمة المرور.
تسجيل الخروج لا يقتصر على عرض رسالة تؤكد ذلك. بل يتطلب تحديد النطاق وإنهاء الجلسات داخله.
إبطال الرموز عملية أخرى
المقصود بالمفاتيح هنا هو الجلسات. أما رموز الوصول والتحديث فلها آلية مختلفة، وإنهاء الجلسة لا يبطل بالضرورة الرموز التي سبق إصدارها. إبطال الرموز عملية مستقلة.
في OIDC، خروج الجلسة وإبطال الرمز وتعطيل الحساب لدى موفر الهوية الأعلى ثلاث عمليات مختلفة. تتناول هذه المقالة الجلسات. وللرموز راجع فحص الرموز وإبطالها.
Authrim في المنتصف
في هذا المسار، يوفر الطرف الأعلى تسجيل الدخول، بينما يطلبه تطبيقك. ويتغير دور Authrim بحسب الطرف الذي يتعامل معه.
يشبه الأمر وكالة سفر: ترتب رحلتك، لكنها عميل يشتري مقعداً من شركة الطيران. يؤدي Authrim الدورين معاً.
غالباً ما يتوقف الخروج في منتصف الطريق
يسير الدخول عبر المسار، لكن الخروج يحتاج إلى من ينقله صراحة.
إنهاء الجلسة الأعلى لا يحذف تلقائياً جلسات Authrim والتطبيق. يجب نقل طلب الإنهاء إلى الأطراف التالية، ثم أن ينهي كل مستلم الجلسة المطابقة. يوضح الرسم الحالة التي تتوافر فيها الطرق والإعدادات المطلوبة.
الفرق هو السهم الأوسط: هل يستطيع Authrim استقبال الإشعار ثم إرساله إلى التطبيقات؟ ويجب أيضاً أن يدعم الموفر الأعلى وكل تطبيق الطرق اللازمة ويضبط إعداداتها.
كيف تظهر المشكلة في العمل اليومي؟
الحالة
نتيجة انقطاع السلسلة
مغادرة موظف
تلغي الموارد البشرية الوصول، لكن التطبيق يبقى مفتوحًا على الحاسوب وتظل البيانات الداخلية مرئية حتى الصباح.
أجهزة مشتركة
في متجر أو مستشفى أو مركز اتصال، يسجّل المستخدم السابق خروجه، لكن تبويبًا آخر ما زال يعرض لوحة حسابه.
فقدان جهاز
يُضغط على «تسجيل الخروج من كل الأجهزة»، لكن الجلسة الحالية وحدها تنتهي.
الاستجابة لحادث
يُحظر الحساب المخترق، لكن جلسة المهاجم تستمر حتى انتهاء صلاحيتها.
التدقيق
يُطلب إثبات وصول تسجيل الخروج إلى كل الأنظمة، ولا يوجد ما يثبت ذلك.
زر الخروج موجود والشاشة تتغير، لكن نطاق تأثيره أضيق مما كان متوقعاً. ولهذا يصعب ملاحظة المشكلة.
حدود الإرسال عبر المتصفح
هناك طريقتان لإبلاغ التطبيقات. الطريقة المعتمدة على المتصفح تواجه قيوداً إضافية.
تستخدم الطريقة الأولى إطارات خفية لإبلاغ التطبيقات، وقد تمنعها قيود الخصوصية في المتصفح. أما القناة الخلفية فتربط الخوادم مباشرة، ولذلك لا تعتمد على حالة المتصفح. لكنها لا تضمن التسليم: قد يفشل بسبب الشبكة أو توقف المستلم أو المهلة أو استجابة 5xx. إعادة المحاولة والطوابير وسجلات الفشل مسؤولية التنفيذ.
تشمل شهادة Authrim استقبال إشعارات القناة الخلفية. ويجب التحقق من الاستقبال والإرسال اللاحق كل على حدة.
التحقق من المستلم والمرسل معاً
يعمل Authrim كطرف معتمد (RP) تجاه الموفر الأعلى، ومزوّد OpenID (OP) تجاه التطبيقات. ويتطلب تمرير الخروج الالتزام بالمواصفات في الدورين.
بصفته OP: يرسل الإشعارات كي تتمكن التطبيقات المتصلة من إنهاء جلساتها المطابقة.
توفر شهادات ملفات تعريف الخروج OP وRP دليلاً على هذين الدورين. حصل Authrim عليها عبر إجراء الاعتماد الذاتي لدى OpenID Foundation باستخدام اختبارات المطابقة الرسمية.
تعني الشهادة أن نسخة التنفيذ المقدمة اجتازت اختبارات ملفات التعريف المطلوبة. ولا تضمن إنهاء كل جلسة فوراً عبر تطبيقات العميل وشبكته.
يجب أن يدعم الموفر الأعلى والتطبيقات الطرق المطلوبة مع ضبط نقاط الإشعار وربط الجلسات. تعطيل الحساب الأعلى لا يولد إشعار خروج بالضرورة. ويجب اختبار فشل التسليم وإعادة المحاولة وإمكانية متابعة الفشل في البيئة المنشورة.
هذا هو السؤال عند تسليم جهاز مشترك إلى زميل أو إنهاء وصول موظف غادر. يستقبل Authrim الإشعارات ويرسلها بين الموفر الأعلى والتطبيقات. الشهادة تقدم دليلاً على التنفيذ، بينما يحدد اختبار الأنظمة المتصلة ما إذا كان الخروج يشمل النطاق المقصود.
كلمات المرور محفوظة أصلًا في Active Directory. كيف تضيف تسجيل دخول حديثًا دون نسخ بصماتها أو إتاحة نقطة اتصال واردة جديدة؟ لهذا صُمّم Authrim Relay.
البدء مما لا يمكن تغييره
حسابات الموظفين في Active Directory، وكذلك سياسات كلمات المرور وانتهاؤها وتعطيل حسابات المغادرين. هذا هو النظام المعمول به منذ سنوات.
تريد إضافة مفاتيح المرور وتنظيم المصادقة متعددة العوامل وتوسيع الدخول الموحد إلى SaaS. ويظهر السؤال الأول: أين يجري التحقق من كلمة المرور؟
بعض البنى تزامن تجزئات كلمات المرور إلى السحابة، وأخرى تطلب من الدليل الداخلي التحقق. المهم معرفة موضع بيانات الاعتماد، ومن يبدأ الاتصال، ومن يشغّل مساره.
يترك WordWarden التحقق لدى LDAP/AD ويتيح اختيار المسار. يقدم Authrim Relay اتصالاً صادراً للمؤسسات التي لا تريد نشر نقطة دخول جديدة.
ماذا يفعل WordWarden؟
Authrim WordWarden هو موصل دليل، خدمة صغيرة تعمل قرب LDAP/AD. تستقبل اسم المستخدم وكلمة المرور، وتسأل الدليل، ثم تعيد نتيجة التحقق.
يتولى Authrim واجهة الدخول والجلسات ومفاتيح المرور ورموز البريد واتحاد الهوية وربط سجلات التدقيق ومطابقة الهويات. أما WordWarden فيجري التحقق بجوار الدليل فقط.
يغير اتجاه الاتصال إعدادات الشبكة والمكونات التي تحتاج إلى تشغيلها.
من يتصل بمن؟
يدعم WordWarden ثلاثة مسارات، تختلف في الحاجة إلى نشر نقطة تستقبل اتصالات من الخارج.
توضح الأسهم من يبدأ الاتصال. في Direct HTTPS يتصل Authrim بالنقطة المنشورة. يبدأ Tunnel وRelay من الشبكة الداخلية؛ الأول عبر عملية cloudflared مستقلة، والثاني باتصال يحافظ عليه WordWarden نفسه.
ما المناسب لبيئتك؟
في نشر جديد لا يريد إضافة وصول وارد، ابدأ بالنظر في Relay. وقد يفيد استخدام منصة نشر أو نفق قائمين. الأمثلة التالية سيناريوهات اختيار وليست ادعاءات عن عملاء يستخدمون المنتج.
Authrim Relay: إبقاء AD داخلياً دون إضافة وصول وارد
مثلاً، شركة تحتاج إلى مراجعة منفصلة لكل خادم عام جديد، أو جامعة تمنع الاتصالات الواردة إلى شبكة LDAP داخل الحرم. يتصل WordWarden بـAuthrim دون نشر منفذ وارد جديد في تلك الشبكة.
لا حاجة إلى نقطة عامة جديدة أو عملية نفق منفصلة. يجب السماح بـWebSocket الصادر، ومراقبة WordWarden واتصاله. لا يعمل Relay في شبكة تحظر كل اتصال خارجي.
Cloudflare Tunnel: الاستفادة من تشغيل نفق قائم
إذا كانت المؤسسة تنشر أدوات داخلية عبر Cloudflare Tunnel ولديها فريق يدير تحديثات cloudflared والمسارات، يمكن إدراج WordWarden في الإجراءات نفسها دون فتح منفذ وارد جديد.
تُضبط أسماء المضيفين والمسارات التي توصل طلبات Authrim إلى الموصل، مع صيانة النفق. لا يحتاج المضيف الداخلي إلى وصول وارد مباشر، لكن الطلبات تمر عبر Cloudflare.
Direct HTTPS: استخدام منصة قائمة لواجهات API العامة
قد تدير شركة أو جامعة أو مؤسسة بحثية منطقة DMZ ووكيلاً عكسياً للتكاملات الخارجية. يمكن حينها تشغيل نقطة HTTPS يصل إليها Authrim ضمن إجراءات الشهادات وسجلات الوصول والمراقبة القائمة.
لا حاجة إلى إبقاء اتصال نفق أو Relay منفصل. في المقابل، تسمح المؤسسة بالمسار الوارد وتحمي النقطة العامة وتصونها. المنشور هو واجهة HTTPS للموصل، وليس منفذ LDAP/AD مباشرة على الإنترنت.
كل الطرق تتطلب تشغيل WordWarden في مكان يستطيع الوصول إلى LDAP/AD. كون الجهة أكاديمية لا يحدد الطريقة؛ البنية الحالية وسياسة الشبكة هما ما يحددانها.
Authrim Relay: اتصال يبدأ من الداخل
في وضع Relay، يتصل WordWarden من داخل الشبكة بـAuthrim عبر WebSocket. يبقي WebSocket قناة الاتصال مفتوحة كي يتمكن الطرفان من تبادل الرسائل.
يحافظ WordWarden على الاتصال وينتظر. عند تسجيل الدخول، يرسل Authrim عبر المسار نفسه: «تحقق من هذا المستخدم». يسأل WordWarden الدليل الداخلي ثم يعيد النتيجة.
يشبه ذلك إجراء مكالمة من داخل المؤسسة والبقاء على الخط؛ يمكن للطرف الآخر أن يتحدث أيضاً. لا يلزم اتصال وارد جديد مع كل طلب.
لذلك لا تنشر شبكة الدليل عنوان URL لهذا المسار. يقل عبء إدارة اسم عام وشهادة وWAF جديد للموصل. وتظل صلاحية الخروج وصيانة WordWarden ومراقبة الاتصال مطلوبة.
تفصيل تقني: الفرق بين WebSocket ونشر منفذ وارد
الفرق هو من يبدأ الاتصال. في Direct HTTPS توفر المؤسسة نقطة يصل إليها Authrim. وفي Relay يبدأ WordWarden الداخلي اتصال WebSocket مشفراً (wss) نحو Authrim.
يتابع جدار الحماية ذو الحالة أو NAT عادة الاتصالات التي بدأت من الداخل ويسمح بحركة عودتها. وهكذا يستقبل WordWarden طلبات التحقق دون نشر منفذ وارد أو إعداد تحويل منافذ لاتصالات خارجية جديدة.
هذا لا يعني عدم استخدام منافذ. يستخدم wss عادة منفذ TCP 443 لدى الوجهة. يجب أن يسمح الجدار أو الوكيل بالخروج إلى Relay وباتصالات WebSocket المستمرة. لا تصل الطلبات عبر هذا المسار أثناء انقطاعه، لذا تبقى المراقبة مهمة.
تقليل نقاط الاتصالات الخارجية الجديدة لا يلغي طلبات التحقق عبر الاتصال القائم. تبقى مصادقة الطرف الآخر والتحقق من الطلبات ضروريين.
الاتصال الصادر يحتاج إلى مصادقة أيضاً. يجمع Relay بين مصادقة الموصل والتحقق من الوجهة المضبوطة.
تفصيل تقني: المصادقة باستخدام HMAC
يرد WordWarden بـHMAC على تحدٍّ قصير الصلاحية، بتوقيع سلسلة تضم معرّف التحدي وقيمة nonce. ويتحقق من تطابق معرّفي المستأجر والموصل في عنوان الوجهة مع إعداداته.
HMAC إلزامي في الطرق الثلاث. يقلل Relay التعرض للاتصالات الواردة، ولا يلغي مصادقة الموصل أو إدارة الأسرار.
ما الذي يعبر الحدود فعلاً؟
يجب توضيح هذا بدقة: ليس صحيحاً أن كلمة المرور لا تغادر الشبكة أبداً.
عند إدخالها في واجهة الدخول، تمر عبر Authrim. الوصف الدقيق هو أن Authrim وWordWarden لا يخزنانها، لا أنها لا تغادر المؤسسة.
تنص الوثائق على أن Authrim لا يستورد كلمات المرور ولا يجزئها أو يعيد تجزئتها أو يحفظها، ويشمل ذلك التجزئات القادمة من نظام قديم.
البيانات العائدة محدودة أيضاً
عند النجاح، يتلقى Authrim النتيجة والسمات المطلوبة الموجودة في قائمة السماح المحلية للموصل. لا يحدد الطرف الطالب نطاق البيانات التي يحصل عليها؛ جهة الدليل هي التي تقرر ما ترسله.
لذلك لا يكفي تغيير إعدادات Authrim وحده لتوسيع السمات المستخرجة من الشبكة الداخلية.
كلمة المرور جسر للانتقال
هذا التكامل موجود لفترة الانتقال.
يبقى LDAP/AD مرجع كلمات المرور، ويستمر المستخدمون بحساباتهم الحالية مع تسجيل مفاتيح المرور تدريجياً. يبقى رمز البريد مساراً للاسترداد، فتتغير وسيلة المصادقة مع استمرار الدخول.
وتمنع الوثائق صراحة تصدير تجزئات كلمات مرور LDAP/AD إلى Authrim؛ فهذا ينشئ نسخة من بيانات الاعتماد بدلاً من تسهيل الانتقال.
النسخة التجريبية العامة قيد الإعداد. الهدف الأول v0.1.0-beta.1.
مخصص للتجارب الأولية لدى جهات تستطيع تشغيل خدمة قرب LDAP/AD وتفهم حدود الدليل والشبكة وTLS وإدارة الأسرار. ليس خدمة دليل مُدارة.
يتطلب Authrim 0.3.2 أو أحدث مع تفعيل Directory Authentication وRelay. تحتاج تغييرات الإعداد في النسخة التجريبية الحالية إلى إعادة تشغيل العملية.
نسخ بيانات الاعتماد أو فتح مدخل وارد ليسا الخيارين الوحيدين.
إجراء التحقق قرب الدليل وبدء الاتصال من الداخل يتيحان دخولاً حديثاً دون نسخ تجزئات كلمات المرور أو نشر نقطة استقبال داخل الشبكة.
والهدف التالي هو الانتقال إلى مفاتيح المرور. يهيئ تكامل الدليل أساساً لهذا الانتقال دون إيقاف تسجيل دخول المستخدمين.
ازدياد المستخدمين خبر سار، لكنه يطرح سؤالًا: إلى متى تستوعبهم قاعدة البيانات الحالية؟ تجهّز Authrim مساحة الحسابات الجديدة قبل الحاجة إليها، حتى لا يبدأ النمو بمشروع ترحيل.
إضافة التخزين قبل نقل البيانات
تضع Cloudflare D1، التي يستخدمها Authrim، حداً لكل قاعدة: 500 MB في الخطة المجانية و10 GB في المدفوعة. ومع نمو المستخدمين والبيانات، ستحتاج إلى موضع تخزين آخر.
صُمم Authrim لتوزيع الحسابات بين قواعد متعددة منذ البداية، دون نقل كل الحسابات القديمة عند التوسع. نسمي كل وحدة تخزين جزءاً أو shard.
تبقى الحسابات الحالية في مكانها، وتُضاف وجهات للحسابات الجديدة. هذا أساس توسيع تخزين الحسابات.
أنواع البيانات تنمو بسرعات مختلفة
تُخزن إعدادات المستأجر مثل عملاء OAuth والسياسات، والحسابات والبيانات الشخصية، وفهارس العثور على موقع الحساب بالبريد الإلكتروني بصورة منفصلة.
زيادة المستخدمين لا تعني توسيع كل القواعد معاً. تختلف أعداد السجلات وسرعة نمو الحسابات والفهارس، فتُضاف السعة حيث تلزم.
يُخصص الحساب الجديد لأحد الأجزاء المتاحة لمستأجره. تُفضل الأجزاء السليمة التي تكون نسبة الحسابات المخصصة فيها إلى العدد المستهدف أقل.
المعيار ليس نسبة استخدام القرص، بل كم حساباً إضافياً يمكن قبوله ضمن الهدف المضبوط. إذا كان الهدف 100,000 حساب، فإن هامش 20,000 حساب يساعد في تحديد موعد تجهيز الجزء التالي.
عندما يقل الهامش المتاح، يُخصص جزء احتياطي جاهز. وينطبق ذلك على الأجزاء المشتركة بين مستأجرين أو المخصصة لمستأجر واحد.
مستأجرون مشتركون
مستأجرون مخصصون
تخزين مشترك ومخصص
في النشر المشترك والمخصص والمختلط، تستقبل الأجزاء المضافة الحسابات الجديدة. يمثل مستوى الماء عدد الحسابات المخصصة، لا استخدام القرص ولا لحظة الإنشاء. والفواصل تعبر عن العزل المنطقي للمستأجرين.
ما الذي لا يلزم تكراره في التشغيل اليومي؟
بعد إعداد الإنشاء التلقائي، لا يحتاج المشغّل إلى إنشاء قاعدة وجداول وربط وجهة تسجيل جديدة كلما زاد التسجيل. كما لا تتطلب كل إضافة سعة خطة لنقل الحسابات الموجودة.
يتابع المشغّل التقدم والأخطاء والاستخدام والتكلفة. وتظل مشكلات الصلاحيات أو حدود الخدمة بحاجة إلى تدخله. في هذا التقسيم للعمل، يجهز Authrim وجهة التخزين التالية.
المساحة المتاحة اليوم لا تكفي للتوقع
مع سعة متبقية لـ20,000 حساب، تختلف مهلة الاستعداد بين خدمة تضيف 100 حساب يومياً وأخرى تضيف 10,000 في الساعة.
لذلك يتوقع Authrim السعة المستقبلية من معدلات التسجيل الأخيرة والتخصيص الحالي، للحسابات والفهارس معاً. تعمل مهمة دورية كل دقيقة، وتُحدّث توقعات الحسابات بعد التخصيص أيضاً.
تدخل الأجزاء الجاري إنشاؤها في الحساب، كي لا تنشئ عدة عمليات قواعد زائدة عندما تكتشف النقص نفسه.
من الإنشاء إلى الاستخدام
عندما لا تكفي الأجزاء الاحتياطية، ينشئ Authrim قواعد D1 عبر واجهة إدارة Cloudflare، ويجهز الجداول ووصول Workers ويوزع المواقع الجديدة. لا تصبح القاعدة وجهة للتخصيص إلا بعد نجاح فحوص القراءة والكتابة.
يجب تفعيل الإنشاء التلقائي وإعداد رمزي API منفصلين لـD1 وWorkers. وعندما يتعذر التنفيذ التلقائي، يتابع المشغّل عبر أداة الإعداد.
يُحفظ تقدم الإنشاء. يمكن إعادة المحاولة بعد عطل اتصال مؤقت اعتماداً على تلك الحالة. أما نقص الصلاحيات أو بلوغ حدود الموارد فيحتاج إلى معالجة السبب قبل الاستئناف.
إذا تأخر التجهيز ونفدت الأماكن، فقد تحتاج عمليات التسجيل الجديدة إلى إعادة المحاولة. الاستعداد المبكر يهدف إلى تقليل الانتظار.
المشغّل يقرر نقل البيانات
إضافة السعة ونقل البيانات عمليتان مختلفتان. فنقل مستأجر من جزء مشترك إلى جزء مخصص يحتاج أيضاً إلى نسخ بياناته الحالية.
يقرر المشغّل بدء النقل. وبعد الموافقة، يتولى Authrim المزامنة والتحقق والتحويل.
بعد الموافقة، تُزامن البيانات ويُتحقق منها قبل التحويل إلى التخزين المخصص. تتضمن العملية مرحلة توقف الكتابة لفترة قصيرة.
التغيير المدعوم حالياً هو من المشترك إلى المخصص. العودة إلى المشترك وإعادة توزيع الحسابات القائمة تلقائياً بالتساوي غير مطبقتين.
حذف جزء خرج من الاستخدام يحتاج إلى موافقة أيضاً. زيادة السعة لا تبدأ تلقائياً نقل البيانات الحالية أو حذفها.
ما الذي جرى قياسه؟
في اختبار خلال يوليو 2026 شمل 200,000 حساب، استخدمت Core نحو 208 MB وPII نحو 238 MB وLookup نحو 426 MB. كان كل منها أقل من 5% من حد 10 GB للقاعدة المدفوعة. ويتغير الاستخدام الفعلي بحسب السمات والفهارس.
الهدف الافتراضي 100,000 حساب لكل جزء، مع هامش لتجهيز التالي بدلاً من ملء القاعدة حتى حدها المادي.
Authrim في مرحلة ما قبل 1.0، والخبرة التشغيلية الطويلة على نطاق واسع ما زالت قيد البناء. قياس تخزين 200,000 حساب اختباري مختلف عن تشغيل خدمة يستخدمها ملايين الأشخاص يومياً.
خطط نقل أقل مع النمو
يمكن لخدمة صغيرة البدء بأجزاء قليلة وإضافة وجهات مع نمو التسجيل، دون تجهيز بنية ضخمة منذ اليوم الأول. يتضمن Authrim الاستعداد والإجراءات اللازمة لذلك.
عندما يزداد المستخدمون، نريد ألا يكون نقل قاعدة البيانات أول مهمة في القائمة. تقليل هذا العمل يتيح وقتاً أكبر لتطوير الخدمة نفسها.
قياس التخزين في 30 يوليو 2026 باستخدام 200,000 حساب اختباري. وحدة MB عشرية. حدود D1 موضحة في وثائق Cloudflare.
الأداء
أحمال خضعت للاختبار.
3,500RPSنقاط نهاية الرموز
150عملية دخول / ثانيةمسار تسجيل دخول OAuth كامل
1–4msزمن CPU المعتاد
0% أخطاءخلال الاختبارات
تغطي اختبارات K6 Cloud أحمال OIDC تمثيلية. تعتمد السعة على نمط الحمل وحدود خطة Cloudflare والتخزين وتقسيم البيانات.
لا تفرض Authrim رسومًا لكل مستخدم. تعتمد تكلفة البنية التحتية على الطلبات وزمن CPU والتخزين والسجلات. هذا تقدير تقريبي لتكاليف Cloudflare، وليس عرض سعر لبيئة إنتاج.
المستخدمون النشطون شهريًا50,000
1,00010,000,000
نوع الخدمة
الافتراضاتدخول أسبوعي، نشاط يومي 10%، جلسة 7 أيام
مجاني/ شهر
الطلبات~1M
لكل مستخدممجاني
Workers: الفئة المجانية (100 ألف يوميًا)(USD)
يعتمد التقدير على أسعار Cloudflare Workers مع معامل لتكلفة KV وDurable Objects وD1، استنادًا إلى أنماط استخدام Authrim المرصودة.
ملاحظة — للبنية التحتية فقط. لا يشمل الامتثال والمراقبة والدعم والتشغيل والمراجعة الأمنية وقواعد البيانات الخارجية والاستخدام الكبير لـR2 أو الأرشيف. تختلف التكلفة الفعلية باختلاف إعداد النشر.
