פרק מספר 511 של רברס עם פלטפורמה, שהוקלט ב-18 בינואר 2026. אורי ורן מקליטים בכרכור (הגשומה והקרה) ומארחים את נמרוד וקס - CPO ו-Co-Founder של BigID - שחצה את כביש 6 בגשם זלעפות כדי לדבר על אתגרים טכנולוגיים בעולם המופלא של Data Production ו-Security. 🎗️
[00:38] נמרוד, BigID ולמה אנחנו צריכים קטלוג ל-Data?
- נמרוד - אחד מה-Co-Founders של BigID, ש”עוזרת לארגונים להבין את ה-Data שלהם”.
- האתגר המרכזי של ארגונים היום הוא שהם אוספים אינסוף מידע (על לקוחות, עובדים, שוק), אבל מתקשים בשלושה דברים עיקריים: להגן עליו, לעמוד ברגולציות (פרטיות), ולהפיק ממנו ערך (למשל לטובת AI).
- הפתרון של BigID: בניית קטלוג של כל המידע בארגון.
- סריקת כל המערכות: Unstructured, Structured, Big Data, Cloud Storage, Business Applications . . .
- וגם אספקטים של Data at Rest & In Motion: מציאת המידע “איפה שהוא לא נמצא”.
- החברה עושה קלסיפיקציה (Classification) של המידע - שכבה סמנטית של ה-Metadata, ולא רק סמנטיקה:
- המערכת ממפה את ה-Metadata העסקי (“למה המידע משמש?”), האופרטיבי (“מי ה-Owner? למי יש גישה?”) והטכני.
- כולל Contextual Metadata - עמודות, שורות, Foreign Keys . . .
- לחברה יש גם את היכולת לייצר קורלציה ל-Data Subject – כלומר, להבין למי המידע שייך (לאיזה אדם ספציפי הוא מתייחס), שזה הבסיס לעולמות הפרטיות (כמו "הזכות להישכח").
- מעל הקטלוג הזה, BigID מנגישה אפליקציות -
- להגן על המידע - Data Access, Governance, Monitoring, Control.
- כולל היבטים של רגולציה בהגנה על המידע, בעיקר סביב Privacy Management.
- היום יש גם הרבה אספקטים של רגולציה סביב AI - ואיך להפיק ערך מהמידע הזה.
- הייחוד של החברה בעולמות ה-AI הוא היכולת לייצר קטלוג של Unstructured Data - שזה היום המקור המרכזי של AI.
- אם פעם אנשים היו מסתכלים על ה-Snowflake או על ה-Databricks שלהם כדי לעשות אנליזה למידע - היום הם מסתכלים על ה-OneDrive
- גם כדי למצוא את המידע שהם רוצים - וגם כדי למחוק את המידע שהם לא רוצים.
- רן - “אם פעם פיצ’רים היו בתוך עמודות ב-Database, היום אני מסתכל פשוט על Unstructured Text” . . . .
- החברה מאפשרת Secure pipelines ל-AI, ופיצ’רים של Security - גם ב-Design time וגם ב-Runtime - לאפליקציות AI.
- וגם אפשרות להפיק את המידע הזה החוצה - לספק את ה-Metadata הזה לכל אפליקציה אחרת בארגון
- כלי Cataloging לשימושי AI או למטרות Security - העשרה של המידע עם מידע (Metadata . . . ).
- נמרוד מגיע מרקע של Product Management - ניהל את ה-Identity Management Product Line של CA (היום בתוך Broadcom).
- ולפני כן רקע טכני - מפתח בתחומים של Security.
[05:18] האתגר הטכנולוגי: "אתה לא יכול להגן על מה שאתה לא רואה"
- רן מעלה את המשפט הידוע: "You can't protect what you can't see" - מה המשמעות מבחינת הלקוחות של BigID? מהם האתגרים הטכניים בייצור של פתרונות עבורם?
- נמרוד מסביר ש-BigID קמה על מנת לתת לארגונים את ה-Visibility הזה.
- ארגונים לא יודעים מה יש להם - וגם כשארגונים חושבים שהם יודעים איפה המידע הרגיש שלהם נמצא, בפועל הם טועים.
- ועל מנת להגן על מידע רגיש, בתור התחלה צריך לדעת איפה הוא - וזה האתגר מספר 1.
- דוגמא ל-Use Case נפוץ: איזשהו Stream של מידע, לפעמים Structured ולפעמים לא . . . עושים לו Structuring, מביאים אותו ל-Databases של האפליקציות - וחושבים שהוא רק שם.
- אחד ה-Use Cases הנפוצים זה עולם הבנקאות ו-Wealth Management - המון רגישות לפרטיות של הלקוחות.
- ארגונים כאלו מנהלים כמויות עצומות של מידע - ואסור שמספרי חשבון ופרטים מזהים יצאו מגבולות ה-Data Lake או ה-"Green Zones" לאיזורים אחרים.
- גם הדיוק מאוד חשוב - וגם ה-Scale מאוד גבוה.
- ואלו “עבירות של כלא” . . . .אם המידע דולף, המנכ"ל עלול ללכת לכלא.
- (רן) מהזוית של המהנדס - איך עושים דבר כזה? זה נשמע כמו RegEx . . . יש מספרי חשבונות בנק וכו’, אז הפתרון הטריויאלי הוא להפעיל איזשהו Regular Expression. אבל המציאות קצת יותר מורכבת . . . . אילו טכנולוגיות אחרות יש?
- נמרוד מסביר ש-”Regular Expression טוב בערך ל-Email . . . . לכל מה שהוא מעבר ל-Email, זה כבר לא עוזר לך”.
- הסיבה לכישלון של מערכות DLP (Data Loss Prevention) ישנות היא ההסתמכות על RegEx, שיצרו המון רעש.
- “זו פשוט לא טכנולוגיה מספיק טובה”.
- אחת הטכנולוגיות הראשונות ש-BigID יצאה איתה הייתה Correlation, מה שהחברה מכנה Identity Graph.
- היכולת לעשות Exact Value Matching על מידע שהוא Correlated.
- איך זה עובד? לוקחים Data ממערכת ה-CRM או ה-HR, ממפים פרופילים של משתמשים, ואז מוצאים את המידע הזה.
- זה נותן דיוק מאוד גבוה - וגם יכולת לדעת למי המידע שייך.
- לדוגמא - “מספרי חשבון זה רק רצף של מספרים - RegEx לא יעזור לך”.
- אם מוצאים רצף מספרים, קשה לדעת אם זה מספר חשבון או סתם מספר - אבל אם הרצף הזה תואם לרשימת הלקוחות מה-CRM – הוודאות גבוהה מאוד.
- מסתכלים על המסמך כולו, או על Entities בתוכו? גם וגם . . .
- יש Machine Learning & Deep Learning -
- שימוש ב-NER (Named Entity Recognition) לחילוץ ישויות.
- שימוש ב-Document Classifiers כדי לזהות את סוג המסמך (האם זה חוזה העסקה? האם זה NDA? - עושים Deep Learning על כל המסמך), ומזהים על סמך Training קודם.
- את אותו הדבר עושים גם עם LLM-Based Classification.
- מאפשר גמישות (גם וגם - או זה או זה, או שניהם)
- אבל מציב אתגרים חדשים של עלות ומהירות - זה יקר מאוד ואיטי מאוד לסרוק TBs של Data . . . . צריך להתחיל עם כל מיני סוגים של אופטימיזציות.
[11:01] סוגיית ה-Scale וה-Cost בעולם ה-LLM
- רן מציין שגם מודלים "צנועים" זה עדיין “מליארדים של פרמטרים”, וגם הם דורשים GPU ועולים לא מעט כסף.
- נמרוד מפרט על האסטרטגיה להתמודדות -
- אחת הטכניקות הראשונות הייתה ב-Small Language Models (SLM): התחילו עם BERT או RoBERTa.
- זה עבד (ביצועים טובים, עדיין צריך GPU), אבל חייב אימון (Training) על ה-Data של הלקוח – וזה "Big No No" מבחינת אבטחה (ענייני Security ורגולציה) ואופרציה (זמן…).
- “סיוט אופרטיבי” . . . .
- השלב הבא הוא LLMs (“מודרניים”): גם מודלים של 50 מיליארד פרמטרים כבר לא דורשים אימון (Pre-trained) ונותנים תוצאות מעולות.
- “ה-LLM של לפני חודש זה כבר ה-SLM של היום” . . . .
- והם כבר באים מאומנים.
- מה לגבי המחיר? פה נכנסת האופציה לעשות אופטימיזציה לסריקה (Full Scan vs. Sampling): רוב פתרונות ה-DSPM (Data Security Posture Management) לא מסוגלים לעשות Full Scan, הם עושים רק דגימה (Sampling מהיר מעל ה-Data).
- זו הדרך היחידה ל-Cost Effective Brute-force עם LLM . . . .
- זו אופציה טובה למטרות Security (ו-BigID מאפשרת אותה), אבל נמרוד טוען שזה לא מספיק ל-CISO, שצריך Full Scan.
- זה טוב בשביל Risk Assessment, אבל לא “פתרון סופי” [הגענו גם לזה…].
- פה מגיע הפתרון ההיברידי (LLM Augmented):
- משתמשים בכלים דטרמיניסטיים וזולים (כמו RegExאו NER) כדי לסרוק את הרוב.
- משתמשים ב-LLM כדי לנקות את ה-False Positives.
- "אתה מקטין בסדר גודל את כמות ה-Findings שאתה צריך לעבור עליהם וצריך לעשות עליהם LLM Classification”.
- מכוונים את ה-RegEx להיות "רחב" (לתפוס הרבה False Positive), ואז ה-LLM מנקה את השגיאות (גם אם עדיין משאיר קצת FP).
- אלו ענייני Cost-Effectiveness שצריך לקחת בחשבון.
- אורי מזכיר שנהוג לחשוב על LLM-ים כ”לא דטרמניסטיים” . . . . איך משתמשים בהם על מנת לקבל משהו דטרמניסטי?
- נמרוד משתמש במונח “כמה שיותר לא דטרמניסטי” - שהוא עצמו לא דטרמניסטי . . . .
- באופן כללי, Data Classification זו טכניקה סטטיסטית - אף פעם אין 100% ודאות.
- כן יודעים להגיע עם LLM לרמות דיוק מאוד גבוהות, יותר מאשר עם RegEx - כשמסתכלים על כל מגוון האפשרויות.
- יכול להיות שה-LLM ישווה ויטעה - אבל ל-RegEx אין שום אפשרות בכלל לבדוק (למשל - “האם זה לקוח?”).
- אלו False Positives עם Use Cases מאוד ספציפיים, לעומת שיטות דטרמיניסטיות שמחפשות את המידע הזה.
[16:13] סיכונים וחיות אחרות / " LLM זה ראשי תיבות של לא למחוק"
מה קורה עם לקוחות שגם מאמנים מודלים? רן העלה את החשש שמידע שדלף לתוך האימון של המודל "נצרב" בתוך המשקולות של ה-LLM (שזו למעשה “מכונה שיודעת לעשות Compaction מאוד יפה, וזוכרת כמה דברים” . . . ).
איך מתמודדים עם מידע בתוך המודל?
- נמרוד אומר ש”למחוק מידע מ-LLM זו משימה כמעט-בלתי-אפשרית”.
- יש טכנולוגיות שמתיימרות לעשות את זה, אבל זה מצריך כמות חישוביות כל כך גבוהה, שכבר עדיף לאמן את המודל מחדש.
- פרקטית, מה שצריך לעשות זה לטפל ב-Pipeline של ה-Data:
- מניעה (Sanitization) - “לא להכניס מידע שאתה לא רוצה”, לנקות את ה-Data הלא-רצוי לפני שהוא נכנס ל-Training או ל-RAG.
- סריקת Vector DBs: להסתכל על ה-Inference Framework.
- האמבדינג (Embedding) הוא “וקטור של מספרים”, אבל הוא מכיל לרוב גם את ה-Snippet של המידע המקורי עצמו, או לינק ל-Data במקום אחר - BigID יכולים לסרוק את ה-Data הזה (את ה-Vector DB), מזהים וקטורים שמכילים מידע רגיש, ושמים עליהם Label (אם המפתחים לא רוצים למחוק אותם).
- ואז אפשר להפעיל Access Control: ברגע שהוקטור מסומן כרגיש, אפשר למנוע מהאפליקציה למשוך אותו בשלב בניית התשובה.
- אורי מציין שראשי התיבות של LLM זה “לא למחוק” . . . . נמרוד - "בתעשייה שלנו, Job Security זה שארגונים לא מוחקים מידע אף פעם".
- צריך לזכור שהסיכונים הם לא רק זליגה של מידע, אלא באותה מידה גם Insider Threat: חשש שהמידע יחשף בתוך הארגון.
- ארגונים חוששים שעובדים ישתמשו ב-Microsoft Copilot (או Glean, או Gemini) כדי לשאול "מה המשכרות של ה-CEO, או של החבר שלי?"
- פעם היינו מוגנים ע"י "Security by Obscurity" (אף אחד לא ידע איפה הקובץ . . .
- [יש הטוענים ש-SharePoint זו מכונת הצפנה כמעט מושלמת]
- היום ה-AI מוצא הכל, והפתרון הוא סניטציה בסיסית, ללא קשר ל-AI, אלא ל-Data Access Governance.
- “לוודא שלאנשים הנכונים יש Access לדברים הנכונים”.
[20:38] הגנה בזמן ריצה Runtime Security & Agents
רן שואל על מקרים של שליחת מידע רגיש, (נניח ש)בטעות, למודלים פומביים, כמו -ChatGPT או Gemini. “לא תיארתי לעצמי שדווקא שם יהיה מספר חשבון בנק או פרטים סודיים” . . . אין אפשר להגן מפני טעויות כאלה?
- אז כאן יש את ה-Runtime - ואפשר לעשות Interception ל-LLM.
- מעיין Firewall לכל מה שיוצא החוצה ל-LLM - או נכנס פנימה.
- יש הרבה חברות שמתחילות להציע את זה היום - לא רק בשביל Data אלא גם עבור כל מיני שירותי Security: מציאת Vulnerabilities ו-Prompt Injections וכל מיני כאלה.
- ב-BigID מתמקדים ב-Data - גם מניעה של זליגה החוצה וגם ווידוא שהאנשים שנחשפים למידע הם אכן אלו שרשאים לגשת אליו.
- יש כל מיני שיטות לעשות את זה, כשב-BigID נמרוד מציג גישה של מעיין “AI Firewall” עבור “Home-grown Applications” -
- שימוש ב-LangChain hooks בשביל “יירוט הפרומפט” (Prompt Interception).
- אם רוצים להגן גם על Employee Access to AI, טכניקה נפוצה היא Plug-Ins ל-Browser (תוספי דפדפן, Browser Plugins).
- טכניקה נוספת היא להשתמש ב-API Gateways.
- כל API Firewall (כמו Congo למשל) מאפשר לעשות Hooking ל-Set של APIs.
- אפשר גם להתחבר ל-API של ה-Service - מאפשר לעשות את זה “בצורה הכי נקייה”.
- התממשקות, בדרך כלל ל-Audit Logs של הספקיות (OpenAI/Microsoft), ובאופן הזה חשיפה, דרך API, ל-Prompt.
- ואז יש יכולת לתת Alert או DDR - Data Discovery & Response.
- אבל גם Microsoft וגם אחרים נותנים עכשיו APIs שמאפשרים, ממש כמו LangChain, להיות Man in the Middle.
- רן מציין שבעולם ה-Agent-י זה כבר עוד יותר מורכב: זה כבר לא Copy-Paste אלא Agent ששובר את המשימה לחלקים ועושה Function Callings . . . . ”בלגן שלם”. איך מגינים על זה?
- כאן הבעיה הופכת לבעיית Identity Management - ו-Agent זו בעיה כזו.
- ה-Agent פועל בשם המשתמש - משתמש ב-Credentials וב-Identity של המשתמש.
- האתגר הוא להבדיל בין האדם למכונה - ומה ה-Context של העבודה.
- זה יותר מורכב מההבדלה בין Human ל-Non-Human Identities - זה דורש טכניקות מעולמות ה-Fraud Detection: זיהוי אנומליות, מהירות פעולה, ומקור הבקשה.
- הגבול הוא מאוד לא-חד (Blurred) - יש אדם שמשתמש ב-Agent - וצריך לדעת להבדיל בין פעילות של אדם לפעילות של מכונה.
- זה לא מדע חדש - אבל פתאום צריך לדעת להפעיל אותו על מקורות מידע ומקורות Compute חדשים.
- כשאתה ניגש בתור אדם למידע אז יש לך גישה, אבל אם ה-Agent מתחיל להעלות את כל הקוד לשרת בבלארוס – זו כנראה אנומליה שצריך לחסום . . .
[27:10] איך מטפלים במה שאתה לא יודע? / גישה חדשה ל-Access Control (דינמי וסמנטי)
- בכל ענייני ה-Unknown מטפלים בדרך כלל ע”י Anomaly Detection - מזהים Baseline שלהתנהגות, וברגע שיש חריגה אז יודעים לתת התראה.
- זה יכול להיות דברים טריוויאליים כמו התנהגות של Downloads (כמויות או מיקום) ויכולים להיות דברים יותר מורכבים (בהתאם לסוג הפעולה וסוג המידע).
- זה דורש Visibility יותר אינטימי ל-Classification של המידע.
- דבר נוסף הוא נושא ה-Access Controls באופן כללי - עולם ה-Security עד היום נבנה על סמך הגישה המסורתית של ACL (Access Control Lists)
- בעולמות ה-Agent-יים ובעולמות ה-AI בכלל, הגישה של ACL סטטי נשברת - אגרגציה (Aggregation) של מידע יוצרת רגישות חדשה.
- מידע שאולי היה לחלוטין לא רגיש כשהוא מבוזר - אבל כשעושים אגרגציה, נוצרים ההקשרים ו-Re-identification של מידע, שהופכת אותו פתאום לרגיש.
- רן נותן דוגמא: פרט אחד על חולה ב-Yorkshire ופרט אחר על גיל 80+ ב-Yorkshire אולי לא מזהים בנפרד; כל עוד המידע מאוד “רחוק אחד מהשני”, נדרשת “עבודת בלשות”, אבל ה-LLM מחבר אותם בקלות, וזה מוריד את סף התקיפה.
- הפתרון הוא קלסיפיקציה (Classification) של המידע בזמן אמת (On the fly) - המערכת צריכה לזהות שכרגע המידע הוא "רפואי", ולבדוק האם לאפליקציה/משתמש הספציפי מותר לראות מידע רפואי ברגע זה, ללא קשר למאיזה קובץ הוא הגיע.
- וזה משנה לגמרי את האופן שבו מנהלים גישה ל-Data - וזה מחייב Controls חדשים ו-Visibility אחר למידע.
- “סוג של ACL - אבל סמנטי ודינמי, On the fly”: קלסיפיקציה בזמן השימוש במידע, ולא (רק) Static Policies לפיסות מידע לא מחוברות.
- קצת מזכיר את התהליך שעבר על ה-Firewalls.
[31:38] סערת ה-LLM בחברה ותיקה
אורי שואל “מחוץ ל-Script” - אנחנו מדברים על חברה ותיקה (BigID), מימי טרום ה-LLM. איך עוברת הטרנספורמציה הזו על החברה?
- זה תהליך טבעי של חברה ושל אימוץ של טכנולוגיות חדשות.
- נמרוד משתף ש-BigID לא התחילה מ-RegEx, אלא מטכנולוגיה אלטרנטיבית חדשה ל-Data Classification - ורק אז השלימה את ה-RegEx, “כשהלקוחות רצו משהו מוכר”.
- “כשהגיעו המודלים של ה-NER וה-Deep Learning אז הכנסנו אותם”.
- אימוץ ה-LLM בחברה היה תהליך טבעי ומהיר (התחיל בהאקתון), כי קלסיפיקציה מבוססת-LLM זה משהו שקל יותר להטמעה מאשר בניית מודלים של NER מאפס.
ומה לגבי Real-time Identification? עולם האיומים השתנה - בהרבה.
- ה-Core של BigID הוא לא על בסיס Agents (על המכונות) - אלא API-Based, וזה תמיד היה ה-Guideline.
- גם ל-Activity Monitoring.
- ההתחלה הייתה עם Data at Rest - ואז נוספו Permissions ל-Data Access Governance.
- והדבר הבא שלקוחות רצו היה לדעת מי ניגש למידע - אז כל נושא ה-Real-time לא קשור ל-AI, אלא נכנס כחלק מההתפתחות של המוצר.
- אם כי זה כמובן גם משרת מאוד את כל נושא ה-AI.
- נמרוד לא בהכרח רואה את BigID נכנסת לבנייה של Gateways ל-AI
- בידול של BigID מול חברות Firewall (כמו Palo Alto / SentinalOne): חברות ה-Network וה-Endpoint שבונות את ה-Firewalls” “וטבעי להן” לבנות את ה-AI Gateways.
- ב-BigID פוגשים את זה בתור “האחראים על ה-Data” - וה-Data זה מה שמניע את ה-AI.
- כל מה שקשור ל-Home-grown AI Applications זה המשך מאוד רציף: AI Product הוא Data Product.
- היכולת לעשות אגרגציה ועיבוד מאוד מתקדם של מידע.
- עוד חוזקה היא על ה-Controls שקשורים ב-Data - ההבנה של ה-Context שעובר בתוך ה-Prompt.
- הכרות יותר אינטימית עם ה-Data והיכולת לדעת האם הוא רגיש.
- והיכרות עם הרגולציות הרלוונטיות - איזה מידע ניתן לשימוש באיזו אפליקציה: בדומה ל-Privacy, עכשיו זה לכיוון של AI Regulations.
[36:59] גיוסים וסיכום
- החברה מונה כ-600 עובדים, מרכז הפיתוח (R&D, Product, Design) נמצא בתל אביב.
- מגייסים בכל התחומים - גם Product, גם פיתוח, גם Design.
- הארגון בינלאומי - אבל מובילים את המוצר מהארץ.
תודה - ובהצלחה!
האזנה נעימה ותודה רבה לעופר פורר על התמלול!
אין תגובות:
הוסף רשומת תגובה