במדריך הזה מוסבר איך לוודא שהאפליקציה ופרטי הכניסה של המשתמש מאובטחים.
השלמת תהליך האימות של אפליקציות OAuth
היקף ההרשאות ל-OAuth 2.0 ב-Google Ads API מסווג כהיקף מוגבל, כלומר, צריך להשלים את תהליך האימות של אפליקציות ה-OAuth לפני הפקת האפליקציה. למידע נוסף, אפשר לעיין במסמכי התיעוד של Google Identity ובמאמר במרכז העזרה.
אבטחת פרטי הכניסה של האפליקציה
עליך לאבטח את מזהה הלקוח ואת סוד הלקוח של OAuth 2.0 של האפליקציה שלך. פרטי הכניסה האלה עוזרים למשתמשים ול-Google לזהות את האפליקציה, ולכן יש לטפל בהם בזהירות. צריך להתייחס לפרטי הכניסה האלה של האפליקציה כמו לסיסמאות. אל תשתפו אותם באמצעות מנגנונים לא מאובטחים כמו פרסום בפורומים ציבוריים, שליחת קובצי תצורה שמכילים את פרטי הכניסה האלה בקבצים מצורפים לאימייל, קידוד קשיח של פרטי הכניסה או התחייבות למאגר קוד. מומלץ להשתמש במנהל סודות, כמו Google Cloud Secret Manager או AWS Secret Manager כשאפשר.
אם סודות הלקוח ב-OAuth 2.0 נחשפו, תוכלו לאפס אותם. אפשר גם לאפס אסימון מפתח.
אבטחת קוד המפתח
קוד המפתח מאפשר לבצע קריאות ל-API בחשבון, אבל אין הגבלות על החשבונות שאפשר להשתמש בו לביצוע הקריאות. כתוצאה מכך, מישהו אחר יכול להשתמש בקוד מפתח שנפגע, כדי לבצע קריאות שמשויכות לאפליקציה שלכם. כדי למנוע מצב כזה, כדאי לנקוט את אמצעי המניעה הבאים:
מתייחסים לקוד המפתח שלכם כאל סיסמה. אל תשתפו אותו באמצעות מנגנונים לא מאובטחים, כמו פרסום בפורומים ציבוריים או שליחת קובצי תצורה שמכילים את האסימונים למפתחים כקובץ מצורף לאימייל. מומלץ להשתמש במנהל סודות, כמו Google Cloud Secret Manager או AWS Secret Manager כשאפשר.
אם קוד המפתח שלך נפרץ, יש לאפס אותו.
- נכנסים לחשבון הניהול ב-Google Ads שבו השתמשתם כשהגשתם בקשה ל-Google Ads API.
- עוברים אל Tools & Settings (כלים והגדרות) > API Center.
- לוחצים על החץ לתפריט הנפתח לצד אסימון מפתח.
- לוחצים על הקישור איפוס האסימון. קוד המפתח הישן שלכם אמור להפסיק לפעול מיד.
- מעדכנים את ההגדרות האישיות בסביבת הייצור של האפליקציה כדי להשתמש בקוד המפתח החדש.
אבטחת חשבונות השירות
כדי להשתמש ב-Google Ads API בצורה תקינה באמצעות חשבונות שירות, צריך להתחזות ברמת הדומיין. בנוסף, אתם צריכים להיות לקוחות של Google Workspace כדי להגדיר התחזות ברמת הדומיין. לכן, מומלץ לא להשתמש בחשבונות שירות כשמבצעים קריאות ל-Google Ads API. עם זאת, אם תחליטו להשתמש בחשבונות שירות, צריך לאבטח אותם באופן הבא:
יש להתייחס למפתח של חשבון השירות ולקובץ ה-JSON כסיסמאות. אבטח אותם באמצעות מנהל סודות, כמו Google Cloud Secret Manager או AWS Secret Manager כשאפשר.
כדאי ליישם את השיטות המומלצות הנוספות מ-Google Cloud כדי לאבטח ולנהל את חשבונות השירות שלכם.
אבטחת אסימוני המשתמש
אם האפליקציה שלך מאשרת מספר משתמשים, עליך לבצע פעולות נוספות כדי להגן על אסימוני הרענון ואסימוני הגישה של המשתמשים. חשוב לאחסן את האסימונים באופן מאובטח באחסון ואף פעם לא לשדר אותם בטקסט פשוט. השתמשו במערכת אחסון מאובטחת שמתאימה לפלטפורמה שלכם.
טיפול בביטול ובתפוגה של אסימון רענון
אם האפליקציה שלכם מבקשת אסימון רענון מסוג OAuth 2.0 כחלק מההרשאה, עליכם לטפל גם בביטול או תפוגה של האסימון. אסימוני הרענון עלולים להתבטל מסיבות שונות, והאפליקציה שלכם אמורה להגיב בצורה נאותה על ידי אישור מחדש של המשתמש במהלך סשן ההתחברות הבא שלו או על ניקוי הנתונים שלו לפי הצורך. משימות אופליין, כמו משימות cron, צריכות לזהות ולתעד חשבונות שפג התוקף של אסימוני הרענון שלהם, במקום להמשיך לשלוח בקשות שנכשלו. כדי לשמור על היציבות של שרתי ה-API, Google עשויה לווסת אפליקציות שיוצרות רמות גבוהות של שגיאות לאורך תקופה ממושכת.
ניהול הסכמה במספר היקפים
אם האפליקציה מבקשת הרשאה למספר היקפי הרשאות OAuth 2.0, יכול להיות שהמשתמש לא יספק את כל היקפי ההרשאות של OAuth שביקשתם. האפליקציה שלכם אמורה לטפל בדחיית היקפים על ידי השבתת התכונות הרלוונטיות. תוכלו לבקש מהמשתמש שוב רק אחרי שהוא יציין בבירור כוונה להשתמש בתכונה הספציפית שדורשת את ההיקף. במקרים כאלה, כדאי להשתמש בהרשאה מצטברת כדי לבקש היקפים מתאימים של OAuth.
אם לתכונות הבסיסיות של האפליקציה נדרשות כמה היקפים, צריך להסביר את הדרישה הזו למשתמש לפני שמבקשים הסכמה.