הענן נפגע: מה מתקפת הרחפנים על תשתיות AWS מלמדת אותנו על רציפות עסקית (Continuity of care)

בתחילת מרץ 2026 קרה משהו שרובנו ידענו שיכול לקרות, אבל מעטים באמת התכוננו אליו: מתקפת רחפנים איראנית פגעה בשלושה מתקנים של Amazon Web Services (AWS) באיחוד האמירויות ובבחריין. שני מרכזי נתונים באמירויות נפגעו ישירות, ומתקן שלישי בבחריין ניזוק מפגיעה בסמיכות. השריפות שפרצו, נזקי המים ממערכות כיבוי האש, והשבתת החשמל על ידי הרשויות המקומיות - כל אלה הובילו להפסקת שירותים רחבה שנמשכה ימים.

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

תלות בתשתיות ענן אזוריות - מה זה באמת אומר 

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

המקרה של AWS חשף כמה נקודות חשובות. ראשית, ארכיטקטורת Multi-AZ, שנחשבת לשיטה המומלצת לזמינות גבוהה, אינה מספיקה כשמדובר בפגיעה פיזית באזור שלם. שני Availability Zones נפגעו באותו Region, מה שאומר שארגונים שהסתמכו על פיזור בתוך Region, כפי שממליץ כל מדריך Best Practices, חוו הפסקת שירות מלאה. שנית, הנזק לא היה רק טכנולוגי. שירותי בנקאות, אפליקציות תשלומים, שירותי משלוחים, ואפילו פלטפורמות AI, כולם נפגעו. ההשלכות חרגו הרבה מעבר לטכנולוגיה, אל ליבת החיים האזרחיים. 

בסקטור הבריאות, התלות הזו מקבלת משמעות אחרת לגמרי. כשמערכת EMR לא זמינה, זה לא רק שירות שלא עובד, זה רופא שלא יכול לקבל החלטה קלינית. כש-PACS נופל, רדיולוג לא יכול לקרוא בדיקה דחופה. במילים אחרות: בעולם הבריאות, זמינות היא לא רק KPI טכנולוגי, היא חיים. 

Data Residency מול יתירות גיאוגרפית - הדילמה שאף אחד לא רוצה לפתור 

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

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

הפתרון לא חייב להיות בינארי. אפשר לחשוב על מודלים שבהם מידע רגיש מסווג לפי רמות: מידע מזהה נשאר מקומי, אבל עיבוד וניתוח יכולים לרוץ ב-Regions מרוחקים. אפשר להשתמש באנקריפציה שמבטיחה שגם אם הנתונים עוברים גבול, הם נשארים חסרי משמעות ללא מפתח שנמצא בארץ. ואפשר, וצריך, לבנות ארכיטקטורות Multi-Region שכוללות failover אוטומטי ל-Region אחר, גם אם הרגולציה מחייבת שה-Primary יהיה מקומי. 

ההקשר הישראלי: לענן ממשלתי, בריאות, ומה שביניהם 

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

מצד שני, האירוע במזרח התיכון מחייב אותנו לשאול שאלות לא נוחות. ישראל, בוודאי בהינתן המציאות הגיאופוליטית שלה, אינה חסינה מפני תרחיש דומה. מה קורה אם מרכז נתונים בישראל נפגע? האם ארגוני הבריאות שמעבירים מערכות לענן במסגרת לענן ממשלתי בנו תוכנית DR (Disaster Recovery) שלוקחת בחשבון פגיעה פיזית בתשתית מקומית? האם יש failover אמיתי ל-Region באירופה? 

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

איך מתכננים נכון: עקרונות לארכיטקטורה שרידה בסביבה רגולטורית 

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

סיווג נתונים כבסיס לארכיטקטורה. לא כל המידע שווה. נתונים מזהים (PII/PHI) צריכים להישאר מקומיים בהתאם לרגולציה, אבל נתוני תפעול, לוגים, אנליטיקה, אלה יכולים לרוץ מ-Region משני. סיווג נכון מאפשר גמישות ארכיטקטונית בלי לפגוע בתאימות. 

Multi-Region DR עם Primary מקומי. להריץ את ה-Primary בישראל (כפי שהרגולציה מחייבת), אבל לתכנן failover אוטומטי ל-Region באירופה (למשל eu-west-1 או eu-central-1). זה אומר רפליקציה מתמדת של נתונים, DNS failover, ותרגול תקופתי של תרחיש מעבר. 

הצפנה כמפתח לגמישות. כשנתונים מוצפנים ב-encryption at rest וב-transit, ומפתחות ההצפנה מנוהלים מקומית (למשל באמצעות AWS KMS עם מפתחות שנשמרים בישראל), ניתן לשמור עותקי גיבוי ב-Region מרוחק בלי לפגוע בריבונות על המידע. 

Chaos Engineering - לא רק למתחילים. לתרגל כשל של Region שלם. לא על נייר, לא בתיאוריה, בפועל. להריץ Game Day שבו ה-Region הישראלי "נעלם" ולבדוק מה באמת קורה. ברוב המקרים, ההפתעות לא נעימות. 

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

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

הענן הוא כלי אדיר. הוא מאפשר חדשנות, גמישות, וקפיצת מדרגה טכנולוגית שלא הייתה אפשרית לפני עשור. אבל כמו כל כלי, צריך לדעת להשתמש בו נכון. ו"נכון" אומר לתכנן לא רק ל-best case, אלא גם ל-worst case. במיוחד כשה-worst case הוא לא באג בתוכנה אלא כטב"מ שפוגע בבניין.