העיקרון הזה, שמופיע בעמודת האבטחה של Google Cloud Well-Architected Framework, עוזר לכם לזהות אמצעי בקרה מעשיים שתוכלו להטמיע בשלב מוקדם במחזור החיים של פיתוח התוכנה כדי לשפר את רמת האבטחה. הוא מספק המלצות שיעזרו לכם להטמיע אמצעי הגנה מונעים ואמצעי בקרה לאבטחה אחרי הפריסה.
סקירה כללית של העקרונות
אבטחה מוקדמת היא אימוץ שיטות אבטחה בשלב מוקדם במחזור החיים של פיתוח התוכנה. העקרון הזה נועד להשיג את המטרות הבאות:
- למנוע פגמי אבטחה לפני ביצוע שינויים במערכת. הטמעת אמצעי הגנה מונעים ואימוץ שיטות עבודה כמו תשתית כקוד (IaC), מדיניות כקוד ובדיקות אבטחה בצינור ה-CI/CD. אפשר גם להשתמש ביכולות אחרות שספציפיות לפלטפורמה, כמו Organization Policy Service ואשכולות GKE מוקשחים ב- Google Cloud.
- איתור ותיקון של באגים באבטחה בשלב מוקדם, במהירות ובאופן מהימן אחרי ביצוע שינויים במערכת. כדאי לאמץ שיטות עבודה כמו בדיקות קוד, סריקת נקודות חולשה אחרי הפריסה ובדיקות אבטחה.
העקרונות Implement security by design ו-shift-left security קשורים זה לזה, אבל הם שונים בהיקף שלהם. העיקרון של אבטחה מובנית עוזר לכם להימנע מפגמים בסיסיים בעיצוב, שיחייבו אתכם לתכנן מחדש את כל המערכת. לדוגמה, תרגיל של מידול איומים מגלה שהעיצוב הנוכחי לא כולל מדיניות הרשאות, וכל המשתמשים יקבלו את אותה רמת גישה ללא המדיניות. אבטחת Shift-left עוזרת לכם להימנע מפגמים בהטמעה (באגים וטעויות בהגדרות) לפני החלת השינויים, ומאפשרת תיקונים מהירים ואמינים אחרי הפריסה.
המלצות
כדי ליישם את עקרון האבטחה 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.
אתם יכולים לשנות את הסקריפטים של תוכנית ה-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, בלוח הבקרה של מצב האבטחה מוצגות המלצות מגובות בדעות וניתנות לביצוע, כדי לעזור לכם לשפר את מצב האבטחה של הקבוצה.