كان لدى مورد لتقنيات الرعاية الصحية أمن بيانات قوي عبر أنظمة تطبيقاته: ضوابط وصول قائمة على الأدوار، وتشفير على مستوى الحقول، وسجلات تدقيق، ومراجعات وصول ربع سنوية. وقبل ثلاث سنوات، بنى فريق هندسة البيانات بحيرة بيانات مركزية في AWS S3 تغذيها مهام نسخ متماثل من كل قاعدة بيانات تطبيق. وكان الهدف تمكين التحليلات ومقاييس المنتجات وتعلم الآلة دون التأثير في أنظمة الإنتاج. وعلى مدى ثلاث سنوات، نمت بحيرة البيانات لتحتوي على التاريخ الكامل لكل سجل عميل، وكل معاملة، وكل ملاحظة سريرية، وكل حدث تكامل عالجه المورد على الإطلاق. وكان فريق هندسة البيانات قد حدد ضوابط الوصول إلى بحيرة البيانات عند إنشائها: صلاحية قراءة لأي شخص في فريقي هندسة البيانات والمنتجات، اللذين نما عدد أعضائهما من ثمانية أشخاص إلى سبعة وأربعين. ولم يُجرِ أحد مراجعة للوصول إلى بحيرة البيانات منذ إنشائها. كانت بحيرة البيانات تحتوي على أشمل مستودع للبيانات الحساسة في بيئة المورد، وكانت لديها أضعف ضوابط وصول بين جميع الأنظمة التي يشغّلها المورد.
ما مشكلة تعرض بحيرات البيانات لدى الموردين في حقيقتها؟
بحيرة البيانات مستودع مركزي مصمم لتخزين كميات كبيرة من البيانات الأولية غير المعالجة الواردة من مصادر متعددة، مثل قواعد بيانات التطبيقات وتدفقات الأحداث وسجلات API والمصادر الخارجية، بصيغتها الأصلية، بما يتيح استعلامات تحليلية مرنة دون قيود المخطط التي تفرضها قاعدة البيانات العلائقية التقليدية. وتكتسب بحيرات البيانات قيمتها تحديدًا من خصائص تصميمها: فهي تستوعب كل شيء، وتخزنه بتكلفة منخفضة، وتوفر وصولًا واسعًا للاستعلام يتيح التحليلات الاستكشافية وتعلم الآلة وذكاء المنتجات، وهو ما يستحيل في أنظمة الإنتاج الخاضعة لحوكمة مشددة. وهذه الخصائص نفسها، أي الاستيعاب الشامل والتخزين منخفض التكلفة والوصول الواسع، تجعل بحيرات البيانات مصدر خطر كبير على أمن البيانات عندما تحتوي على بيانات عملاء حساسة.
تنشأ فجوة الحوكمة من التوتر بين الغرض التحليلي لبحيرة البيانات ومتطلبات حوكمة البيانات الحساسة التي تحتويها. فبحيرات البيانات يصممها مهندسو بيانات يسعون إلى تعظيم المرونة التحليلية، إذ يريدون أن يتمكن علماء البيانات والمحللون ومديرو المنتجات ومهندسو ML من الاستعلام بحرية دون اختناقات في الوصول. أما برامج حوكمة البيانات فتصممها فرق الأمن والخصوصية التي تسعى إلى تقييد الوصول، إذ تريد ألا تكون البيانات الحساسة متاحة إلا لمن يحتاجون إليها لأغراض محددة مصرح بها. وهذه الأهداف متعارضة من الناحية الهيكلية، وفي معظم المؤسسات بنى فريق هندسة البيانات بحيرة البيانات قبل أن يشارك فريق حوكمة البيانات، ما أوجد مستودعًا شاملًا للبيانات الحساسة كان قيد التشغيل قبل تحديد متطلبات حوكمته.
تجعل مشكلة التجميع تعرض بحيرات البيانات مختلفًا من حيث النوع عن تعرض قواعد البيانات الفردية. فسجل العميل في قاعدة بيانات التطبيق يحتوي على البيانات الخاصة بذلك السياق التعاملي المحدد، أما بحيرة البيانات التي تستوعب البيانات من كل قاعدة بيانات تطبيق فتحتوي على كل سجل تعاملي لكل عميل عبر تاريخ المورد بأكمله، وهو ملف تعريف شامل أكثر حساسية من أي نظام مصدر بمفرده لأنه يدمج بيانات من سياقات متعددة في مجموعة بيانات موحدة قابلة للاستعلام. وقيمة مجموعة البيانات المجمعة هذه للمهاجم أعلى بالتناسب من أي نظام مصدر بمفرده، بينما تكون صرامة الحوكمة المطبقة عليها عادةً أدنى بالتناسب.
يتركز تعرض بحيرات البيانات لدى الموردين حول خمسة أنماط محددة من المخاطر:
- وصول افتراضي واسع: بحيرات بيانات مهيأة بصلاحية قراءة لفرق أو أقسام بأكملها بدلًا من ضوابط وصول خاصة بالأدوار وقائمة على الحاجة إلى المعرفة ومعايرة وفق حساسية البيانات
- غياب الأمن على مستوى الحقول: بحيرات بيانات توفر وصولًا على مستوى الجداول أو الحاويات دون قيود على مستوى الحقول، ما يكشف جميع الحقول بما فيها الحساسة لأي مستخدم يملك وصولًا إلى الجدول
- تراكم تاريخي شامل دون حوكمة للاحتفاظ: بحيرات بيانات تستوعب كل شيء ولا تحذف شيئًا، فتراكم سنوات من تاريخ البيانات الحساسة دون إنفاذ آلي للاحتفاظ
- غياب سجلات التدقيق: بحيرات بيانات لا يُسجَّل فيها نشاط الاستعلام أو لا تُراجع سجلاتها، ما يجعل اكتشاف أنماط الوصول الشاذة إلى البيانات مستحيلًا
- تعرض بيانات التدريب في ML: استخدام بيانات العملاء في بحيرات البيانات مدخلات لتدريب نماذج تعلم الآلة دون إذن صريح أو تقليل للبيانات أو إزالة للهوية
لماذا يهم هذا
يكتسب تعرض بحيرات البيانات لدى الموردين أهميته في TPRM لأنه يمثل تركزًا للبيانات الحساسة في نقطة من بنية المورد مصممة تحديدًا لتكون متاحة على نطاق واسع. فخرق بحيرة بيانات المورد لا يكشف بيانات تطبيق واحد، بل يكشف التاريخ المجمع لكل نظام تطبيقات يغذيها. وبالنسبة لمورد يخدم مئات العملاء من المؤسسات، يمكن أن يكون خرق بحيرة البيانات حدث تعرض للبيانات يشمل عملاء متعددين وسنوات متعددة، بحجم لا يبلغه خرق أي قاعدة بيانات تطبيق بمفردها.
يكتسب بعد التهديد الداخلي أهمية خاصة في بحيرات البيانات. فالمهاجمون الخارجيون يجب أن يخترقوا محيط المورد للوصول إلى قواعد بيانات التطبيقات، أما الوصول إلى بحيرة البيانات فيكون متاحًا عادةً لعشرات المستخدمين الداخليين، من مهندسي البيانات وعلماء البيانات ومحللي المنتجات، لم يخضع وصول كثير منهم للمراجعة قط، وربما غادر بعضهم المؤسسة مع احتفاظه ببيانات اعتماد الوصول. والوصول الداخلي الواسع الذي يمنح بحيرات البيانات قيمتها التحليلية يجعلها أهدافًا عالية القيمة للتهديدات الداخلية ولاختراق بيانات الاعتماد الذي يتجاوز الضوابط الأمنية الخارجية.
تتزايد أهمية بعد بيانات التدريب في ML مع إدماج الموردين تعلم الآلة في منتجاتهم. فبيانات العملاء في بحيرة بيانات المورد قد تُستخدم بيانات تدريب لنماذج ML، إما صراحةً ضمن برنامج لتحسين الميزات، وإما ضمنيًا لأن بحيرة البيانات هي المصدر الأيسر لأمثلة التدريب الموسومة. ودون محظورات تعاقدية صريحة وضوابط تقنية تمنع استخدام بيانات العملاء في مسارات تدريب ML، تفتح بحيرة بيانات المورد مسارًا لتصبح بيانات العملاء مضمّنة في أوزان نماذج تُشارك عبر قاعدة عملاء المورد.
أين تخطئ معظم الفرق
يتمثل الإخفاق الأكثر تكرارًا في عدم السؤال عما إذا كان المورد يشغّل بحيرة بيانات أو مستودع تحليلات مركزيًا مماثلًا يجمع البيانات من أنظمة التطبيقات الرئيسية الخاضعة للتقييم. فتقييمات TPRM التي تقيّم أمن قواعد بيانات التطبيقات تقييمًا شاملًا قد لا تكتشف أبدًا أن جميع تلك القواعد تغذي مستودعًا مركزيًا تختلف حوكمة الوصول إليه اختلافًا جوهريًا. فبحيرة البيانات قرار داخلي يتعلق بالبنية التحتية للتحليلات نادرًا ما يتطوع الموردون بذكره في التقييمات الأمنية لأنها ليست نظام السجلات المعتمد للخدمة المتعاقد عليها.
يتمثل الإخفاق الثاني في التعامل مع أمن بحيرات البيانات بوصفه شأنًا من شؤون هندسة البيانات لا شأنًا من شؤون أمن البيانات. ففي معظم مؤسسات الموردين، تبني بحيرات البيانات وتشغّلها فرق هندسة البيانات التي ينصب اهتمامها الرئيسي في الحوكمة على جودة البيانات وموثوقية مسارات المعالجة. أما حوكمة أمن البيانات، أي ضوابط الوصول وسجلات التدقيق وسياسات الاحتفاظ والتشفير على مستوى الحقول، فتُطبق على أنظمة التطبيقات من خلال إشراف فريق الأمن. وكثيرًا ما تقع بحيرات البيانات خارج ذلك الإشراف لأن فريقًا مختلفًا هيأها قبل أن تمتد عمليات الحوكمة الأمنية إلى البنية التحتية للتحليلات.
- عدم السؤال عن وجود بحيرة بيانات أو مستودع تحليلات مركزي: تقييم قواعد بيانات التطبيقات دون اكتشاف النسخة التحليلية المجمعة
- استبعاد بحيرة البيانات من نطاق التقييم الأمني: تقييمات SOC 2 وتقييمات الموردين يقتصر نطاقها على أنظمة تطبيقات الإنتاج وتستبعد صراحةً البنية التحتية للتحليلات
- غياب تقييم ضوابط الوصول إلى بحيرة البيانات: وصول فرق كاملة على نطاق واسع لم يُراجع قط في ضوء متطلبات حساسية البيانات
- غياب اشتراط سجلات التدقيق للبنية التحتية للتحليلات: نشاط الاستعلام في بحيرات البيانات لا يُسجَّل أو لا يُراجع
- عدم تقييم استخدام بيانات التدريب في ML: غياب السؤال عما إذا كانت بيانات العملاء في بحيرة البيانات تُستخدم مدخلات لتدريب ML
كيف تبدو الممارسة الجيدة
تطبق البرامج الناضجة لحوكمة بحيرات البيانات لدى الموردين معايير أمن البيانات على البنية التحتية للتحليلات بالصرامة نفسها المطبقة على أنظمة التطبيقات، من خلال تطبيق الأمن القائم على السمات أو على مستوى الصفوف لتقييد الوصول إلى الحقول الحساسة، والاحتفاظ بسجلات تدقيق لجميع أنشطة الاستعلام، وإنفاذ سياسات احتفاظ تمنع تراكم البيانات الحساسة إلى أجل غير مسمى، وحظر استخدام بيانات العملاء القابلة للتعريف مدخلات لتدريب ML دون إذن صريح.
- الأمن القائم على السمات أو على مستوى الصفوف في بحيرة البيانات: ضوابط وصول تقيد الحقول والصفوف الحساسة بناءً على دور المستخدم والحاجة إلى المعرفة، لا مجرد وصول على مستوى الجداول
- سجلات تدقيق لجميع أنشطة الاستعلام: تسجيل كل استعلام في بحيرة البيانات مع هوية المستخدم والطابع الزمني ومجموعة البيانات التي جرى الوصول إليها، مع اكتشاف الحالات الشاذة في أنماط الوصول غير المعتادة
- إنفاذ سياسات الاحتفاظ على بحيرة البيانات: الحذف الآلي للسجلات التي تجاوزت مدد الاحتفاظ بدلًا من تراكمها إلى أجل غير مسمى
- إزالة الهوية أو استخدام الأسماء المستعارة لأغراض التحليلات: إزالة الهوية من بيانات العملاء الحساسة أو إعطاؤها أسماء مستعارة قبل إدخالها إلى بحيرة البيانات حيث لا تتطلب حالات الاستخدام التحليلية تحديد الهوية
- الإذن باستخدام بيانات التدريب في ML: اشتراط إذن صريح من العميل قبل استخدام بياناته مدخلات لتدريب ML، مع تطبيق تقليل البيانات وإزالة الهوية
- شمول بحيرة البيانات في نطاق SOC 2 والتقييم الأمني: تقييم البنية التحتية للتحليلات وفق معايير الأمن نفسها المطبقة على أنظمة التطبيقات
الأدوات
تتطلب حوكمة أمن بحيرات البيانات أدوات مصممة خصيصًا لسياق البنية التحتية التحليلية، أي ضبط الوصول وسجلات التدقيق وإخفاء البيانات في بيئات بحيرات البيانات السحابية.
أمن بحيرات البيانات السحابية: AWS Lake Formation وAzure Purview وDatabricks Unity Catalog
يوفر AWS Lake Formation أمنًا على مستوى الأعمدة والصفوف لبحيرات البيانات القائمة على S3، ما يتيح ضوابط وصول دقيقة تقصر الحقول الحساسة على المستخدمين المصرح لهم مع السماح بوصول أوسع إلى البيانات غير الحساسة. ويوفر Azure Purview حوكمة البيانات وتصنيفها عبر منظومة بيانات Azure بما فيها بحيرات البيانات. ويوفر Databricks Unity Catalog ضبطًا موحدًا للوصول وسجلات تدقيق لبحيرات البيانات القائمة على Databricks. وبالنسبة لممارسي TPRM، فإن السؤال عما إذا كانت بحيرة بيانات المورد تستخدم Lake Formation أو ضوابط وصول دقيقة مماثلة يكشف ما إذا كان الأمن على مستوى الحقول موجودًا أم أن الوصول يقتصر على المستوى الأوسع للجداول أو الحاويات.
إخفاء البيانات لأغراض التحليلات: Tonic.ai وGretel.ai وImmuta
تعمل منصات إخفاء البيانات والبيانات الاصطناعية على تحويل بيانات العملاء الحساسة قبل دخولها إلى بحيرة البيانات، فتوفر بيانات مناسبة للتحليلات تحافظ على الخصائص الإحصائية دون أن تتضمن معلومات شخصية قابلة للتعريف. ويوفر Immuta ضوابط للوصول إلى البيانات قائمة على السياسات يمكنها إخفاء الحقول الحساسة ديناميكيًا بناءً على دور المستخدم، ما يتيح لمجموعة البيانات نفسها أن تخدم مستويات وصول مختلفة دون الاحتفاظ بنسخ متعددة. وبالنسبة لممارسي TPRM، فإن السؤال عما إذا كان المورد يطبق الإخفاء أو إزالة الهوية على البيانات الحساسة قبل إدخالها إلى بحيرة البيانات يكشف ما إذا كانت حالة الاستخدام التحليلية تتطلب بيانات قابلة للتعريف أم أن البدائل الحافظة للخصوصية ممكنة.
تدقيق بحيرات البيانات ومراقبتها: Securiti وCyera وLaminar
توفر منصات DSPM ومراقبة بحيرات البيانات رؤية مستمرة لأنماط الوصول إلى بحيرات البيانات، إذ تكتشف الاستعلامات الشاذة، وتحدد البيانات الحساسة المتاحة على نطاق واسع، وتنبه إلى مخالفات سياسات الوصول. وبالنسبة لممارسي TPRM، فإن السؤال عما إذا كان المورد يراقب نشاط الاستعلام في بحيرة البيانات بحثًا عن أنماط وصول شاذة يكشف ما إذا كانت بحيرة البيانات قابلة للرصد أم أنها فعليًا نقطة عمياء في مراقبته الأمنية.
تحديات الحوكمة
يتمثل تحدي الحوكمة في أمن بحيرات البيانات في التوتر بين الحجم والمرونة. فبحيرات البيانات تحتوي على بيانات من أنظمة مصدر كثيرة بصيغ متباينة، ويستعلم عنها مستخدمون كثيرون ذوو احتياجات تحليلية متباينة. ويتطلب تطبيق أمن متسق على مستوى الحقول في هذه البيئة غير المتجانسة تصنيف كل حقل، وتحديد سياسات الوصول لكل دور من أدوار المستخدمين، والإنفاذ على مستوى طبقة الاستعلام، وهو استثمار في الحوكمة لم تقم به فرق هندسة البيانات عادةً لأنه لم يكن جزءًا من موجز التصميم الأصلي لبحيرة البيانات.
بالنسبة لبرامج TPRM، يتمثل النهج العملي للحوكمة في إدراج وجود بحيرة البيانات وحوكمة الوصول إليها سؤالًا قياسيًا في تقييمات أي مورد يعالج بيانات عملاء حساسة على نطاق واسع. فوجود بحيرة البيانات ليس خطرًا في حد ذاته، بل هو نمط معماري شائع ومشروع. أما ضوابط الوصول وسجلات التدقيق وحوكمة الاحتفاظ المطبقة عليها فهي التي تحدد ما إذا كانت تمثل قدرة تحليلية خاضعة لحوكمة جيدة، أم مستودعًا متاحًا على نطاق شامل لكل سجل حساس عالجه المورد على الإطلاق.
- إضافة وجود بحيرة البيانات إلى أسئلة تقييم الموردين: هل يوجد مستودع تحليلات مركزي يجمع البيانات من أنظمة التطبيقات الخاضعة للتقييم
- اسأل تحديدًا عن ضوابط الوصول إلى بحيرة البيانات: الأمن على مستوى الحقول، ووتيرة مراجعة الوصول، وما إذا كان نموذج الوصول قد رُوجع في ضوء متطلبات حساسية البيانات
- اشتراط سجلات تدقيق لنشاط الاستعلام في بحيرة البيانات: لا مجرد تسجيل على مستوى البنية التحتية، بل تدقيق على مستوى الاستعلام يتضمن هوية المستخدم والوصول إلى مجموعات البيانات
- اسأل عن الإذن باستخدام بيانات التدريب في ML: ما إذا كانت بيانات العملاء من بحيرة البيانات تُستخدم مدخلات لتدريب ML وما عملية الإذن المطبقة
- إدراج بحيرة البيانات في متطلبات نطاق SOC 2: شمول البنية التحتية للتحليلات في نطاق التقييم الأمني، وعدم استثنائها بوصفها بنية تحتية تشغيلية
إذا كنت فريقًا صغيرًا
أضف سؤالًا واحدًا إلى تقييمك لأي مورد يعالج بيانات حساسة على نطاق واسع: هل تشغّلون بحيرة بيانات مركزية أو مستودع تحليلات يجمع البيانات من أنظمة تطبيقاتكم؟ وإن كان الأمر كذلك، فمن يملك وصولًا إليه، وهل رُوجع ذلك الوصول في ضوء حساسية البيانات التي يحتويها؟ سيكشف هذا السؤال وجود بنية تحتية لبحيرة البيانات لم يصل إليها تقييمك لقواعد بيانات التطبيقات قط، وستخبرك الإجابة ما إذا كانت أشمل نسخة من بيانات عملائك في بيئة المورد تخضع لحوكمة صارمة تعادل حوكمة الأنظمة الرئيسية التي قيّمتها.
- اسأل عن وجود بحيرة بيانات أو مستودع تحليلات مركزي قبل إنهاء تقييم قواعد بيانات التطبيقات
- اسأل عن عدد المستخدمين الذين يملكون وصولًا إلى بحيرة البيانات وعن موعد آخر مراجعة لذلك الوصول
- اسأل عما إذا كانت بيانات العملاء في بحيرة البيانات تُستخدم مدخلات لتدريب ML
- اسأل عما إذا كانت بحيرة البيانات ضمن نطاق تدقيق SOC 2 أو التدقيق الأمني المماثل لدى المورد
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
"هل تشغّلون بحيرة بيانات أو مستودع تحليلات مركزيًا يحتوي على بيانات من أنظمة التطبيقات التي تستخدمونها لمعالجة بيانات عملائنا؟ وإن كان الأمر كذلك، فما ضوابط الوصول المطبقة عليه، ومتى رُوجع الوصول إليه آخر مرة؟"
"هل تُستخدم بيانات العملاء في بحيرة البيانات لديكم مدخلات لتدريب نماذج تعلم الآلة، سواء لتحسين منتجاتكم أو بوصفها بيانات تدريب عامة؟ وإن كان الأمر كذلك، فما عمليات الإذن وإزالة الهوية المطبقة؟"
"هل بحيرة البيانات لديكم مشمولة في نطاق تدقيق SOC 2 أو التدقيق الأمني المماثل، أم أنها مستبعدة بوصفها بنية تحتية تشغيلية أو تحليلية؟"
ما تتوقعه دليلًا
- تأكيد وجود بحيرة البيانات مع وصف ضوابط الوصول
- أدلة مراجعة الوصول: موعد آخر مراجعة للوصول إلى بحيرة البيانات، والفئة الحالية من المستخدمين الذين يملكون الوصول
- تأكيد استخدام بيانات التدريب في ML وعملية الإذن
- تأكيد نطاق SOC 2 أو ما يعادله: شمول بحيرة البيانات أو استبعادها صراحةً مع بيان السبب
المورد الذي يجيب عن سؤال بحيرة البيانات بعبارة "نستخدم بنية تحتية للتحليلات لدعم منتجنا" يكون قد أكد وجودها دون أن يصف الوصول إليها. اسأل تحديدًا عن عدد الأشخاص الذين يمكنهم الاستعلام في بحيرة البيانات وعما توصلت إليه آخر مراجعة للوصول. فمنصة التحليلات المصممة للاستكشاف لديها ضوابط وصول تخدم الاستكشاف، وقد لا تخدم تلك الضوابط حساسية بياناتك.
كيف تُثبت ذلك
تتزايد معالجة حوكمة بحيرات البيانات في إطار مبدأي تقليل البيانات وتقييد التخزين في GDPR كما يُطبقان على البنية التحتية للتحليلات، وفي الإرشادات القطاعية بشأن حوكمة مخازن البيانات التحليلية. ويتطلب إثبات بذل العناية الواجبة أدلة على أن البنية التحتية للتحليلات قد قُيّمت إلى جانب أنظمة التطبيقات.
- سجلات تقييم الموردين التي توثق الأسئلة المتعلقة بوجود بحيرة البيانات وحوكمة الوصول إليها واستخدام بيانات التدريب في ML
- مراجعة نطاق SOC 2 لتأكيد ما إذا كانت البنية التحتية للتحليلات مشمولة
- توثيق ضوابط الوصول إلى بحيرة البيانات للعلاقات الأعلى خطورة مع الموردين
- تأكيد الإذن باستخدام بيانات التدريب في ML
الخلاصة الرئيسية
بُنيت بحيرة البيانات للاستكشاف. فهي تستوعب كل شيء، وتحتفظ بكل شيء، وتوفر وصولًا واسعًا لأن ذلك ما يمنحها قيمتها التحليلية. وهذه الخصائص نفسها تجعلها أكثر مستودعات البيانات حساسية في بيئة المورد: نسخة شاملة ومكتملة تاريخيًا ومتاحة على نطاق واسع من كل سجل في كل نظام شغّله المورد على الإطلاق. تتمتع قواعد بيانات التطبيقات بضوابط قوية لأنها صُممت للمعالجة التعاملية تحت إشراف أمني، بينما تتمتع بحيرة البيانات بضوابط أضعف لأن فريق هندسة البيانات صممها من أجل المرونة التحليلية قبل أن تمتد الحوكمة الأمنية إلى البنية التحتية للتحليلات. وتقييم أمن قواعد بيانات التطبيقات دون السؤال عن بحيرة البيانات أشبه بتقييم واجهة المتجر بينما المستودع الذي خلفها غير مقفل.