يوضِّح هذا الدليل طريقة التأكّد من أمان بيانات اعتماد التطبيق والمستخدم.
إكمال عملية التحقّق من تطبيق OAuth
يُصنَّف نطاق OAuth 2.0 لواجهة Google Ads API على أنّه نطاق مقيّد، ما يعني أنّه عليك إكمال عملية التحقّق من تطبيق OAuth قبل إنتاج تطبيقك. لمزيد من المعلومات، يُرجى الاطّلاع على مستندات هوية Google ومقالة مركز المساعدة.
تأمين بيانات اعتماد التطبيق
يجب تأمين معرّف عميل OAuth 2.0 وسر العميل لتطبيقك. تساعد بيانات الاعتماد هذه المستخدمين وGoogle في التعرّف على تطبيقك، وبالتالي يجب التعامل معها بعناية. يجب أن تتعامل مع بيانات اعتماد التطبيق هذه مثل كلمات المرور. ولا تشاركها باستخدام آليات غير آمنة مثل النشر على المنتديات العامة، أو إرسال ملفات إعداد تحتوي على بيانات الاعتماد هذه في مرفقات البريد الإلكتروني، أو ترميز بيانات الاعتماد بشكل ثابت، أو وضعها في مستودع رموز. ننصحك باستخدام مدير سري، مثل مدير Google Cloud Secret أو AWS Secret Manager عندما يكون ذلك ممكنًا.
إذا تم اختراق أسرار عميل OAuth 2.0، يمكنك إعادة ضبطها. يمكن أيضًا إعادة ضبط الرمز المميز للمطوِّر.
تأمين الرمز المميز للمطوِّر
يتيح لك الرمز المميز للمطوِّر إجراء طلبات بيانات من واجهة برمجة التطبيقات إلى حساب، ولكن لا توجد أي قيود على الحسابات التي يمكن استخدامها لإجراء الاتصالات. ونتيجة لذلك، يمكن أن يستخدم شخص آخر الرمز المميز للمطوِّر الذي تم اختراقه لإجراء مكالمات منسوبة إلى تطبيقك. لتجنب هذا السيناريو، اتخذ الإجراءات الوقائية التالية:
تعامل مع الرمز المميز للمطوِّر ككلمة مرور. لا تشاركه باستخدام آليات غير آمنة، مثل النشر في المنتديات العامة أو إرسال ملفات إعداد تحتوي على الرموز المميزة للمطوِّر كمرفق رسالة إلكترونية. ننصحك باستخدام مدير سري، مثل مدير سر Google Cloud أو مدير AWS، إن أمكن.
وإذا تم اختراق الرمز المميز للمطوِّر، يجب إعادة ضبطه.
- سجِّل الدخول إلى الحساب الإداري على "إعلانات Google" الذي استخدمته عند تقديم طلب الاشتراك في Google Ads API.
- انتقِل إلى الأدوات والإعدادات > مركز واجهة برمجة التطبيقات.
- انقر على سهم القائمة المنسدلة بجانب الرمز المميّز للمطوِّر.
- انقر على رابط إعادة ضبط الرمز المميّز. من المفترض أن يتوقف الرمز المميز القديم للمطوِّر عن العمل على الفور.
- حدِّث إعدادات الإنتاج لتطبيقك لاستخدام الرمز المميز الجديد للمطوِّر.
تأمين حسابات الخدمة
تتطلّب حسابات الخدمة عمليات انتحال هوية على مستوى النطاق لتعمل بشكل صحيح مع Google Ads API. بالإضافة إلى ذلك، يجب أن تكون أحد عملاء Google Workspace لإعداد ميزة انتحال الهوية على مستوى النطاق. لهذه الأسباب، ننصح بعدم استخدام حسابات الخدمة عند إجراء طلبات البيانات من Google Ads API. ومع ذلك، إذا قررت استخدام حسابات الخدمة، يجب تأمينها على النحو التالي:
يمكنك اعتبار مفتاح حساب الخدمة وملف JSON كلمات مرور. تأمينهم باستخدام مدير سري مثل مدير سر Google Cloud أو مدير AWS السري متى أمكن ذلك.
اتّبِع أفضل الممارسات الإضافية من Google Cloud لتأمين حسابات الخدمة وإدارتها.
تأمين الرموز المميزة للمستخدم
إذا سمح تطبيقك لعدة مستخدمين، عليك اتّخاذ خطوات إضافية لحماية رموز الدخول وإعادة التحميل الخاصة بالمستخدمين. عليك تخزين الرموز المميّزة بأمان في حال عدم نقلها وعدم نقلها أبدًا في نص عادي. استخدم نظام تخزين آمن مناسب لنظامك الأساسي.
التعامل مع إبطال الرمز المميّز لإعادة التحميل وانتهاء صلاحيته
إذا طلب تطبيقك الرمز المميّز لإعادة تحميل بروتوكول OAuth 2.0 كجزء من التفويض، عليك أيضًا معالجة حالة إبطاله أو انتهاء صلاحيته. قد يتم إلغاء صلاحية الرموز المميّزة لإعادة التحميل لأسباب مختلفة، ومن المفترض أن يستجيب تطبيقك بشكل رشيق إما من خلال إعادة تفويض المستخدم خلال جلسة تسجيل الدخول التالية أو تنظيف بياناته حسب الحاجة. يجب أن ترصد المهام بلا اتصال بالإنترنت، مثل مهام cron، وتسجّل الحسابات التي انتهت صلاحية رموز التحديث المميزة الخاصة بها، بدلاً من الاستمرار في إرسال الطلبات التي تعذّر تنفيذها. وقد تعيق Google التطبيقات التي تتسبب في حدوث مستويات عالية من الأخطاء خلال فترة زمنية مستمرة للمحافظة على استقرار خوادم واجهة برمجة التطبيقات.
إدارة الموافقة لنطاقات متعددة
وإذا طلب تطبيقك إذنًا لعدة نطاقات OAuth 2.0، قد لا يمنح المستخدم جميع نطاقات OAuth التي طلبتها. يجب أن يتعامل تطبيقك مع رفض النطاقات من خلال إيقاف الميزات ذات الصلة. يمكنك مطالبة المستخدم مرة أخرى فقط بعد أن يشير بوضوح إلى نية استخدام الميزة المحددة التي تتطلب النطاق. يمكنك استخدام تفويض متزايد لطلب نطاقات OAuth المناسبة في مثل هذه الحالات.
إذا كانت الميزات الأساسية لتطبيقك تتطلّب نطاقات متعددة، يُرجى توضيح هذا الشرط للمستخدم قبل طلب الموافقة.