Cloud KMS Autokey מפשט את התהליך של יצירה ושימוש במפתחות הצפנה בניהול הלקוח (CMEK) באמצעות אוטומציה של הקצאת משאבים והקצאת הרשאות. ב-Autokey, אוספי מפתחות ומפתחות נוצרים על פי דרישה. חשבונות שירות שמשתמשים במפתחות כדי להצפין ולפענח משאבים נוצרים ומקבלים תפקידים של ניהול זהויות והרשאות גישה (IAM) לפי הצורך. לאדמינים של Cloud KMS יש שליטה מלאה במפתחות שנוצרו על ידי Autokey, והם יכולים לראות אותם בלי לתכנן מראש וליצור כל משאב. השימוש ב-Autokey פשוט יותר מאשר הקצאת מפתחות באופן עצמאי, והוא הבחירה המומלצת אם המפתחות שנוצרו על ידי Autokey עומדים בכל הדרישות שלכם.
שימוש במפתחות שנוצרו על ידי Autokey יכול לעזור לכם לעמוד באופן עקבי בתקנים בתעשייה ובשיטות המומלצות לאבטחת נתונים, כולל רמת ההגנה של Cloud HSM מרובה הדיירים, הפרדת תפקידים, רוטציית מפתחות, מיקום ומפרט מפתחות. Autokey יוצר מפתחות שעומדים בהנחיות כלליות ובהנחיות ספציפיות לסוג המשאב עבור שירותיםCloud de Confiance שמשולבים עם Cloud KMS Autokey. אחרי שהמפתחות נוצרים, הם פועלים בדיוק כמו מפתחות אחרים של Cloud HSM עם אותן הגדרות.
כשמשתמשים ב-Autokey, ההרשאות שנדרשות כדי לבקש מפתח חדש הן מינימליות, והן כלולות בתפקידי ברירת המחדל שמעניקים הרשאות ליצירת משאבים. המשמעות היא שהמפתחים שלכם וצינורות התשתית כקוד (IaC) לא צריכים הרשאות מורחבות. Autokey מפשט את השימוש ב-Terraform לניהול מפתחות ותומך בעיקרון של הרשאות מינימליות.
אפשר להשתמש ב-Autokey עם אחסון מפתחות בפרויקט ייעודי (שנקרא בעבר ניהול מפתחות מרכזי) או עם אחסון מפתחות באותו פרויקט (שנקרא בעבר ניהול מפתחות בהרשאת משנה). כדי להשתמש ב-Autokey עם אחסון מפתחות בפרויקט ייעודי, צריך משאב מסוג 'ארגון' שמכיל משאב מסוג 'תיקייה'. כשמשתמשים באחסון מפתחות בפרויקט ייעודי, מפעילים את Autokey לפרויקטים בתיקייה, והמפתחות שנוצרים על ידי Autokey נוצרים בפרויקט המפתחות הייעודי של אותה תיקייה. כשמשתמשים באחסון מפתחות באותו פרויקט, מפעילים את Autokey בתיקייה או בפרויקט כדי לאפשר ל-Autokey ליצור מפתחות באותו פרויקט שבו נמצאים המשאבים שהמפתחות מגנים עליהם.
מידע נוסף על משאבי ארגון ותיקיות זמין במאמר היררכיית המשאבים.
תכונת המפתח האוטומטי של Cloud KMS זמינה בכל Cloud de Confiance המיקומים שבהם Cloud HSM זמין. מידע נוסף על מיקומים ב-Cloud KMS מופיע במאמר מיקומים ב-Cloud KMS. אין עלות נוספת לשימוש ב-Cloud KMS Autokey. התמחור של מפתחות שנוצרו באמצעות Autokey זהה לתמחור של כל מפתח אחר ב-Cloud HSM. מידע נוסף על התמחור זמין במאמר תמחור של Cloud Key Management Service.
איך Autokey עובד
בקטע הזה מוסבר איך פועל Cloud KMS Autokey. המשתמשים עם התפקידים הבאים משתתפים בתהליך הזה:
- מנהל מערכת
- האדמין הוא משתמש שאחראי על ניהול האבטחה ברמת התיקייה או הארגון. פייפליין IaC עם הרשאות גבוהות יכול לשמש כאדמין.
- מפתח
- מפתח האפליקציה הוא משתמש שאחראי ליצירת משאבים באמצעות Cloud KMS Autokey. צינורות IaC יכולים לשמש כמפתח.
- אדמין של Cloud KMS
- אדמין Cloud KMS הוא משתמש שאחראי לניהול משאבי Cloud KMS. התפקיד הזה כולל פחות אחריות כשמשתמשים ב-Autokey מאשר כשמשתמשים במפתחות שנוצרו באופן ידני.
גם נציגי השירות הבאים משתתפים בתהליך הזה:
- סוכן שירות של 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 בכל פרויקט בתיקייה הזו יוכלו להפעיל יצירה של מפתח HSM בענן עם ריבוי דיירים על פי דרישה. הוראות מלאות להגדרה של Cloud KMS Autokey מופיעות במאמר הפעלת Cloud KMS Autokey.
הפעלת Autokey עם אחסון מפתחות באותו פרויקט
כדי להשתמש ב-Autokey עם אחסון מפתחות באותו פרויקט, אדמין צריך להשלים את משימות ההגדרה החד-פעמיות הבאות:
- מפעילים את Autokey עם אחסון מפתחות באותו פרויקט בפרויקט או בתיקייה.
- מפעילים את Cloud KMS API בפרויקט או בפרויקטים בתיקייה.
כשמפעילים את התכונה Autokey עם אחסון מפתחות באותו פרויקט, סוכן השירות של Cloud KMS נוצר בשבילכם כשצריך. לא צריך ליצור את סוכן השירות באופן ידני. כל משתמש עם הרשאות ליצירת משאב שתואם ל-Autokey יכול לבקש מפתח חדש על פי דרישה. הוראות מלאות להגדרה של Cloud KMS Autokey מופיעות במאמר הפעלת Cloud KMS Autokey.
מפתחים של Autokey משתמשים ב-Cloud KMS Autokey
אחרי שמפעילים את Autokey בפרויקט, מפתחים וצינורות IaC יכולים ליצור משאבים שמוגנים באמצעות מפתחות שנוצרו עבורם לפי דרישה. זה רלוונטי גם לפרויקטים בתיקייה שבה מופעלת התכונה 'Autokey' עם אחסון מפתחות ייעודי לפרויקט, וגם לפרויקטים שבהם מופעלת התכונה 'Autokey' עם אחסון מפתחות באותו פרויקט. הפרטים של תהליך יצירת המשאב תלויים במשאב שיוצרים, אבל התהליך מתבצע לפי השלבים הבאים:
המפתח מתחיל ליצור משאב בשירות תואם Cloud de Confiance. במהלך יצירת משאב, המפתח מבקש מפתח חדש מסוכן השירות של 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-RESOURCE_TYPE_DESCRIPTOR_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 יוצרת מפתחות במהלך יצירת המאגר, והמפתחות האלה משמשים לכל הארטיפקטים המאוחסנים. |
מפתח אחד לכל משאב |
| שירות Backup and DR |
|
מפתח אחד לכל משאב |
| גיבוי ל-GKE |
השילוב בין Backup for 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 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 |
|
מפתח אחד לכל משאב |
| Datastream |
השילוב בין Datastream לבין Cloud KMS Autokey זמין רק למשאבים שנוצרו באמצעות Terraform או API בארכיטקטורת REST. |
מפתח אחד לכל משאב |
| 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, אדמין צריך להפעיל את Cloud KMS Autokey.
- כדי להשתמש ב-Cloud KMS Autokey אחרי שמפעילים אותו, מפתחים יכולים ליצור משאבים שמוגנים באמצעות CMEK באמצעות Autokey.
- מידע ולמידה על שיטות מומלצות לשימוש ב-CMEK