באמצעות 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. המשתמשים הבאים משתתפים בתהליך:
- מנהל מערכת
- האדמין הוא משתמש שאחראי על ניהול האבטחה ברמת התיקייה או הארגון. צינור עיבוד נתונים של 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 בכל פרויקט בתיקייה הזו יכולים להפעיל יצירה של מפתחות Multi-tenant Cloud HSM על פי דרישה. הוראות מלאות להגדרה של Cloud KMS Autokey
הפעלת Autokey עם אחסון מפתחות באותו פרויקט
כדי להשתמש ב-Autokey עם אחסון מפתחות באותו פרויקט, אדמין צריך לבצע את משימות ההגדרה החד-פעמיות הבאות:
- מפעילים את Autokey עם אחסון מפתחות באותו פרויקט, בפרויקט או בתיקייה.
- מפעילים את Cloud KMS API בפרויקט או בפרויקטים שבתיקייה.
כשמפעילים את Autokey עם אחסון מפתחות באותו פרויקט, סוכן השירות של Cloud KMS נוצר בשבילכם לפי הצורך. אתם לא צריכים ליצור את סוכן השירות באופן ידני. כל משתמש עם הרשאות ליצירת משאב שתואם ל-Autokey יכול לבקש מפתח חדש לפי דרישה. הוראות מלאות להגדרה של Cloud KMS Autokey
מפתחים שמשתמשים ב-Cloud KMS Autokey
אחרי שמפעילים את Autokey בפרויקט, המפתחים וצינורות עיבוד הנתונים של IaC יכולים ליצור משאבים שמוגנים באמצעות מפתחות שנוצרו בשבילם על פי דרישה. ההגדרה הזו חלה גם על פרויקטים בתיקייה שבה מופעל 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-RESOURCE_TYPE_DESCRIPTOR_NAME-RANDOM_HEX - ייצוא מפתחות: כמו כל המפתחות של Cloud KMS, אי אפשר לייצא מפתחות שנוצרו באמצעות Autokey.
- מעקב אחרי מפתחות: כמו כל המפתחות של Cloud KMS שמשמשים בשירותים משולבי CMEK שתואמים למעקב אחרי מפתחות, המערכת עוקבת אחרי המפתחות שנוצרו על ידי Autokey במרכז הבקרה של Cloud KMS.
שליטה בשימוש ב-Autokey
אתם יכולים לקבוע איך ישתמשו ב-Autokey בארגון שלכם באמצעות אמצעי הבקרה הבאים:
- הגדרת Autokey: מפעילים את Autokey בתיקיות או בפרויקטים שבהם רוצים להשתמש בו. הגדרות Autokey עוברות בירושה למשאבי צאצא, אבל אפשר לשנות אותן באמצעות הגדרות ברמה נמוכה יותר. לדוגמה, הגדרת Autokey בפרויקט מקבלת קדימות על פני ההגדרה של תיקיית ההורה. כך אתם יכולים לשלוט ב-Autokey מלמטה למעלה. מידע נוסף על הפעלה והשבתה של Autokey מופיע במאמר הפעלת Cloud KMS Autokey.
- IAM: אתם יכולים להשתמש בהקצאות של תפקידי IAM ובכללי מדיניות דחייה כדי לקבוע מי יכול ליצור ולעדכן הגדרות של Autokey, ומי יכול ליצור משאבים שמוגנים באמצעות Autokey. אפשר להגדיר את אמצעי הבקרה האלה של 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 |
השילוב בין "גיבוי ל-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, אדמין צריך להפעיל את Cloud KMS Autokey.
- כדי להשתמש ב-Cloud KMS Autokey אחרי שהפעלתם אותו, אתם יכולים ליצור משאבים שמוגנים באמצעות CMEK באמצעות Autokey.
- מידע ולמידה על שיטות מומלצות לשימוש ב-CMEK