לא מעט אני מגיע ללקוחות רבים, ודווקא לא מצד האבטחה, אלא בתור תכנת ויועץ לענייני תכנות, שהרי זו המומחיות היותר גדולה שלי. אבל מצד שני, אני גם מכיר את כל ההמלצות, איך כותבים שאילתות למסדי נתונים, איך מנהלים סשנים (session), איך מקבלים מידע, איך מחזירים מידע, חלוקה של משתמשים אפליקטיביים, איפה שומרים ססמאות, כיצד מגנים על קבצים, ומאוד ולפעמים הכי חשוב - הרשאות.
שימו ♥ - מה שנכתב פה הוא בקיצור נמרץ מאוד ולא מהווה כלל סמכות או המלצה לשמירה על המידע.
כאשר תכננו את האינטרנט, ואת הרשתות, תכננו אותם מסיבה מאוד ברורה - לשתף מידע. לכך הם נועדו, ולכן המשימה להגן על המידע היא נוגדת את עצם מהות האינטרנט והרשת, ויש לכך משמעות עמוקה.
אם לא נבין את זה, כל המאמצים שלנו להגן מהר יעלו בתוהו, וכל האקר מתמיד מהר ימצא את מבוקשו.
כאשר תכננו את האינטרנט, עשו חשבון שאני רוצה אולי לשתף קובץ מסויים רק עם הקולגות שלי, ולא עם אחרים, ולכן עשו פתרון מופלא בשם הרשאות. צר לי לאמר, אבל ברוב המקומות אין כלל ניהול הרשאות, אפילו כשיש יחידת אבטחת מידע מוכשרת.
כאשר תכננו את האינטרנט, עשו חשבון שאולי אני רוצה לקבל מידע ולהכניס אותו למחשב שלי, שרת או מסד נתונים (DB), ולכן עשו תהליכי הוצאת מידע ותהליכי הכנסת מידע, מתוך מטרה ששניהם ינוהלו בנפרד, אחד מתוך הנחה שכל מה שיש בו ממילא ציבורי, והשני מתוך הנחה שהוא צריך לעבור עין קפדנית. לצערי הרב הנושא בערבוביא לא פעם, ופתאום צריך "להקל" ע"מ לאפשר הוצאה נורמאלית של מידע ע"ח ההכנסה.
עד כדי כך שיש יועצים שעסוקים בכיצד להגן על המידע הציבורי, הכתבות, התכנים, או שמות היוזרים ליצירת קשר. אבל אומר אני, ברגע שפתחת אתר, המטרה שלך היא לשתף את המידע הזה. הגנה על מידע לא ציבורי יש לה פן אחר במהותה.
כאשר תכננו הרשאות, התכוונו ליוזרים פשוטים (ariel) וססמאות מורכבות (luke1amURfather), והיום, מחמת ריבוי המשתמשים, יש לנו יוזרים מורכבים ונשכחים (ariel.rubi.team1@domainB.second.bz) והססמאות, מחמת ריבוי היוזרים, פשוטות (123456).
ואז לפתע מתחילים צוות אבטחת מידע להקשות קשיים שלא ראום אבותינו, WAF-ים וFIREWALLS עם חוקים דרקוניים שלא מאפשרים עבודה נכונה, וממילא זה עצמו מייצר חורי אבטחה.
דוגמא ראשונה תהיה הגדרה שמידע שעובר ע"י בקשות מסוג GET (שליפת מידע) לא אמור להיות מוגן, וכן שמות יוזרים (מוכרים, אלו שאמורים לקבל מיילים לדוגמא), גם לא אמור להיות מוגן.
המתכנתים מצד שני, אמורים להבין בצורה מאוד ברורה, ולדרוש הגדרות ברורות לכך, מהו המידע הציבורי, שאפשר לחלוק אותו ללא הגנה, ומה היא קבוצת היוזרים הציבורית, ובזה לעשות חתך ברור ותהליכים שונים לחלוטין.
מאידך, יש לתאם עם אבטחת מידע, מהו הכלי הטוב והמוכר להם לפיקוח על מידע נכנס, היינו בקשות מסוג POST, ושם לעשות החלטה משותפת ומושכלת במה משתמשים, אולי FORMS? אולי JSON? אבטחת כ"א מאלו או אחרים היא שונה במהותה, וההתקפות שונות.
וחשוב מכך, על התכנתים לדווא את הקלטים, ולא לסמוך על המערכות הנ"ל להגנה. ע"פ רוב רוב הקלטים מאוד ברורים, מספרים, טלפונים, שמות, וכד', וממילא קל מאוד ליצור כמה פונקציות גנריות שידעו טוב מאוד לבדוק כ"א מהם מכל פינה שלא תהיה בקוד, וללא מאמץ.
ישנן ספריות בשפע שבפונקציה אחת ינקו את כל הקלטים לפי כל דרישה, לא צריך להבין סייבר, ולא צריך לדעת REGEX, רק להשתמש.
גם, לדוגמא, בגישה למסדי נתונים להשתמש רק ב parameterized query שזוהי שאילתא שמתקמפלת לפני הכנסת הפרמטרים, ולכן בלתי אפשרי לפרוץ אותה, ובתיאוריה, אפשר פשוט להראות אותה להאקר, אין לו מה לעשות איתה.
קצת יותר מורכב ודורש לימוד הוא ניהול נכון של SESSIONS ותהליכי LOGIN, אך להכל יש את ההמלצות כיצד עושים תהליכים נכונים ומבקרים אותם, ומי שרוצה "אזור אישי" צריך להבין שהוא לא משלם רק על התכנות, הוא חייב לשלם גם עבור בקרה.
יותר ממחצית הבאגים בעולמות הWEB הוא דבר בשם XSS, שזה אומר שאני יכול לשלוח לך את הדף שלך לחבר, אבל עם קצת פרמטרים לא נכונים הוא יראה תכנים שאני רוצה, נאותים או לא, ואפילו לאפשר פעילות זדונית. גם לזה יש פתרון מאוד פשוט, כל קלט בדף, שם משתמש, ססמא, כתובת להעברה (לדף הבא), הכל עושים לו תהליך שנקרא sanitize (היום יש ספריות שזה כאמור פונקציה אחת) והופ! נעלמה לה הבעיה.
ואולי לפני הכל, מה שבכל מוסד יש טעויות לרוב, הרשאות וססמאות.
כולנו אוהבים את השיטה המוכרת מהמחשב הביתי, יוזר אחד שיכול הכל. זה נחמד לבית, זה אסון לעסק, אפילו קטן. היוזר האדמיני הכל יכול למעשה אמור להעלות אבק מחוסר שימוש, פרט לעדכונים, והפעם הראשונה שהרימו את השרת. ואולי ליצירת יוזרים אדמיניים לתחומם.
הצד השני הוא לתת שפע הרשאות למי שנדרש לכך, לדוגמא (העיקרית) התכנת.
אבל גם הצד השלישי הוא שהיוזר של התכנת, וסביבת העבודה שלו, לא אמורים לעולם להיות חשופים לאינטרנט.
וכן לכל תהליך צריך שהיה יוזר משלו, עם הרשאות ממוקדות, וגם במסד הנתונים חשוב לכבות את ריבוי ההרשאות שהמסד מקבל באופן דיפולטיבי, שהרי אלו נועדו למסד פנימי ולא מסד חשוף לרשת, וכן כל יוזר שפעיל בו שיקבל הרשאות מותאמות לתהליך שלו.
וססמאות. ססמאות. ססמאות. עם כל הקושי לזכור ססמא מורכבת, הקושי הוא רק לשבוע הראשון. ישנם קבצים מפוזרים באינטרנט מלאים בססמאות ידועות, הייתי אומר כאן המקום להחמיר, חבריי לאבטחת מידע, להוריד את הקבצים הללו ולא לאפשר ססמאות שכאלו בשום צורה. למען שיתוף הפעולה, קחו דקה ותראו להם את הסיסמא שהם בחרו בגוגל, או כמה מהר היא נפרצת עם john the ripper.
לעיתים עדיף ססמא ארוכה מורכבת אשר נשמרת ברמז בספר טלפונים או אפילו בפירוש באפליקציית פתקים (NOTES) מוגנת בפלאפון, ועכ"פ לא לתת מתנת חינם לפורצים.
אף ארגון לא אוהב עדכונים, ואף צוות בארגון לא אוהב אותם. גם לא אבטחת מידע. זה בגלל שאנחנו בני אדם ושינויים מאוד מציקים לנו, ומשנים לנו הרגלים. נכון. אבל אין ברירה. מן הראוי לעשות עדכון אבטחת מידע לפחות פעם בשבוע, ובכל שרת שפונה ישירות לאינטרנט או לרשת פתוחה - כל יום. כן, כל יום. כן, זה אומר שעה קבועה ביום השרת לא פעיל. אם העסק מספיק גדול אזי לשים 2 שרתים ולעדכן לסירוגין. כי הפורצים קוראים מדי יום את הפרצות החדשות ומיישמים אותם תוך שעות ספורות, והרי לכם דלת פתוחה, אחרי כל פתרונות הסייבר היקרים.
ניתן עוד להרחיב ולהביא דוגמאות לרוב, ובחרתי בדברים הפופולריים והמצויים יותר, אך אני חוזר לכותרת, בעבודה נכונה, מול ההמלצות עבור כל תהליך ומערכת, הרי שאני אהיה יהיר מספיק לאמר שבעסק קטן כבר סגרנו את כל בעיות אבטחת המידע. בעסק בינוני כבר יהיה ראוי ניטור הולם, ובעסק גדול אך ורק ניטור של בינה מלאכותית, שיודע ללמוד את התעבורה, שהרי היא מתשנית כל הזמן עם כל דף חדש, והניטורים הישנים לעיתים רבות מכבידים ואדרבא מאפשרים חורים.
אבל העיקר - עבודה נכונה, שהרי אף אם יפרצו לי את השרת, אין גישה למסד נתונים. ואם יש אז רק לתהליך הזה. ואם להתהליך הזה אזי ללא אפשרות לקוד זדוני. וכן הלאה.