במאמר הזה מתוארות שיטות מומלצות להגנה על הפריסות.
יצירה ואכיפה של מדיניות פריסה
כדי להגן על סביבות זמן הריצה, צריך להגדיר מדיניות עם קריטריונים לפריסה ולאמת את העמידה בדרישות המדיניות לפני ואחרי הפריסה. הגדרת מדיניות שמאפשרת רק קוד שנחתם על ידי מאמתים מוגדרים מראש עוזרת לשלוט על פריסות ולפרוס רק קוד ממקורות מהימנים.
דוגמאות לקריטריונים לפריסה:
- אין נקודות חולשה ידועות ברמת חומרה גבוהה מבינונית
- קוד המקור מגיע ממאגר מקור מהימן
- שירות מהימן של גרסת build הפעיל את ה-build
- הארטיפקטים שאתם פורסים מגיעים ממאגר ארטיפקטים מהימן
יצירת מטא-נתונים
כדי לאמת את הדרישות האלה, צריך לספק מטא נתונים לגבי ארטיפקטים של בנייה.
- יצירת מקורות
אישור המקור של Build הוא אוסף של נתונים שניתן לאימות לגבי build, כמו תקצירי תמונות שנוצרו, מיקומי מקורות קלט, toolchain של ה-build ומשך ה-build. SLSA, מסגרת להערכת מצב האבטחה, מספקת מודל לתיעוד מקור ודרישות לתיעוד מקור. הוכחת מקוריות היא אחת מקטגוריות הדרישות במסגרת, וכל דרישה משויכת לרמות SLSA, כך שתוכלו ליישם אמצעי מניעה באופן הדרגתי.
- כדי להשיג רמת ודאות 1 של SLSA, צריך לספק את מקורות המידע.
- כדי להבטיח את רמת האבטחה SLSA 2, צריך ליצור את המקורות, והצרכנים צריכים להיות מסוגלים לאמת את האותנטיות והשלמות שלהם.
- לרמות SLSA 3 ו-4 יש דרישות מחמירות יותר לגבי חתימה על מקורות ורמת הפירוט של נתוני המקורות.
חלק משירותי הבנייה יוצרים מטא-נתונים של מקור הבנייה.
- ב- Google Cloud, Cloud Build יוצר וחותם על אישור המקור של Build לקובצי אימג' של קונטיינרים שתומכים ב-builds ברמה 3 של SLSA.
- מסגרת SLSA מספקת כלים לתיעוד מקורות ב-GitHub. הכלים יוצרים ב-GitHub נתוני מקוריות של SLSA שלא ניתן לזייף, שעומדים בדרישות בקטגוריות הבנייה וprovenance לרמה 3 של SLSA.
- פרויקט הקוד הפתוח sigstore כולל את הכלי cosign לחתימה על קונטיינרים.
- נקודות חולשה
תוכנות לסריקת פרצות אבטחה בודקות את קוד המקור ואת תוצרי הבנייה שלכם כדי לזהות פרצות אבטחה ידועות. Artifact Analysis יכול לסרוק באופן אוטומטי קובצי אימג' של קונטיינרים שנשלחים אל Artifact Registry כדי לאתר נקודות חולשה. כדי לבדוק אם יש חולשות בארטיפקטים לפני שמאחסנים אותם, אפשר להשתמש ב-On-Demand Scanning API בסביבת פיתוח מקומית או בצינור CI/CD, כמו שלב בנייה ב-Cloud Build.
הגדרת אכיפת מדיניות
אחרי שיש לכם מטא-נתונים לגבי הארטיפקטים שניתנים לפריסה, אתם צריכים כלים לאכיפת המדיניות.
ב- Google Cloud, אפשר להגדיר מדיניות ב-Binary Authorization לפריסות. Binary Authorization אוכף מדיניות לגבי ניסיונות פריסה בפלטפורמות נתמכות שמבוססות על קונטיינרים. הוא יכול גם לבצע אימות רציף של מדיניות לעומסי עבודה שפועלים ב-GKE, ב-Cloud Run וב-GKE Enterprise.
בדיקות לפני פריסה יכולות לחסום את כל התמונות שלא נמצאות ברשימת התמונות הפטורות, כך שרק תמונות מהימנות ייפרסו ממאגרי תמונות מהימנים. המדיניות יכולה גם לדרוש אישורים, מסמכים דיגיטליים שמעידים על כך שהתמונה נוצרה בהצלחה באמצעות תהליך ספציפי שנדרש. לדוגמה, אישור יכול לציין שתמונה היא:
- נוצר על ידי Cloud Build.
- לא מכיל פרצות אבטחה מעל רמת חומרה מסוימת. אם יש נקודות חולשה ספציפיות שלא רלוונטיות לאפליקציות שלכם, אתם יכולים להוסיף אותן לרשימת ההיתרים.
אימות רציף מרחיב את אימות המדיניות לסביבה אחרי הפריסה. כשמאפשרים את התכונה, Binary Authorization מספק אימות לאורך מחזור החיים של ה-Pod על ידי רישום קבוע של התאמה למדיניות ב-Cloud Logging. האפשרות הזו שימושית במגוון מצבים. לדוגמה, אם משנים את המדיניות אחרי פריסת מאגר תגים, יומני אימות רציף יציגו את ה-Pods שמפירים את המדיניות המעודכנת. הוא גם מתעד הפרות של מדיניות ב-Pods שנפרסו באמצעות הרצת בדיקה או breakglass.
שימוש בשירותי פריסה עם גישה מוגבלת
שערים לפריסה מאפשרים לכם לאשר או לדחות פריסות בנקודות ספציפיות בתהליך הפריסה, באמצעות שירות CI/CD עצמאי או שירות CI/CD שמשולב במערכת אוטומציה של תהליכים. פריסות עם שערים מונעות ממשתמשים לא מורשים לבצע שינויים בסביבות של אפליקציות. הם מספקים פיקוח נוסף על תהליך הפריסה ושקיפות רבה יותר לגבי האישורים.
ב- Google Cloud, Cloud Deploy הוא שירות מנוהל מלא לפריסת עומסי עבודה ב-Google Kubernetes Engine. התכונה פריסה מוגבלת מאפשרת למשתמשים לציין אם נדרש אישור לקידום לסביבת יעד.
מעקב אחרי עומסי העבודה
עומסי עבודה (workloads) הם אפליקציות שפועלות בפלטפורמות מבוססות קונטיינרים כמו GKE ו-Cloud Run. מומלץ שעומסי העבודה שתפרסו יהיו עם הגדרות מוקשחות שמגבילות את שטח הפנים להתקפה.
יכול להיות שיהיה לכם קשה לבדוק באופן ידני בעיות בהגדרות של עומסי עבודה בכמה אשכולות. Google Cloud מספק לוחות בקרה ב-Cloud Run וב-GKE כדי להציג תובנות לגבי אבטחה של עומסי עבודה.
לוח הבקרה של מצב האבטחה ב-GKE מספק הנחיות לחיזוק מצב האבטחה של האשכולות על סמך ההמלצות של Google. הוא כולל סריקה אוטומטית של הגדרות עומסי עבודה, שבודקת אם יש בעיות ידועות בהגדרות בכל עומסי העבודה. GKE בודק כל עומס עבודה שנפרס בהשוואה לשיטות המומלצות הרלוונטיות בתחום, כמו מדיניות בתקני אבטחת ה-Pod. GKE מדרג את חומרת הבעיות שמתגלות ומחזיר המלצות ויומנים שניתן לפעול לפיהם. אפשר להשתמש ב-Cloud Logging כדי לקבל שרשרת של בעיות שניתן לבדוק, וכך לשפר את הדיווח והניראות. הוראות לצפייה בתובנות אבטחה בלוח הבקרה של מצב האבטחה ב-GKE מופיעות במאמר פריסה ב-GKE וצפייה בתובנות אבטחה.
ב-Cloud Run יש חלונית אבטחה שבה מוצגים תובנות לגבי אבטחת שרשרת אספקת התוכנה, כמו מידע על התאימות לרמת ה-build של SLSA, מקור ה-build ונקודות חולשה שנמצאו בשירותים פעילים. הוראות לצפייה בתובנות אבטחה בחלונית התובנות בנושא אבטחה ב-Cloud Run מופיעות במאמר פריסה ב-Cloud Run וצפייה בתובנות אבטחה.
Google Cloud מספקת גם שירותים ותכונות אחרים לשיפור מצב האבטחה לאורך מחזור החיים של פיתוח התוכנה. מידע נוסף זמין במאמר סקירה כללית על שרשרת האספקה של תוכנות.