مفتاح API ليس تفصيلاً تقنياً في عملية الربط، بل أداة دفع. من يملك سلسلة الرمز المميز ينفق رصيدك دون أي أسئلة: فالخدمة تتحقق من القيمة نفسها لا من الشخص الجالس أمام لوحة المفاتيح. يربط المطوّر الفوترة أو الأرقام أو البروكسي عبر API فيحصل على سر يبدو كمتغير عادي، لكنه في الواقع يعادل بطاقة تتيح الوصول إلى أموال الحساب. سنستعرض هنا أكثر الأماكن التي يتسرب منها المفتاح، والمكان الصحيح لحفظه، وكيفية توزيع الصلاحيات بين المهام والأشخاص، وما يجب فعله عند التسريب.
المفتاح يعادل الوصول إلى الرصيد
رمز API المميز لا يثبت الهوية، بل يثبت الحق في الإنفاق. لا يسأل النظام من أرسل الطلب بهذه القيمة، بل يتحقق من القيمة نفسها فقط. وإذا وصلت السلسلة إلى شخص غريب، فهذا بالنسبة إلى API طلب مشروع عادي: شراء رقم، أو استئجار بروكسي، أو خصم من الرصيد، وكل ذلك سيمر كعملية اعتيادية في الحساب. لا يمكن التمييز بين السرقة والاستخدام الشخصي من واقع الطلب نفسه، ولذلك فإن الحماية الوحيدة الفعالة هي منع السر من الوقوع في أيدٍ غريبة، لا محاولة كشف الانتحال بعد وقوعه.
أين لا مكان للمفتاح
يتسرب سر الوصول باستمرار عبر القنوات نفسها. مستودع الشيفرة: السلسلة التي أُدرجت في عملية commit على عجل لأجل اختبار تبقى في سجل إصدارات المستودع إلى الأبد، فحذف الملف في commit جديد لا يمحو القيمة من اللقطة الأقدم، أما المستودع المشترك أو العام فيحوّل هذا الاكتشاف إلى وصول غريب إلى الرصيد خلال دقائق. صورة الحاوية: الرمز المضمَّن في ملف البناء أو الممرَّر كوسيط بناء (build-argument) يستقر في طبقة من طبقات الصورة، وينتقل معها إلى أي سجل، بما في ذلك بيئات الاختبار التي يكون الوصول إليها أيسر منه في بيئة الإنتاج.
شيفرة الصفحة من جهة العميل: كل ما يتلقاه المتصفح وينفذه يمكن لأي زائر قراءته عبر أدوات المطوّرين، والقيمة التي تُرسل إلى الخادم دون وسيط خلفي (backend) خاص بك تظهر نصاً صريحاً. شريط عنوان الطلب: السر الذي يُمرَّر كجزء من المسار أو من معامل query في عنوان URL يُنسخ مع العنوان إلى كل مكان يستقر فيه URL: سجلات خادم الويب والبروكسي، وسجل المتصفح، وترويسة المُحيل (referer) عند الانتقال عبر رابط، وأحياناً نص الخطأ نفسه إذا أعادت الخدمة في التشخيص عنوان URL المستلَم كاملاً. المكان الصحيح له هو ترويسة الطلب، لا المسار ولا سلسلة المعاملات.
أين مكان المفتاح
القاعدة الأساسية بسيطة: يجب ألا يوجد السر في صورة نص داخل الشيفرة أو داخل إعدادات تُرفع إلى المستودع. تقرأ العملية العاملة القيمة من متغيرات البيئة المحددة على مستوى الخادم أو المنسِّق (orchestrator)، لا من ملف بجوار الشيفرة المصدرية. يُرفع ملف نموذجي للإعدادات بقيم فارغة، أما الملف الذي يحوي الرموز الفعلية فلا يصل إلى المستودع، لأنه ضمن قائمة المسارات المتجاهَلة. وفي الفرق التي تملك أكثر من سر واحد وتغيّرها بانتظام لا تكفي متغيرات البيئة: تلزم منظومة تخزين مستقلة تمنح القيمة عند الطلب، وتحتفظ بسجل للوصول، وتسحب الصلاحية دون المساس بشيفرة التطبيق.
مفاتيح منفصلة للمهام والأشخاص
رمز واحد لكل شيء هو أكثر أشكال التبسيط شيوعاً وأغلاها كلفة. فإذا اشترك خادم الإنتاج وسكربت الاختبار وتكامل طرف خارجي في قيمة واحدة، فإن سحبها عند التسريب يعني إيقاف كل شيء دفعة واحدة: تتوقف الخدمة العاملة مع بيئة الاختبار الهشة التي كانت هي مصدر التسريب أصلاً. يُستحسن توزيع الصلاحيات على محورين على الأقل: بحسب المهمة (الإنتاج، وCI، والتطوير المحلي، وتكامل الشريك)، وبحسب الشخص أو الفريق الذي يملك الوصول. عندها يصبح سحب سر واحد استجابة لحادثة محددة، لا إيقافاً للفوترة كلها. وهناك ميزة إضافية: من سجل استخدام قيمة بعينها يتضح أي مهمة تستهلك الرصيد، ويسهل تحديد موضع الشذوذ في الإنفاق فوراً.
تدوير المفاتيح: المخطط والطارئ
التدوير المخطط هو إصدار سر جديد وسحب القديم وفق جدول زمني، لا بعد وقوع حادثة. والترتيب الذي لا يسبب توقفاً هو: إصدار قيمة جديدة دون سحب السابقة؛ ثم نشرها في إعدادات الخدمة والتأكد من نجاح الطلبات؛ وبعد ذلك فقط سحب الرمز القديم. وجود قيمتين فعّالتين في آن واحد خلال فترة انتقالية قصيرة أمر طبيعي، والبنية التحتية تسمح به.
عند الاشتباه في تسريب يكون الترتيب معكوساً: السحب أولاً ثم التحليل. اسحب المفتاح المخترَق فوراً، حتى دون يقين تام، فالتوقف خلال إصدار القيمة الجديدة أرخص من إنفاق الغير من رصيدك. ثم استعرض سجل العمليات عن الفترة التي ربما تعرض فيها الوصول للاختراق، وقارنه بما فعله النظام فعلاً. وإذا كان السر محفوظاً بجوار صلاحيات أخرى، مثل كلمة مرور الخادم نفسه أو رمز خدمة مجاورة كـAPI البروكسي، فغيّرها هي أيضاً: فقناة التسريب نادراً ما تقتصر على قيمة واحدة. وكيف تتفادى بلوغ حد الطلبات بعد تغيير المفتاح تجده في مقال حدود الطلبات وتقييد معدل API.
الأسئلة الشائعة
ماذا أفعل إذا ظهر المفتاح بالفعل في مستودع عام؟
اسحبه فوراً، حتى لو حُذف commit السر بـ commit تالٍ مباشرة، فالمستودع يحتفظ بكل نسخ الملف، والحذف لا يزيل القيمة من اللقطة الأقدم. أصدر مفتاحاً جديداً، وحدّث إعدادات الخدمة، وبعد التحقق فقط حوّل حركة الطلبات إليه؛ وضع على القيمة القديمة علامة «مسحوب»، لا «غير مستخدم» فحسب.
هل يمكن إصدار مفتاح بصلاحيات محدودة بدل منح الوصول إلى كامل API؟
إذا كانت الخدمة تدعم رموزاً محدودة النطاق، مثل قراءة الرصيد فقط دون حق الخصم، فاستخدم هذه الرموز للمهام التي لا تحتاج وصولاً كاملاً. فالقيمة المحدودة إذا وقعت في أيدٍ غير مناسبة تحدّ كذلك من الضرر المحتمل.
كم مرة يجب تغيير المفاتيح إذا لم تحدث تسريبات؟
تعتمد الدورية على عدد الأشخاص والأنظمة التي تملك الوصول: كلما اتسعت الدائرة قصر الفاصل الآمن. والمعيار المعقول هو التدوير مرة كل ربع سنة على الأقل للأسرار العاملة، وفور مغادرة أي شخص كانت القيمة لديه.
تنسيق تمرير المفتاح في ترويسة الطلب، ورموز الاستجابة عند السحب وعند تجاوز الحد، موصوفة في وثائق OTP API.