التحكم في الوصول للمستخدمين والأدوار في SQL

إن الأمن مهم للغاية لمسؤولي قواعد البيانات الذين يسعون إلى حماية جيغابايتتهم من بيانات الأعمال الحيوية من أعين المتطفلين من الغرباء غير المصرح لهم والداخليين الذين يحاولون تجاوز سلطتهم. توفر كافة أنظمة إدارة قواعد البيانات العلائقية نوعًا من آليات الأمان الداخلية المصممة لتقليل هذه التهديدات. وهي تتراوح بين الحماية البسيطة لكلمة المرور التي يوفرها Microsoft Access إلى بنية المستخدم / الدور المعقدة المدعومة بقواعد بيانات علائقية متقدمة مثل Oracle و Microsoft SQL Server. تركز هذه المقالة على آليات الأمان الشائعة لكافة قواعد البيانات التي تطبق لغة الاستعلام الهيكلية (أو SQL ). معًا ، سنستعرض عملية تعزيز عناصر التحكم في الوصول إلى البيانات وضمان سلامة بياناتك.

المستخدمين

تدعم قواعد البيانات المستندة إلى الخادم جميعًا مفهوم المستخدم المماثل لمفهوم المستخدم في أنظمة تشغيل الكمبيوتر. إذا كنت معتادًا على التسلسل الهرمي للمستخدم / المجموعة الموجود في Microsoft Windows NT و Windows 2000 ، فستجد أن مجموعات المستخدم / الأدوار المدعومة بواسطة SQL Server و Oracle متشابهة للغاية.

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

تختلف طرق إنشاء حسابات المستخدمين من النظام الأساسي إلى النظام الأساسي وسيتعين عليك استشارة الوثائق الخاصة بنظام DBMS للإجراء المحدد. يجب على مستخدمي Microsoft SQL Server التحقيق في استخدام الإجراء sp_adduser تخزين. سيجد مشرفو قواعد بيانات Oracle الأمر CREATE USER مفيدًا. قد ترغب أيضًا في التحقق من أنظمة الاستيقان البديلة. على سبيل المثال ، يدعم Microsoft SQL Server استخدام Windows NT Integrated Security. تحت هذا النظام ، يتم تعريف المستخدمين إلى قاعدة البيانات بواسطة حسابات مستخدمي Windows NT الخاصة بهم غير مطلوبة لإدخال معرف مستخدم وكلمة مرور إضافية للوصول إلى قاعدة البيانات. هذا النهج شائع للغاية بين مديري قواعد البيانات لأنه ينقل عبء إدارة الحساب إلى موظفي إدارة الشبكة ويوفر سهولة تسجيل الدخول المفرد للمستخدم النهائي.

الأدوار

إذا كنت في بيئة بها عدد قليل من المستخدمين ، فستجد على الأرجح أن إنشاء حسابات المستخدمين وتعيين الأذونات مباشرة لهم يكفي لاحتياجاتك. ومع ذلك ، إذا كان لديك عدد كبير من المستخدمين ، فستفقدك على الأرجح عبء الحفاظ على الحسابات والأذونات المناسبة. ولتخفيف هذا العبء ، تدعم قواعد البيانات العلائقية مفهوم الأدوار. تعمل أدوار قاعدة البيانات بشكل مماثل لمجموعات Windows NT. يتم تعيين حسابات المستخدمين للدور (الأدوار) ثم يتم تعيين الأذونات إلى الدور ككل بدلاً من حسابات المستخدمين الفردية. على سبيل المثال ، يمكننا إنشاء دور DBA ثم إضافة حسابات المستخدمين الخاصة بالموظفين الإداريين إلى هذا الدور. وبمجرد قيامنا بذلك ، يمكننا تعيين إذن محدد لكل المسؤولين الحاليين (والمستقبليين) بمجرد تعيين إذن لهذا الدور. مرة أخرى ، تختلف إجراءات إنشاء الأدوار من النظام الأساسي إلى النظام الأساسي. يجب أن يتحقق مسؤولو MS SQL Server الإجراء sp_addrole تخزين بينما يجب استخدام DBAs Oracle بناء جملة CREATE ROLE.

منح الأذونات

الآن بعد أن أضفنا المستخدمين إلى قاعدة بياناتنا ، حان الوقت لبدء تعزيز الأمان من خلال إضافة الأذونات. ستكون خطوتنا الأولى منح أذونات قواعد البيانات المناسبة لمستخدمينا. سنقوم بإنجاز ذلك من خلال استخدام عبارة SQL GRANT.

وإليك صيغة الجملة:

منحة <الأذونات>
[ON

]
إلى <المستخدم / الدور>
[مع خيار المنحة]

الآن ، دعونا نلقي نظرة على هذا البيان سطر تلو. يسمح لنا السطر الأول ، GRANT <الأذونات> بتحديد أذونات الجدول المحددة التي نمنحها. يمكن أن تكون هذه الأذونات على مستوى الجدول (مثل SELECT و INSERT و UPDATE و DELETE) أو أذونات قاعدة البيانات (مثل CREATE TABLE و ALTER DATABASE و GRANT). يمكن منح أكثر من تصريح واحد في بيان GRANT واحد ، ولكن قد لا يتم دمج الأذونات على مستوى الجدول والأذونات على مستوى قاعدة البيانات في عبارة واحدة.

يتم استخدام السطر الثاني ، ON

، لتحديد الجدول المتأثر للأذونات على مستوى الجدول. يتم حذف هذا السطر إذا تم منحنا أذونات على مستوى قاعدة البيانات. يحدد السطر الثالث المستخدم أو الدور الذي يتم منحه الأذونات.

وأخيرًا ، السطر الرابع ، مع خيار المنحة ، اختياري. إذا تم تضمين هذا السطر في العبارة ، يُسمح أيضًا للمستخدم المتأثر بمنح هذه الأذونات نفسها للمستخدمين الآخرين. لاحظ أنه لا يمكن تحديد WITH GRANT OPTION عند تعيين الأذونات لدور.

أمثلة

دعونا ننظر في بعض الأمثلة. في السيناريو الأول ، قمنا مؤخرًا بتعيين مجموعة مؤلفة من 42 مشغلًا للدخول إلى البيانات والذين سيضيفون سجلات العملاء ويحافظون عليها. يجب أن يكونوا قادرين على الوصول إلى المعلومات في جدول العملاء ، وتعديل هذه المعلومات وإضافة سجلات جديدة إلى الجدول. يجب ألا يتمكنوا من حذف سجل من قاعدة البيانات بالكامل. أولاً ، يتعين علينا إنشاء حسابات مستخدمين لكل مشغل ثم إضافتها جميعًا إلى دور جديد ، DataEntry. بعد ذلك ، يجب أن نستخدم جملة SQL التالية لمنحهم الأذونات المناسبة:

GRANT SELECT ، INSERT ، UPDATE
على الزبائن
إلى DataEntry

وهذا كل ما في الأمر! الآن دعنا نفحص حالة نعين فيها أذونات على مستوى قاعدة البيانات. نريد السماح لأعضاء دور DBA بإضافة جداول جديدة إلى قاعدة البيانات الخاصة بنا. علاوة على ذلك ، نريدهم أن يكونوا قادرين على منح مستخدمين آخرين إذنًا بفعل الشيء نفسه. ها هي عبارة SQL:

GRANT CREATE TABLE
إلى ديسيبل
مع خيار المنحة

لاحظ أننا قمنا بتضمين خط WITH GRANT OPTION لضمان أن DBAs الخاصة بنا يمكنها تعيين هذا الإذن للمستخدمين الآخرين.

إزالة أذونات

بمجرد منحنا أذونات ، غالبًا ما يثبت ضرورة إلغائها في وقت لاحق. لحسن الحظ ، يزودنا SQL بالأمر REVOKE لإزالة الأذونات الممنوحة مسبقًا. وإليك بناء الجملة:

إعادة الاختيار [GRANT OPTION FOR] <الأذونات>
ON


من <المستخدم / الدور>

ستلاحظ أن بناء جملة هذا الأمر مشابه للأمر GRANT. والفرق الوحيد هو أن WITH GRANT OPTION محدد على سطر الأوامر REVOKE بدلاً من نهاية الأمر. على سبيل المثال ، دعنا نتخيل أننا نريد إلغاء تصريح ماري السابق الممنوح لإزالة السجلات من قاعدة بيانات العملاء. سنستخدم الأمر التالي:

إعادة حذف
على الزبائن
من مريم

وهذا كل ما في الأمر! توجد آلية إضافية مدعومة بواسطة Microsoft SQL Server تستحق الذكر - الأمر DENY. يمكن استخدام هذا الأمر لرفض إذن صريح لمستخدم قد يمتلكه من خلال عضوية دور حالي أو مستقبلي. وإليك بناء الجملة:

رفض <الأذونات>
ON


إلى <المستخدم / الدور

أمثلة

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

حذف حذف
على الزبائن
إلى ماري

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

إعادة حذف
على الزبائن
من مريم

ستلاحظ أن هذا الأمر هو بالضبط نفس الأمر المستخدم لإزالة إذن إيجابي. تذكر أن الأمرين DENY و GRANT يعملان بطريقة مشابهة * mdash ؛ كلاهما ينشئان أذونات (موجبة أو سلبية) في آلية التحكم في الوصول إلى قاعدة البيانات. يقوم الأمر REVOKE بإزالة كافة الأذونات الإيجابية والسلبية للمستخدم المحدد. بمجرد إصدار هذا الأمر ، ستتمكن Mary من حذف الصفوف من الجدول إذا كانت عضوًا في دور يمتلك هذا الإذن. بدلاً من ذلك ، يمكن إصدار أمر GRANT لتزويد إذن DELETE مباشرةً بحسابها.

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