אבטחת מידע רפואי מדריך פרקטי למפתחי מכשור
ב־17:40 מתקבלת התראה: מכשיר ניטור מחובר הפסיק לתקשר עם המערכת המרכזית. הצוות מנסה לאתחל אותו, התמיכה הטכנית בודקת את החיבור, ובינתיים המידע הקליני לא מגיע למקום שבו צריכים אותו. זה הרגע שבו מבינים שמכשיר רפואי מחובר הוא לא רק אלקטרוניקה, תוכנה ומעטפת. הוא חלק מסביבת טיפול, ולכן כל כשל אבטחה עלול להפוך לכשל תפעולי או קליני.
יזמים נוטים לדחות את אבטחת המידע לסוף, בדרך כלל לשלב שבו כבר יש אב־טיפוס, ספקים, קושחה ומועד אספקה. זו טעות יקרה. אבטחה שנכנסת לאפיון משפיעה על בחירת המעבד, זיכרון, ממשקי התקשורת, מבנה ההרשאות, תהליך העדכון והאופן שבו המוצר ייוצר ויתוחזק. אבטחת מידע רפואי היא תכונת מוצר, לא מסמך שמוסיפים לפני ביקורת.
למה אבטחת מידע רפואי היא קודם כל בטיחות מטופל
מכשיר רפואי שמחובר לרשת מאפשר איסוף, עיבוד והעברה של מידע חשוב. הוא גם יוצר נקודת כניסה חדשה. אם התוקף משבית את התקשורת, משנה הגדרה, נועל את המערכת או מונע מהצוות לקבל נתונים, הבעיה כבר אינה מוגבלת לפרטיות. היא נוגעת ישירות לרציפות הטיפול.
הסיכון הזה אינו תיאורטי. דו״ח מבקר המדינה על מכשירים רפואיים מצביע על כ־700 מיליון ניסיונות תקיפה בעולם שנועדו להשבית מכשירים רפואיים, לצד דיווח על זיהוי מתקפה בערך כל 18 שניות. הנתונים האלה אינם אומרים שכל מכשיר בישראל ייפרץ. הם כן אומרים שמכשור מחובר כבר נחשב יעד, ושאי אפשר להשאיר את ההגנה ליד המקרה.
התקלה מתחילה הרבה לפני בית החולים
בפיתוח מכשור רפואי, האבטחה מתחילה בהחלטות שנראות בהתחלה מכאניות או אלקטרוניות. האם יציאת השירות פתוחה? האם אפשר לחבר התקן USB בלי הרשאה? האם הקושחה מאומתת לפני הפעלה? האם המכשיר ממשיך לפעול באופן בטוח כאשר הרשת אינה זמינה? האם צוות התחזוקה מקבל גישה רחבה מדי?
כל תשובה משפיעה על התפקוד הקליני. מוצר שלא תוכנן למצבי כשל יאלץ את הצוות לאלתר. אלתור בסביבת טיפול הוא בדיוק המקום שבו נוצר פער בין התכנון לבין המציאות.
גם דליפת מידע פוגעת בבטיחות, רק בדרך אחרת. תיק רפואי, תוצאת בדיקה או פרטי מטופל שנחשפים עלולים לפגוע באדם ובאמון שלו במערכת. לפי הנחיית הרשות להגנת הפרטיות להעברת מידע רפואי באמצעים דיגיטליים, יש להתייחס למידע רפואי כמידע רגיש, לצמצם את המידע המועבר ולבחור אמצעי ייעודי ומאובטח. זו לא רק דרישה משפטית. זו דרך בסיסית להבטיח שהמוצר לא יוצר נזק במקום שבו הוא אמור לעזור.
כלל תכנון: אם אבטחה יכולה להשפיע על פעולה קלינית, היא צריכה להופיע בדרישות המערכת כבר ביום הראשון.
החלטה מוקדמת חוסכת שינוי מאוחר
שינוי מאוחר כמעט תמיד נוגע ביותר רכיבים ממה שנדמה. הוספת אימות, הפרדת הרשאות או מנגנון עדכון מאובטח עשויה לדרוש שינוי במעבד, בזיכרון, בממשק המשתמש, בבדיקות, בתיעוד ובתהליך הייצור. לפעמים היא גם מחייבת שינוי אצל ספק רכיב שכבר נבחר.
לכן כדאי לנסח בתחילת הפרויקט מודל איומים פשוט. מי עלול לגשת למכשיר? איזה מידע נשמר בו? לאן הוא נשלח? מה קורה אם הקושחה משתנה? מה קורה כשהחיבור נופל? מי יכול לעדכן, למחוק, לייצא או לשחזר מידע?
המסמך הזה לא צריך להיות ארוך. הוא צריך להיות מדויק. כל תשובה הופכת אחר כך לדרישת תכן, בדיקת קבלה או כלל תפעולי. כך אבטחת מידע רפואי הופכת מחסם בסוף הדרך לחלק מהאופן שבו המוצר עובד.
הסיכונים האמיתיים במכשור רפואי מחובר
הסיכון המרכזי אינו תמיד “האקר מבחוץ”. בבדיקות חדירה במרכז רפואי בישראל נמצאו 13 ממצאים משמעותיים בחמישה תחומים, כפי שמתואר בתקציר דו״ח מבקר המדינה על סייבר במרכז רפואי. בשנת 2021 מגזר הבריאות בישראל היה בין עשרת המגזרים המותקפים ביותר במדינה, והכשלים שנמצאו מציירים תמונה שימושית מאוד גם למפתחי מכשור.
התחום הראשון הוא סגמנטציה ובקרת גישה. מכשיר קליני לא צריך להיות באותה סביבת רשת כמו עמדות משרדיות, מדפסות או מערכות שאינן חיוניות לטיפול. כאשר אין בידוד, תקיפה שהתחילה בתחנת עבודה עלולה להתפשט למערכות נוספות. בקרת גישה צריכה להיבנות לפי תפקיד, פעולה והקשר, לא לפי ההנחה שכל משתמש בתוך בית החולים הוא משתמש מהימן.
התחום השני הוא גישת רשת. כל ממשק תקשורת הוא החלטה הנדסית. Wi-Fi, Ethernet, Bluetooth, חיבור תחזוקה או ממשק ענן צריכים להיות ממופים, מוגבלים ומתועדים. אם המכשיר חייב לתקשר עם שירות חיצוני, הגדירו בדיוק מה עובר, לאן, באיזה מצב, ומה קורה כאשר הצד השני אינו זמין. מי שמפתח מוצר IoT רפואי צריך להכיר גם את המשמעות של IoT במוצרים מחוברים, אבל לא להסתפק בהגדרה. צריך לתכנן את גבולות החיבור.
חמשת הכשלים שחוזרים על עצמם
שלושת התחומים הנוספים שנמצאו הם הגנת תחנות עבודה ושרתים, תוכנה לא מעודכנת וגישה לא מאובטחת. אלה נשמעים כמו נושאי IT, אבל במכשיר רפואי הם נכנסים ישר לתכן.
תחנות עבודה ושרתים: עמדת תפעול שמאפשרת גישה רחבה מדי הופכת לנקודת חולשה. הפרידו בין פעולות קליניות, תחזוקה וניהול.
תוכנה לא מעודכנת: רכיב תוכנה ללא תהליך תיקון מסודר נשאר חשוף גם אחרי שהחולשה ידועה. צריך לדעת אילו ספריות ורכיבים נמצאים במוצר, מי מתחזק אותם ואיך מפיצים עדכון.
גישה לא מאובטחת: סיסמת ברירת מחדל, ממשק שירות פתוח או חשבון משותף מונעים זיהוי אמיתי של המשתמש ומקשים על חקירת אירוע.
הטעות הנפוצה היא להשקיע רק ב־perimeter security, כלומר בשער החיצוני. אם המשתמש, הקושחה, השרת או ממשק התחזוקה חלשים, חומת אש לבדה לא תפתור את הבעיה.
מיפוי משטח התקיפה
מפו את המוצר לפי מסלול המידע: חיישן, מעבד, זיכרון, קושחה, ממשק משתמש, רשת, שרת, מערכת בית החולים וספק התחזוקה. ליד כל נקודה כתבו מי ניגש, מה הוא יכול לעשות ומה יקרה אם היא תיפגע.
אחר כך תעדפו לפי השפעה על טיפול, פרטיות והתאוששות. אל תתחילו מהכשל שקל לתקן. התחילו מהכשל שעלול להשבית פעולה קלינית או לפתוח גישה למידע רחב. Segmentation ו־patch management הם בקרות ליבה, לא סעיפים שמסמנים בסוף הפרויקט.
מה הרגולציה הישראלית דורשת ממך בפועל
בישראל, אבטחת מידע רפואי הפכה ממדיניות מומלצת לתנאי מחייב. ב־1.1.2014 נקבע שמוסדות רפואה צריכים להיות מוסמכים לתקן ISO 27799 כתנאי לרישוי, וב־1.1.2016 הורחבה החובה גם לספקים חיצוניים, שנדרשו לעמוד ב־ISO 27001 או ISO 27799, לפי הסקירה על תקן ISO 27799 בישראל. המשמעות עבור יצרן היא פשוטה: אתם חלק ממערכת הרישוי ושרשרת האספקה, גם אם המוצר שלכם אינו בית חולים.
הצעד הראשון הוא מיפוי מאגרים. רשמו איזה מידע המוצר אוסף, היכן הוא נשמר, מי מעבד אותו, למי הוא נשלח ואילו ספקי משנה נוגעים בו. אל תסתפקו בשם המוצר. מאגר יכול להופיע בזיכרון המכשיר, במחשב שירות, בפורטל מטופלים, בגיבוי או במערכת ענן.
הצעד השני הוא ספירת מורשי הגישה. לפי ההסבר על רמות האבטחה בישראל, מידע בריאות מסווג כברירת מחדל ברמת אבטחה בינונית. הרמה עולה לגבוהה כאשר המאגר כולל מידע בריאותי על 100,000 נבדקים ומעלה, או כאשר ל־100 אנשים ומעלה יש גישה אליו. שני הספים האלה דורשים בדיקה נפרדת, ולכן מאגר שאינו גדול במיוחד עדיין עלול להיכנס לרמה גבוהה בגלל מספר המשתמשים.
מתי מאגר מידע בריאות עולה לרמת אבטחה גבוהה
קריטריון | סף לרמה גבוהה | משמעות פרקטית |
|---|---|---|
היקף נבדקים | 100,000 נבדקים ומעלה | יש להיערך לבקרות מחמירות יותר, תיעוד, הרשאות וניהול סיכונים ברמה גבוהה |
מספר מורשי גישה | 100 אנשים ומעלה | יש לבחון את מבנה ההרשאות, יומני הגישה והפיקוח על משתמשים וספקים |
הצעד השלישי הוא התאמת בקרות. הפרדת רשתות, הרשאות לפי תפקיד, תיעוד גישה ובקרה על ספקי משנה אינם מסמכים נפרדים מהתכן. הם צריכים להופיע בדרישות המוצר, בחוזים ובבדיקות. ההסבר על רגולציה למכשור רפואי יכול לעזור למסגר את השיחה, אבל את ההחלטות צריך לקבל לפי זרימת המידע במוצר שלכם.
מה לתעד לפני ביקורת
שמרו תיעוד של מיפוי המאגרים, רשימת המשתמשים, מודל ההרשאות, רכיבי התוכנה, תהליך העדכונים, ספקי המשנה ותוכנית ההתאוששות. כאשר התיעוד נבנה בזמן הפיתוח, הוא משרת גם את האיכות וגם את האבטחה. כאשר מתחילים אותו אחרי שהמוצר מוכן, הוא הופך למרדף אחר פרטים שאבדו.
איך בונים אדריכלות אבטחה מהתכן ועד הייצור
אבטחה טובה מתחילה באדריכלות, לא בסיסמה. בחרו מראש אילו רכיבים אמורים לדעת זה על זה, אילו נתונים צריכים להישמר, ואילו פעולות מחייבות הרשאה מיוחדת. אחר כך תכננו את המוצר כך שההפרדה הזו תהיה מובנית, ולא תלויה במשמעת של משתמש יחיד.
בתכן המכאני, הגנו על יציאות שירות, מחברי debug, כרטיסי זיכרון וגישה פיזית ללוח. אם טכנאי צריך לפתוח את המארז, הגדירו איך הוא מזוהה ומה הוא רשאי לבצע. אל תשאירו ממשק תחזוקה פעיל במוצר סדרתי רק מפני שהוא היה נוח באב־טיפוס.
בתכן האלקטרוני, בדקו אם הרכיב שבחרתם תומך באתחול מאובטח, אחסון מפתחות מוגן, חתימה על קושחה ועדכון שניתן לאמת. אם אין דרך לוודא שהקוד שהותקן הוא הקוד שאישרתם, אין לכם שליטה אמיתית על המוצר לאחר הייצור.
הפרדה במקום אמון
במוסד רפואי, הפרידו בין הרשת הקלינית לבין הרשת האדמיניסטרטיבית. המכשיר צריך לקבל רק את החיבורים הדרושים לו, ולא גישה כללית לסביבה. בתוך המכשיר עצמו, הפרידו בין תהליך האיסוף, תהליך התקשורת, ממשק המשתמש ושירות התחזוקה ככל שהארכיטקטורה מאפשרת.
הרשאות צריכות להיות לפי תפקיד. מפעיל צריך להפעיל. טכנאי צריך לתחזק. מנהל מערכת צריך לנהל. אף אחד מהם לא צריך לקבל גישה מלאה כברירת מחדל. תעדו כל כניסה וכל פעולה משמעותית, כדי שאפשר יהיה להבין מה קרה בלי לנחש.
כלל הנדסי: דלת שלא צריך לפתוח, לא משאירים פתוחה “ליתר ביטחון”.
קושחה, עדכונים וייצור
תהליך עדכון מאובטח צריך לכלול מקור מוכר, אימות חתימה, בדיקת שלמות, אפשרות חזרה לגרסה תקינה והתנהגות ברורה במקרה של כשל. הגדירו גם מי מאשר עדכון ומי מתעד אותו. עדכון שאי אפשר לעקוב אחריו יוצר בעיית אבטחה ותפעול גם אם הוא טכנית מוצלח.
בייצור, שמרו על שליטה בגרסת הקושחה, במפתחות, ברכיבים ובתחנות הצריבה. אין להכניס סודות קבועים לכל היחידות. ודאו שהמוצר יוצא מהמפעל במצב נעול, ושפעולות שירות נפתחות רק באמצעות תהליך מזוהה.
במקביל, נהלו רשימת רכיבי תוכנה ותלות. כאשר מתגלה חולשה, אתם צריכים לדעת אם היא קיימת, באילו גרסאות, ואיך להפיץ תיקון. זהו DFM מאובטח. לא רק לייצר בזול ובאמינות, אלא לייצר מוצר שאפשר להגן עליו לאורך חייו.
הצפנה וניהול העברת מידע בלי ליפול למלכודות
אדריכלות טובה יכולה להיהרס בפעולה יומיומית אחת. עובד מוריד קובץ למחשב פרטי, שולח צילום דרך אפליקציה שאינה ייעודית או שומר מסמך בתיקיית ענן אישית. ברגע הזה, הארגון מאבד שליטה על העותקים, ההרשאות והמחיקה.
הנחיית הרשות להגנת הפרטיות להעברת מידע רפואי באמצעים דיגיטליים, כפי שמסוכמת כאן דורשת לצמצם שימוש בתוכנות שאינן ייעודיות, לא לשמור מידע מזוהה על מכשירים פרטיים ולמחוק את המידע לאחר שהושגה המטרה שלשמה נשמר. היא גם מבהירה שאין להסתמך על שירותי גיבוי ענן פרטיים כמו Google Drive או Dropbox לצורך הזה.
נוהל העברה שאפשר לבצע
הנוהל צריך להיות קצר מספיק כדי שאנשים באמת ישתמשו בו. לפני העברה, שואלים אם כל המידע נחוץ. אם לא, מסירים פרטים מזהים או מצמצמים את הקובץ. אחר כך משתמשים במערכת ייעודית, עם הרשאה ברורה, אימות דו־שלבי ותיעוד.
הקובץ צריך להיות מוצפן במעבר ובאחסון. הסיסמה או אמצעי הגישה צריכים לעבור בערוץ נפרד, ולא להופיע באותה הודעה. לאחר שהנמען סיים להשתמש במידע, מוחקים אותו מהמקום הזמני, מהמחשב ומהמכשיר, בהתאם למדיניות הארגון.
תיקון 13 נכנס לתוקף ב־14.8.2025 והרחיב את חובות הארגונים ואת סמכויות האכיפה של הרשות. לכן הנוהל צריך להיות כתוב, מאושר ומיושם בפועל, לא רק להופיע בתיק ציות.
מה חייב להיות במערכת
המערכת הייעודית צריכה לאפשר משתמשים אישיים, הרשאות לפי תפקיד, יומן פעולות ושליטה בהעתקה וייצוא ככל שנדרש. סיסמה חזקה ואימות דו־שלבי צריכים להיות ברירת המחדל עבור גישה מרחוק, במיוחד כאשר המערכת משמשת צוותים וספקים.
אל תאפשרו צילום מידע רפואי במכשירים אישיים. אל תאפשרו העלאה אוטומטית לענן פרטי. אל תשתמשו בתיבת דוא״ל אישית כדי לעקוף מערכת שלא נוחה למשתמש. אם התהליך הרשמי מסורבל, שפרו אותו. אל תבנו נוהל שמניח שאנשים יפרו אותו בשקט.
תגובה לאירוע וניהול שרשרת אספקה מאובטחת
מוצר רפואי לא חי רק אצל הלקוח. הוא תלוי ביצרן רכיבים, מפתח תוכנה, ספק ענן, חברת תחזוקה, אינטגרטור ולעיתים גם ספק של ספק. לכן אירוע אבטחה צריך להיכנס לניהול שרשרת האספקה מהיום הראשון.
התחילו ברשימה מלאה של כל גורם שיש לו גישה לקוד, למידע, לממשקים, למפתחות או לסביבת הייצור. לכל ספק הגדירו בחוזה מה מותר לו לעשות, איזה מידע הוא מקבל, איך הוא מזוהה, כיצד מדווחים על אירוע ואיך מסתיימת הגישה. דרשו גם תיעוד של רכיבי תוכנה, עדכונים ותהליך טיפול בחולשות.
ניהול שרשרת אספקה במוצר אינו רק עניין של רכש. הוא חלק מהאבטחה. ספק שמתחבר מרחוק למכשיר, למערכת הניהול או לקו הייצור צריך לקבל גישה מוגבלת בזמן, לפי צורך, עם תיעוד מלא. ממשק ישן שנשאר פתוח לטובת נוחות הוא חוב שמישהו ישלם עליו בהמשך.
מה עושים כשמתגלה אירוע
התגובה צריכה להיות מתורגלת ופשוטה:
מזהים ומבודדים: מנתקים את המכשיר או הממשק החשוד בלי להשמיד ראיות ובלי לפגוע בפעולה קלינית חיונית.
ממנים אחראי: אדם אחד מרכז את ההחלטות, התיעוד והתקשורת מול הלקוח, הספקים והגורמים הרלוונטיים.
בודקים את ההיקף: מבררים אילו מכשירים, חשבונות, מאגרים וספקים הושפעו.
משחזרים בזהירות: מתקינים גרסה מאומתת, מחליפים פרטי גישה ובודקים שהמערכת חזרה למצב תקין.
סוגרים את הפער: מתעדים את שורש הכשל, מתקנים את התכן ומעדכנים את הנהלים והחוזים.
אבטחה טובה אינה דרמה. היא סדר פעולות שחוזר על עצמו גם ביום קשה.
אל תבנו על הגנת היקף בלבד, ואל תסמכו על כך שספק גדול “כבר מטפל בזה”. בקשו ראיות, הגדירו אחריות ובדקו את הממשקים בפועל. אבטחת מידע רפואי טובה היא שקטה, עקבית וקצת משעממת בכוונה. בדיוק כך היא צריכה להיות. היא מאפשרת למכשיר לעשות את העבודה שלו בלי להפוך לסיכון נוסף למטופל.
רותל הנדסת מוצר בע"מ מלווה פיתוח וייצור של מכשור רפואי, מהאפיון והתכן המכאני והאלקטרוני ועד אב־טיפוס, בדיקות, ניהול ספקים וייצור סדרתי. אם אתם רוצים לבחון את המוצר שלכם מול דרישות אבטחה, תכן ושרשרת אספקה לפני שהן הופכות לעיכוב, בקרו באתר רותל הנדסת מוצר בע"מ ודברו עם הצוות על השלב שבו אתם נמצאים.