הפרדת תפקידים היא קונספט שמטרתו לוודא שלחשבון משתמש אחד אין את כל ההרשאות הנדרשות להשלמת פעולה זדונית. ב-Cloud Key Management Service, יכולה להיות פעולה כזו כמו שימוש במפתח כדי לגשת לנתונים ולפענח אותם, כשאין למשתמש סיבה מוצדקת לגשת לנתונים האלה.
הפרדת תפקידים היא אמצעי בקרה עסקי שמשמש בדרך כלל בארגונים גדולים יותר, ומטרתו למנוע אירועי אבטחה או פרטיות ושגיאות. זו שיטה מומלצת.
ב-Cloud KMS, הפרדת תפקידים מחייבת הבחנה ברורה בין התפקידים הבאים:
- אדמינים של מפתחות: גורמים ראשיים שמורשים לנהל את מחזור החיים של המפתחות, כולל יצירה, מחיקה, רוטציה ושינויים במצב – לדוגמה, משתמשים עם התפקיד אדמין של Cloud KMS.
- משתמש במפתח: גורמים ראשיים שמורשים להשתמש במפתחות, כולל הצפנה, פענוח, חתימה או אימות חתימה – לדוגמה, משתמשים עם התפקיד Cloud KMS CryptoKey Encrypter/Decrypter.
כשמשתמשים במפתחות Cloud KMS כמפתחות הצפנה בניהול הלקוח, מומלץ שחשבון השירות יהיה הגורם היחיד שמורשה להשתמש במפתח להצפנה ולפענוח. מידע נוסף על האופן שבו שילובי CMEK מטפלים בגישה למשאבים זמין במאמר שירותים עם שילובי CMEK מטפלים בגישה למשאבים.
כדי לשמור על הפרדת תפקידים, לא מומלץ להעניק לישויות מורשות תפקידים בסיסיים רחבים כמו בעלים (roles/owner), שכולל הרשאות ניהול והרשאות קריפטוגרפיות. אתם יכולים להשתמש בלוח הבקרה מדדי הצפנה כדי לזהות מפתחות שלא עומדים בהמלצות להפרדת תפקידים. מידע נוסף זמין במאמר הצגת מדדי הצפנה.
מידע נוסף על שימוש בטוח בתפקידים ב-IAM זמין במאמר שימוש מאובטח ב-IAM.
מודלים של ניהול מפתחות
Cloud KMS תומך בשני מודלים עיקריים לאכיפת הפרדת סמכויות: ניהול מפתחות מרכזי וניהול מפתחות בהרשאה. אפשר להשתמש במודלים האלה בנפרד או בשילוב. לדוגמה, ארגון יכול לבחור להשתמש במודל מרכזי לניהול מפתחות בסביבות ייצור, ובמודל ייעודי לניהול מפתחות בסביבות נמוכות יותר שמשמשות לפיתוח ולבדיקה.
בטבלה הבאה מוצגת השוואה בין מודלים של ניהול מפתחות מרכזי וניהול מפתחות מוקצה, כדי לעזור לכם להחליט מה הכי מתאים לצרכים שלכם.
| אזור | מרכזי (ברמת התיקייה) | הועברה לטיפול של מישהו אחר (ברמת הפרויקט) |
|---|---|---|
| מיקום המפתח | מאוחסן בפרויקט מפתח ייעודי, בדרך כלל לכל תיקייה. | מאוחסן באותו פרויקט שבו נמצא המשאב שהמפתח מגן עליו. |
| שיטת ההפרדה | גבולות הפרויקט: המפתחות והמשאבים שהם מגנים עליהם נמצאים בפרויקטים שונים. | תפקידים נפרדים: הפרדה קפדנית של תפקידי IAM, כך שאף חשבון משתמש לא יכול גם לנהל מפתח וגם להשתמש בו. |
| תרבות עסקית | האפשרות הזו מתאימה לארגונים עם רגולציה מחמירה, שבהם יש צוותי אבטחה או קריפטו מרכזיים ייעודיים. | האפשרות הזו מתאימה לארגונים שנותנים עדיפות לגמישות של המפתחים ולסמכות מבוזרת. |
| הגורמים העיקריים | בידוד גבוה ופיקוח מרכזי. | ניהול מכסות פשוט יותר ופחות עומס תפעולי. |
ניהול מפתחות שהועברו לטיפול
מודל ניהול המפתחות המוקצה או 'באותו פרויקט' מומלץ לארגונים שנותנים עדיפות לגמישות של המפתחים ומעוניינים לצמצם את 'הלולאה' בין צוותי האבטחה המרכזיים לבין המפתחים.
במודל ההרשאה, מפתחות ה-CMEK ומפתחות אחרים מאוחסנים באותו פרויקט שבו מאוחסנים המשאבים שהם מגנים עליהם. כדי לאכוף הפרדת תפקידים בניהול מפתחות שהוקצו, צריך להקפיד על הפרדה בין תפקידי IAM.
אתם יכולים להפעיל את Autokey לפרויקטים (תצוגה מקדימה) בפרויקט או בתיקייה כדי לאפשר יצירה אוטומטית של מפתחות באמצעות מודל ניהול המפתחות המוקצה. מידע נוסף מופיע במאמר בנושא הפעלת Autokey לניהול מפתחות בהרשאת גישה.
ניהול מפתחות מרכזי
מודל ניהול המפתחות המרכזי או 'הפרויקט הייעודי' מומלץ לארגונים עם צוותי אבטחה מרכזיים או לארגונים שנדרשת בהם הפרדה קפדנית של חומר המפתח מסביבות האפליקציה.
במודל המרכזי, מפתחות ה-CMEK ומפתחות אחרים מאוחסנים בפרויקטים ייעודיים של מפתחות, בנפרד מהמשאבים שהם מגנים עליהם. בדרך כלל, המשמעות היא שלכל תיקייה יש פרויקט מפתחות ייעודי משלה שמכיל מפתחות שמגנים על משאבים בכל התיקייה. פרויקט המפתחות הייעודי הזה מנוהל על ידי צוות אבטחה מרכזי, שיש לו הרשאות ניהול מפתחות בפרויקט המפתחות, אבל אין לו גישה לפרויקטים שמכילים את המשאבים שמוגנים על ידי המפתחות האלה.
אתם יכולים להפעיל את התכונה Autokey בתיקייה כדי לאפשר יצירת מפתחות אוטומטית באמצעות מודל ניהול המפתחות המרכזי. מידע נוסף מופיע במאמר בנושא הגדרת Autokey לניהול מפתחות מרכזי.
אוטומציה ומעקב אחרי תאימות
Cloud de Confiance מספק את הכלים הבאים לאוטומציה ולניטור של גבולות האבטחה:
- Cloud KMS Autokey: Autokey תומך במודלים של ניהול מפתחות ריכוזי ומודלים של ניהול מפתחות בהרשאת גישה (גרסת Preview). בשני המקרים, המערכת מבצעת אוטומטית הפרדה בין תחומי האחריות על ידי הקצאת התפקיד של שימוש במפתח לסוכן השירות הנדרש, ולא לאדם שמבקש את המפתח. Autokey מיועד לתמוך בצינורות (pipelines) של תשתית כקוד (infrastructure-as-code) שלא דורשים הרשאות מורחבות ליצירת מפתחות.
- Security Command Center: מעקב אחרי ממצאים של הפרדת תפקידים ב-KMS כדי לזהות כל ישות מורשית, כולל Project Owner או חשבון שירות של Google, שיש לו הרשאות אדמיניסטרטיביות והרשאות קריפטוגרפיות במפתח יחיד.
מדדי הצפנת CMEK: אפשר להשתמש בלוח הבקרה כדי לוודא שההפרדה בין התפקידים בארגון מתבצעת בהתאם לשיטות המומלצות.