اسمي دينيس روجكوف ، وأنا رئيس تطوير البرامج في Gazinformservice ، في فريق منتجات Jatoba . تفرض التشريعات واللوائح المؤسسية متطلبات معينة لأمان تخزين البيانات. لا أحد يريد لأطراف ثالثة الوصول إلى المعلومات السرية ، وبالتالي فإن القضايا التالية مهمة لأي مشروع: تحديد الهوية والمصادقة ، وإدارة الوصول إلى البيانات ، وضمان سلامة المعلومات في النظام ، وتسجيل الأحداث الأمنية. لذلك ، أود أن أتحدث عن بعض النقاط المثيرة للاهتمام فيما يتعلق بأمان DBMS.تمت كتابة هذه المقالة بواسطة Databases Meetup ، التي استضافتها Mail.ru Cloud Cloud Solutions . إذا كنت لا تريد القراءة ، يمكنك أن ترى:ستحتوي المقالة على ثلاثة أجزاء:- كيفية حماية الاتصالات.
- ما هو تدقيق الإجراءات وكيفية تسجيل ما يحدث من جانب قاعدة البيانات والاتصال بها.
- كيفية حماية البيانات في قاعدة البيانات نفسها وما هي التقنيات المتاحة لذلك.
المكونات الثلاثة لأمن DBMS: حماية الاتصال ، تدقيق النشاط ، وحماية البياناتحماية الاتصال
يمكنك الاتصال بقاعدة البيانات إما بشكل مباشر أو غير مباشر من خلال تطبيقات الويب. كقاعدة ، لا يتفاعل المستخدم من جانب العمل ، أي الشخص الذي يعمل مع نظام إدارة قواعد البيانات ، بشكل مباشر معه.قبل الحديث عن تأمين الاتصالات ، تحتاج إلى الإجابة عن الأسئلة المهمة التي تعتمد على كيفية بناء الإجراءات الأمنية:- ما إذا كان مستخدم الأعمال يعادل مستخدم DBMS واحد ؛
- هو الوصول إلى بيانات DBMS المقدمة فقط من خلال واجهة برمجة التطبيقات التي تتحكم فيها ، أو هل هناك إمكانية الوصول إلى الجداول مباشرة ؛
- ما إذا كان نظام إدارة قواعد البيانات (DBMS) مخصصًا في مقطع محمي منفصل ، والذي يتفاعل معه وكيف ؛
- ما إذا كان سيتم استخدام التجميع / الوكيل والبرامج الوسيطة ، الأمر الذي يمكن أن يغير المعلومات حول كيفية بناء الاتصال ومن يستخدم قاعدة البيانات.
الآن دعونا نرى ما هي الأدوات التي يمكن استخدامها لحماية الاتصالات:- استخدام حلول فئة جدار حماية قاعدة البيانات. طبقة إضافية من الحماية ، على الأقل ، ستزيد شفافية ما يحدث في نظام إدارة قواعد البيانات ، كحد أقصى - يمكنك توفير حماية إضافية للبيانات.
- . , . — -, , . , , .
, MS SQL Vulnerability Assessmen . - . , , , , , . .
- تكوين 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"
ضد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"
ضد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
نتائج الاختبار :عند الأحمال الخفيفة ، يمكن مقارنة تأثير طبقة المقابس الآمنة بخطأ القياس. إذا كان حجم البيانات المنقولة كبيرًا جدًا ، فقد يختلف الوضع. إذا أنشأنا اتصالًا واحدًا لكل معاملة (هذا نادر الحدوث ، عادة ما يكون الاتصال مشتركًا بين المستخدمين) ، فلديك عدد كبير من الاتصالات / قطع الاتصال ، قد يكون التأثير أكثر قليلاً. أي أنه قد تكون هناك مخاطر على تدهور الأداء ، ومع ذلك ، فإن الفرق ليس كبيرًا إلى حد عدم استخدام الحماية.يرجى ملاحظة أن هناك اختلافًا قويًا عند مقارنة أوضاع التشغيل: في نفس الجلسة ، أنت تعمل أو مختلفة. هذا أمر مفهوم: يتم إنفاق الموارد على إنشاء كل اتصال.كانت لدينا حالة عندما قمنا بتوصيل Zabbix في وضع الثقة ، أي أننا لم نتحقق من md5 ، ولم تكن هناك حاجة للمصادقة. ثم طلب العميل تمكين وضع مصادقة md5. هذا أعطى حمولة كبيرة على وحدة المعالجة المركزية ، انخفض الأداء. بدأوا في البحث عن طرق للتحسين. أحد الحلول الممكنة لهذه المشكلة هو تنفيذ تقييد الشبكة ، وإنشاء شبكات محلية ظاهرية منفصلة لـ DBMS ، وإضافة الإعدادات بحيث يكون من الواضح من الذي يتصل من أين ويزيل المصادقة. يمكنك أيضًا تحسين إعدادات المصادقة لتقليل تكاليف تمكين المصادقة ، ولكن بشكل عام باستخدام طرق مختلفة تؤثر المصادقة على الأداء وتتطلب أخذ هذه العوامل في الاعتبار عند تصميم قوة الحوسبة للخوادم (الأجهزة) لنظام DBMS.الخلاصة: في عدد من الحلول ، حتى الفروق الدقيقة في المصادقة يمكن أن تؤثر بشكل كبير على المشروع ويكون الأمر سيئًا عندما يصبح واضحًا فقط عند تنفيذه في المنتج.مراجعة الإجراءات
لا يمكن أن يكون التدقيق مجرد DBMS. التدقيق هو تلقي معلومات حول ما يحدث في قطاعات مختلفة. يمكن أن يكون جدار حماية لقاعدة البيانات ونظام التشغيل الذي تم بناء DBMS عليه.في DBMSs على مستوى المؤسسة التجارية مع التدقيق ، كل شيء على ما يرام ، في مصدر مفتوح - ليس دائمًا. إليك ما لدى PostgreSQL:- السجل الافتراضي - تسجيل مدمج ؛
- الإضافات: pgaudit - إذا لم يكن لديك ما يكفي من التسجيل الافتراضي ، يمكنك استخدام إعدادات منفصلة تحل بعض المشاكل.
إضافة إلى التقرير في الفيديو:"يمكن توفير التسجيل الأساسي للمشغلين مع وسيلة تسجيل قياسية مع log_statement = all.هذا مقبول للمراقبة والاستخدامات الأخرى ، لكنه لا يوفر مستوى التفاصيل المطلوبة عادةً للتدقيق.لا يكفي وجود قائمة بجميع العمليات التي يتم إجراؤها باستخدام قاعدة البيانات.يجب أن يكون من الممكن أيضًا العثور على بيانات محددة تهم المدقق.تُظهر أداة التسجيل القياسية ما طلبه المستخدم ، بينما تركز pgAudit على تفاصيل ما حدث عندما قدمت قاعدة البيانات الطلب.على سبيل المثال ، قد يرغب المدقق في التأكد من إنشاء جدول معين في نافذة صيانة موثقة.قد تبدو هذه مهمة بسيطة للتدقيق الأساسي والتدقيق ، ولكن ماذا لو صادفت شيئًا كهذا (مربكًا عن عمد) مثال:DO $$BEGINEXECUTE 'CREATE TABLE import' || 'ant_table (معرف INT)' ؛نهاية $$ ؛يمنحك التسجيل القياسي ما يلي:LOG: العبارة: DO $$BEGINEXECUTE 'CREATE TABLE import' || 'ant_table (معرف INT)' ؛نهاية $$ ؛يبدو أن البحث عن جدول اهتمام قد يتطلب بعض المعرفة البرمجية في الحالات التي يتم فيها إنشاء الجداول ديناميكيًا.هذا ليس مثاليًا ، حيث سيكون من الأفضل البحث حسب اسم الجدول فقط.هذا هو المكان الذي سيكون فيه pgAudit مفيدًا.للإدخال نفسه ، سيتم إخراج هذا الإخراج في السجل:AUDIT: الجلسة، 33.1، وظيفة، DO ،،، "DO $$BEGINتنفيذ 'CREATE TABLE استيراد' || 'ant_table (معرف INT)' ؛END $$ ؛ "مراجعة: SESSION ، 33،2 ، DDL ، CREATE TABLE ، TABLE ، public.important_table ، CREATE TABLE important_table (id INT)ليس فقط تم تسجيل كتلة DO ، ولكن أيضًا النص الكامل CREATE TABLE مع نوع المشغل ونوع الكائن و الاسم الكامل ، مما يسهل البحث.في إجراء مجلة المشغلين SELECT و DML pgAudit يمكن تكوينه لتسجيل إدخال منفصل لكل علاقة ، المشار إليها في البيان.لا تحتاج إلى تحليل للعثور على جميع العبارات التي تتعلق بجدول معين ( * ) " .كيف سيؤثر ذلك على أداء DBMS؟
دعونا نجري الاختبارات مع تمكين التدقيق الكامل ونرى ما يحدث مع أداء PostgreSQL. نقوم بتمكين تسجيل أقصى قاعدة بيانات من جميع النواحي.لا نغير أي شيء تقريبًا في ملف التكوين ، من الملف المهم - قم بتشغيل وضع debug5 للحصول على أقصى قدر من المعلومات.postgresql.confفي PostgreSQL DBMS مع المعلمات 1 CPU ، 2.8 GHz ، 2 GB RAM ، 40 GB HDD ، نقوم بإجراء ثلاثة اختبارات تحميل باستخدام الأوامر التالية:$ 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
نتائج الإختبار:خلاصة القول: المراجعة الكاملة ليست جيدة للغاية. ستنتقل البيانات من المراجعة إلى حجم ، مثل البيانات الموجودة في قاعدة البيانات نفسها ، أو حتى أكثر. يمثل مقدار التسجيل الذي يتم إنشاؤه عند العمل مع DBMS مشكلة شائعة على المنتج.نحن ننظر إلى معلمات أخرى:- لا تتغير السرعة كثيرًا: بدون تسجيل - 43.74 ثانية ، مع تسجيل - 53.23 ثانية.
- سوف ينخفض الأداء على ذاكرة الوصول العشوائي ووحدة المعالجة المركزية ، حيث تحتاج إلى إنشاء ملف مع التدقيق. كما يمكن ملاحظته على الإنتاجية.
مع زيادة عدد الاتصالات ، بالطبع ، سيتدهور الأداء قليلاً.في الشركات التي لديها تدقيق ، يكون الأمر أكثر صعوبة:- هناك الكثير من البيانات ؛
- لا يلزم التدقيق فقط من خلال سجل النظام في SIEM ، ولكن أيضًا في الملفات: فجأة يحدث شيء ما مع سجل النظام ، ويجب أن يكون الملف الذي يتم حفظ البيانات فيه قريبًا من قاعدة البيانات ؛
- يتطلب التدقيق رفًا منفصلاً ، حتى لا يغرق على أقراص الإدخال / الإخراج ، لأنه يشغل مساحة كبيرة ؛
- يحدث أن موظفي IS بحاجة إلى GOSTs في كل مكان ، فهم يحتاجون إلى هوية الضيف.
تقييد الوصول إلى البيانات
دعونا نلقي نظرة على التقنيات المستخدمة لحماية البيانات والوصول إليها في DBMS التجارية والمصدر المفتوح.ما يمكن استخدامه ككل:- تشفير وإخفاء الإجراءات والوظائف - أي الأدوات والأدوات المساعدة المنفصلة التي تجعل التعليمات البرمجية غير قابلة للقراءة من التعليمات البرمجية القابلة للقراءة. صحيح ، إذن لا يمكن تغييره أو إعادة بنائه. مثل هذا النهج مطلوب في بعض الأحيان على الأقل من جانب DBMS - يتم تشفير منطق قيود الترخيص أو منطق التفويض بدقة على مستوى الإجراء والوظيفة.
- (RLS) — , , - - .
- (Masking) — , , - . , .
- Security DBA/Application DBA/DBA — , , , database- application-. open source , . , .
- . , , .
- — .
- End-to-end encryption — client-side .
- . , — , .
?
دعونا نلقي نظرة على مثال لتشفير الأعمدة في 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
ساعة الإيقاف قيد التشغيل. معرف | text1 | النص 2------ + ------- + -------1 | 1 | 12 | 2 | 23 | 3 | 3...997 | 997 | 997998| 998 | 998،999| 999 | 9991000 | 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 | \ x31 | \ x312 | \ x32 | \ x323 | \ x33 | \ x33...999 | \ x393939 | \ x3939391000 | \ x31303030 | \ x31303030(1000 سطر)الوقت: 50.203 مللي ثانيةنتائج الاختبار :التشفير له تأثير كبير على الأداء. يمكن ملاحظة أن التوقيت قد ازداد ، نظرًا لأن عمليات فك تشفير البيانات المشفرة (ولا يزال يتم فك التشفير عادةً في المنطق الخاص بك) تتطلب موارد كبيرة. أي أن فكرة تشفير جميع الأعمدة التي تحتوي على نوع من البيانات محفوفة بالأداء المنخفض.ومع ذلك ، فإن التشفير ليس رمزًا فضيًا يحل جميع المشكلات. توجد البيانات التي تم فك تشفيرها ومفتاح فك التشفير في عملية فك التشفير ونقل البيانات على الخادم. لذلك ، يمكن اعتراض المفاتيح من قبل أولئك الذين لديهم حق الوصول الكامل إلى خادم قاعدة البيانات ، على سبيل المثال ، مسؤول النظام.عندما يكون العمود بأكمله لجميع المستخدمين يحتوي على مفتاح واحد (حتى لو لم يكن للجميع ، ولكن لمجموعة محدودة من العملاء) ، فهذا ليس جيدًا وصحيحًا دائمًا. هذا هو السبب في أنهم بدأوا في إجراء التشفير من طرف إلى طرف ، في نظام إدارة قواعد البيانات (DBMS) ، بدأوا في التفكير في خيارات لتشفير البيانات من العميل والخادم ، ظهرت نفس مستودعات خزائن المفاتيح - منتجات منفصلة توفر إدارة رئيسية من جانب نظام إدارة قواعد البيانات (DBMS).مثال على هذا التشفير في MongoDBميزات الأمان في DBMS التجارية والمفتوحة المصدر
الجدول بعيد عن الاكتمال ، ولكن الوضع هو ما يلي: في المنتجات التجارية ، تم حل مشكلات الأمان لفترة طويلة ، وفي المصدر المفتوح ، كقاعدة عامة ، يتم استخدام بعض الوظائف الإضافية للأمان ، والعديد من الوظائف ليست كافية ، وأحيانًا يجب عليك إضافة شيء ما. على سبيل المثال ، سياسات كلمات المرور - في PostgreSQL هناك العديد من الامتدادات المختلفة ( 1 ، 2 ، 3 ، 4 ، 5 ) التي تطبق سياسات كلمات المرور ، ولكن ، في رأيي ، لا يوجد أي منها يغطي جميع احتياجات شريحة الشركات المحلية.ماذا تفعل إذا لم يكن هناك ما هو مطلوب ؟ على سبيل المثال ، أريد استخدام DBMS محدد ، حيث لا توجد وظائف يحتاجها العميل.ثم يمكنك استخدام حلول الطرف الثالث التي تعمل مع DBMSs مختلفة ، على سبيل المثال ، "Crypto DB" أو "Garda DB". إذا كنا نتحدث عن حلول من القطاع المحلي ، فإنهم يعرفون عن GOSTs أفضل من المصادر المفتوحة.الخيار الثاني هو أن تكتب لنفسك ما تحتاجه ، وتنفيذ الوصول إلى البيانات والتشفير في التطبيق على مستوى الإجراء. صحيح ، مع GOST سيكون أكثر صعوبة. ولكن بشكل عام - يمكنك إخفاء البيانات حسب الحاجة ، ووضعها في نظام إدارة قواعد البيانات ، ثم الحصول عليها وفك تشفيرها كما ينبغي ، على مستوى التطبيق مباشرة. في الوقت نفسه ، فكر على الفور في كيفية حماية هذه الخوارزميات عند التطبيق. في رأينا ، يجب أن يتم ذلك على مستوى DBMS ، لأنه سيعمل بشكل أسرع.تم إجراء هذا الحديث لأول مرة في Meets by Mail.ru Cloud Solutions. شاهد الفيديوالمظاهر الأخرى والاشتراك في إعلانات حدث Telegram حول Kubernetes في Mail.ru Group .ماذا تقرأ عن هذا الموضوع :- أكثر من Ceph: MCS Block Cloud Storage .
- كيفية اختيار قاعدة بيانات للمشروع حتى لا يتم الاختيار مرة أخرى .