Cloud KMS Autokey מפשט את התהליך של יצירה ושימוש במפתחות הצפנה בניהול הלקוח (CMEK) באמצעות אוטומציה של הקצאת משאבים והקצאת הרשאות. עם Autokey, אוספי מפתחות ומפתחות נוצרים לפי דרישה. חשבונות שירות שמשתמשים במפתחות כדי להצפין ולפענח משאבים נוצרים ומקבלים תפקידים של ניהול זהויות והרשאות גישה (IAM) לפי הצורך. לאדמינים של Cloud KMS יש שליטה מלאה במפתחות שנוצרו על ידי Autokey, והם יכולים לראות אותם בלי לתכנן מראש וליצור כל משאב. השימוש ב-Autokey פשוט יותר מאשר הקצאת מפתחות באופן עצמאי, והוא מומלץ אם המפתחות שנוצרו על ידי Autokey עומדים בכל הדרישות שלכם.
שימוש במפתחות שנוצרו על ידי Autokey יכול לעזור לכם לעמוד באופן עקבי בתקנים המקובלים בתעשייה ובשיטות המומלצות לאבטחת נתונים, כולל רמת ההגנה של Cloud HSM מרובה הדיירים, הפרדת תפקידים, רוטציית מפתחות, מיקום ומפרט מפתח. Autokey יוצר מפתחות שעומדים בהנחיות כלליות ובהנחיות ספציפיות לסוג המשאב עבור שירותיםGoogle Cloud שמשולבים עם Cloud KMS Autokey. אחרי שהמפתחות נוצרים, הם פועלים בדיוק כמו מפתחות אחרים של Cloud HSM עם אותן הגדרות.
בנוסף, Autokey יכול לפשט את השימוש ב-Terraform לניהול מפתחות, ולבטל את הצורך בהרצת תשתית כקוד עם הרשאות מוגברות ליצירת מפתחות.
אפשר להשתמש ב-Autokey עם אחסון מפתחות בפרויקט ייעודי (שנקרא בעבר ניהול מפתחות מרכזי) או עם אחסון מפתחות באותו פרויקט (שנקרא בעבר ניהול מפתחות בהרשאת משנה). כדי להשתמש ב-Autokey עם אחסון מפתחות בפרויקט ייעודי, צריך משאב מסוג 'ארגון' שמכיל משאב מסוג 'תיקייה'. כשמשתמשים באחסון מפתחות בפרויקט ייעודי, מפעילים את Autokey לפרויקטים בתיקייה, והמפתחות שנוצרים על ידי Autokey נוצרים בפרויקט המפתחות הייעודי של התיקייה הזו. כשמשתמשים באחסון מפתחות באותו פרויקט, מפעילים את Autokey בתיקייה או בפרויקט כדי לאפשר ל-Autokey ליצור מפתחות באותו פרויקט שבו נמצאים המשאבים שהמפתחות מגנים עליהם.
מידע נוסף על משאבי ארגון ותיקיות זמין במאמר היררכיית המשאבים.
התכונה 'הקצאת מפתחות אוטומטית' ב-Cloud KMS זמינה בכל Google Cloud המיקומים שבהם Cloud HSM זמין. מידע נוסף על מיקומים ב-Cloud KMS מופיע במאמר מיקומים ב-Cloud KMS. אין עלות נוספת לשימוש ב-Cloud KMS Autokey. המחיר של מפתחות שנוצרו באמצעות Autokey זהה למחיר של כל מפתח אחר ב-Cloud HSM. מידע נוסף על התמחור זמין במאמר תמחור של Cloud Key Management Service.
איך Autokey עובד
בקטע הזה מוסבר איך פועל Cloud KMS Autokey. התפקידים הבאים של המשתמשים משתתפים בתהליך הזה:
- מנהל מערכת
- האדמין הוא משתמש שאחראי על ניהול האבטחה ברמת התיקייה או הארגון.nk
- מפתח Autokey
- מפתח Autokey הוא משתמש שאחראי ליצירת משאבים באמצעות Cloud KMS Autokey.
- אדמין של Cloud KMS
- אדמין Cloud KMS הוא משתמש שאחראי לניהול משאבי Cloud KMS. כשהמפתחות נוצרים באופן אוטומטי, התפקיד הזה כולל פחות אחריות מאשר כשהמפתחות נוצרים באופן ידני.
גם נציגי השירות הבאים משתתפים בתהליך הזה:
- סוכן שירות של Cloud KMS
- סוכן השירות של Cloud KMS בפרויקט מפתח נתון. התכונה Autokey תלויה בסוכן השירות הזה, שצריכות להיות לו הרשאות מורחבות כדי ליצור מפתחות ואוספי מפתחות ב-Cloud KMS, ולהגדיר מדיניות IAM במפתחות, וכך להעניק הרשאות הצפנה ופענוח לכל סוכן שירות של משאב.
- סוכן שירות משאבים
- סוכן השירות של שירות מסוים בפרויקט משאבים מסוים. לסוכן השירות הזה צריכות להיות הרשאות הצפנה ופענוח לכל מפתח Cloud KMS לפני שהוא יכול להשתמש במפתח הזה להגנה באמצעות CMEK על משאב. Autokey יוצר את סוכן השירות של המשאב כשצריך, ומעניק לו את ההרשאות הנדרשות לשימוש במפתח Cloud KMS.
האדמין מפעיל את Cloud KMS Autokey
כדי להפעיל את Autokey, בוחרים באחת מהאפשרויות הבאות בהתאם למודל אחסון המפתחות שבחרתם:
- אחסון מפתחות בפרויקט ייעודי: הפעלת אחסון מפתחות בפרויקט ייעודי בתיקייה. אתם מגדירים פרויקט מפתח ייעודי שיכיל את המפתחות שמגנים על משאבים שנוצרו בפרויקטים אחרים בתיקייה.
- אחסון מפתחות באותו פרויקט: אפשר להפעיל אחסון מפתחות באותו פרויקט בפרויקטים ספציפיים או בכל הפרויקטים בתיקייה, כדי ליצור מפתחות באותו פרויקט כמו המשאבים שהם מגנים עליהם.
הפעלת אחסון מפתחות בפרויקט ייעודי
כדי להשתמש ב-Autokey עם אחסון מפתחות בפרויקט ייעודי בתיקייה, אדמין צריך להשלים את משימות ההגדרה החד-פעמיות הבאות:
מפעילים את Autokey עם אחסון מפתחות בפרויקט ייעודי בתיקייה, ומזהים את פרויקט Cloud KMS שיכיל משאבי Autokey עבור התיקייה הזו.
יוצרים את סוכן השירות של Cloud KMS ואז מעניקים לו הרשאות ליצירת מפתחות ולהקצאתם.
אחרי שההגדרה הזו תושלם, מפתחים שיש להם הרשאה ליצור משאבים שתואמים ל-Autokey בכל פרויקט בתיקייה הזו יוכלו להפעיל יצירה של מפתחות Multi-tenant Cloud HSM לפי דרישה. הוראות מלאות להגדרה של Cloud KMS Autokey מופיעות במאמר הפעלת Cloud KMS Autokey.
הפעלת Autokey עם אחסון מפתחות באותו פרויקט
כדי להשתמש ב-Autokey עם אחסון מפתחות באותו פרויקט, אדמין צריך להשלים את משימות ההגדרה החד-פעמיות הבאות:
- הפעלת Autokey עם אחסון מפתחות באותו פרויקט בפרויקט או בתיקייה.
- מפעילים את Cloud KMS API בפרויקט או בפרויקטים בתיקייה.
כשמפעילים את התכונה 'הוספת מפתח אוטומטית' עם אחסון מפתחות באותו פרויקט, סוכן השירות של Cloud KMS נוצר בשבילכם כשצריך. לא צריך ליצור את סוכן השירות באופן ידני. כל משתמש עם הרשאות ליצירת משאב שתואם ל-Autokey יכול לבקש מפתח חדש לפי דרישה. הוראות מלאות להגדרה של Cloud KMS Autokey מופיעות במאמר הפעלת Cloud KMS Autokey.
מפתחים של Autokey משתמשים ב-Cloud KMS Autokey
אחרי שמפעילים את Autokey בפרויקט, מפתחים יכולים ליצור משאבים שמוגנים באמצעות מפתחות שנוצרו עבורם לפי דרישה. ההגדרה הזו חלה גם על פרויקטים בתיקייה שבה מופעלת התכונה 'מפתחות אוטומטיים' עם אחסון מפתחות ייעודי לפרויקט, וגם על פרויקטים שבהם מופעלת התכונה 'מפתחות אוטומטיים' עם אחסון מפתחות באותו פרויקט. הפרטים של תהליך יצירת המשאבים תלויים במשאב שיוצרים, אבל התהליך מתבצע לפי השלבים הבאים:
מפתח Autokey מתחיל ליצור משאב בשירותGoogle Cloud תואם. במהלך יצירת משאב, המפתח מבקש מפתח חדש מסוכן השירות של Autokey.
סוכן השירות של Autokey מקבל את הבקשה של המפתח ומשלים את השלבים הבאים:
- יוצרים אוסף מפתחות בפרויקט במיקום שנבחר, אלא אם אוסף המפתחות הזה כבר קיים.
- יוצרים מפתח באוסף המפתחות עם רמת הפירוט המתאימה לסוג המשאב, אלא אם מפתח כזה כבר קיים.
- יוצרים את חשבון השירות לכל פרויקט ולכל שירות, אלא אם חשבון השירות הזה כבר קיים.
- נותנים לחשבון השירות הרשאות הצפנה ופענוח של מפתח לכל פרויקט ולכל שירות.
- מעבירים למפתח את הפרטים העיקריים כדי שהוא יוכל לסיים את יצירת המשאב.
אחרי שהסוכן של שירות Autokey מחזיר את הפרטים החשובים, המפתח יכול לסיים מיד את יצירת המשאב המוגן.
Cloud KMS Autokey יוצר מפתחות עם המאפיינים שמתוארים בקטע הבא. תהליך יצירת המפתח הזה שומר על הפרדת תפקידים. לאדמין של Cloud KMS עדיין יש שליטה מלאה במפתחות שנוצרו על ידי Autokey וגישה לכל המידע שקשור אליהם.
כדי להתחיל להשתמש ב-Autokey אחרי שמפעילים אותו, אפשר לעיין במאמר יצירת משאבים מוגנים באמצעות Cloud KMS Autokey.
מידע על מפתחות שנוצרו על ידי Autokey
למפתחות שנוצרו על ידי Cloud KMS Autokey יש את המאפיינים הבאים:
- רמת הגנה: HSM.
- אלגוריתם: AES-256 GCM.
תקופת הרוטציה: שנה אחת.
אחרי שמפתח נוצר על ידי Autokey, אדמין של Cloud KMS יכול לערוך את תקופת הרוטציה מברירת המחדל.
- הפרדת תפקידים:
- לחשבון השירות של השירות מוענקות באופן אוטומטי הרשאות הצפנה ופענוח במפתח.
- הרשאות האדמין ב-Cloud KMS חלות כרגיל על מפתחות שנוצרו על ידי Autokey. אדמינים של Cloud KMS יכולים להציג, לעדכן, להפעיל או להשבית מפתחות שנוצרו על ידי Autokey, וגם להשמיד אותם. לאדמינים של Cloud KMS לא ניתנות הרשאות הצפנה ופענוח.
- מפתחי Autokey יכולים לבקש רק יצירה והקצאה של מפתחות. הם לא יכולים לראות את המפתחות או לנהל אותם.
- ספציפיות המפתח או גרנולריות: הגרנולריות של מפתחות שנוצרו על ידי Autokey משתנה בהתאם לסוג המשאב. פרטים ספציפיים לשירות על רמת הגרנולריות של המפתח מפורטים בקטע שירותים תואמים בדף הזה.
מיקום: Autokey יוצר מפתחות באותו מיקום שבו נמצא המשאב שרוצים להגן עליו.
אם אתם צריכים ליצור משאבים שמוגנים באמצעות CMEK במיקומים שבהם Cloud HSM לא זמין, אתם צריכים ליצור את ה-CMEK באופן ידני.
- מצב גרסת המפתח: מפתחות חדשים שנוצרו באמצעות Autokey נוצרים כגרסת המפתח הראשית במצב מופעל.
- שמות של אוספי מפתחות: כל המפתחות שנוצרים על ידי Autokey נוצרים באוסף מפתחות שנקרא
autokey. מחזיקי מפתחות בפרויקט Autokey נוצרים כשמפתח Autokey מבקש את המפתח הראשון במיקום נתון. מחזיק המפתחותautokeyנוצר בפרויקט המפתח הייעודי אם משתמשים באחסון מפתחות בפרויקט ייעודי, או בפרויקט המשאבים אם משתמשים באחסון מפתחות באותו פרויקט. - מתן שמות למפתחות: מפתחות שנוצרו על ידי Autokey מקבלים שמות לפי המוסכמה הבאה:
PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX - ייצוא מפתחות: כמו כל המפתחות ב-Cloud KMS, אי אפשר לייצא מפתחות שנוצרו על ידי Autokey.
- מעקב אחרי מפתחות: כמו כל המפתחות של Cloud KMS שמשמשים בשירותים משולבים של CMEK שתואמים למעקב אחרי מפתחות, המפתחות שנוצרו על ידי Autokey מתועדים בלוח הבקרה של Cloud KMS.
שליטה בשימוש ב-Autokey
אתם קובעים איך משתמשים ב-Autokey בארגון באמצעות האמצעים הבאים:
- הגדרת Autokey: מפעילים את Autokey בתיקיות או בפרויקטים שבהם רוצים להשתמש בו. הגדרות של מפתחות אוטומטיים עוברות בירושה למשאבי צאצא, אבל אפשר לעקוף אותן באמצעות הגדרות שנקבעו ברמה נמוכה יותר – לדוגמה, ההגדרה של מפתחות אוטומטיים שנקבעה בפרויקט מקבלת קדימות על פני ההגדרה של תיקיית ההורה. כך תוכלו לשלוט ב-Autokey מלמטה למעלה. מידע נוסף על הפעלה והשבתה של Autokey זמין במאמר הפעלת Cloud KMS Autokey.
- IAM: אתם יכולים לקבוע למי יש הרשאה ליצור ולעדכן הגדרות של Autokey, ולמי יש הרשאה ליצור משאבים שמוגנים באמצעות Autokey, באמצעות הענקת תפקידים ב-IAM וכללי מדיניות דחייה. אפשר להגדיר את אמצעי הבקרה האלה של IAM ברמת הארגון, התיקייה או הפרויקט. ההרשאות שניתנות דרך תפקיד ב-IAM מאפשרות לחשבונות משתמשים לבצע פעולות שהתפקיד מאפשר. מדיניות דחייה ב-IAM חוסמת הרשאות ספציפיות, גם אם הן כלולות בתפקיד שניתן לחשבון המשתמש. אי אפשר לבטל את כללי המדיניות של IAM לסירוב שמוגדרים במשאב אב באמצעות כללי מדיניות מתירים יותר שמוגדרים ברמה נמוכה יותר. כך אתם מקבלים שליטה מלמעלה למטה על מי יכול להפעיל את Autokey ולהשתמש בו. מידע נוסף על שימוש בכללי מדיניות דחייה של IAM כדי לשלוט בשימוש ב-Autokey בארגון זמין במאמר שימוש בכללי מדיניות דחייה של IAM כדי לשלוט ב-Autokey.
- מדיניות הארגון: אתם יכולים לשלוט איפה ואיך אפשר להגדיר את Autokey באמצעות אילוצים מותאמים אישית של מדיניות הארגון. אפשר לאכוף אילוצים של מדיניות הארגון ברמת הארגון, התיקייה או הפרויקט. משאבי צאצא יורשים את מדיניות הארגון, אבל אפשר לבטל את ההשפעה שלהן באמצעות מדיניות שנאכפת ברמה נמוכה יותר. מידע נוסף על שימוש במגבלות מותאמות אישית במדיניות הארגון כדי לשלוט בשימוש ב-Autokey בארגון זמין במאמר שימוש במגבלות מותאמות אישית במדיניות הארגון כדי לשלוט ב-Autokey .
שירותים תואמים
בטבלה הבאה מפורטים שירותים שתואמים ל-Cloud KMS Autokey:
| שירות | משאבים מוגנים | רמת הפירוט של המפתחות |
|---|---|---|
| AlloyDB ל-PostgreSQL |
השילוב בין AlloyDB ל-PostgreSQL לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או ה-API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| Apigee |
השילוב בין Apigee לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| Apigee API hub |
שילוב בין Apigee API hub לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| Artifact Registry |
Autokey יוצר מפתחות במהלך יצירת המאגר, שמשמשים לכל הארטיפקטים המאוחסנים. |
מפתח אחד לכל משאב |
| BigQuery |
Autokey יוצר מפתחות ברירת מחדל למערכי נתונים. טבלאות, מודלים, שאילתות וטבלאות זמניות בתוך מערך נתונים משתמשים במפתח ברירת המחדל של מערך הנתונים. Autokey לא יוצר מפתחות למשאבי BigQuery מלבד מערכי נתונים. כדי להגן על משאבים שלא נכללים במערך נתונים, צריך ליצור מפתחות ברירת מחדל משלכם ברמת הפרויקט או הארגון. |
מפתח אחד לכל משאב |
| Bigtable |
Autokey יוצר מפתחות לאשכולות. Autokey לא יוצר מפתחות למשאבי Bigtable שאינם אשכולות. השילוב בין Bigtable לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או Google Cloud SDK. |
מפתח אחד לכל אשכול |
| Cloud Run |
|
מפתח אחד לכל מיקום בפרויקט |
| Cloud SQL |
Autokey לא יוצר מפתחות למשאבי Cloud SQL
השילוב בין Cloud SQL לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| Cloud Storage |
אובייקטים בקטגוריית אחסון משתמשים במפתח ברירת המחדל של הקטגוריה. Autokey לא יוצר מפתחות למשאבי |
מפתח אחד לכל קטגוריה |
| Compute Engine |
קובצי Snapshot משתמשים במפתח של הדיסק שיוצרים לו קובץ Snapshot.
Autokey לא יוצר מפתחות למשאבי |
מפתח אחד לכל משאב |
| Google Kubernetes Engine |
השילוב בין Google Kubernetes Engine לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או ה-API בארכיטקטורת REST. |
מפתח אחד לכל אשכול |
| Dataflow |
|
מפתח אחד לכל משאב |
| Managed Service for Apache Airflow |
השילוב בין Managed Service for Apache Airflow לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| Managed Service for Apache Spark |
|
למשאבים מסוג Cluster, SessionTemplate ו-WorkflowTemplate: מפתח אחד לכל משאב למשאבי Batch ו-Session: מפתח אחד לכל מיקום בפרויקט |
| Memorystore for Redis |
השילוב בין Memorystore for Redis לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| Pub/Sub |
|
מפתח אחד לכל משאב |
| Secret Manager |
השילוב בין Secret Manager לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או API בארכיטקטורת REST. |
מפתח אחד לכל מיקום בפרויקט |
| Secure Source Manager |
|
מפתח אחד לכל משאב |
| Spanner |
השילוב בין Spanner לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| Filestore |
|
מפתח אחד לכל משאב |
מגבלות
- ה-CLI של gcloud לא זמין למשאבי Autokey.
- ידיות מפתחות לא נמצאות במאגר משאבי הענן.
המאמרים הבאים
- כדי להתחיל להשתמש ב-Cloud KMS Autokey, אדמינים צריכים להפעיל את Cloud KMS Autokey.
- כדי להשתמש ב-Cloud KMS Autokey אחרי שמפעילים אותו, מפתחים יכולים ליצור משאבים שמוגנים באמצעות CMEK באמצעות Autokey.
- שיטות מומלצות לשימוש ב-CMEK