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

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

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

אבטחה של חשבונות השירות

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

אבטחת אסימוני המשתמש

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

איך מטפלים בביטול ובתוקף של אסימון רענון

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

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

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

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

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