איתור כתובות 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 פרויקט.

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

    • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (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). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (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 פרויקט.

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

    • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (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). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (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 כדי לראות את התוצאה. הקנוניזציה ועיצוב כתובת ה-URL מתבצעים על ידי שרת Web Risk. הפתרון הזה אמור להיות תקף לרוב הלקוחות, אלא אם זמן האחזור הממוצע חורג מהדרישות.

לקוח API לעדכון בסיסי

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

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

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

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

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

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