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

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

אם יש לכם דרישות רגולטוריות או דרישות תאימות ספציפיות שקשורות למפתחות שמגנים על הנתונים שלכם, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) ב-Firestore עם תאימות ל-MongoDB. במקום ש-Google תנהל את מפתחות ההצפנה שמגנים על הנתונים שלכם, מסד הנתונים של Firestore עם תאימות ל-MongoDB מוגן באמצעות מפתח שאתם שולטים בו ומנהלים אותו ב-Cloud Key Management Service‏ (Cloud KMS).

בדף הזה מתואר CMEK ל-Firestore עם תאימות ל-MongoDB. מידע נוסף על CMEK באופן כללי, כולל מתי ולמה כדאי להפעיל אותו, זמין במאמרי העזרה הבאים של Cloud KMS:

הוראות לביצוע משימות שקשורות ל-CMEK ב-Firestore עם תאימות ל-MongoDB מופיעות במאמר שימוש ב-CMEK.

תכונות

  • שליטה בנתונים: בעזרת CMEK אפשר לנהל את מפתח ה-KMS. אתם יכולים לבצע רוטציה של המפתח שמשמש להצפנת הנתונים במצב מנוחה במסד הנתונים שלכם ב-Firestore עם תאימות ל-MongoDB, להשבית אותו ולהשמיד אותו.
  • ביצועים: ל-CMEK אין השפעה על הסכם רמת השירות (SLA) של Firestore.
  • יכולת ביקורת: אם מפעילים רישום ביומן הביקורת של Cloud KMS, כל הפעולות שמתבצעות במפתח נרשמות ביומן וניתן לראות אותן ב-Cloud Logging.
  • אילוצים על מדיניות הארגון: אפשר להשתמש באילוצים על מדיניות הארגון בנושא CMEK כדי לציין דרישות תאימות להצפנה במסדי נתונים של Firestore עם תאימות ל-MongoDB בארגון.

תמחור

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

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

אין עלויות נוספות לשימוש ב-Firestore עם תאימות ל-MongoDB במסד נתונים שמוגן באמצעות CMEK, והתמחור של Firestore עם תאימות ל-MongoDB ממשיך לחול.

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

מה מוגן באמצעות CMEK

כשיוצרים מסד נתונים ב-Firestore עם תאימות ל-MongoDB שמוגן באמצעות CMEK, מפתח Cloud KMS משמש להגנה על הנתונים באחסון. ההגדרה הזו כוללת נתונים שמאוחסנים בדיסק או בכונן הבזק, כולל אינדקסים וגיבויים. יש כמה חריגים. סוגי הנתונים הבאים מוצפנים באמצעות הצפנת ברירת המחדל של Google ולא באמצעות מפתח CMEK:

  • נתונים במעבר או בזיכרון
  • מטא-נתונים של מסד נתונים

איך המערכת מטפלת במצב של מפתח לא זמין

פעולות הצפנה ופענוח לא מתבצעות בכל בקשת נתונים. במקום זאת, מערכת Firestore עם תאימות ל-MongoDB מבצעת סקר ב-Cloud KMS כל 5 דקות כדי לבדוק אם המפתח עדיין זמין, ואז מבצעת פעולות הצפנה ופענוח אם המפתח זמין.

אם המערכת מזהה שהמפתח לא זמין, כל הקריאות הבאות למסד הנתונים של Firestore עם תאימות ל-MongoDB, כולל קריאות, כתיבות ושאילתות, מחזירות שגיאת INVALID_ARGUMENT עם ההודעה הבאה:

The customer-managed encryption key required by the requested
resource is not accessible.

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

מפתחות נחשבים ללא זמינים בכל מצב שבו נמנעת באופן מכוון גישה למפתח מ-Firestore עם תאימות ל-MongoDB. למשל:

אם המפתח יוחזר, פעולת התשאול תזהה שהמפתח זמין שוב. הגישה מופעלת מחדש, בדרך כלל תוך דקות, אבל במקרים נדירים יכול להיות שייקח כמה שעות. חשוב לזכור שחלק מהפעולות על מפתחות Cloud KMS, כמו השבתה או השמדה של מפתח, יכולות להימשך עד 3 שעות. ‫Firestore עם תאימות ל-MongoDB לא מזהה שינויים עד שהם נכנסים לתוקף ב-Cloud KMS.

החזרה של מפתח לפעולה כוללת את הפעולות הבאות, בהתאם למצב:

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

שיקולים לגבי רוטציית מפתחות

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

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

שיקולים לגבי מפתחות חיצוניים

כשמשתמשים במפתח Cloud EKM, ל-Google אין שליטה בזמינות של המפתח שמנוהל חיצונית במערכת של השותף החיצוני לניהול מפתחות.

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

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

במסמכי Cloud External Key Manager מפורטים שיקולים נוספים לשימוש במפתחות חיצוניים.

גיבוי ושחזור

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

‫Firestore עם תאימות ל-MongoDB יוצר את הגיבוי הראשון של מסד נתונים עם הצפנה באמצעות מפתח CMEK אחרי 24 שעות מהרגע שבו מפעילים את לוחות הזמנים של הגיבוי.

מידע נוסף על גיבויים של Firestore עם תאימות ל-MongoDB זמין במאמר בנושא גיבוי ושחזור נתונים.

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

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

למידע נוסף על שחזור מסד נתונים של Firestore עם תאימות ל-MongoDB מגיבוי, ראו שחזור נתונים מגיבוי של מסד נתונים. מידע נוסף על שחזור מסד נתונים של Firestore עם תאימות ל-MongoDB שמוגן באמצעות CMEK מגיבוי זמין במאמר שחזור מסד נתונים שמוגן באמצעות CMEK.

שכפל

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

  • שיבוט למסד נתונים עם CMEK עם מפתח חדש שצוין.
  • שיבוט למסד נתונים שאינו CMEK ומשתמש בהצפנת ברירת המחדל של Google.
  • (ברירת מחדל) שיבוט למסד נתונים שמשתמש באותה הצפנה כמו מסד הנתונים של המקור.

מידע נוסף על שיבוט מסד נתונים של Firestore עם תאימות ל-MongoDB זמין במאמר בנושא שיבוט מסד נתונים. מידע נוסף על שיבוט של מסד נתונים ב-Firestore עם תאימות ל-MongoDB שמוגן באמצעות CMEK זמין במאמר שיבוט של מסד נתונים שמוגן באמצעות CMEK.

מעקב אחר מפתחות

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

זמינות של מפתחות ו-CMEK

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

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

  • כשיוצרים מסד נתונים עם CMEK, מפתחות מושבתים לא מופיעים ברשימת המפתחות הזמינים במסוף Google Cloud . אם תזינו ידנית מפתח מושבת, תהליך יצירת מסד הנתונים ייכשל עם השגיאה INVALID_ARGUMENT400.

מגבלות

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

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

  • ‫Firestore תומך במספר מוגבל של מסדי נתונים שמוגנים באמצעות CMEK.

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