التشفير

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

هناك ثلاث طرق مناسبة لتطبيق التشفير للمساعدة في الحفاظ على خصوصية المستخدم، وهي: التشفير أثناء النقل، والتشفير أثناء عدم النشاط، والتشفير التام بين الأطراف:

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

HTTPS

تتمثل الخطوة الأولى في عرض خدمة الويب عبر HTTPS. من المرجح جدًا أن تكون قد قمت بذلك بالفعل، لكن إذا لم يكن الأمر كذلك، فهي خطوة مهمة. HTTPS هو HTTP، وهو البروتوكول الذي يستخدمه المتصفح لطلب صفحات الويب من الخادم، ولكنه مشفّر باستخدام طبقة المقابس الآمنة (SSL). وهذا يعني أنّ مهاجمًا خارجيًا لا يمكنه قراءة طلب HTTPS أو التدخل فيه بين المُرسِل (المستخدم) والمُستلِم (أنت)، لأنّه يكون مشفرًا وبالتالي لا يمكنه قراءته أو تغييره. ويحدث ذلك أثناء نقل البيانات، أي أثناء انتقال البيانات من مستخدم إليك أو من مستخدم إلى آخر. إنّ تشفير HTTPS أثناء نقل البيانات يمنع أيضًا مزوّد خدمة الإنترنت للمستخدم أو مزوّد خدمة Wi-Fi الذي يستخدمه، من قراءة البيانات التي يرسلها إليك كجزء من علاقته بخدمتك. قد يؤثر ذلك أيضًا في ميزات خدمتك: فالعديد من استخدامات واجهات برمجة تطبيقات JavaScript الحالية تتطلب عرض الموقع الإلكتروني عبر HTTPS. وتتضمّن قائمة MDN قائمة أكثر شمولاً، ولكن واجهات برمجة التطبيقات المحمية بسياق آمن تشمل مشغّلي الخدمات والإشعارات الفورية ومشاركة الويب والعملات المشفّرة على الويب وبعض واجهات برمجة التطبيقات للأجهزة.

لعرض موقعك الإلكتروني عبر HTTPS، يجب توفّر شهادة طبقة المقابس الآمنة (SSL). ويمكن إنشاء ملفات تعريف الارتباط هذه مجانًا عبر موقع Let's Encrypt، أو يمكن غالبًا توفيرها من خلال خدمة الاستضافة إذا كنت تستخدم أيًا منها. من الممكن أيضًا استخدام خدمة تابعة لجهة خارجية "توفِّر" خدمة الويب التي تستخدمها ويمكنها توفير HTTPS، إلى جانب خدمات التخزين المؤقت وشبكة توصيل المحتوى (CDN). هناك أمثلة عديدة على هذه الخدمات، مثل Cloudflare وFastly التي يمكنك استخدامها بالضبط اعتمادًا على البنية الأساسية الحالية. في السابق، كان تنفيذ بروتوكول HTTPS صعبًا أو مكلفًا، لهذا السبب كان يُستخدم فقط على صفحات الدفع أو على مصادر آمنة بشكل خاص، ولكن تمت إزالة جميع هذه العقبات من خلال الشهادات المتاحة مجانًا وتحسينات المعايير وزيادة انتشار المتصفّحات.

الإجراءات التي يُنصح بها

• تفعيل HTTPS على خوادمك لجميع الخدمات (أيًا كانت الطريقة التي تختارها)
• يمكنك استخدام خادم وكيل أمام خوادمك، مثل Cloudflare (يوضّح httpsiseasy.com/ العملية).
• سيرشدك Let's Encrypt خلال عملية إنشاء شهادة Let's Encrypt SSL الخاصة بك.
• أو استخدم أداة OpenSSL مباشرةً لإنشاء شهادتك الخاصة وتوقيعها حسب اختيارك لمرجع التصديق (CA) (يشرح تفعيل HTTPS كيفية إجراء ذلك بالتفصيل).

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

إنّ إنشاء الشهادات وتوقيعها من قِبل مرجع تصديق هو الطريقة المستخدمة لتنفيذ عملية طبقة المقابس الآمنة (SSL)، غير أنّ استخدام Let's Encrypt قد يكون أسهل إذا كان متوافقًا مع موفّر الخدمة أو إذا كان فريق الخادم ماهرًا بما يكفي من الناحية الفنية وكان خدمة مجانية. من الشائع أيضًا أن يقوم الموفر بتقديم طبقة المقابس الآمنة (SSL) كخدمة إذا كنت تستخدم شيئًا على مستوى أعلى من الاستضافة السحابية، لذا الأمر يستحق التحقق.

أهمية

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

طريقة عرض المتصفِّحات لصفحة HTTP (غير آمنة)

إعادة التوجيه إلى HTTPS

إذا كان موقعك الإلكتروني متاحًا على كل من عناوين URL التي تستخدم http: وhttps:، يجب إعادة توجيه جميع عناوين URL التي تستخدم http إلى https. ويرجع ذلك إلى الأسباب المذكورة أعلاه، ويضمن أيضًا عدم ظهور موقعك الإلكتروني على whynohttps.com إذا أصبح رائجًا. تعتمد كيفية إجراء ذلك إلى حد كبير على بنيتك الأساسية. إذا كان موقعك الإلكتروني مستضافًا على AWS، يمكنك استخدام موازن حمل كلاسيكي أو تطبيق. مماثلة لخدمة Google Cloud. في Azure، يمكنك إنشاء باب أمامي، وفي Node with Express check for request.secure، وفي Nginx التقط جميع المنافذ 80 وإرجاع 301، وفي Apache، استخدم Re writeRule. إذا كنت تستخدم خدمة استضافة، فمن المحتمل جدًا أنها ستتولى تلقائيًا إعادة التوجيه إلى عناوين URL التي تستخدم HTTPS نيابةً عنك، مثل صفحات Netlify وFirebase وGitHub، وغيرها الكثير.

HSTS

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

وبالمثل، يمكنك عرض العنوان upgrade-Insecure-Requests مع صفحاتك. يعد هذا شيئًا مختلفًا عن ولكنه يتعلق بـ Strict-Transport-Security. في حال إضافة Upgrade-Insecure-Requests: 1، سيتم طلب الطلبات من هذه الصفحة إلى موارد أخرى (الصور والنصوص البرمجية) على أنّها https حتى إذا كان الرابط http. ومع ذلك، لن يطلب المتصفح الصفحة نفسها باعتبارها https، ولن يتذكرها المتصفح في المرة القادمة. من الناحية العملية، تكون طلبات الترقية-غير الآمنة مفيدة إذا كنت تحوّل موقعًا إلكترونيًا حاليًا يحتوي على الكثير من الروابط إلى بروتوكول HTTPS وكنت تحوِّل عناوين URL للروابط في المحتوى، ولكن من الأفضل تغيير المحتوى حيثما أمكن.

وتجدر الإشارة إلى أن آلية HSTS هي في المقام الأول ميزة أمان، فهي تعمل على "قفل" موقعك الإلكتروني بحيث لا تستخدم بروتوكول HTTPS للمستخدمين الذين سبق لهم زيارة موقعك الإلكتروني. ومع ذلك، كما ذُكر أعلاه، يصلح استخدام HTTPS للخصوصية في حين أنّ HSTS مفيد مع HTTPS. وبالمثل، لن تكون "طلبات الترقية-غير الآمنة" مطلوبة في حال تحديث جميع المحتوى لديك، ولكنها طريقة مفيدة من أجل "التثبيت والتثبيت" لتعزيز الدفاع لضمان أن موقعك سيتحول إلى بروتوكول HTTPS دائمًا.

الإجراءات التي يُنصح بها

إضافة عنوان HSTS إلى الردود الصادرة:

Strict-Transport-Security: max-age=300; includeSubDomains

تحدّد مَعلمة max-age المدة التي يجب أن يتذكّر فيها المتصفّح عملية ترقية HTTPS وينفّذها بالثواني. (في هذا المثال، يتم ضبطها على 300 ثانية، أي خمس دقائق). في النهاية، قد يكون 6,3072,000، أي ما يعادل عامَين، وهو الرقم الذي يقترحه الموقع الإلكتروني hstspreload.org، ولكن يصعب استرداده في حال حدوث مشاكل. لذا، نقترح عليك ضبط هذا الإعداد على رقم منخفض في البداية (300)، وإجراء الاختبار للتأكّد من عدم حدوث أي أعطال، ثم زيادة العدد على مراحل.

أضِف عناوين Upgrade-Insecure-Requests إلى الردود الصادرة:

Upgrade-Insecure-Requests: 1 Content-Security-Policy: upgrade-insecure-requests

التشفير التام بين الأطراف

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

How does it work?

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

مثال: ExcaliDraw

يُجري ExcaliDraw هذا الإجراء ويوضِّح الطريقة في مشاركة مدونة. إنه تطبيق رسم متجه يخزن الرسومات على الخادم، والتي يتم تشفيرها باستخدام مفتاح يتم اختياره عشوائيًا. يعود سبب قدرة ExcaliDraw على تنفيذ هذا التشفير التام بين الأطراف باستخدام رمز صغير نسبيًا، لأنّه يتم الآن تضمين مكتبات التشفير في المتصفِّح باستخدام window.crypto، وهي مجموعة من واجهات برمجة تطبيقات JavaScript المتوافقة في كل المتصفحات الحديثة. التشفير صعب، وتنفيذ الخوارزميات يأتي مع العديد من الحالات الهامشية. إنّ إنجاز المتصفح المهام بالغ الأهمية يجعل التشفير أكثر سهولة لمطوّري الويب، وبالتالي تسهيل تنفيذ الخصوصية من خلال البيانات المشفّرة. وحسب ما يوضّحه فريق ExcaliDraw، يظل مفتاح التشفير على جهة العميل لأنّه جزء من جزء عنوان URL: عندما يزور أحد المتصفِّحات عنوان URL https://example.com/path?param=1#fraghere، يتم تمرير مسار عنوان URL (/path) والمعلَمات (param=1) إلى الخادم (example.com)، ولكن لا يتم نقل هذا الجزء (fraghere)، وبالتالي لا يراه الخادم أبدًا. وهذا يعني أنه حتى إذا كانت البيانات المشفرة تمر عبر الخادم، فإن مفتاح التشفير لا يتم الاحتفاظ بها، وبالتالي يتم الاحتفاظ بالخصوصية لأن البيانات تخضع للتشفير التام بين الأطراف.

القيود

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

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

التشفير غير مستخدَم من قِبل أي برنامج حاليًا

بالإضافة إلى تشفير بيانات المستخدمين أثناء نقلها، من المهم أيضًا تشفير البيانات التي خزنتها على الخادم. يساعد ذلك في الحماية من عمليات اختراق البيانات، لأنّ أي شخص يحصل على وصول غير مصرَّح به إلى بياناتك المخزّنة سيكون لديه بيانات مشفَّرة. هناك طريقتان مختلفتان ومتكاملتان لتشفير البيانات غير النشطة: التشفير الذي تضيفه، والتشفير الذي يضيفه مقدّم مساحة التخزين في السحابة الإلكترونية (في حال الاستعانة بأحد مقدّمي مساحة التخزين في السحابة الإلكترونية). لا يوفر تشفير مزود مساحة التخزين الكثير من الحماية ضد عمليات اختراق البيانات من خلال برامجك (لأن تشفير مقدّم مساحة التخزين عادةً ما يكون شفافًا لك بصفتك مستخدمًا لخدمته)، ولكنه يساعد في مكافحة الاختراقات التي تحدث في البنية الأساسية لموفّر الخدمة. غالبًا ما يكون من السهل تفعيل هذه الميزة، لذا من المفيد التفكير في استخدامها. يتغير هذا المجال بسرعة ويكون فريق الأمان لديك (أو المهندسين الخبراء في الأمان في فريقك) هم الخيار الأفضل لتقديم المساعدة بشأن هذا الأمر، إلا أنّ جميع مقدّمي خدمات التخزين في السحابة الإلكترونية يوفّرون التشفير في حالة عدم النشاط لحظر مساحة التخزين Amazon S3 من خلال ضبط كل من Azure Storage وGoogle Cloud Storage بشكل تلقائي، ولتخزين بيانات قاعدة البيانات AWS RDS، Azure1 SQL، Google Cloud. {10 تحقق من ذلك مع مقدم التخزين السحابي، إذا كنت تستخدم أيًا منها. تزداد صعوبة معالجة تشفير البيانات غير النشطة بنفسك للمساعدة في حماية بيانات المستخدمين من عمليات اختراق البيانات، لأنّ الخدمات اللوجستية لإدارة مفاتيح التشفير بأمان وإتاحتها للترميز بدون إتاحتها للمهاجمين أمر صعب. ليس هذا هو المكان الأفضل لتقديم المشورة بشأن مشكلات الأمان على هذا المستوى، حيث يمكنك التحدث مع المهندسين المتمرسين في الأمان أو الفريق المتخصص في هذا الشأن أو مع هيئات الأمان الخارجية.