שיטות מומלצות להגנה מפני מתקפות כריית מטבעות קריפטוגרפיים

Last reviewed 2023-10-20 UTC

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

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

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

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

זיהוי וקטורי האיומים

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

בדוח Threat Horizons מנובמבר 2021 מצוין שרוב התוקפים מנצלים נקודות חולשה כמו אלה:

  • סיסמה חלשה או ללא סיסמה בחשבונות משתמש
  • אימות חלש או ללא אימות עבור ממשקי API Google Cloud
  • נקודות חולשה בתוכנה של צד שלישי
  • הגדרות שגויות בסביבה שלכם Google Cloud או באפליקציות של צד שלישי שאתם מפעילים ב- Google Cloud
  • פרטי כניסה שנחשפו, כמו מפתחות של חשבונות שירות שפורסמו במאגרי GitHub ציבוריים

בנוסף, אפשר להירשם ולקרוא את המסמכים הבאים כדי לקבל רשימה של וקטורים של איומים:

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

הגנה על חשבונות ועל פרטי הכניסה לחשבונות

תוקפים יכולים לנצל חשבונות לא מוגנים או חשבונות שמנוהלים בצורה לא נכונה כדי לקבל גישה למשאבי Compute Engine. Google Cloud כולל אפשרויות שונות שאפשר להגדיר כדי לנהל חשבונות וקבוצות.

הגבלת הגישה לסביבת הענן

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

מגבלה של מדיניות הארגון תיאור
הגבלת השיתוף לדומיין מציינים אילו מספרי לקוחות ב-Cloud Identity או ב-Google Workspace הם תקינים.
חשבונות AWS מותרים שאפשר להגדיר בהם איחוד שירותי אימות הזהות של עומסי עבודה ב-Cloud IAM בסביבת ענן היברידי, מגדירים אילו חשבונות AWS יכולים להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה.
ספקי זהויות חיצוניים שמותר להשתמש בהם עבור עומסי עבודה בסביבת ענן היברידי, מגדירים באילו ספקי זהויות עומסי העבודה יכולים להשתמש.

הגדרה של MFA או אימות דו-שלבי

‫Cloud Identity תומך באימות רב-שלבי (MFA) באמצעות שיטות שונות. הגדרת אימות רב-שלבי (MFA), במיוחד לחשבונות עם הרשאות מיוחדות. מידע נוסף זמין במאמר בנושא הדרישה לאימות רב-שלבי ב- Google Cloud.

כדי למנוע מתקפות פישינג שעלולות להוביל למתקפות של כריית מטבעות קריפטוגרפיים, מומלץ להשתמש במפתחות אבטחה Titan לאימות דו-שלבי (2FA).

הגדרת הרשאות מינימליות

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

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

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

אם אתם משתמשים בקבוצות כדי להקצות מדיניות IAM, חשוב לעקוב אחרי היומנים של הקבוצות כדי לוודא שלא נוספים אליהן חשבונות שהם לא חשבונות ארגוניים. בנוסף, מגבילים את הזהויות שיכולות לגשת למשאבים, על סמך דומיינים של Cloud Identity או Google Workspace. מידע נוסף זמין במאמר בנושא הגבלת זהויות לפי דומיין.

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

כדי לבצע ביקורת על המשתמשים והקבוצות, אפשר לעיין במאמר בנושא יומני ביקורת ב-Google Workspace.

הפחתת החשיפה לאינטרנט של המשאבים ב-Compute Engine וב-GKE

צמצום החשיפה לאינטרנט אומר שלתוקפים יש פחות הזדמנויות למצוא נקודות חולשה ולנצל אותן. בקטע הזה מתוארות שיטות מומלצות שיעזרו לכם להגן על מכונות וירטואליות ב-Compute Engine ועל אשכולות ב-Google Kubernetes Engine‏ (GKE) מפני חשיפה לאינטרנט.

הגבלת תנועה חיצונית

אל תקצו כתובות IP חיצוניות למכונות הווירטואליות. אתם יכולים להשתמש במגבלת המדיניות הארגונית Disable VPC External IPv6 usage כדי לדחות כתובות IP חיצוניות לכל המכונות הווירטואליות. כדי לראות באילו מכונות וירטואליות יש כתובות IP שנגישות לציבור, אפשר לעיין במאמר הצגת הגדרת הרשת של מכונה. אם הארכיטקטורה שלכם דורשת כתובות IP חיצוניות למכונות הווירטואליות, אתם יכולים להשתמש במדיניות הארגון Define allowed external IPs for VM instances, שמאפשרת לכם להגדיר רשימה של שמות מכונות שמותר להן להשתמש בכתובות IP חיצוניות.

הגבלת צמתי GKE לכתובות IP פנימיות בלבד. מידע נוסף זמין במאמר בנושא יצירת אשכול פרטי.

הגבלת תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) לאינטרנט לכל המשאבים בפרויקטים. מידע נוסף זמין במאמרים כללים של חומת אש ב-VPC ומדיניות היררכית של חומת אש.

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

שימוש ב-service perimeters

יוצרים גבול גזרה לשירות למשאבים של Compute Engine ו-GKE באמצעות VPC Service Controls. בעזרת VPC Service Controls אפשר לשלוט בתקשורת עם משאבי Compute Engine מחוץ לגבולות הגזרה. גבולות גזרה לשירות מאפשרים תקשורת חופשית בתוך הגבול, חוסמים העברת נתונים מחוץ לגבול וחוסמים תקשורת של שירותים מחוץ לגבול. להשתמש במאפיינים של בקרת גישה מבוססת-הקשר כמו כתובות IP וזהויות משתמשים כדי לשלוט בגישה לשירותיGoogle Cloud מהאינטרנט.

הגדרת מודל אבטחה של אפס אמון

הגדרה של אבטחה לפי עקרון אפס האמון באמצעות Chrome Enterprise Premium. ‫Chrome Enterprise Premium מספק הגנה מפני איומים והגנה על נתונים ואמצעי בקרה על הגישה. אם עומסי העבודה שלכם נמצאים גם בשרתים מקומיים וגם ב- Google Cloud, צריך להגדיר שרת proxy לאימות זהויות (IAP). הגדרת העברת TCP כדי לקבוע למי תהיה גישה לשירותים אדמיניסטרטיביים כמו SSH ו-RDP במשאביGoogle Cloud שלכם מאינטרנט ציבורי. העברת TCP מונעת את החשיפה הפתוחה של השירותים האלה לאינטרנט.

אבטחת המשאבים ב-Compute Engine וב-GKE

כדי לכרות מטבעות קריפטוגרפיים, צריך גישה למשאבים שלכם ב-Compute Engine וב-GKE. בקטע הזה מתוארות שיטות מומלצות שיעזרו לכם לאבטח את המשאבים של Compute Engine ו-GKE.

הגנה על תמונות של מכונות וירטואליות

כדי להשתמש בתמונות VM מוקשחות ומאוצרות, צריך להגדיר מכונה וירטואלית מוגנת. מכונות וירטואליות מוגנות נועדו למנוע טעינה של קוד זדוני כמו תוכנות זדוניות ברמת הליבה או ערכות rootkit במהלך מחזור האתחול. מכונות וירטואליות מוגנות מספקות אבטחת אתחול, עוקבות אחרי התקינות ומשתמשות במודול פלטפורמה וירטואלית מהימנה (vTPM).

כדי להגביל את התמונות שאפשר להשתמש בהן, אפשר להטמיע מדיניות בנושא קובצי אימג' מהימנים. מדיניות הארגון Define trusted image projects מגדירה אילו פרויקטים יכולים לאחסן תמונות ודיסקים קשיחים קבועים. מוודאים שבפרויקטים האלה יש רק תמונות מהימנות ומתוחזקות.

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

גישת SSH מאובטחת למכונות וירטואליות

הגדרת OS Login לניהול גישת SSH למכונות הווירטואליות שפועלות ב-Compute Engine. OS Login מפשט את ניהול הגישה ל-SSH על ידי קישור חשבון המשתמש של האדמין ב-Linux לזהות שלו ב-Google. התכונה OS Login פועלת עם IAM, כך שאפשר להגדיר את ההרשאות שיש לאדמינים.

במאמר שימוש בתשתיות ובשירותים מאובטחים ומאומתים תוכלו לקרוא מידע נוסף על אבטחת מכונות וירטואליות וקונטיינרים.

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

חשבון שירות הוא חשבון שבעזרתו עומסי עבודה Google Cloud שולחים קריאה ל-Google API של שירות.

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

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

שיטות מומלצות נוספות לאבטחת חשבונות שירות

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

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

מעקב אחרי מכונות וירטואליות וקונטיינרים ותיקון שלהם

כדי להתחיל מתקפת כריית מטבעות קריפטוגרפיים, התוקפים מנצלים לעיתים קרובות הגדרות שגויות ונקודות תורפה בתוכנה כדי לקבל גישה למשאבי Compute Engine ו-GKE.

כדי לקבל תובנות לגבי נקודות החולשה וההגדרות השגויות שרלוונטיות לסביבה שלכם, אתם יכולים להשתמש ב-Security Health Analytics כדי לסרוק את המשאבים. בפרט, אם אתם משתמשים ב-Security Command Center Premium, כדאי לבדוק את הממצאים לגבי מופעי Compute Engine ואת הממצאים לגבי קונטיינרים ולהגדיר תהליכים לפתרון מהיר של הבעיות.

אפשר להשתמש ב-Artifact Analysis כדי לבדוק אם יש נקודות חולשה בקובצי אימג' של קונטיינרים שמאוחסנים ב-Artifact Registry או ב-Container Registry.

חשוב לוודא שהארגון יכול לפרוס תיקוני אבטחה ברגע שהם זמינים. אתם יכולים להשתמש בניהול תיקוני מערכת הפעלה ב-Compute Engine. ‫Google מתקנת באופן אוטומטי פגיעויות ב-GKE. מידע נוסף זמין במאמר שימוש בשירותים ובאינפראסטרוקטורה מאובטחים ומאומתים.

הגנה על האפליקציות באמצעות WAF

תוקפים יכולים לנסות לגשת לרשת שלכם על ידי איתור נקודות פגיעות בשכבה 7 באפליקציות שפרסתם. כדי לצמצם את הסיכון למתקפות האלה, צריך להגדיר את Google Cloud Armor, חומת אש לאפליקציות אינטרנט (WAF) שמשתמשת בסינון בשכבה 7 ובמדיניות אבטחה. ‫Google Cloud Armor מספק הגנה מפני מניעת שירות (DoS) ומפני חומת אש ליישומי אינטרנט (WAF) לאפליקציות ולשירותים שמתארחים ב- Google Cloud, במקום או בעננים אחרים.

‫Google Cloud Armor כולל כלל WAF שיעזור לכם לטפל בנקודות חולשה ב-Apache Log4j. תוקפים יכולים לנצל נקודות חולשה ב-Log4j כדי להחדיר תוכנות זדוניות שיכולות לבצע כרייה לא מורשית של מטבעות וירטואליים. מידע נוסף זמין במאמר בנושא כלל WAF של Cloud Armor שיכול לעזור לטפל בפגיעות של Apache Log4j.

אבטחת שרשרת האספקה

אינטגרציה רציפה (CI) ופיתוח רציף (CD) מספקים מנגנון להעברת הפונקציונליות העדכנית ללקוחות במהירות. כדי למנוע מתקפות של כריית מטבעות קריפטוגרפיים נגד צינור עיבוד הנתונים, מומלץ לבצע ניתוח קוד ולנטר את צינור עיבוד הנתונים כדי לזהות מתקפות זדוניות.

הטמעה של Binary Authorization כדי לוודא שכל התמונות חתומות על ידי רשויות מהימנות במהלך תהליך הפיתוח, ולאחר מכן אכיפת אימות החתימה במהלך פריסת התמונות.

כדאי להעביר את בדיקות האבטחה לשלב מוקדם ככל האפשר בתהליך CI/CD (לפעמים זה נקרא הזזה שמאלה). מידע נוסף זמין במאמר בנושא העברת האבטחה שמאלה: אבטחת שרשרת אספקת התוכנה. במאמר אבטחת שרשרת האספקה של תוכנות מוסבר איך להגדיר שרשרת אספקה מאובטחת באמצעות GKE.

ניהול סודות ומפתחות

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

רוטציה של מפתחות הצפנה באופן קבוע

חשוב לוודא שכל מפתחות ההצפנה מתחלפים באופן קבוע. אם מפתחות ההצפנה שלכם מנוהלים על ידי Cloud KMS, אתם יכולים להחליף את מפתחות ההצפנה באופן אוטומטי.

אם אתם משתמשים בחשבונות שירות עם Google-owned and Google-managed encryption keys, המפתחות גם עוברים רוטציה אוטומטית.

מומלץ להימנע מהורדת סודות

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

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

כדאי להשתמש בפתרונות לניהול סודות, כמו Secret Manager ו-Hashicorp Vault לצורך שמירת הסודות, החלפתם באופן שוטף ושימוש בהרשאות מינימליות.

זיהוי פעילות חריגה

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

בנוסף, אפשר להשתמש ב-Event Threat Detection ב-Security Command Center כדי לזהות איומים שמבוססים על פעילויות ניהול, שינויים ב-Google Groups ושינויים בהרשאות בממשק לניהול זהויות והרשאות גישה (IAM). אפשר להשתמש בזיהוי איומים במכונות וירטואליות ב-Security Command Center כדי לזהות איומים שקשורים למכונות וירטואליות של Compute Engine. מידע נוסף על שירותי Security Command Center זמין במאמר מסלולי שירות של Security Command Center.

כדי לזהות איומים ברשת כמו תוכנות זדוניות, צריך להגדיר את Cloud IDS.

השתתפות בתוכנית להגנה מפני כריית קריפטו ב-Security Command Center

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

עדכון תוכנית התגובה לתקריות

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

  • איך שולחים בקשת תמיכה ל-Cloud Customer Care ואיך פונים אל מנהל החשבון הטכני (TAM) של Google. אם אין לכם חשבון תמיכה, כדאי לעיין בתוכניות התמיכה הזמינות וליצור חשבון.
  • איך מבחינים בין עומסי עבודה לגיטימיים של מחשוב עתיר ביצועים (HPC) לבין מתקפות כריית מטבעות קריפטוגרפיים. לדוגמה, אתם יכולים לתייג את הפרויקטים שבהם מופעל HPC ולהגדיר התראות על עלייה בלתי צפויה בעלויות.
  • איך מתמודדים עם פרטי כניסה שנחשפו Google Cloud .
  • איך להכניס להסגר מערכות נגועות ולשחזר מגיבויים תקינים.
  • מי בארגון צריך לקבל הודעה כדי לחקור את המתקפה ולהגיב לה.
  • איזה מידע צריך לתעד לגבי פעילויות רטרוספקטיביות.
  • איך מוודאים שפעולות התיקון הסירו ביעילות את פעולות הכרייה וטיפלו בפגיעות הראשונית שהובילה להתקפה.
  • איך מגיבים להתראה שנשלחת מ-Cloud Customer Care. מידע נוסף זמין במאמר שאלות נפוצות בנושא הפרות מדיניות.

מידע נוסף זמין במאמר תגובה להתקפות והתאוששות מהן.

הטמעה של תוכנית התאוששות מאסון (DR)

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

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

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