החשיבה שמאחורי העבודה.

בעיות שאנחנו פוגשים שוב ושוב.

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

המסמכים עצמם כתובים באנגלית.

• תשתיות רשת

  למה רשתות Wi-Fi במשרד נכשלות בקיבולת ולא בכיסוי

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

• ניהול זהויות והרשאות

  SSO הוא החלק הקל

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

• ניהול תחנות קצה ו-MDM

  מה באמת נדרש להקמה אוטומטית של מכשירים

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

• מוכנות ותגובה לאירועי אבטחה

  איך מנתחים גל התראות רוחבי

  צורת הגל מזהה את מקורו מהר יותר מניתוח הקובץ עצמו.

• מסירת דוא״ל ומוניטין

  כש‑DKIM עובר בצד השולח ונכשל בצד הנמען

  החתימה מכסה את התוכן לאחר נרמול. שינוי בהמשך עלול לפסול אותה.

• ניהול ובקרה של פלטפורמות AI

  שש שאלות שכדאי לשאול על פלטפורמת AI

  אותן בקרות כמו בכל פלטפורמה אחרת, בסדר הנכון.

• אבטחת דוא״ל

  מאומת לא אומר אמיתי

  SPF, DKIM ו-DMARC יכולים לעבור בהצלחה גם על הודעה שהתחזתה בצורה משכנעת למישהו אחר.

מבט לעומק

נושאים ממוקדים יותר: בקרות ספציפיות, מקרי קצה ופרטי יישום.

תשתיות רשת

• מה נשבר כשאתר מאבד סנכרון זמן

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

• אחד-עשר VLAN ורשת אחת שטוחה

  הפרדת דומיין השידור היא החלק הקל. מיקום ה-Gateway קובע איפה מדיניות ההפרדה באמת נאכפת.

• כלל Deny שלעולם לא מופעל

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

ניהול זהויות והרשאות

• המשך עם Google: שתי החלטות בכפתור אחד

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

• שיתוף בקישור הוא הרשאה שאף אחד לא מבטל

  הקישור יכול להישאר פעיל הרבה אחרי שמי שיצר אותו עזב, בלי שתהליך ה-Offboarding או ביקורת ההרשאות ייגעו בו.

• החשבונות שמחזיקים הכול ולא שייכים לאף אחד

  חשבונות Break-glass, Service Accounts ואינטגרציות לא תמיד שייכים לאדם, ולכן תהליכי Joiner-Mover-Leaver רגילים פשוט לא מגיעים אליהם.

• שרת הקבצים שאף אחד לא הקים

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

• כוננות היא מצב זמני

  גם הגישה המוגברת לסביבת הייצור צריכה להיות זמנית.

• הלוגים של Okta הם כבר פיד אבטחה

  ה-System Log מתעד את השינוי האדמיניסטרטיבי. השאלה אם מישהו בכלל רואה אותו היא החלטה נפרדת.

• נתיב הכניסה ששרד את המיגרציה

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

• העדכון הצליח, אבל שום דבר לא השתנה

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

ניהול תחנות קצה ו-MDM

• ספק הזהויות ומערכת ה‑MDM הם שני מישורי בקרה

  גם ספק הזהויות וגם ה‑MDM יכולים להחזיק מידע על אותו משתמש ואותו מכשיר. השאלה היא איזו מערכת קובעת כשיש סתירה.

• זהות מנוהלת, מכשיר לא מנוהל

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

מוכנות ותגובה לאירועי אבטחה

• אי אפשר לחקור מידע שכבר לא נשמר

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

• הספק שאין כמעט מה לבדוק עליו

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

• חצי מהדוח בכלל מדבר עליכם

  דוח SOC 2 יכול להניח שאתם מפעילים בקרות מסוימות בצד שלכם. ה-CUECs מראים איפה האחריות של הספק נגמרת ושלכם מתחילה.

• חוות דעת נקייה לא אומרת שהדוח נקי משאלות

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

מסירת דוא״ל ומוניטין

• המייל מלא בדומיינים של אחרים

  גם כשה-SPF, ה-DKIM וה-DMARC תקינים, קישורים, תמונות ושירותי מעקב של צד שלישי יכולים להשפיע על האופן שבו ההודעה מסוננת.

• המערכות שלכם הן אלה שנתפסות

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

ניהול ובקרה של פלטפורמות AI

• איפה מידע באמת יוצא דרך פלטפורמת AI

  תיבת הפרומפט היא הנתיב הגלוי. החיבורים והרשאות הפעולה הם הגדולים יותר.

• מגדירים את הגבול לפני ש‑Claude יכול לפעול

  משתמשים יכולים להחמיר את הרשאות החיבורים של Claude, אבל לא להרחיב אותן מעבר למדיניות הארגונית.

• רשומת Allowlist היא שם מארח, לא יעד בודד

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

• Just-in-time הוא חצי ממחזור חיים

  SSO קובע מי יכול להתחבר. ב‑Team עם JIT ההסרה עדיין ידנית.

• ארבעה מסלולים סביב התקרה

  הרשאות החיבורים שולטות בכלי החיבורים. הרחבות, MCP מקומי, מפתחות Console וחשבונות פרטיים נמצאים במישורי בקרה אחרים.

• נבדק על ידי מי שלא יכול לשנות את זה

  תקרה שנראתה רק מחשבון ה‑Owner היא הנחה. צריך לבדוק את התוצאה מחשבון משתמש רגיל.

• הלוג נמצא במערכת האחרת

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

• להעלות את הרישיון, לא את התקרה

  תקרת חריגה נמוכה היא גלאי. סוג הרישיון הוא התקציב.

אבטחת דוא״ל

• שירות הסריקה הוא תחנה נוספת בנתיב הדוא״ל

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

• החתימה מכסה את ההודעה, לא את המסלול

  DKIM ו-DMARC יכולים לעבוד בדיוק כמתוכנן ועדיין לא לעצור שימוש חוזר בהודעה חתומה או ניצול לרעה של מערכת ששולחת בשמכם.

• מדיניות ההתחזות שאף אחד לא תחזק

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

• הגדרות הדוא״ל שאף אחד לא מכניס לבדיקת האבטחה

  Delegation קובע מי יכול לקרוא תיבה, Send-as מי יכול לשלוח בשמה, ו-Forwarding לאן הדואר יכול לצאת מהארגון.

• אף אחד לא מחויב להצפין דוא״ל בדרך אליכם

  TLS אופורטוניסטי בדרך כלל עובד. MTA-STS מאפשר לפרסם מדיניות שמגדירה מתי שולח תומך לא אמור לרדת לחיבור שאינו עומד בדרישות.

• Quarantine הוא תור, לא משמורת

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