העיקרון הזה, שמופיע בעמוד האבטחה של Google Cloud Well-Architected Framework, עוזר לכם לזהות אמצעי בקרה מעשיים שאפשר להטמיע בשלב מוקדם במחזור החיים של פיתוח התוכנה כדי לשפר את מצב האבטחה. הוא כולל המלצות שעוזרות לכם להטמיע אמצעי הגנה למניעת פרצות אבטחה ואמצעי בקרה לאבטחה אחרי הפריסה.
סקירה כללית של העקרונות
אבטחה שזזה שמאלה היא אימוץ של שיטות אבטחה בשלב מוקדם במחזור החיים של פיתוח התוכנה. העיקרון הזה כולל את היעדים הבאים:
- למנוע פגמי אבטחה לפני שמבצעים שינויים במערכת. הטמיעו אמצעי הגנה מונעים לאבטחה ואמצו שיטות כמו תשתית כקוד (IaC), מדיניות כקוד ובדיקות אבטחה בצינור עיבוד הנתונים של CI/CD. אתם יכולים גם להשתמש ביכולות אחרות שספציפיות לפלטפורמה, כמו שירות מדיניות הארגון ואשכולות GKE מוקשחים ב- Google Cloud.
- לזהות ולתקן באגים באבטחה בשלב מוקדם, במהירות ובאופן מהימן אחרי שבוצעו שינויים במערכת. כדאי לאמץ שיטות כמו סקרי קוד, בדיקת נקודות חולשה אחרי הפריסה ובדיקות אבטחה.
העיקרון הטמעת אבטחה משלב התכנון והעיקרון "אבטחה משמאל" קשורים זה לזה, אבל הם שונים בהיקף שלהם. העיקרון של אבטחה מובנית עוזר לכם להימנע מפגמים בסיסיים בתכנון, שעלולים לחייב אתכם לתכנן מחדש את כל המערכת. לדוגמה, תרגיל של מידול איומים מגלה שהעיצוב הנוכחי לא כולל מדיניות הרשאות, ובלעדיה לכל המשתמשים תהיה אותה רמת גישה. אבטחה מסוג Shift-left עוזרת למנוע פגמים בהטמעה (באגים והגדרות שגויות) לפני שמחילים את השינויים, ומאפשרת תיקונים מהירים ואמינים אחרי הפריסה.
המלצות
כדי ליישם את עקרון האבטחה "הסטה שמאלה" בעומסי העבודה בענן, כדאי לפעול לפי ההמלצות שבקטעים הבאים:
- שימוש באמצעי בקרה למניעת פרצות אבטחה
- הקצאה וניהול אוטומטיים של משאבי ענן
- אוטומציה של גרסאות אפליקציה מאובטחות
- לוודא שפריסות של אפליקציות מתבצעות לפי תהליכים מאושרים
- סריקה לאיתור נקודות חולשה ידועות לפני פריסת האפליקציה
- מעקב אחרי קוד האפליקציה כדי לזהות נקודות חולשה ידועות
שימוש באמצעי בקרה למניעת פרצות אבטחה
ההמלצה הזו רלוונטית לתחומי המיקוד הבאים:
- ניהול זהויות והרשאות גישה
- משילות, סיכונים ותאימות בענן
אמצעי בקרה למניעת פרצות אבטחה חיוניים לשמירה על מצב אבטחה חזק בענן. אמצעי הבקרה האלה עוזרים לכם לצמצם סיכונים באופן יזום. כך תוכלו למנוע הגדרות שגויות וגישה לא מורשית למשאבים, לאפשר למפתחים לעבוד ביעילות ולעמוד בתקנים בתחום ובמדיניות הפנימית.
אמצעי בקרה מונעים יעילים יותר כשהם מוטמעים באמצעות תשתית כקוד (IaC). ב-IaC, אמצעי בקרה למניעת פרצות אבטחה יכולים לכלול בדיקות מותאמות אישית של קוד התשתית לפני פריסת השינויים. בשילוב עם אוטומציה, אמצעי בקרה למניעת פרצות אבטחה יכולים לפעול כחלק מהבדיקות האוטומטיות של צינור עיבוד הנתונים של CI/CD.
המוצרים והיכולות הבאים של Google Cloud יכולים לעזור לכם להטמיע אמצעי בקרה מונעים בסביבה שלכם:
- אילוצים של מדיניות הארגון: הגדרת אילוצים מוגדרים מראש ומותאמים אישית באמצעות בקרה מרכזית.
- VPC Service Controls: יצירת גבולות גזרה מסביב לשירותי Google Cloud .
- ניהול זהויות והרשאות גישה (IAM), Privileged Access Manager ומדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB): הגבלת הגישה למשאבים.
- Policy Controller ו-Open Policy Agent (OPA): אכיפת אילוצי IaC בצינור עיבוד הנתונים של CI/CD ומניעת הגדרות שגויות בענן.
בעזרת IAM אתם יכולים להגדיר מי יכול לבצע פעולות במשאבים מסוימים, בהתאם להרשאות. מידע נוסף זמין במאמר בקרת גישה למשאבים של ארגונים שמשתמשים ב-IAM.
מדיניות הארגון מאפשרת להגדיר הגבלות על משאבים כדי לקבוע איך אפשר להגדיר אותם. לדוגמה, אתם יכולים להשתמש במדיניות הארגון כדי:
- הגבלת שיתוף המשאבים על סמך הדומיין.
- הגבלת השימוש בחשבונות שירות.
- להגביל את המיקום הפיזי של משאבים חדשים שנוצרו.
בנוסף לשימוש במדיניות הארגון, אתם יכולים להגביל את הגישה למשאבים בדרכים הבאות:
- תגים עם IAM: מקצים תג לקבוצת משאבים ואז מגדירים את הגישה לתג עצמו, במקום להגדיר את הרשאות הגישה לכל משאב.
- תנאי IAM: הגדרת בקרת גישה מותנית למשאבים, על סמך מאפיינים.
- הגנה לעומק: שימוש ב-VPC Service Controls כדי להגביל עוד יותר את הגישה למשאבים.
מידע נוסף על ניהול משאבים מופיע במאמר בחירה של היררכיית משאבים לאזור הנחיתה ב- Google Cloud .
הקצאה וניהול אוטומטיים של משאבי ענן
ההמלצה הזו רלוונטית לתחומי המיקוד הבאים:
- אבטחת אפליקציות
- משילות, סיכונים ותאימות בענן
כדי להפוך את ההקצאה והניהול של משאבים ועומסי עבודה בענן לאוטומטיים, יעיל יותר להשתמש ב-IaC דקלרטיבי, ולא בסקריפטים אימפרטיביים. IaC הוא לא כלי או שיטה לאבטחה בפני עצמו, אבל הוא עוזר לשפר את האבטחה של הפלטפורמה. השימוש ב-IaC מאפשר ליצור תשתית שניתן לחזור עליה, ומספק לצוות התפעול מצב תקין וידוע. בנוסף, IaC משפר את היעילות של החזרות למצב קודם, שינויים בביקורת ופתרון בעיות.
כשמשלבים את IaC עם צינורות עיבוד נתונים של CI/CD ואוטומציה, אפשר גם לאמץ שיטות כמו מדיניות כקוד באמצעות כלים כמו OPA. אתם יכולים לבדוק את השינויים בתשתית לאורך זמן ולהריץ בדיקות אוטומטיות על קוד התשתית לפני פריסת השינויים.
כדי להפוך את פריסת התשתית לאוטומטית, אתם יכולים להשתמש בכלים כמו Config Controller, Terraform, Jenkins ו-Cloud Build. כדי לעזור לכם ליצור סביבת אפליקציות מאובטחת באמצעות IaC ואוטומציה,Google Cloud מספקת את תוכנית היסודות לארגונים. התוכנית הזו היא העיצוב המומלץ של Google, והיא כוללת את כל השיטות המומלצות וההגדרות שלנו. התוכנית כוללת הוראות מפורטות להגדרה ולפריסה של הטופולוגיה של Google Cloud באמצעות Terraform ו-Cloud Build.
אתם יכולים לשנות את הסקריפטים של תוכנית אב ליסודות הארגון כדי להגדיר סביבה שתואמת להמלצות של Google ועומדת בדרישות האבטחה שלכם. אתם יכולים להוסיף עוד תוכניות או ליצור אוטומציה משלכם. בGoogle Cloud מרכז הארכיטקטורה יש תוכניות נוספות שאפשר להטמיע בנוסף לתוכנית לניהול יסודות הארגון. הנה כמה דוגמאות לתבניות האלה:
- פריסת פלטפורמת פיתוח לארגונים ב- Google Cloud
- פריסת ארכיטקטורה מאובטחת בלי שרת (serverless) באמצעות Cloud Run
- פיתוח ופריסה של מודלים של למידת מכונה ו-AI גנרטיבי בארגון
- ייבוא נתונים מ- Google Cloud למחסן נתונים מאובטח של BigQuery
אוטומציה של גרסאות אפליקציה מאובטחות
ההמלצה הזו רלוונטית לתחום המיקוד הבא: אבטחת אפליקציות.
בלי כלים אוטומטיים, יכול להיות קשה לפרוס, לעדכן ולתקן סביבות מורכבות של אפליקציות כדי לעמוד בדרישות אבטחה עקביות. מומלץ לבנות צינורות עיבוד נתונים אוטומטיים של CI/CD למחזור החיים של פיתוח התוכנה (SDLC). צינורות עיבוד נתונים אוטומטיים של CI/CD עוזרים לכם להסיר שגיאות ידניות, לספק לולאות משוב סטנדרטיות לפיתוח ולאפשר איטרציות יעילות של מוצרים. פיתוח רציף (continuous delivery) הוא אחת מהשיטות המומלצות של DORA framework.
אוטומציה של גרסאות האפליקציה באמצעות צינורות עיבוד נתונים של CI/CD עוזרת לשפר את היכולת לזהות ולתקן באגים באבטחה בשלב מוקדם, במהירות ובאופן מהימן. לדוגמה, אתם יכולים לסרוק באופן אוטומטי כדי לאתר נקודות חולשה באבטחה כשנוצרים פריטי מידע, לצמצם את היקף בדיקות האבטחה ולחזור לגרסה מוכרת ובטוחה. אתם יכולים גם להגדיר כללי מדיניות לסביבות שונות (כמו סביבות פיתוח, בדיקה או ייצור) כדי לפרוס רק פריטי מידע מאומתים.
כדי לעזור לכם להפוך את ההשקות של האפליקציות לאוטומטיות ולהטמיע בדיקות אבטחה בצינור עיבוד הנתונים של CI/CD, ב- Google Cloud יש כמה כלים, כולל Cloud Build, Cloud Deploy, Web Security Scanner ו-Binary Authorization.
כדי ליצור תהליך שמאמת כמה דרישות אבטחה ב-SDLC, השתמשו במסגרת Supply-chain Levels for Software Artifacts (SLSA) שהוגדרה על ידי Google. במסגרת SLSA, צריך לבצע בדיקות אבטחה של קוד המקור, תהליך ה-build ומקור הקוד. אפשר לכלול הרבה מהדרישות האלה בצינור עיבוד נתונים אוטומטי של CI/CD. כדי להבין איך Google מיישמת את השיטות האלה באופן פנימי, קראו את המאמר הגישה שלGoogle Cloudלשינוי.
לוודא שפריסות של אפליקציות מתבצעות לפי תהליכים מאושרים
ההמלצה הזו רלוונטית לתחום המיקוד הבא: אבטחת אפליקציות.
אם תוקף יפרוץ לצינור עיבוד הנתונים של CI/CD, כל מחסנית האפליקציות שלכם עלולה להיפגע. כדי לאבטח את צינור עיבוד הנתונים, כדאי לאכוף תהליך אישור מוגדר לפני פריסת הקוד בסביבת הייצור.
אם אתם משתמשים ב-Google Kubernetes Engine (GKE) או ב-Cloud Run, אתם יכולים להגדיר תהליך אישור באמצעות Binary Authorization. Binary Authorization מצרף חתימות שניתנות להגדרה לקובצי אימג' של קונטיינרים. החתימות האלה (שנקראות גם אישורים) עוזרות לאמת את התמונה. בזמן הפריסה, Binary Authorization משתמשת באישורים האלה כדי לקבוע אם התהליך הושלם. לדוגמה, אתם יכולים להשתמש ב-Binary Authorization כדי:
- לוודא שמערכת build ספציפית או צינור עיבוד נתונים של CI יצרו קובץ אימג' של קונטיינר.
- אימות שקובץ אימג' של קונטיינר תואם למדיניות חתימה על נקודות חולשה.
- לוודא שקובץ אימג' של קונטיינר עומד בקריטריונים לקידום לסביבת הפריסה הבאה, למשל מפיתוח ל-QA.
באמצעות Binary Authorization, אתם יכולים לאכוף שרק קוד מהימן יפעל בפלטפורמות היעד שלכם.
סריקה לאיתור נקודות חולשה ידועות לפני פריסת האפליקציה
ההמלצה הזו רלוונטית לתחום המיקוד הבא: אבטחת אפליקציות.
מומלץ להשתמש בכלים אוטומטיים שיכולים לבצע בדיקת נקודות חולשה רציפה בקובצי האפליקציה לפני שהם נפרסים בסביבת הייצור.
באפליקציות בקונטיינרים, אפשר להשתמש ב-Artifact Analysis כדי להריץ באופן אוטומטי סריקות לאיתור נקודות חולשה בקובצי אימג' של קונטיינרים. Artifact Analysis סורק תמונות חדשות כשהן מועלות ל-Artifact Registry. בסריקה נשלף מידע על חבילות המערכת במאגר. אחרי הסריקה הראשונית, Artifact Analysis עוקב באופן רציף אחרי המטא-נתונים של קובצי האימג' שנסרקו ב-Artifact Registry כדי לאתר נקודות חולשה חדשות. כש-Artifact Analysis מקבל מידע חדש ומעודכן על נקודות חולשה ממקורות של נקודות חולשה, הוא מבצע את הפעולות הבאות:
- מעדכן את המטא-נתונים של קובצי האימג' שנסרקו כדי לשמור על עדכניות הנתונים.
- יצירת מופעים חדשים של נקודות חולשה להערות חדשות.
- מוחק מופעים של נקודות חולשה שכבר לא תקפים.
מעקב אחרי קוד האפליקציה כדי לזהות פרצות אבטחה ידועות
ההמלצה הזו רלוונטית לתחום המיקוד הבא: אבטחת אפליקציות.
השתמשו בכלים אוטומטיים כדי לעקוב באופן קבוע אחרי קוד האפליקציה ולזהות נקודות חולשה ידועות, כמו OWASP Top 10. למידע נוסף על מוצרים ותכונות של Google Cloud שתומכים בטכניקות לצמצום הסיכונים של OWASP Top 10, קראו את המאמר צמצום הסיכונים של OWASP Top 10:2025 ב- Google Cloud.
אתם יכולים להשתמש ב-Web Security Scanner כדי לזהות נקודות חולשה באבטחה באפליקציות האינטרנט של App Engine, Compute Engine ו-GKE. הסורק סורק את האפליקציה, עוקב אחרי כל הקישורים בהיקף של כתובות ה-URL ההתחלתיות ומנסה להפעיל כמה שיותר קלט של משתמשים וגורמים מטפלים באירועים. הוא יכול לסרוק ולזהות באופן אוטומטי נקודות חולשה נפוצות, כולל פרצת אבטחה XSS (cross-site scripting), הזרקת קוד, תוכן מעורב וספריות מיושנות או לא מאובטחות. הכלי Web Security Scanner מאפשר לזהות בשלב מוקדם את נקודות החולשה האלה, בלי להסיח את דעתכם עם תוצאות חיוביות כוזבות.
בנוסף, אם אתם משתמשים ב-GKE כדי לנהל קבוצות של אשכולות Kubernetes, בלוח הבקרה של מצב האבטחה מוצגות המלצות ממוקדות ופרקטיות שיעזרו לכם לשפר את מצב האבטחה של הקבוצה.