סקירה כללית על אבטחה ב-Cloud Service Mesh

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

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

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

mutual TLS

ב-Cloud Service Mesh נעשה שימוש ב-TLS בו-זמני (mTLS) לאימות עמיתים. אימות מתייחס לזהות: מי השירות הזה? מי משתמש הקצה הזה? והאם אפשר לסמוך על כך שהם מי שהם אומרים שהם?

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

‫mTLS הוא האמצע שבו Cloud Service Mesh מטמיע אימות והצפנה בין שירותים.

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

מידע נוסף על אכיפה של mTLS בלבד זמין במאמר Cloud Service Mesh by example: mTLS.

הגדרת סט אלגוריתמים להצפנה

הרשימה הבאה כוללת את חבילות ההצפנה שמוגדרות כברירת מחדל ב-Cloud Service Mesh ועומדות בדרישות של FIPS:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

כדי לשפר את האבטחה, גרסת ה-TLS המינימלית בצד השרת שנתמכת בעומסי עבודה של Cloud Service Mesh היא 1.2, שמאפשרת התאמה אישית של סטים של אלגוריתמים להצפנה (cipher suite). שימו לב ש-Cloud Service Mesh תומך גם ב-TLS v1.3, שבו חבילות ההצפנה מוצפנות בקידוד קשיח ואי אפשר לשנות אותן.

מידע נוסף על חבילות הצפנה זמין במאמרים בנושא הגדרת TLS נפוצה ב-Envoy ואימות TLS הדדי ב-Istio.

הטבות אבטחה

‫Cloud Service Mesh מספק את יתרונות האבטחה הבאים:

  • מפחית את הסיכון למתקפות שידור חוזר או התחזות שנעשה בהן שימוש בפרטי כניסה גנובים. Cloud Service Mesh מסתמך על אישורי mTLS לאימות עמיתים, ולא על אסימוני הרשאה כמו אסימוני JWT‏ (JSON Web Tokens). מכיוון שאישורי mTLS קשורים לערוץ TLS, אי אפשר לישות בסביבת הייצור להתחזות לישות אחרת על ידי הפעלה חוזרת של אסימון האימות בלי גישה למפתחות הפרטיים.

  • הצפנה בזמן ההעברה שימוש ב-mTLS לאימות גם מבטיח שכל התקשורת ב-TCP מוצפנת במעבר.

  • מוודא שרק לקוחות מורשים יכולים לגשת לשירות עם מידע אישי רגיש. רק לקוחות מורשים יכולים לגשת לשירות עם מידע אישי רגיש, ללא קשר למיקום ברשת של הלקוח ולאישורים ברמת האפליקציה. אתם יכולים לציין שרק לקוחות עם זהויות שירות מורשות או במרחבי שמות מורשים של Kubernetes יכולים לגשת לשירות. אפשר גם להשתמש במדיניות גישה מבוססת-IP כדי להעניק גישה ללקוחות שנפרסו מחוץ לסביבת GKE Enterprise.

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

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

תכונות

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

רוטציה אוטומטית של אישורים ורוטציית מפתחות

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

רשות אישורים של Cloud Service Mesh

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

האישורים מרשות האישורים של Cloud Service Mesh כוללים את הנתונים הבאים על השירותים של האפליקציה:

  • Google Cloud מזהה הפרויקט
  • מרחב השמות של GKE
  • השם של חשבון השירות ב-GKE

Certificate Authority Service

במקום להשתמש ברשות האישורים של Cloud Service Mesh, אפשר להגדיר את Cloud Service Mesh כך שישתמש ב-Certificate Authority Service. האפשרות הזו מתאימה לתרחישי השימוש הבאים:

  • אם אתם צריכים רשויות אישורים שונות כדי לחתום על אישורים של עומסי עבודה באשכולות שונים.
  • אם רוצים להשתמש באישורים של פלאגין CA מותאם אישית של Istiod.
  • אם אתם צריכים לגבות את מפתחות החתימה ב-HSM מנוהל.
  • אם אתם פועלים בתחום עם רגולציה מחמירה וכפופים לדרישות תאימות.
  • אם רוצים לשרשר את רשות האישורים של Cloud Service Mesh לאישור בסיס מותאם אישית של הארגון כדי לחתום על אישורים של עומסי עבודה.

העלות של רשות האישורים של Cloud Service Mesh כלולה בתמחור של Cloud Service Mesh. שירות ה-CA לא נכלל במחיר הבסיסי של Cloud Service Mesh, והוא מחויב בנפרד. בנוסף, שירות CA מגיע עם SLA מפורש, אבל רשות האישורים של Cloud Service Mesh לא מגיעה עם SLA.

במסגרת השילוב הזה, כל עומסי העבודה ב-Cloud Service Mesh מקבלים שני תפקידי IAM:

כללי מדיניות של בקרת גישה (חומת אש) שמודעת לזהויות

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

בקשה של כללי מדיניות (חומת אש) לבקרת גישה שמודעת לטענות

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

אימות משתמשים באמצעות שרת proxy לאימות זהויות (IAP)

כדי לאמת משתמשים שניגשים לשירות כלשהו שמוצג בשער הכניסה של Cloud Service Mesh, משתמשים בשרת proxy לאימות זהויות (IAP). שירות IAP יכול לאמת משתמשים שנכנסים לחשבון מדפדפן, להשתלב עם ספקי זהויות בהתאמה אישית ולהנפיק אסימון JWT לטווח קצר או אסימון RCToken שאפשר להשתמש בהם כדי להעניק גישה ב-Ingress gateway או בשירות downstream (באמצעות side-car). מידע נוסף זמין במאמר בנושא שילוב של IAP עם Cloud Service Mesh.

אימות משתמשים באמצעות ספק הזהויות הקיים

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

רישום ביומן ומעקב אחר גישה

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

תאימות ל-FIPS

כל רכיבי מישור הבקרה ושרתי ה-proxy בתוך האשכול בארכיטקטורת x86 משתמשים במודולי הצפנה מאומתים לפי FIPS 140-2.

מגבלות

בשלב הזה, האבטחה של Cloud Service Mesh מוגבלת באופן הבא:

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

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