הטווח אינטרנט של דברים או IoT, שתורגם לעתים קרובות עם אינטרנט של הדברים כאשר התרגום "אינטרנט של אובייקטים" יהיה מתאים יותר, הוא הפך כעת לחלק מהלקסיקון הנפוץ של העוסקים בטכנולוגיות תקשוב (Information Communication Technology, ed).
במהלך הערות אלה, יצאתי להבהיר את הטכנולוגיות שאומצו, את הרכיבים ואת בעיות האבטחה האפשריות של פתרונות IoT.
אני מתחיל לומר שלפתרונות IoT יש מאפיינים מיוחדים שהופכים אותם לייחודיים. מספר המכשירים הגדול, שהם בדרך כלל חלק מפתרון IoT, מטיל מאפייני מדרגיות המבוססים לא פחות על הביצועים כמו על הצורך בניהול ותחזוקה של פארק מותקן המאופיין בקרדינליות משמעותית ביותר (מספרים גבוהים במיוחד). כל זה בא לידי ביטוי בכמות הנתונים שיש לאחסן ולנתח.
המטרה הסופית של פתרונות IoT בתחומי היישומים השונים היא תמיד לספק כלים, לנוכח תופעה פיזית טבעית או מלאכותית, מאפשרים לנו להבין מה קורה, מדוע זה קורה ואולי מה יכול לקרות. חיישנים ומפעילים הם אפוא האמצעים המאפשרים לך לקיים אינטראקציה עם הסביבה ועם התופעה הפיזית עליה ברצונך לשלוט. לכן מדובר בניהול וניתוח של מספר רב של נתונים בעלי אופי שונה על ידי צבירה ועיבודם על מנת להפיק מהם מידע שעל בסיסם ניתן לבצע פעולות ספציפיות (באנגלית מידע בר ביצוע).
אני ממשיך לאשר כי במהלך 2-3 השנים האחרונות היה זמינות של מערך זרזים אשר העדיפו את פיתוח הטכנולוגיות הדרושות למימוש פתרונות IoT וכתוצאה מכך את תשומת הלב של התעשייה כלפי סוג זה של טכנולוגיות הוא גדל בפרופורציות. עד כה, הדיבור על פתרונות IoT אינו מייצג ניסוי גבול, אלא הצורך להתמודד עם בעיות יישום ספציפיות.
בין הזרזים התורמים לאימוץ פתרונות IoT אנו יכולים להזכיר:
- זמינות חיישנים ומפעילים מסוגים שונים ומגוונים;
- ההצעה של ספקי פתרונות הענן העיקריים של פלטפורמות המוקדשות לסביבה זו ומצוידות בפרימיטיבים שנועדו לתת מענה לחלק מהמאפיינים הספציפיים של יישומים מסוג זה;
- זמינותם של פרוטוקולי תקשורת מיוחדים המסוגלים לתמוך בייחודיות (קרדינליות, חוסן, אמינות) הדרושים בתחום ה- IoT.
לפני שנכנס לניתוח של פתרון IoT ורכיבים טכנולוגיים קשורים, כדאי להקדיש כמה מילים לרעיון החיישנים והמפעילים המייצגים את האלמנטים הבסיסיים של פתרון כזה.
החיישנים
חיישנים הם רכיבי חומרה המתמחים בקריאת פרמטר פיזי (טמפרטורה, לחץ, לחות, עוצמת אור, ...) והעברת הנתונים המזוהים בצורה דיגיטלית או אנלוגית באמצעות מערכת של כללים (פרוטוקול) המאפשרים למקלט לפרש אותו נכונה. דוגמה פשוטה מאוד יכולה להיות מדחום טמפרטורה: הוא מייצר ערך המתבטא במעלות צלזיוס או פרנהייט אשר מתגלה בדרך כלל על ידי קריאת סולם מיוחד או תצוגה קטנה.
אם המדחום מצויד במינימום היגיון להעברת ערך זה לרכיב אחר, באמצעות פרוטוקול מתאים, יצרנו חיישן טמפרטורה. מטבע הדברים, החיישנים יכולים להיות מסוגים שונים ומורכבים מאוד המסוגלים לזהות מספר כמויות פיזיות בו זמנית.
כיום ישנם חיישנים המסוגלים לזהות מעבר של אדם דרך שער (שער לוגי) ולזהות את כיוונו (כניסה או יציאה), חיישנים המסוגלים לזהות ברקודים או טביעות אצבע, חיישנים המסוגלים למדוד את המרחק היחסי בין שני אובייקטים וכן הלאה. . כל הנתונים שנאספו על ידי החיישנים חייבים להיות מקודדים כראוי לעיבוד לאחר מכן.
אם נחזור לדוגמא של חיישן הטמפרטורה, יהיה צורך גם לשלוח או לאותת את יחידת המדידה הקשורה: צלזיוס או פרנהייט. לפיכך, יש ליצור פורמט מתאים של הנתונים שנוצר על ידי החיישן לשליחה ולעיבוד לאחר מכן.
המפעילים
בעוד שהחיישנים דואגים ללכוד נתונים ולשלוח אותם לעיבוד לאחר מכן, יש צורך גם באפשרות לבצע פעולות בעקבות העיבוד המבוצע החל מהנתונים שמספקים החיישנים או על ידי מערכת בקרה. זוהי משימתם של המפעילים. כמו בעבר, דוגמה פשוטה יכולה להיות סגירה או פתיחה של מעגל עם קבלת פקודה ספציפית (דוגמא טריוויאלית מאוד: פותחן דלת הבית).
בדומה לאמור לחיישנים, מפעילים יכולים להיות גם מורכבים ורב פונקציונליים: חשבו למשל על הצורך לסובב מנוע במהירות מסוימת או על מיקום זרוע מכנית לשחרור תוכן (פתיחת מעגל). כמו כן במקרה זה, על המפעילים להיות מצוידים בפונקציות תקשורת פרימיטיביות המאפשרות קבלת פקודות ופרשנות משמעותן.
פרוטוקולי התקשורת
על כן, חיישנים ומפעילים חייבים, על מה שנאמר, להיות מסוגלים להעביר ולקבל מידע למערכת ברמה גבוהה יותר לעיבוד לאחר מכן. שים לב כי עבור חיישנים ומפעילים כאחד, התקשורת חייבת להיות בדרך כלל דו -כיוונית ולכן יש לנהל הן את השידור והן את הקליטה של הנתונים והפקודות כלפי שניהם. לדוגמה, בחיישן יתכן שניתן להגדיר מחרוזת ייחודית המזהה את מיקומה, בעוד שהמפעיל חייב להיות מסוגל לספק אינדיקציה לשגיאה אם הפונקציה המבוקשת (מיקום, מהירות, פתיחה / סגירה של איש קשר ...) אינו בר ביצוע.
מכלול הכללים והפורמטים איתם מתקשרים חיישנים ומפעילים עם מערכת עיבוד (PLC, Gateway, Edge Computer, ...) מהווה את פרוטוקול התקשורת המשמש בין ישויות אלה. פרוטוקול התקשורת חייב להתייחס למספר מצבים כדי להיות יעיל ולתמוך ביישום הפתרון המיועד.
כמה מהבעיות שיש לפתור על ידי הפרוטוקול הן:
- כיצד לפנות באופן ייחודי לחיישן / מפעיל ספציפי בהתקנה
- כיצד לתעדף את הגישה לאמצעי השידור (מי מדבר ראשון)
- מה לעשות אם אמצעי השידור עסוק (מי מדבר)
- כיצד לדווח על כל שגיאה
- כיצד לעצב את הנתונים המועברים או המתקבלים (למשל כמה סיביות להקצות לכמות ספציפית)
- כיצד לוודא כי הנתונים המועברים אינם פגומים במהלך השידור
- וכו '
הדרישות עליהן הפרוטוקולים הללו חייבים לעמוד כוללות הן פשטות היישום בהתחשב ביכולת העיבוד המוגבלת והן הצורך להפחית את צריכת הסוללות של החיישנים והמפעילים. לאחר מכן הפרוטוקולים זמינים במדיות שידור שונות: החל מצמד הנחושת הקלאסי ועד לחיבורים אלחוטיים על להקות ללא רישיון (להקות ISM). תכונה משותפת של פרוטוקולים אלה היא רוחב הפס המוגבל הנדרש להעברת נתונים כתוצאה מפשטות הנתונים המועברים.
בתחום ה- IoT ישנם פרוטוקולי תקשורת קנייניים ומתוקננים שונים, ביניהם נוכל לזכור את IO-Link, ModBus, LoraWAN, En-Ocean, השניים האחרונים במדיום שידור רדיו.
הארכיטקטורה של פתרון IoT
ברור שפתרון IoT אינו מסתיים בזמינותם הבלעדית של חיישנים ומפעילים אלא דורש נוכחות ותיאום של שורה של רכיבים המאפשרים לחלץ מידע קבלת החלטות (מידע הניתן לפעולה) מהנתונים.
הנתון משרטט את המרכיבים השונים של יישום IoT.
משמאל לימין ניתן לראות את החיישנים והמפעילים האחראים ללכידת הנתונים ולכל שינוי של הסביבה המבוקרת. פרוטוקולי השידור מאפשרים לאחד נתונים אלה במכשירים חכמים השונים באופן משמעותי ביכולת העיבוד הנדרשת בהתאם למאפייני המערכת שתיווצר.
נגיד מיד שאם לא תידרש תגובה מהמערכת הכוללת תוך זמן קצר מאוד (כמעט בזמן אמת), הנתונים יאוחדו על ידי Edge Gateway1 בעל קיבולת מוגבלת יותר ממחשב Edge המסוגל לספק עיבוד מקומי מתוחכם.
הנתונים המאוחדים, מנורמלים ומעוצבים כך מועברים לאחר מכן ליישום ענן שיחלץ את המידע המעניין. גם בשלב שידור נוסף זה, המאפיינים של פרוטוקול התקשורת המשמש להעברת הנתונים לאזור היישומים בענן הם בסיסיים. לעומת המקרה של שידור מחיישן / מפעיל למכשיר Edge, עם זאת, במקרה זה יש הבדל משמעותי וחשוב: כל הפרוטוקולים שבהם נעשה שימוש (MQTT, AMPQ, OPC UA, ...) מבוססים על יחידה אחת מכנה משותף המיוצג על ידי פרוטוקול ה- IP שעליו נתמכים הפרוטוקולים שזוהו בעבר ברמה גבוהה יותר.
בשדה היישומים, השרתים או שירותי הענן המתאימים יספקו את הפונקציות הפרימיטיביות הדרושות לאחסון, עיבוד והצגת המידע המופק מהנתונים שנלכדו.
כמו כן, יש לקחת בחשבון כי ספקי שירותי הענן העיקריים מציעים כיום פלטפורמות מיוחדות לשדה IoT המציעות שורה של תכונות פרימיטיביות שמטרתן לפשט את תהליך ההטמעה ולתת מענה לצרכי ההתקנה, התצורה והניהול של מכשירי Edge ו- Gateway. אותו מחשב.
יש להבהיר הכרחי בנוגע לפונקציונליות Edge Computing הדרושות, כפי שצייננו, למימוש יישומים המאופיינים בדרישות זמן מחמירות ביותר. זהו מקרה של פתרונות בקרה למערכות קריטיות שהעיכוב (ואולי גם אי זמינותן של יישומי ענן) אינו נסבל ולכן יש צורך לתת מענה (פעולה) תוך זמן קצר מאוד. לכן העיבוד המקומי מחליף את עיבוד הענן המסוגל לנצל אלגוריתמים ונתונים היסטוריים.
אם כן, לסיכום, השרשרת הטכנולוגית של יישום IoT מורכבת ממספר רב של רכיבים, אולם ניתן לצרף אותם לשלוש קטגוריות עיקריות:
- החיישנים / מפעילים האחראים לאינטראקציה עם הסביבה שתיווצר או נשלטו
- התקני Edge המרכזים, מנרמלים ומעבירים נתונים למערכות עיבוד יישומים
- יישומים שחולצים מידע שמיש מהנתונים והופכים אותם לזמינים על ידי הצגתם כראוי.
למרות הפשטות לכאורה של הפתרונות, ההיבטים הקריטיים שיש לנתח בפירוט הם רבים: בפרט, ההיבטים הביטחוניים ראויים לתשומת לב מיוחדת.
אבטחה ביצירות IoT
כמו כל מערכת. אבטחת התקשוב ממלאת תפקיד בסיסי גם ביצירות IoT. לכן מדובר בזיהוי סוגיות קריטיות ורכיבים ספציפיים שיש לקחת בחשבון בתכנון אסטרטגיית אבטחה בתחום ה- IoT.
בעקבות השרשרת הטכנולוגית שזוהו בעבר, ניתן לשער כמה שיקולים החל מחיישנים ומפעילים.
בדרך כלל מדובר ברכיבים פשוטים יחסית המאופיינים ביכולת עיבוד מוגבלת על מנת להפחית את צריכת כל סוללות אספקת החשמל. הכמויות שעליהן חייבים להתערב חיישנים / מפעילים מיוצגים על ידי ערך מספרי (טמפרטורה, לחץ, סיבוב של מנוע דריכה ...) או דיגיטלי (הפעלה / כיבוי, פתוח / סגור, ...) אשר מקבל משמעות מסוימת בהקשר הגלובלי של הפתרון הנחשב.
אנו יכולים לאשר שערכם של הנתונים SINGLE ולכן מוגבל ומעניין מעט: נקודת המבט שונה לחלוטין בכל הנוגע ל- SET של הנתונים שאפשר לתאם אותם. בכל מקרה החיישנים / מפעילים מצוידים ב- הקושחה פשוט יחסית ולעתים קרובות לא ניתן לשדרוג.
לכן יש לבצע הערכת בטיחות ראשונה ב הקושחה של המכשיר ולאחר מכן על פרוטוקול התקשורת המאפשר העברת נתונים למכשיר הקצה. שים לב שבמקרה זה עסקינן בפרוטוקולים מיוחדים, באופן קנייני כלשהו, שבכל מקרה זמינותם של כלי פשרה או יירוט מוגבלת. אין זה אומר שצריך להעריך כל סיכון לפגיעה בפרוטוקולים / אמצעי שידור אלה.
התרחיש הקשור למכשירי Edge שונה: במקרה זה פשרות האבטחה האפשריות יכולות להיות רבות. ה הקושחה של המכשיר במקרה זה מבוסס לעתים קרובות או בכל מקרה כולל רכיבים קוד פתוח שעלולים להציג פגיעויות: לכן יש צורך להעריך הן את ההיבט ההתנהגותי של המכשיר והן את נוכחותם האפשרית של "דלתות אחוריות" רדומות שעשויות להימצא במודול תוכנה כלשהו.
השימוש בפרוטוקולי תקשורת מבוססי IP פותח אז את האפשרות לפגיעויות האופייניות לסביבות מבוססות IP. למרבה המזל, אלה מובנים ומתועדים היטב בתחום הטכנולוגי, ויש כלים מתוחכמים כדי למזער את הסיכון לפשרה ברמה זו.
פתרונות הענן העיקריים בשמלת IoT מציעים היום סדרה שלמה של כלים לטיפול בבעיות של חיבור מאובטח בין התקן edge לבין יישום הענן הקשור: כלים אלה מספקים, בין היתר, את ההצפנה של הנתונים המועברים, האימות ההדדי. בין יישומים והתקן edge, אימות תקינות הנתונים וחוסר ההעתקה של אותם. כדי להשלים את הפגיעויות האפשריות של פתרון IoT, יש להזכיר את אלה הנוגעים לסביבת הענן וליישומים והנתונים המותקנים שם, שעבורם קיים מידע מפורט בספרות.
לסיום, פתרונות IoT לנוכח פשטות מושגית בשל האופי הסכימטי של ארכיטקטורת הרשת, לעומת זאת, מציגים שורה של מורכבות הנובעת מהמספר הגבוה של המכשירים המעורבים, מהצורך שהתקבל בכלי ניהול יעילים. ובעיות אבטחה הניתנות למימוש, בדרכים שונות, בכמה נקודות מימוש הדורשות יישום, תיאום וניהול של מכשירי הגנה בעלי אופי שונה. זה כרוך בידע רב תחומי של טכנולוגיות ומוצרים שניתן לשאול בחלקם מניסיונות קודמים בתחום התקשוב כאשר הוא קשור לשליטה הדרושה של הסביבה הפיזית (של האובייקטים) שאתה רוצה לשלוט ו / או ליצור.
1 Edge Gateway: מונח זה מזהה מכשיר תקשורת המסוגל לחלץ את המידע המתקבל באמצעות פרוטוקול תקשורת ספציפי ולעצב אותו כראוי להעברה והעברה באמצעות פרוטוקול אחר. לדוגמה, Edge Gateway מסוגל לזהות את הסטטוס של איש קשר דיגיטלי (ON / OFF) ולעצב מידע זה כראוי כך שניתן יהיה להעביר אותו ליישום המתגורר בשרת באמצעות פרוטוקול TCP / IP.
