كتبت الشهر الماضي مقالة حول الطريقة التي تقدم بها الأنظمة الأساسية منخفضة الكود / بدون رمز مشاركة بيانات الاعتماد كخدمة ، ولماذا يفعلون ذلك ، وكيف يبدو هذا من منظور المهاجم. في هذه المقالة ، سأركز على الآثار المترتبة على هذا الحل الوسط وكيف يؤثر على المؤسسات اليوم.
إليك سبب اعتبار مشاركة بيانات اعتماد مؤسستك مع شخص آخر ممارسة سيئة. لنفترض أنني أرغب في تمرير بيانات الاعتماد الخاصة بي إلى زميل من أجل الاستعلام عن سجلات الإنتاج لتحليل سلوك المستخدم لمرة واحدة. في مؤسسة نموذجية ، قد يعني منح أذونات لشخص ما للاستعلام عن مصدر بيانات جديد عملية مراجعة وصول طويلة ، خاصة عندما يتعلق الأمر بالإنتاج أو البيانات الحساسة. يمكن أن يصاب زميلي بالإحباط بسهولة. "كل ما أردته هو إجراء هذا الاستعلام الصغير لمرة واحدة ، وقد كنت أنتظر بالفعل منذ شهر!" يمكنهم القول. يمكنني فقط تشغيل الاستعلام عنهم ، لكنني غارق في المهام اليومية الخاصة بي ، وتميل الاستعلامات التي تتم لمرة واحدة إلى التعقيد.
لدي حل سريع واحد: يمكنني فقط مشاركة اسم المستخدم / كلمة المرور الخاصة بي مع زميلي. إذا حصلوا على تحدي MFA ، فسأوافق عليها بكل سرور. لا يتعين علي قضاء الوقت في تشغيل الاستعلام ، ويتم إلغاء حظر زميلي. الجميع يفوز! حق؟
حسنًا ، ستكون محقًا في تحليلك ، لكنك تفتقد الصورة الأكبر. في حين أنه من المهم بالنسبة للمؤسسة أن يقوم زميلك بتحليل سلوك المستخدم الخاص به ، فمن المهم بنفس القدر ، إن لم يكن أكثر ، أن تظل مؤسستك متوافقة مع مجموعة كاملة من معايير الخصوصية والأمان وتحافظ على ثقة العملاء من خلال الحفاظ على التزام الشركة بالأمان .
إذا لم تقنعك أهداف المؤسسة عالية المستوى ، ففكر في فرق الإدارة المركزية في تكنولوجيا المعلومات أو الأمن. تبني هذه الفرق عملياتها واستراتيجياتها الأمنية على حقيقة أن لكل مستخدم هويته الفريدة. تقوم فرق تكنولوجيا المعلومات بإعداد سياسات الشبكات والوصول التي تفترض أن كل مستخدم سيتم تسجيل دخوله من عنوان IP خاص بشركة واحدة أو كمبيوتر محمول للشركة في وقت واحد ؛ تقوم فرق الأمان بربط الأحداث بناءً على معرف المستخدم ؛ يمكن أن تقوم فرق المالية بتجميع تقارير التكلفة لكل مستخدم وبيئة السحابة الشخصية الخاصة بهم. يقوض تقاسم الاعتماد كل هذه الافتراضات ، من بين أمور أخرى. إنه يزيل المعنى الأساسي للهوية عبر الإنترنت.
مثال من العالم الحقيقي
دعنا ننتقل إلى عالم الكود المنخفض / بدون رمز ونفحص سيناريو العالم الحقيقي. في مؤسسة كبيرة ، أدركت جين ، الموظف الملهم من فريق خدمة العملاء ، أنه عندما يشارك الموظفون عبر المؤسسة في حالة عميل ، فإنهم عادةً ما يفتقدون المعلومات الأساسية حول العميل ، مثل سجل حالة الدعم وأحدث عمليات الشراء. هذا يحط من تجربة العميل ، حيث يتعين عليهم شرح مشكلتهم مرارًا وتكرارًا أثناء توجيه القضية إلى الموظف المناسب الذي يمكنه معالجة المشكلة.
لتحسين ذلك ، أنشأت Jane تطبيقًا يسمح لموظفي الشركة بعرض هذه المعلومات الأساسية حول العملاء عندما يكون هؤلاء الموظفون جزءًا من الفريق المسؤول عن معالجة حالة دعم العميل. أولاً ، دعنا نتوقف لحظة للإقرار بقوة الرمز المنخفض / عدم وجود رمز ، والذي يسمح لجين بتحديد الحاجة ومعالجتها بنفسها ، دون طلب ميزانية أو انتظار تخصيص موارد تكنولوجيا المعلومات.
أثناء إنشاء التطبيق ، كان على Jane حل مشكلات متعددة ، أكبرها الأذونات. لا يتمتع الموظفون عبر المؤسسة بإمكانية الوصول المباشر للاستعلام عن قاعدة بيانات العملاء للحصول على المعلومات التي يحتاجون إليها. إذا فعلوا ذلك ، فلن تضطر جين إلى إنشاء هذا التطبيق. للتغلب على هذه المشكلة ، قامت Jane بتسجيل الدخول إلى قاعدة البيانات وتضمنت جلستها المصدق عليها مباشرة في التطبيق. عندما يتلقى التطبيق طلبًا من مستخدم واحد ، فسيستخدم هوية Jane لتنفيذ هذا الاستعلام ثم إرجاع النتائج إلى المستخدم. ميزة تضمين بيانات الاعتماد هذه ، كما اكتشفنا الشهر الماضي، هي ميزة أساسية للمنصات منخفضة الكود / بدون رمز. حرصت Jane على إعداد التحكم في الوصول المستند إلى الدور (RBAC) في التطبيق بحيث يمكن لكل مستخدم الوصول فقط إلى حالات العملاء التي تم تعيينهم لها.
حل التطبيق مشكلة تجارية مهمة ، وسرعان ما اكتسب اعتماد المستخدم عبر المؤسسة. كان الناس سعداء لأنهم يستطيعون تقديم خدمة أفضل لعملائهم من خلال توفير السياق المناسب للمحادثة. كان العملاء سعداء أيضًا. بعد شهر من إنشاء جين للتطبيق ، تم استخدامه بالفعل من قبل مئات المستخدمين في جميع أنحاء المؤسسة ، مع ارتفاع معدلات رضا العملاء.
في غضون ذلك ، تم تشغيل تنبيه شديد الخطورة يظهر نشاطًا غير طبيعي حول قاعدة بيانات عملاء الإنتاج في SOC ، وتم تعيينه إلى Amy ، محلل أمني متمرس. أظهر التحقيق الأولي لـ Amy أن مستخدمًا داخليًا كان يحاول كشط قاعدة البيانات بأكملها ، والاستعلام عن معلومات حول العديد من العملاء من عناوين IP متعددة عبر المؤسسة. كان نمط الاستعلام معقدًا للغاية ؛ بدلاً من نمط التعداد البسيط الذي تتوقع رؤيته عند كشط قاعدة البيانات ، تم الاستعلام عن بيانات العميل نفسه عدة مرات ، أحيانًا من خلال عناوين IP مختلفة وفي تواريخ مختلفة. هل يمكن أن يكون هذا مهاجمًا يحاول إرباك أنظمة المراقبة الأمنية؟
بعد تحقيق سريع ، كشفت إيمي عن جزء مهم من المعلومات: كل هذه الاستعلامات عبر جميع عناوين IP والتواريخ كانت تستخدم هوية مستخدم واحدة ، شخص اسمه جين من فريق خدمة العملاء.
تواصلت إيمي مع جين لتسألها عما يحدث. في البداية ، لم تعرف جين. هل سُرقت أوراق اعتمادها؟ هل نقرت على الرابط الخطأ أو تثق في البريد الإلكتروني الوارد الخطأ؟ ولكن عندما أخبرت جين إيمي عن التطبيق الذي بنته مؤخرًا ، أدرك كلاهما أنه قد يكون هناك اتصال. لم تكن إيمي ، محللة SOC ، على دراية بالرمز المنخفض / بدون رمز ، لذلك تواصلوا مع فريق AppSec. بمساعدة Jane ، اكتشف الفريق أن تطبيق Jane يحتوي على أوراق اعتماد Jane داخله. من منظور قاعدة البيانات ، لم يكن هناك تطبيق - كان هناك جين فقط ، ينفذ الكثير من الاستعلامات.
قررت Jane و Amy و AppSec إغلاق التطبيق حتى يتم العثور على حل. أصيب مستخدمو التطبيقات في جميع أنحاء المؤسسة بالإحباط لأنهم أصبحوا يعتمدون عليها ، وكان العملاء يشعرون بذلك أيضًا.
بينما أغلقت إيمي القضية ووثقت النتائج التي توصلوا إليها ، لم يكن نائب الرئيس لرعاية العملاء سعيدًا برؤية انخفاض معدل رضا العملاء ، لذلك طلبوا من جين البحث عن حل دائم. بمساعدة وثائق النظام الأساسي وفريق مركز التميز التابع للمؤسسة ، أزالت جين هويتها المضمنة من التطبيق ، وغيرت التطبيق لاستخدام هوية كل مستخدم للاستعلام عن قاعدة البيانات ، وتأكدت من حصول المستخدمين على أذونات فقط لحالات العملاء المرتبطة بهم . في نسخته الجديدة والمحسّنة ، استخدم التطبيق هوية كل مستخدم للاستعلام عن قاعدة بيانات العملاء. كانت جين ومستخدمي التطبيق سعداء بعودة التطبيق إلى الإنترنت ، وكانت إيمي وفريق AppSec سعداء لأن هوية جين لم تعد مشتركة ، وشهدت المؤسسة ارتفاع معدل رضا العملاء مرة أخرى. كل شيء بخير.
بعد أسبوعين ، تلقت SOC تنبيهًا آخر بشأن الوصول غير الطبيعي إلى قاعدة بيانات عملاء الإنتاج. بدا الأمر مشابهًا بشكل مثير للريبة للتنبيه السابق في نفس قاعدة البيانات. مرة أخرى ، كانت عناوين IP عبر المؤسسة تستخدم هوية مستخدم واحد للاستعلام عن قاعدة البيانات. مرة أخرى ، كان هذا المستخدم هو جين. لكن هذه المرة ، علم فريق الأمان وجين أن التطبيق يستخدم هويات مستخدميه. ماذا يحدث هنا؟
كشف التحقيق أن التطبيق الأصلي به المشتركة ضمنيًا جلسة قاعدة بيانات جين المصادق عليها مع مستخدمي التطبيق. من خلال مشاركة التطبيق مع مستخدم ، حصل هذا المستخدم على وصول مباشر إلى ملف صلة، عبارة عن غلاف حول جلسة قاعدة بيانات مصادق عليها مقدمة من النظام الأساسي ذي التعليمات البرمجية المنخفضة / بدون رمز. باستخدام هذا الاتصال ، يمكن للمستخدمين الاستفادة من جلسة المصادقة مباشرة - لم يعد عليهم المرور عبر التطبيق. اتضح أن العديد من المستخدمين قد اكتشفوا ذلك ، واعتقدوا أن هذا هو السلوك المقصود ، كانوا يستخدمون جلسة قاعدة بيانات Jane المصادق عليها لتشغيل استعلاماتهم. لقد أحبوا هذا الحل ، نظرًا لأن استخدام الاتصال مباشرة منحهم حق الوصول الكامل إلى قاعدة البيانات ، وليس فقط لحالات العملاء التي تم تعيينهم لها.
تم حذف الاتصال ، وانتهى الحادث. تواصل محلل SOC مع المستخدمين الذين استخدموا اتصال Jane للتأكد من تجاهلهم لأي بيانات خاصة بالعميل قاموا بتخزينها.
معالجة تحدي الأمان ذو التعليمات البرمجية المنخفضة / عدم وجود تعليمات برمجية
القصة أعلاه هي سيناريو واقعي من شركة B2C متعددة الجنسيات. تم حذف بعض التفاصيل أو تعديلها لحماية الخصوصية. لقد رأينا كيف يمكن للموظف حسن النية أن يشارك هويته عن غير قصد مع مستخدمين آخرين ، مما يتسبب في مجموعة كاملة من المشكلات عبر تكنولوجيا المعلومات والأمن والأعمال. كما اكتشفنا الشهر الماضي ، تعد مشاركة بيانات الاعتماد ميزة أساسية للرمز المنخفض / بدون رمز. إنها القاعدة وليس الاستثناء.
As يستمر رمز منخفض / لا رمز في الازدهار في المؤسسة ، بوعي أم بغير وعي، من الأهمية بمكان أن تنضم فرق الأمن وتكنولوجيا المعلومات إلى محادثة تطوير الأعمال. تأتي التطبيقات منخفضة الكود / بدون رمز بامتداد مجموعة فريدة من التحديات الأمنية، وطبيعتها الغزيرة تعني أن تلك التحديات تصبح حادة بشكل أسرع من أي وقت مضى.
