סקירה כללית על Cloud HSM עם דייר יחיד

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

שירות Cloud HSM עם דייר יחיד מאפשר לכם ליצור ולנהל מופע של Cloud HSM עם דייר יחיד. מופע Cloud HSM בדייר יחיד הוא אשכול ייעודי של מחיצות במודולים של אבטחת חומרה (HSMs) לשימוש בלעדי שלכם. כל מופע מספק את אותה יתירות וזמינות גבוהה כמו Cloud HSM עם ריבוי דיירים. כל אשכול Single-tenant Cloud HSM מפוזר על פני כמה מודולי HSM בכמה אזורים באזור שנבחר. כל מחיצה מבודדת באופן קריפטוגרפי ממחיצות אחרות ב-HSM.

אתם יכולים להעניק או לדחות את הגישה של Google לאשכול, והאדמינים של המופע מנהלים את האשכול. אדמינים של מופעים שולטים במופע באמצעות מודל אישור של קוורום שמסתמך על מפתחות בקרה אסימטריים לאימות דו-שלבי (2FA). אתם יוצרים את מפתחות הבקרה מחוץ ל-Cloud de Confiance, כך של-Google אף פעם לא תהיה גישה למפתחות הבקרה הפרטיים שלכם.

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

השימוש ב-Single-tenant Cloud HSM כרוך בעלויות. למידע על מחירים, אפשר לעיין במאמר בנושא תמחור של Cloud KMS.

אימות מבוסס-קוורום

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

לפעולות שנדרש אימות קוורום כדי לבצע אותן יש שלושה שלבים:

  1. הצעה: אדמין של מופע מציע פעולה – לדוגמה, רישום של מפתח בקרה חדש. ההצעה יוצרת תמונת מצב בלתי ניתנת לשינוי של המצב הנוכחי של המערכת. התוקף של הצעות פג אחרי 24 שעות, ואפשר לבטל אותן בכל שלב עד להפעלת הפעולה שאושרה.

  2. אישור: מספר האדמינים הנדרש צריך לחתום על האתגרים באמצעות מפתח הבקרה הייחודי שלהם. כל אתגר חתום מציין אדמין שמאשר את הפעולה. כשיש מספיק אתגרים חתומים, אדמין של המופע מעלה אותם כדי לאשר את ההצעה. אם האתגרים תקפים ותוקף ההצעה לא פג, ההצעה מאושרת.

  3. ביצוע: אחרי שההצעה מאושרת, אבל לפני שהתוקף שלה פג, אפשר להריץ את הפעולה המוצעת.

יכולות של Cloud HSM עם דייר יחיד

בקטע הזה מוסבר על יכולות הליבה של Cloud HSM עם דייר יחיד.

ניהול מכונות

האדמינים שלכם מנהלים את מחזור החיים של מופעי Single-tenant Cloud HSM.

  • יצירת מכונה וירטואלית: הקצאת מכונה וירטואלית חדשה באזור יחיד. תהליך היצירה מחייב הגדרה של אימות קוורום.
  • קבלת מידע על מופע: אפשר לשלוח שאילתה למופע כדי לקבל את המטא-נתונים וההגדרות שלו. הפעולה הזו לא מחייבת אימות קוורום.
  • השבתה והפעלה של מופע: אפשר להשבית מופע באופן זמני, וכך לבטל את הגישה של Google למחיצות. אפשר להפעיל את המופע מאוחר יותר. שתי הפעולות מחייבות אימות קוורום. הפעלת המופע מאפסת את disableDate ל-730 ימים ממועד ההפעלה. בזמן שהמופע מושבת, כל המפתחות שנוצרו במופע לא זמינים, וכל הפעולות שמנסות להשתמש במפתחות האלה נכשלות.
  • רענון מכונה: כדי שהמכונה תהיה זמינה, צריך לרענן אותה באופן קבוע. צריך לרענן את המקרים כל 730 ימים או פחות. לכל מופע יש disableDate שמציין מתי יחול איחור בעדכון המופע. רענון המופע מאפס את הערך disableDate ל-730 ימים מהרגע שבו בוצע הרענון. כדי לבצע את הפעולה הזו נדרש אימות קוורום. מופעים שלא ירעננו לפני השעה disableDate יושבתו באופן אוטומטי.
  • מחיקת מכונה: אתם יכולים למחוק מכונה. מחיקה של מופע משמידה באופן סופי את כל המפתחות שנוצרו במופע הזה. זו פעולה הרסנית שאי אפשר לבטל. אל תמחקו מופע אלא אם אתם רוצים לבצע מחיקה קריפטוגרפית של כל הנתונים שמוצפנים באמצעות מפתחות שנוצרו במופע. כדי לבצע את הפעולה הזו נדרש אימות קוורום.

ניהול מפתחות

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

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

שיטות מומלצות לשימוש ב-Cloud HSM עם דייר יחיד

כדאי לפעול לפי השיטות המומלצות הבאות כשמשתמשים ב-Single-tenant Cloud HSM:

  • שעבוד פרויקטים: אפשר להשתמש בשעבוד פרויקטים כדי להגן על פרויקטים שמכילים מופעים פעילים של Cloud HSM עם דייר יחיד. אם מוחקים פרויקט שמכיל מופע של Single-tenant Cloud HSM, אי אפשר לשחזר את המפתחות שנוצרו במופע הזה.
  • אסימונים פיזיים: אפשר להשתמש באסימונים פיזיים כדי לשמור את המפתחות הפרטיים של האימות הדו-שלבי של האדמינים במופע. חשוב לאחסן את האסימונים הפיזיים האלה באופן מאובטח. אם תאבדו את הרוב הדרוש של המפתחות, Google לא תוכל לעזור לכם לקבל גישה מחדש למופע. מכיוון שצריך לעדכן את המכונות באופן קבוע, אם לא יהיה רוב של מפתחות, המכונה תושבת בסופו של דבר.
  • מפתחות גיבוי: רצוי לרשום לפחות מפתח אחד נוסף לאימות דו-שלבי, בנוסף למפתחות שנמצאים אצל חברי הקוורום. חשוב לשמור את מפתחות הגיבוי במקום בטוח שאפשר לגשת אליו אם מפתח של חבר בקוורום אבד או נגנב.
  • הפרדת תפקידים: חשוב לשמור על הפרדת תפקידים בין האדמינים של המופע. הצעת השינוי, האישור והביצוע דורשים תפקידים נפרדים ב-IAM, שצריך לחלק בין שני אנשים לפחות, כך שאף אדם לא יקבל את ההרשאות של כל שלושת התפקידים. אם לאדם מסוים יש את כל ההרשאות הבסיסיות, הסיכון לאובדן נתונים בשוגג או במכוון גבוה יותר.
  • הפצה של מפתחות: חשוב לוודא שהמפתחות הפרטיים של האימות הדו-שלבי מופצים בצורה מאובטחת בין אנשים מהימנים. אף אדם לא צריך להחזיק מספיק מפתחות פרטיים כדי להשיג קוורום. אם לאדם יש גישה למספיק מפתחות פרטיים כדי להגיע לגודל הקוורום הנדרש, יש סיכון גבוה יותר לאובדן נתונים מקרי או מכוון.
  • רענון לוח הזמנים: כדאי לכלול את רענון המכונות של Single-tenant Cloud HSM בהליכי התחזוקה השוטפים. צריך לעקוב אחרי disableDate של כל מופע ולהשלים פעולת רענון לפני הזמן הזה. כדי לרענן את המופע, צריך אישור של קוורום, לכן חשוב להציע את פעולת הרענון מספיק זמן מראש כדי שההצעה תוכל לקבל אישור ולהתבצע לפני disableDate.

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