כאן מתוארים הבקרות שפועלות בפועל באתר, בפורטל הלקוחות ובמערכת העבודה של הפירמה, ומה כל אחת מהן אינה עושה. כל משפט נבדק מול הקוד, מול המערכת החיה או מול נוסח הדין, ולא נכתב משפט שלא הצלחנו לבדוק.
נבדק ב-2.11.2026
כל בקשת שינוי בקוד (pull request) עוברת שער בדיקה אוטומטי: Gitleaks מחפש סודות בקוד ובהיסטוריה שלו, Semgrep מנתח את הקוד, כללי האבטחה של המאגר בודקים בקרת גישה, הזרקות, סודות והרשאות של סוכני בינה מלאכותית, npm audit ו-pip-audit בודקים תלויות עם חולשות ידועות, Bandit בודק קוד Python ו-ShellCheck בודק סקריפטים. ממצא חדש צובע את הריצה באדום. השער רץ גם על כל מיזוג לענף הראשי ובכל יום שני, והריצה על הענף הראשי ב-2.11.2026 הסתיימה ללא ממצא חדש. הכללים ממופים ל-OWASP Top 10 (2025), ל-OWASP API Security Top 10 (2023), ל-OWASP Top 10 for LLM Applications (2025), לבקרה A.8.28 של ISO/IEC 27001:2022 ול-NIST SP 800-218 (SSDF).
גבול: השער מזהה דפוסים ידועים, ואינו בדיקת חדירה. ממצאים ישנים שנבדקו ונמצאו לא מסוכנים רשומים ברשימת חריגים, כל אחד עם הנימוק שלו. בהגדרות המאגר השער אינו מוגדר עדיין כבדיקת חובה, ולכן הכלל שלא ממזגים שינוי עם ריצה אדומה הוא כלל עבודה. בדיקת התלויות מכסה את האפליקציה ואת שירות ה-webhook הקולי, ולא את כל הפרויקטים המשניים שבמאגר.
ב-1.11.2026 נבדק כל מאגר הקוד מול אותם תקנים: סריקת סודות בכל היסטוריית השינויים, ניתוח קוד סטטי, קריאה ידנית של כל 45 פונקציות השרת ושל תהליכי האוטומציה, ויועץ האבטחה של מסד הנתונים. התיקונים לממצאים הבאים נפרסו ב-2.11.2026: הרשאת מנהל נקבעת לפי דגל במסד ולא לפי כתובת דוא״ל, פעולות מנהל בפונקציות השרת דורשות אימות דו-שלבי, נתיב קובץ נבדק כך שלא ייצא מהתיקייה של המשתמש, שליחת דוא״ל מוגבלת לכל חשבון בכל שעה, וסוד משותף מושווה בזמן קבוע. ב-5.11.2026 נסגרו עוד ארבעה: דרישת הגורם השני של המנהל הורחבה להרשאות ברמת השורה, מפתח הדוח היומי עבר מכתובת הבקשה לכותרת שלה, וכך גם המפתח שספק החתימה האלקטרונית שולח, והתלויות בפרויקטים המשניים עודכנו. שני התיקונים הראשונים נבדקו באותו יום מול המערכת החיה.
גבול: לא כל הממצאים נסגרו. אחד פתוח: תלות אחת בכלי שרץ רק על מחשב הפירמה ממתינה לגרסה חדשה של הספרייה שמגבילה אותה. בתיקון של ספק החתימה האלקטרונית נבדק מול המערכת החיה שבקשה שמביאה את המפתח בכתובת נדחית. הביקורת נעשתה בידי הפירמה ולא בידי גוף חיצוני.
מי שמנהל את הפלטפורמה נקבע רק לפי דגל במסד הנתונים, ולא לפי כתובת דוא״ל שמושווית בקוד. פונקציות השרת שפועלות בהרשאת מנהל דוחות סשן שנכנס בסיסמה בלבד, ודורשות סשן שעבר אימות דו-שלבי. מ-5.11.2026 כך גם ההרשאות ברמת השורה ובאחסון הקבצים שפתוחות למנהל: סשן שנכנס בסיסמה בלבד מקבל בהן את ההרשאות של משתמש רגיל, וחיבור של כלי חיצוני בשם המנהל אינו מקבל הרשאת מנהל כלל.
גבול: הבדיקה החיה ב-5.11.2026 נעשתה מול פונקציית ההרשאה במסד הנתונים, בסשן מדומה של המנהל בגורם אחד ובשני גורמים, ולא בכניסה דרך הממשק.
קוד המקור של הפלטפורמה, מבנה מסד הנתונים ופונקציות השרת נמצאים במאגרי קוד פרטיים, ואינם גלויים לציבור.
גבול: מי שמחובר למאגרים רואה את הקוד: בעל הפירמה, וכלי הפיתוח והפריסה שמחוברים אליהם. סריקת הסודות המובנית של GitHub אינה זמינה למאגר פרטי של חשבון אישי, ולכן הבדיקה לסודות היא Gitleaks בשער שבסעיף הראשון, שרץ על כל שינוי, על כל מיזוג לענף הראשי ובכל יום שני.
אזור הלקוחות, פורטל הלקוח וסביבת העבודה של הפירמה דורשים התחברות. העוזר המשפטי באתר פועל רק למשתמש מחובר: פנייה אנונימית מקבלת בקשת התחברות ולא מגיעה למודל.
גבול: כלי ניתוח החוזים הציבוריים אינם דורשים התחברות. הם מתוארים בקבוצה "בינה מלאכותית".
לשותפים ולעורכי דין זמין אימות דו-שלבי באפליקציית אימות (TOTP), ובחשבון הפירמה הוא מוגדר כחובה. את הדרישה אוכף מסד הנתונים עצמו ולא רק הממשק: רשומות רגישות כגון בדיקות זיהוי לקוח, גרסאות מסמכים ונספחים נדחות מסשן שלא עבר את הגורם השני. חריג אחד, בהחלטת הבעלים: חשבון הנהלת החשבונות החיצונית נכנס בסיסמה בלבד. לחשבון הזה אין גישה לתיקים, למסמכים או לרשומות הרגישות שלעיל, והוא מוגבל לצפייה והורדה של חומרי הנהלת החשבונות.
גבול: חשבון שנכנס בסיסמה בלבד חשוף יותר לדליפת סיסמה, ולכן ההרשאה שלו מוגבלת מראש לקריאה בלבד.
בהפעלת האימות נוצרים שמונה קודי שחזור חד-פעמיים, ומוצגים פעם אחת. הקוד עצמו אינו נשמר, אלא גיבוב SHA-256 הקשור לחשבון. חמישה ניסיונות שגויים נועלים את השחזור לחמש עשרה דקות. שחזור מסיר את גורמי ה-TOTP הקיימים, כדי שאפשר יהיה לחבר אפליקציה חדשה.
דגל מנהל הפלטפורמה אינו ניתן לשינוי מסשן של משתמש, גם לא של המשתמש עצמו, ואינו ניתן להגדרה בעת הרשמה. הוא נקבע רק בצד השרת.
סיסמה חדשה, בהרשמה, בהחלפה ובאיפוס, חייבת לכלול לפחות 12 תווים ולא יותר מ-72 בתים. אין חובה לסימנים מיוחדים. הטופס חוסם סיסמאות נפוצות, חזרות ורצפי מקלדת, וסיסמה שבנויה מכתובת האימייל או מהשם של החשבון. הוא בודק גם אם הסיסמה הופיעה בדליפה פומבית, בשיטה שבה יוצאים מהדפדפן רק חמשת התווים הראשונים של גיבוב הסיסמה. בטופס ההחלפה צריך להזין את הסיסמה הנוכחית, והיא נבדקת מול שרת האימות. אחרי החלפה או איפוס, כל שאר ההתחברויות של החשבון מנותקות. אפשר לאפס סיסמה גם בקוד חד-פעמי שנשלח במייל, ובחשבון עם אימות דו-שלבי נדרש גם קוד האפליקציה לפני שאפשר לבחור סיסמה חדשה.
גבול: הבדיקות שבטופס, כולל בדיקת הדליפה וההשהיה אחרי ניסיונות שגויים, רצות בדפדפן. פנייה ישירה לממשק ההרשמה של ספק האימות עוקפת אותן: שם נאכפים רק מינימום של 12 תווים ובדיקת הסיסמאות המדולפות של הספק עצמו, ולא החסימה של סיסמאות נפוצות, חזרות ורצפי מקלדת. גם הדרישה להזין את הסיסמה הנוכחית נאכפת בטופס ולא בשרת.
בכל יום שני בבוקר רצה בדיקה אוטומטית שאינה נוגעת בנתונים. היא מריצה את בדיקות מדיניות הסיסמאות, בונה את האתר וסורקת את הקוד שנשלח לדפדפן לחיפוש מפתח שירות, מפתח ספק או מפתח פרטי. אחר כך היא פונה לאתר החי ובודקת שהוא שולח כותרות אבטחה, שקריאה אנונימית לעוזר האתר מקבלת בקשת התחברות ולא תשובה, ושאישור תשלום בלי הסוד המשותף נדחה. תוצאת כל ריצה נשלחת לפירמה, וכשל בבדיקה מסמן את הריצה באדום. הריצות הידניות שהופעלו ב-20.10.2026 וב-21.10.2026 הסתיימו ללא כשל.
גבול: הבדיקה סוקרת ארבעה דברים בלבד. היא אינה בודקת את מסד הנתונים (הרשאות שורה, מדיניות וגישה), שנבדקים בנפרד בבדיקת SQL ידנית, ואינה מחליפה בדיקת חדירה.
בכל טבלאות הנתונים מופעלת אבטחה ברמת שורה (Row Level Security): 147 מתוך 147 בבדיקה מיום 10.11.2026. הגישה לתיק מותנית בתפקיד ובשיוך לפירמה, והיא נאכפת במסד הנתונים ולא רק בממשק.
גבול: הפעלת המנגנון בכל טבלה אינה הוכחה שכל מדיניות נכונה. לכן נכתבו בדיקות SQL ייעודיות לבידוד בין תיקים, חיוב וגישה לפי תפקיד, והן חלק מהקוד.
במסכי הצוות מוצג קוד תיק במקום שם הלקוח. חשיפת השם היא פעולה מכוונת שמותרת למנהל הפירמה בלבד, וגם לשותף או לעורך דין שמנהל הפירמה אישר לכך במפורש, אחרי אימות דו-שלבי עדכני. היא דורשת בחירת סיבה, ונרשמת ביומן הביקורת עם מי חשף ולמה, וגם סיום החשיפה ואישור ההרשאה נרשמים.
גבול: זו בקרה ברמת התצוגה. הרשאת הקריאה לתיק עצמו נקבעת במסד הנתונים, כמתואר בסעיף הקודם. הנהלת החשבונות החיצונית רואה את פרטי הלקוח המחויב במסמכים הכספיים ואת תנועות חשבון הבנק העסקי, לקריאה בלבד, כנדרש לניהול ספרים ולהתאמת בנק. אין לה גישה לתיקים.
מפתח השירות הפריבילגי של מסד הנתונים נמצא רק במשתני הסביבה של פונקציות השרת. חבילת הקוד שנשלחת לדפדפן נבדקה, ולא נמצאו בה מפתח שירות, מפתחות של ספקים או מפתחות פרטיים. בדפדפן יושב המפתח הציבורי בלבד, וההגנה על הנתונים נשענת על הסעיף הקודם.
כל שמונת מאגרי הקבצים במערכת מוגדרים פרטיים. פתיחת קובץ מהפורטל, ופתיחת מקור של מסמך על ידי שותף או עורך דין, נעשות בקישור חתום שתוקפו שישים שניות.
גבול: קישורי עבודה פנימיים של צוות הפירמה יכולים להיות בני תוקף ארוך יותר, עד שעה. חריג אחד: כשלקוח מעלה קובץ לפורטל, הפירמה מקבלת הודעת דוא״ל עם קישור הורדה שתקף 72 שעות, וכל מי שמחזיק בהודעה יכול להוריד בו את הקובץ עד שיפוג. חותם חיצוני רואה את המסמך שנשלח אליו לחתימה בקישור שתקף עשר דקות.
ספק מסד הנתונים והאחסון, Supabase, מצהיר שהנתונים מוצפנים במנוחה ובמעבר.
גבול: זו הצהרת הספק ולא תכונה שבנינו. היא מכסה את הנתונים שבתוך הפלטפורמה שלו.
Supabase מצהירה שהיא עומדת בתקן SOC 2 Type 2 ונבדקת אחת לשנה על ידי גורם חיצוני.
גבול: ההסמכה היא של הספק בלבד. לפי הספק עצמו היא אינה עוברת לסביבות שמחוץ לפלטפורמה, ואינה הסמכה של LALUM.
באפליקציה אין שדות להזנת פרטי כרטיס אשראי. הזנת הפרטים מתבצעת אצל חברת הסליקה, ופרטי כרטיס אינם נשמרים במסד הנתונים של LALUM.
אישור תשלום מחברת הסליקה נקלט רק עם סוד משותף, שנבדק בהשוואה בזמן קבוע, ונדחה כשהסוד אינו מוגדר. כשהאישור כולל סכום, הוא חייב להתאים לסכום אבן הדרך, ואחרת האבן דרך לא מסומנת כמשולמת.
גבול: האימות הוא סוד משותף ולא חתימה קריפטוגרפית של הספק על כל הודעה.
הודעות WhatsApp נקלטות רק עם חתימת HMAC-SHA256 תקפה של Meta, ונדחות כשהסוד אינו מוגדר. ה-webhook הקולי וה-webhook של החתימה האלקטרונית נדחים כשהסוד שלהם אינו תואם או אינו מוגדר.
האתר מוגש ב-HTTPS עם HSTS לשנה הכולל תתי דומיינים. מדיניות תוכן (CSP) אוכפת, ולא רק מדווחת, אוסרת סקריפטים מקוונים ואובייקטים, מגבילה מאיפה נטענים סקריפטים, ומונעת הטמעת האתר במסגרת של אתר זר. מוגדרות גם כותרות nosniff, מדיניות רפרר, מדיניות הרשאות דפדפן ובידוד חלונות.
גבול: המדיניות מתירה סגנונות מקוונים. סקריפטים נטענים רק מהמארחים הרשומים בה, ובהם שירותי צד שלישי של האתר הציבורי.
טפסי הפנייה, קביעת פגישה, ניתוח החוזים והעוזר המשפטי מוגבלים לפי מקור הפנייה. לעוזר המשפטי יש גם מכסה יומית לכל משתמש ומכסה יומית כוללת. כתובת ה-IP של מבקר אינה נשמרת: נשמר גיבוב שמשמש את המגבלה בלבד.
כל רשומה ביומן הביקורת של פירמה כוללת גיבוב SHA-256 של הרשומה שלפניה, ויש פונקציית בדיקה שמאתרת את הרשומה הראשונה שבה השרשרת נשברת. עדכון או מחיקה של רשומה נדחים בידי המסד, וכתובת דוא״ל אינה נרשמת ביומן.
גבול: השרשרת מגלה שינוי בדיעבד, והיא אינה אחסון חיצוני בלתי ניתן לשינוי.
משימות מתוזמנות רצות בכל יום: מחיקת מסמכי תיק שהלקוח הסכים למחיקתם שלושים יום אחרי סיום הטיפול, אלא אם חל עיכוב משפטי, והמחיקה נרשמת ביומן הביקורת. מחיקת פניות מהאתר בתום תקופת השמירה שלהן. ריקון תוכן הודעות WhatsApp אחרי שלושים יום, כשמועד וכיוון ההודעה נשארים. ופינוי רשומות זמניות של מנגנון הסרת הזיהוי.
במערכת העבודה של הפירמה שמות לקוחות וכתובות מוחלפים באסימונים כגון [CLIENT_NAME_2] לפני שהטקסט נשלח לניתוח, והמיפוג חזרה לשמות האמיתיים נשמר בדפדפן למשך הסשן בלבד ומופעל בייצוא.
גבול: הזיהוי מבוסס כללים וזיהוי תבניות, ואינו מבטיח זיהוי של כל פרט. לכן ההחלטה המקצועית נשארת בידי עורך דין, והסרת הזיהוי היא שכבת הגנה ולא תחליף לשיקול דעת.
כלי ניתוח החוזים הציבוריים באתר פועלים ללא התחברות ושולחים את הטקסט שהוזן אליהם לספק בינה מלאכותית חיצוני לצורך הניתוח. אין להזין אליהם מסמכים חסויים או מידע מזהה של אחרים.
גבול: פלטי הכלים אינם ייעוץ משפטי ואינם מחליפים עורך דין.
נבדק ב-5.11.2026
סעיף 90 לחוק לשכת עורכי הדין קובע: "דברים ומסמכים שהוחלפו בין לקוח לבין עורך דין ויש להם קשר עניני לשירות המקצועי שניתן על ידי עורך הדין ללקוח, לא יגלה אותם עורך הדין בכל הליך משפטי, חקירה או חיפוש, מלבד אם ויתר הלקוח על חסינותם." לפי לשון הסעיף, הוויתור בידי הלקוח.
גבול: החיסיון הוא הוראת דין ולא בקרה טכנית, והמערכת אינה מכריעה מה חסוי. הבקרות שמגינות על חומרי התיק מתוארות בסעיפים SEC-05, SEC-06 ו-SEC-18.
מקור: סעיף 90 לחוק לשכת עורכי הדין, התשכ״א-1961
כלל 19 קובע: "עורך דין ישמור בסוד כל דבר שיובא לידיעתו בידי לקוח או מטעמו, תוך כדי מילוי תפקידיו, זולת אם הסכים הלקוח במפורש אחרת; הוראה זו אינה חלה על גילוי בהליך משפטי, חקירה או חיפוש שאינו חסוי על פי סעיף 90 לחוק." כלל 20 מוסיף: "עורך דין יעמיד את העובדים בשירותו על חובתם לשמור על סודיות הענינים המגיעים לידיעתם במהלך עבודתם." במערכת, הגישה לתיק נקבעת לפי תפקיד ושיוך לפירמה (SEC-05), ולחשבון הנהלת החשבונות החיצונית אין גישה לתיקים (SEC-02).
גבול: החובה מוטלת על עורך הדין ועל העובדים בשירותו. בקרות הגישה במערכת תומכות בה, ואינן ממלאות אותה במקומם.
מקור: כללים 19 ו-20 לכללי לשכת עורכי הדין (אתיקה מקצועית), התשמ״ו-1986
נבדק ב-5.11.2026
סעיף 13(א) לחוק הגנת הפרטיות קובע: "כל אדם זכאי לעיין בעצמו (...) במידע האישי שעליו המוחזק במאגר מידע." לפי אותו סעיף, אפשר לעיין גם באמצעות בא כוח שהורשה בכתב או באמצעות אפוטרופוס. סעיף 13(ג1) מסייג: "אין בהוראות סעיף זה כדי לחייב למסור מידע אישי בניגוד לחסיון שנקבע לפי כל דין, אלא אם כן המבקש הוא מי שהחסיון נועד לטובתו." בקשת עיון במידע שמוחזק אצלנו נשלחת אל [email protected], כפי שכתוב במדיניות הפרטיות (SEC-33).
גבול: הסימן (...) מחליף את המילים על בא כוח ועל אפוטרופוס, שמתוארות אחרי הציטוט. העמוד אינו מתאר מועדי מענה או סדרי בקשה, ואינו מפרש את הסייג מעבר ללשונו.
מקור: סעיפים 13(א) ו-13(ג1) לחוק הגנת הפרטיות, התשמ״א-1981
סעיף 14(א) לחוק קובע: "אדם שעיין במידע האישי שעליו ומצא כי אינו נכון, שלם, ברור או מעודכן, רשאי לפנות לבעל השליטה במאגר המידע (...) בבקשה לתקן את המידע האישי או למוחקו." גם בקשה כזו נשלחת אל [email protected].
גבול: הסימן (...) מחליף את ההוראה על בעל שליטה שהוא תושב חוץ, שהושמטה מהציטוט.
מקור: סעיף 14(א) לחוק הגנת הפרטיות, התשמ״א-1981
לפי תקנה 21(4), על "מאגר המנוהל בידי יחיד" חלה רשימה מצומצמת של תקנות. אבל ההגדרה שבתקנה 1 מוציאה ממנו במפורש "מאגר מידע הכולל מידע שבעל המאגר כפוף בשלו לחובת סודיות מקצועית לפי דין או לפי עקרונות של אתיקה מקצועית". מאגר התיקים של הפירמה כולל מידע כזה (SEC-28), ולכן הרשימה המצומצמת אינה חלה עליו. בכל אחת משלוש רמות האבטחה האחרות שבתקנה 21 חלות תקנה 2, שלפיה בעל המאגר יגדיר "מסמך הגדרות מאגר", ותקנה 4(א), שלפיה הוא יקבע "נוהל אבטחת מידע".
גבול: העמוד מצטט את התקנות ואינו קובע איזו משלוש הרמות חלה על מאגר הפירמה. הבקרות שבעמוד לא מופו לתקנות ולא נבדקו מולן בידי גורם חיצוני.
מקור: תקנות 1, 2, 4(א) ו-21 לתקנות הגנת הפרטיות (אבטחת מידע), התשע״ז-2017
נבדק ב-5.11.2026
הסעיפים כאן מצטטים את מדיניות הפרטיות שמפורסמת באתר. הנוסח הקובע הוא נוסח המדיניות עצמה.
מדיניות הפרטיות קובעת: "אנחנו לא מוכרים את המידע שלכם. ענייני לקוח מוחזקים תחת חיסיון עורך דין ולקוח."
גבול: החיסיון עצמו נובע מהדין (SEC-27), ולא מהמדיניות.
מקור: מדיניות הפרטיות באתר
מדיניות הפרטיות קובעת: "יש לכם זכות לדעת איזה מידע אישי מוחזק אצלנו עליכם, לעיין בו, ולבקש לתקן או למחוק אותו. למימוש הזכויות, פנו אלינו בכתובת [email protected]."
גבול: הזכויות עצמן קבועות בחוק (SEC-29, SEC-30), והמדיניות מפנה למימושן.
מקור: מדיניות הפרטיות באתר
שלושה דברים שאפשר לקחת ולהשתמש בהם. לכל אחד כתוב אם הוא רץ אצלנו או שהוא תבנית, ומה תוקן בהשוואה לגרסאות נפוצות.
שאילתת קריאה בלבד אחת שמריצים ב-SQL Editor של Supabase. היא לא משנה דבר, ומחזירה רשימת מוקדים לבדיקה לפי חומרה. הרצנו אותה על מסד הנתונים של LALUM ב-19.10.2026.
מה תוקן לעומת גרסאות נפוצות:
תבנית למאגר שבו כל משתמש רואה רק את התיקייה שלו, עם מגבלת גודל וסוגים. שמונת מאגרי הקבצים של LALUM פרטיים, ומדיניות הגישה אליהם נבנתה על אותו עיקרון: ב-client-files לפי בעלות, וב-matter-originals לפי פירמה, תפקיד ואימות דו-שלבי.
מה תוקן לעומת גרסאות נפוצות:
הרעיון: הקובץ לא נכתב למאגר ישירות מהדפדפן. הוא עובר בפונקציית שרת, נבדק, ורק קובץ תקין נשמר. כרגע LALUM אינה סורקת נוזקות בקבצים שלקוח מעלה לפורטל, והם מגיעים ישירות למאגר פרטי עם מגבלת גודל ובלי סריקה.
מה תוקן לעומת גרסאות נפוצות:
אם מצאתם חולשה או חשש אבטחה, פנו אל [email protected]. כתבו מה ראיתם, באיזו כתובת, ואיך אפשר לשחזר, ובלי לגשת למידע של אחרים או להשתמש בחולשה מעבר לנדרש כדי להדגים אותה.
פרטי הקשר מפורסמים גם בקובץ security.txt, בדרך המקובלת לכך.
הטענות נבדקו ב-10.11.2026 מול הקוד ומול המערכת החיה, הטענות בקבוצה "פיתוח מאובטח" ב-2.11.2026, והטענות שמצטטות את הדין ואת מדיניות הפרטיות ב-5.11.2026.
העמוד מספק מידע כללי על בקרות אבטחה ואינו התחייבות חוזית ואינו ייעוץ משפטי. התחייבות כזו, אם תינתן, תיכתב בהסכם מול לקוח.
ייעוץ וחוות דעת נדל״ן · ייעוץ וחוות דעת AI · ייעוץ משפטי · גישור ויישוב סכסוכים · מאמרים · שאלות ותשובות · מבדק מוכנות · לתיאום פגישת ייעוץ
כל שינוי בקוד נבדק בשער פיתוח מאובטח לפי עקרונות OWASP Top 10, ISO/IEC 27001:2022 (A.8.28) ו-NIST SSDF. בדיקה אחרונה: 2.11.2026. פירוט הבקרות