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

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

تتقارب المزوّدات الثلاثة الكبرى نحو البنية ذاتها: مفتاح التشفير الذي تولّده خدمتها المُدارة الأصلية لا يغادر أبدًا وحدات أمنها المادية، أيًّا كانت شهادة FIPS الدقيقة (المستوى 2 لـ Azure Key Vault Premium، والمستوى 3 لـ AWS CloudHSM وGoogle Cloud HSM). الآلية الموثّقة في الفصل الأول ليست إذن خصوصية لمزوّد واحد، بل اتفاقية بنيوية مشتركة بين الفاعلين الثلاثة الرئيسيين في السوق.

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

الهوية والمفتاح مُغلقان في آن واحد بأثر تراكمي غير مقصود (آرثر) وبلاتماثل بنيوي في ملكية البنية التحتية المادية التي تصادق عليهما (غروسمان وهارت). الركيزة الثانية تفسّر لماذا يقاوم هذا الإغلاق حتى حوكمة مفتوحة لطبقة التنسيق (المجلد السابع): فالحوكمة البرمجية لا تنقل ملكية وحدة الأمن المادية.

لا شيء في متطلبات SecNumCloud الموثَّقة يُلزم المزوّد المؤهَّل بضمان قابلية التصدير التشغيلية لمفتاح تشفير أُنشئ تحت رقابته نحو بنية تحتية لمزوّد آخر. تحمي المرجعية سلامة المفتاح وسريته ما دام لدى المزوّد المؤهَّل — لا تتناول قابليته للنقل عند لحظة الخروج.

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

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

يمكن لمؤسسة تستخدم SPIFFE/SPIRE أن تحمل الهوية ذاتها لحمل العمل، قابلة للتحقق تشفيريًا، عبر عدة بيئات سحابية في آن واحد — شرط ضروري كي لا يكسر تغيير المزوّد فورًا سلسلة التفويض التطبيقية.

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

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

رفض جيميني اقتراح إعادة صياغة استبدال Keycloak/Vault الذي عولج بالفعل في المجلد الرابع، معتبرًا إياه غير كافٍ أمام الاعتراض التقني المتعلق بهوية حمل العمل. أعاد كلود توجيه الهدف التجريبي نحو SPIFFE/SPIRE وبروتوكول KMIP، وتحقّق منهما بشكل مستقل قبل صياغة الفصل الثالث.

أكّد كلود المرجعين النظريين عبر بحث مستقل (العنوان الدقيق، المجلة، المجلد، الصفحات). أكّد المادية التجريبية بشأن AWS KMS وAzure Key Vault (nCipher/Thales، FIPS 140-2 المستوى 2) وGoogle Cloud KMS (FIPS 140-2 المستوى 3) مباشرة من الوثائق الرسمية لكل من المزوّدين الثلاثة، في إطار التدقيق الشامل الذي طلبه جيميني على المسودة الأولى. أشار كلود، بدلًا من التصحيح الصامت، إلى خطأ في مستوى FIPS الذي قدّمه جيميني أولًا بشأن Azure (اقترح المستوى 3، وأكّدت وثائق مايكروسوفت المستوى 2).

أكّد كلود، من مصادر متعددة متّسقة، مضمون متطلبات SecNumCloud بشأن إدارة المفاتيح (التوليد، التخزين، التوزيع، الإلغاء)، دون أن تذكر أي منها التزامًا بقابلية نقل المفتاح الوظيفي. كان جيميني قد اقترح اقتباسًا نصيًا من المادة 30؛ رأى كلود، بعد التحقق، أنه أقرب إلى التقريب منه إلى الدقة ليُستنسخ كما هو، فاستعاض عنه بركيزة أدق، مستندة إلى تعريف «البيانات القابلة للتصدير» (المادة 2، البند 38 — استثناء خطر أمن سيبراني) و«الأصل الرقمي» (حق استخدام مستقل عن العقد)، بما يعزّز فرضية الثغرة الدلالية التي طرحها جيميني دون استنساخ صياغته غير الدقيقة.

أكّد كلود، من مصادر تقنية متعددة متّسقة، أن مصادقة العقدة في SPIRE تعتمد على واجهات برمجية لبيانات وصفية خاصة بكل مزوّد حوسبة سحابية (وثيقة هوية مثيل AWS EC2، رموز بيانات وصفية لـ GCP، مصادقة Azure). سمح هذا التأكيد لكلود بالتحقق من البرهان المركزي للفصل الثالث دون تأكيده اعتمادًا على الذاكرة.

أشار جيميني إلى لاتماثل في المادية بين AWS من جهة، وAzure وGoogle Cloud من جهة أخرى في الفصل الأول؛ صحّحه كلود بحقن مادية تجريبية متماثلة للمزوّدين الثلاثة. اعتبر جيميني الغموض القانوني في الفصل الثاني بشأن Data Act غير مرسَّخ نصيًا بما يكفي؛ صحّحه كلود بركيزة على المادة 2، البندين 37 و38، بعد أن تبيّن أن الاقتباس الذي اقترحه جيميني غير قابل للتحقق كما هو.

برّر جيميني تقرير تدقيقه الأولي بالقول إنه كان يقصد خدمة Azure Dedicated HSM (المستوى 3) لا Key Vault Premium. تحقّق كلود من هذه الحقيقة، الصحيحة إذا أُخذت بمعزل — فـ Dedicated HSM يبلغ فعلًا المستوى 3 — لكنه لاحظ أن صياغة جيميني الأصلية جمعت هاتين الخدمتين المتمايزتين من Azure تحت مستوى شهادة واحد، وهو ما شكّل خلطًا. التصحيح الذي كان كلود قد أجراه في المسودة الثانية (المستوى 2 لـ Key Vault Premium) يبقى دقيقًا ولم يحتج إلى تعديل إضافي بعد هذا التدقيق المضاد.