אבטחת פרטי הכניסה

במדריך הזה מוסבר איך לוודא שהאפליקציה ופרטי הכניסה של המשתמשים מאובטחים.

השלמת האימות של אפליקציית OAuth

היקף ההרשאות של OAuth 2.0 ל-Google Ads API מסווג כהיקף הרשאות מוגבל, ולכן צריך להשלים את תהליך האימות של אפליקציית OAuth לפני שמעבירים את האפליקציה לסביבת הייצור. למידע נוסף, אפשר לעיין במסמכי Google Identity, במאמר במרכז העזרה בנושא אפליקציות לא מאומתות ובמסמכים בנושא הגדרת מסך הסכמה ל-OAuth.

הגנה על פרטי הכניסה של האפליקציה

חשוב לאבטח את מזהה הלקוח ואת הסוד של הלקוח ב-OAuth 2.0 של האפליקציה. פרטי הכניסה האלה עוזרים למשתמשים ול-Google לזהות את האפליקציה שלכם, ולכן חשוב לשמור עליהם היטב. חשוב להתייחס לפרטי הכניסה האלה לאפליקציות כמו לסיסמאות. אסור לשתף אותם באמצעות מנגנונים לא מאובטחים, כמו פרסום בפורומים ציבוריים, שליחת קובצי הגדרה שמכילים את פרטי הכניסה האלה כקבצים מצורפים באימייל, קידוד קשיח של פרטי הכניסה או העברתם למאגר קוד. מומלץ להשתמש במנהל סודות כמו Google Cloud Secret Manager או AWS Secret Manager כשזה אפשרי.

אם הסודות של לקוח OAuth 2.0 נחשפו, אפשר לאפס אותם. אפשר גם לאפס אסימון למפתחים.

הגנה על קוד המפתח

טוקן הפיתוח מאפשר לבצע קריאות ל-API בחשבון, אבל אין הגבלות על החשבונות שאפשר להשתמש בו כדי לבצע את הקריאות. כתוצאה מכך, מישהו אחר יכול להשתמש באסימון מפתח שנפרץ כדי לבצע קריאות שמשויכות לאפליקציה שלכם. כדי להימנע מהתרחיש הזה, כדאי לנקוט את אמצעי הזהירות הבאים:

  • חשוב להתייחס לקוד המפתח כמו אל סיסמה. אל תשתפו אותו באמצעות מנגנונים לא מאובטחים, כמו פרסום בפורומים ציבוריים או שליחת קובצי הגדרה שמכילים את טוקני המפתחים כקובץ מצורף לאימייל. מומלץ להשתמש ב-Secret Manager כמו Google Cloud Secret Manager או AWS Secret Manager כשזה אפשרי.

  • אם אסימון המפתח שלך נפרץ, עליך לאפס אותו.

    • נכנסים לחשבון הניהול ב-Google Ads שבו השתמשתם כששלחתם בקשה ל-Google Ads API.
    • עוברים אל כלים והגדרות > מרכז ה-API.
    • לוחצים על החץ לתפריט הנפתח לצד Developer token (אסימון למפתחים).
    • לוחצים על הקישור איפוס האסימון. קוד המפתח הישן שלך יפסיק לפעול באופן מיידי.
    • מעדכנים את הגדרות הייצור של האפליקציה כדי להשתמש בטוקן החדש למפתחים.

הגנה על חשבונות השירות

כדי שחשבונות שירות יפעלו בצורה תקינה עם Google Ads API, צריך להגדיר התחזות ברמת הדומיין. בנוסף, צריך להיות לקוח Google Workspace כדי להגדיר התחזות ברמת הדומיין. לכן, אנחנו לא ממליצים להשתמש בחשבונות שירות כשמבצעים קריאות ל-Google Ads API. עם זאת, אם מחליטים להשתמש בחשבונות שירות, צריך לאבטח אותם באופן הבא:

הגנה על טוקנים של משתמשים

אם האפליקציה שלכם מאשרת כמה משתמשים, כדאי לבצע פעולות נוספות כדי להגן על טוקני הגישה והרענון של המשתמשים. צריך לאחסן את האסימונים בצורה מאובטחת במצב מנוחה ואסור לשדר אותם כטקסט פשוט. משתמשים במערכת אחסון מאובטחת שמתאימה לפלטפורמה שלכם.

טיפול בביטול של טוקן רענון ובתפוגה שלו

אם האפליקציה שלכם מבקשת אסימון רענון OAuth 2.0 כחלק מההרשאה, אתם צריכים גם לטפל בביטול או בתפוגה שלהם. יכול להיות שייפסל תוקף של טוקנים לרענון מסיבות שונות, והאפליקציה צריכה להגיב בצורה חלקה על ידי אישור מחדש של המשתמש במהלך סשן ההתחברות הבא שלו, או על ידי ניקוי הנתונים שלו בהתאם. עבודות אופליין, כמו עבודות cron, צריכות לזהות ולתעד חשבונות שתוקף הטוקנים לרענון שלהם פג, במקום להמשיך לשלוח בקשות שנכשלות. יכול להיות ש-Google תבצע ויסות של אפליקציות שמייצרות רמות גבוהות של שגיאות לאורך זמן, כדי לשמור על היציבות של שרתי ה-API.

ניהול הסכמה למספר היקפים

אם האפליקציה שלכם מבקשת הרשאה למספר היקפי הרשאות של OAuth 2.0, יכול להיות שהמשתמש לא יאשר את כל היקפי ההרשאות שביקשתם. האפליקציה צריכה לטפל בדחייה של היקפי ההרשאות על ידי השבתת התכונות הרלוונטיות. אפשר להציג למשתמש הנחיה נוספת רק אחרי שהוא מציין בבירור כוונה להשתמש בתכונה הספציפית שדורשת את ההיקף. במקרים כאלה, כדאי להשתמש בהרשאות מצטברות כדי לבקש את היקפי ההרשאות המתאימים ל-OAuth.

אם התכונות הבסיסיות של האפליקציה דורשות כמה היקפי הרשאה, צריך להסביר למשתמש את הדרישה הזו לפני שמבקשים ממנו להביע הסכמה.

הקודם
סקירה כללית
הבא
רמות הגישה