أساسيات الحوسبة السحابية

التشفير وحماية البيانات

كيف يحمي التشفير في حالة السكون والتشفير أثناء النقل البيانات في نقطتين مختلفتين من رحلتها، وكيف تُبقي إدارة المفاتيح البيانات المشفّرة عديمة الفائدة لأي طرف غير مُصرّح له، وأين تنتهي حماية التشفير.

متوسط 19 دقائق 5 أهداف التعلّم
  1. فرّق بين التشفير في حالة السكون والتشفير أثناء النقل، وحدد النقطة التي يحميها كل منهما في الطلب
  2. اشرح كيف يقابل AES-256 وTLS الحماية في حالة السكون وأثناء النقل على التوالي
  3. صف نموذج العزل خلف خدمات إدارة المفاتيح المُدارة، ولماذا يفصل الوصول للبيانات عن الوصول للمفتاح
  4. قارن بين خدمة مفاتيح مُدارة ووحدة أمان عتادية مخصصة، وحدد متى يناسب كل خيار
  5. صحح الفكرة الخاطئة القائلة إن التشفير وحده يغني عن ضبط الوصول

نفس الملف، خطران مختلفان

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

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

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

التشفير في حالة السكون: AES-256 والتشفير من جانب الخادم

يحمي التشفير في حالة السكون البيانات المكتوبة على التخزين، سواء أقراصاً أو نسخاً احتياطية أو ملفات قواعد بيانات، بحيث يرى أي شخص يصل إلى وسيط التخزين المادي أو المنطقي دون تصريح نصاً مشفّراً غير قابل للقراءة فقط. الآلية المعيارية عبر كل مزوّد سحابي رئيسي هي AES-256، شفرة الكتلة القياسية بـ 256 بت، تُطبَّق تلقائياً أو عند الطلب على البيانات لحظة كتابتها.

تسمي AWS أسلوبها الافتراضي التشفير من جانب الخادم: تشفّر خدمة التخزين نفسها البيانات قبل كتابتها وتفك شفرتها عند إخراجها، كل ذلك داخل الخدمة، باستخدام مفاتيح تُدار عبر نظام إدارة مفاتيح. لا يلمس العميل عادة الشفرة مباشرة؛ يختار خيار إدارة مفتاح وتتولى خدمة التخزين الباقي.

التشفير أثناء النقل: TLS

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

اعتباراً من منتصف 2024، تفرض كل نقطة نهاية API لدى AWS إصدار TLS 1.2 على الأقل، وتدعم TLS 1.3، الإصدار الأحدث والأسرع من البروتوكول. يعكس هذا الحد الأدنى نمطاً عاماً في الصناعة: تُقاعَد إصدارات TLS القديمة وسلفه SSL كلما تراكمت الثغرات فيهما، ويستمر الحد الأدنى المقبول بالتقدم.

الفجوة الوسطى: البيانات قيد الاستخدام

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

إدارة المفاتيح: فصل مَن يستطيع فك التشفير عمّن يملك المفتاح

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

الحد الفاصل: خدمة مفاتيح مُدارة مقابل عتاد مخصص

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

الالتباس: التشفير يغني عن ضبط الوصول

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

إشارات الامتحان: في حالة السكون أم أثناء النقل

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

إلى أين يقودك هذا

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