העיקרון הזה, שנכלל בעמודת האבטחה של Google Cloud Well-Architected Framework, עוזר לכם לזהות אמצעי בקרה מעשיים שאפשר להטמיע בשלב מוקדם במחזור החיים של פיתוח התוכנה כדי לשפר את רמת האבטחה. הוא מספק המלצות שיעזרו לכם להטמיע אמצעי בקרת אבטחה מונעים ומגנים, וגם אמצעי בקרת אבטחה אחרי הפריסה.
סקירה כללית של העקרונות
אבטחה בתחילת מחזור החיים של פיתוח התוכנה (Shift-left security) היא אימוץ שיטות אבטחה בשלב מוקדם במחזור החיים של פיתוח התוכנה. העיקרון הזה כולל את היעדים הבאים:
- למנוע פגמים באבטחה לפני ביצוע שינויים במערכת. הטמעת אמצעי הגנה למניעת פרצות אבטחה ואימוץ שיטות עבודה מומלצות כמו תשתית כקוד (IaC), מדיניות כקוד ובדיקות אבטחה בצינור ה-CI/CD. אפשר גם להשתמש ביכולות אחרות שספציפיות לפלטפורמה, כמו Organization Policy Service וhardened GKE clusters ב- Google Cloud.
- איתור ותיקון של באגים באבטחה בשלב מוקדם, במהירות ובאופן מהימן אחרי ביצוע שינויים במערכת. כדאי לאמץ שיטות עבודה כמו בדיקות קוד, סריקת נקודות חולשה אחרי הפריסה ובדיקות אבטחה.
העקרונות יישום אבטחה משלב התכנון ואבטחה משמאל קשורים זה לזה, אבל הם שונים בהיקף שלהם. העיקרון של אבטחה מובנית עוזר לכם להימנע מפגמים בסיסיים בעיצוב שידרשו שינוי הארכיטקטורה של המערכת כולה. לדוגמה, תרגיל של מידול איומים מגלה שהעיצוב הנוכחי לא כולל מדיניות הרשאות, וכל המשתמשים יקבלו את אותה רמת גישה ללא המדיניות. גישת Shift-left security עוזרת לכם להימנע מפגמים בהטמעה (באגים וטעויות בהגדרות) לפני החלת השינויים, ומאפשרת תיקונים מהירים ואמינים אחרי הפריסה.
המלצות
כדי ליישם את עקרון האבטחה 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 אנחנו מספקים את התוכנית של enterprise foundations. התוכנית הזו היא דעה מגובשת של Google לגבי עיצוב, והיא פועלת בהתאם לכל השיטות המומלצות וההגדרות שלנו. התוכנית מספקת הוראות מפורטות להגדרה ולפריסה של טופולוגיית Google Cloud באמצעות Terraform ו-Cloud Build.
אתם יכולים לשנות את הסקריפטים של תוכנית ה-blueprint של Enterprise Foundations כדי להגדיר סביבה שתפעל בהתאם להמלצות של Google ותעמוד בדרישות האבטחה שלכם. אפשר להוסיף עוד תוכניות לתוכנית הקיימת או ליצור אוטומציה משלכם.Google Cloud במרכז הארכיטקטורה יש תוכניות נוספות שאפשר להטמיע בנוסף לתוכנית לניהול יסודות האבטחה. הנה כמה דוגמאות לתוכניות האלה:
- פריסת פלטפורמת פיתוח לארגונים ב- Google Cloud
- פריסת ארכיטקטורה מאובטחת בלי שרת (serverless) באמצעות Cloud Run
- פיתוח ופריסה של מודלים של בינה מלאכותית גנרטיבית ולמידת מכונה בארגון
- ייבוא נתונים מ- Google Cloud למחסן נתונים מאובטח של BigQuery
אוטומציה של פרסום אפליקציות מאובטח
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת אפליקציות.
בלי כלים אוטומטיים, יכול להיות שיהיה קשה לפרוס, לעדכן ולתקן סביבות מורכבות של אפליקציות כדי לעמוד בדרישות אבטחה עקביות. מומלץ לבנות צינורות עיבוד נתונים אוטומטיים של CI/CD למחזור החיים של פיתוח התוכנה (SDLC). צינורות CI/CD אוטומטיים עוזרים לכם להסיר שגיאות ידניות, לספק לולאות משוב סטנדרטיות לפיתוח ולאפשר איטרציות יעילות של מוצרים. Continuous delivery היא אחת מהשיטות המומלצות שמומלצות במסגרת DORA.
שימוש בצינורות עיבוד נתונים של 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גישה של Google לשינויים.
לוודא שפריסות של אפליקציות מתבצעות בהתאם לתהליכים מאושרים
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת אפליקציות.
אם תוקף יפרוץ לצינור עיבוד הנתונים של CI/CD, כל חבילת האפליקציות שלכם עלולה להיפגע. כדי לאבטח את צינור הנתונים, כדאי לאכוף תהליך אישור מוגדר לפני פריסת הקוד בסביבת הייצור.
אם אתם משתמשים ב-Google Kubernetes Engine (GKE) או ב-Cloud Run, אתם יכולים להגדיר תהליך אישור באמצעות Binary Authorization. ב-Binary Authorization, חתימות שאפשר להגדיר מצורפות לקובצי אימג' של קונטיינרים. החתימות האלה (שנקראות גם אישורים) עוזרות לאמת את התמונה. בזמן הפריסה, Binary Authorization משתמש באישורים האלה כדי לקבוע אם תהליך הושלם. לדוגמה, אפשר להשתמש ב-Binary Authorization כדי:
- מוודאים שמערכת build ספציפית או צינור CI יצרו תמונת קונטיינר.
- בדיקה שקובץ אימג' של קונטיינר תואם למדיניות חתימה של פגיעות.
- מוודאים שקובץ אימג' של קונטיינר עומד בקריטריונים לקידום לסביבת הפריסה הבאה, למשל מפיתוח לבדיקת איכות.
באמצעות Binary Authorization, אתם יכולים לוודא שרק קוד מהימן יפעל בפלטפורמות היעד שלכם.
סריקה לאיתור פרצות אבטחה מוכרות לפני פריסת האפליקציה
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת אפליקציות.
מומלץ להשתמש בכלים אוטומטיים שיכולים לבצע באופן רציף סריקות של נקודות חולשה בארטיפקטים של האפליקציה לפני שהם נפרסים בסביבת הייצור.
באפליקציות בקונטיינרים, אפשר להשתמש ב-Artifact Analysis כדי להריץ באופן אוטומטי סריקות של נקודות חולשה בקובצי אימג' של קונטיינרים. הכלי Artifact Analysis סורק תמונות חדשות כשהן מועלות אל Artifact Registry. הסריקה מחלצת מידע על חבילות המערכת במאגר. אחרי הסריקה הראשונית, Artifact Analysis עוקב באופן רציף אחרי המטא-נתונים של תמונות שנסרקו ב-Artifact Registry כדי לזהות נקודות חולשה חדשות. כש-Artifact Analysis מקבל מידע חדש ומעודכן על נקודות חולשה ממקורות של נקודות חולשה, הוא מבצע את הפעולות הבאות:
- עדכון המטא-נתונים של התמונות הסרוקות כדי לשמור על עדכניות הנתונים.
- יצירת אירועי נקודות חולשה חדשים עבור טיפים ממשתמשים חדשים.
- מחיקת מקרים של פגיעויות שכבר לא תקפים.
מעקב אחרי קוד האפליקציה כדי לזהות פרצות אבטחה ידועות
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת אפליקציות.
מומלץ להשתמש בכלים אוטומטיים כדי לעקוב באופן רציף אחרי קוד האפליקציה ולחפש בו נקודות חולשה מוכרות, כמו אלה שמופיעות בOWASP Top 10. מידע נוסף על מוצרים ותכונות שתומכים בטכניקות לטיפול ב-OWASP Top 10 זמין במאמר אפשרויות לטיפול ב-OWASP Top 10 ב- Google Cloud. Google Cloud
כדאי להשתמש ב-Web Security Scanner כדי לזהות נקודות חולשה באבטחה של אפליקציות אינטרנט ב-App Engine, ב-Compute Engine וב-GKE. הסורק סורק את האפליקציה, עוקב אחרי כל הקישורים בהיקף של כתובות ה-URL להתחלה ומנסה להפעיל כמה שיותר קלט משתמשים ומטפלי אירועים. הוא יכול לסרוק ולזהות באופן אוטומטי נקודות חולשה נפוצות, כולל פרצת אבטחה XSS (cross-site scripting), החדרת קוד, תוכן מעורב וספריות לא עדכניות או לא מאובטחות. Web Security Scanner מאפשר לזהות מוקדם את סוגי נקודות החולשה האלה בלי להסיח את דעתכם עם תוצאות חיוביות כוזבות.
בנוסף, אם אתם משתמשים ב-GKE כדי לנהל קבוצות של אשכולות Kubernetes, בלוח הבקרה של מצב האבטחה מוצגות המלצות מגובות בדעות וניתנות לביצוע, שיעזרו לכם לשפר את מצב האבטחה של הקבוצה.