לבדוק לאן הספקים שלכם עדיין יכולים להגיע

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

שלושה אירועים, דפוס אחד

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

• IDScan.net. ב-21 בספטמבר 2026 פתח משרד נציב הפרטיות של קנדה בחקירה, בעקבות דיווחים שגורם לא מורשה "השיג גישה למאגר הנתונים של החברה וגנב מידע אישי, כולל סריקות דיגיטליות של רישיונות נהיגה". מקומות אירוח ובילוי לילי משתמשים ב-IDScan.net כדי לבדוק תעודות מזהות של לקוחות, כך שהלקוחות של אותם מקומות נחשפו דרך ספק. ההודעה של החברה עצמה מציינת שנודע לה על הגישה בסביבות 1 בספטמבר. ההיקף שמופיע ברוב הכותרות מגיע ממקור אחר: מודעה ברשת האפלה הציעה יותר מ-153 מיליון סריקות של רישיונות, ו-KrebsOnSecurity איתר את מקורן ב-IDScan.net. לא הרגולטור ולא החברה אישרו מספר כלשהו.
• McKesson. ב-28 באוגוסט הודיעה McKesson שהיא חוקרת "אירוע סייבר שכלל יישומי צד שלישי, גישה לא מורשית והוצאת נתונים". העדכון שלה מ-21 בספטמבר אישר שהגישה "הוגבלה ליישומי צד שלישי מסוימים". קבוצה עבריינית טענה להרבה יותר; BleepingComputer דיווח על הטענה וציין שלא אימת אותה באופן עצמאי.
• Aeroméxico. בהצהרה שדווחה ב-El Financiero ב-21 בספטמבר, קשרה חברת התעופה בין נתוני לקוחות שהוצעו ברשת לבין אירוע מאוקטובר 2025, ומסרה שהגישה הלא מורשית התרחשה בפלטפורמה למידע על לקוחות שמנוהלת בידי ספק חיצוני.

השאלה שמאחורי שלושתם

"האם הספק שלנו מאובטח?" היא שאלה לספק. "לאן כל גורם חיצוני עדיין יכול להגיע היום, והאם זה צריך להיות כך?" היא שאלה שאתם יכולים לענות עליה בעצמכם. מסגרות העבודה המקובלות כבר מצפות לה. NIST Cybersecurity Framework 2.0 (GV.SC-10) דורשת שתוכניות לניהול סיכוני שרשרת האספקה "יכללו הוראות לפעילויות שמתרחשות לאחר סיום שותפות או הסכם שירות". ההנחיות של ה-ICO הבריטי לחוזים קובעות שבסיום חוזה, מעבד המידע חייב, לפי בחירת האחראי לעיבוד, "למחוק או להחזיר לאחראי לעיבוד את כל המידע האישי שעיבד עבורו".

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

מתחילים מהתיקיות שאתם משתפים

ב-Kiteworks, העברת קבצים עם ספקים מתבצעת לעיתים קרובות בתיקיות משותפות. שלושה סוכנים מה-Marketplace מכסים חלקים שונים של הבדיקה:

• Sharing Auditor עובר על היקף תיקיות שאתם בוחרים ומדווח אילו עצי תיקיות משותפים, מאיפה מתחיל כל שיתוף וכמה מהעץ הוא סרק. הוא לא חושף מי החברים ואם הם פנימיים או חיצוניים, והוא לא מזהה קבצים ששותפו ישירות או שיתוף מעל התיקייה העליונה שהמשתמש הסורק רואה.
• Folder Expiry Audit מדווח לאילו תיקיות יש הגדרת תפוגה או שמירה ולאילו אין. תיקיית פרויקט בלי תפוגה נשארת משותפת עד שמישהו מסיר את השיתוף. הסוכן רק קורא; הוא לא יכול להגדיר תפוגה.
• Sensitive Content Scanner מאתר מונחים רגישים ומידע אישי נפוץ, כמו מספרי ביטוח לאומי אמריקאיים (SSN), מספרי כרטיסי אשראי ומספרי IBAN, וכך מראה אילו תיקיות משותפות כדאי לבדוק קודם.

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

בדיקה שהאחראי על הספק יכול להריץ

1. לרשום את הספקים והפרויקטים שהסתיימו בשנים-עשר החודשים האחרונים, ואת התיקיות ששימשו להעברת קבצים איתם.
2. להריץ את Sharing Auditor על כל תיקייה. לתעד את מקורות השיתוף שהוא מצא ואת החלקים בעץ שהוא לא הצליח לסרוק.
3. להריץ את Folder Expiry Audit על אותו היקף. לציין לאילו תיקיות משותפות אין תפוגה.
4. להריץ את Sensitive Content Scanner על התיקיות המשותפות כדי לקבוע את סדר הבדיקה.
5. לכל תיקייה משותפת, האחראי מאמת מול מקור מאושר למי עדיין צריכה להיות גישה, כי הסוכנים לא רואים את החברים. לשמור את השיתוף, לצמצם אותו או להסיר אותו, ולתעד את ההחלטה ואת התאריך.
6. לחזור על הבדיקה בסיום כל חוזה ובמרווח קבוע, למשל פעם ברבעון.

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

כדי לעבור איתנו על בדיקה של תיקיות ספקים, אפשר לכתוב אל sales@kiteworks.com או לפתוח בשיחה. לא צריך Claude או הגדרת MCP כדי לשאול. אפשר גם לקרוא את חשיפת שיתוף בתיקיות: בדיקה בעזרת AI.