באמצעות Cloud KMS Autokey, קל יותר ליצור מפתחות הצפנה בניהול הלקוח (CMEK) ולהשתמש בהם, כי ההקצאה וההגדרה שלהם מתבצעות באופן אוטומטי. באמצעות Autokey, אוספי מפתחות ומפתחות נוצרים על פי דרישה. חשבונות שירות שמשתמשים במפתחות כדי להצפין ולפענח משאבים נוצרים ומוקצים להם תפקידים של ניהול זהויות והרשאות גישה (IAM) לפי הצורך. לאדמינים ב-Cloud KMS יש שליטה מלאה וגישה למפתחות שנוצרו באמצעות Autokey, בלי שהם צריכים לתכנן מראש וליצור כל משאב. השימוש ב-Autokey פשוט יותר מהקצאת מפתחות בעצמכם, וזו האפשרות המומלצת אם המפתחות שנוצרו על ידי Autokey עומדים בכל הדרישות שלכם.
שימוש במפתחות שנוצרו על ידי Autokey יכול לעזור לכם לפעול באופן עקבי בהתאם לתקנים המקובלים בתחום ולשיטות המומלצות לאבטחת מידע, כולל רמת ההגנה של Multi-tenant Cloud HSM, הפרדת תפקידים, רוטציית מפתחות, מיקום וספציפיות של מפתחות. Autokey יוצר מפתחות בהתאם להנחיות כלליות ולהנחיות ספציפיות לסוג המשאב, בשביל שירותיGoogle Cloud שמשתלבים עם Cloud KMS Autokey. אחרי שיוצרים את המפתחות, המפתחות שביקשתם באמצעות Autokey פועלים באופן זהה למפתחות אחרים של Cloud HSM עם אותן הגדרות.
כשמשתמשים ב-Autokey, ההרשאות שנדרשות כדי לבקש מפתח חדש הן מינימליות, והן כלולות בתפקידי ברירת המחדל שמעניקים הרשאות ליצירת משאבים. המשמעות היא שהמפתחים וצינורות עיבוד הנתונים של תשתית כקוד (IaC) לא צריכים הרשאות מורחבות. התכונה Autokey מפשטת את השימוש ב-Terraform לניהול מפתחות, ותומכת בעיקרון של הרשאות מינימליות.
אתם יכולים להשתמש ב-Autokey עם אחסון מפתחות בפרויקט ייעודי (שנקרא בעבר ניהול מפתחות ריכוזי) או עם אחסון מפתחות באותו פרויקט (שנקרא בעבר ניהול מפתחות מבוזר). כדי להשתמש ב-Autokey עם אחסון מפתחות בפרויקט ייעודי, צריך משאב ארגון שמכיל משאב תיקייה. כשמשתמשים באחסון מפתחות בפרויקט ייעודי, מפעילים את Autokey לפרויקטים בתוך תיקייה, והמפתחות שנוצרים על ידי Autokey נוצרים בפרויקט המפתחות הייעודי של אותה תיקייה. כשמשתמשים באחסון מפתחות באותו פרויקט, מפעילים את Autokey בתיקייה או בפרויקט כדי לאפשר ל-Autokey ליצור מפתחות באותו פרויקט שבו נמצאים המשאבים שהם מגינים עליהם.
למידע נוסף על משאבי ארגון ותיקייה, קראו את המאמר היררכיית המשאבים.
Cloud KMS Autokey זמין בכל Google Cloud המיקומים שבהם Cloud HSM זמין. מידע נוסף על מיקומים ב-Cloud KMS מופיע במאמר מיקומים ב-Cloud KMS. אין עלות נוספת לשימוש ב-Cloud KMS Autokey. המחיר של מפתחות שנוצרו באמצעות Autokey זהה למחיר של כל מפתח אחר ב-Cloud HSM. למידע נוסף על התמחור, ראו המחירון של Cloud Key Management Service.
בחירה בין Autokey לבין אפשרויות הצפנה אחרות
Cloud KMS עם Autokey הוא כמו טייס אוטומטי למפתחות הצפנה בניהול הלקוח: הוא מבצע את העבודה בשבילכם, לפי דרישה. אתם לא צריכים לתכנן מפתחות מראש או ליצור מפתחות שאולי לא תצטרכו אף פעם. המפתחות והשימוש בהם עקביים. אתם יכולים להגדיר איפה אתם רוצים להשתמש ב-Autokey ולשלוט במי יכול להשתמש בו. אתם שומרים על שליטה מלאה במפתחות שנוצרו באמצעות Autokey. אתם יכולים להשתמש במפתחות Cloud KMS שנוצרו באופן ידני לצד מפתחות שנוצרו באמצעות Autokey. אתם יכולים להשבית את Autokey ולהמשיך להשתמש במפתחות שהוא יצר, בדיוק כמו כל מפתח אחר ב-Cloud KMS.
Cloud KMS Autokey מתאים לכם אם אתם רוצים להשתמש במפתחות באופן עקבי בפרויקטים, עם עלויות תפעול נמוכות, ורוצים לפעול לפי ההמלצות של Google לגבי מפתחות.
| תכונה או יכולת | ברירת המחדל של Google להצפנה | Cloud KMS | Cloud KMS Autokey |
|---|---|---|---|
| בידוד קריפטוגרפי: המפתחות הם בלעדיים לחשבון של לקוח אחד | לא | כן | כן |
| הלקוח הוא הבעלים של המפתחות והוא שולט בהם | לא | כן | כן |
| המפתח מפעיל את ההקצאה והשיוך של המפתחות | כן | לא | כן |
| ספציפיות: המפתחות נוצרים באופן אוטומטי ברמת הפירוט המומלצת של המפתח | לא | לא | כן |
| מאפשרת לכם לבצע גריסה קריפטוגרפית של הנתונים | לא | כן | כן |
| התאמה אוטומטית לשיטות המומלצות לניהול מפתחות | לא | לא | כן |
| שימוש במפתחות שמגובים ב-HSM ותואמים ל-FIPS 140-2 ברמה 3 | לא | אופציונלי | כן |
אם אתם צריכים להשתמש ברמת הגנה אחרת מ-HSM או בתקופת רוטציה בהתאמה אישית, אתם יכולים להשתמש ב-CMEK בלי 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 יוצר מפתחות במהלך יצירת המאגר, שמשמשים לכל פריטי המידע שמאוחסנים. |
מפתח אחד לכל משאב |
| שירות Backup and DR |
|
מפתח אחד לכל משאב |
| גיבוי ל-GKE |
השילוב בין "גיבוי ל-GKE" לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| BigQuery |
Autokey יוצר מפתחות ברירת מחדל למערכי נתונים. טבלאות, מודלים, שאילתות וטבלאות זמניות בתוך מערך נתונים משתמשים במפתח ברירת המחדל של מערך הנתונים. Autokey לא יוצר מפתחות למשאבים של BigQuery, חוץ ממערכי נתונים. כדי להגן על משאבים שלא שייכים למערך נתונים, צריך ליצור מפתחות ברירת מחדל משלכם ברמת הפרויקט או הארגון. |
מפתח אחד לכל משאב |
| Bigtable |
Autokey יוצר מפתחות לאשכולות. Autokey לא יוצר מפתחות למשאבים של Bigtable, חוץ מאשכולות. השילוב בין Bigtable לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או Google Cloud SDK. |
מפתח אחד לכל אשכול |
| Cloud Run |
|
מפתח אחד לכל מיקום בפרויקט |
| Cloud SQL |
Autokey לא יוצר מפתחות למשאבי השילוב בין Cloud SQL לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או ה-API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| Cloud Storage |
אובייקטים בקטגוריית אחסון משתמשים במפתח ברירת המחדל של הקטגוריה. Autokey לא יוצר מפתחות למשאבים של |
מפתח אחד לכל קטגוריה |
| Compute Engine |
תמונות המצב משתמשות במפתח של הדיסק שממנו אתם יוצרים את תמונת המצב.
Autokey לא יוצר מפתחות למשאבי |
מפתח אחד לכל משאב |
| Google Kubernetes Engine |
השילוב בין Google Kubernetes Engine לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או ה-API בארכיטקטורת REST. |
מפתח אחד לכל אשכול |
| Dataflow |
|
מפתח אחד לכל משאב |
| Datastream |
השילוב בין Datastream לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או ה-API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| Document AI |
המפתח שמגן על מעבד צריך להיות באותו מיקום כמו המעבד, חוץ מאשר במספר אזורים: |
מפתח אחד לכל משאב |
| Managed Service for Apache Airflow |
|
מפתח אחד לכל משאב |
| Managed Service for Apache Spark |
|
למשאבים Cluster, SessionTemplate ו-WorkflowTemplate: מפתח אחד לכל משאב למשאבים של Batch ו-Session: מפתח אחד לכל מיקום בפרויקט |
| Memorystore for Redis |
השילוב בין Memorystore for Redis לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או ה-API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| Memorystore for Valkey |
השילוב בין Memorystore for Valkey לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| Migrate to Virtual Machines |
השילוב בין Migrate to Virtual Machines לבין 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 |
|
מפתח אחד לכל משאב |
| Workflows |
השילוב בין Workflows לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או ה-API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
המאמרים הבאים
- כדי ללמוד עוד על אופן הפעולה של Cloud KMS Autokey, ראו סקירה כללית על Autokey.