שיטות מומלצות לאבטחה

בדף הזה מתוארות שיטות מומלצות לאבטחת ההתקנה של Google Distributed Cloud.

אבטחת חומרה פיזית

באחריותכם לאבטח פיזית את החומרה המחוברת של Distributed Cloud, למשל להגביל את הגישה לעובדים מורשים.

המאפיינים של Distributed Cloud במודל מחובר מבחינת אבטחה הם:

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

השרת של Distributed Cloud במודל מחובר כולל את תכונות האבטחה הבאות:

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

אם יש לכם שאלות נוספות לגבי האבטחה של המתלה הפיזי, תוכלו לפנות לנציג המכירות שלכם. Google Cloud

אבטחת פלטפורמה

פלטפורמת החומרה של Distributed Cloud במודל מחובר כוללת את תכונות האבטחה הבאות:

  • מודול פלטפורמה מהימן (TPM). מודול ה-TPM הוא שורש האמון שיוצר ומאחסן מפתחות הצפנה לכל הנתונים שמאוחסנים ב-Distributed Cloud Connected, וגם לנתונים שמתקבלים ממנו ומועברים אליו.

  • אישור פלטפורמה. אישור הפלטפורמה הוא רשומה מאובטחת מבחינה קריפטוגרפית של הזהות של TPM ושל תהליך הייצור. האישור משמש כהוכחה לתקינות שרשרת האספקה של חומרה שמחוברת ל-Distributed Cloud.

  • נעילת יציאות. כל היציאות החיצוניות והפנימיות מלבד יציאות אתרנט, כמו יציאות USB ויציאות קונסולה מסוג RS-232, מושבתות ברמת הקושחה ומופעלות רק לצורך תיקון.

אבטחה של אחסון מקומי

הציוד המחובר ל-Distributed Cloud נשלח עם סוגי האחסון הפנימיים הבאים, בהתאם לגורם הצורה:

  • מתקני Distributed Cloud במודל מחובר נשלחים עם כונני Solid State Disk ‏ (SSD).
  • שרתים מחוברים של Distributed Cloud נשלחים עם כונני דיסק בהצפנה עצמית (SED).

ב-Distributed Cloud connected נעשה שימוש ב-Linux Unified Key Setup‏ (LUKS) כדי להצפין את הכרכים הלוגיים בכל צומת של Distributed Cloud connected. יש לכם אפשרות להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) או בGoogle-owned and managed keys אריזה של המפתח להצפנת דיסק LUKS (DEK). כשמקצים צומת למאגר צמתים, הצומת יוצר מפתח DEK של LUKS ועוטף אותו בביטוי סיסמה של LUKS שמנוהל על ידי Google, שנקרא גם מפתח להצפנת מפתחות הצפנה (KEK), או במפתח שאתם מספקים דרך Cloud KMS. אתם יכולים לבחור אם להשתמש ב-Cloud KMS כשיוצרים מאגר צמתים. ‫Distributed Cloud connected משולב עם Cloud KMS באמצעות מודל הצפנת המעטפה.

‫Distributed Cloud connected מסובב אוטומטית את ביטויי הסיסמה של LUKS ו-SED לפי לוח זמנים קבוע.

בנוסף, כל מכונה שמחוברת ל-Distributed Cloud מבצעת את הפעולות הבאות בכל הפעלה במצב התחלתי (cold start):

  • אם אתם לא משתמשים ב-Cloud KMS, המכונה יוצרת KEK חדש (ביטוי סיסמה של LUKS) ומגדירה אחסון מוצפן מההתחלה.

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

הפעלת תמיכה במפתחות הצפנה בניהול הלקוח (CMEK) לאחסון מקומי

כדי להפעיל את השילוב של Cloud KMS עם Distributed Cloudconnected, מבצעים את השלבים הבאים:

  1. יוצרים אוסף מפתחות, מפתח סימטרי וגרסה אחת או יותר של מפתח לשימוש עם Distributed Cloud connected. צריך ליצור את הארטיפקטים האלה באותו Google Cloud אזור שבו נמצאת ההתקנה המחוברת של Distributed Cloud. הוראות מפורטות מופיעות במאמר יצירת מפתח.

  2. מקצים את התפקיד Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) לחשבון השירות המחובר ל-Distributed Cloud בפרויקטGoogle Cloud . צריך לעשות את זה לכל גרסת מפתח שרוצים להשתמש בה עם Distributed Cloud במודל מחובר. אם מבטלים את ההרשאה של התפקיד הזה אחרי שמשלבים את ההתקנה של Distributed Cloud Connected עם Cloud KMS, מאבדים את הגישה לנתונים שמאוחסנים במכונות של Distributed Cloud Connected.

  3. יוצרים מאגר צמתים באמצעות הדגל --local-disk-kms-key ומספקים את הנתיב המלא לגרסת המפתח שרוצים להשתמש בה במאגר הצמתים הזה.

  4. יוצרים אשכול באמצעות הדגל --control-plane-kms-key ומספקים את הנתיב המלא לגרסת המפתח שרוצים להשתמש בה עם הצומת שמריץ את מישור הבקרה של האשכול.

  5. אופציונלי: משתמשים בדגל --offline-reboot-ttl כשיוצרים את האשכול כדי לציין חלון זמן שבמהלכו צמתים שהופעלו מחדש יכולים להצטרף מחדש לאשכול בזמן שהאשכול פועל בצומת שניתן לשחזור. אם לא מציינים את חלון הזמן הזה, הצמתים שהופעלו מחדש לא יכולים להצטרף מחדש לאשכול עד שהם יוצאים ממצב הישרדות.

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

מידע נוסף זמין במאמר בנושא מפתחות הצפנה בניהול הלקוח (CMEK) במסמכי התיעוד של Cloud KMS.

שחזור וגיבוי נתונים

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

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

אבטחת רשת

תעבורת הנתונים ברשת בין חומרה שמחוברת ל-Distributed Cloud לבין Google Cloud מוצפנת באמצעות מנהרות MASQUE או TLS שמשתמשות באישורים לכל מכונה. ‫Distributed Cloud מחובר ומבצע רוטציה אוטומטית של האישורים האלה לפי לוח זמנים קבוע.

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

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

  • איסור חיבורים נכנסים ממשאבי רשת חיצוניים לרשתות משנה שמשרתות את שכבות ניהול המערכת וניהול השירות.

  • איסור חיבורים נכנסים ממשאבי רשת חיצוניים לכתובות IP של נקודות קצה (endpoints) של מישור הבקרה המקומי. מידע נוסף זמין במאמר בנושא מצב הישרדות.

מידע נוסף על הכנת הרשת המקומית לחיבור של ציוד Distributed Cloud זמין במאמר בנושא רשתות.

בפריסות של כמה מתלים, Distributed Cloud Connected תומך באבטחת בקרת גישה למדיה (MAC) בשכבה 2 (L2 MACsec) ברמת מסגרת ה-Ethernet בין מתגי האגרגטור במתלה הבסיסי לבין מתגי ToR במתלים העצמאיים.

ב-Distributed Cloud connected נעשה שימוש ב-MACsec כדי לאמת מכשירי Ethernet, לוודא את התקינות של כל פריים Ethernet שמועבר ולהצפין כל פריים שמועבר.

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

כל מכשיר שמוגדר עם MACsec צריך לעבור אימות ולהיות משויך ל-Connectivity Association (CA). חברי CA משתמשים במפתחות CA לטווח ארוך (CAK) כדי לזהות את עצמם ברשת. מפתח ה-CAK משמש ליצירת מפתחות הצפנה של סשנים בכל פעם שחבר ב-CA צריך להחליף נתונים עם חבר אחר ב-CA ברשת.

מדיניות MACsec ב-Distributed Cloud במודל מחובר

התכונה Distributed Cloud connected אוכפת את כללי המדיניות הבאים של MACsec בכל קישורי ה-Ethernet בין מתגי צבירת המתלים הבסיסיים לבין מתגי ToR של מתלים עצמאיים. אי אפשר לשנות או להשבית את המדיניות הזו.

הגדרת MACsec

‫Google מנהלת את כל ההגדרות של MACsec במודל מחובר של Distributed Cloud, כולל מפתחות ההצפנה.

ב-Distributed Cloud במודל מחובר, אסור להשתמש במנות לא מוצפנות בכל קישורי ה-Ethernet הפנימיים. אם לא ניתן לנהל משא ומתן על סשן MACsec, קישור ה-Ethernet המושפע מושבת אוטומטית.

מחזיק מפתחות MACsec

מחזיק מפתחות MACsec הוא מאגר המפתחות שמכיל את כל המפתחות הנדרשים לקישור ספציפי של Ethernet. נוצר מחזיק מפתחות ייחודי לממשק של חבילה. כל מחזיק מפתחות מכיל 4 מפתחות ראשיים ומפתח חלופי. כל מפתח ראשי תקף ל-25%.

מעבר חלופי ל-MACsec

‫Distributed Cloud connected מגדיר מפתח גיבוי של MACsec בנוסף ל-4 מפתחות ראשיים לכל קישור אתרנט פנימי. אם Distributed Cloud Connected לא מצליח לנהל משא ומתן על סשן MACsec באמצעות המפתחות הראשיים, הוא מנסה לנהל משא ומתן על סשן חלופי באמצעות המפתח החלופי. התוקף של מפתח הגיבוי לא פג.

רוטציית מפתחות MACsec

הצמתים המצטברים שמחוברים ל-Distributed Cloud והמתגים של ToR מבצעים רוטציה למפתחות ה-MACsec הראשיים שלהם באופן מיידי כשהתוקף של המפתחות האלה פג. כדי להבטיח רוטציית מפתחות בטוחה, כל מפתח קודם וכל מפתח הבא ברוטציה חופפים למשך 5 ימים.

מפתח שיוך מאובטח של MACsec

ב-Distributed Cloud Connected נעשה שימוש במפתח MACsec Secure Association Key ‏ (SAK) שנוצר באופן אקראי כדי להצפין את כל מסגרות ה-Ethernet שמועברות על ידי קישורי Ethernet פנימיים. ‫Distributed Cloud connected מבצעת שינוי מפתח מחדש על בסיס נפח באמצעות Extended Packet Numbering‏ (XPN). מפתח ה-SAK נוצר מחדש כל 6 שעות.

כדי לבדוק את סטטוס MACsec של קישור Ethernet ספציפי בין מתג צבירה של מתלה בסיס לבין מתג ToR במתלה עצמאי, משתמשים בפקודה הבאה:

gcloud edge-cloud networking networks get-status default --location=REGION --zone=us-ZONE_NAME

מחליפים את מה שכתוב בשדות הבאים:

  • ‫REGION: Google Cloud האזור שבו נוצר פרויקט היעדGoogle Cloud .
  • ‫ZONE_NAME: השם של אזור היעד המחובר של Distributed Cloud.

הפקודה מחזירה פלט שדומה לזה:

result:
  macsecStatusInternalLinks: SECURE

הערכים האפשריים של סטטוס הקישור הם:

  • ‫SECURE – סשן MACsec פעיל בקישור היעד.
  • ‫UNSECURE – סשן MACsec לא פעיל בקישור היעד.

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