كثيرًا ما تكون التكاملات مع منصات مثل Stripe وShopify وSalesforce هي المواضع التي تنتقل فيها البيانات الحيوية للأعمال والأموال بين الأنظمة. وهي أيضًا مواضع شائعة للاختصارات: مفتاح API يُلصق في شيفرة الواجهة الأمامية، أو نقطة نهاية Webhook تقبل أي طلب، أو مهمة مزامنة تفشل بصمت. ينشر كل مزوّد إرشادات أمنية مفصّلة، لكن شيفرة التكامل التي يكتبها فريقك تظل مسؤوليتك. يتناول هذا الدليل الضوابط العملية التي تجعل التكاملات أكثر أمانًا وموثوقية.
ما هو
يحمي التكامل الآمن ثلاثة أمور: بيانات الاعتماد التي تمنح الوصول، والبيانات المتدفقة بين الأنظمة، وسلامة أحداث الأعمال التي تُطلق الإجراءات. وتشمل بيانات الاعتماد مفاتيح API ورموز OAuth وأسرار العملاء؛ وينبغي ألا توجد إلا على الخادم، في مدير للأسرار أو في إعدادات بيئة محمية، وبأضيق الصلاحيات التي يحتاجها التكامل. وتنتقل البيانات عبر HTTPS، وتقتصر البيانات المخزّنة على ما تحتاج الأعمال فعلًا إلى تخزينه. وتعتمد سلامة الأحداث على التحقق من أن رسائل Webhook الواردة صادرة فعلًا عن المزوّد. فعلى سبيل المثال، يوقّع Stripe أحداث Webhook بسرّ توقيع ويوفر ترويسة توقيع ينبغي لنقطة النهاية لديك التحقق منها؛ ويوقّع Shopify رسائل Webhook بترويسة HMAC؛ وتعتمد تكاملات Salesforce عادةً على OAuth عبر تطبيق متصل (Connected App) أو بديله الأحدث، تطبيق العميل الخارجي (External Client App)، مع صلاحيات محددة النطاق. والموثوقية مهمة أيضًا. فقد تصل رسائل Webhook متأخرة، أو أكثر من مرة، أو بغير ترتيبها، ولذلك ينبغي أن تكون المعالِجات غير متأثرة بالتكرار (Idempotent)، وأن تتعامل الاستدعاءات الصادرة مع حدود المعدل وإعادة المحاولة دون تكرار الرسوم أو الطلبات أو السجلات. ولهذا السبب يدعم Stripe مفاتيح عدم التكرار (Idempotency Keys).
لمن هذا؟
هذا الدليل موجّه إلى:
- الفرق التي تربط المدفوعات أو الاشتراكات أو مسارات إتمام الشراء بأنظمتها الخاصة
- شركات التجارة الإلكترونية التي تزامن الطلبات أو المخزون أو العملاء بين Shopify ومنصات أخرى
- الشركات التي تدمج بيانات إدارة علاقات العملاء من Salesforce مع أدوات داخلية أو بوابات للعملاء
- مالكي المنتجات الذين يراجعون أعمال تكامل سلّمتها وكالة أو مستقل
ما يساعد على توضيح
يساعد العمل على هذه الضوابط في توضيح:
- أين تُخزَّن بيانات الاعتماد، ومن يمكنه الوصول إليها، وكيف تُدوَّر
- ما إذا كانت نقاط نهاية Webhook تتحقق من التواقيع وترفض الطلبات غير الموقّعة أو المعاد إرسالها
- كيف تُعالَج الأعطال وإعادة المحاولة والتكرارات دون إفساد البيانات
- البيانات التي تُنسخ بين الأنظمة، وما إذا كانت كلها ضرورية
ما هو متضمن
- أبقِ مفاتيح API السرية على الخادم فقط؛ واستخدم المفاتيح القابلة للنشر أو العامة في تطبيقات العملاء حيثما يدعمها المزوّد
- خزّن الأسرار في مدير للأسرار أو في إعدادات محمية، ولا تخزّنها أبدًا في مستودعات الشيفرة المصدرية
- اطلب أضيق النطاقات والصلاحيات؛ واستخدم بيانات اعتماد منفصلة لكل بيئة
- دوّر بيانات الاعتماد وفق جدول، وفورًا بعد تغييرات الموظفين أو الموردين
- تحقق من تواقيع Webhook بالطريقة الموثقة لدى المزوّد، وارفض الطلبات التي تفشل في التحقق
- تحقق من الطوابع الزمنية للأحداث للحد من خطر إعادة الإرسال، وسجّل معرّفات الأحداث المعالَجة
- اجعل المعالِجات غير متأثرة بالتكرار حتى لا تُنشئ الأحداث المتكررة إجراءات مكررة
- استخدم مفاتيح عدم التكرار أو تدابير حماية مماثلة في عمليات الإنشاء الصادرة حيثما كان ذلك مدعومًا
- تعامل مع حدود المعدل بالتراجع التدريجي، وضع العمل في طابور بدلًا من إسقاطه
- سجّل أحداث التكامل دون تسجيل الأسرار أو بيانات البطاقات أو البيانات الشخصية غير الضرورية
- نبّه شخصًا ما حين تفشل مهام المزامنة أو رسائل Webhook بشكل متكرر
- اختبر في بيئة sandbox أو وضع الاختبار لدى المزوّد قبل التحول إلى بيانات الاعتماد الحية
ما لا يشتمل عليه
- التحقق من الامتثال لمعيار PCI DSS أو موافقة معالج المدفوعات
- عمليات مكافحة الاحتيال أو إدارة المبالغ المعترض عليها
- ادعاء بأن اتباع هذه الضوابط يمنع كل حادث تكامل
- تشغيل منصات الأطراف الثالثة، الذي يظل من مسؤولية المزوّدين
متى تختارها
استخدم قائمة التحقق هذه عند تصميم تكامل جديد، وقبل التشغيل الفعلي، وعند وراثة شيفرة تكامل من فريق آخر، وبعد أي حادث ينطوي على مدفوعات مكررة أو طلبات مفقودة أو وصول غير متوقع إلى البيانات. وهي مهمة بشكل خاص حين يكون بإمكان التكامل إطلاق إجراءات مالية، مثل تحصيل الرسوم أو ردّ المبالغ أو تغيير الاشتراكات، أو كشف سجلات العملاء.
نهجنا
تعامل مع كل تكامل بوصفه منتجًا صغيرًا له مالك وتوثيق ومراقبة خاصة به. ابدأ بجرد التكاملات وبيانات الاعتماد ونقاط نهاية Webhook؛ فكثير من المؤسسات تكتشف مفاتيح لا يتذكر أحد إنشاءها. ثم طبّق الضوابط المذكورة أعلاه حسب ترتيب المخاطر: الأسرار والتحقق من التواقيع أولًا، ثم عدم التكرار ومعالجة الأعطال، ثم التسجيل والتنبيه. تصمّم خدمتنا «Secure Backend & API Engineering» أعمال الواجهات الخلفية والتكامل وتنفّذها مع عقد API وملخص للاختبارات ودليل للتشغيل، ولا يُستخدم الوصول إلى بيئة الإنتاج وبيانات العملاء إلا بموجب تفويض كتابي صريح. وحيثما تتعلق المسألة بمنطق المدفوعات والاشتراكات، يمكن لخدمة «Subscription & Payment Infrastructure Security» مراجعة مسارات الدفع والاستحقاقات المتفق عليها بشكل منفصل. وإذا أردت فحصًا مستقلًا لنقاط نهاية التكامل القائمة، فيمكن لمراجعة أمن التطبيقات أن تشملها في نطاقها.
الأسئلة المتكررة
مقالات ذات صلة
ابدأ
هل تخطط لتكامل حيوي للأعمال أو تراجعه؟
شاركنا المنصات المعنية، والبيانات والأحداث التي تتدفق بينها، وأي مشكلات لاحظتها. وسنقترح نطاقًا مكتوبًا.
اطلب نطاقًا مكتوبًا