كنت في مناقشة مع أحد المطورين حول تطوير برنامج مختص بال Authentication يعمل على الاندرويد، وبما أن البرنامج يصنف تحت برامج الحماية Security Applications فقد أفترضت أن صديقنا سوف يراعي كل ال Standards المستخدمة في تطوير الأنظمة الأمنة (استخدام مثلاً RSA بمفاتيح كبيرة مثلاً 2048 على الأقل، استخدام الشهادات الرقمية Certificates الخ..) ولكن صدمت عندما وجدت ان التشفير في برنامجه هو عباره عن عملية حساب لل Hash فقط (تحقق من البيانات اي بعباره اخرى فحص للIntegrity للبيانات) وهل تغيرت أم لأ.
لننسى نقطة ان Data Integrity هي ليست الا فائده أولى من فوائد التوقيع الرقمي Digital Signature، ولننسى نقطة أن أغلب المواقع العربية ما زالت تسمي الـ Hash بالتشفير Encryption ، ولنركز حول أخر فقرة في النقاش وهي بعدما عرف ان هذا لن يكون برنامج جيد لأنه بلا اي حماية وقابل للاختراقات، بأنه سوف يقوم فيما بعد باستخدام خوارزمية تشفير بمفتاح واحد Symmetric Key (مثل AES) ويقوم بعمل مفتاح واحد وينشره بين مستخدمين البرنامج، لأنه برنامج محدد للأقارب مثلاً وبالتالي الجميع يعرف ويثق الآخر.
لذلك السؤال المطروح: هل تقوم بعمل الحمايه في تطبيقات الحماية قبل أو بعد الانتهاء من المشروع (هل تتبع Designing in Security أو لا تتبعها).
ال Designing-In Security يعني أنك ستدخل مسائل التحقق والتشفير والbackup وكل جوانب الحماية في كل مرحلة من مراحل التطوير سواء كانت في مرحلة متطلبات المشروع Requirement أو كانت في مرحلة وضع هيكله المشروع، ولا يجب بالبدء البرمجة وبعد ذلك تفكر باضافة طبقة الحمايه لاحقا.
لماذا؟ لن أقول لك لماذا ، ولكن دع التاريخ يسرد نفسه ويريك الحقائق…
نظام ويندوز 98
بسبب تم دعم نافذه السؤال عن اسم المستخدم والباسورد password dialog بعد صدور نسخ الويندوز الأولى، فمن خلال ال Safe Mode (عند اقلاع الجهاز بعد الضغط على F8) يمكن تجاوز هذه النافذه والدخول مباشرة للنظام. هذا بسبب أن هذه الحماية الأولى لم تكن في التصاميم الأولية للنظام Initial Design والا فكان المفترض ان يتم السؤال عن تلك المعلومات حتى اثناء الدخول في ال Safe Mode.
هذا مثال واحد على ان اضافة الSecurity كLayer جديدة في النظام قد لا تنفع.
الإنترنت Internet
أحد الأمثلة الأخرى التي تبين لنا مدى صعوبة ادخال ال Security بعد اطلاق الأنظمة هو الأنترنت، فعندما صممت هذه الشبكة كانت كل الأجهزة التي تتصل ببعضها موثوقه لأنها كل كانت تتبع لجهات عسكرية أو جامعات. وبعد ذلك في منتصف التسعينيات عندما توسعت الشبكة ودخلت كثير من أجهزة الشركات والأفراد الشبكة بدئت بعض الجهات باستخدام ال Firewalls للحماية. ال Firewall يقوم بايقاف كل البيانات التي لا تريدها من اي مصدر تقوم بتحديده، لكن المشكلة التي حدثت هو أنك يمكن أن تتلاعب في الباكت نفسه IP Packet وتقوم بتغيير عنوان المرسل في الباكت الخارج منك الى عنوان B وترسله الى الجهاز A والذي يثق فيه وسيتم دخول الباكت بواسطة الFirewall والسبب أنه يسمح لB بالتعامل معه لأنه موثوق.
هذه كانت من احدى مشاكل التصاميم الأولية لشبكة الانترنت وبالتحديد TCP/IP ويمكنك قرائه الورقة العملية التي تصف المشكلة بالتفصيل:
https://www.cs.columbia.edu/~smb/papers/ipext.pdf
أو قرائه هذه المقالة من سميانتيك: IP Spoofing: An Introduction
ولو تم تصميم البرتوكول منذ الأول على اساس عدم الوثوقية والحماية لكن الأمر مختلف الآن.
خلاصة
عندما تبدأ في تطوير برامجك (خاصه المختصة بالحمايه والتشفير) ففكر في جانب الحماية منذ الأول بشكل صحيح. وراعي بين ال Security وسهولة Convenience استخدام المنتج، فمثلاً لو قمت باستخدام طرق حماية قصوى ولكن المنتج اصبح صعب الاستخدام فلن يستخدمه احد، على سبيل المثال عندما تسجل برقم سري في خدمة على الانترنت فبعض المواقع الجيدة تمنعك من اختيار كلمات مرور سيئة وسهل تخمينها وهذا لكي يعطيك حمايه افضل، وفي نفس الوقت لا تولد لك كلمات صعبه حتى لا تنساها أو تكتبها على ورقة وبالتالي تزيد المخاطرة ، ولكن تجعلك تكتبه بنفسك مع استخدام Policy في الكتابه مثلاً احتوائه على رقم أو رمز والخ، وكلما وازنت في الحماية Security مع السهوله Convenience كلما كان افضل، وحتى لو قلت السهوله بدرجة واحدة وحافظت على الحماية فهذا سوف يقلل من احتمالات اختراق أو حدوث خلل في منتجك الأمني وفي نفس الوقت لن تزعج مستخدمك كثيراً.
أتمنى من الصديق قرائه هذه المقالة
مقاله بسيطه و جميله …