זה לא סוד ש- DevOps ואבטחת מידע הם כמו שמן ומים – קשה לשלב ביניהם. אחרי הכל, DevOps נועד להשיג מהירות, ואילו אבטחה עוסקת בזהירות. עם זאת, גם ה- DevOps וגם אבטחת מידע משרתים מטרה גדולה יותר – הפעילות העסקית – וזו תפעל רק אם השניים ילמדו לעבוד יחדיו.
ניתן (וצריך) להטמיע תהליכי אבטחה אל תוך תהליכי ה- DevOps, ויחד הם יצרו את מה שמכונה לרוב: DevSecOps. צוותי אבטחת מידע מחויבים להבין כיצד אפליקציות ונתונים נעים משלב הפיתוח והבדיקות אל סביבת הייצור, ולטפל בחולשות והפרצות שנמצאות בדרך. במקביל, צוותי DevOps חייבים להבין שאבטחה, לפחות בחלקה, היא תחת אחריותם, והיא בטח לא משהו שמשליכים על האפליקציה בסוף התהליך.
מכיוון שחצי מהמשוואה כאן היא ההפיכה של אנשי ה- DevOps למודעים יותר לאבטחת מידע, הרכבנו רשימה של עקרונות אבטחה בסיסיים ושל ההשלכות שלהם על סביבת DevOps. כמובן שרשימה זו היא רק הבסיס הראשוני.
חולשות לעומת קוד פריצה (Vulnerabilities vs. exploits)
חולשות (Vulnerability) או פרצות של מערכת עלולות לאפשר לתוקף לפגוע. הן קיימות בדרך כלל בגלל קוד גרוע, שגיאות בתכנון או טעויות בתכנות. למעשה מדובר לרוב בבאגים, ואף על פי שאלו באגים שאינם פוגעים בפעילות התוכנה, הם פותחים דלת לתוקף אפשרי. כאשר משתמשים ברכיב קוד פתוח, מומלץ לסרוק את הקוד לאתר נקודות תורפה מוכרות (CVE). קוד פריצה (Exploit), לעומת זאת, הוא תוכנה המנצלת את נקודת החולשה – ולמעשה, מאפשר התקפה. שכיח מאוד שחולשה מתגלה על ידי חוקר אבטחה White Hat, והיא תעבור תיקון ועדכון לפני שבכלל תנוצל על ידי כלי פריצה. עם זאת, יש לעשות הכל כדי למנוע מצב בו נעשה שימוש בקוד פריצה "בשטח", ולשם כך יש להשתמש בתהליך ניהול חולשות אוטומטי המשתלב בתהליך הפיתוח והאספקה באמצעות כלי CI/CD.
חולשת יום אפס (Zero-Day) לעומת חולשות ידועות (CVE)
נקודות תורפה של תוכנות ציבוריות יכולות להיפתר על ידי מתכנת, ולרוב הן ניתנות לתיקון באמצעות שדרוג הרכיב הפגיע. נקודות תורפה שכאלה מתויגות ברשימת Common Vulnerabilities and Exposures המתופעלת על ידי MITRE ונגישה לכל אחד. לעומת זאת, במצבים מסוימים האקרים מגלים נקודות תורפה חדשות לפני שהן הופכות לציבוריות וזוכות לתיקון. חולשות יום אפס שכאלה הן מסוכנות ביותר, אבל הן נפוצות פחות. אין דרך לגלות אותן מראש. עם זאת ניתן למזער את הסיכון באמצעות סגמנטציה של הרשת, ניטור רציף, והצפנת מידע רגיש. ניתן גם להפעיל כלי ניתוח אנליטיים של התנהגות ולימוד מכונה כדי לזהות חריגות בפעילות אפליקציה.
שטח ההתקפה (Attack Surface)
השטח הפוטנציאלי של ההתקפה מורכב מסך אפשרויות הגישה למערכת שעומדות בפני תוקפים. תמיד מומלץ למזער את שטח ההתקפה הפוטנציאלי באמצעות כיבוי או הסרת חלקים במערכת שאינם נדרשים לצורך עומס עבודה מסוים. בסביבות DevOps, שם אפליקציות מופעלות ומתעדכנות בתדירות גבוהה, קל לאבד שליטה על הרכיבים השונים ורכיבי הקוד שנכללים, משתנים או מתווספים לכל עדכון. לאורך זמן, הדבר יכול ליצור שטח תקיפה מנופח. לכן, חשוב להבין את עומסי העבודה ולהגדיר שרתים ואפליקציות באופן אופטימלי, ולהסיר יכולות ורכיבים שאינם הכרחיים. יש לבצע התאמות לכל עומס עבודה או לפחות לכל קבוצת אפליקציות ורמות אמון, משום שהחלת כללים אחידים על כל הסביבה לא תהיה אפקטיבית
עקרון ה- Least-Privilege
העיקרון קובע שמשתמשים ורכיבי אפליקציות צריכים לקבל רק את הגישה המזערית ביותר למידע ומשאבים. זאת כדי למנוע שימוש שגוי במערכת – בכוונה או בטעות. הפעלת מדיניותLeast Privileges יכולה למנוע התפשטות של קוד זדוני שינסה פעמים רבות להשתמש בהרשאות שיש למשתמש המותקף. מומלץ לבדוק באופן תקופתי את הרשאות המשתמשים ולהגביל אותן בהתאם. בסביבות DevOps, מומלץ להגדיר הרשאות גישה לפיתוח, בדיקות, staging וסביבות ייצור.
תנועה רוחבית (מזרח מערב)
תנועה רוחבית, המכונה לעיתים גם "מתקפות מזרח-מערב", מתייחסת ליכולת של תוקף לנוע לרוחב רשתות, משרת לשרת או מאפליקציה לאפליקציה, ובכך להרחיב את היקף ההתקפה או לנוע אל עבר נכסים יוקרתיים יותר. זה שונה מתנועת צפון-דרום, המתייחסת למעבר בין שכבות, לדוגמא, מרמת אפליקצית הרשת אל בסיס הנתונים. נקודות בקרה ברשת, כגון סגמנטציה, חיוניים כדי למנוע תנועה רוחבית וכדי למזער את הנזק של התקפה מוצלחת. מכיוון שאחד מהיעדים של DevOps הוא להסיר חסמים, מדובר בנושא מאתגר. חשוב לבצע את ההבחנה בין שמירה על פתיחות בתהליך האספקה, בין הפיתוח לייצור, לבין שמירה על פתיחות לרוחב הרשת. הראשון תורם לאג'יליות (גמישות) וליעילות, והשני כמעט ולא נוגע בכך. לדוגמא, לרוב מתרחש דו-שיח בין התהליכים השונים הנדרשים לאספקת אפליקציות. אם יש לך אפליקציית מסחר אלקטרוני ואפליקציית ERP, והן מפותחות על ידי צוותים שונים, אז הן שייכות לסגמנטים שונים ברשת. אין שום הצדקה מצד ה- DevOps לאפשר רשת פתוחה בין השניים.
הפרדת סמכויות (Segregation of duties)
זוכרים את הסרטים בהם שני אנשים מסובבים מפתחות באותו הזמן כדי לשגר טיל גרעיני? הפרדת סמכויות עוסקת בהגבלת ההרשאות שיש למשתמשים כדי לגשת למערכות ולנתונים רגישים, כדי שלא תהיה. לדוגמא, נכון יהיה להפריד הרשאות ניהול של שרת מהרשאות לאפליקציה שרצה על אותו השרת. בסביבת DevOps, המפתח הוא ביצוע הפרדה של סמכויות כחלק מתהליכי ה- CI/CD ולהפעיל אותם באופן שווה על מערכות ומשתמשים, כך ששום מערכת או משתמש בודדים יהיו מוגלים לפגוע בסביבת הייצור.
חילוץ מידע (Data exfiltration)
חילוץ מידע בלתי מורשה מהמערכת יכול לגרום לנפילת מידע רגיש בידי גורמים שאינם מורשים. לעיתים מכנים זאת "גניבת מידע", אבל מדובר בגניבה שונה מזו של העולם הפיזי: הנתונים שנגנבו עדיין נותרים באותו המקום כך שקשה לזהות את האובדן. כדי למנוע חילוץ מידע, יש להבטיח ש"סודות" ומידע רגיש, כגון מידע אישי, סיסמאות ונתוני אשראי, יהיו מוצפנים. יש גם למנוע קישוריות לרשת חיצונית במקומות בהם היא אינה נדרשת. בסביבות פיתוח, מומלץ להשתמש ב- masking של נתונים ובנתונים מזויפים. שימוש בנתונים אמיתיים מחייב אותך להגן על סביבת הפיתוח כמו על סביבת הייצור.
מתקפת מניעת שירות (DoS)
DoS הוא אפיק תקיפה שמטרתו למנוע מהמשתמשים שלך לקבל שירות מהמערכות. הדבר נעשה באמצעות מגוון שיטות המייצרות עומס מאסיבי על שרתים, אפליקציות או רשתות, ואשר משתקות אותם או גורמות להם לקרוס. באינטרנט, מדובר בדרך כלל במתקפה מבוזרת (DDoS), שקשה יותר לחסום מכיוון שהיא לא מגיעה מ- IP יחיד. עם זאת, גם מתקפת DoS ממקור בודד יכולה להיות הרסנית כאשר היא מגיעה מבפנים, כגון מקונטיינר שנפרץ. יש דרכים מגוונות לזהות ולמנוע מתקפות DoS, אבל הגדרה נכונה והיצמדות לעקרונות הבסיסיים של מזעור שטח התקיפה, עדכון תוכנות, ו- least Privileges יכולה לעשות הרבה כדי למנוע אירועים שכאלה. דווקא ארגונים המפעילים שיטות DevOps יכולים להתאושש מהר יותר מ- DoS מכיוון שהם יכולים להעלות במהירות את האפליקציות ב- nodes שונים.
מתקפות מתמשכות (APT – Advanced Persistent Threat)
APT הוא השם שניתן להתקפות מתוחכמות שלוקח לעיתים חודשים לגלות. בתרחיש טיפוסי, חודר ימצא נקודת פריצה דרך נקודת תורפה או בעיה בהגדרות, וישתול קוד שיאסוף נתוני תעבורה ברשת או שיסרוק תהליכים. באמצעות הנתונים שנאספו התוקף יתקדם לשלב הבא של ההתקפה, לדוגמא, חדירה לעומק הרשת. תהליך זה יימשך עד שהתוקף ישים את ידיו על נכס בעל ערך, כגון נתוני לקוחות או נתונים פיננסים. בשלב זה הוא יפנה לחילוץ המידע. בסביבת DevOps קשה יותר לזהות פעילות שכזו כתוצאה מהדינאמיות של הפעילות. מעבר לסגירת נקודות תורפה, יישום הדוק של least privilege והקשחת הסביבה, צריך גם להטמיע סגמנטציה של הרשת כדי למנוע את התקדמות התוקף.
"תנועה שמאלה" של האבטחה
אחת מהתוצאות של פיתוח מתמשך ומחזורי DevOps מהירים, היא שמפתחים חייבים לקחת על עצמם יותר אחריות לגבי אבטחת הקוד. הטעויות שלהם משולבות ישירות באפליקציה, ושערי האבטחה המסורתיים - בדיקות חדירה וסקירות קוד - פשוט לא עובדים מהר מספיק. בדיקות אבטחה חייבות לבצע "תנועה שמאלה" לשלבים מוקדמים או "במעלה" תהליכי הפיתוח. הדרך הטובה ביותר לעשות זאת היא באמצעות שילוב כלי אבטחה בכלי ה- CI/CD ולהכניס את הצעדים הנדרשים בתהליך ה- Build.
*This article was originally featured in infoworld.com
מאת: אמיר ג'רבי, מייסד ו- CTO , אקווה סקיוריטי
זה לא סוד ש- DevOps ואבטחת מידע הם כמו שמן ומים – קשה לשלב ביניהם. אחרי הכל, DevOps נועד להשיג מהירות, ואילו אבטחה עוסקת בזהירות. עם זאת, גם ה- DevOps וגם אבטחת מידע משרתים מטרה גדולה יותר – הפעילות העסקית – וזו תפעל רק אם השניים ילמדו לעבוד יחדיו.
ניתן (וצריך) להטמיע תהליכי אבטחה אל תוך תהליכי ה- DevOps, ויחד הם יצרו את מה שמכונה לרוב: DevSecOps. צוותי אבטחת מידע מחויבים להבין כיצד אפליקציות ונתונים נעים משלב הפיתוח והבדיקות אל סביבת הייצור, ולטפל בחולשות והפרצות שנמצאות בדרך. במקביל, צוותי DevOps חייבים להבין שאבטחה, לפחות בחלקה, היא תחת אחריותם, והיא בטח לא משהו שמשליכים על האפליקציה בסוף התהליך.
מכיוון שחצי מהמשוואה כאן היא ההפיכה של אנשי ה- DevOps למודעים יותר לאבטחת מידע, הרכבנו רשימה של עקרונות אבטחה בסיסיים ושל ההשלכות שלהם על סביבת DevOps. כמובן שרשימה זו היא רק הבסיס הראשוני.
חולשות לעומת קוד פריצה (Vulnerabilities vs. exploits)
חולשות (Vulnerability) או פרצות של מערכת עלולות לאפשר לתוקף לפגוע. הן קיימות בדרך כלל בגלל קוד גרוע, שגיאות בתכנון או טעויות בתכנות. למעשה מדובר לרוב בבאגים, ואף על פי שאלו באגים שאינם פוגעים בפעילות התוכנה, הם פותחים דלת לתוקף אפשרי. כאשר משתמשים ברכיב קוד פתוח, מומלץ לסרוק את הקוד לאתר נקודות תורפה מוכרות (CVE). קוד פריצה (Exploit), לעומת זאת, הוא תוכנה המנצלת את נקודת החולשה – ולמעשה, מאפשר התקפה. שכיח מאוד שחולשה מתגלה על ידי חוקר אבטחה White Hat, והיא תעבור תיקון ועדכון לפני שבכלל תנוצל על ידי כלי פריצה. עם זאת, יש לעשות הכל כדי למנוע מצב בו נעשה שימוש בקוד פריצה "בשטח", ולשם כך יש להשתמש בתהליך ניהול חולשות אוטומטי המשתלב בתהליך הפיתוח והאספקה באמצעות כלי CI/CD.
חולשת יום אפס (Zero-Day) לעומת חולשות ידועות (CVE)
נקודות תורפה של תוכנות ציבוריות יכולות להיפתר על ידי מתכנת, ולרוב הן ניתנות לתיקון באמצעות שדרוג הרכיב הפגיע. נקודות תורפה שכאלה מתויגות ברשימת Common Vulnerabilities and Exposures המתופעלת על ידי MITRE ונגישה לכל אחד. לעומת זאת, במצבים מסוימים האקרים מגלים נקודות תורפה חדשות לפני שהן הופכות לציבוריות וזוכות לתיקון. חולשות יום אפס שכאלה הן מסוכנות ביותר, אבל הן נפוצות פחות. אין דרך לגלות אותן מראש. עם זאת ניתן למזער את הסיכון באמצעות סגמנטציה של הרשת, ניטור רציף, והצפנת מידע רגיש. ניתן גם להפעיל כלי ניתוח אנליטיים של התנהגות ולימוד מכונה כדי לזהות חריגות בפעילות אפליקציה.
שטח ההתקפה (Attack Surface)
השטח הפוטנציאלי של ההתקפה מורכב מסך אפשרויות הגישה למערכת שעומדות בפני תוקפים. תמיד מומלץ למזער את שטח ההתקפה הפוטנציאלי באמצעות כיבוי או הסרת חלקים במערכת שאינם נדרשים לצורך עומס עבודה מסוים. בסביבות DevOps, שם אפליקציות מופעלות ומתעדכנות בתדירות גבוהה, קל לאבד שליטה על הרכיבים השונים ורכיבי הקוד שנכללים, משתנים או מתווספים לכל עדכון. לאורך זמן, הדבר יכול ליצור שטח תקיפה מנופח. לכן, חשוב להבין את עומסי העבודה ולהגדיר שרתים ואפליקציות באופן אופטימלי, ולהסיר יכולות ורכיבים שאינם הכרחיים. יש לבצע התאמות לכל עומס עבודה או לפחות לכל קבוצת אפליקציות ורמות אמון, משום שהחלת כללים אחידים על כל הסביבה לא תהיה אפקטיבית
עקרון ה- Least-Privilege
העיקרון קובע שמשתמשים ורכיבי אפליקציות צריכים לקבל רק את הגישה המזערית ביותר למידע ומשאבים. זאת כדי למנוע שימוש שגוי במערכת – בכוונה או בטעות. הפעלת מדיניותLeast Privileges יכולה למנוע התפשטות של קוד זדוני שינסה פעמים רבות להשתמש בהרשאות שיש למשתמש המותקף. מומלץ לבדוק באופן תקופתי את הרשאות המשתמשים ולהגביל אותן בהתאם. בסביבות DevOps, מומלץ להגדיר הרשאות גישה לפיתוח, בדיקות, staging וסביבות ייצור.
תנועה רוחבית (מזרח מערב)
תנועה רוחבית, המכונה לעיתים גם "מתקפות מזרח-מערב", מתייחסת ליכולת של תוקף לנוע לרוחב רשתות, משרת לשרת או מאפליקציה לאפליקציה, ובכך להרחיב את היקף ההתקפה או לנוע אל עבר נכסים יוקרתיים יותר. זה שונה מתנועת צפון-דרום, המתייחסת למעבר בין שכבות, לדוגמא, מרמת אפליקצית הרשת אל בסיס הנתונים. נקודות בקרה ברשת, כגון סגמנטציה, חיוניים כדי למנוע תנועה רוחבית וכדי למזער את הנזק של התקפה מוצלחת. מכיוון שאחד מהיעדים של DevOps הוא להסיר חסמים, מדובר בנושא מאתגר. חשוב לבצע את ההבחנה בין שמירה על פתיחות בתהליך האספקה, בין הפיתוח לייצור, לבין שמירה על פתיחות לרוחב הרשת. הראשון תורם לאג'יליות (גמישות) וליעילות, והשני כמעט ולא נוגע בכך. לדוגמא, לרוב מתרחש דו-שיח בין התהליכים השונים הנדרשים לאספקת אפליקציות. אם יש לך אפליקציית מסחר אלקטרוני ואפליקציית ERP, והן מפותחות על ידי צוותים שונים, אז הן שייכות לסגמנטים שונים ברשת. אין שום הצדקה מצד ה- DevOps לאפשר רשת פתוחה בין השניים.
הפרדת סמכויות (Segregation of duties)
זוכרים את הסרטים בהם שני אנשים מסובבים מפתחות באותו הזמן כדי לשגר טיל גרעיני? הפרדת סמכויות עוסקת בהגבלת ההרשאות שיש למשתמשים כדי לגשת למערכות ולנתונים רגישים, כדי שלא תהיה. לדוגמא, נכון יהיה להפריד הרשאות ניהול של שרת מהרשאות לאפליקציה שרצה על אותו השרת. בסביבת DevOps, המפתח הוא ביצוע הפרדה של סמכויות כחלק מתהליכי ה- CI/CD ולהפעיל אותם באופן שווה על מערכות ומשתמשים, כך ששום מערכת או משתמש בודדים יהיו מוגלים לפגוע בסביבת הייצור.
חילוץ מידע (Data exfiltration)
חילוץ מידע בלתי מורשה מהמערכת יכול לגרום לנפילת מידע רגיש בידי גורמים שאינם מורשים. לעיתים מכנים זאת "גניבת מידע", אבל מדובר בגניבה שונה מזו של העולם הפיזי: הנתונים שנגנבו עדיין נותרים באותו המקום כך שקשה לזהות את האובדן. כדי למנוע חילוץ מידע, יש להבטיח ש"סודות" ומידע רגיש, כגון מידע אישי, סיסמאות ונתוני אשראי, יהיו מוצפנים. יש גם למנוע קישוריות לרשת חיצונית במקומות בהם היא אינה נדרשת. בסביבות פיתוח, מומלץ להשתמש ב- masking של נתונים ובנתונים מזויפים. שימוש בנתונים אמיתיים מחייב אותך להגן על סביבת הפיתוח כמו על סביבת הייצור.
מתקפת מניעת שירות (DoS)
DoS הוא אפיק תקיפה שמטרתו למנוע מהמשתמשים שלך לקבל שירות מהמערכות. הדבר נעשה באמצעות מגוון שיטות המייצרות עומס מאסיבי על שרתים, אפליקציות או רשתות, ואשר משתקות אותם או גורמות להם לקרוס. באינטרנט, מדובר בדרך כלל במתקפה מבוזרת (DDoS), שקשה יותר לחסום מכיוון שהיא לא מגיעה מ- IP יחיד. עם זאת, גם מתקפת DoS ממקור בודד יכולה להיות הרסנית כאשר היא מגיעה מבפנים, כגון מקונטיינר שנפרץ. יש דרכים מגוונות לזהות ולמנוע מתקפות DoS, אבל הגדרה נכונה והיצמדות לעקרונות הבסיסיים של מזעור שטח התקיפה, עדכון תוכנות, ו- least Privileges יכולה לעשות הרבה כדי למנוע אירועים שכאלה. דווקא ארגונים המפעילים שיטות DevOps יכולים להתאושש מהר יותר מ- DoS מכיוון שהם יכולים להעלות במהירות את האפליקציות ב- nodes שונים.
מתקפות מתמשכות (APT – Advanced Persistent Threat)
APT הוא השם שניתן להתקפות מתוחכמות שלוקח לעיתים חודשים לגלות. בתרחיש טיפוסי, חודר ימצא נקודת פריצה דרך נקודת תורפה או בעיה בהגדרות, וישתול קוד שיאסוף נתוני תעבורה ברשת או שיסרוק תהליכים. באמצעות הנתונים שנאספו התוקף יתקדם לשלב הבא של ההתקפה, לדוגמא, חדירה לעומק הרשת. תהליך זה יימשך עד שהתוקף ישים את ידיו על נכס בעל ערך, כגון נתוני לקוחות או נתונים פיננסים. בשלב זה הוא יפנה לחילוץ המידע. בסביבת DevOps קשה יותר לזהות פעילות שכזו כתוצאה מהדינאמיות של הפעילות. מעבר לסגירת נקודות תורפה, יישום הדוק של least privilege והקשחת הסביבה, צריך גם להטמיע סגמנטציה של הרשת כדי למנוע את התקדמות התוקף.
"תנועה שמאלה" של האבטחה
אחת מהתוצאות של פיתוח מתמשך ומחזורי DevOps מהירים, היא שמפתחים חייבים לקחת על עצמם יותר אחריות לגבי אבטחת הקוד. הטעויות שלהם משולבות ישירות באפליקציה, ושערי האבטחה המסורתיים - בדיקות חדירה וסקירות קוד - פשוט לא עובדים מהר מספיק. בדיקות אבטחה חייבות לבצע "תנועה שמאלה" לשלבים מוקדמים או "במעלה" תהליכי הפיתוח. הדרך הטובה ביותר לעשות זאת היא באמצעות שילוב כלי אבטחה בכלי ה- CI/CD ולהכניס את הצעדים הנדרשים בתהליך ה- Build.
*This article was originally featured in infoworld.com
מאת: אמיר ג'רבי, מייסד ו- CTO , אקווה סקיוריטי
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר