קמפיין לקוחות בשירות חיצוני

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

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

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

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

מה עושים? כנראה שאין הרבה מה לעשות. אפשר לנסות את ההצעות הבאות:

1. להגדיר חוקים במערכת DLP לזיהוי זליגת נתונים רגישים (שיוצאים בתור דוגמא למשרד הפרסום).
2. לנסות לזהות ולחסום גישה לקמפיינים כאלה ע"י מערכת Web Filtering – מאוד קשה לעלות על זה.
3. לחנך את השיווק (לא ממש יעזור).
4. לבנות עם מערכות מידע תשתית מוכנה מראש לקמפיינים – אחלה הצעה אבל בד"כ לא ממוממשת עקב חוסר משאבים.
5. להעביר החלטה בהנהלה/דירקטוריון נגד הפקרות בנתוני לקוחות – מאוד יעיל אבל קשה למימוש.

 

פגיעה במידע בשירות מיקור חוץ

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

הוצאת שירותים עסקיים מצריכה לאפשר אחת מהשתיים:

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

 

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

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

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

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

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

 

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

 

סיכונים הנובעים ממערכת MDM בענן

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

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

• ממשק הניהול של המערכת נגיש לכל אחד בעולם. אם גורם זר מצליח להשיג את נתוני ההזדהות לממשק (בין אם ע"י גניבת סיסמא או ע"י מתקפת XSS וכל דרך אחרת), הרי שהוא יכול להשבית את השירות לארגון שלם. במצבים מסוימים ייתכן והוא גם יצליח לרשום מכשיר שאינו שייך לארגון אל השרת הארגוני. או שמישהו יחליט למחוק לחלוטין (Remote Wipe) מכשירים מתוך רוע לב.
• פתיחת גישה ל – Active Directory למערכת בענן. בארגון גדול, לא ירצו לנהל משתמשים מקומיים במערכת, אלא לקשר את המערכת למשתמשים המוגדרים ב – AD. רגע, אתם רציניים? לפתוח את AD הארגוני לספק שירות זר המספק פלטפורמה משותפת לעוד אלפי לקוחות?

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

סיכונים במחשוב ענן

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

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

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

1. מעילה/גניבה: אדמין עם הרשאות חזקות בחוות השרתים של הענן מסוגל להפעיל אפליקציות רגישות או להכנס לבסיסי נתונים רגישים ולבצע מעילה בכספי הארגון או לגנוב נתונים רגישים. כל זאת, ללא יכולת בקרה של הארגון.
2. תשתית לא מאובטחת: אם בארגון יש למנהלי הרשת בקרה על הקשחת שרתים, השרתים בענן עשויים שלא להיות בשליטת הארגון. ניצול פרצות בהקשחות השרתים עשוי לאפשר ניצולם לרעה.
3. היעדר אמצעי אבטחה נאותים: אם ברשת הפנימית אנחנו יכולים להתקין מערכות אבטחה כראות עינינו, בענן היכולת שלנו מוגבלת עד בלתי-אפשרית. רמת אבטחת המערכות שלנו עשויה לרדת באופן משמעותי ביציאה לענן.
4. ממשק ניהול פרוץ: כדי להקל על ארגונים, או עקב חוסר מודעות, ספק הענן עשוי לאפשר גישה לא מאובטחת כראוי ללקוחות השונים לצורך ניהול המערכות. סביר להניח שהאקר ינסה בראש ובראשונה להשיג גישה לממשק זה שיאפשר לו שליטה מלאה לביצוע פעולות זדוניות.
5. תקלות כלליות: תקלה בהגדרות או בתוכנה של הספק עשויות לפתוח, באופן זמני, פרצה רוחבית לכל המערכות המאוחסנות אצל הספק. לא מזמן פורסם מקרה כזה שאפשר, למשך כשעתיים, גישה לכולם ללא סיסמא.
6. שיתוף מידע: המידע המאוחסן ע"י הספק יושב בתשתית Storage משותפת. הגדרות לקויות עשויות לגרום לזליגת מידע בין לקוחות.
7. חבות משפטית: בשירותי ענן, לא ברור איפה השירות נמצא – באיזה מדינה חוות השרתים מותקנת. ייתכן גם שהשירות ינדוד בין חוות שרתים במדינות שונות באופן שקוף לארגון. במקרה של אירוע, מול איזה ישות משפטית ימוצה הדין, ולפי חוק של איזה מדינה? האם יש לארגון שליטה על בחירת הרשות השופטת?

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