איתור כתובות URL זדוניות באמצעות Web Risk

לפני שמתחילים

הגדרת אימות והפעלה של Web Risk API

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

  2. התקינו את ה-CLI של Google Cloud.

  3. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

  4. כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה: 

    gcloud init

  5. יוצרים או בוחרים פרויקט ב- Google Cloud .

    התפקידים שנדרשים כדי לבחור או ליצור פרויקט

    • בחירת פרויקט: כדי לבחור פרויקט לא נדרש תפקיד IAM ספציפי – אתם יכולים לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים?

    • יוצרים Google Cloud פרויקט:

      gcloud projects create PROJECT_ID

      מחליפים את PROJECT_ID בשם של הפרויקט ב- Google Cloud שאתם יוצרים.

    • בוחרים את הפרויקט שיצרתם: Google Cloud 

      gcloud config set project PROJECT_ID

      מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

  6. מוודאים שהחיוב מופעל בפרויקט Google Cloud .

  7. מפעילים את Web Risk API, אם הוא עדיין לא מופעל:

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים 

    gcloud services enable webrisk.googleapis.com

  8. התקינו את ה-CLI של Google Cloud.

  9. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

  10. כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה: 

    gcloud init

  11. יוצרים או בוחרים פרויקט ב- Google Cloud .

    התפקידים שנדרשים כדי לבחור או ליצור פרויקט

    • בחירת פרויקט: כדי לבחור פרויקט לא נדרש תפקיד IAM ספציפי – אתם יכולים לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים?

    • יוצרים Google Cloud פרויקט:

      gcloud projects create PROJECT_ID

      מחליפים את PROJECT_ID בשם של הפרויקט ב- Google Cloud שאתם יוצרים.

    • בוחרים את הפרויקט שיצרתם: Google Cloud 

      gcloud config set project PROJECT_ID

      מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

  12. מוודאים שהחיוב מופעל בפרויקט Google Cloud .

  13. מפעילים את Web Risk API, אם הוא עדיין לא מופעל:

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים 

    gcloud services enable webrisk.googleapis.com
    14.

שימוש בממשקי ה-API

כשמשתמשים בממשקי Web Risk API, חשוב להכיר את הסכם רמת השירות ומגבלות השימוש של Web Risk.

כדי להתחיל להשתמש ב-Web Risk, אפשר לעיין בנושאים הבאים:

איזה API מתאים לי? חיפוש או עדכון?

יש שני ממשקי API שונים של Web Risk שאפשר לשלב. ממשקי ה-API האלה הם Lookup API ו-Update API. שני ממשקי ה-API האלה מספקים את אותו מידע. כלומר, אם כתובת URL זוהתה כזדונית. הכי קל להשתמש ב-Lookup API. באמצעות Lookup API, תוכלו לשלוח שאילתה ל-Web Risk לגבי כל כתובת URL שתרצו לבדוק.

ה-API לעדכון מורכב יותר, אבל יש לו כמה מאפיינים רצויים. באמצעות Update API, אתם יכולים לתחזק מסד נתונים מקומי. יכול להיות שנבדוק את מסד הנתונים הזה כדי לראות אם כתובת URL היא זדונית. מסד הנתונים הזה פועל כמסנן בלום. כלומר, יכול להיות שיהיו תוצאות חיוביות כוזבות (כתובת URL מזוהה כזדונית אבל היא לא), אבל לא אמורות להיות תוצאות שליליות כוזבות (כתובת URL מזוהה כלא זדונית אבל היא כן). לכן, השרתים של Web Risk לא יוצרים קשר לעיתים קרובות, והם יוצרים קשר רק כדי לאשר התאמות ולבצע הבחנה בין תוצאות חיוביות שגויות. ברוב המקרים, כשבודקים כתובת URL באמצעות Update API, לא צריך ליצור קשר עם שרתי Web Risk בכלל. השימוש בשרתי Web Risk מיועד רק לעדכון מסד הנתונים המקומי ולאישור שכתובת URL מסוימת מזיקה.

לסיכום, כדאי להשתמש ב-Lookup API אם רוצים להגדיר את התכונה במהירות ובקלות. אם אתם צריכים לבדוק כתובות URL עם זמן אחזור נמוך יותר, אתם יכולים להשתמש ב-Update API.

בחירת התכונות המתאימות ללקוח

אם בחרתם להשתמש ב-Update API, יכול להיות שלא תצטרכו להטמיע את כל המפרט. יש תכונות שמיועדות ללקוחות שמופצים באופן נרחב (כמו דפדפני אינטרנט), אבל במקרים רבים בארגונים הן נחשבות לאופטימיזציית יתר.

יש תכונות מסוימות שאפשר להתעלם מהן כדי להקל על השילוב.

אלה פתרונות לשילוב של Web Risk, לפי רמת המורכבות:

  1. שימוש ב-LookUp API
  2. לקוח API לעדכון בסיסי
  3. עדכון של לקוח API באמצעות הבדלים
  4. עדכון לקוח API באמצעות RICE compressed diffs

שימוש ב-Lookup API

השימוש ב-Lookup API הוא הכי פשוט. בכל פעם שיש כתובת URL שעלולה להיות חשודה, פשוט שולחים קריאה ל-Lookup API עם כתובת ה-URL כדי לקבל החלטה. השרת של Web Risk מטפל בקנוניזציה ובפורמט של כתובת ה-URL. הפתרון הזה אמור להיות תקף לרוב הלקוחות, אלא אם זמן האחזור הממוצע חורג מהדרישות.

לקוח Basic Update API

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

בשילוב אופייני של לקוח עם Web Risk, הלקוח יחיל הבדלים במסד הנתונים כדי להישאר מעודכן. יכול להיות שייקח קצת זמן להטמיע בצורה נכונה את לוגיקת האפליקציה של ההפרשים, לכן במקרים הפשוטים ביותר אנחנו ממליצים ללקוחות להתעלם מההפרשים ולבקש מסד נתונים חדש ומלא מ-Web Risk בכל מחזור. מסד הנתונים הזה עדיין יאוחסן בזיכרון כדי לאפשר שאילתות יעילות. כדי לבקש איפוס מלא של מסד הנתונים, משאירים את השדה versionToken ריק בבקשה threatLists.computeDiff. הפתרון הזה אמור להיות תקף ללקוחות, אלא אם רוחב הפס או זמן האחזור של סנכרון מסד הנתונים חורגים מהדרישות.

שימוש ב-Update API ובקשת עדכוני diff

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

שימוש ב-Update API ובקשה לעדכוני diff מוצפנים ב-RICE

הפתרון הזה הוא השילוב הכי יעיל שאפשר בין לקוח לשרת. קידוד RICE דוחס את גודלי ה-DIFF ומקטין עוד יותר את רוחב הפס של העדכון. הפתרון הזה מיועד ללקוחות עם רוחב הפס המוגבל ביותר. דוגמה למקרה שבו זה רלוונטי: אם שאילתות של Web Risk מוטמעות באפליקציה לטלפון. המשתמשים באפליקציה כזו בוודאי יעריכו פתרון שדורש פחות רוחב פס אם הם צריכים לעדכן את מסד הנתונים באמצעות נתונים מהטלפון. מידע נוסף זמין במאמר בנושא דחיסה.