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

1. איזה מידע המערכת מחזיקה

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

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

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

2. אילו תפקידים והרשאות קיימים

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

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

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

3. הפרדה בין לקוחות ובין משתמשים

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

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

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

4. מה חשוף לאינטרנט ומה מחובר מבחוץ

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

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

5. מה לשאול את המפתח

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

6. מה להכין לבודק

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

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

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

מה בדיקה מקצועית בוחנת ומה מגבלותיה

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

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

מה הצעד הבא

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

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