تأمين بيانات الاعتماد

يعرض هذا الدليل كيفية التأكد من أمان بيانات اعتماد التطبيق والمستخدم.

إكمال عملية إثبات ملكية تطبيق OAuth

يتم تصنيف نطاق OAuth 2.0 لواجهة Google Ads API على أنّه نطاق مقيّد، ما يعني أنّه يجب عليك إكمال عملية التحقّق من تطبيق OAuth قبل إنتاج تطبيقك. يمكنك الاطّلاع على مستندات Google Identity ومقالة مركز المساعدة للحصول على مزيد من المعلومات.

تأمين بيانات اعتماد التطبيقات

يجب تأمين معرّف عميل OAuth 2.0 وسر العميل لتطبيقك. تساعد بيانات الاعتماد هذه المستخدمين وGoogle في التعرّف على تطبيقك، وبالتالي يجب التعامل معها بعناية. يجب أن تتعامل مع بيانات اعتماد التطبيق هذه مثل كلمات المرور. ويُرجى عدم مشاركتها باستخدام آليات غير آمنة، مثل النشر في المنتديات العامة، أو إرسال ملفات إعداد تحتوي على بيانات الاعتماد هذه في مرفقات البريد الإلكتروني، أو ترميز بيانات الاعتماد بشكل ثابت، أو وضعها في مستودع رموز. ننصحك باستخدام مدير سري مثل Google Cloud Secret manager أو AWS Secret Manager عندما يكون ذلك ممكنًا.

إذا تم اختراق أسرار عملاء OAuth 2.0، يمكنك إعادة ضبطها. يمكن أيضًا إعادة ضبط الرمز المميز للمطوِّر.

تأمين الرمز المميز للمطوِّر

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

  • يمكنك التعامل مع الرمز المميز للمطوِّر باعتباره كلمة مرور. ويُرجى عدم مشاركتها باستخدام آليات غير آمنة، مثل النشر في المنتديات العامة أو إرسال ملفات إعداد تحتوي على الرموز المميزة للمطوِّر كمرفق عبر البريد الإلكتروني. ونقترح عليك استخدام مدير سري مثل Google Cloud Secret Manager أو AWS Secret Manager متى أمكن.

  • إذا تم اختراق الرمز المميز للمطوِّر، يجب إعادة ضبطه.

    • سجِّل الدخول إلى الحساب الإداري على "إعلانات Google" الذي استخدمته عند تقديم طلب للاشتراك في Google Ads API.
    • انتقِل إلى الأدوات والإعدادات > مركز واجهة برمجة التطبيقات.
    • انقر على سهم القائمة المنسدلة بجانب الرمز المميز للمطوِّر.
    • انقر على رابط إعادة ضبط الرمز المميز. من المفترض أن يتوقف الرمز المميز القديم للمطوِّر عن العمل على الفور.
    • عليك تحديث إعدادات الإنتاج لتطبيقك لاستخدام الرمز المميّز الجديد للمطوِّر.

تأمين حسابات الخدمة

تتطلّب حسابات الخدمة انتحال الهوية على مستوى النطاق لكي تعمل بشكل صحيح مع Google Ads API. بالإضافة إلى ذلك، يجب أن تكون أحد عملاء Google Workspace لإعداد ميزة انتحال الهوية على مستوى النطاق. لهذه الأسباب، ننصحك بعدم استخدام حسابات الخدمة عند إجراء استدعاءات Google Ads API. ومع ذلك، إذا قررت استخدام حسابات الخدمة، عليك تأمينها على النحو التالي:

تأمين الرموز المميزة للمستخدم

إذا كان تطبيقك يسمح للعديد من المستخدمين، عليك اتّخاذ خطوات إضافية لحماية رموز إعادة التحميل والوصول للمستخدمين. تخزين الرموز المميّزة بشكل آمن غير مفعَّل وعدم إرسالها بتنسيق نص عادي استخدِم نظام تخزين آمن مناسب لنظامك الأساسي

التعامل مع إبطال الرمز المميّز لإعادة التحميل وانتهاء صلاحيته

إذا طلب تطبيقك الرمز المميّز لإعادة تحميل بروتوكول OAuth 2.0 كجزء من التفويض، عليك أيضًا معالجة عملية إبطاله أو انتهاء صلاحيته. يمكن أن تُبطل الرموز المميزة لإعادة التحميل لأسباب مختلفة، ويجب أن يتجاوب تطبيقك بشكل جيد إما من خلال إعادة تفويض المستخدم أثناء جلسة تسجيل الدخول التالية، أو بتنظيف بياناته على النحو المناسب. يجب أن ترصد المهام بلا اتصال بالإنترنت، مثل مهام cron، وتسجّل الحسابات التي انتهت صلاحية رموز إعادة التحميل الخاصة بها، بدلاً من مواصلة تقديم الطلبات التي تعذّر تنفيذها. قد تقيّد Google التطبيقات التي تنشئ مستويات عالية من الأخطاء خلال فترة زمنية طويلة للحفاظ على استقرار خوادم واجهة برمجة التطبيقات.

إدارة الموافقة لنطاقات متعدّدة

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

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