وظيفة مجدولة أم تسجيل دخول بشري: أي هوية ينبغي أن تراها واجهة API؟

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

ثلاث بوابات تبدو كأنها واحدة

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

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

المسار التفاعلي قالب أتمتة سيئ

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

البديل المدعوم هو عادةً تدفق عميل سري يتحقق فيه خادم التفويض من التطبيق ويصدر رمزًا. ومنح بيانات اعتماد العميل في RFC 6749 القسم 4.4 مثال على ذلك. ووجود هذا المنح لا يعني أن كل واجهة API تقبله، أو أن مهمة مفوَّضة من مستخدم يمكن استبدالها به، لأن تلك أسئلة يملك صاحب الخدمة جوابها. اسأل أي نموذج دون إشراف تدعمه الخدمة قبل كتابة أي شيفرة.

أين يبقى VPN في مكانه

يمكن لـVPN أن يوفّر مسار الشبكة الذي تتطلبه واجهة API خاصة، وهذا دور مشروع. لكنه لا يصادق الوظيفة أمام التطبيق، ولا يحدد نطاق ما يجوز للوظيفة فعله. كما أن عنوان خروج مشتركًا يعرّف المضيف لا الوظيفة، لذا فإن إدخالًا في قائمة السماح لذلك العنوان يسمح لكل عملية تعمل عليه.

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

قارن التصميمين بصدق

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

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

ما يجب التحقق منه قبل التسليم

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

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

سجّل الفاعل والنطاق ومالك التدوير وبيئة التنفيذ بجانب تلك النتيجة. ذلك السجل هو ما يجعل التدوير التالي روتينيًا لا حادثًا. وهو أيضًا الجزء الذي يطلبه المدقق.