الهويات غير البشرية أصبحت أكبر سطح هجوم غير مُدار في أمن السحابة

في بيئة السحابة المؤسسية النموذجية اليوم، تفوق الهويات الآلية — حسابات الخدمة، مفاتيح API، رموز OAuth، بيانات اعتماد CI/CD، وهويات أعباء العمل — حسابات المستخدمين البشرية بنسب تتراوح عادة بين 45:1 و90:1. أمضت فرق الأمن عقدين من الزمن في بناء إدارة الهوية والوصول حول البشر: الإدماج، إنهاء الخدمة، المصادقة متعددة العوامل، المراجعة الدورية للوصول. تقريبًا لا شيء من هذه البنية التحتية بُني للآلات، وهذا واضح. أصبحت الهويات غير البشرية (NHIs) بهدوء أكبر سطح هجوم غير مُدار في أمن السحابة، ومعظم المؤسسات لا تستطيع الإجابة على سؤال أساسي: كم عدد بيانات الاعتماد الآلية الموجودة في بيئتها، ومن أو ما الذي يملك كل واحدة منها، ومتى كانت آخر مرة استُخدمت فيها.

لماذا لا تغطي IAM التقليدية الآلات

تعتمد حوكمة الهوية البشرية على افتراضات لا تنطبق على الآلات. الشخص لديه مدير يمكنه أن يشهد على استمرار الحاجة. الشخص يحصل على مقابلة خروج وقائمة تحقق عند مغادرته. طلب الوصول للشخص يمر بدورة مراجعة. حسابات الخدمة، على النقيض، غالبًا ما تُنشأ بشكل مخصص من قبل مطور يجهّز خدمة مصغرة جديدة، وتُمنح صلاحيات واسعة لتجنب أخطاء الأذونات لاحقًا، ثم لا يُعاد النظر فيها أبدًا. بيانات الاعتماد تعيش أطول من المشروع، ومن المطور الذي أنشأها، وغالبًا من السبب الذي وُجدت من أجله أساسًا. اضرب هذا النمط عبر كل خط أنابيب CI/CD، وكل تكامل SaaS من طرف ثالث، وكل خدمة داخلية تستدعي خدمة داخلية أخرى، وستصبح مشكلة الجرد هائلة.

كيف تُخترق بيانات الاعتماد الآلية فعليًا

أنماط الاختراق متشابهة بشكل لافت في تقارير الحوادث. مفاتيح API طويلة العمر تُنشر في مستودعات GitHub العامة من قبل مطورين ينسون إضافتها إلى ملف .gitignore — الماسحات الآلية تجدها وتستغلها خلال دقائق من كشفها. حسابات الخدمة المفرطة في الصلاحيات، التي مُنحت وصولاً بمستوى المسؤول لأن ذلك كان أسرع من تحديد النطاق الصحيح للأذونات، تحول بيانات اعتماد واحدة مخترقة إلى وصول كامل للبيئة. رموز OAuth قديمة من تكامل SaaS أُوقف قبل ثمانية عشر شهرًا تظل صالحة لأن لا أحد ألغاها. وفي البيئات السحابية الأصلية، هويات أعباء العمل التي يجب أن تكون قصيرة العمر ومحددة بحاوية أو دالة واحدة، تُدمج بدلاً من ذلك في صور الحاويات كأسرار ثابتة طويلة العمر.

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

ما الذي يتغير فعليًا

ظهرت فئة جديدة من الأدوات الأمنية خصيصًا لمعالجة هذه الفجوة، حيث يبني بائعون بما في ذلك Astrix Security وEntro وOasis Security وToken Security منتجات تكتشف وتجرد وتراقب الهويات غير البشرية عبر بيئات السحابة وSaaS بطرق لم تُصمم أدوات IAM العامة للقيام بها أبدًا. تبدأ هذه المنصات عادةً ببناء جرد شامل — وهو شيء لم تمتلكه معظم المؤسسات من قبل — ثم تضيف تقييم المخاطر بناءً على مستوى الصلاحية وعمر بيانات الاعتماد وأنماط الاستخدام، وأخيرًا تعمل على أتمتة المعالجة مثل تدوير بيانات الاعتماد أو تحديد نطاق الوصول.

مزودو السحابة تحركوا أيضًا في هذا المجال. تقدم AWS وGoogle Cloud وAzure الآن جميعًا توحيد هوية أعباء العمل، الذي يسمح للخدمة بالمصادقة باستخدام رموز قصيرة العمر تُدار تلقائيًا ومرتبطة بهويتها الفعلية وقت التشغيل بدلاً من مفتاح ثابت طويل العمر. هذا يلغي فئة كاملة من المخاطر — بيانات الاعتماد الثابتة المسربة — بالتصميم، لكن التبني يتطلب إعادة هيكلة التكاملات القائمة، ولهذا كان الانتقال بطيئًا رغم توفر الأدوات منذ عدة سنوات.

ما الذي يجب أن تفعله فرق الأمن فعليًا

ابدأ بالاكتشاف، وليس المعالجة. لا يمكنك تأمين ما لا تراه، ومعظم المؤسسات تقلل من تقدير عدد الهويات غير البشرية لديها بدرجة كبيرة حتى تجري فحصًا مناسبًا عبر حسابات السحابة ووحدات تحكم إدارة SaaS وأنظمة CI/CD ومستودعات الكود المصدري. بمجرد حصولك على جرد، رتب الأولويات حسب نصف قطر الانفجار: بيانات اعتماد بوصول بمستوى المسؤول إلى السحابة أهم من مفتاح API للقراءة فقط لأداة داخلية منخفضة الحساسية، بغض النظر عن أيهما أقدم أو أكثر ظهورًا.

انتقل إلى بيانات الاعتماد قصيرة العمر حيثما يدعم المنصة ذلك — توحيد هوية أعباء العمل للمصادقة بين السحابات، ورموز OIDC لخطوط أنابيب CI/CD بدلاً من الأسرار الثابتة المخزنة في إعدادات خط الأنابيب. بالنسبة لبيانات الاعتماد التي يجب أن تبقى طويلة العمر، فرض التدوير وفق جدول زمني ثابت بدلاً من الاعتماد على تذكر شخص ما للقيام بذلك يدويًا، وحدد تواريخ انتهاء الصلاحية كقاعدة افتراضية وليس كاستثناء. أخيرًا، حدد الملكية. يجب أن تُربط كل بيانات اعتماد آلية بشخص أو فريق مسؤول عنها، بنفس الطريقة التي يُربط بها كل حساب بشري بموظف. بيانات الاعتماد غير المملوكة هي بيانات اعتماد لن يلاحظ أحد تقادمها، أو يعلّمها للاستخدام المشبوه، أو يفكر في إلغائها عندما يُوقف النظام الذي تخدمه — وهذه هي بالضبط الفجوة التي يستغلها المهاجمون حاليًا على نطاق واسع.