שיטות מומלצות לאבטחה של ממשקי API של Cloud Service Mesh עם Istio

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

סיכוני אבטחה

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

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

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

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

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

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

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

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

  • אבטחת קצה של רשת Mesh
    • אבטחת הכניסה ב-Cloud Service Mesh מספקת בקרת גישה לתנועה חיצונית ומאבטחת גישה חיצונית לממשקי ה-API שנחשפים על ידי השירותים ברשת.
    • אבטחת תעבורת נתונים יוצאת (egress) ב-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 לאבטחה מאפשר מעקב אחרי ההגדרות של מדיניות האבטחה ושל NetworkPolicies של Kubernetes עבור עומסי העבודה.
    • בקרת גישה לקבוצות Pod שמבוססת על מדיניות רשת Kubernetes, על כתובות IP, על תוויות של קבוצות Pod, על מרחבי שמות ועוד.
  • אבטחת עומסי עבודה
    • כדי לוודא שקובצי ה-binary של 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 Web Token‏ (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 על שערים של תנועה נכנסת לתנועה חיצונית, או על שירותים פנימיים לתנועה בתוך הרשת. אפשר לשלב אימות 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, כדי שהשירות יאמת ויאשר את הבקשה. יכול להיות שטוקן שמגיע מחוץ לרשת יהיה תקף לזמן ארוך. כדי להתגונן מפני התקפות חוזרות של אסימונים, מחליפים אסימון מחוץ לרשת באסימון פנימי של הרשת לטווח קצר עם היקף מוגבל בכניסה לרשת. שירות הרשת מאמת אסימון פנימי של הרשת ומאשר את בקשת הגישה על סמך האסימון הפנימי של הרשת.

‫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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

צמצום נקודות החולשה ברשת

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

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

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

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

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

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

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

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

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

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