בניית אבטחה בתכונה בשלב העיצוב

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

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

היום נדבר על אחת מהשיטות הללו שברבים מכם עשויה להיות מוכרת בשם DevSecOps (אבטחת פיתוח תפעול). אז, מהו DevSecOps?

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

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

בדרך כלל, תהליך הפצת תכונה כולל:

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

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

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

בצע מודלים של איומים

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

בואו נקח דוגמה כדי להבין זאת. דמיינו שאתם מפתחים API ש:

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

GET /api/products?search=laptop

​

דגם איום יכול להיראות כמו זה:

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

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

דוגמה למודל איום בכלי תכנון איום של מיקרוסופט

תצוגת ניתוח

תצוגת הניתוח של כלי תכנון האיום מציגה התקפות שונות שעשויות לקרות על ה- API.

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

• שימושים קריפטוגרפיים חלשים. לדוגמה, שימוש ב־SHA1 או MD5 נחשב חלש.CA530 הוא דוגמה לאזהרה שקוד C# יוצר כאשר משתמשים בפונקציות גיבוב חלשות.
• תקיפות הכנסת SQL. CA2100 הוא דוגמה לבדיקה שבודקת האם הקוד סופג לתקיפות הכנסת.
• סיסמאות מוקשות, מנגנוני אימות והרשאה חלשים, ו טעויות תצורה בתשתית יכולות להיות זוהות באמצעות אנליזטים סטטיים.

יש כלים קיימים בתחום זה גם. SonarQube, CodeQL, Roslyn Analyzer, OWASP Dependency Check, ו- Snykיש מגוון טוב בתחום זה.

שילוב ניתוח סטטי בצינורות בנייה גם חשוב. זה מציע יתרונות כמו:

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

סקירות קוד מנקודת מבט אבטחה

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

מסקנה

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

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