שיטות מומלצות לאבטחה של ממשקי Istio API ב-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 מסוימות מהשתתפות ברשת. חשוב להגדיר אמצעי בקרה שינהלו את תצורות הרשת ואת חריגי האבטחה.

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

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

וקטורי תקיפה

האבטחה של 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 משולב בתשתית של Google כדי לאמת קריאות חיצוניות מדפדפני אינטרנט לשירותים שמריצים אפליקציות אינטרנט.
    • ניהול אישורי שערים ב-Cloud Service Mesh מגן על המפתחות הפרטיים ועל אישורי X.509 שבהם נעשה שימוש בשערי כניסה ויציאה של Cloud Service Mesh, ומבצע רוטציה שלהם באמצעות Certificate Authority Service.
    • ‫VPC ו-VPC Service Controls מגנים על קצה הרשת באמצעות אמצעי בקרה לגישה לרשת פרטית.
  • אבטחת אשכולות
    • הצפנה ואימות של תעבורה בין עומסי עבודה באמצעות TLS בו-זמני (mTLS) ב-Cloud Service Mesh.
    • רשות האישורים של Cloud Service Mesh מספקת ומנהלת בצורה מאובטחת אישורים שמשמשים את עומסי העבודה.
    • ההרשאה ב-Cloud Service Mesh אוכפת בקרת גישה לשירותי רשת על סמך הזהויות שלהם ומאפיינים אחרים.
    • לוח הבקרה של GKE Enterprise בנושא אבטחה מאפשר מעקב אחרי ההגדרות של מדיניות האבטחה ושל Kubernetes NetworkPolicies עבור עומסי העבודה.
    • בקרת גישה לקבוצות Pod שמבוססת על כתובות IP, תוויות של קבוצות Pod, מרחבי שמות ועוד, ואכיפה של כללי מדיניות של רשת Kubernetes.
  • אבטחת עומסי עבודה
    • כדי לוודא שקבצים בינאריים של 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 מוודא שתמונות עומס העבודה ברשת הן אלה שהאדמינים אישרו.
    • יומני הביקורת של 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 (כמו מדיניות אימות והרשאה) על כל התעבורה שנכנסת ל-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

כשחושבים על מדיניות אימות ב-Cloud Service Mesh, כדאי להתייחס לנקודות הבאות.

אסימון JWT‏ (JSON Web Token)

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

‫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 משפיעה באופן שלילי על האבטחה הכוללת של המערכת. לדוגמה, אם נעקפים ב-Cloud Service Mesh אמצעי אבטחה כמו mTLS ומדיניות הרשאות עבור יציאת רשת באמצעות הערות, לא תהיה בקרה על הגישה לתעבורה ביציאה, וייתכן שיהיה אפשר לבצע האזנה או שינוי של התעבורה. בנוסף, עקיפה של כללי מדיניות של Cloud Service Mesh משפיעה גם על כללי מדיניות שאינם קשורים לאבטחה, כמו כללי מדיניות רשת.

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

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

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

סחף הגדרות מתרחש כשההגדרה של מדיניות ברשת סוטה ממקור האמת שלה. אתם יכולים להשתמש ב-Config Sync כדי למנוע סטיות בהגדרות.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ‫Artifact Analysis יכול לסרוק ולחשוף נקודות חולשה בעומסי עבודה ב-GKE.
  • טיפול בנקודות חולשה נפוצות (CVE). אחרי שמתגלה נקודת חולשה בקובץ אימג' של קונטיינר, האדמינים של הרשת יכולים לתקן את נקודת החולשה בהקדם האפשרי. ‫Google מטפלת באופן אוטומטי בתיקון של פגיעויות נפוצות (CVE) שמשפיעות על תמונות הרשת.

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

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

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

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

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

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

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

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

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