اسمي دينيس روجكوف، أنا رئيس تطوير البرمجيات في شركة Gazinformservice، في فريق المنتج جاتوبا. تفرض التشريعات ولوائح الشركات متطلبات معينة لأمن تخزين البيانات. لا أحد يريد أن تتمكن أطراف ثالثة من الوصول إلى المعلومات السرية، لذا فإن القضايا التالية مهمة لأي مشروع: تحديد الهوية والمصادقة، وإدارة الوصول إلى البيانات، وضمان سلامة المعلومات في النظام، وتسجيل الأحداث الأمنية. لذلك، أريد أن أتحدث عن بعض النقاط المثيرة للاهتمام فيما يتعلق بأمان نظام إدارة قواعد البيانات (DBMS).

تم إعداد المقال بناءً على خطاب ألقاه في @DatabaseMeetup، منظم حلول سحابة Mail.ru. إذا كنت لا تريد القراءة يمكنك مشاهدة:

ستتكون المقالة من ثلاثة أجزاء:

• كيفية تأمين الاتصالات.
• ما هو تدقيق الإجراءات وكيفية تسجيل ما يحدث في قاعدة البيانات والاتصال بها.
• كيفية حماية البيانات في قاعدة البيانات نفسها وما هي التقنيات المتاحة لذلك.

ثلاثة مكونات لأمن نظام إدارة قواعد البيانات: حماية الاتصال، وتدقيق النشاط، وحماية البيانات

تأمين اتصالاتك

يمكنك الاتصال بقاعدة البيانات إما بشكل مباشر أو غير مباشر من خلال تطبيقات الويب. كقاعدة عامة، يتفاعل مستخدم الأعمال، أي الشخص الذي يعمل مع نظام إدارة قواعد البيانات (DBMS)، معه بشكل غير مباشر.

قبل الحديث عن حماية الاتصالات، عليك الإجابة على الأسئلة المهمة التي تحدد كيفية تنظيم الإجراءات الأمنية:

• هل يعادل مستخدم أعمال واحد مستخدمًا واحدًا لنظام إدارة قواعد البيانات (DBMS)؟
• ما إذا كان الوصول إلى بيانات نظام إدارة قواعد البيانات يتم توفيره فقط من خلال واجهة برمجة التطبيقات (API) التي تتحكم فيها، أو ما إذا كان يتم الوصول إلى الجداول مباشرة؛
• ما إذا كان نظام إدارة قواعد البيانات مخصصًا لقطاع محمي منفصل ومن يتفاعل معه وكيف؛
• ما إذا كان سيتم استخدام طبقات التجميع/الوكيل والطبقات المتوسطة، والتي يمكن أن تغير المعلومات حول كيفية إنشاء الاتصال ومن يستخدم قاعدة البيانات.

الآن دعونا نرى ما هي الأدوات التي يمكن استخدامها لتأمين الاتصالات:

1. استخدم حلول فئة جدار الحماية لقاعدة البيانات. ستعمل طبقة الحماية الإضافية، على الأقل، على زيادة شفافية ما يحدث في نظام إدارة قواعد البيانات (DBMS)، وعلى الحد الأقصى، ستتمكن من توفير حماية إضافية للبيانات.
2. استخدم سياسات كلمة المرور. يعتمد استخدامها على كيفية بناء الهندسة المعمارية الخاصة بك. على أية حال، كلمة مرور واحدة في ملف التكوين الخاص بتطبيق الويب الذي يتصل بنظام إدارة قواعد البيانات ليست كافية للحماية. هناك عدد من أدوات نظام إدارة قواعد البيانات (DBMS) التي تسمح لك بالتحكم في حاجة المستخدم وكلمة المرور إلى التحديث.

   يمكنك قراءة المزيد عن وظائف تصنيف المستخدم هنا، يمكنك أيضًا التعرف على مقيِّمي الثغرات الأمنية في MS SQL هنا. 

3. إثراء سياق الجلسة بالمعلومات اللازمة. إذا كانت الجلسة مبهمة، فأنت لا تفهم من يعمل في نظام إدارة قواعد البيانات ضمن إطارها، فيمكنك، في إطار العملية التي يتم تنفيذها، إضافة معلومات حول من يفعل ماذا ولماذا. ويمكن رؤية هذه المعلومات في التدقيق.
4. قم بتكوين SSL إذا لم يكن لديك شبكة منفصلة بين نظام إدارة قواعد البيانات (DBMS) والمستخدمين النهائيين؛ فهي ليست في شبكة محلية ظاهرية (VLAN) منفصلة. في مثل هذه الحالات، من الضروري حماية القناة بين المستهلك ونظام إدارة قواعد البيانات (DBMS) نفسه. أدوات الأمان متاحة أيضًا في المصادر المفتوحة.

كيف سيؤثر ذلك على أداء نظام إدارة قواعد البيانات (DBMS)؟

دعونا نلقي نظرة على مثال PostgreSQL لنرى كيف يؤثر SSL على تحميل وحدة المعالجة المركزية، ويزيد التوقيت ويقلل TPS، وما إذا كان سيستهلك الكثير من الموارد إذا قمت بتمكينه.

يعد تحميل PostgreSQL باستخدام pgbench برنامجًا بسيطًا لتشغيل اختبارات الأداء. فهو ينفذ تسلسلًا واحدًا من الأوامر بشكل متكرر، ربما في جلسات قاعدة بيانات متوازية، ثم يحسب متوسط ​​معدل المعاملة.

الاختبار 1 بدون SSL واستخدام SSL - يتم إنشاء الاتصال لكل معاملة:

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require 
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

الاختبار 2 بدون SSL واستخدام SSL - يتم تنفيذ كافة المعاملات في اتصال واحد:

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

اعدادات اخرى:

scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000

نتائج الإختبار:

 
لا طبقة المقابس الآمنة
SSL

يتم إنشاء اتصال لكل معاملة

متوسط ​​الكمون
مللي 171.915
مللي 187.695

tps بما في ذلك إنشاء الاتصالات
58.168112
53.278062

tps باستثناء إنشاء الاتصالات
64.084546
58.725846

وحدة المعالجة المركزية‏:
24%
28%

يتم تنفيذ جميع المعاملات في اتصال واحد

متوسط ​​الكمون
مللي 6.722
مللي 6.342

tps بما في ذلك إنشاء الاتصالات
1587.657278
1576.792883

tps باستثناء إنشاء الاتصالات
1588.380574
1577.694766

وحدة المعالجة المركزية‏:
17%
21%

عند الأحمال الخفيفة، يكون تأثير SSL مشابهًا لخطأ القياس. إذا كانت كمية البيانات المنقولة كبيرة جدًا، فقد يكون الوضع مختلفًا. إذا قمنا بإنشاء اتصال واحد لكل معاملة (وهذا أمر نادر، وعادةً ما يتم مشاركة الاتصال بين المستخدمين)، وكان لديك عدد كبير من الاتصالات/قطع الاتصال، فقد يكون التأثير أكبر قليلاً. وهذا يعني أنه قد تكون هناك مخاطر لانخفاض الأداء، ولكن الفرق ليس كبيرًا لدرجة عدم استخدام الحماية.

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

كانت لدينا حالة عندما قمنا بتوصيل Zabbix في وضع الثقة، أي أنه لم يتم التحقق من MD5، ولم تكن هناك حاجة للمصادقة. ثم طلب العميل تمكين وضع مصادقة md5. أدى هذا إلى وضع حمل ثقيل على وحدة المعالجة المركزية، وانخفض الأداء. بدأنا في البحث عن طرق للتحسين. أحد الحلول الممكنة للمشكلة هو تنفيذ قيود الشبكة، وإنشاء شبكات VLAN منفصلة لنظام إدارة قواعد البيانات، وإضافة إعدادات لتوضيح من يتصل من أين وإزالة المصادقة. يمكنك أيضًا تحسين إعدادات المصادقة لتقليل التكاليف عند تمكين المصادقة، ولكن بشكل عام، يؤثر استخدام طرق المصادقة المختلفة على الأداء ويتطلب أخذ هذه العوامل في الاعتبار عند تصميم قوة الحوسبة للخوادم (الأجهزة) لنظام إدارة قواعد البيانات (DBMS).

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

تدقيق العمل

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

في أنظمة إدارة قواعد البيانات على مستوى المؤسسات التجارية، كل شيء على ما يرام فيما يتعلق بالتدقيق، ولكن في المصادر المفتوحة - ليس دائمًا. إليك ما يحتويه PostgreSQL:

• السجل الافتراضي - التسجيل المدمج؛
• الإضافات: pgaudit - إذا لم يكن التسجيل الافتراضي كافيًا بالنسبة لك، فيمكنك استخدام إعدادات منفصلة تحل بعض المشكلات.

اضافة للتقرير في الفيديو:

"يمكن توفير تسجيل البيان الأساسي من خلال أداة تسجيل قياسية باستخدام log_statement = all.

يعد هذا أمرًا مقبولًا للمراقبة والاستخدامات الأخرى، ولكنه لا يوفر مستوى التفاصيل المطلوب عادةً للتدقيق.

لا يكفي أن يكون لديك قائمة بجميع العمليات التي يتم إجراؤها على قاعدة البيانات.

ويجب أن يكون من الممكن أيضًا العثور على بيانات محددة تهم المدقق.

يعرض التسجيل القياسي ما طلبه المستخدم، بينما يركز pgAudit على تفاصيل ما حدث عندما نفذت قاعدة البيانات الاستعلام.

على سبيل المثال، قد يرغب المراجع في التحقق من إنشاء جدول معين ضمن نافذة صيانة موثقة.

قد تبدو هذه مهمة بسيطة مع التدقيق الأساسي و grep، ولكن ماذا لو تم تقديم شيء مثل هذا المثال (المربك عمدًا):

افعل $$
ابدأ
تنفيذ 'استيراد جدول إنشاء' || "ant_table(المعرف int)";
نهاية $$؛

سيعطيك التسجيل القياسي ما يلي:

السجل: البيان: افعل $$
ابدأ
تنفيذ 'استيراد جدول إنشاء' || "ant_table(المعرف int)";
نهاية $$؛

يبدو أن العثور على جدول الاهتمام قد يتطلب بعض المعرفة البرمجية في الحالات التي يتم فيها إنشاء الجداول ديناميكيًا.

وهذا ليس مثاليًا، حيث أنه من الأفضل البحث ببساطة حسب اسم الجدول.

هذا هو المكان الذي يكون فيه pgAudit مفيدًا.

لنفس الإدخال، فإنه سيتم إنتاج هذا الإخراج في السجل:

التدقيق: الجلسة، 33,1،XNUMX، الوظيفة، القيام،،، "افعل $$".
ابدأ
تنفيذ 'استيراد جدول إنشاء' || "ant_table(المعرف int)";
النهاية$$;"
التدقيق: الجلسة، 33,2،XNUMX، DDL، إنشاء جدول، TABLE، public.important_table، إنشاء جدول important_table (معرف INT)

لا يتم تسجيل كتلة DO فحسب، بل يتم أيضًا تسجيل النص الكامل لـ CREATE TABLE مع نوع العبارة ونوع الكائن والاسم الكامل، مما يجعل البحث أسهل.

عند تسجيل بيانات SELECT وDML، يمكن تكوين pgAudit لتسجيل إدخال منفصل لكل علاقة مشار إليها في البيان.

ليس هناك حاجة إلى تحليل للعثور على جميع البيانات التي تمس جدولًا معينًا (*) ".

كيف سيؤثر ذلك على أداء نظام إدارة قواعد البيانات (DBMS)؟

لنجري اختبارات مع تمكين التدقيق الكامل ونرى ما يحدث لأداء PostgreSQL. دعونا نمكن الحد الأقصى من تسجيل قاعدة البيانات لجميع المعلمات.

لا نغير أي شيء تقريبًا في ملف التكوين، والشيء الأكثر أهمية هو تشغيل وضع debug5 للحصول على أقصى قدر من المعلومات.

postgresql.conf

log_destination = 'stderr'
logging_collector = on
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 10 ميجابايت
log_min_messages = التصحيح 5
log_min_error_statement = التصحيح 5
log_min_duration_statement = 0
debug_print_parse = on
debug_print_rewriter = on
debug_print_plan = قيد التشغيل
debug_pretty_print = قيد التشغيل
log_checkpoints = تشغيل
log_connections = تشغيل
log_disconnections = تشغيل
log_duration = on
log_hostname = on
log_lock_waits = تشغيل
log_replication_commands = on
ملفات_سجل_المؤقت = 0
log_timezone = 'أوروبا/موسكو'

في نظام PostgreSQL DBMS بمعلمات وحدة المعالجة المركزية (CPU) واحدة، وسرعة 1 جيجا هرتز، وذاكرة الوصول العشوائي (RAM) سعة 2,8 جيجابايت، ومحرك الأقراص الثابتة (HDD) سعة 2 جيجابايت، نجري ثلاثة اختبارات تحميل باستخدام الأوامر:

$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark

نتائج الإختبار:

لا يوجد تسجيل
مع التسجيل

إجمالي وقت ملء قاعدة البيانات
43,74 ثانية
53,23 ثانية

سرقة
24%
40%

وحدة المعالجة المركزية‏:
72%
91%

الاختبار 1 (50 اتصالاً)

عدد المعاملات في 10 دقائق
74169
32445

المعاملات/ثانية
123
54

متوسط ​​وقت الاستجابة
شنومك مس
شنومك مس

الاختبار 2 (150 اتصالاً مع 100 اتصال محتمل)

عدد المعاملات في 10 دقائق
81727
31429

المعاملات/ثانية
136
52

متوسط ​​وقت الاستجابة
شنومك مس
شنومك مس

حول الأحجام

حجم قاعدة البيانات
2251 ميغابايت
2262 ميغابايت

حجم سجل قاعدة البيانات
شنومك مب
شنومك مب

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

دعونا نلقي نظرة على المعلمات الأخرى:

• لا تتغير السرعة كثيرًا: بدون التسجيل - 43,74 ثانية، مع التسجيل - 53,23 ثانية.
• سوف يتأثر أداء ذاكرة الوصول العشوائي (RAM) ووحدة المعالجة المركزية (CPU)، حيث تحتاج إلى إنشاء ملف تدقيق. وهذا ملحوظ أيضًا في الإنتاجية.

مع زيادة عدد الاتصالات، بطبيعة الحال، سوف يتدهور الأداء قليلا.

في الشركات التي تقوم بمراجعة الحسابات يكون الأمر أكثر صعوبة:

• هناك الكثير من البيانات.
• هناك حاجة إلى التدقيق ليس فقط من خلال سجل النظام في SIEM، ولكن أيضًا في الملفات: إذا حدث شيء ما لسجل النظام، فيجب أن يكون هناك ملف قريب من قاعدة البيانات يتم حفظ البيانات فيه؛
• يلزم وجود رف منفصل للتدقيق حتى لا تضيع أقراص الإدخال/الإخراج، لأنها تشغل مساحة كبيرة؛
• يحدث أن موظفي أمن المعلومات يحتاجون إلى معايير GOST في كل مكان، فهم يحتاجون إلى تحديد هوية الدولة.

تقييد الوصول إلى البيانات

دعونا نلقي نظرة على التقنيات المستخدمة لحماية البيانات والوصول إليها في أنظمة إدارة قواعد البيانات التجارية ومفتوحة المصدر.

ما الذي يمكنك استخدامه بشكل عام:

1. التشفير والتعتيم على الإجراءات والوظائف (التغليف) - أي الأدوات والمرافق المنفصلة التي تجعل التعليمات البرمجية المقروءة غير قابلة للقراءة. صحيح أنه لا يمكن تغييره أو إعادة هيكلته مرة أخرى. يكون هذا النهج مطلوبًا في بعض الأحيان على الأقل من جانب نظام إدارة قواعد البيانات - حيث يتم تشفير منطق قيود الترخيص أو منطق التفويض بدقة على مستوى الإجراء والوظيفة.
2. يتم تقييد رؤية البيانات حسب الصفوف (RLS) عندما يرى مستخدمون مختلفون جدولًا واحدًا، ولكن تركيبة مختلفة من الصفوف فيه، أي أنه لا يمكن إظهار شيء لشخص ما على مستوى الصف.
3. يتم تحرير البيانات المعروضة (الإخفاء) عندما يرى المستخدمون في عمود واحد من الجدول إما البيانات أو العلامات النجمية فقط، أي أنه سيتم إغلاق المعلومات بالنسبة لبعض المستخدمين. تحدد التكنولوجيا المستخدم الذي سيتم عرضه بناءً على مستوى وصوله.
4. التحكم في الوصول إلى DBA/Application DBA/DBA يتعلق بالأحرى بتقييد الوصول إلى نظام إدارة قواعد البيانات (DBMS) نفسه، أي أنه يمكن فصل موظفي أمن المعلومات عن مسؤولي قواعد البيانات ومسؤولي التطبيقات. هناك عدد قليل من هذه التقنيات في المصادر المفتوحة، ولكن يوجد الكثير منها في أنظمة إدارة قواعد البيانات التجارية. تكون هناك حاجة إليها عندما يكون هناك العديد من المستخدمين الذين لديهم إمكانية الوصول إلى الخوادم بأنفسهم.
5. تقييد الوصول إلى الملفات على مستوى نظام الملفات. يمكنك منح الحقوق وامتيازات الوصول إلى الدلائل بحيث يتمكن كل مسؤول من الوصول إلى البيانات الضرورية فقط.
6. الوصول الإلزامي ومسح الذاكرة - نادرًا ما يتم استخدام هذه التقنيات.
7. التشفير الشامل مباشرة من نظام إدارة قواعد البيانات (DBMS) هو تشفير من جانب العميل مع إدارة المفاتيح من جانب الخادم.
8. تشفير البيانات. على سبيل المثال، يتم التشفير العمودي عند استخدام آلية تقوم بتشفير عمود واحد من قاعدة البيانات.

كيف يؤثر هذا على أداء نظام إدارة قواعد البيانات (DBMS)؟

دعونا نلقي نظرة على مثال التشفير العمودي في PostgreSQL. هناك وحدة pgcrypto، وهي تسمح لك بتخزين الحقول المحددة في شكل مشفر. يكون هذا مفيدًا عندما تكون بعض البيانات فقط ذات قيمة. لقراءة الحقول المشفرة، يرسل العميل مفتاح فك التشفير، ويقوم الخادم بفك تشفير البيانات وإعادتها إلى العميل. بدون المفتاح، لا يمكن لأحد أن يفعل أي شيء ببياناتك.

دعونا نختبر باستخدام pgcrypto. لنقم بإنشاء جدول يحتوي على بيانات مشفرة وبيانات عادية. فيما يلي أوامر إنشاء الجداول، يوجد في السطر الأول أمر مفيد - إنشاء الامتداد نفسه من خلال تسجيل DBMS:

CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));

بعد ذلك، دعونا نحاول عمل عينة بيانات من كل جدول وإلقاء نظرة على توقيت التنفيذ.

الاختيار من جدول بدون وظيفة التشفير:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

ساعة الإيقاف قيد التشغيل.

  معرف | النص 1 | text2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 سطراً)

الوقت: 1,386 مللي ثانية

الاختيار من جدول مع وظيفة التشفير:

psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt

ساعة الإيقاف قيد التشغيل.

  معرف | فك تشفير | فك التشفير
——+—————+————
1 | ×31 | x31
2 | ×32 | x32
3 | ×33 | x33
...
999 | ×393939 | x393939
1000 | ×31303030 | x31303030
(1000 سطراً)

الوقت: 50,203 مللي ثانية

نتائج الإختبار:

 
بدون تشفير
بي جي كريبتو (فك التشفير)

عينة 1000 صف
شنومك مس
شنومك مس

وحدة المعالجة المركزية‏:
15%
35%

سرقة
 
+ 5٪

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

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

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

مثال على هذا التشفير في MongoDB

ميزات الأمان في نظم إدارة قواعد البيانات التجارية والمفتوحة المصدر

وظائف
نوع
سياسة كلمة المرور
خدمات التدقيق
حماية الكود المصدري للإجراءات والوظائف
RLS
التشفير

Oracle
تجاري
+
+
+
+
+

MsSql
تجاري
+
+
+
+
+

جاتوبا
تجاري
+
+
+
+
اضافات المتصفح

كيو
مجانًا
اضافات المتصفح
اضافات المتصفح
-
+
اضافات المتصفح

مونجودب
مجانًا
-
+
-
-
متوفر في MongoDB Enterprise فقط

الجدول بعيد عن الاكتمال، ولكن الوضع هو كما يلي: في المنتجات التجارية، تم حل المشكلات الأمنية لفترة طويلة، في المصدر المفتوح، كقاعدة عامة، يتم استخدام بعض الوظائف الإضافية للأمان، والعديد من الوظائف مفقودة ، في بعض الأحيان عليك إضافة شيء ما. على سبيل المثال، سياسات كلمة المرور - يحتوي PostgreSQL على العديد من الامتدادات المختلفة (1, 2, 3, 4, 5)، التي تنفذ سياسات كلمة المرور، ولكن في رأيي، لا يغطي أي منها جميع احتياجات قطاع الشركات المحلية.

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

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

الخيار الثاني هو كتابة ما تحتاجه بنفسك، وتنفيذ الوصول إلى البيانات والتشفير في التطبيق على مستوى الإجراء. صحيح أن الأمر سيكون أكثر صعوبة مع GOST. ولكن بشكل عام، يمكنك إخفاء البيانات حسب الحاجة، ووضعها في نظام إدارة قواعد البيانات (DBMS)، ثم استرجاعها وفك تشفيرها حسب الحاجة، مباشرة على مستوى التطبيق. في الوقت نفسه، فكر على الفور في كيفية حماية هذه الخوارزميات في التطبيق. في رأينا، يجب أن يتم ذلك على مستوى نظام إدارة قواعد البيانات (DBMS)، لأنه سيعمل بشكل أسرع.

تم تقديم هذا التقرير لأول مرة في @لقاء قواعد البيانات بواسطة Mail.ru Cloud Solutions. يرى فيديو العروض الأخرى والاشتراك في إعلانات الأحداث في Telegram حول Kubernetes في مجموعة Mail.ru.

ماذا تقرأ عن الموضوع:

1. أكثر من Ceph: تخزين الكتل السحابية MCS.
2. كيفية اختيار قاعدة بيانات لمشروع حتى لا تضطر إلى الاختيار مرة أخرى.

المصدر: www.habr.com