פריסת סריקה אוטומטית של תוכנות זדוניות בקבצים שמועלים ל-Cloud Storage

Last reviewed 2024-12-02 UTC

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

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

ארכיטקטורה

בתרשים הבא מוצגת ארכיטקטורת הפריסה שיוצרים במאמר הזה:

ארכיטקטורה של צינור עיבוד נתונים לסריקת תוכנות זדוניות.

בתרשים מוצגים שני צינורות עיבוד הנתונים הבאים שמנוהלים על ידי הארכיטקטורה הזו:

  • תהליך סריקת קבצים, שבודק אם קובץ שהועלה מכיל תוכנה זדונית.
  • צינור עיבוד נתונים לעדכון מאגר הנתונים של ClamAV, ששומר על מאגר נתונים עדכני של תוכנות זדוניות שבהן ClamAV משתמש.

למידע נוסף על הארכיטקטורה, קראו את המאמר סריקה אוטומטית של תוכנות זדוניות בקבצים שהועלו ל-Cloud Storage.

מטרות

  • בניית עותק של מסד הנתונים של הגדרות התוכנות הזדוניות של ClamAV בקטגוריה של Cloud Storage.

  • יוצרים שירות Cloud Run עם הפונקציות הבאות:

    • סריקת קבצים בקטגוריה של Cloud Storage לאיתור תוכנות זדוניות באמצעות ClamAV, והעברת הקבצים שנסרקו לקטגוריות נקיות או לקטגוריות בהסגר בהתאם לתוצאות הסריקה.
    • תחזוקה של עותק של מסד הנתונים של הגדרות התוכנות הזדוניות של ClamAV ב-Cloud Storage.
  • יוצרים טריגר של Eventarc כדי להפעיל את שירות הסריקה לאיתור תוכנות זדוניות כשמעלים קובץ ל-Cloud Storage.

  • יוצרים משימה ב-Cloud Scheduler כדי להפעיל את שירות הסריקה לאיתור תוכנות זדוניות, כדי לרענן את העותק של מסד הנתונים של הגדרות התוכנות הזדוניות ב-Cloud Storage.

חסרונות

בארכיטקטורה הזו משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

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

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

  1. נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.
  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the Artifact Registry, Cloud Build, Resource Manager, Cloud Scheduler, Eventarc, Logging, Monitoring, Pub/Sub, Cloud Run, and Service Usage APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  6. Verify that billing is enabled for your Google Cloud project.

  7. Enable the Artifact Registry, Cloud Build, Resource Manager, Cloud Scheduler, Eventarc, Logging, Monitoring, Pub/Sub, Cloud Run, and Service Usage APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  8. מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

    בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  9. בפריסה הזו, מריצים את כל הפקודות מ-Cloud Shell.

פריסת הארכיטקטורה

אפשר לפרוס את הארכיטקטורה שמתוארת במסמך הזה באחת מהשיטות הבאות:

  • שימוש ב-Cloud Shell: השתמשו בשיטה הזו אם אתם רוצים לראות איך כל רכיב של הפתרון נפרס ומוגדר באמצעות הכלי Google Cloud CLI של שורת הפקודה.

    כדי להשתמש בשיטת הפריסה הזו, פועלים לפי ההוראות במאמר פריסה באמצעות Cloud Shell.

  • באמצעות Terraform CLI: כדאי להשתמש בשיטה הזו אם רוצים לפרוס את הפתרון בכמה שפחות שלבים ידניים. בשיטה הזו, Terraform פורס ומגדיר את הרכיבים השונים.

    כדי להשתמש בשיטת הפריסה הזו, פועלים לפי ההוראות במאמר פריסה באמצעות ה-CLI של Terraform.

פריסה באמצעות Cloud Shell

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

הכנת הסביבה

בקטע הזה מקצים הגדרות לערכים שמשמשים לאורך כל הפריסה, כמו אזור ומרחב. בפריסה הזו, האזור של שירות Cloud Run הוא us-central1 והמיקום של הטריגר של Eventarc ושל הקטגוריות של Cloud Storage הוא us.

  1. ב-Cloud Shell, מגדירים משתני מעטפת נפוצים, כולל אזור ומיקום:

    REGION=us-central1
    LOCATION=us
    PROJECT_ID=PROJECT_ID
    SERVICE_NAME="malware-scanner"
    SERVICE_ACCOUNT="${SERVICE_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
    

    מחליפים את PROJECT_ID במזהה הפרויקט.

  2. מאתחלים את סביבת gcloud באמצעות מזהה הפרויקט:

    gcloud config set project "${PROJECT_ID}"
    
  3. יוצרים שלוש קטגוריות של Cloud Storage עם שמות ייחודיים:

    gcloud storage buckets create "gs://unscanned-${PROJECT_ID}" --location="${LOCATION}"
    gcloud storage buckets create "gs://quarantined-${PROJECT_ID}" --location="${LOCATION}"
    gcloud storage buckets create "gs://clean-${PROJECT_ID}" --location="${LOCATION}"
    

    הערך ${PROJECT_ID} משמש כדי לוודא ששמות הקטגוריות ייחודיים.

    שלוש הקטגוריות האלה מכילות את הקבצים שהועלו בשלבים שונים במהלך צינור עיבוד הנתונים של סריקת הקבצים:

    • ‫unscanned-PROJECT_ID: מכיל קבצים לפני שהם נסרקים. המשתמשים מעלים את הקבצים שלהם לקטגוריה הזו.

    • ‫quarantined-PROJECT_ID: מכיל קבצים ששירות סריקת התוכנות הזדוניות סרק וקבע שהם מכילים תוכנות זדוניות.

    • ‫clean-PROJECT_ID: מכיל קבצים ששירות הסריקה של התוכנות הזדוניות סרק ומצא שהם לא נגועים.

  4. יוצרים קטגוריה רביעית ב-Cloud Storage:

    gcloud storage buckets create "gs://cvd-mirror-${PROJECT_ID}" --location="${LOCATION}"
    

    ‫${PROJECT_ID} משמש כדי לוודא ששם הקטגוריה ייחודי.

    הקטגוריה cvd-mirror-PROJECT_ID משמשת לשמירה על שיקוף מקומי של מסד הנתונים של הגדרות התוכנות הזדוניות, כדי למנוע הפעלה של הגבלת קצב של יצירת בקשות על ידי ה-CDN של ClamAV.

הגדרת חשבון שירות לשירות סריקת התוכנות הזדוניות

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

  1. יוצרים את חשבון השירות של malware-scanner:

    gcloud iam service-accounts create ${SERVICE_NAME}
    
  2. מקצים את התפקיד "אדמין של אובייקטים" לקטגוריות. התפקיד מאפשר לשירות לקרוא ולמחוק קבצים מהקטגוריה של הקבצים שלא נסרקו, ולכתוב קבצים בקטגוריות של הקבצים הנקיים והקבצים שבהסגר.

    gcloud storage buckets add-iam-policy-binding "gs://unscanned-${PROJECT_ID}" \
        --member="serviceAccount:${SERVICE_ACCOUNT}" --role=roles/storage.objectAdmin
    gcloud storage buckets add-iam-policy-binding "gs://clean-${PROJECT_ID}" \
        --member="serviceAccount:${SERVICE_ACCOUNT}" --role=roles/storage.objectAdmin
    gcloud storage buckets add-iam-policy-binding "gs://quarantined-${PROJECT_ID}" \
        --member="serviceAccount:${SERVICE_ACCOUNT}" --role=roles/storage.objectAdmin
    gcloud storage buckets add-iam-policy-binding "gs://cvd-mirror-${PROJECT_ID}" \
        --member="serviceAccount:${SERVICE_ACCOUNT}" --role=roles/storage.objectAdmin
    
  3. מקצים את התפקיד "כתיבת מדדים", שמאפשר לשירות לכתוב מדדים ב-Monitoring:

    gcloud projects add-iam-policy-binding \
          "${PROJECT_ID}" \
          --member="serviceAccount:${SERVICE_ACCOUNT}" \
          --role=roles/monitoring.metricWriter
    

יצירת השירות malware-scanner ב-Cloud Run

בקטע הזה תפרסו את השירות malware-scanner ב-Cloud Run. השירות פועל בקונטיינר של Docker שמכיל את הרכיבים הבאים:

  • קובץ Dockerfile ליצירת קובץ אימג' של קונטיינר עם השירות, סביבת זמן הריצה של Node.js, ‏Google Cloud SDK וקובצי ה-binary של ClamAV.
  • קובצי TypeScript של שירות Cloud Run לסריקת תוכנות זדוניות.
  • קובץ תצורה של config.json כדי לציין את שמות הקטגוריות ב-Cloud Storage.
  • סקריפט מעטפת של updateCvdMirror.sh לרענון מסד הנתונים של הגדרות התוכנות הזדוניות של ClamAV ב-Cloud Storage.
  • סקריפט מעטפת bootstrap.sh להפעלת השירותים הנדרשים בהפעלת המכונה.

כדי לפרוס את השירות:

  1. משכפלים ב-Cloud Shell את המאגר ב-GitHub שמכיל את קובצי הקוד:

    git clone https://github.com/GoogleCloudPlatform/docker-clamav-malware-scanner.git
    
  2. עוברים לספרייה cloudrun-malware-scanner:

    cd docker-clamav-malware-scanner/cloudrun-malware-scanner
    
  3. יוצרים את קובץ התצורה config.json על סמך קובץ התבנית config.json.tmpl במאגר ב-GitHub:

    sed "s/-bucket-name/-${PROJECT_ID}/" config.json.tmpl > config.json
    

    הפקודה הקודמת משתמשת בפעולת חיפוש והחלפה כדי לתת לקטגוריות של Cloud Storage שמות ייחודיים שמבוססים על מזהה הפרויקט.

  4. אופציונלי: הצגת קובץ התצורה המעודכן:

    cat config.json
    
  5. מבצעים אכלוס ראשוני של מסד הנתונים של ClamAV לזיהוי תוכנות זדוניות ב-Cloud Storage:

    python3 -m venv pyenv
    . pyenv/bin/activate
    pip3 install crcmod cvdupdate
    ./updateCvdMirror.sh "cvd-mirror-${PROJECT_ID}"
    deactivate
    

    הפקודות האלה מתקינות באופן מקומי את הכלי CVDUpdate, ואז מריצות את הסקריפט updateCvdMirror.sh שמשתמש ב-CVDUpdate כדי להעתיק את מסד הנתונים של ClamAV לזיהוי תוכנות זדוניות לקטגוריה cvd-mirror-PROJECT_ID שיצרתם קודם.

    אתם יכולים לבדוק את התוכן של קטגוריית המראה:

    gcloud storage ls "gs://cvd-mirror-${PROJECT_ID}/cvds"
    

    הקטגוריה צריכה להכיל כמה קובצי CVD עם מסד הנתונים המלא של התוכנות הזדוניות, כמה קובצי .cdiff עם העדכונים הדיפרנציאליים היומיים, ושני קובצי JSON עם הגדרות ופרטי מצב.

  6. יוצרים ופורסים את שירות Cloud Run באמצעות חשבון השירות שיצרתם קודם:

    gcloud beta run deploy "${SERVICE_NAME}" \
      --source . \
      --region "${REGION}" \
      --no-allow-unauthenticated \
      --memory 4Gi \
      --cpu 1 \
      --concurrency 20 \
      --min-instances 1 \
      --max-instances 5 \
      --no-cpu-throttling \
      --cpu-boost \
      --timeout 300s \
      --service-account="${SERVICE_ACCOUNT}"
    

    הפקודה יוצרת מכונה של Cloud Run עם מעבד וירטואלי אחד ו-4GiB של זיכרון RAM. הגודל הזה מתאים לפריסה הזו. עם זאת, בסביבת ייצור, יכול להיות שתרצו לבחור מעבד וגודל זיכרון גדולים יותר למכונה, ופרמטר --max-instances גדול יותר. גודל המשאבים שאתם צריכים תלוי בכמות התנועה שהשירות צריך לטפל בה.

    הפקודה כוללת את המפרטים הבאים:

    • הפרמטר --concurrency מציין את מספר הבקשות שכל מכונה יכולה לעבד בו-זמנית.
    • הפרמטר --no-cpu-throttling מאפשר למכונה לבצע פעולות ברקע, כמו עדכון הגדרות של תוכנות זדוניות.
    • הפרמטר --cpu-boost מכפיל את מספר המעבדים הווירטואליים בהפעלת המכונה כדי לצמצם את זמן האחזור של ההפעלה.
    • הפרמטר --min-instances 1 שומר על לפחות מכונה אחת פעילה, כי זמן ההפעלה של כל מכונה הוא ארוך יחסית.
    • הפרמטר --max-instances 5 מונע מהשירות להתאים את קנה המידה שלו יותר מדי.
  7. כשמופיעה בקשה, כותבים Y כדי ליצור ולפרוס את השירות. תהליך ה-build והפריסה נמשך כ-10 דקות. בסיום, תופיע ההודעה הבאה:

    Service [malware-scanner] revision [malware-scanner-UNIQUE_ID] has been deployed and is serving 100 percent of traffic.
    Service URL: https://malware-scanner-UNIQUE_ID.a.run.app
    
  8. מאחסנים את הערך של Service URL מהפלט של פקודת הפריסה במשתנה מעטפת. תשתמשו בערך הזה בהמשך, כשתצרו משימה ב-Cloud Scheduler.

    SERVICE_URL="SERVICE_URL"
    
  9. אופציונלי: כדי לבדוק את השירות שפועל ואת הגרסה של ClamAV, מריצים את הפקודה הבאה:

    curl -D - -H "Authorization: Bearer $(gcloud auth print-identity-token)"  \
        ${SERVICE_URL}
    

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

    gcs-malware-scanner version 3.2.0
    Using Clam AV version: ClamAV 1.4.1/27479/Fri Dec  6 09:40:14 2024
    

בשירות Cloud Run, כל ההפעלות צריכות לעבור אימות, ולזהויות המאומתות צריכה להיות ההרשאה run.routes.invoke בשירות. בקטע הבא מוסבר איך מוסיפים את ההרשאה.

יצירת טריגר של Eventarc ל-Cloud Storage

בקטע הזה מוסיפים הרשאות כדי לאפשר ל-Eventarc לתעד אירועים ב-Cloud Storage, ויוצרים טריגר לשליחת האירועים האלה לשירות malware-scanner של Cloud Run.

  1. אם אתם משתמשים בפרויקט קיים שנוצר לפני 8 באפריל 2021, הוסיפו את התפקיד iam.serviceAccountTokenCreator לחשבון השירות של Pub/Sub:

    PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")
    PUBSUB_SERVICE_ACCOUNT="service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com"
    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PUBSUB_SERVICE_ACCOUNT}"\
        --role='roles/iam.serviceAccountTokenCreator'
    

    הוספת התפקיד הזה נדרשת רק לפרויקטים ישנים יותר, ומאפשרת ל-Pub/Sub להפעיל את שירות Cloud Run.

  2. ב-Cloud Shell, מקצים את התפקיד "פרסום הודעות ב-Pub/Sub" לחשבון השירות של Cloud Storage:

    STORAGE_SERVICE_ACCOUNT=$(gcloud storage service-agent --project="${PROJECT_ID}")
    
    gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
      --member "serviceAccount:${STORAGE_SERVICE_ACCOUNT}" \
      --role "roles/pubsub.publisher"
    
  3. מאפשרים לחשבון השירות malware-scanner להפעיל את שירות Cloud Run ולשמש כמקבל אירועים של Eventarc:

    gcloud run services add-iam-policy-binding "${SERVICE_NAME}" \
      --region="${REGION}" \
      --member "serviceAccount:${SERVICE_ACCOUNT}" \
      --role roles/run.invoker
    gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
      --member "serviceAccount:${SERVICE_ACCOUNT}" \
      --role "roles/eventarc.eventReceiver"
    
  4. יוצרים טריגר של Eventarc כדי לתעד את אירוע האובייקט הסופי בקטגוריה של Cloud Storage שלא נסרקה, ולשלוח אותו לשירות Cloud Run. הטריגר משתמש בחשבון השירות malware-scanner לצורך אימות:

    BUCKET_NAME="unscanned-${PROJECT_ID}"
    gcloud eventarc triggers create "trigger-${BUCKET_NAME}-${SERVICE_NAME}" \
      --destination-run-service="${SERVICE_NAME}" \
      --destination-run-region="${REGION}" \
      --location="${LOCATION}" \
      --event-filters="type=google.cloud.storage.object.v1.finalized" \
      --event-filters="bucket=${BUCKET_NAME}" \
      --service-account="${SERVICE_ACCOUNT}"
    

    אם מופיעה אחת מהשגיאות הבאות, המתינו דקה ואז הריצו שוב את הפקודות:

    ERROR: (gcloud.eventarc.triggers.create) INVALID_ARGUMENT: The request was invalid: Bucket "unscanned-PROJECT_ID" was not found. Please verify that the bucket exists.
    
    ERROR: (gcloud.eventarc.triggers.create) FAILED_PRECONDITION: Invalid resource state for "": Permission denied while using the Eventarc Service Agent. If you recently started to use Eventarc, it may take a few minutes before all necessary permissions are propagated to the Service Agent. Otherwise, verify that it has Eventarc Service Agent role.
    
  5. משנים את המועד האחרון לאישור ההודעה ל-5 דקות במינוי Pub/Sub הבסיסי שמשמש את הטריגר של Eventarc. ערך ברירת המחדל של 10 שניות קצר מדי לקבצים גדולים או לעומסים גבוהים.

    SUBSCRIPTION_NAME=$(gcloud eventarc triggers describe \
        "trigger-${BUCKET_NAME}-${SERVICE_NAME}" \
        --location="${LOCATION}" \
        --format="get(transport.pubsub.subscription)")
    gcloud pubsub subscriptions update "${SUBSCRIPTION_NAME}" --ack-deadline=300
    

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

יצירת משימה ב-Cloud Scheduler כדי להפעיל עדכונים של מסד הנתונים של ClamAV

  • יוצרים משימה ב-Cloud Scheduler שמריצה בקשת HTTP POST בשירות Cloud Run, עם פקודה לעדכון העותק של מסד הנתונים של הגדרות התוכנות הזדוניות. כדי למנוע מצב שבו יותר מדי לקוחות משתמשים באותה משבצת זמן, ב-ClamAV צריך לתזמן את המשימה לדקה אקראית בין 3 ל-57, ולהימנע מכפולות של 10.

    while : ; do
      # set MINUTE to a random number between 3 and 57
      MINUTE="$((RANDOM%55 + 3))"
      # exit loop if MINUTE isn't a multiple of 10
      [[ $((MINUTE % 10)) != 0 ]] && break
    done
    
    gcloud scheduler jobs create http \
        "${SERVICE_NAME}-mirror-update" \
        --location="${REGION}" \
        --schedule="${MINUTE} */2 * * *" \
        --oidc-service-account-email="${SERVICE_ACCOUNT}" \
        --uri="${SERVICE_URL}" \
        --http-method=post \
        --message-body='{"kind":"schedule#cvd_update"}' \
        --headers="Content-Type=application/json"
    

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

המשימה הזו מעדכנת רק את העותק המדויק של ClamAV ב-Cloud Storage. ה-ClamAV freshclam daemon בכל מכונה של Cloud Run בודק את ה-mirror כל 30 דקות כדי למצוא הגדרות חדשות ומעדכן את ה-ClamAV daemon.

פריסה באמצעות Terraform CLI

בקטע הזה מוסבר איך לפרוס את הארכיטקטורה שמתוארת במסמך הזה באמצעות Terraform CLI.

שכפול המאגר ב-GitHub

  1. ב-Cloud Shell, משכפלים את המאגר ב-GitHub שמכיל את הקוד ואת קובצי Terraform:

    git clone https://github.com/GoogleCloudPlatform/docker-clamav-malware-scanner.git
    

הכנת הסביבה

בקטע הזה מקצים הגדרות לערכים שמשמשים לאורך כל הפריסה, כמו אזור ומרחב. בפריסה הזו, האזור של שירות Cloud Run הוא us-central1 והמיקום של הטריגר של Eventarc ושל הקטגוריות של Cloud Storage הוא us.

  1. ב-Cloud Shell, מגדירים משתני מעטפת נפוצים, כולל אזור ומיקום:

    REGION=us-central1
    LOCATION=us
    PROJECT_ID=PROJECT_ID
    

    מחליפים את PROJECT_ID במזהה הפרויקט.

  2. מאתחלים את סביבת gcloud CLI באמצעות מזהה הפרויקט:

    gcloud config set project "${PROJECT_ID}"
    
  3. יוצרים את קובץ התצורה config.json על סמך קובץ התבנית config.json.tmpl במאגר ב-GitHub:

    sed "s/-bucket-name/-${PROJECT_ID}/" \
      docker-clamav-malware-scanner/cloudrun-malware-scanner/config.json.tmpl \
      > docker-clamav-malware-scanner/cloudrun-malware-scanner/config.json
    

    הפקודה הקודמת משתמשת בפעולת חיפוש והחלפה כדי לתת לקטגוריות של Cloud Storage שמות ייחודיים שמבוססים על מזהה הפרויקט.

  4. אופציונלי: הצגת קובץ התצורה המעודכן:

    cat docker-clamav-malware-scanner/cloudrun-malware-scanner/config.json
    
  5. מגדירים את המשתנים של Terraform. התוכן של קובץ התצורה config.json מועבר ל-Terraform באמצעות המשתנה TF_VAR_config_json, כדי ש-Terraform תדע אילו קטגוריות של Cloud Storage צריך ליצור. הערך של המשתנה הזה מועבר גם ל-Cloud Run כדי להגדיר את השירות.

    TF_VAR_project_id=$PROJECT_ID
    TF_VAR_region=us-central1
    TF_VAR_bucket_location=us
    TF_VAR_config_json="$(cat docker-clamav-malware-scanner/cloudrun-malware-scanner/config.json)"
    TF_VAR_create_buckets=true
    export TF_VAR_project_id TF_VAR_region TF_VAR_bucket_location TF_VAR_config_json TF_VAR_create_buckets
    

פריסת התשתית הבסיסית

  1. ב-Cloud Shell, מריצים את הפקודות הבאות כדי לפרוס את התשתית הבסיסית:

    gcloud services enable \
      cloudresourcemanager.googleapis.com \
      serviceusage.googleapis.com
    cd docker-clamav-malware-scanner/terraform/infra
    terraform init
    terraform apply
    

    משיבים yes כשמוצגת בקשה לעשות זאת.

    סקריפט Terraform מבצע את המשימות הבאות:

    • יצירת חשבונות השירות
    • יצירת Artifact Registry
    • יצירת הקטגוריות של Cloud Storage
    • מגדיר את התפקידים וההרשאות המתאימים
    • אכלוס ראשוני של קטגוריה של Cloud Storage שמכילה את העותק של מסד הנתונים של הגדרות התוכנות הזדוניות של ClamAV

בניית הקונטיינר של השירות

  1. ב-Cloud Shell, מריצים את הפקודות הבאות כדי להפעיל משימה של Cloud Build שתיצור את קובץ האימג' של הקונטיינר בשביל השירות:

    cd ../../cloudrun-malware-scanner
    gcloud builds submit \
      --region="$TF_VAR_region" \
      --config=cloudbuild.yaml \
      --service-account="projects/$PROJECT_ID/serviceAccounts/malware-scanner-build@$PROJECT_ID.iam.gserviceaccount.com" \
      .
    

    ממתינים כמה דקות עד שה-build יסתיים.

פריסת השירות והטריגר

  1. ב-Cloud Shell, מריצים את הפקודות הבאות כדי לפרוס את שירות Cloud Run:

    cd ../terraform/service/
    terraform init
    terraform apply
    

    עונים yes כשמוצגת בקשה.

    יכול להיות שיעברו כמה דקות עד שהשירות ייפרס ויתחיל לפעול.

    הסקריפט הזה של Terraform מבצע את המשימות הבאות:

    • פריסת השירות של Cloud Run באמצעות קובץ האימג' של הקונטיינר שיצרתם.
    • הגדרת הטריגרים של Eventarc בקטגוריות של unscanned ב-Cloud Storage. הטריגר נוצר באופן מיידי, אבל יכול להיות שיעברו עד שתי דקות עד שהוא יפעל באופן מלא.
    • יצירת משימה ב-Cloud Scheduler לעדכון הגדרות התוכנות הזדוניות של ClamAV במאגר המראה.

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

    Error: Error creating Trigger: googleapi: Error 400: Invalid resource state for "": The request was invalid: Bucket "unscanned-PROJECT_ID" was not found. Please verify that the bucket exists.
    
    Error: Error creating Trigger: googleapi: Error 400: Invalid resource state for "": Permission denied while using the Eventarc Service Agent. If you recently started to use Eventarc, it may take a few minutes before all necessary permissions are propagated to the Service Agent. Otherwise, verify that it has Eventarc Service Agent role..
    
  2. אופציונלי: כדי לבדוק את השירות שפועל ואת הגרסה של ClamAV שבה משתמשים, מריצים את הפקודות הבאות:

    MALWARE_SCANNER_URL="$(terraform output -raw cloud_run_uri)"
    curl -H "Authorization: Bearer $(gcloud auth print-identity-token)"  \
      "${MALWARE_SCANNER_URL}"
    

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

    gcs-malware-scanner version 3.2.0
    Using Clam AV version: ClamAV 1.4.1/27479/Fri Dec  6 09:40:14 2024
    

בדיקת צינור עיבוד הנתונים באמצעות העלאת קבצים

כדי לבדוק את צינור עיבוד הנתונים, מעלים קובץ אחד נקי (ללא תוכנות זדוניות) וקובץ בדיקה אחד שמדמה קובץ נגוע:

  1. יוצרים קובץ טקסט לדוגמה או משתמשים בקובץ נקי קיים כדי לבדוק את תהליכי צינור עיבוד הנתונים.

  2. ב-Cloud Shell, מעתיקים את קובץ הנתונים לדוגמה לקטגוריה שלא נסרקה:

    gcloud storage cp FILENAME "gs://unscanned-${PROJECT_ID}"
    

    מחליפים את FILENAME בשם של קובץ הטקסט הנקי. שירות סריקת התוכנות הזדוניות בודק כל קובץ ומעביר אותו לקטגוריה המתאימה. הקובץ הזה מועבר לקטגוריה "נקי".

  3. ממתינים כמה שניות עד שה-pipeline יעבד את הקובץ, ואז בודקים אם הקובץ המעובד נמצא בקטגוריה הנקייה:

    gcloud storage ls "gs://clean-${PROJECT_ID}" --recursive
    

    כדי לוודא שהקובץ הוסר מהקטגוריה של הקבצים שלא נסרקו:

    gcloud storage ls "gs://unscanned-${PROJECT_ID}" --recursive
    
  4. מעלים קובץ בשם eicar-infected.txt שמכיל את חתימת הבדיקה הרגילה של EICAR נגד תוכנות זדוניות לקטגוריה שלא נסרקה:

    echo -e 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' \
        | gcloud storage cp - "gs://unscanned-${PROJECT_ID}/eicar-infected.txt"
    

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

  5. מחכים כמה שניות ובודקים אם הקובץ עבר בהצלחה את צינור עיבוד הנתונים והגיע לקטגוריית ההסגר:

    gcloud storage ls "gs://quarantined-${PROJECT_ID}" --recursive
    

    בנוסף, השירות רושם רשומה ביומן של Logging כשמזוהה קובץ שנגוע בתוכנה זדונית.

    כדי לוודא שהקובץ הוסר מהקטגוריה של הקבצים שלא נסרקו:

    gcloud storage ls "gs://unscanned-${PROJECT_ID}" --recursive
    

בדיקת המנגנון לעדכון מסד הנתונים של הגדרות התוכנות הזדוניות

  • ב-Cloud Shell, מפעילים את הבדיקה של העדכונים על ידי אילוץ ההרצה של המשימה ב-Cloud Scheduler:

    gcloud scheduler jobs run "${SERVICE_NAME}-mirror-update" --location="${REGION}"
    

    התוצאות של הפקודה הזו מוצגות רק ביומנים המפורטים.

מעקב אחרי השירות

אתם יכולים לעקוב אחרי השירות באמצעות Cloud Logging ו-Cloud Monitoring.

הצגת יומנים מפורטים

  1. נכנסים לדף Cloud Logging Logs Explorer במסוף Google Cloud .

    כניסה לדף Logs Explorer

  2. אם המסנן Log fields לא מוצג, לוחצים על Log Fields.

  3. במסנן Log Fields, לוחצים על Cloud Run Revision.

  4. בקטע Service Name של המסנן Log Fields, לוחצים על malware-scanner.

בתוצאות השאילתה של היומנים מוצגים היומנים מהשירות, כולל כמה שורות שבהן מוצגות בקשות הסריקה והסטטוס של שני הקבצים שהעליתם:

Scan request for gs://unscanned-PROJECT_ID/FILENAME, (##### bytes) scanning with clam ClamAV CLAMAV_VERSION_STRING
Scan status for gs://unscanned-PROJECT_ID/FILENAME: CLEAN (##### bytes in #### ms)
...
Scan request for gs://unscanned-PROJECT_ID/eicar-infected.txt, (69 bytes) scanning with clam ClamAV CLAMAV_VERSION_STRING
Scan status for gs://unscanned-PROJECT_ID/eicar-infected.txt: INFECTED stream: Eicar-Signature FOUND (69 bytes in ### ms)

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

בפלט מוצגים גם יומני העדכונים של השרת המראה של הגדרות התוכנות הזדוניות:

Starting CVD Mirror update
CVD Mirror update check complete. output: ...

אם המאגר המראה עודכן, הפלט יכלול שורות נוספות:

CVD Mirror updated: DATE_TIME - INFO: Downloaded daily.cvd. Version: VERSION_INFO

יומני העדכונים של Freshclam מופיעים כל 30 דקות:

DATE_TIME -> Received signal: wake up
DATE_TIME -> ClamAV update process started at DATE_TIME
DATE_TIME -> daily.cvd database is up-to-date (version: VERSION_INFO)
DATE_TIME -> main.cvd database is up-to-date (version: VERSION_INFO)
DATE_TIME -> bytecode.cvd database is up-to-date (version: VERSION_INFO)

אם מסד הנתונים עודכן, שורות היומן של freshclam ייראו כך:

DATE_TIME -> daily.cld updated (version: VERSION_INFO)

הצגת המדדים

השירות יוצר את המדדים הבאים למטרות מעקב והתראות:

  • מספר הקבצים הנקיים שעובדו:
    workload.googleapis.com/googlecloudplatform/gcs-malware-scanning/clean-files
  • מספר הקבצים הנגועים שעובדו:
    workload.googleapis.com/googlecloudplatform/gcs-malware-scanning/infected-files
  • מספר הקבצים שהמערכת התעלמה מהם ולא סרקה:
    workload.googleapis.com/googlecloudplatform/gcs-malware-scanning/ignored-files
  • משך הזמן של סריקת הקבצים:
    workload.googleapis.com/googlecloudplatform/gcs-malware-scanning/scan-duration
  • מספר הבייטים הכולל שנסרקו:
    workload.googleapis.com/googlecloudplatform/gcs-malware-scanning/bytes-scanned
  • מספר הסריקות לאיתור תוכנות זדוניות שנכשלו:
    workload.googleapis.com/googlecloudplatform/gcs-malware-scanning/scans-failed
  • מספר הבדיקות של עדכוני CVD Mirror: ‏
    workload.googleapis.com/googlecloudplatform/gcs-malware-scanning/cvd-mirror-updates

אפשר לראות את המדדים האלה ב-Metrics Explorer של Cloud Monitoring:

  1. במסוף Google Cloud , נכנסים לדף Metrics Explorer ב-Cloud Monitoring.

    לדף Metrics Explorer

  2. לוחצים על השדה Select a metric ומזינים את מחרוזת הסינון malware.

  3. מרחיבים את המשאב משימה כללית.

  4. מרחיבים את הקטגוריה Googlecloudplatform.

  5. בוחרים את המדד googlecloudplatform/gcs-malware-scanning/clean-files. בגרף מופיעה נקודה על הגרף שמציינת מתי הקובץ הנקי נסרק.

אתם יכולים להשתמש במדדים כדי לעקוב אחרי צינור עיבוד הנתונים וליצור התראות כשמתגלה תוכנה זדונית או כשעיבוד הקבצים נכשל.

למדדים שנוצרו יש את התוויות הבאות, שבהן אפשר להשתמש לסינון ולצבירה כדי להציג פרטים מדויקים יותר באמצעות Metrics Explorer:

  • source_bucket
  • destination_bucket
  • clam_version
  • cloud_run_revision

במדד ignored_files, התוויות הבאות של reason מגדירות את הסיבה להתעלמות מהקבצים:

  • ‫ZERO_LENGTH_FILE: אם ערך ההגדרה ignoreZeroLengthFiles מוגדר והקובץ ריק.
  • ‫FILE_TOO_LARGE: כשהקובץ חורג מגודל הסריקה המקסימלי של 500MiB.
  • ‫REGEXP_MATCH: כששם הקובץ תואם לאחת מהתבניות שהוגדרו ב-fileExclusionPatterns.
  • ‫FILE_SIZE_MISMATCH: אם גודל הקובץ משתנה בזמן שהוא נבדק.

הגדרה מתקדמת

בקטעים הבאים מוסבר איך להגדיר את הסורק באמצעות פרמטרים מתקדמים יותר.

טיפול בכמה קטגוריות

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

  1. יוצרים קטגוריות של Cloud Storage עם שמות ייחודיים, ומחלקים אותן לשלוש קבוצות: קבצים שלא נסרקו, קבצים נקיים וקבצים בהסגר.

  2. מקצים את התפקידים המתאימים לחשבון השירות של malware-scanner בכל קטגוריה.

  3. עורכים את קובץ התצורה config.json כדי לציין את שמות הקטגוריות לכל הגדרה:

    {
      "buckets": [
        {
          "unscanned": "unscanned-bucket-1-name",
          "clean": "clean-bucket-1-name",
          "quarantined": "quarantined-bucket-1-name"
        },
        {
          "unscanned": "unscanned-bucket-2-name",
          "clean": "clean-bucket-2-name",
          "quarantined": "quarantined-bucket-2-name"
        }
      ],
      "ClamCvdMirrorBucket": "cvd-mirror-bucket-name"
    }
    
  4. לכל אחת מהקטגוריות שלא נסרקו, יוצרים טריגר של Eventarc. חשוב ליצור שם טריגר ייחודי לכל קטגוריה.

    הקטגוריה של Cloud Storage צריכה להיות באותו פרויקט ובאותו אזור כמו הטריגר של Eventarc.

אם אתם משתמשים בפריסה של Terraform, השלבים בקטע הזה מיושמים באופן אוטומטי כשאתם מעבירים את קובץ התצורה המעודכן של config.json במשתנה התצורה של Terraform‏ TF_VAR_config_json.

התעלמות מקבצים זמניים

שירותי העלאה מסוימים, כמו שערים של SFTP ל-Cloud Storage, יוצרים קובץ זמני אחד או יותר במהלך תהליך ההעלאה. לאחר מכן, השירותים האלה משנים את השם של הקבצים לשם הקובץ הסופי בסיום ההעלאה.

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

בקטע fileExclusionPatterns בקובץ התצורה config.json אפשר להשתמש בביטויים רגולריים כדי לציין רשימה של תבניות של שמות קבצים שצריך להתעלם מהם. כל הקבצים שתואמים לביטויים הרגולריים האלה נשארים בקטגוריה unscanned.

כשהכלל הזה מופעל, המונה ignored-files גדל, ונרשמת הודעה ביומן שמציינת שהמערכת התעלמה מהקובץ שתואם לתבנית.

בדוגמת הקוד הבאה מוצג קובץ תצורה של config.json עם הרשימה fileExclusionPatterns שמוגדרת להתעלם מקבצים שמסתיימים ב-.tmp או שמכילים את המחרוזת .partial_upload..

{
  "buckets": [
    {
      "unscanned": "unscanned-bucket-name",
      "clean": "clean-bucket-name",
      "quarantined": "quarantined-bucket-name"
    },
  ],
  "ClamCvdMirrorBucket": "cvd-mirror-bucket-name",
  "fileExclusionPatterns": [
    "\\.tmp$",
    "\\.partial_upload\\."
  ]
}

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

התעלמות מקבצים באורך אפס

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

אפשר גם להתעלם מהקבצים האלה על ידי הגדרת הפרמטר config.json ignoreZeroLengthFiles לערך true, לדוגמה:

{
  "buckets": [
    {
      "unscanned": "unscanned-bucket-name",
      "clean": "clean-bucket-name",
      "quarantined": "quarantined-bucket-name"
    },
  ],
  "ClamCvdMirrorBucket": "cvd-mirror-bucket-name",
  "ignoreZeroLengthFiles": true
}

כשהכלל הזה מופעל, המדד ignored-files גדל, ונרשמת הודעה ביומן שמציינת שהמערכת התעלמה מקובץ באורך אפס.

גודל הקובץ המקסימלי לסריקה

גודל הקובץ המקסימלי לסריקה כברירת מחדל הוא 500MiB. הגודל הזה נבחר כי סריקה של קובץ בגודל כזה נמשכת כ-5 דקות.

קבצים שגדולים מ-500MiB נשארים בקטגוריה unscanned. המדד files-ignored גדל והודעה נרשמת ביומן.

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

הסרת המשאבים

בקטע הבא מוסבר איך להימנע מחיובים עתידיים בפרויקט ב-Google Cloud שבו השתמשתם בפריסה הזו.

מחיקת הפרויקט Google Cloud

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

  1. במסוף Google Cloud , נכנסים לדף Manage resources.

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

המאמרים הבאים