ב-Cloud Key Management Service (Cloud KMS) מוצגים מדדים לגבי מפתחות ההצפנה שמגנים על הנתונים במנוחה. המדדים האלה מראים איך המשאבים שלכם מוגנים, ואם המפתחות שלכם תואמים לשיטות המומלצות. המדדים מתמקדים בעיקר במפתחות הצפנה בניהול הלקוח (CMEK) שמשמשים להגנה על משאבים בשירותים שמשולבים עם CMEK. במדריך הזה מוסבר איך לצפות במדדי ההצפנה של הפרויקט ואיך להבין את המשמעות שלהם לגבי מצב האבטחה של הארגון.
מידע נוסף על שיטות מומלצות לשימוש במפתחות CMEK כדי להגן על המשאבים ב- Google Cloudזמין במאמר שיטות מומלצות לשימוש במפתחות CMEK.
לפני שמתחילים
-
כדי לקבל את ההרשאות שדרושות לצפייה במדדי הצפנה, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט או במשאב אב:
- Cloud KMS Encryption Dashboard Viewer (
roles/cloudkms.encryptionDashboardViewer) -
כדי לראות את פרטי הכיסוי של CMEK:
צפייה במאגר משאבי ענן (
roles/cloudasset.viewer)
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.
יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
- Cloud KMS Encryption Dashboard Viewer (
אם בארגון שלכם משתמשים במודל ניהול מפתחות מרכזי, עם מפתחות שמאוחסנים בפרויקט מפתחות משותף ומגנים על משאבים בפרויקטים אחרים, אתם צריכים להעניק את התפקיד סוכן שירות ארגוני של Cloud KMS לסוכן השירות הארגוני של Cloud KMS:
gcloud organizations add-iam-policy-binding ORGANIZATION_ID \ --member=serviceAccount:service-org-ORGANIZATION_ID@gcp-sa-cloudkms.iam.gserviceaccount.com \ --role=roles/cloudkms.orgServiceAgentאם מדלגים על השלב הזה, יכול להיות שיוצג מידע חלקי בלוח הבקרה מדדי הצפנה. לדוגמה, כשמציגים מדדי הצפנה עבור PROJECT_A, משאבים ב-PROJECT_B שמוגנים על ידי מפתח ב-PROJECT_A לא ייכללו במדדים.
הצגת מדדי ההצפנה
כדי לראות את מדדי ההצפנה, פועלים לפי השלבים הבאים:
נכנסים לדף Key Management במסוף Google Cloud .
לוחצים על הכרטיסייה סקירה כללית ואז על מדדי הצפנה.
משתמשים בכלי לבחירת פרויקטים כדי לבחור פרויקט. במרכז הבקרה מוצגים מדדי ההצפנה הבאים של משאבים ומפתחות בפרויקט:
- בתרשימים Resources in this project by protection type ו-Resource protection type by service מוצגים מדדי סיכום של כיסוי CMEK.
- בתרשים התאמה לשיטות מומלצות לשימוש מוצגים מדדי סיכום של התאמה, ואפשר גם לראות פרטים על ההתאמה.
אופציונלי: כדי לראות רשימה של מפתחות בכל קטגוריה, לוחצים על הקטע שרוצים לראות את המפתחות שלו. כדי לסנן את רשימת המפתחות, מזינים את מונחי החיפוש בתיבה filter_list Filter ואז מקישים על Enter.
הצגת פרטים על התאמת מילות מפתח
כדי לראות רשימה של מפתחות בפרויקט ולבדוק לאילו שיטות מומלצות הם תואמים, פועלים לפי השלבים הבאים:
בדף Encryption metrics (מדדי הצפנה), מאתרים את התרשים Alignment to key usage recommended practices (התאמה לשיטות מומלצות לשימוש במפתחות).
אופציונלי: כדי להתמקד רק במפתחות שנוצרו על ידי Cloud KMS Autokey, לוחצים על הכרטיסייה Cloud KMS (Autokey). כדי להתמקד רק במפתחות שנוצרו באופן ידני, לוחצים על הכרטיסייה Cloud KMS (ידני).
כדי לראות רשימה של מפתחות ולבדוק אם הם תואמים לכל שיטת עבודה מומלצת, לוחצים על הקטע שמייצג את הקטגוריה ואז על View (הצגה).
בדף התאמה לשיטות המומלצות לשימוש במפתחות מפורטים מפתחות Cloud KMS בפרויקט שנבחר, ומוצג אם כל אחד מהם מותאם או לא מותאם לכל המלצה. מידע נוסף על המשמעות של התאמה או אי-התאמה של מפתח להמלצה זמין בקטע התאמת מפתחות במאמר הזה.
אופציונלי: כדי לסנן את רשימת המפתחות, מזינים את מונחי החיפוש בתיבה filter_list Filter ואז מקישים על Enter. לדוגמה, אפשר לסנן את הרשימה כדי להציג רק מפתחות שמותאמים להמלצה בנושא רמת הפירוט.
הסבר על מדדי הצפנה
לוח הבקרה של מדדי ההצפנה משתמש בשירות מאגר משאבי ענן כדי לאסוף מידע על המשאבים והמפתחות של Cloud KMS. בלוח הבקרה מחושבים מדדים לפי דרישה באמצעות הנתונים הזמינים העדכניים ביותר.
במרכז הבקרה מוצגות שתי קטגוריות עיקריות של מדדים: כיסוי CMEK והתאמה מרכזית. שני המדדים מציגים תצוגת סיכום עם מידע מצטבר ותצוגה מפורטת עם רשימת משאבים או מפתחות בטבלה.
היקף הכיסוי של CMEK
בטבלאות Resources in this project by protection type (משאבים בפרויקט הזה לפי סוג ההגנה) ו-Resource protection type by service (סוג ההגנה על המשאב לפי שירות) מוצגים מדדים של כיסוי CMEK, שמראים כמה מהמשאבים שלכם מוגנים על ידי CMEK. המדד הזה מתייחס למשאבים שנתמכים בהם שילוב של CMEK ומעקב אחרי מפתחות Cloud KMS. המשאבים מחולקים לקטגוריות הבאות:
- Google Managed Encryption: משאבים שמוגנים באמצעות הצפנת ברירת המחדל של Google.
- Cloud KMS (ידני): משאבים שמוגנים על ידי CMEK שאתם יוצרים ומנהלים באופן ידני.
- Cloud KMS (Autokey): משאבים שמוגנים על ידי CMEK שהוקצה והוגדר על ידי שירות Autokey.
מדדי הכיסוי של CMEK מוצגים עבור הפרויקט כולו, ומפורטים לפי השירות שמשויך לכל אחד מהמשאבים המוגנים. אתם יכולים להשתמש במידע הזה כדי להעריך כמה מהמשאבים בפרויקט שנבחר משתמשים בהצפנה שמוגדרת כברירת מחדל ב-Google, במקום להשתמש ב-CMEK.
רשימה של סוגי המשאבים הנתמכים זמינה במאמר סוגי משאבים במעקב.
יישור מקשים
מדדי ההתאמה למפתחות בתרשים התאמה לשיטות מומלצות לשימוש במפתחות מראים אם מפתחות Cloud KMS שלכם תואמים לשיטות המומלצות הבאות לאבטחה:
- תקופת רוטציה: מוגדרת למפתח תקופת רוטציה מתאימה.
- גרנולריות: המפתח מגן על משאבים שנמצאים בפרויקט אחד ושייכים לשירות אחד.
- הפרדת תפקידים: רק לחשבונות שירות יש הרשאה להצפין ולפענח באמצעות המפתח.
- מיקום: המפתח מגן רק על משאבים שנמצאים באותו מיקום בענן.
מדדי התאמת המפתחות כוללים את כל מפתחות ההצפנה הסימטרית של Cloud KMS בפרויקט שנבחר, גם אם הם לא משמשים להגנה על משאבים בשירות שמשולב עם CMEK. המדדים האלה מוערכים לגבי מפתחות, ולא לגבי גרסאות של מפתחות. לדוגמה, מפתח שאין לו גרסאות פעילות יכול עדיין להופיע כמותאם לכל אחת מהשיטות המומלצות האלה או לכולן.
בקטעים הבאים מוסבר בהרחבה על כל אחת מהשיטות האלה.
רמת פירוט
גרנולריות של מפתח מתייחסת להיקף ולטווח של השימוש המיועד במפתח. המפתחות יכולים להיות מפורטים מאוד ולהגן רק על משאב יחיד, או פחות מפורטים ולהגן על הרבה משאבים. שימוש במפתחות עם רמת פירוט נמוכה מגדיל את ההשפעה הפוטנציאלית של אירועי אבטחה, כולל גישה לא מורשית ואובדן נתונים מקרי.
באופן כללי, מומלץ להשתמש באסטרטגיית הגרנולריות הבאה:
- כל מפתח מגן על משאבים במיקום אחד – לדוגמה,
us-central1. - כל מפתח מגן על משאבים בשירות או במוצר יחיד – לדוגמה, BigQuery.
- כל מפתח מגן על משאבים ב Google Cloud פרויקט אחד.
יכול להיות שההמלצה הזו לא תהיה אסטרטגיית הגרנולריות האידיאלית לארגון שלכם. ברוב הארגונים, האסטרטגיה הזו מספקת איזון טוב בין התקורה של תחזוקת מפתחות רבים ברמת פירוט גבוהה לבין הסיכונים הפוטנציאליים של שימוש במפתחות ברמת פירוט נמוכה יותר שמשותפים בין פרויקטים, שירותים או משאבים רבים.
מפתחות שנוצרו באמצעות Cloud KMS Autokey עומדים בהמלצה הזו.
כל מפתח בפרויקט נחשב תואם להמלצה הזו אם כל המשאבים שהוא מגן עליהם נמצאים באותו מיקום, שירות ופרויקט. מפתח נחשב לא תואם להמלצה הזו אם המשאבים שהוא מגן עליהם נמצאים בשני מיקומים, שירותים או פרויקטים או יותר.
אם המפתחות שלכם לא תואמים להמלצה הזו, כדאי לשקול אם כדאי לארגון שלכם לשנות את אסטרטגיית הגרנולריות של המפתחות. מידע נוסף על שיטות מומלצות לגרנולריות של מפתחות מופיע במאמר בחירת אסטרטגיה לגרנולריות של מפתחות.
מיקום
ברוב המקרים, מפתחות Cloud KMS שמשמשים עם שירותים שמשולבים ב-CMEK צריכים להיות באותו Google Cloud אזור או באותו מיקום שכולל מספר אזורים שבו נמצאים המשאבים שהם מגנים עליהם. עם זאת, יש כמה שירותים שמאפשרים חריגים לכלל הזה.
כל מפתח בפרויקט נחשב מתאים להמלצה הזו אם כל המשאבים שהוא מגן עליהם נמצאים באותו מיקום כמו המפתח – לדוגמה, מפתח ב-us-central1 שמגן על משאבים ב-us-central1. מפתחות אזוריים יכולים להגן על משאבים של תחום מוגדר באותו אזור – לדוגמה, מפתח ב-us-central1 שמגן על משאבים ב-us-central1a.
מפתח נחשב לא תואם להמלצה הזו אם הוא מגן על משאב באזור אחר או במספר אזורים – לדוגמה, מפתח באזור us שכולל מספר אזורים ומגן על דיסק של Compute Engine באזור us-central1.
אם המפתחות לא תואמים להמלצה הזו, כדאי להעביר או להחליף את המשאבים או המפתחות כך שיהיו באותו מיקום. מידע נוסף על מיקומים זמין במאמר מיקומים ב-Cloud KMS.
סיבוב
רוטציה קבועה של המפתחות היא היבט חשוב באבטחת מידע. לדוגמה, חלק מהתקנים מחייבים לסובב את המפתחות לפי לוח זמנים מסוים. יכול להיות שיהיה צורך לבצע רוטציה של מפתחות שמגנים על עומסי עבודה רגישים בתדירות גבוהה יותר. Cloud KMS מאפשר להגדיר רוטציית מפתחות אוטומטית למפתחות שלכם כדי לוודא שהלוח זמנים שבחרתם מתבצע.
כל מפתח בפרויקט נחשב מתאים להמלצה הזו אם מוגדר לו לוח זמנים להחלפה. מפתח נחשב לא מיושר אם הוא לא מוגדר לרוטציית מפתחות אוטומטית.
כדי להפעיל את הרוטציה האוטומטית, אפשר לבצע אחת מהפעולות הבאות:
- יצירה ידנית של מפתח חדש עם לוח זמנים מותאם אישית להחלפה.
- שימוש ב-Cloud KMS Autokey כשיוצרים משאב חדש. למפתחות שנוצרו על ידי Cloud KMS Autokey יש תקופת רוטציה של שנה כברירת מחדל, אבל אפשר לשנות את תקופת הרוטציה אחרי יצירת המפתח.
- עדכון מפתח קיים כדי להוסיף לוח זמנים להחלפה.
הפרדת תפקידים
הפרדת תפקידים היא שיטת אבטחה שמטרתה למנוע מתן הרשאות רבות מדי למשתמשים או לגורמים אחרים. בהקשר של Cloud KMS ואינטגרציות של CMEK, המשמעות היא שהמשתמשים שמנהלים את המפתחות של Cloud KMS לא צריכים לקבל הרשאות להשתמש במפתחות האלה, והגורמים הראשיים שמשתמשים במפתחות כדי להצפין ולפענח את המשאבים לא צריכים לקבל הרשאות אחרות במפתחות.
כל מפתח בפרויקט נחשב תואם להמלצה הזו אם שני התנאים הבאים מתקיימים:
- חשבון השירות של המשאב המוגן הוא החשבון היחיד עם ההרשאות
cloudkms.cryptoKeyVersions.useToEncryptו-cloudkms.cryptoKeyVersions.useToDecryptבמפתח. - לחשבון השירות של המשאב המוגן אין תפקיד שמעניק הרשאות ניהול מפתחות במפתח, כולל
roles/cloudkms.admin,roles/editorו-roles/owner.
מפתח נחשב לא מיושר אם לחשבון השירות יש הרשאות ניהול או אם לחשבון משתמש אחר יש הרשאות הצפנה או פענוח.
אם המפתחות לא תואמים להמלצה הזו, כדאי לבדוק את תפקידי ה-IAM וההרשאות במפתחות ובמשאבים אחרים של Cloud KMS, ולהסיר את ההרשאות והתפקידים שלא נדרשים. מידע נוסף על תפקידים ב-Cloud KMS וההרשאות שכלולים בהם מופיע במאמר הרשאות ותפקידים. מידע נוסף על צפייה בתפקידים ב-IAM והסרתם במשאבי Cloud KMS זמין במאמר בקרת גישה באמצעות IAM.
מגבלות
אלו המגבלות שחלות על מרכז הבקרה מדדי הצפנה:
- במרכז הבקרה מוצגים מדדים של פרויקט אחד בכל פעם.
- לוח הבקרה מוגבל ל-10,000 משאבים או מפתחות לכל פרויקט. אם הפרויקט שלכם מכיל יותר מ-10,000 מפתחות, או אם המפתחות בפרויקט מגנים על יותר מ-10,000 משאבים, יוצגו רק מדדים חלקיים.
- לוח הבקרה מתבסס על נתונים משירות מאגר משאבי הענן. אם חלק מהנתונים במאגר משאבי הענן לא עדכניים, יכול להיות שיוצג בלוח הבקרה מידע לא מדויק או חלקי.
- בלוח הבקרה נלקחים בחשבון רק מפתחות סימטריים לצורך התאמת מפתחות וכיסוי CMEK.
- בלוח הבקרה מוצגים רק משאבים שתומכים במעקב אחר השימוש במפתחות.
- מדדי התאמת המפתחות לא מבחינים בין מפתחות שנמצאים בשימוש פעיל כמפתחות CMEK להגנה על משאבים שאפשר לעקוב אחריהם, בין מפתחות שנמצאים בשימוש פעיל לתרחישי שימוש אחרים ובין מפתחות שאין להם גרסאות פעילות. לדוגמה, נתוני התאמת המפתחות עשויים לכלול מפתחות שמשמשים לאפליקציות בהתאמה אישית.
- כשנתוני התאמת המפתחות כוללים מפתחות שמגנים על משאבים שלא ניתן לעקוב אחריהם ועל אפליקציות בהתאמה אישית, יכול להיות שפרטי ההתאמה של המפתחות האלה לא יהיו מדויקים. לדוגמה, מפתח שמשמש בכמה אפליקציות מותאמות אישית בכמה פרויקטים עשוי להופיע כתואם להמלצות לגבי רמת הפירוט של המפתח, גם אם הוא לא תואם.