الوصول المفوّض
قم بإشراك مطور، أو تسليم الفوترة إلى محاسبك، أو منح العميل نافذة للقراءة فقط لمواقعهم الخاصة، أو السماح لفريق الدعم لدينا بفحص مشكلة ما. كل منح هو دور بأذونات محددة، مخصص لمؤسسة، ومطبق في قاعدة البيانات، ومسجل في سجل تدقيق للإضافة فقط.
تشارك بيانات تسجيل دخول واحدة هو السبب في حدوث مشكلات الوصول إلى الحسابات. في Zinn Digital®، يمتلك كل شخص هويته الخاصة، والوصول عبارة عن عضوية — مستخدم، ومؤسسة، ودور — يمكنك منحها أو تغييرها أو إلغاؤها بشكل مستقل.
يسجل كل متعاون دخوله بهويته الخاصة عبر Keycloak، وهي طبقة الهوية لدينا. لا أحد يكتب كلمة المرور الخاصة بكم، ولا أحد يشارك جلسة المتصفح، وإزالة أي شخص تتم بإجراء واحد بدلاً من تغيير كلمة المرور والارتباك لمعرفة من كان يعرفها أيضاً.
الحسابات ذات هيكل هرمي — تحتوي مؤسسة الموزع على مؤسسات العملاء، وتحتوي مؤسسات العملاء على المواقع. تنطبق العضوية على المؤسسة وكل ما يندرج تحتها، بحيث يمكنكم منح عميل الوكالة إمكانية التحكم في مؤسسته الخاصة دون الكشف مطلقاً عن عملائكم الآخرين.
إن عزل المستأجرين ليس مجرد عامل تصفية في رمز التطبيق البرمجي يمكن لخطأ تجاوزه. حيث يحدد أمان مستوى الصف (Row-Level Security) في Postgres نطاق كل استعلام وفق الشجرة الفرعية لمؤسسة المتصل، وبالتالي فإن أي طلب خارج نطاقك لا يجد شيئاً لعرضه.
إذا طلبت مؤسسة أو موقعًا خارج نطاقك، فستستجيب واجهة برمجة التطبيقات برسالة "لم يتم العثور عليه" عادية بدلاً من خطأ في الأذونات. إذ يؤكد خطأ الأذونات وجود السجل، بينما لا يكشف عدم العثور عليه أي شيء على الإطلاق لأي طرف خارجي.
الأذونات عبارة عن مفاتيح دقيقة — الوحدة بالإضافة إلى الإجراء، مثل sites.restart أو billing.refund — وتقوم الأدوار بتجميعها. وتغطي أربعة أدوار الهياكل التي تحتاجها الفِرق الفعلية، وكل دور منها عبارة عن بيانات نقوم بتهيئتها مسبقًا، وليس منطقًا مدفونًا في التعليمات البرمجية.
تحكم كامل: إنشاء مؤسسات فرعية، ودعوة الأعضاء وإزالتهم، وتغيير الأدوار، وإدارة مفاتيح API، وإنشاء المواقع وإعادة تشغيلها ومسح بياناتها المؤقتة وتعليقها وحذفها، وإدارة الفواتير والمدفوعات، وفتح التذاكر، وقراءة سجل التدقيق. الدور الذي تحتفظ به لنفسك.
يعرض المؤسسة وأعضاءها ودليل الخطط، ويدير الفواتير وطرق الدفع والرسوم. لا يملك حق الوصول لإنشاء أي موقع أو تعديله أو حذفه — تماماً كما ينبغي لمحاسب خارجي.
يعرض المواقع وينشئها، ويعيد تشغيل الخدمات، ويمسح ذاكرة التخزين المؤقت، ويدير مفاتيح API ويتعامل مع التذاكر. مستبعد عمداً: الفوترة، والفواتير، وطرق الدفع، وإدارة الأعضاء، وتعليق المواقع، وحذف المواقع. يمكن للمقاول البناء دون أن يتمكن من محاسبتك أو تدمير أي شيء.
يرى المؤسسة، وأعضاءها، ومواقعها، وفواتيرها، ودليل الخطط، والتذاكر، وحالة الترجمة، وسجل التدقيق — ولا يمكنه تغيير أي منها. الصلاحية المناسبة لعميل يريد الاطلاع، أو لمدقق حسابات، أو لجهة معنية تحتاج فقط إلى المشاهدة.
لا يكون تفويض الوصول آمنًا إلا إذا كانت الحسابات التي تفوض إليها صعبة الاختراق. وتتم المصادقة عبر Keycloak لكل شخص في الحساب، على كل واجهة.
يتطلب عمل الدعم أحيانًا الاطلاع على ما بداخل حسابكم. ويخضع هذا الوصول لنفس نموذج الأذونات المطبق على كل شيء آخر — حيث يتواجد الموظفون ببساطة ضمن مؤسسة موظفين، مقسمين إلى أقسام تتمتع بصلاحيات محدودة.
يتم تجميع الموظفين في فئات الدعم، الفوترة والمالية، مكافحة إساءة الاستخدام والثقة والأمان، المبيعات، تأهيل العملاء الجدد، الهندسة والعمليات، التسويق، والإدارة. يمنح كل دور وحدات وإجراءات محددة، بحيث لا يرى الوكيل سوى الجزء من لوحة تحكم المسؤول الذي يتطلبه عمله دون البقية.
يمنح دور وكيل الدعم هذه الصلاحيات تحديداً: عرض العملاء، وعرض التذاكر والرد عليها، وعرض المواقع، وإعادة تشغيل الموقع ومسح ذاكرة التخزين المؤقت الخاصة به. ولا يتضمن أي تكوين للفوترة، أو استرداد للأموال، أو تعديل للخطة، أو إدارة للأسطول. إن إجراءات المعالجة التي يمكن للوكيل تنفيذها مقيدة بالدور، وليس بالنوايا الحسنة.
إذن customer.impersonate ليس جزءًا من دور Manager — فهو مخصص فقط لـ Super Admin. عندما تكون هناك جلسة تعمل بالنيابة عنكم، تعرض لوحة التحكم شريط انتحال دائم حتى لا يكون هناك أي غموض بشأن هوية من يتصرف.
يُضاف كل إجراء ذي صلاحيات أو إداري إلى سجل تدقيق للإضافة فقط، يُسجِّل الفاعل، والإجراء، والهدف، والبيانات الوصفية الداعمة، وعنوان IP، والطابع الزمني — مقسماً زمنياً في بيئة الإنتاج. يمكن للمالكين والأعضاء ذوي صلاحية القراءة فقط قراءة سجل مؤسستهم بأنفسهم.
يمكن أن تتطلب إجراءات الموظفين الحساسة والمدمرة مصادقة إضافية أو موافقة شخصين قبل تنفيذها، كما أن الأقسام والأدوار الجديدة تتطلب مجرد ضبط للإعدادات بدلاً من تغيير في التعليمات البرمجية.
تتم مصادقة البرامج النصية، ومسارات التكامل المستمر (CI)، وواجهة سطر الأوامر (CLI)، ومزود Terraform، ووكلاء الذكاء الاصطناعي جميعها من خلال نفس نموذج الأذونات مثل الأشخاص — دون بيانات اعتماد بشرية مشتركة، ودون أسرار طويلة الأمد يتم لصقها في عملية البناء.
تنتمي المفاتيح إلى مؤسسة وتحمل نطاقات دقيقة مرتبطة بأذونات RBAC نفسها — للقراءة فقط، الفوترة، التوفير. امنح مسار العمل النطاق المحدود الذي يحتاجه فقط بدلاً من منح حساب العضو بالكامل.
تختلف مفاتيح وضع الاختبار عن مفاتيح الوضع المباشر، وبالتالي لا يمكن للتكامل قيد التطوير الوصول إلى بيانات الإنتاج عن طريق الخطأ أو عبر متغير بيئة منسوخ.
نقوم بتخزين تجزئة SHA-256 للسر وبادئة بحث — ولا نخزن أبدًا المفتاح الأصلي. ترى المفتاح مرة واحدة فقط عند إنشائه. يتتبع كل مفتاح وقت آخر استخدام له ويمكن إلغاؤه بشكل مستقل دون التأثير على أي شيء آخر.
يتيح خادم MCP الخاص بنا لأي وكيل يدعم MCP إدارة استضافتكم بلغة طبيعية، مع مصادقة عبر OAuth 2.1 ومحدد لنطاق مؤسستكم ودور التحكم في الوصول القائم على الأدوار (RBAC)، بالإضافة إلى رموز مميزة قابلة للإلغاء لكل أداة، وتأكيد على الإجراءات التدميرية، وحدود للإنفاق، وتسجيل تدقيق كامل.
إن الوصول إلى الحساب والوصول إلى الخادم مسألتان مختلفتان. تُدار بيانات الاعتماد على مستوى الموقع من لوحة التحكم، وتُمنح بأدنى حد من الصلاحيات، وتُعزل لضمان أن تكون واجهة الأوامر الخاصة بأحد المساهمين مقتصرة فقط على موقع واحد.
يحتفظ المشغل الفردي بمؤسسة واحدة وعضوية مالك واحدة، ويضيف دور مطوّر عندما ينضم مقاول من أجل مشروع ما. وعندما ينتهي المشروع، تتم إزالة العضوية ويتوقف تسجيل دخوله عن العمل على الفور — دون ترك أي بيانات اعتماد مشتركة تحتاج إلى تدوير.
تستخدم الوكالة شجرة المؤسسة. يحصل كل عميل على مؤسسة فرعية خاصة به تضم مواقعه، ويحصل موظفو العميل على عضويات فيها — للقراءة فقط لأصحاب المصلحة الراغبين في الاطلاع، وصلاحية المالك للعميل الذي يفضل الإدارة الذاتية. يمتلك موظفوكم عضويات في مستوى أعلى من الشجرة ويتسنى لهم الاطلاع على محفظة الأعمال؛ بينما لا يرى العميل سوى فرعه الخاص، وميزة الأمان على مستوى الصف (Row-Level Security) هي ما تجعل ذلك حقيقة واقعة وليس مجرد وعد.
يعمل الموزع بالطريقة نفسها، ولكن بمستوى أعلى بدرجة واحدة: تضم مؤسسة الموزع مؤسسات العملاء، ولكل منها أعضاؤها وطريقة عرض الفواتير ومواقعها الخاصة. الآلية الأساسية نفسها تدعم الحسابات الفرعية وفرق الوكالات والتسلسلات الهرمية للموزعين — فلا توجد آلية منفصلة أو أضعف لأي منها.
كل شيء متاح في التجربة المجانية لمدة 14 يومًا دون الحاجة لبطاقة ائتمان. سجّل دون بيانات دفع، وادعُ زميلاً، وشاهد ما يمكن لكل دور الوصول إليه وما لا يمكنه، واطلع على سجل التدقيق الخاص بك.
تمنح العضوية اليوم دورها عبر المؤسسة وكل ما يقع تحتها في التسلسل الهرمي، لذا فإن الطريقة لفصل مجموعات المواقع هي فصل المؤسسات — ضع تلك المواقع في مؤسسة فرعية خاصة بها وامنح العضوية هناك. إنه نموذج منظم للوكالات والموزعين، حيث يريد كل عميل بالفعل حدوده الخاصة. إن تحديد نطاق الموارد لكل عضوية، وتثبيت عضوية واحدة بمواقع محددة داخل مؤسسة واحدة، هو تحسين مخطط له وليس شيئًا متاحًا الآن.
لا يتضمن دور Developer صلاحية حذف الموقع أو تعليقه — فهذه المفاتيح تخص دور Owner. يمنح هذا الدور صلاحيات عرض المواقع وإنشائها، وإعادة تشغيل الخدمات، وتفريغ ذاكرة التخزين المؤقت، وإدارة مفاتيح API، والتعامل مع التذاكر. كما أن أذونات النشر والـ push-to-live ليست جزءاً من صلاحيات Developer، وبالتالي يظل الترحيل إلى بيئة الإنتاج من اختصاص مالك الحساب. ادمجوا ذلك مع بيئة التجربة (staging) حتى يتم عمل البناء بعيداً عن الموقع المباشر في المقام الأول.
يعتمد ذلك كلياً على دور الموظف، فكل دور يمثل مجموعة محددة من مفاتيح الأذونات. على سبيل المثال، يمكن لوكيل الدعم عرض حسابكم ومواقعكم، والاطلاع على تذاكركم والرد عليها، وإعادة تشغيل موقع ومسح ذاكرة التخزين المؤقت الخاصة به — ولكنه لا يستطيع المساس بإعدادات الفوترة، أو عمليات رد الأموال، أو الخطط، أو الأسطول. كما يُعد تسجيل الدخول كعميل إذناً منفصلاً مخصصاً فقط لدور Super Admin، وعند حدوث ذلك تعرض لوحة التحكم شريط انتحال هوية ثابتاً. ويتم تسجيل كل إجراء ذي امتيازات في سجل التدقيق شاملاً الفاعل، والإجراء، والهدف، وعنوان IP، والطابع الزمني، ويمكنكم قراءة سجل مؤسستكم بأنفسكم.
قم بإزالة العضوية وسينتهي وصولهم إلى تلك المؤسسة — سيظلون محتفظين بهويتهم الخاصة، ولكن بدون أي دور وبالتالي بدون أي أذونات في حسابكم. يتم إبطال مفاتيح API بشكل فردي، لذا يمكن إيقاف مفتاح pipeline دون التأثير على أي شيء آخر. إذا كنتم تستخدمون تسجيل الدخول الموحد SAML، فإن إلغاء التوفير (deprovisioning) في مزود الهوية الخاص بكم يتولى إدارة تسجيل الدخول مركزياً. يتم إبطال بيانات الاعتماد على مستوى الموقع مثل مفاتيح SSH من لوحة التحكم، كما يتم تسجيل عملية الإزالة نفسها في سجل التدقيق.
لا — ولكن تجدر الدقة في توضيح السبب. تعود مفاتيح API إلى المؤسسة وليس إلى عضو فردي، وتحمل نطاقات دقيقة خاصة بها مرتبطة بكتالوج الأذونات نفسه. لذا، بدلاً من تسليم مفتاح لشخص ما، تقومون بإنشاء مفتاح للوظيفة التي يؤديها مع أضيق نطاق تتطلبه تلك الوظيفة، وإلغاء هذا المفتاح عند انتهاء الوظيفة. لا يتم تخزين سوى تجزئة (hash) المفتاح السري، ويسجل كل مفتاح آخر موعد تم استخدامه فيه، مما يسهل العثور على المفاتيح غير المستخدمة وإلغاء تفعيلها.
نعم. يقوم خادم MCP الخاص بنا بمصادقة الوكلاء باستخدام OAuth 2.1 ويحدد نطاقهم وفقًا لمؤسستكم ودور RBAC الخاص بكم، مع رموز قابلة للإلغاء لكل أداة، بحيث تمنحون إمكانية محددة بدلاً من الوصول الشامل. وتتطلب الإجراءات التدميرية تأكيدًا، كما تُطبق حدود الإنفاق، ويتم تسجيل كل إجراء في نفس سجل التدقيق الخاص بالنشاط البشري.
يعمل أمان مستوى الصفوف في Postgres على حصر الاستعلامات في الشجرة الفرعية لمؤسسة المتصل داخل قاعدة البيانات نفسها، مع اعتبار التصفية على مستوى التطبيق دفاعًا متعمقًا وليس الخط الوحيد. تُرجع طلبات السجلات الواقعة خارج النطاق نتيجة تفيد بعدم العثور عليها بدلاً من خطأ في الأذونات، مما لا يكشف أي شيء عما هو موجود. على جانب الخادم، يحافظ العزل لكل موقع عبر CageFS على قشرة وملفات كل مستأجر مقصورة على موقعه الخاص.
نعم. التجربة لمدة 14 يومًا بدون بطاقة — لا توجد تفاصيل دفع ولا أي التزام — وتشمل استضافة Footprint-Free لما يصل إلى خمسة مواقع. إنها كافية لدعوة زميل وتعيين دور والتأكد من أن الحدود تعمل بالطريقة التي تحتاج إليها قبل أن تلتزم.
ابدأوا بالفترة التجريبية لمدة 14 يومًا دون الحاجة لبطاقة، وادعوا أحد الأشخاص، وشاهدوا نموذج الأذونات وهو يؤدي مهمته — أدوار يمكنكم تسميتها، ونطاقات صلاحيات يمكنكم إلغاؤها، وسجل تدقيق يوضح بدقة من قام بماذا.
ابدأ مجانًا