خلال تقييم أمني لأحد الموردين، سأل فريق TPRM عن التشفير. فأكد المورد تطبيق تشفير AES-256 أثناء التخزين لجميع بيانات العملاء: تشفير على مستوى قاعدة البيانات، وتشفير وحدات التخزين، وتشفير النسخ الاحتياطية، وكلها مؤكدة في تقرير SOC 2 من النوع II. فدوّن الفريق ذلك وانتقل إلى غيره. وما لم يستكشفه التقييم هو أن التشفير على مستوى قاعدة البيانات كان تشفيراً شفافاً: إذ كان محرك قاعدة البيانات يفك تشفير البيانات تلقائياً عند القراءة، فتتلقى طبقة التطبيق وجميع الخدمات المصغرة وخط التحليلات وأي مستخدم لديه بيانات اعتماد لقاعدة البيانات البيانات بنص واضح. لقد حمى التشفير وسيط التخزين من الاستخراج المادي. لكنه لم يوفر أي حماية من الوصول غير المصرح به على مستوى التطبيق، ولا من بيانات اعتماد مخترقة لقاعدة البيانات، ولا من ثغرة في التطبيق كشفت نتائج استعلامات قاعدة البيانات، ولا من التهديد الداخلي المتمثل في مستخدم مميز يستعلم عن قاعدة البيانات مباشرة. كان التشفير حقيقياً. وكان حماية حقيقية من تهديد لم يكن هو التهديد الأرجح.
تتركز فجوات تغطية التشفير حول خمسة سيناريوهات تعرّض محددة:
- تشفير قاعدة البيانات الشفاف مع صلاحيات استعلام واسعة: تشفير على مستوى قاعدة البيانات يُفك تلقائياً لأي مستخدم أو تطبيق مصادَق عليه، فلا يوفر أي حماية من الوصول المصرح به لكنه مفرط
- بيانات نصية واضحة في ذاكرة التطبيق والسجلات: بيانات حساسة يُفك تشفيرها لمعالجتها في التطبيق وتوجد في الذاكرة وسجلات التطبيق ورسائل الخطأ ومخرجات التصحيح
- بيانات غير مشفرة أثناء النقل بين الخدمات: اتصالات داخلية بين الخدمات تمرر بيانات مفكوكة التشفير دون حماية TLS، مما يعرّض البيانات للاعتراض على مستوى طبقة الشبكة
- نص واضح في ذاكرات التخزين المؤقت والتخزين المؤقت: بيانات مفكوكة التشفير مخزنة في Redis أو Memcached أو طبقات تخزين مؤقت أخرى دون إعادة تشفيرها، ويمكن لأي عملية لديها وصول إلى ذاكرة التخزين المؤقت الوصول إليها
- فجوات إدارة مفاتيح التشفير: مفاتيح تشفير تُدار في البيئة نفسها التي توجد فيها البيانات التي تحميها، مما يلغي الفصل بين المفتاح والنص المشفر الذي يمنح التشفير معناه
لماذا يهم هذا
يُعد تأكيد التشفير أثناء التخزين من أكثر الضوابط الأمنية ذكراً في ردود الموردين على الاستبيانات، فهو مرئي وقابل للتدقيق وموثق في تقارير SOC 2. وبالنسبة لممارسي TPRM، يكمن الخطر في أن تأكيد التشفير أثناء التخزين يولّد طمأنينة بشأن حماية البيانات تبالغ كثيراً في تقدير ما تمت حمايته فعلاً. فالتهديدات التي يعالجها التشفير أثناء التخزين، مثل سرقة وسائط التخزين والاقتحام المادي، ليست هي التهديدات التي تنتج عنها معظم اختراقات بيانات الموردين. أما التهديدات التي تنتج عنها الاختراقات، مثل بيانات الاعتماد المخترقة وثغرات التطبيقات والوصول الداخلي، فتعمل جميعها على بيانات مفكوكة التشفير لا يحميها التشفير أثناء التخزين.
إن الاعتماد على التحكم في الوصول هو البُعد الحاسم. فالتشفير أثناء التخزين لا يوفر من الحماية إلا بقدر ما توفره ضوابط الوصول إلى المفاتيح وإلى الأنظمة التي تُجري فك التشفير. وإذا كان أي مستخدم لديه وصول إلى قاعدة البيانات يتلقى البيانات بعد فك تشفيرها، فإن التشفير لا يوفر أي حماية من الوصول المفرط إلى قاعدة البيانات. وإذا كان التطبيق يفك تشفير البيانات لمعالجتها ثم كشفت ثغرة في التطبيق نتائج قاعدة البيانات، فإن التشفير لم يوفر أي حماية من تلك الثغرة. التشفير يحمي طبقة التخزين. أما ضوابط الوصول وأمن التطبيقات وإدارة المفاتيح فتحمي الطبقات التي تقع فيها الاختراقات فعلاً.
بالنسبة لممارسي TPRM، ينشئ هذا التزامًا محددًا في التقييم: السؤال لا عن مجرد تشفير البيانات، بل عن التهديد الذي يعالجه التشفير، وما لا تحميه طبقة التشفير أثناء التخزين، والضوابط التعويضية التي تعالج الانكشاف أثناء الاستخدام. فالمورّد القادر على شرح نموذج التهديد لتطبيق التشفير لديه، أي ما يحميه التشفير وما يتطلب ضوابط أخرى، قد تعامل مع التشفير باعتباره قرارًا في البنية الأمنية لا مجرد بند امتثال يُستوفى شكليًا.
أين تخطئ معظم الفرق
الإخفاق الأكثر انتشاراً هو التعامل مع تأكيد التشفير على أنه تأكيد لحماية البيانات. فـAES-256 أثناء التخزين معيار تشفير قوي. وهو يحمي البيانات المخزنة من تهديدات محددة. لكنه لا يوفر أي حماية من أي تهديد يعمل من خلال فك تشفير مصرح به، وهي الطريقة التي تقع بها تقريباً جميع اختراقات بيانات أنظمة الإنتاج. والتأكد من أن البيانات مشفرة أثناء التخزين ثم استنتاج أن حماية البيانات قد عولجت هو خلط بين الآلية والتغطية.
الإخفاق الثاني هو عدم السؤال عن إدارة المفاتيح تحديداً. فالتشفير لا يكون قوياً إلا بقدر قوة حماية مفاتيح التشفير. وتشفير قاعدة البيانات الذي يستخدم مفاتيح مخزنة على خادم قاعدة البيانات نفسه، وتشفير التخزين السحابي الذي يستخدم مفاتيح يديرها الحساب السحابي نفسه، وتشفير النسخ الاحتياطية الذي يستخدم مفاتيح مخزنة بجانب النسخ الاحتياطية، كلها توفر حماية أضعف بكثير من التشفير المقترن بإدارة مفاتيح مفصولة على النحو الصحيح. خوارزمية التشفير هي AES-256. وإدارة المفاتيح هي التي تحدد ما إذا كان لتلك الخوارزمية أي معنى من الناحية العملية.
- التعامل مع تأكيد التشفير أثناء التخزين على أنه تأكيد لحماية البيانات: التشفير أثناء التخزين يحمي طبقة التخزين، لا طبقة التطبيق والوصول التي تقع فيها الاختراقات
- لا يوجد تقييم لإدارة المفاتيح: قوة التشفير تحددها حماية المفاتيح لا اختيار الخوارزمية
- عدم السؤال عن التشفير أثناء النقل بين الخدمات الداخلية: اتصالات داخلية بين الخدمات تتجاوز TLS
- عدم السؤال عن النص الواضح في السجلات وذاكرات التخزين المؤقت: بيانات حساسة في سجلات التطبيق ورسائل الأخطاء وطبقات التخزين المؤقت
- لا يوجد سؤال عن نموذج التهديدات: هل يفهم المورد ما يغطيه تشفيره وما الذي يتطلب ضوابط أخرى
كيف تبدو الممارسة الجيدة
تطبق برامج التشفير الناضجة لدى الموردين التشفير بوصفه استراتيجية حماية متعددة الطبقات: تشفير التخزين للطبقة المادية، وTLS لجميع الاتصالات أثناء النقل، والتشفير على مستوى التطبيق للحقول الحساسة التي يجب أن تبقى مشفرة حتى داخل طبقة التطبيق، وإدارة مفاتيح مفصولة عن البيانات التي تحميها. ويُفهم وضع التشفير من حيث التهديدات التي يعالجها، وتعالج الضوابط التعويضية صراحةً طبقة الاستخدام التي لا يوفر فيها التشفير أثناء التخزين أي حماية.
- تشفير أثناء التخزين مع إدارة مفاتيح مفصولة: مفاتيح تُدار عبر HSM أو KMS سحابية مع فصل بين الوصول إلى المفاتيح والوصول إلى البيانات
- TLS 1.2 أو أعلى لجميع الاتصالات أثناء النقل، بما في ذلك الاتصالات الداخلية بين الخدمات، وليس فقط واجهات برمجة التطبيقات الخارجية
- التشفير على مستوى التطبيق للحقول الأعلى حساسية: تشفير على مستوى الحقل يُبقي الحقول الحساسة مشفرة حتى عندما تفك قاعدة البيانات تشفير السجل المحيط بها
- استبعاد البيانات الحساسة من السجلات: ضبط تسجيل التطبيق بحيث يحجب قيم الحقول الحساسة أو يحذفها من مخرجات السجلات
- تشفير ذاكرة التخزين المؤقت للبيانات الحساسة: تشفير طبقة التخزين المؤقت لمنع بقاء البيانات الحساسة بنص واضح في ذاكرات التخزين المؤقت
- صياغة نموذج تهديدات التشفير: قدرة المورد على وصف التهديدات التي يعالجها تشفيره والضوابط التعويضية التي تغطي طبقة الاستخدام
الأدوات
تتطلب معالجة تغطية التشفير عبر جميع الطبقات أدوات تمد الحماية إلى ما بعد طبقة التخزين لتشمل سياقات التطبيق والنقل.
إدارة المفاتيح: AWS KMS، وAzure Key Vault، وHashiCorp Vault، وThales
توفر خدمات إدارة المفاتيح إدارة دورة حياة مفاتيح التشفير، وهي التي تحدد ما إذا كان التشفير يوفر حماية ذات معنى. وتوفر AWS KMS وAzure Key Vault إدارة مفاتيح سحابية أصلية مع فصل بين الوصول إلى المفاتيح والوصول إلى البيانات، إذ تتحكم سياسة IAM مختلفة في من يمكنه استخدام مفتاح التشفير مقابل من يمكنه قراءة البيانات المشفرة. ويوفر HashiCorp Vault إدارة الأسرار والمفاتيح على مستوى التطبيق للبيئات متعددة السحابات. وبالنسبة لممارسي TPRM، فإن السؤال عن خدمة إدارة المفاتيح التي يستخدمها المورد وكيفية فصل الوصول إلى المفاتيح عن الوصول إلى البيانات هو أهم سؤال منفرد في حوكمة التشفير بعد التأكد من الخوارزمية.
التشفير على مستوى الحقل: Crypteron، وAWS DynamoDB Encryption Client، وMongoDB CSFLE
يُبقي التشفير على مستوى الحقول، أو التشفير على مستوى الحقول من جانب العميل، حقولًا حساسة محددة مشفرة في طبقة التطبيق، أي أن قاعدة البيانات تخزّن نصًا مشفرًا وتعيده حتى لمستخدم التطبيق المصادَق عليه، ويجب أن يحتفظ التطبيق بمفتاح فك التشفير بشكل منفصل للوصول إلى قيمة الحقل. ويمدّ ذلك حماية التشفير إلى طبقة التطبيق لأكثر الحقول حساسية. ويوفر MongoDB Client-Side Field Level Encryption (CSFLE) هذه القدرة في عمليات نشر MongoDB. وبالنسبة لممارسي TPRM، فإن السؤال عمّا إذا كان المورّد يستخدم التشفير على مستوى الحقول لأكثر فئات البيانات حساسية يكشف ما إذا كانت تغطية التشفير تمتد إلى ما بعد طبقة التخزين.
الحوسبة السرية: Intel SGX، وAMD SEV، وAWS Nitro Enclaves
توفر منصات الحوسبة السرية بيئات تنفيذ موثوقة قائمة على العتاد تحمي البيانات أثناء الاستخدام، فتُبقي البيانات مشفرة حتى في الذاكرة أثناء المعالجة، وتحميها من الوصول المميز على مستوى OS ومن اختراق برنامج الإشراف الافتراضي (Hypervisor). وتوفر AWS Nitro Enclaves وAzure Confidential Computing حوسبة سرية سحابية أصلية. وهذه قدرات ناشئة لم تنتشر بعد على نطاق واسع في المؤسسات، لكن الموردين الذين يعالجون أكثر فئات البيانات حساسية، مثل بيانات الجينوم والتداول المالي والبيانات الحكومية السرية، بدأوا في نشرها. وبالنسبة لممارسي TPRM، فإن الوعي بالحوسبة السرية بوصفها الاتجاه الذي تسير إليه الحماية أثناء الاستخدام يتيح إجراء محادثات مستنيرة حول الوضع الحالي وخارطة الطريق.
تحديات الحوكمة
إن تحدي الحوكمة في التشفير هو الخلط بين الخوارزمية والبنية، وهو ما يجسده المراجع. فـAES-256 خوارزمية قوية. أما ما إذا كانت تُطبق بطريقة توفر حماية ذات معنى فيتوقف كلياً على إدارة المفاتيح، وضوابط الوصول إلى فك التشفير، وما يحدث للبيانات بعد فك تشفيرها. وبرنامج التشفير الذي يحدد الخوارزمية دون أن يعالج إدارة المفاتيح وضوابط الوصول والتعرض أثناء الاستخدام قد وثّق اختيار شفرة دون أن يوثّق بنية أمنية.
بالنسبة لبرامج TPRM، يتمثل التحول العملي في الحوكمة في الانتقال من التأكد من الخوارزمية إلى التأكد من نموذج التهديدات، أي مطالبة الموردين بوصف التهديدات التي يعالجها تشفيرهم والضوابط التعويضية التي تعالج التهديدات التي لا يغطيها التشفير أثناء التخزين. فالمورد القادر على صياغة هذا الرد قد فكّر في التشفير بوصفه بنية أمنية. أما المورد الذي لا يستطيع إلا تأكيد AES-256 فقد فكّر في التشفير بوصفه متطلباً للامتثال.
- اسأل عن إدارة المفاتيح تحديداً: ليس فقط عن الخوارزمية المستخدمة، بل عن كيفية إدارة المفاتيح وتخزينها والتحكم في الوصول إليها
- اسأل عن التشفير أثناء النقل بين الخدمات الداخلية: امتداد تغطية TLS لتشمل شبكة الخدمات (Service Mesh) والاتصالات الداخلية
- اسأل عن البيانات الحساسة في السجلات: هل يحجب تسجيل التطبيق قيم الحقول الحساسة
- اطلب من الموردين وصف ما يغطيه تشفيرهم: ما التهديد الذي يعالجه وما الضوابط التعويضية التي تعالج طبقة الاستخدام
- أدرج بنية التشفير في تقييمات الموردين: ليس مجرد التأكد من الخوارزمية، بل إدارة المفاتيح وتغطية النقل والتشفير على مستوى الحقل للبيانات الأعلى حساسية
إذا كنت فريقًا صغيرًا
أضف إلى تقييمك للتشفير سؤالين يتجاوزان التأكد من الخوارزمية. الأول: كيف تُدار مفاتيح التشفير لديكم، ومن لديه وصول إلى المفاتيح مقابل من لديه وصول إلى البيانات المشفرة، وهل هذان الوصولان مفصولان؟ الثاني: ما الذي يحمي بيانات العملاء الحساسة أثناء معالجتها في التطبيق بعد أن يفك تشفير التخزين تشفيرها، وتحديداً ما الذي يمنع مسؤول قاعدة بيانات لديه بيانات اعتماد صالحة من الوصول إلى جميع بيانات العملاء بنص واضح؟ يكشف السؤال الأول مدى نضج إدارة المفاتيح. ويفرض السؤال الثاني نقاشاً حول نموذج التهديدات يكشف ما إذا كان المورد يفهم ما يحميه التشفير أثناء التخزين وما لا يحميه.
- أضف الفصل في إدارة المفاتيح إلى تقييمك للتشفير: من يصل إلى المفاتيح مقابل من يصل إلى البيانات
- اسأل عما يحمي البيانات أثناء معالجتها في التطبيق بعد فك التشفير
- اسأل عن تغطية TLS للاتصالات الداخلية بين الخدمات، وليس فقط لواجهات برمجة التطبيقات الخارجية
- اسأل عما إذا كانت البيانات الحساسة تظهر في سجلات التطبيق
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
«كيف تُدار مفاتيح التشفير لديكم؟ وتحديداً: هل تُخزَّن في خدمة منفصلة لإدارة المفاتيح بضوابط وصول مفصولة عن البيانات التي تشفرها، أم تُدار في البيئة نفسها التي توجد فيها البيانات؟»
«ما الذي يحمي بيانات العملاء أثناء معالجتها في التطبيق بعد أن يفك تشفير التخزين لديكم تشفيرها؟ وتحديداً: ما الذي يمنع مستخدماً لديه بيانات اعتماد صالحة لقاعدة البيانات من الاستعلام عن جميع بيانات العملاء بنص واضح؟»
«هل يُطبَّق TLS على جميع الاتصالات الداخلية بين الخدمات ضمن بنية تطبيقكم، وهل تظهر بيانات العملاء الحساسة بنص واضح في سجلات التطبيق أو رسائل الأخطاء؟»
ما تتوقعه دليلًا
- وصف بنية إدارة المفاتيح: خدمة KMS، وفصل الوصول إلى المفاتيح عن الوصول إلى البيانات
- وصف الحماية أثناء الاستخدام: ضوابط الوصول، أو التشفير على مستوى الحقل، أو الحوسبة السرية للبيانات الأعلى حساسية
- تأكيد تغطية TLS للاتصالات الداخلية بين الخدمات
- تأكيد حجب حقول البيانات الحساسة في السجلات
المورد الذي يجيب عن سؤال إدارة المفاتيح بعبارة «نستخدم AES-256» قد وصف الخوارزمية مرة أخرى. اسأل تحديداً عن مكان تخزين المفاتيح ومن يمكنه الوصول إليها. فمفتاح التشفير المخزن على الخادم نفسه الذي يحمل البيانات المشفرة يوفر الحماية نفسها التي يوفرها غياب التشفير إذا اختُرق ذلك الخادم. الخوارزمية هي القفل. وإدارة المفاتيح هي ما إذا كان المفتاح معلقاً بجوار الباب.
كيف تُثبت ذلك
تتناول متطلبات التشفير كلٌّ من PCI-DSS (تشفير قوي لبيانات حاملي البطاقات)، والمواصفة القابلة للمعالجة الخاصة بالتشفير في HIPAA، والاسم المستعار والتشفير بوصفهما تدابير تقنية مناسبة في GDPR، وNIST SP 800-111. ويتطلب إثبات العناية الواجبة أدلة على أن بنية التشفير قد قُيّمت، لا مجرد التأكد من الخوارزمية.
- سجلات تقييم الموردين التي توثق أسئلة إدارة المفاتيح والحماية أثناء الاستخدام وتغطية TLS
- توثيق بنية إدارة المفاتيح لعلاقات الموردين الأعلى خطورة
- توثيق نموذج التهديدات الخاص بالتشفير: ما الذي يغطيه التشفير وما الذي تعالجه الضوابط التعويضية
- تأكيد تغطية TLS لاتصالات الخدمات
الخلاصة الرئيسية
AES-256 خوارزمية قوية. وهي تحمي البيانات الموجودة على وسيط التخزين من الاستخراج المادي. ويُفك تشفيرها تلقائياً عندما تعالج قاعدة البيانات استعلاماً. وبعد فك التشفير، تتدفق البيانات عبر التطبيق بنص واضح، وعبر شبكة الخدمات بنص واضح، وإلى ذاكرة التخزين المؤقت بنص واضح، وعلى شاشة أي شخص لديه بيانات اعتماد صالحة بنص واضح. التشفير أثناء التخزين يحمي من التهديد الذي لا ينفذه أحد: سرقة الأقراص. أما ضوابط الوصول وأمن التطبيقات وإدارة المفاتيح فتحمي من التهديدات التي تنتج عنها الاختراقات الفعلية. التأكد من الخوارزمية هو تأكد من القفل على الخزنة. أما السؤال عمن يحمل المفاتيح، ومن يمكنه فتح الخزنة، وكيف تبدو البيانات بعد مغادرتها الخزنة، فهو سؤال عن الأمن. اطرح الأسئلة الثلاثة جميعها.