שיטות מומלצות להפעלת קצה עורפי של IoT ב-Google Cloud

Last reviewed 2024-12-06 UTC

במסמך הזה מפורטות שיטות מומלצות לאבטחה של ניהול והפעלה של קצה עורפי (backend) של האינטרנט של הדברים (IoT) ב- Google Cloud. בפתרון IoT, קצה עורפי של IoT מחבר בין מכשירי קצה למקורות אחרים. המאמר הזה מתמקד בשרתי קצה עורפיים (backend) של IoT הבאים: ברוקר של פרוטוקול MQTT ופלטפורמת IoT.

המסמך הזה הוא חלק מסדרת מסמכים שמספקים מידע על ארכיטקטורות IoT ב- Google Cloud ועל מעבר מ-IoT Core. מסמכים אחרים בסדרה הזו כוללים את:

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

ארכיטקטורת IoT

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

התרשים הבא מתאר את ארכיטקטורת ה-IoT.

ארכיטקטורת קצה עורפי של IoT.

בארכיטקטורה מוצגים השירותים שנדרשים לשלושת התהליכים הבאים:

  1. הקצאת הרשאות ידנית של אישורים, התהליך שצריך להשלים כדי להכין מכשיר קצה להגדרה.

  2. אימות והרשאה, כולל סכימת האימות שבה משתמשים מכשיר הקצה ושרת ה-MQTT או פלטפורמת ה-IoT כדי לאמת אחד את השני.

  3. חיבורים בין מכשירי קצה לבין שירותי Google Cloud , שהם משימות שמכשיר הקצה משלים כדי להתחבר למשאבי ענן ולהעלות או להוריד נתונים.

המסמך הזה מתמקד בעיקר בשיטות מומלצות לאבטחה של הקצאת הרשאות ואימות.

הארכיטקטורה משתמשת בשילוב של השירותים והתכונות הבאים:

  • מכשיר קצה (כמו מכשיר רפואי) שאתם פורסים בקצוות של הסביבה ושנמצא בקרבה גיאוגרפית לנתונים שאתם רוצים לעבד. מכשירי הקצה מתחברים באופן דו-כיווני ל-IoT backend, כלומר הם יכולים לשלוח הודעות ל-IoT backend ולקבל ממנו הודעות.
  • עורף קצה של IoT שיכול להיות ברוקר MQTT או פלטפורמת IoT.
    • ברוקר MQTT מספק ממשק מאובטח למכשירי קצה כדי להתחבר באמצעות פרוטוקול MQTT. לשרתי MQTT חסרות יכולות לזיהוי מכשירים ולניהול מכשירים, והם מסתמכים על מערכות חיצוניות כדי לספק אותן.
    • פלטפורמת IoT היא אפליקציה בענן שמכשירי קצה מתחברים אליה ומתקשרים איתה. פלטפורמות IoT מספקות ממשק מאובטח למכשירי קצה כדי להתחבר באמצעות פרוטוקול MQTT. לכל פלטפורמת IoT יש הטמעה משלה של אבטחה שקובעת איך היא מאמתת ומאשרת מכשירי קצה ואיך היא מנהלת את זהויות המכשירים.
  • מאגר מרכזי של אישורים שמארח את האישורים של כל מכשירי הקצה.
  • משאבי Cloud שמכשירי Edge צריכים לגשת אליהם.

הקצאת מכשיר קצה

כדי שמכשיר קצה יוכל להתחבר לעומסי העבודה של ה-Backend, צריך להקצות אישור למכשיר הקצה. יש שני תרחישים עיקריים שקובעים איך מקצים את האישור:

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

  • אם אתם משתמשים במכשירים בהתאמה אישית, תהליך ההקצאה הראשוני מתבצע במהלך הייצור של המכשירים, ואתם צריכים לשלב את תהליך ההקצאה עם הספקים והיצרנים שלכם.

בשני המקרים, צריך ליצור אישורים למכשירים עם שרשרת מהימנות שמקשרת לרשות אישורי בסיס (CA). האישורים האלה מאמתים את זהות המכשיר ועוזרים לוודא שעדכונים ושינויים שמתבצעים במכשיר נעשים על ידי גורמים מהימנים. כדי לבצע את המשימות הבאות, צריך להשתמש ברשות אישורים כמו Certificate Authority Service:

כדי להקצות אישור למכשיר, צריך לבצע את המשימות הבאות:

  • אם במכשיר שלכם יש פתרון אבטחה מבוסס-חומרה ועמיד בפני שיבוש, כמו רכיב מאובטח (SE) או מודול אבטחה לחומרה (HSM) שמאחסן את המפתחות הפרטיים באופן מקומי, והמפתחות הפרטיים אף פעם לא נחשפים חיצונית, צריך לבצע את הפעולות הבאות:

    1. יוצרים את זוג המפתחות הציבורי/פרטי באמצעות פתרון האבטחה שמבוסס על חומרה ונתמך על ידי המכשיר.
    2. מבקשים אישור באמצעות בקשת חתימה על אישור (CSR).

  • אם אתם לא משתמשים בפתרון אבטחה מבוסס-חומרה כדי ליצור זוג מפתחות ציבורי/פרטי, אתם יכולים להשתמש ב-CA כדי ליצור את המפתחות ואת האישור. מידע נוסף מופיע במאמר שימוש במפתח שנוצר אוטומטית. האישור שמורידים באמצעות השיטה הזו כבר חתום.

אחרי שיוצרים אישור למכשיר וחותמים עליו, מתקינים את האישור החתום במכשיר הקצה ומאחסנים אותו במאגר מרכזי של אישורים, כמו Secret Manager.

מידע נוסף זמין במאמר איך פורסים תשתית של מפתח ציבורי מהימנה ומאובטחת באמצעות Google Cloud CA Service (PDF).

מידע על שיטות מומלצות אחרות להקצאת הרשאות זמין במאמר שיטות מומלצות להקצאת הרשאות אוטומטית ולהגדרה של מערכות ושרתים מסוג Edge ו-Bare Metal.

יש שלושה סוגים של אישורים שמשמשים לאבטחת פתרון IoT:

  • אישור ה-CA הבסיסי מספק את הבסיס לשרשרת האמון של כל האישורים האחרים במערכת. עומסי העבודה של ה-Backend משתמשים באישור הבסיסי כדי לאמת את אישורי הלקוח, והמכשירים ההיקפיים משתמשים באישור הבסיסי כדי לאמת את אישור השרת. צריך להפיץ את אישור הבסיס גם ל-IoT backend וגם למכשירי Edge.

  • אישורי רשויות האישורים ברמת הביניים מספקים שרשרת מהימנות שמבוססת על רשות האישורים ברמה הבסיסית. אפשר להשתמש ב-CA ביניים להקצאת הרשאות או לצרכים תפעוליים, כמו מתן גישה ל-CA ביניים ליצרנים, או ליישום תהליכים גמישים לניהול CA.

  • האישורים של השרת משמשים לאבטחת נקודות הקצה שנחשפות על ידי הקצה העורפי של IoT. יש לכם אישורי שרת לאלגוריתמי ההצפנה השונים שנקודות הקצה צריכות לתמוך בהם. אישורים לשרת מקושרים לאישורי CA ברמה הבסיסית. מנהל סודות מנהל ומאחסן את החלקים הפרטיים והציבוריים של אישורי השרת. צריך להגדיר את העורף של ה-IoT עם אישורי השרת והמפתחות הפרטיים התואמים שלהם.

  • אישורי הלקוח משמשים לזיהוי מכשירי קצה. לכל מכשיר קצה יש לפחות אישור לקוח אחד, כלומר מספר האישורים שיש לכם גדל עם מספר מכשירי הקצה בסביבה שלכם. אישורי לקוח מקושרים לאישורי CA בסיסיים. צריך להפיץ אישורי לקוח למכשירי הקצה ולעורף של IoT.

תהליך ליצירת אישור למכשיר באמצעות HSM או SE

בתרשים הבא אפשר לראות איך מוקצה אישור למכשיר כשמשתמשים ב-HSM או ב-SE.

תהליך ליצירת אישור מכשיר.

בתרשים הזה מתרחשים השלבים הבאים:

  1. מכשיר הקצה יוצר את זוג המפתחות הציבורי בחומרה.
  2. מורידים את המפתח הציבורי ויוצרים עבורו את בקשת חתימת האישור (CSR).
  3. שולחים את ה-CSR לרשות האישורים כדי לבקש אישור.
  4. רשות האישורים מבצעת את הפעולות הבאות:
    1. חתימת האישור.
    2. הפרופיל להקצאת הרשאות ידנית מחזיר את האישור החתום.
  5. כלי ההקצאה משלים את הפעולות הבאות:
    1. שולח את האישור החתום למכשיר הקצה.
    2. שמירת האישור החתום במאגר האישורים המרכזי.
  6. מכשיר הקצה מאחסן את האישור במיקום מאובטח.

תהליך ליצירת אישור מכשיר באמצעות רשות האישורים

בתרשים הבא מוצג תהליך הקצאת אישור למכשיר כשמשתמשים ב-CA.

תהליך ליצירת אישור מכשיר.

בתרשים הזה מתרחשים השלבים הבאים:

  1. מנהל ההקצאות (provisioner) מבקש מרשות האישורים לשלוח תעודה חתומה למכשיר.
  2. רשות האישורים מבצעת את הפעולות הבאות:
    1. יוצר זוג מפתחות ציבורי/פרטי וחותם על המפתח הציבורי.
    2. הפרוביזיונר מחזיר את אישור המכשיר ואת המפתח הפרטי.
  3. כלי ההקצאה משלים את הפעולות הבאות:
    1. שליחת האישור והמפתח הפרטי למכשיר קצה.
    2. מאחסן את האישור ואת המפתח הפרטי במאגר האישורים המרכזי.
  4. מכשיר קצה מאחסן את האישור ואת המפתח הפרטי במיקום מאובטח.

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

אימות מכשירים לפני חתימה על אישורים

כדי ליצור אישור מכשיר (במכשיר או באמצעות CA), המכשיר וה-CA צריכים לתקשר ולאמת זה את זה.

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

כדי למנוע ממכשירים זדוניים לתקשר עם רשות האישורים (CA), מומלץ לבצע את הפעולות הבאות:

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

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

  • המכשיר עדיין לא יצר אישור.
  • המכשיר עדיין לא שלח בקשת חתימה על אישור (CSR) לרשות האישורים (CA).
  • רשות האישורים עדיין לא שלחה את האישור החתום בחזרה למכשיר.

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

  1. יוצרים אישור הקצאת הרשאות שמשמש רק לאימות המכשיר מול תשתית חתימת האישורים.
  2. חותמים על אישור ההקצאה באמצעות רשות האישורים.
  3. מאחסנים את אישור ההקצאה החתום ב-SE או ב-HSM במכשיר.
  4. מאחסנים את אישור ההקצאה החתום ב Google Cloud קצה העורפי.

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

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

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

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

שיטות מומלצות לזהות המכשיר

בקטע הזה מתוארות שיטות מומלצות לשימוש בזהויות של מכשירים.

שימוש בספק זהויות עם ברוקרים של MQTT

ברוקרי MQTT מאמתים מכשירי קצה באמצעות פרטי כניסה למכשיר שסופקו על ידי תוספים, מסדי נתונים וקבצים. כדי לנהל את זהויות המכשירים באופן שיטתי וניתן להרחבה, צריך להשתמש בספק זהויות (IdP). ספק ה-IdP מנהל את הזהויות ואת פרטי הכניסה של כל המכשירים, ומשמש כמקור המהימן העיקרי לזהויות המכשירים.

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

שימוש בזהויות הדיגיטליות של פלטפורמת ה-IoT כמקור אמין

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

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

שיטות מומלצות לקישוריות לרשת

חשוב לאבטח את הקישוריות לרשת מהסיבות הבאות:

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

מומלץ להשתמש ב-Transport Layer Security ‏ (TLS) כדי להגן על התקשורת ברשת בין מכשירי הקצה לבין עומסי העבודה בעורף.

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

הוראות לשימוש ב-TLS מופיעות במאמרים Standalone MQTT broker architecture on Google Cloud ו-IoT platform product architecture on Google Cloud.

שיטות מומלצות לניהול אישורים של שרתי MQTT

בקטע הזה מתוארות שיטות מומלצות לניהול אישורים כשמשתמשים בשרתי MQTT.

אחסון אישורים באופן מרכזי

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

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

שימוש בפתרון לאחסון ולניהול סודות, כמו Secret Manager או HashiCorp Vault. ‫Secret Manager מאפשר ליצור גרסאות של פרטי הכניסה של המכשיר, לעדכן אותם ולבטל את התוקף שלהם, וגם לנהל את מדיניות הגישה לפרטי הכניסה.

בפלטפורמת IoT, מטמיעים גישה לפרטי הכניסה באמצעות גישה ל-Secret Manager API.

הגנה על אישורים במכשירי קצה

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

סנכרון של מאגר האישורים המרכזי עם מאגר האישורים של ברוקר ה-MQTT

לשרתי MQTT נדרשת גישה לאישורי לקוח לצורך אימות מבוסס-אישורים, ולכן צריך לסנכרן את מאגרי האישורים של שרתי MQTT עם מאגר האישורים המרכזי. מוודאים ששינויים במאגר האישורים המרכזי, כמו הוספה, עדכון ומחיקה של אישורים, מסונכרנים עם מאגר האישורים של ברוקר MQTT. ברוקרים של MQTT משתמשים במאגרי אישורים כמו MySQL,‏ PostgresDB ו-Java Key Store. בהתאם לחנות האישורים שבה משתמש ברוקר ה-MQTT, מוודאים שהתהליכים הבאים קיימים:

  • תהליך שמנטר שינויים במאגר המרכזי של האישורים ושולח התראות לתהליך הסנכרון.
  • תהליך שבו שינויים במאגר המרכזי של האישורים מסונכרנים עם מאגר האישורים שמשמש את שרת ה-MQTT.

כשמשתמשים ב-Secret Manager כמאגר אישורים, אפשר להשתמש בהתראות על אירועים כחלק מתהליך המעקב. אפשר להטמיע את תהליך הסנכרון כמאזין לתזכורות לאירועים.

הפצה מאובטחת של אישורים למכשירי קצה

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

ערוצי התקשורת העיקריים להפצת אישורים הם:

  • נתיב ישיר מהקצה העורפי של IoT למכשירי הקצה דרך ערוצי תקשורת קיימים.
  • נתיב עקיף שבו מכשירי קצה מבקשים ומורידים את האישורים.

במהלך הפצת האישורים, נדרשים הרכיבים הבאים:

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

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

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

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

  1. רכז ההפצה מקבל פרטי גישה ממאגר האישורים.
  2. רכז ההפצה מעביר את פרטי הגישה לאישור למכשירי הקצה, יחד עם מידע נוסף כמו כתובת ה-URL להורדה.
  3. ההנדלר של העדכון במכשיר מקבל את פרטי הגישה, שומר את המידע באופן זמני ומאשר את הקבלה.
  4. העדכון יתבצע כשהמכשיר לא יהיה פעיל. ה-handler של העדכון משתמש בפרטי הגישה כדי להוריד אישורים ממאגר פרטי הכניסה.
  5. אחרי שהאישורים מורדים, מנהל העדכונים ממשיך בתהליך של רוטציית האישורים, שמתואר בקטע רוטציית אישורים.

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

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

רוטציה אוטומטית של אישורים

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

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

במהלך החלפת האישורים, נדרשים הרכיבים הבאים:

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

כדי להחליף אישורים, פתרון ה-IoT מבצע את השלבים הבאים:

  1. במהלך תהליך הרוטציה נשלחת הודעת אתחול למכשיר קצה כדי להתחיל את רוטציית האישורים.
  2. ההודעה על ההפעלה מאושרת על ידי המטפל בסבב האישורים של המכשיר, ששולח תגובה בחזרה למשימת הסבב.
  3. תהליך הרוטציה מבקש אישור חדש מרשות האישורים. הבקשה הזו דומה לבקשת הקצאת אישורים, אבל המפתחות ובקשת החתימה על האישור נשלחים כהודעות של ברוקר MQTT.
  4. אחרי קבלת האישור החדש מרשות האישורים, משימת הרוטציה מחלקת את האישור למאגר האישורים המרכזי ולמכשיר הקצה. הוא גם מסנכרן את האישור עם מאגר האישורים של ברוקר ה-MQTT.
  5. ה-handler של רוטציית אישורי המכשיר מאחסן את האישור החדש ומפעיל חיבור חדש עם ברוקר ה-MQTT באמצעות האישור החדש.
  6. אחרי שהחיבור החדש נוצר, המטפל ברוטציה של אישורי המכשיר שולח הודעה שהפעולה הושלמה לשרת ה-MQTT.
  7. אחרי שמקבלים את ההודעה על השלמת התהליך, תהליך הרוטציה מבטל את התוקף של האישור הישן במאגר האישורים המרכזי.

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

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

מידע נוסף על רוטציה של סודות באמצעות Secret Manager זמין במאמר רוטציה של סודות.

שיטות מומלצות לניהול אישורים בפלטפורמות IoT

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

שיטות מומלצות לאימות באמצעות שרת MQTT

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

בקטעים הבאים מפורטות שיטות מומלצות לשימוש בשיטות אימות כשמשתמשים בשרתי MQTT.

בחירת שיטת האימות לשרתי MQTT

סוגים שונים של עורפי IoT תומכים בשיטות אימות שונות. אלה השיטות הנפוצות:

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

כחלק מתקן MQTT, ברוקרי MQTT תומכים באימות באמצעות שם משתמש וסיסמה כברירת מחדל עבור חבילות MQTT CONNECT.

חבילת MQTT CONNECT מכילה גם את השדה Client Identifier שבו אפשר להשתמש כדי לזהות באופן ייחודי את הלקוח בשרת MQTT. מכשירי Edge שולחים את חבילת MQTT CONNECT לשרת MQTT Broker כשהם יוצרים חיבור.

בנוסף לשדות של שם המשתמש, הסיסמה ומזהה הלקוח בחבילת MQTT CONNECT,‏ MQTT 5.0 תומך באימות משופר שמאפשר ליצור תהליכי אימות של אתגר ותגובה. ‫MQTT 5.0 מאפשר AUTH חבילות מרובות של חילופי נתונים בין מכשיר הקצה לבין ברוקר ה-MQTT.

שימוש במאגרי סיסמאות עם אימות באמצעות שם משתמש וסיסמה

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

מוודאים שהסיסמאות מוצפנות במנוחה ובתנועה, באופן הבא:

כדאי להשתמש באימות מבוסס-טוקן

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

אסימוני JWT (‏JSON Web Tokens) הם דרך להטמיע אימות מבוסס-אסימונים. מכשירי Edge יכולים ליצור את ה-JWT ולאמת את עצמם מול ברוקר ה-MQTT. ה-JWT מוטמע בחבילת ה-MQTT CONNECT כשדה הסיסמה.

היתרונות של JWT הם:

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

כדאי לשקול סכימות אימות מותאמות אישית

חלק משרתי ה-MQTT תומכים במנגנונים ובפרוטוקולים שונים של אימות. לדוגמה, אם בשרת פרוטוקול MQTT שלכם יש תמיכה בסכימות אימות בהתאמה אישית, אתם יכולים להגדיר אותו כך שיתמוך באפשרויות הבאות:

  • פרוטוקולי אימות בתקנים של התעשייה, כמו OpenID Connect,‏ Security Assertion Markup Language‏ (SAML),‏ LDAP,‏ Kerberos ו-Simple Authentication and Security Layer‏ (SASL). הפרוטוקולים האלה מעבירים את אימות המכשיר לספקי הזהויות הקיימים שלכם. חלק משרתי ה-MQTT תומכים באימות משופר ובמנגנוני אימות שניתנים להרחבה. אתם יכולים להשתמש בהם כדי להרחיב את שרת ה-MQTT כך שיתמוך בפרוטוקולים חדשים ובספקי זהויות.
  • אימות הדדי מבוסס-אישור. חלק משרתי פרוטוקול MQTT תומכים בסכימת אימות הדדית, כמו אימות שמבוסס על mTLS.

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

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

שימוש בחשבונות שירות למטרה יחידה כדי לגשת Google Cloud למשאבים

הגישה למשאבים Google Cloud מנוהלת באמצעות מדיניות הרשאה ב-IAM שמקשרת בין הרשאת הגישה למשאב לבין קבוצה של חשבונות משתמשים. חשבונות משתמשים, חשבונות שירות וקבוצות הם דוגמאות לחשבונות משתמשים. חשבונות שירות משמשים בדרך כלל אפליקציה או עומס עבודה כדי לבצע קריאות מורשות ל-API של משאבי ענן. חשבונות שירות מאפשרים למכשירי IoT edge לגשת למשאבי ענן.

מכיוון שמזהה המכשיר מנוהל על ידי הבק-אנד של IoT, עליך למפות זהות בין הבק-אנד של IoT לבין IAM כדי שמכשיר הקצה יוכל לגשת למשאביGoogle Cloud .

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

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

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

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

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

בדרך כלל, מכשירי הקצה מתקשרים עם פלטפורמת ה-IoT באמצעות MQTT. עם זאת, במקרים ספציפיים, יכול להיות שהמכשירים שלכם יצטרכו גישה ישירה למשאבים ב-Google Cloud . לדוגמה:

  • כדי להוריד תוכן, למכשיר קצה נדרשת גישת קריאה בלבד לקטגוריה של Cloud Storage במהלך תהליך ההורדה בלבד.
  • כדי להעלות נתונים לקטגוריה של Cloud Storage, למכשיר קצה צריכה להיות הרשאת כתיבה לקטגוריה.

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

כדי להפיץ אסימוני גישה למשאבי ענן למכשירים, צריך להגדיר איחוד של Workload Identity בין ספק הזהויות של המכשיר לביןGoogle Cloud. כדי לתמוך באיחוד שירותי אימות הזהות של עומסי עבודה, צריך לוודא ששרת ה-backend של ה-IoT עומד בדרישות של איחוד שירותי אימות הזהות של עומסי עבודה ופועל בהתאם לשיטות המומלצות לאבטחה שמתאימות לתרחישי השימוש שלכם.

כדי לגשת למשאבים של Google Cloud באמצעות איחוד שירותי אימות הזהות של עומסי עבודה, מכשירי הקצה צריכים להטמיע את תהליך העבודה של המרת אסימון OAuth 2.0, שכולל את השלבים הבאים:

  • המכשיר קורא ל-Security Token Service ומספק את פרטי הכניסה שלו.
  • שירות אסימון האבטחה מאמת את הזהות של מכשיר ה-Edge על ידי אימות פרטי הכניסה שמכשיר ה-Edge סיפק לספק הזהויות של המכשיר.
  • אם אימות הזהות מצליח, Security Token Service מחזיר אסימון גישה למכשיר הקצה.
  • מכשיר הקצה משתמש באסימון הזה כדי להתחזות לחשבון השירות הייעודי ולקבל אסימון גישה לטווח קצר מסוג OAuth 2.0.
  • המכשיר משתמש באסימון הגישה לטווח קצר מסוג OAuth 2.0 כדי לבצע אימות באמצעות ממשקי Google Cloud API ולקבל גישה למשאבי הענן הנדרשים.

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

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

מעקב וביקורת של הגישה למשאבים בענן

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

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

שותפים ביצירת התוכן

מחברים:

  • Charlie Wang | Cloud Solutions Architect
  • Marco Ferrari | Cloud Solutions Architect