הגנה על 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 קטן בנוסף לשם משתמש וסיסמא.








תגובות

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

גישה פיסית - game over

תרגיל סייבר