אבטחת תשתיות טלפוניה בענן - האם יש דבר כזה?
מאת: ניר סמיונוביץ, 7.10.21, 11:22

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

1. תשתיות הענן הן בטוחות ומצוינות,
2. תשתיות הענן הן פרוצות ולא בטוחות כלל.

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

אף על פי כן, כיוון שכמות הפניות שקיבלתי בשבועיים האחרונים הוכיחה לי עד כמה עולמנו הפכפך וחסר יציבות, לא יכולתי שלא לתהות על קנקנה של השאלה: ״האם אפשר לאבטח תשתיות טלפוניה בענן?״ אולם, זו הביאה אותי לשאלה הרבה יותר מעניינת: ״על מי אני סומך בדיוק?״
 
תשתיות מחשוב - לא רק Someone Elses Computer
לחלק ניכר מהארגונים בארץ, בייחוד אלה העוסקים ב״טלפוניה בענן״, יש ״פערים״ רבים בהבנה של תשתיות ענן. מרביתם מתייחסים לנושא הענן בתור אוסף של שרתים וירטואליים, בלי באמת להבין מה זה אומר. יתר על כן, חלק אפילו מאמינים, שבהנחה והמוצר מדף, שאותו התקינו, כולל את המילה Cloud, אזי הם ״ספקי ענן״.

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

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

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

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

שיטה שלישית (נדיר לראות בארץ) - Full Serverless Implementation
בשיטה זו אין לנו שרתים וירטואליים או שרתי Container, פשוט כי אין לנו צורך בהם. בשיטה זו המרכיבים השונים ירכבו על תשתיות ענן שונות, כאשר החיבור בין המרכיבים יהיה דרך ממשקי API מוגדרים מראש. לדוגמא:

ממשק ה-Frontend יעבוד על בסיס אחסון הדפים ב-Amazon S3 והצגתם ישירות משם.
הדפים יקראו לממשק API, שיסופק ע"י שירות Amazon API Gateway ו-Amazon Lambda.
מסד הנתונים יאוחסן בשרותי Amazon RDS או על בסיס של שרתי RDBMS ייעודיים.
הקישור בין ממשק ה-API לבין מסד הנתונים יתבצע ע"י שימוש בשירותי Messaging של AWS, כגון: SQS ו-ElastiCache, ולא בהכרח ע"י קישור DSN ישיר.

אם 3 השיטות שקולות, מה גורם לשיטה השלישית להיות מאובטחת יותר? - אין תשובה אחת אלא כמה.

כדי לענות עליה, עלינו לענות על שאלה בסיסית אחת, לפני כל השאלות האחרות: ״האם אנו סומכים על Amazon AWS, שיעשו את העבודה נכון?״ - בסופו של יום, אנו צריכים לסמוך על מישהו.

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

בשיטה השלישית, ספק הטלפוניה יוצא במספר הצהרות מאוד חזקות:

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

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

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

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

מרבית הארגונים מאמינים, שכאשר ספק הטלפוניה בענן נותן להם גישה לאתר מאובטח, מוצפן, עם סיסמא ווידוא משתמש ע"י 2FA (ע״ע זיהוי ע"י SMS וכו׳) - זה מספיק. ובכן - זה לא מספיק, אפילו לא מתקרב למספיק.

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

אז איך מגינים על המידע הזה? מוסיפים עוד כמה שכבות של הגנה, לדוגמא:

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

גישה לקבצים ע"י API מוגן ב-Ephemeral Tokens. בשיטה זו, הגישה לקבצים לא יכולה להתבצע ישירות, אלא רק ע"י זיהוי בעזרת Token ידוע מראש. ה-Token מאפשר להוריד את הקובץ, אך לא לשמוע אותו ישירות - בשביל זה צריך את המפתח הקודם. כל Token מיוצר עם זמן תפוגה ידוע מראש, שלאחריו יש לייצר Token חדש.

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

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

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

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

בארה״ב ,חברת Wallmart החלה בבניה של שירות מתחרה ל-Amazon AWS כיוון שהיא לא מוכנה לרכוש תשתיות ענן מ-Amazon, והתשתיות של Google מתאימות לצרכים שלה בצורה חלקית. אבל עם כל הכבוד, אני לא חושב, שיש ספק ענן ישראלי בארץ, שבכלל מתקרב לכיסים של Wallmart - פשוט אין.

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

גישת Security and Privacy by Design
אחת הטעויות הקלאסיות של חברות סטארטאפ, ואני מכליל לקטגוריה כל חברת טלפוניה בענן, כיוון שכולן עדיין נמצאות בתהליך מתמיד של פיתוח וצמיחה, היא גישה של: מוצר קודם לאבטחה.

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

לדוגמא, כאשר בנינו את Cloudonix, אחד הלקוחות העמיד לנו אתגר מאוד רציני:

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

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

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

כ"כ, הדרישה החמישית דורשת מצב של Double Tier Multi Tenant, כלומר, לתת ללקוח אפשרות לנהוג במערכת כאילו היה Reseller ו-Tenant בעת ובעונה אחת.
הבנו כבר בהתחלה, שכדי לתת ללקוח מענה אנו צריכים להסתכל על הנושאים של פרטיות ואבטחה בראיה אחרת, כזו הלוקחת בחשבון קודם כל את נושא הפרטיות, ולאחר מכן את נושא האבטחה.

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

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

סיכום
בשנת 2004 ישבתי בפגישה עם צמרת ההנהלה של חברת תדיראן טלקום. הצגתי לפניה את העולם של טלפוניה בקוד פתוח, ומי, שאז היה המנכ״ל, לאחר זרק לכיווני (בעודי ילד בן 30): ״ילד, תקשיב, אין מצב שמערכת תוכנה תהיה אמינה כמו מערכת אלקטרונית. כל הנושא של VoIP הוא לא אמין, ואין שום סיכוי, שארגון בר-דעת ישים את כספו על הדבר הזה". מאז ועד היום, עברו הרבה מאוד ביטים של VoIP באינטרנט ואפילו תדיראן טלקום כבר לא מוכרת מרכזיות, שאינן VoIP.

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

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

על מנת שאירועים מסוג זה לא יישנו בהמשך, צריכים לקרות 2 דברים:

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

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

מאת: ניר סמיונוביץ, אוקטובר 2021.
מנכ"ל cloudonix.io