בדף הזה נסביר על מפתחות הצפנה בניהול הלקוח (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.
כש-AlloyDB משתמש במפתח, אתם מחויבים על ידי Cloud KMS בעלות המפתח ועל פעולות ההצפנה והפענוח. מידע נוסף זמין במאמר בנושא תמחור של 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 בזמן יצירת האשכול.
מערכת 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, הוא מוצפן באמצעות הגרסה הראשית של מפתח ה-KMS בזמן יצירת הגיבוי. אחרי שיוצרים גיבוי, אי אפשר לשנות את המפתח ואת גרסת המפתח שלו, גם אם מתבצעת רוטציה של מפתח ה-KMS. מידע נוסף זמין במאמר בנושא גיבוי של אשכול.
כשמשחזרים אשכול מגיבוי, האשכול המשוחזר משתמש כברירת מחדל בהצפנה בניהול Google, אבל אפשר לציין מפתח CMEK לשימוש במקום זאת. כדי לשחזר גיבוי שמופעל בו CMEK, המפתח וגרסת המפתח ששימשו להצפנת הגיבוי צריכים להיות זמינים.
רישום ביומן
אם הפעלתם את רישום הביקורת עבור Cloud KMS API בפרויקט שלכם, תוכלו לבדוק ב-Cloud Logging את הבקשות ש-AlloyDB שולח ל-Cloud KMS בשמכם. רשומות היומן של Cloud KMS האלה מוצגות ב-Cloud Logging. מידע נוסף זמין במאמר צפייה ביומני ביקורת של מפתח Cloud KMS.