מוזרויות במערכות מידע

מוזרויות במערכות מידע

Print Friendly, PDF & Email

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

  • כל הכבוד לצה"ל – כשהייתי חייל בשירות סדיר, השתמשנו במערכת מידע מיוחדת, מבוססת שרתי Tandem אשר עבדה על "תחנות עבודה" ישנות עם אמולציית DOS וותיקה. המערכת הזו השתמשה במקשים שכבר היום נעלמו מזמן מהמקלדת (למשל F16, לא המטוס, המקש) ועבדה באופן מסורבל במיוחד. במהלך השירות הצבאי הגשתי הצעת ייעול להקים ממשק משתמש חדש למערכת זו שיהפוך את המערכת לידידותית יותר וכמובן גם אפשרית לעבודה בסביבת Windows עםמקלדות חדשות. עברו שנים והגעתי לשירות מילואים, כשהגעתי הבנתי שכל התחנות שודרגו וכעת הן מריצות Windows 2000, תהיתי כיצד התמודדו עם המערכת הישנה הזו, ואז התברר לי שהם מריצים אמולציה זהה שעובדת בדיוק אותו הדבר אך היא מתאימה ל-Windows ועל מנת להתמודד עם בעיית המקלדת, משתמשים ב-Alt על מנת להגדיל את הטווח (למשל, אם זכור לי נכון Alt+F12=F16). זו לדעתי דוגמא מצויינת להתחמקות מבעיה ללא יישום פתרון אמיתי.
  • זו השאילתא, מה הפינה – באחד הארגונים בהם עבדתי, קיימת מערכת וותיקה, מבוססת Linux, אשר קיימות לה תתי מערכות שונות המתקשרות איתה, מסיבות שעד היום לא ברורות לי דיין (אולי חלקן פוליטיות ואינן טכנולוגיות כלל) מפתחי המערכות הללו פיתחו פרוטוקול תקשורת ייחודי המיועד לתקשורת מול מערכת זו בלבד. חשוב להדגיש שלא מדובר בהגדרה של Port שונה בלבד אלא ממש מדובר בפרוטוקול שלם שאינו מתבסס על משהו קיים אלא המצאה אמיתית, פרוטוקול זה מעביר שאילתות ממערכות שונות אל המערכת הנ"ל. במקרה אחר, בו נדרשה המערכת לספק קובץ XML פותח על ידי מפתחי המערכות הללו XML Parser משלהם על מנת ליצור את ה-XML הדרוש. אלו דוגמאות חשובות בעיניי לחשיבות של היצמדות לתקנים מוכרים גם במחיר של שימוש בקוד סגור שייתכן שקיים בו באג וגם במחיר של קוד שייתכן שהוא מעט פחות יעיל על מנת שיהיה ניתן לאתר בעיות אבטחת מידע במערכת בקלות יחסית, בנוסף, אם מדובר בפרוטוקול סטנדרטי ייתכן בהחלט שכבר קיימים מנגנוני סינון לזיהוי וחסימת פרצות בקלות רבה יחסית. כמו כן, במרבית המקרים, לא קיימים בידך משאבים מספיקים על מנת לאתר פרצות בפרוטוקול שפיתחת.
  • הגודל כן קובע (Scalability) – באחד הארגונים בהם עבדתי, מערכת אחת התבססה על גישה בפרוטוקול Telnet לצורך גישה לשרת, מעבר לעובדה שהמפתחים של המערכת בנו לקוח Telnet מלא מותאם אישית לצרכיהם (בעוד שקיימים כאלו מוכנים), גם הוקמו יותר מעשרה (!) שרתים שכאלו אשר אליהם היו המשתמשים מתחברים ומבצעים את פעולותיהם ואותם שרתים היו פונים לשרת מסד נתונים משותף. כמובן שברבות השנים הוקם על ידם מנגנון פיזור לקוחות הדואג להפנות תחנות לשרת Telnet פנוי. זו בעיני דוגמא לבעיית Scalability (תמיכה בגידול עתידי), פתרונות טובים יותר יכולים להתבסס על ארכיטקטורה שאינה דורשת חיבור קבוע (כדוגמת HTTP) ובמדת הצורך להשתמש במנגנוני פיזור מוכנים, חלק ממנגנונים אלו מייצרים כתובת וירטואלית אשר בעת הפנייה אליה מופנים לכתובת של שרת אחר בכל פעם ומאפשרים סינכרון State בין שרתי HTTP.
  • עזרה, למי זה עוזר? – כשנברתי בתפריטי הטלפון הנייד שלי מצאתי אופציה בשם "שליחת הודעות אוטומטית", חשבתי לעצמי: "זה מעניין, למי הוא שולח, מתי הוא שולח, בוא נבדוק בעזרה…" כשבדקתי, גיליתי שם את הטקסט המהמם הבא: "מאפשר הפעלה או הפסקה של משלוח הודעות אוטומטית"… היות והתופעה הזו קיימת גם במערכות מידע רבות שנתקלתי בהן חשבתי שראוי להמליץ, או יותר נכון, להזכיר לתוכניתנים – העזרה לא מיועדת למי שכבר מכיר את התוכנית, עד כמה שזה ישמע ברור מאיליו – העזרה היא עבור אלו שלא מכירים את המערכת…. (-;

השאר תגובה