إبطال الأسرار المكشوفة وتدويرها

بمجرد التأكد من تسرّب بيانات اعتماد، تصبح السرعة مهمة — وكذلك الترتيب. فقد يؤدي تعطيل المفتاح فجأة إلى تعطيل الإنتاج إذا لم تفهم أولًا ما يعتمد عليه.

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

تتمثل الخطوة الأولى عند تسرّب مفتاح وصول في تعطيله، لا حذفه. إذ يؤدي ضبط حالة المفتاح على Inactive إلى إيقاف عمله فورًا.

يتيح الاحتفاظ به (معطلًا) في الوقت الحالي ربطه جنائيًا بسجلات CloudTrail. ولا تحذفه إلا بعد اكتمال التحقيق.

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

يمنع تنفيذ الخطوات بهذا الترتيب حدوث انقطاع: إذ يصبح الاعتماد الجديد فعالًا قبل إيقاف القديم. احرص دائمًا على التحقق من عمل التطبيق باستخدام المفتاح الجديد أولًا.

لا يؤدي تعطيل مفتاح طويل الأجل إلى إنهاء بيانات الاعتماد المؤقتة التي ربما أنشأها بالفعل. وبالنسبة إلى الأدوار، استخدم ميزة IAM المسماة revoke sessions، التي ترفق سياسة رفض تستند إلى وقت قطع إصدار الرموز.

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

قبل التدوير، اعرف مكان وجود السر. يوضح CloudTrail الخدمات وعناوين IP التي استخدمت المفتاح.

إن تضمين سر داخل التعليمات البرمجية في أماكن كثيرة يوضح تحديدًا سبب خطورة هذا الأسلوب. ويضمن تحديد كل مستخدم للمفتاح ألا يؤدي التدوير إلى ترك نظام منسي معطلًا أو إبقاء نسخة من السر قيد الاستخدام.

يخزن AWS Secrets Manager الأسرار مثل كلمات مرور قواعد البيانات ومفاتيح API، ويمكنه تدويرها تلقائيًا وفق جدول زمني باستخدام وظيفة Lambda.

يعني التدوير التلقائي أن السر المتسرّب يظل مفيدًا لفترة قصيرة، وأن التطبيقات تجلب القيمة الحالية وقت التشغيل بدلًا من الاحتفاظ بنسخة قديمة مضمنة في التعليمات البرمجية.

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

دوّر الأسرار التابعة كذلك. فكّر في السلسلة كاملة: يجب اعتبار كل سر كان بإمكان المهاجم الوصول إليه مكشوفًا واستبداله.

إذا اكتشفت AWS انكشافًا، فقد ترفق AWSCompromisedKeyQuarantineV2 بالمستخدم، فترفض الإجراءات عالية الخطورة مع إبقائك قادرًا على التحقيق.

لا تكتفِ بفصلها والمتابعة. تعامل معها باعتبارها إشارة إلى أن المعالجة الفعلية — التعطيل والتدوير والمراجعة — لا تزال بحاجة إلى أن تنفذها بنفسك.

يوقف التدوير إساءة الاستخدام المستقبلية، لكنه لا يلغي الضرر السابق. استخدم CloudTrail لسرد كل إجراء نفذته بيانات الاعتماد المخترقة.

تراجع عن التغييرات الخبيثة: احذف مستخدمي IAM غير المصرح بهم، وأزل مفاتيح الوصول الخلفية، وأوقف الموارد التي أنشأها المهاجم. فالاحتواء والتنظيف خطوتان منفصلتان وضروريتان.

بعد التعافي، قلّل المخاطر المستقبلية. استبدل المفاتيح طويلة الأجل ببيانات اعتماد مؤقتة قائمة على الأدوار، وفعّل التدوير التلقائي للأسرار، وأضف فحص الأسرار إلى مسار CI/CD لديك.

أقوى إصلاح هو الإصلاح المعماري: إذا لم يوجد سر ثابت يمكن تسرّبه، فلن يجد المهاجم شيئًا.

لا تكتمل المعالجة حتى تُسجّل. وثّق بيانات الاعتماد التي دُوّرت، وما فعله المهاجم، وما تم التراجع عنه.

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

اختر الإجراء الأول الصحيح.

للمعالجة بعد تسرّب بيانات اعتماد، قم بتعطيل مفتاح الوصول (مع الاحتفاظ به لأغراض التحليل الجنائي)، ثم بتدويره إلى مفتاح جديد من دون انقطاع، وبإبطال جلسات الأدوار النشطة لإنهاء بيانات الاعتماد المؤقتة التي تم إصدارها مسبقًا. حدّد أولًا جميع المستهلكين، ثم دوّر الأسرار التابعة التي ربما وصل إليها المهاجم، وتراجع عن التغييرات الخبيثة المسجّلة في CloudTrail. استخدم Secrets Manager للتدوير التلقائي، وانتقل إلى بيانات اعتماد مؤقتة قائمة على الأدوار لمنع تكرار الحادثة.