מולטיקלאוד: אילו סיכונים ואתגרים

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

• צורך בכוח אדם מנוסה בניהול סביבות מרובות עננים;

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

• פיקוח קשה על כל המשאבים;

• פיקוח וממשל סיכונים קשים על פני מגוון רחב של נכסים על פני מספר פלטפורמות ענן e על הנחת יסוד²;

• קושי בשילוב פלטפורמות מרובות, אפילו בעזרת ממשקי API³, שכן ספקי ענן משתמשים בטכנולוגיות שונות כדי להשיג יתרון תחרותי;

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

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

אבל נמשיך עם הסדר.

מה זה מולטיקלאוד

אם אנו מתייחסים ל-IBM, אנו מוצאים זאת עבור מולטי קולוד פירושו שימוש בשירותים ענן מיותר מספק שירות אחד ענן. זה יכול להיות שימוש תוכנה כשירות (SaaS) מספקים שונים או, כפי שקורה לעתים קרובות בחברות גדולות, זה יכול להפעיל יישומים על פלטפורמה כשירות (PaaS) או למעלה תשתית כשירות (IaaS) של ספקי שירות שונים ענן^5,6,7,8.

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

כיצד להימנע מ לנעול ב

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

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

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

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

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

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

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

כיצד לבחור ספקי שירות עבור multicloud

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

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

מכאן נובע שלפני בחירת ספק שירותי ענן יהיה צורך:

• בצע "בדיקת נאותות"¹¹ והשוואה מדוקדקת של הצעות - בדוק אם ההצעות עונות על הצרכים שלך; לבחון מודלים שונים של תמחור כדי לקבוע חיסכון בעלויות לטווח קצר, בינוני וארוך; להבין הסכמי רמת שירות (SLAs); לשקול את התהליכים והעלויות של העברת נתונים; זכור חברות דומות אחרות שהם עבדו איתן.

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

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

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

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

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

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

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

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

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

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

• אישורים ותקנים

• מפת דרכים טכנולוגיות ושירות

• אבטחת מידע, ממשל נתונים ומדיניות החברה

• תלות ושותפויות שירות

• חוזים, פרסום ו-SLA

• אמינות וביצועים

• תמיכה בהגירה, נעילת ספקים ותכנון שחרור

• חוסן פיננסי ופרופיל ספק

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

אסטרטגיית ניהול ריבוי עננים

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

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

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

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

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

אבטחה והצעה

כדי להבטיח אבטחה בענן יש צורך בידע מעמיק בארגון ובאמינות של ספק שירותי הענן על מנת לבצע בחירות אפקטיביות, יעילות ומובנות המבוססות על יעדי החברה, במיוחד במונחים של: הגנת מידע; בְּטִיחוּת; שיתוף של תקנות ותקנים שניתן ליישם, להשתמש ולהבין לכולם.

למעשה, בשלב הבחירה בספק הענן, יש צורך:

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

  • אימות שירותי קישוריות וכוח במרכזי נתונים במקרה של אסון / שיבוש.

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

  • בדוק כיצד הנתונים משוכפלים והיכן הם נשמרים למטרות ה-GDPR.

• בדוק את מפרטי מרכז הנתונים בשימוש על ידי ספק הענן.

• בדוק אם יש מקרים של השבתהà התרחש ב-18 החודשים האחרונים.

• בדוק את תדירות הבדיקות התאוששות, חירום וזמינות הדוח האחרון.

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

• ניהול זהות וגישה באמצעות אימוץ מערכת ניהול זהות וגישה (IAM).

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

• מידע על איומים, ניטור ומניעה באמצעות אימוץ של מודיעין איומים, מערכות זיהוי חדירה (IDS) ומערכות למניעת חדירות (IPS).

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

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

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

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

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

מרכיב חשוב נוסף הוא הבנת אחריות משותפת וציות.

ניידות של עומסי עבודה

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

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

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

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

חוסן בענן

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

חוויות בענן

ישנם ארגונים רבים, קבוצות, צוותי משימה ועמותות המציעים משאבים ותקנים בנושא אבטחת ענן, רק תחשבו על NIST, ISO, Cloud Security Alliance, ETSI, OGF, OASIS,

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

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

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

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

מסקנות

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

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

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

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

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

פדריקה מריה ריטה לולי, אלסנדרו רוגולו

_{תודה לכל חברי קבוצת SICYNT על הערותיהם/הצעותיהם}