تتطلب معظم تطبيقات الويب اليوم على الأقل بعض إستراتيجيات الأمان الأساسية. على سبيل المثال، المواقع التي تقدم محتوى محميًا بكلمة مرور، والمواقع التي تحتوي على واجهة إدارية فقط، والمدونات والمجلات الشخصية، ومواقع التجارة الإلكترونية، والشبكات الداخلية للشركات، وما إلى ذلك.
أسلوب التصميم الأكثر شيوعًا لبناء هذه الأنواع من تطبيقات الويب هو دمج سياسة الأمان في منطق أعمال تطبيق الويب، حيث يحدد التطبيق ما إذا كان المستخدم لديه إذن للوصول إلى بيانات معينة في قاعدة البيانات. في هذا السيناريو، يكون دور قاعدة البيانات هو ببساطة تخزين البيانات وتقديمها عند الطلب. بمعنى آخر، إذا طلب تطبيق ويب من قاعدة البيانات توفير معلومات محددة، فإن قاعدة البيانات تنفذ الأمر مباشرة دون التحقق من أذونات المستخدم.
ستتعلم في هذه المقالة كيفية الاستفادة من ميزات الأمان المضمنة في Oracle لفرض قواعد أمان التطبيق على مستوى قاعدة البيانات لتحسين الأمان العام لتطبيقك. وكميزة جانبية، فإن تأمين الوصول إلى البيانات مباشرة في قاعدة البيانات لا يؤدي إلى تحسين أمان التطبيق فحسب، بل يساعد أيضًا في تقليل التعقيد.
ماذا عنالحاجة إلى الأمان من جانب قاعدة البيانات
للتحكم في الوصول إلى البيانات من تطبيقات الويب؟ في معظم الحالات لا توجد مشكلة؛ وهذا حل جيد، خاصة إذا كانت البيانات المعنية ليست مهمة أو سرية للغاية. تُستخدم هذه الطريقة في العديد من الكتب والموارد عبر الإنترنت. في الواقع، أحد كتب PHP/MySQL المشهورة لا يشجع صراحةً على إنشاء أكثر من حساب مستخدم لقاعدة بيانات واحدة لكل تطبيق لأن "المستخدمين الإضافيين أو الأذونات المعقدة قد يحتاجون إلى المزيد من عمليات التحقق قبل متابعة المعلومات ويبطئون سرعة تنفيذ MySQL." هذا صحيح، ولكن هناك بعض الأشياء التي قد ترغب في أخذها في الاعتبار قبل التخلي عن فكرة دمج الأمان في منطق قاعدة البيانات الخاصة بك. دعونا ننظر إلى المثال التالي.
لنفترض أنك قمت بإنشاء نظام إدارة المحتوى (CMS). يتم استخدام قاعدة بيانات لتخزين المحتوى المنشور على الموقع. معظم البيانات عامة، مما يسمح لمستخدمي الويب المجهولين بقراءتها؛ ولا يُسمح إلا للمحررين بتغيير البيانات. استخدم حساب قاعدة بيانات واحدًا للوصول إلى السجلات في قاعدة البيانات وتعديلها، والتحكم في الأمان باستخدام كود PHP عن طريق الوصول المحمي بكلمة مرور إلى الصفحات المخصصة للمسؤول فقط.
إذا كان الجانب العام من تطبيق ويب يعاني من هجوم مثل حقن SQL في نموذج بحث عام (أي نموذج لم يتم ترميزه بشكل كافٍ)، فقد يتمكن الدخيل من تنفيذ عبارات SQL عشوائية على كائنات قاعدة البيانات التي الحساب العام لديه حق الوصول إلى. بالطبع، في هذه الحالة، تنفيذ عبارة SELECT لا يشكل مشكلة كبيرة لأن البيانات عامة. ولكن نظرًا لأن الحقوق العامة والإدارية تستخدم نفس حساب قاعدة البيانات، فيمكن للمتسلل أيضًا تنفيذ عبارات UPDATE وDELETE، أو حتى حذف الجداول من قاعدة البيانات.
كيف يمكننا منع حدوث ذلك؟ إن أبسط طريقة هي تقييد أذونات حساب قاعدة البيانات العامة بالكامل لتعديل البيانات. دعونا نلقي نظرة على كيفية حل Oracle لهذه المشكلة.
نظرة عامة أساسية على Oracle Security
توفر Oracle Database لمطوري الويب العديد من الطرق للتحكم في الوصول إلى البيانات، بدءًا من إدارة الوصول إلى كائنات قاعدة البيانات المحددة مثل الجداول وطرق العرض والإجراءات وحتى التحكم في الوصول إلى البيانات في الصفوف أو الأعمدة الفردية. من الواضح أن مناقشة كل ميزة أو خيار أمان متاح في Oracle هو خارج نطاق هذه المقالة. هنا، لن نخوض في الكثير من التفاصيل، ولكن فقط الجوانب الأساسية لأمن الوصول إلى بيانات أوراكل:
· المصادقة وحسابات المستخدمين · الأذونات ·
مصادقة الأدوار وحسابات المستخدمين. كما هو الحال مع قواعد البيانات الأخرى، يجب مصادقة كل مستخدم (حساب قاعدة بيانات) يطلب الوصول إلى Oracle. يمكن إجراء التحقق من الصحة عن طريق قاعدة بيانات أو نظام تشغيل أو خدمة شبكة. بالإضافة إلى المصادقة الأساسية (مصادقة كلمة المرور)، تدعم Oracle أيضًا آليات مصادقة قوية مثل Kerberos وCyberSafe وRADIUS وما إلى ذلك.
دور. دور Oracle هو مجموعة محددة من الأذونات. على الرغم من أنه يمكنك منح أذونات حساب المستخدم مباشرة، إلا أن استخدام الأدوار يمكن أن يبسط إدارة المستخدم إلى حد كبير، خاصة عندما تحتاج إلى إدارة عدد كبير من المستخدمين. من الفعال جدًا إنشاء أدوار صغيرة يمكن التحكم فيها ثم منح المستخدمين دورًا واحدًا أو أكثر بناءً على مستوى الأمان الخاص بهم. ناهيك عن مدى سهولة تعديل الأذونات - ما عليك سوى تعديل الدور الذي يرتبط به الدور، بدلاً من تعديل كل حساب مستخدم.
لتبسيط العمل الأولي لإنشاء مستخدمين جدد، تأتي Oracle بثلاثة أدوار محددة مسبقًا:
· دور CONNECT - يسمح هذا الدور للمستخدمين بالاتصال بقاعدة البيانات وتنفيذ العمليات الأساسية، مثل إنشاء الجداول الخاصة بهم. بشكل افتراضي، لا يمكن لهذا الدور الوصول إلى جداول المستخدمين الآخرين.
· دور المورد - يشبه دور المورد دور CONNECT، ولكنه يسمح للمستخدمين بالحصول على المزيد من أذونات النظام، مثل إنشاء المشغلات أو الإجراءات المخزنة.
· دور DBA — يسمح للمستخدم بالحصول على كافة امتيازات النظام.
التراخيص والأذونات المستخدمة
في هذا القسم، نناقش كيفية استخدام تراخيص Oracle وأذوناتها لتحسين أمان مثال CMS البسيط الذي تمت مناقشته في بداية هذه المقالة. من المفترض أن يتم تخزين المحتوى المقدم لمستخدمي التطبيق في جدول WEB_CONTENT.
أولاً، قم بإنشاء الجدول. ابدأ تشغيل Oracle Database Special Edition وقم بتسجيل الدخول كمسؤول النظام. قم بإصدار نموذج مستخدم الموارد البشرية إذا لم يتم إصداره بعد. اتبع الإرشادات الموجودة في دليل البدء المتضمن مع تثبيت الإصدار الخاص. لاحظ أنه بشكل افتراضي، يتم تعيين دور المورد لمستخدمي الموارد البشرية. هنا، امنح المستخدم دور DBA بحيث يمكن استخدام الحساب لإدارة جوانب قاعدة البيانات لتطبيق CMS. وبطبيعة الحال، لن يتم استخدام حساب مستخدم الموارد البشرية للوصول عبر الإنترنت، فقط لإدارة قاعدة البيانات.
يمكنك الآن إنشاء جدول جديد باستخدام Object Browser أو عن طريق تنفيذ نافذة أوامر SQL. إليك رمز إنشاء الجدول:
CREATE TABLE WEB_CONTENT (
page_id رقم المفتاح الأساسي،
page_content VARCHAR2(255)
);
نظرًا لأنه تم إنشاء الجدول باستخدام حساب مستخدم الموارد البشرية، فإن الجدول مملوك لحساب الموارد البشرية وهو موجود في مخطط الموارد البشرية، ولا يمكن للمستخدمين الآخرين الوصول إلى الجدول حتى يتم منحهم إذنًا صريحًا للوصول إلى الجدول. إذا كنت لا تصدق ذلك، يمكنك إنشاء مستخدم جديد ومحاولة استخدام هذا المستخدم للوصول إلى جدول WEB_CONTENT.
الآن، قم بإنشاء مستخدمين جديدين، CMS_USER وCMS_EDITOR. وأخيرًا، سيتم منح CMS_USER أذونات للقراءة فقط في جدول WEB_CONTENT، وسيتم استخدام هذا المستخدم كحساب قاعدة بيانات يقدم المحتوى كمستخدم ويب مجهول. سيكون لحساب CMS_EDITOR المزيد من الأذونات في الجدول وسيتم استخدامه كحساب محرر CMS (الحساب المطلوب لتغيير البيانات في الجدول والحفاظ عليها).
يمكن إنشاء مستخدمين جدد باستخدام واجهة XE الرسومية أو عن طريق تنفيذ الأمر التالي:
CREATE USER cms_user IDENTIFIED BY cms_user;
إنشاء مستخدم cms_editor تم تحديده بواسطة cms_editor؛
(للتبسيط، كلمة المرور هنا تتوافق مع اسم المستخدم.)
لكي يتمكن كلا الحسابين من تسجيل الدخول إلى قاعدة البيانات، نحتاج إلى منحهما دور CONNECT. للقيام بذلك، حدد خانة الاختيار CONNECT ضمن معلومات المستخدم في قسم الإدارة/مستخدمي قاعدة البيانات بالواجهة الرسومية XE، أو قم بتنفيذ الأمر التالي:
GRANT CONNECT to cms_user;
منح الاتصال بـ cms_editor
الآن، إذا حاولت تسجيل الدخول كمستخدم CMS_USER أو CMS_EDITOR وحاولت قراءة البيانات من جدول WEB_CONTENT (اختر * من hr.web_content;)، فسوف تواجه الخطأ التالي:
ORA-00942: جدول أو عرض. غير
موجود للوصول إلى البيانات أو مجرد رؤية الجدول، تحتاج إلى منح حسابات CMS_USER وCMS_EDITOR أذونات للقراءة فقط في جدول WEB_CONTENT:
GRANT SELECT على hr.web_content إلى cms_user؛
منح التحديد على hr.web_content إلى cms_editor؛
الكود أعلاه يمكّن هذين الحسابين من تنفيذ عبارات SELECT في جدول WEB_CONTENT. إذا حاولت تنفيذ عبارات أخرى، فسوف تواجه خطأ. على سبيل المثال، يؤدي إدراج صف:
INSERT INTO hr.web_content (page_id,page_content) VALUES (1,'hello World');
إلى ظهور رسالة الخطأ
ORA-01031: امتيازات غير كافية
للسماح لـ CMS_EDITOR بتغيير محتويات هذا الجدول. يجب منح الأذونات التالية:
منح الإدراج والتحديث والحذف على hr.web_content إلى cms_editor؛
من الآن فصاعدًا، يمكن لحساب CMS_EDITOR تنفيذ عبارات INSERT وUPDATE وDELETE في جدول WEB_CONTENT.
انظر كم هو سهل! يمكن ملاحظة أن إدارة الأذونات من خلال الأدوار هي طريقة أكثر فعالية. إذا كانت قاعدة بيانات Oracle المستخدمة ليست XE، فيمكنك تنفيذ العمليات التالية:
إنشاء دور:
CREATE ROLE Reader؛
إنشاء دور الكاتب؛
منح أذونات الدور:
منح التحديد على محتوى الويب للقارئ؛
منح الإدراج والتحديث والحذف على web_content للكاتب؛
منح دور المستخدم:
منح القارئ إلى cms_user؛
منح القارئ إلى cms_editor (يحتاجون إلى القراءة أيضًا)
منح الكاتب إلى cms_editor؛
لاحظ أنه إذا قمت بتغيير تعريف دور القارئ، فإن هذه التغييرات تؤثر على جميع حسابات المستخدمين مع هذا الدور. إذا تم منح الأذونات مباشرة للمستخدمين، فيجب تحديث كل حساب مستخدم على حدة.
بعد إكمال الخطوات المذكورة أعلاه، يمكنك تكوين تطبيق PHP الخاص بك لاستخدام حساب CMS_USER لجميع اتصالات قاعدة البيانات التي يطلبها مستخدمو الويب المجهولون وحساب CMS_EDITOR للاتصالات التي تبدأ بواسطة الصفحات الإدارية المحمية بكلمة مرور. الآن، حتى لو تم اختراق نموذج ويب عام، فسيكون التأثير على قاعدة البيانات ضئيلًا لأن حساب CMS_USER لديه أذونات للقراءة فقط فقط.
الاستنتاج
في هذه المقالة، قمنا فقط بتقديم بعض الميزات الأساسية لأمن الوصول إلى بيانات Oracle بشكل مختصر. بالإضافة إلى ذلك، تتمتع Oracle بالعديد من الميزات الأخرى التي تنقل أمان تطبيقات الويب الخاصة بك إلى المستوى التالي، بما في ذلك قاعدة البيانات الافتراضية الخاصة (VPD) وأمان العلامات.