مفاتيح API والأسرار بعد تغيير المطور: جرد وتدوير دون إيقاف التطبيق

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

أكثر أخطاء التدوير تأتي من معاملة كل المفاتيح كأنها كلمة مرور تُغيَّر. عمود «النوع» في الجدول يحدد طريقة التعامل:

أسرار الخادم

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

معرّفات مضمنة في التطبيق

مفاتيح داخل تطبيق الجوال يستطيع أي شخص استخراجها، فلا معنى لاعتبارها سرًا. تنص وثائق Firebase عن مفاتيح API على أن مفاتيح Firebase المقيدة بخدماتها لا تحتاج إلى معاملتها كأسرار، وأن الحماية تأتي من صلاحيات الوصول وقواعد الأمان. العلاج هنا التقييد لا التدوير: قصر مفتاح الخرائط على معرّف تطبيقك وبصمة توقيعه وعلى الواجهات التي يستخدمها. وإن احتجت إلى استبداله، فتذكر ما تقوله إرشادات أمان مفاتيح خرائط Google: المفاتيح في تطبيقات Android وiOS لا تُستبدل حتى يحدّث العملاء تطبيقاتهم.

مفاتيح التوقيع والتشفير

مفتاح تشفير التطبيق، ومفتاح توقيع رموز الجلسات، ومفتاح رفع Android، ومفتاح APNs. تغييرها له آثار جانبية: بيانات مشفرة لا تُقرأ، أو مستخدمون يخرجون من حساباتهم، أو إصدارات لا تُقبل في المتجر. هذه لا تُدوَّر قبل خطة مكتوبة لكل منها.

التوقف يحدث حين يُلغى المفتاح القديم قبل أن يعمل الجديد في كل مكان يُستخدم فيه. كل نوع من المفاتيح له نمط يمنع ذلك:

دورة تدوير مفتاح واحد دون انقطاع

1. إنشاءمفتاح جديد بجانب القديمالمنشأة
2. نشرفي الخزنة ثم في الخادمالفريق التقني
3. تحققاختبار وظيفي حقيقيالفريق والمنشأة
4. تعطيلتعطيل القديم لا حذفهالمنشأة
5. حذفبعد فترة مراقبة بلا أخطاءالمنشأة

1. مفتاحان متداخلان

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

2. مستخدم جديد بدل كلمة مرور جديدة

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

3. قبول القديم والجديد لفترة

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

4. عبر إصدار جديد من التطبيق

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

«الخادم يعمل» ليس تحققًا. كل مفتاح يُختبر بالعملية التي يخدمها فعلًا، على الإنتاج، ثم يُتأكد أن القديم لم يعد يعمل:

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

من المطور السابق، قبل خروجه أو ضمن ترتيبات التسليم:

• قائمة بكل سر أنشأه أو استخدمه، والخدمة التي يخصها، وأين وضعه.
• تأكيد مكتوب بالأماكن التي حفظ فيها نسخًا خارج أنظمة المنشأة: أجهزته، وأدوات تخزين كلمات المرور الخاصة به، والمحادثات.
• قائمة بالحسابات التي أنشأها باسمه أو ببريده، لنقلها قبل التدوير.
• التعاون خلال فترة محددة للإجابة عن سؤال «ما الذي يستخدم هذا المفتاح؟».

ومن الفريق الذي سينفذ التدوير، داخليًا أو خارجيًا:

• جدول الجرد مكتملًا وموافقًا عليه قبل تغيير أي مفتاح.
• خطة بالترتيب والتوقيت، مع طريقة الرجوع لكل مفتاح إن فشل التحقق.
• خطة مستقلة مكتوبة لكل مفتاح من الطبقة الرابعة، بأثرها على المستخدمين.
• نتائج اختبار ما بعد التدوير لكل خدمة، لا تقرير «تم».
• مكان الأسرار الجديد وصلاحيات الاطلاع عليه، وموعد التدوير الدوري التالي.

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

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

إن كنت أمام هذا الموقف الآن، احجز اجتماعًا تقنيًا لنراجع معك الجرد والترتيب ونحدد ما يُنفذ يوم التحويل وما يحتاج خطة خاصة.