CISA הוסיפה ב-26.08.2026 חולשה מנוצלת ב-Microsoft SQL Server לרשימת ה-KEV. במדריך: איך בודקים גרסה וחשיפה, אילו הרשאות מגדילות סיכון, איך מצפינים ומנטרים נכון, ואיך הופכים עדכון לתיקון מתועד.
⚡ TL;DR, תקציר מהיר
מה קרה: CISA הוסיפה את CVE-2019-1068 ב-SQL Server ל-KEV ב-26.08.2026 על בסיס ניצול פעיל בשטח.
הבדיקה הראשונה: להריץ SELECT @@VERSION בכל מופע SQL Server ולהשוות לטבלת הגרסאות של Microsoft.
מה בודקים: הרשאות חשבון שירות, הצפנת TDE ותעבורה, ניטור Audit Log, ותיעוד מחזור התיקון.
לא לדלג: גיבוי מלא ובדיקת שחזור לפני כל התקנת CU או GDR בפרודקשן.
מה קרה ב-26 באוגוסט 2026, ולמה זה נוגע גם לעסק בגודל שלכם?
ב-26 באוגוסט 2026 הוסיפה CISA שישה CVEs לרשימת ה-Known Exploited Vulnerabilities שלה, וביניהם חולשה ב-Microsoft SQL Server (CVE-2019-1068) שיש עליה ראיות לניצול פעיל בשטח. הכניסה לרשימת ה-KEV לא נועדה רק לארגוני ממשל: CISA ממליצה לכל הארגונים לתעדף חולשות שנמצאות שם, כי בניגוד לרוב הפרצות התיאורטיות, כאן כבר ידוע שמישהו מנצל אותן בפועל.
אם יש לכם מערכת עסקית שיושבת על SQL Server, למכירות, לניהול לקוחות, להנהלת חשבונות, לייצור, אבטחת שרתי SQL אצלכם מתחילה לא ב"האם צריך לעדכן", אלא ב"איזו גרסה רצה אצלנו ומה החשיפה שלה". מדריך זה נותן לכם את סדר הבדיקה: זיהוי גרסה, הרשאות מסוכנות, הצפנה, ניטור, ואיך מתעדים את החלטת התיקון כך שיש לכם ראיה שהטיפול הושלם.
הפרסום המקורי, לפי CISA (26.08.2026), מגדיר את החולשה כ-CVE-2019-1068, פגיעה בהרצת קוד מרחוק בהקשר חשבון השירות של SQL Server Engine, ומחייב רשויות פדרליות אמריקאיות לטפל בה עד תאריך יעד. עסק ישראלי לא כפוף לצו הזה, אבל הראיה לניצול פעיל תקפה בדיוק באותה מידה, בלי קשר למי המפרסם.
איך בודקים אילו גרסת SQL Server רצה אצלכם ואם היא נושאת את התיקון?
מריצים SELECT @@VERSION בכל מופע SQL Server פעיל, ובודקים את מספר ה-Build מול טבלת הגרסאות הרשמית של Microsoft. אם הבילד ישן מהעדכון המצטבר (CU) או עדכון האבטחה (GDR) האחרון לגרסה שלכם, המערכת חשופה עד שהעדכון יותקן. זו הבדיקה היחידה שקובעת אם החולשה רלוונטית אצלכם בפועל.
Microsoft מפרסמת ומעדכנת מפת גרסאות ל-SQL Server, כולל מספרי Build לכל GDR ו-CU, בעמוד התמיכה הרשמי שלה (עודכן לאחרונה ב-13.08.2026). שני נתיבי עדכון קיימים במקביל:
- GDR (General Distribution Release), מכיל רק תיקוני אבטחה. מסלול שמרני, מתאים כשרוצים לסגור חולשה בלי לשנות התנהגות אחרת של המנוע.
- CU (Cumulative Update), מכיל תיקוני אבטחה וגם באגים ושיפורים נוספים. מסלול רחב יותר, דורש בדיקת רגרסיה יסודית יותר לפני התקנה בפרודקשן.
עסק שמריץ מערכת עסקית קריטית (ERP, CRM, מערכת ייצור) על SQL Server, ולא יודע להשיב תוך דקות מה מספר ה-Build המותקן, כבר נמצא בפער ניהולי, לא רק טכני.
אילו הרשאות וגישה למנוע ה-SQL Server מגדילות את משטח החשיפה?
ההרשאה המסוכנת ביותר היא חשבון שירות (Service Account) שרץ בהרשאות מנהל מערכת מקומי או Domain Admin, כי חולשה בהרצת קוד מרחוק בהקשר החשבון הזה נותנת לתוקף בדיוק אותן הרשאות. מדריך האבטחה הרשמי של Microsoft ל-SQL Server ממליץ על הפרדה בין הרשאות המנוע להרשאות התחנה, ועל עקרון ההרשאה המינימלית לכל login וכל role.
לפי הנחיית Microsoft, שכבות ההרשאה שכדאי לבדוק כוללות:
| שכבה | מה בודקים | סיכון אם לא מוגדר נכון |
|---|---|---|
| חשבון שירות | האם רץ תחת חשבון ייעודי ולא Local System או Domain Admin | הרצת קוד עוינת יורשת הרשאות רחבות |
| Login-ים | האם sa מושבת או שיש לו סיסמה חזקה ומוגבלת שימוש | כניסה ישירה למנוע דרך חשבון ידוע ומנוחש |
| Server roles | האם משתמשי אפליקציה מקבלים sysadmin שלא לצורך | הרשאה מלאה למקום שצריך רק קריאה וכתיבה |
| Database roles | האם יש הפרדה בין קריאה, כתיבה והרשאות מבנה (DDL) | שינוי מבנה טבלאות על ידי חשבון אפליקציה תמים |
| גישת רשת | האם הפורט (בדרך כלל 1433) פתוח לאינטרנט או רק לרשת הפנימית | חשיפת המנוע לניסיונות חיבור מכל מקום בעולם |
איך מצפינים נתונים ב-SQL Server, ומה ברירת המחדל לא מכסה?
ברירת המחדל של התקנת SQL Server לא מצפינה כלום, לא בזמן מנוחה ולא בתעבורה. Microsoft מציעה מספר מנגנוני הצפנה שכל אחד מכסה סיכון שונה, ועסק צריך להפעיל אותם באופן מפורש בהתאם לרגישות הנתונים.
- TDE (Transparent Data Encryption), מצפין את קובצי מסד הנתונים על הדיסק. מגן מפני גניבת קבצים פיזית או גיבוי שדלף, לא מפני שאילתה זדונית ממשתמש מחובר.
- Always Encrypted, מצפין עמודות ספציפיות כך שאפילו מנהל מסד הנתונים לא רואה את הערך הגולמי. מתאים לשדות כמו מספרי כרטיס אשראי או תעודת זהות.
- Connection Encryption (TLS), מצפין את התעבורה בין האפליקציה למנוע. בלעדיו, פרטי התחברות ונתונים עוברים ברשת בטקסט גלוי.
- Row-Level Security, לא הצפנה במובן הטכני, אבל קובע אילו שורות משתמש מסוים רואה, וסוגר פער נפוץ באפליקציות רב-לקוחיות.
בחירה בין המנגנונים תלויה בשאלה מה מנסים למנוע. עסק שדואג מגניבת קובץ גיבוי צריך TDE. עסק שמחזיק נתוני תשלום צריך Always Encrypted על השדות הרגישים. רוב הארגונים צריכים את שניהם יחד עם TLS, לא אחד במקום השני.
מה לנטר כדי לזהות ניסיון ניצול של חולשה כזו בזמן אמת?
מנטרים ניסיונות התחברות כושלים חוזרים, שאילתות שמגיעות מחשבון שירות אך מבצעות פעולות מנהלתיות, ושינויים בלתי מתועדים בהרשאות או ב-roles. חולשת הרצת קוד מרחוק לרוב לא "שקטה", היא יוצרת פעילות חריגה שניתן לתפוס לפני שהיא הופכת לפריצה מלאה.
מקורות לוג שכדאי לחבר לניטור מרכזי:
- SQL Server Audit, מנגנון מובנה של המנוע שמתעד גישה לאובייקטים רגישים ושינויים בהרשאות.
- Windows Event Log בשרת עצמו, לזיהוי ניסיונות הרצת תהליכים חריגים תחת חשבון השירות.
- לוגי חומת אש וניתוב, לזיהוי חיבורים נכנסים לפורט 1433 ממקורות לא מוכרים.
עסק בגודל של 3 עד 100 עובדים לרוב לא מפעיל SOC פנימי 24/7, ולכן ניטור מנוהל של תשתית השרתים, לא רק אנטי וירוס בתחנות הקצה, הוא מה שסוגר את הפער בין "יש לוג" לבין "מישהו הגיב אליו בזמן".
איך הופכים בדיקת גרסה להחלטת תיקון מתועדת ולא רק "עדכנו משהו"?
מתעדים ארבעה דברים לכל שרת SQL: מספר הבילד לפני העדכון, מקור ההחלטה (למשל, הוספה ל-KEV), מי אישר את חלון התחזוקה, ותוצאת בדיקת התקינות אחרי ההתקנה. בלי התיעוד הזה, אין דרך להראות לביטוח סייבר, ללקוח שדורש הוכחת עמידה בתקנים, או לרואה חשבון מבקר, שהטיפול בחולשה אכן קרה.
רשימת בדיקה מעשית לכל מחזור תיקון:
| שלב | מה בודקים | מי אחראי |
|---|---|---|
| 1. זיהוי | הרצת SELECT @@VERSION בכל מופע, השוואה לטבלת הגרסאות של Microsoft | אחראי IT או ספק מנוהל |
| 2. תעדוף | האם החולשה ברשימת KEV, מה ציון ה-CVSS, האם המערכת חשופה לרשת חיצונית | אחראי אבטחת מידע |
| 3. גיבוי מקדים | Snapshot או גיבוי מלא לפני התקנה, כולל בדיקת יכולת שחזור | צוות תשתיות |
| 4. התקנה בסביבת בדיקה | הרצת ה-CU או GDR בסביבה מקבילה, לא ישירות בפרודקשן | צוות תשתיות |
| 5. התקנה בפרודקשן | חלון תחזוקה מתואם, עדיף שעות שפל | אחראי IT או ספק מנוהל |
| 6. אימות לאחר עדכון | בדיקת @@VERSION שוב, בדיקת תקינות אפליקציה מולה, סריקת פגיעויות חוזרת | אחראי אבטחת מידע |
| 7. תיעוד | שמירת תאריך, גרסה לפני ואחרי, ותוצאת האימות בכרטיס עבודה | אחראי IT או ספק מנוהל |
איך גיבוי SQL Server נכנס לתמונה כשמתגלה חולשה מנוצלת?
לפני כל עדכון אבטחה בשרת SQL מריצים גיבוי מלא ומוודאים שהוא ניתן לשחזור, כי עדכון שמשבש את המנוע בלי גיבוי תקין הופך תקרית אבטחה מנוהלת לתקרית זמינות בלתי מתוכננת. גיבוי הוא לא תחליף לעדכון, אלא רשת הביטחון שמאפשרת לבצע אותו בביטחון.
עסק שמריץ SQL Server בסביבה ארגונית צריך שלוש שכבות גיבוי: גיבוי מלא תקופתי, גיבוי דיפרנציאלי יומי, וגיבוי Transaction Log תכוף למערכות עם דרישת Point-in-Time Recovery. שילוב הגיבוי הנכון עם תכנון תשתית השרת עצמו, כולל השאלה אם השרת יושב בענן או במשרד, נסקר במדריך שרת במשרד מול ענן, ותכנון הרכיבים שמריצים את השרת נסקר במדריך מדריך רכיבי מחשב.
צעדי ההקשחה הכלליים, כולל מדיניות עדכונים, ניהול הרשאות ותשתית לוגים, נסקרים במדריך הקשחת שרתים. מדריך זה מתמקד בשכבה הספציפית של מנוע ה-SQL, ומיועד להישען עליו, לא להחליף אותו.
שאלות נפוצות
מה זה CISA KEV, ולמה זה חשוב לעסק ישראלי שלא כפוף לחוק האמריקאי?
CISA KEV היא רשימת חולשות עם ראיות לניצול פעיל בשטח, לא רק פוטנציאל תיאורטי. עסק ישראלי לא חייב בציווי הפדרלי, אבל הראיה לניצול פעיל רלוונטית בדיוק באותה מידה. אם החולשה ברשימה, מישהו כבר מנצל אותה, בלי קשר למי המפרסם.מה ההבדל בין GDR ל-CU, ואיזה מהם מתאים לתיקון חולשה?
GDR מכיל רק תיקוני אבטחה, ומתאים כשרוצים לסגור חולשה מהר עם סיכון רגרסיה נמוך. CU מכיל תיקוני אבטחה יחד עם באגים ושיפורים נוספים, ודורש בדיקה יסודית יותר לפני התקנה בפרודקשן. Microsoft מפרסמת את שניהם בטבלת הגרסאות הרשמית שלה.האם TDE מספיק כדי להגן על מסד נתונים של SQL Server?
לא. TDE מצפין את קובצי מסד הנתונים על הדיסק ומגן מפני גניבת קובץ פיזי או גיבוי שדלף, אבל לא מפני שאילתה זדונית ממשתמש מחובר עם הרשאות תקינות. הגנה מלאה דורשת שילוב של TDE, הצפנת תעבורה (TLS), הרשאות מינימליות וניטור.כמה זמן יש לעסק לתקן חולשה שנוספה ל-KEV?
CISA קובעת מועד יעד לרשויות פדרליות אמריקאיות, בדרך כלל בין שבועיים לשלושה. עסק ישראלי לא כפוף למועד הזה, אבל ראיה לניצול פעיל היא סיבה לתעדף את התיקון באותו לוח זמנים, ולא לדחות אותו לחלון התחזוקה הבא כמו עדכון שגרתי.מי אחראי לבדוק את גרסת ה-SQL Server, אם אין לנו איש IT פנימי?
במרבית העסקים בגודל 3 עד 100 עובדים, האחריות עוברת לספק ה-IT המנוהל שמתחזק את התשתית. כדאי לוודא מול הספק שקיים תהליך תיעוד ברור, מי בודק גרסה, באיזו תדירות, ואיזו ראיה נשמרת שהתיקון בוצע ואומת.האם מספיק לעדכן את SQL Server פעם בשנה יחד עם שאר עדכוני המערכת?
לא כשמדובר בחולשה שברשימת ה-KEV. עדכון שגרתי יכול להישאר במחזור התחזוקה הרגיל, אבל חולשה עם ראיה לניצול פעיל דורשת תעדוף מחוץ למחזור, לפי המלצת CISA לתעדף לפי סיכון ולא לפי לוח זמנים קבוע מראש.תשתית שמריצה מערכת עסקית על SQL Server היא בדיוק המקום שבו בדיקת גרסה שגרתית פוגשת החלטת אבטחה עם שעון. אם אתם לא בטוחים אילו שרתים אצלכם חשופים כרגע, שירותי תשתיות ושרתים של SouliTek הוא המקום להתחיל בבדיקה.
רוצים לדעת אילו שרתים אצלכם חשופים כרגע?
המומחים שלנו ב-SouliTEK ישמחו לבצע סקירה מקצועית ולהתאים עבורכם תוכנית פעולה.
יוצא עולם הסייבר ההתקפי עם למעלה מ-10 שנות ניסיון בשירותי IT לארגונים. מוביל את SouliTek במתן שירותי מחשוב מנוהלים ואבטחת מידע לעסקים קטנים ובינוניים בישראל.
LinkedIn