כדי לשלוט במפתחות ההצפנה שמגינים על הנתונים במצב מנוחה באשכולות ובגיבויים של AlloyDB ל-PostgreSQL, ולנהל אותם, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud Key Management Service (Cloud KMS).
מידע נוסף על 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 מוסבר איך להשתמש במפתחות CMEK שנוצרו באופן ידני כדי להגן על משאבי AlloyDB.
CMEK עם Cloud KMS Autokey
אתם יכולים ליצור מפתחות CMEK באופן ידני כדי להגן על המשאבים של AlloyDB, או להשתמש ב-Cloud KMS Autokey. באמצעות Autokey, אוספי מפתחות ומפתחות נוצרים על פי דרישה כדי לתמוך ביצירת משאבים ב-AlloyDB. אם עדיין לא קיימים סוכני שירות שמשתמשים במפתחות לפעולות הצפנה ופענוח, הם נוצרים ומוקצים להם התפקידים הנדרשים של ניהול זהויות והרשאות גישה (IAM). מידע נוסף זמין במאמר סקירה כללית על Autokey.
תכונות
בקרת גישה לנתונים: אדמינים יכולים להחליף, לנהל את הגישה, להשבית או להשמיד את המפתח ששימש להגנה על נתונים במנוחה ב-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, ובגלל הצורך בזמן אחזור קצר ובזמינות גבוהה, מפתחות ה-DEK נשמרים ב-AlloyDB לצד הנתונים שהם מצפינים.
מערכת AlloyDB מצפינה כל DEK באמצעות מפתח להצפנת מפתחות הצפנה (KEK) שמוחזק על ידי האשכול.
לבסוף, AlloyDB מצפין את ה-KEK באמצעות מפתח ההצפנה של האשכול שמבוסס על Cloud KMS, שהוא מפתחGoogle-owned and Google-managed encryption key או מפתח CMEK.
אתם יכולים גם לראות את גרסאות המפתחות שמשמשות להגנה על אשכול.
הפעלת CMEK
כדי לאפשר לאשכול AlloyDB להשתמש ב-CMEK, צריך לציין את המפתח של Cloud KMS בזמן יצירת האשכול.
כדי ש-AlloyDB יוכל לגשת למפתח בשמכם, אתם צריכים להקצות את התפקיד Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) לסוכן השירות של 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 דקות עדיין אין ל-AlloyDB חיבור ל-Cloud KMS, AlloyDB מתחיל להעביר את האשכול למצב אופליין כאמצעי הגנה. הנתונים באשכול AlloyDB לא יהיו נגישים עד שהאשכול יתחבר מחדש ל-Cloud KMS, ו-Cloud KMS ישיב שהמפתח פעיל.
גיבויים ושחזור
ב-AlloyDB גם הגיבויים מוגנים באמצעות CMEK או באמצעות הצפנה שמוגדרת כברירת מחדל ומנוהלת על ידי Google. אם הגיבוי מופעל באמצעות CMEK, הוא מוצפן באמצעות הגרסה הראשית של מפתח Cloud KMS בזמן יצירת הגיבוי. אחרי שיוצרים גיבוי, אי אפשר לשנות את המפתח ואת גרסת המפתח שלו, גם אם מחליפים את המפתח ב-Cloud KMS. מידע נוסף על הצפנת גיבויים באמצעות CMEK זמין במאמר גיבוי אשכול.
כשמשחזרים אשכול מגיבוי, האשכול המשוחזר משתמש כברירת מחדל בהצפנה בניהול Google, אבל אפשר לציין מפתח CMEK לשימוש במקום זאת. כדי לשחזר גיבוי שמופעל בו CMEK, גם המפתח וגם גרסת המפתח ששימשו להצפנת הגיבוי צריכים להיות זמינים.
רפליקציה בין אזורים
מכיוון שמפתחות Cloud KMS הם משאבים אזוריים, אשכול ראשי ואשכול משני חוצה-אזורים חייבים להשתמש במפתחות Cloud KMS שונים שנמצאים באזורים שלהם. הגדרות ההצפנה של אשכול ראשי ושל אשכול משני לא תלויות זו בזו. כדי להגן על שני האשכולות באמצעות CMEK, צריך ליצור מפתח Cloud KMS באזור של האשכול הראשי ומפתח Cloud KMS נפרד באזור של האשכול המשני.
רישום ביומן
אם הפעלתם את יומני הביקורת של Cloud KMS API בפרויקט, אתם יכולים לבדוק ב-Cloud Logging את הבקשות ש-AlloyDB שולח ל-Cloud KMS בשמכם. אפשר לראות את רשומות היומן של Cloud KMS ב-Cloud Logging. מידע נוסף זמין במאמר הצגת יומני ביקורת של מפתח Cloud KMS.