حماية قواعد البيانات وراء كلمة السر

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

ومهما يكن، فإن حماية البيانات السرية والحسّاسة في أنظمة تكنولوجيا المعلومات (IT) سواء أكانت في معالجة المعاملات (OLTB)، أو في أنظمة تخزين البيانات، تمثل أهمية عظمي للأعمال التجارية، على سبيل المثال، هل يمكن أن تتخيل نظام مبيعات بدون تخزين أسماء الزبائن، عناوينهم، وأرقام بطاقات الائتمان في قاعدة البيانات؟، تمثل البيانات الشخصية فائدة إستراتيجية في أنظمة اليوم، لذا فإن الشركات يجب أن تتخذ إجراءات وقائية، وقوية وشاملة من أجل لحفاظ على السرية عبر تطبيق الحماية، من هذا المنظور، فإن قرارات منظمتك الإستراتيجية والتكتيكية يجب أن تستهدف النتيجة النهائية، بدلا من التركيز على مشاريع معينة أو حاجات الأعمال التجارية الفورية لتفادي التكلفة العالية لإعادة العمل أو حتى الخسارة النهائية لثقة العملاء.
العديد من الإجراءات المتطورة تطبق عادة في موضعها الصحيح لمنع الدخول الغير مصرح به إلى الشبكة ونظام التشغيل، وتدمج كإجراءات جاهزة مع أنظمة التطبيق أو يتم تصنيعها حسب الطلب، لكن أيضا في أغلب الأحيان فإن قاعدة البيانات، والتي تستقر بها البيانات في حقيقة الأمر، فإنه يتم حمايتها فقط من خلال استخدام آلية اسم المستخدم (Username) وكلمة السر (Password). قاعدة بيانات أوراكل (10g) لديها إحدى أكثر التطبيقات المتقدمة في هذه الآلية، لكن إذا تم اختراق كلمة السر، فإن هذه الحماية تذهب وتفقد، قاعدة بيانات أوراكل يمكن أن تزود درجة أكبر من الحماية من خلال استعمال قاعدة بيانات الأوراكل الافتراضية الخاصّة، حماية جداول أوراكل (Oracle Label Security)، وهكذا، لكن هذه الآليات ما تزال غير مستعملة بشكل كافي في تطبيقات الإنتاج.
في هذه المقالة التقنية، أنا سأصف (وأوضح ذلك عن طريق عينة) تطبيق آلية حماية بافتراض بأن واحدة أو أكثر من كلمات السر لقاعدة البيانات اخترقت، هذه النظرة تعرض طريقة بسيطة لدمج الميزات الأمنية لقاعدة بيانات الأوراكل (10 g) إصدار 1 (والبعض منها متوفر في أوراكل (9i)) لإنجاز بسهولة مستوى هام من الحماية حتى إذا كان الدخيل يؤسس اتصالا مع قاعدة البيانات، إن الغرض الرئيسي من ذلك هو حماية البيانات الحساسة من أي مستخدم غير مصرح له بالدخول، سواء أكان ذلك الشخص لص حاسب (هاكرز) من الخارج، أو حتى إذا مديرًا لقاعدة البيانات من داخل الشركة، إن الأمثلة المقدمة في هذا البحث مخصصة للبيئة التفاعلية (transactional)، ولكن نفس المبادئ تطبق في الاستخبارات التجارية، وفي أنظمة تخزين البيانات أيضًا.

أهداف حماية قاعدة البيانات:
إن قاعدة بيانات الأوراكل هي مكون رئيسي لتنفيذ الحماية الحقيقية، بشكل عام، أجهزة الخادم (servers) التي تدير محرك قاعدة بيانات الأوراكل تحتمي جيدًا وراء برامج الحماية (firewall)، لكن هذه الحقيقة لا تمنع إمكانية محاولات الدخول الغير مصرح به، ومن بين ذلك المحاولات الداخلية من قبل الموظفين. يزوّد محرّك قاعدة بيانات الأوراكل آليات حماية مكتفية ذاتيا، بالإضافة إلى الطريقة التقليدية (اسم المستخدم / كلمة السر) لحماية محتوى بياناتها حتى لو تم تجاوز بقية طرق الحماية، إن التدابير الأمنية التي سوف تذكر في الأجزاء القادمة تفترض وقوع اختراق إلى مستوى قاعدة البيانات، وتمثل كخط أخير للدفاع في قاعدة البيانات نفسها، وليس كبديل كلي للحماية الخارجية.
بدءً من المقدمة المنطقية، القائلة بأن: كل التدابير الأمنية الأخرى تم تجاوزها، والدخول الغير مصرح بها إلى قاعدة البيانات يمكن أن يبدأ، فإن الحل الذي يقدم في الأجزاء التالية يتضمن ميزات بناء دفاع قاعدة البيانات لضمان ما يأتي:
- جهاز الخادم لتطبيق أوراكل (Oracle Application Server) أن يكون عميلاً موثوقًا لقاعدة البيانات، يمكنه أن يقرأ، يدخل، ويجدد كل البيانات حسب الحاجة، جهاز الخادم لتطبيق أوراكل سيستعمل آليات الحماية الداخلية، وآلية الحماية المخصصة لحماية البيانات من المستخدمين الغير مصرح لهم في طبقة التقديم (presentation layer).
- الوصول الآمن لقاعدة البيانات يكون متوفرًا لعملية تحليل الخطأ (error-resolution process)، باستخدام (SQL*Plus) متضمنا القدرة على رؤية المعلومات الخاصة.
- لا يمكن لأية وسيلة دخول أخرى لقاعدة البيانات آخر استرجاع معلومات العميل الخاصة.
إعداد العينة:
هذا التمرين يتضمن نموذج بيانات تقليدي من نوع المبيعات، والتي البيانات المحمية فيه تخزن في قاعدة بيانات تدعى (CUSTOMER)،وبشكل خاص في العمود (CARD_NO). المثال سيجعل الجدول كأنه فارغًا بالكامل في حالة أية طلب غير مصرح به، لهذا فإن الأمر (SELECT * from CUSTOMER) لن يسترجع أية بيانات أو سجلات، إن الجدول يبدو وكأنه ليس لديه أية سجلات، لذلك فإنه من المحتمل سيكون أقل جاذبية للدخلاء (لربما هذا الجدول لم يستعمل؟) من ذلك الجدول الذي لديه سجلات ولكنه يخفيها أو يخفي أعمدة مثيرة منها.
على أية حال، مع تغيير ثانوي في أمر استدعاء (DBMS_RLS.ADD_POLICY)، فإن الناتج سيخفي (يعرضه كملغي (null)) أو مخفي (يعرض كـ****) قيم العمود المحمية (CARD_NO)، ولكن تعرض كل السجلات في قيم الأعمدة الأخرى، يمكنك أن تفعل تلك القابلية بتخصيص قيم (sec_relevant_cols) و (sec_relevant_cols_opt ) في أمر الاستدعاء (DBMS_RLS.ADD_POLICY)، إن (initial_setup.sql iscript) في ملفات دعم هذا المقال تنشئ الجدول الأساسي (CUSTOMER) لاستعماله كمثال في هذه العملية.
هذه هي أفضل ممارسة لتجنب مالك مخطط البيانات (schema) للدخول إلى البيانات، بالأحرى, فإن حسابًا آخر مثل (AppSvr) يجب أن يكون مشتركًا مع كل ارتباطات العميل ويتم التعامل معه بواسطة جاهز خادم تطبيق الأوراكل، إن مستخدم قاعدة البيانات (AppSvr) لا يمتلك أي شيء سوى نظام امتياز إنشاء جلسة (CREATE SESSION) ولكنه يتسلم صلاحيات: الاختيار (select)، والإضافة (insert)، والتحديث (update)، والحذف (delete) على كل الجداول التي تحتوي بيانات للتطبيق من مالك مخطط البيانات (schema)، مثل مالك قاعدة البيانات (SHIP2004).
إن النص البرمجي (enable_connection.sql) في ملفات دعم تنشئ مستخدمًا الذي يكون نموذجيًا يستخدم بواسطة جهاز خادم تطبيق الأوراكل كما وصف سابقًا:
تطبيق الحماية:
لتحقيق أهداف الحماية المنصوص عليها، فإن سياسة قاعدة البيانات تستعمل لإخفاء السجلات في جدول (CUSTOMER) ما لم يكن الاتصال "مصرح به" (يدخل بواسطة خادم تطبيق الأوراكل، وينفذ عبر عنوان بروتوكول إنترنت (IP) معروف، وهكذا). إن السياسة مطبقة تحت مدير حماية قاعدة بيانات المستخدم، مثل (Sec_Manager) لهذا فإنه يكون غير مرئي حتى من مخطط البيانات (SHIP2004) أو AppSvr.
تحديد المتغيرات التي سوف تستخدم، والقيم المخصصة التي سوف يتم التحقق منها بواسطة الحماية هي الأسئلة التي يطرحها التطبيق، إن عددًا كبيرًا جدا من تفاصيل المجموعات المحتملة والموقع الخاص سوف تنشئ كتلة جامدة أمام محاولة الدخول.
إنها لفكرة جيدة إنشاء مخطط بيانات منفصل، مثل (Sec_Manager)، بدون أية امتيازات – حتى مجرد الاتصال – تكون مثل حامل (placeholder) لكل التعاريف المستخدمة في تطبيق الحماية. إن كل الأشياء التي سوف تنشئ بواسطة حساب مدير قاعدة البيانات في (Sec_Manager) لن يكون لديها أية امتيازات، هذا اسم المستخدم لا يمكن أن يستخدم حتى للاتصال بقاعدة البيانات، لهذا فإن تعاريف الحماية ستكون محمية بشكل جيد جدا. (لا أحد يمكن أن يرى حتى تعاريف الأشياء المتعلقة بالحماية ).
على أية حال، أحد أهدافنا الأولية هنا هو تفعيل مستوى الدخول لـ(SQL*Plus) لعدد قليل من أعضاء فريق الصيانة والدعم بالمؤسسة، هذا الدخول الطارئ يتطلب "كلمة مرور سرية" التي تتذكر بسهولة من قبل الناس المصرح لهم، ولكنها طويلة جدا عن أن تصبح مكتوبة كملاحظة صلبة (مرئية لكل أحد)، التي لسوء الحظ تحفظ عدد قليل من كلمات السر، في هذا المثال نستخدم متغير النظام (CLIENT_IDENTIFIER)، لكنه يمكن أن يكون أي متغير آخر للنظام أو مجموعة متغيرات للنظام تختارها أنت.
النص البرمجي (create_setup.sql) (الموجود في ملفات الدعم) تظهر كيف تنشئ مخطط لتطبيق الحماية، المهمة المعلنة، وسياسة الحماية طبقًا لما تم شرحه سابقًا، إنه ينتج كذلك عددًا من نتائج البيانات، يستخدم صلاحيات مختلفة للاتصال بقاعدة البيانات لإظهار ما هي الارتباطات المختلفة التي ستظهر (أو لن تظهر) في جدول (CUSTOMER)، كما أنه يعرض استخدام مهمة (dbms_session.set_identifier) لأجل فتح الباب السري لدخول قاعدة البيانات عبر الاتصال بـ (SQL*Plus).
دخول (SQL*Plus) المباشر:
لأن جهاز خادم تطبيق الأوراكل له ميزات حماية داخلية قوية لتوثيق وتأكيد الطلبات، فإن دخول (SQL*Plus) المباشر يمثل نقطة دخول معتادة للدخلاء، تطبيق سياسة الحماية المذكورة سابقًا يحقق التالي:
- حتى إذا كانت كلمة السر (AppSvr) اخترقت وشخص ما يستعمل اتصال (AppSvr) للدخول الغير مصرح به خلال (SQL*Plus)، فإن بيانات جدول (CUSTOMER) لن تعرض، لأن عنوان برتوكول الإنترنت (IP) أو اسم الجلسة الخارجية لن تكون تلك التي تتوقع من قبل مسند الحماية، النظام لن يظهر بأن هناك حتى أية سجلات في الجدول المحمي.
- اتصال مالك المخطط لن يكون مستعمل من قبل التطبيقات على الإنترنت، لأنها ستكون مستعملة فقط لأغراض الصيانة، ولهذا سوف تعطى بنحو صارم إلى عدد قليل من الناس، علاوة على ذلك، هم يجب أن يضعوا واحد أو أكثر من إعدادات النظام أماكن بيئة أكثر (CLIENT_IDENTIFIER في هذه الحالة) بشكل ملائم لرؤية بيانات جدول (CUSTOMER)، حتى إذا اخترقت كلمة السر (على سبيل المثال، شخص ما يكتشف ملاحظة مكتوبة على المنضدة)، فإن الجدول المحمي سوف يبدو فارغًا لشخص الغير مصرح له بدخوله، طالما لم يتم كشف إعداد الباب الخلفي المخفي من واضع الحماية، وبالتالي لن يعرف بأن هناك حتى أية بيانات في الجدول، لهذا فإنه من غير المحتمل أن ينظر إليه الدخيل مرة أخرى.
-

نتائج البيانات جراء كافة أنواع النصوص البرمجية سوف تعرض ما سبق أن شرحناه في الأعلى.

تشفير البيانات والحزم (Packages):
تشفير بيانات (CARD_NO) يضمن طبقة أخرى من حماية البيانات للبيانات الحساسة، يمكنك أن تعمل التشفير مع شفرة ثابتة يعرف في عملية خارجية أو يخزن في عمود في قاعدة البيانات، هي ممارسة جيدة لفصل مكونات التشفير (الشفرة والمهمة) في خادمين منفصلين، لزيادة تعقيد النظام والجهد المتطلب من الدخلاء المحتملين لاسترجاع كافة المعلومات المطلوبة من أجل فك تشفير البيانات المحمية.
إذا تم تعريف الشفرة في التطبيق، فإن لص الكومبيوتر (الهاكرز) سوف يكسر ليس فقط جهاز خادم قاعدة البيانات ولكن أيضا جهاز خادم التطبيق للوصول إلى الشفرة من أجل فك تشفير البيانات، حتى إذا ما تمكن شخص ما من كسر حماية الدخول التي وصفت في الأجزاء السابقة، فإنه ما يزال يجب عليه أن يفك شفرة الحزمة (Package) (الترميز كما سيشرح في "ضمان حماية النظام" في الأجزاء التالية) لمعرفة مهمة التشفير المطبقة، يحتاج الدخيل أيضا إلى كسر كود التطبيق الموجود في أجهزة خادم التطبيق لمعرفة الشفرة المستخدمة. إذا لم يتم تخزين الشفرة في أي ملف نصيّ واضح، مثل ملف متغير أو مصدر الكود، ولكن فقط في نسخة مجمعة، فإن ذلك يزيد الصعوبة والمهارة المطلوبة لاسترجاع البيانات الخاصة الحقيقية خلال عملية الدخول الغير مصرح بها.
على أية حال، لكي يكون التطبيق مستقلاً، فإن المثال يعرض في ملفات الدعم استعمال عمود آخر في جدول البيانات كمفتاح لعملية التشفير، القيمة التي تخزن في عمود الشفرة يجب أن تكون ثابتة، لأنه إذا تغيرت القيمة، فإن بيانات (CARD_NO) لا يمكن أن يتم فك تشفيرها، في هذه الحالة، فإن العمود (CREATED_BY) اختير لأجل الشفرة، لأنه لا يجب أن يحدث بعد الإنشاء القياسي.
إن الحل الأكثر سهولة لتقليل العمل الإضافي المطلوب في عملية التشفير هو إنشاء حزمة (package) التي تخفي أمر الاستدعاء الأساسي لأدوات تشفير الأوراكل، إن المطورين سيجرون ببساطة مهمة استدعاء بدلا من استعمال العمود المحمي مباشرة، والذي سيكون أقل إزعاجًا ما يمكن مقابل المنافع الأمنية المكتسبة، يستعمل هذا المثال مهمة Encrypt وDecrypt من حزمة (DBMS_CRYPTO)، التي تعرض العديد من الاختيارات المشفّرة (راجع مستندات الأوراكل لمزيد من التفاصيل) إن مجموعة كبيرة من الخيارات، مع اختيار مفتاح التشفير، تضيف مزيدًا إلى التعقيد لكسر الحل المقدم، خاصة عندما يتم تغليف الكود الأصلي للحزمة المخصصة كما يوصف لاحقًا (إن النص البرمجي create_packages.sql يقدم عينة من إعداد مهام التشفير/ وفك التشفير التي وصفت هنا).
قاعدة بيانات أوراكل (10g) إصدار 2 توفر تشفير واضح للبيانات (Transparent Data Encryption) خارج الصندوق، يفعل القدرة على تشفير أي عمود منتظم في قاعدة البيانات (التواريخ، السلاسل الرمزية، الأعداد)، ويقوم بفك التشفير آليًا عندما يمر المستخدم عبر عمليات مراقبة السيطرة على الدخول الضرورية، محرك الأوراكل نفسه، بدون تحكم من مستعمل قاعدة البيانات، تتعامل مع مفاتيح التشفير، لهذا فإن دخول التطبيق أو لغة الاستعلام المركبة (SQL) إلى الجدول ليس من حقها أن تدير المفاتيح، إضافة إلى ذلك فإن مدير قاعدة البيانات يمكنه أن يدير الجدول ولكنه لا يرى قيم البيانات الفعلية، مما يحل جزءً من مخاوف عملية الإعداد التي شرحناها سابقًا.

معالجة البيانات المشفرة:
تستعمل تطبيقات خادم تطبيق الأوراكل المهمة (Sec_Manager.Secure_Package) من أجل تخزين البيانات الشخصية في صيغة مشفرة، مثل (Secure_Package.Secure_Data) لتخزين بيانات (CARD_NO)، طبقا لتعريف حزمة التشفير المخصصة الموصوفة في (create_packages.sql) في ملفات الدعم، فإن الدخول إلى عمود (CARD_NO) تستبدل بأمر استدعاء والتي متغيراته خزنت في العمود، واستعملت الشفرة لتشفير البيانات
على سبيل المثال، لإستعمال ' a 1 b 2 c 3 d 4 ' كمفتاح للتشفير، فإن أمر الإدخال (INSERT) النموذجي، الذي يكون كالتالي:
insert into CUSTOMER (NAME, CARD_NO) values ('Jane Doe', '1234123412341234');
يجب أن يتحول إليه:
insert into CUSTOMER (NAME, CARD_NO) values ('Jane Doe', Sec_Manager.Secure_Package.Secure_Data('1234123412341234','a1b2c3d4'));
بنفس الطريقة، تستعمل تطبيقات خادم تطبيق أوراكل المهام من (Sec_Manager.Secure_Package) لقراءة البيانات في صيغة "decrypted"، مثل (Secure_Package.Clear_Data) لبيانات (CARD_NO)، نفس مفتاح التشفير الذي يستعمل لإدخال القيم الآن يستعمل لاسترجاع المعلومات المحمية في صيغة واضحة، في هذه الحالة فإن أمر الاختيار (SELECT) النموذجي، والذي يكون كالتالي:
select NAME, CARD_NO from CUSTOMER;
يجب أن يتغير إلى:
select NAME, Sec_Manager.Secure_Package.Clear_Data(CARD_NO,'a1b2c3d4') from CUSTOMER;

تأمين النظام:
عندما يتم تنفيذ كافة التطويرات (على أمل أن يقوم بها شخص جدير بالثقة)، فإن كود الترقية يمكنه أن يشفر أيضا، حتى لو أن مدير قاعدة البيانات هو الذي يقوم بترقية النصوص البرمجية فإنه لا يستطيع رؤية بالضبط كيف يتم تطبيق إجراءات الحماية. أنت تطبق التشفير بواسطة أداة مرفقة مع أوراكل، وباستخدام أوامر تشغيل النظام مثل:
wrap iname=Secure_Package.sql oname=Secure_Package.sec
وعندما يتحقق ذلك، فإن (Secure_Package.sec ) يمكن أن ينفذ في (SQL*Plus) مثلها مثل أي نص برمجي آخر، وسيقوم محرك قاعدة بيانات أوراكل بترجمتها. نفس المفهوم يمكن أن ينفذ أيضًا لأي نص برمجي متعلق بحماية (SQL*Plus). هذه المعالجة لا تمنع الأشخاص المشاركين في ترقية الكود (مدراء قواعد البيانات، والمطورون، والدعم، وفريق الإدارة) من رؤية محتوى الحزمة فقط، ولكنه ينشر ذلك في صيغة مشفرة في قاعدة البيانات، لذلك فإن أية محاولة بعد ذلك لحل محتوى الحزمة فإن ذلك يكون صعبًا للغاية.
حتى إذا كان الدخيل معه صلاحيات حساب مدير قاعدة البيانات، وقام بمنح صلاحية CONNECT لحاملة أدوات الحماية (Sec_Manager) من أجل الإطلاع على محتويات الحماية وحزمة التشفير، فإنه لن يجد نصًا واضحًا مخزنًا في قاعدة البيانات لهذه الأشياء، لأن الأوراكل لا تزوّد أي أداة للكشف، فإن الدخيل يجب عليه أن يخترق خوارزميات تشفير الأوراكل حتى يكون قادرًا على رؤية محتويات الحزمة.
تدقيق الدخول إلى البيانات الحساسة على الرغم من الدخول:
حتى مع تطبيق كل هذه التدابير الأمنية، فإنه لا يزال من المهم معرفة إذا كان حدث أي دخول غير مصرح به على البيانات الحسّاسة، إن الطريق الأسهل لذلك هو استعمال وظيفة تدقيق قاعدة البيانات الداخلية لمراقبة عمليات الدخول (SELECT, INSERT, UPDATE, DELETE) على البيانات المحمية في مستوى الجدول، بغض النظر عن اتصال قاعدة البيانات الذي يتطلب معاملة، خلال:
insert, update, select في SHIP2004.CUSTOMER.
على أية حال، مع نظام أوراكل لمراجعة الحسابات Fine Grained Auditing (FGA)، يمكنك أن تنقي عملية مراقبة الدخول أكثر من ذلك لتقليل تكاليف المعالجة، وتقدم المعلومات المفيدة وذات المغزى، المثال الذي قدم في (enable_fga.sql) يستعمل حزمة (DBMS_FGA) لتفعيل سياسة مراجعة الحسابات الأساسية، إن آلية التدقيق الداخلية في قاعدة البيانات يمنع المستخدمين من تجاوز التدقيق، وهكذا يضمن دقتها وصحتها.
سجلات التدقيق يمكن أن تراجع في (DBA_FGA_AUDIT_TRAIL)، كما يمكن أن تشاهد كذلك في (DBA_COMMON_AUDIT_TRAIL)، ويمكن أن تتضمن حتى معلومات (SQLBIND ) و(Sqltext) لو أن السياسة تخصص audit_trail = DBMS_FGA.DB_EXTENDED .
إن المثال المقدم هنا يمكنه أن يحسّن بسهولة بواسطة الوظيفة المقدمة مع أوراكل لتضمين إنذارات بواسطة البريد الإلكتروني أو بواسطة جهاز، وتهيئة الأوضاع من أجل توليد سجلات التدقيق فقط للأحداث المعينة. للمعلومات الإضافية عن السياسات وتطبيق تدقيق قاعدة البيانات، راجع ملفات أوراكل (Oracle documentation).
الخاتمة:
بينما تزداد محاولات الاختراق تطورًا أكثر فأكثر، فإن مصممي النظام ومدرائه يجب أن يعرفوا طرق أفضل لحماية محتويات قاعدة بياناتهم، دمج الطرق المستخدمة والتقنيات العادية على نحو غير عادي يمكن أن يجعلا محاولات الدخيل للاختراق أكثر تعقيدًا وأشد صعوبة.
الطريقة التي وصفت هنا أثبتت فعاليتها، حتى عندما كشفت كلمات السر مخطط بيانات (AppSvr)، و(SHIP2004) عرضيًا، لهذا هو يمكن أن يستعمل كمكوّن في نظام أمنك لحماية أصول البيانات الإستراتيجية وتحسين ثقة الزبون في كشف البيانات الخاصة، في المدى البعيد، هذا يساهم في علاقة أفضل مع الزبون وتحسين فرص العمل.