אבטחת מידע בעת תכנון האינטרנט של הדברים (IoT): מנקודת הקצה ועד הענן
מאת:
אלכסנדר דמיש, 7.6.15, 18:30
אבטחה נחשבת לאתגר עיקרי המונע מ-IoT להתקדם מהר יותר ליישום. עם זמינות של כל הפלטפורמות עבור מערכות מותקנות והפעלות חדשות, החל מרמת המכשיר ועד לענן, ניתן לטפל באבטחה מנקודת מבט מערכתית.
כאשר חברה או צוות פיתוח שוקלים ליישם אינטרנט של הדברים (
Internet of Things), חייבים לחשוב על הפתרון מקצה לקצה בטרם ניגשים לעבודה. נקודת הגישה (
Gateway) היא כנראה מרכיב חשוב בפתרון, אבל בדרך אליה יש תשתית רבה, שצריך לחשוב עליה.
כאשר שוקלים את הדברים,
גישה פתוחה היא חיונית לתכנון האינטרנט של הדברים (IoT) משום שתחום זה עוסק בשיתוף וקישוריות, ולכן סטנדרטים פתוחים ואינטגרציה עם הסביבה הרחבה הם הכרחיים. לכן, המטרה היא לאפשר אינטגרציה של אפליקציות חיצוניות וספקים אחרים עם התשתית.
קיימים מספר מרכיבים משמעותיים בתכנון פתרון אינטרנט של הדברים אותם אסקור להלן:
ניהוליות
Figure 1- Building blocks of any IoT solution
אבטחת מידע היא דרישה מרכזית בכל פתרון אינטרנט של הדברים, לא רק עבור תקשורת בין נקודת הקצה לענן, אלא גם עבור כל המכשירים עצמם. גורמים חשובים נוספים כוללים השהיה (
Latency) בתקשורת, ומאפיינים של בטיחות פונקציונאלית כפי שמוגדר בתקן
IEC61508, במיוחד כאשר מדובר בתכנון של אוטומציה תעשייתית.
עבור תוכניות
IoT תעשייתיות, מפתחים צריכים גם לשקול את מחזור החיים הטיפוסי של כל חלק בציוד הנמצא בשימוש בסביבה התעשייתית. תקופת שירות של 20 עד 30 שנה אינה נדירה, במיוחד עבור רכיבים גדולים במפעלי תעשייה ובשליטה בתהליכים.
בגלל הקושי לחזות כיצד תיראה בעתיד מערכת מקצה לקצה, ההטמעה של סטנדרטים, שיאפשרו שדרוג מערכות קל, היא מרכיב חיוני.
תקשורת
שימוש בפרוטוקולים פתוחים לתקשורת מבוססת
IP כגון
MQTT,
XMTP ו-
M2M -
Machine to Machine קלי משקל, הוא חשוב. בין פרוטוקולים אלה יש מספר קווי דמיון והם אידיאלים לשימוש ב"שער הגישה". בעיקר, יש להם את היכולת לעבוד על רשת, שאינה תמיד בפעולה.
בשונה מרשתות
IT מסורתיות, בהן אם כבל מתנתק אז התקשורת כושלת לחלוטין, פרוטוקולים אלה תומכים במודל מפרסם/מנוי
Publisher/Subscriber. בנוסף, MQTT משתמש בגישת מפרסם/מנוי כאשר אתה מחליט איזה מידע אתה צריך ומבקש אותו. הפרוטוקול מבוסס אירועים ומספק גישה פתוחה לחלוטין.
פרוטוקולים מבוססי
IP, כגון
MQTT, הם גם שקופים עבור סטנדרטים בצמיחה כגון
Time-Sensitive Networking. בראש ובראשונה, הוא הופך לחלק מתקינת
IEEE 802.1. שנית, הוא פועל כ-
ISO ב-
Layer 2, דבר המוסיף תקשורת דטרמינסטית באופן שקוף, בנוסף ליצירת חציצה מאובטחת ובטוחה עבור פרוטוקולים קיימים של אפליקציות.
Figure 2
קישוריות
מרכיב חשוב נוסף עבור יישומי האינטרנט של הדברים הוא, שההשהייה (
latency) בתקשורת צריכה להיות מובטחת. אם מסתכלים על תקשורת
IP רגילה, אנו יודעים כי ל-
TCP/IP אין השהייה מובטחת כלל. למעשה, אתה יכול בקלות לקבל השהייה של מאות אלפיות שניה בגלל ניקוי
Buffers.
TCP/IP לא נוצר כדי להשיג השהייה נמוכה.
לחלק מהפרוטוקולים יכולה להיות השהייה נמוכה יותר באמצעות שימוש ב-
UDP, אבל עדיין לא מדובר בהבטחה להשהייה נמוכה, במיוחד אם אתה עובר דרך רשת מתגים. בנוסף, המשמעות של שימוש ב-
UDP היא, שאתה לא יכול לשלוט באיכות השירות. כתוצאה מכך, אין לך את היכולת לתכנן ולמדוד את תרחישי ההשהייה הגרועים ביותר לרוחב הרשת. גם כאן, סטנדרט הרשת
Time-Sensitive נכנס לעניין. כאשר משתמשים במתגי
Layer 2 מתאימים ניתן להבטיח השהייה.
Figure 3
Security
Figure 4 -
End-to-end system based on safety and security requirements
מאפייני האבטחה
ישנם מספר מאפייני אבטחה שחשוב לשקול. כיצד מאתחלים את נקודת הקצה או נקודת הגישה הוא אחד מהם. הצורך להבטיח כי אימג' האתחול שלך מאושר ומאובטח הוא חיוני. אם זה לא יקרה, הרצת גרסה, שעברה שינוי, יכולה בוודאות גבוהה לעקוף את כל אמצעי האבטחה האחרים בהם משתמשת האפליקציה לנתונים ותקשורת.
לדוגמא, מנקודת מבט של אתחול מאובטח, יש פלטפורמות המשתמשות במאפיינים ייחודיים של סיליקון כדי להבטיח אחסון מאובטח של המפתח. אם אתה מייצר תהליך אתחול מאובטח עם אימג' חתום ומוצפן, שימוש במנגנון
Challenge and Response יכול לספק וודאות של 100%, כי המפתח בשימוש מאומת ומתוקף.
בהמשך יש לטפל גם באבטחה של ה-
Run Time. לדוגמא, בפלטפורמות שונות ניתן לוודא, שאם מישהו ניסה לשנות את האפליקציה אז מזהים זאת באמצעים מסוימים ברמת מערכת ההפעלה.
ניתן להשתמש גם בטכנולוגיה של
Intel Security כדי להשיג זאת, כשהיא מבוססת על הקצאת הרשאות לתהליכים כדי להפעיל משאבים ספציפיים. אם תהליך מנסה לגשת למשאב ללא הרשאה מתאימה, אז ניתן להסיר אותו ולהדליק התרעה לצורך בדיקה.
אבטחה בתוך תקשורת הנתונים גם היא חיונית כאשר ישנן דרכים רבות לביצוע האבטחה. שיקול נוסף לצרוך אבטחה כוללת הוא הביטחון כי כאשר מסירים נקודת קצה או רשת, אז יש צורך לוודא, שכל הנתונים במכשיר מוסרים או מוצפנים. הסרת מכשיר מעניקה את היכולת לאחזר מפתחות אבטחה.
API
כל שער גישה לא יהיה שלם ללא היכולת לתמוך ב-
API. ממשקי
API הם אמצעי לשליטה בתקשורת נתונים מנקודת הקצה ועד לענן, כדי לאפשר רמה מסוימת של שליטה מקומית. לדוגמא, חיישן טמפרטורה פשוט מאוד המשמש כנקודת קצה לשליטה במערכת חימום. אתה יכול לאסוף את קריאות הטמפרטורה ולהחליט האם לאחד אותם ולשמור אותם באופן מקומי, או להעבירם ישירות לאפליקציית הענן. ייתכן שאפליקציית הענן תהיה זו שתחליט, נניח, שהטמפרטורה ירדה מתחת לסף מסוים ותדליק שוב את החימום.
עם זאת,
API יכול להכניס את המידע הזה אל תוך נקודת הקצה. אבל בעוד הפעלת
API ב"שער גישה" יכולה להיראות פעולה פשוטה, ישנם שיקולי אבטחה ותחזוקה. מפתחי
API נוטים להתמקד בשימוש ביוזמת
Java Open Service Gateway – המתבססת על סביבות
Run Time או שפות תכנות כגון פייתון,
node.js ו-
LUA. מנגד, יש נטיה להימנע משימוש באובייקטים של
C/C++ בגלל הסיכון הפוטנציאלי לפרצות אבטחה.
ניהול
בניה של שער גישה גמיש מחייבת יצירה של היכולת להוסיף, לעדכן או למחוק
API. ברור, שביצוע של הדברים באופן מאובטח הוא חשוב. ניהול של נקודות קצה ואפיקי התקשורת שלהם אל נקודות קצה אחרות ואל הענן חשוב גם הוא. יש עדיפות לשימוש בסטנדרטים לניהול, כגון:
OMA-DM,
LWM2M ו-
TR68, לצורך שימוש בארכיטקטורה מרובת סוכנים, שכוללת מאפיינים של ניהול המכשיר, עדכונים מהאוויר, הפעלה מאוחרת של אפליקציות, והקצאת משאבים באמצעות קבצי הגדרות.
כאשר מתמודדים עם האתגר המייגע של בניית "שער גישה פתוח" אך גם מאובטח עבור האינטרנט של הדברים, מפתחים יכולים לשקול לבסס את התכנון שלהם על פלטפורמה מוכנה, כדי להאיץ את יציאת האפליקציה לשוק. יש פלטפורמות כאלו בשוק, הן מהוות סביבת פיתוח סלקאבילית מאובטחת, לטווח ארוך, שמפשטת את הפיתוח, האינטגרציה וההפעלה של שערי גישה עבור האינטרנט של הדברים, מספקות אפשרויות לאבטחת מכשירים, קישוריות חכמה, רשת עשירה וניהול מכשיר, וכוללות מרכיבים מוכנים לשימוש, שנבנו במיוחד עבור פיתוח אפליקציות אינטרנט של הדברים.
סיכום
לצד האינטגרציה,
אבטחה נחשבת לאתגר עיקרי המונע מהאינטרנט של הדברים להתקדם מהר יותר ליישום בתחומים צומחים כגון תשתית חיונית והשוק התעשייתי. עם זמינות של כל הפלטפורמות עבור מערכות מותקנות וכן עבור הפעלות חדשות, החל מרמת המכשיר ועד לענן,
ניתן לטפל באבטחה מנקודת מבט מערכתית.
מאת:
אלכסנדר דמיש, ווינד ריבר, יוני 2015.
