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

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

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

המסמך מאורגן באופן הבא:

מבוא

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

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

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

וקטורי תקיפה

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

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

אפשר גם לסווג את המתקפות לפי המטרות שלהן:

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

סיכוני אבטחה

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

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

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

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

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

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

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

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

  • אבטחה בקצה הרשת
    • אבטחת תעבורת הנתונים הנכנסת ב-Cloud Service Mesh מספקת בקרת גישה לתנועה חיצונית, ומאבטחת את הגישה החיצונית לממשקי ה-API שנחשפים על ידי השירותים ברשת.
    • אבטחת תעבורת הנתונים היוצאת (egress) ב-Cloud Service Mesh מסדירה את תעבורת הנתונים היוצאת מעומסי עבודה פנימיים.
    • אימות המשתמשים ב-Cloud Service Mesh משתלב בתשתית של Google כדי לאמת קריאות חיצוניות מדפדפני אינטרנט לשירותים שמריצים אפליקציות אינטרנט.
    • ניהול אישורי השער של Cloud Service Mesh מגן על המפתחות הפרטיים ועל אישורי X.509 שמשמשים את שערי הכניסה והיציאה של Cloud Service Mesh, ומחליף אותם באמצעות שירות רשות האישורים.
    • ‫Cloud Armor יכול להגן מפני התקפות מניעת שירות מבוזרות (DDoS) חיצוניות והתקפות בשכבה 7. הוא משמש כחומת אש ליישומי אינטרנט (WAF) כדי להגן על רשת ה-mesh מפני התקפות רשת. לדוגמה, התקפות הזרקה והרצת קוד מרחוק.
    • VPC ו-VPC Service Controls מגינים על קצה הרשת באמצעות בקרת הגישה לרשת הפרטית.
  • אבטחת אשכולות
    • ‫Cloud Service Mesh mutual 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) ב-Kubernetes מונע התקפות של הסלמת הרשאות, כי הוא מייתר את הצורך בקונטיינר init עם הרשאות ב-Cloud Service Mesh.
  • אבטחת המפעיל
    • בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes מגבילה את הגישה למשאבים ב-Kubernetes ואת ההרשאות של המפעילים, כדי לצמצם את ההתקפות שמקורן במפעילים זדוניים או בהתחזות למפעילים.
    • GKE Enterprise Policy Controller מאמת ומבקר את הגדרות המדיניות ברשת כדי למנוע הגדרות שגויות.
    • Google Cloud Binary Authorization מוודא שתמונות עומסי העבודה ברשת הן אלה שאושרו על ידי האדמינים.
    • Google Cloud רישום ביומן הביקורת מבצע ביקורת על פעולות ברשת.

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

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

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

הפעלת פרוטוקול TLS הדדי (mTLS) מחמיר

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

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

מידע נוסף זמין במאמר דוגמה ל-Cloud Service Mesh: ‏mTLS | אכיפת mTLS ברמת רשת ה-Mesh.

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

צריך לאכוף את מדיניות האבטחה של 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‏ (JWT) ביחד, כחלק מכללי מדיניות ההרשאות של Cloud Service Mesh.

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

‫JSON Web Token ‏ (JWT)

בנוסף לאימות mTLS, מנהלי רשת יכולים לדרוש משירות לאמת בקשות ולהעניק להן הרשאה על סמך JWT. ‫Cloud Service Mesh לא פועל כספק JWT, אלא מאמת אסימוני JWT על סמך נקודות הקצה המוגדרות של JSON Web Key Set‏ (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.

אכיפת החלפת טוקנים כדי לגשת לשירותי רשת

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

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

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