סיכונים לא קלאסיים בפיתוח Services

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

כבר ציינתי כאן בעבר ששירותים מאפשרים למערכת A לשלוף מידע ולבצע עדכונים במערכת B ואת הבעיות הנובעות מכך. בגישה העתיקה, היו מפתחים במערכת B פונקציה שמעבירה את הנתונים למערכת A. בגישת SOA, ישנו מתווך שניגש למערכת A, שולף את הנתונים, ומעביר אותם למערכת אחרת (במקרה שלנו מערכת B). החוזק של SOA הוא שניתן לעשות שימוש בשירות גם עבור מערכת C ללא צורך בפיתוח נוסף.

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

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

אין כאן שום ניצול של פרצת אבטחת מידע ע"י תוקף. לא הזנחה של הסיסטם בהסרת דפים מיותרים משרת IIS. גם לא שכחו להגדיר חוקים מגבילים ב – Firewall, רק פורט 80 פתוח.
יש כאן בעיה שלא נותנים לה היום את הדעת. אז מה ניתן לעשות?

אני נוהג לבחון מסמכי אפיון לפני תחילת פיתוח. אני בוחן בין השאר:

• איזה מידע רוצים להציג למשתמשים? לפעמים אני משכנע את הביזנס לא להציג כמה שדות רגישים.
• איזה מידע שולפים מטבלאות?
• לאיזה בסיסי נתונים ניגשים (בעיקר מאפליקציות החשופות לאינטרנט)?
• כיוון שיש לנו שירותים רחבים כמתואר למעלה, אני מנסה לשכנע את המפתחים לכתוב שירות מצומצם יותר ובטח לא לשלוף מהשירות שדות רגישים. כך, אולי התוכניתנים ייחשפו למידע הרגיש הנשלף ע"י השירות ממערכת A, אך המידע עצמו לא יישמר במערכת המפותחת (מערכת B) וכמובן לא יוצג בה.

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