دعوة لأمن البيانات أولاً

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

يجب أن تركز على البيانات. أولاً.

الحدود التالية في الأمان هي البيانات ، وخاصة البيانات الحساسة. البيانات الحساسة هي البيانات التي لا تريد مؤسسات البيانات أن ترى مسربة أو مخترقة. وهذا يشمل المعلومات الصحية المحمية ، ومعلومات تحديد الهوية الشخصية ، و PD والبيانات المالية. خرق البيانات الحساسة يحمل عقوبات حقيقية. بعضها ملموس ، مثل غرامات اللائحة العامة لحماية البيانات (10 مليون يورو أو 2٪ من الإيرادات السنوية) ، وغرامات لجنة التجارة الفيدرالية (مثل 150 مليون دولار ضد تويتر) والرسوم القانونية. ثم هناك تكاليف غير ملموسة ، مثل فقدان ثقة العملاء (على سبيل المثال ، كشف Chegg عن بيانات تخص 40 مليون مستخدم) ، وألم إعادة الهيكلة ، وأسوأ من ذلك.

>> لا تفوّت إصدارنا الخاص: أجندة CIO: خارطة طريق 2023 لقادة تكنولوجيا المعلومات. <

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

ماذا سيحدث إذا جعلت البيانات مركزًا لعالم الأمان؟

تعد البيانات واحدة من أثمن الأصول التي تريد المؤسسات حمايتها ، وتحدث انتهاكات هائلة للبيانات وتسرب البيانات في كثير من الأحيان. حان الوقت لتطور جديد للأمن السيبراني: أمن البيانات أولاً.

البيانات مختلفة

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

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

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

يجب أن يبدأ أمان البيانات أولاً في الكود. هذا يعني مع المطورين: التحول إلى اليسار. وفقًا لـ GitLab ، فإن 57 ٪ من فرق الأمن قد غيرت الأمن بالفعل أو يخططون لهذا العام. ابدأ في بداية الرحلة ، وقم بتأمين البيانات أثناء قيامك بالتشفير.

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

لذا يجب أن يشتمل نهج أمان البيانات أولاً على ثلاثة مكونات: 1) لا يمكن أن يكون مسؤولية أمنية أخرى ؛ 2) يجب أن يفهم سياق الملكية ؛ 3) يحمي من الأخطاء في منطق الأعمال المخصص (ليس كل خرق ينطوي على خطأ).

ليست مسؤولية أمنية أخرى

الأمن هو حول التخفيف من المخاطر. تتعارض إضافة أداة أو بائع جديد مع هذا المبدأ الأساسي. لدينا جميعًا SolarWinds في الاعتبار ، لكن البعض الآخر يظهر يوميًا. يعد امتلاك أداة جديدة تتكامل مع بيئة الإنتاج الخاصة بك طلبًا كبيرًا ، ليس فقط لفريق الأمان ، ولكن لفريق SRE / Ops. يعني إجراء اكتشاف البيانات على البنية التحتية للإنتاج النظر إلى القيم الفعلية وبيانات العملاء المحتملين – وهو ما نحاول حمايته في المقام الأول. ربما تكون أفضل طريقة لعدم التعرض لخطر آخر هي ببساطة عدم الوصول إلى البنى التحتية والبيانات الحساسة.

نظرًا لأن نهج أمان البيانات أولاً يعتمد على معرفة البيانات الحساسة ، فقد يكون من المفاجئ أن تكون قادرًا على تنفيذ هذا الاكتشاف فقط من قاعدة التعليمات البرمجية – خاصةً عندما نستخدم حلول DLP وإدارة وضع أمان البيانات (DSPM) التي تنفذ الاكتشاف على بيانات الإنتاج. صحيح أنه في قاعدة الكود ليس لدينا وصول إلى البيانات الفعلية (القيم) ، فقط البيانات الوصفية. ولكن من المثير للاهتمام ، أنه من الدقة أيضًا اكتشاف البيانات الحساسة بهذه الطريقة. وبالفعل ، فإن الافتقار إلى الوصول إلى القيم يقابله الوصول إلى قدر هائل من السياقات ، وهو أمر أساسي للتصنيف.

على الرغم من أهمية الأمان التقليدي في التحول إلى اليسار ، فإن نهج أمان البيانات أولاً يوفر قيمة أكبر عندما يتعلق الأمر بعدم كونه خطرًا آخر على المؤسسة.

سياق الملكية

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

لماذا نقوم بتخزين هذه البيانات؟ ما هو سبب العمل لمشاركة هذه البيانات مع هذا الطرف الثالث؟ هذه أسئلة يجب على المنظمات الإجابة عليها في مرحلة معينة. يتم التعامل مع هذه الأسئلة اليوم بشكل متزايد من قبل فرق الأمان ، لا سيما في بيئات السحابة الأصلية. إن الرد عليها وتحديد المخاطر المرتبطة بها يكاد يكون مستحيلاً دون الكشف عن “الملكية”.

من خلال القيام بأمان البيانات أولاً من وجهة نظر الكود ، لدينا وصول مباشر إلى المعلومات السياقية الضخمة – على وجه الخصوص ، متى شيء ما تم تقديمه وبواسطة مَن. لا تستطيع حلول DSPM ببساطة توفير هذا السياق من خلال النظر حصريًا إلى مخازن بيانات الإنتاج.

في كثير من الأحيان تعتمد المنظمات على “التقييم اليدوي”. يرسلون استبيانات إلى الفريق الهندسي بأكمله لفهم البيانات الحساسة التي تتم معالجتها ولماذا وكيف. يكره المطورون هذه الاستبيانات وغالبًا لا يفهمون الكثير من الأسئلة. يمكن التنبؤ بنتائج أمان البيانات السيئة.

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

منطق عمل مخصص

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

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

لكن هل الكود كافٍ؟

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

يعد التوفيق بين المعلومات بين الكود والإنتاج أمرًا صعبًا للغاية ، خاصة مع تدفق أصول البيانات في كل مكان. يُظهر Airbnb مدى التعقيد الذي يمكن أن يكون عليه. والخبر السار هو أنه مع التحول إلى البنية التحتية كرمز (IaC) ، يمكننا إجراء الاتصالات على مستوى الكود وتجنب التعامل مع التسوية المؤلمة.

بالنظر إلى التحديات المرتبطة بالأمان والبيانات ، يجب أن يصبح كل حل أمني على الأقل “مدركًا للبيانات” وربما “البيانات أولاً” في أي طبقة من المكدس الموجودة فيها. يمكننا بالفعل رؤية إدارة وضع أمان السحابة (CSPM ) حلول تمتزج مع DSPM ، لكن هل ستكون كافية؟

غيوم مونتارد هو الشريك المؤسس والرئيس التنفيذي لشركة Bearer.