בדף הזה מוסבר על מפתחות הצפנה בניהול הלקוח (CMEK) ב-AlloyDB ל-PostgreSQL.
מידע נוסף על CMEK באופן כללי, כולל מתי וכדאי להפעיל את התכונה הזו, מופיע במסמכי התיעוד של Cloud KMS.
כברירת מחדל, תוכן של לקוחות ב-AlloyDB ל-PostgreSQL מוצפן במצב מנוחה. AlloyDB מטפל בהצפנה בשבילכם בלי שתצטרכו לבצע פעולות נוספות. האפשרות הזו נקראת הצפנת ברירת המחדל של Google.
אם אתם רוצים לשלוט במפתחות ההצפנה, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud KMS עם שירותים שמשולבים עם CMEK, כולל AlloyDB. שימוש במפתחות Cloud KMS מאפשר לכם לשלוט ברמת ההגנה, במיקום, בלוח הזמנים של הרוטציה, בשימוש ובהרשאות הגישה, ובגבולות הקריפטוגרפיים. בנוסף, באמצעות Cloud KMS תוכלו לצפות ביומני ביקורת ולשלוט במחזורי החיים של המפתחות. במקום ש-Google תהיה הבעלים של מפתחות ההצפנה של המפתחות (KEK) הסימטריים שמגנים על הנתונים שלכם ותנהל אותם, אתם שולטים במפתחות האלה ומנהלים אותם ב-Cloud KMS.
אחרי שמגדירים את המשאבים עם CMEK, חוויית הגישה למשאבי AlloyDB דומה לשימוש בהצפנה שמוגדרת כברירת מחדל ב-Google. מידע נוסף על אפשרויות ההצפנה זמין במאמר מפתחות הצפנה בניהול הלקוח (CMEK).
כדי ללמוד איך להשתמש במפתחות CMEK שנוצרו באופן ידני כדי להגן על משאבי AlloyDB, אפשר לעיין במאמר בנושא שימוש ב-CMEK.
CMEK עם Cloud KMS Autokey
אתם יכולים ליצור מפתחות CMEK באופן ידני כדי להגן על משאבי AlloyDB, או להשתמש ב-Cloud KMS Autokey. באמצעות Autokey, אוספי מפתחות ומפתחות נוצרים לפי דרישה כדי לתמוך ביצירת משאבים ב-AlloyDB. סוכני שירות שמשתמשים במפתחות לפעולות הצפנה ופענוח נוצרים אם הם לא קיימים כבר, ומקבלים את התפקידים הנדרשים של ניהול זהויות והרשאות גישה (IAM). מידע נוסף מופיע במאמר סקירה כללית על Autokey.
AlloyDB תואם ל-Cloud KMS Autokey רק כשיוצרים משאבים באמצעות Terraform או API בארכיטקטורת REST.
חלופה בניהול עצמי להצפנה בניהול Google
כברירת מחדל, כל הנתונים במצב מנוחה ב- Google Cloud, כולל הנתונים ב-AlloyDB, מוגנים באמצעות הצפנה כברירת מחדל שמנוהלת על ידי Google. Google Cloudמטפל בהצפנה הזו ומנהל אותה בשבילכם בלי שתצטרכו לבצע פעולות נוספות.
אם יש לכם דרישות תאימות או רגולטוריות ספציפיות שקשורות למפתחות שמגנים על הנתונים שלכם, אתם יכולים להשתמש ב-CMEK במקום זאת. בעזרת CMEK, האשכול של AlloyDB מוגן באמצעות מפתח שאתם שולטים בו ומנהלים אותו ב-Cloud Key Management Service (KMS). אתם יכולים לבחור את רמת ההגנה של המפתח.
תכונות
בקרת גישה לנתונים: אדמינים יכולים לבצע רוטציה של המפתח שבו השתמשתם כדי להגן על נתונים באחסון ב-AlloyDB, לנהל את הגישה אליו, להשבית אותו או להשמיד אותו.
ניהול המפתחות מתבצע על ידי Cloud KMS. אחרי הרוטציה, האשכולות לא מוצפנים מחדש באופן אוטומטי באמצעות הגרסה החדשה יותר של המפתח. האשכולות מוצפנים באמצעות הגרסה הראשית של CMEK בזמן יצירת האשכול. כדי לבצע רוטציה של הצפנת האשכול, צריך ליצור גיבוי ולשחזר את האשכול באמצעות הגרסה החדשה יותר של המפתח. מידע נוסף זמין במאמר סקירה כללית על גיבוי ושחזור נתונים.
יכולת ביקורת: אם מפעילים רישום ביומן ביקורת עבור Cloud KMS API בפרויקט, כל הפעולות שמתבצעות במפתח, כולל אלה שמבוצעות על ידי AlloyDB, נרשמות ביומן וניתן לראות אותן ב-Cloud Logging.
ביצועים: השימוש ב-CMEK לא משנה את הביצועים של AlloyDB.
תמחור
החיוב על אשכולות עם הפעלת CMEK ב-AlloyDB זהה לחיוב על כל אשכול אחר, ואין עלויות נוספות ב-AlloyDB. מידע נוסף זמין במאמר בנושא תמחור של AlloyDB ל-PostgreSQL.
תחויבו על ידי Cloud KMS בעלות המפתח ועל פעולות ההצפנה והפענוח כש-AlloyDB משתמש במפתח. מידע נוסף זמין במאמר תמחור של Cloud Key Management Service.
מה מוגן באמצעות CMEK
AlloyDB משתמש במפתח Cloud KMS שלכם כדי להגן על נתונים באחסון בדרכים הבאות:
- אם מפעילים CMEK באשכול, מערכת AlloyDB משתמשת במפתח כדי להצפין את כל הנתונים של האשכול באחסון.
- אם מציינים הגדרת CMEK כשיוצרים גיבוי לפי דרישה, AlloyDB משתמש במפתח כדי להצפין את הגיבוי הזה.
אם מפעילים CMEK עם ההגדרה של גיבוי רציף או אוטומטי של האשכול, AlloyDB משתמש במפתח כדי להצפין את הגיבויים השוטפים.
בין אם משתמשים ב- Google-owned and Google-managed encryption keys או ב-CMEK, AlloyDB כולל שלוש שכבות של הצפנה:
AlloyDB מחלק את הנתונים באחסון למקטעים לצורך אחסון, ומצפין כל מקטע באמצעות מפתח הצפנה נפרד. המפתח שמשמש להצפנת הנתונים במקטע נקרא מפתח להצפנת נתונים (DEK).
בגלל הכמות הגדולה של מפתחות Google, ובגלל הצורך בזמן אחזור קצר ובזמינות גבוהה, מערכת AlloyDB שומרת כל מפתח DEK לצד הנתונים שהוא מצפין.
AlloyDB מצפין כל DEK באמצעות מפתח להצפנת מפתחות הצפנה (KEK) שמאוחסן באשכול.
לבסוף, AlloyDB מצפין את מפתח ה-KEK באמצעות מפתח ההצפנה של האשכול שמבוסס על Cloud Key Management Service, שהוא מפתח Google-owned and Google-managed encryption keyאו מפתח CMEK.
אפשר גם לראות את גרסאות המפתח שמשמשות להגנה על אשכול.
הפעלת CMEK
כדי לאפשר לאשכול AlloyDB להשתמש ב-CMEK, צריך לציין את מפתח Cloud KMS בזמן יצירת האשכול.
אחרי שתקצו את התפקיד Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) לסוכן שירות של AlloyDB, AlloyDB יוכל לגשת למפתח בשמכם.
הוראות מפורטות זמינות במאמר בנושא שימוש ב-CMEK.
ניהול מפתחות
משתמשים ב-Cloud KMS לכל פעולות ניהול המפתחות. AlloyDB לא יכול לזהות שינויים במפתחות או לפעול לפיהם עד שהם מועברים על ידי Cloud KMS. חלק מהפעולות, כמו השבתה או השמדה של מפתח, יכולות להימשך עד שלוש שעות. שינויים בהרשאות בדרך כלל מופצים הרבה יותר מהר.
אחרי שיוצרים את האשכול, AlloyDB מתקשר עם Cloud KMS בערך כל חמש דקות כדי לוודא שהמפתח עדיין בתוקף.
אם מערכת AlloyDB מזהה שהמפתח שלכם ב-Cloud KMS הושבת או נמחק, מתחילה מיד פעולה להפיכת הנתונים באשכול לבלתי נגישים. אם הקריאות של AlloyDB אל Cloud KMS מזהות שמפתח שהושבת בעבר הופעל מחדש, המערכת משחזרת את הגישה באופן אוטומטי.
שימוש במפתחות חיצוניים וניהולם
במקום להשתמש במפתחות שנמצאים ב-Cloud KMS, אתם יכולים להשתמש במפתחות שנמצאים אצל שותף חיצוני לניהול מפתחות. כדי לעשות את זה, אתם יכולים להשתמש ב-Cloud External Key Manager (Cloud EKM) כדי ליצור ולנהל מפתחות חיצוניים, שהם מצביעים למפתחות שנמצאים מחוץ ל- Google Cloud. מידע נוסף זמין במאמר בנושא Cloud External Key Manager.
אחרי שיוצרים מפתח חיצוני באמצעות Cloud EKM, אפשר להחיל אותו על אשכול חדש של AlloyDB על ידי ציון המזהה של המפתח הזה כשיוצרים את האשכול. התהליך הזה זהה לתהליך של החלת מפתח Cloud KMS על אשכול חדש.
אתם יכולים להשתמש ב-Key Access Justifications כחלק מ-Cloud EKM. התכונה 'הצדקות גישה למפתחות' מאפשרת לכם לראות את הסיבה לכל בקשה ל-Cloud EKM. בנוסף, על סמך ההצדקה שסופקה, אפשר לאשר או לדחות בקשה באופן אוטומטי. מידע נוסף זמין במאמר סקירה כללית.
ל-Google אין שליטה על הזמינות של מפתחות במערכת חיצונית לניהול מפתחות של שותף.
מפתח לא זמין
אם משביתים את מפתח Cloud KMS שמשמש להצפנה של אשכול AlloyDB, המכונות של AlloyDB ששייכות לאשכול הזה יושבתו תוך 30 דקות. הפעלה מחדש של המפתח תגרום להפעלת המכונות מחדש.
בתרחישים לא שכיחים, כמו בתקופות שבהן Cloud KMS לא זמין, יכול להיות ש-AlloyDB לא יוכל לאחזר את הסטטוס של המפתח מ-Cloud KMS. בתרחיש הזה, מערכת AlloyDB ממשיכה לתמוך בפעולות מלאות של אשכול על בסיס מיטב המאמצים למשך עד 30 דקות, כדי למזער את ההשפעה של הפסקות זמניות על עומס העבודה.
אחרי 30 דקות, אם עדיין אין אפשרות להתחבר ל-Cloud KMS מ-AlloyDB, AlloyDB מתחיל להעביר את האשכול למצב אופליין כאמצעי הגנה. לא ניתן לגשת לנתונים באשכול AlloyDB עד שהאשכול יוכל להתחבר מחדש ל-Cloud KMS, ו-Cloud KMS ישיב שהמפתח פעיל.
גיבויים ושחזור
ב-AlloyDB יש גם הגנה על גיבויים באמצעות CMEK או הצפנה שמנוהלת על ידי Google כברירת מחדל. אם הגיבוי מופעל באמצעות CMEK, הוא מוצפן באמצעות הגרסה הראשית של מפתח ה-KMS בזמן יצירת הגיבוי. אחרי שיוצרים גיבוי, אי אפשר לשנות את המפתח ואת גרסת המפתח שלו, גם אם מתבצעת רוטציה של מפתח ה-KMS. מידע נוסף זמין במאמר בנושא גיבוי של אשכול.
כשמשחזרים אשכול מגיבוי, האשכול המשוחזר משתמש כברירת מחדל בהצפנה בניהול Google, אבל אפשר לציין מפתח CMEK לשימוש במקום זאת. כדי לשחזר גיבוי שמופעל בו CMEK, המפתח וגרסת המפתח ששימשו להצפנת הגיבוי צריכים להיות זמינים.
רישום ביומן
אם הפעלתם יומני ביקורת עבור Cloud KMS API בפרויקט שלכם, תוכלו לבדוק ב-Cloud Logging את הבקשות ש-AlloyDB שולח ל-Cloud KMS בשמכם. רשומות היומן של Cloud KMS האלה מוצגות ב-Cloud Logging. מידע נוסף זמין במאמר הצגת יומני ביקורת של מפתח Cloud KMS.