عندما لا تكفي MFA

القاعدة الأولى في أمن السحابة هي: "عليك استخدام MFA في جميع الأوقات". لماذا؟ لأنكم عند الانتقال إلى الحوسبة السحابية العامة تأخذون في الأساس جميع واجهاتكم الإدارية، وتوحّدونها في بوابة واحدة أو واجهة برمجة تطبيقات واحدة، ثم… تضعونها على الإنترنت محمية باسم مستخدم وكلمة مرور و(ربما) MFA. حتى عند استخدام الاتحاد بين الهويات.

لكن اتضح أن حتى MFA ليست كافية دائمًا، كما ظهر في عدة اختراقات كبرى، بما في ذلك ما حدث لدى Uber.

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

تُعد MFA وسيلة فعّالة لحماية مصادقة المستخدمين/المسؤولين. ولدينا خيارات كثيرة تتراوح بين الأكثر أمانًا قليلاً (MFA المعتمدة على الرسائل) والآمنة إلى حد بعيد (المفاتيح المادية). لكن المشكلة حتى مع MFA هي أن المستخدمين يمتلكون وصولاً دائمًا بامتيازات دائمة. فإذا منحتم مستخدمًا دورًا، يمكنه استخدام تلك الأذونات في أي وقت بعد المصادقة. والمهاجمون يعرفون ذلك وقد طوّروا مجموعة من الأساليب للحصول على وصول مُصادَق عليه. فهم:

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

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

الحد الأدنى من الامتيازات وهم

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

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

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

تعزيز الأمن بالتفويضات الديناميكية

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

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

هكذا تعمل أدوات مثل FireMon Authorization Control لدينا. أو اطّلعوا على Netflix ConsoleMe كمثال مفتوح المصدر. يطلب المستخدمون الوصول عند حاجتهم إليه، ثم تستخدم المنصات السياسات لتحديد ما يلزم للموافقة. وعند استيفاء تلك الشروط، مثل موافقة مدير أو زميل، يُفوَّض المستخدم باستخدام دور لجلسة واحدة. بل يمكن للمنصات إدراج شروط مثل "السماح بهذه الجلسة فقط من عنوان IP الذي طلبها". وتكون هذه الطلبات عادةً خارج النطاق وتستخدم قنوات جانبية مثل ChatOps للموافقات، مما يجعل العملية ملحوظة عن قصد، خصوصًا للوصول الحسّاس إلى بيئة الإنتاج.

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

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