חיברתי עבורכם כמה הנחיות שיעזרו לכם איך כן לעלות לענן. מיועד לתעשיית ה OT בישראל

הענן איתנו והוא פה בשל לפעילות ובמאמר זה אני לא מתכוון להמליץ לכם אם כן או לא לעלות לענן.

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

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

ולא פחות חשוב, איך אנו ניגשים לבקרת הפיקוח? איך אנו מאבטחים את הנתונים הרגישים המתארחים בענן?

 

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

מסמך זה אינו מכוון להכתיב שפתרון ענני הוא הגישה הנכונה עבור תעשיית ה OT.

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

 

אבטחת הענן היא נושא שמחייב שיתוף פעולה של ה IT ושל ה OT.

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

מה נותן לנו המעבר לענן ?

שיפור יעילות תפעולית, חיסכון בעלויות, גמישות, זמינות.

מה צריך לבצע כדי להיות מוכנים לעלייה לענן ?

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

 

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

2.      תקשורת יעילה – שקיפות התהליך מול הצוותים (כולל פגישות פרונטליות).

3.      הכשרה מקיפה – הכשרה מקיפה לכל העובדים בהתאם לצרכים ולרמות המיומנות של העובדים. 

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

5.      ניטור והערכה – ניטור התקדמות, מעקב בניהול הפרויקט, ניהול סיכונים שוטף, מומלץ לשלב שירותי SOC.

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

 

עקרונות אבטחת ענן

1. הנתונים צריכים להיות מוצפנים ומאומתים.

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

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

4. צריכה להיות מסגרת מדיניות אבטחת ענן וניהול סיכונים.

5. צריכים להיות נהלים ותהליכים ברורים לאבטחת המערכות ותשתיות הענן.

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

7. תהליך הפיתוח של שירותי הענן צריך להיות מאובטח וכולל בקרות מתאימות.

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

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

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

11. ממשקי שירותי הענן צריכים להיות מוגנים מפני התקפות.

12. שירותי הענן צריכים להיות מנוהלים בצורה מאובטחת.

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

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

15. יש לוודא זמינות של שירות הגיבוי התקשורתי מהלקוח ומוצריו לענן.


המעבר לענן בין אם מדובר לענן כ DR, לענן כ Main Site, לניהול בענן HMI ואפילו הבקר כתקשורת ישירה לענן יכול ואפילו עדיף שיתבצע בשלבים.

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

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

——

נכתב על ידי: רז זדה, תום מלכה ואושר עשור.