עד 2025, סך הכל יצירת נתונים גלובליים יגיע ל-181 זטה-בייט. עבור ארגונים, הנתונים הללו הם נכס, המאפשר להם למנף מגוון פלטפורמות טכנולוגיות ליצירת חוויות לקוח מותאמות אישית ביותר, המעוררות נאמנות ומושכות עסקים חדשים. עם זאת, חוויות אלו תלויות בתשתיות ענן המשתמשות במצבי אבטחה משותפים. שם טמון הסיכון, והוא הולך וגובר ככל שהטכנולוגיה צומחת ומשלבת צבא חדש של מפתחים אזרחיים המשתמשים בפלטפורמות עם קוד נמוך וללא קוד.
הבנה והתגברות על הלך הרוח של הירושה
גרטנר מעריכה שעד 2025, 70% מהיישומים הארגוניים ייבנו מפלטפורמות עם קוד נמוך וללא קוד כמו Salesforce ו-ServiceNow. תגובה עם חשיבה מבוססת ירושה היא דרך בטוחה להגדיר יותר משני שליש מהאפליקציות הארגוניות לכישלון.
"הלך הרוח של ירושה" הוא מתאר מתאים לבעיות הפוקדות את התשתית. זה מזכיר ילדים עשירים ומפונקים, התלויים לחלוטין בעבודה שנעשתה ובאנשים שבאו לפניהם. זו לא דרך טובה לבנות מורשת, וזו דרך גרועה באותה מידה לבנות מערכת.
כאשר יש לך חשיבה מדור קודם, אתה מניח שהתשתית מוגדרת. הפלטפורמה בטוחה והאבטחה מובנית. מניחים אמון פשוט בגלל שהטכנולוגיה הייתה שם לפני המנהל.
הלך הרוח של הירושה פוגע בפלטפורמות עם קוד נמוך וללא קוד. משתמשים מסתמכים על הבטיחות של פלטפורמה כדי להעביר אותם דרך תשתית ארגונית שלמה. במקום זאת, האבטחה של אותה פלטפורמה צריכה לחול רק על אותה פלטפורמה.
נניח שמפתחי Salesforce יוצרים תוכנית הקצאה אוטומטית עבור לידים חדשים. הם משתמשים בזה בתוך Salesforce עבור משימות פנימיות, וזה בסדר. הם יכולים לסמוך על בטיחות הפלטפורמה. הם מחליטים להרחיב אותו כדי לשפר את האוטומציה. הם מחברים את התוכנית הזו ל-CRM הפונה חיצונית כמו ServiceNow, SAP או Oracle. הלך הרוח של הירושה משתלט: Salesforce בטוח. ServiceNow, SAP או הצד השלישי בטוחים.
אז, Salesforce + צד שלישי = בטוח.
אבל, יש הרבה לא ידוע בסימן הפלוס הזה. איך מחברים בבטחה ובהתאמה את התוכנית הפנימית שנוצרה ב-Salesforce לתוכנית החיצונית שנוצרה בפלטפורמת הצד השלישי? יש הרבה מקום לטעות בדמות הבודדת הזו.
וזה רק קשר אחד. תוכניות רבות שנוצרו ב-Salesforce נוגעות במאות אחרות. זה מאות אלמונים שמתייחסים אליהם כמו סימן הפלוס שתואר לעיל על ידי אנשים שיש להם ניסיון בפיתוח מועט עד לא.
הפתרון היחיד הוא לקחת את הפיתוח הזה בחזרה לכדור הארץ עם חזרה לעקרונות DevSecOps.
הקמת מסגרת DevSecOps
DevSecOps מסגרות נכתבו, שוכתבו ונכתבו שוב מאז שהקונספט נוצר. אין צורך להמציא את הגלגל מחדש בעת הקמתם, במיוחד כאשר SAFECode ו-Cloud Security Alliance בנה שישה עמודים:
- אחריות קולקטיבית: האבטחה היא באחריות של כל אדם בארגון - אבל אנשים לא יכולים לעמוד בסטנדרטים שהם לא מכירים. יש להקצות לידים כדי להניע את מדיניות אבטחת הסייבר ולהבטיח שהיא מופצת ברחבי הארגון.
- שיתוף פעולה ושילוב: יש לחלוק ולהעביר ידע. חצי מהסיבה שארגונים נופלים לתוך הלך הרוח המורשת היא שכל מי שהכיר את המערכת הישנה איננו. שיתוף ידע מתמשך עוזר לבטל בעיה זו.
- יישום פרגמטי: הטמעה פרגמטית קשורה לחוויית המפתח. לא עוקבים אחרי תהליכים קשים, ארציים ומסורבלים לאורך זמן. יש להכניס אבטחה לפרקטיקות פיתוח - כלומר, כל שורת קוד דורשת שורת בדיקה. ארגון בעל ביצועים גבוהים ייקח את זה רחוק יותר על ידי שימוש בכלי לאוטומטי של כל שורת קוד בדיקה.
- תאימות ופיתוח: דרישות התאימות צריכות להנחות את תהליך הפיתוח באופן שלא יאפשר למפתחים לסטות מהן. מפתח עבור מוסד פיננסי, למשל, יעבוד על פלטפורמה שנועדה להיות תואמת לחוק Gramm-Leach-Bliley. המפתח לא צריך לדעת את הפרטים והפרטים של המעשה כדי לעמוד בדרישות מכיוון שהם מובנים בפלטפורמה.
- אוטומציה: משימות הניתנות לחיזוי, שניתן לחזור עליהן ובנפח גבוה צריכות להיות אוטומטיות בכל הזדמנות אפשרית כדי להסיר את הנטל מהמפתחים ולהפחית את הסיכון לטעות אנוש.
- צג: תשתיות ענן מודרניות משתנות וצומחות. חיוני לעקוב אחריו - באופן אידיאלי, באמצעות צורה כלשהי של תזמור המאפשרת מבט חטוף על כל החיבורים השונים.
ב נמוך או ללא קוד סביבה, עמודי התווך הללו אינם פשוטים כפי שניתן היה לצפות. האנשים המשתמשים בכלים אלה הם לרוב מומחים עסקיים עם מעט היכרות עם יסודות DevSecOps.
איחוד אנשים, תהליכים וטכנולוגיה
השימוש בפלטפורמות עם קוד נמוך וללא קוד יכול למעשה לעזור לסגור את פער הכישורים הזה. עובדים רוצים ללמוד מיומנויות חדשות. ארגונים יכולים לתמוך בכך על ידי הקמת מסגרת DevSecOps המתמקדת באנשים, תהליכים וטכנולוגיה.
- תהליכים: בסביבת אמון אפס, מפתחי קוד נמוך וללא קוד אינם צריכים לדאוג ליצירת קשרים המסכנים את שלמות המערכת מכיוון שהם אינם מסוגלים לעשות זאת. אין להם סמכות בסיסית מחוץ למערכת המבודדת שלהם.
- אנשים: תרבות של אחריות שונה מתרבות של האשמה. אחריות פירושה שאנשים מרגישים בנוח להופיע עם בעיה או טעות מכיוון שהפוקוס הוא על הנושא, לא על האדם.
- טכנולוגיה: הטכנולוגיה היא החסם הגדול ביותר בפני יישום נכון של עקרונות DevSecOps מכיוון שהיא אינה בידי המפתחים. הם חייבים להשתמש במה שהארגון נותן להם. אם הטכנולוגיה הזו לא תעבוד, מפתחים יציגו דרכים לעקיפת הבעיה שאינן מאובטחות ואינן בטוחות. בעיקרו של דבר, הטכנולוגיה הופכת למחולל IT צל גדול אחד.
אנו חיים בתקופה מרגשת להתפתחות. ליותר ויותר אנשים יש הזדמנות לבנות תוכנה, לבדוק אסטרטגיות ולשפר את הערך העסקי. אבל עם זה בא סיכון. ארגונים אשר בוחנים דרכים להוריד את הסיכון הזה לטכנולוגיה ישמרו על הפיתוח שלהם עד כדור הארץ תוך השארת מקום לחקור.
