אופן בניית הקוד מייצר סיכוני תקיפת סייבר
19 דצמבר, 2021
בזכות תשתיות הענן התקצר תהליך הפיתוח והפריסה של תוכנות ושל השקת שירותים טכנולוגיים חדשים - אלא שהנוחות והמהירות יצרו חולשות אבטחה מסוכנות. הכרתן תאפשר לבצע את תהליך הפיתוח בצורה נכונה ובטוחה
מאת: אורי שמאי, מייסד שותף ו-CTO בחברת Spectral, המספקת פתרונות לאיתור טעויות אבטחה בסביבת הפיתוח
התוכנה היא מרכיב מרכזי בפיתוח כל מוצר טכנולוגי חדש, והחברות נמצאות היום במירוץ לקיצור זמני הפיתוח והאצת מתן השירות ללקוחות. כדי להשיג את המטרה הזאת, המפתחים מאמצים תהליכי אוטומציה המאפשרים לקצר את הזמנים, אבל על-ידי כך הם חושפים גם את עצמם וגם את לקוחותיהם בפני סיכוני אבטחה רבים. אחד השינויים המרכזיים בעולם התוכנה של השנים האחרונות הוא השימוש הגובר בשירותי תוכנה כשירות (Software as a Service – SaaS), אשר מאפשרים להאיץ את תהליך הפיתוח והפריסה, אך גם הן מהווים גורם סיכון לפריצה.
כדי להמחיש את התועלת והסיכון שב-SaaS, נסתכל על מספר דוגמאות. מערכת לניהול תצורה וגרסאות של הקוד: בעבר ארגונים הריצו את מערכת ניהול תצורת הקוד בשרת פיזי בתוך הארגון (מוגן מאחורי "סורג ובריח"), היום הם משתמשים בשירות פומביים כמו Github או Gitlab. הדבר מאפשר להם להתמקד יותר בכתיבת הקוד ופחות בכל האופרציה הקשורה בניהולו, כאשר ספק השירות מבטיח זמינות גבוהה, גיבויים ועוד. גם שיתוף הקוד בין צוותי הפיתוח והרצת בדיקות האיכות נפתרו על-ידי נותן השירות "התוכנה כשירות". ועם כל-כך הרבה יתרונות – מה הם החסרונות?
מידע פרטי הופך ציבורי
העובדה שאותם שירותים הם פומביים ומחזיקים בקניין הרוחני של החברות מעמידה את קוד המקור, שטומן בתוכו מידע רגיש של החברה, בסיכון גדול. מעבר ללוגיקה ולאלגוריתמיקה שמהווים את הצד הטכני של הקוד (שגם פריצה אליו היא מסוכנת), קוד המקור מכיל לא פעם מידע פנימי של החברה, פרטי מידע סודיים כמו מפתחות הצפנה של הקוד לשירותים אחרים, סיסמאות לבסיסי נתונים, מפתחות API המאפשרים לקוד לתקשר עם שירותי תוכנה חיצוניים, ועוד.
למעשה, הפומביות של שירותים האלה משפיעה ישירות על רמת אבטחה ומגדילה את סיכויי הפריצה. אם כתוצאה מפריצה לספקית שירותי ה-SaaS גם הקוד יזלוג החוצה (כמו במקרה של CodeCov), ניתן להגיע דרכו לקוד של מגוון רחב של חברות שמשתמשות בשירות. מקרה נוסף יכול להיות תוצר של טעות גרמה לחשיפה פומבית של קוד פרטי סגור. אם הקוד נכתב באופן שבו הוא מכיל פרטי מידע רגישים מכל סוג שהוא, הפריצה הבאה ממתינה מעבר לפינה, כמו שראינו במקרה של הפריצה ל-Twitch.
האוטומציה גם מאפשרת להקטין את מרווח הזמן שמרגע כתיבת הקוד ועד הרגע שבו התוכנה עולה לסביבה חיה ומספקת שירות ללקוחות. מצד אחד, התהליך שמורכב משרשרת פעולות כמו בדיקת האיכות של הקוד, הרצת טסטים שונים, בדיקות בסביבות פנימיות ועוד, דורש תשתיות גמישות כדי שקבוצות שונות של מהנדסי תוכנה יוכלו לעבוד במקביל בלי שקוד של אחד ישפיע על אחר. כל אחד מהם יכול לרוץ בסביבה מבודדת משל עצמו, ולאחר מכן לבצע אינטגרציה לפני העלאת הגרסה החדשה של התוכנה.
האוטומציה ממוקדת במהירות – לא באבטחה
בעבר, איש התשתיות היה צריך להשקיע שעות וימים כדי לעשות זאת. ובכל פעם שיש דרישה חדשה – התהליך מתחיל מחדש. כיום מעניקות ספקיות הענן הפומביות את היכולת להשתמש ב-API בעזרת קוד (Infrastructure as Code), ולייצר בענן מגוון של שירותים ותשתיות באמצעות כמה שורות קוד. מכיוון שלכל ספקית ענן יש שפת API משלה, ויש חברות המשתמשות ביותר מספקית ענן אחת, נוצרו פתרונות הפשטה כמו Terraform או Pulumi, המאפשרים לכתוב בסטאק טכנולוגי אחד את פתרונות ה-API של ספקיות שונות. בכך הם מאיצים את התהליך ומצמצמים את מרווח הזמן לשעות ספורות, ואפילו דקות במקרים פשוטים.
אומנם פלטפורמות התשתיות כקוד הופכות תהליכים מורכבים לפשוטים יותר, אולם הן מייצרות סיכוני אבטחה חדשים. מה קורה אם פורסים לענן הפומבי בסיסי נתונים או שרתים, שבטעות בסיס הנתונים בהם הוגדר ללא גיבויים, או ללא הצפנה כברירת מחדל לנתונים שעוברים אליו וממנו, או עם הרשאות גבוהות מדי? מה קורה כאשר בסיס הנתונים צריך להיות נגיש רק לטווח כתובות רשת פנימיות של החברה, אך כעת הוא פתוח לעולם? זהו עוד מקרה שבו לאופן בניית הקוד יש השפעה על סיכויי הפריצה, שכן הקוד שמתאר את התשתיות יכול להכיל misconfiguration או לא לבטא את מאפייני האבטחה עבור אותן תשתיות קריטיות.
מתי הפירצה קוראת לגנב
בעקבות התפתחות הענן הפומבי, בשנים האחרונות הגיעה טכנולוגיה חדשה לעולם התשתיות בהשראתה של חברת גוגל: טכנולוגיית קוברנטיס (Kubernetes) מאפשרת להאיץ את תהליכי הפיתוח ופריסת התוכנה בענן ולספק הפשטה של תשתיות ושירותים מסוגים שונים במתכונת Cloud-Native. כלומר מאפשרת להריץ את התוכנה באופן שאינו נעול לתשתית של ספקית ענן ספציפית (vendor lock). כך ניתן לבטא את התוכנה בשפת קונפיגורציה אחת (yaml), ולהריץ אותה בכל אחת מספקיות הענן.
מכאן שכעת גם אנשי תוכנה שלא מגיעים מעולם התשתיות יכולים לבצע את הפריסה. אבל מה קורה אם הקוד שמכיל את הפריסה של התשתיות לא מכיל שום מאפייני הגנה על שרת השליטה הראשי של הקלאסטר של קוברנטיס, וברירת המחדל של אותו שרת קריטי בזמן הפריסה זה להיות פתוח פומבי לאינטרנט? במקרה הטוב התוצאה היא שכזה שרת מזמין Crypto Miners (כורי מטבעות קריפטוגרפיים), במקרה הרע הוא מזמין חשיפת מידע רגיש.
טכניקות לגילוי ומניעת חולשות אבטחה
כיצד ניתן להתמודד עם האתגר המסוכן הזה? סקירת קוד עם חברי הצוות (code review) היא פתרון אחד לכך, אבל היא לא חסינה בפני טעויות. לכן הטכנולוגיה נכנסה גם לתחום הזה באמצעות כלים אוטומטיים הסורקים את הקוד תוך כדי כתיבתו. למשל linters המוודאים שהקוד עומד בדרישות הרלוונטיות. חסרונם נעוץ בכך שהם בוחנים את הקוד מפרספקטיבה של בקרת איכות הקוד ולא של אבטחה. קיימים הבודקים שאין בקוד מידע רגיש או סודות למיניהם, וכוללים גם סריקה עמוקה של קוד ותשתיות, בין אם זה בשפות Terraform ,CloudFormation ,Kubernetes או השפות הנוספות. הכלים האלה מאפשרים לוודא שבקוד לא קיימות בעיות תצורה (misconfiguration) שיכולות לחשוף את הארגון לפריצה וגניבת מידע.
הסורקים מהסוג הזה מאפשרים גם לארגונים לעמוד בתקנים כמו CIS controls, PCI-DSS controls, ISO27001, SOC2 Type 2 ואחרים. זוהי רשימת בקרות המיישמות את מדיניות אבטחת המידע (policies) של כלל הנכסים הדיגיטליים שהארגון מייצר, כולל המידע שהוא שומר, בין אם שלו או בין אם של הלקוחות שלו. הארגון מתחייב להיות כפוף להן בשביל לעמוד בתקינה, ויש חלק שלם בבקרות אשר מגדיר את האבטחה של קוד המקור ונגזרותיו, שכן הוא אחד המקורות לפריצת סייבר.
סיכום
קוד פומבי יכול להוביל לפריצה ולדליפת מידע. גם המפתח המקצועי ביותר הוא, בסופו של דבר בן אנוש מועד לטעויות. ההסתמכות על הטכנולוגיה כדי להקל על חייהם של מפתחים יכולה להוביל גם לחדירות סייבר, ויש לעשות כל מה שאפשר כדי למנוע אפשרות לתקיפה כזו בכל דרך שהיא. בפעם הבאה כשאתם מוסיפים עוד תוסף טכנולוגי לעבודה שלכם – תחשבו מה היתרונות שלו בהקשרי אבטחה, ולא רק מהי כמות העבודה שהוא מקצר.
פורסם בקטגוריות: אבטחת סייבר , חדשות
פורסם בתגיות: Spectral , סייבר
כתבות נוספות העשויות לעניין אותך
