חברת MongoDB מזהירה כי המערכות הארגוניות שלה נפרצו וכי נתוני לקוחות נחשפו במתקפת סייבר שזוהתה על ידי החברה בתחילת השבוע.באימיילים שנשלחו ללקוחות MongoDB מ-CISO Lena Smart, החברה אומרת שהם זיהו שהמערכות שלהם נפרצו ביום רביעי בערב (13 בדצמבר) והחלו בחקירת האירוע.
לחץ כאן לצפיה דרך טוויטר
אימייל שקיבלתי מהחברה בשעה האחרונה:
גירסת הדפסה
סגן המנהל
מפקח
עיתונאי מקוון
צל"ש
חבר מתאריך 27.8.19
18806 הודעות
בתגובה להודעה מספר 0
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 2.4.12
3406 הודעות, 15 מדרגים, 22 נקודות. ראה משוב
בתגובה להודעה מספר 1
בכל מקרה, ממליצים לעבור לאבטחה דו-שלבית בחשבון ולהחליף סיסמאות
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 27.8.19
18806 הודעות
בתגובה להודעה מספר 3
מה זה עוזר?
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 2.4.12
3406 הודעות, 15 מדרגים, 22 נקודות. ראה משוב
בתגובה להודעה מספר 4
הם בודקים את המקרה ומנגד טוענים שנחשפו פרטי לקוחות ללא פירוט מיוחד.
מבקשים לשים לב לאפשרויות של מקרי פישינג (דיוג)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 27.8.19
18806 הודעות
בתגובה להודעה מספר 5
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 10.10.07
4192 הודעות, 36 מדרגים, 72 נקודות. ראה משוב
בתגובה להודעה מספר 1
רק הצטרפו השבוע לS&P
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 5.11.20
11765 הודעות, 40 מדרגים, 15 נקודות. ראה משוב
בתגובה להודעה מספר 6
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 28.11.21
3020 הודעות
בתגובה להודעה מספר 0
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 25.3.16
8054 הודעות, 41 מדרגים, 48 נקודות. ראה משוב
בתגובה להודעה מספר 2
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 2.9.07
119280 הודעות, 393 מדרגים, 616 נקודות. ראה משוב
בתגובה להודעה מספר 0
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 5.2.13
18050 הודעות, 204 מדרגים, 401 נקודות. ראה משוב
בתגובה להודעה מספר 9
החל מסוף שנות ה-70 ועד לפני 12-13 שנה, רוב בסיסי הנתונים, וכל המובילים שבהם, היו רילאציוניים והשתמשו בשפת SQL.
משמעות הדבר היא שהם התבססו על טבלאות מקושרות, שהוגדרו ע״י סכמות, ובעזרת שפת SQL ניתן היה לבצע כמעט כל פעולת חיתוך, שליפה, שינוי המוני, וכו׳, כיד הדמיון הטובה.
השימוש בשפה אחידה גם איפשר למתכנתי ומפעילי בסיסי נתונים לגשת לבסיסי נתונים באותה שפה שלמדו פעם אחת, ואף להמיר בסיסי נתונים מספק אחד לספק אחר.
העובדה שהטכנולוגיה הזאת התיישנה, לא הפריעה כל כך, כי במהלך השנים בוצע המון מחקר, ופותחו אופטימיזציות ששיפרו עוד ועוד את ביצועי בסיסי הנתונים האלה.
גם כיום, כל ארבעת בסיסי הנתונים הנפוצים בעולם הינם כאלה:
אורקל, MySQL, SQL-Server, ופוסטגרס.
בשלב מסויים החל עוררין על הדומיננטיות של בסיסי הנתונים מהסוג הזה, כשהרעיון היה ששימוש במבנים פשוטים יותר, בלי סכמות, בלי SQL, יאפשר למתכנתים ולמפעילים יותר גמישות, ואף ביצועים מהירים יותר במשימות מסויימות (על חשבון ביצועים במשימות אחרות).
בסיסי נתונים אלו נקראו NoSQL, ורובם (כולל MongoDB) התבססו על הרעיון של היררכיה של מבנים (אובייקטים) שבכל אחד מהם יש סדרה של key-value.
השפה שאומצה לצורך כך היתה JSON (במקרה של MongoDB וחלק מבסיסי הנתונים האחרים), מה שאיפשר שילוב מעולה עם שפת JavaScript, שלמרות תפוצתה בצד הדפדפן, באותם ימים עשתה את צעדיה הראשונים בצד השרת, באמצעות סביבת NodeJS.
עם פריחתה של JavaScript מאז, הלכו ופרחו גם בסיסי הנתונים מסוג NoSQL, ובראשם MongoDB, וכיום הוא הראשון בתפוצתו מביניהם, והחמישי בתפוצתו מתוך כלל בסיסי הנתונים (לאחר הארבעה שהזכרתי קודם).
כמו MySQL ופוסטגרס, כך גם MongoDB הינו מוצר קוד פתוח, ולכן אני מניח שלחברה שמאחוריו יש גם מודל עסקי, אחרת היא לא היתה שווה כ-30 מיליארד דולר, אך NoSQL ממש איננו התחום שלי, ולכן אין לי מושג מה המודל העסקי הנ״ל.
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 2.9.07
119280 הודעות, 393 מדרגים, 616 נקודות. ראה משוב
בתגובה להודעה מספר 10
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 8.11.16
8757 הודעות, 63 מדרגים, 96 נקודות. ראה משוב
בתגובה להודעה מספר 10
אני מניח שזה מה שנפרץ
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 5.2.13
18050 הודעות, 204 מדרגים, 401 נקודות. ראה משוב
בתגובה להודעה מספר 12
אז אני מניח שהמודל העסקי שלהם מבוסס על מקורות הכנסה נוספים.
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 25.9.23
23 הודעות
בתגובה להודעה מספר 15
ברגע שאתה מתחיל לגדול ויש לך מספר גדול של פעולות / משתמשים (כל כתיבה / קריאה / מחיקה / שינוי תוכן בבסיס הנתונים נחשבת כפעולה בודדת)
החבילה מתחילה לעלות כסף.
בעולם שכולו מבוסס על בסיסי נתונים שחלקם משרת עשרות מיליוני אנשים באופן יום-יומי, רווחי החברה עצומים והצפי הוא שרק יגדלו עם הזמן.
מונגו פשוט וקל ללמידה יחסית, מתממשק עם השפות הכי נפוצות ויש לו קהילת תמיכה גדולה
מניח שגוגל עם המקבילה שלו (FireBase) ירוויח משתמשים חדשים בגלל התקלה.
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 5.2.13
18050 הודעות
בתגובה להודעה מספר 19
שים לב גם ל-Supabase, שדומה לפיירבייס מבחינות רבות, אך הוא קוד פתוח ומאפשר לך להריץ אותו בחינם On-Premise.
ובמקביל מתפתחות אלטרנטיבות נוספות לפיירבייס.
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 2.4.12
76656 הודעות
בתגובה להודעה מספר 10
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 13.11.14
6442 הודעות, 146 מדרגים, 286 נקודות. ראה משוב
בתגובה להודעה מספר 10
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 7.7.14
15434 הודעות
בתגובה להודעה מספר 10
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 14.7.11
45794 הודעות, 148 מדרגים, 230 נקודות. ראה משוב
בתגובה להודעה מספר 9
בסיסי נתונים רלאציונים פועלים על בסיס טבלאות מקושרות, בעיקר על מנת למנוע כפילויות מידע ושיפור ביצועים של חיתוכים שונים.
לדוגמא, נניח שיש טבלה של לקוחות: שם פרטי, שם משפחה, עיר מגורים, בבסיס נתונים רלציוני יהיו לך בעצם 2 טבלאות, טבלת לקוחות וטבלת ערים:
טבלת לקוחות: שם פרטי, שם משפחה, קוד עיר
טבלת ערים: קוד עיר, שם עיר.
לדוגמא:
טבלת לקוחות
פלוני אלמוני 4
שלמה ישראלי 3
טבלת ערים
4 תל אביב
3 פתח תקווה
הצירוף של שתי הטבלאות יתן לך:
פלוני אלמוני תל אביב
שלמה ישראלי פתח תקווה
למה זה טוב?
כי אתה חוסך שלא מעט מקום (שומר עבור לקוח רק מספר שהוא קטן בהרבה ממחרוזת וגם קל יותר לאינדוקס), שומר על אחידות (לקוח אחד ירשום תל-אביב, השני תלאביב והשלישי ת״א, ולך עכשיו תסיק שכלם מתל אביב)והתשובה לשאלה ״כמה לקוחות יש לי בתל אביב״ קלה יותר ומהירה יותר.
למה זה לא טוב?
כי אתה צריך לבצע 2 קריאות (אם נזניח לרגע אינדקסים) בכדי לקבל את פרטי הלקוח במקום קריאה אחת, עכשיו תחשוב על טבלאות מסובכות יותר עם המון קישורים בין אחת לשניה, או הצגת רשימה של מציוני לקוחות, ותבין שזה פוגע בביצועים.
(יש דרכים שונות לשפר אותן, כמו אינדקסים ושימוש ב-cache)
ב-NoSql אתה שומר את כל המידע על הלקוח באובייקט אחד גדול, ולא מתיחס לכך שזה עלול להיות בזבזני מבחינת מידע. היתרון הוא שפעולות על לקוח הופכות להיות פשוטות ומהירות, החסרונות הם שטח אחסון (ככל שמחירי האחסון יורדים זה נהיה זניח) ומהירות חיפוש לפי חיתוכים.
עוד קונספט שהוא לא בהכרח קשור ל-NoSql אבל רווח בו, הוא אי מחיקת מידע. אם הלקוח עבר דירה מתל אביב לפתח תקווה (למה שיעשה דבר שכזה?), במקום לעדכן את הרשומה, פשוט מוסיפים רשומה חדשה ומסמנים את הרשומה הקודמת כישנה.
למה זה טוב?
לכל מני כלי BI וניתוח שאולי ימצאו דפוסים שכרגע לא חשבת עליהם בעתיד, אז שומרים כמה שיותר מידע, ליתר בטחון.
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 12.11.19
613 הודעות
בתגובה להודעה מספר 0
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
חבר מתאריך 14.7.11
45794 הודעות, 148 מדרגים, 230 נקודות. ראה משוב
בתגובה להודעה מספר 17
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד