كان لدى مورد برمجيات سحابية لقطاع التأمين برنامج ناضج لأمن البيانات لقواعد بيانات تطبيقاته الرئيسية. فقد طُبّق التصنيف، وفُرضت ضوابط الوصول، وأكد تدقيق SOC 2 وجود ضوابط مناسبة في أنظمته الرئيسية. أما ما لم يفحصه التدقيق، لأنه كان خارج نطاق الأنظمة الرئيسية، فهو نظام تذاكر دعم العملاء لدى المورد. فعلى مدى ست سنوات من التشغيل، أرسل العملاء تذاكر دعم بملفات مرفقة تضمنت وثائق تأمين بأرقام الضمان الاجتماعي، ونماذج مطالبات بمعلومات طبية، ووثائق هوية ممسوحة ضوئيًا، وجداول بيانات مُصدَّرة تحتوي على PII للعملاء رفعها العملاء أثناء معالجة تباينات في البيانات. واحتوى نظام التذاكر على نحو أربعة عشر ألف مرفق حساس، لم يُصنَّف أي منها، ولم يخضع أي منها للحوكمة ضمن برنامج أمن البيانات. ثم اختُرق نظام التذاكر عبر ثغرة منفصلة. ووصف الإخطار بالاختراق انكشاف محتوى تذاكر الدعم. وسألت الجهة التنظيمية للتأمين عمّا إذا كان المورد قد أجرى فحصًا لاكتشاف البيانات الحساسة في أنظمة الدعم لديه، فكانت الإجابة: لا.
ما حقيقة مشكلة فجوات اكتشاف البيانات الحساسة؟
اكتشاف البيانات الحساسة هو العملية المنهجية لفحص بيئة البيانات في المؤسسة لتحديد مواضع وجود البيانات الحساسة، أي المعلومات الشخصية والبيانات المالية والمعلومات الصحية وبيانات الاعتماد وغيرها من فئات البيانات الخاضعة للتنظيم أو عالية القيمة، عبر أنظمة التخزين والمستندات ومنصات التعاون والبنية التحتية التشغيلية. وتنشأ الفجوة من التوتر المتأصل بين طريقة تصميم برامج حوكمة البيانات، انطلاقًا من مستودعات البيانات الحساسة المعروفة، والطريقة التي تتوزع بها البيانات الحساسة فعليًا، إذ تتراكم عبر الأنشطة التشغيلية لكل شخص ونظام يتعامل مع مشهد بيانات المؤسسة.
تُصمَّم برامج حوكمة البيانات عادةً حول الأنظمة التي تجمع البيانات الحساسة وتخزنها عن قصد: قواعد بيانات العملاء، وأنظمة الموارد البشرية، والمنصات المالية، وأنظمة السجلات الصحية. وتُجرد هذه الأنظمة وتُصنَّف وتخضع للحوكمة وتُدرج في التقييمات الأمنية لأن غرضها المتعلق بالبيانات الحساسة صريح ومعروف. أما فجوة الاكتشاف فتنشأ في الفئة الأكبر بكثير من الأنظمة التي تجمع البيانات الحساسة عرضًا من خلال التشغيل الاعتيادي لعمليات الأعمال: أنظمة الدعم التي يرسل فيها العملاء ملفات تحتوي على معلومات شخصية، ومنصات التعاون التي يتشارك فيها الموظفون مستندات تحتوي على بيانات حساسة، وأرشيفات البريد الإلكتروني التي تنتقل فيها المعلومات الحساسة ضمن المرفقات، والأنظمة التشغيلية التي تصل إليها البيانات الحساسة سياقًا للمهمة الجاري تنفيذها.
كثيرًا ما يُستهان بحجم التراكم العرضي للبيانات الحساسة. ففي أي مؤسسة تتعامل مع العملاء أو تعالج المعاملات أو تدير علاقات خدمة مستمرة، تصل البيانات الحساسة عبر قنوات الدعم والطلبات التشغيلية واتصالات الأعمال بكميات تتضاءل أمامها مجموعة البيانات المُدارة رسميًا. فقد يراكم نظام تذاكر الدعم لدى مورد في قطاع التأمين عبر مرفقات ملفات العملاء في عام واحد بيانات حساسة أكثر مما تضيفه قاعدة البيانات الرئيسية في الفترة نفسها، لأن كل عميل يرسل طلب دعم قد يرفق المستند الذي بين يديه، وكثيرًا ما يكون وثيقة تأمين أو نموذج مطالبة أو كشف حساب يحتوي على معلوماته الشخصية.
تتركز فجوات اكتشاف البيانات الحساسة حول خمسة أنماط محددة للتراكم:
- مرفقات أنظمة الدعم والتذاكر: ملفات يرسلها العملاء تحتوي على بيانات حساسة تُرفع سياقًا لطلبات الدعم، وتتراكم في أنظمة التذاكر خارج نطاق حوكمة البيانات الرئيسية
- مستندات منصات التعاون: بيانات حساسة تُتشارك عبر قنوات Teams وسلاسل محادثات Slack ومجلدات Google Drive ومكتبات SharePoint في سياق العمل التشغيلي، ولم تُصنَّف أو تخضع للحوكمة رسميًا قط
- البيانات الحساسة في أرشيفات البريد الإلكتروني: معلومات شخصية وبيانات مالية وبيانات اعتماد تُرسل في مرفقات البريد الإلكتروني ونصوص الرسائل، وتتراكم في أرشيفات البريد الإلكتروني التي قد لا تكون ضمن نطاق الاكتشاف في برنامج حوكمة البيانات
- الجمع العرضي في الأنظمة التشغيلية: أنظمة السجلات ومنصات الرصد وأدوات الإبلاغ عن الأخطاء وقواعد البيانات التشغيلية التي تراكم بيانات حساسة أثرًا جانبيًا لوظيفة الرصد الأساسية لديها
- البيانات الحساسة في بيئات التطوير والاختبار: عينات من بيانات الإنتاج منسوخة إلى بيئات التطوير، ومجموعات بيانات اختبار تحتوي على معلومات عملاء حقيقية، ومخرجات تصحيح الأخطاء التي تلتقط بيانات حساسة من أنظمة الإنتاج
لماذا يهم هذا
تكتسب فجوات اكتشاف البيانات الحساسة أهمية بالنسبة لـTPRM لأنها تمثل فئة من انكشاف البيانات لا تراها تقييمات أمن الموردين المعتادة. فالمورد الذي يؤكد وجود ضوابط مناسبة على أنظمته الرئيسية، ويجتاز تدقيق SOC 2 المقتصر نطاقه على تلك الأنظمة، ويحتفظ بوثائق شاملة لحوكمة البيانات، قد يحتفظ في الوقت نفسه بكميات كبيرة من بيانات العملاء الحساسة في أنظمة لم تدخل قط ضمن نطاق أي تقييم أو تدقيق أو برنامج حوكمة. فالضوابط المؤكدة في التقييم تنطبق على الأنظمة التي جرى تقييمها، أما الاختراق الذي سيقع فسيجد النظام الذي لم يُقيَّم.
عاقبة الإخطار بالاختراق هي البُعد الأكثر أثرًا على الفور. فعندما يتعرض مورد لاختراق ويبدأ فريق الاستجابة للحوادث تحديد النطاق، سيفحص جميع الأنظمة بحثًا عن البيانات الحساسة، بما فيها الأنظمة التي لم تكن قط ضمن نطاق برنامج الحوكمة. والبيانات الحساسة المكتشفة في تلك الأنظمة أثناء تحديد النطاق يجب إدراجها في الإخطار بالاختراق، بصرف النظر عمّا إذا كان وجودها هناك معروفًا قبل الاختراق. والمورد الذي يؤكد أنه يُخضع بيانات العملاء الحساسة للحوكمة على النحو المناسب قد يجد أن إخطاره بالاختراق يصف انكشاف بيانات لم يكن يعلم أنه يحتفظ بها، في أنظمة لم يقيّمها قط، عبر عمليات لم يعتبرها قط من أنشطة التعامل مع البيانات.
يضيف بُعد الامتثال التنظيمي مزيدًا من الإلحاح. فمبدأ المساءلة في GDPR يشترط أن يتمكن المتحكمون في البيانات والمعالجون من إثبات علمهم بالبيانات الشخصية التي يحتفظون بها والأساس القانوني للاحتفاظ بها. والمورد الذي يحتفظ بكميات كبيرة من البيانات الشخصية في أنظمة غير مفحوصة لا يستطيع إثبات المساءلة وفق GDPR عن تلك البيانات لأنه لا يعلم بوجودها. ففجوة الاكتشاف هي في آن واحد خطر أمني وفجوة في الامتثال التنظيمي.
أين تخطئ معظم الفرق
الإخفاق الأكثر تكرارًا هو قصر نطاق تقييم أمن البيانات على الأنظمة المعروف أنها تحتفظ ببيانات حساسة، بدلًا من البحث عن الأنظمة التي ربما تراكمت فيها بيانات حساسة دون حوكمة. فالتقييمات التي تنطلق من جرد البيانات الحساسة المعروفة ستؤكد الحوكمة على الأنظمة المعروفة وتغفل فجوة الاكتشاف كليًا، لأن سؤال «هل يخضع هذا النظام لحوكمة كافية؟» لا يمكن طرحه إلا عن الأنظمة المدرجة في الجرد، وفجوة الاكتشاف هي بالضبط فجوة الجرد.
الإخفاق الثاني هو التعامل مع اكتشاف البيانات الحساسة على أنه تمرين يُجرى مرة واحدة بدلًا من عملية مستمرة. فحتى المؤسسات التي تُجري فحوصًا أولية لاكتشاف البيانات كثيرًا ما تكتشف أن بيانات حساسة جديدة تتراكم في أنظمة سبق فحصها بين دورات الفحص، وأن أنظمة جديدة تُنشأ أو تُعتمد دون أن يستتبع ذلك فحص اكتشاف. وتتكرر فجوة الاكتشاف باستمرار مع تطور بيئة البيانات.
- قصر نطاق التقييم على الأنظمة المعروفة: تقييم حوكمة مستودعات البيانات الحساسة المحددة دون فحص اكتشاف للتراكمات غير المحددة
- عدم تقييم بيانات أنظمة الدعم: أنظمة الدعم والتذاكر الموجهة للعملاء غير مدرجة في نطاق اكتشاف البيانات الحساسة
- غياب وتيرة للاكتشاف: فحوص اكتشاف تُجرى مرة واحدة دون إعادة فحص دورية لتحديد تراكمات البيانات الحساسة الجديدة
- عدم فحص منصات التعاون: استبعاد Teams وSlack وSharePoint وأنظمة البريد الإلكتروني من نطاق اكتشاف البيانات الحساسة
- عدم فحص بيئات التطوير والاختبار: البيانات الحساسة في البيئات غير الإنتاجية ليست ضمن نطاق برنامج الاكتشاف
كيف تبدو الممارسة الجيدة
تفحص برامج اكتشاف البيانات الحساسة الناضجة بيئة البيانات بالكامل، لا الأنظمة المعروف احتواؤها على بيانات حساسة فحسب، بل جميع أنظمة التخزين التي يمكن أن تكون البيانات الحساسة قد تراكمت فيها، وفق جدول زمني محدد، مع إحالة النتائج إلى برنامج التصنيف والحوكمة لمعالجتها. وبرنامج الاكتشاف مستمر، لا يقتصر على نقطة زمنية واحدة.
- فحص الاكتشاف في البيئة بالكامل: تطبيق أدوات الاكتشاف على جميع أنظمة التخزين، بما فيها منصات الدعم وأدوات التعاون وأرشيفات البريد الإلكتروني وبيئات التطوير
- فحص بيانات أنظمة الدعم: إدراج أنظمة التذاكر ومنصات مكاتب المساعدة ومساحات تخزين دعم العملاء تحديدًا في نطاق الاكتشاف
- إعادة الفحص المستمرة أو الدورية: فحوص اكتشاف وفق وتيرة محددة لتحديد التراكمات الجديدة بين الدورات
- معالجة نتائج الاكتشاف: تقييم البيانات الحساسة المكتشفة في الأنظمة غير المصنفة وتصنيفها وإخضاعها للحوكمة المناسبة أو حذفها
- فحص بيئات التطوير: إدراج البيئات غير الإنتاجية في نطاق الاكتشاف مع تركيز خاص على وجود بيانات الإنتاج
الأدوات
يتطلب اكتشاف البيانات الحساسة أدوات قادرة على فحص بيئات تخزين غير متجانسة بحثًا عن أنماط البيانات الحساسة في البيانات المنظمة وغير المنظمة على حد سواء.
اكتشاف البيانات وتصنيفها: BigID وVaronis وSpirion وMicrosoft Purview
تطبّق هذه المنصات مطابقة الأنماط والتعلم الآلي وتحليل المحتوى لفحص بيئات التخزين بحثًا عن البيانات الحساسة، فتحدد المعلومات الشخصية والبيانات المالية والسجلات الصحية وبيانات الاعتماد في قواعد البيانات وأنظمة الملفات والتخزين السحابي ومنصات التعاون. وتوفر BigID تحديدًا فحصًا شاملًا عبر بيئات بيانات متنوعة، منها التخزين السحابي وتطبيقات SaaS والمستودعات غير المنظمة. وبالنسبة لممارسي TPRM، فإن السؤال عمّا إذا كان فحص الاكتشاف لدى المورد يغطي أنظمة الدعم ومنصات التعاون يكشف ما إذا كانت فجوة الاكتشاف الموصوفة في السيناريو الافتتاحي ستُكتشف.
أمن أنظمة الدعم: ميزات GDPR في Zendesk، وFreshdesk Data Privacy، وSalesforce Shield
توفر منصات دعم العملاء الحديثة ميزات للخصوصية وأمن البيانات مخصصة لإدارة البيانات الحساسة في سياقات الدعم: الاكتشاف الآلي للبيانات الحساسة في محتوى التذاكر ومرفقاتها، وإخفاء البيانات الحساسة المكتشفة، وسياسات الاحتفاظ بمحتوى التذاكر. وبالنسبة لممارسي TPRM، فإن السؤال عمّا إذا كانت ميزات إدارة البيانات الحساسة مفعّلة في منصة الدعم لدى المورد يمثل سؤالًا محددًا عن القدرات لأعلى قنوات التراكم العرضي للبيانات خطورة.
DLP لمنصات التعاون: DLP من Microsoft Purview، وNightfall، وPolymer
تكتشف أدوات DLP الخاصة بمنصات التعاون البيانات الحساسة في رسائل Teams وقنوات Slack ومحتوى Google Workspace ومستندات SharePoint وتستجيب لها، فتمنع تراكم البيانات الحساسة في مساحات تخزين التعاون غير المصنفة. وبالنسبة لممارسي TPRM، فإن السؤال عمّا إذا كان المورد يطبّق DLP على منصات التعاون التي تحتوي على محتوى يشاركه العملاء يكشف ما إذا كانت ثاني أكثر قنوات التراكم العرضي للبيانات الحساسة شيوعًا مشمولة بالتغطية.
تحديات الحوكمة
يتمثل تحدي الحوكمة في اكتشاف البيانات الحساسة في التعقيد التشغيلي لفحص بيئات غير متجانسة على نطاق واسع. فبيئات البيانات في المؤسسات تضم عشرات أنظمة التخزين والتطبيقات والمنصات، وفحصها جميعًا يتطلب تغطية بالأدوات لأنواع متنوعة من الأنظمة، واستثمارًا تشغيليًا لإدارة النتائج ودفع المعالجة. وتطبّق معظم المؤسسات برامج اكتشاف تغطي الأنظمة المعروفة عالية المخاطر، مع فجوات كبيرة في الأنظمة الأقل ظهورًا التي تراكمت فيها البيانات الحساسة عرضًا.
بالنسبة لبرامج TPRM، يتمثل النهج العملي للحوكمة في سؤال الموردين تحديدًا عن نطاق برنامج الاكتشاف لديهم، أي ما إذا كان يمتد إلى ما بعد قواعد البيانات الرئيسية ليشمل أنظمة الدعم ومنصات التعاون وبيئات التطوير، وما إذا كانت نتائج الاكتشاف تُحال إلى عملية معالجة بدلًا من الاكتفاء بإصدار تقرير. فنطاق برنامج الاكتشاف يحدد ما يعرفه المورد عن مشهد بياناته الحساسة، والفجوات في ذلك النطاق تحدد ما لا يعرفه.
- اسأل عن نطاق برنامج الاكتشاف: ما الأنظمة المشمولة، وتحديدًا ما إذا كانت بيئات الدعم والتعاون والتطوير مغطاة
- اسأل عن وتيرة الاكتشاف: مدى تكرار إعادة الفحص، وما إذا كانت الأنظمة الجديدة تخضع للاكتشاف قبل استخدامها
- اسأل عن إدارة البيانات الحساسة في أنظمة الدعم: ما إذا كان DLP أو ما يعادله مطبقًا على منصات دعم العملاء
- اسأل عن فحص بيئات التطوير: ما إذا كانت البيئات غير الإنتاجية التي تحتوي على بيانات العملاء ضمن نطاق الاكتشاف
- اشترط توسيع برنامج الاكتشاف للموردين الذين لديهم فجوات معروفة في القنوات عالية المخاطر
إذا كنت فريقًا صغيرًا
أضف سؤالًا واحدًا إلى تقييم الموردين لديك يكشف فجوة نطاق الاكتشاف على الفور: هل يغطي فحص اكتشاف البيانات الحساسة لديكم نظام تذاكر دعم العملاء ومرفقاته، ومتى اكتمل آخر فحص لذلك النظام؟ يركّز هذا السؤال على أعلى قنوات التراكم العرضي للبيانات الحساسة خطورة، ويميّز فورًا بين الموردين ذوي برامج الاكتشاف الشاملة ومن تنتهي تغطية الاكتشاف لديهم عند قواعد بيانات التطبيقات الرئيسية.
- اسأل عمّا إذا كانت مرفقات أنظمة الدعم مشمولة في فحص اكتشاف البيانات الحساسة
- اسأل متى أُجري آخر فحص للاكتشاف وما أهم نتيجة أسفر عنها
- اسأل عمّا إذا كانت منصات التعاون ضمن نطاق الاكتشاف
- اسأل عمّا يحدث للبيانات الحساسة المكتشفة في الأنظمة غير المصنفة: معالجة أم مجرد إبلاغ
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
«هل يفحص برنامج اكتشاف البيانات الحساسة لديكم نظام تذاكر دعم العملاء والملفات المرفقة به، ومتى أُجري آخر فحص لذلك النظام، وما فئات البيانات الحساسة التي عُثر عليها؟»
«ما نطاق برنامج اكتشاف البيانات الحساسة لديكم، وتحديدًا: هل يغطي منصات التعاون وأرشيفات البريد الإلكتروني وبيئات التطوير إضافةً إلى قواعد بيانات التطبيقات الرئيسية؟»
«عند اكتشاف بيانات حساسة في نظام غير مصنف أو غير خاضع للحوكمة، ما عملية المعالجة لديكم، وهل يمكنكم وصف مثال حديث لبيانات حساسة اكتُشفت خارج نطاق الحوكمة الرئيسي لديكم؟»
ما تتوقعه دليلًا
- توثيق نطاق برنامج الاكتشاف: جميع الأنظمة المشمولة مع تأكيد محدد لتغطية منصات الدعم والتعاون
- ملخص نتائج أحدث فحص اكتشاف لأنظمة الدعم
- توثيق عملية المعالجة للبيانات الحساسة المكتشفة خارج النطاق
- تأكيد وتيرة الاكتشاف: مدى تكرار إعادة الفحص
المورد الذي يجيب عن سؤال نظام الدعم بعبارة «أنظمتنا الرئيسية تخضع لحوكمة جيدة» يكون قد أكد الحوكمة على الأنظمة التي يعرفها. اسأله تحديدًا عمّا إذا كان قد أُجري يومًا فحص اكتشاف على نظام تذاكر الدعم لديه، وماذا وجد. فالإجابة عن هذا السؤال تبيّن ما إذا كان سيناريو الأربعة عشر ألف مرفق حساس سيناريو كان المورد سيكتشفه، أم سيناريو ينتظر أن يُكتشف في تحقيق في اختراق.
كيف تُثبت ذلك
يشترط مبدأ المساءلة في GDPR أن يتمكن المتحكمون في البيانات والمعالجون من إثبات علمهم بالبيانات الشخصية التي يحتفظون بها. واكتشاف البيانات الحساسة هو الآلية التي تُنشئ هذا العلم فيما يتجاوز مستودعات البيانات المعروفة. ويتطلب إثبات العناية الواجبة أدلة على أن نطاق برنامج الاكتشاف قد غطى الأنظمة التي تتراكم فيها البيانات الحساسة عرضًا.
- سجلات تقييم الموردين التي توثق نطاق برنامج الاكتشاف بما في ذلك أنظمة الدعم والتعاون
- أدلة فحص الاكتشاف لأنظمة الدعم ومنصات التعاون
- أدلة المعالجة للبيانات الحساسة المكتشفة خارج نطاق الحوكمة الرئيسي
- توثيق وتيرة الاكتشاف
الخلاصة الرئيسية
لا تصل البيانات الحساسة عبر البوابة الأمامية للجمع المتعمد للبيانات فحسب، بل تصل عبر كل قناة يتبادل فيها العملاء والموظفون والأنظمة المعلومات: تذاكر الدعم، ومنصات التعاون، ومرفقات البريد الإلكتروني، وسجلات الأخطاء، وأدوات المطورين. وبرنامج الحوكمة المبني حول الجمع المتعمد للبيانات يغطي الأنظمة المصممة لذلك. أما البيانات الحساسة التي تراكمت عبر القنوات العرضية فلا يراها برنامج ينطلق من الجرد المعروف بدلًا من البحث عن التراكم غير المعروف. والاكتشاف هو خطوة الحوكمة التي تجعل غير المرئي مرئيًا. فما لا يعلم المورد أنه يحتفظ به لا يستطيع إخضاعه للحوكمة، وما لا يستطيع إخضاعه للحوكمة لا يستطيع حمايته.