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