אבטחת השירות

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

הערה: המדריך הזה תומך רק ב-Cloud Service Mesh עם ממשקי API של Google Cloud ולא תומך בממשקי Istio API. מידע נוסף זמין במאמר סקירה כללית על Cloud Service Mesh.

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

• אימות והצפנה באמצעות Transport Layer Security ‏ (TLS) ו-mutual TLS ‏ (mTLS) גם ב-Cloud Service Mesh עם Envoy וגם ב-Cloud Service Mesh עם אפליקציות gRPC ללא שרת Proxy. מדיניות TLS של לקוח ומדיניות TLS של שרת קובעות אם שירותים צריכים להוכיח את הזהות שלהם אחד לשני ולהשתמש בערוצי תקשורת מוצפנים.
• הרשאה, על סמך מאפיינים של הלקוח והבקשה. מדיניות הרשאות קובעת אם לשירות מסוים מותר לגשת לשירות אחר ואילו פעולות מותרות.

השימוש באישורים ובמפתחות שסופקו על ידי רשות אישורים פרטית (CA), Certificate Authority Service של Google, מקל על שמירת האבטחה של השירות. שירות CA מספק אישורים של GKE Mesh. התכונה GKE mesh certificates ו-Cloud Service Mesh מאפשרות לפרוס את האישורים האלה באופן אוטומטי ולגרום לעומסי עבודה להשתמש בהם. משנים את ה-Pods כדי לאפשר לעומסי העבודה לקבל ולהשתמש בפרטי כניסה של mTLS. האבטחה של שירות Cloud Service Mesh זמינה כרגע רק לעומסי עבודה מבוססי GKE.

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

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

במודל הזה, פרוקסי gRPC בלי שרת Proxy או Envoy sidecars מבצעים אימות והצפנה של תקשורת בצורה מאובטחת על ידי קבלת פרטי הגדרה מ-Cloud Service Mesh ואישורים ממאגר של CA Service.

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

• הקצאה אוטומטית של מפתחות ואישורים לכל השירותים ברשת.
• רוטציה אוטומטית של מפתחות ואישורים כדי לספק אבטחה נוספת.
• שילוב עם Google Kubernetes Engine‏ (GKE) כדי להשתמש בכל היכולות שלו, כמו תיאורי פריסה ותוויות.
• זמינות גבוהה של שירותים מנוהלים של Google, כולל Cloud Service Mesh ומאגרי רשויות אישורים פרטיות מנוהלות של CA Service.
• אבטחה שקשורה לניהול זהויות והרשאות גישה (IAM) של Google: הרשאת שירות שמבוססת על חשבונות שירות מורשים של Google.
• יכולת פעולה הדדית חלקה עם עומסי עבודה (workloads) מבוססי Envoy ובלי שרת Proxy. לדוגמה, שירות יכול להיות מאחורי שרת proxy של Envoy, אבל הלקוח משתמש באבטחת Service mesh ללא proxy של gRPC. לעומת זאת, שירות יכול להיות מאחורי אבטחת Service mesh ללא proxy של gRPC, אבל הלקוח משתמש ב-proxy של Envoy.

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

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

• לאשר ולאמת את הזהויות שלהם.
• הצפנה של סשנים של תקשורת באמצעות TLS או mTLS.

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

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

שימוש ב-TLS להצפנה

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

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

שימוש ב-TLS לאימות

כששירות אחד קורא לשירות אחר, כדאי לשקול את השאלות הבאות:

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

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

כדי לצמצם את הבעיות האלה, אפשר להשתמש ב-HTTP, ב-HTTP/2 וב-gRPC over TLS. בחילופי הנתונים האלה בין לקוח לשרת, השרת חייב להשתמש באישור שרת כדי להוכיח את הזהות שלו ללקוח. הבקשות והתגובות מוצפנות באמצעות TLS.

אימות TLS בו-זמני (mTLS)

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

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

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

אימות Mutual TLS (mTLS) ב-Service mesh (לחצו כדי להגדיל)

איך מאשרים שיחות שירות

אתם יכולים להשתמש במדיניות הרשאות כדי לאשר או לדחות גישה לשירותים. באמצעות Cloud Service Mesh, אפשר להגדיר כללי הרשאה ודחייה כדי לאשר גישה על סמך פרמטרים של בקשות. אפשר לבסס את הכללים האלה על פרמטרים של שכבה 3 ושכבה 7, כולל מזהה לקוח שנגזר מ-client-cert בחיבור mTLS, כתובת IP של המקור, התאמה של המארח, התאמה של השיטה והתאמה של הכותרת. בתרשים הבא מוצגת הרשאה באמצעות שרתי proxy של Envoy. התהליך דומה לזה של לקוחות gRPC.

הרשאה ב-service mesh באמצעות Envoy (לחצו כדי להגדיל)

הגבלת הגישה באמצעות הרשאה

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

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

• פעולה: אישור או דחייה
• רשימת כללים

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

• כשמשתמשים ב-mTLS, חשבון השירות של Kubernetes של שירות הקריאה
• כתובת ה-IP (או טווח הכתובות) של השירות שמבצע את השיחה
• היציאות של שירות היעד
• מאפייני ה-HTTP של הבקשה, כולל שמות מארחים, שיטות וכותרות HTTP שהוגדרו על ידי המשתמש.

זהירות: אם מגדירים כללי DENY בשילוב עם מאפייני בקשה כמו מארחים, יציאות והתאמות אחרות של כותרות, מומלץ מאוד שהכללים יחסמו את כל התנועה. יכול להיות שבקשות מסוימות יאושרו בטעות. לדוגמה, אם מגדירים כלל DENY שדוחה את כל התעבורה עם host: service-test, תוקף שיש לו גישה ישירה לשרת העורפי עשוי לשלוח בקשה עם service-test:80. מכיוון שהערך הזה לא תואם ל-service-test,

הבקשה מאושרת בטעות והבקאנד משרת את הבקשה.

מתן שמות מאובטח

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

אבטחת התנועה בשער

כדי להגדיר את השערים, אפשר להשתמש ב-Cloud Service Mesh. שער הוא שרת proxy עצמאי של Envoy, שבדרך כלל פועל כאחד מהבאים:

• שער כניסה שמטפל בתעבורת נתונים נכנסת (ingress) שנכנסת לרשת או לדומיין אחר
• שער יציאה שמטפל בתעבורת נתונים יוצאת שיוצאת מרשת או מדומיין אחר
• שרת proxy הפוך או שרת proxy באמצע שמפיץ תנועה נכנסת בין שירות אחד או יותר

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

רכיבי אבטחה

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

הצפנה ומצבי אימות נתמכים

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

אפשר להגדיר את רמות האבטחה הבאות:

• לא מוצפן/לא מאומת
• TLS
• TLS דו-צדדי (mTLS)
• מתירני: mTLS או לא מוצפן/לא מאומת, בהתאם לאופן שבו הלקוח יוזם את החיבור

אישורים ורשויות אישורים

אישורים ורשות אישורים (CA) מהימנה מספקים את הבסיס לאמון במערכת מבוזרת, כמו Service mesh. באמצעות אישורים, שירותים יכולים להוכיח את הזהויות שלהם ולאמת את הזהויות שמוצגות להם בדרכים הבאות:

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

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

• הקצאת זהויות ואישורים
• הופך את האישורים לזמינים ללקוחות Cloud Service Mesh, כמו שרתי proxy של Envoy, שמוגדרים על ידי Cloud Service Mesh

‫Cloud Service Mesh תומך בשירות CA של Google. מדריכי ההגדרה של Envoy ו-gRPC בלי שרת Proxy כוללים הוראות להגדרה (פרטים נוספים מופיעים בקטע השלבים הבאים).

ארכיטקטורה ומשאבים

‫Cloud Service Mesh כולל את מרחב השמות של Network Security API, שמורכב משלושה משאבי API Google Cloud שמאפשרים לכם לציין את מדיניות האבטחה שצריך להחיל על מישור הנתונים.

שני משאבי API תומכים באימות ברשת: Google Cloud מדיניות TLS של לקוחות ומדיניות TLS של שרתים. משאב שלישי, מדיניות ההרשאות, תומך בהרשאות.

מרחב השמות של Network Services API כולל את משאב מדיניות נקודת הקצה, שמאפשר ל-Cloud Service Mesh לספק הגדרות (TLS של שרת, TLS של לקוח ומדיניות הרשאות) לנקודות קצה. נקודות קצה הן לקוחות Cloud Service Mesh שמסיימים תקשורת נכנסת מלקוח אחר של Cloud Service Mesh.

מדיניות TLS של לקוח

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

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

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

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

מדיניות TLS של השרת

מדיניות TLS של שרת (ServerTlsPolicy resource) מאפשרת לכם לציין את מצב ה-TLS בצד השרת ואת פרטי ספק האישורים שיחולו על מישור הנתונים. מדיניות TLS של שרתים תומכת ב-TLS, ב-mTLS ובאימות Open_or_mTLS (רק ב-Envoy). מצרפים מדיניות TLS של שרת למשאב מדיניות של נקודת קצה.

שמות חלופיים לנושא

כשמגדירים את השדה securitySettings של שירות קצה עורפי גלובלי, אפשר לספק רשימה של שמות חלופיים לנושא בשדה subjectAltNames. כשלקוח מפעיל לחיצת יד ב-TLS עם אחד מהעורפים של השירות, השרת מציג את אישור X.509 שלו. הלקוח בודק את השדה subjectAltName של האישור. אם השדה מכיל אחד מהערכים שצוינו, התקשורת נמשכת. המנגנון הזה מתואר בחלק הקודם של המאמר בנושא מתן שמות מאובטח.

מדיניות הרשאות

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

כלל במדיניות הרשאות כולל את הרכיבים הבאים:

• ‫from: מציין את הזהות של הלקוח שמורשה על ידי הכלל. אפשר לקבל את הזהות מאישור לקוח בחיבור TLS בו-זמני (mTLS), או שהיא יכולה להיות הזהות הסביבתית שמשויכת למכונה הווירטואלית של הלקוח, למשל מחשבון שירות או מתג מאובטח.
• ‫to: מציין את הפעולות שמותרות לפי הכלל, כמו כתובות ה-URL שאפשר לגשת אליהן או שיטות ה-HTTP שמותרות.
• ‫when: מאפשרת להגדיר אילוצים נוספים שצריך לעמוד בהם. אפשר להשתמש בביטויים של Common Expression Language ‏(CEL) כדי להגדיר את האילוצים.
• ‫action: מציין את הפעולה של הכלל. אפשר להשתמש באחד מהערכים הבאים: ALLOW, DENY או CUSTOM.

חשוב: עדיין אין תמיכה במדיניות ב-Cloud Service Mesh‏ (CSM)CUSTOM.

מגבלות

אבטחת שירותים ב-Cloud Service Mesh נתמכת רק ב-GKE. אי אפשר לפרוס אבטחת שירות באמצעות Compute Engine.

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

• ‫ALLOW: מעניקה גישה למשאב המבוקש אם הבקשה תואמת לכללים שמוגדרים במדיניות ההרשאות. מדיניות ההרשאות חוסמת את הגישה למשאב המבוקש אם הבקשה לא תואמת לאף אחד מהכללים שמוגדרים במדיניות ההרשאות. בקשה נדחית אם היא לא תואמת למדיניות ALLOW, גם אם מדיניות אחרת מאפשרת אותה.

• ‫DENY: חסימת הגישה למשאב אם בקשה תואמת לאחד מהכללים שצוינו במדיניות DENY. מדיניות ההרשאות מעניקה גישה למשאב המבוקש אם הבקשה לא תואמת לאף אחד מהכללים המוגדרים במדיניות ההרשאות. בקשה נדחית אם היא תואמת למדיניות DENY, גם אם מדיניות אחרת מאפשרת אותה.

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

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

סדר ההערכה של מדיניות ההרשאות

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

1. מדיניות עם פעולות CUSTOM: אם המדיניות CUSTOM דוחה את הבקשה, הבקשה נדחית באופן מיידי. המערכת לא מעריכה את המדיניות DENY או ALLOW, גם אם הן מוגדרות.

2. כללי מדיניות עם פעולות DENY: אם בקשה תואמת לכללי מדיניות DENY, הבקשה תידחה. מדיניות ALLOW לא מוערכת, גם אם היא מוגדרת.

3. מדיניות עם פעולות ALLOW: אם אין מדיניות ALLOW או אם בקשה תואמת למדיניות ALLOW כלשהי, הבקשה תאושר. עם זאת, אם אין מדיניות ALLOW שתואמת לבקשה, הבקשה נדחית.

מגבלות באפליקציות gRPC בלי שרת Proxy

יש מגבלות על אבטחת שירותים בשירותי gRPC בלי שרת Proxy:

• הגרסה הזו מוגבלת לשפות Java,‏ Python,‏ C++‎ ו-Go.

מכסות של AuthzPolicy

• אפשר להגדיר עד 5 מדיניות הרשאות לכל שער.
• אפשר להגדיר עד 20 משאבי AuthzPolicy לכל פרויקט.
• כל AuthzPolicy יכול להפנות לעד 100 שערים.

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

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