أمان مفاتيح API البريد الإلكتروني: الصلاحيات والتدوير وأين تُحفظ المفاتيح

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

الخبر السار: بضع عادات تجعل التسرّب مستبعدًا، وتحدّ من الضرر إن وقع رغم ذلك. يتناول هذا الدليل هذه العادات مستخدمًا أدوات التحكم التي توفّرها Inbixio لكل مفتاح.

ما الذي يستطيع مفتاح Inbixio فعله

لكل مفتاح تنشئه من API Keys → Create Api Key (مفاتيح API ← إنشاء مفتاح API) ثلاثة إعدادات:

• Name (الاسم)، لتنظيم مفاتيحك بنفسك، مثل prod-auth-service.
• Server Access (الوصول إلى الخادم): All Server (كل الخوادم؛ يرسل عبر أول خادم SMTP ربطته) أو Selected Server (خادم محدّد؛ الخادم الذي تختاره تحديدًا).
• Permissions (الصلاحيات): Send (إرسال) وRead (قراءة) وManage (إدارة). تملك الواجهة حاليًا نقطة نهاية واحدة هي إرسال البريد، لذا فإن Send هي الصلاحية التي تحتاجها خدماتك.

تبدو المفاتيح على هيئة ibx_ متبوعة بـ 32 حرفًا ست عشريًا. هذه البادئة تجعل التعرّف عليها سهلًا، وتسهّل على أدوات فحص الأسرار التقاطها.

القاعدة 1: مفتاح لكل خدمة وبيئة

لا تشارك مفتاحًا واحدًا على مستوى شركتك كلها. أنشئ مفتاحًا منفصلًا لكل خدمة، ولكل بيئة:

المفاتيح المنفصلة تعني:

• احتواء التسرّب. إلغاء prod-billing لا يوقف رسائل تسجيل الدخول.
• كل خدمة ترسل من العنوان الصحيح. المفتاح المربوط بخادم billing@ يرسل من billing@، لا من أي خادم ربطته أولًا. وإذا حذفت خادمًا مربوطًا بمفتاح، يعود المفتاح إلى خادمك الأول، لذا أعد ربط المفاتيح عند إزالة الخوادم.
• التدوير بلا عناء. يمكنك تجديد مفتاح خدمة واحدة دون المساس بالبقية.

القاعدة 2: امنح أقل صلاحية تؤدي الغرض

الخادم الخلفي الذي يرسل البريد يحتاج إلى Send ولا شيء غيرها، لذا اترك Read وManage دون تحديد. فكلما قلّ ما يُسمح للمفتاح بفعله، قلّت كلفة تسرّبه.

القاعدة 3: المفاتيح مكانها الخوادم لا العملاء

أي شيء يُشحن إلى متصفح أو تطبيق جوال يمكن استخراجه، سواء كان مصغّرًا أم لا. ويشمل ذلك:

• حِزم JavaScript (مكوّنات العميل في React وVue وNext.js)،
• متغيّرات البيئة ذات البادئات المخصّصة للمتصفح، مثل NEXT_PUBLIC_ أو VITE_ أو REACT_APP_،
• الملفات الثنائية لتطبيقات iOS وAndroid.

إذا كان إجراء يقوم به المستخدم في الواجهة الأمامية يستدعي إرسال بريد، فاستدعِ نقطة نهاية في الخادم الخلفي الخاص بك. يتحقق خادمك من أن المستخدم مسموح له بذلك، ويطبّق حدود المعدّل، ثم يستدعي Inbixio بالمفتاح المحفوظ في بيئته.

// ✅ Browser → your API → Inbixio
await fetch('/api/invite', { method: 'POST', body: JSON.stringify({ email }) });

// ❌ Never do this in frontend code
fetch('https://backend.inbixio.com/api/send-email/', {
  headers: { 'X-API-Key': 'ibx_…' }, // visible to every visitor
});

القاعدة 4: احفظ المفاتيح كما تحفظ كلمات المرور

• ضع المفاتيح في مدير أسرار (AWS Secrets Manager أو Google Secret Manager أو Doppler أو 1Password أو Vault) أو في متغيّرات البيئة المشفّرة لدى منصّتك.
• لا تُدرجها أبدًا في عمليات الإيداع (commit). أضف .env إلى .gitignore وفعّل فحص الأسرار في مستودعاتك؛ فميزة حماية الدفع في GitHub تمنع كثيرًا من التسرّبات قبل حدوثها.
• أبعِد المفاتيح عن السجلات. إن كنت تسجّل الطلبات الصادرة، فاحذف الترويسة X-API-Key أولًا.
• لا تلصق المفاتيح في التذاكر أو المحادثات أو لقطات الشاشة. شارك صلاحية الوصول إلى السر، لا قيمته.

القاعدة 5: دوّر المفاتيح بانتظام، وفورًا عند الشك

تستطيع Inbixio تجديد المفتاح: انقر أيقونة التحديث بجواره في صفحة API Keys. يُصدر التجديد قيمة جديدة بالاسم نفسه والوصول إلى الخادم نفسه والصلاحيات نفسها، وتتوقف القيمة القديمة عن العمل فورًا. ولتدوير مفتاح بيئة الإنتاج دون أي عملية إرسال فاشلة:

1. أنشئ مفتاحًا ثانيًا بالإعدادات نفسها (مثل prod-auth-2).
2. انشر المفتاح الجديد في الخدمة، وتأكّد من أن طلباتها تُعيد 200، في سجلات تطبيقك مثلًا.
3. احذف المفتاح القديم.

استخدم أيقونة التحديث حين تكون السرعة أهم من الانتقال السلس، كما في اللحظة التالية للتسرّب مباشرة. دوّر المفاتيح الاعتيادية كل بضعة أشهر، وكلما غادر الفريقَ شخصٌ لديه صلاحية الوصول.

إذا تسرّب مفتاح

تعامَل مع الأمر بوصفه حادثة، لكنها حادثة يمكن السيطرة عليها:

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

قائمة تحقق سريعة

• مفتاح لكل خدمة وبيئة، بأسماء واضحة
• مفاتيح مربوطة بالخادم (عنوان المُرسِل) الذي يجب أن تستخدمه كل خدمة
• صلاحية Send وحدها لخدمات الإرسال
• لا مفاتيح في شيفرة الواجهة الأمامية أو تطبيقات الجوال أو المستودعات
• مفاتيح محفوظة في مدير أسرار ومحذوفة من السجلات
• موعد للتدوير في التقويم، وخطة للتعامل مع التسرّب

والأمان أيضًا هو ما يُبقيك خارج مجلدات البريد المزعج: فالرسائل المُرسلة من مفتاح مخترَق تضرّ بسمعة نطاقك. اجمع بين قائمة التحقق هذه وSPF وDKIM وDMARC لتكتمل الصورة.