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

  • הגנה לא מלאה על האבטחה. לא הוגדר 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, מרחבי שמות ועוד.
    • אבטחת מישור הבקרה מגינה מפני התקפות על מישור הבקרה. ההגנה הזו מונעת מתוקפים לשנות, לנצל או להדליף נתוני תצורה של שירות ורשת.
  • אבטחת עומסי עבודה
    • כדי לוודא שקבצים בינאריים של Cloud Service Mesh שפועלים ברשת שלכם לא מכילים נקודות חולשה שמוכרות לציבור, חשוב להתעדכן בגרסאות האבטחה של Cloud Service Mesh.
    • איחוד זהויות של עומסי עבודה ל-GKE מאפשר לעומסי עבודה לקבל פרטי כניסה כדי לבצע קריאות מאובטחות לשירותי Google.
    • ‫Cloud Key Management Service (Cloud KMS) מאבטח מידע אישי רגיש או פרטי כניסה באמצעות מודולים לאבטחת חומרה (HSM). לדוגמה, עומסי עבודה יכולים להשתמש ב-Cloud KMS כדי לאחסן אישורים או מידע אישי רגיש אחר. שירות CA – משמש להנפקת אישורים לעומסי עבודה ברשת – תומך במפתחות חתימה לכל לקוח ומפתחות חתימה שמגובים ב-HSM ומנוהלים על ידי Cloud KMS.
    • ממשק רשת של קונטיינרים (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 על סמך נקודות הקצה (endpoints) של 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 יהיה תקף לזמן ארוך. כדי להתגונן מפני מתקפות חוזרות של אסימונים, צריך להחליף אסימון שמגיע מחוץ לרשת באסימון פנימי של הרשת עם תוקף קצר והיקף מוגבל בנקודת הכניסה לרשת. שירות הרשת מאמת אסימון פנימי לרשת ומאשר את בקשת הגישה על סמך האסימון הפנימי לרשת.

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

טיפול מאובטח בחריגים במדיניות של Cloud Service Mesh

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

יכול להיות שיש לכם סיבות מוצדקות לעקוף את מדיניות האבטחה של Cloud Service Mesh עבור חלק מהיציאות וטווח כתובות ה-IP. אתם יכולים להוסיף הערות (כמו excludeInboundPorts, excludeOutboundPorts, excludeOutboundIPRanges) ל-Pods כדי למנוע את הטיפול בתנועה על ידי Envoy sidecar. בנוסף להערות להחרגת תנועה, אפשר לעקוף את הרשת כולה על ידי פריסת אפליקציה עם השבתה של הזרקת sidecar. לדוגמה, על ידי הוספת התווית sidecar.istio.io/inject="false" ל-Pod של האפליקציה.

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

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

  • כדי למנוע מתקפות MITM, חשוב לוודא שהתנועה שעוקפת את קובצי ה-sidecar מוצפנת ומאומתת באופן מקורי.
  • אכיפת כללי מדיניות של רשת Kubernetes כדי להגביל את הקישוריות של יציאות עם חריגים במדיניות (לדוגמה, הגבלת יציאה עם חריגים במדיניות כך שתאפשר רק תעבורה משירות אחר באותו מרחב שמות) או כדי לאפשר רק לתעבורה לעבור דרך היציאות עם אכיפה של מדיניות האבטחה של Cloud Service Mesh.
  • אכיפה של Policy Controller ב-GKE Enterprise כדי לאמת באופן אוטומטי את כללי המדיניות של Cloud Service Mesh. לדוגמה, אפשר לאכוף את ההזרקה של רכיבי ה-sidecar של Cloud Service Mesh תמיד לעומסי העבודה.

אכיפה של מדיניות רשת ב-Kubernetes

‫Cloud Service Mesh מבוסס על הפלטפורמה הבסיסית (לדוגמה, Kubernetes). לכן, האבטחה של Cloud Service Mesh תלויה באבטחה של הפלטפורמה הבסיסית. לדוגמה, אם אין לכם שליטה על מי יכול לעדכן משאבי Kubernetes, משתמש יכול לשנות את ה-Deployment של שירות Kubernetes כדי לעקוף את ה-sidecar של השירות.

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

כללי מדיניות של רשת Kubernetes פועלים בשכבת הרשת (L3 ו-L4) עבור כתובות IP ויציאות ב-Pods ובמרחבי שמות של Kubernetes. אפשר לאכוף את כללי המדיניות של רשת Kubernetes בשילוב עם כללי המדיניות של Cloud Service Mesh כדי לשפר את האבטחה של הרשת.

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

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

מישור הבקרה של Cloud Service Mesh מאמת את כל הלקוחות שמתחברים. לכן, רק מפעילים עם פרטי כניסה תקפים (JWT של Kubernetes או אישורי X.509 שהונפקו על ידי רשויות אישורים מורשות) יכולים לגשת למישור הבקרה של Cloud Service Mesh. פרוטוקול TLS מצפין את החיבורים בין עומסי העבודה לבין מישור הבקרה של Cloud Service Mesh.

בנוסף למנגנון האימות, ב-Cloud Service Mesh בתוך האשכול, אפשר לפרוס מדיניות רשת של Kubernetes כדי לבודד את מרחב השמות של מערכת Cloud Service Mesh (ברירת המחדל היא istio-system) ממרחבי שמות לא מנוהלים ומלקוחות מחוץ לרשת, תוך מתן אפשרות למישורי נתונים לגשת למישור הבקרה. כללי חומת אש ב-VPC יכולים למנוע מתעבורת נתונים מחוץ לאשכול להגיע אל Istiod. באמצעות אמצעים כאלה לבידוד הרשת, תוקף מחוץ לרשת לא יוכל לגשת לרמת הבקרה, גם אם יש לו פרטי כניסה תקינים. במישורי בקרה מנוהלים, Google מטפלת באבטחה של מישורי הבקרה, ולכן אין צורך במדיניות כזו של בידוד רשת עבור מישורי בקרה.

אכיפת גבולות של מרחב שמות

כדי למנוע ממשתמש במרחב שמות אחד לגשת למשאבים במרחב שמות לא מורשה או לעדכן אותם:

  • אכיפת בקרת גישה.
  • אכיפה של כללי מדיניות לרשת ב-Kubernetes. אם לשירותים במרחב שמות אין תנועה מחוץ למרחב השמות, מנהל הרשת צריך לפרוס מדיניות רשת של Kubernetes שמאפשרת רק תנועה בתוך מרחב השמות: ללא תעבורת נתונים נכנסת (ingress) או תעבורת נתונים יוצאת (egress) ממרחב השמות.
  • אכיפת מדיניות RBAC ב-Kubernetes.
    • התפקידים של אדמינים של אפליקציות צריכים להיות קשורים למרחב שמות.
    • צריך לאפשר רק לאדמינים של רשתות Mesh לקבל ClusterRole.

אכיפת מדיניות RBAC ב-Kubernetes

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

אבטחת קצה של רשת Mesh

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

בקרת גישה לכניסה לאשכול

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

ה-Ingress צריך לאכוף אימות והרשאה לשירותים שחשופים למתקשרים חיצוניים.

  • אכיפה של מדיניות אבטחה לכניסה לאשכול. כשהאשכול צריך לקבל תנועה חיצונית, האדמין של רשת השירותים צריך לאכוף מדיניות אבטחה של תעבורת נתונים נכנסת (ingress), כולל TLS של שער, אימות ומדיניות הרשאה של Cloud Service Mesh, כדי לאמת בקשות חיצוניות ולוודא שיש הרשאה לבקשות חיצוניות לגשת לשירותים שנחשפים על ידי שער התעבורה הנכנסת. אכיפה של מדיניות אבטחה של תעבורת נתונים נכנסת (ingress) מגנה מפני מתקפות מחוץ לרשת שמנסות לגשת לשירות ללא הרשאות או פרטי כניסה תקפים.
  • אפשר להשתמש ב-Cloud Armor כחומת אש ליישומי אינטרנט (WAF) כדי להתגונן מפני מתקפות מבוססות-אינטרנט (לדוגמה, מתקפות החדרת קוד ומתקפות של הרצה מרחוק). מידע נוסף מופיע במאמר מ-edge ל-mesh: חשיפת אפליקציות של Service mesh באמצעות GKE Ingress.

הסדרת תעבורת נתונים יוצאת (egress) באשכול

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

בנוסף לשימוש בחומות אש של VPC כדי להגביל תעבורת נתונים יוצאת, האדמינים של ה-mesh צריכים גם לאכוף מדיניות אבטחה של תעבורת נתונים יוצאת עבור האשכול, ולהגדיר את תעבורת הנתונים היוצאת שלו כך שתעבור דרך שערים של תעבורת נתונים יוצאת.

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

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

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

שימוש באשכול פרטי או ב-VPC Service Control כדי לנעול גישה חיצונית

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

אפשר לאכוף את VPC Service Controls כדי להגדיר מתחם אבטחה לשירותים, וכך:

  • הגבלת הגישה של שירותים למשאבים חיצוניים.
  • הגבלת הגישה של גורמים חיצוניים לשירותים בגבולות גזרה לאבטחה.

‫VPC Service Controls עוזרים להגן מפני התקפות של זליגת נתונים ולמנוע מתוקפים חיצוניים לגשת לשירותים בתוך רשת.

הגנה מפני מתקפות DDoS חיצוניות

התקפות DDoS חיצוניות עלולות ליצור עומס יתר על שערים של תעבורת נתונים נכנסת ושירותי קצה עורפי, ולמנוע טיפול בבקשות לגיטימיות. אפשר להשתמש ב-Cloud Armor כדי להתגונן מפני מתקפות DDoS. ‫Cloud Armor מגן לא רק מפני מתקפות DDoS בשכבת הרשת (L3 ו-L4), אלא גם מפני מתקפות DDoS בשכבת האפליקציה (L7).

אבטחה לניהול ולאוטומציה של רשתות Mesh

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

פילוח התפקידים שמשמשים לפעולות ברשת

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

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

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

מדיניות RBAC של Kubernetes מאפשרת לאדמינים של רשתות שירותים להגביל את הגישה למשאבים רק למשתמשים מורשים.

אימות אוטומטי של הגדרות המדיניות

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

כדי להימנע ממצב שבו יש יותר מדי אמון באנשים שיש להם הרשאות לעדכן את מדיניות האבטחה של Cloud Service Mesh, וכדי להפוך את האימות של מדיניות Cloud Service Mesh לאוטומטי, מומלץ לאדמינים של הרשת להטמיע אילוצים במדיניות Cloud Service Mesh באמצעות Policy Controller.

‫Policy Controller מבוסס על פרויקט הקוד הפתוח Gatekeeper, ואפשר להפעיל אותו כבקר קבלה של Kubernetes כדי לדחות משאבים לא חוקיים, או במצב ביקורת כדי להודיע לאדמינים על הפרות. Policy Controller יכול לאמת באופן אוטומטי את הפריסה של משאבים ברשת, למשל לאמת שההערות בפריסה לא עוקפות את המדיניות של Cloud Service Mesh, לאמת שהמדיניות של Cloud Service Mesh היא כצפוי ולאמת שפריסה לא כוללת יכולות של Root (למשל, NET_ADMIN ו-NET_RAW).

Policy Controller יכול גם לבצע ביקורת על משאבים קיימים של Cloud Service Mesh בהתאם לאילוצים, כדי לזהות הגדרות שגויות של מדיניות.

הנה כמה דוגמאות לאכיפת מדיניות אבטחה על ידי Policy Controller ב-GKE Enterprise:

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

  • אכיפת mTLS מחמיר ברמת הרשת PeerAuthentication.
  • אי אפשר להשתמש באפשרות Enforce all PeerAuthentications כדי לשנות את ההגדרות של mTLS מחמיר.
  • אכיפה של דחייה כברירת מחדל ברמת הרשת AuthorizationPolicy.
  • אכיפה של דפוסי שימוש בטוחים ב-AuthorizationPolicy.
  • אכיפה של הזרקת sidecar של Cloud Service Mesh תמיד לעומסי עבודה.

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

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

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

אכיפה של רישום ביומן ביקורת ומעקב

האדמינים של רשת ה-Mesh צריכים לעקוב אחרי הדברים הבאים:

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

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

הגנה על רשות האישורים עבור אישורים בתוך האשכול

כברירת מחדל, Cloud Service Mesh משתמש ברשות אישורים (CA) שמנוהלת על ידי Google ונקראת Cloud Service Mesh certificate authority.

אם אתם משתמשים ברשות האישורים (CA) הלא מנוהלת של Istio, שמארחת כחלק מ-Istiod, מפתח החתימה של רשות האישורים מאוחסן בסוד של Kubernetes ונגיש למפעילים שיש להם גישה למשאב הסודי במרחב השמות istio-system. זהו סיכון, כי יכול להיות שאופרטור יוכל להשתמש במפתח של רשות האישורים באופן עצמאי מרשות האישורים של Istiod, ואולי גם לחתום על אישורים של עומסי עבודה באופן עצמאי. קיים גם סיכון שייחשף בטעות מפתח חתימה של רשות אישורים בניהול עצמי בגלל שגיאה תפעולית.

כדי להגן על מפתח החתימה של רשות האישורים, מנהל הרשת יכול לשדרג את הרשת לשימוש ברשות האישורים של Cloud Service Mesh או ב-Certificate Authority Service (CA Service), שמאובטחים ומנוהלים על ידי Google. בהשוואה לרשות האישורים של Cloud Service Mesh, שירות CA תומך במפתחות חתימה לכל לקוח דרך Cloud KMS שמגובה על ידי Cloud HSM. שירות CA תומך גם בעומסי עבודה בפיקוח, בעוד שרשות האישורים של Cloud Service Mesh לא תומכת בהם.

אבטחת עומסי עבודה

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

הגבלת ההרשאות של הפוד

יכול להיות של-Pod ב-Kubernetes יש הרשאות שמשפיעות על Pods אחרים בצומת או באשכול. חשוב לאכוף הגבלות אבטחה על פודים של עומסי עבודה כדי למנוע מפוד שנפרץ לשגר מתקפות נגד האשכול.

כדי לאכוף את העיקרון של הרשאות מינימליות עבור עומסי העבודה ב-Pod:

  • השירותים שנפרסים ברשת צריכים לפעול עם כמה שפחות הרשאות.
  • קבוצות Pod של Kubernetes שפועלות במצב מורשה יכולות לשנות את מחסניות הרשת ואת היכולות האחרות של ליבת המערכת במארח. אפשר להשתמש ב-GKE Enterprise Policy Controller כדי למנוע הפעלה של Pods עם קונטיינרים עם הרשאות.
  • אפשר להגדיר את Cloud Service Mesh כך שישתמש ב-init container כדי להגדיר הפניה אוטומטית של תעבורת iptables אל ה-sidecar. כדי לעשות את זה, למשתמש שמבצע פריסות של עומסי עבודה צריכות להיות הרשאות לפריסת קונטיינרים עם היכולות NET_ADMIN ו-NET_RAW. כדי להימנע מהסיכון להפעלת קונטיינרים עם הרשאות מורחבות, אדמינים של רשתות יכולים להפעיל במקום זאת את התוסף Istio CNI כדי להגדיר הפניה אוטומטית של תעבורה למכלי צד.

אבטחת קובצי אימג' של קונטיינרים

תוקפים עשויים ליזום התקפות על ידי ניצול תמונות קונטיינר פגיעות. האדמינים צריכים לאכוף Binary Authorization כדי לאמת את תקינות קובצי האימג' של הקונטיינרים ולוודא שרק קובצי אימג' מהימנים של קונטיינרים נפרסים ברשת.

צמצום פגיעויות ברשת

  • Container Analysis. Container Analysis יכול לסרוק ולחשוף נקודות חולשה בעומסי עבודה ב-GKE.
  • טיפול ב-CVE (נקודות חולשה וחשיפות נפוצות). אחרי שמתגלה נקודת חולשה בקובץ אימג' של קונטיינר, האדמינים של הרשת צריכים לתקן את נקודת החולשה בהקדם האפשרי. ב-managed Cloud Service Mesh עם managed data plane,‏ Google מטפלת באופן אוטומטי בתיקון של CVE שמשפיעים על תמונות הרשת.

שימוש באיחוד זהויות של עומסי עבודה ל-GKE כדי לגשת לשירותי Google בצורה מאובטחת

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

מעקב אחרי סטטוס האבטחה באמצעות מרכז הבקרה לאבטחה וטלמטריה

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

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

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

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

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

  • אם אפשר, כדאי לאחסן נתונים רגישים של משתמשים ופרטי כניסה באחסון מוגן, כמו Secret Manager ו-Cloud KMS.
  • הגדרת מרחבי שמות נפרדים לקבוצות Pod של Kubernetes שיש להן גישה לנתונים רגישים, והגדרת כללי מדיניות של Kubernetes כדי למנוע גישה אליהם ממרחבי שמות אחרים. פילוח התפקידים שמשמשים לפעולות והגדרת גבולות למרחבי שמות.
  • אכיפה של החלפת טוקנים כדי למנוע את החילוץ של טוקנים עם הרשאות גבוהות ותוקף ארוך.

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