تبعات فجوة AuthN/AuthZ

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

أولاً، تمهيد موجز حول الفرق بين AuthN و AuthZ:

• AuthN تعني المصادقة. أي إثبات أنكم كيان معيّن. وبالنسبة إلينا نحن البشر العاديين، يكون ذلك عادةً باسم مستخدم وكلمة مرور وربما المصادقة متعددة العوامل.
• AuthZ تعني التخويل. أي التحقق مما إذا كان إجراء ما مسموحاً به. وفي السحابة من نوع IaaS، يرتبط ذلك دائماً تقريباً باستدعاء واجهة برمجة تطبيقات، حتى عند استخدام وحدة التحكم أو البوابة عبر الويب.

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

إذا فكرتم في الأمر، فبمجرد حصولكم على رمز الجلسة ذاك لا يعاد التحقق منه ما لم يفرض شيء في الشيفرة عملية تحقق جديدة. تظل مصادقتكم صالحة طوال الجلسة، وبالتالي يمكنكم تنفيذ أي شيء يقع ضمن نطاق تخويلاتكم. وبحسب المنصة أو النظام، ستظل بيانات الاعتماد المؤقتة تلك صالحة للعمل حتى لو جرى إبطالها أو حُذف الحساب بالكامل. هذه هي فجوة AuthN/AuthZ.

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

كيف تعالجون ذلك؟

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

• إضافة شروط لتقييد عنوان IP المصدر لاستدعاءات واجهة برمجة التطبيقات.
• رفض جميع الجلسات التي أنشئت قبل تاريخ أو وقت محدد.

من الأرجح أن تواجهوا هذه المسألة عند الاتحاد مع مزوّد سحابي أكثر من مواجهتها داخل المزوّد نفسه. لقد أجريت للتو اختباراً في AWS وفقدت الوصول في الجلسات المفتوحة بسرعة كبيرة بعد حذف مستخدم IAM. غير أن الأمر ليس كذلك بالضرورة عند الاتحاد من مزوّد هوية خارجي، بل وحتى داخل AWS لن تعيد بعض الخدمات التحقق من بيانات الاعتماد أثناء الجلسات النشطة (على سبيل المثال، ظلت جلستي في Session Manager نشطة لنحو 15 دقيقة أو أكثر بعد حذف الدور الذي يتيح الوصول).

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

داخلياً، انتقلنا إلى استخدام أداة Authorization Control الخاصة بنا، وهي تدعم إنشاء الجلسات مع قيود عبر ChatOps دون إضافة أي عوائق قد تبطئ مطوّرينا. ومع أنها لم تُطرح للإصدار العام بعد، فإذا كنتم مهتمين بتجربتها خلال مرحلة الوصول المبكر، يرجى ببساطة مراسلتي مباشرة على rich.mogull@firemon.com.