במדריך הזה מוסבר איך לוודא שהאפליקציה ופרטי הכניסה של המשתמשים מאובטחים.
השלמת האימות של אפליקציית 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.
- עוברים אל כלים והגדרות > מרכז ה-API.
- לוחצים על החץ של התפריט הנפתח לצד אסימון למפתחים.
- לוחצים על הקישור Reset token. קוד המפתח הישן שלכם אמור להפסיק לפעול באופן מיידי.
- מעדכנים את ההגדרות של האפליקציה בסביבת הייצור כך שישתמשו באסימון המפתח החדש.
אבטחה של חשבונות השירות
כדי שחשבונות שירות יפעלו בצורה תקינה עם 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 מתאימים.
אם התכונות הבסיסיות של האפליקציה שלכם דורשות כמה היקפי הרשאה, צריך להסביר את הדרישה הזו למשתמש לפני שמבקשים ממנו הסכמה.