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

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

במרבית המקרים המיתוסים מבוססים על פחד, חוסר וודאות או ספקות (FUD – Fear, uncertainty and doubt).

במאמר זה נציג מספר מיתוסים נפוצים ונבחן אותם למול המציאות בשטח.

האמת נמצאת איפשהו באמצע.

כאשר משווים שירותים מנוהלים (SaaS) דוגמת SalesForce, Office 365, Oracle CRM, SAP SuccessFactors ועוד, למול פתרונות מקבילים בסביבת ה-On Premise, ניתן לומר כי אין מקום להשוואה. מצד אחד, הלקוח מעביר את נטל האבטחה והתחזוקה השוטפת לספק הענן ומהצד השני, ספקי ענן בוגרים אלו, משקיעים סכומי כסף עצומים (ביחס למרבית הארגונים בתעשייה) באבטחת השירותים, ביצוע מבדקי חדירה, ניטור גישה והכשרת צוותי התמיכה והאבטחה.

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

מצד אחד, מודל ה-IaaS מזכיר ניהול סביבת וירטואליזציה מה-Data Center המקומי, אך מצד שני, ספקי ה-IaaS המובילים מספקים ללקוח עשרות שירותים מנוהלים על-מנת להקל על תחזוקת השרתים (מבסיסי נתונים מנוהלים, דרך שירותי גיבוי, שירותי Patch management ו-Vulnerability management ועוד).

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

האמת נמצאת איפשהו באמצע.

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

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

כאשר משווים סביבות IaaS המצב משתנה. עלות שרתים בענן במודל Pay as you go גבוהה במרבית המקרים (כאשר משווים אותה כמות vCPU ו-Memory) למול סביבת ה-On premise. על-מנת לצמצם עלויות במודל IaaS, צריך להבין האם אנחנו מתמודדים עם workload בעל ביצועים וזמני ריצה משתנים, או שאנו מתמודדים עם שרתים אשר ירוצו בסביבת הענן 24×7 למשך תקופה ארוכה ובמידה וכן, ההמלצה היא לרכוש התחייבות (Reserved Instances) לתקופה של שנה או שלוש שנים מראש.

אפשרות נוספת לחסוך בעלויות שרתים בסביבת IaaS, במידה והשירות עצמו אינו רגיש לנפילות ומסוגל להתאושש בעצמו (דוגמת שירותי Batch processing, image processing וכו'), היא לבחור במודל Spot וכך לחסוך עד 90% ממחיר המחירון.

האפשרות הכי טובה לחסוך בעלויות שרתים ידרוש מאתנו להשקיע בארכיטקטורה מחדש של המערכות (ככל הניתן) ולעבור לבניית אפליקציות במודל micro-services או להשתמש בשירותי Serverless וכך לצמצם את צריכת המשאבים והעלות החודשית למינימום ההכרחי.

הגירת שירותים קיימים מסביבת ה-on premise לשירותים מנוהלים בתצורת SaaS משתנה משירות אחד למשנהו ולכן קשה לצאת בהכללות.

שירותי SaaS רבים מפרסמים מאמרים או כלים אשר יסייעו לארגונים לבצע הגירה לעולמות ה-SaaS.

דוגמאות: SalesForce, Oracle CRM, SAP, Office 365, Google G Suite ועוד.

גם במעבר לשירותי PaaS, קיימים מדריכים ושירותים מנוהל על מנת לסייע לבצע הגירה מסביבת ה-on premise לענן.

דוגמאות: AWS Database Migration Service, Azure Database Migration Service, Google BigQuery Data Transfer Service ועוד.

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

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

היה ומעוניינים לבצע הגירה פשוטה (fast and dirty), תמיד ניתן לבחור (לפחות בשלבי ההתנסות הראשוניים) בהגירת מערכות בשיטת lift & shift – זה אומנם לא פתרון כלכלי (לעיתים חומרה דומה בסביבת IaaS תעלה יותר מהמקבילה בסביבת ה-on premise), אך פתרון זה יאפשר בשלב הראשון לאפשר לארגון לגשת למערכות אשר עברו הגירה לסביבת הענן ובהמשך להתאים את משאבי החומרה הנדרשים לשימוש בפועל, לשנות את ארכיטקטורת המערכת (דוגמת החלפת שרתים בשירותים מנוהלים) ועוד.

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

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

החשש מ-Vendor Lock In או מתרחיש בו ספק ה-IaaS יפשוט את הרגל לא בלתי סביר, אך הבקרה לכך היא בחירה באחד מספקי הענן אשר מוגדרים כ-Hyperscale Cloud Providers וכך לצמצם את הסיכון לתרחיש בו ספק הענן יפשוט את הרגל.

תיאורטית, בחירה במספר ספקי IaaS עשויה לאפשר מעבר של סביבות בין ספקי ענן שונים, אך בפועל, מעבר לתצורת multi-cloud מייצר הרבה מאוד אתגרים לארגון דוגמת הצורך לאכוף הזדהות מרכזית, הצורך להכיר כיצד כל ספק ענן מיישם את שירותים (דוגמת compute, network, storage), כיצד לבצע פריסת סביבות על פני ספקי ענן שונים, כיצד לאכוף ניטור וטיפול באירועי אבטחת מידע בצורה מרכזית ועוד.

במידה ורוצים לצמצם את הסיכון ל-Vendor Lock In ולאפשר לארגון להעביר סביבות בין מספר ספקי ענן, נדרש לתכנן את ארכיטקטורת התשתיות מהשלב הראשון להתבסס על Containers או Kubernetes. כל עוד נארוז את השירותים שלנו בתוך Containers, נוכל להריץ אותם על גבי תשתיות של ספקי ענן שונים. כדאי כמובן לקחת בחשבון חיבור ל-eco system של ספקי הענן (דוגמת storage, ניטור, שירותי messaging וכו').

בשורה התחתונה – פריסת סביבות Production על פני מספר ספקי ענן (תצורת multi-cloud) כרוכה בהיכרות מעמיקה עם עולם הענן ובמקום להוות פתרון ל-Vendor Lock In, היא עשויה לייצר תקורות רבות על הארגון, אשר לא מצדיקות את הסיכון של Vendor Lock In. מעבר לשימוש ב-Containers יכול להקל על היכולת שלנו כארגון לעבוד על מספר ספקי ענן במקביל.

מדוייק חלקית.

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

• ניטור גישה בשירותי SaaS: Office 365, SalesForce, Oracle HCM, ועוד
• ניטור גישת אנשי תשתיות בשירותי SaaS: Office 365 Customer LockBox, Oracle Break Glass ועוד
• ניטור גישה בשירותי IaaS/PaaS: Amazon CloudTrail, Google Cloud Audit Logs ועוד
• גישה לדוחות ביקורת מסוג ISO27001 או SOC 2 Type 2 (לרוב בהינתן חתימה על NDA מול הספק): AWS Compliance Programs, Microsoft Trust Center, GCP Compliance resource center ועוד
• ביצוע מבדקי חוסן (לרוב בסביבות IaaS): Azure, AWS, GCP ועוד

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

זהו מיתוס נפוץ, אך מאוד לא מדוייק.

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

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

מעבר ארגונים מסביבות ה-on premise לסביבות הענן יחייב ארגונים להתייעל. אומנם המעבר לשירותים מנוהלים (SaaS) ידרוש פחות אנשי תשתיות, אך המעבר לסביבות IaaS / PaaS, יחייב שינוי מחשבה בקרב אנשי התשתיות הקיימים ע"י התאמה הידע מעבודה ידנית (תחזוקת שרתים, בסיסי נתונים, הקמת סביבות, שרידות וכו') לאוטומציה, כתיבת קוד (לא חייבים להפוך למפתחים מקצועיים), מעבר להקמת סביבות מבוססות Infrastructure as a Code ועוד.

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