لماذا لا يتوقف المفتاح فورًا؟

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

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

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

لماذا تمثل هذه الفجوة خطرًا حقيقيًا؟

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

خلال هذه النافذة يمكن للمهاجم الذي يمتلك المفتاح المسرب أن:

• يواصل الوصول إلى واجهات API المرتبطة بالمشروع
• يرسل طلبات إضافية إلى الخدمات
• يسبب استهلاكًا سحابيًا غير متوقع أو فواتير أعلى

أكد الباحثون أنهم لاحظوا هذا السلوك مع مفاتيح مرتبطة بخدمة Gemini الخاصة بالذكاء الاصطناعي، وكذلك مع خدمات أخرى مثل BigQuery وGoogle Maps. ويبدو أن المشكلة مرتبطة بنوع بيانات الاعتماد نفسه (API key) وليس بخدمة معينة.

كيف كان رد Google؟

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

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

ويرتبط السبب التقني الأساسي بانتشار تحديثات الإلغاء تدريجيًا عبر البنية التحتية، ما يجعل توقيت التعطيل النهائي يعتمد على الخوادم التي تتعامل مع الطلبات.

ما الذي يجب على المطورين فعله الآن؟

إلى أن يتم ضمان الإلغاء الفوري، من الأفضل التعامل مع حذف المفاتيح باعتباره خطوة احتواء وليست حلًا فوريًا.

اعتبر الحذف عملية متأخرة التأثير
قد تستمر المخاطر لمدة تصل إلى نحو 30 دقيقة بعد حذف المفتاح.

راقب السجلات والاستهلاك السحابي
أي نشاط API غير متوقع أو ارتفاع مفاجئ في الاستخدام بعد الحذف قد يشير إلى استمرار استغلال المفتاح خلال نافذة الانتشار.

قيّد استخدام مفاتيح API قدر الإمكان
توصي Google بتقييد المفاتيح عبر تحديد عناوين IP المسموح بها أو المواقع أو APIs المحددة لتقليل الأضرار في حال تسربها.

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

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

تكشف هذه الحالة حقيقة مهمة في الأنظمة الموزعة الكبيرة: التغييرات في الإعدادات الحساسة — مثل إلغاء بيانات الاعتماد — لا تُطبق دائمًا بشكل فوري على جميع المكونات.

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

لماذا لا يتوقف المفتاح فورًا؟

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

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

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

لماذا تمثل هذه الفجوة خطرًا حقيقيًا؟

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

خلال هذه النافذة يمكن للمهاجم الذي يمتلك المفتاح المسرب أن:

• يواصل الوصول إلى واجهات API المرتبطة بالمشروع
• يرسل طلبات إضافية إلى الخدمات
• يسبب استهلاكًا سحابيًا غير متوقع أو فواتير أعلى

أكد الباحثون أنهم لاحظوا هذا السلوك مع مفاتيح مرتبطة بخدمة Gemini الخاصة بالذكاء الاصطناعي، وكذلك مع خدمات أخرى مثل BigQuery وGoogle Maps. ويبدو أن المشكلة مرتبطة بنوع بيانات الاعتماد نفسه (API key) وليس بخدمة معينة.

كيف كان رد Google؟

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

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

ويرتبط السبب التقني الأساسي بانتشار تحديثات الإلغاء تدريجيًا عبر البنية التحتية، ما يجعل توقيت التعطيل النهائي يعتمد على الخوادم التي تتعامل مع الطلبات.

ما الذي يجب على المطورين فعله الآن؟

إلى أن يتم ضمان الإلغاء الفوري، من الأفضل التعامل مع حذف المفاتيح باعتباره خطوة احتواء وليست حلًا فوريًا.

اعتبر الحذف عملية متأخرة التأثير
قد تستمر المخاطر لمدة تصل إلى نحو 30 دقيقة بعد حذف المفتاح.

راقب السجلات والاستهلاك السحابي
أي نشاط API غير متوقع أو ارتفاع مفاجئ في الاستخدام بعد الحذف قد يشير إلى استمرار استغلال المفتاح خلال نافذة الانتشار.

قيّد استخدام مفاتيح API قدر الإمكان
توصي Google بتقييد المفاتيح عبر تحديد عناوين IP المسموح بها أو المواقع أو APIs المحددة لتقليل الأضرار في حال تسربها.

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

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

تكشف هذه الحالة حقيقة مهمة في الأنظمة الموزعة الكبيرة: التغييرات في الإعدادات الحساسة — مثل إلغاء بيانات الاعتماد — لا تُطبق دائمًا بشكل فوري على جميع المكونات.

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