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

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

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

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

הטבות אבטחה

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

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

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

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

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

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

תכונות

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

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

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

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

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

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

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

Certificate Authority Service

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

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

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

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

תאימות ל-FIPS

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

מגבלות

יש מגבלה אחת באבטחה של Cloud Service Mesh:

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

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