خصوصية البيانات للتحليات على نطاق السحابة في Azure

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

مخطط تصنيف سرية البيانات

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

قبل استيعاب البيانات، يجب تصنيف البيانات على أنها سرية أو أقل أوحساسة (بيانات شخصية):

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

• قد يتم فرز البيانات إلى بيانات حساسة (بيانات شخصية) إذا كانت هناك قيود تكون الأعمدة والصفوف مرئية لمستخدمين مختلفين.

هام

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

سري أو أقل

لكل منتج بيانات مدمج، نقوم بإنشاء مجلدي مستودع بيانات في الطبقات المنسقة والمثرية، سرية أو أدناهوحساسة (بيانات شخصية)، ونستخدم قوائم التحكم في الوصول لتمكين دليل Microsoft Azure (Azure AD) Pass-through Authentication.

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

يتيح هذا النمط لأي منتج حساب يدعم Azure AD Pass-through Authentication الاتصال بمستودع البيانات ومصادقة المستخدمين المسجلين. إذا كان المستخدم جزءا من مجموعة Azure AD لأصل البيانات، فيمكنه الوصول إلى البيانات عبر مصادقة المرور Azure AD. يسمح لهؤلاء المستخدمين داخل المجموعة بقراءة أصل البيانات بأكمله دون عوامل تصفية النهج. يمكن بعد ذلك تدقيق Access بالتفصيل باستخدام السجلات المناسبة وMicrosoft Graph.

للحصول على توصيات حول تخطيط مستودع البيانات الخاص بك، يرجى مراجعة توفير ثلاثة حسابات Azure Data Lake Storage Gen2 لكل منطقة هبوط بيانات.

ملاحظة

من أمثلة منتجات الحوسبة تجمعات Azure Databricks وAzure Synapse Analytics وApache Spark وAzure Synapse SQL عند الطلب الممكنة مع مصادقة المرور Azure AD.

البيانات الحساسة (البيانات الشخصية)

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

أحد أمثلة السيناريوهات

يصف المثال التالي خيارات تأمين الحساسة (البيانات الشخصية):

ي استيعاب تطبيق البيانات لمنتج بيانات موظفي الموارد البشرية (HR) لأمريكا الشمالية وأوروبا. تستدعي حالة الاستخدام للمستخدمين الأوروبيين رؤية سجلات الموظفين الأوروبيين فقط ومستخدمي أمريكا الشمالية لرؤية سجلات الموظفين في أمريكا الشمالية فقط. يتم تقييده بشكل أكبر بحيث يرى مديرو الموارد البشرية فقط الأعمدة التي تحتوي على بيانات الراتب.

الخيار 1: محرك النهج (مستحسن)

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

• الوصول إلى البيانات
• إدارة دورة حياة البيانات
• السياسات واللوائح الداخلية والخارجية
• نهج مشاركة البيانات
• تحديد البيانات الحساسة (البيانات الشخصية)
• رؤى حول الحماية والتوافق
• نهج الإبلاغ عن حماية البيانات

عادة ما يتكامل محرك النهج مع كتالوج بيانات مثل Azure Purview. يتميز Azure Marketplace بحلول موردين تابعين لجهة خارجية، ويعمل بعض الموردين مع Azure Synapse وAzure Databricks لتشفير المعلومات وفك تشفيرها مع توفير أمان على مستوى الصف وعلى مستوى العمود. اعتبارا من يناير 2022، أطلق Azure Purview معاينة عامة لنهج الوصول للتحكم في الوصول إلى البيانات المخزنة في Blob Azure Data Lake Storage (ADLS) Gen2. راجع توفير مجموعة البيانات بواسطة مالك البيانات ل Azure Storage (معاينة).

يجب أن يستخدم محرك النهج مجموعات Azure AD لتطبيق النهج على منتجات البيانات. يتمثل توقع أي حل نهج يوفر خصوصية البيانات في رمز حساس (البيانات الشخصية) والتحقق دائما من خلال التحكم في الوصول إلى السمات حتى يتمكن المستخدم من إلغاء رمز الأعمدة التي يحتاج إلى الوصول إليها.

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

الخيار 2: إصدارات سرية أو أسفل وحساسة (بيانات شخصية)

لكل منتج بيانات يتم تصنيفه على أنه حساس (بيانات شخصية) يتم إنشاء نسختين بواسطة البنية الأساسية لبرنامج ربط العمليات التجارية. واحد يصنف على أنه سري أو أدناه يحتوي على جميع الأعمدة الحساسة (البيانات الشخصية) التي تمت إزالتها ويتم إنشاؤها ضمن المجلد السري أو أدناه لمنتج البيانات. يتم إنشاء النسخة الأخرى في المجلد الحساس (البيانات الشخصية)، لمنتج البيانات، الذي يحتوي على جميع البيانات الحساسة المضمنة. سيتم تعيين مجموعة أمان قارئ Microsoft Azure Active Directory ومجموعة أمان كاتب Azure Active Directory لكل مجلد. باستخدام إدارة الوصول إلى البيانات ، يمكن للمستخدم طلب الوصول إلى منتج البيانات.

في حين أن هذا يفي بفصل البيانات الحساسة (الشخصية)والسرية أو أدناه، فإن المستخدم الذي منح حق الوصول عبر مصادقة مرور Active Directory إلى الحساسة (البيانات الشخصية) سيكون قادرا على الاستعلام عن جميع الصفوف. إذا كنت بحاجة إلى أمان على مستوى الصف، فستحتاج إلى استخدام الخيار 1: محرك النهج (مستحسن) أو الخيار 3: قاعدة بيانات Azure SQL أو مثيل SQL المدار أو تجمعات SQL Azure Synapse Analytics.

الخيار 3: قاعدة بيانات Azure SQL أو مثيل SQL المدار أو تجمعات Azure Synapse Analytics SQL

يستخدم تطبيق البيانات تجمعات SQL Database أو SQL Managed Instance أو Azure Synapse Analytics SQL لتحميل منتجات البيانات في قاعدة بيانات تدعم الأمان على مستوى الصف والأمان على مستوى العمود وإخفاء البيانات الديناميكي. تقوم فرق تطبيق البيانات بإنشاء مجموعات Azure AD مختلفة وتعيين أذونات تدعم حساسية البيانات.

بالنسبة لحالة استخدام هذا السيناريو، ستحتاج فرق تطبيقات البيانات إلى إنشاء مجموعات Azure AD الأربع التالية مع الوصول للقراءة فقط:

التجميع	الإذن
DA-AMERICA-HRMANAGER-R	عرض أصل بيانات موظفي الموارد البشرية في أمريكا الشمالية مع معلومات الراتب.
DA-AMERICA-HRGENERAL-R	عرض أصل بيانات موظفي الموارد البشرية في أمريكا الشمالية دون معلومات الراتب.
DA-EUROPE-HRMANAGER-R	عرض أصل بيانات موظفي الموارد البشرية في أوروبا مع معلومات الراتب.
DA-EUROPE-HRGENERAL-R	عرض أصل بيانات موظفي الموارد البشرية في أوروبا دون معلومات الراتب.

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

المستوى الثاني هو إضافة أمان على مستوى العمود لتقييد المديرين غير المسؤولين عن الموارد البشرية من رؤية الرواتب والأمان على مستوى الصف لتقييد الصفوف التي يمكن لأعضاء فريق أوروبا وأمريكا الشمالية رؤيتها.

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

يمكن توفير الجداول ل Azure Databricks باستخدام موصل Apache Spark: SQL Server وقاعدة بيانات Azure SQL.

الخيار 4: Azure Databricks

الخيار الرابع هو استخدام Azure Databricks لاستكشاف الحساسة (البيانات الشخصية). يساعد استخدام مجموعة من مكتبات تشفير Fernet والوظائف المعرفة من قبل المستخدم (UDFs) وأسرار Databricks والتحكم في الوصول إلى الجدول ووظائف العرض الديناميكي على تشفير الأعمدة وفك تشفيرها.

كمنشور مدونة، فإن فرض التشفير على مستوى العمود وتجنب تكرار البيانات، يصف:

الخطوة الأولى في هذه العملية هي حماية البيانات عن طريق تشفيرها أثناء الاستيعاب وأحد الحلول الممكنة هو مكتبة Fernet Python. يستخدم Fernet تشفيرا متماثلا، والذي تم إنشاؤه مع العديد من بدائيات التشفير القياسية. يتم استخدام هذه المكتبة داخل UDF التشفير الذي سيمكننا من تشفير أي عمود معين في إطار بيانات. لتخزين مفتاح التشفير، نستخدم أسرار Databricks مع عناصر التحكم في الوصول في مكانها للسماح فقط لعملية استيعاب البيانات لدينا بالوصول إليها. بمجرد كتابة البيانات في جداول Delta Lake الخاصة بنا، سيكون من المستحيل على المستخدم غير المصرح له قراءة أعمدة البيانات الشخصية التي تحتوي على قيم مثل رقم الضمان الاجتماعي ورقم الهاتف ورقم بطاقة الائتمان والمعرفات الأخرى.

بمجرد كتابة البيانات الحساسة وحمايتها، تحتاج إلى طريقة للمستخدمين المتميزين لقراءة البيانات الحساسة. أول شيء يجب القيام به هو إنشاء UDF دائم لإضافته إلى مثيل Apache Hive الذي يعمل على Databricks. لكي يكون UDF دائما، يجب كتابته بلغة Scala. لحسن الحظ، لدى Fernet أيضا تطبيق Scala يمكنك استخدامه للقراءات التي تم فك تشفيرها. يصل UDF هذا أيضا إلى نفس السر المستخدم في الكتابة المشفرة للقيام بفك التشفير، وفي هذه الحالة، تتم إضافته إلى تكوين Spark للمجموعة. يتطلب هذا منا إضافة عناصر تحكم في الوصول إلى نظام المجموعة للمستخدمين المتميزين وغير المميزين للتحكم في وصولهم إلى المفتاح. بمجرد إنشاء UDF، يمكننا استخدامه ضمن تعريفات العرض الخاصة بنا للمستخدمين المتميزين لمشاهدة البيانات التي تم فك تشفيرها.

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

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

طريقة عرض أمريكا الشمالية:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_us AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-AMERICA-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='US'

وجهة النظر الأوروبية:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_eu AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-EUROPE-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='EU'

لكي يعمل، يمكنك تمكين التحكم في الوصول إلى جدول Azure Databricks في مساحة العمل وتطبيق الأذونات التالية:

• DA-AMERICA-HRGENERAL-R امنح DA-AMERICA-HRMANAGER-R المجموعات حق الوصول إلى vhr_us طريقة العرض Azure AD.
• DA-EUROPE-HRGENERAL-R امنح DA-EUROPE-HRMANAGER-R المجموعات حق الوصول إلى vhr_eu طريقة العرض Azure AD.

نظرا لأن الأعمدة مشفرة ولا يمكن فك تشفيرها في مساحة العمل السرية أو الموجودة أدناه، فلا يزال بإمكان مساحات العمل السرية أو أدناه استخدام مصادقة المرور Azure AD والسماح للمستخدمين باستكشاف المستودع، استنادا إلى أذوناتهم.

عند استخدام الوصول إلى الجدول، تتم إضافة الفرق التي تتطلب الوصول إلى مساحة عمل Azure Databricks. سيستخدم Azure Databricks أساسيات الخدمة لتعيين إلى Azure Data Lake Storage، ولكن سيتم تأمين البيانات باستخدام التحكم في الوصول إلى جدول Azure Databricks.

عند توزيع منتجات بيانات جديدة، سيحتاج جزء من عملية DevOps إلى تشغيل البرامج النصية لإعداد أذونات الجدول في مساحة عمل Azure Databricks وإضافة مجموعات Azure AD الصحيحة إلى هذه الأذونات.

ملاحظة

لا يمكن دمج التحكم في الوصول إلى جدول Azure Databricks Azure AD مصادقة المرور. لذلك، يمكنك استخدام مساحة عمل Azure Databricks واحدة فقط واستخدام التحكم في الوصول إلى الجدول بدلا من ذلك.

البيانات المقيدة

إلى جانب تنفيذ خيارات البيانات السرية أو المقيدة، نوصي أيضا باستضافة بيانات سرية للغاية في منطقة هبوط بيانات مخصصة ومنطقة هبوط لإدارة البيانات.

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

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

الخطوات التالية

• إدارة الوصول إلى البيانات