4 גישות לאבטחת יישומי האינטרנט של הארגון שלכם

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

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

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

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

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

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

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

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

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

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

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

גישת ה- Bug Bounty Program – במסגרתה מציעות חברות התוכנה, ארגונים ובעלי עסקים, תמריצים כספיים למוצאי באגים, פרצות אבטחה ופגיעויות בשירותים אותם הם מציעים, בתמורה לתשלום.

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

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

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

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

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

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