كيف يتعامل iDBQuery مع الأمان على مستوى الصف والصلاحيات؟

يتحكّم iDBQuery في الوصول على عدة طبقات بدلًا من كشف كل شيء للجميع: - تقرّر المصادقة من يمكنه تسجيل الدخول. - تقرّر الصلاحيات المبنية على الأدوار أي المشاريع ومصادر البيانات يمكن لكل مستخدم أو فريق رؤيتها، فلا يصل الأشخاص إلا إلى البيانات الممنوحة لهم. - تحكم بيانات اعتماد الاتصال ما يمكن لـ iDBQuery نفسه قراءته؛ فهو يستعلم بحسابات قاعدة البيانات التي تهيّئها، فيرث صلاحيات القراءة التي تفرضها تلك الحسابات أصلًا ويحترمها.

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

غير أن التحكم الأكبر هو النشر. فلأن iDBQuery يمكن أن يعمل في سحابتك الخاصة الافتراضية (VPC) أو معزولًا تمامًا عن الشبكة، ويستعلم عن بياناتك في مكانها بدلًا من نسخها خارجًا، لا تضطر البيانات الحساسة إلى مغادرة بيئتك أصلًا؛ فأقوى صور التحكم في الوصول هي بيانات لا تتحرّك قط. والبيانات مُشفَّرة أثناء النقل وعند التخزين، ولا تُستخدَم بياناتك أبدًا لتدريب أي نموذج ذكاء اصطناعي. وللفرق التي تحتاج إلى قيود على مستوى الصف مفروضة أعلى المنبع، يحترم iDBQuery سياسات قاعدة البيانات على مستوى الصف لأنه يشغّل استعلام SQL حقيقيًا عبر بيانات اعتمادك المُتحكَّم فيها. والمبدأ الموجّه هو البنية أولًا: فأأمن حدّ هو الحدّ الذي تفرضه بنيتك التحتية أصلًا.