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

لوحة سحابية مجردة مع مفتاح مكشوف وشريط حجر وقائمة تدوير للمفاتيح

قالت Truffle Security إنها جمعت 431,875 نتيجة مؤكدة لأسرار AWS، ثم خفضتها إلى 64,024 access keys فريدة عبر 50,654 حساباً. بعد ذلك أعادت اختبار 10,616 زوجاً كاملاً من المفاتيح ظهر للعامة بين أغسطس 2022 وأغسطس 2026. النتيجة: 88% ما زالت تقبل المصادقة. من 9,308 مفاتيح نشطة، صُنفت 817 كمفاتيح مرتبطة بأعمال، و768 منها أعطت سيطرة كاملة على حساب AWS شركة: 526 root keys و242 مستخدم IAM مع AdministratorAccess.

غطت BleepingComputer وThe Register وTNW القصة سريعاً. ركز Corey Quinn في The Register على AWSCompromisedKeyQuarantineV3. تصف AWS هذه السياسة بأنها تحد من بعض الأضرار المرتبطة بالاحتيال من دون التأثير في الموارد القائمة. لكن النقطة الأساسية أن الحجر ليس علاجاً كاملاً. قد يقلل إساءة استخدام واضحة، لكنه لا يعني أن الحساب آمن.

هذه قصة مناسبة للأمن بلا هلع لأن العلاج عملي. root access keys يجب أن تكون نادرة جداً. مفاتيح IAM طويلة العمر تحتاج مالكاً ومدة حياة وتدويراً. السر الذي يدخل Git history أو Docker image أو CI log أو notebook أو dataset يجب اعتباره منشوراً. وquarantine policy يجب أن تبدأ الاستجابة للحادث، لا أن تنهيها.

ما الذي وُجد

الرقم 431,875 يتضمن تكرارات كثيرة في forks وmirrors وlogs وimages وdatasets. الأهم هو 64,024 مفتاحاً فريداً، ثم 10,616 زوجاً كاملاً أعيد اختبارها في 10 أغسطس 2026. من بينها 9,308 كانت ما تزال تعمل.

الجزء المرتبط بالشركات أصغر لكنه أخطر. 817 مفتاحاً نشطاً ارتبطت بأعمال، و768 امتلكت سيطرة إدارية كاملة. ومن بينها 130 root keys حية على organization management accounts. هذا ليس مجرد سر تطوير منسي؛ قد يكون المفتاح الرئيسي لمنظومة سحابية كاملة.

العمر يزيد الخطر. ذكرت Truffle Security أن العمر الوسيط للمفتاح المسرّب الذي ما زال يعمل هو 1,831 يوماً. كثير من credentials كانت عامة لسنوات. كما أن 13.7% فقط من الحالات كان لديها مفتاح أحدث بجانب المفتاح المسرّب. هذا يشير إلى استمرار استخدام القديم لا إلى تدوير ناجح.

ظهر Hugging Face في البحث كمصدر كبير للمفاتيح داخل datasets عامة. لا ينبغي صياغة ذلك كاختراق جديد لـHugging Face. المعنى الأدق أن datasets وnotebooks وmodel repositories ترث مشكلة مستودعات البرمجيات: الناس يرفعون artefacts قد تحتوي credentials.

لماذا root key أخطر

مفتاح IAM قد يكون خطيراً. أما root access key فهو أخطر. root user يمثل حساب AWS نفسه. وتوصي وثائق AWS بحماية root credentials، وتجنب استخدام root في العمل اليومي، والاعتماد على IAM Identity Center وroles وtemporary credentials.

الفارق هو النطاق. يمكن تقييد IAM identity بصلاحيات وشروط وسياسات. أما root فيقف فوق جزء كبير من هذه البنية. إذا تسرّب root key، فالمشكلة تشمل billing وaccount settings وrecovery paths وربما organization management account.

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

برنامج cloud ناضج يجب أن يعرف دائماً: هل توجد root access keys؟ من وافق عليها؟ متى ستُحذف؟ إذا كان الجواب “لا نعرف”، فلا توجد سيطرة حقيقية.

حذف سطر لا يكفي

قاعدة secret scanning الأساسية لا تزال تُنسى: إذا وصل credential إلى artefact عام، فافترض أنه نُسخ. حذفه من آخر commit لا يمحو Git history. إغلاق مستودع لا يمحو forks وmirrors وpackage caches وDocker layers وCI logs وnotebooks وsearch indexes وdatasets.

لذلك يجب التعامل مع AWS key مسرّب مثل كلمة مرور منشورة. يجب تدويره أو حذفه، والتحقيق في استخدامه، وفحص workloads التي تعتمد عليه. وإذا كان root أو AdministratorAccess، يجب فحص CloudTrail وbilling وsecret inventory والبحث عن persistence أو privilege escalation.

يتعلم بعض المطورين الدرس الخطأ: “حذفت السطر”. الدرس الصحيح: “السطر كشف credential يجب استبداله”. هذا الفرق بين تنظيف ملف وإغلاق وصول.

Docker images وML datasets تجعل الأمر أصعب. قد يبقى المفتاح في image layer قديم، أو output cell في notebook، أو debug log، أو benchmark corpus، أو ملف ZIP. إدارة الأسرار الحديثة يجب أن تفحص أكثر من repository الرئيسي.

ماذا يعني حجر AWS

AWSCompromisedKeyQuarantineV3 هي AWS managed policy. تقول الوثائق إنها تُستخدم عندما تكون IAM credentials compromised أو exposed publicly، وتمنع أفعالاً معينة للحد من fraud-related damage من دون التأثير في existing resources.

هذه العبارة الأخيرة مهمة. هذا harm reduction وليس remediation. المفتاح الموضوع في quarantine هو إشارة حادث. لا يثبت أن الحساب آمن. إذا كانت السياسة مصممة حتى لا تكسر الموارد القائمة، فقد تستمر بعض المسارات القائمة.

انتقاد Corey Quinn يركز على residual risk: عمليات قواعد بيانات، جلسات إدارة، AssumeRole، تعطيل سجلات، إساءة استخدام رسائل، قراءة أسرار، backups وتغييرات بنية. لا حاجة لتحويل ذلك إلى دليل هجومي. الخلاصة الدفاعية تكفي: quarantine is a temporary guardrail, not incident closure.

المفاضلة حقيقية. إذا أغلقت AWS كل مفتاح عام تلقائياً، قد تكسر إنتاج العملاء. وإذا تركته يقبل المصادقة، تتجنب outage لكنها تبقي exposure. لذلك تحتاج المؤسسات playbook سريعاً للتدوير.

ما الذي يجب فحصه اليوم

ابدأ بـroot. في كل حساب AWS، تحقق من وجود root access keys. إذا وجدت، حدد السبب والمالك وآخر استخدام وتاريخ الحذف. الحالة المستهدفة لمعظم الشركات هي عدم وجود root keys. ويجب حماية root user بـMFA واستخدامه فقط للمهام النادرة.

أنشئ inventory لكل IAM access keys. رتبها حسب العمر، وآخر استخدام، والمالك، وworkload، ومستوى الصلاحيات. AdministratorAccess، والصلاحيات الواسعة، وعدم وجود مالك، وعدم وجود تدوير، كلها أولوية.

ابحث عن AWSCompromisedKeyQuarantine attachments. إذا وضعت AWS الحجر، تعامل معه كـincident signal. اعثر على credential، دوّره، احذف القديم، وافحص CloudTrail وbilling وbudget anomalies وAssumeRole paths.

افحص أكثر من الكود: Git history، forks، public registries، container images، build logs، CI variables، notebooks، support bundles، public datasets وmodel repositories. الأسرار تعيش الآن في data artifacts أيضاً.

استبدل static credentials حيث أمكن. في CI/CD استخدم OIDC federation وshort-lived role assumption. للبشر استخدم IAM Identity Center أو federation. للأعمال استخدم scoped roles. مفاتيح legacy يجب أن يكون لها owner وexpiry وmonitoring.

التدوير من دون كسر الإنتاج

الخوف من outage يفسر بقاء مفاتيح كثيرة. حذف مفتاح مجهول قد يكسر build system أو backup job أو data pipeline أو خدمة قديمة. الحل ليس تركه إلى الأبد، بل rotation with evidence.

حدد أولاً principal والخدمات المستخدمة. CloudTrail وIAM last-accessed data وapplication logs وcost anomalies تساعد. ثم ابحث عن المالك، وأنشئ replacement path بصلاحيات أضيق، وانشره مع monitoring، ثم احذف المفتاح القديم. إذا تعذر الحذف فوراً، يجب أن يكون الاستثناء محدود الزمن وله مالك.

مع root وAdministratorAccess، افترض احتمال استخدام طرف آخر. افحص recent API activity وsecret access وrole assumptions وsecurity-group changes وbucket policies وbackup operations وIAM changes وunusual spend. فعّل budget alerts وcost anomaly detection.

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

الخلاصة الهادئة

لا يعني البحث أن كل حساب AWS مخترق. ولا يعني أن AWS quarantine بلا فائدة، ولا أن حذف مفاتيح عشوائياً هو الحل. الهلع يكسر الإنتاج؛ والإنكار يصنع الحوادث.

الرد المتوازن: اعتبر كل public credential compromised، احذف root keys، استبدل long-lived IAM keys بـroles وfederation، افحص artefacts الحقيقية، تعامل مع quarantine كحادث، مارس rotation، وفعّل billing alarms.

الجزء المزعج أن cloud access يفشل بصمت. يتسرّب مفتاح، يطلق scanner تنبيهاً، يحد provider بعض الأفعال، يحذف شخص سطراً، ثم يستمر الجميع. لكن credential ما زال يقبل المصادقة. العلاج هو ownership وinventory وshort-lived credentials والانضباط التشغيلي.