طريقة مشاركة مفاتيح API بأمان

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

ما تبقى من هذا الدليل هو التفاصيل: لماذا تفشل القنوات المعتادة، وخطوات التسليم بالضبط، وما تفعله إذا تسرب مفتاح رغم ذلك، والحالات التي لا يناسبها الرابط لمرة واحدة.

لماذا لا يصح إرسال مفتاح API عبر Slack أو البريد الإلكتروني؟

لأن كليهما يحتفظ بالرسالة ما دام أي شيء يحتفظ بها، وينسخها إلى كل جهاز وكل تصدير في الطريق.

• كلاهما قابل للبحث إلى الأبد. المفتاح الذي شاركته في 2023 قد يكون مصدر حادثتك الأمنية القادمة. والمهاجمون الذين يصلون إلى محادثات شركة أو صندوق بريدها يبحثون فيها عادةً عن السلاسل النصية التي تشبه مفاتيح API تحديدًا: sk_live و AKIA و ghp_ و Bearer.
• كلاهما يُزامَن في كل مكان. الهواتف والحواسيب المحمولة الشخصية والأجهزة اللوحية، وهي أجهزة خارج نطاق ضوابطك الأمنية وخارج متناول سياسة المسح عن بُعد لديك.
• كلاهما يُصدَّر. مراجعات الامتثال والإفصاح القانوني وعمليات تصدير مساحة العمل كلها تنتج نسخًا من السجل، وكل تصدير مكان آخر يعيش فيه المفتاح.
• كلاهما يبقى بعد مغادرة الموظف. ينتهي عقد المتعاقد، أما سلسلة الرسائل المباشرة التي فيها مفتاح Stripe لديك فلا تنتهي.

حين تضع سرًا في أي من الأداتين، فأنت تقبل أن يعيش هذا السر حيثما تصل الرسالة، ما دام أي شيء يحتفظ بها. فلم يُصمَّم أي من النظامين لينسى.

قبل المشاركة: قلّص صلاحيات المفتاح

أفضل تسليم هو الذي لا يكاد المفتاح المسلَّم فيه يهم. وقبل أن تنشئ أي شيء، طبّق مبدأ أقل الصلاحيات من المصدر:

• حدّد نطاقه. مفاتيح Stripe المقيدة ورموز الوصول الشخصية الدقيقة في GitHub وسياسات AWS IAM المحصورة في إجراءات وموارد محددة: معظم المزودين الجادين يتيحون لك إنشاء مفتاح لا يفعل إلا الشيء الوحيد الذي يحتاجه المستلم.
• فضّل صلاحية القراءة فقط ما لم تكن الكتابة ضرورية فعلًا.
• اضبط انتهاء الصلاحية لدى المزود حيث تدعمه المنصة (رموز PAT الدقيقة في GitHub، وبيانات الدخول المؤقتة في AWS عبر STS). عندها يكون حتى للمفتاح المسرَّب عمر محدود لا يتوقف على أي شيء تفعله بعد ذلك.
• سمِّ المفتاح باسم المستلم (vendor-x-readonly) حتى يكون إبطاله بعد ستة أشهر قرارًا تتخذه بنظرة واحدة، لا مشروع تنقيب في الماضي.

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

طريقة التسليم

1. أنشئ المفتاح في النظام المصدر (AWS أو Stripe أو واجهة API الخاصة بك) بأقل النطاقات اللازمة، كما ورد أعلاه.
2. الصقه في رابط سري لمرة واحدة مع تفعيل الحذف بعد القراءة وأقصر مدة صلاحية مناسبة: أقصر خيار جاهز هو 1 ساعة، يليه 24 ساعة ثم 7 أيام، ومع خطة Pro تختار تاريخًا ووقتًا مخصصين. تكفي مدة التسليم الفعلي، ولا أكثر.
3. أضف عبارة مرور، وأرسلها عبر قناة أخرى: الرابط بالبريد الإلكتروني، وعبارة المرور برسالة SMS أو رسالة مباشرة في Slack. في LinkPilot تأتي عبارة المرور ومدة الصلاحية المخصصة وسجل التدقيق مع خطة Pro بسعر $29 شهريًا. وإذا تسربت إحدى القناتين، فلا يملك المهاجم إلا نصف اللغز. (يحوّل LinkPilot عبارة المرور إلى قيمة تجزئة في المتصفح باستخدام SHA-256 قبل إرسالها، فلا تصل عبارة المرور الأصلية أبدًا إلى قاعدة بيانات الخادم أو سجلاته، ولا يتجاوز عدد المحاولات 5 لكل عنوان IP في الدقيقة.)
4. أرسل الرابط.
5. تأكد عبر قناة أخرى أن المستلم فتحه، وراجع سجل التدقيق: مشاهدة واحدة، في الوقت المتوقع، ومن الموقع المتوقع. هذا هو إيصالك.

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

مثال: تسليم مفتاح Stripe مقيد

# generate a restricted key with the minimum needed scopes
stripe api_keys create \
  --restricted \
  --display-name "vendor-x-readonly"

# pipe the resulting key into a LinkPilot secret
curl -X POST https://api.uselinkpilot.com/v1/secrets \
  -H "Authorization: Bearer $LP_KEY" \
  -d 'payload=sk_restricted_…' \
  -d 'expires_in=3600' \
  -d 'burn_after_read=true'

ما يراه المستلم: يفتح الرابط فتظهر له صفحة فيها زر الإظهار، لا المفتاح. أدوات معاينة الروابط وماسحات البريد التي تجلب عنوان URL مسبقًا لا تحصل إلا على البيانات الوصفية، لأن المشاهدة لا تُسجَّل إلا عند الضغط الصريح على زر الإظهار، وليس أبدًا عند طلب GET. وحين يضغط المستلم «إظهار» (ويُدخل عبارة المرور إن وُجدت) يرى المفتاح مرة واحدة فقط. بعد ذلك نكتب فوق المحتوى المخزن، ويعيد الرابط الرمز HTTP 410. وحتى لو تنقلت رسالة البريد بين موظفي الشركة كلها، فلم يكن بوسع أحد أن يقرأ المفتاح إلا أول من فتحه، وسجل التدقيق يبيّن لك من هو.

أي قناة لأي تسليم

ماذا تفعل إذا تسرب مفتاح API؟

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

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

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

ما يجب تجنبه

• إعادة إرسال السر نفسه. دوّره بدلًا من ذلك. فإعادة الإرسال تمحو ما يثبته سجل التدقيق من «انكشاف واحد بالضبط»، وهو ما جعل الرابط لمرة واحدة يستحق الاستخدام.
• مدد الصلاحية الطويلة. اجعل المدة القصيرة هي الإعداد الافتراضي. معظم عمليات التسليم تنتهي في دقائق، ونافذة مدتها 8 ساعات ليست إلا تسربًا أطول.
• إهمال عبارة المرور. لا تكلف شيئًا يُذكر، وتحمي من تسرب الرابط عن غير قصد: رسائل بريد يُعاد توجيهها، ومشاركة الشاشة، ومن يختلس النظر إلى شاشة مشتركة.
• لقطات الشاشة للمفاتيح. ينتهي بها المطاف في معرض الصور وفي مزامنة الصور السحابية وفي البحث عن الصور. لقطة الشاشة تبقى كما يبقى اللصق في المحادثة، لكن البحث فيها أصعب عليك وسهل على تقنية التعرف الضوئي على الحروف (OCR).
• استخدام أداة الروابط للتخزين. الرابط ساعي بريد، لا خزنة. ويجب أن يحفظ المستلم المفتاح في مدير كلمات المرور أو في أدوات متغيرات البيئة لحظة استلامه.

متى لا يناسبك الرابط لمرة واحدة

قسم المصارحة، فلهذه الطريقة حدود:

• بيانات الدخول بين الآلات مكانها مدير أسرار أو المخزن الأصلي في المنصة، وتُحقن عند النشر أو وقت التشغيل. ضغطة إنسان على رابط ليست خطوة نشر.
• بيانات الدخول المشتركة طويلة الأمد مكانها مدير كلمات مرور فيه تحكم حقيقي في الوصول وإبطال لكل شخص على حدة.
• التدوير المتكرر (مفاتيح تتغير كل ساعة) يجب أن يكون مؤتمتًا من أوله إلى آخره، ولا مكان فيه للبشر ولا للروابط.
• الأسرار التي لا تحتمل أن يلمسها أي طرف ثالث إطلاقًا: انقل تسليمها إلى خارج الإنترنت. تحديث في 29 سبتمبر 2026: كان هذا البند يقول في الأصل إن LinkPilot لا يدّعي التشفير من طرف إلى طرف (E2EE)، وينصح باستخدام أداة مشفرة من طرف إلى طرف بدلًا منه. أصبح LinkPilot الآن يشفّر المحتوى النصي في المتصفح، فلا يخزن إلا النص المشفر، ومعه الملفات المرفقة. وتوضح صفحة بنية الأمان بالضبط ما هو محمي وما ليس محميًا.

في الحالة الشائعة، أي شخص يسلّم بيانات دخول واحدة لشخص آخر مرة واحدة، يبقى الرابط لمرة واحدة مع عبارة مرور ومدة صلاحية قصيرة أقوى طريقة بسيطة متاحة.

قراءات ذات صلة

• لماذا تسرّب عناوين URL المعلومات الحساسة
• مشاركة كلمات المرور بأمان: مقارنة بين 5 طرق
• بنية الأمان في LinkPilot
• مقارنة واجهات API لاختصار الروابط
• أداة مجانية لإنشاء رابط سري

المراجع

• Stripe Docs، API keys: limit access with restricted keys.
• GitHub Docs، Managing your personal access tokens.
• AWS IAM User Guide، Temporary security credentials in IAM.