آراؤنا

مشكلة مفاتيح API التي لا تنتهي صلاحيتها أبدًا

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

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

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

العادة الأوسع في هذا المجال، أي معاملة المفتاح كبيانات اعتماد دائمة تُثبَّت مرة واحدة، تنبع من تقديم راحة التكامل الأولي على كامل عمر بيانات الاعتماد تلك. من الأسهل فعلًا، في اليوم الأول، توليد مفتاح لا يحتاج إلى أي تعديل مرة أخرى. تلك الراحة تأتي في البداية، أما التكلفة، أي مفتاح قديم غير مراقب وغير مدوَّر قابع في مكان ما كعبء دائم، فتُرحَّل إلى حادثة مستقبلية لا يفكر فيها أحد في اليوم الأول.

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