PostgreSQL RLS: فرض عزل البيانات على مستوى قاعدة البيانات

قارن بين التصفية على مستوى التطبيق وPostgreSQL Row-Level Security لمنع تصعيد الصلاحيات وتسرب البيانات في البيئات متعددة المستأجرين.

مخاطر التصفية على مستوى التطبيق

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

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

كيف يعمل Row-Level Security

يقيّد PostgreSQL Row-Level Security (RLS)، على أساس كل مستخدم، الصفوف التي يمكن إرجاعها بواسطة الاستعلامات أو تعديلها بأوامر البيانات. عند تفعيل RLS على جدول، يجب أن تسمح سياسة أمان الصفوف بجميع عمليات الوصول العادية. إذا لم توجد سياسة، تُطبَّق سياسة رفض افتراضية، مما يعني عدم ظهور أي صفوف أو إمكانية تعديلها.

تُعرَّف السياسات باستخدام تعبيرات منطقية (Boolean) تُقيَّم لكل صف قبل أي شروط من استعلام المستخدم. الصفوف التي لا يُرجع التعبير لها قيمة صحيحة (true) لا تتم معالجتها. يضمن ذلك أن قاعدة البيانات نفسها تفرض قيود الرؤية حتى لو أرسل التطبيق استعلامًا بدون عوامل تصفية مناسبة.

فعّل RLS باستخدام ALTER TABLE ... ENABLE ROW LEVEL SECURITY.
أنشئ السياسات باستخدام CREATE POLICY مع بنود USING وWITH CHECK.
تُدمج السياسات المسموحة (Permissive) باستخدام OR؛ والسياسات المقيدة (Restrictive) باستخدام AND.

تنفيذ السياسات للتعدد المستأجري

نمط شائع هو إنشاء سياسة تقيد الوصول إلى الصفوف التي يطابق فيها معرّف المستأجر سياق المستخدم الحالي. على سبيل المثال، يمكن إنشاء سياسة تسمح للمستخدمين بعرض سجلاتهم الخاصة فقط باستخدام تعبير مثل user_name = current_user. يعمل هذا بشكل مشابه لأنواع أوامر مختلفة، مما يضمن عدم قدرة المستخدمين على اختيار أو تحديث أو حذف صفوف تخص مستخدمين آخرين.

يمكن تحديد تعبيرات منفصلة لأوامر SELECT وأوامر التعديل. يسمح ذلك بتحكم دقيق، مثل السماح لجميع المستخدمين بعرض البيانات العامة مع تقييد التعديلات على سجلاتهم الخاصة. يضمن بند WITH CHECK أن الصفوف الجديدة المُدخلة أو المُحدثة تلتزم أيضًا بسياسة الأمان.

التدقيق والتحقق

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

المستخدمون الخارقون (Superusers) والأدوار التي تمتلك خاصية BYPASSRLS يتجاوزون RLS، لذا يجب إدارة هذه الأدوار بعناية. عادةً ما يتجاوز مالكو الجداول RLS ما لم يتم استخدام FORCE ROW LEVEL SECURITY. ضمان تعيين الأدوار الصحيحة للسياسات واتصال التطبيق بسياق المستخدم المناسب أمر حاسم لعزل البيانات الفعال.