שיטות מומלצות לאבטחה ב-VMware Engine

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

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

VMware Engine Networking

בקטעים הבאים מפורטות שיטות מומלצות לניהול רשת בסביבת VMware Engine.

זיהוי והבנה של כל זרימות התנועה בסביבה שלכם

‫VMware Engine משתמש ברשתות VMware Engine ובקישור בין רשתות VPC שכנות כדי ליצור חיבור רשת פרטי מרשת ענן פרטי של VMware Engine לרשת ה-VPC שלכם. תעבורת נתונים נכנסת מרשת VPC בסביבתGoogle Cloud או מרשת מקומית עוברת ברשת של יחידת דיירות שמנוהלת על ידי Google.

שימוש בשירות כתובות ה-IP הציבוריות של VMware Engine להעברת נתונים באינטרנט

תעבורת נתונים באינטרנט יכולה להיכנס ישירות לענן פרטי באמצעות שירות כתובות ה-IP הציבוריות של VMware Engine. לחלופין, תעבורת נתונים באינטרנט יכולה להיכנס באמצעות מאזן עומסים ציבורי ב- Google Cloud. במקרה כזה, התנועה מנותבת כמו כל תנועה נכנסת אחרת. שימו לב שהאפשרויות האלה הן בלעדיות. אם נדרשים אמצעי בקרה מותאמים אישית לתעבורת נתונים באינטרנט, כמו סינון כתובות URL, ‏ IPS/IDS או בדיקת תעבורה שמתבצעת על ידי מופע או שירות מרכזיים בסביבה שלכם Google Cloud , כדאי לנתב את התעבורה שמיועדת לאינטרנט דרך רשת VPC.

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

הפרדה בין כללי חומת אש מצפון לדרום וממזרח למערב בשער ובחומת אש מבוזרת ב-VMware Engine NSX

מגדירים את חומת האש המבוזרת (DFW) ב-NSX בנתב הלוגי ברמה 1 כדי לפלח את התנועה הפנימית בין הדומיינים הווירטואליים ברמה 2. ה-NSX DFW מיועד לטפל בתעבורה ברשת (פנימית) ממזרח למערב בין פלחים, ומאפשר כללי חומת אש שמאפשרים ומסרבים לתעבורה בין מופעים בודדים בתוך פלח.

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

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

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

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

צריך לחסום העברת נתונים יוצאים למכשירי ניהול וגם לטווח ה-CIDR של vSphere/vSAN מ-VPC באמצעות חומת האש של ה-VPC. צריך לאפשר העברת נתונים יוצאים רק ממארחים וכתובות IP מהימנים בתוך הרשת שלכם אל מכשירי ניהול. חשוב לציין שמכשירי ניהול לא נמצאים בקטע NSX, ולכן כללי DFW לא חלים כדי להגביל את הגישה.

יישום של עקרונות האבטחה של אפס אמון ומיקרו-פילוח ב-NSX

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

ה-DFW מופעל בקרנל של ההיפר-ויז'ר בכל המארחים של VMware Engine vSphere בענן הפרטי, ויכול לשלוט בזרימת התנועה בין עומסי עבודה שנמצאים באותו פלח NSX או בפלחים נפרדים. אפשר להגדיר כללי חומת אש כדי לאפשר תעבורה מהמכונות הווירטואליות ואליהן על ידי ארגון המכונות הווירטואליות בקבוצות מדיניות, שיכולות לכלול קריטריונים גמישים לחברות, כמו תג או שם של מכונה וירטואלית שתואמים לכלל.

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

פריסת מכשיר חומת אש של צד שלישי מפורטל Cloud Marketplace ליכולות IPS/IDS

אם אתם צריכים אבטחה מתקדמת בשכבה 7, כולל יכולות IDS/IPS לתנועה נכנסת לענן הפרטי משאר הרשת או בין פלחי הרשת של NSX, כדאי לשקול פריסה של חומת אש של צד שלישי. אפשר לפרוס את מכשיר הצד השלישי כמכשיר עם כמה כרטיסי רשת (NIC) בין שני VPC ברשת Google Cloud או בענן הפרטי עם שילוב עם NSX.

לעיון מעמיק בארכיטקטורות של VMware Engine עם מכשירים מרכזיים, שאפשר להשתמש בהם למגוון תרחישי שימוש מתקדמים באבטחה, כמו IPS/IDS, ‏ DDoS, ‏ SSL offloading ועוד, אפשר לעיין במסמך בנושא אבטחת רשת באמצעות מכשירים מרכזיים ב-Cloud Architecture Center.

שימוש ב-Google Cloud Armor כדי להגן על שירותי אינטרנט ב-VMware Engine מפני מתקפות DDoS

אם אתם מעבירים תנועה נכנסת לעומסי עבודה ב-VMware Engine דרך ה-VPC של הלקוח, מומלץ למקם את עומסי העבודה ב-VMware Engine בקבוצות היברידיות של נקודות קצה ברשת מאחורי Cloud Service Mesh ולהשתמש במאזן העומסים החיצוני של HTTP(S). שתי ההגדרות מאפשרות לכם לכלול את Google Cloud Armor באפליקציות שפונות לציבור, וכך לצמצם את הסיכון למתקפות DDoS ולנקודות חולשה נפוצות כמו הזרקות SQL או פרצות אבטחה XSS‏ (cross-site scripting).

אם אתם צריכים תכונות של Cloud Service Mesh כמו ניהול מתקדם של תעבורת נתונים באמצעות Envoy proxy או שילוב של Certificate Authority Service, מומלץ להשתמש ב-Cloud Service Mesh. בכל המקרים האחרים, מומלץ להשתמש במאזן עומסים חיצוני מסוג HTTP(S).

פועלים לפי התיעוד כדי להוסיף עומסי עבודה של VMware Engine ל-NEGs היברידיות באחת מההגדרות הבאות:

• איזון עומסים חיצוני אזורי מסוג HTTP(S) עם קישוריות היברידית
• מאזן עומסים חיצוני גלובלי מסוג HTTP(S) עם קישוריות היברידית

התחברות לשירותי Google Cloud באופן פרטי ללא גישה לאינטרנט

עומסי עבודה בענן פרטי של VMware Engine יכולים לגשת ל-APIs כמו Cloud Storage API באמצעות גישה פרטית ל-Google. Google Cloudמומלץ להשתמש בגישה פרטית ל-Google כדי לגשת לשירותי Google בלי לשלוח תנועה באינטרנט, כי כך מצמצמים את עלות העברת הנתונים היוצאים ואת זמן האחזור. בנוסף, אין צורך בנתיב רשת לאינטרנט לעומסי עבודה שנדרשת להם רק גישה ל-Google API. לפרטים טכניים נוספים ולהוראות הגדרה, אפשר לעיין במאמר בנושא גישה פרטית ל-Google.

באופן דומה, עומסי עבודה ב-VMware Engine שצריכים לגשת לGoogle Cloud משאבים מרשת של בעלים של שירות מנוהל, כמו מכונות Cloud SQL או Memorystore, צריכים להתחבר באופן פרטי באמצעות PSA. מידע נוסף זמין בקטע בנושא PSA ל-VMware Engine.

הצפנת התקשורת בין הסביבה המקומית לבין Google Cloud

עומסי עבודה ב-VMware Engine שצריכים לתקשר עם מערכות מקומיות צריכים להתחבר דרך ערוץ מוצפן. אנחנו ממליצים על גישה רב-שכבתית להצפנה בזמן העברת הנתונים בין מרכזי הנתונים המקומיים לביןGoogle Cloud. הקישור בין מערכות מקומיות לבין Google Cloud יכול להיות מוצפן על ידי הגדרת Cloud VPN עם מנהרת IPsec, או על ידי שימוש ב-IPsec המובנה בצירופי VLAN של Interconnect. בנוסף, צריך להפעיל הצפנה בשכבת האפליקציה בין רכיבי האפליקציה באמצעות TLS.

איך משתמשים ב-VPC Service Controls כדי להגן על הנתונים מפני זליגת מידע

מומלץ לצמצם את הסיכונים לזליגת נתונים באמצעות VPC Service Controls, על ידי הצבת משאבים רגישים כמו קטגוריות של Cloud Storage ומערכי נתונים של BigQuery בתוך גבולות גזרה של VPC Service Controls. עומסי עבודה שצריכים לגשת לנתונים בתוך היקף האבטחה צריכים להיות ממוקמים גם הם בתוך היקף האבטחה. במילים אחרות, Google Cloud הפרויקט שמארח את הענן הפרטי צריך להיות חלק מגבולות הגזרה של VPC Service Controls כדי לגשת למשאבים שמוגנים על ידי VPC Service Controls.

כדי לאפשר לממשקי ה-API של שירות הבעלים של VMware Engine להיכנס למתחם, צריך להגדיר מדיניות העברת נתונים נכנסת ויוצאת בהגדרות של VPC Service Controls. הוראות מפורטות להגדרה זמינות בדפי התיעוד בנושא VPC Service Controls עם VMware Engine.

הרשאות ו-IAM ב-VMware Engine

בקטעים הבאים מפורטות שיטות מומלצות להרשאות משתמשים בסביבת VMware Engine. חשוב לנהל את ההרשאות בסביבת VMware Engine ובפרויקט Google Cloud שבו הענן הפרטי נפרס.

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

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

פלטפורמה	רכיב	מקור זהויות	איפה מגדירים הרשאות	דוגמאות לפעילויות
Google Cloud	פורטל VMware Engine	Cloud Identity	ניהול זהויות והרשאות גישה	פריסה וביטול של ענן פרטי, פריסה וביטול של אשכול, למשל.
VMware Engine	vCenter	LDAP	מארחים ואשכולות, מכונות וירטואליות ותיקיות, מאגרי נתונים בממשק המשתמש של vCenter	יצירת מכונה וירטואלית, יצירת תיקייה של מכונה וירטואלית, יצירה ומחיקה של אובייקט במאגר נתונים, לדוגמה
	NSX	LDAP	'משתמשים ותפקידים' בממשק המשתמש של NSX Manager	למשל, יצירת פלח NSX, הגדרת חומת אש והגדרת מאזן עומסים.
vCenter	מערכת הפעלה של מכונה וירטואלית (VM) אורחת	לדוגמה, Active Directory, ‏ LDAP, משתמשים מקומיים	מערכת הפעלה של אורח	התחברות באמצעות SSH או RDP, פעולות על קבצים, לדוגמה

ב-IAM, יש שני תפקידים מוגדרים מראש עם הרשאות לפורטל VMware Engine: Google Cloud

• ‫VMware Engine Service Admin – מעניק גישה מלאה לשירות VMware Engine ב- Google Cloud.
• VMware Engine Service Viewer – הרשאת קריאה בלבד לשירות VMware Engine ב- Google Cloud.

ההרשאות האלה קשורות לפעולות בפורטל VMware Engine ולא לפעולות ב-API או ב-CLI. שימו לב שהתפקידים הבסיסיים כוללים גם את היכולת לנהל את שירות VMware Engine (בעלים, עריכה) או לצפות בפרטי השירות (צפייה). באופן כללי, מומלץ להשתמש בתפקידים מוגדרים מראש במקום בתפקידים בסיסיים, כי הם מספקים הרשאות פרטניות יותר.

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

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

לא נדרשות הרשאות Cloud IAM לפעילויות שצריך לבצע רק בתוך vCenter, ‏ NSX או HCX. עובדים שצריכים רק להפעיל את הסביבות האלה לא צריכים את תפקידי ה-IAM שצוינו קודם. במקום זאת, הם צריכים להשתמש בזהויות LDAP עם הרשאות שהוגדרו ב-vCenter וב-NSX. מומלץ להקצות את התפקידים VMware Engine Service Admin או VMware Engine Service Viewer למספר מצומצם מאוד של משתמשים, כי התפקידים האלה מעניקים גישה לחשבון המשתמש CloudOwner ב-vCenter ולחשבון המשתמש administrator ב-NSX. צריך להשתמש בחשבונות המשתמש האלה רק להגדרה ראשונית או לנוהלי חירום.

הגבלת הגישה של האדמינים וביצוע ביקורת פעילה

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

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

הגדרת מקור זהויות LDAP או Active Directory

צריך להגדיר ספק זהויות שתומך באימות LDAP, כמו Active Directory, כדי להפעיל אימות משתמשים עבור vCenter ו-NSX Manager. זו שיטה מומלצת לניהול מרכזי של מחזור החיים של הזהויות, ניהול קבוצות, ניהול סיסמאות ועוד. שימו לב: אין תמיכה בהצטרפות ישירה של vCenter ו-NSX ל-Active Directory לצורך אימות משולב של Windows.

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

‫VMware Engine יוצר פרטי כניסה לגישה למכשירי ניהול בענן הפרטי (כמו vCenter, ‏ NSX ו-HCX). מומלץ ליצור תהליך לרוטציה של הסיסמאות של חשבון השירות [e-mail] שמוגדר כברירת מחדל ב-vCenter ושל האדמין של חשבון השירות שמוגדר כברירת מחדל ב-NSX. צריך להשתמש בשני חשבונות המשתמשים רק לצורך ההגדרה הראשונית ולנהלי חירום, ולשנות את הסיסמאות שלהם באופן קבוע (למשל, כל 60 או 90 ימים). באופן דומה, כדאי להחליף באופן קבוע את הסיסמאות של חשבונות משתמשים בפתרון, שמשמשים בדרך כלל לשילוב של כלים של צד שלישי. ככל שתבצעו רוטציה של הסיסמאות של חשבונות השירות בתדירות גבוהה יותר, כך הסיכוי שהסיסמה עדיין תהיה תקפה כשגורם זדוני ימצא אותה יהיה נמוך יותר.

רישום ביומן ומעקב ב-VMware Engine

בקטעים הבאים מפורטות שיטות מומלצות לרישום ביומן ולמעקב אחרי עומסי עבודה (workloads) של מכונות וירטואליות ואחרי התשתית של VMware Engine, שמספקת את המשאבים שעומסי העבודה צורכים.

הוספת יומנים ומדדים של VMware Engine

ארגונים רבים רוצים לאסוף ולנתח יומנים באופן מרכזי ב'חלון יחיד'. ב- Google Cloud, המוצרים Cloud Logging ו-Cloud Monitoring מספקים שירותים שאפשר להשתמש בהם לניהול מרכזי של יומנים ומדדים. אפשר לשלב את VMware Engine עם Cloud Monitoring באמצעות סוכן עצמאי. בהגדרה הזו, vCenter מעביר מדדים כמו ניצול המעבד (CPU) והזיכרון של ESXi אל Cloud Monitoring. מומלץ ליצור לוחות בקרה על סמך מדדים שמועברים על ידי vCenter, או להתחיל עם כמה לוחות בקרה לדוגמה שפורסמו ב-GitHub.

כדי לאסוף יומנים של פלטפורמות, עננים פרטיים של VMware Engine יכולים להעביר יומני Syslog למצבור יומנים מרכזי. אפשר לעשות את זה גם עבור הודעות Syslog של vCenter וגם עבור הודעות Syslog של NSX. יש תרחישי שימוש חשובים לאבטחה שקשורים לאיסוף, לשמירה ולניתוח של הודעות Syslog מ-vCenter, כמו התראות בזמן אמת שמבוססות על התחברויות של משתמשים עם הרשאות אדמין (או משתמשי חירום), שצריכות להתבצע רק בנסיבות חריגות. כדי לנתח הודעות Syslog, צריך להגדיר צובר Syslog, כמו Fluentd או הסוכן העצמאי, כדי להעביר את ההודעות ל-Cloud Logging.

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

שימוש בסוכן Cloud Logging לרישום ביומן של מכונות וירטואליות של עומסי עבודה

מכונות וירטואליות של עומסי עבודה ב-VMware Engine יכולות לשלוח יומנים ישירות אל Cloud Logging API באמצעות סוכן Logging. סוכן Logging מבוסס על fluentd ומעביר יומנים באופן שוטף מאפליקציות נפוצות של צד שלישי ומתוכנות מערכת אל Cloud Logging. מומלץ להשתמש באותה גישה לאיסוף ולניתוח של יומנים עבור מכונות וירטואליות של עומסי עבודה ב-VMware Engine, עבור מכונות של Compute Engine ועבור נכסים מקומיים (אם רלוונטי). השימוש בסוכן Logging ב-VMware Engine זהה לגישה שבה משתמשים במכונות וירטואליות ב-Compute Engine, כך שעומסי עבודה בשתי הפלטפורמות שולחים את היומנים שלהם ל-Cloud Logging.

החלת יכולות שוות ערך של מדיניות Access Transparency ו-Access Approval

‫VMware Engine לא תומך בשקיפות גישה (AxT) ובאישור גישה (AxA) ב- Google Cloud, אבל הטמענו תהליכים עם יכולות שוות ערך שאפשר להפעיל לפי בקשה.

כדי להשיג שוויון בשקיפות הגישה, צריך לקחת בחשבון כמה מקורות של יומנים, כולל:

• יומנים של vCenter – אפשר לייצא אותם באמצעות הגדרת שרת syslog מרוחק.
• יומני ESXi – אפשר לאסוף אותם באמצעות הגדרת syslog מרחוק, אבל צריך לשלוח בקשת תמיכה אל Google Cloud כדי להגדיר העברה של syslog ב-ESXi.

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

Google Cloud החרגות של אישורי גישה חלות.

הצפנה ב-VMware Engine

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

שימוש בספק Google-owned and managed key שמופעל להצפנה במנוחה ב-vSAN

ההצפנה של נתונים במצב מנוחה מיושמת באמצעות הצפנה מבוססת תוכנה של vSAN. כברירת מחדל, VMware Engine מפעיל הצפנת vSAN בכל אשכול ESXi ומגדיר ספק מפתחות כברירת מחדל ב-vCenter. ‫Google מחייבת את הלקוחות להשאיר את ההצפנה של vSAN מופעלת באשכולות ESXi שלהם. השבתה של ההצפנה של vSAN היא הפרה של התנאים וההגבלות של VMware Engine. ארגונים רבים דורשים הצפנה במנוחה כחלק ממדיניות החברה שלהם, או מחויבים על פי תקנות להצפין נתונים (לדוגמה, NIST,‏ FIPS).

כל מארח ESXi מצפין נתונים באמצעות מצב XTS של AES-256 רגיל עם מפתחות שונים להצפנת נתונים (DEK) שנוצרים באופן אקראי. מפתח ה-DEK מוצפן באמצעות מפתח להצפנת מפתחות הצפנה (KEK) ומאוחסן בדיסק רק בצורה מוצפנת. שרת vCenter מאחסן רק את המזהה של ה-KEK, אבל לא את ה-KEK עצמו, שמאוחסן ב-Cloud Key Management Service (KMS). אתם יכולים לבחור את המיקום של Cloud KMS שבו מפתח ה-KEK שלכם יישמר.

מומלץ להשתמש בספק ברירת המחדל של מפתחות שמנוהל על ידי Google. עם זאת, אם אתם נדרשים לנהל את Cloud KMS בעצמכם, אתם יכולים להשתמש ב-Cloud KMS של צד שלישי שתואם ל-KMIP 1.1 מאחד מהספקים הנתמכים. בשני המקרים, אפשר להשתמש בספק המפתחות כדי להצפין נתונים במנוחה ותנועה של vMotion בזמן ההעברה.

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

ספק מפתחות	יתרונות	חסרונות
ספק Google-owned and managed key ברירת המחדל	פשטות: הפריסה מתבצעת 'מחוץ לקופסה' ללא צורך בניהול ספקים וללא עומס תפעולי תמיכה מקצה לקצה של Google השיטה הפשוטה ביותר להחלפת מפתחות DEK/KEK היא דרישת המפתח ללא עלות נוספת יתירות מובנית של אזורים לזמינות גבוהה	אי אפשר להשתמש בחומר מפתח משלכם (BYOK) מפתחות ה-KEK מאוחסנים ומנוהלים בתשתית של Google. אין תמיכה במנהלי מפתחות חיצוניים (EKM).
ספק מפתחות Cloud KMS של צד שלישי	שליטה מלאה בנתונים המוצפנים ובמפתח ההצפנה אפשר לאחסן מפתחות שמגובים בחומרה במכשיר HSM	מורכבות נוספת ותקורה תפעולית עלות נוספת יכול להיות שיהיה זמן אחזור נוסף, במיוחד במקרה של SaaS KMS יכול להיות שהזמינות תהיה נמוכה יותר

‫Google לא ממליצה להפעיל הצפנה ברמת המכונה הווירטואלית יחד עם הצפנה של מאגר נתונים של vSAN, כי יעילות ביטול הכפילויות יורדת לאפס במכונות וירטואליות מוצפנות.

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

באחריותכם לבצע רוטציה של מפתח ה-KEK ב-VMware Engine vSphere. ההגדרה הזו חלה גם אם משתמשים בספק מפתחות ברירת המחדל וגם אם משתמשים ב-Cloud KMS חיצוני. אפשר להתחיל את החלפת מפתח ההצפנה (KEK) מ-vCenter או באמצעות vCenter API. כדאי לשקול להפוך את ההחלפה של מפתחות KEK לאוטומטית כדי לעמוד בדרישות האבטחה של הארגון. אפשר למצוא דוגמה לסקריפט PowerCLI ב-GitHub.

דרישה למכונות וירטואליות מוצפנות

אתם יכולים לנהל מפתחות הצפנה למכונות וירטואליות באמצעות ספק ברירת המחדלGoogle-owned and managed key או Cloud Key Management Service.

אם הפעלתם הצפנה של מכונות וירטואליות (או vTPM) במכונות וירטואליות בענן הפרטי שלכם ואתם משתמשים ב-KMS כדי לנהל מפתחות הצפנה, אתם צריכים להצפין מחדש (החלפה חלקית של מפתחות) כל מכונה וירטואלית אחרי שאתם מבצעים רוטציה של מפתח ה-KMS.

החלפת מפתח רדודה מחליפה רק את המפתח להצפנת מפתחות הצפנה (KEK) ולא משנה את המפתח להצפנת נתונים (DEK) של מכונות ה-VM. בדרך כלל מפעילים הצפנה מחדש חלקית באמצעות הפעולה Re-encrypt ב-vSphere Client.

במהלך הפעולה הזו, המערכת מצפינה מחדש את המפתח הקיים להצפנת נתונים (DEK) באמצעות מפתח חדש להצפנת מפתחות הצפנה (KEK). התהליך הזה מהיר כי הוא לא משכתב נתונים בפועל בדיסק, אלא רק מעדכן את חבילת המפתחות הקטנה שמכילה את מפתח ה-DEK המוצפן. מידע נוסף זמין במסמכי התיעוד הבאים של VMware:

• יצירת מפתחות הצפנה חדשים
• הצפנה מחדש של מכונה וירטואלית

הסיכונים בכישלון של החלפת מפתחות במכונות VM מוצפנות

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

• העברות vMotion שנכשלו: מארחי ESXi לא יכולים לפענח את מפתחות ההצפנה של מכונות וירטואליות במהלך vMotion אם אתם מפעילים מחדש את מארחי היעד או מוסיפים אותם לאשכול אחרי רוטציה של מפתחות KMS אבל לפני שמבצעים החלפת מפתחות של המכונה הווירטואלית.
• כשלים בהפעלה: אם מארח מפעיל מחדש את המחשב או מנקה את מטמון המפתחות המקומי שלו, הוא לא יכול לקבל מחדש מפתחות מ-KMS. אם מחקתם את המפתחות הנדרשים מ-KMS, המארח לא יכול לפענח את מפתח הנתונים, ולכן לא ניתן להפעיל מכונות וירטואליות מוצפנות.

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

1. ב-vSphere Client, לוחצים לחיצה ימנית על המכונה הווירטואלית.
2. בוחרים באפשרות VM Policies > Re-encrypt (מדיניות של מכונות וירטואליות > הצפנה מחדש).
3. מאשרים את הבקשה להצפנה מחדש בתיבת הדו-שיח שמופיעה.
4. מחכים שהמשימה תסתיים.
5. כדי לאמת את החלפת המפתחות, מעבירים את המכונה הווירטואלית למארח שהפעלתם מחדש או שהוספתם לאשכול אחרי רוטציית מפתחות ה-KMS.

גיבוי ותוכנית התאוששות מאסון (DR) ב-VMware Engine

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

גיבוי עומסי העבודה באמצעות שירות Backup and DR

‫שירות Backup and DR Google Cloud הוא פתרון גיבוי מובנה ומנוהל מרכזי שאפשר להשתמש בו במגוון תרחישי שימוש, כולל גיבוי של עומסי עבודה ב-Compute Engine וב- Google Cloud VMware Engine. שירות Backup and DR הוא הפתרון המומלץ של Google לגיבוי עומסי עבודה, כי הוא מציע יתרונות כמו תמיכה במגוון רחב של עומסי עבודה, גיבויים מצטברים יעילים מבחינת נפח האחסון ואפשרויות אחסון גמישות.

Google Cloud ב-VMware Engine יש גם תמיכה בפתרונות גיבוי של צד שלישי שמבוססים על סוכנים. יכול להיות שתעדיפו להשתמש בהן אם כבר יש לכם רישיונות למוצר גיבוי של צד שלישי. הדרישות המוקדמות לשימוש בכלים כאלה כוללות:

• הם מספקים גיבויים ברמת האפליקציה
• הם מוסמכים על ידי ספקי האפליקציות
• הם מאושרים על ידי VMware Engine ל-vSAN
• הם תומכים בתקן הפרוטוקול VMware Engine vStorage API for Data Protection‏ (VADP) או יוצרים גיבויים ברמת האפליקציה

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

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

אפשר גם לבחור באחסון vSAN כדי למזער את RPO. אפשר להשתמש באפשרות האחסון הזו אם אתם מוכנים לשלם יותר על אחסון גיבוי, ואם אי אפשר לעמוד בדרישות של RPO באמצעות Cloud Storage. מומלץ להימנע מהאפשרות הזו לארכיון לטווח ארוך, כי יש סיכון שגודל האשכולות של VMware Engine יהיה מוגבל על ידי האחסון.

הטמעה של תוכנית התאוששות מאסון (DR) באמצעות שירות Backup and DR

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

בנוסף ל- Google Cloud Backup and DR,‏ VMware Engine תואם לאפשרויות אחרות לשחזור מאסון, כמו VMware Engine SRM ו-Zerto. גם VMware Engine SRM וגם Zerto מסתמכים על רפליקציית vSphere עבור תוכנית התאוששות מאסון (DR), שבדרך כלל תומכת ביעדי RPO נמוכים יותר. אם יעד ה-RPO שלכם הוא דקות ולא שעות, כדאי לשקול פתרונות DR שמבוססים על שכפול vSphere.

סיכום רשימת המשימות

ברשימת המשימות הבאה מפורטות שיטות מומלצות לאבטחה של השימוש ב-VMware Engine.

משימה	נושא
VMware Engine Networking	זיהוי והבנה של כל זרימות התנועה בסביבה שימוש בשירות כתובות ה-IP הציבוריות של VMware Engine להעברת נתונים באינטרנט ב- כללי חומת אש נפרדים מצפון לדרום וממזרח למערב בשער ובחומת אש מבוזרת ב-VMware Engine NSX החלת עקרונות אבטחה של אפס אמון ומיקרו-פילוח ב-NSX פריסת מכשיר חומת אש של צד שלישי מפורטל Cloud Marketplace ליכולות IPS/IDS שימוש ב-Google Cloud Armor כדי להגן על שירותי אינטרנט ב-VMware Engine מפני מתקפות DDoS התחברות ל Google Cloud שירותים באופן פרטי ללא גישה לאינטרנט הצפנת התקשורת בין הסביבה המקומית לבין Google Cloud איך עוזרים להגן על הנתונים מפני זליגה באמצעות VPC Service Controls
הרשאות ו-IAM ב-VMware Engine	שימוש בתפקידים מוגדרים מראש או בתפקידים בהתאמה אישית כדי להעניק גישה ל-VMware Engine הגבלת גישת אדמין ל-VMware Engine וביצוע ביקורת פעילה על הגישה הגדרת מקור זהויות LDAP או Active Directory החלפת הסיסמאות של חשבונות שירות מובנים ב-VMware Engine
רישום ביומן ומעקב ב-VMware Engine	הוספת יומנים ומדדים של VMware Engine שימוש בסוכן Cloud Logging לרישום ביומן של מכונות VM של עומסי עבודה החלת יכולות שוות ערך של מדיניות Access Transparency ו-Access Approval
הצפנה ב-VMware Engine	שימוש בספק מפתחות בניהול Google שהופעל להצפנת נתונים במנוחה ב-vSAN אוטומציה של רוטציית מפתחות הצפנה בהתאם לתקנים של הארגון
גיבוי ותוכנית התאוששות מאסון (DR) ב-VMware Engine	גיבוי עומסי העבודה באמצעות Backup and DR הטמעה של תוכנית התאוששות מאסון (DR) באמצעות Backup and DR

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

• רוצים להתנסות ב-Google Cloud VMware Engine? מידע נוסף זמין במאמר תכונות, הטבות ותיאורי מקרה.
• מידע נוסף על מושגי אבטחה ב-VMware Engine
• כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים, מדריכים ושיטות מומלצות בנושאי Google Cloud. מידע נוסף זמין במרכז הארכיטקטורה של Cloud.