במאמר הזה מוסבר איך להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud Key Management Service (Cloud KMS) עבור אשכולות ב-Memorystore for Redis Cluster. במסמך מפורט גם אילו נתונים מוצפנים באחסון קבוע ואיך האשכולות מתנהגים במהלך אירועים במחזור החיים של המפתחות.
CMEK מאפשר לכם לשלוט במפתחות ההצפנה שמגנים על הנתונים המאוחסנים. ניהול המפתחות שלכם ב-Cloud KMS מאפשר לכם לקבל שליטה רבה יותר על הגישה למפתחות, על הרוטציה שלהם ועל השימוש בהם, וכך לעמוד בדרישות מחמירות של תאימות ותקנות.
הטמעה של CMEK מספקת שכבת אבטחה נוספת ושליטה בנתונים הקבועים, כמו גיבויים וקבצים קבועים. אפשר להפעיל CMEK רק באשכולות חדשים. אי אפשר להחיל CMEK על אשכולות קיימים.
למי כדאי להשתמש בהצפנה באמצעות מפתח משלהם (CMEK)?
התכונה CMEK מיועדת לארגונים שמאוחסנים בהם נתונים רגישים או נתונים בפיקוח, ונדרשת שליטה במפתחות ההצפנה שלהם. מידע נוסף על השימוש ב-CMEK להצפנת הנתונים האלה זמין במאמר בחירת המקומות שבהם כדאי להשתמש ב-CMEK.
הצפנה בניהול הלקוח
ב-CMEK אפשר להשתמש במפתחות קריפטוגרפיים כדי להגן על נתונים מאוחסנים באשכולות. כדי להצפין את הנתונים האלה, Memorystore for Redis Cluster משתמש במפתחות להצפנת נתונים (DEK) בניהול Google ובמפתחות להצפנת מפתחות הצפנה (KEK) בניהול הלקוח.
אפשר להשתמש ברמות ההצפנה הבאות:
- הצפנת DEK: מפתחות DEK מצפינים נתונים ב-Memorystore for Redis Cluster.
- הצפנת KEK: מפתחות KEK מצפינים מפתחות DEK.
ב-Memorystore for Redis Cluster נעשה שימוש במפתחות KEK להצפנת מפתחות DEK, ובמפתחות DEK להצפנת הנתונים המאוחסנים. אם אתם משתמשים ב-CMEK, אתם יכולים לנהל את מפתחות ה-KEK שמצפינים את מפתחות ה-DEK באשכול.
בתרשים הבא מוצג אופן השימוש ב-CMEK להצפנת נתונים באשכול. הנתונים שמועלים לתשתית האחסון של Google מחולקים למקטעים, וכל מקטע מוצפן באמצעות מפתח DEK משלו. Cloud KMS מספק את ה-KEK להצפנת ה-DEK, ותשתית האחסון של Google מפיצה את מקטעי הנתונים המוצפנים ואת ה-DEK המוצפנים במערכת.

הדיאגרמה הבאה מציגה כיצד Memorystore for Redis Cluster מפענח נתונים שמוצפנים באמצעות CMEK. כדי לגשת לנתונים המוצפנים האלה, מערכת Memorystore for Redis Cluster שולחת בקשה ל-Cloud KMS, שמנהל את מפתח ה-KEK, כדי לפענח את מפתח ה-DEK. לאחר מכן, Cloud KMS מחזיר את ה-DEK המפוענח, והאשכול משתמש בו כדי לפענח את הנתונים המאוחסנים.

אילו נתונים מוצפנים באמצעות CMEK?
מפתחות CMEK מצפינים את סוגי נתוני הלקוחות הבאים שמאוחסנים באחסון קבוע:
- גיבויים: גיבויים מאפשרים לכם לשחזר את הנתונים לנקודת זמן מסוימת, וגם לייצא ולנתח אותם. גיבויים שימושיים גם לתרחישים של תוכנית התאוששות מאסון (DR), העברת נתונים, שיתוף נתונים ותאימות.
- עמידות:
ב-Memorystore for Redis Cluster יש תמיכה בשני סוגים של עמידות:
- שמירת נתונים ב-RDB: התכונה של מסד הנתונים Redis (RDB) מגנה על הנתונים שלכם על ידי שמירת תמונות מצב של הנתונים באחסון עמיד.
- שמירת נתונים בפורמט AOF: התכונה הזו נותנת עדיפות לעמידות הנתונים. הוא שומר את הנתונים באופן עמיד על ידי הקלטה של כל פקודת כתיבה בקובץ יומן שנקרא קובץ להוספה בלבד (AOF). אם מתרחשת כשל במערכת או הפעלה מחדש, השרת מפעיל מחדש את הפקודות בקובץ ה-AOF באופן רציף כדי לשחזר את הנתונים.
- מטא-נתונים שקשורים לתכונות אבטחה כמו אימות בסיסי מבוסס-טוקן והצפנה בזמן העברה. מידע נוסף זמין במאמרים גישה מאובטחת לאשכולות באמצעות אימות בסיסי מבוסס-טוקן ומידע על הצפנה במעבר.
רכיבי CMEK
בקטעים הבאים מתוארים הדרישות וההתנהגויות של חשבונות השירות, המפתחות הקריפטוגרפיים, הגרסאות של המפתחות ומדיניות הארגון שמרכיבים את ארכיטקטורת ה-CMEK שלכם.
חשבונות שירות
כדי ליצור אשכול עם הצפנה באמצעות CMEK, צריך להעניק את התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter לחשבון השירות של Memorystore for Redis Cluster בפורמט הבא:
service-PROJECT_NUMBER@cloud-redis.iam.gserviceaccount.com
ההרשאה הזו מאפשרת לחשבון השירות לבקש גישה למפתחות מ-Cloud KMS.
מקשים
ב-Cloud KMS, צריך ליצור אוסף מפתחות, ואז ליצור מפתח קריפטוגרפי שמשתמש באלגוריתם הצפנה סימטרי. כשיוצרים אשכול, בוחרים את המפתח הזה כדי להצפין את האשכול. אתם יכולים ליצור פרויקט אחד למפתחות ולמערכות שלכם, או פרויקטים שונים לכל אחד מהם.
הצפנה באמצעות מפתח משלכם (CMEK) זמינה בכל המיקומים של האשכולות. צריך ליצור את אוסף המפתחות ואת המפתח באותו אזור שבו רוצים ליצור את האשכול. במקרה של אשכול מרובה אזורים, צריך להגדיר את אוסף המפתחות ואת המפתח לאותו מיקום כמו האשכול. אם האזורים או המיקומים לא תואמים, הבקשה ליצירת האשכול תיכשל.
למזהה המשאב של המפתח, CMEK משתמש בפורמט הבא:
projects/CMEK_ENABLED_PROJECT/locations/REGION/keyRings/KEY_RING_NAME/cryptoKeys/KEY_NAME
מידע נוסף על איתור מזהי משאבים של מפתחות קיימים זמין במאמר קבלת מזהה משאב של Cloud KMS.
מפתחות חיצוניים
כחלק מאסטרטגיית ה-CMEK, אתם יכולים להשתמש במפתחות חיצוניים. כדי לעשות זאת, אפשר להשתמש ב-Cloud External Key Manager (Cloud EKM) כדי להצפין נתונים ב- Google Cloud באמצעות מפתחות חיצוניים שאתם מנהלים.
כשמשתמשים במפתח Cloud EKM, ל-Google אין שליטה בזמינות של המפתחות שמנוהלים באופן חיצוני. אם מפתח לא זמין כשיוצרים את האשכול, Memorystore for Redis Cluster לא יוצר את האשכול. בנוסף, אם המפתח החיצוני לא יהיה זמין בשלב כלשהו אחרי יצירת האשכול, Memorystore for Redis Cluster ישבית את הגיבויים ואת העמידות, אבל פעולות רגילות של שמירת נתונים במטמון בזיכרון ימשיכו לשרת תנועה.
למידע נוסף על שיקולים לגבי שימוש במפתחות חיצוניים, אפשר לעיין במאמר שיקולים.
גרסאות מפתח
ב-Cloud KMS, חומרי המפתחות הקריפטוגרפיים שבהם אתם משתמשים כדי להצפין ולפענח את הנתונים מאוחסנים בגרסת מפתח. מפתח יחיד יכול להכיל כמה גרסאות של מפתחות. בכל פעם שמבצעים רוטציה למפתח, נוצרת גרסת מפתח.
בקטעים הבאים מתואר אופן הפעולה של האשכולות והנתונים המוגנים שלהם במהלך אירועים במחזור החיים של המפתחות, כמו השבתה, השמדה, החלפה, הפעלה או שחזור של גרסאות מפתח. בקטעים האלה מוסבר גם מה קורה כשמבטלים את הגישה למפתח Cloud KMS או מחליפים אותו, ומופיעות הנחיות להצפנה מחדש של נתונים באופן ידני.
השבתה או השמדה של גרסת מפתח CMEK
יכול להיות שיהיו מצבים שבהם תרצו להפוך נתונים שהוצפנו באמצעות CMEK לבלתי נגישים באופן קבוע, למשל כשאתם מתקנים דליפת נתונים. כדי להשיג השמדת נתונים ברמת ודאות גבוהה (שנקראת גם השמדה קריפטוגרפית), צריך להשמיד את גרסת המפתח. מידע נוסף על השמדת גרסאות מפתח זמין במאמר השמדה ושחזור של גרסאות מפתח.
אם משביתים או משמידים את הגרסה הראשית של המפתח, התנאים הבאים חלים על גיבויים ועל נתונים קבועים.
גיבויים
כשמשמידים את הגרסה הראשית של המפתח, הגיבויים של האשכול כפופים להגבלות הבאות:
- אי אפשר ליצור גיבויים לפי דרישה או גיבויים אוטומטיים. עם זאת, אם מפעילים גרסה ישנה יותר של מפתח, אפשר לגשת לגיבויים שנוצרו באמצעות גרסת המפתח הזו.
- אי אפשר לעדכן או להפעיל מחדש גיבויים אוטומטיים עד שמפעילים או משחזרים את גרסת המפתח הראשית. מידע נוסף זמין במאמר בנושא הפעלה או שחזור של הגרסה הראשית של מפתח CMEK.
התמדה
כשמשמידים את הגרסה הראשית של המפתח, ההגבלות הבאות חלות על נתונים קבועים באשכול:
- אם מגדירים את האשכול לשימוש בנתונים קבועים, Memorystore for Redis Cluster משבית את הנתונים הקבועים כשגרסת המפתח לא זמינה. לא נגבה יותר תשלום על שימוש בנתונים מתמשכים.
- ב-Memorystore for Redis Cluster, הנתונים החדשים לא מועברים לאחסון מתמיד באמצעות CMEK.
- Memorystore for Redis Cluster לא יכול לקרוא נתונים קיימים שנמצאים באחסון הקבוע.
- אי אפשר לעדכן או להפעיל מחדש את ההתמדה עד שמפעילים או משחזרים את גרסת המפתח הראשית.
אם מפעילים את גרסת המפתח הראשית, אבל משביתים או משמידים גרסת מפתח ישנה יותר, התנאים הבאים חלים על גיבויים ועל נתונים קבועים:
- אתם יכולים ליצור גיבויים. עם זאת, אם הגיבוי מוצפן באמצעות גרסה ישנה יותר של מפתח שהושבתה או נהרסה, לא תהיה לכם גישה לגיבוי.
- אם מפעילים את ההתמדה, היא נשארת פעילה. אם גרסת המפתח הישנה יותר שמשמשת להתמדה מושבתת או מושמדת, Memorystore for Redis Cluster מבצע עדכון שדומה לזה שמשמש לתחזוקה, ומצפין מחדש את הנתונים באמצעות גרסת המפתח הראשית.
ביטול הגישה למפתח Cloud KMS
אם מבטלים את הגישה למפתח פעיל של Cloud KMS על ידי השבתת המפתח או הסרת הרשאות IAM למפתח, המערכת של Memorystore for Redis Cluster נותנת עדיפות לזמינות של מטמון ראשי. פעולות רגילות של שמירת נתונים במטמון בזיכרון ממשיכות להציג תנועה.
עם זאת, הגיבויים וההתמדה מושבתים. Memorystore for Redis Cluster מפסיק מיד לכתוב נתונים חדשים לדיסק ולא קורא נתונים מהדיסק המוצפן של הלקוח לזיכרון.
רוטציה של גרסת המפתח הראשית של CMEK
אם מבצעים רוטציה של גרסת המפתח הראשי ויוצרים גרסת מפתח ראשי חדשה, התנאים הבאים חלים על גיבויים ועל נתונים קבועים:
- הגרסה האחרונה של המפתח הראשי של ה-CMEK מצפינה גיבויים חדשים.
- לגיבויים קיימים, לא מתבצעת הצפנה מחדש.
- לצורך התמדה, הצמתים לא מבצעים שום פעולה. הצמתים ימשיכו להשתמש בגרסה הישנה יותר של המפתח עד לאירוע התחזוקה הבא.
הצפנה מחדש של נתונים שמוגנים באמצעות CMEK באופן ידני
Memorystore for Redis Cluster לא תומך בהצפנה מחדש של נתונים מאוחסנים לפי דרישה. אי אפשר להפעיל תהליך באופן ידני כדי להשתמש בגרסה חדשה של מפתח להצפנה מחדש של גיבויים קיימים או קבצים פעילים של נתונים קבועים. עם זאת, אפשר להשתמש בגרסת המפתח החדשה כדי להצפין נתונים חדשים שנכתבו.
אם מבצעים רוטציה למפתח וצריך לאלץ את האשכול להשתמש בגרסת המפתח החדשה, התנאים הבאים חלים על הגיבויים ועל נתונים קבועים:
גיבויים
אי אפשר להצפין מחדש גיבויים קיימים. אם התאימות מחייבת שכל הנתונים יוצפנו באמצעות המפתח החדש ביותר, צריך ליצור גיבוי באמצעות המפתח הזה ואז למחוק את הגיבויים הקיימים באופן ידני. אפשר גם לייצא את הגיבוי הזה לקטגוריה של Cloud Storage כדי להשתמש במפתח ההצפנה של Cloud Storage.
התמדה
כדי לאלץ את האשכול להשתמש במפתח חדש של Cloud KMS, אפשר להפעיל תחזוקה מדומה באשכול. אחרי השלמת הפעולה הזו, Memorystore for Redis Cluster יכול לכתוב נתוני שמירה באמצעות הגרסה המעודכנת של המפתח הראשי.
החלפת מפתח מוגן של Cloud KMS
אם מחליפים מפתח מוגן של Cloud KMS במפתח אחר או בגרסה חדשה של מפתח ראשי, השינוי הזה יחול ב-Memorystore for Redis Cluster רק על פעולות עתידיות.
החלפה של מפתח מוגן משפיעה על המשאבים שלכם בדרכים הבאות:
- גיבויים: כל הגיבויים הבאים מוצפנים באמצעות המפתח החדש. הגיבויים הקיימים שומרים על המפתחות המקוריים שלהם.
- שימור: בפעם הבאה שהאשכול יופעל מחדש או שתתבצע בו פעולת תחזוקה, ייעשה שימוש במפתח החדש.
- מטמון ראשי: להחלפת המפתח הזה אין השפעה. הצפנת CMEK לא חלה על נתונים בזיכרון כי הנתונים האלה לא נחשבים לנתונים מאוחסנים.
הפעלה או שחזור של גרסת המפתח הראשית של CMEK
אם מפעילים או משחזרים את גרסת המפתח הראשי, התנאים הבאים חלים על גיבויים ועל שמירת נתונים:
- תוכלו ליצור שוב גיבויים לפי דרישה וגיבויים אוטומטיים.
- מערכת Memorystore for Redis Cluster מבצעת עדכון שדומה לזה שמשמש לתחזוקה, ומפעילה מחדש את העמידות.
מגבלות שקשורות למדיניות הארגון
Memorystore for Redis Cluster תומך באילוצים של מדיניות הארגון לגבי CMEK. באמצעות האילוצים האלה, אתם יכולים לאכוף הגנה באמצעות CMEK על האשכולות שלכם ולהגביל את מפתחות Cloud KMS שבהם אתם יכולים להשתמש להגנה הזו.
אפשר להגדיר את אילוצי המדיניות הארגונית הבאים:
-
constraints/gcp.restrictNonCmekServices: משתמשים באילוץ הזה כדי לאכוף הגנה באמצעות CMEK על האשכולות. אם Memorystore for Redis Cluster API מופיע ברשימת השירותים של המדיניותDenyשל האילוץ הזה, לא תוכלו ליצור אשכולות שלא מוגנים באמצעות CMEK. -
constraints/gcp.restrictCmekCryptoKeyProjects: משתמשים באילוץ הזה כדי להגביל את מפתחות Cloud KMS שאפשר להשתמש בהם להגנה באמצעות CMEK. אם מגדירים את האילוץ הזה, אשכולות שמשתמשים בהצפנת CMEK חייבים להשתמש במפתח מפרויקט, מתיקייה או מארגון מורשים.
מכיוון של-Memorystore for Redis Cluster ול-Memorystore for Redis יש נקודת קצה משותפת (redis.googleapis.com), אי אפשר לאכוף CMEK עבור אשכולות בנפרד ממכונות Memorystore for Redis.
מידע נוסף על אילוצים של מדיניות הארגון שקשורים ל-CMEK וש-Google מנהלת עבור Memorystore for Redis Cluster זמין במאמר אילוצים של מדיניות הארגון.
תמחור
החיוב על Memorystore for Redis Cluster עבור אשכול עם הפעלת CMEK זהה לחיוב על כל אשכול אחר, ואין עלויות נוספות. מידע נוסף מופיע במאמר בנושא תמחור של Memorystore for Redis Cluster.
משתמשים ב-Cloud KMS API כדי לנהל את ה-CMEK. כשיוצרים אשכול עם CMEK, Memorystore משתמש במפתח באופן תקופתי כדי להצפין נתונים.
תחויבו על ידי Cloud KMS בעלות המפתח ועל פעולות ההצפנה והפענוח כש-Memorystore for Redis Cluster משתמש במפתח. מידע נוסף זמין במאמר תמחור של Cloud KMS.
מגבלות
ההגבלות הבאות חלות כשמשתמשים ב-CMEK עם Memorystore for Redis Cluster:
- אי אפשר להפעיל CMEK באשכול קיים.
- המפתח, אוסף המפתחות והאשכול צריכים להיות באותו אזור.
- חובה להשתמש באלגוריתם הצפנה סימטרי בשביל המפתח.
- קצב ההצפנה והפענוח של Cloud KMS תלוי במכסה.