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

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

הבה נבחן לעומק את הבעייתיות שבאימוץ קו מחשבה שכזה:

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

2. רמת אבטחת המידע של מערכת מסוימת מוגדרת כרמת אבטחת המידע של הנקודה החלשה ביותר בה מבחינת אבטחת המידע. משום כך, רמת אבטחת המידע של המערכת בפירוש תלויה וקשורה קשר אמיץ לאופן בו מוטמעת המערכת או האתר, לרכיבים המוטמעים מסביבו, למדיניות ולנהלי העבודה של מנהלי המערכת ומשתמשי המערכות המשיקות לה. לצורך הדוגמה, בחרתי לציין בפניכם מקרה אמיתי בו נתקלתי בעבר: בית תוכנה כלשהו המספק לארגון בו עבדתי מערכת מידע כלשהי, המערכת הינה מערכת תפעולית מבוססת MS-Access עם מסד נתונים מבוסס MS-SQL. בנקודת זמן מסוימת הציע אותו בית תוכנה לארגון לרכוש מודול למערכת המידע המאפשר חשיפת נתונים ללקוחות דרך רשת האינטרנט. היות והיה מדובר במודול חדש אך כזה שהוטמע אצל לקוחות אחרים והיות והיה מדובר במערכת קיימת, הארגון לא ראה לנכון לנתח טרם הרכישה את האופן בו אמור להיות מוטמע אותו מודול ואת האופן בו הוא אמור לתקשר עם המערכת המרכזית ועם מערכות אחרות, זאת במיוחד לאור היתרון השיווקי המגולם במהלך זה. לכן, כחלק מצוות ה-IT קיבלנו דרישה של המנהלים להתקין את האתר, בבדיקה ראשונית שלנו התברר שהאתר של המערכת הזו מבוסס על מסד נתונים המותקן בשרת המארח את האתר כאשר אחת ללילה אמור לרוץ תהליך אוטומטי להעברת כל מסד הנתונים באופן לא מוצפן מהמערכת התפעולית לשרת המארח את האתר. היינו מופתעים ביותר מכך שאתר שבנוי באופן כזה יכול לעבור בדיקות אבטחת מידע ע"י אחת מחברות אבטחת המידע המובילות בארץ, לאחר בדיקה מעמיקה יותר התברר שאכן האתר בתצורה הזו קיבל את אישורם של חברת אבטחת המידע בארכיטקטורה שבה שרת האתר מאוחסן באותה חוות מחשבים יחד עם שרתי המערכת התפעולית ב-DMZ נפרד כאשר באותו ארגון בו עבדתי שרת האתר היה מאוחסן אצל ספק האינטרנט כך שהעברת נתונים באופן כזה הייתה חושפת אותם בפני כל משתמש באינטרנט שיש לו Sniffer ומספיק מוטיבציה…

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

השאר תגובה