→ חזרה לבלוג

מה זה סייבר: מדריך מעשי ליזמים ומנהלי פיתוח

בשנת 2025 טופלו בישראל יותר מ־26,000 אירועי סייבר, עלייה של 55% לעומת 2024, לפי דיווח המבוסס על נתוני המערך הלאומי להגנת הסייבר (דיווח על הדוח השנתי של INCD). הנתון הזה משנה את השאלה “מה זה סייבר”. עבור יזם, מנכ״ל או מנהל פיתוח, סייבר הוא לא רק שרתים ממשלתיים, תשתיות חשמל או יחידות מודיעין. הוא גם חשבון Google Workspace של עובד, מפתח שקיבל גישה רחבה מדי ל־AWS, מפתח API שנשמר בטעות במאגר קוד, או לקוח SaaS שמבקש לדעת איך החברה מגנה על המידע שלו.

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

תוכן עניינים

למה סייבר הוא כבר לא רק עניין של תשתיות לאומיות

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

בשנת 2025 התקבלו במוקד 119 כ־26,500 פניות ודיווחים על אירועי סייבר בישראל. בין הווקטורים הנפוצים בלטו פישינג, השתלטות על חשבונות וחדירות לא מורשות למערכות, לפי נתוני INCD לשנת 2025. מבחינת סטארטאפ, המשמעות מעשית: תוקף יכול להתחיל מחשבון עובד, להמשיך לסביבת הענן, ולהגיע למידע של לקוחות או לקוד המוצר.

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

הפער בין המצגת למציאות

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

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

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

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

הגדרה ומונחי יסוד בעולם הסייבר

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

ההבדל חשוב משום שהמערכת המוגנת כבר אינה יושבת בהכרח במשרד. צוות עובד דרך AWS, Azure או GCP, משתמש ב־GitHub, Slack, Jira, מערכות CRM ושירותי AI. לכל שירות יש משתמשים, הרשאות, מפתחות גישה ותלות בספק חיצוני. האבטחה צריכה להתייחס לכל המארג הזה, לא רק לשרת שנמצא מאחורי Firewall.

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

מילון קצר למנהל מוצר ול־CTO

  • Threat, איום: גורם או מצב שעלול לגרום נזק. זה יכול להיות תוקף, קבוצת תקיפה, עובד שפועל בזדון או תהליך אוטומטי שמנסה לנצל חשבונות.
  • Vulnerability, פגיעות: חולשה במערכת, בקוד, בתהליך או בהרשאה. לדוגמה, Endpoint שמקבל קלט בלי בדיקה או משתמש שמחזיק גישה לסביבת ייצור ללא צורך.
  • Exploit, ניצול: הדרך שבה תוקף משתמש בפגיעות כדי לבצע פעולה שלא היה אמור לבצע, כמו קריאת מידע או יצירת משתמש בעל הרשאות גבוהות.
  • Attack Vector, וקטור תקיפה: הנתיב שבו התוקף מגיע לנכס. קישור פישינג, API חשוף, ספק תוכנה או סיסמה שנגנבה הם וקטורים שונים.
  • Attack Surface, שטח תקיפה: כל המקומות שדרכם אפשר לנסות לפגוע בארגון, כולל קוד, ענן, חשבונות, התקנים ושירותים חיצוניים.

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

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

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

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

בשנת 2022 קיבל מערך הסייבר הלאומי 9,108 דיווחים על אירועי סייבר מכלל הגופים במשק, וכ־31% מהם יוחסו לניסיונות פישינג, לפי דיווח על נתוני דוח מבקר המדינה (הדיווח על נתוני פישינג בישראל). הנתון מדגיש למה הדרכת עובדים ו־MFA אינם נושאים אדמיניסטרטיביים בלבד.

פישינג והנדסה חברתית

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

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

כופר והשבתת פעילות

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

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

דליפת סודות וחשבונות ענן

מפתח API שנשמר במאגר קוד, הרשאת IAM רחבה מדי או Bucket שהוגדר בצורה שגויה יכולים להפוך אירוע קטן לבעיה מערכתית. לדוגמה, מפתח שנחשף ב־GitHub עשוי לאפשר גישה למשאבי ענן, למשוך מידע או להפעיל שירותים. הפתרון אינו רק סריקת קוד. יש לבטל מפתחות שנחשפו, להפריד סביבות, להשתמש ב־Secrets Manager ולהגדיר הרשאות לפי תפקיד.

שרשרת אספקה ולוחמה תודעתית

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

בישראל, סייבר מתקיים גם בתוך הקשר גיאו־פוליטי. לפי דיווח על ניתוח Radware, ישראל הייתה בשנת 2025 המדינה המותקפת ביותר בעולם במתקפות ממניעים גיאופוליטיים, עם 1,881 תביעות תקיפה ייחודיות. באותו דיווח נמסר כי Microsoft דירגה את ישראל במקום השלישי בעולם במספר מתקפות הסייבר במחצית הראשונה של 2025, עם 3.5% מכלל האירועים הגלובליים (הדיווח על ניתוחי Radware ו־Microsoft). לכן תוכנית אבטחה צריכה להתייחס גם לשיבוש שירות, דיסאינפורמציה וניסיונות להשפיע על עובדים ולקוחות, ולא רק לגניבת מידע.

רכיבי ההגנה הטכנולוגיים והארגוניים

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

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

ארבע שכבות שצריך לחבר

שכבה מה היא מגינה פשרה מרכזית
Network Security תעבורה, גבולות רשת וגישה בין רכיבים יותר בידוד מחייב ניהול מורכב יותר
Endpoint Security מחשבים, שרתים ומכשירי עובדים בקרות חזקות עשויות להכביד על משתמשים
Application Security קוד, ממשקי API, תהליכי פיתוח ונתוני אפליקציה בדיקות עמוקות דורשות זמן ומומחיות
Cloud ו־IAM זהויות, הרשאות ומשאבי ענן הרשאות מצומצמות דורשות תכנון מדויק

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

ב־AWS אפשר להשתמש ב־GuardDuty לזיהוי פעילות חשודה, ובסביבות Azure קיימים כלי אבטחה וניהול כגון Microsoft Defender for Cloud, שהיה מוכר בעבר תחת המיתוג Azure Security Center. הכלים האלה מועילים, אבל רק כאשר מישהו מקבל את ההתראה, מבין את ההקשר ומגיב. רכישה בלי תהליך הפעלה יוצרת תחושת ביטחון מטעה.

אבטחה כחלק מצינור הפיתוח

אבטחת אפליקציות צריכה להופיע בתוך SDLC. צוות React, Angular או Vue צריך להגן על צד הלקוח, אבל בקרת הרשאות אמיתית חייבת להתבצע בשרת. ב־Node.js או Python יש להוסיף בדיקות קלט, ניהול סודות, בדיקות תלויות ובקרות על API. כלי SAST, DAST וסריקת Dependencies יכולים לתפוס בעיות, אך הם עלולים גם לייצר רעש.

הפשרה הנכונה אינה “לבדוק הכול תמיד” או “לא להאט את הפיתוח”. מגדירים שערים קריטיים לפני מיזוג קוד, מתעדפים חולשות לפי חשיפה והשפעה, ומאפשרים לצוות לתקן בעיות בלי להפוך כל אזהרה לחסימת Release. בחברת Scale-up מוסיפים בדיקות חדירה, ניטור מרכזי ותהליך סקירת ארכיטקטורה. ב־Enterprise, מוסיפים גם הפרדת תפקידים, רישום פעולות ובקרות גישה מפורטות.

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

תהליכים ומדיניות אבטחה בארגון

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

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

מה צריך לקרות בשגרה

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

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

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

האיזון התפעולי חשוב. מדיניות שמחייבת אישור ידני לכל שינוי תאט צוות ותעודד עקיפות. מדיניות שמאפשרת הכול תיצור סיכון. אוטומציה, תבניות Infrastructure as Code, הרשאות זמניות ובדיקות בתוך CI/CD מאפשרות לשמור על קצב בלי לוותר על בקרה.

דרישות רגולטוריות וסידורי אבטחה לסטארטאפים

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

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

מה להכין לפני שהלקוח שואל

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

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

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

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

התחילו ממה שאפשר לבצע מחר, לא מרשימת כלים ארוכה:

  1. Pre-Seed ו־Seed: הפעילו MFA לכל החשבונות, הגדירו מנהל סיסמאות, הפרידו סביבת פיתוח מייצור, נעלו הרשאות ענן, הוציאו סודות מהקוד והדריכו את הצוות בזיהוי פישינג.
  2. Scale-up: מנו בעלים לאבטחה, הפעילו ניטור מרכזי, בצעו בדיקות חדירה, הגדירו תוכנית תגובה, בדקו ספקים והטמיעו סריקות בקוד וב־CI/CD.
  3. חברה בשלה: חברו את ההתראות לתהליך SOC או לשירות מנוהל, בצעו Threat Hunting, תרגלו התאוששות, בדקו בקרות מול דרישות לקוחות ושמרו ראיות לתפעולן.

סימני אזהרה כוללים הרשאות אדמין לכל הצוות, חשבונות משותפים, מפתחות שנשמרים בצ׳אט, גיבוי שלא שוחזר מעולם, לקוח Enterprise שממתין לתשובות, או צוות שאינו יודע מי מוביל אירוע. שלבו אבטחה באפיון ובארכיטקטורה, בין אם אתם בונים מוצר React ו־Node.js, מערכת Python, אפליקציה מובייל או פלטפורמת AI.


מיסטרביט מסייעת לסטארטאפים ולחברות הייטק לשלב אבטחה בארכיטקטורה, בפיתוח ובתחזוקת מוצרי Web, מובייל, SaaS ו־AI, וכן לחזק צוותים באמצעות Team Extension וייעוץ CTO. לקבלת ייעוץ מעשי, פיתוח תוכנה או ליווי בבניית פתרון מאובטח, בקרו באתר מיסטרביט.

תודה על פנייתך, ניצור איתך קשר בהקדם

צור קשר

נשמח לקבל את הודעתך

ונחזור אליך בהקדם