שיטות מומלצות לאבטחה ב-Cloud Service Mesh

במסמך הזה נסביר על שיטות מומלצות להגדרה ולניהול של Cloud Service Mesh מאובטח שפועל ב-Google Kubernetes Engine‏ (GKE). ההנחיות במאמר הזה חורגות מההגדרות שמשמשות להגדרה ולהתקנה של Cloud Service Mesh, ומתארות איך אפשר להשתמש ב-Cloud Service Mesh עם מוצרים ותכונות אחרים של Google CloudGoogle כדי להגן מפני איומי אבטחה שאפליקציות ברשת עלולות להתמודד איתם.

קהל היעד של המאמר הזה כולל אדמינים שמנהלים מדיניות ב-Cloud Service Mesh ומשתמשים שמפעילים שירותים ב-Cloud Service Mesh. אמצעי האבטחה שמתוארים כאן שימושיים גם לארגונים שצריכים לשפר את האבטחה של רשתות השירות שלהם כדי לעמוד בדרישות התאימות.

המבנה של המסמך הוא כזה:

מבוא

‫Cloud Service Mesh מספק תכונות וכלים שעוזרים לכם לצפות בשירותים, לנהל אותם ולאבטח אותם בצורה מאוחדת. הגישה מתמקדת באפליקציות ומשתמשת בזהויות אפליקציות מהימנות במקום בגישה שמתמקדת בכתובות IP ברשת. אפשר לפרוס Service mesh באופן שקוף בלי לשנות את קוד האפליקציה הקיים. ‫Cloud Service Mesh מספק שליטה הצהרתית בהתנהגות הרשת, ועוזר להפריד בין העבודה של צוותים שאחראים על אספקה ושחרור של תכונות אפליקציה לבין האחריות של אדמינים שאחראים על אבטחה ורשתות.

‫Cloud Service Mesh מבוסס על Istio service mesh בקוד פתוח, שמאפשר הגדרות וטופולוגיות מתוחכמות. בהתאם למבנה הארגון, יכול להיות שצוות אחד או יותר או תפקיד אחד או יותר יהיו אחראים להתקנה ולהגדרה של רשת Mesh. ההגדרות שמוגדרות כברירת מחדל ב-Cloud Service Mesh נבחרו כדי להגן על האפליקציות, אבל במקרים מסוימים יכול להיות שתצטרכו הגדרות בהתאמה אישית או להעניק חריגים על ידי החרגת אפליקציות, יציאות או כתובות IP מסוימות מהשתתפות ברשת. חשוב להגדיר אמצעי בקרה שינהלו את תצורות הרשת ואת חריגי האבטחה.

וקטורי תקיפה וסיכוני אבטחה

וקטורי תקיפה

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

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

אפשר גם לסווג את ההתקפות לפי יעדי ההתקפה:

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

סיכוני אבטחה

בנוסף למתקפות אבטחה, רשת Mesh חשופה גם לסיכוני אבטחה אחרים. ברשימה הבאה מתוארים כמה סיכוני אבטחה אפשריים:

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

אמצעים להגנה על Service mesh

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

ארכיטקטורת אבטחה

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

מצב האבטחה של Cloud Service Mesh

‫Cloud Service Mesh מספק אבטחה בכמה שכבות, כולל:

  • אבטחת קצה של רשת Mesh
    • אבטחת הכניסה של Cloud Service Mesh מספקת בקרת גישה לתנועה חיצונית ומאבטחת גישה חיצונית לממשקי ה-API שנחשפים על ידי השירותים ברשת.
    • אבטחת התעבורה היוצאת (egress) ב-Cloud Service Mesh מווסתת את התעבורה היוצאת מעומסי עבודה פנימיים.
    • Cloud Service Mesh User Auth משתלב עם התשתית של Google כדי לאמת קריאות חיצוניות מדפדפני אינטרנט לשירותים שמריצים אפליקציות אינטרנט.
    • ניהול אישורים של שערים ב-Cloud Service Mesh מגן על המפתחות הפרטיים ועל אישורי X.509 שמשמשים לשערי כניסה ויציאה של Cloud Service Mesh ומבצע רוטציה שלהם באמצעות Certificate Authority Service.
    • ‫Cloud Armor יכול להגן מפני התקפות מניעת שירות מבוזרות (DDoS) חיצוניות והתקפות בשכבה 7. הוא משמש כחומת אש לאפליקציות אינטרנט (WAF) כדי להגן על הרשת מפני התקפות רשת. לדוגמה, מתקפות של החדרת קוד והרצת קוד מרחוק.
    • ‫VPC ו-VPC Service Controls מגנים על קצה הרשת באמצעות אמצעי בקרה לגישה לרשת פרטית.
  • אבטחת אשכולות
    • ב-Cloud Service Mesh,‏ TLS בו-זמני (mTLS) מאפשר הצפנה ואימות של תעבורה בין עומסי עבודה.
    • רשות אישורים מנוהלת, כמו רשות האישורים של Cloud Service Mesh ו-Certificate Authority Service, מספקת ומנהלת באופן מאובטח אישורים שמשמשים את עומסי העבודה.
    • הרשאות ב-Cloud Service Mesh אוכפות בקרת גישה לשירותי רשת על סמך הזהויות שלהם ומאפיינים אחרים.
    • לוח הבקרה לאבטחה של GKE Enterprise מאפשר מעקב אחרי ההגדרות של מדיניות האבטחה ומדיניות הרשת של Kubernetes עבור עומסי העבודה.
    • מדיניות הרשת של Kubernetes אוכפת בקרת גישה לקבוצות Pod על סמך כתובות IP, תוויות של קבוצות Pod, מרחבי שמות ועוד.
    • אבטחת מישור הבקרה מגינה מפני התקפות על מישור הבקרה. ההגנה הזו מונעת מתוקפים לשנות את נתוני התצורה של השירות והרשת, לנצל אותם או להדליף אותם.
  • אבטחת עומסי עבודה
    • כדי לוודא שקובצי ה-binary של Cloud Service Mesh שפועלים ברשת שלכם לא מכילים נקודות חולשה שמוכרות לציבור, חשוב להתעדכן בגרסאות האבטחה של Cloud Service Mesh.
    • איחוד זהויות של עומסי עבודה ל-GKE מאפשר לעומסי עבודה לקבל פרטי כניסה כדי לבצע קריאות מאובטחות לשירותי Google.
    • ‫CNI‏ (Container Network Interface) של Kubernetes מונע מתקפות של העלאת רמת הרשאה, כי הוא מבטל את הצורך ב-init container של Cloud Service Mesh עם הרשאות.
  • אבטחת אופרטורים
    • בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes מגבילה את הגישה למשאבי Kubernetes ומגבילה את הרשאות המפעיל כדי לצמצם את הסיכון להתקפות שמקורן במפעילים זדוניים או בהתחזות למפעיל.
    • ‫GKE Enterprise Policy Controller מאמת ומבצע ביקורת על הגדרות המדיניות ברשת כדי למנוע טעויות בהגדרות.
    • Google Cloud Binary Authorization מוודא שתמונות עומס העבודה ברשת הן אלה שהאדמינים אישרו.
    • Google Cloud רישום ביומן הביקורת בודק פעולות ברשת.

בתרשים שלמטה מוצגים תהליכי התקשורת וההגדרה של פתרונות האבטחה המשולבים ב-Cloud Service Mesh.

תרשים אבטחה של זרימת התנועה

אבטחת אשכולות

הפעלת פרוטוקול TLS הדדי קפדני

במתקפת 'אדם באמצע' (MitM) מנסים להחדיר ישות זדונית בין שני צדדים שמתקשרים ביניהם כדי לצותת לתקשורת או לתפעל אותה. Cloud Service Mesh מגן מפני מתקפות MitM ומתקפות של גניבת נתונים על ידי אכיפה של אימות והצפנה של mTLS לכל הצדדים המתקשרים. במצב מקל, נעשה שימוש ב-mTLS אם שני הצדדים תומכים בו, אבל מותרים חיבורים ללא mTLS. לעומת זאת, mTLS מחמיר מחייב שהתנועה תהיה מוצפנת ומאומתת באמצעות mTLS, ולא מאפשר תנועה של טקסט רגיל.

Cloud Service Mesh מאפשר לכם להגדיר את גרסת ה-TLS המינימלית לחיבורי ה-TLS בין עומסי העבודה, כדי לעמוד בדרישות האבטחה והתאימות שלכם.

מידע נוסף זמין במאמר Cloud Service Mesh by example: mTLS | Enforcing mesh-wide mTLS.

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

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

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

מדיניות ההרשאות של Cloud Service Mesh מספקת דרך גמישה להגדרת אמצעי בקרה להגבלת הגישה, כדי להגן על השירותים מפני גישה לא מורשית. צריך לאכוף את מדיניות ההרשאות של Cloud Service Mesh על סמך הזהויות המאומתות שנגזרות מתוצאות האימות. צריך להשתמש באימותים מבוססי-mTLS או מבוססי-JSON Web Token ‏ (JWT) ביחד כחלק ממדיניות ההרשאות של Cloud Service Mesh.

אכיפה של מדיניות אימות ב-Cloud Service Mesh

טוקן רשת מבוסס JSON‏ (JWT)

בנוסף לאימות mTLS, אדמינים של רשתות יכולים לדרוש משירות לאמת ולאשר בקשות על סמך JWT. ‫Cloud Service Mesh לא פועל כספק JWT, אלא מאמת JWT על סמך נקודות הקצה של קבוצת מפתחות האינטרנט בפורמט JSON ‏ (JWKS) שהוגדרו. אפשר להחיל אימות JWT על שערים של תנועה נכנסת לתנועה חיצונית או על שירותים פנימיים לתנועה בתוך הרשת. אפשר לשלב אימות JWT עם אימות mTLS כשמשתמשים ב-JWT כפרטי כניסה שמייצגים את מבצע הקריאה הסופית, והשירות המבוקש דורש הוכחה לכך שהקריאה מתבצעת בשם מבצע הקריאה הסופית. אכיפת אימות JWT מגנה מפני מתקפות שמאפשרות גישה לשירות ללא פרטי כניסה תקפים, ובשם משתמש קצה אמיתי.

אימות משתמשים ב-Cloud Service Mesh

אימות משתמשים ב-Cloud Service Mesh הוא פתרון משולב לאימות משתמשי קצה מבוסס-דפדפן ולבקרת גישה לעומסי העבודה. הוא משלב רשת שירותים עם ספקי זהויות (IdP) קיימים כדי להטמיע זרימת כניסה והסכמה סטנדרטית מבוססת-אינטרנט של OpenID Connect ‏ (OIDC), ומשתמש במדיניות הרשאות של Cloud Service Mesh לצורך בקרת גישה.

אכיפת מדיניות ההרשאות

מדיניות ההרשאות של Cloud Service Mesh שולטת ב:

  • מי או מה מורשים לגשת לשירות.
  • אילו משאבים אפשר לגשת.
  • אילו פעולות אפשר לבצע במשאבים המותרים.

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

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

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

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

אפשר להשתמש במדיניות הרשאה יחד עם מדיניות רשת של Kubernetes, שפועלת רק בשכבת הרשת (שכבה 3 ושכבה 4) ושולטת בגישה לרשת לכתובות IP ולפורטים בקבוצות Pod של Kubernetes ובמרחבי שמות של Kubernetes.

החלת המרת אסימונים לגישה לשירותי רשת

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

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

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