كيف تتم حماية بيانات الهوية؟
إجابة موجزة: تحدّد Cyber Crucible المواقع التي تُخزَّن فيها بيانات الهوية وتحمي تلك المواقع على مستوى النواة (kernel). عندما يحاول أحد البرامج الوصول إلى إحداها، يُتتبَّع وصوله ويُحلَّل — دون الوصول إلى كلمات المرور أو الرموز المميزة (tokens) أو مفاتيح التشفير نفسها أو جمعها على الإطلاق. وبناءً على هذا التحليل، يُسمح للبرنامج بالوصول، أو يُعطى بيانات مزيفة، أو يُرفض، أو يُعلَّق.
حماية الوصول، لا حماية السر نفسه
تعمل معظم حلول حماية الهوية على السر نفسه: تشفيره، أو تخزينه في خزنة، أو مراقبة ظهوره في تسريب بيانات. أما Cyber Crucible فتعمل على فعل السعي للوصول إليه.
الهجمات الآلية يمكن التنبؤ بها بطريقة محددة واحدة — إذ يجب أن تذهب إلى مواقع معروفة للعثور على بيانات الاعتماد. فمخازن ملفات تعريف الارتباط الخاصة بالمتصفح، ومسارات بيانات اعتماد VPN، ومخزن بيانات الاعتماد في Windows، وملفات المحافظ، وبيانات Active Directory، جميعها موجودة في أماكن يعرفها المهاجمون مسبقاً. وهذا القابلية للتنبؤ هي الفرصة الدفاعية.
تحدّد Cyber Crucible مخازن بيانات الهوية تلك ثم تحميها. ويُقيَّم أي برنامج يلمس أحدها، إلى جانب العمليات الأصلية والفرعية له والمكتبات التي حمّلها.
لا يتم قراءة الأسرار مطلقاً
هذا قيد تصميمي متعمد وليس أثراً جانبياً: يُتتبَّع الوصول ويُحلَّل دون الوصول إلى بيانات الاعتماد نفسها. لا تقوم Cyber Crucible بقراءة كلمات المرور أو رموز الجلسات أو ملفات تعريف الارتباط أو مفاتيح التشفير أو معالجتها أو جمعها أو نقلها — إلى أي خادم، سواء كان مستضافاً من قِبل Cyber Crucible أو من قِبل العميل.
اتضح أن التحليل السلوكي للوصول إلى الهوية لا يتطلب بيانات الهوية نفسها. فما يهم هو أي برنامج يصل إلى أين، وفي أي سياق، وماذا فعل قبل ذلك — ولا شيء من هذا يتطلب فتح السر.
والنتيجة هي أن آلية الحماية نفسها لا يمكن أن تصبح مصدر الاختراق، ولا يوجد مخزن مركزي لبيانات اعتمادك يمكن استدعاؤه قضائياً أو تسريبه أو فقدانه.
ما الذي يقيّمه المحرك السلوكي
القرار ليس "هل هذا البرنامج مدرج في قائمة؟" — بل "ماذا يفعل هذا الكود فعلياً الآن؟" وتشمل الإشارات:
- حالة الذاكرة وسلوكها — تُتبَّع عبر دورة حياة البرنامج بأكملها، بما في ذلك التغييرات في الذاكرة التي لا تصل أبداً إلى القرص. هذه هي طبقة الاستشعار الأساسية للمنصة، وهي مشتركة مع حماية البيانات و FortressAI وليست خاصة بالهوية فقط.
- نسب العمليات (Process lineage) — ما الذي أطلق هذه العملية، وما الذي أطلقته هي بدورها.
- نمط الوصول — هل هذا تطبيق عادي يقرأ بيانات اعتماده الخاصة، أم عملية مسح واسعة عبر مواقع هوية متعددة في آن واحد؟
- نشاط المكتبات والحقن (Injection) — هل تم حقن شيء في هذه العملية الموثوقة أو تغييرها في الذاكرة؟
الاستجابة متدرجة، لا ثنائية
ليس كل برنامج يسعى للوصول إلى بيانات الهوية مهاجماً، لذا تعتمد الاستجابة على طبيعة البرنامج وسلوكه:
| الحالة | الاستجابة |
|---|---|
| تطبيق معروف، غير مُستغَل، يصل إلى ما يحتاجه فعلياً | مسموح |
| تطبيق معروف، غير مُستغَل، لكنه يتجاوز نطاق وصوله المناسب | يُعطى بيانات مزيفة، أو يُرفض الوصول — وفقاً لقواعد الخصوصية السلوكية |
| تطبيق غير معروف | يُرفض أو يُعلَّق، وفقاً للمحرك السلوكي وإعداداتك |
| تطبيق مُخترَق — تم استغلال عملياته أو مكتباته | يُرفض أو يُعلَّق، وفقاً للمحرك السلوكي وإعداداتك |
الحالة الوسطى أهم مما تبدو للوهلة الأولى. فالكثير من البرمجيات المشروعة تصل إلى مخازن الهوية بشكل أعمق مما تحتاجه فعلياً. وتعليق هذه البرمجيات سيعطل عمل المستخدم دون أي فائدة أمنية — لكن منحها بيانات اعتماد حقيقية يمثل تعرّضاً غير ضروري. وإرجاع بيانات مزيفة يُرضي البرنامج بينما يبقى السر الحقيقي في مكانه.
التمييز الذي يقوم به المحرك هو بين برنامج موثوق يتجاوز حدوده وبرنامج غير معروف أو تم الاستيلاء عليه. فقط الحالة الأخيرة تُعامَل كهجوم.
لماذا يحدث هذا على الجهاز الطرفي (endpoint)
يمكن لأداة سرقة معلومات آلية أن تتسلل وتجمع البيانات وتحذف أدواتها الخاصة العاملة في الذاكرة خلال ثوانٍ. وإرسال بيانات القياس إلى خدمة سحابية وانتظار حكم منها لا يمكن أن يواكب هذه السرعة. لذا تعمل حلقة الكشف-القرار-الاستجابة (detect-decide-respond) الكاملة محلياً في النواة، وهذا أيضاً هو سبب عملها دون أي اتصال بالشبكة على الإطلاق.
راجع أيضاً: "هل تجمعون أياً من بيانات الهوية؟"، و*"ما بيانات الهوية المحمية؟"، و"ماذا يحدث عندما يحاول برنامج الوصول إلى بيانات هوية لا ينبغي له الوصول إليها؟"*