9,300 مفتاح AWS مُسرّب ظلّ يعمل… و768 منها منحت سيطرة كاملة على حسابات شركات

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

768 مفتاحًا منحت سيطرة إدارية كاملة على حسابات شركات

من بين المفاتيح الفعّالة المرتبطة بحسابات شركات، نُسب 817 مفتاحًا إلى مؤسسات تجارية. وشملت هذه المجموعة:

• 526 مفتاحًا لحسابات AWS الجذرية (Root).
• 242 مفتاحًا لمستخدمين في IAM مرتبطين بسياسة AWS المسماة AdministratorAccess.
• 768 مفتاحًا إجمالًا منحت سيطرة إدارية كاملة على حساب AWS تابع لشركة.

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

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

Hugging Face كانت المصدر الأكبر منفردًا

سجلت منصة Hugging Face 8,482 حالة تعرض لمفاتيح AWS، لتصبح أكبر مصدر منفرد حدده التقرير. وقالت Truffle Security إن 17.9% من مفاتيح AWS التي عُثر عليها هناك كانت مفاتيح جذرية.

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

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

مفاتيح قديمة نادرًا ما جرى تدويرها

بلغ العمر الوسيط لبيانات الاعتماد التي أُبلغ عنها نحو 1,831 يومًا، أي ما يقارب خمس سنوات، بينما بلغ عمر أقدم مفتاح 17.4 سنة. ولم يكن لدى سوى 13.7% من الحالات مفتاح أحدث مرتبط بالمستخدم نفسه، ما يشير إلى أن معظم المفاتيح لم تُستبدل ضمن عملية تدوير منتظمة.

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

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

تنبيهات الميزانية كانت نادرة

تمكنت Truffle Security من قراءة معلومات الحسابات في 2,754 حسابًا، لكن 262 حسابًا فقط كانت لديه تنبيهات ميزانية مفعّلة في AWS.

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

ماذا تفعل إشعارات AWS، وما الذي لا تضمنه؟

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

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

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

ماذا ينبغي للمؤسسات أن تفعل بعد تسريب مفتاح AWS؟

1. إلغاء المفتاح أو تدويره فورًا

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

2. التخلص من مفاتيح الحسابات الجذرية

لا ينبغي استخدام مفاتيح مستخدم AWS الجذري للوصول البرمجي اليومي. احذف هذه المفاتيح وانقل أعباء العمل إلى هويات مُدارة بصلاحيات محددة وضيقة.

3. مراجعة الصلاحيات والملكية

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

4. التحقيق قبل الإلغاء وبعده

راجع نشاط المصادقة، وسجلات CloudTrail، وتغييرات IAM، والموارد التي أُنشئت حديثًا، والفوترة بحثًا عن سلوك مشبوه. فإلغاء المفتاح يوقف استخدامه لاحقًا، لكنه لا يثبت ما إذا كان قد استُخدم قبل إلغائه.

5. استبدال المفاتيح طويلة العمر بهويات مؤقتة

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

6. تفعيل تنبيهات الميزانية وتحديد مسار للاستجابة

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

الدرس الأوسع في أمن السحابة

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

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