מידע על הצפנת vSAN

הצפנה של נתונים במנוחה ב-vSAN מחייבת מערכת לניהול מפתחות (KMS). ב-Google Cloud VMware Engine יש כמה אפשרויות לניהול מפתחות להצפנת נתונים ב-vSAN:

  • ‫Google-owned and Google-managed encryption keys (GMEK): כברירת מחדל, הצפנת נתונים ב-vSAN משתמשת ב- Google-owned and Google-managed encryption keys ב-Cloud Key Management Service לעננים פרטיים, ללא עלות נוספת.
  • מפתחות הצפנה בניהול הלקוח (CMEK): אתם יכולים להשתמש ב-CMEK ב-Cloud Key Management Service כדי לנהל מפתחות הצפנה לעננים פרטיים נפרדים.
  • מערכת חיצונית לניהול מפתחות הצפנה (KMS): אפשר לפרוס מערכת חיצונית לניהול מפתחות הצפנה להצפנת נתונים במצב מנוחה ב-vSAN מאחד מהספקים הנתמכים הבאים.

בחירת פתרון לניהול מפתחות

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

תכונה GMEK (ברירת מחדל) CMEK מערכת KMS חיצונית
האחריות לניהול המפתחות Google לקוח/ה לקוח/ה
אחסון מפתחות Cloud Key Management Service (פרויקט Google) Cloud Key Management Service (פרויקט של לקוח) מערכת KMS חיצונית
רמת הבידוד שירות אזורי ענן פרטי אישי ענן פרטי אישי
אוטומציה של רוטציה אוטומציה של Google אוטומטי על ידי Google לאחר רוטציה ב-KMS מנוהל על ידי הלקוח
עלות של רישיון נוסף ללא Google Cloud חלים חיובים על KMS רישוי KMS של צד שלישי

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

הצפנת נתונים ב-vSAN

כברירת מחדל, ב-VMware Engine מופעלת הצפנת vSAN לנתונים באשכול הראשי ובאשכולות שנוספים בהמשך לענן הפרטי. ההצפנה של נתונים במנוחה ב-vSAN מתבצעת באמצעות מפתח להצפנת נתונים (DEK) שמאוחסן בדיסק הפיזי המקומי של האשכול אחרי ההצפנה. מפתח ה-DEK הוא מפתח הצפנה מסוג AES-256 bit שנוצר אוטומטית על ידי מארחי ESXi, בהתאם לתקן FIPS 140-2 Level 1. המערכת משתמשת במפתח להצפנת מפתחות הצפנה (KEK) שסופק על ידי Cloud Key Management Service או על ידי KMS חיצוני כדי להצפין את ה-DEK.

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

באופן דומה, אם מגדירים KMS חיצוני, אנחנו לא ממליצים למחוק את הגדרת ספק המפתחות של Cloud Key Management Service ב-vCenter Server.

Google-owned and Google-managed encryption keys (GMEK)

כברירת מחדל, בעננים פרטיים נעשה שימוש ב Google-owned and Google-managed encryption keys (GMEK). בעזרת GMEK, ‏ VMware Engine מגדיר את vCenter Server להתחבר לספק GMEK. ‫VMware Engine יוצר מופע אחד של ספק המפתחות לכל אזור, וספק המפתחות משתמש ב-Cloud KMS להצפנה של המפתח להצפנת מפתחות הצפנה. ‫VMware Engine מנהל באופן מלא את ספק המפתחות ומגדיר אותו כך שיהיה זמין מאוד בכל האזורים.

ספק ה-GMEK משלים את ספק המפתחות המובנה ב-vCenter Server (ב-vSphere 7.0 Update 2 ואילך) והוא הגישה המומלצת לסביבות ייצור. ספק המפתחות המובנה פועל כתהליך בתוך vCenter Server, שפועל באשכול vSphere ב-VMware Engine. ‫VMware ממליצה לא להשתמש בספק המפתחות המובנה להצפנת האשכול שמארח את vCenter Server. במקום זאת, אפשר להשתמש ב-GMEK, ב-CMEK או ב-KMS חיצוני.

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

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

מפתחות הצפנה בניהול הלקוח (CMEK)

‫Google Cloud VMware Engine תומך במפתחות הצפנה בניהול הלקוח (CMEK) עבור עננים פרטיים נפרדים באמצעות Cloud Key Management Service. אפשר להגדיר לכל ענן פרטי מפתח CMEK נפרד, במקום לשתף מפתח יחיד בכל הפרויקט. היתרונות של השימוש ב-Google Analytics:

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

ניהול הצפנת CMEK

אתם יכולים להגדיר ולנהל מפתחות הצפנה בניהול הלקוח (CMEK) לענן הפרטי שלכם באמצעות מסוף Google Cloud ו-VMware Engine API. כדי להשתמש ב-CMEK, צריך להעניק לחשבון השירות של VMware Engine‏ (service-<var>PROJECT_NUMBER</var>@gcp-sa-vmwareengine.iam.gserviceaccount.com) את תפקיד ה-IAM‏ roles/cloudkms.cryptoKeyEncrypterDecrypter עבור מפתח Cloud KMS הספציפי שרוצים להשתמש בו. ההרשאה הזו מאפשרת ל-VMware Engine להצפין ולפענח את המפתח להצפנת המפתח (KEK) שמגן על נתוני vSAN באמצעות מפתח Cloud KMS שנבחר בפרויקט.

הקצאת הרשאות למפתחות

כדי להפעיל את CMEK, צריך להקצות את ההרשאות הנדרשות:

  1. מזהים את משאב ה-KMS: עוברים לדף Key Management במסוףGoogle Cloud ומחפשים את מפתח Cloud KMS הספציפי שבו רוצים להשתמש להגנה על הנתונים.

    כניסה אל Key Management

  2. הגדרת תפקידי IAM: מקצים את התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter לחשבון השירות של VMware Engine‏ (service-<var>PROJECT_NUMBER</var>@gcp-sa-vmwareengine.iam.gserviceaccount.com) ישירות בלוח הבקרה של מפתח Cloud KMS.

Google Cloud הוראות לניהול CMEK ב-Console וב-VMware Engine API:

מסוף Google Cloud

כדי להגדיר מפתחות הצפנה בניהול הלקוח (CMEK) באמצעות מסוף Google Cloud :

יצירת ענן פרטי עם CMEK

כדי ליצור ענן פרטי עם CMEK באמצעות Google Cloud המסוף:

  1. נכנסים לדף Private clouds במסוף Google Cloud .

    כניסה ל-Private clouds

  2. לוחצים על יצירה.

  3. בקטע Encryption בוחרים באפשרות Customer-managed encryption keys (CMEK).

  4. מזינים את שם המשאב המלא של מפתח Cloud KMS.

  5. לוחצים על יצירה או על שמירה.

עדכון מפתח CMEK בענן פרטי קיים

כדי לעדכן את מפתח ה-CMEK עבור ענן פרטי קיים באמצעות מסוף Google Cloud :

  1. נכנסים לדף Private clouds במסוף Google Cloud .

    כניסה ל-Private clouds

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

  3. בקטע Encryption בוחרים באפשרות Customer-managed encryption keys (CMEK).

  4. מזינים את שם המשאב המלא של מפתח Cloud KMS.

  5. לוחצים על יצירה או על שמירה.

עדכון ההצפנה ל-GMEK בענן פרטי קיים

כדי לעדכן את סוג ההצפנה ל-GMEK בענן פרטי קיים באמצעות Google Cloud המסוף:

  1. נכנסים לדף Private clouds במסוף Google Cloud .

    כניסה ל-Private clouds

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

  3. בקטע Encryption, בוחרים באפשרות Google-owned and Google-managed encryption keys (GMEK).

  4. לוחצים על יצירה או על שמירה.

VMware Engine API

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

  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫LOCATION: האזור ב-VMware Engine, כמו us-east4.
  • ‫PC_ID: המזהה של הענן הפרטי החדש.
  • ‫NETWORK_ID: המזהה של רשת ה-VPC.
  • ‫CIDR_RANGE: טווח ה-CIDR לניהול של הענן הפרטי.
  • ‫CLUSTER_ID: המזהה של אשכול הניהול.
  • ‫NODE_TYPE: סוג הצומת, למשל standard-72.
  • ‫COUNT: מספר הצמתים באשכול.
  • ‫RING: השם של אוסף המפתחות ב-Cloud KMS.
  • ‫KEY: השם של המפתח הקריפטוגרפי ב-Cloud KMS.
  • ‫PC_NAME: השם של הענן הפרטי הקיים.

כדי ליצור ענן פרטי עם CMEK, משתמשים בשיטה privateClouds.create ומציינים את הפרמטר encryptionConfig:

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json; charset=utf-8" \
  "https://vmwareengine.googleapis.com/v1/projects//locations//privateClouds?private_cloud_id=" \
  -d '{
  "networkConfig": {
    "vmwareEngineNetwork": "projects//locations/global/vmwareEngineNetworks/",
    "managementCidr": ""
  },
  "managementCluster": {
    "clusterId": "",
    "nodeTypeConfigs": {
      "": {
        "nodeCount": 
      }
    }
  },
  "encryptionConfig": {
    "cryptoKeyName": "projects//locations//keyRings//cryptoKeys/"
  }
}'

כדי לעדכן את מפתח ה-CMEK בענן פרטי קיים, משתמשים בשיטה privateClouds.patch:

curl -X PATCH \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json; charset=utf-8" \
  "https://vmwareengine.googleapis.com/v1/projects//locations//privateClouds/?updateMask=encryptionConfig" \
  -d '{
  "encryptionConfig": {
    "cryptoKeyName": "projects//locations//keyRings//cryptoKeys/"
  }
}'

כדי להחזיר ענן פרטי קיים ל-GMEK ‏ (Google-owned and Google-managed encryption keys), משתמשים בשיטה privateClouds.patch עם אובייקט encryptionConfig ריק:

curl -X PATCH \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json; charset=utf-8" \
  "https://vmwareengine.googleapis.com/v1/projects//locations//privateClouds/?updateMask=encryptionConfig" \
  -d '\''{
  "encryptionConfig": {}
}'\''

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

  • דרישות אזוריות: גם הענן הפרטי וגם מפתח Cloud KMS שבחרתם צריכים להיות באותו אזור. שימו לב: לא ניתן להשתמש במפתחות גלובליים של Google Cloud KMS להצפנת vSAN.
  • זמינות המפתח: אם מפתח ההצפנה לא נגיש כי הוא הושבת או בוטל, כל פעולות ה-vSAN שתלויות בו ייכשלו. אי אפשר להמשיך בהליכים חיוניים, כולל הפעלה מחדש של המארח והחלפה חלקית של מפתחות, עד שתתבצע שוב גישה למפתחות.

יעילות תפעולית עם רוטציה אוטומטית של מפתחות KEK באמצעות CMEK

לארגונים שבוחרים ב-CMEK, התכונה של רוטציה אוטומטית של מפתחות הצפנה (KEK) להצפנת נתונים במצב מנוחה ב-vSAN מאפשרת לבצע אוטומציה של משימות אבטחה ידניות:

  • סנכרון אוטומטי: המערכת עוקבת אחרי Cloud KMS ומזהה באופן אוטומטי רוטציות של מפתחות.
  • החלפת מפתח הצפנה (KEK) ברקע בצורה חלקה: אחרי ההחלפה, המערכת מתחילה החלפת KEK רדודה, כדי להבטיח הגנה רציפה ללא התערבות ידנית ב-vCenter. הפעולה הזו מעדכנת את המפתח להצפנת מפתחות הצפנה (KEK) של המפתחות להצפנת נתונים (DEK) במפתח חדש להצפנת מפתחות הצפנה (KEK). מכיוון שמפתחות DEK מצפינים את הנתונים ב-vSAN באופן ישיר, התהליך הזה לא מחייב הצפנה מחדש מלאה של הנתונים ב-vSAN.
  • ניהול ללא השבתה: המערכת יוצרת ומחילה מפתחות KEK ברקע, ושומרת על הביצועים והזמינות של עומסי העבודה. התהליך הזה בדרך כלל מסתיים תוך 48 שעות אחרי רוטציה של מפתח Cloud KMS.

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

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

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

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

מערכת KMS חיצונית

אפשר גם לבחור פתרון KMS של צד שלישי שתואם ל-KMIP 1.1 וקיבל אישור מ-VMware לשימוש ב-vSAN. הספקים הבאים אימתו את פתרון ה-KMS שלהם באמצעות VMware Engine ופרסמו מדריכי פריסה והצהרות תמיכה:

הוראות להגדרה מפורטות במסמכים הבאים:

שימוש בספק נתמך

כל פריסה של KMS חיצונית דורשת את אותם שלבים בסיסיים:

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

לאחר מכן, פורסים את ה-KMS במכונה וירטואלית ב-Compute Engine:

  1. הגדרת הרשאות IAM שנדרשות לפריסת מכונות וירטואליות של Compute Engine.
  2. פורסים את KMS ב-Compute Engine.
  3. יצירת אמון בין vCenter לבין KMS.
  4. הפעלת הצפנת נתונים ב-vSAN.

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

הגדרת הרשאות IAM

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

בעלי פרויקטים ומשתמשי IAM עם התפקיד Network Admin יכולים ליצור טווחי כתובות IP שהוקצו ולנהל חיבורים פרטיים. מידע נוסף על תפקידים זמין במאמר תפקידי IAM ב-Compute Engine.

פריסת מערכת לניהול מפתחות ב-Compute Engine

חלק מפתרונות ה-KMS זמינים כציוד ב-Google Cloud Marketplace. אפשר לפרוס מכשירים כאלה על ידי ייבוא קובץ ה-OVA ישירות לרשת ה-VPC או לפרויקט Google Cloud .

במקרה של KMS מבוסס-תוכנה, פורסים מכונת VM ב-Compute Engine באמצעות ההגדרה (מספר ליבות ה-vCPU, הזיכרון והדיסקים) שמומלצת על ידי ספק ה-KMS. מתקינים את תוכנת ה-KMS במערכת ההפעלה האורחת. יוצרים את המכונה הווירטואלית ב-Compute Engine ברשת VPC שמחוברת לרשת VMware Engine.

יצירת אמון בין vCenter לבין KMS

אחרי שמפעילים את KMS ב-Compute Engine, צריך להגדיר את VMware Engine vCenter כך שיאחזר מפתחות הצפנה מ-KMS.

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

  1. יוצרים אישור ב-vCenter.
  2. חותמים עליו באמצעות אסימון או מפתח שנוצרו על ידי KMS.
  3. מספקים או מעלים את האישור הזה ל-vCenter.
  4. כדי לוודא את סטטוס הקישוריות, בודקים את ההגדרה והסטטוס של KMS בדף ההגדרה של שרת vCenter.

הפעלת הצפנת נתונים ב-vSAN

ב-vCenter, למשתמש CloudOwner שמוגדר כברירת מחדל יש הרשאות מספיקות להפעלה ולניהול של הצפנת נתונים ב-vSAN.

כדי לעבור מספק KMS חיצוני בחזרה לספק ברירת המחדלGoogle-owned and managed key , צריך לבצע את השלבים לשינוי ספק המפתחות שמופיעים בתיעוד של VMware הגדרה וניהול של ספק מפתחות רגיל.

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