על אבטחת מידע ללקוחות – מצד הספקים

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

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

תקיפת שרת

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

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

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

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

פריצה לשרת

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

שיטה זו עדיין בשימוש היום על ידי סקריפטים שפורצים רבים מריצים. הסקריפט לוקח טווח כתובות מסויים ומנסה למצוא בפורטים מסויימים אפשרות לפרוץ, כך לדוגמא אחד הפורטים הפופולריים הוא פורט 22 שמשמש בשרתי יוניקס/לינוקס כחיבור לשרת (SSH). סקריפט כזה שמוצא את הפורט הזה, ינסה לעשות login דרך משתמשים כמו root, admin וכו' ועל כל משתמש הוא ינסה להריץ סידרה של סיסמאות ידועות כמו מספרים, מספרים ואותיות רציפות על מקלדת (1q2w3e4r) ועוד כל מיני סיסמאות. אם השרת נמצא עם סיסמא כזו, הסקריפט יצור יוזר נוסף עם הרשאות root וידווח בחזרה למפעיל הסקריפט שיש לו עוד שרת פתוח לשימושו. אותו דבר קורה עם פורטים כמו 25 (SMTP), ועוד פורטים.

קל מאוד למנוע את הפריצות האלו: כל מה שצריך הוא לשנות את פורט SSH מ-22 למספר אחר, לבטל אפשרות כניסת root ע"י סיסמא מרחוק (תמיד תוכלו להיכנס כ-root מהקונסולה), ואם אפשר, עדיף לבטל סיסמאות לגמרי ולהשתמש במפתחות, כך שאם אין למשתמש קובץ סיסמא, המערכת לא תבקש ממנו סיסמא אלא תסגור את החיבור. אפשר להוסיף דברים כמו אפליקציית LFD (או להשתמש בתוכנת חומת אש CSF) וכך התוכנה יודעת לספור את כמות החיבורים מאותו IP ולחסום אותו זמנית או בצורה קבועה.

אבל רוב הפריצות אינן פריצות פורטים, אלא פריצת אפליקציות.

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

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

אז מה ספק אחסון טוב צריך שיהיה וצריך לעשות? כמה דברים:

  1. הטמעת חומת אש רצינית עם חוקים קשיחים: סיסקו, צ'ק-פוינט, פורטינט, ג'וניפר – כולם מייצרים קופסאות חומות אש מספיק רציניות כדי להגן על משתמשים. ספק רציני יודע לקחת קופסא כזו ולהגדיר מי יכול להיכנס ברזולוציה של כתובת IP, איזה פורטים לפתוח עבור הלקוח ואיזה פורטים לסגור. ספק רציני גם יתקין ללקוח חומת אש פנימית עם חסימת פורטים פנימה והחוצה לפי הצורך.
  2. לא לאפשר לעובדים שלו להיכנס למערכות של הספק עם סיסמאות אלא עם מפתחות הצפנה בלבד וכל כניסה נרשמת ומתועדת.
  3. ספק טוב מפריד לחלוטין בין רשת השרתים של הלקוחות לרשת שלו עצמו. כך לדוגמא כל עניין ניהול הלקוחות, פרטי הלקוחות, סיסמאות וכו' צריכים לשבת ברשת נפרדת, עם גישה מאוד מפוקחת לסקריפט ששולף נתונים ועדיף שהנתונים יועברו בהצפנה. (אצלנו לדוגמא כל רישום הלקוחות נמצא בכלל בעיר אחרת אצל ספק אחר).
  4. אם מדובר בספק שסולק כרטיסי אשראי, אז הספק צריך להקים רשת פיזית אחרת (לא להסתפק במכונה וירטואלית וחיבור VLAN נפרד) ולהציג אישור שעבר PCI (שימו לב: ישנו סולק שלא אציין את שמו שמציג לוגו של PCI באתר שלו אך הוא לא עבר PCI ולכן חשוב לבקש לראות הוכחה שהספק עבר תקן PCI ושהתעודה מראה את השנה הקלנדרית הנוכחית (בדיקת תקינות ל-PCI צריך לעבור כל שנה).
  5. ספק טוב שומר בשרתי אחסון שיתופי שלו לפחות חודש רישומים של כניסות לשרת הן דרך WEB וגם SSH, רישומים אלו אמורים להישמר בגיבוי.
  6. עדכונים – כל השרתים (למעט VPS שאינם מנוהלים על ידי הספק) צריכים להיות אחת לשבוע מעודכנים בכל הטלאים האחרונים שיצאו לאותה הפצה.
  7. פאנלים – חובה שיהיו מעודכנים לגירסה האחרונה.

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

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

ועוד משהו אחד: בחשבון משותף עם גישת SSH אפשר לבדוק את חלק מהדברים. לדוגמא אם תקישו את הפקודה uname -a תוכלו לראות שגירסת הליבה (אם זו מערכת CentOS מעודכנת) היא 2.6.18-274 (לקוחות שלנו יראו 374, הוספנו כמה דברים לליבה). אם המספר פחות מ-274, זה אומר שהשרת אינו מעודכן, ובמקרים כאלו אתם חשופים לחורי אבטחה.

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

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

על אבטחת מידע ללקוחות בעלי אתרים

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

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

אז נתחיל לעשות סדר בבלאגן.

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

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

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

עוד מספר נקודות:

  1. ספק האחסון אינו יכול לעשות קסמים ולהפוך את כל הנתונים למוצפנים, זו אחריותו של המתכנת להצפין את הנתונים לפני ההכנסה/עריכת נתונים קיימים בין אם דרך שפת התכנות, ספריית תכנות או שימוש בפונקציות ששרת ה-SQL נותן (לדוגמא: encrypt ב-MySQL וכאן אפשר למצוא יותר מידע). האחריות של הספק היא לחסום כניסה לא מורשת ל-MySQL (לדוגמא) ברמה של כניסה מבחוץ ומניעת אפשרות למשתמש לראות את כל בסיסי הנתונים בתוך ה-DB עצמו (למעט מה ששייך לאותו חשבון). כמו כן הספק צריך לאסור באחסון משותף (לדוגמא) אפשרות להתחבר ל-SQL מבחוץ (גם כשבונה האתר מאוד אוהב כלי GUI חיצוניים ורוצה להתחבר ישירות לשרת איתם).
    ככלל, ספק צריך לברר עם הלקוח מה הוא מאחסן ולעדכן את החוזה בין הספק ללקוח לגבי אחריות על המידע, עניינים משפטיים וכו' (ואני ממליץ לקחת את שרותיו של עו"ד קלינגר לעניינים אלו, הוא מומחה בזה).
  2. בוני האתרים: מאחריותכם להסביר ללקוחות לגבי עניין האבטחת מידע ולבקש ממנו שימצא איש אבטחת מידע שישב איתכם ויבדוק את האתר וימליץ לכם מה לעשות מבחינת קוד, פרוצדורות וכו'. אם לקוח רוצה לחסוך או לשחק אותה "ראש קטן", אתם תהיו המטרה של רמו"ט על עבירת אי רישום מאגר מידע (ואני די בטוח שהם ימצאו עוד סעיפים להאשים אתכם), ואם מחר חס ושלום יפרצו לאותו אתר ויפיצו את המידע, הנפגעים יכולים לתבוע אותו תביעה אזרחית ותנחשו את מי הוא יגרור אל התביעה הזו..
    לכן אם לקוח מתעקש לא לקחת איש אבטחת מידע, ואתם לוקחים את הפרוייקט, תצטרכו להחתים את הלקוח על מסמך שהוא זה שמבקש אתר ללא אבטחת מידע כפי שנדרש בחוק והוא לוקח את כל האחריות עליו ופוטר אתכם מאחריות (לא יודע כמה מסמך כזה הוא לגטימי, עדיף להתייעץ עם עו"ד).
  3. לקוחות שיש להם אתרי חנויות או כל אתר שאוסף מידע מגולשים: בלי אבטחת מידע גם הרמו"ט יכולה לתבוע אתכם ואם נפרץ האתר שלכם – אלו שזלג המידע שלהם החוצה יכולים לתבוע אתכם תביעה אזרחית על אי-הגנה על מאגר מידע ושלל סעיפים נוספים, לכן מומלץ להשקיע את הסכומים הנוספים ברישום ובאבטחה על מנת להימנע מהכאב ראש הזה.

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

Exit mobile version