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

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

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

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

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

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

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

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

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

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

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

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

ניהול הסכמה למספר היקפי הרשאות

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

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

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