במהלך השנים הזדמן לי לשמש הן בתפקידי פיתוח והן בתפקידי ניהול הרשת ואבטחת מידע. עם השנים התברר לי יותר ויותר כי תוכניתנים בדרך כלל מתמקדים בפתרון הבעיות הלוגיות והתכנותיות הרלוונטיות למשימה המוטלת עליהם, ואולי טוב שכך. לתוכניתנים קיימות לא פעם בעיות מורכבות מאד אשר עליהם לפתור, בעיות אלו כוללות בין השאר בעיות יעילות, תקשורת ואלגוריתמיקה. החיסרון שבכך הוא שפעמים רבות משיקולי יעילות נוחות הפיתוח או ידידותיות למשתמש, מייצרים מתכנתים רבים חורי אבטחת מידע בתום לב.
אני סבור שהאחריות לאבטחת המידע של המוצר אותו מפתחים התוכניתנים צריכה להיות מוטלת על כתפיו של מאפיין המערכת או, במקרה שזה עשה את עבודתו נאמנה, על אנשי ה-QA. הרי, אם התוכנה לא הייתה ידידותית מספיק, הייתה מייצרת עומס בתקשורת וכדו' לא היינו פונים לתוכניתן שבסך-הכול פעל בהתאם לאפיון כתוב ומוגדר. עם זאת, עקב העובדה שאפיון מערכת מידע, מעצם טיבעו לא יכול להיות (ולא נדרש להיות) הרמטי ולהקיף את המוצר מכל זווית אפשרית ולכסות כל פרט קטן, משום כך, באופן טבעי צצות שאלות ותהיות במהלך שלב הפיתוח כאשר כל שאלה או תהיה כזו מייצגת למעשה צומת החלטות אשר במקרים רבים התוכניתן עצמו הוא זה שמספק את המענה לשאלות אלו על בסיס ניסיון העבר שלו. משום כך, חשבתי שנכון לנסח רשימה של נושאים שמטבעם מהווים או עלולים להוות סיכון אבטחת מידע ומכיוון שכך, רצוי שהתוכניתן שנתקל בשאלה, יציף אותה בפני מומחה אבטחת המידע או איש ה-System המעורב בפרויקט.
קישוריות: כאשר תוך כדי הפיתוח נתקלת בצורך לקשר את המערכת שלך למערכת אחרת או בצורך לקשר בין רכיבים שונים במערכת שלך או בין השכבות השונות שלה חשוב לערב מומחה אבטחת מידע ו/או איש System. זאת, על מנת לוודא שהאופן בו הנתונים מועברים לא מאפשר לגורם שאינו מורשה לצפות בנתונים או לשנות אותם. כמו כן, איש ה-System עשוי לבדוק את השפעתה של קישוריות באופן שתוכנן על מערכות אחרות הקיימות בארגון.
ניהול הזדהות (Authentication): כאשר מתוכנן אופן ההזדהות של מערכת כלשהי חשוב לערב מומחה אבטחת מידע ואיש System על מנת לוודא מדיניות מתאימה של חוזק סיסמאות, אופן שמירתן (במידה ורלוונטי). גם במידה ומחליטים להשתמש בשירות הזדהות קיים (למשל Active Directory) עדיין יש לשקול האם לדרוש משתמש וסיסמה פעם נוספת או שניתן לבצע כניסה שקופה (Integrated Windows Authentication), כמו גם להחליט האם מדיניות חוזק הסיסמאות הנהוגה באותו שירות הזדהות אכן מספקת את צרכי אבטחת המידע של המערכת. כמובן שיש להכריע האם מספיקה הזדהות באמצעות סיסמה (Something you know) או שנדרשת הזדהות חזקה יותר באמצעות כרטיסים חכמים למיניהם (Something you have) או שנדרשת הזדהות חזקה אף יותר באמצעות רכיב ביומטרי למשל (Something you are).
ניהול הרשאות (Authorization): זה באמת נשמע קצת ברור מאליו, אבל תתפלאו, במערכות מידע רבות קיים מנגנון בסיסי מאד לניהול הרשאות, אמנם, ברוב המכריע של המקרים מדובר במערכות מידע קטנטנות או באפליקציות שירות כלשהן, אך כדאי לזכור שגם מערכת קטנה יכולה להיות חור אבטחת מידע גדול. זאת במיוחד כאשר מדובר על אפליקציות אשר מסתמכות על הזדהות מול שירות ניהול זהויות כלשהו, למשל Active Directory. מספיק לדמיין מצב שבו תוכנת שירות קטנה וממש לא משמעותית אשר מאפשרת, כתוצאה מתכנון לקוי, חור אבטחה המאפשר את הרצתה של תוכנית כלשהי תחת הרשאות גבוהות יותר מאלו של המשתמש, בכדי להבין שכנראה בנושאים כגון אבטחת מידע אין כל כך מקום לכללי אצבע דוגמת פארטו.
רישום פעילויות (Auditing): לכאורה, נושא רישום הפעילויות המבוצעות הינו עניין עיסקי ולא אמור להצריך מעורבות של אבטחת מידע ו/או אנשי סיסטם אך האמת היא שנושא רישום הפעולות הוא למעשה, נושא של אבטחת מידע לעילא ולעילא, אחת הדרישות החשובות מבחינת אבטחת המידע מכל מערכת כוללת את היכולת הבסיסית לשמור נתונים רבים ככל האפשר לגבי מבצעי הפעולות השונות במערכת. הנתונים הנשמרים אמורים להיות כאלו שיאפשרו לזהות את המשתמש באופן שיהיה קשה למשתמש כזה להתכחש לפעילות שביצע (בפועל, המצב העדיף הוא שלמשתמש יהיה בלתי אפשרי להתחזות אלא שברוב המקרים זה לא ממש ניתן באופן הרמטי). בנוסף, אם ניהול רישום הפעילויות מבוצע באופן לא נכון, תיתכן פגיעה באבטחת המידע של המערכת, למשל במערכת הרושמת כל ניסיון כושל להיכנס אליה ואשר אינה מבצעת כל סירקולציה של לוגים על מנת שיהיה ניתן לנתח את הקבצים כל העת, מערכת זו תהיה חשופה לפגיעה משמעותית במקרה של ניסיון תקיפה בשיטת Brute Force שכן היא תתעד את כל מיליוני ניסיונות הכניסה הנוצרים בשיטת תקיפה זו. בנוסף, ניהול רישום פעילויות תקין אשר מכיל פרטים רבים ככל האפשר לגבי הגורם הפונה וסוג הפניה המבוצעת יחד עם ניהול רישום שגיאות נכון המכיל פרטים רבים ככל האפשר לגבי מהות השגיאה ומקורה עשויים להוות יתרון משמעותי בעת ניתוח של תקלה במערכת המידע או ניתוח של פריצה לאתר האינטרנט.
מנגנוני גיבוי/שחזור: על מנת לאפשר את שיחזורה התקין של מערכת, איש ה-System חייב להיות בקיא בפרטי המערכת והמודולים המרכיבים אותה. הדבר נכון שבעתיים כאשר מדובר על שילוב מערכת חדשה בארכיטקטורת גיבוי קיימת דוגמת Snapshots וכדו'. בארכיטקטורות המכתיבות גיבוי "חם" תוך כדי פעולת המערכת חשוב ביותר התכנון המשותף של המערכת החדשה על מנת שהגיבוי המבוצע יהיה ניתן לשחזור תקין.
ביצוע בדיקות: טרם ביצוע בדיקות למערכת החדשה ובפרט בדיקות תפקוד תחת עומס (Stress Tests) חשוב מאד ליידע את אנשי ה-System על מנת שאלו יוכלו לבדוק את השלכות העומס המופעל על מערכות אחרות החולקות משאבים עם המערכת החדשה. כמובן שאת בדיקות אבטחת המידע למערכת (Penetration Test) יש לבצע בשיתוף אנשי ה-System על מנת לבצע את הבדיקות המדויקות ביותר למערכת החדשה תוך הכללת נושאים הקשורים לתשתית עליה מוחזקת מערכת המידע.
במאמר זה התייחסתי לנושאים המחייבים עבודה צמודה יחד עם אנשי ה-System ואבטחת המידע, התייחסתי גם לנושאים הנראים לכאורה ברורים מאליהם משום שהניסיון מלמד שנושא הברור מאליו לאחד לא בהכרח ברור מאליו לאחר. ובמהלך העשור האחרון נתקלתי לא פעם במקרים של מפתחים שונים אשר לא תפסו את הנושאים המוצגים כאן כברורים מאליהם כלל.