الانتقال إلى المحتوى الرئيسي
إخفاء البيانات هو تقنية تُستخدم لحماية البيانات، حيث تُستبدل البيانات الأصلية بنسخة منها تحافظ على تنسيقها وبنيتها مع إزالة أي معلومات تعريف شخصية (PII) أو معلومات حساسة. يوضح هذا الدليل كيفية إخفاء البيانات في ClickHouse باستخدام عدة أساليب:
  • سياسات الإخفاء (ClickHouse Cloud، 25.12+): إخفاء ديناميكي مدمج يُطبَّق وقت الاستعلام لمستخدمين/أدوار محددة
  • String replacement functions: إخفاء أساسي باستخدام الدوال المضمنة
  • Masked views: إنشاء طرق عرض بمنطق تحويل
  • Materialized columns: تخزين نُسخ مخفية إلى جانب البيانات الأصلية
  • قواعد إخفاء الاستعلامات: إخفاء البيانات الحساسة في السجلات (ClickHouse OSS)

استخدام سياسات الإخفاء (ClickHouse Cloud)

تتوفر سياسات الإخفاء في ClickHouse Cloud بدءًا من الإصدار 25.12.
يوفّر الأمر CREATE MASKING POLICY طريقة مدمجة لإخفاء قيم الأعمدة ديناميكيًا لمستخدمين أو أدوار محددة عند وقت الاستعلام. وعلى عكس الأساليب الأخرى، لا تتطلب سياسات الإخفاء إنشاء واجهات عرض منفصلة أو تخزين بيانات مخفية، إذ يحدث هذا التحويل بشفافية عندما يستعلم المستخدمون من الجدول.

سياسة إخفاء بسيطة

لتوضيح سياسات الإخفاء، لننشئ جدول orders يحتوي على معلومات العملاء:
الآن، أنشئ دورًا للمستخدمين الذين ينبغي لهم رؤية البيانات المخفية:
أنشئ سياسة إخفاء تُطبَّق على دور masked_data_viewer:
عندما يُجري مستخدم لديه الدور masked_data_viewer استعلامًا على الجدول orders، فإنه يرى البيانات المخفية تلقائيًا:
Query
Response (for masked_data_viewer role)
يرى المستخدمون الذين لا يملكون الدور masked_data_viewer البيانات الأصلية غير المُخفاة.

الإخفاء المشروط

يمكنك استخدام العبارة WHERE لتطبيق الإخفاء على صفوف معيّنة فقط. على سبيل المثال، لإخفاء الطلبات ذات القيمة العالية فقط:

سياسات متعددة مع تحديد الأولوية

عندما تسري عدة سياسات إخفاء على العمود نفسه، استخدم البند PRIORITY للتحكم في التحويل الذي سيُطبَّق. وتُطبَّق قيم الأولوية الأعلى أخيرًا:
في هذا المثال، بالنسبة إلى الطلبات التي يكون فيها total_amount > 100، تحلّ سياسة refined_masking (الأولوية 10) محلّ سياسة basic_masking (الأولوية 0) بالنسبة إلى العمود name، بينما يواصل email استخدام الإخفاء الأساسي.

الإخفاء المستند إلى التجزئة

في الحالات التي تحتاج فيها إلى إخفاء متسق (أي إن الإدخال نفسه يُنتِج دائمًا المخرَج المُخفى نفسه)، استخدم دوال التجزئة:

إدارة سياسات الإخفاء

اعرض جميع سياسات الإخفاء:
احذف سياسة إخفاء البيانات:
استبدال سياسة موجودة:
لمزيد من التفاصيل، راجع توثيق CREATE MASKING POLICY.

استخدم دوال استبدال السلاسل النصية

في حالات استخدام إخفاء البيانات الأساسية، توفّر عائلة الدوال replace طريقة ملائمة لإخفاء البيانات: على سبيل المثال، يمكنك استبدال الاسم “John Smith” بعنصر نائب [CUSTOMER_NAME] باستخدام الدالة replaceOne:
Query
Response
وبشكلٍ أعم، يمكنك استخدام replaceRegexpOne لاستبدال اسم أي عميل:
Query
Response
أو يمكنك إخفاء رقم الضمان الاجتماعي مع الإبقاء على آخر 4 أرقام فقط باستخدام الدالة replaceRegexpAll.
Query
في الاستعلام أعلاه، يُستخدم \3 لإدراج مجموعة الالتقاط الثالثة في السلسلة الناتجة، لينتج ما يلي:
Response

إنشاء VIEWs لإخفاء البيانات

يمكن استخدام VIEW بالاقتران مع دوال السلاسل النصية المذكورة أعلاه لتطبيق تحويلات على الأعمدة التي تحتوي على بيانات حساسة قبل عرضها على المستخدم. وبهذه الطريقة، تبقى البيانات الأصلية من دون تغيير، ولا يرى المستخدمون الذين يستعلمون عبر هذا الـ VIEW سوى البيانات المُخفاة. للتوضيح، لنتخيّل أن لدينا جدولًا يخزّن سجلات طلبات العملاء. نريد التأكد من أن مجموعة من الموظفين يمكنها عرض هذه المعلومات، لكننا لا نريدهم أن يروا البيانات الكاملة الخاصة بالعملاء. شغّل الاستعلام أدناه لإنشاء جدول تجريبي باسم orders وإدراج بعض سجلات طلبات العملاء الافتراضية فيه:
أنشئ طريقة عرض باسم masked_orders:
في عبارة SELECT ضمن استعلام إنشاء طريقة العرض أعلاه، نحدّد التحويلات باستخدام replaceRegexpOne على الحقول name وemail وphone وshipping_address، وهي الحقول التي تحتوي على معلومات حساسة ونرغب في إخفائها جزئيًا. اعرض البيانات من طريقة العرض:
Query
Response
لاحظ أن البيانات المُعادة من طريقة العرض تكون مخفية جزئيًا، مما يحجب المعلومات الحساسة. يمكنك أيضًا إنشاء عدة طرق عرض بمستويات مختلفة من التعتيم، بحسب مستوى الوصول الممنوح إلى المعلومات لدى الـ Viewer. لضمان تمكّن المستخدمين من الوصول فقط إلى طريقة العرض التي تُرجع البيانات المخفية، وليس إلى الـ table التي تحتوي على البيانات الأصلية غير المقنَّعة، ينبغي استخدام Role Based Access Control لضمان أن تكون لدى أدوار محددة فقط grants لإجراء select من طريقة العرض. أنشئ الدور أولًا:
بعد ذلك، امنح الدور امتيازات SELECT على طريقة العرض:
نظرًا إلى أن أدوار ClickHouse تراكمية، يجب عليك التأكد من أن المستخدمين الذين ينبغي لهم رؤية العرض المُخفّى فقط لا يملكون أي امتياز SELECT على الجدول الأساسي من خلال أي دور. لذلك، ينبغي لك إلغاء امتياز الوصول إلى الجدول الأساسي صراحةً احتياطًا:
أخيرًا، أسنِد الدور إلى المستخدمين المناسبين:
يضمن ذلك أن المستخدمين الذين لديهم الدور masked_orders_viewer لا يمكنهم سوى الاطلاع على البيانات المخفية من العرض، وليس البيانات الأصلية غير المُقنَّعة من الجدول.

استخدم أعمدة MATERIALIZED وقيود الوصول على مستوى العمود

في الحالات التي لا تريد فيها إنشاء طريقة عرض منفصلة، يمكنك تخزين نُسخ مخفية من بياناتك إلى جانب البيانات الأصلية. وللقيام بذلك، يمكنك استخدام أعمدة MATERIALIZED. تُحتسب قيم هذه الأعمدة تلقائيًا وفقًا للتعبير المحدد لها عند إدراج الصفوف، ويمكن استخدامُها لإنشاء أعمدة جديدة تحتوي على نُسخ مخفية من البيانات. استنادًا إلى المثال السابق، وبدلًا من إنشاء VIEW منفصل للبيانات المخفية، سنُنشئ الآن أعمدة مخفية باستخدام MATERIALIZED:
إذا نفّذت الآن استعلام SELECT التالي، فسترى أن البيانات المُقنَّعة تصبح ‘مُخزَّنة ماديًا’ وقت الإدراج وتُخزَّن إلى جانب البيانات الأصلية غير المُقنَّعة. ومن الضروري تحديد الأعمدة المُقنَّعة صراحةً، لأن ClickHouse لا يضمّن الأعمدة المُخزَّنة ماديًا تلقائيًا في استعلامات SELECT * افتراضيًا.
Query
Response
لضمان ألا يتمكن المستخدمون من الوصول إلا إلى الأعمدة التي تحتوي على البيانات المخفية، يمكنك استخدام Role Based Access Control مرة أخرى لضمان ألّا تُمنَح أدوار محددة سوى صلاحية select على الأعمدة المقنّعة في orders. أعِد إنشاء الدور الذي أنشأناه سابقًا:
بعد ذلك، امنح صلاحية SELECT على الجدول orders:
ألغِ الوصول إلى أي أعمدة حساسة:
أخيرًا، أسنِد الدور إلى المستخدمين المناسبين:
إذا كنت تريد تخزين البيانات المخفية فقط في جدول orders، فيمكنك تمييز الأعمدة الحساسة غير المقنّعة بأنها EPHEMERAL، وهذا يضمن عدم تخزين أعمدة من هذا النوع في الجدول.
إذا شغّلنا الاستعلام نفسه كما في السابق، فسترى الآن أن البيانات المخفية المُخزَّنة فعليًا فقط هي التي أُدرِجت في الجدول:
Query
Response

استخدم قواعد إخفاء الاستعلامات لبيانات السجلات

بالنسبة إلى مستخدمي ClickHouse OSS الذين يرغبون تحديدًا في إخفاء بيانات السجلات، يمكنهم استخدام قواعد إخفاء الاستعلامات (إخفاء السجلات) لإخفاء البيانات. للقيام بذلك، يمكنك تحديد قواعد إخفاء تستند إلى تعبيرات نمطية في تهيئة الخادم. تُطبَّق هذه القواعد على الاستعلامات وجميع رسائل السجل قبل تخزينها في سجلات الخادم أو جداول النظام (مثل system.query_log وsystem.text_log وsystem.processes). يساعد هذا على منع تسرّب البيانات الحساسة إلى السجلات فقط. لاحظ أن هذا لا يُخفي البيانات في نتائج الاستعلام. على سبيل المثال، لإخفاء رقم الضمان الاجتماعي، يمكنك إضافة القاعدة التالية إلى تهيئة الخادم:
آخر تعديل في ٢٥ يونيو ٢٠٢٦