התוכן הזה עודכן לאחרונה באוקטובר 2025, והוא מציג את המצב הקיים במועד כתיבתו. מדיניות האבטחה ומערכות האבטחה של Google עשויות להשתנות בעתיד, מכיוון שאנחנו כל הזמן פועלים לשיפור ההגנה על הלקוחות שלנו.
שירות Cloud HSM הוא חלק מהארכיטקטורה של Cloud Key Management Service (Cloud KMS), והוא מספק את הקצה העורפי להקצאה ולניהול של מפתחות שמוגנים באמצעות חומרה. כדי לעזור לכם לעמוד בדרישות של תקנות תאגידיות ותקנות תאימות, Cloud HSM מאפשר לכם ליצור מפתחות הצפנה ולבצע פעולות קריפטוגרפיות במודולים של אבטחת חומרה (HSM) התואמים לאישור FIPS 140-2 ברמה 3.
שירות Cloud HSM מספק שתי רמות הגנה למפתחות שמגובים בחומרה:
- Cloud HSM מרובה דיירים: מפתחות מרובי דיירים מאוחסנים באשכולות של HSM שמשרתים כמה לקוחות של Google Cloud .
- Cloud HSM עם דייר יחיד: מפתחות עם דייר יחיד מאוחסנים במחיצות ייעודיות באשכולות של HSM, כאשר כל מחיצה משרתת רק לקוח אחד. אתם יוצרים ומנהלים בעצמכם מופעים של Cloud HSM עם דייר יחיד, שמבודדים קריפטוגרפית מלקוחות אחרים שלGoogle Cloud . למופעי Cloud HSM עם דייר יחיד יש עלויות נוספות בהשוואה למפתחות Cloud HSM עם מספר דיירים. מידע נוסף זמין במאמר Cloud HSM עם דייר יחיד.
במדריך הזה, כשמזכירים את Cloud HSM, הכוונה היא גם ל-Cloud HSM עם דיירים רבים וגם ל-Cloud HSM עם דייר יחיד.
במאמר הזה מתוארת הארכיטקטורה של Cloud HSM, כולל אופן הניהול של החומרה, והאימות והיצירה של מפתחות. מידע נוסף על Cloud KMS זמין במאמר הצפנה באמצעות Cloud Key Management Service.
סקירה כללית
פעולות קריפטוגרפיות כוללות את הפעולות הבאות:
- הצפנת נתונים באחסון
- הגנה על המפתחות הפרטיים של Certificate Authority Service
- הגנה על מפתחות להצפנת נתונים כדי שאפשר יהיה לאחסן אותם יחד עם הנתונים המוצפנים
- יצירה ושימוש במפתחות אסימטריים לפעולות קריפטוגרפיות כמו חתימות דיגיטליות ואימות
ב-Cloud HSM נעשה שימוש ב-HSMs של Marvell LiquidSecurity (דגמים CNL3560-NFBE-2.0-G ו-CNL3560-NFBE-3.0-G) עם גרסאות קושחה 3.4 build 09 ו-10. מידע נוסף על האישור שלנו זמין במאמר בנושא אישור #4399. במאמר אימות מפתח תוכלו לקרוא מידע נוסף על מכשירי HSM ומפתחות שמוגנים באמצעות חומרה.
Cloud HSM עם כמה דיירים מנוהל באופן מלא, כך שאתם יכולים להגן על עומסי העבודה בלי העומס התפעולי של ניהול אשכול HSM. הניהול של Cloud HSM לדייר יחיד מתבצע במשותף על ידי האדמינים של המכונה ו-Google. לשירות Cloud HSM יש את היתרונות הבאים:
- זמינות גלובלית
- API עקבי ומאוחד
- התאמה אוטומטית לעומס (automatic scaling) על סמך השימוש שלכם
- ניהול מרכזי ועמידה בתקנות
Cloud HSM עם ריבוי דיירים זמין בהרבה Google Cloud אזורים ברחבי העולם, כולל מספר אזורים שמשתרעים על שטחים גיאוגרפיים גדולים יותר. Cloud HSM לדייר יחיד זמין בחלק מהאזורים האלה. כדי להגן על הנתונים שלכם, כולל נתונים שאתם מאחסנים בשירותים אחרים של Google Cloud כמו BigQuery, Cloud Storage ו-Persistent Disk, אתם צריכים להשתמש בנקודת הקצה של שירות Cloud KMS כדי ליצור מפתחות שמוגנים באמצעות חומרה ב-Cloud HSM ולהשתמש בהם.
באמצעות Cloud HSM, אתם יכולים להשתמש במפתחות שמוגנים באמצעות חומרה בלי לנהל בעצמכם את חומרת ה-HSM. Google היא הבעלים של חומרת ה-HSM והיא מנהלת אותה, כולל פריסה, הגדרה, מעקב, תיקון ותחזוקה. כשמשתמשים ב-Cloud HSM, הנתונים מבודדים באופן מוחלט מדיירים וממשתמשים אחרים ב- Google Cloud. ממשק Cloud HSM API למישור הנתונים, שהוא חלק מ-Cloud Key Management Service API, מאפשר לכם לנהל מפתחות שמוגנים בחומרה באופן פרוגרמטי.
שירות Cloud HSM תומך במפתחות הצפנה בניהול הלקוח (CMEK) שמוגנים באמצעות חומרה, בכל מקום שבו שירותי Google Cloud תומכים ב-CMEK. לדוגמה, אתם יכולים להצפין נתונים בקטגוריות של Cloud Storage או בטבלאות של Cloud SQL באמצעות מפתח Cloud HSM שאתם מנהלים. Cloud HSM עם ריבוי דיירים תומך גם ב-Cloud KMS Autokey, כדי ליצור ולנהל את מפתחות ה-CMEK בצורה יעילה.
ניהול Cloud HSM
ב-Cloud HSM, אשכולות של HSM מנוהלים על ידי מהנדסי אמינות אתרים (SRE) וטכנאים של Google שעובדים בכל מיקום של מרכז נתונים של Google Cloud. Google מטפלת באבטחה פיזית, באבטחה לוגית, בתשתית, בתכנון קיבולת, בהתרחבות גיאוגרפית ובתכנון התאוששות מאסון (DR) במרכז הנתונים.
הפשטה של חומרת HSM
בדרך כלל, אפליקציות מתקשרות ישירות עם HSM באמצעות PKCS#11 ו-API לניהול אשכולות. כדי להשתמש בתקשורת הזו, צריך לתחזק קוד מיוחד לעומסי עבודה שמשתמשים במפתחות שמוגנים באמצעות חומרה או מנהלים אותם.
שירות Cloud HSM מפשט את התקשורת עם ה-HSM באמצעות העברת בקשות למפתחות שמוגנים בחומרה דרך Cloud Key Management Service API. ההפשטה מפחיתה את הצורך בקוד ספציפי ל-HSM. שירות Cloud HSM משתלב באופן הדוק עם Cloud KMS.
שילוב הדוק עם Cloud KMS מספק יתרונות משמעותיים בתחום האבטחה. ממשק Cloud Key Management Service API מצמצם באופן משמעותי את רוחב הפס של ממשק ה-HSM שזמין, וכך מפחית את הסיכון במקרה של פרצת אבטחה אצל לקוח. לדוגמה, תוקף לא יוכל למחוק את כל ה-HSM. כברירת מחדל, ניסיונות להשמיד מפתחות בודדים נמנעים באמצעות תקופת בטיחות של 30 יום. אתם יכולים להגדיר את מדיניות הארגון constraints/cloudkms.minimumDestroyScheduledDuration כדי לאכוף משך זמן מינימלי של מועד ההשמדה למפתחות חדשים, ואת מדיניות הארגון constraints/cloudkms.disableBeforeDestroy כדי להשמיד גרסאות של מפתחות רק כשהן מושבתות. מידע נוסף זמין במאמר שליטה בהשמדה של גרסאות מפתחות.
אפשר לשלוט בגישה למשאבי HSM באמצעות ניהול זהויות והרשאות גישה (IAM). פחות סביר שיהיו בעיות בהגדרות של IAM, כמו באגים או הגדרות שגויות, מאשר בפתרון HSM בהתאמה אישית. בנוסף לאמצעי הבקרה של IAM, כדי לנהל מכונה של Cloud HSM לדייר יחיד נדרש גם אימות דו-שלבי (2FA) מקוורום של לפחות שני מאשרים ייעודיים. כשיוצרים מכונה, מחליטים כמה אישורים נדרשים לכל שינוי במכונה של Cloud HSM לדייר יחיד. כדי לאשר, צריך להשתמש באתגרים שחתומים באמצעות חומר מפתח פרטי שאתם יוצרים מחוץ ל- Google Cloud.
התרשים הבא מציג את הארכיטקטורה של Cloud HSM.
הפרדה גיאוגרפית קפדנית, כחלק מהתכנון
ב-Multi-tenant Cloud HSM, אתם יכולים לבחור אם להפוך את המפתחות לזמינים באופן גלובלי או לאכוף הגבלות גיאוגרפיות מחמירות על מפתחות שנדרשות להם הגבלות. Cloud HSM לדייר יחיד זמין רק באזורים נפרדים.
בדרך כלל, מכשירי HSM מחולקים למחיצות, כך שמכשיר פיזי אחד יכול לפעול כמספר מכשירים לוגיים. אפשר להשתמש במחיצות כדי להפחית את עלויות הפריסה במקרים שבהם צריך להפריד בין ניהול ה-HSM לבין המפתחות. בתרשים הבא מוצגות מחיצות של Cloud HSM עם כמה דיירים בשלושה אזורים.
כדי לבודד את המפתחות לכל אזור ולכל מיקום שכולל מספר אזורים, כל אזור ב-Cloud HSM משויך למפתח אריזה אזורי נפרד של HSM (ראו את הדיאגרמה בקטע יצירת מפתחות). כדי לתמוך בזמינות גבוהה, מפתח האריזה משוכפל למחיצות בכל HSM שנמצא פיזית באזור. מפתחות אזוריים של HSM לא יוצאים מה-HSM במיקום הזה. השכפול מאפשר ל-HSMs באותו אזור להציג את אותה קבוצה של מפתחות לקוחות, ומוודא ש-HSMs מחוץ לאזור לא יכולים להציג את המפתחות האלה.
בנוסף, Cloud HSM יוצר אזורים גיאוגרפיים נרחבים באמצעות מפתחות אריזה. כל מפתחות הלקוח באזור שכולל מספר אזורים נארזים באמצעות מפתח אריזה שנמצא במחיצה בכל המיקומים שמרכיבים את האזור שכולל מספר אזורים. השירות משתמש באותה חומרה למספר אזורים, אבל מספק את אותו בידוד חזק בין אזורים לבין מספר אזורים שקיים בין אזורים שונים.
לפי תוכנית האזורים, מפתחות העטיפה משוכפלים רק למחיצות המתאימות. כל שינוי בהגדרות חייב לקבל אישור מכמה חברים בצוות Cloud HSM לפני שהוא נכנס לתוקף. טכנאים במרכזי נתונים לא יכולים לגשת להגדרות, לזמן ריצה או לאחסון של HSM.
כשיוצרים מפתחות במכונה של Cloud HSM עם דייר יחיד, מפתחות האריזה במחיצות הייעודיות מבטיחים שלא ניתן יהיה להציג את המפתחות מחוץ למחיצות או לאזור.
ניהול מרכזי
במרכז נתונים רגיל שמארח מודולי HSM, הניהול של מודולי ה-HSM והמשאבים שלהם נפרד לחלוטין מהניהול של מפתחות אחרים שמוגנים על ידי חומרה. שירות Cloud HSM משולב באופן הדוק ב- Google Cloud, ומאפשר לכם לנהל בצורה חלקה את המשאבים של Cloud HSM. לדוגמה, אתם יכולים לנהל את:
- אתם יכולים לנהל את המפתחות שמוגנים באמצעות חומרה לצד מפתחות אחרים ב-Cloud KMS ומפתחות שמנוהלים חיצונית ב-Cloud External Key Manager (Cloud EKM).
- אתם יכולים לנהל את הגישה למפתחות שמוגנים באמצעות חומרה ב-IAM.
- העלויות של פעולות קריפטוגרפיות באמצעות מפתחות שמוגנים על ידי חומרה מדווחות בחיוב ב-Cloud.
- אתם יכולים להשתמש במפתחות שמוגנים באמצעות חומרה באופן שקוף בכל שירותי Google Cloudשתומכים בהצפנת משאבים באמצעות CMEK. שילובים של CMEK מחייבים שהמפתח של CMEK והנתונים שהוא מצפין יהיו במיקומים גיאוגרפיים תואמים. בגלל ההגבלה הגיאוגרפית המחמירה של מפתחות Cloud HSM, כל ההצפנה והפענוח של נתוני CMEK מוגבלים גם הם מבחינה גיאוגרפית.
- פעולות אדמיניסטרטיביות במפתחות שמוגנים על ידי חומרה תמיד נרשמות ביומני הביקורת של Cloud בשכבת ה-API. אפשר גם להפעיל רישום ביומן של גישה לנתונים. מידע נוסף זמין במאמר בנושא רישום ביומני ביקורת ב-Cloud KMS.
- Google עובדת ישירות עם יצרן ה-HSM כדי לעדכן את החומרה והתוכנה בכל HSM, וכדי למצוא ולתקן בעיות בזמן אמת. במקרה של ניצול לרעה של פגיעות ב-HSM, Google יכולה להשבית באופן סלקטיבי נתיבי קוד מושפעים באשכולות HSM מושפעים עד לתיקון הפגיעות.
- אתם יכולים לעקוב אחרי המפתחות שלכם, כולל מפתחות שמוגנים בחומרה והמשאבים שהם מצפינים, באמצעות לוחות בקרה למעקב אחרי השימוש במפתחות.
חוויית המשתמש והמפתחים
מכיוון ש-Google אחראית לניהול של HSM, Cloud HSM מציע יתרונות משמעותיים למפתחים ולמשתמשי קצה. כשמשתמשים ב-Cloud HSM עם ריבוי דיירים, לא צריך לעשות שום דבר כדי לתחזק את אשכולות ה-HSM. כשמשתמשים ב-Cloud HSM לדייר יחיד, אתם אחראים על פעולות התחזוקה השוטפות של האשכול באמצעות ה-CLI של gcloud.
יש ארבעה סוגים עיקריים של משתמשים ב-Cloud HSM:
- משתמשי קצה: בדרך כלל, Cloud HSM שקוף למשתמשי הקצה של המוצרים והמשאבים שלכם. לדוגמה, אם המשאבים שלכם ב- Google Cloud מוגנים באמצעות CMEK, הנתונים מוצפנים ומפוענחים באופן אוטומטי לפי הצורך של המשתמשים על ידי סוכני שירות.
- מפתחים: המפתחים משתמשים במפתחות Cloud HSM. אם אתם משתמשים ב-Autokey, המפתחים יכולים לבקש מפתחות חדשים על פי דרישה. אם אתם לא משתמשים ב-Autokey, האדמינים של Cloud KMS יוצרים ומנהלים את המפתחות שהמפתחים שלכם משתמשים בהם.
- אדמינים של Cloud KMS: האדמינים של Cloud KMS אחראים ליצירה ולרוטציה של מפתחות Cloud HSM. הם יכולים גם לנהל את ההגדרות של Autokey או את מדיניות הארגון, אם האחריות הזו לא מנוהלת על ידי מנהלי חשבון ארגוני ייעודיים.
- אדמינים של Cloud HSM עם דייר יחיד: אם אתם משתמשים ב-Cloud HSM עם דייר יחיד, אתם צריכים צוות אדמינים שאתם סומכים עליו שיאשר פעולות של יצירה ותחזוקה במופעים של Cloud HSM עם דייר יחיד. תפקידי IAM נפרדים קובעים למי יש הרשאה להציע שינויים במופע, לאשר אותם ולבצע אותם. אי אפשר להחיל שינויים בלי אישור מראש, שדורש אימות קוורום באמצעות מפתחות אימות דו-שלבי.
HSM בקנה מידה של Google
כשמסתמכים על חומרה שקיימת באתר או במרכזי נתונים, החומרה יכולה ליצור צוואר בקבוק בביצועים או להפוך לנקודת כשל בודדת. שירות Cloud HSM מתוכנן להיות עמיד מאוד בפני עומסי עבודה בלתי צפויים וכשלים בחומרה. הקצה העורפי של Cloud HSM משתמש במאגר של HSMs בכל אזור כדי להבטיח זמינות גבוהה ומדרגיות. מאגר ה-HSM הזה מאפשר ל-Cloud HSM לספק גם תפוקה גבוהה. מידע נוסף מופיע במאמר מעקב אחרי מכסות ב-Cloud KMS ושינוי שלהן.
כל המפתחות של הלקוחות מאוחסנים כשהם עטופים במפתח עטיפה אזורי במסד הנתונים של Cloud KMS, ואפשר לפתוח את העטיפה שלהם רק באמצעות HSM באזור כחלק מפעולה קריפטוגרפית. היתרונות של ה-wrapper:
- העמידות של מפתח לא קשורה ל-HSM ספציפי או לקבוצת משנה של HSMs באזור.
- כל לקוח של Cloud HSM נהנה מהיקף מלא וזמינות מלאה של אשכולות Cloud HSM שמשרתים את המפתחות שלו.
- שירות Cloud HSM יכול לטפל במערך גדול בהרבה של מפתחות שאפשר לאחסן ב-HSM.
- הוספה או החלפה של HSM מתבצעת במהירות ובאופן מאובטח.
עיצוב API מאוחד
ל-Cloud HSM ול-Cloud KMS יש ממשק API משותף לניהול ולמישור הנתונים. הפרטים הפנימיים של התקשורת עם HSM מופשטים מהמתקשר.
לכן, לא צריך לשנות את הקוד כדי לעדכן אפליקציה קיימת שמשתמשת במפתחות תוכנה ב-Cloud KMS, כך שתתמוך במפתחות שמוגנים באמצעות חומרה. במקום זאת, מעדכנים את שם המשאב של המפתח שבו רוצים להשתמש.
תמיכה ב-PKCS#11
אתם יכולים להשתמש ב-Cloud Key Management Service API כדי לחבר את האפליקציות הקיימות שלכם ל-Cloud HSM ולנהל מפתחות קריפטוגרפיים. הספרייה של PKCS#11 מאפשרת לכם להשתמש במפתחות שמוגנים באמצעות חומרה כדי לחתום על קובצי ה-binary שלכם ולשרת סשנים של TLS באינטרנט.
אבטחה ועמידה בתקנות
Cloud HSM עומד בתקנות רבות, כולל FedRAMP High, C5:2020 ו-OSPAR. בנוסף, Cloud HSM עוזר לכם לאכוף עמידה בתקנות עבור עומסי העבודה שלכם ב-Cloud.
אימות מפתח קריפטוגרפי
בכל פעם שיוצרים או מייבאים מפתח Cloud HSM, ה-HSM יוצר הצהרת אימות שנחתמת באמצעות מפתח חתימה שמשויך למחיצה. ההצהרה מכילה מידע על המאפיינים של המפתח. מפתח החתימה מגובה על ידי שרשראות אישורים שמבוססות על Google ועל יצרן ה-HSM. אפשר להוריד את הצהרת האימות ואת האישורים כדי לאמת את האותנטיות של ההצהרה, ולאמת את המאפיינים של המפתח ושל ה-HSM שיצר או ייבא אותו.
שרשרת האישורים מאפשרת לבדוק את הפרטים הבאים:
- החומרה והקושחה של ה-HSM מקוריות.
- מחיצת ה-HSM וה-HSM מנוהלים על ידי Google.
- ה-HSM נמצא במצב פעולה של FIPS.
תוכן הצהרת האימות מאפשר לכם לבדוק את הפרטים הבאים:
- אי אפשר לחלץ את המפתח.
- המפתח נוצר עבור CryptoKeyVersion.
- המפתח הציבורי בזוג מפתחות אסימטריים תואם למפתח פרטי שמוגן על ידי חומרה.
- חומר המפתח של מפתח סימטרי מיובא תואם לערך שארזתם.
ייבוא מאובטח של מפתחות ישירות ל-HSMs
אתם יכולים לייבא באופן מאובטח מפתחות קיימים ל-Cloud HSM כדי לשמור גיבוי של חומר המפתח מחוץ ל- Google Cloud, או כדי לפשט את ההעברה של עומסי עבודה מסוימים ל- Google Cloud. תהליך ייבוא המפתחות לא מאפשר ל-Google גישה ישירה לחומר המפתח הלא עטוף. שירות Cloud HSM מספק לכם הצהרת אימות למפתח האריזה שנוצר על ידי HSM, כדי לאמת שלא הייתה גישה.
מכיוון שיבוא מפתחות עלול ליצור סיכונים בתחום האבטחה והתאימות, כי הוא מאפשר למשתמשים להביא מפתחות ממקורות לא ידועים, תפקידי IAM נפרדים מאפשרים שליטה מדויקת במי שיכול לייבא מפתחות לפרויקט. אפשר להבחין בין מפתחות מיובאים באמצעות הצהרת האימות שה-HSM יוצר בזמן הייבוא.
מידע נוסף זמין במאמר ייבוא מפתח ל-Cloud Key Management Service.
נהלי אבטחה מחמירים שמגנים על חומרת ה-HSM
בהתאם לדרישות של FIPS 140-2 ברמה 3, במכשירי HSM יש מנגנונים מובנים שמספקים הגנה מפני פגיעה פיזית וראיות לפגיעה כזו.
בנוסף לאבטחה שמספקת חומרת ה-HSM עצמה, התשתית של Cloud HSM מנוהלת בהתאם לסקירה הכללית על תכנון האבטחה בתשתית של Google.
ההליכים הבאים, שמתועדים וניתנים לביקורת, מגינים על השלמות של כל HSM במהלך ההקצאה, הפריסה והייצור:
- לפני שניתן לפרוס את ה-HSM במרכז נתונים, צריך לוודא שכל ההגדרות של ה-HSM אומתו על ידי כמה מהנדסי SRE של Cloud HSM.
- אחרי שמכניסים HSM לשירות, רק מספר מהנדסי SRE של Cloud HSM יכולים ליזום ולאמת שינוי בהגדרות.
- HSM יכול לקבל רק קושחה שחתומה על ידי יצרן ה-HSM.
- חומרת ה-HSM לא חשופה ישירות לאף רשת.
- שרתים שמארחים חומרת HSM לא יכולים להריץ תהליכים לא מורשים.
הסמכויות של אופרטורים של מערכות מוגדרות בתהליכי ההפעלה הרגילים. לאופרטורים של מערכות אין גישה לחומרי מפתחות של לקוחות, והם לא יכולים להשתמש בהם או לחלץ אותם כשהם מבצעים את המשימות שלהם.
בידוד של שירותים ודיירים
הארכיטקטורה של Cloud HSM מבטיחה שה-HSMs מוגנים מפני הפרעות זדוניות או לא מכוונות משירותים או מדיירים אחרים.
מודול HSM שהוא חלק מהארכיטקטורה הזו מקבל בקשות רק מ-Cloud HSM, ושירות Cloud HSM מקבל בקשות רק משירות Cloud KMS. שירות Cloud KMS אוכף את הדרישה שלמתקשרים יהיו הרשאות IAM מתאימות במפתחות שהם מנסים להשתמש בהם. בקשות לא מורשות לא מגיעות ל-HSM.
מפתחות Cloud HSM עם ריבוי דיירים כפופים גם למכסות של פעולות קריפטוגרפיות. המכסות האלה מגנות על היכולת שלכם להריץ את עומסי העבודה, ועוזרות למנוע ניסיונות זדוניים או לא מכוונים להעמיס על השירות. מכסות ברירת המחדל מבוססות על דפוסי השימוש שנצפו. המכסות נמוכות משמעותית מהקיבולת של השירות, ואפשר להגדיל אותן לפי בקשה.
תהליכי בקשות
בקטע הזה מוסבר איך הארכיטקטורה של Cloud HSM פועלת בפועל, באמצעות הצגת השלבים של סוגי בקשות שונים. התהליכים האלה מדגישים את החלקים של Cloud HSM. מידע נוסף על השלבים המשותפים לכל המפתחות זמין בניתוח המעמיק של Cloud Key Management Service.
יצירת מפתחות
כשיוצרים מפתח שמוגן באמצעות חומרה, ה-API של Cloud Key Management Service לא יוצר את חומר המפתח, אלא מבקש מ-HSM ליצור אותו.
אפשר ליצור מפתחות ב-HSM רק במיקומים שנתמכים על ידו. ב-Multi-tenant Cloud HSM, כל מחיצה ב-HSM מכילה מפתח אריזה שתואם למיקום ב-Cloud KMS. במכונה של Cloud HSM לדייר יחיד, המחיצה הייעודית משתמשת במפתח אריזה ייעודי למכונה. מפתח האריזה משותף בין כל המחיצות שתומכות במיקום ב-Cloud KMS או במכונה של Cloud HSM עם דייר יחיד.
בתרשים הבא מוצג איך מפתחות שמוגנים באמצעות חומרה נעטפים ב-Cloud KMS.
תהליך יצירת המפתח נראה כך:
- שירות ממשק הקצה של Google (GFE) מנתב את הבקשה ליצירת מפתח לשרת Cloud KMS במיקום שתואם לבקשה.
- Cloud Key Management Service API מאמת את זהות הגורם שמבצע את הקריאה, את ההרשאה שלו ליצור מפתחות בפרויקט, ומוודא שיש לו מכסה מספקת לבקשות כתיבה. אם מבצע הקריאה מבקש מפתח Cloud HSM לדייר יחיד, ה-API גם מוודא שהמכונה שנבחרה של Cloud HSM לדייר יחיד זמינה.
- הבקשה מועברת מ-Cloud Key Management Service API אל Cloud HSM.
- ל-Cloud HSM יש ממשק ישיר עם ה-HSM. ה-HSM:
- המערכת יוצרת את המפתח ועוטפת אותו במפתח העטיפה הספציפי למיקום או למכונה.
- יוצר את הצהרת האימות של המפתח וחותם עליה באמצעות מפתח החתימה של המחיצה.
- אחרי ש-Cloud HSM מחזיר את המפתח הארוז ואת האישור ל-Cloud KMS, ה-Cloud Key Management Service API אורז את המפתח שנארז ב-HSM בהתאם להיררכיית המפתחות של Cloud KMS, ואז כותב אותו בפרויקט.
העיצוב הזה מבטיח שלא ניתן לפתוח את המפתח או להשתמש בו מחוץ ל-HSM, שלא ניתן לחלץ אותו מה-HSM, ושהוא קיים במצב פתוח רק במיקומים שצוינו.
פעולות קריפטוגרפיות
כשמבצעים פעולה קריפטוגרפית ב-Cloud KMS, לא צריך לדעת אם משתמשים במפתח שמוגן באמצעות חומרה או במפתח שמוגן באמצעות תוכנה. כש-Cloud Key Management Service API מזהה שפעולה מסוימת כוללת מפתח שמוגן באמצעות חומרה, הוא מעביר את הבקשה ל-HSM באותו מיקום. אלה השלבים של פעולה קריפטוגרפית:
- GFE מנתב את הבקשה לשרת Cloud KMS במיקום המתאים. Cloud Key Management Service API מאמת את זהות מבצע הקריאה, את ההרשאה שלו לגשת למפתח ולבצע את הפעולה, ואת המכסה של הפרויקט לפעולות קריפטוגרפיות.
- Cloud Key Management Service API מאחזר את המפתח הארוז ממאגר הנתונים ומפענח רמה אחת של הצפנה באמצעות מפתח המאסטר של Cloud KMS. המפתח עדיין נארז באמצעות מפתח האריזה של HSM למיקום של KMS.
- Cloud Key Management Service API מזהה שרמת ההגנה היא
HSMאוHSM_SINGLE_TENANTושולח את המפתח שפוענח באופן חלקי, יחד עם נתוני הקלט לפעולה הקריפטוגרפית, אל Cloud HSM. - ל-Cloud HSM יש ממשק ישיר עם ה-HSM. מודול ה-HSM משלים את הפעולות הבאות:
- בודק שהמפתח המוצפן והמאפיינים שלו לא שונו.
- ביטול האריזה של המפתח וטעינה שלו לאחסון ב-HSM.
- מבצע את הפעולה הקריפטוגרפית ומחזיר את התוצאה.
- התוצאה מועברת חזרה למי ששלח את הקריאה באמצעות Cloud Key Management Service API.
פעולות קריפטוגרפיות באמצעות מפתחות שמוגנים על ידי חומרה מתבצעות באופן מלא בתוך HSM במיקום המוגדר, ורק התוצאה גלויה למתקשר.
בתרשים הזה מוצג ההבדל בין יצירת מפתחות שמוגנים באמצעות חומרה לבין מפתחות שמוגנים באמצעות תוכנה ב-Cloud KMS.
שילובי CMEK
כל המפתחות שמוגנים באמצעות חומרה הם מפתחות CMEK. כדי להגדיר שירות שתומך ב-CMEK לשימוש במפתחות Cloud HSM, פשוט בוחרים מפתח עם רמת הגנה HSM או HSM_SINGLE_TENANT כשפועלים לפי ההוראות הספציפיות לשירות.
כשמתקשר קורא נתונים או כותב נתונים לשירות שמופעל בו CMEK, המתקשר לא צריך הרשאה ישירה להשתמש במפתח, והוא לא צריך לדעת אם המפתח מאוחסן ב-HSM.
תהליך הפעולה של CMEK זהה למפתחות שמוגנים באמצעות חומרה ולמפתחות שמוגנים באמצעות תוכנה, עם החריגים הבאים כשמשתמשים במפתחות שמוגנים באמצעות חומרה:
- הבקשה מהשירות שמופעל בו CMEK מתחילה ברשת של Google, ולא צריכה לעבור דרך ה-GFE.
- Cloud Key Management Service API מוודא שלחשבון השירות של השירות שבו מופעל CMEK יש את ההרשאות המתאימות לשימוש במפתח. ה-Cloud Key Management Service API לא מאמת הרשאות של משתמש הקצה בשירות שמופעל בו CMEK.
אם רוצים להשתמש ב-Autokey כדי להקצות מפתחות Cloud KMS, צריך להשתמש ב-Cloud HSM. Autokey מאפשר לסוכן השירות של Cloud KMS להקצות מפתחות מוגנים בחומרה באופן אוטומטי לפי בקשה. למידע נוסף, ראו הקצאה אוטומטית של CMEK.
שימוש במודולי HSM משלכם
Google מנהלת את ה-HSMs שבהם משתמש Cloud HSM. עם זאת, בנסיבות מסוימות, יכול להיות שהארגון שלכם ירצה להשתמש ב-HSM משלכם כדי לאחסן את המפתחות שמוגנים באמצעות חומרה לעומסי העבודה שלכם. לדוגמה, שימוש במודולי HSM משלכם יכול לעזור לכם להעביר את עומסי העבודה אל Google Cloud.
במיקומים מסוימים בלבד, Google מציעה תשתית HSM כשירות שמספקת פעולות של מפתחות קריפטוגרפיים לעסקאות קריפטוגרפיות מאובטחות ב-Google Cloud. המוצרים נקראים Bare Metal Rack HSM ו-Bare Metal HSM. ב-Bare Metal Rack HSM או ב-Bare Metal HSM, אתם רוכשים ומגדירים את ה-HSM שלכם, ואז שולחים אותם למרכזי הנתונים של Google כדי ש-Google תארח אותם. יש לכם גישה לוגית מלאה ל-HSM, ואתם צריכים לעבוד ישירות מול ספק ה-HSM כדי לנהל את המכשירים ולפתור בהם בעיות. Google מספקת אבטחה פיזית ואבטחת רשת, מקום במתקן, חשמל ושילוב רשת בתשלום. מידע נוסף זמין במאמרים Bare Metal Rack HSM ו-Bare Metal HSM.
המאמרים הבאים
מידע נוסף זמין במשאבים הבאים:
- מסמכי תיעוד של Cloud HSM
- מסמכי תיעוד של Cloud KMS
- הצפנה ב-Cloud Key Management Service
- סקירה כללית על תכנון האבטחה בתשתית של Google
- הצפנה במנוחה