מה זה בכלל DevOps?
אם גם אתם שומעים לאחרונה מסביב יותר ויותר את המונח DevOps, אתם לא לבד.
עד לפני מספר שנים עולם התוכנה עבד בשיטה שנקראה מפל (באנגלית Waterfall) שיטה היררכית לייצור מוצר טכנולוגי,
בשיטה זו הלקוח נפגש עם ארכיטקט התוכנה שבתורו העביר את הדרישות למהנדסי התוכנה שלבסוף העבירו מוצר למחלקת האופרציות (System) שנועדה לתמוך במוצר.w
העולם התקדם והביקוש לתוכנה עלה מהר, פרויקטי תוכנה הפכו מסובכים יותר ומסורבלים לתכנון של כל המערכת מהיום הראשון. כיום מהפגישה הראשונה מעורבים בתהליך הפיתוח כל הגורמים הרלוונטים, מארכיטקטי ועד מחלקת אופרציות מהרגע הראשון. השינוי נועד כדי לפרק את תהליך הפיתוח התוכנה לחלקים קטנים, כאשר כל חלק מאופיין היטב ובונים את המוצר הגדול צעד אחד כל פעם, המעבר הזה נקרא גם מעבר לDevOps או לפיתוח אג'ילי.
מן הסתם שהמעבר לDevOps דורש שינוי בתפיסת העולם ובתרבות הארגונית.
במילים פשוטות, משמעות המונח DevOps היא חיבור התקשורת בין צוותים שהיו עד כה נפרדים: מחלקת פיתוח – Dev, ומחלקת אופרציות – OPS (מהנדסי System, תומכי Production).
למעשה, בחלק מהארגונים אין הפרדה כלל בין צוותי הפיתוח, האופרציה ואבטחת המידע- כולם עושים הכל ועובדים יחד כדי לייעל ולשפר את ביצועי הפיתוח ויציבות המוצר בשוק.
נשמע אוטופי, לא?
תוכן עניינים
איך כל זה בא לידי ביטוי?
כולכם ודאי שמעתם על המושא Agile (“פיתוח תוכנה זריז”) שגורס כי פיתוח תוכנה היא בעיה אמפירית ואי אפשר לפתור אותה על ידי תכנון בלבד,
הרעיון בפיתוח זריז היא היכולת להתמודד עם שינויים ודרישות חדשות תוך כדי תנועה ובמקביל להוציא עדכונים בקצב זריז למוצר.
כחלק מתהליך פיתוח התוכנה בשיטת הDevOps נוצר Pipeline שלוקח את הקוד, מקמפל (עושה build, compile) בודק עם כלי בדיקה שונים ורק אז משחרר אותו לשוק. התהליך הזה פועל המון ונותן מענה לצורך שעושה חיים קלים למפתחים ולא בהכרח אחרי כל עדכון גדול למערכת כפי שהיה בגישה הישנה.
כדי להתמודד עם השינויים התכופים יש לבדוק את עמידות המערכת ולדעת מה מצבה בכל רגע נתון ולכן כחלק מתפיסת העולם יש להוסיף כלי ניטור שונים מעל המערכת כדי תמיד להיות בבקרה עליה ולדעת איזה שינויים יש לבצע בה.
דוגמה לזה ניתן לראות בתמונה הבאה:
תפיסת העולם של ה-DevOps מבקשת ליצור יישור קו ושיתוף פעולה בין צוותי הפיתוח והאופרציות שמאפשר יציאה מוקדמת יותר לשוק ופיתוח זריז.
הרי אם כתבנו מוצר נהדר אבל אין לנו את היכולת להנגיש אותו ללקוחות כי השרתים שלנו לא תומכים בו או לא יציבים מספיק, לא השגנו בזה הרבה.
פיתוח מוצרים הפך מתהליך מסובך לעבודה בחלקים קטנים שמאפשרת הוספה מתמדת של תכונות (פיצ’רים) למוצר מידי שבוע.
לא כולם מצטרפים לחגיגה
יש כאלו שנשארו מאחור: צוותי אבטחת המידע נותרו מאחור ולא נכנסו לשיח של עולמות ה-DevOps.
למה? בעיקר כי ארגונים רבים רואים את נושא אבטחת המידע כמכשול מסורבל, שמפריע לתהליכי הפיתוח ומאט את ההוספה של תכונות חדשות למוצר.
כתוצאה מכך, תהליכי אבטחת המידע הסופר חשובים נשכחו בדרך.
אז איך קורה שעל אף המודעות הגוברת לאבטחת מידע, ארגונים רבים מזניחים את הצד הקריטי הזה? הרי אף אחד לא רוצה פרצת אבטחת מידע בחצר האחורית שלו.
כדי לעמוד בשאיפות אלו יש לאחד את צוותי אבטחת המידע- SecOps – ואת צוותי ה-DevOps, כדי לתמוך בצורה מלאה בכל תהליכי הפיתוח בארגון. את התוספת הזו ניתן לראות בתמונה הבאה:
DevSecOps, מושג חדש הגיע לעולם
צוותי אבטחת המידע בדרך כלל קטנים יותר ממחלקת הפיתוח, והם אחראים לשמירה על אבטחת הארגון, מה שלא פעם נדמה כנטל לעומת השעטה קדימה של הצוותים האחרים.
צוותי אבטחת המידע בדרך כלל קטנים יותר ממחלקת הפיתוח, והם אחראים לשמירה על אבטחת הארגון, מה שלא פעם נדמה כנטל לעומת השעטה קדימה של הצוותים האחרים.
המטרה של ה-DevSecOps היא להפוך את מחלקת אבטחת המידע ממחלקת ה”לא, זה לא אפשרי” למחלקה שמציעה פתרונות אלטרנטיביים.
המטרה והייעוד של DevSecOps הוא להכניס לתרבות הארגונית את הרעיון ש"כולם אחראיים לאבטחה עם מטרה אחת",
לאפשר לכל הנוגעים בדבר, בכל זמן ובכל גודל לקבל החלטות בנושא אבטחת מידע תוך שמירה על ייצור מהיר בלי לפגוע בדרישות האבטחת הרצויות"
אם נסתכל על מודל האחריות המשותפת של AWS נראה שגם ללקוחותיה של AWS יש הרבה תחומי אחראיות שלמים באבטחת המוצרים שלהם בענן, אנחנו לא יכולים לצפות מאף אחד אחר לעשות את העבודה הזו עבורינו.
בארגון הדוגל בשיטת DevSecOps, מכניסים את ערכי אבטחת המידע מוקדם ככל הניתן בתהליך הפיתוח. כאשר אבטחת מידע היא אחריות של כולם ולא של מחלקה אחת, צוותי ה-DevOps נמצאים ברגע החלטה קריטי בין תהליך הפיתוח לאופרציה, ולכן יש להם את היכולת להחיל את עקרונות אבטחת המידע לכל אורך הדרך.
בימים אלה, שיטות הפעולה של מחלקות האבטחת מידע של פעם כבר לא יעילות באותה מידה. סריקות לחולשות ודו”וחות סיכונים לא רואים את כל התמונה, מה גם שהם מתבצעות על סביבה מייצרת (Production) בפועל ולא על מה שבדרך לשם. בDevSecOps התייחסו לנושא, למשל כחלק מהבדיקות שנעשות בPipeline כ-DevSecOps אוסיף גם בדיקות חדירות כדי לוודא שגם השינויים החדשים בקוד לא חשופים לחולשות ידועות.
בעולם רווי הסכנות של ימינו, ארגונים לא יכולים לשבת ולחכות למתקפה הבאה כנגדם. עולם אבטחת המידע משתנה ולכן צוותי ה-DevSecOps עושים כמיטב יכולתם על מנת לעמוד בדרישות המשתנות בקצב מהיר.
העקרונות החשובים של DevSecOps
הכל עניין של גישה, עקרונות הDevSecOps צריכים תמיד לשאוף להיות מוטמעים בצורה הטבעית ביותר במהלך תהליך הפיתוח של החברה החל מהיום הראשון.
החל מהיום הראשון
בתהליך פיתוח מאובטח מעבירים את האבטחה להתחלה מהסוף, בשיטת ה”קלאסית” מסיימים לפתח ואז מגישים את המוצר למחלקת אבטחת המידע שתעשה את הבדיקות שלה (בדיקות חדירות, סריקת חולשות וכו).
כחלק מעקרונות הDevSecOps מכניסים את מהנדסי אבטחת המידע ואת הארכיטקטים מהיום הראשון של הפיתוח ועובדים יחדיו כדי לבנות את המוצר מאובטח על הצד הטוב ביותר. מטרתם היא לאשר כל רכיב בתוכנה ולוודא כי כל תוכנה חיצונית עומדת בתקנות, שרתי הפיתוח מפוצ’פצ’ים (Patched) וכל רכיב בStack הפיתוח מוגדר בצורה שלא חושפת מידע.
המעבר הזה להתחלה מאפשר זיהוי מוקדם של חולשות ופרצות, כל מנהל יודע שחדשות רעות שמגיעות מוקדם הן בעצם חדשות טובות ולכן ניתן לסגור את הפרצות ולטפל בחולשות מוקדם יותר לפני שהמוצר יוצא לשוק.
בדיקות אוטומטיות
כחלק מתהליך הפיתוח, הPipeline של החברה מבצע בדיקות לעדכונים האחרונים של הקוד לפני שהוא עולה לייצור, אז למה שלא להוסיף בדיקות של אבטחת מידע כבר אז? ישנן סריקות לקוד עצמו (Static Code Analysis) ובדיקות חדירות (Penetration Testing) למוצר שעולות על בעיות בשלב מוקדם. המטרה היא להדגיש שמעבר של בדיקות אלה חשוב לא פחות מעבר של Unit Test, כל בדיקה שכזו יכולה להכשיל את הPipeline.
לאט זה המפתח
טעות נפוצה מאוד שנתקלתי בה היא פריסה של כמה אמצעי אבטחת מידע במקביל כמו שירות Static Code Analyzer ושירות שמוודא עמידה ברגולציה (Compliance) כמו AWS Config, זה עלול לגרום לבלאגן גדול בתהליך הפיתוח ולהוות מטרד על המפתחים שיצטרכו להתרגל להרבה שינויים במכה אחת.
פריסה של כלי עם המון יכולות והפעלתן בבת אחת היא גם טעות, במיוחד כלים שמבצעים המון בדיקות ועלולים להחזיר הרבה שגיאות בהרצה הראשונה. הטעות הזו עלולה לגרום לעומס לא הכרחי על צוות הDevOps שיפגע באיכות המוצר ובתהליך העבודה.
לכן מה שצריך לעשות זה להטמיע את הכלים האלה אחד אחרי השני עם מרווח בין לבין ולא להפעיל את כל הבדיקות בבת אחת, אחרי כל הפעלה של יכולת נוספת צריך לתת זמן לצוות להתרגל אליה ולהבין את התרומה שלה לארגון.
שמרו על זה בסוד
“Secrets” במונחים של אבטחת מידע הם כל המידע הפרטי שקיים במערכת בין עם זה סיסמאות, מפתחות SSH, מפתחות ל-API, תעודות SSL וכדומה.
ה”סודות” צריכים להישמר בצורה מאובטחת ובמקום מרוכז אחד ולא מפוזרים לאורך כל תהליך העבודה ובטח ובטח שלא רשומים כText ומסוכנרים כחלק מהGit Repo שלנו.
בנוסף לשמירה עליהם חשוב גם להחליף אותם בתדירות מסוימת כדי לצמצם גישה ולמנוע מתוקף שכבר קיבל גישה לאחד המקורות שלי להיכנס שוב. ישנם המון שירותים בתעשייה שדואגים גם לשמירה וגם להחלפה האוטומטית של הערכים, לכל ספקי הענן יש כלי כזה, למשל HashiCorp Vault או AWS Secrets Manager או Azure Key Vault
תרבות ארגונית – זה תלוי בכולנו
אבטחת מידע זה שילוב של עבודה רציפה ותכנון. בארגונים גדולים בין עם זה בתחום הפיננסים או הרפואה יש לעמוד בתקנות מחמירות מאוד (באנגלית Compliance) על מנת בכלל להתחיל לעבוד ולהשיק מוצרים בתחום.
כדי לעמוד בתקנות אלה חייבים לתכנן לטווח רחוק ולוודא שכל עבודה שנעשית שומרת על עקרונות אבטחת המידע. גם מפתחים וגם אנשי אופרציה צריכים לשמור עירנות ולקחת חלק בתהליך ולהבין את גודל האחראיות שיש להם.
כל מי שמעורב בתהליך פיתוח התוכנה, מהבורג הקטן ביותר ועד ארכיטקט המערכת צריך להכיר את הרעיונות הבסיסיים ולהיות חשוף למצב בחוץ. ישנם ארגונים שאינם למטרות רווח כמו Open Web Application Security Project (OWASP) שדואגים לעדכן את הרשת בהתפתחויות השונות בתחום מתקפות הWeb. חינוך לאבטחת מידע של כל מי שלוקח חלק בארגון יכול רק להטיב עם הארגון.
גם לנו המפתחים חשוב לשמור על המוצרים שלנו מאובטחים ונגישים,
הרי להתעסק בקוד בחמישי בערב בגלל פרצת אבטחה שהתגלתה זה משהו שאף אחד לא רוצה להיכנס אליו.
כמה מילים אחרונות
מקווה שקראתם ונהנתם מהכתבה, נגעתי בכמה נקודות מפנה של ממש בגישה של עולם התוכנה החדש ובכלל במצב הקיים בתעשייה.
אם תרצו לגלות וללמוד עוד על עולם הDevOps ועל איך מתמודדים עם הענן הציבורי
חכו לפוסטים הבאים 