إنترنت الأشياء (الجزء الثّامن): الخصوصيّة والسّريّة

هناك أدواتٌ عدّةٌ يُمكن لمهندسي تصميم الأنظمة والمطوّرين استخدامها لحماية نظمِ إنترنت الأشياء من الاستخدام الخبيث، سنذكر بعض هذه التِّقنيَّات، ولن نوضّحُ تأثيرها على الأمنِ فحسب؛ بل على التّوافقيّة أيضًا.

الشّبكات الافتراضيّة الخاصّة (Virtual Private Networks (VPNs

تُستخدَم هذه الطّريقة لحماية الحلول غير المضمونة على الإنترنت غالبًا، وتحتاجُ عادةً حلول M2M التّقليديّة، والّتي تعمل على نحوٍ جيّدٍ في الشّبكات الدّاخليَّة إلى التّوسّع عبر شبكة الإنترنت، وإحدى الطّرق لتحقيق ذلك؛ هي إنشاءُ الشَّبكات الافتراضيَّة الخاصّة (VPNs)؛ الّتي تسمح للأجهزة بالاعتقادِ بأنّها موجودة في شبكةٍ داخليّةٍ محليّة على الرّغم من نقل الاتّصالات عبر الإنترنت؛ ما يعني صعوبةَ رؤيةُ تطبيق إنترنت أشياءٍ صريح؛ بل هو حلُّ M2M باستخدام الإنترنت كوسيلةٍ للنّقل، وقد يحمي استخدام الشّبكات الافتراضيّة الخاصّة الحلّ؛ لكنّه يُلغي إمكانيّة التّشغيل البينيّ مع الآخرين على شبكة الإنترنت على نحوٍ تامّ، و يعدّ هذا أكبرَ مِيزةٍ لاستخدام تقنيَّة إنترنت الأشياء.

مصادقة الهويّات Authentication of Identities

المُصادقة هي عمليّة التّحقّق من صحّة ما إذا كانت الهويّة المُقدَّمة صحيحةً أم لا، وقد تكون مصادقةُ الخادم بسيطةً، مثل التّحقق من صحّة شهاداتِ المجال الّذي يوفّره الخادم، والتّأكّد من عدمِ إبطاله ومن توافقيّته مع اسم المجال المُستخدَم للاتصال بالخادم؛ في حين أنَّ مصادقة العميل تتضمّن مصادقة بياناتِ الاعتماد المُقدَّمة من قبله، وتحدثُ هذه المصادقةُ عادةً باستخدامِ طُرقٍ عدّة، ولذلك يجبُ على كلِّ من المطوّرين والمُصمّمين فهم طُرق المُصادقة المتاحة وكيفيَّة عملِها لتقييم مستوى الأمان المُستخدَم من قبل النّظام الّذي يعملون عليه.

وتَستخدِم بعض البروتوكولات كـ HTTP وXMPP طبقةَ المُصادقة والأمان البسيطة (Simple Authentication and Security Layer (SASL القياسيَّة لنشر مجموعةٍ من طرق المُصادَقة القابلة للتَّوسّع، والّتي يُمكن للعميل الاختيار من بينِها، وتتمثّلُ نقطةُ الضَّعف في هذه الطّريقة في إمكانيَّة خداع العملاء باختيار آليَّةِ مُصادقةٍ غير آمنة؛ ما يعني كشفَ بياناتِ اعتماد المُستخدم بغير قصد للاحتيال.

وهناك بروتوكولاتٌ لا تَستخدمُ مصادقةً للأمان على الإطلاق، فمثلاُ؛ يُرسلُ بروتوكول MQTT اعتماداتِ المستخدم  في نصٍّ واضحٍ ويجعله مَطلَبًا لاستخدامِ التَّشفير لإخفاءِ اعتماداتِ المُستخدِم، وهناك بروتوكولاتٌ أخرى لا تمتلكُ طريقةً قياسيَّةً لإنجاز المُصادقة، فعلى سبيلِ المثال؛ تُبنى المصادقةُ على رأسِ بروتوكول CoAP  كخيارات الأمان، ويؤثّرُ عدمُ وجود هذه الخياراتِ في المعيار سلبًا على قابليَّة التّشغيل البينيّ.

أسماءُ المُستخدمين وكلمات المرور Usernames & Passwords

يُعدُّ تزويدُ الخادم باسم مستخدمٍ وكلمة مرورٍ سهلَين طريقةً شائعةً لتجهيزِ اعتماداتِ المُستخدِم أثناءَ المُصادقة ومألوفةً للبشر، وتَستخدِم بعضُ الحلول مفهومَ المفتاح مُسبَق المُشاركة Pre-shared Key (PSK) لأنّه أكثر تآلفًا مع الآلات.

وإنْ كنتَ من مستخدمي اسم مُستخدِمٍ وكلمةَ مرورٍ؛ فلا تُعيد استخدامها بين الأجهزةِ وإنْ كانت طريقةً سهلةً لتذكّرها.

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

وفي حالة استخدام البروتوكول XMPP؛ فهذه المُشكلة محلولة لأنَّ الجهاز يُولّد هويَّته العشوائيَّة الخاصَّة، بالإضافةِ إلى توليدِ الحساب المُطابق على خادم XMPP بطريقةٍ آمنة، ولا نحتاجُ لإعداداتٍ افتراضيَّة مُسبَقة من المصنع، لا تكشفُ هذه الطَّريقة الاعتمادَ ولا تُؤثِّر على الكلفةِ أو الإنتاجيَّة سلبيًّا.

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

المركزيَّة مقابل اللّامركزيَّة Centralization vs Decentralization

الفرقُ بين البيئاتِ المركزيَّة واللّامركزيَّة كالفرقِ بين سلَّةٍ كبيرةٍ مليئةٍ بالبيض وبين أنْ تُوزِّع البيض نفسه على عدّة سلالٍ أصغر، وإنَّ خطرَ كسر الأمان في حالة البيئات الموزَّعة أصغر بكثير، وعلى الرَّغم من أنَّ احتمالَ التّعرض للهجومِ يرتفع؛ لكن من المتُوقَّع أنْ تقلّ المعلومات الّتي سيكسبها المهاجم؛ ما يُقيّد الدَّوافع لتدبيرِ هجوم مُرتفع الكلفة، والّذي يُبسِّط  بدوره عمليَّة الحمايةِ ضدَّ هجومٍ من هذا النَّوع.

ولذلكَ يُنصَح بمراعاةِ النّقاط الآتيةِ عند اختيارِ بِنيةٍ لنظامِ إنترنت الأشياء:

1- تجنَّبْ تخزين البيانات في موقعٍ مركزيّ ما أمكن، باستثناءِ البياناتِ اللَّازمة لربطِ الأشياء بعضها  ببعض.

2- أنجِز العملَ أبعدَ ما تستطيعُ عن مركزِ الشَّبكة؛ فهذا يجعلُ الأمورَ أكثرَ تدرُّجيَّة، ويستخدمُ المواردَ المُتاحة على نحوٍ أفضل.

3- استخدِمْ البيانات المُترابطة لتوزيعِ البياناتِ عبر شبكةِ الإنترنت، واستخدِمْ تِقنيَّات الحوسبة الشَّبكية القياسيَّة من أجلِ تجميع البيانات المُوزَّعة لتجنّب الحاجةِ إلى تخزينِ البياناتِ نفسها  وتكرارها مركزيًّا.

4- اسمحْ للأجهزةِ بالتَّواصل مباشرةً فيما بينها بدلاً من استخدامِ واجهة تطبيقاتِ مُستخدم API مركزيَّة لتخزينِ البيانات وتفسيرِ الاتّصالات بين طرفَي الاتّصال.

5- فكّر جيّدًا باستخدامِ حواسيبَ ميكرويَّة صغيرة ورخيصة وفعَّالة من ناحية الطَّاقة - مثل الرّاسباري باي Raspberry Pi-  كبديلٍ للمُشغّلات والمعالجاتِ المركزيَّة في مركز البيانات.

المصدر

Peter Waher, Learning Internet of Things, Packt Publishing Ltd, Livery Place 35 Livery Street, Birmingham B3 2PB, UK, 2015