כשמפעילים את Cloud Key Management Service (Cloud KMS) עם Cloud External Key Manager (Cloud EKM), אפשר להשתמש במפתחות שמנוהלים על ידי שותף חיצוני לניהול מפתחות כדי להגן על הנתונים ב-Cloud de Confiance by S3NS. במאמר הזה מתוארות ארכיטקטורות ל Cloud de Confiance by S3NS לקוחות שרוצים לפרוס שירות חיצוני לניהול מפתחות (EKM) עם זמינות גבוהה באמצעות Cloud KMS ו-Cloud EKM.
השימוש ב-Cloud EKM עם שירות EKM כרוך בסיכון מובנה שנובע מהפשרה בין מהימנות של עומסי עבודה בענן לבין אמצעי בקרה להגנה על נתונים. הצפנת נתונים במנוחה בענן באמצעות מפתחות הצפנה מחוץ לענן מוסיפה סיכוני כשל חדשים, שעלולים לגרום לכך ש Cloud de Confiance הנתונים בשירותים לא יהיו נגישים. כדי לטפל בסיכונים האלה, צריך לשלב זמינות גבוהה וסובלנות לתקלות בארכיטקטורה של Cloud EKM.
סקירה כללית
שירות Cloud EKM מאפשר להשתמש בחומר מפתח שנשאר מחוץ ל- Cloud de Confiance כדי לשלוט בגישה לנתונים שמאוחסנים בשירותים Cloud de Confiance נתמכים. מפתחות Cloud EKM הם מפתחות הצפנה בניהול הלקוח (CMEK).
בעזרת Cloud EKM אפשר ליצור ולנהל משאבי מפתחות של Cloud KMS באמצעות רמות ההגנה EXTERNAL ו-EXTERNAL_VPC. כשמפעילים את Cloud EKM, כל בקשה לפעולה קריפטוגרפית גורמת לפעולה קריפטוגרפית במפתח החיצוני. ההצלחה של פעולת הבקשה הראשונית תלויה באופן קריטי בתוצאה של פעולת ההצפנה במפתח החיצוני.
בקשות Cloud KMS מבצעות פעולות על מפתחות חיצוניים באמצעות API ייעודי שמשולב עם מערכת ניהול המפתחות החיצונית שלכם. במאמר הזה, שירות שמספק את ה-API הזה נקרא שירות EKM.
אם שירות EKM לא זמין, יכול להיות שפעולות קריאה וכתיבה ממישורי הנתונים של שירותים משולבים של Cloud de Confiance ייכשלו. הכשלים האלה מופיעים באופן דומה לכשלים שמופיעים כשמפתח Cloud KMS שתלוי בו נמצא במצב לא שמיש, למשל כשהוא מושבת. בהודעת השגיאה מפורטים מקור השגיאה ודרכי פעולה. בנוסף, יומני ביקורת של Cloud KMS על גישה לנתונים כוללים תיעוד של הודעות השגיאה האלה, יחד עם סוגי שגיאות תיאוריים. מידע נוסף זמין במאמר הפניה לשגיאות ב-Cloud EKM.
שיטות מומלצות לארכיטקטורות של Cloud EKM
בספר של Google בנושא Site Reliability Engineering מתוארות שיטות מומלצות שיעזרו לכם לפתח ולתחזק מערכות אמינות. בקטע הזה מתוארות חלק מהשיטות האלה בהקשר של האופן שבו שירות ה-EKM שלכם משתלב עם Cloud de Confiance. השיטות המומלצות הבאות רלוונטיות לדוגמאות לארכיטקטורות של Cloud EKM:
- הגדרת קישוריות אמינה לרשת עם זמן אחזור נמוך
- הפעלת זמינות גבוהה
- זיהוי מהיר של כשלים וצמצום ההשפעה שלהם
הגדרת קישוריות אמינה לרשת עם זמן אחזור נמוך
Cloud KMS מתחבר לשירותי EKM באמצעות רשת של ענן וירטואלי פרטי (VPC) או האינטרנט. בפתרונות VPC נעשה לעיתים קרובות שימוש בקישוריות היברידית כדי לארח את שירות ה-EKM במרכז נתונים מקומי. החיבור ביןCloud de Confiance לבין מרכז הנתונים צריך להיות מהיר ואמין. כשמשתמשים באינטרנט, צריך לוודא שיש נגישות יציבה ורציפה ופתרון DNS מהיר ואמין. מנקודת המבט של Cloud de Confiance, כל שיבוש עלול לגרום לחוסר זמינות של שירות ה-EKM ולחוסר אפשרות לגשת לנתונים שמוגנים על ידי EKM.
כשמישור הנתונים של Cloud de Confiance שירות מסוים מתקשר עם שירות ה-EKM, לכל קריאה שקשורה לשירות ה-EKM יש תקופת זמן קצובה מוגדרת (150 אלפיות השנייה). הזמן הקצוב לתפוגה נמדד משירות Cloud KMS במיקום Cloud de Confiance של מפתח Cloud KMS. אםCloud de Confiance המיקום הוא אזור מרובה, פסק הזמן מתחיל באזור שבו Cloud KMS מקבל את הבקשה, שהוא בדרך כלל המיקום שבו התרחשה הפעולה במשאב הנתונים שמוגן באמצעות CMEK. הזמן הקצוב לתפוגה הזה מספיק כדי לאפשר לשירות EKM לטפל בבקשות באזורCloud de Confiance סמוך שממנו הבקשות מגיעות.
ההגדרה הזו עוזרת למנוע כשלים מדורגים בשירותים במורד הזרם שתלויים במפתח החיצוני. בעיות של זמני טעינה ארוכים במיוחד שעלולות לגרום בדרך כלל לחוויית משתמש גרועה באפליקציות ברמה גבוהה יותר, יכולות להתבטא כגישות שנכשלו למפתח החיצוני, וכתוצאה מכך כפעולות לוגיות ברמה גבוהה יותר שנכשלו.
כדי לצמצם את זמן האחזור וליצור רשתות אמינות, כדאי לשים לב לנקודות הבאות:
- מצמצמים את זמן האחזור של תקשורת הלוך ושוב עם Cloud KMS: מגדירים את שירות ה-EKM כך שיטפל בבקשות במיקומים גיאוגרפיים שקרובים ככל האפשר למיקומי Cloud de Confiance שמתאימים למפתחות Cloud KMS שהוגדרו לשימוש בשירות ה-EKM. מידע נוסף זמין במאמרים שיטות מומלצות לבחירת אזורים ב-Compute Engine ואזורים ותחומים.
- מומלץ להשתמש ב-Cloud Interconnect כשזה אפשרי: Cloud Interconnect יוצר חיבור עם זמינות גבוהה וזמן אחזור נמוך בין Cloud de Confianceלבין מרכז הנתונים שלכם באמצעות רשת VPC, ועוזר להסיר תלות באינטרנט.
- במקרה הצורך, פורסים פתרונות רשת באזור הקרוב ביותר לשירות EKM: מומלץ לאחסן את מפתחות Cloud KMS באזור הקרוב ביותר לשירות EKM. Cloud de Confiance אם יש אזורCloud de Confiance שקרוב יותר לשירות EKM מהאזור שבו נמצאים מפתחות Cloud KMS, צריך להשתמש בפתרונות רשת, כמו Cloud VPN, באזור הכי קרוב לשירות EKM. Cloud de Confiance האפשרות הזו עוזרת להבטיח שתעבורת הנתונים ברשת תשתמש בתשתית של Google כשאפשר, וכך מצמצמת את התלות באינטרנט.
- שימוש ברשתות במסלול פרימיום כשנתוני EKM עוברים דרך האינטרנט: במסלול פרימיום, תעבורת הנתונים מנותבת דרך האינטרנט באמצעות התשתית של Google, ככל האפשר, כדי לשפר את המהימנות ולקצר את זמן האחזור.
הפעלת זמינות גבוהה
העובדה שיש נקודת כשל בודדת בשירות EKM מקטינה את הזמינות של משאבים תלויים לרמה של נקודת הכשל הבודדת. Cloud de Confiance נקודות כשל כאלה יכולות להיות בתלות קריטית של שירות ה-EKM, וגם בתשתית הבסיסית של המחשוב והרשת.
כדי להפעיל זמינות גבוהה, כדאי:
- פריסת רפליקות בדומיינים נפרדים של כשל: פורסים לפחות שתי רפליקות של שירות ה-EKM. אם אתם משתמשים במיקומים Cloud de Confiance
רב-אזוריים, אתם צריכים לפרוס את EKM לפחות בשני מיקומים גיאוגרפיים נפרדים, עם לפחות שני עותקים משוכפלים בכל מיקום. כדי לוודא שכל רפליקה לא מייצגת רק מישור נתונים משוכפל של שירות EKM, צריך לצמצם את וקטורי הכשל של הרפליקות ולחזק אותם. כמה דוגמאות:
- כדי לשנות רק עותק אחד בכל פעם, צריך להגדיר שינויים בייצור, כולל דחיפות של קובץ בינארי של שרת והגדרות. לוודא שכל השינויים מתבצעים בפיקוח, ושיש אפשרות זמינה ומוכנה לביצוע שחזור.
- הסבר על מצבי הכשל של העתקים חוצי-אזורים ואיך אפשר לצמצם אותם בתשתית הבסיסית. לדוגמה, צריך לוודא שהרפליקות תלויות בהזנות חשמל עצמאיות ועודפות.
יצירת עותקים עמידים בפני הפסקות חשמל במכונה אחת: מוודאים שכל עותק של השירות מורכב לפחות משלושה מכשירים, מכונות או מארחי מכונות וירטואליות. ההגדרה הזו מאפשרת למערכת לטפל בתנועת נתונים בזמן שמכונה אחת מושבתת לצורך עדכונים או במהלך הפסקת חשמל לא צפויה (הקצאת משאבים של N+2).
הגבלת האזור המושפע מבעיות במישור הבקרה: מגדירים את מישור הבקרה (למשל, יצירה או מחיקה של מפתחות) של שירות ה-EKM לשכפול הגדרות או נתונים בין העותקים. הפעולות האלה בדרך כלל מורכבות יותר כי הן דורשות סנכרון ומשפיעות על כל העותקים. הבעיות יכולות להתפשט במהירות ולהשפיע על המערכת כולה. הנה כמה אסטרטגיות לצמצום ההשפעה של בעיות:
- שליטה במהירות ההפצה: כברירת מחדל, חשוב לוודא שהשינויים מופצים לאט ככל האפשר, בהתאם לשיקולי שימושיות ואבטחה. אם צריך, מגדירים חריגים – למשל, כשרוצים לאפשר גישה למפתח כדי להפיץ אותו במהירות ולאפשר למשתמש לבטל טעות.
- חלוקת המערכת לרסיסים: אם משתמשים רבים משתפים את ה-EKM, צריך לחלק אותם לרסיסים לוגיים שהם בלתי תלויים לחלוטין, כך שבעיות שנגרמות על ידי משתמש ברסיס אחד לא ישפיעו על משתמשים ברסיס אחר.
- תצוגה מקדימה של השפעת השינויים: אם אפשר, כדאי לאפשר למשתמשים לראות את ההשפעה של השינויים לפני שמחילים אותם. לדוגמה, כשמשנים מדיניות גישה למפתח, ה-EKM יכול לאשר את מספר הבקשות האחרונות שהיו נדחות במסגרת המדיניות החדשה.
- הטמעה של בדיקת נתונים: קודם שולחים נתונים רק לקבוצת משנה קטנה של המערכת. אם קבוצת המשנה נשארת תקינה, מעבירים את הנתונים לשאר המערכת.
הטמעה של בדיקות תקינות הוליסטיות: יצירת בדיקות תקינות שמודדות את הפעילות של המערכת כולה. לדוגמה, בדיקות תקינות שמאמתות רק את הקישוריות לרשת לא עוזרות להגיב לבעיות רבות ברמת האפליקציה. במצב אידיאלי, בדיקת התקינות משקפת באופן מדויק את התלות בתנועה אמיתית.
הגדרה של יתירות כשל בין רפליקות: מגדירים איזון עומסים ברכיבי שירות ה-EKM כך שהמערכת תשתמש בבדיקות התקינות, תנתב באופן פעיל את תעבורת הנתונים מרפליקות לא תקינות ותעבור באופן בטוח לרפליקות תקינות.
כוללים מנגנוני בטיחות לניהול עומס יתר ולמניעת כשלים מדורגים: יכול להיות שיהיה עומס יתר על המערכות מסיבות שונות. לדוגמה, אם חלק מהרפליקות לא תקינות, התנועה שמופנית לרפליקות התקינות עלולה לגרום לעומס יתר. אם המערכת מקבלת יותר בקשות ממה שהיא יכולה לטפל בהן, היא צריכה לנסות לטפל במה שהיא יכולה במהירות ובבטחה, ולדחות את התנועה העודפת.
חשוב לוודא שיש לכם תוכנית מגירה חזקה: אי אפשר לשחזר נתונים ב- Cloud de Confiance שמוצפנים באמצעות מפתח חיצוני בשירות EKM בלי המפתח החיצוני. לכן, עמידות המפתחות היא אחת מדרישות התכנון המרכזיות של שירות ה-EKM. מגדירים את שירות ה-EKM כך שיגבה בצורה מאובטחת עותקים מיותרים של חומר המפתח בכמה מיקומים פיזיים. כדאי להגדיר אמצעי הגנה נוספים, כמו גיבויים אופליין, למפתחות בעלי ערך גבוה. חשוב לוודא שמנגנוני המחיקה מאפשרים פרק זמן לשחזור במקרים של תאונות ובאגים.
זיהוי מהיר של כשלים וצמצום ההשפעה שלהם
בכל דקה שבה יש הפסקת שירות ב-EKM, יכול להיות שלא תהיה גישה למשאבים תלויים Cloud de Confiance ושהסיכוי לכשל מדורג של רכיבים תלויים אחרים בתשתית יגדל.
כדי לזהות ולצמצם את הסיכויים לכשלים במהירות, כדאי לשקול את האפשרויות הבאות:
- מגדירים את שירות ה-EKM לדיווח על מדדים שמצביעים על אירועים שמאיימים על המהימנות: מגדירים מדדים כמו שיעורי שגיאות בתגובה וחביון תגובה כדי לזהות בעיות במהירות.
- הגדרת שיטות עבודה תפעוליות לקבלת התראה בזמן על אירועים ולצמצום ההשפעה שלהם: כדי לכמת את היעילות של שיטות העבודה התפעוליות, עוקבים אחרי המדדים 'זמן ממוצע לזיהוי (MTTD)' ו'זמן ממוצע לשחזור (MTTR)', ומגדירים יעדים שנמדדים באמצעות המדדים האלה. בעזרת המדדים האלה תוכלו לזהות דפוסים וליקויים בתהליכים ובמערכות הנוכחיים, כדי שתוכלו להגיב במהירות לאירועים.
תרשימי עזר לארכיטקטורות של Cloud EKM
בארכיטקטורות הבאות מתוארות כמה דרכים לפרוס את שירות ה-EKM באמצעות מוצרי הרשת ואיזון העומסים שלCloud de Confiance .
חיבור ישיר דרך Cloud VPN או Cloud Interconnect
מומלץ ליצור חיבור ישיר בין Cloud de Confiance לבין מרכז הנתונים המקומי שלכם אם אתם מפעילים אפליקציות עם תפוקה גבוהה ב-Cloud de Confiance ושירות ה-EKM פועל במרכז נתונים יחיד. התרשים הבא מציג את הארכיטקטורה הזו.
בארכיטקטורה הזו, שירות Cloud EKM ניגש לשירות EKM שנמצא במרכז נתונים מקומי דרך קישוריות היברידית באזור, ללא איזון עומסים ביניים ב- Cloud de Confiance.
אם אפשר, כדאי לפרוס את החיבור בין Cloud EKM לבין שירות EKM באמצעות הגדרת הזמינות של 99.9% לאפליקציות באזור יחיד. ההגדרה של זמינות של 99.99% מחייבת שימוש ב-Cloud Interconnect בכמה Cloud de Confianceאזורים, וזה אולי לא יתאים לצרכים שלכם אם העסק שלכם דורש בידוד אזורי. אם החיבור למרכז הנתונים המקומי משתמש באינטרנט, צריך להשתמש ב-HA VPN במקום ב-Cloud Interconnect.
היתרון העיקרי של הארכיטקטורה הזו הוא שאין בה קפיצות ביניים Cloud de Confiance, מה שמקטין את זמן האחזור ואת צווארי הבקבוק הפוטנציאליים. אם אתם רוצים להגדיר חיבור ישיר כששירות ה-EKM שלכם מתארח בכמה מרכזי נתונים, אתם צריכים להגדיר מאזני עומסים בכל מרכזי הנתונים שמשתמשים באותה כתובת IP (anycast). אם משתמשים בתצורה הזו, איזון העומסים ומעבר לגיבוי בין מרכזי הנתונים מוגבלים רק לזמינות של נתיב.
אם מגדירים רשת VPC, מפתחות חיצוניים שאליהם ניגשים דרך רשת ה-VPC צריכים להשתמש במיקום אזורי ב-Cloud KMS. אי אפשר להשתמש במפתחות במיקום רב-אזורי. מידע נוסף מופיע במאמר בנושא אזורים ומנהלי מפתחות חיצוניים.
איזון עומסים מהאינטרנט ב- Cloud de Confiance
מומלץ להשתמש במאזן עומסים ב- Cloud de Confiance עם חיבור לאינטרנט כשנדרשים מפתחות Cloud KMS בכמה אזורים. התרשים הבא מציג את הארכיטקטורה הזו.
בארכיטקטורה הזו, ל-EKM יש רפליקות בשני אתרים מקומיים. כל קצה עורפי מיוצג ב- Cloud de Confiance באמצעות קבוצה של נקודות קצה ברשת (NEG) לקישוריות היברידית. הפריסה משתמשת במאזן עומסי רשת חיצוני לשרת proxy כדי להעביר את תעבורת הנתונים ישירות לאחת מהרפליקות. בשונה מהגישות האחרות, שמסתמכות על רשת VPC, למאזן עומסי רשת חיצוני לשרת proxy יש כתובת IP חיצונית, ותעבורת הנתונים מגיעה מהאינטרנט.
כל NEG של קישוריות היברידית עשוי להכיל כמה כתובות IP, מה שמאפשר למאזן עומסי הרשת החיצוני לשרת proxy לאזן את התעבורה ישירות למופעים של שירות ה-EKM. לא צריך מאזן עומסים נוסף במרכז הנתונים המקומי.
מאזן עומסי רשת חיצוני בשרת proxy לא קשור לאזור ספציפי. הוא יכול להפנות תנועה נכנסת לאזור הקרוב ביותר שפועל בצורה תקינה, ולכן הוא מתאים למפתחות Cloud KMS שמוגדרים במספר אזורים. עם זאת, מאזן העומסים לא מאפשר הגדרה של קצוות עורפיים ראשיים וקצוות עורפיים למעבר לגיבוי. התעבורה מתחלקת באופן שווה בין כמה בק-אנדים באזור מסוים.
מאזן העומסים ברשת VPC ב Cloud de Confiance
מומלץ להשתמש במאזן עומסים ב- Cloud de Confiance עם רשת VPC ברוב שירותי ה-EKM שבהם אתם פורסים את ה-EKM. התרשים הבא מציג את הארכיטקטורה הזו.
בארכיטקטורה הזו, Cloud EKM ניגש לשירות EKM שמשוכפל בין שני מרכזי נתונים מקומיים באמצעות קישוריות היברידית עם שכבות של איזון עומסים ביניים באזור Cloud de Confiance . אם החיבור למרכז הנתונים המקומי משתמש באינטרנט, אפשר להשתמש ב-HA VPN במקום ב-Cloud Interconnect.
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי מספק כתובת IP יחידה שמשאבים יכולים להשתמש בה כדי לשלוח תנועה באמצעות רשת וירטואלית. מאזן העומסים עובר לגיבוישל מרכז הנתונים על סמך התקינות של השרתים העורפיים.
קבוצת מופעי מכונה וירטואלית נדרשת כדי להעביר תנועה דרך שרת proxy, כי מאזן העומסים הפנימי לא יכול לנתב תנועה ישירות לבק-אנד מקומי. אפשר לפרוס פרוקסי של מאזן עומסים כדי להריץ קובצי אימג' של Nginx Docker מ-Cloud Marketplace בקבוצות של מכונות וירטואליות. אפשר להשתמש ב-Nginx כמאזן עומסים של TCP.
בגישה הזו נעשה שימוש במאזני עומסים ב- Cloud de Confiance, ולכן לא צריך מאזן עומסים מקומי. מאזני העומסים יכולים להתחבר ישירות למופעים של שירות ה-EKM ולאזן את העומס ביניהם. Cloud de Confiance הסרת איזון העומסים המקומי מפשטת את ההגדרה, אבל מפחיתה את הגמישות שזמינה בשירות EKM. לדוגמה, מאזן עומסים ברמה 7 (L7) שפועל בפריסה מקומית יכול לנסות מחדש בקשות באופן אוטומטי אם מופעלת שגיאה במופע EKM אחד.
אם מגדירים רשת VPC, מפתחות חיצוניים שאליהם ניגשים דרך רשת ה-VPC צריכים להשתמש במיקום אזורי ב-Cloud KMS. אי אפשר להשתמש במפתחות במיקום רב-אזורי. מידע נוסף מופיע במאמר בנושא אזורים ומנהלי מפתחות חיצוניים.
השוואה בין תרשימי עזר לארכיטקטורה
בטבלה הבאה מוצגת השוואה בין האפשרויות של ארכיטקטורת העזר ל-Cloud EKM. הטבלה כוללת גם עמודה לארכיטקטורת EKM בניהול שותף. בתרחיש הזה, השותף אחראי לפריסה ולניהול של EKM, ומספק את EKM כשירות ללקוחות.
| אפשרות | חיבור ישיר | איזון עומסים מהאינטרנט | איזון עומסים ברשת VPC | פתרון EKM מנוהל באופן מלא שסופק על ידי שותף |
|---|---|---|---|---|
אינטרנט או רשת VPC |
VPC |
אינטרנט |
VPC |
אינטרנט |
מאזן עומסים ב- Cloud de Confiance |
לא |
כן |
כן |
לא |
נדרש מאזן עומסים מקומי |
כן |
לא |
לא |
כן (מנוהל על ידי שותף) |
יש תמיכה במיקומים מרובי-אזורים ב-Cloud KMS |
לא |
כן |
לא |
כן |
מומלץ ל |
אפליקציות עם תפוקה גבוהה שבהן שירות ה-EKM פועל באתר יחיד. |
מתי צריך מפתחות Cloud KMS שכוללים כמה אזורים. |
רוב שירותי ה-EKM שבהם אתם פורסים EKM משלכם. |
אתם יכולים להשתמש ב-EKM של שותף במקום לפרוס EKM משלכם. |