سياسة تدوير كلمات المرور والمفاتيح: متى وكيف بلا تعطيل

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

هذا الدليل يشرح ما الذي يُدوَّر، وبأي وتيرة، وكيف تنفّذ التدوير خطوة بخطوة بلا انقطاع، وماذا تفعل في أول ساعة بعد التسرّب.

ما الذي يُدوَّر ومتى

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

السر	الوتيرة الدورية	تدوير فوري عند	أثر التسرّب
رموز بوابة الدفع (secret key)	كل 90 يوماً	أي شك، مغادرة مطوّر	عمليات استرجاع أو اطلاع على بيانات معاملات
كلمة مرور قاعدة البيانات	كل 90 يوماً	تسرّب .env، مغادرة مطوّر	قراءة أو حذف كل بيانات العملاء
مفاتيح API لخدمات خارجية (SMS، واتساب، تخزين)	كل 90 يوماً	تسرّب .env أو مستودع	فواتير غير متوقعة، إرسال باسمك
مفاتيح SSH الشخصية	سنوياً أو عند تغيير الجهاز	مغادرة الشخص، فقدان الجهاز	وصول root كامل
APP_KEY في Laravel	نادراً وبحذر	تسرّب مؤكد	تزوير جلسات وفك بيانات مشفرة
كلمات مرور لوحات التحكم	كل 180 يوماً مع 2FA	مغادرة أي شخص يعرفها	تحكم كامل بالخدمة

الـ90 يوماً ليست رقماً سحرياً، لكنها توازن عملي: أقصر منها يتعب الفريق فيبدأ بالتحايل، وأطول منها يعني أن أي سر مسروق يبقى صالحاً لربع سنة كاملة. ملاحظة على APP_KEY في Laravel: تغييره يُبطل الجلسات والبيانات المشفرة بـCrypt، فإن اضطررت لتدويره استخدم خاصية APP_PREVIOUS_KEYS المتوفرة من Laravel 11 حتى تُقرأ البيانات القديمة أثناء الانتقال.

الجرد أولاً: أين يعيش كل سر

قبل أي تدوير ابنِ جدولاً بسيطاً، حتى لو كان ملف نصياً مشفراً أو خزنة في مدير كلمات مرور مشترك، فيه لكل سر: اسمه، والخدمة التي أصدرته، وكل مكان يُقرأ منه (سيرفر الإنتاج، سيرفر الطوابير، CI، جهاز مطوّر)، وصاحبه المسؤول، وتاريخ آخر تدوير. ستتفاجأ بالنتيجة غالباً، ففي جرد نموذجي لشركة بنظام ERP واحد يظهر من 25 إلى 40 سراً موزعة على 4 إلى 6 أماكن.

طريقة سريعة لاكتشاف الأماكن المنسية على السيرفرات:

# ابحث عن أي ملف يحمل جزءاً مميزاً من المفتاح القديم
grep -rl "sk_live_4f9a" /var/www /etc /home /root 2>/dev/null
# ابحث في متغيرات cron وsystemd
grep -r "DB_PASSWORD\|API_KEY" /etc/cron.d /etc/systemd/system 2>/dev/null
# وفي سجل git للمستودع (أسرار التزمت بالخطأ)
git log -p | grep -n "sk_live_\|password=" | head

إن ظهر سر داخل سجل git فاعتبره مسرّباً ودوّره، لأن حذفه من آخر commit لا يحذفه من التاريخ، وأي شخص استنسخ المستودع يملكه.

التدوير بلا توقف: نمط المفتاحين المتداخلين

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

1. أنشئ الجديد مع إبقاء القديم فعالاً. أغلب بوابات الدفع ومزودي API يسمحون بمفتاحين نشطين في نفس الوقت.
2. انشر الجديد في كل الأماكن من الجرد، ثم أعد تشغيل العمليات طويلة العمر مثل الطوابير.
3. راقب من 24 إلى 48 ساعة: هل ما زال أحد يستخدم القديم؟ أغلب المزودين يعرضون "آخر استخدام" لكل مفتاح.
4. ألغِ القديم حين يصل استخدامه إلى صفر.

مثال: كلمة مرور MySQL

MySQL 8.0.14 وما بعده يدعم كلمتي مرور لنفس المستخدم، وهذا مصمم لهذا الغرض تحديداً:

-- المرحلة 1: أضف الجديدة واحتفظ بالقديمة
ALTER USER 'app'@'10.0.0.%' IDENTIFIED BY 'New#Pass2026' RETAIN CURRENT PASSWORD;
-- المرحلة 2: حدّث .env على كل السيرفرات ثم
-- php artisan config:cache && php artisan queue:restart
-- المرحلة 4: بعد التأكد ألغِ القديمة
ALTER USER 'app'@'10.0.0.%' DISCARD OLD PASSWORD;

مثال: مفاتيح SSH

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

ssh-ed25519 AAAAC3Nz... ahmed@laptop-2026
ssh-ed25519 AAAAC3Nz... deploy@ci

بهذا يكون حذف وصول شخص سطراً واحداً، لا تغييراً لمفتاح يستخدمه خمسة.

عند مغادرة موظف: قائمة الساعة الأولى

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

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

عند تسرّب ملف .env: لا وقت للدورة العادية

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

1. مفاتيح بوابة الدفع خلال الساعة الأولى، لأنها الأسرع تحويلاً لخسارة مالية.
2. مفاتيح الخدمات المفوترة مثل SMS والتخزين وواجهات الذكاء الاصطناعي، فرسالة SMS واحدة رخيصة لكن 100 ألف رسالة ليست كذلك.
3. كلمة مرور قاعدة البيانات، مع التأكد أن المستخدم مقيد بعنوان IP لا بـ%.
4. APP_KEY وبقية الأسرار.

ثم امنع التكرار: تأكد أن خادم الويب لا يقدّم الملفات المخفية:

location ~ /\.(?!well-known) { deny all; }

وجرّب من الخارج curl -I https://example.sa/.env والمتوقع 403 أو 404، لا 200.

أين تحفظ الأسرار بين دورة وأخرى

التدوير يفقد قيمته إذا كان السر الجديد سيُرسل في محادثة واتساب أو يُلصق في ملف مشترك على Google Drive. حدّد مكاناً واحداً معتمداً للأسرار، واجعل كل نسخة أخرى منه مشتقة لا أصلية. للشركات الصغيرة يكفي مدير كلمات مرور مشترك بخزنة للفريق التقني فيها صلاحيات حسب الشخص، أما الفرق الأكبر فتستفيد من أداة مثل HashiCorp Vault أو أسرار منصة CI نفسها، حيث يُحقن السر في بيئة النشر وقت التشغيل ولا يُكتب في المستودع أبداً.

ثلاث قواعد بسيطة تمنع أغلب التسريبات:

• ملف .env في .gitignore من أول commit، مع ملف .env.example يحمل أسماء المتغيرات فقط بقيم فارغة.
• صلاحيات الملف على السيرفر 640 ومالكه مستخدم التطبيق، فلا يقرؤه مستخدم آخر على نفس الجهاز.
• أداة فحص مثل gitleaks تعمل قبل كل دفع للمستودع، فتوقف السر قبل أن يخرج من جهاز المطوّر:

gitleaks protect --staged --redact
# أو فحص كامل لتاريخ المستودع مرة واحدة
gitleaks detect --source . --redact

في تجارب فرق كثيرة، أول فحص كامل بـgitleaks على مستودع عمره سنتان يكشف من 3 إلى 10 أسرار قديمة نسيها الجميع، وكل واحد منها يستحق التدوير فوراً لأنه بقي مكشوفاً طوال هذه المدة لكل من وصل للمستودع.

تقليل عدد الأسرار أصلاً

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

ابدأ هذا الأسبوع

1. اكتب الجرد: كل سر، أماكنه، صاحبه، تاريخ آخر تدوير.
2. ضع تذكيراً متكرراً كل 90 يوماً في التقويم، باسم شخص محدد لا "الفريق".
3. نفّذ أول تدوير لسر واحد منخفض الخطورة بنمط المفتاحين لتختبر العملية.
4. اكتب قائمة المغادرة وقائمة التسرّب في ملف واحد يعرف الجميع مكانه.
5. إن كنت تخطط لنقل نظامك لسيرفر سعودي، اجعل الانتقال فرصة لتدوير كل الأسرار دفعة واحدة، وراجع الأسعار والباقات لتختار الحجم المناسب.