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

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

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

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

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

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

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

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

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

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

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

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

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

النمط راسخ خارج هذه الفئة، وأقل تطبيقاً داخلها.

وعملياً يعني ذلك:

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

ولا شيء من هذا يحتاج اختراعاً. فتبادل الرموز في OAuth 2.0 (RFC 8693) يصف كيف تحصل خدمة على رمز للعمل نيابةً عن طرف آخر؛ ورموز JSON Web Tokens (RFC 7519) تحمل ادعاءات موقّعة قابلة للتحقق؛ و TLS المتبادل مع الرموز المربوطة بالشهادة (RFC 8705) يربط الرمز بالعميل الذي يقدّمه؛ وأطر هوية أحمال العمل مثل SPIFFE تعطي كل خدمة هوية قابلة للتحقق بلا أسرار مشتركة. وإرشادات "انعدام الثقة" مثل NIST SP 800-207 تصف المبدأ نفسه على مستوى البنية كلها.

إن كنت تشتري لا تبني، فهذه الأسئلة تكشف إلى أي حد تدعم المنصة هذا:

1. هل أستطيع إنشاء بيانات اعتماد محصورة في حساب فرعي واحد أو قناة أو قدرة واحدة؟
2. هل تدعمون رموزاً قصيرة العمر، وهل أستطيع سحب واحد منها دون تدوير البقية؟
3. حين يتصرف شريك أو موزّع نيابةً عني، هل يُظهر سجل التدقيق أي طرف تصرف وبأي سلطة؟
4. هل أستطيع رؤية سجلات التدقيق تلك وتصديرها والاحتفاظ بها؟

منصات كثيرة تدعم الحسابات الفرعية والمفاتيح محددة النطاق؛ وأقل منها تدعم التفويض مع السحب لكل عميل. ومعرفة ما تحصل عليه تجنّبك المفاجآت.

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

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

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

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

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

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

• اتحاد الأنظمة دون دمجها: البنية التي تدعمها طبقة الهوية هذه.
• تقييم عقد منصة اتصال: الأسئلة التعاقدية التي تقترن بالأسئلة التقنية أعلاه.