أفضل الممارسات لحماية مفاتيح API ورموز الوصول

يُستخدم مفتاح API المسرب على الفور تقريبًا. تراقب الماسحات الضوئية الآلية المستودعات العامة باستمرار، وعادةً ما يتم العثور على التزام (commit) يحتوي على مفتاح وتجربته قبل أن ينهي المطور طلب السحب (pull request). لا يحتاج المفتاح إلى البقاء في الكود النهائي، لأنه يحتاج فقط إلى الوجود في مكان ما في سجل الالتزامات (commit history).

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

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