הפרדת תפקידים היא קונספט שמטרתו לוודא שלגורם מרכזי אחד אין את כל ההרשאות הנדרשות כדי לבצע פעולה זדונית. ב-Cloud Key Management Service, הפעולה יכולה להיות שימוש במפתח כדי לגשת לנתונים ולפענח אותם, כשאין למשתמש סיבה מוצדקת לגשת לנתונים האלה.
הפרדת תפקידים היא אמצעי בקרה עסקי שמשמש בדרך כלל בארגונים גדולים יותר, ומטרתו לעזור להימנע מאירועי אבטחה או פרטיות ושגיאות. זו נחשבת שיטה מומלצת.
ב-Cloud KMS, הפרדת תפקידים דורשת הבחנה ברורה בין התפקידים הבאים:
- מנהלי מפתחות: גורמים ראשיים שמורשים לנהל את מחזור החיים של המפתחות, כולל יצירה, מחיקה, רוטציה ושינויים במצב – לדוגמה, משתמשים עם התפקיד Cloud KMS Admin.
- משתמשי מפתח: גורמים ראשיים שמורשים להשתמש במפתחות, כולל הצפנה, פענוח, חתימה או אימות חתימה – לדוגמה, משתמשים עם התפקיד 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: אפשר להשתמש בלוח הבקרה מדדי הצפנה כדי לוודא שההפרדה בין התפקידים בארגון תואמת לשיטות המומלצות.