الثغرة التي لا يملؤها أحد: الهوية بين الخدمات

انظر إلى بيانات الاعتماد التي تُصدرها منظومة مراسلتك. على الأرجح هناك مفتاح واجهة لكل حساب، وربما نطاقات عليه. وهذا يغطي "يجوز لهذا التطبيق الإرسال".

ولا يغطي السؤال الذي ينشأ فعلاً في أي نظام متكامل: نيابةً عمّن، ولأي مدة؟

لأنها لم تكن تهم حين كانت المنصة تُستدعى من خادم واحد يخص شركة واحدة. فالمفتاح كان هو الهوية، وجواب "نيابةً عمّن" كان "صاحب الحساب، بداهةً".

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

وفي كل حالة تقول بيانات الاعتماد من المستدعي. ولا شيء يقول لحساب من يستدعي.

حُلّت هوية المستخدم لأنها كانت مشكلة ظاهرة: فالمستخدمون كثر ويغادرون ويُخدَعون والإخفاق عنوان صحفي. ووُجد OAuth و OIDC و SAML لأن ذلك الضغط كان دائماً.

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

الإبطال كل شيء أو لا شيء. فوصول الشريك مفتاح مشترك. وسحب تفويض عميل واحد يعني تدوير بيانات اعتماد يستخدمها كل الآخرين أيضاً.

التدقيق يجيب السؤال الخطأ. فالسجلات تدوّن أي مفتاح أرسل رسالة. وإعادة بناء أي عميل نهائي فوّض ذلك تعني ضم سجلات تطبيق قد لا تكون محفوظة.

نطاق الانفجار هو الحساب كله. فمفتاح تكامل مسرَّب يستطيع الإرسال باسم كل من يخدمهم التكامل.

تطبيق الموافقة يقع في المكان الخطأ. فالنظام الذي يحمل سجل الموافقة غالباً ليس النظام الذي يحمل بيانات الاعتماد. وبلا طريقة لقول "أنا أتصرف لهذا الموضوع"، يجب الوثوق بالمستدعي في الفحص — ما يعني أنه ليس فحصاً.

غياب هوية الخدمة لا يعلن عن نفسه. بل يظهر كسلسلة تنازلات صغيرة، كل منها معقول وحده، والسلسلة واحدة في كل مكان.

النمط راسخ خارج هذه الفئة ونادراً ما يُطبَّق داخلها.

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

لأن تركيبه لاحقاً شبه مستحيل. فمتى وُجدت تكاملات تفترض مفتاحاً طويل العمر بسلطة ضمنية، وجب تغييرها كلها، ويملك كلاً منها فريق مختلف بجدول مختلف.

والترحيل ليس صعباً تقنياً. بل صعب سياسياً، ويستغرق سنة.

الحجة المضادة واحدة دائماً: لدينا ثلاث خدمات ونعرف من هي، وهذه هندسة زائدة.

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

وكلفة فعلها مبكراً أسبوع وشيء من عدم الألفة. وكلفة فعلها متأخراً ترحيل يجب أن يظل كل شيء عاملاً خلاله.

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

والاتحاد بدونها مجموعة أسرار مشتركة في ملفات إعداد، وهو دمج بخصائص أمنية أسوأ وبلا أي من بساطته.

هذه هي الآلية التي يقوم عليها الاتحاد. فـ"يجوز للنظام أ أن يعمل نيابةً عن النظام ب، لهذا الموضوع، لهذه النافذة، قابلاً للإلغاء، بإثبات" ليس بياناً سياساتياً — بل بيانات اعتماد بالخصائص الست أعلاه.

وبلا هوية خدمة يتدهور الاتحاد إلى بيانات اعتماد مشتركة بين الأنظمة، وهي مركزة بخطوات زائدة وبلا شيء من العزل الذي كان يُفترض أن تشتريه.

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