שיטות מומלצות לשימוש בחשבונות שירות בצינורות עיבוד נתונים

צינורות עיבוד נתונים לפריסה מאפשרים לתהליך של קבלת קוד או ארטיפקטים מוכנים מראש ופריסה שלהם לסביבת Cloud de Confiance by S3NS לקרות בצורה אוטומטית, והם יכולים להוות אלטרנטיבה לשימוש בכלים אינטראקטיביים כמו מסוף Cloud de Confiance או ה-CLI של Google Cloud.

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

לפני ש- Cloud de Confiance מאפשרת לגשת למשאב, היא מבצעת בדיקת גישה. כדי לבצע את הבדיקה, IAM בדרך כלל לוקחת בחשבון את:

• הזהות שלכם וכללי המדיניות המשויכים לקביעת גבול הגישה לחשבונות משתמשים (PAB)
• המשאב שאליו מנסים לגשת וכללי מדיניות ההרשאה והדחייה שלו ב-IAM
• ההקשר של הבקשה (אולי כולל השעה והמיקום)

בצינור עיבוד נתונים לפריסה, לעיתים נדירות קוראים Cloud de Confiance ישירות לממשקי ה-API. במקום זאת, משתמשים בכלים כדי לגשת למשאבים של Cloud de Confiance . כלים כמו Cloud de Confiance המסוף או ה-CLI של gcloud, מחייבים שקודם כל תעניקו הרשאה לכלי לגשת למשאבים בשמכם. מתן ההרשאה מעניקה לכלי רשות להשתמש בזהות שלכם בזמן ביצוע קריאות ל-API.

כמו במסוף Cloud de Confiance או ב-CLI של gcloud, צינור עיבוד נתונים לפריסה פועל בשמכם: הוא מקבל את השינויים שלכם, שבאים לידי ביטוי כקוד המקור, ופורס אותם ל- Cloud de Confiance. אבל בניגוד למסוף Cloud de Confiance או ל-CLI של gcloud, צינור עיבוד נתונים לפריסה לרוב לא משתמש בזהות שלכם כדי לבצע את הפריסה:

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

2. צינור עיבוד נתונים לפריסה קורא את שינויי הקוד ששלחה מערכת SCM ופורס אותם ל- Cloud de Confiance.

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

   1. קוד המקור והמטא-נתונים שלו עשויים שלא להצביע על זהות המחבר, או שפרטי המחבר לא מוגנים מפני שינויים (כמו במקרה של שמירות Git לא חתומות)
   2. הזהות שבה משתמשים לשליחת קוד המקור עשויה להיות שונה מהזהות ב- Cloud de Confiance, ולא ניתן למפות את שתי הזהויות

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

3. כשצינור עיבוד נתונים לפריסה מקבל גישה ל- Cloud de Confiance, ‏ IAM מאפשר או מונע גישה אך ורק על סמך זהות חשבון השירות שמשמש את צינור עיבוד הנתונים, ולא על סמך זהות חשבון המשתמש שלכם.

יש מספר יתרונות למתן אפשרות לצינור עיבוד נתונים לפריסה להשתמש בחשבון שירות כדי לגשת אל Cloud de Confiance:

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

עם זאת, שימוש בחשבון שירות כרוך גם באיומים חדשים. אלו כוללים:

• זיוף: גורם זדוני עלול לנסות לזייף את הזהות של צינור עיבוד הנתונים לפריסה או לגנוב את פרטי הכניסה כדי לקבל גישה למשאבים.
• הסלמת הרשאות (privilege escalation): אפשר להטעות את צינור עיבוד הנתונים כדי לגרום לו לבצע פעולות שהוא לא אמור לבצע, וכתוצאה מכך להפוך למעשה לסגן מבולבל (confused deputy).
• מניעת הכחשה: אחרי שצינור עיבוד נתונים ביצע פעולה, יכול להיות שיהיה קשה יותר לשחזר מדוע היא בוצעה, ואיזה מפתח או שינוי קוד גרמו לפעולה.
• פגיעה: ייתכן שייעשה שימוש לרעה בצינור עיבוד נתונים כדי לפגוע בתקינות או באמצעי בקרת האבטחה של סביבות הענן.
• חשיפת מידע: גורמים זדוניים עלולים לנסות להשתמש בצינור עיבוד הנתונים לפריסה בשביל זליגת נתונים סודיים.

הגנה מפני איומי זיוף

כדי להעניק גישה לצינור עיבוד הנתונים לפריסה ב- Cloud de Confiance, בדרך כלל מבצעים את הפעולות הבאות:

1. יצירה של חשבון שירות
2. מעניקים לחשבון השירות גישה למשאבים הנדרשים.
3. מגדירים שצינור עיבוד הנתונים לפריסה ישתמש בחשבון השירות.

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

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

הימנעות מצירוף חשבונות שירות למכונות וירטואליות שמשמשות מערכות CI/CD

לאפליקציות שפרוסות ב-Compute Engine וצריכות גישה למשאבים של Cloud de Confiance, מומלץ לצרף חשבון שירות למכונה הווירטואלית הבסיסית. למערכות CI/CD שמשתמשות במכונות וירטואליות של Compute Engine כדי להפעיל צינורות עיבוד נתונים שונים לפריסה, השיטה הזו עלולה להיות בעייתית אם אותה מכונה וירטואלית יכולה לשמש להפעלת צינורות עיבוד נתונים שונים לפריסה, שכל אחד מהם מחייב גישה למשאבים שונים.

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

שימוש בחשבונות שירות ייעודיים לכל צינור עיבוד נתונים לפריסה

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

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

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

שימוש באיחוד שירותי אימות הזהויות של עומסי עבודה ככל האפשר

מערכות CI/CD מסוימות, כמו GitHub Actions או GitLab, מאפשרות לצינורות עיבוד נתונים לפריסה לקבל אסימונים תואמי OpenID Connect, שמצהירים על הזהות של צינור עיבוד הנתונים לפריסה. אפשר לתת לצינורות עיבוד נתונים לפריסה להשתמש באסימונים האלו כדי להתחזות לחשבון שירות, על-ידי שימוש באיחוד שירותי אימות הזהויות של עומסי עבודה.

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

שימוש ב-VPC Service Controls כדי לצמצם את ההשפעה של פרטי כניסה שדלפו

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

כברירת מחדל, IAM לא לוקחת בחשבון את המיקום הגיאוגרפי, כתובת ה-IP של המקור או את פרויקט המקור Cloud de Confiance לצורך קבלת החלטות לגבי גישה. לכן אפשר להשתמש בפרטי כניסה גנובים מכל מקום.

אפשר להטיל הגבלות על המקורות שמהם ניתן לגשת למשאבים ב- Cloud de Confianceעל-ידי מיקום הפרויקטים בגבולות גזרה לשירות של VPC ושימוש בכללי תעבורת נתונים נכנסת (ingress):

• אם צינור עיבוד הנתונים לפריסה פועל ב- Cloud de Confiance, אפשר להגדיר כלל תעבורת נתונים נכנסת (ingress) כדי לאפשר גישה רק מהפרויקט שמכיל את מערכת ה-CI/CD.
• אם צינור עיבוד הנתונים לפריסה פועל מחוץ ל- Cloud de Confiance, אפשר ליצור רמת גישה שמאפשרת גישה רק ממיקומים גיאוגרפיים מסוימים או מטווחי IP מסוימים. לאחר מכן צריך ליצור כלל של תעבורת נתונים נכנסת (ingress) שמאפשר גישה ללקוחות שעומדים ברמת הגישה הזו.

הגנה מפני איומי פגיעה

יכול להיות שיש נתונים מסוימים שמאוחסנים ב- Cloud de Confiance, שחשוב לכם במיוחד למנוע שינוי או מחיקה לא מורשים. אם שינוי או מחיקה לא מורשים של נתונים הוא חשש משמעותי, אפשר לאפיין אותם כנתונים בתקינות גבוהה.

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

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

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

הגבלת גישה לאמצעי בקרת אבטחה

כדי לשמור על האבטחה והתקינות של הנתונים והמשאבים ב- Cloud de Confiance, צריך להשתמש באמצעי בקרת אבטחה כמו:

• כללי מדיניות הרשאה וכללי מדיניות דחייה
• מגבלות שקשורות למדיניות הארגון
• אזורים של VPC Service Controls, רמות גישה וכללי מדיניות תעבורת נתונים נכנסת (ingress)

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

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

כדי להגביל את ההשפעה של צינור עיבוד נתונים לפריסה על תקינות המשאבים:

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

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

הגנה מפני איומי מניעת הכחשה

בשלב מסוים, יכול להיות שתבחינו בפעילות חשודה שמשפיעה על אחד המשאבים שלכם ב- Cloud de Confiance. במקרה כזה, צריך שתהיה לכם אפשרות לקבל מידע נוסף על הפעילות, ובאופן אידיאלי, לשחזר את שרשרת האירועים שהובילו אליה.

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

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

לוודא שאפשר לבצע קורלציה בין יומני צינור עיבוד נתונים לפריסה ליומני הביקורת של Cloud

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

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

• כשמשתמשים ב-Terraform, צריך לרשום סיבה לבקשה שמציינת את הפעילות של צינור עיבוד הנתונים של CI/CD.
• הוספת כותרת HTTP של X-Goog-Request-Reason לבקשות API והעברת מזהה הפעילות של צינור עיבוד הנתונים לפריסה.
• שימוש ב-User-Agent בהתאמה אישית שמטמיע את מזהה הפעילות של צינור עיבוד הנתונים לפריסה.

אפשר גם להעשיר את היומנים שיצר צינור עיבוד הנתונים לפריסה:

• רישום בקשות API שכל פעילות של צינור עיבוד נתונים של CI/CD מבצעת.
• בכל פעם שה-API מחזיר מזהה פעילות, רושמים את המזהה ביומנים של מערכת ה-CI/CD.

ליצור התאמה בין תקופות השמירה של יומני צינורות עיבוד נתונים לפריסה ויומני הביקורת של Cloud

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

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

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

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

הגנה מפני איומי חשיפת מידע

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

• ישירה: יכול להיות שלחשבון השירות של צינור עיבוד הנתונים לפריסה יש הרשאה לקרוא נתונים סודיים מ-Cloud Storage, מ-BigQuery או ממיקומים אחרים. יכול להיות שגישה זו הוענקה באופן מכוון, אבל היא עשויה להיות גם תוצאה מקרית של הענקת גישה רחבה מדי.

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

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

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

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

הימנעות מהענקת גישה ישירה לנתונים סודיים

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

דרכים לצמצום הגישה לנתונים קיימים שעשויים להיות סודיים כוללות:

• במקום להעניק לחשבון השירות של צינור עיבוד נתונים לפריסה גישה לכל הפרויקט, מעניקים גישה רק למשאבים ספציפיים.
• להעניק גישת יצירה מבלי לאפשר גישת קריאה. לדוגמה, כשמקצים את התפקיד יצירת אובייקטים של אחסון (roles/storage.objectCreator), אפשר לתת לחשבון שירות להעלות אובייקטים חדשים לקטגוריה של Cloud Storage, בלי להעניק הרשאה לקרוא נתונים קיימים.
• הגבלת התשתית כקוד (IaC) למשאבים פחות סודיים – לדוגמה, אפשר להשתמש ב-IaC לניהול מכונות VM או רשתות, אבל לא לניהול מערכי נתונים סודיים של BigQuery.

שימוש ב-VPC Service Controls כדי לעזור במניעת זליגת מידע

כדי לצמצם את הסיכון לזליגת מידע באופן עקיף, אפשר לפרוס את Cloud de Confiance המשאבים במתחם היקפי של VPC Service Controls.

אם צינור עיבוד נתונים לפריסה פועל מחוץ ל- Cloud de Confianceאו שהוא חלק ממתחם היקפי אחר, אפשר לתת לחשבון השירות של צינור עיבוד הנתונים גישה למתחם היקפי באמצעות הגדרה של כלל תעבורת נתונים נכנסת (ingress). אם אפשר, כדאי להגדיר את כלל תעבורת הנתונים הנכנסת (ingress) כך שיאפשר גישה רק מכתובות ה-IP שנמצאות בשימוש של צינור עיבוד הנתונים לפריסה, ורק לשירותים שדרושים באמת לצינור עיבוד הנתונים לפריסה.

הגנה מפני איומי הסלמת הרשאות (privilege escalation)

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

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

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

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

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

כדי שאמצעי הבקרה האלו יהיו אפקטיביים, צריך גם לוודא שגורמים זדוניים לא יוכלו לעקוף אותם באמצעות:

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

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

לא לאפשר לצינור עיבוד נתונים לפריסה לשנות מדיניות

‫IAM מגדיר הרשאת RESOURCE_TYPE.setIamPolicy לרוב סוגי המשאבים. ההרשאה הזו מאפשרת למשתמשים לשנות את מדיניות ההרשאה של משאב מסוים, כדי להעניק למשתמשים אחרים גישה או כדי לשנות ולהרחיב את הגישה שלהם. אלא אם חלה עליו מדיניות דחייה, המשמעות של הענקת הרשאת *.setIamPolicy למשתמש או לחשבון שירות, היא הענקת גישה מלאה למשאב.

ככל האפשר, אסור לאפשר לצינור עיבוד נתונים לפריסה לשנות גישה למשאבים. כשמעניקים לחשבון שירות של צינור עיבוד נתונים גישה למשאבים של Cloud de Confiance , צריך להשתמש בתפקידים שלא כוללים כל הרשאה של *.setIamPolicy ולהימנע משימוש בתפקידים הבסיסיים עריכה ובעלים .

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

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

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

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

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

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

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

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

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