DevOps שילוב היבטי אבטחת מידע בתהליכי
במאמרים קודמים ניתנה סקירה על תהליכי פיתוח מבוססי DevOps. במאמר זה, נתמקד בהיבטי אבטחת המידע בתהליכי DevOps.
שרטוט של תהליך DevOps:
עולם ה-DevOps נועד לתת מענה משלים מצד אחד לעולמות הפיתוח המהיר (agile לצורותיו) וכן פתרון לסביבות הענן, בהן אנשי ה-IT הופכים לחלק ממשי מעולם הפיתוח. בעולמות ה- DevOps, ניהול מערך גדול מאוד של סביבות אינו אפשרי באופן ידני. ניטור של סביבות מעורבות הופך להיות סבך של פתרונות והפצת גרסאות הופכת להיות זריזה ורגישה לשינויים.
חלומו של כל פתרון ומערך DevOps הינו מתן מענה מידי והקמה של תהליך CI/CD מלא, דהיינו שינויים תכופים והפצה מידית של גרסאות. לעומת זאת, לאנשי מערך אבטחת המידע תהליך כזה נראה במבט ראשוני כסיוט ממשי – עשרות גרסאות, בדיקות חלקיות, אין בקרה של עין אנושית על כל שינוי ועוד.
לכן, נדרש מאנשי אבטחת המידע לאמץ את גישת DevOps לליבם, דהיינו להשתלב בתהליכים אלו בכל שלב, להיות חלק אינטגרלי מסביבת הפיתוח ומתהליכי הפצת התוכנה או שינויי הסביבות.
חשוב להבהיר שאין השלבים הללו רציפים כבעולם ה- Waterfall אלא חלקם הגדול מקבילים, בעולם ה-CI/CD הכול משתנה ומהר, מספר רכיבים יכולים להיות בשלבים שונים של התהליך ולכן ישנו צורך אמתי להנחיל את התהליכים, השיטות והכלים בכלל צוותי הפיתוח וה- DevOps.
על-מנת להבין כיצד ניתן לשלב היבטי אבטחת מידע בתהליך פיתוח מבוסס DevOps, כדאי שנסקור את השלבים השונים בתהליך הפיתוח:
(Plan) שלב התכנון
שלב זה בתהליך הפיתוח עוסק באיסוף הדרישות העסקיות.
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• איסוף דרישות אבטחת מידע (דוגמת אימות, הזדהות, תיעוד, הצפנה וכו')
• ביצוע Threat modeling לאיתור חולשות אפשריות בקוד
• הדרכה לאנשי הפיתוח וה- DevOps בנושא פיתוח מאובטח
(Create / Code) שלב היצירה / כתיבת הקוד
שלב זה בתהליך הפיתוח עוסק בכתיבת הקוד עצמו. בשלב זה מומלץ לשלב את ההיבטים הבאים:
• חיבור סביבת הפיתוח (IDE) למוצרי Static Code Analysis
• בחינת ארכיטקטורת הפתרון ע"י מומחה אבטחת מידע או security champion מטעמו
• בחינת רכיבי קוד פתוח המשולבים בקוד המפותח
(Verify / Test) שלב הבדיקות
שלב זה בתהליך הפיתוח עוסק בתהליכי הבדיקות, לרוב ע"י אנשי ה-QA.
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• הרצת כלי SAST (Static application security tool) על הקוד עצמו (לפני שלב ה-compile)
• הרצת כלי DAST (Dynamic application security tool) על הקוד הבינארי (לאחר שלב ה-compile)
• הרצת כלי IAST (Interactive application security tool) למול האפליקציה עצמה
• הרצת כלי SCA (Software Composition Analysis) לאיתור חולשות אבטחה בקוד פתוח או ברכיבי צד ג’.
(Preproduction) לפני המעבר לסביבת הייצור (Package) שלב הכנת חבילות התוכנה
בשלב זה מבוצע תהליך אריזת הקוד לחבילת תוכנה המיועדת להפצה.
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• הרצת כלי IAST (Interactive application security tool) למול האפליקציה עצמה
• הרצת כלי fuzzing לזיהוי חולשות דוגמת Buffer overflow, ניתן להחיל שלב זה באופן אוטומטי בסביבת ה Build באמצעות שלב ייחודי אשר מבצע Fuzzing או בדיקות אבט"מ בתצורת functional testing \ negative testing.
• חתימת הקוד (Code signing) לאיתור שינויים עתידיים (דוגמת malwares)
(Release) שלב שחרור חבילות התוכנה
זהו שלב ביניים בין שלב הכנת ה-Package לבין שלב ההפצה (Deploy).
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• וידוא חתימת הקוד לחתימה המקורית בזמן יצירת חבילת התוכנה (Package)
• ביצוע בדיקות אמינות (Integrity) לחבילת התוכנה
• הפצה לסביבת Dev והרצת אוטומציות או בדיקות Stress
•ניתן להפיץ בתצורת Green\Blue לצורך בקרת איכות ובדיקות אבטחת מידע מקיפות יותר
(Deploy) שלב ההפצה
זהו השלב בו חבילת התוכנה (דוגמת קוד לאפליקציית מובייל, Docker container וכו') עובר לשלב ההפצה.
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• הרשאות גישה לתיקיות היעד (במקרה של פריסת קוד לשרתי Web)
• הרשאות גישה ל-Docker Registry
• הרשאות לשירותים נוספים בסביבת הענן (אחסון, בסיסי נתונים, אפליקציות ועוד), טיוב הRole שבאמצעותו רץ הקוד.
(Configure / Operate / Tune) שלב התפעול השוטף
בשלב זה הפיתוח נמצא בסביבת הייצור ועובר התאמות (בהתאם לצורך) ותחזוקה שוטפת.
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• תהליכי הפצת עדכוני אבטחה (Patch Management) או ניהול תצורה באמצעות כלים כגון Ansible, Chef ועוד
• תהליכי סריקה לאיתור חולשות אבטחה באמצעות כלי Vulnerability assessment
• מחיקת והפצה מחדש של סביבות פגיעות בתצורה מעודכנת באם ניתן
(Monitor) שלב הניטור השוטף
בשלב זה מבוצע ניטור שוטף אחר האפליקציה ע"י צוותי התשתיות/שו"ב.
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• כלי הגנה בטכנולוגיית RASP (Runtime Application Self-Protection)
• יישום הגנות בשכבת האפליקציה דוגמת WAF (Web Application Firewall)
• כלי הגנה מפני מתקפות מבוססות Botnets
• כלי הגנה מפני מתקפות מניעת שירות (DoS / DDoS)
• ביצוע בדיקות חוסן (Penetration Testing)
• הקמת מערך ניטור באמצעות חוקים אוטומטיים כגון שחזור של שינויים רגישים באופן אוטומטי (כלים כגון GuardRails)
: DevOps / CI/CD המלצות אבטחת מידע בעת פיתוחי
• מומלץ לבצע הכשרה שוטפת לצוותי הפיתוח וה-DevOps בכל הקשור להיבטי אבטחת מידע ופיתוח מאובטח
• מומלץ למנות security champions מקרב צוותי הפיתוח וה-DevOps על-מנת לאפשר להם לבצע threat modeling בשלבים מוקדמים של הפיתוח וכך לשלב היבטי אבטחת מידע, מוקדם ככל הניתן בתהליכי הפיתוח
• שימוש בכלי אוטומציה מאפשר להקים סביבות בצורה פשוטה וסטנדרטית, אך כלים דוגמת Puppet הינם בעלי גישת Root לכל מחיצה אליו יש לו גישה. על-מנת לצמצם את הסיכון, יש להפעיל ניטור על גישה לתיקיות.
• יש להימנע משמירת סיסמאות ו-access keys בצורה מובנית (hard-coded) בתוך סקריפטים וקטעי קוד.
• מומלץ לאחסן נתוני הזדהות (API keys, privileged credentials, SSH keys וכו') בכספת (פתרונות דוגמת HashiCorp Vault או CyberArk)
• נדרש לצמצם הרשאות גישה על-בסיס תפקיד (Role based access control) בשיטת least privileged.
• מומלץ לבצע הפרדה רשתית מלאה בין סביבת הייצור (Prod) לייתר סביבות הפיתוח (Dev, Test, UAT וכו')
• מומלץ למנוע כל גישה של אנשי פיתוח לסביבות הייצור ולאפשר גישה אך ורק לאנשי ה-DevOps
• מומלץ לבצע תיעוד ובקרה אחר גישה לסביבות המערכת השונות ולאתר חריגות בניסיונות הגישה (דוגמת ניסיון גישה של איש פיתוח לסביבות הייצור)
• מומלץ לוודא כי מידע רגיש (נתוני לקוחות, נתוני הזדהות וכו') אינו מועבר ברשת ובמידה וקיימת דרישה עסקית להעברת מידע רגיש ברשת, יש לוודא כי המידע מועבר באמצעות פרוטוקולים מוצפנים (דוגמת TLS 1.2, SSH v2 וכו'), תוך שימוש ב- Strong cipher suites.
• מומלץ לפעול בהתאם להמלצות של ארגון OWASP (ראה OWASP Top10, OWASP ASVS וכו')
• בעת שימוש ב-Containers, מומלץ להשתמש ב-Containers ממקורות חתומים ומוכרים.
• בעת שימוש ב-Containers, מומלץ שלא להסתמך על עדכניות ספריות הקוד הפתוח בתוך ה-Containers ולבצע סריקה לאיתור גרסאות פגיעות (לרבות dependencies), כבר במהלך יצירת ה-build.
• בעת שימוש ב-Containers, מומלץ לבצע הקשחה באמצעות מדריכים דוגמת CIS Docker Benchmark או CIS Kubernetes Benchmark.
• מומלץ להטמיע כלים אוטומטיים לביצוע פעולות שוטפת, החל מפריסת גרסאות חדשות של האפליקציה, דרך מנגנונים לאיתור חולשות אבטחה בקוד הקיים (Code Review) וברכיבי קוד פתוח, ועד מנגנוני עדכון טלאי אבטחה, אשר יוטמעו בתהליכי הפיתוח ויצירת ה-build.
• מומלץ לבצע תהליכי סריקה לאיתור חולשות אבטחה (Vulnerability management) בצורה שוטפת במהלך חיי המערכת.
• מומלץ להטמיע כלי בקרת תצורה (Configuration management), על-מנת לאתר ולתקן בצורה אוטומטית חריגות מהתצורה המקורית שהוגדרה.
:מקורות מידע נוספים
• The DevOps Security Checklist
• Making AppSec Testing Work in CI/CD
• Value driven threat modeling
• Security at the Speed of DevOps
• DevOps Security Best Practices
• The integration of DevOps and security
• When DevOps met Security - DevSecOps in a nutshell
• Grappling with DevOps Security
• Minimizing Risk and Improving Security in DevOps
• Application Security in Devops
• Five Security Defenses Every Containerized Application Needs
• 5 ways to find and fix open source vulnerabilities
• 20 Ways to Make Application Security Move at the Speed of DevOps
Cloud Security Architect ,מאת: אייל אסטרין
Application Security Architect ,ויטלי אוניק
DevOps שילוב היבטי אבטחת מידע בתהליכי
במאמרים קודמים ניתנה סקירה על תהליכי פיתוח מבוססי DevOps. במאמר זה, נתמקד בהיבטי אבטחת המידע בתהליכי DevOps.
שרטוט של תהליך DevOps:
עולם ה-DevOps נועד לתת מענה משלים מצד אחד לעולמות הפיתוח המהיר (agile לצורותיו) וכן פתרון לסביבות הענן, בהן אנשי ה-IT הופכים לחלק ממשי מעולם הפיתוח. בעולמות ה- DevOps, ניהול מערך גדול מאוד של סביבות אינו אפשרי באופן ידני. ניטור של סביבות מעורבות הופך להיות סבך של פתרונות והפצת גרסאות הופכת להיות זריזה ורגישה לשינויים.
חלומו של כל פתרון ומערך DevOps הינו מתן מענה מידי והקמה של תהליך CI/CD מלא, דהיינו שינויים תכופים והפצה מידית של גרסאות. לעומת זאת, לאנשי מערך אבטחת המידע תהליך כזה נראה במבט ראשוני כסיוט ממשי – עשרות גרסאות, בדיקות חלקיות, אין בקרה של עין אנושית על כל שינוי ועוד.
לכן, נדרש מאנשי אבטחת המידע לאמץ את גישת DevOps לליבם, דהיינו להשתלב בתהליכים אלו בכל שלב, להיות חלק אינטגרלי מסביבת הפיתוח ומתהליכי הפצת התוכנה או שינויי הסביבות.
חשוב להבהיר שאין השלבים הללו רציפים כבעולם ה- Waterfall אלא חלקם הגדול מקבילים, בעולם ה-CI/CD הכול משתנה ומהר, מספר רכיבים יכולים להיות בשלבים שונים של התהליך ולכן ישנו צורך אמתי להנחיל את התהליכים, השיטות והכלים בכלל צוותי הפיתוח וה- DevOps.
על-מנת להבין כיצד ניתן לשלב היבטי אבטחת מידע בתהליך פיתוח מבוסס DevOps, כדאי שנסקור את השלבים השונים בתהליך הפיתוח:
(Plan) שלב התכנון
שלב זה בתהליך הפיתוח עוסק באיסוף הדרישות העסקיות.
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• איסוף דרישות אבטחת מידע (דוגמת אימות, הזדהות, תיעוד, הצפנה וכו')
• ביצוע Threat modeling לאיתור חולשות אפשריות בקוד
• הדרכה לאנשי הפיתוח וה- DevOps בנושא פיתוח מאובטח
(Create / Code) שלב היצירה / כתיבת הקוד
שלב זה בתהליך הפיתוח עוסק בכתיבת הקוד עצמו. בשלב זה מומלץ לשלב את ההיבטים הבאים:
• חיבור סביבת הפיתוח (IDE) למוצרי Static Code Analysis
• בחינת ארכיטקטורת הפתרון ע"י מומחה אבטחת מידע או security champion מטעמו
• בחינת רכיבי קוד פתוח המשולבים בקוד המפותח
(Verify / Test) שלב הבדיקות
שלב זה בתהליך הפיתוח עוסק בתהליכי הבדיקות, לרוב ע"י אנשי ה-QA.
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• הרצת כלי SAST (Static application security tool) על הקוד עצמו (לפני שלב ה-compile)
• הרצת כלי DAST (Dynamic application security tool) על הקוד הבינארי (לאחר שלב ה-compile)
• הרצת כלי IAST (Interactive application security tool) למול האפליקציה עצמה
• הרצת כלי SCA (Software Composition Analysis) לאיתור חולשות אבטחה בקוד פתוח או ברכיבי צד ג’.
(Preproduction) לפני המעבר לסביבת הייצור (Package) שלב הכנת חבילות התוכנה
בשלב זה מבוצע תהליך אריזת הקוד לחבילת תוכנה המיועדת להפצה.
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• הרצת כלי IAST (Interactive application security tool) למול האפליקציה עצמה
• הרצת כלי fuzzing לזיהוי חולשות דוגמת Buffer overflow, ניתן להחיל שלב זה באופן אוטומטי בסביבת ה Build באמצעות שלב ייחודי אשר מבצע Fuzzing או בדיקות אבט"מ בתצורת functional testing \ negative testing.
• חתימת הקוד (Code signing) לאיתור שינויים עתידיים (דוגמת malwares)
(Release) שלב שחרור חבילות התוכנה
זהו שלב ביניים בין שלב הכנת ה-Package לבין שלב ההפצה (Deploy).
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• וידוא חתימת הקוד לחתימה המקורית בזמן יצירת חבילת התוכנה (Package)
• ביצוע בדיקות אמינות (Integrity) לחבילת התוכנה
• הפצה לסביבת Dev והרצת אוטומציות או בדיקות Stress
•ניתן להפיץ בתצורת Green\Blue לצורך בקרת איכות ובדיקות אבטחת מידע מקיפות יותר
(Deploy) שלב ההפצה
זהו השלב בו חבילת התוכנה (דוגמת קוד לאפליקציית מובייל, Docker container וכו') עובר לשלב ההפצה.
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• הרשאות גישה לתיקיות היעד (במקרה של פריסת קוד לשרתי Web)
• הרשאות גישה ל-Docker Registry
• הרשאות לשירותים נוספים בסביבת הענן (אחסון, בסיסי נתונים, אפליקציות ועוד), טיוב הRole שבאמצעותו רץ הקוד.
(Configure / Operate / Tune) שלב התפעול השוטף
בשלב זה הפיתוח נמצא בסביבת הייצור ועובר התאמות (בהתאם לצורך) ותחזוקה שוטפת.
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• תהליכי הפצת עדכוני אבטחה (Patch Management) או ניהול תצורה באמצעות כלים כגון Ansible, Chef ועוד
• תהליכי סריקה לאיתור חולשות אבטחה באמצעות כלי Vulnerability assessment
• מחיקת והפצה מחדש של סביבות פגיעות בתצורה מעודכנת באם ניתן
(Monitor) שלב הניטור השוטף
בשלב זה מבוצע ניטור שוטף אחר האפליקציה ע"י צוותי התשתיות/שו"ב.
בשלב זה מומלץ לשלב את ההיבטים הבאים:
• כלי הגנה בטכנולוגיית RASP (Runtime Application Self-Protection)
• יישום הגנות בשכבת האפליקציה דוגמת WAF (Web Application Firewall)
• כלי הגנה מפני מתקפות מבוססות Botnets
• כלי הגנה מפני מתקפות מניעת שירות (DoS / DDoS)
• ביצוע בדיקות חוסן (Penetration Testing)
• הקמת מערך ניטור באמצעות חוקים אוטומטיים כגון שחזור של שינויים רגישים באופן אוטומטי (כלים כגון GuardRails)
: DevOps / CI/CD המלצות אבטחת מידע בעת פיתוחי
• מומלץ לבצע הכשרה שוטפת לצוותי הפיתוח וה-DevOps בכל הקשור להיבטי אבטחת מידע ופיתוח מאובטח
• מומלץ למנות security champions מקרב צוותי הפיתוח וה-DevOps על-מנת לאפשר להם לבצע threat modeling בשלבים מוקדמים של הפיתוח וכך לשלב היבטי אבטחת מידע, מוקדם ככל הניתן בתהליכי הפיתוח
• שימוש בכלי אוטומציה מאפשר להקים סביבות בצורה פשוטה וסטנדרטית, אך כלים דוגמת Puppet הינם בעלי גישת Root לכל מחיצה אליו יש לו גישה. על-מנת לצמצם את הסיכון, יש להפעיל ניטור על גישה לתיקיות.
• יש להימנע משמירת סיסמאות ו-access keys בצורה מובנית (hard-coded) בתוך סקריפטים וקטעי קוד.
• מומלץ לאחסן נתוני הזדהות (API keys, privileged credentials, SSH keys וכו') בכספת (פתרונות דוגמת HashiCorp Vault או CyberArk)
• נדרש לצמצם הרשאות גישה על-בסיס תפקיד (Role based access control) בשיטת least privileged.
• מומלץ לבצע הפרדה רשתית מלאה בין סביבת הייצור (Prod) לייתר סביבות הפיתוח (Dev, Test, UAT וכו')
• מומלץ למנוע כל גישה של אנשי פיתוח לסביבות הייצור ולאפשר גישה אך ורק לאנשי ה-DevOps
• מומלץ לבצע תיעוד ובקרה אחר גישה לסביבות המערכת השונות ולאתר חריגות בניסיונות הגישה (דוגמת ניסיון גישה של איש פיתוח לסביבות הייצור)
• מומלץ לוודא כי מידע רגיש (נתוני לקוחות, נתוני הזדהות וכו') אינו מועבר ברשת ובמידה וקיימת דרישה עסקית להעברת מידע רגיש ברשת, יש לוודא כי המידע מועבר באמצעות פרוטוקולים מוצפנים (דוגמת TLS 1.2, SSH v2 וכו'), תוך שימוש ב- Strong cipher suites.
• מומלץ לפעול בהתאם להמלצות של ארגון OWASP (ראה OWASP Top10, OWASP ASVS וכו')
• בעת שימוש ב-Containers, מומלץ להשתמש ב-Containers ממקורות חתומים ומוכרים.
• בעת שימוש ב-Containers, מומלץ שלא להסתמך על עדכניות ספריות הקוד הפתוח בתוך ה-Containers ולבצע סריקה לאיתור גרסאות פגיעות (לרבות dependencies), כבר במהלך יצירת ה-build.
• בעת שימוש ב-Containers, מומלץ לבצע הקשחה באמצעות מדריכים דוגמת CIS Docker Benchmark או CIS Kubernetes Benchmark.
• מומלץ להטמיע כלים אוטומטיים לביצוע פעולות שוטפת, החל מפריסת גרסאות חדשות של האפליקציה, דרך מנגנונים לאיתור חולשות אבטחה בקוד הקיים (Code Review) וברכיבי קוד פתוח, ועד מנגנוני עדכון טלאי אבטחה, אשר יוטמעו בתהליכי הפיתוח ויצירת ה-build.
• מומלץ לבצע תהליכי סריקה לאיתור חולשות אבטחה (Vulnerability management) בצורה שוטפת במהלך חיי המערכת.
• מומלץ להטמיע כלי בקרת תצורה (Configuration management), על-מנת לאתר ולתקן בצורה אוטומטית חריגות מהתצורה המקורית שהוגדרה.
:מקורות מידע נוספים
• The DevOps Security Checklist
• Making AppSec Testing Work in CI/CD
• Value driven threat modeling
• Security at the Speed of DevOps
• DevOps Security Best Practices
• The integration of DevOps and security
• When DevOps met Security - DevSecOps in a nutshell
• Grappling with DevOps Security
• Minimizing Risk and Improving Security in DevOps
• Application Security in Devops
• Five Security Defenses Every Containerized Application Needs
• 5 ways to find and fix open source vulnerabilities
• 20 Ways to Make Application Security Move at the Speed of DevOps
Cloud Security Architect ,מאת: אייל אסטרין
Application Security Architect ,ויטלי אוניק
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר
