צינור עיבוד נתונים לפריסה הוא תהליך אוטומטי שלוקח קוד או ארטיפקטים מוכנים מראש ופורס אותם בסביבת בדיקה או בסביבת ייצור. צינורות עיבוד נתונים לפריסה משמשים בדרך כלל לפריסה של אפליקציות, הגדרות או תשתית ענן (תשתית כקוד), והם יכולים למלא תפקיד חשוב באבטחה הכוללת של פריסת ענן.
המדריך הזה מיועד למהנדסי DevOps ולמהנדסי אבטחה, והוא מתאר שיטות מומלצות לתכנון צינורות עיבוד נתונים לפריסה מאובטחת בהתאם לדרישות הסודיות, השלמות והזמינות שלכם.
ארכיטקטורה
בתרשים הבא מוצג זרימת הנתונים בצינור פריסה. הוא מראה איך אפשר להפוך את הארטיפקטים למשאבים.
צינורות פריסה הם לרוב חלק מתהליך עבודה גדול יותר של אינטגרציה רציפה (CI) ופריסה רציפה (CD), ובדרך כלל הם מיושמים באמצעות אחד מהמודלים הבאים:
מודל Push: במודל הזה, מטמיעים את צינור עיבוד הנתונים לפריסה באמצעות מערכת CI/CD מרכזית, כמו Jenkins או GitLab. יכול להיות שמערכת ה-CI/CD הזו פועלת ב- Google Cloud, בסביבת ארגון או בסביבת ענן אחרת. לרוב, אותה מערכת CI/CD משמשת לניהול של כמה צינורות עיבוד נתונים לפריסה.
מודל הדחיפה מוביל לארכיטקטורה ריכוזית עם כמה מערכות CI/CD שמשמשות לניהול מספר גדול של משאבים או אפליקציות. לדוגמה, אתם יכולים להשתמש במופע יחיד של Jenkins או GitLab כדי לנהל את כל סביבת הייצור, כולל כל הפרויקטים והאפליקציות שלה.
מודל משיכה: במודל הזה, תהליך הפריסה מיושם על ידי סוכן שנפרס לצד המשאב – למשל, באותו אשכול Kubernetes. הסוכן מושך ארטיפקטים או קוד מקור ממיקום מרכזי ופורס אותם באופן מקומי. כל סוכן מנהל משאב אחד או שניים.
מודל המשיכה מוביל לארכיטקטורה מבוזרת יותר עם מספר גדול פוטנציאלי של סוכנים למטרה יחידה.
בהשוואה לפריסות ידניות, שימוש עקבי בצינורות פריסה יכול להניב את היתרונות הבאים:
- הגברת היעילות, כי לא נדרשת עבודה ידנית.
- המהימנות גבוהה יותר, כי התהליך אוטומטי לחלוטין וניתן לחזרה.
- שיפור היכולת לעקוב אחרי שינויים, כי אפשר לעקוב אחרי כל הפריסות כדי לראות שינויים בקוד או בארטיפקטים של הקלט.
כדי לבצע פריסה, צינור עיבוד הנתונים לפריסה צריך גישה למשאבים שהוא מנהל:
- צינור עיבוד נתונים לפריסה שפורס תשתית באמצעות כלים כמו Terraform עשוי ליצור, לשנות או אפילו למחוק משאבים כמו מופעי מכונות וירטואליות, רשתות משנה או קטגוריות של Cloud Storage.
- יכול להיות שצינור עיבוד נתונים לפריסה של אפליקציות יצטרך להעלות תמונות חדשות של קונטיינרים ל-Artifact Registry, ולפרוס גרסאות חדשות של אפליקציות ב-App Engine, ב-Cloud Run או ב-Google Kubernetes Engine (GKE).
- יכול להיות שצינור (pipeline) שמנהל הגדרות או פורס קובצי תצורה יצטרך לשנות מטא-נתונים של מכונות וירטואליות, הגדרות של Kubernetes או לשנות נתונים ב-Cloud Storage.
אם צינורות עיבוד הנתונים לפריסה לא מאובטחים בצורה נכונה, הגישה שלהם למשאביGoogle Cloud עלולה להפוך לנקודת חולשה במצב האבטחה שלכם. אבטחה חלשה עלולה להוביל לכמה סוגים של מתקפות, כולל:
תקיפות של הרעלת צינורות: במקום לתקוף משאב ישירות, גורם זדוני עלול לנסות לפגוע בצינור עיבוד הנתונים לפריסה, בהגדרות שלו או בתשתית הבסיסית שלו. הגורם הזדוני יכול לנצל את הגישה של צינור עיבוד הנתונים אל Google Cloudכדי לגרום לצינור לבצע פעולות זדוניות במשאבי Cloud, כפי שמוצג בתרשים הבא:
מתקפות על שרשרת האספקה: במקום לתקוף את צינור עיבוד הנתונים לפריסה, גורם זדוני עלול לנסות לפגוע במקורות הקלט של צינור עיבוד הנתונים או להחליף אותם – כולל קוד מקור, ספריות או תמונות של קונטיינרים, כמו שמוצג בתרשים הבא:
כדי לקבוע אם צינורות עיבוד הנתונים לפריסה מאובטחים בצורה מתאימה, לא מספיק לבדוק רק את כללי מדיניות ההרשאה ואת כללי מדיניות הדחייה של Google Cloud משאבים בנפרד. במקום זאת, צריך להתייחס לגרף המלא של המערכות שמעניקות גישה למשאב באופן ישיר או עקיף. הגרף הזה כולל את הפרטים הבאים:
- צינור הפריסה, מערכת ה-CI/CD הבסיסית שלו והתשתית הבסיסית שלו
- מאגר המקורות של הקוד, השרתים והתשתית הבסיסיים שלו
- קלט ארטיפקטים, מיקומי האחסון שלהם והתשתית הבסיסית שלהם
- מערכות שמפיקות את פריטי הקלט, והתשתית הבסיסית שלהן
קשה לזהות גישת משתמשים למשאבים ולחולשות מערכתיות בתרשימי קלט מורכבים.
בקטעים הבאים מתוארות שיטות מומלצות לעיצוב צינורות עיבוד נתונים לפריסה, שיעזרו לכם לנהל את גודל הגרף ולצמצם את הסיכון לתנועה לרוחב ולאיומי שרשרת אספקה.
הערכת יעדי האבטחה
רמת הרגישות של המשאבים ב- Google Cloud עשויה להשתנות. יכול להיות שחלק מהמשאבים רגישים מאוד כי הם קריטיים לעסק או סודיים. יכול להיות שמשאבים אחרים פחות רגישים כי הם זמניים או מיועדים למטרות בדיקה בלבד.
כדי לתכנן צינור עיבוד נתונים לפריסה מאובטחת, קודם צריך להבין לאילו משאבים צינור עיבוד הנתונים צריך לגשת, ומה רמת הרגישות של המשאבים האלה. ככל שהמשאבים רגישים יותר, כך צריך להתמקד יותר באבטחת צינור עיבוד הנתונים.
המשאבים שצינורות עיבוד הנתונים לפריסה ניגשים אליהם עשויים לכלול:
- אפליקציות, כמו Cloud Run או App Engine
- משאבים בענן, כמו מכונות וירטואליות או קטגוריות של Cloud Storage
- נתונים, כמו אובייקטים ב-Cloud Storage, רשומות ב-BigQuery או קבצים
יכול להיות שלחלק מהמשאבים האלה יש תלות במשאבים אחרים, למשל:
- אפליקציות עשויות לגשת לנתונים, למשאבי ענן ולאפליקציות אחרות.
משאבים בענן, כמו מופעים של מכונות וירטואליות או קטגוריות של Cloud Storage, עשויים להכיל אפליקציות או נתונים.
כפי שמוצג בתרשים הקודם, התלויות משפיעות על רמת הרגישות של משאב. לדוגמה, אם אתם משתמשים באפליקציה שניגשת לנתונים רגישים מאוד, בדרך כלל צריך להתייחס לאפליקציה הזו כאל אפליקציה רגישה מאוד. באופן דומה, אם משאב בענן כמו קטגוריה של Cloud Storage מכיל מידע אישי רגיש, בדרך כלל צריך להתייחס לקטגוריה כאל מידע אישי רגיש.
בגלל התלות הזו, מומלץ קודם להעריך את רמת הרגישות של הנתונים. אחרי ההערכה, אפשר לבדוק את שרשרת התלות ולהעריך את רמת הרגישות של המשאבים והאפליקציות ב-Cloud.
סיווג רמת הרגישות של הנתונים
כדי להבין את רגישות הנתונים בצינור הפריסה, כדאי להתייחס לשלוש המטרות הבאות:
- סודיות: אתם צריכים להגן על הנתונים מפני גישה לא מורשית.
- תקינות: עליכם להגן על הנתונים מפני שינוי או מחיקה לא מורשים.
- זמינות: אתם צריכים לוודא שאנשים ומערכות מורשים יכולים לגשת לנתונים בצינור הפריסה.
לגבי כל אחד מהיעדים האלה, כדאי לשאול את עצמכם מה יקרה אם תהיה פריצה לצינור שלכם:
- סודיות: מה הנזק שייגרם אם הנתונים ייחשפו לגורם זדוני או ידלפו לציבור?
- יושרה: מה הנזק שייגרם אם גורם זדוני ישנה או ימחק את הנתונים?
- זמינות: מה הנזק שייגרם אם גורם זדוני ישבש את הגישה לנתונים שלכם?
כדי שיהיה אפשר להשוות בין התוצאות של משאבים שונים, כדאי להשתמש בקטגוריות אבטחה. תקנים לסיווג אבטחה (FIPS-199) מציעים להשתמש בארבע הקטגוריות הבאות:
- גבוהה: הנזק יהיה חמור או קטסטרופלי
- בינוני: הנזק יהיה חמור
- נמוך: הנזק יהיה מוגבל
- לא רלוונטי: התקן לא חל
בהתאם לסביבה ולהקשר, יכול להיות שיהיה מתאים יותר להשתמש בקבוצה אחרת של קטגוריות.
הסודיות והשלמות של נתונים מצינור המכירות משתנות בהתאם לקטגוריות האבטחה שצוינו למעלה. בקטעי המשנה הבאים יש דוגמאות למשאבים עם מדדים שונים של סודיות ושלמות:
משאבים עם סודיות נמוכה, אבל יושרה נמוכה, בינונית וגבוהה
לכל הדוגמאות הבאות של משאבים יש סיווג סודיות נמוך:
- תקינות נמוכה: נתוני בדיקה
- יושרה בינונית: תוכן שרת אינטרנט ציבורי, מגבלות מדיניות לארגון שלכם
- יושרה גבוהה: קובצי אימג' של קונטיינרים, קובצי אימג' של דיסקים, הגדרות של אפליקציות, מדיניות גישה (רשימות של הרשאות ודחיות), שעבודים, נתונים של רמות גישה
משאבים עם סודיות בינונית, אבל יושרה נמוכה, בינונית וגבוהה
לדוגמאות הבאות של משאבים יש סיווג סודיות בינוני:
- מהימנות נמוכה: תוכן של שרת אינטרנט פנימי
- יומני ביקורת: שמירה על תקינות ברמה בינונית
- מהימנות גבוהה: קובצי תצורה של אפליקציות
משאבים עם סודיות גבוהה, אבל יושרה נמוכה, בינונית וגבוהה
לכל דוגמאות המשאבים הבאות יש סודיות גבוהה:
- רמת יושרה נמוכה: נתוני שימוש ופרטים אישיים מזהים
- יושרה בינונית: סודות
- רמת תקינות גבוהה: נתונים פיננסיים, מפתחות KMS
סיווג אפליקציות על סמך הנתונים שהן ניגשות אליהם
כשלאפליקציה יש גישה לנתונים רגישים, גם האפליקציה וגם צינור עיבוד הנתונים לפריסה שמנהל את האפליקציה יכולים להפוך לרגישים. כדי להבין את רמת הרגישות, צריך לבדוק את הנתונים שהאפליקציה והצינור צריכים לגשת אליהם.
אחרי שמזהים את כל הנתונים שהאפליקציה ניגשת אליהם ומסווגים אותם, אפשר להשתמש בקטגוריות הבאות כדי לסווג את האפליקציה באופן ראשוני לפני שתתכננו צינור עיבוד נתונים לפריסה מאובטחת:
- סודיות: הקטגוריה הכי גבוהה של כל נתון שהייתה אליו גישה
- תקינות: הקטגוריה הגבוהה ביותר של נתונים שאליהם יש גישה
- זמינות: הקטגוריה הגבוהה ביותר של כל נתון שהייתה אליו גישה
ההערכה הראשונית הזו מספקת הנחיות, אבל יכול להיות שיש עוד גורמים שכדאי לקחת בחשבון – לדוגמה:
- יכול להיות ששתי קבוצות נתונים יהיו בעלות סיווג סודיות נמוך בנפרד, אבל בשילוב ביניהן הן יוכלו לחשוף תובנות חדשות. אם לאפליקציה יש גישה לשתי קבוצות הנתונים, יכול להיות שתצטרכו לסווג אותה כבעלת סודיות בינונית או גבוהה.
- אם לאפליקציה יש גישה לנתונים עם רמת יושרה גבוהה, בדרך כלל כדאי לסווג את האפליקציה כבעלת רמת יושרה גבוהה. אבל אם הגישה היא לקריאה בלבד, יכול להיות שהסיווג הזה יהיה מחמיר מדי.
לפרטים על גישה פורמלית לסיווג אפליקציות, אפשר לעיין במדריך למיפוי סוגי מידע ומערכות מידע לקטגוריות אבטחה (NIST SP 800-60 כרך 2, גרסה 1).
סיווג משאבי ענן על סמך הנתונים והאפליקציות שהם מארחים
כל נתון או אפליקציה שאתם פורסים ב- Google Cloud מתארחים במשאבGoogle Cloud :
- אפליקציה יכולה להיות מאוחסנת בשירות App Engine, במכונה וירטואלית או באשכול GKE.
- יכול להיות שהנתונים שלכם מאוחסנים בדיסק קשיח, בקטגוריה של Cloud Storage או במערך נתונים ב-BigQuery.
כשמשאב בענן מארח מידע אישי רגיש או אפליקציות, גם המשאב וגם צינור עיבוד הנתונים לפריסה שמנהל את המשאב יכולים להפוך לרגישים. לדוגמה, צריך להתייחס לשירות Cloud Run ולצינור עיבוד הנתונים לפריסה שלו כאל רגישים כמו האפליקציה שהוא מארח.
אחרי סיווג הנתונים והאפליקציות, יוצרים קטגוריית אבטחה ראשונית לאפליקציה. כדי לעשות זאת, צריך לבחור רמה מבין הקטגוריות הבאות:
- סודיות: הקטגוריה הגבוהה ביותר של נתונים או אפליקציות שמתארחים
- תקינות: הקטגוריה הגבוהה ביותר של נתונים או אפליקציות שמתארחים
- זמינות: הקטגוריה הגבוהה ביותר של נתונים או אפליקציה שמתארחים
כשאתם מבצעים את ההערכה הראשונית, אל תהיו קפדניים מדי – לדוגמה:
- אם מצפינים נתונים סודיים ביותר, צריך להתייחס למפתח ההצפנה כאל נתונים סודיים ביותר. אבל אפשר להשתמש בקטגוריית אבטחה נמוכה יותר עבור המשאב שמכיל את הנתונים.
- אם אתם מאחסנים עותקים מיותרים של נתונים, או מפעילים מופעים מיותרים של אותן אפליקציות בכמה משאבים, אתם יכולים להגדיר את הקטגוריה של המשאב כנמוכה יותר מהקטגוריה של הנתונים או האפליקציה שהוא מארח.
הגבלת השימוש בצינורות עיבוד נתונים לפריסה
אם צינור עיבוד הנתונים לפריסה צריך לגשת למשאבים רגישים Google Cloud, צריך לבדוק את מצב האבטחה שלו. ככל שהמשאבים רגישים יותר, כך צריך להשקיע יותר מאמץ באבטחת צינור הנתונים. עם זאת, יכול להיות שתיתקלו במגבלות המעשיות הבאות:
- כשמשתמשים בתשתית קיימת או במערכת CI/CD קיימת, יכול להיות שהתשתית הזו תגביל את רמת האבטחה שאפשר להשיג בפועל. לדוגמה, יכול להיות שמערכת ה-CI/CD שלכם תומכת רק בקבוצה מוגבלת של אמצעי בקרה לאבטחה, או שהיא פועלת בתשתית שאתם מחשיבים כפחות מאובטחת מחלק מסביבות הייצור שלכם.
- כשמגדירים תשתית ומערכות חדשות להפעלת צינור עיבוד הנתונים לפריסה, יכול להיות שלא יהיה משתלם לאבטח את כל הרכיבים באופן שעומד בדרישות האבטחה המחמירות ביותר.
כדי להתמודד עם המגבלות האלה, כדאי להגדיר אילו תרחישים צריכים להשתמש בצינורות פריסה ובמערכת CI/CD מסוימת, ואילו לא. לדוגמה, עדיף לטפל בפריסות הרגישות ביותר מחוץ לצינור פריסה. הפריסות האלה יכולות להיות ידניות, באמצעות מערכת ניהול סשנים עם הרשאות או מערכת ניהול גישה עם הרשאות, או משהו אחר, כמו שרתי proxy של כלים.
כדי להגדיר את ההגבלות, צריך להגדיר אילו אמצעי בקרה לגישה רוצים לאכוף על סמך קטגוריות המשאבים. כדאי להיעזר בהנחיות שבטבלה הבאה:
| קטגוריית המשאב | בקרת גישה |
|---|---|
| נמוכה | לא נדרש אישור |
| בינוני | נדרש אישור מראש הצוות |
| גבוהה | נדרש אישור מכמה מובילי פרויקטים והפעולות צריכות להיות מתועדות |
כדי להשוות בין הדרישות האלה לבין היכולות של המערכות לניהול קוד מקור (SCM) ול-CI/CD, כדאי לשאול את השאלות הבאות ואחרות:
- האם מערכות ה-SCM או ה-CI/CD תומכות באמצעי בקרת גישה ובמנגנוני אישור נדרשים?
- האם אמצעי הבקרה מוגנים מפני חדירה אם גורמים זדוניים תוקפים את התשתית הבסיסית?
- האם התצורה שמגדירה את אמצעי הבקרה מאובטחת בצורה מתאימה?
בהתאם ליכולות ולמגבלות של מערכות ה-SCM או ה-CI/CD, אפשר להגדיר את האילוצים של הנתונים והאפליקציות בצינורות הפריסה. כדאי לעיין בהנחיות שבטבלה הבאה:
| קטגוריית המשאב | מגבלות |
|---|---|
| נמוכה | אפשר להשתמש בצינורות פריסה, והמפתחים יכולים לאשר בעצמם פריסות. |
| בינוני | אפשר להשתמש בצינורות עיבוד נתונים לפריסה, אבל מנהל הצוות צריך לאשר כל פעולת commit ופריסה. |
| גבוהה | לא משתמשים בצינורות פריסה. במקום זאת, האדמינים צריכים להשתמש במערכת לניהול גישה עם הרשאות מיוחדות ובהקלטת סשנים. |
שמירה על זמינות המשאבים
שימוש בצינור עיבוד נתונים לפריסה לניהול משאבים יכול להשפיע על הזמינות של המשאבים האלה, ועלול ליצור סיכונים חדשים:
- גורם להפסקות שירות: צינור עיבוד נתונים לפריסה עשוי להעביר קוד פגום או קובצי הגדרה, ולגרום למערכת שעבדה בעבר להתקלקל או לנתונים להפוך ללא שמישים.
- הארכת משך ההשבתה: כדי לתקן השבתה, יכול להיות שתצטרכו להפעיל מחדש צינור עיבוד נתונים לפריסה. אם צינור עיבוד הנתונים לפריסה שבור או לא זמין מסיבות אחרות, יכול להיות שמשך ההשבתה יתארך.
פייפליין שעלול לגרום להפסקות זמניות בשירות או להאריך אותן יוצר סיכון של התקפת מניעת שירות (DoS): גורם זדוני עלול להשתמש בפייפליין לפריסה כדי לגרום להפסקות זמניות בשירות בכוונה.
יצירת נהלים לגישת חירום
כשצינור עיבוד נתונים לפריסה הוא הדרך היחידה לפרוס או להגדיר אפליקציה או משאב, הזמינות של צינור עיבוד הנתונים יכולה להיות קריטית. במקרים קיצוניים, שבהם צינור עיבוד נתונים לפריסה הוא הדרך היחידה לנהל אפליקציה קריטית לעסק, יכול להיות שתצטרכו להתייחס לצינור עיבוד הנתונים לפריסה כקריטי לעסק.
צינורות עיבוד נתונים לפריסה מורכבים לרוב ממערכות ומכלים רבים, ולכן יכול להיות קשה או לא משתלם לשמור על רמת זמינות גבוהה.
כדי לצמצם את ההשפעה של צינורות עיבוד נתונים לפריסה על הזמינות, אפשר ליצור נהלים לגישת חירום. לדוגמה, אפשר ליצור נתיב גישה חלופי שאפשר להשתמש בו אם צינור עיבוד הנתונים לפריסה לא פועל.
כדי ליצור תהליך לגישת חירום, בדרך כלל צריך לבצע את רוב התהליכים הבאים:
- תחזוקה של חשבון משתמש אחד או יותר עם גישה מורשית למשאבים רלוונטיים.Google Cloud
- מאחסנים את פרטי הכניסה של חשבונות משתמשים עם גישת חירום במיקום בטוח, או משתמשים במערכת לניהול גישה עם הרשאות כדי לתווך את הגישה.
- צריך ליצור נוהל שמאפשר לעובדים מורשים לגשת לפרטי הכניסה.
- ביצוע ביקורת ובדיקה של השימוש בחשבונות משתמשים עם גישת חירום.
לוודא שפריטי הקלט עומדים בדרישות הזמינות
בדרך כלל, פייפליינים לפריסה צריכים להוריד קוד מקור ממאגר המקורות של הקוד מרכזי לפני שהם יכולים לבצע פריסה. אם מאגר המקורות של הקוד לא זמין, סביר להניח שהפעלת הפייפליין לפריסה תיכשל.
הרבה צינורות פריסה מסתמכים גם על ארטיפקטים של צד שלישי. פריטים כאלה יכולים לכלול ספריות ממקורות כמו npm, Maven Central או NuGet Gallery, וגם תמונות בסיס של קונטיינרים וחבילות .deb ו-.rpm. אם אחד מהמקורות של צד שלישי לא זמין, יכול להיות שהפעלת צינור הפריסה תיכשל.
כדי לשמור על רמת זמינות מסוימת, צריך לוודא שכל פריטי הקלט של צינור הפריסה עומדים בדרישות זמינות זהות או גבוהות יותר. הרשימה הבאה יכולה לעזור לכם לוודא שפריטי הקלט זמינים:
- הגבלת מספר המקורות של ארטיפקטים של קלט, במיוחד מקורות של צד שלישי
- שמירה במטמון של ארטיפקטים של קלט שצינורות עיבוד נתונים לפריסה יכולים להשתמש בהם אם מערכות המקור לא זמינות
התייחסות לצינורות עיבוד נתונים לפריסה ולתשתית שלהם כמו למערכות ייצור
צינורות עיבוד נתונים לפריסה משמשים לעיתים קרובות כרקמת החיבור בין סביבות פיתוח, Staging וייצור. בהתאם לסביבה, יכול להיות שהם יטמיעו כמה שלבים:
- בשלב הראשון, צינור הפריסה מעדכן סביבת פיתוח.
- בשלב הבא, צינור הפריסה מעדכן סביבת ביניים.
- בשלב האחרון, צינור עיבוד הנתונים לפריסה מעדכן את סביבת הייצור.
כשמשתמשים בצינור פריסה בכמה סביבות, חשוב לוודא שצינור הפריסה עומד בדרישות הזמינות של כל סביבה. בדרך כלל, בסביבות ייצור יש דרישות זמינות גבוהות ביותר, ולכן צריך להתייחס לצינור עיבוד הנתונים לפריסה ולתשתית הבסיסית שלו כמו למערכת ייצור. במילים אחרות, צריך להחיל על התשתית שמריצה את צינורות הפריסה את אותם תקני בקרת גישה, אבטחה ואיכות שחלים על מערכות הייצור.
הגבלת ההיקף של צינורות עיבוד נתונים לפריסה
ככל שלצינור פריסה יש גישה ליותר משאבים, כך הנזק שהוא עלול לגרום אם הוא ייפרץ יהיה גדול יותר. צינור פריסה שנפרץ ויש לו גישה לכמה פרויקטים או אפילו לכל הארגון, עלול לגרום במקרה הגרוע ביותר לנזק מתמשך לכל הנתונים והאפליקציות ב-Google Cloud.
כדי למנוע את התרחיש הגרוע הזה, כדאי להגביל את ההיקף של צינורות עיבוד הנתונים לפריסה. צריך להגדיר את ההיקף של כל צינור עיבוד נתונים לפריסה כך שהוא יזדקק לגישה רק למספר קטן יחסית של משאבים ב- Google Cloud:
- במקום להעניק גישה ברמת הפרויקט, מעניקים לצינורות עיבוד נתונים לפריסה גישה רק למשאבים ספציפיים.
- נמנעים מהענקת גישה למשאבים בכמה פרויקטים. Google Cloud
- אם צינורות הפריסה צריכים גישה לכמה פרויקטים או סביבות, צריך לפצל אותם לכמה שלבים ואז לאבטח כל שלב בנפרד.
שמירה על סודיות
צינור פריסה חייב לשמור על סודיות הנתונים שהוא מנהל. אחד הסיכונים העיקריים שקשורים לסודיות הוא זליגת נתונים.
יש כמה דרכים שבהן גורם זדוני עלול לנסות להשתמש בצינור עיבוד נתונים לפריסה כדי לחלץ נתונים מהמשאבים שלכם ב- Google Cloud . הדרכים האלה כוללות:
- ישירה: גורם זדוני עלול לשנות את צינור עיבוד הנתונים לפריסה או את ההגדרה שלו כדי לחלץ נתונים מהמשאבים שלכם ב- Google Cloudואז להעתיק אותם למקום אחר.
- עקיפה: גורם זדוני עלול להשתמש בצינור עיבוד הנתונים לפריסה כדי לפרוס קוד שנפרץ, ואז הקוד הזה יגנוב נתונים מהסביבה שלכם ב- Google Cloud.
כדי לצמצם את הסיכונים שקשורים לסודיות, כדאי לצמצם את הגישה למשאבים סודיים. עם זאת, יכול להיות שלא יהיה מעשי להסיר את כל הגישה למשאבים סודיים. לכן, צריך לתכנן את צינור עיבוד הנתונים לפריסה כך שיעמוד בדרישות הסודיות של המשאבים שהוא מנהל. כדי לקבוע את הדרישות האלה, אפשר להשתמש בגישה הבאה:
- קובעים לאילו נתונים, אפליקציות ומשאבים צינור הפריסה צריך לגשת, ומסווגים אותם.
- מחפשים את המשאב עם קטגוריית הסודיות הכי גבוהה ומשתמשים בו כקטגוריה ראשונית לצינור הפריסה.
בדומה לתהליך הסיווג של אפליקציות ומשאבי ענן, ההערכה הראשונית הזו לא תמיד מתאימה. לדוגמה, יכול להיות שתשתמשו בצינור פריסה כדי ליצור משאבים שבסופו של דבר יכילו מידע סודי ביותר. אם מגבילים את צינור עיבוד הנתונים לפריסה כך שהוא יוכל ליצור את המשאבים האלה אבל לא לקרוא אותם, יכול להיות שקטגוריית סודיות נמוכה יותר תספיק.
כדי לשמור על סודיות, מודל Bell–LaPadula מציע שצינור פריסה לא צריך:
- צריכת פריטי קלט בעלי סודיות גבוהה יותר
- כתיבת נתונים למשאב ברמת סודיות נמוכה יותר
לפי מודל Bell–LaPadula, בתרשים שלמעלה מוצג אופן הזרימה של הנתונים בפייפליין כדי להבטיח את סודיות הנתונים.
לא מאפשרים לצינורות עיבוד נתונים לפריסה לקרוא נתונים שהם לא צריכים
לרוב, לצינורות עיבוד נתונים לפריסה אין צורך בגישה לנתונים, אבל יכול להיות שהם עדיין יקבלו גישה. מתן גישה רחבה מדי כזה יכול לנבוע מהסיבות הבאות:
- מתן הרשאות גישה שגויות. לדוגמה, יכול להיות שצינור פריסה יקבל גישה ל-Cloud Storage ברמת הפרויקט. כתוצאה מכך, צינור הפריסה יכול לגשת לכל הקטגוריות של Cloud Storage בפרויקט, למרות שגישה לקטגוריה אחת עשויה להספיק.
- שימוש בתפקיד עם יותר מדי הרשאות. לדוגמה, יכול להיות שצינור עיבוד הנתונים לפריסה קיבל תפקיד שמעניק גישה מלאה ל-Cloud Storage. עם זאת, הרשאה ליצור מאגרי מידע חדשים תספיק.
ככל שלצינור עיבוד נתונים יש גישה ליותר נתונים, כך גדל הסיכון שמישהו או משהו יגנוב את הנתונים. כדי לצמצם את הסיכון הזה, מומלץ להימנע ממתן גישה לצינורות עיבוד נתונים לפריסה לנתונים שהם לא צריכים. להרבה צינורות עיבוד נתונים לפריסה אין צורך בגישה לנתונים בכלל, כי המטרה היחידה שלהם היא לנהל פריסות של הגדרות או של תוכנה.
לא מאפשרים לצינורות פריסה לכתוב למיקומים שהם לא צריכים
כדי להסיר נתונים, גורם זדוני צריך גישה ודרך להעביר את הנתונים מחוץ לסביבה שלכם. ככל שצינור עיבוד הנתונים לפריסה יכול לשלוח נתונים ליותר מיקומים ברשת ובאחסון, כך גדל הסיכוי שגורם זדוני יוכל להשתמש באחד מהמיקומים האלה כדי לבצע זליגת נתונים.
כדי לצמצם את הסיכון, אפשר להגביל את מספר המיקומים ברשת ובאחסון שאליהם צינור יכול לשלוח נתונים:
- ביטול הרשאת כתיבה למשאבים שצינור עיבוד הנתונים לא צריך, גם אם המשאבים לא מכילים נתונים סודיים.
- חסימת הגישה לאינטרנט או הגבלת החיבורים לקבוצה של מיקומי רשת שנכללים ברשימת ההיתרים.
הגבלת הגישה היוצאת חשובה במיוחד לצינורות שסווגו כסודיים למדי או כסודיים מאוד, כי יש להם גישה לנתונים סודיים או לחומר מפתח קריפטוגרפי.
שימוש ב-VPC Service Controls כדי למנוע פריצה לפריסות וגניבת נתונים
במקום לאפשר לצינור עיבוד הנתונים לפריסה לבצע זליגת נתונים, גורם זדוני עלול לנסות להשתמש בצינור עיבוד הנתונים לפריסה כדי לפרוס קוד שנפרץ. הקוד שנפרץ יכול לגנוב נתונים מתוך סביבת Google Cloud.
כדי לצמצם את הסיכון לאיומים כאלה של גניבת נתונים, אפשר להשתמש ב-VPC Service Controls. בעזרת VPC Service Controls אפשר להגביל את קבוצת המשאבים וממשקי ה-API שאפשר לגשת אליהם מתוךGoogle Cloud פרויקטים מסוימים.
שמירה על התקינות
כדי לשמור על האבטחה של סביבת Google Cloud , צריך להגן על השלמות שלה. למשל:
- מניעת שינוי או מחיקה לא מורשים של נתונים או הגדרות
- מניעת פריסה של קוד או הגדרה לא מהימנים
- לוודא שכל השינויים משאירים שובל ביקורת ברור
צינורות פריסה יכולים לעזור לכם לשמור על התקינות של הסביבה, כי הם מאפשרים לכם:
- הטמעת תהליכי אישור – לדוגמה, בצורה של בדיקות קוד
- אכיפת תהליך עקבי לכל שינוי בהגדרות או בקוד
- הפעלת בדיקות אוטומטיות או בדיקות מהירות לפני כל פריסה
כדי שהאמצעים האלה יהיו אפקטיביים, צריך לוודא שגורמים זדוניים לא יוכלו לערער אותם או לעקוף אותם. כדי למנוע פעילות כזו, צריך להגן על השלמות של:
- צינור עיבוד הנתונים לפריסה וההגדרות שלו
- התשתית הבסיסית
- כל מקורות הקלט שצינור עיבוד הנתונים לפריסה צורך
כדי למנוע מצב שבו צינור עיבוד הנתונים לפריסה יהיה פגיע, כדאי לוודא שסטנדרטי התקינות של צינור עיבוד הנתונים לפריסה תואמים לדרישות התקינות של המשאבים שהוא מנהל, או עולים עליהן. כדי לקבוע את הדרישות האלה, אפשר להשתמש בגישה הבאה:
- קובעים לאילו נתונים, אפליקציות ומשאבים צינור הפריסה צריך לגשת, ומסווגים אותם.
- מחפשים את המשאב עם קטגוריית היושרה הכי גבוהה ומשתמשים בו כקטגוריה של צינור הפריסה.
כדי לשמור על התקינות של צינור עיבוד הנתונים לפריסה, מודל Biba מציע:
- צינור הפריסה לא יכול לצרוך פריטי קלט עם רמת יושרה נמוכה יותר.
- צינור הפריסה לא יכול לכתוב נתונים למשאב עם רמת יושרה גבוהה יותר.
לפי מודל Biba, בתרשים הקודם מוצג איך הנתונים צריכים לזרום בצינור כדי להבטיח את שלמות הנתונים.
אימות האותנטיות של ארטיפקטים של קלט
הרבה צינורות פריסה צורכים ארטיפקטים ממקורות של צד שלישי. ארטיפקטים כאלה יכולים לכלול:
- תמונות בסיס של Docker
-
.rpmאו.debחבילות - ספריות Maven,
.npmאו NuGet
גורם זדוני עלול לנסות לשנות את צינור עיבוד הנתונים לפריסה כדי שישתמש בגרסאות שנפרצו של ארטיפקטים של צד שלישי, על ידי:
- פריצה למאגר שבו מאוחסנים הארטיפקטים
- שינוי ההגדרה של צינור עיבוד הנתונים לפריסה כדי להשתמש במאגר מקור אחר
- העלאת חבילות זדוניות עם שמות דומים או שמות שמכילים שגיאות הקלדה
מנהלי חבילות רבים מאפשרים לאמת את האותנטיות של חבילה באמצעות תמיכה בחתימת קוד. לדוגמה, אפשר להשתמש ב-PGP כדי לחתום על חבילות RPM ו-Maven. אפשר להשתמש ב-Authenticode כדי לחתום על חבילות NuGet.
אתם יכולים להשתמש בחתימת קוד כדי להפחית את הסיכון ליפול קורבן לחבילות צד שלישי שנפרצו, על ידי:
- דרישה שכל הארטיפקטים של צד שלישי יהיו חתומים
- שמירה על רשימה שנבחרה בקפידה של אישורים או מפתחות ציבוריים מהימנים של בעלי תוכן דיגיטלי
- איך מאפשרים לצינור הפריסה לאמת את החתימה של ארטיפקטים של צד שלישי מול רשימת המפרסמים המהימנים
אפשר גם לאמת את הגיבובים של הארטיפקטים. אפשר להשתמש בגישה הזו לארטיפקטים שלא תומכים בחתימת קוד ומשתנים לעיתים רחוקות.
לוודא שהתשתית הבסיסית עומדת בדרישות שלכם בנוגע לשלמות
במקום לפגוע בצינור הפריסה עצמו, גורמים זדוניים עשויים לנסות לפגוע בתשתית שלו, כולל:
- תוכנת ה-CI/CD שמריצה את צינור הפריסה
- הכלים שבהם נעשה שימוש בצינור – לדוגמה, Terraform, kubectl או Docker
- מערכת ההפעלה וכל הרכיבים שלה
התשתית שעליה מבוססים פייפליינים לפריסה היא לרוב מורכבת, ועשויה להכיל רכיבים מספקים או ממקורות שונים, ולכן קשה לזהות סוג כזה של תקרית אבטחת מידע.
כדי להפחית את הסיכון לפריצה לתשתית, אפשר:
- התשתית וכל הרכיבים שלה עומדים באותם תקני יושרה כמו צינור עיבוד הנתונים לפריסה ו Google Cloud המשאבים שהוא מנהל
- מוודאים שהכלים מגיעים ממקור מהימן ומאמתים את האותנטיות שלהם
- בנייה מחדש של התשתית באופן קבוע
- הפעלת צינור עיבוד הנתונים לפריסה במכונות וירטואליות מוגנות
החלת אמצעי בקרה של תקינות בצינור העיבוד
שחקנים זדוניים הם איום, אבל הם לא המקור האפשרי היחיד לשינויים בתוכנה או בהגדרות שעלולים לפגוע בשלמות של סביבתGoogle Cloud . שינויים כאלה יכולים גם להגיע ממפתחים, והם יכולים להיות מקריים, בגלל חוסר מודעות או בגלל שגיאות הקלדה ושגיאות אחרות.
כדי לצמצם את הסיכון להחלת שינויים מסוכנים בטעות, אפשר להגדיר צינורות פריסה להחלת אמצעי בקרה נוספים של יושרה. אמצעי בקרה כאלה יכולים לכלול:
- ביצוע ניתוח סטטי של קוד ושל הגדרות
- דרישה שכל השינויים יעמדו בסדרה של כללים (מדיניות כקוד)
- הגבלת מספר השינויים שאפשר לבצע בו-זמנית
המאמרים הבאים
- שיטות מומלצות לשימוש בחשבונות שירות בצינורות עיבוד נתונים לפריסה
- מומלץ לקרוא את המאמר שיטות מומלצות לאבטחת חשבונות שירות.
- מידע נוסף על חקירה של איומים ותגובה לאיומים
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.