הארכיטקטורה של Cloud HSM

התוכן הזה עודכן לאחרונה באוקטובר 2025, והוא מציג את המצב הקיים במועד כתיבתו. מדיניות האבטחה ומערכות האבטחה של Google עשויות להשתנות בעתיד, מכיוון שאנחנו כל הזמן פועלים לשיפור ההגנה על הלקוחות שלנו.

‫Cloud HSM הוא חלק מהארכיטקטורה של Cloud Key Management Service‏ (Cloud KMS), ומספק את הקצה העורפי להקצאה ולניהול של מפתחות שמוגנים בחומרה. כדי לעזור לכם לעמוד בדרישות של תקנות תאגידיות ותקנות תאימות, Cloud HSM מאפשר לכם ליצור מפתחות הצפנה ולבצע פעולות קריפטוגרפיות במודולים של אבטחת חומרה (HSMs) התואמים לאישור FIPS 140-2 ברמה 3.

שירות Cloud HSM מספק שתי רמות הגנה למפתחות שמגובים בחומרה:

  • ‫Cloud HSM מרובה דיירים: מפתחות מרובי דיירים מאוחסנים באשכולות של HSM שמשרתים כמה לקוחות Google Cloud .
  • ‫Cloud HSM עם דייר יחיד: מפתחות עם דייר יחיד מאוחסנים במחיצות ייעודיות באשכולות של HSM, כאשר כל מחיצה משרתת רק לקוח אחד. אתם יוצרים ומנהלים בעצמכם מופעים של Single-tenant 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 עקבי ומאוחד
  • התאמה אוטומטית לעומס בהתאם לשימוש
  • ניהול מרכזי ותאימות לתקנות

‫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 data plane 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 מטפלת באבטחה פיזית, באבטחה לוגית, בתשתית, בתכנון קיבולת, בהתרחבות גיאוגרפית ובתכנון להתאוששות מאסון במרכזי נתונים.

הפשטה של חומרת 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) מקבוצת בעלי הרשאה שכוללת לפחות שני מאשרים ייעודיים. כשיוצרים מופע, קובעים כמה אישורים נדרשים לכל שינוי במופע Single-tenant Cloud HSM. אישורים דורשים אתגרים שנחתמים באמצעות חומר מפתח פרטי שאתם יוצרים מחוץ ל- Google Cloud.

התרשים הבא מציג את הארכיטקטורה של Cloud HSM.

תרשים ארכיטקטורה של Cloud HSM.

הפרדה גיאוגרפית מחמירה, לפי עיצוב

ב-Multi-tenant Cloud HSM, אתם יכולים לבחור אם המפתחות יהיו זמינים באופן גלובלי או לאכוף הגבלות גיאוגרפיות מחמירות על מפתחות שנדרשות להם הגבלות. ‫Cloud HSM עם דייר יחיד זמין רק באזורים מסוימים.

לרוב, מודולי HSM מחולקים למחיצות, כך שמכשיר פיזי יחיד יכול לפעול כמספר מכשירים לוגיים. אפשר להשתמש במחיצות כדי להקטין את עלויות הפריסה במקרים שבהם צריך להפריד בין ניהול HSM לבין מפתחות. בתרשים הבא מוצגות מחיצות של Cloud HSM עם ריבוי דיירים בשלושה אזורים.

תרשים של מיקום גיאוגרפי של Cloud HSM באמצעות מחיצות Cloud HSM מרובות דיירים.

כדי לבודד את המפתחות לכל אזור ולכל מיקום שכולל מספר אזורים, כל אזור ב-Cloud HSM משויך למפתח אריזה אזורי נפרד של HSM (ראו דיאגרמה ביצירת מפתחות). כדי לתמוך בזמינות גבוהה, מפתח האריזה משוכפל למחיצות בכל HSM שנמצא פיזית באזור. מפתחות אזוריים של HSM לא יוצאים מה-HSM במיקום הזה. שיבוט מאפשר ל-HSM באותו אזור לשרת את אותו סט של מפתחות לקוח, ומבטיח ש-HSM מחוץ לאזור לא יוכל לשרת את המפתחות האלה.

בנוסף, 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 מוגבלים גם הם מבחינה גיאוגרפית.
  • פעולות אדמיניסטרטיביות במפתחות שמוגנים על ידי חומרה תמיד מתועדות בשכבת ה-API ביומני הביקורת של Cloud. אפשר גם להפעיל רישום ביומן של גישה לנתונים. מידע נוסף זמין במאמר בנושא יומני ביקורת של 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 באזור כחלק מפעולה קריפטוגרפית. העטיפה הזו מציעה את היתרונות הבאים:

  • עמידות של מפתח לא קשורה ל-HSM ספציפי או לקבוצת משנה של HSM באזור מסוים.
  • כל לקוח של 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 מאפשרת לכם להשתמש במפתחות שמוגנים על ידי חומרה כדי לחתום על קבצים בינאריים ולשרת סשנים של TLS באינטרנט.

אבטחה ועמידה בתקנות

‫Cloud HSM עומד בדרישות של תקנות רבות, כולל FedRAMP High,‏ C5:2020 ו-OSPAR. בנוסף, Cloud HSM עוזר לכם לאכוף עמידה בתקנות עבור עומסי העבודה שלכם ב-Cloud.

אימות (attestation) של מפתח קריפטוגרפי

בכל פעם שיוצרים או מייבאים מפתח 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 חייבות לעבור אימות על ידי כמה מהנדסי SRE של Cloud HSM לפני שאפשר לפרוס את ה-HSM במרכז נתונים.
  • אחרי שמכניסים HSM לשימוש, רק כמה מהנדסי SRE של Cloud HSM יכולים ליזום ולאמת שינוי בהגדרות.
  • מערכת HSM יכולה לקבל רק קושחה שחתום עליה יצרן ה-HSM.
  • ציוד HSM לא נחשף ישירות לאף רשת.
  • שרתים שמארחים חומרת HSM לא יכולים להריץ תהליכים לא מורשים.

הסמכויות של אופרטורים של מערכות מוגדרות בתהליכי ההפעלה הרגילים. לאופרטורים של מערכות אין אפשרות לגשת לחומרי מפתחות של לקוחות, להשתמש בהם או לחלץ אותם כשהם מבצעים את המשימות שלהם.

בידוד של שירות ודייר

הארכיטקטורה של Cloud HSM מבטיחה שה-HSM מוגנים מפני הפרעות זדוניות או לא מכוונות משירותים או מדיירים אחרים.

מודול 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 יכולה ליצור מפתחות רק במיקומים שהיא תומכת בהם. ב-Cloud HSM עם ריבוי דיירים, כל מחיצה ב-HSM מכילה מפתח אריזה שתואם למיקום ב-Cloud KMS. במקרה של מופע Cloud HSM עם דייר יחיד, המחיצה הייעודית שלכם משתמשת במפתח אריזה שייעודי למופע שלכם. מפתח האריזה משותף לכל המחיצות שתומכות במיקום Cloud KMS או במופע Cloud HSM בדיירות יחידה.

בתרשים הבא מוצג תהליך העטיפה של מפתחות שמוגנים על ידי חומרה ב-Cloud KMS.

תרשים של יצירת מפתח HSM.

תהליך יצירת המפתח נראה כך:

  1. שירות ממשק הקצה של Google‏ (GFE) מנתב את הבקשה ליצירת מפתח לשרת Cloud KMS במיקום שמתאים לבקשה.
  2. ממשק Cloud Key Management Service API מאמת את הזהות של השירות המפעיל, את ההרשאה שלו ליצור מפתחות בפרויקט ואת המכסה שלו לבקשות כתיבה. אם מבצע הקריאה מבקש מפתח של Cloud HSM בדייר יחיד, ה-API גם מאמת שמופע Cloud HSM בדייר יחיד שנבחר זמין.
  3. ה-Cloud Key Management Service API מעביר את הבקשה אל Cloud HSM.
  4. ‫Cloud HSM מתקשר ישירות עם ה-HSM. ה-HSM:
    1. המערכת יוצרת את המפתח ועוטפת אותו במפתח עטיפה ספציפי למיקום או ספציפי למופע.
    2. יוצר את הצהרת האימות של המפתח וחותם עליה באמצעות מפתח החתימה של המחיצה.
  5. אחרי ש-Cloud HSM מחזיר את המפתח הארוז ואת האישור ל-Cloud KMS, ‏ Cloud Key Management Service API אורז את המפתח הארוז ב-HSM בהתאם להיררכיית המפתחות של Cloud KMS, ואז כותב אותו בפרויקט.

העיצוב הזה מבטיח שלא ניתן לבטל את העטיפה של המפתח או להשתמש בו מחוץ ל-HSM, שלא ניתן לחלץ אותו מה-HSM, והוא קיים במצב לא עטוף רק במיקומים שצוינו.

פעולות קריפטוגרפיות

כשמבצעים פעולה קריפטוגרפית ב-Cloud KMS, לא צריך לדעת אם משתמשים במפתח שמוגן באמצעות חומרה או במפתח שמוגן באמצעות תוכנה. כש-Cloud Key Management Service API מזהה שפעולה מסוימת כוללת מפתח שמוגן באמצעות חומרה, הוא מעביר את הבקשה ל-HSM באותו מיקום. אלה השלבים של פעולה קריפטוגרפית:

  1. ‫GFE מנתב את הבקשה לשרת Cloud KMS במיקום המתאים. ה-API של Cloud Key Management Service מאמת את הזהות של מי שקורא ל-API, את ההרשאה שלו לגשת למפתח ולבצע את הפעולה, ואת המכסה של הפרויקט לפעולות הצפנה.
  2. ‫Cloud Key Management Service API מאחזר את המפתח הארוז ממאגר הנתונים ומפענח רמה אחת של הצפנה באמצעות מפתח האב של Cloud KMS. המפתח עדיין נארז באמצעות מפתח האריזה של ה-HSM במיקום של ה-KMS.
  3. ‫Cloud Key Management Service API מזהה שרמת ההגנה היא HSM או HSM_SINGLE_TENANT, ושולח את המפתח שפוענח באופן חלקי, יחד עם נתוני הקלט לפעולה הקריפטוגרפית, אל Cloud HSM.
  4. ‫Cloud HSM מתקשר ישירות עם ה-HSM. מודול ה-HSM משלים את הפעולות הבאות:
    1. בודקת שהמפתח העטוף והמאפיינים שלו לא שונו.
    2. מבטל את העטיפה של המפתח וטוען אותו באחסון של ה-HSM.
    3. מבצעת את הפעולה הקריפטוגרפית ומחזירה את התוצאה.
  5. התוצאה מועברת חזרה למי ששלח את הקריאה באמצעות 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 משלכם

ה-HSMs שבהם נעשה שימוש ב-Cloud HSM מנוהלים על ידי Google. עם זאת, בנסיבות מסוימות, יכול להיות שהארגון שלכם ירצה להשתמש ב-HSM משלו כדי לאחסן את המפתחות שמוגנים באמצעות חומרה לעומסי העבודה שלכם. לדוגמה, שימוש ב-HSM משלכם יכול לעזור לכם להעביר את עומסי העבודה אל Google Cloud.

במיקומים מסוימים בלבד, Google מציעה מודול HSM כתשתית כשירות (IaaS) שמספק פעולות של מפתחות קריפטוגרפיים לעסקאות קריפטוגרפיות מאובטחות ב-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.

המאמרים הבאים

מידע נוסף זמין במשאבים הבאים: