SQL Server / المتوسط / الدرس 12
الهويات والصلاحيات وأقل امتياز
صمّم وصول التطبيق وفق حدود أمان SQL Server الصحيحة، وافصل المصادقة وتفويض القاعدة وأمان المعلمات والتشفير والتدقيق.
في هذه الصفحة
أهداف الدرس
- تمييز تسجيل الدخول والمستخدم والدور.
- منح صلاحيات محددة النطاق.
- شرح تكامل المعلمات والتفويض.
افصل هوية الخادم عن وصول القاعدة
يصادق تسجيل الدخول على مستوى المثيل في نموذج SQL Server التقليدي، بينما يمثل مستخدم القاعدة الوصول داخل قاعدة معينة. تجمع الأدوار الصلاحيات للمستخدمين. توفر القواعد المحتواة خيارات هوية إضافية، فشخّص الإعداد الفعلي بدلاً من افتراض نمط ربط موحد. لا يثبت نجاح الاتصال امتلاك صلاحية قراءة جدول أعمال.
استخدم هويات خدمة منفصلة للتطبيقات والبيئات المختلفة. لا تجعل البشر يشتركون في بيانات اعتماد التطبيق للسهولة. فضّل آلية المصادقة المدارة المعتمدة بالمؤسسة حيث تتاح، واحفظ الأسرار في مخزن مناسب. لا تحتاج الدورة إلى بيانات اعتماد حقيقية؛ يمكن تحليل التصميم بأسماء هويات مصطنعة ونصوص مراجعة.
امنح أصغر قدرة مفيدة
لا يحتاج تطبيق ينفذ إجراء طلبات فقط إلى db_owner. امنح دور قاعدة EXECUTE على الكائن المطلوب ثم أضف مستخدم الخدمة إلى الدور بعملية نشر مخولة. يفترض المثال التصوري وجود الإجراء والمستخدم في قاعدة تدريب، ولا يتضمن كلمة مرور أو أمراً لإنشاء تسجيل دخول.
قد تبسط صلاحيات المخطط واجهة وحدات محدودة مقصودة، لكن الكائنات المستقبلية فيه توسع التعرض. منح الكائن أضيق لكنه يحتاج صيانة أكبر. اختر الحد وفق مسؤوليات التطبيق. راجع الصلاحيات الفعلية وسلاسل الملكية وSQL الديناميكي مستقلاً؛ فلا تمتد ضمانات وحدة ثابتة تلقائياً إلى كل عبارة ديناميكية.
-- Conceptual authorization migration for a training database.
CREATE ROLE OrderExecutor;
GRANT EXECUTE ON OBJECT::sales.PlaceOrder TO OrderExecutor;
ALTER ROLE OrderExecutor ADD MEMBER TrainingAppUser;يمكن للدور تنفيذ الوحدة، لكن وصول الجداول وسلوك SQL الديناميكي يحتاجان مراجعة؛ النص غير منفذ.
افحص السياق الفعلي
يمكن لبيانات وصفية للقراءة فقط تحديد مستخدم القاعدة الحالي وفحص صلاحياته دون أسرار. تعيد HAS_PERMS_BY_NAME هل يمتلك السياق الحالي الصلاحية المسماة عند صحة مدخلات الكائن والصلاحية. وتخضع رؤية البيانات الوصفية للأمان؛ فقد يعني غياب صف كتالوج نقص الرؤية لا غياب الكائن.
اختبر هوية الخدمة الفعلية لا جلسة المسؤول وحدها. تثبت الفحوص الإيجابية المسموح، وتؤكد السلبية فشل الممنوع. ينبغي ألا يعدل دور التقارير الطلبات، وألا تمنح وحدة كتابة صلاحية تغيير الجداول اعتباطياً. اربط الاختبارات بقدرات التطبيق بدلاً من توسيع الأدوار حتى يختفي الخطأ.
SELECT ORIGINAL_LOGIN() AS original_login,USER_NAME() AS database_user;
SELECT HAS_PERMS_BY_NAME(N'sales.PlaceOrder',N'OBJECT',N'EXECUTE')
AS can_execute;تتبع الأسماء والنتيجة للجلسة؛ ولا تنشر أسماء هويات حقيقية في تقارير عامة.
ميّز ضوابط الأمان
تمنع المعلمات تحول القيم إلى بنية أمر SQL، لكنها لا تقرر أحقية المستخدم في الوصول إلى العميل 42. يجب تطبيق تفويض المستأجر والكائن مستقلاً مع ربط موثوق بين الهوية والمستأجر. لا يكفي ربط CustomerId إن أمكن لأي مستدع اختيار معرف مستأجر آخر.
يحمي تشفير النقل البيانات أثناء عبورها، ويحمي تشفير التخزين حداً مختلفاً، وتحتاج النسخ والسجلات ضوابطها. لا يغني أي منها عن التفويض أو ربط المعلمات. سجل في التدقيق الهوية والفعل والهدف والنتيجة المفيدة دون كلمات مرور أو سلاسل اتصال كاملة أو بيانات شخصية غير لازمة. تتبع المراجعة مسار البيانات كله لا كلمة SQL واحدة.
راجع الوصول طوال عمره
تتراكم الصلاحيات إن لم تتضح ملكيتها ومراجعتها. سجّل سبب كل منح وعملية النشر المالكة وكيفية إزالته عند إيقاف الميزة. افصل إدارة الطوارئ عن وصول الخدمة المعتاد وراجع المنح المؤقت بعد الحادثة. الحل الدائم بمنح sysadmin عيب أمني حتى لو أزال خطأً فورياً.
عند تشخيص فشل حدد هل وقع في المصادقة أو ربط القاعدة أو صلاحية الكائن أو سلوك الوحدة. احتفظ برقم الخطأ في سجل تشخيص مقيد. لا تطلب سراً من متعلم ولا تنسخ إعداد إنتاج إلى تدريب. يحدد الإصلاح المفيد القدرة الفاشلة بدقة ويتحقق من حد الوصول المطلوب.
الأخطاء الشائعة وإصلاحها
The SELECT permission was denied.
- لماذا يحدث؟
- يفتقر المستخدم إلى القدرة المطلوبة أو يوجد قيد فعلي.
- كيف تصلحه؟
- امنح الدور المعتمد قدرة الكائن المطلوبة فقط.
- كيف تتجنب تكراره؟
- اختبر بهوية الخدمة الفعلية.
Login succeeded but database access failed.
- لماذا يحدث؟
- خُلطت المصادقة بتفويض القاعدة.
- كيف تصلحه؟
- تحقق مع المسؤول من القاعدة وربط المستخدم وتوافرها.
- كيف تتجنب تكراره؟
- وثّق حدود الهوية لكل بيئة.
A bound identifier exposed another tenant.
- لماذا يحدث؟
- اعتمد التفويض على ملكية يختارها المستدعي.
- كيف تصلحه؟
- افرض نطاق مستأجر موثوقاً في كل عملية مناسبة.
- كيف تتجنب تكراره؟
- اختبر رفض الوصول بين المستأجرين.
اختبر فهمك
1. تحتاج خدمة تقارير عرضاً واحداً. هل تمنح db_owner؟
اعرض الحل المشروح
لا؛ امنح SELECT على العرض المعتمد عبر دور مخصص وراجع صلاحياته التابعة وتحقق من رفض الكتابة المباشرة وتغيير المخطط.
2. هل يثبت ربط @TenantId تفويض المستأجر؟
اعرض الحل المشروح
لا؛ يبقي الربط القيمة بيانات. يجب اشتقاق عضوية المستأجر أو التحقق منها بهوية موثوقة، وفرض النطاق باتساق في العملية.
أهم ما تعلمته
- المصادقة والتفويض ومنع الحقن ضوابط منفصلة.
- يجب أن تمثل الأدوار قدرات محدودة.
- تحقق من العمليات المسموحة والممنوعة.