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

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

קהל היעד של המסמך הזה כולל אדמינים שמנהלים מדיניות ב-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 חשופה גם לסיכוני אבטחה אחרים. ברשימה הבאה מתוארים כמה סיכוני אבטחה אפשריים:

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

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

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

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

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

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

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

  • אבטחת קצה של רשת
    • אבטחת הכניסה ב-Cloud Service Mesh מספקת בקרת גישה לתנועה חיצונית ומאבטחת גישה חיצונית לממשקי ה-API שנחשפים על ידי השירותים ברשת.
    • אבטחת היציאה של 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 מגנים על קצה הרשת באמצעות אמצעי בקרה לגישה לרשת פרטית.
  • אבטחת אשכולות
    • הצפנה ואימות של תעבורה בין עומסי עבודה באמצעות TLS בו-זמני (mTLS) ב-Cloud Service Mesh.
    • רשות אישורים מנוהלת, כמו רשות האישורים של 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) ב-Kubernetes מונע מתקפות להעלאת רמת ההרשאה, כי הוא מבטל את הצורך בקונטיינר init של 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 Web Key Set‏ (JWKS) שהוגדרו. אפשר להחיל אימות JWT על שערים של תעבורת נתונים נכנסת (ingress) לתנועה חיצונית או על שירותים פנימיים לתנועה בתוך הרשת. אפשר לשלב אימות 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, כדי שהשירות יאמת ויאשר את הבקשה. יכול להיות שטוקן שמגיע מחוץ לרשת ה-Mesh יהיה תקף לזמן ארוך. כדי להתגונן מפני מתקפות חוזרות של אסימונים, צריך להחליף אסימון שמגיע מחוץ לרשת באסימון פנימי של הרשת עם תוקף קצר והיקף מוגבל בנקודת הכניסה לרשת. שירות הרשת מאמת אסימון פנימי לרשת ומאשר את בקשת הגישה על סמך האסימון הפנימי לרשת.

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