הגנה על WEB SERVICES

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

בגדול (אבל לא כולם עושים את זה) באבטחת WS צריך לדאוג ל-3 דברים:

  • הזדהות (חזקה)
  • תווך העברת נתונים (מוצפן - SSL)
  • חתימה על המסר
ואני מוסיף גם את הסגמנטציה - כלומר פתיחת חוקים מתאימים ב-FW שרק הגורמים הרלוונטיים יגיעו לשרת הנכון.

לגבי תווך הצפנה - הכל ברור גם כך, זה חייב להיות מוצפן.

בהזדהות אני ממליץ להשתמש ב-CLIENT CERTIFICATE או במילים אחרות בסרטיפיקט X.509. סרטיפיקט זה צריך להיות מונפק ע"י ה-CA הארגוני ולכלול מידע על הזהות שמזדהה לקבלת שירות. הבעיה בפתרון זה שלא כולם יודעים לעשות את זה כמו שצריך. ומה זה כמו שצריך? - זה כמובן בדיקת סרטיפיקט שהוא חתום ע"י ה-CA המתאים (בד"כ מתבצעת ע"י התשתית), אך בנוסף לזה זה גם בדיקת פרמטרים של הסרטיפיקט כגון CN. למה צריך את זה ? מכוון שבארגון מנפיקים די הרבה סרטיפיקטים, ויש סיכוי (במידה ובדיקת CN לא מתבצעת), שהתוקף יכול להשיג סרטיפיקט אחר של הארגון (כמובן מאותו סוג X.509) ולהשתמש בו להזדהות לשירותים אליהם מזדהים עם הסרטיפיקט הנכון. 
לכן חשוב מאוד לבצע את הבדיקה של -CN ואולי של השדות האחרים של הסרטיפיקט.

להלן הדוגמה איך בודקים את ה-CN ב-TOMCAT:

In <tomcat home>/conf/tomcat-users.xml


<role rolename="securerole"/>
<user username="CN=client1, OU=myDev, O=myOrg" password="null"  roles="securerole"/>

בדוגמה רואים את שם של הסרטיפיקט - כלומר את כל השדות שלו עם פסיק ורווח.


אבל כמו שאמרתי הרבה מסתבכים עם זה, ורוצים לרדת מ-X.509. 

ואז עושים הזדהות רגילה עם שם משתמש וסיסמא, אשר שמורים איפשהו בקובץ קונפיגורציה ב-PLAIN TEXT. יש כאלה שלא עושים גם את זה ואז התוקף יכול בקלות להשתמש בשירותים אילו. 

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

במידה וארגון מחליט לא להשתמש בסרטיפיקט לצורך הזדהות, אני ממליץ לממש את הפרוטוקול OAUTH2 או להוסיף מנגנון OTP קטן בנוסף לשם משתמש וסיסמא.








פוסטים פופולריים מהבלוג הזה

הגנה על Web services 2

בחלק הראשון סיפרתי על הזדהות בהגנה על ה WS. עכשיו אני רוצה לספר קצת על אבטחה בארכיטקטורה של ה WS. אז על מה כדאי לשים לב בארכיטקטורה של WS ? באחד הסקרים שעשיתי מזמן, גיליתי שה-WS עוברים מהאיזור של DMZ אל האיזור של שרתים פנימיים דרך ה FW אך ללא שום הגנה נוספת. כלומר הסיכון כאן שהתוקף במידה ופורץ לאחזור ה-DMZ יוכל בקלות להפעיל WS ב-ESB. אני המלצתי כמקובל לשים XML FW בין הסביבות (ולפעמים מקובל לשים 2), אך בגלל יוקר המוצר (DATAPOWER), לא רצו לשים כלום. ומכוון שאני בעבר בא מתחום הפתוח, איפיינתי אפליקציה שתעשה הגנה בסיסית על ה-WS במעבר בין האיזורים. באפליקציה זו דרשתי את הדברים הבאים: * בדיקת גודל ה-Request * בדיקת Schema Validation * בדיקת RegEx על השדות * הזדהות עם X.509 בין כל ה-WS * שבירת פרוטוקול ל-MQ וחזרה * בדיקת Response על RegEx * בדיקת גודל ה-Response כמובן היו עוד כמה דרישות על log, מיסוך וכו. והאפליקציה עשתה את שלה - נתנה הגנה מינימלית בין הסביבות. זה כמובן לא DP, אבל גם משהו. מכוון שהמוצר לא כלל חתימות התקפתיות, דרשתי גם להעביר את הפניה דרך WAF הפנימי. בצור...
המשך לקרוא

מה נכנס לארגון שלכם ?

תמונה
בהרבה ארגונים קיימת גישה לאינטרנט מהמחשבים קצה ולפעמים גם מהשרתים. ולא כולם לצערי שמים את כל השכבות ההגנה הנדרשות בשביל להגן אל הנכסים הדיגיטליים של הארגון. גישה לאינטרנט לא מבוקרת עלולה לתת לתוקפים אפשרות להוריד קבצים מזיקים לתחנה. זה יכול להתבצע גם בפישינג בדוא"ל, וגם דרך אתרים מתחזים. כדי להתגונן מחדירה למחשבים, חשוב מאוד להשקיע במניעת שלבים ראשונים של שרשרת תקיפה, במקרה זה מדובר ב-Delivery. לכן חשוב לשים את השכבות ההגנה הרלוונטיים. על אילו שכבות אני מדבר ? כמובן זה תלוי בסוג הארגון. למשאל בבנקים הגלישה באינטרנט מתבצעת דרך חוצץ כמו Citrix דרכו (במידה ומטוייב כמו שצריך) ניתן לראות את התוכן של הגלישה אך לא ניתן להעתיקו ולא ניתן להוריד קבצים לתחנה. הגנה זו עם קיום WebProxy הכולל מנועי אנטיווירוס והלבנה בהחלט מבדילים גישה בין רשתות פנימיות ורשת האינטרנט. בארגונים אחרים שלא נדרשים לגישה לאינטרנט מבודדת על ידי הרגולציה, המצבים יכולים להיות שונים. בחלק מהמקומות אני אפילו לא רואה שיש WebProxy, אשר צריך לפחות לחסום את קבצי הרצה להורדה, ולבצע בדיקות אנטיווירוס לקבצים שיורדים לתחנות. כחלק...
המשך לקרוא