פיתוח מערכות – "הגבינה זזה"

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

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

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

הערך החשוב מכל בעולם פיתוח המערכות המודרני, לצד התאמה מרבית לצרכי הארגון, הינו ה-Time to Market של יישומים חדשים שיאפשרו לארגון ערך ויכולות חדשות ומהר.

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

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

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

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

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

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

לערב את אנשי האבטחה והסייבר בזמן הנכון

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

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

זה יכול להיות מפתה לראות את DevSecOps כמו רק עוד מילת מפתח (Buzzword), אבל עבור מנהלי IT המודעים לנושא האבטחה, זהו מונח מהותי: אבטחה חייבת להיות בעדיפות גבוהה בתהליך פיתוח תוכנה, ולא רק לאחר שמתרחש אירוע אמיתי.

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

לפי גרטנר (Gartner) "המטרה של DevSecOps היא לשפר את אבטחת המידע הכוללת באמצעות תכנון מערך של בקרות משולבות בכדי לספק DevSecOps מבלי לערער את הזריזות והגמישות (אג'יליות) והיבטי שיתוף הפעולה של פילוסופיית ה-DevOps יצירת שכבה של כלים ותהליכים סטנדרטיים לאבטחת מידע על גבי ה-DevOps לא תעבוד.

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