لماذا نحمي كلمة المرور إذا كان بإمكاننا الاستغناء عنها؟

مشكلة اعتدنا اعتبارها أمراً طبيعياً

تضم كل تطبيقات الويب تقريباً لوحة تحكم إدارية. وعادةً ما يكون للوحة التحكم عنوان للدخول ونموذج للمصادقة واسم مستخدم وكلمة مرور.

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

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

لكن ماذا يحدث عندما يصبح عدد المشاريع عشرة أو عشرين أو ثلاثين؟

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

وبالتالي، يحتاج كل منها إلى آلية للوصول الإداري.

استخدمت لوقت طويل نهجاً مألوفاً تماماً: بيانات اعتماد إدارية منفصلة، وكلمات مرور قوية، وحفظها في المتصفح.

كان ذلك ينجح.

لكنني تساءلت في مرحلة ما: لماذا ينبغي لي أصلاً أن أحتفظ بهذا العدد من كلمات المرور الإدارية؟ ولماذا عليّ حماية الخوادم، وكذلك وسائل الوصول إليها؟

وهل يمكن الاستغناء عن هذه الحاجة؟

توصلت إلى فكرة أصبحت لاحقاً أساس الحل الذي اعتمدته:

ربما يجدر بنا حماية الحق في الحصول على وصول مؤقت، بدلاً من حماية منفذ دخول دائم.

ماذا لو لم تكن هناك صفحة تسجيل دخول مألوفة أصلاً؟

قررت التخلي عن نموذج المصادقة الإدارية التقليدي في مشاريعي.

ليس بمجرد إخفاء نموذج تسجيل الدخول.

ولا بتغيير عنوانه.

ولا باستبدال كلمة المرور بأخرى أشد تعقيداً.

بل بإلغاء الحاجة إلى وجود منفذ دائم لتسجيل الدخول باستخدام كلمة مرور.

بالطبع، لم تختفِ الواجهات الإدارية. فما زالت ضرورية لإدارة التطبيقات.

لكن طريقة الحصول على الوصول إليها تغيّرت.

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

بدلاً من ذلك، أستخدم نظامي الخاص لإدارة الهوية والوصول، MeldID.

الفكرة بسيطة بما يكفي: يُمنح الوصول الإداري عند الحاجة إليه فعلاً فقط، لمستخدم محدد ولمشروع محدد.

ومجرد امتلاك حساب لا يعني أن لصاحبه حق فتح لوحة التحكم الإدارية.

يجب منح هذا الحق بشكل منفصل.

وصول لم يكن موجوداً قبل دقيقة

لعل هذا هو الجزء الأكثر إثارة للاهتمام في الفكرة كلها.

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

قررت تغيير هذا المبدأ.

فبدلاً من بيانات الاعتماد الإدارية الدائمة، تُستخدم إمكانية مؤقتة لبدء تسجيل الدخول.

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

لكن حتى امتلاك هذا الرابط المؤقت لا يعني بحد ذاته الحصول على الوصول.

وهذه نقطة جوهرية.

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

أما في نموذجي، فلا يتيح الرابط سوى بدء إجراء التأكيد.

وللمتابعة، يلزم الحصول على موافقة منفصلة عبر جهاز محمول موثوق يستخدم MeldID.

ومن دون التأكيد المناسب، لا تُنشأ جلسة إدارية.

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

معرفة وجهة الاتصال وامتلاك حق الدخول أمران مختلفان تماماً.

الهاتف يصبح أداة لإدارة الوصول

في هذا النموذج، يؤدي الجهاز المحمول دوراً أهم بكثير من دور مولّد عادي للرموز أحادية الاستخدام.

فهو يُستخدم لتأكيد الإجراءات المرتبطة بالوصول الإداري.

عندما أريد فتح لوحة التحكم الإدارية، يطلب النظام تأكيداً عبر MeldID.

أرى الطلب المناسب على الجهاز الموثوق وأؤكد الإجراء.

ولا يسمح النظام بمتابعة إجراء تسجيل الدخول إلا بعد نجاح التحقق.

ويرتبط التأكيد بإجراء محدد، لا بمجرد حقيقة أن الهاتف قد أُزيل قفله.

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

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

وهنا تظهر ميزة أخرى: يمكن إدارة الأجهزة الموثوقة.

إذا لم يعد ينبغي استخدام جهاز ما لتأكيد الوصول، فيمكن إلغاء حالته كجهاز موثوق.

وبعد ذلك، يتوقف عن العمل كوسيلة صالحة للمصادقة على العمليات المعنية.

نظام واحد ومشاريع مستقلة متعددة

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

لم أرد دمج جميع لوحات التحكم الإدارية في تطبيق ضخم واحد.

يجب أن تظل كل خدمة من خدمات DigiMeld مسؤولة عن منطقها وإعداداتها ومستخدميها وبياناتها.

لذلك فصلت بين مهمتين.

يتولى MeldID تحديد الهوية ومنح الإذن بالوصول الإداري.

أما المشروع نفسه فيتولى وظائفه الإدارية الخاصة والتحقق من الصلاحيات السارية.

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

إضافة إلى ذلك، تُمنح الصلاحيات بشكل منفصل.

فلا يحصل مسؤول أحد المشاريع تلقائياً على إمكانية الوصول إلى المشاريع الأخرى لمجرد امتلاكه حساباً في MeldID.

ويمكن تحديد مجموعة المستخدمين المصرح لهم لكل مجال إداري على حدة.

وفي الوقت نفسه، تظل حقوق المستخدمين العاديين والصلاحيات الإدارية منفصلة.

وقد اتضح أن هذا مناسب على نحو خاص لمنظومة تضم عشرات الخدمات.

لماذا أفضل الوصول المؤقت على الدائم

هناك مبدأ آخر تعمدت تضمينه في النظام.

يجب ألا يستمر الوصول الإداري إلى ما لا نهاية.

تظل الموافقة سارية لفترة محدودة، وتنتهي بصرف النظر عن استمرار المستخدم في العمل عبر المتصفح.

ولمتابعة العمل بعد انتهاء المدة، يلزم إجراء تأكيد جديد.

وهذا يمنع تحوّل المصادقة التي أُجريت مرة واحدة إلى صلاحية دائمة.

لكن تقييد المدة وحده لا يكفي.

فإمكانية إنهاء الوصول الممنوح مسبقاً قبل انتهاء مدته أمر مهم أيضاً.

لذلك يتضمن MeldID آلية مركزية لإلغاء أذونات الوصول الإداري.

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

وهكذا لا تنتهي إدارة الوصول في اللحظة التي ينجح فيها المستخدم في تسجيل الدخول.

إمكانية إلغاء الصلاحيات لا تقل أهمية بالنسبة إليّ عن إمكانية منحها.

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

ما الذي تغيّر في العمل اليومي؟

أولاً، لم أعد مضطراً إلى الرجوع باستمرار إلى كلمات المرور الإدارية المحفوظة.

لم أعد بحاجة إلى الاحتفاظ في المتصفح بمجموعة من بيانات الاعتماد لتسجيل الدخول إلى كل لوحة تحكم إدارية متصلة.

وبدلاً من ذلك، أدير الأذونات عبر آلية موحدة.

أختار المشروع المطلوب، وأؤكد الوصول، ثم أبدأ العمل.

وعندما لا أعود بحاجة إلى الوصول الإداري، يمكن إلغاؤه.

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

يكفي ربطه بالنموذج القائم وتحديد الأذونات اللازمة.

بالطبع، هذا لا يعني أن جميع المخاطر الأمنية قد اختفت.

فالأذونات المؤقتة والأجهزة الموثوقة وجلسات الخادم والبنية التحتية المركزية تحتاج هي الأخرى إلى الحماية.

لكنني لم أعد مضطراً إلى معالجة مشكلة إدارة كلمات المرور الإدارية نفسها بصورة منفصلة لكل تطبيق.

وكان هذا تحديداً أحد أهدافي الأولية.

أليست تقنيات كهذه موجودة بالفعل؟

بلى، إنها موجودة.

فالمصادقة من دون كلمة مرور، وإدارة الوصول ذي الامتيازات، والأذونات المؤقتة، والتأكيد عبر الأجهزة الموثوقة، كلها مفاهيم معروفة منذ زمن طويل في مجال أمن المعلومات.

وتُستخدم مثل هذه الأساليب في أنظمة إدارة الهوية والوصول (Identity and Access Management)، وإدارة الوصول ذي الامتيازات (Privileged Access Management)، ومفاهيم انعدام الثقة (Zero Trust).

لا أدّعي أنني اخترعت هذه المبادئ.

كان هدفي مختلفاً.

كنت بحاجة إلى إنشاء نظام متكامل خاص بي يعالج مشكلات محددة في البنية التحتية لـ DigiMeld، ويتيح إدارة الوصول الإداري إلى عدد كبير من المشاريع المستقلة.

وفي نهاية المطاف، جمعت عدة أساليب معروفة في بنية واحدة تلبي متطلباتي.

وأرى أن قيمة العمل الهندسي لا تكمن بالضرورة في ابتكار تقنية جديدة تماماً.

فأحياناً تكمن في صياغة المشكلة على نحو صحيح وإيجاد الحل المناسب لها.

MeldID ليس مخصصاً للوحات التحكم الإدارية فحسب

يجدر هنا توضيح أمر على نحو منفصل.

لم يُنشأ MeldID حصراً ليكون أداة لوصولي الإداري الشخصي.

فهو يتيح للمطورين أيضاً استخدام حزمة تطوير برمجية (SDK) لدمج آليات تحديد الهوية وتأكيد تسجيل الدخول في تطبيقاتهم الخاصة.

وهذه الحزمة متاحة مجاناً.

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

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

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

وهذا يتيح الحد من مخاطر الوصول غير المصرح به في حال اختراق بيانات الاعتماد.

ومن المهم التمييز بين هذه الإمكانية المتاحة للجميع في MeldID وبين نموذج الوصول الإداري الذي طورته لمشاريع DigiMeld.

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

الأمن لا يقتصر على حماية ما هو موجود

جعلني العمل على هذا النظام أنظر بطريقة مختلفة إلى آليات المصادقة المألوفة.

كثيراً ما نحاول حماية أشياء موجودة لأسباب تاريخية.

فنضيف عمليات تحقق جديدة وقيوداً وكلمات مرور إضافية وطبقات حماية.

وهذا ضروري فعلاً أحياناً.

لكن من المفيد أحياناً طرح سؤال مختلف:

هل يجب أن تظل الآلية التي نحميها قائمة بالشكل السابق؟

في حالتي، كانت الإجابة بالنفي.

لم أكن بحاجة إلى نموذج تسجيل دخول إداري متاح باستمرار.

كنت بحاجة إلى إمكانية الحصول على صلاحيات إدارية بأمان، في اللحظة التي أحتاج إليها تحديداً.

وهاتان مهمتان مختلفتان.

وقد غيّر الانتقال من الأولى إلى الثانية البنية التقنية وطريقة العمل اليومية مع المشاريع على حد سواء.

ليس خاتمة نهائية، بل اتجاه اخترته

تعمل هذه البنية اليوم في جزء كبير من منظومة DigiMeld.

وتُنقل المشاريع المتبقية تدريجياً إلى نموذج الوصول الإداري الجديد.

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

وقد تطرأ تغييرات أخرى على بعض عناصر الواجهة وقواعد إدارة الجلسات.

لكن الفكرة الأساسية حُسمت بالفعل.

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

وفي الوقت نفسه، لا أعتبر تطبيقي الخاص حلاً شاملاً للجميع.

فلدى المؤسسات المختلفة متطلبات وبنى تحتية ونماذج تهديد وأساليب إدارة مختلفة.

وما يناسب منظومة DigiMeld ويبرره قد لا يكون الخيار الأمثل لمطور آخر.

ومع ذلك، فإن مبدأ منح الصلاحيات مؤقتاً يستحق الاهتمام.

في الختام

قررت مشاركة هذه التجربة لا لأنني أعتبر نفسي مخترع طريقة جديدة للمصادقة.

ولا لأنني أريد تقديم نظام آخر على أنه آمن تماماً.

فالأمن المطلق غير موجود.

إنما أرى أن طريقة طرح السؤال نفسها مثيرة للاهتمام.

فبدلاً من الاستمرار بلا نهاية في حماية منفذ إداري دائم، يمكننا إعادة النظر في ضرورة وجوده.

وبدلاً من تخزين كلمات مرور كثيرة، يمكن استخدام أذونات مؤقتة.

وبدلاً من منح الثقة تلقائياً بعد أول مصادقة، يمكن تأكيد منح صلاحيات محددة.

وبدلاً من انتظار انتهاء الجلسة، يمكن توفير إمكانية إلغاء الوصول مركزياً.

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

لا أزعم أن هذا النهج يمنع احتمال الاختراق.

إنه ببساطة ينقل التركيز من حماية بيانات اعتماد دائمة الوجود إلى منح الصلاحيات وإنهائها بطريقة خاضعة للتحكم.

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

ومن هذه الفكرة تحديداً بدأت بالنسبة إليّ قصة MeldID Admin Gateway.